throbber
US008122141B2
`
`(12) United States Patent
`Price
`
`(10) Patent N6;
`(45) Date of Patent:
`
`US 8,122,141 B2
`*Feb. 21, 2012
`
`(54) STREAMING MEDIA BUFFERING SYSTEM
`
`.
`-
`(75) Inventor. Iglasrold Edward Price, Bethel Park, PA
`(
`)
`
`(73) Assignee: WAG Acquisition, LLC, Flanders, NJ
`(Us)
`
`7/1999 Emura ........................ .. 709/219
`5,922,048 A
`7/1999 Veschietal.
`370/394
`5,923,655 A
`7/1999 GoetZ et al. ................. .. 709/231
`5,928,330 A *
`5,999,525 A l2/l999 Krishnaswamy et a1‘
`370/352
`6,002,720 A 12/1999 YuIt et al. ................... .. 375/240
`6,014,693 A
`l/2000 Ito et a1. ....... ..
`709/219
`6,014,694 A
`1/2000 Aharoniet a1.
`709/219
`6,014,706 A
`l/2000 Cannon et al. .
`709/231
`6,029,194 A
`2/2000 Tilt
`............... ..
`709/219
`
`( * ) Notice:
`
`
`
`Subject to any disclaimer, the term of this patent is extended or adjusted under 35
`
`
`
`2 630613731 A
`
`
`
`5232x121“ et a1‘ 50000 Blakeslee
`
`709031
`
`U-S-C- 154(1)) by Odays-
`.
`.
`.
`.
`.
`Thl's Patent 15 sublect to a tennmal (115'
`Clalmer'
`(21) App1.No.: 12/s00,152
`
`6,061,732 A
`6,065,050 A
`6,085,221 A
`6,292,834 B1
`
`5/2000 Korstetal. .
`709/231
`5/2000 DeMoney
`709/219
`7/2()()() Graf ““““““““““““““““““ " 709/202
`9/2001 Ravi et al.
`(Continued)
`
`(22) File/d1
`
`May 10, 2010
`
`(65)
`
`Prior Publication Data
`
`US 2010/0235536A1
`
`Sep' 16’ 2010
`
`OTHER PUBLICATIONS
`
`Salehi et al., “Supporting Stored Video: Reducing Rate Variability
`and End-to-End Resource Requirements through Optimal Smooth
`ing,” IEEE/ACM Transactions on Networking, vol. 6, Issue 4, p.
`
`Related US. Application Data
`
`397'410’ Aug‘ 1998'
`
`(63) Continuation of application No. 10/893,814, ?led on
`Jul. 19, 2004, noW Pat. No. 7,716,358, Which is a
`continuation-in-part of application No. 09/819,337,
`?led On Mar. 28, 2001, noW Pat. NO. 6,766,376.
`
`(60) Provisional application No. 60/231,997, ?led on Sep.
`12, 2()()()_
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/16
`(52) us. Cl. ..................................................... .. 709/231
`
`(58) Field of Classi?cation Search ................ .. 77%99//223301,
`See application ?le for Complete Search history
`'
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6/1996 Henley et al. .............. .. 370/60.1
`5,526,353 A
`8/1998 Glaser et a1.
`395/200.61
`5,793,980 A
`5,822,537 A 10/1998 Katseffet al.
`395/200.61
`
`(Continued)
`
`_
`_
`_
`Pr’mary Exammer * Joseph Avelhno
`
`Asslsmm Exammer i Marshall McLeod
`(74) Attorney, Agent, or Firm * Ernest D. Buff; Ernest D.
`Buff & Assoc. LLC; Gordon E. Fish
`
`(57)
`
`ABSTRACT
`
`Streaming media’ Such as audio or Video ?les’ is Sent Via the
`Internet. The media are immediately played on a user’s com
`puter. Audio/video data is transmitted from the server more
`rapidly than it is played out by the user system. The audio/
`video data in the user buffer accumulates; and interruptions in
`playback as Well as temporary modem delays are avoided.
`
`28 Claims, 3 Drawing Sheets
`
`PAGE 1 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US 8,122,141 B2
`Page 2
`
`US. PATENT DOCUMENTS
`Eyer et a1.
`6,588,015
`B1
`7/2003
`6,594,699
`B1
`7/2003
`Sahai et a1.
`Hejna
`6,598,228
`B2
`7/2003
`6,637,031
`B1 * 10/2003
`6,665,751
`B1
`12/2003
`6,708,213
`B1
`3/2004
`6,728,753
`B1 *
`4/2004
`6,829,368
`B2 12/2004
`6,889,257
`B1
`5/2005
`6,907,481
`B2
`6/2005
`7,054,500
`B1
`5/2006
`7,111,058
`B1
`9/2006
`7,170,856
`B1
`1/2007
`
`Chou ............................ .. 725/87
`Chen et al.
`Bommaiah et a1.
`Parasnis et al. ............. .. 709/203
`Meyer et al.
`Patel
`Kovacevic
`Lillevold
`Nguyen et al.
`Ho et al.
`
`3/2008 Hannaway
`7,346,698 B2
`5/2008 Nguyen et al.
`7,373,413 B1
`2001/0047377 A1* 11/2001 Sincaglia et a1. ............... .. 709/1
`
`OTHER PUBLICATIONS
`
`Rexford et al., “Smoothing variable-bit-rate video in an
`internetwork,” IEEE/ACM Transactions on Networking, vol. 7, Issue
`2, p. 202-215, Apr. 1999.
`Bianchi, “Buffer sizing for high speed video information retrieval on
`ATM networks,” GIObGCOIIIiNGW Yorki, 1997, vol. 2, pp. 1057
`1061.
`
`* cited by examiner
`
`PAGE 2 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 1 of3
`
`US 8,122,141 B2
`
`Fig. 1
`
`PAGE 3 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US. Patent
`
`Feb. 21, 2012
`
`Sheet 2 of3
`
`US 8,122,141 B2
`
`(X)
`
`2,,
`
`l1
`
`-
`
`I?
`
`16
`
`14
`
`2421
`
`Z4n
`
`18
`
`(X)
`
`2
`
`’
`
`
`
`-"'/ | \ /I______',______
`
`@2022
`
`PAGE 4 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US. Patent
`U.S. Patent
`
`Feb. 21, 2012
`Feb. 21, 2012
`
`Sheet 3 013
`Sheet 3 013
`
`US 8,122,141 B2
`US 8,122,141 B2
`
`Fig. 3
`Fig. 3
`
`32
`
`34
`
`36
`36
`
`4
`
`38
`
`40
`
`
`
`PAGE 5 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US 8,122,141 B2
`
`1
`STREAMING MEDIA BUFFERING SYSTEM
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of US. patent applica
`tion Ser. No. 10/893,814, ?led Jul. 19, 2004 (published on
`Dec. 9, 2004 as US. patent publication number 2004/
`0249969 A1, and now US. Pat. No. 7,716,358), Which Was a
`continuation-in-part of US. patent application Ser. No.
`09/819,337, ?led Mar. 28, 2001 (now US. Pat. No. 6,766,
`376), Which claimed the bene?t under 35 U.S.C. §119(e) of
`US. provisional patent application Ser. No. 60/231,997, ?led
`Sep. 12, 2000; claims the bene?t, under 35 U.S.C. §120, of
`the respective ?ling dates of said applications, as Well as
`bene?t of the ?ling date of copending US. patent application
`Ser. No. 10/825,869, ?led Apr. 16, 2004 (published on Dec.
`23, 2004 as US. patent publication number 2004/260828
`A1), Which Was a continuation of said US. patent application
`Ser. No. 09/819,337, ?led Mar. 28, 2001 (now US. Pat. No.
`6,766,376), Which claimed the bene?t under 35 U.S.C. §119
`(e) of said US. provisional patent application Ser. No.
`60/231,997, ?led Sep. 12, 2000; and hereby incorporates by
`reference the entire disclosure of each of said prior applica
`tions.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention relates to multimedia computer com
`munication systems; and more particularly, to a buffering
`system for streaming media, such as audio/video, on the
`Internet.
`2. Description of the Related Art
`Prior to the development of Internet streaming media tech
`nologies, audio and video Were formatted into ?les, Which
`users needed to doWnload to their computer before the ?les
`could be heard or vieWed. Real time, continuous media, as
`from a radio station, Was not suitable for this arrangement in
`that a ?le of ?nite siZe must be created so it could be doWn
`loaded. The advent of streaming media technologies alloWed
`users to listen or vieW the ?les as they Were being doWn
`loaded, and alloWed users to “tune-in” to a continuous media
`broadcast, or “stream”, such as from a radio station. There are
`tWo fundamental types of streaming media: (i) material that
`originates from a source having a real-time nature, such as a
`radio or TV broadcast, and (ii) material that originates from a
`non-real-time source such as from a disk ?le. An example of
`non-real-time material might be a piece of music stored as a
`disk ?le, or a portion of a broadcast that originally Was real
`time, perhaps yesterday’s TV evening neWs, and Was
`recorded into a disk ?le. For purposes of clarity Within this
`document, streaming media of type (i) Will be referred to as
`“broadcast” media, and streaming media of type (ii) Will be
`referred to as “?le based” media. Broadcast streaming media
`has as its source a system or arrangement that by de?nition
`can only be transmitted to users as fast as the material is
`generated; for example, a disk jockey speaking into a micro
`phone. Broadcast streaming media is the focus of this patent
`application.
`Since audio and video media must play out over a period of
`time it is more appropriate to think of bandWidth require
`ments than ?le siZe. The bandWidth requirement of an audio
`or video media refers to the data rate in bits per second that
`must be transmitted and received in order to listen or vieW the
`material uninterrupted. Transmitting the audio or video mate
`rial over a connection sloWer than the bandWidth requirement
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`results in unsatisfactory vieWing or listening, if vieWing or
`listening is possible at all. The connection available to most
`Internet users is by dial-up modem, Which has a maximum
`receive data rate of 56,000 bits per second. Most audio and
`video available on the Internet has been compressed to be
`listenable or vieWable Within the 56,000 bits per second
`modem bandWidth. Requirements for achieving adequate
`audio and video over the Internet generally consume a con
`siderable portion of the listener’s available bandWidth.
`Internet connection quality can vary rapidly over time, With
`tWo primary factors responsible for degradation of the instan
`taneous bandWidth actually available to the user. These fac
`tors are the quality of the user’s modem connection over
`telephone lines, Which can have periods of interference caus
`ing reduced available bandWidth, and momentary Internet
`congestion at various points along the route over Which the
`user’s data ?oWs. Each of these factors can cause delays and
`interruptions in the transmission of data to the user. Internet
`data communications devices such as routers are designed to
`drop data “packets” if they get overloaded. For material that is
`not time sensitive, these dropped packets Will usually be
`resent, and the user Will eventually be presented With the
`material. HoWever, since streaming media is time sensitive,
`dropped packets can have a signi?cant impact on the receipt
`and playback of an audio or video stream. These degradations
`in the receipt of Internet data are very common, and prevent
`most users from being able to listen to or vieW streaming
`media Without interruption unless some special provisions
`have been incorporated into the user’s computer softWare to
`accommodate data transmission interruptions.
`These interruptions are commonly referred to as “drop
`outs”, meaning that the data flow to the user has been inter
`rupted (i.e., the audio “drops out”). Dropouts can be
`extremely annoyingifor example, While listening to music.
`The current state-of-the-art solution to the problem uses a
`pre-buffering technique to store up enough audio or video
`data in the user’s computer so that it can play the audio or
`video With a minimum of dropouts. This process requires the
`user to Wait until enough of the media ?le is buffered in
`memory before listening or vieWing can begin. The media
`data is delivered by a server computer Which has available to
`it the source of the media data, such as by a connection to a
`radio station. When the user connects to the server via the
`Internet, audio/video output at the user’s system is delayed
`While the user’s buffer is ?lled to a predetermined level.
`Typical pre-buffering Wait times range from 10 to 20 seconds
`or more, determined by the vendor providing the audio or
`video media. Even With this pre-buffering process, interrup
`tions in playback still occur.
`In this process, the user has a softWare application on the
`computer commonly called a “media player”. Using the fea
`tures built into the media player, the user starts the audio or
`video stream, typically by clicking on a “start” button, and
`Waits 10-20 seconds or so before the material starts playing.
`During this time data is being received from the source and
`?lling the media player’s buffer. The audio or video data is
`delivered from the source at the rate it is to be played out. If,
`for example, the user is listening to an audio stream encoded
`to be played-out at 24,000 bits per second, the source sends
`the audio data at the rate of 24,000 bits per second. Provided
`that the user Waits 10 seconds, and the receipt of the buffering
`data has not been interrupted, there is enough media data
`stored in the buffer to play for 10 seconds.
`Gaps in the receipt of audio/video data, due to Internet
`sloWdoWns, cause the buffer to deplete. Because transmission
`of audio/video media data to the user takes place at the rate it
`is played out, the user’s buffer level can never be increased or
`
`PAGE 6 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US 8,122,141 B2
`
`3
`replenished While it is playing. Thus, gaps in the receipt of
`audio/video media data inexorably cause the buffer level to
`decrease from its initial level. In time, extended or repeated
`occurrences of these gaps empty the user’s buffer. The audio/
`video material stops playing, and the buffer must be re?lled to
`its original predetermined level before playing of the media
`resumes.
`By Way of illustration in a 10 second pre-buffering sce
`nario, if the data reception stopped the instant that the media
`started playing, it Would play for exactly 10 seconds. Once it
`starts playing, the media data plays out of the buffer as neW
`media data replenishes the buffer. The incoming data rate
`equals the rate at Which the data is played out of the user’s
`buffer, assuming the receipt of data across the Internet is
`unimpeded. If there are no interruptions in the receipt of the
`media data for the duration of the time the user listens to or
`Watches the material, the buffer level remains constant and
`there Will still be 10 seconds of data stored in the media
`player’s buffer When the user stops the player. On the other
`hand, if the media player encounters interruptions totaling 6
`seconds While playing the material, there Would only be 4
`seconds of media data remaining in the buffer When the user
`stopped it. If data reception interruptions at any time during
`the playing exceed 10 seconds, the user’s media player buffer
`becomes exhausted. There is no media data to play, and the
`audio or video stopsia dropout has occurred. At this point a
`softWare mechanism in the media player stops attempting to
`play any more of the material, and starts the buffering process
`again. The media player remains silent until the buffer re?lls,
`at Which time the media player Will once again start playing
`the material.
`There are tWo fundamental types of streaming media: (i)
`material that originates from a source having a real-time
`nature, such as a radio or TV broadcast, and (ii) material that
`originates from a non-real-time source such as from a disk
`?le. An example of non-real-time material might be a piece of
`music stored as a disk ?le, or a portion of a broadcast that
`originally Was real-time, perhaps yesterday’s TV evening
`neWs, and Was recorded into a disk ?le. For purposes of clarity
`Within this document, streaming media of type (i) Will be
`referred to as “broadcast” media, and streaming media of type
`(ii) Will be referred to as “?le based” media.
`Both streaming media types are handled similarly in con
`ventional systems, and both are handled similarly by the
`streaming media buffering system of the present invention.
`The tWo streaming media types are readily distinguished.
`Broadcast streaming media has as its source a system or
`arrangement that by de?nition can only be transmitted to
`users as fast as the material is generated; for example, a disk
`jockey speaking into a microphone. File based media, on the
`other hand, can be transmitted to users at any data rate, since
`there is no inherent time element to a ?le residing on a com
`puter disk. With conventional Internet streaming media sys
`tems for streaming media of either type, media data is trans
`mitted from the server to the user at the rate at Which it Will be
`played out, regardless of the data rate capabilities of the
`connection betWeen the server and the user.
`Conventional streaming media systems may incorporate
`buffering systems for programmatic purposes. For example,
`the system may buffer media data at the server for the purpose
`of packet assembly/disassembly. Media data may also be
`buffered at the server to permit programming conveniences
`such as dealing With chunks of data of a speci?c siZe. Such
`server buffering of media data is not used by conventional
`streaming media systems to mitigate long term Internet per
`formance degradation as described hereinafter.
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`The sending of audio or video ?les via a netWork is knoWn
`in the art. U.S. Pat. No. 6,029,194 to Tilt describes a media
`server for the distribution of audio/video over netWorks, in
`Which retrieved media frames are transferred to a FIFO
`buffer. A clock rate for a local clock is adjusted according to
`the fullness of the buffer. The media frames from the buffer
`are sent in the form of data packets over the netWorks in
`response to interrupts generated by the local clock. In this
`manner, the timing for the media frames is controlled by the
`user to assure a continuous stream of video during editing.
`U.S. Pat. No. 6,014,706 to Cannon, et al. discloses an appa
`ratus and method for displaying streamed digital video data
`on a client computer. The client computer is con?gured to
`receive the streamed digital video data from a server com
`puter via a computer netWork. The streamed digital video data
`is transmitted from the server computer to the client computer
`as a stream ofvideo frames. U.S. Pat. No. 6,002,720, to Yurt,
`et al. discloses a system of distributing video and/or audio
`information Wherein digital signal processing is employed to
`achieve high rates of data compression. U.S. Pat. No. 5,923,
`655, to Veschi et al. discloses a system and method for com
`municating audio/video data in a packet-based computer net
`Work Wherein transmission of data packets through the
`computer netWork requires variable periods of transmission
`time. U.S. Pat. No. 5,922,048 to Emura discloses a video
`server apparatus having a stream control section Which deter
`mines a keyframe readout interval and a keyframe playback
`interval that satisfy a playback speed designated by a terminal
`apparatus. Finally, U.S. Pat. No. 6,014,694 to Aharoni, et al.
`discloses a system and method for adaptively transporting
`video over netWorks, including the Internet, Wherein the
`available bandWidth varies With time.
`There remains a need in the art for a method and system
`that afford immediate and uninterrupted listening/vieWing of
`streaming media by the user.
`
`SUMMARY OF THE INVENTION
`
`The present invention provides a system and method for
`sending streaming media, such as audio or video ?les, via the
`Internet. Immediate playing of the media on a user’s com
`puter is afforded While reducing interruptions in playback due
`to Internet congestion and temporary modem delays due to
`noisy lines. Nearly instantaneous playback is achieved, While
`maintaining protection against playback interruption.
`Delayed starts, heretofore required to provide protection
`against interruption, are avoided. Data loss due to interrup
`tions in the receipt of media data by the media player can be
`recovered While the player continues to play out the audio or
`video material. If the interruptions are so severe as to deplete
`the user’s buffer and stop the play out, the media player Will
`begin to play out again as soon as the media player begins to
`receive media data Without Waiting to ?rst build up the buffer.
`Generally stated, the invention provides a system for dis
`tributing via the Internet streaming media composed of a
`plurality of time-sequenced data elements. The system has a
`server connected to the Internet for transmitting the data
`elements. Associated With the server are a buffer manager and
`a FIFO buffer for storing at least one of the data elements for
`transmission. The buffer manager comprises means for:
`receiving the media data; supplying media data in order to the
`FIFO buffer; supplying the FIFO buffer With a predetermined
`number of data elements; maintaining a pointer into the buffer
`for each user computer indicating the last media data element
`that has been sent to that user, thus indicating the next element
`or elements to be sent; and, once the FIFO buffer is full,
`deleting the oldest data elements in the buffer as neW data
`
`PAGE 7 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US 8,122,141 B2
`
`20
`
`5
`elements are received, said means arranged to maintain the
`pre-determined number of data elements in the FIFO buffer.
`At least one user computer is connected to the server via the
`Internet or other data communications medium.
`This invention presumes the existence of a data communi
`cations transport mechanism, such as the TCP protocol, for
`the reliable delivery of data in an ordered sequence from the
`source of the media data to the server, or from the server to the
`media player softWare of the user computer. Thus, the deliv
`ery of data in the proper sequence is outside the scope of this
`invention.
`The user computer is associated With a media player soft
`Ware incorporating a user buffer and comprises means for
`receiving and storing a predetermined number of media data
`elements Which are received sequentially by the media player,
`playing the data out sequentially as audio and/or video, and
`deleting media data elements from the buffer as they are
`played out. As data is played out, the next sequential data
`elements are received from the server in such a fashion as to
`approximately maintain the predetermined number of data
`elements in the user’s buffer.
`There are tWo types of encoding schemes used for audio
`and video materiali“Variable Bit Rate”iVBR, and “Con
`stant Bit Rate”iCBR. CBR encoding represents the encoded
`media With a constant bit rate per second, regardless of the
`complexity of the material being encoded, for example, if an
`audio source is encoded at 20 kilobits per second at a Constant
`Bit Rate, the media data being produced from the encoding is
`at 20 kilobits per second Whether the audio material is sym
`phonic music or silence. Variable Bit Rate encoding uses a
`variable number of bits to represent sounds, With more bits
`required for complex (symphonic) sounds than for simple
`sounds or silence. The standard encoding scheme used for
`streaming media is CBR because the resulting data rate is
`more predictable than for VBR.
`The server stores a predetermined amount of media data in
`a First-In First-Out (FIFO) buffer in an arrangement that
`receives media data directly or indirectly from a real-time
`source, such as a radio station. For example, the server buffer
`might be set to store up 30 seconds of media data. Because the
`source produces media data in real time, the media data is
`delivered to the server approximately at the rate it is gener
`ated. Of course there can be variability’s in this data delivery
`process due to networking, disk accesses, and so on, causing
`the delivery rate of the media data to be variable over short
`periods of time, typically measured in seconds. But over a
`longer period of time measured in minutes or tens of minutes
`or longer, the media data is delivered from source to server at
`the rate it is generated, and the server in turn provides that
`media data to the FIFO buffer at that same rate. Since CBR
`50
`encoding is normally used for streaming media, the media
`data is generated, received by the server, and provided to the
`buffer approximately at a ?xed rate. Once the buffer is full, for
`each neW data element received into the buffer the oldest data
`element is deleted from the buffer. Once a connection is made
`to a user’s computer, the server sends the media data to the
`user computer’ s buffer in the folloWing manner. First, media
`data is sent to the user at the highest rate that the data con
`nection betWeen the server and the user computer Will support
`until the predetermined amount of data that had been stored in
`the server buffer has been transferred to the user’ s computer.
`Once the buffer has been transferred a steady state condition
`is reached Wherein as each media data element arrives at the
`server, it is immediately sent out to the user computer. In this
`steady state condition, the media data is sent at a rate that
`matches the constant ?ll rate of the server buffer, and is
`received at the same rate by the user computer if there are no
`
`55
`
`65
`
`25
`
`30
`
`35
`
`40
`
`45
`
`6
`interruptions in the transmission of media data betWeen the
`server and the user’s computer. If interruptions have inter
`fered With the arrival of sent media data to the user’s com
`puter, that data may have been “dropped” by routers in the
`Internet and needs to be resent. This causes data to “back up”
`into the server FIFO for that user.
`In one method of operation, the resending of missing data
`is the responsibility of a reliable transport mechanism, such as
`TCP. The server buffer “sends” data by delivering it to the
`transport mechanism. The transport mechanism actually
`“sends” the data across the communications medium, and has
`processes Which determine if all the data that has been sent
`has been received by the destination. If not, missing pieces of
`data are automatically resent to the destination, and are
`arranged to be delivered to the target softWare on the desti
`nation system in an ordered fashion. In the circumstance of
`this invention, the destination is the user computer, and the
`target softWare on the destination system is the media player.
`If the transport mechanism determines that data is missing, it
`retransmits that data to the destination as fast as the connec
`tion betWeen the server and destination Will alloW. The net
`effect of this invention is that all media data to be delivered to
`a user computer is alWays sent as fast as the communications
`medium Will support, either by the server buffer passing
`media data to the transport mechanism, or by the transport
`mechanism delivering or redelivering the media data to the
`user computer. This is enabled by buffering data at the server,
`and is distinctly different from prior art in Which media data
`is only sent from the server to the user computer at the rate at
`Which it is to be played out.
`In another method of operation, the server can use an
`unreliable transport mechanism, such as UDP, and rely on a
`streaming softWare process to manage data delivery and the
`resending of data elements not received by the media player.
`As an example of the preceding description, if the server
`had been set to store 30 seconds of audio in its buffer, When a
`user connects that 30 seconds Worth of media, data is trans
`ferred to the user’s media player buffer as fast as the data
`connection betWeen the tWo Will alloW. The media player can
`begin playing as soon as it has received a very minimum
`amount of data, perhaps comprising only a single packet of
`media data. For ease of understanding, consider the server
`buffer and the media player buffer to be an elastic system that
`betWeen the tWo stores up 30 seconds of audio data. The
`server starts With 30 seconds of buffered audio data Which it
`transfers to the media player until the server has no buffered
`media data and the media player has 30 seconds of buffered
`media data. Regardless of hoW much of the buffered media
`data has been transmitted to the media player, there alWays is
`30 seconds of media data being buffered betWeen the tWo
`locations. Consequently, the audio being played out by the
`media player Will alWays be 30 seconds behind the audio at
`the source. If there Were a media player in the radio station
`studio, an announcer Would hear themselves through the
`media player With a 30 second delay.
`Routinely, once a steady state has been achieved, the next
`data element to be sent is the next sequential data element
`from that Which has already been received by the user’s
`computer buffer. HoWever, if there is more data to be sent than
`at the routine constant ?ll rate, such as in the condition Where
`some media data has been resent by the reliable transport
`layer, the server transport mechanism Will again send the
`buffered media data as fast as the connection betWeen the
`server and the user’s computer Will support. Similarly, if the
`media player buffer begins to deplete or becomes depleted
`due to netWorking interruptions, the server Will attempt to
`send as much data as is necessary to rebuild the user comput
`
`PAGE 8 of 13
`
`PETITIONERS' EXHIBIT 1001
`
`

`

`US 8,122,141 B2
`
`7
`er’s buffer to the proper level. This allows for rebuilding the
`user’ s computer buffer under circumstances Wherein Internet
`interruptions have blocked the normal How of data. When
`compared to conventional systems, Which provide no capa
`bility to rebuild the user’ s computer buffer When data is lost,
`the streaming media buffering system of the present invention
`provides for recovery of lost data elements and the restoration
`of the user’s buffer, even While the user media player contin
`ues to play.
`Under conditions in Which interruptions have interfered
`With the arrival of sent media data to the user’ s computer, data
`loss exceeding certain levels Will cause the transport mecha
`nism software to stop accepting data for transmission from
`the application software, namely the streaming media server
`softWare. Although other arrangements are possible Within
`the scope of this invention, in the preferred embodiment, the
`streaming media server softWare keeps track of the last data
`element in the FIFO buffer that has been “sent” to each user
`using a softWare pointer. An interruption in the ability to send
`media data to a user results in this pointer “backing up” in the
`FIFO in such a Way that the server knoWs from What point in
`the buffer to restart sending data When the transport mecha
`nism again requests data to send. When the server softWare
`receives that noti?cation, it Will begin sending data to the user
`starting from the next data element to send as indicated by the
`pointer, and sending as much data as the transport mechanism
`Will accept. The transport mechanism Will again send this
`data as fast as it can to the user. This process continues until
`the steady state condition is again reached Wherein each data
`element is sent to the user as soon as it arrives from the media
`source.
`In another embodiment, the server is connected to the
`Internet, and to a broadcast media source, such as a radio
`station. A radio station computer is provided With a means for
`receiving media data elements as they are generated by the
`audio and/ or video source, and for transmitting those media
`data elements to the server as they are generated. As before,
`the server provides a buffer manager and a FIFO buffer, and
`provides a means for receiving the sequentially arranged
`media data elements from the broadcast media source and
`storing those data elements in the FIFO buffer. The buffer
`manager comprises means for: supplying the FIFO buffer
`With a predetermined number of data elements; maintaining a
`pointer into the buffer for each user computer indicating the
`last media data element that has been sent to that user, thus
`indicating the next element or elements to be sent; and, once
`the FIFO buffer is full, deleting the oldest data element in the
`buffer as each neW data element is received. Importantly, the
`buffer manager is arranged to maintain the pre-determined
`number of data elements in the FIFO buffer. At least one user
`computer is connected to the server via the Internet or other
`data communications medium.
`The user computer is associated With a media player soft
`Ware incorporating a user buffer and comprises means for
`receiving and storing a predetermined number of media data
`elements, playing the data out sequentially as audio and/or
`video, and deleting media data elements from the buffer as
`they are played out. As data is played out, the next sequential
`data elements are received from the server in such a fashion as
`to approximately maintain the predetermined number of data
`elements in the user’ s buffer. It should be understood that data
`might arrive at the media player out-of-sequence and that
`processes in the media player or the media player buffer
`manager are responsible for properly arranging this data.
`In another embodiment, the server is connected to the
`Internet and provisioned as initially described, and has avail
`able to it ?le based media data as the source material. The ?le
`
`40
`
`45
`
`20
`
`25
`
`30
`
`35
`
`50
`
`55
`
`60
`
`65
`
`8
`based media data can be read by the server Which can deliver
`media data elements to the server FIFO buffer at a constant
`time- sequenced rate, as if the data Were arriving from a broad
`cast media source. As before, the server provides a buffer
`manager and a FIFO buffer, and provides a means for receiv
`ing the sequentially arranged media data elements from the
`?le based media source and storing those

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket