WO2002073437A1

WO2002073437A1 - Seek architecture for media streaming

Info

Publication number: WO2002073437A1
Application number: PCT/US2002/007463
Authority: WO
Inventors: Maged Bishay; Michael Zelevinsky; Emad Barsoum
Original assignee: Edgestream, Inc.
Priority date: 2001-03-12
Filing date: 2002-03-12
Publication date: 2002-09-19

Abstract

The invention is a technique and apparatus for supporting random reads in files on the server side (415A-415N), without adding more software layers on top of the socket layer. In one embodiment, such a technique is implemented in a streaming architecture that is based on dividing or splitting a media file into multiple sub-files (1-N). The sub-files may exist on the different servers. Such servers are capable of streaming the sub-files to the client (405) that stitches or reassembles them together and provides them to a media player on the client machine.

Description

SEEK ARCHITECTURE FOR MEDIA STREAMING

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority to U.S. provisional patent application serial number 60/275,523, filed on March 12, 2001 and assigned to the assignee of the present application. The present invention is also related to U.S. provisional patent application serial number 60/275,408, entitled "Splitting and Redundant Storage on Multiple Servers", and U.S. Provisional Patent Application serial number 60/275,407, entitled "Re-assembly of Streaming Files from Separate Connections," both of which were filed on March 12, 2001 and also assigned to the assignee of the present application.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to data communication networks and more particularly to a method and apparatus for adaptive selection of media streaming.

2. Background Information

In a typical client-server network environment, an incoming connection from a client is accepted by the server by performing an accept operation on the server's listening socket. A new server socket is typically created for the new client connection, h an HTTP setting, the HTTP request header from the client is parsed and processed. Where a file has been requested by the client, the server performs a file search to determine if the requested file exists. Where the server deteraiines that the requested file does exist, the server sends a response header to the client through the appropriate socket connection. The server then undertakes to read the requested file into memory (e.g., the network buffer) and transmit the file to the client, again through the same socket connection. For larger files that exceed memory constraints, the read/send operations are repeated until the entire requested file has been sent.

While the above-described client-server interaction is suitable for sequential data streaming operations, there is presently no means for a server to perform random reads in response to non-sequential file requests from the client. This functionality would enable video streaming applications to provide media which can be started at any point within the media file.

SUMMARY OF THE INVENTION The invention is a technique and apparatus for supporting random reads in files on the server side, hi one embodiment, such a technique is implemented in a streaming architecture that is based on dividing or splitting a media file into multiple sub-files. The sub-files may exist on different servers. Such servers are capable of streaming the sub-files to the client that stitches or reassembles them together and provides them to a media player on the client machine.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a system block diagram of one embodiment of a network system in which the system and method of the invention may be implemented. Figure 2 is a system block diagram of one embodiment of a computer system which implements the embodiments of the invention.

Figure 3 is a flow diagram for the setup of one embodiment of the invention.

Figure 4A is a system diagram of the interaction between a client side and a server side, according to one embodiment of the invention.

Figure 4B is another embodiment of the interaction between a client side and a server side.

Figure 5 is an illustration of anon-sequential file seek, according to one embodiment of the invention

Figure 6A illustrates the splitting and recombining of a file, according to one embodiment.

Figure 6B is a system diagram of the interaction between a client side and a server side, according to another embodiment of the invention

Figure 7 is a flow diagram of the process for requesting and receiving nonsequential content, according to one embodiment.

DETAILED DESCRIPTION

One aspect of the invention relates to a system and method for providing media over a network from a server side to a client side in a non-sequential fashion, h one embodiment, an original file is divided into a number of sub-files. A client may then issue a request for a non-sequential read of the original file, along with an offset for the original file, response, a server determines which of a number of subfiles are to be provided to the client to fulfil the request, according to one embodiment.

Another aspect of the invention involves using a client-provided offset for the original file to determine offsets for each of a plurality of sub-files that are to be provided to the client. In one embodiment, the computation of offset information is performed on the server side, while in another embodiment such computations are performed on the client side. Once the offset information is determined, the server may then stream the requested content to the user where each requested sub-file is streamed beginning at the specified offset point.

Yet another aspect of the invention is to reassemble the requested sub-files into a sequential content clip so that it may be presented on the client side.

Definitions

As discussed herein, a "computer system" is a product including circuitry capable of processing data. The computer system may include, but is not limited to, general purpose computer systems (e.g., server, laptop, desktop, palmtop, personal electronic devices, etc.), personal computers (PCs), hard copy equipment (e.g., printer, plotter, fax machine, etc.), banking equipment (e.g., an automated teller machine), and the like. Content and/or media elements refers to application programs, driver programs, utility programs, file, payload, and combinations thereof, as well as graphics, informational material (articles, stock quotes, etc.) and the like, either singly or in any combination. A "communication link" refers to the medium or channel of communication. The communication link may include, but is not limited to, a telephone line, a modem connection, an Internet connection, an Integrated Services Digital Network ("ISDN") connection, an Asynchronous Transfer Mode (ATM) connection, a frame relay connection, an Ethernet connection, a coaxial comiection, a fiber optic connection, satellite connections (e.g. Digital Satellite Services, etc.), wireless connections, radio frequency (RF) links, electromagnetic links, two way paging connections, etc., and combinations thereof.

System Overview

A description of an exemplary system, which incorporates embodiments of the invention, is herein described. Figure 1 shows a system block diagram of one embodiment of a network system 10 in which the apparatus and method of the invention is used. Referring to Figure 1, the network system 10 comprises a service center 12 that is connected over one or more communication links 20 to a remote network 30 (e.g., a wide area network or the Internet) or a remote site (e.g., a satellite, which is not shown in Figure 1) to one or more user computer systems 40i-40 ("40"). In one embodiment the service center 12 is a website. The service center 12 includes one or more servers 22 and one or more databases 24. hi one embodiment, the server 22 includes software modules that may be downloaded for performing the processes of the invention, as described in detail in the following sections, h addition, more than one service center 12 may be used, each having one or more servers.

The service center 12 may also include one or more computers 26_\-26 _. If a plurality of computers are used, then the computers 26_\-26u maybe connected by a local area network (LAN) or any other similar connection teclmology. However, it is also possible for the service center 12 to have other configurations. For example, a smaller number of larger computers (i.e. a few mainframe, mini, etc. computers) with a number of internal programs or processes running on the larger computers capable of establishing communication links to the user computers.

The remote network 30 or remote site allows the service center 12 to provide peer-to-peer information and services to the user computers 40_I-40N, using software that is stored at the service center 12. hi one embodiment, the user computers 40 may be any computer system or any other device that processes and/or presents audio and/or video information. The one or more databases 24 connected to the service center computer(s), e.g., computer 26_1? are used to store data. Each user computer 40 is connected via network connection 32_I-32_N over a corresponding communication link 42 42_N such as a local carrier exchange to a respective ISP 44i-44_N, through which access to the remote network 30 is made.

By inputting the URL address of the target website with which the user desires to interact, the user may be connected to various target websites, such as websites 50_J-50_NN. h an alternate embodiment, each user computer 40 may be connected via network connection 32 32 over a corresponding communication link 48_Ϊ-48_N to the service center 12, which provides internet access and service to the user computer(s) 40. In a further embodiment, the display screen for viewing the content or media elements may be located on a television coupled to the network 30. hi this case, navigation through the content or media elements may be provided through the use of control buttons on a remote control unit for controlling viewing of the television, or by other means known in the art. One aspect of the present invention relates to retrieval and delivery of content and/or media elements. The software for providing such processes may be developed and or stored on a computer 40, or maybe developed using one of the computers 26\- 26_M- Upon completion of the development process, the software may be stored in the computer 40 or in the database 24. Alternatively, the software may be stored on a machine-readable medium, in any of the computers 40 or computers

Referring to Figure 2, the computer system 100 (representing either of computer 26 or 40) comprises a processor or a central processing unit (CPU) 110. The illustrated CPU 110 includes an Arithmetic Logic Unit (ALU) for performing computations, a collection of registers for temporary storage of data and instructions, and a control unit for controlling operation for the system 100. hi one embodiment, the CPU 110 includes any one of the x86, Pentium™, Pentium H™, and Pentium Pro™ microprocessors as marketed by Intel™ Corporation, the K-6 microprocessor as marketed by AMD™, or the 6x86MX microprocessor as marketed by Cyrix™ Corp. Further examples include the Alpha™ processor as marketed by Digital Equipment Corporation™, the 680X0 processor as marketed by Motorola™; or the Power PC™ processor as marketed by IBM™, h addition, any of a variety of other processors, including those from Sun Microsystems, MIPS, IBM, Motorola, NEC, Cyrix, AMD, Nexgen and others may be used for implementing CPU 110. The CPU 110 is not limited to microprocessor but may take on other forms such as microcontrollers, digital signal processors, reduced instruction set computers (RISC), application specific integrated circuits, and the like. Although shown with one CPU 110, computer system 100 may alternatively include multiple processing units. The CPU 110 is coupled to a bus controller 112. The bus controller 112 may include a memory controller (not shown) integrated therein, though the memory controller may be external to the bus controller 112. The memory controller provides an interface for access by the CPU 110 or other devices to memory 116 via memory bus 114. hi one embodiment, the system memory 116 includes synchronous dynamic random access memory (SDRAM). System memory 116 may optionally include any additional or alternative high speed memory device or memory circuitry. The bus controller 112 is coupled to a system bus 120 that may be a peripheral component interconnect (PCI) bus, Industry Standard Architecture (ISA) bus, etc. Coupled to the system bus 120 are a graphics controller, a graphics engine or a video controller 132, a mass storage device 150, a communication interface device 152, and one or more input/output (I/O) devices 168_I-168N. The video controller 132 is coupled to a video memory 136 (e.g., 8 Megabytes) and video BIOS 140, all of which may be integrated onto a single card or device, as designated by numeral 144. The video memory 136 is used to contain display data for displaying information on the display screen 148, and the video BIOS 140 includes code and video services for controlling the video controller 132. h another embodiment, the video controller 132 is coupled to the CPU 110 through an Advanced Graphics Port (AGP) bus.

The mass storage device 150 includes (but is not limited to) a hard disc, floppy disc, CD-ROM, DVD-ROM, tape, high density floppy, high capacity removable media, low capacity removable media, solid state memory device, etc., and combinations thereof. The mass storage device 150 may include any other mass storage medium. The communication interface device 156 includes a network card, a modem interface, etc. for accessing network 164 via communications link 160. The VO devices 168_\~l68π include a keyboard, mouse, audio/sound card, printer, and the like. The I/O devices lόδ lόδ_N may be disk drive, such as a compact disc (CD) drive, a hard disc drive, a tape drive, a zip drive, a jazz drive, a digital versatile disc (DVD) drive, a magneto-optical disk drive, a high density floppy drive, a high capacity removable media drive, a low capacity media device, and/or any combination thereof.

The information, content and/or application software may be stored in the database 24, on the computers 40, or on a machine-readable medium. The information, content and/or application software may also be made available to users such as those located at user computer 1 -N, i.e., computers 40₁-40_N, through service center 12 or by means of the machine-readable medium.

As discussed earlier, one aspect of the invention relates to a system and method for providing media over a network in a non-sequential fashion, h one embodiment, a request may be made by a user for content or media elements. The system and process of the invention may retrieve the desired content/media element from either database 24 or one of target websites 50^50^- The retrieved content/media element is then processed (e.g., decompressed, formatted, etc.). Users may then view the processed content/media element on a display device, such as a user computer 40. In another embodiment, the desired content/media is provided to the user in a non-sequential fashion.

In accordance with the practices of persons skilled in the art of computer programming, the invention is described below with reference to symbolic representations of operations that are performed by a computer system or a like electronic system. Such operations are sometimes referred to as being computer- executed. It will be appreciated that operations that are symbolically represented include the manipulation by a processor, such as a central processing unit, of electrical signals representing data bits and the maintenance of data its at memory locations such as in system memory, as well as other processing of signals. The memory locations where data its are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits. Thus, the term "server" is understood to include any electronic device that contains a processor, such as a central processing unit.

Setup Process

Referring now to Figure 3, in which a setup process is depicted. Setup process 300 begins with the development of the client-side software at block 305. As will be discussed in more detail below, the client-side software will enable a user to communicate with client-side software by issuing read requests to one or more servers, according to one embodiment, hi another embodiment, the server-side software also comprises stitching software which may be used to reassemble a requested file, or portion thereof, which has been previously split. One example of a method for reassembling streaming files is provided in related PCT Application No.

PCT/US / , entitled "Re-assembly of Streaming Files from Separate

Connections" (hereinafter the "PCT/US / patent application"), which describes the reassembly of the sub-files into a viewable file upon receipt by a client system, h one embodiment, the server passes the information regarding the splitting process to the client system to facilitate the sub-file reassembly process. Server-side software is developed at block 310. As will be discussed in more detail below, the server-side software will be able to process random read requests, according to one embodiment. The server-side software of block 310 may also enable a server to perform offset computations, thereby enabling the server to stream content to a client system beginning at the requested location. The server-side software may also comprise software to split a single file into multiple sub-files, which may then be distributed and stored on one or more servers. One example of a method for splitting files into sub-files is provided in related PCT Application No. PCT/US / , entitled "Splitting and Redundant Storage on Multiple Servers" (hereinafter the

"PCT/US / patent application"), which describes the division of a single file into multiple sub-files which are then stored on one or more servers. Such a file may include text, data, graphics, video clips, JPEG elements or images, static photographs, web pages, audio clips, animation, any type of informational material or any combination thereof. The servers may be distributed over different geographical locations. In one embodiment, the sub-files can be transmitted in parallel from one or more servers in response to a user request, thereby increasing the rate at which data can be delivered.

While in the embodiment of Figure 3 the development of the server-side software takes place at block 310, it should be appreciated that the server-side software may be developed before the client-side software of block 305. It should further be appreciated that the development process of block 305 or block 310 may take place on any one of user computers 40, computers 26_\-26u, server 22, or any other system capable of being used for software development. It is also possible to install both client-side and server-side software on the same client computer to implement a peer-to-peer system.

Continuing to refer to Figure 3, the software of block 305 and 310 are installed at block 315. It should be appreciated that the client-side software of block 305 may be installed on one or more user computers 40, while the server-side software of block 310 may be installed on server 22. In another embodiment the server-side software is installed on a plurality of servers connected either to the network 30 or to the client systems directly over a communications link.

At block 320, media presentation software is installed on one or more client system, such as one or more user computers 40. Media presentation software may include any of Windows Media Player, Real Player, QuickTime Player, or any other media players capable of receiving streaming content. It should also be appreciated that the media presentations software installation of block 320 may occur before the installation activities of blocks 315, and even before the development activities of blocks 305 and 310. Thereafter, the client system(s) on which the client-side software was loaded may be comiected to the server(s) running the server-side software. In one embodiment, the client system communicates with the server(s) by connecting to the World Wide Web, while in another embodiment the client system(s) and the server(s) communicate over a LAN connection. However, it should be appreciated that the client system(s) may interact with the server(s) over any known communication link. System Interaction

Referring now to Figure 4A, in which a diagram of the interaction between a client system 405 and a plurality of servers 415a-415N is depicted, h this embodiment, the client system 405 is connected to the plurality of servers 415a-415N using communication links 410a-410N. Moreover, in this embodiment the server- side software of block 310 is a SeekMod module. The SeekMod module may be contained in a database or any other storage area within the server. In addition to the SeekMod module, servers 415a-415N also contain sub-files 1 -N, where the sub-files represent portions of an original file which has been split into a plurality of parts and stored on servers 415a-415N. In one embodiment, each sub-file has a file name and other file attributes, and is treated by the operating system's file system as just another file.

hi one embodiment, the SeekMod modules of Figure 4A have two interfaces. One interface connects to the client system 405 through a socket connection, typically using User Datagram Protocol (UDP)-based or TCP/IP -based (such as HTTP) protocol. The second interface reads data from the sub-file stored in the server's file system (e.g., sub-files 1 - N). In another embodiment, the second interface has the capability to read data from a server file system, specifying an offset from the beginning of the sub-file stored thereon. This seek function may be implemented by the SeekMod module, according to one embodiment. It should be appreciated that the SeekMod module may run on top of the web-server software, or it may run as a separate process, application, or service that communicates with the client system 405 using regular socket connections. hi one embodiment, client-side software running on client system 405 will make read requests for N different sub-files through the server-side software running on each server (e.g., SeekMod modules). The server-side software module translate the "socket read" requests issued by the client system 405 into file read requests. In one embodiment, the server-side software can handle read requests for more than one sub-file at a time for a plurality of sub-files residing on the same server.

In the embodiment of Figure 4B, the client system 405 is depicted as being one or more user computers 40. hi addition, user computers 40 communicate with servers 415a-415N over remote network 30. Moreover, in the embodiment of Figure 4B, the server-side software 420a-420N has been installed on each of servers 415a- 415N. hi addition to the server-side software, each server 415a-415N includes database 425a-425N, on which one or more media files or sub-files maybe stored.

Non-sequential Seek Functionality

For purposes of illustration only, assume a user has dragged the "progress bar" on a media player while viewing a media clip. In such a case the user is in fact asking the player to start reading data from a different location in the file, thus requiring a non-sequential file read. At this point, the client-side software may compute the new location in the original unsplit file, according to one embodiment. Thereafter, the client system can make non-sequential read requests starting at that computed offset location.

By way of providing a non-limiting example, Figure 5 depicts the case where a user has dragged the progress bar on the media player, either to move to an advanced point of playback time or to return to a previously viewed playback time. The new playback time corresponds to the point in the original unsplit file that has an offset of 24,576 bytes from the beginning. In this example, the original file has been split into 8192 byte chunks, and the chunks re-assembled into sub-file 1 and sub-file 2. The offset for sub-file 2 would be 9192 bytes from the beginning, which corresponds to 1000 bytes from the beginning of chunk 4. The offset for sub-file 1 would be 16,384 bytes from the beginning, which corresponds to the beginning of chunk 5.

Although the client-side software will make requests for these two sub-files with the new offsets from the appropriate servers, any server in the network can perform the offset computation required by this operation, hi one embodiment, such a function is implemented by the client-side software. When the data from the two sub-files is received, the client-side software will stitch or recombine the partial chunk 4 with chunks 5-6 together before passing the recombined file onto the media player. As mentioned above, while any known method of recombining split files may be used, one example of such a method if provided in the PCT/US / patent application.

Server-side software maybe used to process the non-sequential read requests. In one embodiment, implementation for communication to the server-side software is through TCP/IP sockets using the Hyper Text Transfer Protocol (HTTP). In another embodiment, regular sockets may be utilized.

Continuing to refer to the example of Figure 5, client-side software may make a request for the file, including the offset information, using a standard HTTP request. For example, the request for data starting 9192 bytes after the start of the file named sub-file2.mpg from the server with an IP address of 192.168.0.1 may be written as follows:

http://192.168.0.1/SeekMod.dll?File=sub-file2.mpg&Offset-9192.

When the server-side software receives this request from the client, it will request the server file system to read sub-file2.mpg with an offset of 9192 bytes. Server-side software module will then send the file data, which will not include the first 9192 bytes of data, to the client system. Using this approach, the client can seek to any location within the media file.

In the case where the server does not support HTTP, the client system and server may communicate through basic socket protocol (UDP or TCP/IP-based), and the request from the client system will be served using a server-side module, which runs as a separate process, application, or service.

Referring now to Figure 6A, an example of an original file 600 is shown. The original file 600 is 72 Kbytes in length and has been split into 9 chunks, which are each 8 Kbytes long, hi this embodiment, the original file 600 has been reassembled into three sub-files SI, S2 and S3, with each sub-file contains 24 Kbytes. While the splitting and reassembling processes performed on the original file 600 correspond to the methods disclosed in the PCT/US / patent application and the

PCT/US / patent application, it should be appreciated that any other known means of splitting and recombining files may be used. Namely, any method of recombining portions of a previously split original file into sub-files maybe used where it is possible to compute an offset based on a user request, and correlate that offset to a particular location within the recombined sub-files. Figure 6B illustrates a block diagram of a networked system, according to one embodiment of the invention. Client system 610 running client-side software, such as the client-side software of Figure 3, is connected to one or more servers over network 30. Moreover, in this embodiment Servers A, B and C are running server-side software, such as the server-side software of Figure 3, and are connected to network 30. However, it should be appreciated that client system 610 and Servers A-C maybe connected using any known communication link.

h one embodiment, the client-side software of client system 610 includes stitching software 620, which may be used to create reassembled file 630. Thereafter, reassembled file 630 may be provided to media presentation software 640 for display. In one embodiment, stitching software 620 is used to reassemble file segments which have been downloaded from one or more of the Servers A-C. While any known means of reassembling file segments may be used, the method described in the PCT/US / patent application may be used, according to one embodiment.

Continuing to refer to Figure 6B, sub-files S 1 and S2 from Figure 6A have been loaded onto Server A. Similarly, sub-files SI and S3 have been loaded onto Server B, while sub-files S2 and S3 have been loaded onto Server C. Thus, in this embodiment the original file 600 has been split into three sub-files, with each of the three sub-files being available from more than one server. As described in the

PCT US / patent application, this arrangement improves the speed at which a user will be able to download a given file.

Suppose, for example, that a user at client system 610 desires to begin viewing the original file 600 at just over two-thirds of the way into the original file 600. This corresponds to a point in the original file which is 2 Kbytes into the sixth segment, labeled as seek point 650 in Figure 6B. The original file offset for seek point 650 is 50 Kbytes. It should be appreciated that this offset computation may be conducted using the client-side software of the client system 610, or maybe conducted using the server-side software of any of Servers A-C. Where the offset computation is to be conducted by one or more of Servers A-C, it may be necessary to provide the client system 610 with information regarding how the original file 600 was originally segmented. With this information, client-side software may then be able to convert a user request for a non-sequential read to a read request recognizable by the server-side software. In one embodiment, anyone of Servers A-C may use the original file 600 offset to compute the offsets for each of the sub-files which are to be streamed to the client.

Continuing with the example where a user has requested to view the original file beginning at seek point 650, client system 650 will receive the partial sixth segment from Server B, the entire seventh segment from Server A, the entire eighth segment from Server C, and the entire ninth segment from Server B, according to one embodiment. After these segments are received, they may recombined using stitching software 620 into reassembled file 630.

Figure 6C is a flow diagram of one embodiment for providing media over a network in a non-sequential fashion. Process 600 begins at block 705 where both the client and server(s) are initialized. In one embodiment, this comprises initializing client-side software, running on client system 610, and server-side software, running on one or more server(s). At block 710, content is loaded onto one or more of the servers running the server-side software. In one embodiment, the content comprises a media file. The content is then split into N segments at block 715. While any method of splitting the content may be used, in one embodiment the content is split according to the method described in the PCT/US / patent application. Thereafter, the segments are recombined into M sub-files, hi one embodiment, M is less than N.

Where it is desirable to provide storage redundancy, the sub-files may be loaded onto multiple servers. For example, in the previously discussed embodiment of Figure 6B, each of sub-files SI -S3 were loaded onto two of the Servers A-C. This may enable a sub-file to be streamed to a given user in parallel and simultaneously from one or more servers, thereby increasing the data delivery rate, hi another embodiment, sub-files are replicated so that the most frequently accessed files and sub-files are replicated onto more servers, while the less frequently accessed files and sub-files are replicated onto fewer servers. The sub-files may be replicated onto multiple servers based on anticipation or actual demand.

Process 700 continues with decision block 730, where a determination is made as to whether the user has requested the content from the server. If not, process 700 stays in a loop until the content is requested, according to one embodiment. If, on the other hand, the content has been requested, a determination is then made at block 735 as to whether the user is requesting non-sequential access to the content. If not, the content is streamed to the client system at block 740 using the method described in PCT US / patent application, or any other known means of streaming media content over a network to a client system.

Where, however, the client has requested non-sequential access to the content, offset information is computed at block 745. It should be appreciated that, while this offset information^'may be computed by the client system in one embodiment, such information may also be computed on the server-side and subsequently provided to the client system. Such offset information may include an offset for the original file, as well as offsets for each of a plurality of sub-files. Moreover, where the content has been reassembled into M sub-files, the offset information for the original content may also be used to determine which of the sub-files are to be provided to the client.

Referring back to the example of Figure 6B, the original file offset of 50 Kbytes for seek point 650 means that the offset for SI is 16 Kbytes, since only the sixth segment of SI is needed. Similarly, the offset for S2 is 16 Kbytes since only the last segment in S2 is required to fulfil the client request. Continuing with the example of Figure 6B, the offset for S3 would be 10 Kybtes. Thus, computation of the offset information of block 745 may require correlating the offset for the original file to the offset for each of the sub-files.

hi another embodiment, the client is to provide to the server(s) the read request at block 750, including the offset information, h one embodiment, where the client has requested sub-file2.mpg, the request will have the form:

send (socket, command, lengthofcommand),

where socket is the open connection socket to the server, command is "open sub-file2.mpg " and lengthofcommand is the size of the memory buffer holding the command. In another embodiment, the request from the client involves two steps. First, a READ command is sent to one or more servers with the required offset (e.g., 9192) for the sub-file2.mpg, where the command may be in the following form: send (socket, command, lengthofcommand),

where socket is the open connection socket to the server, command is "read 9192" and lengthofcommand size of buffer holding the command "read 9192." Secondly, a command is sent in the following form:

recv (socket, buffer, BytesToReceive),

where socket is the open connection socket to the server, buffer is where the content will be received on the client side, and BytesToReceive is the amount of data the client is asking for.

Once the request is issued by the client, the request is processed on the server- side at block 755. hi one embodiment, a single server serves as a clearinghouse through which all requests are processed, while in another embodiment, the requests are routed to one or more servers depending on the content requested.

In response to the request of block 750, the requested content is streamed to the chent at block 760. As discussed above, the content may be streamed from a single server or a plurality of servers, either simultaneously or in succession, h any event, the content will be streamed beginning at the appropriate offset for each subfile such that the content is provided to the client in the requested non-sequential manner. As the streamed sub-files are received by the client, client-side software may then be used to stitch the sub-files together at block 765. As mentioned above, the method for recombining the sub-files may follow the method described in the PCT/US_/ patent application. Once the requested content has been reassembled, it may then be provided to a media player for presentation at block 770.

While the preceding description has been directed to particular embodiments, it is understood that those skilled in the art may conceive modifications and/or variations to the specific embodiments described herein. Any such modifications or variations which fall within the purview of this description are intended to be included therein as well. It is understood that the description herein is intended to be illustrative only and is not intended to limit the scope of the invention.

Claims

CLAIMSWhat is claimed is:

1. A method for providing content non-sequentially over a network comprising: splitting said content into a plurality of sub-files; storing said sub-files on at least one server; attempting to access said content beginning at a start point, where said start point is other than a beginning of said content; determining a content offset corresponding to said start point; determining a sub-file offset corresponding to said content offset; providing a portion of one of said sub-files to a client system over the network, said portion to correspond to said sub-file offset.

2. The method of claim 1 wherein splitting said content comprises splitting said content into a plurality of segments and then combining said plurality of segments into the plurality of sub-files.

3. The method of claim 1 , wherein storing said sub-files comprises storing at least one of said plurality of sub-files on a plurality of servers.

4. The method of claim 1, wherein attempting to access said content comprises attempting to access said content beginning at a start point other than a beginning of said content by re-positioning a progress bar of a media player.

5. The method of claim 1 , wherein determining the content offset comprises determining a distance between said beginning of said content and said start point.

6. The method of claim 5, wherein said distance corresponds to an amount of time that would elapse when presenting the content from said beginning of said content to said start point.

7. The method of claim 5, wherein said distance corresponds to an amount of data between said beginning of said content and said start point.

8. The method of claim 1, wherein determining said sub-file offset comprises determining a distance between a beginning of said sub-file and said start point.

9. The method of claim 1 , wherein providing the portion of one of said sub-files comprises transmitting said portion to the client system over the network in response to a non-sequential client request for said content.

10. The method of claim 1 , further comprising providing an additional portion of one of said sub-files to the client system, where said additional portion is from a different sub-file than said portion.

11. The method of claim 10, further comprising recombining said portion and said additional portion into a recombined portion using said client system.

12. The method of claim 11, further comprising presenting said recombined portion using a media player on said client system.

13. A system for providing content non-sequentially over a network comprising: a client to receive over the network a portion of said content beginning at a start point, where said start point is other than a beginning of said content, said client to determine a content offset corresponding to said start point and to provide said content offset to said server; and a server in communication with the client over the network, where at least a portion of said content is stored on said server as of a plurality of sub-files, said server to determine a sub-file offset corresponding to said content offset, said server to provide a portion of one of said sub-files to the client over the network where said portion corresponds to said sub-file offset.

14. The system of claim 13 wherein said plurality of sub-files are formed by splitting said content into a plurality of segments and then combining said plurality of segments into the plurality of sub-files.

15. The system of claim 13, wherein at least one of said plurality of subfiles are stored on a plurality of servers.

16. The system of claim 13, wherein said client issues a request to access said portion of said content by re-positioning a progress bar of a media player.

17. The system of claim 13, wherein said content offset comprises a distance between said beginning of said content and said start point.

18. The system of claim 17, wherein said distance corresponds to an amount of time that would elapse when presenting the content from said beginning of said content to said start point.

19. The system of claim 17, wherein said distance corresponds to an amount of data between said beginning of said content and said start point.

20. The system of claim 13, wherein said sub-file offset comprises a distance between a beginning of said sub-file and said start point.

21. The system of claim 13 , wherein the portion of one of said sub-files are provided to the client by the server in response to a non-sequential client request for said content.

22. The system of claim 13, wherein said server further provides an additional portion of one of said sub-files to the client, where said additional portion is from a different sub-file than said portion.

23. The system of claim 22, wherein said client further recombines said portion and said additional portion into a recombined file.

24. The system of claim 23, wherein said client presents said recombined portion using a media player.

25. A server to provide content to a client over a network comprising: a processor; a memory couple to the processor; and, a communications port, coupled to the processor, to connect the server to the network; wherein said memory comprises instruction sequences to cause said processor to: store said content as a plurality of sub-files, receive a client request to access said content beginning at a start point, where said start point is other than a beginning of said content, detennine a sub-file offset using a content offset corresponding to the start point, and provide a portion of one of said sub-files to the client over the network, where said portion corresponds to said sub-file offset.

26. The server of claim 25 wherein said plurality of sub-files are formed by splitting said content into a plurality of segments and then combining said plurality of segments into the plurality of sub-files.

27. The server of claim 25, wherein at least one of said plurality of subfiles are stored on a plurality of servers.

28. The server of claim 25, wherein said client request is initiated by repositioning a progress bar of a media player.

29. The server of claim 25, wherein said content offset comprises a distance between said beginning of said content and said start point.

30. The server of claim 29, wherein said distance corresponds to an amount of time that would elapse when presenting the content from said beginning of said content to said start point.

31. The server of claim 29, wherein said distance corresponds to an amount of data between said beginning of said content and said start point.

32. The server of claim 25, wherein said memory further includes instruction sequences to cause said processor to provide the portion of one of said sub-files to the client in response to a non-sequential client request for said content.

33. The server of claim 25, wherein said memory further includes instruction sequences to cause said processor to provide an additional portion of one of said sub-files to the client, where said additional portion is from a different sub-file than said portion.

34. The server of claim 33, wherein said client is to recombine said portion and said additional portion into a recombined file.

35. The server of claim 34, wherein said client is further to present said recombined portion using a media player.