Device for processing non-fungible tokens

Abstract

An electronic device is provided that includes a communications interface, one or more memories, and one or more processors configured to receive, from a user terminal of a user, a lending request for a digital asset corresponding to a first token, and to perform a procedure for generating a second token based on the lending request. The first token is generated based on a first smart contract configured to prove ownership of the digital asset, and first metadata of the first token indicates an owner of the digital asset. The second token is generated based on a second smart contract configured to prove usage rights of the digital asset, and second metadata of the second token indicates a user authorized to use the digital asset. Upon generation of the second token, generation information of the second token indicating a history of lending of the digital asset is recorded in the first metadata of the first token.

Description

Technical Field

[0001] This document relates to non-fungible tokens, and particularly to an apparatus and method for processing non-fungible tokens.

Background Art

[0002] For a product, heritage represents the long tradition and history of the product, and the formation of heritage for a product is utilized as a major marketing strategy to enhance the value of the product.

[0003] In recent years, due to the increasing interest in the Metaverse, that is, the extended virtual world, the interest in digital assets, which are means to express an individual's unique personality within the Metaverse, has also increased. In particular, the interest in non-fungible tokens for proving the origin of such digital assets is also on the rise.

Summary of the Invention

Problems to be Solved by the Invention

[0004] [Technical Problems] At least a part of the content disclosed in this document provides a technique for increasing the value of non-fungible tokens that guarantee digital assets.

[0005] At least a part of the content disclosed in this document provides a technique for representing the usage history of a digital asset by a non-fungible token that guarantees the digital asset.

[0006] At least a part of the content disclosed in this document provides a platform for lending digital assets.

[0007] At least a part of the content disclosed in this document provides a technique for proving the right to use by lending a digital asset.

Means for Solving the Problems

[0008] [Technical solution] According to one aspect of the disclosures herein, an electronic device is provided. The electronic device may include a communication interface for communicating with at least one node of a blockchain network and an external device, one or more memories for storing at least one instruction, and one or more processors communicatively connected to the communication interface and the one or more memories. The one or more processors may be configured to receive a loan request from a user's terminal for a digital asset corresponding to a first token by executing the at least one instruction, and to perform a procedure for generating a second token based on the loan request. The first token is generated based on a first smart contract configured to prove ownership of the digital asset, and the first metadata of the first token may indicate the owner of the digital asset. The second token is generated based on a second smart contract configured to prove the right to use the digital asset, and the second metadata of the second token may indicate the user of the digital asset. Based on the generation of the second token, generation information of the second token indicating the history of the lending of the digital asset may be recorded in the first metadata of the first token.

[0009] In one embodiment, the one or more processors are configured to further receive a usage log from the user terminal of the user indicating the history of how the digital asset has been used, and to perform a recording procedure based on the receipt of the usage log, which records the usage log for the first token in the first metadata of the first token, the recording procedure may include the operation of transmitting a recording request to at least one node of the blockchain network to execute the first smart contract.

[0010] In one embodiment, the second metadata of the second token indicates the loan period of the digital asset, and the one or more processors may be configured to perform the recording procedure of recording the usage log of the first token based on whether the transmission of the recording request is within the loan period.

[0011] In one embodiment, based on the record request, virtual assets corresponding to at least a portion of the virtual assets recorded in the first token may be transmitted to the user's wallet address.

[0012] In one embodiment, the usage log may include at least one of the following: information about the licensee, information about the content on which the digital asset was used, information about the manner in which the digital asset was used, or information about the time of use of the digital asset.

[0013] In one embodiment, the one or more processors are configured to further receive a verification request for the second token from an external terminal distinct from the user terminal, compare the second metadata of the second token with the information recorded in the block corresponding to the second token based on the verification request, and based on the fact that the second metadata of the second token and the information recorded in the block are identical, transmit at least a portion of the first address of the first token, the second address of the second token, the identifier of the second token, the user's signature, or a temporary value to the external terminal, wherein the temporary value may be a value that is arbitrarily changed based on the receipt of the verification request.

[0014] In one embodiment, based on the fact that the second metadata of the second token and the information recorded in the block are identical, information indicating the history of how the digital asset was used may be recorded as the usage log in the first metadata of the first token.

[0015] In one embodiment, the representative image of the first token may be determined to be one of several sub-digital assets included in the digital asset, based on at least one of the following numbers: a first number of usage logs or a second number of generated information recorded in the first metadata of the first token.

[0016] In one embodiment, the representative image of the first token may be determined to be one of several sub-digital assets included in the digital asset, based on at least one of the following: the first quantity and the first additive calculation of the usage period corresponding to the first quantity, or the second additive calculation of the first quantity and the first loan period corresponding to the first quantity.

[0017] In one embodiment, the representative image of the first token is determined to be one of a plurality of sub-digital assets included in the digital asset, based on whether at least one of the usage logs or generated information recorded in the first metadata of the first token satisfies a predetermined condition, and the predetermined condition may be a condition relating to at least one of the following: information relating to the owner or licensee of the digital asset included in at least one of the usage logs or generated information; information relating to content related to the use of the digital asset; or information relating to the manner of use of the digital asset.

[0018] In one embodiment, the second token generation procedure may be performed based on interaction with at least one node included in the blockchain network.

[0019] In one embodiment, the second metadata of the second token can indicate whether or not the digital asset can be subleased.

[0020] In one embodiment, the generated information may include at least one of the following: information regarding the loan period of the digital asset, information regarding the user, information regarding the content on which the digital asset is intended to be used, information regarding the intended manner of use of the digital asset, or information regarding the intended time of use of the digital asset.

[0021] In one embodiment, the loan request may involve the transmission of a virtual asset corresponding to the payment for lending the digital asset to the wallet address of the electronic device based on the loan request.

[0022] In one embodiment, based on the generation of the second token, the amount of the virtual asset is recorded in the metadata of the first token, and the one or more processors may further be configured to receive a withdrawal request for the virtual asset from the user terminal of the owner of the digital asset for the first token, and to transmit a transmission message to at least one node included in the blockchain network, based on the withdrawal request, to transmit at least a portion of the virtual asset to the owner's wallet address.

[0023] In one embodiment, the one or more processors may be configured to receive a transfer request for the second token from the user terminal of the user, and to transmit a modification message to at least one node included in the blockchain network, which modifies the information indicating the user of the second token based on the transfer request.

[0024] In one embodiment, the second metadata of the second token indicates the loan period of the digital asset, and one or more processors may be configured to further modify information indicating the user of the second token based on whether the loan period has expired.

[0025] In one embodiment, the first smart contract includes information that enables the generation of a second token including lending information of the digital asset as metadata, and the lending information of the digital asset can indicate the user of the right to use the digital asset.

[0026] According to one aspect of the content disclosed in this document, a method performed by an electronic device is provided. The method may include receiving a lending request for a digital asset corresponding to a first token from a user's user terminal, and performing a procedure for generating a second token based on the lending request. The first token is generated based on a first smart contract configured to prove the ownership of the digital asset, and the first metadata of the first token can indicate the owner of the digital asset. The second token is generated based on a second smart contract configured to prove the right to use the digital asset, and the second metadata of the second token can indicate the user of the right to use the digital asset. Based on the generation of the second token, generation information of the second token indicating the history of lending of the digital asset may be recorded in the first metadata of the first token.

[0027] In one embodiment, the method further includes receiving a usage log indicating the history of use of the digital asset from the user's user terminal, and performing a recording procedure for recording the usage log for the first token in the first metadata of the first token based on the reception of the usage log. The recording procedure may include an operation of transmitting a recording request for executing the first smart contract to at least one node of the blockchain network.

[0028] Further aspects may be explicit in a part of the following description, some of which may be apparent from the description or learned by the execution of the presented embodiments.

Advantages of the Invention

[0029] According to at least one embodiment disclosed herein, it is possible to increase the value of non-fungible tokens that guarantee digital assets.

[0030] According to at least one embodiment disclosed herein, the usage history of a digital asset can be represented by a non-fungible token that guarantees that digital asset.

[0031] According to at least one embodiment disclosed herein, the utilization of digital assets can be enhanced by providing a platform on which digital assets can be lent out.

[0032] According to at least one embodiment disclosed herein, a technology can be provided to prove the right to use a digital asset through lending.

[0033] Other aspects, features, and advantages relating to specific embodiments of the content disclosed herein will become more apparent through the description and drawings. [Brief explanation of the drawing]

[0034] [Figure 1] This diagram shows an environment in which the apparatus relating to one embodiment of the contents disclosed in this document can be applied. [Figure 2] This figure shows a computing device that can embody one embodiment of the device disclosed in this document. [Figure 3] This flowchart shows a method for generating asset tokens according to one embodiment of the content disclosed in this document. [Figure 4] This figure shows an asset token relating to one embodiment of the content disclosed in this document. [Figure 5] This flowchart shows a method for generating a usage rights token according to one embodiment of the content disclosed in this document. [Figure 6] This figure shows a usage rights token relating to one embodiment of the content disclosed in this document. [Figure 7] This flowchart shows a method for recording usage logs (Log) according to one embodiment of the content disclosed in this document. [Figure 8] This flowchart shows a method for withdrawing virtual assets using asset tokens, according to one embodiment of the content disclosed in this document. [Figure 9] This flowchart shows a method for verifying a usage rights token according to one embodiment of the content disclosed in this document. [Figure 10] This flowchart shows a method for transferring usage rights tokens according to one embodiment of the content disclosed in this document. [Modes for carrying out the invention]

[0035] The various embodiments described herein are illustrative for the purpose of clearly illustrating the technical concept of this document and are not intended to limit it to any particular embodiment. The technical concept of this document includes various modifications, equivalents, alternatives, and embodiments selectively combined from all or part of the embodiments described herein. Furthermore, the scope of rights to the technical concept of this document is not limited to the various embodiments or specific descriptions thereof presented below.

[0036] Unless otherwise defined, terms used in this document, including technical or scientific terms, may have meanings that are generally understood by those with ordinary skill in the art to which this document pertains.

[0037] Expressions such as "includes," "may include," "equip," "may equip," "possess," and "may possess" used in this document mean that the feature in question (e.g., function, operation, or component) exists, but do not exclude the existence of other further features. In other words, such expressions should be understood as open-ended terms that imply the possibility of including other embodiments.

[0038] In this document, singular expressions may also have plural meanings unless otherwise specified in the context, and this applies equally to singular expressions in claims.

[0039] In this document, expressions such as "first," "second," or "first," "second," etc., are used to distinguish one object from others when referring to multiple similar objects, unless otherwise specified in the context, and do not limit the order or importance of the objects. For example, each user terminal included in multiple user terminals related to the content disclosed in this document may be distinguished from each other by being expressed as "first user terminal" and "second user terminal," etc. Similarly, multiple tokens related to the content disclosed in this document may be distinguished from each other by being expressed as "first token" and "second token," etc.

[0040] Expressions used in this document such as "A, B, and C," "A, B, or C," "at least one of A, B, and C," or "at least one of A, B, or C" can refer to each of the listed items, or any possible combination of the listed items. For example, "at least one of A or B" can refer to (1) at least one A, (2) at least one B, or (3) all of at least one A and at least one B.

[0041] The expression "based on" as used in this document is used to describe one or more factors that influence an act or action of decision, judgment, or action described in the phrase or sentence containing this expression, and this expression does not exclude any further factors that influence that act or action of decision, judgment, or action.

[0042] In this document, the expression that one component (e.g., the first component) is "linked" or "connected" to another component (e.g., the second component) can mean not only that the first component is directly linked or connected to the other component, but also that it is linked or connected via yet another component (e.g., the third component).

[0043] The expression "configured to" as used in this document may mean, depending on the context, "set to do," "capable of doing," "modified to do," "made to do," or "capable of doing." This expression is not limited to meaning "specifically designed in hardware." For example, a processor configured to perform a specific operation can mean a generic-purpose processor that can perform that specific operation by running software, or a special-purpose computer that is programmed to perform that specific operation.

[0044] Embodiments of the present invention may be described and illustrated in terms of a block performing the functions described, as shown in the drawings. Such blocks, which may be referred to herein as units, modules, or similar, or as devices, logic, circuits, counters, comparators, generators, converters, or similar names, may be physically embodied by analog and / or digital circuits including one or more of the following: logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, etc. They may also be embodied or driven by software and / or firmware (configured to perform the functions or operations described herein).

[0045] As used in this document, the term "Digital Asset" can refer to any data that is represented in binary and usable as an asset. Digital assets may include, for example, text, 2D images, 3D images, videos, or polygon graphics. More specifically, digital assets may include text, 2D images, 3D images, videos, or polygon graphics for items such as clothing, bags, accessories, furniture, vehicles, buildings, real estate, game items, or digital cards. In the various embodiments described in this document, digital assets may be traded as a single asset with value between owners or licensees, or used by owners or licensees in various content. In addition, in the various embodiments, the authenticity of digital assets may be guaranteed by non-fungible tokens corresponding to the digital assets.

[0046] As used in this document, the term "token" refers to a token usable on a blockchain managed by a blockchain network, and may be a non-fungible token. Hereafter, in the disclosures in this document, anything simply referred to as a token may be a non-fungible token unless otherwise specified in the context.

[0047] Specifically, a token may be a collection of data containing a specific type of data. In one embodiment, a token may include at least one of the following: information for accessing the digital asset linked to the token (hereinafter also referred to as a "Digital Asset URI (Uniform Resource Identifier)"), information for accessing the token's metadata (hereinafter also referred to as a "Metadata URI"), or information about the token's owner (for example, the address of the owner's node on the blockchain (hereinafter also referred to as "Information Identifying the Owner"). In another embodiment, a token may further include the digital asset linked to the token or the token's metadata. The Digital Asset URI linked to the token may be the address of a centralized server or cloud server where the digital asset is stored. Alternatively, the Digital Asset URI may be an IPFS (InterPlanetary File System) file distributed across multiple devices. The hash value of the digital asset stored on the IPFS System (for example, "ipfs.io / ipfs / 12345678") may also be the hash value of the digital asset stored on the IPFS System. The token metadata URI may be the address of the central server or cloud server where the token metadata is stored. Alternatively, it may be the hash value of the metadata stored on IPFS. The token metadata may refer to a data set containing various information about the token. The metadata may include, for example, the token name, token identification information (hereinafter also referred to as "token ID"), the name of the specific object associated with the token, the token creation date, information on the current owner of the token, the history of changes in token ownership, or information for accessing the digital asset linked to the token (i.e., the digital asset URI mentioned above). For an example of expressing arbitrary metadata in JSON (JavaScript® Object Notation) format, refer to the explanation of Figure 4 or Figure 6 below.In this document, expressions such as "the first information possessed by the token," "the first information recorded in the token," or "the first information contained in the token" should be understood as meaning "the first information contained in (or recorded in) the token's metadata."

[0048] As used in this document, the term "smart contract" may refer to a program or application that runs on a virtual machine (Virtual Machine) executed by one or more nodes included in a blockchain network. A smart contract may be constructed to conform to certain rules (or protocols). For example, a smart contract may be constructed to include one or more functions corresponding to each protocol, such as ERC-20, ERC-721, or ERC-1155. However, any variety of smart contracts may be constructed by including other functions not included in the exemplified protocols.

[0049] As used in this document, the term "usage log" may refer to a record representing the usage history of a digital asset when it is used in content. Specifically, a "usage log" may include at least one of the following: information about the owner or licensee of the digital asset that used the digital asset; information about the content in which the digital asset was used; information about the manner in which the digital asset was used; or information about the time of use of the digital asset. Content may be symbols, characters, graphics, colors, sounds, sounds, images, videos, or combinations thereof, and may include, for example, movies, dramas, games, audio clips, or video clips. The manner of use of a digital asset may mean the overall appearance, form, or arrangement of the digital asset when it is used in content, or it may mean the images or audio within the content when the digital asset is used.

[0050] The usage may include how the digital asset changes dynamically through interaction with other elements within the content. For example, if a digital asset is used in a film, the usage log may include the film's title, the scene in which the digital asset is used, the scene's position and duration on the film's overall timeline, or the date the digital asset was used in the film. For example, if a digital asset is used in a game, the usage log may include the game's title, the digital asset's position on the game's map, the date it was used in the game, or a list of game accounts that used the digital asset. For example, if a digital asset is used in a metaverse, the usage log may include the platform's name, a list of user accounts on the platform that used the digital asset, the digital asset's position in the metaverse, or the date it was used in the metaverse. In addition to the examples above, digital assets that can be recorded in the form of text or images may also be included in the usage log.

[0051] The term "subleasing" as used in this document can refer to the act of a user who has borrowed a digital asset (i.e., the right holder of the digital asset) lending that digital asset to another user. Since the lending of digital assets related to the content disclosed in this document is based on usage rights tokens, such "subleasing" may be embodied, for example, by changing the information indicating the right holder included in the metadata of the usage rights token.

[0052] The various embodiments described in this document will be explained below with reference to the attached drawings. In the attached drawings and descriptions thereof, identical or substantially equivalent components may be denoted by the same reference numeral. Furthermore, in the descriptions of the various embodiments below, redundant descriptions of identical or corresponding components may be omitted, but this does not mean that the component is not included in that embodiment.

[0053] Figure 1 shows an environment to which the apparatus relating to one embodiment of the content disclosed in this document can be applied. This environment may include a platform operation server 110, a blockchain network 120 including multiple nodes (for example, a first node 120a, a second node 120b, a third node 120c, a fourth node 120d, a fifth node 120e, a sixth node 120f, a seventh node 120g, and an eighth node 120h), or one or more user terminals (for example, a first user terminal 130a, a second user terminal 130b, a third user terminal 130c; hereinafter referred to as 130). Figure 1 shows an example in which one or more user terminals 130 and multiple nodes 120a to 120h are connected to the platform operation server 110 via a network, but this is only for the purpose of providing convenience of understanding, and the number of user terminals and nodes can be changed at will.

[0054] The platform operation server 110 may be a server that embodies a platform for supporting the trading of digital assets based on non-fungible tokens. The platform operation server 110 may be a device related to an entity that operates this platform. The platform operation server 110 can perform various processes on non-fungible tokens related to digital assets in order to support the trading of digital assets. For example, the platform operation server 110 can receive a digital asset from a first user terminal 130a and perform a procedure to generate a token (e.g., an asset token) that can prove ownership of that digital asset. As another example, the platform operation server 110 can receive a loan request for a digital asset from a second user terminal 130b and perform a procedure to generate a token (e.g., a usage right token) that can prove the right to use that digital asset. In the above examples, the generation procedure may include the operation of the platform operation server 110 transmitting the generation request to at least one node 120a to 120h included in the blockchain network 120. A detailed explanation of the generation procedure will be provided below with reference to Figure 3 or Figure 5.

[0055] As yet another example, the platform operation server 110 can receive a usage log of a digital asset from a third user terminal 130c and perform a recording procedure to record the usage log in the metadata of the token (e.g., asset token) corresponding to that digital asset. In the above example, the recording procedure may include the platform operation server 110 transmitting a recording request to at least one node 120a to 120h included in the blockchain network 120. In one embodiment, at least one node 120a to 120h that receives the recording request can record the usage log on the web page of a link (e.g., a URL linked to an external web page) included in the metadata of the asset token. A specific explanation of the recording procedure will be described below with reference to Figure 7.

[0056] In addition to the examples mentioned above, the platform operating server 110 can perform various operations required for a trading platform of non-fungible token-based digital assets. For example, the platform operating server 110 can store and manage tokens (e.g., asset tokens or usage rights tokens) received from the user terminal 130 and provide the user with a UI (User Interface) for token management. Furthermore, the platform operating server 110 can perform buy or sell procedures for tokens in response to buy or sell requests from the user terminal 130. In other words, the platform operating server 110 can operate as a platform that acts as an intermediary between token sellers and buyers. In one embodiment, a virtual asset may be requested as counter-payment for the token in order for the platform operating server 110 to initiate a buy or sell procedure. In one embodiment, the token may be transferred from the seller's wallet address to the buyer's wallet address as a result of the buy or sell procedure performed by the platform operating server 110.

[0057] Furthermore, the platform operating server 110 can interact with nodes 120a to 120h included in the blockchain network 120, thereby participating in the generation of tokens or the recording of usage logs.

[0058] The aforementioned platform operation server 110 may be embodied as one or more computing devices. For example, all functions of the platform operation server 110 may be embodied in a single computing device. As another example, the first function of the platform operation server 110 may be embodied in a first computing device, and a second function distinct from the first function may be embodied in a second computing device distinct from the first computing device. Here, the aforementioned computing devices may be, but are not limited to, desktops, laptops, application servers, proxy servers, or cloud servers, and may include any type of device equipped with computing functions.

[0059] The blockchain network 120 may include one or more nodes 120a to 120h that manage the blockchain. A block may represent a specific data type. A blockchain may represent a data structure in which one or more blocks are linked together in a chain. One or more blocks included in the blockchain may be stored independently in multiple nodes 120a to 120h included in the blockchain network 120, or they may be distributed and stored across multiple nodes. Each of the one or more blocks may include a block hash, a block header, or a block body. The block hash is unique information that can identify a block, and may be, for example, a string represented by 256 bits. The block header may include, for example, software or protocol version information, the hash of the transferred block according to the block concatenation order on the blockchain, the Merkle root, time information indicating the time the block was generated, bits indicating the difficulty of the computation, or a nonce, which is a value required for the mining process of adding a new block to the blockchain. The block body may include at least one transaction. A transaction is a collection of data having a specific data structure and may be a unit of information stored in the block body. A transaction may include information about token generation or trading. For example, a transaction may contain information stating that "a first node 120a included in blockchain network 120 transmits a token to a second node 120b." As another example, a transaction may contain information stating that "a first node 120a included in blockchain network 120 transmits a non-fungible token to a second node 120b."

[0060] Each of the at least one node 120a to 120h included in the blockchain network 120 may be called a “participant” of the blockchain network 120. The at least one node 120a to 120h included in the blockchain network 120 may operate in a hierarchical structure. This hierarchical structure may include, for example, a data hierarchy that defines the structure of the data handled by the blockchain network 120 and manages the data; a consensus hierarchy that verifies the validity of blocks, performs mining to generate blocks, and is responsible for processing the fees paid to miners in the mining process; a common hierarchy that embodies or manages the P2P network protocol, hash functions, digital signatures, encoding, and common storage; or an application hierarchy where various applications are generated or processed.

[0061] At least one node 120a to 120h included in the blockchain network 120 can share or store transactions recorded on the blockchain. Furthermore, at least one node 120a to 120h included in the blockchain network 120 may have the function of verifying transactions transmitted to the blockchain network 120 using the blockchain's consensus algorithm, and recording the verified transaction in a block on the blockchain once verification is complete. The consensus algorithm used by the blockchain network 120 may include at least one of the following: PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stage), PBFT (Practical Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), RBFT (Redundant Byzantine Fault Tolerance), Sieve, Tendermint, Paxos, Raft, PoA (Proof of Authority), or PoET (Proof of Elapsed Time).

[0062] Each of the at least one node 120a to 120h included in the blockchain network 120 can store a smart contract. This allows at least one node 120a to 120h included in the blockchain network 120 to share the same smart contract. The smart contract may also be recorded in a block on the blockchain managed by the blockchain network 120. The smart contract may be, for example, a document or script created in a programming language such as Solidity, or a program or application that runs on a virtual machine executed by at least one node 120a to 120h included in the blockchain network 120. The smart contract may be designed so that a specific action is performed when a specific condition is met. In this case, the specific condition may be, for example, a condition in which a specific type of token or a file of a specific format is input. The specific action may be, for example, an action in which a specific type of token is transmitted to any node of the blockchain network 120.

[0063] The aforementioned nodes 120a to 120h may be full nodes, light nodes, master nodes, mining nodes, random nodes, baking nodes, or super nodes, depending on the operations they perform. By interacting with the platform operation server 110, nodes 120a to 120h can generate tokens (e.g., asset tokens, usage rights tokens) or record usage logs.

[0064] Nodes 120a to 120h may be embodied as computing devices. For example, the aforementioned computing devices may be, but are not limited to, desktops, laptops, application servers, proxy servers, cloud servers, etc., and may include any type of device equipped with computing capabilities.

[0065] The user terminal 130 may be the terminal of a user who uses a platform for trading non-fungible token-based digital assets. For example, the user terminal 130 may be the terminal of the owner of the digital assets or the terminal of the licensee of the digital assets. To allow each user to use the digital asset trading platform, the user terminal 130 may be equipped with a web browser or a dedicated application. Such a user terminal 130 may be, but is not limited to, any one of the following devices: a desktop, workstation, laptop, tablet computer, wearable device, or smartphone, and may include any type of computing device equipped with computing capabilities.

[0066] The platform operating server 110, nodes 120a to 120h, and user terminals 130 can communicate with each other via a network. The aforementioned network may be implemented as any type of wired or wireless network, such as a Local Area Network (LAN), Wide Area Network (WAN), Mobile Radio Communication Network, or Wibro (Wireless Broadband Internet).

[0067] On the other hand, the platform operation server 110, nodes 120a to 120h, and user terminals 130 represent functionally distinct elements. That is, two or more components may be implemented in an integrated form in the actual physical environment. For example, either the platform operation server 110 or one of the nodes 120a to 120h may be implemented in the same computing device in forms of different logic. That is, the platform operation server 110 may be implemented to also function as nodes 120a to 120h of the blockchain network 120.

[0068] Figure 2 shows a computing device 200 that can embody an apparatus according to one embodiment of the content disclosed in this document. In the content disclosed in this document, the computing device 200 may be represented as an electronic device, and the computing device 200 and the electronic device may be used interchangeably. The aforementioned platform operation server 110, nodes 120a to 120h, and user terminal 130 may be embodied by this computing device. The computing device 200 may include one or more processors 210 or one or more memories 220. In one embodiment, some components may be removed from the computing device 200, and other components (e.g., a display) may be added to the computing device 200. Alternatively, some components may be embodied as an integrated entity or as one or more individual entities. In the content disclosed in this document, one or more processors 210 may be represented as processor 210. Such representation as processor 210 can mean one or more processors unless otherwise specified in the context. Furthermore, in the disclosures in this document, one or more memories 220 may be referred to as "memory 220." Unless otherwise specified in the context, such a reference to "memory 220" can mean one or more sets of memories.

[0069] At least some components within the computing device 200 are connected to each other via a bus, GPIO (General Purpose Input / Output), SPI (Serial Peripheral Interface), or MIPI (Mobile Industry Processor Interface), etc., and can exchange data or signals.

[0070] The processor 210 can perform calculations and data processing related to the control or communication of each component of the computing device 200. Specifically, the processor 210 can drive software (e.g., instructions, programs, etc.) received from other components to control at least one component of the computing device 200 connected to the processor 210. For example, the processor 210 can load instructions or data into memory 220, process the instructions or data stored in memory 220, and store the resulting data in memory 220. Furthermore, the processor 210 is operationally connected to the components of the computing device 200 and can perform various operations such as calculations, processing, data generation, and manipulation related to the content disclosed in this document.

[0071] Memory 220 can store various types of data. The data stored in memory 220 is data acquired, processed, or used by at least one component of the computing device 200, and may include software (e.g., instructions, programs, etc.). For example, memory 220 can store instructions for the operation of the processor 210 as a computer program. Here, the computer program, when loaded into memory 220, may include one or more instructions that cause the processor 210 to perform operations according to various embodiments of the content disclosed herein. That is, the processor 210 can perform operations according to various embodiments of the content disclosed herein by executing the aforementioned one or more instructions. Memory 220 may also include volatile or non-volatile memory. In one embodiment, the instructions or program are software stored in memory 220 and may include an operational system for controlling the resources of the computing device 200, an application, or middleware that provides various functions to the application so that the application can utilize the resources of the computing device 200.

[0072] In one embodiment, the computing device 200 may further include a communication interface 230, which may also be called a network interface. The communication interface 230 can establish a wired or wireless communication channel with an external device (e.g., each of nodes 120a to 120h or each of user terminals 130) and send and receive various data with the external device. In one embodiment, the communication interface 230 may include at least one port for being connected to an external device by a wired cable in order to communicate with the external device via a wired connection. In this case, the communication interface 230 can communicate with the external device connected by a wired connection through at least one port. In one embodiment, the communication interface 230 may include a cellular communication module and be configured to be connected to a cellular network (e.g., 3G, LTE, 5G, Wibro, or WiMAX). In one embodiment, the communication interface 230 includes a short-range communication module that can transmit and receive data with an external device using short-range communication (e.g., Wi-Fi, Bluetooth®, BLE (Bluetooth® Low Energy), UWB). In one embodiment, the communication interface 230 may include a contactless communication module for contactless communication. Here, contactless communication may include at least one contactless proximity communication technology, such as NFC (Near Field Communication) communication, RFID (Radio Frequency Identification) communication, or MST (Magnetic Secure Transmission) communication. In addition to the various examples described above, the computing device 200 may be embodied in various known ways for communicating with an external device, and the scope of the disclosures in this document is not limited to the examples described above.

[0073] In one embodiment, the computing device 200 may further include a display. Here, the display can show various screens based on the control of the processor 210. For example, the display can show the results of reading usage logs recorded in the metadata of asset tokens based on the control of the processor 210. In this case, a web browser or dedicated application may be installed on the computing device 200 to display the results of reading usage logs on the display. In one embodiment, the aforementioned web browser or dedicated application may be implemented to provide the user with functions such as a function to request the generation of tokens corresponding to digital assets (e.g., asset tokens, usage right tokens), and a function to trade digital assets through a user interface. The display is also configured to be interactive with the user, and can show various screens based on the control of the processor 210 and receive user input from the user. Such a display may be implemented in the form of a touch sensor panel (TSP) that can recognize contact or proximity of various external objects (e.g., fingers, stylus, etc.). Herein, the touch sensor panel may have various structures and types, and the contents disclosed in this document are applicable regardless of the structure and type of the touch sensor panel.

[0074] In one embodiment, the computing device 200 may further include an input device (e.g., a mouse, a keyboard, etc.). The input device can receive data used by the components of the computing device 200 (e.g., a processor 210) from outside the computing device 200 (e.g., a user).

[0075] Figures 3, 5, 7, and 8-10 illustrate a non-fungible token processing method according to one embodiment of the content disclosed in this document. Although the illustrated non-fungible token processing method is described as having a specific sequence of operations, depending on the embodiment, each operation does not necessarily have to be performed in the illustrated order or sequential order, or all operations may not be performed. Furthermore, although the stages of the non-fungible token processing method shown in Figures 3, 5, and 7 show the execution entity for each stage, there may be any number of acceptable variations in the execution entity. For example, the platform operation server 110 can integrate with any one of the nodes 120a-120h of the blockchain network 120 and perform all the operations of the platform operation server 110 and the node.

[0076] Figure 3 is an exemplary flowchart illustrating a method for generating asset tokens according to one embodiment of the content disclosed in this document. The asset token generation method shown in Figure 3 relates to a user uploading a digital asset to a platform and generating an asset token corresponding to this digital asset. This digital asset may be traded (e.g., bought, sold, lent, etc.) based on the generated asset token. Here, the asset token may be a non-fungible token that corresponds one-to-one with the digital asset, and the metadata of this asset token may include information indicating the owner of the digital asset. In the content disclosed in this document, the asset token may be referred to as the first token.

[0077] In the disclosures herein, the generation of asset tokens may be understood as asset token minting. Therefore, any publicly known techniques not described in the disclosures herein in relation to minting may be applied to the disclosures herein. For the sake of explanation, the process of generating asset tokens through the interaction between the platform operation server 110 and the first node 120a of the blockchain network 120 has been described, but other additional nodes may also be involved in the generation of asset tokens. Alternatively, the platform operation server 110 and the first node 120a may each be embodied in the form of logic within a single computing device. That is, the procedure for generating asset tokens can also be performed by embodiing the platform operation server 110 and the first node 120a as a single, undivided device.

[0078] The first user terminal 130a can transmit a digital asset to the platform operation server 110 and request the generation of an asset token corresponding to this digital asset (S11). For example, the first user terminal 130a can transmit a digital asset and request the generation of an asset token to the platform operation server 110. The request for asset token generation can be understood as the same as or similar to the operation in which the first user terminal 130a transmits a message to the platform operation server 110 requesting the start of the procedure for generating an asset token. Here, the first user terminal 130a can mean a terminal used by the owner of the digital asset. Also, here, the transmission of the digital asset can be expressed as uploading the digital asset. Here, in conjunction with the request for asset token generation, at least a portion of the information regarding the owner of the digital asset, the lending conditions of the digital asset, or the address of the digital asset may be transmitted from the first user terminal 130a to the platform operation server 110 as information regarding the digital asset. In this case, the information about the digital asset transmitted in conjunction with the request to generate the asset token may be used to generate the asset token, so that the asset token is generated to include at least a portion of the aforementioned information as metadata.

[0079] The platform operation server 110 can preprocess information about digital assets (S12). Here, preprocessing can mean the operation of extracting at least a portion of the digital assets and information about the digital assets received from the first user terminal 130a in order to proceed with the asset token generation procedure, processing or modifying them, and then storing them again in the platform operation server 110. In other words, preprocessing can be understood as the operation of processing digital assets and information about the digital assets in a manner that corresponds to the generation protocol for generating asset tokens. For example, the platform operation server 110 can extract a portion of the metadata of the received digital assets (e.g., the extension of the digital asset, the address of the digital asset, etc.). For example, the platform operation server 110 can extract, delete, or modify at least a portion of the information about the received digital assets. For example, the platform operation server 110 can store the received digital assets in storage (e.g., distributed storage (IPFS), centralized storage (S3), etc.). In addition to the examples mentioned above, the platform operating server 110 can perform all operations to preprocess information about digital assets in the form required by the asset token generation protocol. However, depending on the embodiment, the preprocessing of information about digital assets (S12) may be omitted.

[0080] The platform operation server 110 can transmit a request for the generation of asset tokens to the first node 120a (S13). The request for the generation of asset tokens may be understood as identical or similar to the operation by which the platform operation server 110 transmits a message to the first node 120a requesting the execution of the first smart contract described later. In various embodiments, the platform operation server 110 can transmit information about pre-processed digital assets to the first node 120a along with the request for the generation of asset tokens.

[0081] The first node 120a can generate asset tokens based on information about digital assets and a first smart contract (S14). Here, the smart contract is a program or application that runs on the blockchain network 120 and may be executed by one or more nodes 120a to 120h included in the blockchain network 120 using a distributed computing method. The smart contract may include code that pre-programs certain conditions so that when these conditions are met, a pre-configured action is executed. Here, the first smart contract can mean a smart contract embodied in the code for generating asset tokens. For example, the first smart contract may be embodied by referring to a non-fungible token generation protocol such as ERC-721 or ERC-1155.

[0082] In one embodiment, the first smart contract may be constructed such that information indicating the history of use of the digital asset corresponding to the asset token (hereinafter referred to as the "usage log") is recorded in the metadata of the asset token. In one embodiment, the usage log may be cumulatively recorded on the web page of a link included in the metadata of the asset token based on the first smart contract. That is, the metadata of the asset token generated based on the first smart contract may cumulatively record the usage log of the digital asset corresponding to the asset token. In another embodiment, the first smart contract may include information that can generate a usage rights token. Here, the metadata of the usage rights token may include information that identifies the user of the digital asset (e.g., a user who borrowed the digital asset and a user who subleased the digital asset). The user of the digital asset can prove their usage rights using the usage rights token. Here, the information that can generate a usage rights token may include, for example, information on the procedure for generating a usage rights token in response to a request to lend the digital asset or information on the price required for lending the digital asset.

[0083] In yet another embodiment, the first smart contract may be constructed such that when a usage right token is generated by information capable of generating a usage right token, the generation information of that usage right token is recorded in the metadata of the asset token. In one embodiment, the generation information may be cumulatively recorded on the web page of a link (e.g., a URL linked to an external web page) included in the metadata of the asset token based on the first smart contract. That is, the metadata of the asset token generated based on the first smart contract may cumulatively record the generation information as usage right tokens are generated. For example, each time a usage right token is generated, the generation information of that usage right token may be recorded in the asset token. The generation information of a usage right token may include various types of information. For example, information regarding the loan period of the digital asset, information regarding the user of the digital asset, information regarding the content in which the digital asset is intended to be used, information regarding the intended manner of use of the digital asset, or information regarding the intended time of use of the digital asset may be recorded as a string or image as the generation information of the usage right token. As another example, the generation information may be information indicating the fact that a usage right token has been generated, or information indicating the number of times the usage right token has been generated. For example, when the first usage token is generated, the generation information may have a value of 1, and thereafter, each time a usage token is generated, it may be changed to have an accumulated value.

[0084] Since the lending of digital assets related to the content disclosed in this document is based on usage rights tokens, the generation information of such usage rights tokens may be information indicating the history of the lending of the digital assets. Therefore, the value of the asset tokens that guarantee the digital assets may increase as usage rights tokens are generated by the lending of digital assets, and information regarding their generation is cumulatively recorded as generation information in the metadata of the asset tokens.

[0085] In yet another embodiment, the first smart contract may include information regarding an incentive for recording usage logs. Since recording usage logs in the metadata of an asset token incurs a fee (e.g., gas) for executing the smart contract, recording usage logs can be encouraged by providing an incentive for doing so. Here, the provision of an incentive may be, for example, the act of transmitting a portion of the payment for a loan to the wallet address of the user recording the usage log, but the scope of disclosure in this document is not limited to this, and any act to encourage recording usage logs may be included in the scope of disclosure in this document.

[0086] The first node 120a can transmit a notification of asset token generation to the platform operation server 110 (S15). The platform operation server 110 can transmit a notification of asset token generation to the first user terminal 130a (S16). Such generation notification transmission processes (S15, S16) may be carried out by various publicly known techniques, and the operation that can notify the generation of asset tokens may be included within the scope of the disclosures in this document. Furthermore, depending on the embodiment, at least some of the generation notification transmission processes (S15, S16) may be omitted.

[0087] In one embodiment, the generated asset token may be transmitted to the wallet address of the owner of the digital asset using the first user terminal 130a in conjunction with either of the asset token generation notification processes (S15, S16). In another embodiment, the generated asset token may be transmitted to the wallet address of the platform operation server 110. In yet another embodiment, the generated asset token may be transmitted to the wallet address of the owner of the digital asset using the first user terminal 130a or the wallet address of the platform operation server 110, regardless of whether the generation notification transmission (S15, S16) has been performed. For example, even if the generation notification transmission (S15, S16) is omitted, the generated asset token may be transmitted to the wallet address of the owner of the digital asset using the first user terminal 130a or the wallet address of the platform operation server 110 because the asset token is generated in step S14.

[0088] Figure 4 shows metadata for an asset token relating to one embodiment of the content disclosed in this document. The metadata for the asset token 400 may include attribute information 410. Here, the attribute information 410 may include at least some of the following information: the identifier of the asset token (the "Token ID" attribute (Attribute) in Figure 4), the URI or URL address of the digital asset, the address of the storage where the digital asset is stored (the "File URI" attribute in Figure 4, e.g., IPFS), the owner of the digital asset (the "Owner" attribute in Figure 4), the price required to lend the digital asset (the "Asset Permission Price" attribute in Figure 4), whether the digital asset can be subleased (the "Binded" attribute in Figure 4), and the revenue accumulated from lending the digital asset (the "Total Profit" attribute in Figure 4). However, in addition to the above-mentioned information that may be included in the attribute information 410, any amount of further information that can represent the attributes of the digital asset may be included.

[0089] In one embodiment, the metadata 400 of the asset token may further include information on the generation of usage rights tokens. The generation information recorded by the generation of usage rights tokens, i.e., by the lending of the digital asset, can form a unique heritage for this digital asset. The metadata 400 of the asset token may also include one or more usage logs 420. The usage logs 420 may be accumulated and recorded in the metadata 400 of the asset token as a result of the use of the digital asset corresponding to the metadata 400 of the asset token. In one embodiment, the usage logs 420 recorded in the metadata 400 may be recorded in the form of a URL linked to an external web page where the usage logs are recorded. In this case, the input usage logs may be accessed by connecting to the URL of the usage log 420 recorded in the metadata 400 of the asset token. One or more recorded usage logs 420 can form a unique heritage for this digital asset.

[0090] In one embodiment, the representative image of an asset token may be determined to be one of several sub-digital assets included in the digital asset, based on the number of usage rights token generation information or usage logs recorded in the metadata of the asset token. For example, the representative image of an asset token may be determined based on the number of usage rights token generation information associated with the asset token, or based on the number of usage logs associated with the asset token. As another example, the representative image of an asset token may be determined based on the sum or additive sum of the number of usage rights token generation information associated with the asset token and the number of usage logs associated with the asset token. Here, multiple sub-digital assets can mean multiple lower-level digital assets that have common attributes and can be clustered together as a single digital asset. For example, if a portrait of a person is a digital asset, the sub-digital assets of this portrait may include portraits of childhood, youth, adulthood, and old age. For example, if an image of a chair is a digital asset, the sub-digital assets of this chair image may include images of a new chair, a stained chair, and an old chair. For example, if a stained image is a digital asset, the sub-digital assets of this image may include multiple images in which at least a portion of the original image has been altered. Such alterations can mean any alteration to the original image, such as adding and changing shapes, changing hues, or moving the position of some pixels. Here, the representative image is an image representing the asset token, and this representative image may be changed to one of the sub-digital assets according to predetermined conditions (e.g., the generation information or the number of usage logs for the right-of-use token). Techniques related to Dynamic NFTs may be referenced for determining this representative image. By changing the representative image of the asset token according to the generation information or the number of usage logs for the right-of-use token, the asset token can be represented in a variety of ways, thereby increasing the value of the asset token. For example, a portrait of a person may change from a portrait of childhood to a portrait of old age depending on the generation information or the number of usage logs for the right-of-use token.For example, as the number of generated usage tokens or usage logs increases, the representative image of the chair may change from an image of a new chair to an image of an increasingly old chair.

[0091] In other embodiments, the representative image of an asset token may be determined to be one of several sub-digital assets included in the digital asset, based on the number of generation information entries recorded in the asset token's metadata and the additive weighting of the loan periods corresponding to those generation information entries. For example, if the loan period for the first generation information is one week and the loan period for the second generation information is one day, the first weighting applied to the first generation information may be set to be greater than the second weighting applied to the second generation information. This means that even if "Token A" and "Token B" each have two generation information entries recorded, the representative image of the token with the longer combined loan period may change more quickly. According to this embodiment, in addition to the number of generation information entries, the loan period corresponding to each generation information entry is also considered, and the representative image of the asset token can be changed accordingly. In other words, the representative image of the asset token can be changed by considering not only the number of loans to the digital asset, but also the loan time.

[0092] In yet another embodiment, the representative image of an asset token may be determined to be one of several sub-digital assets included in the digital asset, based on the additive weighting of the number of usage logs recorded in the asset token's metadata and the usage periods corresponding to those usage logs. The usage period can mean the period of use of the digital asset corresponding to the usage log. For example, if the loan period of a digital asset is one month, and the usage period during which the digital asset was used for a specific content is one week, then it may be understood that this digital asset was loaned for a total of one month, and used for a specific content for one week within this loan period. In other words, according to this example, the usage period corresponding to the usage log may be one week. To give a specific example related to additive weighting, if the usage period of the first usage log is one week and the usage period of the second usage log is one day, the first weighting value applied to the first usage log may be set to be greater than the second weighting value applied to the second usage log. This allows the representative image of the token with the longer combined usage period to change more quickly, even if two usage logs are recorded for both "Token A" and "Token B". According to this embodiment, in addition to the number of usage logs, the usage period corresponding to each usage log is also taken into consideration, allowing the representative image of the asset token to be changed. In other words, the representative image of the asset token can be changed by considering not only the number of times the digital asset is used, but also the duration of use.

[0093] In yet another embodiment, the representative image of an asset token may be determined to be one of several sub-digital assets included in the digital asset, based on whether the usage log (or generation information of the usage rights token) recorded in the metadata of the asset token satisfies certain conditions. Specifically, when calculating the number of usage logs (or generation information) to determine the representative image of an asset token, if one usage log (or generation information) recorded in the metadata of the asset token satisfies certain conditions, a weighted value can be assigned to that usage log (or generation information) to calculate the total number of usage logs (or generation information). Alternatively, when determining the representative image of an asset token, if one usage log (or generation information) recorded in the metadata of the asset token satisfies certain conditions, the sub-digital asset corresponding to those conditions may be determined as the representative image.

[0094] Here, the specific condition may be a condition relating to information about the owner or user of the digital asset that used the digital asset. For example, the specific condition may be a condition in which a person belonging to "Group A" (e.g., 100 people this year) uses the digital asset and is recorded in the usage log. If there is a usage log in which a person belonging to "Group A" used the digital asset as the owner or user, that usage log may be weighted when calculating the number of usage logs, or a sub-digital asset (e.g., a sub-digital asset related to "Group A") corresponding to this specific condition (the condition in which a person belonging to "Group A" uses the digital asset and is recorded in the usage log) may be determined as a representative image. As another example, the specific condition may be a condition in which a person belonging to the "group" lends out the digital asset and information on the generation of usage tokens is recorded.

[0095] The specific condition may also be a condition relating to information about the content in which the digital asset is used. For example, the specific condition may be that the digital asset is used in content belonging to "Group B" (e.g., films nominated for a film festival) and recorded in the usage log. If there is a usage log in which the digital asset is used in content belonging to "Group B" among the usage logs, that usage log may be weighted when calculating the number of usage logs, or a sub-digital asset (e.g., a sub-digital asset related to "Group B") corresponding to this specific condition (the condition that the digital asset is used in content belonging to "Group B" and recorded in the usage log) may be determined as a representative image. As another example, the specific condition may be that the use of the digital asset is planned for content belonging to "Group B" and recorded in the generated information.

[0096] Other specific conditions may be conditions relating to the manner in which the digital asset is used (for example, conditions that the digital asset is used in a specific type of content (e.g., movies, dramas, games, audio clips, etc.) and recorded in the usage log (or generated information)), or conditions relating to the time of use of the digital asset (for example, conditions that the digital asset is used up to a specific date and recorded in the usage log (or generated information)). The specific conditions may also be a combination of at least some of the conditions described above.

[0097] In connection with this embodiment, information for determining whether or not specific conditions have been met may be stored in advance in the memory 220 of the platform operation server 110. The platform operation server 110 can also receive information for determining whether or not specific conditions have been met from an external database. In this case, the information for determining whether or not specific conditions have been met may be stored in the external database in advance. For example, the information for determining whether or not specific conditions have been met may include at least a part of the following: information about a person belonging to "Group A", information about content belonging to "Group B", information about a specific type of content, or information about a specific date.

[0098] Figure 5 is an exemplary flowchart illustrating a method for generating usage rights tokens according to one embodiment of the content disclosed in this document. The method for generating usage rights tokens according to one embodiment relates to generating usage rights tokens for lending digital assets uploaded to a platform. Here, the usage rights token may be a non-fungible token that corresponds one-to-one with a lending request for the digital asset. In one embodiment, the usage rights token may include lending information (e.g., information about the user of the digital asset, information about the lending period, etc.). In the content disclosed in this document, the usage rights token may be referred to as the second token. The generation of the usage rights token may be understood as minting the usage rights token.

[0099] This description explains how usage rights tokens are generated through interaction between the platform operation server 110 and the second node 120b of the blockchain network. However, any number of additional nodes can also participate in the generation of usage rights tokens. Alternatively, the platform operation server 110 and the second node 120b may be implemented within the same computing device in the form of different logics. That is, the platform operation server 110 and the second node 120b can be implemented as a single, undivided device to perform the procedure for generating usage rights tokens.

[0100] The second user terminal 130b can transmit a loan request to the platform operation server 110 (S21). The second user terminal 130b can mean a terminal used by a user who wishes to borrow a digital asset. A loan request may be understood as identical or similar to the operation in which the second user terminal 130b transmits a message to the platform operation server 110 requesting the commencement of the procedure for lending a digital asset. Here, along with the loan request, at least a portion of the following may be transmitted from the second user terminal 130b to the platform operation server 110 as information regarding the loan request: information about the user who made the loan request, information about the loan period, information about the intended use of the digital asset (e.g., the content to be used, the intended manner of use, the intended time of use, etc.), or information about the digital asset that is the subject of the loan request. At this time, the information regarding the loan request transmitted along with the loan request may be used to generate a usage right token, so that the usage right token is generated to include at least a portion of the aforementioned information as metadata. Furthermore, in response to a loan request, virtual assets used to pay for the loan of digital assets may be transferred from the wallet address of the user using the second user terminal 130b to the wallet address of the platform operation server 110.

[0101] The platform operation server 110 can preprocess information regarding loan requests (S22). Here, preprocessing can mean the operation of extracting at least a portion of the information regarding loan requests received from the second user terminal 130b, processing or modifying it, and then storing it back in the platform operation server 110 in order to perform the procedure for generating a usage right token. In other words, preprocessing can be understood as the operation of processing information regarding loan requests in a manner that corresponds to the generation protocol for generating a usage right token. For example, the platform operation server 110 can extract, delete, or modify at least a portion of the information regarding loan requests. In addition to the examples given above, the platform operation server 110 can perform various operations to preprocess information regarding loan requests, and can perform operations to preprocess information regarding loan requests in a manner required by the usage right token generation protocol. However, depending on the embodiment, the preprocessing of information regarding loan requests (S22) may be omitted.

[0102] The platform operation server 110 can transmit a request for the generation of a usage rights token to the second node 120b (S23). The request for the generation of a usage rights token may be understood as identical or similar to the operation by which the platform operation server 110 transmits a message to the second node 120b requesting the execution of the second smart contract described later. In various embodiments, the platform operation server 110 can transmit information regarding a pre-processed loan request to the second node 120b in conjunction with the request for the generation of a usage rights token.

[0103] In one embodiment, the entity requesting the generation of usage rights tokens may be a node that executed the first smart contract, rather than the platform operation server 110. Specifically, the platform operation server 110 uses the processed loan request information to cause a specific node included in the blockchain network to execute the first smart contract, and this specific node that executed the first smart contract can transmit a request for the generation of usage rights tokens to the second node 120b based on the information included in the first smart contract that enables the generation of usage rights tokens. In other words, one or more nodes may be included between the platform operation server 110 and the second node 120b, causing them to execute a second smart contract regarding the generation of usage rights tokens in conjunction with the first smart contract regarding the generation of asset tokens.

[0104] The second node 120b can decide whether or not to generate a usage rights token under the first smart contract (S24). Specifically, the second node 120b can decide whether or not to generate a usage rights token based on the information included in the first smart contract that enables the generation of usage rights tokens. For example, the decision to generate a usage rights token may be made by comparing the virtual asset associated with the loan request with the information regarding the loan price of the digital asset included in the first smart contract. In addition to the examples given above, the decision to generate a usage rights token may also be made by comparing the information regarding the loan conditions included in the first smart contract with the information associated with the loan request.

[0105] The second node 120b can generate a right-of-use token based on the loan request information and the second smart contract (S25). Here, the second smart contract can mean a smart contract embodied in the code for generating the right-of-use token. For example, the second smart contract may be embodied by referring to a non-fungible token generation protocol such as ERC-721 or ERC-1155.

[0106] In one embodiment, when a usage right token is generated, the generation information of the usage right token may be recorded in the metadata of the asset token. The generation information of the usage right token may be recorded in the metadata of the asset token through the linkage between the first smart contract and the second smart contract described above. As a result, information regarding the generation information within the attribute information of the asset token's metadata may be recorded cumulatively.

[0107] In other embodiments, when a usage right token is generated, the amount of virtual assets associated with a loan request may be accumulated and recorded in the asset token's metadata. Through the linkage between the first smart contract and the second smart contract described above, the amount of virtual assets associated with a loan request may be accumulated and recorded in the asset token's metadata. This may update the information regarding accumulated revenue within the attribute information of the asset token's metadata.

[0108] By generating a usage right token, the second node 120b can transmit a notification of the generation of the usage right token to the platform operation server 110 (S26). The platform operation server 110 can transmit a notification of the generation of an asset token to the second user terminal 130b (S27). Here, various known technologies may be referenced for the transmission of the notification, and the operation that enables the notification of the generation of a usage right token may be included within the scope of the disclosure in this document. Also, depending on the embodiment, the transmission process of the generation notification (S26, S27) may be omitted.

[0109] In one embodiment, the generated usage token may be transmitted to the wallet address of the user of the digital asset using the second user terminal 130b in conjunction with either of the transmission processes for notifying the generation of the asset token (S26, S27). In another embodiment, the generated usage token may be transmitted to the wallet address of the platform operation server 110. In yet another embodiment, the generated usage token may be transmitted to the wallet address of the user using the second user terminal 130b or the wallet address of the platform operation server 110, regardless of whether the transmission processes for notifying the generation of the asset token (S26, S27) have been performed. For example, even if the transmission processes for notifying the generation of the asset token (S26, S27) are omitted, the generated usage token may be transmitted to the wallet address of the user using the second user terminal 130b or the wallet address of the platform operation server 110 upon generation of the asset token (S25).

[0110] Figure 6 is a diagram showing metadata for a permission token relating to one embodiment of the content disclosed in this document. Referring to Figure 6, the metadata 600 of the permission token may include attribute information 610. The attribute information 610 may include at least some of the following information: the identifier of the permission token (the "Permission Token ID" attribute in Figure 6), the identifier of the asset token corresponding to the permission token (the "Token ID" attribute in Figure 6), the user of the digital asset (the "Owner" attribute in Figure 6), the history of use of the digital asset (the "Used At" attribute in Figure 6), and whether the digital asset can be subleased (the "Binded" attribute in Figure 6). However, in addition to the aforementioned information that may be included in the attribute information 610, further information that can express the attributes of the permission to use the digital asset may also be included. In one embodiment, a usage log may be recorded in the asset token based on the information regarding the history of use of the digital asset recorded in the metadata 600 of the permission token. That is, even if the user does not directly input the usage log into the asset token, the usage log may be recorded in the asset token by referring to the metadata 600 of the permission token.

[0111] In one embodiment, the metadata of the usage rights token may include information indicating the loan period of the digital asset. Since the usage rights token can be a means of proving the right to use the digital asset, proof of usage rights may become impossible upon the expiration of the loan period. Also, since the usage rights token may be transferable, transfer of the usage rights token may become impossible upon the expiration of the loan period. Furthermore, recording of usage logs on the asset token or usage rights token may become impossible upon the expiration of the loan period.

[0112] In one embodiment, the metadata of a usage rights token may include information indicating whether or not the digital asset can be subleased. Such information indicating subleasing is possible may be included in the metadata of the usage rights token in Boolean format (for example, the "Binded" attribute in Figure 6). For example, a usage rights token instructed to be subleasable can be uploaded by the user to the platform and freely traded with other users. For example, a usage rights token instructed not to be subleasable may not be tradable. Such settings regarding subleasing can be implemented by including them in a second smart contract that generates the usage rights token, or by including them in a first smart contract that generates the usage rights token in conjunction with the second smart contract.

[0113] Figure 7 is an exemplary flowchart illustrating a method for recording usage logs according to one embodiment of the content disclosed in this document. The method for recording usage logs according to one embodiment may be a method for recording usage logs on asset tokens corresponding to digital assets. Here, the user of the digital asset can mean the person designated as the user on the usage token. In one embodiment, the owner of the digital asset can also record usage logs on the asset token. In this case, the owner may bear the fees (e.g., gas) incurred for recording usage logs. The method for recording usage logs according to one embodiment has been described below based on the interaction between the platform operating server 110 and the third node 120c of the blockchain network, but other additional nodes may also be involved in recording usage logs.

[0114] The third user terminal 130c can transmit usage logs to the platform operation server 1110 (S31). The third user terminal 130c can mean a terminal used by a licensee of a digital asset, or a terminal used by the owner of a digital asset. Here, the transmission of usage logs may be expressed as uploading usage logs. In this case, the information uploaded to the platform operation server 110 as usage logs may be a string or an image.

[0115] The platform operation server 110 can transmit a usage log recording request to the third node 120c (S32). Specifically, the platform operation server 110 can transmit a usage log recording request to the third node 120c by executing the first smart contract relating to the asset token. The usage log recording request may be understood as identical or similar to the operation in which the platform operation server 110 transmits a message to the third node 120c requesting the commencement of the procedure for recording usage logs.

[0116] The third node 120c can record usage logs (S33). Specifically, the third node 120c can record usage logs in the metadata of the asset token by executing the first smart contract relating to the asset token. Here, the operation of the third node 120c may be understood as recording the usage logs received as a result of the usage log transmission operation (S31) on the web page of the link included in the metadata of the asset token.

[0117] In one embodiment, the usage log may be recorded in the asset token's metadata based on whether the time of use of the digital asset indicated by the usage log falls within the lending period of the digital asset. In other words, use after the lending period constitutes unauthorized use of the digital asset, and therefore may not be recorded as a usage log in the asset token's metadata or the like.

[0118] In one embodiment, usage logs may be recorded in the metadata of an asset token based on whether the transmission of the request to record usage logs occurs within the loan period of the digital asset. Specifically, by utilizing information about the loan period included in the metadata of the usage rights token as a requirement for recording usage logs, it is possible to deactivate the recording of usage logs requested after the loan period has expired.

[0119] In one embodiment, a usage log may be recorded in the metadata of an asset token based on whether the transmission of a request to record a usage log occurs within a usage log recording period determined based on the loan period of the digital asset. Here, the usage log recording period is a period that may be determined by the loan period and can mean a period that is determined periodically or aperiodicly within the loan period, or a predetermined period after the expiration of the loan period.

[0120] In one embodiment, if the user of a digital asset is verified by the verification operation described later, information on the use of the digital asset may be recorded as a usage log in the metadata of the asset token. In this case, the entity recording the usage log may be a user using an external terminal that transmitted the verification request. The external terminal may be a terminal related to the entity that directly uses the digital asset (e.g., a film company, a game company, etc.). A fee for recording the usage log may be levied on this external terminal as payment for verification. The reliability of the usage log may be ensured by having the usage log recorded by the entity that directly uses the digital asset.

[0121] In one embodiment, in response to a user's request to record usage logs, at least a portion of the virtual assets associated with the request to lend digital assets may be transmitted to the user's wallet address.

[0122] The third node 120c can transmit a usage log recording notification to the platform operation server 110 (S34). The platform operation server 110 can transmit a usage log recording notification to the third user terminal 130c (S35). Here, various known technologies may be referenced for the transmission of the notification, and the operation that enables the notification of usage log recording may be included within the scope of the disclosure in this document. Also, depending on the embodiment, the transmission process of the usage log recording notification (S34, S35) may be omitted.

[0123] Figures 8 to 10 illustrate a non-fungible token processing method relating to one embodiment of the content disclosed in this document. These methods may relate to additional operations by a first smart contract or a second smart contract. The steps of these methods may be embodied by one or more instructions executed by the processor of a computing device. Each step included in such a method may be executed by a single physical computing device, but the first step of the method may be performed by the first computing device, and the second step of the method may be performed by the second computing device. In the following description of Figures 8 to 10, it will be assumed that the steps of the methods described above are performed by one of the multiple nodes 120a to 120h of the blockchain network 120.

[0124] Figure 8 is a flowchart showing a method for withdrawing virtual assets using asset tokens according to one embodiment of the content disclosed in this document. The withdrawal of virtual assets using asset tokens may be performed by executing a first smart contract corresponding to the asset token on a node.

[0125] In response to a withdrawal request for an asset token, at least a portion of the virtual assets recorded in the asset token's metadata based on the lending of the digital assets may be transmitted to the wallet address of the asset token owner (S100). The withdrawal request may be a request message received by the node where the first smart contract is executed. For example, the withdrawal request may be transmitted directly from the user terminal or via the platform operating server 110. In response to the withdrawal request, the withdrawal operation may be realized by a withdrawal function defined in the first smart contract. In this way, the asset token owner can generate revenue by lending out the digital assets corresponding to the asset token.

[0126] Figure 9 is a flowchart illustrating a method for verifying a usage rights token according to one embodiment of the content disclosed in this document. Verification of the usage rights token may be performed by querying the block on which the usage rights token is recorded, without transaction consumption.

[0127] In response to a verification request from an external terminal for the usage rights token, the usage rights token may be verified (S200). The verification request may be a message requesting verification of the authenticity of the usage rights by querying the block in which the usage rights token is recorded. For example, the verification request may be transmitted directly from the external terminal to the node, or transmitted to the node via the platform operation server 110. Alternatively, the platform operation server 110, acting as a node, can receive a verification request from an external terminal and verify the usage rights token.

[0128] Specifically, in response to a verification request for a usage rights token, at least some of the nodes 120a to 120h on the blockchain network can compare the metadata of the usage rights token subject to the verification request with the information recorded in the block corresponding to that usage rights token. If the metadata and the information recorded in the block are identical as a result of this comparison, it is determined that the usage rights token is free from abnormalities or defects; otherwise, it may be determined that the usage rights token is abnormal or defective. If the verification of the usage rights token reveals no abnormalities or defects, at least some of the nodes 120a to 120h on the blockchain network can transmit at least some of the asset token address, usage rights token address, usage rights token identifier, user signature, or temporary value to the external terminal that transmitted the verification request, for example, an entity that directly uses the digital asset (e.g., a film company, a game company, etc.) via a second smart contract. In other words, the external terminal can receive the aforementioned information as a result of the verification of the usage rights token. Here, the temporary value is a value that is arbitrarily changed each time a verification request is made, and can be understood as a value that prevents replay attacks that exploit the user's signature. This ensures trust in the use of digital assets by verifying the right to use them using the usage token.

[0129] In one embodiment, an asymmetric key encryption algorithm using a public key and a personal key may be applied to the operation related to the verification request (S200). Specifically, in response to a verification request for a usage rights token, the user terminal of the usage rights holder can encrypt the asset token address, the usage rights token address, or the usage rights token identifier with the personal key and proceed with the digital signature (i.e., the usage rights holder's signature). The user terminal of the usage rights holder can transmit the digitally signed information to at least some of the nodes 120a to 120h on the blockchain network. At least some of the nodes 120a to 120h on the blockchain network can transmit at least some of the asset token address, usage rights token address, usage rights token identifier, usage rights holder's signature, or temporary value to the external terminal that transmitted the verification request via a second smart contract. The external terminal that receives the aforementioned information can decrypt the digitally signed information with the usage rights holder's public key and compare the decrypted information with the information recorded in the block corresponding to the usage rights token. As a result of this comparison, if the decrypted information and the information recorded in the block are identical, it can be determined that the usage token has been verified; if they are not identical, it can be determined that the usage token has not been verified.

[0130] Figure 10 is a flowchart showing a method for transferring a usage rights token according to one embodiment of the content disclosed in this document. Transfer of a usage rights token can mean that the user subleases the usage rights token to another person. Transfer of a usage rights token may be carried out by the execution of a second smart contract corresponding to the usage rights token at the node.

[0131] In response to a transfer request for a usage rights token, the owner of the usage rights token may be changed (S300). The transfer request is a request message received by the node where the second smart contract is executed, and may be transmitted, for example, directly from the user terminal or via the platform operation server 110. Specifically, the information indicating the user included in the metadata of the usage rights token may be changed, for example, the information indicated by the "Owner" attribute shown in Figure 6 may be changed. The ability to transfer usage rights tokens may stimulate the use of digital assets.

[0132] In one embodiment, the node executing the second smart contract relating to the usage rights token can modify the information indicating the user included in the metadata of the usage rights token based on the information regarding the loan period included in the metadata of the usage rights token. For example, the transfer of the usage rights token may be made possible by activating the ownership transfer function of the second smart contract before the loan period of the usage rights token expires. For example, the transfer of the usage rights token may be made impossible by deactivating the ownership transfer function of the second smart contract when the loan period of the usage rights token expires.

[0133] The disclosures in this document indicate that the value of asset tokens guaranteeing digital assets can be increased by recording the usage history of those digital assets in the metadata of those asset tokens. Furthermore, providing users with a platform to trade digital assets can enhance their utilization. The technical effects of the disclosures are not limited to those mentioned above, and any other effects not mentioned should be clearly understood by a typical engineer from the wording of this document.

[0134] In the flowcharts disclosed herein, each step of the method or algorithm is described in a sequential order; however, each step may be performed in any order that can be combined, in addition to being performed sequentially. The descriptions of the flowcharts herein do not preclude changes or modifications to the method or algorithm, nor do they imply that any particular step is essential or preferred. In one embodiment, at least some steps may be performed in parallel, iteratively, or heuristically. In one embodiment, at least some steps may be omitted, and other steps may be added.

[0135] According to at least one embodiment disclosed herein, it is possible to increase the value of non-fungible tokens that guarantee digital assets.

[0136] According to at least one embodiment disclosed herein, the usage history of a digital asset can be represented as a non-fungible token guaranteeing that digital asset.

[0137] According to at least one embodiment disclosed herein, the utilization of digital assets can be enhanced by providing a platform on which digital assets can be lent out.

[0138] According to at least one embodiment disclosed herein, a technology can be provided to prove the right to use a digital asset through lending.

[0139] Various embodiments relating to the content disclosed herein may be embodied as software on a machine-readable storage medium. The software may be software for embodying the various embodiments described herein. The software can be inferred from the various embodiments described herein by a programmer in the art to which the content disclosed herein pertains. For example, the software may be a program containing instructions (e.g., code or code segments) that are readable by a computing device. The device is a device capable of operating in response to instructions called from a storage medium, and may be, for example, a computer. In one embodiment, the device may be a computing device according to one of the various embodiments described herein. In one embodiment, the processor of the device can execute a called instruction and cause the components of the device to perform the function corresponding to this instruction. The storage medium can mean any type of recording medium on which information is stored and is readable by the device. The storage medium may include, for example, ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. In one embodiment, the storage medium may be implemented in a distributed form, such as in a network-connected computer system. The software may be stored and executed in a distributed manner in the computer system. The storage medium may be a non-transitory storage medium. A non-transitory storage medium means a medium that exists regardless of whether the data is stored semi-permanently or temporarily, and does not include signals that are transmitted transiently.

[0140] While the technical concept relating to the disclosures herein has been explained through various embodiments, the technical concept relating to the disclosures herein includes various substitutions, modifications, and alterations that can be understood by a person with ordinary skill in the art to which the disclosures pertain. Furthermore, such substitutions, modifications, and alterations should be understood to be included within the scope of the attached claims.

Claims

1. A communication interface that communicates with at least one node of the blockchain network and an external device, One or more memory locations that store at least one instruction, The communication interface and one or more processors communicatively connected to one or more memories include, The one or more processors execute the at least one instruction, The system receives a lending request from the user's terminal for the digital asset corresponding to the first token. Based on the aforementioned loan request, the system is configured to perform the procedure for generating a second token. The first token is generated based on a first smart contract configured to prove ownership of the digital asset, The first metadata of the first token indicates the owner of the digital asset, The second token is generated based on a second smart contract configured to prove the right to use the digital asset, The second metadata of the second token indicates the user of the digital asset, Based on the generation of the second token, generation information of the second token indicating the lending history of the digital asset is cumulatively recorded in the first metadata of the first token. The aforementioned one or more processors further, From the user's terminal, a usage log (Log) indicating the history of how the digital asset was used is received. Based on the receipt of the usage log, the system is configured to perform a recording procedure in which the usage log for the first token is recorded in the first metadata of the first token. The recording procedure includes an electronic device that transmits a recording request to execute the first smart contract to at least one node of a blockchain network.

2. The second metadata of the second token indicates the lending period of the digital asset, The aforementioned one or more processors further, The electronic device according to claim 1, configured to perform the recording procedure for recording the usage log of the first token based on whether the transmission time of the recording request is within the loan period.

3. The electronic device according to claim 1, wherein, based on the record request, virtual assets corresponding to at least a portion of the virtual assets recorded in the first token are transmitted to the user's wallet address.

4. The electronic device according to claim 1, wherein the usage log includes at least one of the following: information relating to the licensee, information relating to the content on which the digital asset was used, information relating to the manner in which the digital asset was used, or information relating to the time of use of the digital asset.

5. The aforementioned one or more processors further, A verification request for the second token is received from an external terminal distinct from the user terminal. Based on the verification request, the second metadata of the second token and the information recorded in the block corresponding to the second token are compared, Based on the fact that the second metadata of the second token and the information recorded in the block are identical, the system is configured to transmit at least a portion of the first address of the first token, the second address of the second token, the identifier of the second token, the user's signature, or a temporary value to the external terminal. The electronic device according to claim 1, wherein the aforementioned temporary value is a value that is arbitrarily changed based on the receipt of a verification request.

6. The electronic device according to claim 5, wherein, based on the fact that the second metadata of the second token and the information recorded in the block are identical, information indicating the history of use of the digital asset is recorded in the first metadata of the first token as the usage log.

7. The representative image of the aforementioned first token is: The electronic device according to claim 1, which determines one of a plurality of sub-digital assets included in the digital asset based on at least one of a first number of usage logs or a second number of generated information recorded in the first metadata of the first token.

8. The representative image of the aforementioned first token is: The electronic device according to claim 7, which is determined to be one of a plurality of sub-digital assets included in the digital asset based on at least one of the following: a first number and a first additive calculation of the usage period corresponding to the first number, or a second additive calculation of the first number and the loan period corresponding to the first number.

9. The representative image of the aforementioned first token is: Based on whether at least one of the usage logs or generated information recorded in the first metadata of the first token satisfies predetermined conditions, it is determined to be one of a plurality of sub-digital assets included in the digital asset. The electronic device according to claim 1, wherein the predetermined conditions are conditions relating to at least one of the following: information relating to the owner or licensee of the digital asset included in the usage log or the generated information; information relating to content related to the use of the digital asset; or information relating to the manner of use of the digital asset.

10. The procedure for generating the second token is as follows: The electronic device according to claim 1, which is performed based on interaction with at least one node included in the blockchain network.

11. The electronic device according to claim 1, wherein the second metadata of the second token indicates whether or not the digital asset can be subleased.

12. The electronic device according to claim 1, wherein the generated information includes at least one of the following: information regarding the loan period of the digital asset, information regarding the user, information regarding the content on which the digital asset is scheduled to be used, information regarding the planned manner of use of the digital asset, or information regarding the planned time of use of the digital asset.

13. The electronic device according to claim 1, wherein the loan request is accompanied by the operation of transmitting a virtual asset corresponding to the payment for lending the digital asset to the wallet address of the electronic device based on the loan request.

14. Based on the generation of the second token, the amount of the virtual asset is recorded in the metadata of the first token. The aforementioned one or more processors further, The user terminal of the owner of the digital asset receives a withdrawal request for the first token of the virtual asset, The electronic device according to claim 13, configured to transmit a transmission message to at least one node included in the blockchain network, which causes at least a portion of the virtual assets to be transmitted to the owner's wallet address based on the withdrawal request.

15. The aforementioned one or more processors further, The user terminal of the aforementioned user receives a transfer request for the second token, The electronic device according to claim 1, configured to transmit a change message to at least one node included in the blockchain network, which changes the information indicating the user of the second token based on the transfer request.

16. The second metadata of the second token indicates the lending period of the digital asset, The aforementioned one or more processors further, The electronic device according to claim 15, configured to change the information indicating the user of the second token based on whether or not the loan period has expired.

17. The first smart contract includes information that enables the generation of a second token, which includes the lending information of the digital asset as metadata. The electronic device according to claim 1, wherein the lending information of the digital asset indicates the user of the digital asset.

18. A method performed by an electronic device, The process involves receiving a loan request from the user's terminal for the digital asset corresponding to the first token, This includes the step of performing a procedure to generate a second token based on the aforementioned loan request, The first token is generated based on a first smart contract configured to prove ownership of the digital asset, The first metadata of the first token indicates the owner of the digital asset, The second token is generated based on a second smart contract configured to prove the right to use the digital asset, The second metadata of the second token indicates the user of the digital asset, Based on the generation of the second token, generation information of the second token indicating the lending history of the digital asset is cumulatively recorded in the first metadata of the first token. The steps include receiving a usage log from the user's terminal indicating the history of how the digital asset was used, The procedure further includes, based on the receipt of the usage log, a recording procedure that records the usage log for the first token in the first metadata of the first token, The recording procedure is a method that includes transmitting a recording request to execute the first smart contract to at least one node of a blockchain network.

Images