BR102022007423A2 - Gerenciamento de memória em um dispositivo de processamento de transações - Google Patents

Gerenciamento de memória em um dispositivo de processamento de transações Download PDF

Info

Publication number
BR102022007423A2
BR102022007423A2 BR102022007423-2A BR102022007423A BR102022007423A2 BR 102022007423 A2 BR102022007423 A2 BR 102022007423A2 BR 102022007423 A BR102022007423 A BR 102022007423A BR 102022007423 A2 BR102022007423 A2 BR 102022007423A2
Authority
BR
Brazil
Prior art keywords
transaction
terminal
memory area
during
generation counter
Prior art date
Application number
BR102022007423-2A
Other languages
English (en)
Inventor
Emmanuelle Dottax
Lauren DEL GIUDICE
Original Assignee
Idemia France
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 by Idemia France filed Critical Idemia France
Publication of BR102022007423A2 publication Critical patent/BR102022007423A2/pt

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

A invenção propõe um método em um primeiro dispositivo (C1) compreendendo um histórico de transações e um contador de geração, este dispositivo processando transações com um segundo dispositivo (C2). Durante uma transação atual (TRX): recebimento de dados compreendendo uma chave pública do segundo dispositivo, um contador de segunda geração e um identificador da transação atual; verificação de que os contadores de primeira e segunda geração coincidem; verificação de que o histórico compreende uma entrada associada à chave pública; aprovação da transação atual se o identificador da transação satisfizer uma condição que indica a exclusividade da transação atual; armazenamento no histórico de uma nova entrada com a chave pública; e atualização de saldo de conta para pagamento de crédito em conta (U1). O método compreende ainda: detecção de risco de saturação da memória do primeiro dispositivo; atualização do contador de primeira geração e despejo da memória.

Description

GERENCIAMENTO DE MEMÓRIA EM UM DISPOSITIVO DE PROCESSAMENTO DE TRANSAÇÕES Antecedentes da invenção
[001] A invenção refere-se ao campo de dispositivos capazes de processar transações eletrônicas, como transações de pagamento ou transações de reputação, por exemplo, bem como a métodos para implementar tais transações. A invenção refere-se particularmente ao processamento de transações usando mecanismos criptográficos para garantir as referidas transações.
[002] A invenção aplica-se em particular, mas não exclusivamente, a dispositivos de pagamento para fazer pagamentos peer-to-peer em uma moeda criptográfica (ou criptomoeda), ou seja, uma moeda virtual utilizável em uma rede de computadores descentralizada pública ou privada. Estão também previstas outras aplicações destinadas à transferência eletrônica de créditos de diversas naturezas.
[003] É conhecido o uso de dispositivos de pagamento que implementam uma carteira virtual para receber ou efetuar um pagamento em qualquer moeda criptográfica. Uma moeda virtual do tipo criptográfico bem conhecida hoje é o Ether, que é baseado em um sistema de pagamento chamado Ethereum. O sistema Ethereum permite realizar transações conta a conta, por meio de software denominado wallet implementado em dispositivos de processamento apropriados (smartphones, computadores etc.). A validade de cada transação é verificada por terminais de verificação (ou software) chamados "validadores". Uma vez validadas as transações, elas são submetidas pelos “mineradores” a um registro público chamado blockchain devido à sua estrutura composta por uma série de blocos. Cada bloco define transações validadas pelos validadores e se refere a transações anteriores.
[004] Uma carteira virtual permite particularmente criar uma conta e fazer transações em Ether com uma conta de terceiros. Durante uma transação de pagamento, por exemplo, a conta da carteira virtual é debitada com um determinado valor em Ether para creditar a conta de terceiros.
[005] De maneira conhecida, um dispositivo de transação pode ser usado para fazer uma transação em modo online (isto é, cooperando com um servidor remoto pertencente a um sistema online de um operador terceirizado) ou em modo offline (ou seja, sem cooperar com um servidor remoto, mas cooperando diretamente com um dispositivo peer, no modo peer-to-peer).
[006] Para processar transações eletrônicas, como transações de pagamento, por exemplo, um dispositivo pode ser configurado para registrar em sua memória interna dados de transações representativos de transações previamente aprovadas. Um dispositivo pode, em particular, armazenar um histórico de transações para permitir o monitoramento das transações aprovadas por este dispositivo, particularmente para identificar pagamentos recebidos de outro dispositivo. Esse histórico pode ser usado, em particular, para garantir o processamento de transações.
[007] No entanto, o espaço de memória necessário para armazenar esses dados históricos em um dispositivo de processamento aumenta à medida que novas transações são aprovadas (ou recebidas) por esse dispositivo. Os recursos de memória e os recursos necessários para gerar tal memória são geralmente relativamente limitados, devido à própria natureza dos dispositivos utilizados para processar as transações. Particularmente, embora outros tipos de equipamentos sejam possíveis, dispositivos móveis, como cartões inteligentes ou terminais móveis (smartphones, tablets), que possuem memórias e recursos de processamento relativamente limitados, são frequentemente usados.
[008] Existe, portanto, a necessidade de uma solução que permita uma gestão eficiente da memória num dispositivo de processamento de transações, sem que isso comprometa a segurança das transações efetuadas.
[009] Esta necessidade de otimizar o uso do espaço de memória em tais dispositivos de processamento aplica-se ao processamento de quaisquer transações eletrônicas, como transações de pagamento, transações de reputação destinadas a transferir créditos de reputação (por exemplo, a forma de "Curtir") ou a todos os outros tipos de transações que permitem transferir um crédito de um determinado valor e de uma determinada natureza de um dispositivo denominado dispositivo de "débito" (ou pagador) para outro dispositivo denominado dispositivo de "crédito" (ou receptor).
[010] O gerenciamento da memória deve ser feito garantindo a segurança das transações, inclusive as realizadas em modo offline pelos dispositivos de processamento em questão. Particularmente, é importante evitar pagamentos duplos e, de forma mais geral, garantir que o mesmo dispositivo de crédito não possa aprovar os mesmos créditos de um dispositivo de débito várias vezes.
Objeto e resumo da invenção
[011] Para tanto, a presente invenção refere-se a um método de controle (também denominado "método") implementado por um primeiro dispositivo capaz de processar transações em cooperação com um segundo dispositivo, compreendendo o primeiro dispositivo: - uma primeira área de memória na qual um histórico (H1) compreendendo uma ou várias entradas representativas de uma transação é armazenado, e - uma segunda área de memória na qual um contador de primeira geração definido para um valor inicial é armazenado, o método compreendendo, durante o processamento de uma transação atual:
a) consulta da segunda área de memória para determinar o contador de primeira geração em um momento atual durante o qual a transação atual é processada.
b) recebimento, vindo do segundo dispositivo, dos primeiros dados compreendendo segundos dados, os referidos segundos dados compreendendo:
- uma chave pública do segundo dispositivo,
- um valor de um crédito a ser pago durante a transação atual,
- um contador de segunda geração, e
- um primeiro identificador de transação alocado pelo segundo dispositivo para a transação atual;
c) verificação de que os contadores de primeira e segunda geração possuem valores iguais;
d) se o resultado da verificação c) for negativo, negação da transação atual pelo referido primeiro dispositivo;
e) se o resultado da verificação c) for positivo, verificação na primeira área de memória de que o histórico compreende uma entrada associada à chave pública do segundo dispositivo;
f) se o resultado da verificação e) for negativo, a transação atual é aprovada;
g) se o resultado da verificação e) for positivo, verificação de que o primeiro identificador de transação satisfaz uma primeira condição predeterminada indicando a unicidade da transação atual;
h) se o resultado da verificação g) for positivo, a transação atual é aprovada; em que, se a transação atual for aprovada, o processamento da transação atual compreende ainda:
i) armazenamento no histórico de uma nova entrada associada à chave pública do segundo dispositivo; e
j) atualização de um saldo de conta armazenado na segunda área de memória, de modo a pagar o valor do referido crédito à conta associada ao primeiro dispositivo; o método compreendendo ainda uma etapa de gerenciamento da primeira área de memória, a referida etapa de gerenciamento sendo implementada antes, durante ou após uma transação atual e compreendendo:
k) detecção de que o espaço ocupado na primeira área de memória satisfaz uma segunda condição predeterminada indicando um risco de saturação da referida primeira área de memória; e
l) em resposta à detecção k), implementação de um processo de despejo compreendendo:
l1) atualização do contador de primeira geração na segunda área de memória de modo a atribuir ao referido contador de primeira geração um novo valor diferente do valor inicial; e
l2) despejo de pelo menos parte da primeira área de memória para liberar espaço de memória, quando a referida etapa de gerenciamento é implementada durante a transação atual, ela é implementada com exceção dos seguintes momentos:
- entre e durante a etapa de consulta da segunda área de memória para determinar o contador de primeira geração em um momento atual durante o qual a transação atual é processada e a etapa A30, se o teste da etapa A26 for positivo.
- entre e durante a etapa de consulta da segunda área de memória para determinar o contador de primeira geração em um momento atual durante o qual a transação atual é processada e a etapa A26, se o teste da etapa A26 for negativo.
- Entre e durante a etapa de consulta da segunda área de memória para determinar o contador de primeira geração em um momento atual durante o qual a transação atual é processada e a etapa A40.
[012] A invenção permite gerenciar com eficiência a memória do primeiro dispositivo, sem comprometer a segurança das transações realizadas. De fato, o histórico de transações aumenta de tamanho à medida que novos créditos são recebidos pelo primeiro dispositivo. A etapa de gerenciamento permite liberar espaço de memória na primeira área de memória se necessário, ou seja, quando for detectado um risco de saturação dessa área de memória, de modo que sempre haja espaço de memória suficiente para registrar um histórico recente de transações. Para isso, é realizado um processo de despejo para excluir toda ou parte da primeira área de memória ao detectar que essa memória poderá estar saturada em breve. Excluindo particularmente todo ou parte do histórico compreendido na primeira área de memória, é possível evitar atingir a saturação da referida primeira área de memória, o que causaria dificuldades na operação do primeiro dispositivo. Esse mecanismo de despejo (ou purga) de memória é ainda mais útil, pois os recursos de memória podem ser relativamente limitados em alguns tipos de dispositivos, como terminais móveis, cartões inteligentes etc.
[013] Além disso, o gerenciamento da primeira área de memória é realizado garantindo a segurança das transações, incluindo aquelas realizadas em modo off-line pelo primeiro dispositivo com dispositivos externos, como o segundo dispositivo. Particularmente, a invenção permite evitar pagamentos em duplicidade e, de maneira mais geral, garantir que o mesmo dispositivo de crédito não possa aprovar os mesmos créditos de um dispositivo de débito várias vezes. De fato, a eliminação da primeira área de memória causa uma perda parcial ou total do histórico H1, de modo que nem sempre é possível que o primeiro dispositivo conte com o histórico durante o processamento de uma transação atual. O recurso ao contador de geração conforme definido acima, e conforme descrito abaixo em exemplos particulares, permite resolver este problema e, assim, processar as transações de maneira segura.
[014] De acordo com uma modalidade particular, o processamento da transação atual compreende, antes da etapa b):
m) envio ao segundo dispositivo de terceiros dados para solicitar o pagamento pelo segundo dispositivo do valor do referido crédito na conta associada ao primeiro dispositivo, compreendendo os referidos terceiros dados o contador de primeira geração definido para o valor inicial.
[015] De acordo com uma modalidade particular, a atualização l1) é realizada entre o envio m) e o recebimento b), causando a detecção de uma incompatibilidade dos contadores de primeira e segunda geração durante a verificação c).
[016] De acordo com uma modalidade particular, os terceiros dados compreendem ainda uma primeira chave pública do primeiro dispositivo, o processamento da transação atual compreendendo ainda:
  • - recepção nos segundos dados de uma segunda chave pública do primeiro dispositivo;
  • - verificação de que a primeira e a segunda chaves públicas do primeiro dispositivo coincidem; em que a transação atual é aprovada apenas se a primeira e a segunda chaves públicas do primeiro dispositivo coincidirem.
[017] De acordo com uma modalidade específica, os terceiros dados compreendem ainda um segundo valor do crédito a ser pago, compreendendo ainda o processamento da transação atual:
- verificação de que o valor do crédito a pagar e o segundo valor do crédito a pagar coincidem (ou verificação de que o valor do crédito a pagar é superior ao segundo valor); em que a transação atual é aprovada apenas se o valor do crédito a pagar e o segundo valor coincidirem (ou se o valor do crédito a pagar for maior que o segundo valor)
[018] De acordo com uma modalidade particular, os primeiros dados recebidos em b) compreendem:
- uma primeira assinatura calculada a partir dos segundos dados, e
- uma segunda assinatura calculada a partir dos segundos dados e da primeira assinatura;
o método compreende, após o recebimento b):
n) verificação da segunda assinatura a partir da primeira assinatura e dos segundos dados recebidos nos primeiros dados e de uma chave pública de grupo associada a um grupo ao qual pertencem o primeiro e o segundo dispositivos; a transação atual sendo aprovada somente se o resultado da verificação n) for positivo.
[019] De acordo com uma modalidade particular, se for determinado durante a verificação c) que os contadores de primeira e segunda geração possuem valores diferentes, a transação atual é bloqueada (ou rejeitada).
[020] De acordo com uma modalidade particular, durante a verificação c), o primeiro dispositivo determina que os contadores de primeira e segunda geração têm valores que não coincidem se o contador de segunda geração recebido nos segundos dados tiver um valor antigo definido pelo primeiro dispositivo antes de uma atualização anterior l1) do contador de geração (ou seja, antes de uma última atualização (ou modificação) do contador de geração que ocorreu antes da atualização l1)).
[021] De acordo com uma modalidade particular, o primeiro identificador de transação alocado pelo segundo dispositivo é um contador representativo de um número atual de transações feitas pelo segundo dispositivo.
[022] De acordo com uma modalidade particular, durante o armazenamento i), a nova entrada é associada à chave pública do segundo dispositivo e ao primeiro identificador de transação; em que a verificação g) compreende:
- determinação de um segundo identificador de transação armazenado, em associação com a chave pública do segundo dispositivo, em uma entrada detectada no histórico durante a verificação e); e
- comparação do primeiro identificador de transação com o segundo identificador de transação,em que a primeira condição predeterminada é detectada para ser satisfeita se o primeiro e o segundo identificadores de transação forem diferentes ou se o primeiro e o segundo identificadores de transação forem contadores de modo que o primeiro identificador de transação seja maior que o segundo identificador de transação.
[023] De acordo com uma modalidade particular, o método é implementado por uma primeira carteira virtual implementada pelo primeiro dispositivo, em cooperação com uma segunda carteira virtual implementada no segundo dispositivo, sendo a transação atual uma transação de pagamento do referido crédito em uma moeda criptográfica.
[024] De acordo com uma modalidade particular, a transação atual é uma transação de reputação e o crédito pago durante a referida transação de reputação é um crédito de reputação.
[025] De acordo com uma modalidade particular, o primeiro e o segundo dispositivos cooperam durante o processamento da transação atual no modo peer-to-peer.
[026] De acordo com uma modalidade particular, o primeiro dispositivo é um dispositivo entre: um cartão inteligente e um terminal. Da mesma forma, o segundo dispositivo pode ser um cartão inteligente ou um terminal. Geralmente, o primeiro e o segundo dispositivos podem compreender um elemento seguro (conforme desenvolvido em mais detalhes abaixo).
[027] De acordo com uma forma de realização particular, durante a detecção k), a segunda condição predeterminada é satisfeita se o espaço ocupado na área de memória atingir uma porção predeterminada do espaço total da primeira área de memória.
[028] De acordo com uma modalidade particular, na qual a atualização em l1) do contador de primeira geração é realizada incrementando o valor atual do referido contador de primeira geração.
[029] De acordo com uma forma de realização particular, durante o despejo l2), toda a primeira área de memória é esvaziada para liberar espaço de memória.
[030] De acordo com uma modalidade particular, durante o processo de despejo l):
- a atualização l1) e o despejo l2) sejam realizados concomitantemente, ou
- o despejo l2) é realizado após a atualização l1).
[031] De acordo com uma forma de realização particular, a atualização l1) do contador de primeira geração provoca o bloqueio de todas as transações, processadas pelo primeiro dispositivo, para as quais o contador de segunda geração recebido em b) tem um valor diferente do novo valor.
[032] De acordo com uma modalidade particular, a etapa de gerenciamento da primeira área de memória compreende, em resposta à detecção k) e antes do processo de despejo l):
o) envio de um pedido de transação online para um sistema online composto por pelo menos um servidor;
p) recebimento, em resposta à referida solicitação de transação on-line, de dados de transação on-line representativos de pelo menos uma transação on-line feita pelo referido sistema on-line em cooperação com pelo menos um dispositivo externo para pagar um crédito na conta associada ao primeiro dispositivo, o referido dados de transações online compreendendo um contador de terceira geração associado a cada transação online; e
q) verificação para cada transação online de que os contadores de primeira e terceira geração possuem valores iguais; e
r) atualização, a partir dos dados de transações online correspondentes a cada transação online cujo contador de terceira geração coincida com o contador de primeira geração, do saldo de conta armazenado na segunda área de memória.
[033] De acordo com uma modalidade particular, o processo de despejo l) compreende, após a atualização l1):
s) envio para o sistema online do contador de primeira geração com o novo valor atribuído em l1), para que o servidor online possa associar a chave pública do primeiro dispositivo com o contador de primeira geração configurado para o novo valor para permitir sua acesso a pelo menos um dispositivo externo para processar transações subsequentes.
[034] De acordo com uma forma de realização particular, o envio de s) provoca a atualização pelo sistema online de um valor atual do contador de terceira geração para que seja igual ao novo valor.
[035] A invenção também se refere a um segundo método de controle implementado por um sistema compreendendo um primeiro dispositivo que implementa um método como definido acima e um segundo dispositivo cooperando com o primeiro dispositivo, o segundo método compreendendo:
t) aquisição, pelo segundo dispositivo, da chave pública do segundo dispositivo, do valor do crédito a ser pago durante a transação atual, do contador de segunda geração e do primeiro identificador de transação alocado pelo segundo dispositivo para a transação atual; e
u) envio, pelo segundo dispositivo, para o primeiro dispositivo, dos primeiros dados que compõem os segundos dados, para efetuar o pagamento do valor do crédito na conta associada ao primeiro dispositivo.
[036] De acordo com uma modalidade particular, o método compreende ainda:
  • - geração da primeira assinatura calculada a partir dos segundos dados e da chave secreta do segundo dispositivo,
  • - geração da segunda assinatura calculada a partir dos segundos dados, da primeira assinatura e de uma chave secreta de grupo.
[037] Em uma modalidade particular, as várias etapas do método de controle são determinadas pelas instruções do programa de computador.
[038] Consequentemente, a invenção também se refere a um programa de computador em um meio de informação (ou meio de gravação), sendo provável que este programa seja implementado em um dispositivo (ou dispositivo de processamento) ou mais geralmente em um computador, incluindo este programa instruções adaptadas à implementação das etapas de um método de controle, conforme definido neste documento.
[039] Este programa pode usar qualquer linguagem de programação e estar na forma de código-fonte, código-objeto ou código intermediário entre o código-fonte e o código-objeto, como em uma forma parcialmente compilada ou em qualquer outra forma desejável.
[040] A invenção também se refere a um meio de informação (ou meio de gravação) legível por um computador ou mais particularmente por um dispositivo de processamento, este meio de informação incluindo instruções de um programa de computador conforme definido neste documento.
[041] O meio de informação pode ser qualquer entidade ou dispositivo capaz de armazenar o programa. Por exemplo, o meio pode incluir um meio de armazenamento, tal como um ROM, por exemplo um CD ROM ou um circuito microeletrônico ROM, ou um meio de gravação magnética, por exemplo um disquete ou um disco rígido.
[042] Por outro lado, o meio de informação pode ser um meio transmissível, como um sinal elétrico ou óptico, que pode ser transmitido por meio de um cabo elétrico ou óptico, por rádio ou por outros meios. O programa de acordo com a invenção pode ser descarregado particularmente através de uma rede do tipo Internet.
[043] Alternativamente, o meio de informação pode ser um circuito integrado no qual o programa está incorporado, sendo o circuito adaptado para executar ou ser utilizado na execução do método em questão.
[044] A invenção também se refere a um primeiro dispositivo (ou primeiro dispositivo de processamento) configurado para implementar o método de controle da invenção. Particularmente, a invenção refere-se a um primeiro dispositivo capaz de processar transações em cooperação com um segundo dispositivo, o primeiro dispositivo compreendendo:
- uma primeira área de memória na qual um histórico capaz de compreender pelo menos uma entrada representativa de uma transação é armazenado, e
- uma segunda área de memória na qual um contador de primeira geração definido para um valor inicial é armazenado,
- um módulo de recebimento configurado para receber, durante o processamento de uma transação atual, proveniente do segundo dispositivo, primeiros dados compreendendo segundos dados, os referidos segundos dados compreendendo:
  • • uma chave pública do segundo dispositivo,
  • • um valor de um crédito a ser pago durante a transação atual,
  • • um contador de segunda geração, e
  • • um primeiro identificador de transação alocado pelo segundo dispositivo para a transação atual;
  • • um módulo de verificação configurado para realizar as seguintes etapas:
  • • verificação de que os contadores de primeira e segunda geração possuem valores coincidentes;
  • • se os contadores de primeira e segunda geração tiverem valores coincidentes, verificação na primeira área de memória de que o histórico compreende uma entrada associada à chave pública do segundo dispositivo;
  • • se o histórico não incluir uma entrada associada à chave pública do segundo dispositivo, aprovação da transação atual;
  • • se o histórico compreender uma entrada associada à chave pública do segundo dispositivo, verificação de que o primeiro identificador de transação satisfaz uma primeira condição predeterminada indicando a unicidade da transação atual;
  • • se o primeiro identificador de transação satisfizer a primeira condição predeterminada, aprovação da transação atual;
- um módulo de armazenamento configurado para armazenar no histórico, caso a transação atual seja aprovada, uma nova entrada associada à chave pública do segundo dispositivo;
- um módulo de atualização configurado para atualizar, caso a transação atual seja aprovada, um saldo de conta armazenado na segunda área de memória, de modo a pagar o valor do referido crédito à conta associada ao primeiro dispositivo;
- um módulo de gerenciamento de memória configurado para realizar as seguintes etapas:
  • • detecção de que o espaço ocupado na primeira área de memória satisfaz uma segunda condição predeterminada indicando um risco de saturação da referida primeira área de memória; e
  • • em resposta à referida detecção, implementação de um processo de despejo compreendendo uma atualização do contador de primeira geração na segunda área de memória de modo a atribuir ao referido contador de primeira geração um novo valor diferente do valor inicial; e um despejo de pelo menos parte da primeira área de memória para liberar espaço de memória.
[045] A invenção também se refere a um sistema que compreende um primeiro dispositivo e um segundo dispositivo para processar uma transação corrente, conforme definido neste documento.
[046] Deve notar-se que as diferentes formas de realização mencionadas acima em relação aos métodos da invenção, bem como as vantagens associadas, aplicam-se analogamente ao primeiro dispositivo e ao sistema da invenção.
[047] De acordo com uma modalidade, a invenção é implementada por meio de componentes de software e/ou hardware. Nesta perspectiva, o termo "módulo" pode corresponder neste documento a um componente de software, a um componente de hardware ou a um conjunto de componentes de hardware e software.
[048] Para cada etapa dos métodos da invenção, os diferentes elementos da invenção (particularmente: o primeiro dispositivo, o segundo dispositivo, o sistema compreendendo o primeiro e o segundo dispositivos, bem como o sistema online) podem compreender um módulo correspondente configurado para realizar o referido passo.
[049] Um componente de software corresponde a um ou vários programas de computador, um ou vários subprogramas de um programa, ou mais geralmente a qualquer elemento de um programa ou software capaz de implementar uma função ou conjunto de funções, conforme descrito abaixo para o módulo em questão.
[050] Da mesma forma, um componente de hardware corresponde a qualquer elemento de um conjunto de hardware capaz de implementar uma função ou um conjunto de funções, conforme descrito abaixo para o módulo em questão. Pode ser um componente de hardware programável ou um componente de hardware com processador integrado para execução de software, por exemplo, um circuito integrado, um cartão inteligente, etc.
Breve descrição dos desenhos
[051] Outras características e vantagens da presente invenção surgirão da descrição dada abaixo, com referência aos desenhos anexos que ilustram modalidades exemplares sem qualquer limitação. Nas figuras:
[052] A Figura 1 representa esquematicamente um ambiente compreendendo um primeiro dispositivo capaz de cooperar com um segundo dispositivo e com um sistema online e de acordo com uma modalidade particular da invenção.
[053] A Figura 2 representa esquematicamente a estrutura de um primeiro dispositivo de acordo com uma modalidade particular da invenção.
[054] A Figura 3 representa esquematicamente a estrutura de um segundo dispositivo de acordo com uma forma de realização particular da invenção.
[055] A Figura 4 representa esquematicamente módulos implementados por um primeiro dispositivo de acordo com uma forma de realização particular da invenção.
[056] A Figura 5 representa esquematicamente, na forma de um diagrama, as etapas de um método de controle de acordo com uma modalidade particular da invenção
[057] A Figura 6 representa esquematicamente, na forma de diagrama, as etapas de um método de controle de acordo com uma modalidade particular da invenção.
[058] A Figura 7 representa esquematicamente, na forma de diagrama, as etapas de um método de controle de acordo com uma modalidade particular da invenção
[059] A Figura 8 representa esquematicamente, na forma de diagrama, as etapas de um método de controle de acordo com uma modalidade particular da invenção.
[060] A Figura 9 representa esquematicamente, na forma de um diagrama, as etapas de um método de controle de acordo com uma modalidade particular da invenção.
Descrição detalhada de várias modalidades
[061] Conforme indicado acima, a invenção refere-se a dispositivos capazes de processar transações eletrônicas, como transações de pagamento ou transações de reputação, por exemplo, bem como a métodos para implementar tais transações.
[062] As modalidades particulares da invenção são descritas abaixo no contexto de transações de pagamento feitas eletronicamente de um segundo dispositivo (chamado dispositivo "pagador" ou "débito") para um primeiro dispositivo (chamado dispositivo "receptor" ou "crédito"). A invenção permite, em particular, que um primeiro dispositivo receba de maneira segura, proveniente de um segundo dispositivo, um pagamento em moeda criptográfica (ou criptomoeda), ou seja, uma moeda virtual utilizável em uma rede de computadores descentralizada.
[063] Note-se, no entanto, que a invenção não se aplica exclusivamente às operações de pagamento e aos dispositivos configurados para processar este tipo de operação, mas aplica-se de forma mais geral ao processamento de quaisquer operações electrónicas que permitam transferir um crédito de um determinado montante e de uma determinada natureza de um dispositivo de débito para outro dispositivo de crédito. A natureza desses créditos (valor numérico) pode ser adaptada conforme o caso. A invenção aplica-se em particular ao processamento de transações de reputação destinadas a transferir créditos de reputação, ou seja, créditos representativos de uma reputação associada a uma conta (ou a um indivíduo, um grupo de indivíduos, uma organização, etc.). Esses créditos de reputação podem, por exemplo, assumir a forma de um " Curtir " ou uma pontuação.
[064] A invenção propõe, em particular, um método de controle (também chamado de "método") implementado em um primeiro dispositivo capaz de processar transações em cooperação com um segundo dispositivo, e visa particularmente garantir o gerenciamento eficiente de uma memória do primeiro dispositivo, permitindo um processamento das transações. Para tanto, a invenção propõe, de acordo com diferentes modalidades, um primeiro dispositivo compreendendo uma primeira área de memória capaz de conter um histórico de transações, este histórico pode compreender uma ou várias entradas representativas de transações processadas pelo primeiro dispositivo. Este método de controle compreende, em particular, um processamento de uma transação atual durante a qual o primeiro dispositivo recebe dados de transação provenientes do segundo dispositivo para pagar (ou transferir) um crédito de uma certa quantia para uma conta associada ao primeiro dispositivo. Este processamento utiliza particularmente um contador de primeira geração armazenado em uma segunda área de memória do primeiro dispositivo. Durante o processamento da transação atual, o primeiro dispositivo verifica se este contador de primeira geração coincide (ou corresponde) com um contador de segunda geração fornecido pelo segundo dispositivo nos dados da transação. O método de controle compreende ainda uma etapa de gerenciamento da primeira área de memória durante a qual um processo de despejo é implementado pelo primeiro dispositivo de modo a atualizar o contador de primeira geração (por incremento, decrementação ou semelhante) e realizar um total ou parcial despejo (ou limpeza) da primeira área de memória para liberar espaço de memória.
[065] Conforme descrito abaixo, a invenção também se refere a um primeiro dispositivo de processamento correspondente, um segundo dispositivo de processamento correspondente, um sistema correspondente compreendendo o primeiro e o segundo dispositivos, bem como os programas de computador correspondentes. Outros aspectos e vantagens da presente invenção surgirão das modalidades exemplares descritas abaixo com referência aos desenhos mencionados acima.
[066] Salvo indicação em contrário, os elementos comuns ou semelhantes a várias figuras ostentam os mesmos sinais de referência e têm características idênticas ou semelhantes, pelo que estes elementos comuns não são geralmente descritos novamente por questões de simplicidade.
[067] Salvo indicação em contrário, os termos "primeiro", "segundo", etc, são usados neste documento por convenção arbitrária para permitir identificar e distinguir diferentes elementos (como chaves, dispositivos, etc.) implementados nas modalidades descritas abaixo.
[068] A figura 1 representa esquematicamente um sistema SY1 compreendendo um primeiro dispositivo C1, um segundo dispositivo C2 e um sistema online NT1 (também chamado Ledger) compreendendo um ou vários servidores SV. O primeiro dispositivo C1 é capaz de processar transações em cooperação com o segundo dispositivo C2. Para tanto, o primeiro dispositivo C1 pode receber, por meio de um link de comunicação L1, transações offline TRX (no modo peer-to-peer), na forma de dados de transação destinados a transferir ou pagar um crédito CR do segundo dispositivo C2 atuante como dispositivo de débito, para o primeiro dispositivo C1 atuando como dispositivo de crédito, sem envolver o sistema online NT1.
[069] O sistema online NT1 compreende pelo menos um servidor remoto SV configurado para processar transações online TRY visando a transferência de créditos CR para o primeiro dispositivo C1 atuando como dispositivo de crédito. Assim, o primeiro dispositivo C1 pode cooperar através de um segundo link de comunicação L2 com o sistema online NT1 para receber créditos CR durante as transações online TRY
[070] Como já indicado, assume-se posteriormente que os créditos CR transferidos (ou pagos) para o primeiro dispositivo C1 (ou mais particularmente para uma conta U1 associada a este primeiro dispositivo C1) são créditos em moeda criptográfica. A moeda criptográfica utilizada pode ser qualquer moeda criptográfica (em Ether, por exemplo), entendendo-se que também são possíveis outros créditos além daqueles em criptomoeda. Em particular, a invenção permite a atribuição ou o pagamento de créditos de reputação (por exemplo sob a forma de "Like", ou sob a forma de pontuação ou pontos) a uma conta associada ao primeiro dispositivo C1. Esses créditos CR podem ser transmitidos durante uma transação para serem pagos na conta do primeiro dispositivo C1.
[071] O primeiro e segundo dispositivos C1, C2 juntos formam um sistema denominado SY2 capaz de processar transações offline TRX conforme já indicado.
[072] Supõe-se posteriormente que as transações offline TRX processadas pelo primeiro dispositivo C1 em cooperação com o segundo dispositivo C2, bem como as transações online TRY processadas pelo primeiro dispositivo C1 em cooperação com o sistema online NT1, são transações de pagamento, como por exemplo, transações Ether, embora outros exemplos sejam possíveis.
[073] Presume-se nas seguintes modalidades exemplares que o primeiro e o segundo dispositivos C1, C2 (também chamados de dispositivos de processamento) são terminais, como smartphones, tablets, computadores portáteis ou semelhantes. Esses dispositivos C1 e C2 podem, no entanto, assumir outras formas (formas fixas ou móveis), como, em particular, terminais fixos (servidores, etc.), cartões inteligentes, chaves USB, objetos conectados, etc. Alternativamente, pelo menos um dos dispositivos C1 e C2 podem ser, em particular, um cartão de pagamento no formato ISO/IEC 7816 ID1 (por exemplo, o dispositivo C2 é um cartão de pagamento no formato ISO/IEC 7816 ID1 enquanto o dispositivo C1 é qualquer terminal capaz de cooperar com este cartão ou vice-versa. vice-versa).
[074] Além disso, pelo menos um dos terminais C1, C2 (ou ambos) pode compreender um elemento seguro. Neste caso, as etapas de processamento da transação (conforme descrito mais adiante) são realizadas pelos elementos seguros incorporados respectivamente pelos terminais C1, C2. Conforme definido pela organização de padronização "GlobalPlatform" bem conhecida dos especialistas na técnica, um elemento seguro é uma plataforma de hardware e software configurada para hospedar aplicativos com segurança e seus dados sensíveis associados (chaves criptográficas, algoritmos, etc.), de acordo com regras definidas por uma autoridade terceirizada confiável. Um elemento seguro fornece um ambiente de execução seguro para aplicativos. Ele pode assumir várias formas, como um módulo UICC (Universal Integrated Circuit Card), um elemento seguro incorporado (ou "SE incorporado" ou " eSIM ") ou um cartão microSD. Um módulo UICC e um cartão microSD geralmente são removíveis. Cada forma de elemento seguro deve ser usada em aplicações muito específicas e deve atender aos requisitos específicos do mercado em questão.
[075] Conforme representado na Figura 1, assume-se a título de exemplo que os terminais C1 e C2 incorporam, respectivamente, os elementos de segurança SE1 e SE2, que podem tomar, por exemplo, a forma de um cartão SIM, cartão eSIM ou semelhante.
[076] Assume-se aqui que os links de comunicação L1 e L2 são quaisquer links sem fio, embora também seja possível implementar a invenção com links com fio. As trocas de dados entre os dispositivos C1 e C2 também podem ser feitas pela aquisição de códigos de barras do tipo QR code (quick response code).
[077] A figura 2 representa, de acordo com uma modalidade particular, a estrutura do primeiro terminal C1 descrito acima com referência à Figura 1. Mais especificamente, o terminal C1 compreende neste exemplo um processador 2, uma memória volátil 4, uma memória não volátil 6, uma memória não volátil regravável MR1 e uma interface de comunicação INT1.
[078] De acordo com um exemplo particular, os elementos 2, 4, 6 e MR1, bem como possivelmente a interface INT1, estão incluídos no elemento seguro SE1 (no caso em que tal elemento seguro esteja presente).
[079] A memória não volátil 6 (do tipo Flash, ROM ou similar) constitui neste exemplo um meio de gravação (ou meio de informação) de acordo com uma modalidade particular, legível pelo terminal C1, e no qual um programa de computador PG1 de acordo com uma modalidade particular é registrado. Este programa de computador PG1 inclui instruções para a execução das etapas de um método de controle de acordo com uma modalidade particular. As etapas deste método são descritas posteriormente, em modalidades particulares da invenção.
[080] O processador 2 controla os diferentes componentes (memórias, interface de comunicação, etc.) e utiliza a memória volátil 4 para realizar as diferentes operações e funções necessárias para a operação do primeiro dispositivo C1, também para executar o programa de computador PG1 durante a implementação do método de controle da invenção.
[081] De acordo com um exemplo particular, o processador 2 é conduzido pelo programa PG1 para implementar uma carteira virtual destinada a realizar um método de controle de acordo com a invenção. Esta carteira virtual pode permitir particularmente gerenciar uma conta de usuário U1 associada ao terminal C1 e fazer transações em moeda criptográfica (por exemplo, em Ether ou quaisquer outras criptomoedas apropriadas) com uma conta de terceiros U2 associada ao terminal C2.
[082] Deve-se notar que o terminal C1 pode, em um exemplo particular, compreender várias contas de usuário distintas U1, cada uma permitindo receber pagamentos de uma conta de terceiros associada a um dispositivo externo, como o terminal C2.
[083] No exemplo considerado aqui, a memória não volátil regravável MR1 compreende duas áreas de memória distintas denominadas Z1 e Z2. Estas áreas de memória Z1 e Z2 podem ser formadas na mesma memória física MR1 do terminal C1 ou, alternativamente, ser formadas em memórias físicas separadas
[084] A primeira área de memória Z1 está configurada para armazenar um histórico (ou histórico de transações) H1 capaz de conter dados de histórico DH1, em particular na forma de entradas EN. O histórico H1 pode, assim, compreender uma ou várias entradas EN, sendo cada uma dessas entradas EN representativa de uma transação passada processada pelo dispositivo C1 e durante a qual um crédito CR foi pago de uma conta de terceiros para a conta U1 associada ao terminal C1.
[085] Mais especificamente, cada entrada EN está associada neste exemplo a uma chave pública de um dispositivo de débito que está na origem do pagamento do CR de crédito correspondente. Conforme descrito abaixo, além desta chave pública, cada entrada EN também pode ser associada a um identificador de transação. Conforme representado na Figura 2, assume-se neste exemplo que o histórico H1 está em um estado inicial no qual compreende pelo menos uma entrada EN1 associada a uma chave pública PK2 do dispositivo C2 e com um identificador de transação denotado nonce1. Outras modalidades exemplares são, no entanto, possíveis sem o uso de tal identificador de transação nonce1.
[086] Deve-se notar que outros parâmetros que caracterizam os dados de transação também podem ser incluídos nos dados de transação DH1, embora isso não seja necessário para implementar a invenção.
[087] Além disso, a segunda área de memória Z2 é configurada para armazenar um contador de primeira geração GEN1 que é inicialmente definido para um valor inicial Val1 neste exemplo. Como ficará mais claro a seguir, o valor do contador de geração GEN1 pode ser qualquer número inteiro, este número permite garantir o processamento das transações processadas pelo terminal C1.
[088] A segunda área de memória Z2 compreende ainda neste exemplo um primeiro par de chaves criptográficas PK1/SK1 e um segundo par de chaves criptográficas PK/SK. Neste exemplo, PK1 é uma chave pública do terminal C1 enquanto SK1 é uma chave privada do terminal C1, sendo estas duas chaves complementares entre si. Da mesma forma, PK é uma chave pública de grupo e SK é uma chave privada de grupo, sendo estas duas chaves complementares entre si e associadas a um grupo ao qual pertencem os terminais C1 e C2. No entanto, outras implementações da invenção são possíveis, em particular, sem ter que usar as chaves de grupo PK e SK.
[089] Neste documento, as chaves mencionadas são chaves criptográficas. Uma chave é chamada de chave "privada" quando é secreta, em oposição à chave pública.
[090] O terminal C1 (por exemplo, sua carteira virtual) pode usar as chaves PK1/SK1 e PK/SK da conta de usuário U1 para assinar dados de transação ou verificar a assinatura de dados de transação durante o processamento de transações.
[091] De acordo com um exemplo particular, o par de chaves PK1/SK1 (e possivelmente o par de chaves PK/SK) é calculado dinamicamente pelo terminal C1 a partir de um dado (chamado semente; não representado na figura) que pode ser armazenado na segunda área de memória Z2.
[092] Neste exemplo, a segunda área de memória Z2 também compreende um saldo de conta ACN1 associado à conta U1 do terminal C1. Este saldo de conta ACN1 é um parâmetro que especifica um saldo atual da conta U1 associada ao terminal C1. Este saldo pode, em particular, ser creditado com um valor quando um crédito CR é pago na conta U1 (ou também pode ser debitado com um valor quando um crédito é retirado e pago da conta U1 para uma conta de terceiros, como a conta U2).
[093] A figura 3 representa, de acordo com uma modalidade particular, a estrutura do segundo terminal C2 descrito acima com referência à Figura 1 . Mais especificamente, o terminal C2 compreende neste exemplo um processador 22, uma memória volátil 24, uma memória não volátil 26, uma memória não volátil regravável MR2 e uma interface de comunicação INT2.
[094] A memória não volátil 26 (do tipo Flash, ROM ou semelhante) constitui neste exemplo um meio de gravação (ou meio de informação) de acordo com uma modalidade particular, legível pelo terminal C2, e no qual um programa de computador PG2 de acordo com uma modalidade particular é registrado. Este programa de computador PG2 inclui instruções para a execução das etapas de um método de controle de acordo com uma modalidade particular em cooperação com o terminal C1. As etapas deste método são descritas posteriormente, em modalidades particulares da invenção.
[095] De acordo com um exemplo particular, os terminais C1 e C2 têm uma estrutura análoga e são configurados de forma análoga para que os terminais C1 e C2 possam cooperar juntos para fazer pagamentos offline de C2 para C1 e vice-versa, embora outras implementações sejam possíveis (nas quais, por exemplo o terminal C1 está configurado apenas para receber créditos CR enquanto o terminal C2 está configurado apenas para pagar créditos).
[096] Por uma questão de simplicidade, apenas alguns elementos úteis para a descrição da invenção foram representados na Figura 3 e descritos neste documento.
[097] Supõe-se neste exemplo que o terminal C2 compreende em sua memória não volátil MR2 um primeiro par de chaves criptográficas PK2/SK2 e um segundo par de chaves criptográficas PK/SK. Neste exemplo, PK2 é uma chave pública do terminal C2 enquanto SK2 é uma chave privada do terminal C2, sendo estas duas chaves complementares entre si. Da mesma forma, PK e SK são respectivamente a chave pública do grupo e a chave privada do grupo disponível para o terminal C2 (assim como o terminal C1) como membro de um grupo que compreende os terminais C1 e C2. Como já indicado, as modalidades são, no entanto, possíveis sem, em particular, o uso das chaves de grupo PK/SK.
[098] Neste exemplo, a memória não volátil MR2 também pode conter um identificador de transação nonce2 alocado pelo segundo dispositivo C2 para uma transação atual.
[099] A memória não volátil MR2 do terminal C2 também pode conter um saldo de conta ACN2 associado à conta U2 do terminal C2. Quanto ao ACN1, o saldo da conta ACN2 é um parâmetro que especifica o saldo atual da conta U2 associada ao terminal C2. Este saldo pode, em particular, ser debitado com um valor quando um crédito CR é transferido da conta U2 para uma conta de terceiros, como a conta U1 (ou pode ser creditado com um valor quando um crédito é recebido na conta U2).
[0100] Embora isso não seja representado, a memória MR2 também pode armazenar outros elementos, como um contador de geração denotado GEN1a associado ao terminal C1. Conforme descrito abaixo, se os terminais C1 e C2 estiverem sincronizados, o contador de geração GEN1a armazenado na memória MR2 do terminal C2 é idêntico ao contador de geração GEN1 armazenado na segunda área de memória Z2 do terminal C1. Se, por outro lado, os terminais C1 e C2 estiverem dessincronizados, o contador de geração GEN1a armazenado na memória MR2 do terminal C2 é diferente do contador de geração GEN1 armazenado na segunda área de memória Z2 do terminal C1.
[0101] O terminal C1 e o terminal C2 são configurados para usar suas respectivas interfaces de comunicação INT1, INT2 para se comunicarem juntos. Assim, as interfaces de comunicação INT1 e INT2 podem ser configuradas para estabelecer um link de comunicação offline L1 (no modo peer-to-peer, ou seja, que não passa pelo sistema online NT1, conforme já indicado). O link de comunicação L1 pode ser, por exemplo, um link sem fio (Bluetooth, Wi-Fi, NFC, etc.) ou um link com fio.
[0102] Deve-se notar que o sistema SY2, e mais particularmente os dispositivos C1 e C2 representados nas Figuras 1-3, constituem apenas modalidades exemplares particulares, sendo outras implementações possíveis dentro da estrutura da invenção. Os versados na técnica entendem particularmente que alguns elementos do terminal C1 representado na Figura 2 e do terminal C2 representado na Figura 3 são descritos aqui apenas para facilitar o entendimento da invenção, não sendo esses elementos necessários para implementar a invenção.
[0103] Além disso, a Figura 4 representa, de acordo com uma modalidade particular, módulos implementados pelo processador 2 acionado pelo programa de computador PG1 dentro do terminal C1. Esses módulos compreendem um módulo de recepção MD4, um módulo de verificação MD6, um módulo de gerenciamento de histórico MD8, um módulo de gerenciamento de contas MD10 e um módulo de gerenciamento de memória MD12. De acordo com um exemplo particular, o processador 2 acionado pelo programa PG1 também implementa um módulo de envio MD2, embora sejam possíveis modalidades sem este módulo em particular.
[0104] Mais particularmente, o módulo receptor MD4 está configurado para receber, durante uma transação atual, os primeiros dados DT3 provenientes do segundo dispositivo C2. Estes primeiros dados DT3 compreendem segundos dados DT2 que podem incluir: a chave pública PK2 do segundo dispositivo C2, um montante MT1a do crédito CR1 a ser creditado (ou pago) durante a transação atual, um contador de geração GEN1a e uma primeira transação identificador nonce2 alocado pelo segundo dispositivo C2 para a transação atual.
[0105] De acordo com um exemplo particular, o primeiro identificador de transação nonce2 alocado pelo segundo terminal C2 é um contador representativo de um número atual de transações feitas pelo segundo terminal C2.
[0106] Conforme descrito abaixo, são possíveis modalidades particulares nas quais os dados DT3 compreendem assinaturas além dos dados DT2.
[0107] O módulo de verificação MD6 é configurado para verificar se o contador de primeira geração GEN1 armazenado na área de memória Z2 e o contador de segunda geração GEN1a recebido possuem valores coincidentes. Em caso afirmativo, o módulo de verificação MD6 é configurado para verificar na primeira área de memória Z1 que o histórico H1 compreende uma entrada EN associada à chave pública PK2 do segundo dispositivo C2. Se o histórico H1 não incluir nenhuma entrada EN associada à chave pública PK2 do segundo dispositivo C2, o módulo de verificação MD6 é configurado para aprovar a transação atual.
[0108] Caso contrário (uma entrada EN é detectada), o módulo de verificação MD6 é configurado para verificar se o primeiro identificador de transação nonce2 satisfaz uma primeira condição predeterminada (denotada CD1) indicando a exclusividade da transação atual. Neste caso, se for detectado que a primeira condição foi satisfeita, o módulo de verificação MD6 é configurado para aprovar a transação atual.
[0109] Além disso, se a transação atual for aprovada:
  • - o módulo de gerenciamento de histórico MD8 é configurado para armazenar (ou registrar) no histórico H1 uma nova entrada EN associada à chave pública PK2 do segundo dispositivo C2; e
  • - o módulo de gestão de contas MD10 está configurado para atualizar o saldo da conta ACN1 na segunda área de memória Z2 de modo a pagar o valor do crédito à conta U1 associada ao primeiro dispositivo C1.
[0110] Além disso, o módulo de gerenciamento de memória MD12 compreende um módulo de detecção MD14, um módulo de atualização MD16 e um módulo de despejo MD18. Mais particularmente, o módulo de detecção MD14 está configurado para detectar que o espaço ocupado na primeira área de memória Z1 satisfaz uma segunda condição predeterminada (denotada CD2) indicando um risco (próximo ou iminente) de saturação da primeira área de memória Z1. Em resposta a esta detecção, o módulo de gerenciamento de memória MD12 é configurado para realizar um processo de despejo durante o qual:
  • - o módulo de atualização MD16 atualiza o contador de primeira geração GEN1 na segunda área de memória Z2 do dispositivo C1 de modo a atribuir ao contador de primeira geração GEN1 um novo valor (denominado Val2) diferente do valor inicial Val1; e
  • - o módulo de despejo MD18 despeja (ou seja, esvazia) pelo menos parte da primeira área de memória Z1 para liberar espaço de memória.
[0111] A operação e a configuração dos módulos MD2–MD18 do dispositivo C1 aparecerão mais especificamente nas modalidades exemplares descritas abaixo. Deve-se notar também que os módulos MD2- MD18, conforme representados na Figura 4, constituem apenas uma implementação exemplar da invenção.
[0112] Uma modalidade particular da invenção é agora descrita com referência às Figuras 5-6. Mais especificamente, o terminal C1 representado nas Figuras 1, 2 e 4 executa o programa de computador PG1 para implementar um método de controle de acordo com uma modalidade particular. Da mesma forma, o terminal C2 representado nas Figuras 1 e 3 executa o programa de computador PG2 para implementar um método de controle coletivamente com o terminal C1, de acordo com uma modalidade particular.
[0113] Assume-se neste exemplo que um usuário usa o terminal C1 para receber um crédito CR1 vindo do terminal C2 de outro usuário durante uma transação offline atual TR1 (no modo peer-to-peer, ou seja, sem o sistema online NT1 atuando como um intermediário entre os terminais C1 e C2 para processar a transação atual TR1). Conforme já indicado, trata-se de uma operação de pagamento destinada a pagar um crédito CR1 em moeda criptográfica (em Ether ou similar) da conta U2 associada ao terminal C2 para a conta U1 do terminal C1. Tal transação é feita, por exemplo, quando um comerciante usando o terminal C1 tenta receber um pagamento de um cliente usando o terminal C2. Para isso, o terminal C1 coopera com o terminal C2 para trocar os dados necessários para a execução da transação TR1.
[0114] Conforme representado na Figura 5, assume-se que a transação atual TR1 entre o terminal C1 e o terminal C2 é iniciada durante uma etapa de iniciação A1.
[0115] Durante uma etapa de envio B20, o terminal C2 envia os primeiros dados de transação DT3 que são recebidos em A20 pelo terminal C1. Conforme descrito abaixo, o terminal C2 envia em B20 esses dados DT3 para fazer com que o pagamento de um valor MT1a do crédito CR1 para a conta U1 associada ao terminal C1.
[0116] Mais particularmente, os primeiros dados de transação DT3 compreendem os segundos dados DT2 e podem opcionalmente também compreender outros dados que serão descritos posteriormente em um exemplo particular. Os segundos dados DT2 compreendem:
  • - uma chave pública PK2 do terminal C2,
  • - um valor MT1a do crédito CR1 a ser creditado (ou pago) durante a transação atual TR1,
  • - um contador de geração GEN1a, e
  • - um primeiro identificador de transação nonce2 alocado pelo segundo terminal C2 para a transação atual TR1.
[0117] De acordo com um exemplo particular, o primeiro identificador de transação nonce2 alocado pelo segundo terminal C2 é um contador representativo de um número atual de transações feitas pelo segundo terminal C2 para pagar um respectivo CR de crédito.
[0118] Deve-se notar que a maneira como o terminal C2 adquire (obtém) esses segundos dados DT2 de antemão pode variar dependendo do caso, alguns exemplos particulares serão descritos posteriormente.
[0119] Durante uma etapa de verificação A26, o terminal C1 verifica se o contador de geração GEN1a recebido em A20 nos dados DT2 coincide (ou coincide) com o contador de geração GEN1 armazenado em sua segunda área de memória Z2. Para isso, o terminal C1 compara o valor do contador de geração GEN1a com o valor inicial Val1 do contador de geração GEN1. Neste exemplo, o terminal C1 verifica se os contadores GEN1 e GEN1a são idênticos. Para este fim, o terminal C1 pode, antes do passo de verificação A26, consultar a sua segunda área de memória Z2 para determinar o contador de geração GEN1 no momento atual, durante o qual a transação atual TR1 é processada.
[0120] Se o resultado da verificação A26 for negativo (GEN1 e GEN1a não coincidem), o terminal C1 bloqueia (A28) ou nega (ou rejeita) a transação TR1.
[0121] Se, por outro lado, o resultado da verificação A26 for positivo (GEN1 e GEN1a coincidem), o terminal C1 verifica (A30) na primeira área de memória Z1 que o histórico H1 compreende uma entrada EN associada à chave pública PK2 de o segundo terminal C2.
[0122] Se o resultado da verificação A30 for negativo (nenhuma entrada EN detectada), o terminal C1 aprova (A32) a transação atual TR1. A ausência da entrada EN associada à chave pública PK2 no histórico H1 significa que o terminal C1 não tem conhecimento de nenhuma transação antiga durante a qual teria recebido um pagamento do terminal C2.
[0123] Caso contrário (tal entrada EN é detectada), o terminal C1 verifica (A34) que o primeiro identificador de transação nonce2 satisfaz uma primeira condição predeterminada CD1 indicando a unicidade da transação atual TR1. Ou seja, esta verificação A34 permite determinar se a transação atual TR1 é única do ponto de vista do terminal C1 ou se, pelo contrário, o terminal C1 já processou anteriormente esta mesma transação TR1, correspondente ao mesmo pagamento, com o terminal C2. Para isso, o terminal C2 atribui um identificador de transação único (geralmente denominado "nonce") para cada nova transação que processa durante um pagamento a um terminal de terceiros. Neste exemplo particular, o terminal C1 pode assim verificar, a partir do identificador de transação nonce2 recebido em A20, que a transação atual TR1 constitui efetivamente uma transação nova e não uma transação antiga já efetuada com o terminal C2.
[0124] Conforme descrito posteriormente, o terminal C1 pode verificar em A34 o identificador de transação nonce2 de várias maneiras. A condição predeterminada CD1 pode assim ser adaptada conforme apropriado. A título de exemplo, o terminal C1 pode comparar o identificador de transação nonce2 com pelo menos um identificador de transação previamente registrado em sua área de memória Z2.
[0125] De acordo com um exemplo particular, assume-se que a entrada EN1 associada à chave pública PK2 do terminal C1 é detectada durante a verificação A30 no histórico H1 armazenado na primeira área de memória Z1. Esta entrada de histórico EN1 é representativa de uma (ou pelo menos uma) transação passada durante a qual o mesmo terminal C2 pagou um crédito CR ao terminal C1. Em outras palavras, a presença desta entrada EN1 significa que o terminal C1 está ciente de uma transação passada durante a qual recebeu um pagamento do terminal C2.
[0126] Esta entrada EN1 detectada em A30 pode ainda compreender um segundo identificador de transação nonce1 que identifica a transação mais recente (diferente da transação atual TR1) durante a qual um crédito CR foi recebido pelo terminal C1 proveniente do terminal C2. Quanto ao identificador de transação nonce2, o identificador de transação nonce1 pode ser um contador de transações que foi previamente atribuído pelo terminal C2 a esta transação antiga e enviado pelo terminal C2 ao terminal C1 durante a referida transação antiga.
[0127] Assim, a condição predeterminada CD1 pode ser definida a partir do contador de transações nonce1 pré-gravado na entrada de histórico H1 em associação com a chave pública PK2. Por exemplo, a condição CD1 é cumprida se os identificadores nonce1 e nonce2 forem diferentes. De acordo com outro exemplo, os identificadores de transação nonce1 e nonce2 são contadores e a condição CD1 é cumprida se nonce2 > nonce1.
[0128] Se o resultado da verificação A34 for negativo (o identificador nonce2 não atende à condição CD1), o terminal C1 bloqueia (A36) ou rejeita a transação atual TR1, porque isso significa que o terminal C2 (ou outro dispositivo atuando como terminal C2) tenta repetir uma transação para pagar os créditos CR1 que já foram pagos pelo terminal C2 ao terminal C1.
[0129] Se, por outro lado, o resultado da verificação A34 for positivo (o identificador nonce2 preenche a condição CD1), o terminal C1 aprova (A38) a transação atual TR1 e realiza uma etapa de armazenamento A40 e uma etapa de atualização A42 (Figura 5) durante o processamento da transação atual TR1.
[0130] Mais particularmente, durante a etapa de armazenamento A40, o terminal C1 armazena (ou registra) no histórico H1 uma nova entrada EN2 associada à chave pública PK2 do segundo terminal C2. Esta nova entrada EN2 pode substituir a antiga entrada EN1, no caso, por exemplo, em que o terminal C1 mantém apenas uma entrada EN no histórico H1 para cada dispositivo de débito do qual recebe um CR de crédito durante uma transação. Esta substituição pode ser feita através de uma atualização causando a conversão da antiga entrada EN1 na nova entrada EN2. Alternativamente, a antiga entrada EN1 é mantida no histórico H1 além da nova entrada EN2. Em outras palavras, a nova entrada EN2 é adicionada no histórico H1 como a entrada mais recente em associação com a chave pública PK2 do terminal C2, sem necessariamente sobrescrever a antiga entrada EN1.
[0131] Esta nova entrada EN2 pode ser associada não apenas à chave pública PK2 do segundo terminal C2, mas também ao identificador de transação nonce2 recebido em A20 do terminal C2. Este identificador de transação nonce2 pode possivelmente ser usado pelo terminal C1 durante uma próxima transação durante a qual o terminal C2 tenta fazer um pagamento de crédito CR para o terminal C1 (como descrito acima com referência à etapa A34 (Figura 5).
[0132] Além disso, durante a etapa de atualização A42, o terminal C1 atualiza o saldo da conta ACN1 armazenado na segunda área de memória Z2, de modo a pagar o valor MT1a do crédito CR1 à conta U1 associada ao primeiro terminal C1. Esta atualização equivale, por exemplo, a incrementar o saldo ACN1 pelo valor MT1a.
[0133] Além disso, a Figura 6 representa uma etapa A60 de gerenciamento da primeira área de memória Z1, esta etapa compreendendo uma etapa de detecção A62 e um processo de despejo A74. Conforme indicado abaixo, esta etapa de gerenciamento A60 pode ser acionada em vários momentos, em resposta a um evento de ativação detectado em A62.
[0134] Particularmente, a etapa de gerenciamento A60 pode ser realizada antes do início da transação TR1, ou após a conclusão do processamento da transação TR1, dependendo do momento em que o evento desencadeador é detectado. A etapa de gerenciamento A60 também pode ocorrer durante a transação atual, com exceção dos seguintes momentos:
  • - Entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um tempo atual durante o qual a transação atual é processada e etapa A30, se o teste da etapa A26 for positivo.
  • - Entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um tempo atual durante o qual a transação atual é processada e etapa A26, se o teste da etapa A26 for negativo.
  • - Entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um momento atual durante o qual a transação atual é processada e etapa A40.
[0135] Dependendo do momento em que esta etapa de gerenciamento A60 é realizada, o resultado do processamento da transação atual TR1 pode variar, mais particularmente no que diz respeito ao resultado da verificação A26 que visa determinar se o contador de geração atual GEN1 armazenado no a segunda área de memória Z2 coincide com o contador de geração GEN1a fornecido em A20 pelo terminal C2.
[0136] Mais especificamente, conforme representado na Figura 6 , o terminal C1 detecta durante uma etapa de detecção A62 que o espaço - denotado por ESP1 - ocupado na primeira área de memória Z1 satisfaz uma segunda condição predeterminada CD2 indicando um risco de saturação (próxima ou iminente) do primeira área de memória Z1 (evento de disparo). O terminal C1 pode verificar periodicamente ou em determinados momentos predefinidos (por exemplo, durante cada transação processada) se a condição CD2 é satisfeita.
[0137] A condição predeterminada CD2 pode ser adaptada por aqueles versados na técnica de acordo com os requisitos de espaço de memória específicos para cada caso de uso e de acordo com, por exemplo, o tamanho da área de memória Z1. A condição CD2 pode, por exemplo, definir um limiar predeterminado TH além do qual o espaço ocupado ESP1 na área de memória é considerado crítico e, portanto, constituindo um risco de saturação da área de memória Z1. De acordo com um exemplo particular, o terminal C1 detecta em A62 um risco de saturação da área de memória Z1 se o espaço ocupado ESP1 atingir pelo menos um valor limite TH, sendo este valor possivelmente igual, por exemplo, a uma razão predeterminada (ou porção) de o tamanho total da área de memória Z1.
[0138] Em resposta à detecção em A62 de que a primeira área de memória Z1 pode estar saturada, o terminal C1 executa um processo de despejo A74 compreendendo uma atualização A76 e uma remoção A78.
[0139] Mais especificamente, durante a etapa de atualização A76, o terminal C1 atualiza o contador de primeira geração GEN1 na segunda área de memória Z2 de modo a atribuir ao contador de primeira geração GEN1 um novo valor – denotado Val2 – diferente do valor inicial Val1. Esta atualização A76 pode consistir, por exemplo, em incrementar (ou decrementar) o valor do contador de geração GEN1 armazenado na área de memória Z2.
[0140] De acordo com um exemplo particular, o terminal C1 atribui ao contador de geração GEN1 um novo valor Val2 que difere de qualquer outro valor anterior atribuído no passado ao contador de geração GEN1. Um mecanismo de alocação aleatória também é possível.
[0141] Além disso, durante a etapa de despejo A78, o terminal C1 despeja (ou purga) pelo menos parte da primeira área de memória Z1 (ou mesmo toda a área de memória Z1) para liberar espaço de memória. Em outras palavras, o terminal exclui todo ou apenas parte do conteúdo da área de memória Z1, para liberar espaço de memória. De acordo com um exemplo particular, o despejo A78 compreende uma purga (ou exclusão) de todo ou parte do histórico H1 armazenado na área de memória Z1.
[0142] A atualização A76 (Figura 6) do contador de primeira geração GEN1 provoca um bloqueio (ou rejeição) de todas as transações, processadas pelo terminal C1, para as quais o contador de segunda geração GEN1a recebido em A20 (Figura 5) tem um valor que difere de o novo valor Val2 alocado em A76 para o contador de geração GEN1.
[0143] Particularmente, durante a verificação A26 (Figura 5), o primeiro terminal C1 pode determinar que os contadores de primeira e segunda geração GEN1 e GEN1a têm valores que não coincidem se o contador de segunda geração GEN1a recebido nos dados DT2 em A20 tiver um valor antigo definido pelo primeiro terminal C1 antes de uma atualização anterior (por exemplo, a última atualização) do contador de geração GEN1, ou seja, antes de uma ocorrência anterior da atualização A76 durante o processamento de uma transação anterior ( Figura 6 ). A incompatibilidade (ou dessincronização) dos contadores de geração GEN1 e GEN1a leva então o terminal C1 a bloquear (ou rejeitar) a transação atual TR1 em A28 como já descrito acima com referência à Figura 5.
[0144] A invenção permite gerir de forma eficiente a memória do terminal C1, sem comprometer a segurança das transações efetuadas. De fato, o histórico de transações H1 aumenta de tamanho à medida que novos créditos são recebidos pelo terminal C1. A etapa de gerenciamento A60 (Figura 6) permite liberar espaço de memória na primeira área de memória Z1 se necessário, ou seja, quando for detectado um risco de saturação desta área de memória, de modo que sempre haja espaço de memória suficiente para registrar um histórico recente de transações.
[0145] Para isso, é realizado um processo de despejo para deletar toda ou parte da área de memória Z1 após a detecção de que esta memória Z1 pode estar saturada em breve. Excluindo particularmente todo ou parte do histórico H1, é possível evitar atingir a saturação da área de memória Z1, o que causaria dificuldades de operação do terminal C1. Esse mecanismo de despejo (ou purga) de memória é tanto mais útil quanto os recursos de memória podem ser relativamente limitados em alguns tipos de dispositivos C1, como terminais móveis, cartões inteligentes, etc.
[0146] Além disso, o gerenciamento da primeira área de memória Z1 é realizado em A60, garantindo a segurança das transações, incluindo aquelas realizadas em modo off-line pelo dispositivo C1 com dispositivos externos, como o dispositivo C2. Particularmente, a invenção permite evitar pagamentos duplos e, de forma mais geral, garantir que o mesmo dispositivo de débito não possa pagar os mesmos créditos a um dispositivo de crédito várias vezes. De fato, a eliminação da área de memória Z1 leva a uma perda parcial ou total do histórico H1, de modo que nem sempre é possível ao terminal C1 confiar no histórico H1 durante o processamento de uma transação atual.
[0147] Além disso, para superar o problema da perda de histórico, a invenção introduz o uso de contadores de geração conforme descrito acima. Assim, cada vez que é realizada uma remoção da área de memória Z1 (A78, Figura 6), o terminal C1 também atribui (A76) um novo valor ao contador de geração GEN1. Uma vez realizada a atualização A76 (Figura 6), o terminal C1 pode transmitir o contador de geração atualizado GEN1 (GEN1 = Val2) ao terminal C2 para que este possa utilizá-lo para efetuar um pagamento. O terminal C2 pode, alternativamente, obter o contador de geração atualizado de outras maneiras apropriadas.
[0148] Um dispositivo externo como o terminal C2 pode assim efetuar um pagamento de um crédito CR ao terminal C1 com sucesso apenas se tiver o contador de geração atualizado associado ao terminal C1. Se o terminal C2 fornecer em B20 (Figura 5) ao terminal C1 um contador de geração GEN1a que difere do contador de geração atualizado GEN1 (ou seja, se GEN1a ≠ val2), então a transação é negada (A28). Se, por outro lado, os contadores GEN1 e GEN1a coincidirem (GEN1 = GEN1a), então o terminal C1 pode consultar em A30 o seu histórico H1 para verificar se existe uma entrada EN associada à chave pública PK2.
[0149] A utilização do histórico H1 permite, portanto, proteger as transações e, em particular, evitar pagamentos duplos (enviando os mesmos dados de transação várias vezes do mesmo dispositivo C2). Além disso, a utilização dos contadores de geração permite, em caso de purga do histórico H1 no terminal C1, garantir que um dispositivo de débito C2 não possa utilizar dados de transação que já tenham sido utilizados para transferir um CR de crédito do dispositivo de débito C2 para o terminal C1 durante uma transação anterior à eliminação, enquanto esta transação anterior não aparece mais no histórico H1 devido à eliminação. Graças à invenção, se o terminal C2 tenta pagar um crédito CR durante uma transação atual usando um contador de geração anterior a uma limpeza da área de memória Z1, o terminal C1 bloqueia a transação na medida em que o histórico H1 armazenado no a primeira área de memória Z1 não é confiável para processar esta transação atual (se este histórico H1 está vazio ou não).
[0150] De acordo com uma primeira variante, durante o processo de despejo A74 (Figura 6), o terminal C1 realiza concomitantemente (ou simultaneamente) a atualização A76 do contador de geração GEN1 e a despejo A78 da área de memória Z1. Em outras palavras, a atualização A76 e o despejo A78 são realizados atomicamente, o que faz com que esses passos A76 e A78 sejam eficazes apenas se ambos forem realizados durante o processo de despejo A74. De acordo com uma segunda variante, o despejo A78 é realizado após a atualização A76 do contador de geração GEN1. Estas duas variantes de realização permitem aumentar ainda mais a segurança do terminal C1, evitando uma violação de segurança que poderia ocorrer se o processo de despejo A74 fosse suspenso (por exemplo, devido a um desligamento de energia) enquanto o despejo A78 da área de memória Z1 fosse executado sem que o contador de geração GEN1 tenha sido atualizado (A76).
[0151] Uma modalidade particular da invenção é agora descrita com referência às Figuras 7-9. Mais especificamente, o terminal C1 representado nas Figuras 1, 2 e 4 executa o programa de computador PG1 para implementar um método de controle de acordo com uma modalidade particular. Da mesma forma, o terminal C2 representado nas Figuras 1 e 3 executa o programa de computador PG2 para implementar um método de controle coletivamente com o terminal C1, de acordo com uma modalidade particular.
[0152] Também é assumido neste exemplo que um usuário usa o terminal C1 para receber um crédito CR1 vindo do terminal C2 de outro usuário durante uma transação atual TR1. Conforme já indicado, trata-se de uma operação de pagamento destinada a pagar um crédito CR1 em moeda criptográfica (em Ether ou similar) da conta U2 associada ao terminal C2 para a conta U1 do terminal C1. Tal transação é feita, por exemplo, quando um comerciante usando o terminal C1 tenta receber um pagamento de um cliente usando o terminal C2. Para isso, o terminal C1 coopera com o terminal C2 para trocar os dados necessários para a execução da transação TR1.
[0153] Conforme representado na Figura 7, assume-se que a transação atual TR1 entre o terminal C1 e o terminal C2 é iniciada em A1 de acordo com qualquer maneira apropriada. O terminal C1 então executa um processamento da transação TR1 (etapas A2–A42) cooperando com o terminal C2 através do link de comunicação L1 (Figura 1).
[0154] Mais especificamente, durante uma etapa de envio A2, o primeiro terminal C1 envia os dados DT1 ao segundo terminal C2 para solicitar o pagamento pelo segundo terminal C2 de um crédito CR1 do valor MT1 para a conta U1 associada ao primeiro terminal C1, estes dados DT1 compreendendo o contador de geração GEN1 ajustado para o valor inicial Val1. Em outras palavras, os dados DT1 enviados em A2 compreendem a quantidade solicitada MT1 e o contador de geração GEN1. Para tal, o terminal C1 pode, antes do passo de envio A2, consultar a sua segunda área de memória Z2 para determinar o contador de geração GEN1 num tempo atual durante o qual a transação atual TR1 é processada.
[0155] Conforme representado na Figura 7, os primeiros dados DT1 podem opcionalmente também compreender a chave pública PK1 do terminal T1.
[0156] O segundo terminal C2 recebe os primeiros dados DT1 em B2 (Figura 7).
[0157] Deve-se notar que o contador de geração GEN1 fornecido em A2 pelo terminal C1 está atualizado, no sentido de que é aquele atualmente armazenado na área de memória Z2 no momento da transação atual TR1. A disponibilização do contador de geração GEN1 em A2 ao terminal C2 permite que este último realize a transferência a crédito. No entanto, outros exemplos são possíveis em que o terminal C2 obtém o contador de geração GEN1 de outra forma. Por exemplo, o terminal C2 pode receber este contador de outro terminal ou servidor (por exemplo, do sistema online NT1). Alternativamente, um usuário pode inserir o contador de geração GEN1 no terminal C2 através de uma interface de usuário.
[0158] De acordo com uma variante da forma de realização, o terminal C1 envia para um terminal externo (por exemplo para o sistema online NT1) o contador de primeira geração GEN1 para que seja acessível pelo terminal C2.
[0159] Da mesma forma, são possíveis variantes nas quais o terminal C1 não fornece em A2 (Figura 7) pelo menos uma entre a chave pública PK1 e a quantidade solicitada MT1. É assim possível prever que o terminal C2 obtenha a chave pública PK1 e/ou a quantidade solicitada MT1 de outra forma. O terminal C2 pode, por exemplo, ter a chave pública PK1 na memória, por exemplo, porque já processou uma transação no passado com o terminal C1. Também é possível prever que um usuário insira a quantidade desejada MT1 no terminal C2 por meio de uma interface de usuário.
[0160] Durante uma etapa de geração B4, o terminal C2 calcula uma assinatura S a partir do segundo dado DT2. Mais especificamente, neste exemplo o terminal C2 gera (B4) a primeira assinatura S a partir do segundo dado DT2 usando a chave privada SK2 do terminal C2. Em outras palavras, o terminal C2 assina o segundo dado DT2 por meio da chave privada SK2 de modo a produzir a primeira assinatura S, que pode ser formulada da seguinte forma:
[Matemática. 1] S = sinal (DT2)SK2
[0161] Os segundos dados DT2 usados pelo terminal C2 para gerar a primeira assinatura S compreendem neste exemplo:
  • - a chave pública PK2 do terminal C2 (que é complementar à chave privada SK2),
  • - uma chave pública PK1a,
  • - uma quantia denotada MT1a do crédito CR1 que o terminal C2 está prestes a pagar durante a transação atual TR1;
  • - um contador de geração GEN1a, e
  • - um identificador de transação nonce2 que é alocado pelo terminal C2 para a transação atual TR1.
[0162] Supõe-se neste exemplo que o terminal C2 é o terminal legítimo que deve cooperar com o terminal C1 durante a transação atual TR1 para pagar um crédito CR1 ao terminal C1, pois é de fato o terminal C2 que recebeu em B2 os dados DT1. Além disso, a chave pública PK1a usada pelo terminal C2 no segundo dado DT2 é idêntica à chave pública PK1 recebida em B2 no primeiro dado DT1. Da mesma forma, a quantidade MT1a utilizada pelo terminal C2 no segundo dado DT2 é idêntica à quantidade MT1 recebida em B2 no primeiro dado DT1. Da mesma forma, o contador de geração GEN1a utilizado pelo terminal C2 no segundo dado DT2 é idêntico ao contador de geração GEN1 recebido em B2 no primeiro dado DT1. Esses parâmetros PK1a, MT1a e GEN1a usados pelo terminal C2 como dados DT2 serão verificados posteriormente pelo terminal C1 para garantir que a transação atual TR1 seja válida.
[0163] Deve-se notar também que o identificador de transação nonce2 usado pelo terminal C2 pode ser qualquer identificador ou um contador. De acordo com um exemplo particular, para cada nova transação durante a qual o terminal C2 atua como devedor (pagador), o terminal C2 incrementa o valor do identificador de transação nonce2 de modo que este identificador tenha um valor diferente para cada transação.
[0164] Alternativamente, o identificador de transação nonce2 não é alocado pelo terminal C2, mas definido por um usuário, ou determinado por uma entidade externa (por exemplo, o sistema online NT1) e fornecido previamente ao terminal C2 para processar a transação atual TR1
[0165] Durante uma etapa de geração B6, o terminal C2 calcula então uma segunda assinatura, chamada " super assinatura " , a partir do segundo dado DT2 e da primeira assinatura S. Mais especificamente, neste exemplo, o terminal C2 gera (B6) a segunda assinatura SS de o segundo dado DT2 e da assinatura S, usando a chave privada do grupo SK disponível para o terminal C2. Em outras palavras, o terminal C2 assina o segundo dado DT2 associado à assinatura S por meio da chave privada de grupo SK de modo a produzir a segunda assinatura SS, que pode ser formulada da seguinte forma:
[Matemática. 2] SS = sinal (DT2, S)SK
[0166] Como se verá a seguir, as assinaturas S e SS permitem ao terminal C1 verificar posteriormente que o terminal C2 com o qual coopera durante a transação atual TR1 é de fato legítimo, tornando assim o processamento das transações ainda mais seguro. No entanto, deve-se notar que outras modalidades são possíveis sem o uso dessas assinaturas S e SS, como aparece em particular com referência às Figuras 5-6.
[0167] Conforme representado na Figura 7, o terminal C2 também realiza duas etapas de atualização B8 e B10. Mais particularmente, durante a etapa de atualização B8, o terminal C2 atualiza o contador de transações nonce2 armazenado neste exemplo em sua memória MR2. Como já indicado, o identificador de transação nonce2 foi previamente alocado (ou definido) pelo terminal C2 para identificar a transação atual TR1. Este identificador nonce2 pode ser particularmente um contador representativo de um número atual de transações feitas pelo terminal C2. Durante a atualização B8, o terminal C2 pode, por exemplo, aumentar ou diminuir o valor atual do contador nonce2. Assume-se aqui, por exemplo, que o terminal C2 incrementa em 1 o valor do contador nonce2 em B18. Outros mecanismos de atualização (diminuição, etc.) são, no entanto, possíveis.
[0168] Além disso, durante a atualização B10, o terminal C2 atualiza o saldo da conta ACN2 associado à conta U2 do terminal C2 de modo a subtrair do saldo da conta ACN2 o valor MT1a da transação atual TR1. Ou seja, o saldo da conta ACN2 é debitado com o valor MT1a que se supõe ser igual ao valor MT1 solicitado pelo terminal C1. Alternativamente, esta etapa de atualização B10 é realizada posteriormente, por exemplo, uma vez que o terminal C1 informa ao terminal C2 que o pagamento do crédito CR1 foi aprovado.
[0169] Deve-se notar também que a ordem em que as etapas B4 a B10 são realizadas pode ser adaptada dependendo do caso.
[0170] Durante uma etapa de envio B12 (Figura 7), o terminal C2 envia terceiros dados DT3 ao terminal C1 para efetuar o pagamento, da conta U2 do terminal C2 para a conta U1 do terminal C1, do crédito CR1 correspondente à quantidade MT1a. Esses terceiros dados DT3 compreendem os segundos dados DT2 usados em B4 e B6 para calcular as assinaturas S e SS, bem como as assinaturas S e SS.
[0171] Conforme representado na Figura 8, o terminal C1 recebe em A20 os dados DT3 provenientes do terminal C2.
[0172] Durante uma etapa de verificação A21, o terminal C1 verifica a super assinatura SS recebida nos dados DT3 da primeira assinatura S e os dados DT2 também presentes nos dados DT3 e do grupo chave pública PK disponível para o terminal C1 em sua área de memória Z2. Como já indicado, o grupo de chave pública PK está associado a um grupo ao qual pertencem o primeiro e o segundo terminais C1, C2.
[0173] Neste exemplo particular, para verificar (A21) a validade da super assinatura SS, o terminal C1 realiza os passos A22 e A23 (Figura 8). Mais especificamente, o terminal C2 executa (A22) uma função hash (denotada "Hash") a partir dos dados DT2 e da primeira assinatura S, de modo a obter uma impressão digital h (comumente chamada de "hash"). Em outras palavras:
[Matemática 3] h = Hash (DT2, S)
[0174] Uma vez que a técnica de Hashing é bem conhecida dos especialistas na técnica, ela não será descrita em detalhes neste documento.
[0175] O terminal C2 então compara (A23) a impressão digital h com um parâmetro x tal que:
x = SSe mod N
onde SS é a super assinatura, os parâmetros e e N são definidos pela chave pública do grupo PK, e mod corresponde à função "módulo". O expoente e na expressão acima é chamado de expoente público. N corresponde ao módulo RSA (como usado em uma assinatura criptográfica RSA ou em um sistema criptográfico RSA). Para isso, é possível, por exemplo, usar o PKCS#1 que é um padrão para o sistema criptográfico RSA.
[0176] O terminal C2 detecta em A23 que a super assinatura SS é válida se a impressão digital h for igual ao parâmetro x calculado a partir da super assinatura SS e da chave pública de grupo SK. Se a super assinatura SS não for válida, o terminal C2 bloqueia (ou rejeita) a transação TR1 e o método termina.
[0177] Assim, a transação atual TR1 é aprovada pelo terminal C1 somente se o resultado da verificação A21 da super assinatura SS for positivo. A utilização da assinatura S e da super assinatura SS permite aumentar ainda mais a segurança das transações na medida em que permite garantir a autenticidade do terminal C2 com o qual o terminal C1 coopera durante a transação em curso. O terminal C1 pode assim confiar no comportamento do terminal C2 e garantir que o terminal C2 provavelmente não lhe enviará uma transação incluindo um segundo dado válido DT2 (por exemplo, um novo valor do primeiro identificador de transação nonce2 e/ou um novo valor do contador de geração GEN1a) para pagar o valor de um crédito já gasto pelo referido terminal C2 (isto é, neste exemplo, a partir da conta de usuário U2).
[0178] De acordo com outros exemplos, a geração de assinatura SS e sua verificação estão de acordo com o algoritmo ECDSA ou RSA PKCS#1 V1.5 ou V2.1 (isso também é válido para a assinatura S).
[0179] Se a super assinatura SS for considerada válida em A21, o terminal C1 realiza as etapas de verificação A24 e A25 (Figura 8).
[0180] Durante a etapa de verificação A24, o terminal C1 verifica se a chave pública PK1a recebida em A20 nos dados DT3 coincide com (é idêntica) a chave pública PK1 do terminal T1 armazenada na área de memória Z2 (e, portanto, coincide com a chave pública PK1 do terminal T1 armazenada na área de memória Z2 chave PK1 fornecida em A2 para o terminal C2 neste exemplo).
[0181] Durante a etapa de verificação A25, o terminal C1 verifica se o valor MT1a do crédito CR conforme indicado pelo terminal C2 nos dados DT3 recebidos em A20 coincide com (é idêntico a) o valor MT1 especificado nos dados DT1 transmitidos em A2 por o terminal C1 ao terminal C2. De acordo com uma variante, o terminal C1 verifica em A25 que o valor MT1a é maior que o valor MT1 (por exemplo, em um caso há taxas aplicadas durante a transação TR1).
[0182] Deve-se notar que a ordem em que as verificações A21, A24 e A25 são realizadas pode ser adaptada dependendo do caso. Em geral, a transação atual TR1 é aprovada pelo terminal C1 somente se o resultado dessas verificações for positivo.
[0183] Particularmente, o terminal C1 aprova a transação atual TR1 somente se: a chave pública PK1a coincidir com a chave pública PK1 e os valores MT1a e MT1 coincidirem (ou, na variante mencionada, somente se o valor MT1a for maior que o valor MT1).
[0184] Deve-se notar que as modalidades também são possíveis sem realizar pelo menos qualquer uma (ou nenhuma) das etapas A24 e A25. Neste caso, não é necessário que o terminal C2 forneça a chave pública PK1a e/ou a quantidade MT1a nos dados DT2 enviados em B12. Embora isso seja possível, também não é necessário que o terminal C1 envie os dados DT1 em A2 sua chave pública PK1 e/ou a quantidade MT1.
[0185] Após a detecção de que as etapas de verificação A21, A24 e A25 passaram com sucesso (resultados positivos), o terminal C1 executa as etapas A26–A42 (Figura 8) como já descrito acima com referência às Figuras 5–6.
[0186] Neste exemplo particular, assume-se que o terminal C1 detecta em A26 que o valor inicial Val1 do contador de geração GEN1 armazenado na área de memória Z2 por um lado, e o valor do contador de geração GEN1a recebido nos dados DT3 em por outro lado, são idênticos.
[0187] Supõe-se que o terminal C1 detecta então em A30 a presença no histórico H1 da entrada EN1 associada à chave pública PK2 do terminal C2 e ao identificador de transação nonce1. Como já indicado, este identificador pré-gravado nonce1 pode identificar a transação mais recente (diferente da transação atual TR1) durante a qual um crédito CR foi recebido pelo terminal C1 proveniente do terminal C2. Considera-se neste exemplo que os identificadores nonce1 e nonce2 são contadores de transações. Quanto ao contador de transações nonce2, o contador pré-gravado nonce1 foi, por exemplo, recebido pelo terminal C1 do terminal C2 durante a última (a mais recente) transação para transferir um CR de crédito do terminal C2 para o terminal C1. Conforme já indicado, o uso destes identificadores de transação permite evitar os pagamentos em duplicidade do terminal C2 para o terminal C1 com os mesmos créditos CR.
[0188] O terminal C1 detecta, por exemplo, em A34, que a condição predeterminada CD1 é cumprida se os contadores de transações nonce1 e nonce2 forem diferentes. Alternativamente, o terminal C1 detecta em A34 que a condição predeterminada CD1 é cumprida se os contadores de transações nonce1 e nonce2 forem tais que nonce2 > nonce1, em um caso particular em que o terminal C2 incrementa seu identificador nonce para identificar cada nova transação para pagar um crédito CR.
[0189] Supõe-se agora que o terminal C1 detecta em A34 (Figura 8) que o identificador de transação nonce2 cumpre a condição predeterminada CD1, o que significa que a transação atual TR1 é única e que, portanto, não há risco de pagamento duplo. O terminal C1, portanto, aprova a transação atual e prossegue para a etapa A38 conforme descrito anteriormente. Neste exemplo, o terminal C1 pode usar com confiança o identificador de transação nonce2 fornecido pelo terminal C2 em A20, desde que a autenticidade do terminal C2 tenha sido verificada previamente usando as assinaturas S e SS.
[0190] O terminal C1 realiza, portanto, o armazenamento A40 de uma nova entrada EN2 e a atualização A42 do saldo da conta ACN1, conforme já descrito anteriormente com referência às Figuras 5–6. Deve-se notar que durante a etapa de armazenamento A40, o terminal C1 registra no histórico H1 uma nova entrada EN2 associada à chave pública PK2 do segundo terminal C2 e com o identificador de transação nonce2 recebido em A20 do terminal C2. Este identificador de transação nonce2 pode assim ser usado pelo terminal C1 durante uma próxima transação durante a qual o terminal C2 tenta novamente fazer um pagamento a crédito ao terminal C1. Particularmente, o terminal C1 será capaz de levar em conta este nonce2 durante uma nova ocorrência da etapa A34 para determinar se um novo nonce (denominado nonce3) recebido satisfaz a condição de exclusividade CD1 (como já descrito com referência à etapa A34, Figuras 5 e 8).
[0191] Além disso, a Figura 9 representa um exemplo de implementação da etapa de gerenciamento A60 representada na Figura 6. Conforme já descrito, esta etapa A60 visa gerenciar o espaço de memória da primeira área de memória Z1, compreendendo esta etapa uma etapa de detecção A62 e um processo de despejo A74. Esta etapa de gerenciamento A60 pode ser acionada em vários momentos, em resposta a um evento de acionamento detectado em A62.
[0192] Mais especificamente, assume-se que o terminal C1 está em um estado inicial de acordo com o qual:
  • - o saldo da conta ACN1 armazenado na área de memória Z2 é igual ao valor ACN0 de pelo menos uma transação passada durante a qual o terminal C1 recebeu um CR de crédito de um dispositivo de débito (ACN1 = ACN0 onde ACN0 é o valor da(s) transação(ões) passada(s));
  • - o contador de geração GEN1 armazenado na área de memória Z2 é ajustado para um valor inicial Val1 (GEN1 = Val1);
  • - o histórico H1 armazenado na área de memória Z1 compreende dados de histórico DH0 representativos da(s) transação(ões) passada(s).
[0193] Antes da etapa de detecção A62, assume-se que o terminal C1 processa (A59, Figura 9) uma ou várias transações offline TRX com pelo menos qualquer terminal externo (por exemplo, com o terminal C2). Cada vez que uma transação offline TRX é aprovada (A38, Figuras 5 e 8), o terminal C1 atualiza seu histórico H1 na área de memória Z1 e seu saldo de conta ACN1 na área de memória Z2. Uma vez aprovada(s) a(s) transação(ões) TRX off-line, o histórico H1 compreende, portanto, os dados do histórico DH0, bem como os dados do histórico DH1 representativos das transações TRX. O saldo da conta ACN1 também é incrementado pelo valor ACNX das transações offline realizadas TRX (ACN1 = ACN0 + ACNX). Assume-se neste exemplo que nenhum processo de despejo A74 (Figura 6) foi realizado nesta fase a partir da etapa de processamento A59, de modo que o contador de geração GEN1 armazenado na área de memória Z2 permanece inalterado no valor inicial Val1.
[0194] Supõe-se agora que o terminal C1 verifica se a condição predeterminada CD2 é cumprida e detecta em A62 que o espaço de memória ESP1 ocupado na primeira área de memória Z1 satisfaz esta condição CD2, o que significa que existe o risco de saturação da área de memória Z1. Esta verificação é realizada, por exemplo, durante uma transação (no final da transação, por exemplo). O terminal C1 detecta, por exemplo, que o espaço de memória ocupado ESP1 atinge pelo menos um valor limite TH1 que pode corresponder, por exemplo, a 75% ou 80% do espaço total da área de memória Z1.
[0195] Conforme representado na Figura 9, após a detecção de que a condição predeterminada CD2 é satisfeita (A62), o terminal C1 interroga o sistema online NT1 para recuperar quaisquer dados representativos de transações online TRY provavelmente recebidos recentemente para pagar créditos CR à conta U1 associada ao terminal C1. Para tal, o terminal C1 envia (A68) um pedido de transação online RQ1 ao sistema online NT1 que recebe este pedido em C68 (Figura 1). Em resposta, o sistema online NT1 envia (C70) para o terminal C1 dados de transação DHY – denominados dados de transação online – representativos de pelo menos uma transação online TRY feita pelo sistema online NT1 em cooperação com pelo menos um dispositivo externo (diferente de C1) para pagar um crédito CR na conta U1 associada ao terminal C1.
[0196] Os dados da transação online DHY especificam particularmente um saldo de crédito CR ACNY a ser pago na conta U1 associada ao terminal C1. Esses dados de transações online DHY também podem incluir um contador de geração GENY associado a cada transação offline TRY.
[0197] O terminal C1 recebe os dados da transação online DHY em A70 e, em seguida, processa (A72) esses dados DHY para atualizar seu saldo de conta ACN1 e seu histórico H1 de acordo. Assim, assume-se aqui que o terminal C1 credita o saldo da conta ACN1 com o valor ACNY correspondente aos valores acumulados das transações online TRY processadas pelo sistema online NT1 (portanto, ANC1 = ACN0 + ACNX + ACNY). Da mesma forma, o terminal C1 pode atualizar o histórico H1 para incluir os dados da transação online DHY das transações online TRY. Assume-se neste exemplo que nenhum processo de despejo A74 (Figura 6) foi realizado nesta fase a partir da etapa de processamento A60, de modo que o contador de geração GEN1 armazenado na área de memória Z2 permanece inalterado no valor inicial Val1.
[0198] Deve-se notar que se um contador de geração GENY é fornecido pelo sistema online NT1 nos dados da transação online DHY para cada transação online TRY processada, então o terminal C1 pode processar em A72 esses contadores para verificar se eles são válidos. Para isso, o terminal C1 verifica (A72) que cada contador de geração GENY recebido coincide com o contador de geração atual GEN1 armazenado na área de memória Z2, da mesma forma que durante a etapa de verificação A26 descrita anteriormente (Figuras 5 e 8). O terminal C1 então apenas aprova cada transação para a qual o contador de geração GENY fornecido pelo sistema online NT1 é válido (ou seja, síncrono com o contador de geração atual GEN1). Em outras palavras, o terminal C1 então atualiza o saldo da conta ACN1 armazenado na segunda área de memória Z2 a partir dos dados de transação online DHY correspondentes a cada transação online TRY cujo contador de geração GENY fornecido em A70 coincide com o contador de geração GEN1. O terminal C1 também pode atualizar o histórico H1 para incluir apenas os dados da transação online DHY correspondentes a cada transação online TRY cujo contador de geração associado GENY seja válido.
[0199] De acordo com um exemplo particular, durante o processamento A72, o terminal C1 também verifica se os dados de transação online DHY recebidos em A70 correspondem aos dados de transação DH que já estão armazenados no histórico H1. Em outras palavras, o terminal C1 verifica se as transações online TRY especificadas pelos dados DHY ainda não estão presentes no histórico H1. O terminal C1 leva então em consideração apenas as transações online TRY que ainda não estão armazenadas no histórico H1 para atualizar o saldo da conta ACN1 e o histórico H1 em A72.
[0200] Uma vez processadas as transações online TRY, o terminal C1 executa o processo de despejo A74 da mesma forma descrita anteriormente com referência às Figuras 5–6. Neste exemplo, o terminal C1 atualiza assim (A76) o contador de geração GEN1 armazenado em sua área de memória Z2, de modo a atribuir a este contador GEN1 um novo valor Val2, diferente do valor inicial Val1. Para isso, o terminal C1, por exemplo, incrementa o contador de geração GEN1 em 1. O terminal C1 também realiza um despejo (ou purga) A78 como já descrito para apagar todo ou parte do histórico H1. Supõe-se aqui que todo o histórico H1 é excluído para liberar o máximo de espaço de memória possível.
[0201] De acordo com um exemplo particular, uma vez realizado o processo de despejo A74, o terminal C1 envia (A90, Figura 9 ) ao sistema online NT1 um pedido de atualização RQ2 compreendendo o contador de geração atual GEN1, ou seja, que tem o novo valor Val2 atribuído durante a atualização A76, para que o servidor online NT1 possa associar a chave pública PK1 do primeiro terminal C1 com o contador de geração GEN1 configurado para o novo valor Val2 para permitir seu acesso a pelo menos um dispositivo externo (ou a dispositivos externos), incluindo, por exemplo, o terminal C2.
[0202] Assim, em resposta ao pedido RQ2 recebido em B90, o sistema online NT1 atualiza (B92) um valor atual do contador de geração GENY armazenado em associação com a chave pública PK1 do terminal C1. Este valor pode ser armazenado e atualizado em uma memória do referido sistema NT1, por exemplo na memória de um ou vários servidores SV (Figura 1), de modo que o contador GENY seja igual ao contador atualizado GEN1.
[0203] O contador de geração GENY associado à chave pública PK1 também é acessível por pelo menos um dispositivo externo, como por exemplo o terminal C2 neste caso particular. Assim, o terminal C2 (e possivelmente também outros dispositivos externos) é capaz de processar as transações subsequentes utilizando o contador de geração GENY com o valor atualizado, a fim de pagar um crédito CR ao terminal C1. Particularmente, o terminal C2 pode assim incluir em seus dados de transação DT3 o contador de geração atualizado GENY (como um contador GEN1a) da mesma maneira descrita acima com referência à etapa de envio A20 (Figuras 5 e 8).
[0204] Deve-se notar que são possíveis variantes nas quais a etapa A64 de recuperação dos dados da transação online DHY, e possivelmente também as etapas A90 e B90–B92, não são executadas.
[0205] Conforme indicado acima, o processo de despejo A74 descrito acima com referência às Figuras 6 e 9 pode ocorrer em vários momentos, dependendo da configuração do terminal C1 e do estado de ocupação da área de memória Z1. De acordo com um exemplo particular, a atualização A76 do contador de geração GEN1 é realizada após o envio A2 dos dados DT1, mas antes do recebimento A20 dos dados DT1 (Figura 7), causando a detecção de uma incompatibilidade (dessincronização) dos contadores de geração GEN1 e GEN1a durante a verificação A26.
[0206] Os versados na técnica entenderão que as modalidades e variantes descritas acima constituem apenas exemplos não limitativos de implementação da invenção. Particularmente, os versados na técnica podem prever qualquer adaptação ou combinação das modalidades e variantes descritas acima, de acordo com as reivindicações seguintes, para atender a uma necessidade muito específica.

Claims (16)

  1. Método de controle implementado por um primeiro dispositivo (C1) capaz de processar transações em cooperação com um segundo dispositivo (C2), o primeiro dispositivo caracterizado por compreender: - uma primeira área de memória (Z1) na qual um histórico (H1) compreendendo uma ou várias entradas representativas de uma transação é armazenado, e - uma segunda área de memória (Z2) na qual um contador de primeira geração (GEN1) definido para um valor inicial (Val1) é armazenado, o método compreendendo, durante o processamento de uma transação atual (TR1):
    a) consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um momento atual durante o qual a transação atual é processada.
    b) recebimento (A20), vindo do segundo dispositivo, dos primeiros dados (DT3) compreendendo segundos dados (DT2), os referidos segundos dados compreendendo:
    • - uma chave pública (PK2) do segundo dispositivo,
    • - um valor (MT1a) de um crédito a ser pago durante a transação atual,
    • - um contador de segunda geração (GEN1a), e
    • - um primeiro identificador de transação (nonce2) alocado pelo segundo dispositivo para a transação atual;
    c) verificação (A26) de que os contadores de primeira e segunda geração (GEN1, GEN1a) possuem valores iguais;
    d) se o resultado da verificação c) for negativo, negação da transação atual pelo referido primeiro dispositivo (C1);
    e) se o resultado da verificação c) for positivo, verificação (A30) na primeira área de memória (Z1) de que o histórico (H1) compreende uma entrada (EN) associada à chave pública (PK2) do segundo dispositivo;
    f) se o resultado da verificação e) for negativo, a transação atual é (A32) aprovada;
    g) se o resultado da verificação e) for positivo, verificação (A34) de que o primeiro identificador de transação (nonce2) satisfaz uma primeira condição predeterminada (CD1) indicando a unicidade da transação atual;
    h)se o resultado da verificação g) for positivo, a transação atual é aprovada (A38); em que, se a transação atual for aprovada, o processamento da transação atual compreende ainda:
    i) armazenamento (A40) no histórico (H1) de uma nova entrada (EN2) associada à chave pública (PK2) do segundo dispositivo; e
    j) atualização (A42) de um saldo de conta (ACN1) armazenado na segunda área de memória (Z2), de modo a pagar o valor do referido crédito à conta associada ao primeiro dispositivo; o método compreendendo ainda uma etapa de gerenciamento da primeira área de memória (Z1), sendo a referida etapa de gerenciamento implementada antes, após ou durante uma transação atual e compreendendo:
    k) detecção de que o espaço ocupado (ESP1) na primeira área de memória satisfaz uma segunda condição predeterminada (CD2) indicando um risco de saturação da referida primeira área de memória; e
    l) em resposta à detecção k), implementação de um processo de despejo compreendendo:
    l1) atualização do contador de primeira geração (GEN1) na segunda área de memória (Z2) de modo a atribuir ao referido contador de primeira geração um novo valor (Val2) diferente do valor inicial; e
    l2) despejo de pelo menos parte da primeira área de memória (Z1) para liberar espaço de memória, quando a referida etapa de gerenciamento é implementada durante a transação atual, ela é implementada com exceção dos seguintes momentos:
    - entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um tempo atual durante o qual a transação atual é processada e etapa A30, se o teste da etapa A26 for positivo.
    - entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um tempo atual durante o qual a transação atual é processada e etapa A26, se o teste da etapa A26 for negativo.
    - entre e durante a etapa de consulta da segunda área de memória (Z2) para determinar o contador de primeira geração (GEN1) em um momento atual durante o qual a transação atual é processada e etapa A40.
  2. Método, de acordo com a reivindicação 1, caracterizado por o processamento da transação atual (TR1) compreender, antes da etapa b): m) enviar ao segundo dispositivo de terceiros dados (DT1) para solicitar o pagamento pelo segundo dispositivo do valor do referido crédito na conta associada ao primeiro dispositivo, compreendendo os referidos terceiros dados o contador de primeira geração (GEN1) definido para o valor inicial.
  3. Método, de acordo com qualquer uma das reivindicações 1 a 2, caracterizado por os primeiros dados (DT3) recebidos em b) compreenderem:
    - uma primeira assinatura (S) calculada a partir dos segundos dados (DT2), e
    - uma segunda assinatura (SS) calculada a partir dos segundos dados e da primeira assinatura; o método compreendendo, após o recebimento b):
    n) verificação da segunda assinatura (SS) a partir da primeira assinatura (S) e do segundo dado (DT2) recebido no primeiro dado (DT3) e de uma chave pública de grupo (PK) associada a um grupo ao qual o primeiro e o segundo dispositivos pertencem; a transação atual sendo aprovada somente se o resultado da verificação n) for positivo.
  4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado por, se for determinado durante a verificação c) que os contadores de primeira e segunda geração (GEN1, GEN1a) têm valores que não são iguais, a transação atual é bloqueada
  5. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado por o primeiro identificador de transação (nonce2) alocado pelo segundo dispositivo ser um contra-representante de um número atual de transações feitas pelo segundo dispositivo.
  6. Método de acordo com qualquer uma das reivindicações 1 a 5, caracterizado por durante o armazenamento i), a nova entrada estar associada à chave pública (PK2) do segundo dispositivo e ao primeiro identificador de transação (nonce2); em que a verificação g) compreende:
    - determinação de um segundo identificador de transação (nonce1) armazenado, em associação com a chave pública do segundo dispositivo, em uma entrada (EN1) detectada no histórico (H1) durante a verificação e); e
    - comparação do primeiro identificador de transação (nonce2) com o segundo identificador de transação (nonce1), em que a primeira condição predeterminada (CD1) é detectada para ser satisfeita se o primeiro e o segundo identificadores de transação forem diferentes ou se o primeiro e o segundo identificadores de transação forem contadores de modo que o primeiro identificador de transação seja maior que o segundo identificador de transação.
  7. Método de acordo com qualquer uma das reivindicações 1 a 6, caracterizado por ser implementado por uma primeira carteira virtual implementada pelo primeiro dispositivo, em cooperação com uma segunda carteira virtual implementada no segundo dispositivo, sendo a transação atual uma transação de pagamento do referido crédito em uma moeda.
  8. O método de acordo com qualquer uma das reivindicações 1 a 6, caracterizado por a transação atual ser uma transação de reputação e o crédito pago durante a referida transação de reputação ser um crédito de reputação.
  9. Método, de acordo com qualquer uma das reivindicações 1 a 8, caracterizado por durante a detecção k), a segunda condição predeterminada (CD2) ser satisfeita se o espaço ocupado na área de memória atingir uma porção predeterminada do espaço total da primeira área de memória.
  10. Método de acordo com qualquer uma das reivindicações 1 a 9, caracterizado por durante o despejo l2), toda a primeira área de memória (Z1) ser esvaziada para liberar espaço de memória
  11. Método, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado por durante o processo de despejo l):
    • - a atualização l1) e o despejo l2) serem realizados concomitantemente, ou
    • - o despejo l2) ser realizado após a atualização l1).
  12. Método, de acordo com qualquer uma das reivindicações 1 a 11, caracterizado por a atualização l1) do contador de primeira geração causar um bloqueio de todas as transações, processadas pelo primeiro dispositivo, para as quais o contador de segunda geração (GEN1a) recebido em b) tenha um valor que difere do novo valor.
  13. Método, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por a etapa de gerenciamento da primeira área de memória (Z1) compreender, em resposta à detecção
    k) e antes do processo de despejo l): o) envio de um pedido de transação online para um sistema online compreendendo pelo menos um servidor;
    p) recebimento, em resposta à referida solicitação de transação on-line, de dados de transação on-line representativos de pelo menos uma transação on-line feita pelo referido sistema on-line em cooperação com pelo menos um dispositivo externo para pagar um crédito na conta associada ao primeiro dispositivo, a referida transação on-line dados compreendendo um contador de terceira geração em associação com cada transação online; e
    q) verificação para cada transação online que os contadores de primeira e terceira geração (GEN1, GEN3) possuem valores iguais; e
    r) atualização, a partir dos dados de transação online correspondentes a cada transação online cujo contador de terceira geração coincide com o contador de primeira geração, do saldo da conta (ACN1) armazenado na segunda área de memória (Z2).
  14. Método, de acordo com a reivindicação 13, caracterizado por o processo de despejo l) compreender, após a atualização l1):
    s) envio para o sistema online do contador de primeira geração com o novo valor atribuído em l1), para que o servidor online possa associar a chave pública (PK1) do primeiro dispositivo com o contador de primeira geração definido para o novo valor para permitir seu acesso a pelo menos um dispositivo externo para processar transações subsequentes.
  15. Método de controle implementado por um sistema que compreende um primeiro dispositivo que implementa um método de acordo com qualquer uma das reivindicações 1 a 14 e um segundo dispositivo cooperando com o primeiro dispositivo, o método caracterizado por compreender:
    t) aquisição, pelo segundo dispositivo, da chave pública (PK2) do segundo dispositivo, do valor (MT1a) do crédito a ser pago durante a transação atual, do contador de segunda geração (GEN1a) e da primeira transação identificador (nonce2) alocado pelo segundo dispositivo para a transação atual; e
    u) envio, pelo segundo dispositivo, para o primeiro dispositivo, dos primeiros dados (DT3) que compõem os segundos dados (DT2), para efetuar o pagamento do valor do crédito na conta associada ao primeiro dispositivo.
  16. Programa de computador (PG1; PG2) caracterizado por incluir instruções para a execução dos passos de um método de controle de acordo com qualquer uma das reivindicações 1 a 15 quando o referido programa é executado por um computador.
BR102022007423-2A 2021-04-16 2022-04-18 Gerenciamento de memória em um dispositivo de processamento de transações BR102022007423A2 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103946 2021-04-16
FR2103946A FR3122010B1 (fr) 2021-04-16 2021-04-16 Gestion de la mémoire dans un dispositif de traitement de transactions

Publications (1)

Publication Number Publication Date
BR102022007423A2 true BR102022007423A2 (pt) 2022-10-25

Family

ID=77226856

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102022007423-2A BR102022007423A2 (pt) 2021-04-16 2022-04-18 Gerenciamento de memória em um dispositivo de processamento de transações

Country Status (4)

Country Link
US (1) US20220335420A1 (pt)
EP (1) EP4075358B1 (pt)
BR (1) BR102022007423A2 (pt)
FR (1) FR3122010B1 (pt)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7321692B2 (en) * 2001-11-13 2008-01-22 Anoto Ab Method, device and computer program product for processing information in a memory
CN101320389B (zh) * 2008-06-30 2011-07-13 中兴通讯股份有限公司 文件管理方法和装置
US20170046689A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Voting and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US10949520B2 (en) * 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
JP2021048546A (ja) * 2019-09-20 2021-03-25 富士通株式会社 通信装置、通信方法、通信システム、およびプログラム

Also Published As

Publication number Publication date
FR3122010A1 (fr) 2022-10-21
EP4075358C0 (fr) 2023-11-15
FR3122010B1 (fr) 2024-03-01
EP4075358B1 (fr) 2023-11-15
US20220335420A1 (en) 2022-10-20
EP4075358A1 (fr) 2022-10-19

Similar Documents

Publication Publication Date Title
US11875344B2 (en) Cloud-based transactions with magnetic secure transmission
US11783061B2 (en) Embedding cloud-based functionalities in a communication device
US10909522B2 (en) Cloud-based transactions methods and systems
US11502848B2 (en) Blockchain entity, off-chain entity, certification device for blockchain operations and method for performing a cooperation between a blockchain entity and an off-chain entity
CA3027909C (en) Authentication in ubiquitous environment
RU154072U1 (ru) Средство чтения смарт-карты с безопасной функцией журналирования
CN107797827A (zh) 安全储存系统以及用于安全储存的方法
JP3636984B2 (ja) Ｉｃカードシステム用記録媒体及びｉｃカードシステム
BRPI0911217B1 (pt) métodos para suporte de múltiplos aplicativos sem contato, dispositivo inteligente sem fio e meios que podem ser lidos em computador
WO2020082898A1 (zh) 基于区块链的交易处理方法及装置、电子设备
JP6037583B2 (ja) データの再インストールを管理するためのシステム、方法、およびコンピュータプログラム製品
US11017396B2 (en) Automatic transaction device and control method thereof
BR102022007423A2 (pt) Gerenciamento de memória em um dispositivo de processamento de transações
BR102022007206A2 (pt) Gerenciamento de memória em um dispositivo de processamento de transações
BRPI0610977A2 (pt) terminal móvel de transações eletrÈnicas seguras e sistema de transações eletrÈnicas seguras
US20190378114A1 (en) Method of managing an emergency mode transaction procedure, and an associated device
JP7009844B2 (ja) 電子情報記憶媒体、ｉｃカード、電子情報記憶媒体によるアップデート方法及びアップデートプログラム
JP2013105438A (ja) カード照合システム、およびカード照合方法
CN110956551A (zh) 一种收益分发方法及相关设备
JP2013105437A (ja) カード発行システム、カード発行機、およびカード発行方法

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]