(12) United States Patent
`Chen et al.
`
`USOO6175862B1
`(10) Patent No.:
`US 6,175,862 B1
`(45) Date of Patent:
`Jan. 16, 2001
`
`(54) HOT OBJECTS WITH SEQUENCED LINKS
`IN WEB BROWSERS
`
`(75) Inventors: Jeane Shu-Chun Chen; Ephraim Feig,
`both of Chappaqua, NY (US)
`
`(73) Assignee: International Business Machines
`Corporation, Armonk, NY (US)
`Under 35 U.S.C. 154(b), the term of this
`patent shall be extended for 0 days.
`
`(*) Notice:
`
`(21) Appl. No.: 09/098,706
`(22) Filed:
`Jun. 17, 1998
`(51) Int. Cl." ............................. G06F 13/38; G06F 15/17
`(52) U.S. Cl. ...
`709/218; 709/250; 704/233;
`704/276; 395/615
`(58) Field of Search ..................................... 395/200, 615;
`704/233,276; 370/94
`References Cited
`U.S. PATENT DOCUMENTS
`5,289,470 * 2/1994 Chang et al. .......................... 370/94
`
`(56)
`
`1/1998 Scloss .................................. 395/615
`5,706,507
`5,774,664 * 6/1998 Hidary et al. ........................ 395/200
`5,774,666
`6/1998 Portuesi ............................... 395/200
`5,983,176 : 11/1999 Hoffert et al. ....................... 704/233
`5,983,190 * 11/1999 Trower, II et al. .................. 704/276
`
`* cited by examiner
`Primary Examiner Zarni Maung
`Assistant Examiner-Farzaneh Farahi
`(74) Attorney, Agent, or Firm-Scully, Scott, Murphy &
`Presser; Daniel P. Morris, Esq.
`(57)
`ABSTRACT
`The present invention extends a standard HTML browser to
`Support a new data type, the Uniform ReSource Locator
`Sequence (URLS). The URLS consists of a header and a
`sequence of URLs. The method of the present invention
`receives the URLS data then sequentially accesses the data
`of each URL comprising the URLS, obtains statistics on the
`response time to the requests for URLS, and times the calls
`for Subsequent URLS in the Sequence accordingly So that the
`arrival of the linked data nearly simulates actual Streaming.
`
`20 Claims, 3 Drawing Sheets
`
`
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 1
`
`

`

`U.S. Patent
`
`Jan. 16, 2001
`
`Sheet 1 of 3
`
`US 6,175,862 B1
`
`URLs(I) URLs(2) . . . .
`
`. . . .
`
`URLsin)
`
`F. G.
`
`URL(j)
`
`T(j)
`
`B(J)
`
`F. G. 2
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 2
`
`

`

`U.S. Patent
`
`Jan. 16, 2001
`
`Sheet 2 of 3
`
`US 6,175,862 B1
`
`101
`
`108
`
`MEMORY
`
`STATIC
`STORAGE
`DEWICE
`
`107
`
`INPUT
`DEWICE
`
`109
`
`COMM
`LINK
`
`100
`/
`
`CPU
`
`103
`
`
`
`
`
`GRAPHICS
`ADAPTER
`
`O4
`
`DISPLAY
`DEVICE
`
`105
`
`FIG 3
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 3
`
`

`

`U.S. Patent
`
`Jan. 16, 2001
`
`Sheet 3 of 3
`
`US 6,175,862 B1
`
`FIG 4
`
`Read header
`
`Initialize
`
`Streaming <D Manual
`
`Fetch segment
`
`Fetch URL
`
`
`
`Fetch next segment
`and display present
`segment
`
`Fetch next URL and
`display present URL
`
`NO
`
`Display segment
`
`NO
`
`Display URL
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 4
`
`

`

`1
`HOT OBJECTS WITH SEQUENCED LINKS
`IN WEB BROWSERS
`
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention relates to Internet and Intranet
`Browsers, more Specifically, to BrowserS equipped with
`functionality to process a Sequence of URL requests auto
`matically. This capability allows the Browser to induce a
`non-streaming Server to Simulate a streaming Server.
`2. Discussion of Prior Art
`Internet Browsers are computer programs that Simplify
`and make convenient viewing and navigating through docu
`ments on the World Wide Web (Web), written in the Hyper
`text Markup Language (HTML). Two of the most popular
`browsers are the Netscape's Navigator, home page http://
`www.netscape.com, and the MicroSoft's Internet Explorer,
`home page http://www.microSoft.com/ie/default.esp. All
`Web browsers provide a graphical user interface with stan
`dard point-and-click navigation methods and HTML file
`Support.
`HTML documents linked to other HTML documents on
`the Internet are called hypertext documents. Hypertext docu
`ments with multimedia capabilities are called hypermedia
`documents. The links, connecting hypertext documents, are
`called hyperlinks or hot linkS. Hyperlinks often appear in the
`hypertext documents behind the highlighted text, a word or
`a phrase usually describing Something of which a user might
`want further information. The region of the hypertext docu
`ment where the hyperlink appears as text is called hot object.
`To activate a hyperlink, the user must point and click on
`the hot object by using a computer pointing device Such as
`a keyboard or a mouse. The user's computer Screen display
`is then changed to display the linked hypertext document,
`which typically contains more information on the high
`lighted word or phrase of the hot object. Hyperlinks make it
`easy to follow cross-references between documents.
`The hypertext documents and other data on the Web are
`found and retrieved by the means of the Uniform Resource
`Locator (URL). The URL complies with a draft standard for
`Specifying an object on the Internet. It specifies the object
`format, the acceSS method, and the location of the object.
`The objects formats are specified as Multipurpose Internet
`Mail Extensions (MIME). The following are a few formats
`on the Web.
`.au-the most common audio format,
`.html-hypertext markup language,
`.jpg-Still images encoded using Joint Picture Experts
`Group Standards,
`mid-midi music,
`mpg-Video images encoded using Motion Picture
`Experts Group Standard, and
`pS-post Script.
`Each hot object in hypertext files is linked to a unique
`URL. Often having a hot object linked to a sequence of
`URLS is desirable. For example, a presentation may consist
`of a sequence of HTML files, each of which is linked by a
`URL. The author may want this presentation of HTMLS to
`be shown in Sequence, each lasting Some predetermined
`amount of time. Another Situation arises when a Sequence of
`video segments is located at various URLS, when linked
`together Such Sequences comprise one contiguous Selection
`of video.
`Video is the dominant medium in entertainment and is
`rapidly becoming common in computing environments.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,175,862 B1
`
`2
`Viewing a Sequence of Video Segments in contiguous fashion
`is very desirable for a viewer, So as to Simulate viewing the
`entire Video being Streamed from a Server. Providing the user
`with one hot object that would automatically direct the
`request to the multitude of URLS in a Sequence is therefore
`desirable, with the request being executed either automati
`cally or manually by the viewer.
`A conventional non-Streaming Server is insensitive to
`isochronous requirements. In general, that type of Server is
`designed for minimal transfer latency. Without explicit
`mechanisms to ensure isochronism, delivery rates of data to
`a browser are irregular, resulting in erratic playback quality
`at client machines. To avoid an erratic playback of Video
`files, the usual approach is to download to the host computer
`whole video files before starting the video playback. Video
`data is typically very Voluminous. Compressed Video for
`mats such as MPEG-1, Indeo, QuickTime-MOV, and
`Cinepack require about 10 MB to store one minute of video
`data. When the bandwidth of the channel is too low to
`Support the bit rate of the particular video, this approach of
`downloading of whole video files before starting the video
`or Some modification of it is inevitable.
`One Such modification is to obtain statistics of the down
`load rate, and together with the bit rate of the Video compute
`a reasonable Starting time for playback So that the entire
`Video may be played without glitches. This Scheme reduces
`the latency between the request for the video and the start of
`the playback. When the bandwidth of the channel is greater
`than that required for a real-time playback, a non-Streaming
`Server may overwhelm the Storage of the receiving playback
`System.
`Streaming video is primarily intended to address this
`Situation. A Streaming Server deliverS Video Streams
`isochronously, So that the Video playback is guaranteed to
`have Smooth motion and Sound, provided that the channel
`bandwidth is high enough. The Streaming Server Sends Video
`data at controlled bit rates that match the bit rate of the
`encoded video. One drawback of streaming video files is that
`the receiving playback System cannot Support random SeekS.
`A user viewing Streaming Video must always begin viewing
`from the beginning of the file, or at best from that portion of
`the file that is cached. When seeking video to the future point
`in time, for example, the viewer has to wait for the Server to
`Stream all the Video data prior to the desired Seek position.
`
`SUMMARY OF THE INVENTION
`
`The present invention extends a standard HTML browser
`to Support a new data type, the Uniform Resource Locator
`Sequence (URLS). The URLS consists of a header contain
`ing descriptive information and a Sequence of URLS. The
`URLS may be a sequence of pre-existing files, or a new
`Sequence of URL's may be created by partitioning a data
`resource Such as Video into contiguous time Segments,
`Storing each Segment in an Internet location and creating a
`URL for each of these segments.
`The browser receives the URLS data, sequentially
`accesses the data of each URL comprising the URLS initi
`ating the requests at times dependent on the bandwidth of the
`channel and various parameters provided by the data in the
`header portion of URLS. When the various URLs constitute
`contiguous Segments Such as from a Video Sequence, and the
`requests are timed appropriately, the effect is that of Simu
`lating Streaming of Video.
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 5
`
`

`

`15
`
`3
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 illustrates the structure of the URLS;
`FIG. 2 illustrates the structure of the URLG) component
`of a URLS;
`FIG.3 illustrates a computer processing System utilized in
`the implementation of the preferred embodiment; and
`FIG. 4 shows a flow chart diagram of the preferred
`embodiment of the present invention.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`Although this invention has been found particularly useful
`in the environment of Video data, this invention can also be
`applied to various other types of data, Such as but not limited
`to audio data.
`The preferred embodiment of the present invention
`extends a standard HTML browser to support a new data
`type. FIG. 1 shows the structure of this new data type, the
`Uniform Resource Locator Sequence (URLS). A URLS
`consists of a Header, containing a header file, and an ordered
`list URLSC), where j is an index ranging from 1 to n.
`The Header file contains information regarding the type of
`data contained in the various subsequent URLS. Such data
`type may be text, images, audio, Video, and other types of
`data. The Header also contains information regarding what,
`if any, computer plug-ins or extras are necessary for pro
`cessing the data in the Subsequent URLS, and whether or not
`Streaming needs to be simulated. A browser Simulating
`Streaming is Said to be in a streaming mode.
`The structure of a URLSC), shown in FIG. 2, contains
`URL(j), a time duration parameter TG), and a value B()
`representing the size of the corresponding data. AURL() is
`the URL for the jth entry of the URLS. Typically the time
`duration parameter TG) will signify that the browser exhibits
`the contents of the URLG) for TG) period.
`The present invention may be implemented on any com
`puter processing System including, for example, a personal
`computer or a WorkStation. AS Shown in FIG. 3, a computer
`processing System which may be utilized by the present
`invention generally comprises the memory 101, one or more
`central processing units (CPU) 103, and one or more user
`input devices 107, Such as a keyboard, a mouse, a joystick,
`a Voice recognition System, or a handwriting recognition
`System. The computer processing System of the present
`invention includes a nonvolatile memory such as ROM and
`other nonvolatile storage devices 108 such as a fixed disk
`drives that Store operating Systems and application programs
`that are loaded into the memory 101 for execution by the
`CPU 103. In the execution of operating systems and appli
`cation programs the CPU 103 may use data stored in the
`nonvolatile storage device 108 and memory 101.
`The computer processing System of the present invention
`further includes a graphics adapter 104 coupled between the
`CPU 103 and a display device 105 such as a CRT display or
`a LCD display. The application program and the operating
`system executed by the CPU 103, generate graphics
`commands, for example a command to draw a box (or a
`window), to display a bit map image, to render a three
`60
`dimensional model, or to display a Video file. Such com
`mands may be handled by the application program or the
`operating system executed by the CPU 103 or by the
`hardware that works in conjunction with the application
`program and the operating system executed by the CPU 103,
`wherein the appropriate pixel data is generated and the
`display device 105 is updated accordingly.
`
`45
`
`50
`
`55
`
`65
`
`US 6,175,862 B1
`
`25
`
`35
`
`40
`
`4
`In addition, the computer processing System includes a
`communication link 109, Such as a network adapter or a
`modem coupled to the CPU 103, that allows the CPU 103 to
`communicate with other computer processing Systems over
`the communication link, for example over the Internet. The
`CPU 103 may receive portions of the operating system,
`portions of the application programs, or portions of the data
`used by the CPU 103 in executing the operating system and
`application programs over the communication link 109.
`Application programs and the operating System executed
`by the CPU 103 may perform the methods of the present
`invention described below. Alternatively, portions or all of
`the methods described below may be embodied in hardware
`that works in conjunction with the application program and
`the operating system executed by the CPU 103. In addition,
`the methods described below may be embodied in a distrib
`uted processing System whereby portions of Such methods
`are distributed among two or more processing Systems that
`are linked together via communication link 109.
`According to the preferred embodiment of the present
`invention, described in a flow chart shown on FIG. 4, the
`user launches a hyperlink by clicking on the hot object
`appearing on the HTML page displayed by the browser, Such
`hot object having a link to a URLS. Recognizing the URLS
`data type, the browser responds by executing a Sequence of
`computer instructions.
`The “Read header” module is called to extract the nec
`essary information from the header portion of the URLS.
`The header information is passed to the “Initialize” module.
`Based on the information in the header file, the “Initialize”
`module causes the browser to launch the appropriate func
`tions necessary to execute one or more desired applications.
`For example, if the data in the URLS comprise segments
`from a video stream, the browser will spawn (start up) on the
`host computer the appropriate video decoderS and players.
`Next, the “Mode'?” module reads the part of the header file
`that specifies whether the data pointed to by URLS is
`intended for the Streaming mode playback, or whether the
`choice of Streaming mode Versus manual mode will be left
`to the user. If the header indicates the Streaming mode, the
`playback mode is set automatically to Streaming. Otherwise,
`the browser will output a query to the computer Screen,
`prompting the user to input which of the two modes the user
`wishes to execute as a playback. The user then may respond
`by making the appropriate choice. A default value may be
`chosen by the browser if the user chooses not to reply to the
`query.
`In the Streaming mode, the timing of the transitions
`between the various data of the different URLs is crucial. As
`an illustration, consider the URLS comprising contiguous
`Segments from a video Sequence. Streaming Succeeds only
`if TD(i+1)+A(i+1)<T(), where TD(i) is the time delay
`between the time the browser initiates a request for URLG)
`and the time the first data packet from URL(j) arrives at the
`browser. A(i) is the time duration for all data from URLG)
`to arrive, that is the time duration from when the first data
`packet arrives till the last data packet arrives.
`The “Parameters' module enables the user to choose a
`minimum time duration for uninterrupted display of the
`Streaming data. The user is prompted to choose a time
`duration value T, Such that in case Streaming of the entire
`program is not possible, at least Segments of time duration
`T will be played continuously. Predefined or default values
`may be used instead of user input.
`In the streaming mode, the “Parameters' module then
`partitions the URLs comprising the URLS into segments
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 6
`
`

`

`US 6,175,862 B1
`
`S
`Segment 1-(URL(A), . . . , URL(A)),
`Segment 2-(URL(A+1), . . . , URL(A)),
`Segment 3-(URL(A+1), ..., URL(A)), etc., Such that
`
`6
`until all the contents of URL(2) have arrived. When all the
`contents of URL(2) have arrived, the “URLs left?” decision
`module sends the control back to "Fetch next URL and
`display present URL' module to begin fetching data from
`the next URL, URL(3) and storing it in the alternate buffer
`BUFFA, and simultaneously displaying the decoded URL
`(2) data stored in BUFF B.
`This proceSS is continued, with buffers interchanging,
`ping-ponging, until no more URLS are left to fetch. After the
`“URLS left?” decision module makes that determination, it
`sends control to the “Display URL module which displays
`the decoded data from the last URL and the process is
`terminated by the “End” module.
`The present invention is well Suited for viewing video
`whose compressed data is transmitted from a Server, without
`the need for Storing all the data in advance at the local Site,
`and without the need for the Server to have Streaming
`capabilities. The video data which will be streamed is
`partitioned into Sequenced Segments. A URLS is created,
`with the URL Segment Sequence as its content.
`AS an illustration, please consider the following. A 60
`minute MPEG encoded video stream is partitioned into one
`minute Segments. The data rate of the encoded Video is 1.5
`Mbps, each one minute Segment is therefore encoded with
`90 megabits, and the entire video is encoded with 5.4
`Gigabits (or 675 MBYTES) of data. The bandwidth from the
`server to the browser is 3 Mbps. The browser determines that
`the time delay between its request for data and the beginning
`of the arrival of the data is less than 20 seconds. The time to
`deliver a one minute segment of video over the channel is 30
`Seconds. Thus, the total time from initiating the request for
`a minute Segment till the entire data for that Segment arrives
`is less than 50 Seconds, and certainly less than one minute,
`which is the playing time of one segment. Hence the
`Streaming criteria is Satisfied. The browser allocates 2 or
`more memory buffers, each of 12 megabytes, for tempo
`rarily Storing the incoming Video data, and utilizes them in
`an alternating fashion.
`Having thus described our invention, what we claim as
`new, and desire to Secure by Letters Patent is:
`1. A method for creating a Uniform Resource Locator
`Sequence data type (URLS), the method comprising the
`Steps of
`locating two or more URLS provided by a user to com
`prise said URLS, each of said URLs being associated
`with a resource;
`determining a type of the resource of each Said located
`URLs;
`determining a size of the resource of each said located
`URLs;
`determining a playback time of the resource of each Said
`located URLs, and
`Storing a header including type of resource of Said located
`URLs, and a sequence of entries URLSC), where j is an
`integer from 1 to n, where each URLSC) comprises a
`URL, the size parameter and the playback time param
`eter of the respective resource, wherein the data type is
`used for Simulating a streaming Server.
`2. A method of claim 1, further comprising dividing the
`resource into a plurality of Segments and associating each
`segment with one of said URLS.
`3. A method of claim 2, wherein the division of resources
`is made according to time.
`4. A method of claim 2, wherein the division of resources
`is made according to size.
`5. A method of claim 3, wherein the segments are of
`approximately equal duration.
`
`The display of the last Segment cannot be guaranteed to
`satisfy the requirement. Therefore the buffer size BUFF
`required to Store the Segment with the largest amount of data
`is determined utilizing the B(i) value in the URLS(i). BUFF
`is equal to the maximum B(A+1)+B(A+2)+...+B(A).
`It then allocates two buffers, BUFF A and BUFF B, each
`of Size BUFF.
`Next, the “Fetch segment” module fetches the first seg
`ment and stores it in BUFF A. This involves making
`requests for URL(1), URL(2), and so on, until URL(A1). As
`Soon as all the data for the first segment arrives, the “Fetch
`next segment-and display present-Segment module begins
`fetching the second segment and storing it in BUFF B and
`Simultaneously displaying the decoded contents from the
`first segment stored in BUFF A.
`The system continuously watches for the finish of the
`Segment fetch, and the finish of the Segment display. This
`task is performed by the “Wait auto” module. If the stream
`ing constraints are met, namely TD(i+1)+A(i+1)<TG), then
`the fetch will be done before the display. When both fetch
`and display are done, the “URL's left?” decision module
`determines whether Segments are remaining to be fetched. If
`there are, the control is passed back to the “Fetch next
`Segment-and display present-Segment module, which ini
`tiates a fetch of a neXt Segment, and Stores it in the alternate
`buffer, BUFF A for segment three. At the same time it starts
`displaying the decoded output from the current Segment,
`which is already stored in BUFF B.
`This proceSS is continued, with one Segment being Stored
`in one buffer and the previous Segment being played back
`from the other, until the “URLS left?” decision module
`determines that there are no more Segments left to fetch,
`Then, the last Segment is displayed by the "Display Seg
`ment' module and the Streaming process terminates with the
`“End module.
`In accordance with the invention, if the Streaming criteria
`are met, then the entire content of all the URLS comprising
`the URLS will be displayed in proper timing order as
`prescribed by the content creator. If the contents of the URLs
`comprise a video Sequence, then the Video will be displayed
`from beginning to end in a continuous manner as is typical
`when using a Streaming Server and a stream capable player.
`The player may be programmed So that after playing each
`Video Segment, it may be called upon again to continue
`playing a Subsequent Segment. This way, the browser does
`not have to Spawn a new player for every incoming Segment.
`In the Manual mode, the “Parameters' module allocates at
`least two buffers BUFF A and BUFF B, each buffer
`equals in size to the maximum B(i). The “Fetch URL'
`module fetches the data in URL(1) and stores it in a buffer
`BUFF A. As soon as all the data from URL(1) has arrived,
`the “Fetch next URL and display present URL module
`begins fetching the data from URL(2), storing it in a buffer
`BUFF B and simultaneously displaying the decoded URL
`(1) data stored in BUFF A.
`The “Wait man” module continuously monitors the sys
`tem for a Signal from the user to begin fetching data from the
`next URL. When such signal is detected and all the contents
`of URL(2) have not arrived, the “Wait man” module waits
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 7
`
`

`

`US 6,175,862 B1
`
`8
`12. A method of claim 11, wherein the fetching the next
`Segment Step further comprises determining whether the
`next segment fetch should be performed before the next
`Segment display.
`13. A method of claim 12, where the playback mode is the
`Streaming mode.
`14. A method of claim 13, wherein step c further com
`prises Selecting a minimum time duration for uninterrupted
`display of data.
`15. A method of claim 14, wherein the determination of
`whether the next segment fetch should be performed before
`the next segment display is made using a formula
`
`7
`6. A method of claim 4, wherein the Segments are of
`approximately equal size.
`7. A method for requesting a Uniform Resource Locator
`Sequence data type (URLS) from a network, the URLS
`including a header containing types of one or more
`resources, each of Said resources being associated with a
`URL, and a sequence of entries URLS(i), where j is an
`integer from 1 to n, where each URLS(i) comprises a URL,
`a size parameter and a playback time parameter of a respec
`tive resource, the method comprising the Steps of:
`a) initiating URL requests to each of the URLs included
`in a requested URLS for transmission over a data
`channel;
`b) determining a timing sequence for the requests accord
`ing to the timing, Size and type parameters contained in
`said URLS and the bandwidth of the data channel; and
`c) transmitting resources according to the timing Sequence
`determined in Step b Over the channel for playback,
`wherein the data type is used for simulating a streaming
`SCWC.
`8. A method of claim 7, further including the step of
`playing back a resource Simultaneously with the transmis
`Sion of the next resource as described in Step c.
`9. A method of claim 7, wherein the initiation of the
`requests to the various URLs comprising the URLS is timed
`automatically according to a user predetermined timing
`Sequence.
`10. A method of claim 7, wherein the initiation of the
`requests to the various URLs comprising the URLS is timed
`manually according to a user provided input.
`11. A method for requesting a Uniform Resource Locator
`Sequence data type (URLS) from a network, the URLS
`including a header containing types of one or more
`resources, each of Said resources being associated with a
`URL, and a sequence of entries URLS(i), where j is an
`integer from 1 to n, where each URLS(i) comprises a URL,
`a size parameter and a playback time parameter of a respec
`tive resource, the method comprising the Steps of:
`a) extracting the type of resources of Said URLS from a
`header portion of a URLS;
`b) initiating one or more computer applications to play
`back said types of resources of Said URLs,
`c) selecting a playback mode,
`d) partitioning the URLs comprising the URLS into
`Segments,
`e) determining a largest segment size BUFF and allocat
`ing at least two buffers each of size BUFF;
`f) fetching the first segment and storing it in one of the
`empty buffers;
`g) fetching the next segment and storing it in an empty
`buffer, and Simultaneously displaying the Segment
`Stored in a full buffer until no more Segments remain to
`be fetched; and
`h) displaying the Segment stored in the last full buffer and
`terminating the process, wherein the data type is used
`for Simulating a streaming Server.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`where
`TD(i) is the time delay between the initiation of a request
`for the URLS(i) and the time a resource associated with
`a URL from URLSC) arrives from the network,
`A(i) is the time duration for all resource data associated
`with a URL from URLS(i) to arrive, and
`T(j) is the predefined time duration for uninterrupted
`display of the resource.
`16. A method of claim 15, wherein the step of partitioning
`the URLS comprising the URLS into Segments is repre
`sented by:
`(URL(1),..., URL(A)),
`(URL(A+1), . . . , URL(A)),
`(URL(A+1), . . . , URL(A)), etc., Such that
`
`where
`T is a user defined time duration value, and
`A is an integer from 1 to n.
`17. A method of claim 16, wherein a buffer size BUFF is
`determined as follows:
`
`where
`B(A) is the data size given in URLS(A.), and
`A is an integer from 1 to n.
`18. A method of claim 12, where the playback mode is the
`manual mode.
`19. A method of claim 18, wherein each URL is a
`Segment.
`20. A method of claim 11, wherein the playback data is
`video.
`
`Amazon / WAG Acquisition
`Exhibit 1031
`Page 8
`
`