SurferNETWORK Owns Two Fundamental
Streaming Media Patents
With the issuance of our second fundamental streaming media patent, SurferNETWORK continues to demonstrate Technology Leadership of the Industry.
You can also read the Press Releases.
System for Modifying and Targeting Advertising Content of Internet Radio Broadcasts,
U.S. Patent ## 7,490,053, Issued Feb. 10, 2009, valid until 2020
This is a fundamental ad-replacement technology. SurferNETWORK (and a very few others) recognized early on that there was a financial opportunity in replacing a radio station’s over-the-air ads, which tend to feature local businesses like pizza shops and car dealers, with ads of broad appeal. Further, ads would become more valuable if they could be targeted to the needs, interests, or locality of the listener.
There really are only three basic ways that a radio station’s (or similar content provider’s) ad can be replaced: at the station, at the player, or at the central distribution server. Ad replacement at the station (“at the encoder”) can be made seamlessly, but there is no opportunity to do targeting – everyone on the Internet hears the same ad, which is different from the over-the-air ad. “Seamlessly” means that if the station runs a 37 second ad, and you replace it with a 30 second ad, you can stitch the audio together and fix up the timing with rubber-banding techniques. Ad replacement at the player enables targeting so that each listener theoretically can hear a different ad, but it is difficult to fix up the timing to avoid bad “up-cuts” where ads start too late, finish too early, etc.
The third alternative, ad replacement at the streaming server, is the optimum solution, and that is what our patent covers. At high level, the concept is to send metadata from the station to the streaming server along with the audio content, identifying ad replacement opportunities. A characteristic of streaming servers is that they send an individual stream to each listener. In this arrangement, special sauce server software receives the metadata, and when an ad slot arrives from the station, the software determines which ad to insert into each listener’s stream – hence it inherently provides targeting capability. With rubber-banding at the server it is also possible to replace a 15 second ad with a 30 second ad or vice-versa, and fix up the clock over time. Thus, both goals are achieved: ad replacement with targeting capability, and seamless ad replacement.
Streaming Media Buffering System,
U.S. Patent ## 6,766,376, Issued July 20, 2004, valid until 2021
This is the Granddaddy to all modern streaming. With our technology, supported by this patent, SurferNETWORK introduced “INSTANT-ON” to the streaming media world.
To understand the importance of this patent, it is helpful to recall a bit of history. Going back into the ‘90’s, before all that Internet stuff came about, “on-line” meant dialing into a commercial service like AOL or CompuServe, or into one of hundreds of smaller “Bulletin Board” services. Accessing a video was unthinkable, but audio music files were available from many of these sites. You would use a file transfer program to download the music file to your computer, and then you were able to play it locally after the file transfer was completed.
The next step along the technology path was the introduction of progressive download – this was a really good innovation that allowed you to start playing the file while it was downloading if your connection was fast enough (which lots weren’t). As part of this feature, the media players of the time (WinAmp and others) incorporated a buffer which would typically hold 20-30 seconds or so of audio. The download would start, and when the buffer was full the player would begin playback while the download continued. Modem connections were notoriously bad, with frequent lapses, hiccups, and dropouts. The purpose of the buffer was to store up enough audio in the bank so that it could survive an interruption of up to 20-30 seconds. But once the buffer ran down, playback would stop (obviously, since there was no more data to play out); when the connection returned to normal, the user would have to wait another 30 seconds for the buffer to fill again before playback would resume.
Music files are nice, but what if you wanted to listen to a live broadcast? Well, in about the 1997-1998 timeframe along comes streaming to address this need (and the blossoming of the Internet appeared as well). There actually are two flavors of streaming – live broadcasts and on-demand (streaming on-demand is yet another way of getting at that music file). Live streaming introduced the concept of a streaming server (ShoutCast was one of the first, followed by the next generation IceCast) which could either be located at the source location (e.g. a radio station), or in a centralized place like a datacenter. The streaming server accepted an audio feed and allowed multiple players to connect simultaneously. As each audio bit came in from the audio feed, it was immediately sent out the door to the players. These were the same players as before (i.e., WinAmp), modified slightly to connect to a streaming server, and with the same 30 second buffer.
Streaming was a great innovation, but the buffering system made it painful to use. You would connect your player to the stream, wait 20-30 seconds for the player’s buffer to fill (while you watched the buffering message increment -- “buffering ….35%”). When the buffer was full, playback would start. But, dial-up, and the Internet being bumpy roads, there were lots of dropouts due to poor connections, congested routers, and so on. As before, the playback would continue during a dropout, but each dropout depleted the music bank, and when the bank was empty, the music would stop. Since the stream was delivered to the players at the playback rate, the player would have to wait 30 seconds to fill a 30 second buffer – then playback would resume.
Streaming was a nice concept, but presented a bad experience with frequent and lengthy audio dropouts. Many users simply gave up – it was too annoying.
Then, along came SurferNETWORK. Our objective was to offer listeners a “Just like Radio” experience, with Instant-On, rapid tuning from station to station, and high quality audio. Our most important solution is memorialized in the Streaming Media Buffering patent. In simplified terms, a buffer at the streaming server stores up some amount of audio data when streaming from a “live” source like a radio station. Think of it like the radio station’s over-the-air 7 second tape delay. When a player connects, the contents of the buffer are transmitted to the player at a fast rate, faster than the playback rate and, under most circumstances, as fast as the network connection will allow. This audio data is stored up in the player’s buffer. If the buffered amount in the player diminishes due to dropouts, the buffer will be refilled at this fast pace as soon as the network connection is restored. Consequently, since the system has excellent recovery from dropouts, we can start the audio playback as soon as a minimal number of audio packets have arrived at the player – perhaps even one single packet. And there you have it – Instant-On!
And, without going into lengthy details, we might also mention that the patent describes a similar mechanism to provide Instant-On for on-demand streaming (streaming from file-based media).
You can also read the Press Releases.