BR9906355B1 - cartão de chip compreendendo meios para gerenciar uma memória virtual, método e protocolo de comunicação associados. - Google Patents

cartão de chip compreendendo meios para gerenciar uma memória virtual, método e protocolo de comunicação associados. Download PDF

Info

Publication number
BR9906355B1
BR9906355B1 BRPI9906355-7A BR9906355A BR9906355B1 BR 9906355 B1 BR9906355 B1 BR 9906355B1 BR 9906355 A BR9906355 A BR 9906355A BR 9906355 B1 BR9906355 B1 BR 9906355B1
Authority
BR
Brazil
Prior art keywords
data
card
application
data set
storage media
Prior art date
Application number
BRPI9906355-7A
Other languages
English (en)
Other versions
BR9906355A (pt
Inventor
Azad Nassor
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed filed Critical
Publication of BR9906355A publication Critical patent/BR9906355A/pt
Publication of BR9906355B1 publication Critical patent/BR9906355B1/pt

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/08Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers from or to individual record carriers, e.g. punched card, memory card, integrated circuit [IC] card or smart card
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44594Unloading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/04Methods or arrangements for sensing record carriers, e.g. for reading patterns by mechanical means, e.g. by pins operating electric contacts
    • G06K7/042Methods or arrangements for sensing record carriers, e.g. for reading patterns by mechanical means, e.g. by pins operating electric contacts controlling electric circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4093Monitoring of device authentication

Description

CARTÃO DE CHIP COMPREENDENDO MEIOS PARA GERENCIAR UMA MEMÓRIA VIRTUAL, MÉTODO E PROTOCOLO DE COMUNICAÇÃO ASSOCIADOS
A presente invenção refere-se a um cartão de chip compreendendo meios para gerenciar uma memória virtual.
Depois de vinte anos, o cartão de chip ocupa um grande lugar na vida atual. O domínio bancário teve interesse primeiramente nos cartões de microcircuitos : a principal vantagem deles é de diminuir a fraude. As sociedades de televisão por pagamento e de telefonia celular os utilizam como meio de geração de chaves que servem para codificar e decodificar as emissões criptografadas. Para garantir a segurança, foi necessário criar uma nova arquitetura de circuito integrado. Os cartões de tipo porta dinheiro eletrônico contêm uma soma de dinheiro eletrônico: outros cartões, denominados de fidelidade, conseguem vantagens financeiras para seus proprietários.
E visto que, os aparelhos relacionados com os cartões de microcircuito e mais particularmente os cartões de microprocessador, são utilizáveis em um número cada vez maior de aplicações. Inicialmente, o sistema de exploração dos cartões, isto é, o programa situado na memória ROM, só podia gerenciar uma única aplicação. O sistema de exploração é inscrito no momento da fabricação do microcircuito. Aumentando-se o tamanho da memória programa (ROM) e da memória programável não volátil (EPROM e EEPROM, atualmente FeRAM), o sistema de exploração pode executar mais funções. Porém, o número destas funções está limitado hoje em dia pelo tamanho da memória RAM. Além disso, o acréscimo de uma função suplementar na ROM implica em realizar uma nova máscara; esta realização custa muito caro e não é rentável verdadeiramente se não é destinada a uma grande quantidade de cartões. Um meio de aumentar o número destas funções sem tocar na memória ROM consiste em escrever na memória programável, o programa executável bem como os dados que permitem fazê-la funcionar. Assim é possível adicionar as funções suplementares a um sistema de exploração que só possui na partida um número congelado de funções. O pedido de patente FR-A-2.748.134 descreve um meio de carregar o programa na memória programável. Mas a memória programável é de um tamanho limitado : uma vez preenchida com um programa, não é possível adicionar funções. Ademais, o armazenamento deste programa se efetua em detrimento do espaço de memória destinado aos dados na memória programável. O processo precedente é utilizado para corrigir algumas imperfeições do programa situado em ROM ou para adicionar algumas outras funções. Se um cartão deve executar um programa de um tamanho muito importante, o processo descrito neste documento pode provar ser insuficiente.
A presente invenção tem por objeto solucionar este problema propondo um método de carregamento e descarregamento da memória programável em função das necessidades no que diz respeito aos programas e/ou aos dados aplicativos, por um dispositivo de processamento de dados constituído por um cartão. Desse modo, torna-se possível a este executar aplicações muito diversas tais como : Porta Dinheiro Eletrônico, aplicação bancária, telefonia GSM ou aplicação de saúde atualmente experimentada na FRANÇA. Com o auxílio da presente invenção, as aplicações que acabamos de enumerar estão virtualmente no cartão. O proprietário do cartão as carregou de antemão; desse modo, o cartão está configurado de acordo com suas próprias necessidades.
A presente invenção permite também solucionar um outro problema. Um usuário pode ter necessidade de abrir ao mesmo tempo duas vezes a mesma aplicação. A execução desta aplicação num dispositivo de processamento de dados tal como um cartão dura um tempo determinado. Para acelerar o processamento, é vantajoso poder começar uma segunda execução de aplicação antes do fim da primeira. Desse modo, o mesmo programa se desenvolve duas vezes ao mesmo tempo.
Este propósito é conseguido pelo fato que o cartão é dotado de um sistema de exploração compreendendo ao menos três funções:
- Carregamento de informações aplicativas.
- Descarregamento de informações aplicativas.
- Execução de informações aplicativas.
Para adquirir uma nova aplicação, o cartão recebe as informações aplicativas na sua memória programada e controla estas informações.
Quando um comando recebido de uma leitora que coopera com o cartão visando a executar uma aplicação, o sistema de exploração do cartão analisa o conteúdo de sua memória e determina se há lugar para chamar a rede para descarregar uma parte da memória, e/ou recarregar as informações aplicativas anteriormente descarregadas.
Quando do recarregamento das informações aplicativas, o sistema de exploração do cartão verifica que as informações carregadas foram validadas por ele no passado. Estas informações são executadas em seguida.
A rede pode s<;r considerada como uma extensão da memória programável do cartão : este envia para ela aquilo que ele não pode guardar na sua própria memória. Ele controla, quando do recairegamento, que as informações recebidas da rede são verdadeiramente aquelas que ele tinha enviado anteriormente. A memória ROM do cartão deve dispor de um mecanismo de gerenciamento da memória programável que lhe permita carregar e executar um número ilimitado de aplicação. Por conseguinte, os tamanhos das memória ROM e programáveis do canão não são mais uma limitação ao número de aplicações executáveis, e não há mais necessidade de efetuar um novo mascaramento quando de acréscimo de aplicações.
Em resumo, a invenção diz respeito a um cartão de chip que compreende os meios de processamento de dados e os meios de armazenamento de dados principais, caracterizado pelo fato que os meios de processamento compreendem :
- meios para detectar, durante o funcionamento do cartão de chip, que os meios de armazenamento principais contêm uma quantidade de dados tal que a execução de uma operação não é possível;
- meios para selecionar, nos meios de armazenamento principais. um conjunto de dados a descarregar, cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar a execução da dita operação:
- meios para descarregar o conjunto de dados a descarregar nos meios de armazenamento secundários, no caso em que os ditos meios de armazenamento secundários não contêm o dito conjunto de dados a descarregar.
A invenção refere-se também ao método associado. Ela diz respeito finalmente a um protocolo de comunicação entre um cartão de chip e uma leitora de cartão de chip, o cartão compreendendo os meios de processamento de dados e os meios de armazenamento de dados principais, caracterizado pelo fato que ele compreende as etapas que consistem em :
- a leitora transmite ao cartão uma ordem de execução de uma operação;
- o cartão busca se, para executar esta operação, ele dispõe de um lugar suficiente nos meios de armazenamento principais;
- em caso afirmativo, o cartão executa a dita operação depois transmite um relatório de execução à leitora; - no caso negativo, o cartão seleciona nos meios de armazenamento principais um conjunto de dados a descarregar cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar a execução da dita operaçao, depois o cartão descarrega o conjunto de dados a descarregar nos meios de armazenamento secundários pela transmissão de uma ordem de descarregamento à leitora, no caso onde os ditos meios de armazenamento secundários não contêm o dito conjunto de dados a descarregar, depois ele executa a dita operação e depois transmite finalmenle um relatório de execução à leitora.
Outros detalhes e vantagens da presente invenção ficarão aparentes durante a descrição seguinte de alguns modos de execução preferidos, mas não limitativos, com relação aos desenhos apensos, nos quais:
A figura l representa uma rede de processamento de dados utilizada pela invenção;
A figura 2 representa um dispositivo de processamento de dados, utilizado na figura 1 e cooperando com um cartão de chip;
A figura 3 representa uma variante da figura 2, na qual o dispositivo de processamento de dados integra as funcionalidades do cartão de chip;
A figura 4 é uma variante da figura 2, onde o dispositivo de processamento de dados é equipado de um dispositivo de leitura de trilha ótica; e
A figura 5 representa uma variante da figura 3. Na figura 1, um terminal 20, apto a ler um cartão de chip, ou um terminal 22 integrando as funcionalidades de cartão de chip cooperam com os bancos de dados 23 a 25 distantes e ligados a estes por uma rede de comunicação de dados 26. A rede de comunicação de dados 26 é notadamente uma rede telefônica, a rede Internet, ou qualquer outra rede de comunicação de dados. Cada banco de dados compreende uma unidade central de processamento de dados gerenciando uma memória. De acordo com a invenção, e como declarado anteriormente, o cartão 21 ou o terminal 22 podem, quando eles detectam que o carregamento de uma nova aplicação neles não é possível em razão de uma falta de espaço de memória, decidir descarregar para um dos bancos de dados 23 a 25 uma outra aplicação. Este descarregamento libera um espaço memória suficiente para acolher a nova aplicação. Se o cartão 21 ou o terminal 22 têm necessidade ulteriormente da aplicação descarregada, eles enviarão um comando ao banco de dados correspondente para recarregar a aplicação, depois de ter, se necessário, liberado novamente do espaço memória por um descarregamento da aplicação.
A constituição do terminal 20 e do cartão 21 é ilustrada na figura 2. O terminal compreende de modo intrinsicamente conhecido um microprocessador 2 ao qual são ligados uma memória ROM 3, e uma memória RAM 4, os meios 5 para cooperar, com ou sem contato físico, com o cartão de chip 21, e uma interface de transmissão 7 que permite ao terminal comunicar-se com a rede de comunicação de dados 26 da figura 1. O terminal 20 pode também equipar os meios de armazenamento tais como disquetes ou discos amovíveis ou não, os meios de entrada (tais como um teclado e/ou um dispositivo de sinalização do tipo mouse) e os meios de visualização, estes diferentes meios não sendo representados na figura 2.
O terminal pode ser constituído por qualquer aparelho de informática instalado num local privado ou público e apto a fornecer os meios de gerenciamento da informação ou de entrega de diversos bens e serviços, este aparelho sendo instalado portátil ou remotamente. Ele pode notadamente tratar-se também de um aparelho dedicado às telecomunicações.
Por outro lado, o cartão 21 porta um chip que inclui os meios de processamento de dados 9, uma memória não volátil 10, uma memória volátil de trabalho RaM 14, e os meios 13 para cooperar com o terminal 20. Este chip é disposto para definir, na memória 10, uma área secreta 11 na qual as informações uma vez gravadas, são inacessíveis a partir do exterior do chip mas apenas acessíveis aos meios de processamento 9, e uma área acessível 12 que é tornada acessível a partir do exterior do chip pelo microprocessador 9 para leitura e/ou uma escrita de dados. Cada área da memória não volátil 10 pode compreender uma parte não modificável ROM e uma parte modificável EPROM, EEPROM, ou constituída de memória RAM do tipo "flash" ou FRAM (esta última sendo uma memória RAM ferromagnética), isto é, apresentando as características de uma memória EEPROM com além disso os tempos de acesso idênticos àqueles de uma RAM convencional.
Na qualidade de chip, poderá ser utilizado notadamente um microprocessador autoprogramável com memória não volátil, tal como descrito no pedido americano n°. 4.382.279 em nome da Requerente. Como indicado na coluna 1, nas linhas 13-25 deste pedido, o caractere autoprogramável do chip corresponde à possibilidade para um programa fi situado na memória ROM, de modificar um outro programa fj situado numa memória programável em um programa gj. Numa variante, o microprocessador do chip é substituído - ou pelo menos completado - pelos circuitos lógicos implantados num chip de semicondutores. Efetivamente, tais circuitos são aptos a efetuar os cálculos, notadamente de autenticação e de assinatura, graças à eletrônica cabeada, e não microprogramada. Eles podem notadamente ser do tipo ASIC (do inglês
"Application Specific ]ntegrated Circuit"). A título de exemplo de ASIC, pode-se citar o componente da sociedade SIEMENS comercializado sob a referência SLE 4436 e aquele da sociedade SGS-THOMSON comercializado sob a referência ST 1335. Vantajosamente, o chip será concebido sob forma monolítica.
Uma variante da figura 2 é ilustrada na figura 3, onde o terminal 22 da figura 1 compreende, também os elementos do terminal 20, aqueles do cartão 21 dispostos num módulo 15, os elementos comuns às duas figuras 2, 3 portando as mesmas referências. Entretanto, os meios de cooperação 5,13 da figura 2 são substituídos por uma ligação permanente entre os microprocessador 2 e o microprocessador 9.
Uma variante da figura 3 é representada na figura 5. Aqui, o terminal 50 apenas compreende um só microprocessador 51 ou equivalente, ligado a uma memória RAM 52 e a uma memória não volátil 53. A memória não volátil 53 compreende uma zona 54 tornada acessível do exterior do terminal pelo microprocessador 51, e uma zona secreta 55 acessível somente ao microprocessador 51. O microprocessador 51 possui a característica autoprogramável do microprocessador 9, descrito em relação com a figura 2. Finalmente, o terminal 50 possui uma interface de transmissão 56 que lhe permite comunicar-se com a rede de comunicação de dados 26 da figura 1.
A descrição seguinte fará referência, de modo não limitativo, à forma de realização da figura 2 e o terminal 20 será denominado "leitora" em razão de sua função leitora do cartão 21.
As memórias do cartão são organizadas do seguinte modo: uma memória de tipo ROM, uma memória de trabalho de tipo RAM, e uma memória programável não volátil de tipo EEPROM ou FLASH. Como representado no quadro 1, a memória ROM contém uma zona de sistema de exploração de base compreendendo no mínimo os sub- programas ou rotinas tais como aquelas de entrada/saída e de escrita/leitura em memória e uma zona de sistema de exploração de uma memória virtual, esta memória virtual sendo constituída pela memória dos bancos de dados 23 a 25. O sistema de exploração de base e o sistema de exploração da memória virtual formam conjunto o que denominaremos a seguir o "sistema de exploração do cartão".
O sistema de exploração da memória virtual é capaz de gerenciar de preferência ao menos nove comandos. Quatro comandos ao menos são lançados pela leitora para o cartão:
- Carregamento de aplicações no cartão.
Execução em cartão das aplicações anteriormente carregadas.
- Apagamento de aplicações em cartão.
- Controle de presença de aplicações em cartão. Cinco outros comandos são lançados pelo cartão para a leitora:
- Descarregamento de aplicações para a rede.
- Recarregamento de aplicações a partir da rede.
- Suspensão da processo de carregamento.
- Recomeço do processo de carregamento.
- Apagamento de aplicações na rede.
Numa realização particular, o sistema de exploração da memória virtual filtra e transmite ao programa de aplicação carregado na memória programável, todas as ordens recebidas do exterior que devem ser tratadas por este programa.
No presente texto, o termo "dados" designa todo programa executável 011 dado não executável em geral. O termo "aplicação" designa um programa particular, destinado a realizar uma aplicação de um fornecedor de serviços ou de produtos, e os dados de aplicação associados.
Sempre de acordo com o quadro 1, a memória programável comporta no mínimo três zonas:
- uma primeira zona denominada "os dados de sistema" contendo um código "C" que identifica o cartão;
- uma segunda zona denominada "de dados de gerenciamento" contendo os dados de gerenciamento das aplicações, a saber uma chave de assinatura denominada "SWAP" particular a cada cartão, uma ou muitas chaves de codificação ligadas de acordo com o caso aos fornecedores de aplicações ou às aplicações particulares, e um quadro denominado "TABAPPLI" e
uma terceira zona denominada "de carregamento", utilizada para receber os dados de aplicações, isto é, do programa executável e/ou dos dados necessários ao funcionamento deste programa.
No início, o cartão pode ser dado a seu portador com uma zona de carregamento e um quadro TAB APPLI vazios. Ao menos a chave SWAP é situada na zona secreta 11 da memória não volátil 10 do cartão.
<table>table see original document page 11</column></row><table>
O quadro TABAPPLI contém os dados correspondentes às aplicações disponíveis no cartão, quer estas aplicações sejam fisicamente contidas no cartão, quer elas sejam virtualmente conlidas em cartão pois descarregadas para a rede. Ele tem a estrutura seguinte:
<table>table see original document page 12</column></row><table>
Quadro 2 : TAB_APPLI
O quadro TAB_APPLI 2 compreende tantas linhas quanto as aplicações tornadas disponíveis pelo cartão e, para cada linha, cinco colunas. Uma primeira coluna define um código de identificação I,J,K da aplicação. Uma segunda coluna define um endereço de armazenamento ADR-I,ADR- J,ADR-K a partir do qual a aplicação é armazenada no cartão. Uma terceira coluna define um número de octetos que representam a quantidade de dados da aplicação. Uma quarta coluna define uma assinatura portando sobre o conjunto dos octetos da aplicação, calculada pela utilização de um algoritmo e a chave SWAP do cartão na qualidade de chave secreta. Na qualidade de algoritmo, pode-se utilizar um algoritmo simétrico tal como o D.E.S. (do inglês Data Encryption Standard) ou assimétrico tal como o R.S.A. (do autores Rivest5 Shamir e Adleman) ; vantajosamente entretanto, será suficiente utilizar uma função mais simples, tal como uma função de corte como MD5 ou SHA, ou uma função tal como o "ou exclusivo", uma vez que, no campo da invenção, a assinatura não sai do cartão e fica portanto preservada. Finalmente, uma quinta coluna define se a aplicação relacionada está num estado "carregado" no cartão ou "descarregado" num banco de dados.
Num primeiro tempo, um portador de cartão ou um fornecedor de aplicações deseja carregar no cartão uma primeira aplicação tendo um código de identificação "Κ". A execução de um comando de carregamento pode estar condicionada por uma autenticação de portador ou de fornecedor de aplicações bem conduzida. O mecanismo de autentificação intrinsicamente bem conhecido consiste, para o portador ou o fornecedor de aplicações, em fornecer ao cartão uma informação lhe permilindo assegurar que ele dialogue com um interlocutor habilitado.
O comando de carregamento contém uma ordem de carregamento, o código C do cartão, o código K da aplicação e o número de octetos η de dados correspondente à esta aplicação, o que dá o formato de comando seguinte:
<table>table see original document page 13</column></row><table>
Quando o comando é recebido pelo cartão, o sistema de exploração do cartão verifica que o código C enviado é na verdade o mesmo que aquele registrado na zona dos dados de sistema. Em caso negativo, o cartão reenvia à rede uma mensagem de erro No caso afirmativo, os dados da aplicação são portanto bem destinadas à este cartão: o sistema de exploração do cartão lê então o quadro TAB APPLI na zona dos dados de gerenciamento para determinar que se trata de um carregamento inicial ou não. Na partida, TAB_APPLI não contém dados sobre a aplicação K; se este não for o caso, o cartão responde à leitora pela mensagem "aplicação já carregada" ; se este for o caso, trata-se então de um carregamento inicial. O sistema de exploração do cartão determina se os n octetos podem estar alojados na memória : no caso afirmativo, ele calcula o endereço de início "ADR-K" de um primeiro bloco de n octetos disponíveis na zona de carregamento. No caso negativo, ele reenvia a mensagem "memória insuficiente". Finalmente, o cartão indica à leitora que ela pode enviar os n octetos da aplicação, com auxílio da resposta "OKCarregamento". A leitora envia então os n octetos da aplicação.
Uma vez os dados da aplicação armazenados em memória programável, o sistema de exploração do cartão calcula a assinatura "SGN-K" destes dados. Ele recolhe então no quadro TABAPPLI o codigo de aplicação Κ, o endereço de armazenamento ADR-K, o número de octetos n, e a assinatura SGN-K. Uma vez que esta operação foi efetuada, o indicador "Carregamento/Descarregamento" é posicionado em "Carregado". A atualização do quadro TAB_APPLI estando terminada, o sistema de exploração do cartão pode então enviar um relatório, através da leitora, ao portador de cartão ou ao fornecedor de aplicações, indicando que o carregamento da aplicação foi corretamente efetuado. O quadro TAB APPLI possui assim a estrutura seguinte:
<table>table see original document page 14</column></row><table>
Quadro 3 : TAB_APPLI Segundo uma primeira variante, o sistema de exploração do cartão pode lançar, logo após o carregamento, o programa executável contido nos dados aplicativos, isto é, nos dados da aplicação. Isto permite inicializar os dados aplicativos. Por exemplo, no caso de uma aplicação de Bolsa Eletrônica, a primeira execução do programa permite inicializar em 0 Frs o pagamento ou saldo da bolsa escrito na memória. Segundo uma segunda variante, o programa executável é lançado quando de um primeiro comando enviado pela leitora ao cartão e fazendo referência à aplicação considerada. De modo simples, o endereço de início de execução da aplicação é "ADR-K", mas se pode utilizar um endereçamento indireto : o endereço designado é então, de modo intrinsicamente conhecido no domínio dos microcomputadores, o conteúdo da memória anotado [ADR-K] que contém o endereço de execução.
A leitora envia ao cartão os comandos especificando o tipo de aplicação ; por exemplo, este tipo pode ser codificado no prtmeiro dos cinco octetos de um comando de acordo com a norma ISO 7816-3; este octeto é denominado na dita norma : "CLA". O sistema de exploração da memória virtual do cartão controla os comandos que lhe envia a leitora e determina o código da aplicação correspondente ao comando. Depois disso, ele lê no quadro TABAPPLI se o código está escrito; se é este o caso, o cartão pode executar a aplicação K. Se este não é o caso, o cartão não pode executar a aplicação K : ele responde enviando uma mensagem de erro. Se o código K está escrito em TABAPPLI, o valor do indicador "Carregamento/Descarregamento" é em seguida testado. Se ele é posicionado sobre o "Carregamento" os dados aplicativos são devidamente presentes na memória programável do cartão. Neste caso, o sistema de exploração do cartão se utiliza de um programa da aplicação situado no endereço ADR-K ou [ADR-K]. Vamos ver em seguida o que se passa quando a memória programável do cartão não contém as informações aplicativas, porque elas já foram descarregadas.
Façamos a suposição agora que o portador de cartão ou o fornecedor de aplicações deseja que seu cartão contenha os dados de uma segunda aplicação, marcada "J" por exemplo. Isto é possível carregando os dados aplicativos "J" na memória programável do cartão. Do mesmo modo que anteriormente, o portador de cartão ou o fornecedor de aplicações se autentifica apresentando um segredo ou senha seguido do comando de carregamento de dados aplicativos seguinte:
Ordem de carregamento Cartão C Appli J Número m
Ela se apresenta como a precedente relativa ao carregamento da aplicação K; aqui, o número de octetos da aplicação é m.
O sistema de exploração do cartão verifica o código C e busca o primeiro bloco de m octetos disponível na memória programável. Suponhamos que a memória programável não possa fisicamente conter ao mesmo tempo os dois blocos de dados aplicativos constituídos pela aplicação K e a aplicação J, mas que ela possa conter a aplicação J se ela descarrega toda ou parte da aplicação Κ. O cartão informa a leitora que ela suspende o processo de carregamento da aplicação J com auxílio de um comando específico enviado à leitora, e decide então
descarregar a aplicação K num banco de dados que pode ser considerado como a memória virtual do cartão. Este descarregamento vai liberar o espaço memória para carregar a aplicação J. O descarregamento consiste então em transferir em um dos bancos de dados 23 a 25 da rede destinada notadamente ao cartão atual, os dados aplicativos particulares a este cartão. Pelo cálculo da assinatura efetuada quando do carregamento, o cartão se assegura de poder controlar a integridade e a autenticidade de seus próprios dados quando de um recarregamento ulterior. Além disso, o fato de já ter efetuado o cálculo de assinatura quando do carregamento inicial otimiza o tempo de execução do comando de descarregamento. O cartão envia à leitora o comando seguinte:
<table>table see original document page 17</column></row><table>
Este comandc comporta, como o comando de carregamento, o código C do cartão, aquele K da aplicação a descarregar, e o número de octetos η de dados da aplicação; ele comporta ademais o conteúdo mesmo destes η octetos de dados, transmitido à leitora ao mesmo tempo que a ordem de descarregamento. No caso em que o descarregamento da aplicação intervém quando uma parte desta já foi executada, os dados de contexto, permitindo recomeçar ulteriormente a execução da aplicação no local onde ela foi interrompida, são, quer armazenados na memória programável do cartão, quer adicionados aos η octetos de dados da aplicação e descarregados ao mesmo tempo que eles na rede.
É possível indicar um identificador de destinatário sob a forma de um endereço de rede. Vantajosamente, a rede possui um quadro de correspondência que associa cada cartão ao endereço do banco de dados que lhe é notadamente destinado. Isto permite evitar que o cartão tenha de armazenar o dito endereço ou o dito identificador, e de agrupar num mesmo banco de dados todos os dados descarregados a partir de um mesmo cartão.
A leitora recebe o comando, mas reconhece que ele é destinado à rede : ela o reenvia então para o banco de dados ao qual ele é endereçado. Se a rede possui muitos bancos de dados, a escolha pode se efetuar em função do código C do cartão. O banco de dados recebe os η octetos de dados aplicativos e reenvia ao cartão, via a leitora, acusando a boa recepção indicando que o armazenamento foi bem transmitido. O cartão modifica então o quadro TABAPPLI posicionando o indicador Carregamento/Descarregamento sobre "Descarregado". O local memória ocupado justamente ali pelos dados aplicativos da aplicação K fica disponível. A operação de carregamento da aplicação J pode então ser recomeçada e o cartão envia à leitora um comando de recomeço do processo de carregamento; a operação de carregamento se efetua de modo idêntico àquela de Κ. O sistema de exploração do cartão determina o endereço de armazenamento ADR-J dos m octetos da aplicação J e indica à leitora por uma mensagem ,;OK_Carregamento" que ela pode enviar os m octetos de dados aplicativos.
A leitora envia os m octetos de dados aplicativos que são escritois a partir do endereço "ADR-J". Uma vez que os dados da aplicação J são armazenados em memória programável, o sistema de exploração do cartão calcula uma assinatura desses efetuando um cálculo criptográfico com auxílio da chave SWAP. Finalmente, o sistema de exploração atualiza o quadro TABAPPLI escrevendo o código J, os valores ADR-J, m e SGN-J, e atualiza o indicador "Carregamento/Descarregamento" posicionando-o sobre "Carregado". O sistema de exploração pode então enviar à leitora um relatório indicando que o carregamento foi corretamente efetuado.
O quadro TAB_APPLI possui então os valores seguintes:
<table>table see original document page 19</column></row><table>
Quadro 4 : TAB APPLI
Uma vez terminada a atualização do quadro TAB_APPLI, o sistema de exploração do cartão pode então lançar a aplicação J do mesmo modo que ele lançou a aplicação Keo cartão executa o comando de execução que a leitora lhe havia enviado.
Se o portador de cartão ou o fornecedor de aplicações conecta seu cartão à uma leitora e deseja executar novamente a aplicação Κ, o sistema de exploração do cartão analisa o conteúdo do quadro TAB_APPLI para determinar se esta aplicação é acessível com este cartão. No presente caso, a aplicação K está devidamente registrada em TAB_APPLI, mas ela foi descarregada na rede. Uma outra aplicação está na memória, é J e ela ocupa m octetos. O sistema de exploração testa então se a aplicação K que ocupa η octetos na memória pode ser carregada no que resta disponível na memória. Como tínhamos suposto anteriormente, a resposta a este teste é negativa. O sistema de exploração decide então descarregar a aplicação J atual para poder recarregar a aplicação K.
O comando. emitido pelo cartão, de descarregamento para a rede de J é:
<table>table see original document page 20</column></row><table>
Uma vez efetuada a operação, o indicador de carregamento da aplicação J em TAB APPLI é posicionado "Descarregado". O espaço memória estando ainda disponível, o sistema de exploração envia à leitora um comando de recarregamento da aplicação K a partir da rede. Este comando tem o formato seguinte:
<table>table see original document page 20</column></row><table>
A leitora recebe o comando e o reenvia para o banco de dados associado ao cartão C. O banco de dados que possui as informações do cartão C recebe o comando e busca no arquivo deste cartão, os η octetos de dados aplicativos relativos à aplicação Κ. O banco de dados elabora a mensagem seguinte, que é a resposta ao último comando do cartão. Esta resposta é transmitida ao cartão via a leitora:
<table>table see original document page 20</column></row><table> O sistema cie exploração do cartão pode verificar que os códigos C', K e o valor η recebidos, são bastante idênticos àqueles do comando de descarregamento emitido anteriormente. Se a identidade é realizada, o comando prossegue pela recepção dos η octetos que são escritos a partir do endereço ADR-K na zona de carregamento, este endereço sendo para este efeito lido pelo sistema de exploração no quadro TABAPPLI ou recuperado a partir das informações de contexto recarregadas. Ao mesmo tempo, o sistema de exploração calcula a assinatura dos η octetos escritos por um cálculo criptográfico utilizando o valor da chave SWAP. A assinatura recalculada é então comparada ao valor escrito no quadro TAB APPLI. Se os dados recebidos da rede não são idênticos àqueles descarregados anteriormente, os dois valores de assinatura não serão iguais. Existe, portanto, uma dúvida quanto a autenticidade ou a integridade dos dados recebidos. Os dados carregados não devem portanto ser executados. O cartão reenvia à leitora uma mensagem de erro indicando uma recepção de dados errados durante a última operação de carregamento, e a impossibilidade de executar a aplicação Κ; o sistema de exploração não coloca o indicador de carregamento em posição "carregado"; se necessário, ele pode apagar o conteúdo da aplicação K.
Se em contrapartida os dois valores de assinatura são iguais, os dados recebidos correspondem devidamente àqueles da aplicação K anteriormente carregada no cartão. Uma vez que esses controles
foram efetuados, o sistema de exploração do cartão atualiza o quadro TABAPPLI posicionando o indicador de carregamento da aplicação K na posição "Carregado".
O quadro TAB APPLI tem então os seguintes valores: <table>table see original document page 22</column></row><table>
Quadro 5 : TAB_APPLI
Uma vez terminada a atualização do quadro TAB_APPLI, o sistema de exploração lança a aplicação K como anteriormente, e o cartão pode executar o último comando de tipo aplicativo enviado pela leitora.
Foi descrito anteriormente que, quando da recepção pelo cartão de um comando de carregamento de uma aplicação não armazenada atualmente, o sistema de exploração do cartão testa o espaço disponível em memória. Se este é suficiente, o carregamento pode operar sem descarregar a aplicação atualmente em memória. Existe então duas aplicações no cartão. 0 quadro TAB APPLI toma então a configuração seguinte:
<table>table see original document page 22</column></row><table>
Quadro 6 : TAB_APPLI
Neste exemplo, duas aplicações I e K coabitam no cartão: elas são diretamente executáveis. Uma terceira aplicação J é acessível com auxílio deste cartão, mas é necessário recarregá-lo a partir da rede.
As memórias não voláteis do cartão contêm as informações seguintes:
<table>table see original document page 23</column></row><table>
Quadro 7
Este quadro corresponde ao quadro 1 precedente, no qual a área de carregamento é detalhada como segue: é visto que a área de carregamento dos dados aplicativos compreende três sub-áreas : uma área que recebe os dados da aplicação K, uma área que recebe os dados daa aplicaçíio I, e uma área residual livre que é de tamanho inferior à m.
À luz deste exemplo, é melhor compreendido as características da invenção. O cartão é dotado de um sistema de exploração mínimo permitindo gerenciar o espaço memória, carregar ou descarregar as aplicações, indicar os dados aplicativos a descarregar para a rede, verificar os dados aplicativos descarregados e recebidos da rede pela comparação das assinaturas, e lançar as aplicações carregadas na memória. A assinatura permite verificar que os dados aplicativos armazenados no banco de dados foram precedentemente bem carregados neste cartão. A leitora é dotada de um programa que reconhece os comandos de descarregamento e recarregamento do cartão e os meios para transmitir os ditos comandos à rede. Finalmente, a rede é equipada de bancos de dados, a memória desses bancos podendo ser considerada como uma extensão da memória programável do cartão.
Como observado no preâmbulo, a inscrição de rotinas na memória programável para modificar o funcionamento do programa em ROM não pode ser realizada a não ser por pessoas que conhecem este programa. Os saltos para essas rotinas e seus retornos no programa em ROM necessitam do conhecimento preciso dos endereços, dos parâmetros de entrada e de saída dessas rotinas, da utilização da memória de trabalho, etc. A presente invenção soluciona este problema evitando utilizar essas rotinas e, consequentemente, divulgar as especificações dessas rotinas, com a finalidade de autorizar a execução de numerosas aplicações. Os programas aplicativos são executados fazendo o menos possível chamada ao programa em ROM. O conceituador deste programa pode indicar os pontos de entrada para determinadas rotinas ditas elementares : recepção de octetos, emissão de octetos, escritura de η octetos em memória programável, cálculo criptográfico... etc. Um primeiro aperfeiçoamento da invenção consiste em codificar os dados aplicativos para protegê-los quando de suas diferentes transferências entre o dispositivo de processamento de dados destinado a receber as aplicações (tal como o cartão 21 ou o terminal 22 da figura 1) e a rede, e quando de seus armazenamentos exteriormente ao cartão 21 ou ao terminal 22.
Uma primeira codificação da aplicação diz respeito ao carregamento inicial por um fornecedor de aplicações e utiliza uma chave de base secreta, detida pelo dispositivo de processamento de dados e pelo fornecedor de aplicações situado na rede; no caso em que o dispositivo de processamento de dados é um cartão, sua leitora ignora a chave de base. Vantajosamente, cada aplicação é codificada com uma chave diversificada própria, obtida a partir da chave de base e de um diversificador constituído por um parâmetro específico da aplicação, por exemplo, seu código K ou seu endereço de armazenamento ADR-K na memória programável. Este diversificador pode ser armazenado no quadro TAB APPLI de modo que o sistema de exploração pode facilmente o encontrar quando dos comandos de carregamento / descarregamento.
Quando do carregamento inicial da aplicação pelo fornecedor de aplicações no dispositivo de processamento de dados 21 ou 22, este fornecedor calcula a chave diversificada associada a esta aplicação e codifica a aplicação por meio desta antes de a enviar para a rede; na recepção, o dispositivo de processamento de dados calcula a chave diversificada associada a esta aplicação e a decodifica com esta, antes de armazeriá-la na zona de carregamento da memória programável.
Uma segunda codificação da aplicação diz respeito aos descarregameritos e recarregamentos efetuados pelo dispositivo de processamento de dados 21, 22 para um banco de dados, a aplicação é novamente codificada por este dispositivo. A chave de codificação utilizada não é compartilhada pelo dispositivo de processamento de dados com qualquer outro interlocutor tal como o fornecedor de aplicações: não importa qual chave gerada pelo dispositivo de processamento de dados seja conveniente, pois é este mesmo dispositivo, e ele apenas, que efetuará a decodificação ulterior.
Vantajosamente, o cartão pode utilizar o método descrito pelo documento US-A-4.907.270 que tem por objeto fornecer um método para assegurar a autenticidade e a integridade de uma mensagem codificada.
A codificação descrita acima permite evitar que os dados aplicativos possam ser descobertos por um fraudador, e impede a cópia fraudulenta dos programas aplicativos.
Além dos comandos descritos anteriormente, é possível prever dois comandos suplementares: um comando de apagamento de aplicações, e um comando de controle de presença de aplicações no cartão.
O comando de apagamento de aplicações consiste, para o portador do cartão ou para o fornecedor de aplicações, em enviar ao cartão um comando destinado a suprimir as aplicações que não são mais utilizadas; seu formato é o seguinte:
Ordem de apagamento Cartão C Appli K númeron de aplicações
Ele compreende uma ordem de apagamento de aplicações, o código C do cartão concernente, o código K da aplicação, e eventualmente o número n de octetos de dados da aplicação. Se a aplicação concernente está carregada no cartão, o sistema de exploração do cartão torna disponível o espaço memória reservado ali para a aplicação K. Se ao contrário, a aplicação K estava descarregada num banco de dados, o cartão envia para este uma ordem de apagamento que tem o mesmo formato que aquele acima. Finalmente, uma vez que a ordem de apagamento foi executada, o sistema de exploração apaga a linha do quadro TABAPPLI concernente a esta aplicação.
O comando de controle de presença de aplicações no cartão pode tomar duas formas diferentes. A primeira forma do comando permite ao portador de cartão ou ao fornecedor de aplicações perguntar ao cartão se ele possui uma aplicação particular; se i formato é o seguinte:
<table>table see original document page 27</column></row><table>
Ela compreerde uma ordem de controle de presença de aplicações, o código C do cartão concernente, o código K da aplicação, e eventualmente o número η de octetos de dados da aplicação.
A segunda forma do comando permite ao portador de cartão ou ao fornecedor de aplicações perguntar ao cartão o conjunto de linhas de seu quadro TAB APPLI, com exclusão evidentemente das assinaturas e eventualmente do número η de octetos e o indicador de carregamento. O formato do comando é o seguinte:
<table>table see original document page 27</column></row><table>
Um segundo aperfeiçoamento da invenção consiste em desencadear o descarregame nto de uma aplicação para a rede apenas quando ela é necessária. Se, no momento quando se deve liberar da memória, a aplicação carregada não foi modificada e se a rede já possui os mesmos dados aplicativos desta aplicação, não é útil descarregar estes dados. O segundo aperfeiçoamento tem por objeto evitar armazenar várias vezes os mesmos valores de dados aplicativos na rede.
Para realizar este aperfeiçoamento é necessário modificar o quadro TABAPPLI; eis aqui a nova estrutura:
<table>table see original document page 28</column></row><table>
Quadro 8 : TAB_APPLI
Foi acrescentado uma sexta coluna ao quadro, que contém um indicador denominado "Modificação", podendo tomar dois valores : Sim ou Não. Quando do carregamento inicial de ama aplicação, o indicador é posicionado em "Sim": este valor indica que é necessário descarregar os dados aplicativos para a rede para liberar o espaço memória correspondente. Ao contrário, após um comando de recarregamentc a partir da rede, o indicador é posicionado em "Não": este valor indica que os dados aplicativos armazenados em memória programável do dispositivo de processamento de dados (cartão 21 ou terminal 22 da figura 1) são idênticos àqueles armazenados no banco de dados da rede. Desde que o indicador permaneça em "Não", o sistema de exploração do dispositivo de processamento de dados não efetua o comando de descarregamento da aplicação; ele posiciona unicamente o indicador de carregamento em posição "Descarregado" para que uma outra aplicação possa ocupar seu espaço na memória. O indicador é posicionado em "Sím" quando é modificado os dados aplicativos; consequentemente, o valor da assinatura não é mais exato : será necessário recalculá-lo quando do descarregamento.
Esta modificação pode intervir em ao menos dois casos. O primeiro caso é uma atualização do programa aplicativo, quer para torná-lo mais atuante acrescentando-se funções suplementares, quer corrigir uma falha. O segundo caso acontece freqüentemente pois, na memória programável do dispositivo de processamento de dados 21 ou 22, os dados são emaranhados no programa aplicativo. Por exemplo, uma aplicação de porta dinheiro eletrônico contém por sua vez o logicial para gerenciar os débitos e os créditos, mas também os dados referentes ao saldo. A cada utilização, este valor evolui geralmente e portanto, o indicador "Modificação" está quase sempre na posição "Sim".
Este último exemplo dá lugar a um terceiro aperfeiçoamento da presente invenção. E observado que nos dados aplicativos, existem por sua vez o programa executável e os valores de dados aplicativos suscetíveis de evoluir freqüentemente. Os meios descritos no terceiro aperfeiçoamento descrito adiante permitem separar devidamente os dois tipos de dados. O dispositivo de processamento de dados esc olhe então só descarregar para a rede os dados que ele efetivamente modificou.
Para realizar este terceiro aperfeiçoamento, convém aperfeiçoar a organização das memórias não voláteis, que pode se esquematizar do modo seguinte: <table>table see original document page 30</column></row><table>
Quadro 9
O quadro 9 difere do quadro 1 antes mencionado pela estrutura de sua área de carregamento da memória programável, que se apresenta como segue:
- um bloco relativo à aplicação enquanto tal e compreendendo dois sub-blocos de dados :
- um bloco relativo ao programa executável da aplicação, denominado "programa da aplicação" ;
- um bloco relativo aos dados (não executáveis) evolutivos da aplicação, denominado "dados da aplicação";
- um determinado número de blocos de dados (não executáveis) evolutivos correspondendo às execuções particulares do programa executável : estas execuções são denominadas em seguida 'seqüências". Por definição, os dados de uma seqüência são temporários, isto é, eles só são utilizados quando desta seqüência, e não quando das seqüências precedentes ou seguintes. E isto que os distingue dos "dados da aplicação" antes mencionados, os quais são utilizados durante todas as seqüências. No quadro 9, dois blocos de dados de seqüências são representados, marcados "dados evolutivos seqüência 1" e "dados evolutivos seqüência 2". O papel destes diferentes blocos de dados será explicado no exemplo em seguida.
Para realizar este terceiro aperfeiçoamento, o quadro TAB_APPLI é modificado, ele possui a estrutura seguinte:
<table>table see original document page 31</column></row><table>
Quadro 10 : TABAPPLI
Em comparação ao quadro TAB APPLI 1 antes mencionado, este quadro apresenta as diferenças seguintes. A primeira coluna especifica, além do código da aplicação, o número "I" da seqüência concernente. As informações 15 processadas as são em dois grupos: aquelas relativas ao programa executável e aos dados da aplicação, e aquelas relativas aos dados evolutivos das seqüências. Para cada grupo de dados, é encontrado as quatro colunas seguintes do quadro TAB APPLI 1 : endereço de armazenamento, número de octetos, assinatura, indicador de carregamento. Cada linha do quadro corresponde a uma seqüência dada P/l ou P/2 todas duas relativas a uma aplicação P, ou uma seqüência J/l ou J/2 todas duas relativas a uma outra aplicação J. Nos diferentes casos do quadro, o código da aplicação é mencionado para lembrar que o valor considerado é relativo a uma aplicação dada; por exemplo :
. ADR-Cod-P : endereço de armazenamento relativo à aplicação P
. j-cod : número de octetos relativos à aplicação J Além disso, o símbolo "Cod ' indica que o valor considerado é relativo a um dado de tipo "aplicação" (programa ou dados do primeiro grupo), enquanto "Dat" indica que o valor considerado é relativo a um dado de tipo "seqüência" (dados do segundo grupo); por exemplo :
• SGN-cod-P : assinatura de dados (programa ou dados) relativos à aplicação P
. SGN-dat-J/2 : assinatura de dados relativos à seqüência N°2 da aplicação J
Um exemplo descreverá melhor o problema enunciado e o modo de solucioná-lo utilizando a presente invenção.
O dispositivo de processamento de dados (cartão 21 neste caso) acaba de receber um comando de carregamento inicial da aplicação P : aplicação de pagamento de tipo Porta-Dinheiro Eletrônico (PME). Os dados aplicativos armazenados ein memória programável são o programa executável e os dados relativos à aplicação; ele não tem ainda os dados evolutivos correspondentes a uma seqüência. Os dados compreendem n-Cod octetos armazenados a partir de um endereço ADR-Cod-P. O indicador de carregamento é posicionado em "Carregado". Adicionalmente, os dados relativos ao programa executável e aos dados da aplicação, os dados transmitidos quando do comando contêm um número de octetos de dados evolutivos "p-dat" relativos a uma seqüência i. O quadro TABA_PPLI possui assim os valores seguintes:
<table>table see original document page 33</column></row><table>
Quadro 1 : TAB_APPLI
As transações são validadas por um circuito eletrônico denominado módulo de segurança. Este módulo pode se situar quer no terminal leitor de cartão 20 da figura 1, quer, se é desejado um máximo de segurança, num centro de aprovação bancário que pode estar situado remotamente ao terminal 20. Uma transação de tipo P.M.E. é desenvolvida em muitas etapas que necessitam comunicações entre o cartão, o terminal e o módulo de segurança. A compra pode se efetuar no estabelecimento de um comerciante dotado de um terminal com módulo, como também ser feita no domicílio do portador do cartão cujo terminal não está dotado de um módulo. O cartão é solicitado para efetuar uma compra por uma ordem de inicialização de uma transação. O sistema de exploração do cartão reconhece uma ordem de tipo aplicativo ; ele interroga então seu quadro TABAPPLI. A interrogação do quadro lhe indica que a aplicação correspondente à ordem está bem carregada e que nenhuma seqüência foi alocada. O sistema de exploração inicializa então uma seqüência lhe atribuindo um número, "1", por exemplo. Ele aloca esta seqüência num espaço memória de "n- dat" octetos, a partir do endereço ADR-Dat-P/1.
O indicador de carregamento correspondente a esta seqüência é posicionado sobre "Carregado". O quadro TAB APPLI possui assim os valores seguintes :
<table>table see original document page 34</column></row><table>
Quadro TAB_APPLI 12
Depois, o sistema de exploração do cartão lança o programa aplicativo efetuando um salto ao endereço ADR- Cod-P ; ele especifica o endereço ADR-Dat-P/1 dos dados temporários a utilizar, o que permite à aplicação conhecer o lugar onde são armazenados os dados da seqüência. Estes dados são, entre outros, o montante da transação, o objeto da transação, o estabelecimento de venda e a data da transação. Em contrapartida, um dado tal como o saldo do porta dinheiro eletrônico não é um dado temporário de seqüência, pois sua validade ou duração ultrapassa aquela de uma seqüência; sendo de tipo aplicativo, este dado é armazenado com o programa da aplicação.
A compra de um primeiro produto está em curso: o cartão envia entiío à leitora 20 uma mensagem visando obter uma validação da transação perto de um centro de pagamento acessível pela rede. Esta comunicação pode durar um certo tempo. Efetivamente, as comunicações podem ser perturbadas e os dados enviados podem ser demoradamente analisados pelo centro de aprovação bancário. Tudo isto provoca uma demora da duração global da transação. Durante este tempo, o usuário decide efetuar uma segunda compra. A presente invenção vai permitir evitar a espera do fim da primeira transação para começar a segunda.
Para efetuar esta segunda compra, o cartão é solicitado uma segunda vez para uma nova ordem de inicialização de uma transação. Do mesmo modo que anteriormente, o sistema de exploração do cartão verifica que o programa executável da aplicação PME está carregado em memória programável. Hsta verificação é efetuada interrogando seu quadro TABAPPLI; o sistema de exploração reconhece então a presença do programa e de uma seqüência (1) que está em curso. Paia isto, ele aloca a esta segunda execução um novo número de seqüência (2) e inicializa o quadro TABAPPLI adicionando uma nova linha a ele. Depois, ele verifica st existe lugar suficiente para alocar na memória programável n-dat octetos para as informações de tipo dados não executáveis. Se c espaço é suficiente, um novo endereço ADR-Dat-P/2 é determinado e a segunda transação pode ser lançada. O quadro TAB_APPLI possui os valores seguintes:
<table>table see original document page 36</column></row><table>
QuadrO TAB_APPL113
As duas transações serão então realizadas em paralelo no cartão, sem fazer chamada à rede. A leitora deve indicar nos comandos aplicativos enviados ao cartão, de qual transação ela se trata.
Se o espaço é insuficiente, o sistema de exploração do cartão decide descarregar unicamente os dados em alteração correspondentes à primeira transação (número de seqüência 1). Ele calcula então a assinatura dos ditos dados da primeira seqüência "SGN-dat-P/1", e a inscreve no quadro TAB_APPLI. Os novos dados não executáveis poderão assim estar no mesmo lugar que os dados descarregados, isto é, em um endereço comum às duas seqüências e marcado ADR-Dat-P. Depois o cartão envia à leitora o seguinte comando:
<table>table see original document page 36</column></row><table> Este comando é de estrutura idêntica àquele antes mencionado, com a seguinte diferença : a terceira casa contém um parâmetro especificando não apenas o código P da aplicação, mas também o faio que ele diz respeito a dados de tipo seqüência (pelo termo "Data"), e o número 1 da seqüência a respeito.
Depois deste comando, o quadro TABAPPLI possui os seguintes valores :
<table>table see original document page 37</column></row><table>
Quadro 1 AB_APPLI 14
Em seguida a esta operação, a segunda transação levando o número de seqüência 2 pode prosseguir.
Esta nova transação necessiia também uma validação da parte do centro de pagamento : uma solicitação é então emitida para o módulo de segurança. Suponhamos que o cartão receba neste momento uma mensagem de validação da primeira transação.
O sistema de exploração do cartão reconhece, com auxílio do número de seqüência, que esta mensagem diz respeito a uma outra transação que aquela t m curso e, pela leitura do quadro TAB_APPLI, ele reconhece a primeira transação. Para processá-la, ele deve portanto carregar os dados não executáveis da primeira transação.
Sabendo que o espaço memória é insuficiente para os dois blocos de dados., o sistema de exploração do cartão deve então descarregar os dados da segunda transação. Ele calcula então a assinatura dos ditos dados "SGN-dat-P/2", e a inscreve no quadro TAB APPLI. Depois, o cartão envia à leitora o seguinte comando:
<table>table see original document page 38</column></row><table>
O quadro TAB_APPLI possui então os valores seguintes:
<table>table see original document page 38</column></row><table>
Quadro TAB APPLI 15 O sistema de exploração do cartão envia então à leitora o comando seguinte :
<table>table see original document page 39</column></row><table>
Este comando difere do comando de recarregamento já descrito pelo fato que a terceira casa contém um parâmetro especificando não apenas o código P da aplicação, mas também o fato que ele diz respeito a dados de tipo seqüência (pelo terno "Data"), e o número 1 da seqüência respectiva.
A leitora recebe o comando e a reenvia para o banco de dados alocado notadamente no cartão. O banco de dados busca no arquivo deste cartão, os n-dat octetos de dados não executáveis relativos à aplicação P, número de seqüência 1. O banco de dados elabora a mensagem seguinte, que é a resposta ao último comando do cartão; esta resposta é transmitida ao cartão via a leitora :
<table>table see original document page 39</column></row><table>
Este comando difere da resposta a um comando de recarregamento já descrito pelo fato que a segunda casa contém uma parâmetro especificando não apenas o código P da aplicação, mas também peloo fato que ele trata de dados de tipo seqüência (pelo terno "Data"), e o número 1 da seqüência concernente.
O sistema de exploração do cartão pode efetuar uma operação preliminar segundo a qual ele verifica que os códigos C.P, o número de seqüência e o valor n-dat recebidos, são bastante idênticos àqueles do comando emitido precedentemente. Se a identidade é realizada, os n-dat octetos recebidos são armazenados a partir do endereço ADR-dat-P lido no quadro TABAPPLI. Uma vez que o último octeto foi escrito, o sistema de exploração recalcula a assinatura dos dados com auxílio de um cálculo criptográfico utilizando o valor da chave SWAP. A assinatura recalculada é então comparada ao valor "SGN-dat-P/1" escrito no quadro TAB APPLI. Se os dois valores de assinatura não forem iguais, os dados recebidos da rede são considerados como não idênticos àqueles descarregados anteriormente. O cartão reenvia à leitora uma mensagem de erro indicando a recepção de dados errados durante a última operação de carregamento, e a impossibilidade de continuar a transação.
Se os dois valores são iguais, os dados recebidos são considerados como idênticos àqueles anteriormente descarregados pelo cartão : a primeira transação pode então contiruar. O sistema de exploração do cartão a seguir atualiza o quadro TABAPPLI pelo posicionamento do indicador dos dados da aplicação P/l em "Carregado" :
<table>table see original document page 40</column></row><table>
Quadro TABAPPLI 16 A atualização do quadro TABAPPLI tendo terminado, o sistema de exploração lança a aplicação P que vai continuar a primeira transação.
A primeira transação tendo terminado, a execução do programa da aplicação termina por uma volta ao sistema de exploração que gerencia a memória virtual. O sistema de exploração reconhece então o fim da seqüência "1" e decide liberar o espaço memória correspondente aos dados da dita seqüência. Para isto, ele apaga as informações "endereço de armazenagem", "assinatura"e o indicador de carregamento/descarregamento colocando-os no valor zero.
O quadro TAB APPLI tem então os seguintes valores :
<table>table see original document page 41</column></row><table>
Quadro TABAPPLI 17
Quando o carlão recebe a validação da segunda transação, o sistema de exploração do cartão reconhece, com auxílio do número de seqüência, que esta mensagem diz respeito a uma outra transação que não está carregada. A primeira transação tendo terminado, os dados não executáveis correspondentes não são mais úteis. Não há portanto lugar para descarregá-los. É suficiente, portanto, carregar os dados não executáveis correspondentes à segunda transação. O sistema de exploração envia à leitora o seguinte comando :
<table>table see original document page 42</column></row><table>
Do mesmo modo que para o carregamento da seqüência 1, a leitora recebe o comando e a reenvia para o banco de dados. O banco de dados busca, no arquivo deste cartão, os n-dat octetos de dados não executáveis relativos à aplicação P, número de seqüência 2. O banco de dados elabora a mensagem seguinte que é transmitida ao cartão via a leitora:
<table>table see original document page 42</column></row><table>
O sistema de exploração do cartão pode efetuar uma operação preliminar segundo a qual ele verifica os códigos C, Ρ, o número de seqüência, e o valor n-dat recebidos. Se a verificação está de acordo, os octetos são escritos. Em seguida, o sistema de exploração calcula e verifica a assinatura dos dados. Se os dois valores são iguais, os dados recebidos são considerados como idênticos àqueles anteriormente descarregados pelo cartão : a segunda transação pode portanto continuar. O sistema de exploração atualiza o quadro TAB_APPLI posicionando o indicador de carregamento da aplicação 2 em "Carregado": <table>table see original document page 43</column></row><table>
Quadro TAB_APPLI 18
A atualização do quadro TAB APPLI tendo terminado, o sistema de exploração lança a aplicação P que vai continuar a segunda transação.
Tendo terminado a segunda transação, o programa da aplicação termina por uma instrução de volta ao sistema de exploração que gerencia a memória virtual. O sistema de exploração deduz que a seqüência "2" terminou; o espaço memória pode então ser liberado. Para isto, os locais, no quadro TAB_APPLI, de : "endereço de armazenamento", "assinatura" e o indicador de carregamento/descarregamento são colocados em zero. O quadro toma os seguintes valores: <table>table see original document page 44</column></row><table>
Quadro TAB_APPLI 19
Neste estado, o sistema de exploração do cartão pode apagar inteiramente uma linha do quadro TABAPPLI. O gerenciamento das linhas do quadro TAB_APPLI se efetua então dinamicamente em função das necessidades.
Um outro mrtoclo estático pode gerenciar o quadro e decidir de uma vez por todas o número de seqüências máximo executáveis para uma aplicação : seja "s" este número, "s" é então transmitido quando do comando de carregamento inicial da aplicação : o sistema de exploração reserva no quadro TAB APPLI o local correspondente a essas "s " seqüências. Tomemos, por exemplo, por s o valor 2.
O comando de carregamento da aplicação K possui os seguintes valores :
<table>table see original document page 44</column></row><table> Este comando difere daquele descrito anteriormente pelo fato que ele inclui uma quinta casa definindo o valor do parâmetro s. Será observado que aqui o comando especifica o número cle n-cod de octetos relativos à aplicação e enviados pelo comando, e o número de n-dat de octetos relativos a cada seqüência futura e reservados a este uso. Alternativamente, o número de n-dat de octetos pode não ser transmitido neste estado, porém fornecido mais tarde ao sistema de exploração do cartão pela aplicação que aqui é carregada.
Em seguida a este comando, o sistema de exploração atualiza o quadro TABAPPLI como os valores seguintes:
<table>table see original document page 45</column></row><table>
Quadro TABAPPLI 20
A aplicação K pode agora ser executada : duas seqüências são possíveis.
O cartão pode perfeitamente conter de modo virtual muitas aplicações dotadas cada uma de muitas seqüências. Por exemplo, eis a configuração particular do quadro TAB APPLI: <table>table see original document page 46</column></row><table>
Quadro TAB_APPLI 21
Correspondendo a este exemplo, o cartão possui virtualmente duas aplicações notadas: K e J. O programa executável da aplicação K não está na zona de carregamento; três seqüências desta aplicação, designadas 1, 2 e 3, podem ser executadas ao mesmo tempo. A primeira seqüência é terminada, as duas outras estão em curso de execução. A seqüência 2 é descarregada: será necessário então recarregá-la para terminá-la. Além disso, para terminar as seqüências 2 e 3, será necessário recarregar o programa executável e os dados da aplicação K.
O programa executável da aplicação J está na zona de carregamento; esta aplicação pode executar ao mesmo tempo duas seqüências, designadas 1 e 2, que estão em curso de execução. A seqüência 2 é descarregada : será necessário recarregá-la para terminá-la. Deste exemplo, é observado que aparece a necessidade de gerenciar devidamente o espaço memória disponível. É necessário ocupar o mais possível a área de carregamento e assim evitar freqüentemente os comandos de Descarregamento e Recarregamento.
Evidentemente, o aperfeiçoamento consistindo em codificar os dados, além de assiná-los, quando do descarregamento e em decodificá-los quando do carregamento/recarregamento, pode aplicar-se a este terceiro aperfeiçoamento.
Um aperfeiçoamento do procedimento de carregamento inicial de uma aplicação em cartão consiste em introduzir no cartão uma assinatura dos dados aplicativos calculada a partir de uma chave de fornecedor de aplicação. Esta assinatura permite assegurar a integridade dos dados aplicativos e autentificar a erigem desses dados aplicativos.
O carregamento inicial de acordo com o aperfeiçoamento consiste em apresentar o cartão ao fornecedor de aplicação. Ele é aconselhado a efetuar esta operação nos locais do fornecedor da aplicação. Este último introduz no cartão sua chave de fornecedor, a assinatura dos dados aplicativos, e o código da aplicação, "K" por exemplo. Um portador do cartão efetua uma solicitação de carregamento inicial da aplicação K. Esta solicitação, que foi descrita anteriormente, pode ser feita em seu domicílio. Um método para efetuar de modo segui o o carregamento inicial de uma aplicação é descrito no documento FR-A-2.748.134.
De acordo com um modo de realização alternativo da invenção, as aplicações armazenadas no cartão não são descarregadas num banco de dados distante, através de uma rede : é a leitora 20 da figura 2 que recebe e armazena essas aplicações; ela possui então para esta finalidade uma memória programável não volátil na qual são armazenadas as aplicações. Os comandos de carregamento e de descarregamento são invariáveis. Esta alternativa é interessante quando o cartão é introduzido sempre na mesma leitora, por exemplo, uma leitora localizada no domicílio do portador do cartão.
Um outro modo de realização alternativo da invenção utiliza a leitora de cartão 40 e o cartão de chip 41 da figura 4, cujos elementos comuns com aqueles da figura 2 levam as mesmas referências. O cartão 41 se distingue daquele 21 da figura 2 pelo fato que ele porta uma trilha ótica 42, por exemplo, uma trilha de escrita e leitura por raio laser. Quanto à leitora 40, ela se distingue daquela 20 pelo fato que ela comporta uma leitora de trilha ótica 43, apta a ler e escrever as informações na trilha ótica 42, ligada ao microprocessador 2 e às memórias 3,4.
De acordo com a invenção, a trilha ótica 42 é utilizada na qualidade de banco de dados, em lugar daqueles distantes 23 a 25 da figura 1. Na prática, quando do descarregamento de uma aplicação a partir do cartão 41, o cartão transmite o comando de descarregamento à leitora de cartão 40. A leitora de tri ha 43 recebe as informações da aplicação e as escreve na trilha ótica 42. Quando de um comando de recarregamento, a leitora de cartão ativa a leitora de trilha 43 para ela retire antecipadamente na pista ótica 42 as informações da aplicação: a leitora de cartão transmite em seguida essas informações ao microprocessador 9 do cartão para que este as armazene na área de carregamento. Os comandos de carregamenio e de descarregamento são entretanto imutáveis.
Alternativamente, a trilha ótica é substituída por um outro suporte de armazenamento de massa, por exemplo, uma trilha magnética.
Nos exemplos de realização precedentes, foi descrito um descarregamen*o de aplicações a partir de um dispositivo de processamento de dados para o exterior deste: no caso da figura 2, o cartão 21 efetuava um descarregamento para a leitora 20 ou para os bancos de dados 23-25 da figura 1; no caso da figura 4, o dispositivo de processamento de dados constituído pelo microprocessador 9 e suas memórias 10,14 efetuava um descarregamento para a trilha ótica 42. De acordo com uma outro modo de realização alternativo da invenção, um dispositivo de processamento de dados efetua um descarregamento enlre diversas memórias deste dispositivo. Por exemplo, este dispositivo de processamento de dados é constituído pelo cartão 21 da figura 2 e o microprocessador 9 descarrega uma aplicação a partir de sua memória RAM 14 para sua memória não volátil 10.
Por exemplo, diversas aplicações K, J são armazenadas na memória não volátil 10. Antes de mais nada, a aplicação K é executada. Nesta ocasião, os dados de trabalho Itjc relativas à aplicação K s ão tratados na memória RAM, ao passo que um programa da aplicação K fica na memória não volátil 10. Estes dados de trabalho compreendem notadamente:
- variáveis de trabalho temporárias, intervindo nos cálculos;
- variáveis de contexto, permitindo ao cartão recomeçar ulteriormente uma execução da aplicação interrompida;
- subprogramas.
Em um dado momento, o cartão deve executar a outra aplicação J e, para isto, carregar os dados de trabalho Itk na memória RAM. Se o cartão constata que o espaço livre na memória RAM é insuficiente para receber os dados de trabalho Itk, ele decide parar a execução da aplicação K e descarregar os dados de trabalho Itk da aplicação K na sua memória não volátil 10. Em seguida ele executa a aplicação J carregando os dados de trabalho Itk associados em memória RAM. Depois da execução da aplicação J, o cartão recomeça a execução da aplicação K, no lugar onde esta foi interrompida, carregando de novo os dados de trabalho Itk em memória RAM. Neste última a ariante da invenção, os comandos de carregamento e de descarregamento não são utilizados, pois o dispositivo de processamento de dados concernente não avisou um dispositivo externo para efetuar as operações de carregamento e descarregamento de suas memórias. Ele possui ainda um quadro TAB_APPLI., mas este é simplificado em relação ao quadro 2 antes mencionado: o parâmetro "assinatura dos dados" é suprimido. Efetivamente, os dados não saindo do dispositivo de processamento de dados, eles não correm o risco de serem alterados durante seu descarregamento.
Na descrição precedente, foi descrito acima de tudo a tomada de decisão, pelo cartão, do descarregamnento de um conjunto de dados a partir de uma ordem recebida pelo cartão de carregamento de um outro conjunto de dados. E observado, no entanto que, a invenção cobre também o caso onde a ordem recebida pelo cartão visa a executar uma outra operação que um carregamento de um conjunto de dados. Por exemplo, um processamento particular solicitado ao cartão pode requerer um lugar memória superior ao espaço atualmente disponível na memória do cartão : pode tratar-se notadamente de um cálculo criptográfico. Neste caso, o cartão decidirá descarregar um conjunto de dados para poder executar esta operação. Uni outro exemplo é aquele onde a ordem recebida pelo cartão é uma ordem de execução de uma aplicação K que foi anteriormente descarregada do cartão. O cartão deve portanto recarregar esta aplicação para executá- la: se o lugar memóiia é insuficiente para este recarregamento, o cartão vai decidir descarregar uma outra aplicação J, em seguida efetuar o recarregamento da aplicação K.

Claims (18)

1. Cartão de chip compreendendo meios de processamento de dados (9) e meios de armazenamento de dados principais (10, 14), para armazenar um programa, dados gerais para tornar o referido programa operável e pelo menos um conjunto de dados de sessão especifica relacionado a uma sessão particular da execução do programa, em que os referidos meios de processamento (9) compreendem: - meios para detectar, enquanto o cartão de chip está funcionando, que os meios de armazenamento principais (10,14) contêm uma quantidade de dados tal que uma operação não pode ser executada; caracterizado pelo fato que os meios de processamento (9) ainda compreendem: - meios para selecionar, nos meios de armazenamento principais, um conjunto d:; dados a descarregar (K) , cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar a execução da dita operação; - meios para descarregar c conjunto de dados a descarregar (K) nos meios de armazenamento secundários (23 a 25; 42; 53), no caso em que os ditos meios de armazenamento secundários não contêm o dito conjunto de dados a descarregar.
2. Cartão de chip, de acordo com a reivindicação 1, caracterizado pelo fato cie que compreende um quadro de carregamento (TAB_APPLI) armazenado nos meios de armazenamento principais e incluindo um indicador de armazenamento indicando, para ao menos um conjunto de informações, se este está armazenado ou não nos meios de armazenamento principais, de modo que, quando os meios de processamento (9) devem 1 er acesso ao dito conjunto de dados, eles consultam o dii.o indicador de armazenamento: e - num primeiro císo em que o indicador de armazenamento indica que o conjunto de dados está armazenado, os meios de processamento têm acesso a este; ou -num segundo caso on ie o indicador de armazenamento indica que o conjunto de dados ou informações não está armazenado, os meios de processamento enviam aos meios de armazenamento secundários (23 a 25; 42; 53) um comando de carregamento deste conjunto de dados.
3. Cartão de chip, ds acordo com a reivindicação 2, caracterizado pelo fato de que o indicador de armazenamento compreende um estado "cariegado" indicando que o conjunto de dados correspondentes foi carregado no cartão de chip a partir dos meios de armazenamento secundários (23 a 25; 42; 53), e um estado "descarregado" indicando que o conjunto de dados foi descarregado peLo cartão de chip nos meios de armazenamento secundários.
4. Cartão de chip, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende um quadro de carregamento (TAB_APPLI) armazenado nos meios de armazenamento principais (10,14) e incluindo um indicador de modificação indicando, para ao menos um conjunto de dados do qual uma primeirí. versão foi carregado no cartão de chip a partir dos meios de armazenamento secundários (23 a 25; 42; 53), se esta piimeira versão foi modificada ou não no cartão de chip, de nodo que, quando este conjunto de dados deve ser descarregado nos meios de armazenamento secundários, ele só é efetivamente descarregado se esta primeira versão foi modificada.
5. Cartão de chip, de acordo com a reivindicação 1, caracterizado pelo fato de que armazena ao menos um conjunto de dados em duas partes, a saber, um subconjunto de dados de aplicação (p-cod) contendo um programa e os dados gerais de funcionamento de uma aplicação, e um subconjunto de dados de seqüência (p-dat), contendo os dados particulares definindo uma sessão particular de funcionamento da aplicação, e que compreende os meios para detetar que diversos conjuntos de dados possuem um mesmo subconjunto de dados de aplicação (p-cod) e subconjuntos de dados de seqüência respectivos diferentes (p-dat), de modo que apenas uma vez é armazenado nos meios de armazenamento principais (10,14) o dito subconjunto de dados de aplicação e que ele associa a este cada um dos ditos subconjuntos de dados de seqüência.
6. Cartão de chip, d;; acordo com a reivindicação 5, caracterizado pelo fato de que compreende: - meios para detectar, durante seu funcionamento, que os meios de armazenamentc principais (10,14) contêm uma quantidade de dados tal que o armazenamento suplementar de um subconjunto de dados de seqüência (p-dat) a armazenar, associado a um subconjunto de dados de aplicação (p-cod) já armazenado, não é possível, - meios para selecio íar, nos meios de armazenamento principais, um subconjunto de dados de seqüência a descarregar, associado ao mesmo subconjunto de dados de aplicação, cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar o armazenamento do dito subconjunto de dados de seqüência a armazenar; - meios para descarregar este subconjunto nos ditos meios de armazenamento secundários (23 a 25; 42; 53), no caso em que os ditos meios de armazenamento secundários não contêm o dito subconjunto de dados de seqüência a descarregar; e - meios para armazenar nos meios de armazenamento principais o subconjunto d<; dados de seqüência a armazenar.
7. Cartão de chip, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende um quadro de carregamento (TAB_APPLI) armazenado nos meios de armazenamento principais e incluindo, para cada subconjunto de dados de aplicação arirazenado, um número máximo (s) de seqüências associadas, podundo ser armazenadas nos meios de armazenamento principais.
8. Cartão de chip, de acordo com a reivindicação 1, caracterizado pelo fato ce que compreende os meios para recarregar nos meios de arnazenamento principais (10,14) um conjunto de dados antecipadamente descarregado nos meios de armazenamento secundários 23 a 25; 42; 53).
9. Cartão de chip, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende um quadro de carregamento (TAB_APPLI) armazenado nos meios de armazenamento principais (10,14) e incluindo, para ao menos um conjunto de dados (K) tratado pelo dispositivo, uma primeira assinatura (SGN-K) deste conjunto de dados calculada pelos meios de processamento (9) antes do descarregamento eventual io conjunto de dados, com uma chave de assinatura (SWAP) armazenada nos meios de armazenamento principais, os meios de processamento sendo dispostos para calcular uma segunda assinatura do conjunto de dados armazenado, para comparar esta segunda assinatura com a primeira, para validar o recarregamento do conjunto de dados no caso onde as ciuas assinaturas são idênticas, e para invalidar o recarregamento do conjunto de dados no caso em que as duas assinaturas são diferentes.
10. Método de gerenciamento da memória em um cartão de chip compreendendo meios de processamento de dados (9) e meios de armazenamento de dados principais (10, 14) para armazenar um programa, dados gerais para tornar o referido programa operável e pelo menos um conjunto de dados de sessão especifica relacior.ado a uma sessão particular da execução do programa, compreendendo as etapas consistindo em: - detectar, durante o funcionamento do cartão de chip, que os meios de armazenamento principais (10, 14) contêm uma quantidade de dados de modo que a execução de uma operação não é possível; caracterizado pelo fato de que também compreende as etapa:; consistindo em: - selecionar, nos me: os de armazenamento principais, um conjunto de dados a descarregar (K) , cujo descarregamento pode liberar nos meios de armazenamento principais um espaço sufic iente para autorizar a execução da dita operação; - descarregar o conjunto de dados a descarregar (K) nos meios de armazenamento secundários (23 a 25; 42; 53), no caso em que os ditos meios de armazenamento secundários não contêm o dito conjunto de dados a descarregar.
11. Método, de accrdo com a reivindicação 10, caracterizado pelo fato de que compreende as etapas consistindo em: - detectar, durante o funcionamento do cartão de chip, que os meios de armazenamento principais (10,14) contêm uma quantidade de dados tal que um armazenamento suplementar de um dado conjunto de dadoí antecipadamente descarregado é possível; - recarregar nos meies de armazenamento principais o dito conjunto de dados descarregado.
12. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende as etapas consistindo em: - detectar, durante o funcionamento do cartão de chip, que os meios de armazenamento principais (10,14) contêm uma quantidade de dados tal qu<:; um armazenamento suplementar de um dado conjunto de dados antecipadamente descarregado (K) não é possível; - selecionar, nos me: os de armazenamento principais, um conjunto de dados a descarregar (J), cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar o armazenamento do dito conjunto de dados antecipadamente descarregado; - descarregar o conjunto de dados a descarregar (J) nos meios de armazenamento secundários (23 a 25; 42; 53) , no caso em que os ditos meios de armazenamento secundários não contêm o dito conjunto de dados a descarregar; e - recarregar nos meie s de armazenamento principais o dito conjunto de dados antecipadamente descarregado (K).
13. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que os ditos meios de armazenamento secundários compreendem um banco de dados (23-25) distante do cartão de chip e ligado a este por uma rede de transmissão de dados (26).
14. Método, de accrdo com a reivindicação 10, caracterizado pelo fato de que os ditos meios de armazenamento secundários pertencem a um dispositivo de processamento de dados (2)) que coopera com o cartão de chip (21).
15. Método, de accrdo com a reivindicação 10, caracterizado pelo fato de que os ditos meios de armazenamento secundários (42;53) pertencem ao cartão de chip.
16. Método, de acordc com a reivindicação 10, usando um protocolo de comunicação entre um cartão de chip (21) e uma leitora de cartão de chip (20), o referido método caracterizado pelo fato de que compreende as etapas consistindo em que: - a leitora (20) transmite ao cartão de chip uma ordem de execução de uma operação; o cartão (21) consulta se, para executar esta operação, ele dispõe de um lugar suficiente nos meios de armazenamento principais; - no caso afirmativo, o cartão (21) executa a dita operação depois transmite um relatório de execução à leitora; - no caso negativo, o cartão (21) seleciona nos meios de armazenamento principais um conjunto de dados a descarregar (K) cujo desça: regamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar a execução da dica operação, em seguida o cartão descarrega o conjunto de dados a descarregar (K) nos meios de armazenamento secundáiios transmitindo uma ordem de descarregamento à leitora (20), no caso em que os ditos meios de armazenamento secundários (23 a 25; 42; 53) não contêm o dito conjunto de dados a descarregar, depois ele executa a dita operação, depois transmite um relatório de execução à leitora (20).
17. Método, de accrdo com a reivindicação 16, caracterizado pelo fato de que a dita operação é um carregamento de um conjunto de dados a armazenar (J), as etapas consistindo em que: - a leitora (20) transmite ao cartão uma ordem de carregamento do dito conjunto de dados a armazenar (J); - o cartão (21) consulta se, para executar esta ordem de carregamento, ele dispõe de um lugar suficiente nos meios de armazenamento principais; - no caso afirmativo, o cartão (21) executa a ordem de carregamento depois transmite um relatório de execução à leitora (20); - no caso negativo, o cartão (21): - transmite à leitora (20) uma ordem de suspensão do carregamento; - seleciona nos meio; de armazenamento principais um conjunto de dados a descarregar (K) cujo descarregamento pode liberar nos meios de armazenamento principais um espaço suficiente para autorizar a execução da ordem de carregamento; - descarrega o conjunl o de dados a descarregar (K) nos meios de armazenamento secundários transmitindo uma ordem de descarregamento à leitora, no caso em que os ditos meios de armazenamento secundários (23 a 25; 42; 53) não contêm o dito conjunto de dados a descarregar; - transmite à leitora (20) uma ordem de recomeço do carregamento; - executa o dito cí rregamento depois transmite um relatório de execução à le:tora (20).
18. Método, de accrdo com a reivindicação 16, caracterizado pelo fato de que a dita ordem de execução de uma operação consiste, pari a leitora (20), em desencadear uma alimentação de energia elétrica do cartão (21).
BRPI9906355-7A 1998-04-15 1999-04-14 cartão de chip compreendendo meios para gerenciar uma memória virtual, método e protocolo de comunicação associados. BR9906355B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9804693A FR2777673B1 (fr) 1998-04-15 1998-04-15 Dispositif de traitement de l'information comprenant des moyens pour gerer une memoire virtuelle, et procede de stockage d'informations associe
FR98/04693 1998-04-15
PCT/FR1999/000877 WO1999053401A2 (fr) 1998-04-15 1999-04-14 Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes

Publications (2)

Publication Number Publication Date
BR9906355A BR9906355A (pt) 2000-09-19
BR9906355B1 true BR9906355B1 (pt) 2012-01-24

Family

ID=9525264

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI9906355-7A BR9906355B1 (pt) 1998-04-15 1999-04-14 cartão de chip compreendendo meios para gerenciar uma memória virtual, método e protocolo de comunicação associados.

Country Status (16)

Country Link
US (1) US6687800B1 (pt)
EP (1) EP0990204B1 (pt)
JP (1) JP3575697B2 (pt)
KR (1) KR100760275B1 (pt)
CN (1) CN1130629C (pt)
AR (1) AR016464A1 (pt)
AU (1) AU774140B2 (pt)
BR (1) BR9906355B1 (pt)
CA (1) CA2293297C (pt)
DE (1) DE69938702D1 (pt)
FR (1) FR2777673B1 (pt)
HK (1) HK1032125A1 (pt)
NO (1) NO325907B1 (pt)
TW (1) TW432853B (pt)
WO (1) WO1999053401A2 (pt)
ZA (1) ZA997683B (pt)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031442A2 (en) * 1999-10-22 2001-05-03 General Instrument Corporation Management of volatile and non-volatile memory resources in digital communications terminals
DE10015775A1 (de) * 2000-03-30 2001-10-04 Deutsche Telekom Ag Kartenmaterial und Verfahren zum Betreiben eines Kartenterminals
US6629227B1 (en) 2000-05-04 2003-09-30 Scientific-Atlanta, Inc. System and method for a communication terminal to manage memory and maintain a current application version for multiple applications
JP4568963B2 (ja) 2000-06-08 2010-10-27 ソニー株式会社 情報処理装置、情報通信システム
DE10040974A1 (de) 2000-08-22 2002-03-14 Giesecke & Devrient Gmbh Verfahren zur virtuellen Vergrößerung des Stacks eines tragbaren Datenträgers
FR2816729B1 (fr) * 2000-11-14 2003-02-07 Gemplus Card Int Procede de verification avant activation d'un programme charge dans une carte a puce
FR2817055B1 (fr) * 2000-11-22 2003-02-14 Gemplus Card Int Execution d'une application dans un objet electronique portable a faible capacite de memoire
JP3805211B2 (ja) 2001-06-11 2006-08-02 株式会社東芝 サービス提供方法及びサービス提供装置
US6941135B2 (en) * 2001-08-13 2005-09-06 Qualcomm Inc. System and method for temporary application component deletion and reload on a wireless device
JP2003108939A (ja) * 2001-09-27 2003-04-11 Dainippon Printing Co Ltd Icカードへのアプリケーション追加システム
FR2832821B1 (fr) * 2001-11-29 2004-04-23 Gemplus Card Int Procede de verification de codes pour microcircuits a ressources limitees
ES2387763T3 (es) * 2002-05-06 2012-10-01 Swisscom Ag Sistema y procedimiento para la administración de recursos de módulos de recursos portátiles
EP1450297A1 (en) * 2002-10-04 2004-08-25 Sony Corporation Data management system, data management method, virtual memory device, virtual memory control method, reader/writer device, ic module access device, and ic module access control method
DE10312774A1 (de) * 2003-03-21 2004-10-14 Deutsche Telekom Ag Verfahren und Kommunikationssystem zur Freigabe einer Datenverarbeitungseinheit
US20040199787A1 (en) * 2003-04-02 2004-10-07 Sun Microsystems, Inc., A Delaware Corporation Card device resource access control
US6996070B2 (en) * 2003-12-05 2006-02-07 Alacritech, Inc. TCP/IP offload device with reduced sequential processing
EP1901207A4 (en) * 2005-06-29 2009-10-28 Panasonic Corp MOBILE END UNIT WITH NON-CONTACT CHIP CARD
US20070197202A1 (en) * 2006-02-17 2007-08-23 Sprigg Stephen A System and method for application auto-disable/restore enhancement
FR2928754B1 (fr) * 2008-03-13 2012-05-18 Sagem Securite Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant
DE102009037235A1 (de) 2008-10-14 2010-04-15 Giesecke & Devrient Gmbh Speicherverwaltung in einem portablem Datenträger
US8566481B2 (en) 2009-06-10 2013-10-22 Cisco Technology, Inc. Managing configuration data
ES2524242T3 (es) * 2010-08-05 2014-12-04 Gemalto Sa Sistema y procedimiento para utilizar con total seguridad múltiples perfiles de abonados con un componente de seguridad y un dispositivo de telecomunicación móvil
JP2012027929A (ja) * 2011-08-31 2012-02-09 Sandisk Il Ltd スマートカード上の内部アプリケーションのローディング
CN103425539B (zh) * 2012-05-14 2016-04-27 联想(北京)有限公司 信息处理方法及装置
EP3093761A1 (en) * 2015-05-13 2016-11-16 Gemalto Sa Integrated circuit card adapted to transfer first data from a first application for use by a second application

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63228852A (ja) * 1987-03-17 1988-09-22 Omron Tateisi Electronics Co Idシステムの通信制御方式
JP2776929B2 (ja) * 1989-03-29 1998-07-16 株式会社日立製作所 カードデータ処理システム及びカードデータの処理方法
DE69330691T2 (de) * 1992-06-03 2002-07-04 Sun Microsystems Inc Dynamisch konfigurierbares Kernsystem
FR2704704B1 (fr) 1993-04-28 1995-09-01 Gemplus Card Int Systeme de communication.
JPH07210395A (ja) * 1994-01-10 1995-08-11 Fujitsu Ltd ファームウェアメンテナンス方式
FR2736735B1 (fr) * 1995-07-11 1997-09-19 Mireille Campana Systeme de chargement du logiciel dans des organes de telephonie et notamment dans des publiphones
US5859982A (en) * 1996-06-05 1999-01-12 Sun Microsystems, Inc. Computer system and method for executing methods of downloaded programs with reduced run-time memory space requirements

Also Published As

Publication number Publication date
KR100760275B1 (ko) 2007-09-19
NO996177L (no) 2000-02-11
EP0990204A2 (fr) 2000-04-05
JP2001502099A (ja) 2001-02-13
WO1999053401A3 (fr) 1999-12-29
JP3575697B2 (ja) 2004-10-13
AU3154199A (en) 1999-11-01
AU774140B2 (en) 2004-06-17
FR2777673B1 (fr) 2001-09-21
TW432853B (en) 2001-05-01
CA2293297C (en) 2005-10-25
WO1999053401A2 (fr) 1999-10-21
BR9906355A (pt) 2000-09-19
US6687800B1 (en) 2004-02-03
HK1032125A1 (en) 2001-07-06
EP0990204B1 (fr) 2008-05-14
ZA997683B (en) 2001-03-14
KR20010013827A (ko) 2001-02-26
AR016464A1 (es) 2001-07-04
CN1272187A (zh) 2000-11-01
DE69938702D1 (de) 2008-06-26
CN1130629C (zh) 2003-12-10
CA2293297A1 (en) 1999-10-21
NO996177D0 (no) 1999-12-14
NO325907B1 (no) 2008-08-11
FR2777673A1 (fr) 1999-10-22

Similar Documents

Publication Publication Date Title
BR9906355B1 (pt) cartão de chip compreendendo meios para gerenciar uma memória virtual, método e protocolo de comunicação associados.
EP0981807B1 (en) Integrated circuit card with application history list
CA2281576C (en) Multi-application ic card system
US7584358B2 (en) Tamper resistant module certification authority
US8811971B2 (en) Mobile communication device and method for disabling applications
JP4906168B2 (ja) Icカードのための鍵配送ユニット
CN101965597B (zh) 用于安装和取回已链接的mifare应用的方法和设备
JP4127862B2 (ja) Icカード配送鍵セット
US6488211B1 (en) System and method for flexibly loading in IC card
JP4806639B2 (ja) セキュアデバイス及びicカード発行システム
AU762165B2 (en) Methods and apparatus for authenticating the download of information onto a smart card
JP7439847B2 (ja) 電子情報記憶媒体、鍵データ設定方法、及びプログラム
WO1998052152A2 (en) Communication between interface device and ic card
JPS62159295A (ja) 携帯可能電子装置
MXPA99011751A (en) Chip card comprising means for managing a virtual memory, associated communication method and protocol
JP2023046168A (ja) Icカード,icチップおよび認証結果の記録方法
JPH03224083A (ja) 携帯可能電子装置
JPS62269289A (ja) 携帯可能電子装置

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: CP8 TECHNOLOGIES (FR)

Free format text: TRANSFERIDO DE: BULL CP8

B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B06G Technical and formal requirements: other requirements [chapter 6.7 patent gazette]

Free format text: AFIM DE ATENDER A PETICAO NO 020100095427 DE 11/10/2010, APRESENTE O REQUERENTE PROCURACAO ORIGINAL OU COPIA AUTENTICADA EM CARTORIO.

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 24/01/2012, OBSERVADAS AS CONDICOES LEGAIS.

B21A Patent or certificate of addition expired [chapter 21.1 patent gazette]

Free format text: PATENTE EXTINTA EM 24.01.2022