RU2575242C1 - Conditional access method and apparatus for simultaneous handling of multiple television programmes - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: receiving encoded audio/video content in the form of a stream of packet data containing one or more programmes having data packets identified by corresponding sets of one or more packet identifiers, and containing identification data which establish correspondence between programmes and corresponding sets of packet identifiers; selecting data packets form the stream of packet data for the required programme according to the set of packet identifiers, defined by identification data for said stream relative to the required programme; selecting additional data packets from the stream of packet data, from which the programme was selected, containing packet identifiers not included in the identification data for said stream of packet data; generating a composite stream of packet data from the selected packets; generating identification data of the composite stream indicating packet identifiers included in the composite stream of packet data, and transmitting the composite stream of packet data to a content decoder for decoding the programme from the composite stream of packet data according to packet identifiers contained in the identification data of the composite stream.

EFFECT: concealed transmission of certain packets such that the user is not aware, which enables to transmit, to a receiver, data which a potential hacker will find hard to detect and use illegally.

16 cl, 24 dwg

Description

FIELD OF THE INVENTION

The present invention relates to the reception of audio-video content.

Prior art

The description of the "background to the invention" in this specification is intended to represent the general context of the present invention. The work of personally named inventors to the extent that it is described in this section, as well as aspects of the description that cannot be qualified otherwise than the prior art known at the time of application, are not explicitly or implicitly recognized by the prior art in relation to the present invention.

The prior art common interface specification (“CI specification”) (CI, abbreviated from Common Interface) of the DVB standard provided the television receiver or set-top box (“host device”) the ability to interact with a secure hardware module (conditional access module or CAM-module "(CAM, abbreviated from Conditional Access Module)) in order to grant permission to the host device to decrypt content with controlled access. The CI specification defines the interface between the host device and the CAM module so that both devices work together if they meet the CI specification. Such interoperability provided a significant advantage of CI systems, as in principle, it provided consumers the opportunity to choose compatible products from different manufacturers.

In the CI specification, the CAM module interacts with a smart card and / or a user's personal identification number in order to authenticate the user.

However, the drawback of the original CI specification is that it potentially makes it possible to copy decrypted content. This possibility stems from the way the host device and the CAM module interact. During operation, the host device sends encrypted data to the CAM module. The CAM module verifies user authentication and, assuming that the user is authenticated, decrypts content with controlled access. The CAM module then sends the decrypted content back to the host device via an interface, which is usually a PCMCIA interface (PCMCIA, abbreviated from Personal Computer Memory Card International Association, although not limited to this type of interface, for example, a USB interface may be used. Such a connection of the CAM module with the host device is a security weakness in the sense that decrypted digital content can in principle be intercepted and illegally copied. From a security point of view, this weakness led some providers to use integrated devices in which the host device and the CAM module were combined into a single device, as this made it possible to provide a higher degree of security when transferring decrypted data from the CAM module to the host device. However, this, of course, negated the advantage of the CI interface associated with the potential interoperability of various CAM modules and host devices.

To solve this problem, the CI Plus specification was proposed, which provides two main directions for solving the problem. CI Plus technology provides a secure interface between the CAM module and the host device, so that decrypted content is not sent in its pure form between the two devices. Also, CI Plus technology provides authentication of both the host device and the CAM module, unlike CI technology, which provides authentication of only the CAM module.

The authentication system uses a hierarchy of certificates, so the host device and the CAM module must have certificates issued by an authority (such as the CI Plus Limited Partnership).

The PCMCIA interface between the host and the CAM module is protected by encrypting the decrypted content before transferring it from the CAM module to the host device and then decrypting it in the host device. Such encryption is not associated with encryption-decryption in access control by the content provider, and is specific for each pair of CAM-module-host device. Key exchange between the CAM module and the host device is carried out using the Diffie-Hellman key exchange technology. The keys change from time to time, so even if the key has been declassified, it will in any case be changed a few seconds later.

The CI Plus specification allows CAM modules to be connected in series or in circuit.

Disclosure of invention

This description describes the method defined in paragraph 1 of the claims.

Various further relevant aspects and features of the method are defined in the appended claims.

The preceding paragraphs are provided as general information and do not imply any limitation on the scope of the following claims. The described embodiments of the invention, together with other advantages, are better understood from the following detailed description, followed by the accompanying drawings.

Brief Description of the Drawings

A more complete understanding of the invention and many of its inherent advantages follows from the following detailed description of specific embodiments with reference to the accompanying drawings, which show:

in FIG. 1 is a schematic view of a host device with a CAM module and a smart card;

in FIG. 2 is a block diagram of a conditional access system including the one shown in FIG. 1 host device

in FIG. 3 is a flowchart illustrating the operation of FIG. 1 system;

in FIG. 4 is a block diagram of a host device with multiple tuners;

in FIG. 5 is a schematic view of a multiplexing-demultiplexing device;

in FIG. 6a is a schematic view of the so-called M-cards;

in FIG. 6b is a schematic view of the so-called S-cards;

in FIG. 7 is a schematic view of a packet of a transport stream;

in FIG. 8 is a schematic view of a data packet of a composite packet data stream;

in FIG. 9 is a more detailed schematic view of a multiplexing device;

in FIG. 10 is a schematic view of packets of a transport stream of two services;

in FIG. 11 is a schematic view of a kit containing a sequence of CAM modules;

in FIG. 12 is a schematic view of a sequence of CAM modules with interfaces between them;

in FIG. 13 is a flowchart illustrating the processing of so-called ghost packet identifiers;

in FIG. 14 is a correspondence table of packet identifiers;

in FIG. 15 is a flowchart of identifying which of the CAM modules is capable of decrypting a desired software service;

in FIG. 16 is a flowchart of a host device controlling multiple tuners;

in FIG. 17 is a schematic representation of the multiplexing process of two separate software services;

in FIG. 18 is a schematic view of an extended header packet;

in FIG. 19 is a schematic view of a table with clock information of packets;

in FIG. 20 is a flowchart of the header generation shown in FIG. 18 packages;

in FIG. 21 is a flowchart of the use shown in FIG. 18 packet headers;

in FIG. 22 is a flowchart of the formation shown in FIG. 19 tables;

in FIG. 23 is a flowchart of the use shown in FIG. 19 tables, and

in FIG. 24 is a schematic view of a system for setting and verifying a digital signature.

The implementation of the invention

In order to form a technical context for the subsequent consideration of the present embodiments of the invention, first with reference to FIG. 1-3, a broadcast system having one tuner and a decryption device is described.

In FIG. 1, the host device 10 is shown in this case in the form of a TV, but can be, for example, a set-top box (bearing in mind that “a device designed to be placed on top of a TV” does not mean for a person skilled in the art the specific physical position of the device during its operation). The host device receives a television signal 15 with controlled access via a broadcast data channel. This may be, for example, a satellite television signal received by a satellite dish not shown in the drawing, a terrestrial television signal, a cable television signal, and the like, although other types of television signal include broadcasting or transmitting a television signal using an EP packet signal (IP signal). One technology is to encode an MPEG transport stream into IP packets, so that an IP packet carries several (for example, 7-8) packets of a transport stream. Another technology encrypts a television signal in the so-called The International Organization for Standardization (ISO) main media file format BMFF (short for Base Media File Format) described in the link: http://en.wikipedia.org/wiki/ISO_base_media_file_format, the contents of which are incorporated into this description by reference . In this case, the IP interface in the host device is usually regarded as a “tuner”, even if it may not have radio frequency circuits or functions. However, it acts like an RF tuner in the sense that it selects an IP stream from the many possible IP streams. It may also provide buffering of the received IP stream.

Said host device 10 has a PCMCIA connector 20 including electrical connections and physical space for a plug-in module, both of which comply with the PCMCIA standard. In other embodiments, a universal serial data bus (USB) or other electrical interface may be used in place of the PCMCIA interface.

The CI Plus conditional access module, called the CICAM module 30, is a PCMCIA module that can be inserted into the PCMCIA connector 20. When the CICAM module 30 is fully inserted into the connector 20, electrical connections are established between the contacts on the CICAM module 30 and the interacting contacts connector 20.

The CICAM module itself can be a wireless module or can have a connector 40, into which the so-called smart card. The smart card is removable and carries information identifying the current user of the content receiver in a safe and non-volatile way protected from ineptitude. When the smart card is fully inserted into the slot 40, an electrical connection is established between the smart card 50 and the CICAM module 30, either by interacting electrical contacts on the smart card 50 and in the connector 40, or by the known contactless technology in which data is transmitted without contact at a very small distance (about 1-2 cm).

In FIG. 2 schematically shows a host device 10 in the context of a conditional access system. The so-called parent television station 60 is a source of television signal 15 with conditional access. Said parent television station may be, for example, an uplink satellite broadcasting station or a signal distribution center of a terrestrial or cable broadcasting station. The CA system encrypts the content on the parent television station using the CA encryption system. The mentioned head-end television station can also introduce other information related to conditional access into the encrypted data stream, which allows the CICAM-module to decrypt the content and control the access and rights of subscribers (users).

The host television station 60 sends the television signal 15 to the host device 10, which in turn routes the signal to the OCAM module 30 to decrypt the encrypted access control. Then, the CICAM module 30 re-encrypts the signal using local encryption, and sends the re-encrypted signal back to the host device 10 through the PCMCIA connector. The host device decrypts the signal received from the CICAM module 30 for display on the display screen or for sending to another device, such as a video recorder on the hard disk.

In FIG. 3 is a flowchart of the operation shown in FIG. 2 systems. A detailed description of the operation shown in FIG. 2 systems are given in CI Plus-specification 1.3 (2010-01), available (at the time of application) on the website http: //www.ci-.3.pdf. This document is incorporated into this description by reference. The present description of FIG. 3 gives only a general idea of such a detailed work in order to link the corresponding description with the corresponding technical context.

As mentioned previously, in FIG. 3 shows the host television station 60 (receiving the content signal from the content provider), the host device 10, the CICAM module 30, and the smart card 50. The signal 15 is shown coming from the host television station 60 to the host device 10. Secure interface 80 between the host device 10 and the CICAM module 30 is called a common interface (a single joint conditional access for receiving television programs with multiple decoders in one television receiver).

Conditional access

Known CA systems provide a technology whereby a user may be denied access or allowed access to a digital television stream. Access is granted only to those subscribers or users who have valid payment accounts. In practice, the user is provided with a smart card 50 that identifies it in a secure (ideally) way against forgery, and the system is configured so that only users with a valid smart card can access content with controlled access.

Access control is provided using scrambling and encryption. The content signal is scrambled with an eight-bit control word, which often changes (up to several times per minute) to prevent the CA system from being declassified due to the knowledge of the control word by outsiders. The said control words are transmitted to the receiver's CICAM module to descramble the scrambled content in encrypted form as an authorization control message (ECM, abbreviated from Entitlement Control Message). The CICAM module decrypts the control word to allow descrambled content with controlled access only when the module is authorized to do so by receiving an authorization message (EMM, abbreviated from the Entitlement Management Message). EMM messages are specific to each user or group of users; The CICAM module confirms the rights granted by the EMM message by comparing the user ID contained in the EMM message with the user information contained in the smart card 50. The mentioned EMM messages may be sent less frequently compared to ECM messages at intervals between consecutive EMM messages of commercial systems currently in effect from 12 minutes to six weeks.

ECM and EMM messages themselves are widely known types of messages in MPEG television distribution systems. The format of their loads may be specific to the CA system used, and the differences between the formats are more semantic than technical. In various embodiments, ECM and EMM data are transmitted in a packet data stream as data packets defining decryption information, and are used in the decoding process to decode audio-video programs from the packet data stream.

Head television station

The head television station 60 comprises a CA decoder 61, a key generator 62, an authorization control unit 63, and a multiplexer and modulator 64.

The content provider 90 provides content (such as television signals) to the parent television station 60. The parent television station 60 uses content scrambling and encryption to provide conditional access.

More specifically, the CA decoder 61 encrypts or scrambles the content using the CA key as a control word. Said CA key is generated by the CA key generator 62. The scrambled content generated by the CA encoder enters the multiplexer and modulator 64.

The CA key also arrives at the authorization control unit 63, which generates ECM messages based on the CA keys and EMM messages based on the subscriber data determining which of the subscribers has the right to descramble which of the content streams. These ECM and EMM messages are sent to the multiplexer and modulator 64. One or more scrambled content streams from the CA decoder 61, one or more unencrypted (open access or "open unencrypted broadcast") content streams and authorization control messages are combined together to form a transport stream, such as an MPEG2 transport stream. Well-known formats are used to transfer content data and ECM and EMM messages. ECM and EMM messages and data defining the type of scrambling used in each elementary stream (corresponding to separate scrambled content streams) are provided in a known format and are indicated using known technologies in the program composition table (PMT, abbreviated from Program Map Table) and / or in a conditional access table (CAT, abbreviated from Conditional Access Table), which has a specified program identifier (PID) of 0 × 001, so that the CAT table can be recognized by the CICAM module.

The multiplexed transport stream is then modulated by the multiplexer and modulator 64 for transmission in the form of a signal 15 cable, satellite or terrestrial broadcasting.

Host device

The host device 10 includes a tuner 11, a demodulator and a demultiplexer 12, a demultiplexer ("demux") 13, and a content management decoder 14 (CC decoder 14). Please note that the host device may have other additional functions, for example, it can receive two or more programs of satellite broadcasting, cable broadcasting, terrestrial broadcasting and television broadcasting on channels with IP protocols.

Depending on the type of broadcast signal 15, the tuner converts the received signal back to the main frequency band, so that the demodulator and demultiplexer 12 can select and demultiplex one elementary content stream and associated CAT data from the received signal. The content stream and the ECM and EMM message data pass through a common interface 80 to the CICAM module 30.

In the case of content data with controlled access at this stage, the content data is still scrambled as it passes through the common interface 80 to the CICAM module 30. As a result, this part of the transmission through the common interface 80 is protected by CA encryption.

Provided that the ECM and EMM messages allow this, the CICAM module 30 descrambles the content data and re-encrypts it using CC encryption. A method for implementing this process is described below. The data encrypted by CC encryption is returned to the host device 10, where it is demultiplexed by the demultiplexer 13 and decrypted by the CC decoder 14, so that it can be displayed on the screen or displayed on the other device 70 as unencrypted content.

Thus, the host device receives audio and video content and has a content decoder (for example, a CAM module) capable of decoding audio-video programs from a packet data stream (such as a transport stream) using data packets (such as EMM and ECM messages) containing decryption information. The received transport stream may contain one or more programs having data packets identifiable by the respective sets of packet identifiers (such as program identifiers) and containing identification data matching programs (PMT program composition tables, PAT distribution tables, or CAT conditional access tables) corresponding packet identifier sets.

Cicam module

The CICAM module 30 includes a decoder 31, a CA key generator 32, a CC decoder 33, and a CC key generator 34.

The CA decoder 31 and the CA key generator 32 can be considered as an access control unit for decoding access controlled television content or other data. The CC key generator 34 and the CC decoder 33 of the CICAM module 30, and the demultiplexer 13 and the CC decoder 14 of the host device 10 communicate with each other to create an encrypted communication line (common interface 80) for transmitting decoded television content with controlled access between the CICAM module and the host device.

The CA decryptor 31 uses the keys generated from the received ECM and EMM messages by the CA key generator 32 using user identity checks from the smart card 50 to descramble the received access-controlled content. This part of the work of the CICAM module uses well-known CA technologies for searching and applying CA keys.

The unencrypted content data is sent from the CA decoder 31 to the CC encoder 33. However, since this data transfer takes place entirely inside the CICAM module, it can be considered a known and copy-protected technology, such as the placement of the CA decoder 31, CC-encoder 33 and an unencrypted content interface within a single integrated circuit.

The CC encoder 33 encrypts the descrambled content using the CC key provided by the CC key generator 34. This key is established through the secure interaction of the CICAM module 30 and the host device 10 and is specific to such a CICAM module-host device pair. The content encrypted by the CC-encoder passes through the common interface 80 to the host device 10. Thus, this part of the common interface is also protected, as content data is encrypted using CC encryption when passing to the host device.

Key exchange

Both the CICAM module 30 and the host device 10 contain logic, firmware, or software that provide algorithms for secure key exchange using the Diffie-Hellman method, hashing, and encryption using well-known algorithms of the SHA-256 standards (abbreviated from Secure Hash ( Hashed) Algorithm - authentication and information integrity verification algorithm), DES (short for Data Encryption Standard - data encryption standard), AES (short for Advanced Encryption Standard - advanced data encryption standard), relevant certificates issued by an authorized and the body such as the Limited Partnership CI Plus, and private keys with the corresponding public key.

When the CICAM module 30 first communicates with the host device 10, the CICAM module 30 initiates the process of mutual authentication of the devices. During this process, each device verifies the counterparty device certificate, and information is exchanged to generate a shared key using the Diffie-Hellman method to securely distribute keys between the two devices. In particular, the CICAM module first asks the host device for its certificate information. The CICAM module verifies the signature on the host device certificate. A similar process is then performed by the host device, requesting and verifying the certificate of the CICAM module. Then, both the CICAM module and the host device demonstrate that they have private keys corresponding to the public key in the certificate by signing the Diffie-Hellman public key and sending it to the content device for validation. The CICAM module then receives and verifies the ACN authentication key from the host device. The CICAM module and the host device begin to calculate and exchange encryption key data and authentication data sent through the common interface 80. Thus, the key, key pair or other key information set by the CICAM module and the host device for communication through a common interface 80, specific to a specific pair of CICAM-module-host device.

After authentication, the CICAM module also begins to calculate the CC key. The CICAM module may also issue a command to the host device to calculate the CC key. Said CC key is then used, as described above, to encrypt the content data passing through from the CICAM module 30 to the host device 10 according to the algorithm of the improved AES encryption standard. Thus, it is understood that the keys used for the secure common interface 80 are specific to a particular CICAM-module-host device pair.

Typical embodiments of the invention that use multiple tuners are discussed below, although many of the technologies are also applicable to arrangements that use only one tuner.

In FIG. 4 is a block diagram of a host device 100 having several tuners designated as tuner A 102 and tuner B 104, each of which receives an RF input signal. The radio frequency input signal may be a common signal 106 processed by each of several tuners, or it may be a different signal for each of the tuners (for example, one tuner can work with a signal from a terrestrial television station, and the other tuner can work with a signal from a satellite television station). The system mentioned is not limited to two tuners; the principles described are applicable to systems with more than two tuners, however, for clarity, in FIG. 4 shows only two tuners.

The output of each of the tuners 102, 104 is connected to a respective demodulator 108, 110. The output signal may be data, such as a packet data stream or a transport stream transmitted over one corresponding transmission channel selected (from a plurality of custom transmission channels) by such a tuner. The demodulator operates as described above (with respect to the demodulator 12 shown in FIG. 3) to demodulate the packetized signal from the output of the corresponding tuner. The packetized signals from several demodulators 108, 110 are multiplexed by the CI controller 112 for processing by a set 114 of one or more CAM modules having the form of two or more content decoders connected in series. Various options for implementing a set of CAM modules are discussed below, but at a basic technical level, a set of 114 CAM modules is capable of simultaneously decoding at the output of more than one software service. For example, a set of CAM modules 114 may be designed to simultaneously decode as many software services as there are tuners in host device 100.

The decoded data received back from the set 114 of CAM modules is demultiplexed by the CI controller 112 into corresponding signals 116, 118, which are the required software services. Signals 116, 118 are provided to program demultiplexers 120, 122, having the same as shown in FIG. 3 demultiplexer 13 functions.

Finally, each software service is prepared for delivery by a respective decoder 124, 126, having the same as shown in FIG. 3 CC-decoder 14 functions. Decoders 124, 126 generate corresponding output audio and video signals 128,130.

Shown in FIG. 4, the host device is controlled by a central processor 132, which in turn can be a programmable processor device operating according to software or firmware stored in memory 134 (which in turn can be non-volatile machine-readable memory, such as a magnetic or optical disk , or non-volatile semiconductor memory).

In FIG. 5 schematically shows a multiplexing-demultiplexing device forming part of the functionality shown in FIG. 4 CI controllers 112.

In general, as part of the functionality of the CI controller 112, at least the corresponding parts of the packet data signals from the demodulators 108, 110 are combined by the multiplexer 140 into a composite packet data signal sent to a set 114 of one or more CAM modules, and a decoded composite version the packet data signal is received by demultiplexer 142, which demultiplexes it into corresponding signals 116, 118 for decoding. However, there are various ways to achieve this.

The output of the packet data signals of two demodulators 108, 110 may be a so-called. transport streams and usually includes data packets related to several audio-video software services along with various service and control packages. For example, a single packet data signal may include packets related to 3-10 software services, although choosing how many software services are represented by a single transport stream is just as much a commercial choice as a technical one; the transport stream provides a certain frequency band for the data, but the broadcaster remains the commercial choice of how many software services will be provided in the available frequency band. To encode more software services in a given frequency band, the encoding quality (which, based on experience, affects the quality of reproduced audio and video signals) of each software service should be reduced. But in any case, under normal use, it is possible that each of the packet data signals generated by one of the demodulators 108, 110 will contain data packets that are different from those needed to decode the particular desired software service.

Then it becomes technically possible for the CI controller 112 to at least in principle simply combine a plurality of packet data signals from demodulators 108, 110 so that all information contained in each packet data signal is stored. This would make it possible to obtain a composite packet data signal having a data bandwidth of the order of n times the bandwidth of a single transport stream, where n is the number of separate transport streams multiplexed together by multiplexer 140. A potential problem with this construction is that the CAM modules included in set 114, will not be able to process such a high-speed packet data signal. One possible reason is that CAM modules can be designed for harmonious use with only one packet data signal.

Therefore, in other systems, the corresponding subset of the data packets is extracted from each of the output signals of the packet data of the demodulators 108, 110, and the composite signal of the packet data, which should be supplied to the set 114 of one or more CAM modules, is generated from a combination of such corresponding subsets. The technology for generating such a combination to generate a composite packet data signal is discussed below.

Two types of CAM modules belong to this consideration. In FIG. 6a schematically shows the so-called M-card (multithreaded card) 150, and in FIG. 6b - the so-called S-card (single-threaded card) 160.

The main technical difference between the two types of CAM modules is as follows. An M-card is a single device capable of simultaneously decrypting more than one software service. It is a more modern version of the CAM module than the S-card, which has been discontinued, but is still in operation and is able to decrypt only one software service from the transport stream. It should be noted that the M-card can work either in multi-threaded or single-threaded (like S-card) mode. S-card can only work in single-threaded mode.

In FIG. 7 schematically shows a transport stream packet 170. Mentioned packets contain a 4-bit header 172 and 184-bit part for the payload. This is the standard format for transport stream packets, and the transport stream is formed from a sequence of packets of this format. Header 172 includes a packet identifier or PID (short for Packet IDentifier). Each audio-video program service has an associated set of two or more packet identifiers. For example, one packet identifier may be associated with program service video packets, another PID packet identifier may be associated with audio program service packets, and another packet identifier may be associated with service encryption control packets. Thus, different packet identifiers can be used within a single transport stream. The distribution of package identifiers for various types of packages is carried out through the program distribution table (PAT) and the program composition table (PMT, abbreviated from Program Map Table). The program distribution table itself has a package identifier of 0 and works in such a way as to indicate the identifiers of the packages carrying the program composition table. The program composition table indicates the identifiers of packets carrying video and audio data, as well as identifiers of packets carrying data for detecting and correcting errors in the service. For completeness, the Conditional Access Table (CAT, abbreviated from Conditional Access Table) has a packet identifier of 1 and indicates which of the packets carry an EMM message for one or more access control systems.

Packet identifiers are uniquely identified within a single transport stream in the 13-bit range (0-8191 in decimal). However, from one transport stream to another, the data represented by a particular packet identifier value may be ambiguous. Those. the packet identifier value can be reused in various transport streams. In the case where multiple transport streams are multiplexed by multiplexer 140, a mechanism is needed to eliminate this potential ambiguity of packet identifiers.

One technology to ensure this is described in US publication 7394834, the contents of which are incorporated into this description by reference. According to this publication, packets representing the desired services are retrieved from several transport streams, and packet identifiers retrieved from at least one of the transport streams are converted to new packet identifier values that are not used for any data retrieved from other transport streams. The conversion process includes replacing the value of the packet identifier with another value of the packet identifier with recording or entering the packet identifiers in the correspondence table, so that the desired service can be identified by the new (converted) values of the packet identifiers. Such a scheme can be used to generate a pseudo-transport stream, which is, so to speak, an artificially created transport stream that exists only within the host device, but which gives the impression (from the point of view of the S-card) that it meets all the requirements for the format of the broadcast transport flow. Those. this pseudo-transport stream can be decoded by an S-card, as if it were broadcast in this form, although in fact it was developed within the host device by combining parts of several broadcast transport streams.

Another technology is to use a preliminary header, which is inserted at the beginning of each packet of the transport stream and contains information about the origin of this packet. This technology is used when sending to an M-card operating in multi-threaded mode. An example transport stream packet with a preliminary header 176 is shown schematically in FIG. 8.

Preliminary header 176 contains 12 bits of additional data and is pre-added to each packet sent to the M-card. Those. it is added at the beginning of each package. The 12 bits of additional data contain various fields, including the identifier of the local transport stream, identifying the transport stream from which the packets were extracted, the local time stamp, data for detecting errors in the preliminary header, and backup data fields for subsequent or special use. It is important for the purposes of the present invention that the local transport stream identifier means that even in a situation where packets in the composite packet data stream have conflicting packet identifier values, they can nevertheless be distinguished by their local transport stream identifier value, contained in the preliminary title.

It should be noted that the M-card requires an additional preliminary header. S-card cannot work if there is an additional preliminary header.

So, in another scheme, the multiplexer 140 combines the packets extracted from several transport streams into a composite packet data stream for use by an M-card, adding at least to each such packet at least an identity element to the transport stream from which it is extracted.

In FIG. 9 shows a more detailed block diagram of a multiplexer. Shown in FIG. 9, a multiplexer block diagram relates to a block diagram in which a pseudo-transport stream is generated for decoding with S-cards and M-cards when operating in single-threaded mode.

Each input transport stream passes to a corresponding packet identifier selection block 180, 182, which refers to a program distribution table 184, 186 associated with this transport stream and data 188, 190 defining the required software service to establish the packet identifiers that are required for decoding (the required software service) as part of a composite packet data signal.

In embodiments of the invention, selection blocks 180, 182 are activated to perform one or more of the following operations:

selecting data packets from the packet data stream for the desired program according to the set of packet identifiers defined by the identification data for the stream in relation to the desired program;

selecting additional data packets from the packet data stream from which the program is selected having packet identifiers not included in the identification data for this packet data stream; and

selecting from each stream of packet data from which the program is selected, additional data packets containing data of the master clock of the program related to the selected program.

The mentioned features of the operation of the selection blocks are described in more detail below.

Data 188, 190 defining the required software service can be provided by the central processor 132, for example, in response to a user request of a remote control not shown in the drawing or, possibly, in response to a machine request, for example, from a command-line video recorder a timer and requiring the receipt of some software service for a given time interval for recording it. Block 192, 194 for each transport stream rejects "unwanted" packets, i.e. packets that do not have packet identifiers defined in a selection made by selection blocks 180, 182. The packet identifier conversion unit 196, 198 is used to convert the packet identifiers of one of the transport streams to the new packet identifier values in order to exclude any possible coincidence with the packet identifier values of the other transport streams. It should be noted that the conversion does not occur in cases where there is no mismatch (in multi-packet mode) of the packet identifiers between different transport streams, although in some embodiments of the invention all identifiers of at least selected packets of the secondary transport streams can be converted to corresponding different packet identifiers. It should also be noted that there is no need to perform a conversion operation for both transport streams (or, if there are more than two transport streams, then each transport stream), and in fact, in embodiments of the invention, one of the transport streams is processed as the so-called A “primary” transport stream for which packet identifier conversion is not performed. For flexibility, however, a conversion unit 196, 198 is provided for each transport stream for possible use if required. It should also be noted that only those packet identifiers that conflict (the same packet identifier number as the packet from another transport stream) need conversion, although other packet identifiers can also be converted. In some embodiments, packet identifiers from one or more “secondary” transport streams are candidates for conversion, while packet identifiers from a primary transport stream are not candidates for conversion.

In other embodiments of the invention, the selection blocks 180 may be considered when making a selection of the so-called. packets of the master clock of the program, so that such packets are included with the composite stream of packetized data.

For reference, for decoding audio and video data in a transport stream, the data of the master clock of the program are used as clock information. The data of the master clock of the program are relatively small and are actually included in the packet of the transport stream in the so-called adaptation field. Said adaptation field is within the 184-bit payload 174 (see FIG. 7), but from the point of view of the function, it appears more like an extension of the header (inside the payload field 174). To signal the presence of an adaptation field, the header carries a flag pointer (such as a one-bit flag). In addition, there is another signaling means associated with the adaptation field, in turn, to indicate that the adaptation field contains the data of the master clock of the program. Thus, the selection blocks 180 can identify a packet carrying data of the program clock, by first checking the “presence of adaptation field” flag in the packet header and then checking the flag associated with the adaptation field indicating that “the adaptation field contains data of the program clock” .

The mentioned clock information indicated by the data of the master clock of the program, as a rule, is common to all program services in the transport stream. It is used by decoders, so that decoding of the content is carried out according to packets with data of the master clock of the program and packet identifiers related to the required service. Thus, as a rule, it is necessary to provide one data set of the master clock of the program within the transport stream. In the prior art, the general rule is that the data of the master clock of the program for the transport stream is contained in the adaptation fields of packets related to one randomly selected software service. The identifiers of packets carrying the data of the master program clock for the transport stream can be indicated in the PCR_PID field of the program composition table.

In schemes where the entire transport stream enters the CAM module for decryption (as is the case in the "one tuner - one CAM module" scheme or in the scheme with the allocation of its own CAM module for each tuner or source of the transport stream), that the data of the master clock of the program can be in packages related to the software service, other than the currently observed or currently decoded software service, is not a problem, because The program clock data remains available for the CAM module and then for the decoder.

But in the considered embodiments of the invention, in which a composite packet data stream is formed as a combination of subsets of several input transport streams, each subset related to the required software service, situations may arise in which there is no data of the program clock for the program service, t. to. they are contained in packages related to a different software service than a software service selected from a given transport stream.

To eliminate such situations, the selection blocks 180 can check the adaptation field of each packet and (if there is an adaptation field) a data availability flag for the program clock, so that if the packet is a packet containing data of the program clock, then the packet is selected regardless Whether or not it relates to the selected software service. Said packet containing the data of the master clock of the program is included in the selected packets and thus is included in the composite stream of packet data.

The selected and, if necessary, converted packets are then combined into a single composite data stream in combining unit 200. For example, it can be a cascade connection process in a circuit, which, simply put, means connecting packets side by side (one after another) into a composite data stream. This does not necessarily imply that the packages are located directly behind each other (there may be gaps between them) or that they are located in some specific order.

As a result, the packet data stream collected using this technology may contain data from several data sources of the program clock. In general, there may be packets containing data of the master program clock originating from each transport stream from which the program service is selected for inclusion in the composite stream of packet data. However, for each software service, the decoder is able to access the correct data of the master clock of the program. If the data of the program clock is included in the packages of the program service to be decoded, then the decoder will use this data of the program clock. If the data of the master clock of the program in the original transport stream were included in packets related to another software service, then these packets will be included with the composite stream of packetized data through the above mechanism. In any case, even if packet identifier conversion is used, the PCR_PID data (converted, if necessary) is stored for each software service in a composite packet data stream. In fact, the data set from the program distribution table and / or from the program composition table is transferred to the composite packet data stream as the identification data of the composite stream (see the example shown in Fig. 14) for each selected program service, for example, so that specify in the composite stream packet identifiers containing audio, video data and conditional access data, as well as to indicate PCR_PID.

Therefore, if the receiving step is to receive two or more packet data streams; the selection steps discussed above apply to each packet data stream from which the program is selected; the composite packetized data stream contains program data from two or more packetized data streams; and generating a composite packet data stream is to connect the selected packets to form a composite packet data stream. In FIG. 10 schematically shows packets 205 of a transport stream of two software services, services 1 and services 2, combined into a single composite packet data stream.

In FIG. 11 schematically shows a sequence of CAM modules as an example of the above set of 114 CAM modules. CAM-modules in the set are arranged sequentially in the form of so-called chain, so that the composite stream of packetized data from the output of the CI controller 112 is fed to the input 210 of the first CAM module 212 of the sequence and sent from the first CAM module 212 to the second CAM module 214 of the sequence, from where it goes to the third CAM module 216, before returning back to the CI controller 112, having the required services, decrypted based on the identifiers of the packets passed to the CI controller 112 together or as part of the identity of the composite stream. The CAM modules in the chain can be adapted to decrypt different conditional access services, so that whatever service (within the services and CA systems processed by set 114) is selected for decryption by the user or by command of the control device, one of the CAM modules said set 114 is capable of decrypting it. The technology by which a host device can select a suitable CAM module to decrypt a particular software service is described below with reference to FIG. fifteen.

Accordingly, the content decoder, made in the form of a set of CAM-modules or conditional access M-cards, is capable of simultaneously decoding two or more audio-video programs from one packet data stream, and in such cases, the step of generating a composite packet data stream includes forming a composite stream packetized data from packets representing two or more programs.

It should be noted that each CAM module has two main interfaces. Audio, video, and some control data may enter the CAM module as part of the composite packet data stream supplied to input 210 and pass from one CAM module to another. In addition, there is a control interface between the CI controller and the CAM module with a significantly lower data rate. The control signals, which are discussed below, can be multiplexed into a composite packet data stream or transmitted via a control interface.

In general, only the CAM module decrypts a specific software service, and the CAM module cannot decrypt the software service other than after receiving a command from the host device to perform this action.

In some embodiments, the circuit shown in FIG. 11, can work if all CAM-modules in the chain are S-cards (or M-cards operating in single-threaded mode), or if all CAM-modules in the chain are M-cards, because In any case, the data format of the composite packet data stream is the same throughout the chain of CAM modules. For situations where this is not the case, in FIG. 12 schematically shows a sequence of CAM modules 220, 222, 224 with interfaces 226, 228 between them.

Assume that in one embodiment, the CAM module 220 is an M card, the CAM module 222 is an S card, and the CAM module 224 is an M card. The signal 230 of the composite packet data stream received from the CI controller 112 has an M-card format, i.e. includes the additional preliminary heading discussed earlier. This signal is processed in the usual way by the M-card 220, but then, instead of directly arriving at the next card 222 of the chain, it goes to the interface unit 226, where additional header information related to the preliminary header is excluded from the packet, and, if necessary, the packet identifier value is converted before the composite packet data stream arrives on the S-card 222. The interface unit 226 stores the excluded data and any data of the identifier conversion pa eta related to the original composite packet data stream and transmits this stored information to the interface unit 228, which receives the output data stream from the S-card 222. The interface unit 228 reinserts the preliminary header into each package and performs the inverse transformation of the packet identifiers to return the values packet identifiers their original form. The output data stream from the block 228 of the interface then goes to the processing of the M-card 224.

In FIG. 13 schematically shows a block diagram of a so-called processing algorithm ghost packet identifiers.

Phantom packet identifiers refer to the so-called ghost packets in the MPEG transport stream. Sometimes ghost packets can be used by participants in a broadcast system, such as manufacturers of host devices, manufacturers of television receivers, broadcasters, vendors of CA systems, etc. to ensure confidentiality of control information (such as, for example, "personal" data) in various parts of the host device and, in particular, in the CAM module or CAM modules used in the host device.

In general, it is considered desirable to keep such packages secret or at least not to advertise their availability, as they may contain information that may be useful to an unauthorized user or hacker in order to carry out unauthorized decryption of one or more services.

In a simple example, ghost packets may include a firmware update for the CAM module, which in turn contains data that CA vendors or CAM module manufacturers prefer to hide from potential hackers. To achieve the necessary degree of confidentiality, packets containing such data can be transmitted using packet identifiers that are retrieved by the CAM module according to (for example) a specified algorithm based on current time or other conditions, but which are not indicated as part of any distribution tables forming part of such a traffic stream. Thus, ghost packets are potentially important for the operation of CAM modules, but since they are not included in any distribution tables, they can essentially be discarded as shown in FIG. 9 rejection units 192, 194, unless targeted actions are taken to avoid this, and may be absent from the composite packet data stream that actually enters the CAM module.

To solve this potential problem, the selection blocks 180, 182 and shown in FIG. 9, reject units 192, 194 may operate according to the following shown in FIG. 13 stages.

At step 250, blocks 180, 182 select packet identifiers for the required software services. This mode of operation corresponds to that already described with reference to FIG. 9. The difference compared to FIG. 9, however, consists in the fact that, at step 252, the selection blocks also select (for inclusion in the composite packet data stream) all packet identifiers that are not specified in the identification data (program composition tables, program allocation tables, or conditional access tables) for this traffic flow. Thus, at this stage, the selection blocks do not know which functions the ghost packet identifiers have, but they select all the packet identifiers that are present in the transport stream and which do not specifically correspond to software services other than the required software service. At step 254, the conversion units 196, 198 perform the conversion operation, but it should be noted that the conversion operation is performed not only in relation to the packet identifiers of the selected service, but also in relation to the phantom packet identifiers selected in step 252. Finally, in step 256, the conversion data representing the correspondence between the identifiers of packets before conversion and identifiers of packets after conversion (see the example shown in Fig. 14) are sent to the set of 114 CAM-modules, so that if the CAM module from the set requires access to the packet indicated by the ghost identifier of the packet, then the CAM module can identify such a packet in the converted data by referring to the conversion information and decode the identified packet, respectively.

It should be noted that the packet identifiers used to designate ghost packets may change from time to time. In fact, this may be part of the security routine associated with these packages. Ghost packets may not be transmitted too often. So, if shown in FIG. 9, the system first works with a specific software service from a specific transport stream; it cannot know in advance the current set of ghost packet identifiers. She can recognize it using one of two technologies: by detecting (using selection block 180, 182) the packet identifier in the data stream that is not in all look-up tables, or by asking the CAM module (for example, via the control interface) a specific identifier a packet that the CAM module considers necessary, but which is not in the composite packet data stream. The first of the technologies can be considered a proactive choice, the second - a reciprocal choice. In any case, selection block 180, 182 may in response select such a packet identifier to include in the composite packet data stream. In principle, this can happen immediately, so that at the first request, such a packet identifier is included in the composite packet data stream. Or there may be a delay, in particular, if the packet identifier is included in the composite packet data stream in response to a request from a CAM module requesting a missing packet identifier. This is due to the relatively low data rate of the control interface. But a small delay (for example, less than one second) is not considered a problem, because Common practice is to repeatedly transmit any important packets that are not part of the audio-video stream. This is done in order to take into account the possibility of turning the TV on or off by the user at any time, so that when a critical packet is transmitted once, the user can skip such a transfer.

In FIG. 14 schematically shows a packet identifier correspondence table as an example of the kind of converting information that can be transmitted from multiplexer 140 to a set of CAM modules 114 in step 256, either in the form of control data or data multiplexed into a composite packet data stream. The packet identifier correspondence table contains the transport stream identifier 260 from which the packet identifier was extracted, the program service identifier 262 extracted from their transport stream, the “former” packet identifier 264 (before conversion) and the “new” packet identifier 266 (after conversion). The packet identifier mapping table may be multiplexed into a composite packet data stream and / or transmitted to the CAM module via the control interface 218. In some embodiments of the invention shown in FIG. 14, the table may serve as an example of the identity of a composite stream. In some embodiments, the data from that shown in FIG. 14 tables can be used to control the decoding of programs from a composite packet data stream by one or more CAM modules in accordance with the packet identifiers contained in FIG. 14 of the package identifier matching table.

It should be noted that for any transport stream there can be several entrances to the one shown in FIG. 14 is a correspondence table of packet identifiers relating to different packet identifiers of the required software service and various other phantom packet identifiers present in the transport stream.

It should also be noted that the packet identifier mapping table may change over time, so that it is either retransmitted to the CAM modules by the CI controller, or at least partially retransmitted in response to a change in the conversion. One reason that the re-conversion may change is that the newly identified ghost packet has a packet identifier that matches a different packet identifier in the composite packet data stream, which necessitates the conversion of one of them, identifiers, or both packet identifiers.

In FIG. 15 is a schematic flowchart of identifying which of the CAM modules of an existing sequence of such modules is capable of decoding a desired software service.

Shown in FIG. 15 operations indicate the interaction or handshaking between the host device and each CAM module from the set of CAM modules. The following describes operations related to only one CAM module from the set, but it should be understood that the corresponding operations are performed with respect to other CAM modules from the set.

Step 300 is performed at system startup or boot, and consists in the fact that each CAM module sends data (the so-called CA_SYS_ID conditional access system indicator) to identify the type of CA system that this CAM module can decrypt when it receives the corresponding ECM / EMM data for the service.

Step 310 occurs when a new software service is selected for decryption, for example, using a control panel or a timer of a recorder, or when the CA parameters associated with the software service are changed (for example, from “unencrypted” to “encrypted” or vice versa). The host device sends the packet identifiers related to the required software service to the CAM module of the set 114. Each CAM module in step 320 detects the ECM and EMM data related to this service, and identifies it in step 330 (with reference to the ECM - and EMM data, as well as the own capabilities of the CAM module), is it possible to decode such a service with this CAM module. Naturally, at step 310, the host device can decide to send the questioning packet identifiers only to those CAM modules that, at step 300, showed the original (fundamental) ability to decode this type of data.

At 340, the host device checks for a response from the currently requested CAM module. If the CAM module can decode the software service, then at step 350, the host device distributes the task of decoding the software service to the current requested CAM module. If not, then if there is still a CAM module that has not yet been requested, the host device returns to step 310 to request the next CAM module. Otherwise, if there are no more unsolicited CAM modules left, and the process stops, and the user is additionally notified that the required software service cannot be decoded by the set of 114 CAM modules available in the system.

In FIG. 16 schematically shows a control algorithm for several tuners 102, 104 implemented by a host device, in particular, for example, a host processor 132. In FIG. 16, the left part of the flowchart refers to operations performed by the host device, and the right part refers to operations performed by the CAM module from set 114.

This process introduces the concept of a "primary" and "secondary" tuner, although this can be considered as equivalent to a "primary" and "secondary" transport stream, as in the present embodiments, there is a unique correspondence between the operation of the tuner and the reception of the transport stream, in other words, in the present embodiments, each tuner receives one transport stream.

At 360, the factory setting is the designation of the tuner 102 (tuner A) and the transport stream received by the tuner 102, the definition of "primary", and the tuner 104 (tuner B) and the transport stream received by the tuner 104 - the definition of "secondary". It should be noted that in normal operation, only one tuner is required to watch a TV program, as they say, "live"; one of the functions of using another tuner is to record a second program service while the first service is being viewed live. Alternatively, the first of the tuners or traffic streams originally requested for use may receive the initial designation of the primary transport stream or primary tuner.

At 362, the central processor 132 determines whether a secondary tuner (transport stream) is used, for example, to record a software service for later viewing. If the secondary tuner is not used, then at step 364, the central processor 132 or the CI controller informs the set 114 of CAM modules that the secondary tuner is free, in response to which one of the CAM modules of the set may decide to use the secondary tuner for unobtainable reception non-viewable information at step 366. In other words, if the tuner is not currently used to provide a program for decoding, then it is considered available for use in order to access the channel (for example, tuning to the channel), he neprosmatrivaemye information.

In this case, the term “invisible reception” may refer to the reception by the CAM module of non-visible information, such as CAM module management information, service data, firmware or software updates or the like, which may require exclusive use of this CAM- module or tuner for an indefinite time.

Another example relates to the so-called. "impose video on demand." In this situation, the CAM module may, preventively or by command from the parent television station, require the storage, for example, on the hard disk of the received data relating to video programs that the user may wish to view. Accordingly, for this purpose, the CAM module can act as a controller for managing storage of non-viewable information for subsequent access. The received data may relate to the entire program, or to the announcement or advertisement of the program, or may provide a sufficient amount of buffer data for instantly initiating a response (at the command of the user), even during the broadcast of the program. Reception of this kind of data is not specifically requested or initiated by the user; the data is received at the initiative of the CAM-module or another part of the system as a background process and is considered as “non-viewable data” or “unviewable information”, a) such data is often transmitted at a lower speed than the transmission speed of the decoded or viewed data, and b) the user must take additional steps (such as requesting access to data stored in the hard disk recorder) before even the visible part can be viewed. The data can be decoded by a CAM module acting as a decoder of the non-viewable information.

Unviewable information may be carried by at least one transport stream.

Over time, while at step 366 reception of service or other non-viewable data is performed, any other accesses to step 362 will lead to an indication of the busy state of the secondary tuner. Naturally, if the user requires the use of a secondary tuner, for example, for recording a software service, then the use of the tuner by the CAM module for invisible background reception can be stopped. This is done in such a way that the user does not even know that the CAM module has ever used a secondary tuner.

Returning to step 362, if a secondary tuner is required for use, then at step 368 the identifiers of the software service packages to be received by the secondary tuner (and, additionally, the identifiers of any phantom packets in this transport stream) are selected. This corresponds to steps 250 and 252 of FIG. 13. At step 370, the secondary transport stream packet identifiers selected as described above are converted (according to step 254 in FIG. 13), and packets corresponding to the selected primary and secondary tuner packet identifiers are multiplexed to form a composite packet data stream. It should be noted that, as discussed above, it is only necessary to convert the packet identifier if there is a collision or conflict with another packet identifier from another transport stream. The system can convert all identifiers of packets selected from the secondary transport stream, or identifiers of only those packets that have come into conflict with identifiers. However, it is important that the secondary transport stream is the stream that has packet identifiers that are at least candidates for the conversion, if the conversion is necessary. Packet identifiers in the primary stream are not converted, they retain their original values (as they were when they were received).

This order is maintained until the change in channel (software service) is detected at step 372. A channel change can be initiated by the user using the control panel or a machine channel change operation, for example, by a timer command to control the recording process that requires access to a specific software service. The actions in response to the detection of a channel change depend on which tuner, secondary or primary, the channel is changing.

If the secondary transport stream changes, then returns to step 362, but no changes occur with the purpose of the primary and secondary transport streams.

If, however, the channel on the primary tuner (transport stream) changes, then proceeds to step 374, where the assignment of the tuners primary and secondary is reversed, and also returns to step 362. That is, in a system that has two tuners, each of which receives a corresponding transport stream, one stream that was previously designated as primary is now assigned as secondary, and the second stream, which was previously secondary, is now assigned as primary. (In systems with more than two tuners, the tuner, formerly the primary one, is now assigned as the secondary one).

The result of this is that the transport stream, formerly primary, is now treated as secondary and is thus subject to the process of converting its packet identifiers at 370, or its packet identifiers at least become candidates for conversion. In turn, this means that there is no need to perform any further conversion or change of the packet identifiers of the formerly secondary transport stream, since such a formerly secondary transport stream is now treated as primary. As for the user, this means that viewing is not interrupted on a channel that does not change, because the tuner receiving this channel (or the transport stream carrying this channel) is now assigned as the primary one, and thus, there is no need to further convert the identifiers of packets coming from this tuner.

The change in the destination of the transport stream from primary to secondary in the considered embodiments of the invention is carried out immediately, but the change in the destination of the stream from secondary to primary may be delayed until it is determined that the secondary transport stream must be reconfigured, because there is no current primary stream, in which case the change is applied to said secondary transport stream. It should be noted that this feature is typical for systems with two or more tuners.

If the presented system did not take place, then the change of the channel by the primary tuner might require a re-conversion of the packet identifiers received by the secondary tuner. This is because the conversion performed on the packet identifiers of the secondary transport stream is performed to eliminate a conflict between the packet identifiers of the primary tuner and the transformed packet identifiers of the secondary tuner. If there was no change in the purpose of the primary and secondary tuners, then changing the software service for the primary tuner can lead to a conflict of packet identifiers and, therefore, to the subsequent need to convert secondary packet identifiers, even if the channel did not change on the secondary tuner. Accordingly, in the absence of this technology, changing the channel on the primary tuner could lead to a temporary interruption of the service for the program received by the secondary tuner, which, in turn, would be subjectively unpleasant for the user.

Step 374 may be described further as follows. In response to detecting a change in the channel or transport stream received by the primary tuner (or, in other words, in response to detecting that the primary tuner is using another program), the primary tuner can be reassigned to the secondary one, and the tuner that was previously the secondary one is reassigned to the primary one. However, this does not imply that the conversion operation performed at step 370 with respect to the former secondary (and now the primary) traffic stream should not be performed, and indeed this would not be desirable since this would lead to a possible interruption of the service received by this tuner. But this does not mean that there is no need to perform any conversion of the newly assigned primary packet identifiers in order to avoid conflict with the previous primary (now secondary) packet identifiers after the migration.

In other words, if it is revealed that another program has been selected for decoding from the primary transport stream (compared to the currently decoded one), or if it is found that a different transport stream (compared to the current primary stream) is selected, then the secondary tuner is reassigned as the primary one.

In cases where at present the primary tuner is absent (when the primary tuner is reassigned as secondary, but the secondary tuner has not yet been reassigned as primary), then if it is revealed that another program from the secondary transport stream has been selected for decoding (compared to the program currently being decoded from secondary transport stream), or it is revealed that a different secondary transport stream is selected (compared to the current secondary transport stream), then such a secondary tuner is reassigned as primary.

In FIG. 17 schematically shows the multiplexing of two separate software services.

Using the technology described above, a mechanism is proposed for combining selected packets from two or more transport streams into a single composite packet data stream. Packets can be multiplexed in the correct order, i.e. for any separately received transport stream, packets related to the required software service for decoding will appear in the composite packet data stream in the correct order relative to each other. However, this mechanism does not necessarily guarantee that multiplexed packets will appear in a consistent stream of packetized data at the correct time. In practice, the problem may be when two packets intended to be included in the composite packet data stream have overlapping temporary positions; when creating a composite packet data stream, one of the packets must be delayed to be included in the composite packet data stream after the other. Such temporary errors may lead to corresponding errors in decoding or playing back the audio-video signal represented by said packets.

In FIG. 17 schematically shows an example of such a possible problem. A subset of packets is selected from each of the two transport streams TS1 and TS2. The selected subset of packets is packets elongated along a time axis extending from left to right in the drawing. Unselected packages are simply not shown in the drawing for clarity. An example of a temporary collision is the time overlap of a packet 400 from a transport stream TS1 with a packet 402 from a transport stream TS2.

The third row in FIG. 17 (labeled “to / from the module”) schematically shows a composite packet data stream. It can be seen that the packet 400 essentially retained its original temporary position, but the packet 402 is delayed in time to get into the composite packet data stream after the packet 400.

The fourth and fifth rows in FIG. 17 represent separate packetized data streams reconstructed after decryption by a set of 114 CAM modules and demultiplexing. Again, it can be seen that the decrypted packet 400 'has retained its original temporal position, while the decrypted version of packet 402 (decrypted packet 402') has experienced a time delay 404. A similar time delay 406 is experienced by the last packet in the transport stream TS2.

Such a change in the temporal positions of the packets in the transport streams makes the timestamps of the master clock of the program in the packet data stream further inaccurate. As a result, the receiver clock necessary for decoding the MPEG standard software service will not be accurate enough, and this can cause subjectively unpleasant sensations for the user, such as errors in synchronizing lip articulation with speech.

To solve this problem, two possible technologies are further discussed. In FIG. 18 schematically shows a packet 410 (with or without a preliminary header, as described above), which also includes an extended header 412 containing at least the arrival time of the packet in the form of a time stamp assigned to each packet of the transport stream coming from the corresponding demodulator, or, in other words, correlated with the time of formation of the composite stream of packet data.

In FIG. 19 schematically shows a table with packet clock information storing similar data, although not in the form of a packet header, allowing to restore the initial distribution of transport stream packets in time at the final decoding stage. The table can enter the CAM-modules through the control interface, for example, in the form of confidential DVB data or in the form of tabular data. Such data may be transmitted as a confidential data packet located in a composite packet data stream adjacent to the packet to which it relates. This links the mentioned data with the corresponding package.

In an initial detailed examination of FIG. Figure 9 shows that the packet clock table contains five fields for each packet of the transport stream. This is the sequence number 420 assigned by the host device to each incoming packet of the transport stream as part of the sequence, this is the 422 identifier value of the packet taken from its header, this is the arrival time 424 of the packet, which is the time stamp assigned by the host device or CI controller to each packet the transport stream coming from the corresponding demodulator is the Sent flag 426, which means that the transport stream packet has been sent to the set of 114 CAM modules for decryption, and this is the Received flag "(" Accepted "), meaning that the transport stream packet is received from the set of 114 CAM modules after decryption.

Using the information contained in the packet clock table, the CI controller can insert the decrypted packets received back from the set 114 of CAM modules into their original time positions according to the packet arrival times stored in the table. Naturally, there may be a slight delay of all packets in the restored transport stream (since packets cannot be reinserted into the transport stream before the time when they will be received back from the set of CAM modules), but the relative temporary position of all packets in the restored transport stream can be stored correctly by using the packet arrival data stored in the packet clock table.

A similar problem can be solved using the data shown in FIG. 18 extended header 412.

In FIG. 20 schematically shows the formation process of FIG. 18 packets, and FIG. 21 illustrates the use process of FIG. 18 packages.

From FIG. 20 it can be seen that at step 430, the CI controller determines the current arrival time of the transport stream packet to the CI controller, and at step 432 adds at least the mentioned arrival time to the extended header 412.

According to FIG. 21, when a packet is received back from the set of CAM modules after decryption, said CI controller, in step 434, recognizes the clock information previously inserted in the extended header 412, and in step 436 either generates control information to control the decoding of the packet at the correct time, or reinserts the packet back into the restored transport stream at the correct time (or, as described above, at least at the correct time relative to other packets in the restored transport stream).

In FIG. 22 schematically shows the process of forming shown in FIG. 19 of the table, and in FIG. 23 is a process for using this table.

According to FIG. 22, in step 440, the CI controller determines the arrival time of the transport stream packet from the corresponding demodulator, and in step 422 stores this arrival time as part of a table similar to that shown in FIG. 19 of the table, along with the serial number and packet identifier extracted from the packet header. If the CI controller sends such a packet for decryption, the CI controller sets the Sent flag 426 to indicate that this packet has occurred.

According to FIG. 23, when the packet is received back after the decryption process, the CI controller sets the Received flag 428 at step 444 and then, at step 446, accesses clock information from the table field 424 using the packet identifier 422, and serial number 420 to indicate the correct packet data. Additionally, since access to a series of data for a packet is obtained, it can be removed from the one shown in FIG. 19 tables to avoid too much data growth in this table. As before, at step 448, the CI controller either controls the decoding process of this packet, which should be carried out at the right time, or controls the insertion of the packet into the restored transport stream at the right time, or at least in relation to other packets in such a restored transport stream time.

Two distinctive features of some conditional access systems that increase system security are the so-called. avoidance procedure and so-called cancellation procedure.

Avoidable data is included in the form of so-called service description tables (Service Description Table) as part of the broadcast data, such as, for example, service data, including information on the secure authorization of host devices (content receivers). Avoidance allows the host device to be notified of the prohibition of the use of pirated or other unauthorized CAM modules or of the prohibition of receiving and decrypting certain services. Unauthorized modules or services are determined by the service description table. Accordingly, avoidance imposes an obligation on the host device not to use the CAM module.

Cancellation includes a directive to the host television station to transmit to the CAM module data containing an instruction to the module not to interact with a specific model number of the manufacturer as a host device. On the other hand, revocation can be used in situations where the security of a particular model is compromised in order to protect the integrity of the entire conditional access system. Thus, the cancellation imposes a ban on the CAM module to provide decryption services to any host device. The cancellation data is transmitted by entering in the EMM message an indication to the CAM module where to find the Revocation Signalling Data file in the data carousel of the CI Plus common interface.

In a situation of avoidance or cancellation, the host device determines, based on the data in the service description table, whether the host device is authorized to decode the received program data. The host device may further notify the user of the occurrence of such a situation, for example, by means of an on-screen display not shown in the drawing.

Revocation data is usually signed by an operator certificate, which in turn is signed by the root certificate, and thus the precautions described below are more relevant to avoidance data than to revocation data.

All this data is contained in the transport stream. In a system with one tuner and one CAM module, the integrity of the avoided and / or canceled data can be essentially guaranteed by the tuner bypassing the CAM module, checking the data of the service description table for any avoidable or canceled data related to the current host device and / or to a CAM module, and passing said avoidable or nullified data into the CAM module for execution. Such measures make it possible to exclude the CAM module from manipulating data in the transport stream until this data is verified by the host device. (This is dangerous in a situation where the CAM module is compromised).

The situation is even more complicated in the case of multiple tuners and a multiplexed composite packet data stream. It’s not easy to get around a set of CAM modules in the context of a composite packet data stream. Thus, there is a danger that one or more CAM modules from the set may distort or manipulate the data to be deleted or canceled in the service description table before the host device acts according to this data in the context of determining whether the host device is authorized to work with a CAM-module, for example, whether it should avoid the CAM-module (for example, by means of a command on the CAM-module not to decode the received program data) or refuse to interact with a specific CAM-module.

In FIG. 24 schematically shows a configuration that allows at least mitigating this problem in the context of, for example, shown in FIG. 4 host devices.

According to FIG. 24, the multiplexed (composite) data stream generated by the CI controller 112 is signed by the digital signature block 460 using a secret cryptographic key. A digitally signed multiplexed data stream then enters a set of CAM modules 114, which acts as a content decoder for decoding two or more programs from a composite packet data stream according to packet identifiers contained in the stream identification data. After decryption, the signature is verified by signature verification block 462 (which verifies the validity of the signature) before data is returned back to demultiplexer 142.

Well-known digital signature technologies using a private key and public key verification can be used here. Such a key may be unique to the receiver, for example, secretly stored in the receiver's memory during manufacture. Such a digital signature is an example of a sign of digital security.

A secret key may be transmitted between the digital signature block 460 and the signature verification block 462 via a secure data line 464. A pair of private and public keys may differ from the host device to the host device to increase the potential reliability of the verification system.

A digital signature can be applied to the entire composite packet data stream, or only to data from a service description table in a data stream. So, in some embodiments of the invention, a digital signature is applied to at least the data in the service description table included in the multiplexed stream. A digital signature may be inserted into the data stream or may be transmitted separately between blocks 460 and 462.

If the host device detects that the digital signature is malformed, it can act differently. It can inform the user about this, for example, by displaying it on the screen. It can, using the control interface 218, turn the CAM modules on and off in turn to detect which of the CAM modules causes distortion, and then permanently or almost permanently deactivate this CAM module. In any case, the CI Plus specification notifies that the host device does not allow the damaged or avoidable CAM module to decrypt the current content for viewing by the user on the screen or for recording.

It should be borne in mind that some of the above technologies, for example, technologies for generating a composite packet data stream, relate to systems using at least two transport streams. Other technologies relate to systems using one or more traffic streams.

Embodiments of the invention also include a data signal, which is a signal within the described device, in particular (although not exclusively), a signal passing from the host device to the CAM module or set of CAM modules, or a feedback signal. A storage medium, such as a memory by which such a signal is stored, is also considered an embodiment of the invention. The storage medium may be, for example, a non-volatile computer-readable storage medium.

In the context of FIG. 24, an example of such a signal is an audio-video data signal comprising a composite packet data stream having program data of two or more packet data streams having a subset of data packets of two or more received packet data streams, a subset including audio-video data packets, which relate to those programs that are decoded, and service data, including protected authorization information for content receivers, service data, which is digitally applied th security indicator.

When it comes to at least partial implementation of the invention using a software-controlled processing device, it should be understood that such software and the media on which the software is provided (such as a non-volatile machine-readable storage medium, for example, a magnetic or optical disk or non-volatile memory ) are also considered embodiments of the present invention.

The following embodiments of the invention provide for the use of the above distinguishing features in their various combinations.

Embodiments of the invention may provide a method for operating an audio-video content receiver having a content decoder suitable for decoding an audio-video program from a packet data stream using data packets defining decryption information, the method comprising the following steps:

the step of receiving encoded audio-video content in the form of a packet data stream containing one or more programs having data packets identifiable by the corresponding sets of one or more packet identifiers, and containing programs for constructing identification data matching the corresponding sets of packet identifiers;

the step of selecting data packets from the packet data stream for the desired program in accordance with the set of packet identifiers defined by the identification data for this stream with respect to the desired program;

the step of selecting additional data packets from the packet data stream from which a program is selected having packet identifiers not included in the identification data for this packet data stream;

the step of generating a composite stream of packetized data from the selected packets;

a step of generating identification data of the composite stream indicating the identifiers of packets included in the composite stream of packetized data; and

the step of supplying the composite packet data stream to the content decoder for decoding the program from the composite packet data stream in accordance with the packet identifiers contained in the identification data of the composite stream.

Embodiments of the invention may provide a method of operating an audio-video content receiver having a content decoder suitable for simultaneously decoding two or more audio-video programs from a single packet data stream, the method comprising the following steps:

the step of receiving encoded audio-video content in the form of two or more streams of packet data, each stream containing one or more programs having data packets identified by the corresponding sets of one or more packet identifiers, each packet data stream containing identification matching programs data to the corresponding sets of packet identifiers;

the step of generating a composite packet data stream containing program data from two or more packet data streams by:

assigning one of the packet data streams from which program data should be decoded as the primary packet data stream, and other packet data streams from which program data should be decoded, as secondary packet data streams;

selecting data packets from the packet data stream for each desired program in accordance with the sets of packet identifiers determined by the identification data for this stream with respect to the desired program;

mapping identifiers of at least those packets that were selected from the secondary packet data stream (s) and which have packet identifiers identical to packet identifiers from another packet data stream and other corresponding packet identifiers, and not mapping identifiers of those packets that were selected from the primary packet data stream; and

a step of generating identification data of the composite stream defining identifiers of data packets in the composite stream of packetized data;

a step of decoding two or more programs from the composite packet data stream in accordance with packet identifiers contained in the composite stream identification data;

the step of reassigning the packet data stream from the primary to the secondary packet data stream in response to detecting a choice of another program for decoding from the primary packet data stream or selecting to receive another packet data stream instead of the primary packet data stream.

Embodiments of the invention may provide a method of operating an audio-video content receiver having a content decoder suitable for simultaneously decoding two or more audio-video programs from a single packet data stream by using data packets defining decryption information, the method comprising the following steps:

the step of receiving encoded audio-video content in the form of two or more streams of packetized data, each stream containing one or more programs having data packets identifiable by the corresponding sets of one or more packet identifiers, each stream of packetized data containing identification mapping programs data corresponding sets of packet identifiers and service data, including information on the secure authorization of content receivers;

the step of generating a composite packet data stream comprising program and service data from two or more packet data streams;

the step of applying the digital security indicator to at least the service data included in the composite packet data stream;

the step of supplying the composite packet data stream to a content decoder for decoding two or more programs from the composite packet data stream in accordance with packet identifiers contained in the composite stream identification data;

the step of receiving service data from the content decoder;

the step of determining the reliability of the digital security indicator used for service data; and

the step of determining whether the content receiver is authorized to decode the received program data in response to the service data.

Embodiments of the invention may provide a method for operating an audio-video content receiver having a content decoder suitable for simultaneously decoding two or more audio-video programs from a single packet data stream consisting of encoded audio-video data packets, the method comprising the following steps:

the step of receiving encoded audio-video content in the form of two or more streams of packetized data, wherein each data stream contains one or more programs having respective encoded packets of audio-video data;

the step of generating a composite packet data stream containing program data from two or more packet data streams by selecting a subset of the data packets from two or more received packet data streams, the subset containing audio-video data related to those programs to be decoded;

a step of storing clock information indicating at least the arrival time of those audio-video data packets that are included in the composite packet data stream; and

the step of decoding and outputting the audio-video program data from the composite packet data stream in accordance with the time metrics stored for each decoded audio-video packet.

In embodiments of the invention, an audio-video content receiver may be provided for receiving and decoding signals with audio-video data transmitted over data channels, wherein at least one data channel carries not viewed information, a receiver comprising:

a tuner that can simultaneously tune to two or more data channels;

a multiplexer designed to generate a composite data signal from the received audio-video signals related to the program required for decoding;

a content decoder suitable for simultaneously decoding two or more audio-video programs from a composite data signal;

a detector designed to detect if one or more tuned data channels are used to provide a program for decoding;

a controller that responds to the detection that the data channel is not currently being used to control the tuner in order to tune this channel to a transmission channel that carries unplayable information; and

non-viewable decoder for decoding received non-viewable information.

Embodiments of the invention may provide a method of operating an audio-video content receiver having a content decoder suitable for decoding an audio-video program from a packet data stream by using data packets defining decryption information, the method comprising the following steps:

the step of receiving encoded audio-video content in the form of streams of packet data containing one or more programs having data packets identifiable by the corresponding sets of one or more packet identifiers, and a program for constructing correspondence of identification data to the corresponding sets of packet identifiers;

the step of selecting data packets from the packet data stream for each desired program in accordance with the set of packet identifiers determined by the identification data for this stream with respect to the desired program;

the step of selecting additional data packets from each packet data stream from which a program is selected that contains the data of the master clock related to the selected program, if the data of the master clock of the program is not included in the packets related to the selected program;

the step of generating a composite stream of packetized data from the selected packets; and

a step of generating identification data of the composite stream defining identifiers of data packets in the composite stream of packetized data; and

the step of supplying the composite stream of packetized data to the content decoder for decoding in accordance with the data of the master clock of the program and the packet identifiers contained in the identification data of the composite stream.

Obviously, in light of the above ideas, numerous modifications and variations of the subject matter of the present invention are possible. Therefore, it is understood that, within the scope of the appended claims, the technology mentioned may be carried out in other ways than specifically described herein.

Claims (16)

1. The method of operation of the receiver of audio-video content containing a content decoder, configured to decode an audio-video program from a packet data stream using data packets defining decryption information, the method comprising the steps of:
receive encoded audio-video content in the form of a packet data stream containing one or more programs containing data packets identifiable by means of respective sets of one or more packet identifiers and containing identification data establishing correspondence between programs and corresponding sets of packet identifiers;
selecting from the packet data stream data packets for the desired program in accordance with the set of packet identifiers determined by the identification data for said stream with respect to the desired program;
selecting additional data packets from the packet data stream from which the program is selected containing packet identifiers not included in the identification data for said packet data stream;
generating a composite stream of packetized data from the selected packets;
generating a composite stream identification data indicating identifiers of packets included in the composite packet data stream; and
supplying the composite packet data stream to a content decoder for decoding a program from the composite packet data stream in accordance with the packet identifiers in the identification data of the composite stream. 2. The method according to p. 1, comprising the step of selecting from each packet data stream from which the program is selected, additional data packets containing program defining clock data related to the selected program. 3. A method according to claim 1 or 2, comprising the step of including the identity of the composite stream in the composite stream of packetized data. 4. The method according to p. 1 or 2, in which:
a content decoder is configured to simultaneously decode two or more audio-video programs from a single packet data stream;
at the same time, at the stage of generating a composite packet data stream, a composite packet data stream is formed from packets representing two or more programs. 5. The method according to p. 4, in which:
at the receiving stage, two or more packet data streams are received;
apply selection steps to each packet data stream from which the program is selected;
the composite packetized data stream contains program data from two or more packetized data streams; and
in the step of generating a composite packet data stream, the selected packets are combined into a composite packet data stream. 6. The method according to claim 5, comprising the step of establishing a correspondence between packet identifiers selected from at least one packet data stream and packet identifiers that are different from them. 7. The method according to p. 6, containing stages in which:
designate one of the received packet data streams as the primary packet data stream, and the remaining received packet data streams as secondary packet data streams; and
they match the packet identifiers from the secondary packet data streams and do not match packet identifiers from the primary packet data stream. 8. The method according to p. 5, containing a stage on which:
identify the source of each selected packet by inserting additional information at the beginning of each packet included in the composite packet data stream. 9. The method according to p. 1 or 2, containing stages in which:
indicate by the content decoder that the content decoder requires packets from the packet data stream with a specific packet identifier not included in the identification data for said packet data stream; and
packets with said packet identifier are selected from said packet data stream for inclusion with the composite packet data stream. 10. A storage medium storing a computer program, which when executed by a computer causes the computer to execute the method according to any one of paragraphs. 1-9. 11. A receiver of audio-video content containing:
a content decoder fired to decode the audio-video program from the packet data stream using data packets defining decryption information;
a tuner configured to receive encoded audio-video content in the form of a packet data stream containing one or more programs containing data packets identifiable by the corresponding sets of one or more packet identifiers and containing identification data establishing correspondence between the programs and corresponding sets package identifiers;
a selection unit configured to select from the packet data stream data packets for the desired program in accordance with the set of packet identifiers determined by the identification data for said stream with respect to the desired program and select additional data packets from the packet data stream from which the program is selected, containing packet identifiers not included in the identification data for said packet data stream; and
a composite packet data stream generator, configured to generate a composite packet data stream from the selected packets and generate a composite stream identification data indicating identifiers of packets included in the composite packet data stream;
wherein said content decoder is adapted to receive a composite packet data stream coming from the composite packet data generator to decode the program from the composite packet data stream in accordance with packet identifiers contained in the composite stream identification data. 12. The receiver according to claim 11, in which the selection unit is configured to select additional data packets from each packet data stream from which the program is selected, containing program defining clock data related to the selected program. 13. The receiver of claim 11 or 12, wherein the content decoder comprises two or more series-connected content decoders. 14. The receiver of claim 11, wherein the composite packet stream data generator is configured to include the composite stream identification data in the composite packet data stream. 15. The receiver according to claim 11, characterized in that it is configured to:
receiving two or more streams of packetized data;
wherein the selection unit is configured to work with each packet data stream from which the program is selected;
the composite packetized data stream contains program data from two or more packetized data streams; but
the composite packet data stream generator is configured to combine selected packets to form a composite packet data stream. 16. The receiver of claim 15, wherein the composite packet data generator is configured to identify the source of each selected packet by inserting additional information at the beginning of each packet of the composite data stream.

Images