Method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet

Abstract

The present invention relates to a method for implementing a transaction relating to the transfer of digital currency from a first to a second electronic wallet, characterized in that it comprises implementing steps of: (a) establishing an ad-hoc communication channel between first and second terminals (2a, 2b) implementing the electronic wallets, each associated with an expiry date and with a transaction log; (b) if said expiry date is not exceeded, carrying out said transaction by way of the terminals (2a, 2b) via said ad-hoc communication channel, and updating said electronic wallets and the associated transaction logs; (c) upon the first and / or second terminal (2a, 2b) connecting to a gateway (1) via a wide area network (10): a. transferring said transaction log; b. implementing at least one check on the consistency of said transaction log by way of the gateway (1); c. if at least one inconsistency is detected, triggering asynchronous exception handling.

Description

[0001] Description

[0002] Title of the invention: Method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet.

[0003] GENERAL TECHNICAL FIELD

[0004] The present invention relates to the field of electronic payment. More specifically, it relates to a method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet.

[0005] STATE OF THE ART

[0006] Central Bank Digital Currency (CBDC) is the digital form of fiat money (called "cash"), i.e., electronic money issued by a central bank.

[0007] A unit of digital currency has the same value as a unit of traditional "paper" currency, since it was issued by a central bank, and can be used anywhere, as long as the point of sale where you want to pay offers this option. The main advantages of a CBDC are that it allows for secure and instant payments, without the risk of theft.

[0008] This type of digital currency has already been deployed in China since April 2021 on an experimental basis, as the digital yuan (e-CNY).

[0009] To use a CBDC, each user can install an electronic wallet ("wallet") on a personal terminal such as a smartphone, credit it for example from his bank account (which is the equivalent of withdrawing money), and an interaction between two terminals (for example via proximity wireless communication) allows a transfer of digital currency units, in the same way as a banknote would pass from one hand to another.

[0010] The challenge is to prevent fraudulent duplication of electronic money, through what is known as "double spending," i.e., the transfer of the same units of electronic money in two transactions. Also, "double crediting," which could occur in the event of a replay of a transaction marked as failed, must be avoided.

[0011] As such, CBDCs generally use a ledger, particularly a distributed one (usually a blockchain), similar to what is done for cryptocurrencies, for example. The implementation of a consensus algorithm guarantees the correct content of the data and effectively ensures the absence of fraud.

[0012] However, this requires a permanent connection of user terminals to the internet. However, for digital currency to be truly equivalent to fiat currency, it must be possible to transfer currency under all circumstances without the need for a network connection and in a completely anonymous manner.

[0013] The invention improves the situation.

[0014] PRESENTATION OF THE INVENTION

[0015] The present invention therefore relates, according to a first aspect, to a method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet, characterized in that it comprises the implementation of steps of:

[0016] (a) Establishing an ad-hoc communication channel between a first terminal implementing the first electronic wallet and a second terminal implementing the second electronic wallet, each of the first and second electronic wallets being associated with an expiration date and a transaction log;

[0017] (b) If said expiration date of each of the first and second electronic wallets has not passed, execution of said transaction by the first and second terminals via said ad-hoc communication channel, and updating of said first and second electronic wallets, and of the associated transaction logs;

[0018] (c) When connecting the first terminal and / or the second terminal to a gateway via a wide area network a. Transferring said transaction log associated with the electronic wallet implemented by said first terminal(s) and / or second connected terminal(s); b. Implementing at least one consistency check of said transaction log by the gateway; c. If at least one inconsistency is detected, triggering an asynchronous exception management.

[0019] According to advantageous and non-limiting characteristics:

[0020] Step (b) does not involve any connection to said gateway, and in particular no connection to the network. Said ad-hoc communication channel between the first terminal and the second terminal is a short-range wireless communication channel, in particular NFC, or an optical communication channel.

[0021] The method comprises a step (aO), implemented by the first terminal and / or second terminal during a connection to the gateway via said wide area network, of securely creating the first and / or second electronic wallet.

[0022] Step (aO) is repeated each time step (c) is implemented, so as to renew said first and / or second electronic wallet(s).

[0023] Step (aO) comprises defining a new expiry date for said first and / or second electronic wallet.

[0024] Each of the first and second electronic wallets is further associated with at least one usage limit, step (b) further being implemented only if said usage limits of each of the first and second electronic wallets are not exceeded, step (aO) comprising resetting said limits. Each of the first and second electronic wallets is further associated with a unique electronic wallet identifier, step (b) comprising, for each of the first and second electronic wallets, constructing a triplet (unique electronic wallet identifier / expiration date / local transaction identifier) ​​uniquely identifying said transaction.

[0025] Each of the first and second e-wallets is further associated with a pair of a private key and a public key, wherein step (aO) comprises generating a new key pair, constructing said unique e-wallet identifier from the public key, and obtaining gateway-signed versions of said public key and expiration date.

[0026] Step (b) further comprises, for at least the first electronic wallet, signing with the private key of said first electronic wallet, the triplet uniquely identifying said transaction, an amount of electronic money transferred during the transaction, and a timestamp of the transaction.

[0027] Each terminal comprises a security element, said transaction being executed in step (b) in said security elements.

[0028] Step (c) is implemented for each of the first terminal and the second terminal, substep b. comprising verifying that the same transaction from the point of view of the first terminal and the second terminal is found described in the logs of the first and second electronic wallets.

[0029] Step b. comprises selecting a consistency verification level of said transaction log from among several possible levels, and implementing said selected verification level, including a traceability verification level of the transferred electronic money, in which each unit of electronic money has a unique identifier and the gateway further verifies that the same fragment of a unit of electronic money is present at a given time only in a single electronic wallet. Each terminal stores an electronic certificate representative of the identity of a user of said terminal, step (a) comprising the verification by at least one terminal, and preferably each terminal, of the certificate stored by the other terminal.

[0030] Step (a) comprises the transmission by each terminal to the other terminal, via said ad-hoc communication channel, of the electronic certificate that it stores.

[0031] According to a second aspect, the invention relates to a first terminal implementing a first electronic wallet, characterized in that it is configured to:

[0032] - Establish an ad-hoc communication channel with a second terminal implementing a second electronic wallet, each of the first and second electronic wallets being associated with an expiration date and a transaction log;

[0033] - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said first electronic wallet and the associated transaction log;

[0034] - When connecting the first terminal to a gateway via a wide area network o Transfer said transaction log associated with the first electronic wallet; o Implement at least one consistency check of said transaction log by the gateway; o If at least one inconsistency is detected, triggering an asynchronous exception management.

[0035] According to a third aspect, the invention relates to a second terminal implementing a second electronic wallet, characterized in that it is configured to: - Establish an ad-hoc communication channel with a first terminal implementing a first electronic wallet, each of the first and second electronic wallets being associated with an expiry date and a transaction log;

[0036] - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said second electronic wallet and the associated transaction log;

[0037] - When connecting the second terminal to a gateway via a wide area network o Transfer said transaction log associated with the second electronic wallet; o Implement at least one consistency check of said transaction log by the gateway; o If at least one inconsistency is detected, trigger an asynchronous exception management.

[0038] According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet; and a storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for executing a method according to the first aspect of implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet.

[0039] PRESENTATION OF THE FIGURES Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

[0040] [Fig. 1]Figure 1 is a diagram of a system for implementing the method according to the invention;

[0041] [Fig.2]Figure 2 is a flowchart illustrating the steps of an embodiment of the method according to the invention.

[0042] DETAILED DESCRIPTION

[0043] Architecture

[0044] With reference to Figure 1, the present invention relates to a method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet, where appropriate without connectivity, and making it possible to immediately reuse this digital currency for a new transfer to a possible third electronic wallet. The first electronic wallet is implemented by a first terminal 2a and the second electronic wallet is implemented by a second terminal 2b.

[0045] The first and / or second electronic wallet is typically that of an individual, and the first / second terminal 2a, 2b is then typically his / her personal terminal, such as a smartphone. Alternatively, it may be the electronic wallet of an entity, for example a business, and then the terminal is typically a fixed piece of equipment such as a cash register.

[0046] Each individual / entity (in the remainder of the description we will refer to the owner of the terminal 2a, 2b - normally identical to the user of the terminal 2a, 2b), can have an electronic certificate, for example an X.509 certificate, stored on his terminal 2a, 2b, thanks to which he can prove his identity. This is an electronic certificate representing the identity of the user of the terminal 2a, 2b on which it is stored. It is understood in this respect that said certificate is linked to the owner and not to the terminal, and even less to the wallet: for example, the same certificate could be used on several terminals (if applicable with several electronic wallets) if they have the same owner (which is typically the case in a store). Such certificates, their obtaining and their renewal are well known to those skilled in the art and we will not return to this.

[0047] By electronic wallet, or "wallet", we mean an application adapted to store a quantity of electronic money (CBDC), and implement transactions, which are in practice of three types:

[0048] - Credit, i.e. loading the wallet with electronic money from a bank account (equivalent to a withdrawal from an ATM);

[0049] - Debit, i.e. the withdrawal of electronic money to a bank account (equivalent to a cash deposit in the bank);

[0050] - Transfer from one wallet to another (equivalent to a classic currency exchange).

[0051] The first two are not difficult because they can only be implemented on dedicated terminals or online, and therefore necessarily involve an internet connection. On the other hand, the transfer, which is the transaction that interests us, must be able to be done anywhere, and the present process will allow a completely "offline" over-the-counter transaction, in French "hors ligne", that is to say without a network connection.

[0052] Each terminal 2a, 2b comprises data processing means 21a, 21b (a processor), and a security element 20a, 20b (Secure Element, SE), i.e. a dedicated closed microprocessor of the enclave type (which may, if necessary, be part of the data processing means 11). As will be seen, the terminal 2a, 2b is typically a mobile terminal such as a smartphone, a touchscreen tablet, but also an EFT, or any peripheral.

[0053] Each terminal 2a, 2b is connectable to a wide area network 10 such as the internet, and via this to a gateway 1 of an electronic money management system, in particular a decentralized network for the distributed storage of a blockchain-type database, but it may alternatively be a network of conventional servers. This aspect is known to those skilled in the art and will not be described in more detail. It is understood in all cases that the gateway 1 is a trusted device, under the control of an authority such as the central bank.

[0054] By “connectable” we mean that each terminal 2a, 2b can connect to the network 10, but is not necessarily connected to it when the transaction is implemented, so as to allow “offline” operation.

[0055] Enrollment

[0056] As is known, the first and second electronic wallets typically have an expiration date and a key pair (public key / private key) for implementing transactions, and each is an applet signed by an authority entity (in particular the gateway 1) executed securely in the security element 20a, 20b. Preferably at least the private key is stored by the security element 20a, 20b.

[0057] In this respect, as represented by Figure 2, the method advantageously begins with a step (aO) of enrollment, that is to say of secure creation of the first and / or second electronic wallet, respectively the first / second terminal 2a, 2b, which involves a connection to the gateway 1 and therefore to the network 20. As we will see, each electronic wallet is associated with an expiration date (beyond which it is no longer possible to implement a transaction on the wallet), so that we distinguish the very first enrollment from the following enrollments which are in practice renewals that must be regularly repeated. Each occurrence of step (aO) defines an “offline session” of the wallet to be renewed before expiration.

[0058] Preferably, step (aO) contains the following sub-steps:

[0059] - If necessary, installation of the signed applet on the first / second terminal 2a, 2b; - Generation (in particular by the security element 20a, 20b) of a (new) key pair, and obtaining a unique electronic wallet identifier from the public key of said pair (typically by hashing);

[0060] - Registration of the e-wallet with Gateway 1 (after authentication), which will: o Set a (new) expiration date for the e-wallet; o Sign the public key of the e-wallet and said expiration date with a private key of Gateway 1 (which is in practice a key of the authority under whose control Gateway 1 is);

[0061] - In the case of a renewal, there is also a reset of any limits on the use of the electronic wallet (among the limit on the number of transactions, balance limit, single transaction amount limit, cumulative transaction amount limit, etc.). In addition, the electronic money is naturally retained.

[0062] Step (aO) may further comprise the obtaining by the terminal 2a, 2b of a “reference” timestamp, i.e. a timestamp certified by an authority (typically the gateway), making it possible to limit the possibilities of rigging a subsequent timestamp.

[0063] As will be seen later, a new enrollment (aO) is preferably implemented at each resynchronization following one or more offline transactions. It is understood that preferably, in the absence of transactions, the wallet does not wait to reach the expiry date before restarting an enrollment (aO), and that for example step (aO) is implemented automatically as soon as possible (at the first connection to the gateway 1) in a given time interval before the expiry date. For example, if wallets are expected to expire after a week, it can be provided that the terminals 2a, 2b seek to renew it two days before its expiry. Method

[0064] The present method very cleverly solves the problems of the prior art by combining three mechanisms:

[0065] - A fully offline transaction system;

[0066] - An asynchronous transaction verification mechanism; and

[0067] - Expiry date wallets.

[0068] Indeed, rather than trying in vain to secure transactions, which is only possible in the case of a permanent online function, the process lets the transactions take place entirely offline, and checks them at a later stage at resynchronization thanks to several levels of verification that will be detailed later. This does not pose any problem thanks to the expiration date: in a hypothetical case where a fraudulent user prevents resynchronization, for example by putting their terminal in airplane mode, they would reach the expiration date and their wallet would become blocked.

[0069] In summary, paradoxically, the present procedure tolerates a certain risk of fraud linked to the possibility of purely offline transactions, using the necessary renewal of the wallet as an a posteriori control mechanism that is impossible to circumvent.

[0070] The method begins with a step (a) of establishing an ad-hoc communication channel between the first terminal 2a implementing the first electronic wallet and a second terminal 2b implementing the second electronic wallet.

[0071] By ad hoc communication channel is meant a direct connection between the two terminals 2a, 2b, without an intermediary, in particular not via the network 10, so as to provide the capability of implementing transactions “offline”. Step (a) is thus a step of pairing the terminals 2a, 2b, voluntarily carried out by their users in order to enable the transfer of electronic money. This is also referred to as a p2p (peer-to-peer) connection.

[0072] This is advantageously a short-range wireless communication channel, for example in NFC by placing the two terminals 2a, 2b opposite each other, but also in Bluetooth or Wi-Fi Direct, or even an optical communication channel, for example by flashing with the second terminal 2b a QR code displayed by the first terminal 2a.

[0073] This step may include the mutual verification of the users' identities using their electronic certificates: the terminals 2a, 2b reciprocally transmit the certificates of their owners, and verify that they correspond to the identity of the other party, and that they have not expired. To reformulate, step (a) preferably includes, following the establishment of the channel, the transmission, by at least one (and preferably each) terminal 2a, 2b to the other terminal 2a, 2b, of the certificate that it stores (the one representing the identity of its owner), then the verification, by the (and preferably each) terminal 2a, 2b, of the certificate received (i.e. each ultimately verifies the certificate stored by the other terminal 2a, 2b). The objective here is to avoid, for example, identity theft (attempted payment using a terminal 2a stolen from a third party).As explained, said verification of a certificate advantageously includes verification that the certificate has not expired.

[0074] Then, in a step (b), said transaction is executed by the first and second terminals 2a, 2b, in particular in said secure elements 20a, 20b, via said ad-hoc communication channel. Step (b) comprises updating said first and second electronic wallets accordingly. In this case, if the transaction is the transfer of X units of electronic currency, the 1 er wallet sees its balance vary by -X and 2 e wallet sees its balance vary by +X.

[0075] It is important to understand that step (b) can be implemented “offline”, and therefore does not involve any communication with said gateway 1, and in particular no connection to the network 10. The terminals 2a, 2b can even be put in “airplane mode”. Of course, one and / or the other of the terminals 2a, 2b can alternatively be connected to the network 10 (and this will be in practice the majority of cases), but this connection is not used, and in any event the transaction is not accomplished differently.

[0076] The transaction can be executed in any manner known to those skilled in the art, but preferably, it involves a certain number of security mechanisms which, while they will never replace the security permitted by online operation, make it possible to block most fraud attempts.

[0077] In particular, step (b) advantageously comprises all or part of the following sub-steps:

[0078] - Authentication of the first user on the first terminal 2a (proof of consent), particularly interesting when he has previously presented a valid electronic certificate to the second terminal 2b;

[0079] - Mutual authentication of electronic wallets (using the signed identifier)

[0080] - Checking the consistency of transaction dates between terminals 2a, 2b (to prevent a user from altering the time on their terminal to bypass an expiration) and checking that the expiration date of none of the wallets has passed. It will be understood that this is a separate check from the optional check for electronic certificates, because it is entirely possible to have a valid and unexpired certificate but an expired wallet (i.e. valid identity but wallet not synchronized for too long) or the opposite (for example in the event of theft and hacking of a terminal 2a storing a valid wallet from a third party).

[0081] - Generation of a transaction identifier, and construction of a transaction with, for at least the first electronic wallet (and advantageously each of the first and second wallets), a triplet (unique electronic wallet identifier / expiration date / local transaction identifier). Note that said local transaction identifier is for a given wallet insofar as it is not possible to directly generate a unique transaction identifier due to the potentially online nature of the transaction. It is typically incremented with each new transaction involving the wallet. On the other hand, the triplet (unique electronic wallet identifier / expiration date / transaction identifier) ​​is necessarily unique;

[0082] - Signature of said triplet, the amount and a timestamp with the secret key of the wallet (as well as a possible list of units or fragments of electronic money units involved in said transaction, see below);

[0083] - Update of a transaction log. Note that no personal data is advantageously entered there to guarantee the privacy of users: all identifiers are pseudo anonymized.

[0084] The unique signed triplet allows for a transaction that can be replayed as much as necessary to overcome any communication issues between terminals 2a, 2b while ensuring that the electronic money is ultimately transferred once and only once. And it remains entirely possible to implement several similar transactions (same wallets and same amount) since we will have different triplets.

[0085] Then, the method comprises, as explained, a resynchronization step (b). If the terminals 2a, 2b were connected online, it takes place simultaneously, otherwise it takes place at the next connection of the first terminal 2a and / or the second terminal 2b to a gateway 1 via the wide area network 10.

[0086] It is noted that there may be (before step (c)) several occurrences of steps (a) and (b), i.e. several successive offline transactions, and in particular transactions involving the same virtual currency units, which are therefore retransferred; the resynchronization will in fact concern all transactions in the time interval.

[0087] Step (c) thus comprises the following sub-steps: a. Transfer of the transaction log from the first terminal 2a and / or the second terminal 2b, in practice each as soon as it is connected to the gateway; b. Implementation of at least one consistency check of each transaction log by the gateway 1; c. If at least one inconsistency is detected, updating said first and second electronic wallets accordingly.

[0088] Checks

[0089] By checking the consistency of the transaction log, we mean cross-checking with all the information available to the gateway 1, which allows the detection of anomalies either in the log itself, or of contradictions with another log, and in particular between the log of the first wallet and the log of the second wallet, which we will call "inconsistencies" in all cases.

[0090] Generally, Gateway 1 will check at least in the logs:

[0091] - that we find the same transaction (the one that has just been executed) from the point of view of the first terminal 2a and the second terminal 2b with the same amounts and same timestamp, i.e. the consistency of the transaction identifiers and associated information;

[0092] - where applicable, that the timestamp of the log is consistent with the reference timestamp, to prevent, for example, the user from being able to rig the clock of his terminal 2a, 2b so as to implement a transaction when the expiry date had passed;

[0093] - where applicable, the signatures (the gateway has the public keys of the wallets, allowing it to check, for each of the first and second wallets, the signatures of the triplet, the amount and the timestamp);

[0094] - where applicable, the absence of crossing the limits of use of electronic wallets.

[0095] Preferably, several verification paradigms, corresponding to several security levels, can be implemented to increasingly verify said consistency of each log, and sub-step b. comprises the selection of a consistency verification level of said transaction log from among the possible levels, and the implementation of said selected verification level:

[0096] - At the first level, only a balance variation check is implemented, called a “balance based” check. Here, the consistency of portfolio balance variations with the transactions described in the journals is checked;

[0097] - According to a second level, a traceability verification of the transferred electronic money is implemented, called “funding-based” verification, relating to the tracking of electronic money units. Indeed, preferably, the electronic money is “tokenized” and fragmentable, which means that each unit of the currency has a unique identifier (in the same way as a banknote), and the units involved in the transaction (i.e. those which constitute the transferred amount) are entered in the journal. It is understood that the same unit (or fragment of a unit) can only be present at a given time in a single electronic wallet, otherwise it is a case of “double spending”. Note that it can be provided that a unit also has an expiration period, which prevents it from being retransferred until the next resynchronization (occurrence of step (aO));

[0098] - At a third level, called "full history", a verification of the complete transaction history is implemented. This is a more advanced version of the traceability verification in which the transfer chain of electronic money units from wallet to wallet is completely determined. Such verification requires significantly more computing power and is only advantageously implemented in cases of suspected fraud, so as to carry out a more in-depth verification.

[0099] If at least one inconsistency is detected, an exception management is triggered to identify the origin of this inconsistency and / or to correct it. This exception management may possibly require a certain delay to recover and process additional data during the synchronization of other wallets. Depending on the conclusions of this analysis and in the event of fraud, additional actions may be implemented such as additional verifications (such as lifting anonymity) and / or sanctions such as the immediate deactivation of the electronic wallet concerned and the initiation of legal proceedings against the holder. Since transactions are final, wallets that have interacted legitimately will not be impacted.

[0100] If, on the contrary, no inconsistency is identified, as explained, a new enrollment (aO) is implemented in order to define a new expiry date and authorize new offline transactions.

[0101] Terminal

[0102] According to a second and a third aspect, the invention relates to the terminals 2a and / or 2b for implementing the method according to the first aspect.

[0103] The first and second terminals 2a, 2b each implement a first and a second electronic wallet, each of the first and second electronic wallets being associated with an expiry date and a transaction log, and comprise data processing means 21a, 21b and preferably secure elements 20a, 20b for executing an electronic money transfer transaction.

[0104] The first terminal 2a is configured for:

[0105] - Establish an ad-hoc communication channel with the second terminal 2b;

[0106] - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said first electronic wallet and the associated transaction log;

[0107] - When connecting the first terminal 2a to a gateway 1 via a wide area network 10 o Transferring said transaction log associated with the first electronic wallet; o Implementing at least one consistency check of said transaction log by the gateway 1; o If at least one inconsistency is detected, triggering an asynchronous exception management.

[0108] The second terminal 2b is configured for:

[0109] - Establish an ad-hoc communication channel with the first terminal 2a;

[0110] - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said second electronic wallet and the associated transaction log;

[0111] - When connecting the second terminal 2b to a gateway 1 via a wide area network 10 o Transfer said transaction log associated with the second electronic wallet; o Implement at least one consistency check of said transaction log by the gateway 1; o If at least one inconsistency is detected, triggering of an asynchronous exception management

[0112] Computer program product According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means 21 a, 21 b of the terminal 2a, 2b) of a method according to the first aspect of implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet, as well as storage means readable by computer equipment (for example the data storage means 22a, 22b of the terminal 2a, 2b) on which this computer program product is found.

Claims

CLAIMS 1. Method for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet, characterized in that it comprises the implementation of steps of: (a) Establishing an ad-hoc communication channel between a first terminal (2a) implementing the first electronic wallet and a second terminal (2b) implementing the second electronic wallet, each of the first and second electronic wallets being associated with an expiration date and a transaction log; (b) If said expiry date of each of the first and second electronic wallets has not passed, execution of said transaction by the first and second terminals (2a, 2b) via said ad-hoc communication channel, and updating of said first and second electronic wallets, and of the associated transaction logs; (c) When connecting the first terminal (2a) and / or the second terminal (2b) to a gateway (1) via a wide area network (10) a. Transferring said associated transaction log to the electronic wallet implemented by said connected first terminal(s) (2a) and / or second terminal (2b); b. Implementing at least one consistency check of said transaction log by the gateway (1); c. If at least one inconsistency is detected, triggering an asynchronous exception management.

2. Method according to claim 1, wherein step (b) does not involve any connection to said gateway (1), and in particular no connection to the network (10).

3. Method according to one of claims 1 and 2, in which said ad-hoc communication channel between the first terminal (2a) and the second terminal (2b) is a short-range wireless communication channel, in particular NFC, or an optical communication channel.

4. Method according to one of claims 1 to 3, comprising a step (aO), implemented by the first terminal (2a) and / or second terminal (2b) during a connection to the gateway (1) via said extended network (10), of secure creation of the first and / or second electronic wallet.

5. Method according to claim 4, in which step (a0) is repeated each time step (c) is implemented, so as to renew said first and / or second electronic wallet(s).

6. Method according to one of claims 5 and 6, in which step (aO) comprises defining a new expiry date of said first and / or second electronic wallet.

7. The method of claim 6, wherein each of the first and second electronic wallets is further associated with at least one usage limit, step (b) being further implemented only when said usage limits of each of the first and second electronic wallets are not exceeded, step (aO) comprising resetting said limits.

8. Method according to one of claims 1 to 7, wherein each of the first and second electronic wallets is further associated with a unique electronic wallet identifier, step (b) comprising, for each of the first and second electronic wallets, the construction of a triplet (unique electronic wallet identifier / expiry date / local transaction identifier) ​​uniquely identifying said transaction.

9. A method according to one of claims 6 and 7 and claim 8 in combination, wherein each of the first and second electronic wallets is further associated with a pair of a private key and of a public key, step (aO) comprising generating a new key pair, constructing said unique e-wallet identifier from the public key, and obtaining gateway-signed versions (1) of said public key and expiration date.

10. The method of claim 9, wherein step (b) further comprises, for at least the first electronic wallet, signing with the private key of said first electronic wallet, the triplet uniquely identifying said transaction, an amount of electronic money transferred during the transaction, and a timestamp of the transaction.

11. Method according to one of claims 1 to 10, wherein each terminal (2a, 2b) comprises a security element (20a, 20b), said transaction being executed in step (b) in said security elements (20a, 20b).

12. Method according to one of claims 1 to 11, in which step (c) is implemented for each of the first terminal (2a) and the second terminal (2b), sub-step b. comprising the verification that the same transaction is found from the point of view of the first terminal (2a) and the second terminal (2b) described in the logs of the first and second electronic wallets.

13. Method according to claim 12, in which step b. comprises the selection of a level of verification of the consistency of said transaction log from among several possible levels, and the implementation of said selected level of verification, including a level of verification of traceability of the transferred electronic money, in which each unit of the electronic money has a unique identifier and the gateway (1) further verifies that the same fragment of a unit of the electronic money is present at a given time only in a single electronic wallet.

14. Method according to one of claims 1 to 13, in which each terminal (2a, 2b) stores an electronic certificate representative of the identity of a user of said terminal (2a, 2b), step (a) comprising the verification by at least one terminal (2a, 2b), and preferably each terminal (2a, 2b), of the certificate stored by the other terminal (2a, 2b).

15. First terminal (2a) implementing a first electronic wallet, characterized in that it is configured to: - Establishing an ad-hoc communication channel with a second terminal (2b) implementing a second electronic wallet, each of the first and second electronic wallets being associated with an expiration date and a transaction log; - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said first electronic wallet and the associated transaction log; - When connecting the first terminal (2a) to a gateway (1) via a wide area network (10) o Transferring said transaction log associated with the first electronic wallet; o Implementing at least one consistency check of said transaction log by the gateway (1); o If at least one inconsistency is detected, triggering an asynchronous exception management.

16. Second terminal (2b) implementing a second electronic wallet, characterized in that it is configured to: - Establish an ad-hoc communication channel with a first terminal (2a) implementing a first electronic wallet, each of the first and second electronic wallets being associated with an expiration date and a transaction log; - If said expiration date of each of the first and second electronic wallets has not passed, execute via said ad-hoc communication channel a transaction relating to the transfer of digital currency from the first electronic wallet to the second electronic wallet, and update said second electronic wallet and the associated transaction log; - When connecting the second terminal (2b) to a gateway (1) via a wide area network (10) o Transfer said transaction log associated with the second electronic wallet; o Implement at least one consistency check of said transaction log by the gateway (1); o If at least one inconsistency is detected, triggering an asynchronous exception management.

17. Computer program product comprising code instructions for executing a method according to one of claims 1 to 14 for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet, when said program is executed on a computer.

18. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 14 for implementing a transaction relating to the transfer of digital currency from a first electronic wallet to a second electronic wallet.

Images