GB2486393A

GB2486393A - Delivering a personalised file from a content provider to a client

Info

Publication number: GB2486393A
Application number: GB1014878.1A
Authority: GB
Inventors: Peter Vassilev Sedeffow
Original assignee: Saffron Digital Ltd
Current assignee: Ott Film 1 Ltd
Priority date: 2010-09-08
Filing date: 2010-09-08
Publication date: 2012-06-20
Anticipated expiration: 2030-09-08
Also published as: EP2429151A1; US20120059904A1; US8769042B2; GB2544888A; GB2486393B; GB201014878D0

Abstract

A request from a client to access a file is received at a content provider. A common file that is common to all requesting clients is identified in a first storage location. In a second storage location a personalised file that is unique to said client (based on e.g. client age, device type etc.) is identified. The common file and personalised file are analysed to find their differences. The shared data and the unique data are delivered to the client and the client is instructed to combine the shared data and the unique data together to form the personalized file. This method saves bandwidth at the storage location of the personalised file, since only the differences are transmitted from that location.

Description

Delivering a File From a Content Provider to a Client

CROSS REFERENCE TO RELATED APPLICATIONS

This application represents the first application for a patent directed towards the invention and the subject matter.

s BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a system and a method for delivering personalised files to users using a content delivery network.

2. Description of the Related Art

Content delivery networks are used to maximise bandwidth for accessing data by distributing copies of the data amongst several strategically placed nodes. This can result in an increase in the ability of a content provider to serve concurrent users, whilst reducing bandwidth costs.

A problem is encountered when a content provider wishes to provide a personalised file to a unique user. As the copies of files stored within a content delivery network must be identical and distributable to any user, there is no scope for storing a personalised file for each unique user. A solution is required that allows the delivery of personalised files, but retains the strengths of a content delivery network in respect of performance and cost advantages.

BRiEF SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provided a method of delivering a file from a content provider to a requesting client according to claim 1.

According to a second aspect of the present invention, there is provided apparatus for delivering files to a client according to claim 7.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Figure 1 shows an environment in which the present invention may be deployed; Figure 2 shows an apparatus for implementing the present invention; Figure 3 shows steps carried out to construct a local personalised file on a client device; Figure 4 illustrates operations carried out during step 304; Figure 5 illustrates a procedure for allowing a download of a personalised file; and Figure 6 illustrates a procedure for streaming a personalised file.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Figure 1 An environment in which the present invention may be deployed is iiiustrated in Figure 1.

A content provider 101 stores common versions of files at various locations 102, 103, 104, 105 and 106. These locations usually comprise large server pools configured to provide a high level of bandwidth for accessing content, and, in combination, form a first storage location, in this case content delivery network 107, which is connected to the Internet 108. At each location 102 to 106, the common files are substantially the same, thus distributing copies of data over a large geographical area. By distributing the data in this way, content provider 101 is not reliant upon one single server pool to provide access it its content. Additionally, spreading the data out over a large area reduces the amount of bandwidth required to service the sending of any one file in a particular server pool to clients.

Clients, such as those found in groups 110, 120 and 130, may request the sending of data held by the content provider over the Internet 108.

Requests from the clients are received by a request management system 109 networked within content provider 101. Incoming requests from groups 110, and 130 are handled by a request management system 109. Request management system 109 is used to locate content on content delivery network 107 and deliver it to its requesting client.

Groups 110, 120 and 130 typically comprise large numbers of clients clustered in a particular geographical area. Thus, group 110 may be located in Europe, group 120 in North America and group 130 in Asia.

When all of the clients requesting data use substantially the same platform to view files, such as personal computers 111, 121 and 131 running the Microsoft® WindowsTM operating system in combination with Windows Media Player, then all of the copies of files stored by the content delivery network 107 can be identical. However, other types of clients, such as 3G smartphones 112, 122 and 132 may require copies of the file that are tailored to their platform, such as the Google® AndroidlM operating system.

Furthermore, each unique client requesting data may require a unique file personalised solely for them, due to factors such as device type, age restrictions, location, time limits on storing the file and so on. Current content delivery systems are not able to provide this personalisation, as by their nature the files they store must be substantially the same.

The present invention overcomes this problem within the framework of a content delivery network 107 by adding a second storage location, in this case file store 140, to content provider 101. File store 140 is, as with locations 102 to 106, a large server poo1. File store 140 holds copies of the common files stored on the content delivery network 107 that have been personalised for each unique client so as to create personalised versions of the files. The process of personalisation of the common files to produce personalised files will be discussed below with reference to the Figures.

Figure 2 Figure 2 illustrates components within request management system 109. In this particular example, request management system 109 is provided by a single request manager 2011 but in other examples it is likely that clusters of request managers would be used to deal with high numbers of requests.

Indeed, a large number of clusters spread over different physical sites may be employed to add redundancy.

Request manager 201 comprises a central processing unit 202, memory 203, hard disk drive 204 and network interface 205. In an! example, central processing unit 202 comprises an Intel® Xeon® processor, memory 203 comprises 8-gigabytes of DDR3 random access memory, and hard disk drive 204 comprises a 500-gigabyte hard disk drive. Network interface 205 allows request manager 201 to connect to an internal network 206 installed at content provider 101, and also to the Internet 108.

Request manager 201 also comprises an optical drive 207, such as a CD-ROM drive, into which an optical disk, such as CD-ROM 208 may be inserted. CD-ROM 208 comprises instructions for implementing the personalisation functionality that are installed on hard disk drive 204, loaded into memory 203 and executed by processor 202.

Figure 3 Figure 3 shows steps carried out to construct a local personalised file on a client device.

At step 301, content provider 101 receives a request from a client, say personal computer 111, to access a file on content delivery network 107. This request includes data that requires that the file be personalised for the particular user. In an example, the user is requesting a film, and requires personalisation to censor profanities in the film's audio track.

At step 302, request management system 109 locates the common file in a location within content delivery network 107 that is nearest to the requesting client, for example location 102. At step 303, the personalised file is located on file store 140. In this example, file store 140 is located much further from the requesting client, and is serving a larger number of concurrent clients than location 102. Thus, its available bandwidth is much lower than that at location 102.

In order to reduce the amount of data needing to be transferred from file store 140 to personal computer 111 via the Internet 108, request management system 109 performs a differential analysis upon the common file stored at location 102 and the personalised file stored at file store 140 at step 304. This process will be discussed further with reference to Figure 4. This results in the difference between the common and the personalised file being identified, and only the unique portions of the personalised file need be downloaded by personal computer 111 from file store 140.

Thus, at step 305, the shared data is delivered by location 102 to personal computer 111, whilst the unique data is delivered at substantially the same time by file store 140 to personal computer 111 at step 306.

Upon completion of steps 305 and 306, personal computer 111 is instructed by request management system 109 to stitch the shared data and the unique data together to reproduce the personalised tile as a local personalised file.

In an alternative embodiment, the shared data and the unique data are delivered sequentially and in order. In this case, personal computer stitches each portion of shared data and each portion of unique data together in real time as they are received. This procedure is especially suited to a situation where a personalised file is being streamed to a client.

Figure 4 Figure 4 illustrates operations carried out during step 304.

Request management system 109 locates at steps 302 and 303 the common file 401 and the personalised file 402. It then proceeds to compare the data contained within the files through a process of differential analysis, which results in the identification of shared data 403 that is common to both common file 401 and personalised file 402, along with unique data 404 that is only found in personalised file 402. This allows request management system 109 to establish download patterns that describe the portions of the shared file 401 and personalised file 402 that need to be delivered to the client. This procedure will be described further with reference to Figures 5 and 6.

Figure 5 Figure 5 illustrates the use of the download patterns in an embodiment where the requested file is downloaded.

In a download situation, the client must wait for all the data to arrive before accessing the delivered, personalised file. Thus, the data for delivery from location 102 and file store 140 is first located and then delivered simultaneously to the client into a local shared file 501 and a local personalised file 502. When the delivery is complete, the local personalised file 503 may be constructed by stitching together the data.

Thus, the unique data 404 is delivered to the client even when file store 140 is experiencing a bandwidth shortage, as the amount of data required from file store 140 is only the data that is unique to the personalised file.

Figure 6 Figure 6 illustrates a procedure for streaming a personalised file, such as a film.

The identification of shared and unique portions allows content provider 101 to establish file delivery patterns of the common file 401 and personalised file 402 such that streaming of the file can take place. This is especially suitable when the client is requesting a film from content provider 101, and does not wish to wait for the entire file to download before commencing playback.

ln this particular example, there are three portions of common data 403A, 403B and 403C, whilst there are four portions of unique data 404A, 404B, 404C and 404D that have been identified. Thus, the streaming of the file from content provider 101 to the client begins with the delivery and commencement of playback of portion 404A from file store 140, followed by the delivery and playback of portion 403A from location 102 and so on. Thus, the portions of data are delivered sequentially and in order. Each portion is delivered consecutively and produces a received stream 601, which is displayed by the client to a user.

Claims

Claims 1. A method of delivering a file from a content provider to a requesting client, comprising the steps of: receiving a request from a client to access a file; identifying in a first storage location a common file that is common to all requesting clients; identifying in a second storage location a personalised file that is unique to said client; analysing said common file and said personalised file to find their differences, thus identifying portions of shared data in said common file and portions of unique data in said personalised file; delivering to said client said shared data and said unique data; and instructing said client to stitch said shared data and said unique data together, so as to create a local personal file for use only by said client.
2. The method of claim 1, wherein said portions of shared data and said portions of unique data are delivered to said client simultaneously.
3. The method of claim 2, wherein said delivering of portions of shared data and portions of unique data is performed when a client requests to download a file.
4. The method of claim 1, wherein said portions of shared data and said portions of unique data are delivered to said client sequentially and in order.
5. The method of claim 4, wherein said delivering of portions of shared data and portions of unique data is performed when a client requests to stream a file.
6. The method of any of claims I to 5, wherein said first storage location comprises a content delivery network.
7. The method of any of claims I to 5, wherein said second storage location comprises a file store.
8. A computer-readable medium having computer-readable instructions executable by a computer such that when executing said instructions a computer will perform steps according to any of claims I to 7.
9. Apparatus for delivering files to a client, comprising a processor, memory, storage and a network interface, wherein said apparatus is configured to: receive a request from a client via said network interface to access a file; identify in a first storage location a common file using said processor, said common The being common to all requesting clients; identify in a second storage location a personalised file using said processor, said personalised file being unique to said client; analyse said common file and said personalised file to find their differences using said processor, thus identifying portions of shared data in said common file and portions of unique data in said personalised file; deliver to said client said shared data and said unique data via said network interface; and issuing instructions to said client to stitch said shared data and said unique data together via said network interface, so as to create a local personal file for use only by said client.
10. The apparatus of claim 9, wherein said portions of shared data and said portions of unique data are delivered to said client simultaneously.
11. The apparatus of claim 10, wherein said delivering of portions of shared data and portions of unique data is performed when a client requests to download a file.
12. The apparatus of claim 9, wherein said portions of shared data and said portions of unique data are delivered to said client sequentially and in order.
13. The apparatus of claim 12, wherein said delivering of portions of shared data and portions of unique data is performed when a client requests to stream afile.
14. The method of any of claims 9 to 13, wherein said first storage location comprises a content delivery network.
15. The apparatus of any of claims 9 to 14, wherein said second storage location comprises a file store.