WO2016042510A1

WO2016042510A1 - Dynamic control of content on distributed media player devices using a carousel mechanism

Info

Publication number: WO2016042510A1
Application number: PCT/IB2015/057155
Authority: WO
Inventors: Alan John Sullivan
Original assignee: Altron Tmt (Pty) Limited
Priority date: 2014-09-17
Filing date: 2015-09-17
Publication date: 2016-03-24

Abstract

A method of controlling from a central backend 12, content in a local library of assets stored on a respective mass data storage device 26 of a plurality of distributed master devices 14.1 to 14.n is provided. The method comprises outputting at least a first set 18.1 of files and a second set 18.2 of files which second set comprises respective assets. The first set is cyclically outputted at a first repetition rate and the second set is cyclically outputted at a second repetition rate, which is slower than the first repetition rate. A content control message file (MF) 20 comprising library content control messages relating to assets to be stored in the local library is incorporated into the first set. The first set of files and the second set of files are received at each of the master devices, processed and if they comply with a set of rules, are stored in the local library. The received MF is used to update the contents of the local library of assets in accordance with the library content control messages.

Description

DYNAMIC CONTROL OF CONTENT ON DISTRIBUTED MEDIA

PLAYER DEVICES USING A CAROUSEL MECHANISM

INTRODUCTION AND BACKGROUND

This invention relates to a method of and system for controlling from a central backend data stored on distributed devices such as, but not limited to media player devices, such as set-top boxes.

In technologically advanced regions of the world with adequate broad bandwidth internet connectivity, media data is satisfactorily streamed via the internet from a remote source to be played out on demand and in real time on a renderer system comprising a set top box connected to an audio visual renderer device, such as a television set, at a local user station (such as a home). On the other hand, in other regions of the world (which include areas in developed countries, developing countries and least developed countries) there is not adequate internet connectivity (in terms of bit rate available and/or affordability) and therefore play-out of media data "on demand" is associated with unacceptable time delays after the demand and/or frustrating intermittent buffering.

One known solution is to download via a satellite link items of content (also referred to as assets, such as movies) in a data stream in a first encrypted form from a backend to a set-top box at a user station. In the set top-box, the received encrypted items are decrypted and then re-encrypted utilizing Triple Data Encryption Algorithm (IDEA or 3DES), before they are written to a hard drive in the set-top box, to be pre-stored on the hard drive. A decryption key for decrypting the 3DES encrypted content is required. When a user wants to view a selected movie, the user is prompted via a graphical user interface (GUI) manually to key in a twelve digit long data string, which is then sent by a Short Message Service (SMS) to the backend. The string comprises protected data relating to the movie selected by the user, the number of a smart card hosted by the set-top box and data relating to a financial transaction for viewing the selected movie. At the backend, if the string meets with certain rules, an entitlement management message is sent from the backend via said satellite link to the smart card of the set-top box enabling loading of the decryption key for a decrypter in the set-top box to decrypt the 3DES encrypted movie for play out on the media renderer device.

Since the assets so distributed are not protected by a suitable digital rights management (DRM) regime, media content providers or studios may in at least some cases not be prepared to make premium content available for distribution as aforesaid. DRM is a class of technologies that are used by rights holders to control the use of digital content after it has been made available to a prospective user. Such control may include, but is not limited to, control over executing, viewing and copying. In applications where large numbers of assets of different categories (e.g. premium assets and older assets) are pre-stored, control over the presto red content is problematic.

OBJECT OF THE INVENTION

Accordingly, it is an object of the present invention to provide a method of controlling from a backend, content on a local library of assets stored on a respective one of a plurality of distributed devices and an associated supporting system with which the applicant believes the aforementioned problems and/or disadvantages and/or shortcomings may at least be alleviated or which may provide a useful alternative for the known methods and systems.

SUMMARY OF THE INVENTION

In this specification, unless the context otherwise indicates, the terms "asset" or "assets" shall mean content in the form of media including but not limited to audio, still images, text, animation, video, and multimedia which may be a combination of any of the aforementioned such as audio visual and interactivity content forms.

According to the invention there is provided a method of controlling from a central backend, content in a local library of assets stored on a respective mass data storage device of a plurality of distributed master devices, each master device being connectable to a respective renderer device comprising a monitor for displaying at a respective user station a graphical user interface (GUI), the method comprising:

- outputting at least a first set of files and a second set of files which second set of files comprises respective assets, the first set of files being repeatedly outputted at a first average repetition rate and the second set of files being repeatedly outputted at a second average repetition rate, which is slower than the first average repetition rate;

- incorporating a content control message file into one of the first set of files and the second set of files, the content control message file comprising library content control messages relating to assets to be stored in the local library;

- causing the at least first set of files and the second set of files to be received at each of the master devices, to be processed and if they comply with a first set of rules, to be stored in the local library of assets; and

- utilizing the received content control message file to update the content of the local library of assets in accordance with the library content control messages.

The content control message file may be incorporated into the first set of files. The method may comprise also outputting a third set of files comprising respective assets, the third set of files being outputted repeatedly at a third average repetition rate which is slower than the second average repetition rate.

In some forms of the method, the content control message file comprises data relating to assets to be deleted from the local library.

In other forms of the method, the content control message file comprises data relating to assets to be retained in the local library.

In still other forms of the method the content control message file may comprise a master file comprising an inventory of assets to be stored in the library on the master devices and in respect of at least some of the assets, an associated control command and/or an associated time availability window and/or a delete action command.

The method may also comprise incorporating into the first set of files at least one of: a file comprising data relating to messages to be displayed on the GUI; and a file comprising configuration data relating to a required configuration of the GUI. Hence also included within the scope of the present invention is a method of dynamically updating a GUI at a master device or user station, as herein described or defined.

The first, second and third sets of files may be outputted from a carousel server.

The method may also comprise, before outputting the first, second and third sets of files, protecting the respective assets with a respective digital rights management (DRM) protection token.

The method may comprise, after having protected the respective assets, compressing the respective files.

The compressed files in the first, second and third sets of files may also be protected cryptographically.

The method may comprise utilizing an encapsulator between the carousel server and a distribution system, to package the first, second and third sets of files in a Multi Program Transport Stream (MPTS), before they are distributed by the distribution system via one of satellite, terrestrial and cable. The invention also extends to at least one carrier comprising respective parts of a computer program, which when executed on at least one processor at a central backend, performs the method as defined above. Further according to the invention there is provided a system configured for performing the above method. Still further according to the invention there is provided a backend configured for performing the above method.

Further according to the invention there is provided a method of controlling content in a local library of assets stored on a respective mass data storage device of a master device at a user station comprising, at the master device:

- repeatedly receiving at least a first set of files and a second set of files which second set of files comprises respective assets, the first set of files being repeatedly received at a first average repetition rate and the second set of files being repeatedly received at a second average repetition rate, which is slower than the first average repetition rate;

- processing the received files and if the received files comply with a first set of rules, storing the files in the local library of assets;

- utilizing a received content control message file which forms part of each first set of files and which content control message file comprises library content control messages relating to assets to be stored in the local library, to update the content of the local library of assets in accordance with the library content control messages.

The invention also includes within its scope a carrier comprising a computer program, which when executed on at least one processor on a master device, performs the above method.

Yet further according to the invention there is provided a master device configured for performing the above method.

BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS

The invention will now further be described, by way of example only, with reference to the accompanying diagrams wherein:

figure 1 is a high level diagram of an example embodiment of a system supporting a method of controlling from a central backend, content in a local library of assets stored on a respective mass data storage device of a plurality of distributed master devices;

figure 2 is a diagrammatic representation of example time periods associated with Transactional Video on Demand (TVOD) movies and Subscription Video on Demand (SVOD) movies; Q

figure 3 is a more detailed diagram of delivery of the data files to the distributed master devices via a carousel mechanism;

figure 4 is a diagram illustrating relevant parts of processing of received data files on one of the master devices; figure 5 is a more detailed diagram illustrating processing by the master device of a received content message control file comprising library content control messages or commands; figure 6 is a diagrammatic representation of an example configuration of a graphic user interface GUI as displayed on a renderer device connected to the master device; and

figure 7 is a diagrammatic representation of another example embodiment of the configuration of the GUI.

DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

In figure 1 there is illustrated an example embodiment of a system 10 supporting a method of controlling from a central backend 12 content in a local library 22 (shown in figure 4) of assets stored on a respective mass data storage device 26 (also shown in figure 4) of a plurality of distributed master devices 14.1 to 14. n at respective user stations.

Referring to figures 1 and 3, the method comprises at the central backend 12 outputting via a first communications path 16 to the master devices 14.1 to 14. n at least a first set 18.1 and a second set 18.2 of files. The files in the first set 18.1 of files being repeatedly outputted at a first average repetition rate and the files in the second set 18.2 being repeatedly outputted at a average second repetition rate, which is slower than the first repetition rate. The method further includes incorporating a content control message file in one of the first set of files and the second set of files. The content control message file is typically, but not necessarily, in the form of a master file (MF) 20, comprising library content control messages or commands relating to assets to be pre-stored in the library. In presently preferred example embodiments, the MF 20 is incorporated in the first set 18.1 of files. The method further comprises causing the at least first set 18.1 of files and the second set 18.2 of files to be received at each of the master devices 14.1 to 14.n, to be processed and if they comply with a first set of rules (including but not limited to error detection and error correction methods as will be explained below), to be stored in a respective file system in the library 22 of assets (shown in figure 4) on a mass data storage device, for example in the form of a hard disk drive HDD 26 shown in figures 3 and 4 hosted by the master device 14.1. The library content control messages or commands in the received MF 20 are utilized to update the content of the library 22 of assets in accordance with the library content control messages.

Each master device 14.1 to 14. n at the user stations is connected to a respective renderer device 27.1 to 27. n, such as, but not limited to a TV apparatus. The renderer device, under control of the master device, is able to display at the user station a graphic user interface (GUI) 23.1 , 23.2 (example embodiments of which are shown in figures 6 and 7, respectively) and/or play out user selectable assets which are pre-stored on the mass data storage device 26. The mass data storage device may have a capacity of 512 Gigabytes or more. The master device may form part of a local area network (not shown) at the user station. The master device may act as a hub of the local area network and/or gateway to the backend 12 via a second communications path 58, as will be described below.

Referring to figure 1 , assets 28 such as movies, series, documentaries, resources stored at websites, such as YouTube, Netflix, to name only two, learning programmes etc are supplied by a content provider 30 to the central backend 12. The backend 12 comprises a content management system (CMS) 32, where these assets are ingested for further processing. Optionally and in suitable cases, such as in the case of movies, each asset may be encrypted at Digital Rights Management (DRM) encrypter 34 according to a DRM technology, such as Microsoft (MS) Playready with a respective DRM token (also referred to as a DRM key). The token may comprise at least one of a key, certificate or algorithm which is stored in a DRM key database 36. Whenever data is transferred between components of the backend (and which components may be distributed), secure cryptographic protocols such as Secure Sockets Layer (SSL) and/or hardware security module (HSM) and/or later technologies and/or protocols may be utilized as shown in figures 1 and 3. It will be appreciated that for reasons including but not limited to anti-copying and security reasons, no DRM keys to decrypt the DRM protected assets is stored on the master devices 14.1 to 14.n.

The aforementioned ingested assets and other data are forwarded to a carousel server 38. The carousel server 38 comprises an encapsulator 39 (shown in figure 3) which uses a custom bidirectional stream communications protocol to generate and output a single Multi Program Transport Stream (MPTS). Hence, data is forwarded from the carousel server 38 to the encapsulator 39 and said data is packaged by the encapsulator into a format suitable for combining with a satellite, terrestrial or cable distribution system. Moving Picture Experts Group (MPEG) standards may be applied to the data streams.

From the encapsulator, the MPTS is output to a multiplexer (MUX) 40 at a broadcast facility 42. The MUX 40 combines the MPTS output stream from the carousel server with other streams 44 from other data sources and broadcasts said streams over the first communications path 16 as a single MPEG 2 (or later standard) transport stream according to Digital Video Broadcasting standards (DVB S/T/S2 T2 or later standards). It will be appreciated that multiple assets and/or data may be transmitted or broadcasted simultaneously, sharing an available bandwidth (typically 10 megabits per second or more) on the first communications path 16. The first communications path 16 may alternatively comprise a Digital terrestrial television (DTT) path or a cable path.

The backend 12 further comprises a Key Management Server (KMS) 46. The KMS generates and stores in respect of the distributed master devices 14.1 to 14. n security tokens (also referred to as security keys).

The backend 12 further comprises a billing and subscriber management system 54 and an associated user/subscriber database 56. The system 54 is in data communication with each of the master devices 14.1 to 14. n via a second communications path 58, which is different from the first communications path 16. The second communications path may be provided by an Asymmetric digital subscriber line (ADSL) or Global System for Mobile Communications (GSM) or GPRS or 3G or 4G or LTE or later protocol, preferably utilizing Internet Protocol (IP).

The billing and subscriber management system 54 also interacts with the KMS 46 via part of the second communications path 58, since certain rules have to be complied with to ensure the integrity of master devices 14.1 to 14. n and secure delivery of assets to these devices. Utilizing said second communications path 58, various checks are carried out including security key verification, billing (financial transactions) and security. Integrity of messages over the IP communications path 58 is ensured by the aforementioned security keys.

As illustrated in figure 2, at least some assets, more particularly movies, may be divided by the content provider 30 into a) a premium or first group of assets and b) a second group of assets. The first group of assets may be assets which are between v months (typically six months) and w months (typically 12 months) into their respective life times, after release. Hence, these assets are relatively recent, normally higher in demand and therefore they are made available to users on a Transactional Video on Demand (TVOD) basis, which is referred to below. The second group may be between w months and x months (typically 36 months) into their respective life times, after release. Hence, these assets have been available for some time and are then made available to users on a Subscription Video on Demand (SVOD) basis. Broadcasting of these groups may be prioritized by the carousel server, so that TVOD assets are broadcast more frequently than SVOD assets. Video on demand (VOD) is a system which allows users to select and watch/listen to video and/or or audio content when they choose to, rather than having to watch a linear broadcast at a specific broadcast time. SVOD includes services that require users or subscribers to pay a periodic, such as monthly, fee to access a bundled group of assets at any time during the subscription period. With TVOD, the user pays for each individual asset and system rules may provide that the asset acquired must be viewed/accessed within a time window (t), such as 24 hours.

Referring now to figure 3, the assets 28 that are received from the content provider 30 arrive and are ingested at the central backend 12. Each asset is assigned a specific number such as 001 , 002, 003 ... to n. For explanatory purposes, the processing of an asset in the form of a movie is explained below. It will be appreciated that many other assets may be processed by the system 10 such as but not limited to series, documentaries, e-learning programmes, e-books, intelligently and dynamically cached content from suitable and popular websites, such as YouTube etc. An asset typically comprises one or more of media data 60 which comprises the audio visual data relating to the movie, metadata 62 in the form of an Extensible Markup Language (XML) file, which includes data such as: a start and end date of an availability time window (T) of the movie, the cast, the director etc; an image file such as a Joint Photographic Experts Group (JPEG) file 64 comprising an icon or a still image (such as that typically used on posters relating to the movie); parental control level of the movie; and trailer data 66 comprising data relating to a trailer of the movie. The media data 60 is DRM encrypted with a respective DRM key, as explained above. For each asset, the DRM encrypted media data 60, the metadata 62, the JPEG 64 and the trailer data 66 relating to that asset are subsequently compressed by any suitable file compression format such as .ZIP. The .ZIP file for movie asset 001 is illustrated at 68 in figure 3.

Also at the backend 12, the content control message file is generated. In this example embodiment the content control message file comprises a running "white" list or inventory of the assets 001 , 002, 003 etc that are processed as described above, are made available to the master devices 14.1 to 14. n as will be explained below, and which must continue to remain pre-stored on the HDD's 26 and/or remain available to be accessed by users via the master devices 14.1 to 14. n. In other embodiments, the MF 20 may comprise a running "black" list of assets currently stored on the HDD 26, but which must be deleted by the master device. In still other embodiments, entries in the MF 20 may include a field in which a command (C), such as "delete" or "update" may be stored. In some embodiments, a similar field may be used for data relating to the availability time window (T) of the movie. The MF 20 is also encrypted and compressed by a suitable file format such as .ZIP.

All the above compressed files (asset files and the MF file) are also cryptographically protected using cryptographic hash functions, such as message-digest (MD5), the value of which is also saved in the file as shown at 70.

An error correction technology is applied to the asset data which may increase the size of the asset file, but also enables a certain level of error detection and correction to handle data that gets lost or corrupt during transmission. The technology used for the error correction may loosely be based on the Multiprotocol Encapsulation Forward Error Correction (MPE- FEC) standard. However, as implemented it may have adaptations to optimise transmission over IP based multicast User Datagram Protocol (UDP) transmissions as well as satellite and terrestrial RF broadcast conditions. Many of the error correction parameters may be adjusted. The process of adding error correction codes and control codes to manage the transfer of the asset may be designed for optimum efficiency and suitability for digital RF broadcast over an MPEG2 transport stream.

Assets may be scheduled to be outputted periodically and in a given sequence. Multiple assets may be outputted at the same time, sharing the available bandwidth. Each queue of assets to be outputted is referred to as a streamer. Each streamer has its own queue of jobs, where each job relates to an asset file to be broadcast. The carousel server 38 may be monitored and controlled via a Representational State Transfer (REST) interface. The aforementioned compressed and cryptographically protected files are forwarded to the carousel server 38. At the carousel server, the processed files may be arranged into at least two sets of files as stated above. In the example embodiment, the files are arranged into three sets 18.1 , 18.2 and 18.3.

The first set 18.1 of files may comprise at least one of the MF 20, a messages file 72 comprising data that may inter alia relate to messages that may be displayed on the GUI 23.1 and 23.2 as will be explained below and one or more files 74 comprising operational data such as data relating to updates of software running on the master devices and/or the operating system (OS) for Virtual Machines (VM) that may be hosted by the master device 14.1 and/or configuration data relating to a required configuration of the GUI, thereby to effect dynamic updating of the GUI in at least one of configuration and content, such as advertisements or promotions, to be displayed on the GUI. The first set 18.1 of files may further comprise metadata updates as required by the content provider 30. In some embodiments, the first set of files 18.1 may also comprise data (such as schedules for switches) relating to or for use in home automation applications, such as those disclosed in the applicant's Patent

Cooperation Treaty (PCT) application PCT/IB2015/055774 filed on 30 July 2015 entitled "Media player device serving as hub or gateway for home automation", the contents of which are incorporated herein by this reference. The first set 18,1 of files is given first priority and sent out sequentially and at a first repetition rate which is higher than the corresponding repetition rates of the second set 18.2 and of the third set 18.3. The carousel server 38 prepares the data to be forwarded to the encapsulator 39 for distribution over DVB MUX 40 which multiplexes the data received from the encapsulator 39 with data 44 received from other data sources, before broadcasting same over the first communications path 16 as explained above.

The second set 18.2 of files typically comprises the compressed and protected files comprising premium or recently released DRM protected assets that are typically made available on TVOD basis (as discussed above with reference to figure 2). Examples are assets 001 , 002, etc which are shown in the second set 18.2 in figure 3 and which are sent out by the carousel server 38 less frequently than the first set 18.1 of files.

The third set 18.3 of files typically comprises the protected and compressed files of DRM protected assets that are typically made available on SVOD basis (as discussed above with reference to figure 2). Examples are assets 2001 , 2002, 2003, etc which are sent out by the carousel server 38 less frequently than the second set 18.2 of files.

Data leaving the carousel server 38 may be configured to use unicast UDP, multicast UDP, or a custom multi protocol encapsulated stream protocol. The UDP protocols would require the carousel server 38 to control the bitrate of every job being transmitted, and are broadcast protocols in that there is no handshaking with the recipient of the output data.

In addition to UDP, the carousel server 38 may also support a custom stream transmission protocol, which allows for handshaking (and thus hugely improved transmission reliability over ethernet) as well as upstream bitrate control. However this requires a non-standard upstream device to receive the data and control the link.

Hence, the encapsulator supports the reception of data utilizing the custom bidirectional stream communications protocol referred to above. The encapsulator also uses a REST interface for monitoring and control.

The main function of the encapsulator is to receive "raw" data streams from the carousel server 38, and package these into a format suitable for combining with a full satellite (or terrestrial or cable) digital broadcasting system. It is required to format and combine all input streams, add additional MPEG2 system information tables, and output the MPTS with a strictly controlled output bitrate. The encapsulator feeds a commercial MUX 40 which combines the MPTS stream with other streams 44 and transmits them to the satellite as a single MPEG2 transport stream.

A feature of the above method and system, which is enabled by the custom communication protocol between the carousel server and the encapsulator, is to be able to dynamically and intelligently manage the bitrates of the various asset streams coming from the carousel server 38. This means that rules may be given to the encapsulator 39 to allocate all available spare bandwidth to a single (high priority) stream, and it will dynamically scale the bandwidth for this stream up or down whenever other streams stop or start. The allocation of fixed guaranteed bandwidth to the other streams can be adjusted (using the REST interface) while the system is busy running. This allows customizable and/or optimal bandwidth utilisation for data transmission.

When standard UDP transmission protocols are used, each data stream has to have a fixed bitrate which can't be dynamically adjusted. If a stream stops, then the encapsulator inserts NULL (empty) packets in their place to make up the required output bandwidth. This is also prone to overloading of the encapsulator if the bitrates of the UDP streams exceed the available output bandwidth. In this case the encapsulator is forced to discard excess data. This situation does not occur when the encapsulator itself controls the input stream rates, since it is aware of the maximum output bitrate and can control the rates of the input streams never to exceed this.

As stated above, the files in the first set 18.1 of files are sequentially and cyclically outputted at a first cycle repetition rate, the files in the second set 18.2 are sequentially and cyclically outputted at a second cycle repetition rate, which is slower than the first cycle repetition rate and the files in the third set 18.3 are sequentially and cyclically outputted out at a third cycle repetition rate, which is slower than the second cycle repetition rate. The custom bidirectional stream communication protocol used between the carousel server 38 and the encapsulator enables the bitrates of various data streams to be controlled dynamically and intelligently. The encapsulator 39 is configured to control input bitrates from the carousel server 38 in order to accommodate for a certain maximum output bitrate.

The broadcast sets of files are received by the master devices 14.1 to 14. n via the first communications path 16. One of these master devices, in the form of a set top box STB 14.1 , is shown in figure 4. Using a receiver and a demultiplexer, the STB 14.1 can filter out streams from the signal received from the satellite over the first communications path 16 that contain the asset data being transferred and process these to detect and correct transmission errors. Multiple assets corresponding to multiple streams can be processed in parallel. The exact nature of the data output by the carousel in each stream is designed to be optimised to take advantage of perhaps limited central processing unit (CPU) processing power on the master device 14.1 and to maximise available hardware (embedded silicon) subsystems to alleviate the load required to analyse and reconstruct the assets from the data stream. This includes optimising usage of hardware cyclic redundancy check (CRC) checking, optimising section sizes to best suit MPEG demultiplexer capabilities, and optimising control block transmission repetition rates to minimise efficiency but still maintain robustness (e.g. the ability of a receiver to start downloading a stream even when it misses the start of the transmission or to recover when there was a very large burst error, such as could be caused by bad weather severely affecting transmission, etc).

As shown in figure 3, current time and date is an important input to the master device 14.1. The time and date can be obtained either via the first communications path 16 or the second communications path 58. The time and date may be used inter alia to check whether the movie is still within its availability window (T). The time and date input may also be used to determine the respective asset's current age in its respective lifetime on the timeline (shown in figure 2) and handle the asset accordingly as will be explained in further detail below (with reference to figure 5). Once a file (asset, MF or other files etc) has been received by the master device 14.1 , if the file is found to have unrecoverable errors, the file is still at least temporarily stored and may be used as a starting point for recovery of the remainder of the file during the next repetition cycle of the set of which the file forms part. In such a case, only the sections of the file in error need to be received and processed to complete the download. If a file (or part thereof) was correctly received in the first instance, it need not be re-processed during the next cycle, which saves processing power.

Referring to figure 4, at the master device 14.1 , received data is demultiplexed. Next, the assets are unzipped and the MF 20 is both unzipped and decrypted. Cryptographic hash functions such as MD5 checks are performed to verify that the files are complete and correct. Both the DRM protected assets and MF are then stored in the library 22 on local HDD 26. A local directory is created on said hard drive 26 pointing at the stored assets and MF.

Figure 5 shows an example embodiment of an algorithm that may be used by the master device to process the received data. Forward Error Correction (FEC) is performed at 80. Packets of the zipped data are received at 82 and concurrent processing of a plurality of data streams may be performed as shown at 84. This FEC may comprise a hardware based scheme to correct errors in a DVB broadcast stream and/or a software based scheme to correct errors in the content of the broadcast file,

It will be appreciated that the processing will be performed for every stream, but by way of illustration only, the processing of the data stream relating to the MF 20 is illustrated at 84 and described in more detail below. For the MF 20, the processing is generally as follows: the algorithm stores MF_TEMP (a temporary master file) at 86. At 88 checks are performed to determine if the received MF_TEMP file is complete and whether there are errors. If the file is not complete, a next version in a subsequent cycle is awaited. If there are errors in the file, each error's position is flagged to be corrected during the next cycle.

If on the other hand, the MF_TEMP is complete, the processor performs MD5 checks at 90. If the received MD5 hash value 70 (shown in figure 3) is equal to the locally computed hash value, the MD5 check passes. If MD5 passes, the time stamp in the MF_TEMP file is checked at 92, 94 against that of an immediately previously stored version. If the MF_TEMP is new (in that its time stamp is later in time than that of the immediately previously stored version), the MF_TEMP file is saved at 96 on the HDD

26 as MF_V (a verified master file). If MF_TEMP is not new, it is discarded and the algorithm starts over as shown. As explained below, at 98 the algorithm performs the function of comparing MF_V to the locally stored assets in the library 22. It will be appreciated that MF_V, like MF, also comprises at least the fields C and T (as referred to above with reference to figure 3). The pre-stored assets in library 22 are accordingly deleted or updated according to the command field C in the newly stored MF_V. The assets may also be removed if the time availability window T for that asset has expired. An example would be if a TVOD movie changes to the SVOD bundle after time period w referred to in figure 2. Another example would be an SVOD movie that is to be taken off the system, after time x referred to in figure 2. A Content

Manager Application (CMA) may be installed on the STB which application runs at least on a daily basis to update and or delete files on the master device as necessary. Since the MF includes the command field C such as "delete" or "update", the master device can handle assets in library 22 accordingly. It will be appreciated that the system enables control from the backend 12 of the assets pre-stored on the HDD 26, for example to be deleted and/or updated quickly and efficiently, as the case may be. For example, if a "delete" command (C) in respect of asset 001 is issued by the content provider 30, at the backend 12 and in the MF 20, the delete command field is appropriately populated in respect of asset 001 . The updated MF 20 is broadcast as aforesaid and once received and processed by the master 2

devices 14,1 to 14. n, the associated asset 001 is immediately deleted from the HDD 26 of all the master devices 14.1 to 14. n in the system population. Similarly the update command can be used and assets accordingly updated on the hard drives of the master devices 14.1 to 14. n. Since the MF is highly prioritized, the command such as "delete" or "update" arrives at the remote devices quickly and efficiently.

Figure 6 depicts an example embodiment of the configuration of the GUI 23.1 that may be displayed on the renderer device 27.1 connected to the master device 14.1 . As shown in the figure, the user is able to select by adjusting the "focus" 100 to one of a plurality of available menus, such as "entertain", "services", "settings", "apps" and "account". In the current example, the user selects "entertain" as focus. Sub-menus 102 such as "movies", "TV shows" (or series), cached (preferably intelligently cached) content such as "YouTube" content, "sports", "news" and "my media" can be selected. The rectangular areas 104 towards the bottom of the GUI may be used to display the aforementioned messages which may be included in messages file 72 in the first set 18.1 of files referred to above. It will be appreciated that with the high priority given to the first set 18.1 of files, these messages can be updated dynamically from the backend. Similarly, based on the configuration data in file 74 in the first set of files, the configuration of the GUI may similarly and dynamically be updated. Other information such as the current time, messages, connections, etc po

may also be displayed at 106 towards the bottom of the GUI 23.1 , In use, and whilst a user may browse any one of the aforementioned sub-menu's, a trailer based on the aforementioned trailer data 66 in respect of an asset pointed at, may be played in the background on the GUI. In the event that a user elect a particular pre-stored asset for viewing, a DRM decryption key is required. The decryption key is provided from the backend 12 via the second communications path 58, in secure manner, as more fully described in the applicant's PCT application PCT/IB/2015/054516 entitled "Delivery of DRM protected content to distributed user stations", the contents of which are incorporated herein by this reference.

Figure 7 depicts the Ul 23.2, but with "services" selected as "focus" 100. In this example embodiment the user is able to select from services, such as home surveillance. These services may be provided and performed as described in the applicant's above PCT/IB2015/055774.

Each master device also has a unique device identification (ID) number (preferably in the nature of an Internet Protocol (IP) address) and a unique serial number (SN) assigned to it and which numbers are stored on the KMS. The integrity of the master device 14.1 is ensured through use of the above security keys together with the SN that uniquely identifies the STB in the associated database at the backend for security purposes and to prevent device impersonation. The ID and SN, in turn, are used for identification of the user's master device.

Specific assets or data can also be targeted via the first communications paths at individual or groups of devices based on the unique device identification (ID) number. Devices not matching this ID will ignore these assets or data. When content is received by master device 14.1 , the master device will only be enabled to process the content if the content passes a first filter based on the ID. It will be appreciated that there are many variations in detail on the invention as herein defined and/or described without departing from the scope and spirit of this disclosure. The master devices 14.1 t 14.n may also be configured to stream IP data directly via an ethernet interface. This may eliminate both the encapsulator component and the carousel component, and the master device would stream the data directly from the backend via the second communications path 58. This (networked) configuration is not applicable to digital RF broadcast systems, but can be utilised for IP (internet protocol) based distribution systems.

Claims

1. A method of controlling from a central backend, content in a local library of assets stored on a respective mass data storage device of a plurality of distributed master devices, each master device being connectable to a respective renderer device comprising a monitor for displaying at a respective user station a graphical user interface (GUI), the method comprising:

- causing the at least first set of files and the second set of files to be received at each of the master devices, to be processed and if they comply with a first set of rules, to be stored in the local library of assets; and - utilizing the received content control message fiie to update the content of the local library of assets in accordance with the library content control messages.

2. The method of claim 1 wherein the content control message file is incorporated into the first set of files.

3. The method as claimed in any one of claims 1 and 2 comprising outputting a third set of files comprising respective assets, the third set of files being outputted repeatedly at a third average repetition rate which is slower than the second average repetition rate.

4. The method as claimed in any one of claims 1 to 3 wherein the content control message file comprises data relating to assets to be deleted from the local library.

5. The method as claimed in any one of claims 1 to 3 wherein the content control message file comprises data relating to assets to be retained in the local library.

6. The method as claimed in any one of claims 2 to 5 comprising incorporating into the first set of files at least one of: a file comprising data relating to messages to be displayed on the GUI; and a file comprising configuration data relating to a required configuration of the GUI.

7. The method as claimed in any one of claims 3 to 6 comprising outputting the first, second and third sets of files from a carousel server.

8. The method as claimed in any one of claims 1 to 7 comprising, before outputting the first, second and third sets of files, protecting the respective assets with a respective digital rights management (DRM) protection token.

9. The method as claimed in claim 8 comprising, after having protected the respective assets, compressing the respective files.

10. The method as claimed in claim 9 comprising cryptographically protecting the respective compressed files in the first, second and third sets of files.

1 1 . The method as claimed in any one of claims 7 to 10 comprising utilizing an encapsulator between the carousel server and a distributor, to package the first, second and third sets of files in a Multi Program Transport Stream (MPTS), before they are distributed via one of a satellite, terrestrial and cable distribution system.

12. A method of controlling content in a local library of assets stored on a respective mass data storage device of a master device at a user station comprising, at the master device: - repeatedly receiving at least a first set of files and a second set of files which second set of files comprises respective assets, the first set of files being repeatedly received at a first average repetition rate and the second set of files being repeatedly received at a second average repetition rate, which is slower than the first average repetition rate;

At least one carrier comprising respective parts of a computer program, which when executed on at least one processor at a central backend, performs the method as claimed in any one of claims 1 to 1 1.

14. A carrier comprising a computer program, which when executed on at least one processor on a master device performs the method as claimed in 12.