BRPI0517352B1

BRPI0517352B1 - método, sistema compreendendo um dispositivo e um servidor web acoplados por meio de uma conexão sem fio, dispositivo e aparelho

Info

Publication number: BRPI0517352B1
Application number: BRPI0517352A
Authority: BR
Inventors: Mittal Gaurav; Ypya Tapio
Original assignee: Nokia Corp; Nokia Technologies Oy
Priority date: 2004-08-20
Filing date: 2005-08-18
Publication date: 2018-11-06
Also published as: KR20070039173A; EP1779594B1; KR100898522B1; BRPI0517352A8; US20060039561A1; WO2006018707A1; CN101032121A; HK1106090A1; CN101032121B; US7889869B2; CA2577638A1; JP4546528B2; CA2577638C; JP2008511049A; EP1779594A1; BRPI0517352A

Abstract

método, sistema e produto de programa de computador para automatizar uma sessão do dispositivo em combinação com a interação do usuário e o servidor, método, servidor de gerenciamento do dispositivo e gerente de fluxo de trabalho para operar um dispositivo para baixar a informação através da rede sem fio. o método inclui, em resposta à recepção de um certo tipo de mensagem de pedido http do dispositivo durante a sessão de navegação, enviar uma mensagem de resposta http para o dispositivo. a mensagem de resposta http compreendendo o tipo-mime dedicado para indicar que a sessão de gerenciamento do dispositivo está sendo iniciada, e a sessão de gerenciamento do dispositivo é identificada por um identificador que compreende parte da mensagem de resposta http. o dispositivo responde à mensagem de resposta http com a resposta da sessão de gerenciamento do dispositivo que compreende os detalhes do dispositivo e o identificador. ao usar os detalhes do dispositivo, o sistema desenvolve uma lista contendo ao menos uma opção de transferência que é compatível com o dispositivo e envia a lista para o dispositivo. em resposta à seleção do usuário selecionar ao menos uma opção de transferência da lista, o sistema entrega ao menos uma opção de transferência selecionada para o dispositivo durante a sessão de gerenciamento do dispositivo.

Description

(54) Título: MÉTODO, SISTEMA COMPREENDENDO UM DISPOSITIVO E UM SERVIDOR WEB ACOPLADOS POR MEIO DE UMA CONEXÃO SEM FIO, DISPOSITIVO E APARELHO (51) IntCI.: H04L 12/24; H04L 29/08; H04M 3/42; H04M 7/00; H04W 80/00.

(52) CPC: H04L 41/0253; H04L 67/02; H04L 67/34; H04M 3/42178; H04M 7/006; (...).

(30) Prioridade Unionista: 20/08/2004 US 10/923,439.

(73) Titular(es): NOKIA TECHNOLOGIES OY.

(72) lnventor(es): TAPIO YPYA; GAURAV MITTAL.

(86) Pedido PCT: PCT IB2005002448 de 18/08/2005 (87) Publicação PCT: WO 2006/018707 de 23/02/2006 (85) Data do Início da Fase Nacional: 23/03/2007 (57) Resumo: MÉTODO, SISTEMA E PRODUTO DE PROGRAMA DE COMPUTADOR PARA AUTOMATIZAR UMA SESSÃO DO DISPOSITIVO EM COMBINAÇÃO COM A INTERAÇÃO DO USUÁRIO E O SERVIDOR, MÉTODO, SERVIDOR DE GERENCIAMENTO DO DISPOSITIVO E GERENTE DE FLUXO DE TRABALHO PARA OPERAR UM DISPOSITIVO PARA BAIXAR A INFORMAÇÃO ATRAVÉS DA REDE SEM FIO. O método inclui, em resposta à recepção de um certo tipo de mensagem de pedido HTTP do dispositivo durante a sessão de navegação, enviar uma mensagem de resposta HTTP para o dispositivo. A mensagem de resposta HTTP compreendendo o tipo-MIME dedicado para indicar que a sessão de gerenciamento do dispositivo está sendo iniciada, e a sessão de gerenciamento do dispositivo é identificada por um identificador que compreende parte da mensagem de resposta HTTP. O dispositivo responde à mensagem de resposta HTTP com a resposta da sessão de gerenciamento do dispositivo que compreende os detalhes do dispositivo e o identificador. Ao usar os detalhes do dispositivo, o sistema desenvolve uma lista contendo ao menos uma opção de transferência que é compatível com o dispositivo e envia a lista para o dispositivo. Em resposta à seleção do usuário selecionar ao menos uma opção de transferência da lista, o sistema entrega ao menos (...).

/25

MÉTODO, SISTEMA COMPREENDENDO UM DISPOSITIVO E UM SERVIDOR WEB ACOPLADOS POR MEIO DE UMA CONEXÃO SEM FIO, DISPOSITIVO E APARELHO

Campo da Invenção

Esta invenção geralmente relaciona aos dispositivos de comunicação móveis e métodos e, mais especificamente, relaciona à entrega de conteúdo, aos navegadores de rede e ao software do dispositivo na entrega aérea usada com os terminais de comunicação sem fio e aplicativos.

IO

Descrição da Técnica Anterior

À medida que a quantia e a complexidade do software nos dispositivos de comunicaççao móvel aumenta, há uma necessidade crescente pelos fabricantes, provedores de serviço e desenvolvedores de software em manter a configuração do 15 dispositivo móvel e seus componentes de software depois da fase industrial. Por exemplo, ao vender o conteúdo das aplicações adicionadas ou comercial para os usuários dos dispositivos móveis requer a verificação da compatibilidade e o gerenciamente faz dependências relaciondas aos módulos de software. Ao prover um perfil genérico ou informação modelo do dispositivo pode ser suficiente para uma 20 entrega de conteúdo relativamente simples (por exemplo, tal como baixar música), para as instaçãoes de aplicação e particularmente para as atualizações de firmware (suporte lógico inalterável) é essencial obter a informação detalhada do dispositivo móvel para corretamente selecionar as versões de entrega e os pacotes de transferência. Em muitos casos, porém, estes detalhes importantes não são 25 conhecidos do usuário, e/ou não são visíveis para o usuário pela interface do usuário.

A aliança Móvel Aberta (OMA) unificou um grupo de peritos de serviço para cumprir as necessidades de gerenciamento do dispositivo e baixar produtos digitiais. Porém, muitos dos padrões são totalmente focalizados no 30

Petição 870180072983, de 20/08/2018, pág. 14/22

2/25

	domínio móvel, e então a integração deles como componentes arquitetônicos em
V	uma entidade do sistema de entrega digital mais genérica não é direta. Em vários casos o uso de entrega digital para os dispositivos móveis é orientado ao comércio eletrônico. Como tal, em adição às tarefas de
5	gerenciamento do dispositivo a nível técnico há vários aspectos a nível do usuário, tal como a criação de demanda, navegação de menu, seleção, compromisso e pagamento. A escolha da tecnologia natural, e o método de fato atual para implementar a interface do usuário, é através das tecnologias de rede, particularmente navegação HTTP e aplicações de rede. Assim, qualquer tentativa
•	para endereçar os problemas discutidos acima deveria idealmente ser compatível e inter-operar com as tecnologias relacionadas a rede existentes e futuras, incluindo os navegadores de rede. Referência geral com respeito a atualização do usuário pode ser feita às Patentes US a seguir, todas de Richard R. Reisman: 5,694,546, Sistema para
15	Transporte da Informação Eletrônica Automática Não Atendida Entre o Servidor e o Cliente por um Vendedor Proporcionado com o Software de Transporte com uma Lista de Manifesto”; 6,125,388, Sistema para Transportar Objetos de Informação Entre uma Estação do Usuário e Múltiplas Fontes Remotas Baseadas no Manifesto do Objeto Modificável do Usuário Armazenado na Estação do
20 •	Usuário”; 6,594,692 B1, Métodos para Transação de Comércio Eletrônico”; e 6,658,464 B2, “Software da Estação do Usuário que Controla Transporte, Armazenamento, e a Apresentação do Conteúdo de uma Fonte Remota. Resumo da Invenção 0 precedente e outros problemas são solucionados, e outras
25	vantagens são percebidas, de acordo com as incorporações agora preferidas destes ensinamentos.

Em um aspecto esta invenção provê um método e um sistema para automatizar uma sessão do dispositivo em combinação com a interação do usuário com um servidor. O método inclui, em resposta à recepção de um certo tipo de 30 mensagem de pedido HTTP do dispositivo durante a sessão de navegação, enviar

3/25 uma mensagem de resposta HTTP ao dispositivo. A mensagem de resposta HTTP inclui o tipo-MIME dedicado para indicar que a sessão de gerenciamento do dispositivo está sendo iniciada, e a sessão de gerenciamento do dispositivo é identificada por um identificador que forma parte da mensagem de resposta HTTP.

O dispositivo responde à mensagem de resposta de HTTP com a resposta da sessão de gerenciamento do dispositivo que inclui os detalhes do dispositivo e o identificador. Ao usar os detalhes do dispositivo, o sistema desenvolve uma lista que contém ao menos a opção de transferência que é compatível com o dispositivo e envia a lista ao usuário. Em resposta ao usuário que seleciona ao

menos uma opção de transferência da lista, o sistema entrega ao menos uma opção de transferência ao dispositivo durante a sessão de gerenciamento do dispositivo.

Em outro aspecto esta invenção provê um método para operar um dispositivo para baixar a informação através da rede sem fio, e um dispositivo possuindo um controlador que opera de acordo com o método. O método inclui, durante uma sessão HTTP sem fio, fazer uma consulta com o dispositivo com respeito à informação transferível; em resposta à consulta, iniciar o diálogo sem fio seguro de gerenciamento do dispositivo com o dispositivo para obter os descritivos dos parâmetros específicos do dispositivo de ao menos certas capacidades do 20 dispositivo; gerar uma lista e enviar a lista ao dispositivo, a lista compreendendo ao menos uma entrada que é o descritivo da informação transferível que é compatível com as capacidades do dispositivo; e durante a sessão HTTP sem fio, selecionar ao menos uma entrada da lista a ser transferida para o dispositivo.

Em um aspecto adicional desta invenção é provido um servidor de gerenciamento do dispositivo que é operável com o dispositivo para baixar a informação através da rede sem fio para o dispositivo. O servidor de gerenciamento do dispositivo inclui uma primeira interface para acoplar ao dispositivo, uma segunda interface para acoplar o gerente de fluxo de trabalho e um controlador que opera com o programa para executar as operações que são iniciadas em resposta ao dispositivo, durante a sessão HTTP sem fio, realizar a

4/25

w	consulta com relação à informação transferíveL 0 servidor de gerenciamento do dispositivo é também responsável ao gerente de fluxo de trabalho que inicia a sessão sem fio segura de gerenciamento do dispositivo com o dispositivo para obter os descritivos dos parâmetros específicos do dispositivo de pelo menos
5	certas capacidades do dispositivo; cooperar com o gerente de fluxo de trabalho através da segunda interface para gerar uma lista e enviar a lista para o dispositivo através da primeira interface, onde a lista contém ao menos uma entrada que é descritiva da informação transferível que é compatível com as capacidades do dispositivo; e durante a sessão de HTTP sem fio, baixar a informação para o
·'	dispositivo correspondendo a pelo menos uma entrada da lista selecionada pelo usuário do dispositivo. Em um ainda outro aspecto desta invenção é proporcionado um gerente de fluxo de trabalho operável com o dispositivo e com o servidor de gerenciamento do dispositivo para baixar a informação através da rede sem fio
15	para o dispositivo. 0 gerente de fluxo de trabalho inclui a primeira interface para acoplar ao dispositivo através de um local de rede e ao servidor de gerenciamento do dispositivo, a segunda interface para acoplar ao menos um sistema auxiliar, e um controlador que opera com um programa para executar as operações iniciadas em resposta ao dispositivo, durante a sessão HTTP sem fio, realizando uma
20 •	consulta ao local de rede com relação à informação transferível. 0 gerente de fluxo de trabalho inicia uma sessão sem fio segura de gerenciamento do dispositivo com o dispositivo para obter os descritivos dos parâmetros específicos do dispositivo de ao menos certas capacidades do dispositivo; e coopera com o servidor de gerenciamento do dispositivo através da primeira interface e com ao menos um
25	sistema auxiliar através da segunda interface para gerar a lista que é descritiva da informação transferível que é compatível com as capacidades do dispositivo. 0 gerente de fluxo de trabalho também opera para enviar a lista para o dispositivo através da primeira interface e pelo servidor de rede. Breve Descrição das Fiquras
30	Os precedentes e outros aspectos dos ensinamentos de acordo com

5/25 esta invenção se tornam mais evidentes da Descrição Detalhada das Incorporações Preferidas a seguir, quando lida em conjunto com as Figuras apensas, onde:

Figura 1 - é um diagrama seqüencial de nível lógico de uma seqüência típica para entrega digital como parte do caso de uso orientado ao comércio eletrônico;

Figura 2 - é um diagrama seqüencial do fluxo da mensagem para o caso exemplar de uma atualização firmware que ocorre com o dispositivo de acordo com as incorporações preferidas da invenção;

Figura 3 - é um diagrama em blocos de um dispositivo adequado para uso na seqüência do fluxo da mensagem da Figura 2;

Figura 4 - é um diagrama em blocos de um servidor DM adequado para uso na seqüência do fluxo da mensagem da Figura 2;

Figura 5 - é um diagrama em blocos de um gerente de fluxo de 15 trabalho adequado para uso na seqüência do fluxo de mensagem da Figura 2;

Figura 6 - apresenta um exemplo não-limitativo da estrutura da mensagem de Resposta HTTP que carrega a mensagem de notificação do Gerenciamento do Dispositivo de acordo com um aspecto dos ensinamentos desta invenção; e

Figura 7 - apresenta um exemplo não-limitativo da estrutura da mensagem de notificação de Gerenciamento do Dispositivo que é carregada pela mensagem de Resposta HTTP da Figura 6.

Descrição Detalhada das Incorporações Preferidas

Exemplos dos documentos que são descritivos das tecnologias atuais relacionadas a rede de interesse para as incorporações agora preferidas desta invenção incluem: RFC 2616: Protocolo de Transferência de Hipertexto-HTTP/1.1, IETF, junho de 1999; RFC 2109: Mecanismo de Gerenciamento de Estado HTTP;

IETF, fevereiro de 1997; e Protocolo de Gerenciamento de Dispositivo SyncML,

Versão 1.1.2 (OMA-SyncML-DMProtocol-VI_L2-20030612-C), Aliança Móvel 30 Aberta, junho de 2003.

6/25

	Para assegurar uma experiência agradável do usuário durante uma
w	transação de entrega digital, os inventores tem percebido que o acumulo da informação detalhada a nível do dispositivo e os procedimentos de gerenciamento deveriam ser automatizados e integrados facilmente com a transação de entrega
5	digital. Nas incorporações preferidas desta invenção, um modelo é usado utilizando os peritos de serviço OMA, preferivelmente o Dispositivo de Gerenciamento OMA e a Transferência OMA, como sub-componentes integrados em uma transação de entrega digital baseada na navegação de rede. 0 uso das incorporações agora preferidas desta invenção é particularmente benéfico para o
10 •	caso de uso de atualização firmware, mas pode ser aplicado também para beneficiar outras aplicações de entrega digital. Para o propósito desta invenção “firmware pode ser considerado para incluir o código escrito do computador em uma linguagem de nível relativamente baixo que é diretamente ou indiretamente executável (por exemplo,
15	depois de ser rodado pelo compilador ou intérprete) pelo processador de dados que forma parte do dispositivo 10. Um exemplo de firmware, ou atualização firmware, poderia ser uma revisão, como exemplos não-limitativos, a um módulo do sistema operacional, uma implementação da pilha do protocolo http, ou uma melhoria ao acesso de rede sem fio e/ou a um procedimento de varredura
20 •	necessário, ou feito opcional devido, a uma mudança para um padrão de comunicações subjacente. Em contradição, uma aplicação pode ser considerada um programa de nível mais alto que dá uma nova, e possivelmente opcional, funcionalidade ao dispositivo 10, tal como um navegador Internet melhorado ou diferente, ou aparelho de mídia, ou um programa de captura de imagem que provê
25	o arquivo das imagens capturadas (assumindo que o dispositivo 10 inclui uma câmera digital) para alguns banco de dados de imagem fornecidos pela rede. Como pode ser apreciado, as particularidades de construção e operação do dispositivo 10, tal como o nível de revisão de seu software do sistema operacional, a quantia de memória instalada, o tipo (por exemplo, número modelo) de sua
30	câmera digital e outros tipos de parâmetros podem ter uma influência significante

7/25 no tipo e/ou nível de revisão nível do firmware ou software de aplicação que são carregados no dispositivo 10. Como mas um exemplo, o usuário pode desejar carregar firmware ou uma aplicação que são incompatíveis com o hardware do dispositivo 10, ou que requeira mais memória do que o dispositivo 10 tem 5 instalado, ou este assume uma versão do sistema operacional que foi liberada subseqüente a data de fabricação do dispositivo 10. Em quaisquer destes casos baixar simplesmente o firmware solicitado pelo usuário ou aplicação poderia criar problemas significantes para o usuário, e uma menor experiência ótima do usuário com a rede local 30, que pode ser associada com o fabricante do dispositivo 10,

ou com o operador de rede com quem o usuário 1 tem uma assinatura. Um fator de motivação para esta invenção é evitar tais problemas, e ocasionando assim um impacto mínimo no usuário. É uma meta desejável proporcionar ao usuário uma ótima experiência para os tipos de operações interativo-usuário e não-interatívousuário (por exemplo, segundo plano).

Deveria ser apreciado que enquanto as incorporações desta invenção preferidas e exemplares discutidas abaixo são apresentadas na estrutura de quadro OMA, esta invenção não está limitada apenas ao uso com os peritos e tecnologia baseados em OMA.

Por meio da introdução, uma seqüência típica para entrega digital 20 como parte de um caso de uso orientado ao comércio eletrônico é ilustrado na ) Figura 1, na forma de um diagrama de seqüência de nível lógico. A Figura 1 apresenta o usuário final 1 associado com uma estação móvel (MS) 10, um servidor DM 20 e um servidor de rede 30. A sessão do usuário é assumida para existir entre o usuário final 1 e o servidor de rede 30, enquanto a sessão do 25 dispositivo existir entre a MS 10 e o servidor DM 20. A Figura 1 é útil ao explicar os problemas que surgem em uma sessão de entrega digital convencional para a MS

10, e assim ajuda a prover um melhor entendimento das melhorias providas pelas incorporações preferidas desta invenção.

Deveria ser observado que os ensinamentos desta invenção são aplicáveis às várias tecnologias de interface do usuário, mas não são limitado

8/25

apenas às tecnologias de interface de rede. Como exemplos não limitativos, os ensinamentos desta invenção também são aplicáveis às tecnologias do Protocolo de Aplicação Sem fio (WAP), e as aplicações baseadas em JAVA™.

Com relação à Figura 1, pode ser assumido que como o resultado próspero de marketing bem sucedido e de acordo com a informação de enlace de rede, o usuário 1 tem chegado no site de rede 30 que tem itens transferíveis disponíveis para as estações móveis. Esta interação é apresentada como a navegação genérica 40. Para assegurar que as alternativas apresentadas para o usuária 1 sejam realmente compatíveis e funcionais na MS 10 do usuário, o

sistema do lado do servidor necessita conhecer as capacidades da MS 10. Um procedimento manual convencional para realizar isto seria restringir o espectro de discrepâncias dos produtos digitais de acordo com uma faixa de modelos MS 10 e, como um ponto inicial para a interação do usuário, indicando ao usuário 1 o modelo de informações MS 10. Porém, há inúmeras desvantagens inerentes nesta 15 aproximação convencional. Como alguns exemplos, e primeiro, esta aproximação pode resultar em uma experiência ruim do usuário, uma vez que o usuário 1 é indicado para executar uma tarefa de entrada de dados mundana. Mais adiante, a menos que as instruções para o usuário estejam perfeitamente claras, o usuário 1 pode abandonar o servidor de rede 30 e ir a outro lugar para a entrega digital desejada. Segundo, a confiabilidade da informação pode ser compromissada ao requerer ao usuário 1 para entrar com a informação. Como pode ser apreciado, em alguns casos a legitimidade da informação do dispositivo é muito crítica para uma entrega próspera (e particularmente para uma ativação próspera de uma aplicação entregue ou firmware). Terceiro, e relacionado aos primeiros dois assuntos, a complexidade da informação requerida pode ser tal que o usuário 1 não conhece a informação, e pode não ser capaz de recuperar esta usando a interface do usuário convencional da MS 10.

Além da sessão do usuário 40, uma sessão do dispositivo separado é usada para colher uma informação suficiente do dispositivo para criar um menu de itens dos transferíveis alternativos para o usuário 1. Este menu pode

9/25 apresentado em uma sessão do usuário baseada na rede 44, onde o usuário 1 pode navegar pelo menu, ler a informação adicional, selecionar e restabelecer a entrega. Finalmente, e de acordo com a seleção do usuário 1, a entrega e as tarefas de gerenciamento do dispositivo relacionadas são concluídas através da 5 segunda sessão do dispositivo 46.

Os inventores perceberam que o problema que surge no cenário exemplar descrita na Figura 1 é como combinar melhor duas sessões diferentes (sessão do usuário e sessão do dispositivo) e transferir os dados entre eles. Por exemplo, após o usuário 1 ter chegado no servidor de rede 30 usando um ío navegador de rede, e deseja que uma lista de itens pertinentes seja mostrada, qual a melhor forma para começar a sessão de gerenciamento do dispositivo OMA para obter a capacidade do dispositivo (MS 10) e a informação de compatibilidade? Mais adiante, e assumindo que este acumulo de informação automático pode ser concluído, qual a melhor técnica para devolver os resultados 15 na sessão de rede para o navegador do usuário? Em outras palavras, qual é a maneira mais oportuna na qual integrar ou auto-carregar uma sessão DM OMA com a sessão de navegação da rede do usuário?

Para obter uma compreensão mais completa dos problemas subjacentes que são inerentes, prover um navegador do usuário integrado e uma 20 sessão DM OMA, uma breve discussão é agora fornecida para alguns dos fundamentos básicos pertinentes das tecnologias de rede (no contexto HTTP), e também no gerenciamento do dispositivo OMA.

HTTP é o protocolo de rede simples e poderoso de rede. Normalmente é implementado no topo do soquete do Protocolo de Controle de 25 Transporte/Protocolo Internet (TCP/IP) para transferir recursos (arquivos, saída de aplicação) de um servidor HTTP (normalmente um servidor de rede) para o cliente HTTP (tal como o navegador de rede).

Originalmente, o conceito de uma sessão de rede não existiu no HTTP, uma vez que o HTTP é um protocolo sem conexão; i.e., tem duas 30 mensagens, pedido e resposta, e inclui métodos alternativos: OBTER, POSTAR e

10/25

CABEÇA. No senso original, a sessão HTTP inicia quando a mensagem de pedido é enviada, e a sessão HTTP termina quando a mensagem de resposta é recebida.

No princípio, a sessão TCP/IP subjacente era fechada após cada par de mensagens de pedido-resposta. Porém, como a tecnologia de rede progrediu e tornou-se amplamente usada, o tamanho e a complexidade das páginas de rede aumentaram drasticamente, enquanto conduzindo às páginas de redes típicas vistas atualmente com dez ou centenas de recursos HTTP separados (como ícones GIF de iluminação, bandeiras malditas, e anúncios de esboços animados).

Como resultado deste aumento na complexidade da página de rede HTTP, a despesa do recurso de computação, para o cliente e para o servidor, abrir e fechar um soquete TCP/IP dedicado para cada pedido HTTP ficaram muito grandes. Em resposta, especialistas de protocolo padronizaram (no HTTP 1.1), uma técnica para usar uma conexão TCP/IP persistente. Porém, mesmo com o soquete TCP/IP persistente no lugar não é possível ao servidor enviar uma mensagem de resposta para o cliente sem uma mensagem de pedido HTTP precedendo. Indicado de outro modo, o servidor de rede não pode empurrar a informação para o navegador (ver RPC 2616: Protocolo de Transferência de H?ipertexto-HTTP/1.1, IETF, junho de 1999).

Apesar da orientação sem conexão HTTP, a necessidade para ) sessões de rede tem se tornado rapidamente aparente à medida que mais aplicações de rede aparecem. O mecanismo de gerenciamento de estado HTTP (ver RFC 2109: Mecanismo de Gerenciamento de Estado HTTP; IETF, fevereiro de 1997) proporciona ao fomentador da aplicação de rede, características no topo do HTTP para combinar várias mensagens HTTP em uma sessão específica do usuário. A implementação inclui cookies que carregam a informação relacionada ao usuário e a sessão em todas as mensagens do cliente para o servidor. O servidor tipicamente codifica o cookie para impedir um cliente fraudulento de mexer no seu conteúdo.

Retornando agora ao DM OMA, e como o nome todo OMA DM

Ι·.; <·,

11/25 indica, o Protocolo de Gerenciamento do Dispositivo SyncML utiliza SyncML no domínio de do gerenciamento do dispositivo. Este é um protocolo de clíente servidor para implementação em um cliente DM e em um servidor DM.

O cliente DM inclui uma árvore de gerenciamento que é uma estrutura de dados em formato de árvore contendo objetos gerenciáveis. Para executar as tarefas requeridas de gerenciamento do dispositivo, o servidor DM servidor usa os comandos tal como Obter, Substituir e Executar que são alvos para os objetos na árvore de gerenciamento.

DM OMA é aperfeiçoado para interações entre o servidor e o dispositivo, tal como a MS 10 da Figura 1. Para as interações do usuário há comandos simples para implementar as características, tal como as notificações e as escolhas do usuário, mas em geral as capacidades da interface do usuário do

DM OMA são muito limitadas.

estabelecida o

Antes da sessão de gerenciamento do dispositivo OMA ser dispositivo deveria ser auto-carregado. O Protocolo de

Gerenctamento do Dispositivo SyncML padrão define dois métodos de auto carregamento:

(a)

Auto-carregamento customizado onde os dispositivos são

B carregados com a informação de auto-carregamento SyncML DM na fabricação (também referenciado como auto-carregamento de fábrica); e (b) Auto-carregamento iniciado pelo Servidor, onde o servidor envia a informação de auto-carregamento por algum mecanismo de empurrão, por exemplo WAP Push ou OBEX. Neste método, o servidor deve ser informado anteríormente do endereço/número do telefone do dispositivo. Durante o procedimento de auto-carregamento, os vários parâmetros são fixos no dispositivo, incluindo o endereço do servidor e a identificação, como também a informação de autenticação relacionada ao cliente e ao servidor. Enquanto as incorporações agora preferidas desta invenção preferirem usar o procedimento de autocarregamento de fábrica, o procedimento de auto-carregamento iniciado no servidor também pode ser usado.

12/25

Tendo descrito os ambientes HTTP e DM OMA que são muito germanos para as incorporações desta invenção atualmente preferidas (mas nãolimitativas), uma descrição é provida agora das incorporações agora preferidas dos métodos e aparelhos de acordo com esta invenção.

Aspectos salientes desta invenção incluem o uso de um tipo-MIME dedicado em uma mensagem de resposta HTTP para lançar a sessão DM OMA e enviar os parâmetros de auto-carregamento para o dispositivo; a cifragem com uma chave secreta da informação de Auto-carregamento na mensagem de aprovísionamento do cliente (uma notificação pode ser usada em vez do autocarregamento); e o uso de uma sessão de entrega digital da camada superior e sua identificação para combinar uma sessão de rede e as sessões do dispositivo em uma transação lógica global. Um aspecto adicional desta invenção relaciona a um procedimento para retornar o controle para a sessão de rede após a sessão do dispositivo pelo uso de um pedido de HTTP enfileirado; o comando Exec DM OMA para um objeto do navegador de rede com um URL pré-definido; e uma resposta do usuário à uma indicação de ativação previamente enviada.

Mais especificamente, o que é incluído por este aspecto adicional da invenção é o seguinte:

1. Um pedido HTTP enfileirado

Como uma reação para a resposta HTTP (mensagem (g) da Figura 2, discutida abaixo), e além do estabelecimento da sessão (mensagem (h) da Figura 2, discutida abaixo), o dispositivo 10 cria um pedido HTTP para o servidor de 30. O servidor de rede 30 enfileira o pedido até este receber uma mensagem de opções do usuário (mensagem (o) da Figura 2, discutida abaixo), e então envia a resposta ao navegador 10B (mensagem (p) na Figura 2, discutida abaixo).

2. O Exec DM OMA

Após criar o menu (atividade (n) na Figura 2, discutida abaixo), o gerente de fluxo de trabalho 50 solicita ao servidor DM 20 para enviar o comando Exec para o dispositivo cliente DM 10A, e desta maneira solicita ao navegador de rede do dispositivo 10B ficar ativos e enviar o pedido HTTP para o servidor de rede

13/25

	30. 0 servidor de rede 30 responde a este pedido HTTP enviando as opções (mensagem (o) na Figura 2, discutida abaixo) para o navegador 10B na resposta HTTP (mensagem (p) na Figura 2, discutida abaixo). 3. Resposta do usuário à indicação de ativação
5	Como parte da resposta HTTP (mensagem (g) na Figura 2, discutida abaixo), existe também a informação da interface do usuário a ser apresentada no navegador de rede 10B. Esta atividade da interface do usuário inclui apresentar a indicação para o usuário (por exemplo por favor espera, a informação do dispositivo sendo acumulada) e o botão submeter (por exemplo, “ok). Quando o
	usuário aceita a informação (por exemplo, ao pressionar o botão ok), o navegador de rede 10B envia um pedido HTTP para o navegador de rede 30. Este pedido será controlado então como na alternativa 1 (como um pedido HTTP enfileirado). Em geral, MIME foi pretendido originalmente para estender o formato
15	de correio da Internet para permitir as mensagens textuais não-US-ASCIl, as mensagens não-textuais, os corpos da mensagem de múltiplas-partes e a informação não-US-ASCIl nos cabeçalhos da mensagem. Os RFCs a seguir definem MIME: RFC 2045: MIME Parte Um: Formato dos Corpos da Mensagem Internet; RFC 2046: MIME Parte Dois: Tipos de mídia; RFC 2047: MIME Parte
20 •	Três: Extensões do Cabeçalho de mensagem para Texto Não-ASCII; RFC 2048: MIME Parte Quatro: Procedimentos de Registro; e RFC 2049: MIME Parte Cinco: Critérios de Correspondência e Exemplos. Referência também pode ser obtida para o RFC 1341 (junho de 1992) que era obsoleto para o RFC 1521: MIME (Extensões de Correio Internet de Múltiplos Propósitos) Parte Um: Mecanismos
25	para Especificar e Descrever o Formato dos Corpos da Mensagem Internet (setembro de 1993); e RFC 1342: MIME (Extensões de Correio Internet de Múltiplos Propósitos) Parte Dois: Extensões do Cabeçalho da mensagem para texto Não-ASCII (setembro de 1993). Uma descrição do sistema é provida agora com respeito à
30	incorporação da Figura 2 que apresenta o sinal e fluxo da mensagem entre o

14/25 usuário 1, o dispositivo, tal como a MS 10 da Figura 1, o local de rede (ou servidor de rede) 30, o servidor DM 20, o gerente de fluxo de trabalho 50 acima mencionado e um ou mais partes dos sistemas auxiliares 60. As capacidades e as responsabilidades destes vários componentes que também podem se referir aqui como atores são descritas abaixo, seguido por uma descrição da seqüência de uso descrita na Figura 2.

Deveria ser observado que em uma incorporação preferida desta invenção, mas por nenhum meios de limitar a prática desta invenção, o enlace entre o dispositivo 10 e a rede local 30 é carregado ao menos parcialmente através do enlace sem fio, tal como um enlace RF celular, ou um enlace Bluetooth, ou um enlace para a rede de área local sem fio (WLAN), ou por um enlace óptico, possivelmente por um provedor de rede (por exemplo, um operador de rede celular, ou um operador hotspot WLAN) do dispositivo 10.

Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o usuário 1 é um ser humano que usa o dispositivo 10. O usuário 1 pode estar interessado nos produtos digitais (possivelmente comercial) disponíveis na rede, tal como conteúdo, aplicações e/ou atualizações firmware. O navegador de rede é a aplicação preferida para descobrir, selecionar e restabelecer a entrega de um produto digital. O usuário 1 necessariamente não possui o dispositivo 10.

Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o dispositivo 10 é ou inclui um componente móvel que tem um exemplo de uma implementação de aplicação do cliente DM OMA10A e um navegador de rede HTTP 1.1 complacente 10B. Para as atualizações firmware, o dispositivo 10 pode ter, como um exemplar e um exemplo não-limitativo, a capacidade Firmware Sobre o Ar (FOTA). O dispositivo 10 pode ser, como exemplos e incorporações não-limitativas, um telefone celular ou um telefone não-celular, ou um computador que tem uma interface sem fio (RF e/ou IR) com a rede de área local e/ou geograficamente distribuída (LAN e/ou WAN), ou assistente digital pessoal (PDA) tendo uma

15/25

4	interface sem fio (RF e/ou IR) com uma LAN e/ou WAN, ou qualquer aplicação de Internet adequada que permite ao usuário 1 operar o navegador para contatar o servidor de rede ou local 30. Este sendo o caso, o dispositivo 10 incluirá tipicamente um transceptor sem fio (RF ou óptico).
5	Referência é feita à Figura 3 para apresentar um exemplo nãolimitativo do diagrama em blocos do dispositivo 10 que são adequados para uso na seqüência do fluxo de mensagem da Figura 2. É assumido que o dispositivo 10 inclui um controlador 11, tal como um microprocessador que é acoplado a memória 12 que armazena, além do sistema operacional e outro software típico,
10 •	um software para implementar o cliente DM OMA 10A de acordo com esta invenção, como também o navegador de rede 10B. Também encontrado na memória 12 pode estar uma tabela do dispositivo 10C que armazena os detalhes do dispositivo (por exemplo, as capacidades de hardware, a versão do sistema operacional, a capacidade de memória) que foram carregados na fabricação, ou
15	quando o dispositivo foi primeiro ativado. É também fornecido uma interface de usuário (UI) 13, ou uma interface para um UI adequado. Em uma incorporação não-limitativa, a UI 13 inclui o visor do usuário (por exemplo, um visor LCD) 13A e um teclado ou mini-teclado 13B do dispositivo de entrada dos dados do usuário. O controlador 11 também é acoplado a um RF adequado ou a um transceptor óptico
20 •	14 para comunicação com o site de rede 30 e o Servidor DM 20, tipicamente através da rede/operador sem fio, tal como um operador de rede de telefone celular, ou uma rede LAN sem fio. Note que em uma incorporação cabeada do dispositivo 10, o transceptor 14 pode ser acoplado a um cabo elétrico ou óptico ou outra instalação elétrica.
25	Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o site de rede 30 contém ou é acoplado ao servidor de rede complacente com o HTTP 1.1, que implementa a interface do usuário (páginas HTML) para o usuário 1. O site de rede 30 tem preferivelmente uma Interface do Programa de Aplicação (API) para
30	implementar as aplicações de rede, e uma interface para outros componentes do

16/25 lado do servidor (por exemplo, 20, 50, 60).

Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o servidor DM 20 implementa a pilha de protocolo DM SyncML OMA, comunica com o cliente DM 5 10A no dispositivo 10, e tem interfaces com outros componentes do lado do servidor (30, 50, 60). Referência com respeito ao SyncML pode ser obtida, como exemplos, o Protocolo de Gerenciamento do Dispositivo SyncML, Versão 1.1.2 (OMA-SyncML-DMProtocol - VI_l_2-20030612-C, Aliança Móvel Aberta, junho de 2003, como também para Informação DTD do Dispositivo SyncML, versão 1.1,

fevereiro de 2002 (onde DTD representa a Definição do Tipo de Documento)).

Referência é feita a Figura 4 para apresentar um exemplo não limitativos de um diagrama em blocos do servidor DM 20 que é adequado para uso na seqüência do fluxo de mensagem da Figura 2. O servidor DM 20 é assumido para incluir um controlador 21, tal como um microprocessador que é acoplado a uma memória 21A que armazena, além do sistema operacional e outro software típico (SW), um software para implementar a pilha de protocolo DM SyncML OMA e um software para comunicar com o cliente DM OMA 10A do dispositivo 10. O servidor DM 20 inclui interfaces de entrada e saída (l/Os) 22A e 22B (que pode ser lógico e/ou físico l/Os) para comunicação com o dispositivo 10 e o gerente de fluxo 20 de trabalho 50. Note que ambas as interfaces l/O 22A, 22B podem ser embutidas ) como interfaces lógicas que comunicam por TCP/IP na Internet.

Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o gerente de fluxo de trabalho 50 mantém rasto do processo de entrega digital global, por exemplo, uma transação de atualização de firmware. O gerente de fluxo de trabalho 50 cria uma identificação única de transação (TID), usa o servidor de rede 30 e o servidor DM 20 como interfaces para o usuário 1 e o dispositivo 10, e combina as sessões de nível mais baixo individuais em uma transação lógica. O gerente de fluxo de trabalho 50 usa os serviços preferivelmente nos sistemas auxiliares 60 para completar certas tarefas específicas durante a transação com o dispositivo 10.

17/25

* <	Referência é feita a Figura 5 para apresentar um exemplo nãolimitativo de um diagrama em blocos do gerente de fluxo de trabalho 50 que é adequado ao uso na seqüência do fluxo de mensagem da Figura 2. 0 gerente de fluxo de trabalho 50 é assumido para incluir um controlador 51, tal como um
5	microprocessador que é acoplado a uma memória 51 IA que armazena além do sistema operacional e outro software típico (SW), um software para gerar o TID e gerenciar e correlatar as várias transações com o dispositivo 10 e outros componentes dos sistemas. O gerente de fluxo de trabalho 50 l/Os 52A e 52B (que pode ser l/Os lógico e/ou físico) para comunicação com o site de rede 30, o
10 •	servidor DM 20, e os servidores auxiliares e o sistema(s) 60. Como com o servidor DM 20, ambas as interfaces l/O 52A, 52B podem ser embutidas como interfaces lógicas que comunicam pelo TCP/IP na Internet. Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, os servidores
15	auxiliares e o sistemas 60 provêem os serviços para o gerente de fluxo de trabalho 50. Os serviços podem incluir, mas não estão restritos, aos serviços de segurança para autenticação, cifragem e assinaturas, os serviços relacionados ao dispositivo 10 tal como a informação de status legal e de garantia, como também os serviços detalhados de gerenciamento de produto, tal como a informação de
20 •	Gerenciamento de Dados do Produto (PDM). Para os propósitos de descrição das incorporações preferidas desta invenção, e não como uma limitação a prática desta invenção, o gerente de fluxo de trabalho 50 e os sistemas auxiliares 60 são controlados pela mesma entidade que controla o site de rede 30 e o servidor DM 20. Porém, esta não é uma
25	limitação a prática desta invenção, e um ou ambos destes componentes pode estar sob controle das terceiras partes. Por exemplo, um dos sistemas auxiliares 60 pode ser um autenticador de assinatura digital de terceira parte, ou um facilitador de pagamento digital de terceira parte. Referenciando ao diagrama de seqüência exemplar apresentado na
30	Figura 2, os passos a seguir são executados de acordo com as incorporações

18/25 desta invenção. No (a) o usuário 1 navega através dos sites de rede de competição e encontra as páginas de atualização firmware do vendedor desejado (FW). No (b) o usuário 1 clica o enlace na página de atualização FW para determinar que novas alternativas de atualização FW (se houver) estão disponíveis para o dispositivo 10. No (c) o site de rede 30 envia uma página ao usuário 1, pelo dispositivo 10, e a resposta HTTP é usada para informar o usuário 1 pelo dispositivo 10 que o acumulo da informação do dispositivo automatizado está a ponto de começar. Uma mensagem adequada pode ser: Esperar enquanto nós recuperamos o firmware solicitado para o seu telefone. No (d) o usuário 1 aceita, pela interface do usuário do dispositivo 10, o estabelecimento da sessão do dispositivo automatizado que resulta em um pedido HTTP sendo enviado do navegador 10B para o servidor de rede 30. No (e) o servidor de rede 30 informa o gerente de fluxo de trabalho 50 que há um pedido do usuário para iniciar a transação de atualização firmware (FWupdTransaction) e estabelecer uma sessão DM OMA. Em resposta, o gerente de fluxo de trabalho 50 cria uma nova transação com um TID único. No (f), e com a ajuda dos serviços auxiliares 60, o gerente de fluxo de trabalho 50 cria uma mensagem (CP) de aprovisionamento do cliente OMA adequada e sinaliza esta com a chave secreta. Uma mensagem INIT DM é enviada ao site de rede 30 com o CP codificado. No (g), e como parte da resposta HTTP, o site de rede 10 envia uma mensagem CP assinada, com o tipo-MIME dedicado ao gerenciamento do dispositivo OMA, para o dispositivo 10. O TID é embutido na mensagem de resposta HTTP. Baseado na informação do tipo-MIME e a mensagem CP assinada, no passo (h) o dispositivo 101 verifica a validade da informação de auto-carregamento DM, estabelece os parâmetros adequadamente, e lança a aplicação do cliente DM OMA 10A. No (i) o cliente DM OMA 10A estabelece uma sessão DM OMA e envia a informação detalha dispositivo 10 para o servidor DM 20. Estes detalhes do dispositivo podem ser armazenados na tabela 10C na memória 12 do dispositivo 10, e pode ter sido carregada na fabricação, ou quando o dispositivo foi ativado primeiro. Em todo caso, o usuário 1 não necessita estar atento das informações do dispositivo 10, uma vez que este passo (i)

19/25 preferivelmente ocorre automaticamente, e sem envolvimento do usuário 1. O TID é incluído preferivelmente como uma parte desta informação que é enviada de volta para o servidor DM 20. No (j) o servidor DM envia o TID e a informação do dispositivo recebida para o gerente de fluxo de trabalho 50, e no (k) o gerente de 5 fluxo de trabalho 50 comunica com os serviços auxiliares 60 para determinar se a quantia e o nível de detalhes da informação do dispositivo 10 é suficiente para criar uma lista de alternativas (um menu de opções de transferência firmware). Se há necessidade para informações mais detalhadas e específicas do dispositivo 10, no (1) o gerente de fluxo de trabalho 50 solicita ao servidor DM 20 para ir ίο buscar os dados pertinentes do dispositivo 10. Neste caso em (m), e ao usar o protocolo DM OMA, o servidor DM 20 obtém as informações adicionais do dispositivo 10 e envia esta de volta para o gerente de fluxo de trabalho 50. Em (n) o gerente de fluxo de trabalho 50 cria (ou usa um ou mais serviços auxiliares 60 para criar) uma lista de alternativas disponíveis, i.e., um menu de opções de 15 transferência firmware para o usuário final 1. Em (o) o gerente de fluxo de trabalho envia para o menu das opções de transferência firmware para o site de rede 30, e em (p) o site de rede 30 retorna o menu para o navegador 10B para o usuário 1 para selecionar os produtos ou solicitar mais informação (formalizada de rede). Isto pode ser realizado em (p) através de pelo menos três técnicas: um pedido 20 HTTP previamente enfileirado; um exec DM OMA para o objeto de rede; ou uma ação do usuário na página de rede previamente enviada. Pela técnica é usado em (p), uma navegação de rede adicional, envolvendo pedidos e respostas HTTP (usuário 1 através do dispositivo 10 com o site de rede 30), e uma eventual entrega do firmware solicitado e o gerenciamento do dispositivo (dispositivo 10 e 25 servidor DM 20), ocorre nos passos (q) e (r), respectiva mente. Note que qualquer tecnologia adequada e mecanismos podem ser usados para a transferência atual do firmware para o dispositivo 10.

Um aspecto para combinar uma sessão de rede com uma sessão

DM automatizada, de acordo com as incorporações desta invenção, envolve o 30 carregamento da mensagem de notificação DM OMA dentro da mensagem de

20/25 resposta HTTP (mensagem (g) na Figura 2). Referenciando à Figura 6, a mensagem de resposta HTTP geralmente contém um campo Linha de Status 102, um campo Cabeçalhos Gerais 104, um campo Cabeçalhos de Resposta 106, um campo Cabeçalhos da Entidade 108, um delimitador ou separador, apresentados como uma carruagem de alimentação de linha/retorno (CRLF) 109, e um campo Corpo da Mensagem 110. De maior interesse para as incorporações nãolimitativas desta invenção é o campo Cabeçalhos da Entidade 108, que contém um campo Tipo-Conteúdo 108A, um campo Comprimento-Conteúdo 108B e um campo Último-Modificado 108C. De interesse particular é o campo Tipo-Conteúdo 108A que carrega o tipo-MIME predeterminado acima mencionado. Como exemplos não-limitativos, o tipo-MIME predeterminado para uma mensagem Alerta de Sessão Iniciada de Notificação Geral pode ser o Tipo-Conteúdo 108A: “application/vnd.syncml.notification , e o código do Tipo-Conteúdo pode ser 0x44.

Na incorporação não-limitativa preferida atualmente da estrutura da mensagem de resposta HTTP ilustrada na Figura 6, a notificação DM OMA é carregada no campo Corpo-Mensagem 110.

O conteúdo exemplar da mensagem HTTP pode ser como a seguir: Response = Status-line (102 na Figura 6) * ((general-header (104 na Figura 6) |response-header (106 na Figura 6) |entity-header (108 na Figura 6)) CRLF) CRLF (109 na Figura 6) [mensagem-body] (110 na Figura 6) status-line = HTTP /1.1 <Space>status-code+reason-phrase status-code+reason-phrase = 200 <Space> OK |

400 <Space> Bad Request | // Pedido Ruim

404 < Space> Notfound| //Não encontrado

500 < Space> Internai Error Server| //Erro Interno do

Servidor

501 < Space> Not lmplemented| // Não Implementado

21/25 general-header=Date: <Space> date <CRLF>

Connection; < Space > close <CRLF>

response-header = Server: < Space> vendor-string <CRLF> entity-header = Content-Lenght: <Space> integer-greater-or-igual5 0<CRLF>

Content-type: < Space> text/html <CRLF>

Last-Modified: <Space> date <CRLF>

[Cache-Control: <Space> no-cache<CRLF>] // apenas para páginas dinâmicas [Expires: < Space> date <CRLF>] / / apenas para páginas dinâmicas message-body = / / os conteúdos dos documentos solicitados pelo cliente date = // formato de data de acordo com RFC822 e RFCI 123 vendor-string= // identificação do servidor // (livremente definido pelo implementador do servidor)

Os campos de uma incorporação exemplar da mensagem de notificação DM OMA 120 são mostrados na Figura 7, onde:

Campo digest 122 trigger-hdr 124, contendo:

version 124^a ui-mode 124B initiator 124C future-use 124D sessionid 124E lenght-identifier 124F server-identifier 124G

Descrição

Valor Digest MD5

Versão de Gerenciamento do Dispositivo não-especificado/interação do usuário Servidor/Usuário iniciado (cliente/servidor) Reservado para uso futuro DM Identificador de Sessão

Comprimento do Identificador de Sessão

Identificador do Servidor trigger body 126

Específico do Vendedor

Um exemplo não-limitativo da mensagem Detalhes do Dispositivo DM (mensagem (i) na Figura 2) é apresentado abaixo (referência pode ser feita

22/25

	novamente ao: Protocolo de Gerenciamento do Dispositivo SyncML, Versão 1.1.2 (OMA-SyncML-DMProtocol-VI_l_2-20030612-C), Aliança Móvel Aberta, junho de 2003): <SyncML xmlns='SYNCML:SYNCML1.1 '>
5	<SyncHdr> <VerDTD> 1.1 </VerDTD> <VerProto>DM/l .1 </VerProto> <SessionlD> 1 </SessionlD> <MsglD>K/MsglD>
•	<Target> <LocURI>http://XXXX/mgmt-server</LocURI> </T arget> <Source> <LocURI>IMEI:XXXX</LocURI>
15	</Source> <Cred> <!- Client credentials --> <Meta> <Type xmlns=syncml:metinf>syncml:auth-basic</Type> <Format xmlns-syncml:metinf>b64</Format>
20 •	</Meta> <Data> </Data> </Cred>
25	<Meta> <!-- Maximum message size for the client -> <MaxMsgSÍze xmlns=syncml:metinf'>5000</MaxMsgSize> </Meta> </SyncHdr> <SyncBody>
30	<Alert>

23/25

« *	<CmdlD>K/CmdlD> <Data>1200</Data> <! -- Server-initiated session — > <ltem></ltem> <ltem>
5	<Data>123 blah blah</Data> <! ~ one example of sending TID — > </ltem> </Alert> <Alert> <CmdlD>XXX</CmdlD>
•	<Data>TIDXXXX 123 blah blah </Data> <! - or alternative way of sending TID -> </Alert> <Replace> <CmdlD>3</CmdlD>
15	<ltem> <Source><LocURI>./Devlnfo/Devld</LocURI></Source> <Meta> <Format xmlns- syncml :metinf >chr</Format> <Type xmlns- syncml rmetinf >text/plain</Type>
20 •	</Meta> <Data>abc blah blah 123 blah blah</Data> </ltem> <ltem> <Source><LocURI>./Devlnfo/Man</LocURI></Source>
25	<Meta> <Format xmlns- syncml :metinf >chr</Format> <Type xmlns='syncml :metinf >text/plain</Type> </Meta> <Data>BEST MANUFACTURER lnc.</Data>

</ltem>

24/25

	<ltem>
	<Source><LocURI>./Devlnfo/Mod</LocURI></Source> <Meta> <Format xmlns- syncml :metinf >chr</Format>
5	<Type xmlns- syncml :metinf >text/plain</Type> </Meta> <Data>BEST PHONE 2004</Data> </ltem> <ltem>
10 •	<Source><LocU Rl>./Devl nfo/DmV</LocU Rlx/Source> <Meta> <Format xmlns- syncml:metinf>chr</Format> <Type xmlns- syncml :metinf >text/plain</Type> </Meta>
15	<Data>123 blah abc blah</Data> </ltem> <ltem> <Sou rce><LocU RI > ./Deví nfo/Lang</LocU Rl></Sou rce> <Meta>
20 •	<Format xmlns-syncml:metinf>chr</Format> <Type xmlns-syncml: metinf >text/plain</Type> </Meta> <Data>blah blah</Data> </ltem>
25	</Replace> <Final/> </SyncBody> </SyncML> A descrição precedente tem provido por meio de exemplos e
30	exemplares não-limitativos uma descrição completa e informativa do melhor

25/25 método e aparelho atualmente contemplados pelos inventores para executar a invenção. Porém, várias modificações e adaptações podem se tornar aparentes do técnico nas técnicas pertinentes devido à descrição precedente, quando lida em conjunto com os desenhos apensos e as reivindicações apensas. Como mas 5 alguns exemplos, o uso de outros cenários de transferência similares ou equivalentes, programas de aplicação e tecnologias de transferência de firmware (por exemplo, a transferência firmware pode usar outras que a tecnologia OMA FOTA), protocolos de tipos de mensagem e gerenciamento do dispositivo e os métodos podem ser tentados pelo técnico. Porém, todas as tais modificações e 10 similares dos ensinamentos desta invenção ainda estarão dentro do escopo desta invenção.

Além disso, algumas das características da presente invenção poderíam ser usadas de forma vantajosa sem o uso correspondente de outras características. Como tal, a descrição precedente deveria ser considerada como 15 meramente ilustrativa dos princípios da presente invenção, e não uma limitação desta.

1/6

Claims

REIVINDICAÇÕES

1. Um método, caracterizado por compreender:

transmitir determinado tipo de mensagem de requisição HTTP a partir de um dispositivo (10) durante uma sessão de navegação;

receber uma mensagem de resposta HTTP, tal mensagem compreendendo um tipo MIME dedicado indicando que uma sessão de gerenciamento de dispositivo está sendo iniciada, tal sessão sendo identificada por um identificador incorporado na mensagem de resposta HTTP, em que a sessão de navegação compreende a comunicação entre um servidor web (30) e um navegador web em execução no dispositivo (10), e a sessão de gerenciamento do dispositivo compreende a comunicação entre um servidor de gerenciamento de dispositivos (20) e um cliente de gerenciamento de dispositivos em execução no dispositivo;

em resposta ao recebimento da mensagem de resposta HTTP, enviar uma resposta de sessão de gerenciamento de dispositivo que compreende detalhes do dispositivo descritivos de pelo menos certos recursos do dispositivo e do identificador;

receber uma lista no dispositivo (10), tal lista compreendendo pelo menos uma opção de download que descreva informações para download que sejam compatíveis com as capacidades do dispositivo; e em resposta a um usuário (1) selecionando pelo menos uma opção de download da lista, receber informações para download descritas pela opção selecionada pelo menos uma opção de download no dispositivo durante uma sessão de gerenciamento de dispositivos.

2/6

2. Método de acordo com a reivindicação 1, caracterizado por a mensagem de resposta HTTP compreender uma mensagem de provisionamento de cliente (CP) criptografada.

3/6 para enviar a lista para o dispositivo (10) através do gerenciador de fluxo de trabalho (50); e em resposta a um usuário (1) selecionar pelo menos uma opção de download da lista, estando o referido servidor de gerenciamento de dispositivos (20) configurado para fornecer informações para download descritas pelas opções de download ao dispositivo (10) durante uma sessão de gerenciamento do dispositivo;

em que a sessão de navegação compreende a comunicação entre o servidor web (30) e um navegador web em execução no dispositivo (10), e a sessão de gerenciamento de dispositivos compreende a comunicação entre o servidor de gerenciamento de dispositivos (20) e o cliente de gerenciamento de dispositivos em execução no dispositivo (10).

3. Método de acordo com a reivindicação 2, caracterizado por determinado tipo de mensagem de solicitação HTTP acionar uma transação com um gerenciador de fluxo de trabalho que estabelece o identificador, em que o gerenciador de fluxo de trabalho cria a mensagem CP e a criptografa com uma chave secreta.

Petição 870180072983, de 20/08/2018, pág. 15/22

4/6

4. Método de acordo com a reivindicação 1, caracterizado por a lista ser recebida no dispositivo utilizando uma sessão de navegação.

5/6

5. Método de acordo com a reivindicação 1, caracterizado por o dispositivo (10) compreender uma unidade que possui um transceptor sem fio configurado para se comunicar com um servidor web (30) e onde as informações para download compreendem um programa aplicativo.

6/6 dispositivos com o dispositivo (10) para obter parâmetros específicos de dispositivo descritivos de pelo menos certas capacidades do dispositivo (10); cooperar com o servidor de gerenciamento de dispositivos (20) através da primeira interface, e com pelo menos um sistema back-end (60) através da segunda interface, para gerar uma lista; e enviar a lista para o dispositivo (10) através da primeira interface e através do servidor web (30), tal lista compreendendo pelo menos uma entrada que é descritiva de informações transferíveis que são compatíveis com as capacidades do dispositivo.

6. Método de acordo com a reivindicação 1, caracterizado por o dispositivo (10) compreender uma unidade que possui um transceptor sem fio configurado para se comunicar com um servidor web (30) e onde as informações para download fornecidas compreendem firmware.

7. Um sistema compreendendo um dispositivo (10) e um servidor web (30) acoplados por meio de uma conexão sem fio, e caracterizado por compreender ainda:

um servidor de gerenciamento de dispositivos (20), acoplado ao servidor web (30), o servidor web (30) estando configurado para enviar uma mensagem de resposta HTTP para o dispositivo (10) em resposta a determinado tipo de mensagem de solicitação HTTP sendo enviada a partir do dispositivo (10) durante uma sessão de navegação, tal mensagem de resposta HTTP compreendendo um tipo MIME dedicado indicando que uma sessão de gerenciamento de dispositivo está sendo iniciada e a sessão de gerenciamento de dispositivo sendo identificada por um identificador incorporado na mensagem de resposta HTTP;

o referido dispositivo (10), compreendendo um cliente de gerenciamento de dispositivo configurado para responder à mensagem de resposta HTTP com uma resposta de sessão de gerenciamento de dispositivo compreendendo detalhes do dispositivo e o identificador;

em que o servidor de gerenciamento de dispositivo (20) está configurado para utilizar detalhes do dispositivo descritivos de pelo menos certas capacidades do dispositivo, em cooperação com um gerenciador de fluxo de trabalho (50), para desenvolver uma lista contendo pelo menos uma opção de download descritiva de informações compatíveis com as capacidades do dispositivo e

Petição 870180072983, de 20/08/2018, pág. 16/22

8. Sistema de acordo com a reivindicação 7, caracterizado por a mensagem de resposta HTTP compreender uma mensagem de provisionamento de cliente (CP) criptografada.

9. Sistema de acordo com a reivindicação 8, caracterizado por compreender ainda o gerenciador de fluxo de trabalho (50) no qual o determinado tipo de mensagem de solicitação HTTP está configurado para disparar uma transação com o referido gerenciador de fluxo de trabalho (50) que está configurado para estabelecer o identificador, em que o gerenciador de fluxo de trabalho (50) está configurado para criar a mensagem CP e criptografá-la com uma chave secreta.

10. Sistema de acordo com a reivindicação 9, caracterizado por o referido gerenciador de fluxo de trabalho (50) compreender uma interface com pelo menos um sistema back-end, e onde a mensagem CP é criptografada em cooperação com pelo menos um sistema back-end.

11. Sistema de acordo com a reivindicação 7, caracterizado por a lista ser enviada para o dispositivo (10) utilizando uma sessão de navegação e protocolos HTTP.

Petição 870180072983, de 20/08/2018, pág. 17/22

12. Sistema de acordo com a reivindicação 7, caracterizado por o dispositivo (10) compreender um transceptor sem fio configurado para se comunicar com o servidor web (30), e onde as informações para download fornecidas compreendem um programa de aplicação.

13. Sistema de acordo com a reivindicação 7, caracterizado por o dispositivo (10) compreender um transceptor sem fio configurado para se comunicar com o servidor web (30), e onde as informações para download fornecidas compreendem firmware.

14. Sistema de acordo com a reivindicação 7, caracterizado por o dispositivo (10) compreender uma unidade de comunicações possuindo um transceptor sem fio configurado para se comunicar com o servidor web (30), e onde as informações de download compreendem um programa.

15. Um método, caracterizado por compreender:

durante uma sessão HTTP sem fio, receber uma consulta de um dispositivo (10) com relação a informações para download;

em resposta à inicialização, iniciar um diálogo sem fio de gerenciamento seguro de dispositivos com o dispositivo (10) para obter parâmetros específicos do dispositivo descritivos de pelo menos certas capacidades do dispositivo (10), em que o referido iniciador utiliza uma mensagem de resposta HTTP que compreende um tipo MIME predeterminado indicando que uma sessão de gerenciamento de dispositivos está sendo iniciada, a sessão de gerenciamento de dispositivos sendo identificada por um identificador incorporado na mensagem de resposta HTTP;

gerar uma lista e enviá-la para o dispositivo (10), tal lista compreendendo pelo menos uma entrada que descreve as informações de download que são compatíveis com as capacidades do dispositivo; e durante uma sessão HTTP sem fio, receber uma seleção de pelo menos uma entrada da lista; e, durante uma sessão de gerenciamento de dispositivos, transferir as informações de download para o dispositivo (10) correspondendo à pelo menos uma entrada selecionada.

Petição 870180072983, de 20/08/2018, pág. 18/22

16. Um dispositivo (10), caracterizado por compreender uma interface de usuário, e um controlador configurado para operar com um programa para executar operações, o referido controlador estando configurado para receber uma mensagem de resposta HTTP que compreende um tipo MIME predeterminado indicando que uma sessão de gerenciamento de dispositivo seguro está sendo iniciada, tal sessão de gerenciamento de dispositivos sendo identificada por um identificador incorporado na mensagem de resposta HTTP, as referidas operações compreendendo:

durante uma sessão HTTP sem fio envolvendo um usuário (1) e a interface de usuário, enviar uma consulta do dispositivo (10) com relação a informações para download;

em resposta ao recebimento da mensagem de resposta HTTP através de uma rede sem fio, estabelecer a sessão de gerenciamento de dispositivo seguro para enviar parâmetros específicos do dispositivo descritivos de pelo menos certas capacidades do dispositivo (10);

receber uma lista com pelo menos uma entrada que descreva informações para download compatíveis com as capacidades do dispositivo, selecionar, através da interface do usuário durante uma sessão HTTP sem fio, pelo menos uma entrada da lista; e receber informações para download correspondentes à pelo menos uma entrada selecionada da lista durante uma sessão de gerenciamento de dispositivos.

17. Um aparelho (50), caracterizado por compreender uma primeira interface, configurada para ser acoplada a um dispositivo (10) através de um servidor web (30) e a um servidor de gerenciamento de dispositivos (20), uma segunda interface, configurada para ser acoplada a pelo menos um sistema de back-end (60), e um controlador, configurado para operar com um programa para executar operações compreendendo:

em resposta ao recebimento de uma indicação de que o dispositivo (10) fez, durante uma sessão HTTP sem fio, uma consulta ao servidor web (30) com relação a informações transferíveis, iniciar, através da primeira interface via servidor web (30), uma sessão sem fio de gerenciamento seguro de

Petição 870180072983, de 20/08/2018, pág. 19/22

18. Aparelho de acordo com a reivindicação 17, caracterizado por o aparelho ser configurado para criar um identificador de transação e uma mensagem de provisionamento de cliente (CP) criptografada.

19. Aparelho de acordo com a reivindicação 18, caracterizado por o aparelho ser configurado para receber os parâmetros específicos do dispositivo e o identificador de transação.

Petição 870180072983, de 20/08/2018, pág.

20/22

WO 2006/018707

PCT/IB2005/002448