GB2385683A

GB2385683A - Distribution system with content replication

Info

Publication number: GB2385683A
Application number: GB0204223A
Authority: GB
Inventors: Shaheedur Reza Haque; David Cecil Robinson; Richard Andrew Morrell; Michael John Chamberlain
Original assignee: Thirdspace Living Ltd
Current assignee: Thirdspace Living Ltd
Priority date: 2002-02-22
Filing date: 2002-02-22
Publication date: 2003-08-27
Also published as: GB0204223D0

Abstract

A video distribution system is provided for delivering a number of video streams to a plurality of users. The system employs a distributed architecture in which a number of local servers are provided for servicing user requests received from users in the proximity of the respective local server. In dealing with the user request, the local server determines if the user request should fail, should proceed or should be redirected to another server. The redirection is preferably controlled using the real time streaming protocol (RTSP) used to control the streaming of video files and the like over the Internet. Network cost and server busyness are used to decide which server the request should be redirected to. The location of content on the servers may be dynamically changed in dependence upon request history. A management server 1 controls this, as well as the location of content replicas.

Description

DISTRIBUTION SYSTEM The present invention relates to a system for distributing and delivering media content data, such as video data, to a number of different users.

Conventionally, television programs have been broadcast to users via RF signals transmitted from terrestrial base stations, via signals transmitted from overhead satellites and via signals transmitted over cable to user premises. Each of these systems offers the user the ability to watch a number of different channels which can be selected by the user. These existing systems, however, require all of the channels to be transmitted to the user's television receiver, which then tunes into and displays one of the channels in accordance with the user's selection. Whilst this conventional technique is cost effective, it requires the use of a significant amount of bandwidth. In some of these conventional systems, the user must subscribe to the service provider in order to be able to view some of the channels.

However, since each user's television receiver receives all of the channels, user's can still gain access to restricted channels using appropriate hacking equipment which can bypass the service provider's security.

Television broadcasters have also provided television channels over data networks to computers provided in user's homes. To be able to work effectively, these systems use a different protocol to transmit the audio and video data to that conventionally used to send, for example, email over the internet. In particular, these systems use a streaming protocol (such as UDP (user datagram protocol) ) which allows some packets to be lost in the transmission process without the transmission stopping and restarting. In one of these data network video systems, a common video stream is transmitted from the video server using multi-cast techniques to duplicate the video stream for each of the users which is a party to the multi-cast transmission. However, this system does not provide a truly one-to-one relationship between the user and the video server and hence limited personalisation of the video stream for each user can be achieved.

In another type of data network video delivery system, a dedicated video stream is provided from a central video server to each user. The problem with this approach is that it requires a significant bandwidth between the central video server and each user. This problem can be overcome using a distributed content delivery system in

which a central master server is provided which can communicate through a core network to a large number of local servers distributed over the geographical area of interest. In such a system, the master server has access to the entire set of content files that are available to the users and operates to distribute some of the content files to the individual local servers. In this way, each local server has a subset of all of the content files available at the master server and can provide those to users in its proximity on demand. In operation, users make requests for content files directly to the master server which identifies a local server having the requested content file which is in the locality of the user and instructs that local server to stream or download the content file to the user. If, however, the requested content file is not stored in any of the local servers, then the master server will stream the requested content file to the user. In this way, there is a tradeoff between using the core network bandwidth and disc storage space provided in the local servers.

The main issues with this type of distributed delivery system is how to manage the distribution of the content files to and the deletion of content files from the local servers in order to maximise the likelihood that the

user's request is dealt with by the local server and not by the master server whilst minimising the storage space required by the local servers. In particular, how the system should determine what content files are to be copied to, deleted from and duplicated in each of the local servers and after this decision has been made, when and how this should be carried out.

According to one aspect, the present invention provides a content data distribution system having a plurality of content servers and at least one user device, wherein at least one of the content servers includes means for receiving requests for content files from the user device, means for determining if the content server can provide the requested content file; and means for redirecting the user device to another one of the content servers if the content server cannot provide the requested content file.

Preferably, the content servers maintain statistics of the requests that have been made by the users, which statistics are transmitted, from time to time, to a remote management server which processes the statistics and in response controls the copying of content files to the content servers. In this way, the management server

can try to minimise the number of content files stored within the content servers whilst minimising the likelihood that a user request will have to be redirected.

Other features and aspects of the invention will become clear from the detailed description of the exemplary embodiments given below with reference to the accompanying drawings in which: Figure 1 is a schematic block diagram of a data distribution system; Figure 2 is a schematic block diagram illustrating the connection between a local server and a user device shown in Figure 1; Figure 3 is a block diagram illustrating the main components of a playout control unit shown in Figure 2; Figure 4a is a flowchart illustrating part of the operation of a database server shown in Figure 2 upon receipt of a request for a content file from a user; Figure 4b is a flowchart illustrating a remaining part

of the operation of the database server shown in Figure 2 upon receipt of a request for a content file from a user; Figure 5a is a block diagram illustrating the main components of a user set-top box shown in Figure 2; Figure 5b schematically illustrates the form of an RTSP request transmitted from an RTSP controller shown in Figure 5a ; Figure 6 is a block diagram illustrating the main components of a management server shown in Figure 1; Figure 7 is a block diagram illustrating the way in which the local servers and the management server shown in Figure 1 may be arranged into a hierarchy of servers based on geographical area; and Figure 8 is a schematic diagram illustrating that a redirect program may be provided within a switch connected between a local server and a user set-top box.

OVERVIEW Figure 1 is a schematic block diagram of a data broadcast

system for supplying data signals (in this embodiment video signals for a plurality of television channels) to a plurality of users. As shown in Figure 1, the system comprises a management server 1 which receives video signals from a number of different media content sources 3-1,3-2 and 3-3 and which distributes these video signals to a number of geographically distributed local servers 5-1,5-2 via a core data network 7. In this embodiment, the management server 1 transmits the video files in digital MPEG format. In this embodiment, the video signals received from the media content sources 3-1 and 3-3 are digital signals whereas the video signals received from the media content source 3-2 are analogue signals. An appropriate encoder 9 is therefore provided between the media content source 3-2 and the management server 1.

The local servers 5 are arranged to store the video files received from the management server 1 so that they are available, upon request, to users in the locality of the local server 5. In this embodiment, each local server 5 only stores a subset of the video files that are available at the management server 1. The aim is that the local servers 5 only hold the video files of most interest to the users within the geographic locality

serviced by the local server 5, so that the local servers 5 can satisfy the majority of requests received directly from those users. If a user requests, via their user device 11, a video file that is not stored within the local server 5, then the local server redirects the user either to another local server 5 or to the management server 1. In order to determine how to redirect a user, each local server 5 maintains data identifying which local servers have each content file and data identifying how busy each local server 5 currently is. The local server 5 then uses a predefined redirection algorithm to determine how the user should be redirected.

Each local server 5 also maintains redirection statistics identifying the users, their video requests and those that have been redirected. These redirection statistics are then transmitted, from time to time, back to the management server 1 which uses the redirection statistics, in this embodiment, to control the copying of content files to (and the deletion of content files from) the local servers 5. For example, if the management server 1 identifies that there have been ten attempts to watch the film"The Wizard of Oz"redirected from local server 5-1, then it determines that a copy of that film should be moved to local server 5-1 and it

schedules the copying of that film to local server 5-1 at an appropriate time.

An electronic program guide (EPG) server 12 is also provided that is connected to the management server 1 and the core network 7. The EPG server 12 generates a program guide identifying all the video files that are available from the management server 1 and makes that guide available to the user devices 11 via the core network 7. In this way, users can browse through the electronic program guide to identify a video to be streamed from their local server 5.

The above description gives an overview of the video distribution system of this embodiment. A more detailed description will now be given of the individual components and how they communicate with the other components of the system.

LOCAL SERVER Figure 2 is a block diagram illustrating the main components of each local server 5 and illustrating the way in which it communicates with a user within its proximity. As shown, in this embodiment, the local server 5 includes a video server 13 which controls the

delivery of video data streams to the users and a database server 15 which is connected to the video server 13 and which controls access to programs and data stored in a database 17. In this embodiment, the database 17 includes a redirect program 18 and a lookup program 19 which can be read out from the database 17 into the database server 15 and run in order to control redirect and addressing operations; a user address lookup table 21 which stores data identifying the appropriate network address for each user; redirect data 23 which is used by the redirect program to determine whether or not to redirect a user's request to another server; redirect statistics 25 which identify what user requests and what redirects, if any, have been made; and a stored content directory 27 which identifies the content files stored locally within the video server 13.

In this embodiment, the video server 13 includes three video pumps 31-1,31-2 and 31-3 which are operable to generate the streams of video data that are transmitted to the users from video files stored in the local hard discs 33-1 and 33-2. As shown in Figure 2, the streams of video data are output to user set-top boxes 35 via a local network (e. g. an Asymmetric Digital Subscriber Line (ADSL) switched network) 41. The user's set-top box 35

receives the stream of video data, decodes it and displays it on a user television 37 for viewing by the user. The set-top box 35 also receives user input identifying control commands for controlling the playout of the video data or for identifying a request for a new video stream, which the set-top box 35 encodes and transmits, via the local network 41, to a playout control unit 39 of the video server 13. If the user request is for controlling the playback of a video stream (for example to stop, pause, fast-forward or rewind the current stream being output), the playout control unit 39 outputs the appropriate control signals to control the reading out of the data from the disc 33 and the delivery of the data via the video pump 31. However, as will be described in more detail below, if the user request relates to a request for a new video stream, then the playout control unit 39 forwards the request to the database server 15 which determines if the user's request should: (i) fail because, for example, the requested video stream is not known; (ii) be redirected to another server; or (iii) proceed so that the requested video data is streamed out to the user from the video server 13.

As shown in Figure 2, the video server 13 also includes a file transfer protocol (FTP) unit 43 which operates to

receive content files transmitted from the management server 1 over the core network 7 and to store and make duplicates (if appropriate) of the received content files in the hard discs 33. Duplicates of the content files may be stored in the hard discs 33 since this increases the number of users that can be served at any one time with the same film. In particular, there is a limit to the number of users to which the video pump can stream the same content file. This problem is overcome, in this embodiment, by having one or more duplicate copies of the content files, depending on the demand for the content file. The FTP unit 43 can also output content files stored in the discs 33 to other local servers 5 if desired.

In this embodiment, the database server 15 is operable to communicate with the management server 1 in order to transmit the redirect statistics and the like back to the management server 1 and in order to receive details of new content to be stored in the video server 13 and new redirect rules for determining whether or not a user's request should be redirected. The database server 15 also receives control data from the local network 41 defining the user address which is used for updating the user address lookup table 21 stored within the database

17.

As will be apparent from the above description, one of the main features of the local servers 5 used in this embodiment is their ability to receive user requests and to either service them themselves or to redirect the requests to another server. In this embodiment, this redirection is controlled using the real time streaming protocol (RTSP) which is a standard Internet control protocol. This control protocol is used to control the delivery of streamed media data over data networks. As a result, the user's set-top box 35 only needs to include a standard RTSP controller to be able to communicate with the local server 5 and to be able to be redirected if appropriate.

Figure 3 is a block diagram illustrating the form of the playout control unit 39 which forms part of the video server 13 shown in Figure 2. As shown, the request received from the local network 41 from the user set-top box 35 is passed to an RTSP request receiving unit 51 which extracts the user request and passes it to the playout controller 53. Each received request will identify the user making the request and the requested action. If the request relates to the control of a video

file currently being streamed to the user, then the playout controller 53 generates and outputs appropriate control signals to the video pumps 31 and to a disc reading unit 55, in order to control the delivery of the video stream to the user in accordance with the received request. If on the other hand, the received request is a request for a new video file, then the playout controller 55 outputs the request (identifying the requested video file and the user making the request) to the database server 15.

A description will now be given with reference to Figure 4 of the way in which the database server 15 processes such a user request. As shown, in step sl, the database server 15 receives the user request and in response loads and runs, in step s3, the redirect program 18.

Initially, the redirect program 18 queries, in step s5, the content directory 27 to determine the location of the requested video file. In particular to determine if the requested video file is known and if so if it is stored in the video server 13 or in any of the other local servers 5. If the redirect program 18 determines at step s7 that the requested video file is not known, then processing proceeds to step s9 where the redirect program 18 returns a fail response back to the playout controller

53.

If, however, the video file is known then processing proceeds to step sll where the redirect program 18 determines if the user's request is to be redirected to another server. In making this decision, the redirect program 18 uses the locations found in step s5 and the redirect data 23 stored in the database 17. In particular, the redirect program 18 identifies the servers having the requested video file from the locations found in step s5 and it then retrieves the redirect data 23 for those servers. In this embodiment, the redirect data 23 is constantly being updated by the management server 1 and identifies how busy each server currently is and what the"network cost"is for redirecting the user making the request to that server.

In this embodiment, this redirect data 23 is encapsulated in a single"score"for each server which is calculated and updated by the management server 1.

The network cost associated with redirecting the user to the other server depends on where the user is located relative to the other server. In particular, if the other server is also in close proximity to the user then the network cost associated with such a redirect is

likely to be relatively small. Whereas, if the other server is remote from the user (in which case the video stream will have to be streamed over a significant part of the network), then the network cost associated with redirecting the user to that other server is likely to be relatively high. In this way, the local server 5 can make an independent determination as to where it is best to redirect the user if it cannot service the user's request itself.

As those skilled in the art will appreciate, there are various ways in which the redirect program 18 can use the scores for each server in determining which server will service the user's request. For example, if the requested video file is stored within the video server 13 then the redirect program 18 may be arranged so that the video server 13 will always service the user's request if the video server 13 is not too busy, which can be determined by comparing the score for the video server 13 with a predetermined threshold value. If the score is below the threshold, then the video server 13 can service the request otherwise the redirect program 18 has to consider the scores for the other servers which have the requested video file. In this embodiment, in making this consideration, the redirect program 18 compares the

scores for the different servers identified in step s5 and redirects the user to the server having the lowest score.

If at step sl3, the redirect program 18 determines that the user request should be redirected then processing passes to step s15 where the redirect program 18 returns a redirect instruction to the playout control unit 39, identifying the network address of the server to which the user is to be redirected. If on the other hand the user's request is not to be redirected, then the processing proceeds to step s17 where the database server 15 loads and runs the lookup program 19, which accesses the user address lookup table 21, to identify the current network address for the user who made the request and to determine, from the stored content directory 27, the storage location of the requested video file within the local hard discs 33.

The processing then proceeds to step sl9 where the database server 15 updates the redirect data 23 to take into account the delivery of the new stream to the user.

In particular, if the delivery of the new stream results in an additional video stream being generated and output to the local network 41 by the video server 13, then the

database server 15 updates the score identifying how busy the video server 13 is, so that the actual state of the video server 13 is used to control whether or not subsequent user requests are redirected. Similarly, if a user request is a request to stop the streaming of a video file, then in addition to the playout controller 53 generating the appropriate control signals to stop the video stream, it also informs the database server 15 of the stopping of the stream so that the score identifying how busy the video server 13 is can be updated to indicate that it is no longer as busy as it was.

In this embodiment, the updated score for the video server 13 is not transmitted to the management server 1 each time that it is updated. Instead, the updated score for the video server 13 is transmitted to the management server 1 upon request from the management server 1. As will be discussed below, when the updated scores for all the local servers 5 are transmitted to the management server 1, the management server 1 recalculates new redirect data 23 for each of the local servers 5, which it downloads to the respective local servers 5 in order to keep them up-to-date with how busy the other local servers 5 are. In this embodiment, after the redirect data 23 has been updated in this way, the look-up program

19 returns, in step s21, the user network address and the local storage location determined in step s17 back to the playout control unit 39.

After step s9, step s15 or step s21, the processing proceeds to step s23 where the database server 15 updates the video delivery and redirect statistics 25. In particular, the database server 15 keeps a record as to whether the user request failed, was redirected or was serviced by the video server 13. This record also identifies the time at which the request was made, the user that made the request and the video file that was requested. As mentioned above, these video delivery and redirect statistics 25 are transmitted from time to time back to the management server 1, which analyses the various requests that have been made to all of the local servers 5 and decides what content files should be copied to each of the local servers 5 and what content files already stored in the local servers 5 should be deleted.

In steps s9, s15 and s21, the database server 15 returns data to the playout control unit 39 of the video server 13, identifying if the user request has failed, if it is to be serviced by the video server 13 or if it is to be redirected to another server. As shown in Figure 3, this

data is received at the playout controller 53 of the playout control unit 39. If the returned data indicates that the video server 13 has the requested video file and is to output the file to the user, then the playout controller 53 outputs the appropriate control signals to the disc reading unit 55 and to the video pumps 31 so that the requested video file can be streamed to the user. The playout controller 53 also outputs an appropriate proceed command to an RTSP response transmitting unit 57 which transmits the RTSP proceed command back to the user's set-top box 35. This proceed command informs the user's set-top box 35 that the requested video file is about to be streamed from the video server 13.

If the data returned from the database server 15 indicates that the user's request has failed, then the playout controller 53 formats an appropriate fail message which it passes to the RTSP response transmitting unit 57 which transmits the fail RTSP message back to the user's set-top box 35.

If the data returned from the database server 15 indicates that the user's request is to be redirected to another server, then the playout controller 53 formats

an appropriate redirect message identifying the server to which the user should be redirected, which message is passed to the RTSP response transmitting unit 57 which transmits the appropriate RTSP redirect command to the user's set-top box 35, so that the user can send the request again to the server identified in the redirect message.

USER SET-TOP BOX Figure 5a is a schematic block diagram illustrating the main components of the user set-top box 35 used in this embodiment. As shown, the set-top box 35 includes an RTSP controller 71 which can communicate with the playout control unit 39 using the Internet RTSP control protocol.

As shown in Figure 5a, the RTSP controller 71 receives user input via the user interface 73. As discussed above, this user input either relates to commands for controlling the playout of an existing video file being received at the set-top box 35 or relates to a request for a new video stream. The RTSP controller 71 is arranged to format and transmit the appropriate RTSP request to the playout control unit 39 of the local server 5 normally assigned to service that user. The format of a typical message 72 transmitted by the RTSP controller 71 is illustrated in Figure 5b. As shown, the

message 72 includes a server address portion 74 identifying the Internet address of the user's usual local server 5; a user ID portion 76 which identifies the user to the local server 5; and a user request portion 78 which identifies the user request.

When the request relates to a request for a new video stream, the RTSP controller 71 transmits the message 72 as an RTSP setup request and the user request portion 78 identifies the requested video file. If the request relates to a command for controlling the delivery of an existing video stream, then the RTSP controller 71 transmits the message 72 as the appropriate RTSP command in which the request portion 78 identifies the requested action. The RTSP controller 71 also receives the responses back from the playout control unit 39 identifying if the user's request has failed, is proceeding or if it is to be redirected to another server. If the response is an RTSP redirect, then the RTSP controller 71 extracts from the RTSP redirect message and without interaction from the user, the network address for the server to which the redirection is to be made and reformats the user query using the received network address in the server address portion 74. This received network address data is also stored

within the RTSP controller 71, so that any subsequent user control command relating to the requested video file will be directed to the correct server. Once the requested stream of video data ends or if the user stops the video stream before it has reached the end, the RTSP controller 71 deletes the stored network address and directs any future user requests to the usual local server 5 that services the user set-top box 35 (the network address of which is also stored within the RTSP controller 71).

As shown in Figure 5a, the user set-top box 35 also includes a video stream receiving unit 75 which operates to receive the video stream transmitted from the local server 5 via the local network 41. This stream of video data is then processed and decoded by a video decoder 77 which converts the stream into appropriate video signals for playing out on the user television 37.

As those skilled in the art will appreciate, either the user request will fail or eventually one of the local servers 5 or the management server 1 will stream the requested video data to the user set-top box 35. Eventually, therefore, the RTSP controller 71 will either receive a fail command or a proceed command. In this

embodiment, the RTSP controller 71 is arranged so that when it receives a fail command, it outputs an appropriate control signal to the video decoder 77 to cause an error message to be output to the user on the user television 37 to inform the user that his request could not be serviced. Similarly, when the RTSP controller 71 receives the proceed command from the server that will service the user request, the RTSP controller 71 outputs a control signal to the video decoder 77 to cause a message to be displayed to the user informing the user that the requested video stream is about to be received.

MANAGEMENT SERVER As discussed above, the main functions of the management server 1 are to control the distribution of content files to and the deletion of content files from each of the local servers 5 and to maintain and update the redirect data 23 and redirect programs 18 used in each of the local servers 5 to determine whether or not a user request is to be redirected. The way in which this is achieved in this embodiment will now be described with reference to Figure 6.

As shown in Figure 6, the management server 1 includes

a video server statistics retrieval unit 81 which operates to poll the local servers 5 for them to transmit their stored video delivery and redirect statistics 25. In this embodiment, the video server statistics retrieval unit 81 is arranged to poll each of the local servers 5 every few minutes. Once the video delivery and redirect statistics 25 have been transmitted to the video server statistics retrieval unit 81, each local server 5 deletes this data from the database 17 in order to minimise storage space required within the database 17. The statistics received at the retrieval unit 81 are then passed to a statistics processing unit 83 where they are processed together with historical data from a historical database 85. In this embodiment, the statistics processing unit 83 reacts to the"live"redirect statistics 25 received from the retrieval unit 81 according to a predetermined set of rules (not shown), in order to try to respond to current demand by determining if any new content files should be downloaded to any of the local servers 5, if duplicates of any content files already on a local server 5 should be made and if any content files should be deleted from any of the local servers 5. For example, if the redirection statistics identify that a particular local server 5 has received a number of requests for the same film from a

number of different users, then the statistics processing unit 83 may decide to download a copy of that film to that local server 5.

The statistics processing unit 83 also uses the historical data from the historical database 85 in order to try to identify any trends in the user requests (for example, illustrating that users in a particular geographic locality prefer a certain type of video) in order to try to predict what the demand will be in the future. For example, the statistics processing unit 83 may be able to process the historical data to identify that users in a particular geographic region access more romantic comedy films than action and horror films. The statistics processing unit 83 can then use this information to determine what films the users in that locality are likely to request in the future and hence what films should be stored locally for that geographic region. In this embodiment, the historical database 85 also includes marketing data identifying details of any marketing campaigns used or about to be used to promote the launch of a new video film. The statistics processing unit 83 then uses this marketing data to identify the geographic regions in which it thinks the film will be in most demand and then ensures that the new

5 10 15 20 25 video film is copied to the local servers 5 that will service those regions. The historical database 85 can also include data identifying trends in viewing habits from geographic regions which are ahead in time of the geographic regions being serviced by the local servers 5. For example, if the video distribution system is serving the west coast of the US and a similar distribution system is serving the east coast of the US, then data identifying the viewing habits from the east coast may be used to predict user demand in the west coast at the corresponding times.

In this embodiment, the statistics processing unit 83 outputs visual warning signals to a human operator via an operator display 88. For example, if the statistics processing unit 83 identifies that over a predetermined period of time, a single local server 5 has redirected more than a predetermined number of requests for the same film, it outputs a warning to the operator. Different levels of warnings may be displayed depending on the number of requests that have been redirected. In this way, a human operator can monitor the redirects that are occurring and can make overriding commands via an operator interface 89 as appropriate. For example, the operator may identify that more and more of the local

servers 5 are beginning to receive requests for a given film. The operator may then take the decision to copy that film to all or some of the local servers in anticipation of future requests made to the local servers 5. These overriding actions are input via the operator interface 89 to the statistics processing unit 83, which then takes the appropriate action to ensure that the content is distributed in the required way.

In this embodiment, the statistics processing unit 83 also determines from the redirect statistics whether or not any video data files already stored on any of the local servers 5 are to be deleted from those servers (either because they are not being accessed or because a licence needed for distributing the film has expired) or are to be copied so that multiple copies of the video file are available from the same local server 5.

By reacting to the live redirect statistics in this way and by using the data in historical database 85 to predict what content will be required, the statistics processing unit 83 tries to ensure that the appropriate video files are stored locally within each local server 5 in order to try to minimise the number of user requests that are redirected to the management server 1. In this

way, the costly use of bandwidth on the core network 7 can be kept to a minimum whilst also minimising the amount of storage space required at the local servers 5.

In this embodiment, the actual distribution of the video files and the deletion of the video files from the local servers 5 are controlled by a content distribution engine 87. As shown in Figure 6, the content distribution engine 87 receives the content from the content stores 3 shown in Figure 1. It also receives the control signals identifying where the content should be distributed from the statistics processing unit 83. In this embodiment, the content distribution engine 87 schedules appropriate times for the content files to be distributed to the local servers 5. The content files may be distributed immediately or they can be scheduled to be distributed at some time in the future. If the files are to be distributed at some time in the future, the content distribution engine 87 transmits a placeholder command to the local servers 5, identifying the content file that is to be downloaded, the time that it is to be downloaded and the size of the file.

As mentioned above, in this embodiment, the content files are distributed to the local servers 5 using a file

transfer protocol (FTP). In this embodiment, the content distribution engine 87 is arranged to copy the content file to one local server 5 together with instructions of other local servers 5 in its vicinity to which the local server 5 should copy the received content file. In this way, the traffic burden of transmitting separate content files to each local server 5 through the core network 7 can be minimised. The use of the placeholder entries discussed above is also advantageous since they allow the initial local server 5 to schedule the copying of the new content file to the other local servers 5 before the new content file has arrived. The use of such placeholder entries also allows the destination server to perform the actual copying rather than the source server 1. This allows the management server 1 to concentrate on the various other management tasks that it must perform.

As shown in Figure 6, the management server 1 also includes a video server scores retrieval unit 91 which operates to poll each of the local servers 5 to transmit the current score indicating how busy the local server 5 is from the redirect data 23 stored in the database 17.

The polling of the local servers 5 for this score information may be done independently from or combined with the polling performed by the video server statistics

retrieval unit 81. The scores received at the scores retrieval unit 91 are then passed to a redirect scores determining unit 93 which collates the scores for all of the local servers 5 together and generates appropriate redirect data 23 for each of the local servers 5. The redirect scores determining unit 93 does this using the current scores identifying how busy each of the local servers 5 is together with network data which defines the "network cost"for redirecting a user from one local server 5 to another. This network cost data is stored in a network database 95. Since the local servers 5 will in general be fixed relative to each other, the system can determine in advance the approximate network cost for redirecting a user in the locality of one local server 5 to another local server 5. In this embodiment, this network cost data is only changed if a significant event occurs in the network connecting the local servers 5 to the user set-top boxes 35. For example, if part of the network becomes disrupted such that a local server 5 cannot deliver video files to users in a particular locality, then this information is used to update the network costs stored in the network database 95, to ensure that requests from users in that locality are not redirected to that local server 5. This network control information is received by the network database 95 on the

control line 97.

As discussed above, in this embodiment the redirect data 23 for a local server 5 includes a single score for each of the other local servers in the system. The score associated with each of the other local servers 5 is a combination of the network cost for redirecting a user to that other local server and the score identifying how busy that other local server 5 is. In this embodiment, the combination is a biased linear combination in which more emphasis is placed on the score identifying how busy each local server is. Other combinations could of course be used.

As those skilled in the art will appreciate, the redirect scores determining unit 93 determines different redirect data 23 for each local server 5. The redirect data 23 for all of the local servers 5 can therefore be analysed to identify natural groupings of local servers 5 that can effectively service the same group of users. In this embodiment, these natural groupings are determined and output by the redirect scores determining unit 93 to the operator display 88. The operator of the management server 1 can then use this grouping information in determining how content should be distributed to the

local servers 5. The operator can also change the redirect data 23 for any of the local servers 5 in order to exercise some management control over the local servers 5 to which each local server 5 normally redirects user requests. In this embodiment, the operator display 88 also displays the scores identifying how busy the local servers 5 are. In this way, the operator of the management server 1 is presented with a visual indication of how busy each local server 5 is, together with an indication of other local servers 5 that can costeffectively service the users in the locality of that local server, thereby allowing the operator to be able to manually alter the redirect data being determined by the determining unit 93.

In this embodiment, the management server 1 also keeps track of the redirection rules (i. e. the redirect programs 18) used by each of the local servers 5. In this embodiment, each of the local servers 5 may be programmed with a different redirect program 18. These programs are set by a redirect program setting unit 101 which can receive a control input from the operator of the management server 1 via the operator interface 89. In this way, provision is made to allow the management server 1 to be able to vary dynamically the way in which

each local server 5 determines whether or not to redirect a user request. In this embodiment, the redirect program setting unit 101 is arranged to generate the redirect program 18 for each local server based on a predetermined set of rules and any overriding action by the operator.

For example, the redirect program setting unit 101 may be arranged to initially program each local server 5 with the same set of redirect rules. However, from the processing of the redirect statistics, the management server 1 may establish that some local servers 5 only ever redirect to a few other local servers. Therefore, the operator may decide to change the redirect program for those servers so that if the local server cannot service a user request, it simply redirects the user to one of those other servers. This results in a simplification of the redirect program 18 used in those local servers 15.

In this embodiment, the redirect programs 18 are stored within the database 17 of each local server 5 since this facilitates the ability to be able to vary dynamically the redirect program 18. In particular, since the programs are stored as data within the database, it is relatively straightforward to change part of the redirect program 18, such as parameters used in the program,

without having to download an entire new redirect program 18. For example, threshold values used in the redirect program 18 may be changed simply by changing the corresponding data entry within the database 17, without having to change the entire program.

The management server 1 also includes a database management tool 103 which operates to combine the content directory 27 stored on each of the local servers 5 into a single content directory identifying all of the films available to the system and identifying where those films are stored. This global content directory is then made available to other servers, such as the electronic program guide (EPG) server 12 shown in Figure 1. In this embodiment, the EPG server 12 uses this global content directory to create an appropriate program guide which is made available to subscribers via the core network 7.

The subscribers can then browse through the program guide to see the video files that are available and then select a desired video file to watch.

MODIFICATIONS AND ALTERNATIVE EMBODIMENTS A video distribution system is described above in which video files are distributed from a central management server to a number of local servers distributed over the

geographic area serviced by the system. The aim of the distribution is to minimise the serving of individual users by the central management server, thereby reducing the amount of bandwidth used in the core network connecting the management server to the local servers.

The local servers are arranged to store only a subset of the video files available to the management server (in order to reduce the required storage space at the local servers), the subset being selected in order to try to maximise the likelihood of the local server being able to service requests from users within its locality. In the event that a user request cannot be handled by the local server, the user is either redirected to another local server or redirected back to the management server.

As those skilled in the art will appreciate, a number of modifications can be made to the system described above.

A number of these modifications will now be described for illustration.

In the above embodiment, a two-layer hierarchy was described in which a plurality of local servers communicated directly with a single management server. As those skilled in the art will appreciate, other hierarchical arrangements may be provided. For example, the geographic area to be serviced by this system may be

divided into regions, with a separate intermediate management server linking local servers within each region to a national management server. Such an embodiment is illustrated in Figure 7 which shows the way in which the hierarchy may be arranged for England, with a national operations centre 101 being provided to control management servers associated with each county in England (illustrated as the Durham control server 103, the Essex control server 105, the Kent control server 107, the Norfolk control server 109 and the Suffolk control server 111). Each of these county servers then controls a number of local servers which service users within subregions of the county. Again, this is illustrated in Figure 7 by the local servers connected to the Norfolk control server 109 which include the Cromer video server 113, the Lowestoft video server 115 and the Norwich video server 117. In addition, there may be two or more servers assigned to each region or subregion to provide redundancy or to share the processing load. This is illustrated in Figure 7 by the two video servers 117a and 117b provided for Norwich.

The operation of such a three-level hierarchy is similar to the operation of the first embodiment, except that the national operations centre 101 will control the

distribution of data to each of the county servers and then each county server will be responsible for controlling the distribution of content to the individual local servers under its control. With a multilayered hierarchy, it is possible to simplify the redirect algorithm used to control the redirection of users by simply referring the user to the next layer up in the hierarchy. For example, if the Cromer video server 113 receives a request for a video file from a user that the Cromer video server cannot service (either because it is too busy or because it does not have the requested video file), then it can be configured to simply redirect the user's request to the Norfolk control server 109.

In the above embodiments, a hierarchical video distribution system was described. As those skilled in the art will appreciate, it is not essential that the servers are connected in such a hierarchical manner. All of the local servers may operate in groups, with no overall management server being provided. In this case, if a server of a group cannot service a user request, the local server would redirect the user to another one of the local servers in the same group. As in the first embodiment described above, the redirection may be controlled based on how busy the other local servers

within the group are. In this case, each of the local servers within a group will have to inform the other servers from time to time of how busy they are. Alternatively, the redirection may be a static one in which each local server within a group is configured to redirect the user to a respective different one of the other local servers in the group.

In the embodiment described above with reference to Figure 7, two servers were provided for Norwich. In the general case, N active servers may be provided for any given location together with M standby servers. In this case, the redirection algorithm may be arranged to redirect users between the active servers and, if these are all busy or have failed, to redirect the user to one of the standby servers.

In the main embodiment described above, the management server polled each of the local servers to transmit the redirect statistics and the score identifying how busy the local server is. In an alternative embodiment, the redirect statistics and/or the updated scores may be transmitted automatically from each local server to the management server intermittently or at predetermined times. Alternatively still, a combination of polling and

automatic transmission may be used.

In the above embodiments, a user makes a request for a new video file from their local server and if the local server cannot service the request then a redirect command is transmitted back to the user identifying a different server to which the user should direct another request. In an alternative embodiment, the local server may redirect the user's request directly to the other server, so that the user does not have to initiate another request to that other server.

In the main embodiment described above, the redirect statistics processing unit processed the redirect statistics received from the various local servers and automatically determined how content should be distributed to and deleted from the local servers based on these statistics and the data stored in the historical database. As those skilled in the art will appreciate, this may be done in a number of different ways. For example, the received data may be input to a neural network or an expert system which generates the appropriate control signals for controlling the content distribution engine. The rules used by the redirect statistics processing unit may be template-based,

allowing the user the ability to change the way in which content is distributed simply by changing parameters of the rules. Example rules which may be used include: i) after N failures for a file by a local server- initiate a copy of the file to that local server; ii) if no one has accessed a file for a period X from a given server, delete the file from that local server; iii) if a given file is being streamed to more than M users from a local server-duplicate the content file on that local server.

In addition to being able to define rules which can respond to the live statistics, other rules will be provided to deal with the historical data and the marketing data stored in the historical database. For example, a top ten list of video files may be defined, with the statistics processing unit being arranged to automatically copy any new video file added to this top ten list to a predefined subset of the local servers 5.

In the main embodiment described above, requests from users were treated on an equal basis. In an alternative embodiment, different levels of service may be provided to different users. For example, there may be a gold

level of service, a silver level of service and a bronze level of service, in which gold users get a better level of service than silver users, which in turn get a better level of server than bronze users. This may be used, for example, to control the redirect program stored at each of the local servers. For example, if the distribution system is operating at a highest capacity, then preference will be given to new requests coming from gold users and requests from bronze users may be declined service.

In the main embodiment described above, each of the local servers redirected user requests based on whether or not the local server has the requested video file and based on how busy the local server currently is. In an alternative embodiment, the local server may redirect users based on some attribute of the user that it making the request. For example, the local servers may be designed only to operate for users having a particular type of set-top box, and to redirect users with a different type of set-top box to another local server. This may be the case, for example, where a local server can only deliver MPEG video files but where some users in the locality of the local server may only be able to accept a different format of video files. In this case,

as long as the local server knows which local servers can provide the video data in the correct format, the local server can redirect the user to the appropriate server. In the above embodiments, a local server was provided to service the requests of users within the proximity of the local server. Whilst this geographic association between the users and the local server is preferred, the association between the users and the local servers may be dependent on the availability and connection between the user and the local server. For example, if a user in London has a leased line to a server located in Edinburgh, then the local server for the user in London may be located in Edinburgh and not in London. The term "local server"used throughout this description is intended to cover such situations.

In the above embodiment, the user devices 11 transmitted requests to the local servers through the same data network via which the video streams are transmitted. As those skilled in the art will appreciate, this is not essential. The user requests may be transmitted to the local servers on a completely separate communication link between the user device and the local server. However, such an embodiment is not preferred because it would

require two communication interfaces within the user device.

In the above embodiments, each of the local servers controls whether or not it will redirect a user request to another server. In an alternative embodiment, the redirect rules may be embedded within the network (for example in a switch or router) located between the user and the local server. This is illustrated in Figure 8 which shows a user set-top box 35 which connects to a telephony data switch 121 (such as an ADSL switch) which includes the redirect program 18. In this embodiment, the redirect program 18 determines whether or not to pass the user request onto the local server 5-A or to pass the user request through the core network 7 and data switch 123 to the local server 5-B. Since the redirect program 18 can determine where to redirect a user request by comparing scores associated with each of the local servers 5, the data switch 121 can quickly identify where to route the user request. These scores can then be updated from time to time as in the first embodiment.

The advantage of providing the redirect program 18 within the data switch 121 is that it reduces the design and hence cost requirements on the local servers 5 in order

to achieve the same quality of service. In particular, the local dial-up switches 121 are designed to be very robust so that they can remain online nearly all the time. Consequently, the switches are nearly always able to perform the redirect operation. In contrast, the local servers 5 are more complex and are more liable to go offline. Therefore, if the redirect program 18 is stored within the local server 5 and it goes offline, then any user who initially connects to that local server 5 will not be able to receive service from that local server 5 or for that matter from any other server since they will not be able to be redirected to the other server.

In the above embodiment, the content files being distributed were video files. As those skilled in the art will appreciate, the above distribution systems can be used to distribute any type of content files, such as audio data or financial data such as the financial data provided by Reuters.

In the above embodiment, the RTSP control protocol was used by the user set-top box and the local servers to communicate the user requests and to inform the user of any redirects. As those skilled in the art will

appreciate, other protocols may be used. The advantage of using the RTSP control protocol, however, is that it allows the user's set-top box to communicate with the local server using standard RTSP controller software.

In the above embodiment, each user has an associated user set-top box which is connected to a user television. In an alternative embodiment, one or more of the users may connect to the local servers via a personal computer or the like, in which case the video may be streamed and played on the monitor of the computer.

In the above embodiment, the management server used network data to identify the network cost for redirecting a user from one local server to another local server. The management server can therefore analyse the network cost data to identify natural groupings of the local servers. In practice, the servers within a group are likely to be geographically close to each other, although this may not necessarily be the case. After the management server has identified the different groupings, a separate management server or one of the local servers in the group may be arranged to monitor the other local servers in the group. For example, the management server for a group may be arranged to transmit messages to the

local servers in the group in order to establish their current status. Consequently, if one of the local servers of the group goes off-line, then the management server can quickly update the redirect data for the other members of the group so that users are not redirected to that server. Alternatively, instead of having a single management server for the group, all of the servers within the group may be arranged to transmit messages between themselves in order to keep track of the status of the servers within the group.

In addition to using the network cost data to identify natural groupings of the local servers, the management server may use this grouping information to ensure that all content files that are available to the system can be obtained from one of the servers within the group.

In this way, the system can minimise the possibility of a user request being redirected to a local server out with the group.

In the main embodiment described above, the content data files were streamed over a communications network to user

devices that requested the content files. In an alternative embodiment, the above system can be used to control the downloading (as opposed to the streaming) of the content files to the user devices. Whilst such downloading of the content files will not allow the real time playback of the video file, it will allow a timeshifted playback of the video file to be carried out within the user device. In particular, the content file may be downloaded and stored in the user device and then played out upon request to the user at a later time point.

In the first embodiment described above, the redirect program was stored as a stored procedure within a database of the local server. This allowed the remote management server to be able to dynamically change the redirect program simply by changing the data stored in the database 17. As those skilled in the art will appreciate, whilst storing the redirect program as data in a database provides a number of advantages, it is not essential to store the redirect program in this way. The redirect program may be stored within the video server and run when needed. In this case, the software may be in the form of source code, object code or a code intermediate source and object code. The software may

be downloaded to the local server over the core network or on a carrier such as a ROM or a CD.

Claims

CLAIMS: 1. A content data distribution system comprising: a plurality of content computer servers, each storing a plurality of content data files and being operable to generate and output content data files upon request; a plurality of user devices, each being operable (i) to store data associating the user device to a content computer server; (ii) to receive a user input and to generate therefrom a user request identifying a user requested action; and (iii) to transmit said user request to the associated content computer server; a communications network operable for establishing communication links between said plurality of user devices and said plurality of content computer servers, for transporting said content data files from said content computer servers to said user devices; wherein at least one of said content computer servers has an associated user request processing unit comprising: i) means for receiving a user request for a content data file, transmitted from a user device associated with said at least one content computer server;

<Desc/Clms Page number 51>

ii) means for determining if the associated at least one content computer server can provide the requested content file;

iii) means for causing said associated at least one content computer server to generate and to output the requested content file over said communications network to the associated user device, if said determining means determines that the associated content computer server can provide the requested content file; and iv) means for redirecting the associated user device to another one of said content computer servers, if said determining means determines that the associated content computer server cannot provide the requested content file.
2. A system according to claim 1, wherein said redirecting means is operable to redirect the associated user device by sending a data message to the associated user device identifying the other content computer server.
3. A system according to claim 1 or 2, wherein said redirecting means is operable to redirect the associated user to another content computer server having an associated user request processing unit and wherein said

<Desc/Clms Page number 52>

redirecting means is operable to redirect the associated user device to said other content computer server via the user request processing unit associated with said other content computer server.
4. A system according to claim 1, wherein said redirecting means is operable to redirect the associated user device by forwarding the received user request to said other content computer server.
5. A system according to any preceding claim, wherein said determining means comprises means for comparing the requested content file with data identifying the content files stored in said associated content computer server, to determine if the content file is stored in the associated content computer server.
6. A system according to claim 5, wherein said data identifies the content files stored on one or more of the other content computer servers and wherein said determining means determines which, if any, of the other content computer servers stores the requested content file.
7. A system according to claim 6, wherein if said

<Desc/Clms Page number 53>

determining means determines that the associated content computer server cannot provide the requested content file, said redirecting means is operable to redirect the associated user to one of the content computer servers identified by the determining means as storing the requested content file.
8. A system according to any preceding claim, wherein said determining means is operable to determine if the associated at least one content computer server can provide the requested content file based on a current status of the associated content computer server.
9. A system according to claim 8, wherein said determining means is operable to determine if the associated at least one content computer server can provide the requested content file on the basis of how busy the associated at least one content computer server is.
10. A system according to claim 9, wherein the associated content computer server includes a current score indicating how busy the associated at least one content computer server currently is and wherein said determining means determines if the associated at least

<Desc/Clms Page number 54>

one content computer server can provide the requested content file on the basis of the current score.
11. A system according to claim 10, wherein said determining means is operable to determine if the associated at least one content computer server can provide the requested content file by comparing said current score with a predetermined threshold.
12. A system according to claim 10 or 11, further comprising means for updating said current score each time a new stream of content data is generated by the at least one content computer server.
13. A system according to claim 12, wherein said updating means is operable to update said current score each time said at least one content computer server stops generating a stream of content data.
14. A system according to any of claims 10 to 13, wherein each of said plurality of content computer servers includes a score identifying how busy the content computer server currently is and means for updating the score on the basis of received user requests.

<Desc/Clms Page number 55>
15. A system according to any preceding claim, wherein said plurality of content computer servers are operable to transmit redirect data identifying a current status of the corresponding content computer server to said at least one content computer server.
16. A system according to any of claims 1 to 14, further comprising a management server, wherein said plurality of content computer servers are operable to transmit current scores identifying the current status of the corresponding content computer server to said management server, and wherein said management server is operable to transmit redirect data identifying how busy each of the other content computer servers are to said user request processing unit of said at least one content computer server.
17. A system according to claim 16, wherein said management server comprises network data identifying a network cost for redirecting users from said at least one content computer server to each of a plurality of the other content computer servers, and wherein said redirect data is determined from the scores received from the plurality of content computer servers and said network data.

<Desc/Clms Page number 56>
18. A system according to claim 17, wherein said management server is operable to process said network data to identify groups of said content computer servers for which there is minimal network cost associated with redirecting user requests from any content computer server in the group to another content computer server in the group.
19. A system according to any of claims 16 to 18, wherein said plurality of content computer servers are operable to transmit, from time to time, updated scores identifying the current status and wherein said management server is operable to transmit, from time to time, updated redirect data to said user request processing unit of said at least one content computer server.
20. A system according to any of claims 15 to 19, wherein said redirecting means is operable to determine the other content computer server to which the user is to be redirected based on the received redirect data.
21. A system according to any preceding claim, wherein said user request processing unit further comprises means for storing data identifying user requests that have been

<Desc/Clms Page number 57>

received.
22. A system according to claim 21, further comprising a management server, wherein said user request processing unit comprises means for transmitting said data identifying user requests that have been received to said management server and wherein said management server is operable to control the content files stored on said at least one content computer server on the basis of the received data.
23. A system according to claim 22, wherein said storing means is operable to store data identifying what redirects have been made, wherein said transmitting means is operable to transmit said data identifying said redirects to said management server and wherein said management server is operable to control the content files stored on said at least one content computer server on the basis of the received data identifying what redirects have been made.
24. A system according to claim 22 or 23, wherein said storing means is operable to store data identifying: the user requests that have been made, the requests that have been serviced by the associated content computer server;

<Desc/Clms Page number 58>

the requests that have been redirected to another content computer server; and details of the content file requested by the user device, wherein said transmitting means is operable to transmit said stored data to said management server and wherein said management server is operable to control the content file stored on said at least one content computer server on the basis of the data transmitted from said user request processing unit.
25. A system according to any of claims 22 to 24, wherein said management server is operable to control the copying of content files to said at least one content computer server and the deleting of content files from said at least one content computer server.
26. A system according to any of claims 22 to 25, wherein said management server is operable to control the duplicating of content files on said at least one content computer server.
27. A system according to any of claims 22 to 26, wherein said management server has an associated content store which stores a plurality of content files and wherein each of said plurality of content computer servers stores a subset of the content files stored in

<Desc/Clms Page number 59>

said content store associated with said management server.
28. A system according to any of claims 22 to 27, wherein said management server is operable to control the copying of content files to said at least one content computer server in dependence upon an input received from an operator associated with the management server.
29. A system according to any of claims 22 to 28, wherein said management server is operable to control the copying of content files to said at least one content computer server in dependence upon historical redirect data received from said at least one content computer server.
30. A system according to any of claims 22 to 28, wherein said management server includes means for storing network data identifying network costs associated with redirecting a user request from said at least one content computer server to another one of said content computer servers, and wherein said management server is operable to control the copying of content files to said at least one content computer server in dependence upon the content files stored on said other content computer

<Desc/Clms Page number 60>

servers and said network cost data.
31. A system according to any preceding claim, wherein said user request processing unit associated with said at least one content computer server forms part of said at least one content computer server.
32. A system according to any of claims 1 to 30, wherein said user request processing unit associated with said at least one content computer server forms part of said communications network.
33. A system according to claim 32, wherein said user request processing unit associated with said at least one content computer server forms part of a switch or a router of said communications network.
34. A system according to any preceding claim, wherein said determining means comprises a computer program stored as data in a database and a processor for retrieving the data and executing the stored program.
35. A system according to claim 34, wherein said user request processing unit further comprises means for changing the data stored in said database in order to

<Desc/Clms Page number 61>

update said determining means.
36. A system according to claim 35, wherein a remote management server includes means for changing the data stored in said database in order to update said determining means.
37. A system according to claim 35 or 36, wherein said updating means is operable to update said determining means such that the determination made is time-dependent.
38. A system according to any preceding claim, wherein said redirecting means comprises a computer program stored as data in a database and a processor for retrieving the data and executing the stored program.
39. A system according to claim 38, wherein said user request processing unit further comprises means for changing the data stored in said database in order to update said redirecting means.
40. A system according to claim 38, wherein a remote management server includes means for changing the data stored in said database in order to update said redirecting means.

<Desc/Clms Page number 62>
41. A system according to claim 39 or 40, wherein said updating means is operable to update said redirecting means such that the redirection that is performed is time-dependent.
42. A system according to any preceding claim, wherein at least one of said user devices is operable to transmit said user request to the associated content computer server using a real time control protocol.
43. A system according to any preceding claim, wherein each of said plurality of content computer servers comprises an associated user request processing unit.
44. A system according to any preceding claim, wherein said plurality of content computer servers are arranged in groups, wherein a management server is provided for each group and wherein a supervising management server is provided to supervise the operation of the management servers.
45. A system according to any preceding claim, wherein said at least one content computer server is operable to stream content data corresponding to requested content files.

<Desc/Clms Page number 63>
46. A content data distribution system comprising: a plurality of content computer servers, each storing a plurality of content data files and being operable to generate and output content data files upon request; a plurality of user devices, each being operable (i) to store data associating the user device to a content computer server; (ii) to receive a user input and to generate therefrom a user request identifying a user requested action; and (iii) to transmit said user request to the associated content computer server; a communications network operable for establishing communication links between said plurality of user devices and said plurality of content computer servers, for transporting said content data files from said content computer servers to said user devices; and a management computer server operable to receive data transmitted from at least one of said content computer servers and operable to control the copying of content files to said at least one content computer server; wherein said at least one content computer server is operable to receive user requests for content files from one or more associated user devices and is operable to transmit data identifying the user requests that have

<Desc/Clms Page number 64>

been received, to said management server; and wherein said management server is operable to control the copying of content files to said at least one content computer server based on the data received from said at least one content computer server.
47. A method of distributing streamed content data files to a number of user devices from a number of content computer servers through a communications network, the method comprising the steps of: storing at each content computer server a plurality of content data files; at each of the user devices, i) storing data associating the user device to a content computer server; ii) receiving a user input and to generate therefrom a user request identifying a user requested action; and iii) transmitting said user request to the associated content computer server; wherein at least one of said content computer servers has an associated user request processing unit which carries out the following steps: i) receiving a user request for a content data file, transmitted from a user device associated with said at least one content computer server;

<Desc/Clms Page number 65>

ii) determining if the associated at least one content computer server can provide the requested content file ; iii) causing said associated at least one content computer server to generate and to output the requested content data file over said communications network to the associated user device, if said determining step determines that the associated content computer server can provide the requested content file ; and iv) redirecting the associated user device to another one of said content computer servers, if said determining step determines that the associated content computer server cannot provide the requested content file.
48. A method of distributing streamed content data files to a number of user devices from a number of content computer servers through a communications network, the method comprising the steps of: storing at each content computer server a plurality of content data files ; at each of the user devices, i) storing data associating the user device to a content computer server; ii) receiving a user input and generating therefrom

<Desc/Clms Page number 66>

a user request identifying a user requested action; and iii) transmitting said user request to the associated content computer server; at said content computer servers, outputting requested content files to the user devices over said communications network; providing a management computer server for receiving data transmitted from at least one of said content computer servers and for controlling the copying of content files to said at least one content computer server; receiving at said at least one content computer server user requests for content files from one or more associated user devices and transmitting data identifying the user requests that have been received to said management server; and at said management server, controlling the copying of content files to said at least one content computer server based on the data received from said at least one content computer server.
49. A user request processing unit for use in any of claims 1 to 45 comprising: i) means for receiving a user request for a content data file, transmitted from a user device

<Desc/Clms Page number 67>

associated with a content computer server; ii) means for determining if the content computer server can provide the requested content file; iii) means for outputting control signals for causing said content computer server to generate and to output the requested content file over a communications network to the user device, if said determining means determines that the content computer server can provide the requested content file ; and iv) means for redirecting the user device to another content computer server, if said determining means determines that the content computer server cannot provide the requested content file.
50. A user device for use in a content data distribution system according to any of claims 1 to 45, comprising: means for storing data associating the user to a content computer server ; means for receiving user input and to generate therefrom a user request identifying a user requested action; means for transmitting said user requested action to the associated content computer server; means for receiving a response from the associated content computer server identifying:

<Desc/Clms Page number 68>

i) if the user request has failed; ii) if the user request is to proceed; or iii) if the user device is to be redirected to a different content computer server; and wherein if said response identifies that the user request is to be redirected to another content computer server, said transmitting means is operable to retransmit said user request to said other content computer server.
51. A content data distribution control apparatus for controlling a plurality of content computer servers, the apparatus comprising: means for receiving status data from said plurality of content computer servers indicative of their current status; means for receiving network data identifying a network cost associated with redirecting a user request from at least one of said content computer servers to another one of said content computer servers; and means for processing said status data and said network data to determine redirect data for said at least one content computer server for use thereby in determining where to redirect a user request.
52. A content data distribution control apparatus for

<Desc/Clms Page number 69>

controlling a plurality of content computer servers, the apparatus comprising: means for receiving data from said plurality of content computer servers, identifying user requests for content data from said content computer servers; means for processing the received data to determine content data files to be copied to at least one of said content computer servers; and means for controlling the copying of the determined content data files to said at least one content computer server.
53. A management server comprising any of the management server characteristics claimed in any of claims 16 to 19, 22 to 30 and 46.
54. A computer readable medium storing computer executable instructions for causing a programmable computer device to become configured as the user request processing unit of any of claims 1 to 45.
55. Computer executable instructions for causing a programmable computer device to become configured as the user request processing unit of any of claims 1 to 45.

<Desc/Clms Page number 70>
56. A computer readable medium storing computer executable instructions for causing a programmable computer device to become configured as the content computer server of any of claims 1 to 45.
57. Computer executable instructions for causing a programmable computer device to become configured as the content computer server of any of claims 1 to 45.
58. A computer readable medium storing computer executable instructions for causing a programmable computer device to become configured as the management server of any of claims 16 to 19,22 to 30 and 46.
59. Computer executable instructions for causing a programmable computer device to become configured as the management server of any of claims 16 to 19,22 to 30 and 46.