BRPI0914207B1

BRPI0914207B1 - Método de geração de um documento e cartão inteligente

Info

Publication number: BRPI0914207B1
Application number: BRPI0914207-0A
Authority: BR
Inventors: Christophe Foesser
Original assignee: Gemalto Sa
Priority date: 2008-06-20
Filing date: 2009-06-10
Publication date: 2020-08-11
Also published as: EP2291779A1; MX2010013373A; BRPI0914207A2; CN102067122A; EP2291779B1; CN102067122B; EP2136304A1; WO2009153205A1

Abstract

método de geração de um documento a partir de um servidor da web localizado em dispositivo eletrônico portátil. a invenção é um método de geração de um documento destinado a ser usado por um navegador em uma máquina cliente, que compreende um mecanismo de script. um dispositivo eletrônico portátil compreende um servidor da web e é conectado a uma máquina hospedeira. o método compreende as etapas de: a) estabelecimento de uma sessão de cliente-servidor entre a máquina cliente e o dispositivo eletrônico portátil; b) envio de primeiros dados do servidor da web para o navegador em resposta a uma primeira solicitação, os referidos primeiros dados compreendendo uma primeira parte executável destinada a ser interpretada pelo mecanismo de script; c) envio de uma segunda solicitação para o servidor da web, a referida segunda solicitação sendo gerada por meio do mecanismo de script e da primeira parte executável; d) geração, dinamicamente, de segundos dados no dispositivo eletrônico portátil em resposta à segunda solicitação; e) envio dos segundos dados do servidor da web para o navegador, os referidos segundos dados sendo interpretados pelo mecanismo de script para gerar uma parte do documento.

Description

Campo da Invenção

[0001] A presente invenção se refere a métodos de geração de documentos de HTML ou XML de um servidor da web localizado em um dispositivo eletrônico portátil. Ela se refere, particularmente, aos métodos de geração de documentos destinados a serem usados por um navegador da web em uma máquina cliente ligada a um dispositivo eletrônico portátil. Em particular, a presente invenção é bem adequada para servidores da web embutidos em cartões inteligentes.

Técnica Anterior

[0002] Dispositivos eletrônicos portáteis são objetos eletrônicos portáteis semelhantes a cartões inteligentes, dispositivos de áudio portáteis, handsets móveis, assistentes pessoais digitais ou tokens. Os dispositivos eletrônicos portáteis podem embutir um servidor da web que pode ser endereçado de uma máquina cliente conectada diretamente ao dispositivo eletrônico portátil. O servidor da web embutido também pode ser endereçado de uma máquina cliente remota, que é conectada ao dispositivo eletrônico portátil através de uma ou de diversas redes. Esse servidor da web proporciona serviços de acordo com as regras de consórcio da World Wide Web (W3C).

[0003] Um dispositivo eletrônico portátil pode ser conectado a uma máquina hospedeira através de um canal de contato ou de um canal sem contato. A maior parte das máquinas cliente existentes têm um navegador da web da Internete como o Microsoft Internet Explorer ® ou Mozilla Firefox ®. O navegador da web da máquina cliente pode atuar como um ator cliente, quando tentando carregar uma página de HTML do servidor da web do dispositivo eletrônico portátil conectado.

[0004] Um documento dinâmico é um documento cujo conteúdo não é fixo e deve ser construído dinamicamente. Um documento de HTML dinâmico tem conteúdo dinâmico. Atualmente, para carregar uma página de HTML dinâmica do servidor da web de um dispositivo eletrônico portátil, a página de HTML deve ser gerada no dispositivo eletrônico portátil. Uma solução orientada a texto para essa geração pode ser realizar uma análise de um documento pré-definido. Nesse caso, a geração corresponde a uma modificação de um documento pré-definido. A operação de análise é realizada através de busca, então, substituindo tags pré-definidos. Essa operação de análise requer conhecimento do número de cada espécie de dados a serem incluídos na página de HTML. Por exemplo, quando uma tabela está sendo preenchida, o número de fileiras deve ser conhecido como uma preliminar. Contudo, o número de fileiras pode ser desconhecido antes de gerar o documento de HTML, especialmente se o número de fileiras depende dos dados armazenados em um arquivo tendo um conteúdo variável.

[0005] Além disso, esse mecanismo de análise deve conhecer a relação de tags a serem buscados. Além disso, muitos dispositivos eletrônicos portáteis estão em conformidade com linguagens que não são orientadas a grupo. Em particular, uma porção de dispositivos eletrônicos portáteis do tipo cartão inteligente com padrão Javacard 2.x, que não suporta o tipo String. Desse modo, o tipo ByteArray deve ser usado, o qual é consumidor de recursos e leva a código de software complexo.

Sumário da Invenção

[0006] Um objetivo da invenção é resolver os problemas técnicos mencionados acima.

[0007] O objetivo da presente invenção é um método de geração de um documento destinado a ser usado por um navegador em uma máquina cliente. A máquina cliente compreende um mecanismo de script. Um dispositivo eletrônico portátil compreende um servidor da web. O método compreendendo as etapas de: - estabelecimento de uma sessão de cliente-servidor entre a máquina cliente e o dispositivo eletrônico portátil; - envio de uma primeira solicitação do navegador para o servidor da web; - envio dos primeiros dados do servidor da web para o navegador em resposta à primeira solicitação, os referidos primeiros dados compreendendo uma primeira parte executável destinada a ser interpretada pelo mecanismo de script; - envio de uma segunda solicitação do navegador para o servidor da web, a referida segunda solicitação sendo gerada por meio do mecanismo de script e da primeira parte executável; - geração de segundos dados dinamicamente no dispositivo eletrônico portátil em resposta à segunda solicitação; - envio dos segundos dados do servidor da web para o navegador, os referidos segundos dados sendo interpretados pelo mecanismo de script (SE) para gerar uma parte do documento.

[0008] Em uma modalidade preferida, o documento é um documento de HTML ou documento de XML.

[0009] Vantajosamente, o método pode compreender as etapas adicionais de: - envio de uma terceira solicitação do navegador para o servidor da web, a terceira solicitação sendo gerada por meio do mecanismo de script e dos segundos dados; - geração dos terceiros dados no dispositivo eletrônico portátil em resposta à terceira solicitação; - envio dos terceiros dados do servidor da web para o navegador, os referidos terceiros dados sendo interpretados pelo mecanismo de script para gerar uma parte do documento.

[0010] De modo alternativo, a terceira solicitação pode ser gerada por meio do mecanismo de script e da primeira parte executável.

[0011] Vantajosamente, os segundos dados podem compreender dados usados pelo mecanismo de script para gerar uma parte do documento.

[0012] Em uma primeira modalidade, o mecanismo de script é um mecanismo Javascript® e os primeiro e segundo dados são do tipo Javascript®.

[0013] Vantajosamente, os segundos dados são gerados por uma extensão de servidor.

[0014] Em uma modalidade preferida, a extensão de servidor é Javascript® servlet.

[0015] Outro objetivo da invenção é um dispositivo eletrônico portátil destinado a ser conectado a uma máquina hospedeira. O dispositivo eletrônico portátil é destinado a ser ligado a uma máquina cliente através de uma sessão de cliente-servidor. A máquina cliente compreende um navegador e um mecanismo de script. 0 dispositivo eletrônico portátil compreende um microprocessador, uma interface de comunicação, um sistema operacional, uma memória de trabalho e uma memória não volátil. 0 dispositivo eletrônico portátil também compreende um servidor da web, primeiros dados e primeiros meios capazes de enviar primeiros dados para o navegador em resposta a uma primeira solicitação recebida do referido navegador. Os primeiros dados compreendem uma primeira parte executável destinada a ser interpretada pelo mecanismo de script e o dispositivo eletrônico portátil compreende segundos meios capazes de gerar segundos dados, dinamicamente, em resposta a uma segunda solicitação recebida do navegador. Os segundos dados são usados pelo mecanismo de script para gerar uma parte de um documento destinado a ser usado pelo navegador.

[0016] Em uma modalidade preferida, o documento é um documento de HTML ou documento XML.

[0017] Vantajosamente, os referidos segundos dados podem compreender dados usados pelo mecanismo de script para gerar uma parte do documento. Em uma modalidade preferida, os primeiro e segundo dados são do tipo Javascript®.

[0018] Vantajosamente, os segundos meios podem ser uma extensão de servidor.

[0019] Em uma modalidade preferida, os segundos meios são um Javascript® servlet.

[0020] 0 dispositivo eletrônico portátil pode ser um cartão inteligente.

Breve Descrição dos Desenhos

[0021] Outras características e vantagens da presente invenção emergirão mais claramente de uma leitura da descrição seguinte de um número de modalidades preferidas da invenção com referência aos desenhos anexos correspondentes em que: - A figura 1 representa, esquematicamente, um exemplo de arquitetura de um dispositivo eletrônico portátil destinado a proporcionar um documento de HTML de acordo com a invenção; - A figura 2 é um exemplo de sequência de etapas para geração de um documento de HTML de acordo com a invenção; e - A figura 3 representa, esquematicamente, um exemplo de comunicação trocada entre uma máquina cliente e um dispositivo eletrônico portátil de acordo com a invenção.

Descrição Detalhada das Modalidades Preferidas

[0022] A invenção pode se aplicar a quaisquer tipos de dispositivos eletrônicos portáteis. Nesta especificação, o dispositivo eletrônico portátil é um cartão inteligente, mas poderia ser qualquer outra espécie de dispositivo eletrônico portátil compreendendo um servidor da web.

[0023] A invenção pode se aplicar a quaisquer tipos de máquinas cliente. Nesta especificação, a máquina cliente é um handset de telecomunicações, mas poderia ser qualquer outra espécie de cliente como um computador pessoal, por exemplo. Nesta especificação, a máquina cliente é a máquina hospedeira, mas poderia ser qualquer máquina cliente remota, capaz de estabelecer uma sessão de cliente-servidor com o dispositivo eletrônico portátil.

[0024] A presente invenção conta com o uso de mecanismo de script acoplado a um navegador da web. É uma questão de fato que o uso de script é muito comum no domínio da web e a maior parte dos navegadores da web é empregada com um mecanismo de script acoplado. Uma vantagem da invenção é tirar vantagem de recursos hospedeiros. Em particular, o mecanismo de script da máquina cliente tem menos limitações de recursos do que um mecanismo de script de um dispositivo eletrônico portátil. A interpretação de script requer uma porção de recursos e é consumidora de tempo em um dispositivo eletrônico portátil. A interpretação de script é realizada de maneira mais rápida na máquina cliente do que em um dispositivo eletrônico portátil como um cartão inteligente.

[0025] Uma vantagem adicional da invenção é tirar vantagem de atualizações adicionais do mecanismo de script no lado cliente, sem qualquer mudança no lado do dispositivo eletrônico portátil.

[0026] A figura 1 mostra a arquitetura de um dispositivo eletrônico portátil SC do tipo cartão inteligente SIM de acordo com uma modalidade preferida da invenção.

[0027] O dispositivo eletrônico portátil SC compreende uma memória de trabalho MEM1 do tipo RAM, uma memória não volátil MEM2, um microprocessador MP e uma interface de comunicação IN. A memória de trabalho MEM1 compreende um servidor da web SCWC e um sistema operacional OS.

[0028] Além disso, o dispositivo eletrônico portátil SC compreende duas memórias não voláteis MEM3 e MEM4. A memória MEM3 armazena primeiros dados Dl. Na modalidade preferida, a memória MEM3 é gerenciada como uma área de sistema de arquivo e os primeiros dados Dl é um documento de HTML. Dl compreende uma primeira parte executável EP1, que é destinada a ser interpretada por um navegador da web. EP1 é um script do tipo Javascript®. A memória MEM4 armazena dados de cartão GDI, CD2 e CD3.

[0029] O dispositivo eletrônico portátil SC compreende primeiro e segundo meios Ml e M2. O primeiro meio Ml é capaz de enviar os dados Dl para o navegador da máquina cliente ligada. O segundo meio M2 é capaz de gerar, dinamicamente, segundos dados D2 dos dados GDI, CD2 e CD3, armazenados no cartão SIM. Em uma modalidade preferida, meios M2 são Javascript® servlet.

[0030] As três memórias MEM2, MEM3 e MEM4 podem ser implementadas como quaisquer combinações de uma, duas ou três memórias. Essas memórias podem ser memórias flash NAND ou EEPROM ou outro tipo de memória não volátil.

[0031] O cartão SIM SC é destinado a trocar mensagens com um handset de telecomunicações HM através da interface de comunicação IN.

[0032] A figura 2 mostra um exemplo de uma sequência de etapas para gerar um documento de HTML a ser exibido por um navegador no handset de telecomunicações HM.

[0033] Primeiro, um usuário inicia um navegador da web BR no handset de telecomunicações HM. Na etapa SI, o navegador BR envia uma primeira solicitação RI para o servidor da web SCWS embutido no cartão SIM. A solicitação RI contém a referência da página de HTML requerida pelo navegador BR. Por exemplo, a referência de página a ser alcançada pode ser http://i92,168.0.2/home.html ou httpsj//i92.168.0.2/home.html em protocolo de TCP/IP ou http :_//lOcalhost: 3516/home em Protocolo Bearer Independent, também chamado BIP. Então, o servidor da web SCWS obtém os primeiros dados Dl da área do sistema de arquivo de MEM3 na etapa S2. Os primeiros dados Dl compreendem uma parte estática de HTML e uma parte executável EDI. Neste exemplo, EP1 é um código Javascript®. Então, na etapa S3, os primeiros dados Dl são enviados para o navegador BR. No recebimento de Dl, a etapa S4 é alcançada. 0 navegador BR identifica a parte executável EP1. Então, o navegador BR delega a interpretação de EP1 para o mecanismo de script SE na etapa S5. A parte executável EP1 permite que o mecanismo de script Se construa uma segunda solicitação R2 destinada a ser enviada para o servidor da web SOWS. Na etapa S6, a segunda solicitação R2 é enviada para o servidor da web SCWS. Na etapa S7, o servidor da web SCWS obtém um segundo script D2 do segundo meio M2. Neste exemplo, o meio M2 é um Javascript® servlet. 0 servlet constrói os segundos dados D2 dos dados armazenados no cartão SIM. Neste exemplo, D2 é um documento Javascript® e o servlet pode construir os segundos dados D2 de CD1 e CD2. Na etapa S8, o servidor da web envia os segundos dados D2 para o navegador BR. Então, o navegador BR delega a interpretação do script D2 para o mecanismo de script SE na etapa S9. Na etapa S10, uma verificação de Dl e D2 é realizada a fim de detectar a presença de um elemento dedicado à construção de uma solicitação adicional destinada a ser enviada para o servidor da web SCWS.

[0034] Se os dados Dl ou D2 contêm um elemento necessitando o envio de uma nova solicitação para o SCWS, então, uma terceira solicitação R3 é construída de D2 e um laço é feito saltando de volta para a etapa S6. Em outras palavras, o mecanismo de script SE solicita o navegador BR para obter um novo script do servidor da web SCWS. Se os dados Dl e D2 não contêm qualquer elemento que requeira o envio de uma nova solicitação para o SCWS, então, a página de HTML é completada com os dados retornados pelo mecanismo de script SE. Os dados retornados pelo mecanismo de script SE são construídos dos dados Dl e / ou D2. Na etapa Sll, o mecanismo de script SE envia a página de HTML final para o navegador BR. Então, na etapa S12, a geração de HTML é realizada com sucesso e pode ser exibida pelo navegador BR na tela do handset.

[0035] A figura 3 mostra um exemplo de trocas de comunicação entre um handset de Telecom HM e um cartão SIM de acordo com uma modalidade preferida da invenção, Neste exemplo, o handset de Telecom HM visa a exposição de todos os números telefônicos de uma agenda armazenada no cartão SIM. Supondo que sete números telefônicos são armazenados na agenda do cartão SIM, a página de HTML a ser exibida no terminal de handset HM conterá uma lista de sete números telefônicos. Neste exemplo, o mecanismo de script SE é um intérprete de Javascript®.

[0036] Primeiro, o navegador BR envia a solicitação RI para o servidor da web SCWS. A solicitação RI corresponde a uma solicitação para obter uma página de HTML do servidor da web SIM SCWS. Então, o servidor da web SCWS envia de volta os dados de Dl, que compreende uma parte de HTML e uma primeira parte Javascript®.

[0037] No exemplo a seguir, EPl tem duas partes: uma primeira parte no cabeçalho e uma segunda parte no corpo. <html> <head> <title>Contact List</title> <script> // get contact list dynamically from card servlet document .write ("<script src=\"/smart card/contact list.j s \ "><\script>"); </script> </head> <body> <script> // contactlist array is filled by header dynamic call var list = contactlist; // static build table Javascript code document.write("<table name=\"contactlist\" cellspacing=5>") ; // add the contact list adapted to dynamic data length for(var 1=0; i<list.length; i++) { document. write ("<tr><td align=rightximg src=\"'contacts /images /small/" + list [i] . id + ".jpg\"></td><td colspan=l valign=middle><a href=\"ContactDetail.html?id="+list[i].id+"\">" + list [i] .value + </a></tdx/tr>") ; } document.write ("</table>"); … </script></body> < /html>

[0038] A primeira parte permite a construção da solicitação de R2 (’ src="/smartcard/contactlist. js") . A segunda parte permite a construção dinâmica de uma tabela de acordo com os dados de D2 recuperados do servidor da web SCWS em resposta à solicitação de R2.

[0039] O navegador BR envia a primeira parte Javascript® EP1 para o mecanismo de script SE. Pelo uso da parte de Javascript® EP1, o intérprete de Javascript® SE constrói uma segunda solicitação R2 que corresponde a uma solicitação de Javascript®. R2 é proporcionado para o navegador BR que enviou R2 para o servidor da web SCWS. O servidor da web SCWS envia a solicitação de R2 para Javascript® servlet. Em resposta, Javascript® servlet constrói, dinamicamente, um documento de Javascript® D2 dos dados armazenados no cartão SIM. O documento de Javascript® de D2 compreende a lista de contatos armazenados na agenda. Então, para cada um dos contatos, o intérprete de Javascript® SE constrói uma outra solicitação R3 a R9 que corresponde à solicitação de detalhes relacionados com cada contato. Desse modo, o mecanismo de script SE obtém, progressivamente, todos os dados que permitem a construção do documento de HTML a ser exibido no telefone móvel HM. O documento de Javascript® D3 compreende o primeiro número telefônico. O documento Javascript® de D3 é, então, enviado para o navegador BR pelo cartão SIM. 0 intérprete de Javascript® SE constrói uma quarta solicitação R4, que corresponde a uma solicitação de Javascript®. R4 permite obter o segundo número telefônico armazenado no cartão SIM. A sequência é repetida até a recuperação do último número telefônico da agenda SIM. Em outras palavras, a sequência é repetida até a solicitação R9. 0 nono documento de Javascript® D9 compreende o sétimo número telefônico e nenhuma parte executável adicional. No recebimento do documento D9, o navegador BR é agora capaz de mostrar a lista completa de números telefônicos na tela do handset de Telecom HM.

[0040] Vantajosamente, os documentos de Javascript® gerados pelo servlet no cartão SIM pode conter dados adicionais relacionados com o número telefônico como uma imagem, um nome ou um e-mail, por exemplo.

[0041] No exemplo acima, a invenção conta com uma primeira parte executável Javascript® incluída em uma página de HTML estática. Essa primeira parte executável de Javascript® importa um documento Javascript®, que é gerado, dinamicamente por um servlet no cartão SIM. O documento Javascript® gerado pode conter uma segunda parte executável de Javascript® , que permite a construção da página de HTML alvo.

[0042] A página de HTML é construída, dinamicamente, graças a uma sucessão de extensões progressivas do conteúdo da página de HTML via diversas solicitações de Javascript®. O mecanismo de script SE localizado no lado cliente interpreta corretamente a série de códigos executáveis como um código Javascript® global. Desse modo, as estruturas de página de HTML não são codificadas rigidamente na parte de servlet. As estruturas de página de HTML podem ser facilmente modificadas no dispositivo eletrônico portátil através de uma ferramenta padrão de desenho da web.

[0043] De acordo com a presente invenção, o processo de geração de documento é sequencial com um minimo de processamento feito pelo dispositivo eletrônico portátil, O dispositivo eletrônico portátil proporciona ao navegador BR da máquina cliente dados estruturados. O navegador BR usa os dados estruturados recebidos e partes executáveis a fim de criar uma página de HTML via o mecanismo de script SE.

[0044] O código de Javascript® enviado pelo servlet pode ser construído sequencialmente. A série de solicitações para o servlet pode ser enviada através de laços. Desse modo, as invenção evita reserva um grande buffer de memória e evita a identificação do tamanho desse buffer no começo. Graças ao modo chunk, a invenção permite a construção do código corretamente.

[0045] Nos exemplos descritos acima, o dispositivo eletrônico portátil SC é conectado diretamente à máquina cliente compreendendo o navegador BR ativo. Nesse caso, a máquina cliente é a máquina hospedeira.

[0046] Vantajosamente, a máquina cliente pode ser distinta da máquina hospedeira. Nesse caso, a máquina hospedeira é uma porta entre o dispositivo eletrônico portátil SC e a máquina cliente.

[0047] Uma vantagem da invenção é permitir a geração de documento com dados armazenados no cartão inteligente, qualquer que seja o número de itens/ dados a serem inseridos na página de HTML . A invenção permite uma geração dinâmica da estrutura de página de HTML, de acordo com os dados a serem inseridos na página de HTML. Não há necessidade de conhecer o número de itens/ registros a serem tratados antes da geração. Se o tamanho de um dado elemento estiver caminhando para ser determinado, o tamanho é definido, dinamicamente, pela parte de script, de acordo com os dados extraídos do cartão SIM.

[0048] Outra vantagem da invenção é requerer um pequeno tamanho de memória para armazenar o servlet. Comparado com a solução de análise, uma vantagem da invenção é evitar armazenar grupos a serem buscados e substituídos. Esse ponto é muito importante, visto que os recursos da memória do dispositivo eletrônico portátil SC são limitados.

[0049] Além disso, se a estrutura de documento deve mudar, o servlet pode ser mantido inalterado.

[0050] Outra vantagem da invenção é requerer uma largura de banda limitada entre o dispositivo eletrônico portátil e a máquina cliente HM uma vez que apenas a série de dados estruturados é enviada pelo dispositivo eletrônico portátil com um overhead limitado. O dispositivo eletrônico portátil não envia todo o documento de HTML final como tal. O dispositivo eletrônico portátil envia um documento de HTML pré-definido como uma semente. Então, o documento semente enviado é completado na máquina cliente pelo navegador da web.

[0051] Uma vantagem adicional da invenção é que não há necessidade de analisar a rotina no dispositivo eletrônico portátil.

[0052] De modo alternativo, a invenção pode ser usada para a geração de página de XML. A invenção pode usar outros sistemas de script que precisam ser interpretados por um mecanismo de script. Alternativamente, parâmetros podem ser usados para personalizar a solicitação enviada para o servlet. No exemplo de uma agenda a seguinte solicitação "Createcontact. js ? id=3" permite obter o terceiro contato armazenado na agenda. A solicitação "Createcontact.js ? type=phonenumber" permite obter o número telefônico de todos os contatos armazenados na agenda. A solicitação "Createcontact.js ? type=photo" permite obter o curso da foto relacionada com todos os contatos armazenados na agenda.

[0053] Vantajosamente, os dados trocados entre a máquina cliente e o dispositivo eletrônico portátil podem ser protegidos graças a mecanismos de segurança como mecanismos de integridade e confidencialidade. Esses mecanismos de segurança são bem conhecidos no dominio dos cartões inteligentes ou no dominio da web. Por exemplo, os dados trocados podem ser protegidos graças à Secure Sockets Layer também denominada SSL ou graças à Transport Layer Security , também denominada TLS.

[0054] Em uma modalidade, os dois dados de cartão CD1 e CD2 podem ser armazenados em um formato especifico no dispositivo eletrônico portátil. Em particular, CD1 e CD2 podem ser armazenados em um formato que não é compatível, diretamente, com o navegador BR, especialmente quando o dispositivo eletrônico portátil é um cartão inteligente. Por exemplo, um JavaCard não é capaz de gerencial o modo Texto, ainda que o navegador BR trabalhe no modo Texto. Além disso, o servidor da web SCWS embutido em um cartão inteligente tem características limitadas, uma vez que recursos do cartão inteligente SC são limitados.

[0055] Em particular, as Java Server Pages (também denominadas JSP) não estão disponíveis em um Javacard. Além disso, um servidor da web usual SCWS é destinado a gerar e enviar documentos estáticos ou documentos dinâmicos básicos. Os documentos dinâmicos básicos são documentos com complexidade muito limitada.

[0056] Vantajosamente, os primeiros dados Dl podem compreender um conjunto de variáveis a serem inicializadas para geração do documento DOC. Os primeiros dados Dl podem compreender uma segunda parte executável, que é capaz de extrair o conteúdo dos segundos dados D2. A segunda parte executável, que é capaz de extrair o conteúdo dos segundos dados D2. A segunda parte executável é especifica para o meio M2, uma vez que a segunda parte executável é capaz de compreender o formato e a estrutura de dados gerados pelo meio M2. O meio M2 pode ser um servlet, que é capaz de extrair dados de cartão e gerar dados correspondentes, que podem ser usados no lado da máquina cliente. Por exemplo, quando dados de cartão são armazenados no formato ByteArray ou Integer, o meio M2 pode traduzir os dados de cartão no valor correspondente no formato String. Além disso, se os dados de cartão forem armazenados através de um sistema de arquivo no cartão inteligente SC, o meio M2 realiza uma série de traduções de formato.

[0057] Os primeiros dados Dl podem compreender uma terceira parte executável, que é capaz de inicializar o conjunto de variáveis do conteúdo extraído dos segundos dados D2. A terceira parte executável atua como um conector entre os dados enviados pelo cartão SC e as variáveis que permitem construir o documento DOC.

[0058] A terceira parte executável pode ser implementada como um método, que é chamado pelos outros scripts R2 e R3. As segunda e terceira partes executáveis são destinadas a serem interpretadas pelo mecanismo de script SE.

Claims

1. Método de geração de um documento (DOC) destinado a ser usado por um navegador (BR) em uma máquina cliente, a referida máquina cliente compreendendo um mecanismo de instruções, um cartão inteligente (SC) sendo conectado a uma máquina hospedeira (HM), o referido cartão inteligente (SC) compreendendo um servidor da web (SCWS) e dados de cartão (CD1, CD2), o referido método compreendendo as etapas de: a) estabelecimento de uma sessão de cliente-servidor entre a máquina cliente e o cartão inteligente (SC) ; b) envio de uma primeira solicitação (Rl) do navegador (BR) para o servidor da web (SCWS); caracterizado pelo fato de o referido método compreender as etapas de: c) envio dos primeiros dados (Dl) do servidor da web (SCWS) para o navegador (BR) em resposta à primeira solicitação (Rl), os referidos primeiros dados (Dl) compreendendo primeira (EP1), segunda e terceira instruções destinadas a serem realizadas pelo mecanismo de instruções, os referidos primeiros dados (Dl) para gerar o documento (DOC); d) envio de uma segunda solicitação (R2) do navegador (BR) para o servidor da web (SCWS), a referida segunda solicitação (R2) sendo gerada por meio do mecanismo de instruções e da primeira instrução (EP1); e) geração de segundos dados (D2), dinamicamente, dos referidos dados de cartão (CD1, CD2) no cartão inteligente (SC) em resposta à segunda solicitação (R2); f) envio dos segundos dados (D2) do servidor da web (SCWS) para o navegador (BR), os referidos segundos dados (D2) sendo realizados pelo mecanismo de instruções para gerar uma parte do documento (DOC), a referida segunda instrução sendo capaz de extrair conteúdo dos segundos dados (D2) e a referida terceira instrução sendo capaz de inicializar o conteúdo dos segundos dados (D2).

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de o referido documento (DOC) ser um documento de HTML ou um documento de XML.

3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de o referido método compreender as etapas adicionais de: g) envio de uma terceira solicitação (R3) do navegador (BR) para o servidor da web (SCWS) , a referida terceira solicitação (R3) sendo gerada por meio do mecanismo de instruções e dos referidos segundos dados (D2) ou da referida primeira instrução (EP1); h) geração dos terceiros dados (D3) no cartão inteligente (SC) em resposta à terceira solicitação (R3); i) envio dos terceiros dados (D3) do servidor da web (SCWS) para o navegador (BR), os referidos terceiros dados (D3) sendo realizados pelo mecanismo de instruções para gerar uma parte do documento (DOC).

4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de os referidos segundos dados (D2) compreenderem dados (SD) usados pelo mecanismo de instruções para gerar uma parte do documento (DOC).

5. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de os referidos dados (D2) serem gerados por uma extensão de servidor.

6. Cartão inteligente (SC) destinado a ser conectado a uma máquina hospedeira (HM), o referido cartão inteligente (SC) sendo destinado a ser ligado a uma máquina cliente através de uma sessão de cliente-servidor, a referida máquina cliente compreendendo um navegador (BR) e um mecanismo de instruções, o referido cartão inteligente (SC) compreendendo: - um microprocessador (MP); - uma interface de comunicação (IN); - um sistema operacional (OS); - uma memória de trabalho (MEM1) e uma memória não volátil (MEM2); - um servidor da web (SCWS); - primeiros dados (Dl); - dados de cartão (CD1, CD2); - primeiros meios (Ml) capazes de enviar primeiros dados para o navegador (BR) em resposta a uma primeira solicitação (Rl) recebida do navegador (BR); caracterizado pelo fato de os referidos primeiros dados (Dl) compreenderem primeira (EP1), segunda e terceira instruções destinadas a serem realizadas pelo mecanismo de instruções, pelo fato de os referidos primeiros dados (Dl) compreenderem um conjunto para gerar o documento (DOC) e pelo fato de o referido cartão inteligente (SC) compreender: - segundos meios (M2) capazes de gerar segundos dados (D2), dinamicamente, em resposta a uma segunda solicitação (R2) recebida do navegador (BR), os referidos segundos dados (D2) sendo usados pelo mecanismo de instruções para gerar uma parte de um documento destinado a ser usado pelo navegador (BR), a referida segunda instrução sendo capaz de extrair conteúdo dos segundos dados (D2) e a referida terceira instrução sendo capaz de inicializar o conteúdo dos segundos dados (D2).

7. Cartão inteligente (SC), de acordo com a reivindicação 6, caracterizado pelo fato de o referido documento (DOC) ser um documento de HTML ou um documento XML.

8. Cartão inteligente (SC), de acordo com a reivindicação 6 ou 7, caracterizado pelo fato de os referidos segundos dados (D2) compreenderem dados (SD) usados pelo mecanismo de instruções para gerar uma parte do documento (DOC).

9. Cartão inteligente (SC), de acordo com qualquer uma das reivindicações 6 a 8, caracterizado pelo fato de os referidos segundos meios (M2) serem uma extensão de servidor.