FR3128344A1 - Méthode pour la mise à disposition immédiate d’un jeton non fongible à partir d’un fichier numérique d’un terminal mobile connecté à un service de chaine de blocs - Google Patents

Abstract

La présente invention concerne un procédé de mise à disposition de jeton non fongible (JNF) par un service de chaine de blocs (BC) à partir d’un fichier numérique transmis par un terminal mobile (MD) connecté. La spécificité de ce procédé est de générer un ou plusieurs jetons non fongibles (JNF) à partir de fichiers numériques n’existant que temporairement dans la mémoire vive du terminal mobile (MD), et dont les contenus numériques sont eux-mêmes temporaires et non reproductibles, en l’occurrence des évènements capturés en direct par un utilisateur (Usr) au moyen du terminal mobile (MD) ; rendant par conséquent le ou les jetons non fongibles générés sont d’autant plus rares. Figure de l’abrégé : Figure 2

Description

Procédé pour la mise à disposition immédiate d’un jeton non fongible à partir d’un fichier numérique d’un terminal mobile connecté à un service de chaine de blocs

L’invention se rapporte, dans le domaine Informatique, à un procédé pour mettre à disposition d’un utilisateur un jeton non fongible qui est généré par un service de chaine de blocs, cela à partir d’un fichier numérique qui est stocké dans un terminal mobile connecté (comme un téléphone mobile, une tablette, un ordinateur portable) de l’utilisateur et qui est envoyé par ce dernier au service de chaine de blocs.

L’invention trouve une application non limitative dans le monde de l’art dont les usages et les pratiques se transforment au gré des évolutions technologiques, les artistes exposant et vendant des œuvres, uniques ou à tirage limité, non plus uniquement physiques mais désormais aussi purement numériques.

Dans le domaine de la Monétique, les évolutions technologiques pour effectuer des transactions de paiement électronique (par exemple, via Internet ou au moyen d’un téléphone mobile) ont conduit à l’émergence puis à l’essor de technologies, dont une des plus connues est la chaine de blocs (ou « Blockchain » en anglais). Une chaine de blocs est un registre distribué, c'est à dire un registre simultanément enregistré et synchronisé sur un réseau d'ordinateurs. Ce registre est une structure linéaire constituée de blocs qui sont des ensembles horodatés et validés de transaction. Ainsi, dans le temps, les blocs en bout de chaines correspondent aux blocs de transactions les plus récents ayant été ajoutés à la chaine.

La chaine de bloc fonctionnant sans organe central de contrôle, les informations arrivant sur une chaîne de blocs sont visibles et récupérées par l’ensemble des systèmes (ou nœuds) connectés à ce réseau. Les transactions nouvellement arrivées vont subir une opération de minage par un nœud du réseau (appelé alors mineur). Le minage va consister à regrouper les transactions dans un bloc en ajoutant un en-tête qui contient notamment la taille du bloc, le nombre de transactions contenues dans le bloc, la date, l'heure, une somme de contrôle qui empêche toute modification du bloc et sert également d'identificateur unique au bloc, et l’identificateur du bloc précédent. Une fois le bloc crée, il doit être validé par l’ensemble des autres nœuds du réseau selon des règles dites de consensus (c’est-à-dire des critères que doit remplir le bloc formé regard de la chaîne de blocs). Une fois le bloc validé, il est chiffré et ajouté à la chaine de blocs. L’intérêt de la technologie de la chaine de blocs est qu’une fois la transaction stockée dans un bloc ajouté à la chaine, il n’est plus possible ni de modifier ou de supprimer cette transaction.

Par ailleurs, chaque système présent sur la chaine de blocs conserve un historique de cette dernière. C’est pourquoi la technologie de chaine de blocs présente de nombreux intérêts dans des applications pour lesquelles la sécurité, mais aussi l’irréfutabilité et la pérennité de la traçabilité, des informations sont primordiales.

Parmi les chaines de blocs de blocs les plus connues utilisées dans le domaine du paiement électronique : les chaines de blocs Bitcoin^TMet Ethereum^TM. Les actifs numériques émis et échangés au travers des transactions dans ces chaines de blocs correspondent à de la crypto-monnaie, c’est-à-dire de la monnaie numérique représentative d’une monnaie fiat. Ces actifs numériques, préalablement chiffrés par un mécanisme de chiffrement avant émission dans la chaine de blocs, sont aussi appelés jetons (ou token). Un jeton spécifique est défini pour chacune des technologies de chaine de blocs citées : sont échangés respectivement des jetons BTC^TMet Ether^TMdans les chaines de blocs Bitcoin et Ethereum. Une caractéristique de ces jetons est qu’ils sont fongibles, c’est-à-dire que sur le principe, en termes de valeur, rien ne distingue un BTC (respectivement un Ether) d’un autre BTC (respectivement un Ether). Une analogie peut être faite avec chacune des monnaies fiat : rien ne distingue par exemple en termes de valeur un euro (ou un dollar) d’un autre euro (ou d’un autre dollar).

La technologie de chaine de blocs a rapidement évolué, avec désormais la possibilité de transmettre et échanger dans les chaines de blocs différents types de fichiers numériques (un fichier, une image ou une vidéo). La technologie a également trouvé un intérêt dans des domaines s’étendant au-delà de la Monétique. De plus en plus d’entreprises intègrent la technologie de chaine de blocs dans leur Système d’Information, notamment pour la gestion électronique de leur documentation, cela à des fins de stockage mais aussi pour garantir la datation et l’authenticité des documents, ainsi que la confidentialité de ceux pouvant être sensibles car stratégiques pour l’entreprise. Là encore, les fichiers numériques sont des actifs fongibles car il peut exister plusieurs copies d’un même fichier texte, d’une image, d’une vidéo.

Les avantages de la chaine de blocs (sécurité, traçabilité et authenticité) et une consommation de plus en plus élevée de biens numériques ont fait récemment apparaître un nouvel usage de la technologie de chaine de blocs dans les mondes de l’Art, du Luxe, ou bien encore du Jeu Vidéo : celui de la vente à des collectionneurs d’œuvres numériques qui sont uniques ou à tirage limité.

C’est ainsi que sont apparues en 2017 deux applications : CryptoPunks^TMet CryptoKitties^TM. CryptoPunks est une application permettant à des collectionneurs d’acheter puis de vendre à d’autres collectionneurs des vignettes de visage de punks dont les traits sont générés aléatoirement ; CryptoKitties est un jeu vidéo dans lequel un joueur achète des chats virtuels aux caractéristiques physiques différentes pour ensuite les croiser et donner naissance à un nouveau chat virtuel aux caractéristiques uniques, qu’il peut ensuite garder ou échanger avec un autre joueur.

De ces deux applications, qui fonctionnent sur la chaine de blocs Ethereum et qui sont disponibles aujourd’hui sur un large panel de terminal mobile, a émergé un nouveau concept : celui de jeton non fongible (ou NFT). Par définition, un jeton non fongible est un actif chiffré représentant un objet numérique tel qu’une image, une vidéo, ou une piste audio, auquel est rattaché une identité numérique le reliant à un propriétaire. Selon les cas, soit l’objet numérique fait l’objet d’un unique jeton non fongible ; soit il fait l’objet numérique d’un tirage limité, auquel cas il existe autant de jeton non fongibles que d’exemplaires de l’objet numérique voulus, et chaque jeton non fongible de ce tirage est relié à un propriétaire avec une identité numérique propre. C’est cette unicité ou ce tirage limité de l’objet numérique, mais aussi l’acte de propriété, qui garantissent la rareté du jeton non fongible et le rendent non interchangeable et valorisable.

Depuis CryptoKitties et Cryptopunks, de nombreuses applications reposant sur les jetons non fongibles sont apparues, non exhaustivement :
- NBA Top Shot^TM, développé par les créateurs de CryptoKitties, qui permet l’achat et l’échange de jetons non fongibles contenant des vidéos de moments d’un match de basketball (par exemple, une action d’un joueur qui permet à son équipe de marquer un panier) ;
- CryptoKicks^TM, de Nike, qui consiste à acheter un jeton non fongible relatif à représentation numérique unique d’une nouvelle paire de chaussures fabriquée physiquement ;
- Dans le monde de l’Art, des plateformes de marché en ligne comme Opensea^TM, S!ng^TM, sur lesquelles les artistes vendent leurs œuvres numériques (image, vidéo, musique…) sous forme de jeton non fongible, qu’il s’agisse d’œuvres purement numériques ou de représentations numériques d’œuvres physiques. Les acheteurs peuvent également se vendre entre eux les jetons non fongibles. Certaines des plateformes disponibles proposent de procéder, en plus de simples ventes, à des ventes aux enchères.

Toutes les applications citées fonctionnent en étant interfacées à une technologie de chaine de blocs, à la fois pour procéder : à la génération d’un jeton non fongible à partir d’une œuvre numérique et le mettre à la mise à disposition d’un utilisateur, à l’échange d’un jeton non fongible entre deux utilisateurs (un vendeur et un acheteur par exemple) ; mais aussi, si l’échange du jeton non fongible entre deux utilisateurs fait l’objet d’une transaction de paiement électronique (par exemple, achat d’un jeton non fongible d’un utilisateur A à un utilisateur B), à l’étape de paiement électronique proprement dite, en débutant le compte crypto-monnaie (dans l’exemple donnée, compte de l’utilisateur A débité d’une certaine somme en crypto-monnaie, compte de de l’utilisateur B crédité d’une ladite somme). L’ensemble de ces applications fonctionnent également sur une large variété de terminaux mobiles connectés comme les ordinateurs portables, les téléphones mobiles, ou les tablettes.

Toutefois, pour les applications citées, bien qu’un unique ou un nombre limité de jeton non fongible peuvent être créés à partir de l’œuvre numérique, l’œuvre numérique elle-même reste toujours disponible et reproductible. Pour NBA Top Shot, les moments sont conservés et disponibles sur des sites d’hébergement de vidéo tel que Youtube^TM. Un artiste peut quant à lui, ultérieurement, potentiellement recréer de nouveaux jetons non fongibles à partir d’une même œuvre numérique.

La présente invention vise la proposition d’un procédé de mise à disposition d’un ou plusieurs jeton(s) non fongible(s) par un service de chaine de blocs à partir d’un fichier numérique contenant un objet numérique éphémère et non reproductible, et pour lequel l’acte de génération de ce(s) dit(s) jeton(s) n’est réalisable qu’une seule fois, dans le but de rendre le jeton non fongible inéluctablement unique ou à tirage limité. Les concepts de chaine de blocs et de jeton non fongible sont à comprendre selon les définitions qui ont été données précédemment.

L’invention consiste en un procédé de mise à disposition d’un jeton non fongible au moyen d’un terminal mobile connecté à un service de chaîne de blocs, le procédé de mise à disposition étant exécuté par le terminal mobile et comprenant les étapes suivantes :
- une étape de capture en direct d’un évènement par un utilisateur du terminal mobile, au moyen d’un périphérique dudit terminal mobile connecté, de façon à générer et stocker un fichier numérique représentatif de l’évènement dans une partie dédiée d’une mémoire vive du terminal mobile ;
- une étape de transmission du fichier numérique représentatif de l’évènement, et de métadonnées qui lui sont associées, du terminal mobile vers le service de chaine de blocs ;
- une étape de réception, en provenance du service de chaine de blocs, d’une confirmation d’une mise à disposition pour la mise à disposition de l’utilisateur : d’au moins un jeton non fongible généré à partir du fichier numérique représentatif de l’évènement, ainsi qu’au moins un identifiant uniforme de ressource associés à l’au moins jeton non fongible ;
- une étape d’effacement lors de laquelle, suite à l’étape de réception de la confirmation de la mise à disposition dudit au moins un jeton non fongible, le terminal mobile procède à l’effacement du fichier numérique représentatif de l’évènement stocké dans la partie dédiée de la mémoire vive du terminal mobile.

Ainsi, le procédé présente deux spécificités qui sont les suivantes :
- l’objet numérique, ici le fichier numérique représentatif de l’évènement correspond à un évènement capturé en direct et qui est par nature éphémère et non reproductible ;

- le fichier numérique représentatif de l’évènement, et contenant donc l’évènement, n’existe que temporairement dans la mémoire vive du terminal mobile connecté, durant l’intervalle de temps entre le moment de la capture de l’évènement et la mise à disposition de l’utilisateur du ou des jeton(s) non fongible(s).

Ainsi, le service de chaine de blocs ne peut procéder qu’à un seul acte de génération et de mise à disposition de jeton non fongible à partir de ce fichier numérique.

Par conséquent, ces deux spécificités rendent non possible toute reproduction de l’objet numérique lui-même, mais également toute éventuelle nouvelle demande ultérieure de mise à disposition de nouveaux jetons non fongibles à partir de ce dit objet numérique : seuls existent le ou les jeton(s) non fongible(s) qui ont été généré(s) au moment où le procédé a été exécuté, selon que l’auteur ait décidé de générer à partir de cet évènement un jeton non fongible unique ou à tirage limité. Aussi ce procédé renforce inéluctablement le caractère rare de ce ou ces jeton(s) non fongible(s).

Avantageusement, un jeton non fongible généré par le service de chaines de blocs est transmis au terminal mobile de l’utilisateur du terminal, et également un identifiant uniforme de ressource pour : relier le jeton aux métadonnées du fichier numérique qui a servi à sa génération (par exemple : le titre associé à l’objet numérique faisant l’objet du ou des jeton(s) non fongible(s), le nom de l’utilisateur) ; et renforcer sa sécurité.

Selon une caractéristique de l’invention, le procédé de mise à disposition comprend en outre, entre l’étape de transmission du fichier numérique représentatif de l’évènement vers le service de chaîne de blocs et l’étape de réception de la confirmation de la mise à disposition d’au moins un jeton non fongible généré à partir dudit fichier numérique représentatif de l’évènement :
- une étape de réception en provenance du service de chaine de blocs d’un contrat intelligent demandant à l’utilisateur du terminal mobile une autorisation pour la génération et la mise à disposition par le service de chaîne de blocs d’au moins un jeton non fongible généré à partir du fichier numérique représentatif de l’évènement ;
- une étape de signature du contrat intelligent par l’utilisateur du terminal mobile, pour validation dudit contrat intelligent ;
- une étape de transmission du contrat intelligent signé vers le service de chaine de blocs.

On entend par contrat intelligent un programme informatique contenu dans le service de chaine de blocs qui vérifie et exécute, selon des conditions spécifiques définies dans le service de chaine de blocs par le développeur du contrat intelligent, un contrat implémenté sous forme numérique ; puis qui, si les conditions contractuelles sont remplies, va lancer une action. Les contrats intelligent tirent parti des avantages de la technologie de chaine de blocs puissent qu’ils sont datés, historiés, et irrévocables pour les contractant s’ils valident ses termes.

Dans le cadre de l’invention, le contrat intelligent sert à confirmer, auprès de l’utilisateur, sa demande de génération et de mise à disposition de jeton non fongible à partir de son fichier numérique représentatif d’un évènement. Avantageusement, le contrat intelligent sert aussi de façon immuable à prouver l’authenticité du ou des futur(s) jeton(s) généré(s), et l’identité de l’utilisateur du terminal mobile comme propriétaire de ce(s) jeton(s) non fongible(s). L’exécution du contrat intelligent, si les conditions requises sont remplies, entraîne la génération du ou des jeton(s) non fongible(s).

Selon une caractéristique de l’invention, le procédé de mise à disposition est lancé puis exécuté au moyen d’une fonction implémentée dans une application mobile dédiée, ladite application mobile dédiée étant accessible à partir du terminal mobile ; et contrôlant le périphérique et la partie dédié de la mémoire vive du terminal mobile qui est allouée à ladite application mobile dédiée, ainsi que les opérations de capture en direct d’un évènement et les opérations de lecture, d’écriture et d’effacement de ladite partie dédiée de la mémoire vive du terminal mobile.

Autrement dit, l’utilisateur du terminal mobile connecté se sert d’une application mobile proposant un certain nombre de fonctionnalités, dont une conçue pour interagir : avec au moins un périphérique du terminal mobile pour la capture de l’évènement ; avec la mémoire vive du terminal mobile pour écrire puis effacer le fichier numérique généré suite à la capture de l’évènement et représentatif de celui-ci ; et avec un service de chaine de blocs pour la mise à disposition du ou des jeton(s) non fongible(s).

Selon une caractéristique de l’invention, l’étape de capture en direct d’un évènement est réalisée au moyen d’au moins un des périphériques suivants du terminal mobile :
- une caméra, de sorte que le fichier numérique représentatif de l’évènement est un fichier image ;
- un microphone, de sorte que le fichier numérique représentatif de l’évènement est un fichier audio ;
- une caméra associée à un microphone, de sorte que le fichier numérique représentatif de l’évènement est un fichier vidéo.

Ainsi, le procédé de mise à disposition est compatible avec une pluralité de périphériques du terminal mobile. Avantageusement, l’utilisateur n’est pas restreint quant à ses possibilités de capture d’un évènement, pouvant aussi bien : prendre une photo dudit évènement ; tourner sa propre vidéo de celui-ci ; ou enregistrer uniquement du son dans le cas où par exemple, le jeton non fongible qu’il souhaite avoir à disposition, soit relatif à une musique ou un discours.

Selon une possibilité de réalisation de l’invention, le procédé de mise à disposition comprend, entre l’étape de capture en direct d’un évènement et l’étape de transmission du fichier numérique représentatif de l’évènement à destination du service de chaîne de blocs, une étape intermédiaire de modification mettant en œuvre une modification dudit fichier numérique représentatif de l’évènement.

Avantageusement, au travers de cette étape, l’utilisateur modifie le fichier numérique pour personnaliser l’objet numérique lui-même. En plus de capturer et immortaliser l’évènement au travers de l’objet numérique, l’utilisateur a ainsi la possibilité de faire part dans ce même objet de sa vision et/ou de son ressenti face à l’évènement. La modification peut consister par exemple en l’application d’un ou plusieurs filtres, tels que des filtres image, vidéo ou audio.

Selon une possibilité de réalisation de l’invention, lorsque le fichier numérique représentatif de l’évènement est un fichier image ou vidéo, l’étape intermédiaire de modification dudit fichier numérique représentatif de l’évènement comprend l’ajout d’au moins un effet visuel, comme par exemple un filtre ou un émoticône.

Autrement dit, l’utilisateur peut, dans le cas où il a pris une photo ou une vidéo d’un évènement, modifier le fichier numérique pour personnaliser l’objet numérique qu’il contient, en appliquant par exemple des effets visuels comme un filtre (par exemple, noir et blanc, sépia). L’avantage de ces filtres est de permettre possiblement la création d’une collection de jeton non fongible selon un thème artistique spécifique, par exemple des photos noir et blanc de concerts en plein air.

Selon une caractéristique de l’invention, les métadonnées associées au fichier numérique représentatif de l’évènement contiennent des informations relatives à l’évènement, le procédé de mise à disposition comprenant une étape de saisie d’informations mettant en œuvre une saisie par l’utilisateur desdites informations sur le terminal mobile.

Ainsi, à l’aide du clavier virtuel de son terminal mobile, l’utilisateur va saisir au moins un nom à son fichier numérique représentatif de l’évènement, qui sera également celui du ou des jeton(s) non fongible(s) généré(s) à partir du fichier numérique. Par exemple, l’utilisateur peut être un artiste voulant donner un nom ou titre à son œuvre numérique. Parmi les autres possibilités, l’utilisateur peut : saisir son nom s’il souhaite que celui-ci soit associé au(x) jeton(s) non fongible(s) généré(s) (un artiste apposant son nom sur l’œuvre numérique dont il est l’auteur) ; associer au fichier numérique un texte descriptif, ou des mots-dièses pour l’accéder à du contenu relatif aux mots référents et en lien avec l’objet numérique compris dans le fichier numérique.

Selon une possibilité de réalisation de l’invention, les métadonnées associées au fichier numérique représentatif de l’évènement comprennent une requête de mise à disposition par le service de chaine de blocs d’un seul et unique jeton non fongible à partir du fichier numérique représentatif de l’évènement.

Avantageusement, au travers de cette possibilité de réalisation, le service de chaine de blocs ne génère et ne met à disposition de l’utilisateur qu’un seul et unique jeton non fongible à partir du fichier numérique représentatif de l’évènement, en réponse à la requête émise sous forme de métadonnée que lui a envoyé le terminal mobile avec le fichier numérique représentatif de l’évènement. Indéniablement et inéluctablement, le fait même qu’il n’existe qu’un unique jeton non fongible représentant un objet numérique non reproductible rend ce dit jeton non fongible d’une insigne rareté, augmentant ainsi très fortement sa valeur (par exemple, pour des collectionneurs souhaitant posséder un objet numérique unique).

Selon une possibilité de réalisation de l’invention, le procédé de mise à disposition, avant l’étape de transmission du fichier numérique représentatif de l’évènement au service de chaine de blocs, comprend une étape de saisie d’un nombre mettant en œuvre une saisie d’un nombre de jeton non fongible à mettre à disposition par le service de chaine de blocs à partir du fichier numérique représentatif de l’évènement, ce dit nombre de jeton non fongible saisi faisant ensuite partie intégrante des métadonnées transmises par le terminal mobile au service de chaine de blocs en association avec le fichier représentatif de l’évènement.

Ainsi, l’utilisateur, au travers de cette saisie, émet une requête au service de chaine de blocs quant au nombre de jeton non fongible à générer à partir du fichier numérique représentatif de l’évènement, selon qu’il souhaite que l’objet numérique contenu dans le fichier numérique fasse l’objet d’un jeton non fongible unique ou d’un tirage limité à quelques exemplaires.

Selon une possibilité de réalisation de l’invention, le procédé de disposition, suite à la saisie du nombre de jeton non fongible à générer par le service de chaine de blocs, comprend une étape de saisie du nombre de jeton non fongible qui fera l’objet d’une vente, et d’au moins une condition de vente.

Dans ce mode de réalisation, l’utilisateur du terminal mobile peut déjà décider s’il va conserver ou vendre le ou les jeton(s) non fongible(s) qui vont être générés et mis à disposition par le service de chaine de blocs. Dans le cas d’un tirage limité, l’utilisateur peut décider de vendre tout ou partie des jetons non fongibles générés. Si l’utilisateur décide de vendre son ou ses futur(s) jeton(s) non fongible(s), il doit définir au minimum une condition de vente, qui correspond au prix de vente de son ou ses jeton(s) non fongible(s). Il peut ensuite de la nature de la vente (vente classique ou vente aux enchères), de sa date d’ouverture et de sa durée.

Selon une caractéristique de l’invention, le terminal mobile connecté communique et interagit avec le service de chaine de blocs au moyen de l’application mobile dédiée et au travers d’interfaces graphiques.

Autrement dit, l’application mobile dédiée contient plusieurs interfaces graphiques avec lesquelles : l’utilisateur interagit pour les étapes de capture de l’évènement et de personnalisation/modification du fichier numérique représentatif de l’évènement ; et aussi pour communiquer avec le service de chaine de blocs pour les étapes d’envoi du fichier numérique, de signature du contrat intelligent, et de confirmation de mise à disposition d’un ou plusieurs jeton(s) non fongible(s).

L’invention se rapporte également à un procédé de disposition d’un jeton non fongible au moyen d’un terminal mobile connecté à un service de chaîne de blocs, le procédé de mise à disposition étant exécuté par un système de service dorsal et comprenant les étapes suivantes :
- une étape de réception d’un fichier numérique représentatif d’un évènement, qui a été capturé en direct, et de ses métadonnées associées, en provenance d’un terminal mobile connecté ;
- une étape de transmission du fichier numérique représentatif d’un évènement et des métadonnées associées vers le service de chaîne de blocs ;
- une étape de réception, en provenance du service de chaine de blocs, de l’au moins un jeton non fongible, et au moins un identifiant uniforme de ressource associé, et une confirmation de la mise à disposition desdits au moins un jeton non fongible, et au moins un identifiant uniforme de ressource ;
- une étape de stockage de l’au moins un jeton non fongible dans une base de données administrée par le système de service dorsal, et dudit au moins un identifiant uniforme de ressource associé ;
- une étape de transmission vers le terminal mobile de la confirmation de la mise à disposition dudit au moins un jeton non fongible, et dudit au moins un identifiant uniforme de ressource associé.

Autrement dit, l’ensemble des échanges entre le terminal mobile connecté et le service de chaine de blocs, pour la mise à disposition de jeton non fongible par le service de chaine de blocs à partir d’un fichier numérique représentatif d’un évènement envoyé depuis le terminal mobile, se font par l’intermédiaire d’un système de service dorsal, aussi appelé « backend service ». Le système de service dorsal stocke également dans un espace de la base de donnée dédié à un utilisateur : au moins un jeton non fongible appartenant à cet utilisateur, ainsi que l’identifiant uniforme de ressource qui lui est associé, tous ces éléments ayant été transmis puis générer par le service de chaine de blocs ; et les métadonnées relatives audit au moins jeton non fongible, correspondantes aux métadonnées associées au fichier numérique dont est issu l’au moins un jeton non fongible, que le système de service dorsal a récupéré puis stocké dans l’espace de la base de donnée dédié à l’utilisateur lors de la réception du fichier numérique et desdites métadonnées associées.

Selon une caractéristique de l’invention, le procédé de mise à disposition comprend en outre une phase de gestion d’un contrat intelligent comprenant les étapes suivantes :
- une étape de réception, en provenance du service de chaine de blocs, du contrat intelligent pour une demande d’autorisation de la génération et de la mise à disposition d’au moins un jeton non fongible à partir du fichier numérique représentatif de l’évènement par le service de chaine de blocs ;
- une étape de transmission du contrat intelligent vers le terminal mobile ;
- une étape de réception, en provenance du terminal mobile, du contrat intelligent signé ;
- une étape de transmission du contrat intelligent signé vers le service de chaine de blocs.

Autrement dit, le système de service dorsal sert également d’intermédiaire entre le terminal mobile connecté et le service de chaine de blocs pour l’étape de signature du contrat intelligent.

Dans une première variante de réalisation, la phase de gestion du contrat intelligent se déroule suite à l’étape de transmission du fichier numérique représentatif de l’évènement et de ses métadonnées associées vers le service de chaine de blocs. Dans une seconde variante, la phase de gestion du contrat intelligent se déroule avant l’étape de transmission du fichier numérique représentatif de l’évènement et de ses métadonnées associées vers le service de chaine de blocs, et suite à l’envoi d’une requête de mise à disposition de jeton non fongible.

Selon une caractéristique de l’invention, suite à l’étape de réception du fichier numérique représentatif de l’évènement et de ses métadonnées associées, le procédé de mise à disposition comprend une étape de génération et stockage dans la base de donnée d’une version dégradée dudit fichier numérique représentatif de l’évènement, cette version dégradée étant soit dans un format de qualité inférieure à celui du fichier numérique représentatif de l’évènement, soit dans un format identique mais pour lequel des caractéristiques ont été dégradées, par exemple, pour un fichier image source haute résolution au format JPEG, la génération d’une version dégradée au format GIF, ou la génération d’une version dégradée au format JPEG basse résolution.

Avantageusement, cette version dégradée, générée par le système de service dorsal, sert à prouver que l’utilisateur est bien à l’origine de la génération d’un ou plusieurs jeton(s) non fongible(s) en lien avec un évènement capturé en direct, dans le cas où l’utilisateur viendrait à ne plus être propriétaire du ou des jeton(s) non fongible(s), par exemple suite à un acte de cession.

Selon une caractéristique de l’invention, e procédé de mise à disposition comprend, suite à l’étape de transmission de la confirmation de mise à disposition d’au moins un jeton non fongible, une étape de transmission par le système de service dorsal vers le terminal mobile de la version dégradée du fichier numérique représentatif de l’évènement et ayant fait l’objet d’une mise à disposition de jeton non fongible.

Autrement dit, suite à l’envoi au terminal mobile de la confirmation de mise à disposition de jeton non fongible, le système de service dorsal va également envoyer au terminal mobile la version dégradée du fichier numérique qu’il a généré à partir du fichier d’origine.

Avantageusement, cela permet à l’utilisateur de communiquer, par exemple sur un réseau social, sur le fait qu’il a généré un ou plusieurs jeton(s) non fongible(s) à partir d’un objet numérique, de diffuser et d’exposer un aperçu de l’objet numérique, cela sans pour autant manipuler directement ledit ou lesdits jeton(s) non fongible(s). En effet, manipuler un jeton non fongible directement peut potentiellement être problématique en termes de sécurité. Par exemple, si l’utilisateur se rend sur un site communautaire ayant un faible niveau de sécurité et diffuse un jeton non fongible, rien ne garantit qu’une personne malintentionnée ne puisse pas s’approprier illégalement le jeton non fongible.

Selon une caractéristique de l’invention, le procédé de mise à disposition comprend, suite à au stockage dans la base de données dans un espace de stockage de données dédié à un utilisateur d’un premier terminal mobile d’un jeton non fongible, et d’un identifiant uniforme de ressource et d’une version dégradée du fichier numérique représentatif de l’évènement associés, le transfert dudit jeton non fongible vers un second espace de stockage de données dédié à un second utilisateur d’un deuxième terminal mobile est exécuté par le système de service dorsal dans la base de données selon les étapes suivantes :
- une étape de récupération dans l’espace de stockage de données dédié à un utilisateur d’un premier terminal mobile du jeton non fongible, et de son identifiant uniforme de ressource associé, seul étant conservé dans ledit espace de stockage de données dédié à un utilisateur d’un premier terminal mobile la version dégradée du fichier numérique représentatif de l’évènement ;
- une étape de stockage du jeton non fongible, et de l’identifiant uniforme de ressource associé, dans l’espace de stockage de données dédié au second utilisateur d’un deuxième terminal mobile.

Ainsi, outre la génération par un service de chaine de blocs et le stockage dans une base de données de jeton non fongible, le procédé de mise à disposition permet également la manipulation de jeton non fongible au moyen du système de service dorsal, comme ici me transfert d’un jeton non fongible d’un premier utilisateur vers un second utilisateur, ce transfert pouvant être par exemple représentatif d’une cession par le premier utilisateur dudit jeton non fongible au second utilisateur. Est aussi transféré au second utilisateur l’identifiant uniforme de ressource associé au jeton non fongible. Le premier utilisateur ne conserve dans son espace dédié dans la base de données que la version dégradée du fichier numérique représentatif de l’évènement ayant fait l’objet de la mise à disposition du jeton non fongible, cette version dégradée ayant pour utilité de prouver que le premier utilisateur fut celui à l’origine de la mise à disposition du jeton non fongible, et donc le premier propriétaire du jeton non fongible.

Selon une caractéristique de l’invention, le terminal mobile connecté communique et interagit avec le système de service dorsal au moyen de l’application mobile dédiée et au travers d’interfaces graphiques.

Autrement dit, au moyen des interfaces graphiques de l’application mobile dédiée, le terminal mobile interagit : indirectement avec le service de chaine de blocs pour la génération et la mise à disposition de jeton non fongible à partir du fichier numérique représentatif de l’évènement par l’intermédiaire du système de service dorsal, le système de service dorsal étant transparent du point de vue de l’utilisateur du terminal mobile dans le cadre des échanges avec le service de chaine de bloc ; directement avec le système de service dorsal lorsqu’il y a manipulation par l’utilisateur de son ou ses jeton(s) non fongible(s) stocké(s) dans la base de données.

Selon une possibilité de réalisation de l’invention, le procédé de mise à disposition, pour la mise à disposition par un service de chaine de blocs d’au moins un jeton non fongible à partir d’un fichier représentatif d’un évènement transmis par un terminal mobile connecté, fait communiquer soit directement ledit terminal mobile connecté avec le service de chaine de blocs, soit indirectement avec un système de service dorsal tenant un rôle d’intermédiaire.

Deux possibilités de réalisation sont donc possibles pour la mise en œuvre de la méthode de disposition par un service de chaine de blocs d’au moins un jeton non fongible à partir d’un fichier représentatif d’un évènement transmis par un terminal mobile connecté : une méthode indirecte pour laquelle le terminal mobile connecté et le service de chaine de blocs communique par le biais d’un système de service dorsal, et une méthode directe pour laquelle le terminal mobile connecté et le service de chaine de blocs communique sans intermédiaire.

Dans le cas de la méthode indirecte, suite à la génération d’au moins un jeton non fongible par le service de chaine de blocs, ledit au moins un jeton non fongible, ainsi que son identifiant uniformes de ressource associé, sont transmis par le service de chaine de blocs au s système de service dorsal qui va les stocker dans la base de données, le système de service dorsal envoyant au terminal mobile une confirmation de mise à disposition de l’au moins un jeton non fongible.

Dans le cas de la méthode directe, ledit au moins un jeton non fongible, ainsi que son identifiant uniformes de ressource associé, sont transmis par le service de chaine de blocs au terminal mobile. Le terminal mobile stocke donc dans sa mémoire ledit au moins un jeton non fongible, son identifiant uniformes de ressource associé. Le terminal mobile contient également les métadonnées relatives à l’au moins un jeton non fongible, générées et stockées dans le terminal mobile lorsque fut édité par l’utilisateur le fichier numérique représentatif de l’évènement à l’origine de la mise à disposition de l’au moins un jeton non fongible.

Les caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description détaillée ci-après d’un exemple de mise en œuvre non limitatif, faite en référence aux figures annexées pour lesquelles :

est un schéma montrant les systèmes intervenant dans la mise en œuvre du procédé de mise à disposition selon un mode de réalisation de l’invention. Pour ce mode de réalisation sont considérés un terminal mobile connecté, un système de service dorsal administrant une base de données, et un service de chaine de blocs. La figure montre aussi les interactions entre ces trois systèmes.

est un diagramme de fonctionnement détaillant étape par étape le déroulement du procédé de disposition selon le mode de réalisation pris en considération et illustré .

[Description détaillée d’un ou plusieurs modes de réalisation de l’invention]

En référence à la , le procédé de mise à disposition pour la mise à disposition de jeton non fongible JNF à partir d’un fichier numérique dF représentatif d’un évènement, qui est éphémère et non reproductible, fait intervenir trois acteurs :
- Un terminal mobile MD connecté, qui capture l’évènement éphémère et non reproductible, génère et transmet un fichier numérique dF représentatif de l’évènement pour une mise à disposition de jeton non fongible JNF ;
- Un service de chaine de blocs BC, qui génère et met à disposition un ou plusieurs jeton(s) non fongible(s) JNF à partir du fichier numérique dF représentatif de l’évènement qu’il réceptionne ;
- Un système de service dorsal BEserv qui sert d’intermédiaire dans les échanges entre le terminal mobile ND et le service de chaine de blocs BC, et de moyen de stockage et de mise à disposition des jetons non fongibles JNF que génère le service de chaine de blocs BC.

Les interactions entre le système de service dorsal BEserv et le service de chaine de blocs BC apparaissent comme transparentes du point de vue du terminal mobile MD.

Le procédé de mise à disposition est également réalisable en ne faisant intervenir qu’un terminal connecté MD et un service de chaine de blocs BC, les jetons non fongibles JNF générés par le service de chaine de blocs BC étant alors directement stockés et mis à disposition sur le terminal mobile MD.

Le procédé de mise à disposition se matérialise sous la forme d’une fonction Func se lançant et s’exécutant à partir d’une application mobile dédiée App que l’utilisateur Usr du terminal mobile MD connecté va en premier lieu télécharger sur son terminal mobile MD. Dans le cadre du mode de réalisation illustré , le terminal mobile MD est considéré comme étant un téléphone mobile, mais il est également envisageable de considérer par exemple une tablette ou un ordinateur portable. L’application mobile dédiée se veut la plus agnostique possible en fonctionnant sous plusieurs versions de différents systèmes d’exploitation mobile tels que Android^TMou iOS^TM.

Lorsque l’utilisateur Usr lance l’application mobile dédiée App de son terminal mobile MD, il se retrouve connecté à une plateforme numérique communautaire correspondant à un système de service dorsal BEserv qui administre une base de données dataB utilisée pour le stockage et la gestion de jetons non fongibles JNF.

L’utilisateur interagit avec le système de service dorsal BEserv et, par le biais de celui-ci, avec la base de données dataB sous-jacente, par le biais d’interfaces graphiques utilisateur affichées par l’application mobile dédiée App sur le téléphone mobile MD de l’utilisateur, et selon : des interfaces de programmation d’application respectant les contraintes d’un style d’architecture logicielle pour la création de services web ; et d’un protocole de communication client-serveur sécurisé pour Internet. En référence au mode de réalisation illustré , le terminal mobile MD, au travers de l’application mobile dédiée App, communique avec le système de service dorsal BEserv en HTTPS au moyen d’une API REST standard.

Lorsque l’utilisateur Usr se sert pour la première fois de l’application mobile dédiée App, celle-ci lui demande soit : de créer/renseigner un profil utilisateur ; ou de transférer un profil utilisateur d’un réseau social comme Instagram^TMou Twitter^TM. L’une comme l’autre des actions entraine la création par le système de service dorsal BEserv d’un profil utilisateur spécifique à l’utilisateur Usr consultable au moyen de l’application mobile dédiée App sur le terminal mobile MD, et se traduisant dans la base de données dataB par l’allocation d’un espace de stockage données dédié à l’utilisateur Esp1, Esp2,…,Espn, selon que l’utilisateur Usr soit le premier, le second ou le nième utilisateur à avoir créer son profil spécifique sous la plateforme numérique.

Dans la suite de cette description détaillée, on considère pour plus de praticité que l’utilisateur Usr est le premier à avoir créé un profil sur la plateforme, et qui lui est donc attribué un espace de stockage dédié Esp1. En plus du profil spécifique de l’utilisateur Usr, le système de service dorsal BEserv génère un portefeuille électronique W qui est stocké dans l’espace de stockage de données Esp1 dédié à l’utilisateur Usr, ce portefeuille électronique W servant au stockage du ou des jeton(s) non fongible(s) JNF de l’utilisateur Usr. L’utilisateur Usr a aussi la possibilité de relier son profil spécifique à une solution de portefeuille électronique dont il serait déjà en possession.

Suite à la création de son profil spécifique sur la plateforme numérique communautaire, l’utilisateur Usr peut se servir de l’ensemble des fonctionnalités proposées par l’application mobile dédiée App, dont la fonction Func de mise à disposition de jeton non fongible JNF à partir d’un évènement capturé en direct avec le terminal mobile MD.

En référence au diagramme de fonctionnement de la , la première étape se produisant lorsque l’utilisateur Usr lance la fonction Func est l’étape de capture en direct de l’évènement E0 au moyen d’un périphérique du terminal mobile MD que va venir contrôler l’application mobile dédiée App.

La capture de l’évènement est suivie par la génération par l’application mobile App d’un fichier numérique dF représentatif de l’évènement qui va être stocké temporaire dans la partie dédiée de la mémoire vive du terminal mobile MD qui est allouée à l’application mobile dédiée App.

L’application mobile dédiée App et la fonction Func sont compatibles avec plusieurs types de périphérique de terminal mobile. Selon si le terminal mobile MD en dispose, il est possible de prendre une photo de l’évènement au moyen d’une caméra, de capturer du son avec un microphone, ou bien encore réaliser une vidéo de l’évènement lorsque sont associées une caméra et un microphone. Ainsi, selon le cas, le fichier numérique dF représentatif de l’évènement peut être un fichier image, un fichier audio, ou un fichier vidéo.

Eventuellement, suite à l’étape de capture en direct de l’évènement E0, l’utilisateur Usr peut ou non personnaliser le fichier numérique dF représentatif de l’évènement au travers d’une étape intermédiaire de modification E1. Par exemple, dans les cas où le fichier numérique dF représentatif de l’évènement est un fichier image ou vidéo, l’utilisateur Usr peut non exhaustivement ajouter des GIFs, des émoticônes, des filtres, etc.

Suite à l’étape intermédiaire de modification E1, l’utilisateur Usr va saisir à l’aide du clavier virtuel de son terminal mobile MD, durant une étape de saisie E2, des informations relatives au fichier numérique dF représentatif de l’évènement. A minima, l’utilisateur Usr donne un nom au fichier numérique dF représentatif de l’évènement. Il peut ensuite fournir d’autres informations comme son nom, un texte décrivant / caractérisant l’évènement capturé ; associer le fichier numérique dF représentatif de l’évènement à des mots-dièses en lien avec l’évènement capturé (par exemple : « Photo de xxx, tirage unique »); etc.

L’étape de saisie E2 est suivi d’une étape de saisie d’un nombre E3 au cours de laquelle l’utilisateur Usr indique le nombre de jeton non fongible JNF qu’il souhaite avoir mis à disposition à partir du fichier numérique dF représentatif de l’évènement. L’utilisateur peut donc décider que son fichier numérique dF représentatif de l’évènement fera l’objet d’un jeton non fongible JNF unique ou d’un tirage limité. De manière simpliste, une possibilité de réalisation est de définir une variable nb_JNF telle que : nb_JNF = 1 dans le cas où une demande de jeton unique est requêtée, nb_JNF = value avec value le nombre d’exemplaire souhaité du jeton non fongible JNF.

Dans une autre possibilité de réalisation, cette étape de saisie d’un nombre E3 n’est pas implémentée. Le procédé de mise à disposition, codé au travers de la fonction Func, est alors définie pour ne mettre automatiquement à disposition de l’utilisateur Usr qu’un seul et unique jeton non fongible à partir du fichier numérique dF représentatif de l’évènement. Une idée de codage, en regard de la possibilité de réalisation de l’étape E3 exposée ci-dessus, est de fixer nb_JNF = 1.

Dans une autre possibilité de réalisation, suite à l’étape de saisie d’un nombre E3, la fonction Func comprend une étape de saisie du nombre de jeton non fongible qui fera l’objet d’une vente. Deux cas de figure se présentent alors : soit l’utilisateur Usr décide de ne vendre aucun jeton non fongible JNF qui lui sera mis à disposition ; soit il décide de vendre au moins un jeton non fongible JNF qui lui sera mis à disposition, auquel cas il devra spécifier au moins une condition de vente, à savoir le prix de vente. Il peut ensuite préciser la nature de la vente (vente classique ou vente aux enchères), sa date d’ouverture et de sa durée, etc.

Les informations renseignées par l’utilisateur Usr au cours de l’étape de saisie E2 et de l’étape de saisie d’un nombre E3 sont associées au fichier numérique représentatif de l’évènement sous forme de métadonnées Mdata.

Suite à l’étape de saisie d’un nombre E3, l’utilisateur Usr visualise dans une interface graphique faisant office de récapitulatif le contenu du fichier numérique dF représentatif de l’évènement et l’ensemble des informations qu’il a fourni. L’interface graphique lui propose le choix de revenir en arrière pour modifier les informations associées au fichier numérique dF représentatif de l’évènement, ou celui de poursuivre la procédure de mise à disposition de jeton non fongible JNF.

Lorsque l’utilisateur Usr décide de poursuivre la procédure de mise à disposition de jeton non fongible, le terminal mobile MD transmet, lors d’une étape de transmission E4, et au travers du protocole de communication client-serveur sécurisé pour Internet (dans ce mode de réalisation, HTTPS), au système de service dorsal BEserv le fichier numérique dF représentatif de l’évènement et ses métadonnées associées Mdata. Le système de service dorsal BEserv va accuser réception du fichier numérique dF représentatif de l’évènement et des métadonnées associées Mdata au dit fichier lors d’une étape de réception E4’. Il va ensuite stocker le fichier numérique dF représentatif de l’évènement et les métadonnées associées Mdata dans l’espace de stockage de données Esp1 dédié à l’utilisateur Usr. A partir du fichier numérique dF représentatif de l’évènement, le système de service dorsal BEserv va générer et stocker dans l’espace de stockage de données Esp1 dédié à l’utilisateur Usr, durant une étape de génération et de stockage E5, une version dégradée lowdF du fichier numérique dF représentatif de l’évènement. Selon différents modes de réalisation, le procédé pour dégrader le fichier numérique dF représentatif de l’évènement peut éventuellement consister à générer un fichier numérique dégradé dans un format de qualité inférieure à celui du fichier numérique dF représentatif de l’évènement, ou dans un format identique mais pour lequel des caractéristiques ont été dégradées. Par exemple, si on suppose que le fichier numérique dF représentatif de l’évènement transmis au système de service dorsal BEserv est un fichier image haute résolution au format JPEG, le système de service dorsal BEserv peut éventuellement générer une version dégradée lowdF au format GIF, ou générer une version dégradée lowdF au format JPEG basse résolution.

Suite à l’étape de génération et de stockage E5, le système de service dorsal BEserv transmet à un service de chaine de blocs BC le fichier numérique dF représentatif de l’évènement et ses métadonnées associées au cours d’une étape de transmission E6. Ainsi, seul est conservé dans l’espace de stockage de données Esp1 de l’utilisateur Usr la version dégradée lowdF du fichier numérique dF représentatif de l’évènement.

Selon la définition donnée précédemment pour un système de chaine de blocs, le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées sont transmis à un système décentralisé / nœud distant connecté au service de chaîne de blocs BC au cours d’une étape de transmission E6. L’étape de transmission E6 requière :
- d’implémenter dans la conception et la programmation du système de service dorsal BEserv des fonctions lui permettant de communiquer et d’interagir avec le nœud distant ; et
- dans la mesure où le fichier numérique dF représentatif de l’évènement peut être un fichier image, un fichier audio, ou un fichier vidéo, d’implémenter également dans le système de service dorsal BEserv un protocole pair à pair de distribution de contenu adressable par hypermédia ; étant entendu par hypermédia une extension qui ajoute aux informations de type texte (par exemple, des métadonnées) d'autres médias comme des images, des sons, des vidéos ou encore des données multimédia.

Le service de chaine de blocs BC à considérer doit être en capacité de supporter des transactions pair-à-pair (c’est-à-dire, une transaction en entre deux entités qui sont à la fois client et serveur, comme ici le système de service dorsal BEserv et le nœud distant) reposant sur l’échange de jeton non fongible JNF. Cependant, selon le mode de réalisation du procédé de mise à disposition, dans le cas où un échange de jeton non fongible JNF ferait également l’objet d’une transaction électronique de paiement pair-pair (ce point sera abordé plus loin dans la description), le service de chaine de blocs doit aussi être en capacité de supporter les échanges de crypto-monnaie.

Le procédé de réalisation décrit suppose que le ou les jetons non fongibles JNF générés par le procédé de mise à disposition feront l’objet de transfert entre utilisateurs et donc de transaction de paiement électronique. Ainsi est considéré comme exemple non limitatif de service de chaine de blocs BC dans le cadre de la présente méthode de réalisation de l’invention le service de chaine de blocs Ethereum. Deux possibilités de réalisation sont ensuite envisageables concernant le nœud distant : soit considérer un nœud distant faisant partie intégrante du service de chaine de blocs BC, soit considérer un nœud distant appartenant à un réseau qui communique avec le service de chaine de blocs BC. Pour le mode de réalisation présentement décrit, le système de service dorsal BEserv communique avec un nœud distant Polygon Np qui sert d’intermédiaire dans les échanges entre le système de service dorsal BEserv et le service de chaine de blocs BC Ethereum. Brièvement, Polygon^TMest un service de chaine de blocs fonctionnant en parallèle du service de chaine de bloc Ethereum, qui permet de déporter sur celui-ci une partie des transactions arrivant sur Ethereum de plus en plus impacté par des problématiques d’encombrement et de délai de temps de traitement des transactions. Outre sa compatibilité avec Ethereum, les avantages de Polygon sont sa robustesse (jusqu’à 65000 transactions par seconde), sa rapidité de validations de transactions (moins de deux secondes), sa capacité de mise à l’échelle et sa sécurité. Les échanges entre le nœud distant Polygon Np et le service de chaine de blocs BC Ethereum sont transparents du point de vue du système de service dorsal BEserv.

Selon ces considérations, ont été implémentées dans le système de service dorsal BEserv des fonctionnalités de libraires Web3js pour afin qu’il interagisse et communique avec le nœud distant Polygon Np. Le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées sont envoyées par le système de service dorsal BEserv au nœud au moyen du protocole IPFS.

Suite à l’étape de transmission E6, le nœud distant Polygon NP réceptionne durant une étape de réception E6’ puis stocke le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées. Le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées vont être regroupés par le nœud distant Polygon Np sous la forme d’une transaction qui va être contenue dans un bloc qui va être validé par un des autres nœuds de Polygon selon la méthode dite de Preuve d’Enjeu (« Proof-Of-Stake » en anglais). Une fois que le bloc est validé, il est intégré à la suite des autres blocs constituant la chaine de blocs du service de chaine de blocs BC Ethereum. Le bloc, et donc la transaction de transmission au service de chaine de bloc BC Ethereum du fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées, est horodaté et historié.

Parallèlement à la génération du bloc qui va contenir le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées par le nœud distant Polygon Np, ledit nœud distant Polygon Np va envoyer une requête au service de chaine de blocs BC Ethereum pour la récupération d’un contrat intelligent CI qui a été implémenté dans le service de chaine de blocs BC Ethereum en vue de la mise en œuvre du procédé de mise à disposition. Pour l’invention présentée, le contrat intelligent CI sert in fine à l’exécution de la procédure même de génération et de mise à disposition de jeton non fongible JNF à partir d’un fichier numérique dF représentatif de l’évènement, sous réserve que les conditions du contrat intelligent CI à l’origine du lancement de la procédure soient remplies. Plusieurs langages de programmation et d’implémentation de contrat intelligent CI dans un service de chaine de bloc sont disponibles dans la littérature. Dans le cadre de la méthode de réalisation exposée, le contrant intelligent CI a été écrit et implémenté dans le service de chaine de blocs BC Ethereum au moyen du langage de programmation orienté objet dédié à l'écriture de contrats intelligents Solidity, qui est aussi compatible avec le service de chaine de blocs BC Polygon.

Une fois que le nœud distant Polygon Np reçoit le contrat intelligent CI, celui-ci le transmet au système de service dorsal BEserv lors d’une étape de transmission E7. Le système de service dorsal BEserv accuse réception du contrat intelligent CI lors d’une étape de réception E7’, puis le transmet au terminal mobile MD de l’utilisateur Usr lors d’une étape de transmission E8, ledit terminal mobile MD accusant réception du contrat intelligent CI lors d’une étape de réception E8’.

Suite à l’étape de réception E8’, l’utilisateur Usr vérifie les termes du contrat intelligent CI puis les approuve durant une étape de signature E9. Pour l’utilisateur Usr, le contrat intelligent CI se présente comme une demande de confirmation de lancement de la procédure de génération puis de mise à disposition de jeton non fongible JNF.

Lorsque l’utilisateur Usr accepte et signe les termes du contrat intelligent CI, le contrat intelligent CI signé est renvoyé lors d’une étape de transmission E10 au système de service dorsal BEserv qui en accuse réception lors d’une étape de réception E10’. A son tour, le système de service dorsal BEserv transmet lors d’une étape de transmission E11 le contrat intelligent CI signé au nœud distant Polygon Np qui va le réceptionner lors d’une étape de réception E11’. Le nœud distant Polygon Np transmet ensuite au service de chaine de bloc BC Ethereum le contrat intelligent CI signé.

Si la transaction a été validée par le service de chaine de blocs BC Polygon, alors le contrat intelligent CI signé récupère dans le nœud distant Polygon Np le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées, puis lance l’exécution dans le service de chaine de blocs BC Ethereum la procédure de génération et de mise à disposition de jeton non fongible JNF. Différentes normes pour la génération de jeton non fongible JNF sous le service de chaine de blocs BC Ethereum existent comme par exemple les normes ERC-721 et ERC-1155. La norme à considérer dépend des fonctionnalités ambitionnées pour le procédé de mise à disposition, notamment : selon si le fichier numérique dF représentatif de l’évènement va faire l’objet d’une mise à disposition d’un unique ou de plusieurs jetons non fongibles JNF ; et si les jetons non fongibles JNF mis à disposition feront ou non ultérieurement l’objet de transactions de paiement électronique. Par exemple, la norme ERC-721 n’est par exemple pas compatible avec les norme ERC-20 qui définit un ensemble de règles pour la création des jetons fongibles en lien avec la crypto-monnaie Ether. Une transaction de paiement électronique pair-à-pair autour d’un jeton non fongible nécessiterait alors l’établissement de deux contrats intelligents : un premier relatif à l’acte de paiement en crypto–monnaie Ether, un second pour l’acte de transfert du jeton non fongible JNF. Il faudrait également implémenter des fonctionnalités dans le service de chaine de bloc BC Ethereum pour relier les deux types de contrat. De plus, la norme ERC-721 ne permet pas de générer directement un identifiant de jeton avec le jeton non fongible JNF.

La norme ERC-1155 répond à ces problématiques : en étant compatible avec la norme ERC-20, ce qui permet dans le cadre d’un même contrat intelligent CI de procéder à la transaction pair-à-pair à des échanges de jetons fongibles (Ether) et de jetons non fongibles JNF ; et en reliant le jeton non fongible à un identifiant, permettant en une seule transaction de générer plusieurs jetons non fongibles JNF se distinguant les uns des autres par leur identifiant uniforme de ressource URid.

La norme retenue dans la cadre de la présente description de l’invention est la norme ERC-1155.

A noter que dans un autre mode de mise en œuvre du procédé, la transmission (respectivement la réception) du fichier numérique dF et des métadonnées associées par le système de service dorsal BEserv (respectivement par le service de chaine de blocs BC Ethereum) durant l’étape de transmission E6 (respectivement durant l’étape de réception E6’) se produit après l’étape de réception E11’ par le service de chaine de blocs BC Ethereum du contrat intelligent CI signé. Pour cette possibilité de mise en œuvre, suite à l’étape de stockage E5, le système de service dorsal BEserv envoie une requête de mise à disposition qui va être reçue puis traitée comme une transaction par un nœud distant Polygon Np. Suite à la validation du bloc généré par le nœud distant Polygon Np et contenant la transaction par les autres nœuds de Polygon, le service de chaine de blocs BC Ethereum va générer le contrat intelligent CI qui va être transmis au système de service dorsal BEserv afin que ce dernier l’envoi à l’utilisateur Usr pour signature, selon l’étape de transmission E7. Le procédé de mise à disposition se déroule ensuite de la même manière que décrite précédemment, avec la succession des étapes E7’, E8, E8’, E9, E10, E10’. Par contre, au cours de l’étape de transmission E11, le système de service dorsal BEserv transmet au nœud distant Polygon Np, en plus du contrat intelligent CI signé, le fichier numérique dF et ses métadonnées qui vont être stockés par le nœud distant Polygon Np. Si la transaction, correspondant dans cette possibilité de réalisation à la requête de mise à disposition, a été validée par le service de chaine de blocs BC Polygon, alors le contrat intelligent CI signé récupère dans le nœud distant Polygon Np le fichier numérique dF représentatif de l’évènement et ses métadonnées Mdata associées, puis lance l’exécution dans le service de chaine de blocs BC Ethereum la procédure de génération et de mise à disposition de jeton non fongible JNF.

Suite à la génération d’au moins un jeton non fongible JNF et de son identifiant uniforme de ressource URid associé, le service de chaine de blocs BC Ethereum va transmettre au nœud distant Polygon Np : ledit au moins un jeton non fongible JNF et son identifiant uniforme de ressource URid associé, ainsi qu’une confirmation Conf de la mise à disposition dudit au moins un jeton non fongible JNF. Le nœud distant Polygon Np va alors transmettre au système de service dorsal BEserv lors d’une étape de transmission E12 : ledit au moins un jeton non fongible JNF et son identifiant uniforme de ressource URid associé, ainsi que la confirmation Conf.

Le système de service dorsal BEserv accuse ensuite réception, lors d’une étape de réception E12’ dudit au moins un jeton non fongible JNF et de son identifiant uniforme de ressource URid associé, ainsi que de la confirmation Conf. Puis au cours d’une étape de stockage E13, le système de service dorsal BEserv va stocker dans le portefeuille électronique W de l’utilisateur Usr ledit au moins un jeton non fongible JNF et son identifiant uniforme de ressource URid associé.

Ainsi, l’espace de stockage de données Esp1 de l’utilisateur Usr peut contenir un ou plusieurs jetons non fongibles JNF avec chacun leur identifiant uniforme de ressource URid associé, et des versions dégradées lowdF toutes générées à partir d’un fichier numérique dF représentatif d’un évènement différent. Il n’y a pas de corrélation entre le nombre de versions dégradées lowdF et le nombre de jetons non fongibles JNF et/ou le nombre d’identifiants uniformes de ressource URid présents dans l’espace de stockage de données Esp1, dans la mesure où un fichier numérique dF représentatif d’un évènement peut faire l’objet de plusieurs jetons non fongibles JNF (dans le cadre d’un tirage limité). En référence à la , il est supposé que l’utilisateurs possède dans son portefeuille électronique W n jetons non fongibles (JNF1, JNF2… JNFn) chacun associé à un identifiant uniforme de ressource (URid1, URid2…URidn), chacun des jetons non fongibles JNF correspondant à un tirage unique fait à partir de n fichiers numériques dF représentatifs chacun d’un évènement différent.

Dans un autre mode de réalisation du procédé de mise à disposition pour lequel le terminal mobile MD serait connecter directement au nœud distant Polygon Np et/ou au service de chaine de blocs BC Ethereum, le nœud distant Polygon Np et/ou le service de chaine de blocs BC Ethereum enverrait directement sur le terminal mobile MD au moins un jeton non fongible JNF et son identifiant uniforme de ressource associé URid, ledit au moins un jeton non fongible JNF et son identifiant uniforme de ressource URid.

Suite à l’étape de stockage E13, le système de service dorsal BEserv envoie au terminal mobile MD lors d’une étape de transmission E14 la confirmation Conf de la génération des jetons non fongibles JNF à partir du fichier numérique dF représentatif de l’évènement, et de leur mise à disposition sur la plateforme numérique. Le terminal mobile MD reçoit la confirmation Conf lors de l’étape de réception E14’.

Dans le mode de réalisation décrit, le système de service dorsal BEserv envoie au terminal mobile MD lors d’une étape de transmission E15 la version dégradée lowdF du fichier numérique dF représentatif de l’évènement venant de faire l’objet de la mise à disposition de jeton non fongible JNF, que le terminal mobile MD va réceptionner durant une étape de réception E15’.

La version dégradée lowdF est ensuite stockée et mise à disposition dans la mémoire de stockage du terminal mobile MD de l’utilisateur Usr, qui peut ensuite l’utiliser par exemple en la diffusant sur Internet afin que des internautes soient informés de l’existence du ou des jeton(s) non fongible(s) JNF en lien cette version dégradée lowdF, qui est une copie de moins bonne qualité de l’objet numérique / l’évènement contenu dans le(s)dit(s) jeton(s) non fongible(s). Les étapes de transmission E15 et de réception E15’peuvent éventuellement ne pas être définies et implémentées dans le procédé de mise à disposition, le procédé de mise à disposition passant alors directement de l’étape de transmission/réception (E14, E14’) à l’étape d’effacement E16.

Suite à l’étape de réception E15’, l’application mobile dédiée App efface le fichier numérique dF représentatif de l’évènement de la mémoire vive du terminal mobile MD lors d’une étape d’effacement E16, rendant impossible toute réexploitation du fichier numérique dF représentatif de l’évènement, qui était éphémère, pour la mise à disposition d’un ou plusieurs nouveaux jetons non fongibles JNF, assurant l’extrême rareté du ou des jetons non fongibles JNF issus de l’unique mise à disposition rendue possible par le procédé de mise à disposition.

Une fois terminé, le procédé de mise à disposition d’un ou plusieurs jeton(s) non fongible(s), selon le mode de réalisation détaillé ici, l’utilisateur Usr peut le(s) consulter et le(s) gérer depuis le portefeuille numérique W se trouvant dans son profil utilisateur lorsqu’il se connecte à la plateforme numérique à partir de l’application mobile dédiée MD installée sur son téléphone mobile MD. Dans le cas de réalisation où le terminal mobile MD est directement relié au service de chaine de blocs BC, la consultation et la manipulation de jeton non fongible JNF se font depuis le terminal mobile MD.

Parmi les possibilités de gestion de jeton non fongible JNF proposées par le procédé de mise à disposition, le transfert d’un jeton non fongible JNF d’un utilisateur vers un autre. Soit deux utilisateurs Usr1 et Usr2, Esp1 et Esp2 leur espace de stockage de données respectifs dans la base de données dataB, et W1 et W2 leurs portefeuilles électroniques contenus respectivement dans Esp1 et Esp2. Avec le jeton non fongible JNF est également transféré l’identifiant uniforme de ressource URid associé.

Le transfert d’un jeton non fongible NJF et de son identifiant uniforme de ressource URid se trouvant dans le portefeuille électronique W1 vers le portefeuille électronique W2 est assuré par le service de système dorsale BEserv et comprend deux étapes : une étape de récupération dans le portefeuille électronique W1 se trouvant dans l’espace de stockage de données Esp1 de l’utilisateur Usr1 du jeton non fongible JNF et de l’identifiant uniforme de ressource URid; une étape de stockage du jeton non fongible JNF identifiant uniforme de ressource URid dans le portefeuille électronique W2 dans l’espace de stockage de données Esp2 dédié au second utilisateur Usr2. Finalement, en lien avec ce jeton non fongible JNF, il ne reste dans l’espace de stockage de données Esp1 de l’utilisateur Usr1 que la version dégradée lowdF.

Plusieurs possibilités de réalisations sont possibles pour le transfert. Par exemple : une simple option de transfert accessible depuis le profil de l’utilisateur qui permet à l’utilisateur Usr1 de choisir le destinataire du jeton non fongible JNF, ne faisant alors intervenir que le système de service dorsal BEserv comme décrit ci-avant. Le transfert peut aussi faire l’objet d’une transaction de jeton non fongible JNF entre l’utilisateur Usr1 et Usr2, auquel cas l’intervention du service de chaine de blocs BC Ethereum est envisageable pour l’établissement d’un contrat intelligent, différent du contrat intelligent CI jusqu’ici mentionné, servant d’accord de transfert entre les deux utilisateurs Usr1 et Us2.

Le système de service dorsal BEserv sert à nouveau d’intermédiaire, cette fois entre les terminaux mobiles MD1 et MD2 de chaque utilisateur Usr1 et Usr2 et le service de chaine de blocs BC Ethereum à la fois : pour l’envoi de la requête de transfert du jeton non fongible terminaux mobiles MD1 et MD2 vers le service de chaine de blocs BC Ethereum ; le transfert du contrat intelligent en lien avec l’acte de transfert du service de chaine de blocs BC Ethereum vers les terminaux mobiles MD1 et MD2, et réciproquement avec l’envoi de ce contrat intelligent signé par les deux utilisateurs Usr1 et Us2 de leurs terminaux mobiles respectifs MD1 et MD2 vers le service de chaine de bloc BC Ethereum.

Suite à la réception du contrat intelligent signé par les deux utilisateurs Usr1 et Usr2, le service de chaine de blocs BC envoie une réponse au système de service dorsal pour qu’il exécute la procédure de transfert du jeton non fongible JNF du portefeuille électronique W1 vers le portefeuille électronique W2. Le transfert du jeton non fongible JNF peut aussi faire l’objet d’une transaction électronique de paiement. Comme expliqué antérieurement, dans le cas où la norme ERC-1155 est considérée, un seul contrat intelligent peut être établi pour le transfert du jeton non fongible et d’une somme en crypto-monnaie, deux contrats intelligents différents autrement pour chaque type d’échange si une autre norme est considérée. Le transfert de la somme en crypto-monnaie se fait après réception du contrat intelligent de transfert signé par les deux utilisateurs par le service de chaine de blocs BC Ethereum, simultanément à celui d’un jeton non fongible JNF. Le service de chaine de blocs BC Ethereum envoie une réponse au système de service dorsal BEserv qui va alors débiter la somme en crypto-monnaie du portefeuille électronique W1 de l’utilisateur Usr1 pour créditer de cette somme le portefeuille électronique W2 de l’utilisateur Usr2.

Comme l’exemple de service de chaine de blocs BC considéré est Ethereum, la crypto-monnaie échangée est en Ether. Selon les fonctionnalités de réalisation envisagées pour la plateforme numérique, soit l’utilisateur Usr doit alimenter son portefeuille électronique W en Ether ; soit il lui est possible de l’alimenter avec une monnaie fiat, dans ce cas, le système de service dorsal BEserv sous-jacent à la plateforme numérique doit intégrer une solution de paiement / de conversion d’une monnaie fait vers l’Ether, par exemple Stripe^TM.

Claims (15)

1. Procédé de mise à disposition d’un jeton non fongible (JNF) au moyen d’un terminal mobile (MD) connecté à un service de chaîne de blocs (BC), le procédé de mise à disposition étant exécuté par le terminal mobile (MD) et comprenant les étapes suivantes :
   - une étape de capture en direct d’un évènement (E0) par un utilisateur (Usr) du terminal mobile (MD), au moyen d’un périphérique dudit terminal mobile (MD) connecté, de façon à générer et stocker un fichier numérique (dF) représentatif de l’évènement dans une partie dédiée d’une mémoire vive du terminal mobile (MD) ;
   - une étape de transmission (E4) du fichier numérique (dF) représentatif de l’évènement, et de métadonnées (Mdata) qui lui sont associées, du terminal mobile (MD) vers le service de chaine de blocs (BC) ;
   - une étape de réception (E14’), en provenance du service de chaine de blocs (BC), d’une confirmation (Conf) d’une mise à disposition pour la mise à disposition de l’utilisateur (Usr) : d’au moins un jeton non fongible (JNF) généré à partir du fichier numérique (dF) représentatif de l’évènement, ainsi que d’au moins un identifiant uniforme de ressource (URid) associés à l’au moins jeton non fongible (JNF) ;
   - une étape d’effacement (E16) lors de laquelle, suite à l’étape de réception (E14’) de la confirmation (Conf) de la mise à disposition dudit au moins un jeton non fongible (JNF), le terminal mobile (MD) procède à l’effacement du fichier numérique (dF) représentatif de l’évènement stocké dans la partie dédiée de la mémoire vive du terminal mobile (MD).
2. Procédé de mise à disposition selon la revendication 1, comprenant en outre, entre l’étape de transmission (E4) du fichier numérique (dF) représentatif de l’évènement vers le service de chaîne de blocs (BC) et l’étape de réception (E14’) de la confirmation (Conf) de la mise à disposition d’au moins un jeton non fongible (JNF) à partir dudit fichier numérique (dF) représentatif de l’évènement :
   - une étape de réception (E8’) en provenance du service de chaine de blocs (BC) d’un contrat intelligent (CI) demandant à l’utilisateur (Usr) du terminal mobile (MD) une autorisation pour la génération et la mise à disposition par le service de chaîne de blocs (BC) d’au moins un jeton non fongible(JNF) généré à partir du fichier numérique (dF) représentatif de l’évènement ;
   - une étape de signature (E9) du contrat intelligent (CI) par l’utilisateur (Usr) du terminal mobile (MD), pour validation dudit contrat intelligent (CI);
   - une étape de transmission (E10) du contrat intelligent (CI) signé vers le service de chaine de blocs (BC).
3. Procédé de mise à disposition selon la revendication 1 ou 2, dans lequel ledit procédé de mise à disposition est lancé puis exécuté au moyen d’une fonction (Func) implémentée dans une application mobile dédiée (App), ladite application mobile dédiée (App) étant accessible à partir du terminal mobile (MD) ; et contrôlant le périphérique et la partie dédié de la mémoire vive du terminal mobile (MD) qui est allouée à ladite application mobile dédiée (App), ainsi que les opérations de capture en direct d’un évènement (E0) et les opérations de lecture, d’écriture et d’effacement de ladite partie dédiée de la mémoire vive du terminal mobile (MD).
4. Procédé de mise à disposition selon la revendication 3, pour lequel le terminal mobile (MD) connecté communique et interagit avec le service de chaine de blocs (BC) au moyen de l’application mobile dédiée (App) et au travers d’interfaces graphiques.
5. Procédé de mise à disposition selon l’une quelconque des revendications précédentes, dans lequel l’étape de capture en direct d’un évènement (E0) est réalisée au moyen d’au moins un des périphériques suivants du terminal mobile (MD) :
   - une caméra, de sorte que le fichier numérique (dF) représentatif de l’évènement est un fichier image ;
   - un microphone, de sorte que le fichier numérique (dF) représentatif de l’évènement est un fichier audio ;
   - une caméra associée à un microphone, de sorte que le fichier numérique (dF) représentatif de l’évènement est un fichier vidéo.
6. Procédé de mise à disposition selon l’une quelconque des revendications précédentes, dans lequel, entre l’étape de capture en direct d’un évènement (E0) et l’étape de transmission (E4) du fichier numérique représentatif de l’évènement à destination du service de chaîne de blocs, se déroule une étape intermédiaire de modification (E1) mettant en œuvre une modification dudit fichier numérique (dF) représentatif de l’évènement.
7. Procédé de mise à disposition selon les revendications 5 et 6, pour lequel, lorsque le fichier numérique (dF) représentatif de l’évènement est un fichier image ou vidéo, l’étape intermédiaire de modification (E1) dudit fichier numérique (dF) représentatif de l’évènement comprend l’ajout d’au moins un effet visuel, comme par exemple un filtre ou un émoticône.
8. Procédé de mise à disposition selon l’une quelconque des revendications précédentes, pour lequel les métadonnées (Mdata) associées au fichier numérique (dF) représentatif de l’évènement contiennent des informations relatives à l’évènement, ledit procédé de mise à disposition comprenant une étape de saisie d’informations (E2) mettant en œuvre une saisie par l’utilisateur desdites informations sur le terminal mobile (MD).
9. Procédé de mise à disposition selon l’une quelconque des revendications 1 à 8, pour lequel les métadonnées (Mdata) associées au fichier numérique (dF) représentatif de l’évènement comprennent une requête de mise à disposition par le service de chaine de blocs d’un seul et unique jeton non fongible à partir du fichier numérique (dF) représentatif de l’évènement.
10. Procédé de mise à disposition selon l’une quelconque des revendications 1 à 8, pour lequel, avant l’étape de transmission (E4) du fichier numérique (dF) représentatif de l’évènement au service de chaine de blocs (BC), ledit procédé de mise à disposition comprend une étape de saisie d’un nombre (E3) mettant en œuvre une saisie d’un nombre de jeton non fongible (JNF) à mettre à disposition par le service de chaine de blocs (BC) à partir du fichier numérique (dF) représentatif de l’évènement, ce dit nombre de jeton non fongible (JNF) saisi faisant ensuite partie intégrante des métadonnées (Mdata) transmises par le terminal mobile (MD) au service de chine de blocs (BC) en association avec le fichier numérique (dF) représentatif de l’évènement.
11. Procédé de mise à disposition d’un jeton non fongible (JNF) au moyen d’un terminal mobile (MD) connecté à un service de chaîne de blocs (BC), le procédé de mise à disposition étant exécuté par un système de service dorsal (BEserv) et comprenant les étapes suivantes :
    - une étape de réception (E4’) d’un fichier numérique (dF) représentatif d’un évènement, qui a été capturé en direct, et de ses métadonnées (Mdata) associées, en provenance d’un terminal mobile connecté (MD) ;
    - une étape de transmission (E6) du fichier numérique (dF) représentatif d’un évènement et des métadonnées (Mdata) associées vers le service de chaîne de blocs (BC) ;
    - une étape de réception (E12’), en provenance du service de chaine de blocs (BC), de l’au moins un jeton non fongible (JNF), et au moins un identifiant uniforme de ressource (URid) associés, et une confirmation (Conf) de la mise à disposition desdits au moins un jeton non fongible (JNF), et au moins un identifiant uniforme de ressources (URid) ;
    - une étape de stockage (E13) de l’au moins un jeton non fongible (JNF) dans une base de données (dataB) administrée par le système de service dorsal (BEserv), et dudit au moins un identifiant uniforme de ressource associés (URid) ;
    - une étape de transmission (E14) vers le terminal mobile (MD) de la confirmation (Conf) de la mise à disposition dudit au moins un jeton non fongible (JNF), et dudit au moins un identifiant uniforme de ressource (URid) associés.
12. Procédé de disposition selon la revendication 11, comprenant en outre une phase de gestion d’un contrat intelligent (CI) comprenant les étapes suivantes :
    - une étape de réception (E7’), en provenance du service de chaine de blocs (BC), du contrat intelligent (CI) pour une demande d’autorisation de la génération et de la mise à disposition d’au moins un jeton non fongible (JNF) à partir du fichier numérique (dF) représentatif de l’évènement par le service de chaine de blocs (BC) ;
    - une étape de transmission (E8) du contrat intelligent (CI) vers le terminal mobile (MD) ; - une étape de réception (E10’), en provenance du terminal mobile (ND), du contrat intelligent (CI) signé ;
    - une étape de transmission (E11) du contrat intelligent (CI) signé vers le service de chaine de blocs (BC).
13. Procédé de mise à disposition selon la revendication 11 ou 12, pour lequel, suite à l’étape de réception (E4’) du fichier numérique (dF) représentatif de l’évènement et de ses métadonnées (Mdata) associées, se déroule une étape de génération et stockage (E5) dans la base de donnée d’une version dégradée (lowdF) dudit fichier numérique (dF) représentatif de l’évènement, cette version dégradée (lowdF) étant soit dans un format de qualité inférieure à celui du fichier numérique représentatif de l’évènement, soit dans un format identique mais pour lequel des caractéristiques ont été dégradées, par exemple, pour un fichier image source haute résolution au format JPEG, la génération d’une version dégradée au format GIF, ou la génération d’une version dégradée au format JPEG basse résolution.
14. Procédé de mise à disposition selon la revendication 13, pour lequel ledit procédé de mise à disposition comprend, suite à l’étape de transmission (E14) de la confirmation (Conf) de mise à disposition d’au moins un jeton non fongible (JNF), une étape de transmission (E15) par le système de service dorsal (BEserv) vers le terminal mobile (MD) de la version dégradée (lowdF) du fichier numérique (dF) représentatif de l’évènement et ayant fait l’objet d’une mise à disposition de jeton non fongible (JNF).
15. Procédé de mise à disposition selon la revendication 13 ou 14, pour lequel, suite à au stockage dans la base de données (dataB) dans un espace de stockage de données (Esp1) dédié à un utilisateur d’un premier terminal mobile d’un jeton non fongible (JNF), et d’un identifiant uniforme de ressource (URid) et d’une version dégradée (lowDF) du fichier numérique (dF) représentatif de l’évènement associés, le transfert dudit jeton non fongible vers un second espace de stockage de données (Esp2) dédié à un second utilisateur d’un deuxième terminal mobile est exécuté par le système de service dorsal (BEserv) dans la base de données (dataB) selon les étapes suivantes : - une étape de récupération dans l’espace de stockage de données (Esp1) dédié à un utilisateur d’un premier terminal mobile du jeton non fongible (JNF), et de son identifiant uniforme de ressource (URid) associés, seul étant conservé dans ledit espace de stockage de données (Esp1) dédié à un utilisateur d’un premier terminal mobile la version dégradée (lowdF) du fichier numérique (dF) représentatif de l’évènement ;
    - une étape de stockage du jeton non fongible (JNF), et de l’identifiant uniforme de ressource (URid) associés, dans l’espace de stockage de données (Esp2)dédié au second utilisateur d’un deuxième terminal mobile.