Method for carrying out a transaction relating to at least one non-fungible token uniquely associated with a physical product

Abstract

The present invention relates to a method for carrying out a transaction in a blockchain-type database, relating to at least one non-fungible token, the method being characterised in that it comprises carrying out steps of: (c) receiving, via a first client device (2a) of a first user that is the recipient of the transaction, a request to authenticate a physical product (1) uniquely associated with the non-fungible token; (d) if the physical product (1) is authenticated on the first client device (2a), executing the transaction in the blockchain-type database.

Description

[0001] Description

[0002] Title of the invention: Method for implementing a transaction involving at least one non-fungible token uniquely associated with a physical product.

[0003] GENERAL TECHNICAL FIELD

[0004] The present invention relates to the field of securing transactions. More specifically, it relates to a method for implementing a transaction in a blockchain-type database and a method for implementing a transaction relating to a product.

[0005] STATE OF THE ART

[0006] Luxury brand products (such as handbags, jewelry, watches, etc.) often have, due to their rarity, a value that decreases only slightly over time and in some cases even increases. As a result, these products are popular on the resale market, known as the secondary market.

[0007] The problem is that this secondary market is plagued by the growing presence of illegal or counterfeit products, which malicious third parties hope to sell among legal products, which is all the more so since transactions are most often over-the-counter, without involving a professional who would be able to assess the product.

[0008] To solve this problem, solutions have been proposed for the unique identification (and therefore authentication) of a product:

[0009] - Some products incorporate a physical element such as an RFID tag, or a QR code, encoding a unique product identifier;

[0010] - We also know of so-called "fingerprinting" solutions that allow the creation of a unique and tamper-proof digital identity of a product from a photo, in particular from visible micro-defects; More recently, specifically trained artificial intelligence algorithms make it possible to recognize each copy of a product.

[0011] These solutions provide satisfaction and allow a potential buyer to ensure that the product they are going to buy is original and not a copy, but do not ensure that it has not been stolen.

[0012] Luxury products are sold with a certificate that is intended to guarantee legal possession of the product, but these certificates are themselves falsifiable and conversely the seller may not find his certificate.

[0013] The present invention improves the situation.

[0014] PRESENTATION OF THE INVENTION

[0015] The present invention therefore relates, according to a first aspect, to a method for implementing a transaction in a blockchain-type database, relating to at least one non-fungible token, the method being characterized in that it comprises the implementation of steps of:

[0016] (c) Receipt by a first client device from a first user receiving the transaction of a request for authentication of a physical product uniquely associated with said non-fungible token;

[0017] (d) If said physical product is authenticated on said first client device, execution of said transaction in the blockchain database.

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

[0019] The method comprises implementing a step (b) of receiving by a second client device of a second user at the origin of the transaction another request for authentication of the physical product uniquely associated with said non-fungible token.

[0020] Either step (c) is implemented if said physical product is authenticated on said second client device, or in step (d) said transaction is executed if said physical product is authenticated on each of the first and second client devices.

[0021] Step (c) includes verifying said authentication by an authority entity.

[0022] Step (d) includes the payment of a gas fee.

[0023] The authentication of said physical product comprises at least one of: reading a QR code carried by the physical product, reading an electronic label carried by the physical product, extracting a digital fingerprint from a photo of said physical product and recognizing said physical product by an artificial intelligence algorithm.

[0024] Said blockchain database is the Ethereum® blockchain or one of its side chains, and said non-fungible token is based on the ERC-721 standard.

[0025] The process is implemented in the form of a smart contract.

[0026] Said smart contract is controlled by a trusted third party, step (d) comprising the calculation and payment of a royalty for the benefit of said trusted third party, in particular in accordance with the ERC-2981 standard.

[0027] The non-fungible token contains descriptive metadata of a history of said physical product, step (d) comprising updating said metadata.

[0028] According to a second aspect, the invention relates to a method for implementing a transaction relating to the transfer of a physical product from a second user to a first user, characterized in that it comprises the implementation of a step (a) of requesting, from a second client device of the second user, the transfer from the second user to the first user of at least one non-fungible token uniquely associated with said physical product, then the implementation of the method according to the first aspect, in which said transaction in a blockchain-type database is a transfer of said non-fungible token from the second user to the first user.According to a third aspect, the invention relates to a method for implementing a transaction relating to the initial acquisition by a first user of a physical product, characterized in that it comprises the implementation of a step (a') of requesting the creation of at least one non-fungible token uniquely associated with said physical product for the benefit of the first user, then the implementation of the method according to the first aspect, in which said transaction in a blockchain type database is the creation of said non-fungible token for the benefit of the first user.

[0029] According to a fourth aspect, the invention relates to a method for implementing a transaction relating to the repair of a physical product of a first user comprising the replacement of at least one part of the product, characterized in that it comprises the implementation of a step (a') of requesting the creation of a new non-fungible token uniquely associated with said part of the physical product for the benefit of the first user, then the implementation of the method according to the first aspect, in which said transaction in a blockchain type database is the creation of said non-fungible token for the benefit of the first user.

[0030] According to advantageous and non-limiting characteristics, an old non-fungible token is uniquely associated with said at least one part of the physical product prior to said repair, the method comprising the implementation of a prior step (a”) of requesting destruction of said old non-fungible token uniquely associated with said part of the physical product.

[0031] According to a fifth aspect, the invention relates to a first client device of a first user receiving a transaction in a blockchain type database, relating to a non-fungible token, characterized in that it is configured to:

[0032] - receive a request for authentication of a physical product uniquely associated with said non-fungible token; - If said physical product is authenticated on said first client device, execute said transaction in the blockchain database.

[0033] According to a sixth aspect, the invention relates to a set of a first client device according to the fifth aspect and a second client device of a second user at the origin of said transaction and configured to receive another request for authentication of the physical product uniquely associated with said non-fungible token.

[0034] According to a seventh and an eighth aspect, the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of implementing a transaction in a blockchain-type database, relating to a non-fungible token; and a storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for executing a method according to the first aspect of implementing a transaction in a blockchain-type database, relating to a non-fungible token.

[0035] PRESENTATION OF FIGURES

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

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

[0038] [Fig. 2a]Figure 2a is a diagram illustrating the transfer of a state-of-the-art physical NFT;

[0039] [Fig. 2b]Figure 2c is a diagram illustrating the transfer of a PBT according to the invention; [Fig. 3a]Figure 3a is a flowchart illustrating the steps of a first embodiment of the method according to the invention;

[0040] [Fig. 3b]Figure 3b is a flowchart illustrating the steps of a second embodiment of the method according to the invention;

[0041] [Fig. 3c]Figure 3c is a flowchart illustrating the steps of a third embodiment of the method according to the invention;

[0042] [Fig. 3d]Figure 3d is a flowchart illustrating the steps of a third embodiment of the method according to the invention.

[0043] DETAILED DESCRIPTION

[0044] Architecture

[0045] The present invention relates to a method for implementing a transaction in a blockchain-type database 3 relating to a non-fungible token, which as will be seen will be uniquely associated with a physical product 1 (or a part of the product), in a system such as represented in FIG. 1, in particular for implementing a transaction relating to said product 1. This physical product can be any marketable merchandise, in particular a luxury product such as a handbag, a watch, a pair of shoes, etc. Preferably, said physical product 1 is authenticatable, or even uniquely identifiable; techniques for this purpose will be presented later.

[0046] Said system comprises at least one client device 2a, 2b (generally a large number of them), advantageously playing the role of a “wallet”, each being a personal device of a user allowing him to carry out transactions on his behalf, for example sending or receiving cryptocurrencies. As such, each client device 2a, 2b can implement an application such as MetaMask.

[0047] Alternatively, the wallets of each of the users can be managed in a decentralized manner, in particular by a third client device 2c of an authority entity such as the manufacturer of the product 1 (the brand), or a trusted third party (see below), connected to the devices 2a, 2b. Said possible third client device 2c is typically a remote and automated server, or a terminal of an employee of the brand. In particular, the third client device 2c can create and manage the wallets on behalf of the customers.

[0048] Alternatively, instead of individual wallets, a single common wallet can be provided, advantageously directly held by said authority entity (and therefore typically managed by the third device 2c).

[0049] In all cases, in particular, there is at least one first client device 2a called the creditor as the device of a first “buyer” user in said transaction (recipient of the transaction), and advantageously a second client device 2b called the debtor as the device of a second “seller” user in said transaction (at the origin of the transaction). Said non-fungible token and / or said physical product are in other words transferred from the second user (of the second client device 2b) to the first user (that of the first client device 2a). Note that we will see a specific use case of creation of the non-fungible token for the benefit of the first user (of the first client device 2a) and a case of destruction of the non-fungible token.

[0050] In the present case, each client device 2a, 2b is preferably a lightweight physical device such as a smart card or a terminal such as a smartphone, in particular a security element (Secure Element) of such a terminal, i.e. a dedicated closed microprocessor of the enclave type. It will be understood that the present invention is not limited to these cases and that the client device 2a, 2b can always be a smartphone, a touch tablet, a personal computer, etc. Each client device 2a, 2b can further comprise a camera and / or an NFC or RFID reader.

[0051] The devices 2a, 2b, 2c communicate with each other via at least one network 20, for example the Internet network, a cellular network, or a combination of such networks. They each have read and write access to a blockchain-type database 3 stored in the network 20. It should be noted that in the same case there are also transaction validating devices, called “miners”, which are known to those skilled in the art and which will not be discussed in more detail.

[0052] The database 3 is public, in the sense that it is freely accessible for reading not only by the devices 2a, 2b, 2c present but also by any other third-party device. Any third-party device can in particular consult the data written by one of the devices 2a, 2b, 2c.

[0053] Blockchain databases are generally used as the basis for electronic money transaction systems. Each client device 2a, 2b, 2c stores a mutually associated public key and a private key that are specific to it (and allow transactions to be carried out on the blockchain database 3). The private key allows signed data to be written to the database; it is not intended to be communicated to third parties. The public key allows the device 2a, 2b, 2c (and any other holder of an account for accessing the database 3) to verify that data present in the database 3 has been written therein by the device 2a, 2b, 2c. Generally, the client device 2a, 2b, 2c is designated by an address that is typically a cryptographic fingerprint of its public key.

[0054] The database 3 is distributed or decentralized in the network 20, that is to say it is stored by a plurality of nodes of the network 20 with which the devices 2a, 2b, 2c can communicate.

[0055] A blockchain database is distributed among multiple storage nodes in a network. The storage nodes are configured to validate data written to the database by implementing a consensus-building method among the storage nodes. Examples of such methods include proof of work (POW) or proof of stake (POS). The database's contents (a history of all past transactions between user accounts in the system) are thus protected against tampering, despite its distributed nature.The most famous blockchain-type databases are the Bitcoin® or Ethereum® blockchains, typically the latter in the context of the present invention, or any other compatible blockchain, i.e. based on the EVM (Ethereum Virtual Machine), the execution environment for Ethereum instructions (in a language such as Solidity). These are called "sidechains", such as Polygon or Avalanche.

[0056] A non-fungible token, or NFT, is a type of cryptographic token that can be transferred on a blockchain, just like a cryptocurrency, but is unique and therefore non-interchangeable, unlike the latter. The Ethereum blockchains (or sidechains), but also Solana or Cardano are the most commonly used for NFTs.

[0057] An NFT typically contains a reference to a digital object such as an image or video, sometimes artistic, for which it serves as a sort of certificate of authenticity, and sometimes metadata. It is claimed that an NFT could constitute ownership of said digital object, but there is no real legal basis.

[0058] Minting is the act of creating an NFT, typically through a smart contract on the blockchain, for example, in accordance with the ERC-721 standard on the Ethereum blockchain. In particular, an ERC-721 token has a tokenld parameter that makes it unique (as opposed to an ERC-20 fungible token, which is a standard ETH, i.e., the native cryptocurrency of the Ethereum blockchain). Like any other transaction on the blockchain, minting involves paying a “gas fee,” to reward miners for the computing power they must use to execute transactions.

[0059] Similarly, the action of destroying an NFT by the same means is called “burning”.

[0060] Principle The present invention proposes a new type of N FT, advantageously still based on the ERC-721 standard, which will be called a “product-bound token”, or PBT (“product-bound token”), which very cleverly guarantees the ownership and authenticity of a physical product during a transaction.

[0061] Note that it is already known to associate an NFT with a physical product (we speak of "physical NFT"), for example if the digital data to which it points constitutes a unique digital identifier of said physical product, for example that coded by a QR code or an RFID tag carried by the physical product, as explained in the introduction.

[0062] However, as seen in Figure 2a, such physical NFTs do not provide any solution to the problem of reselling counterfeit or stolen products, and are only of advertising interest, since the NFT and the product can be resold independently. In practice, the object of value is the physical NFT and the attached physical product is an "accessory" often offered for the purchase of the NFT.

[0063] On the contrary, the PBT is an NFT accessory to a physical product (and not the other way around), which has no value in itself and is only transferable if the buyer provides proof of possession of the linked product, as seen in Figure 2b. Thus:

[0064] - If the product is a fake, the NFT transfer will be rejected;

[0065] - If the product is stolen, it will not be resalable due to lack of access to the NFT.

[0066] Note that one or more non-fungible tokens according to the invention may be associated with the product, where appropriate with sub-parts of the product, i.e. parts, for example the shoulder strap of a bag, which will allow repairs and their traceability where appropriate (thus one may resell a product that has been repaired while guaranteeing that all the parts are original and that the product has been repaired in an official workshop). In all cases, even with several tokens associated with the same product, it will be understood that each token will always be uniquely associated with the product (it is impossible for a token to be associated with several products). Thus in the remainder of this description, when we speak of a token uniquely associated with a product, we will designate a token associated with the entire product and / or one of the tokens associated more precisely with a sub-part of the product.

[0067] Note that you can even accumulate a global product token (a “super token”) and tokens for the games.

[0068] Method for implementing a transaction involving an NFT

[0069] The present invention relates, as explained according to a first aspect, to a method for implementing a transaction in a blockchain-type database, relating to at least one non-fungible token, i.e. an NFT, here of the PBT type (and preferably each non-fungible token associated with the product 1).

[0070] In practice, there are three possible types of transactions on the said token:

[0071] - Either a transfer of the token from the second user to the first user, preferably within the framework of a transfer of the physical product 1 from the second user to the first user, represented by figures 3a and 3b;

[0072] - Either the creation of the token (“mint”) by the second user for the benefit of the first user, typically when the physical product 1 is first put on sale or the repair of the product including the replacement of a part of the product, the token concerned being the new token of the replaced part (the second user is then the manufacturer of the product 1, i.e. the brand), represented by figure 3c;

[0073] - Either the destruction of the token ("burn") by the first user at the request of the second user, typically during the repair of the product including the replacement of a part of the product, the token concerned being the old token of the replaced part (the second user is then the manufacturer of product 1, i.e. the brand), visible in figure 3d. In the case of a transfer / first sale of product 1, all the tokens associated with the product are preferably transferred (including a possible super-token), and in the case of the repair of the product, just the token(s) associated with the replaced part(s).

[0074] If each user has their own wallet, the effect of the token transfer transaction is its movement from one wallet to another. In the case of a common wallet held by an authority entity, the effect of this transaction is the modification of ownership information of the non-fungible token, notably in the token's metadata. The transaction is therefore only an update of the token's metadata. In particular, each user can be designated by a customer identifier, for example created at the user's first purchase.

[0075] The present methods are in all cases implemented by the data processing means of the client devices 2a and / or 2b and / or the possible 2c, typically in the form of a smart contract as enabled in particular by the Ethereum ecosystem, in particular via an MTM centralizer (“multi-token minter”) which allows smart contracts to be deployed via any public blockchain. Alternatively, one can go through a trusted third party, i.e. a dedicated platform such as OpenSea.

[0076] The methods have at least one step (c) of reception by the first client device 2a of the first user receiving the transaction of a request for authentication of the physical product 1 uniquely associated with said non-fungible token, and (d) of execution of said transaction in the blockchain type database if said physical product 1 is authenticated on said first client device 2a.

[0077] By authentication of the physical product 1, we mean at least the verification of the authenticity of the physical product 1, and advantageously its identification, that is to say the verification that it is indeed a specific copy of the product. In both cases, it is ensured that the first user has been given the original product and not a counterfeit. Preferably, said authentication is a proximity authentication, involving the immediate presence of said physical product 1, and in particular a direct interaction of the first client device 2a with the product. This makes it possible to guarantee that the second user has in his hands the product 1 associated with the PBT, i.e. that the second user has for example given it to him by hand or sent it by post.

[0078] It should be noted that certain authentication techniques that will be presented use a photo which is thus advantageously acquired live by a camera of the first client device 2a, and not received from a remote terminal, which could lead to risks of falsification (we understand in any case that the first user would have no interest in doing this because he is precisely seeking to ensure that he has been given an authentic product).

[0079] Preferably, the authentication of said physical product 1 comprises at least one of:

[0080] - reading a QR code carried by the physical product 1 (by a camera of the first client device 2a). In particular, it is possible to extract from the QR code a product identifier, or even a unique identifier of this copy of the product 1, and to verify this identifier, in particular by means of a proprietary function of the brand of said product, where appropriate using digital data directly contained or linked to the PBT. For example, it is possible to have a cryptographic fingerprint (hashed) of a reference identifier of the product accessible via a URL contained in the PBT, called the expected cryptographic fingerprint (it could even be directly contained in the PBT), and the verification is carried out by hashing (with a predefined hash function) the identifier extracted from the QR code and comparing it with said expected cryptographic fingerprint

[0081] - reading an electronic label (also called a "radio-label", typically NFC or RFID) carried by the physical product 1, for example by a suitable reader of the client device 2a. The same identifier mechanism can be used as for the QR code; - extracting a digital fingerprint from a photo of said physical product 1. Again, it is possible to have a reference digital fingerprint contained or accessible via the PBT, and to use a mechanism for calculating the distance between the extracted digital fingerprint and the expected fingerprint, in particular by fuzzy logic. Again, such a mechanism is known to those skilled in the art.

[0082] - the recognition of said physical product 1 by an artificial intelligence algorithm. We can directly have AI algorithms such as classification neural networks (typically CNNs) provided by the product brands, taking as input a photo of the product 1 allowing to directly answer the question of its authenticity, in a secure manner since we have a "black box".

[0083] In the case where the transaction is a transfer or destruction of the PBT (figures 3a, 3b and 3d), there is advantageously a prior step (b), similar to step (c), of reception by a second client device 2b from a second user at the origin of the transaction of another request for authentication of a physical product 1 uniquely associated with said non-fungible token. Note that this is also the case in figure 2b. This makes it possible to ensure in the case of a transfer that the second user (the seller) has an original, and therefore has the right to transfer the PBT, and in the case of a repair that the first user entrusts the second user (the repairer) with an original, and therefore has the right to have a new PBT created for the replaced part - even if a fake would obviously be detected in the workshop.

[0084] In the case where the transaction is a creation of the PBT for an initial acquisition (figure 3c), this other request for authentication of the physical product 1 by the second user is not essential, but it can be implemented in advance, following manufacturing (at the series level). The result can be stored for authentication by the first user. The same authentication / identification techniques for product 1 are advantageously used.

[0085] In such a case of double authentication:

[0086] - either step (c) is implemented if (and in particular only if) said physical product 1 is authenticated on said second client device 2b, as represented by figure 3a. In other words, at this stage the second user can transfer the physical product 1 to the first user, and this triggers the authentication request by the first user. This is an asymmetric scheme, which is typically used if the product is transferred by post or pre-authenticated, and therefore with a delay (and that represented by figure 3a if the transaction is a transfer). At step (d) it is then sufficient for the product 1 to be authenticated on the first client device 2a for the transaction to be able to be executed.

[0087] - either in step (d) said transaction is executed if (and in particular only if) said physical product 1 is authenticated on each of the first and second client devices 2a, 2b, as shown in Figure 3b. In other words, the two authentications can be done simultaneously or almost simultaneously, and we just wait to have the results of the two verifications to launch the execution. This is a symmetrical scheme, which is typically used when handing over the product 1 in person.

[0088] In any case, step (b) (if it takes place) and / or step (c) may include the verification of said authentication by an authority entity. By authority entity is meant, as explained, either the manufacturer of product 1 (the brand), or a trusted third party, for example an intermediary involved in the transaction, for example a marketplace.

[0089] The notion of verification of said authentication by an authority entity can be interpreted here in the broad sense and can take many forms: - according to a first embodiment, there can be a third authentication in its own right, i.e. the presence of a step (c') similar to steps (b) and / or (c) (which can take place at any time before step (d)) of reception by said possible third client device 2c of the authority entity (as explained potentially a remote and automated server, or a terminal of an employee of the brand) of another request for authentication of the physical product 1 uniquely associated with said non-fungible token.For example, each user can implement authentication via electronic label, and in addition the authority entity can implement remote authentication by recognition of said physical product 1 by an artificial intelligence algorithm kept secret: the second user performs his authentication (b) and takes a photo that he transfers to said third client device for it to perform. Thus, when the first user receives the product 1 , he knows that he has also been authenticated by the brand, and he is even more convinced of the authenticity of the product when he scans his electronic label in step (c). Alternatively, the exchange can take place in a store, and the seller also authenticates the product 1 .

[0090] In such an embodiment, again either step (b) or step (c) is implemented if said physical product 1 is authenticated on the third client device 2c of the authority entity (sequential operation), or in step (d) said transaction is executed if said physical product 1 is authenticated on each of the first and / or second client device 2a, 2b, and the third client device 2c (triple authentication).

[0091] - according to a second embodiment, visible in figure 3b, the first and / or the second authentication is controlled by the authority entity, and it can be provided that if necessary the latter signs the transaction, and that only a signed transaction can be executed in step (d). This means that the authority entity certifies for example that a recognized authentication mechanism has been used, and correctly.

[0092] - According to a third embodiment, the authority entity carries out additional checks making it possible to observe the context of the authentication, for example by analyzing the state of wear of the product, by comparing it with a digital maintenance log, by verifying a guarantee, but also by verifying a location of the authentication if the transaction must take place at a specific place, etc.

[0093] Step (d) typically involves the payment of a gas fee (by the first user, on his client device 2a, or possibly by the brand on the device 2c if this is included in the sale price). In other words, as soon as the required authentication(s) are made, the transaction is executable, and it is the first user, who now has the conviction that the product being legally owned by the second user and was an original, who can trigger the effective transfer of the PBT by paying the gas fee or at least by instructing a possible third party managing his wallet to do so. The execution of the transaction in the blockchain is then done in a classic way: it is verified by the miners, and included in the next mined block. The miners collect the gas fee for their work.

[0094] Note that the transaction may also involve the transfer of cryptocurrencies from the first user to the second user as payment for the transfer of the PBT (and the physical product 1), particularly if each has their own wallet, although as we will see this transfer may involve a classic payment outside the blockchain, or even be free of charge (gift).

[0095] Step (d) may further comprise, particularly in the case of a payment in cryptocurrency and when the smart contract is controlled by a trusted third party, the calculation and payment of a royalty to the benefit of said trusted third party, as a commission for having ensured the transaction. This is typically permitted by the ERC-2981 standard. Finally, in a particularly preferred manner, the non-fungible token contains descriptive metadata of a history of said physical product, called traceability data. They may comprise the ownership history of the product and / or the repair and maintenance history, where appropriate in a pseudo-anonymized manner. In this case, step (d) advantageously comprises the updating of said metadata, in particular by adding the transaction currently carried out. This makes it possible to have a complete, public, and unalterable record of what happened to the product 1 .

[0096] Preferably, this metadata constitutes a digital passport, or Digital Product Passport (DPP), of the product 1, in accordance with the requirements of the European Commission.

[0097] Method of implementing a transaction involving the physical product

[0098] We will now describe three methods of implementing a transaction relating to the transfer of the physical product 1, involving the method of implementing a transaction in a blockchain type database, relating to at least one non-fungible token, according to the first aspect.

[0099] According to a second aspect, said transaction relating to the transfer of the physical product 1 is from a second user to a first user, this is the case of resale of the physical product 1.

[0100] With reference to figures 3a and 3b, the method begins with a step (a) of request, from the second client device 2b of the second user, for transfer of the (and preferably each) non-fungible token uniquely associated with said physical product 1 (the PBT), from the second user to the first user.

[0101] We understand that this step is only feasible if the second user actually has the PBT(s) in his wallet (or if he is clearly indicated as the owner in the common wallet). Otherwise, the product 1 is stolen. It is carried out in particular by identifying the first user on the second client device 2b, for example by entering a public address of his wallet in the case of an individual wallet, or a client identifier of the first user. If necessary, a first request is transmitted to the third client device 2c holding the wallet (to transfer the transaction information to it), and this generates a second request which is the request to execute the actual transaction (on the blockchain).

[0102] Then, the method according to the first aspect is implemented so as to implement the transfer of said non-fungible token(s) from the second user to the first user as a transaction in a blockchain database that is the subject of the method (at least steps (c) and (d), and preferably step (b)). By step (c), the second user must have transmitted the physical product to the first user, possibly against payment of a sum of money, in exchange for something, etc. Preferably, as explained, the transaction in the blockchain database 3 may involve the reverse transfer of electronic money from the first user to the second user as payment. Alternatively, it may be a gift.

[0103] In summary, the method according to the second aspect is as follows:

[0104] Method for implementing a transaction relating to the transfer of a physical product 1 from a second user to a first user, characterized in that it comprises the implementation of steps of:

[0105] (a) request, from a second client device 2b of the second user, for transfer from the second user to the first user of at least one (and preferably each) non-fungible token uniquely associated with said physical product 1,

[0106] (b) optionally, reception by the second client device 2b of a request for authentication of the physical product 1;

[0107] (c) Reception by a first client device 2a from the first user of a request for authentication of the physical product 1;

[0108] (d) If said physical product 1 is authenticated on said first client device 2a (and where applicable on the second client device 2b), execution of a transaction in the blockchain type database for transferring said non-fungible token from the second user to the first user.

[0109] According to a third aspect, said transaction relating to the transfer of the physical product 1 is the initial acquisition by a first user of a physical product, this is the case of a purchase in store or online of the new physical product 1.

[0110] With reference to Figure 3c, the method begins with a step (a') of requesting the creation of at least one non-fungible token uniquely associated with said physical product 1 (the PBT), for the benefit of the first user, in particular either a single token associated with the product as a whole, or a token per part of the product. There may or may not be a second user, depending on whether this is done uniquely, or by a seller in a store on his client device (which is then the second client device 2b, which is then potentially confused with the possible third client device 2c of the authority entity - or there may again be a first and then a second request as in step (a)). This step may be triggered by the payment of the price of the new physical product 1.

[0111] If this is the first purchase for the first user, and in the case of a decentralized wallet, step (a') can include creating their wallet on the third client device 2c. In the case of a shared wallet, we can simply create a client ID for them.

[0112] Then, the method according to the first aspect is again implemented so as to implement said creation (“mint”) of said non-fungible token(s) for the benefit of the first user as a transaction in a blockchain-type database which is the subject of the method (at least steps (c) and (d)).

[0113] In summary, the method according to the third aspect is as follows: Method for implementing a transaction relating to the initial acquisition by a first user of a physical product 1, characterized in that it comprises the implementation of steps of:

[0114] (a') request for the creation of at least one non-fungible token uniquely associated with said physical product 1 for the benefit of the first user;

[0115] (b) optionally, reception by a possible second client device 2b from which the creation request would have been issued, of a request for authentication of the physical product 1;

[0116] (c) Reception by a first client device 2a from the first user of a request for authentication of the physical product 1;

[0117] (d) If said physical product 1 is authenticated on said first client device 2a (and where applicable on the second client device 2b), execution of a transaction in the blockchain-type database for the creation of said non-fungible token for the benefit of the first user.

[0118] According to a fourth aspect, said transaction relating to the transfer of the physical product 1 is the repair of a physical product 1 of a first user, typically in an official store. It is assumed that this repair comprises the replacement of one (or more) parts of the product, and that various parts of the product including the part to be replaced are each associated with a non-fungible token. It is understood that a worn version of said worn part is replaced by the same but new one.

[0119] The idea is that we will just create a new token here for each part that has been replaced since it is now new, similar to what is done in the process according to the third aspect.

[0120] Thus, as explained, the method begins with a step (a') of requesting the creation of the non-fungible token uniquely associated with said replaced part, for the benefit of the first user, as described just before. This step can be triggered by the payment of the price of the repair, in particular when depositing the product 1.

[0121] Then, the method according to the first aspect is again implemented so as to implement said creation (“mint”) of said non-fungible token for the benefit of the first user as a transaction in a blockchain-type database which is the subject of the method (at least steps (c) and (d)).

[0122] Note that you may want to check beforehand that the first user actually owns product 1. To do this, simply plan to destroy ("burn") the non-fungible token previously associated with the replaced part. In doing so, the old token of the game is replaced by the new one.

[0123] Thus, preferably, with reference to figure 3d, the method comprises a prior step (a”) of requesting destruction of the old non-fungible token uniquely associated with said part of the physical product 1 (and preferably each token associated with a part to be replaced). Step (a”) is implemented under the same conditions as step (a), just the PBT is destroyed instead of transferring it.

[0124] Tokens associated with other (non-replaced) parts are not affected. In other words, only the tokens of the replaced parts are destroyed and then recreated.

[0125] We understand that this step (a”) is only feasible if the first user actually has the PBT(s) concerned in his wallet (or if he is clearly indicated as the owner in the common wallet). Otherwise, the product 1 is stolen. It is thus carried out in particular from the first terminal 2a if it is the one that stores a personal wallet of the first user.

[0126] Preferably, in the case of a centralized or common wallet, steps (a”) and (a') are implemented in the form of a common request from the third client device 2c, itself on instruction from the first or second device 2a, 2b. This makes it possible to link the destruction of the old token and the creation of the new one, so as to prevent a token from being destroyed without creating a new one (which would make the product unsaleable) or a new token from being created without destroying the old one (which would allow fraud). Step (c) (and therefore step (d)) can only be implemented upon recovery of the product after repair, which allows the user to ensure that an original part was indeed placed on his product during the repair.

[0127] In summary, the method according to the fourth aspect is as follows:

[0128] Method for implementing a transaction relating to the repair of a physical product 1 of a first user comprising the replacement of at least part of the product, characterized in that it comprises the implementation of steps of:

[0129] (a”) Optionally, request for destruction of an old non-fungible token uniquely associated with said part of the physical product 1,

[0130] (a') request for creation of at least one new non-fungible token uniquely associated with said part of the physical product 1 for the benefit of the first user;

[0131] (b) optionally, reception by the second client device 2b of a request for authentication of the physical product 1;

[0132] (c) Reception by a first client device 2a from the first user of a request for authentication of the physical product 1;

[0133] (d) If said physical product 1 is authenticated on said first client device 2a (and where applicable on the second client device 2b), execution of a transaction in the blockchain type database for the destruction of the old non-fungible token and then creation of said new non-fungible token for the benefit of the first user.

[0134] Client devices

[0135] According to a fifth and / or a sixth aspect, the invention relates to the first and / or the second client device 2a, 2b, and in particular the whole of the first and second client devices 2a, 2b, for implementing the method for implementing a transaction in a blockchain type database, relating to a non-fungible token, according to the first aspect.

[0136] The first client device 2a, of a first user receiving a transaction in a blockchain-type database, relating to a non-fungible token, is configured to:

[0137] - receive a request for authentication of a physical product 1 uniquely associated with said non-fungible token;

[0138] - If said physical product 1 is authenticated on said first client device 2a, execute said transaction in the blockchain type database.

[0139] The first client device 2b, of a second user at the origin of said transaction in a blockchain type database, relating to a non-fungible token, is configured to:

[0140] - If said transaction is a transfer of a non-fungible token uniquely associated with said physical product 1, from the second user to the first user, require this transfer of the non-fungible token; or if the transaction is the creation of said non-fungible token uniquely associated with said physical product 1, for the benefit of the first user, require this creation of the non-fungible token;

[0141] - receive a possible other authentication request for the physical product 1 uniquely associated with said non-fungible token.

[0142] Computer program product

[0143] According to a seventh and an eighth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means of the client devices 2a, 2b and / or 2c) of a method according to the first aspect of implementing a transaction in a blockchain type database, relating to a non-fungible token (or even the methods according to the second or third aspect), as well as storage means readable by computer equipment (for example the memories of the client devices 2a, 2b and / or 2c) on which this computer program product is found.

Claims

CLAIMS 1. Method for implementing a transaction in a blockchain-type database, relating to at least one non-fungible token, the method being characterized in that it comprises the implementation of steps of: (c) Reception by a first client device (2a) from a first user receiving the transaction of a request for authentication of a physical product (1) uniquely associated with said non-fungible token; (d) If said physical product (1) is authenticated on said first client device (2a), execution of said transaction in the blockchain database.

2. Method according to claim 1, comprising the implementation of a step (b) of reception by a second client device (2b) of a second user at the origin of the transaction of another request for authentication of the physical product (1) uniquely associated with said non-fungible token.

3. The method of claim 2, wherein either step (c) is implemented if said physical product (1) is authenticated on said second client device (2b), or in step (d) said transaction is executed if said physical product (1) is authenticated on each of the first and second client devices (2a, 2b).

4. Method according to one of claims 1 to 3, in which step (c) comprises the verification of said authentication by an authority entity.

5. Method according to one of claims 1 to 4, in which step (d) comprises the payment of a gas fee.

6. Method according to one of claims 1 to 5, in which the authentication of said physical product (1) comprises at least one of: the reading a QR code carried by the physical product (1), reading an electronic label carried by the physical product (1), extracting a digital fingerprint from a photo of said physical product (1) and recognizing said physical product (1) by an artificial intelligence algorithm.

7. Method according to one of claims 1 to 6, wherein said blockchain database is the Ethereum® blockchain or one of its side chains, and said non-fungible token is based on the ERC-721 standard.

8. Method according to one of claims 1 to 7, implemented in the form of a smart contract.

9. Method according to claim 8, wherein said smart contract is controlled by a trusted third party, step (d) comprising the calculation and payment of a royalty for the benefit of said trusted third party, in particular in accordance with the ERC-2981 standard.

10. Method according to one of claims 1 to 9, in which the non-fungible token contains descriptive metadata of a history of said physical product, step (d) comprising updating said metadata.

11. Method for implementing a transaction relating to the transfer of a physical product (1) from a second user to a first user, characterized in that it comprises the implementation of a step (a) of requesting, from a second client device (2b) of the second user, transfer from the second user to the first user of at least one non-fungible token uniquely associated with said physical product (1), then the implementation of the method according to one of claims 1 to 10, wherein said transaction in a blockchain type database is a transfer of said non-fungible token from the second user to the first user.

12. Method for implementing a transaction relating to the initial acquisition by a first user of a physical product (1), characterized in that it comprises the implementation of a step (a') of requesting the creation of at least one non-fungible token uniquely associated with said physical product (1) for the benefit of the first user, then the implementation of the method according to one of claims 1 to 10, in which said transaction in a blockchain type database is the creation of said non-fungible token for the benefit of the first user.

13. Method for implementing a transaction relating to the repair of a physical product (1) of a first user comprising the replacement of at least one part of the product, characterized in that it comprises the implementation of a step (a') of requesting the creation of a new non-fungible token uniquely associated with said part of the physical product (1) for the benefit of the first user, then the implementation of the method according to one of claims 1 to 10, in which said transaction in a blockchain type database is the creation of said non-fungible token for the benefit of the first user.

14. Method according to claim 13, in which an old non-fungible token is uniquely associated with said at least one part of the physical product (1) prior to said repair, the method comprising the implementation of a prior step (a”) of requesting destruction of said old non-fungible token uniquely associated with said part of the physical product (1).

15. First client device (2a) of a first user receiving a transaction in a blockchain type database, relating to at least one non-fungible token, characterized in that it is configured to: - receive a request for authentication of a physical product (1) uniquely associated with said non-fungible token; If said physical product (1) is authenticated on said first client device (2a), execute said transaction in the blockchain database.

16. Set of a first client device (2a) according to claim 15 and a second client device (2b) of a second user at the origin of said transaction and configured to receive another request for authentication of the physical product (1) uniquely associated with said non-fungible token.

17. Computer program product comprising code instructions for executing a method according to one of claims 1 to 10 for implementing a transaction in a blockchain type database, relating to at least one non-fungible token, when said program is executed on a computer.

18. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 10 for implementing a transaction in a blockchain type database, relating to at least one non-fungible token.

Images