FR3078187A1 - CONTROL OF A VIRTUAL COIN PURSE - Google Patents

Abstract

The invention proposes a method for controlling a virtual wallet (4) in a processing device (DV1) capable of performing transactions in a cryptographic currency from transaction entries (TI), the method comprising: when processing a transaction in progress, generating, from at least one transaction entry, a transaction output (TO) defining the transaction; storing (M1) a parameter (SP) of a status of a transaction entry, which parameter is initially set to a first value as long as the transaction input (TI) is not used in a transaction ; if the transaction entry is used, assigning a second value to the parameter (SP) of the transaction entry (TI); wherein, when processing the current transaction, the transaction input (TI) is used in the generation of the transaction output (TO) if the parameter (SP) is set to the first value.

Description

Background ,, dg „H.nYentfon _:

The invention relates to the field of payment systems using a cryptographic currency (or cryptocurrency), that is to say a virtual currency usable on a decentralized computer network (peer to peer) and using cryptographic mechanisms.

The invention relates more particularly to the management of a virtual wallet enabling transactions to be carried out in a cryptographic currency.

A virtual currency of cryptographic type well known to date is "bitcoin" which is based on a peer-to-peer payment system called Bitcoin. The Bitcoin system makes it possible to make account-to-account transactions, thanks to software called virtual wallet (or “wallet” in English) implemented in appropriate processing devices (smartphones, computers, etc.). The validity of each transaction is verified by verification terminals (or software) called "miners", the transactions once validated being registered in a public register called block chain (or "blockchain" in English) because of its constituted structure of a series of blocks. Each block defines transactions validated by minors and refers to previous transactions.

In particular, a virtual wallet allows you to create an account and carry out bitcoin transactions with a third-party account. During a payment transaction for example, the account of the virtual wallet is debited with a certain amount in bitcoin to credit the third party account.

A virtual wallet can store data (or entries) corresponding to old transactions for which the virtual wallet was the beneficiary (the recipient). This data, called "inputs" or "transaction inputs", constitutes the value available in bitcoin owned by the user of the wallet. From its transaction inputs, the virtual wallet can generate "outputs" or "transaction outputs" defining amounts in bitcoin transferred during payment transactions from the user's account to accounts of third party recipients. Each transaction output defines an amount of the transaction and the statement of the third party account that is credited.

In addition, each account is associated with a pair of cryptographic dice including a public die and a private die. To make transfers, a virtual wallet must sign its transactions using at least one private key.

The transactions thus carried out are broadcast to verification terminals (minors) which validate the transactions they receive and gradually group them together before saving them in the form of blocks in the block chain. The miners' network checks in particular the validity of the signature of each transaction using the public key corresponding to the debtor account, using an asymmetric cryptography mechanism. During this verification operation, the miners assemble the bulk transactions by adding a header including specific indications (date, time, checksum or "hash" ...). The entry in the block chain of a new transaction (transaction exit) has the effect of prohibiting any subsequent use of the transaction entries from which the new transaction was made, which amounts to debit the accounts of payers and credit recipient accounts.

The verifications carried out by the verification terminals during mining operations to validate each transaction require processing time and special resources. During a transaction, the third party recipient must therefore wait a minimum processing time (10 minutes to 1 hour, for example) from the time of the transaction to ensure that the transaction is validated. If the third party does not wait for the transaction to be confirmed before delivering its consideration (for example relating to a good or service), it takes the risk of not being paid. This waiting time presents a problem in certain transactions, in particular those carried out in everyday life.

In addition, the waiting period necessary for the completion of this validation and registration process presents a risk insofar as this period can be exploited to carry out a so-called “double payment” attack. This attack, which can be carried out by a malicious third party, consists in spending several times the same cryptographic currency (or money) before the validation of a first transaction has taken place, in order for example to obtain several goods or services from different merchants. In this case, only one of the potential recipients is ultimately paid (the one for which the validation and registration process is completed the fastest).

These risks of non-payment oblige third party recipients to wait for the processing time necessary to obtain confirmation that the transaction has been validated. This waiting time has a disadvantage for users. The risks associated with double payment problems further decrease user confidence in the Bitcoin system.

In addition, when a payment transaction is carried out by a virtual wallet, a problem may arise when a breakdown or a technical difficulty occurs in particular at the terminal of the third party recipient before the transaction has been validated and entered in the block chain. In such a situation, the transaction entries used for the transaction are blocked and can no longer be used although the payment has not actually taken place.

Today, there is no satisfactory system making it possible to overcome the problems and drawbacks exposed above. In particular, there is a need for a solution which makes it possible to secure transactions carried out in a cryptographic currency such as bitcoin or the like, and in particular to avoid the phenomenon of double payment and allow faster transactions between the parties. There is also a need to manage a situation in which a technical difficulty arises during a transaction, preventing it from succeeding.

Subject and summary of the invention

To this end, the present invention relates to a method for controlling a virtual wallet, implemented in a processing device capable of carrying out transactions in a cryptographic currency, the processing device storing in a memory at least one transaction entry. defining a transaction of which the virtual wallet has been the beneficiary, the method comprising:

processing of a transaction in progress, comprising a generation, from at least one transaction input, of a transaction output defining the transaction in progress between the processing device and a third-party terminal;

the method further comprising:

conservation in memory of at least one parameter representative of a status of an associated transaction entry stored in said memory, the parameter being initially set at a first value as long as said associated transaction entry is not used by the virtual wallet when processing a transaction to generate a transaction output;

- upon detection that said associated transaction entry is used by the wallet to generate a transaction output, modification of the status of said associated transaction entry by assigning to said parameter a second value different from the first value to indicate that said associated transaction entry is spent;

wherein, said processing of the transaction in progress comprises a verification of the parameter of an associated transaction entry, the latter being used in the generation of the transaction output only if said parameter is set to the first value indicating that said entry of associated transaction is not spent.

The invention advantageously allows a processing device, such as a smart card for example, to control the status of the transaction entries stored in its memory so as to determine the transaction entries which have been spent and which are still available to complete a payment transaction. By assigning a first value or a second value to the status parameters of each transaction entry, the processing device can distinguish spent transaction entries from those that are not spent.

The invention further allows the processing device to block all transaction inputs which have been spent during a transaction but which are still present in the memory. In this way, the processing device cannot spend several times money corresponding to the same transaction entry, in particular in the period necessary for the completion of the validation and registration process by the network of minors. Once a transaction has been written to the blockchain, synchronization of the processing device with a server can cause the deletion of the transaction entry (s) spent in memory.

The invention thus makes it possible to combat the phenomenon of double-payment already described previously and thus to secure the payment transactions.

According to a particular embodiment, the method comprises:

- first synchronization with a remote server, comprising a reception of a first time indicator representative of a first instant associated with the first synchronization; and

- assignment, to the parameter of at least a first transaction entry indicated as spent, of a third value representative of the first instant and different from the first and second values.

According to a particular embodiment, the method comprises:

- second synchronization, after the first synchronization, with a remote server, comprising a reception of a second time indicator representative of a second instant associated with the second synchronization;

- upon detection that the parameter of the first transaction entry has a third value different from the first and second values, determination from the third value and from the second time indicator, of whether the time interval between the first instant and the second instant reaches a predetermined time limit; and

- in the affirmative, modification of the status of said first transaction entry by assigning to the associated parameter said first value indicating that said first transaction entry is not spent.

According to a particular embodiment, the predetermined time limit is determined from a parameter included in the first transaction entry or in a transaction output generated from said first transaction entry.

According to a particular embodiment, the method comprises:

- synchronization with a remote server, including reception of update data; and

- Upon detection, from the update data, that a transaction entry is no longer valid, the processing device deletes said invalid transaction entry from the memory.

According to a particular embodiment, the method comprises:

- during the second synchronization, receipt of update data; and

- Upon detection, from the update data, that said first transaction entry is no longer valid, the processing device deletes said first transaction entry from the memory.

According to a particular embodiment, in which the cryptographic currency is bitcoin.

According to a particular embodiment, during the processing of the transaction in progress, the processing device authenticates with the third-party terminal by sending a response determined from challenge data previously received from said third-party terminal.

According to a particular embodiment, the response comprises a signature of a message comprising the challenge data.

In a particular embodiment, the different steps of the control method are determined by instructions from computer programs.

Consequently, the invention also relates to a computer program on an information medium (or recording medium), this program being capable of being implemented in a processing device or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a control process as defined above,

This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

The invention also relates to an information medium (or recording medium) readable by a computer, and comprising instructions of a computer program as mentioned above.

The information medium can be any entity or device capable of storing the program. For example, the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disc. hard.

On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from a network of the Internet type.

Alternatively, the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

The invention also relates to a processing device configured to control a virtual wallet intended for carrying out transactions in a cryptographic currency, comprising:

- a storage module configured to store at least one transaction entry defining a transaction of which the virtual wallet has been the beneficiary;

a module for processing a transaction in progress, configured to generate, from at least one transaction input, a transaction output defining the transaction in progress between the processing device and a third-party terminal;

the treatment device further comprising:

a management module configured to keep in memory at least one parameter representative of a status of an associated transaction entry, the parameter being initially set at a first value as long as said associated transaction entry is not used by the processing module during the processing of a transaction to generate a transaction output, the management module being configured, on detection that said associated transaction input is used by the wallet to generate a transaction output, to modify the status said associated transaction entry by assigning said parameter a second value different from the first value to indicate that said associated transaction entry is spent;

wherein, said processing module is configured to check the parameter of an associated transaction entry and to use the latter in generating the transaction output only if said parameter is set to the first value indicating that said associated transaction entry is not spent.

It will be noted that the various embodiments mentioned above in relation to the control method of the invention as well as the associated advantages apply in a similar manner to the processing device of the invention.

According to a particular embodiment, the processing device comprises a synchronization module configured to perform a first synchronization with a remote server, during which the processing device receives a first time indicator representative of a first instant associated with the first synchronization;

the management module being configured to assign, to the parameter of at least a first transaction entry indicated as spent, a third value representative of the first instant and different from the first and second values.

According to a particular embodiment, the synchronization module is configured to perform, after the first synchronization, a second synchronization with a remote server, during which the processing device receives a second time indicator representative of a second associated instant at the second synchronization;

the management module being configured for:

- upon detection that the parameter of the first transaction entry has a third value different from the first and second values, determine from the third value and the second time indicator, whether the time interval between the first instant and the second instant reaches a predetermined time limit; and

- if so, modify the status of said first transaction entry by assigning to the associated parameter said first value indicating that said first transaction entry is not spent.

According to a particular embodiment, the synchronization module determines the predetermined time limit on the basis of a parameter included in the first transaction input or in a transaction output generated from said first transaction input.

According to a particular embodiment, the processing device comprises a synchronization module configured to perform synchronization with a remote server, during which the processing device receives update data;

- in which the management module is configured to detect, from the update data, that a transaction entry is no longer valid; and

- in which the storage module is configured to delete said invalid transaction entry from the memory.

According to a particular embodiment, the synchronization module is configured, during the second synchronization, to receive update data; and upon detection, from the update data, that said first transaction entry is no longer valid, the storage module is configured to delete said first transaction entry from memory.

According to one embodiment, the invention is implemented by means of software and / or hardware components. With this in mind, the term "module" can correspond in this document to a software component, to a hardware component or to a set of hardware and software components.

A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or of software capable of implementing a function or a set of functions, as described below for the module concerned.

In the same way, a hardware component corresponds to any element of a hardware (or hardware) set capable of implementing a function or a set of functions, as described below for the module concerned. It can be a programmable hardware component or with an integrated processor for running software, for example an integrated circuit, a smart card, etc.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate exemplary embodiments thereof without any limiting character. In the figures:

• Figure 1 schematically shows an environment comprising a processing device according to a particular embodiment of the invention;

· Figure 2 schematically shows the structure of a processing device according to a particular embodiment of the invention;

• Figure 3 shows, in the form of a flowchart, the steps of a processing method according to a particular embodiment of the invention;

• Figure 4 shows, in the form of a flowchart, the steps of a processing method according to a particular embodiment of the invention;

• Figure 5 shows, in the form of a flowchart, the steps of a processing method according to a particular embodiment of the invention; and • Figure 6 shows, in the form of a flowchart, the steps of a processing method according to a particular embodiment of the invention.

Detailed description of several embodiments

As indicated above, the invention relates to payment systems using a cryptographic currency (or cryptocurrency). As is well known, a virtual currency can be used on a decentralized computer network (peer-to-peer) 30 to carry out account-to-account transactions using cryptographic keys associated with the accounts of the users.

The invention relates more particularly to the management of a virtual wallet enabling transactions to be carried out in a cryptographic currency. In this document, embodiments of the invention are described in the context of the system.

Bitcoin well known to those skilled in the art and of which certain characteristics have been recalled above. It is understood, however, that the invention does not apply exclusively to virtual wallets using bitcoin currency and can more generally be applied to all types of virtual wallet using any cryptographic currency.

The invention proposes in particular a method for controlling (or managing method) a virtual wallet in a processing device capable of carrying out transactions, and is aimed in particular at managing the transaction entries stored in the processing device and likely to be used by the virtual wallet to carry out a transaction with a third party. To do this, the invention proposes, according to different embodiments, to keep in memory a respective parameter representing a status of each transaction entry stored in the processing device, this parameter being fixed at a first value as long as the entry associated transaction is not used (The. not spent) to carry out a transaction and fixed at a second value when said transaction input is used (ie spent) during a transaction. Thus, each transaction entry stored in the processing device whose associated parameter is set to the second value is blocked so that it cannot be used by the virtual wallet to carry out a new transaction.

The invention also relates to a corresponding processing device, as well as a corresponding computer program.

Other aspects and advantages of the present invention will emerge from the exemplary embodiments described below with reference to the drawings mentioned above.

Unless otherwise indicated, the elements common or analogous to several figures bear the same reference signs and have identical or analogous characteristics, so that these common elements are generally not described again for the sake of simplicity.

FIG. 1 schematically represents an environment E comprising a processing device DV1, a terminal DV2, a remote server SV and a network 20, in accordance with a particular embodiment of the invention.

In this example, the processing device DV1 is a smart card although other types of processing device are possible. As a variant, the processing device DV1 can be any device capable of carrying out the processing method described below, such as for example a multifunction mobile (or "smartphone"), a computer, a tablet etc.

In a particular example, the chip card DV1 is an EMV card, such as a payment card for example.

In the embodiment described here, a user UI uses his chip card DV1 to carry out transactions with third parties in the bitcoin cryptographic currency well known to those skilled in the art. It is assumed here that the user UI realizes for example a transaction with a third-party user U2, representing for example a merchant. To do this, the smart card DV1 cooperates with the terminal (or reader) DV2 of the user U2 in order to exchange data necessary for the execution of the transaction.

More specifically, the smart card DV1 comprises in this example external contacts 1 configured to cooperate with the terminal DV2, a processor 2, a virtual wallet 4 implemented by the processor 2, a volatile rewritable memory (RAM) 6 and a non-volatile rewritable memory Ml (of the Flash type for example).

The non-volatile memory M1 constitutes in this example a recording medium (or information medium) conforming to a particular embodiment, readable by the smart card DV1, and on which a computer program PG1 conforming is recorded. to a particular embodiment. This computer program PG1 includes instructions for the execution of the steps of a control method according to a particular embodiment. The steps of this process are described later, in particular embodiments of the invention.

As described below, the processor 2 is controlled by the program PG1 to implement the virtual wallet 4 intended to carry out a processing method according to the invention. This virtual wallet 4 can in particular make it possible to create an account of the user UI and to carry out transactions in bitcoin cryptographic currency with an account of the third-party user U2. During a payment transaction for example, the account of the virtual wallet 4 is debited with a certain amount in bitcoin to credit the account of the third party U2. It is assumed here that the environment E is an environment conforming to or compatible with the Bitcoin system, although other examples are possible.

In a particular example, the smart card DV1 complies with standard ISO 7816. In this case, the external contacts 1 have characteristics conforming to this standard. It is understood, however, that other embodiments are possible without the use of such external contacts. The DV1 chip card can for example be configured to cooperate with the DV2 terminal in contactless mode via an RF antenna (not shown) integrated in the DV1 card.

In the example considered here, the rewritable non-volatile memory M1 is configured to store a pair of cryptographic keys associated with the account of the user Ul, this pair comprising a public key PKI and a complementary private key SKI. The virtual wallet 4 can use the private key SKI of the account of the user Ul to sign transaction data before sending to the third party recipient U2.

In an implementation mode, the PKI / SKI key pair is not stored in the memory Ml but calculated on the fly by the virtual wallet 4, from a datum (called “seed”, or “ seed "in English) which is stored in the memory Ml.

Note that the virtual wallet 4 can have several user accounts. In this case, the transaction data generated for each transaction is signed using the private key of each account used. As indicated above, each pair of dice can be stored in advance in the memory M1 or calculated on the fly from a seed stored in the memory Ml.

The memory M1 is also configured to store one or more transaction entries (or entries), each of them corresponding to an old transaction of which the virtual wallet 4 has been the beneficiary (the recipient) in the past. These transaction entries Ή constitute the value available in bitcoin owned by the user Ul. These transaction entries ΊΊ can be received by the virtual wallet 4 from a third party entity, the server SV for example, which can correspond to an organization issuing the card DV1, to a service provider or the like.

From the transaction inputs TI stored in the memory M1, the virtual wallet 4 can generate transaction outputs TO defining bitcoin transfer transactions from the account of the user Ul of the wallet 4 to at least one account of the third party recipient U2 and its DV2 terminal. These transaction outputs TO can be transmitted by the smart card DV1 to the terminal DV2 during a payment transaction.

As shown in FIG. 1, it is assumed here that the smart card DV1 stores in its memory M1 transaction inputs TI1, ΊΊ2 and TI3 (collectively noted TI). Each transaction entry TI is made up of a data group characterizing an old transaction for which the user U1 has benefited. In this example, the transaction entries TI comprise an identifier of a past transaction of which the user Ul has been the beneficiary, an address of the account of the user U1 (equal to or comprising the public key PKI) and an amount in bitcoin of the transaction.

Each transaction output TO generated by the smart card DV1, and more precisely by the virtual wallet 4 comprises for example an amount of the transaction and the payment of the account of the account of the third-party user who is the beneficiary of the transaction. The wallet 4 is configured to generate transaction data which may include one or more transaction outputs TO and possibly other associated data (for example, information relating to one or more transaction inputs Ή used of which at least one TI is associated with the PKI public key, a transaction identifier, etc.). These transaction data can be signed by the virtual wallet 4 from the private key SKI associated with the account of the user UI which is used to carry out the transactions.

In a particular example, a transaction can be carried out from transaction input Ή associated with different user accounts. In this case, the transaction data is signed with each of the private keys associated with these accounts.

In the example described here, the memory M1 is also configured to store at least one parameter SP, called the status parameter, each parameter SP being representative of a status of an associated transaction entry Ή stored in the memory Ml. In this example, the memory M1 includes a respective parameter SP1-SP3 for each of the transaction inputs Ή1-ΤΙ3.

As explained below, the parameters SP are initially set to a first value VI as long as the associated transaction inputs Ή are not used by the virtual wallet 4 during the processing of a transaction to generate a transaction output TO .

The status parameters SP allow the virtual wallet 4 to monitor and control the status of each transaction transaction TI, in order to determine in particular whether these have already been spent during a transaction with a third party or, on the contrary , if they are still available (not spent) for use in a transaction.

As shown in FIG. 1, the smart card DV1 is configured to communicate with the remote server SV in particular in order to make regular updates, as described later. In the present case where the processing device DV1 is a smart card, it can communicate with the server SV via any appropriate equipment, such as the terminal DV2 (during the processing of a transaction, for example). As a variant, the processing device DV1 comprises communication means for communicating directly with the server SV.

The server SV, executing a computer program PG2, can in particular transmit to the smart card DV1 at least one of update data DM and an associated time indicator TS. The update data DM informs the smart card DV1 of the transaction inputs TI of which the user Ul, that is to say the account of the user Ul, is the owner, at a given instant which is represented by the TS time indicator.

Furthermore, the terminal DV2 includes in memory a computer program PG3 which it can execute to carry out a bitcoin transaction.

As already explained, each payment transaction carried out from the user U1 in favor of the user U2 requires prior validation by verification terminals, called miners, arranged here in a network of miners 20. The terminal DV2 is configured to transmit to the network 20 each transaction output TO received from the chip card DV1 so that minors can check the validity of the transaction. Miners (verification terminals) validate the TO transaction outputs they receive and progressively group the transactions before recording them as blocks in the block chain of the Bitcoin system. This process is called in this document validation and registration process.

During this process, the miners network 20 checks in particular the validity of the signature associated with each transaction entry Ή used to generate the transaction output TO received, from the public key PKI of the user Ul. As indicated thereafter, it is assumed in the following embodiments that all of the transaction inputs 1Ί1 to ΤΊ3 are associated with the same account of the user Ul (although other examples are possible in which these inputs TI1-TI3 are associated at least two respective accounts), and that at least one transaction output TO can be generated from these inputs ΊΙ1 to TI3. In known manner, the entry by the network of miners 20 in the block chain of a new transaction output TO has the effect of prohibiting any subsequent use of the transaction input (s) TI from which the new transaction has has been carried out, which amounts to debiting the user Ul and crediting the user U2 for the amount defined in the transaction output TO.

As already explained, the verifications carried out by the verification terminals in the network 20 to validate the transactions (that is to say the transaction data representing each transaction) require a processing time which can be relatively long and which can pose problem especially for users Ul and U2.

In addition, there is a risk for the beneficiary U2 that the user Ul attempts to use the same transaction entries TI, in a limited time interval, to carry out several separate transactions, for example with other third-party users (double payment ).

It should be noted that the environment E, and more particularly the processing device DV1, represented in FIG. 1 constitutes only one example of embodiment, other implementations being possible within the framework of the invention. Those skilled in the art understand in particular that certain elements of the processing device DV1 shown in FIG. 1 are described here only to facilitate understanding of the invention, these elements not being necessary for implementing the invention.

Furthermore, in the example envisaged here, the processor 2 controlled by the computer program PG1 implements a certain number of modules represented in FIG. 2, namely: a storage module MD2, a processing module MD4, a MD6 management module and, optionally, an MDS synchronization module.

The storage module MD2 is configured to store in the memory M1 at least one transaction entry TI defining a transaction of which the virtual wallet 4 is the beneficiary. As indicated, it is assumed here that the storage module MD2 has initially stored the transaction inputs TI1, TI2 and TI3 in the memory M1.

The MD4 processing module is configured to process transactions. More particularly, the processing module MD4 is configured to process a transaction in progress by generating, from at least one of the transaction inputs TI1-TI3, a transaction output TO defining the transaction in progress between the card to DV1 chip and the DV2 third-party terminal.

The management module MD6 is configured to keep in memory at least one parameter SP representative of a status of an associated transaction entry Ή, this parameter SP being initially set at a first value VI as long as said associated transaction entry TI n is not used by the processing module MD4 during the processing of a transaction to generate a transaction output TO. The MD6 management module is further configured, on detection that said: associated transaction input is used by the wallet 4 to generate a transaction output TO, to modify the status of said associated transaction input Ή by assigning to said parameter SP a second value V2 different from the first value VI to indicate that said associated transaction entry TL is spent (that is to say "consumed" or "used").

The processing module MD4 is further configured to use a transaction input Ή in the generation of a transaction output TO only if said associated parameter SP is set to the first value VI indicating that said associated transaction input TI is not not spent (ie "not consumed" or "not used"). To do this, the processing module MD4 is configured to check the parameter SP of at least one transaction input to determine whether it can be used to generate a transaction output TO.

Furthermore, the MDS synchronization module is configured to synchronize, if necessary, the virtual wallet 4 of the device DV1 with a remote server, such as the server SV shown in FIG. 1 for example. During synchronization with the server SV, the synchronization module MDS is configured to receive update data DM and possibly a time indicator TS, as explained later. According to a particular example, the synchronization module MDS is configured to receive update data DM from the server DV in order to determine whether its transaction entries TI1-TI3 are still valid.

According to a particular example, the MDS synchronization module is configured to perform synchronization with a remote server such as the SV server. During such synchronization, the processing device (and more particularly the synchronization module MD8) receives update data MD. The MD6 management module can be configured to detect, from the DM update data received, that a transaction entry Ή (TI1 for example) is no longer valid. The storage module MD2 can also be configured to delete from the memory M1 the transaction entry (s) Ή detected as invalid by the management module MD6.

The operation and configuration of the modules MD2-MD8 of the processing device DV1 will appear more precisely in the embodiments described below. Note also that the MD2-MD8 modules as shown in Figure 2 are only one example of implementation of the invention.

A particular embodiment of the invention is now described with reference to Figure 3. More specifically, the processing device DV1 shown in Figures 1-2 executes the computer program PG1 to implement a method of controlling the virtual wallet 4, according to a particular embodiment.

It is assumed that the smart card DV1 is regularly synchronized with the remote server SV to update the transaction entries Ή of which the user Ul, that is to say the account of the user Ul, is the owner at an instant current according to the blockchain. In this example, the smart card DV1 receives during such synchronization the transaction inputs entrées1-ΊΠ3 which it records (step S2) in its memory M1. Note that other ways are possible to allow the smart card DV1 to obtain the transaction inputs Ή1-Ή3.

The TI transaction entries include for example an identifier of a past transaction for which the user Ul was the beneficiary, an address of the user Ul (equal to or including the public key PKI) and an amount in bitcoin of this old transaction in favor of user Ul.

During an initialization step S4, the smart card DV1 generates and stores in the memory M1, in association with each transaction input TI1-TI3, a respective status parameter SP. The smart card DV1 initializes (S4) each of these parameters SP by assigning them a first predefined value VI (VI = 0 for example). A parameter SP set to the value VI indicates that the associated transaction entry Ή has not been spent, that is to say that it has not yet been used by the smart card DV1 to generate a TO transaction exit.

The smart card DV1 thus stores in memory the parameters SP, these parameters being fixed at the first value VI as long as the associated transaction entry is not used by the virtual wallet 4 during the processing of a transaction for generate a TO transaction output.

In this example, the smart card DV1 then performs a processing S6 of a transaction, denoted TRI, with a third-party terminal, namely the terminal DV2 in this case. It is assumed here that this is a payment transaction of a given amount in bitcoin carried out by the user Ul as a debtor (or payer), intended for the user U2 as a creditor (or recipient). During this processing S6, the smart card DV1 performs the steps S8, S10 and S12 as described below.

During a verification step SS, the smart card DV1 identifies at least one transaction entry TI stored in the memory M1, which is indicated as unused, that is to say whose status parameter SP is fixed at the initial value VI. In the example considered here, the transaction entries TU, TI2 and TI3 are detected as unspent and therefore available (SP = VI) to make a payment.

During a generation step S10, the smart card DV1 generates, from at least one of the unspent transaction inputs TI identified in S8, a transaction output TO defining the transaction in progress between the card chip DV1 and the terminal

DV2. This transaction output TO includes, for example, an amount of the transaction in progress and the public key of the third-party user who is the beneficiary of this transaction.

Thus, the transaction inputs TL stored in the memory M1 are used in the generation (S10) of a transaction output TO only if the corresponding parameter SP is set to the first value VI indicating that said associated transaction input is not not spent.

During a modification step S12, on detection that a transaction input Ή is used in S10 to generate a transaction output TO, the smart card DV1 modifies the status of this transaction input Tl by assigning to its parameter SP associated with a second predefined value V2 (V2 = -1 for example), different from the first value VI, to indicate that the transaction input is spent and is therefore no longer available for carrying out a new transaction. In other words, the DV1 smart card blocks the use of the transaction entries Ή which have been spent so that they cannot be the subject of a double payment.

The validation and registration process of the current TRI transaction is then carried out by the network of miners 20 in a conventional manner as already mentioned above and is therefore not described in detail in this document for the sake of simplicity. Once the TRI transaction in progress is validated, it is recorded by the network 20 in the block chain (register) so as to be viewable in particular by the server SV.

If the smart card DV1 detects (S14) that a new payment transaction is initiated, the method performs a new iteration of the processing S6, comprising the steps S8-S10, as already described above. During this new iteration of S6, the smart card DV1 detects in particular in SB that the transaction input (s) TI whose parameter SP is now set to the value V2 are blocked and cannot therefore be used in S10 for generate a new TO transaction output.

The invention advantageously allows a processing device, such as the smart card DV1, to control the status of the transaction entries stored in its memory so as to determine the transaction entries which have been spent and which are still available for complete a payment transaction. By assigning values VI or V2 to the status parameters of each transaction entry, the processing device DV1 can distinguish spent transaction entries TI from those which are not spent.

The invention further allows the processing device DV1 to block all the transaction inputs TI which have been spent during a transaction but which are still present in the memory M1. In this way, the processing device DV1 cannot spend money several times corresponding to the same transaction entry ΊΊ, in particular in the period necessary for the completion of the validation and registration process by the network of minors. Once a transaction has been entered in the block chain, synchronization of the processing device DV1 with the server SV can cause the deletion of the transaction entry (s) Ή spent in the memory M1,

The invention thus makes it possible to combat the phenomenon of double-payment already described previously and thus to secure the payment transactions.

Note, however, as indicated above, that if technical difficulties arise during the validation and registration process of a transaction in progress, in particular at the DV2 terminal or the miners' network 20 (Figure 1), there is a risk that the registration of the TO transaction exit is delayed, or even that it never takes place. In this case, a problem may arise in that a transaction entry TI can be considered spent from the point of view of the processing device DV1 when it has never been recorded, as a transaction spent (or validated). ), in the blockchain. This inconsistency means that, although the payment has not taken place, the transaction entry l'entrée concerned can no longer be used by the processing device DV1. The invention proposes to solve these additional problems as described below.

A particular embodiment of the invention is now described with reference to Figure 4. More specifically, the processing device DV1 shown in Figures 1-2 executes the computer program PG1 to implement a method of controlling the virtual wallet 4, according to a particular embodiment.

As indicated previously, the smart card DV1 can be synchronized regularly with the remote server SV to update the transaction entries TI of which the user Ul, that is to say the account of the user Ul, is the owner according to blockchain. Thus, during such synchronization, the smart card DV1 receives (step S20) update data DM and a time indicator TS. These update data DM specify the valid transaction entries Ή, that is to say available to the account of the user Ul, at a particular instant tl represented by the time indicator TS. These update data DM are for example representative of the state of the block chain at time tl, and therefore reflect the transaction entries TI which are valid at this time. The time indicator TS comprises for example the date and / or the time of the instant tl. Synchronization S20 can be carried out in a secure manner, for example by using a secure channel between the server SV and the smart card DV1, following a mutual authentication protocol. In one implementation mode, the time indicator TS is certified, for example by cryptographic signature of said indicator using a private key associated with a public key known to the processing device DV1.

In the example considered here, the processing according to steps S22-S34 described below is carried out for each of the transaction inputs Ή1-ΊΊ3 present in the memory M1 of the smart card DV1. It is assumed here that the smart card DV1 processes the transaction input TU during a first iteration of steps S22-S34.

During a verification step S22, the smart card DV1 verifies, from the update data DM received, that the transaction entry TU stored in its memory M1 is valid. The update data DM in particular allows the smart card DV1 to determine whether a previously completed payment transaction has been validated and recorded in the block chain.

If the transaction entry TU is determined (S22) to be invalid, the smart card DV1 deletes (S24) the transaction entry TU from its memory M1. A transaction entry TI is in particular designated as invalid by the update data DM if this entry has been previously used by the user U1 to make a payment which has been validated and entered in the block chain of the Bitcoin system. According to a particular implementation mode, the smart card DV1 also removes the indicator SP1 associated with the deleted transaction entry TU.

Once the deletion step S24 has been carried out, the method can end or continue by carrying out a new iteration of the steps S22-S34, for example to process the other transaction inputs TI2 and TI3.

On the other hand, if the transaction entry TU is detected in S22 as valid, the method continues at the detection step S26.

During the detection step S26, the smart card DV1 determines whether the parameter SP1 corresponding to the transaction entry TU detected as valid from the point of view of the server SV has a value different from the predefined values VI and V2 already mentioned above .

As a reminder, a status parameter SP fixed at the predefined value VI or V2 indicates that, from the point of view of the smart card DV1, the associated transaction entry TI is respectively available (not spent) or used (spent). The transaction input TU is considered spent, and therefore blocked, from the point of view of the smart card DV1 if the latter has previously used this transaction input TI1 during a transaction to generate an output transaction TO. These values VI and V2 are known to the smart card DV1. In a particular example, VI = 0 and V2 = -1, other assignments of values being possible.

If the parameter SP1 of the transaction input TI1 is set to a value different from VI and V2 (step S26), the method continues in step S32, otherwise the method continues in step 530.

In S30, if the parameter SP1 is detected as having the value V2, the smart card DV1 detects that the associated transaction input TI1 was previously used to generate a transaction output TO and, consequently, modifies the status of the transaction input TIl by assigning to the corresponding SRI parameter a third value V3, different from the values VI and V2, this value V3 being representative of the instant tl defined by the time indicator TS received in S20. Note that, in this case, the smart card DV1 considers that the transaction entry TIl in question is spent whereas, according to the update data DM, this transaction entry TIl is always valid (because its expenditure n 'is not included in the blockchain). This situation occurs in particular when a transaction recently carried out by the smart card DV1 has not yet been validated by the network 20 and entered in the block chain.

In a particular example, the value V3 is equal to the time indicator TS or determined from the time indicator TS. Once step S30 has been completed, the method can end or continue by carrying out a new iteration of steps S22-S34, for example to process the other transaction inputs ΤΊ2 andTI3.

Still at step S30, if the parameter of the transaction input TI1 is detected as having the value VI, no particular action is taken and the method can initiate a new iteration of steps S22-S34, for example to process the other transaction entries TI2 and 1Ί3. The fact that a transaction entry Ή considered valid from the blockchain point of view has its parameter SP at the value VI is consistent and does not call for any particular action.

Furthermore, upon detection in S26 that the parameter SRI of the transaction input TH (which is valid) has a value V4 different from the predefined values VI and V2, the smart card DV1 deduces therefrom that this value V4 is representative of an instant t2, prior to tl, corresponding to a previous update. This value V4 has been assigned by the smart card DV1 to the parameter SP1 in question during a previous iteration of step S30 (previous synchronization).

The smart card DV1 then calculates (S32) the time interval INT which has elapsed between the instant t2 and the instant tl, from the time indicator TS representative of the instant tl and the value V4 representative of the previous instant t2.

SU is detected in S32 that this time interval (tl - t2) reaches a predetermined limit duration DL, then the method continues at step S34. Otherwise, the method can end or possibly resume with a new iteration of steps S22-S34, for example to process the other transaction inputs ΊΊ2 and Π3.

In a particular example, the smart card DV1 determines in S32 the predetermined limited duration DL from a parameter, called the duration parameter, included in the transaction input TI1 or in the transaction output TO which was generated at from this TI1 transaction entry.

In the modification step S34, the smart card DV1 modifies the status of the transaction entry TI1 by assigning to the associated parameter SP1 the initial value VI indicating that the transaction entry in question is not spent.

In this way, the transaction input TI1, the SRI parameter of which has been reset to the value VI, is released and can therefore again be used by the smart card DV1 during a subsequent transaction to generate (step S10, FIG. 3). ) a transaction exit.

As shown in FIG. 4, the method can end or continue by carrying out a new iteration of steps S22-S34, for example to process the other transaction inputs TI2 and ΊΊ3.

An exemplary embodiment is now described with reference to FIG. 5. In this example, it is assumed that the smart card DV1, represented in FIGS. 1-2, includes in its memory M1 the transaction inputs ΤΊ1-ΤΊ3 defining transactions of which the user UI was the beneficiary, in association with the status parameters SP1-SP3 indicating whether these respective transaction entries TI1-TI3 have been spent by the user UI or not. In this example, it is assumed that the transaction entry 111 has already been spent by the smart card DV1 during a past payment transaction, denoted TRI (FIG. 3), with the terminal DV2 and that the transaction entries TI2 and TI3 have not yet been spent by the smart card DV1, We therefore consider in this example that the memory Ml is in the following state:

• SP1 = V2 = -1 indicating that the input TI1 is spent and therefore blocked;

• SP2 = VI = 0 and SP3 = VI = Ο indicating that the respective inputs ΊΊ2 and TI3 have not yet been spent and can be used by the smart card

DV1.

During a first synchronization S20a, the smart card DV1 receives from the server SV first update data DM1 and a first time indicator TS1.

This update data DM1 specifies the transaction entries Ή of the user lll which are valid according to the block chain of the Bitcoin system at a particular instant t3 represented by the time indicator TS1. The time indicator TS1 10 comprises for example the date and / or the time corresponding to (Instant t3.

It is assumed that this is the first synchronization with the remote server SV since the use by the smart card DV1 of the transaction input ΊΊ1 (step S10, FIG. 3) during the past transaction TRI to generate a TO input output. In this example, the update data DM1 indicate that the transaction entry Π1 is still valid at time t3 because its expenditure is not yet recorded in the block chain. As already explained, a more or less long processing time is necessary between the moment of the TRI transaction and the recording of this transaction in the block chain. This registration of the TRI transaction may in particular delay, or even never occur, if technical difficulties arise at the level of the terminal DV2 or 20 of the network of miners 2 during the verification and registration process in the block chain.

During a step S30a (identical to step S30 of FIG. 4), the smart card DV1 assigns, to the parameter SRI of the first transaction entry ΤΊ1 indicated as spent (SP1 = V2), a third value V3 predefined representative of the first instant 25 t3, this value V3 being different from the values VI = 0 and V2 = -1 previously mentioned. In this example, the value V3 is equal to the time indicator TS1 received in S20a during the first synchronization.

By assigning this value V3 to the status parameter SRI, it is possible to specify in the memory M1 of the smart card DV1 a time t3 from which the transaction entry TI1 has the status "spent" and, as explained below. -afterwards, check later whether the time necessary for this transaction entry ΤΊ1 to be written to the block chain is normal or abnormally long.

It is assumed that the smart card DV1 subsequently performs a second synchronization S20b with the server SV. During this second synchronization

S20b, the smart card DV1 receives from the server SV second update data DM2 and a second time indicator TS2.

This update data DM2 specifies the transaction inputs Ή of the user U1 which are valid according to the block chain of the Bitcoin system at a particular time t4 represented by the time indicator TS2. In this example, time t4 is after time t3. The time indicator TS2 comprises for example the date and / or the time corresponding to time t4.

During a determination step S22b, the smart card DV1 determines for each transaction entry ΤΙ1-ΊΊ3 stored in the memory M1, if the latter is valid from the point of view of the block chain, in the same way as step S22 shown in FIG. 4. In the negative (invalid entry), the smart card DV1 deletes the transaction entry Ή concerned from its memory M1 in step S30b in an identical manner to step S24 shown in FIG. 4 .

By way of example, we are subsequently interested in the processing of the input TH which was previously spent by the user U1 during the transaction TRI. It is assumed in this example that any technical problem affecting the terminal DV2 or the network of miners 20 has disrupted the validation and registration process of the TRI transaction previously carried out by the smart card DV1 with the terminal DV2.

Also, at time t4, the transaction output TO generated from the transaction input TU has still not been written to the block chain. Consequently, in step S22b, the smart card DV1 detects that the input TI1 is still valid and the method proceeds to step S26b.

During step S26b, the smart card DV1 detects that the status parameter SP1 of the transaction entry TU has a value V3 distinct from the predefined values VI and V2, as already described with reference to step S26 shown in FIG. 4. The smart card DV1 deduces therefrom that the value V3 constitutes a time indication corresponding to a previous synchronization and the method proceeds to a step S32b identical to the step S32 shown in FIG. 4.

Upon detection (S22b, S26b) that the transaction input TI1 is still valid and that the parameter SP1 has a third value V3 different from the predefined values VI and V2, the smart card DV1 determines (step S32b) then, from ia third value V3 and of the second time indicator TS2, if the time interval INT between the first time t3 and the second time t4 reaches a predetermined time limit DL. If not, the process ends (step S40). Otherwise (t4 - t3> DL), the method continues at step S34b.

In a particular example, the smart card DV1 determines in S32b the predetermined limited duration DL from a parameter, called the duration parameter, included in the transaction input TI1 or in the transaction output TO which was previously generated from this TU transaction entry.

During step S34b (identical to step S34 shown in FIG. 4), the smart card DV1 modifies the status of the transaction entry TU by assigning to the associated SRI parameter the initial value VI indicating that this entry of TU transaction is not spent.

Note that the order in which the steps of the process of the invention are carried out, in particular in FIGS. 3, 4 and 5, is presented here only by way of example and is susceptible of adaptations in the context of the invention. In FIG. 5, for example, step S22b can optionally be carried out after step S26b.

As indicated above, if technical difficulties disrupt the validation and registration process of a transaction in progress, particularly at the level of the DV2 terminal or the miners' network 20 (Figure 1), there is a risk that the registration of a TO transaction output is delayed, or even never takes place, which is problematic insofar as one or more transaction inputs Π can be blocked in the DV1 smart card although the payment did not happen.

The invention advantageously allows the DV1 chip card to check whether the validation process and the blockchain process of a TO transaction output takes too long or not and, in the case of abnormally processing long, to consider that the payment has not taken place and consequently to unlock in the smart card DV1 the transaction input (s) TI which were used to generate the transaction output TO considered. Once reactivated, the TI transaction entries can be used again by the virtual wallet during a new payment transaction.

The invention thus makes it possible to prevent TI transaction entries from being blocked indefinitely in the event that a particular problem disturbs the validation and registration process in the block chain.

Note that, in the examples shown in FIGS. 4 and 5, the smart card DV1 performs synchronizations with a remote server SV in order to update its transaction inputs TI. To do this, the smart card DV1 receives from the server SV update data DM and a time indicator TS, as already explained previously. Note however that the DV1 smart card can, in general, perform synchronization with a remote server (such as the SV server) so as to receive DM update data without TS time indicator or, conversely, to receive a TS time indicator without DM update data.

According to a particular example, the smart card DV1 receives update data DM from the server SV in order to determine whether its transaction entries TI1-TI3 are still valid. To do this, the smart card DV1 performs, for example, synchronization with the server SV. During such synchronization, the smart card DV1 receives update data MD. The smart card DV1 detects, from the DM update data received, that at least one transaction entry TI (TU for example) stored in its memory Ml is no longer valid and deletes from its memory Ml each entry transaction transaction detected as invalid.

Furthermore, to secure a payment transaction, it is preferable that the terminal DV2 (FIG. 1) authenticate the smart card DV1 to determine that it is a trusted third party. Upon detection that the user UI is a trusted third party and therefore cannot make a double payment, the DV2 terminal accepts a transaction in progress.

According to a particular example, during the processing of a transaction in progress, the smart card DV1 authenticates with the terminal DV2 by sending a response determined from challenge data previously received from the terminal DV2. This response includes for example a signature of a message comprising the challenge data.

A particular exemplary embodiment is described with reference to FIG. 6. In this example, during a transaction TR2 during processing, the terminal DV2 generates (S54) a challenge data item CH1. This challenge data CH1 is for example in the form of a series of symbols, of alphanumeric type or others. This challenge data CH1 is for example randomly generated by the terminal DV2.

The terminal DV2 sends (S56) this challenge data CH1 to the smart card DV1. Once the challenge data CH1 has been received (S56), the smart card DV1 calculates (S58) a result HH1 of a hash function F, from transaction data representative of the transaction TR.2 in progress. This transaction data can be a transaction output TO generated by the smart card DV1 as described previously (S10, FIG. 3).

The smart card DV1 then determines (S60) the signature SI of a message comprising the result HH1 and the challenge data CH1, with possibly other information. This signature is carried out using the secret key SKI of the user U1.

The smart card DV1 sends the signature SI and the result HH1 to the terminal DV2 during a step S62.

According to another embodiment, the signature SI is determined in S60 using a secret key other than the secret key SKI associated with the crypto-currency account of the user Ul. (Eg the secret key associated with a EMV payment application).

The terminal DV2 receives (S62) then verifies (S64) the signature SI from the public PKI of the user Ul. If this verification S64 has passed successfully, the terminal DV2 stores (S66) the result HH1 in its memory and the process continues.

A verification phase S68 of a personal code (PIN) of the user Ul is optionally carried out between the smart card DV1 and the terminal DV2.

The smart card DV1 then sends (S70) the transaction data representative of the transaction TR2 in progress to the terminal DV2, possibly on request from the terminal DV2. This transaction data includes the transaction output TO corresponding to the transaction TR2 and, possibly other associated data as already explained. From this transaction data, the terminal DV2 calculates (S72) its own result HH2 of the hash function F and then compares the results HH1 and HH2 so that the authentication of the smart card DV1 and of the transaction TR2 is passed successfully only if HH1 = HH2.

A person skilled in the art will understand that the embodiments and variants described above only constitute nonlimiting examples of implementation of the invention. In particular, a person skilled in the art can envisage any adaptation or combination of the embodiments and variants described above in order to meet a very specific need.

It will be noted, for example, that in the embodiments described above, there is a pair of PKI / SKI keys associated with an account of the user Ul. Nevertheless, the invention also applies to virtual wallets with multiple key pairs associated with multiple user accounts. In this case, the virtual wallet can sign its transactions using several private keys.

Claims (15)

1, Method for controlling a virtual wallet (4), implemented in a processing device (DV1) capable of carrying out transactions in a cryptographic currency, the processing device storing at least one memory (Ml) a transaction entry (TI) defining a transaction for which the virtual wallet has been the beneficiary, the method comprising: - processing of a transaction in progress (TRI), comprising a generation (S10), from at least one transaction input (TI), of a transaction output (TO) defining the transaction in progress between the device processing and a third-party terminal (DV2); the method being characterized in that it comprises: conservation (S4) in memory of at least one parameter (SP) representative of a status of an associated transaction entry stored in said memory, the parameter being initially set at a first value (VI) as long as said entry associated transaction is not used by the virtual wallet when processing a transaction to generate a transaction output (TO); - upon detection that said associated transaction input is used by the wallet to generate a transaction output (TO), modification (S12) of the status of said associated transaction input (TI) by assigning to said parameter a second different value (V2) the first value to indicate that said associated transaction entry is spent; wherein, said processing of the transaction in progress comprises a verification (S8) of the parameter of an associated transaction entry, the latter being used in generating the transaction output only if said parameter is set to the first value indicating that said associated transaction entry is not spent. 2. Method according to claim 1, comprising: - first synchronization (S20a) with a remote server (SV), comprising a reception of a first time indicator (TS1) representative of a first instant (t3) associated with the first synchronization; and - Assignment (S30a), to the parameter (SP1) of at least a first transaction entry (ΊΓΙ1) indicated as spent, of a third value (V3) representative of the first instant and different from the first and second values. 3. Method according to claim 2, comprising: - second synchronization (S20b), subsequent to the first synchronization, with a remote server (SV), comprising a reception of a second time indicator (TS2) representative of a second instant (M) associated with the second synchronization; * - upon detection (S26b) that the parameter (SP1) of the first transaction input (ΊΙ1) has a third value (V3) different from the first and second values (VI, V2), determination (S32b) from the third value and of the second time indicator, of whether the time interval (INT) between the first instant (13) and the second instant (t4) reaches a predetermined time limit (DL); and - in the affirmative, modification (S34b) of the status of said first transaction entry by assigning to the associated parameter (SP1) said first value (VI) indicating that said first transaction entry (ΊΠ1) is not spent. The method of claim 3, wherein the predetermined time limit (DL) is determined from a parameter included in the first transaction entry or in a transaction output generated from said first transaction entry. 5. Method according to any one of claims 1 to 4, comprising: - synchronization with a remote server, including reception of update data; and - Upon detection, from the update data, that a transaction entry is no longer valid, the processing device deletes said invalid transaction entry from the memory. 6. Method according to any one of claims 1 to 5, wherein the cryptographic currency is bitcoin. 7. Method according to any one of claims 1 to 6, in which, during the processing of the transaction in progress, the processing device authenticates with the third-party terminal by sending (S60) a response determined from challenge data (CH1) previously received (S56) from said third-party terminal. 8. The method of claim 7, wherein the response comprises a signature 5 (SI) of a message comprising the challenge data (CH1). 9. computer program (PG1) comprising instructions for the execution of the steps of a processing method according to any one of claims 1 to 8 when said program is executed by a computer. 10. Recording medium readable by a computer on which a computer program (PG1) is recorded comprising instructions for the execution of the steps of a processing method according to any one of claims 1 to 8, 15 11. Processing device (DV1) configured to control a virtual wallet (4) intended to carry out transactions in a cryptographic currency, comprising: - a storage module (MD2) configured to store at least one transaction entry (TI) defining a transaction of which the virtual wallet has been the beneficiary; 20 - a processing module (MD4) of a transaction in progress (TRI), configured to generate, from at least one transaction input, a transaction output (TO) defining the transaction in progress between the device processing and a third-party terminal; the treatment device being characterized in that it comprises: 25 - a management module (MDS) configured to keep in memory at least one parameter (SP) representative of a status of an associated transaction entry (ΤΊ), the parameter being initially set at a first value (VI) both that said associated transaction input is not used by the processing module during the processing of a transaction to generate a transaction output, The management module (MD6) being configured, on detection that said associated transaction entry is used by the wallet to generate a transaction output, to modify the status of said associated transaction entry by assigning to said parameter (SP) a second value (V2) different from the first value (VI) to indicate that said associated transaction entry is spent; wherein, said processing module (MD4) is configured to check the parameter (SP) of an associated transaction input and to use the latter in generating the transaction output only if said parameter is set to the first value ( VI) indicating that said associated transaction entry is not spent. 12. Device according to claim 11, comprising a synchronization module (MDS) configured to perform a first synchronization with a remote server, during which the processing device receives a first time indicator representative of a first instant associated with the first synchronization; the management module (MD6) being configured to assign, to the parameter of at least one first transaction entry indicated as spent, a third value representative of the first instant and different from the first and second values. 13. Device according to claim 12, in which the synchronization module (MD8) is configured to perform, after the first synchronization, a second synchronization with a remote server (SV), during which the processing device receives a second time indicator representative of a second instant associated with the second synchronization; the management module (MD6) being configured to: - upon detection that the parameter of the first transaction entry has a third value different from the first and second values, determine from the third value and the second time indicator, whether the time interval between the first instant and the second instant reaches a predetermined time limit; and - if so, modify the status of said first transaction entry by assigning to the associated parameter said first value indicating that said first transaction entry is not spent. 14. Device according to claim 13, in which the synchronization module (MD8) determines the predetermined time limit on the basis of a parameter included in the first transaction input or in a transaction output generated from said first transaction input. . 15. Device according to any one of claims 11 to 14, comprising a synchronization module configured to perform synchronization with a remote server, during which the processing device receives update data; - in which the management module is configured to detect, from the data 5 update, that a transaction entry is no longer valid; and - in which the storage module is configured to delete said invalid transaction entry from the memory.