EP2832105A1 - Recevoir du contenu audio/vidéo - Google Patents

Recevoir du contenu audio/vidéo

Info

Publication number
EP2832105A1
EP2832105A1 EP13725729.1A EP13725729A EP2832105A1 EP 2832105 A1 EP2832105 A1 EP 2832105A1 EP 13725729 A EP13725729 A EP 13725729A EP 2832105 A1 EP2832105 A1 EP 2832105A1
Authority
EP
European Patent Office
Prior art keywords
data
stream
data stream
content
programme
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP13725729.1A
Other languages
German (de)
English (en)
Inventor
David HILL-JOWETT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Saturn Licensing LLC
Original Assignee
Sony Europe Ltd
Sony Corp
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 Sony Europe Ltd, Sony Corp filed Critical Sony Europe Ltd
Publication of EP2832105A1 publication Critical patent/EP2832105A1/fr
Withdrawn legal-status Critical Current

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
    • 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26606—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing entitlement messages, e.g. Entitlement Control Message [ECM] or Entitlement Management Message [EMM]
    • 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
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43607—Interfacing a plurality of external cards, e.g. through a DVB Common Interface [DVB-CI]
    • 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
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/418—External card to be used in combination with the client device, e.g. for conditional access
    • H04N21/4181—External card to be used in combination with the client device, e.g. for conditional access for conditional access
    • 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
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/4263—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific tuning arrangements, e.g. two tuners
    • 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
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • 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
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4367—Establishing a secure communication between the client and a peripheral device or smart card
    • 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
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
    • 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
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4408—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream encryption, e.g. re-encrypting a decrypted video stream for redistribution in a home network

Definitions

  • This disclosure relates to receiving audio/video content.
  • the DVB Common Interface (“CI”) specification allowed a television receiver or set top box (a "host") to interact with a secure hardware module (a conditional access module or "CAM”) to allow the host to decrypt access-controlled content.
  • the CI specification defines an interface between the host and the CAM, so that the two will0 work together if both conform to the CI specification. This interoperability provided a significant benefit of the CI system, as, in principle, it allowed consumers a choice of compatible products from different manufacturers.
  • the CAM interacts with a smart card and/or a user's personal identification number (“PIN”) to provide user authentication.
  • PIN personal identification number
  • a disadvantage of the original CI specification is that it gave the potential for the decrypted digital content to be copied.
  • This problem arises from the way in which the host and CAM interact.
  • the host sends encrypted data to the CAM.
  • the CAM checks the user authentication and, assuming that the user is authenticated, it decrypts the access- controlled content.
  • the CAM then sends the decrypted content back to the host over the CAM-0 host interface, which is generally a PCMCIA (Personal Computer Memory Card International Association) interface, though it is not limited to this interface - for example, a USB interface could be used.
  • PCMCIA Personal Computer Memory Card International Association
  • CI Plus The CI Plus specification was drafted to address these problems, by two main routes. CI Plus provides a secure interface between the CAM and the host, so that decrypted content data is not sent in clear form between the two devices. Also, CI Plus provides for the authentication of both the host and the CAM, rather than the CI technique of authenticating only the CAM.
  • the authentication system uses certificate hierarchy so that the host and the CAM must both have been issued certificates by an authority (such as CI Plus LLP).
  • the PCMCIA interface between a host and a CAM is protected by encrypting the decrypted content data before it is sent from the CAM to the host, and then decrypting it at the host.
  • This encryption is separate to the access control encryption-decryption established by the content provider, and is specific to each particular CAM-host pair. Keys are exchanged between the CAM and host by the Diffie-Hellman key exchange technique. The keys are also cycled from time to time, so that even if a key was compromised, it would in any event be changed a few seconds later.
  • the CI Plus specification also allows CAMs to be connected in series, or daisychained.
  • Figure 1 is a schematic diagram of a host device with a CAM and a smart card
  • FIG 2 is a schematic diagram of a conditional access (CA) system incorporating the host device of Figure 1 ;
  • CA conditional access
  • Figure 3 is a schematic diagram illustrating the operation of the system of Figure 2;
  • Figure 4 is a schematic diagram of the host device having multiple tuners;
  • Figure 5 schematically illustrates a multiplexer-demultiplexer arrangement
  • FIG. 6a schematically illustrates a so-called M card
  • FIG. 6b schematically illustrates a so-called S card
  • Figure 7 schematically illustrates a transport stream (TS) packet
  • Figure 8 schematically illustrates a data packet of a composite packetized data stream
  • Figure 9 schematically illustrates a multiplexer arrangement in more detail
  • Figure 10 schematically illustrates TS packets of two services
  • Figure 11 schematically illustrates a set comprising a succession of CAMs
  • Figure 12 schematically illustrates a succession of CAMs with interface units between them
  • Figure 13 is a schematic flowchart illustrating the handling of so-called ghost PIDs
  • Figure 14 schematically illustrates a PID mapping table
  • Figure 15 schematically illustrates operations involved in detecting which CAM of a succession of CAMs is capable of decoding the required programme service
  • Figure 16 schematically illustrates control of multiple tuners by the host device
  • Figure 17 schematically illustrates the multiplexing of two separate programme services
  • Figure 18 schematically illustrates a packet having an augmented packet header
  • Figure 19 schematically illustrates a packet timing data table
  • Figure 20 schematically illustrates the generation of the packet header of Figure 18
  • Figure 21 schematically illustrates the use of the packet header of Figure 18
  • Figure 22 schematically illustrates the generation of the table of Figure 19
  • FIG. 23 schematically illustrates the use of the table of Figure 19.
  • Figure 24 schematically illustrates an SDT signature and signature checking system.
  • a host device 10 is shown here as a television set but could be, for example, a set top box (noting that the expression "set top” does not imply, to the skilled person, any requirement for a particular physical position of the device in use).
  • the host device 10 receives an access-controlled television signal 15 via a broadcast data path.
  • This could be, for example, a satellite television signal received by a satellite dish (not shown), a terrestrial television signal, a cable television signal or the like, although other types of television signal include a television signal broadcast or transmitted by an internet protocol (IP) packet signal.
  • IP internet protocol
  • One technique is to encode an MPEG transport stream (TS) into IP packets so that an IP packet carries a number (for example 7 or 8) TS packets.
  • BMFF Base Media File Format
  • IP interface at a host device is generally considered within the art as a "tuner” even though it may have no radio frequency circuitry or functionality. It does however act in a similar way to a radio frequency tuner in that it selects an IP stream from a multitude of possible IP streams. It may also provide buffering of the received IP stream.
  • the host device 10 has a PCMCIA slot 20 which includes electrical connections and a physical space for a plug-in module, both according to the PCMCIA standard.
  • a universal serial bus (USB) or other electrical interface can be used instead of the PCMCIA interface.
  • a CI Plus conditional access module referred to as a CICAM 30, is a PCMCIA module which can be plugged into the PCMCIA slot 20.
  • a CICAM 30 When the CICAM 30 is fully plugged into the slot 20, electrical connections are made between connectors on the CICAM 30 and cooperating connectors within the slot 20.
  • the CICAM itself may be a cardless module or may have a slot 40 into which a so- called smart card 50 may be inserted.
  • the smart card is removable and carries information defining a current user of the content receiver in a tamper-proof, secure and non-volatile form.
  • a data connection is formed between the smart card 50 and the CICAM 30, either by using cooperating electrical connectors on the smart card 50 and within the slot 40, or by using a known contactless connection technique in which data is transferred wirelessly over a very short range such as 1-2 cm.
  • FIG. 2 schematically illustrates the host device 10 in the context of a conditional access system.
  • a so-called head end 60 represents the source of the access-controlled television signal 15.
  • the head end may represent, for example, an uplink station of a satellite broadcaster or a signal distribution centre of a terrestrial or cable broadcaster.
  • the CA system scrambles content at the head end using a CA system encryption.
  • the head end can also introduce other CA-related information into the encrypted data stream which enables the CICAM to descramble the content and to manage the subscriber's (user's) access and entitlements.
  • the head end 60 sends the television signal 15 to the host 10 which in turn passes the signal to the CICAM 30 for decryption of the access control encryption.
  • the CICAM 30 then re- encrypts the signal using a local encryption and sends the re-encrypted signal back to the host 10 via the PCMCIA connection.
  • the host decrypts the signal received from the CICAM 30 for display on a display screen or for supply to another device 70 such as a hard disk based video recorder.
  • Figure 3 is a schematic diagram illustrating the operation of the system of Figure 2. The detailed operation of the system of Figure 3 is described in the CI Plus Specification 1.3 (2010- 01), available (at the time of filing) at http://www.ci-plus.eom/data/ci-plus_specification_v1.3.pdf. This document is incorporated by reference into the present description. The present description of Figure 3 simply provides an overview of that detailed operation, for the purposes of placing the subsequent description into the appropriate technical context.
  • Figure 3 shows the head end 60 (which receives a content signal from a content provider 90), the host device 10, the CICAM 30 and the smart card 50.
  • the signal 15 is shown passing from the head end 60 to the host device 10.
  • the secure interface 80 between the host device 10 and the CICAM 30 is referred to as the common interface.
  • Known CA systems provide techniques by which a user can be denied or allowed access to a digital television stream. Access is provided only to those subscribers or users with valid payment accounts.
  • a user is provided with a smart card 50 identifying that user in (ideally) a tamper-free way, and the system is set up so that only users with valid smart cards are able to obtain access to the access-controlled content.
  • Access control is provided by the use of scrambling and encryption.
  • the content signal is scrambled with an 8-byte control word, which is changed frequently (up to several times per minute) to avoid the CA system being compromised by outside knowledge of the control word.
  • the control words are transmitted to the receiver's CICAM, for descrambling of the scrambled content, in an encrypted form as an entitlement control message (ECM).
  • ECM entitlement control message
  • the CICAM decrypts the control word to allow descrambling of the access-controlled content only when it is authorised to do so by receipt of an entitlement management message (EMM).
  • EMMs are specific to each user or group of users; the CICAM confirms the rights which an EMM provides by comparing the user identification provided in the EMM with user information provided in the smart card 50.
  • the EMMs can be sent less frequently than the ECMs, with intervals between successive EMMs in current commercial systems varying between 12 minutes and six weeks.
  • ECMs and EMMs themselves are well known message types in M PEG television distribution systems.
  • the format of their payloads can be specific to the CA system in use, with the differences between formats often being semantic rather than having technical significance.
  • the ECM and EMM data are carried in a packetized data stream as data packets defining decryption information and are used in the decoding process to decode an audio/video programme from the packetized data stream.
  • the head end 60 comprises a CA encryptor 61 , a key generator 62, an entitlement control unit 63 and a multiplexer and modulator 64.
  • the content provider 90 supplies content (such as television signals) to the head end
  • the head end 60 applies conditional access (CA) scrambling and encryption to the content. More specifically, the CA encryptor 61 encrypts or scrambles the content using a CA key as a control word.
  • the CA key is generated by the CA key generator 62.
  • the scrambled content generated by the CA encryptor is supplied to the multiplexer and modulator 64.
  • the CA key is also provided to the entitlement control unit 63, which generates ECMs based on the CA keys and EMMs based on subscriber data defining which subscribers are entitled to descramble which content streams.
  • the ECMs and EMMs are supplied to the multiplexer and modulator 64.
  • One or more scrambled content streams from the CA encryptor 61 , one or more unscrambled (open access or "free to air") content streams and the entitlement control messages are multiplexed together to form a transport stream such as an MPEG2 transport stream.
  • Known formats are used to carry the content data, the ECMs and the EMMs.
  • the ECMs, EMMs and data defining the type of scrambling used on each elementary stream are provided in a known format and are referenced using known techniques in a programme map table (PMT and/or in a conditional access table (CAT) which has a predetermined programme identifier (PID) of 0x001 , so that the CAT can be recognised at the CICAM.
  • PMT programme map table
  • CAT conditional access table
  • PID programme identifier
  • the multiplexed transport stream is then modulated by the multiplexer and modulator 64 for transmission as a cable, satellite or terrestrial broadcast signal 15.
  • the host device 10 comprises a tuner 11 , a demodulator and demultiplexer 12, a demultiplexer ("demux") 13 and a CC (content control) decryptor 14.
  • the host device may have other additional functions; for example, a host device may provide two or more of satellite broadcast reception, cable broadcast reception, terrestrial broadcast reception and network (IPTV) television reception.
  • IPTV network
  • the tuner acts to transform the received signal back to baseband, so that the demodulator and demultiplexer 12 can select and demultiplex a single elementary content stream and associated CAT data from the received signal.
  • the content stream and ECM / EMM data are passed via the common interface 80 to the CICAM 30.
  • the content data is still scrambled as it is passed via the common interface 80 to the CICAM 30. This part of the transmission over the common interface 80 is therefore secure by virtue of the CA encryption.
  • the CICAM 30 descrambles the content data and re-encrypts it using a content control (CC) encryption.
  • the way in which this is done will be described below.
  • the CC encrypted data is returned to the host device 10 where it is demultiplexed by the demux 13 and decrypted by the CC decryptor 14, so that it can be displayed or passed to another device 70 as clear content.
  • the host device therefore operates to receive audio/video content and has a content decoder (the CAM module for example) capable of decoding an audio/video programme from a packetized data stream (such as a TS) by using data packets (such as EMM/ECM) defining decryption information.
  • the received TS may comprise one or more programmes having data packets identified by respective sets of packet identifiers (such as PI Ds) and comprising identification data (PAT, PMT, CAT and the like) mapping programmes to respective sets of the PIDs.
  • the CICAM 30 comprises a CA decryptor 31 , a CA key generator 32, a CC encryptor 33 and a CC key generator 34.
  • the CA decryptor 31 and the CA key generator 32 may be considered as an access control unit for decoding access-controlled broadcast content or other data.
  • the CC key generator 34 and the CC encryptor 33 of the CICAM 30, and the demultiplexer 13 and the CC decryptor 14 of the host device 10 cooperate to provide an encrypted communication link (the common interface 80) for decoded access-controlled encoded broadcast content, between the
  • the CA decryptor 31 uses keys generated from received ECMs and EMMs by the CA key generator 32, using checks of the user's identity from the smart card 50, to descramble the received access-controlled content. This part of the operation of the CICAM uses known CA techniques to retrieve and apply the CA keys.
  • Clear content data is passed from the CA decryptor 31 to the CC encryptor 33.
  • this data transfer is entirely internal to the CICAM, it can be rendered secure and tamper proof by known techniques such as by providing the CA decryptor 31 , the CC encryptor 33 and the clear content interface within a single integrated circuit device.
  • the CC encryptor 33 encrypts the descrambled content using a CC key supplied by the
  • CC key generator 34 This key is established by a secure interchange between the CICAM 30 and the host device 10, and is specific to that CICAM-host device pair.
  • the CC-encrypted content is passed over the common interface 80 to the host device 10. Therefore, this part of the common interface is also secure, as the content data is CC-encrypted as it passes to the host device.
  • the CICAM 30 and the host device 10 both contain logic, firmware or software providing algorithms for Diffie-Hellman (DH) secure key exchange, hashing and encryption using the known algorithms SHA-256, DES and AES, respective certificates issued by a certifying authority such as CI Plus LLP, and private keys with the corresponding public keys.
  • DH Diffie-Hellman
  • the CICAM 30 initiates an authentication process with the host device 10. In this process, each device verifies the other's certificate, and the DH key exchange process takes place so as to securely share keys between the two devices.
  • the CICAM first requests that the host device provides its certificate data. The CICAM verifies the signature on the host device's certificate.
  • the same process is then carried out by the host requesting and verifying the CICAM's certificate.
  • the CICAM and the host then each demonstrate that they possess the private key corresponding to the public key in the certificate by signing a DH public key and sending it to the other device for validation.
  • the CICAM then obtains and verifies an authentication key AKH from the host.
  • the CICAM and host start to compute and exchange key data for the encryption and authentication of data sent over the common interface 80. In this way, the key, key pair or other key information established by the CICAM and the host for communication over the common interface 80 is specific to that CICAM-host pair.
  • the CICAM After authentication, the CICAM also starts to compute the CC key.
  • the CICAM can also instruct the host device to compute the CC key.
  • the CC key is then used as described above to encrypt content data passed from the CICAM 30 to the host device 10, according to the AES algorithm. Therefore, it will be understood that the keys used for the secure common interface 80 are specific to a particular CICAM-host pair.
  • FIG 4 is a schematic diagram of a host device 100 having multiple tuners illustrated as tuner A 102 and tuner B 104, each receiving a radio-frequency (RF) input signal.
  • the RF input signal may be a common signal 106 processed by each of the multiple tuners, for maybe a different respective signal for different tuners (for example, one tuner may operate in respect of terrestrial broadcast television and another tuner may operate in respect of satellite broadcast television).
  • the system is not limited to two tuners; the principles to be described may be extended to more than two tuners, but only two are shown in Figure 4 for clarity of the diagram.
  • Each of the tuners 102, 104 supplies an output to a respective demodulator 108, 110.
  • the output may represent data, such as a packetized data stream or TS, transmitted by a single respective transmission channel, as selected (from a plurality of tunable transmission channels) by that tuner.
  • the demodulators operate as described above (in respect of the demodulator 12 of Figure 3) to demodulate a packetized data signal from the output of the respective tuner.
  • the packetized data signals from the multiple demodulators 108, 1 10 are multiplexed together by a CI controller 112 for handling by a set of one or more CAMs 1 14 as a series-connected set of two or more content decoders. .
  • the set of CAMs 1 14 is capable of concurrently decoding more than one programme service for output.
  • the set of CAMs may be arranged to decode the same number of programme services concurrently as there are tuners provided in the host device 100.
  • Decoded data received back from the set of CAMs 1 14 is demultiplexed by the CI controller 1 12 into respective signals 1 16, 1 18 representing the required programme services. These are passed to programme demultiplexers 120, 122 similar in function to the demultiplexer 13 of Figure 3.
  • each programme service is prepared for output by a respective decoder 124, 126 corresponding in function to the CC decryptor 14 of Figure 3.
  • the decoders 124, 126 generate respective audio/video output signals 128, 130.
  • the host device of Figure 4 operates under the control of a central processing unit (CPU) 132 which in turn may be a programmable processor device operating according to software or firmware stored in a memory 134 (which may in turn be a non-transitory machine- readable memory such as a magnetic or optical disk store or a non-volatile semiconductor memory).
  • CPU central processing unit
  • memory 134 which may in turn be a non-transitory machine- readable memory such as a magnetic or optical disk store or a non-volatile semiconductor memory.
  • Figure 5 schematically illustrates a multiplexer-demultiplexer arrangement forming part of the functionality of the CI controller 112 of Figure 4.
  • a multiplexer 140 At least respective portions of the packetized data signals from the demodulators 108, 110 are combined by a multiplexer 140 into a composite packetized data signal to be passed to the set of one or more CAMs 1 14, and a decoded version of the composite packetized data signal is received by a demultiplexer 142 which demultiplexes it into the respective signals 1 16, 118 for decoding.
  • a demultiplexer 142 demultiplexes it into the respective signals 1 16, 118 for decoding.
  • the packetized data signals output by the two demodulators 108, 110 may represent so- called transport streams (TS) and would normally include data packets relating to several audio/video programme services along with various housekeeping and control packets.
  • a single packetized data signal may include packets relating to between 3 and 10 programme services, although the choice of how many programme services are represented by an individual TS is as much a commercial choice as a technical choice; a TS provides a certain amount of data bandwidth, but it is then a commercial choice by the broadcaster as to how many programme services should be fitted within that available bandwidth.
  • each programme service In order to encode a higher number of programme services within a given bandwidth, the coding quality (which relates to the output quality of the reproduced audio and video signals as experienced by a viewer) of each programme service must be lowered. But in any event, it is likely in normal use that each one of the packetized data signals generated by one of the demodulators 108, 1 10 will contain packets of data other than those required to decode a particular desired programme service. A technical choice then arises, in that it is possible, at least in principle, for the CI controller 1 12 simply to combine the multiple packetized data signals output by the demodulators 108, 1 10 such that all of the information contained in each packetized data signal is retained.
  • a respective subset of data packets is extracted from each of the packetized data signals output by the demodulators 108, 110, and the composite packetized data signal to be supplied to the set of one or more CAMs 114 is formed from a combination of these respective subsets. Techniques for forming this combination in order to generate the composite packetized data signal will be discussed further below.
  • Figure 6a schematically illustrates a so-called M (multi-stream) card 150
  • Figure 6b schematically illustrates a so- called S (single stream) card 160.
  • the M card 150 is a single unit capable of concurrently decrypting more than one encrypted programme service. This represents a more modern implementation of the CAM system than the S card, which is more of a legacy device capable of decrypting only one programme service from a TS. Note that an M card can operate in either a multi-stream or a single stream (S card) mode. An S card can operate only in a single stream mode.
  • FIG. 7 schematically illustrates a transport stream (TS) packet 170.
  • the packets comprise a 4-byte header portion 172 and a 184-byte payload portion 174.
  • This is a standard format for TS packets, and a TS is formed of a succession of packets of this form.
  • the header portion 172 includes a packet identifier or PID.
  • Each audio/video programme service has an associated set of two or more PIDs. For example, one PID may be associated with video packets of a programme service, another PID may be associated with audio packets of the programme service and a further PID may be associated with encryption control packets of the service. Therefore, within a single TS, many different PIDs may be in use.
  • the allocation of PIDs to different types of packets is handled by a programme allocation table (PAT) and a programme map table (PMT).
  • the PAT itself has a PID of 0 and functions so as to indicate the PID of the packets carrying the PMT.
  • the PMT indicates the PIDs of packets carrying video and audio data as well as the PID of packets carrying the ECM data for a service.
  • a conditional access table (CAT) has a PID of 1 and indicates which packets carry the EMM data for one or more access control systems.
  • the PI Ds are uniquely defined within a single TS, in a 13 bit range (0 to 8191 in decimal). However, from TS to TS, the data represented by a particular PID value may be ambiguous. That is to say, PI D values may be reused across different TSs. In the case that multiple TSs are multiplexed together by the multiplexer 140, a mechanism is needed to overcome this potential ambiguity in the allocation of PID
  • packets representing desired services are extracted from multiple input TSs, and the PIDs for packets extracted from at least one of the TSs are re-mapped to new PID values which are not used in respect of any data extracted from the other TS.
  • the re-mapping process involves replacing a PID value with another PID value, with a record or a re-mapping table being maintained so that the desired service can be identified from the new (re-mapped) PID values.
  • This arrangement can be used to generate a pseudo-TS, which is to say an artificially produced TS, present only within the host device, but which appears (from the point of view of an S card) to fulfil all the format requirements of a broadcast TS. That is to say, the pseudo-TS can be decoded by an S card as though it had been broadcast in that form, even though it is in fact generated within the host device by combining parts of multiple broadcast TSs.
  • a pseudo-TS which is to say an artificially produced TS, present only within the host device, but which appears (from the point of view of an S card) to fulfil all the format requirements of a broadcast TS. That is to say, the pseudo-TS can be decoded by an S card as though it had been broadcast in that form, even though it is in fact generated within the host device by combining parts of multiple broadcast TSs.
  • Another technique is to use a pre-header which is inserted at the beginning of each TS packet and which provides further information as to the origin of that packet. This technique is used when sending data to M cards operating in multi-stream mode.
  • An example of a TS packet with a pre-header 176 is shown schematically in Figure 8.
  • the pre-header 176 comprises 12 bytes of additional data and is pre-pended by the host to each packet sent to an M card. That is to say, it is added before the beginning of each packet.
  • the 12 bytes of additional data comprise various fields including a local transport stream identifier, which identifies the TS from which the packets was derived, a local timestamp, error detecting data for detecting errors within the pre-header, and reserved data fields for later or proprietary use.
  • the local transport stream identifier means that even in the situation where packets in a composite packetized data stream have conflicting PID values, they can still be distinguished by their local transport stream identifier value in the pre-header.
  • the multiplexer 140 combines packets taken from multiple TSs into a composite packetized data stream suitable for use by an M card, pre-pending the additional pre-header to each such packet in dependence upon at least the identity of the TS from which that packet originated.
  • Figure 9 schematically illustrates a multiplexer arrangement in more detail. The multiplexer arrangement of Figure 9 is relevant to an arrangement in which a pseudo-TS is generated for decoding by S cards and by M cards operating in single-stream mode.
  • Each input transport stream is passed to a respective PID selector 180, 182 which refers to the programme allocation table 184, 186 associated with that TS and to data 188, 190 defining a required programme service, to establish the PIDs which are required to be passed for decoding (of a required programme service) as part of the composite packetized data signal.
  • the selectors 180, 182 are operable to do one or more of the following: to select data packets from the packetized data stream for a required programme according to the set of packet identifiers defined by the identification data for that stream in respect of the required programme;
  • the data 188, 190 defining a required programme service may be provided by the CPU 132, for example, possibly in response to a user control of a remote commander (not shown) or other user interface control (not shown), or possibly in response to a machine control, for example from a video recording device operating in a timer mode and requiring a certain programme service to be received during a pre-set time interval for recording.
  • a unit 192, 194 for each TS discards "unwanted" packets, that is to say, packets which do not have PIDs defined by the selection made and the selectors 180, 182.
  • a PID re-mapper 196, 198 is used to re-map the PIDs of one of the TSs to new PID values so as to avoid any potential overlap with PID values of the other TS. Note that remapping need not take place in instances where there is no overlap (multiple use) of PIDs as between the different TSs, although in embodiments, all of the PIDs of at least the selected packets of the secondary TSs can be remapped to different respective PIDs.
  • the re-mapping operation does not need to be carried out in respect of both TSs (or, if more than two are under consideration, each TS), and indeed in embodiments one of the TSs is treated as a so-called "primary" TS for which PID re-mapping does not take place.
  • a re-mapper 196, 198 as provided in respect of each TS for possible use when required. Note also that only those PIDs which exhibit a conflict (the same PID number as a PID form another TS) need to be re-mapped, although other PIDs may be re-mapped as well.
  • PIDs from one or more "secondary" TSs are candidates for re-mapping, but PIDs from a primary TS are not candidates for re-mapping.
  • the selectors 180 can be arranged to include in their selection so-called programme clock reference packets so that these packets are included within the composite packetized data stream.
  • PCR data are used to provide timing information for the decoding of audio and video data within a TS.
  • the PCR data are relatively small and in fact are included within TS packets in a so-called adaptation field.
  • the adaptation field is positioned within the 184 byte payload 174 ( Figure 7) but in terms of function, acts more like an extension (into the payload area 174) of the header.
  • the header carries a flag indicator (such as a one bit flag).
  • the selectors 180 can detect a packet that carries PCR data by first checking the "is an adaptation field present" flag in the packet header, and then checking the "does the adaptation field carry PCR data" flag associated with the adaptation field.
  • the timing information indicated by the PCR data is generally common across all programme services in a TS. It is used by the decoders so that content decoding takes place according to the PCR packets and the PIDs relating to the required service. So, there is generally a need only to provide one set of PCR data within a TS. It is common in the art for the PCR data for a TS to be carried by adaptation fields in packets relating to an arbitrary one of the programme services. The PI D of the packets carrying the PCR data for a TS may be indicated in a field PCR_PID in the PMT.
  • a whole TS is passed to a CAM for decryption (as in a single tuner: single CAM arrangement, or an arrangement with a dedicated CAM for each tuner or TS source)
  • the fact that the PCR data may be in packets relating to a programme service other than the currently viewed or decoded programme service is not a problem, because the PCR data will still be available to the CAM and then to the decoder.
  • a composite packetized data stream is formed as a combination of subsets of multiple input TSs, with each subset relating to a required programme service, there may be situations in which the PCR data for a programme service is missing, because it is carried by packets relating to a programme service other than the selected programme service for that TS.
  • the selectors 180 can examine the so-called adaptation field of each packet and (if an adaptation field is present) the PCR data flag, so that if the packet is a packet containing programme clock reference data then the packet is selected whether or not it relates to a selected programme service.
  • the packet containing PCR data is included within the selection and so included within the composite packetized data stream.
  • the selected and, where appropriate, re-mapped packets are then combined into a single composite data stream by a combiner 200. For example, this may be by a process of concatenation, which in general terms simply means putting side by side (one after another) in the composite data stream. It does not necessarily imply that the packets are directly adjacent (there could be gaps), nor does it necessarily imply any particular packet order.
  • PCR data may therefore contain multiple sources of PCR data.
  • the decoder in respect of each programme service will be able to access the correct PCR data. If the PCR data is included within packets of the programme service to be decoded, then the decoder will use that PCR data. If the PCR data in the original TS was included in packets relating to another programme service, then these packets will be included in the composite packetized data stream by the mechanism described above.
  • the PCR_PID data (as re- mapped if necessary) is carried for each programme service in the composite packetized data stream.
  • a set of data from the PAT and/or PMT is carried into the composite packetized data stream as composite stream identification data (an example being illustrated in Figure 14) in respect of each selected programme service, for example to indicate the PIDs of packets in the composite stream containing audio, video and CA data, as well as to indicate the PCR_PID.
  • the receiving step comprises receiving two or more packetized data streams; the selecting steps discussed above are applied to each packetized data stream from which a programme is selected; the composite packetized data stream comprises programme data from two or more of the packetized data streams; and generating the composite packetized data stream comprises concatenating the selected packets to form the composite packetized data stream.
  • Figure 10 schematically illustrates TS packets 205 of two programme services, service 1 and service 2, combined into a single composite packetized data stream.
  • FIG 11 schematically illustrates a succession of CAMs, forming an example of the set of CAMs 114 discussed above.
  • the CAMs are arranged in series, as a so-called daisy chain, so that the composite packetized data stream from the CI controller 1 12 is supplied as an input 210 to a first CAM 212 in the series, and is routed from the first CAM 212 to a second CAM 214, from where it is passed to a third CAM 216 before being returned, with the required services decrypted on the basis of the packet identifiers passed with or as part of the composite data stream identification data, to the CI controller 1 12.
  • the CAMs in the daisy chain can be arranged to provide decryption of different conditional access services, so that whichever service (within the range of services and CA systems handled by the set 1 14) is selected for decryption by user or machine control, one of the set of CAMs 1 14 is capable of decrypting it.
  • a technique by which the host can select the appropriate CAM for a particular programme service to be decrypted will be described below with reference to Figure 15.
  • the content decoder when formed as a set of CAMs or a M card CAM is capable of concurrently decoding two or more audio/video programmes from a single packetized data stream; and in such cases the step of generating the composite packetized data stream comprises forming the composite packetized data stream from packets representing two or more programmes.
  • Audio, video and some control data can be passed to the CAMs as part of the composite packetized bit stream supplied at the input 210 and passed from CAM to CAM.
  • An additional, much lower data rate, control interface 218 is provided between the CI controller and each CAM. Control signals to be discussed below can be multiplexed into the composite packetized data stream or carried by the control interface.
  • CAM In general terms, only one CAM acts to decrypt a particular programme service, and the CAM cannot decrypt a programme service unless it receives an instruction from the host to do so.
  • the arrangement of Figure 11 can be operated when all of the CAMs in the daisy chain arrangement are S cards (or M cards operating in single-stream mode), or when all of the CAMs in the daisy chain arrangement are M cards, because in either case the data format for the composite packetized data stream is the same across the whole of the daisy chain arrangement of CAMs.
  • Figure 12 schematically illustrates a succession of CAMs 220, 222, 224 with interface units 226, 228 between them.
  • a composite packetized data signal 230 received from the CI controller 1 12 is in the M card format, which is to say it includes the additional pre-header discussed above.
  • This signal is handled in a conventional way by the M card 220 but instead of being passed directly to the next card 222 in the daisy chain arrangement, it is instead passed to the interface unit 226 where the additional header information relating to the pre-header is stripped off the packets and, if necessary, PID values are re-mapped, before the composite packetized data stream is passed to the S card 222.
  • the interface unit 226 retains the stripped data and any PID re-mapping data relating to the original composite packetized data stream, and passes this retained information to the interface unit 228 which receives the output data stream from the S card 222.
  • the interface unit 228 re-inserts the pre-header onto each packet and performs an inverse PID re-mapping process to return the PID values to their original form.
  • the output data stream from the interface unit 228 is then passed to the M card 224 in order to be processed.
  • Figure 13 is a schematic flowchart illustrating the handling of so-called ghost PIDs.
  • Ghost PI Ds relate to so-called ghost packets in an MPEG transport stream.
  • ghost packets may be used by contributors to the broadcast system such as host device manufacturers, receiver manufacturers, broadcasters, CA system vendors and so on to provide confidential control information (as a "private data" field, for example) to various parts of the host device and in particular the CAM or CAMs in use at a host device.
  • the ghost packets may include a firmware update for a CAM device, which in turn represents data which the CA vendor or the CAM manufacturer would normally prefer to keep away from potential hackers.
  • packets containing such data may be transmitted using PIDs which are derivable by the CAM according to (for example) a predetermined algorithm based on the current time or other conditions, but which are not indicated as part of any of the allocation tables forming part of that TS.
  • the ghost packets are potentially important for use by the CAM devices, but as they are not included within any of the allocation tables then unless specific action is taken to avoid this, they may in fact be discarded by the units 192, 194 in Figure 9 and may not be present in a composite packetized data stream which is actually supplied to the CAM.
  • the selectors 180, 182 select the PIDs for the required programme services. This represents a mode of operation corresponding to that already described with reference to Figure 9.
  • the selectors also select (for inclusion in the composite packetized data stream) all PIDs which are not specified by the identification data (PMT, PAT or CAT) for that TS. So, at this stage, the selectors do not know what technical meaning may be attached to the ghost PIDs, but they are selecting all PIDs which are present in the TS and which do not specifically correspond to programme services other than the required programme service.
  • a step 254 represents the re- mapping operation carried out by the re-mappers 196, 198, but noting that the re-mapping operation refers not only to the PIDs for the selected service but also to the ghost PIDs selected at the step 252.
  • the re-mapping data which is to say, the relationship between the PIDs before re-mapping and the PIDs after re-mapping (an example being shown in Figure 14) is sent to the set of CAMs 1 14 so that if a CAM within the set requires access to a packet defined by a ghost PID, the CAM may identify that packet within the re-mapped data by referring to the re-mapping information, and decode the identified packet accordingly.
  • the PIDs used to indicate ghost packets can change from time to time. Indeed, this might be part of the security procedure associated with those packets. Also, the ghost packets may not be broadcast very often.
  • the system of Figure 9 when the system of Figure 9 first operates in respect of a particular programme service from a particular TS, it may not be aware of the current set of ghost PI Ds. It may become aware of them by one of two techniques: by the detection (by a selector 180, 182) of a PID in the data stream which is not referenced in any of the reference tables, or by a CAM requesting a particular PID (for example, via the control interface) which the CAM considers it requires but which is not in the composite packetized data stream. The first of these may be considered as a pre-emptive selection, the second as a reactive selection. In either case, the selector 180, 182 can act, in response, to select that PID for inclusion in the composite packetized data stream.
  • FIG 14 schematically illustrates a PID mapping table as an example of the type of remapping information which may be transmitted from the multiplexer 140 to the set of CAMs 114 at the step 256, either as control data or multiplexed into the composite data stream.
  • the PID mapping table refers to an identification 260 of the TS from which the PID was taken, an identification 262 of the programme service derived from that TS, an identification 264 of the "old" PID (before re-mapping) and an identification 266 of the "new" PID (after re-mapping).
  • the PID mapping table may be multiplexed into the composite packetized data stream and/or transmitted to the CAMs by the control interface 218.
  • the table of Figure 14 may act as an example of composite stream identification data.
  • the data of Figure 14 may be used to control the decoding of programmes from the composite packetized data stream by one or more CAMs, according to the packet identifiers in the PID mapping table of Figure 14.
  • the PID mapping table may change in time, so it is either repeatedly transmitted to the CAMs by the CI controller or is at least re-transmitted in response to a change in the mapping.
  • One reason that the re-mapping may change is that a newly identified ghost packet has a PI D which corresponds to another PID in the composite packetized data stream, leading to a requirement to re-map one or both of them.
  • Figure 15 schematically illustrates operations involved in detecting which CAM of a succession of CAMs is capable of decoding the required programme service.
  • FIG 15 represent an interaction or handshake between the host and each CAM in the set of CAMs 1 14. Operations relating to only one CAM of the set will be described, but it will be understood that corresponding operations would be carried out in respect of other ones of the set.
  • a step 300 is carried out when the system starts up or boots, in that each CAM sends data (a so-called CA_SYS_ID) to identify the type of CA system(s) which that CAM is capable of decrypting, subject to receiving the appropriate ECM/EMM data for the service.
  • CA_SYS_ID data
  • ECM/EMM data for the service.
  • a step 310 takes place when a new programme service is selected for decryption, for example by operation of the user control or under the control of a timed recording device, or when the CA parameters associated with a programme service change (for example, from “clear” to "encrypted” or the other way around).
  • the host sends an identification of the PIDs relating to the required programme service to a CAM in the set 1 14.
  • Each CAM detects the ECM and EMM data relating to that service at a step 320 and, at a step 330 detects (with reference to the ECM and EMM data, as well as the CAM'S own capabilities) whether that service is decodable by that CAM.
  • the host might elect to send the PIDs in question only to those CAMs which indicated, at the step 300, a basic capability (in principle) to decode that type of data.
  • the host checks the response from the current CAM which is being queried. If the CAM can decode the programme service then at a step 350 the host allocates a decoding task for that programme service to the currently queried CAM . If not, then if there remains a further CAM which has not yet been queried, then the host returns control to the step 310 to query that next CAM. Otherwise, if no further CAMs remain to be queried, and the process is aborted and, optionally, the user is notified that the required programme service cannot be decrypted by the set of CAMs 1 14 present in the system.
  • Figure 16 schematically illustrates control of multiple tuners 102, 104 by the host device, and in particular example by the CPU 132 of the host device.
  • the left-hand region of the diagram relates to operations carried out at the host, and the right-hand region relates to operations carried out at a CAM of the set 1 14.
  • This process introduces the concept of a "primary” and a “secondary” tuner, though this may be considered as being equivalent to a designation of a "primary” and a “secondary” TS, since there is a one-to-one correspondence in the present embodiments between the operation of a tuner and the reception of a TS, or in other words, each tuner receives a single TS in the present embodiments.
  • a default position is established such that the tuner 102 (tuner A) and the TS received by the tuner 102 are designated as "primary”, and the tuner 104 (tuner B) and the TS received by the tuner 104 are designated as "secondary". It is noted that in a normal mode of operation, only one tuner is required to watch so-called "live" television; one function of having another tuner is that a second service can be recorded while a first service is being watched live. Alternatively, the first of the tuners or TSs to be initially required for use can form the initial definition of the primary TS or tuner.
  • the CPU 132 detects whether the secondary tuner (TS) is in use, for example to record a programme service for later viewing. If the secondary tuner is not in use, then at a step 364 the CPU 132 or the CI controller communicates the availability of the secondary tuner to the set of CAMs 1 14, in response to which one of the set may elect to use the secondary tuner for non-viewing reception of non-viewing information at a step 366. In other words, if the tuner is not currently in use in respect of providing a programme for decoding, it is considered available for the purpose of accessing (for example, tuning to) a channel carrying non-viewing information.
  • TS secondary tuner
  • non-viewing reception may relates to the reception, by a CAM, of non- viewing information such as control information for a CAM, housekeeping data, firmware or software updates or the like, which may require the exclusive use by that CAM or a tuner for a period of time.
  • a CAM can, pre-emptively or under instruction from the head end, cause the reception of data to be stored on, for example, a hard disk recorder, relating to video programmes which the user might wish to watch. Accordingly, for this purpose the CAM may act as a store controller for controlling storageof the non-viewing information for later access.
  • the received data could relate to the whole programme or could relate to a trailer or advertisement for the programme, or could provide enough buffer data to allow an instant initiation of replay (at the user's command) even when the programme is being streamed.
  • Reception of this type of data is not specifically requested or instructed by the user; it is received at the initiation of the CAM or another part of the system as a background process, and is considered as "non-viewing data" or “non-viewing information” because (a) it is often transmitted at a data rate lower than a decoding or viewing data rate, and (b) the user must generally take other steps (such as requesting access to the data on a hard disk recorder) before even a viewable portion may be viewed, it may be decoded by a CAM acting as a non- viewing information decoder.
  • Non-viewing information may be carried by at least one TS.
  • any further instances of the step 362 will show that the secondary tuner is in use.
  • the user requires use of the secondary tuner, for example to record a programme service, then use by the CAM for non-viewing background reception can be cancelled. This can take place in such a way that the user need not know that the CAM was ever making use of the secondary tuner.
  • the PIDs for the programme service to be received by the secondary tuner are selected. This corresponds to the steps 250 and 252 in Figure 13.
  • the PIDs for the secondary TS are re-mapped (corresponding to the step 254 in Figure 13) and the packets corresponding to the selected PIDs for the primary and secondary tuners are multiplexed together to form the composite packetized data signal. Note that as discussed above, it is necessary only to re-map a PID if a collision or conflict with another PID (from another TS) has occurred.
  • the system may re-map all PIDs of those packets selected from the secondary TS, or may just re-map those exhibiting a conflict of PID number. But a significant feature is that the secondary TS defines a TS having PIDs which are at least candidates for re-mapping, if re-mapping proves necessary. PIDs in the primary TS are not remapped; they retain their original values (as received).
  • a channel change may be initiated by user operation of a user control or by machine operation of a channel control, for example by a timed recording process requiring access to a particular programme service.
  • the operations in response to the detection of a channel change vary according to whether it is the secondary or the primary tuner which is being changed.
  • control returns to the step 362, but no changes are made to the designation of primary and secondary.
  • the previous primary is now treated as a secondary, and so is subject to a re-mapping process in respect of its PIDs at the step 370, or at least its PI Ds become candidates for re-mapping.
  • the change from primary to secondary is, in embodiments, carried out straight away, but the change from secondary to primary can be deferred until a detection that a secondary TS is to be retuned when no primary currently exists, in which case the change is applied to that secondary TS. Note that this feature applies whether there are two tuners or more than two tuners.
  • a channel change by the primary tuner could require a new re-mapping operation by the secondary tuner. This is because the remapping carried out in respect of the secondary TS's PIDs is performed in order to avoid any conflict between the primary tuner's PIDs and the re-mapped secondary tuner's PIDs. If there were no change in designation of primary and secondary, then a change in the programme service for the primary tuner could lead to a conflict of PIDs and so a further need to re-map the secondary PIDs, even though no channel change was being executed at the secondary. Accordingly, in the absence of the present technique, a channel change at the primary tuner could result in a temporary interruption in service for the programme received by the secondary tuner, which would in turn be subjectively disturbing for the user.
  • the step 374 can be discussed further as follows.
  • the primary In response to a detection that the channel or TS received by the primary is being changed (or in other words that the primary is to be used for reception of a different programme), the primary can be redesignated as a secondary and the previous secondary as primary.
  • this does not imply that the remapping operation carried out at the step 370 in respect of the previous secondary (now the primary) needs to be undone, and in fact this would be undesirable as it would cause a potential interruption in received service by that tuner.
  • it does mean that there is no need to do any re-mapping of the newly-designated primary's PIDs to avoid a conflict with the previous primary (now secondary) PIDs after retuning.
  • a secondary tuner is redesignated to become the primary.
  • Figure 17 schematically illustrates the multiplexing of two separate programme services.
  • a mechanism has been provided to amalgamate selected packets from two or more TSs into a single composite packetized data stream.
  • the packets can be multiplexed together in the right order, which is to say for any individual received TS, the packets appropriate to the required programme service for decoding will appear in the composite packetized data stream in the correct order relative to one another.
  • the mechanism does not necessarily guarantee that the multiplexed packets appeared in the concert packetized data stream at the correct time positions.
  • Figure 17 is a schematic illustration of an example of this potential problem.
  • a subset of packets is selected from each of two transport streams, TS1 and TS2.
  • the selected subset of packets are those packets which are drawn along a time axis running from left to right in the diagram. Unselected packets are simply not illustrated, to assist in the clarity of the diagram. As an example of a timing clash, it can be seen that a packet 400 from TS1 overlaps in time with a packet 402 from TS2.
  • a third row of Figure 17 (labelled “to/from module") schematically represents the composite packetized data stream. It will be seen that the packet 400 has substantially retained its original time position, but the packet 402 has been delayed in order to occur, in the composite packetized data stream, after the packet 400.
  • Fourth and fifth rows of Figure 17 represent the individual packetized data stream is which are reconstructed after decrypting by the set of CAMs 1 14 and demultiplexing. Again, it will be seen that the decrypted packet 400' has retained its original time position, where is the decrypted version of the packet 402 (the decrypted packet 402') has undergone a time shift by a shift amount 404. A similar time shift 406 applies to a later packet in TS2.
  • Figure 18 schematically illustrates a packet 410 (which may or may not include a pre-pended header as described above) which also includes an augmented packet header 412 including at least a packet arrival time which represents a timestamp allocated to each TS packet coming from the respective demodulator, or in other words is related to a time at which the composite stream is generated.
  • Figure 19 schematically illustrates a packet timing data table which stores similar data, though not in the form of a packet header, allowing the original timing of the TS packets to be regenerated at the final decoder stage.
  • the table may be passed to the CAMs via the control interface or, for example, as DVB private data or as a data table.
  • Such data can be transmitted as a private data packet adjacent in the composite stream to the packet to which it refers. This links the data to the respective packet.
  • the packet timing data table comprises five data fields for each TS packet. These are: a sequence number 420 assigned by the host as part of a sequence to each incoming TS packet in a transport stream, a PID value 422 taken from the packet's header, a packet arrival time 424 which represents a timestamp allocated by the host or the CI controller to each TS packet coming from its respective demodulator, a "sent" flag 426 indicating whether the TS packet has been sent to the set of CAMs 1 14 for decryption, and a "received” flag 428 indicating whether the packet has been received back from the set of CAMs after decryption.
  • the CI controller can insert the decrypted packets received back from the set of CAMs 1 14 at their original time positions according to the packet arrival times stored in the table.
  • the CI controller can insert the decrypted packets received back from the set of CAMs 1 14 at their original time positions according to the packet arrival times stored in the table.
  • the relative timings of all the packets in the reconstructed TS can be made correct by use of the arrival time data stored in the packet timing data table.
  • Figure 20 schematically illustrates the generation of the packet of Figure 18, and Figure 21 schematically illustrates the use of the packet of Figure 18.
  • the CI controller detects a current time when a TS packet arrives at the CI controller, and adds at least the arrival time data to the augmented header 412 at a step 432.
  • the CI controller detects the timing information previously inserted into the augmented header 412 at a step 434 and at a step 436 either generates control information to control the decoding of that packet at the correct time or reinserts the packet back into a reconstituted TS at the correct time (or, as described above, at least at the correct relative time with respect to other packets in the reconstituted TS).
  • Figure 22 schematically illustrates the generation of the table of Figure 19 and Figure 23 schematically illustrates the use of the table of Figure 19.
  • the CI controller detects the arrival time of a TS packet from its respective demodulator, and at a step 442 stores that arrival time as part of a table such as the table shown in Figure 19, along with a sequence number and the PID extracted from the packet's header. If the CI controller is sending that packet for decryption, the CI controller sets the "sent" flag 426 to indicate that this has taken place.
  • the CI controller sets the "received" flag 428 in the table at a step 444, and then, at a step 446 accesses timing information from the arrival time field 424 in the table, using the PID 422 and the sequence number 420 to index the data for the correct packet.
  • the CI controller either controls the decoding process for that packet to be carried out at the correct time or controls the reinsertion of the packet into a reconstituted TS at the correct time or at least the correct relative time with respect to other packets in that reconstituted TS.
  • Shunning data is included within the so-called service description table (SDT) within broadcast data, as an example of service data including security authorisation information for hosts (content receivers).
  • SDT service description table
  • Shunning allows a host to be instructed not to use a pirate or otherwise unauthorised CAM, or to receive and decrypt certain services.
  • the unauthorised module or services are defined within the service description table data. Accordingly, shunning imposes a requirement on a host not to use a CAM.
  • Revocation involves a head end telling a host to pass data to a CAM instructing that module not to interact with a particular manufacturer's model number as a host. Again, this can be used in situations where the security of a particular model has been compromised, in order to protect the integrity of the overall conditional access system. So, revocation imposes a requirement on a CAM not to provide decryption services to a host. Revocation data is signalled by an entry in the EMM telling the CAM where to find a revocation signalling data (RSD) file in the Clplus data carousel.
  • RSS revocation signalling data
  • the host executes a detection, based on the SDT data, as to whether the host is authorised to decode the received programme data.
  • the host may optionally signal the incident to the user, for example by an on-screen display (not shown).
  • Revocation data is generally signed by an operator certificate which in turn is signed by a root certificate, and so the precautions to be described below are more relevant to shunning data than to revocation data.
  • the integrity of the shunning and/or revocation data can be substantially guaranteed by the tuner bypassing the CAM module, checking the SDT data for any shunning or revocation data relevant to the current host and/or CAM, and passing the shunning all revocation data to the CAM for action.
  • These measures can avoid the CAM manipulating the data in the TS before that data is checked by the host. (This is a risk in a situation where the security of the CAM has been compromised).
  • Figure 24 schematically illustrates an arrangement which can at least alleviate this problem in the context of, for example, the host device of Figure 4.
  • the multiplexed (composite) data stream generated by the CI controller 1 12 is digitally signed by a signing unit 460 using a secret cryptographic key.
  • the digitally signed multiplexed data stream is then passed to the set of CAMs 1 14 acting as a content decoder for decoding two or more programmes from the composite packetized data stream according to the PIDs in the stream identification data.
  • the signature is checked by a signature checker 462 (which checks the validity of the signature) before the data is passed back to the demultiplexer 142.
  • a key may be unique to the receiver, for example being stored in a secure manner in the receiver at manufacture.
  • This digital signature is an example of a digital security indicator.
  • the secret key may be communicated between the signing unit 460 and the checking unit 462 by a secure data link 464.
  • the public-private key pair may be different from host to host to increase the potential integrity of the checking system.
  • the digital signature can be applied to the entire packetized composite data stream or just to the SDT data within the data stream. So, in embodiments, the digital signature is applied to at least the SDT data included in the multiplexed stream.
  • the digital signature can be inserted into the data stream or can be communicated separately between the units 460 and 462.
  • the host finds that the digital signature has been corrupted, it can carry out various different actions. It can indicate the fact to the user, for example as an on-screen display. It can enable and disable each CAM in turn, using the control interface 218, to detect which CAM is causing the corruption, and then permanently or semi-permanently disable that CAM. In any event, the CIplus specification indicates that the host is not allowed to present content decrypted by a corrupt or shunned CAM to the screen for viewing by a user, or for recording by a user.
  • Embodiments also include a data signal, being a signal within the apparatus as described, in particular (though not exclusively) a signal as passed from the host to the CAM or set of CAMs, or the return signal.
  • a storage medium such as a memory by which such a signal is stored is also considered as an embodiment.
  • the storage medium may be, for example, a non-transitory machine-readable storage medium.
  • an example of such a signal is an audio/video data signal comprising a composite packetized data stream having programme data from two or more packetized data streams, having a subset of data packets from the two or more received packetized data streams, the subset including those audio/video data packets relating to those programmes to be decoded; and service data including security authorisation information for content receivers, the service data having an applied digital security indicator.
  • Embodiments can provide a method of operation of an audio/video content receiver having a content decoder capable of decoding an audio/video programme from a packetized data stream by using data packets defining decryption information, the method comprising the steps of:
  • Embodiments can provide a method of operation of an audio/video content receiver having a content decoder capable of concurrently decoding two or more audio/video programmes from a single packetized data stream, the method comprising the steps of:
  • each data stream comprising one or more programmes having data packets identified by respective sets of one or more packet identifiers, each packetized data stream comprising identification data mapping programmes to respective sets of the packet identifiers;
  • composite stream identification data defining the packet identifiers of data packets in the composite packetized data stream; decoding two or programmes from the composite packetized data stream according to the packet identifiers in the composite stream identification data;
  • Embodiments can provide a method of operation of an audio/video content receiver having a content decoder capable of concurrently decoding two or more audio/video programmes from a single packetized data stream by using data packets defining decryption information, the method comprising the steps of:
  • each data stream comprising one or more programmes having data packets identified by respective sets of one or more packet identifiers, each packetized data stream comprising identification data mapping programmes to respective sets of the packet identifiers and service data including security authorisation information for content receivers;
  • Embodiments can provide a method of operation of an audio/video content receiver having a content decoder capable of concurrently decoding two or more audio/video programmes from a single packetized data stream of encoded audio/video data packets, the method comprising the steps of:
  • each data stream comprising one or more programmes having respective encoded audio/video data packets;
  • Embodiments can provide an audio/video content receiver for receiving and decoding audio/video data signals modulated onto transmission channels, at least one transmission channel carrying non-viewing information, the receiver comprising:
  • a tuner arrangement capable of concurrently tuning to two or more transmission channels
  • a multiplexer configured to generate a composite data signal from received audio/video signals relating to required programmes for decoding
  • a content decoder capable of concurrently decoding two or more audio/video programmes from the composite data signal
  • a detector configured to detect whether one or more of the transmission channels tuned by the tuner arrangement are not currently in use in respect of providing a programme for decoding
  • a controller responsive to a detection that a transmission channel is not currently in use, for controlling the tuner to tune that channel to a transmission channel carrying non-viewing information
  • Embodiments can provide a method of operation of an audio/video content receiver having a content decoder capable of decoding an audio/video programme from a packetized data stream by using data packets defining decryption information, the method comprising the steps of:
  • receiving encoded audio/video content as a packetized data streams comprising one or more programmes having data packets identified by respective sets of one or more packet identifiers and identification data mapping programmes to respective sets of the packet identifiers;

Landscapes

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

Abstract

Les étapes du procédé selon l'invention de fonctionnement d'un récepteur de contenu audio/vidéo ayant un décodeur de contenu capable de décoder concurremment deux programmes audio/vidéo ou plus à partir d'un seul flux de données en paquets en utilisant des paquets de données définissant des informations de déchiffrage consistent : à recevoir du contenu audio/vidéo codé sous la forme de deux flux de données en paquets ou plus, chaque flux de données comprenant un ou plusieurs programmes ayant des paquets de données identifiés par des ensembles respectifs d'un ou plusieurs identifiants de paquets, chaque flux de données en paquet comprenant des programmes de mappage de données d'identification associés aux ensembles respectifs des identifiants de paquets et des données de service incluant les informations d'autorisation de sécurité pour les récepteurs de contenu ; à générer un flux de données en paquets composite ayant des données de programme et les données de service provenant de deux des flux de données en paquets ou plus ; à appliquer un indicateur de sécurité numérique au moins aux données de service incluses dans le flux de données en paquets composite ; à fournir le flux de données en paquets composite au décodeur de contenu afin de décoder deux programmes ou plus à partir du flux de données en paquets composite en fonction des identifiants de paquets dans les données d'identification de flux composite ; à recevoir les données de service du décodeur de contenu ; à détecter la validité de l'indicateur de sécurité numérique appliqué aux données de service ; et en réponse aux données de service, à détecter si le récepteur de contenu est autorisé à décoder les données de programme reçues.
EP13725729.1A 2012-03-26 2013-03-20 Recevoir du contenu audio/vidéo Withdrawn EP2832105A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1205291.6A GB2500612A (en) 2012-03-26 2012-03-26 Receiving and Selectively Decoding Received Audio/Video Content According to a Security Indicator
PCT/GB2013/050730 WO2013144585A1 (fr) 2012-03-26 2013-03-20 Recevoir du contenu audio/vidéo

Publications (1)

Publication Number Publication Date
EP2832105A1 true EP2832105A1 (fr) 2015-02-04

Family

ID=46087132

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13725729.1A Withdrawn EP2832105A1 (fr) 2012-03-26 2013-03-20 Recevoir du contenu audio/vidéo

Country Status (3)

Country Link
EP (1) EP2832105A1 (fr)
GB (1) GB2500612A (fr)
WO (1) WO2013144585A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104661075B (zh) * 2015-02-04 2018-07-03 深圳创维数字技术有限公司 一种数据处理方法及数字电视接收终端

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7058803B2 (en) * 2002-05-22 2006-06-06 Broadcom Corporation System and method for protecting transport stream content
GB2399972A (en) * 2003-03-26 2004-09-29 Sony Uk Ltd Common interface controller and method of descrambling transport stream channels
KR100688089B1 (ko) * 2005-09-27 2007-03-02 한국전자통신연구원 케이블 방송 수신기의 다중화/역다중화 장치
BRPI0807731A2 (pt) * 2007-02-21 2014-06-03 Koninkl Philips Electronics Nv Sistema de acesso condicional
EP2018059A1 (fr) * 2007-07-19 2009-01-21 Panasonic Corporation Récepteur de diffusion vidéo numérique et procédé de décryptage de flux de données numériques
US8385542B2 (en) * 2009-04-27 2013-02-26 Nagrastar L.L.C. Methods and apparatus for securing communications between a decryption device and a television receiver
KR20110028784A (ko) * 2009-09-14 2011-03-22 엘지전자 주식회사 디지털 컨텐츠 처리 방법 및 시스템

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2013144585A1 *

Also Published As

Publication number Publication date
GB2500612A (en) 2013-10-02
GB201205291D0 (en) 2012-05-09
WO2013144585A1 (fr) 2013-10-03

Similar Documents

Publication Publication Date Title
US9973804B2 (en) Conditional access method and apparatus for simultaneously handling multiple television programmes
AU2013372516B2 (en) Receiving audio/video content
US20140375892A1 (en) Receiving audio/video content
US9467736B2 (en) Receiving audio/video content
WO2013144585A1 (fr) Recevoir du contenu audio/vidéo
WO2013144586A1 (fr) Recevoir du contenu audio/vidéo
WO2013143951A1 (fr) Procédé d'accès conditionnel et appareil de gestion simultanée de plusieurs programmes télévisés
WO2013144583A1 (fr) Réception de contenu audio/vidéo
RU2575242C1 (ru) Способ и устройство условного доступа для одновременной обработки нескольких телевизионных программ

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140919

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SATURN LICENSING LLC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180502

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200213