FR3143144A1

FR3143144A1 - Procédé de vente de jetons non-fongibles sur une chaîne de blocs

Info

Publication number: FR3143144A1
Application number: FR2213088A
Authority: FR
Inventors: José LUU; Cyril VIGNET
Original assignee: BPCE SA
Current assignee: BPCE SA
Priority date: 2022-12-09
Filing date: 2022-12-09
Publication date: 2024-06-14

Abstract

L’invention concerne un procédé qui prévoit : la création d’un coffre-fort numérique (16) de gestion de jetons non-fongibles (2) pour un créateur (1) sur la chaine de blocs ; lors de la création d’un jeton non-fongible (2) par le créateur (1), l’enregistrement d’une information liée dans le coffre-fort numérique (16), en l’associant à : une adresse numérique (10) détenue par le créateur (1) sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible (2) ; et une valeur rationnelle d’un montant d’achat en cryptomonnaie à verser en rétribution audit créateur ; puis, lorsqu’un utilisateur (3) souhaite acheter un jeton non-fongible (2) du créateur (1) : le transfert d’un montant en cryptomonnaie requis, par l’intermédiaire du coffre-fort numérique (16) ; l’enregistrement dans le coffre-fort numérique (16) de gestion d’une adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible. Figure 3

Description

Procédé de vente de jetons non-fongibles sur une chaîne de blocs

L’invention concerne un procédé pour permettre à un créateur de vendre des jetons non-fongibles (NFT, pour l’anglais « non fungible token ») à des utilisateurs sur une chaîne de blocs, ainsi qu’une architecture comprenant des moyens pour mettre en œuvre un tel procédé.

Les jetons non fongibles correspondent à des représentations numériques de bien sur une chaîne de blocs (pour l’anglais « blockchain »), assimilables à un titre de propriété desdits biens. Ces biens peuvent être des objets physiques, tels que par exemple des œuvres d’art ou des biens immobiliers, des éléments numériques, tels que par exemple des images ou des photographies, ou encore des éléments mixtes, notamment des objets connectés à Internet® (IoT, pour l’anglais « Internet of Things »).

Une telle représentation permet au propriétaire d’un tel bien de l’échanger ou de le vendre à un autre utilisateur présent sur la chaîne de blocs de manière sécurisée, en effectuant la transmission de cette représentation numérique peut en parallèle de celle dudit bien, notamment contre une somme en monnaie scripturale ou en cryptomonnaie. En effet, la duplication d’un jeton non-fongible étant impossible, cette procédure permet d’annuler le risque de contrefaçon du titre de propriété.

Les architectures connues d’échange de biens et de jetons non-fongibles sur une chaîne de blocs reposent généralement sur des plateformes de commerce en ligne, ce qui représente un risque de fraude non négligeable. En particulier, elles ne donnent pas entière satisfaction tant pour la protection du créateur des biens vendus que pour leurs acheteurs, qui ne disposent pas de garantie suffisante quant à l’identité dudit créateur et l’authenticité des œuvres vendues.

Par ailleurs, avec ces solutions existantes, le créateur ne dispose pas de moyens pour pouvoir superviser de manière simple et fiable la logistique de vente de ses biens.

L’invention vise à perfectionner l’art antérieur en proposant notamment un procédé pour permettre à des utilisateurs d’échanger des jetons non-fongibles sur une chaîne de blocs via un système intégré de vente qui permet de s’affranchir des plateformes de commerce en ligne classiques, ledit système permettant en outre d’assurer une rétribution automatique du créateur de tels jetons sur toute la chaîne de ventes successives desdits jetons, mais également d’assurer un suivi logistique précis retraçant les responsables et propriétaires intermédiaires de chaque transaction.

A cet effet, selon un premier aspect, l’invention propose un procédé pour permettre à un créateur de vendre des jetons non-fongibles à des utilisateurs sur une chaîne de blocs, ledit procédé prévoyant :

la création d’un coffre-fort numérique de gestion de jetons non-fongibles pour le créateur sur la chaine de blocs ;
lors de la création d’un jeton non-fongible par le créateur, l’enregistrement d’une information liée au jeton non-fongible dans le coffre-fort numérique de gestion de jetons non-fongibles, en l’associant à :
- une adresse numérique détenue par le créateur sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible ;
- une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur lors d’une vente dudit jeton non-fongible ;

ledit procédé prévoyant en outre, lorsqu’un utilisateur souhaite acheter un jeton non-fongible du créateur :

le transfert par ledit utilisateur d’un montant en cryptomonnaie requis pour ledit achat par l’intermédiaire du coffre-fort numérique de gestion de jetons non-fongibles, afin de transférer audit créateur un montant rationnel de rétribution prélevé sur le montant d’achat requis en fonction de la valeur rationnelle associée au jeton non-fongible, le reste dudit montant d’achat requis étant transféré au propriétaire actuel dudit jeton non-fongible ;
en cas de succès de l’achat, l’enregistrement dans le coffre-fort numérique de gestion d’une adresse numérique dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.

Selon un second aspect, l’invention propose une architecture pour permettre à un créateur de vendre des jetons non-fongibles à des utilisateurs sur une chaîne de blocs, ladite architecture comprenant :

une plateforme de déploiement de coffres-forts numériques sur la chaîne de blocs ;
un terminal comprenant, notamment au moyen d’une application installée sur ledit terminal, des moyens pour permettre au créateur de :
- solliciter la plateforme de déploiement pour créer un coffre-fort numérique de gestion de jetons non-fongibles pour ledit créateur sur la chaine de blocs ;
- lors de la création d’un jeton non-fongible par ledit créateur, enregistrer une information liée audit jeton non-fongible dans le coffre-fort numérique de gestion de jetons non-fongibles, en l’associant à :
  - une adresse numérique détenue par le créateur sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible ;
  - une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur lors d’une vente dudit jeton non-fongible ;
un terminal comprenant des moyens pour permettre à un utilisateur souhaitant acheter un jeton non-fongible du créateur de transférer un montant en cryptomonnaie requis pour ledit achat par l’intermédiaire du coffre-fort numérique de gestion de jetons non-fongibles ;

le coffre-fort numérique étant agencé pour transférer audit créateur un montant rationnel de rétribution prélevé sur le montant d’achat requis en fonction de la valeur rationnelle associée au jeton non-fongible, et transférer le reste dudit montant d’achat requis au propriétaire actuel dudit jeton non-fongible ;

au moins l’un des terminaux comprenant des moyens pour, en cas de succès de l’achat, enregistrer dans le coffre-fort numérique de gestion une adresse numérique dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.

D’autres particularités et avantages de l’invention apparaîtront dans la description qui suit, faite en référence aux figures annexées, dans lesquelles :

représente schématiquement les étapes de création d’un coffre-fort numérique de gestion de jetons non-fongibles pour un créateur sur la chaîne de blocs, dans un procédé selon un mode de réalisation de l’invention ;

représente schématiquement un organigramme d’enregistrement, au sein de chaque coffre-fort numérique de gestion de jetons non-fongibles créé sur la chaîne de blocs, des adresses numériques du créateur de jetons non-fongible possédant ledit coffre-fort numérique de gestion et de l’adresse numérique du serveur répertoire de l’architecture représentée sur la , dans lequel sont enregistrées des informations liées aux jetons non-fongibles gérés par ledit coffre-fort numérique de gestion, selon un mode de réalisation de l’invention ;

représente schématiquement les étapes de création et d’enregistrement d’un jeton non-fongible par son créateur sur la chaîne de blocs, dans l’architecture des figures 1 et 2 ;

représente schématiquement les étapes de connexion d’un créateur de jetons non-fongibles à son coffre-fort numérique de gestion de ses jetons non-fongibles sur la chaîne de blocs, dans l’architecture des figures précédentes ;

et

représentent schématiquement différentes étapes pour permettre à un utilisateur présent sur la chaîne de blocs de respectivement visualiser un fichier numérique d’un jeton non-fongible enregistré dans le serveur répertoire des figures précédentes ( ) et consulter la liste des coffres-forts numériques de gestion de jetons non fongibles répertoriés sur ledit serveur ( ) ;

représente schématiquement et de façon simplifiée la structure interne du coffre-fort numérique de gestion des jetons non fongibles des figures précédentes, et notamment de la sous-liste de détention d’un jeton non-fongible donné référencé dans ce coffre-fort numérique de gestion, respectivement avant (à gauche) et après (à droite) sa vente à un autre utilisateur sur la chaîne de blocs ;

représente schématiquement la liaison, au sein du coffre-fort numérique de gestion des jetons non fongibles des figures précédentes, entre une liste principale répertoriant tous les jetons non fongibles du créateur et deux sous-listes secondaires propre à un unique jeton fongible de ladite liste principale, qui concernent chacune respectivement les ventes dudit jeton-fongible et ses propriétaires successifs ;

représente schématiquement les étapes de vente d’un jeton non-fongible entre son créateur et l’utilisateur l’ayant acheté sur la chaîne de blocs, et notamment le contenu des sous-listes de vente et de détention de ce jeton non-fongible, respectivement avant (à gauche) et après (à droite) ladite vente ;

et

représentent schématiquement les sous-listes secondaires de la , respectivement la sous-liste de vente d’un jeton non-fongible donné ( ) et la sous-liste de détention listant les propriétaires successifs dudit jeton non-fongible ( ).

En relation avec ces figures, on décrit ci-dessous un procédé pour permettre à un créateur 1 de vendre des jetons non-fongibles 2 à des utilisateurs 3 sur une chaîne de blocs, ainsi qu’une architecture comprenant des moyens techniques pour permettre la mise en œuvre d’un tel procédé.

L’architecture comprend une plateforme 4 liée à la chaîne de blocs, qui comprend une interface de programmation d’applications (API, pour l’anglais « Application Programming Interface ») réalisant l’activation des moyens techniques pour recevoir des requêtes de créateurs 1 et d’utilisateurs 3 connectés à la chaîne de blocs, cette dernière étant formée par un ensemble de plateformes de communication et de calcul permettant son fonctionnement, et servant de moyens d’accès à ladite chaîne de blocs.

L’architecture comprend en outre au moins un terminal 5, 6 équipé de moyens pour permettre à un utilisateur 3 ou un créateur 1 d’interagir avec la chaîne de blocs et/ou la plateforme 4, notamment pour envoyer des requêtes telles que susmentionnées.

Comme représenté sur les figures, le terminal 5, 6 peut être un téléphone portable de type « intelligent » (pour l’anglais « smartphone »). Le terminal 5, 6 peut également être d’un autre type, notamment une tablette numérique, un assistant personnel (PDA, pour l’anglais « Personal Digital Assistant »), un ordinateur portable ou un ordinateur de bureau, sous réserve d’être équipé de moyens techniques adaptés pour la mise en œuvre du procédé.

En particulier, l’architecture peut comprendre au moins une application avec des moyens adaptés pour la mise en œuvre du procédé, que l’utilisateur 3 ou le créateur 1 peut télécharger pour l’installer sur son terminal 5, 6, notamment en envoyant une requête adaptée à ladite architecture.

Pour pouvoir interagir avec la chaîne de blocs, le créateur 1 ou l'utilisateur 3 doit générer une paire de clés privée 7a et publique 7b, 8, notamment lors de sa première connexion à ladite chaîne de blocs et en cas de perte ou de vol de ses précédentes clés. La clé privée 7a est tenue secrète par son propriétaire (créateur 1 ou utilisateur 3) et la clé publique 7b, 8 permet audit propriétaire d’interagir avec la chaîne de blocs pour y effectuer des opérations. En particulier, une adresse numérique personnelle est dérivable de la clé publique 7b, 8 pour représenter son propriétaire 1, 3 sur la chaîne de blocs.

Pour générer de telles clés 7a, 7b, 8, le créateur 1 ou l'utilisateur 3 peut lancer une procédure adaptée sur son terminal 5, 6 notamment au moyen de l’application décrite précédemment. Les clés 7a, 7b, 8 sont ainsi liées au terminal 5, 6 au sein duquel elles sont générées sous le contrôle du créateur 1 ou de l'utilisateur 3, qui n’utilise que la clé publique 7b, 8. De ce fait, la clé privée 7a ne quitte jamais le terminal 5, 6, ce qui garantit à son propriétaire 1, 3 une sécurité optimale.

Pour finaliser ou mettre à jour son adhésion à la chaîne de blocs, le créateur 1 ou l’utilisateur 3 enregistre sa clé publique 7b, 8 sur ladite chaîne de blocs. En particulier, le créateur 1 ou l’utilisateur 3 peut effectuer cet enregistrement en associant sa clé publique 7b, 8 à une empreinte numérique liée à l’identité dudit utilisateur.

Pour ce faire, le créateur 1 ou l’utilisateur 3 peut authentifier son identité auprès d’une plateforme tierce (non représentée), afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée sur la chaîne de blocs pour être associée avec la clé publique 7b, 8.

La plateforme tierce présente un niveau de confiance qui peut être évalué dans le cadre de la réglementation eIDAS (pour l’anglais « Electronic IDentification And Trust Services ») ou de tout autre système d’évaluation de la confiance basé sur l’identité, et peut être par exemple une plateforme de fourniture d’un service d’identification publique et/ou administratif tel que la sécurité sociale, un service pour le paiement de taxes officielles telles que les impôts sur le revenu, ou tout autre service d’identification permettant d’atteindre le niveau de confiance eIDAS requis par les utilisateurs, ou encore tout autre système fournissant une identité, par exemple un système d’identification des employés d’une entreprise. En particulier, la plateforme tierce peut fournir pour le créateur 1 ou l’utilisateur 3 un identifiant unique, notamment basé sur les données d’identité.

Cet enregistrement peut notamment être effectué dans un coffre-fort numérique personnel 9 détenu par le créateur 1 ou l’utilisateur 3 sur la chaîne de blocs, comme représenté sur les figures, en relation avec les clés 7a, 7b détenues par le créateur 1.

Le créateur 1 ou l’utilisateur 3 peut créer un tel coffre-fort personnel 9 pour pouvoir interagir ultérieurement avec la chaîne de blocs uniquement au moyen de l’adresse numérique 10, 11 dudit coffre-fort personnel, ce qui permet audit créateur ou utilisateur d’enregistrer plusieurs clés publiques 7b, 8 dans un même coffre-fort personnel 9 et d’accéder à la chaîne de blocs avec n’importe laquelle desdites clés, et donc d’éviter la perte de son accès à la chaîne de blocs en cas de perte et/ou de vol de ses clés 7a, 7b, 8 et/ou de son terminal 5, 6.

Pour ce faire, l’architecture comprend une plateforme pour le déploiement de coffres-forts sur la chaîne de blocs, le terminal 5, 6 et/ou l’application comprenant des moyens pour solliciter ladite plateforme de déploiement pour créer un coffre-fort personnel 9, notamment par l’envoi d’une requête adaptée (non représentée).

Dans le mode de réalisation représenté, cette fonctionnalité est réalisée par la plateforme 4 d’accès à la chaîne de blocs, qui comprend des moyens techniques adaptés pour réaliser le déploiement de coffres-forts 9 sur requête de tout utilisateur 3 ou créateur 1 présent sur ladite chaîne de blocs. En variante, l’architecture peut comprendre une plateforme additionnelle de déploiement de coffres-forts qui est distincte de la plateforme 4 d’accès à la chaîne de blocs.

Tous les coffres-forts numériques de l’architecture peuvent être créés sous la forme de protocoles informatiques de type contrats intelligents (pour l’anglais « smart contract »), qui sont accessibles sur la chaîne de blocs au moyen d’une adresse numérique publique.

La plateforme de déploiement 4 comprend une interface de programmation d’applications (API), qui comprend des moyens techniques adaptés pour permettre la création de coffres-forts sur la chaîne de blocs.

De façon avantageuse, la plateforme de déploiement 4 est agencée pour permettre la création automatique de coffres-forts numériques sur simple requête d’un utilisateur 3 ou créateur 1. A cet effet, comme représenté sur les figures 1 à 6, l’architecture comprend :

un coffre-fort numérique 12 lié à la plateforme de déploiement 4, dans lequel est enregistré au moins un identifiant de ladite plateforme de déploiement sur la chaîne de blocs, par exemple une adresse numérique dérivée d’une clé publique 13 d’accès de ladite plateforme à ladite chaîne de blocs ;
un coffre-fort numérique central 14, qui comprend notamment :
- une liste répertoriant les plateformes de déploiement de coffres-forts appartenant à un réseau de confiance, ladite liste comprenant les adresses numériques des coffres-forts liés à chacune de ces plateformes de confiance, notamment l’adresse numérique 15 du coffre-fort 12 lié à la plateforme 4 représentée ; et
- une liste répertoriant l’ensemble des coffres-forts numériques créés par ces plateformes de confiance sur la chaîne de blocs, ladite liste comprenant des entrées qui contiennent chacune l’adresse numérique d’un coffre-fort créé par une plateforme de déploiement, associée à l’adresse numérique du coffre-fort lié à cette plateforme de déploiement, et notamment une entrée comprenant l’adresse 10 du coffre-fort personnel 9 du créateur 1 associé à l’adresse numérique 15 du coffre-fort 12 présenté ci-dessus.

En variante, la plateforme de déploiement 4 peut être agencée pour permettre la création de coffres-forts numériques par un administrateur de la chaîne de blocs, notamment suite à la réception d’une requête de sollicitation par un utilisateur 3 ou un créateur 1.

Après création de son coffre-fort numérique personnel 9, le créateur 1 peut authentifier son identité auprès de la plateforme tierce décrite précédemment, afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée dans ledit coffre-fort numérique personnel par la plateforme de déploiement 4.

A l’issue de cet enregistrement, la plateforme de déploiement 4 envoie au créateur 1 une notification contenant l’adresse numérique publique 10 de son coffre-fort personnel 9, afin que ledit créateur puisse accéder audit coffre-fort personnel au moyen de ladite adresse numérique.

Le procédé prévoit en outre, lorsqu’un créateur 1 présent sur la chaîne de blocs souhaite y créer des jetons non-fongibles 2, de créer un coffre-fort numérique 16 spécifique pour ledit créateur sur ladite chaîne de blocs, afin de permettre audit créateur de gérer ses jetons non-fongibles 2 au moyen dudit coffre-fort de gestion.

Pour ce faire, le terminal 5 du créateur 1 comprend des moyens pour permettre audit créateur de solliciter une plateforme de déploiement présente sur la chaîne de blocs, notamment la plateforme 4 représentée sur les figures, afin de créer un tel coffre-fort numérique 16 pour la gestion de ses jetons non-fongibles 2.

En particulier, le procédé prévoit d’enregistrer l’adresse numérique du coffre-fort personnel 9 du créateur 1 en tant qu’adresse parente dans le coffre-fort numérique 16 de gestion des jetons non-fongibles 2 dudit créateur lors de la création dudit coffre-fort numérique de gestion. Pour ce faire, la plateforme 4 comprend des moyens adaptés pour effectuer cet enregistrement dans le coffre-fort 16 lors de sa création.

En relation avec la , lorsqu’il souhaite créer des jetons non-fongibles 2 sur la chaîne de blocs, le créateur 1, après s’être connecté à ladite chaîne de blocs via la plateforme 4, envoie à ladite plateforme au moyen de son terminal 5 ou de l’application une requête 17 contenant l’adresse numérique 10 de son coffre-fort personnel 9, afin de solliciter ladite plateforme pour la création d’un coffre-fort 16 pour l’aider à gérer ses jetons non-fongibles 2.

La plateforme 4 crée ensuite un coffre-fort 16 de gestion, notamment sous la forme d’un contrat intelligent avec des fonctionnalités adaptées pour permettre au créateur 1 de gérer facilement ses jetons non-fongibles 2, parmi lesquelles :

un suivi des mises à jour des caractéristiques de ses jetons non-fongibles 2, afin de fournir audit créateur une meilleure visibilité desdites mises à jour ;
la possibilité de vendre les jetons non-fongibles 2 à d’autres utilisateurs 3 de la chaîne de blocs en établissant une relation directe « de pair à pair » (pour l’anglais « peer to peer »), sans recourir à une plateforme de commerce en ligne intermédiaire ;
un suivi de la logistique des biens correspondant aux jetons non-fongibles 2.

Durant la création du coffre-fort 16, la plateforme 4 y enregistre, notamment au sein d’une liste numérique dédiée, plusieurs variables en plus de l’adresse numérique 10 du coffre-fort personnel 9, parmi lesquelles :

la clé publique 13 identifiant la plateforme 4 sur la chaîne de blocs ;
l’adresse numérique 15 du coffre-fort 12 lié à ladite plateforme sur la chaîne de blocs ;
un code identifiant la version logicielle dudit coffre-fort de gestion ;
un identifiant client du créateur 1 sur la chaîne de blocs ;
un code de programme (pour l’anglais « scheme code ») indiquant le format autorisé pour les adresses numériques enregistrées dans le coffre-fort 16, notamment les adresses parentes respectives du créateur 1 détenant ce coffre-fort 16 et la plateforme 4 l’ayant déployé, ledit code étant choisi parmi :
- un code « false », permettant d’enregistrer dans le coffre-fort 16 des adresses numériques directement dérivées de clés privée et publique générées lors d’un premier accès à la chaîne de blocs, notamment les clés publiques 7b, 13 du créateur 1 et de la plateforme 4, ou plus généralement des clés d’accès liés à des comptes externes (EOA, pour l’anglais « Externally Owned Account ») de la chaîne de blocs ;
- un code « true », qui restreint l’enregistrement dans le coffre-fort 16 à des adresses numériques identifiées dans le coffre-fort central 14, notamment les adresses numériques 10, 15 du coffre-fort personnel 9 du créateur 1 et du coffre-fort 12 lié à la plateforme 4 ;
un code d’activation du coffre-fort 16, qui peut être modifié uniquement par le créateur 1, via l’adresse parente 10, 7b, ou par la plateforme 4, via son adresse numérique 13 ou l’adresse numérique 15 de son coffre-fort 12 ;
le nombre maximal de jetons non-fongibles 2 pouvant être gérés par le coffre-fort 16.

La plateforme 4, après avoir créé le coffre-fort de gestion 16, envoie en retour au terminal 5 ou à l’application une notification 18 contenant l’adresse numérique 17 dudit coffre-fort de gestion, afin de permettre au créateur 1 d’y accéder au moyen de ladite adresse numérique.

Cette notification 18 est par ailleurs adaptée pour afficher sur le terminal 5 un message incitant le créateur 1 à activer son coffre-fort de gestion 16, afin de pouvoir l’utiliser pour créer et gérer des jetons non-fongibles 2.

Comme représenté sur la , le créateur 1 lance sur son terminal 5 ou l’application une procédure 19 pour activer son coffre-fort de gestion 16, en interagissant avec l’adresse numérique 17 affichée sur son terminal 5 pour accéder audit coffre-fort et y modifier le code d’activation décrit précédemment.

En particulier, la plateforme 4 est agencée pour attribuer au coffre-fort 16 un code d’activation « standard » « 0 » à l’issue de sa création, correspondant à un état d’attente d’activation par le créateur 1. Le créateur 1 peut notamment modifier ce code en choisissant l’une des valeurs suivantes :

une valeur « activé » « 1 » permettant d’utiliser le coffre-fort 16 pour gérer ses jetons non-fongibles 2 ;
une valeur « maximum » « 2 » bloquant le référencement dans le coffre-fort 16 de jetons non-fongibles 2 supplémentaires ;
une valeur « verrouillage » « 3 » empêchant toute modification de donnée dans le coffre-fort 16.

Pour l’activation initiale du coffre-fort 16, le créateur 1 envoie à la plateforme 4 une requête 20 contenant l’adresse numérique 17 dudit coffre-fort, afin d’enregistrer ladite adresse numérique dans le coffre-fort central 14 de la chaîne de blocs.

La plateforme 4 utilise l’adresse numérique 17 pour accéder au coffre-fort 16, afin de vérifier la valeur indiquée pour le code d’activation dans ledit coffre-fort. Si cette valeur correspond au statut « activé » « 1 », la plateforme 4 envoie au coffre-fort central 14 une notification 21 contenant cette adresse 17, afin de l’y enregistrer en l’associant à l’adresse numérique 15 de son propre coffre-fort 12. La plateforme 4 envoie ensuite au terminal 5 une notification 22 pour informer le créateur 1 du référencement de son coffre-fort de gestion 16 dans le coffre-fort central 14, et ainsi de son activation.

En particulier, la plateforme 4 peut entrer dans la liste des variables un code identifiant le type de fichier sous lequel le coffre-fort de gestion 16 est référencé dans le coffre-fort central 14, à l’issue de l’activation dudit coffre-fort de gestion par le créateur 1.

La plateforme 4 peut notamment comprendre au moins une interface de programmation API adaptée pour effectuer les opérations mentionnées ci-dessus, et de façon préférentielle des interfaces API spécifiques et distinctes pour réaliser respectivement le déploiement du coffre-fort de gestion 16 sur la chaîne de blocs, notamment avec un code d’activation « standard » « 0 », puis son activation par référencement de son adresse 17 dans le coffre-fort central 14, notamment en vérifiant la présence d’un code d’activation « activé » « 1 » dans ledit coffre-fort de gestion.

Le coffre-fort de gestion 16 comprend en outre une autre liste de paramètres spécifiques qui peut être modifiée par le créateur 1 et/ou par la plateforme 4, parmi lesquels :

des informations de référence du créateur 1, par exemple relatives à son identité, qui permettent de certifier la valeur des jetons non-fongibles 2 créés par ledit créateur ;
un code ou un lien interactif d’affichage d’un logo lié au coffre-fort de gestion 16, notamment sur le terminal 5, 6 du créateur 1 ou d’un autre utilisateur 3 ;
une étiquette de lecture humaine, permettant l’affichage sur un terminal 5, 6 des informations enregistrées dans le coffre-fort de gestion 16 sous un format lisible par une personne humaine, notamment le créateur 1 ou un autre utilisateur 3.

Sur les figures 1 à 6, l’architecture comprend en outre un serveur répertoire 23 qui comprend au moins une base de données 24 pour enregistrer des fichiers numériques 2’ liés à des jetons non-fongibles 2 d’au moins un créateur 1 présent sur la chaîne de blocs.

En particulier, le procédé prévoit, lors de la création du coffre-fort de gestion 16 pour le créateur 1, d’enregistrer dans ledit coffre-fort de gestion une adresse numérique 25 sur la chaîne de blocs du serveur répertoire 23, afin de permettre audit créateur de gérer ses jetons non-fongibles 2 au moyen dudit serveur répertoire et de son coffre-fort de gestion 16.

Pour ce faire, la plateforme de déploiement 4 comprend des moyens pour enregistrer cette adresse 25 dans la liste de variables décrite précédemment du coffre-fort 16. Cette adresse 25 peut se présenter sous la forme d’un lien interactif alphanumérique de type URL (pour l’anglais « Uniform Resource Locator »), et ne peut pas être modifiée, car elle permet de certifier l’identité du créateur 1 initial d’un jeton non-fongible 2 référencé dans le serveur 23, et ce même après la session dudit jeton non fongible à un autre utilisateur 3 de la chaîne de blocs.

Par ailleurs, la plateforme 4 peut enregistrer en parallèle, dans la liste de paramètres du coffre-fort de gestion 16 décrite précédemment, une adresse numérique alternative d’accès au serveur répertoire 23 sur la chaine de blocs, notamment en cas de défaillance de l’adresse principale 25 dudit serveur répertoire.

Comme représenté sur l’organigramme de la , l’adresse numérique 25 du serveur répertoire 23 est enregistrée dans chaque coffre-fort numérique 16, 16’, 16a, 16a’ de gestion de jetons non-fongibles 2 déployé sur la chaîne de blocs, chacun desdites coffres-forts numériques stockant en outre l’adresse numérique 10, 10a du coffre-fort personnel 9, 9a du créateur de jetons non-fongibles 1 qui en est le propriétaire.

Lors de la création d’un jeton non-fongible 2 par le créateur 1, le procédé prévoit, grâce à des moyens adaptés prévus dans le terminal 5 ou l’application préalablement installée dessus, l’enregistrement d’une information liée audit jeton numérique dans le coffre-fort numérique 16 de gestion dudit créateur, en l’associant à :

une adresse numérique détenue par ledit créateur sur la chaîne de blocs, notamment l’adresse 10 de son coffre-fort numérique personnel 9, en tant que propriétaire du jeton non-fongible 2 ;
une valeur rationnelle, par exemple un pourcentage, d’un montant d’achat à verser en rétribution au créateur 1 lors d’une vente dudit jeton non-fongible.

Pour ce faire, en relation avec la , le terminal 5 du créateur 1 comprend des moyens pour effectuer cet enregistrement, en lançant une procédure 26 adaptée au moyen de l’application installée sur ledit terminal.

En particulier, le terminal 5 ou l’application comprend des moyens pour :

calculer un arbre de hachage, par exemple un arbre de Merkle (pour l’anglais « Merkle tree ») à partir du jeton non-fongible 2 lui-même ou d’un fichier numérique 2’ lié audit jeton non-fongible, par exemple une photographie ou une image électronique dudit jeton non-fongible s’il s’agit d’un bien matériel ;
enregistrer cet arbre de hachage dans le coffre-fort de gestion 16, en tant qu’information liée audit jeton non-fongible, en l’associant à l’adresse 10 et à la valeur rationnelle de rétribution à verser au créateur 1 en cas de vente dudit jeton non-fongible.

Sur la , le terminal 5 effectue cet enregistrement en réalisant une étape 27 d’écriture pour inscrire l’arbre de hachage et les informations à lui associer dans le coffre-fort de gestion 16. Cette inscription est irréversible, l’arbre de hachage ne pouvant plus être changé par la suite.

En parallèle, le procédé prévoit :

l’envoi par le créateur 1 au serveur répertoire 23 d’une notification 28 comprenant le fichier numérique 2’ lié au jeton non-fongible 2 et les adresses numériques respectives 10, 17 dudit créateur et du coffre-fort de gestion 16 dudit créateur sur la chaîne de blocs ;
la comparaison par le serveur répertoire 23 dudit fichier numérique avec l’arbre de hachage enregistré dans le coffre-fort de gestion 16 ;
en cas de succès de cette comparaison, l’enregistrement dudit fichier numérique dans une base de données 24 dudit serveur répertoire, en l’associant aux adresses numériques 10, 17.

En relation avec la , le terminal 5 comprend des moyens pour envoyer au serveur répertoire 23 :

une requête 29 pour se connecter audit serveur répertoire, qui contient l’adresse numérique 10 de son coffre-fort personnel 9 ;
après s’être connecté audit serveur répertoire, la notification 28 mentionnée ci-dessus, afin de requérir l’enregistrement du fichier informatique 2’ lié à son jeton-non fongible 2 dans ledit serveur répertoire.

Le serveur répertoire 23 lance ensuite successivement :

une procédure 30 pour contrôler le référencement des coffres-forts 9, 16 du créateur 1 dans le coffre-fort central 14, en vérifiant la présence de leurs adresses numériques 10, 17 respectives dans ledit coffre-fort central ;
une procédure 31 pour comparer le fichier informatique 2’ communiqué dans la notification 28 avec l’arbre de hachage inscrit dans le coffre-fort de gestion 16 ;
une procédure 32 pour enregistrer le fichier 2’ dans sa base de données 24 en cas de succès de cette comparaison ;
l’envoi au terminal 5 d’une notification 33 pour indiquer l’état d’enregistrement de son fichier 2’ dans ledit serveur répertoire.

La représente plus en détail la connexion du créateur 1 au serveur répertoire 23 préalablement au référencement d’un nouveau jeton-non fongible 2, 2’ créé par ledit créateur dans ledit serveur répertoire et dans le coffre-fort de gestion 16 associé audit créateur. En particulier, le serveur répertoire 23 comprend une interface de programmation 34 spécialement adaptée pour gérer la connexion du créateur 1 et l’authentification de son coffre-fort de gestion 16 nécessaires au référencement des nouveaux jetons non-fongibles 2.

En premier lieu, le créateur 1 envoie via son terminal 5 la requête en connexion 29 représentée sur la , et contenant l’adresse numérique 10 de son coffre-fort personnel 9. L’interface de programmation 34 reçoit la requête 29 puis :

vérifie le référencement du coffre-fort personnel 9 du créateur 1 sur la chaîne de blocs, en vérifiant notamment la présence de son adresse numérique 10 dans le coffre-fort central 14 et dans une base de données 24 dudit serveur répertoire ;
envoie en retour au terminal 5 une notification 35 contenant un premier numéro généré aléatoirement par ladite interface de programmation.

Le terminal 5 ou l’application lance ensuite une procédure 36 adaptée pour :

générer un second numéro aléatoire ;
signer les premier et second numéros aléatoires au moyen de la clé privée 7a liée audit terminal ;
envoyer à l’interface de programmation 34 une notification 37 contenant l’adresse numérique 10, les numéros aléatoires signés et l’adresse numérique 17 du coffre-fort de gestion 16 associé audit créateur.

A la réception de cette notification 37, l’interface de programmation 34 :

vérifie la signature des numéros aléatoires pour identifier la clé publique 7b liée à la clé privée 7a ayant servi à ces signatures, et vérifie ensuite la concordance entre cette clé publique 7b et l’adresse numérique 10 envoyée dans la notification 37 ;
vérifie notamment la présence dans le coffre-fort de gestion 16 la présence de l’adresse numérique 10 liée au créateur 1, afin de vérifier son enregistrement en tant qu’adresse parente, attestant l’appartenance de ce coffre-fort de gestion 16 au créateur 1 ;
accorde audit créateur 1 l’accès à la base de données 24 en cas de succès de cette vérification, et notamment l’accès à une section 24’ de ladite base contenant spécifiquement l’ensemble des fichiers 2’ préalablement enregistrés par ledit créateur, afin de permettre audit créateur d’y enregistrer de nouveaux fichiers 2’.

Lors de la création d’un jeton non-fongible 2, le procédé prévoit plus particulièrement, grâce à des moyens techniques adaptés intégrés au terminal 5 ou à l’application qui y est installée, de :

enregistrer au moins un arbre de hachage lié audit jeton non-fongible dans une entrée 38 d’une liste principale 39 d’indexation au sein du coffre-fort de gestion 16, en l’associant à un identifiant unique 40 pour ledit jeton non-fongible et à une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur 1 lors d’une vente dudit jeton non-fongible ;
générer pour ledit jeton non-fongible, après enregistrement de son arbre de hachage dans la liste principale 39 :
- une première sous-liste secondaire 40a de vente dudit jeton non-fongible, et d’enregistrer dans une première entrée 41 de ladite sous-liste de vente l’adresse numérique 10 dudit créateur sur la chaîne de blocs, ainsi qu’une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible ;
- une deuxième sous-liste secondaire 40b de détention dudit jeton non-fongible, et d’enregistrer dans une première entrée 42 de ladite sous-liste de détention l’adresse numérique 10 dudit créateur sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible 2.

En particulier, les identifiants uniques 40 sont listés successivement dans la première cellule 43 de respectivement une entrée 38 de la liste principale 39, ladite liste étant incrémentée au fur et à mesure du remplissage des entrées 38, qui se fait à chaque fois qu’un jeton non-fongible 2 est référencé dans le coffre-fort de gestion 16. Le nombre d’entrées 38 disponibles dans la liste principale 39 correspond au nombre maximal de jeton non-fongibles 3 pouvant être gérés grâce au coffre-fort 16, et est fixé par le créateur 1 dans la liste de variables présentée précédemment.

Chaque entrée 38 de la liste principale 39 comprend plusieurs cellules 43a, 43b alignées horizontalement, en plus de la première cellule 43 de gauche de ladite entrée, indiquant l’identifiant unique 40 attribué au jeton non-fongible 2 lors de sa création, ces autres cellules 43a, 43b pouvant comprendre respectivement une information parmi les informations suivantes :

l’arbre de hachage du jeton non-fongible 2, généré sur le terminal 5 comme indiqué précédemment ;
le nom du jeton non-fongible 2 ;
la description du jeton non-fongible 2 ;
le cas échéant, l’adresse d’un lieu sécurisé où est conservé le jeton non-fongible 2, s’il s’agit d’un bien physique ;
la valeur rationnelle de rétribution (pour l’anglais « retribution rate »), qui correspond par exemple à un pourcentage du montant d’achat du jeton non-fongible 2 devant revenir à son créateur 1 en cas de vente ou de cession dudit jeton à tout nouvel acheteur.

En relation avec la , la première entrée 41 de la sous-liste 40a de vente d’un jeton non-fongible 2 donné comprend plusieurs cellules 41a-41i alignées horizontalement, dont la première cellule de gauche 41a qui comprend un indicatif « 1 » marquant la création dudit jeton non-fongible, chacune des autres cellules 41b-41i pouvant comprendre respectivement une information parmi les informations suivantes :

l’adresse numérique 10 du créateur 1, en tant que propriétaire du jeton non-fongible 2 ;
le marqueur temporel de création de la transaction ;
le code d’affichage de cette transaction dans le serveur répertoire 23, choisi parmi :
- le code « 0 », indiquant que cette transaction ne doit pas être affichée sur le serveur 23 (et donc ne doit pas être lisible par tout utilisateur 3 consultant ledit serveur) ;
- le code « 1 », indiquant que ladite transaction peut être affichée sur le serveur 23 pour pouvoir être lisible par tout utilisateur 3, 1 ;
le code de vente de cette transaction, choisi parmi :
- un code prédéfini tel que :
  - le code « 0 », indiquant que le jeton non-fongible 2 n’est pas à vendre ; ou
  - le code « 1 », indiquant que n’importe quel utilisateur 3 fournissant le montant en cryptomonnaie requis peut acheter le jeton non-fongible 2 ; ou
  - le code « 2 », indiquant que le jeton non-fongible 2 est vendu aux enchères ; ou
- un code personnalisé, consistant par exemple en l’adresse numérique 11 d’un utilisateur 3 auquel la vente de ce jeton non-fongible 2 est exclusivement réservée ;
une donnée alphanumérique correspondant au montant en cryptomonnaie requis pour l’achat du jeton non-fongible 2 ;
un jeton de paiement, sur lequel le montant en cryptomonnaie requis doit être transféré pour acheter le jeton non-fongible 2 au créateur 1 ;
un marqueur temporel de délai d’achat, au-delà de laquelle la transaction doit être finalisée ;
une donnée alphanumérique indiquant la fonction de la transaction, par exemple une vente simple, une mise à jour d’une transaction précédente, une vente aux enchères….

De même, comme représenté la , la première entrée 42 de la sous-liste 40b de détention de ce même jeton non-fongible 2 comprend également plusieurs cellules 42a-42e alignées horizontalement, dont la première cellule de gauche 42a qui comprend un indicatif « 1 » marquant la création dudit jeton non-fongible, chacune des autres cellules 42b-42e pouvant comprendre respectivement une information parmi les informations suivantes :

l’adresse numérique 10 du créateur 1 sur la chaîne de blocs, en tant que propriétaire et responsable actuel du jeton non-fongible 2 ;
une chaîne de caractères alphanumériques identifiant spécifiquement l’enregistrement de cette entrée 42 ;
une chaîne de caractères alphanumériques correspondant à un texte lisible par un utilisateur humain 1, 3, et pouvant notamment être renseigné manuellement par le créateur 1 propriétaire du jeton non-fongible 2, indiquant la localisation physique dudit jeton non-fongible (s’il s’agit d’un bien physique) ;
le marqueur temporel d’enregistrement de cette entrée 42.

Comme représenté sur les figures 5 et 6, tout utilisateur 3 présent sur la chaîne de blocs peut consulter le serveur répertoire 23 pour identifier les créateurs 1 de jetons non-fongibles 2, afin d’obtenir la liste des coffres-forts de gestion 16 d’au moins un créateur 1 donné, et ainsi consulter les données relatives à un jeton non-fongible 2 dudit créateur qu’il souhaite éventuellement acheter.

Sur la , l’utilisateur 3 se connecte à la chaîne de blocs au moyen de son terminal 6, qui peut notamment comprendre une application et/ou des moyens techniques similaires à ceux installé(e)s sur le terminal 5 du créateur 1, puis, grâce à des moyens techniques spécifiques installés sur ledit terminal ou dans ladite application, envoie une requête 45 au serveur répertoire 23, qui envoie en retour audit terminal une notification 46 contenant les adresses numériques 10, 10a, 10b de l’ensemble des créateurs 1 référencés dans ledit serveur répertoire.

L’utilisateur 3 choisit parmi ces adresses 10, 10a, 10b communiquées l’adresse numérique 10 du créateur 1 qui l’intéresse, puis envoie au serveur répertoire 23 au moyen de son terminal 6 une nouvelle requête 47 contenant cette adresse numérique 10, le serveur répertoire 23 envoyant en retour une notification comprenant l’adresse numérique 10 de ce créateur 1 et les adresses numériques 17, 17’, 17’’ de l’ensemble des coffres-forts 16, 16’ de gestion de jetons non-fongibles 2 associés audit créateur sur la chaîne de blocs.

En relation avec la , l’utilisateur 3, lorsqu’il souhaite consulter le fichier numérique 2’ d’un jeton non-fongible 2 donné, envoie au serveur répertoire 23 une requête 49 contenant l’adresse numérique 17 du coffre-fort de gestion 16 dans lequel ce jeton non-fongible 2 est répertorié, ainsi que l’identifiant unique 40 associé à ce jeton non-fongible 2, qu’il a pu obtenir en consultant la liste d’indexation 39 enregistrée dans ledit coffre-fort de gestion.

Le serveur répertoire 23 consulte ensuite le coffre-fort de gestion 16 correspondant, afin de vérifier si ce jeton non-fongible 2 peut être consulté par l’utilisateur 3, notamment en consultant le code d’affichage inscrit dans la sous-liste de vente 40a propre à ce jeton non-fongible 2 (étape 50) puis, dans l’affirmative, vérifier l’arbre de hachage lié à ce jeton non-fongible 2 qui est enregistré dans ledit coffre-fort de gestion (étape 51).

Si le jeton non-fongible 2 peut être visualisé par l’utilisateur 3, le serveur répertoire 23 communique au terminal 6 une notification 52 contenant notamment un fichier numérique 2’ lié audit jeton non-fongible, ainsi qu’un code de retour, le terminal 6 ou l’application lançant ensuite une procédure 53 adaptée pour afficher sur ledit terminal de manière lisible pour un utilisateur humain 3 le fichier numérique 2’ et les informations sur ledit jeton non-fongible enregistrées dans les ses sous-listes 40a, 40b de vente et de détention.

Le procédé prévoit ensuite, lorsque l’utilisateur 3 souhaite acheter un jeton non-fongible 2 du créateur 1 :

le transfert par l’utilisateur 3 d’un montant en cryptomonnaie requis pour cet achat, par l’intermédiaire du coffre-fort numérique de gestion 16 dans lequel est répertorié ce jeton non-fongible 2, afin de transférer audit créateur un montant rationnel de rétribution prélevé sur le montant d’achat requis en fonction de la valeur rationnelle associée au jeton non-fongible 2, le reste dudit montant d’achat requis étant transféré au propriétaire actuel 1 dudit jeton non-fongible ;
en cas de succès de cet achat, l’enregistrement dans le coffre-fort numérique de gestion 16 d’une adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.

Pour ce faire, le terminal 6 comprend des moyens adaptés pour permettre à l’utilisateur 3 d’effectuer le transfert du montant en cryptomonnaie requis, et le coffre-fort 16 est agencé pour répartir ledit montant requis entre le créateur 1 et l’actuel propriétaire du jeton non-fongible 2, en fonction de la valeur rationnelle de rétribution renseignée par le créateur 1 pour ledit jeton non-fongible.

En particulier, le terminal 6 comprend des moyens pour enregistrer, dans une nouvelle entrée 44 de la sous-liste 40a de vente du jeton non-fongible 2, une adresse numérique 8, 11 de l’utilisateur 3 sur la chaîne de blocs, en l’associant à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat, ainsi qu’à un lien interactif d’accès à des actifs dudit utilisateur sur la chaîne de blocs pour pouvoir prélever ledit montant proposé.

En relation avec la , la sous-liste de vente 40a comprend plusieurs autres entrées 44, 55 s’étendant horizontalement sous la première entrée 41 relative à la création du jeton non-fongible, et qui sont complétées successivement par le créateur 1 ou par l’utilisateur 3 à chaque transaction effectuée pour ledit jeton non-fongible. Chaque entrée 44, 55 comprend une première cellule 44a, 55a qui comprend un numéro incrémenté correspondant au rang de la transaction.

L’utilisateur 3 complète, au moyen de son terminal 6, la première entrée 44, 55 disponible en remplissant les cellules 44b, 55b, 44c, 55c, 44f, 55f, 44i, 55i appropriées avec respectivement les informations suivantes :

l’adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs ;
le marqueur temporel d’activation de ladite entrée, et donc de création de la proposition d’achat ;
une donnée alphanumérique correspondant au montant en cryptomonnaie proposé par l’utilisateur 3 pour l’achat du jeton non-fongible 2 ;
une donnée alphanumérique indiquant la fonction de la transaction, par exemple une vente simple, une mise à jour d’une transaction précédente, une vente aux enchères….

Ensuite, en cas de succès de la vente, le procédé prévoit de transférer le montant proposé, prélevé des actifs de l’utilisateur 3 accessibles depuis son adresse numérique 8, 11, dans le coffre-fort 16 de gestion des jetons non-fongibles 2 du créateur 1.

Pour ce faire, le terminal 6 comprend des moyens pour effectuer ce transfert. Ensuite, le coffre-fort numérique 16 effectue, grâce à une fonctionnalité adaptée qui lui a été attribuée lors de sa création par la plateforme 4, un transfert de ce montant en cryptomonnaie total, ou du montant rationnel de rétribution, sur le jeton de paiement du créateur 1, en interagissant avec ledit jeton de paiement renseigné en cellule 41h dans la première entrée 41 de la sous-liste de vente 40a.

En particulier, lorsque l’utilisateur 3 achète le jeton non-fongible 2 à un propriétaire autre que le créateur 1, par exemple un autre utilisateur ayant préalablement acheté ledit jeton non-fongible directement au créateur 1, le procédé prévoit de répartir le montant versé par l’utilisateur 3 sur le coffre-fort numérique 16 comme suit :

un montant rationnel, calculé à partir de la valeur rationnelle de rétribution associée au jeton non-fongible 2, sur le jeton de paiement du créateur 1 ;
le reste du montant requis, correspondant au résultat de la soustraction de ce montant rationnel au montant total versé par l’utilisateur 3, au propriétaire actuel dudit jeton non-fongible, par exemple via un jeton de paiement renseigné pour ledit propriétaire actuel dans la cellule 44h, 55h d’une entrée 44, 55 de la sous-liste de vente 40a correspondant à l’acquisition dudit jeton non-fongible par ledit propriétaire actuel.

De même, lorsque l’utilisateur 3 achète le jeton non-fongible 2 directement au créateur 1, le coffre-fort 16 est agencé pour verser le montant rationnel de rétribution et le reste du montant total au créateur 1, suivant les mêmes étapes que décrites précédemment. Selon une variante de réalisation, le coffre-fort 16 peut être agencé pour ne pas tenir compte de la valeur rationnelle de rétribution lorsqu’un utilisateur 3 achète un jeton non-fongible 2 directement au créateur 1, et ainsi verser le montant total requis pour ledit achat directement sur le jeton de paiement dudit créateur.

Par ailleurs, au moins l’un des terminaux 5, 6 respectifs du créateur 1 (ou actuel propriétaire du jeton non-fongible 2) et de l’utilisateur 3 comprend des moyens pour enregistrer dans le coffre-fort numérique de gestion 16 l’adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire du jeton non-fongible 2.

Pour ce faire, l’un des terminaux 5, 6, et notamment le terminal 6 de l’utilisateur 3 venant d’acheter le jeton non-fongible 2, comprend des moyens pour enregistrer, dans une nouvelle entrée 54 de la sous-liste 40b de détention du jeton non-fongible 2, l’adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.

En particulier, le coffre-fort numérique 16 peut être agencé pour communiquer à l’utilisateur 3, automatiquement et immédiatement après son achat du jeton non-fongible 2, une requête (non représentée) pour l’inviter à remplir une nouvelle entrée 54 dans la sous-liste 40b, notamment l’entrée vide 54 suivant la première entrée 42, dont la première cellule 54a contient un numéro incrémenté indiquant le rang de ladite nouvelle entrée.

L’utilisateur 3 peut notamment compléter les autres cellules 54b-54e avec respectivement les informations suivantes :

l’adresse numérique 8, 11 de l’utilisateur 3 sur la chaîne de blocs, en tant que nouveau propriétaire et responsable du jeton non-fongible 2 ;
une chaîne de caractères alphanumériques identifiant spécifiquement l’enregistrement de cette entrée 54 ;
une chaîne de caractères alphanumériques correspondant à un texte lisible par un utilisateur humain 1, 3, et pouvant notamment être renseigné manuellement par l’utilisateur 3 pour indiquer la nouvelle localisation physique dudit jeton non-fongible (s’il s’agit d’un bien physique) ;
le marqueur temporel d’enregistrement de cette entrée 54.

Le procédé peut prévoir, lorsqu’un utilisateur 3 ayant acheté le jeton non-fongible 2 au créateur 1 souhaite le revendre à un autre utilisateur présent sur la chaîne de blocs, d’enregistrer dans une nouvelle entrée 44, 55 de la sous-liste de vente 40a, l’adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs, en tant que propriétaire actuel du jeton non-fongible 2, et une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible audit propriétaire actuel.

Pour ce faire, le terminal 6 comprend des moyens pour permettre à l’utilisateur 3 de compléter une nouvelle entrée 44, 55 pour revendre le jeton non-fongible 2, de manière similaire à la première entrée 41 remplie par le créateur 1 lors de la première mise en vente dudit jeton non-fongible.

Ensuite, lors d’un achat ultérieur de ce jeton non-fongible 2 par un autre utilisateur, le créateur 1 percevra un montant rationnel de rétribution prélevé sur le montant total de l’achat, et calculé à partir de la valeur de rétribution qu’il a initialement renseignée dans la cellule 43b de l’entrée 38 relative à ce jeton non-fongible 2 dans la liste d’indexation 39.

De façon avantageuse, le procédé prévoit en outre, lorsqu’au moins deux utilisateurs 3 souhaitent acheter un même jeton non-fongible 2 du créateur 1 :

d’enregistrer pour chaque utilisateur 3, dans respectivement une entrée 44, 55 de la sous-liste 40a de vente dudit jeton non-fongible, l’adresse numérique 8, 11 dudit utilisateur sur la chaîne de blocs, associé à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat ;
après expiration d’un délai d’achat préalablement fixé par l’actuel propriétaire du jeton non-fongible 2, par exemple le créateur 1 lui-même dans le cas d’une première vente, et renseigné dans la cellule 41h de la première entrée 41 de ladite sous-liste, finaliser l’achat dudit jeton non-fongible avec l’utilisateur 3 dont le montant en cryptomonnaie proposé est le plus élevé.

Cette option est notamment accessible en remplissant, dans la première entrée 41 de la sous-liste de vente 40a, la cellule 41e relative au code de vente avec le code « 2 », correspondant à une mise aux enchères du jeton non-fongible 2. Ainsi, les utilisateurs 3 souhaitant acheter le jeton non-fongible 2 peuvent remplir chacun, et ce jusqu’à expiration du délai d’achat, au moins une entrée 44, 55 pour proposer un montant d’achat en cryptomonnaie, qui doit être supérieur à la fois au montant de départ fixé dans l’entrée 41 (cellule 41f), qui peut notamment être nul, et au montant proposé dans l’éventuelle entrée 44 précédemment renseignée par un autre utilisateur 3.

Pour ce faire, l’architecture comprend au moins deux terminaux 6 (non représentés) comprenant des moyens pour permettre à respectivement un utilisateur 3 présent sur la chaîne de blocs d’acheter des jetons non-fongibles 2 du créateur 1, et le terminal 5 dudit créateur (ou d’un propriétaire actuel de jetons 2 dudit créateur) comprend des moyens pour permettre audit créateur (ou propriétaire actuel) de fixer un délai d’achat pour ses jetons non-fongibles 2, par exemple en remplissant la cellule 41h, 44h, 55h dans une entrée 41, 44, 55 des sous-listes de vente 40a respectives desdits jetons non-fongibles, comme développé précédemment.

Chaque terminal 6 comprend en outre des moyens pour, lorsque leurs utilisateurs 3 respectifs souhaitent acheter un même jeton non-fongible 2, enregistrer les informations requises dans respectivement une entrée 44, 55 de la sous-liste de vente 40a correspondante, puis pour permettre à l’utilisateur 3 dont le montant en cryptomonnaie proposé est le plus élevé de finaliser cet achat après expiration du délai fixé par le créateur 1 (ou propriétaire actuel) dudit jeton non-fongible.

En particulier, les entrées 41, 44, 55 ne peuvent pas être modifiées tant que le délai d’achat n’a pas expiré, et les utilisateurs 3 participant à la vente peuvent changer leur adresse numérique 8, 11 de paiement en complétant une nouvelle entrée, avec un montant d’achat proposé conforme.

Le coffre-fort numérique de gestion 16 peut être programmé pour :

pour chaque entrée 44, 55 de proposition d’achat renseignée dans la sous-liste de vente 40a, prélever le montant proposé depuis l’adresse numérique 8, 11 renseignée par l’utilisateur 3 dans la cellule 44f, 55f correspondante ;
si une nouvelle entrée 44, 55 est remplie avec une proposition de montant d’achat supérieure à celle renseignée dans l’entrée 44 précédente, annuler la vente correspondant à l’entrée précédente 44 en reversant le montant prélevé à l’adresse numérique 8, 11 de paiement renseignée dans ladite entrée précédente ;

et répéter ces opérations tant que le délai d’achat renseigné dans l’entrée 41, 44, 55 n’a pas expiré.

Ensuite, après expiration du délai d’achat, le créateur 1 (ou le propriétaire actuel) du jeton 2 acheté, ou l’utilisateur 3 ayant remporté l’enchère, peut requérir le versement du paiement audit créateur (ou audit propriétaire actuel), afin que le coffre-fort de gestion 16 reverse le montant prélevé lors de la dernière enchère sur le jeton de paiement dudit créateur (ou dudit propriétaire actuel).

En particulier, lorsqu’un utilisateur 3 autre que le créateur 1 revend un jeton non-fongible 2 aux enchères, le procédé peut prévoir en plus de verser le montant rationnel de rétribution sur le jeton de paiement du créateur 1, et verser le reste du montant total payé par l’acheteur dudit jeton à l’adresse numérique 8, 11 du revendeur.

Claims

Procédé pour permettre à un créateur (1) de vendre des jetons non-fongibles (2) à des utilisateurs (3) sur une chaîne de blocs, ledit procédé prévoyant :
la création d’un coffre-fort numérique (16) de gestion de jetons non-fongibles (2) pour le créateur (1) sur la chaine de blocs ;

lors de la création d’un jeton non-fongible (2) par le créateur (1), l’enregistrement d’une information liée au jeton non-fongible (2) dans le coffre-fort numérique (16) de gestion de jetons non-fongibles (2), en l’associant à :

une adresse numérique (10) détenue par le créateur (1) sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible (2) ;

une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur (1) lors d’une vente dudit jeton non-fongible ;
ledit procédé prévoyant en outre, lorsqu’un utilisateur (3) souhaite acheter un jeton non-fongible (2) du créateur (1) :
le transfert par ledit utilisateur d’un montant en cryptomonnaie requis pour ledit achat par l’intermédiaire du coffre-fort numérique (16) de gestion de jetons non-fongibles (2), afin de transférer audit créateur un montant rationnel de rétribution prélevé sur le montant d’achat requis en fonction de la valeur rationnelle associée au jeton non-fongible (2), le reste dudit montant d’achat requis étant transféré au propriétaire actuel (1) dudit jeton non-fongible ;

en cas de succès de ladite vente, l’enregistrement dans le coffre-fort numérique (16) de gestion d’une adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.
Procédé selon la revendication 1, caractérisé en ce qu’il prévoit d’enregistrer une adresse numérique (10) détenue par le créateur (1) sur la chaîne de blocs en tant qu’adresse parente dans le coffre-fort numérique (16) de gestion des jetons non-fongibles (2) dudit créateur lors de la création dudit coffre-fort numérique de gestion.
Procédé selon l’une des revendications 1 ou 2, caractérisé en ce qu’il prévoit d’enregistrer l’information liée au jeton non-fongible (2) dans le coffre-fort numérique (16) de gestion du créateur (1) en l’associant à l’adresse numérique (10) d’un coffre-fort numérique personnel (9) détenu par ledit créateur sur la chaîne de blocs, au moins une clé publique (7b) d’accès dudit créateur à ladite chaîne de blocs étant enregistrée dans ledit coffre-fort numérique personnel.
Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’il prévoit, lors de la création du coffre-fort numérique (16) de gestion pour le créateur (1), d’enregistrer dans ledit coffre-fort numérique une adresse numérique (25) sur la chaîne de blocs d’un serveur répertoire (23) comprenant au moins une base de données (24) dans laquelle sont enregistrées des fichiers numériques liés à des jetons non-fongibles d’au moins un créateur présent sur la chaîne de blocs, ledit procédé prévoyant en outre, lors de la création d’un jeton non-fongible (2) par le créateur (1) :
l’enregistrement dans le coffre-fort numérique de gestion (16) dudit créateur d’un arbre de hachage lié audit jeton non-fongible ;

l’envoi par le créateur (1) au serveur répertoire (23) d’une notification (27) comprenant le fichier numérique (2’) lié audit jeton non-fongible (2) et les adresses numériques respectives (10, 17) dudit créateur et dudit coffre-fort numérique de gestion sur la chaîne de blocs ;

la comparaison par ledit serveur dudit fichier numérique avec l’arbre de hachage enregistré dans le coffre-fort numérique de gestion (16) ;

en cas de succès de ladite comparaison, l’enregistrement dudit fichier numérique dans une base de données (24) dudit serveur répertoire, en l’associant aux adresses numériques (10, 17) respectives du créateur (1) et de son coffre-fort numérique de gestion (16).
Procédé selon l’une quelconque des revendications 1 à 4, caractérisé en ce qu’il prévoit, lors de la création d’un jeton non-fongible (2) par le créateur (1) :
d’enregistrer au moins un arbre de hachage lié audit jeton non-fongible dans une entrée (38) d’une liste principale (39) d’indexation au sein du coffre-fort numérique de gestion (16), en l’associant à un identifiant unique (40) pour ledit jeton non-fongible et à une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur (1) lors d’une vente dudit jeton non-fongible ;

de générer pour ledit jeton non-fongible, après enregistrement de son arbre de hachage dans ladite liste principale :

une première sous-liste secondaire (40a) de vente dudit jeton non-fongible, et d’enregistrer dans une première entrée (41) de ladite sous-liste de vente l’adresse numérique (10) dudit créateur sur la chaîne de blocs et une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible ;

une deuxième sous-liste secondaire (40b) de détention dudit jeton non-fongible, et d’enregistrer dans une première entrée (42) de ladite sous-liste de détention l’adresse numérique (10) dudit créateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible.
Procédé selon la revendication 5, caractérisé en ce qu’il prévoit, lorsqu’un utilisateur (3) souhaite acheter un jeton non-fongible (2) du créateur (1), de :
enregistrer, dans une nouvelle entrée (44, 55) de la sous-liste de vente (40a), une adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en l’associant à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat ; puis

en cas de succès de l’achat :

transférer le montant en cryptomonnaie proposé, prélevé des actifs de l’utilisateur (3) accessibles depuis son adresse numérique
(8, 11), dans le coffre-fort (16) de gestion des jetons non-fongibles (2) du créateur (1) ;

enregistrer, dans une nouvelle entrée (54) de la sous-liste de détention (40b) l’adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.
Procédé selon la revendication 6, caractérisé en ce qu’il prévoit, lorsqu’au moins deux utilisateurs (3) souhaitent acheter un même jeton non-fongible (2) du créateur (1) :
d’enregistrer pour chaque utilisateur (3), dans respectivement une entrée (44, 55) de la sous-liste (40a) de vente dudit jeton non-fongible, l’adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, associée à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat ;

après expiration d’un délai préalablement fixé par l’actuel propriétaire (1) dudit jeton non-fongible, finaliser l’achat dudit jeton non-fongible avec l’utilisateur (3) dont le montant en cryptomonnaie proposé est le plus élevé.
Procédé selon l’une quelconque des revendications 5 à 7, caractérisé en ce qu’il prévoit, lorsqu’un utilisateur (3) ayant acheté un jeton non-fongible (2) au créateur (1) souhaite revendre ledit jeton non-fongible, d’enregistrer, dans une nouvelle entrée (44, 55) de la première sous-liste secondaire (40a) de vente dudit jeton non-fongible, l’adresse numérique (8, 11) dudit utilisateur sur la chaine de blocs, en tant que propriétaire actuel dudit jeton non-fongible, et une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible audit propriétaire actuel.
Architecture pour permettre à un créateur (1) de vendre des jetons non-fongibles (2) à des utilisateurs (3) sur une chaîne de blocs, ladite architecture comprenant :
une plateforme (4) de déploiement de coffres-forts numériques (9, 16) sur la chaîne de blocs ;

un terminal (5) comprenant, notamment au moyen d’une application installée sur ledit terminal, des moyens pour permettre au créateur (1) de :

solliciter la plateforme de déploiement (4) pour créer un coffre-fort numérique (16) de gestion de jetons non-fongibles (2) pour ledit créateur sur la chaine de blocs ;

lors de la création d’un jeton non-fongible (2) par ledit créateur, enregistrer une information liée audit jeton non-fongible dans le coffre-fort numérique (16) de gestion de jetons non-fongibles (2), en l’associant à :

une adresse numérique (10) détenue par le créateur (1) sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible (2) ;

une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur (1) lors d’une vente dudit jeton non-fongible ;

un terminal (6) comprenant des moyens pour permettre à un utilisateur (3) souhaitant acheter un jeton non-fongible (2) du créateur (1) de transférer un montant en cryptomonnaie requis pour ledit achat par l’intermédiaire du coffre-fort numérique (16) de gestion de jetons non-fongibles (2) ;
le coffre-fort numérique (16) étant agencé pour transférer audit créateur un montant rationnel de rétribution prélevé sur le montant d’achat requis en fonction de la valeur rationnelle associée au jeton non-fongible (2), et transférer le reste dudit montant d’achat requis au propriétaire actuel (1) dudit jeton non-fongible ;
au moins l’un des terminaux (5, 6) comprenant des moyens pour, en cas de succès de l’achat, enregistrer dans le coffre-fort numérique de gestion (16) une adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.
Architecture selon la revendication 9, caractérisée en ce que la plateforme de déploiement (4) comprend des moyens pour enregistrer une adresse numérique (10) détenue par le créateur (1) sur la chaîne de blocs en tant qu’adresse parente dans le coffre-fort numérique (16) de gestion des jetons non-fongibles (2) dudit créateur lors de la création dudit coffre-fort numérique de gestion.
Architecture selon l’une des revendications 9 ou 10, caractérisée en ce que le terminal (5) du créateur (1) comprend des moyens pour enregistrer l’information liée au jeton non-fongible (2) dans le coffre-fort numérique (16) de gestion dudit créateur en l’associant à l’adresse numérique (10) d’un coffre-fort numérique personnel (9) détenu par ledit créateur sur la chaîne de blocs, au moins une clé publique (7b) d’accès dudit créateur à ladite chaîne de blocs étant enregistrée dans ledit coffre-fort numérique personnel.
Architecture selon l’une quelconque des revendications 9 à 11, caractérisée en ce qu’elle comprend un serveur répertoire (23) qui comprend au moins une base de données (24) pour enregistrer des fichiers numériques liés à des jetons non-fongibles d’au moins un créateur présent sur la chaîne de blocs, la plateforme de déploiement (4) comprenant des moyens pour, lors de la création du coffre-fort numérique (16) de gestion pour le créateur (1), enregistrer dans ledit coffre-fort de gestion une adresse numérique (25) dudit serveur sur la chaîne de blocs, le terminal (5) du créateur (1) comprend des moyens pour, lors de la création d’un jeton non-fongible (2) par le créateur (1) :
enregistrer dans le coffre-fort numérique de gestion (16) un arbre de hachage lié audit jeton non-fongible ;

envoyer au serveur répertoire (23) une notification (27) comprenant le fichier numérique (2’) lié audit jeton non-fongible et les adresses numériques (10, 17) respectives dudit créateur et dudit coffre-fort numérique de gestion sur la chaîne de blocs ;
le serveur répertoire (23) comprenant en outre des moyens pour :
comparer ledit fichier numérique avec l’arbre de hachage enregistré dans le coffre-fort numérique de gestion (16) ;

en cas de succès de ladite comparaison, enregistrer ledit fichier numérique dans une base de données (24) dudit serveur répertoire, en l’associant aux adresses numériques (10, 17) respectives du créateur (1) et de son coffre-fort numérique de gestion (16).
Architecture selon l’une quelconque des revendications 9 à 12, caractérisée en ce que le terminal (5) du créateur (1) comprend des moyens pour, lors de la création d’un jeton non-fongible (2) par le créateur (1) :
enregistrer au moins un arbre de hachage lié audit jeton non-fongible dans une entrée (38) d’une liste principale (39) d’indexation au sein du coffre-fort numérique de gestion (16), en l’associant à un identifiant unique (40) pour ledit jeton non-fongible et à une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur (1) lors d’une vente dudit jeton non-fongible ;

générer pour ledit jeton non-fongible, après enregistrement de son arbre de hachage dans ladite liste principale :

une première sous-liste secondaire (40a) de vente dudit jeton non-fongible, et enregistrer dans une première entrée (41) de ladite sous-liste de vente l’adresse numérique (10) dudit créateur sur la chaîne de blocs et une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible ;

une deuxième sous-liste secondaire (40b) de détention dudit jeton non-fongible, et enregistrer dans une première entrée (42) de ladite sous-liste de détention l’adresse numérique (10) dudit créateur sur la chaîne de blocs, en tant que propriétaire dudit jeton-non fongible.
Architecture selon la revendication 13, caractérisée en ce que le terminal (6) de l’utilisateur (3) souhaitant acheter un jeton non-fongible (2) du créateur (1) comprend des moyens pour :
enregistrer, dans une nouvelle entrée (44, 55) de la sous-liste de vente (40a), une adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en l’associant à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat ;

en cas de succès de l’achat :

transférer le montant en cryptomonnaie proposé, prélevé des actifs de l’utilisateur (3) accessibles depuis son adresse numérique
(8, 11), dans le coffre-fort (16) de gestion des jetons non-fongibles (2) du créateur (1) ;

enregistrer, dans une nouvelle entrée (54) de la sous-liste de détention (40b), l’adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, en tant que nouveau propriétaire dudit jeton non-fongible.
Architecture selon la revendication 14, caractérisée en ce qu’elle comprend au moins deux terminaux (6) comprenant des moyens pour permettre à respectivement un utilisateur (3) présent sur la chaîne de blocs d’acheter des jetons non-fongibles (2) du créateur (1), le terminal (5) du propriétaire actuel (1) desdits jetons non-fongibles comprenant des moyens pour permettre audit propriétaire actuel de fixer un délai d’achat pour lesdits jetons non-fongibles, chaque terminal utilisateur (6) comprenant des moyens pour, lorsque les utilisateurs (3) souhaitent acheter un même jeton non-fongible (2) du créateur (1) :
enregistrer pour l’utilisateur (3) correspondant, dans respectivement une entrée (44, 55) de la sous-liste (40a) de vente dudit jeton non-fongible (2), l’adresse numérique (8, 11) dudit utilisateur sur la chaîne de blocs, associée à une information sur un montant en cryptomonnaie proposé par ledit utilisateur pour ledit achat ;

après expiration d’un délai d’achat fixé par le propriétaire actuel (1) pour ledit jeton non-fongible, permettre à l’utilisateur (3) dont le montant en cryptomonnaie proposé est le plus élevé de finaliser l’achat avec ledit propriétaire actuel.
Architecture selon l’une quelconque des revendications 13 à 15, caractérisée en ce que le terminal (6) de l’utilisateur (3) ayant acheté un jeton non-fongible (2) au créateur (1) comprend des moyens pour permettre audit utilisateur, lorsqu’il souhaite revendre ledit jeton non-fongible, d’enregistrer, dans une nouvelle entrée (44, 55) de la première sous-liste secondaire (40a) de vente dudit jeton non-fongible, l’adresse numérique (8, 11) dudit utilisateur sur la chaine de blocs, en tant que propriétaire actuel dudit jeton non-fongible, et une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible audit propriétaire actuel.