BRPI0712750A2 - métodos em uma rede de comunicação, para distribuição de arquivos para uma pluralidade de receptores e para receber, seletivamente, o conteúdo de arquivo em um receptor, receptor, e, controlador de multidifusão - Google Patents

Abstract

MéTODOS EM UMA REDE DE COMUNICAçãO, PARA DISTRIBUIçãO DE ARQUIVOS PARA UMA PLURALIDADE DE RECEPTORES E PARA RECEBER, SELETIVAMENTE, O CONTEUDO DE ARQUIVO EM UM RECEPTOR, RECEPTOR, E, CONTROLADOR DE MULTIDIFUSãO. Método e nós em uma rede de comunicação (305) para controlar a distribuição de multidifusão de arquivos, em que a distribuição de multidifusão é adaptada para reduzir a quantidade de distribuições de arquivos de unidifusão na rede de comunicação. Um navegador de uma Função de Término de IPTV (ITF; 310 a, b, c), requerendo que um arquivo interrogue uma cache (316) da IFT para o conteúdo de arquivo, antes que uma solicitação de unidifusão para distribuição de arquivos seja enviada para uma Plataforma de Serviço de Aplicativo (ASP; 300). Os arquivos armazenados na cache foram previamente distribuídos para a IFT via o mecanismo de multidifusão proposto. Se o conteúdo de arquivo não está armazenado na cache, uma solicitação de unidifusão é enviada para a ASP. Cada solicitação de unidifusão também é avançada para um Controlador de Multidifusão (MCC; 320), que determina se o arquivo solicitado será enviado também para uma pluralidade de IFTs adicionais em um canal de multidifusão. Em cada IFT, que escuta o canal de multidifusão, o conteúdo recebido pode ser manipulado seletivamente de acordo com um mecanismo de filtragem e um arquivo recebido pode, por exemplo, ser armazenado na cache para recuperação posterior.

Description

"MÉTODOS EM UMA REDE DE COMUNICAÇÃO, PARA DISTRIBUIÇÃO DE ARQUIVOS PARA UMA PLURALIDADE DE RECEPTORES E PARA RECEBER, SELETIVAMENTE, O CONTEÚDO DE ARQUIVO EM UM RECEPTOR, RECEPTOR, E, CONTROLADOR DE MULTIDIFUSÃO"

O presente pedido reivindica prioridade do Pedido Provisório dos Estados Unidos US60/803729, depositado em 2 de junho de 2006, cujos ensinamentos totais são aqui incorporados através de referência.

CAMPO TÉCNICO

A presente invenção se refere, de um modo geral, a um método e a uma disposição para fornecimento de um mecanismo de distribuição eficiente para distribuição do conteúdo de arquivo através de um canal de multidifusão e para fornecimento de recepção flexível e manipulação do conteúdo nas extremidades de recebimento.

FUNDAMENTOS

IPTV é uma técnica emergente para distribuição de serviços de TV radiodifundidos, através de uma rede de IPs. O serviço de IPTV predominante é TV de radiodifusão, em que os canais normais não IPTV, bem como canais adicionais com baixa penetração, são transmitidos através de uma rede de bandas largas de uma super cabeça de rede para uma pluralidade de usuários finais, tipicamente, tendo um set-top-box (STB).

Em sistema de TV de radiodifusão tradicionais, tais como, por exemplo, Digital Video Broadcasting-Terrestrial (DVB-T) (Radiodifusão de Vídeo Digital-Terrestre) e Digital Video Broadcasting-Satellite (Radiodifusão de Vídeo Digital-Satélite) (DVB-S'), um canal de radiodifusão é dedicado a transmitir/receber informação de camada de aplicativo. A informação de camada de aplicativo pode compreender, por exemplo, um Electronic Program Guide (EPG) (Guia de Programa Eletrônico), que é uma guia na tela para programas de televisão de radiodifusão programada, permitindo a um espectador navegar, selecionar e descobrir conteúdo por tempo, título, canal, gênero, etc., pelo uso, por exemplo, de um controle remoto, um teclado ou um teclado telefônico. A informação de EPG é, tipicamente, uma linguagem para análise formal de documentos, tal como, por exemplo, XML. Um aplicativo executando na STB pode processar essa informação e traduzi-la em uma tela de TV conectada à STB.

Em geral, há quatro meios de comunicação adequados para a comunicação entre um receptor para IPTV, que, de agora em diante, será referido como uma função de terminação de IPTV (ITF), tal como, por exemplo, uma STB/TV e uma rede. As figuras Ia - d ilustram, esquematicamente, essas quatro maneiras diferentes de conteúdo de transmissão.

A figura Ia ilustra transmissão via transferência contínua específica do cliente. Transferência contínua específica de cliente é um meio de comunicação que é adequado para distribuição de áudio e/ ou vídeo para um usuário final especificado em tempo real. A transferência contínua específica de cliente pode ser proporcionada com base no Protocole de Real Time streaming Protocol (RSTP) (Protocolo de transferência contínua em Tempo Real do Protocolo de controle) e o Real-time Transport Protocol (RTP) (Protocolo de Transporte em Tempo Real) e é usado, tipicamente, a pedido. Na figura la, três Funções de Terminação de IPTV (ITFs) 101 - 103 são conectadas a uma Plataforma de Servidor de Aplicativo (Application Server Platform (ASP)) 100, proporcionando serviços de IPTV para as ITFs. Cada ITF pode solicitar distribuição de conteúdo diferente transferido continuamente da ASP comum 100 a pedido. A ITF 1 101 recebe conteúdo transferido continuamente requerido 104 da ASP 100 via Transferência contínua específica de cliente, enquanto ITF 2 102 recebe conteúdo transferido continuamente 105 e ITF 3 103 recebe um terceiro transferência contínua de conteúdo de dados 106. Cada transferência contínua ilustrada na figura Ia é distribuído via sessões de transferência contínua independentes, separadas.

Pull específico de cliente é outro meio de comunicação baseado em uma funcionalidade que permite a um cliente solicitar, automaticamente, dados sem ter que contar com qualquer intervenção de usuário, isto é, dados são distribuídos de acordo com uma especificação predeterminada. Esse meio de comunicação, que é apresentado na figura lb, permite a uma ITF solicitar, automaticamente, conteúdo sem ter que contar com qualquer intervenção do usuário, isto é, conteúdo é distribuído de acordo com uma especificação predeterminada, que pode ser única para cada ITF. Na figura ITF 1 101, ITF 2 102 e ITF 3 103, recebem o respectivo conteúdo 104, 105 e 106, independente uma da outra.

Push específico de cliente ainda é outra comunicação alternativa apresentada na figura 3c. O push específico de cliente permite que dados solicitados sejam recebidos automaticamente de um servidor de acordo com regras ou preferências predeterminadas armazenadas nos servidores. Essa alternativa de comunicação, porém, conta com um servidor da ASP, que, independentemente, pode avançar conteúdo de dados para as diferentes ITFs, em relação a que conteúdo distribuir e quando distribuir o respectivo conteúdo depende de especificações feitas previamente para a respectiva ITF.

Em qualquer sistema de banda larga há, freqüentemente, uma necessidade de enviar a mesma informação para um grande número de ITFs. O envio dessa informação para cada ITF individualmente é possível, mas não desejável devido a um número de razões. Inicialmente, a informação a ser transmitida pode ser bastante grande em tamanho e pode requerer recursos consideráveis de largura de banda da rede de acesso usada. Em segundo lugar, a informação pode interferir com outro tráfego em tempo real, na ausência de priorização no ambiente da rede doméstica. Finalmente, o tráfego de controle agregado destinado a todas as ITFs pode causar congestão potencial na rede de núcleos, impactando o tráfego de geração de rendimento.

Todos os três meios de comunicação mencionados acima sofrem das desvantagens já mencionadas. Portanto, outro meio de comunicação será requerido.

Push específico geral é um meio de comunicação para distribuição do mesmo conteúdo de dados para uma pluralidade de ITFs 101 — 103. Na figura ld, a arquitetura apresentada acima é usada para ilustrar uma distribuição de dados de push específico geral exemplificado. O push geral, que é um mecanismo essencial para a redução de tempo de resposta e carga de rede, conta com um Canal de Dados de Multidifusão (Multi-cast Data Channel) (MDC) para a distribuição de conteúdo de dados entre uma ASP 100 e as ITFs conectadas 101 - 103. O MDC é adequado para diferentes tipos de transferência de informação, como, por exemplo, distribuição de páginas da web de EPG, arquivos de metadados, arquivos de disparo de interatividade, atualizações de firmware e mensagens de alerta.

Na figura ld, todas as três ITFs recebem o mesmo conteúdo de dados 104 simultaneamente através do MDC.

Do ponto de vista dos operadores, porém, o EPG de IPTV tradicional descrito acima tem algumas desvantagens importantes, também quando usado com push geral, pelo fato de que diferentes fabricantes de STB proporcionam diferentes interfaces de usuário. Isso torna mais difícil para os operadores marcar seu servido de IPTV para os usuários finais. Também torna mais difícil introduzir novas interfaces de usuário e serviços. Além disso, as possibilidades de personalização de novos aplicativos são muito limitados.

Por causa das desvantagens mencionadas acima, alguns novos sistemas de IPTV estão considerando um conceito estreito de cliente, em que tecnologias de navegador da web, tais como, por exemplo, HTML, javascript ou Gráficos de Vetor Escalonáveis (Scalable Vector Graphics) (SVG), são usadas a fim de obter uma interface do tipo personalizado, marcada pelo operador. Ainda, uma desvantagem principal com uma interface do tipo navegador é que ela divulga uma desvantagem inerente com tecnologia de servidor de cliente, o que significa que uma porção de usuários navegando no EPG simultaneamente podem introduzir uma carga significativa nos servidores e rede intermediária.

SUMÁRIO

E um objetivo da presente invenção direcionar os problemas esboçados acima. Mais particularmente, é um objetivo da presente invenção encontrar um mecanismo que ofereça transmissão eficiente de conteúdo de IPTV para um grande número de assinantes. Também é desejável obter um mecanismo mais flexível para recepção seletiva e manipulação de conteúdo de arquivo em receptores, tais como, por exemplo, ITFs.

Esses e outros objetivos podem ser alcançados através do fornecimento de um método, um receptor e um controlador de multidifusão de acordo com as reivindicações independentes anexadas abaixo.

De acordo com um aspecto, a presente invenção envolve um método de distribuição de arquivo para uma pluralidade de receptores, ouvindo um canal de multidifusão. O método inclui recebimento e enfileirar solicitações para distribuição de arquivo de uma ou mais Application Server Platforms (ASPs) (Plataformas de Servidores de Aplicativo) em um Multi- Cast Controller (MCC) (Controlador de Multidifusão), em que cada solicitação compreende pelo menos um atributo, especificando uma condição para como manipular a solicitação e conteúdo de arquivo associado. O método ainda inclui a recuperação de conteúdo de arquivo de uma respectiva ASP, por ter determinado que o conteúdo de arquivo deve ser distribuído do MCC para os receptores através de um canal de multidifusão. Cada distribuição de arquivo é, então, programada com base em pelo menos um atributo. A informação de descrição de arquivo é formatada e transmitida em uma ou mais entradas de arquivo, cada uma das quais está associada com o conteúdo de arquivo. A seguir, o conteúdo de arquivo é formatado e distribuído em uma ou mais instância de arquivo.

Antes do recebimento e enfileiramento de uma solicitação, o conteúdo de arquivo solicitado foi distribuído da respectiva ASP para o receptor de solicitação via unidifusão.

De acordo com outro aspecto, a presente invenção também envolve um método em uma rede de comunicação para receber seletivamente conteúdo de arquivo em um receptor, ouvindo um canal de multidifusão. Esse método inclui o recebimento de uma ou mais entradas de arquivos no canal de multidifusão, onde cada entrada de arquivo compreende um ou mais atributos e um identificador, ligando a respectiva entrada de arquivo a uma ou mais instâncias de arquivos, em que cada instância de arquivo compreende conteúdo de arquivo e um identificador idêntico. Instâncias de arquivos de interesse para o receptor são identificadas pela correspondência de um ou mais atributos de cada entrada de arquivo com um ou mais critérios de seleção, especificando exigências de recepção para o receptor. A seguir, conteúdo de arquivo é recebido em uma ou mais instâncias de arquivos, em que instâncias de arquivos de interesse para o receptor são manipuladas de acordo com um ou mais atributos, associados com a instância de arquivo, enquanto as instâncias de arquivos restantes são descartadas.

Os critérios de seleção podem compreender um ou mais de: região, indicando a região geográfica em que o receptor está localizado; marca, indicando o fabricante do receptor; versão, indicando o firmware do receptor; interesse, indicando áreas de interesse do usuário corrente do receptor; classificação, indicando o nível mínimo de classificação do usuário corrente de um receptor; idade, indicando a idade mínima do usuário corrente de um receptor ou canal, indicando o canal de TV que é visto correntemente em um receptor.

O método pode ainda incluir uma interrogação de uma cache para conteúdo de arquivo requerido, em que o conteúdo de arquivo armazenado na cache foi distribuído para o receptor via distribuição de multidifusão e em que o conteúdo de arquivo é recuperado da cache, se o arquivo não for armazenado na cache, o conteúdo de arquivo é recuperado de uma ASP, via distribuição de unidifusão.

Se o conteúdo de arquivo solicitado não for armazenado na cache, a solicitação para distribuição de unidifusão é avançada da ASP para um MCC, em adição à inicialização da distribuição de unidifusão. No MCC é determinado se o conteúdo de arquivo solicitado deve ser distribuído também no canal de multidifusão.

Na etapa de determinação, critérios, tais como, por exemplo, padrões de solicitação de arquivo experimentados e/ ou estatística armazenada de padrões de distribuição de arquivo, podem ser considerados.

Cada entrada de arquivo, tipicamente, compreende um ou mais atributos, recuperados da respectiva solicitação e um identificador único, que está ligando a entrada de arquivo às respectivas uma ou mis instâncias de arquivos, enquanto a uma ou mais instâncias de arquivos associadas compreendem conteúdo de arquivo e um identificador idêntico.

Uma etapa de identificação pode resultar em uma atualização de uma lista de seleção, compreendendo os identificadores de instâncias de arquivos de interesse e os atributos associados e em que a lista de seleção é usada quando da filtragem de instâncias de arquivos e quando manipulando instâncias de arquivos recebidas de interesse.

Um atributo a ser usado de acordo com qualquer um dos aspectos mencionados acima pode ser, por exemplo, um ou mais de: localização de conteúdo, especificação de uma identificação única de URL; tipo de conteúdo, especificando formato de informação usado; uma prioridade, especificando a prioridade entre instâncias de arquivos; critérios, especificando que uma instância de arquivo precisa ser processada; tempo gasto, especificando o tempo antes que uma instância de arquivo deva ser enviada em um MDC; tempo de validade, especificando quando uma instância de arquivo se torna inválida, ou tipo, especificando como uma instância de arquivo será manipulada. O atributo "tipo" pode, por exemplo, ser um ou mais dos seguintes: cache - indicando que uma instância de arquivo deve ser armazenada em uma cache de ITF; tela, indicando que o conteúdo de uma instância de arquivo deve ser visualizado em uma tela de ITF; atualização, indicando que o conteúdo de uma instância de arquivo deve ser usado para atualização de firmware; mensagem de interatividade, indicando que uma instância de arquivo deve ser usada em uma sessão interativa; canal de junção, indicando que um receptor unirá outro canal de MDC, ou canal de separação, indicando que um receptor deixará o presente MDC. Em uma modalidade, o conteúdo de instância de arquivo de interesse pode ser associado com um atributo, indicando que o conteúdo deve ser colocado na cache do receptor. Nessa situação, o conteúdo é armazenado na cache para uma duração especificada em outro atributo associado. O canal de multidifusão mencionado acima pode ser um Multi-cast Data Channel (MDC) (Canal de Dados de Multidifusão) e o receptor pode ser uma função de Término de IPTV (ITF).

Cada receptor, usado de acordo com as modalidades mencionadas acima, também pode compreender uma lista de um ou mais critérios de seleção predeterminados, em que cada critério de seleção está especificando uma regra para recepção de conteúdo de arquivo para o receptor.

De acordo com outro aspecto, a presente invenção envolve um receptor para recepção seletiva de conteúdo de arquivo, distribuído em um canal de multidifusão. O receptor compreende meios para unir o canal de multidifusão e meios para receber pelo menos uma entrada de arquivo no canal de multidifusão, antes de receber conteúdo de arquivo associado em pelo menos uma instância de arquivo. O receptor ainda compreende meios para identificação de instâncias de arquivos que são considerados relevantes para o receptor pela filtragem de entradas de arquivo recebidas.

Os meios para identificação de instâncias de arquivos podem ainda ser adaptados para lidar com cada instância de arquivo, conduzindo conteúdo de arquivo relevante, com base em um ou mais atributos, recuperados da entrada de arquivo associada.

Além disso, o receptor pode compreender meios para interrogação de uma cache para conteúdo de arquivo requerido, em que o conteúdo de arquivo armazenado na cache foi distribuído para o receptor via distribuição de multidifusão. Esses meios também podem ser adaptados para recuperar o conteúdo de arquivo da cache, se ele for armazenado na cache ou recuperar o conteúdo de arquivo de uma ASP, via uma distribuição de unidifusão, no caso de o conteúdo de arquivo não ser armazenado na cache.

Em um aspecto, o meio de identificação pode ser adaptado para identificar um ou mais atributos e o identificador de cada entrada de arquivo e identificar cada uma ou mais instância de arquivo, compreendendo conteúdo de arquivo, que é ligado à entrada de arquivo via um identificador idêntico.

Ainda em outro aspecto, o meio de identificação pode ser adaptado para filtrar entradas de arquivo recebidas por meio da correspondência de um ou mais critérios de seleção, especificando exigências de recepção para o receptor.

Em outro aspecto, o meio para identificação de instâncias de arquivos pode ainda ser adaptado para atualizar uma lista de seleção, compreendendo os identificadores de instâncias de arquivos de interesse e os atributos associados.

Os meios de recebimento podem ser adaptados para usar a lista de seleção a fim de aceitar instâncias de arquivos de interesse e descartar as instâncias de arquivos restantes, enquanto os meios para identificação de instâncias de arquivos podem ser adaptados para lidar com instâncias de arquivos de interesse de acordo com um ou mais atributos associados. Em outro aspecto, o receptor pode compreender meios para inserir conteúdo de arquivo relevante na cache, se isso for indicado com um atributo, ou para substituir conteúdo de arquivo já existente com uma nova versão do conteúdo de arquivo. O receptor, que pode ser um ITF, pode ser qualquer um de um set- top-box/ TV, um telefone móvel ou computador pessoal (PC). De acordo com ainda outro aspecto, a presente invenção

envolve um MCC para gerenciamento de distribuição de multidifusão para uma pluralidade de receptores, ouvindo um canal de multidifusão, que é gerenciado pelo MCC. O MCC compreende meios para recebimento e meios para enfileiramento de solicitações de distribuição de arquivos de pelo menos um SPP, em que cada solicitação compreende um ou mais atributos, cada um especificando uma condição para como manipular a solicitação e o conteúdo de arquivo associado. O MCC também compreende meios para determinar se um conteúdo de arquivo deve ser distribuído do MCC para os receptores através de um canal de multidifusão. O MCC ainda compreende meios para recuperação de um conteúdo de arquivo a ser distribuído através do canal de multidifusão e meios para programação de cada distribuição de arquivos com base em um ou mais atributos da solicitação associada. O MCC também compreende meios para formatação e distribuição de informação de descrição de arquivo em uma ou mais entradas de arquivos, associada com o conteúdo de arquivo, antes da formatação e distribuição do conteúdo de arquivo em uma ou mais instâncias de arquivos.

O meio para formatar e distribuir pode ser adaptado para formatar cada entrada de arquivo para compreender um ou mais atributos e um identificador único, ligando a entrada de arquivo a uma instância de arquivo, conduzindo o conteúdo de arquivo associado e formatar a instância de arquivo para compreender o conteúdo de arquivo associado e um identificador idêntico.

Ainda outro aspecto, o meio de determinação é adaptado para considerar padrões de solicitação de arquivo experimentados e/ ou estatística armazenada de padrões de distribuição de arquivo, quando determinando se um conteúdo de arquivo deve ser distribuído do MCC para os receptores através do canal de multidifusão, que pode ser, por exemplo, um MDC.

Características adicionais da presente invenção e seus benefícios serão explicados na descrição detalhada abaixo.

BREVE DESCRIÇÃO DOS DESENHOS

A presente invenção será agora descrita em mais detalhes com referência ao desenho anexo, em que:

- A figura Ia é uma ilustração esquemática de uma maneira de proporcionar distribuição de arquivos entre de uma rede para receptores de IPTV, com base em Transferência contínua específica de cliente de acordo com a técnica anterior.

- A figura IB é outra ilustração esquemática de uma segunda maneira de fornecimento de distribuição de arquivos de acordo com a técnica anterior, em que pull específico de cliente é usado para a distribuição de arquivos;

- A figura Ic é outra ilustração esquemática ilustrando um terceiro meio de distribuição de arquivos de acordo com a técnica anterior, usando push específico de cliente.

-A figura Id é outra ilustração esquemática, apresentando uma quarta maneira alternativa de distribuição de arquivos de acordo com a técnica anterior, que é baseada em push específico geral.

A figura 2 é uma ilustração de uma FLUTE File Delivery Structure (Estrutura de Distribuição de Arquivo FLUTE) exemplificativa de acordo com a técnica anterior.

A figura 3A é uma tabela, explicando a função de um número de atributos exemplificados e em que nós os atributos estão relacionados quando usados em um método de acordo com uma modalidade.

- A figura 3b é outra tabela, explicando como alguns atributos do tipo exemplificado podem ser definidos quando usados em um método de acordo com uma modalidade.

A figura 4 ilustra a arquitetura de uma rede e uma Função de Término de IPTV (ITF), envolvida em uma distribuição de multidifusão de acordo com a modalidade.

- A figura 5 ilustra a arquitetura de um Controlador de Multidifusão (MCC) em detalhes adicionais, em que o MCC controla a distribuição de canal de multidifusão de acordo com uma modalidade.

- A figura 6 ilustra a arquitetura de uma Multi-cast Data Channel Terminal Function (MDC TF) (Função de Terminal de Canal de Dados de Multidifusão (MDC TF)) de uma ITF em mais detalhes, em que a MDC TF recebe e manipula objetos de arquivo recebidos na ITF de acordo com uma modalidade.

- a figura 7 é uma outra tabela apresentando alguns critérios de seleção exemplificados e como esses podem ser definidos quando usados em um método de acordo com uma modalidade descrita.

A figura 8 é um gráfico de sinalização, ilustrando um procedimento para distribuição de arquivos de multidifusão de acordo com uma modalidade.

DESCRIÇÃO DETALHADA

Resumidamente descrito, a presente invenção proporciona uma solução onde um canal de multidifusão, usado para a distribuição de dados de aplicativo e meios, é combinado com um conceito de navegador de cliente, a fim de obter uma interface de usuário flexível e um mecanismo de distribuição eficiente para serviços de IPTV.

A fim de proporcionar um mecanismo aperfeiçoado para a distribuição de conteúdo de dados, particularmente conteúdo de dados relacionado como IPTV, proporcionando serviços de IPTV para um número de receptores, referidos como funções de Término de IPTV (ITFs), é sugerido que a técnica conhecida com base na transmissão através de um canal de multidifusão, tal como, por exemplo, um MDC, é ainda desenvolvida com o foco no fornecimento de mais flexibilidade à extremidade de transmissão, bem como no fornecimento de um mecanismo de recepção seletivo, a ser implementado nas extremidades de recebimento de uma rede.

Um Multi-Cast File Delivery Protocol (Protocolo de Distribuição de Arquivo de Multidifusão), denotado FLUTE, é um protocolo que é o padrão de fato para distribuição de arquivos através de um canal unidirecional de multidifusão. Ainda que não seja um padrão oficial, ele tem sido adotado em vários contextos, tais como, por exemplo, OMA BCast 3GPP e como o protocolo de escolha para distribuição de multidifusão de arquivos de multimídia. FLUTE é embutido em Asynchronous Layered Coding (ALC) (Codificação Assíncrona de Camadas), versão 1, que é o protocolo base destinado à distribuição de multidifusão de forma maciçamente escalonável. ALC, que define transporte de objetos binários arbitrários, comumente se refere a objetos de dados transferidos como objetos, enquanto FLUTE descreve os objetos de dados como arquivos. Por essa razão, os termos "objeto" e "arquivo" serão usados permutavelmente por todo esse documento. Também deve ser notado que o termo "objeto", quando usado neste contexto, denota um item de dados transferido, em lugar de um objeto, como seria o caso, normalmente, em um contexto orientado em objeto.

Para aplicativos de distribuição de arquivos, o simples transporte de objetos, porém, não é o bastante. Os sistemas de extremidades precisam saber o que os objetos realmente representam. FLUTE especifica um mecanismo para sinalização e mapeamento das propriedades de arquivos para conceitos de ALC de uma maneira que permite aos receptores atribuir aqueles parâmetros para objetos recebidos. Por essa razão, FLUTE define um aplicativo de transporte específica de ALC, construção de Ouma sessão de distribuição de arquivos, incluindo detalhes de transporte e restrições de cronometragem, no topo de ALC. Também proporciona sinalização em banda das propriedades de arquivos distribuídos. Além disso, FLUTE também especifica detalhes associados com a multiplexação de múltiplos arquivos dentro de uma sessão.

FLUTE proporciona a distribuição de informação de descrição de arquivo separada do conteúdo de arquivo real, onde a informação de descrição de arquivo, tipicamente, é distribuída em uma FILE Delivery Table (FDT) (Tabela de Distribuição de Arquivo). Uma FDT, compreendendo informação de descrição de arquivo de um ou mais arquivos , pode ser distribuída como um objeto único (Instância de FDT) ou dispersa através de múltiplas instâncias de FDT e pode, assim, ser transmitida como uma transferência contínua contínuo de instâncias de descritor de arquivos. Um exemplo dessa Estrutura de Distribuição de Arquivos FLUTE da técnica anterior é descrito com referência à figura 2.

A figura 2 ilustra um conteúdo típico de duas instâncias de FDT 200 e 201, cada uma etiquetada com uma identidade de instância de FDT (FDTInstanceID). Uma instância de FDT pode compreender uma ou mais entradas de arquivo, cada uma compreendendo informação a cerca de conteúdo de arquivo associado e um identificador, ligando a entrada de arquivo ao respectivo conteúdo de arquivo. Na figura, a primeira instância de FDT 200, etiquetada com ID de instância de FDT 23, contém três entradas de arquivo 202 - 204, enquanto a segunda instância de FDT subseqüente 201, etiquetada com a identidade de FDT 24, contém apenas uma única entrada de arquivo 205. Cada entrada de arquivo 202 -205 está associada com uma instância de arquivo (objeto de arquivo) 206 - 209, conduzindo o conteúdo de arquivo, isto é, a informação de usuário a ser distribuída para uma pluralidade de ITFs via um canal de multidifusão. Cada entrada de arquivo 202 - 205 compreende um ou mais atributos, associados com e indicando informação específica sobre o conteúdo de arquivo associado. Essa informação pode ser relevante para os mecanismos de recepção de modo que as respectivas instâncias de arquivos possam ser manipuladas, conseqüentemente. Uma lista completa de atributos definidos para FLUTE pode ser encontrada em RFC 3926 "FLUTE -File Delivery over Unidirectional Transport". As entradas de arquivo apresentadas na filtro de IF compreendem os dois atributos "Content_Type" e Content_Location" (Loc). Content_Type é um atributo indicando o tipo MIME (Multipurpose Internet Mail Extensions), definido para o conteúdo de arquivo associado. Conforme ilustrado na figura, o Content_Type pode ser usado para indicar a distribuição de conteúdo de arquivo na forma, por exemplo, de um texto HTML) text/ html), imagem em jpeg (pict/jpeg) ou um aplicativo xml (appl/xml). Content_Location, que é obrigatório para a FDT, é um descritor de URL, que identifica, unicamente, o arquivo e pode conter um endereço de http, tal como, por exemplo, "http: /test . com/file. html". Além disso, cada entrada de arquivo também contém um Target Object Identifier (TOI) (Identificador de Objeto Alvo), que é um identificador único de nível de ALC, indicando uma ligação entre uma entrada de arquivo da FDT e o conteúdo de arquivo real, isto é, FDT 202 com TOI ajustado para 2 é o descritor de arquivo para o conteúdo de arquivo conduzido na instância de arquivo 206, que também é etiquetado com um TOI que é ajustado para 2. A fim de ser capaz de distinguir instâncias de descrição de arquivos de instâncias de arquivos em um receptor, cada instância de descrição de arquivo (instância de FDT) é dotada de um TOI que iguala 0, enquanto entradas de arquivo e instâncias de arquivos ligadas são dotadas de um TOI único, que igual um outro número que não 0. Através da extensão de FDT de FLUTE, descrita acima, e pelo uso dos atributos com um mecanismo de distribuição aperfeiçoado, que pode ser implementado na extremidade de transmissão do canal de multidifusão, um mecanismo mais efetivo para distribuição de multidifusão é requerido.

Em cada ITF que ouve um MDC, um mecanismo de filtragem proposto também proporcionará recepção seletiva e manipulação de conteúdo de arquivo distribuído. Na figura 3a, um número de atributos que podem ser usados na FLUTE/FDT estendida, proposta, são apresentados. A finalidade principal com a lista ampliada de atribuídos é proporcionar parâmetros que permitem que um mecanismo de distribuição aperfeiçoado na entidade de transmissão seja usado para filtragem de conteúdo de arquivo desejado nas ITFs de recebimento. Deve ser compreendido que a lista de atributos apresentada na figura 3a seja apresentada sem quaisquer limitações e que o mecanismo de distribuição proposto e o mecanismo seletivo sejam adaptados para operar também com atributos adicionais, alguns dos quais podem ser específico de operador. O mecanismo de distribuição será gerenciado por uma entidade denotada o Controlador de Multidifusão (MCC), que será descrito em mais detalhes abaixo com referência às figuras 4 e 5, enquanto o mecanismo seletivo será gerenciado por uma Função de Terminal de MDC (MDC TF). O MDC TF será descrito em mais detalhes com referência à figura 6.

Os dois atributos ("Content-Location") "Conteúdo - Localização" e ("Content-Type") "Tipo-conteúdo" representa atributos de FLUTE existentes. ("Priority") "Prioridade" é um atributo que pode ser relevante tanto na fase de transmissão quanto na de recebimento. Esse atributo pode ser usado na programação, quando a priorização entre objetos perto de serem distribuídos através de um MDC, que está congestionado ou perto de se tornar congestionado. Na ITF, esse atributo pode ser usado para priorizar como manipular conteúdo de arquivo, se problemas de congestão estiverem perto de ocorrer na ITF. ("Criteria") "Critério" é um atributo que pode ser de interesse para as ITFs, indicando se um objeto recebido correspondente a um critério específico precisa ser processado ou não.

O atributo ("Stale time") "tempo gasto", que pode ser relevante para a IFT, permite que o MCC retarde a transmissão de um objeto, favorecendo outras distribuições mais críticas em tempo. O tempo gasto, assim, permite que o MCC use o MDC mais eficientemente.

("Validity time") tempo de validade é outro atributo proposto, que pode ser relevante para o MCC e para as ITFs. O tempo de validade indica quanto o conteúdo de um objeto é válido e, assim, quanto o conteúdo do objeto será acessível, uma vez distribuído e armazenado em uma IFT.

O atributo ("Type") "Tipo" indica como uma mensagem deve ser manipulada pela respectiva ITF. Sem qualquer limitação, uma lista de possíveis definições de tipo é apresentada na figura 3b.

Um objeto tendo o tipo "Cache" indica que o objeto deve ser armazenado em uma cache da respectiva ITF. A cache é um meio de armazenamento para armazenar e proporcionar conteúdo solicitado quando navegando na IFT, ou de um aplicativo da IFT. O conteúdo de arquivo que mais provavelmente será solicitado no futuro próximo, por exemplo, por causa de sua popularidade, pode ser distribuído antecipadamente e armazenado na cache para recuperação rápida, quando requerido. Quando navegando pelo conteúdo que já foi armazenado na cache, uma distribuição de unidifusão de um servidor de aplicativo é, assim, evitado. O fato de que esse conteúdo de arquivo é distribuído para uma pluralidade de receptores através de canais de multidifusão e armazenado na cache do respectivo receptor, antes que seja realmente necessário, assim, poupará largura de banda. Outro benefício será que um usuário será capaz de obter acesso mais rápido ao conteúdo de arquivo. A função da cache será ainda descrita abaixo com referência à figura 4. Outro tipo denotado ("Display") "visualizar" pode ser usado para indicar que o respectivo conteúdo de um objeto recebido deve ser visualizado na tela da ITF. O tipo ("upgrade") "atualizar" é outro tipo, que pode ser usado para indicar para uma ITF que o conteúdo de um respectivo objeto deve ser usado para atualização de firmware. ("Interactivity message") "mensagem de interatividade" é outro atributo que pode ser usado para indicar que a mensagem deve ser usada em uma sessão de interatividade, enquanto os dois tipos ("Join channel" e "Leave channel") "unir canal" e "separar canal" indicam para uma ITF que ela se unirá a outro MDC ou que separará do presente MDC, respectivamente.

Uma arquitetura de IPTV esquemática, com base em um conceito de MDC/FLUTE estendido, e um novo mecanismo de critérios de acordo com uma modalidade, serão descritos agora com referência à figura 4. A figura mostra uma rede de comunicação 305, compreendendo três IPTV Application Platforms (Plataformas de Aplicativo de IPTV) (ASPs) 300a-c, cada uma adaptada para proporcionar conteúdo de arquivo, associado com serviços de IPTV, para um ou mais de três ITFs 310 a-c, que pode ser qualquer um de, por exemplo, STB/TV, um PC ou um telefone celular, adaptado para receber serviços de IPTV.

Por razões de clareza, embora as ITFs e ASPs sejam limitadas a três entidades na figura, a arquitetura poderia, facilmente ser estendida com ITSs e ASPs adicionais. A rede de comunicação 305 também compreende um Controlador de Multidifusão (MCC) introduzido 320, adaptado para controlar distribuição de multidifusão de conteúdo de arquivo para as ITFs ouvindo o MDC. Cada ASP 300 a-c pode compreender uma ou mais aplicativos (ASP API, ASP AP2) 301a, 301b, cada uma adaptada para proporcionar serviços específicos de IPTV para inscrever usuários finais, usando qualquer uma das ITFs 310 a-c. Algumas aplicativos (ASP API) 301a podem ser adaptadas para proporcionar serviços em resposta a uma interação de usuário, tal como, por exemplo, navegação ou em resposta a uma solicitação automatizada, iniciada por um aplicativo da ITF. Normalmente, uma solicitação para um arquivo é enviado para a respectiva ASP. De onde o conteúdo de arquivo solicitado é distribuído para a ITF via unidifusão. De acordo com uma modalidade descrita, solicitações para distribuição de arquivos também são enviadas para o MCC da uma ou mais ASPs, em adição ao disparo de uma distribuição de arquivos de unidifusão. No MCC, solicitações recebidas são avaliadas, considerando, por exemplo, padrões de solicitações de arquivos experimentados ou estatística armazenada de padrões de distribuição de arquivos, para determinar se um arquivo também será distribuído para e armazenado nas IFTS, ouvindo um canal de multidifusão. Uma vez distribuído para uma IFT, esse conteúdo de arquivo será recuperável pela IFT imediatamente mediante solicitação, sem ter que sobrecarregar a rede de comunicação 305 com qualquer sinalização.

Outras aplicativos (ASP AP2) 301b podem ser adaptadas para executar uma solicitação para uma distribuição de arquivos de multidifusão direta com base em algum outro disparo, iniciado interna ou externamente. Serviços não requerendo qualquer interação de usuário podem compreender, por exemplo, a distribuição de informação de emergência a ser distribuído para um grupo de ITFs em caso de uma situação de emergência.

Deve ser compreendido que as ITFs apresentadas nesse documento também são supostas serem equipadas com funcionalidade de interação necessária, tal como um visor, necessário para apresentar o conteúdo recuperado para um usuário final e uma interface de usuário, adaptada para inserção de opções específicas de usuário, bem como para executar interação do usuário, associada com serviços interativos de IPTV. Esse tipo de funcionalidade, porém, é conhecido comumente e oferecido em várias alternativas no mercado e, desse modo, fora do escopo deste documento. Da perspectiva da IFTs, o conteúdo de arquivo que é de interesse para um usuário, normalmente, é solicitado de uma respectiva ASP 3 OOa-c por uma interação de usuário, em que uma navegação de usuário final com um navegador 311 da respectiva ITF 310a-c, pode acessar uma ASP e recuperar o arquivo solicitado através de distribuição de unidifusão, via um Proxy de http 312. Alternativamente, um aplicativo (IFT AP2) 313b da ITF pode disparar o proxy de HTTP 312 para solicitar um arquivo requerido automaticamente. De acordo com a modalidade apresentada, porém, um arquivo solicitado é procurado, inicialmente, em uma cache 316 da respectiva ITF. A cache 316 contém, conteúdo de arquivo que foi recuperado do MCC através de um MDC, antes da busca, em que o respectivo conteúdo de arquivo é mantido na cache 36 desde que ele seja estabelecido como sendo válido. A validade de um arquivo pode ser definida por um atributo de validade específico, armazenado em associação com o conteúdo. Se o conteúdo de arquivo solicitado for encontrado na cache 316, ele pode ser recuperado sem qualquer outro retardo e sem ter que iniciar qualquer solicitação para distribuição de arquivos através da rede de comunicação 305. Se, porém, o arquivo não estiver presente na cache, uma solicitação para uma distribuição de arquivos de unidifusão tem que ser iniciada e avançada para a respectiva ASP e aplicativo. Um ou mais atributos, cada definindo uma exigência específica de arquivo, são anexados à solicitação antes que ela seja distribuída para uma das ASPs 300 a-c.

A fim de proporcionar um mecanismo de distribuição de MDC aperfeiçoado, funcionalidade de controle no lado de transmissão de um MDC 312 será requerida. Por essa razão, a função de controle genérica, denotada como o Controlador de Multidifusão (MCC) 320, é introduzida. Conforme mencionado acima, cada solicitação de unidifusão enviada para uma ASP também será enviada para o MCC 320, onde a solicitação é avaliada junto com outras solicitações e, com base em informação disponível, uma determinação é feita quanto a se o conteúdo de arquivo também será distribuído através do MDC 312. Um exemplo desse processo será descrito abaixo com referência À figura 8. O MCC 320 é responsável por uma distribuição de multidifusão de conteúdo de arquivo, proporcionada das ASPS 300 a-c em um MDC 312, para cada ITF 310 a-c que foi unida e está ouvindo o MDC 312. Embora apenas um MDC 312 seja ilustrado na figura, um MCC pode ser capaz de controlar distribuições de arquivos através de uma pluralidade de MDCs. Uma IFT normalmente junta um MDC na inicialização, tipicamente pelo uso do Internet Group Management Protocol (IGMP) (Protocolo de Gerenciamento de Grupos da Internet) e continua ouvindo o MDC até que a IFT seja desligada ou até que ela seja instruída para mudar o MDC. O MCC 320 também pode ser conectado a um ou mais Proxies de MDC (não mostrados), operando como uma unidade intermediária entre uma ITF 3 lOa-c e uma ASP 300a-c.

A função de Inserção de MDC (MDC IF) 321, que será descrita em mais detalhes abaixo com referência à figura 5, é adaptada para controlar a distribuição de arquivos de multidifusão de conteúdo de arquivo, recuperado de uma ASP 300 a, b, c. Por ter chegado à conclusão de que um arquivo deve ser distribuído através do MDC 312, o conteúdo de arquivo real é recuperado da respectiva ASP. Uma distribuição de conteúdo de arquivo é, então, programada e empurrada para a ITFs 310 a-c. Gerenciamento de distribuição eficiente para o respectivo MDC 312 contará com um esquema de programação, que levará em consideração critérios específicos de conteúdo. A FDT estendida proposta, usada com um processo de filtragem, introduzirá uma programação mais flexível, em que o um ou mais atributos recebidos nas solicitações e, opcionalmente, informação adicional, tal como, por exemplo, estatística sobre a popularidade de um programa de TV, armazenada em uma base de dados de MCC (MCC DB) 322, podem ser considerados durante o procedimento de determinação. Tipicamente, a MCC DB 322 também mantém vários carrosséis de instâncias de arquivos a serem repetidas no MDC com intervalos regulares.

Uma vez distribuído para uma ITF 310a via MDC 312, o conteúdo de arquivo será manipulado por uma Função de Terminal de MDC (MDC TF) 314. Um processo de filtragem proposto pode ser controlado por lógica localizada em MDC TF 314 ou por um aplicativo (IFT API) 313a da ITF 310a-c. O processo de filtragem permite a um usuário final distinguir conteúdo de arquivo recebido que é de interesse para o usuário final de conteúdo irrelevante. Após a filtragem, conteúdo de arquivo identificado é manipulado de acordo com um ou mais atributos associados com o conteúdo de arquivo. O conteúdo de arquivo pode, por exemplo, ser recuperado da MDC TF 314 por Cache Insert Function (Cache IF) 315 (Função de Inserção de Cache) e inserido na cache 316, se indicado por um respectivo atributo. O respectivo conteúdo de arquivo normalmente permanece na cache desde que seja válido. Quando o tempo de validade, que pode ser estabelecido por um atributo de validade, expira, o conteúdo de arquivo é descartado da cache 316. Se, porém, um arquivo correspondente já está presente na cache, esse arquivo é descartado e substituído pelo novo, atualizado.

Um MCC 320 exemplificativo, compreendendo a MDC IF 321, para ser usado para avaliação e programação de distribuição de multidifusão de acordo com a modalidade descrita acima será agora apresentado em mais detalhes com referência à figura 5. O MCC 320 compreende uma ou mais Application Programming Interfaces (APIs) 330 (Interface de Programação de Aplicativo), aplicadas aos aplicativos das ASPs 300a-c, permitindo recepção de solicitações, originalmente destinadas a uma ASP 300 a, b, c, bem como permitindo a recepção do próprio conteúdo de arquivo uma vez que uma decisão para distribuição de arquivos de multidifusão do respectivo conteúdo de arquivo tenha sido tomada pelo MCC 320. Uma solicitação para uma distribuição de arquivos recebida pela API 330 é enviada para a MDC Formatting and Scheduling Function (MDC FSF) 331 (Função de Formatação e Programação de MDC), onde a solicitação é colocada em uma fila 333, junto com outras solicitações de enfileiramento. Subseqüente ao enfileiramento, a MDC FSF 331 pode usar estatística armazenada em e recuperada da MCC DB 322, para determinar se o arquivo deve ser distribuído também através do MDC. Se isso for decidido, o conteúdo de arquivo é recuperado da respectiva ASP, tipicamente, por meio da execução de um PULL específico de cliente e a distribuição de arquivos é programada com base em um ou mais atributos recuperados na solicitação.

A programação pode ser baseada em uma ou mais funções de filtragem, para serem ativadas sozinhas ou em uma combinação. Em um primeiro nível, que pode ser ativado quando um MDC alcançou um limite de largura de banda predeterminado, a MDC FSF 331 pode considerar um atributo, tal como, por exemplo, prioridade, a fim de priorizar a ordem em que executar a distribuição de arquivos solicitada. Em um segundo nível, que é considerado quando o risco de congestionamento no MDC é baixo, outros atributos, tais como, por exemplo, tempo gasto e/ ou tempo de validade, podem ser considerados e comparados com atributos correspondentes de outras solicitações.

Além dos atributos, a programação também pode usar informação de uso recuperada da MCC DV 322, tal como, por exemplo, o conteúdo de arquivo mais freqüentemente solicitado é dedicada à prioridade mais alta. Subseqüente à programação, o conteúdo de arquivo e a informação de descrição de arquivo, compreendendo instruções para os receptores das IFTs, são formatados na MDC FSF 321 de acordo com o protocolo de FLUTE.

Conforme descrito acima, com referência à figura 2, uma ou mais instâncias de descrição de arquivo são montadas como instâncias de FDT, cada uma das quais está conduzindo uma ou mais entradas de arquivo. As instâncias de FDT são empurradas para as ITFs 310 a-c em um MDC dedicado, via um Transmissor de MDC 334. Uma vez que as instâncias de FDT tenham sido distribuídas para as IFTs, um ou mais pacotes de ALC, conduzindo o conteúdo de arquivo, são montados juntos, com o identificador relevante (TOI). Também os pacotes de ALC são, então, empurrados para as ITSs 310 a-c via o transmissor de MDC 334.

Em cada IFT de recebimento, o conteúdo de arquivo de interesse pode ser identificado e distinguido de conteúdo irrelevante, usando os atributos associados com o conteúdo de arquivo e um critério de seleção, definindo um perfil específico estabelecido para cada receptor. Uma MDC TF exemplificativa 314 de uma ITF 310, adaptada para controlar essa identificação e filtragem de acordo com a modalidade descrita, será agora apresentada em mais detalhes com referência à figura 6.

As entradas de arquivo que chegam na MDT TF 314, via um MDC, são recebidas por um receptor de MDC 340 e manipuladas por lógica de ITF 341. A lógica de ITF 341 compreende um mecanismo de identificação, que é usado para determinar se o conteúdo de arquivo a ser distribuído subseqüente às entradas de arquivo é de interesse para a ITF. Após ter comparado os atributos das instâncias de arquivos com um critério de seleção pré-estabelecido 343, recuperados da lógica de IFT 341 ou IFT API 313, a lógica de ITF coloca juntos uma relação de seleção 342, indicando o um ou mais identificadores (TOIs) que estão ligando às instâncias de arquivos que foram verificadas serem de interesse para a ITF e os atributos associados. Todas as instâncias de arquivos, compreendendo um identificador que está presente na lista de seleção 342, são consideradas pela lógica de IFT 341 e manipuladas de acordo com os respectivos um ou mais atributos. As instâncias de arquivos tendo um identificador que não está presente na lista de seleção 342, porém, são descartadas pela lógica de IFT 341. Em uma modalidade alternativa, conteúdo de arquivo irrelevante pode ser descartado já no receptor de MDC 340.

A figura 7 apresenta alguns exemplos de critérios de seleção, que podem ser usados para especificar exigências de recepção para uma ITF, isto é, personalizar a recepção.

O critério de seleção "Região" define a região geográfica em que a respectiva IFT está localizada. Quando usando o critério de seleção "Região", uma ITF que está localizada na zona definida, por exemplo, com "se.stockholm.norrmalm.se", aceitará todas as instâncias de arquivos que chegam etiquetadas com a região "se", "se.stockholm" e "se.stockholm. norrmalm".

O critério de seleção "Marca" indica o fabricante da ITF. Esse critério pode indicar que apenas conteúdo destinado para aquela marca específica será aceito.

"Versão" é outro critério de seleção, que pode ser usado para indicar que versão de firmware é usada, permitindo que a ITF filtre qualquer conteúdo que não está adaptado para ser usado com essa versão.

"Interesse" pode proporcionar a um usuário final uma grande variedade de opções alternativas para serem usadas a fim de personalizar uma IFT e, assim, ser capaz de escolher, seletivamente, que categorias de conteúdo receber, via o mecanismo de MDC proposto.

"Classificação" pode ser usado para indicar um nível mínimo de usuários correntes da ITF.

"Idade" pode indicar a idade mínima do usuário corrente da IFT, enquanto "Canal" é um critério de seleção indicando o canal de TV que está sendo visto correntemente na ITF. Deve ser compreendido que essa lista apresentada de critérios de seleção apenas descreve o uso principal por meio de exemplos. A lista da figura 7 poderia, assim, ser estendida com critérios de seleção adicionais adequados para expressar aspectos de interesses e preferências dos usuários finais, bem como de um ponto de vista dos fabricantes e/ ou de provedores de serviços.

A lógica de IFT 341 também é adaptada para lidar com instâncias de arquivos de interesse de acordo com o atributo de tipo. Uma instância de arquivo, sendo marcada com cache, por exemplo, será avançada para a cache 315 e armazenada na mesma, conforme explicado acima. Se, porém, a cache estiver cheia ou tiver alcançado um limite predeterminado, um atributo de prioridade pode ser usado para determinar que instâncias de arquivos priorizar.

A figura 8 é um diagrama de sinalização, ilustrando o mecanismo de distribuição de arquivos de acordo com a modalidade descrita acima. Na figura 8 está ilustrado como uma solicitação para um arquivo distribuído para uma ASP 300 é avançada para um MCC e como uma determinação para enviar o conteúdo de arquivo solicitado também para um grupo de IFTs, via um MDC, é feita no MCC de acordo com uma modalidade descrita acima. Deve ser compreendido que, embora o diagrama de sinalização na figura 8 mostre apenas a chegada de uma solicitação, uma decisão para um distribuição de arquivos de multidifusão será tomada apenas se uma pluralidade de solicitações para o mesmo arquivo indica alguma espécie de padrão para a lógica de decisão do MCC 320.

Em uma primeira etapa 8:1 (ReqNewFilefattributes]) da figura 8, uma de um número de solicitações para distribuição de arquivos, inicialmente, enviada de uma IFT para uma ASP 300, é enviada da ASP 300 para o MCC 320. Na ITF, cada solicitação, inicialmente, é dotada de atributos indicando certas exigências para o respectivo arquivo solicitado. Em uma etapa seguinte 8:2, a solicitação é colocada em uma fila (EnqueueFile), junto com outras solicitações, recebidas da mesma ou outras ASPs. O enfileiramento da solicitação é confirmado para a ASP 300 (ConfirmSendNewFile) em uma etapa subseqüente 8:3. Em outra etapa 8:4, a lógica de decisão determina se o conteúdo de arquivo deve ser distribuído via distribuição de multidifusão pelo MCC 320. Se a distribuição de multidifusão for decidida para um arquivo, aquele conteúdo de arquivo é puxado (HTTPiGetüRL) da ASP 300 em uma etapa 8:5 e uma etapa 8:6 (HTTP:URL). Em seguida, a distribuição de arquivos de multidifusão é programada, pelo que diferentes critérios podem ser usados a fim de, por exemplo, evitar congestão no MDC e/ ou priorizar distribuições de maneira eficiente. A programação, que é ilustrada com uma etapa 8:7, tipicamente, conta com os atributos, distribuídos com as respectivas solicitações, mas também pode contar com estatística adicional relevante para o conteúdo de arquivo a ser distribuído. O conteúdo de arquivo recuperado agora está disponível no MCC 320 para distribuição para todas as ITFs que escutam o MDC. Em uma etapa 8:9, uma ou mais instâncias de FDT, associadas com o conteúdo de arquivo a ser transmitido, são montadas e empurradas (FLUTE:SendFDT [attributes]) para as ITFs que escutam o respectivo canal de multidifusão. Uma vez recebidos em uma ITF 310, o um ou mais atributos das instâncias de FDT são usados para filtragem (ProcessSelectionCriteria) do conteúdo de arquivo que é considerado relevante para a IFT 310 através de correspondência de um ou mais atributos com os critérios de seleção da IFT 310. Isso é feito em outra etapa 8:9. Como um resultado da correspondência, as instâncias de arquivos consideradas como relevantes para a IFT 310 podem ser distinguidas das instâncias de arquivos verificadas serem irrelevantes para o receptor. Em uma etapa seguinte 8:10, as instâncias de arquivos associadas com as instâncias de DFT previamente empurradas são empurradas (FLUTE:SendFile [TOI, file content]) para as ITFs via o MDC dedicado. Dependendo do resultado do procedimento de filtragem, o conteúdo de arquivo relevante pode agora ser manipulado, conseqüentemente. Na figura essa etapa é indicada com uma etapa 8:11 (HandleFile).

Embora a invenção tenha sido descrita com referência à modalidades exemplificativas específicas, a descrição, em geral, é destinada somente a ilustrar o conceito da invenção e não a ser tomada como limitando o escopo da invenção, que é definido pelas reivindicações anexas.

Claims (25)

1. Método em uma rede de comunicação (305) para distribuição de arquivos para uma pluralidade de receptores (310a, b,c), que escutam um canal de multidifusão (312), caracterizado pelo fato de compreender as seguintes etapas: - recebimento (8:1) e enfíleiramento (8:2) de solicitações para distribuição de arquivos de pelo menos uma Plataforma de Servidor de Aplicativo (ASP; 300a,b,c) em um Controlador de Multidifusão (MCC; 320), em que cada solicitação compreende pelo menos um atributo especificando uma condição para como manipular a solicitação e conteúdo de arquivo associado; - recuperação (8:5, 8:6) de conteúdo de arquivo de uma respectiva ASP por ter determinado (8:4) que o conteúdo de arquivo deve ser distribuído do MCC para os receptores através de um canal de multidifusão; - programação (8:7) de cada distribuição de arquivos com base em pelo menos um atributo; e - formatação e distribuição (8:8) de informação de descrição de arquivo em pelo menos uma entrada de arquivo, associada com o conteúdo de arquivo, antes da formatação e da distribuição (8:10) do conteúdo de arquivo em pelo menos uma instância de arquivo, em que a distribuição do conteúdo de arquivo é com base nos padrões de solicitação de arquivo e/ou padrões de distribuição de arquivo.

2. Método de acordo com a reivindicação 1, caracterizado pelo fato de, antes de receber e enfileirar uma solicitação, o conteúdo de arquivo solicitado ser distribuído da respectiva ASP para o receptor solicitante via unidifusão.

3. Método em uma rede de comunicação (305) para receber, seletivamente, o conteúdo de arquivo em um receptor (310 a, b, c) que escuta um canal de multidifusão (312), caracterizado pelo fato de compreender as seguintes etapas: - recebimento (8:8) de pelo menos uma entrada de arquivo, cada uma compreendendo pelo menos um atributo e um identificador ligando a respectiva entrada de arquivo a pelo menos uma instância de arquivo, compreendendo conteúdo de arquivo e um identificador idêntico no canal de multidifusão; - identificação (8:9) de instâncias de arquivos de interesse para o receptor através de correspondência do pelo menos um atributo de cada entrada de arquivo com pelo menos um critério de seleção (343), especificando exigências de recepção para o receptor, a etapa de identificação resultando em uma atualização de uma lista de seleção, dita lista compreendendo os identificadores as instâncias de arquivo de interesse para o receptor e os atributos associados, - recebimento (8:10) de conteúdo de arquivo em pelo menos uma instância de arquivo no canal de multidifusão; - manipulação (8:11) de instâncias de arquivos de interesse para o receptor de acordo com o conteúdo da lista de seleção.

4. Método de acordo com a reivindicação 3, caracterizado pelo fato de os critérios de seleção poderem compreender pelo menos qualquer um dos seguintes critérios: - região, indicando a região geográfica em que o receptor está localizado; - marca, indicando o fabricante do receptor; - versão, indicando o firmware do receptor; - interesse, indicando áreas de interesse do usuário corrente do receptor; - classificação, indicando o nível mínimo de classificação do usuário corrente de um receptor; - idade, indicando a idade mínima do usuário corrente de um receptor; - canal, indicando o canal de TV que é visto correntemente em um receptor.

5. Método de acordo com a reivindicação 3 ou 4, caracterizado pelo fato de ainda compreender as seguintes etapas: - interrogação de uma cache (316) para conteúdo de arquivo requerido, em que o conteúdo de arquivo armazenado na cache foi distribuído para o receptor via distribuição de multidifusão; - recuperação do conteúdo de arquivo da cache, se o conteúdo de arquivo for armazenado na cache; ou - recuperação do conteúdo de arquivo de uma Plataforma de Servidor de Aplicativo (ASP; 300a, b, c) via distribuição de unidifusão, se o conteúdo de arquivo não for armazenado na cache.

6. Método de acordo com a reivindicação 5, caracterizado pelo fato de, se o conteúdo de arquivo solicitado não for armazenado na cache, a solicitação para distribuição de unidifusão ser avançada da ASP para um Controlador de Multidifusão (MCC; 320), em adição à iniciação da distribuição de unidifusão para determinar se o conteúdo de arquivo solicitado deve ser distribuído também no canal de multidifusão.

7. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de cada entrada de arquivo compreender o pelo menos um atributo recuperado da respectiva solicitação e um identificador único, ligando a entrada de arquivo à respectiva pelo menos uma instância de arquivo e pelo fato de a instância de arquivo associada compreender conteúdo de arquivo e um identificador idêntico.

8. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de um atributo poder ser pelo menos qualquer um dos seguintes: -localização-conteúdo, especificando uma identificação de URL única; - tipo-conteúdo, especificando formato de informação usada; - uma prioridade, especificando a prioridade entre instâncias de arquivos; - critérios, especificando o que uma instância de arquivo precisa para ser processada; - tempo gasto, especificando o tempo antes que uma instância de arquivo deva ser enviada em um MDC; - tempo de validade, especificando quando uma instância de arquivo se torna inválida; - tipo, especificando como uma instância de arquivo será manipulada.

9. Método de acordo com a reivindicação 8, caracterizado pelo fato de um atributo de tipo poder ser pelo menos qualquer um dos seguintes: - cache, indicando que uma instância de arquivo deve ser armazenada em uma cache de ITF; - visor, indicando que o conteúdo de uma instância de arquivo deve ser mostrado em uma tela de ITF; - atualização, indicando que o conteúdo de uma ia deve ser usado para atualização de firmware; - mensagem de interatividade, indicando que uma instância de arquivo deve ser usada em uma sessão interativa; - junção de canal, indicando que um receptor deve se unir a outro canal de MDC; - separação de canal, indicando que um receptor deve se separar do presente MDC.

10. Método de acordo com qualquer uma das reivindicações de -3 a 9, caracterizado pelo fato de o conteúdo de uma instância de arquivo de interesse ser associado com um atributo indicando que o conteúdo a ser colocado na cache do receptor está armazenado na cache por uma duração especificada em outro atributo associado.

11. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de o canal de multidifusão ser um Canal de Dados de Multidifusão (MDC).

12. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de o receptor ser uma Função de Término de IPTV (ITF).

13. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de cada receptor compreender uma lista de um ou mais critérios de seleção predeterminados, cada um especificando uma regra para recepção de conteúdo de arquivo para o receptor.

14. Receptor (310a, b,c) para recepção seletiva de conteúdo de arquivo distribuído em um canal de multidifusão (312), caracterizado pelo fato de compreender: - meios para unir o canal de multidifusão; - meios (340) para receber pelo menos uma entrada de arquivo no canal de multidifusão antes do recebimento do conteúdo de arquivo associado em pelo menos uma instância de arquivo; e - meios (341) para atualizar uma lista de seleção (342), dita lista compreendendo os identificadores das instâncias de arquivo de interesse para o receptor e os atributos associados e para identificar instâncias de arquivos que são consideradas relevantes para o receptor através de filtragem de entradas de arquivo recebidas com base no conteúdo da lista de seleção.

15. Receptor de acordo com a reivindicação 14, caracterizado pelo fato de o meio para identificar instâncias de arquivos ainda ser adaptado para manipular (8:12) cada instância de arquivo conduzindo conteúdo de arquivo relevante, com base em pelo menos um atributo recuperado da entrada de arquivo associada.

16. Receptor de acordo com a reivindicação 15, caracterizado pelo fato de ainda compreender: - meios (311) para interrogar uma cache (316) para conteúdo de arquivo requerido, em que conteúdo de arquivo armazenado na cache foi distribuído para o receptor via distribuição de multidifusão, em que o meio é adaptado para recuperar o conteúdo de arquivo da cache, se ele estiver armazenado na cache, ou recuperar o conteúdo de arquivo de uma Plataforma de Servidor de Aplicativo (ASP; 300a, b,c) via uma distribuição de unidifusão, se o conteúdo de arquivo não estiver armazenado na cache.

17. Receptor de acordo com qualquer uma das reivindicações de 14 a 16, caracterizado pelo fato de o meio de identificação ser adaptado para identificar o pelo menos um atributo e o identificador de cada entrada de arquivo recebida e identificar cada uma de pelo menos uma instância de arquivo compreendendo conteúdo de arquivo, que é ligada à entrada de arquivo via um identificador idêntico.

18. Receptor de acordo com qualquer uma das reivindicações de 14 a 17, caracterizado pelo fato de o meio de identificação ser adaptado para filtrar as entradas de arquivo recebidas por meio da correspondência do pelo menos um atributo de cada respectiva entrada de arquivo com pelo menos um critério de seleção (343), especificando exigências de recepção para o receptor.

19. Receptor de acordo com a reivindicação 18, caracterizado pelo fato de o meio de recebimento ser adaptado para usar a lista de seleção a fim de aceitar instâncias de arquivos de interesse e descartar as instâncias de arquivos restantes e o meio para identificação de instâncias de arquivos ser adaptado para usar a lista de seleção para manipular instâncias de arquivos de interesse de acordo com o pelo menos um atributo associado.

20. Receptor de acordo com a reivindicação 14 a 19, caracterizado pelo fato de o receptor ainda compreender: - meios (315) para inserir conteúdo de arquivo relevante associado com um atributo assim indicando na cache ou para substituir conteúdo de arquivo já existente com uma nova versão do conteúdo de arquivo.

21. Receptor de acordo com qualquer uma das reivindicações de 14 a 20, caracterizado pelo fato de o receptor ser uma Função de Término de IPTV (ITF).

22. Receptor de acordo com qualquer uma das reivindicações de 14 a 21, caracterizado pelo fato de a ITF ser qualquer um de um set-top- box/ TV, um telefone móvel ou computador pessoal (PC).

23. Controlador de Multidifusão (MCC; 320) para gerenciamento de distribuição de multidifusão para uma pluralidade de receptores (310a, b, c) que escuta um canal de multidifusão (312) gerenciado pelo MCC, caracterizado pelo fato de compreender: - meios (330, 333) para recebimento (8:1) e enfileiramento (8:2) de solicitações de distribuição de arquivos de pelo menos uma Plataforma de Provedor de Serviços (SPP; 300 a, b, c), em que cada solicitação compreende pelo menos um atributo, cada um especificando uma condição para como manipular a solicitação e o conteúdo de arquivo associado; - meios para determinar (8:4) se um conteúdo de arquivo deve ser distribuído do MCC para os receptores através de um canal de multidifusão por considerar padrões de distribuição de arquivo e/ou padrões de solicitação de arquivo armazenados, - meios para recuperação (8:5,8:6) e um conteúdo de arquivo para ser distribuído através do canal de multidifusão; - meios (331) para programar cada distribuição de arquivos com base no pelo menos um atributo da solicitação associada; e - meios (331, 334) para formatar e distribuir (8:8) informação de descrição de arquivo em pelo menos uma entrada de arquivo associada com o conteúdo de arquivo, antes da formatação e da distribuição (8:10) do conteúdo de arquivo em pelo menos uma instância de arquivo.

24. Controlador de Multidifusão de acordo com a reivindicação 23, caracterizado pelo fato de o meio de formatação e distribuição ser adaptado para formatar cada entrada de arquivo a fim de compreender pelo menos um atributo e um identificador único ligando a entrada de arquivo a uma instância de arquivo conduzindo conteúdo de arquivo associado e formatar a instância de arquivo a fim de compreender o conteúdo de arquivo associado e um identificador idêntico.

25. Controlador de Multidifusão de acordo com a reivindicação 23 ou 24, caracterizado pelo fato de o canal de multidifusão ser um Canal de Dados de Multidifusão (MDC).