WO2016042510A1 - Commande dynamique d'un contenu sur des dispositifs de lecteur multimédia distribués à l'aide d'un mécanisme de carrousel - Google Patents

Commande dynamique d'un contenu sur des dispositifs de lecteur multimédia distribués à l'aide d'un mécanisme de carrousel Download PDF

Info

Publication number
WO2016042510A1
WO2016042510A1 PCT/IB2015/057155 IB2015057155W WO2016042510A1 WO 2016042510 A1 WO2016042510 A1 WO 2016042510A1 IB 2015057155 W IB2015057155 W IB 2015057155W WO 2016042510 A1 WO2016042510 A1 WO 2016042510A1
Authority
WO
WIPO (PCT)
Prior art keywords
files
assets
content
library
content control
Prior art date
Application number
PCT/IB2015/057155
Other languages
English (en)
Inventor
Alan John Sullivan
Original Assignee
Altron Tmt (Pty) Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Altron Tmt (Pty) Limited filed Critical Altron Tmt (Pty) Limited
Publication of WO2016042510A1 publication Critical patent/WO2016042510A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26266—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for determining content or additional data repetition rate, e.g. of a file in a DVB carousel according to its importance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof

Definitions

  • 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.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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.
  • GUI graphical user interface
  • SMS Short Message Service
  • 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.
  • 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.
  • DRM digital rights management
  • 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.
  • the content control message file comprising library content control messages relating to assets to be stored in the local library
  • 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.
  • the content control message file comprises data relating to assets to be deleted from the local library.
  • the content control message file comprises data relating to assets to be retained in the local library.
  • 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.
  • 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.
  • DRM digital rights management
  • 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.
  • MPTS Multi Program Transport Stream
  • 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.
  • a system configured for performing the above method.
  • a backend configured for performing the above method.
  • 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:
  • 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.
  • a master device configured for performing the above method.
  • 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;
  • FIG 2 is a diagrammatic representation of example time periods associated with Transactional Video on Demand (TVOD) movies and Subscription Video on Demand (SVOD) movies;
  • TVOD Transactional Video on Demand
  • SVOD Subscription Video on Demand
  • 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.
  • FIG 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.
  • 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.
  • MF master file
  • 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.
  • 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.
  • CMS content management system
  • 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).
  • DRM Digital Rights Management
  • MS Microsoft
  • the token may comprise at least one of a key, certificate or algorithm which is stored in a DRM key database 36.
  • 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).
  • MPTS Multi Program Transport Stream
  • 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.
  • MPEG Moving Picture Experts Group
  • 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).
  • DVD S/T/S2 T2 Digital Video Broadcasting standards
  • the first communications path 16 may alternatively comprise a Digital terrestrial television (DTT) path or a cable path.
  • DTT Digital terrestrial television
  • the backend 12 further comprises a Key Management Server (KMS) 46.
  • KMS Key Management Server
  • 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).
  • ADSL Asymmetric digital subscriber line
  • GSM Global System for Mobile Communications
  • GPRS Global System for Mobile Communications
  • 3G or 4G or LTE Long Term Evolution
  • IP Internet Protocol
  • 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.
  • At least some assets 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.
  • 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.
  • these assets have been available for some time and are then made available to users on a Subscription Video on Demand (SVOD) basis.
  • SVOD Subscription Video on Demand
  • Video on demand 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.
  • each asset 28 that are received from the content provider 30 arrives and are ingested at the central backend 12.
  • Each asset is assigned a specific number such as 001 , 002, 003 ... to n.
  • 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.
  • 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.
  • the content control message file is generated.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • REST Representational State Transfer
  • the aforementioned compressed and cryptographically protected files are forwarded to the carousel server 38.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • CPU central processing unit
  • CRC hardware cyclic redundancy check
  • 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).
  • 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.
  • received data is demultiplexed.
  • 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.
  • FIG. 5 shows an example embodiment of an algorithm that may be used by the master device to process the received data.
  • FEC Forward Error Correction
  • 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,
  • 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.
  • 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.
  • MF_TEMP a temporary master file
  • 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
  • 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.
  • 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.
  • CMA Manager Application
  • 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
  • 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.
  • 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 .
  • 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”.
  • 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
  • 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.
  • 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.
  • 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.
  • ID device identification
  • SN unique serial number 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 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.
  • ID unique device identification
  • the master device 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention concerne un procédé pour commander, à partir d'un logiciel dorsal central (12), un contenu dans une bibliothèque locale d'actifs stockés sur un dispositif de stockage de données de masse respectif (26) d'une pluralité de dispositifs maîtres distribués (14.1 à 14.n). Le procédé consiste à délivrer au moins un premier ensemble (18.1) de fichiers et un second ensemble (18.2) de fichiers, lequel second ensemble comprend des actifs respectifs. Le premier ensemble est délivré de manière cyclique à une première vitesse de répétition et le second ensemble est délivré de manière cyclique à une seconde vitesse de répétition, qui est plus lente que la première vitesse de répétition. Un fichier de message (MF) de commande de contenu (20) comprenant des messages de commande de contenu de bibliothèque associés à des actifs à stocker dans la bibliothèque locale est incorporé dans le premier ensemble. Le premier ensemble de fichiers et le second ensemble de fichiers sont reçus au niveau de chacun des dispositifs maîtres, traités et s'ils sont conformes à un ensemble de règles, sont stockés dans la bibliothèque locale. Le MF reçu est utilisé pour mettre à jour les contenus de la bibliothèque locale d'actifs conformément aux messages de commande de contenu de bibliothèque.
PCT/IB2015/057155 2014-09-17 2015-09-17 Commande dynamique d'un contenu sur des dispositifs de lecteur multimédia distribués à l'aide d'un mécanisme de carrousel WO2016042510A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ZA2014/06805 2014-09-17
ZA201406805 2014-09-17

Publications (1)

Publication Number Publication Date
WO2016042510A1 true WO2016042510A1 (fr) 2016-03-24

Family

ID=54325571

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2015/057155 WO2016042510A1 (fr) 2014-09-17 2015-09-17 Commande dynamique d'un contenu sur des dispositifs de lecteur multimédia distribués à l'aide d'un mécanisme de carrousel

Country Status (1)

Country Link
WO (1) WO2016042510A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6741834B1 (en) * 2000-06-06 2004-05-25 Hughes Electronics Corporation Device and method to improve integrated presentation of existing radio services and advanced multimedia services
WO2010051858A1 (fr) * 2008-11-10 2010-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Procédé de fourniture de données à un client

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6741834B1 (en) * 2000-06-06 2004-05-25 Hughes Electronics Corporation Device and method to improve integrated presentation of existing radio services and advanced multimedia services
WO2010051858A1 (fr) * 2008-11-10 2010-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Procédé de fourniture de données à un client

Similar Documents

Publication Publication Date Title
US10382816B2 (en) Systems and methods for performing transport I/O
JP5710273B2 (ja) 衛星配信テレビのための暗号化システム
US9537944B2 (en) Method and apparatus for file sharing of missing content between a group of user devices in a peer-to-peer network
US7992175B2 (en) Methods and apparatus to provide content on demand in content broadcast systems
EP2273405A1 (fr) Traitement de contenu enregistrable dans un flux
US20080254739A1 (en) Method and system for file sharing between a group of user devices using obtained permissions
KR101705010B1 (ko) 스트림에서의 레코딩가능한 콘텐트의 프로세싱
JP2010028693A (ja) コンテンツ配信システム、コンテンツ受信方法および装置
US11451849B2 (en) Methods and systems for content control
US20120042092A1 (en) Method for transmitting an iptv streaming service by p2p transmission, and method for receiving an iptv streaming service by p2p transmission
WO2012027535A2 (fr) Transport de supports partiellement cryptés
TWI595778B (zh) 用於組合及提取命令及控制資料之系統及方法
JP2010028691A (ja) コンテンツ受信再生方法および装置
CA2972818C (fr) Traitement de contenu video automatise
WO2016042510A1 (fr) Commande dynamique d'un contenu sur des dispositifs de lecteur multimédia distribués à l'aide d'un mécanisme de carrousel
KR101175354B1 (ko) 복수의 수신 제한 시스템을 이용하는 콘텐츠 보안 시스템 및 방법
US20230188810A1 (en) Systems and methods for transporting data over content delivery networks
CN111526378B (zh) 一种签名信息的传输方法及装置
CN102326399A (zh) 用于安全分发根据多个传输协议封装的视听数据的方法和设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15781149

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15781149

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 16/10/2017)

122 Ep: pct application non-entry in european phase

Ref document number: 15781149

Country of ref document: EP

Kind code of ref document: A1