A method of exchanging non-fungible tokens on a blockchain

Abstract

The invention relates to a method which provides: the recording by a user (1), in an exchange vault (35), of lists (n, m) each comprising the identifier of at least one non-fungible token which he wishes to exchange and acquire respectively, associated with the digital address (39a, 40) of the vault (10a, 11) for managing said token; the sending of the lists (m, n) and the address (36) of the exchange vault (35) to the vault (11) for managing the desired non-fungible token;approval of the exchange by the user (2) possessing the desired token, by associating with his unique identifier the address (36) of the exchange vault (35) and an exchange authorization status, and by sending a notification (52) to the exchange vault (35), the exchange vault (35) recording, in the corresponding vault (10a, 11), the user (1) as the new owner of the token obtained by the exchange and the user (2) as the new owner of the token exchanged with the first user (1). Figure 1b;

Description

Title of the invention: Method for exchanging non-fungible tokens on a blockchain

[0001] The invention relates to a method for enabling two users to exchange non-fungible tokens on a blockchain, as well as an architecture comprising means for implementing such a method.

[0002] Non-fungible tokens correspond to digital representations of goods on a blockchain, similar to a title of ownership of said goods. These goods can be physical objects, such as for example works of art or real estate, digital elements, such as for example images or photographs, or even mixed elements, in particular objects connected to the Internet® (IoT, for the English “Internet of Things”).

[0003] Such a representation allows the owner of such a good to exchange or sell it to another user present on the blockchain in a secure manner, by transmitting this digital representation in parallel with that of said good, in particular against a sum in scriptural currency or in cryptocurrency. Indeed, since the duplication of a non-fungible token is impossible, this procedure makes it possible to cancel the risk of counterfeiting of the title of ownership.

[0004] Known architectures for exchanging goods and non-fungible tokens on a blockchain are generally based on online trading platforms, which represents a significant risk of fraud. In particular, they do not provide complete satisfaction either for the protection of the creator of the goods sold or for their buyers, who do not have sufficient guarantees as to the identity of said creator, the authenticity of the works sold, or the honesty of the intermediary parties in a sale.

[0005] Furthermore, with existing solutions, users acquire non-fungible tokens by paying an amount in fiat or cryptographic currency directly to their owner and, to the extent that these transactions are recorded on the blockchain, this amount can be read by users other than the parties to the initial transaction, especially when said blockchain is public. Thus, a problem arises with regard to the confidentiality of this transaction, the buyer and / or seller of which may wish to keep the amount secret to preserve their privacy or the confidentiality of their professional activities.

[0006] The invention aims to improve the prior art by proposing in particular a method for allowing users to exchange non-fungible tokens on a blockchain via an integrated sales system which makes it possible to free oneself from platforms of classic online commerce, said system also allowing these exchanges to be carried out while avoiding direct transfers of fiat or cryptographic currency between said users, while simplifying the monitoring of said exchanges in the case where they concern several non-fungible tokens at the same time.

[0007] To this end, according to a first aspect, the invention proposes a method for enabling two users to exchange non-fungible tokens on a blockchain, said method providing beforehand: - when creating a non-fungible token, recording information related to said non-fungible token in a digital token management vault on the blockchain, associating it with a unique identifier for said non-fungible token; - when a user acquires a non-fungible token, the recording, in the digital safe for managing said non-fungible token, of a digital address of said user on the blockchain, as the owner of said non-fungible token;

[0008] said method further providing, when a first user wishes to exchange non-fungible tokens with a second user on the blockchain: - the selection by the first user of at least one non-fungible token to be exchanged, from among the non-fungible tokens that he owns on the blockchain, by associating with the unique identifier of said non-fungible token to be exchanged, recorded in the corresponding digital management safe: • a digital address of a digital safe present on the blockchain to manage the exchanges of non-fungible tokens between users on said blockchain; • an exchange authorization status for said non-fungible token; - the registration by the first user, in the exchange vault, of an exchange proposal including: • a first list m comprising the unique identifier of at least one non-fungible token that it wishes to exchange, associated with the digital address of the management safe of said non-fungible token to be exchanged; • a second list n comprising the unique identifier of at least one non-fungible token of the second user that said first user wishes to acquire via said exchange, associated with the digital address of the management safe of said desired non-fungible token; - the sending by the first user, to the management safe of the desired non-fungible token, of a notification including the lists m, n, as well as the digital address of the exchange safe; - verification by the second user of the exchange proposal recorded in the exchange vault; - verification by the second user in the management safe of the non-fungible token to be exchanged: • the registered exchange authorization status for said non-fungible token to be exchanged; • the association of the digital address of the exchange vault with the unique identifier of said non-fungible token to be exchanged; - if these checks are successful, approval by the second user of this exchange proposal: • by associating with the unique identifier of the desired non-fungible token, recorded in the corresponding management vault: • the digital address of the exchange vault; • an exchange authorization status of said desired non-fungible token; • by sending to the exchange vault a notification of approval of said exchange proposal; - the recording, by the exchange safe, of: • the digital address of the first user in the digital safe for managing the non-fungible token obtained from the second user, by associating it with the unique identifier of said non-fungible token obtained, in order to designate said first user as the new owner of said non-fungible token obtained; • the digital address of the second user in the digital safe for managing the non-fungible token exchanged with the first user, by associating it with the unique identifier of said non-fungible token exchanged, in order to designate said second user as the new owner of said non-fungible token exchanged.

[0009] According to a second aspect, the invention proposes an architecture for allowing two users to exchange non-fungible tokens on a blockchain, said architecture comprising: - at least one digital safe for managing non-fungible tokens on the blockchain, in which are recorded: • when creating a non-fungible token, information linked to said non-fungible token, being associated with a unique identifier for said non-fungible token; • when a user acquires a non-fungible token managed by means of said token management vault, a digital address of said user on the blockchain, as the owner of said non-fungible token; a digital vault to manage the exchange of non-fungible tokens between users on said blockchain; a first terminal comprising means for enabling a first user wishing to exchange non-fungible tokens with a second user on the blockchain to: • select at least one non-fungible token to exchange, from among the non-fungible tokens that it owns on the blockchain, by associating with the unique identifier of said non-fungible token to exchange, recorded in the corresponding digital management safe: • a digital address on the blockchain of the digital vault of non-fungible token exchanges; • an exchange authorization status for said non-fungible token; • save an exchange proposal in the exchange vault including: • a first list m comprising the unique identifier of at least one non-fungible token that it wishes to exchange, associated with the digital address of the management safe of said non-fungible token to be exchanged; • a second list n comprising the unique identifier of at least one non-fungible token of the second user that said first user wishes to acquire via said exchange, associated with the digital address of the management safe of said desired non-fungible token; • send, to the management vault of the desired non-fungible token, a notification including the lists m, n, as well as the digital address of the exchange vault; a second terminal comprising means to enable the second user to: • check the exchange proposal recorded in the exchange vault; • check, in the management safe of the non-fungible token to be exchanged: • the registered exchange authorization status for said non-fungible token to be exchanged; • the association of the digital address of the exchange vault with the unique identifier of said non-fungible token to be exchanged; • if these checks are successful, approve this exchange proposal: • by associating with the unique identifier of the desired non-fungible token, recorded in the corresponding management vault: • the digital address of the exchange vault; • an exchange authorization status of said desired non-fungible token; • by sending to the exchange vault a notification of approval of said exchange proposal;

[0010] the exchange safe comprising means for recording, at the end of this exchange: - the digital address of the first user in the digital safe for managing the non-fungible token obtained from the second user, by associating it with the unique identifier of said non-fungible token obtained, in order to designate said first user as the new owner of said non-fungible token obtained; - the digital address of the second user in the digital safe for managing the non-fungible token exchanged with the first user, by associating it with the unique identifier of said non-fungible token exchanged, in order to designate said second user as the new owner of said non-fungible token exchanged.

[0011] Other features and advantages of the invention will appear in the following description, given with reference to the appended figures, in which:

[0012] [Fig.la] and

[0013] [Fig. 1b] schematically represent the different stages of exchange of non-fungible tokens between two users on a blockchain, from the point of view respectively of a first user issuing an exchange proposal ([Fig.la]) and of a second user accepting this exchange proposal ([Fig.lb]), according to a method according to the invention;

[0014] [Fig.2a],

[0015] [Fig.2b] and

[0016] [Fig.2c] schematically represent the different stages to enable the first user to purchase a digital voucher in the form of a non- fungible to be exchanged subsequently with a second user, respectively according to an alternative embodiment of the invention;

[0017] [Fig.3a] and

[0018] [Fig.3b] schematically represent the different stages of exchange of non-fungible tokens, including a digital voucher, between two users on a blockchain, from the point of view respectively of a first user issuing an exchange proposal containing a digital voucher ([Fig.3a]) and of a second user accepting this exchange proposal ([Fig.3b]), according to a method according to the invention;

[0019] [Fig.4] schematically represents the steps allowing the second user to verify the monetary value of a digital voucher that the first user proposes to exchange with him, according to one embodiment of the invention;

[0020] [Fig.5] schematically represents the steps allowing the second user to obtain a monetary refund from the digital voucher exchanged with the first user in the preceding figures, according to one embodiment of the invention.

[0021] In relation to these figures, a method is described below for enabling two users 1, 2 to exchange non-fungible tokens on a blockchain, as well as an architecture comprising technical means for enabling the implementation of such a method.

[0022] The architecture comprises a platform 3 linked to the blockchain, which comprises an application programming interface (API) activating the technical means for receiving requests from creators and users 1, 2 connected to the blockchain, the latter being formed by a set of communication and calculation platforms allowing its operation, and serving as means of access to said blockchain.

[0023] The architecture further comprises a first 4 and a second terminal 5 each equipped with means to allow respectively a first 1 and a second user 2 to interact with the blockchain and / or the platform 3, in particular to send requests such as those mentioned above.

[0024] As shown in the figures, the terminals 4, 5 may be mobile phones of the “smartphone” type. The terminals 4, 5 may also be of another type, in particular a digital tablet, a personal digital assistant (PDA), a laptop or a desktop computer, provided that they are equipped with technical means suitable for implementing the method.

[0025] In particular, the architecture may comprise at least one application with means adapted for implementing the method, which each user 1, 2 may download to install it on your terminal 4, 5, in particular by sending a request adapted to said architecture.

[0026] To be able to interact with the blockchain, each user 1, 2 must generate a pair of private and public keys (not shown), in particular when first connecting to said blockchain and in the event of loss or theft of his previous keys. The private key is kept secret by its owner (first 1 or second user 2) and the public key allows said owner to interact with the blockchain to carry out operations there. In particular, a personal digital address is derivable from the public key to represent its owner 1, 2 on the blockchain.

[0027] To generate such keys, the user 1, 2 can launch a suitable procedure on his terminal 4, 5 in particular by means of the application described previously. The keys are thus linked to the terminal 4, 5 within which they are generated under the control of the user 1, 2, who only uses the public key. As a result, the private key never leaves the terminal 4, 5, which guarantees its owner 1, 2 optimal security.

[0028] To finalize or update his membership in the blockchain, user 1, 2 registers his public key on said blockchain. In particular, user 1, 2 can carry out this registration by associating his public key with a digital fingerprint linked to the identity of said user.

[0029] To do this, the user 1, 2 can authenticate his identity with a third-party platform (not shown), in order to create a digital fingerprint using identity data provided by said third-party platform, said digital fingerprint then being recorded on the blockchain to be associated with the public key linked to the terminal 4, 5 of said user.

[0030] The third-party platform has a trust level that can be assessed under the elDAS (Electronic IDentification And Trust Services) regulation or any other identity-based trust assessment system, and may be, for example, a platform for providing a public and / or administrative identification service such as social security, a service for paying official taxes such as income taxes, or any other identification service that achieves the elDAS trust level required by users, or any other system providing an identity, for example, a system for identifying employees of a company. In particular, the third-party platform may provide a unique identifier for the user 1, 2, in particular based on the identity data.

[0031] This recording can in particular be carried out in a personal digital safe 6, 7 held by the user 1, 2 on the blockchain, as shown in the figures, in relation to the keys linked to the terminal 4, 5 of said user.

[0032] The user 1, 2 can create such a personal safe 6, 7 to be able to subsequently interact with the blockchain only by means of the digital address 8, 9 of said personal safe, which allows said user to record several public keys in the same personal safe 6, 7 and to access the blockchain with any of said keys, and therefore to avoid the loss of his access to the blockchain in the event of loss and / or theft of his keys and / or his terminal 4, 5.

[0033] To do this, the architecture comprises a platform for deploying safes on the blockchain, the terminal 4, 5 and / or the application comprising means for requesting said deployment platform to create a personal safe 6, 7, in particular by sending a suitable request (not shown).

[0034] Advantageously, this functionality is carried out by the platform 3 for accessing the blockchain, which comprises technical means adapted to carry out the deployment of safes 6, 7 at the request of any user 1, 2 present on said blockchain. Alternatively, the architecture may comprise an additional platform for deploying safes which is distinct from the platform 3 for accessing the blockchain.

[0035] All digital safes in the architecture can be created in the form of computer protocols of the smart contract type, which are accessible on the blockchain by means of a public digital address.

[0036] The deployment platform 3 comprises an application programming interface (API), which comprises technical means adapted to enable the creation of safes on the blockchain.

[0037] Advantageously, the deployment platform 3 is arranged to allow the automatic creation of digital safes upon simple request from a user 1, 2. To this end, the architecture may comprise (not shown in the figures): - a digital safe linked to the deployment platform 3, in which at least one identifier of said deployment platform on the blockchain is recorded, for example a digital address derived from a public access key of said platform to said blockchain; - a central digital safe, which includes in particular: • a list of the safe deployment platforms belonging to a trusted network, said list including the digital addresses of the safes linked to each of these trusted platforms, in particular the digital address of the safe linked to the platform 3 represented; and • a list of all digital safes created by these trusted platforms on the blockchain, said list comprising entries which each contain the digital address of a safe created by a deployment platform, associated with the digital address of the safe linked to this deployment platform, and in particular an entry comprising the address 8, 9 of the personal safe 6, 7 of user 1, 2, associated with the digital address of the safe linked to platform 3.

[0038] Alternatively, the deployment platform 3 can be arranged to allow the creation of digital safes by an administrator of the blockchain, in particular following the receipt of a solicitation request by a user 1, 2.

[0039] After creating his personal digital safe 6, 7, the user 1, 2 can authenticate his identity with the third-party platform described previously, in order to create a digital fingerprint using identity data provided by said third-party platform, said digital fingerprint then being recorded in said personal digital safe by the deployment platform 3.

[0040] At the end of this registration, the deployment platform 3 sends to the user 1, 2 a notification containing the public digital address 8, 9 of his personal safe 6, 7, so that said user can access said personal safe by means of said digital address.

[0041] To enable users 1, 2 to exchange non-fungible tokens on the blockchain, the method provides beforehand, when creating a non-fungible token on said blockchain, the recording of information linked to said non-fungible token in a digital safe 10a, 10b, 11 for managing tokens on said blockchain, by associating it with a unique identifier i, j for said non-fungible token.

[0042] To do this, the architecture comprises at least one digital safe 10a, 10b, 11 for managing non-fungible tokens on a blockchain, in which is recorded, during the creation of a non-fungible token on the blockchain, information linked to said non-fungible token, being associated with a unique identifier i, j as defined above.

[0043] Non-fungible tokens may correspond to digital representations of goods on a blockchain, similar to a title of ownership of said goods, which may be, for example: - physical objects, such as for example works of art or real estate; or - digital elements, such as for example images or photographs; or - mixed elements, including objects connected to the Internet® (IoT, for the English “Internet of Things”).

[0044] In particular, a user wishing to create such non-fungible tokens on the blockchain may request the creation of a digital safe 10a, 11 specific to him, as creator of non-fungible tokens on said blockchain, in order to allow him to manage his creations by means of said digital safe.

[0045] To do this, as explained previously in connection with the personal safes 6, 7, a “creator” user can, using suitable means or applications installed on his / her blockchain access terminal, request a deployment platform present on said blockchain, in particular the platform 3 shown in the figures, in order to create such a digital safe 10a, 11 for the management of his / her non-fungible tokens.

[0046] Advantageously, the platform 3 creates such a management safe 10a, 11 in the form of a smart contract with functionalities adapted to allow a “creator” user to easily manage his non-fungible tokens, including: - monitoring of updates to the characteristics of its non-fungible tokens, in order to provide said “creator” user with better visibility of said updates; - the ability to sell or exchange non-fungible tokens with other blockchain users by establishing a direct “peer-to-peer” relationship, without resorting to an intermediary online trading platform; - tracking the logistics of the goods corresponding to the non-fungible tokens.

[0047] In particular, the architecture may comprise a directory server (not shown in the figures), which comprises at least one database for recording digital files linked to non-fungible tokens of at least one “creator” user on the blockchain, said files being able to be, for example, images or photographs representing a “material” good to which a non-fungible token corresponds.

[0048] Furthermore, when creating a digital safe 10a, 11 to manage the non-fungible tokens of a “creator” user, the platform 3 can record in said management safe, in particular among immutable variables of said management safe: - a digital address on the blockchain of the directory server, in order to allow said “creator” user to manage his non-fungible tokens by means of said directory server and its management vault 10a, 11; - possibly, an alternative digital address for accessing the directory server on the blockchain, particularly in the event of failure of the main address of said directory server.

[0049] These digital addresses can be in the form of alphanumeric interactive links of the URI (Uniform Resource Identifier) ​​type, and cannot be modified, because they make it possible to certify the identity of the initial creator of a non-fungible token referenced in the server, even after the session of said non-fungible token to another user 1, 2 of the blockchain.

[0050] Furthermore, each non-fungible token management safe 10a, 11 linked to a “creator” user contains, in its list of immutable parameters, the digital address of the personal digital safe of said “creator” user on the blockchain, as owner of said management safe.

[0051] When creating a non-fungible token of the “good” type as mentioned above, the method provides, using suitable means or applications installed on the terminal of its creator, to: - calculate a hash tree, for example a Merkle tree, from the non-fungible token itself or from a digital file linked to said non-fungible token, for example a photograph or an electronic image of said non-fungible token if it is a material good; - record this hash tree in the management safe 10a, 11 belonging to said creator, as information linked to said non-fungible token, by associating it with a unique identifier i, j for said non-fungible token.

[0052] Furthermore, other information on the non-fungible token may be recorded by the “creator” user in the management safe 10a, 11, at the time of creation of said non-fungible token or subsequently, including: - a status to authorize the sale and / or exchange of said non-fungible token; and / or - in the case of a sale of said token for an amount in cryptocurrency or fiat currency, information relating to the remuneration to be paid to said “creator” user, in particular: • in the case of a first sale made by the “creator” user himself with another user 1, 2: a monetary amount to be paid to said “creator” user; or • in the case of a subsequent sale made by a user 1, 2 other than said “creator” to another user 2, 1: a rational value of remuneration to be paid to said “creator”, deducted from the total monetary amount set by user 1, 2 reseller of said non-fungible token.

[0053] The method further provides, when a user 1, 2 acquires a non-fungible token, the recording, in the digital safe 10a, 11 for managing said non-fungible token, of a digital address 8, 9 of said user on the blockchain, as owner of said non-fungible token.

[0054] In the case where the user is the creator of the non-fungible token, it is considered that said user acquires said non-fungible token at the time of its creation, and the digital address of the personal safe of said creator is recorded in the management safe 10a, 11 linked to said creator, being associated with the unique identifier of said non-fungible token to designate said creator as the owner.

[0055] In the case where the user 1, 2 is not the creator of the non-fungible token, the method provides for recording the digital address 8, 9 of the personal safe 6, 7 of said user in the management safe 10a, 11 of said token at the time of the transfer of said token by its creator to said user, by associating said digital address with the unique identifier of said token, in order to designate said user as the new owner of said token.

[0056] Non-fungible tokens can also be in the form of digital vouchers, which a first user 1 can purchase in advance to later exchange with a second user 2 on the blockchain.

[0057] To do this, as shown in Figures 2a to 2c, 3a, 3b, 4 and 5, the architecture comprises a server 12 linked to the blockchain for providing such purchase vouchers to users 1, 2 of said blockchain.

[0058] In this case, the server 12 can be likened to a “creator” of non-fungible tokens on the blockchain, and can therefore have: - a “personal” digital safe 14 linked to it, in which a public key 13b representing said server 12 on the blockchain can be recorded, and linked to a private cryptographic signature key 13a which is recorded and kept secret within a memory in said server; - a digital safe 10b for managing non-fungible tokens of the “digital voucher” type that it creates for users 1, 2 on the blockchain, in response to requests sent by said users, and in which is recorded the public key 13b of said server (as shown) and / or the digital address 15 of its “personal” safe 14 on the blockchain.

[0059] To carry out the purchase of such a non-fungible token / digital voucher, the method firstly provides for the sending by the first user 1 of a request 16 to the server 12 for supplying digital vouchers, said request comprising information on a monetary amount that said first user wishes to allocate. digital voucher audit. In particular, server 12 is under the control of an organization authorized to receive, store and send digital currency.

[0060] To do this, as shown in Figures 2a to 2c, the first terminal 4 comprises means, in particular in the form of a programming interface 22 (API) integrated into said terminal or into the application installed therein, to allow the first user 1 to make such a purchase, by first sending a request 16 as mentioned above. In particular, this request includes not only information on the monetary amount to be allocated to the requested digital voucher, but also the digital address 8 of the personal safe 6 of the first user 1 on the blockchain.

[0061] After sending the request 16, and its successful reception by the server 12 using suitable means installed in said server, the method provides: - the creation by the server 12 of a digital voucher corresponding to the needs of the user 1, in the digital safe 10b assigned to said server on the blockchain to manage the vouchers that it creates, by assigning it a unique identifier j and a monetary value corresponding to the amount information communicated in the request 16; - sending by the first user 1 of the required monetary amount, corresponding to the information communicated in the request 16, to a payment server 17 linked to the blockchain; - the recording by the voucher server 12, in the voucher management safe 10b, of the digital address 8 of said first user on the blockchain, as the owner of said voucher.

[0062] To do this, the server 12 comprises means for, upon receipt of the request 16, sending to its management safe 10b a notification 18 to create there the purchase voucher required by the first user 1, by assigning to it the unique identifier j and the monetary value mentioned above. In particular, upon creation of the purchase voucher, the server 12 associates with it in the safe 10b the digital address 15 of its “personal” safe 14 on the blockchain, as the provisional owner of said purchase voucher, pending payment of the monetary amount required by the first user 1.

[0063] Advantageously, the server 12 comprises certified programming interfaces (APIs), in particular downloadable from the platform 3, to be able to carry out all the operations necessary for the provision of vouchers to users 1, 2 who request them on the blockchain. Thus, the risks of theft of a voucher by a user other than the one who requested its creation are prevented.

[0064] In particular, after creation of the purchase voucher, the server 12 enters in the management safe 10b, by associating it with the unique identifier j of said purchase voucher, the digital address 8 of the first user 1, as a person authorized to consult the information relating to said purchase voucher in the safe 10b, in order to be able to verify them before paying the required monetary amount.

[0065] In Figures 2a and 2b, the architecture comprises a payment server 17 which is separate from the voucher supply server 12, the first user 1 sending the required monetary amount to the payment server 17, by means of a payment card ([Fig.2a]) or a bank transfer ([Fig.2b]).

[0066] During a payment by card ([Fig.2a]), after receiving the request 16, the voucher server 12 sends the payment server 17 a connection request 19, in particular by means of a digital address communicated in the request 16 to access said payment server, and the payment server 17 responds with a notification 20 containing a link and / or a payment identification number for the transaction in progress.

[0067] Upon receipt of notification 20, the server 12, after having created the required purchase voucher in the safe 10b (via notification 18), sends to the first terminal 4 a notification 21 containing: - the payment link to server 17; - a hash imprint of the voucher created in the safe 10b in response to the request 16 of the first user 1; - information on the monetary amount required, which corresponds to the amount information communicated in request 16.

[0068] From this notification 21, the first terminal 4, in particular via the programming interface 22 installed there, connects to the safe 10b to be able to check the purchase voucher recorded there, then launches a procedure 23 to connect to the payment server 17, by means of the payment link communicated in the notification 21, in order to be able to send to said payment server the monetary amount required for the purchase of the voucher, and corresponding to the information communicated in the request 16 and recalled in the notification 21.

[0069] In particular, the procedure 23 provides for displaying on the first terminal 4 a conventional card payment interface, in which the first user 1 must fill in several fields, for example to enter the number of his payment card, its expiry date and his cryptographic number, then authenticate himself with the payment server 17, for example by entering a secret code to authorize the payment.

[0070] At the end of this procedure 23, the first terminal 4 sends to the voucher server 12 a transfer request 24 containing the payment identifier linked to the transaction in progress, and if necessary restarts a procedure 25 called “polling” to regularly connect to the payment server 17, until the payment of the required monetary amount is correctly made.

[0071] The server 12 then sends to the payment server 17 a request 26 to verify the receipt of the payment, by the first user 1, of the required monetary amount then, if so: - records in the voucher management safe 10b, via a notification 27, the digital address 8 of the first user 1 as the new owner of the voucher, by associating this digital address 8 with the unique identifier j of said voucher; - sends to the first terminal 4 a notification 28 to inform the first user 1 of the transfer of ownership of the voucher that he requested.

[0072] During a payment by bank transfer ([Fig.2b]), after receiving the request 16, the voucher server 12 sends a notification 18 as described previously to create the required voucher in its management safe 10b, associating with it a unique identifier j, the required monetary value and the digital address 15 of its “personal” safe 14, then sends to the payment server 17 a connection request 29, in particular via a payment security protocol defined by an authority such as the European Directive relating to Payment Services (DSP2).

[0073] Upon receipt of this request 29, the payment server 17: - launches a payment procedure 31, following a protocol as described previously, with a banking establishment 30 of which the first user 1 is a client, during which said first user authenticates himself with said banking establishment to initiate, to said payment server, a transfer corresponding to the monetary amount required for the purchase voucher; then - in case of confirmation of the initiation of this transfer, sends to the voucher supply server 12 an appropriate notification 32.

[0074] Upon receipt of notification 32, the server 12, as described previously in relation to [Fig.2a] (card payment): - records in the voucher management safe 10b, via a notification 27, the digital address 8 of the first user 1 as the new owner of the voucher, by associating this digital address 8 with the unique identifier j of said voucher; - sends to the first terminal 4 a notification 28 to inform the first user 1 of the transfer of ownership of the voucher that he requested.

[0075] Then, the banking establishment 30 can execute the initiated transfer by sending a suitable notification 33 to the server 12, immediately or deferred, according to the terms defined by the first user 1 when initiating said transfer.

[0076] [Fig.2c] represents an alternative embodiment of the invention, in which the banking establishment 30 of which the first user 1 is a customer offers a service for supplying digital vouchers, and for this purpose uses a suitable server 12 linked to the blockchain. In this case, the payment server 17 and this server 12 for supplying vouchers are merged, and the first user 1 interacts directly with this single server 12, 17 both to create a voucher and to pay the corresponding monetary amount.

[0077] Thus, after receiving the request 16 from the first user 1, the server 12 successively performs the following steps: - sending to his management safe 10b a notification 18 to create the required purchase voucher, associating with it the unique identifier], the monetary value corresponding to the information communicated in the request 16, as well as the digital address 15 of his “personal” safe 14 to identify him as the provisional owner of said purchase voucher; - sending to the first terminal 4 an authentication request 34 to the first user 1, in order to initiate a transfer corresponding to the monetary amount required for the purchase voucher.

[0078] In the event of confirmation of the initiation of this transfer, the first terminal 4 sends to the server 12 an adapted notification 32', then to the server 12, as described previously: - records in the voucher management safe 10b, via a notification 27, the digital address 8 of the first user 1 as the new owner of the voucher, by associating this digital address 8 with the unique identifier of said voucher; - sends to the first terminal 4 a notification 28 to inform the first user 1 of the transfer of ownership of the voucher that he requested.

[0079] Finally, in a similar manner to the embodiment shown in [Fig.2b] (payment by bank transfer), the banking establishment 30 of the first user 1 executes the transfer within it via an adapted notification 33, immediately or deferred.

[0080] In the three embodiments shown, the first user 1 can authenticate himself with the payment server 17 and / or his banking establishment 30 by means of data relating to his banking identity previously recorded in his personal digital safe 6 on the blockchain, in order to facilitate the authentication operations of said first user when he purchases digital vouchers on said blockchain.

[0081] To enable users 1, 2 of the blockchain to exchange non-fungible tokens, the architecture includes a digital safe 35 specially dedicated to managing such exchanges on the blockchain.

[0082] The safe 35 can be created by an administrator in charge of managing the server 12, and in particular by interaction with the platform 3 for providing digital safes described above. In this case, the respective digital addresses of the “personal” safes linked to the platform 3 and to the server 12 can be recorded in the immutable parameters of the exchange management safe 35, as parent addresses of said exchange management safe.

[0083] The method firstly provides, when the first user 1 wishes to exchange non-fungible tokens with a second user 2 on the blockchain, the selection by said first user of at least one non-fungible token to exchange, from among those which he possesses on the blockchain.

[0084] To do this, the first user 1 must associate with the unique identifier j of the non-fungible token to be exchanged, recorded in the corresponding digital safe 10a, 10b for managing non-fungible tokens: - a digital address 36 of the digital safe 35 present on the blockchain to manage the exchanges of non-fungible tokens between users 1, 2 on said blockchain; - an exchange authorization status for said non-fungible token.

[0085] In relation to figures 1a and 3a, the first terminal 4 comprises suitable means, in particular integrated into an application which has been previously installed there, to allow the first user 1 to select, from among the non-fungible tokens which he possesses, those which he wishes to exchange with the second user 2.

[0086] To do this, the first terminal 4 (or the application installed therein) sends a suitable request 37, 37' on the blockchain, in order to carry out the requested registrations in the token management safe(s) 10a, 10b in which the non-fungible token(s) that it wishes to exchange is / are referenced.

[0087] In the case where the non-fungible token to be exchanged has been created by a human user on the blockchain, for example the first user 1 himself or another user of said blockchain, and corresponds in particular to a material, real estate or digital “good”, the first terminal 4 sends the request 37 directly to the safe 10a for managing said non-fungible token ([Fig. 1a]), in order to enter the required information therein (digital address 36 of the exchange safe 35 and exchange authorization status) by associating them with the unique identifier j of said non-fungible token.

[0088] In the case where the first user 1 selects a digital voucher that he possesses as a non-fungible token to exchange with the second user 2, said first user associates, by means of the first terminal 4, the required information (digital address 36 of the exchange safe 35 and exchange authorization status) with the unique identifier j of said voucher recorded in the corresponding digital voucher management safe 10b.

[0089] To do this, as shown in [Fig.3a], the first terminal 4 sends a request 37' as described above to the server 12 for managing digital vouchers, said server 12 interacting with the digital safe 10b for managing vouchers in which the information and the unique identifier j linked to the voucher to be exchanged are recorded, in particular via a suitable notification 37”, in order to associate with said unique identifier the information required to enable this exchange (digital address 36 of the exchange safe 35 and exchange authorization status).

[0090] After the first user 1 has selected the non-fungible token(s) that he wishes to exchange with a second user 2, the method provides for the recording by the first user 1 in the exchange safe 35, in particular using specific means installed on the first terminal 4 or the application installed therein, of an exchange proposal comprising: - a first list m comprising the unique identifier j of at least one non-fungible token that he wishes to exchange, associated with the digital address 39a, 39b of the safe 10a, 10b for managing said non-fungible token to be exchanged; - a second list n comprising the unique identifier i of at least one non-fungible token of the second user 2 that said first user wishes to acquire via said exchange, associated with the digital address 40 of the safe 11 for managing said desired non-fungible token.

[0091] To do this, as shown in figures 1a and 3a, the first user 1 sends to the exchange safe 35, by means of the first terminal 4, a notification 38 comprising the lists m, n, in order to record these lists m, n in said exchange safe, as an exchange proposal intended for the second user 2.

[0092] Advantageously, the first terminal 4 comprises means for calculating a digital fingerprint of the lists m, n, in particular by means of an appropriate hashing application which is integrated into said first terminal or implemented in the form of a programming interface (API) in the general application previously described, then for sending this fingerprint with said lists in the notification 38 addressed to the exchange safe 35.

[0093] Similarly, the exchange safe 35 comprises means for calculating a digital fingerprint of the lists m, n and comparing it with the communicated fingerprint. in notification 38, in order to only record the exchange proposal in the event of a match between these two fingerprints.

[0094] At the end, in particular in the case of exchanges of non-fungible tokens created directly by the user(s) 1, 2, the first user 1 initiating the exchange can send to the exchange safe 35 a request 41 to verify an initiation status of this exchange proposal, as well as the conformity of the digital addresses of the management safes 10a, 10b, 11 and the identifiers of the non-fungible tokens concerned.

[0095] In the case where the first list m of non-fungible tokens that the first user 1 wishes to exchange contains at least one digital voucher, the method provides that said first user records in the exchange safe 35, with suitable means installed in the first terminal 4 (or in the application installed therein), this first list m comprising the unique identifier j of said voucher, associated with the digital address 39b of the corresponding digital voucher management safe 10b.

[0096] In parallel, the method provides for the sending by the first user 1, using means installed for this purpose on the first terminal 4 or the application installed therein, of a notification 42 to the safe 11 for managing the desired non-fungible token, said notification comprising the aforementioned lists m, n, as well as the digital address 36 of the exchange safe 35.

[0097] In the case where the second list n of non-fungible tokens held by a second user 2 and desired by the first user 1 contains several non-fungible tokens managed by different safes 11, for example if these non-fungible tokens have been previously purchased by said second user from different creators, the first terminal 4 can send a notification 42 adapted to each of said management safes, so that the second user 2 can identify the non-fungible token(s) desired by the first user 1 by consulting each of the corresponding management safes 11.

[0098] Once the exchange proposal has been issued by the first user 1 and notified to the second user 2, for example via direct exchanges or by messaging between said users, the method provides: - verification by the second user 2 of the exchange proposal recorded in the exchange safe 35; - verification by the second user 2, in the safe 10a, 10b for management of the non-fungible token to be exchanged: • the registered exchange authorization status for said non-fungible token to be exchanged; • the association of the digital address 36 of the exchange safe 35 with the unique identifier j of said non-fungible token to be exchanged.

[0099] To do this, the second terminal 5 comprises means to allow the second user 2 to carry out these checks.

[0100] In relation to figures 1b and 3b, the second user 2 launches on the second terminal 5 a procedure 43 adapted to trigger the sending of a request 44 to the exchange safe 35, in order to verify the lists m, n, and in particular to become aware, via the first list m, of the non-fungible tokens that the first user 1 proposes to exchange, as well as the digital addresses 39a, 39b of the safes 10a, 10b for managing these non-fungible tokens, in order to be able to access these safes 10a, 10b to carry out the required verifications there.

[0101] Then, the second user 2 sends via the second terminal 5 a request 45 to the safe(s) 10a, 10b for managing the non-fungible token(s) entered in the first list m, of which he obtained the digital address(es) 39a, 39b by consulting the exchange safe 35, in order to verify there, for each non-fungible token: - the exchange authorization status recorded by the first user 1 for said non-fungible token; - the association of the digital address 36 of the exchange safe 35 with the unique identifier j of said non-fungible token, and thus the accreditation of said exchange safe to supervise the exchange of said non-fungible token.

[0102] Thus, in the event of a negative result for one and / or the other of these parameters (no exchange authorization for a non-fungible token from the first list m and / or no association of the digital address 36 of the exchange safe 35 with said non-fungible token), the second user 2 can choose to refuse the exchange proposal issued by the first user 1.

[0103] In particular, the method provides, when the first list m recorded by the first user 1 contains a digital voucher, the verification by the second user 2 of the monetary value of said digital voucher in the digital safe 10b for managing said voucher.

[0104] To do this, as shown in Figures 3b and 4, the second terminal 5 comprises means, installed directly in said second terminal or in a previously installed application, to allow the second user 2 to verify this monetary value, by sending to the server 12 a request 46 containing, as shown in more detail in [Fig.4]: - the digital address 9 of said second user on the blockchain, preferably associated with a personal safe 7 assigned to said second user on said blockchain; - the digital address 39b of the safe 10b for managing the purchase voucher present on the first exchange list m of the first user 1; - the unique identifier j of said purchase voucher referenced on said first exchange list m and recorded in said purchase voucher management safe.

[0105] Advantageously, the method provides for the prior communication by the first user 1, to the server 12 for supplying purchase vouchers, of a notification 47 comprising: - the digital address 9 of the second user 2 on the blockchain, and in particular of the personal safe 7 allocated to said second user on said blockchain; and - for each digital voucher that he wishes to exchange with the second user 2, the unique identifier j recorded for said voucher in the corresponding voucher management safe 10b;

[0106] in order to position said second user as a party authorized to verify the monetary value of said voucher(s).

[0107] To do this, as shown in [Fig.4], the first terminal 4 (or the application installed therein) comprises means for communicating such a notification 47 to the server 12, said server then recording the digital address 9 of the second user 2 in the corresponding management safe(s) 10b, by associating it with the unique identifier(s) j of the purchase voucher(s) concerned.

[0108] Thus, after receiving the request 46 sent by the second user 2, the server 12 interacts with the management safe(s) 10b concerned, in order to: - verify, via a first request 48, that said second user is a party authorized to verify the monetary value of the corresponding voucher(s), in particular by verifying that the digital address 9 provided by said second user is indeed associated with the unique identifier(s) provided by said second user and recorded in the safe(s) 10b consulted; and - if so, decrypt, via a second request 49, the monetary value associated with each of the digital identifiers j provided by the second user 2, for example by means of the private key 13a associated with said server 12 on the blockchain.

[0109] Then, the server 12 responds to the second user 2 by sending him a notification 50 containing the monetary value(s) of the voucher(s) that said second user wished to verify.

[0110] If the verifications presented above are successful, the method provides for approval by the second user 2 of this exchange proposal: - by associating with the unique identifier i of the non-fungible token that he possesses and that the first user 1 wishes to acquire, recorded in the corresponding management safe 11: • the digital address 36 of the exchange safe 35; • an exchange authorization status of said desired non-fungible token; - by sending to the exchange vault 35 a notification 52 of approval of said exchange proposal.

[0111] To do this, in relation to figures 1b and 3b, the second terminal 5 (or the application installed therein) comprises means adapted to allow the second user 2 to approve the exchange proposal by carrying out the required operations.

[0112] In particular, the second terminal 5 sends: - several notifications 51 to the safe(s) 11 for managing the non-fungible token(s) that it possesses and which are referenced on the second wish list n of the first user 1, in order to associate an exchange authorization status and the digital address 36 with the unique identifier(s) i of said non-fungible token(s); - a notification 52 of approval as described previously to the exchange vault 35.

[0113] Following approval of the exchange by the second user 2, the method provides, to finalize this exchange, that the exchange safe 35 records the following information: - the digital address 8 of the first user 1, and in particular of his personal safe 6, in the digital safe(s) 11 for managing the non-fungible token(s) obtained from the second user 2, by associating it with the unique identifier(s) i of said non-fungible token(s) obtained, in order to designate said first user as the new owner of said non-fungible token(s) obtained; - the digital address 9 of the second user 2, in this case that of his personal safe 7, in the digital safe(s) 10a, 10b for managing the non-fungible token(s) exchanged by the first user 1, by associating it with the unique identifier(s) j of said non-fungible token(s) exchanged, in order to designate said second user as the new owner of said non-fungible token(s) exchanged.

[0114] To do this, the exchange safe 35 comprises means for carrying out such recordings, in particular after having received the notification 52 of approval of the exchange sent by the second user 2 via the second terminal 5.

[0115] These means may be in the form of an algorithm arranged to be triggered automatically upon receipt of the approval notification 52 described previously, the platform 3 comprising means to enable the deployment of the exchange safe 35 arranged to execute said algorithm after receiving said notification.

[0116] Advantageously, this algorithm is arranged to allow the exchange safe 35 to verify the presence of the respective digital addresses 8, 9 of the users 1, 2 on the blockchain, in particular in a central digital safe as described previously, as well as, where appropriate, the presence in this same central safe of a digital address linked to the platform 3 for deploying the personal safes 6, 7 linked to these digital addresses 8, 9. This arrangement makes it possible to further secure the method of exchanging non-fungible tokens between the users 1, 2.

[0117] In the case where the first user 1 has exchanged a digital voucher with the second user 2, the exchange safe 35 records the digital address 9 of the second user 2 in the safe 10b for managing said exchanged voucher, in order to designate said second user as the new owner of said exchanged voucher.

[0118] In relation to [Fig.5], the method provides, when the second user 2 wishes to recover a monetary amount equivalent to the monetary value of a digital voucher exchanged with the first user 1, that said second user 2 sends to the server 12 a reimbursement request 53 comprising: - the digital address 9 of his personal safe 7 on the blockchain; - the digital address 39b of the safe 10b for managing the corresponding purchase voucher; - the unique identifier j of the purchase voucher recorded in said purchase voucher management safe; - information linked to a banking identity of the second user 2, for example an alphanumeric identifier of an account held by said second user in a banking establishment 54.

[0119] To do this, the second terminal 5 comprises means for sending such a request 53 to the server 12, for example via a dedicated application installed on said second terminal, or via a programming interface (API) integrated into the general application previously described and installed on said second terminal.

[0120] Advantageously, the method provides that the owner of a digital voucher, for example the first user 1 after creation and purchase of said voucher, or the second user 2 after exchange of said voucher by said first user, approves the server 12 as a manager capable of carrying out management operations of said voucher. To do this, the owner 1, 2 can carry out a specific manipulation on the corresponding application, in particular at the time when he acquires the digital voucher.

[0121] After receiving the request 53, the server 12 sends to the safe 10b for managing the purchase voucher a notification 55 to verify the registration of the second user 2 as the current owner of said purchase voucher, in particular by verifying the association of the digital address 9 of said second user with the unique identifier j of said purchase voucher.

[0122] Then, the server 12 sends to the second terminal 5 a notification 56 to verify the information linked to the banking identity of the second user 2, this information possibly being an alphanumeric identifier of type IB AN (for the English “International Bank Account Number”).

[0123] If these checks are successful, the method provides, in response to this request 53, the interaction of the server 12 with a payment server 57b linked to the banking establishment 54 of the second user 2, in order to make a monetary reimbursement to said second user equivalent to the monetary value of the purchase voucher.

[0124] To do this, as shown in [Fig.5], the server 12 comprises means for: - send a notification 58 to the 10b voucher management safe to recover the said voucher; - send to the payment server 57 a notification 59 to initiate a transfer of the monetary amount corresponding to the monetary value of said voucher, said transfer being able to be carried out according to a SEPA type protocol (for “Single Euro Payments Area”); - send to the second terminal 5 a notification 60 containing an alphanumeric reference identifying said transfer, in order to inform the second user 2 of the execution of said transfer, and thus of the reimbursement of his purchase voucher.

Claims

Claims

1. Method for enabling two users (1,2) to exchange non-fungible tokens on a blockchain, said method firstly providing: - when creating a non-fungible token, recording information related to said non-fungible token in a digital safe (10a, 10b, 11) for managing tokens on the blockchain, by associating it with a unique identifier (i, j) for said non-fungible token; - when a user (1, 2) acquires a non-fungible token, recording, in the digital safe (10a, 10b, 11) for managing said non-fungible token, a digital address (8, 9) of said user on the blockchain, as owner of said non-fungible token; said method further providing, when a first user (1) wishes to exchange non-fungible tokens with a second user (2) on the blockchain: the selection by the first user (1) of at least one non-fungible token to be exchanged, from among the non-fungible tokens that he owns on the blockchain, by associating with the unique identifier (j) of said non-fungible token to be exchanged, recorded in the corresponding digital management safe (10a, 10b): • a digital address (36) of a digital safe (35) present on the blockchain to manage the exchanges of non-fungible tokens between users (1,2) on said blockchain; • an exchange authorization status for said non-fungible token; the recording by the first user (1), in the exchange safe (35), of an exchange proposal comprising: • a first list (m) including the unique identifier (j) of at least one non-fungible token that he wishes to exchange, associated with the digital address (39a, 39b) of the safe (10a, 10b) for managing said non-fungible token to be exchanged; • a second list (n) comprising the unique identifier (i) of at least one non-fungible token of the second user (2) that said first user wishes to acquire via said exchange, associated with the digital address (40) of the safe (11) for managing said desired non-fungible token; the sending by the first user (1), to the safe (11) for managing the desired non-fungible token, of a notification (42) comprising the lists (m, n), as well as the digital address (36) of the exchange safe (35); the verification by the second user (2) of the exchange proposal recorded in the exchange safe (35); the verification by the second user (2) in the safe (10a, 10b) for managing the non-fungible token to be exchanged: • the registered exchange authorization status for said non-fungible token to be exchanged; • the association of the digital address (36) of the exchange safe (35) with the unique identifier (j) of said non-fungible token to be exchanged; if these checks are successful, approval by the second user (2) of this exchange proposal: • by associating with the unique identifier (i) of the desired non-fungible token, recorded in the corresponding management safe (11): • the digital address (36) of the exchange safe (35); • an exchange authorization status of said desired non-fungible token; • by sending to the exchange vault (35) a notification (52) of approval of said exchange proposal; the recording, by the exchange safe (35), of: • the digital address (8) of the first user (1) in the digital safe (11) for managing the non-fungible token obtained from the second user

2. (2), by associating it with the unique identifier (i) of said non-fungible token obtained, in order to designate said first user as the new owner of said non-fungible token obtained; • the digital address (9) of the second user (2) in the digital safe (10a, 10b) for managing the non-fungible token exchanged with the first user (1), by associating it with the unique identifier (j) of said non-fungible token exchanged, in order to designate said second user as the new owner of said non-fungible token exchanged. Method according to claim 1, characterized in that it provides in advance for the purchase by the first user (1) of a digital voucher in the form of a non-fungible token intended to be exchanged subsequently with a second user (2), said purchase being carried out by: - sending by the first user (1) a request (16) to a server (12) for providing digital vouchers linked to the blockchain, said request comprising information on a monetary amount that said first user wishes to allocate to said digital voucher; - the creation by the voucher server (12), in a digital voucher management safe (10b) present on the blockchain, of a digital voucher in the form of a non-fungible token, by assigning it a unique identifier (j) and a monetary value corresponding to the amount information communicated in the request (16); - sending by said first user the monetary amount corresponding to the information communicated in the request (16) to a payment server (17) linked to the blockchain; - the recording by the voucher server (12), in the voucher management safe (10b), of the digital address (8) of the first user (1) on the blockchain, as the owner of said voucher.

3. Method according to claim 2, characterized in that it provides, when the first user (1) selects a digital voucher as a non-fungible token to be exchanged with a second user (2), to associate with the unique identifier (j) of said digital voucher to be exchanged, recorded in the corresponding voucher management safe (10b): - a digital address (36) of the exchange safe (35) on the blockchain; - an exchange authorization status of said digital voucher;the first user (1) then recording in the exchange safe (35) the first list (m) comprising the unique identifier (j) of said voucher associated with the digital address (39b) of the voucher management safe (10b), the method further providing, after the exchange of the digital voucher with the second user (2), recording the digital address (9) of said second user in the digital safe (10b) for managing the voucher exchanged with the first user (1), by associating it with the unique identifier (j) of said exchanged voucher, in order to designate said second user as the new owner of said exchanged non-fungible token.;

4. Method according to one of claims 2 or 3, characterized in that it provides, when the first exchange list (m) recorded by the first user (1) contains at least one digital voucher, the verification by the second user (2) of the monetary value of said digital voucher in the digital safe (10b) for managing said voucher.

5. Method according to claim 4, characterized in that it provides for the sending by the second user (2) to the voucher supply server (12) of a request (46) containing the digital address (9) of said second user on the blockchain, the digital address (39b) of the safe (10b) for managing the voucher present on the first exchange list (m), as well as the unique identifier (j) of said voucher referenced on the first exchange list (m) and recorded in said voucher management safe.

6. Method according to one of claims 4 or 5, characterized in that it provides for prior communication by the first user (1) to the voucher supply server (12) of a notification (47) comprising the digital address (8) of the second user (2) on the blockchain and, for each digital voucher that he wishes to exchange with said second user, the unique identifier (j) recorded for said voucher in the corresponding voucher management vault (10b), in order to position said second user as a party authorized to verify the monetary value of said voucher(s).

7. Method according to any one of claims 2 to 6, characterized in that it provides, when the second user (2) wishes to recover a monetary amount equivalent to the monetary value of a digital voucher exchanged with the first user (1), the sending by the second user (2), to the voucher supply server (12), of a reimbursement request (53) containing: - the digital address (9) of the second user (2) on the blockchain; - the digital address (39b) of the safe (10b) for managing the corresponding purchase voucher; - the unique identifier (j) of the purchase voucher recorded in said purchase voucher management safe; - information linked to the banking identity of the second user (2); said method further providing, in response to said request, the interaction of said server with a payment server (57) linked to a banking establishment (54) of said second user to make to said second user a monetary reimbursement equivalent to the monetary value of said voucher.

8. Architecture for enabling two users (1,2) to exchange non-fungible tokens on a blockchain, said architecture comprising: - at least one digital safe (10a, 10b, 11) for managing non-fungible tokens on the blockchain, in which are recorded: • when creating a non-fungible token, information linked to said non-fungible token, being associated with a unique identifier (i, j) for said non-fungible token; • when a user (1,2) acquires a non-fungible token managed by means of said token management vault, a digital address (8,9) of said user on the blockchain, as owner of said non-fungible token; a digital safe (35) for managing the exchanges of non-fungible tokens between users (1,2) on said blockchain; a first terminal (4) comprising means for enabling a first user (1) wishing to exchange non-fungible tokens with a second user (2) on the blockchain to: • select at least one non-fungible token to be exchanged, from among the non-fungible tokens that it possesses on the blockchain, by associating with the unique identifier (j) of said non-fungible token to be exchanged, recorded in the corresponding digital management safe (10a, 10b): • a digital address (36) on the blockchain of the digital vault (35) of non-fungible token exchanges; • an exchange authorization status for said non-fungible token; • record in the exchange safe (35) an exchange proposal including: • a first list (m) comprising the unique identifier (j) of at least one non-fungible token that it wishes to exchange, associated with the digital address (39a, 39b) of the safe (10a, 10b) for managing said non-fungible token to be exchanged; • a second list (n) comprising the unique identifier (i) of at least one non-fungible token of the second user (2) that said first user wishes to acquire via said exchange, associated with the digital address (40) of the safe (11) management of said desired non-fungible token; • send, to the safe (11) for managing the desired non-fungible token, a notification (42) including the lists (m, n), as well as the digital address (36) of the exchange safe (35); - a second terminal (5) comprising means for enabling the second user (2) to: • check the exchange proposal recorded in the exchange safe (35); • check, in the safe (10a, 10b) for managing the non-fungible token to be exchanged: • the registered exchange authorization status for said non-fungible token to be exchanged; • the association of the digital address (36) of the exchange safe (35) with the unique identifier (j) of said non-fungible token to be exchanged; • if these checks are successful, approve this exchange proposal: • by associating with the unique identifier (i) of the desired non-fungible token, recorded in the corresponding management safe (11): • the digital address (36) of the exchange safe (35); • an authorization status exchange of said desired non-fungible token; • by sending to the exchange vault (35) a notification (52) of approval of said exchange proposal; the exchange safe (35) comprising means for recording, at the end of this exchange: - the digital address (8) of the first user (1) in the digital safe (11) for managing the non-token

9. fungible token obtained from the second user (2), by associating it with the unique identifier (i) of said non-fungible token obtained, in order to designate said first user as the new owner of said non-fungible token obtained; - the digital address (9) of the second user (2) in the digital safe (10a, 10b) for managing the non-fungible token exchanged with the first user (1), by associating it with the unique identifier (j) of said exchanged non-fungible token, in order to designate said second user as the new owner of said exchanged non-fungible token. Architecture according to claim 8, characterized in that the first terminal (4) comprises means for allowing the first user (1) to purchase a digital voucher intended to be exchanged subsequently with a second user (2), by sending: - a request (16) comprising information on a monetary amount that said first user wishes to allocate to said digital voucher; - the monetary amount corresponding to the information communicated in the request (16) to a payment server (17) linked to the blockchain; said architecture further comprising a server (12) for providing digital vouchers linked to the blockchain, which comprises means for: - receive the request (16) sent by the first terminal to purchase a digital voucher; - upon receipt of said request, create, in a digital voucher management safe (10b) present on the blockchain, a digital voucher in the form of a non-fungible token, by assigning it a unique identifier (j) and a monetary value corresponding to the amount information communicated in said request; - upon receipt by the payment server (17) of confirmation of the transfer of the monetary amount, record, in the voucher management safe (10b) purchases, the digital address (8) of the first user (1) on the blockchain, as the owner of said purchase voucher.

10. Architecture according to claim 9, characterized in that the first terminal (4) comprises means for allowing the first user (1), when selecting a digital voucher as a non-fungible token to be exchanged with a second user (2), to associate with the unique identifier (j) of said digital voucher to be exchanged, recorded in the corresponding voucher management safe (10b): - a digital address (36) of the exchange safe (35) on the blockchain; - an exchange authorization status of said digital voucher;as well as means for allowing the first user (1) to then record in the exchange safe (35) the first list (m) comprising the unique identifier (j) of said voucher associated with the digital address (39b) of the voucher management safe (10b), the exchange safe (35) further comprising means for, after the exchange of the digital voucher with the second user (2), recording the digital address (9) of said second user in the digital voucher management safe (10b) of the voucher exchanged with the first user (1), by associating it with the unique identifier (j) of said exchanged voucher, in order to designate said second user as the new owner of said exchanged non-fungible token.;

11. Architecture according to one of claims 9 or 10, characterized in that the second terminal (5) comprises means for, when the first exchange list (m) recorded by the first user (1) contains at least one digital voucher, verifying the monetary value of said digital voucher in the digital safe (10b) for managing said voucher.

12. Architecture according to claim 11, characterized in that the second terminal (5) comprises means for allowing the second user (2) to send, to the voucher supply server (12), a request (46) containing the digital address (9) of said second user on the blockchain, the digital address (39b) from the safe (10b) for managing the purchase voucher present on the first exchange list (m), as well as the unique identifier (j) of said purchase voucher referenced on the first exchange list (m) and recorded in said purchase voucher management safe.

13. Architecture according to one of claims 11 or 12, characterized in that the first terminal (4) comprises means for allowing the first user (1) to communicate in advance, to the voucher supply server (12), a notification (47) comprising the digital address (9) of the second user (2) on the blockchain and, for each digital voucher that he wishes to exchange with said second user, the unique identifier (j) recorded for said voucher in the corresponding voucher management safe (10b), in order to position said second user as a party authorized to verify the monetary value of said voucher(s).

14. Architecture according to any one of claims 9 to 13, characterized in that the second terminal (5) comprises means for allowing the second user (2), when he wishes to recover a monetary amount equivalent to the monetary value of a digital voucher exchanged with the first user (1), to send to the voucher supply server (12) a refund request (53) containing: - the digital address (9) of the second user (2) on the blockchain; - the digital address (39b) of the safe (10b) for managing the corresponding purchase voucher; - the unique identifier (j) of the purchase voucher recorded in said purchase voucher management safe; - information linked to the banking identity of the second user (2); said voucher supply server further comprising means for, in response to said request, interacting with a payment server (57) linked to a banking establishment (54) of said second user to make a monetary reimbursement to said second user equivalent to the monetary value of said voucher.

Images