PT1281279E - Mecanismo motor de processamento de dados genéricos - Google Patents

Description

DESCRIÇÃO

"MECANISMO MOTOR DE PROCESSAMENTO DE DADOS GENÉRICOS" CAMPO DA INVENÇÃO A presente invenção refere-se geralmente a um mecanismo motor genérico para processar dados, e mais particularmente, a um sistema e método para um mecanismo motor genérico para processar pedidos de aplicação para dados formatados, tais como informações relacionadas com televisão num sistema de televisão interativo.

ANTECEDENTES 0 documento n° US 5,844,620 descreve um guia de interface visual interativo em ecrã que guia um usuário através de um menu de eventos individuais disponíveis através de uma rede de informações. O documento n° US 5,847,751 descreve uma arquitetura de rede para entrega de difusão e serviços digitais interativos ao longo de um sistema de distribuição híbrida fibra-cabo coaxial. O documento n° US 5,734,589 descreve um terminal de entretenimento digital que inclui um módulo de interface de rede que acopla o terminal a um tipo especifico de rede de comunicação para receber um canal de banda-larga digital.

Um fornecedor de serviço de difusão transmite fluxos de áudio e vídeo para uma televisão do espetador. Sistemas de televisão interativa têm capacidade para exibir imagens gráficas e de texto além de programas áudio-vídeo típicos. Os mesmos podem também fornecer um número de serviços, tais como comércio através da televisão e outras aplicações interativas para espetadores. 0 sinal de televisão interativa pode incluir uma porção interativa que consiste no código de aplicação, dados e informações de sinalização, além de porções áudio-vídeo. A abreviação "SI" nessa aplicação é utilizada para se referir tanto a informações de sinalização como a qualquer um dos dados de aplicação enviados de acordo com um formato rígido. 0 SI pode incluir informações, tal como horários ou canais nos quais um programa de televisão particular será mostrado, o género de um programa particular, ou informações que identificam qual dos fluxos elementares transportará o áudio para um programa particular numa linguagem particular. Essas informações podem ser combinadas num sinal único ou em vários sinais, sendo que a transmissão para um recetor ligado à televisão do espetador ou ao fornecedor pode incluir apenas um subconjunto das informações, possivelmente com localizadores de recurso. Tais localizadores de recurso podem ser utilizados para indicar fontes alternativas de informações interativas e/ou áudio-vídeo. Por exemplo, o localizador de recurso poderia tomar a forma de um localizador de recurso universal world wide web (URL). 0 sinal de televisão é geralmente compactado antes da transmissão e transmitido através de média de difusão típicos tais como linhas de televisão por cabo (CATV) ou sistemas de transmissão por satélite diretos. As informações referidas por localizadores de recurso podem ser obtidas por diferentes médias, por exemplo, através de um canal de devolução sempre ligado, tal como um modem DOCSIS.

Um descodificador recetor integrado (IRD) controla a funcionalidade interativa da televisão. 0 IRD recebe o sinal, separa a porção interativa da porção áudio-vídeo e descompacta as respetivas porções do sinal. 0 IRD usa parte das informações interativas para executar uma aplicação enquanto parte das informações áudio-vídeo é transmitida para a televisão.

Um mecanismo motor de SI executa dentro de um IRD, filtrando os fluxos de difusão, extraindo informações solicitadas por aplicações, e entregando informações a aplicações. Tais mecanismos motores de SI são tipicamente construídos para usar com uma especificação de SI particular que é projetada para um cabo particular, satélite, RF ou outro sistema. Isto é, o código para o mecanismo motor de SI é adaptado diretamente ao formato de SI utilizado por esse sistema. Em resposta a um pedido da aplicação para dados, o mecanismo motor de SI define máscaras para filtros, modifica máscaras, recebe informações dos filtros e devolve as informações às aplicações. A codificação de SI no fluxo de dados é dependente do formato utilizado num sistema particular e varia tipicamente de um sistema para outro, assim como lentamente ao longo do tempo no mesmo sistema.

Assim, se for suposto um sistema diferente usar uma diferente especificação de SI, um novo mecanismo motor, possivelmente derivado de um mecanismo motor existente, deve ser construído. Especificações SI são muitas vezes modificadas após um sistema ser instalado, com o propósito de, por exemplo, fornecer funcionalidade adicional. Nesses casos, o mecanismo motor de SI em tais sistemas deve ser dinamicamente atualizado. Por o mecanismo motor de SI ser normalmente incorporado quer no sistema operativo quer no middleware que executa no IRD, a instalação e/ou modificação é logisticamente complexa, muitas vezes cara e certamente morosa. É também possível transmitir sempre informações de formatação (tal como etiquetas HTML) juntamente com dados formatados, no entanto, essa solução não é viável onde a largura de banda é limitada, como é o caso com metadados relacionados com televisão, porque, em tais casos, transmitir os dados de formato em si cada vez que os dados formatados são enviados necessitaria uma maior ordem de grandeza de largura de banda.

Existe, portanto, uma necessidade de um mecanismo motor de SI aperfeiçoado capaz de processar qualquer formato de SI, que possa ser atualizado facilmente e sem necessitar um uso contínuo de largura de banda preciosa ao sistema de difusão.

SUMÁRIO DA INVENÇÃO

De acordo com um primeiro aspeto da invenção é fornecido um recetor para processar dados em que o dito recetor compreende um mecanismo motor de processamento de dados genéricos configurado para: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; configurar o dito mecanismo motor para processar dados que são formatados de acordo com a definição de formato, responsivo para receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar o dados adicionalmente recebidos em concordância com a definição de formato.

De acordo com um segundo aspeto da invenção é fornecido um sistema para processar dados formatados, que compreende: um transmissor configurado para transmitir uma definição de formato associada com os dados, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; e o recetor de acordo com o primeiro aspeto.

De acordo com um terceiro aspeto da invenção é fornecido um método para atualizar um mecanismo motor de processamento de dados genéricos operável para processar dados independentes das informações de formatação, que compreende: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; configurar o dito mecanismo motor para processar dados que são formatados de acordo com a definição de formato, responsivo para receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar os dados adicionalmente recebidos em concordância com a definição de formato.

De acordo com um quarto aspeto da invenção é fornecido um produto programa de computador para processar dados formatados, que compreende um meio utilizável por computador que tem um código legível por máquina incorporado em si para: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; configurar um mecanismo motor de processamento de dados responsivo para receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar os dados adicionalmente recebidos em concordância com a definição de formato.

Um mecanismo motor de processamento de dados genéricos é operável para receber uma definição de formato e processar dados formatados de acordo com a definição, sem utilização das informações de formatação nos dados.

Numa modalidade, a definição de formato inclui uma descrição da sintaxe do formato e uma descrição da semântica do formato. A sintaxe e semântica podem ser descritas na mesma linguagem ou em diferentes linguagens, e o mecanismo motor é configurado para produzir uma representação interna da sintaxe e semântica. 0 mecanismo motor pode ser configurado para receber consultas e usar as mesmas em conjunto com a representação interna para definir máscaras para os filtros. Os filtros aplicam as máscaras aos dados e devolvem dados filtrados ao mecanismo motor, o qual pode reencaminhar uma porção dos dados filtrados para as aplicações, armazenar uma porção dos dados filtrados, definir novas máscaras baseadas numa porção dos dados filtrados, ou modificar as máscaras existentes baseadas numa porção dos dados filtrados. Os filtros podem também ser configurados para devolver dados filtrados diretamente às aplicações, contornando o mecanismo motor. Métodos e produtos de programa de computador em concordância com os supracitados são também revelados.

Outras caracteristicas, vantagens e modalidades da invenção serão aparentes às pessoas versadas na técnica a partir da seguinte descrição, desenhos e reivindicações.

BREVE DESCRIÇÃO DOS DESENHOS A Figura 1 é um diagrama que ilustra a prática corrente de substituição de software de mecanismo motor de SI quando uma versão diferente é necessária para processar uma diferente especificação de SI; A Figura 2 é um diagrama que ilustra um processo idealizado para mudanças de mecanismo motor de SI para novos "mercados horizontais de sinal aberto"; A Figura 3 é um diagrama que ilustra o mecanismo motor de SI genérico e sua reconfiguração para usar uma nova especificação de SI; A Figura 4 é um diagrama que ilustra a distribuição de programas de televisão e informações de sinalização desde uma estação de difusão até uma estação de receção; A Figura 5 é um diagrama que ilustra uma caixa descodificadora que incorpora um mecanismo motor de SI genérico numa modalidade da invenção; A Figura 6 é um diagrama que ilustra uma modalidade dos componentes funcionais de um mecanismo motor de SI genérico e a interação dos mesmos; A Figura 7 ilustra uma modalidade de uma linguagem de especificação de sintaxe SI; A Figura 8 ilustra uma modalidade de uma especificação da sintaxe para parte de um formato de SI; A Figura 9 ilustra uma modalidade de uma estrutura de dados que pode ser utilizada para armazenar uma representação interna de uma descrição de formato de sintaxe SI;

As Figuras 10a e 10b ilustram uma modalidade de parte de uma especificação de um sistema particular para a semântica do respetivo SI;

As Figuras 11a e 11b ilustram uma modalidade de uma gramática que define a sintaxe para os não-terminais de parte de uma linguagem particular de semântica de SI;

As Figuras 12a, 12b e 12c ilustram uma modalidade de uma estrutura de dados que pode ser utilizada para armazenar uma representação interna de uma descrição de formato de semântica de SI; A Figura 13 ilustra uma modalidade de uma consulta de aplicação para informações de SI utilizando uma linguagem de consulta de baixo nível; A Figura 14 é um diagrama de blocos que mostra a relação entre várias estruturas de SI descritas no pedido de aplicação mostrado na Figura 13; A Figura 15 ilustra uma modalidade na qual são especificadas semânticas complexas de uma restrição num pedido de aplicação; A Figura 16 ilustra uma modalidade na qual Prolog é utilizada para definir a semântica de parte de um SI do sistema;

As Figuras 17a = 17f ilustram especificações numa modalidade de semântica para um formato de SI complexo; A Figura 18 ilustra uma modalidade de um pedido de aplicação expresso utilizando o formato de SI cuja semântica é definida nas Figuras 17a a 17f; e A Figura 19 ilustra um fluxo de processo em concordância com a invenção.

Caracteres de referência correspondentes indicam partes correspondentes ao longo das várias vistas dos desenhos.

DESCRIÇÃO DETALHADA DA INVENÇÃO A seguinte descrição é apresentada para permitir a uma pessoa de habilidade comum na técnica fazer e usar a invenção. Descrições de modalidades especificas e aplicações são fornecidas apenas como exemplos e várias modificações serão imediatamente aparentes às pessoas versadas na técnica. Os princípios gerais descritos no presente documento podem ser aplicados a outras modalidades e aplicações sem se afastar do escopo da invenção. Assim, a presente invenção não deve ser limitada às modalidades mostradas, mas deve estar de acordo com o escopo mais amplo concordante com os princípios e características descritos no presente documento. Será compreendido por uma pessoa versada na técnica que muitas modalidades são possíveis, tais como o uso de um sistema de computador e visor para realizar as funções e características descritas no presente documento. Para efeitos de clareza, a invenção será descrita na aplicação da mesma a uma caixa descodificadora utilizada com uma televisão, e detalhes relacionados com material técnico que são conhecidos nos campos técnicos relacionados com a invenção não foram incluídos.

Vista Geral

Como será descrita no presente documento, a presente invenção refere-se a um mecanismo motor para processar rigidamente dados formatados. Por meio de ilustração não limitativa, a invenção será descrita em aplicação da mesma para processamento de difusão de metadados relacionados com televisão (tal como SI) num recetor-descodificador integrado (IRD), o qual pode, por exemplo, ser implementado numa televisão, incorporado num gravador de vídeo pessoal (PVR), ou estar numa caixa descodificadora separada. 0 termo "metadados" como utilizado no presente documento deve ser compreendido como referência a qualquer espécie de dados formatados, e os princípios da invenção podem-se aplicar a outras aplicações que envolvam a utilização de dados formatados que não se refiram necessariamente à televisão, tais como dados de previsão meteorológica. Também, os dados podem ser transmitidos por outros meios que não difusão, tais como multidifusão e ligações ponto-a-ponto. São revelados no presente documento um método e um sistema para um mecanismo motor de SI genérico que processe pedidos de aplicação para metadados formatados relacionados com televisão.

Mecanismos motores de SI são utilizados para apoiar aplicações interativas de televisão digital. Ambos o mecanismo motor de SI e as aplicações interativas digitais executam num descodificador recetor integrado (IRD). Como afirmado acima, o IRD pode ser implementado numa caixa descodificadora, numa televisão, ou noutro dispositivo.

Aplicações de televisão interativas digitais muitas vezes exigem acesso a informações atualizadas que estão a ser enviadas por uma difusora ou operador de sistema, tais como horários ou canais nos quais um programa particular de televisão será mostrado, o género de um programa particular, ou informações que identifiquem que fluxo elementar irá suportar o áudio numa linguagem particular. SI pode também incluir quaisquer dados cujo propósito seja descrever outros dados ou conteúdo televisivo.

Normalmente, SI é enviado, embutido no fluxo da transmissão, de acordo com um formato rígido. A SI não é autodescritiva, isto é, não existem quaisquer informações embutidas na SI que descrevam o formato do mesmo, como etiquetas. Em mercados em que a difusora ou operador de rede fornece o IRD, cada difusora ou operador de rede decide, por fim, o formato particular utilizado para SI para a rede do mesmo, enquanto em mercados em que o consumidor pode ter adquirido qualquer de um número de IRDs comercialmente disponíveis, múltiplos formatos de SI podem ser utilizados simultaneamente. Normalmente, um formato é baseado numa das várias especificações de formato de SI que foram desenvolvidas por organismos de normalização, tais como DVB (Difusão de Vídeo Digital) ou ATSC (Comité de Sistemas Televisivos Avançados). Essas especificações foram escritas para que as mesmas possam facilmente ser estendidas para adaptar necessidades adicionais de outros, tais como difusoras individuais ou subcomités do mesmo organismo de normalização que tratam de problemas diferentes. Essa flexibilidade é normalmente fornecida ao reservar alguma sequência de bits em várias posições para definição tardia, isto é, se um comité viu uma necessidade para apenas 3 valores diferentes, pode deixar que 3 ou 4 bits permitam até 5 ou 13 usos adicionais, respetivamente, para um dado campo. No entanto, uma vez que um valor seja escolhido para significar um uso particular, o formato é rígido até que novos usos sejam adicionados. Quando novos usos são adicionados, o formato deve ser alterado para refletir a designação de valores aos novos usos.

Frequentemente, os descodificadores de recetor integrado têm filtros que podem ser utilizados para pesquisar rapidamente através de fluxos de dados para a presença de padrões de dados particulares. Os mecanismos de SI tipicamente definem máscaras para estes filtros. Uma máscara é utilizada para descrever um padrão de dados particular. Por exemplo, a máscara binária lllxxOOO identifica o padrão de três ls, seguida por quaisquer dois bits, seguida por três Os. Além de designar um padrão, uma máscara pode designar posição; por exemplo, estipular que tal padrão binário deve ocorrer no início de um pacote de tamanho fixo. A SI é enviada num formato rígido de modo que os filtros, frequentemente implementados em hardware, podem separar eficazmente as informações desejadas pela aplicação ou espetador utilizando o IRD. Outros IRDs que são utilizados por outros espetadores podem filtrar para outras informações, dependendo das preferências de espetadores e/ou aplicações sendo executadas. Tipicamente, o espetador interage com o IRD ao pressionar botões no comando à distância ou teclado que, por sua vez, faz com que informações sejam entregues a software no nível de aplicação a executar num processador no IRD. A fim de prestar o serviço do pedido de um espetador, o software de aplicação pode precisar aceder alguns dos dados da porção de SI de um fluxo que está a ser recebido. 0 software de aplicação pediria, então, estes dados do mecanismo motor de SI que executa no IRD.

Assim como o software no nível de aplicação, o mecanismo motor de SI pode ser software, embora tipicamente no nível de OS ou middleware em vez de ser no nível de aplicação, que executa no IRD, embora possa também ser implementado em hardware. Sua função é a de auxiliar o software no nível de aplicação a obter eficazmente informações de SI do fluxo transmitido. Quando um mecanismo motor de SI recebe um pedido de um programa de aplicação, o mesmo irá usar os filtros subjacentes (que podem ser implementados em hardware) para obter as informações solicitadas pela aplicação.

Por exemplo, a aplicação pode pedir os nomes de todos os filmes que serão difundidos entre 9 p.m. daquele dia até 1 a.m. do dia seguinte num conjunto de 16 canais diferentes, numerados em 16 a 31. Num determinado formato de SI, isto pode traduzir para um conjunto de possíveis padrões de bit nos primeiros 13 bytes de um pacote de MPEG-2 juntamente com determinada estrutura mais atrás no pacote. Um IRD particular pode conter hardware de propósito especial que tem capacidade para filtrar nos primeiros 8 bytes de um pacote. 0 mecanismo motor de SI poderia então criar um conjunto de máscaras para fornecer aos filtros, de modo que os filtros descartariam quaisquer pacotes que não correspondem a um dos padrões de 8 bytes viáveis dos elementos do conjunto desejado. Isto reduz o número de pacotes inteiros que o próprio mecanismo motor de SI precisaria processar, isto exige que o mecanismo motor de SI entenda tanto a estrutura rígido na qual SI é enviada por uma dada rede, quanto o significado atrás dos padrões de bit particulares que aparecem naquela estrutura. SI é tipicamente transmitido por difusoras de televisão juntamente com vídeo, áudio e outros dados privados. As estruturas de dados nas quais o SI é contido estão num estado de fluxo, devido a aprimoramentos e mudanças por organismos de padrões internacionais e difusoras e, em alguns casos, estruturas inteiramente novas são definidas, resultando em mudanças na especificação de SI. 0 mecanismo motor de SI deve ser capaz de lidar com dados na especificação de SI alterada. Como será revelado no presente documento, a presente invenção fornece um mecanismo motor de SI flexível com capacidade para lidar com qualquer especificação de SI transmitida ao mesmo em concordância com a invenção, permitindo que o mesmo seja facilmente atualizado para uma especificação de SI revisada.

Embora a aplicação do mecanismo motor de SI num sistema de difusão de televisão possa não exigir que tenha capacidade para processar mais do que um formato de SI simultaneamente, um mecanismo motor de SI genérico que pode ser configurado para processar qualquer formato de SI tem várias vantagens. Tal software pode ser testado mais a fundo do que sua contraparte não genérica e, mais importante, é substancialmente mais fácil de atualizar para novas versões do formato de SI. Além disto, o tempo de definição de um novo formato de SI para o uso daquele formato pode ser substancialmente reduzido. Com típicos mecanismos de SI, qualquer mudança na definição de SI precisa de uma mudança no software de sistema que executa no descodificador recetor integrado (IRD). Assim, as difusoras não podem usar uma nova definição de SI até: (i) o novo software ter sido projetado, escrito e testado; e (ii) todos os descodificadores de recetor integrado terem sido atualizados, incluindo aqueles atualmente em uso por consumidores. A Figura 1 ilustra uma situação que não usa o mecanismo motor de SI genérico para um mercado vertical (um mercado em que o IRD é concedido pelo operador de sistema ou difusora). Aqui, pelo menos o software para o mecanismo motor de SI deve ser reinstalado. A dificuldade de atualizar o software num ambiente de difusão é agravada pela natureza do sistema. 0 software a ser reinstalado deve ser continuamente difundido se não houver mecanismo disponível para permitir a transferência por download através de um canal de devolver. Mesmo se houver um canal de devolução, um sinal para indicar a disponibilidade da nova versão deve ser difundido repetidamente, porque nem todos os IRDs serão necessariamente ligados ao mesmo tempo. Além disto, o uso do novo formato provavelmente seria atrasado até uma percentagem substancial dos IRDs ter sido atualizada.

Numa abordagem conhecida como o "mercado horizontal", os fabricantes do descodificador recetor integrado irão fabricar e vender descodificadores independentes de operador. Estes descodificadores serão úteis para qualquer consumidor, independentemente de o operador ser utilizado pelo consumidor. No entanto, esta abordagem é complicada pelo desejo das difusoras de difundir sua própria sinalização, que pode não ser completamente padrão e, assim, o fabricante teria que produzir um mecanismo motor de SI diferente para cada especificação de SI com a qual desejasse ser compatível. Como ilustrado na Figura 2, quando várias difusoras diferentes têm padrões modificados para seus próprios sistemas, o mecanismo motor de SI deve ter capacidade para acomodar múltiplos formatos de SI diferentes, simultaneamente. Adicionalmente, se uma nova especificação de SI é introduzida mais tarde ou uma especificação existente é atualizada, o descodificador não terá um mecanismo motor de SI para processar a nova especificação de SI, e deve ser atualizada com novo software de mecanismo motor de SI na maneira ilustrada pela Figura 1. Em outras palavras, este cenário exigiria que todos os formatos de SI sejam definidos antes da construção do mecanismo motor de SI, de outro modo o mecanismo motor de SI teria que ser atualizado, como descrito anteriormente.

Um mecanismo motor de SI genérico em concordância com a invenção permite que uma difusora ou operador de sistema configure o mecanismo motor de SI de modo que possa lidar com a sinalização da difusora, por difusão de uma descrição do SI numa linguagem compreendida pelo mecanismo motor de SI genérico. Mediante a receção da descrição, o mecanismo motor de SI genérico reconfigura a si mesmo para lidar com a nova sinalização, como mostrado na Figura 3. Ao utilizar o mecanismo motor de SI reconfigurável da invenção, o descodificador recetor integrado não é mais necessário para conter software especifico para lidar com cada formato de sinalização de operador. Nenhum código fonte precisa ser escrito ou modificado a fim de utilizar um novo formato de SI, e o software para o mecanismo motor de SI não exige modificação ou substituição. Apenas uma descrição da nova sintaxe de formato de SI (estrutura) e semântica (significado) deve ser concedida ao mecanismo motor de SI. Estas informações são tipicamente muito menores do que um novo mecanismo motor de SI e é muito mais fácil de instalar do que o novo software. Finalmente, a probabilidade de introduzir incompatibilidades com o software existente instalado é eliminada, porque o próprio software não precisa ser alterado.

Numa modalidade da invenção, o mecanismo motor de SI compreende uma interface de aplicação, uma interface de filtragem e uma interface de especificação de formato. A interface de aplicação é responsável por receber pedidos de aplicações, e pode também ser utilizada para retornar informações àquelas aplicações. A interface de filtragem é utilizada para construir ou modificar máscaras para filtros, que pode ser implementada em hardware ou software. Como dados são recebidos de um fluxo de difusão (ou através de outro meio, tal como uma ligação ponto-a-ponto) e processados pelos filtros, os dados extraídos pelos filtros podem ser fornecidos ao mecanismo motor de SI genérico ou diretamente às aplicações. Antes de fornecer informações obtidas através dos filtros até as aplicações, o mecanismo motor de SI genérico pode processar aqueles dados, e, ao fazê-lo, pode definir máscaras adicionais ou modificar máscaras existentes. A interface de especificação de formato tem capacidade para receber e processar descrições de novos formatos, que podem mais tarde ser utilizadas por aplicações quando as mesmas fazem pedidos através da interface de aplicação. Os dados formatados e as especificações de formato podem ser embutidos num fluxo de difusão de televisão ou ser transmitidos separadamente por outros meios, tal como multidifusão ou uma ligação ponto-a-ponto. A sintaxe e semântica de novos formatos podem ser transmitidas separadamente uma da outra, ou juntas.

Se uma nova especificação de formato está a ser utilizada, a mesma pode ser transmitida ao mecanismo motor de SI genérico, que será reconfigurado para usar a nova especificação de formato. A operação do mecanismo motor de SI genérico será descrita no presente documento a título de referência a seu uso, numa modalidade da invenção, como um componente de sistemas de televisão interativa distribuídos.

Descrição Detalhada

Referindo-se à Figura 4, um diagrama de uma difusão de televisão e sistema de receção é mostrado e geralmente indicado como 10. O sistema 10 inclui uma estação de difusão 12 em que informações de áudio-vídeo e controlo são montados na forma de dados digitais e mapeados em sinais digitais (que também podem ser analógicos) para transmissão por satélite a uma estação de receção. A difusora pode incluir metadados rigidamente formatados e relacionados à televisão, denominados SI. O SI é embutido no fluxo de difusão. O SI pode, por exemplo, listar cada um dos identificadores de fluxo elementar e associar a cada identificador uma codificação que descreve o tipo do fluxo associado (por exemplo, caso o mesmo contenha vídeo ou áudio, qual perspetiva representa, ou qual linguagem está a ser portada no fluxo), informações de programa de televisão, tais como hora, data, e canal, o SI é convertido pela estação de difusão a um formato adequado para transmissão através de meio de difusão. Os dados podem ser formatados em pacotes, por exemplo, que podem ser transmitidos através de uma rede de satélite digital 22, fios de televisão por cabo, linhas telefónicas, redes celulares, fibras óticas, ou qualquer outra média adequada. Os pacotes podem ser multiplexados com outros pacotes para transmissão. A estação de receção inclui um descodificador recetor integrado na forma de uma caixa descodificadora 16, ligada a um dispositivo de armazenamento 18 e uma televisão 20 que é utilizada para apresentar programas a um espetador, como mostrado na Figura 5. A caixa descodificadora 16 é operável para descompactar os dados digitais. Os sinais de vídeo descompactados podem ser convertidos em sinais analógicos, tal como sinais de formato de NTSC (Comité Nacional de Padrões de Televisão) para exibição em televisão, ou podem ser em formato digital para uso por um visor digital de televisão. A caixa descodificadora 16 compreende, ainda, um mecanismo motor de SI genérico 36, que compreende uma interface de aplicação, uma interface de filtragem, e uma interface de especificação de formato, como descrito no presente documento. Os sinais enviados à caixa descodificadora 16 são filtrados pelo estágio de transporte 28 sob a direção do mecanismo motor de SI genérico 36, e daqueles que atendem às exigências de filtragem, alguns podem ser utilizados pelo processador 30 imediatamente, enquanto outros podem ser colocados em armazenamento local, tal como RAM ou dispositivo de armazenamento 18. Exemplos de exigências que precisariam ser filtradas para incluir um valor particular no local reservado para um identificador de fluxo elementar ou um identificador de rede de origem. A caixa descodificadora 16 pode ser utilizada para sobrepor ou combinar diferentes sinais para formar a exibição desejada numa televisão do espetador 20.

Os sinais de áudio-vídeo e sinais de controlo de programa recebidos pela caixa descodificadora 16 correspondem a programas de televisão e seleções de menu que o espetador pode aceder através de uma interface de usuário, assim como aplicações que podem ser executadas, por exemplo, interpretadas, pelo processador de controlo 30. O espetador pode controlar a caixa descodificadora 16 através de uma unidade de comando à distância infravermelho, um painel de controlo na caixa descodificadora, ou um menu exibido no ecrã de televisão, por exemplo. Seleções e entradas feitas pelo espetador podem, por sua vez, fazer com que aplicações mudem suas exigências de filtragem e enviem pedidos ao mecanismo motor de SI 36 para mudar as máscaras para os filtros e receber informações baseadas nas exigências de filtragem modificadas. A caixa descodificadora 16 pode ter capacidade para descodificar vídeo, áudio e dados. Numa modalidade, a mesma pode ser uma caixa descodificadora digital para usar com um satélite recetor ou recetor de descodificador integrado por satélite que tem capacidade para descodificar vídeo MPEG, áudio e dados. A caixa descodificadora 16 pode ser configurada, por exemplo, para receber canais de vídeo digital que apoiam comunicações por banda-larga utilizando Modulação de Amplitude em Quadratura (QAM) e para controlar canais para sinalização de duas vias e mensagens. Os canais de QAM digital portam fluxos de transporte de MPEG (Grupo de Peritos de Imagem em Movimento) de múltiplos programas compactados e codificados. Um estágio de transporte 28 extrai o programa desejado do fluxo de transporte e separa os componentes de áudio, vídeo e dados, que são encaminhados para dispositivos que processam os fluxos, tal como um ou mais descodificadores de áudio, um ou mais descodificadores de vídeo, e opcionalmente para RAM (ou outra forma de memória) ou um disco rígido. Deve ser compreendido que a caixa descodificadora 16 e o dispositivo de armazenamento 18 (assim como quaisquer dados e sinais do fornecedor de serviço de difusão) podem ser analógicos, digitais, ou tanto analógicos quanto digitais. 0 dispositivo de armazenamento 18 é opcionalmente acoplado à caixa descodificadora 16. 0 dispositivo de armazenamento 18 é utilizado para fornecer armazenamento suficiente para registrar programas e dados que não se encaixarão na quantidade limitada de memória principal (por exemplo, RAM) tipicamente disponíveis em caixas descodificadoras. 0 dispositivo de armazenamento 18 pode compreender qualquer dispositivo de armazenamento adequado, tal como uma unidade de disco rígido, uma unidade de DVD gravável, fita magnética, disco ótico, disco magneto-ótico, memória flash, ou memória de estado sólido, por exemplo. 0 dispositivo de armazenamento 18 pode ser interno à caixa descodificadora 16 ou ligado externamente (por exemplo, através de uma ligação IEEE 1394-1995) com uma ligação permanente ou uma ligação removível. Mais do que um dispositivo de armazenamento 18 pode ser fixado à caixa descodificadora 16. A caixa descodificadora 16 e/ou o dispositivo de armazenamento 18 pode também ser incluído num pacote com um aparelho de televisão 20. A caixa descodificadora 16 geralmente inclui um processador de controlo 30 compreendido por uma unidade de controlo (por exemplo, microprocessador), memória principal (por exemplo, RAM) , e outros componentes que são necessários para processar o sinal de televisão interativa recebido.

Como mostrado na Figura 5, a caixa descodificadora 16 inclui uma extremidade frontal 26 operável para receber áudio, vídeo e outros dados da estação de difusão 12. A fonte de difusão é alimentada à caixa descodificadora 16 na extremidade frontal 26, que compreende um conversor analógico para digital (A/D) e sintonizador/ desmoduladores (não mostrado). A extremidade frontal 26 exclui por filtragem uma banda particular de frequências, desmodula a mesma, e converte-a num formato digital. A emissão digitalizada é, então, enviada a um estágio de transporte 28. O estágio de transporte 28 processa, adicionalmente, os dados, enviando uma porção dos dados a um estágio audiovisual (AV) 34 para exibição e outra porção ao processador de controlo 30, e excluindo por filtragem o restante dos dados. Informações de sinalização e controlo também podem ser registadas como difusão juntamente com os dados de áudio-video ou podem ser primeiro manipuladas por software dentro da caixa descodificadora 16.

Deve ser compreendido que o sistema 10 descrito no presente documento é apenas um exemplo de um sistema utilizada para transportar sinais para uma televisão 20. O sistema de rede de difusão e a caixa descodificadora 16 podem ser diferentes do que o descrito no presente documento sem divergir do escopo da invenção. Por exemplo, vários componentes retratados na caixa descodificadora 16 da Figura 5 podem ser combinados, tal como a colocação de mecanismo motor de SI 36 dentro do processador 30 ou parcialmente no estágio de transporte 28 e no processador de controlo 30, ou a integração de dispositivo de armazenamento 18 dentro da caixa descodificadora 16. O mecanismo motor de SI genérico A construção do mecanismo motor de SI genérico envolve o seguinte: — definir/selecionar uma linguagem para expressar a sintaxe do SI ou metadados formatados. — definir/selecionar uma linguagem para expressar a semântica dos metadados de SI. Esta linguagem pode ser a mesma linguagem que a definida para expressar a sintaxe, uma extensão da linguagem definida para expressar a sintaxe, ou uma linguagem diferente. — definir/selecionar uma linguagem para expressar consultas de SI. Esta linguagem pode ser a mesma que a(s) linguagem(s) definida (s) para expressar sintaxe e semântica, uma extensão, ou uma linguagem diferente. - construir um mecanismo motor de SI genérico que compreende descrições de SI escritas na(s) linguagem(s) para expressar sintaxe e semântica, e podem usar aquelas descrições para obter informações de SI em resposta a um pedido de programa de aplicação. Numa modalidade da invenção, o mecanismo motor de SI genérico é configurado para converter versões transmitidas da sintaxe de SI e definição de semântica de SI em representações internas a serem armazenadas pelo mecanismo motor de SI. 0 mecanismo motor de SI genérico é ainda configurado para usar a estrutura das representações internas da(s) definição(ões) de SI para responder a consultas para SI.

Um versado na técnica observará que as etapas acima não precisam de ser realizadas na ordem listada acima.

Consequentemente, numa modalidade da invenção, uma linguagem para expressar a sintaxe e semântica de uma definição de SI é definida, embora outra modalidade possa usar linguagens separadas para a sintaxe e semântica. Esta linguagem para a sintaxe e semântica é utilizada para expressar o formato no qual os dados de SI serão transmitidos, assim como as relações entre dados nas mesmas estruturas transmitidas ou em estruturas diferentes. Também é definido um método para processar, de modo inteligente, a(s) especificação(ões) de SI que são escritas naquela linguagem ou aquelas linguagens. Além de uma ou mais linguagens para especificar a sintaxe e semântica do formato de SI, uma linguagem é exigida para uso por aplicações ao fazer pedidos para dados de SI particulares. Os pedidos das aplicações devem corresponder a termos identificados nas definições de sintaxe e semântica, de modo que o mecanismo motor de SI genérico possa produzir máscaras e filtrar e processar adicionalmente dados a serem devolvidos à aplicação. A Figura 6 ilustra a arquitetura de um mecanismo motor de SI genérico 36 numa modalidade da invenção. 0 mecanismo motor de SI genérico 36, que é mostrado dentro de caixa descodificadora 16, mas poderia ser implementado em outro tipo de IRD ou colocado no interior de uma televisão, compreende uma interface de especificação de formato 60, uma interface de aplicação 70 e uma interface de filtro 80.

Numa modalidade, a reconfiguração do mecanismo motor de SI genérico procede conforme segue. Quando o mecanismo motor de SI genérico recebe uma descrição de um novo formato de SI ou uma descrição de um melhoramento para um formato de SI existente, o mesmo irá usar a descrição para criar um conjunto de estruturas de dados. Estas estruturas de dados podem ser utilizadas para configurar, ou para reconfigurar, o mecanismo motor de SI genérico e podem ser utilizadas pelo mecanismo motor de SI genérico para determinar como lidar com pedidos de aplicações para dados de SI, e como lidar com dados recebidos dos filtros.

Numa modalidade, quando o mecanismo motor de SI genérico recebe um pedido de uma aplicação para dados de SI particulares, o mecanismo motor de SI genérico usa as estruturas de dados mencionadas acima e outras estruturas de dados armazenadas no IRD para determinar como os filtros no IRD podem ser melhor utilizados para adquirir as informações solicitadas pela aplicação, ou um superconjunto daquelas informações. 0 pedido da aplicação é convertido pela interface de consulta de SI 70 numa série de pedidos (um ou mais) a serem feitos ao filtro generalizado e gerador de máscara de SI 82. Em resposta a cada um destes pedidos, o filtro generalizado e gerador de máscara de SI 82 cria uma máscara ou um conjunto de máscaras, e escolhe uma ou mais definições de filtros no interior do IRD para usar essas máscaras. Pode haver diferentes tipos de filtros presentes, cada um projetado para filtrar eficazmente informações que foram codificadas num formato de codificação de sistema particular, tal como MPEG ou DSS, por exemplo. O pedido da aplicação inclui, implicitamente (porque estas informações de nivel inferior podem ser definidas pelas especificações SI) ou explicitamente, o formato ou formatos de codificação de sistema particular que devem ser utilizados, assim como a codificação de transporte, tal como MPEG-2 ou DSS, no qual os dados são codificados. Os filtros podem ser hardware ou software, ou uma combinação de ambos. Os filtros usam as máscaras para determinar quais dados retornam ao filtro generalizado e gerador de máscara de SI 82 para processamento adicional, ignorando quaisquer dados que não correspondem ou se encaixam dentro de uma gama especificada pelas máscaras.

Numa modalidade, mediante a receção de dados dos filtros, o filtro generalizado e gerador de máscara de SI 82 usa as estruturas de dados que descrevem a sintaxe e semântica de SI, juntamente com as consultas pendentes atuais, para determinar qual filtragem e processamento adicionais podem ser necessários antes de retornar resultados para a aplicação solicitante. Por exemplo, os filtros podem ter capacidade para filtrar apenas num determinado subconjunto dos bits, deixando o mecanismo motor de SI genérico para realizar a filtragem restante. As capacidades dos filtros particulares poderiam ser armazenadas em estruturas de dados associadas com cada tipo de filtro, por exemplo, num objeto com características de filtro 84. Além disto, informações devolvidas dos filtros podem ser interpretadas pelo filtro generalizado e gerador de máscara de SI 82 para determinar que dados adicionais, que exigem configuração adicional de máscaras e filtros, são necessários. Portanto, os dados devolvidos podem não ser devolvidos imediatamente ou de forma alguma à aplicação, mas, em vez disto, podem ser utilizados para determinar máscaras adicionais para uso pelos filtros. Eventualmente, o filtro generalizado e gerador de máscara de SI 82 receberia todos os dados necessários para satisfazer o pedido da aplicação e coloca em cache/armazena os mesmos ou devolve-os à aplicação, possivelmente após aplicar processamento adicional nos dados. As informações podem ser colocadas em cache em RAM ou em armazenamento local, tal como o dispositivo de armazenamento 18.

Numa modalidade, os filtros podem ser configurados para localizar de modo autónomo e isolar informações exigidas pela aplicação, e devolver as informações solicitadas diretamente para a aplicação em vez de passar a mesma através do mecanismo motor de SI. Adicionalmente, dependendo do tipo de pedido, o mecanismo motor de SI poderia, simplesmente, armazenar um tipo particular de dados buscados pela aplicação até os dados serem especificamente solicitados pela aplicação mais tarde. A interface de especificação de formato 60 compreende um mecanismo motor de inicialização de sintaxe de SI 62 e um mecanismo motor de inicialização de semântica de SI 64. O mecanismo motor de inicialização de sintaxe de SI 62 inclui um mecanismo motor de inicialização, interpretador e analisador léxico configurado para processar descrições escritas na linguagem escolhida ou criada para especificar sintaxe de SI. Similarmente, o mecanismo motor de inicialização de semântica de SI 64 inclui um mecanismo motor de inicialização, interpretador e analisador léxico configurado para processar descrições escritas na linguagem escolhida ou criada para especificar semântica de SI. Se a mesma linguagem for utilizada para expressar a sintaxe e a semântica do SI, então ambos o mecanismo motor de inicialização de sintaxe de SI 62 e o mecanismo motor de inicialização de semântica de SI 64 podem compartilhar alguns dos mesmos componentes. Independentemente de se a sintaxe de linguagem de SI for a mesma como a linguagem de semântica de SI, as representações internas podem ser mantidas como entidades distintas ou podem ser mescladas.

Numa modalidade, a interface de aplicação 70, que é também referida como uma interface de consulta de SI, pode compreender um lexical analisador e um interpretador para processar consultas de aplicações. Estas consultas pedem dados de SI a serem devolvidos às aplicações, ou armazenados em cache. Se a linguagem para descrever as consultas de SI for a mesma que a linguagem utilizada para descrever sintaxe de SI e/ou semântica de SI, a mesma pode compartilhar, por exemplo, a implementação do analisador e interpretador lexical com o mecanismo motor de inicialização de sintaxe de SI 62 e/ou mecanismo motor de inicialização de semântica de SI 64, respetivamente. 0 mesmo caso pode ser utilizado, se escrito com sincronização adequada.

Como mostrado na Figura 6, a interface de filtro 80 compreende um gerador de máscara de SI e filtro genérico 82, e um objeto com caracteristicas de filtro 84. O gerador de máscara de SI e filtro genérico 82 pode ser controlado pelo interpretador na interface de consulta de SI 70. O objeto com caracteristicas de filtro 84 é uma estrutura ou objeto que inclui uma descrição das capacidades de filtro de nivel inferior do IRD, que pode incluir, por exemplo, (i) os tamanhos de pacote associados com o filtro; (ii) o número de bytes no pacote para que a filtragem de hardware esteja disponível; e/ou (iii) se os filtros podem ser configurados para rejeitar determinados padrões de bit em vez de aceitar determinados padrões de bit.

Deve ser compreendido que os componentes descritos acima podem ser implementados como diferentes módulos dentro de um único processamento, como um inteiro integrado, ou como qualquer combinação dos mesmos. Os mesmos podem também ser adicionalmente subdivididos em mais componentes. Se implementados como múltiplos módulos, os mesmos podem ser instanciados como sequências separadas dentro de um único programa de execução, ou como programas separados que se comunicam uns com os outros ou são colocados juntos numa única sequência de um programa de execução. Adicionalmente, as três linguagens (para especificar sintaxe, semântica e consultas de SI) podem ser combinadas numa ou duas linguagens, ou expressas como mais do que três linguagens. A Figura 6 ilustra, utilizando setas, as interações de vários componentes entre si no mecanismo motor de SI. Um fornecedor de serviço de difusão ou operador de sistema transmite um fluxo que compreende uma descrição do sintaxe e semântica de SI, dados de SI, dados de aplicação (incluindo código), áudio, vídeo, e várias outras informações. Deve ser observado que o fluxo pode não necessariamente conter todas estas informações ao mesmo tempo. Mediante a receção do fluxo de bits transmitido pelo IRD, etapa 100, o mecanismo motor de inicialização de sintaxe de SI 62 e o mecanismo motor de inicialização de semântica de SI 64 irão converter suas respetivas descrições de SI para uma ou mais representações internas que podem ser utilizadas por vários outros componentes do mecanismo motor de SI, como indicado pela etapa 102 na Figura 6. O fluxo de bits transmitido pode conter o código de aplicação, que é extraído do fluxo de bits para execução pelo IRD, etapa 104. Alternativamente, a aplicação pode já existir no IRD ou pode ter sido recentemente recebida do fluxo de bits transmitido. Quando a aplicação começa a execução, a mesma pode emitir consultas (também referido como pedidos) para dados de SI particulares, como indicado pela etapa 106, e as consultas são entregues à interface de consulta de SI 70. Os pedidos podem ser síncronos (a aplicação para e aguarda uma resposta) ou assíncronos (a aplicação continua a execução, desempenhando outras tarefas, até a mesma parar por algum outro motivo ou receber uma resposta). Os pedidos podem também ser distintos ou contínuos. Um pedido distinto é um em que as primeiras n instâncias das informações solicitadas são exigidas pela aplicação, em que n é um número inteiro maior do que ou igual a 1. Um pedido contínuo é um em que a aplicação deseja ter novas versões das informações solicitadas continuamente devolvidas para si até cancelar o pedido. Além disto, a consulta da aplicação pode ser classificada como um pedido para dados a ser devolvido assim que possível ou como um pedido para o mecanismo motor de SI para armazenar em cache dados de SI particulares, como os recursos permitem (tal como em RAM ou dispositivo de armazenamento 18). Quaisquer dados armazenados em cache podem então ser solicitados mais tarde.

Numa modalidade da invenção, a interface de consulta de SI 70 transmite os pedidos ao gerador de máscara de SI e filtro genérico 82, etapa 108. O gerador de máscara de SI e filtro genérico 82 podem usar informações armazenadas na representação interna de sintaxe de SI, representação interna de semântica de SI, e objeto com caracteristicas de filtro (etapas 109 e 110) para construir uma sequência de uma ou mais consultas. Por exemplo, a aplicação pode pedir todas as informações de guia de programa eletrónico, que pode corresponder a ter um padrão de bit 01 ou 10, começando no terceiro byte de um pacote. Em resposta, para um tipo de máquina, o gerador de máscara de SI e filtro genérico 82 pode construir duas máscaras, uma para o padrão de bit "01" e um para o padrão de bit "10", e designar cada um a um filtro de hardware diferente. As máscaras podem também ser utilizadas para pesquisar etiquetas, tal como etiquetas XML, que tem valores especificados. Num diferente tipo de máquina, um único filtro de hardware pode ter capacidade para simultaneamente procurar pacotes que correspondem a qualquer máscara.

Esta sequência de consultas pode ser modificada conforme as informações são devolvidas dos filtros no fluxo indicado por 116. Alternativamente, as consultas podem ser construídas pela interface de consulta de SI 70, utilizando linhas de comunicação adicionais (não mostrado) entre a interface de consulta de SI 70 e a interface de especificação de formato 60 ou o gerador de máscara de SI e filtro genérico 82 pode ser combinado com a interface de consulta de SI 70. O gerador de máscara de SI e filtro genérico 82, possivelmente após obter informações das representações internas das descrições de SI e da descrição de filtro, irá compor máscaras adequadas e designar as mesmas aos filtros adequados, como indicado em 112. Os filtros, que podem ser completos ou parcialmente implementados em hardware ou software, usam as máscaras para obter os dados de SI solicitados do fluxo de bits transmitido, etapa 114. Os dados de SI filtrados são então devolvidos ao gerador de máscara de SI e filtro genérico 82, mostrado por fluxo 116. Alternativamente, os dados de SI filtrados poderiam ser devolvidos diretamente a aplicações através de um mecanismo de tratamento de interrupção ou por consulta. Após receber os dados de SI, o gerador de máscara de SI e filtro genérico 82 podem filtrar adicionalmente as informações antes de devolver as mesmas à interface de consulta de SI 70, etapa 118. Conforme citado acima, a interface de consulta de SI 70 e o gerador de máscara de SI e filtro genérico 82 podem ser implementados como um único componente, em cujo caso a interface de consulta de SI 70 (que compreende o gerador de máscara de SI e filtro genérico) realizaria a filtração adicional.

Quando a interface de consulta de SI 70 recebe os dados de SI, a mesma examina as informações e pode tomar qualquer combinação das seguintes ações: - fazer outro pedido ao gerador de máscara de SI e ao filtro genérico 82, baseado nos valores devolvidos pelo gerador de máscara de SI e filtro genérico 82 até então, etapa 108. - fazer outro pedido do gerador de máscara de SI e do filtro genérico 82, independentemente dos valores devolvidos até então. Etapa 108. - Passar as informações devolvidas, possivelmente combinadas com informações previamente devolvidas ou um subconjunto das mesmas, de volta à aplicação que faz a consulta, etapa 120. - Armazenar em cache parte ou todas as informações devolvidas, conforme recursos permitirem. O armazenamento em cache pode ser feito diretamente pelo gerador de máscara de SI e pelo filtro genérico 82, pela interface de consulta de SI 70, ou por um módulo dedicado para alocar recursos para armazenamento em cache e realizar o armazenamento em cache. - Cancelar o pedido para o gerador de máscara de SI e o filtro genérico 82 de modo que os filtros possam ser reutilizados para outro propósito.

Após as informações serem entregues à aplicação na etapa 120, a aplicação pode cancelar o pedido que produziu as informações ou deixar o pedido aberto se o pedido foi continuo. Se o pedido foi distinto, e a interface de consulta de SI 70 devolveu o número de versões solicitado (que, em muitos casos, será um), ou a aplicação pede o cancelamento, a interface de consulta de SI 70 irá cancelar o pedido para o gerador de máscara de SI e o filtro genérico 82 que, por sua vez, irá libertar os filtros.

Um exemplo de uma linguagem de especificação de sintaxe SI utilizável em concordância com a invenção será descrito abaixo. A modalidade revelada é apenas um exemplo de muitas linguagens possíveis que podem ser utilizadas. A mesma é apresentada como uma possível implementação, e não deve ser lida como limitante de qualquer modo ao escopo da invenção. A sintaxe de uma linguagem simples, que permitiria entrada quase verbatim de muitos dos documentos de definição de SI existentes, pode ser expressa em BNF estendida (forma Backus-Naur), como mostrado na Figura 7. Como é típico, □ Dsignifica a cadeia vazia e literais são encerrados em aspas A Figura 8 ilustra uma descrição escrita nesta sintaxe. Esta descrição define parcialmente uma seção de MFEG de SI de DVB (Difusão de Vídeo Digital) que contém uma Subtabela de Informações de Rede. Se um mecanismo motor de SI genérico 36 já estivesse no lugar na extremidade de recetor (por exemplo, num IRD, televisão, ou outro dispositivo), então alguma codificação, talvez de acordo com ASCII ou Unicode, da definição textual da Figura 8 seria transmitida (tal como por difusão, ponto-a-ponto, etc.) para o recetor, talvez como uma seção privada de MPEG-2.

Referindo-se novamente à Figura 8, a definição da Subtabela de Informações de Rede assume que MPEG é utilizado como a codificação de sistema do fluxo de bits. Nesta codificação, a existência da Subtabela de Informações de Rede é sinalizada ao definir o campo definido por MPEG denominado PID (Identificador de Pacote) para o valor 8. A definição também mostra que esta seção é reconhecível por um valor de table_id da seção de 64 ou 65. Tanto o valor de PID quanto o valor de table_id são utilizados nesta linguagem de SI, porque filtros devem ter capacidade para localizar subtabelas parciais que são identificáveis apenas por valores de PID, e não são identificáveis por valores de table_id (tal como se a subtabela for grande demais para caber num único pacote). Os comprimentos de cada campo são dados em números de bits. Tanto "bslbf" quanto "uimsbf" são listados como tipos básicos na tabela interna, com a qual o mecanismo motor teria sido inicializado, que descreve MPEG, um de poucos padrões comummente utilizados.

Este exemplo mostra ciclos dentro de ciclos. Visto que o escopo dos comprimentos de ciclo está dentro do ciclo ou estrutura atual, nenhuma anotação é necessária para identificar o comprimento de ciclo. Dois dos ciclos, o primeiro e o terceiro (que está aninhado no interior do segundo), podem conter descritores, que podem ser qualquer um daqueles listados em "alternativo" porque são conhecidos como NITDescriptor. Acontece que, na definição de SI de DVB, qualquer um de uma longa lista de descritores é possível em inúmeros lugares na maioria das subtabelas (o termo que DVB usa para as estruturas em questão, porém, pode não necessariamente ser em formato tabular). No entanto, a linguagem que é utilizada aqui permite a possibilidade de ter restrições nos tipos de subtabelas nas quais os descritores podem aparecer. Será aparente para um versado na técnica que o exemplo mostrado na Figura 8 é apenas uma descrição parcial. Os campos, tais como network_name_descriptor e data_broadcast_id_descriptor precisariam ser adicionalmente refinados, e as outras subtabelas precisariam ser definidas e a lista exata de descritores seria necessária. A linguagem discutida no presente documento é apenas um exemplo muito simples de uma linguagem que poderia ser utilizada para expressar sintaxe de SI, e há muitas extensões e modificações possíveis que fariam com que ou permitiriam que pessoas escrevessem descrições mais longas ou mais curtas de especificações particulares de SI. Por exemplo, a linguagem acima pode ser melhorada para incluir herança, de modo que uma tabela poderia ser definida para ser quase idêntica à outra tabela, com determinados campos substituídos. Adicionalmente, um melhoramento da linguagem poderia permitir que uma pessoa escrevesse todas as tabelas possíveis nas quais um novo descritor poderia aparecer, em vez de ter que adicionar aquele novo descritor a todas as estruturas adequadas que representam grupos de descritores alternativos para cada tabela dada.

Uma possível implementação de um mecanismo motor de inicialização de sintaxe de SI 62 seria um programa que lê uma descrição dada numa linguagem similar àquela discutida acima e cria estruturas de dados similares àquelas ilustradas na Figura 9, utilizando conjuntos de procedimentos bem conhecidos na técnica. As estruturas de dados podem ser dinamicamente alocadas e povoadas com informações, tal como aquelas da Figura 8, e podem reter qualquer coisa exprimível na linguagem de Figura 7. Estas estruturas de dados correspondem a uma representação interna da sintaxe de SI e seriam mais tarde acedidas por um gerador de máscara e filtro genérico 82, juntamente com possivelmente informações do objeto com características de filtro 84, para permitir que o mesmo localize campos solicitados numa cadeia de bits, assim como para configurar máscaras para filtros de nível inferior.

Devido à grande quantidade de dados num típico fluxo de difusão de televisão digital, a mesma é atualmente impraticável de examinar, dentro de um software de aplicação ou do mecanismo motor de SI, todos os dados de SI contidos dentro do fluxo. Assim, a revelação no presente documento fornece a capacidade para aplicações de fazer dois tipos diferentes de pedidos ao software de nível inferior. 0 primeiro tipo de pedido resulta em dados sendo devolvidos a uma aplicação. A aplicação solicita que estruturas específicas, que podem ser simples ou muito complexas, sejam devolvidas a um software de aplicação se as mesmas tiverem valores particulares em campos especificados. 0 software de camada média iria então configurar máscaras que os filtros de hardware (e possivelmente software) de menor nível utilizariam para limitar o número de candidatos que devem ser adicionalmente analisados e filtrados pela camada média, antes de devolver as estruturas solicitadas a um software de aplicação. 0 segundo tipo de pedido é conhecido como um pedido de armazenamento em cache. Um pedido de armazenamento em cache é quase idêntico a um primeiro tipo de pedido, exceto que as estruturas retiradas do fluxo transmitido não são imediatamente devolvidas a um software de aplicação. Em vez disto, estas estruturas seriam armazenadas em cache, conforme tempo, espaço, e alocação de filtros de hardware permitirem, pela camada média (por exemplo, em RAM, em dispositivo de armazenamento 18, etc.). Os valores armazenados em cache poderiam, então, ser utilizados como uma fonte adicional de informações quando uma aplicação faz um pedido de um primeiro tipo.

Portanto, uma linguagem na qual fazer estes pedidos se faz necessária, embora os conceitos desta invenção não sejam dependentes de qualquer escolha particular de linguagem. É apenas necessário que a linguagem permita um programador de aplicação especifique exatamente as estruturas que devem ser devolvidas ou armazenadas em cache. Uma gama de abordagens poderia ser tomada ao projetar a linguagem para um programador de aplicação usar. Qualquer abordagem especifica é caracterizada pela quantidade de conhecimento que um programador de aplicação deve ter em relação ao significado associado com a sintaxe de SI.

Num extremo da escala, um programador de aplicação compreende tudo sobre a parte do sintaxe e semântica de SI que a difusora ou operador de sistema está utilizando e usa tal entendimento para pedir especificamente estruturas e campos daquelas estruturas. No outro extremo da escala, o programador não compreende qualquer coisa sobre a sintaxe de SI ou semântica subjacente particular, porque a difusora ou operador proporcionou significado a termos de nivel superior, que são expressos na sintaxe e semântica de SI de nivel inferior. Utilizando este segundo modelo, um programador de aplicação pediria informações utilizando apenas estes termos de nivel superior.

Uma modalidade da invenção pode usar uma implementação em algum ponto entre estes dois extremos. Utilizando tal abordagem intermediária, a difusora ou operador de sistema definiria alguns termos de alto nivel que um programador de aplicação pode usar para pedir tipos comuns de dados de SI. Adicionalmente, sob esta abordagem, um programador de aplicação teria a flexibilidade de pedir menos informações comuns ao utilizar conhecimento do formato subjacente de SI. Exemplos destas abordagens são revelados no presente documento. Várias modalidades de consulta e linguagens de especificação de semântica de SI são reveladas abaixo, juntamente com descrições de interfaces de consulta de SI 70 e mecanismos de inicialização de semântica de SI 64 utilizáveis com as linguagens. Estas modalidades são apresentadas com o propósito de ilustrar os conceitos da invenção e são baseadas na suposição de que a sintaxe de SI é especificada na linguagem de especificação de sintaxe SI descrita acima e na Figura 7. Deve ser compreendido que qualquer outra linguagem poderosa o suficiente para descrever a sintaxe de SI pode ser utilizada, e em tais linguagens, uma convenção dependendo da linguagem de especificação de sintaxe SI pode ser adotada. Por exemplo, network_information_section.loop_2.loop_l.transport_ stream_id se referiria a um valor de transport_stream_id no interior do primeiro ciclo que está no interior do segundo ciclo de um network_information_section. Como outro exemplo, network_information_section.loop_l.descritor. service_list_descriptor se referiria a uma coleção de todos os campos de um service_list_descriptor que seria encontrado dentro do primeiro ciclo de um network_information_section, enquanto network_information_section.loop_l.descritor .service_list_descrip tor.service_id se referiria apenas ao campo service_id daquele mesmo descritor. Extensões às convenções sugeridas acima podem ser utilizadas para permitir a identificação de um elemento de SI particular. Adicionalmente, se regras de escopo forem necessárias, as mesmas poderiam ser implícitas ou explícitas. Um exemplo em que regras de escopo são utilizadas é agora mostrado. Considere o caso em que as duas referências a seguir existem: network_information_section.loop_l: named_loop.descritor.service_list_descriptor named_loop.descritor.satellite_delivery_descriptor se as mesmas aparecem dentro do mesmo escopo, este exemplo indica que ambos os descritores devem aparecer no mesmo ciclo de um network_information_section. em contraste, colocar as duas referências a seguir num escopo diferente significaria o mesmo que o seguinte: network_information_section.loop_l.descritor .service_list_descrip tor network_information_section.loop_l.descritor .satellite_delivery_descriptor

Este último exemplo refere-se a dois descritores diferentes, que podem ocorrer na mesma instanciação ou numa instanciação diferente do loop_l.

Numa modalidade, uma linguagem de consulta de alto nível pode ser acoplada com uma linguagem de semântica de SI adequada. Para esta abordagem, duas linguagens adicionais são utilizadas. A primeira linguagem, que é denominada a linguagem de semântica de SI, seria tipicamente utilizada pela difusora ou operador ou seus representantes e contratantes para especificar significados para objetos comumente utilizados em sua representação de SI. A segunda linguagem, que é referida como a linguagem de consulta, faz uso de termos definidos pela difusora na linguagem de semântica de SI. A segunda linguagem permite que um programador de aplicação consulte para informações das representações internas de SI no mecanismo motor de SI genérico 36 sem exigir que um programador de aplicação saiba como as informações são armazenadas dentro das estruturas de SI.

Para ilustrar, adicionalmente, esta modalidade, considere um cenário exemplificativo que demonstra o uso de uma linguagem de semântica de SI que complementa uma linguagem de consulta de alto nível. Palavras-chave das duas linguagens são representadas em negrito neste exemplo. Supondo-se que o espetador selecionasse um "menu configurar guia de TV" que está disponível como uma aplicação na caixa descodificadora (ou TV ou outro dispositivo utilizado para TV interativa). Esta aplicação pode ser transferida por download sob demanda do fluxo de difusão, transferida por download da Internet ou ligação ponto-a-ponto, ou já estar armazenada em cache na caixa descodificadora do espetador. Neste exemplo, o espetador escutou que haverá um festival de John Wayne no canal 17 em algum momento nos próximos dias e deseja determinar se haverá quaisquer filmes de John Wayne, particularmente qualquer um produzido pela empresa de produção Metro-Goldwyn-Mayer, sendo mostrado entre as 7:00 da manhã e as 13:30 do dia corrente. Após o espetador escolher itens de menus adequados e talvez inserir informações (utilizando um comando à distância, teclado, ou outro dispositivo de entrada), a aplicação formula a seguinte chamada ao software subjacente:

Success = 0_si_query("acquire eventInfo where channel ( = 17) and startTime(>=, 25200) and endTime(<=, 48600)and eventType(=, Movie) and itemPair(=, Factor, =, 'John Wayne') and itemPair(=, ProductionCompany, =, 'MetroGoldwynMayr')", &event);

neste exemplo, a aplicação converteu o tempo de inicio e final no número de segundos após meia-noite do dia corrente. A consulta é o componente encerrado em aspas duplas, O remanescente da afirmação acima representa um modo em que a consulta pode ser utilizada dentro de uma interface de programador de aplicação (API).

Algumas suposições simplificadas são feitas nesta ilustração. O SI que a difusora está utilizando para este exemplo é muito similar a SI de DVB, embora uma diferença seja que todos os horários são expressos como o número de segundos após meia-noite, horário local. Além disso, o próprio SI de DVB não fornece maneira de associar o que o espetador pensa como um número de canal (que o espetador insere com o comando à distância, por exemplo) ao terceto que SI de DVB normalmente usa para identificar um serviço; isto é, o identificador de serviço, o identificador de rede original, e o identificador de fluxo de transporte ou os valores utilizados numa tabela de ATSC similar. Portanto, para esta ilustração, assume-se que a difusora tem definidas suas próprias seções, denominadas seções de correspondência de canal, cujo propósito é o de associar o conceito do espetador de um número de canal com valores para este terceto (ou os valores de ATSC). A difusora ou operador já terá escrito, utilizando sua linguagem identificada, e difundido para IRDs, uma tradução dos termos utilizados pelo escritor de aplicação para definir um conjunto de constantes, neste caso Movie, Actor, e ProductionCompany, e um tipo de objeto, eventlnfo, como mostrado nas Figuras 10a e 10b. A definição de eventlnfo indica que um event_information_section é obtido e campos particulares do objeto solicitado são devolvidos. É incorporado numa das definições de campo uma palavra-chave de computação. Isto é uma indicação de que o tempo final não é obtido diretamente dos campos na tabela obtida do fluxo, mas é calculado com base nos mesmos. As afirmações abaixo da palavra em que define vários métodos que, quando solicitados por uma aplicação neste caso, resulta em estreitamento dos candidatos para os valores a serem devolvidos ao chamador. Como mostrado, nem todos os métodos precisam ser utilizados por uma consulta particular, e um método pode ser utilizado múltiplas vezes, como com o método de instanciação. Uma afirmação de computação, como explicado mais à frente, pode consistir em operandos e os operadores +, -, *, /, div, mod, min, e max. Portanto, os cálculos podem ser realizados utilizando uma estrutura em pilha simples incorporada dentro do mecanismo motor de SI 36.

Uma gramática que define a sintaxe para a linguagem de semântica de SI exemplificativa será descrita. Os tokens são definidos conforme segue: DEFINE= "Define", OBTAIN = "obtain", EQUALS = "=", GT = ">", LT = "<", NOTEQUALS = "I = ",GTEQ = ">=", LTEQ = "<=", SEMICOLON = ", STRINGTYPE = "string", INTTYPE= "int", OBJECT = "Object", LEFTCURLY = "{", RIGHTCURLY = "}", FETCH = "fetch", RETURN = "return", COLON = ASSIGNOP = LSQUARE= "[", RSQUARE = "]", DOT = ".", PLUS = "+", MINUS = TIMES = "*", DIV = "div", MOD = "mod", MIN = "min", MAX = "max", RELOP = "relop", SET = "set", FILTER = "filter", COMPUTE = "compute", LPAREN = "(", COMMA = RPAREN = ")", WHERE = "where", DBLEQUALS = "= =" INTEGER = digit (digit)*, STRING = "'" (any_char_except_') * and VARIABLE = letter (any_letter_or_digit_or_underscore)* .

Na definição acima, o digito significa qualquer um dos caracteres 0..9, any_letter_or_digit_or_underscore significa qualquer caractere que é uma letra na gama a..z ou A..Z ou 0..9. 0 termo any_char_except_' significa qualquer caractere exceto a única citação. 0 simbolo * nas definições acima do tokens significa "qualquer número (mesmo 0) dos itens em parênteses pode ser incluído".

Os não terminais são definidos numa versão de BNF, como ilustrado nas Figuras 11a e 11b. O programa não terminal é o objetivo inicial. Como de costume, □ Drefere-se à cadeia vazia, e o símbolo "|" significa que o não terminal pode ser substituído pela expressão para a esquerda do " | " ou a expressão para a direita.

Um mecanismo motor de inicialização de semântica de SI 64 correspondente será agora descrito. Utilizando a gramática definida nas Figuras 11a e 11b, a difusora ou operador podem descrever novas estruturas de nível superior que incluem campos escolhidos das estruturas de SI originais. O propósito do mecanismo motor de inicialização de semântica de SI 64 é de interpretar um conjunto de descrições das estruturas de nível superior e armazenar uma representação interna das descrições numa estrutura. Esta estrutura de representação interna é utilizada pelo gerador de máscara de SI e filtro genérico 82 (ou possivelmente pela interface de consulta 70, conforme citado acima) para determinar exatamente quais os dados de SI a serem obtidos, baseado na consulta da aplicação. Portanto, tudo o que é necessário é o código que lê os dados na forma da gramática e armazena os mesmos numa forma a partir da qual os mesmos podem ser recuperados mais tarde.

Um exemplo de uma estrutura que poderia ser assim gerada pelo mecanismo motor de inicialização de semântica de SI 64 é mostrado nas Figuras 12a, 12b, e 12c numa anotação similar à C. 0 indicador PtrToDefns é inicializado pelo mecanismo motor de inicialização de semântica de SI 64. Este indicador contém o endereço do primeiro elemento de uma lista de definições. Cada definição aponta para a próxima. Similarmente, cada definição afirma se é uma definição de um número inteiro, uma cadeia, ou um novo objeto. Se a mesma for um número inteiro ou cadeia, então é uma definição constante, portanto a definição armazena o valor real. De outro modo, a mesma armazena a estrutura do novo objeto que está a ser definido. Este novo objeto inclui indicadores para outras estruturas que devem ser adquiridas, indicadores para informações sobre métodos para invocar aqueles outros objetos, indicadores para estruturas que contêm novos nomes para valores que são devolvidos, e uma lista de indicadores para filtros que serão definidos para objetos que serão adquiridos mais tarde. Cada um desses elementos de objeto é complexo o suficiente para reter todas as informações na semântica de descrição de SI que é enviada no fluxo de transmissão. Ao mesmo tempo, os mesmos são simples o suficiente para serem atravessados para determinar objetos de SI que devem ser obtidos e para determinar filtros naqueles objetos de SI que devem ser utilizados a fim de obter os valores reais para os objetos de nível superior que são definidos nesta linguagem.

Como foi citado acima, a linguagem de consulta, que é utilizada por aplicações, é muito simples neste caso. Sua gramática é muito próxima de um subconjunto da linguagem de semântica de SI acima, em que cada invocação do programa de aplicação corresponde a algo similar a uma expressão de obtenção. A linguagem de consulta difere em que acquire ou cache podem ser utilizadas em vez de obtain. A palavra chave acquire pode ser utilizada para indicar que a aplicação deseja que os dados de SI solicitados sejam devolvidos quando encontrados. Por outro lado, cache seria utilizada para indicar que o mecanismo motor de SI 36 deve cache este tipo de dados de SI, caso os recursos permitam, e que a aplicação executaria mais tarde uma afirmação acquire a fim de obter os mesmos. A gramática para a linguagem de consulta correspondente, portanto, pode parecer similar à descrição abaixo.

Query : := Request ObjName OptConstraint Request : := "acquire" | "cache" ObjName : := VARIABLE OptConstraint : := WHERE OptNot OptConstraints OptConstraints : := D| Constraint Connector OptNot OptConstraints Constraint : := MethodName LPAREN ActualParamList RPAREN ActualParamList : := ActualParam OptMoreActualParams OptMoreActualParams ::= □| COMMA ActualParam OptMoreActualParams ActualParam : := VARIABLE | INTEGER | Comparator Comparator : := DBLEQUALS | GT I GTEQ I LTEQ | LT NOTEQUALS Connector : := "and" | "or" OptNot : : = □ φ "not"

Como antes, esta modalidade foi apresentada para o propósito de ilustração, e deve ser reiterado que há um número infinito de possibilidades para tal linguagem. Por exemplo, a linguagem descrita aqui inclui ambos os conectores lógicos AND e OR, assim como a lógica opcional NOT, em que vários subconjuntos destes conectores seriam suficientes (por exemplo, OR pode ser expresso como uma combinação de funções E e NOT, visto que OR é equivalente a AND-NOT com todas as entradas negadas). A interface de consulta de SI correspondente pode ser invocada através de um API que contém uma cadeia formatada de acordo com a linguagem de SI de consulta acima. 0 API pode também permite pedidos síncronos ou assíncronos de um programador de aplicação. Um pedido síncrono pausa o programa de aplicação até o valor de SI ser obtido e devolvido. Um pedido assíncrono permite que o programa continue imediatamente. Em qualquer caso, o programa de aplicação pode usar o API para especificar onde armazenar os dados de SI devolvidos, se houver. Se o programa de aplicação tiver solicitado anteriormente que determinados tipos de dados de SI sejam armazenados em cache, então um pedido tardio para obter dados pode resultar na verificação do local armazenado em cache antes de obter quaisquer novos dados de SI. Em todas estas situações, a interface de consulta de SI interpretaria o pedido. A interface de consulta de SI 70 ou o gerador de máscara de SI e filtro genérico 82 usaria o conhecimento da estrutura descrita acima para localizar a descrição do objeto de alto nível que foi solicitada na consulta. A mesma então usaria esta descrição, que pode indicar que um conjunto de estruturas intermediárias ou múltiplas são obtidas dos dados de SI, a fim de criar a estrutura de nível superior solicitada pela aplicação.

Numa modalidade da invenção, a linguagem de consulta pode ser implementada como uma linguagem de baixo nível. Utilizando uma linguagem de baixo nível de consulta, um programador de aplicação pediria dados de SI específicos utilizando o conhecimento da estrutura da difusão SI. A Figura 13 demonstra como tal linguagem pode ser utilizada para construir uma consulta. 0 espetador de televisão, que pode estar ocupado durante as próximas horas, pode desejar registrar alguns programas de noticias interessantes neste meio tempo. Portanto, o espetador pode querer ver uma lista de tais programas que serão oferecidos no "serviço básico" ao qual o mesmo subscreve, representados por um bouquet particular (grupo de canais) . Este serviço básico pode consistir em alguns canais que são portados através de satélite e outros canais que são portados através de cabo. Portanto, o espetador precisará configurar o IRD para cabo ou satélite, dependendo dos programas que estão a ser oferecidos. Utilizando uma interface de usuário adequada, o espetador pode indicar um interesse em programas de "noticias", o período de interesse (RequestedStartTime e RequestedEndTime), que está interessado apenas em redes que são transmitidas através de cabo (se as mesmas estiverem configuradas para cabo), e que as redes devem ser incluídas no "serviço básico." Estas escolhas podem, por exemplo, ser apresentadas num menu pendente, ou outro formato adequado. As seleções do espetador seriam traduzidas numa consulta que é de algum modo similar a SQL, como mostrado na Figura 13. A consulta ilustrada pede que todos os conteúdos de cada instanciação do primeiro ciclo de um event_information_section ser devolvido para uma aplicação, se as restrições forem atendidas em ambos: (i) alguns campos do event_information_section que estão fora do ciclo; e (ii) alguns campos que estão no interior daquele ciclo. Os campos que são pertinentes fora do ciclo incluem o original_network_id e o transport_stream_id. Estes dois campos servem para identificar exclusivamente qualquer fluxo de transporte de qualquer outro. Ao saber destes valores, é possível usar informações em outras tabelas para determinar, por exemplo, se um fluxo de transporte particular é transportado por cabo ou através de satélite e a quais bouquets aquele fluxo de transporte pertence. As informações no interior do referido ciclo são específicas a um evento particular, permitindo a determinação do tempo inicial e duração do evento, o tipo do evento (por exemplo, se é um drama, um evento desportivo, ou um evento de notícias), o título, produtor, e em alguns casos, atores individuais que aparecem no evento. 0 primeiro segmento que expressa tais restrições garante que apenas eventos que estão na categoria de um programa de notícias são devolvidos. 0 segundo segmento de restrição é mais complexo, como ilustrado pela Figura 14. 0 transporte stream_id e original_network_id encontrados no event_information_section devem ser idênticos ao encontrado numa instanciação do segundo ciclo de um bouquet_association_section. No entanto, não apenas qualquer bouquet_association_section será suficiente. 0 bouquet_association_section em que este transport_stream_id e original_network_id são encontrados deve ser o mesmo bouquet_association_section que contém um transport_stream_id e original_network_id cujos valores são idênticos àqueles encontrados num network_information_section para o atual fluxo de transporte. 0 ciclo em que este segundo par de transport_stream_id e original_network_id são encontrados pode ser o mesmo ciclo em que o primeiro par foi encontrado; isto é, na Figura x = y e v = z. Em vez de gerar esta consulta composta, a aplicação poderia ter primeiro pedido para o original_network_id e transport_stream_id no network_information_section do fluxo de transporte atual. Utilizando estas informações, o mesmo poderia então ter pedido para o bouquet_id correspondente ao fluxo de transporte atual, e para o conjunto de todos os pares de original_network_id e transport_stream_id no bouquet com aquele bouquet_id. A aplicação poderia ter restrito o conjunto destes para aqueles portados a cabo (como será discutida abaixo), e, finalmente, poderia restringir os eventos de acordo com categoria e tempo. A terceira restrição define a exigência de que o fluxo de transporte deve ser acessível através de cabo. Ou seja, o transport_stream_id e original_network_id do fluxo no qual o evento é portado devem também ser listados num network_information_section que contém um cable_delivery_system_descriptor. Note que isso pode ser o mesmo network_information_section, como referido na descrição da segunda restrição. 0 mesmo pode também ser diferente, visto que a mesma estação (isto é, transport_stream_id e original_network_id) pode ser redifundida através de múltiplos média. A quarto e última restrição no exemplo da Figura 13 é mostrada na Figura 15, que expande a restrição "// DVB_time_Between". Como pode ser visto a título de referência à Figura, estas restrições de tempo traduzem em restrições nos campos section_number do event_information_sections, assim como nos campos de start_time e duração. Os eventos adequados, que se encontram dentro das dimensões de tempo adequadas, poderiam ser localizados e devolvidos à aplicação sem especificar as restrições no campo de section_number. No entanto, não conseguir especificar as restrições no campo de section_number exigiria um IRD típico para realizar substancialmente mais filtragem (removendo pacotes em que a aplicação não está interessada) em software do que hardware (visto que os filtros são normalmente implementados em hardware), talvez fazendo com que o mesmo perca (devido a extravasamento de armazenamento temporário) , ou pelo menos atrase, pacotes que a aplicação definitivamente precisa.

Um versado na técnica reconhecerá da revelação supracitada que a linguagem em que consultas são expressas para este tipo de SI particular deve incluir a capacidade para especificar o seguinte: — a partir de quais estruturas as informações devem ser extraídas; - operações aritméticas de número inteiro arbitrariamente complexas utilizando operandos vulgarmente encontrados na maioria das linguagens de programação; — atribuições; — comparações arbitrariamente complexas feitas a partir dos típicos operadores de comparação: <,>, @ igual a), h, e d; - restrições lógicas arbitrariamente complexas feitas a partir dos típicos operadores lógicos: e, ou, e não. A linguagem de semântica de SI revelada acima tem todas estas propriedades.

Numa modalidade da invenção, não é necessário criar uma nova linguagem ou conjunto de linguagens para ser utilizada para especificar a semântica de SI e as consultas. Por exemplo, Prolog pode ser utilizado. Deve ser compreendido que, se Prolog, ou outra linguagem de computação de propósito geral lógica ou interpretada for utilizada, as informações complementares no tempo de execução podem ser significativas, para ambos o mecanismo motor de inicialização de semântica de SI 64 e, se também utilizou como uma forma de representação interna, o filtro generalizado e gerador de máscara de SI 82. 0 IRD deve ter potência de processamento suficiente para lidar com as informações complementares exigidas.

Um exemplo do uso de Prolog para expressar a semântica de uma porção de uma definição de SI é ilustrado na Figura 16. A primeira regra afirma que X é o transport_stream_id atual se A for um program_association_table e A tiver um campo denominado transport_stream_id cujo valor é X. A segunda regra define quando C é um membro do bouquet B. C é um membro do bouquet B se L for um bouquet_association_section cujo campo denominado bouquet_id tiver o valor B e cujo campo denominado transport_stream_id tiver o valor C. As duas últimas regras identificam os dois casos em que pode ser determinado que o fluxo cujo transport_stream_id é X está a ser enviado numa média particular (isto é, cabo, satélite ou terrestre). A primeira das duas últimas regras indica que X está a ser transmitido através da média especificada se X for o transport_stream_id atual (que faz uso da primeira regra) e o network_information_section correspondente ao fluxo de transporte atual (significado por um table_id de 32) tem um descritor em seu primeiro ciclo que é de tipo frequency_list_descriptor cujo campo coding_type tem o valor média.

As Figuras 17a a 17f ilustram um exemplo ligeiramente mais complexo. A Figura 17a mostra uma regra que pode ser utilizada para determinar uma lista de eventos que podem começar tão cedo quanto o tempo inicial solicitado e que termina antes do tempo final solicitado (inclusive). Para obter uma lista não vazia de tais eventos, pelo menos um serviço no fluxo de transporte solicitado deve difundir uma programação. Se pelo menos tal programação for difundida, uma gama de números de segmento deve ser obtida devido ao modo que SI de DVB especifica que tabelas de informações de evento são divididas, até 8 valores de número de segmento para cada intervalo de 3 horas no dia. Após todos os eventos descritos em tabelas de informações de evento com os números de segmento adequados terem sido obtidos, deve ser verificado que os eventos reais estão entre os horários solicitados. Isto é feito pela última regra mostrada na Figura 17a. A Figura 17b mostra uma regra para determinar se quaisquer programações são difundidas para serviços num dado fluxo de transporte. A Figura 17c mostra regras que podem ser utilizadas para obter informações de evento correspondentes a uma gama de números de segmento. Visto que este exemplo é baseado em DVB, e devido ao modo que DVB estipula que números de segmento sejam alocados em números, há duas regras diferentes. A primeira é para encontrar informações no primeiro segmento correspondente a um bloco de três horas, e a segunda é para encontrar o restante das informações para aquele bloco de três horas. Duas regras diferentes são utilizadas porque alguns números de segmento podem ser não usados, e seria ineficaz ter um filtro ou conjunto de filtros dedicado a localizar informações que não vão aparecer no fluxo de transporte. A Figura 17d ilustra um número de regras que são necessárias para determinar a diferença entre os valores de tempo local atual dados na gama solicitada e meia-noite da data atual no UTC (Código de Hora Universal)-0 fuso horário. A Figura 17e apresenta as regras necessárias para determinar os números de segmento que correspondem a horários particulares. Finalmente, a Figura 17f mostra como os eventos são verificados para determinar se os mesmos de facto se encaixam no período especificado.

Um mecanismo motor de inicialização de semântica de SI configurado para ser utilizado com as definições acima seria um que simplesmente armazena em cache regras similares àquelas mostradas nas Figuras 16 e 17a a 17f. Para a linguagem de SI de consulta, se Prolog ou linguagem similar for utilizada para expressar a semântica de SI, a mesma linguagem pode ser utilizada para expressar as consultas. Numa modalidade, a Figura 18 mostra uma consulta que pede os titulos de todos os eventos de noticias que serão mostrados num canal a cabo, que é associado ao mesmo bouquet que o programa que o usuário está atualmente a assistir entre 13 de junho de 2000 às 9:30 da manhã e 13 de junho de 2000 às 13:00, inclusive.

As representações de sintaxe e semântica de SI internas podem ser utilizadas pela interface de consulta de SI 64 numa modalidade da invenção. O gerador de máscara de SI e filtro genérico 82 pode também usar as representações internas de sintaxe e semântica de SI. As linguagens e estruturas discutidas no presente documento podem ser utilizadas para especificar a estrutura de dados de SI e para armazenar aquela especificação de estrutura de SI, embora tenha-se muitas maneiras diferentes de especificar uma estrutura de SI e de armazenar a especificação. Não importa quais estruturas são utilizadas para armazenar a especificação de SI, nesta aplicação a versão armazenada da especificação foi referida como uma representação interna de especificação de sintaxe de SI.

Os métodos da presente invenção podem ser resumidos como mostrado na Figura 19. Na etapa 190, a descrição de formato é transmitida, incluindo a sintaxe e semântica do formato. A descrição de formato é recebida, na etapa 192. Uma representação ou representações internas (tal como se diferentes linguagens fossem utilizadas para ambos) da sintaxe e semântica será criada, etapa 194. Uma consulta de aplicação é recebida na etapa 196, e então, utilizando a consulta, representação(ões) interna (s), e informações de filtro (que podem ser armazenadas num objeto com caracteristicas de filtro), uma máscara ou conjunto de máscaras será criado, etapa 198. As máscaras são aplicadas em filtros selecionados na etapa 200, e os metadados são filtrados utilizando as máscaras na etapa 202. Várias etapas são possíveis após as informações terem sido colhidas. As informações podem ser utilizadas para definir ou modificar máscaras, ou máscaras podem ser definidas ou modificadas independentes dos metadados filtrados, como mostrado na etapa 204. As informações devolvidas podem ser passadas de volta a uma aplicação que faz a consulta, seja por si mesma ou em combinação com informações anteriormente devolvidas (e armazenadas/armazenadas em cache), etapa 206. Parte de ou todas as informações devolvidas podem ser armazenadas, na etapa 208. As máscaras também podem ser canceladas, etapa 210 .

Um mecanismo motor reconfigurável para processar metadados formatados foi revelado. O mecanismo motor pode ser implementado em software, hardware ou uma combinação dos mesmos. Se qualquer parte da invenção for implementada em software, aquele software pode ser armazenado em alguma forma de meio legível por computador, tal como memória ou CDROM, ou transmitido por uma rede, e executado por um processador. Adicionalmente, onde métodos foram revelados, várias sequências de etapas podem ser possíveis, e pode ser possível realizar tais etapas simultaneamente, sem divergir do escopo da invenção.

Embora a presente invenção tenha sido descrita em concordância com as modalidades mostradas, uma pessoa de habilidade comum na técnica irá imediatamente reconhecer que pode haver variações feitas às modalidades sem divergir do escopo da presente invenção. Por exemplo, o mecanismo motor reconfigurável pode ser utilizado para processar quaisquer dados rigidamente formatados, e não é limitado a SI ou metadados relacionados com televisão. Consequentemente, é intencionado que toda a matéria contida na descrição acima e mostrada nos desenhos anexos seja interpretada como ilustrativa e não num sentido limitante.

Lisboa,

Claims (62)

1. REIVINDICAÇÕES 1. Recetor para processar dados em que o dito recetor é caracterizado por compreender um mecanismo motor de processamento de dados genéricos (36) configurado para: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; configurar o dito mecanismo motor (36) para processar dados que são formatados de acordo com a definição de formato, responsiva a receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar os dados recebidos adicionalmente em concordância com a definição de formato.
2. 2. Recetor, conforme definido na reivindicação 1, caracterizado por ser ainda configurado para receber uma difusão que inclui os dados.
3. 3. Recetor, conforme definido na reivindicação 2, caracterizado por o mecanismo motor (36) ser ainda configurado para receber a definição de formato da difusão.
4. 4. Recetor, conforme definido na reivindicação 1, caracterizado por ser ainda configurado para receber uma difusão que inclui a definição de formato.
5. 5. Recetor, conforme definido na reivindicação 1, caracterizado por ser ainda configurado para receber uma multidifusão que inclui os dados.
6. 6. Recetor, conforme definido na reivindicação 5, caracterizado por o mecanismo motor (36) ser ainda configurado para receber a definição de formato da multidifusão.
7. 7. Recetor, conforme definido na reivindicação 1, caracterizado por a definição incluir uma descrição de uma sintaxe do formato.
8. 8. Recetor, conforme definido na reivindicação 7, caracterizado por a definição incluir uma descrição de semântica do formato.
9. 9. Recetor, conforme definido na reivindicação 8, caracterizado por a descrição semântica associar pelo menos um identificador com os dados.
10. 10. Recetor, conforme definido na reivindicação 8, caracterizado por a sintaxe e a semântica serem descritas numa primeira linguagem.
11. 11. Recetor, conforme definido na reivindicação 10, caracterizado por o mecanismo motor (36) ser ainda configurado para produzir uma representação interna da sintaxe e semântica.
12. 12. Recetor, conforme definido na reivindicação 11, caracterizado por o mecanismo motor (36) ser ainda configurado para receber uma consulta e usar a representação interna para criar pelo menos uma máscara que defina um padrão de dados particular.
13. 13. Recetor, conforme definido na reivindicação 12, caracterizado por a descrição semântica associar pelo menos um identificador com os dados, e a consulta usar o pelo menos um identificador.
14. 14. Recetor, conforme definido na reivindicação 12, caracterizado por o mecanismo motor (36) compreender ainda pelo menos um filtro (82) operável para aplicar a pelo menos uma máscara a fim de filtrar os dados.
15. 15. Recetor, conforme definido na reivindicação 14, caracterizado por o mecanismo motor (36) compreender ainda um objeto com caracteristicas de filtro que inclui informações sobre o pelo menos um filtro (82), e em que o mecanismo motor (36) é ainda configurado para usar a informações de filtro para selecionar pelo menos um filtro (82) para aplicar a pelo menos uma máscara.
16. 16. Recetor, conforme definido na reivindicação 14, caracterizado por o mecanismo motor (36) ser ainda configurado para remeter pelo menos uma porção dos dados filtrados para uma aplicação.
17. 17. Recetor, conforme definido na reivindicação 14, caracterizado por o mecanismo motor (36) ser ainda configurado para produzir uma máscara adicional, baseada nos dados filtrados.
18. 18. Recetor, conforme definido na reivindicação 14, caracterizado por o mecanismo motor (36) ser ainda configurado para modificar a pelo menos uma máscara, baseada nos dados filtrados.
19. 19. Recetor, conforme definido na reivindicação 12, caracterizado por o mecanismo motor (36) ser ainda configurado para receber uma segunda consulta.
20. 20. Recetor, conforme definido na reivindicação 19, caracterizado por o mecanismo motor (36) ser ainda configurado para criar pelo menos uma máscara adicional, baseada na segunda consulta.
21. 21. Recetor, conforme definido na reivindicação 12, caracterizado por a consulta ser formulada utilizando a primeira linguagem.
22. 22. Recetor, conforme definido na reivindicação 12, caracterizado por a consulta ser formulada utilizando uma segunda linguagem.
23. 23. Recetor, conforme definido na reivindicação 12, caracterizado por compreender ainda um mecanismo operável para executar uma aplicação que formula a consulta.
24. 24. Recetor, conforme definido na reivindicação 23, caracterizado por a consulta ser distinta.
25. 25. Recetor, conforme definido na reivindicação 23, caracterizado por a consulta ser continua.
26. 26. Recetor, conforme definido na reivindicação 8, caracterizado por a sintaxe ser descrita numa primeira linguagem e a semântica ser descrita numa segunda linguagem.
27. 27. Recetor, conforme definido na reivindicação 26, caracterizado por o mecanismo motor (36) ser ainda configurado para produzir uma representação interna da sintaxe e uma representação interna da semântica.
28. 28. Recetor, conforme definido na reivindicação 27, caracterizado por o mecanismo motor (36) ser ainda configurado para receber uma consulta e usar as representações internas para criar pelo menos uma máscara que defina um padrão de dados particular.
29. 29. Recetor, conforme definido na reivindicação 28, caracterizado por a descrição semântica associar pelo menos um identificador com os dados, e a consulta usar o pelo menos um identificador.
30. 30. Recetor, conforme definido na reivindicação 28, caracterizado por o mecanismo motor (36) compreender ainda pelo menos um filtro (82) operável para aplicar a pelo menos uma máscara a fim de filtrar os dados.
31. 31. Recetor, conforme definido na reivindicação 30, caracterizado por o mecanismo motor (36) compreender ainda um objeto com caracteristicas de filtro que inclui informações sobre o pelo menos um filtro (82), e em que o mecanismo motor (36) é ainda configurado para usar a informações de filtro para selecionar pelo menos um filtro (82) para aplicar a pelo menos uma máscara.
32. 32. Recetor, conforme definido na reivindicação 30, caracterizado por o mecanismo motor (36) ser ainda configurado para remeter pelo menos uma porção dos dados filtrados para uma aplicação.
33. 33. Recetor, conforme definido na reivindicação 30, caracterizado por o mecanismo motor (36) ser ainda configurado para produzir uma máscara adicional, baseada nos dados filtrados.
34. 34. Recetor, conforme definido na reivindicação 30, caracterizado por o mecanismo motor (36) ser ainda configurado para modificar a pelo menos uma máscara, baseada nos dados filtrados.
35. 35. Recetor, conforme definido na reivindicação 28, caracterizado por o mecanismo motor (36) ser ainda configurado para receber uma segunda consulta.
36. 36. Recetor, conforme definido na reivindicação 35, caracterizado por o mecanismo motor (36) ser ainda configurado para criar pelo menos uma máscara adicional, baseada na segunda consulta.
37. 37. Recetor, conforme definido na reivindicação 28, caracterizado por a consulta ser formulada utilizando pelo menos uma da primeira linguagem e da segunda linguagem.
38. 38. Recetor, conforme definido na reivindicação 28, caracterizado por a consulta ser formulada utilizando uma terceira linguagem.
39. 39. Recetor, conforme definido na reivindicação 28, caracterizado por compreender ainda um mecanismo operável para executar uma aplicação que formula a consulta.
40. 40. Recetor, conforme definido na reivindicação 39, caracterizado por a consulta ser distinta.
41. 41. Recetor, conforme definido na reivindicação 39, caracterizado por a consulta ser continua.
42. 42. Recetor, conforme definido na reivindicação 1, caracterizado por os dados compreenderem informações relacionada com televisão.
43. 43. Recetor, conforme definido na reivindicação 42, caracterizado por os dados compreenderem informações de serviço.
44. 44. Sistema para processar dados formatados, caracterizado por compreender: um transmissor configurado para transmitir uma definição de formato associada aos dados, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; e o recetor da reivindicação 1.
45. 45. Sistema, conforme definido na reivindicação 44, caracterizado por os dados compreenderem informações relacionada com televisão.
46. 46. Sistema, conforme definido na reivindicação 44, caracterizado por os dados incluírem informações de formatação.
47. 47. Sistema, conforme definido na reivindicação 44, caracterizado por os dados excluírem informações de formatação.
48. 48. Método para atualizar um mecanismo motor de processamento de dados genéricos operável para processar dados independentes das informações de formatação, caracterizado por compreender: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; Configurar o dito mecanismo motor para processar dados que são formatados de acordo com a definição de formato, responsiva para receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar os dados adicionalmente recebidos em concordância com a definição de formato.
49. 49. Método, conforme definido na reivindicação 48, caracterizado por os dados compreenderem informações relacionada com televisão.
50. 50. Método, conforme definido na reivindicação 48, caracterizado por a definição de sintaxe e definição de semântica serem transmitidas separadamente.
51. 51. Método, conforme definido na reivindicação 48, caracterizado por transmitir a definição de sintaxe incluir a difusão da definição de sintaxe.
52. 52. Método, conforme definido na reivindicação 48, caracterizado por transmitir a definição de sintaxe incluir multidifusão da definição de sintaxe.
53. 53. Produto programa de computador para processar dados formatados, caracterizado por compreender um meio utilizável de computador tendo código legível por máquina incorporado em si para: receber uma definição de formato, em que a dita definição de formato compreende uma descrição de uma gramática que define uma sintaxe de uma linguagem alvo; configurar um mecanismo motor de processamento de dados (36) responsivo para receber a definição de formato; receber dados adicionais que se conformem à linguagem alvo; e processar os dados adicionalmente recebidos em concordância com a definição de formato.
54. 54. Produto programa de computador, conforme definido na reivindicação 53, caracterizado por a definição incluir uma definição de sintaxe do formato.
55. 55. Produto programa de computador, conforme definido na reivindicação 54, caracterizado por a definição incluir uma definição de semântica do formato.
56. 56. Produto programa de computador, conforme definido na reivindicação 55, caracterizado por o código ser ainda configurado para produzir uma representação interna da sintaxe e semântica.
57. 57. Produto programa de computador, conforme definido na reivindicação 56, caracterizado por o código ser ainda configurado para receber uma consulta e usar a representação interna para criar pelo menos uma máscara que define um padrão de dados particular para filtrar os dados.
58. 58. Produto programa de computador, conforme definido na reivindicação 57, caracterizado por o código ser ainda configurado para fornecer a pelo menos uma máscara ao pelo menos um filtro (82).
59. 59. Produto programa de computador, conforme definido na reivindicação 57, caracterizado por o código ser ainda configurado para armazenar dados filtrados devolvidos por o pelo menos um filtro (82).
60. 60. Produto programa de computador, conforme definido na reivindicação 58, caracterizado por o código ser ainda configurado para definir uma máscara de acordo com pelo menos uma porção de dados filtrados devolvidos por o pelo menos um filtro (82).
61. 61. Produto programa de computador, conforme definido na reivindicação 58, caracterizado por o código ser ainda configurado para modificar pelo menos uma máscara de acordo com pelo menos uma porção de dados filtrados devolvidos por o pelo menos um filtro (82).
62. 62. Produto programa de computador, conforme definido na reivindicação 53, caracterizado por os dados incluírem informação relacionada com televisão. Lisboa,