WO 01/080558
`
`PCT/US01/40452
`
`hikewise,
`
`if the TCP connection fails 250 to retrieve a
`
`frame 235 then an attempt to establish a HTTP connection 225
`
`is made. Alternatively, more than one attempt to establish a
`
`TCP connection will be made. Further attempts to establish a
`
`connection are made with progressively narrower transports
`
`until the transport mode with a narrowest acceptable
`
`bandwidth has been reached. For example, a HTTP connection.
`
`Attempts to establish this transport mode will be continue
`
`until a connection is established, 240/255. At this point it
`
`10
`
`is assumed that the server is down or the network has
`
`failed. When the server comes up or the network improves,
`
`video will begin streaming once the connection has been
`
`established.
`
`In an alternative embodiment,
`
`the transport
`
`mode with the narrowest acceptable bandwidth will be
`
`15
`
`attempted a specified number of times.
`
`Once a successful video connection has been established
`
`and an audio format has been selected, an audio connection
`
`will be made and display the data will begin 260.
`
`Tf at any point a connection fails 265, a connection
`
`20
`
`will be attempted'with the next bandwidth, for example from
`
`UDP to TCP. While in the alternative transport mode,
`
`the
`
`mode with a lower bandwidth, periodic attempts to establish
`
`a connection with the original transport will be made. No
`
`user intervention is needed during operation of the method.
`
`-~16-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02031
`EXHIBIT 1003 - PAGE 02031
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`Alternatively, if the connection is maintained,
`
`the
`
`datagram frame counter is incremented 280. A request is then
`
`made for the next packet based on the frame counter value
`
`from the server. The steaming video data will continue until
`
`the client terminates the connection with the server.
`
`If displaying a stream on-demand,
`
`the client is given
`
`the ability to fast forward,
`
`rewind, and jump to arbitrary
`
`parts of the stream. A clock is also displayed indicating
`
`the current location in the stream. The client initially
`
`10
`
`sends a query to the server requesting the length of the
`
`stream in frames. Proceeding with each frame,
`
`the server
`
`sends the frame number, allowing the client’s clock to
`
`remain accurate regardless of the speed of the, stream. When
`
`the user wishes to fast forward,
`
`rewind, or jump to a
`
`15
`
`specific location in the stream, it sends a request with the
`desired target frame number to the server. The server
`
`responds by seeking to the requested frame number and
`
`streaming from there. All other functions of rate adaption
`
`and protocol selection operate as normal.
`
`20
`
`An advantage to the present invention, related to the
`
`client’s ability to move on the stream,
`
`is error resilience.
`
`That is, since each video frame is independent, if an error
`
`occurs in a frame the invention can either attempt to fix
`
`the error or drop the frame. When a frame is dropped,
`
`the
`
`25
`
`invention requests the next frame and preserves the
`
`-17-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02032
`EXHIBIT 1003 - PAGE 02032
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`continuity of the video and/or audio display. This is
`
`especially advantageous in devices having limited processing
`
`power, and therefore,
`
`lacking the resources to fix errors.
`
`Having described the role of the client above,
`
`the
`
`method will described in reference to various types of
`
`capture. Other types of capture may also be implemented in
`
`the present invention.
`
`The server may capture a thread 305 from a specified
`
`source, e.g., a local capture card. Example of a local
`
`10
`
`capture card include the SunVideoPlus Osprey and the
`
`SunVideo (sun) capture board.
`
`In this instance,
`
`the server
`
`makes use of native Solaris threads to achieve rate-adaptive
`
`connections to the clients. A thread is a placeholder
`
`information associated with a single use of a program that
`can handle multiple concurrent users. From the program's
`
`15
`
`point-of-view, a thread is the information needed to serve
`one individual user or a particular service request. If
`
`multiple users are using the program or concurrent requests
`
`from other programs occur, a thread is created and
`
`20
`
`maintained for each of them. The thread allows a program to
`
`know which user is being served as the program alternately
`
`gets re-entered on behalf of different users. One way thread
`
`information is kept is by storing it in a special data area
`
`and putting the address of that data area in a register. The
`
`25
`
`OS always saves the contents of the register when the
`
`-18-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02033
`EXHIBIT 1003 - PAGE 02033
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`program is interrupted and restores it when it gives the
`
`program control again.
`
`On startup,
`
`the server creates two threads which
`
`capture video 300 and audio 400 from the specified source.
`
`The server places the captured data 310 into a shared area
`
`of memory 315 which is accessible to all other threads
`
`within the server. Other threads are created which accept
`
`incoming requests for each transport type. These incoming
`
`requests for each client are handled as part of a non-
`
`10
`
`blocking loop. Each transport type is handled differently.
`
`For example, for UDP video 325 connections,
`
`the non-
`
`blocking loop accepts and services connections. Since UDP is
`
`“connectionless,” there is no need to maintain a persistent
`
`connection to the client and each client connection is
`
`15
`
`really a request for a single frame. The thread receives a
`
`single byte datagram from a client 340,
`
`immediately
`
`retrieving 355 and sending 370 back the frame currently
`
`stored in the shared memory segment 315. A datagram is a
`
`self-contained,
`
`independent entity of data carrying
`
`20
`
`sufficient information to be routed from the source to the
`
`destination computer without reliance on earlier exchanges
`
`between this source and destination computer and the
`
`transporting network. This process continues indefinitely.
`
`Since sending a UDP datagram is a non~blocking
`
`25
`
`operation,
`
`the server need only have one thread. Thus,
`
`the
`
`-19-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02034
`EXHIBIT 1003 - PAGE 02034
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`amount of CPU time and memory required from UDP is
`
`drastically less than that needed for other connections.
`
`Another example is TCP connections 330. The server
`
`waits for a new connection to be established with a client
`
`345. A non-blocking loop accepts incoming requests. The
`
`client corresponding to the requests are arranged ina
`
`connection pool list. Since TCP is a connected protocol, an
`
`independent thread is then created to service 360 each
`
`elient. The service threads act like the UDP thread,
`
`10
`
`awaiting 375 a single byte (request)
`
`from the client,
`
`the
`
`requested frame is retrieved 385 by the server from the
`
`shared memory 315. The retrieved frame is then sent 390 to
`
`the client.
`
`The above two examples are rate adaptive solutions. By
`
`15
`
`allowing the clients to control the flow of video frames
`
`rather than simply pushing each frame to each client as it
`
`is captured, data bottlenecks typically associated with
`
`streaming media over the Internet are eliminated.
`
`As an illustration,
`
`two desktop PCs are connected to a
`
`20
`
`server.
`
`The first by LOOMbps Ethernet,
`
`the second by a
`
`28.8Kbps dialup Internet connection.
`
`The 100Mbps machine
`
`will receive video at the rate it is captured, up to 30fps.
`
`The rate of speed of the video is due in great part to the
`
`available bandwidth,
`
`the 100Mbps sends out frame requests to
`
`25
`
`the server fast enough to allow for a 30 fps stream.
`
`~20-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02035
`EXHIBIT 1003 - PAGE 02035
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`However,
`
`the 28.8Kbps machine requires more time to receive
`
`each frame and therefore sends out frame requests less
`
`frequently.
`
`Thus the rate of speed is about 3 to 4fps, and
`
`both machines will be at the same place in the stream.
`
`The
`
`illustration method of the present invention accomplishes
`
`this through client side requests for current frames.
`
`These
`
`requests may or may not be for the next sequential frame.
`
`Comparing the machines,
`
`the 100Mbps machine will show a
`
`higher quality video, while the 28.8Kbps machine will appear
`
`10
`
`to be skipping frames in order to maintain a real time
`
`stream.
`
`This approach has several advantages over conventional
`streaming methods. Current methods require re-encoding the
`
`video at several frame rates in order to support users with
`
`15
`
`different bandwidth availability. The user is also required
`
`to select a rate beforehand that is appropriate for their
`
`connection.
`
`In contrast,
`
`the illustrative method according
`
`to the present invention needs only one rate of capture and
`
`encoding. A user no longer needs to know anything about
`
`20
`
`their network bandwidth. The user will connect to the stream
`
`at a rate which adapts itself to the environment.
`
`Additionally, degraded network conditions will not create a
`
`bottleneck and will not cause the stream to fall behind real
`
`time, rather the frame rate will decrease and more frames
`
`25
`
`will be skipped. When conditions improve, so will the frame
`
`-21-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02036
`EXHIBIT 1003 - PAGE 02036
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`rate. Further,
`
`this approach will take advantage of high-
`
`bandwidth consumer access devices, such as xDSL and 38GHz
`
`wireless connections without any changes or updating the
`
`server of client.
`
`Other transport modes are supported by the invention,
`
`for example, HTTP 335. HITP is a one-way protocol and thus
`
`cannot perform true rate adaption. It is included for
`
`clients that do not have UDP, TCP, or another transport
`
`available to them. This may be due to a network firewall, or
`
`10
`
`a packet filter for example. Further,
`
`some Internet Service
`
`Providers (ISP) may not support connections on certain
`
`ports, or not support UDP at all. HTTP connections are
`
`achieved through the use of an external program which is
`
`activated by a web server 500, e.g.
`
`common gateway interface
`
`15
`
`(CGI). A main server creates one thread to accept and
`
`service connections from this external program via local
`
`UNIX domain sockets and UDP 505. Although UDP is used here,
`it is only for local redirection of frames from the main
`
`server to the CGI. The server waits for a CGI request 350.
`
`20
`
`The CGI requests frames at a steady rate from the main
`
`server 510. As the main server retrieves frames 365 from the
`
`shared memory 315,
`
`the frames are re-broadcast to the client
`
`380 back through the web server 520 via HTTP. To avoid
`
`bottlenecks,
`
`from the audio push 525,
`
`this transport mode
`
`-22-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02037
`EXHIBIT 1003 - PAGE 02037
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`transmits 380/515 at a default rate of 1fps in order to
`
`remain real time regardless of available bandwidth.
`
`Another capture can be from a local file which is
`
`looped. This method obtains video and audio data from a
`
`single file that has been pre-encoded from a capture board
`
`and stored on the server. It operates exactly as above and
`
`uses the exact same thread structure. Data is read in from
`
`the specified file and placed into the shared memory
`
`segments at the rate it was encoded. When the end of the
`
`10
`
`file is reached, it re-starts from the beginning.
`
`Still another capture can be had from a local file on-
`
`demand. This method deals with more than one source of
`
`audio/video data being sent to all clients. Each client
`
`needs its own unique copy of the server which then acts as
`
`15
`
`described above using the requested file. This is
`
`accomplished by creating another layer of threads which
`
`create entire server sets of threads for each client. While
`
`this creates a high amount of overhead,
`
`the data is being
`
`delivered in an compressed and encoded state,
`
`therefore it
`
`20
`
`ig not necessary to make deliveries in real time.
`
`In
`
`addition,
`
`the server returns the number of frames in the
`
`stream to the client as well as the frame number of each
`
`frame sent,
`
`therefore,
`
`the client’s clock remains accurate.
`
`The server also receive requests from the client indicating
`
`25
`
`that it wishes to jump forward of backward to a specific
`
`-23-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02038
`EXHIBIT 1003 - PAGE 02038
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`frame,
`
`the server seeks to this location in the file and
`
`continues streaming.
`
`Yet another capture is from a remote IP address,
`
`according to this method the server receives data from
`another server on a remote machine. The remote machine may
`
`be located anywhere on the network that is accessible from
`
`the local machine’s network. The local server acts as a
`
`Single client to the remote server, and pulls a stream from
`
`the remote server in the same rate-adaptive fashion as the
`
`10
`
`Java client. The local server then places the data into its
`
`shared memory buffers, and re-broadcasts it as if it were
`
`being captured locally. All other functions of the local
`
`server operate as normal.
`
`Because the local server is acting as a regular client,
`
`15
`
`it does not matter how the remote server is captures data,
`
`it can be from any of the methods described above. It can
`
`even be capturing its data from another remote server,
`
`allowing for server chains to be created that, for example,
`
`re-broadcast a source feed on different networks.
`
`20
`
`Like video 300, audio data 400 may be transported by
`
`the methods described above: UDP 440, TCP 445, and HTTP 450.
`
`However, it is pushed data. As new audio data is captured
`
`410, it is immediately sent out to all clients 430. This
`allows for a steady audio stream which will inherently be in
`
`25
`
`syne with the video played in real time according to the
`
`-24-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02039
`EXHIBIT 1003 - PAGE 02039
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`invention. The server also attempts to adapt the streamed
`
`audio to the clients available bandwidth. This is
`
`accomplished by the server making available multiple types
`
`of audio simultaneously, for example,
`raw uncompressed 410,
`Global System for Mobile communication (GSM) encoded audio
`
`415, and G.728 encoded audio 420 (G728 is specified in ITU-T
`
`recommendation G.728,
`
`"Coding of speech at 16Kbit/s using
`
`low-delay code excited linear prediction") . Uncompressed
`
`audio 410 occupies 64k of bandwidth, G.728 420 occupies
`
`10
`
`16Kbps of bandwidth, and GSM 415 occupies 13Kbps of
`
`bandwidth. The client times the amount of time between two
`
`frames 265, for example,
`
`the second and third frames, and
`
`based on this time selects the appropriate available audio
`
`format 270. The server creates a thread 435 to accept
`
`15
`
`incoming audio connections via each of the available
`
`transport modes: UDP 440, TCP 445, and HTTP 450. The server
`
`waits for a new connection 455 a, b, c to be established by
`
`a client. Upon comnection,
`
`the client sends preferred audio
`
`format
`
`information to the server 460 a, b, c. The server
`
`20
`
`then creates a service thread 275/465 a, b, c, for the
`
`client which delivers audio in the requested format. These
`
`service threads wait for a signal
`
`from the corresponding
`
`audio encoding thread 470a, b, c,
`
`that more audio has become
`
`available. The server retrieves audio data from a selected
`
`25
`
`buffer 475a, b, c,
`
`then the selected buffer is sent to the
`
`-25-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02040
`EXHIBIT 1003 - PAGE 02040
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`client 285/480a, b, c, and immediately wait for another
`
`Signal 470a, b, c. HTTP connections will automatically
`
`default to the lowest bandwidth signal, since a degraded
`
`connection is assumed.
`
`Advantageously,
`
`the system and method according to an
`
`illustrative embodiment of the invention functions in low
`
`bit rate environments, at about 9.6 Kbps, and suffers no
`
`degradation even during a transmission over a 14.4 Kbps
`
`network. Theoretically there is no upper bound as the
`
`10
`
`system utilizes an adaptive bandwidth method. That is,
`
`the
`
`system scales the data stream to the available bandwidth so
`
`that as bandwidth increases the stream rate will increase
`
`accordingly. The flow of data from the server to the client
`
`is intelligently managed so as to completely eliminate
`
`_ 15
`
`network bottlenecks traditionally associated with streaming
`
`media. This is especially beneficial in wireless
`
`environments where available bandwidth may be limited or
`
`inconsistent. The end user is allowed to receive multimedia
`
`data without fore knowledge of the available bandwidth while
`
`20
`
`maintaining a real-time stream. This also frees the content
`
`provider from having to provide multiple media streams to
`
`accommodate differing connection speeds.
`
`In order to control
`
`the drain of the server’s network capacity,
`
`the system and
`
`method provides for a cap. The cap is utilized by the server
`
`+~26-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02041
`EXHIBIT 1003 - PAGE 02041
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`to restrict usage of the stream to maintain the integrity of
`
`the server's network.
`
`Having described preferred embodiments of a system
`
`and method for multimedia streaming, it is noted that
`
`modifications and variations can be made by persons skilled
`
`in the art in light of the above teachings.
`
`It is therefore
`
`to be understood that changes may be made in the particular
`
`embodiments of the invention disclosed which are within the
`
`scope and spirit of the invention as outlined by the
`
`10
`
`appended claims. Having thus described the invention with
`
`the details and particularity required by the patent laws,
`
`what is claimed and desired protected by Letters Patent is
`
`set forth in the appended claims.
`
`-27-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02042
`EXHIBIT 1003 - PAGE 02042
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`WHAT IS CLAIMED IS:
`
`1.
`
`A method for streaming video data over a network
`
`in real time, comprising:
`
`initializing a transport mode for the video data;
`
`sending from a client to a server a data request for a
`
`single frame of video data;
`
`retrieving the single frame from a memory at the
`
`server; and
`
`sending the video data to the client.
`
`10
`
`2.
`
`The method for streaming video in Claim 1, wherein
`
`the steps of sending a data request for a single frame from
`
`the client to a server, retrieving the video data from a
`
`shared memory, and sending the retrieved video data to the
`
`15
`
`client, are repeated for each video frame.
`
`3.
`
`The method for streaming video as in claim 2,
`
`wherein said each video frame is processed for display
`
`independently from processing of another video frame.
`
`20
`
`4,
`
`The method for streaming video in Claim 1, wherein
`
`the step of initializing further comprises:
`
`determining a list of available transport modes for the
`
`client;
`
`-28-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02043
`EXHIBIT 1003 - PAGE 02043
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`determine incompatibilities between the available
`
`transport modes and software;
`
`choosing a transport mode from the list; and
`
`initializing parameters of the transport mode at the
`
`client for client control of video streaming.
`
`5.
`
`The method for streaming video in Claim 4, wherein
`
`the step of initializing is performed by a client
`
`application which is capable of running in different
`
`10
`
`operating systems.
`
`6.
`
`The method for streaming video in Claim 4, wherein
`
`the step of initializing is performed by a client embedded
`
`in a web page.
`
`15
`
`7.
`
`The method for streaming video in Claim 6, wherein
`
`the client embedded in the web page is chosen from one of a
`
`common gateway interface and an active server page.
`
`20
`
`8.
`
`The method for streaming video in Claim 1, wherein
`
`the transport mode is chosen from the group consisting of a
`
`UDP, a TCP, and a HTTP.
`
`25
`
`-29-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02044
`EXHIBIT 1003 - PAGE 02044
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`9.
`
`The method for streaming video in Claim 1, wherein
`
`storing video further comprises:
`
`capturing a thread from a specified source; and
`
`storing the captured thread in the server’s shared area
`
`of memory.
`
`10.
`
`A storage medium having a stored program which is
`
`executable by a processor for causing the processor to
`
`perform method steps for streaming video communication,
`
`the
`
`10
`
`method steps comprising:
`
`requesting a packet representing a single datagram from
`
`a server over a communication network;
`
`receiving a requested packet;
`
`processing and displaying said requested packet;
`
`15
`
`incrementing a datagram frame counter;
`
`requesting a next packet based on the frame counter
`value from the server; and
`
`asynchronously processing and displaying said next
`
`packet when received.
`
`20
`
`il.
`
`The method of claim 10, wherein communications
`
`between said processor and said server is by Wireless
`
`Application Protocol
`
`(WAP).
`
`-~30-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02045
`EXHIBIT 1003 - PAGE 02045
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`12.
`
`The method of claim 10, wherein said server is
`
`accessed by said processor via HTTP.
`
`13.
`
`The method of claim 10, wherein said packet
`
`representing a datagram is JPEG encoded.
`
`14.
`
`The method of claim 10, wherein said step of
`
`asynchronously processing and displaying is independent of
`
`data from said step of processing and displaying said
`
`10
`
`requested packet.
`
`15. An apparatus for communicating streaming video
`
`data between a plurality of users and a server connected by
`
`a communication network, comprising:
`
`15
`
`a stored program executable by a processor in said
`
`server for causing the server to: receive requests for
`
`individual datagrams from the plurality of users; and
`
`forwarding individual datagrams in response to each
`
`request to the user making the request at a rate based on
`
`20
`
`available bandwidth of the user making the request.
`
`16.
`
`The apparatus according to claim 15, wherein said
`
`plurality of users are wireless mobile devices.
`
`-31L-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02046
`EXHIBIT 1003 - PAGE 02046
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`17.
`
`The apparatus according to claim 15, wherein said
`
`server is accessible via HTTP.
`
`18.
`
`The apparatus according to claim 15, wherein the
`
`datagrams are JPEG encoded.
`
`-32-
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02047
`EXHIBIT 1003 - PAGE 02047
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`1/5
`
`
`
`Client
`
`Client
`
`
`
`FIG.1
`SUBSTITUTE SHEET (RULE 26)
`
`panzer
`
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02048
`EXHIBIT 1003 - PAGE 02048
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`2/5
`
`Java Audio/Video Client
`
`200 Gather System
`
`Info
`
`
`
`
`
`210
`Yes (TCP)
`
`
`st
`Initialize UDP
`
`—— 220
`
`Heat
`Initialize TCP
`
`230
`
`chCGIthrough &
`
`roug
`
`aun
`
`Send UDP
`Frame Request
`
`
`
`Send TCP
`
`Await HTTP
`
`
`
`
`
`
`
`FrameRequest ;
`Frame 7
`
`
`\;
`
`
`
`
`
`
` Receive and Play
`
`
`Audio Using Current
`
`
`Transport Method
`
`Display Frame
`
`
`270
`
`
`Select Audio
`Format
`
`28:
`
`5
`
`280
`
`Create Audio
`Thread
`
`Increment Frame
`Counter
`
`
`
`
`
`
`FIG. 2
`
`SUBSTITUTE SHEET (RULE26)
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02049
`EXHIBIT 1003 - PAGE 02049
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`3/5
`
`Multithreaded Audio/Video Server
`
`300__iio 305
`
`Accept Threads
`
`320
`
`225
`
`(wr?) @ (1)
`
`330
`
`335
`
`340
`
`345
`
`330
`
`Capture Thread
`
`CaptureFrame
`
`Store in
`Shared Memory
`
`310
`
`315
`
`Walt for Client
`Request
`
`
`
`355
`Reirieve Frame
`from Shared
`
`Memory
`
`
`
`370
`
`Send Frame
`
`Wit for New
`Connection
`360
`Cree Sere
`Tea
`
`375
`
`Wait for Client
`Request
`
`Walt for CGI
`
`Request
`
`
`265
`Retrieve Frame
`from Shared
`Memory
`
`380
`
`
`
`
`Send Frame
`
`Retrieve Frame
`from Shared
`Memory
`
`383
`
`390
`
`
`
`
`FIG. 3
`
`SUBSTITUTE SHEET (RULE 26)
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02050
`EXHIBIT 1003 - PAGE 02050
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`Al5
`
`Multithreaded Audio/Video Server
`
`eS 405
`
`Accept Threads
`
`435
`
`Capture Thread
`
`440
`
`445
`
`455a
`
`455b
`
`450@ CaptureDa
`
`ta
`
`410
`
`455e
`
`
`
`Wait for New
`Connection
`
`Lawee33a5mp=ouS
`
`Thread
`
`Wait for New
`Connection
`
`460¢
`
`Determine Audio
`Format
`
`Create Service
`Thread
`
`
`
`
`Wait for New
`Connection
`
`Determine Audio
`Format
`
`4600
`
`4650
`
`
`
`
`
`Create Service
`‘ Thread
`
`4704,
`Wait for Signal
`from Capture
`Thread
`
`4750
`
`
`
`Retreive Audio
`
`from Selected
`shared Butfer
`
`
`4800,
`
`Send Audio
`
`GSM Encoding
`
`465¢ see
`
`
`415
`
`420
`
`6.728 Encoding
`
`425
`
`Store in
`Shared Memory
`Buffers
`
`430
`
`Send Signal to
`Service Threads
`
`470b
`470¢c
`Wait for Signal
`Wait for Signal
`from Capture
`from Capture
`
`Thread
`Thread
`
`
`
`
`Retreive Audio
`
`
`from Selected
`
`shared Buffer
`
`
`475¢
`Retreive Audio
`from Selected
`shared Buffer
`
`480b
`
`480c
`
`
`
`Send Audio
`
`Send Audio
`
`SUBSTITUTE SHEET (RULE 26)
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02051
`EXHIBIT 1003 - PAGE 02051
`
`

`

`WO 01/080558
`
`PCT/US01/40452
`
`5/5
`
`CGI HTTP Transport Module
`
`
`Initialize Client
`UNIX Domain
`
`Socket
`
`
`Send Frame
`
`Requestto
`Main Server
`
`
`
`Send Retreived
` Web Server
`
`Frame to Web
`
`Server
`
`Push Frame to
`
`Java Client
`
`FIG. 5
`
`SUBSTITUTE SHEET (RULE26)
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02052
`EXHIBIT 1003 - PAGE 02052
`
`

`

`INTERNATIONAL SEARCH REPORT
`
`Intc...u..onal Application No
`PCT/US 01/40452
`
`A. CLASSIFICATION OF SUBJECT MATTER
`IPC 7
`HOAN7/24
`
`Accordingto International Patent Classification (IPC) or to both nationalclassification and IPC
`B. FIELDS SEARCHED
`
`Minimum documentation searched (classification system followed by classification symbols)
`IPC 7
`HO4N
`HO4L
`
`Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched
`
`Electronic data base consulted during the international search (name of data base and, where practical, search terms used)
`
`EPO~Internal, WPI Data, PAJ,
`
`INSPEC
`
`C. DOCUMENTS CONSIDERED TO BE RELEVANT
`
`
`
`Category °|Citation of document, with indication, where appropriate, of the relevant passages Relevant to claim No.
`
`1-3,8,
`15-18
`
`line 10 — line 22
`line 8 - line 10
`line 6 - line 10
`line 16 -page 25,
`line 6 - line 16
`
`line 5
`
`Beaudet, J-P
`
`WO 97 22201 A (XIE DONG ;CAMPBELL ROY H
`(US); CHEN ZHIGANG (US); TAN SEE MONG (US)
`19 June 1997 (1997-06-19)
`abstract
`page 19,
`page 21,
`page 24,
`page 24,
`page 26,
`
`US 5 929 850 A (HAASS JON CET AL)
`27 July 1999 (1999-07-27)
`abstract
`column 3,
`column 6,
`column 12,
`figure 10
`
`line 24 -— line 43
`line 9 — line 17
`line 47 -column 13,
`
`line 30;
`
`Further documents are listed in the continuation of box C.
`
`Patent family membersarelisted in annex.
`
`-/--
`
`° Special categories of cited documents :
`P
`8
`aoe
`aan
`A* documentdefining the general state of the art which is not
`considered to beof particular relevance
`earlier documentbut published onorafter the international
`filing date
`_
`;
`document which may throw doubtson priory. claim(s) or
`whichis cited to establish the publicationdate of another
`citation or other special reason (as specified)
`documentreferring to an orat disclosure, use, exhibition or
`other means
`* document published prior to the internationalfiling date but
`later than the priority date claimed
`Date of the actual completion ofthe international search
`
`2 October 2001
`
`Name and mailing addressof the ISA
`European Patent Office, P.B. 5818 Patentlaan 2
`NL — 2280 HV Rijswijk
`ne
`31
`Tel. (431-70) 340-2040,
`Tx. 31 651 epo ni,
`Fax: (431-70) 340-3016
`Form PCT/ISA/210 (second sheet) July 1992)
`
`.
`*T* later document published after the internationalfiling date
`or priority date and not in conflict with the application but
`:
`a
`"
`citedtounderstand the principle or theory underlying the
`documentof particular relevance; the claimed invention
`cannot be considered novelor cannot be considered to
`involve an inventive step when the documentis taken alone
`documentofparticular relevance;the claimed invention
`cannot be consideredto involveaninventive step when the
`documentis combined with one or more other such docu-—
`ments, such combination being obvious to a person skilled
`in the art.
`document memberof the samepatent family
`Date of mailing of the international search report
`
`16/10/2001
`
`Authorized officer
`
`_
`
`page 1 of 2
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02053
`EXHIBIT 1003 - PAGE 02053
`
`

`

`INTERNATIONAL SEARCH REPORT
`
`Inter nia.Onal Application No
`
`US 5 999 979 A CRAVI HEMANTH SRINIVAS
`AL) 7 December 1999 (1999-12-07)
`the whole document
`
`ET
`
`
`
`PCT/US 01/40452
`
`C.(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT
`
`
` Relevant to claim No.
`
`Category °|Citation of document, with indication,where appropriate, of the relevant passages
`
`
`
`
`
`
`
`
`
`
`
`"WAP — THE WIRELESS
`ERLANDSON C ET AL:
`APPLICATION PROTOCOL”
`ERICSSON REVIEW, ERICSSON. STOCKHOLM, SE,
`no. 4, 1998, pages 150-153, XP000792053
`ISSN: 0014-0171
`the whole document
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`“IMPLEMENTING
`KALVA H ET AL:
`MULTIPLEXING, STREAMING, AND SERVER:
`INTERACTION FOR MPEG-4"
`IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS
`FOR VIDEO TECHNOLOGY,
`IEEE INC. NEW YORK,
`US,
`vol. 9, no. 8, December 1999 (1999-12),
`pages 1299-1312, XP000873453
`ISSN: 1051-8215
`paragraphs ‘0002!, ‘0005!
`
`
`
`Form PCT/SA/210 (continuation of second sheat) (July 1992)
`
`page 2 of 2
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02054
`EXHIBIT 1003 - PAGE 02054
`
`

`

`INTERNATIONAL SEARCH REPORT
`i
`tent fami
`Information on patent
`family members
`
`Into. wcdOnal Application No
`PCT/US 01/40452
`
`Patent document
`cited in search report
`
`WO 9722201
`
`US 5929850
`
`Publication
`date
`
`19-06-1997
`
`27-07-1999
`
`A
`
`A
`
`US 5999979
`
`A
`
`07-12-1999
`
`Patent family
`member(s)
`
`0867003 A2
`2000515692 T
`9722201 A2
`
`3648197 A
`0909512 Al
`2001508602 T
`9800975 Al
`
`0956686 Al
`2000509592 T
`9834385 Al
`0956702 Al
`9834405 Ali
`6014706 A
`6230172 Bi
`
`EP
`JP
`WO
`
`AU
`EP
`JP
`WO
`
`EP
`JP
`WO
`EP
`WO
`US
`US
`
`Publication
`date
`
`30-09-1998
`21-11-2000
`19-06-1997
`
`21-01-1998
`21-04-1999
`26-06-2001
`08-01-1998
`
`17-11-1999
`25-07-2000
`06-08-1998
`17-11-1999
`06-08-1998
`11-01-2000
`08-05-2001
`
`Form POT/ISA/210 (patent family annex) (July 1992)
`
`
`
`IPR2022-01227
`IPR2022-01227
`EXHIBIT 1003 - PAGE 02055
`EXHIBIT 1003 - PAGE 02055
`
`

`

`(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`pore
`
`:
`fen aN
`ft
`
`by
`
`(19) World Intellectual Property Organization
`International Bureau
`
`(43) International Publication Date
`25 July 2002 (25.07.2002)
`
`PCT
`
`(10) International Publication Number
`WO 02/057943 Al
`
`(51) International Patent Classification’:
`
`GOOF 15/16
`
`STEVEN,Alexander, Roberts [US/US]; 5406 Kingston
`Drive, Richardson, TX 75082-4067 (US). GHOUSUD-
`DIN, Syed [US/US]; 504 Sheffield Drive, Richardson,
`(21) International Application Number:=PCT/US02/01840
`TX 75081 (US). VINAY, Polavarapu [IN/US]; 6913
`Valleyview Lane- Apt.
`#230, Irvin, TX 75039 (US).
`BHARGAVARAM, Bulleyya, Gade
`[IN/US];
`1213
`Meadow Creek Drive, Apt. #J, Irving, TX 75038 (US).
`
`(22) International Filing Date: 18 January 2002 (18.01.2002)
`
`(25) Filing Language:
`
`English
`
`English
`
`(74)
`
`Agents: DECARLO, James, J. et al.; Stroock & Stroock
`& Lavan LLP, 180 Maiden Lane, New York, NY 10038
`(US).
`
`Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU,
`CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH,
`GM,IIR,ITU, ID,IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC,
`LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, Mw,
`Mx, MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK,
`SL, TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA,
`ZW.
`
`(84)
`
`Designated States (regional): ARIPO patent (GH, GM,
`KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW),
`Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, T™),
`European patent (AT, BE, CH, CY, DE, DK, ES, FI, FR,
`GB, GR,IE, IT, LU, MC, NL, PT, SE, TR), OAPI patent
`
`[Continued on next page]
`
`(26) Publication Language:
`
`(30) Priority Data:
`60/263,058
`
`18 January 2001 (18.01.2001)
`
`US
`
`(81)
`
`(71) Applicant (for all designated States except US): YAHOO!
`INC. [US/US]; 701 First Avenue, Sunnyvale, CA 94089
`(US).
`
`(72)
`(75)
`
`Inventors; and
`JUSTIN, Paul,
`Inventors/Applicants (for US only):
`Madison [US/US]; 1504 Concord Drive, Richardson, TX
`75081 (US). ANTHONY,Joseph, Rodiger [US/US]; 5004
`Lake Vista Drive, The Colony, TX 75056 (US). SYED,
`Noman, Kazmi [PA/US]; 12480 Abrams Road, #2601,
`Dallas, TX 75243 (US). WILLIAM, David, Turner
`[US/US]; 6326 Bryan Parkway, Dalls, TX 75214 (US).
`
`(54) Title: METHOD AND SYSTEM FOR MENEGINGDIGITAL CONTENT, INCLUDING STREAMING MEDIA
`
`LAN-Basedfile move
` at
`
`LAN-based
`
` LAN-based
`file move,
`file read
`
`HTTPupload
`
`
`
`Client FTP
`
`upload
`
`
`
`Directs
`ingest
`
` FILE MANIPULATION SERVER612
`
`INTERNE!
`
`
`e
`i
`END USER105
`
`
`CLIENT 102
`
`Directs
`ingest
`
`cS
`MEDIA SERVER620
`MEDIA SERVER620
`stream
`
`
`(57) Abstract: Method and system for uploading, managing and delivering digital content, including streaming media. The system
`according to one embodiment allows receives digital content