WO2012010214A1

WO2012010214A1 - Provision of cached data

Info

Publication number: WO2012010214A1
Application number: PCT/EP2010/060703
Authority: WO
Inventors: Jussi-Pekka Sairanen
Original assignee: Nokia Siemens Networks Oy
Priority date: 2010-07-23
Filing date: 2010-07-23
Publication date: 2012-01-26

Abstract

A protocol is described in which content, such as popular video files, are cached by an operator/service provider. When a user requests access to the content, the file can be provided from the cache, rather than retrieving the file from the original source of the file. The protocol enables the current status of the file to be obtained from the original source of the file, to ensure that content is not provided to the end user if that is inappropriate.

Description

Provision of Cached Data

The invention is related to the provision of cached data, such as cached video files.

Figure 1 is a block diagram of a known system, indicated generally by the reference numeral 1. The system 1 comprises a service provider 2, a first content provider 4, a second con^¬ tent provider 6, a first end user 8 and a second end user 10. One or more of the content providers may, for example, store and provide video files. The end users may request access to the video files (or other stored data) via the service pro^¬ vider 2. The service provider 2 may typically communicate with the content providers and the end users using the Inter- net.

The streaming of content, such as video files, over the

Internet is becoming increasingly common. In an exemplary use of the system 1, the first end user 8 may ask the service provider 2 to provide that end user with access to a video file stored at the first content provider 4. The video file may be provided using video streaming. Such streaming requires large data files to be transferred over the Internet from the content provider 4 to the service provider 2 and from the service provider 2 to the end user 8. This is rela^¬ tively straightforward; however, if a large number of end us^¬ ers request access to a large number of video files, then the traffic required can be significant. Any of the links be^¬ tween the content providers and the end users can provide a bottleneck in the system and slow down the delivery of data to the end users. Clearly, a delay in the arrival of data is likely to significantly reduce the quality of service pro^¬ vided to the end user. For example, a video file may require buffering during display, thereby interrupting the display of that video file.

Local caching of high bandwidth Internet content (such as video files) is an attractive idea for an operator, such as the service provider 2, since caching can reduce costly net^¬ work traffic resulting from a large number of end users ac^¬ cessing the same content residing outside the operator' s net^¬ work (e.g. video files hosted by a video repository website) . Moreover, caching provides a partial solution to the problem of delays in the provision of data described above.

Caching, however, can present problems. For example, in the event that a data file had been removed from a content pro- vider, that file may still exist (and be publicly available) in a cache of the service provider 2. This can be problem^¬ atic for many reasons. For example, in the event that a le^¬ gal authority or an intellectual property owner demands that a piece of content be removed from a hosting website, that content might still be available from a cache and this may leave the network operator vulnerable to legal consequences. There are other scenarios in which storing data files in a cache might be problematic. For example, a news article or report that was requested by a first user and that is stored within a data cache may be out-of-date by the time a second user seeks to access that report.

The present invention seeks to address at least some of the problems outlined above.

The present invention provides a method comprising: receiving at a first entity (such as an operator/service provider) a request (typically from a user) for data (such as a video file or some other content) ; determining whether or not the requested data is stored within a data cache to which the first entity has access (the data cache may or may not form part of the first entity) ; and in the event that the re^¬ quested data is stored within the data cache: obtaining (e.g. by requesting or retrieving) status information regarding the data from a database associated with a source of the data (i.e. where the first entity obtained the content, which may or may not be the original source of the data) ; and deciding whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status information.

Thus, a protocol is described in which content, such as popu^¬ lar video files, are cached by an operator/service provider. When a user requests access to the content, the file can be provided from the cache, rather than retrieving the file from the original source of the file. The protocol enables the current status of the file to be obtained, for example from the original source of the file, to ensure that content is not provided to the end user if that is inappropriate.

The present invention also provides an apparatus (such as an operator or a service provider) comprising: a first input configured to receive a request (typically from a user) for data; a first processor configured to determine whether or not the requested data is stored within a data cache (to which the apparatus has access, or which might, for example, form a part of the apparatus) ; a second processor configured to obtain, in the event that the requested data is stored within the data cache, status information (e.g. by requesting or retrieving the status information) regarding the data from a database associated with a source of the data (e.g. where the apparatus obtained the data, which may or may not be the original source of the data) ; and a third processor config- ured to determine whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status information. The apparatus may have a first output configured to provide the said data in response to said request for data, in the event that the third proces^¬ sor determines that the data should be provided. One or more of the said processors may be provided by a single processor. By way of example, the functionality of the second processor and/or the third processor may, in a particular implementa- tion of the invention, be provided by the first processor. This principle applies to other processors, such as the fourth, fifth and sixth processors referred to below.

In some forms of the invention, the requested data may be provided to an end user in the event that the status informa^¬ tion indicates that the requested data can be provided. By way of example, this step might test whether the data is available at the source of the data; e.g. a data file may be provided, on request, from the data cache only if that data file is still available from the original source of that data file. Alternatively, the data might still be available to be provided to the end user, even if that data is no longer available at the source. In some forms of the invention, the request for data (e.g. as received from an end user) may be denied in the event that the status information indicates that the requested data should not be provided to the end user (e.g. if it is no longer available at the source, or if it has been flagged as being deleted) . This enables a provider of content to pre^¬ vent such content from being provided to an end user in some circumstances; for example, if the content provider has been instructed to remove a particular file, for example for legal reasons, that content provider may be able to prevent that file from being provided from the data cache of the present invention .

The invention may further comprise removing the requested data from the data cache in the event that the status infor^¬ mation indicates that the requested data should be removed (e.g. if the content is unavailable at the source, although if unavailable, it might still be possible to provide that content in some circumstances) .

The invention may further comprise requesting said data from the source of the data in the event that the status informa^¬ tion indicates that the data stored in the data cache should be updated (e.g. if the data is unreliable or out-of-date) . This might be useful, for example, for files (such as video files) relating to news articles or other information that might quickly become out-of-date.

In some forms of the invention, the said database may be un^¬ der the control of the source of said data. For example, the database may form part of the data source.

In the event that the requested data is not stored within the data cache, the invention may further comprise requesting said data from a source of said data. Furthermore, the in^¬ vention may further comprise determining whether or not to copy said requested content to said data cache. Factors such as size of data, frequency of access to the data, rele^¬ vance of data (according to data source) and available capac^¬ ity of the data cache might be of relevance to this determi^¬ nation .

The present invention also provides a computer program comprising: code (or some other means) for receiving at a first b entity (such as an operator/service provider) a request (from a user) for data; code (or some other means) for determining whether or not the requested data is stored within a data cache to which the first entity has access (the data cache may or may not form part of the first entity) ; code (or some other means) for obtaining status information regarding the data from a database associated with a source of the data, in the event that the requested data is stored within the data cache; and code (or some other means) for deciding whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status informa^¬ tion. The computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.

Exemplary embodiments of the invention are described below, by way of example only, with reference to the following num^¬ bered schematic drawings. Figure 1 is a block diagram of a known data streaming system;

Figure 2 is a block diagram of a system in accordance with an aspect of the present invention;

Figure 3 is a flow chart showing an algorithm in ac- cordance with an aspect of the present invention; and

Figure 4 shows a message sequence in accordance with an aspect of the present invention.

Figure 2 is a block diagram of a system, indicated generally by the reference numeral 20, in accordance with an aspect of the present invention. The system 20 has many similarities with the system 1 described above with reference to Figure 1. The system 20 comprises an operator 22, a first content pro^¬ vider 24, a second content provider 26, a first end user 28 and a second end user 30. The first content provider 24 is similar to the content provider 4 described above, but is ad- ditionally associated with a first database 25. The second content provider 26 is similar to the second content provider 6 described above, but is additionally associated with a sec^¬ ond database 27. The first database 25 and the second data^¬ base 27 include an indication of the status (such as the le- gal status) of files stored at the first content provider 24 and the second content provider 26 respectively, as described further below. The databases 25 and 27 may be provided as part of the content providers 24 and 26, or may be separate databases to which those content providers have access.

The operator 22 is in two-way communication with each of the content providers 24 and 26, each of the databases 25 and 27 and each of the end users 28 and 30. The operator 22 is also in two-way communication with a data cache 32.

In use, the data cache 32 is used to store data files (such as video files) that may be requested by an end user. For example, the data cache may be used to store files that are particularly large. Alternatively, or in addition, the data cache may be used to store data files that are accessed of^¬ ten. Other selection criteria could, of course, be used to determine which files should be stored within the local data cache (which is likely to have a limited storage capacity) . The data cache 32 may form part of the operator 22; alterna- tively, the data cache 32 may be separate from, but available to, the operator 22.

Figure 3 is a flow chart showing an algorithm, indicated generally by the reference numeral 40, in accordance with an as- pect of the present invention. The algorithm 40 may be im^¬ plemented using the system 20.

The algorithm 40 starts at step 42, where an end user (such as the end user 28) requests access to a video file, for ex^¬ ample in the form of a digital feed.

In response to the request received at step 42, the operator 22 determines (at step 44) whether the requested feed is stored within the cache 32. If the requested file is stored within the cache 32, then the algorithm 40 moves to step 48, otherwise the algorithm moves to step 46.

At step 46, the requested content is obtained from the rele- vant content provider (such as the content provider 24) and, once obtained, the algorithm moves to step 47, wherein it is determined whether or not the obtained content should be cop^¬ ied to the cache. From step 47, the algorithm 40 moves to step 52 as described further below.

The determination (at step 47) of whether the content ob^¬ tained in step 46 should be copied to the data cache 32 might include obtaining an indication for some content that it should never be uploaded to the cache. This might be, for example, because the nature of the data file is such that it becomes almost immediately out-of-date and so the most recent version of that file should always be obtained. Alterna^¬ tively, or in addition, a determination of whether or not to copy a particular file to the cache 32 may include one or more of many factors, such as the size of the file, the num^¬ ber of times access to the file has been requested and the available capacity of the cache. At step 48, the status of the requested content (which is stored within the cache 32) is obtained from the database as^¬ sociated with the content provider that originally provided the file. For example, in the event that the original source of the file was the content provider 24, the status of that file would be requested from the database 25.

Once the status of the file is obtained in step 48, it is de^¬ termined (at step 50) whether the file is recorded in the relevant database as being available. If so, the algorithm 40 moves to step 52, otherwise the algorithm moves to step 54.

The step 48 may simply include determining whether or not the relevant file is still available from the original source of the file. Alternatively, the step 48 may be able to deter^¬ mine that the file is no longer available from the original source, but can still be made available by the cache 32. In such a circumstance, the algorithm 40 would proceed to step 52, despite the fact that the file is not available at its original source.

At step 52, the content originally requested at step 42 is provided to the requesting user (such as the end user 28) . This file is either obtained at step 46 from the content pro^¬ vider, or obtained from the cache 32. The algorithm 40 then terminates at step 56.

At step 54 (after it has been determined that the file is no longer available) , the relevant file is deleted from the cache 32 and the algorithm 40 then terminates at step 56. In some forms of the invention, the step 54 may be omitted. In other forms of the invention, a determination may be made at step 54 regarding whether or not the relevant file should be deleted. For example, in some forms of the invention, the data file may no longer be available from the original source, but there may be no reason why the file should be de^¬ leted from the cache. In such circumstances, the data file may be retained within the cache 32.

The algorithm 40 described above is provided by way of exam^¬ ple only. More steps could be added to the algorithm (e.g. determining whether or not a particular file should be added to the data cache 32) . Some steps may be omitted (e.g. step 47 in which it is determined whether or not to copy obtained content to the cache) .

In one variant of the algorithm 40, the step 44 is modified as follows. In the event that it is determined that the re^¬ quested content is stored within the cache 32, an additional check is made as to whether the content should in any event by obtained from the original source. By way of example, the requested content may be cached, but it may be determined that the content is out-of-date and should therefore be up^¬ dated. In such circumstances, the algorithm 40 would move from step 44 to step 46, at which step the up-to-date content is obtained. At step 47, the up-to-date content would then typically be uploaded to the cache 32.

The algorithm 40 described above enables a data file to be provided in response to a content request from an end user. Figure 4 shows a message sequence, indicated generally by the reference numeral 60, in accordance with an aspect of the present invention. The message sequence 60 shows messages between the service provider 22, database 25, end user 28 and cache 32 that enables a data file to be provided to the end user 28 on request. The message sequence 60 starts at step 62 where the end user 28 asks the service provider 22 to provide a data file to the end user (thereby implementing step 42 of the algorithm 40) . In response to the message 62, the service provider deter- mines that the requested data file is stored within the cache 32 (step 44 of the algorithm 40) .

Next, the service provider 22 identifies the database associ^¬ ated with the source of the data file (the database 25 in the exemplary message sequence 60) and sends a message 64 to that database requesting the current status of the cached data file (e.g. whether the data is available to be provided to the end user 28) . The database 25 responds by sending a mes^¬ sage 66 to the service provider 22 indicating the status of the requested data file. The messages 64 and 66 of the mes^¬ sage sequence 60 therefore implement step 48 of the algorithm 40.

It should be noted that if the database 25 does not provide an indication of the status of the requested data file (or if the service provider 22 cannot find that database, or cannot determine which database to ask) then the action taken de^¬ pends on the implementation of the system 20. For example, the service provider 22 may determine in such circumstances that the requested file should be provided. Alternatively, the service provider 22 may determine in such circumstances that the requested file should not be provided. Other ac^¬ tions are possible. For example, the user 28 may be asked whether he wants to make use of the cached file (which might allow faster access to the file) or to obtain the file from the content provider.

On receipt of the message 66, the service provider 22 deter^¬ mines, on the basis of the message 66, whether or not the cached data file is available to be sent to the end user (thereby implementing step 50 of the algorithm 40) . If the determination is that the data file can be provided to the end user, the service provider 22 requests that data file from the cache 32 (message 68) and receives that data file in a message 70.

Finally, the requested data file is sent from the service provider 22 to the end user 28 (message 72), thereby imple- menting step 52 of the algorithm 40.

The algorithm 40 and the message sequence 60 are provided by way of example only. Many modifications will, of course, be apparent to the skilled person.

The present invention can be implemented in many ways. For example, the operator 22 may be a web server, which is ac^¬ cessed by the end users 28 and 30 using a network, such as the Internet. The operator 22 may be a mobile telecommunica- tions operator and the end users 28 and 30 may make use of mobile communication devices to access the operator 22 via a mobile telecommunications network. Many alternative arrange^¬ ments will be readily apparent to the skilled person. The present invention has generally been described in rela^¬ tion to the streaming of video files. The invention is not so limited. For example, the principles of the invention can be applied to access to other cached data files, such as im^¬ age files or audio files.

The embodiments of the invention described above are illus^¬ trative rather than restrictive. It will be apparent to those skilled in the art that the above devices and methods may incorporate a number of modifications without departing from the general scope of the invention. It is intended to include all such modifications within the scope of the inven^¬ tion insofar as they fall within the scope of the appended claims .

Claims

CLAIMS :

1. A method comprising:

receiving at a first entity a request for data;

determining whether or not the requested data is stored within a data cache to which the first entity has access; and in the event that the requested data is stored within the data cache:

obtaining status information regarding the data from a database associated with a source of the data; and

deciding whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status information.

2. A method as claimed in claim 1, further comprising providing the requested data in the event that the status infor^¬ mation indicates that the requested data can be provided.

3. A method as claimed in claim 1 or claim 2, further comprising denying the request for data in the event that the status information indicates that the requested data should not be provided.

4. A method as claimed in any one of claims 1 to 3, further comprising removing the requested data from the data cache in the event that the status information indicates that the re^¬ quested data should be removed.

5. A method as claimed in any preceding claim, further comprising requesting said data from said source of the data in the event that the status information indicates that the data stored in the data cache should be updated.

6. A method as claimed in any preceding claim, wherein said database is under the control of the source of said data.

7. A method as claimed in any preceding claim, wherein, in the event that the requested data is not stored within the data cache, the method further comprises requesting said data from said source of said data.

8. A method as claimed in claim 7, further comprising de- termining whether or not to copy said requested data to said data cache.

9. An apparatus comprising:

a first input configured to receive a request for data; a first processor configured to determine whether or not the requested data is stored within a data cache;

a second processor configured to obtain, in the event that the requested data is stored within the data cache, status information regarding the data from a database associ^¬ ated with a source of the data; and

a third processor configured to determine, in the event that the requested data is stored within the data cache, whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status information.

10. An apparatus as claimed in claim 9, further comprising a first output configured to provide the said data in response to said request for data, in the event that the third proces- sor determines that the data should be provided.

11. An apparatus as claimed in claim 9 or claim 10, further comprising a fourth processor adapted to remove the requested data from the data cache in the event that the status infor- mation indicates that the requested content should be re^¬ moved .

12. An apparatus as claimed in any one of claims 9 to 11, further comprising a fifth processor configured to request said data from said source of the data in the event that the status information indicates that the data stored in the data cache should be updated.

13. An apparatus as claimed in any one of claims 9 to 12, further comprising a sixth processor configured to request said data from said source of said data in the event that the requested data is not stored within the data cache.

14. An apparatus as claimed in any one of claims 9 to 13, further comprising the said data cache.

15. A computer program product comprising:

means for receiving at a first entity a request for data;

means for determining whether or not the requested data is stored within a data cache to which the first entity has access ;

means for obtaining status information regarding the data from a database associated with a source of the data, in the event that the requested data is stored within the data cache; and

means for deciding whether or not to provide the data stored in the data cache in response to the request for data on the basis of said status information.