BRPI0618917A2

BRPI0618917A2 - método para distribuição de notificação de upgrade de software para dispositivos em sistemas de comunicação

Info

Publication number: BRPI0618917A2
Application number: BRPI0618917-2A
Authority: BR
Inventors: Jangwon Lee; An Mei Chen
Original assignee: Qualcomm Inc
Priority date: 2005-11-23
Filing date: 2006-11-22
Publication date: 2011-09-13
Also published as: US20120084765A1; US8516142B2; WO2007120288A2; US8112538B2; KR100944143B1; CN101361354A; EP1952616A2; RU2008125171A; US20070118617A1; RU2390963C2; US7844721B2; CN101361354B; JP2009517926A; KR20080071195A; WO2007120288A3; CA2630851A1; US20110072146A1

Abstract

MéTODO PARA DISTRIBUIçAO DE NOTIFICAçãO DE UPGRADE DE SOFTWARE PARA DISPOSITIVOS EM SISTEMAS DE COMUNICAçãO. São descritos sistemas e metodologias parafacilitar a provisão de notificações de upgrade de software para dispositivos de usuário que utilizam técnicas de conexão unicast e multicast em um ambiente de comunicação sem fio. Largura de banda e consumo de energia são minimizados ao se permitir que a determinação seja feita com relação a se uma atualização de software determinada é relevante para o dispositivo de usuário antes de tentar transferir ou receber uma notificação da mesma. Adicionalmente, avaliação de número de versão e identidade de software facilita a determinação de se deve empregar um protocolo de verificação de software unicast ou um protocolo de verificação de software multicast. Informaçãode upgrade de software também deve ser transmitida através de um canal multicast por um período de tempo predeterminado, após o qual um dispositivo de usuário pode iniciar um protocolo de verificação unicast para receber informação de upgrade de software.

Description

"MÉTODO PARA DISTRIBUIÇÃO DE NOTIFICAÇÃO DE UPGRADE DE SOFTWARE PARA DISPOSITIVOS EM SISTEMAS DE COMUNICAÇÃO". REIVINDICAÇÃO DE PRIORIDADE EM CONFORMIDADE COM 35 U.S.C. §119

Esse pedido reivindica o beneficio do Pedido Provisório dos Estados Unidos 60/739.837, intitulado "METHODS AND APPARATUS DELIVERY OF SOFTWARE UPGRADE NOTIFICATION TO DEVICES IN COMMUNICATION SYSTEMS", depositado em 23 de novembro de 2005, o qual é integralmente aqui incorporado como referência.

ANTECEDENTES

I. Campo

A descrição a seguir se refere geralmente às comunicações sem fio, e mais especificamente à facilitação de notificação de upgrade de software para os dispositivos que empregam redes unicast e multicast em um ambiente de comunicação sem fio.

II. Antecedentes

Os sistemas de comunicação sem fio se tornaram um meio prevalecente através do qual a maioria das pessoas no mundo todo se comunica. Os dispositivos de comunicação sem fio são cada vez menores e mais potentes para atender às necessidades dos usuários, e para melhorar a portabilidade e a conveniência. 0 aumento na capacidade de processamento nos dispositivos móveis tais como os telefones celulares, têm levado a um aumento de demanda para os sistemas de transmissão de redes sem fio. Tais sistemas, tipicamente, não são tão facilmente atualizados como os dispositivos celulares que se comunicam através dos mesmos. À medida que se expandem as capacidades dos dispositivos móveis, pode ser difícil manter um sistema de rede sem fio mais antigo de uma forma que facilite a exploração completa de novas e aperfeiçoadas capacidades dos dispositivos sem fio.

Uma rede de comunicação sem fio, típica, (por exemplo, empregando técnicas de divisão por freqüência, tempo e código) inclui uma ou mais estações base que proporcionam uma área de cobertura e um ou mais terminais móveis (por exemplo, sem fio) que podem transmitir e receber dados dentro da área de cobertura. Uma estação base típica pode transmitir simultaneamente múltiplos fluxos de dados para serviços de broadcast, multicast, e/ou unicast, em que um fluxo de dados é um fluxo de dados que pode ser de interesse de recepção independente para um terminal móvel. Um terminal móvel dentro da área de cobertura daquela estação base pode estar interessado em receber um, mais do que um, ou todos os fluxos de dados transportados pelo fluxo composto. Similarmente, um terminal móvel pode transmitir os dados para a estação base ou para outro terminal móvel. Tal comunicação entre a estação base e o terminal móvel ou entre terminais móveis pode ser degradada devido a variações de canal e/ou variações de energia de interferência.

Verificações de upgrade de software podem ser realizadas em ambientes de comunicação, por exemplo, a partir de um lançamento da aplicação de software, ou por intermédio de iniciação de usuário, tal como a aplicação estabelece uma conexão unicast com o servidor designado e

verifica se existe disponível qualquer upgrade de software. Os dispositivos móveis atuais, contudo, são capazes de transferir software através de uma rede sem fio, de tal modo que eles não precisam estar conectados fisicamente a um sistema para notificação de upgrade de software. Desse modo, existe a necessidade na técnica de um sistema e/ou metodologia para aperfeiçoar a capacidade de transmissão em tais sistemas de rede sem fio. SUMÁRIO

O que se segue apresenta um sumário simplificado de uma ou mais modalidades para prover um entendimento básico de tais modalidades. Esse sumário não é uma visão geral extensiva de todas as modalidades consideradas, e não pretende identificar elementos essenciais ou cruciais de todas as modalidades nem delinear o escopo de qualquer uma ou de todas as modalidades. Seu único propósito é o de apresentar alguns conceitos de uma ou mais modalidades em uma forma simplificada como um prelúdio para a descrição mais detalhada que é apresentada posteriormente.

Diversos aspectos aqui apresentados se referem a prover notificação de upgrade de software para uma aplicação em um dispositivo que utiliza redes multicast (broadcast) e unicast. Esses dois tipos de redes (multicast e unicast) podem ser de ligação física ou sem fio. Um exemplo de tal aplicação é o sistema de link direto apenas (FLO), o qual tem dois tipos de redes disponíveis: (1) FLO como uma rede multicast (broadcast) e (2) CDMA Ix EV-DO como uma rede unicast. Tipicamente, upgrade de software não ocorre freqüentemente; contudo, os dispositivos precisam se manter atualizados para upgrades de software porque o software pode ser atualizado por razões cruciais, tal como melhoramentos de recursos, reparos de falhas, violações de segurança, etc. Os aspectos aqui apresentados podem ser aplicados a qualquer tipo de entrega de informação freqüente, infreqüente e/ou crítica para dispositivos em redes sem fio. Vários aspectos facilitam a minimização dos recursos consumidos e cargas de servidor, entregando rapidamente as notificações de upgrade de software aos dispositivos, de tal modo que um dispositivo pode ser atualizado para notificações de upgrade de software sempre que o dispositivo tiver conectado à rede. De acordo com um aspecto, um método de prover notificação de upgrade de software em um ambiente de comunicação sem fio pode compreender receber informação de versão de software a partir de um servidor, realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário, e realizar um protocolo de acesso para receber uma notificação de upgrade de software. O método pode compreender adicionalmente transmitir uma notificação de upgrade de software através de um canal multicast. O protocolo de verificação pode ser um protocolo de verificação "pull" realizado através de uma conexão multicast entre um servidor e pelo menos um dispositivo de usuário, que pode compreender receber a informação de versão de software através de um canal de dados multicast, e avaliar se um ID de software recebido com a informação de versão corresponde ao dispositivo de usuário para determinar se a informação de versão de software recebido é relevante para o dispositivo de usuário. 0 protocolo de verificação também pode ser um protocolo de verificação "pull", compreendendo gerar uma conexão de ponto a ponto entre o dispositivo de usuário, solicitando a informação de upgrade de software a partir do servidor, recebendo urna resposta de servidor compreendendo a informação de versão de software, e receber uma notificação de upgrade de software se um número de versão na resposta do servidor for maior do que um número de versão associado com o software armazenado no dispositivo de usuário. O método pode compreender adicionalmente empregar um protocolo de acesso baseado em token e determinar se um token de cliente é válido no dispositivo de usuário, realizar um protocolo de verificação "pull", criando um token de cliente, e estabelecer o valor de token de cliente igual a um valor de token de servidor se o valor de cliente não for válido, e determinar se um valor de token de cliente é maior do que ou igual a um valor de token de servidor (módulo η) , se o token de cliente for válido. Ainda adicionalmente, o método pode compreender determinar se o valor de token de cliente está entre o valor de token de servidor menos m (módulo η), onde o servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token e servidor mais recentes, e o valor de token de servidor -1 (módulo η) , onde η é um valor de token máximo, se o valor de token de cliente não for maior do que ou igual ao valor de token de servidor (módulo η) . O método pode compreender adicionalmente realizar um protocolo de verificação "push" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo n) e o valor de token de servidor -1 (módulo η) , e realizar um protocolo de verificação "pull" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo n) e o valor de token de servidor -1 (módulo n).

De acordo com outro aspecto, um equipamento que facilita a provisão de notificações de upgrade de software para dispositivos de usuário que se comunicam através de conexões multicast e unicast em um ambiente de comunicação sem fio pode compreender um receptor que recebe informação de versão de software, e um processador que realiza um protocolo de verificação e um protocolo de acesso para obter uma notificação de upgrade de software. O processador pode realizar qualquer um ou ambos de um protocolo de verificação "push" e "pull", conforme descrito com relação ao método. Por exemplo, o processador pode determinar se um token de cliente é válido no dispositivo de usuário, pode comparar o valor de token de cliente com um valor dé token de servidor, etc., para determinar qual protocolo de verificação utilizar. Adicionalmente, a notificação de upgrade de software pode ser realizada utilizando um protocolo de verificação "push" para um período de tempo predeterminado, seguido por um protocolo de verificação "pull".

De acordo com outro aspecto, um equipamento de comunicação sem fio pode compreender meios para receber informação de versão de software a partir de um servidor através de ambas, uma conexão multicast e uma conexão unicast, meio para realizar o protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário, e meio para realizar um protocolo de acesso para receber uma notificação de upgrade de software. O equipamento pode compreender ainda meio para empregar um protocolo de acesso baseado em token e determinar se um token de cliente é válido no dispositivo de usuário, meio para realiza um protocolo de verificação unicast, e meio para criar um token de cliente, e meio para estabelecer o valor de token de cliente igual a um valor de token de servidor se o valor de token de cliente não for válido. O equipamento pode compreender ainda meio para determinar se um valor de token de cliente é maior do que ou igual a um valor de token de servidor (módulo η) , se o token de cliente for válido; meio para determinar se o valor de token de cliente está entre o valor de token de servidor menos m (módulo η) , onde o servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor de token de servidor -1 (módulo η) , onde η é um valor de token máximo, se o valor de token de cliente não for superior ou igual ao valor de token de servidor (módulo n) ; meio para realizar um protocolo de verificação multicast e meio para estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo n) e o valor de token de servidor -1 (módulo n) ; e meio para realizar um protocolo de verificação unicast e meio para estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo n) e o valor de token de servidor -1 (módulo n). Ademais, o equipamento pode compreender meios para prover a notificação de upgrade e de software mediante emprego de meios para realizar um protocolo de verificação de multicast por um período de tempo predeterminado, seguido por meios para executar um protocolo de verificação unicast.

Ainda outro aspecto se refere a um meio legível por computador tendo um programa de computador compreendendo instruções executáveis por computador para receber uma mensagem de overhead compreendendo informação de versão de software a partir de um servidor; realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário, e realizar um protocolo de acesso para receber uma notificação de upgrade de software. O protocolo de verificação pode ser um protocolo de verificação multicast e/ou um protocolo de verificação unicast. O meio legível por computador pode ter adicionalmente instruções para determinar qual protocolo de verificação deve executar, incluindo instruções para analisar um valor de token de cliente e comparar o valor de token de cliente com um valor de token de servidor. Um aspecto adicional se refere a um processador que executa instruções para aumentar a capacidade de transmissão em um ambiente de comunicação sem fio, as instruções compreendendo: receber uma mensagem de overhead com informação de versão de software a partir de um

servidor; realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário; e realizar um protocolo de acesso para receber uma notificação de upgrade de software. O protocolo de verificação pode ser qualquer um ou ambos,

um protocolo de verificação multicast e um protocolo de verificação unicast, conforme determinado por uma série de determinações com relação ao valor de token de cliente e valor de token de servidor. Adicionalmente, notificações de upgrade de software podem ser providas a um dispositivo de usuário utilizando um protocolo multicast por um período de tempo predeterminado, após o qual o dispositivo de usuário pode iniciar um protocolo unicast para obter informação de notificação de upgrade. Para a realização das finalidades relacionadas e

anteriormente mencionadas, uma ou mais modalidades compreendem os recursos em seguida descritos completamente e particularmente assinalados nas reivindicações. A descrição a seguir e os desenhos anexos apresentam em detalhe certos aspectos ilustrativos da uma ou mais modalidades. Esses aspectos, contudo, são indicativos de apenas umas poucas das várias formas nas quais os princípios das diversas modalidades podem ser empregados e pretende-se que as modalidades descritas incluam todos os tais aspectos e seus equivalentes.

DESCRIÇÃO RESUMIDA DOS DESENHOS

A Figura 1 ilustra um sistema de comunicação de rede sem fio de acordo com vários aspectos aqui apresentados.

A Figura 2 é uma ilustração de uma metodologia para realizar um protocolo de verificação "pull" para determinar se um upgrade de software está disponível para um dispositivo de usuário em um ambiente de comunicação sem fio, de acordo com um ou mais aspectos.

A Figura 3 é uma ilustração de um método de realizar um protocolo de verificação "pull" para determinar se um upgrade de software está disponível para um dispositivo de usuário em um ambiente de comunicação sem fio, de acordo com um ou mais aspectos.

A Figura 4 é uma ilustração de um método que facilita permitir que um dispositivo de usuário receba uma notificação de upgrade de software, de acordo com um ou mais aspectos.

A Figura 5 ilustra a metodologia que facilita a realização de um protocolo de acesso de token em combinação com cada um de um método de verificação "push" e um protocolo de verificação "pull", de acordo com vários aspectos.

A Figura 6 é uma ilustração de um cenário de notificação de um upgrade de software no qual um ou mais protocolos de verificação podem ser realizados, de acordo com uma variedade de aspectos.

A Figura 7 é uma ilustração de um sistema em uma visão geral conceptual de um método "push", um método "pull", e o método de verificação híbrido com acesso de token.

A Figura 8 é uma ilustração de um ambiente de rede sem fio que pode ser empregado com vários conjuntos e métodos aqui descritos.

A Figura 9 ilustra uma rede de comunicação que compreende um sistema de transporte que opera para criar e transportar fluxos de conteúdo de multimídia através de redes de dados, de acordo com vários aspectos.

A Figura 10 ilustra vários aspectos de um servidor de provedor de conteúdo adequado para uso em um sistema de entrega de conteúdo.

A Figura 11 ilustra um servidor ou dispositivo adequado para usò em um sistema de entrega de conteúdo, de acordo com um ou mais aspectos.

A Figura 12 é uma ilustração de um equipamento que facilita a realização de um protocolo de verificação e de um protocolo de acesso em um ambiente de comunicação sem fio, de acordo com vários aspectos.

DESCRIÇÃO DETALHADA

Várias modalidades são descritas agora com referência aos desenhos, em que numerais de referência são usados para se referir a elementos semelhantes do princípio ao fim. Na descrição a seguir, com o propósito de explanação, vários detalhes específicos são apresentados para prover um entendimento completo de uma ou mais modalidades. Pode ser evidente, contudo, que tal modalidade(s) pode ser praticada sem esses detalhes específicos. Em outros casos, estruturas e dispositivos conhecidos são mostrados na forma de diagrama de blocos para facilitar a descrição de uma ou mais modalidades.

Conforme usado nesse pedido, os termos: "componente", "sistema", e semelhantes, pretendem se referir a uma entidade relacionada a computador seja hardware, software, software em execução, firmware, middleware, microcódigo, e/ou qualquer combinação dos mesmos. Por exemplo, um componente pode ser, mas não é limitado a ser, um processo executando em um processador, um processador, um objeto, um executável, um fluxo de execução, um programa, e/ou um computador. Um ou mais componentes podem residir dentro de um processo e/ou fluxo de execução e um componente pode estar localizado em um computador e/ou distribuído entre dois ou mais comutadores. Além disso, esses componentes podem executar a partir de vários meios legíveis por computador tendo diversas estruturas de dados armazenadas nos mesmos. Os componentes podem se comunicar por intermédio de processos locais e/ou remotos tal como de acordo com um sinal tendo um ou mais pacotes de dados (por exemplo, dados a partir de um componente interagindo com outro componente em um sistema local, sistema distribuído, e/ou através de uma rede tal como a Internet com outros sistemas por intermédio do sinal). Adicionalmente, componentes de sistemas descritos aqui podem ser rearranjados e/ou complementados mediante componentes adicionais para facilitar a obtenção de vários aspectos, objetivos, vantagens, etc., descritos com relação aos mesmos, e não são limitados às configurações exatas apresentadas em uma determinada figura, como será considerado por aqueles versados na técnica.

Ademais, várias modalidades são aqui descritas em conexão com uma estação de assinante. Uma estação de assinante também pode ser chamada de um sistema, uma unidade de assinante, estação móvel, aparelho móvel, estação remota, ponto de acesso, terminal remoto, terminal de acesso, terminal de usuário, agente de usuário, um dispositivo de usuário, ou equipamento de usuário. Uma estação de assinante pode ser um telefone celular, um telefone sem fio, um telefone Protocolo de Iniciação de Sessão (SIP) , uma estação de laço local sem fio (WLL) , um assistente pessoal digital (PDA), um dispositivo de mão tendo capacidade de conexão sem fio, ou outro dispositivo de processamento conectado a um modem sem fio.

Além disso, vários aspectos ou características aqui descritos podem ser implementados como um método, equipamento, ou produto industrial utilizando técnicas padrão de programação e/ou de construção. O termo "produto industrial" conforme aqui utilizado pretende abranger um programa de computador acessível a partir de qualquer dispositivo legível por computador, portadora, ou meios. Por exemplo, meios legíveis por computador podem incluir, porém, não são limitados aos dispositivos de armazenamento magnéticos (por exemplo, disco rígido, disquete, fitas magnéticas, etc.), discos óticos (por exemplo, disco a laser (CD), disco digital versátil (DVD), etc.), cartões inteligentes, dispositivos de memória flash (por exemplo, cartão, stick, unidade de teclas, etc.). Adicionalmente, vários meios de armazenamento aqui descritos podem representar um ou mais dispositivos e/ou outros meios

legíveis por máquina para armazenar informação. O termo "meio legível por máquina" pode incluir, sem ser limitado a: canais sem fio e vários outros meios capazes de armazenar, conter, e/ou transportar instrução(ões) e/ou dados.

Com referência agora à Figura 1, um sistema de comunicação de rede sem fio 100 é ilustrado de acordo com várias modalidades aqui apresentadas. O sistema 100 pode compreender uma ou mais estações base 102 e um ou mais setores que recebem, transmitem, repetem, etc., sinais de comunicação sem fio uns para os outros e/ou para um ou ma|s dispositivos móveis 104. Cada estação base 102 pode compreender uma cadeia de transmissores e uma cadeia de receptores, cada uma das quais por sua vez pode compreender uma pluralidade de componentes associados com transmissão e recepção de sinal (por exemplo, processadores, moduladores, multiplexadores, demoduladores, demultiplexadores, antenas, etc.), como será considerado por aqueles versados na técnica. Os dispositivos móveis 104 podem ser, por exemplo, telefones celulares, telefones inteligentes, laptops, dispositivos de comunicação de mão, dispositivos de computação de mão, rádios via-satélite, sistemas de posicionamento global, PDAs, e/ou qualquer outro dispositivo adequado para comunicação através da rede sem fio 100. O sistema 100 pode ser empregado em conjunto com vários aspectos aqui descritos para facilitar a ação de notificar os dispositivos de usuário sobre um upgrade de software em um ambiente de comunicação sem fio, conforme exposto com relação às figuras subseqüentes.

De acordo com diversos aspectos aqui apresentados, o exemplo a seguir se refere a um cenário no qual um grande número de dispositivos de usuário emprega uma aplicação de notificação de upgrade de software e notificações de atualização desejada para um grande número de classes de software. Considerando uma versão de software compreendendo dois componentes, XeY, de tal modo que a classe de software é descrita como SOFTWARE_ID(X), e um número de seqüência de software é definido por Y. Pode haver múltiplas classes de software da aplicação dependendo de diferentes tipos de sistema operação (OS), diferentes provedores de rede, e diferentes tipos de dispositivo.

Desse modo, X pode compreender qualquer nivel de hierarquia, tal como, por exemplo, X = a.b.c, onde "a" é um OS_type ID, "b" é o ID de provedor de rede, e "c" é o ID de tipo de dispositivo. O número de seqüência (Y) (por exemplo, "Versão 3, Versão 5.2, etc.) é incrementado sempre que existir novo software disponível para um determinado SOFTWARE_ID.

Para notificação de upgrade de software, dois fatores de projeto podem ser considerados a partir de uma perspectiva do dispositivo, isto é: (1) a forma na qual se obtém a informação, e (2) o tempo no qual se obtém a informação. A forma na qual a informação de upgrade é obtida se refere à execução de um protocolo de "verificação", e a temporização da mesma se refere à execução de um protocolo de acesso. Conforme aqui descrito um ou mais protocolos de verificação podem ser combinados com qualquer um de uma pluralidade de protocolos de acesso. Dessa maneira, os sistemas e métodos aqui apresentados podem conservar recursos de rede mediante redução de uma necessidade de transmissões de upgrade de software consumidoras de largura de banda de longa duração, enquanto facilitando ainda a provisão de upgrades de software para os dispositivos de usuário na rede.

Com referência 2-5, são ilustradas metodologias relacionadas à notificação de um dispositivo de usuário sobre um upgrade de software. As metodologias aqui descritas podem ser realizadas em um ambiente FDMA em um ambiente OFDMA, em um ambiente CDMA, em um ambiente WCDMA, em um ambiente TDMA, em um ambiente SDMA, ou qualquer outro ambiente sem fio adequado. Embora as metodologias sejam mostradas e descritas como uma série de ações com a finalidade de simplicidade de explanação deve-se entender e considerar que as metodologias não são limitadas pela ordem das ações, uma vez que algumas ações podem, de acordo com uma ou mais modalidades, ocorrer em diferentes ordens e/ou simultaneamente com outras ações a partir daquelas mostradas e descritas aqui. Por exemplo, aqueles versados na técnica entenderão e considerarão que a metodologia alternativamente poderia ser representada como uma série de estados ou eventos relacionados entre si, tal como em um diagrama de estado. Além disso, nem todas as ações ilustradas podem ser exigidas para se implementar uma metodologia de acordo com um ou mais aspectos. A Figura 2 é uma ilustração de uma metodologia 200 para realizar um protocolo de verificação "pull" para determinar se um upgrade de software está disponível para um dispositivo de usuário em um ambiente de comunicação sem fio, de acordo com um ou mais aspectos. Conforme aqui usado, "upgrade" e "atualização" pretendem ser termos sinônimos e permutáveis que denotam uma versão mais recente de um artigo de software específico do que aquele atualmente instalado no dispositivo de usuário. "pull" pretende descrever um sistema de broadcast, multicast ou "um para muitos". Desse modo, o mecanismo "push" utiliza uma rede broadcast (multicast) em que informação é avançada a partir de um servidor para uma pluralidade de dispositivos. No mecanismo "pull" (por exemplo, tal como descrito em detalhe abaixo, com relação à Figura 3), um dispositivo inicia individualmente comunicação de ponto a ponto com o servidor, e o servidor responde a isso utilizando a rede unicast (por exemplo, o dispositivo "extrai" informação a partir do servidor).

De acordo com o método 200, um dispositivo de usuário pode receber informação de versão de software a partir de um servidor através de um canal de dados multicast dedicado, em 202. Um servidor pode transmitir continuamente um número de seqüência mais recente para uma versão de software para a totalidade das classes de software no canal de dados. SOFTWARE_ID pode ser utilizado para delinear um escopo da seqüência e/ou informação de versão de acordo com vários aspectos. Por exemplo, SOFTWARE_ID pode ser empregado como um "endereço" da mensagem, e o dispositivo apenas recebe uma mensagem "endereçada" a seu SOFTWARE_ID específico. Desse modo, um dispositivo com um SOFTWARE_ID específico sintoniza no canal de dados e avalia um sinal no mesmo até que ele encontre o número de seqüência mais recente correspondendo a seu SOFTWARE_ID, em 204. Em 206, é feita uma determinação com relação a se o número de seqüência mais recente anunciado no canal de dados é maior do que o número de seqüência do software atual do dispositivo. Se for, então uma notificação de upgrade de software deve ser entregue ao dispositivo de usuário. Em 208, o dispositivo de usuário pode prosseguir para executar um protocolo de acesso para obter o upgrade de software.

A Figura 3 é uma ilustração de um método 300 de realizar um protocolo de verificação "pull" para determinar se um upgrade de software está disponível para um dispositivo de usuário em um ambiente de comunicação sem fio, de acordo com um ou mais aspectos. Um protocolo de verificação "pull" compreende um link de comunicação de ponto a ponto entre um servidor e um dispositivo de usuário. 0 dispositivo pode individualmente criar uma conexão de ponto a ponto (unicast) com o servidor em 302. 0 dispositivo pode enviar uma mensagem de solicitação para informação de upgrade de software, em 304, para "pull" tal informação a partir do servidor. A mensagem de solicitação pode conter o SOFTWARE_ID do dispositivo e um número de seqüência indicando a versão de software mais recente no dispositivo. Em 306, o dispositivo pode receber uma mensagem de resposta a partir do servidor. De acordo com um aspecto, a mensagem de resposta pode compreender o número de seqüência mais recente associado com a aplicação de software específica para o SOFTWARE_ID provido pelo dispositivo em 304. Em tal caso, o dispositivo pode determinar se ele precisa de um upgrade de software ou não (por exemplo, mediante determinação de se o número de seqüência recebido na mensagem de resposta é maior do que o número de seqüência do software atual do dispositivo). De acordo com outro aspecto,, o servidor pode determinar se o número de seqüência do software mais recente é maior do que o número de seqüência indicado do dispositivo, e pode enviar a notificação de atualização de software na mensagem de resposta em 306 (por exemplo, "upgrade necessário" ou "nenhum upgrade necessário" ou semelhante). Em qualquer dos casos, em 308, o dispositivo pode receber uma notificação de upgrade.

Os métodos 200 e 300 podem ser combinados com qualquer um de uma pluralidade de métodos de acesso. Por exemplo, um método de acesso periódico pode ser empregado, em que o dispositivo periodicamente verifica se um upgrade de software está disponível. Para cada classe de software, um período de verificação (por exemplo, 1 dia, 5 dias, 7 dias, 30 dias, etc.) será associado, o qual pode ser diferente para diferentes classes de software. De acordo com outro método de acesso, o dispositivo pode verificar no sentido de um upgrade a partir de cada lançamento da aplicação. De acordo com ainda outro aspecto, o usuário pode iniciar uma verificação de software. Ainda outro aspecto se refere a um protocolo de acesso baseado em transação, pelo que o dispositivo realiza um protocolo de verificação a partir de uma transação entre o dispositivo e o servidor. Um aspecto adicional se refere a um método de acesso "token", o qual emprega um canal multicast dedicado, denominado canal de "overhead" para transportar informação de estado de sistema atualizado, descrita em mais detalhe abaixo na Figura 4.

A Figura 4 é uma ilustração de um método 400 que facilita a permissão para um dispositivo de usuário receber uma notificação de upgrade de software, de acordo com um ou mais aspectos. O método 400 é uma abordagem baseada em token em que um valor de token de cliente é comparado com um valor de token de servidor, o qual é periodicamente anunciado em um canal multicast. Em 402, um dispositivo pode sintonizar em um canal overhead através do qual um servidor transmite continuamente informação de overhead, a qual pode incluir uma versão de software mais recente ou número de seqüência, informação de ID de dispositivo, etc., e receber uma mensagem de overhead. O dispositivo pode sintonizar periodicamente no canal de overhead. Ao contrário dos outros canais de dados, o canal de overhead contém menores quantidades, porém cruciais, de informação para a operação da aplicação. Desse modo, os recursos necessários por um dispositivo de usuário para sintonizar nesse canal e ler a mensagem de overhead são relativamente poucos da perspectiva do dispositivo. Em 404, pode ser feita uma determinação com relação a se um token de cliente (CLI_T0KEN) está presente. De acordo com um aspecto, o dispositivo mantém localmente um valor de número inteiro CLI_T0KEN (por exemplo, um valor de número inteiro de 1 byte ou algum outro valor adequado). Inicialmente, CLI_T0KEN não está presente: contudo, a partir do recebimento da mensagem de overhead, se o CLI_T0KEN não estiver presente no dispositivo conforme determinado em 404, então o dispositivo realiza a verificação para o upgrade de software, em 406. Também em 406, o dispositivo pode criar um CLI_T0KEN e definir o mesmo igual ao SVR_T0KEN no canal de overhead.

O servidor mantém um valor de número inteiro SVR_T0KEN (por exemplo, um byte, ou algum outro valor adequado). De acordo com um exemplo de 1 byte sem ser limitado ao mesmo, o valor SVR_T0KEN pode ser incrementado por um módulo 256 a partir de 0, a partir da liberação de novos upgrades de software. O valor SVR_T0KEN pode ser continuamente anunciado no canal OVERHEAD. Se CLI_TOKEN estiver presente em 404, então em 408 uma determinação pode ser feita com relação a se CLI_TOKEN é igual ao SVR_TOKEN. Se o valor de CLI_T0KEN for menor do que o valor de SVR_T0KEN, o dispositivo realiza a verificação para o upgrade de software, e o valor de CLI_TOKEN é estabelecido para valor de SVR_TOKEN, em 412. Se o valor de CLI_TOKEN for maior do que ou igual ao valor de SVR_TOKEN, então o dispositivo tem a versão de software mais recente e nenhuma atualização é necessária, conforme indicada em 410.

Adicionalmente, SVR_TOKEN pode reiniciar ciclicamente após 256 incrementos. Desse modo, o valor de CLI_TOKEN pode ser igual ao SRV_TOKEN reiniciado ciclicamente, tal como quando o dispositivo estiver fora da rede por um longo período de tempo. Para lidar com esse cenário, o CLI_TOKEN armazenado pode ser apagado se mensagens de overhead não tiverem sido adquiridas para certo período de tempo predefinido (por exemplo, 30 dias, 45 dias, 90 dias, etc.) . Essa duração pode ser estabelecida de modo a ser substancialmente mais curta do que um período estimado exigido para reinicio cíclico de SVR_TOKEN.

A Figura 5 ilustra a metodologia 500 que facilita a realização de um protocolo de acesso token em combinação com cada um de: método de verificação "push" e um protocolo de verificação "pull", de acordo com vários aspectos. Similar ao método 400, o método 500 também utiliza um protocolo baseado em token em que um valor de token de cliente é comparado com um valor de token de servidor que é periodicamente anunciado em um canal multicast. Por exemplo, mais propriamente do que enviar todos os números de seqüência mais recentes para as classes de software inteiras conforme descrito acima, um servidor pode enviar informação de mudança incrementai entre dois SVR_TOKENs em um canal de dados. Por exemplo, em um caso onde existem dois upgrades novos para software classe AeB com SVR_TOKEN =3, o servidor pode incrementar seu SVRJTOKEN (por exemplo, para 4) e anunciar o SVR_TOKEN em um canal de overhead, (por exemplo, de uma maneira similar àquela descrita acima, com relação à Figura 3). Então, o servidor pode enviar duas mensagens de notificação de upgrade de software no canal de dados. O formato da mensagem pode compreender uma pluralidade de campos. Por exemplo, "SVRJTOKEN" pode compreender um valor associado com um upgrade de software. "NUMJRECORD" pode definir um número de notificações de upgrade de software adicionado em um determinado SVRJTOKEN. "RECORD_ID" pode ser atribuído singularmente entre notificações de upgrade de software NUM_RECORD. "SOFTWARE_ID" pode ser definido conforme descrito acima. "LATEST_SQN_NUM " pode definir um número de seqüência mais recente para o SOFTWARE_ID. Mediante utilização do NUM_RECORD e RECORD_ID de cada mensagem, o dispositivo pode determinar quantas notificações de upgrade de software devem ter coletadas e quando parar de procurar por notificações de upgrade.

Conseqüentemente, o método 500 começa em 502, onde um dispositivo de usuário pode receber uma mensagem de overhead. Em 504, pode ser feita uma determinação com relação a se existe um CLI_TOKEN. Se não existir, então um protocolo de verificação "pull" pode ser realizado e o CLI_TOKEN pode ser criado e estabelecido igual ao SVRJTOKEN em 506. Se um token de cliente for válido em 504, então em 508, pode ser feita uma determinação com relação a se o valor de token de cliente é maior ou igual ao valor de token de servidor (módulo η) , onde η é um número de token máximo. Se o valor de token de cliente for maior ou igual ao valor de token de servidor, então nenhuma ação precisa ser realizada, conforme indicado em 510, porque o dispositivo está atualizado e tem a versão mais recente do software em questão.

Se o valor de token de cliente for menor do que o valor de token de servidor, então em 512, uma determinação pode ser feita com relação a se o valor de token de cliente está entre o valor de token de servidor -m (módulo n) onde o servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor e token de servidor -1 (módulo η) , se o valor de token de cliente não for maior do que ou igual ao valor de token de servidor (módulo n) (por exemplo, com referência ao cenário em que o valor de token de servidor reinicia ciclicamente a partir do valor máximo, n, até zero) . Por exemplo, um servidor pode transmitir continuamente e/ou periodicamente notificações de upgrade de software associadas com m valores de token mais recentes. Por exemplo, m pode ser um número preestabelecido, tal como 3, de tal modo que o servidor transmite continuamente e/ou periodicamente as modificações de upgrade de software associadas com os três valores de token de servidor mais recentes. Adicionalmente ou alternativamente, m pode ser definido dinamicamente e ser incluído na mensagem de overhead. De acordo com outro exemplo, em um cenário no qual η é um valor de número inteiro expresso por um único byte (por exemplo, um valor de 8 bits) , η pode ter um valor máximo de 255, e uma condição de reinicio cíclico pode surgir quando o valor de cliente atinge 255 e o token de servidor realizou reinicio cíclico para 0 (por exemplo, ou algum outro valor menor do que 255) . Em tal cenário, o valor de token de cliente pode parecer ser maior do que o valor de token de servidor, embora o dispositivo de cliente seja qualificado para uma notificação de upgrade de software. Para minorar o problema de reinicio cíclico, se um servidor transmite notificações de upgrade de software multicast que são associadas com um número de upgrades na faixa de SVR_TOKEN-m (módulo 255) a SVR_T0KEN-1 (módulo 255) (por exemplo, um token de servidor mais recente), então um critério pode ser estabelecido para garantir que o valor de token de cliente esteja compreendido entre os valores "SVR_TOKEN-m (módulo 255)" e "SVR_T0KEN-1 (módulo 255)", antes de se iniciar um protocolo de verificação "push". Será considerado que o exemplo anterior é de natureza ilustrativa e tem o propósito de facilitar o entendimento do mecanismo mediante o qual se recorre a uma condição de reinicio cíclico, e que η pode ser qualquer número inteiro adequado (por exemplo, 512, 1000, 1024) e não é limitado ao valor 255 associado com um valor de número inteiro de byte único máximo.

Se a condição for verdadeira em 512, então em 514 um protocolo de verificação "push" pode ser implementado, após o qual o valor de token de cliente pode ser estabelecido igual ao valor de token de servidor. Se a condição não for verdadeira em 512, então em 516, um protocolo de verificação "pull" pode ser implementado, após o que o valor de token de cliente pode ser estabelecido igual ao valor de token de servidor. Como com o método 400, um token de cliente armazenado pode ser apagado se mensagens de overhead não tiverem sido adquiridas por certo período de tempo predefinido (por exemplo, 15 dias, 31 dias, 60 dias, etc.). Essa duração pode ser estabelecida para ser substancialmente mais curta do que um período estimado exigido para reinicio cíclico SVR_TOKEN.

A discussão a seguir apresenta diversas variações para os métodos 400 e 500. Por exemplo, o servidor pode parar de enviar informação de upgrade de software incrementai no canal de dados após um período de tempo predefinido. Nesse caso, o dispositivo pode utilizar um método de verificação "pull" se ele não puder coletar as notificações de upgrade de software no canal de dados. De acordo com outro exemplo, mais propriamente do que enviar mudança incrementai entre o SVR_TOKEN mais recente e o SVR_TOKEN-l, o servidor pode enviar valor de mudança que descreve uma diferença entre o SVR_TOKEN mais recente e o SVR_TOKEN-M. Nesse caso, pode haver M números de mudanças de token, e a informação de upgrade de software correspondente pode ser enviada através do canal de dados. No evento em que CLI_T0KEN está entre SVR_TOKEN-M e SVR_T0KEN (incluindo um caso de reinicio cíclico), então o dispositivo pode utilizar um protocolo de verificação "push". Caso contrário, o dispositivo pode utilizar um protocolo de verificação "pull".

De acordo com ainda outro aspecto, existem duas maneiras nas quais se podem transferir upgrade de software: (1) ponto a ponto e (2) multicast. Para implementações de ponto a ponto, após aprovação de um usuário, cada dispositivo pode criar uma conexão de ponto a ponto com o servidor e transferir a aplicação de software atualizada. Para multicast, o servidor pode multicast a aplicação atualizada por um determinado período de tempo (por exemplo, uma semana, 30 dias, etc.). Desse modo, dependendo do protocolo de transferência, a mensagem de notificação de upgrade de software no canal de dados pode ter campos adicionais. Por exemplo, um campo "NOTIFICATION_DELAY" pode ser adicionado à mensagem se um mecanismo de transferência de ponto a ponto for utilizado. 0 dispositivo pode gerar um número aleatório entre 0 e um valor de NOTIFICATION_DELAY, e pode notificar o usuário sobre uma necessidade de upgrade de software após o tempo aleatório escolhido. Esse parâmetro facilita a entrega dos registros de notificação de upgrade aos dispositivos, simultaneamente. Se um mecanismo de transferência automática for empregado após a permissão de um usuário, um surto de solicitações de transferência pode sobrecarregar os sítios de transferência. Adicionalmente, o campo "CONTACT_WINDOW" pode ser adicionado à mensagem se multicast for utilizado para transferência de atualização de aplicação, o que pode indicar quando sintonizar em um canal de broadcast para transferir a aplicação atualizada.

A Figura 6 é uma ilustração de um cenário de notificação de upgrade de software 600 no qual um ou mais protocolos de verificação podem ser realizados, de acordo com uma variedade de aspectos. De acordo com o cenário, um token de servidor foi atualizado de 3 para 4, conforme indicado pela seta a partir de 3 para 4 na figura. Pode-se supor que existam dois novos upgrades para classes de software AeB, e o servidor pode anunciar o SVR_TOKEN em um canal de overhead. O servidor pode então enviar duas mensagens de notificação de upgrade de software em um canal de dados, utilizando um protocolo de verificação "push" se

o valor de token de cliente for igual a 3. 0 cliente pode solicitar uma notificação de upgrade utilizando um protocolo de verificação "pull" se o valor de token de cliente não for igual a 3.

A Figura 7 é uma ilustração de um sistema 700 em uma visão geral conceptual de um método "push" 7 02, um método "pull" 704, e um método de verificação híbrido 706 com acesso de token. De acordo com vários aspectos, é descrita a abordagem híbrida utilizando ambos os protocolos de verificação, "push" e "pull". Nos casos onde eventos de upgrade de software não ocorrem freqüentemente, uma quantidade de dados de broadcast relacionados apenas a uma mudança incrementai mais recente será relativamente pequena, a qual pode conservar recursos de broadcast. Adicionalmente, o protocolo hibrido entrega notificações de upgrade, instantâneas, aos dispositivos conectados a uma rede. Ademais, o período de tempo entre mudança de SVR_TOKEN é provavelmente grande. Conseqüentemente, a maioria dos dispositivos pode estar sincronizada com o valor de SVR_T0KEN e apenas uns poucos podem exigir que um mecanismo "pull" seja atualizado, o que por sua vez conserva os recursos unicast.

Dependendo da importância de um upgrade em comparação com um upgrade anterior, existem múltiplos níveis de urgência de upgrade de software (URGENCY_LEVEL) associados com cada upgrade de software. A informação de nível de urgência de upgrade de software também pode ser adicionada à mensagem de modificação. Por exemplo, a partir do nível 1 a 3, o nível 1 pode ser crucial, o nível 2 pode ser moderado, e o nível 3 pode ser opcional. Dependendo do URGENCY_LEVEL, um dispositivo pode se comportar de diferentes maneiras. Por exemplo, quando uma aplicação é rotulada com nível 1, um dispositivo pode desistir da aplicação e forçar o usuário a transferir o upgrade do novo software para proteger o dispositivo contra dano.

A Figura 8 mostra um sistema de comunicação sem fio exemplar 800. 0 sistema de comunicação sem fio 800 ilustra uma estação base e um terminal com o propósito de brevidade. Contudo, deve ser considerado que o sistema pode incluir mais do que uma estação base e/ou mais do que um terminal, em que as estações base adicionais e/ou terminais podem ser substancialmente similares ou diferentes para a estação base e terminal, exemplares, descritos abaixo. Além disso, deve ser considerado que a estação base e/ou o terminal pode entregar os sistemas (Figuras 1, 6, 7, e 9- 12) e/ou métodos (Figuras 2-5) descritos aqui para facilitar a comunicação sem fio entre os mesmos.

Com referência agora à Figura 8, em um downlink, no ponto de acesso 805, um processador de dados de transmissão (TX) 810 recebe, formata, codifica, intercala, e modula (ou mapeia em símbolos) os dados de tráfego e provê símbolos de modulação ("símbolos de dados"). Um modulador de símbolo 815 recebe e processa os símbolos de dados e os símbolos piloto e provê um fluxo de símbolos. Um modulador de símbolos 820 multiplexa os dados e símbolos piloto e provê os mesmos a uma unidade transmissora (TMTR) 820. Cada símbolo de transmissão pode ser um símbolo de dados, um símbolo piloto, ou um valor de sinal de zero. Os símbolos piloto podem ser enviados continuamente em cada período de símbolo. Os símbolos piloto podem ser multiplexados por divisão de freqüência (FDM), multiplexados por divisão de freqüência ortogonal (OFDM), multiplexados por divisão de tempo (TDM), multiplexados por divisão de freqüência (FDM), ou multiplexados por divisão de código (CDM).

TMTR 820 recebe e converte o fluxo de símbolos em um ou mais sinais analógicos e adicionalmente condiciona (por exemplo, amplifica, filtra, e converte ascendentemente em freqüência) os sinais analógicos para gerar um sinal de downlink adequado para transmissão através do canal sem fio. O sinal de downlink é, então, transmitido através de uma antena 825 para os terminais. No terminal 830, uma antena 835 recebe o sinal de downlink e provê um sinal recebido para uma unidade receptora (RCVR) 840. A unidade receptora 840 condiciona (por exemplo, filtra, amplifica, e converte descendentemente em freqüência) o sinal recebido e digitaliza o sinal condicionado para obter as amostras. Um demodulador de símbolos 845 demodula e provê os símbolos piloto recebidos a um processador 850 para estimativa de canal. O demodulador de símbolo 8 45 adicionalmente recebe uma estimativa de resposta de freqüência para o downlink a partir do processador 850, realiza demodulação de dados nos símbolos de dados recebidos para obter estimativas de símbolos de dados (as quais são estimativas dos símbolos de dados transmitidos), e provê as estimativas de símbolos de dados a um processador de dados RX 855, o qual demodula (isto é, desmapeia em símbolos), desintercala, e decodifica as estimativas de símbolos de dados para recuperar os dados de tráfego transmitidos. O processamento pelo demodulador de símbolos 845 e processador de dados RX 855 é complementar ao processamento pelo modulador de símbolos 815 e processador de dados TX 810, respectivamente, no ponto de acesso 805.

No uplink, um processador de dados TX 860 processa os dados de tráfego e provê símbolos de dados. Um modulador de símbolos 8 65 recebe e multiplexa os símbolos de dados com símbolos piloto, realiza modulação, e provê um fluxo de símbolos. Uma unidade transmissora 870 então recebe e processa o fluxo de símbolos para gerar um sinal de uplink, o qual é transmitido pela antena 835 para o ponto de acesso 805.

No ponto de acesso 805, o sinal de uplink a partir do terminal 830 é recebido pela antena 825 e processado por uma unidade receptora 875 para obter as amostras. Um demodulador de símbolos 880 então processa as amostras e provê os símbolos piloto recebidos e as estimativas de símbolos de dados para o uplink. Um processador de dados RX 885 processa as estimativas de símbolos de dados para recuperar os dados de tráfego transmitidos pelo terminal 830. Um processador 890 realiza estimativa de canal para cada' terminal ativo transmitindo no uplink. Múltiplos terminais podem transmitir piloto simultaneamente no uplink em seus conjuntos atribuídos respectivos de sub-bandas piloto, onde os conjuntos de sub- bandas piloto podem ser entrelaçados.

Os processadores, 890 e 850, dirigem (por exemplo, controlam, coordenam, gerenciam etc.) a operação no ponto de acesso 805 e terminal 830, respectivamente. Os processadores respectivos 890 e 850 podem ser associados com unidades de memória (não mostradas) que armazenam códigos de programa e dados. Os processadores, 890 e 850, também podem realizar computações para derivar estimativas de resposta e impulso e freqüência para o uplink e para o downlink, respectivamente.

Para um sistema de acesso múltiplo (por exemplo, FDMA, OFDMA, CDMA, TDMA, etc.), múltiplos terminais podem transmitir simultaneamente no uplink. Para tal sistema, as sub-bandas piloto podem ser compartilhadas entre diferentes terminais. As técnicas de estimativas de canal podem ser usadas em casos onde as sub-bandas piloto para cada terminal cobrem a banda de operação inteira (possivelmente, exceto as bordas de banda). Tal estrutura de sub-banda piloto seria desejada para se obter diversidade de freqüência para cada terminal. As técnicas aqui descritas podem ser implementadas por vários meios. Por exemplo, essas técnicas podem ser implementadas em hardware, software, ou uma combinação dos mesmos. Para uma implementação de hardware, as unidades de processamento usadas para estimativa de canal podem ser implementadas dentro de um ou mais circuitos integrados de aplicação específica (ASICs), processadores de sinais digitais (DSPs), dispositivos de processamento de sinais digitais (DSPDs), dispositivos lógicos programáveis (PLDs), arranjos de portas programáveis no campo (FPGAs), processadores, controladores, microcontroladores, microprocessadores, outras unidades eletrônicas projetadas para realizar as funções aqui descritas, ou uma combinação dos mesmos. Com software, a implementação pode ser através de módulos (por exemplo, procedimentos, funções, e assim por diante) que realizam as funções aqui descritas. Os códigos de software podem ser armazenados em unidades de memória e executados pelos processadores, 890 e 850.

A Figura 9 ilustra uma rede de comunicação 900 que compreende um sistema de transporte que opera para criar e transportar fluxos de conteúdo de multimídia através de redes de dados, de acordo com vários aspectos. Por exemplo, o sistema de transporte é adequado para uso no transporte de clipes de conteúdo a partir de uma rede de servidor para uma rede de acesso sem fio para distribuição de broadcast. A rede 900 compreende um servidor 902, uma rede de multicast 906, e uma rede de acesso sem fio 908. A rede 900 também inclui dispositivos 910 que compreendem um telefone móvel 912, assistente pessoal digital (PDA) 914, e um computador notebook 916. Os dispositivos 910 ilustram apenas alguns dos dispositivos que são adequados para uso em um ou mais aspectos do sistema de transporte. Deve ser observado que embora três dispositivos sejam mostrados na Figura 9, virtualmente qualquer número de dispositivos, ou tipos de dispositivos, é adequado para uso no sistema de transporte.

O servidor 902 opera para prover conteúdo para distribuição para os usuários' na rede 900. O conteúdo compreende vídeo, áudio, conteúdo de multimídia, clipes, conteúdo em tempo real e em tempo não-real, roteiros, programas, dados, ou qualquer outro tipo de conteúdo adequado. O servidor 902 provê o conteúdo para a rede multicast 906 e/ou para a rede unicast 908 para distribuição. Por exemplo, o servidor 902 se comunica com. a rede unicast 908 por intermédio do link de comunicação 918, o qual compreende qualquer tipo adequado de link de comunicação cabeado e/ou sem fio.

A rede 900 compreende qualquer combinação de rede cabeada e sem fio que opera para distribuir conteúdo para entrega aos usuários. 0 servidor 902 se comunica com a rede multicast 906 por intermédio do link 920. O link 920 compreende qualquer tipo adequado de link de comunicação cabeado e/ou sem fio. A rede multicast 906 compreende qualquer combinação de redes cabeadas e sem fio que são projetadas para transmitir conteúdo de alta qualidade. Por exemplo, a rede multicast 906 pode ser uma rede patenteada especializada que foi otimizada para entregar conteúdo de alta qualidade a dispositivos selecionados através de uma pluralidade de canais de comunicação otimizados.

Em um ou mais aspectos, o sistema de transporte opera para entregar conteúdo a partir do servidor 902 através da rede multicast 906 e da rede unicast 908, para os dispositivos 910. Por exemplo, o fluxo de conteúdo pode compreender um clipe de conteúdo em tempo não-real que foi provido pelo servidor 902 para distribuição utilizando a rede multicast 906. Em um aspecto, o servidor 902 opera para negociar com a rede multicast 906 para determinar um ou mais parâmetros associados com o clipe de conteúdo.

Quando a rede multicast 906 recebe o clipe de conteúdo, ela realiza broadcast/multicast do clipe de conteúdo através da rede 900 para recepção por um ou mais dos dispositivos 910. Qualquer um dos dispositivos 910 pode ser autorizado a receber o clipe de conteúdo e armazenar o mesmo em cache para visualização posterior pelo usuário do dispositivo.

Por exemplo, o dispositivo 910 compreende um programa de cliente 932 que opera para prover um guia de programas que exibe uma listagem de conteúdos que é programado para transmissão através da rede 900. O usuário do dispositivo pode, então, selecionar receber qualquer conteúdo especifico para renderização em tempo real ou para ser armazenado em um cache 934 para posterior visualização.

Por exemplo, o clipe de conteúdo pode ser programado para transmissão durante as horas da noite, e o dispositivo 912 opera para receber a transmissão e armazenar em cache o clipe de conteúdo no cache 934 de modo que o usuário do dispositivo pode visualizar o clipe no dia seguinte.

Tipicamente, o conteúdo é transmitido como parte de um

serviço de subscrição e o dispositivo receptor pode precisar prover uma chave ou de outro modo autenticar a si próprio para receber a transmissão.

A Figura 10 ilustra vários aspectos de um servidor de provedor de conteúdo 1000 adequado para uso em

um sistema de entrega de conteúdo. Por exemplo, o servidor 1000 pode ser usado como o servidor 902 na Figura 9. O servidor 1000 compreende lógica de processamento 1010, recursos e interfaces 1004, e lógica de transceptor 1010, todos acoplados a um barramento de dados interno 1012. O

servidor 1000 também compreende lógica de ativação 1014, PG 1006, e lógica de registro PG 1008, os quais também são acoplados a barramento de dados 1012. Em um ou mais aspectos, a lógica de processamento 1002 compreende uma CPU, processador, arranjo de portas, lógica de hardware,

elementos de memória, máquina virtual, software, e/ou qualquer combinação de hardware e software. Desse modo, a lógica de processamento 1002 geralmente compreende lógica para executar instruções legíveis por máquina e para controlar um ou mais diferentes elementos funcionais do

servidor 1000 por intermédio do barramento de dados interno 1012.

Os recursos e interfaces 1004 compreendem hardware e/ou software que permitem que o servidor 1000 se comunique com sistemas internos e externos. Por exemplo, os sistemas internos podem incluir sistemas de armazenamento em massa, memória, acionador de display, modem, ou outros recursos de dispositivos internos. Os sistemas externos podem incluir dispositivos de interface de usuário, impressoras, unidade de disco, ou outros dispositivos ou sistemas locais. A lógica de transceptor 1010 compreende lógica de hardware e/ou software que opera para permitir que o servidor 1000 transmita e receba dados e/ou outra informação com dispositivos ou sistemas remotos utilizando o canal de comunicação 1016. Por exemplo, em um aspecto, o canal de comunicação 1016 compreende qualquer tipo adequado de link de comunicação para permitir que o servidor 1000 se comunique com uma rede de dados.

A lógica de ativação 1014 compreende uma CPU, processador, arranjo de porta, lógica de hardware, elementos de memória, máquina virtual, software, e/ou qualquer combinação de hardware e software. A lógica de ativação 1014 opera para ativar um servidor e/ou um dispositivo para permitir que o servidor e/ou o dispositivo selecione e receba conteúdo e/ou serviços descritos no PG 1006. Em um aspecto, a lógica de ativação 1014 transmite um programa de cliente 1020 para o servidor e/ou para o dispositivo durante o processo de ativação. 0 programa de cliente 1020 executa no servidor e/ou dispositivo para receber o PG 1006 e exibir informação sobre conteúdo ou servidor que estão disponíveis para o usuário de dispositivo. Desse modo, a lógica de ativação 1014 opera para autenticar um servidor e/ou um dispositivo, transferir o cliente 1020, e transferir o PG 1006 para renderização no dispositivo pelo cliente 1020.

O PG 1006 compreende informação em qualquer formato adequado que descreve conteúdo e/ou serviços que estão disponíveis para recebimentos pelos dispositivos. Por exemplo, o PG 1006 pode ser armazenado em uma memória local do servidor 1000 e pode compreender informação tal como identificadores de conteúdo ou serviço, informação de

programação, preços, e/ou qualquer outro tipo de informação relevante. Em um aspecto, o PG 1006 compreende uma ou mais seções identificáveis que são atualizadas pela lógica de processamento 1002 quando mudanças são feitas para o conteúdo ou serviços disponíveis.

O registro de PG 1008 compreende hardware e/ou software que opera para gerar mensagens de notificação que identificam e/ou descrevem mudanças para o PG 1006. Por exemplo, quando a lógica de processamento 1002 atualiza o PG 1006, a lógica de registros de PG 1008 é notificada sobre as mudanças. A lógica de registros de PG 1008 então gera uma ou mais mensagens de notificação que são transmitidas para os servidores, os quais podem ter sido ativados com o servidor 1000, de modo que esses servidores são notificados imediatamente sobre as mudanças para o PG 1006.

Em vários aspectos, como parte da mensagem de notificação de entrega de conteúdo, um indicador de broadcast é provido o qual indica quando uma seção do PG identificada na mensagem será transmitida. Por exemplo, em um aspecto, o indicador de broadcast compreende um bit para indicar que a seção será transmitida e um indicador de tempo que indica quando ocorrerá a transmissão. Desse modo, os servidores e/ou os dispositivos pretendendo atualizar sua cópia local dos registros de PG podem ouvir a transmissão no tempo designado para receber a seção atualizada dos registros de PG. Em um aspecto, o sistema de notificação de entrega de conteúdo compreende instruções de programa armazenadas em um meio legível por computador, o qual quando executado por um processador, por exemplo, a lógica de processamento 1002, provê as funções do servidor 1000 aqui descritas. Por exemplo, as instruções de programa podem ser carregadas no servidor 1000 a partir de um meio legível por computador, tal como um disquete, CD-ROM, cartão de memória, dispositivo de memória FLASH, RAM, ROM ou qualquer outro tipo de dispositivo de memória ou meios legíveis por computador que estabelecem interface com o servidor 1000 através dos recursos 1004. Em outro aspecto, as instruções podem ser transferidas para o servidor 1000 a partir de um dispositivo externo ou recurso de rede que estabelece interface com o servidor 1000 através da lógica de transceptor 1010. As instruções de programa quando executadas pela lógica de processamento 1002, proporcionam um ou mais aspectos de um sistema de notificação de estado de guia conforme aqui descrito.

A Figura 11 ilustra um servidor ou dispositivo 1100 adequado para uso em um sistema de entrega de conteúdo, de acordo com um ou mais aspectos. Por exemplo, o servidor 1100 pode ser o servidor 902 ou o dispositivo 910 mostrado na Figura 9. O servidor 1100 compreende lógica de processamento 1102, recursos e interfaces 1104, a lógica de transceptor 1106, todos acoplados a um barramento de dados 1108. O servidor 1100 também compreende um cliente 1110, uma lógica de programa 1114 e uma lógica de PG 1112, as quais também são acopladas ao barramento de dados 1108. Em um ou mais aspectos, a lógica de processamento 1102 compreende uma CPU, processador, arranjo de portas, lógica de hardware, elementos de memória, máquina virtual, software, e/ou qualquer combinação de hardware e software. Desse modo, a lógica de processamento 1102 geralmente compreende lógica configurada para executar instruções legíveis por máquina e para controlar um ou mais diferentes elementos funcionais do servidor 1100 por intermédio do barramento interno de dados 1108.

Os recursos e interfaces 1104 compreendem hardware e/ou software que permitem que o servidor 1100 se comunique com os sistemas interno e externo. Por exemplo, os sistemas internos podem incluir sistemas de armazenamento em massa, memória, acionador de display, modem, ou outros recursos de dispositivos internos. Os sistemas externos podem incluir dispositivos de interface de usuário, impressoras, unidades de disco, ou outros dispositivos ou sistemas locais. A lógica de transceptor 1106 compreende hardware e/ou software que operam para permitir que o servidor 1100 transmita e receba dados e/ou outra informação com dispositivos externos ou sistemas através do canal de comunicação 1114. Por exemplo, o canal de comunicação 1114 pode compreender um link de comunicação de rede, um link de comunicação sem fio, ou qualquer outro tipo de link de comunicação.

Durante operação, o servidor e/ou o dispositivo 1100 é ativado de modo que ele pode receber conteúdo disponível ou serviços através de uma rede de dados. Por exemplo, em um aspecto, o servidor e/ou o dispositivo 1100 se identifica junto a um servidor de provedor de conteúdo durante um processo de ativação. Como parte do processo de ativação, o servidor e/ou o dispositivo 1100 recebe e armazena registros de PG por intermédio da lógica de PG 1112. O PG 1112 contém informação que identifica conteúdo ou serviços disponíveis para recebimento pelo servidor 1100. 0 cliente 1110 opera para renderizar informação na lógica de PG 1112 no servidor e/ou no dispositivo, 1100, utilizando os recursos e interfaces 1104. Por exemplo, o cliente 1110 renderiza informação na lógica de PG 1112 em uma tela de display que é parte do dispositivo. O cliente 1110 também recebe entrada de usuário através dos recursos e interfaces de modo que um usuário de dispositivo pode selecionar conteúdo ou serviços.

Em alguns aspectos, o servidor 1100 recebe mensagens de notificação através da lógica de transceptor 1106. Por exemplo, as mensagens podem ser broadcast ou unicast para o servidor 1100 e recebidas pela lógica de transceptor 1106. As mensagens de notificação de PG identificam atualizações para os registros de PG na lógica de PG 1112. Em um aspecto, o cliente 1110 processa as mensagens de notificação de PG para determinar se a cópia local na lógica de PG 1112 precisa ser atualizada. Por exemplo, em um aspecto, as mensagens de notificação incluem um identificador de seção, tempo de inicio, tempo de fim, e número de versão. 0 servidor 1100 opera para comparar a operação nas mensagens de modificação de PG com informação localmente armazenada na lógica de PG existente 1112. Se o servidor 1100 determinar a partir das mensagens de notificação de PG que uma ou mais seções da cópia local na lógica PG 1112 precisam ser atualizadas, o servidor 1100 opera para receber as seções atualizadas do PG em uma das várias formas. Por exemplo, as seções atualizadas do PG podem ser transmitidas em um momento indicado nas mensagens de notificação de PG, de modo que a lógica de transceptor 1106 pode receber as transmissões e passar as seções atualizadas para o servidor 1100, o qual por sua vez atualiza a cópia local na lógica de PG 1112.

Em outros aspectos, o servidor 1100 determina quais seções do PG precisam ser atualizadas com base nas mensagens de notificação de atualização de PG recebidas, e transmite uma solicitação para um servidor CP para obter as seções atualizadas desejadas do PG. Por exemplo, a solicitação pode ser formatada utilizando qualquer formato adequado e compreende informação tal como um identificador de servidor solicitante, identificador de seção, número de versão, e/ou qualquer outra informação adequada. Em um aspecto, o servidor 1100 realiza uma ou mais das seguintes funções em um ou mais aspectos de um sistema de notificação de PG. Deve ser observado que as funções a seguir poderiam ser mudadas, rearranjadas, modificadas, adicionadas, deletadas, ou de outra forma ajustadas dentro do escopo dos aspectos. O servidor pode ser ativado para operação com um sistema de provedor de conteúdo para receber conteúdo de serviços. Como parte do processo de ativação, um cliente e PG são transmitidos para o servidor. Uma ou mais mensagens de notificação de PG podem ser recebidas pelo servidor e usadas para determinar se uma ou mais seções do PG localmente armazenado precisam ser atualizadas. Em um aspecto, se o servidor determina que uma ou mais seções do PG localmente armazenado precisam ser atualizadas, o servidor presta atenção em uma transmissão a partir do sistema de distribuição para obter as seções atualizadas do PG que ele precisa para atualizar sua cópia local. Em um aspecto, o servidor transmite uma ou mais mensagens de solicitação para o CP para obter as. seções atualizadas do PG que ele precisa. Em resposta à solicitação, o setor transmite as seções atualizadas do PG para o servidor. O servidor utiliza as seções atualizadas recebidas do PG para atualizar sua cópia local do PG.

De acordo ainda com outros aspectos, o sistema de entrega de conteúdo compreende instruções de programa armazenadas em meios legíveis por computador, as quais quando executados por um processador, tal como a lógica de processamento 1102, provêem as funções do sistema de notificação de entrega de conteúdo conforme aqui descrito. Por exemplo, as instruções podem ser carregadas no servidor 1100 a partir de um meio legível por computador, tal como um disquete, CD-ROM, cartão de memória, dispositivo de memória FLASH, RAM, ROM, ou qualquer outro tipo de dispositivo de memória ou meio legível por computador que estabelece interface com o servidor 1100 através dos recursos e interfaces 1104. Em outro aspecto, as instruções podem ser transferidas para o servidor 1100 a partir de um recurso de rede que estabelece interface com o servidor 1100 através da lógica de transceptor 1106. As instruções, quando executadas pela lógica de processamento 1102, proporcionam um ou mais aspectos de um sistema de entrega de conteúdo conforme aqui descrito. Deve ser observado que o servidor 1100 representa apenas uma implementação e que outras implementações são possíveis dentro do escopo dos aspectos.

A Figura 12 é uma ilustração de um equipamento 1200 que facilita a realização de um protocolo de verificação e de um protocolo de acesso em um ambiente de comunicação sem fio, de acordo com vários aspectos. O

equipamento 1200 pode compreender meios para receber, 1202, informação de versão de software, tal como um número de seqüência e/ou ID de software associado com uma classe de software. O equipamento compreende ainda meio para realizar um protocolo de verificação 1204, o qual pode realizar ou um protocolo de verificação "push" ou um protocolo de verificação xxpull", ou ambos, dependendo de certas condições (por exemplo, tal como descrito acima com relação às Figuras 2 e 3). O equipamento 1200 compreende ainda meio para realizar um protocolo de acesso para facilitar a determinação de se uma modificação de upgrade é exigida. Meio para realizar um protocolo de acesso 1206 pode realizar um protocolo periódico que é executado em intervalos predeterminados, um protocolo iniciado por lançamento que é executado cada vez que o software é lançado, um protocolo iniciado pelo usuário que é executado a partir de um comando do usuário, um protocolo baseado em transação que é iniciado a partir de uma transação entre o cliente e um servidor, etc. Adicionalmente, o meio para realizar um protocolo de acesso 1206 pode executar um protocolo de acesso de token, tal como é descrito em detalhe com relação às Figuras 4 e 5. Dessa maneira, o equipamento 1200 pode facilitar a determinação de se o software em um dispositivo de usuário está atualizado ou se uma notificação de upgrade de software é exigida para o dispositivo.

Para uma implementação de software, as técnicas aqui descritas podem ser implementadas com módulos (por exemplo, procedimentos, funções e assim por diante) que realizam as funções aqui descritas. Os códigos de software podem ser armazenados em unidades de memória e executados por processadores. A unidade de memória pode ser implementada dentro do processador ou externa ao processador, em cujo caso ela pode ser acoplada de forma comunicativa com o processador por intermédio de vários meios conforme sabido na técnica.

O que foi descrito acima inclui exemplos de uma ou mais modalidades. Evidentemente, não é possível descrever cada combinação concebível de componentes ou metodologias com o propósito de descrever as modalidades anteriormente mencionadas, porém aqueles de conhecimento comum na técnica podem reconhecer que são possíveis muitas combinações e permutações adicionais de várias modalidades.

Conseqüentemente, as modalidades descritas pretendem abranger todas as tais alterações, modificações e variações que estejam compreendidas dentro do espírito e escopo das reivindicações anexas. Além disso, na amplitude em que o termo "inclui" é usado seja na descrição detalhada ou nas reivindicações, pretende-se que tal termo seja incluído de uma forma similar ao termo "compreendendo" conforme "compreendendo" é interpretado com uma palavra de transição em uma reivindicação.

Claims

1. Método de prover modificação de upgrade de software em um ambiente de comunicação sem fio, compreendendo: receber informação de versão de software a partir de um servidor; realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário; e realizar um protocolo de acesso para receber uma notificação de upgrade de software.

2. Método, de acordo com a reivindicação 1, em que o protocolo de verificação é um protocolo de verificação "push" realizado através de uma conexão multicast entre um servidor e pelo menos um dispositivo de usuário.

3. Método, de acordo com a reivindicação 2, compreendendo ainda transmitir notificações de upgrade de software através de um canal multicast.

4. Método, de acordo com a reivindicação 2, compreendendo ainda receber a informação de versão de software através de um canal de dados multicast.

5. Método, de acordo com a reivindicação 4, compreendendo ainda avaliar se um ID de software recebido com a informação de versão na notificação corresponde ao dispositivo de usuário para determinar se a informação de versão de software recebida é relevante para o dispositivo de usuário.

6. Método, de acordo com a reivindicação 1, compreendendo ainda gerar uma conexão de ponto a ponto entre o dispositivo de usuário e o servidor e realizar um protocolo de verificação "pull".

7. Método, de acordo com a reivindicação 6, compreendendo ainda solicitar a informação de upgrade de software a partir do servidor.

8. Método, de acordo com a reivindicação 7, compreendendo ainda receber uma resposta de servidor compreendendo a informação de versão de software.

9. Método, de acordo com a reivindicação 8, compreendendo ainda receber uma notificação de upgrade de software se um número de versão na resposta do servidor for maior do que um número de versão associado com o software armazenado no dispositivo de usuário.

10. Método, de acordo com a reivindicação 1, em que o protocolo de acesso é pelo menos um de um protocolo de acesso periódico, um protocolo de acesso iniciado por usuário, um protocolo de acesso baseado em transação, e um protocolo iniciado por lançamento.

11. Método, de acordo com a reivindicação 1, em que o protocolo de acesso compreende ainda uma abordagem baseada em token em que um valor de token de cliente é comparado com um valor de token de servidor que é periodicamente anunciado em um canal multicast.

12. Método, de acordo com a reivindicação 11, compreendendo ainda realizar um protocolo de verificação "pull", criar um token de cliente, e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não for válido.

13. Método, de acordo com a reivindicação 11, compreendendo ainda determinar se o valor de token de cliente é maior ou igual ao valor de token de servidor.

14. Método, de acordo com a reivindicação 13, compreendendo ainda confirmar se o dispositivo de cliente tem software atualizado se o valor de token de cliente for igual ou maior do que o valor de token de servidor.

15. Método, de acordo com a reivindicação 13, compreendendo ainda determinar se o valor de token de cliente está entre o valor de token de servidor menos m (módulo n) , onde um servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor de token de servidor -1 (módulo n) , onde η é um valor de token máximo, se o valor de token de cliente não for maior do que ou igual ao valor de token de servidor (módulo n).

16. Método, de acordo com a reivindicação 15, compreendendo ainda realizar um protocolo de verificação "push" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo n), e o valor de token de servidor -1 (módulo n).

17. Método, de acordo com a reivindicação 15, compreendendo ainda realizar um protocolo de verificação "pull" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo n), e o valor de token de servidor -1 (módulo n).

18. Método, de acordo com a reivindicação 1, compreendendo ainda prover a notificação de upgrade de software mediante realização de um protocolo de verificação "push" para um período de tempo predeterminado, seguido por um protocolo de verificação "pull".

19. Equipamento que facilita prover notificações de upgrade de software para dispositivos de usuário que se comunicam através de conexões multicast e unicast em um ambiente de comunicação sem fio, compreendendo: um receptor que recebe informação de versão de software; e um processador que realiza um protocolo de verificação e um protocolo de acesso para obter uma notificação de upgrade de software.

20. Equipamento, de acordo com a reivindicação -19, em que o processador emprega um protocolo baseado em token em que um token de cliente é comparado com um valor de token de servidor que é periodicamente anunciado em um canal multicast, e determina se o token de cliente é válido no dispositivo de usuário.

21. Equipamento, de acordo com a reivindicação -20, em que o processador executa um protocolo de verificação "pull", gera um token de cliente, e estabelece o valor de token de cliente igual a um valor de token de servidor recebido com a informação de versão de software, se o valor de token de cliente não for válido.

22. Equipamento, de acordo com a reivindicação -19, em que o processador determina se um valor de token de cliente é maior do que ou igual a um valor de token de servidor.

23. Equipamento, de acordo com a reivindicação -22, em que o processador determina se o valor de token de cliente está entre o valor de token de servidor menos m (módulo η) , onde um servidor transmite notificações de upgrade de software associados com m (números inteiros positivos) valores de token de servidor mais recentes, e o valor de token de servidor -1 (módulo η) , onde η é um valor de token máximo, se o valor de token de cliente não for maior do que ou igual ao valor de token de servidor (módulo n).

24. Equipamento, de acordo com a reivindicação -23, em que o processador executa um protocolo de verificação "push" e estabelece o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo n), e ο valor de token de servidor -1 (módulo n).

25. Equipamento, de acordo com a reivindicação 23, em que o processador executa um protocolo de verificação "pull" e estabelece o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo n) , e o valor de token de servidor -1 (módulo n).

26. Equipamento, de acordo com a reivindicação 19, compreendendo ainda prover a notificação de upgrade de software mediante realização de um protocolo de verificação "push" por um período de tempo predeterminado, seguido por um protocolo de verificação "pull".

27. Equipamento de comunicação sem fio, compreendendo: meio para receber informação de versão de software a partir de um servidor através de ambas, conexão multicast e uma conexão unicast; meio para realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um dispositivo de usuário; e meio para realizar um protocolo de acesso para receber uma notificação de upgrade de software.

28. Equipamento, de acordo com a reivindicação 27, em que o protocolo de acesso é pelo menos um de um protocolo de acesso periódico, um protocolo de acesso iniciado por usuário, um protocolo de acesso baseado em transação, e um protocolo iniciado por lançamento.

29. Equipamento, de acordo com a reivindicação 27, compreendendo ainda meio para empregar um protocolo de acesso baseado em token e determinar se um token de cliente é válido no dispositivo de usuário.

30. Equipamento, de acordo com a reivindicação - 29, compreendendo ainda meio para realizar um protocolo de verificação unicast, meio para criar um token de cliente, o meio para estabelecer o valor de token de cliente igual a um valor de token de servidor se o valor de cliente não estiver presente.

31. Equipamento, de acordo com a reivindicação 29, compreendendo ainda meio para determinar se um valor de token de cliente é maior do que ou igual a um valor de token de servidor, se o token de cliente for válido.

32. Equipamento, de acordo com a reivindicação 31, compreendendo ainda meio para determinar se o valor de token de cliente está entre o valor de token de servidor menos m (módulo η) , onde um servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor de token de servidor -1 (módulo η), onde η é um valor de token máximo, se o valor de token de cliente não for maior do que ou igual ao valor de token de servidor (módulon).

33. Equipamento, de acordo com a reivindicação 32, compreendendo ainda meio para realizar um protocolo de verificação multicast e meio para estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo η) , e o valor de token de servidor -1 (módulo n).

34. Equipamento, de acordo com a reivindicação 32, compreendendo ainda meio para realizar um protocolo de verificação unicast e meio para estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo η) , e o valor de token de servidor -1 (módulo n).

35. Equipamento, de acordo com a reivindicação -27, compreendendo ainda meio para prover a notificação de upgrade de software mediante emprego de meio para realizar um protocolo de verificação multicast para um periodo de tempo predeterminado, seguido por meio para executar um protocolo de verificação unicast.

36. Meio legivel por computador tendo um programa de computador compreendendo instruções executáveis por computador para: receber uma mensagem de overhead compreendendo uma informação de versão de software a partir de um servidor; realizar um protocolo de verificação para determinar se um upgrade de software estiver disponível para o dispositivo de usuário; e realizar um protocolo de acesso para receber uma notificação de upgrade de software.

37. Meio legível por computador, de acordo com a reivindicação 36, em que o protocolo de verificação é um protocolo de verificação "push" realizado através de uma conexão multicast entre um servidor e pelo menos um dispositivo de usuário.

38. Meio legível por computador, de acordo com a reivindicação 37, compreendendo ainda instruções para receber a informação de versão de software através de um canal de dados multicast, e determinar se um ID de software recebido com a informação de versão é relevante para o dispositivo de usuário.

39. Meio legível por computador, de acordo com a reivindicação 36, compreendendo ainda instruções para gerar uma conexão de ponto a ponto entre o dispositivo de usuário e o servidor e realizar um protocolo de verificação "pull", solicitando a informação de upgrade de software a partir do servidor, receber uma resposta de servidor compreendendo a informação de versão de software, e receber uma notificação de upgrade de software se um número de versão na resposta do servidor for maior do que um número de versão associado com software armazenado no dispositivo de usuário.

40. Meio legível por computador, de acordo com a reivindicação 36, em que o protocolo de acesso é pelo menos um de um protocolo de acesso periódico, um protocolo de acesso iniciado por usuário, um protocolo de acesso baseado em transação, e um protocolo iniciado por lançamento.

41. Meio legível por computador, de acordo com a reivindicação 36, compreendendo ainda instruções para empregar um protocolo de acesso baseado em token e determinar se um token de cliente é válido no dispositivo de usuário.

42. Meio legível por computador, de acordo com a reivindicação 41, compreendendo ainda instruções para realizar um protocolo de verificação "pull", criar um token de cliente, e estabelecer o valor de token de cliente igual a um valor de token de servidor se o valor de cliente não for válido.

43. Meio legível por computador, de acordo com a reivindicação 41, compreendendo ainda instruções para determinar se um valor de token de cliente é maior do que ou igual a um valor de token de servidor, se o token de cliente for válido.

44. Meio legível por computador, de acordo com a reivindicação 43, compreendendo ainda instruções para determinar se o valor de token de cliente está entre o valor de token de servidor menos m (módulo η) , onde um servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor de token de servidor - -1 (módulo η), onde η é um valor de token máximo, se o valor de token de cliente não for maior ou igual ao valor de token de servidor (módulo n).

45. Meio legível por computador, de acordo com a reivindicação 44, compreendendo ainda instruções para realizar um protocolo de verificação "push" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo η), e o valor de token de servidor -1 (módulo n).

46. Meio legível por computador, de acordo com a reivindicação 44, compreendendo ainda instruções para realizar um protocolo de verificação "pull" e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo η), e o valor de token de servidor -1 (módulo n).

47. Meio legível por computador, de acordo com a reivindicação 36, compreendendo ainda instruções para prover a notificação de upgrade de software mediante realização de um protocolo de verificação "push" para um período de tempo predeterminado, seguido por um protocolo de verificação "pull".

48. Processador que executa instruções para aumentar a capacidade de transmissão em um ambiente de comunicação sem fio, as instruções compreendendo: receber uma mensagem de overhead com informação de versão de software a partir de um servidor; realizar um protocolo de verificação para determinar se um upgrade de software está disponível para um. dispositivo de usuário; e realizar um protocolo de acesso para receber uma notificação de upgrade de software.

49. Processador, de acordo com a reivindicarão -48, em que protocolo de verificação é um protocolo de verificação multicast realizado através de um canal de multicast entre um servidor e pelo menos um dispositivo de usuário.

50. Processador, de acordo com a reivindicação -48, as instruções realizando adicionalmente um protocolo de verificação unicast através de uma conexão ponto a ponto, solicitando informação de versão de software a partir do servidor, recebendo uma resposta de servidor compreendendo a informação de versão de software, e recebendo uma notificação de upgrade de software se um número de versão na resposta do servidor for maior do que um número de versão associado com o software associado armazenado no dispositivo de usuário.

51. Processador, de acordo com a reivindicação -48, as instruções compreendendo ainda implementar um protocolo de acesso baseado em token e determinar se um token de cliente é válido no dispositivo de usuário.

52. Processador, de acordo com a reivindicação -51, as instruções compreendendo ainda realizar um protocolo de verificação unicast, criar um token de cliente, e estabelecer o valor de token de cliente igual a um valor de token de servidor, ser o valor de cliente não for válido.

53. Processador, de acordo com a reivindicação -51, as instruções compreendendo ainda determinar se um valor de token de cliente é maior ou igual a um valor de token de servidor, se o token de cliente for válido.

54. Processador, de acordo com a reivindicação -53, as instruções compreendendo ainda determinar se um valor de token de cliente está entre o valor de token de servidor menos m (módulo η) , onde um servidor transmite notificações de upgrade de software associadas com m (número inteiro positivo) valores de token de servidor mais recentes, e o valor de token de servidor -1 (módulo η) , onde η é um valor de token máximo, se o valor de token de cliente não for maior ou igual ao valor de token de servidor (módulo n).

55. Processo, de acordo com a reivindicação 54, as instruções compreendendo ainda realizar um protocolo de verificação multicast e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente estiver entre o valor de token de servidor menos m (módulo η), e o valor de token de servidor -1 (módulo n).

56. Processo, de acordo com a reivindicação 54, as instruções compreendendo ainda realizar um protocolo de verificação unicast e estabelecer o valor de token de cliente igual ao valor de token de servidor se o valor de token de cliente não estiver entre o valor de token de servidor menos m (módulo η), e o valor de token de servidor -1 (módulo n).

57. Processador, de acordo com a reivindicação 48, as instruções compreendendo ainda prover a notificação de upgrade de software mediante realização de um protocolo de verificação multicast para um período de tempo predeterminado, e permitir que o dispositivo de usuário inicie um protocolo de verificação unicast após ter se esgotado o período de tempo predeterminado.