FR3148653A1 - Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique. - Google Patents

Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique. Download PDF

Info

Publication number
FR3148653A1
FR3148653A1 FR2304745A FR2304745A FR3148653A1 FR 3148653 A1 FR3148653 A1 FR 3148653A1 FR 2304745 A FR2304745 A FR 2304745A FR 2304745 A FR2304745 A FR 2304745A FR 3148653 A1 FR3148653 A1 FR 3148653A1
Authority
FR
France
Prior art keywords
transaction
user
physical product
client device
fungible token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2304745A
Other languages
English (en)
Inventor
David DE ABREU
Sébastien TAUPIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aura Blockchain Consortium
Original Assignee
Aura Blockchain Consortium
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aura Blockchain Consortium filed Critical Aura Blockchain Consortium
Priority to FR2304745A priority Critical patent/FR3148653A1/fr
Priority to EP24723894.2A priority patent/EP4710280A1/fr
Priority to KR1020257041438A priority patent/KR20260009896A/ko
Priority to PCT/EP2024/062565 priority patent/WO2024235744A1/fr
Priority to CN202480032143.2A priority patent/CN121195276A/zh
Publication of FR3148653A1 publication Critical patent/FR3148653A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G06Q30/0185—Product, service or business identity fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de : Réception par un premier dispositif client (2a) d’un premier utilisateur destinataire de la transaction d’une requête d’authentification d’un produit physique (1) associé de manière unique audit jeton non fongible ;Si ledit produit physique (1) est authentifié sur ledit premier dispositif client (2a), exécution de ladite transaction dans la base de données de type chaine de blocs [Fig. 1]

Description

Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique.
DOMAINE TECHNIQUE GÉNÉRAL
La présente invention se rapporte au domaine de la sécurisation des transactions. Plus précisément, elle concerne un procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs et un procédé de mise en œuvre d’une transaction portant sur un produit.
ETAT DE L’ART
Les produits de grandes marques de luxe (tels que des sacs à main, des bijoux, des montres, etc.) ont souvent, du fait de leur rareté, une valeur qui ne diminue que peu avec le temps et dans certains cas va même augmenter. Ainsi, ces produits sont plébiscités sur le marché de la revente, dit marché secondaire.
Le problème est que ce marché secondaire est parasité par la présence croissante de produits illégaux ou de contrefaçons, que des tiers mal intentionnés espèrent écouler au milieu des produits licites, ce qui est d’autant plus que les transactions sont le plus souvent de gré à gré, sans impliquer un professionnel qui serait capable d’expertiser le produit.
Pour résoudre ce problème, il a été proposé des solutions d’identification unique (et donc d’authentification) d’un produit :
  • Certains produits intègrent un élément physique tel qu’une étiquette RFID, ou un QR code, codant un identifiant unique du produit ;
  • On connait également des solutions dites de « fingerprinting » permettant de créer une identité numérique unique et infalsifiable d’un produit à partir d’une photo, notamment à partir des micro-défauts visibles ;
  • Plus récemment, des algorithmes d’intelligence artificielle spécifiquement entraînés permettent de reconnaître chaque exemplaire d’un produit.
Ces solutions apportent satisfaction et permettent à un acheteur potentiel de s’assurer que le produit qu’il va acheter est original et non une copie, mais ne permettent pas de s’assurer qu’il n’a pas été volé.
Les produits de luxe sont vendus avec un certificat qui vise justement à garantir la possession légale du produit, mais ces certificats sont eux-mêmes falsifiables et inversement le vendeur peut ne pas retrouver son certificat.
La présente invention vient améliorer la situation.
PRÉSENTATION DE L’INVENTION
La présente invention se rapporte donc selon un premier aspect à un procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :
  1. Réception par un premier dispositif client (2a) d’un premier utilisateur destinataire de la transaction d’une requête d’authentification d’un produit physique (1) associé de manière unique audit jeton non fongible ;
  2. Si ledit produit physique (1) est authentifié sur ledit premier dispositif client (2a), exécution de ladite transaction dans la base de données de type chaine de blocs.
Selon des caractéristiques avantageuses et non-limitatives :
Le procédé comprend la mise en œuvre d’une étape (b) de réception par un deuxième dispositif client d’un deuxième utilisateur à l’origine de la transaction d’une autre requête d’authentification du produit physique associé de manière unique audit jeton non fongible.
Soit l’étape (c) est mise en œuvre si ledit produit physique est authentifié sur ledit deuxième dispositif client, soit à l’étape (d) ladite transaction est exécutée si ledit produit physique est authentifié sur chacun du premier et du deuxième dispositif client.
L’étape (c) comprend la vérification de ladite authentification par une entité d’autorité.
L’étape (d) comprend le paiement d’un frais de gaz.
L’authentification dudit produit physique comprend au moins une de : la lecture d’un QR code porté le produit physique, la lecture d’une étiquette électronique portée par le produit physique, l’extraction d’une empreinte numérique d’une photo dudit produit physique et la reconnaissance dudit produit physique par un algorithme d’intelligence artificielle.
Ladite base de données de type chaine de blocs est la blockchain Ethereum® ou l’une de ses chaînes latérales, et ledit jeton non fongible est basé sur la norme ERC-721.
Le procédé est implémenté sous la forme d’un contrat intelligent.
Ledit contrat intelligent est contrôlé par un tiers de confiance, l’étape (d) comprenant le calcul et le paiement d’une royaltie au profit dudit tiers de confiance, en particulier conformément à la norme ERC-2981.
Le jeton non-fongible contient des métadonnées descriptives d’un historique dudit produit physique, l’étape (d) comprenant la mise à jour desdites métadonnées.
Selon un deuxième aspect, l’invention concerne un procédé de mise en œuvre d’une transaction relative au transfert d’un produit physique depuis un deuxième utilisateur à un premier utilisateur, caractérisé en ce qu’il comprend la mise en œuvre d’une étape (a) de requête, depuis un deuxième dispositif client du deuxième utilisateur, de transfert du deuxième utilisateur au premier utilisateur d’un jeton non fongible associé de manière unique audit produit physique, puis la mise en œuvre du procédé selon le premier aspect, dans lequel ladite transaction dans une base de données de type chaine de blocs étant un transfert dudit jeton non fongible du deuxième utilisateur au premier utilisateur.
Selon un troisième aspect, l’invention concerne un procédé de mise en œuvre d’une transaction relative à l’acquisition initiale par un premier utilisateur d’un produit physique , caractérisé en ce qu’il comprend la mise en œuvre d’une étape (a’) de requête de création d’un jeton non fongible associé de manière unique audit produit physique au profit du premier utilisateur, puis la mise en œuvre du procédé selon le premier aspect, dans lequel ladite transaction dans une base de données de type chaine de blocs étant la création dudit jeton non fongible au profit du premier utilisateur.
Selon un quatrième aspect, l’invention concerne un premier dispositif client d’un premier utilisateur destinataire d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, caractérisé en ce qu’il est configuré pour :
  • recevoir une requête d’authentification d’un produit physique associé de manière unique audit jeton non fongible ;
  • Si ledit produit physique est authentifié sur ledit premier dispositif client, exécuter de ladite transaction dans la base de données de type chaine de blocs.
Selon un cinquième aspect, l’invention concerne un ensemble d’un premier dispositif client selon le cinquième aspect et d’un deuxième dispositif client d’un deuxième utilisateur à l’origine de ladite transaction et configuré pour recevoir une autre requête d’authentification du produit physique associé de manière unique audit jeton non fongible.
Selon un sixième et un septième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible.
 PRÉSENTATION DES FIGURES
D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :
la est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ;
la est un schéma illustrant le transfert d’un NFT physique de l’état de l’art ;
la figure 2c est un schéma illustrant le transfert d’un PBT conforme à l’invention ;
la est un logigramme illustrant les étapes d’un premier mode de réalisation du procédé selon l’invention ;
la est un logigramme illustrant les étapes d’un deuxième mode de réalisation du procédé selon l’invention ;
la est un logigramme illustrant les étapes d’un troisième mode de réalisation du procédé selon l’invention.
 DESCRIPTION DÉTAILLÉE
Architecture
La présente invention concerne un procédé de mise en œuvre d’une transaction dans une base de données 3 de type chaine de blocs portant sur un jeton non fongible, qui comme on va le voir va être associé de manière unique à un produit physique 1, dans un système tel que représenté sur la , en particulier pour la mise en œuvre d’une transaction portant sur ledit produit 1. Ce produit physique peut être toute marchandise commercialisable, en particulier un produit de luxe tel qu’un sac à main, une montre, une paire de chaussures, etc. De manière préférée ledit produit physique 1 est authentifiable, voire identifiable de manière unique, on présentera des techniques à cet effet plus loin.
Ledit système comprend au moins un dispositif client 2a, 2b (généralement un grand nombre d’entre eux), jouant le rôle de « wallet », chacun étant un dispositif personnel d’un utilisateur lui permettant d’effectuer des transactions en son nom, par exemple envoyer ou recevoir des cryptomonnaies. A ce titre, chaque dispositif client 2a, 2b peut implémenter une application telle que MetaMask.
On a en particulier au moins un premier dispositif client 2a dit créditeur en tant que dispositif d’un premier utilisateur « acheteur » dans ladite transaction (destinataire de la transaction), et avantageusement un deuxième dispositif client 2b dit débiteur en tant que dispositif d’un deuxième utilisateur « vendeur » dans ladite transaction (à l’origine de la transaction). Ledit jeton non fongible et/ou ledit produit physique sont en d’autres termes transférés du deuxième utilisateur (du deuxième dispositif client 2b) au premier utilisateur (celui du premier dispositif client 2a). A noter qu’on verra un cas d’usage spécifique de création du jeton non fongible au profit du premier utilisateur (du premier dispositif client 2a).
Dans le présent cas, chaque dispositif client 2a, 2b est préférentiellement un dispositif physique léger tel qu’une carte à puce ou un terminal tel qu’un smartphone, en particulier un élément de sécurité (Secure Element) d’un tel terminal, c’est-à-dire un microprocesseur dédié fermé de type enclave. On comprendra que la présente invention n’est pas limitée à ces cas et que le dispositif client 2a, 2b peut toujours être un smartphone, une tablette tactile, un ordinateur personnel, etc. Chaque dispositif client 2a, 2b peut en outre comprendre une caméra et/ou un lecteur NFC ou RFID.
Les dispositifs 2a, 2b communiquent entre eux par l’intermédiaire d’au moins un réseau 20 par exemple le réseau Internet, un réseau cellulaire, ou une combinaison de tels réseaux. Ils ont chacun accès en lecture et en écriture à une base de données 3 de type chaîne de blocs stockée dans le réseau 20. On note qu’on a également dans le même cas des dispositifs valideurs de transactions, appelés « mineurs », qui sont connus de l’homme du métier et dont on ne parlera pas plus en détail.
La base de données 3 est publique, au sens où elle est libre d’accès en lecture non seulement par les dispositifs 2a, 2b en présence mais également à tout autre dispositif tiers. Tout dispositif tiers peut en particulier consulter les données écrites par l’un des dispositifs 2a, 2b.
Les bases de données de type « chaîne de blocs » servent généralement de base à des systèmes de transaction de monnaie électronique. Chaque dispositif client 2a, 2b mémorise une clé publique et une clé privée mutuellement associées et qui lui sont propres (et permettent d’effectuer des transactions sur la base de données 3 de type chaîne de blocs). La clé privée permet d’écrire des données signées dans la base de données ; elle est destinée à ne pas être communiquée à des tiers. La clé publique permet au dispositif 2a, 2b (et à tout autre titulaire d’un compte d’accès à la base de données 3) de vérifier qu’une donnée présente dans la base de données 3 a été écrite dans celle-ci par le dispositif 2a, 2b. Généralement, le dispositif client 2 est désigné par une adresse qui est typiquement une empreinte cryptographique de sa clé publique.
La base de données 3 est distribuée ou décentralisée dans le réseau 20, c’est-à-dire qu’elle est stockée par une pluralité de nœuds du réseau 20 avec lesquels les dispositifs 2a, 2b peuvent communiquer.
Une base de données de type chaîne de blocs (en anglais « blockchain ») est distribuée entre plusieurs nœuds de stockage d’un réseau. Les nœuds de stockage sont configurés pour valider des données écrites dans la base de données par la mise en œuvre d’une méthode de recherche de consensus entre les nœuds de stockage. Une telle méthode est par exemple la « preuve de travail » ou POW (« proof of work »), ou la « preuve d’enjeu « ou POS (« proof of stake »). Le contenu de la base de données (un historique de toutes les transactions passées effectuées entre des comptes d’utilisateurs du système) est ainsi protégé contre des falsifications et ce malgré son caractère distribué.
Les plus célèbres bases de données de type chaines de blocs sont les blockchain Bitcoin® ou Ethereum®, typiquement la seconde dans le cadre de la présente invention, ou toute autre blockchain compatible, c’est-à-dire basée sur l’EVM (Ethereum Virtual Machine), l’environnement d’exécution des instructions Ethereum (dans un langage tel que Solidity). On parle de « sidechains » (chaînes latérales), telles que Polygon ou Avalanche.
Par jeton non fongible, ou NFT (non-fongible token), on entend un type de jeton cryptographique transférable sur une blockchain, au même titre qu’une cryptomonnaie, mais unique et donc non-interchangeable contrairement à ce dernier. Les blockchain Ethereum (ou chaines latérales), mais également Solana ou Cardano sont les plus utilisés pour les NFTs.
Un NFT contient généralement une référence à un objet numérique tel qu’une image ou une vidéo, parfois artistique, dont il constitue en quelque sorte un certificat d’authenticité, et parfois des métadonnées. Il est prétendu qu’un NFT pourrait valoir propriété dudit objet numérique, mais il n’y a pas véritablement de base légale.
On appelle « mint » l’action de création d’un NFT, généralement au moyen d’un contrat intelligent (« smart contract ») sur la chaîne de blocs, par exemple conformément à la norme ERC-721 sur la blockchain Ethereum. En particulier, un jeton ERC-721 présente un paramètre tokenId le rendant unique (par opposition à un token fongible ERC-20 qui est un ETH standard, i.e. la cryptomonnaie native de la blockchain Ethereum). Comme toute autre transaction sur la chaine de blocs, le mint implique le paiement d’un « frais de gaz », pour récompenser les mineurs pour la puissance de calcul qu'ils doivent utiliser pour exécuter les transactions.
Principe
La présente invention propose un nouveau type de NFT, avantageusement toujours basé sur la norme ERC-721, qu’on appellera « jeton lié au produit », ou PBT (« product-bound token »), qui permet très astucieusement de garantir la propriété et l’authenticité d’un produit physique lors d’une transaction.
A noter qu’il est déjà connu d’associer un NFT à un produit physique (on parle de « physical NFT »), par exemple si la donnée numérique vers laquelle il pointe constitue un identifiant numérique unique dudit produit physique, par exemple celui codé par un QR code ou une étiquette RFID portée par le produit physique, comme expliqué dans l’introduction.
Cependant, comme l’on voit sur la , de tels NFT physiques n’apportent aucune solution au problème de la revente de produits contrefaits ou volés, et n’ont d’intérêt que publicitaire, puisque le NFT et le produit peuvent être revendus indépendamment. En pratique, dans l’objet de valeur est le NFT physique et le produit physique attaché est un « accessoire » souvent offert pour l’achat du NFT.
Au contraire, le PBT est un NFT accessoire à un produit physique (et non l’inverse), qui n’a en lui-même aucune valeur et qui n’est transférable que si l’acheteur apporte la preuve de la possession du produit lié, comme l’on voit sur la . Ainsi :
  • Si le produit est un faux, le transfert du NFT sera rejeté ;
  • Si le produit est volé, il ne sera pas revendable faute d’accès au NFT.
Procédé de mise en œuvre d’une transaction portant sur un NFT
La présente invention concerne comme expliqué selon un premier aspect un procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, i.e. un NFT, ici de type PBT.
En pratique, on a deux types de transactions possibles sur ledit jeton :
  • Soit un transfert du jeton du deuxième utilisateur au premier utilisateur, préférentiellement dans le cadre d’un transfert du produit physique 1 du deuxième utilisateur au premier utilisateur, représenté par les et 3b;
  • Soit la création du jeton (« mint ») par le deuxième utilisateur au profit du premier utilisateur, typiquement lors de la première mise en vente du produit physique 1 (le deuxième utilisateur est alors le fabricant du produit 1, i.e. la marque), représenté par la .
Les présents procédés sont dans tous les cas mis en œuvre par les moyens de traitement de données des dispositifs clients 2a et/ou 2b, typiquement sous la forme d’un contrat intelligent (« smart contrat ») tel que permis notamment par l’ecosystème Ethereum, en particulier via un centralisateur MTM (« multi-token minter ») qui permet de déployer des contrats intelligents via n’importe quelle blockchain publique. Alternativement, on peut passer par un tiers de confiance, i.e. une plateforme dédiée telle que OpenSea.
Les procédés présentent au moins une étape (c) de réception par le premier dispositif client 2a du premier utilisateur destinataire de la transaction d’une requête d’authentification du produit physique 1 associé de manière unique audit jeton non fongible, et (d) d’exécution de ladite transaction dans la base de données de type chaine de blocs si ledit produit physique 1 est authentifié sur ledit premier dispositif client 2a.
Par authentification du produit physique 1, on entend au moins la vérification de l’authenticité du produit physique 1, et avantageusement son identification, c’est-à-dire la vérification qu’il s’agit bien d’un exemplaire spécifique du produit. Dans les deux cas, on s’assure que le premier utilisateur s’est fait remettre le produit original et pas une contrefaçon.
Préférentiellement, ladite authentification est une authentification de proximité, impliquant la présence immédiate dudit produit physique 1, et en particulier une interaction directe du premier terminal 2a avec le produit. Cela permet de garantir que le deuxième utilisateur a bien entre les mains le produit 1 associé au PBT, i.e. que le deuxième utilisateur lui a par exemple remis en main propre ou envoyé par la poste.
A noter que certaines techniques d’authentification qui vont être présentées utilisent une photo qui est ainsi avantageusement acquise en direct par une caméra du premier dispositif client 12a, et non reçue depuis un terminal distant, ce qui pourrait entraîner des risques de falsification (on comprend de toute façon que le premier utilisateur n’aurait aucun intérêt à faire cela car il cherche justement à s’assurer qu’on lui a bien donné un produit authentique).
De manière préférée, l’authentification dudit produit physique 1 comprend au moins l’une de :
  • la lecture d’un QR code porté le produit physique 1 (par une caméra du premier dispositif client 2a). En particulier, on peut extraire du QR code un identifiant du produit, voire un identifiant unique de cet exemplaire du produit 1, et vérifier cet identifiant, notamment au moyen d’une fonction propriétaire de la marque dudit produit, le cas échéant en utilisant des données numériques directement contenues ou liées au PBT. Par exemple, on peut avoir une empreinte cryptographique (haché) d’un identifiant de référence du produit accessible via une URL contenue dans le PBT, dite empreinte cryptographique attendue (elle pourrait même être directement contenue dans le PBT), et on accomplit la vérification en hachant (avec une fonction de hachage prédéfinie) l’identifiant extrait du QR code et en comparant avec ladite empreinte cryptographique attendue
  • la lecture d’un étiquette électronique (aussi appelée « radio-étiquette », typiquement NFC ou RFID) portée par le produit physique 1, par exemple par un lecteur adéquat du dispositif client 2a. On peut utiliser le même mécanisme d’identifiant que pour le QR code ;
  • l’extraction d’une empreinte numérique d’une photo dudit produit physique 1. A nouveau on peut avoir une empreinte numérique de référence contenue ou accessible via le PBT, et utiliser un mécanisme de calcul de distance entre l’empreinte numérique extraite et l’empreinte attendue, notamment par logique floue (fuzzy logic). A nouveau, un tel mécanisme est connu de l’homme du métier.
  • la reconnaissance dudit produit physique 1 par un algorithme d’intelligence artificielle. On peut directement avoir des algorithmes d’IA tels que des réseaux de neurones de classification (typiquement des CNN) fournis par les marques des produits, prenant en entrée une photo du produit 1 permettant de directement répondre à la question de son authenticité, de manière sécurisée puisqu’en « boite noire ».
Dans le cas où la transaction est un transfert du PBT (figures 3a et 3b), on a avantageusement une étape préalable (b), similaire à l’étape (c), de réception par un deuxième dispositif client 2a d’un premier utilisateur à l’origine de la transaction d’une autre requête d’authentification d’un produit physique 1 associé de manière unique audit jeton non fongible. On note que cela est également le cas dans la . Cela permet de s’assurer sur le deuxième utilisateur (le vendeur) dispose bien d’un original, et donc ait le droit de transférer le PBT.
On utilise avantageusement les mêmes techniques d’authentification/identification du produit 1.
Dans un tel cas de double authentification :
  • soit l’étape (c) est mise en œuvre si (et en particulier seulement si) ledit produit physique 1 est authentifié sur ledit deuxième dispositif client 2b, comme représenté par la . En d’autres termes, à ce stade le deuxième utilisateur peut transférer le produit physique 1 au premier utilisateur, et cela déclenche la demande d’authentification par le premier utilisateur. C’est un schéma asymétrique, qui est typiquement utilisé si le produit est transféré par voie postale, et donc avec un délai (et celui représenté par la ). A l’étape (d) il suffit alors que le produit 1 soit authentifié sur le premier dispositif client 2a pour que la transaction puisse être exécutée.
  • soit à l’étape (d) ladite transaction est exécutée si (et en particulier seulement si) ledit produit physique 1 est authentifié sur chacun du premier et du deuxième dispositif client 2a, 2b, comme représenté sur la . En d’autres termes, les deux authentifications peuvent être faites simultanément ou presque, et on attend juste d’avoir les résultats des deux vérifications pour lancer l’exécution. Il s’agit d’un schéma symétrique, qui est typiquement utilisé lors d’une remise du produit 1 en main propre.
Dans tous les cas, l’étape (b) (si elle a lieu) et/ou l’étape (c) peut comprendre la vérification de ladite authentification par une entité d’autorité. Par entité d’autorité on entend soit le fabriquant du produit 1 (la marque), soit un tiers de confiance, par exemple un intermédiaire impliqué dans transaction, par exemple une place de marché.
La notion de vérification de ladite authentification par une entité d’autorité être ici interprétable au sens large et peut prendre de nombreuses formes :
  • selon un premier mode de réalisation, on peut avoir une troisième authentification à part entière, i.e. la présence d’une étape (c’) similaire aux étapes (b) et/ou (c) (pouvant avoir lieu n’importe quand avant l’étape (d)) de réception par un troisième dispositif client de l’entité d’autorité (potentiellement un serveur distant et automatisé, ou un terminal d’un employé de la marque) d’une autre requête d’authentification du produit physique 1 associé de manière unique audit jeton non fongible. Par exemple, chaque utilisateur peut mettre en œuvre une authentification via étiquette électronique, et en plus l’entité d’autorité peut mettre en œuvre une authentification à distance par reconnaissance dudit produit physique 1 par un algorithme d’intelligence artificielle gardé secret : le deuxième utilisateur effectue son authentification (b) et prend une photo qu’il transfère audit troisième dispositif client pour qu’il effectue. Ainsi, lorsque le premier utilisateur réceptionne le produit 1, il sait qu’il a été également authentifié par la marque, et il est encore plus convaincu de l’authenticité du produit lorsqu’il scanne son étiquette électronique à l’étape (c). Alternativement, l’échange peut se faire dans une boutique, et le vendeur authentifie également le produit 1.
Dans un tel mode de réalisation, à nouveau soit l’étape (b) ou l’étape (c) est mise en œuvre si ledit produit physique 1 est authentifié sur le troisième dispositif client de l’entité d’autorité (fonctionnement séquentiel), soit à l’étape (d) ladite transaction est exécutée si ledit produit physique 1 est authentifié sur chacun du premier et/ou du deuxième dispositif client 2a, 2b, et du troisième dispositif client (triple authentification).
  • selon un deuxième mode de réalisation, visible sur la , la première et/ou la deuxième authentification est contrôlée par l’entité d’autorité, et on peut prévoir que le cas échéant cette dernière signe la transaction, et que seule une transaction signée peut être exécutée à l’étape (d). Cela signifie que l’entité d’autorité certifie par exemple qu’un mécanisme d’authentification reconnu a été utilisé, et de façon correcte.
  • Selon un troisième mode de réalisation, l’entité d’autorité effectue des vérifications supplémentaires permettant d’observer le contexte de l’authentification, par exemple en analysant l’état d’usure du produit, en le comparant avec un carnet numérique d’entretien, en vérifiant une garantie, mais également en vérifiant une localisation de l’authentification si la transaction doit avoir lieu à un endroit précis, etc.
L’étape (d) comprend typiquement le paiement d’un frais de gaz (par le premier utilisateur, sur son dispositif client 2a). En d’autres termes, dès que la ou les authentifications requises sont faites, la transaction est exécutable, et c’est le premier utilisateur, qui a présent la conviction que le produit étant possédé légalement par le deuxième utilisateur et était un original, qui peut déclencher le transfert effectif du PBT en payant le frais de gaz. L’exécution de la transaction dans la blockchain est alors faite de manière classique : elle est vérifiée par les mineurs, et incluse dans le prochain bloc miné. Les mineurs encaissent le frais de gaz pour leur travail.
A noter que la transaction peut impliquer en sus le transfert de crypto monnaies du premier utilisateur au deuxième utilisateur en tant que paiement du transfert du PBT (et du produit physique 1), bien que comme l’on verra ce transfert peut impliquer un paiement classique hors de la blockchain, voire être à titre gratuit (cadeau).
L’étape (d) peut en outre comprendre, en particulier dans le cas d’un paiement en crypto monnaie et lorsque le contrat intelligent est contrôlé par un tiers de confiance, le calcul et le paiement d’une royaltie au profit dudit tiers de confiance, en tant que commission pour avoir assuré la transaction. Cela est typiquement permis par la norme ERC-2981.
Enfin, de manière particulièrement préférée, le jeton non-fongible contient des métadonnées descriptives d’un historique dudit produit physique, dites données de traçabilité. Elles peuvent comprendre l’historique de propriété du produit et/ou l’historique de réparation et d’entretien, le cas échéant de manière pseudo-anonymisée. Dans le cas, l’étape (d) comprend avantageusement la mise à jour desdites métadonnées, notamment en y rajoutant la transaction présentement effectuée. Cela permet d’avoir un enregistrement complet, public, et inaltérable de ce qui est arrivé au produit 1.
Procédé de mise en œuvre d’une transaction portant sur le produit physique
On va à présent décrire deux procédés de mise en œuvre d’une transaction relative au transfert du produit physique 1, impliquant le procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, selon le premier aspect.
Selon un deuxième aspect, ladite transaction relative au transfert du produit physique 1 est depuis un deuxième utilisateur à un premier utilisateur, c’est le cas de revente du produit physique 1.
En référence aux figures 3a et 3b, le procédé commence par une étape (a) de requête, depuis le deuxième dispositif client 2b du deuxième utilisateur, de transfert du jeton non fongible associé de manière unique audit produit physique 1 (le PBT), du deuxième utilisateur au premier utilisateur.
On comprend que cette étape n’est faisable que si le deuxième utilisateur dispose effectivement du PBT dans son wallet. Sinon, c’est que le produit 1 est volé. Elle s’effectue en particulier en identifiant le premier utilisateur sur le deuxième terminal 2b, notamment en renseignant une adresse publique de son wallet.
Ensuite, le procédé selon le premier aspect est mis en œuvre de sorte à mettre en œuvre le transfert dudit jeton non fongible du deuxième utilisateur au premier utilisateur en tant que transaction dans une base de données de type chaine de blocs objet du procédé (au moins les étapes (c) et (d), et préférentiellement l’étape (b)). D’ici à l’étape (c), le deuxième utilisateur doit avoir transmis le produit physique au premier utilisateur, le cas échéant contre paiement d’une somme d’argent, en échange de quelque chose, etc. De manière préférée, comme expliqué la transaction dans la base de données 3 de type chaine de blocs peut impliquer le transfert inverse de monnaie électronique du premier utilisateur au deuxième utilisateur en tant que paiement. Il peut alternativement s’agir d’un cadeau.
En résumé, le procédé selon le deuxième aspect est le suivant :
Procédé de mise en œuvre d’une transaction relative au transfert d’un produit physique 1 depuis un deuxième utilisateur à un premier utilisateur, caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :
  1. requête, depuis un deuxième dispositif client 2b du deuxième utilisateur, de transfert du deuxième utilisateur au premier utilisateur d’un jeton non fongible associé de manière unique audit produit physique 1,
  2. optionnellement, réception par le deuxième dispositif client 2b d’une requête d’authentification du produit physique 1 ;
  3. Réception par un premier dispositif client 2a du premier utilisateur d’une requête d’authentification du produit physique 1 ;
  4. Si ledit produit physique 1 est authentifié sur ledit premier dispositif client 2a (et le cas échéant sur le deuxième dispositif client 2b), exécution d’une transaction dans la base de données de type chaine de blocs de transfert dudit jeton non fongible du deuxième utilisateur au premier utilisateur.
Selon un troisième aspect, ladite transaction relative au transfert du produit physique 1 est l’acquisition initiale par un premier utilisateur d’un produit physique, c’est le cas d’un achat en boutique ou en ligne du produit physique 1 neuf.
En référence à la , le procédé commence par une étape (a’) de requête de création du jeton non fongible associé de manière unique audit produit physique 1 (le PBT), au profit du premier utilisateur. Il peut y avoir ou non un deuxième utilisateur, selon si cela est fait de manière unique, ou par un vendeur en boutique sur son dispositif client (qui est alors le deuxième dispositif client 2b, lequel est alors potentiellement confondu avec l’éventuel troisième dispositif client de l’entité d’autorité). Cette étape peut être déclenchée par le paiement du prix du produit physique neuf 1.
Ensuite, le procédé selon le premier aspect est à nouveau mis en œuvre de sorte à mettre en œuvre ladite création (« mint ») dudit jeton non fongible du deuxième utilisateur au premier utilisateur en tant que transaction dans une base de données de type chaine de blocs objet du procédé (au moins les étapes (c) et (d)).
En résumé, le procédé selon le trosième aspect est le suivant :
Procédé de mise en œuvre d’une transaction relative à l’acquisition initiale par un premier utilisateur d’un produit physique 1, caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :
(a’) requête de création d’un jeton non fongible associé de manière unique audit produit physique (1) au profit du premier utilisateur ;
  1. optionnellement, réception par un éventuel deuxième dispositif client 2b depuis lequel la requête de création aurait été émise, d’une requête d’authentification du produit physique 1 ;
  2. Réception par un premier dispositif client 2a du premier utilisateur d’une requête d’authentification du produit physique 1 ;
  3. Si ledit produit physique 1 est authentifié sur ledit premier dispositif client 2a (et le cas échéant sur le deuxième dispositif client 2b), exécution d’une transaction dans la base de données de type chaine de blocs de création dudit jeton non fongible au profit du premier utilisateur.
Dispositifs client
Selon un quatrième et/ou un cinquième aspects, l’invention concerne le premier et/ou le deuxième dispositif client 2a, 2b, et en particulier l’ensemble du premier et du deuxième dispositif client 2a, 2b, pour la mise en œuvre du procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, selon le premier aspect.
Le premier dispositif client 2a, d’un premier utilisateur destinataire d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, est configuré pour :
  • recevoir une requête d’authentification d’un produit physique 1 associé de manière unique audit jeton non fongible ;
  • Si ledit produit physique 1 est authentifié sur ledit premier dispositif client 2a, exécuter de ladite transaction dans la base de données de type chaine de blocs.
Le premier dispositif client 2b, d’un deuxième utilisateur à l’origine de ladite transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, est configuré pour :
  • Si ladite transaction est un transfert d’un jeton non fongible associé de manière unique audit produit physique 1, du deuxième utilisateur au premier utilisateur, requérir ce transfert jeton non fongible ; ou si la transaction est la création dudit jeton non fongible associé de manière unique audit produit physique 1, au profit du premier utilisateur, requérir cette création du jeton non-fongible ;
  • recevoir une éventuelle autre requête d’authentification du produit physique 1 associé de manière unique audit jeton non fongible.
Produit programme d’ordinateur
Selon un sixième et un septième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés des dispositifs client 2a et/ou 2b) d’un procédé selon le premier aspect de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible (voire les procédés selon le deuxième ou troisième aspect), ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les mémoires des dispositifs client 2a et/ou 2b) sur lequel on trouve ce produit programme d’ordinateur.

Claims (16)

  1. Procédé de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de :
    1. Réception par un premier dispositif client (2a) d’un premier utilisateur destinataire de la transaction d’une requête d’authentification d’un produit physique (1) associé de manière unique audit jeton non fongible ;
    2. Si ledit produit physique (1) est authentifié sur ledit premier dispositif client (2a), exécution de ladite transaction dans la base de données de type chaine de blocs.
  2. Procédé selon la revendication 1, comprenant la mise en œuvre d’une étape (b) de réception par un deuxième dispositif client (2b) d’un deuxième utilisateur à l’origine de la transaction d’une autre requête d’authentification du produit physique (1) associé de manière unique audit jeton non fongible.
  3. Procédé selon la revendication 2, dans lequel soit l’étape (c) est mise en œuvre si ledit produit physique (1) est authentifié sur ledit deuxième dispositif client (2b), soit à l’étape (d) ladite transaction est exécutée si ledit produit physique (1) est authentifié sur chacun du premier et du deuxième dispositif client (2a, 2b).
  4. Procédé selon l’une des revendications 1 à 3, dans lequel l’étape (c) comprend la vérification de ladite authentification par une entité d’autorité.
  5. Procédé selon l’une des revendications 1 à 4, dans lequel l’étape (d) comprend le paiement d’un frais de gaz.
  6. Procédé selon l’une des revendications 1 à 5, dans lequel l’authentification dudit produit physique (1) comprend au moins une de : la lecture d’un QR code porté le produit physique (1) la lecture d’une étiquette électronique portée par le produit physique (1), l’extraction d’une empreinte numérique d’une photo dudit produit physique (1) et la reconnaissance dudit produit physique (1) par un algorithme d’intelligence artificielle.
  7. Procédé selon l’une des revendications 1 à 6, dans lequel ladite base de données de type chaine de blocs est la blockchain Ethereum® ou l’une de ses chaînes latérales, et ledit jeton non fongible est basé sur la norme ERC-721.
  8. Procédé selon l’une des revendications 1 à 7, implémenté sous la forme d’un contrat intelligent.
  9. Procédé selon la revendication 8, dans lequel ledit contrat intelligent est contrôlé par un tiers de confiance, l’étape (d) comprenant le calcul et le paiement d’une royaltie au profit dudit tiers de confiance, en particulier conformément à la norme ERC-2981.
  10. Procédé selon l’une des revendications 1 à 9, dans lequel le jeton non-fongible contient des métadonnées descriptives d’un historique dudit produit physique, l’étape (d) comprenant la mise à jour desdites métadonnées.
  11. Procédé de mise en œuvre d’une transaction relative au transfert d’un produit physique (1) depuis un deuxième utilisateur à un premier utilisateur, caractérisé en ce qu’il comprend la mise en œuvre d’une étape (a) de requête, depuis un deuxième dispositif client (2b) du deuxième utilisateur, de transfert du deuxième utilisateur au premier utilisateur d’un jeton non fongible associé de manière unique audit produit physique (1), puis la mise en œuvre du procédé selon l’une des revendication 1 à 10, dans lequel ladite transaction dans une base de données de type chaine de blocs étant un transfert dudit jeton non fongible du deuxième utilisateur au premier utilisateur.
  12. Procédé de mise en œuvre d’une transaction relative à l’acquisition initiale par un premier utilisateur d’un produit physique (1), caractérisé en ce qu’il comprend la mise en œuvre d’une étape (a’) de requête de création d’un jeton non fongible associé de manière unique audit produit physique (1) au profit du premier utilisateur, puis la mise en œuvre du procédé selon l’une des revendication 1 à 10, dans lequel ladite transaction dans une base de données de type chaine de blocs étant la création dudit jeton non fongible au profit du premier utilisateur.
  13. Premier dispositif client (2a) d’un premier utilisateur destinataire d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, caractérisé en ce qu’il est configuré pour :
    • recevoir une requête d’authentification d’un produit physique (1) associé de manière unique audit jeton non fongible ;
    • Si ledit produit physique (1) est authentifié sur ledit premier dispositif client (2a), exécuter de ladite transaction dans la base de données de type chaine de blocs.
  14. Ensemble d’un premier dispositif client (2a) selon la revendication 10 et d’un deuxième dispositif client (2b) d’un deuxième utilisateur à l’origine de ladite transaction et configuré pour recevoir une autre requête d’authentification du produit physique (1) associé de manière unique audit jeton non fongible.
  15. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible, lorsque ledit programme est exécuté sur un ordinateur.
  16. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 de mise en œuvre d’une transaction dans une base de données de type chaine de blocs, portant sur un jeton non fongible.
FR2304745A 2023-05-12 2023-05-12 Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique. Pending FR3148653A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR2304745A FR3148653A1 (fr) 2023-05-12 2023-05-12 Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique.
EP24723894.2A EP4710280A1 (fr) 2023-05-12 2024-05-07 Procédé de mise en ?uvre d'une transaction portant sur au moins un jeton non fongible associé de manière unique à un produit physique
KR1020257041438A KR20260009896A (ko) 2023-05-12 2024-05-07 물리적 제품과 고유하게 연관된 적어도 하나의 대체 불가능 토큰과 관련된 트랜잭션을 수행하기 위한 방법
PCT/EP2024/062565 WO2024235744A1 (fr) 2023-05-12 2024-05-07 Procédé de mise en œuvre d'une transaction portant sur au moins un jeton non fongible associé de manière unique à un produit physique
CN202480032143.2A CN121195276A (zh) 2023-05-12 2024-05-07 用于执行与物理产品唯一关联的至少一个非同质化代币相关的交易的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2304745 2023-05-12
FR2304745A FR3148653A1 (fr) 2023-05-12 2023-05-12 Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique.

Publications (1)

Publication Number Publication Date
FR3148653A1 true FR3148653A1 (fr) 2024-11-15

Family

ID=87555036

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2304745A Pending FR3148653A1 (fr) 2023-05-12 2023-05-12 Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique.

Country Status (5)

Country Link
EP (1) EP4710280A1 (fr)
KR (1) KR20260009896A (fr)
CN (1) CN121195276A (fr)
FR (1) FR3148653A1 (fr)
WO (1) WO2024235744A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210248653A1 (en) * 2020-02-07 2021-08-12 Citizens Reserve, Inc. Authentication of products
US11374756B1 (en) * 2021-07-12 2022-06-28 CreateMe Technologies LLC Tracking apparel items using distributed ledgers
US20230109574A1 (en) * 2021-10-04 2023-04-06 Ebay Inc. Fingerprinting Physical Items to Mint NFT's
US20230145439A1 (en) * 2021-11-05 2023-05-11 In-Soo SUK Method of providing real asset authentication service using decentralized identifier and non-fungible token

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11700123B2 (en) * 2020-06-17 2023-07-11 Alitheon, Inc. Asset-backed digital security tokens

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210248653A1 (en) * 2020-02-07 2021-08-12 Citizens Reserve, Inc. Authentication of products
US11374756B1 (en) * 2021-07-12 2022-06-28 CreateMe Technologies LLC Tracking apparel items using distributed ledgers
US20230109574A1 (en) * 2021-10-04 2023-04-06 Ebay Inc. Fingerprinting Physical Items to Mint NFT's
US20230145439A1 (en) * 2021-11-05 2023-05-11 In-Soo SUK Method of providing real asset authentication service using decentralized identifier and non-fungible token

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BURKS ZACH ET AL: "ERC-2981: NFT Royalty Standard", 3 May 2023 (2023-05-03), pages 1 - 8, XP093085062, Retrieved from the Internet <URL:https://web.archive.org/web/20230503063041/https://eips.ethereum.org/EIPS/eip-2981> [retrieved on 20230922] *

Also Published As

Publication number Publication date
WO2024235744A1 (fr) 2024-11-21
CN121195276A (zh) 2025-12-23
EP4710280A1 (fr) 2026-03-18
KR20260009896A (ko) 2026-01-20

Similar Documents

Publication Publication Date Title
US11720907B2 (en) Blockchain-based product authentication system
US20220215382A1 (en) Blockchain-based product authentication system
EP1875446B1 (fr) Dispositif, procede et systeme de securite pour transactions financieres, reposant sur l&#39;identification d&#39;un individu grâce a son profil bio-metrique, et utilisant une carte a microprocesseur
US20230177489A1 (en) Utilization of biometrics in creation of secure key or digital signature
US20150310426A1 (en) Bit Currency: Transactional Trust Tools
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
EP0708949A1 (fr) Procede pour produire une cle commune dans deux dispositifs en vue de mettre en uvre une procedure cryptographique commune, et appareil associe
EP3488390B1 (fr) Procédé de communication rfid sécurisée
WO2006092539A2 (fr) Securisation de donnees pour programmes de fidelisation de clientele
FR3054055B1 (fr) Procede de traitement d&#39;au moins une donnee de moyen de paiement, terminal de paiement et programme d&#39;ordinateur correspondant
FR3148653A1 (fr) Procédé de mise en œuvre d’une transaction portant sur un jeton non fongible associé de manière unique à un produit physique.
EP2724305B1 (fr) Procede de transaction dematerialisee
FR3002056A1 (fr) Authentification de signature manuscrite numerisee.
EP3284209B1 (fr) Procédés de génération et de vérification d&#39;une clé de sécurité d&#39;une unité monétaire virtuelle
WO1998044464A1 (fr) Procede de certification d&#39;un cumul dans un lecteur
WO2022122821A1 (fr) Dispositif et procédé d&#39;authentification de produits
WO2017077210A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
FR3160492A1 (fr) Procédé pour la mise en œuvre d’une transaction, sur un terminal de paiement électronique d’un marchand.
EP4441954A1 (fr) Procédé de traitement de preuve numérique, système et programme correspondant
EP4241190A1 (fr) Procede d&#39;authentification securise par le decouplage structurel des identifiants personnels et de services
FR3160491A1 (fr) Procédé pour l’initialisation d’un terminal de paiement électronique d’un marchand.
FR3113323A1 (fr) Procede pour generer un document numerique securise stocke sur un terminal mobile et associe a une identite numerique
FR2814575A1 (fr) Procedes et systemes d&#39;identification, de chiffrement et de paiement electronique notamment a l&#39;aide de supports homologues detenant un secret partage s&#39;identifiant mutuellement
WO2008003886A1 (fr) Module electronique pour le stockage de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20241115

PLFP Fee payment

Year of fee payment: 3