TITRE : Procédé de gestion de droits associés à un objet.

Domaine Technique de l'invention

L’invention concerne un procédé de gestion de droits associés à un objet. L’invention concerne encore l’utilisation d’un tel objet dans un procédé de gestion des droits attachés à cet objet. L’invention concerne aussi un dispositif de gestion de droits associés à un tel objet. L’invention concerne aussi un produit programme de gestion de droits associés à un tel objet. L’invention concerne aussi un support d’enregistrement de données dédié à la mise en oeuvre du procédé de gestion de droits associés à un tel objet. L’invention concerne enfin un signal d'un support de données, portant un tel produit programme d'ordinateur

Etat de la technique antérieure

Dans certains domaines, notamment dans le domaine des produits de luxe, il existe un besoin de tenir un registre des produits manufacturés et vendus. Il peut aussi exister un intérêt de suivre la chaîne de propriété tout au long de la vie des produits. Or, un tel suivi ne peut être garanti une fois le produit mis sur le marché. Un registre ne peut être tenu que si les différents propriétaires du produit se font connaître auprès du teneur du registre, notamment auprès de la manufacture tenant le registre.

Présentation de l'invention

Le but de l’invention est de fournir un procédé de gestion de droits associés à un objet remédiant aux inconvénients évoqués ci-dessus et améliorant les procédés de gestion connus de l’art antérieur. En particulier, l’invention propose un procédé de gestion de droits associés à un objet qui permette de garantir une traçabilité et une authenticité tout en permettant de gérer en outre des droits associés à des produits et/ou services annexes à l’objet.

Résumé de l'invention

Selon l’invention, un procédé permet de gérer des droits associés à un objet, tel qu’une pièce d’horlogerie ou de joaillerie. Le procédé comprend les étapes suivantes :

- création d’un premier jeton numérique associé à un premier droit, notamment au droit de propriété, sur l’objet, le premier jeton numérique étant stocké et authentifié grâce à un premier protocole de chaîne de blocs,

- création d’un deuxième jeton numérique, notamment un jeton numérique non fongible, associé à un deuxième droit, notamment un droit d’accès à un contenu numérique, en particulier un contenu multimédia, associé à l’objet, le deuxième jeton numérique étant stocké et authentifié grâce à un deuxième protocole de chaîne de blocs,

- création d’un contrat intelligent liant les droits sur les premier et deuxième jetons numériques de sorte que le droit de propriété sur l’un des premier et deuxième jetons numériques ne peut pas être transféré sans le droit de propriété sur l’autre des premier et deuxième jetons numériques.

Le premier protocole de chaîne de blocs et le deuxième protocole de chaîne de blocs sont avantageusement d’un même type ou le premier protocole de chaîne de blocs et le deuxième protocole de chaîne de blocs sont avantageusement un même protocole de chaîne de blocs.

Le contrat intelligent peut impliquer la création, grâce à un protocole de chaîne de blocs, d’un troisième jeton numérique incluant des informations comprenant :

- au moins une information contenue dans le premier jeton numérique, tel que notamment une information de l’objet et/ou un numéro de série de l’objet et/ou un identifiant de la transaction de création du premier jeton numérique et/ou la date d’activation du certificat d’authenticité et/ou la date de la vente du produit et/ou un identifiant du premier jeton numérique, et

- au moins une information contenue dans le deuxième jeton numérique, tel que notamment un identifiant du deuxième jeton numérique.

De préférence, le contrat intelligent est configuré de sorte que le transfert du droit de propriété sur le premier jeton numérique implique le transfert du droit de propriété sur le deuxième jeton numérique et/ou le transfert du droit de propriété sur le troisième jeton numérique, et/ou le transfert du droit de propriété sur le deuxième jeton numérique implique le transfert du droit de propriété sur le premier jeton numérique et/ou le transfert du droit de propriété sur le troisième jeton numérique, et/ou le transfert du droit de propriété sur le troisième jeton numérique implique le transfert du droit de propriété sur le premier jeton numérique et/ou le transfert du droit de propriété sur le deuxième jeton numérique.

Le premier jeton numérique et/ou le deuxième jeton numérique peuvent être associés à des portefeuilles numériques de crypto-actifs, notamment à un même portefeuille numérique de crypto-actifs.

Le portefeuille numérique de crypto-actifs ou l’un des portefeuilles numériques de crypto-actifs peut être associé à :

- une clé publique, ou

- un code associé à la clé publique, la clé publique ou le code étant inscrit sur :

- l’objet, notamment sur un composant d’une pièce d’horlogerie, en particulier sur un barillet ou sur un rochet de barillet d’une pièce d’horlogerie, ou

- sur un support matériel vendu avec l’objet, ou

- dans un document numérique, comme un fichier informatique ou un message, notamment un MMS (de l’anglais Multimedia Messaging Service) ou un SMS (de l’anglais Short Message).

La clé publique ou le code associé à la clé publique peut être inscrit par impression ou par gravure ou par collage d’une étiquette.

Le code associé à la clé publique peut être un code lisible par une machine, comme une étiquette NFC ou comme un code-barres, en particulier comme un code matriciel ou un code QR.

Le portefeuille numérique de crypto-actifs ou l’un des portefeuilles numériques de crypto-actifs peut être associé à :

- une clé privée, ou

- un code associé à la clé privée, la clé privée ou le code associé à la clé privée étant inscrit :

- sur un support matériel annexé à l’objet, notamment sur une carte, sur une étiquette ou sur un document physique, et/ou

- dans un document numérique, comme un fichier informatique ou un message, notamment un MMS ou un SMS.

Le code associé à la clé privée peut être un code lisible par une machine, comme une étiquette NFC ou comme un code-barres, en particulier comme un code matriciel ou un code QR.

L’invention porte aussi sur une utilisation d’un objet ou d’un support matériel annexé à l’objet et/ou d’un accessoire, notamment d’une pièce d’horlogerie, en particulier d’un barillet ou d’un rochet de barillet d’une pièce d’horlogerie comme support d’une clé publique ou d’un code associé à une clé publique d’un portefeuille numérique de crypto-actifs. Selon l’invention, un dispositif, notamment une architecture informatique distribuée, permet de gérer des droits associés à un objet, le dispositif comprenant des éléments matériels et/ou logiciels mettant en oeuvre le procédé défini précédemment, notamment des éléments matériels et/ou logiciels conçus pour mettre en oeuvre le procédé défini précédemment.

Selon l’invention, un dispositif comprend des moyens de mettre en oeuvre des étapes du procédé défini précédemment.

Selon l’invention, un produit programme d’ordinateur comprend des instructions de code de programme enregistrées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé défini précédemment lorsque ledit programme fonctionne sur un ordinateur.

L’invention porte aussi sur un produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support de données lisible par un ordinateur et/ou exécutable par un ordinateur. Le produit programme comprend des instructions qui, lorsque le programme est exécuté par l’ordinateur, conduisent celui-ci à mettre en oeuvre des étapes du procédé défini précédemment.

L’invention porte encore sur un support d’enregistrement de données, lisible par un ordinateur, sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme de mise en oeuvre du procédé défini précédemment.

L’invention porte encore sur un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en oeuvre des étapes du procédé défini précédemment. L’invention porte encore sur un signal d'un support de données, portant le produit programme d'ordinateur défini précédemment.

Présentation des figures

Les objets, caractéristiques et avantages de la présente invention sont exposés en détail dans la description suivante d’un mode de réalisation particulier fait à titre non-limitatif en relation avec les figures jointes.

La figure 1 est une vue d’une pièce d’horlogerie dont les droits sont gérés selon un mode d’exécution du procédé selon l’invention.

Description détaillée

Le mode d’exécution du procédé de gestion décrit par la suite est explicité en application à un objet 1 étant une pièce d’horlogerie 1. Toutefois, ce procédé peut être appliqué à tout type d’objet physique ou immatériel, produit ou service. Il peut notamment aussi être appliqué à une pièce de joaillerie.

L’objet est l’élément principal dont les droits sont gérés selon le procédé. L’objet peut être commercialisé avec un élément annexe ou un élément auxiliaire qui peut aussi être de tout type comme un objet physique ou immatériel, produit ou service.

Dans le mode de réalisation décrit, alors que l’élément principal est la pièce d’horlogerie, l’élément auxiliaire comprend un service d’accès à des données, notamment à des données multimédia pouvant contenir des images, des contenus sonores, des vidéos. Ces données peuvent par exemple retracer l’histoire du projet créatif ayant donné lieu à la mise de l’objet sur le marché. Ces données peuvent par exemple contenir des témoignages des personnes impliquées dans le projet comme le témoignage d’un directeur artistique ou comme le témoignage d’un directeur technique s’adressant directement au propriétaire de la pièce d’horlogerie.

L’élément auxiliaire peut aussi contenir une oeuvre d’art numérique ou physique vendue avec la pièce d’horlogerie et produite par exemple par un artiste ayant collaboré avec la manufacture, en particulier ayant collaboré avec la manufacture dans le processus de création de la pièce d’horlogerie. L’élément auxiliaire peut aussi être constitué par un objet accessoire comme par exemple un écrin pour la pièce d’horlogerie.

Une fois l’élément principal (par exemple, l’objet constitué par la pièce d’horlogerie) et l’élément auxiliaire (par exemple, le service d’accès à des données) produits par la manufacture, un mode d’exécution du procédé objet de l’invention est mis en oeuvre.

Le procédé permet de gérer des droits sur l’élément principal. En particulier, il est possible de gérer le droit de propriété sur l’élément principal. Ce droit de propriété peut être démembré en nue-propriété et usufruit. La gestion de tout autre droit associé à l’élément principal peut être envisagée.

Le procédé permet aussi de gérer des droits sur l’élément auxiliaire. En particulier, il est possible de gérer le droit de propriété sur l’élément auxiliaire. Ce droit de propriété peut être démembré en nue-propriété et usufruit. La gestion de tout autre droit associé à l’élément auxiliaire peut être envisagée. Ces droits sur l’élément auxiliaire peuvent être vus comme des droits associés à l’élément principal, l’élément auxiliaire étant associé à l’élément principal.

L’association entre l’élément auxiliaire et l’élément principal peut être de toute nature comme notamment fonctionnelle, commerciale, conceptuelle, ou artistique. L’association peut en outre être seulement la conséquence de la mise en oeuvre du procédé de gestion des droits.

Dans une première étape du procédé de gestion, on crée ou on frappe (en anglais « to mint ») un premier jeton numérique (en anglais « token ») associé à un premier droit, notamment au droit de propriété, sur la pièce d’horlogerie. Le premier jeton numérique est par exemple du type non- fongible (en anglais « NFT » pour non-fongible token). Le premier jeton numérique est stocké et authentifié grâce à un premier protocole de chaîne de blocs (en anglais « blockchain »). Le premier protocole est par exemple le protocole de la chaîne de blocs AURA.

Dans une deuxième étape du procédé de gestion, on crée ou on frappe un deuxième jeton numérique associé à un deuxième droit, notamment un droit d’accès à un contenu numérique, en particulier un contenu multimédia, associé à la pièce d’horlogerie. Comme vu précédemment, le deuxième droit peut être un droit sur un élément auxiliaire. Le deuxième jeton numérique est par exemple du type non-fongible. Le deuxième jeton numérique est stocké et authentifié grâce à un deuxième protocole de chaîne de blocs. Le deuxième protocole est par exemple le protocole de la chaîne de blocs POLYGON.

Par exemple, le deuxième droit peut être un droit d’accès à un contenu numérique se trouvant sur un site internet qui appartient à la manufacture. Le deuxième droit peut donc être un droit d’usufruit sur le site internet alors que la nue-propriété du site internet demeure détenue par la manufacture.

Le premier protocole de chaîne de blocs et le deuxième protocole de chaîne de blocs peuvent être d’un même type, voire même le premier protocole de chaîne de blocs et le deuxième protocole de chaîne de blocs peuvent être un même protocole de chaîne de blocs. La deuxième étape peut être mise en oeuvre de différentes manières.

Par exemple, dans un premier mode d’exécution, la manufacture déclenche l’opération de création du deuxième jeton numérique dès que la pièce d’horlogerie est terminée ou lors de la vente de la pièce d’horlogerie de la manufacture au premier client ou premier propriétaire.

Par exemple, dans un deuxième mode d’exécution, c’est le premier client ou le premier propriétaire qui déclenche l’opération de création du deuxième jeton numérique après qu’il a pris possession de la pièce d’horlogerie.

Afin de mettre en oeuvre ce deuxième mode d’exécution :

- une clé publique, ou

- un code associé à la clé publique, est inscrit sur la pièce d’horlogerie 1 , notamment sur un composant 2 de la pièce d’horlogerie, en particulier sur un barillet 2 ou sur un rochet 3 de barillet 2 de la pièce d’horlogerie 1 .

Alternativement, la pièce d’horlogerie peut être fournie avec un support matériel comme un document, une étiquette, un certificat, un écrin ou tout accessoire sur lequel est inscrit la clé publique ou le code associé à la clé publique. Alternativement encore, la pièce d’horlogerie peut être fournie avec un document numérique, comme un fichier informatique ou un message, notamment un MMS ou un SMS, contenant la clé publique ou le code associé à la clé publique. Ce document numérique peut être remis ou envoyé lors de l’achat de la pièce d’horlogerie.

En complément, lors de la vente de la pièce d’horlogerie, - une clé privée, ou

- un code associé à la clé privée, peut être fourni avec un support matériel comme un document, une étiquette, un certificat, un écrin ou tout accessoire sur lequel est inscrit la clé privée ou le code associé à la clé privée. Alternativement, la pièce d’horlogerie peut être fournie avec un document numérique, comme un fichier informatique ou un message, notamment un MMS ou un SMS, contenant la clé privée ou le code associé à la clé privée. Ce document numérique peut être remis ou envoyé lors de l’achat de la pièce d’horlogerie. De préférence, la délivrance de la clé privée ou du code associé à la clé privée est sécurisée. Par exemple, lorsque la clé privée ou le code associé à la clé privée est apposé sur un document ou plus généralement sur tout support physique, il est recouvert d’un revêtement le masquant de sorte que seul le premier propriétaire pourra le voir après retrait du revêtement.

L’une et/ou l’autre des clés et/ou l’un et/ou l’autre des codes associés aux clés peuvent être inscrits par impression ou par gravure ou par collage d’une étiquette.

De préférence, l’un et/ou l’autre des codes associés aux clés est un code lisible par radiofréquences ou optiquement par une machine, comme une étiquette NFC (en anglais « near field contact »), un code-barres, en particulier comme un code matriciel ou un code QR.

Ainsi, après l’achat de la pièce d’horlogerie, le premier propriétaire de la pièce d’horlogerie peut en ayant accès à la clé publique et à la clé privée déclencher la création du deuxième jeton numérique. Pour ce faire, il peut se rendre sur un site internet dédié et entrer les clés publique et privée pour lancer la création du deuxième jeton numérique. Dès leur création, les premier et deuxième jetons numériques sont associés à un ou deux portefeuilles numériques de crypto-actifs (en anglais « wallet »). Ils sont dès leur création associés à un portefeuille numérique du premier propriétaire ou transférés d’un portefeuille numérique de la manufacture à un portefeuille numérique du premier propriétaire lors de la vente de la pièce d’horlogerie. Le premier jeton numérique et le deuxième jeton numérique peuvent être associés à des portefeuilles numériques de crypto-actifs différents. Avantageusement, le premier jeton numérique et le deuxième jeton numérique peuvent être associés à un même portefeuille numérique de crypto-actifs.

Les clés publique et privée mentionnées précédemment sont avantageusement les clés publique et privée du portefeuille numérique de crypto-actifs du premier propriétaire et contenant, après vente de la pièce d’horlogerie de la manufacture au premier propriétaire, le premier jeton numérique et le deuxième jeton numérique.

Avantageusement, dans une troisième étape du procédé de gestion, on crée un contrat intelligent (en anglais « smart contract ») liant les droits sur les premier et deuxième jetons numériques de sorte que le droit de propriété sur l’un des premier et deuxième jetons numériques ne peut pas être transféré sans le droit de propriété sur l’autre des premier et deuxième jetons numériques. Autrement dit, les premier et deuxième jetons numériques ne peuvent pas être transférés l’un sans l’autre. De préférence encore, en supposant que les premier et deuxième jetons numériques sont à l’origine associés à un premier portefeuille numérique, ils ne peuvent être transférés qu’ensemble pour être associés à un deuxième portefeuille numérique suite à un transfert.

De préférence, le contrat intelligent implique la création ou la frappe, grâce à un troisième protocole de chaîne de blocs, d’un troisième jeton numérique. Le troisième protocole de chaîne de blocs est de préférence le même protocole que le premier protocole de chaîne de blocs ou que le deuxième protocole de chaîne de blocs

Le troisième jeton numérique contient avantageusement des informations comprenant :

- au moins une information contenue dans le premier jeton numérique, tel que notamment une information de la pièce d’horlogerie et/ou un numéro de série de la pièce d’horlogerie et/ou un identifiant de la transaction de création du premier jeton numérique et/ou la date d’activation du certificat d’authenticité et/ou la date de la vente de la pièce d’horlogerie et/ou un identifiant du premier jeton numérique, et

- au moins une information contenue dans le deuxième jeton numérique, tel que notamment un identifiant du deuxième jeton numérique.

En alternative, le premier jeton numérique et le deuxième jeton numérique (et éventuellement le troisième jeton numérique) peuvent être créés simultanément ou quasi simultanément. Dans un tel cas, le premier jeton numérique peut être créé en incluant une donnée relative au deuxième jeton numérique, de même que le deuxième jeton numérique peut être créé en incluant une donnée relative au premier jeton numérique. Ainsi, les premier et deuxième jetons peuvent être liés dès leur création.

De manière préférée, le contrat intelligent est configuré de sorte que :

- le transfert du droit de propriété sur le premier jeton numérique implique le transfert du droit de propriété sur le deuxième jeton numérique et/ou le transfert du droit de propriété sur le troisième jeton numérique, et/ou

- le transfert du droit de propriété sur le deuxième jeton numérique implique le transfert du droit de propriété sur le premier jeton numérique et/ou le transfert du droit de propriété sur le troisième jeton numérique, et/ou

- le transfert du droit de propriété sur le troisième jeton numérique implique le transfert du droit de propriété sur le premier jeton numérique et/ou le transfert du droit de propriété sur le deuxième jeton numérique.

En pratique, lorsqu’on déclenche le transfert d’un des jetons numériques d’un portefeuille numérique de crypto-actifs à un autre portefeuille numérique de crypto-actifs, on déclenche automatiquement le transfert de l’autre des jetons numériques ou des autres jetons numériques. Avantageusement, dans une application logicielle permettant ce transfert, lorsqu’on ordonne le transfert de l’un des jetons numériques, l’application émet un message alertant des conséquences du transfert sur les autres jetons numériques.

De manière avantageuse encore, le contrat intelligent peut être configuré pour limiter le transfert du ou des jetons numériques, par exemple pour :

- conditionner le transfert du ou des jetons numériques à l’autorisation d’un tiers, tel que par exemple la manufacture,

- limiter la fréquence de transfert du ou des jetons numériques, par exemple limiter le transfert des jetons numériques à un transfert par an,

- interdire le transfert du ou des jetons numériques.

Notamment, l’une ou l’autre de ces limitations peuvent être mises en oeuvre en cas de perte ou de vol de la pièce d’horlogerie.

Dans le cas d’interdiction du transfert du ou des jetons numériques, il peut être prévu que ce soit l’ensemble du portefeuille numérique de cryptoactifs contenant les jetons numériques qui puisse être transféré d’un propriétaire à un autre.

Grâce aux procédés décrits plus haut, il est possible de gérer les droits sur un élément principal tel qu’une pièce d’horlogerie. En particulier, il est possible d’authentifier et de tracer les différentes transactions passées sur les protocoles de chaîne de blocs.

Avantageusement, toutes les transactions sur les protocoles de chaîne de blocs peuvent être sauvegardées par la manufacture. A cette fin notamment, la manufacture peut gérer des noeuds de réseau de l’architecture permettant de réaliser des traitements de constructions des chaînes de blocs impliquées dans le stockage et l’authentification des jetons numériques.

En remarque, le code associé à la clé publique et apposé sur la pièce d’horlogerie elle-même est avantageusement utilisé par le propriétaire pour se connecter à un site internet proposant le contenu numérique déjà évoqué précédemment. Par exemple, une lecture, à l’aide d’un téléphone intelligent (en anglais « smartphone »), du code QR apposé sur la pièce d’horlogerie, permet de connecter automatiquement le téléphone au site internet proposant le contenu.

L’invention porte aussi sur l’utilisation d’un objet et/ou d’un support matériel annexé à l’objet et/ou d’un accessoire, notamment de la pièce d’horlogerie 1 , en particulier du barillet 2 ou du rochet 3 de barillet 2 de la pièce d’horlogerie 1 , comme support de la clé publique ou du code 4 associé à la clé publique du portefeuille numérique de crypto-actifs.

Un mode de réalisation d’un dispositif, notamment d’une architecture informatique distribuée, permet de gérer les droits associés à l’objet. Ce mode de réalisation comprend des éléments matériels et/ou logiciels mettant en oeuvre le procédé décrit précédemment.

Un mode de réalisation d’un produit programme d’ordinateur comprend des instructions de code de programme enregistrées sur un support lisible par ordinateur pour mettre en oeuvre des étapes du procédé décrit précédemment lorsque ledit programme fonctionne sur un ordinateur.

Un exemple de code de produit programme utilisé pour mettre en oeuvre le procédé de gestion décrit est détaillé ci-après. pragma solidity ^A 0.8.0; interface IERC721 Metadata { function name() external view returns (string memory _name); function symbol() external view returns (string memory _symbol); function token URI(uint256 _tokenld) external view returns (string memory);

} interface IERC721 { event Transfer( address indexed _from, address indexed _to, uint256 indexed _tokenld

); event Approval address indexed _owner, address indexed _approved, uint256 indexed _tokenld

); event ApprovalForAII( address indexed _owner, address indexed -Operator, bool _approved

); function balanceOf(address _owner) external view returns (uint256); function ownerOf(uint256 _tokenld) external view returns (address); function safeTransferFrom( address _from, address _to, uint256 _tokenld, bytes calldata data

) external; function safeTransferFrom( address _from, address _to, uint256 _token Id

) external; function transferFrom( address _from, address _to, uint256 _token Id

) external; function approve(address -approved, uint256 _token Id) external; function setApprovalForAII(address -Operator, bool -approved) external; function getApproved(uint256 _tokenld) external view returns (address); function isApprovedForAII(address _owner, address _operator) external view returns (bool);

} interface IERC721 Receiver { function onERC721 Received( address _operator, address _from, uint256 _tokenld, bytes calldata _data

) external returns (bytes4);

} interface ILuxochainNFT { event OwnershipTransferred(address indexed, address indexed); function owner() external view returns (address); function exists(uint256 tokenld) external view returns (bool); function getStorageType() external view returns (uint256); function isLuxochainNFT() external view returns (bool); function transferOwnership(address newlssuer) external; function totalSupply() external view returns (uint256); function count() external view returns (uint256); event TokenFreezed(uint256 tokenld, address unfreezableAddress); event TokenUnfreezed(uint256 tokenld, address newOwner); function safeMint( uint256 tokenld, address to, string calldata tokenMetadataURI

) external; function multipleSafeMint( uint256[] calldata _tokenslds, address _to, string[] calldata _tokenMetadataURIs

) external; function freezeToken(uint256 tokenld, address unfreezeAddress) external; function unfreezeToken(uint256 tokenld, address newOwner) external; function isTokenFreezed(uint256 tokenld) external view returns (bool); function burn(uint256 tokenld) external;

} contract LUXO_BLG_NFT is IERC721, IERC721 Metadata, ILuxochainNFT { bytes4 private constant _INTERFACE_ID_ERC721_METADATA = 0x5b5e139f; bytes4 private constant _INTER FAC E_ID_ERC721 = 0x80ac58cd; bytes4 private constant _l NTER FAC E_ID_ERC 165 = 0x01ffc9a7; uint256 private _totalSupply; uint256 private _maxTotalSupply; uint256 private _count; string private _name; string private _symbol; address private _issuer; mapping(address => mapping(address => bool)) private _operatorApprovals; mapping(uint256 => address) private _tokenApprovals; mapping(uint256 => address) private _owners; mapping(address => uint256) private -balances; mapping(uint256 => string) private _metadataURIs; mapping(uint256 => bool) private _freezed; mapping(uint256 => address) private _unfreezeAddresses; bool private JsFreeMintable; constructor string memory name_, string memory symbol_, bool isFreeMintable_, uint256 maxTotalSupply_

) { _name = name_;

_symbol = symbol_;

JsFreeMintable = isFreeMintable_;

_issuer = msg. sender ;

_maxTotalSupply = maxTotalSupply_;

} function isLuxochainNFT() public view virtual override returns (bool) { return true;

} function getStorageType() public view virtual override returns (uint256)

{ return 1;

} function owner() public view virtual override returns (address) { return -issuer;

} function transferOwnership(address newlssuer) public virtual override { require(msg. sender == -issuer, "Not issuer"); require(newlssuer != address(O), "New issuer is the zero address');

-issuer = newlssuer; emit OwnershipTransferred(msg. sender, newlssuer);

} function supportslnterface(bytes4 interfaceld) public view virtual returns (bool)

{ return interfaced == _INTER FAC E_ID_ERC721 -METADATA 11 interfaced == _INTERFACE_ID_ERC721 11 interfaced == _INTERFACE_ID_ERC 165;

} function balanceOf(address owner) public view virtual override returns (uint256)

{ return -balances] owner];

} function ownerOf(uint256 tokend) public view virtual override returns (address)

{ return _owners[tokend];

} function name() public view virtual override returns (string memory) { return _name;

} function symbol() public view virtual override returns (string memory) { return _symbol;

} function totalSupply() external view override returns (uint256) { return _totalSupply;

} function count() external view override returns (uint256) { return _count;

} function tokenURI(uint256 tokenld) public view virtual override returns (string memory)

{ return _metadataURIs[tokenld];

} function transferFrom( address from, address to, uint256 tokenld

) public virtual override { require(

_isApprovedOrOwner(msg. sender, tokenld),

"Transfer caller is not owner nor approved" );

_transfer(from, to, tokenld); function safeTransferFrom( address from, address to, uint256 tokenld

) public virtual override {

} function safeTransferFrom( address from, address to, uint256 tokenld, bytes memory _data

) public virtual override {

_safeTransfer(from, to, tokenld, _data);

} function _safeTransfer( address from, address to, uint256 tokenld, bytes memory _data

) internal virtual {

_transfer(from, to, tokenld); require(

_checkOnERC721 Received(from, to, tokenld, _data), "Transfer to non ERC721 Receiver implementer" );

} function _transfer( address from, address to, uint256 tokenld

) internal virtual { require(to != address(O), "Transfer to the zero address'); require(!_freezed[tokenld], "Token is freezed"); require(

_isApprovedOrOwner(msg. sender, tokenld),

"Sender cannot transfer token"

);

_balances[from] -= 1;

_balances[to] += 1;

_owners[tokenld] = to;

_approve(address(0), tokenld); emit Transfer(from, to, tokenld);

} function exists(uint256 tokenld) public view virtual override returns (bool)

{ return _owners[tokenld] != address(O);

} function _safeMint( uint256 tokenld, address to, string calldata tokenMetadataURI

) internal virtual {

_owners[tokenld] = to;

_metadataURIs[tokenld] = tokenMetadataURI; emit Transfer(address(O), to, tokenld);

} function safeMint( uint256 tokenld, address to, string calldata tokenMetadataURI

) external override { require( msg. sender ==_issuer // JsFreeMintable,

"Not Issuer nor free mint"

); require(to != address(O), "Mint to the zero address'); require(!exists(tokenld), "Token already minted");

_totalSupply += 1; require(_maxTotalSupply >= _totalSupply, "Max total supply reached");

_count += 1;

_balances[to] += 1;

_safeMint(tokenld, to, tokenMetadataURI);

} function multipleSafeMint( uint256[] calldata tokenslds, address to, stringU calldata token MetadataUR Is

) external override { require( msg. sender ==_issuer H JsFreeMintable,

"Not Issuer nor free mint"

); require( tokenslds.length — token MetadataUR Is. length,

"Different number of tokens and metadata provided"

); require(to != address(O), "Mint to the zero address'); require(

_maxTotalSupply >= _totalSupply + tokenslds.length,

"Max total supply reached"

); for (uint256 i = 0; i < tokenslds.length; i++) { uint256 tokenld = tokenslds[i]; require(!exists(tokenld), "Token already minted");

_safeMint(tokenld, to, tokenMetadataURIs[i]);

}

_count += tokenslds.length;

_totalSupply += tokenslds.length;

_balances[to] += tokenslds.length;

} function freezeToken(uint256 tokenld, address unfreezeAddress) external override

{ require( ZI

_isApprovedOrOwner(msg. sender, tokenld), "Cannot freeze token: permission denied"

); require(unfreezeAddress != address(O), "Invalid unfreeze address");

_freezed[tokenld] = true;

_unfreezeAddresses[tokenld] = unfreezeAddress; emit TokenFreezed(tokenld, unfreezeAddress);

} function unfreezeToken(uint256 tokenld, address newOwner) external override

{ require(

_unfreezeAddresses[tokenld] — msg. sender,

"You're not allowed to unfreeze this token"

); require(newOwner != address(O), "Invalid new owner address"); delete _freezed[tokenld]; delete _unfreezeAddresses[tokenld];

_owners[tokenld] = newOwner; emit TokenUnfreezed(tokenld, newOwner);

} function isTokenFreezed(uint256 tokenld) public view virtual override returns (bool)

{ return _freezed[tokenld]; function burn(uint256 tokenld) external override { require(!_freezed[tokenld], "Token is freezed"); address owner = ownerOf (token Id); require(_isApprovedOrOwner(msg. sender, tokenld), "Permission denied");

_totalSupply -= 1;

_balances[ owner] -= 1; delete _owners[tokenld];

_approve(address(0), tokenld); emit Transfer] owner, address(O), tokenld);

} function isContract(address account) internal view returns (bool) { return account, code, length > 0;

} function _checkOnERC721 Received] address from, address to, uint256 tokenld, bytes memory _data

) private returns (bool) { if (HsContract(to)) return false; try

IERC721 Receiver(to).onERC721 Received] msg. sender, from, tokenld, data

) returns (bytes4 retval) { return retval == IERC721 Receiver.onERC721 Received. selector;

} catch (bytes memory reason) { if (reason. length == 0) { revert("Transfer to non ERC721 Receiver implementer");

} else { assembly { revert(add(32, reason), mload(reason))

}

}

}

} function _isApprovedOrOwner(address spender, uint256 token Id) internal view virtual returns (bool)

{ require(exists(tokenld), "Operator query for nonexistent token"); address owner = ownerOf (token Id); return (spender — owner 11 getApproved(tokenld) — spender 11 isApprovedForAII( owner, spender));

} function _setApprovalForAII( address owner, address operator, bool approved

) internal virtual { require( owner != operator, "Approve to caller");

_operatorApprovals[ owner][operator] = approved; emit ApprovalForAII( owner, operator, approved);

} function _approve(address to, uint256 token Id) internal virtual { _tokenApprovals[tokenld] = to; emit Approval(ownerOf(tokenld), to, token Id);

} function approve(address to, uint256 tokenld) public virtual override { address owner = ownerOf (token Id); require(to != owner, "Approval to current owner"); require( msg. sender == > owner // isApprovedForAII( owner, msg. sender),

"Approve caller is not owner nor approved for all"

);

_approve(to, tokenld);

} function getApproved(uint256 tokenld) public view virtual override returns (address)

{ require(exists(tokenld), "Approved query for nonexistent token"); return _tokenApprovals[tokenld];

} function setApprovalForAII(address operator, bool approved) public virtual override

{

_setApprovalForAII(msg. sender, operator, approved);

} function isApprovedForAII(address owner, address operator) public view virtual override returns (bool)

{ return _operatorApprovals[ owner][operator];

}

}

L’invention porte encore sur un support d’enregistrement de données, lisible par un ordinateur, sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme de mise en oeuvre du procédé décrit précédemment.

L’invention porte encore sur un signal d'un support de données, portant le produit programme d'ordinateur décrit précédemment.