123819/2
`
`
`
`תמרזה
`
`
`
` תרושקת
`
`
`
`תשרב הידמ
`
`
`
`NETWORK MEDIA STREAMING
`
`GEO INTERACTIVE MEDIA GROUP LTD.
`C:29877
`
`
`
` פורג הידממ״עב
`
`
`
`
`
`
`
`
`
`ואג
`
`
` ביטקארטניא
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0001
`
`
`
`
`
`תמרזה
`
`
`
` תרושקת
`
`
`
`תשרב הידמ
`
`
`
`NETWORK MEDIA STREAMING
`
`GEO INTERACTIVE MEDIA GROUP LTD.
`C:29877
`
`
`
` פורג הידממ״עב
`
`
`
`
`
`
`
`
`
`ואג
`
`
` ביטקארטניא
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0001
`
`
`
`29877S4
`
`NETWORK MEDIA STREAMING
`FIELD OF THE INVENTION
`The present invention relates generally to network
`data communications, and specifically to real-time
`multimedia broadcasting over a network.
`BACKGROUND OF THE INVENTION
`In network broadcasting, data are transmitted over a
`network in real time from a single transmitting computer
`to a plurality of clients simultaneously. The network
`may be a LAN, a WAN, an intranet or a public network such
`as the Internet. Network broadcasting is most commonly
`used to stream multimedia data, typically comprising
`images and sound.
`Fig. 1 is a schematic illustration showing a real-
`time broadcasting system 20, as is known in the art. One
`or more input devices 22 (for example, a video camera
`and/or microphone) are used to generate a multimedia data
`stream representing an entertainment or informational
`program to be transmitted to a plurality of clients 30
`via a network 28. Because of bandwidth limitations of
`the network, the data stream from host 22 must first be
`compressed by a real-time encoder 24 and then routed to
`appropriate clients 30 by a broadcast server 26 (since
`not all clients on the network are necessarily intended
`to receive the broadcast).
`Encoder 24 and server 26 typically comprise high-
`cost, dedicated computer systems, such as a Sun Station
`(produced by Sun Microsystems) or a Windows NT server,
`running suitable RealSystem 5.0 software (produced by
`RealNetworks Inc., Seattle, Washington). These dedicated
`systems are required in order to ensure that the data
`stream is distributed and received by clients 30 in real
`time. Similarly, host 22 must typically be connected
`directly to encoder 24 by a high-speed data link or LAN,
`and not via the Internet or other narrowband network.
`1
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0002
`
`
`
`29877S4
`
`Therefore, real-time broadcasting is normally possible
`only for hosts having a suitable, dedicated encoder and
`broadcast server and cannot be offered by Internet
`service providers (ISPs) to their general clientele.
`
`2
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0003
`
`
`
`29877S4
`
`SUMMARY OF THE INVENTION
`of the present
`It is an object of some aspects
`invention to provide substantially continuous, high-
`bandwidth data streaming over a network using common,
`existing server and network infrastructure.
`the
`It is a further object of
`some aspects of
`present invention to provide data broadcasting
`capability, particularly for multimedia data, without the
`need for a dedicated broadcast computer system.
`the
`It is a further object of
`some aspects of
`present invention to provide apparatus and methods for
`data broadcasting at reduced cost by comparison with
`systems known in the art.
`It is still another object of some aspects of the
`present invention to enable a personal computer
`to
`remotely broadcast a multimedia program through an
`Internet
`service provider
`(ISP) using
`common,
`universally-supported Internet communication protocols.
`In preferred embodiments of the present invention, a
`transmitting computer generates a data stream and
`broadcasts the data stream via a network server to a
`plurality of clients. The data stream is divided into a
`sequence of files, each file corresponding to a segment
`or slice of the data, preferably a time slice, wherein
`the data are preferably compressed. Each file is
`preferably assigned a respective slice index.
`The
`transmitting computer uploads the sequence of files to
`the server substantially in real time, preferably using
`an Internet protocol, most preferably the File Transfer
`Protocol (FTP), as is known in the art. The clients
`download the data stream from the server, preferably
`using an Internet protocol, as well, most preferably the
`Hypertext Transfer Protocol (HTTP), which is similarly
`known in the art. The clients use the slice indices of
`the frames to maintain proper synchronization of the
`playback. The division of the data stream into slices
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0004
`
`
`
`29877S4
`
`and the inclusion of the slice indices in the data stream
`to be used by the clients in maintaining synchronization
`allows the broadcast to go on substantially in real time
`without the use of special-purpose hardware.
`In some preferred embodiments of the present
`invention, the data stream comprises multimedia data
`captured or generated by the transmitting computer. The
`term "multimedia" as used in the context of the present
`patent application and in the claims refers to images or
`sound or to data representative of images or of sound or
`a combination thereof. Multimedia image data may include
`still images, video, graphics, animation or any
`combination thereof, including text displayed in
`conjunction therewith. It will be appreciated, however,
`that the principles of the present invention may
`similarly be applied to streaming of other data types.
`Preferably, the transmitting computer compresses the
`frames in the data stream, most preferably using methods
`of image and audio compression such as those described in
`U.S. patent application 08/919,027, which is assigned to
`the assignee of the present patent application and
`incorporated herein by reference. Alternatively, any
`suitable methods of compression known in the art may be
`used. The compressed data are conveyed to the server and
`thence to the clients, which decompress the data.
`In some preferred embodiments of the present
`invention, the transmitting computer and the clients
`monitor the uploading and downloading of data to and from
`the server, respectively, in order to determine the
`amount of time required to convey each slice and to
`verify that the slices are conveyed at a sufficient rate.
`When the data stream comprises multimedia data, the data
`rate should be generally equal to or faster than the rate
`at which the data are generated at the transmitting
`computer.
`
`4
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0005
`
`
`
`29877S4
`
`computer
`Preferably, the transmitting
`and/or the
`FTP
`clients each open a plurality of
`or HTTP links,
`respectively, with the network server.
`The slices are
`over
`different ones
`of
`the
`transferred
`links in
`alternation. Although typically none of the plurality of
`links has sufficient bandwidth on its own to convey the
`entire data stream in real time, the combined bandwidths
`of the plurality of links are generally sufficient for
`this purpose. Preferably, each of the links is monitored
`to determine its specific data transfer rate. If the
`transfer rate of any of the links is below a
`predetermined minimum, that link is preferably closed,
`and a new link is opened in its place.
`Additionally or alternatively, the transmitting
`computer monitors the bandwidth of the data stream that
`it is uploading to the server, and compares the data
`stream bandwidth to a known or estimated bandwidth of the
`link or links between the transmitting computer and the
`server. The transmitting computer preferably compresses
`the data stream at a compression ratio that is adjusted
`so as to match the data stream bandwidth to the available
`link bandwidth, using methods described, for example, in
`the above-mentioned U.S. patent application 08/919,027.
`There is therefore provided, in accordance with a
`preferred embodiment of the present invention, a method
`for real-time broadcasting from a transmitting computer
`to one or more client computers over a network,
`including:
`providing at the transmitting computer a data stream
`having a given data rate;
`dividing the stream into a sequence of slices, each
`slice having a predetermined data size associated
`therewith;
`encoding the slices in a corresponding sequence of
`files, each file having a respective index; and
`
`5
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0006
`
`
`
`29877S4
`
`uploading the encoded sequence to a server at an
`upload rate generally equal to the data rate of the
`stream, such that the one or more client computers can
`download the encoded sequence over the network from the
`server at a download rate generally equal to the data
`rate.
`
`Preferably, dividing the stream into the sequence of
`slices includes dividing the stream into a sequence of
`time slices, each having a predetermined duration
`associated therewith.
`Preferably, uploading the sequence includes
`comparing the upload rate to the data rate and adjusting
`the upload rate responsive to the comparison. Further
`preferably, encoding the stream includes compressing data
`in the stream at a desired compression ratio, and
`adjusting the upload rate includes changing the
`compression ratio. Alternatively or additionally,
`adjusting the upload rate includes adjusting the size of
`one or more of the slices.
`Preferably, uploading the sequence includes opening
`a plurality of file transfer links between the
`transmitting computer and the server, each link
`characterized by a respective link data rate, and
`uploading different files in the sequence over different
`ones of the plurality of links. Further preferably,
`opening the plurality of links includes opening links
`such that the data rates of the links taken together are
`sufficient to upload the sequence at the upload rate
`generally equal to the data rate.
`Preferably, uploading the encoded sequence includes
`most
`uploading a sequence
`using an Internet Protocol,
`preferably using FTP.
`the
`downloading
`Preferably, the
`includes
`method
`most
`encoded sequence using an
`protocol,
`Internet
`preferably HTTP, over the network from the server to the
`one or more client computers. Preferably, the one or
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0007
`
`
`
`29877S4
`
`more client computers decode the encoded sequence and
`play back the data stream responsive to the indices of
`the files, at a replay rate generally equal to the data
`rate.
`
`Preferably, uploading the sequence includes
`uploading and updating an index file containing the index
`of the file in the sequence that was most recently
`uploaded, and the one or more client computers read the
`index file to play back the sequence. In a preferred
`embodiment, downloading the encoded sequence includes
`selecting a file in the sequence earlier than the file
`whose index is contained in the index file and
`downloading at least a portion of the encoded sequence of
`files beginning with the selected file.
`Preferably, the one or more client computers include
`a plurality of client computers, and downloading the
`sequence includes downloading to the plurality of client
`computers substantially simultaneously.
`Preferably, downloading the sequence includes
`opening a plurality of download links between one of the
`client computers and the server, each link characterized
`by a respective link data rate, and downloading different
`files in the sequence over different ones of the
`plurality of links. Most preferably, opening the
`plurality of links includes opening links such that the
`data rates of the links taken together are sufficient to
`download the sequence at the download rate generally
`equal to the data rate.
`Preferably, opening the plurality of links includes
`monitoring the data rates of the links and opening a new
`link in place of one of the links having a data rate
`lower than a predetermined level.
`In one preferred embodiment, opening the new link
`includes retransmitting at least one of the files in the
`sequence, wherein the at least one of the files was
`
`7
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0008
`
`
`
`29877S4
`
`incompletely transmitted over the one of the links having
`the data rate lower than the predetermined level.
`In another preferred embodiment/ opening the new
`link includes dropping at least one file out of the
`sequence, wherein the at least one of the files was
`incompletely transmitted over the one or more of the
`links having the data rate lower than the predetermined
`level.
`Preferably, the data stream includes multimedia
`
`data.
`
`There is further provided, in accordance with a
`preferred embodiment of the present invention, apparatus
`for real-time broadcasting of a data stream having a
`given data rate over a network, including:
`a transmitting computer, which divides the stream
`into a sequence of slices, each slice having a
`predetermined data size associated therewith, and encodes
`the slices in a corresponding sequence of files, each
`file having a respective index, and
`which uploads the encoded sequence to a server at an
`upload rate generally equal to the data rate, such that
`one or more client computers can download the encoded
`sequence over the network from the server at a download
`rate generally equal to the data rate.
`Preferably, the transmitting computer compares the
`upload rate to the data rate and adjusts the upload rate
`responsive to the comparison. Most preferably, the
`transmitting computer compresses the data at a
`compression ratio which is varied responsive to the
`comparison. Additionally or alternatively, the
`transmitting computer adjusts the size of one or more of
`the slices responsive to the comparison.
`Preferably, the transmitting computer opens a
`plurality of links between the transmitting computer and
`the server, each link characterized by a respective data
`rate, and transmits different ones of the sequence of
`8
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0009
`
`
`
`29877S4
`
`files over different ones of the plurality of links.
`Most preferably, the transmitting computer opens the
`plurality of links such that the data rates of the links
`taken together are sufficient to upload the sequence at
`the upload rate generally equal to the data rate.
`Further preferably, the transmitting computer monitors
`the data rates of the links and opens a new link in place
`of one of the links whose data rate is lower than a
`predetermined level.
`Preferably, the transmitting computer uploads the
`encoded sequence using an Internet upload protocol, most
`preferably FTP.
`Preferably, the one or more client computers decode
`the encoded sequence and play back the data stream
`responsive to the indices thereof, at a data replay rate
`generally equal to the data rate. Preferably, the one or
`more client computers download the encode sequence using
`an Internet download protocol, most preferably HTTP.
`Preferably, the one or more client computers include
`a plurality of client computers, which download the
`sequence substantially simultaneously.
`Preferably, the network includes the Internet.
`Further preferably, the data stream includes
`multimedia data, and the predetermined data size of each
`of the slices corresponds to a time duration of the
`slice.
`The present invention will be more fully understood
`from the following detailed description of the preferred
`embodiments thereof, taken together with the drawings in
`which:
`
`9
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0010
`
`
`
`29877S4
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`Fig. 1 is a schematic illustration of a computer
`broadcast network, as is known in the art;
`Fig. 2 is a schematic illustration of a computer
`broadcast network, in accordance with a preferred
`embodiment of the present invention;
`Fig. 3A is a block diagram that schematically
`illustrates a data structure of a broadcast sequence, in
`accordance with a preferred embodiment of the present
`invention;
`Fig. 3B is a block diagram that schematically
`illustrates an index file associated with the data
`structure ' of Fig. 3B, in accordance with a preferred
`embodiment of the present invention;
`Fig. 3C is a schematic illustration of a user
`interface graphic, for use in conjunction with the data
`structure of Fig. 3A, in accordance with a preferred
`embodiment of the present invention;
`Fig. 4 is a block diagram that schematically
`illustrates a network connection between a transmitting•
`computer and a network server, for use in broadcasting of
`a data sequence, in accordance with a preferred
`embodiment of the present invention;
`Fig. 5 is a flow chart that schematically
`illustrates a method of uploading broadcast data from a
`transmitting computer to a server, in accordance with a
`preferred embodiment of the present invention;
`Fig. 6 is a flow chart that schematically
`illustrates a method of downloading broadcast data from a
`server to a client, in accordance with a preferred
`embodiment of the present invention;
`Fig. 7 is a flow chart that schematically
`illustrates a method for preparing data files for
`transmission, in accordance with a preferred embodiment
`of the present invention;
`
`10
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0011
`
`
`
`29877S4
`
`Fig. 8 is a flow chart that schematically
`illustrates a method of file transfer, in accordance with
`a preferred embodiment of the present invention; and
`Fig. 9 is a flow chart that schematically
`illustrates a method for monitoring network links, in
`accordance with a preferred embodiment of the present
`invention.
`
`11
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0012
`
`
`
`29877S4
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
`Reference is now made to Fig. 2, which is a
`schematic illustration of a computer system 32 for remote
`broadcasting of a multimedia sequence over a network 28,
`in accordance with a preferred embodiment of the present
`invention. System 32 comprises a transmitting computer
`34, which generates the sequence, a plurality of clients
`30, and a network server 36, all of which communicate
`over network 28, preferably using the well-known Internet
`Protocol (IP) . Computer 34 preferably receives
`audiovisual input from input devices 22, although data
`inputs of other types may be generated at or by computer
`34 using any suitable means known in the art.
`Network 28 preferably comprises the Internet,
`although it may equally comprise a LAN, WAN, intranet or
`other computer network as is known in the art. Computer
`34 and clients 30 preferably comprise conventional
`personal computers or workstations. Server 36 may
`comprise any suitable type of computer or computer
`system, for example, a Sun Microsystems UltraSPARC
`station or a Windows NT server, as are commonly used by
`Internet Service Providers (ISPs) . In any case, it is
`noted that transmitting computer 34 can be remotely
`located relative to server 36, and that the server need
`not be equipped with any special-purpose hardware or
`software for real-time data broadcasting, unlike
`broadcast systems known in the art, such as the real-time
`encoder and broadcast server shown in Fig. 1.
`After preparing the multimedia sequence, computer 34
`uploads the sequence over network 28, preferably using
`the Internet File Transfer Protocol (FTP).
`Alternatively, other Internet protocols may be used, such
`as the TCP/IP, UDP or RT(x) protocols, which are known in
`the art. Preferably, the data in the sequence are
`compressed, although compression is not essential to
`implementation of the present invention. The sequence is
`12
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0013
`
`
`
`29877S4
`
`preferably generated and compressed in real time, and
`could comprise, for example, an interview program or an
`entertainment or sports event, although a prerecorded
`sequence may similarly be broadcast in this manner.
`Computer 34 is preferably equipped with suitable software
`for preparing and compressing the multimedia sequence.
`For example, for audio data, the computer may typically
`run GSM 6.10 standard audio compression software,
`operating at a sample rate of 8 kHz, with 16 bits/sample.
`Some useful techniques for preparing, compressing and
`transmitting multimedia sequences are described in U.S.
`patent application 08/594,890 and in the above-mentioned
`U.S. patent application 08/919,027, both of which are
`assigned ' to the assignee of the present patent
`application and are incorporated herein by reference.
`Clients 30 connect to server 36 and receive the
`multimedia sequence, substantially in real time. Clients
`30 preferably download the sequence using the Hypertext
`Transfer Protocol (HTTP), although other Internet
`protocols may also be used, as noted hereinabove with
`reference to uploading by computer 34. Since FTP and
`HTTP are supported by substantially all network servers,
`server 36 need not include any special-purpose
`broadcasting hardware or software, as noted above.
`Similarly, because HTTP is supported by substantially all
`modern Web browsers, clients 30 will typically need only
`add a Java applet or plug-in to their existing Web
`browsers, as described further hereinbelow, in order to
`receive and play back the broadcast.
`Fig. 3A is a block diagram that schematically
`illustrates the structure of a stream of broadcast data
`40 produced by computer 34, typically corresponding to a
`multimedia data sequence, in accordance with a preferred
`embodiment of the present invention. Data stream 40
`comprises a series of data slices 42, 44, 46, 48, etc.
`Each slice contains a segment of video and/or audio data,
`13
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0014
`
`
`
`29877S4
`
`corresponding to a respective, successive time interval
`labeled T!, T2, T3, etc. The data are
`preferably
`compressed, as described further hereinbelow. Computer 34
`stores each slice as a corresponding file,
`having a
`running slice index 1, 2, 3... N. Preferably, each file
`also includes one or more time stamps, indicating a real
`time at which the data in the file were recorded or an
`elapsed time relative to the beginning of stream 40. The
`files are uploaded to server 36, such that while any
`given slice (other than first slice 42) is being created,
`one or more preceding slices are in the process of being
`uploaded.
`Computer 34 monitors the time codes as file 40 is
`transmitted, and clients 30 similarly monitor the time
`codes as the file is received, in order to ensure that
`the transmission or reception is "keeping up" with the
`input of the data to the computer. In the event that a
`lag is detected, steps are taken to increase the data
`transmission or reception rate, as described further
`hereinbelow. For example, as shown in Fig. 3, time
`intervals T!, T2, T3, etc., are not all equal, but rather
`are adjusted by computer 34 in response to the
`transmission rate.
`Computer 34 continues to upload files 42, 44, 46,
`etc., until data stream 40 is finished or terminated by a
`user of computer 34. All of the files in the data stream
`may be saved on server 36 for any desired period of time,
`as long as the server has sufficient free memory that is
`accessible to computer 34. Typically, however, the
`memory available on server 36 is limited, and files 42,
`44, 46, etc., will be stored on the server and erased
`therefrom in a "first-in-first-out" sequence.
`Fig. 3B is a block diagram that schematically
`illustrates an index file 50, which is created by
`computer 34, and is uploaded to server 36, in accordance
`with a preferred embodiment of the present invention.
`14
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0015
`
`
`
`29877S4
`
`The index file comprises a slice ID 52, indicating the
`index of the file in data stream 40 that was most
`recently uploaded by computer 34. Each time a new file
`42, 44, 46, etc., is uploaded, ID 52 in file 50 on server
`36 is updated. Preferably, ID 52 holds the file name of
`the new file, wherein the name typically comprises a
`string followed by the index of the file. When one of
`computers 30 connects to server 36 and begins to download
`the data stream, it first reads the index file in order
`to identify at what point in stream 40 to begin and to
`begin receiving the data stream substantially in real
`time, preferably with only a minimal lag, as it is
`transmitted from computer 34. Alternatively, a user of
`one of computers 30 may choose to begin downloading data
`stream 40 from an earlier point in time than that
`indicated by ID 52.
`Index file 50 may further include a message 54,
`which is read by computers 30 when they connect to server
`36 to download data stream 40 or, alternatively or
`additionally, at any time the message is updated by
`computer 34. The message contains parameters relating
`generally to the data stream and/or instructions to
`computers 30, for example, "transmission paused."
`Fig. 3C is a schematic representation of a user
`interface graphic "slider" 56, available to users of
`computers 30, in accordance with a preferred embodiment
`of the present invention. Slider 56, which is preferably
`displayed on the screens of computers 30, includes a bar
`56 and a movable indicator 58. The symbols J, J+l,
`J+2, ... N in the figure are the indices of the slices of
`stream 40 that are stored on server 36, wherein N is the
`index of the most recent slice, and J is the index of the
`earliest stored slice. J may indicate the first slice in
`the sequence, if all of the files are stored on server
`36, or it may be the earliest file not yet erased. (The
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0016
`
`
`
`29877S4
`
`indices are marked in the figure on bar 56 for clarity,
`and need not actually be shown on the computer screen.)
`When one of computers 30 reads index file • 50 and
`begins to download stream 40, indicator 58 preferably
`marks the most recent slice, as shown in Fig. 3C. This
`is the point at which the download will begin, unless the
`user of the computer chooses otherwise. If the user
`wishes to begin the download at an earlier point, he may
`move indicator 58 to the left along bar 56 to that point,
`preferably using a mouse or other pointing device, as is
`known in the art. Indicator 58 may be moved back and
`forth along bar 56 to jump back and forth along stream
`40.
`
`Fig. 4 is a block diagram that schematically
`illustrates communication between computer 34 and server
`36 over network 28, in accordance with a preferred
`embodiment of the present invention. Computer 34 must
`ensure that there is sufficient communication bandwidth
`between the computer and the server, particularly when
`network 28 includes an Internet connection, which may be
`slow and subject to bottlenecks. Therefore, the computer
`preferably opens a plurality of links, each link having
`its own URL (Uniform Resource Locator). Preferably, five
`links 60, 62, 64, 66 and 68 are opened and operate
`simultaneously over a single modem line. Alternatively,
`each link may be routed differently from the other links,
`over a different telephone line and/or through different
`Internet nodes. Files 42, 44, 46, 48, etc., in stream 40
`are transmitted respectively over links 60, 62, 64, 66
`and 68 in successive alternation, so that at any given
`time (except at the very beginning of the sequence) up to
`five files are transmitted in parallel. Alternatively,
`more than five links may be opened, so that more than
`five files may accordingly be transmitted in parallel.
`Preferably, computer 34 monitors the rate of data
`being transmitted over each of links 60, 62, 64, etc.,
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0017
`
`
`
`29877S4
`
`and allocates files 42, 44, 46, 48, etc., according to
`the data rates. The sizes of the files may be varied by
`adjusting slice durations T]_, T2, T3, etc., and a
`relatively greater volume of data may be transmitted
`through links exhibiting relatively greater data rates.
`The bandwidth open for transmission between computer 34
`and server 36 is effectively roughly equal to a sum of
`the bandwidths of the plurality of open links. The
`number of links that are actually opened between computer
`34 and server 36 may be less than or greater than the
`five links shown in the example of Fig. 4, depending on
`the available data rates of the open links, compared with
`the rate of data in stream 40. Preferably at least two
`links are opened, so that preparation and transmission of
`files 42, 44, 46, 48, etc., may be toggled back and forth
`between the links. A similar technique is preferably
`employed by clients 30.
`Fig. 5 is a flow chart that schematically shows an
`overview of operations of computer 34 in preparing and
`transmitting data stream 40 over network 28, in
`accordance with a preferred embodiment of the present
`invention. Details of some of the steps in the operation
`are shown in Figs. 7-9 and described further with
`reference thereto. Exemplary programs for carrying out
`the functions illustrated in Fig. 5 are incorporated
`herein in a software appendix, which is described further
`hereinbelow.
`To begin the broadcast, computer 34 connects to
`server 36, preferably opening the plurality of links
`shown in Fig. 4. Broadcast data are then input to the
`computer, for example, from input devices 22, or from a
`video, audio or animation sequence stored on disk or
`tape. The data are compressed at step 80, and are then
`"sliced" at step 82 into files 42, 44, 46, 48, etc., as
`shown in Fig. 3A. Computer 34 conveys file 40 to server
`36 over links 60, 62, 64, 66 and 68, as described above.
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0018
`
`
`
`29877S4
`
`preferably using FTP, at step 84. Each time a new file
`is uploaded to the server, index file 50 (Fig. 3B) is
`updated, at step 86.
`For each link that is open, computer 34 checks the
`link function at step 88, preferably by timing the
`transfer of the respective files being transmitted over
`the link. In the event that one of the links, for
`example, link 60 as shown in Fig. 4, is not responding or
`is responding unacceptably slowly, computer 34 breaks the
`link. The file being transmitted over the broken link
`may be retransmitted over another link. Alternatively,
`the file may be dropped from the transmission,
`particularly in the case of a real-time multimedia
`broadcast,׳ in which data arriving at one of computers 30
`will generally tend to disrupt reception of the
`broadcast. When link 60 is broken, a new link, for
`example, link 70, is opened in its stead, as described
`further hereinbelow with reference to Fig. 8.
`Alternatively or additionally, the encoding (step 80) or
`slicing (step 82) of the data may be adjusted, as
`described hereinbelow with reference to Fig. 7. This
`process continues until the broadcast program is
`completed.
`Fig. 6 is a flow chart illustrating the operation of
`clients 30 in downloading and playing back data stream 40
`transmitted by computer 34, in accordance with a
`preferred embodiment of the present invention. The
`operation of client is controlled by a Java applet, which
`may be downloaded from server 36, and includes facilities
`for carrying out the steps shown in Fig. 6, as well as
`for error detection and, optionally, correction in
`communications received by the clients and for other
`functions known in the art. A sample applet of this sort
`is incorporated herein in the software appendix, as
`further described hereinbelow.
`
`Petitioner's Exhibit 1113
`Google LLC v. WAG Acquisition, IPR2022-01413
`Page 0019
`
`
`
`29877S4
`
`Each client 30 connects to server 36, preferably
`using multiple HTTP links, in a manner similar to that
`shown and described above with reference to Fig. 4.
`Typically, client 30 opens two HTTP links, over which
`files 42, 44, 46, etc., are downloaded in successive
`alternation, but as in the case of transmitting computer
`34, a greater or lesser number of links may similarly be
`opened. The client first reads index file 50 (Fig. 3B) ,
`and graphic 56 (Fig. 3C) is displayed by the client, so
`that a user can decide and indicate at which slice of
`data stream 40 to begin downloading. Responsive to a
`user input, client 30 selects an appropriate starting
`slice and begins to download and decode (decompress)
`files 42, 44, 46, etc.
`In the case of a multimedia
`stream, client 30 reconstructs and outputs the multimedia
`data for the appreciation of a user. Time stamps in the
`data stream are used to synchronize the data, so that the
`multimedia sequence is played back just as it was input
`at computer 34, preferably with only a minimal necessary
`transmission and decoding delay.
`Client 30 preferably mo
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
