BR112014023251A2 - método de operação de um receptor de conteúdo de áudio/vídeo, software de computador, mídia de armazenamento, receptor de conteúdo de áudio/vídeo, e, sinal de dados de dados de áudio/vídeo - Google Patents

método de operação de um receptor de conteúdo de áudio/vídeo, software de computador, mídia de armazenamento, receptor de conteúdo de áudio/vídeo, e, sinal de dados de dados de áudio/vídeo Download PDF

Info

Publication number
BR112014023251A2
BR112014023251A2 BR112014023251-2A BR112014023251A BR112014023251A2 BR 112014023251 A2 BR112014023251 A2 BR 112014023251A2 BR 112014023251 A BR112014023251 A BR 112014023251A BR 112014023251 A2 BR112014023251 A2 BR 112014023251A2
Authority
BR
Brazil
Prior art keywords
data
stream
packaged
composite
program
Prior art date
Application number
BR112014023251-2A
Other languages
English (en)
Inventor
Sri Gopikanth Gutta
David Hill-Jowett
Paul Szucs
Original Assignee
Sony Corporation
Sony Europe Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation, Sony Europe Limited filed Critical Sony Corporation
Publication of BR112014023251A2 publication Critical patent/BR112014023251A2/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42623—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific decryption arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/418—External card to be used in combination with the client device, e.g. for conditional access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/418—External card to be used in combination with the client device, e.g. for conditional access
    • H04N21/4181—External card to be used in combination with the client device, e.g. for conditional access for conditional access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/4263—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific tuning arrangements, e.g. two tuners
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4344—Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43607—Interfacing a plurality of external cards, e.g. through a DVB Common Interface [DVB-CI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities

Abstract

  MÉTODO DE OPERAÇÃO DE UM RECEPTOR DE CONTEÚDO DE ÁUDIO/VÍDEO, MEIO DE ARMAZENAMENTO EM MEMÓRIA, RECEPTOR DE CONTEÚDO DE ÁUDIO/VÍDEO, E, SINAL DE DA DOS DE ÁUDIO/VÍDEO. É descrito um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem informação de desencriptação que compreende as etapas de: receber conteúdo de áudio/vídeo codificado como um fluxo contínuo de dados empacota do que compreende um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote e que compreende dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; selecionar pacotes de da dos a partir do fluxo contínuo de dado empacotado para um programa exigi do de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; selecionar pacotes de dados adicionais a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado; gerar um fluxo contínuo de dados empacotado composto a partir dos pacotes selecionados; gerar dados de identificação do fluxo contínuo composto que indicam identificadores de pacote dos pacotes incluídos no fluxo contínuo de dados empacotado composto; e suprir o fluxo contínuo de dados empacotado composto para o decodificador de conteúdo para decodificação do programa a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote nos dados de identificação do fluxo contínuo composto.

Description

“MÉTODO DE OPERAÇÃO DE UM RECEPTOR DE CONTEÚDO DE ÁUDIO/VÍDEO, MEIO DE ARMAZENAMENTO EM MEMÓRIA, RECEPTOR DE CONTEÚDO DE ÁUDIO/VÍDEO, E, SINAL DE DADOS DE ÁUDIO/VÍDEO” REFERÊNCIA CRUZADA A PEDIDO RELACIONADO
[0001] O presente pedido reivindica o benefício da data de depósito anterior de GB1205296.5, depositado no United Kingdom Intellectual Property Office em 26 de março de 2012, cuja íntegra do conteúdo do pedido é aqui incorporada pela referência.
FUNDAMENTOS Campo
[0002] Esta descrição refere-se à recepção de conteúdo de áudio/vídeo. Descrição da Tecnologia Relacionada
[0003] A descrição dos "fundamentos da invenção" aqui provida é com o propósito de apresentar, no geral, o contexto da descrição. O trabalho dos inventores atualmente nomeados, até o limite em que ele é descrito nesta seção de fundamentos da invenção, bem como aspectos da descrição que podem, em outras circunstâncias, não qualificar como tecnologia anterior no momento do depósito, não são nem expressamente nem implicitamente admitidos como tecnologia anterior em relação à presente descrição.
[0004] Como fundamentos da invenção, a especificação da Interface Comum DVB ("CI") permitiu que um receptor de televisão ou receptor / decodificador integrado (um "hospedeiro") interagissem com um módulo de hardware seguro (um módulo de acesso condicional ou "CAM") para permitir que o hospedeiro desencripte conteúdo com acesso controlado. A especificação CI define uma interface entre o hospedeiro e o CAM, de forma que os dois trabalhem em conjunto se ambos se conformarem com a especificação CI. Esta interoperabilidade provia um significativo benefício do sistema CI, já que, em princípio, ela permitia aos consumidores uma escolha de produtos compatíveis a partir de diferentes fabricantes.
[0005] Na especificação CI, o CAM interage com um cartão inteligente e/ou um número de identificação pessoal ("PIN") do usuário para prover autenticação do usuário.
[0006] Entretanto, uma desvantagem da especificação CI original é que ela dava o potencial para que o conteúdo digital desencriptado fosse copiado. Este problema surge a partir da maneira na qual o hospedeiro e o CAM interagem. Em uso, o hospedeiro envia dados encriptados para o CAM. O CAM verifica a autenticação do usuário e, considerando que o usuário está autenticado, ele desencripta o conteúdo com acesso controlado. O CAM, então, reenvia o conteúdo desencriptado para o hospedeiro através da interface CAM - hospedeiro, que é, no geral, uma interface PCMCIA (Associação Internacional de Cartão de Memória para Computador Pessoal), embora ela não seja limitada a esta interface - por exemplo, uma interface USB pode ser usada. Esta conexão do CAM no hospedeiro representa um ponto fraco na segurança, em que o conteúdo digital desencriptado pode, em princípio, ser interceptado e ilegalmente copiado. Este ponto fraco na segurança significava que alguns provedores de conteúdo preferiam dispositivos integrados, que têm o hospedeiro e o CAM como uma unidade individual, em virtude disto permitir a eles maior segurança em relação à transferência de dados não encriptados do CAM para o hospedeiro. Entretanto, isto certamente agia contra a vantagem associada com CI, em relação à potencial interoperabilidade de diferentes CAMSs e hospedeiros.
[0007] A especificação CI Plus foi esboçada para abordar estes problemas, por duas principais rotas. CI Plus provê uma segura interface entre o CAM e o hospedeiro, de forma que dados de conteúdo desencriptados não são enviados de forma clara entre os dois dispositivos. Também, CI Plus provê a autenticação tanto do hospedeiro quanto do CAM, em vez da técnica
CI de autenticação apenas do CAM.
[0008] O sistema de autenticação usa hierarquia de certificado, de forma que tanto para o hospedeiro quanto para o CAM devam ter sido emitidos certificados por uma autoridade (tal como CI Plus LLP).
[0009] A interface PCMCIA entre um hospedeiro e um CAM é protegida pela encriptação dos dados de conteúdo desencriptados antes de eles serem enviados do CAM para o hospedeiro e, então, pela desencriptação destes no hospedeiro. Esta encriptação é separada da encriptação - desencriptação de controle de acesso estabelecida pelo provedor de conteúdo, e é específica de cada par CAM - hospedeiro em particular. Chaves são trocadas entre o CAM e o hospedeiro pela técnica de troca de chave Diffie- Hellman. As chaves também são cicladas de tempo em tempo, de forma que, mesmo se uma chave estivesse comprometida, ela seria, em qualquer evento, trocada poucos segundos depois.
[00010] A especificação CI Plus também permite que CAMs sejam conectados em série ou em cadeia margarida.
SUMÁRIO
[00011] Esta descrição provê um arranjo, da forma definida na reivindicação 1.
[00012] Vários respectivos aspectos e recursos adicionais são definidos nas reivindicações anexas.
[00013] Os parágrafos expostos foram providos a título de introdução geral, e não pretende-se que limitem o escopo das seguintes reivindicações. As modalidades descritas, juntamente com vantagens adicionais, serão mais bem entendidas pela referência à seguinte descrição detalhada tomada em conjunto com os desenhos anexos.
BREVE DESCRIÇÃO DOS DESENHOS
[00014] Uma apreciação mais completa da descrição e muitas das vantagens presentes desta serão prontamente obtidas à medida que a mesma torna-se mais bem entendida pela referência à seguinte descrição detalhada das modalidades exemplares quando consideradas em conexão com os desenhos anexos, em que:
a Figura | é um diagrama esquemático de um dispositivo hospedeiro com um CAM e um cartão inteligente;
a Figura 2 é um diagrama esquemático de um sistema de acesso condicional (CA) que incorpora o dispositivo hospedeiro da Figura 1;
a Figura 3 é um diagrama esquemático que ilustra a operação do sistema da Figura 2;
a Figura 4 é um diagrama esquemático do dispositivo hospedeiro que tem múltiplos sintonizadores;
a Figura 5 ilustra esquematicamente um arranjo multiplexador - desmultiplexador;
a Figura 6a ilustra esquematicamente um assim denominado cartão M;
a Figura 6b ilustra esquematicamente um assim denominado cartão S;
a Figura 7 ilustra esquematicamente um pacote do fluxo contínuo de transporte (TS);
a Figura 8 ilustra esquematicamente um pacote de dados de um fluxo contínuo de dados empacotado composto;
a Figura 9 ilustra esquematicamente um arranjo de multiplexador com mais detalhes;
a Figura 10 ilustra esquematicamente pacotes de TS de dois serviços;
a Figura 11 ilustra esquematicamente um conjunto que compreende uma sucessão de CAMs;
a Figura 12 ilustra esquematicamente uma sucessão de CAMs com unidades de interface entre eles;
a Figura 13 é um fluxograma esquemático que ilustra Oo tratamento de assim denominados PIDs fantasmas; a Figura 14 ilustra esquematicamente uma tabela de mapeamento de PID; a Figura 15 ilustra esquematicamente operações envolvidas na detecção de qual CAM de uma sucessão de CAMSs é capaz de decodificar o serviço de programa exigido; a Figura 16 ilustra esquematicamente o controle de múltiplos sintonizadores pelo dispositivo hospedeiro; a Figura 17 ilustra esquematicamente a multiplexação de dois serviços de programa separados; a Figura 18 ilustra esquematicamente um pacote que tem um cabeçalho de pacote aumentado; a Figura 19 ilustra esquematicamente uma tabela de dados de sincronismo de pacote; a Figura 20 ilustra esquematicamente a geração do cabeçalho de pacote da Figura 18; a Figura 21 ilustra esquematicamente o uso do cabeçalho de pacote da Figura 18; a Figura 22 ilustra esquematicamente a geração da tabela da Figura 19; a Figura 23 ilustra esquematicamente o uso da tabela da Figura 19;e a Figura 24 ilustra esquematicamente uma assinatura SDT e um sistema de verificação de assinatura.
DESCRIÇÃO DAS MODALIDADES
[00015] Para estabelecer o contexto técnico das presentes modalidades, um sistema de difusão que tem um único arranjo de sintonizador e decodificador será descrito primeiro em relação às Figuras 1 a 3.
[00016] Agora, em relação à Figura 1, um dispositivo hospedeiro 10 é aqui mostrado como um aparelho de televisão, mas pode ser, por exemplo, um receptor / decodificador integrado (notando que a expressão "set top box" não implica, aos versados na técnica, nenhuma exigência de uma posição física em particular do dispositivo em uso). O dispositivo hospedeiro 10 recebe um sinal de televisão com acesso controlado 15 por meio de um caminho dos dados de difusão. Este pode ser, por exemplo, um sinal de televisão via satélite recebido por uma antena parabólica (não mostrada), um sinal de televisão terrestre, um sinal de televisão a cabo ou congêneres, embora outros tipos de sinal de televisão incluam um sinal de televisão difundido ou transmitido por um sinal em pacote no Protocolo da Internet (IP). Uma técnica é codificar um fluxo contínuo de transporte (TS) MPEG em pacotes IP, de forma que um pacote IP porte inúmeros (por exemplo, 7 ou 8) pacotes de TS. Uma outra técnica codifica o sinal de televisão como um assim denominado arranjo BMFF (Formato de Arquivo de Mídia Base) ISO da (Organização “Internacional para Padrões) descrito na referência: http://en.wikipedia.org/wiki/ISO base media file format, cujos conteúdos são incorporados na presente descrição pela referência. Em tais arranjos, a interface IP em um dispositivo hospedeiro é, no geral, considerada na tecnologia como um "sintonizador", mesmo embora ela possa não ter sistema de circuitos ou funcionalidade de radiofrequência. Entretanto, ela age de uma maneira similar a um sintonizador de radiofrequência em que ela seleciona um fluxo contínuo IP a partir de uma multiplicidade de possíveis fluxos contínuos IP. Ela também pode prover armazenamento temporário do fluxo contínuo IP recebido.
[00017] O dispositivo hospedeiro 10 tem um slot PCMCIA 20 que inclui conexões elétricas e um espaço físico para um módulo de plug-in, ambos de acordo com o padrão PCMCIA. Em outras modalidades, um barramento serial universal (USB) ou outra interface elétrica podem ser usados em vez da interface PCMCIA.
[00018] Um módulo de acesso condicional CI Plus, referido como um CICAM 30, é um módulo PCMCIA que pode ser plugado no slot PCEMCIA
20. Quando o CICAM 30 estiver completamente plugado no slot 20, conexões elétricas são feitas entre conectores no CICAM 30 e conectores cooperantes no slot 20.
[00019] O próprio CICAM pode ser um módulo sem cartão ou pode ter um slot 40 no qual um assim denominado cartão inteligente 50 pode ser inserido. O cartão inteligente é removível e porta informação que define um usuário atual do receptor de conteúdo de uma forma à prova de adulteração, segura e não volátil. Quando o cartão inteligente for completamente inserido no slot 40, uma conexão de dados é formada entre o cartão inteligente 50 e o CICAM 30, tanto pelo uso de conectores elétricos cooperantes no cartão inteligente 50 e no slot 40 quanto pelo uso de uma conhecida técnica de conexão sem contato na qual dados são transferidos sem fios através de um alcance muito curto, tal como 1 - 2 cm.
[00020] A Figura 2 ilustra esquematicamente o dispositivo hospedeiro no contexto de um sistema de acesso condicional. Uma assim denominada central de operações 60 representa a origem do sinal de televisão com acesso controlado 15. A central de operações pode representar, por exemplo, uma estação de ligação ascendente de uma difusora via satélite ou um centro de distribuição de sinal de uma difusora terrestre ou a cabo. O sistema de CA embaralha o conteúdo na central de operações usando uma encriptação do sistema de CA. A central de operações também pode introduzir outra informação relacionada a CA no fluxo contínuo de dados encriptado que habilita o CICAM a desembaralhar o conteúdo e a gerenciar o acesso e os direitos do assinante (do usuário).
[00021] A central de operações 60 envia o sinal de televisão 15 para o hospedeiro 10 que, por sua vez, passa o sinal para o CICAM 30 para desencriptação da encriptação do controle de acesso. O CICAM 30, então, reencripta o sinal usando uma encriptação local e reenvia o sinal reencriptado para o hospedeiro 10 por meio da conexão PCMCIA. O hospedeiro desencripta o sinal recebido a partir do CICAM 30 para exibição em uma tela de exibição ou para suprimento para um outro dispositivo 70, tal como um gravador de vídeo com base em disco rígido.
[00022] A Figura 3 é um diagrama esquemático que ilustra a operação do sistema da Figura 2. A operação detalhada do sistema da Figura 3 é descrita na especificação CI Plus 1.3 (2010-01), disponível (no momento do depósito) em http://www.ci-plus.com/data/ci-plus. specification vl.3.pdf. Este documento é incorporado pela referência na presente descrição. A presente descrição da Figura 3 provê simplesmente uma visão geral desta operação detalhada, com os propósitos de colocar a subsequente descrição no apropriado contexto técnico.
[00023] Como antes, a Figura 3 mostra a central de operações 60 (que recebe um sinal de conteúdo a partir de um provedor de conteúdo 90), o dispositivo hospedeiro 10, o CICAM 30 e o cartão inteligente 50. O sinal 15 é mostrado passando da central de operações 60 para o dispositivo hospedeiro
10. A interface segura 80 entre o dispositivo hospedeiro 10 e o CICAM 30 é referida como a interface comum. Acesso Condicional
[00024] Conhecidos sistemas de CA proveem técnicas pelas quais pode-se negar ou permitir acesso de um usuário a um fluxo contínuo de televisão digital. Acesso é provido apenas para aqueles assinantes ou usuários com contas de pagamento válidas. Em termos práticos, é provido para um usuário um cartão inteligente 50 que identifica este usuário (de forma ideal) de uma maneira à prova de adulteração, e o sistema é configurado de forma que apenas usuários com cartões inteligentes válidos possam obter acesso ao conteúdo com acesso controlado.
[00025] Controle de acesso é provido pelo uso de embaralhamento e encriptação. O sinal de conteúdo é embaralhado com uma palavra de controle de 8 bytes, que é mudada frequentemente (até diversas vezes por minuto) para evitar que o sistema de CA seja comprometido pelo conhecimento externo da palavra de controle. As palavras de controle são transmitidas para o CICAM do receptor, para desembaralhamento do conteúdo embaralhado, de uma forma encriptada como uma mensagem de controle de direito (ECM). O CICAM desencripta a palavra de controle para permitir o desembaralhamento do conteúdo com acesso controlado apenas quando ele for autorizado a fazê- lo pela recepção de uma mensagem de gerenciamento de direito (EMM). EMMs são específicas de cada usuário ou grupo de usuários; o CICAM confirma os direitos que uma EMM provê pela comparação da identificação do usuário provida na EMM com informação do usuário provida no cartão inteligente 50. As EMMs podem ser enviadas menos frequentemente que as ECMSs, com intervalos entre sucessivas EMM;s nos atuais sistemas comerciais variando entre 12 minutos e seis semanas.
[00026] As próprias ECMs e EMMs são tipos de mensagem bem conhecidos em sistemas de distribuição de televisão MPEG. O formato de suas cargas úteis pode ser específico do sistema de CA em uso, com as diferenças entre formatos sendo frequentemente semânticas em vez de ter significância técnica. Em modalidades, os dados da ECM e da EMM são portados em um fluxo contínuo de dados empacotado como pacotes de dados que definem informação de desencriptação e são usados no processo de decodificação para decodificar um programa de áudio/vídeo a partir do fluxo contínuo de dados empacotado. Central de Operações
[00027] A central de operações 60 compreende um encriptador de CA 61, um gerador de chave 62, uma unidade de controle de direito 63 e um multiplexador e modulador 64.
[00028] O provedor de conteúdo 90 supre conteúdo (tais como sinais de televisão) para a central de operações 60. A central de operações 60 aplica embaralhamento e encriptação de acesso condicional (CA) no conteúdo.
[00029] Mais especificamente, o encriptador de CA 61 encripta ou embaralha o conteúdo usando uma chave de CA como uma palavra de controle. A chave de CA é gerada pelo gerador de chave de CA 62. O conteúdo embaralhado gerado pelo encriptador de CA é suprido para o multiplexador e modulador 64.
[00030] A chave de CA também é provida para a unidade de controle de direito 63, que gera ECMs com base nas chaves de CA e EMMs com base em dados do assinante que definem quais assinantes têm direito de desembaralhar quais fluxos contínuos de conteúdo. As ECMs e EMMs são supridas para o multiplexador e modulador 64. Um ou mais fluxos contínuos de conteúdo embaralhados provenientes do encriptador de CA 61, um ou mais fluxos contínuos de conteúdo desembaralhados (acesso aberto ou "livre para o ar") e as mensagens de controle de direito são multiplexados em conjunto para formar um fluxo contínuo de transporte, tal como um fluxo contínuo de transporte MPEG2. Formatos conhecidos são usados para portar os dados de conteúdo, as ECMs e as EMMs. As ECMs, as EMMs e os dados que definem o tipo de embaralhamento usado em cada fluxo contínuo elementar (correspondente a fluxos contínuos de conteúdo embaralhados individuais) são providos em um formato conhecido e são referenciados usando técnicas conhecidas em uma tabela de mapa do programa (PMT) e/ou em uma tabela de acesso condicional (CAT) que tem um identificador de programa predeterminado (PID) de 0x001, de forma que a CAT possa ser reconhecida no CICAM.
[00031] O fluxo contínuo de transporte multiplexado é, então, modulado pelo multiplexador e modulador 64 para transmissão como um sinal de difusão a cabo, via satélite ou terrestre 15.
Dispositivo Hospedeiro
[00032] O dispositivo hospedeiro 10 compreende um sintonizador 11, um desmodulador e desmultiplexador 12, um desmultiplexador ("demux") 13 e um desencriptador de CC (controle de conteúdo) 14. Note que o dispositivo hospedeiro pode ter outras funções adicionais; por exemplo, um dispositivo hospedeiro pode prover dois ou mais de recepção de difusão via satélite, recepção de difusão a cabo, recepção de difusão terrestre e recepção de televisão em rede (IPTV).
[00033] Dependendo do tipo de sinal de difusão 15, o sintonizador age para retransformar o sinal recebido em banda base, de forma que o desmodulador e desmultiplexador 12 possa selecionar e desmultiplexar um único fluxo contínuo de conteúdo elementar e dados da CAT associados provenientes do sinal recebido. O fluxo contínuo de conteúdo e dados de ECM / EMM são passados por meio da interface comum 80 para o CICAM
30.
[00034] No caso de dados de conteúdo com acesso controlado, neste estágio, os dados de conteúdo ainda são embaralhados à medida que eles são passados por meio da interface comum 80 para o CICAM 30. Esta parte da transmissão através da interface comum 80 é, portanto, segura em virtude da encriptação de CA.
[00035] Considerando que a ECM e a EMM o permitem, o CICAM 30 desembaralha os dados de conteúdo e os reencripta usando uma encriptação de controle de conteúdo (CC). A maneira na qual isto é feito será descrita a seguir. Os dados de CC encriptados são retornados para o dispositivo hospedeiro 10, onde eles são desmultiplexados pelo demux 13 e desencriptados pelo desencriptador de CC 14, de forma que eles possam ser exibidos ou passados para um outro dispositivo 70 como conteúdo claro.
[00036] Portanto, o dispositivo hospedeiro opera para receber conteúdo de áudio/vídeo e tem um decodificador de conteúdo (o módulo de CAM, por exemplo) capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado (tal como um TS) pelo uso de pacotes de dados (tal como EMM / ECM) que definem a informação de desencriptação. O TS recebido pode compreender um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de identificadores de pacote (tais como PIDs) e que compreendem dados de identificação (PAT, PMT, CAT e congêneres) que mapeiam programas para respectivos conjuntos dos PIDs.
CICAM
[00037] O CICAM 30 compreende um desencriptador de CA 31, um gerador de chave de CA 32, um encriptador de CC 33 e um gerador de chave de CC 34.
[00038] O desencriptador de CA 31 e o gerador de chave de CA 32 podem ser considerados como uma unidade de controle de acesso para decodificação de conteúdo de difusão com acesso controlado ou outros dados. O gerador de chave de CC 34 e o encriptador de CC 33 do CICAM 30, e o desmultiplexador 13 e o desencriptador de CC 14 do dispositivo hospedeiro cooperam para prover uma ligação de comunicação encriptada (a interface comum 80) para conteúdo de difusão codificado com acesso controlado decodificado, entre o CICAM e o dispositivo hospedeiro.
[00039] O desencriptador de CA 31 usa chaves geradas a partir das ECMs e EMMs recebidas pelo gerador de chave de CA 32, usando verificações da identidade do usuário proveniente do cartão inteligente 50, para desembaralhar o conteúdo com acesso controlado recebido. Esta parte da operação do CICAM usa técnicas de CA conhecidas para recuperar e aplicar as chaves de CA.
[00040] Dados de conteúdo claro são passados do desencriptador de CA 31 para o encriptador de CC 33. Entretanto, como esta transferência de dados é integralmente interna ao CICAM, ela pode se tornar segura e à prova de adulteração por técnicas conhecidas, tais como pela provisão do desencriptador de CA 31, do encriptador de CC 33 e da interface de conteúdo claro em um único dispositivo de circuito integrado.
[00041] O encriptador de CC 33 encripta o conteúdo desembaralhado usando uma chave de CC suprida pelo gerador de chave de CC 34. Esta chave é estabelecida por um intercâmbio seguro entre o CICAM 30 e o dispositivo hospedeiro 10, e é específica deste par CICAM - dispositivo hospedeiro. O conteúdo encriptado com CC é passado através da interface comum 80 para o dispositivo hospedeiro 10. Portanto, esta parte da interface comum também é segura, já que os dados de conteúdo são encriptados com CC à medida que eles passam para o dispositivo hospedeiro. Troca de Chave
[00042] Tanto o CICAM 30 quanto o dispositivo hospedeiro 10 contêm lógica, software embarcado ou software que proveem algoritmos para troca segura de chave Diffie-Hellman (DH), dispersão e encriptação usando os conhecidos algoritmos SHA-256, DES e AFES, respectivos certificados emitidos por uma autoridade certificadora, tal como CI Plus LLP, e chaves privadas com as correspondentes chaves públicas.
[00043] Quando o CICAM 30 for associado primeiro com o dispositivo hospedeiro 10, o CICAM 30 inicia um processo de autenticação com o dispositivo hospedeiro 10. Neste processo, cada dispositivo verifica o certificado do outro, e o processo de troca de chave DH ocorre para compartilhar seguramente chaves entre os dois dispositivos. Em particular, o CICAM, primeiro, solicita que o dispositivo hospedeiro proveja seus dados de certificado. O CICAM verifica a assinatura no certificado do dispositivo hospedeiro. O mesmo processo é, então, realizado pelo hospedeiro que solicita e verifica o certificado do CICAM. Então, cada um do CICAM e do hospedeiro demonstra que eles possuem a chave privada correspondente à chave pública no certificado pela assinatura de uma chave pública DH e envio desta para o outro dispositivo para validação. O CICAM, então, obtém e verifica uma chave de autenticação AKH proveniente do hospedeiro. O CICAM e o hospedeiro começam a computar e trocar dados de chave para a encriptação e a autenticação dos dados enviados através da interface comum
80. Desta maneira, a chave, o par de chave ou outra informação de chave estabelecida pelo CICAM e pelo hospedeiro para comunicação através da interface comum 80 é específica deste par CICAM - hospedeiro.
[00044] Depois da autenticação, o CICAM também começa a computar a chave de CC. O CICAM também pode instruir o dispositivo hospedeiro a computar a chave de CC. A chave de CC é, então, usada da forma supradescrita para encriptar dados de conteúdo passados do CICAM 30 para o dispositivo hospedeiro 10, de acordo com o algoritmo AES. Portanto, será entendido que as chaves usadas para a interface comum segura 80 são específicas de um par CICAM - hospedeiro em particular.
[00045] Serão agora descritas modalidades de exemplo nas quais múltiplos sintonizadores são usados, embora muitas das técnicas também sejam aplicáveis em arranjos nos quais somente um sintonizador é provido.
[00046] A Figura 4 é um diagrama esquemático de um dispositivo hospedeiro 100 que tem múltiplos sintonizadores ilustrados como sintonizador A 102 e sintonizador B 104, cada qual recebendo um sinal de entrada de radiofrequência (RF). O sinal de entrada de RF pode ser um sinal comum 106 processado por cada um dos múltiplos sintonizadores para, talvez, um respectivo sinal diferente para diferentes sintonizadores (por exemplo, um sintonizador pode operar em relação a televisão de difusão terrestre e um outro sintonizador pode operar em relação a televisão de difusão via satélite). O sistema não é limitado a dois sintonizadores; os princípios a serem descritos podem ser estendidos para mais de dois sintonizadores, mas apenas dois são mostrados na Figura 4 por objetividade do diagrama.
[00047] Cada um dos sintonizadores 102, 104 supre uma saída para um respectivo desmodulador 108, 110. A saída pode representar dados, tal como um fluxo contínuo de dados empacotado ou TS, transmitidos por um único respectivo canal de transmissão, selecionado (a partir de uma pluralidade de canais de transmissão sintonizáveis) por este sintonizador. —Os desmoduladores operam da forma supradescrita (em relação ao desmodulador 12 da Figura 3) para desmodular um sinal de dados empacotado proveniente da saída do respectivo sintonizador. Os sinais de dados empacotados provenientes dos múltiplos desmoduladores 108, 110 são multiplexados em conjunto por um controlador de CI 112 para tratamento por um conjunto de um ou mais CAMs 114 como um conjunto conectado em série de dois ou mais decodificadores de conteúdo. Diferentes opções para implementar o conjunto de CAMs 114 serão discutidas a seguir, mas, em um nível técnico básico, o conjunto de CAMs 114 é capaz de decodificar concorrentemente mais de um serviço de programa para transmissão. Por exemplo, o conjunto de CAM;s pode ser arranjado para decodificar o mesmo número de serviços de programa concorrentemente, já que há sintonizadores providos no dispositivo hospedeiro 100.
[00048] Dados decodificados recebidos de volta a partir do conjunto de CAMs 114 são desmultiplexados pelo controlador de CI 112 em respectivos sinais 116, 118 que representam os serviços de programas exigidos. Estes são passados para desmultiplexadores de programa 120, 122 com função similar ao desmultiplexador 13 da Figura 3.
[00049] Finalmente, cada serviço de programa é preparado para transmissão por um respectivo decodificador 124, 126 com função correspondente ao desencriptador de CC 14 da Figura 3. Os decodificadores 124, 126 geram respectivos sinais de áudio/vídeo de saída 128, 130.
[00050] O dispositivo hospedeiro da Figura 4 opera sob o controle de uma unidade de processamento central (CPU) 132 que, por sua vez, pode ser um dispositivo processador programável que opera de acordo com software ou software embarcado armazenado em uma memória 134 (que, por sua vez, pode ser uma memória legível por máquina não temporária, tal como um armazenamento em disco magnético ou ótico ou uma memória semicondutora não volátil).
[00051] A Figura 5 ilustra esquematicamente um arranjo multiplexador - desmultiplexador que forma parte da funcionalidade do controlador de CI 112 da Figura 4.
[00052] Em termos básicos, como parte da funcionalidade do controlador de CI 112, pelo menos respectivas partes dos sinais de dados empacotados provenientes dos desmoduladores 108, 110 são combinadas por um multiplexador 140 em um sinal de dados empacotado composto a ser passado para o conjunto de um ou mais CAMs 114, e uma versão decodificada do sinal de dados empacotado composto é recebida por um desmultiplexador 142 que o desmultiplexa nos respectivos sinais 116, 118 para decodificação. Há, entretanto, diferentes maneiras nas quais isto pode ser alcançado.
[00053] Os sinais de dados empacotados transmitidos pelos dois desmoduladores 108, 110 podem representar assim denominados fluxos contínuos de transporte (TS) e, normalmente, incluirão pacotes de dados em relação a diversos serviços de programa de áudio/vídeo juntamente com vários pacotes de manutenção e controla. Por exemplo, um único sinal de dados empacotado pode incluir pacotes em relação a entre 3 e 10 serviços de programa, embora a escolha de quantos serviços de programa são representados por um TS individual seja mais uma escolha comercial do que uma escolha técnica; um TS provê uma certa quantidade de largura de banda de dados, mas, então, é uma escolha comercial pelo difusora quantos serviços de programa devem ser adequados nesta largura de banda disponível. A fim de codificar um número mais alto de serviços de programa em uma dada largura de banda, a qualidade de codificação (que refere-se à qualidade da saída dos sinais de áudio e vídeo reproduzidos experimentada por um visualizador) de cada serviço de programa deve ser abaixada. Mas, em qualquer evento, é provável que, em uso normal, cada um dos sinais de dados empacotados gerados por um dos desmoduladores 108, 110 contenha pacotes de dados diferentes daqueles exigidos para decodificar um serviço de programa desejado em particular.
[00054] Surge, então, uma escolha técnica, em que é possível, pelo menos em princípio, que o controlador de CI 112 simplesmente combine os múltiplos sinais de dados empacotados transmitidos pelos desmoduladores 108, 110, de maneira tal que toda a informação contida em cada sinal de dados empacotado seja retida. Isto proporcionará um sinal de dados empacotado composto com uma largura de banda de dados da ordem de nx a largura de banda de um TS individual, em que n é o número de TSs individuais que são multiplexados em conjunto pelo multiplexador 140. Um problema em potencial com este tipo de arranjo é que os CAMs 114 pode não ser capaz de tratar uma alta taxa de dados do sinal de dados empacotado como esta. Um motivo em potencial é que os CAMs podem ser desenhados para uso compatível em relação a somente um único sinal de dados empacotado.
[00055] Desta maneira, em outros arranjos, um respectivo subconjunto de pacotes de dados é extraído a partir de cada um dos sinais de dados empacotados transmitidos pelos desmoduladores 108, 110, e o sinal de dados empacotado composto a ser suprido para o conjunto de um ou mais CAMs 114 é formado a partir de uma combinação destes respectivos subconjuntos. Técnicas para formar esta combinação a fim de gerar o sinal de dados empacotado composto serão discutidas adicionalmente a seguir.
[00056] Dois tipos de CAM são relevantes para a presente discussão. À Figura 6a ilustra esquematicamente um assim denominado cartão M (múltiplos fluxos contínuos) 150, e a Figura 6b ilustra esquematicamente um assim denominado cartão S (fluxo contínuo individual) 160.
[00057] Uma principal diferença técnica entre estes dois tipos de CAM é como segue. O cartão M 150 é uma unidade individual capaz de desencriptar concorrentemente mais de um serviço de programa encriptado. Isto representa uma implementação do sistema de CAM mais moderna que o cartão S, que compreende mais de um dispositivo legado capaz de desencriptar apenas um serviço de programa a partir de um TS. Note que um cartão M pode operar tanto em um modo de múltiplos fluxos contínuos quanto em um modo de único fluxo contínuo (cartão S). Um cartão S pode operar apenas em um modo de único fluxo contínuo.
[00058] A Figura 7 ilustra esquematicamente um pacote do fluxo contínuo de transporte (TS) 170. Os pacotes compreendem uma parte de cabeçalho de 4 bytes 172 e uma parte de carga útil de 184 bytes 174. Este é um formato padrão para pacotes de TS, e um TS é formado por uma sucessão de pacotes desta forma. A parte de cabeçalho 172 inclui um identificador de pacote ou PID. Cada serviço de programa de áudio/vídeo tem um conjunto associado de dois ou mais PIDs. Por exemplo, um PID pode ser associado com pacotes de vídeo de um serviço de programa, um outro PID pode ser associado com pacotes de áudio do serviço de programa e um PID adicional pode ser associado com pacotes de controle de encriptação do serviço. Portanto, em um único TS, muitos PIDs diferentes podem estar em uso. À alocação de PIDs em diferentes tipos de pacotes é tratada por uma tabela de alocação de programa (PAT) e uma tabela de mapa do programa (PMT). À própria PAT tem um PID de O e funciona para indicar o PID dos pacotes que portam a PMT. A PMT indica os PIDs dos pacotes que portam dados de vídeo e de áudio, bem como o PID dos pacotes que portam os dados da ECM para um serviço. Para completude, uma tabela de acesso condicional (CAT) tem um PID de 1 e indica quais pacotes portam os dados da EMM para um ou mais sistemas de controle de acesso.
[00059] Os PIDs são exclusivamente definidos em um único TS, em uma faixa de 13 bits (O até 8.191 em decimal). Entretanto, de TS para TS, os dados representados por um valor de PID em particular podem ser ambíguos. Isto é, valores de PID podem ser reusados através de diferentes TSs. No caso em que múltiplos TSs forem multiplexados em conjunto pelo multiplexador 140, um mecanismo é necessário para superar esta ambiguidade em potencial na alocação de valores de PID.
[00060] Uma técnica para alcançar este fato é descrita em US-B-
7.394.834, cujos conteúdos são incorporados na presente descrição pela referência. Neste documento, pacotes que representam serviços desejados são extraídos a partir de múltiplos TSs de entrada, e os PIDs para pacotes extraídos a partir de pelo menos um dos TSs são remapeados para novos valores de PID que não são usados em relação a quaisquer dados extraídos a partir do outro TS. O processo de remapeamento envolve substituir um valor de PID com um outro valor de PID, com um registro ou uma tabela de remapeamento que são mantidos, de forma que o serviço desejado possa ser identificado a partir dos novos (remapeados) valores de PID. Este arranjo pode ser usado para gerar um pseudo-TS, isto é, um TS artificialmente produzido, presente apenas no dispositivo hospedeiro, mas que parece (a partir do ponto de vista de um cartão S) satisfazer todas as exigências de formato de um TS de difusão. Isto é, o pseudo-TS pode ser decodificado por um cartão S como se ele tivesse sido difundido desta forma, mesmo embora ele seja, de fato, gerado no dispositivo hospedeiro pela combinação de partes de múltiplos TSs de difusão.
[00061] Uma outra técnica é usar um pré-cabeçalho, que é inserido no início de cada pacote de TS e que provê informação adicional em relação à origem deste pacote. Esta técnica é usada durante o envio de dados para cartões M que operam no modo de múltiplos fluxos contínuos. Um exemplo de um pacote de TS com um pré-cabeçalho 176 é mostrado esquematicamente na Figura 8.
[00062] O pré-cabeçalho 176 compreende 12 bytes de dados adicionais e é pré-pendente pelo hospedeiro em cada pacote enviado para um cartão M. Isto é, ele é adicionado antes do início de cada pacote. Os 12 bytes de dados adicionais compreendem vários campos, incluindo um identificador do fluxo contínuo de transporte local, que identifica o TS a partir do qual os pacotes foram derivados, um registro de tempo local, dados de detecção de erro para detecção de erros no pré-cabeçalho, e campos de dados reservados para uso posterior ou proprietário. De forma importante para os presentes propósitos, o identificador do fluxo contínuo de transporte local significa que, mesmo na situação em que pacotes em um fluxo contínuo de dados empacotado composto tiverem valores de PID conflitantes, eles ainda podem ser distinguidos por seus valores do identificador do fluxo contínuo de transporte local no pré-cabeçalho.
[00063] Note que um cartão M exige que o pré-cabeçalho adicional esteja presente. Um cartão S não pode operar com o pré-cabeçalho adicional presente.
[00064] Então, em um outro arranjo, o multiplexador 140 combina pacotes tomados a partir de múltiplos TSs em um fluxo contínuo de dados empacotado composto adequado para uso por um cartão M, pré-pendente o pré-cabeçalho adicional em cada tal pacote na dependência pelo menos da identidade do TS a partir do qual este pacote se originou.
[00065] A Figura 9 ilustra esquematicamente um arranjo de multiplexador com mais detalhes. O arranjo de multiplexador da Figura 9 é relevante para um arranjo no qual um pseudo-TS é gerado para decodificação por cartões S e por cartões M que operam no modo de fluxo contínuo individual.
[00066] Cada fluxo contínuo de transporte de entrada é passado para um respectivo seletor do PID 180, 182 que consulta a tabela de alocação de programa 184, 186 associada com este TS e os dados 188, 190 que definem um serviço de programa exigido, para estabelecer os PIDs que exige-se que sejam passados para decodificação (de um serviço de programa exigido) como parte do sinal de dados empacotado composto.
[00067] Em modalidades, os seletores 180, 182 são operáveis para fazer um ou mais dos seguintes: para selecionar pacotes de dados a partir do fluxo contínuo de dados empacotado para um programa exigido de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; para selecionar pacotes de dados adicionais a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado; e para selecionar pacotes de dados adicionais a partir de cada fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que contém dados de referência do relógio do programa em relação ao programa selecionado.
[00068] Estes recursos da operação dos seletores serão adicionalmente descritos a seguir.
[00069] Os dados 188, 190 que definem um serviço de programa exigido podem ser providos pela CPU 132, por exemplo, possivelmente, em resposta a um controle do usuário de um controle remoto (não mostrado) ou outro controle da interface de usuário (não mostrado) ou, possivelmente, em resposta a um controle da máquina, por exemplo, proveniente de um dispositivo de gravação de vídeo que opera em um modo de temporizador e que exige que um certo serviço de programa seja recebido durante um intervalo de tempo pré-definido para gravação. Uma unidade 192, 194 para cada TS descarta pacotes "indesejados", isto é, pacotes que não têm PIDs definidos pela seleção feita e pelos seletores 180, 182. Um remapeador do PID 196, 198 é usado para remapear os PIDs de um dos TSs para novos valores de PID para evitar qualquer sobreposição em potencial com valores de PID do outro TS. Note que remapeamento não precisa ocorrer em instâncias em que não há sobreposição (múltiplos usos) de PIDs como entre os diferentes TSs, embora, em modalidades, todos os PIDs pelo menos dos pacotes selecionados dos TSs secundários possam ser remapeados para respectivos PIDs diferentes. Note também que a operação de remapeamento não precisa ser realizada em relação a ambos os TSs (ou, se mais de dois estiverem em consideração, cada TS) e, de fato, em modalidades, um dos TSs é tratado como um assim denominado TS "primário" para o qual remapeamento de PID não ocorre. Por flexibilidade, entretanto, um remapeador 196, 198 é provido em relação a cada TS para uso possível quando exigido. Note também que apenas aqueles PIDs que exibem um conflito (o mesmo número do PID que um PID de um outro TS) precisam ser remapeados, embora outros PIDs também possam ser remapeados. Em modalidades, PIDs provenientes de um ou mais TSs "secundários" são candidatos para remapeamento, mas PIDs provenientes de um TS primário não são candidatos para remapeamento.
[00070] Em modalidades adicionais, os seletores 180 podem ser arranjados para incluir em sua seleção assim denominados pacotes de referência do relógio do programa, de forma que estes pacotes sejam incluídos no fluxo contínuo de dados empacotado composto.
[00071] Como fundamentos, dados de referência do relógio do programa (PCR) são usados para prover informação de sincronismo para a decodificação de dados de áudio e de vídeo em um TS. Os dados de PCR são relativamente pequenos e, de fato, são incluídos em pacotes de TS em um assim denominado campo de adaptação. O campo de adaptação fica posicionado na carga útil de 184 bytes 174 (Figura 7), mas em termos de função, age mais como uma extensão (na área da carga útil 174) do cabeçalho. Para sinalizar a presença de um campo de adaptação, o cabeçalho porta um indicador tipo flag (tal como um indicador de um bit). Há, então, um arranjo de sinalização adicional associado com um campo de adaptação para indicar, por sua vez, que o campo de adaptação inclui dados de PCR. Então, os seletores 180 podem detectar um pacote que porta dados de PCR, primeiro, pela verificação do indicador "um campo de adaptação está presente" no cabeçalho de pacote e, então, pela verificação do indicador "o campo de adaptação porta dados de PCR" associado com o campo de adaptação.
[00072] A informação de sincronismo indicada pelos dados de PCR é, no geral, comum através de todos os serviços de programa em um TS. Ela é usada pelos decodificadores, de forma que decodificação de conteúdo ocorra de acordo com os pacotes de PCR e os PIDs em relação ao serviço exigido. Então, há, no geral, apenas uma necessidade de prover um conjunto de dados de PCR em um TS. É comum na tecnologia que os dados de PCR para um TS sejam portados por campos de adaptação em pacotes em relação a um serviço de programa arbitrário dos serviços de programa. O PID dos pacotes que portam os dados de PCR para um TS pode ser indicado em um campo PCR PID na PMT.
[00073] Em arranjos em que a íntegra de um TS é passada para um CAM para desencriptação (como em um único sintonizador: arranjo de CAM individual ou um arranjo com um CAM dedicado para cada sintonizador ou origem de TS), o fato que os dados de PCR podem estar em pacotes em relação a um serviço de programa diferente daquele atualmente visualizado ou serviço de programa decodificado não é um problema, em virtude de os dados de PCR ainda estarem disponíveis para o CAM e, então, para o decodificador.
[00074] Mas, nas presentes modalidades, quando um fluxo contínuo de dados empacotado composto for formado como uma combinação de subconjuntos de múltiplos TSs de entrada, com cada subconjunto em relação a um serviço de programa exigido, pode haver situações em que os dados de PCR para um serviço de programa estão ausentes, em virtude de eles serem portados por pacotes em relação a um serviço de programa diferente do serviço de programa selecionado para este TS.
[00075] Para abordar este fato, os seletores 180 podem examinar o assim denominado campo de adaptação de cada pacote e (se um campo de adaptação estiver presente) o indicador dos dados de PCR, de forma que, se o pacote for um pacote que contém dados de referência do relógio do programa, então, o pacote é selecionado se ele se referir a um serviço de programa selecionado ou não. O pacote que contém dados de PCR é incluído na seleção e, então, incluído no fluxo contínuo de dados empacotado composto.
[00076] Os pacotes selecionados e, quando apropriado, remapeados são, então, combinados em um único fluxo contínuo de dados composto por um combinador 200. Por exemplo, isto pode ser por um processo de concatenação, que, em termos gerais, simplesmente significa colocar lado a lado (um depois do outro) no fluxo contínuo de dados composto. Isto não implica necessariamente que os pacotes ficam diretamente adjacentes (pode haver hiatos), nem implica necessariamente nenhuma ordem de pacote em particular.
[00077] O fluxo contínuo de dados empacotado montado usando estas técnicas pode, portanto, conter múltiplas origens de dados de PCR. No geral, pode haver pacotes de dados que contêm dados de PCR que se originam a partir de cada TS a partir do qual um serviço de programa é selecionado para inclusão no fluxo contínuo de dados empacotado composto. Entretanto, o decodificador em relação a cada serviço de programa será capaz de acessar os dados de PCR corretos. Se os dados de PCR forem incluídos em pacotes do serviço de programa para serem decodificados, então, o decodificador usará estes dados de PCR. Se os dados de PCR no TS original estavam incluídos em pacotes em relação a um outro serviço de programa, então, estes pacotes serão incluídos no fluxo contínuo de dados empacotado composto pelo mecanismo supradescrito. Em cada caso, mesmo se remapeamento de PID for usado, os dados PCR PID (remapeados, se necessário) são portados para cada serviço de programa no fluxo contínuo de dados empacotado composto. De fato, um conjunto dos dados da PAT e/ou da PMT é portado para o interior do fluxo contínuo de dados empacotado composto como dados de identificação do fluxo contínuo composto (um exemplo sendo ilustrado na Figura 14) em relação a cada serviço de programa selecionado, por exemplo, para indicar os PIDs dos pacotes no fluxo contínuo composto que contém dados de áudio, de vídeo e de CA, bem como para indicar o PCR PID.
[00078] Desta maneira, quando a etapa de recepção compreender receber dois ou mais fluxos contínuos de dados empacotados; as etapas de seleção discutidas anteriormente são aplicadas em cada fluxo contínuo de dados empacotado a partir do qual um programa é selecionado; o fluxo contínuo de dados empacotado composto compreende dados de programa provenientes de dois ou mais dos fluxos contínuos de dados empacotados; e a geração do fluxo contínuo de dados empacotado composto compreende concatenar os pacotes selecionados para formar o fluxo contínuo de dados empacotado composto. A Figura 10 ilustra esquematicamente pacotes de TS 205 de dois serviços de programa, serviço | e serviço 2, combinados em um único fluxo contínuo de dados empacotado composto.
[00079] A Figura 11 ilustra esquematicamente uma sucessão de CAMs, que formam um exemplo do conjunto de CAMs 114 discutido anteriormente. Os CAMs são arranjados em série, como uma assim denominada cadeia margarida, de forma que o fluxo contínuo de dados empacotado composto proveniente do controlador de CI 112 seja suprido como uma entrada 210 para um primeiro CAM 212 na série, e seja roteado do primeiro CAM 212 para um segundo CAM 214, a partir de onde ele é passado para um terceiro CAM 216 antes de ser retornado, com os serviços exigidos desencriptados com base nos identificadores de pacote passados com dados de identificação do fluxo contínuo de dados composto, ou como parte deles, para o controlador de CI 112. Os CAMs na cadeia margarida podem ser arranjados para prover desencriptação de diferentes serviços de acesso condicional, de forma que, qualquer que seja o serviço (na faixa dos serviços e sistemas de CA tratados pelo conjunto 114) selecionado para desencriptação pelo usuário ou controle da máquina, um do conjunto de CAMs 114 é capaz de desencriptá-lo. Uma técnica pela qual o hospedeiro pode selecionar o CAM apropriado para que um serviço de programa em particular seja desencriptado será descrita a seguir em relação à Figura 15.
[00080] Desta maneira, o decodificador de conteúdo, quando formado como um conjunto de CAMs ou um CAM tipo cartão M, é capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir de um único fluxo contínuo de dados empacotado; e, em tais casos, a etapa de geração do fluxo contínuo de dados empacotado composto compreende formar o fluxo contínuo de dados empacotado composto a partir de pacotes que representam dois ou mais programas.
[00081] Note que há duas interfaces principais para cada CAM. Áudio, vídeo e alguns dados de controle podem ser passados para os CAMs como parte do fluxo contínuo de bits empacotado composto suprido na entrada 210 e passado de CAM para CAM. Uma interface de controle adicional, com taxa de dados muito inferior, 218 é provida entre o controlador de CI e cada CAM. Sinais de controle a serem discutidos a seguir podem ser multiplexados no fluxo contínuo de dados empacotado composto ou portados pela interface de controle.
[00082] Em termos gerais, apenas um CAM age para desencriptar um serviço de programa em particular, e o CAM não pode desencriptar um serviço de programa, a menos que ele receba uma instrução do hospedeiro para fazê-lo.
[00083] Em modalidades, o arranjo da Figura 11 pode ser operado quando todos os CAMSs no arranjo em cadeia margarida forem cartões S (ou cartões M que operam no modo de fluxo contínuo individual), ou quando todos os CAM;s no arranjo em cadeia margarida forem cartões M, em virtude de, em cada caso, o formato dos dados para o fluxo contínuo de dados empacotado composto ser o mesmo através da íntegra do arranjo em cadeia margarida de CAMs. Para uso em situações em que este não é O caso, a Figura 12 ilustra esquematicamente uma sucessão de CAMs 220, 222, 224 com unidades de interface 226, 228 entre eles.
[00084] Em um arranjo de exemplo, considere que o CAM 220 é um cartão M, o CAM 222 é um cartão S e o CAM 224 é um cartão M. Um sinal de dados empacotado composto 230 recebido a partir do controlador de CI 112 está no formato do cartão M, o que significa que ele inclui o pré- cabeçalho adicional discutido anteriormente. Este sinal é tratado de uma maneira convencional pelo cartão M 220, mas, em vez de ser passado diretamente para o próximo cartão 222 no arranjo em cadeia margarida, em vez disto, ele é passado para a unidade de interface 226 onde a informação de cabeçalho adicional em relação ao pré-cabeçalho é retirada dos pacotes e, se necessário, valores de PID são remapeados, antes de o fluxo contínuo de dados empacotado composto ser passado para o cartão S 222. A unidade de interface 226 retém os dados retirados e quaisquer dados de remapeamento de PID em relação ao fluxo contínuo de dados empacotado composto original, e passa esta informação retida para a unidade de interface 228 que recebe o fluxo contínuo de dados de saída a partir do cartão S 222. A unidade de interface 228 reinsere o pré-cabeçalho sobre cada pacote e realiza um processo de remapeamento do PID inverso para retornar os valores de PID para suas formas originais. O fluxo contínuo de dados de saída proveniente da unidade de interface 228 é, então, passado para o cartão M 224 a fim de ser processado.
[00085] A Figura 13 é um fluxograma esquemático que ilustra Oo tratamento de assim denominados PIDs fantasmas.
[00086] PIDs fantasmas referem-se a assim denominados pacotes fantasmas em um fluxo contínuo de transporte MPEG. Em alguns casos, pacotes fantasmas podem ser usados pelos contribuintes para o sistema de difusão, tais como fabricantes do dispositivo hospedeiro, fabricantes do receptor, difusoras, revendedores do sistema de CA e congêneres, para prover informação de controle confidencial (como um campo de "dados privados", por exemplo) para várias partes do dispositivo hospedeiro e, em particular, o CAM ou os CAMs em uso em um dispositivo hospedeiro.
[00087] Em termos gerais, é considerado desejável manter tais pacotes secretos, ou pelo menos não anunciar sua presença, em virtude de eles poderem conter informação que pode ser útil para que um usuário não autorizado ou hacker empreendam desencriptação não autorizada de um ou mais serviços.
[00088] Em um exemplo simples, os pacotes fantasmas podem incluir uma atualização de software embarcado para um dispositivo CAM, que, por sua vez, representa dados que o revendedor do CA ou o fabricante do CAM, normalmente, prefeririam manter afastados de hackers em potencial. Para alcançar um grau de confidencialidade, pacotes que contêm tais dados podem ser transmitidos usando PIDs que são deriváveis pelo CAM de acordo com (por exemplo) um algoritmo predeterminado com base no tempo atual ou em outras condições, mas que não são indicados como parte de nenhuma das tabelas de alocação que fazem parte deste TS. Então, os pacotes fantasmas são potencialmente importantes para uso pelos dispositivos CAM, mas, como eles não são incluídos em nenhuma das tabelas de alocação, então, a menos que ação específica seja tomada para evitar este fato, eles podem, de fato, ser descartados pelas unidades 192, 194 da Figura 9 e podem não estar presentes em um fluxo contínuo de dados empacotado composto que é realmente suprido para o CAM.
[00089] Para abordar este problema em potencial, os seletores 180, 182 e as unidades de descarte 192, 194 da Figura 9 podem operar de acordo com as seguintes etapas mostradas na Figura 13.
[00090] Em uma etapa 250, os seletores 180, 182 selecionam os PIDs para os serviços de programas exigidos. Isto representa um modo de operação correspondente àquele já descrito em relação à Figura 9. Uma diferença em relação à Figura 9, entretanto, é que, em uma etapa 252, os seletores também selecionam (para inclusão no fluxo contínuo de dados empacotado composto) todos os PIDs que não são especificados pelos dados de identificação (PMT, PAT ou CAT) para este TS. Então, neste estágio, os seletores não sabem qual significado técnico pode ser anexado nos PIDs fantasmas, mas eles estão selecionando todos os PIDs que estão presentes no TS e que não correspondem especificamente a serviços de programa diferentes do serviço de programa exigido. Uma etapa 254 representa a operação de remapeamento realizada pelos remapeadores 196, 198, mas nota-se que a operação de remapeamento refere-se não apenas aos PIDs para o serviço selecionado, mas, também, aos PIDs fantasmas selecionados na etapa 252. Finalmente, em uma etapa 256, os dados de remapeamento, isto é, o relacionamento entre os PIDs antes do remapeamento e os PIDs depois do remapeamento (um exemplo sendo mostrado na Figura 14), são enviados para o conjunto de CAMs 114, de forma que, se um CAM no conjunto exigir acesso a um pacote definido por um PID fantasma, o CAM pode identificar este pacote nos dados remapeados pela referência à informação de remapeamento, e decodificar o pacote identificado desta maneira.
[00091] Note que os PIDs usados para indicar pacotes fantasmas podem mudar de tempo em tempo. De fato, isto pode ser parte do procedimento segurança associado com estes pacotes. Também, os pacotes fantasmas podem não ser difundidos muito frequentemente. Então, quando o sistema da Figura 9 operar primeiro em relação a um serviço de programa em particular proveniente de um TS em particular, ele pode não estar ciente do conjunto atual de PIDs fantasmas. Ele pode ficar ciente destes por uma de duas técnicas: pela detecção (por um seletor 180, 182) de um PID no fluxo contínuo de dados que não é referenciado em nenhuma das tabelas de referência, ou por um CAM que solicita um PID em particular (por exemplo, por meio da interface de controle) que o CAM considera que ele exige, mas que não está no fluxo contínuo de dados empacotado composto. A primeira destas pode ser considerada como uma seleção preventiva, a segunda como uma seleção reativa. Em cada caso, o seletor 180, 182 pode agir, em resposta, para selecionar este PID para inclusão no fluxo contínuo de dados empacotado composto. Isto pode, em princípio, ocorrer imediatamente, de maneira tal que a primeira instância de um PID como este seja incluída no fluxo contínuo de dados empacotado composto. Ou pode haver um atraso, particularmente, se a inclusão do PID for em resposta a uma solicitação proveniente de um CAM que consulta a ausência do PID. Esta é uma ocorrência em potencial em virtude da taxa de dados relativamente baixa da interface de controle. Mas um pequeno atraso (por exemplo, menos de um segundo) não é considerado um problema, em virtude de ser prática comum transmitir múltiplas vezes todos os pacotes importantes que não são parte do fluxo contínuo de áudio/vídeo. Isto é para lidar com o fato de que o usuário pode ativar ou desativar seu receptor em qualquer momento, então, seria prática ruim transmitir um pacote crítico somente em uma única ocasião, em um momento em que o usuário pode estar sem sorte o suficiente para perder esta transmissão.
[00092] A Figura 14 ilustra esquematicamente uma tabela de mapeamento de PID como um exemplo do tipo de informação de remapeamento que pode ser transmitida do multiplexador 140 para o conjunto de CAMs 114 na etapa 256, tanto como dados de controle quanto multiplexada no fluxo contínuo de dados composto. A tabela de mapeamento de PID refere-se a uma identificação 260 do TS a partir do qual o PID foi tomado, uma identificação 262 do serviço de programa derivado a partir deste TS, uma identificação 264 do PID "antigo" (antes do remapeamento) e uma identificação 266 do PID "novo" (depois do remapeamento). A tabela de mapeamento de PID pode ser multiplexada no fluxo contínuo de dados empacotado composto e/ou transmitida para os CAMs pela interface de controle 218. Em modalidades, a tabela da Figura 14 pode agir como um exemplo dos dados de identificação do fluxo contínuo composto. Em modalidades, os dados da Figura 14 podem ser usados para controlar a decodificação de programas provenientes do fluxo contínuo de dados empacotado composto por um ou mais CAMs, de acordo com os identificadores de pacote na tabela de mapeamento de PID da Figura 14.
[00093] Note que, para qualquer TS, pode bem haver diversas diferentes entradas na tabela de mapeamento de PID da Figura 14, em relação aos vários PIDs do serviço de programa exigido e aos vários outros PIDs fantasmas presentes neste TS.
[00094] Note também que a tabela de mapeamento de PID pode mudar no tempo, então, ela é tanto repetidamente transmitida para os CAMs pelo controlador de CI quanto é pelo menos retransmitida em resposta a uma mudança no mapeamento. Um motivo pelo qual o remapeamento pode mudar é que um pacote fantasma novamente identificado tem um PID que corresponde a um outro PID no fluxo contínuo de dados empacotado composto, levando a uma exigência para remapear um ou ambos destes.
[00095] A Figura 15 ilustra esquematicamente operações envolvidas na detecção de qual CAM de uma sucessão de CAMs é capaz de decodificar o serviço de programa exigido.
[00096] As operações mostradas na Figura 15 representam uma interação ou aperto de mãos entre o hospedeiro e cada CAM no conjunto de
CAM;s 114. Operações relacionadas a apenas um CAM do conjunto serão descritas, mas será entendido que operações correspondentes serão realizadas em relação a outros do conjunto.
[00097] Uma etapa 300 é realizada quando o sistema iniciar ou inicializar, em que cada CAM envia dados (um assim denominado CA SYS ID) para identificar o tipo do(s) sistema(s) de CA que este CAM é capaz de desencriptar, sujeitos à recepção dos dados da ECM / EMM apropriados para o serviço.
[00098] Uma etapa 310 ocorre quando um novo serviço de programa for selecionado para desencriptação, por exemplo, pela operação do controle do usuário ou sob o controle de um dispositivo de gravação temporizado, ou quando os parâmetros de CA associados com um serviço de programa mudarem (por exemplo, de "claro" para "encriptado" ou o contrário). O hospedeiro envia uma identificação dos PIDs em relação ao serviço de programa exigido para um CAM no conjunto 114. Cada CAM detecta os dados da ECM e da EMM relacionados a este serviço em uma etapa 320 e, em uma etapa 330, detecta (em relação aos dados da ECM e da EMM, bem como as capacidades do próprio CAM) se este serviço é decodificável por este CAM. Certamente, na etapa 310, o hospedeiro pode eleger enviar os PIDs em questão apenas para aqueles CAMs que indicaram, na etapa 300, uma capacidade básica (em princípio) de decodificar este tipo de dados.
[00099] Em uma etapa 340, o hospedeiro verifica a resposta do CAM atual que está sendo consultado. Se o CAM puder decodificar o serviço de programa, então, em uma etapa 350, o hospedeiro aloca uma tarefa de decodificação para este serviço de programa no CAM atualmente consultado. Se não, então, se permanecer um CAM adicional que ainda não foi consultado, então, o hospedeiro retorna o controle para a etapa 310 para consultar este próximo CAM. Em outras circunstâncias, se nenhum CAM adicional permanecer para ser consultado, o processo é abortado e,
opcionalmente, o usuário é notificado de que o serviço de programa exigido não pode ser desencriptado pelo conjunto de CAMs 114 presentes no sistema.
[000100] A Figura 16 ilustra esquematicamente o controle de múltiplos sintonizadores 102, 104 pelo dispositivo hospedeiro e, em exemplo em particular, pela CPU 132 do dispositivo hospedeiro. Na Figura 16, a região esquerda do diagrama refere-se às operações realizadas no hospedeiro e a região direita refere-se às operações realizadas em um CAM do conjunto 114.
[000101] Este processo introduz o conceito de um sintonizador "primário" e um sintonizador "secundário", embora isto possa ser considerado como equivalente a uma designação de um TS "primário" e um TS "secundário", já que há uma correspondência um para um nas presentes modalidades entre a operação de um sintonizador e a recepção de um TS, ou, em outras palavras, cada sintonizador recebe um único TS nas presentes modalidades.
[000102] Em uma etapa 360, uma posição padrão é estabelecida de maneira tal que o sintonizador 102 (sintonizador A) e o TS recebido pelo sintonizador 102 sejam designados como "primários", e o sintonizador 104 (sintonizador B) e o TS recebido pelo sintonizador 104 sejam designados como "secundários". Percebe-se que, em um modo normal de operação, exige-se que apenas um sintonizador assista à assim denominada televisão "ao vivo"; uma função de ter um outro sintonizador é que um segundo serviço possa ser gravado ao mesmo tempo em que um primeiro serviço está sendo assistido ao vivo. Alternativamente, os primeiros dos sintonizadores ou TSs a serem inicialmente exigidos para uso podem formar a definição inicial do TS ou sintonizador primários.
[000103] Em uma etapa 362, a CPU 132 detecta se o sintonizador (TS) secundário está em uso, por exemplo, para gravar um serviço de programa para visualização posterior. Se o sintonizador secundário não estiver em uso, então, em uma etapa 364, a CPU 132 ou o controlador de CI comunicam a disponibilidade do sintonizador secundário para o conjunto de CAMs 114, em resposta a qual CAM do conjunto pode eleger usar o sintonizador secundário para recepção de não visualização da informação de não visualização em uma etapa 366. Em outras palavras, se o sintonizador não estiver atualmente em uso em relação à provisão de um programa para decodificação, ele é considerado disponível com o propósito de acessar (por exemplo, sintonizar em) um canal que porta informação de não visualização.
[000104] Aqui, o termo "recepção de não visualização" pode referir-se à recepção, por um CAM, de informação de não visualização, tais como informação de controle para um CAM, dados de manutenção, atualizações de software embarcado ou software ou congêneres, o que pode exigir o uso exclusivo por este CAM ou um sintonizador por um período de tempo.
[000105] Um outro exemplo refere-se ao assim denominado "vídeo sob demanda impulsionado" ou VOD impulsionado. Neste arranjo, um CAM pode, preventivamente ou sob instrução da central de operações, fazer com que a recepção dos dados seja armazenada, por exemplo, em um gravador de disco rígido, em relação a programas de vídeo que o usuário pode desejar assistir. Desta maneira, com este propósito, o CAM pode agir como um controlador de armazenamento para controlar o armazenamento da informação de não visualização para acesso posterior. Os dados recebidos podem referir-se à íntegra do programa ou podem referir-se a um trailer ou anúncio para o programa, ou podem prover dados de armazenamento temporário suficientes para permitir uma iniciação instantânea de repetição (no comando do usuário) mesmo quando o programa estiver sendo transmitido em fluxo contínuo. A recepção deste tipo de dados não é especificamente solicitada ou instruída pelo usuário; eles são recebidos na iniciação do CAM ou de uma outra parte do sistema como um processo em segundo plano, e são considerados como "dados de não visualização" ou "informação de não visualização" em virtude de (a) eles serem frequentemente transmitidos em uma taxa de dados inferior a um taxa de dados de decodificação ou de visualização, e (b) o usuário dever, no geral, tomar outras etapas (tal como solicitar acesso aos dados em um gravador de disco rígido) mesmo antes de uma parte visualizável poder ser visualizada. Eles podem ser decodificados por um CAM que age como um decodificador de informação de não visualização.
[000106] Informação de não visualização pode ser portada por pelo menos um TS.
[000107] Durante um período em que os dados de manutenção ou outros para dados de não visualização estão sendo recebidos na etapa 366, quaisquer instâncias adicionais da etapa 362 mostrarão que o sintonizador secundário está em uso. Certamente, se o usuário exigir o uso do sintonizador secundário, por exemplo, para gravar um serviço de programa, então, o uso pelo CAM para recepção em segundo plano de não visualização pode ser cancelado. Isto pode ocorrer de uma maneira tal que o usuário não precisa saber que o CAM alguma vez fez uso do sintonizador secundário.
[000108] Retornando para a etapa 362, se o sintonizador secundário for exigido para uso, então, em uma etapa 368, os PIDs para que o serviço de programa seja recebido pelo sintonizador secundário (e, opcionalmente, os PIDs para quaisquer pacotes fantasmas neste TS) são selecionados. Isto corresponde às etapas 250 e 252 da Figura 13. Em uma etapa 370, os PIDs para o TS secundário, da forma selecionada anteriormente, são remapeados (correspondentes à etapa 254 da Figura 13) e os pacotes correspondentes aos PIDs selecionados para os sintonizadores primário e secundário são multiplexados em conjunto para formar o sinal de dados empacotado composto. Note que, da forma discutida anteriormente, é necessário apenas remapear um PID se uma colisão ou um conflito com um outro PID (proveniente de um outro TS) tiver ocorrido. O sistema pode remapear todos os PIDs destes pacotes selecionados a partir do TS secundário, ou pode remapear somente aqueles que exibem um conflito do número do PID. Mas, um recurso significativo é que o TS secundário defina um TS com PIDs que são pelo menos candidatos para remapeamento, se o remapeamento se provar necessário. PIDs no TS primário não são remapeados; eles retêm seus valores originais (como recebidos).
[000109] Então, isto representa o arranjo até que uma mudança de canal (serviço de programa) seja detectada em uma etapa 372. Uma mudança de canal pode ser iniciada por operação de usuário de um controle do usuário ou por operação de máquina de um controle de canal, por exemplo, por um processo de gravação temporizado que exige acesso a um serviço de programa em particular. As operações em resposta à detecção de uma mudança de canal variam de acordo com se é o sintonizador secundário ou o sintonizador primário que está sendo mudado.
[000110] Se o TS secundário estiver sendo mudado, então, o controle retorna para a etapa 362, mas, nenhuma mudança é feita na designação de primário e secundário.
[000111] Se, entretanto, o canal estiver sendo mudado no sintonizador primário (TS), então, o controle passa para uma etapa 374 na qual a designação de primário e secundário é invertida, e o controle também retorna para a etapa 362. Isto é, em um sistema com dois sintonizadores, cada qual recebendo um respectivo TS, aquele que foi previamente designado como o primário é agora designado como o secundário, e aquele que foi previamente designado como o secundário é agora designado como o primário (Em um sistema com mais de dois sintonizadores, o primário prévio é tratado como um secundário).
[000112] O efeito disto é que o primário prévio é agora tratado como um secundário e, então, é sujeito a um processo de remapeamento em relação a seus PIDs, na etapa 370, ou, pelo menos, seus PIDs tornam-se candidatos para remapeamento. Por sua vez, isto significa que não há necessidade de realizar nenhum remapeamento ou alteração adicionais dos PIDs do TS secundário prévio, em virtude de este secundário prévio ser agora tratado como um primário. Na medida em que o usuário é interessado, isto significa que a visualização não é interrompida no canal que não está sendo mudado, em virtude de o sintonizador que recebe este canal (ou o TS que porta este canal) ser agora designado como um primário e, então, não haver necessidade de nenhum remapeamento adicional dos PIDs deste sintonizador.
[000113] A mudança de primário para secundário é, em modalidades, realizada imediatamente, mas a mudança de secundário para primário pode ser atrasada até uma detecção de que um TS secundário deve ser ressintonizado quando nenhum primário existir atualmente, em cujo caso, a mudança é aplicada neste TS secundário. Note que este recurso se aplica se houver dois sintonizadores ou mais de dois sintonizadores.
[000114] Se o presente sistema não estivesse em vigor, então, uma mudança de canal pelo sintonizador primário pode exigir uma nova operação de remapeamento pelo sintonizador secundário. Isto é em virtude de o remapeamento realizado em relação aos PIDs do TS secundário ser realizado a fim de evitar qualquer conflito entre os PIDs do sintonizador primário e os PIDs do sintonizador secundário remapeado. Se não houve mudança na designação de primário e secundário, então, uma mudança no serviço de programa para o sintonizador primário pode levar a um conflito de PIDs e, então, uma necessidade adicional de remapear os PIDs secundários, mesmo embora nenhuma mudança de canal estivesse sendo executada no secundário. Desta maneira, na ausência da presente técnica, uma mudança de canal no sintonizador primário pode resultar em uma interrupção temporária no serviço para o programa recebido pelo sintonizador secundário, o que, por sua vez, perturbaria subjetivamente o usuário.
[000115] A etapa 374 pode ser discutida adicionalmente como segue. Em resposta a uma detecção de que o canal ou TS recebidos pelo primário está sendo mudado (ou, em outras palavras, que o primário deve ser usado para recepção de um programa diferente), o primário pode ser redesignado como um secundário e o secundário prévio como primário. Entretanto, isto não implica que a operação de remapeamento realizada na etapa 370 em relação ao secundário prévio (agora, o primário) precisa ser desfeita e, de fato, isto seria indesejável, já que ocasionaria uma interrupção em potencial no serviço recebido por este sintonizador. Mas, isto não significa que não há necessidade de fazer algum remapeamento dos PIDs do primário novamente designado para evitar um conflito com os PIDs do primário prévio (agora, secundário) depois da ressintonia.
[000116] Em outras palavras, quando for detectado que um programa diferente é selecionado para decodificação do TS primário (comparado com aquele que é atualmente decodificado), ou for detectado que um TS diferente é selecionado (comparado com o TS primário atual), então, um sintonizador secundário é redesignado para se tornar o primário.
[000117] Em instâncias em que não há atualmente um sintonizador primário (quando o primário tiver sido redesignado como um secundário, mas um secundário ainda não tiver sido redesignado como um primário), então, quando for detectado que um programa diferente é selecionado para decodificação do TS secundário (comparado com aquele que é atualmente decodificado a partir do TS secundário), ou for detectado que um TS secundário diferente é selecionado (comparado com o TS secundário atual), então, este sintonizador secundário é redesignado para se tornar o primário.
[000118] A Figura 17 ilustra esquematicamente a multiplexação de dois serviços de programa separados.
[000119] Usando as técnicas supradescritas, foi provido um mecanismo para amalgamar pacotes selecionados a partir de dois ou mais TSs em um único fluxo contínuo de dados empacotado composto. Os pacotes podem ser multiplexados em conjunto na ordem certa, isto é, para qualquer TS individual recebido, os pacotes apropriados para o serviço de programa exigido para decodificação aparecerão no fluxo contínuo de dados empacotado composto na ordem correta uns em relação aos outros. Entretanto, o mecanismo não garante necessariamente que os pacotes multiplexados que apareceram no fluxo contínuo de dados empacotado acertado nas corretas posições no tempo. Em um nível simples, isto pode ser um problema quando dois pacotes pretendidos que sejam incluídos no fluxo contínuo de dados empacotado composto tiverem posições no tempo sobrepostas; na geração do fluxo contínuo de dados empacotado composto, um destes deve ser atrasado a fim de ser incluído no fluxo contínuo de dados empacotado composto depois do outro. Estes erros de tempo podem levar a correspondentes erros quando o sinal de áudio/vídeo representado pelos pacotes for decodificado ou renderizado.
[000120] A Figura 17 é uma ilustração esquemática de um exemplo deste problema em potencial. Um subconjunto de pacotes é selecionado a partir de cada um dos dois fluxos contínuos de transporte, TS1 e TS2. O subconjunto de pacotes selecionado compreende aqueles pacotes que são carregados ao longo de um eixo geométrico do tempo que passa da esquerda para a direita no diagrama. Pacotes não selecionados são simplesmente não ilustrados, para auxiliar na clareza do diagrama. Como um exemplo de um conflito de sincronismo, pode-se ver que um pacote 400 proveniente de TS] sobrepõe no tempo com um pacote 402 proveniente de TS2.
[000121] Uma terceira linha da Figura 17 (rotulada "para / a partir do módulo") representa esquematicamente o fluxo contínuo de dados empacotado composto. Será visto que o pacote 400 reteve substancialmente sua posição no tempo original, mas o pacote 402 foi atrasado a fim de ocorrer, no fluxo contínuo de dados empacotado composto, depois do pacote 400.
[000122] As quarta e quinta linhas da Figura 17 representam o fluxo contínuo de dados empacotado individual que são reconstruídos depois da desencriptação pelo conjunto de CAMs 114 e da desmultiplexação. Novamente, será visto que o pacote desencriptado 400' reteve sua posição no tempo original, em que a versão desencriptada do pacote 402 (o pacote desencriptado 402') passou por um deslocamento no tempo em uma quantidade de deslocamento 404. Um deslocamento no tempo similar 406 se aplica em um pacote posterior em TS2.
[000123] Esta mudança nas posições no tempo nos fluxos contínuos de transporte torna os registros de tempo de referência do relógio do programa (PCR) no fluxo contínuo de dados empacotado não mais precisos. Em decorrência disto, o relógio do receptor necessário para decodificação do serviço de programa MPEG não seria preciso o suficiente e isto pode ocasionar questões subjetivamente perturbantes, tais como erros de sincronismo labial.
[000124] Duas possíveis técnicas serão discutidas para abordar este problema. A Figura 18 ilustra esquematicamente um pacote 410 (que pode ou pode não incluir um cabeçalho pré-pendente, como exposto) que também inclui um cabeçalho de pacote aumentado 412 que inclui pelo menos um tempo de chegada do pacote que representa um registro de tempo alocado em cada pacote de TS que chega respectivo desmodulador, ou, em outras palavras, é relacionado a um tempo no qual o fluxo contínuo composto é gerado.
[000125] A Figura 19 ilustra esquematicamente uma tabela de dados de sincronismo de pacote que armazena dados similares, embora não na forma de um cabeçalho de pacote, permitindo que o sincronismo original dos pacotes de TS seja regerado no estágio final do decodificador. A tabela pode ser passada para os CAMs por meio da interface de controle ou, por exemplo, como dados privados DVB ou como uma tabela de dados. Tais dados podem ser transmitidos como um pacote de dados privado adjacente, no fluxo contínuo composto, ao pacote ao qual ele refere-se. Isto liga os dados ao respectivo pacote.
[000126] Primeiro, em relação à Figura 19, com detalhes, a tabela de dados de sincronismo de pacote compreende cinco campos de dados para cada pacote de TS. Estes são: um número de sequência 420 atribuído pelo hospedeiro como parte de uma sequência a cada pacote de TS que chega em um fluxo contínuo de transporte, um valor de PID 422 tomado a partir do cabeçalho do pacote, um tempo de chegada do pacote 424 que representa um registro de tempo alocado pelo hospedeiro ou pelo controlador de CI em cada pacote de TS que chega a partir do seu respectivo desmodulador, um indicador "enviado" 426 que indica se o pacote de TS foi enviado para o conjunto de CAMs 114 para desencriptação, e um indicador "recebido" 428 que indica se o pacote foi recebido de volta a partir do conjunto de CAMs depois da desencriptação.
[000127] Usando a informação mantida na tabela de dados de sincronismo de pacote, o controlador de CI pode inserir os pacotes desencriptados recebidos de volta a partir do conjunto de CAMs 114 em suas posições no tempo originais de acordo com os tempos de chegada do pacote armazenados na tabela. Certamente, pode haver um curto atraso consistente para todos os pacotes em um TS reconstruído (em virtude de pacotes não poderem ser reinseridos em um TS antes do tempo no qual eles são recebidos de volta a partir do conjunto de CAMSs), mas os sincronismos relativos de todos os pacotes no TS reconstruído podem se tornar corretos pelo uso dos dados do tempo de chegada armazenados na tabela de dados de sincronismo de pacote.
[000128] Uma função similar pode ser realizada usando os dados de cabeçalho aumentados 412 mostrados na Figura 18.
[000129] A Figura 20 ilustra esquematicamente a geração do pacote da Figura 18 e a Figura 21 ilustra esquematicamente o uso do pacote da Figura
18.
[000130] Em relação à Figura 20, em uma etapa 430, o controlador de CI detecta um tempo atual em que um pacote de TS chega no controlador de CI, e adiciona pelo menos os dados do tempo de chegada no cabeçalho aumentado 412 em uma etapa 432.
[000131] Em relação à Figura 21, quando o pacote for recebido de volta a partir do conjunto de CAMs depois da desencriptação, o controlador de CI detecta a informação de sincronismo previamente inserida no cabeçalho aumentado 412 em uma etapa 434 e, em uma etapa, 436 tanto gera informação de controle para controlar a decodificação deste pacote no tempo correto quanto reinsere o pacote em um TS reconstituído no tempo correto (ou, como exposto, pelo menos no tempo relativo correto em relação a outros pacotes no TS reconstituído).
[000132] A Figura 22 ilustra esquematicamente a geração da tabela da Figura 19 e a Figura 23 ilustra esquematicamente o uso da tabela da Figura
19.
[000133] Em relação à Figura 22, em uma etapa 440, o controlador de CI detecta o tempo de chegada de um pacote de TS a partir de seu respectivo desmodulador e, em uma etapa 442, armazena este tempo de chegada como parte de uma tabela, tal como a tabela mostrada na Figura 19, juntamente com um número de sequência e o PID extraído a partir do cabeçalho do pacote. Se o controlador de CI estiver enviando este pacote para desencriptação, o controlador de CI define o indicador "enviado" 426 para indicar que isto Ocorreu.
[000134] Em relação à Figura 23, quando um pacote for recebido de volta a partir do processo de desencriptação, o controlador de CI define o indicador "recebido" 428 na tabela em uma etapa 444 e, então, em uma etapa 446, acessa informação de sincronismo a partir do campo de tempo de chegada 424 na tabela, usando o PID 422 e o número de sequência 420 para indexar os dados para o pacote correto. Opcionalmente, uma vez que uma linha dos dados foi acessada para um pacote, ela pode ser deletada da tabela da Figura 19 para evitar uma proliferação muito grande dos dados na tabela. Como antes, em uma etapa 448, o controlador de CI tanto controla o processo de decodificação para este pacote para ser realizado no tempo correto quanto controla a reinserção do pacote em um TS reconstituído no tempo correto ou pelo menos no tempo relativo correto em relação a outros pacotes neste TS reconstituído.
[000135] Dois recursos de alguns sistemas de acesso condicional que podem aumentar a segurança do sistema são assim denominados procedimentos de afastamento e assim denominados procedimentos de revogação.
[000136] Dados de afastamento são incluídos na assim denominada tabela de descrição do serviço (SDT) nos dados de difusão, como um exemplo dos dados de serviço que incluem informação de autorização de segurança para hospedeiros (receptores de conteúdo). Afastamento permite que um hospedeiro seja instruído a não usar um CAM pirata ou de outra forma não autorizado, ou a receber e desencriptar certos serviços. Os módulos ou serviços não autorizados são definidos nos dados da tabela de descrição do serviço. Desta maneira, afastamento impõe uma exigência em um hospedeiro para não usar um CAM.
[000137] Revogação envolve uma central de operações dizer a um hospedeiro para passar dados para um CAM, instruindo este módulo a não interagir com um número de modelo do fabricante em particular como um hospedeiro. Novamente, isto pode ser usado em situações em que a segurança de um modelo em particular foi comprometida, a fim de proteger a integridade do sistema de acesso condicional geral. Então, revogação impõe uma exigência em um CAM para não prover serviços de desencriptação para um hospedeiro. Dados de revogação são sinalizados por uma entrada na EMM que diz ao CAM onde encontrar um arquivo de dados de sinalização da revogação (RSD) no carrossel de dados CIplus.
[000138] Em uma situação tanto de afastamento quanto de revogação, o hospedeiro executa uma detecção, com base nos dados da SDT, sobre se o hospedeiro está autorizado a decodificar os dados de programa recebidos. O hospedeiro pode sinalizar opcionalmente o incidente ao usuário, por exemplo, por uma exibição na tela (não mostrada).
[000139] Dados de revogação são, no geral, assinados por um certificado do operador que, por sua vez, é assinado por um certificado raiz, e, então, as precauções a serem descritas a seguir são mais relevantes para dados de afastamento do que para dados de revogação.
[000140] Todos estes dados ficam contidos no TS. Em um sistema de sintonizador individual e CAM individual, a integridade dos dados de afastamento e/ou de revogação pode ser substancialmente garantida pelo sintonizador que desvia do módulo de CAM, verifica os dados da SDT em relação a quaisquer dados de afastamento ou de revogação relevantes para os atuais hospedeiro e/ou CAM e passa os dados de afastamento e de revogação para o CAM para ação. Estas medidas podem evitar que o CAM manipule os dados no TS antes de estes dados serem verificados pelo hospedeiro (Este é um risco em uma situação em que a segurança do CAM foi comprometida).
[000141] A situação é mais complicada em um arranjo de múltiplos sintonizadores e fluxo contínuo de dados empacotado composto multiplexado. Aqui, não é direto desviar o conjunto de CAMSs no contexto do fluxo contínuo de dados empacotado composto. Então, há o perigo de que um ou mais do conjunto de CAMSs possa corromper ou manipular os dados de afastamento ou de revogação contidos na SDT antes de ele ser acionado pelo hospedeiro como parte de uma detecção se o hospedeiro está autorizado a trabalhar com um CAM, por exemplo, para afastar um CAM (por exemplo, pelo envio de uma instrução para um CAM para não decodificar os dados de programa recebidos) ou para recusar a interagir com um CAM em particular.
[000142] A Figura 24 ilustra esquematicamente um arranjo que pode pelo menos aliviar este problema no contexto, por exemplo, do dispositivo hospedeiro da Figura 4.
[000143] Em relação à Figura 24, o fluxo contínuo de dados multiplexado (composto) gerado pelo controlador de CI 112 é digitalmente assinado por uma unidade de assinatura 460 usando uma chave criptográfica secreta. O fluxo contínuo de dados multiplexado digitalmente assinado é, então, passado para o conjunto de CAMs 114 que age como um decodificador de conteúdo para decodificação de dois ou mais programas a partir do fluxo contínuo de dados empacotado composto de acordo com os PIDs nos dados de identificação do fluxo contínuo. Depois da desencriptação, a assinatura é verificada por um verificador de assinatura 462 (que verifica a validade da assinatura) antes de os dados serem repassados para o desmultiplexador 142.
[000144] Técnicas conhecidas relacionadas à assinatura que usa uma chave privada e verificação que usa uma chave pública podem ser aqui usadas. Uma chave como esta pode ser exclusiva do receptor, por exemplo, que é armazenada de uma maneira segura no receptor na fabricação. Esta assinatura digital é um exemplo de um indicador de segurança digital.
[000145] A chave secreta pode ser comunicada entre a unidade de assinatura 460 e a unidade de verificação 462 por uma ligação de dados segura 464. O par chave pública - privada pode ser diferente de hospedeiro para hospedeiro para aumentar a integridade em potencial do sistema de verificação.
[000146] A assinatura digital pode ser aplicada na íntegra do fluxo contínuo de dados empacotado composto ou somente nos dados da SDT no fluxo contínuo de dados. Então, em modalidades, a assinatura digital é aplicada pelo menos nos dados da SDT incluídos no fluxo contínuo multiplexado. A assinatura digital pode ser inserida no fluxo contínuo de dados ou pode ser comunicada separadamente entre as unidades 460 e 462.
[000147] Se o hospedeiro verificar que esta assinatura digital foi corrompida, ele pode realizar várias diferentes ações. Ele pode indicar o fato para o usuário, por exemplo, como uma exibição na tela. Ele pode habilitar e desabilitar cada CAM um após o outro, usando a interface de controle 218, para detectar qual CAM está ocasionando a corrupção e, então, desabilitar permanentemente ou semipermanentemente este CAM. Em qualquer evento, a especificação CIplus indica que não permite-se que o hospedeiro apresente conteúdo desencriptado por um CAM corrompido ou afastado para a tela para visualização por um usuário ou para gravação por um usuário.
[000148] Será entendido que algumas das técnicas supradescritas, tais como aquelas relacionadas à geração do fluxo contínuo de dados empacotado composto, referem-se aos sistemas que usam pelo menos dois TSs. Outras das técnicas referem-se aos sistemas que usam um ou mais TSs de entrada.
[000149] Modalidades também incluem um sinal de dados, que é um sinal no aparelho, da forma descrita, em particular (embora não exclusivamente), um sinal passado do hospedeiro para o CAM ou conjunto de CAMSs, ou o sinal de retorno. Uma mídia de armazenamento, tal como uma memória pela qual um sinal como este é armazenado, também é considerada como uma modalidade. A mídia de armazenamento pode ser, por exemplo, uma mídia de armazenamento legível por máquina não temporária.
[000150] No contexto da Figura 24, um exemplo de um sinal como este é um sinal de dados de áudio/vídeo que compreende um fluxo contínuo de dados empacotado composto que tem dados de programa provenientes de dois ou mais fluxos contínuos de dados empacotados, com um subconjunto de pacotes de dados provenientes de dois ou mais fluxos contínuos de dados empacotados recebidos, o subconjunto incluindo estes pacotes de dados de áudio/vídeo em relação àqueles programas a serem decodificados; e dados de serviço que incluem informação de autorização de segurança para receptores de conteúdo, os dados de serviço tendo um indicador de segurança digital aplicado.
[000151] Enquanto as modalidades foram implementadas, pelo menos em parte, usando o aparelho de processamento dos dados controlado por software, será percebido que tal software e uma mídia pela qual o software é provisionado (tal como uma mídia de armazenamento legível por máquina não temporária, por exemplo, um disco magnético ou ótico ou uma memória não volátil) também são considerados como modalidades da presente descrição.
[000152] As seguintes modalidades referem-se aos recursos discutidos anteriormente em várias combinações.
[000153] Modalidades podem prover um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem a informação de desencriptação, o método compreendendo as etapas de: receber conteúdo de áudio/vídeo codificado como um fluxo contínuo de dados empacotado que compreende um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote e que compreende dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; selecionar pacotes de dados a partir do fluxo contínuo de dados empacotado para um programa exigido de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; selecionar pacotes de dados adicionais a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado; gerar um fluxo contínuo de dados empacotado composto a partir dos pacotes selecionados; gerar dados de identificação do fluxo contínuo composto que indicam identificadores de pacote dos pacotes incluídos no fluxo contínuo de dados empacotado composto; e suprir o fluxo contínuo de dados empacotado composto para o decodificador de conteúdo para decodificação do programa a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote nos dados de identificação do fluxo contínuo composto.
[000154] Modalidades podem prover um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir de um único fluxo contínuo de dados empacotado, o método compreendendo as etapas de: receber conteúdo de áudio/vídeo codificado como dois ou mais fluxos contínuos de dados empacotados, cada fluxo contínuo de dados compreendendo um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote, cada fluxo contínuo de dados empacotado compreendendo dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; gerar um fluxo contínuo de dados empacotado composto que tem dados de programa provenientes de dois ou mais dos fluxos contínuos de dados empacotados por: definição de um dos fluxos contínuos de dados empacotados a partir dos quais dados de programa devem ser decodificados como um fluxo contínuo de dados empacotado primário e outros fluxos contínuos de dados empacotados a partir dos quais dados de programa devem ser decodificados como fluxos contínuos dos dados secundários empacotados; seleção pacotes de dados a partir de um fluxo contínuo de dados empacotado para cada programa exigido de acordo com os conjuntos de identificadores de pacote definidos pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; remapeamento dos identificadores de pacote de pelo menos aqueles pacotes que foram selecionados a partir dos(s) fluxo(s) contínuo(s) de dados empacotados secundário(s) e que têm identificadores de pacote idênticos aos identificadores de pacote provenientes de um outro fluxo contínuo de dados empacotado para diferentes respectivos identificadores de pacote, e não remapeamento dos identificadores de pacote dos pacotes que foram selecionados a partir do fluxo contínuo de dados empacotado primário; e geração dos dados de identificação do fluxo contínuo composto que definem os identificadores de pacote dos pacotes de dados no fluxo contínuo de dados empacotado composto; decodificação de dois ou mais programas a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote nos dados de identificação do fluxo contínuo composto; em resposta à detecção da seleção de um programa diferente para decodificação a partir do fluxo contínuo de dados empacotado primário ou da seleção de um diferente fluxo contínuo de dados empacotado para recepção no lugar do fluxo contínuo de dados empacotado primário, mudança da designação do fluxo contínuo de dados empacotado primário para ser um fluxo contínuo de dados empacotado secundário.
[000155] Modalidades podem prover um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir de um único fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem a informação de desencriptação, o método compreendendo as etapas de:
receber conteúdo de áudio/vídeo codificado como dois ou mais fluxos contínuos de dados empacotados, cada fluxo contínuo de dados compreendendo um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote, cada fluxo contínuo de dados empacotado compreendendo dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote e dados de serviço que incluem informação de autorização de segurança para receptores de conteúdo; gerar um fluxo contínuo de dados empacotado composto que tem dados de programa e os dados de serviço a partir de dois ou mais dos fluxos contínuos de dados empacotados; aplicar um indicador de segurança digital pelo menos nos dados de serviço incluídos no fluxo contínuo de dados empacotado composto; suprir o fluxo contínuo de dados empacotado composto para o decodificador de conteúdo para decodificação de dois ou programas a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote nos dados de identificação do fluxo contínuo composto; receber os dados de serviço a partir do decodificador de conteúdo; detectar a validade do indicador de segurança digital aplicado nos dados de serviço; e em resposta aos dados de serviço, detectar se o receptor de conteúdo está autorizado a decodificar dados de programa recebidos.
[000156] Modalidades podem prover um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir de um único fluxo contínuo de dados empacotado de pacotes de dados de áudio/vídeo codificados, o método compreendendo as etapas de: receber conteúdo de áudio/vídeo codificado como dois ou mais fluxos contínuos de dados empacotados, cada fluxo contínuo de dados compreendendo um ou mais programas que têm respectivos pacotes de dados de áudio/vídeo codificados; gerar um fluxo contínuo de dados empacotado composto que tem dados de programa provenientes de dois ou mais dos fluxos contínuos de dados empacotados pela seleção de um subconjunto de pacotes de dados a partir de dois ou mais fluxos contínuos de dados empacotados recebidos, o subconjunto incluindo aqueles pacotes de dados de áudio/vídeo em relação àqueles programas a serem decodificados; armazenar dados de sincronismo que indicam pelo menos um tempo de chegada daqueles pacotes de dados de áudio/vídeo incluídos no fluxo contínuo de dados empacotado composto; e decodificar e transmitir dados de programa de áudio/vídeo a partir do fluxo contínuo de dados empacotado composto de acordo com a informação de sincronismo armazenada em relação a cada pacote de áudio/vídeo decodificado.
[000157] Modalidades podem prover um receptor de conteúdo de áudio/vídeo para receber e decodificar sinais de dados de áudio/vídeo modulados sobre canais de transmissão, pelo menos um canal de transmissão portando informação de não visualização, o receptor compreendendo: um arranjo de sintonizador capaz de sintonizar concorrentemente em dois ou mais canais de transmissão; um multiplexador configurado para gerar um sinal de dados composto a partir de sinais de áudio/vídeo recebidos relacionados a programas exigidos para decodificação; um decodificador de conteúdo capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir do sinal de dados composto; um detector configurado para detectar se um ou mais dos canais de transmissão sintonizados pelo arranjo de sintonizador não estão atualmente em uso em relação à provisão de um programa para decodificação; um controlador, responsivo a uma detecção de que um canal de transmissão não está atualmente em uso, para controlar o sintonizador para sintonizar este canal em um canal de transmissão que porta informação de não visualização; e um decodificador de informação de não visualização para decodificar a informação de não visualização recebida.
[000158] Modalidades podem prover um método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem a informação de desencriptação, o método compreendendo as etapas de: receber conteúdo de áudio/vídeo codificado como fluxos contínuos de dados empacotados que compreendem um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote e dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; selecionar pacotes de dados a partir do fluxo contínuo de dados empacotado para cada programa exigido de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; selecionar pacotes de dados adicionais a partir de cada fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que contém dados de referência do relógio do programa em relação ao programa selecionado, no caso em que dados de referência do relógio do programa não forem incluídos nos pacotes em relação ao programa selecionado; gerar um fluxo contínuo de dados empacotado composto a partir dos pacotes selecionados; e gerar dados de identificação do fluxo contínuo composto que definem os identificadores de pacote dos pacotes de dados no fluxo contínuo de dados empacotado composto; e suprir o fluxo contínuo de dados empacotado composto para o decodificador de conteúdo para decodificação de acordo com as referências do relógio do programa e os identificadores de pacote nos dados de identificação do fluxo contínuo composto.
[000159] Ficará aparente que inúmeras modificações e variações da presente descrever são possíveis à luz dos preceitos expostos. Portanto, deve ser entendido que, no escopo das reivindicações anexas, a tecnologia pode ser praticada de forma diferente daquela aqui especificamente descrita.

Claims (20)

REIVINDICAÇÕES
1. Método de operação de um receptor de conteúdo de áudio/vídeo que tem um decodificador de conteúdo capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem informação de desencriptação, caracterizado pelo fato de que o método compreende as etapas de: receber conteúdo de áudio/vídeo codificado como um fluxo contínuo de dados empacotado que compreende um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote e que compreende dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; selecionar pacotes de dados a partir do fluxo contínuo de dados empacotado para um programa exigido de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido; selecionar pacotes de dados adicionais a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado; gerar um fluxo contínuo de dados empacotado composto a partir dos pacotes selecionados; gerar dados de identificação do fluxo contínuo composto que indicam identificadores de pacote dos pacotes incluídos no fluxo contínuo de dados empacotado composto; e suprir o fluxo contínuo de dados empacotado composto para o decodificador de conteúdo para decodificação do programa a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote no dados de identificação do fluxo contínuo composto.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende: selecionar pacotes de dados adicionais a partir de cada fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que contém dados de referência do relógio do programa em relação ao programa selecionado.
3. Método, de acordo com a reivindicação 1 ou a reivindicação 2, caracterizado pelo fato de que compreende: incluir o dados de identificação do fluxo contínuo composto no fluxo contínuo de dados empacotado composto.
4. Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que: o decodificador de conteúdo é capaz de decodificar concorrentemente dois ou mais programas de áudio/vídeo a partir de um único fluxo contínuo de dados empacotado; e a etapa de geração do fluxo contínuo de dados empacotado composto compreende formar o fluxo contínuo de dados empacotado composto a partir de pacotes que representam dois ou mais programas.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que: a etapa de recepção compreende receber dois ou mais fluxos contínuos de dados empacotados; as etapas de seleção são aplicadas em cada fluxo contínuo de dados empacotado a partir do qual um programa é selecionado; o fluxo contínuo de dados empacotado composto compreende dados de programa provenientes de dois ou mais dos fluxos contínuos de dados empacotados; e a etapa de geração do fluxo contínuo de dados empacotado composto compreende concatenar os pacotes selecionados para formar o fluxo contínuo de dados empacotado composto.
6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende: para, pelo menos um dos fluxos contínuos de dados empacotados, remapear os identificadores de pacote dos pacotes que foram selecionados a partir deste fluxo contínuo de dados empacotado para diferentes identificadores de pacote.
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende: definir um dos fluxos contínuos de dados empacotados recebidos como um fluxo contínuo de dados empacotado primário e outros fluxos contínuos de dados empacotados recebidos como fluxos contínuos dos dados secundários; e remapear os identificadores de pacote para pacotes provenientes dos fluxos contínuos dos dados secundários empacotados e não remapear os identificadores de pacote para pacotes provenientes do fluxo contínuo de dados empacotado primário.
8. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende: identificar a origem de cada pacote selecionado pela inserção de informação adicional no início de cada pacote no fluxo contínuo de dados composto.
9. Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que compreende: o decodificador de conteúdo indicar que ele exige pacotes provenientes de um fluxo contínuo de dados empacotado de um identificador de pacote em particular não incluído nos dados de identificação para este fluxo contínuo de dados empacotado; e selecionar pacotes deste identificador de pacote a partir deste fluxo contínuo de dados empacotado para inclusão no fluxo contínuo de dados empacotado composto.
10. Meio de armazenamento em memória, caracterizado pelo fato de que compreende instruções que, quando executadas por um computador, fazem com que o computador implemente o método como definido em qualquer uma das reivindicações anteriores.
11. Receptor de conteúdo de áudio/vídeo, caracterizado pelo fato de que compreende: um decodificador de conteúdo capaz de decodificar um programa de áudio/vídeo a partir de um fluxo contínuo de dados empacotado pelo uso de pacotes de dados que definem informação de desencriptação; um arranjo de sintonizador configurado para receber conteúdo de áudio/vídeo codificado como um fluxo contínuo de dados empacotado que compreende um ou mais programas que têm pacotes de dados identificados por respectivos conjuntos de um ou mais identificadores de pacote e que compreende dados de identificação que mapeiam programas para respectivos conjuntos dos identificadores de pacote; um seletor configurado para selecionar pacotes de dados a partir do fluxo contínuo de dados empacotado para um programa exigido de acordo com o conjunto de identificadores de pacote definido pelos dados de identificação para este fluxo contínuo em relação ao programa exigido e para selecionar pacotes de dados adicionais a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado; e um gerador de fluxo contínuo empacotado composto configurado para gerar um fluxo contínuo de dados empacotado composto a partir dos pacotes selecionados e para gerar um dados de identificação do fluxo contínuo composto que indicam identificadores de pacote dos pacotes incluídos no fluxo contínuo de dados empacotado composto;
o decodificador de conteúdo sendo configurado para receber o fluxo contínuo de dados empacotado composto a partir do gerador de fluxo contínuo empacotado composto para decodificação do programa a partir do fluxo contínuo de dados empacotado composto de acordo com os identificadores de pacote no dados de identificação do fluxo contínuo composto.
12. Receptor, de acordo com a reivindicação 11, caracterizado pelo fato de que o seletor é configurado para selecionar pacotes de dados adicionais a partir de cada fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que contém dados de referência do relógio do programa em relação ao programa selecionado.
13. Receptor, de acordo com a reivindicação 11 ou a reivindicação 12, caracterizado pelo fato de que o decodificador de conteúdo compreende um arranjo conectado em série de dois ou mais decodificadores de conteúdo.
14. Receptor, de acordo com a reivindicação 11, caracterizado pelo fato de que o gerador de fluxo contínuo empacotado composto é configurado para incluir os dados de identificação do fluxo contínuo composto no fluxo contínuo de dados empacotado composto.
15. Receptor, de acordo com a reivindicação 11, caracterizado pelo fato de que: o receptor é operável para receber dois ou mais fluxos contínuos de dados empacotados; o seletor é operável em relação a cada fluxo contínuo de dados empacotado a partir do qual um programa é selecionado; o fluxo contínuo de dados empacotado composto compreende dados de programa provenientes de dois ou mais dos fluxos contínuos de dados empacotados; e o gerador do fluxo contínuo de dados empacotado composto é configurado para concatenar os pacotes selecionados para formar o fluxo contínuo de dados empacotado composto.
16. Receptor, de acordo com a reivindicação 15, caracterizado pelo fato de que o gerador de fluxo contínuo empacotado composto é configurado para identificar a origem de cada pacote selecionado pela inserção de informação adicional no início de cada pacote no fluxo contínuo de dados composto.
17. Sinal de dados de áudio/vídeo, caracterizado pelo fato de que compreende um fluxo contínuo de dados empacotado composto que compreende: pacotes de dados provenientes de um fluxo contínuo de dados empacotado para um programa de áudio/vídeo exigido de acordo com o conjunto de identificadores de pacote definido por dados de identificação para este fluxo contínuo em relação ao programa exigido; e pacotes de dados selecionados a partir do fluxo contínuo de dados empacotado a partir do qual é selecionado um programa que tem identificadores de pacote não incluídos nos dados de identificação para este fluxo contínuo de dados empacotado.
18. Sinal de dados, de acordo com a reivindicação 17, caracterizado pelo fato de que compreende dados de identificação do fluxo contínuo composto que indicam identificadores de pacote dos pacotes incluídos no fluxo contínuo de dados empacotado composto.
19. Sinal de dados, de acordo com a reivindicação 17 ou a reivindicação 18, caracterizado pelo fato de que compreende pacotes de dados em relação a respectivos programas selecionados a partir de dois ou mais respectivos fluxos contínuos de dados empacotados.
20. Mídia de armazenamento, caracterizada pelo fato de que armazena um sinal de dados de acordo com qualquer uma das reivindicações 17 a
19.
BR112014023251-2A 2012-03-26 2013-03-20 método de operação de um receptor de conteúdo de áudio/vídeo, software de computador, mídia de armazenamento, receptor de conteúdo de áudio/vídeo, e, sinal de dados de dados de áudio/vídeo BR112014023251A2 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1205296.5A GB2500615B (en) 2012-03-26 2012-03-26 Selecting data packets from a packetized data stream comprising audio/video programme data packets and identification data
GB1205296.5 2012-03-26
PCT/GB2013/050729 WO2013144584A1 (en) 2012-03-26 2013-03-20 Conditional access method and apparatus for simultaneously handling multiple television programmes

Publications (1)

Publication Number Publication Date
BR112014023251A2 true BR112014023251A2 (pt) 2020-10-27

Family

ID=46087137

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112014023251-2A BR112014023251A2 (pt) 2012-03-26 2013-03-20 método de operação de um receptor de conteúdo de áudio/vídeo, software de computador, mídia de armazenamento, receptor de conteúdo de áudio/vídeo, e, sinal de dados de dados de áudio/vídeo

Country Status (10)

Country Link
US (1) US9973804B2 (pt)
EP (1) EP2832104B1 (pt)
CN (1) CN104205856B (pt)
BR (1) BR112014023251A2 (pt)
GB (1) GB2500615B (pt)
HU (1) HUE065077T2 (pt)
MX (1) MX347487B (pt)
MY (1) MY173071A (pt)
TW (1) TWI641262B (pt)
WO (1) WO2013144584A1 (pt)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2509759A (en) 2013-01-14 2014-07-16 Sony Corp Receiving audio/visual content-related non-viewing information via unused transmission channels
CN104536910B (zh) * 2014-12-12 2017-12-12 成都德芯数字科技股份有限公司 一种mpeg ts流pid重映射实现系统及方法
DE102016115892A1 (de) * 2016-08-26 2018-03-01 Technisat Digital Gmbh Verfahren für eine Empfangseinrichtung, eine Empfangseinrichtung sowie eine Anordnung
US10452870B2 (en) 2016-12-06 2019-10-22 Dish Technologies Llc Smart card authenticated download
US10579361B1 (en) 2016-12-14 2020-03-03 Juniper Networks, Inc Systems and methods for efficiently updating software installed on network devices
US10484753B2 (en) 2016-12-23 2019-11-19 DISH Tchnologies L.L.C. Securely paired delivery of activation codes from smart card to remote client set-top box
US10484752B2 (en) * 2016-12-23 2019-11-19 DISH Technologies L.L.C. Securely paired delivery of activation codes from smart card to host set-top box
US10325077B2 (en) * 2016-12-23 2019-06-18 DISH Technologies L.L.C. Strong authentication of client set-top boxes
US10171870B2 (en) 2016-12-28 2019-01-01 DISH Technologies L.L.C. Forced execution of authenticated code
US10289401B1 (en) * 2016-12-30 2019-05-14 Juniper Networks, Inc Systems and methods for efficiently downgrading operating systems installed on network devices
CN111726650B (zh) * 2020-06-30 2022-10-18 广州繁星互娱信息科技有限公司 视频直播方法及装置、计算机存储介质
CN113727159B (zh) * 2021-08-19 2022-07-12 西安交通大学 一种集成条件接收模块处理多转发器节目的系统及方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715009A (en) * 1994-03-29 1998-02-03 Sony Corporation Picture signal transmitting method and apparatus
CN1219265A (zh) * 1997-03-12 1999-06-09 皇家菲利浦电子有限公司 数字信息信号在记录载体上的记录
US6973258B1 (en) * 1998-10-02 2005-12-06 Lg Electronics Inc. Method and apparatus for recording digital data streams
WO2000077650A1 (fr) * 1999-06-16 2000-12-21 Scm Microsystems Gmbh Dispositif et son procede pour gerer automatiquement les flux de donnees numeriques d'un hôte entre interface commune et ses modules associes
GB0007870D0 (en) 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for making and replauing digital video recordings, and recordings made by such methods
GB0208373D0 (en) 2002-04-11 2002-05-22 Nokia Corp Digital video broadcasting receiver
GB2399972A (en) * 2003-03-26 2004-09-29 Sony Uk Ltd Common interface controller and method of descrambling transport stream channels
KR20060134395A (ko) * 2005-06-22 2006-12-28 엘지전자 주식회사 케이블 방송 수신기 및 펌웨어 업그레이드 방법
US9015773B2 (en) * 2009-11-18 2015-04-21 Lg Electronics Inc. Method for transmitting and receiving a broadcast signal and a broadcast receiver using the method
US8514853B2 (en) * 2010-01-11 2013-08-20 Cisco Technology, Inc. Remote re-multiplexing of transport streams
US20110302599A1 (en) 2010-06-07 2011-12-08 Mark Kenneth Eyer TV-Centric Actions in Triggered Declarative Objects
GB2487727A (en) 2011-01-28 2012-08-08 Sony Europe Ltd Module for extracting decryption seed, generating a key and providing a secure host channel
GB2489671A (en) 2011-03-28 2012-10-10 Sony Corp Cryptographic key distribution for IPTV
GB2489672A (en) 2011-03-28 2012-10-10 Sony Corp Authentication certificate distribution to set top boxes

Also Published As

Publication number Publication date
TWI641262B (zh) 2018-11-11
TW201406136A (zh) 2014-02-01
MX347487B (es) 2017-04-28
EP2832104A1 (en) 2015-02-04
GB201205296D0 (en) 2012-05-09
US20150040155A1 (en) 2015-02-05
GB2500615A (en) 2013-10-02
MX2014011453A (es) 2015-03-10
GB2500615B (en) 2019-10-23
US9973804B2 (en) 2018-05-15
CN104205856A (zh) 2014-12-10
CN104205856B (zh) 2017-09-22
MY173071A (en) 2019-12-24
EP2832104B1 (en) 2023-11-22
WO2013144584A1 (en) 2013-10-03
HUE065077T2 (hu) 2024-04-28

Similar Documents

Publication Publication Date Title
BR112014023251A2 (pt) método de operação de um receptor de conteúdo de áudio/vídeo, software de computador, mídia de armazenamento, receptor de conteúdo de áudio/vídeo, e, sinal de dados de dados de áudio/vídeo
AU2013372516B2 (en) Receiving audio/video content
US20100158480A1 (en) Multi-stream encryption method and apparatus, and host device for multi-channel recording
US9294446B2 (en) Content encryption
US20140375892A1 (en) Receiving audio/video content
US8996870B2 (en) Method for protecting a recorded multimedia content
ES2653246T3 (es) Recepción de contenido de audio / video
EP2832105A1 (en) Conditional access method and apparatus for simultaneously handling multiple television programmes
WO2013144586A1 (en) Conditional access method and apparatus for simultaneously handling multiple television programmes
RU2575242C1 (ru) Способ и устройство условного доступа для одновременной обработки нескольких телевизионных программ
WO2013143951A1 (en) Conditional access method and apparatus for simultaneously handling multiple television programmes
GB2500616A (en) Concurrent decoding of a composite packetized audio-video data stream according to packet arrival times

Legal Events

Date Code Title Description
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04N 21/418 , H04N 21/426 , H04N 21/434 , H04N 21/436 , H04N 21/4405

Ipc: H04N 21/418 (2011.01), H04N 21/426 (2011.01), H04N

B11B Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements
B350 Update of information on the portal [chapter 15.35 patent gazette]