BRPI0704532B1 - método e produto de programa de computador para adição de inteligência de processamento, envelope de conteúdo, e método, sistema e produto de programa de computador para o processamento de um envelope - Google Patents

Abstract

método envelopado de camada múltipla e sistema para push de conteúdo de metadados um método e um sistema para a adição de inteligência de processamento a uma carga útil de conteúdo em uma arquitetura de entrega de conteúdo dinâmico que tem pelo menos um primeiro elemento de processamento e um segundo elemento de processamento, o método tendo as etapas de:criação de um primeiro envelope, o primeiro envelope incluindo uma carga útil de conteúdo e os metadados de segundo elemento de processamento, os metadados de segundo elemento de processamento adaptados para serem rodados no segundo elemento de processamento; e a formação de um segundo envelope, o segundo envelope contendo o primeiro envelope e metadados de primeiro elemento de processamento adaptados para serem rodados no primeiro elemento de processamento.

Description

MÉTODO E PRODUTO DE PROGRAMA DE COMPUTADOR PARA ADIÇÃO DE INTELIGÊNCIA DE PROCESSAMENTO, ENVELOPE DE CONTEÚDO, E MÉTODO, SISTEMA E PRODUTO DE PROGRAMA DE COMPUTADOR PARA O PROCESSAMENTO DE UM ENVELOPE

Os presentes método e sistema se referem à entrega de conteúdo dinâmico em um ambiente móvel e, em particular, a uma arquitetura de entrega de conteúdo dinâmico genérico na qual aplicativos e provedores de conteúdo podem ser adicionados, sem mudança da arquitetura.

Os usuários de dispositivo móveis ou de equipamento de usuário (UE) móvel estão se tornando crescentemente mais sofisticados em termos da funcionalidade que eles requerem de seus dispositivos móveis e da forma em que acessam dados a partir dos dispositivos móveis.

A entrega de conteúdo dinâmico permite que os usuários tenham informação ou dados empurrados para eles, ao invés de terem de ir e buscar os dados. Os exemplos de dados poderiam incluir cotações de ações, atualizações do clima, atualizações de tráfego, papel de parede dinâmico, anúncios, aplicativos ou outros dados desejáveis para um usuário.

As tecnologias atuais para dispositivos móveis, tal como um protocolo de aplicativo sem fio (WAP), têm a capacidade de empurrar conteúdo; contudo, o WAP requer que websites sejam escritos para satisfazerem ao protocolo de aplicativo sem fio e provejam aos usuários um site uniforme que não mude para a acomodação das capacidades de um substrato de ver um site.

Outras alternativas incluem push baseado em SMS e difusão ou difusão celular. No caso de difusão, a entrega

Petição 870190065310, de 11/07/2019, pág. 6/104

2/63 não pode ser personalizada para as necessidades de um usuário em particular ou as capacidades de um dispositivo em particular. Estes sistemas, portanto, não têm uma inteligência associada a eles. Uma melhor solução é requerida para dispositivos móveis.

Os presentes sistema e método preferencialmente provêem uma arquitetura de entrega de conteúdo dinâmico e um sistema que permitem que aplicativos genéricos e provedores de conteúdo sejam adicionados ao sistema, sem a necessidade de modificação da arquitetura. Especificamente, os presentes sistema e método permitem que um dispositivo móvel se torne uma plataforma de aplicativo dinâmica, na qual os aplicativos podem ser adicionados e o conteúdo provido para o dispositivo móvel, onde a arquitetura do sistema de entrega de conteúdo dinâmico não limita o tipo de aplicativo que pode ser instalado no dispositivo nem o tipo de conteúdo que o dispositivo recebe.

Em um aspecto do presente pedido, metadados preferencialmente são providos e associados ao conteúdo, para se adicionar inteligência ao conteúdo para vários elementos de processamento na arquitetura de entrega de conteúdo dinâmico. Esta arquitetura inclui componentes lógicos que provêem provisão de conteúdo, provisão de serviço incluindo proxies de push, uma rede sem fio, um cliente de push e aplicativos de cliente.

Em um aspecto adicional do presente pedido, metadados preferencialmente são providos em um modelo envelopado em camadas para empurrar metadados de conteúdo. O conteúdo é envolvido com metadados, que podem ser usados para processamento em cada elemento em uma estrutura de

Petição 870190065310, de 11/07/2019, pág. 7/104

3/63 empurrar. Os metadados para cada elemento sucessivo são em camadas, desse modo se permitindo que o elemento de processamento extraia apenas os metadados para aquele elemento. Por exemplo, um pacote de conteúdo que inclui metadados dirigidos para um proxy de push e um aplicativo de cliente pode incluir o conteúdo com um primeiro nível de metadados para o aplicativo de cliente, e uma segunda camada de metadados para o proxy de push. Desse modo, quando o envelope atinge o proxy de push, os metadados para o proxy de push são extraídos e aplicados ao conteúdo, e o conteúdo modificado e os metadados para o aplicativo de cliente são passados para um elemento de processamento adicional. Em um outro aspecto do presente pedido, os metadados podem ser divididos em metadados estáticos (também referidos aqui como metadados de canal) e metadados dinâmicos (também referidos aqui como metadados de conteúdo). Os metadados estáticos são estabelecidos preferencialmente no momento de registro do aplicativo e do provedor de conteúdo. Contudo, os metadados de canal podem ser estabelecidos em um tempo posterior. O metadados de canal especifica regras de processamento que são específicas para o tipo de conteúdo que estiver sendo entregue e as exigências de aplicativo para o tipo de conteúdo.

Os metadados dinâmicos são inversamente associados ao conteúdo específico sendo passado.

Em um outro aspecto do presente pedido, um modelo de registro de plug-in é apresentado na estrutura de push. Um cliente de push genérico e um proxy de push são identificados, cada um tendo vários blocos de processamento

Petição 870190065310, de 11/07/2019, pág. 8/104

4/63 ou módulos que permitem que estes elementos processem conteúdo e metadados. Estes blocos podem ser dirigidos para processarem o conteúdo sendo passado, os metadados sendo passados ou ambos o conteúdo e os metadados sendo passados.

Um registro de plug-in ainda provê a passagem de manifestos de serviço e manifestos de aplicativo para se permitir o estabelecimento de metadados de canal entre um provedor de conteúdo e um aplicativo. Especificamente, os manifestos de serviço podem ser usados para o registro de um provedor de conteúdo junto à estrutura de push, e um manifesto de aplicativo pode ser usado para registro de um aplicativo junto à estrutura de push.

Em um outro aspecto do presente pedido, um método para empurrar conteúdo divulgado é provido preferencialmente, o qual permite a manipulação de dados com base em sua prioridade e com base em fatores de rede incluindo o custo para envio de dados, o tipo de rede conectada ou as preferências de usuário. Um modelo de push/pull misto opcional para conteúdo divulgado permite que um proxy de push empurre conteúdo, quando as condições de rede se tornarem favoráveis ou para um cliente puxar um conteúdo, quando as condições de rede se tornarem favoráveis ou quando o usuário requerer o conteúdo.

De modo a acomodar vários dispositivos móveis, um aspecto adicional do presente pedido provê uma fragmentação de conteúdo, incluindo uma fragmentação de conteúdo não linear. Uma fragmentação de conteúdo não linear inclui o aumento do conteúdo com metadados, permitindo que os dados sejam recompostos uma vez que tenham sido passados para o cliente.

Petição 870190065310, de 11/07/2019, pág. 9/104

5/63

Estes e outros aspectos serão identificados em maiores detalhes com respeito aos desenhos.

O presente pedido preferencialmente provê, portanto, um método para adição de inteligência de processamento para carga útil de conteúdo em uma arquitetura de entrega de conteúdo dinâmico tendo pelo menos um primeiro elemento de processamento e um segundo elemento de processamento, o método compreendendo as etapas de: criação de um primeiro envelope, o referido primeiro envelope incluindo uma carga útil de conteúdo e os metadados de segundo elemento de processamento, os referidos metadados de segundo elemento de processamento adaptados para serem rodados no referido segundo elemento de processamento; e a formação de um segundo envelope, o referido segundo envelope contendo o referido primeiro envelope e metadados de primeiro elemento de processamento adaptados para serem rodados no referido primeiro elemento de processamento.

O presente pedido ainda provê um envelope de conteúdo para uma arquitetura de entrega de conteúdo dinâmico, o envelope de conteúdo compreendendo: uma carga útil de conteúdo; metadados de conteúdo para um primeiro elemento de processamento na referida arquitetura de entrega de conteúdo dinâmico, os referidos metadados de processamento de conteúdo e a carga útil de conteúdo formando um primeiro envelope; e segundos metadados de conteúdo para um segundo elemento de processamento na arquitetura de entrega de conteúdo dinâmico, os segundos metadados de processamento de conteúdo sendo alojados com o referido primeiro envelope para a formação de um segundo envelope.

O presente pedido ainda provê um método de

Petição 870190065310, de 11/07/2019, pág. 10/104

6/63 processamento de um envelope que tem metadados para um elemento de processamento e metadados e conteúdo para elementos de processamento sucessivos em uma arquitetura de entrega de conteúdo dinâmico, o método compreendendo as etapas de: extração dos metadados para o elemento de processamento a partir do envelope; o uso dos metadados nos metadados e conteúdo para elementos de processamento sucessivos, desse modo se criando um envelope alojado processado; e a entrega do envelope alojado processado para um dos elementos de processamento sucessivos.

BREVE DESCRIÇÃO DOS DESENHOS

O presente pedido será mais bem compreendido com referência aos desenhos, nos quais:

a Figura 1 é um diagrama de blocos de uma arquitetura básica para um sistema de arquitetura de entrega de conteúdo dinâmico;

a Figura 2 é um diagrama de blocos que mostra arquiteturas alternativas do sistema de arquitetura de entrega de conteúdo dinâmico da Figura 1;

a Figura 3 é um diagrama de blocos da Figura 1 mostrando fluxo de conteúdo e metadados;

a Figura 4 é um diagrama de blocos que mostra um proxy de push que pode ser usado em associação com os presentes sistema e método;

a Figura 5 é um diagrama de blocos que mostra um cliente de push que pode ser usado em associação com os presentes sistema e método;

a Figura 6 é um diagrama de blocos que mostra um modelo de envelope de camada múltipla do conteúdo e dos metadados;

Petição 870190065310, de 11/07/2019, pág. 11/104

7/63 a Figura 7 é o diagrama de blocos da Figura 6 mostrando as etapas de processamento de metadados dinâmicos para cada envelope;

a Figura 8 é o diagrama de blocos da Figura 6, mostrando adicionalmente um processamento usando metadados estáticos e dinâmicos;

a Figura 9 é um diagrama de blocos mostrando um processo de registro para um aplicativo para um cliente de push compartilhado único;

a Figura 10 é um diagrama de blocos que mostra um processo de registro de um aplicativo para um contêiner de push gerenciando um grupo de clientes de push;

a Figura é um diagrama de blocos que mostra um aplicativo se registrando para um processador de conteúdo e um ouvinte de soquete;

é um diagrama de blocos que mostra um provedor de conteúdo se registrando com um proxy de push compartilhado único;

a Figura 13 é um diagrama de blocos que mostra um provedor de conteúdo se registrando com um contêiner de push gerenciando um grupo de proxies de push;

é um fluxograma que mostra mensagens de registro entre um provedor de conteúdo e um aplicativo de cliente;

a Figura um diagrama de blocos que mostra uma interação durante um registro entre um cliente de push e um proxy de push;

a Figura 16 um diagrama de blocos que mostra uma interação durante um registro entre um proxy de push e um provedor de conteúdo;

Petição 870190065310, de 11/07/2019, pág. 12/104

8/63 a Figura 17 é um fluxograma que mostra o fluxo de conteúdo e metadados entre um provedor de conteúdo e elementos de processamento;

a Figura 18 é um diagrama de blocos que mostra um aplicativo de transformação de exemplo para conteúdo;

a Figura 19 é um diagrama de blocos de um modelo de divulgação de conteúdo;

a Figura 20	é um	diagrama	de	blocos	de	um	processo	de
fragmentação linear;
a Figura 21	é um	diagrama	de	blocos	de	um	processo	de
fragmentação não	linear; e
a Figura 22	é um	diagrama	de	blocos	de	um	dispositivo

móvel de exemplo que poderia ser usado em associação com os presentes método e sistema.

DESCRIÇÃO DE MODALIDADES PREFERIDAS

Uma referência é feita, agora, à Figura 1. Um sistema de push genérico para entrega de conteúdo dinâmico a um aplicativo de cliente é ilustrado. Um sistema da Figura 1 é um sistema simplificado e mostra componentes lógicos que precisam estar em uma arquitetura de entrega de conteúdo dinâmico; contudo, alguém versado na técnica apreciará que outros componentes poderiam existir ou que vários componentes poderiam ser agrupados em conjunto.

A arquitetura 100 inclui um provedor de conteúdo 110. O provedor de conteúdo 110 é disposto para prover conteúdo dinâmico para usuários que tenham assinado o provedor de conteúdo 110. Os exemplos podem incluir, por exemplo, um website de venda de livros. Um usuário pode se registrar junto ao provedor de conteúdo 110 para obter uma lista de livros recém lançados com gêneros específicos. Outros

Petição 870190065310, de 11/07/2019, pág. 13/104

9/63 exemplos poderiam incluir novos sites os quais poderiam prover manchetes para usuários em uma base específica, sites de tráfego os quais poderiam prover uma informação de tráfego atualizada para usuários durante certos períodos do dia, sites de mercado de ações os quais poderiam prover cotações atualizadas de ações ou taxas de câmbio de moeda para usuários, dentre outros.

Conforme será descrito em maiores detalhes abaixo, o provedor de conteúdo 110 se registra junto a um provedor de serviços 120, de modo a permitir que os clientes de provedor de serviços recebam conteúdo do provedor de conteúdo 110. O provedor de serviços 120 inclui um proxy de push 122 que atua como um proxy para um cliente ou um aplicativo de cliente e provê um destino para o provedor de conteúdo 110 enviar o conteúdo.

O provedor de serviços 120 se comunica pela rede sem fio 130 com um cliente de push 140 que está localizado em um dispositivo móvel. O cliente de push 140 será descrito em maiores detalhes abaixo. O cliente de push 140 recebe o conteúdo que está sendo enviado a partir do provedor de conteúdo 110 e pode comunicar o conteúdo com um aplicativo de cliente 150, o qual, por último, consome o conteúdo.

No presente relatório descritivo, uma referência ao provedor de conteúdo 110, ao provedor de serviços 120, ao proxy de push 122, à rede sem fio 130, ao cliente de push 140 ou ao aplicativo de cliente 150 é uma referência de volta à arquitetura da Figura 1.

Com referência à Figura 2, será apreciado por aqueles versados na técnica que os componentes da Figura 1 são meramente componentes lógicos e não são necessariamente

Petição 870190065310, de 11/07/2019, pág. 14/104

10/63 componentes físicos separados. A Figura 1 ilustra uma arquitetura genérica na qual um provedor de conteúdo 110, um proxy de push 122, um cliente de push 140 e um aplicativo de cliente 150 existem. Alternativas são ilustradas na Figura 2.

Especificamente, uma primeira arquitetura alternativa 210 inclui múltiplos provedores de conteúdo 110 em comunicação com um proxy de push 122. O proxy de push 122 conforme na arquitetura da Figura 1 se comunica pela rede sem fio 130 com um cliente de push 140. Ainda, existem múltiplos aplicativos de cliente 150 na arquitetura 210. Portanto, este é um sistema N-1-1-N, que têm múltiplos provedores de conteúdo 110 e múltiplos aplicativos de cliente 150.

A arquitetura 220 da Figura 2 inclui um provedor de conteúdo 110 em comunicação com e registrado para o proxy de push 122. Ainda, o proxy de push 122 se comunica pela rede sem fio 130 com múltiplos clientes de push 140. Cada cliente de push 140 se comunica com um aplicativo de cliente 150. A arquitetura 220 agrupa, portanto, os componentes lógicos de um aplicativo de cliente 150 e de um cliente de push 140 e é um sistema N(1-1)-1-1.

A arquitetura 230 da Figura 2 tem múltiplos proxies de push 122, cada um em comunicação com um provedor de conteúdo 110. Cada combinação de proxy de push e de provedor de conteúdo 232 se comunica por uma rede sem fio 130 com um cliente de push genérico 140, o qual por sua vez se comunica com o aplicativo de cliente 150. Este é um sistema 1-1-N(1-1).

Na arquitetura 240 da Figura 2, um provedor de

Petição 870190065310, de 11/07/2019, pág. 15/104

11/63 conteúdo 110 e um agrupamento 232 d proxy de push 122 se comunicam pela rede sem fio 130 com uma combinação genérica de cliente de push 140 e aplicativo de cliente 150. Portanto, este é um sistema N(1-1)-N(1-1).

Conforme será apreciado por aqueles versados na técnica, outras alternativas são possíveis. O dito acima mostra vários componentes lógicos, os quais podem estar em componentes físicos separados ou agrupados em conjunto. Por exemplo, um cliente de push pode ser embutido em um aplicativo, clientes compartilhados comuns podem ser usados por múltiplos aplicativos ou outras alternativas.

Uma referência agora é feita à Figura 3. De modo a se adicionar inteligência a um sistema, o conteúdo está associado a um metadado. Um metadado, neste caso, é definido como dados que podem ser usados por um elemento de processador para manipulação do conteúdo. Conforme será apreciado, um sistema de push genérico requer metadados para se permitir que vários provedores de conteúdo e aplicativos existam no sistema. Os metadados podem ser em várias formas, incluindo parâmetros de processamento ou regras, ou um manipulador de processamento, código ou referência provido diretamente ou um enlace para um manipulador de processamento, código ou regras em uma outra localização.

Conforme pode ser visto na Figura 3, o conteúdo passa do provedor de conteúdo 110 para o aplicativo de cliente 150 e é ilustrado pela seta 310. O metadado, o qual provê instruções para vários componentes na arquitetura 100 também pode passar entre componentes dentro da arquitetura 100, usualmente juntamente com o conteúdo. Por exemplo, a

Petição 870190065310, de 11/07/2019, pág. 16/104

12/63 seta 320 ilustra um metadado que se origina no provedor de conteúdo e é transparente para o sistema de entrega, até atingir um aplicativo de cliente 150.

A seta 330 mostra um metadado criado pelo provedor de conteúdo 110, que é pretendido para o cliente de push 140 e, assim, apenas flui para o cliente de push genérico 140.

A seta 340 ilustra um metadado criado pelo provedor de serviços 120 e pretendido para o cliente de push 140 e, assim, é primeiramente associado ao conteúdo no proxy de push 122 e retirado do conteúdo no cliente de push genérico 140. Os exemplos de onde isto poderia ocorrer incluem acordos entre um usuário e um provedor de serviços com referência a um plano de tributação e ao nível de serviço a ser provido, onde o provedor de serviços pode usar os metadados para limitação dos serviços disponíveis ou prover serviços melhorados.

O fluxo de metadados e o papel de metadados são descritos em maiores detalhes abaixo.

Uma referência é feita, agora, à Figura 4. A Figura 4 ilustra um proxy de push de exemplo detalhado 410, o qual pode ser usado em associação com os presentes sistema e método. Conforme será apreciado por aqueles versados na técnica, o proxy de push 410 poderia ser o mesmo que o proxy de push 122 das Figuras 1 e 2.

O proxy de push 410 da Figura 4 inclui vários elementos que permitem que o proxy de push 410 opere em um ambiente de push genérico. Isto facilita a flexibilidade, uma vez que o proxy de push não está limitado a uma interação com provedores de conteúdo específicos ou clientes de push, mas, ao invés disso, pode ser adaptado a

Petição 870190065310, de 11/07/2019, pág. 17/104

13/63 um ambiente dinâmico. É preferível que os elementos descritos abaixo para o proxy de push 410 estejam dentro do proxy de push 410, mas os elementos não são exaustivos, e outros elementos são possíveis. Ainda, certos elementos podem ser omitidos do proxy de push 410, com os elementos remanescentes ainda capazes de realizarem serviços de push genéricos.

O proxy de push 410 inclui provedores de conteúdo 412 registrados para ele. Os provedores de conteúdo 412 se registram junto a uma interface de provedor de serviços de registro de provedor de conteúdo (SPI) 420. Conforme é descrito em maiores detalhes abaixo, é desejável neste registro que o provedor de conteúdo 412 inclui uma certa informação para o canal sendo estabelecido, referido aqui como metadado de canal. Os provedores de conteúdo 412 podem ser os mesmos que os provedores de conteúdo 110 da Figura 1.

O proxy de push 410 ainda inclui um bloco de administração de serviço 430 para administração do serviço de proxy de push.

O proxy de push 410 inclui vários módulos para lidar com o conteúdo e os metadados associados àquele conteúdo. Um primeiro módulo é o intermediário de mensagem e fila de entrega 440, o qual é um subsistema que consome mensagens a partir do provedor de conteúdo 412 e gerencia a fila de entrega de conteúdo. Conforme será apreciado por aqueles versados na técnica, nem todo conteúdo para todos os aplicativos de cliente pode ser entregue de uma vez, e uma fila de entrega precisa ser estabelecida, de modo a se entregar o conteúdo no curso devido. Por exemplo, um

Petição 870190065310, de 11/07/2019, pág. 18/104

14/63 dispositivo pode estar fora de cobertura e um conteúdo pode precisar ser armazenado.

O proxy de push 410 ainda inclui um bloco de gerenciamento de controle de fluxo 442. O bloco de gerenciamento de controle de fluxo 442 permite o controle do fluxo de conteúdo. Por exemplo, uma estação móvel com espaço limitado pode ser capaz apenas de receber uma certa quantidade de informação. Neste caso, o dispositivo móvel, através de um cliente de push 140, conforme ilustrado na Figura 1, pode pedir que o proxy de push 410 pare o fluxo de dados para o cliente de push 140. O bloco de gerenciamento de controle de fluxo 442 lida com isto.

Alternativamente, o dispositivo móvel pode estar offline. O bloco de gerenciamento de controle de fluxo 442 pára e começa o fluxo de dados para o cliente de push 140, quando um conteúdo não puder ser entregue conforme recebido pelo proxy de push 410.

Um componente adicional de proxy de push 410 é de agentes de push 444. Os agentes de push 444 são responsáveis pelo envio de dados para clientes.

Conforme será apreciado por aqueles versados na técnica, os blocos 440, 442 e 444 lidam com envio de mensagem apenas, e não estão relacionados a metadados. Em outras palavras, os blocos lidam com o conteúdo das mensagens, mas não com quaisquer metadados associados ao conteúdo.

Um componente adicional de proxy de push 410 é o bloco extrator de metadados de conteúdo e de cache 450. O bloco extrator de metadados de conteúdo e de cache 450 opera em metadados de conteúdo envelopados. Especificamente, no

Petição 870190065310, de 11/07/2019, pág. 19/104

15/63 modelo de envelope de sistema de metadados, o qual é descrito em maiores detalhes abaixo, cada componente lógico no sistema pode ter metadados associados ao processamento de conteúdo. Este metadado permite que o componente lógico realize ações no conteúdo. Cada componente lógico assim precisa ser capaz de extrair os metadados que estão associados a ele.

O bloco extrator de metadados de conteúdo e de cache

450 é responsável pela extração de metadados que estejam associados ao proxy de push 410 e para o armazenamento em cache destes metadados. A função de cache permite uma otimização pela eliminação da necessidade de passagem de metadados idênticos em envelopes de conteúdo subseqüentes a partir do mesmo provedor de conteúdo. A extração e o armazenamento em cache de metadados são descritos abaixo.

O bloco de armazenamento de mensagem de recuperação adiada 452 é usado quando não é efetivo enviar conteúdo ou partes dele para um aplicativo de cliente. O bloco de armazenamento de mensagem de recuperação adiada 452 pode ser usado para o armazenamento de um conteúdo que não seja enviado para o cliente até ser efetivo enviar o conteúdo, ou até o conteúdo ser puxado pelo cliente. O armazenamento de mensagem de recuperação adiada também poderia ser usado para o armazenamento em cache de um conteúdo auxiliar que poderia ser enviado opcionalmente ou puxado pelo cliente, dependendo da navegação de aplicativo de cliente através do conteúdo já enviado.

A finalidade do bloco de armazenamento de mensagem de recuperação adiada 452 é mais bem explicada abaixo, com referência às Figuras 19 e 21. A título de exemplo, o bloco

Petição 870190065310, de 11/07/2019, pág. 20/104

16/63 de armazenamento de mensagem de recuperação adiada 452 pode ser usado em um caso em que um usuário requisitou uma informação de localização, tal como um restaurante próximo da localização do usuário. O provedor de conteúdo ou o provedor de serviços pode ter um modelo de provisão de informação, onde os anunciantes podem pagar para adicionar sua informação para requisições de busca. Assim, o usuário que está requisitando uma informação de restaurante quanto a uma localização também pode ter uma informação sobre lojas, cursos de golfe, academias de ginástica ou outros serviços próximos de sua localização atendendo a sua requisição. Um provedor de conteúdo agrupa a informação de restaurante requisitada com a informação adicional e a passa para o proxy de push 410.

O proxy de push 410 pode criar, com base nos metadados providos, um pacote de conteúdo para enviar para o cliente. O pacote de conteúdo poderia incluir a informação requisitada pelo cliente, bem como um resumo ou sumário de uma informação relacionada em que o usuário pode estar interessado. O sumário é enviado para o usuário, mas o bloco de armazenamento de mensagem de recuperação adiada 452 armazena os dados reais que foram recebidos a partir do provedor de conteúdo 110. Assim, se no futuro o usuário desejar obter uma informação mais detalhada sobre uma informação no resumo, esta informação já estará armazenada no proxy de push 410.

Um uso alternativo para o bloco de armazenamento de mensagem de recuperação adiada 452 é o caso em que um usuário não pode aceitar o conteúdo inteiro de uma vez. Por exemplo, se não for praticável ou econômico enviar todo o

Petição 870190065310, de 11/07/2019, pág. 21/104

17/63 conteúdo para o dispositivo, parte do conteúdo pode ser armazenada até um momento posterior, quando ele pode ser puxado pelo cliente ou empurrado quando regras prédefinidas forem cumpridas. Estas regras podem ser especificadas pela rede ou pelas condições de serviço por certas condições de rede ou serviço serem satisfeitas. Isto é descrito em maiores detalhes com referência à Figura 19 abaixo.

O programador de push 454 programa intervalos de entrega para clientes. Conforme descrito acima, em algumas situações, pode não ser eficiente empurrar todo o conteúdo de uma vez. O bloco de armazenamento de mensagem de recuperação adiada 452 pode determinar que ele empurrará alguma informação imediatamente e o restante de acordo com uma programação pré-definida. Também, o programador de push 454 pode usar a natureza do conteúdo para determinar quando o conteúdo deve ser empurrado. Especificamente, metadados podem indicar que algum conteúdo é de alta prioridade ou tem uma expiração que é limitada no tempo, e este conteúdo pode ser empurrado imediatamente, ao passo que um conteúdo que tenha sido indicado como tendo uma prioridade baixa ou sem expiração pode ser empurrado mais tarde, quando as condições para a passagem de dados forem mais favoráveis.

Conforme será apreciado por aqueles versados na técnica, os blocos 450, 452 e 454 lidam com o conteúdo da mensagem em com os metadados que estão associados à mensagem.

O bloco de assinatura e regras 460 acompanha os aplicativos que estão registrados para receberem um serviço e monitora as regras sobre como lidar com um conteúdo em

Petição 870190065310, de 11/07/2019, pág. 22/104

18/63 particular sendo entregue. Um conteúdo tipicamente é entregue com base em uma assinatura pelo cliente ou em nome do cliente. O usuário, por exemplo, se ele desejar um serviço em particular, pode ativamente requisitar assinaturas. As assinaturas podem ser feitas em nome de um usuário, por exemplo, se o usuário tiver assinado um acordo com seu provedor de serviços 120 para receber um benefício pelo serviço. Isto poderia incluir o caso em que um usuário recebe uma taxa preferida, desde que o usuário concorde em receber um certo número de anúncios a cada dia. Neste caso, o provedor de serviços 120 pode fazer a assinatura para o provedor de anúncio em nome do cliente.

Quando um aplicativo é apagado em um dispositivo móvel ou quando o aplicativo sai do registro de uma assinatura, o bloco de assinatura e regras 460 pode remover a assinatura daquele usuário.

O bloco de dependências de conteúdo 462 é usado pelo proxy de push 410 para anunciar serviços que um usuário de dispositivo móvel pode utilizar. Assim, se um usuário de dispositivo móvel não tiver uma tela ou uma largura de banda ou memória suficiente para o serviço, o bloco de dependências de conteúdo 462 poderá bloquear o anúncio daquele serviço para o usuário.

O bloco de fragmentação de conteúdo 464 é usado para a fragmentação de conteúdo. Isto poderia ser usado, por exemplo, se o dispositivo móvel fosse incapaz de receber todo o conteúdo de uma vez. O bloco de fragmentação de conteúdo 464 é usado para dividir o conteúdo em vários componentes. Ele pode ser usado em associação com o bloco de armazenamento de mensagem de recuperação adiada 452 para

Petição 870190065310, de 11/07/2019, pág. 23/104

19/63 o armazenamento do conteúdo fragmentado que ainda não foi enviado.

O bloco de expiração de conteúdo e substituição 466 é usado para duas finalidades. Em primeiro lugar, este bloco pode ser usado para a monitoração de assinaturas. Cada assinatura tem um tempo de expiração e, quando este tempo de expiração for encontrado, a assinatura poderá ser terminada.

Também, o bloco de expiração de conteúdo e substituição 466 pode ser usado para a monitoração de uma informação. Certo conteúdo terá limites de tempo quanto à validade da informação. Por exemplo, um aplicativo de tráfego usado para a monitoração do tráfego na hora do rush será muito dependente do tempo. Se, por alguma razão, o proxy de push 410 for incapaz de enviar o conteúdo imediatamente para um dispositivo móvel, este conteúdo poderá ser armazenado no armazenamento de conteúdo 480 para entrega futura. Contudo, se o conteúdo não tiver sido enviado em um certo período de tempo especificado, então, ele poderia expirar e não ser entregue de forma alguma.

De modo similar, uma substituição de conteúdo lida com uma situação em que a informação está sendo atualizada. Por exemplo, um aplicativo de cliente que esteja recebendo cotações de ações pode querer apenas a última cotação de ação. Assim, se o proxy de push 410 for incapaz de entregar a cotação de ação para o cliente de push 140 e uma cotação de ação subseqüente for recebida a partir de um provedor de conteúdo 110, metadados na cotação de ação subseqüente podem indicar que ela deve ser usada para substituição da cotação de ação prévia. Uma substituição de informação

Petição 870190065310, de 11/07/2019, pág. 24/104

20/63 armazenada ao invés de adicionar toda a informação a uma fila de entrega livra espaço no armazenamento de conteúdo 480 .

Um depósito de metadados de canal 470 é usado para o armazenamento de metadados de canal, o que é descrito em maiores detalhes abaixo.

O dito acima descreve um proxy de push de exemplo 410 que pode ser usado com o método e os sistemas aqui. Os blocos e os elementos de proxy de push 410 permitem que o proxy de push 410 seja usado em um sistema de entrega de conteúdo dinâmico, onde o tipo de conteúdo e a manipulação do conteúdo em um aplicativo podem variar e não são predeterminados.

Uma referência é feita, agora, à Figura 5. A Figura 5 ilustra um cliente de push 510 que pode ser usado em associação com o sistema e os métodos aqui. O cliente de push 510 pode ser o mesmo que o cliente de push 140 das Figuras 1 e 2.

Conforme será apreciado por aqueles versados na técnica, um cliente de push 510 que é para ser usado em um sistema genérico, no qual o conteúdo e o processamento do conteúdo não são predeterminados, deve incluir blocos ou módulos que possam ser usados para a acomodação do conteúdo e dos metadados associados ao conteúdo. Os blocos definidos com respeito à Figura 5 não têm por significado serem exaustivos, e outros blocos também poderiam existir em um cliente de push 510. Ainda, os blocos no cliente de push 510 podem ser omitidos, em alguns casos, sem restrição da funcionalidade dos outros blocos no cliente de push 510.

Um cliente de push 510 serve aplicativos, e um ou mais

Petição 870190065310, de 11/07/2019, pág. 25/104

21/63 aplicativos 512 podem se registrar junto ao cliente de push 510. O registro de aplicativo usa uma interface de provedor de aplicativo 514 como a interface para registro e a interface de provedor de aplicativo 514 ainda pode ser usada para a extração de metadados de canal para o aplicativo, conforme descrito em maiores detalhes abaixo.

O cliente de push 510 inclui uma administração de cliente 520 usada para a administração do cliente de push 510.

Como com o proxy de push 410 da Figura 4, o cliente de push 510 inclui vários blocos que lidam com envio de mensagem, vários blocos que lidam com metadados e vários blocos que lidam com envio de mensagem e metadados.

As filas de intermediário de mensagem e aplicativo 540 lidam com mensagens a partir do proxy de push 410 para a entrega para aplicativos 512. Uma fila de aplicativo é uma fila de mensagens para os aplicativos 512.

O bloco de gerenciamento de controle de fluxo 542 é usado para notificar ao proxy de push 410 da Figura 4 para parar de empurrar o conteúdo ou para retomar o push do conteúdo. Isto pode ser usado, por exemplo, quando o cliente de push 510 tiver uma quantidade limitada de memória que pode aceitar um conteúdo empurrado. Neste caso, antes de o conteúdo de push ser consumido, o cliente de push 510 precisa parar o fluxo de conteúdo a partir do proxy de push 410. Uma vez que o conteúdo tenha sido consumido, o bloco de gerenciamento de controle de fluxo 542 pode ser usado para se começar o fluxo de dados de novo.

Os agentes de push 544 no cliente de push 510 são

Petição 870190065310, de 11/07/2019, pág. 26/104

22/63 usados para o recebimento de uma informação a partir do proxy de push 410 da Figura 4.

Conforme será apreciado por aqueles versados na técnica, os intermediários de mensagem e filas de aplicativo 540, o bloco de gerenciamento de controle de fluxo 542, e os agentes de push 544 lidam exclusivamente com envio de mensagem e não com metadados.

O bloco extrator de metadados de conteúdo e de cache 550 é usado para a extração de metadados dinâmicos destinados para o cliente de push 510. Conforme indicado acima com referência ao proxy de push 410 da Figura 4, quaisquer elementos de processamento na arquitetura de entrega de conteúdo dinâmico poderiam ter metadados destinados para eles e estes metadados precisam ser extraídos. Assim, metadados destinados para o cliente de push 510 são extraídos pelo bloco extrator de metadados de conteúdo e de cache 550.

Ainda, o bloco extrator de metadados de conteúdo e de cache 550 preferencialmente é adaptado para o armazenamento em cache de metadados. Os metadados para o cliente de push 510 que não mudam entre um primeiro pacote de conteúdo e um segundo pacote de conteúdo não precisam ser passados, poupando-se tempo de processamento no cliente de push 510 ao não se requerer a extração destes metadados, e ainda se poupando recursos de rede ao não se requerer que os metadados para o cliente de push 510 sejam passados pela rede sem fio 130.

O gerenciador de recuperação adiada 552 é usado para a análise de fragmentos de conteúdo que são recebidos e para a colocação em conjunto do conteúdo da forma correta.

Petição 870190065310, de 11/07/2019, pág. 27/104

23/63

Conforme descrito em maiores detalhes abaixo, os dados podem ser lineares ou não lineares. Se os dados forem não lineares, então, metadados são requeridos, de modo a se reconstituí-los, e isto é feito pelo gerenciador de recuperação adiada 552. O gerenciador de recuperação adiada 552 também é adaptado para analisar um resumo de informação disponível no armazenamento de recuperação adiada 452 de cliente de push 510 e comanda o intermediário de pull de conteúdo 554 (descrito abaixo) para recuperar esta informação, quando requerido pelo usuário. Isto inclui uma recuperação preditiva, quando uma navegação de conteúdo entrar em uma certa ramificação do gráfico de estrutura de conteúdo ou quando condições de largura de banda ou de custo forem satisfeitas.

O intermediário de pull de conteúdo 554 é usado em um modelo de push / pull, quando o cliente de push 510 for capaz de puxar conteúdo em certas situações. Essas situações são descritas abaixo em maiores detalhes com referência à Figura 19.

Conforme será apreciado por aqueles versados na técnica, o extrator de metadados de conteúdo e de cache 550, o gerenciador de recuperação adiada 552 e o intermediário de pull de conteúdo 554 lidam com envio de mensagem de conteúdo e com metadados.

O bloco de gerenciamento de assinatura 560 é o mesmo que o bloco de assinatura e regras 460 da Figura 4. Especificamente, o bloco de gerenciamento de assinatura 560 é usado para o gerenciamento de assinaturas. Se um aplicativo sair de registro ou for apagado de um dispositivo móvel, então, o bloco de gerenciamento de

Petição 870190065310, de 11/07/2019, pág. 28/104

24/63 assinatura 560 terminará a assinatura. O bloco de gerenciamento de assinatura 560 também pode refazer a assinatura em nome de um aplicativo de cliente quando um canal de assinatura expirar.

O bloco de notificação de atualização 562 trabalha com aplicativos de cliente e é usado para notificação aos aplicativos que um novo conteúdo está esperando por eles. Isto pode ser feito em uma de três formas:

a. Uma primeira forma pela qual o bloco de notificação de atualização 562 pode notificar um aplicativo 512 é que o cliente de push 510 envie o conteúdo para o aplicativo 512 diretamente.

b. Uma segunda forma pela qual o bloco de notificação de atualização 562 pode notificar aplicativos 512 de um novo conteúdo é armazenar o conteúdo no armazenamento de conteúdo 580 e opcionalmente notificar os aplicativos 512 que o conteúdo está esperando. Uma notificação neste caso é opcional. Especificamente, se um aplicativo 512 souber que uma informação destinada a ele está armazenada em um bloco de memória específico, uma opção para o aplicativo descobrindo que tem novos dados é periodicamente interrogar a localização de memória para ver se alguma coisa foi escrita para ele. Alternativamente, o bloco de notificação de atualização 562 pode enviar uma mensagem para o aplicativo 512, indicando que ele tem novos dados e possivelmente a localização em que aqueles dados estão armazenados.

c. Uma terceira forma pela qual o bloco de notificação de atualização 562 pode notificar os aplicativos 512 de um novo conteúdo é armazenar o conteúdo internamente e

Petição 870190065310, de 11/07/2019, pág. 29/104

25/63 notificar o aplicativo. O aplicativo então pode chamar o cliente de push para recuperar o conteúdo.

O bloco de dependência de conteúdo 564 é o mesmo que o bloco de dependência de conteúdo 462 da Figura 4, e pode determinar se é para anunciar o serviço para o dispositivo móvel.

O bloco de expiração de conteúdo e substituição 566 é o mesmo que o bloco de expiração de conteúdo e substituição 466 da Figura 4. A expiração de conteúdo e a substituição de conteúdo assim podem ser manipuladas no cliente de push 510, além de no servidor de push ou no proxy de push.

Um depósito de metadados de canal 570 é usado para o armazenamento de metadados de canal para o aplicativo 512.

O módulo de processamento de atualização de fundo 575 é usado para a realização de atualizações quando um aplicativo 512 está indisponível. A atualização de fundo permite, por exemplo, a substituição de dados por dados mais novos dentro do armazenamento de aplicativo. Após isso, quando um usuário começa o aplicativo, os dados exibidos pelo aplicativo estão corretos e atualizados.

O módulo de processamento de atualização de fundo 575 usa regras de processamento que traduzem o conteúdo em um formato aceitável para um aplicativo. Ele pode executar e processar o conteúdo no armazenamento de conteúdo 580.

A título de exemplo, uma lista de tarefas é atualizada para que um empreiteiro durante a noite pudesse ter tarefas empurradas para ele. O aplicativo de tarefa não é começado durante este tempo, e o módulo de processamento de atualização de fundo 575 pode ser usado para a atualização do conteúdo para o aplicativo de tarefa. Isto poderia ser

Petição 870190065310, de 11/07/2019, pág. 30/104

26/63 feito com um código para manipulação de um arquivo de linguagem de marcação extensível (XML), e poderia existir no dispositivo em um arquivo denominado handler.exe. O módulo de processamento de atualização de fundo 575 no cliente de push 510 pode rodar o handler.exe, passando o documento XML que tem um parâmetro. O manipulador então constrói a tarefa no formato interno do aplicativo.

Uma vez que o módulo de processamento de atualização de fundo 575 do cliente de push 510 construa a tarefa no formato interno de aplicativo, ele então pode ler a tarefa na lista de tarefas a partir do armazenamento de conteúdo 580 e anexar a nova tarefa à lista. Ele então pode armazenar o fundo modificado no armazenamento de conteúdo 580 para quando o aplicativo de tarefa em seguida se conectar ao cliente de push 510.

Portanto, a Figura 5 ilustra um cliente de push 510 que pode ser usado em um sistema de entrega de conteúdo dinâmico genérico, onde o conteúdo e o processamento do conteúdo são dinâmicos e não predeterminados. Os blocos descritos acima com referência ao cliente de push 510 da Figura 5 são usados para a acomodação da natureza dinâmica do sistema.

Conforme indicado acima com referência à Figura 3, um conteúdo está associado a metadados para a provisão de inteligência para o processamento do conteúdo. De acordo com os presentes método e sistema, os metadados podem ser divididos em dois tipos de metadados. Especificamente, metadados estáticos (de canal) e metadados dinâmicos (de conteúdo).

Devido às possibilidades ilimitadas de tipos de

Petição 870190065310, de 11/07/2019, pág. 31/104

27/63 provedores de conteúdo e aplicativos, os metadados são críticos de modo a se construírem sistemas genéricos. A única forma de se lidar com o tipo específico de conteúdo é através de metadados.

Os metadados estáticos são metadados que provêem regras sobre como processar tipos específicos de conteúdo. Os metadados estáticos podem ser divididos em vários níveis de abstração e incluem, por exemplo, uma informação estrutural sobre o conteúdo em si. Por exemplo, um documento de Divulgação Simples em Tempo Real (RSS) poderia ser entregue com uma estrutura RSS 2.0.XSD, e todo o conteúdo a partir daquele provedor de conteúdo seria entregue com esta estrutura.

Um nível adicional de abstração para metadados estáticos inclui a provisão de regras de processamento para subtipo de conteúdo. Isto poderia ser específico de aplicativo. Assim, por exemplo, um aplicativo de notícias financeiras indica que dados devem ser extraídos a partir de um fluxo de RSS de notícias financeiras, armazenado em uma localização pré-definida, e que o aplicativo deve ser notificado sobre a chegada da informação. O aplicativo sempre requer que um conteúdo destinado a ele seja manipulado desta forma.

Os metadados estáticos (também referidos aqui como metadados de canal) ficam os mesmos por toda a assinatura entre o aplicativo e o provedor de conteúdo, e, assim, os metadados estáticos podem ser estabelecidos uma vez para cada elemento na arquitetura e para cada canal de entrega de conteúdo. Em uma modalidade, isto é feito no momento do registro do aplicativo ou do provedor de conteúdo.

Petição 870190065310, de 11/07/2019, pág. 32/104

28/63

Os metadados dinâmicos são metadados que estão associados a um pedaço em particular de conteúdo. Por exemplo, uma informação de expiração associada a um pedaço em particular de dados ou regras de substituição e informação associada a um pedaço em particular de dados (isto é, o documento K substitui o documento L).

Conforme indicado acima com referência às Figuras 4 e 5, cada entidade de processamento pode receber metadados estáticos e dinâmicos que são dirigidos para aquela entidade de processamento. Assim, o proxy de push 410 usa o bloco extrator de metadados de conteúdo e de cache 450 para a extração dos metadados estáticos, e o módulo de expiração de conteúdo e substituição 466 é usado para a substituição de conteúdo não entregue por um conteúdo mais novo recebido no proxy de push 410.

Uma referência é feita agora à Figura 6. A Figura 6 ilustra um modelo de envelope de camada múltipla para metadados de conteúdo.

Um proxy de push 410 recebe um envelope de push 610 que inclui metadados de processamento de conteúdo para o servidor de proxy 612 e um envelope de cliente de push 614. O proxy de push 410 extrai os metadados de processamento de conteúdo 612 e usa estes metadados para o processamento do envelope de cliente de push 614. Os metadados 612 ditam o proxy de push o que fazer com o envelope de cliente de push 614.

O envelope de cliente de push 614 é passado para o cliente de push 510, onde ele é dividido em um envelope de conteúdo 620 e um metadado de processamento de conteúdo 622. O metadado de processamento de conteúdo 622 é usado

Petição 870190065310, de 11/07/2019, pág. 33/104

29/63 pelo cliente de push 510 para processar o envelope de conteúdo 620. Por exemplo, isto pode ser usado para se instruir o cliente de push 510 para realizar uma substituição de um envelope de conteúdo 620 previamente entregue pelo último envelope, se o aplicativo de cliente 150 estiver interessado apenas na última versão do conteúdo.

O envelope de conteúdo 620 é passado para o aplicativo de cliente 150. O envelope de conteúdo 620 inclui metadados de processamento de conteúdo 630 para o aplicativo e a carga útil de conteúdo 632 que é para ser consumida pelo aplicativo de cliente 150.

Conforme será apreciado por aqueles versados na técnica, o alojamento de envelopes de acordo com a Figura 6 provê um ambiente dinâmico rico no qual um processamento pode ocorrer em qualquer elemento de processamento da arquitetura e com o qual o provedor de conteúdo 110 pode especificar como um conteúdo específico é para ser lidado. Em uma modalidade, os metadados dirigidos para um elemento lógico em particular são opacos para outros elementos de processamento.

Alternativamente, o provedor de serviços 120 também pode adicionar metadados no proxy de push 410 para processamento no cliente de push 510 ou no aplicativo de cliente 150.

Com referência à Figura 7, esta figura mostra o modelo de envelope da Figura 6 e as etapas que aquele elemento de processamento faz com um envelope. Conforme ilustrado na Figura 7, o proxy de push 410 primeiramente extrai os metadados a partir do envelope de push 610. Isto é feito na

Petição 870190065310, de 11/07/2019, pág. 34/104

30/63 etapa 710.

Na etapa 712, o proxy de push 410 usa os metadados para o processamento do envelope de cliente de push 614. Na etapa 714, o proxy de push 410 envia o envelope de cliente de push 614 para o cliente de push 510.

De modo similar, o cliente de push 510 na etapa 720 extrai o metadado de processamento de conteúdo 622 a partir do envelope de cliente de push 614. Na etapa 722, o cliente de push 510 usa o metadado de processamento de conteúdo 622

no envelope de conteúdo 620. Na	etapa 724,	o cliente	de
push 510 entrega o	envelope	de	conteúdo	620 para	o
aplicativo de cliente	150.
Na etapa 730, o	aplicativo	de	cliente	150 extrai	o

metadado de processamento de conteúdo 630 e, na etapa 732, usa o metadado de processamento de conteúdo 630 na carga útil de conteúdo 632.

Com referência à Figura 8, esta figura mostra o método, conforme ilustrado na Figura 7, com a etapa adicional do uso de metadados estáticos ou de canal. Especificamente, após os metadados terem sido extraídos na etapa 710 a partir do envelope de push 610, o proxy de push 410 em seguida usa os metadados de canal estáticos para processamento do envelope de cliente de push na etapa 810. Na etapa 712, o proxy de push 410 em seguida processa os metadados dinâmicos de processamento de conteúdo 612. O proxy de push 410 em seguida entrega o envelope de cliente de push 614 na etapa 714.

De modo similar, o cliente de push 510 extrai o metadado de processamento de conteúdo 622 na etapa 720. O cliente de push 510 então usa os metadados de canal na

Petição 870190065310, de 11/07/2019, pág. 35/104

31/63 etapa 820 no conteúdo com o envelope de conteúdo 620. O cliente de push 510, então, na etapa 722, usa os metadados de conteúdo dinâmico no metadado de processamento de conteúdo 622, antes da entrega do envelope de conteúdo 620 para o aplicativo de cliente 150 na etapa 724.

O aplicativo de cliente 150 primeiramente extrai, na etapa 730, o metadado de processamento de conteúdo 630. Ele então usa os metadados de canal na etapa 830 na carga útil de conteúdo 632. O aplicativo de cliente 150 então usa, na etapa 732, o metadado de processamento de conteúdo 630 na carga útil de conteúdo 632.

Conforme será apreciado por aqueles versados na técnica, o modelo acima, portanto, permite que metadados estáticos sejam aplicados ao canal juntamente com metadados dinâmicos que estão associados ao conteúdo em particular sendo enviado.

Uma referência é feita, agora, à Figura 9. Conforme será apreciado a partir da Figura 5, o cliente de push 510 pode servir a múltiplos aplicativos alvos 512 em um dispositivo móvel. Um mecanismo de registro de tempo de rodada eficiente é requerido, onde aplicativos podem se registrar junto à estrutura de entrega de conteúdo dinâmico sem interrupção do serviço para outros aplicativos.

Com referência à Figura 9, o cliente de push 510 inclui três aplicativos, especificamente, os aplicativos 910, 912 e 914 que já estão registrados junto ao cliente de push. Conforme será apreciado, o modelo de plug-in é importante, porque novos dispositivos podem permitir que tipos ilimitados de aplicativo sejam instalados no dispositivo. Ainda, os aplicativos podem ser instalados

Petição 870190065310, de 11/07/2019, pág. 36/104

32/63 dinamicamente, levando a um dispositivo móvel se tornar uma plataforma de aplicativo. Devido ao fato de o dispositivo poder ser uma plataforma de aplicativo, ele deve ser capaz de incorporar dinamicamente novos aplicativos.

Conforme visto na Figura 9, o aplicativo 916 quer se registrar junto ao cliente de push 510. O aplicativo 916 inclui um manifesto de aplicativo 918 que, em uma modalidade preferida, provê os metadados de canal para o aplicativo. Especificamente, o manifesto de aplicativo 918 provê uma informação para o cliente de push 510 e, finalmente, o proxy de push 410 e o provedor de conteúdo 110 a partir da Figura 1 com metadados estáticos para o aplicativo. Isto pode incluir, mas não está limitado a que tipo de conteúdo o aplicativo espera, como o conteúdo será entregue, se o aplicativo precisa de uma notificação, ou uma outra informação de canal que seria evidente para aqueles versados na técnica tendo consideração quanto aos presentes sistema e método.

Portanto, o aplicativo 916 se registra junto ao cliente de push 510 provendo um manifesto de aplicativo 918 para o estabelecimento de um canal para um provedor de conteúdo para servir o aplicativo 916.

Com referência à Figura 10, um modelo alternativo poderia ser o modelo descrito com respeito à arquitetura 220 da Figura 2. Especificamente, no modelo da Figura 10, um aplicativo de cliente 150 é emparelhado com um cliente de push 140. Cada um dos pares de aplicativo de cliente 150 / cliente de push 140 é coordenado com um contêiner de push 1010.

Quando o aplicativo 1020 deseja se registrar junto ao

Petição 870190065310, de 11/07/2019, pág. 37/104

33/63 contêiner de push 1010, um cliente 140 é criado ou, se ele já existir, é usado pelo contêiner de push 1010. Ainda, no registro, o aplicativo 1020 provê um manifesto de aplicativo 1030 para o contêiner de push 1010, desse modo provendo metadados de canal (metadados estáticos) para o aplicativo 1020.

Uma ilustração alternativa da Figura 10 é mostrada na Figura 11. Especificamente, um contêiner de push 1110 gerencia / mantém um grupo de clientes de push. Quando um aplicativo se registra junto ao contêiner, ele obtém um cliente de push dedicado 510, o qual, no caso simples, poderia ser representado por um par de um ouvinte de soquete 1130 e um manipulador de conteúdo. O cliente de push é retornado para o grupo, quando o aplicativo sai de registro junto ao contêiner (e serviço de entrega de conteúdo) ou é apagado do dispositivo.

O contêiner de push 1110 inclui soquetes 1120 para comunicação. Ainda, o contêiner de push 1110 inclui ouvintes de soquete 1130 e processadores de conteúdo 1140 atribuídos a um soquete em particular.

Conforme visto na Figura 11, vários pares de processador de conteúdo e ouvinte de soquete são usados pelos aplicativos previamente registrados 150.

Quando um novo aplicativo 1150 deseja se registrar junto ao contêiner de push 1110, um novo processador de conteúdo e ouvinte de soquete 1120 e 1130 são atribuídos ao aplicativo de serviço 1050.

Portanto, o dito acima provê uma estrutura de push genérica, na qual um aplicativo de cliente 150 que é novo pode ser implementado e registrado junto a um cliente de

Petição 870190065310, de 11/07/2019, pág. 38/104

34/63 push 510 ou um contêiner de push 1010 ou 1110, desse modo se permitindo que o dispositivo se torne uma plataforma de aplicativo capaz de incorporar dinamicamente novos aplicativos. A passagem de um manifesto de aplicativo 1030 ou 918 a partir das Figuras 9 e 10 acima permite o estabelecimento de metadados de canal, desse modo se permitindo que o conteúdo seja processado de acordo com as exigências de aplicativo.

Com referência à Figura 12, os provedores de conteúdo 110 de modo similar precisam se registrar junto a um proxy de push 410. Conforme visto na Figura 12, o proxy de push 410 inclui três provedores de conteúdo, especificamente, 1210, 1212 e 1214, já registrados junto ao proxy de push 410. O provedor de conteúdo 1216 deseja se registrar junto ao proxy de push 410.

De modo similar ao manifesto de aplicativo 918 ilustrado na Figura 9 provido por um aplicativo 916 quando se registrando junto ao cliente de push 510, o provedor de conteúdo 1216 inclui um manifesto de aplicativo 1218 que é passado para o proxy de push 410, quando o provedor de conteúdo 1216 se registrar. O manifesto de aplicativo 1218 inclui uma informação concernente ao tipo de informação que o provedor de conteúdo proverá, quão freqüentemente ele proverá esta informação, o formato da informação e qualquer outra informação que seja útil para o serviço ou para o anúncio do serviço. Uma outra informação é possível.

O proxy de push 410 assim usa o manifesto de aplicativo 1218 para o estabelecimento de metadados de canal (estáticos) para o provedor de conteúdo 1216.

Com referência à Figura 13, uma modalidade

Petição 870190065310, de 11/07/2019, pág. 39/104

35/63 alternativa, representada pela arquitetura 230 da Figura 2, é ter um contêiner de push com vários emparelhamentos de proxy de push 122 e provedor de conteúdo 110. Como com a Figura 12, vários aplicativos poderiam já estar registrados junto ao contêiner de push 1310 e, no exemplo da Figura 12, os aplicativos 1312, 1314 e 1316 já estão registrados com os proxies de push 1313, 1315 e 1317, respectivamente.

Um novo aplicativo 1320 quer se registrar junto ao contêiner de push 1310. Assim, o contêiner de push 1310 cria um novo proxy (não mostrado), ou usa um proxy existente (não mostrado) com o qual ele associa o provedor de conteúdo 1320. Ainda, o provedor de conteúdo 1320 provê um manifesto de serviço 1322 para a descrição do conteúdo que o provedor de conteúdo 1320 estará provendo, desse modo se permitindo o estabelecimento de metadados de canal.

Conforme será apreciado por aqueles versados na técnica, as modalidades das Figuras 9 e 10 mostram duas opções para os clientes de push, com aplicativos compartilhados ou com clientes de push dedicados por aplicativo. Alguém versado na técnica perceberá que outras modalidades são possíveis. De modo similar, com respeito às Figuras 12 e 13, um proxy de push com múltiplos provedores de conteúdo registrados para ele é mostrado ou um proxy de push dedicado para cada provedor de conteúdo, e concretizado em um contêiner de push é mostrado.

Com referência à Figura 14, um envio de mensagem entre um provedor de conteúdo 110 e um aplicativo de cliente 150 é mostrado. O provedor de conteúdo 110 provê uma mensagem de registro para o proxy de push 410. Esta mensagem pode incluir o manifesto de serviço, o qual pode ser usado para

Petição 870190065310, de 11/07/2019, pág. 40/104

36/63 a provisão de metadados de canal para o proxy de push 410. Isto é feito na etapa 1410.

O provedor de conteúdo 110 também, ou alternativamente, pode prover metadados de canal em uma mensagem subseqüente, conforme ilustrado pela etapa 1412.

O proxy de push 410 então adiciona um serviço a uma lista de serviços disponíveis (o catálogo de serviços) na etapa 1414.

Uma etapa opcional no exemplo da Figura 14 é para o proxy de push 410 notificar o cliente de push 510 do novo serviço disponível na etapa 1416, e esta notificação pode ser propagada para um provedor de conteúdo 110 na etapa 1418 .

Conforme será apreciado por aqueles versados na técnica, as etapas 1416 e 1418 são opcionais, e outras alternativas incluem o aplicativo de cliente 150 puxar o catálogo de serviço periodicamente a partir do proxy de push 410 para ver novos serviços.

Quando um usuário ou um provedor de serviços para aplicativo de cliente 150 decide que o aplicativo de cliente 150 deve assinar um serviço, ele envia uma mensagem de assinatura na etapa 1420. A mensagem de assinatura é adicionalmente passada para o proxy de push 410 na etapa 1422.

Uma vez que o proxy de push 410 receba a mensagem de assinatura na etapa 1422, duas opções estão disponíveis. Uma primeira opção é enviar uma mensagem 1424 para o provedor de conteúdo 110 para uma assinatura e, então, receber um envelope de mensagem que inclui metadados de volta na etapa 1426. Os metadados poderiam ser específicos

Petição 870190065310, de 11/07/2019, pág. 41/104

37/63 de um dispositivo ou de um tipo de dispositivo.

Alternativamente, o proxy de push 410 pode receber a mensagem de assinatura na etapa 1422 e imediatamente, com base em uma informação já provida pelo provedor de conteúdo 110 e armazenada no proxy de push 410, responder na etapa 1430 ao cliente de push 510. Esta resposta é propagada para o aplicativo de cliente 150 na etapa 1532. Conforme será apreciado, a resposta pode incluir metadados de canal específicos para o provedor de conteúdo 110.

A diferença nos modelos pode ser dependente de quem está personalizando os dados para o aplicativo. Conforme será apreciado, o provedor de conteúdo 110 provê a melhor personalização de conteúdo, se comparado com outros elementos de processamento. Contudo, o provedor de serviços 120 através do proxy de push 410 também pode prover uma personalização de conteúdo.

Ainda, conforme será apreciado, a estrutura do conteúdo poderia ser dependente dos dados que o aplicativo requer. Por exemplo, em um aplicativo financeiro, o aplicativo pode querer as cotações de ações e as taxas de câmbio. O XML a seguir pode ser usado:

<FIN>

<quotes>

<quote ticker = ABC>

18.54 </quote>

<quote ticker = XYZ>

123.45 </quote>

</quotes>

Petição 870190065310, de 11/07/2019, pág. 42/104

38/63 <rates>

<rate id = US-CAN>

1.15 </rate>

<rate id = US-EURO>

0.85 </rate>

</rates>

</FIN>

Se o usuário apenas quisesse cotações e nenhum câmbio de moeda, a estrutura poderia mudar para:

<FIN>

<quote ticker = ABC>

18.54 </quote>

<quote ticker = XYZ>

123.45 </quote>

</FIN>

Os metadados	podem	prover	uma	informação para o
aplicativo	sobre a estrutura em que	os	dados	são	passados.
Assim,	existem	dois	modelos.	Os	metadados	estáticos
podem ser	providos	para	o proxy	de	push	410	e para o

cliente de push 510 durante um registro ou depois disso. Alternativamente, os metadados para o proxy de push 410 e o cliente de push 510 podem ser pré-aprovisionados, isto é, uma informação é armazenada em um cliente de push ou em um proxy de push até que um aplicativo se registre junto a um cliente.

Uma referência é feita, agora, à Figura 15. A Figura

Petição 870190065310, de 11/07/2019, pág. 43/104

39/63 mostra as etapas lógicas que ocorrem quando do registro de um aplicativo junto a um cliente de push 510.

Uma vez que um aplicativo se registre junto ao cliente de push 510, uma primeira etapa 1510 é para combinar o aplicativo registrado com o tipo de conteúdo requerido pelo aplicativo. Isto é feito a partir do manifesto de aplicativo 918, conforme ilustrado na Figura 9.

Uma segunda etapa 1520 é para configurar o ambiente para o aplicativo. Isto inclui, mas não está limitado às opções de armazenamento e entrega para o aplicativo. Por exemplo, um aplicativo pode limitar as transmissões a uma quantidade predeterminada de dados. O cliente de push 510 em um evento de controle de fluxo, ou se o aplicativo ou o cliente estiver fora de sintonia, pode requerer o armazenamento em cache dos dados para o aplicativo e, opcionalmente, notificar o aplicativo que os dados estão esperando.

Uma terceira etapa 1530 é notificar o proxy de push 410 das regulagens de aplicativo. Isto inclui, por exemplo, o armazenamento disponível para o aplicativo ou o cliente de push 510. Conforme será apreciado, o proxy de push 410 não deve empurrar mais dados do que o cliente de push 510 pode armazenar. Assim, as regulagens de aplicativo poderiam incluir um limite superior dos dados que são passados. Com referência às Figuras 4 e 5, isto poderia invocar o bloco de fragmentação de conteúdo 464 para fragmentar o conteúdo, se ele fosse maior do que o aplicativo pudesse processar. Também, se os dados forem não lineares, pode ser requerido que o bloco de dependências de conteúdo 462 crie metadados para o bloco de dependências de conteúdo 564 da Figura 5,

Petição 870190065310, de 11/07/2019, pág. 44/104

40/63 de modo a se permitir que o bloco de dependências de conteúdo 564 reconstitua os dados.

Com referência de novo à Figura 15, a etapa 1530 também pode indicar uma preferência quanto à entrega de dados. Por exemplo, o aplicativo pode preferir certos tipos de dados em relação a outros, e a estes tipos de dados pode ser proporcionada uma prioridade. Assim, a etapa 1530 pode ser usada para o estabelecimento de uma programação de entrega, onde os dados do tipo A são entregues imediatamente, enquanto os dados do tipo B podem ser entregues em um tempo adiado.

Uma referência é feita, agora, à Figura 16. Quando um provedor de conteúdo 110 se registra junto a um proxy de push 410, várias etapas são realizadas. Uma primeira etapa 1610 inclui a análise das regulagens de cliente requeridas para armazenamento e entrega de conteúdo. Isto pode ser usado, por exemplo, para um anúncio de serviço, de modo a se identificarem clientes de push 510 em dispositivos capazes de consumirem o conteúdo a partir do provedor de conteúdo 110.

Uma segunda etapa 1620 permite que o proxy de push 410 configure o ambiente, incluindo armazenamento de proxy, opções de entrega, opções de transformação, dentre outros.

Na etapa 163 0, o proxy de push 410 pode checar se o aplicativo já está registro para obter um conteúdo a partir de um provedor de conteúdo 110. Se este for o caso, o aplicativo estará pronto para receber conteúdo e uma notificação a partir do proxy de push 410 para o provedor de conteúdo 110 de que o canal de entrega está estabelecido e o aplicativo está pronto para que o conteúdo seja

Petição 870190065310, de 11/07/2019, pág. 45/104

41/63 enviado.

A etapa 1630 pode ocorrer, por exemplo, se um aplicativo estiver pré-instalado em um dispositivo, antes de o provedor de conteúdo 110 ficar on-line. Assim, o aplicativo está esperando que o provedor de conteúdo 110 se torne disponível ou o aplicativo é de um tipo genérico (por exemplo, um navegador ou um Visualizador de RSS), e é capaz de consumir a informação a partir de múltiplos provedores de conteúdo. Em uma regulagem alternativa, se o provedor de conteúdo 110 já estiver disponível antes de o aplicativo ser instalado, a etapa de notificação 1530 na Figura 15 poderá ser usada para se iniciar o conteúdo começando a fluir a partir do provedor de conteúdo 110 para um aplicativo de cliente 150.

Conforme será apreciado com referência à Figura 16, as regulagens de cliente podem incluir uma certa informação, tal como o tamanho de armazenamento disponível usado para particionamento de conteúdo, o tamanho de fila usado para controle de fluxo, a programação de entrega, incluindo um intervalo de push, se o cliente está recuperando uma informação a partir do proxy, a criação de um modo de pseudo-push, opções de personalização, tal como o tamanho de tela de um dispositivo móvel, dentre outras.

Conforme será adicionalmente apreciado, os catálogos de serviço podem diferir para clientes diferentes. Por exemplo, certos clientes podem ser capazes de utilizarem mais dados, têm um tamanho de tela diferente ou outras condições, as quais tornam o cliente mais adequado para um provedor de conteúdo 110 do que um dispositivo que não pode manipular esta quantidade de informação, tem um tamanho de

Petição 870190065310, de 11/07/2019, pág. 46/104

42/63 tela menor, etc. Assim, o proxy de push 410 pode criar um catálogo de serviço para aplicativos de cliente específicos, com base no conhecimento daqueles aplicativos de cliente, e apenas aqueles dispositivos com aquele aplicativo de cliente 150 instalado podem receber uma informação concernente ao provedor de conteúdo.

Conforme será adicionalmente apreciado, em alguns casos, o aplicativo pode ser instalado com base em um provedor de serviços ou um provedor de conteúdo, sem uma intervenção de usuário. Por exemplo, se o provedor de conteúdo 110 se registrar junto ao proxy de push 410, um usuário de um dispositivo móvel pode ter uma obrigação contratual de aceitar um certo aplicativo. Assim, o proxy de push 410 poderia notificar ao cliente de push 510 que está pronto para instalar um aplicativo e empurrar o aplicativo para o cliente de push 510. Isto poderia incluir, por exemplo, um usuário que tivesse concordado em receber um certo número de anúncios a cada mês, de modo a obter uma taxa preferida em seu plano de aparelho móvel. O provedor de conteúdo 110 poderia ser um provedor de anúncio e o proxy de push 410, portanto, poderia empurrar um aplicativo de exibição de anúncio para o cliente de push 510, o qual poderia ser servido por um instalador de aplicativo registrado junto ao proxy de push 410, desse modo se tendo o provedor de conteúdo 110 e o provedor de serviços 120 comandando inteiramente o processo.

O dito acima provê, portanto, um modelo de registro de plug-in em uma estrutura de push, onde cada aplicativo ou provedor de conteúdo se registra e provê um manifesto de aplicativo ou um manifesto de serviço, respectivamente. O

Petição 870190065310, de 11/07/2019, pág. 47/104

43/63 manifesto de aplicativo ou o manifesto de serviço é usado para o estabelecimento de metadados de canal no proxy de push 410 e no cliente de push 510, durante um registro ou subseqüentemente. Depois disso, quando um aplicativo 150 sai de registro e um provedor de conteúdo 110 se registra, um conteúdo pode começar a fluir entre o aplicativo de cliente 150 e o provedor de conteúdo 110.

Com referência às Figuras 4 e 5, o metadados é armazenado em um depósito de metadados de canal 470 e 570. Contudo, também é vantajoso armazenar metadados dinâmicos nos vários elementos de processamento em uma arquitetura 100, se os metadados dinâmicos forem repetidos. Conforme será apreciado, isto poupará processamento no proxy de push 410, uma vez que o extrator de metadados de conteúdo 450 não precisa extrair os mesmos metadados repetidamente. Ainda, o processamento por vários módulos, tal como o bloco de expiração de conteúdo e substituição 466 ou 566, não precisa ser atualizado para cada pedaço de conteúdo que for passado. Uma vez que o proxy de push 410 poderia estar trabalhando com um grande número de clientes de push 510, esta economia de processamento para cada mensagem de conteúdo poderia ser significativa. Ainda, uma largura de banda poderia ser poupada ao não se ter que passar os metadados por uma linha fixa entre provedor de conteúdo 110 e proxy de push 410 ou pelo ar entre o proxy de push 410 e o cliente de push 510.

Uma referência é feita agora à Figura 17. A Figura 17 ilustra um exemplo de fluxo de tempo de rodada, onde sua última versão de metadados é armazenada pelo elemento de processamento.

Petição 870190065310, de 11/07/2019, pág. 48/104

44/63

Conforme visto na Figura 17, o provedor de conteúdo 110 provê um envelope de conteúdo o qual inclui o conteúdo [C1+M (p,c,a) 1]. Isto significa que uma primeira carga útil de conteúdo está sendo enviada juntamente com metadados, que incluem metadados de proxy, metadados de cliente e metadados de aplicativo. Isto é enviado na etapa 1710.

Na etapa 1712, o proxy de push 410 usa os metadados de proxy, conforme ilustrado pela frase use M(p)1”. Ainda, na etapa 1714, o conteúdo mais os metadados que incluem os metadados de cliente e os metadados de aplicativo são passados para o cliente de push 510.

Na etapa 1716, o cliente de push 510 usa os metadados de cliente e ainda, na etapa 1718, passa a carga útil de conteúdo para o aplicativo de cliente 150. O aplicativo de cliente 150 usa, na etapa 1720, os metadados de aplicativo e ainda consome a carga útil de conteúdo.

Conforme visto na etapa 1722, uma segunda carga útil de conteúdo, designada por C2, tem os mesmos metadados que a primeira carga útil de conteúdo. Devido ao fato de cada elemento de processamento, especificamente, o proxy de push 410, o cliente de push 510 e o aplicativo de cliente 150, ter armazenado em cache os metadados para o provedor de conteúdo 110, os metadados não precisam ser passados de novo, mas, ao invés disso, já residem no elemento de processamento.

Depois disso, na etapa 1724, o proxy de push 410 usa os metadados que estavam previamente armazenados em cache para o proxy de push 410. De modo similar, nas etapas 1726 e 1728, o cliente de push 510 usa os metadados de cliente e

Petição 870190065310, de 11/07/2019, pág. 49/104

45/63 o aplicativo de cliente 150 usa os metadados de aplicativo, respectivamente. Um conteúdo é passado, sem metadados, nas etapas 1725 e 1727.

Conforme ilustrado na etapa 1740, o conteúdo pode ter novos metadados para o cliente de push 510 e o aplicativo de cliente 150, mas pode manter os metadados antigos para o proxy de push 410. Neste caso, os metadados que são passados na etapa 1740 incluem apenas os metadados de cliente e os metadados de aplicativo. Na etapa 1742, o proxy de push 410 usa os metadados de proxy armazenados em cache e passa a carga útil de conteúdo juntamente com os novos metadados de cliente e os metadados de aplicativo na etapa 1744.

Na etapa 1746, o cliente de push 510 usa os novos metadados de cliente que foram passados para ele e ainda passa a carga útil de conteúdo e os metadados de aplicativo na etapa 1748.

Na etapa 1750, o aplicativo de cliente usa os novos metadados de aplicativo e ainda consome a carga útil de conteúdo.

Conforme será apreciado por alguém versado na técnica, várias configurações poderiam existir concernentes a quais metadados mudaram e quais metadados permaneceram os mesmos, e apenas os metadados que mudaram são passados para o elemento de processamento que os requerem. Conforme será apreciado por aqueles versados na técnica, o elemento de processamento, se não receber novos metadados, retorna para os metadados armazenados em cache que ele armazenou e usa isto na carga útil de conteúdo.

Em uma modalidade alternativa adicional, as mudanças

Petição 870190065310, de 11/07/2019, pág. 50/104

46/63 em incrementos também podem ser feitas nos metadados. Por exemplo, na etapa 1760, uma nova carga útil de conteúdo juntamente com uma versão de delta de metadados pode ser passada para o proxy de push 410. O delta dos metadados de proxy pode incluir uma diferença entre os metadados de proxy previamente passados e os metadados atuais com que o conteúdo deve ser processado. O proxy de push 410 compõe os metadados pela adição dos metadados prévios com o delta e, então, usando isto para processar a carga útil de conteúdo na etapa 1762. Após isso, uma vez que não houve mudança, na etapa 1764, a carga útil de conteúdo é enviada por si e, na etapa 1766, o cliente de push 510 usa os metadados de cliente previamente armazenados em cache.

O cliente de push então passa a carga útil de conteúdo na etapa 1768 para o aplicativo de cliente 150, o qual usa os metadados de localização previamente armazenados em cache na carga útil de conteúdo na etapa 1770 e, então, consome a carga útil de conteúdo.

Um exemplo de onde os dados em incrementos podem ser usados é uma situação na qual um provedor de conteúdo conta

ao proxy	que	os campos	existentes	na carga	útil de
conteúdo,	30,	devem	ser	extraídos	para envio	para o
aplicativo	de	cliente	150.	Em uma transação subseqüente,

pode ser julgado necessário que dois campos adicionais que são importantes para aquele pedaço de carga útil de conteúdo sejam passados para o aplicativo de cliente 150 pelo provedor de conteúdo 110. O provedor de conteúdo poderia contar, portanto, usando uma mudança em incremento, ao proxy de push para extrair os dois campos adicionais e adicioná-los aos 30 campos que foram previamente extraídos.

Petição 870190065310, de 11/07/2019, pág. 51/104

47/63

Por ter que passar apenas o delta, isto é, os dois campos adicionais, o tempo de processamento para extração dos metadados no proxy de push 410 é reduzido, desse modo se otimizando o processo.

Conforme será adicionalmente apreciado, os metadados podem vir em várias formas. Ele poderia ser compilado tal como um código nativo ou um código interpretado, tal como Java ou C#. Os metadados também podem ser um arquivo de dados / propriedades que indica o uso de certas propriedades. Em uma outra modalidade alternativa, eles podem ser um conteúdo binário, por exemplo, uma transformação, tal como uma transformação de XSLT em um documento em XML.

O dito acima pode ser usado para várias aplicações para a provisão de inteligência para o conteúdo sendo transferido para um aplicativo de cliente específico. Ele também pode prover um conteúdo rico para provedores que podem prover conteúdo para vários aplicativos meramente com base nos metadados que eles provêem com seus dados. Isto pode ser ilustrado a título de exemplo na Figura 18.

Um provedor de conteúdo 110 poderia ser, por exemplo, uma livraria on-line. Um aplicativo pode se registrar junto à livraria on-line para indicar para a livraria on-line que quer ser informado de novos lançamentos de um gênero específico. Isto poderia ocorrer em uma base diária ou semanal ou mensal.

O provedor de conteúdo 110 em uma base semanal, por exemplo, enviaria um envelope de conteúdo 1810 tendo uma lista de livros 1812 para o proxy de push 410. Ele também pode enviar um metadados de transformação 1814, o qual pode

Petição 870190065310, de 11/07/2019, pág. 52/104

48/63 ser, por exemplo, um link de URL para transformação do conteúdo específico com base no aplicativo o recebendo.

Em uma modalidade, a lista de livros 1812 poderia incluir numerosos livros, descrições de cada livro incluindo o autor e uma sinopse do livro. O arquivo pode ser, por exemplo, de 100 KB de tamanho.

O proxy de push 410 pode receber este arquivo grande e pode perceber, com base no aplicativo de cliente sendo servido, que uma transformação para o arquivo de conteúdo grande precisa ser feita, de modo a se acomodar melhor o cliente, o qual pode ser capaz de receber apenas, por exemplo, 10 quilobytes de informação. A transformação que é passada como um metadado de proxy pode ser aplicada, portanto, à lista de livros para redução da lista de livros para um documento de 10 KB modificado 1820. Isto pode ser feito, por exemplo, pela remoção da sinopse, pela classificação dos livros e apenas incluindo os 50 de cima ou outras transformações, conforme seria evidente para aqueles versados na técnica.

Uma vez que a transformação esteja completada, o documento modificado 1820 então é enviado para o cliente de push 510.

Ainda, o armazenamento de mensagem de recuperação adiada 452, conforme visto na Figura 4, pode ser usado para o armazenamento do conteúdo extra que foi retirado no processo de transformação.

A vantagem do dito acima é que a livraria pode ter um site e enviar uma lista para todos os seus clientes. Uma vez que vários clientes não serão clientes sem fio móveis, o arquivo de 100 KB pode ser apropriado para estes

Petição 870190065310, de 11/07/2019, pág. 53/104

49/63 clientes. Também, pela provisão dos metadados de transformação, a livraria pode ter uma lisa que ela envia para qualquer um. Conforme será apreciado por aqueles versados na técnica, as tecnologias da web mais atuais requerem um website separado para um cliente móvel, e isto é eliminado pela solução acima.

O dito acima se presta a um modelo de divulgação, e uma referência é feita, agora, à Figura 19.

Conforme será apreciado por aqueles versados na técnica, um dispositivo móvel pode não desejar receber grandes quantidades de dados quando as condições de rede não forem ótimas para o recebimento de grandes quantidades de dados. Ainda, as operadoras de rede podem desejar evitar o envio de grandes quantidades de dados durante períodos de pico de uso de largura de banda, de modo a espalharem o tráfego de rede mais uniformemente ao longo do tempo. Isto pode ser realizado usando-se um modelo de push / pull, conforme ilustrado na Figura 19.

Conforme descrito na Figura 4 acima, um conteúdo pode ser provido, que inclui mais informação do que o usuário pode precisar atualmente. Por exemplo, se o usuário requisitar uma informação de localização quanto a restaurantes em sua área, um provedor de serviços pode desejar adicionar um anúncio, tais como outros serviços disponíveis na área. Contudo, o provedor de serviços pode não desejar empurrar este conteúdo adicional imediatamente para o usuário, mas, ao invés disso, prover uma prévia, tal como uma manchete ou uma tabela de conteúdos mostrando o conteúdo adicional.

Em outras situações, o conteúdo pode ser grande demais

Petição 870190065310, de 11/07/2019, pág. 54/104

50/63 para enviar para o usuário, e o usuário pode receber apenas a primeira parte do conteúdo e o restante do conteúdo é armazenado em um armazenamento de mensagem de recuperação adiada 452.

Após isso, o conteúdo armazenado pode ser passado para o cliente de push 510 pelo proxy de push 410 ou quando perguntado pelo meu cliente de push 510.

O cliente de push 510 inclui um monitor de status de rede 1910, o qual pode monitorar o status da rede. O cliente de push 510 pode desejar apenas receber dados extras em certas condições. Por exemplo, em um dispositivo móvel híbrido que tem um WiFi e uma opção celular, é mais barato prover dados na conexão de WiFi e, assim, o monitor de status de rede 1910 poderia esperar até o cliente de push 510 ser conectado a uma rede WiFi, antes de obter o conteúdo adiado. Alternativamente, o monitor de status de rede poderia checar se o cliente está em roaming em uma rede estrangeira ou conectado à rede doméstica, de modo a se minimizarem os encargos de roaming. O monitor de status de rede também pode checar para ver se um canal de dados dedicado está estabelecido para o dispositivo. Alguém versado na técnica perceberá que o monitor de status de rede 1910 também poderia checar quanto a várias outras précondições na rede, antes de requisitar que dados adiados sejam passados para o cliente de push 510.

Uma rede sem fio 130 também poderia prover uma informação para um ou ambos o cliente de push 510 e o proxy de push 410 concernindo a custos de entrega de dados. Conforme será apreciado por aqueles versados na técnica, vários períodos de pico ocorreriam para a entrega de

Petição 870190065310, de 11/07/2019, pág. 55/104

51/63 conteúdo. No caso de uma informação de tráfego, os períodos de pico podem ser no começo e no fim do horário comercial, quando as pessoas então indo e vindo do trabalho. Para cotações de ações, o período de pico pode ser durante o horário em que o mercado estivesse aberto. Outros períodos de pico existirão. De modo a se ratear o tráfego de dados, pode ser desejável que a rede cobre taxas diferentes, com base no uso de dados atuais na rede. Assim, durante períodos de pico, uma taxa mais alta pode ser cobrada do que em um período não de pico, tal como no meio da noite. A rede sem fio 130 provê, portanto, notificações de custo de entrega para um gerenciador de recuperação adiada 552 em um cliente de push 510 e para um programador de push 4 54 no proxy de push 410.

Em uma modalidade, os dados do provedor de conteúdo 110 e passados para o proxy de push 410 podem ser classificados com base em sua importância para o cliente. Uma certa informação pode ser designada através de metadados a serem enviados imediatamente. Uma outra informação pode ser designada para ser entregue quando o custo de rede for menor do que um primeiro valor (por exemplo, 10 centavos por megabyte) e outros dados podem ser designados para serem entregues quando os custos de rede caírem abaixo de um segundo valor (por exemplo, 5 centavos por megabyte). Assim, o programador de push 454 considera os dados que estão armazenados no armazenamento de mensagem de recuperação adiada 452 e instrui o agente de push 444 para passar os dados adiados para o agente de push 544 no cliente de push 510.

Alternativamente, o gerenciador de recuperação adiada

Petição 870190065310, de 11/07/2019, pág. 56/104

52/63

552 também poderia monitorar as condições de rede conforme enviado a partir da rede sem fio 130 e, se a taxa de dados for abaixo de uma certa taxa, pode pedir ao intermediário de pull de conteúdo 554 para puxar o conteúdo a partir do armazenamento de mensagem de recuperação adiada 452.

Alternativamente, o gerenciador de recuperação adiada 552 poderia ver se o status de rede é favorável para puxar quantidades maiores de dados, tal como se o dispositivo móvel tivesse conectado a uma rede WiFi, e pedir ao intermediário de pull de conteúdo 554 para puxar os dados a partir do armazenamento de mensagem de recuperação adiada 452.

Conforme será adicionalmente apreciado, um usuário sempre pode requisitar para ter o conteúdo puxado. Assim, a requisição de usuário 1940 também poderia ser usada para disparar um intermediário de pull de conteúdo 554 para puxar os dados a partir do armazenamento de mensagem de recuperação adiada 452.

As regras armazenadas no programador de push 454 e no gerenciador de recuperação adiada 552 poderiam ser metadados estáticos em uma classificação de conteúdo. As regras também poderiam ser baseadas em metadados dinâmicos para os dados em particular que foram passados. Neste caso, o provedor de conteúdo 110 classificou os dados.

Uma referência é feita, agora, à Figura 20. Conforme será apreciado por aqueles versados na técnica, os dados podem ser em uma de duas formas, lineares ou não lineares. Os dados lineares poderiam ser, por exemplo, arranjos ou cadeias ou conteúdo que fluíssem de uma forma linear. Os dados não lineares, inversamente, são dados que não se

Petição 870190065310, de 11/07/2019, pág. 57/104

53/63 relacionam linearmente uns aos outros e podem incluir dependências complexas com certos mapas ou links.

Para um conteúdo linear, uma fragmentação meramente envolve a divisão dos dados em vários componentes, com base em progressão linear. Os dados são divididos em segmentos, e os segmentos são entregues para o proxy de push 410. Conforme indicado na Figura 20, o processador de fragmentação 2010 interage com o conteúdo 2012 e decide que o conteúdo pode ser analisado gramaticalmente com uma progressão linear. O processador de fragmentação 2010, em seguida, divide os dados nos segmentos 2014, 2016 e 2018 no exemplo da Figura 20 e, conforme ilustrado na Figura 20, passa o primeiro segmento 2014, enquanto adia a passagem dos segundo e terceiros segmentos 2016 e 2018, respectivamente.

O módulo de gerenciamento de cursor 2030 mantém um acompanhamento de qual segmento foi entregue e entrega o próximo segmento em ordem.

Com referência à Figura 21, um conteúdo não linear precisa ser dividido de uma forma mais inteligente. Ainda, na outra extremidade, de modo a se reconstituírem os segmentos, metadados são requeridos.

Um processador de fragmentação 2110 analisa o conteúdo, com base em uma análise baseada em metadados. Estes poderiam incluir certos segmentos ou elementos de dados em conjunto, se logicamente requerido. O processador de fragmentação 2110 analisa o conteúdo 2112 e divide o conteúdo em segmentos, com base em regras lógicas. Cada segmento inclui o conteúdo mais metadados incluindo, por exemplo, dependências, mapas e regras de navegação para

Petição 870190065310, de 11/07/2019, pág. 58/104

54/63 cada segmento.

Uma vez divididos, um primeiro segmento 2114 é enviado para o cliente de push 510 e a passagem do restante dos segmentos 2116 e 2118 é adiada, conforme ilustrado na Figura 21. O bloco de navegação de segmento 2130 lida com qual segmento enviar em seguida. Conforme será apreciado por aqueles versados na técnica, o primeiro segmento 2114 inclui uma porção de dados e uma porção de metadados. A porção de metadados do segmento 2114 é uma camada de metadados que é adicionada pelo processador de fragmentação 2110 para indicar para o bloco de dependências de conteúdo 564 como reconstituir o conteúdo. A porção de dados do primeiro segmento 2114 pode incluir o conteúdo e os metadados associados ao canal ou ao conteúdo.

O bloco de navegação de segmento 2130 é adaptado para processar como um usuário viaja através dos dados. Por exemplo, se os dados estiverem no formato de árvore e o usuário descer a partir de uma primeira ramificação da árvore, o bloco de navegação de segmento 2130 poderá passar para o proxy de push 410 outras ramificações na árvore que podem ser atingidas a partir do elemento pelo que o usuário navegou.

Por exemplo, uma árvore poderia incluir um banco de dados de empregado que tem nomes de empregado juntamente com uma estrutura para a corporação. Com base na Figura 21, se o usuário navegasse para um departamento específico da organização, o bloco de navegação de segmento 2130 poderia encaminhar os fragmentos de grupo para grupos naquele departamento. Se o usuário então navegasse para um grupo específico no departamento, o bloco de navegação de

Petição 870190065310, de 11/07/2019, pág. 59/104

55/63 segmento 2130 poderia então passar fragmentos de informação sobre os empregados naquele grupo.

O dito acima requer, portanto, que os dados sejam divididos em componentes lógicos. Identificadores são atribuídos a todos os tipos e ao conteúdo, e uma informação estrutural é criada, passando a informação com a prévia.

O dito acima provê, portanto, uma arquitetura para entrega de conteúdo dinâmico que pode ser usada com sistemas genéricos, onde aplicativos e conteúdo podem ser adicionados, sem mudança da estrutura do sistema. O conteúdo pode ser talhado para se adaptar ao aplicativo o recebendo, e ser fragmentado de acordo com o dito acima.

Conforme será apreciado, o cliente de push e os aplicativos de cliente podem residir em qualquer dispositivo móvel. Um dispositivo móvel de exemplo é descrito abaixo com referência à Figura 22. Isto não tem por significado ser limitante, mas é provido para fins ilustrativos.

A Figura 22 é um diagrama de blocos que ilustra uma estação móvel apta a ser usada com as modalidades preferidas do aparelho e do método do presente pedido. A estação móvel 2200 preferencialmente é um dispositivo de comunicação sem fio de duas vias que tem pelo menos capacidades de comunicação de voz e de dados. A estação móvel 2200 preferencialmente tem a capacidade de se comunicar com outros sistemas de computador na Internet. Dependendo da funcionalidade exata provida, o dispositivo sem fio pode ser referido como um dispositivo de envio de mensagem de dados, um equipamento de radiochamada de duas vias, um dispositivo de e-mail em fio, um telefone celular

Petição 870190065310, de 11/07/2019, pág. 60/104

56/63 com capacidades de envio de mensagem de dados, um implemento de Internet sem fio, ou um dispositivo de comunicação de dados, como exemplos.

Quando a estação móvel 2200 é habilitada para uma comunicação em duas vias, ela incorporará um subsistema de comunicação 2211, incluindo um receptor 2212 e um transmissor 2214, bem como componentes associados, tais como um ou mais elementos de antena, preferencialmente embutidos ou internos, 2216 e 2218, osciladores locais (LOs) 2213, e um módulo de processamento, tal como um processador de sinal digital (DSP) 2220. Conforme será evidente para aqueles versados no campo das comunicações, o projeto em particular do subsistema de comunicação 2211 será dependente da rede de comunicação na qual se pretende que o dispositivo opere.

As exigências de acesso de rede também variarão, dependendo do tipo de rede 2219. Em algumas redes de CDMA, o acesso de rede está associado a um assinante ou usuário de estação móvel 2200. Uma estação móvel de CDMA pode requerer um cartão de módulo de identidade de usuário removível (RUIM) ou um módulo de identidade de assinante (SIM), de modo a operar em uma rede de CDMA. A interface de SIM / RUIM 2244 normalmente é similar a um slot de cartão no qual um cartão de SIM / RUIM pode ser inserido e ejetado como um disquete ou um cartão PCMCIA. O cartão de SIM / RUIM pode ter aproximadamente 64K de memória e manter muitas configurações de tecla 2251, e uma outra informação 2253, tal como uma identificação, e uma informação relacionada à assinante.

Quando os procedimentos requeridos de registro ou

Petição 870190065310, de 11/07/2019, pág. 61/104

57/63 ativação de rede tiverem sido completados, a estação móvel 2200 pode enviar e receber sinais de comunicação pela rede

2219. Conforme ilustrado na Figura 22, a rede 2219 pode consistir em múltiplas estações bases em comunicação com o dispositivo móvel. Por exemplo, em um sistema híbrido CDMA 1x EVDO, uma estação base de CDMA e uma estação base de EVDO se comunicam com a estação móvel e a estação móvel é conectada a ambos simultaneamente. As estações bases de EVDO e CDMA 1x usam intervalos de envio de radiochamada diferentes para comunicação com o dispositivo móvel.

Os sinais recebidos pela antena 2216 através da rede de comunicação 2219 são introduzidos no receptor 2212, o qual pode realizar funções comuns de receptor, tais como amplificação de sinal, conversão para baixo de freqüência, filtração, seleção de canal e similares, e, no sistema de exemplo mostrado na Figura 22, uma conversão de analógico para digital (A/D). Uma conversão A/D de um sinal recebido permite que funções de comunicação mais complexas, tais como demodulação e decodificação, sejam realizadas no DSP

2220. De uma maneira similar, os sinais a serem transmitidos são processados, incluindo modulação e codificação, por exemplo, pelo DSP 2220 e introduzidos no transmissor 2214 para uma conversão de digital para analógica, uma conversão para cima de freqüência, filtração, amplificação e transmissão pela rede de comunicação 2219 através da antena 2218. O DSP 2220 não apenas processa sinais de comunicação, mas também provê controle de receptor e transmissor. Por exemplo, os ganhos aplicados aos sinais de comunicação no receptor 2212 e no transmissor 2214 podem ser controlados de forma adaptativa

Petição 870190065310, de 11/07/2019, pág. 62/104

58/63 através de algoritmos de controle de ganho automático implementados no DSP 2220.

A estação móvel 2200 preferencialmente inclui um microprocessador 2238 o qual controla a operação geral do dispositivo. Funções de comunicação, incluindo pelo menos comunicações de dados e de voz, são realizadas através de um subsistema de comunicação 2211. O microprocessador 2238 também interage com subsistemas de dispositivo adicionais, tal como o visor 2222, a memória flash 2224, a memória de acesso randômico (RAM) 2226, os subsistemas de entrada / saída (I/O) auxiliares 2228, a porta serial 2230, dois ou mais teclados ou miniteclados 2232, o alto-falante 2234, o meio de indicação de violação 2236, outro subsistema de comunicação 2240, tal como um subsistema de comunicações de faixa curta, e quaisquer outros subsistemas de dispositivo geralmente designados como 2242. A porta serial 2230 poderia incluir uma porta USB ou uma outra porta conhecida por aqueles versados na técnica.

Alguns dos subsistemas mostrados na Figura 22 realizam funções relacionadas à comunicação, ao passo que outros subsistemas podem prover funções residentes ou em dispositivo. Notadamente, alguns subsistemas, tais como o teclado 2232 e o visor 2222, por exemplo, podem ser usados para funções relacionadas à comunicação, tal como a introdução de uma mensagem de texto para transmissão por uma rede de comunicação, e funções residentes em dispositivo, tal como uma calculadora ou uma lista de tarefas.

O software de sistema operacional usado pelo microprocessador 2238 preferencialmente é armazenado em um

Petição 870190065310, de 11/07/2019, pág. 63/104

59/63 armazenamento persistente, tal como uma memória flash 2224, a qual, ao invés disso, pode ser uma memória apenas de leitura (ROM) ou um elemento de armazenamento similar (não mostrado). Aqueles versados na técnica apreciarão que o sistema operacional, aplicativos específicos de dispositivo ou partes dos mesmos podem ser temporariamente carregados em uma memória volátil, tal como uma RAM 2226. Os sinais de comunicação recebidos também podem ser armazenados na RAM 2226.

Conforme mostrado, a memória flash 2224 pode ser segregada em áreas diferentes para programas de computador 2258 e armazenamento de dados de programa 2250, 2252, 2254 e 2256. Estes tipos diferentes de armazenamento indicam que cada programa pode alocar uma porção de memória flash 2224 para suas próprias exigências de armazenamento de dados. O microprocessador 2238, além de suas funções de sistema operacional, preferencialmente permite a execução de aplicativos de software na estação móvel. Um conjunto predeterminado de aplicativos que controlam as operações básicas, incluindo pelo menos aplicativos de comunicação de dados e de voz, por exemplo, normalmente será instalado na estação móvel 2200 durante a fabricação. Outros aplicativos poderiam ser instados de forma subseqüente ou dinâmica.

Um aplicativo de software preferido pode ser um aplicativo gerenciador de informação pessoal (PIM) tendo a capacidade de organizar e gerenciar itens de dados relativos ao usuário da estação móvel, tais como, mas não limitando, e-mail, eventos de agenda, correios de voz, compromissos e itens de tarefa. Naturalmente, um ou mais armazenamentos de memória estariam disponíveis na estação

Petição 870190065310, de 11/07/2019, pág. 64/104

60/63 móvel para facilitação do armazenamento de itens de dados de PIM. Esse aplicativo de PIM preferencialmente teria a capacidade de enviar e receber itens de dados, através da rede de comunicação 2219. Em uma modalidade preferida, os itens de dados de PIM são integrados sem emendas, sincronizados e atualizados através da rede de comunicação 2219, com os itens de dados correspondentes do usuário da estação móvel armazenados ou associados a um sistema de computador central. Outros aplicativos também podem ser carregados na estação móvel 2200 através da rede 2219, de um subsistema de I/O auxiliar 2228, da porta serial 2230, do subsistema de comunicações de faixa curta 2240 ou de qualquer outro subsistema adequado 2242, e instalados por um usuário na RAM 2226 ou, preferencialmente, em um armazenamento não volátil (não mostrado) para execução pelo microprocessador 2238. Essa flexibilidade na instalação de aplicativo aumenta a funcionalidade do dispositivo e pode prover funções melhoradas em dispositivo, funções relacionadas à comunicação, ou ambas. Por exemplo, aplicativos de comunicação segura podem permitir que funções de comércio eletrônico e outras transações financeiras como essas sejam realizadas, usando-se a estação móvel 2200.

Em um modo de comunicação de dados, um sinal recebido, tal como uma mensagem de texto ou uma transferência de página da web, será processado pelo subsistema de comunicação 2211 e introduzido no microprocessador 2238, o qual preferencialmente ainda processa o sinal recebido para extração para o visor 2222 ou, alternativamente, para um dispositivo de I/O auxiliar 2228. Um cliente de push 2260,

Petição 870190065310, de 11/07/2019, pág. 65/104

61/63 o qual poderia ser equivalente aos clientes de push 140 e 510, também poderia processar a entrada.

Um usuário de estação móvel 2200 também pode compor itens de dados, tais como mensagens de e-mail, por exemplo, usando o teclado 2232, o qual preferencialmente é um teclado alfanumérico completo ou um miniteclado do tipo de telefone, em conjunto com o visor 2222 e, possivelmente, um dispositivo de I/O auxiliar 2228. Esses itens compostos então podem ser transmitidos por uma rede de comunicação através do subsistema de comunicação 2211.

Para comunicações de voz, uma operação geral de estação móvel 2200 é similar, exceto pelo fato de que os sinais recebidos preferencialmente seriam extraídos para um alto-falante 2234 e sinais para transmissão seriam gerados por um microfone 2236. Subsistemas alternativos de I/O de voz e de áudio, tal como um subsistema de gravação de mensagem de voz, também podem ser implementados na estação móvel 2200. Embora uma saída de voz ou de sinal de áudio preferencialmente seja realizada primariamente através do alto-falante 2234, o visor 2222 também pode ser usado para a provisão de uma indicação da identidade de uma parte chamando, a duração de uma chamada de voz, ou uma outra informação relacionada a uma chamada de voz, por exemplo.

A porta serial 2230 na Figura 22 normalmente seria implementada em uma estação móvel do tipo de assistente digital pessoal (PDA) para a qual uma sincronização com um computador de mesa de usuário (não mostrado) pode ser desejável, mas é um componente de dispositivo opcional. Uma porta como essa 2230 permitiria que um usuário regulasse preferências através de um dispositivo externo ou de um

Petição 870190065310, de 11/07/2019, pág. 66/104

62/63 aplicativo de software e estenderia as capacidades da estação móvel 2200 pela provisão de uma informação ou outras transferências de software para a estação móvel 2200 além de através de uma rede de comunicação sem fio. O percurso de transferência alternativo pode ser usado, por exemplo, para o carregamento de uma chave de encriptação no dispositivo através de uma conexão direta e, assim, confiável e assegurada para, desse modo, se permitir uma comunicação segura de dispositivo. Conforme será apreciado por aqueles versados na técnica, a porta serial 2230 ainda pode ser usada para a conexão do dispositivo móvel a um computador, para atuar como um modem.

Outros subsistemas de comunicação 2240, tal como o subsistema de comunicações de faixa curta, é um componente opcional adicional, o qual pode prover uma comunicação entre uma estação móvel 2200 e sistemas ou dispositivos diferentes, os quais não precisam necessariamente ser dispositivos similares. Por exemplo, o subsistema 2240 pode incluir um dispositivo de infravermelho e circuitos e componentes associados ou um módulo de comunicação de Bluetooth™ para a provisão de comunicação som sistemas e dispositivos habilitados de forma similar.

As modalidades descritas aqui são exemplos de estruturas, sistemas ou métodos tendo elementos correspondentes a elementos das técnicas deste pedido. Esta descrição escrita pode permitir àqueles versados na técnica fazerem e usarem modalidades tendo elementos alternativos que, da mesma forma, correspondem aos elementos das técnicas deste pedido. O escopo pretendido das técnicas deste pedido inclui, assim, outras estruturas, sistemas ou métodos que não diferem das técnicas deste pedido, conforme descrito aqui, e adicionalmente inclui outras estruturas, sistemas ou métodos com diferenças não substanciais em relação

Petição 870190065310, de 11/07/2019, pág. 67/104

63/63 às técnicas deste pedido, conforme descrito aqui.

Claims (8)

1. REIVINDICAÇÕES

   1. Método para adição de inteligência de processamento a uma carga útil de conteúdo em uma arquitetura de entrega de conteúdo dinâmico, que tem pelo menos um primeiro elemento de processamento e um segundo elemento de processamento caracterizado pelo fato de compreender as etapas de:

   criar um primeiro envelope (620, 614), o referido primeiro envelope compreendendo uma carga útil (632) de conteúdo e um segundo elemento de processamento de metadados (630, 622), os referidos metadados de segundo elemento de processamento adaptados para serem rodados no referido segundo elemento de processamento; e formar um segundo envelope (614, 610), o referido segundo envelope contendo o referido primeiro envelope (620, 614) e metadados de primeiro elemento de processamento (622, 612) adaptados para serem rodados no referido primeiro elemento de processamento.
2. 2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os metadados de primeiro elemento de processamento (622, 612) e os metadados de segundo elemento de processamento (630) são específicos para a carga útil de conteúdo (632).
3. 3. Método, de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado pelo fato de ainda compreender a etapa de propagação de metadados relacionados a um canal para a referida carga útil de conteúdo (632) para o referido primeiro elemento de processamento e para o referido segundo elemento de processamento.
4. 4. Método, de acordo com qualquer uma das

   Petição 870190065310, de 11/07/2019, pág. 69/104

   2/8 reivindicação 1 ou 2, caracterizado pelo fato de ainda compreender a etapa de aprovisionamento do referido primeiro elemento de processamento e do referido segundo elemento de processamento com metadados relacionados a um canal para a referida carga útil de conteúdo (632) .
5. 5. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que pelo menos um primeiro elemento de processamento e um segundo elemento de processamento compreendem qualquer um dentre um proxy de push, um cliente de push ou um aplicativo de cliente.
6. 6. Método, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de ainda compreender as etapas de:

   extrair no primeiro elemento de processamento dos referidos metadados de primeiro elemento de processamento (622, 612);

   usar os metadados de primeiro elemento de processamento (622, 612) no referido primeiro envelope (620, 614), criando-se um primeiro envelope processado (620, 614); e entregar o primeiro envelope processado (620, 614) para o referido segundo elemento de processamento.
7. 7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os referidos metadados de primeiro elemento de processamento (622, 612) e os referidos metadados de segundo elemento de processamento (630) são específicos para a referida carga útil de conteúdo (632), e/ou compreendendo ainda a etapa de propagar metadados

   Petição 870190065310, de 11/07/2019, pág. 70/104

   3/8

   relacionados a um canal para a referida carga útil de conteúdo (632) para o referido primeiro elemento de processamento e o referido segundo elemento de processamento; o método compreendendo ainda as etapas de: extrair, no referido primeiro elemento de

   processamento, os referidos metadados de primeiro elemento de processamento (622, 612), usar os referidos metadados de primeiro elemento de processamento (622, 612) no referido primeiro envelope (620, 614), criando, assim, um primeiro envelope processado (620, 614), entregar o referido primeiro envelope processado (620, 614) para o referido segundo elemento de processamento, e antes das referidas etapas de uso e de entrega, aplicação de metadados relacionados ao referido canal no

   referido primeiro envelope. 8. Método, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de ainda compreender, no referido primeiro elemento de

   processamento, a adição de metadados (630, 622) ao referido primeiro envelope (620, 614).

   9. Método, de acordo com qualquer uma das reivindicações 1 a 8, caracterizado pelo fato de que as etapas de criação e formação são realizadas por um provedor de conteúdo.

   10. Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de ainda compreender a etapa de criação de um terceiro envelope (610), o referido terceiro envelope compreendendo o

   Petição 870190065310, de 11/07/2019, pág. 71/104

   4/8 referido segundo envelope (614) e os metadados de terceiro elemento de processamento (612) para um terceiro elemento de processamento.

   11. Método, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que os metadados de primeiro elemento de processamento (622, 612) compreenderem quaisquer parâmetros de processamento, regras de processamento, um manipulador de processamento, um código de manipulador de processamento, uma referência de manipulador de processamento, um enlace para um manipulador de processador, um enlace para código de manipulador de processamento, e/ou um enlace para regras de manipulador de processamento.

   12. Envelope de conteúdo para uma arquitetura de entrega de conteúdo dinâmico caracterizado pelo fato de compreender:

   uma carga útil de conteúdo (632);

   metadados de processamento de conteúdo (630, 622) para um primeiro elemento de processamento na referida arquitetura de entrega de conteúdo dinâmico, os referidos metadados de processamento de conteúdo (630, 622) e a carga útil de conteúdo (632) formando um primeiro envelope (620, 614); e segundos metadados de processamento de conteúdo (622, 612) para um segundo elemento de processamento na arquitetura de entrega de conteúdo dinâmico, os segundos metadados de processamento de conteúdo (622, 612) sendo alojados com o referido primeiro envelope (620, 614) para a formação de um segundo envelope (614, 610).

   13. Envelope de conteúdo, de acordo com a

   Petição 870190065310, de 11/07/2019, pág. 72/104

   5/8 reivindicação 12, caracterizado pelo fato de que o primeiro elemento de processamento e o segundo elemento de processamento compreendem qualquer um dentre um proxy de push, um cliente de push ou um aplicativo de cliente.

   14. Envelope de conteúdo, de acordo com qualquer uma das reivindicações 12 ou 13, caracterizado pelo fato de que os metadados de conteúdo para o segundo elemento (622) de processamento são dispostos para a provisão de instruções completas para o referido segundo elemento de processamento.

   15. Envelope de conteúdo, de acordo com qualquer uma das reivindicações 12 a 14, caracterizado pelo fato de que os metadados de conteúdo para o primeiro elemento de processamento (630) são dispostos para a provisão de instruções completas para o referido primeiro elemento de processamento.

   16. Envelope de conteúdo, de acordo com qualquer uma das reivindicações 12 a 15, caracterizado pelo fato de que os metadados de conteúdo compreendem qualquer um dentre parâmetros de processamento, regras de processamento, um manipulador de processamento, um código de manipulador de processamento, uma referência de manipulador de processamento, um enlace para um manipulador de processador, um enlace para código de manipulador de processamento, e/ou um enlace para regras de manipulador de processamento.

   17. Método de processamento de um envelope que tem primeiros metadados (622) para um elemento de processamento e segundos metadados (630) e conteúdo (632) para elementos de processamento sucessivos em uma arquitetura de entrega

   Petição 870190065310, de 11/07/2019, pág. 73/104

   6/8 de conteúdo dinâmico caracterizado pelo fato de compreender as etapas de:

   extrair os primeiros metadados (622) para o elemento de processamento a partir do envelope;

   usar os referidos primeiros metadados (622) nos referidos segundos metadados (630) e conteúdo (632) para elementos de processamento sucessivos, desse modo se criando um envelope alojado processado (620); e entregar o envelope alojado processado (620) para um dos elementos de processamento sucessivos.

   18. Método, de acordo com a reivindicação 17, caracterizado pelo fato de ainda compreender:

   utilizar metadados de canal (622) para o conteúdo nos referidos metadados (630) e conteúdo (632) para elementos de processamento sucessivos.

   19. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que os metadados de canal são aprovisionados ou propagados para o elemento de processamento, antes de o elemento de processamento receber o envelope.

   20. Método, de acordo com qualquer uma das reivindicações 17 a 19, caracterizado pelo fato de que o elemento de processamento é um dentre um proxy de push ou um cliente de push.

   21. Método, de acordo com qualquer uma das reivindicações 17 a 20, caracterizado pelo fato de que os metadados para o elemento de processamento compreendem qualquer um dentre parâmetros de processamento, regras de processamento, um manipulador de processamento, um código de manipulador de processamento, uma referência de

   Petição 870190065310, de 11/07/2019, pág. 74/104

   7/8 manipulador de processamento, um enlace para um manipulador de processador, um enlace para código de manipulador de processamento, e/ou um enlace para regras de manipulador de processamento.

   22. Sistema para o processamento de um envelope que tem primeiros metadados (622) para um elemento de processamento e segundos metadados (630) e conteúdo (632) para elementos de processamento sucessivos em uma arquitetura de entrega de conteúdo dinâmico, caracterizado pelo fato de compreender:

   meios para a extração dos primeiros metadados (622) para o elemento de processamento a partir do envelope;

   meios para o uso dos referidos primeiros metadados (622) nos referidos segundos metadados (630) e conteúdo (632) para elementos de processamento sucessivos, desse modo se criando um envelope alojado processado (620); e meios para a entrega do envelope alojado (620) processado para um dos elementos de processamento sucessivos.

   23. Produto de programa de computador para a adição de inteligência de processamento a uma carga útil de conteúdo em uma arquitetura de entrega de conteúdo dinâmico, que tem pelo menos um primeiro elemento de processamento e um segundo elemento de processamento, caracterizado pelo fato de compreender um meio que pode ser lido em computador que concretiza instruções executáveis por um dispositivo, sistema ou aparelho de computação para a implementação de todas as etapas do método como definido em qualquer uma das reivindicações 1 a 11.

   24. Produto de programa de computador para o

   Petição 870190065310, de 11/07/2019, pág. 75/104
8. 8/8 processamento de um envelope que tem metadados para um elemento de processamento e metadados e conteúdo para elementos de processamento sucessivos em uma arquitetura de entrega de conteúdo dinâmico, caracterizado pelo fato de 5 compreender um meio que pode ser lido em computador que concretiza instruções executáveis por um dispositivo, sistema ou aparelho de computação para a implementação de todas as etapas do método como definido em qualquer uma das reivindicações 17 a 21.