Patent Application
20100070571
The present invention relates to telecommunications, in particular to providing digital assets.
Early Internet Protocol television systems contained a limited set of multimedia assets, such as films/movies, and recordings of concerts and sports events. These assets are sometimes referred to as Content-on-Demand CoD, CoD assets, digital assets, content or titles. These early systems typically had relatively few subscribers, for example being based in hotels.
Since then, IPTV systems have expanded both in the number of assets involved and the number of subscribers. More recently, IPTV systems are known having more than five thousand assets and over one million subscribers. An example of such a system is shown in
As shown in
The central library server 4 is connected to a database 8 of CoD assets. The database 8 has enough storage capacity to store all the assets. Typically there is a ratio of 10 to 1 in the amount of content storage available in the database 8 as compared to in a CoD edge streaming server 6. There are, of course, many CoD edge streaming servers 6 and subscribers 10 but only a few of each are shown in
The IPTV system 2 includes a controller 12 which uses data of historical user information 14 to predict the likelihood of future viewings of assets. This user information 14 can include box office sales and records of viewings made in a given previous period.
In the system 2, personal video recorder (PVR) services are provided. In such services, the system 2 captures broadcast television content as CoD assets, and subscribers may access these assets. These services are called network personal video recorder (nPVR) services in that they are provided by the system 2, which is a network.
The most popular assets, be they nPVR assets or other CoD assets, are placed in the appropriate edge streaming servers 6 so as to reduce traffic between the library server 4 and subscribers 10. Essentially, popular assets are stored close to subscribers in the edge streaming servers 6.
In addition to closed or dedicated Content-on-Demand CoD systems such as Internet Protocol television, IPTV, there are open systems, namely so-called internet television systems.
Both for IPTV and internet television, various approaches to selecting assets for storage in the edge streaming servers have been developed. Conventionally, historical data is used to determine which assets to keep stored in edge streaming servers using Least Frequently Used (LFU) or Least Recently Used (LRU) approaches. These are known approaches whereby the least frequently requested asset, or least recently requested asset, at an edge streaming server, is removed, in order to make space for a more popular asset to be stored.
The reader is referred to the appended independent claims. Some preferred features are laid out in the dependent claims.
An example of the present invention is a method of providing digital assets in a network comprising a central controller connected to a plurality of servers. Each asset comprises at least one of video data and audio data. Each server serves a group of user terminals by storing a respective selected set of the assets and providing an asset from the selected set to a user terminal on request. The method comprises, for at least one of the servers, selecting which assets to store by the steps of: (a) for each of the group of user terminals served by the server receiving a recommendation as to a set of assets predicted as most likely to be desired by the individual user terminals, said recommendations being adapted to the individual users of said individual user terminals; (b) determining from the recommendations, a list of the most likely to be requested assets for the group of user terminals; and (c) updating the assets stored in the server so that the most likely to be requested assets are stored in the server.
The list of most likely to be requested assets is used in updating which assets are stored in the server that serves the group of users. In some embodiments, in use, a list of suggested assets provided to a user can be limited to those available at the server to which the user terminal is connected. Users may often favour selecting from the list of suggested assets over searching for an asset from a large list.
In some embodiments, recommendation engines provide advance recommendations as to which assets individual users may be interested in without relying solely on historical data as to the frequency of past asset requests. The predicted recommendations may be dependent upon asset request patterns of other users having similar or related user profiles (age, education level, interests etc). The predicted recommendations may be dependent upon asset type (e.g. an asset of a user's preferred genre or a related genre to that genre). The use of data from recommendation engines is advantageous in determining which assets to store in servers that are local to users but have limited storage.
An embodiment of the present invention will now be described by way of example and with reference to the drawings, in which:
As shown in
DSLAMs 28, denoted D1 and D2 respectively, are shown for simplicity. Each DSLAM is connected to a respective set of IPTV user terminals 30. As shown in
In the system 20, personal video recorder (PVR) services are provided, in addition to multimedia assets such as prerecorded films. In such services, the system 20 captures broadcast television content as CoD assets, and subscribers may access these assets. These services are called network personal video recorder (nPVR) services in that they are provided by the system 20, which is a network.
As explained in more detail below, some assets, be they nPVR assets or other CoD assets, are placed in the appropriate edge streaming caches 24 so as to reduce traffic between the library server 22 and user terminals 30. Assets that are determined as popular to the relevant users using the approach explained in more detail below, are stored close by, in the appropriate edge streaming cache 24.
The recommendation engine is a processor of known type such as sold by Think Analytics Inc. (www.thinkanalytics.com)
The recommendation engine is a processor operative to determine a list of CoD recommendations tailored to a specific user based on: input information of a user's declared profile, behaviour of users with similar profiles to a specific user (in a process known as collaborative filtering), content based filtering, a record of the user's consumption of other media (broadcast television, DVDs, book purchases, etc), and feedback information as to the CoD assets that the user has previously actually requested.
Collaborative filtering predicts level of interest to a specific user based on behaviour of users with similar interests, e.g. most users who watched movie assets A and B have also requested asset C so a user who has watched A and B but not C is likely to be recommended C.
Content based filtering is based on considering asset type, e.g. movie genre, for example based in asset meta-data, in formulating recommendations in view of discovered user preferences.
The user's declared profile is information of preferred film genres, preferred actors, hobbies (e.g. sports), and demographic information of the user (age, sex etc).
The input information is updated daily to provide an up to date list of CoD asset recommendations for each user each day.
The recommendation engine affects future asset request patterns by affecting which assets are stored in each edge streaming node 24 and hence suggested to users connected to the cache 24.
The content controller 32 determines and controls which assets to store in each edge video cache 24 dependent on the recommendations for individual users provided by the recommendation engine 34. The content controller includes a list of content assets for caching, and a counter, and operates as described below with reference to
As shown in
If Yes, then for each user in the set of users which are attached to DSLAM Di, the “top 10” asset titles for the respective user are obtained (step e) from the recommendation engine 34.
Then the list of content assets for caching is generated (step f) by, for each of the “top 10” asset titles for each user in set Ui, determining whether the asset is already on the list of content assets for caching. If yes, a count of the number of times that asset is in a Top 10 list is incremented by one. If no, that asset is added to the list of content assets for caching.
After this, the index i is incremented (step g) by one, and a return is made (step h) to the query (step d) as to whether the current value of i is is less than or equal to the total number N of DSLAMs 28 downstream of the edge video cache 24. Then the process proceeds through repeated steps d,e,f and g until it is determined (step h) that i is not less than or equal to N, in other words all users in all sets Ui where i=1, . . . N have been taken into account in formulating the list of content assets for caching.
The list of titles of content assets for caching is then reordered (step j) so that the assets are in descending order of counts (i.e. the title with the highest count is at the top of the list, and so on). This reordered list is the list of recommendations for caching in that particular edge video cache 24.
Having formulated this list, caching is undertaken as follows. The first title on the reorder list is selected (step k) and a query is made (step l) whether this title is the last title on the list of content assets for caching. The answer is No (step m), so a determination is then made (step n) as to whether the selected asset is already stored in the cache 24.
If Yes (i.e. the asset is already stored), then the next title in the list of content assets for caching is selected (step o) and a return made (step p) to the query (step l) whether this title is the last title on the list of content assets for caching. If No (i.e the asset is not already stored, step r), then a query is made (step s) as to whether that asset has a count that is higher than the lowest count of the assets currently stored in the cache.
If Yes (i.e. the title has a count higher than the least popular asset currently stored in the cache 24, step t) then that least popular asset in the cache is marked (step u) as to be replaced by this “new” title, and a return is made to step o, i.e. the next title in the list of content assets for caching is selected. If No (i.e the title has a count not higher than the least popular asset currently stored in the cache 28,), a return is made (step v) to step o, i.e. the next title in the list of content assets for caching is selected.
The process proceeds through further iterations until upon a query being made (step l) whether this title is the last title on the list of content assets for caching, the answer is yes (step w). As a next step, the replacement of assets marked in step u is put into effect (step x) and the process ends (step y).
This process is run periodically, for example daily, so as to take account of daily changes in recommendations provided by the recommendation engine in respect of individual users. Specifically, shortly after new assets, such as new blockbusters, are introduced into the system, recommendations for individual users are generated by the recommendation engine that include the titles of those assets, and the content controller operation, that is shown in
The IPTV application server 36 includes a CoD application 38 which, when a user terminal access the application, generates and supplies a list of ten suggested assets that are tailored to that user terminal 30 using the user's profile but limited to those assets that are now available in the local edge video cache 24 of the user terminal 30. This list is sent to the user terminal via the appropriate edge video cache 24 and DSLAM 28.
The user terminal selects an asset to view or listen to, from that list, then, under the control of the IPTV application server 36, the edge video cache 24 supplies that asset to the user terminal 30.
Alternatively, if the user does not wish to select an asset from that list of ten, he may search for and request another asset stored in the local edge video cache 24 or the CoD database 8.
In an alternative embodiment, it is possible to weight the counts depending on the type of user, so recommendations in respect of more frequent users have a greater influence. One example is to classify users into three levels: occasional, moderate, or heavy. For an occasional user, a count of 1 is added for each of his/her top ten recommendations. For a moderate user, a count of 2 is added for each of his/her top ten recommendations. For a heavy user, a count of 5 is added for each of his/her top ten recommendations.
In an alternative embodiment, an additional input to the recommendation engine is user's own recommendations as to levels of likely interest to other specified users (e.g. other family members) or groups of users (e.g. football fans). In an alternative embodiment, another input to the recommendation engine is professional recommendations/ratings made by film critics. Upon it being noticed that a well known film reviewer has just published some new film reviews, the recommendation engine is updated. If a significant change in popularity of an asset is noticed, then the content control process of the content controller is rerun to update the assets stored in the edge video caches.
In some other embodiments, in place of the DSLAMs, there are Intelligent Subscriber Access Multiplier (ISAM) systems, or routers, or other network equipment.
Some embodiments are closed networks and some are open networks. Some closed networks are Internet Protocol Television (IPTV) networks and some open networks are internet television networks.
The present invention may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
| Number | Date | Country | Kind |
|---|---|---|---|
| 08290861.7 | Sep 2008 | EP | regional |
