BRPI0208736B1 - A method and apparatus for delivering content to media devices - Google Patents

Description

MÉTODO Ξ APARELHO PARA FORNECER CONTEÚDO A DISPOSITIVOS DE

MÍDIA

Referência Cruzada a Aplicações Relacionadas Esta aplicação é relacionada e reivindica prioridade ao pedido provisório de Patente dos Estados Unidos intitulado "METHOD AND APPARATUS FOR SERVER-SIDE CONTENT ADAPTATION" cora o número de série ***, por Jay Steele, depositado em 21 de março de 2001 e aqui incorporado por referência.

Esta aplicação é relacionada e reivindica prioridade ao pedido provisório de Patente dos Estados Unidos intitulado "METHOD AND APPARATUS FOR SERVER-SIDE MARKUP RENDERING" com o número de série ***, por Jay Steele, depositado em 21 de março de 2001 e aqui incorporado por referência.

Esta aplicação é relacionada e reivindica prioridade ao pedido provisório de Patente dos Estados Unidos intitulado "METHOD AND APPARATUS FOR PROVIDING RICH CONTENT TO MOBILE COMMUNICATION DEVIOCES" com o número de série 60/341223, por Jay Steele, Chris Billard, Ken Whatmough, Shaun Johansen, e Jon-David Lacey, depositado em 20 de dezembro de 2001 e aqui incorporado por referência. Histórico da Invenção Campo da Invenção A presente invenção relaciona-se genericamente ao campo de dispositivos de mídia e, em particular, a fornecer o chamado "conteúdo rico" a dispositivos de mídia de recursos limitados.

Descrição do Estado da Técnica Houve uma explosão na utilização de dispositivos de mídia de recursos limitados, como assistentes digitais pessoais (PDAs), telefones celulares, comunicadores, organizadores, e dispositivos móveis sem fio. No entanto, esses dispositivos de mídia geralmente têm armazenamento, potência de processamento e, quando aplicável, largura de banda muito limitados. Por exemplo, os telefones-I NTT no modo DoCoMi têm apenas 10 Kilobytes (kb) de memória flash para o armazenamento de qualquer uma aplicação de software. Com esses recursos limitados, é difícil transferir, processar e produzir conteúdo rico, como imagens animadas, utilizando os browsers com base em texto como o browser Internet Explorer™.

Uma outra complicação com esses dispositivos de mídia é sua ampla diversidade mesmo dentro de uma classe do mesmo fabricante. As diferenças poderão ser suficientemente grandes para forçar os desenvolvedores de conteúdo a criarem conteúdo adaptado para cada modelo do dispositivo.

Portanto, é desejável fornecer um método e aparelho para fornecer conteúdo rico aos dispositivos de mídia, que encara, em parte, algumas das deficiências de fornecer conteúdo rico a dispositivos de mídia observados acima. Sumário De acordo com um aspecto da presente invenção, é fornecido um sistema provedor de conteúdo para conectar a uma rede para comunicar com dispositivos de mídia, compreendendo: um subsistema de comunicação para comunicar com os dispositivos de mídia pela rede; uma aplicação conectada ao subsistema de comunicação para receber solicitações de conteúdo dos dispositivos de mídia e, em resposta, recuperar o conteúdo solicitado de um armazém de dados; e um conversor conectado à aplicação para formatar o conteúdo solicitado em um formato binário de modo que o conteúdo solicitado no formato binário seja enviado aos dispositivos de mídia através do subsistema de comunicação.

De acordo com um outro aspecto da presente invenção, é fornecido um dispositivo de mídia para conectar a uma rede para acessar um sistema de provedor de conteúdo para o conteúdo, o dispositivo compreendendo um subsistema de comunicação de dispositivo para comunicar-se com o sistema provedor de conteúdo pela rede; uma infra-estrutura de dispositivo tendo uma tela e uma interface de usuário para interagir com o usuário; e um motor de mídia conectado ao subsistema de comunicação do dispositivo e a infra-estrutura do dispositivo para enviar solicitações de conteúdo ao sistema provedor de conteúdo, e receber o conteúdo solicitado e, em resposta, criar o conteúdo solicitado na infra-estrutura do dispositivo.

De acordo com um outro aspecto da presente invenção, é fornecido um motor de mídia para um dispositivo de mídia conectado a uma rede para acessar o sistema provedor de conteúdo para o conteúdo em que o dispositivo de mídia compreende um subsistema de comunicação de dispositivo para comunicar-se com o sistema provedor de conteúdo; e uma infra-estrutura de dispositivo tendo uma tela e uma interface de usuário para interagir com o usuário; e o motor de mídia conectado ao subsistema de comunicação de dispositivo e a infra-estrutura do dispositivo; o motor de mídia compreendendo uma leitura para receber e ler o conteúdo solicitado, e colocar o conteúdo solicitado na memória; e um criador para criar o conteúdo solicitado na memória na infra-estrutura do dispositivo.

De acordo com mais um aspecto da presente invenção, é fornecido um sistema de simulação para verificar o conteúdo antes do emprego em um sistema provedor de conteúdo, o sistema provedor de conteúdo fornece o conteúdo para dispositivos de mídia, por uma rede, o sistema de simulação compreendendo uma pluralidade de simuladores de dispositivos em que cada um dos simuladores de dispositivo emula um tipo de dispositivo de mídia; um conversor para formatar o conteúdo em um formato binário; e um motor de mídia para criar o conteúdo no formato binário em cada um dos simuladores de dispositivo.

De acordo com um outro aspecto da presente invenção, é fornecido um método para criar um conteúdo de dispositivo de mídia, o dispositivo de mídia tendo memória, compreendendo o recebimento do conteúdo, onde o conteúdo compreende elementos visuais representados por um gráfico visual e elementos comportamentais representados por um gráfico seqüencial; lendo o conteúdo e posicionando o conteúdo na memória do dispositivo de mídia para criar; criação do gráfico visual; criação do gráfico seqüencial; e mudança do gráfico visual de acordo com a criação do gráfico seqüencial; e determinação se a criação do gráfico seqüencial foi finalizada, onde se finalizada; então termina e se não finalizada; então vai para a criação do gráfico visual e continua a partir da criação do gráfico visual.

De acordo com um outro aspecto da presente invenção, é fornecido um método de acessar o sistema provedor de conteúdo para obter conteúdo de um dispositivo de mídia tendo memória; o método compreende enviar solicitações de conteúdo ao sistema provedor de conteúdo; receber o conteúdo solicitado em formato binário; ler o conteúdo solicitado, e colocar o conteúdo solicitado na memória da mídia; e criar o conteúdo solicitado no dispositivo de mídia.

Breve Descrição dos Desenhos A presente invenção será descrita em detalhes com referência aos desenhos acompanhantes, em que numerais iguais denotam partes iguais, e em que: A Figura 1 é um diagrama de blocos de um Sistema de Comunicação com um Sistema Provedor de Conteúdo de acordo com uma versão da presente invenção; A Figura 2 é um diagrama de blocos do Sistema Provedor de Conteúdo da Figura 1, que tem um Conversor; A Figura 3 é um diagrama de blocos do Conversor da Figura 2, que tem um Compilador SVG; A Figura 4 é um diagrama de blocos de um Dispositivo de Mídia da Figura 1, que tem um Motor de Mídia; A Figura 5 é um diagrama de blocos do Motor de Mídia da Figura 4; A Figura 6 é um diagrama de blocos de uma conversão de uma Animação pelo Compilador SVG da Figura 3, cuja conversão tem Elementos Visuais e Elementos Comportamentais; A Figura 7 é um diagrama de blocos de um exemplo dos Elementos Visuais da Figura 6 representado como um gráfico visual 700. A Figura 8 é um diagrama de blocos de um exemplo dos Elementos Comportamentais da Figura 6 representados como um gráfico de seqüência; A Figura 9 é um diagrama de blocos de um exemplo de uma Animação Quadrada; A Figura 10 é um diagrama de blocos de um Conversor Alternativo e um Motor de Mídia SVG de acordo com outra versão da presente invenção; A Figura 11 é um diagrama de blocos de um Sistema de Simulação com um Simulador de Dispositivo para verificar o conteúdo antes de empregar no Sistema Provedor de Conteúdo da Figura 1; A Figura 12 é uma fotografia de tela do Simulador de Dispositivo para um telefone modo I NTT DoCoMo em um computador; A Figura 13 é um diagrama de blocos de um Sistema Provedor de Conteúdo Aprimorado com um Seletor de Recurso de acordo com uma outra versão da presente invenção; A Figura 14 é um diagrama de blocos de estratégias de emprego para a utilização do Seletor de Recurso da Figura 13; A Figura 15 é um diagrama de blocos de seqüência para um Navegador de Conteúdo para gerar uma representação SVG de um sistema de arquivo especificado para varrer e visualizar do Motor de Mídia; A Figura 16 é um fluxograma de um método de prover conteúdo aos Dispositivos de Mídia da Figura 4; A Figura 17 é um fluxograma de um método de processar conteúdo no Dispositivo de Mídia da Figura 1; e A Figura 18 é um diagrama de blocos de um dispositivo de comunicação móvel de modo dual.

Descrição Detalhada Com referência à Figura 1, há um diagrama de blocos de um sistema de comunicação 100 com um Sistema Provedor de Conteúdo 125 de acordo com uma versão da presente invenção. O Sistema de Comunicação 100 compreende dispositivos de mídia 105 para apresentar conteúdo, uma Rede Sem Fio 110 para comunicar-se com os dispositivos de mídia 105, um portal de rede sem fio 115 para fazer interface da rede sem fio 110 com uma rede de área ampla (WAN) 120; a WAN 120 para conexão entre o portal de rede sem fio 115 e o sistema provedor de conteúdo 125; e o sistema provedor de conteúdo 125 para fornecer o conteúdo. 0 portal de rede sem fio 115 fornece uma interface entre a rede sem fio 110 em que os dispositivos 105 operam, e a WAN 120 em que o sistema provedor de conteúdo 125 é configurado para operar. A WAN 120 compreende a Internet, uma conexão direta, uma rede de área local (LAN), um enlace de comunicação sem fio, e qualquer combinação destes. 0 sistema provedor de conteúdo 125 fornece o conteúdo para apresentação nos dispositivos de mídia 105. O conteúdo é fornecido em formato binário para processamento pelos dispositivos de mídia 105. O formato binário é substancialmente o conteúdo como ele deve existir na memória nos dispositivos de mídia 105, com um cabeçalho. O conteúdo inclui conteúdo rico.

Os dispositivos de mídia 105 incluem, por exemplo, dispositivos de comunicação de dados, dispositivos de comunicação de múltiplos modos configurados tanto para a comunicação de dados como a de voz, telefones móveis, dispositivos de comunicação móveis, PDAs ativados para comunicação sem fio, comunicadores uni- ou bilaterais, modems sem fio que operam em conjunto com sistemas de computador, e qualquer tipo de dispositivo de comunicação sem fio fixo ou móvel. Cada um dos dispositivos de mídia 105 é configurado para operar dentro da rede sem fio 110. Um subsistema receptor e transmissor ou transceptor (não mostrado) é incluído dentro de cada um dos dispositivos de mídia 105 para operação na rede sem fio 115. Entretanto, deve ser apreciado que a invenção de modo algum é limitada a esses tipos de dispositivos de exemplo e poderá ser implementada em outros dispositivos com telas.

Alternativamente, o sistema provedor de conteúdo 125 também poderá fornecer conteúdo a qualquer sistema conectado à WAN 12 0, incluindo tanto portais sem fio como sistemas não móveis como sistemas de computador de mesa.

Com referência à Figura 2, é mostrado um diagrama de blocos do sistema provedor de conteúdo 125 da Figura 1. O sistema provedor de conteúdo 125 compreende um armazém de dados 200 para armazenar o conteúdo; uma aplicação 205 para acessar e processar o conteúdo para apresentação nos dispositivos 105; um conversor 210 para converter o conteúdo dentro do formato binário; e um subsistema de comunicação 215 para enviar o conteúdo no formato binário. 0 armazém de dados 200 armazena o conteúdo em um disco rígido de um computador servidor em que o sistema provedor de conteúdo 125 está implementado. 0 conteúdo tem autoria e é armazenado em eXtensible Markup Language (XML) e, em particular, no formato Scalable Vector Graphics (SVG) do XML para gráficos que inclui imagens animadas. Alternativamente, o conteúdo armazenado no armazém de dados 2 00 poderá ser em qualquer forma, mas a aplicação 205 processa o conteúdo recuperado em um formato adequado para o conversor 210. A aplicação 205 compreende um servidor de aplicação. Alternativamente, a aplicação 205 poderá compreender uma aplicação que executa em um servidor de aplicação. Alternativamente, a aplicação 205 poderá ainda compreender uma aplicação para determinado serviço que executa em um servidor de aplicação. O conversor 210 processa o conteúdo para apresentação nos dispositivos 105. Este conteúdo processado é fornecido em formato binário para ainda diminuir o processamento no dispositivo 105. Assim, parte do processamento do conteúdo é transferido dos dispositivos 105 para o sistema provedor de conteúdo 125.

Os dispositivos 105 solicitam conteúdo do sistema provedor de conteúdo 125 através de solicitações HTTP padrão e, em resposta, o sistema provedor de conteúdo 125 fornece o conteúdo em formato binário aos dispositivos 105, onde o conteúdo é exibido e operações relacionadas ao conteúdo, incluindo entradas do usuário, são efetuadas.

Alternativamente, o armazém de dados 200 poderá ser um armazém de dados externo, incluindo, por exemplo, um servidor de web, acessível ao sistema provedor de conteúdo 125 através de uma rede ou outra conexão.

Como o portal 115 e os dispositivos 105, o projeto do subsistema de comunicação 215 no sistema provedor de conteúdo 125 depende das redes de comunicação e dos protocolos utilizados pelo sistema provedor de conteúdo 125. 0 subsistema de comunicação 215 inclui tantos componentes quantos sejam necessários para comunicar-se dentro da WAN 120. Aqueles habilitados na tecnologia apreciarão que o subsistema de comunicação 215 poderá também incluir sistemas para processar solicitações de conteúdo, em que o conteúdo é fornecido em resposta a solicitações. 0 subsistema de comunicação 215 também poderá incluir outros ou sistemas alternativos e disposições comumente associadas aos sistemas provedores de conteúdo.

Com referência à Figura 3, é mostrado um diagrama de blocos do conversor 210 da Figura 2. 0 conversor 210 compreende uma leitora SVG 300 para ler o conteúdo em texto XML com gráf-icos em SVG e formatar o conteúdo em um modelo objeto de documento SVG (SVG DOM) 305; um compilador SVG 310 para converter o SVG DOM 3 05 em um modelo objeto BF 315; e um redator BF 320 para redigir o modelo objeto BF 315 do conteúdo dentro do formato binário. 0 SVG DOM 305 é uma versão na memória do conteúdo para pronto acesso pelo compilador SVG 310. O modelo objeto BF 315 é uma versão na memória do conteúdo conforme visto pelos transformadores nos dispositivos 105. O compilador SVG 310 filtra o SVG DOM 305 para eliminar elementos do DOM que não são suportados pelo modelo objeto BF 315 e então o SVG DOM filtrado 305 é então analisado e construído no modelo objeto BF 315. 0 formato binário é substancialmente um mapa binário ou "dump" do modelo objeto BF 315 mais o cabeçalho. Um exemplo de uma especificação do formato binário é listado na Tabela A. Um exemplo dos elementos SVG suportados pelo modelo objeto BF 315 é listado na Tabela B.

Com referência à Figura 4, é fornecido um diagrama de blocos de um dispositivo de mídia 105 da Figura 1, que tem um motor de mídia 410. O dispositivo de mídia 105 compreende um subsistema de comunicação de dispositivo 405 para fazer interface do dispositivo 105 com a rede sem fio 110 para receber o conteúdo e enviar solicitações relacionadas ao conteúdo como entradas de usuário; o motor de mídia 410 para ler e transformar o conteúdo recebido incluindo interpretar solicitações relacionadas ao conteúdo; uma infra-estrutura de dispositivo 415 com memória para suportar as operações do dispositivo 105; uma tela 420 para apresentar o conteúdo; e um teclado 425 e um dispositivo de entrada auxiliar 430 para receber as entradas do usuário. As entradas do usuário incluem solicitações de conteúdo do sistema provedor de conteúdo 125. 0 dispositivo de entrada auxiliar 430 inclui uma esfera acionada pelo polegar, uma tecla de função especial, e um apontador. 0 motor de mídia 410 preferivelmente permite que operações de conteúdo rico como transformar imagens, transformar animação duende, transformar retângulos cheios e vazios, transformar polígonos, pontos e poli-linhas, transformar texto, e seleção de estilo de fonte de texto. Operações avançadas como vias de animação constante, linear e cúbica, animação de duendes, posições e cor de objetos, e transformação de clipes de áudio também são preferivelmente suportadas pelo motor de mídia 410.

Com referência à Figura 5, é mostrado um diagrama de blocos do motor de mídia 410 da Figura 4. 0 motor de mídia 410 compreende uma leitura 505 para ler o conteúdo recebido em formato binário, formatar o conteúdo recebido para o modelo objeto BF 315 e colocar na memória do dispositivo 105; e um transformador 515 para transformar o conteúdo recebido, o modelo objeto BF 315 para apresentar na tela 420 e para suportar operações relacionadas ao conteúdo.

Com referência à Figura 6, é mostrado um diagrama de blocos de uma conversão de uma animação 600 pelo compilador SVG 310 da Figura 3. Como aqueles habilitados na tecnologia apreciarão, a animação 600 em formato SVG tem elementos visuais associados a elementos comportamentais. O compilador SVG 310 separa a animação 600 em elementos visuais 610 e em elementos comportamentais 620, e constrói o modelo objeto BF 315 com elementos visuais e comportamentais separados. Os elementos visuais 610 incluem texto, linhas, cores e formatos; enquanto os elementos comportamentais 620 incluem operações, como mudar cores e mudar posições dos elementos visuais 610 no tempo.

Com referência à Figura 7, é mostrado um diagrama de blocos de um exemplo dos elementos visuais 610 da Figura 6 representado como um gráfico visual 700. 0 gráfico visual 700 é composto de nós, incluindo grupos e folhas conforme é mostrado. O gráfico visual 700 inclui dois grupos - Grupo A 705 e grupo B 710 - e três folhas - retângulo 715, imagem 720 e texto 725. Um grupo representa o sub-universo transformado, enquanto folhas representam objetos visuais e atributos como imagens, primitivos (incluindo linhas, elipses, e retângulos) e texto. O grupo A de nível superior 705 tem duas filhas, uma das quais é o grupo B 710 e a outra das quais é uma folha, o retângulo 715. O grupo B 710 tem duas filhas próprias suas, cada uma delas uma folha, a saber a imagem 720 e o texto 725. 0 agrupamento dos nós em um gráfico visual permite que transformações, como traduções e rotações, por exemplo, sejam aplicadas em todos os elementos de um grupo. Os nós de grupo 705, 710, também são utilizados para fixar coordenadas gráficas a serem utilizadas quando da transformação de elementos visuais em um grupo ou grupo subordinado. 0 retângulo 715 é um primitivo que é um retângulo com seu canto superior esquerdo nas coordenadas 0,0, um comprimento de 10 pixels, uma altura de 24 pixels, e uma cor de vermelho. A imagem 720 é uma imagem de uma face em formato GIF. O texto 72 5 é uma folha de texto com o texto "Hello, World" iniciado nas coordenadas 0.0.

No dispositivo 105, o gráfico visual 700 é transformado pelo processamento dos nós em uma ordem predeterminada, ao iniciar em um nó raiz e percorrer os nós mais à esquerda primeiro (isto é, travessia pré-ordenada). No gráfico visual 700, o nó raiz, o grupo A 705, é processado primeiro. 0 grupo A 705 refixa uma origem do sistema de coordenadas gráficas para todos os elementos em seu sub-universo para as coordenadas x=10 e y=20. Portanto, todos os componentes transformados no sub-universo do grupo A 705 são desenhados relativos à origem traduzida em 10,20.

Atravessando o gráfico visual 700 em uma travessia pré-ordenada, o grupo B 710 é processado a seguir, que ainda traduz a origem do sistema de coordenadas gráficas ao longo de um eixo y. Os elementos visuais no sub-universo do grupo B 710 são transformados relativo a sua origem em 10.24. A imagem 720 é processada a seguir e a imagem "face.gif" é exibida na tela 420 no grupo B 710 origem de 10.24. Como a imagem 720 é uma folha, o processo de transformação retorna ao nó do grupo, o grupo B 710, e então prossegue para o texto 725. 0 texto "Hello, World" é então desenhado iniciando nas coordenadas 0,0 no sub-universo do grupo B 710, que é nas coordenadas absolutas 10,24. 0 texto 725 também é uma folha, tal que o processo de transformação retorna ao nó de grupo, o grupo B 710. Como todas as filhas do grupo B 710 já foram processadas, o controle então retorna ao grupo A 705 e as coordenadas gráficas são refixadas para o sub-universo do grupo A 705, com origem em 10,20. O retângulo 715 ê então transformado para desenhar o retângulo vermelho, na origem do sub-universo (10,20).

Um algoritmo, como o modelo do pintor SVG, é utilizado para controlar a aparência de elementos visuais sobrepostos em uma tela de exibição. De acordo com este algoritmo, cada operação de desenho do elemento visual "pinta" sobre alguma área de uma tela de exibição do dispositivo de saída. Quando esta área sobrepõe-se a uma área anteriormente pintada, a nova tinta obscurece parcial ou completamente a antiga. Cada elemento visual é desenhado sobre quaisquer partes sobrepostas de elementos desenhados anteriormente no mesmo local na tela de exibição. Portanto, elementos visuais de fundo, que devem aparecer "mais fundo" em uma cena exibida, são localizados em um gráfico visual de modo a serem desenhados primeiro, e os elementos de frente são desenhados por cima dos elementos desenhados anteriormente. No gráfico visual 700, o retângulo vermelho 715 é desenhado por cima de quaisquer seções sobrepostas da imagem "face.gif" 720 desenhada anteriormente e do texto "Hello, World" 725. O gráfico visual 700 é um exemplo de um gráfico visual e pretende ser apenas para fins de ilustração. A estrutura e a disposição de qualquer gráfico visual dependerá dos elementos visuais em uma cena a ser exibida. Diferentes elementos daqueles mostrados na Figura 7 poderão ter outros ou diferentes atributos. Por exemplo, um elipse poderá ser definido pela sua localização central e os comprimentos de seus eixos principal e secundário, em vez de sua localização de canto, largura e altura mostrados para o retângulo na folha 715. Também é contemplado que o retângulo ou outro formato poderá incluir outros ou alternativos atributos daqueles mostrados na folha 715, como um canto diferente ou localização central em vez das coordenadas do canto superior esquerdo, propriedades de enchimento, e designações de tipo de linha. De modo similar, os elementos visuais de texto poderão ter atributos tais como fonte, cor e tamanho.

Com referência à Figura 8, é mostrado um diagrama de blocos de um exemplo dos elementos comportamentais 620 da Figura 6, representado como um gráfico de seqüência 800. O gráfico de seqüência 800 tem por base a premissa de que os elementos visuais 610 possuem comportamentos com base no tempo. Esses comportamentos com base no tempo são utilizados para construir comportamentos que são utilizados tanto para cronogramar a animação 600 e fazê-la comportar-se como se pretendeu. Os elementos comportamentais 620 referenciam os elementos visuais 610 conforme necessário para aplicar os comportamentos apropriados para criar a animação 600.

Será aparente àqueles habilitados na tecnologia que a animação 600 no formato SVG requer um cronogramador para gerenciar os comportamentos dos elementos visuais. A separação dos elementos comportamentais 620 no gráfico de seqüência 800 dos elementos visuais 610 no gráfico visual 700 de acordo com este aspecto da invenção não precisa de um cronogramador separado para processar a animação 600. A cronogramação é inerente no gráfico de seqüência 800, que reduz os requisitos do motor de mídia 310 e ainda fornece um método de fornecer conteúdo convertido de encadeamento seguro. O gráfico de seqüência 800 descreve como uma cena comporta-se no tempo e utiliza uma metáfora de cronogramação de comportamento inerente. 0 gráfico de seqüência consiste de comportamentos e seqüenciadores de comportamento. Os comportamentos incluem operações como pontos quentes, hyperlinks, eventos de teclado, entrada de texto, animação/interpolação, cronômetros, parâmetros variáveis, tocar/parar áudio, modificação do gráfico visual, e outros comportamentos. Os comportamentos são limitados por seqüenciadores de comportamento como seqüências lineares, bifurcações inteiras, qualquer bifurcação, e bifurcação se-ou. O ponto quente é um sensor/comportamento agregado especial que permite que os elementos visuais no gráfico visual de uma cena seja rotulado como um ponto quente. Isto permite que comportamentos sejam executados dependendo da situação da navegação desses pontos quentes utilizando um cursor, apontador ou assemelhado em um dispositivo no qual a cena é exibida. Hyperlinks são utilizados para carregar mais conteúdo da rede e são dependentes, de modo similar, à navegação e a seleção de um elemento visual em uma tela de exibição. Eventos de teclado e entrada de texto também poderá invocar outros comportamentos dependentes.

Animação e interpolação são comportamentos que se aplicam a dados de atributos de vários objetos. Uma interpolação, por exemplo, poderá definir uma curva de interpolação ao longo da qual um ou mais elementos visuais poderão ser deslocados. Cronômetros são utilizados para fixar pausas de duração especificada. Parâmetros variáveis fixam o valor de uma variável ou atributo. O comportamento de ligar/parar áudio provê a ligação controlada de um clipe de áudio. O clipe de áudio poderá ser tocado em sua inteireza, parado após uma duração de tempo predeterminada (utilizando o cronômetro, por exemplo), ou parado quando o usuário navegar até um ponto quente da tela de exibição, por exemplo.

Alguns desses comportamentos afetam os elementos visuais de uma animação. Quando um elemento visual deve ser modificado, o gráfico de seqüência referencia o elemento apropriado do gráfico visual correspondente e modifica o elemento no gráfico visual. 0 gráfico visual é então transformado novamente para refletir modificações nos elementos visuais. 0 seqüenciador de comportamento controla a execução de seus comportamentos associados ou "filhas" em um gráfico de seqüência. Um seqüenciador de comportamento desses é uma seqüência linear, em que cada filha é executada em ordem. Uma seqüência linear é completada quando a totalidade de suas filhas tiverem terminado de executar. Laços poderão ser ativados ou desativados em qualquer seqüência linear, e cada filha é executada durante cada passagem do laço. 0 laço em uma seqüência linear é terminado quando todas as filhas tiverem terminado de executar, enquanto uma seqüência linear inteira com laço é terminada quando todas as suas filhas tiverem executado um determinado número de vezes especificado no seqüenciador de comportamento de seqüência linear no gráfico de seqüência. Se uma seqüência linear deve continuar indefinidamente, então laço infinito é especificado.

Outro seqüenciador de comportamento é referido como uma seqüência de "bifurcação inteira". Uma seqüência de bifurcação inteira é completada quando todas as suas filhas tiverem terminado de executar. Uma seqüência de "bifurcação qualquer" é similar no sentido de que ela é terminada quando qualquer uma de suas filhas tiver terminado de executar. As seqüências de "bifurcação inteira" e de "qualquer bifurcação" emulam multi-encadeamento para processar em dispositivos com recursos limitados de modo que a produção de mais encadeamentos são mais facilmente controlados.

Uma seqüência "se-ou" é um outro seqüenciador de comportamento, que executa condicionalmente filhas diferentes dependendo do estado de um sensor. Por exemplo, uma seqüência se-ou com duas filhas poderá executar uma filha quando o sensor estiver ativo, isto é, uma condição monitorada por um sensor é detectada, enquanto a outra filha poderá ser executada quando a condição não for detectada. A função de sensor é abstrata e poderá representar condições relacionadas a dispositivos como um acionamento e/ou liberação de tecla, e recebimento de um sinal de comunicação.

Cada seqüenciador poderá ele próprio ter um pai e/ou filha de qualquer outro seqüenciador. Utilizando combinações de seqüenciadores de comportamento e de comportamentos, muitos comportamentos de cena diferentes poderão ser emulados ao construir um gráfico de seqüência com base no conteúdo rico original.

Entretanto, a presente invenção de modo algum é limitada aos comportamentos e seqüenciadores do exemplo acima. Conversores de conteúdo e provedores de conteúdo poderão ser configurados para lidar com novos comportamentos e seqüenciadores desenvolvidos para suportar funcionalidades de conteúdo rico adicionais nos dispositivos.

Comportamentos com base no tempo possuem um início e um fim. 0 gráfico de seqüência é cronogramado de um comportamento mais externo a um ou mais comportamentos mais internos e é processado até o comportamento mais externo ser terminado. 0 gráfico de seqüência 800 é representativo da operação cronogramada dos comportamentos com base no tempo, com o laço cronogramado mais exterior indicado pelo membro superior do gráfico. Neste caso um seqüenciador de comportamento de qualquer bifurcação 805 é o comportamento mais externo que controla a operação desta cena. Abaixo do bloco qualquer bifurcação 805 há um laço representado pela seqüência linear 810 com o argumento "laço=verdadeiro", indicando que o laço é ativado. Este laço inclui um ponto quente 815, um tocar clipe de áudio 820, o ponto quente 825, e parar clipe de áudio 830. Neste laço, a ativação do ponto quente no nó alvo 720, a imagem "face.gif" (ver o gráfico visual 700) ao navegar o cursor ou apontador sobre o ponto quente faz com que o clipe de áudio, designado "myclip" na Figura 8, toque (controlado pelo bloco 820) . 0 clipe toca até o ponto quente ser novamente engajado pelo bloco 825; o ponto quente poderá ser de opção binária, por exemplo, em cujo tempo o bloco 830 pára o clipe de áudio.

Os comportamentos interpolativos mostrados nos blocos 835, 840, 845 traduzem seus respectivos objetos alvos ao interpolar novas posições de objeto com base em uma curva de interpolação e um tempo decorrido desde que o comportamento foi executado por último. Os comportamentos interpolados 835, 840, 845, deslocam respectivamente os elementos visuais no nó alvo 725 (o texto "Hello, World"), nó alvo 715 (o retângulo) e o nó alvo 710 (o grupo B 710, incluindo tanto a imagem "face.gif" como o texto "Hello, World"). 0 gráfico visual 700 e o gráfico de seqüência 800 são processados em uma série de passes. Em cada passagem, cada um dos elementos nos gráficos processados e as alocações de tempo do processador são fornecidas a cada um dos elementos conforme necessário pelos elementos.

Esta alocação de tempo poderá ser gerenciada de uma variedade de meios, incluindo, por exemplo, partilhar um único tempo de passagem predeterminado entre todos os comportamentos em um gráfico de seqüência ou permitir que cada comportamento complete uma parte em particular de suas operações associadas a cada passagem.

Alternativamente, o processador também poderá acompanhar os tempos de execução de cada passagem e possivelmente de cada comportamento, de modo que os comportamentos dependentes do tempo poderão determinar um tempo decorrido desde sua passagem anterior, tempo de execução cumulativo (isto é, tempo decorrido total desde o início da primeira passagem), e possivelmente outros tempos associados ao processamento do gráfico de seqüência, conforme necessário. A primeira passagem através do gráfico de seqüência 800, por exemplo, procede conforme segue. O seqüenciador de comportamento mais externo, o seqüenciador de qualquer bifurcação 805 controla o término das operações do gráfico de seqüência. Como foi descrito acima, uma seqüência de qualquer bifurcação é terminada quando qualquer uma de suas filhas tiver terminado de executar. No gráfico de seqüência 80, a seqüência linear 810 é processada primeiro. O primeiro comportamento, o ponto quente 815, é permitido executar parta efetuar um ou mais funções em particular.

Comportamentos interpolados preferivelmente têm uma duração total especificada, tal que as operações de tradução associadas são executadas por um certo período de tempo antes de terminar. A duração total é tipicamente especificada como uma medida de tempo, mas poderá, em vez disso, ser especificada como um comprimento em particular ao longo de uma curva de interpolação, um número de ciclos ao redor de uma curva de interpolação fechada ou algum outro tipo de limite de controle da execução do comportamento. O comportamento interpolado calcula efetivamente uma nova posição para um objeto alvo com base em uma curva de interpolação, uma quantidade de tempo decorrido desde uma passagem anterior através do comportamento, e possivelmente uma "velocidade" de animação preferida. Por exemplo, na primeira passagem pelo gráfico de seqüência 800, o comportamento 835 calcula uma nova posição para o texto "Hello, World" ao interpolar uma nova posição na curva de interpolação utilizando o tempo decorrido desde o início da primeira passagem pelo gráfico de seqüência. O comportamento interpolado calcula efetivamente a distância ao longo da curva de interpolação que o objeto alvo deveria ter-se deslocado no tempo decorrido e assim determina novas coordenadas para o objeto alvo. A cada passagem através de um gráfico de seqüência, o comportamento interpolado 835 executa um cálculo de interpolação. A curva de interpolação poderá ser virtualmente de qualquer formato e tamanho, dependendo dos movimentos desejados a serem aplicados a um objeto visual. Deve ser apreciado que as curvas de interpolação são utilizadas por comportamentos interpolados mas não são necessariamente objetos visuais em um gráfico visual. Contudo, quando se pretende que um elemento visual desloque-se ao longo de uma via que traceja outro elemento visual, a curva de interpolação poderá ser estabelecida com base em um elemento em um gráfico visual. Neste caso, o comportamento interpolado poderá referenciar um objeto não alvo no gráfico visual para determinar a curva de interpolação a ser utilizada para controlar o comportamento de outro objeto, o objeto alvo, no gráfico visual.

Cada um dos comportamentos interpolados 835, 840, 845 por exemplo, poderá utilizar um tipo diferente de curva de interpolação para seu objeto alvo respectivo. Por exemplo, o comportamento 835 poderá utilizar uma curva de interpolação circular para deslocar o texto em um padrão circular, como ao redor da imagem "face.gif", enquanto o comportamento 840 poderá animar o retângulo para lá e para cá ao longo uma curva de interpolação de linha reta. O comportamento 845 poderá então deslocar tanto o texto, que está se deslocando ao redor da imagem, e a imagem, em um padrão retangular ao redor das bordas de uma tela de exibição.

Assim, em uma primeira passagem através do gráfico de seqüência 800, o comportamento ponto quente 815 estabelece seu alvo, a imagem, como o ponto quente, e os comportamentos interpolados 835, 840, 845 todos interpolam novas posições para seus respectivos alvos e referenciam seus alvos no gráfico visual 700 para deslocar os elementos visuais 610 para suas novas posições na tela 420 de acordo.

Então tem início a segunda passagem através do gráfico de seqüência 800. Para os fins deste exemplo, supõe-se que nenhum dos comportamentos terminaram a execução na primeira passagem através do gráfico de seqüência 800. O seqüenciador qualquer bifurcação 805 determina a situação de suas filhas ao verificar sinalizadores "acabado" ou similar ou indicadores, que são associados e poderão preferivelmente ser fixados para cada comportamento. Quando o comportamento termina a execução, ele poderá fixar um sinalizador de acabado para verdadeiro, por exemplo. No gráfico de seqüência 800, o seqüenciador qualquer bifurcação 805 termina o processamento do gráfico de seqüência quando qualquer uma de suas filhas tiver fixado seu sinalizador de terminado.

Na segunda e nas passagens subseqüentes através do gráfico de seqüência 800, cada comportamento reinicia no ponto que ele atingiu na passagem anterior. A seqüência linear 810 ainda não está terminada, e continua com o comportamento de ponto quente 815 para determinar se o usuário navegou para ou sobre a imagem de ponto quente. Para este fim, entradas do usuário poderão ser enfileiradas ou colocadas em uma memória no dispositivo e processados durante as operações de gráfico de seqüência. O comportamento de ponto quente 815 verifica a fila de entrada para determinar se o usuário navegou o cursor ou outro apontador de tela sobre o ponto quente. Se o fez, o comportamento 815 está terminado e um sinalizador de acabado é fixado para verdadeiro para indicar ao seqüenciador linear 810 que ele terminou e então o comportamento 820 é iniciado e uma parte do clipe de áudio "myclip" é tocado pelo comportamento 820.

Como o ponto quente não foi pressionado novamente, por exemplo, nesta passagem atual, o controle então passa para os comportamentos interpolados 835, 840, 845 que, por sua vez, determinam novas posições para seus respectivos objetos alvos para transformar.

Na passagem seguinte, o seqüenciador de qualquer bifurcação 805 mais uma vez verifica para ver se quaisquer de seus comportamentos terminaram e, se o fizeram, a seqüência está terminada. Caso contrário, outra passagem através do gráfico de seqüência 800 é efetuado. Nesta passagem, o comportamento de ponto quente 815 terminou, de modo que a seqüência linear 810 prossegue com o comportamento 820 e tocar outra parte de "myclip", e o alvo de ponto quente é estabelecido pelo comportamento 84 dentro do tempo de execução alocado à seqüência linear 810. Novas posições dos alvos 725, 715, 710 são determinadas, e os elementos visuais 610 são modificados e transformados novamente.

Como o laço está ativado na sequência linear 810, a seqüência repete uma vez todos os seus comportamentos filhas tiverem terminado (isto é, quando o usuário novamente navega para o ponto quente e o clipe de áudio é parado). Portanto, no gráfico de seqüência 800, a seqüência de qualquer bifurcação termina quando um dos comportamentos interpolados 835, 840, 845 termina em uma passagem. Na passagem seguinte, o seqüenciador de qualquer bifurcação 805 detecta o sinalizador de acabado, ou possivelmente de outra forma determina que uma de suas filhas terminou de executar, e o processamento do gráfico de seqüência termina. O gráfico visual 700 e o gráfico de seqüência 800 são mostrados nas Figuras 7 e 8 apenas para fins ilustrativos. A animação poderá incluir menos, mais e diferentes elementos visuais em um gráfico visual e comportamentos e seqüenciadores em um gráfico de seqüência. Isto fornece flexibilidade na definição de muitas animações diferentes ou cenas, que poderão incluir uma multidão de efeitos e animações. As seqüências interpoladas representam apenas um exemplo dos efeitos que poderão ser aplicados aos elementos visuais em um gráfico visual. Quaisquer atributos dos elementos visuais em um gráfico visual, incluindo posição, tamanho e cor, por exemplo, poderá ser modificado. Os elementos visuais e grupos em um gráfico visual também poderão preferivelmente ser deslocados de outras formas do que sendo traduzidos ao longo de uma curva de interpolação.

Por exemplo, objetos alvos em um gráfico visual também poderão ou, em vez disso, serem girados. Muitos outros efeitos também poderíam ser definidos para emular efeitos no conteúdo rico original, e estão dentro do escopo da presente invenção.

Com referência à Figura 9, é mostrado um diagrama de blocos de um exemplo de uma animação quadrada 900. 0 exemplo da animação quadrada 900 é um quadrado azul com uma largura de 80 e uma altura de 200 deslocando-se das coordenadas X=2 0, Y=90 no tempo de 0 segundos para as coordenadas X=20, Y=20 no tempo de dois segundos. No armazém de dados 200, a animação quadrada 900 é armazenada como o quadrado SVG 910 no formato de texto do SVG. O quadrado SVG 910 é lido pela leitora SVG 300 e é então armazenado na memória no formato do SVG DOM 305, que é representado por um gráfico SVG quadrado 920. O compilador SVG 310 então converte o gráfico SVG quadrado 920 no modelo objeto BF 315, que é representado por um gráfico visual quadrado 930 e um gráfico de seqüência quadrada 935. 0 gráfico visual quadrado 930 e o gráfico de seqüência quadrada 935 na memória são mostrados como animação de memória quadrada. 0 redator BF 320 então redige a animação de memória quadrada dentro do formato binário mostrado como binário quadrado 940. O binário quadrado 940 é substancialmente o mesmo que a animação de memória quadrada com um cabeçalho. 0 binário quadrado 940 é enviado a um dos dispositivos 105 para apresentação. Em um dos dispositivos 105, a leitora 505 do motor de mídia 310 lê o binário quadrado 940 e coloca na memória a animação quadrada 900 como animação de dispositivo quadrado na forma do modelo objeto BF 315 para transformar pelo transformador 515. A animação de dispositivo quadrado é substancialmente a mesma que a animação de memória quadrada.

Para os dispositivos de mídia 105, o tempo total para a animação ser baixada e processada em um dos dispositivos de mídia 105 é uma combinação do tempo necessário para baixar o arquivo do binário quadrado 940 dentro da animação de dispositivo quadrado na forma do modelo objeto BF 315 para transformação pelo transformador 515. 0 tempo total poderá ser otimizado dependendo da largura de banda disponível para baixar o arquivo e a potência de processamento disponível no dispositivo de mídia em particular. Assim, o tamanho do arquivo poderá ser diminuído por compressão para um tempo de baixa mais curto em troca de um tempo de processamento maior. Será compreendido por aqueles habilitados na tecnologia que o tempo total poderá ser reduzido por compressão e que a descompressão em cada caso depende da largura de banda disponível aos dispositivos de mídia e a potência de processamento dos dispositivos de mídia.

De acordo com uma outra versão da presente invenção, o redator BF 320 ainda comprime o modelo objeto BF 315 do conteúdo quando da redação no formato binário e a leitora 505 ainda descomprime os arquivos recebidos em formato binário para gerar o conteúdo dentro do modelo objeto BF 315 para transformar. O cabeçalho do formato binário inclui informação sobre a compressão como o tipo e nível de compressão que foi aplicado. Os métodos de compressão e de descompressão são conhecidos na tecnologia.

Com referência à Figura 10, é mostrado um diagrama de blocos de um conversor alternativo 1000 e um motor de mídia SVG 1010 de acordo com outra versão da presente invenção. O conversor alternativo 1000 compreende a leitora SVG 1015 para ler o conteúdo em texto XML com gráficos em SVG e formatar o conteúdo em um SVG DOM alternativo 1020, e um redator SVG 1025 para redigir o SVG DOM alternativo 1015 em formato binário SVG. O DOM SVG alternativo 1015 é uma versão em memória do conteúdo conforme visto pelos transformadores nos dispositivos 105. O formato binário SVG é substancialmente o DOM SVG alternativo 1015 com um cabeçalho. O motor de mídia alternativo 1010 lê o conteúdo no formato binário SVG e o transforma de acordo.

De acordo com uma outra versão da presente invenção, as versões em memória do conteúdo como vistas pelos transformadores nos dispositivos 105 são análogas às versões em memória do conteúdo, o DOM SVG alternativo 1020 e o modelo objeto BF 315, no sistema provedor de conteúdo 125. Será compreendido por aqueles habilitados na tecnologia que, embora seja preferível para as versões em memória do conteúdo no sistema provedor de conteúdo 125 serem as mesmas que as versões em memória do conteúdo conforme visto pelos transformadores nos dispositivos 105, as versões em memória do conteúdo no sistema provedor de conteúdo 125 poderão variar das versões em memória do conteúdo conforme vista pelos transformadores nos dispositivos 105.

Com referência à Figura 11, é mostrado um diagrama de blocos de um sistema de simulação 1100 para verificar o conteúdo antes de seu emprego no sistema provedor de conteúdo 125 da Figura 1. O sistema de simulação 1100 compreende um conversor SVG 1105 para ler o conteúdo criado pelos desenvolvedores em formato de texto de XML e gerar o modelo objeto BF 305 em memória do conteúdo, um motor de mídia 1110 para acessar o modelo objeto BF 305 para transformar o conteúdo, e um simulador de dispositivo 1115 para simular determinado dispositivo para controle pelo motor de mídia 1110 para apresentar o conteúdo. O simulador de dispositivo 1115 emula o dispositivo em particular com uma tela e uma interface de usuário. 0 sistema de simulação 1100 processa em uma estação de trabalho sobre uma máquina virtual Java onde o conversor SVG 1105, o motor de mídia 1110, e o simulador de dispositivo 1115 são aplicações Java.

Será apreciado que o sistema de simulação 1100, o conversor SVG 1105, o motor de mídia 1110, e o simulador de dispositivo 1115 poderão ser redigidos em outras linguagens de programação de computador.

Com referência à Figura 12, é mostrado uma imagem de tela do simulador de dispositivo 115 para um telefone modo I NTT DoCoMo em um computador. Assim, os desenvolvedores criam o conteúdo formatado em texto XML para uma animação e o conteúdo é então testado pelo sistema simulador 1100 onde a animação é tocada no simulador de dispositivo 1115. Os desenvolvedores também entram entradas do usuário, quando permitido pelo conteúdo, na interface de usuário para terminar o teste do conteúdo. A interface de usuário compreende telas de teclado Seta, Enter, Vírgula e Ponto para interagir com o telefone para navegar respectivamente entre pontos quentes, selecionar o ponto quente atual, ativar o botão suave esquerdo, e ativar o botão suave direito. A interface de usuário ainda compreende um mouse para clicar os botões de telefone seta, médio, botão sobre a tela e número para respectivamente navegar entre pontos quentes, selecionar o ponto quente atual, ativar uma tecla suave, e ativar o item de menu correspondente. O simulador de dispositivo poderá ser criado para emular cada um dos dispositivos de mídia disponíveis para testar o conteúdo antes de seu emprego. Alternativamente, os simuladores de dispositivos também poderão ser criados quando um simulador de dispositivo emula um conjunto de especificações que são comuns a um número de dispositivos de mídia. Ao utilizar o sistema simulador 1100, os desenvolvedores poderão evitar testar o conteúdo em dispositivos de mídia reais, que podem ser de número muito grande dada a ampla variedade de dispositivos de mídia.

Com referência à Figura 13, é mostrado um diagrama de blocos de um sistema provedor de conteúdo aprimorado 1300 com um seletor de recursos 1305 de acordo com uma outra versão da presente invenção. O sistema provedor de conteúdo aprimorado 1300 compreende o seletor de recursos 1305, o conversor SVG 1310, o armazém de propriedades 1315, o armazém de conteúdo SVG 1320, e um cache BF 1325. O sistema provedor de conteúdo aprimorado 1300 em resposta a solicitações HTTP 1330 por conteúdo dos motores de mídia 1335, fornece arquivos de conteúdo no formato binário.

Os motores de mídia 1335 fornecem ao sistema provedor de conteúdo aprimorado 1300 solicitações HTTP 1330 que contêm informação de identificação do dispositivo. 0 armazém de conteúdo SVG 1329 contém arquivos SVG de conteúdo em que cada arquivo é associado a diferentes recursos como imagem, som, e arquivos textos SVG para tipos de dispositivos diferentes. Um recurso inclui a URL para a imagem, som, texto SVG ou outro arquivo. 0 seletor de recurso 1305 redireciona as solicitações HTTP 1330 para conteúdo aos recursos específicos com base no contexto do dispositivo.

Em resposta à solicitação HTTP 1330, uma URL de entrada, o seletor de recurso 1305 produz uma URL mapeada que corresponde à URL de entrada com base no mapeamento de recurso especificado em um arquivo de configuração. 0 arquivo de configuração tem a informação de endereço para os arquivos de recurso associados aos diferentes tipos de dispositivos para cada um dos arquivos SVG do conteúdo. O seletor de recurso 1305 inclui o fornecimento de mapeamento um-por-um das URLs para dispositivos diferentes, um dispositivo predefinido quando o dispositivo não é especificado, e regras com base no padrão de mapeamento de URLs para dispositivos diferentes.

Alternativamente, o seletor de recurso 1305 poderá manter uma lista de regras de adaptação para modificar o conteúdo solicitado com base na informação de dispositivo recebida. Por exemplo, se a tela é maior que a página de conteúdo, o sistema provedor de conteúdo aprimorado 1300 poderá crescer o conteúdo para caber na tela ou centrar o conteúdo na tela.

As regras com base no padrão para organizar o conteúdo com base nos recursos do dispositivo incluem (1)organizar por conteúdo e ordenar por dispositivo quando cada subdiretório contém conteúdo específico então contém subdiretórios para cada dispositivo suportado, por exemplo, .../flowers/p503i/*.gif; (2) organizar por dispositivo e ordenar por conteúdo quando cada subdiretório para cada dispositivo suportado então contém subdiretórios para conteúdo específico, por exemplo, .../p503i/flowers/*.gif; e (3) organizar por convenção de nome em que cada nome de arquivo identifica o dispositivo correspondente, por exemplo, *_p503i.gif. O p503i é um tipo de dispositivo. 0 conversor SVG 1310 recebe URLs mapeadas do seletor de recurso 1305 correspondentes às solicitações HTTP 1330 e, em resposta, localiza os arquivos SVG e verifica para determinar se há arquivos BF correspondentes do conteúdo convertido dos arquivos SVG. Se existir um arquivo BF convertido para um arquivo SVG correspondente então os carimbos de data em ambos os arquivos são comparados. Se o carimbo de data do arquivo BF é o mesmo ou posterior ao arquivo SVG correspondente então o arquivo BF é recuperado do Cache BF 1325 e enviado para o motor de mídia 1335 do dispositivo de mídia solicitante sem qualquer conversão. Se o carimbo de data do arquivo BF é anterior ao do arquivo SVG correspondente então o conversor SVG 1310 reconverte o arquivo SVG correspondente, substitui o arquivo BF no cache BF mais antigo 1325, e envia o arquivo BF para o motor de mídia 1335 do dispositivo de mídia solicitante.

Cada um dos motores de mídia 1335 ainda compreende um identificador singular. Embutido dentro de cada uma das URLs enviadas pelos motores de mídia 1335 ao sistema provedor de conteúdo aprimorado 1300 está o identificador singular do motor de mídia solicitante 1335. Os identificadores singulares poderão ser utilizados para implementar a personalização de uma aplicação, como inserir o nome do usuário dentro dos arquivos SVG antes da conversão pelo conversor SVG 1310. Os motores de mídia 1335 com identificadores singulares poderão ser carregados dentro de dispositivos de mídia por um número de métodos como é conhecido na técnica.

Os motores de mídia 1335 com os identificadores singulares poderão ainda ser utilizados para permitir aos dispositivos de mídia acessar a Internet sem um endereço IP designado permanentemente para cada um dos dispositivos de mídia. O dispositivo de mídia com o motor de mídia 1335 poderá acessar a Internet através do sistema provedor de conteúdo aprimorado 1300 tal que o sistema provedor de conteúdo aprimorado 1300 associa um endereço IP designado dinamicamente ao identificador singular do dispositivo de mídia solicitante. Assim, sessões de Internet são suportadas no dispositivo de mídia solicitante no sentido de que todas as URLs do dispositivo de mídia serem enviadas ao sistema provedor de conteúdo aprimorado 1300 para recuperação do conteúdo pela Internet. 0 conteúdo recuperado é recebido pelo sistema provedor de conteúdo aprimorado 1300 no endereço IP designado dinamicamente associado ao identificador singular. Utilizando a associação, o conteúdo recuperado é então encaminhado ao dispositivo de mídia solicitante. É contemplado que o sistema provedor de conteúdo aprimorado 1300 poderá converter, processar e modificar o conteúdo recuperado antes de encaminhá-lo ao dispositivo de mídia. 0 motor de mídia 1335 ainda implementa o pseudo-streaming em que uma primeira peça de conteúdo é carregada e tocada e enquanto a primeira peça está sendo tocada, o motor de mídia 13 3 5 é instruído a buscar uma segunda peça do conteúdo. Assim, quando a primeira peça está terminada, a segunda peça é carregada e inicia a tocar. Esta técnica continua com peças subseqüentes para emular um fluxo contínuo.

Com referência à Figura 14, é mostrado um diagrama de blocos do estratégias de emprego para a utilização do seletor de recurso 1305 da Figura 13. Em uma estratégia de redirecionamento de emprego, o motor de mídia 1335 de um determinado dispositivo de mídia baixa o arquivo BF com os arquivos de imagem e de som. Quando o motor de mídia 1335 (com base no conteúdo do arquivo BF) requer um determinado arquivo de imagem ou de som, ele entra em contato com um servlet 1400 e fornece a informação de dispositivo sobre o determinado dispositivo de mídia. O seletor de recurso 1305 é então entrado em contato, e com base na informação do dispositivo, os arquivos específicos de imagem e/ou de som são recuperado dos recursos 1410 e enviados de volta para o motor de mídia 1335. Os recursos 1410 compreendem o conversor SVG 1310, o armazém de conteúdo SVG 1320 e o cache BF 1325.

Em uma estratégia de emprego de re-escrita, o seletor de recurso 1335 é implementado antes do arquivo BF ser baixado. 0 motor de mídia 1335 envia uma solicitação de recurso ao servlet 1400 com a informação de dispositivo do determinado dispositivo de mídia. O seletor de recurso 1305 então determina os arquivos de imagem e de som apropriados a incluir com base na informação do dispositivo. 0 arquivo SVG com os arquivos de imagem e de som apropriados é então convertido pelos recursos 1410 em um arquivo BF para baixar para o motor de mídia 1335.

Com referência à Figura 15, é mostrado um diagrama de blocos de seqüência para um navegador de conteúdo 1500 para gerar uma representação SVG de um sistema de arquivo especificado para varrer e visualizar do motor de mídia 410. Uma solicitação de conteúdo de um diretório atual é enviado do motor de mídia 410 para um FrontEndServlet 1505. A URL do JSP é recuperada do parâmetro de consulta dentro da solicitação de conteúdo. 0 FrontEndServlet 1505 então envia uma solicitação de seguimento por conteúdo sob o diretório atual ao JSP ContentNavigator 1510. As propriedades em um ContentPageBean 1515 são então fixadas. Isto acrescenta a informação de configuração necessária para criar uma página navegadora de conteúdo. A informação de lista de arquivos gerada do diretório atual é a solicitada e devolvida pelo ContentPageBean 1515. Código SVG é então gerado da informação de lista e devolvido ao FrontEndServlet 1505. 0 código SVG é então convertido pelo conversor SVG 210. O código SVG convertido, um arquivo BF, é devolvido ao FrontEndServlet 1505 no formato binário. O arquivo BF com o sistema de arquivos é então enviado para o motor de mídia 410 para varredura e visualização.

Com referência à Figura 16, é mostrado um fluxograma de um método 1600 de fornecer conteúdo para os dispositivos de mídia 105 da Figura 4. No método 1600, o sistema provedor de conteúdo 125 recebe uma solicitação de conteúdo, por exemplo uma solicitação HTTP, do dispositivo de mídia 105 (etapa 1605) .

Embora a etapa 1605 refere-se a uma solicitação de conteúdo, é contemplado que o sistema provedor de conteúdo 125 poderá ser configurado para empurrar conteúdo para um dispositivo sem primeiro ter recebido a solicitação de conteúdo do dispositivo de mídia 105. Por exemplo, o sistema provedor de conteúdo 125 empurra certo conteúdo para o dispositivo de mídia 105 a intervalos predefinidos, em determinadas horas do dia, ou quando o conteúdo armazenado mudar. Portanto, a etapa 1605 deve ser interpretada como incluindo não apenas a recepção de uma solicitação de conteúdo, mas também dispara para gerar solicitações de conteúdo para empurrar conteúdo para os dispositivos de mídia 105. O sistema provedor de conteúdo 125 então obtém o conteúdo a ser enviado ao dispositivo de mídia 105. O conteúdo poderá ser armazenado localmente no sistema provedor de conteúdo 125. No armazém de dados 200, ou em um armazém remoto no servidor da web na Internet, por exemplo, que seja acessível pelo sistema provedor de conteúdo 125. O sistema provedor de conteúdo 125 então determina se o conteúdo foi obtido (etapa 1615).

Se o conteúdo não foi obtido pelo sistema provedor de conteúdo 125 então uma indicação de erro ou de falha é enviada para o dispositivo de mídia 105 e o erro ou falha é registrado para revisão posterior (etapa 1620) . O processamento da solicitação de conteúdo então termina (etapa 1625).

Se o conteúdo é obtido então o conteúdo é convertido no DOM SVG 305 e então no modelo objeto BF na memória do sistema provedor de conteúdo 125 (etapa 1630). O modelo objeto BF 315 é então formatado em formato binário, um arquivo BF (etapa 1635). O sistema provedor de conteúdo 125 então envia o arquivo BF para o dispositivo de mídia 105 (etapa 1640). As operações de conversão de conteúdo e de transferência estão completas e o processamento termina (etapa 1625). Essas etapas são repetidas para cada solicitação de conteúdo ou alternativamente para cada solicitação de empurrar conteúdo.

Alternativamente, a etapa 1610 para obter conteúdo poderá ainda obter conteúdo com base na informação de dispositivo do dispositivo de mídia 105 e poderá ainda modificar o conteúdo obtido com dados de personalização sobre o usuário do dispositivo de mídia 105 de acordo com o sistema provedor de conteúdo aprimorado 1300.

Com referência à Figura 17, é mostrado um fluxograma de um método de processar conteúdo no dispositivo de mídia 105 da Figura 1. 0 dispositivo de mídia 105 envia uma solicitação de conteúdo ao sistema provedor de conteúdo 125 (etapa 1705) . A solicitação de conteúdo poderá ser gerada por uma aplicação de software que processa no dispositivo de mídia 105, quer em resposta a uma entrada do usuário ou automaticamente. A solicitação de conteúdo automática é análoga à operação de empurrar conteúdo da perspectiva do usuário no sentido que o conteúdo é enviado ao usuário sem o usuário ter feito uma solicitação explícita do conteúdo. Em uma versão, a solicitação contém um localizador de recurso uniforme (URL), associado ao sistema provedor de conteúdo 125. Em outra versão, a solicitação também contém informação de sessão como dados específicos da tela e do computador que descrevem o dispositivo de mídia 105. Esta informação poderá incluir as dimensões da tela do dispositivo, disponibilidade de suporte a cores e o número de cores. 0 dispositivo de média 105 recebe uma resposta à solicitação do sistema provedor de conteúdo 125 (etapa 1710). O dispositivo de mídia 105 então determina se a comunicação do sistema provedor de conteúdo 125 é conteúdo efetivo (etapa 1715). Se uma determinação negativa for feita na etapa 1715, por exemplo, se o provedor de conteúdo tiver devolvido uma indicação de erro ou de falha para o dispositivo de mídia 105, então o erro ou falha é indicado no dispositivo de mídia 105 (etapa 1720) .

Alternativamente, o dispositivo de mídia 105 poderá tentar novamente a solicitação de conteúdo ao enviar a solicitação a um sistema provedor de conteúdo diferente, dependendo, por exemplo, da natureza do erro, falha ou outro problema relacionado ao conteúdo (etapa 1725). O processamento então termina (etapa 173 0) .

Se o conteúdo efetivo é recebido, então o dispositivo de mídia 105 processa o conteúdo pelo motor de mídia 410 transformando os elementos visuais do conteúdo (etapa 1730) . Os elementos comportamentais do conteúdo são então processados. Primeiramente, o motor de mídia 410 determina se o processamento dos elementos comportamentais foram terminados (etapa 1735). Se os elementos comportamentais foram processados então o método está terminado (etapa 1730). 0 motor de mídia 410 então processa através dos elementos comportamentais por uma passagem (etapa 1740) e ainda processa as entradas de usuário armazenadas em uma fila de entrada quando necessário em função do conteúdo (1745). Entradas de usuário ou interações do usuário são preferivelmente coletadas e enfileiradas à medida que são feitas, que é um processo contínuo que executa concorrentemente com as operações de processamento de conteúdo.

Os elementos visuais são então modificados quando o comportamento modifica atributos como a cor, dimensão, posição e assemelhados de um elemento visual (etapa 1750). 0 processamento então volta para a etapa 1730, quando o gráfico visual modificado é transformado.

Um outro aspecto da invenção emprega "pseudo-streaming" para reproduzir o conteúdo. O conteúdo a ser reproduzido ou exibido é dividido em blocos de conteúdo. Após o primeiro bloco, contendo um gráfico visual e parte de um gráfico de seqüência, é transmitido para o dispositivo de mídia 105, o motor de mídia 410 inicia a exibição e enquanto esse bloco do gráfico de seqüência está sendo processado, o bloco seguinte, que poderá incluir novas partes ou comportamentos para o gráfico de seqüência, um novo gráfico visual ou novos elementos visuais para o gráfico visual, ou alguma combinação destes, é apanhado pela rede sem fio. Isto dá a impressão de um fluxo contínuo sem as penalidades da rede sem fio para o "streaming".

Também é contemplado que essa funcionalidade poderá ser incorporada dentro de um gráfico de seqüência ao definir comportamentos que buscam outro conteúdo de um sistema provedor de conteúdo 125 enquanto os elementos comportamentais estão sendo executados. Por exemplo, um comportamento "pegar e substituir" é definido, que quando executado apanha outro comportamento ou combinação de comportamentos e seqüenciadores de comportamento de um sistema provedor de conteúdo 125 e substitui a si próprio com o comportamento apanhado ou combinação de comportamentos quando uma resposta à solicitação é recebida.

Com referência à Figura 18, é mostrado um diagrama de blocos de um dispositivo de comunicação móvel de modo dual 1810. Os dispositivos de mídia 105, por exemplo, incluem o dispositivo de comunicação móvel de modo dual 1810. 0 dispositivo de modo dual 1810 inclui um transceptor 1811, um microprocessador 1838, uma tela 1822, memória flash 1824, memória RAM 1826, dispositivos auxiliares de entrada/saída (E/S) 1828, uma porta serial 1830, um teclado 1832, um alto-falante 1834, um microfone 1836, um subsistema de comunicação sem fio de curta distância 1840, e também poderá incluir outros subsistemas de dispositivos 1842. O transceptor 1811 preferivelmente inclui antenas de transmissão e de recepção 1816, 1818, um receptor 1812, um transmissor 1814, um ou mais osciladores locais 1813, e um processador de sinal digital 1820. Dentro da memória flash 1824, o dispositivo 1810 preferivelmente inclui uma pluralidade de módulos de software 1824A-1824N que podem ser executados pelo microprocessador 1838 (e/ou o DSP 1820), incluindo um módulo de comunicação de voz 1824A, um módulo de comunicação de dados 1824B, e uma pluralidade de outros módulos operacionais 1824N para realizar uma pluralidade de outras funções. 0 dispositivo de comunicação móvel 1810 é preferivelmente um dispositivo de comunicação bilateral tendo capacidades de comunicação de voz e de dados. Assim, por exemplo, o dispositivo poderá comunicar-se por uma rede de voz, como quaisquer das redes celulares analógicas ou digitais, e também poderá comunicar-se por uma rede de dados. As redes de voz e de dados são representadas na Figura 18 pela torre de comunicação 1819. Essas redes de voz e de dados poderão ser redes de comunicação separadas utilizando infra-estrutura separada, como estações base, controladoras de rede, etc., ou elas poderão ser integradas em uma única rede sem fio. 0 subsistema de comunicação 1811 é utilizado para comunicar-se com a rede de voz e de dados 1819, e inclui o receptor 1812, o transmissor 1814, o um ou mais osciladores locais 1813 e também poderá incluir o DSP 1820. 0 DSP 1820 é utilizado para enviar e receber sinais de e para o transmissor 1814 e o receptor 1812, e também é utilizado para receber informação de controle do transmissor 1814 e fornecer informação de controle para o receptor 1812. Se a comunicação de voz e de dados ocorre em uma única freqüência, ou um conjunto com espaçamento de perto de freqüências, então um único oscilador local 1813 poderá ser utilizado em conjunto com o transmissor 1814 e o receptor 1812. Alternativamente, se freqüências diferentes são utilizadas para a comunicação de voz verso a comunicação de dados, então uma pluralidade de osciladores locais 1813 podem ser utilizados para gerar uma pluralidade de freqüências que correspondem às redes de voz e de dados 1819. Embora duas antenas 1816, 1818 são representadas na Figura 18, o dispositivo móvel 1810 poderia ser utilizado com uma única estrutura de antena. Informação, que inclui tanto a informação de voz como a de dados, é comunicada de e para o módulo de comunicação 1811 através de um enlace entre o DSP 1820 e o microprocessador 1838. O projeto detalhado do subsistema de comunicação 1811, como a banda de freqüência, seleção de componentes, nível de potência, etc., será dependente da rede de comunicação 1819 em que se pretende que o dispositivo opere. Por exemplo, o dispositivo 1810 pretende-se que opere em um mercado norte-americano poderá incluir um subsistema de comunicação 1811 projetado para operar com as redes de comunicação de dados móveis MobitexTM ou DataTACTM e também projetado para operar com qualquer uma de uma variedade de redes de comunicação de voz, como AMPS, TDMA, CDMA, PCS, etc., enquanto um dispositivo 1810 que se pretende utilizar na Europa poderá ser configurado para operar com a rede de comunicação de dados de Serviço de Rádio de Pacote Geral (GPRS) e a rede de comunicação de voz GSM. Outros tipos de redes de dados e de voz, tanto separados como integrados, também poderão ser utilizados com o dispositivo móvel 1810.

Dependendo do tipo de rede ou de redes 1819, os requisitos de acesso para o dispositivo móvel de modo dual 1810 também poderão variar. Por exemplo, nas redes de dados Mobitex e DataTAC, dispositivos móveis são registrados na rede utilizando um número de identificação singular associado a cada dispositivo. No entanto, nas redes de dados GPRS, o acesso à rede é associado a um assinante ou usuário de um dispositivo 1810. 0 dispositivo GPRS tipicamente exige um módulo de identidade de assinante ("SIM") que é exigido para operar o dispositivo 1810 em uma rede GPRS. Funções de comunicação local ou de não-rede (se houverem) poderão ser operadas, sem o dispositivo SIM, mas o dispositivo 1810 será incapacitado de realizar quaisquer funções que envolvam comunicação pela rede de dados 1819, afora qualquer outra operação legalmente exigida, como a chamada de emergência 91811.

Após quaisquer procedimentos de registro ou de ativação de rede obrigatórios terem sido terminados, o dispositivo de modo dual 1810 poderá então enviar e receber sinais de comunicação, incluindo tanto sinais de voz como de dados, pela rede ou redes 1819. Os sinais recebidos pela antena 1816 da rede de comunicação 1819 são roteados para o receptor 1812, que fornece a amplificação do sinal, conversão descendente da freqüência, filtragem, seleção de canal, etc., e também poderá fornecer conversão analógica para digital. A conversão analógico para digital do sinal recebido permite que funções de comunicação mais complexas, como a demodulação e a decodificação digital sejam efetuadas utilizando o DSP 1820. De maneira similar, os sinais a serem transmitidos para a rede 1819 são processados, incluindo modulação e codificação, por exemplo, pelo DSP 1820 e são então fornecidos ao transmissor 1814 para conversão digital para analógica, conversão ascendente de freqüência, filtragem, amplificação e transmissão para a rede de comunicação 1819 através da antena 1818. Embora um único tranceptor 1811 é mostrado na Figura 18 tanto para a comunicação de voz como a de dados, é possível que o dispositivo 1810 poderá incluir dois transceptores distintos, um primeiro transceptor para transmitir e receber sinais de voz, e um segundo transceptor para transmitir e receber sinais de dados.

Além de processar os sinais de comunicação, o DSP 1820 também provê o controle do receptor e do transmissor. Por exemplo, os níveis de ganho aplicado aos sinais de comunicação no receptor 1812 e no transmissor 1814 poderão ser controlados adaptivamente através de algoritmos de controle de ganho automáticos implementados no DSP 1820. Outros algoritmos de controle do transceptor também poderíam ser implementados no DSP 182 0 para fornecer um controle mais sofisticado do transceptor 1811. O microprocessador 1838 preferivelmente gerencia e controla a operação geral do dispositivo móvel de modo dual 1810. Muitos tipos de microprocessadores ou de microcontroladores poderíam ser aqui utilizados, ou, alternativamente, um único DSP 1820 podería ser utilizado para efetuar as funções do microprocessador 1838. Funções de comunicação de baixo nível, incluindo pelo menos as comunicações de dados e de voz, são efetuadas através do DSP 1820 no transceptor 1811. Outras aplicações de comunicação de alto nível, como a aplicação de comunicação de voz 1824A e a aplicação de comunicação de dados 1824B poderão ser armazenadas na memória flash 1824 para execução pelo microprocessador 1838. Por exemplo, o módulo de comunicação de voz 1824A poderá fornecer uma interface de usuário de alto nível operável para transmitir e receber chamadas de voz entre o dispositivo móvel de modo dual 1810 e uma pluralidade de outros dispositivos de voz através da rede 1819. De modo similar, o módulo de comunicação de dados 1824B poderá fornecer uma interface de usuário de alto nível operável para enviar e receber dados, como mensagens de correio eletrônico, arquivos, informação de organizador, mensagens de texto curtas, etc., entre o dispositivo móvel de modo dual 1810 e uma pluralidade de outros dispositivos de dados através da rede 1819. 0 microprocessador 1838 também interage com outros subsistemas de dispositivo, como a tela 1822, a memória flash 1824, memória de acesso aleatório (RAM) 1826, subsistemas auxiliares de entrada/saída (E/S) 1828, porta serial 1830, teclado 1832, alto-falante 1834, microfone 1836, subsistema de comunicação de curta distância 1840 e quaisquer outros subsistemas de dispositivo geralmente designados como 1842.

Alguns dos subsistemas mostrados na Figura 18 efetuam funções relacionadas com a comunicação, enquanto outros subsistemas poderão funções "residentes" ou no dispositivo. Notadamente, alguns subsistemas, como o teclado 1832 e a tela 1822 poderão ser utilizados tanto para funções relacionadas com a comunicação, como entrar com uma mensagem de texto para transmissão por uma rede de comunicação de dados, como funções residentes no dispositivo como a calculadora ou a lista de tarefas ou outras funções do tipo PDA. 0 software do sistema operacional utilizado pelo microprocessador 1838 é preferivelmente armazenado em um armazém persistente como a memória flash 1824. Além do sistema operacional, que controla todas as funções de baixo nível do dispositivo 1810, a memória flash 1824 poderá incluir uma pluralidade de programas ou módulos de aplicação de software de alto nível, como o módulo de comunicação de voz 1824A, o módulo de comunicação de dados 1824B, um módulo de organizador (não mostrado), ou qualquer outro tipo de módulo de software 1824N. A memória flash 1824 também poderá incluir um sistema de arquivo para armazenar dados. Esses módulos são executados pelo microprocessador 1838 e fornecem uma interface de alto nível entre o usuário do dispositivo e o dispositivo. Esta interface tipicamente inclui um componente gráfico fornecido através da tela 1822, e um componente de entrada/saída fornecido através do E/S auxiliar 1828, do teclado 1832, do alto-falante 1834 e do microfone 1836. O sistema operacional, as aplicações ou módulos específicos do dispositivo, ou partes dos mesmos, poderão ser temporariamente carregados em um armazém volátil, como a RAM 182 6 para operação mais rápida. Ademais, sinais de comunicação recebidos também poderão ser temporariamente armazenados em RAM 1826, antes de gravá-los permanentemente em um sistema de arquivo localizado no armazém persistente 1824.

Um módulo de aplicação exemplar 1824N que poderá ser carregado no dispositivo de modo dual 1810 é uma aplicação de gerente de informação pessoal (PIM) que fornece funcionalidade de PDA, como eventos de calendário, compromissos, e itens de tarefas. 0 módulo 1824N também poderá interagir com o módulo de comunicação de voz 1824A para gerenciar chamadas telefônicas, correio de voz, etc., e também poderá interagir com o módulo de comunicação de dados para gerenciar as comunicações de correio eletrônico e outras transmissões de dados. Alternativamente, toda a funcionalidade do módulo de comunicação de voz 1824A e do módulo de comunicação de dados 1824B poderão ser integrados no módulo PIM. A memória flash 1824 preferivelmente fornece um sistema de arquivo para facilitar o armazenamento de itens de dados PIM no dispositivo. A aplicação PIM preferivelmente inclui a capacidade de enviar e de receber itens de dados, quer por ela própria, ou em conjunto com os módulos de comunicação de voz e de dados 1824A, 1824B, através da rede sem fio 1819. Os itens de dados PIM são preferivelmente integrados sem falhas, sincronizados e atualizados, através da rede sem fio 1819, com um conjunto correspondente de itens de dados armazenados ou associados a um sistema de computador hospedeiro, assim criando um sistema espelhado para itens de dados associados a determinado usuário. 0 dispositivo móvel 1810 também poderá ser sincronizado manualmente com o sistema hospedeiro ao colocar o dispositivo 1810 em um berço de interface, que acopla a porta serial 1830 do dispositivo móvel 1810 na porta serial do sistema hospedeiro. A porta serial 1830 também poderá ser utilizada para permitir ao usuário fixar preferências através de um dispositivo externo ou aplicação de software, ou baixar outros módulos da aplicação 1824N para instalação. Esta via de baixa com fiação poderá ser utilizada para carregar uma chave de criptografia no dispositivo, que é um método mais seguro que a troca de informação criptografada através da rede sem fio 1819. Módulos de aplicação adicionais 1824N poderão ser carregados no dispositivo de modo dual 1810 através da rede 1819, através de um subsistema E/S auxiliar 1828, através da porta serial 1830, através do subsistema de comunicação de curta distância 1840, ou através de qualquer outro subsistema adequado 1842, e instalado por um usuário na memória flash 1824 ou na RAM 1826. Essa flexibilidade na instalação de aplicação aumenta a funcionalidade do dispositivo 1810 e poderá fornecer funções aprimoradas no dispositivo, funções relacionadas à comunicação, ou as duas. Por exemplo, aplicações de comunicação segura poderão permitir funções de comércio eletrônico e outras transações financeiras a serem efetuadas utilizando o dispositivo 1810.

Quando o dispositivo de modo dual 1810 está operando em um modo de comunicação de dados, o sinal recebido, como uma mensagem de texto ou uma baixa de página da web, será processado pelo transceptor 1811 e fornecido ao microprocessador 1838, que preferivelmente ainda processará o sinal recebido para saída na tela 1822, ou alternativamente, a um dispositivo de E/S auxiliar 1828. O usuário do dispositivo de modo dual 1810 também poderá compor itens de dados, como mensagens de correio eletrônico, utilizando o teclado 1832, que é preferivelmente um teclado alfanumérico completo disposto no estilo QWERTY, embora outros estilos de teclados alfanuméricos completos como aquele conhecido como o estilo DVORAK também poderá ser utilizado. A entrada do usuário ao dispositivo 1810 é ainda aprimorada com uma pluralidade de dispositivos de E/S auxiliares 1828, que poderão incluir um dispositivo de entrada de roda de polegar, uma almofada de toque, uma variedade de comutadores, um comutador de entrada de balanço, etc. Os itens de dados compostos entrados pelo usuário poderão então ser transmitidos pela rede de comunicação 1819 através do transceptor 1811.

Quando o dispositivo de modo dual 1810 está operando no modo de comunicação de voz, a operação geral do dispositivo 1810 é substancialmente similar ao modo de dados, exceto que os sinais recebidos são preferivelmente emitidos para o alto-falante 1834 e os sinais de voz para transmissão são gerados por um microfone 1836. Subsistemas alternativos de E/S de voz ou de áudio, como o subsistema de gravação de mensagem de voz, também poderão ser implementados no dispositivo 1810. Embora a saída do sinal de voz ou de áudio seja preferivelmente efetuada essencialmente através do alto-falante 1834, a tela 1822 também poderá ser utilizada para fornecer uma indicação da identidade de uma parte que chama, a duração da chamada de voz, ou outra informação relacionada à chamada de voz. Por exemplo, o microprocessador 1838, em conjunto com o módulo de comunicação de voz e o software do sistema operacional, poderão detectar a informação de identificação de quem chama de uma chamada de voz de entrada e exibi-la na tela 1822 .

Um subsistema de comunicação de curta distância 1840 também poderá ser incluído no dispositivo de modo dual 1810. Por exemplo, o subsistema 1840 poderá incluir um dispositivo infravermelho e circuitos e componentes associados, de um módulo de comunicação sem fio de curta distância Bluetooth TM para prover comunicação com sistemas e dispositivos ativados de modo similar.

Um conversor de conteúdo e provedor de conteúdo correspondente de acordo com aspectos da invenção são assim adaptáveis para suportar novos recursos ao definir seqüenciadores de novos comportamentos e comportamentos em um processador de conteúdo. Portanto, deve ser apreciado que os seqüenciadores e comportamentos do exemplo acima são apresentados apenas para fins de ilustração, e que a invenção de modo algum é a eles limitada.

Será apreciado que a descrição acima relaciona-se a versões preferidas apenas por meio de exemplo. Muitas variações da invenção serão óbvias para aqueles com conhecimentos no campo, e essas variações óbvias estão dentro do escopo da invenção conforme descrita, quer ou descritas expressamente.

Por exemplo, embora os sistemas e métodos de acordo com aspectos da invenção conforme aqui descritas sejam particularmente adequados a dispositivos de mídia, o tamanho do conteúdo e reduções dos requisitos de processamento também poderão ser vantajosos em outros sistemas como sistemas de computador de mesa e assemelhados em que a memória e os recursos de processamento não são tão limitados quando nos dispositivos de mídia. Tamanhos de arquivo menores e processamento menos intensivo resulta em transferência e exibição mais rápida do conteúdo.

Também deve ser apreciado que os conversores de conteúdo e os processadores não são dependentes de qualquer rede, sistemas ou protocolos de comunicação em particular. Como tal, conversores de conteúdo e processadores de acordo com a presente invenção poderão ser implementados em virtualmente qualquer dispositivo de comunicação unilateral ou bilateral. Dependências relacionadas à comunicação seriam defrontadas nos subsistemas de comunicação em sistemas e dispositivos do provedor de conteúdo.

Embora apenas dois dispositivos de mídia e uma rede sem fio, portal, WAN e sistema provedor de conteúdo foram mostrados nos desenhos, será óbvio que um sistema de comunicação normalmente incluirá muitos desses componentes. 0 sistema provedor de conteúdo poderá ser configurado para comunicar-se com múltiplos portais e diferentes redes sem fio, possivelmente através de tipos diferentes de conexões a portais diferentes. Cada rede sem fio normalmente inclui múltiplos portais e fornece serviços de comunicação a milhares ou mesmo milhões de dispositivos, qualquer um ou a totalidade dos quais poderão ser ativados para comunicação com um ou mais sistemas provedores de conteúdo.

Ademais, aspectos da invenção são descritos acima no contexto de SVG como o formato de conteúdo em um sistema provedor de conteúdo, mas outros formatos de dados em XML e em formatos não XML poderão ser utilizados sem desviar do escopo da presente invenção.

De modo similar, o sistema provedor de conteúdo poderá incluir conteúdo em formatos diferentes e ter múltiplos conversores de conteúdo para converter cada tipo de conteúdo. Também é possível que um sistema provedor de conteúdo poderá fornecer conteúdo a sistemas que não implementam um motor de mídia de acordo com a presente invenção. Isto poderá ser alcançado, por exemplo, ao encaminhar conteúdo a um destino sem primeiro converter o conteúdo. É contemplado que dispositivos como o dispositivo 105 ao qual conteúdo convertido poderá ser enviado pelo sistema provedor de conteúdo geralmente não pode suportar todos os elementos e funções do SVG, devido essencialmente a sua limitada memória e recursos de processamento. Dois perfis SVG menores, SVG Basic e SVG Tiny, são adaptados para diferentes classes de dispositivos. Dependendo de qual desses perfis SVG, ou possivelmente algum outro perfil SVG limitado ou modularizado, seja suportado por um dispositivo de mídia de destino, o conversor 210 filtra e ignora ou despreza os elementos não suportados. 0 conversor 210 poderá ser configurado para assumir um perfil em particular e um conjunto de elementos suportados para todos os dispositivos, ou poderá, em vez disso, ser controlado para filtrar o DOM da leitura SVG 300 com base na informação do dispositivo, em uma base de dados de perfil de dispositivo do sistema provedor de conteúdo ou em uma solicitação de conteúdo de um dispositivo, por exemplo. A função de filtrar o conteúdo poderá, em vez disso, ser implementada na leitora SVG 300, em que elementos SVG não suportados são desprezados ou ignorados quando da construção de um DOM. 0 sistema provedor de conteúdo 125 também poderá incluir outros elementos e suportar outras funções do que aqueles explicitamente mostradas nos desenhos e descritas acima. Em conjunto com o conversor SVG 210, por exemplo, outros módulos poderão ser instalados em um sistema provedor de conteúdo 125 para suportar funções como: (1) determinação e autenticação da identidade do usuário; (2) personalização, para permitir que cada usuário especifique o que e como o conteúdo deve ser a ele encaminhado pelo sistema provedor de conteúdo 125, por exemplo, em um perfil de usuário armazenado no sistema provedor de conteúdo 125 em vez de em cada solicitação de conteúdo; (3) comércio móvel seguro, permitindo que transações financeiras seguras ocorram através do conversor de conteúdo e do processador através, por exemplo, do Protocolo de Transferência de Hypertext Seguro (HTTPS) ; (4) alimentações de dados dinâmica, que permite que dados de terceiros como mapas, cotações de ações, ou clipes de notícias sejam empurrados dinamicamente para um dispositivo através de um conversor de conteúdo; e (5) bate-papo e outros serviços de mensagens, utilizando o sistema provedor de conteúdo 125 para fornecer funcionalidade de comunicação de dispositivo para transportar mensagens. Outros serviços avançados poderão ser, de modo similar, desenvolvidos para aprimorar a experiência geral do usuário.

Tabela A O texto seguinte é uma especificação exemplar para o formato binário. O layout de fluxo geral é descrito primeiro, seguido do formato do fluxo específico dos nós específicos. Todos os valores de tamanho são representados em formato Big-Endian (byte alto primeiro) . Quando bits específicos são referidos por número o bit mais significativo será numerado 7 e o bit menos significativo numerado 0. Valores que não são assinados são valores estritamente positivos.

Cada campo é especificado no formato seguinte: <nome> <Primitivo Java> ctamanho do byte> <Encurtado de acordo com o número candidato> O número candidato é definido nos bytes de estreitamento, que são explicados abaixo.

Formato geral: Cabeçalho inicial BF int (4 bytes) Este valor serve para indicar que o fluxo é um fluxo BF válido e não um texto ou outro fluxo. Isto contém os bytes de caracteres: '211' 'P' 'Μ' Έ'. O primeiro caractere é não texto para reduzir a chance de que um fluxo de texto será interpretado como um BF. Os três bytes restantes são para que o arquivo possa ser identificado se aberto em um editor de texto.

Versão 1 principal BF byte (1 byte) Este valor é atualmente não usado.

Versão 2 principal BF byte (1 byte) Este valor indica a versão principal associada ao fluxo. Motores de mídia poderão opcionalmente tocar fluxos de uma versão inferior (compatibilidade para trás) mas não são obrigados a tocar fluxos de uma versão maior (compatibilidade à frente). Quando uma nova geração de produto é liberada, esta versão deve ser incrementada. Versão 1 secundária BF byte (1 byte) Este valor indica uma versão secundária do formato de fluxo. Motores de mídia dentro de uma versão principal dada precisam ser compatíveis para trás com qualquer versão secundária, mas não necessariamente compatível à frente com revisões de versão 1 secundárias. Quando o formato de fluxo é atualizado esta versão deve ser incrementada.

Versão 2 secundária BF byte (1 byte) Este valor indica a versão do motor de mídia dentro de uma geração projetada para tocar este fluxo. Motores de mídia dentro de uma revisão 1 secundária dada precisam ser compatíveis para frente e para trás com esta versão. Esta versão deve ser incrementada sempre que uma mudança for feita no formato de fluxo que não afetará a capacidade do motor de mídia de tocar a nova versão do fluxo.

Nota de rodapé sobre a informação de versão: Houve algum debate sobre se a informação de versão deve ou não ser codificada como texto ou como bytes. Se ela for codificada como caracteres com base em texto, qualquer um que abrir o arquivo BF em um editor de texto pode ver qual versão ela é. Isto, contudo, também limitaria cada identificador de versão aos caracteres 0-9.

Cabeçalho final BF int (4 bytes) Este valor é utilizado para pegar erros de transferência de arquivo no início. Ele consiste dos caracteres: '\r' ’\n' '32' '\n'. A combinação retorno de carro/alimentação de linha será pego como um erro pelos mecanismos de transferência de arquivo com base em texto. Pedimos observar que os cabeçalhos inicial e final são com base nos cabeçalhos de formato de arquivo PNG. (http://www.w3.org/TR/REC-png.html#R.PNG-file-signature). Codificação utf-8 Esta é a cadeia de texto que representa a codificação que foi utilizada para codificar todas as cadeias restantes no fluxo. Este valor não é incluído nos checksums. Título de cena Este é o título da cena. 0 desenvolvedor de conteúdo pode opcionalmente especificar este campo. Ele tem o comprimento máximo de 16 caracteres. Este limite deve ser cumprido pelo compilador ou fluxo de saída pois nenhuma verificação é garantida na ocasião da de-serialização. Informação de Direitos Autorais Este é um campo opcional que poderá conter informação de direitos autorais especificados pelo desenvolvedor de conteúdo. Ele possui o comprimento máximo de 80 caracteres. Este limite também deve ser cumprido pelo compilador ou fluxo de saída.

Bytes de estreitamento int (4 bytes) Este campo contém uma seqüência de máscaras de bit que permitirão que certos conjuntos de variáveis sejam escritas com um número mínimo de bytes. Os valores para o conjunto serão escritos no número menor de bytes necessários para representar o valor máximo contido naquele conjunto. A tabela seguinte mostra os valores limite que serão utilizados para determinar o número de bytes. Um conjunto não assinado é um conjunto em que valores negativos não possuem significado, como índices de malha. Um conjunto assinado é o conjunto em que tanto valores negativos como positivos têm significado. Se todos os valores de um conjunto assinado são positivos, então ele tem permissão de ser tratado como um conjunto não assinado. (*) Este é o valor máximo que pode ser representado como um número de 4 bytes assinado. Isto é limitado para permitir otimizações possíveis ao fluxo de entrada. 0 estreitamento será aplicado pela fixação de uma máscara de bit a um local específico nos 4 bytes (32 bits) alocados para o campo. Como só é possível para os primeiros 7 candidatos serem ou o byte do tipo não assinado ou curto não assinado, apenas o último bit da máscara de bit precisa ser escrito no fluxo. Os 0's dianteiros podem ser acrescentados à máscara quando o fluxo é de-serializado. Pelo mesmo raciocínio, como os tempos chaves nunca podem ser assinados, o 0 dianteiro da máscara de bit é eliminado e apenas 2 bits são escritos no fluxo.

Largura da cena byte/curto 1 byte/2 bytes) (#5) Altura da cena byte/curto 1 byte/2 bytes) (#5) Esta é a largura e altura preferidas da cena. Ela será utilizada para centrar a cena na tela do dispositivo.

Cor da cena - R byte não assinado (1 byte) Cor da cena - G byte não assinado (1 byte) Cor da cena - B byte não assinado (1 byte) Esta é a cor de fundo da cena em formato RGB. Se a tela do dispositivo for maior que a largura e a altura da cena, esta cor será utilizada para fins de enfoscamento. índice de raiz de seqüência não assinado curto (2 bytes) Este índice dentro da malha de nós do nó raiz do gráfico de seqüência. O índice do gráfico visual não é escrito pois ele sempre será 0.

Tamanho do dado de nó não assinado curto (2 bytes) O número de elementos na malha de nós. Este não é o número de nós na malha, e sim o número de ints que precisarão ser alocados. Este número inclui espaços para dados transientes.

Tamanho do dado de tempos chaves não assinado curto (2 bytes) Tamanho do dado de valores chaves não assinado curto (2 bytes) Esses valores são escritos juntos aqui para dar margem à possibilidade de que os tempos chaves e os valores chaves sejam armazenados em uma única malha. Neste caso o motor precisará acrescentar o tamanho do dado de tempos chaves para todos os índices de valores chaves encontrados na malha de nós. numCoordinateArrays byte não assinado/não assinado curto (1 byte/2 bytes) (#2) O número de malhas de coordenadas a ler. numObjects byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Este é o número de referências de uri da mídia, referências de hyperlink, e cadeias de texto contidos na malha de objetos. numSounds byte não assinado/não assinado curto (1 byte/2 bytes) (#1) numlmages byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Fornecido por conveniência, este é o número de uris de som e uris de imagem, respectivamente, contidos na malha de obj etos. numlnterpolators não assinado curto (2 bytes) 0 número de nós interpoladores contidos na malha de nós. numHotspots não assinado curto (2 bytes) 0 número de nós de pontos quentes contidos na malha de nós. channel datasize não assinado curto (2 bytes) 0 tamanho de dados da malha de canais, checksum int (4 bytes) Este será o valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum e o cabeçalho do arquivo. O valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou um erro ocorreu durante a transmissão do fluxo, malha de nós Os dados para cada nó no gráfico visual seguido de cada nó no gráfico de sequência. A informação é escrita em uma pré-ordem de travessia de profundidade primeiro para dar margem para a possibilidade futura de streaming. Pré-ordem significa que o pai é escrito antes da filha. Profundidade primeiro significa que o sub gráfico da primeira filha é escrito inteiramente antes da segunda filha ser escrita. Por exemplo, Grupo Raiz, Filha 1 do Grupo Raiz, Filha 1 da Filha 1 do Grupo Raiz, ... checksum int (4 bytes) Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. 0 valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo.

Malhas de coordenadas: Estes são os dados de coordenadas para todos os polígonos/polilinhas na cena. Os dados seguintes serão escritos no fluxo para cada malha de coordenadas: comprimento byte não assinado/não assinado curto (1 byte/2 bytes) (#3) cada valor x ou y byte/curto ((1 byte/2 bytes)*comprimento) (#11) Espera-se que o motor armazenará estes em um int[] [] devido à natureza do API gráfico docomo. x e y não são distinguidos aqui. Eles são distinguidos apenas na chamada de transformador pelo índice no objeto de polígono. Se um conjunto de coordenadas será animado, o conjunto não será partilhado a menos que esse seja o efeito desejado. Em vez disso ele será escrito no fluxo como um conjunto de coordenadas separado. 0 compilador ou fluxo de saída será responsável por determinar se a malha de coordenadas deve ser partilhada. checksum int (4 bytes.

Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. 0 valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo.

Malha de tempos chaves Esta é a malha para todos os tempos chaves dos interpoladores na cena. Os dados seguintes serão escritos no fluxo para cada malha de tempo chave: comprimento byte não assinado/não assinado curto (1 byte/2 bytes) (#3) cada tempo chave byte não assinado/não assinado curto/3 bytes não assinados/int não assinado ((1 byte/2 bytes/3 bytes/4bytes)*comprimento) (#9) O primeiro tempo chave de 0 não será escrito no fluxo. Em vez disso, o motor deve inicializá-lo por ocasião da de-serialização. checksum int (4 bytes) Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. 0 valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo.

Malha de valores chaves Trata-se das malhas de valores chaves associados para todos os interpoladores na cena. Como essas malhas poderão ser partilhadas, o tamanho dos dados poderá diferir dos tempos chaves. Se a malha de valor chave será animada então ela não será partilhada a menos que esse seja o efeito desejado. Nesse caso ela será escrita como uma malha de valor chave separado. 0 compilador ou fluxo de saída será responsável por determinar se a malha de valor chave deve ser partilhada. Os dados seguintes serão escritos no fluxo para cada malha de valor chave. comprimento byte não assinado/não assinado curto (1 byte/2 bytes) (#3) cada valor chave byte/curto ( (1 byte/2 bytes)*comprimento) (#10) checksum int (4 bytes) Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. O valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo.

Cadeia/Malha de objetos de mídia Esta malha contém as uris para os nós de imagem, de clipe de áudio e de hyperlink. Ela também contém cadeias de texto de qualquer nó de texto. Os dados serão escritos na ordem seguinte: todas as uris de clipes de áudio, todas as uris de imagem, todas as cadeias de texto, todos os hyperlinks. * Se isto é alocado como um Object[] no lado do motor então o objeto MediaResource pode ser gravar por cima da URL no índice apropriado. checksum int (4 bytes) Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. 0 valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo, dados de canal Estes são os canais da cena. Os dados seguintes serão escritos para todos os canais no fluxo: comprimento byte não assinado/não assinado curto (1 byte/2 bytes) (#3) cada índice de canal não assinado curto (2 bytes* comprimento) checksum int (4 bytes) Este será um valor calculado dos bytes do fluxo, até mas sem incluir os bytes deste checksum, qualquer checksum anterior ou o cabeçalho do arquivo. 0 valor é a soma simples de todos os valores escritos no fluxo. Se este valor não estiver correto, o motor deve abortar a carga pois o fluxo foi alterado ou ocorreu um erro durante a transmissão do fluxo.

Formato dos nós específicos: Valores (*) são transientes e não serão escritos no fluxo. Eles serão alocados e designados valores iniciais pelo motor por ocasião em que o fluxo é de-serializado. Todos os nós terão um campo de bits. Dentro desse byte os significados seguintes foram designados às posições de bit: Visível 7 Tem traço 6 Tem enchimento 5 At ivo 4 Terminado 3 Laço 2 Notificar 1 Como os nós serão lidos em base de tipo a tipo não precisa haver nenhuma colisão de espaço de nome no tipo de nó entre seqüência e nós visuais. Os tipos de nó visual iniciação no tipo 1 e incrementam até 64. Os tipos de nó de seqüência iniciam em Byte.MAX_VALUE(127) e decrementam para 65. 0 complemento de uns (~) será utilizado para indicar visibilidade daqueles nós em que o bit visível é o único bit no campo Bits. Especificamente, esses nós são: Interpolador, Ponto Quente, Grupo, Imagem e Texto. O campo Bits para os nós listados não será escrito. Em vez disso, se o nó for visível, a constante de tipo normal é escrita no fluxo. Se o nó não é visível o complemento de uns do tipo é escrito no fluxo.

Campos Bits que são marcados com um P indicam que a visibilidade é empacotada no identificador de tipo. Identificadores de tipo: Retângulo 10 Polilinha/Polígono 20 Texto 30 Imagem 4 0 Grupo 5 0 Laço 125 Bifurcação inteira 120 Qualquer bifurcação 115 Ponto quente 110 Clipe de áudio 105 Parada de áudio 100 Hyperlink 95 Modificador de canal 90 Interpolador 85 Nós de Seqüência: Clipe de áudio: tipo: byte (1 byte) Bits: byte não assinado (1 byte) Laço Notificar * pai índice de mídia byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Parada de áudio: Tipo: byte (1 byte) * Bits: (uso futuro) * pai: Modificador de canal: Tipo: byte (1 byte) * Bits: (uso futuro) * Pai: índice de canal: byte não assinado/não assinado curto (1 byte/2 bytes) (#8) operação: byte (1 byte) Hyperlink: Tipo byte (1 byte) * Bits (uso futuro) * Pai: índice de enlace: byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Interpolador: Tipo: byte (1 byte) P Bits: byte não assinado (1 byte) Visível: * At i vo: * Pai: loopcount byte não assinado/não assinado curto (1 byte/2 bytes) (#4) Tipo de interpolação byte (1 byte) índice de tempos chave byte não assinado/não assinado curto (1 byte/2 bytes) (#6) índice de valores chaves byte não assinado/não assinado curto (1 byte/2 bytes) (#7) * startTime * interval Número de alvos setValue byte não assinado/não assinado curto (1 byte/2 bytes) (#3) índices para setValue não assinado curto (2 bytes*Número de alvos) Em oposição a ter um método de valor fixado, o índice para escrever o valor será especificado diretamente no interpolador. Isto vinculará de perto o formato ao motor de mídia de formato de malha int quando ele indexa o local do campo na malha de nós. O ganho é que isto permitirá a retirada do método de valor fixado e identificadores de valor fixado. Seria possível reconstruir esta informação em uma versão objeto do motor se os índices de cada nó são acompanhados quando da de-serialização e casados quando o interpolador é de-serializado. Se o interpolador tem um alvo nulo para o valor fixado, o índice não deve ser escrito no fluxo.

Ponto quente: Tipo: byte (1 byte) P Bits: byte não assinado (1 byte) Visível: * At ivo: * Pai: índice da filha sem foco não assinado curto (2 bytes) índice da filha em foco não assinado curto (2 bytes) índice da filha inativa não assinado curto (2 bytes) Qualquer bifurcação: Tipo: byte (1 byte) * Bits: * Terminado: * Pai: numChildren: byte não assinado/não assinado curto (1 byte/2 bytes) (#3) índices de filhas: não assinado curto (2 bytes * numChildren) Todas bifurcações Tipo: byte (1 byte) * Bits: (uso futuro) * Pai: numChildren byte não assinado/não assinado curto (1 byte/2 bytes) (#3) índices de filhas: não assinado curto (2 bytes * num/children) Laço: Tipo: byte (1 byte) * Bits: (uso futuro) * Pai: numChildren byte não assinado/não assinado curto (1 byte/2 bytes) (#3) LoopCount byte não assinado/não assinado curto (1 byte/2 bytes) (#4) * CurrentChild * CurrentLoop índices de filhas: não assinado curto (2 bytes * numChildren) Nós visuais: Retângulo: Tipo: byte (1 byte) Bits: byte não assinado (1 byte) Visível Tem traço Tem enchimento X byte/curto (1 byte/2 bytes) (#13) Y byte/curto (1 byte/2 bytes) (#14) Cor de enchimento - Vermelho (se aplicável) byte não assinado (1 byte) Cor de enchimento - Verde (se aplicável) byte não assinado (1 byte) Cor de enchimento - Azul (se aplicável) byte não assinado (1 byte) Cor de traço - Vermelho (se aplicável) byte não assinado (1 byte) Cor de traço - Verde (se aplicável) byte não assinado (1 byte) Cor de traço - Azul (se aplicável) byte não assinado (1 byte) Largura byte não assinado/não assinado curto (1 byte/2 bytes) Altura byte não assinado/não assinado curto (1 byte/2 bytes) Polígono/Polilinha: Tipo: byte (1 byte) Bits: byte não assinado (1 byte) Visível Tem traço Tem enchimento X byte/curto (1 byte/2 bytes) (#13) Y byte/curto (1 byte/2 bytes) (#14) Cor de enchimento - Vermelho (se aplicável) byte não assinado (1 byte) Cor de enchimento - Verde (se aplicável) byte não assinado (1 byte) Cor de enchimento - Azul (se aplicável) byte não assinado (1 byte) Cor de traço - Vermelho (se aplicável) byte não assinado (1 byte) Cor de traço - Verde (se aplicável) byte não assinado (1 byte) Cor de traço - Azul (se aplicável) byte não assinado (1 byte) índice de coordenada x byte não assinado/não assinado curto (1 byte/2 bytes) (#2) índice de coordenada y byte não assinado/não assinado curto (1 byte/2 bytes) (#2) Texto: Tipo: byte (1 byte) P Bits: byte não assinado (1 byte) Visível X byte/curto (1 byte/2 bytes) (#13) Y byte/curto (1 byte/2 bytes (#14) Cor - Vermelho byte não assinado (1 byte) Cor - Verde byte não assinado (1 byte) Cor - Azul byte não assinado (1 byte) fonte int (4 bytes) índice de texto byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Para suportar traço e enchimento em um nó de texto, cada caractere precisaria ser convertido para uma polilinha equivalente. Esta opção não é incluída nesta versão; como resultado, apenas o enchimento é suportado.

Imagem Tipo: byte (1 byte) P Bits: byte não assinado (1 byte) Visível X byte/curto (1 byte/2 bytes) (#13) Y byte/curto (1 byte/2 bytes) (#14) índice de imagem byte não assinado/não assinado curto (1 byte/2 bytes) (#1) Grupo Tipo byte (1 byte) P Bits: byte não assinado (1 byte) Visível X byte/curto (1 byte/2 bytes) (#13) Y byte/curto (1 byte/2 bytes) (#14) currentChild byte/curto(1 byte/2 bytes) (#12) numChildren byte não assinado/não assinado curto (1 byte/2 bytes) (#3) índices de filha não assinado curto (2 bytes) * denota uma extensão para o SVG ** Nota: O elemento "pict" precisa ser utilizado como uma filha do atributo texto; caso contrário, ele será ignorado pelo compilador SVG.

Legenda: branco não é suportado pelo SVG Y é suportado pelo SVG, mas não por esta implementação Y é suportado por SVG e por esta implementação.

REIVINDICAÇÕES

Claims (11)

1. Sistema provedor de conteúdo (125) para conectar a uma rede sem fio (110) para comunicar-se com dispositivos de comunicação móvel de recursos limitados (105), caracterizado pelo fato de compreender: um subsistema de comunicação (215) adaptado para comunicar-se com os dispositivos de comunicação móvel de recursos limitados (105)pela rede (110); uma aplicação (205) conectada ao subsistema de comunicação (215) e adaptado para receber solicitações individuais de conteúdo a partir de cada um dos dispositivos de comunicação móvel de recursos limitados (105), em que as solicitações contêm dispositivo de identificação de informação e, em resposta a uma solicitação individual de conteúdo de um dos dispositivos de comunicação móvel de recursos limitados (105), recuperar o conteúdo solicitado de um armazém de dados (200) , em que o conteúdo é selecionado e/ou modificado de acordo com o dispositivo de identificação de informação, e em que o conteúdo é armazenado no armazém de dados (200) na forma de Linguagem de Marcação Extensível, XML, e Gráficos Vetoriais Escaláveis, SVG; e um conversor (210) conectado à aplicação (205) e adaptado para converter o conteúdo solicitado no formato SVG, em resposta à solicitação individual por conteúdo, em um formato binário para compilar o conteúdo solicitado em formato SVG usando um compilador SVG (310) e adicionar um cabeçalho a saída do compilador, em que o subsistema de comunicação (215) é ainda adaptado para enviar o conteúdo em formato binário à solicitação dos dispositivos de comunicação móvel de recursos limitados (105), em que o conteúdo em formato binário compreende elementos visuais (610) representados por um gráfico visual (700) e por elementos comportamentais (620) representados por um gráfico de sequência (800) serem para transformar separadamente pela solicitação dos dispositivos de comunicação móvel de recursos limitados (105), em que uma versão do conteúdo solicitado no formato binário sem cabeçalho como é, existe no dispositivo de comunicação móvel (105) e como é visto por um transformador (515) no dispositivo de comunicação móvel de recursos limitados (105) .

2. Sistema provedor de conteúdo (125), de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender: um seletor de recurso adaptado para receber informação de dispositivo de identificação e, em resposta às solicitações por conteúdo, dirigir a aplicação (205) para fornecer o conteúdo solicitado, com base na informação do dispositivo, que é mais de acordo com os recursos disponíveis do dispositivo dos respectivos dispositivos de comunicação móvel de recursos limitados (105).

3. Sistema provedor de conteúdo (125), de acordo com a reivindicação 2, caracterizado pelo fato de o seletor de recurso ser adaptado para organizar o conteúdo com base nos recursos do dispositivo utilizando regras com base em padrão que compreendem pelo menos um entre organizar por conteúdo e ordenar por dispositivo, organizar por dispositivo e ordenar por conteúdo, e organizar por convenção de nome.

4. Sistema provedor de conteúdo (125), de acordo com a reivindicação 2, caracterizado pelo fato de o seletor de recurso ser utilizado com uma estratégia de emprego de redirecionamento.

5. Sistema provedor de conteúdo (125), de acordo com a reivindicação 2, caracterizado pelo fato de o seletor de recurso ser utilizado com uma estratégia de emprego de re-escrita.

6. Sistema provedor de conteúdo (125), de acordo com a reivindicação 1, caracterizado pelo fato de cada uma das solicitações por conteúdo compreender um identificador singular associado a um respectivo um dos dispositivos de comunicação móvel de recursos limitados (105).

7. Sistema provedor de conteúdo (125), de acordo com a reivindicação 6, caracterizado pelo fato de a aplicação (205) ser adaptada para utilizar o identificador singular associado a um respectivo um dos dispositivos de comunicação móvel de recursos limitados (105) para personalizar o conteúdo solicitado enviado para o respectivo um dos dispositivos de comunicação móvel de recursos limitados (105).

8. Sistema provedor de conteúdo (125), de acordo com a reivindicação 6, caracterizado pelo fato de a aplicação (205) ser adaptada para utilizar o identificador singular associado ao respectivo um dos dispositivos de comunicação móvel de recursos limitados (105) para fornecer acesso à Internet ao respectivo um dos dispositivos de comunicação móvel de recursos limitados (105).

9. Sistema provedor de conteúdo (125), de acordo com a reivindicação 1, caracterizado pelo fato de o armazém de dados (200) compreender pelo menos um entre o armazém de dados local e um armazém de dados externo.

10. Sistema provedor de conteúdo (1), de acordo com a reivindicação 1, caracterizado pelo fato de o conversor (210) compreender: uma leitura para ler o conteúdo em formato XML e SVG solicitado do armazém de dados (200) e gerar modelos objeto do documento SVG do conteúdo solicitado; um compilador para converter os modelos objetos do documento SVG em modelos objetos no formato binário; e um redator para escrever os modelos objeto de formato binário dentro de arquivos de formato binário por adicionar um cabeçalho para os modelos objetos no formato binário e em que os arquivos no formato binário são fornecidos para o subsistema de comunicação (215) para envio aos dispositivos de comunicação móvel de recursos limitados (105).

11. Sistema provedor de conteúdo (125), de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender: um navegador de conteúdo para gerar uma página de navegador de um sistema de arquivo e para fornecer a página de navegador como o conteúdo solicitado em resposta a uma solicitação por conteúdo para o sistema de arquivo; em que o navegador de conteúdo é adaptado para gerar a página de navegador em um formato XML e SVG e para fornecer a página de navegador ao conversor (210) para convertê-lo no formato binário em resposta à solicitação por conteúdo para o sistema de arquivo.