WO2022266372A1

WO2022266372A1 - Method and system for creating, tracking and changing the status of a fractional non-fungible token

Info

Publication number: WO2022266372A1
Application number: PCT/US2022/033866
Authority: WO
Inventors: Jean-Christophe Hamann
Original assignee: Ipside Innovation Inc.
Priority date: 2021-06-16
Filing date: 2022-06-16
Publication date: 2022-12-22
Also published as: KR20230031983A

Abstract

The invention pertains to a method and a system for creating, tracking and changing the status of Fractional Non-Fungible Tokens (FNFTs). The invention is more particularly adapted to FNFTs associated with assets, whether in the digital or in the real world, the status of which may change over time or upon the occurrence of an event. The invention is also particularly useful for adding a brand or a trademark on an virtual item in a metaworld

Description

Title: Method and system for creating, tracking and changing the status of a Fractional Non-Fungible Token.

Technical Field

[0001] This application claims priority of US provisional application # 63/211027 fled on June 16, 2021, US provisional application # 63/295090 filed on December 30, 2021 and US provi sional application # 63/298903 filed on January 12, 2022, the contents or which are hereby introduced by reference in their entirety.

[0002] The invention pertains to a method and a system for creating, tracking and changing the status of Fractional Non-Fungible Tokens (FNFTs).

[0003] The invention is more particularly adapted to FNFTs associated with assets, whether in the digital or in the real world, the status of which may change over time or upon the occur rence of an event.

[0004] A non-limiting example of such an asset is an industrial property title like a patent or a pa tent application: a patent application may turn into a patent upon grant, or being rejected, and may further lapse or being revoked.

[0005] Another application of the instant invention pertains to an asset that gain value through a guarantee of origin or a certification by an authority, more particularly when this asset is intangible or transitory. An example of such an asset is a unit of energy supply, like a kWh of thus qualified green electricity. Another example of such an asset is a virtual asset in an information technology system known as a meta-universe. An example of such an asset is a virtual object that becomes more valuable when it bears a specific brand.

[0006] Still another application of the instant invention pertains to an asset that requires or that takes advantage of an escrow or a trusted third party for a transfer to occur.

Background

[0007] A blockchain is a database or ledger that is updated and shared across many computers, or nodes, in a network, allowing peer to peer transactions through a cryptocurrency, an imple menting a consensus mechanism. Well known but non limiting examples of decentralized blockchains are Bitcoin® or Ethereum®.

[0008] The blockchain technology offers a tamper proof electronic ledger that records transactions between users, said transactions consisting in an exchange of an amount of cryptocurrency between the involved users’ wallets, and requiring to be authenticated by a process called a consensus mechanism.

[0009] There are several blockchains available on the market some of them like Bitcoin® or

Ethereum® are decentralized or public, some others are centralized and privately owned and managed.

[0010] The principle of chaining blocks corresponding to transactions after authentication by the consensus mechanism is a principle shared among blockchains, whether the consensus mechanism requires mining such as in a “proof or work” or another mechanism. [0011] From an overall point of view the consensus mechanism requests that some tasks be per formed by one or more certifiers to authenticate a transaction or a block of transactions within the blockchain, and the certifier is rewarded. Therefore, each transaction is subject to a fee, or at least a computing time, the fee corresponding to the reward of the certifier, as a for instance, the certifier is a miner on Bitcoin®.

[0012] Some blockchains allow the implementation of smart contracts. A smart contract is a piece of code, a program, that resides at a specific address on the blockchain and that performs specific functions according to specific data at the request of a user. Smart contracts are compositional, meaning that a smart contract can call the execution of another smart con tract.

[0013] Smart contracts allow to create platforms or “Dapps” that may interact with a decentralized blockchain, and take advantage of the safety and traceability of the ledger.

[0014] Those platforms may create and trade assets, the trade in the digital world of the platform being performed with tokens. Therefore tokens are crypto assets that may be the digital counterpart of an asset in the real world.

[0015] The use of tokens in a platform that is built on a blockchain, assures the authenticity of the crypto asset by eradicating the possibility of counterfeiting and double spending.

[0016] Tokens may be fungible, meaning that they can be exchanged blindly for one another, that they are interchangeable and divisible and that they actually behave like a fiat currency. A cryptocurrency is fungible as well, however while the cryptocurrency like Bitcoin® or Ether® are native assets in the blockchain, tokens are units of value in a platform or pro ject developed on top of an existing blockchain network.

[0017] They can also be non-fungible, meaning that they cannot be split or exactly exchanged for other non-fungible tokens of the same type.

[0018] A Non Fungible Token (NFT) is unique and cannot be exchanged blindly for one another. ANFT is a token having a unique identification number or identification string.

[0019] Using the unique identification of a NFT, said NFT can be connected to an asset, such as an artwork, a collectible or a memorabilia, in the real world, the platform implementing such a NFT will, as a for instance, comprise a list associating each unique identification with a specific asset from the real world. Thus, a NFT transports such a real-world asset or an avatar of this real-world asset in the digital world, enabling transactions over this asset. The ownership of such a NFT bears the characteristics of private property.

[0020] “Dapp” is the acronym of Decentralized application, it is an application built on a decen tralized network, i.e. a blockchain, that combines a smart contract and a frontend user in terface.

[0021] Fractional Non Fungible Tokens (FNFT), bear the characteristics of NFTs with said NFTs being fractioned in shares, like the capital of a company may be fractioned in stocks.

[0022] Each FNFT is a NFT having a unique identifier, it is non fungible, and it cannot be further divided. The only reason why it is called fractional is because, ultimately, each fractional NFT of a given asset, pertains to this very asset. Therefore, as a for instance, if this asset is destroyed the whole set of FNFTs related to it will be destroyed, or "burnt", at once.

[0023] The advantage of the digital world is that any NFT, related to any real-world asset, may be split in a plurality of Fractional Non Fungible Tokens whatever the nature of the underly ing asset in the real-world or in a meta-universe. Therefore, such Fractional Non Fungible Tokens (FNFT) may be considered as shares of ownership of an underlying asset.

[0024] As another example, a batch of something may become distinguishable from other similar or even identical goods when it bears a specific brand or trademark. This is thru in the real- world as well as in meta-universes.

[0025] In such a meta-universe a virtual item such as pair of shoes, a car or a tee-shirt, all virtual, may bear a specific brand. In such a virtual world where such an item may be produced or created by infinite numbers, part of them may bear a specific brand that make them special, and potentially more desirable and more expensive.

[0026] In the virtual world there is no physical way to detect an origin, therefore the guarantee of origin, as a trademark can be, shall be brought by a trusted authority.

[0027] The NFT approach making each of t’ose items a unique (virtual) thing is not really satis factory and does not reflect correctly what happens in real life where a batch of items is ac tually affected a guarantee of origin, simply because it bears the bmd, even if each item of this batch, like a tee shirt, is not uniquely identified as such.

[0028] In a platform built on top of a blockchain, any action relies on a transaction that is recorded in the tamper-proof ledger. Therefore, in order to perform a specific task, a smart contract may trigger a plurality of transactions each of them having to go through the consensus mechanism.

[0029] And each triggering of the consensus mechanism triggers the issuance of an award that is won by a certifier.

[0030] Therefore, each transaction requires a fee to be paid, even if this transaction does not trans fer or create any value. As a consequence, smart contracts requiring a lot of transactions may generate an amount of fees that is higher than the value conveyed through the execu tion of the contract.

[0031] As a for instance, splitting a NFT in multiple FNFTs (that may be e.g. 100,000 FNFTs) and affecting the property of each FNFT to a different user will require hundreds of thousands of transactions that may lead to very high fees.

[0032] Furthermore, for the safety of the blockchain, a smart contract cannot be deleted and the interaction with a smart contract, i.e. the transactions involved by the execution of the smart contract, are irreversible.

[0033] Therefore, when FNFT are connected to an underlying asset that may change status, the ownership of the FNFTs being distributed over a wide range of user, such a change of sta tus will, once again, require a lot of transaction and therefore lead to high cost from a certi fying fees standpoint.

Disclosure of the invention

[0034] The invention aims at solving the deficiencies of the prior art and to this end pertains to a method for creating, tracking and changing the status of a FNFT implementing a system comprising a blockchain network connecting nodes and comprising a ledger recording a transaction between nodes; a platform built on top of the blockchain; a plurality of computers connected to the platform and to the blockchain network and com prising an Authority, a User and a Trustee; the platform comprising Utility Tokens and Transformation Tokens and Recording Tokens and a program known as a smart-contract adapted to trigger operations involving one or more nodes of the blockchain when a transaction involving tokens between computers con nected the platform is performed; comprising the steps of :

- User triggering a transaction to acquire a number N of FNFT from Trustee by sending a request to the Trustee;

- upon receiving the request Trustee initiating a transaction with Authority sending to Au thority N utility tokens and receiving a first Transformation Token and one Record Token from Authority;

- identifying each of the N utility tokens as well as the Transformation Token and the Re cording Token with a unique identifier;

- registering in a database of the platform the unique identifiers of the N utility tokens in association with the identifiers of the first Transformation Token and the Recording To ken;

- upon payment of Trustee by User delivering the Recording Token to User;

- initiating a transaction between User and Authority, User giving the Recording Token and Authority delivering the N identified utility tokens to User;

- destroying the Recording Token once the transaction is complete.

[0035] Thus, utility tokens are transformed into FNFT upon association with a transformation to ken. This transformation token is delivered by Trustee and remain in custody of the Trus tee. User may trade its FNFT on the platform, those FNFTs remain tightly connected with the Transformation Token, the latter being associated with an asset more particularly an as set in the real world, the existence of which is guaranteed by Trustee, as well as the actual property of the real asset that shall belong to User.

[0036] This initial association turns the Utility Tokens circulating in the platform into FNFTs. Fur ther operations may change the status of those FNFTs, or may add further FNFTs to the same first Transformation Token.

[0037] The method of the invention may be implemented according to the specific embodiments and variants disclosed hereafter that may be considered individually or in any technically operating combination.

[0038] Thus, the method of the invention may further comprise the steps of:

- User triggering a transaction with Trustee to acquire M additional FNFT associated with the same first Transformation Token by sending a request to Trustee;

- upon receipt of the request Trustee initiating a transaction with Authority sending to Au thority M utility tokens together with the first Transformation Token, Authority giving back the first Transformation Token and a new Recording Token;

- identifying each of the M Utility Tokens as well as the Recording Token with a unique identifier; - registering in a database of the platform the unique identifiers of the M Utility Tokens in association with the identifiers of the first Transformation Token and the new Recording Token;

- upon payment of Trustee by User delivering the new Recording Token to User;

- initiating a transaction between User and Authority, User giving the new Recording To ken to Authority and Authority delivering the identified M Utility Tokens to User;

- destroying the new Recording Token once the transaction is complete.

[0039] Accordingly, the number of Utility Tokens turned into FNFTs by their association with the first Transformation Token is increased.

[0040] The method may further comprise the steps of:

- Trustee initiating a transaction with Authority sending Authority the first Transformation Token without any Utility Token;

- Authority sending back the first Transformation Token and a second Transformation To ken with a unique identifier;

- registering in the database of the platform the unique identifier of the second Transfor mation Token.

[0041] This way, the addition of a further Transformation Token on top of a previous Transfor mation Token may be used to reflect the change of status of the asset underlying the FNFT, by changing the status of all the concerned FNFTs at once.

[0042] To summarize:

- when Trustee initiates a transaction with Authority by sending Authority Utility Tokens only, Authority sends back a Transformation Token and register in a database of the plat form the association of said Utility Tokens with this Transformation Token;

- when Trustee initiates a transaction with Authority by sending Utility Tokens and a Trans formation Token, Authority sends back the Transformation Token and attaches the further Utility Tokens to this same Transformation Token in the database,

- when Trustee initiates a transaction with Authority by sending a Transformation Token alone, Authority sends back a Transformation Token “going on top” of the initially sent Transformation Token and is associated in the database to the latter, thus automatically af fecting the Utility Tokens hat were associated with the initially sent Transformation Token.

[0043] The method of the invention may further comprise:

- Trustee initiating a transaction with Authority sending Authority the Second Transfor mation Token without any Utility Token;

- Authority sending back the Second Transformation Token and a Third Transformation To ken with a unique identifier;

- registering in the database of the platform the unique identifier of the Third Transfor mation Token with the identifier of the Second Transformation Token with the identifier of the First Transformation Token, wherein the last Transformation Token piles up on the preceding ones, and a last Transformation Token is on top of the pile and the First Trans formation Token is on the bottom of the pile, each Transformation Token having a level in the pile increasing form level 0 at the bottom of the pile to the top level on top of the pile. [0044] Once the first association of Utility Tokens with a First Transformation Token is per formed, further Transformation Tokens may pile up on it, thus making a stack of Transfor mation Tokens, each Transformation Token reflecting a change of status of all the affected FNFTs. The Transformation Token on the top of the stack thus represents the current status of the asset.

[0045] The method of the invention may further comprise the steps of:

- Trustee initiating a transaction with Authority sending Authority a set of N Transfor mation Tokens, with N>2, each of the Transformation Tokens of the set having consecu tive levels in the pile from a lower level, numbered LI with LI higher or equal to 0 to a higher level L2 with L2=L1+(N-1) ;

- Authority sending back (N-l) Transformation Tokens of a specific type called Killer To ken, each Killer Token being affected to one Transformation Token from level L2 to level LO+1;

- registering in the database of the platform the association of each Killer Token with each Transformation Token.

[0046] This way the Transformation Tokens of the stack may be annihilated in their effect so as to reflect a status evolution, by annihilating them with a thus defined Killer Token on a “last in - first out” scheme.

[0047] Therefore, initiating a transaction with Authority with more than one successive Transfor mation Tokens without a Utility Token results in annihilating the tokens over the first of the stack.

[0048] According to an embodiment wherein all the Transformation Token except the first Trans formation Token are associated with a Killer Token in the database the method further comprises the steps of:

Trustee initiating a transaction with Authority, sending Authority the First Transfor mation Token with a Killer Token;

Upon receipt Authority registers in the database the association of the Killer Token to the First Transformation Token.

[0049] Advantageously, the method implements a system further comprising an Escrow and Ser vice Tokens, comprising the steps of:

- Authority creating a Service Token with a unique identifier at the request of Escrow;

- registering in the database of the platform the Service Token in association with the up permost Transformation Token on the stack and a definite number of Utility Tokens.

[0050] Advantageously, Escrow act as an escrow for any transaction of a Utility Token that is as sociated with a Service Token.

[0051] According to an embodiment, the creation of the Service Token by Authority is based on a mockup Service Token prepared by Escrow and sent to Authority.

[0052] In a specific embodiment the system comprises a meta-universe comprising N virtual items of a kind and wherein the First Transformation Token associates the kind to the N Utility Tokens and the Second Transformation Token associates a brand to the N Utility Tokens. [0053] This embodiment allows to associate a brand to number of items that is not defined in ad- vance. Brief description of the drawings

[0054] The invention is described below in its preferred embodiments, that are in no way limiting, with reference to figures 1 to 9, wherein:

[0055] [Fig 1] is a static scheme of the system of the invention;

[0056] [Fig 2] illustrates the transaction to turn a utility token into a FNFT according to the method of the invention;

[0057] [Fig 3] shows schematically how, starting from figure 2, further FNFTs may be added to the same asset;

[0058] [Fig 4] shows schematically how a change of status of the underlying asset may be re flected in the FNFTs;

[0059] [Fig 5] illustrates how a set of FNFTs may be reversed from a status to a previous status with the use of a Killer Token;

[0060] [Fig 6] shows how a FNFT may be annihilated without being destroyed using Killer To kens;

[0061] [Fig. 7] illustrates the evolution of the status of an asset underlying a FNFT and how those changes are reflected on the platform using Transformation Tokens;

[0062] [Fig 8] shows an exemplary embodiment for the association of a Service Token to a FNFT before the FNFT changes hands;

[0063] [Fig 9] shows anther embodiment where a Service Token is associated to a FNFT at the same tome of a transfer.

Modes of carrying the invention

[0064] Figure 1, according to an exemplary embodiment the system of the invention comprises a blockchain network (100) to which all the players implementing the method of the inven tion are connected. The blockchain is preferably but not exclusively a decentralized block- chain.

[0065] The blockchain technology is known form the prior art and comprises a ledger that is up dated and shared across many computers, or nodes, in a network, allowing peer to peer transactions implementing a cryptocurrency, such transaction being validated and written in the tamperproof ledger in response to a consensus mechanism.

[0066] The players involved in the method of the invention (101, 102, 103, 111, 112) are all con nected to the blockchain network as nodes of this network.

[0067] The system further comprises a platform (150) that is built on top of the blockchain that can interact, meaning trigger, a set of defined transactions between nodes of the blockchain network using smart contracts being programs residing at an address on the blockchain net work (100).

[0068] Smart contracts are associated with tokens that may circulate and be traded on the platform (150).

[0069] The platform is a network to which the players may access. From an overall point of view the platform is a WAN, but depending on the application, the platform may be a LAN, a MAN or a cloud network. [0070] All the players (101, 102, 103, 111, 112) are also connected to the platform (150).

[0071] The platform comprises Utility Tokens (151) , Transformation Tokens (152) and Recording Tokens (154). In a specific embodiment the platform may also comprise Service Tokens (153). Each type of token is associated with specific rules of transaction and associations defined by specific functions that may be used in each token for executing a smart contract.

[0072] Utility tokens (151) are subject to be traded between players on the platform while Trans formation Tokens (152) and Service Tokens (154) are work tokens that may only be used in a limited number of transactions among specific players,

[0073] Recording Tokens (154) have a short life on the platform and are actually used as vouch ers.

[0074] As an exemplary embodiment, players involved in the implementation of the method of the invention comprise ADMIN (101) playing the role of Authority, one or more EMIITTERs (102) playing the role of Trustee. And Users (111, 112).

[0075] In a specific embodiment the system further comprises one or more SERVICE PROVID ERS (103) playing the role of Escrow.

[0076] Players (101, 102, 103, 111, 112) may be directly connected to the platform (150) or through the internet (190).

[0077] The platform comprises a database (160) comprising tables associating together the differ ent tokens. As shown later, an array of Utility Tokens (151) may thus be associated with a First Transformation Token (152), said First Transformation Token may be associated with further Transformation Tokens piled up on one another in a stack, and a Service Token may be associated with a Transformation Token of the stack and a subarray of Utility Tokens.

[0078] All these associations are recorded in the database (160). Seen from the Users (111, 112) the platform is a marketplace where they can trade their FNFTs, FNFTs being Utility To kens that have been associated with at least one Transformation Token in the database (160). Because such Utility Tokens are uniquely identified they remain associated with the same Transformation Token in the database even when they change hand.

[0079] In other words, the system and the method thereof may be called “token centric” and are allowing to split a NFT in a number of FNFTs that is not known in advance and that can change over time. Most of system of the prior art are “asset centric” and while they allow to split a NFT in FNFT, the split is performed once in a defined and fix number of FNFTs.

[0080] Figure 2, according to an exemplary embodiment a User (111) may gain ownership over a bunch FNFTs by sending a request (211) to EMITTER (102), the Trustee.

[0081] EMITTER has a stock of utility tokens (151) in a wallet (251).

[0082] The request (211) stipulates that User (111) wants to acquire a given quantity of FNFTs, e.g. 10.

[0083] The request (211) may comprise an offer, as a for instance, a price, and therefore may com prise a negotiation process between User (111) and EMITTER (102).

[0084] The ways utility tokens are initially created on the platform depends on the application. In a preferred embodiment the Utility Tokens, and actually any token on the platform, is mint by ADMIN (101) either in batches subjected to an ICO (Initial Coin Offering), or automati cally to reflect the production of a resource. [0085] EMITTERS are Trustees who administer the resource on the platform. In order to build a stock of utility token an EMITTER will need to acquire them from ADMIN through a transaction. Such a transaction may be a purchase or any other formal transaction depend ing on the application. Whatever the kind of transaction, given the fact that Utility Tokens become FNFT once associated with a Transformation Token, in this embodiment, only EMITTER may acquire Utility Tokens, i.e. bare or blank Utility Tokens.

[0086] Users may only acquire and trade FNFTs, not bare or blank Utility Tokens.

[0087] In a specific embodiment when the platform comprises multiples EMITTERS (102) bare or blank Utility Tokens, that are not associated with a Transformation Token, may be traded among EMITTERS either on the same marketplace as FNFTs, but preferably on a dedi cated marketplace of the platform.

[0088] Once User (111) and EMITTER (102) reach an agreement on the request e.g. through an acknowledgment of receipt from EMITTER, EMITTER initiates a transaction (221) with ADMIN (101) where EMITTER sends to ADMIN a number of utility tokens (151) corre sponding to the agreement with User (111).

[0089] According one embodiment, a Utility Token may be uniquely identified upon its initial emission by AMDIN. According to another embodiment each Utility Token is uniquely identified upon is acquisition by EMITTER from ADMIN. According to a third and pre ferred embodiment Utility Tokens are uniquely identified once a transaction (221) with EMITTER sending Utility Tokens to ADMIN is triggered.

[0090] According to the latter, once receiving the Utility Tokens ADMIN will attribute each Util ity Token (151) a unique identification, e.g. number 1 to 10, generate a Transformation To ken (152) also with a unique identifier A1 and a Recording Token which is a voucher, also with a unique identification X. ADMIN also records in the database (191) the association of the Transformation Token A1 with Utility Tokens 1 to 10 and the Recording Token X.

[0091] The Transformation Token A1 remains in the custody of EMITTER. Depending on the ap plication, if this Transformation Token A1 is associated in the real world with a specific identifiable asset, such as a patent application or a brand, EMITTER will record this asso ciation in its own database (260). EMITTER does not need to identify all the Utility To kens connected to this asset, since those are already connected with the Transformation To ken A1 in the platform database (160).

[0092] This also gives a guarantee of origin, and, as a for instance, if the Transformation Token associates a specific brand to a specific virtual item, or set of items, other item pretending to bear the same brand but that are not registered as such are not legit.

[0093] Through a transaction (222), EMITTER will deliver the voucher or Recording Token X (154) to User (111) as a for instance in exchange of a payment in cryptocurrency.

[0094] Once User (111) got this voucher (154) it will initiate a transaction (223) with ADMIN (101) exchanging the voucher for the Utility Tokens numbered 1 to 10 which are now in User’s wallet as FNFTs. The transaction is actually completed when the voucher (154) re turns to ADMIN. In a preferred embodiment the voucher (154) is then burnt.

[0095] Whatever the further transactions on the platform, where, for example, User (111) sells part of its FNFTs to another User, only the Utility Tokens will actually change hand, the Trans formation Token A1 remains in the custody of EMITTER certifying the connection of this Transformation Token to a specific asset and the unique number of each Utility Token re mains associated with transformation Token A1 in the platform database (160).

[0096] ADMIN (101) is an Authority and the only player on the platform that can mint and bum tokens. As shown later, only Recording Token used as a voucher may be burnt. All the other tokens can only be annihilated in their effect but not destroyed.

[0097] Figure 3, in some applications User may need to further increase the number of FNFTs as sociated with the same asset.

[0098] As a for instance the asset may be a patent application owned by User and the FNFTs re flect the amount of spendings by the User for prosecuting its application.

[0099] In such an example EMITTER is a law firm or a patent agent in charge of prosecuting the patent application. According to this example each time User pays EMITTER for a specific service in the patent application prosecution User earns FNFTs that it can further trade on the marketplace in order to finance the prosecution costs.

[0100] Therefore, the prosecution spendings increasing over time e.g. each time the law firm re sponds to a rejection from the patent office, the number of FNFTs earned by User also in crease but the underlying asset, i.e. the patent application, is still the same.

[0101] According to this example, the patent application is associated to the uniquely identified Transformation Token A1 in the database (260) of the EMITTER.

[0102] Adding further Utility Tokens to the same Transformation Token follows a method similar to the initial association of Utility Tokens to the Transformation Token.

[0103] Thus User (111) sends a request (311) to EMITTER (102) requesting that e.g. 5 additional FNFTs be added. As before, depending on the application, the request (311) may comprise an offer and initiate a negotiation mechanism.

[0104] Upon agreement EMITTER (102) initiates a transaction (321) with ADMIN (101), this time EMITTER sends to ADMIN 5 utility tokens (151) from its wallet (251) along with the Transformation Token A1 to which these utility tokens shall be related.

[0105] Upon receipt ADMIN (101) sends back the Transformation Token (152) with unique iden tifier A1 to EMITTER, along with a voucher (154) with a unique identifier Y, attaches a unique identifier 25 to 29 to each of the 5 utility tokens and updates the database (160) to attach the 5 Utility Tokens to Transformation Token with a unique identification Al, as well as uniquely identified voucher Y.

[0106] Through atransaction (322) User (111) receives the voucher (154) with unique identifier Y from EMITTER and, by way of a transaction (323) User (111) exchanges the voucher (154) with ADMIN (101) for the 5 Utility Tokens now identified 25 to 29 and associated with the uniquely defined Transformation Token Al.

[0107] The voucher (154) is burnt, and User (111) may trade these new FNFTs on the market place. Once again, the Transformation Token remains in the custody of EMIITTER, the new FNFTs are connected to the same asset through the EMITTER database (260).

[0108] In some applications, the asset underlying the FNFTs may change status over time or upon the occurrence of specific events taking place in the real world. As a Trustee administering the Utility Tokens and FNFTs, EMITTER shall take action to reflect those changes on the FNFTs.

[0109] To this end, taking the example where the underlying asset is a patent application, at one point the patent is granted. Therefore, the underlying asset is no more a patent application but a patent.

[0110] For this change to be reflected on the FNFTs, EMITTER (102) initiates a transaction (421) with ADMIN (101) by sending the Transformation Token associated with the asset in EMITTER’ s database (260).

[0111] In return, ADMIN sends back the Transformation Token with unique identification A1 along with an additional Transformation Token with unique identifier B7 and records this new Transformation Token on top of the other in the platform database (160). Therefore, Transformation Token identified as B7 in this example affects all the Utility Tokens al ready affected by Transformation Token identified as Al.

[0112] EMITTER update its data base associating the new status e.g. “patent granted” to this Transformation Token B7 in its database (260).

[0113] Any further change of status is performed the same way initiating the transaction (421) with the Transformation Token on top of the pile in the platform database (160).

[0114] As a for instance if the status of the underlying assets further changes from “granted” to e.g. “under litigation” EMITER will send the Transformation Token on top of the stack, i.e. B7 and ADMIN will send it back with a new Transformation Token uniquely identified that will be recorded on top of the stack in the platform database (160). Therefore, change of status always affect the Transformation Token on top of the stack.

[0115] All of the Transformation Tokens remain in the custody of EMITTER,

[0116] Figure 5, starting from an initial situation (500) where 3 Transformation Tokens (152) identified Al. B7 and C9 are stacked over an array of Utility Tokens, each Transformation Token corresponding to a status change of the FNFTs or of the underlying asset, one or more of said Transformation Token may be annihilated, thus reverting the FNFT to the sta tus corresponding to the higher Transformation Token in the stack that is not annihilated.

[0117] To this end, EMITTER (102) initiates a transaction with ADMIN (101) by sending it an array of successive Transformation Tokens. When N such Transformation Tokens are sent to ADMIN, ADMIN sends back N-l specific Transformation Tokens (552) called Killer Tokens, ADMN associates the Killer Tokens with the Transformation Tokens starting from the top of the stack.

[0118] In the example of figure 5, EMITTER (102) sends 2 Transformation Tokens (152) identi fied B7 and C9 being on top of B7 according to the initial situation (500) in the platform database. ADMIN further associates the Killer Token (552) with the Transformation Token on top of the stack, identified as C9, which annihilates the corresponding status and revert to the status of Transformation Token B7, as shown in the new situation (501).

[0119] Therefore, as a rule, when EMITTER initiates a transaction with ADMIN by sending N

Transformation Tokens, each being in the stack on one another staring from level L to level L+N, L+N being the level on top of the stack, ADMIN sends back N-l Killer Tokens and associates these Killer Tokens to the (N-l) Transformation Tokens from level L+N to level L+l included. Thus, the status of the FNFT after this update reverts to the status of the Transformation Token on level L.

[0120] In this embodiment Killer Tokens do not have a unique identifier.

[0121] Using the mechanism of Figure 5, all of the Transformation Tokens of the stack except the First Transformation Token may be annihilated, each by a Killer Token.

[0122] The First Transformation Token is special since this first Transformation Token turns Util ity Tokens into FNFTs.

[0123] Figure 6, starting from the initial situation (600) EMITTER (102) initiates a transaction

(621) with ADMIN (101) by sending the First Transformation Token (152) here identified as A1 with a Killer Token (552).

[0124] Upon receipt ADMIN sends back a Killer Token and associates a Killer Token to the First Transformation Token leading to the new situation (601).

[0125] Depending on application the associated Utility Tokens may lose their value and be further burnt, or they can keep a certain value and be kept as such.

[0126] The method of the invention may be used in many situations where the right of a User to initially own a FNFT shall be checked and proven by a third party and when the FNFT shall bear a guarantee of origin. In the above examples EMITTER, as a Trustee, certifies the origin of the asset and the right of the user to own it.

[0127] The triggering of the various transactions may be the result of a human decision but may also be fully automated or be triggered by machines upon given situations.

[0128] As a for instance, it is common for an electricity supplier to promote the installation of so lar panels by buying back the electricity of consumer installing solar panels on their roof.

[0129] The solar panels set on the roof are producing electricity, which is injected on the grid through an inverter, where it is mixed with the electricity coming from other sources.

[0130] A meter measures the quantity of electricity thus injected on the grid by the installation and in a basic scheme, that may be more complex such as involving bonuses, the injected elec tricity is deducted from the electricity bill of the user, who can then amortize its investment in the installation.

[0131] In a such a scheme, the consumer does not directly consume the electricity it produces, and is not limited by the power and the energy it actually produces by the solar panels.

[0132] Such a system however presents some drawbacks in the sense that the electricity produced by the roof top solar panels is injected in the grid on the low voltage network and cannot be conveyed to a long distance without significant losses.

[0133] On the other hand, huge solar farms, like covering square miles may produce a huge quan tity of electricity with a far better yield and capacity factor, that can also be transformed to high voltage and conveyed to long distances.

[0134] However, those huge solar farms require huge investments.

[0135] The system and the method of the invention may be used to allow individuals to invest in such huge solar farms and still take advantage of the consumption reduction as if solar pan els were on their roof.

[0136] This allows individuals to fund such a huge installation, and allows individuals that are, for instance, living in a condominium to also invest in solar electricity while they do not own a roof.

[0137] In such an embodiment, the energy output of the solar farm may be metered, and such pro duction automatically translated in Utility Tokens on the platform. In a variant the electric ity supplier may own a plurality of solar farms and the totality of the solar production is translated in Utility Tokens.

[0138] When User Bob that invested e.g. 0.01% of the whole solar production system consumes N.kWh in a day or a week or a month, N tokens are also generated and sent to its wallet.

[0139] Automatically, at the end of a given period of time, as a for instance, every day, a transac tion is triggered between Bob and the EMITTER controlled by the electricity supplier that holds the Utility Tokens corresponding to the production of the solar farm(s) on the same day.

[0140] As an exemplary and non-limiting embodiment, Bob will trigger the transaction by sending its own electric consumption tokens of the day to EMITTER. During the first transaction of this type, EMITTER will trigger a transaction with ADMIN sending to ADMIN a num ber M of Utility Tokens where M may be CxNxO.01% where C is the ratio of solar produc tion in that day to the total electric production, N is the electrical consumption of Bob in the same day and 0.01% the share of investment of Bob in the solar farm. Those Utility To kens become FNFTs when associated with a Transformation Token, this Transformation Token is directly connected to Bob’s and its height of investment in the project.

[0141] Further consumptions may be added to the same Transformation Token using the method of the invention.

[0142] Once the whole transaction is completed Bob gets FNFTs that reflects its participation in the development of solar energy and the production of low carbon electricity. For example, Bob may use these FNFTs to offset its electricity bill, or, if such a market exists, may sell these FNFTs to a company wishing to offset its carbon emissions.

[0143] Those FNFTs may have a limited lifetime, e.g. one year, therefore, after one year a Killer Token will be generated according to the method of the invention and applied to the Trans formation Tokens connected to Bob, thus annihilating the Transformation Token and all the associated FNFTs at once.

[0144] Another example of application of the system and the method of the invention, is to attach a warranty of origin, that is to say a brand, om virtual items in a meta-universe.

[0145] Such a virtual item may be a virtual outfit or a virtual object like a car, but may also be a service provided in the meta-universe. Any of these virtual items may be connected to a Utility Token in the system of the invention. In essence there is no difference between a Utility Token for an outfit or an object or a service. The difference will be made by the EMITTER or Trustee and the association of a specific Transformation Token.

[0146] Thus, a Transformation Token my both identify a bare or blank Utility Token as a specific item bearing a specific brand,

[0147] Alternatively, a First Transformation Token at the bottom of the stack, may identify or as sociate a bunch of Utility Tokens to a specific kind of items in the meta-universe, as a for instance each of the Utility Tokens affected by this First Transformation Token are identi fied as a batch of virtual tee shirts. [0148] On top of the First Transformation Token a Second Transformation Token may associate the underlying batch to a specific brand,

[0149] Accordingly, an indefinite and potentially infinite number of blank Utility Token may be mint and transformed to the appropriate item with appropriate brand on the fly when re quired.

[0150] As another example of application of the method and the system of the invention, figure 7 gives an exemplary evolution of the combination of tokens making the FNFT of a patent application.

[0151] Going back to figure 1, according to a specific embodiment the system of the invention comprises a SERVICE PROVIDER (103) among the players. A SERVICE PROVIDER plays the role of Escrow in the method of the invention and actually acts as an escrow in a transaction between two Users (111, 112) and involving a FNFT.

[0152] The SERVICE PROVIDER allows a User, further called a Primo User, to propose a more sophisticated offer to whom purchases its FNFTs.

[0153] A Primo User is the User that own the FNFT at the beginning through a transaction with EMITTER.

[0154] As a consequence, User of figures 2 and 3 is a Primo User, The Primo User is usually the owner of the FNFT underlying asset.

[0155] As an example, such an improved offer provides dividends to the buyer just like a stock may provide dividends to its owner.

[0156] Figure 8, according to an exemplary embodiment User (111) who is a Primo User, wishes to offer for sale part of its FNFTs, as a for instance 3 FNFTs among the 15 FNFTs it holds, with a service proposal such as the payment of royalties of x% of the initial purchase price to the holder of the FNFT.

[0157] The Utility Tokens (151) corresponding to the FNFTs of User (111) are each uniquely iden tified with a label ranging from 1 to 10 and from 25 to 29.

[0158] Each of these utility tokens is associated in the platform database (160) with 2 Transfor mation Tokens (152) each uniquely identified with a A1 label for the First Transformation Token and a B7 label for the Second Transformation Token on top of the First Transfor mation Token in the stack of Transformation Tokens.

[0159] According to a preferred embodiment, Service Tokens may only be associated with FNFTs that are still in the Primo User wallet.

[0160] According to this exemplary embodiment, User (111) send a request (811) to SERVICE PROVIDER (103). The request comprises a description of the service, the underlying as set the number of FNFTs involved and the EMITTER that User is using as a trustee for ad ministering the FNFTs,

[0161] There may be a negotiation. Once User and SERVICE PROVIDER reach an agreement a transaction (821) is initiated between User and SERVICE PROVIDER. As a for instance such a transaction comprises the FNFT (Utility Tokens) that User wishes to associate with the service, a fee for the development of the service and a deposit.

[0162] Upon receipt, SERVICE PROVIDER sends a request to the EMITTER, EMITTER ( 102) checks that User (111) is the right owner of the underlying asset. [0163] EMITTER and SERVICE PROVIDER initiate a series of transactions. According to an ex emplary embodiment, SERVICE PROVIDER sends a deposit to EMITTER. Upon receipt of the deposit EMITTER sends to SERVICE PROVIDER a Transformation Token corre sponding to the underlying asset.

[0164] According to a preferred embodiment a service can only be attached to the most current Transformation Token, i.e. the Transformation Token that is on top of the stack and that is not annihilated by a Killer Token.

[0165] Upon receipt of the Transformation Token, here the Transformation Token labeled B7 which is the most current, SERVICE PROVIDER prepares a Service Token mockup (853) and initiates a transaction (823) with ADMIN sending ADMIN (101) the Transformation Token (152) , the utility tokens that are concerned by the service, and a Service Token mockup.

[0166] Upon receipt ADMIN checks the conformity of the mockup, issues the Service Token

(153) with a unique identification al, associates, in the platform database (160) ,the Ser vice Token alwith the Transformation Token and the 3 Utility Tokens, here labeled 27 to 29.

[0167] ADMIN sends the uniquely identified Service Token (153) to SERVICE PROVIDER (103) along with a Recording Token (154) or voucher uniquely labeled Z, and the 3 Utility To kens.

[0168] The Service Token remains in the custody of the SERVICE PROVIDER.

[0169] SERVICE PROVIDER sends the voucher (154) to EMITTER. EMITTER sends the voucher to ADMIN, and ADMIN returns the Transformation Token to EMIITER, upon re ceipt, EMITTER sends back the deposit to SERVICE PROVIDER who sends back the Utility Tokens to User (111) along with its deposit. ADMIN bums the voucher (154).

[0170] Now each of the Utility Tokens (151) labelled 27 to 29 is associated with the Service To ken al, and the holder of such a token may request the royalties associated with the ser vice.

[0171] In the preceding embodiment, the Service Token is attached to the Utility Token before any transaction takes place on these tokens on the marketplace.

[0172] Alternatively, a Service Token may be attached to a Utility Token only when said Utility Token changes hands between Primo User and another User.

[0173] Figure 9, in a simplified scheme, once Primo User (111) and User (112) agree on the price and condition of service through a negotiation (911), Primo User (111) initiates a transac tion (821) with SERVICE PROVIDER sending the utility tokens User (112) committed to purchase.

[0174] SERVICE PROVIDER (103) prepares a Service Token mockup (853) that is sent to AD MIN (101) along with the selected utility token(s).

[0175] Upon receipt, ADMIN create the Service Token with a unique identifier according to the mockup and associates said Service Token the utility token and the corresponding Trans formation Token that is on top of the stack.

[0176] ADMIN sends back the Service Token (153) that remains in custody of SERVICE PRO VIDER, along with a voucher (154). [0177] Upon receipt of the payment of the price by User (112) SERVICE PROVIDER, sends him back the voucher.

[0178] SERVICE PROVIDER transfers the amount received from User (112) to Primo User (111) minus a service fee, and User (112) sends the voucher to ADMIN in exchange o the utility token.

[0179] Service Token remains attached to a specific FNFT and a Transformation Token. It remains enforceable until the Transformation Token it is attached with is annihilated by a Killer To ken.

[0180] A Service Token is a commitment from a Primo User to any User holding the FNFT. It may also comprise a commitment from any holder of the FNFT to pay a service fee to the SERVICE PROVIDER and /or to the Primo User, as a for instance in a licensing of the un derlying asset.

[0181] SERVICE PROVIDER acts as an escrow and collects the counterparts given by the Primo User to User or paid by User to Primo User depending on the application, before distrib uting them to their legit recipients.

[0182] The system and the method of the invention offers several advantages, Through the impli cation of SERVICE PROVIDER and EMITTER acting as trusted third parties, it brings confidence about the existence, the actual status and the actual ownership of the underlying asset backing up the FNFT in the real world, This is particularly useful for FNFTs backed up with IP right like patents, patent applications or trademarks.

[0183] The change of status and services are reflected on the FNFTs, always by adding tokens on top on one another, changing the status of all the concerned FNFTs at once, even if such FNFTs are distributed over a large number of Users. FNFT are mint but never burnt, only temporarily tokens behaving like vouchers may be burnt. It follows a complete traceability

Claims

[Claim 1] A method for creating, tracking and changing the status of a FNFT implementing a system comprising a blockchain network connecting nodes and comprising a ledger recording a transaction between nodes;

- a platform built on top of the blockchain;

- a plurality of computers connected to the platform and to the blockchain network and comprising an Authority, a User and a Trustee;

- the platform comprising Utility Tokens and Transformation Tokens and Recording Tokens and a program known as a smart-contract adapted to trigger operations involving one or more nodes of the blockchain when a transaction involving tokens between computers connected the platform is performed; comprising the steps of :

- User triggering a transaction to acquire a number N of FNFTs from Trustee by sending a request to Trustee;

- upon receiving the request, Trustee initiating a transaction with Authority sending to Authority N Utility Tokens and receiving a First Transformation Token and one Recording Token from Authority;

- identifying each of the N Utility Tokens as well as the First Transformation Token and the Recording Token with a unique identifier;

- registering in a database of the platform the unique identifiers of the N Utility Tokens in association with the identifiers of the First Transformation Token and the Recording Token;

- upon payment of Trustee by User delivering the Recording Token to User;

- destroying the Recording Token once the transaction is complete.

[Claim 2] The method of claim 1 further comprising the steps of:

- User triggering a transaction with Trustee to acquire M additional FNFTs associated with the same First Transformation Token by sending a request to Trustee;

- upon receipt of the request Trustee initiating a transaction with Authority sending to Authority M Utility Tokens together with the First Transformation Token, Authority giving back the First Transformation Token an a new Recording Token;

- identifying each of the M Utility Tokens as well as the new Recording Token each with a unique identifier;

- registering in a database of the platform the unique identifiers of the M Utility Tokens in association with the identifiers of the First Transformation Token and the new Recording Token;

- upon payment of Trustee by User delivering the new Recording Token to User;

- initiating a transaction between User and Authority, User giving the new Recording Token and Authority delivering the M identified Utility Tokens to User;

- destroying the new Recording Token once the transaction is complete.

[Claim 3] The method of claim 1 or claim 2, further comprising the steps of:

- Authority sending back the First Transformation Token and a Second Transformation Token with a unique identifier;

- registering in the database of the platform the unique identifier of the Second Transformation Token in association with the identifier of the First Transformation Token.

[Claim 4] The method of claim 3, further comprising the steps of:

- Trustee initiating a transaction with Authority sending Authority the Second Transformation Token without any utility token;

- Authority sending back the second Transformation Token and a Third Transformation Token with a unique identifier;

- registering in the database of the platform the unique identifier of the Third Transformation Token in association with the identifier of the Second Transformation Token and in association with the identifier of the First Transformation Token, and making a stack wherein the last Transformation Token piles up on the preceding ones, and a last Transformation Token is on top of the stack and the First Transformation Token is on the bottom of the stack, each Transformation Token having a level in the stack increasing form level 0 at the bottom of the stack to the top level on top of the stack.

[Claim 5] The method of claim 4, further comprising the steps of:

- Trustee initiating a transaction with Authority sending Authority a set of N Transformation Tokens, with N>2, each of the Transformation Tokens of the set having consecutive levels in the stack from a lower level, numbered LI with LI higher or equal to 0 to a higher level L2 with L2=L1+(N-1) ;

- Authority sending back (N-l) Transformation Tokens of a specific type called Killer Token, each Killer Token being affected to one Transformation Token from level L2 to level LO+1;

[Claim 6] The method of claim 5, wherein all the Transformation Token except the First

Transformation Token are associated with a Killer Token in the database further comprising the steps of:

Trustee initiating a transaction with Authority, sending Authority the First Transformation Token with a Killer Token; Upon receipt Authority registers in the database the association of the Killer Token to the First Transformation Token.

[Claim 7] The method of claim 4, implementing a system further comprising an Escrow and Service Tokens, comprising the steps of:

- registering in the database of the platform the Service Token in association with the uppermost Transformation Token on the stack and a definite number of Utility Tokens.

[Claim 8] The method of claim 7, wherein Escrow act as an escrow for any transaction of a Utility Token that is associated with a Service Token.

[Claim 9] The method of claim 7, wherein the creation of the Service Token by Authority is based on a mockup Service Token prepared by Escrow and sent to Authority.

[Claim 10] The method of claim 3, wherein the system comprises a meta-universe comprising N virtual items of a kind and wherein the First Transformation Token associates the kind to the N Utility Tokens and the Second Transformation Token associates a brand to the N Utility Tokens.