Method for implementing a transaction of an initial amount in fiat currency between a first user and a second user.

Abstract

The present invention relates to a method for implementing a transaction of a first amount, comprising the implementation of the following steps: Issuing a credit request from a temporary account, for a second amount greater than or equal to said first amount; Implementing a transaction on a blockchain to create a third quantity of a first fungible token transferable within said blockchain, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount; Implementing a transaction on said blockchain to transfer said first quantity of said first fungible token; Transferring said first amount in said fiat currency from said temporary account to an account of a second user;Implementation of a transaction on said blockchain to destroy said first quantity of the fungible token transferred. [Fig. 1];

Description

Title of the invention: Method for implementing a transaction of a first amount in a fiduciary currency between a first user and a second user.

[0001] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of blockchain-type databases. More specifically, it concerns a method for implementing a transaction of an initial amount in fiat currency between a first user and a second user via such a blockchain-type database.

[0003] STATE OF THE ART

[0004] Blockchain databases are used daily to exchange tokens such as cryptocurrencies in a near-instantaneous, reliable and secure manner.

[0005] It is desirable to use these properties of the blockchain to carry out payment-type transactions (then called "on-chain"), but the problem is that it is not possible to transfer fiat currency directly onto the blockchain.

[0006] The classic solution is to use a stablecoin, that is, a cryptocurrency whose price is pegged to a fiat currency, such as USDC backed by the US dollar (each token theoretically worth $1), or a deposit token (i.e., a token issued by a deposit institution such as a bank) with a value guaranteed by that institution. Stable / deposit tokens are designated "S / DT".

[0007] This solution requires the user initiating the transaction to obtain a quantity of tokens with fiat currency (by purchase or deposit), then to transfer these tokens to the recipient of the transaction, who will then either exchange them for fiat currency or keep them for possible future transactions.

[0008] Using a S / DT helps to protect against any fluctuation in the value of the token during the transaction, but presents a number of disadvantages: - each step is associated with costs for one or the other party, whether it is to obtain S / DT or to exchange them for fiat currency; - riskier because the financial institutions holding the fiat currency equivalent of the stable / deposit tokens may experience financial difficulties or even default. The USDC stablecoin has faced such a risk in March 2023 following the difficulties of Silicon Valley Bank, in which a third of USDC's US dollar reserves were held; - the holder of S / DT no longer benefits from the same financial guarantees (deposit guarantee) nor from the same conditions of remuneration of his deposits as those of his usual bank; - The usual banks of S / DT holders are facing a reduction in their demand deposits, which is impacting their balance sheets.

[0009] Solutions with directly tokenized fiat currencies of the CBDC (“Central Bank Digital Currency”) type are also known, see for example US patent 11354662.

[0010] These currencies are guaranteed by a central bank, but are still rare today, and above all the problem of double conversion remains.

[0011] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0012] The present invention therefore relates, according to a first aspect, to a method for carrying out a transaction of a first amount in fiat currency between a first user and a second user, comprising the implementation of the following steps: a. Issuance from a first device of the first user of a credit request from a temporary account managed by a server connected at least to the first device by a network, up to a second amount in said fiduciary currency greater than or equal to said first amount; b. Implementation by said server of a transaction on a blockchain-type database to create for the benefit of the first user a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount; c. Implementation by said server of a transaction on said blockchain-type database of transfer, from the first user to the second user, of said first quantity of said first fungible token; d. Transfer by the server of said first amount in said fiat currency from said transitory account to an account of the second user; e. Implementation by said server of a transaction on said blockchain-type database to destroy said first quantity of the fungible token transferred to the second user.

[0013] According to advantageous and non-limiting features:

[0014] Step (a) includes the authentication of the first user on the first equipment and the authentication of the second user on a second equipment of the second user also connected to the first equipment via said network, so as to confirm the consent of the first and second users to implement said transaction of said first amount in fiat currency.

[0015] Said credit request of a temporary account managed by the server is a request to transfer said second amount in fiat currency from a bank account of the first user to said temporary account.

[0016] Said credit request for a temporary account managed by the server is a request to debit said server said second amount from said bank account of the first user.

[0017] The issuance of said credit request is triggered by the authentications of the first and second users and the second amount is equal to the first amount.

[0018] The issuance of said credit request is implemented in advance and step (b) is triggered by the authentications of the first and second users.

[0019] The third quantity is equal to the second quantity.

[0020] Step (e) further includes, if the second amount is strictly greater than the first amount, the transfer by the server of the difference between the first and second amounts in said fiat currency from said transitory account to an account of the first user.

[0021] Said first fungible tokens are locked tokens for the first and second users.

[0022] The method includes a step (aO) of implementation by said server of a transaction on said blockchain-type database of creation for the benefit of the first user of a fourth quantity of a second fungible token transferable in said blockchain-type database, said fourth quantity corresponding to a balance of a bank account of said first user.

[0023] Step (c) includes the implementation by said server of a transaction on said blockchain-type transfer database, from the first user to the second user, of a fifth quantity of said second fungible token corresponding to the first amount.

[0024] The process includes, if said balance of said first user's bank account has changed, a step (al) of implementation by said server of a transaction on said blockchain-type database to update said fourth quantity of the first user's second fungible token, so as to correspond to the balance of said first user's bank account.

[0025] Step (aO) includes a request for access from the server to the bank account of the first user.

[0026] Said first fungible token and said second fungible token represent the same value in said fiat currency so that the first quantity of the first fungible token is equal to the fifth quantity of the second fungible token.

[0027] At least steps (b), (c) and (e) are implemented by means of a smart contract.

[0028] The method includes the implementation of a step (f) of implementing an action by said second user in consideration of the transaction.

[0029] According to a second aspect, the invention proposes a server, characterized in that it comprises data processing means configured to, during a transaction of a first amount in fiat currency between a first user and a second user:

[0030] - following transmission from the first device of the first connected user audit server by a network of a credit request of a temporary account managed by said server, up to a second amount in said fiat currency greater than or equal to said first amount, implement a transaction on a blockchain-type database of creation for the benefit of the first user of a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount;

[0031] - implement a transaction on said blockchain-type database of transfer, from the first user to the second user, of said first quantity of said first fungible token;

[0032] - transfer said first amount in said fiat currency from said account transitional to a second user's account;

[0033] - implement a transaction on said blockchain-type database of destruction of said first quantity of the fungible token transferred to the second user.

[0034] According to a third aspect, the invention proposes a set of the server according to the second aspect and the first equipment configured to issue said credit request from a transitory account managed by said server, up to the second amount.

[0035] According to a fourth and fifth aspect, the invention relates to a computer program product comprising code instructions for executing a process according to the first aspect for implementing a transaction of a first amount in fiat currency between a first user and a second user; and a computer-readable storage means on which is stored a computer program product comprising code instructions for executing a process according to the first aspect for implementing of a transaction of an initial amount in fiat currency between a first user and a second user. PRESENTATION OF THE FIGURES

[0036] Other features and advantages of the present invention will become apparent from the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings in which:

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

[0038] [Fig.2a] [Fig.2a] is a flowchart illustrating the steps of a first embodiment of the process according to the invention;

[0039] [Fig.2b] [Fig.2b] is a flowchart illustrating the steps of a second embodiment of the process according to the invention. DETAILED DESCRIPTION

[0040] Architecture

[0041] The present invention relates to a method of implementing a transaction of a first amount in fiat currency between a first user and a second user, in a system as represented in [Fig.1].

[0042] As will be seen, said transaction involves a blockchain-type database, enabling distributed ledger technology (“DLT”), in a completely transparent manner for users (but not necessarily immediately visible, i.e. without complicating the transaction for the user).

[0043] Said system comprises at least one client device 1, 2 (generally a large number of them), in particular a first client device 1 belonging to the first user and a second client device 2 belonging to the second user, each being a personal device of the user enabling them to carry out transactions on their own behalf, i.e., to initiate / accept transactions. In particular, it will be assumed that the users have means of payment in said fiat currency and in particular bank accounts (first account for the first user and second account for the second user), manageable via their client device 1, 2, where appropriate using a dedicated application (such as their bank's application).

[0044] Furthermore, each client device 1, 2 advantageously plays the role of a "wallet," that is, a digital wallet for, for example, sending or receiving fungible tokens transferable on said blockchain in accordance with this process, or even cryptocurrencies and / or non-fungible tokens such as NFTs (transferable on other blockchains). A wallet generally stores a private key of its user, and is designated by an address which is typically a cryptographic hash of the public key corresponding to the private key.

[0045] Alternatively, each user's wallet can be managed in a decentralized manner, notably by a trusted third-party server 3 connected to the devices 1 and 2. This server 3 is typically a remote and automated server such as a transaction management platform or a banking server. In particular, server 3 can create and manage wallets on behalf of the clients, as well as a temporary bank account, which will be described later. It should be noted that the temporary bank account can be completely independent of the aforementioned bank accounts, i.e., opened with different banks.

[0046] In all cases in particular we have at least one first customer equipment 1 called creditor as a device of a first user "buyer" in said transaction (recipient of the transaction), and advantageously a second customer equipment 2 called debtor as a device of a second user "seller" in said transaction (originator of the transaction).

[0047] Said transaction of a first amount in a fiat currency can thus be a payment (and then the first user expects a consideration from the second user such as a product or service which is the object of the transaction, and for example a digital asset such as a non-fungible token according to an embodiment which will be described later).

[0048] Alternatively, said transaction may be a simple transfer of money, i.e. a wire transfer, in particular a gift or a deposit.

[0049] It should be noted that the said transaction is in fiat currency, i.e., a given official currency (for example, €1000), and not in a cryptocurrency, the value of which can fluctuate. The objective here is to avoid using a cryptocurrency, and in particular an S / DT token, so that the first user pays exactly the said initial amount, less any bank charges (which would be of the same order as for any other money transfer such as a wire transfer), but without incurring additional exchange fees between fiat currency and tokens and / or potential exchange rate fluctuations, nor bearing counterparty risk that significantly reduces the value of the tokens.

[0050] To summarize, the first amount of fiat currency is transferred from the first user to the second user, the first user and / or the second user may optionally pay additional bank charges, and any consideration for the transaction is transferred from the second user to the first user.

[0051] In the present case, each customer device 1, 2 is preferably a lightweight physical device such as a smart card or a terminal such as a smartphone, in particular a security element of such a terminal, i.e. a dedicated, closed, enclave-type microprocessor. It will be understood that the present invention is not limited to these cases and that each client device 1, 2 can always be a smartphone, a tablet, a personal computer, etc. Each client device 1, 2 can further include means for acquiring a biometric trait such as a camera or a fingerprint reader.

[0052] In all cases, the first equipment 1, the second equipment 2 and the server 3 include data processing means 11, 21, 31, i.e. a computer such as, for example, a processor, a microprocessor, a controller, a microcontroller, an FPGA, etc. These computers are adapted to execute code instructions to implement the process described below.

[0053] The first equipment 1, the second equipment 2 and / or the server 3 may also include data storage means 12, 22, 32 (a memory, for example flash) possibly a user interface (typically a touch screen), etc.

[0054] Devices 1 and 2 communicate with each other and with server 3 via at least one network 30, for example, the Internet, a cellular network, or a combination of such networks. Devices 1 and 2 and / or server 3 have read and write access to a blockchain database stored in network 30. Note that storage nodes (transaction validator devices, called "miners," which are known to those skilled in the art) may also be present in the same case, but alternatively, server 3 may itself, if necessary on its own, act as a node.

[0055] A blockchain database is potentially distributed across multiple storage nodes, and these nodes are configured to validate data written to the database by implementing a consensus method among them. Such a method is, for example, "proof of work" (POW) or "proof of stake" (POS). The database content (a history of all past transactions between users of the system) is thus protected against falsification, despite its potentially distributed nature.

[0056] The most famous blockchain-type databases are the Bitcoin® or Ethereum® blockchain, or any other compatible blockchain.

[0057] The database can be public, in the sense that it is freely accessible for reading not only by the devices 1, 2, 3 present but also by any other third-party device (which is the case for the aforementioned blockchains). Any third-party device can then, in particular, consult the data of previously implemented transactions in order to ensure that a transaction was indeed implemented under the intended conditions.

[0058] Alternatively, the database can be "private", i.e. it is not accessible to third-party users, and is potentially not distributed but entirely managed by server 3, if it is preferred that transactions be guaranteed (by server 3) but remain confidential.

[0059] The present process uses at least one first fungible token transferable on said blockchain, which will be called vCoinl (or simply vCoin-L for "locked"), and / or a second fungible token also transferable on said blockchain, which will be called vCoin2. Their differences will be discussed later. By fungible token, we mean a type of non-unique and interchangeable cryptographic token (two vCoins are indistinguishable), just like a cryptocurrency. It should be noted that said first and second fungible tokens are purely utility tokens (called "technical tokens" or "just tokens") that represent a predefined value but cannot be freely exchanged for fiat currency. It is understood that said first and second fungible tokens are neither tokenized fiat currencies nor cryptocurrencies.In other words, these tokens only represent a value from a mathematical point of view, but do not have that value. In practice, all transactions in these first or second fungible tokens are controlled by server 3.

[0060] In contrast, a non-fungible token, or NFT (non-fungible token), is a type of cryptographic token transferable on a blockchain, just like a fungible token, but unique and therefore non-interchangeable.

[0061] The action of creating a fungible token, generally by means of a smart contract on the blockchain, for example in accordance with the ERC-20 standard on an Ethereum blockchain, is called "minting".

[0062] Similarly, the action of destroying a fungible token by the same means is called "burning".

[0063] We will now describe two possible alternatives to the present process, depending on whether we use the first type of fungible tokens vCoin1 or the second type of fungible tokens vCoin2. As we will see, it is possible and even very advantageous to use both types of fungible tokens.

[0064] In all cases the present process is implemented mainly by the data processing means 31 of the server 3, but also partly by the data processing means 11, 21 of the two pieces of equipment 1, 2.

[0065] Method - case of the first vCoinl fungible tokens

[0066] With reference to [Fig. 2a], in this first variant the process begins with a step (a) of sending from the first device 1 of the first user a credit request (i.e., a top-up request) to a temporary account managed by the server 3, to height of a second amount in said fiduciary currency greater than or equal to said first amount.

[0067] It is understood here that this is simply a matter of transferring money to the aforementioned temporary account, in a straightforward manner: there is no token purchase, no currency exchange. The idea is simply to reserve at least the initial amount to ensure that the first user is able to complete the transaction, or even, if desired, to guarantee that the first user is not overdrawn or at least that their account balance does not fall below a predefined limit.

[0068] From an accounting perspective, the money transferred to the transitory account always belongs to the first user: if the transaction is ultimately abandoned, they automatically recover this money (minus any applicable fees). This solution is therefore secure for the first user, who does not take any risk by crediting the transitory account, unlike in the case where they would have to buy cryptocurrency. The transitory account can be viewed as an escrow account, and it preferably has a limited lifespan, for example, within one business day, or a maximum of 24 hours (the maximum time after which the money it contains must have been transferred to another user, or otherwise returned to the first user).

[0069] Generally, the first amount is the same as the second amount, but can be much higher if, for example, several transactions are to be made in succession. There may also be bank charges, the second amount then being the money actually transferred by the first user less these charges.

[0070] This step can be done in many ways: - by bank transfer from the first user's first account once the transaction is required - in advance by "pre-loading" the temporary account before one or more transactions, possibly for a predetermined maximum duration such as 24 hours (see below) - by payment through any other means (bank card, automated payment scheme such as PayPal, Apple Pay, etc.) - by debiting the first user's account if the trusted third party (operating server 3) has a SEPA-type mandate - etc.

[0071] It is even noted that step (a) can be implemented in several stages (for example with transfers from several accounts of the first user), the second amount then being the sum of the independently credited amounts.

[0072] Preferably, step (a) includes, before or after said crediting of the transitory account, the validation of the transaction (i.e., of the first amount and the object of the transaction) by each of the first and second users respectively on the first and second equipment 1, 2.

[0073] This can be done in any known way, for example using existing trading platforms, preferably complying with all regulatory obligations, in particular in terms of anti-money laundering (“AML”) and know customer (“KYC”) obligations.

[0074] For example, the first user can validate their purchase on their equipment 1, then the second user confirms the first user's purchase on their equipment 2.

[0075] This phase may include in particular the authentication of the first user on the first equipment 1 and the authentication of the second user on the second equipment 2 (in particular by entering a code or by using biometric acquisition means of equipment 1, 2), so as to confirm the consent of the first and second users to implement said transaction of said first amount in fiat currency.

[0076] According to a first embodiment, the transaction is validated first (i.e., the issuance of the credit request is triggered by the authentication of the first and second users, and the first amount is equal to the second amount). The second amount then generally corresponds to the first amount. The user has the option to pay according to this process (they can choose several payment methods), and if they choose, they are redirected to a page allowing them to issue the credit request. Any applicable fees are automatically added to the first amount.For example, assuming the user approves a transaction of €1000, a page will appear asking them to confirm a transfer or direct debit of €1000.50. This involves either transferring €1000 to the temporary account and deducting €0.50 directly as a bank fee (to the trusted third party operating server 3), or transferring €1000.50 and retrieving €0.50 later (examples will be provided later). Note that the second amount is always €1000, not €1000.50, as the fee is added on top (the amount must not fall below the first amount). Alternatively, the transfer can be initiated by the user (manually if necessary) through their bank. The user will be redirected to their bank's application, usually called "eBanking," to validate the initiated transfer covering the second amount and any applicable bank fees.It can be anticipated that the first user has a limited time to implement the credit request; otherwise, the transaction is canceled. It is reiterated that any fees may be borne by the seller, or there may be no fees at all. If the credit request is delayed (i.e., implemented but after the deadline), the... limited time, so when the transaction is already cancelled), the second amount is refunded, see step (e) further on.

[0077] According to a second embodiment, the issuance of said credit request is implemented in advance, i.e., the temporary account is already funded when the user validates the transaction (assumed to be sufficiently funded, i.e., by a second amount greater than or equal to the first amount – otherwise the transaction is canceled). The following step (b) is directly triggered by the authentications of the first and second users.

[0078] Indeed, validating the transaction constitutes confirmation that the balance can be used for this purpose. For example, assuming that the user has credited the temporary account with €2000 and validates a transaction of an initial amount of €1000 with a bank fee of €0.50, €1000.50 will be automatically allocated to said temporary account.

[0079] Next, in a main step (b), the process includes the implementation by said server 3 of a transaction on said blockchain-type database of creation for the benefit of the first user of a third quantity of the first fungible token transferable in said blockchain-type database (vCoinl).

[0080] By creation, we mean the "mint," i.e., as explained, the pure and simple generation of vCoinl, and not their transfer or acquisition. The tokens are for the benefit of the first user, meaning they appear in the first user's wallet. They are advantageously locked, or "frozen," tokens, meaning they cannot be transferred or used by the first user, hence their name vCoin-L for locked.

[0081] Said third quantity of said first fungible token is between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount, advantageously equal to the second quantity. To rephrase, it is necessary to mint a number of tokens covering at least the first amount of the transaction, but less than the balance of the transitory account (the second amount). Note that if first amount = second amount, then automatically first quantity = second quantity = third quantity.

[0082] By quantity "corresponding to an amount", we mean according to a predefined "value" of said fungible token.

[0083] For example, one can arbitrarily define that one vCoinl represents €1. Since these tokens are technical tokens that have no market value elsewhere, this value is irrelevant. It should be noted that in practice they have no value.

[0084] Thus, assuming a €1000 transaction with €2000 in the transit account, between 1000 and 2000 vCoinsl are minted. Note that additional minting may be required for tokens representing fees if these have not already been deducted, for example, 0.5 vCoinsl in our example.

[0085] As explained, it is possible to predict that the third quantity is equal to the first quantity, which allows for the creation of precisely the right number of tokens and completely prevents fraud. Alternatively, it is possible to predict that the third quantity is equal to the second quantity, which allows for "duplicate" the balance of the transitory account. Anything in between is also possible.

[0086] It is understood here that this mint is without consideration. This means that at the end of step (b), in a very original way, there is both fiat currency in the transit account, and tokens in the first user's wallet, the latter representing the amount of fiat currency in the transit account.

[0087] This is counterintuitive, as it may give the impression of having "double" money, but it allows for the flexibility and efficiency of the present process. It should be noted that the user has no access to the money in the transitory account, nor to the tokens in their wallet, so there is no risk of fraud. It should also be noted that such duplication would be absolutely impossible if the tokens were tokenized fiat currencies or cryptocurrencies.

[0088] This step (b) can be implemented using a smart contract as explained. If the transitory account has not been sufficiently funded (for example, for a €1000 transaction, only €500 has been transferred), then step (b) fails and the tokens are not created. It can be assumed that the bank fees are not refunded. Alternatively, it is possible to retrieve the difference, i.e., to implement a new iteration of step (a), denoted (a'), by issuing a new credit request from the first device 1 to the transitory account, for at least the difference between the second amount and the first amount.

[0089] So, assuming that the tokens could have been created, the process includes a step (c) of implementation by said server 3 of a transaction on said blockchain-type transfer database, from the first user to the second user, of said first quantity of said first fungible token.

[0090] Indeed, we have created at least the said first quantity and we can therefore transfer it to the wallet of the second user, which allows the latter to have the guarantee that the first user is indeed able to pay him up to the first amount, and to create a trace of this transaction in the blockchain.

[0091] If the third quantity is greater than the first quantity (for example, 1500 tokens were minted for a transaction of €1000), then a number of tokens equal to the difference between the first and third quantities remains in the first user's wallet.

[0092] This step (c) can again be implemented via a smart contract.

[0093] Note that if tokens corresponding to the fees have also been minted, the said transaction of step (c) is also a transfer transaction, to a wallet of the trusted third party (for whose benefit the fees are collected), of these tokens corresponding to the fees.

[0094] At this stage, the money in the transit account is still pending. Therefore, the process includes a step (d) of transferring said first amount in said fiat currency from said transit account to an account of the second user via server 3. More precisely, it involves transferring an amount in fiat currency corresponding to the quantity of tokens received. This quantity is the first quantity, so the amount to be transferred is indeed the first amount. This provides additional security against further potential fraud.

[0095] Thus, to return to our example, 1000 vCoins were transferred, so that €1000 was transferred from the temporary account to the second user's account. Again, any money transfer technique can be used, in particular a simple bank transfer, and where applicable, fees may be charged if borne by the seller (for example, only €999.50 actually transferred to the second bank account).

[0096] At this stage, the second user has both the tokens and the money, so that a step (e) of implementation by said server 3 of a transaction on said blockchain-type database of destruction of said first quantity of the first fungible token transferred to the second user occurs.

[0097] It is recalled that the first fungible token (vCoinl) is a technical token with no market value, so that the said first quantity can be removed (the so-called "burn" action), to guarantee a total absence of fraud.

[0098] Preferably steps (d) and (e) can be simultaneous or at least linked, to ensure total security.

[0099] Again, one and / or the other of these steps can be implemented by means of a suitable smart contract.

[0100] At this stage, if the third quantity is different from the first quantity and / or the second quantity, there remains some first tokens in the first user's wallet and / or money in the transitory account.

[0101] For example, if there was €2000 on the transit account, the first 1500 mint tokens, for an initial amount of €1000, there remains €1000 on the transit account and the first 500 tokens in the first wallet (if we do not consider fees).

[0102] In this respect, step (e) may further include, if the second amount is strictly greater than the first amount (or equivalently if the second amount is strictly greater than the first amount), the transfer (recredit) by server 3 of the difference between the first and second amounts in said fiat currency (i.e. the remainder) from said transitory account to an account of the first user, subject to any applicable fees.

[0103] Thus in our example the €1000 will be transferred back to the first user's bank account.

[0104] Alternatively, and particularly in a mode where the temporary account can be loaded in advance, there is no immediate credit, but rather after a given period of time ending, for example, at the end of the current business day, i.e., a maximum of 24 hours, which allows the user to carry out several successive transactions. At the end, the remaining balance, i.e., the difference between all the second amounts and all the first amounts, is credited.

[0105] If the transaction could not take place for any reason whatsoever, for example in the event of a late credit request or a technical incident during steps (b) and (c), there is at this stage still the second amount on the transitory account, and similarly it can be foreseen that the remainder (i.e. this second amount) is credited immediately or at the end of the given time period according to the mode of operation.

[0106] With regard to possible first tokens in excess (if the third quantity is strictly greater than the first quantity), step (e) advantageously includes the implementation by said server 3 of a transaction on said blockchain-type database of destruction of the difference between the first and third quantities of the first fungible token which remains with the first user (i.e. the remainder of his wallet).

[0107] This transaction can be concomitant with that of destruction of the transferred tokens, the idea is that there is no longer a first token, neither in the first user, nor in the second user.

[0108] Note that step (e) may include server 3 sending a notification to the second device 2, informing the second user that the transaction was successful, i.e., that they have received the first amount (less any applicable fees) in their account, without unnecessary costs or risks. Furthermore, thanks to the first fungible tokens, the transaction is irrefutably recorded in the blockchain.

[0109] Then, the process may include a possible final step (f) of implementation of an action by said second user in consideration of the transaction (of the payment of the first amount).

[0110] As explained, the transaction may be a simple transfer of money without explicit consideration, but most often it is a payment upon purchase so that said action is the provision of the product or service purchased.

[0111] In the case where the object of the transaction is a digital asset such as an NFT, step (f) includes the implementation of a transaction on a transfer blockchain-type database (generally different from the blockchain on which are transferable the first fungible tokens), from the second user to the first user, of said digital asset.

[0112] Preferably, in this case of a digital asset, it is possible to implement step (f) at the same time as step (e), or even step (c) (using the same smart contract), this is called a swap (exchange on the blockchain).

[0113] Note that it is possible to lock the digital asset (in the same way as vCoinsl) from step (b) and to unlock it only at the end of step (e) so that the first user does not have access to the digital asset until the second user has collected the first amount.

[0114] Method - case of second fungible tokens vCoin2

[0115] Alternatively or in addition to vCoinl, a second fungible token, denoted vCoin2, can be used. This token is advantageously transferable on the same blockchain and is also a technical token. In other words, each second token again represents a predefined arbitrary value (advantageously the same as the first fungible token, i.e., one vCoinl = one vCoin2 = €1) but cannot be freely exchanged for fiat currency.

[0116] The two types of tokens can be practically equivalent, what will differ is their principle of creation, and in particular their quantity.

[0117] Indeed, with reference to [Fig.2b], in this first variant the process begins directly with a step (aO) of implementation by said server 3 of a transaction on said blockchain-type database of creation for the benefit of the first user of a fourth quantity of a second fungible token transferable in said blockchain-type database, said fourth quantity corresponding to a balance of a bank account of said first user.

[0118] In other words, the fourth quantity is the "mirror" of the first user's bank account: if they have €1456 in their account, then 1456 second tokens will be minted. Thus, as in the first variant, fiat currency and tokens coexist; there is no exchange.

[0119] To rephrase, even before the credit of the transitory account, the money of the first user is "duplicated", which does not pose a problem because the second tokens are not freely exchangeable.

[0120] Note that the first user may have several bank accounts, and we treat it as if he had a single account with a balance equal to the sum of the balances of his different accounts, because fiat money is itself fungible and the money for the transaction may well come from several accounts at once.

[0121] Step (aO), which is equivalent to step (b) of the first variant of the method, can be implemented when the first user registers for the transaction service in accordance with this process, for example by downloading an application onto his first device 1, and in any case before step (a).

[0122] Step (aO) may include a request for access from server 3 (directly or via the first equipment 1) to the first user's account, as it is necessary to know the balance of his account.

[0123] Preferably, the method further includes, where appropriate, one or more occurrences of a step (al) of implementation by said server 3 of a transaction on said blockchain-type database of updating said fourth quantity of the second fungible token of the first user, so as to correspond to the balance of said first user's bank account.

[0124] Indeed, the balance can fluctuate, and by update we mean minting or burning second tokens to adapt to the new balance: if it has increased, new second tokens are minted, and if it has decreased, tokens are burned. But at this stage, no transfer of vCoin2 is possible.

[0125] Step (al) can be implemented via the first equipment 1 which will transmit to the server 3 (in real time or periodically) information relating to the variations in the balance, or the server 3 will itself regularly query the bank account of the first user.

[0126] Technically, for steps (a0) / (al) the AIS (Account Information Service) API or any other technique that allows it.

[0127] Thus, it is assumed that at the end of steps (a0) / (al), the fourth quantity of second tokens of the first user corresponds to the balance of their bank account. This embodiment therefore prevents any overdraft operation since it is physically impossible to obtain, and therefore transfer, a quantity of tokens corresponding to a larger amount in fiat currency.

[0128] Note that these steps can be implemented for each user and not just the first user: the second user can himself, before the transaction, have an amount of vCoins2 corresponding to the balance of his own bank account.

[0129] Then step (a) of issuing from the first equipment 1 of the first user a credit request (i.e. top-up) of the temporary account managed by the server 3, up to a second amount in said fiat currency greater than or equal to said first amount, can take place.

[0130] This step can be implemented under exactly the same conditions as in the first variant of the process, in particular by transfer from the first user's first account once the transaction is required or in advance, or by debit from the first user's account if the trusted third party (operating server 3) has a SEPA-type mandate.

[0131] Step (a) may again include, before or after said crediting of the transitory account, validation of the transaction (i.e. of the first amount and the object of the transaction) by each of the first and second users respectively on the first and second equipment 1, 2; and in particular include authentication of the first user on the first equipment 1 and authentication of the second user on the second equipment 2, so as to confirm the consent of the first and second users to implement said transaction of said first amount in fiat currency.

[0132] It is noted that, as explained, from an accounting point of view, the money transferred to the transitory account always belongs to the first user (if the transaction is ultimately abandoned, he automatically recovers this money, less any fees), so that the money in this transitory account is considered to always be part of the balance of the first user (i.e. the transfer of the second amount does not reduce the fourth quantity of second tokens by the same amount - only any fees are deducted).

[0133] We then proceed directly to step (c) of implementation by said server 3 of a transaction on said blockchain-type transfer database, from the first user to the second user, of a fifth quantity of said second fungible token corresponding to the first amount, and in practice equal to the first quantity of the first fungible token (when the two tokens represent the same value).

[0134] Mathematically, the fourth quantity is greater than the second quantity corresponding to the second amount (since the user could not transfer money they did not have), which is itself greater than the fifth quantity. Therefore, we are assured that the first user's wallet contains at least the fifth quantity, and it can thus be transferred to the second user's wallet. This guarantees the second user that the first user is indeed able to pay them the first amount and creates a record of this transaction in the blockchain. In any case, even if an attacker were to trigger the transaction without having a sufficient balance (with a second amount of money credited to the transitory account that is less than the first amount, or with fraudulently obtained funds in this transitory account), the transfer of the second token would fail because the fifth quantity would not be available.

[0135] If the fourth quantity is greater than the first quantity (for example, if the balance is €1456, 1456 vCoins2 were minted for a transaction of €1000 and 1000 vCoins2 were transferred), then a number of tokens equal to the difference between the first and fourth quantities remains in the first user's wallet (456 vCoins2 here).

[0136] This step (c) can again be implemented via a smart contract.

[0137] At this stage, the money in the transit account is still pending. Therefore, the process similarly includes, as in the first variant, step (d) of server 3 transferring said first amount in said fiat currency from said transit account to an account of the second user. More precisely, it involves transferring an amount in fiat currency corresponding to the quantity of tokens received. This quantity is the first quantity, so the amount to be transferred is indeed the first amount. This provides an additional safeguard against further potential fraud.

[0138] Thus, to return to our example, 1000 vCoins2 were transferred, so that €1000 was transferred from the temporary account to the second user's account. Again, any money transfer method can be used, in particular a simple bank transfer, and where applicable, fees may be charged if borne by the seller (for example, only €999.50 actually transferred to the second bank account).

[0139] At this stage, we could proceed as in the first variant with a step (e) of implementation by said server 3 of a transaction on said blockchain-type database of destruction of said first quantity of the second fungible token transferred to the second user and / or of destruction of the second fungible tokens in excess of the first user, but this is in practice unnecessary, due to the clever nature of the second fungible tokens.

[0140] It is recalled that the quantity of the second fungible token (vCoin2) is a mirror of the account balance: at the next occurrence of step (al), the quantities of the second token of the first and second users will be automatically updated: - the money withdrawn from the temporary account is no longer in the first user's balance, which therefore decreases by the first amount: note that due to step (c) the quantity of second tokens held by the first user has normally already decreased by an equivalent amount - this money is now in the second user's account, whose balance therefore increases by the first amount: we note that due to step (c) the quantity of second tokens has normally already increased in an equivalent manner.

[0141] In summary, at the end of step (d) each of the first and second users normally automatically has the quantity of second tokens corresponding to the balance of their account.

[0142] It is noted that this may be subject to possible costs, but in any case at the next occurrence of step (al), the quantities of second tokens will be corrected accordingly;

[0143] On the other hand, preferably, step (e) always includes, if the second amount is strictly greater than the first amount (or equivalently if the second quantity is strictly greater than the first quantity), the transfer (recredit) by server 3 of the difference between the first and second amounts in said fiat currency (i.e. the remainder) from said transitory account to an account of the first user, always subject to possible charges.

[0144] Alternatively, and particularly in a mode where the temporary account can be loaded in advance, there is no immediate credit, but rather after a given period of time, for example 24 hours, which allows the user to carry out several successive transactions. At the end, the remaining balance, i.e., the difference between all the second amounts and all the first amounts, is credited.

[0145] Finally, step (e) can again include server 3 sending a notification to the second device 2 to inform the second user that the transaction was successful, i.e., that they have received the first amount (less any applicable fees) in their account, without unnecessary costs or risks. Thanks to the second fungible tokens, the transaction is also irrefutably recorded in the blockchain.

[0146] So, the process may include the possible final step (f) of implementation of an action by said second user in consideration of the transaction (of the payment of the first amount) under the same conditions as for the first variant, and in the case where the object of the transaction is a digital asset such as an NFT, step (f) may include the implementation of a transaction on a transfer blockchain-type database (generally different from the blockchain on which the second fungible tokens are transferable), from the second user to the first user, of said digital asset.

[0147] In summary, in the case of the second variant, the process for implementing a transaction of a first amount in fiat currency between a first user and a second user comprises the implementation of the following steps:

[0148] (aO) Implementation by a server 3 of a transaction on a blockchain-type database to create for the benefit of the first user a fourth quantity of a second fungible token transferable in said blockchain-type database, said fourth quantity of said first fungible token corresponding to a balance of a bank account of said first user;

[0149] (al) optionally, if said bank account balance of said first user has changed, implementation by said server 3 of a transaction on said blockchain-type database to update said fourth quantity of the second token fungible of the first user, so as to correspond to the balance of said first user's bank account; a. Issuance from a first piece of equipment 1 of the first user connected to the server 3 by a network 30 of a credit request from a temporary account managed by the server 3, up to a second amount in said fiduciary currency greater than or equal to said first amount (and in practice such that the second quantity corresponding to this second amount is less than or equal to said fourth quantity); a. Implementation by said server 3 of a transaction on said blockchain-type transfer database, from the first user to the second user, of a fifth quantity of said second fungible token corresponding to the first amount; b. Transfer by server 3 of said first amount in said fiat currency from said transitory account to an account of the second user.

[0150] Preferably, as explained, it is possible to combine the first and second tokens for maximum security: - The first tokens are locked and have a very short lifespan, which prevents any fraud - the second tokens are linked to the first user's bank account balance and prevent any attempt at overdraft payment.

[0151] In summary, when these two variants are combined, the process for implementing a transaction of a first amount in fiat currency between a first user and a second user includes the implementation of the following steps:

[0152] (aO) Implementation by a server 3 of a transaction on a blockchain-type database to create for the benefit of the first user a fourth quantity of a second fungible token transferable in said blockchain-type database, said fourth quantity of said first fungible token corresponding to a balance of a bank account of said first user;

[0153] (al) optionally, if said balance of said first user's bank account has changed, implementation by said server 3 of a transaction on said blockchain-type database to update said fourth quantity of the first user's second fungible token, so as to correspond to the balance of said first user's bank account; a. Issuance from a first device 1 of the first user connected to the server 3 by a network 30 of a credit request from a temporary account managed by the server 3, up to a second amount in said fiduciary currency greater than or equal to said first amount; b. Implementation by said server 3 of a transaction on a blockchain-type database to create for the benefit of the first user a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount; c. Implementation by said server 3 of a transaction on said blockchain-type transfer database, from the first user to the second user, of said first quantity of said first fungible token and a fifth quantity of said second fungible token also corresponding to said first amount of said first quantity (preferably in the same transaction); d. Transfer by server 3 of said first amount in said fiat currency from said transitory account to an account of the second user; e. Implementation by said server 3 of a transaction on said blockchain-type database to destroy said first quantity of the fungible token transferred to the second user.

[0154] Server

[0155] According to a second aspect, the invention relates to the server 3 for the implementation of the method according to the first aspect.

[0156] The server 3, of a trusted third party, for fiat currency transactions, includes data processing means 31 and data storage means 32.

[0157] According to the first variant, the data processing means 31 are configured to: - following the issuance from a first device 1 of the first user connected to said server 3 via a network 30 of a request to credit a temporary account managed by said server 3, up to a second amount in said fiat currency greater than or equal to said first amount, implement a transaction on a blockchain-type database to create for the benefit of the first user a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount; - to implement a transaction on said blockchain-type transfer database, from the first user to the second user, of said first quantity of said first fungible token; - transfer said first amount in said fiat currency from said transitory account to an account of the second user; - implement a transaction on said blockchain-type database to destroy said first quantity of the fungible token transferred to the second user.

[0158] According to the second variant, the data processing means 31 are configured to: - to implement a transaction on a blockchain-type database to create, for the benefit of the first user, a fourth quantity of a second fungible token transferable within said blockchain-type database, said fourth quantity of said first fungible token corresponding to a balance in a bank account of said first user - following the issuance from a first device 1 of the first user connected to said server 3 via a network 30 of a credit request to a temporary account managed by said server 3, up to a second amount in said fiat currency greater than or equal to said first amount, implement a transaction on said blockchain-type transfer database, from the first user to the second user, of a fifth quantity of said second fungible token corresponding to the first amount; - transfer said first amount in said fiat currency from said transitory account to an account of the second user.

[0159] According to a third aspect, the invention relates to the entire server 3 according to the second aspect and to at least a first client device 1 of the first user, and advantageously a second client device 2 of the second user, connected via said network 30.

[0160] The first equipment 1 is then configured to issue a credit request from a temporary account managed by said server 3, in the amount of a second amount in said fiat currency greater than or equal to said first amount.

[0161] Computer program product

[0162] 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 31 of the server 3) of a method according to the first aspect for the implementation of a transaction of a first amount in a fiat currency between a first user and a second user; and a storage means (for example the data storage means 32 of the server 3) on which this computer program product is located.

Claims

Demands

1. A method for carrying out a first-amount fiat currency transaction between a first user and a second user, comprising the implementation of the following steps: a. Issuance from a first device (1) of the first user of a credit request from a temporary account managed by a server (3) connected at least to the first device (1) by a network (30), up to a second amount in said fiduciary currency greater than or equal to said first amount; b. Implementation by said server (3) of a transaction on a blockchain-type database of creation for the benefit of the first user of a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount; c. Implementation by said server (3) of a transaction on said blockchain-type transfer database, from the first user to the second user, of said first quantity of said first fungible token; d. Transfer by the server (3) of said first amount in said fiat currency from said transitory account to an account of the second user; e. Implementation by said server (3) of a transaction on said blockchain-type database of destruction of said first quantity of the fungible token transferred to the second user.

2. A method according to claim 1, wherein step (a) comprises the authentication of the first user on the first equipment (1) and the authentication of the second user on a second equipment (2) of the second user also connected to the first equipment (1) via said network (30), so as to confirm the consent of the first and second users to implement said transaction of said first amount in fiat currency.

3. A method according to any one of claims 1 and 2, wherein said request to credit a transitory account managed by the server (3) is either a request to transfer said second amount in fiat currency from a bank account of the first user to said transitory account, or a request to debit said server (3) from said second amount from said bank account of the first user.

4. A method according to claims 2 and 3 in combination wherein either the issuance of said credit request is triggered by the authentications of the first and second users and the second amount is equal to the first amount, or the issuance of said credit request is implemented in advance and step (b) is triggered by the authentications of the first and second users.

5. A method according to any one of claims 1 to 4, wherein the third quantity is equal to the second quantity.

6. A method according to any one of claims 1 to 5, wherein step (e) further comprises, if the second amount is strictly greater than the first amount, the transfer by the server (3) of the difference between the first and second amounts in said fiat currency from said transitory account to an account of the first user.

7. A method according to any one of claims 1 to 6, wherein said first fungible tokens are locked tokens for the first and second users.

8. A method according to any one of claims 1 to 7, comprising a step (aO) of implementation by said server (3) of a transaction on said blockchain-type database creating for the benefit of the first user a fourth quantity of a second fungible token transferable in said blockchain-type database, said fourth quantity corresponding to a balance of a bank account of said first user; step (c) comprising implementation by said server (3) of a transaction on said blockchain-type database transferring, from the first user to the second user, a fifth quantity of said second fungible token corresponding to the first amount.

9. A method according to claim 8, comprising, if said bank account balance of said first user has changed, a step (a1) of implementing by said server (3) a transaction on said basis of blockchain-type data updating said fourth quantity of the second fungible token of the first user, so as to match the balance of said first user's bank account.

10. A method according to any one of claims 8 and 9, wherein step (aO) comprises a request from server (3) to access said bank account of the first user.

11. A method according to any one of claims 8 to 10, wherein said first fungible token and said second fungible token represent the same value in said fiat currency such that the first quantity of the first fungible token is equal to the fifth quantity of the second fungible token.

12. A method according to any one of claims 1 to 11, wherein at least steps (b), (c) and (e) are implemented by means of a smart contract.

13. A method according to any one of claims 1 to 11, comprising the implementation of a step (f) of implementation of an action by said second user in consideration of the transaction.

14. Server (3), characterized in that it comprises data processing means (31) configured to, during a transaction of a first amount in a fiat currency between a first user and a second user: - following the issuance from a first device (1) of the first user connected to said server (3) by a network (30) of a request to credit a temporary account managed by said server (3), up to a second amount in said fiat currency greater than or equal to said first amount, implement a transaction on a blockchain-type database to create for the benefit of the first user a third quantity of a first fungible token transferable in said blockchain-type database, said third quantity of said first fungible token being between a first quantity corresponding to said first amount and a second quantity corresponding to said second amount;- to implement a transaction on said blockchain-type transfer database, from the first user to the second user, of said first quantity of said first fungible token; - to transfer said first amount in said fiat currency from said transitory account to an account of the second user; - implement a transaction on said blockchain-type database to destroy said first quantity of the fungible token transferred to the second user.

15. The server (3) according to claim 14 and the first piece of equipment (1) configured to issue said credit request from a transitory account managed by said server (3), up to the second amount.

16. Product computer program comprising code instructions for carrying out a method according to any one of claims 1 to 13 for carrying out a transaction of a first amount in a fiat currency between a first user and a second user, when said program is executed on a computer.

17. Computer-readable storage means on which is recorded a computer program product comprising code instructions for the execution of a process according to any one of claims 1 to 13 for the implementation of a transaction of a first amount in a fiat currency between a first user and a second user.

Images