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 in particular to an apparatus and method for processing non-fungible tokens. [Background technology]

[0002] Heritage for a product represents the product's long tradition and history, and creating a heritage for a product is used as a major marketing strategy to increase the value of the product.

[0003] In recent years, with the growing interest in the Metaverse, or augmented virtual world, there has been an increase in interest in digital assets, which are a means of expressing an individual's unique personality within the Metaverse. In particular, there has been an increase in interest in non-fungible tokens, which can prove the authenticity of digital assets. Summary of the Invention [Problem to be solved by the invention]

[0004] [Technical issues] At least some of the subject matter disclosed herein provides techniques for increasing the value of non-fungible tokens that secure digital assets.

[0005] At least a portion of the disclosure herein provides technology that allows the usage history of a digital asset to be represented by a non-fungible token that vouches for that digital asset.

[0006] At least some of the subject matter disclosed herein provides a platform through which digital assets can be rented.

[0007] At least part of the disclosure herein provides techniques for verifying the right to use a digital asset through lending. [Means for solving the problem]

[0008] [Technical solution] According to one aspect of the present disclosure, an electronic device is provided. The electronic device may include a communication interface for communicating with at least one node in a blockchain network and an external device, one or more memories storing at least one instruction, and one or more processors communicatively coupled to the communication interface and the one or more memories. The one or more processors may be configured to execute the at least one instruction to receive, from a user terminal of a user, a loan request for a digital asset corresponding to a first token 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 first metadata of the first token may indicate an owner of the digital asset. The second token is generated based on a second smart contract configured to prove a right to use the digital asset, and second metadata of the second token may indicate a right 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 may be recorded in the first metadata of the first token.

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

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

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

[0012] In one embodiment, the usage log may include at least one of information about the licensee, 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 at which the digital asset was used.

[0013] In one embodiment, the one or more processors are further configured to 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 information recorded in a block corresponding to the second token based on the verification request, and transmit at least a part of the first address of the first token, the second address of the second token, an identifier of the second token, the signature of the authorized user, or a nonce to the external terminal if the second metadata of the second token is identical to the information recorded in the block, wherein the nonce may be a value that is arbitrarily changed based on reception of the verification request.

[0014] In one embodiment, based on the second metadata of the second token being identical to the information recorded in the block, information indicating the history of use of the digital asset 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 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 creation 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 a plurality of sub-digital assets included in the digital asset based on at least one of a first sum of the first number and a usage period corresponding to the first number, or a second sum of the first number and a rental period corresponding to the first number.

[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 log or creation information recorded in the first metadata of the first token satisfies a predetermined condition, and the predetermined condition may be a condition related to at least one of information about the owner or licensee of the digital asset included in at least one of the usage log or creation information, information about content related to the use of the digital asset, or information about the manner of use of the digital asset.

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

[0019] In one embodiment, the second metadata of the second token may indicate whether the digital asset is available for subleasing.

[0020] In one embodiment, the generation information may include at least one of information regarding the rental period of the digital asset, information regarding the licensee, information regarding the content for 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 an operation in which virtual assets corresponding to the payment for the loan of the digital assets are transmitted to a 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 be further configured to receive a withdrawal request for the virtual asset for the first token from a user terminal of the owner of the digital asset, and to transmit a transfer message to at least one node included in the blockchain network based on the withdrawal request, to transfer at least a portion of the virtual asset to a wallet address of the owner.

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

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

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

[0026] According to one aspect of the present disclosure, a method is provided that is performed on an electronic device. The method may include receiving, from a user terminal of a user, a loan request for a digital asset corresponding to a first token, and performing 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 first metadata of the first token may indicate 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 may indicate 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 may be recorded in the first metadata of the first token.

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

[0028] Additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the embodiments presented. [Effects of the Invention]

[0029] At least one embodiment disclosed herein may increase the value of non-fungible tokens that vouch for 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 vouches for the digital asset.

[0031] At least one embodiment disclosed herein can increase the utilization of digital assets by providing a platform through which digital assets can be rented.

[0032] At least one embodiment disclosed herein provides a technique for verifying the right to use a digital asset through lending.

[0033] Other aspects, features, and advantages of particular embodiments of the subject matter disclosed herein will become more apparent from the following description taken in conjunction with the drawings. [Brief explanation of the drawings]

[0034] [Figure 1] 1 is a diagram illustrating an environment in which an apparatus according to one embodiment of the subject matter disclosed herein can be applied. [Figure 2] 1 illustrates a computing device capable of implementing an apparatus according to an embodiment of the subject matter disclosed herein. [Figure 3] 1 is a flowchart illustrating a method for generating asset tokens according to one embodiment of the subject matter disclosed herein. [Figure 4] FIG. 1 illustrates an asset token according to one embodiment of the subject matter disclosed herein. [Figure 5] 1 is a flowchart illustrating a method for generating a usage rights token according to one embodiment of the present disclosure. [Figure 6] 1 illustrates a usage rights token according to one embodiment of the subject matter disclosed herein. [Figure 7] 1 is a flowchart illustrating a method for recording a usage log according to an embodiment of the present disclosure. [Figure 8] 1 is a flowchart illustrating a method for withdrawing virtual assets using asset tokens according to one embodiment of the present disclosure. [Figure 9] 1 is a flowchart illustrating a method for verifying a usage rights token according to one embodiment of the present disclosure. [Figure 10] 1 is a flowchart illustrating a method for transferring a usage right token according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0035] The various examples described in this document are provided for the purpose of clearly explaining the technical idea of ​​this document and are not intended to limit the technical idea to specific embodiments. The technical idea of ​​this document includes various modifications, equivalents, alternatives, and embodiments that selectively combine all or part of the examples described in this document. Furthermore, the scope of the technical idea of ​​this document is not limited to the various examples presented below or the specific descriptions thereof.

[0036] Unless otherwise defined, terms used in this document, including technical or scientific terms, may have the meaning commonly understood by one of ordinary skill in the art to which this document belongs.

[0037] As used in this document, terms such as "comprise," "may include," "comprise," "can comprise," "have," "may have," and the like, imply the presence of a feature (e.g., a function, operation, or component) in question, but do not exclude the presence of additional features. That is, such terms should be understood as open-ended terms that include the possibility of including other embodiments.

[0038] As used in this document, the singular terms "a," "an," and "the" may also include the plural meaning unless the context clearly dictates otherwise, and this also applies to the singular terms used in the claims.

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

[0040] As used in this document, phrases 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 listed item 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) both at least one A and at least one B.

[0041] As used in this document, the phrase "based on" is used to describe one or more factors that influence the decision, act of judgment, or behavior described in the phrase or sentence in which it appears, and does not exclude additional factors that influence that decision, act of judgment, or behavior.

[0042] As used in this document, the expression "coupled" or "connected" to one component (e.g., a first component) to another component (e.g., a second component) can mean that the one component is directly coupled or connected to the other component, or that the one component is further coupled or connected via another component (e.g., a third component).

[0043] As used in this document, the expression "configured to" may have the meanings of "set to," "capable of," "modified to," "made to," "capable of," etc., depending on the context. This expression is not limited to the meaning of "specially designed in terms of hardware." For example, a processor configured to perform a specific operation can mean a general-purpose processor that can perform the specific operation by executing software, or a special-purpose computer that is structured by programming to perform the specific operation.

[0044] Embodiments of the present invention may be described and illustrated in terms of blocks, as shown in the figures, that perform the described functions. Such blocks, which may be referred to herein as units, modules, or the like, or as devices, logic, circuits, counters, comparators, generators, converters, or the like, may be physically embodied by analog and / or digital circuitry including one or more of 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 tasks described herein).

[0045] The term "digital asset" as used herein may refer to any data that is expressed in binary form and can be used as an asset. Digital assets may be, for example, text, two-dimensional images, three-dimensional images, videos, or polygonal graphics. More specifically, digital assets may be text, two-dimensional images, three-dimensional images, videos, or polygonal graphics for clothing, bags, accessories, furniture, vehicles, buildings, real estate, game items, digital cards, or the like. In various embodiments described herein, digital assets may be traded as a single asset having value between owners or licensees, or may be used in various content by owners or licensees. In various embodiments, the authenticity of a digital asset may be guaranteed by a non-fungible token corresponding to the digital asset.

[0046] The term "token" used in this document refers to a token that can be used on a blockchain managed by a blockchain network and may be a non-fungible token. Hereinafter, in the contents disclosed in this document, an object 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 set of data including a specific type of data. In one embodiment, a token may include at least one of information for accessing a digital asset linked to the token (hereinafter also referred to as a "digital asset Uniform Resource Identifier (URI)"), information for accessing token metadata (hereinafter also referred to as a "metadata URI"), or token owner information (e.g., an address of the owner's node on the blockchain (hereinafter also referred to as "information indicating the owner"). In another embodiment, a token may further include the digital asset linked to the token or the token metadata. The digital asset URI linked to the token may be the address of a centralized server or a cloud server where the digital asset is stored. Alternatively, the digital asset URI may be an address of an InterPlanetary File System (IPFS) that stores files in a distributed manner across multiple devices. The token metadata URI may be a hash value (e.g., "ipfs.io / ipfs / 12345678") of the digital asset stored on the IPFS (Internet Protocol File System). The token metadata URI may be the address of a centralized server or cloud server where the token metadata is stored. It may also be a 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, at least one of the token name, token identification information (hereinafter also referred to as "token ID"), the name of a specific object associated with the token, the time of token creation, information about the current token owner, token owner change history, or information for accessing the digital asset linked to the token (i.e., the digital asset URI described above). For an example of expressing any metadata in JSON (JavaScript Object Notation) format, see the description of Figure 4 or Figure 6 below.Hereinafter, in this document, expressions such as "first information possessed by a token," "first information recorded in a token," or "first information included in a token" may be understood as "first information included (or recorded) in the metadata of a token."

[0048] As used in this document, the term "smart contract" may refer to a program or application that runs on a virtual machine (VM) executed by one or more nodes in a blockchain network. A smart contract may be created to comply with certain rules (or protocols). For example, a smart contract may be created by referencing ERC-20, ERC-721, or ERC-1155, and including one or more functions corresponding to each protocol. However, any number of different types of smart contracts may be created by including other functions not included in the illustrated protocols.

[0049] The term "usage log" as used herein may refer to a record of the usage history of a digital asset when the digital asset is used in content. Specifically, a "usage log" may include at least one of information about the owner or licensee of the digital asset who used the digital asset, information about the content in which the digital asset was used, information about the usage pattern of the digital asset, or information about the time of use of the digital asset. The content may be symbols, characters, figures, colors, voices, sounds, images, videos, or a combination thereof, such as a movie, drama, game, audio clip, or video clip. The usage pattern of a digital asset may refer to the overall appearance, form, or arrangement of the digital asset when used in content, or may refer to the image or audio in the content when the digital asset is used.

[0050] The usage behavior may also include dynamic changes of the digital asset due to interactions with other objects in the content. For example, if a digital asset is used in a movie, the usage log may include the title of the movie, the scene in which the digital asset is used, the position or duration of that scene on the timeline of the entire movie, or the date on which the digital asset was used in the movie. For example, if a digital asset is used in a game, the usage log may include the title of the game, the position of the digital asset on the game map, the date on which 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 the metaverse, the usage log may include the name of the platform, a list of user accounts on the platform that used the digital asset, the position of the digital asset in the metaverse, or the date on which it was used in the metaverse. In addition to the above examples, a digital asset that can be recorded in the form of a character string or an image may also be included in the usage log.

[0051] The term "subleasing" as used in this document may refer to the act of a user who has borrowed a digital asset (i.e., a licensee of the digital asset) lending the digital asset to another user. Because the lending of digital assets disclosed herein is based on a usage rights token, such "subleasing" may be implemented, for example, by changing the information indicating the licensee included in the metadata of the usage rights token.

[0052] Hereinafter, various embodiments described in this document will be described with reference to the accompanying drawings. In the accompanying drawings and descriptions relating to the drawings, identical or substantially equivalent components may be designated by the same reference numerals. In addition, in the following descriptions of various embodiments, repeated descriptions of identical or corresponding components may be omitted, but this does not mean that the components are not included in the embodiments.

[0053] FIG. 1 illustrates an environment in which an apparatus according to an embodiment of the present disclosure can be applied. This environment may include a platform operating server 110, a blockchain network 120 including multiple nodes (e.g., 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 (e.g., a first user terminal 130a, a second user terminal 130b, and a third user terminal 130c; hereinafter, referred to as 130). While FIG. 1 illustrates an example in which one or more user terminals 130 and multiple nodes 120a-120h are connected to the platform operating server 110 via a network, this is merely for ease of understanding, and the number of user terminals and nodes may be varied.

[0054] The platform operating server 110 may be a server that implements a platform for supporting digital asset transactions based on non-fungible tokens. The platform operating server 110 may be a device associated with an entity that operates the platform. The platform operating server 110 may perform various processes on non-fungible tokens associated with digital assets to support digital asset transactions. For example, the platform operating server 110 may receive digital assets from a first user terminal 130a and perform a procedure for generating a token (e.g., an asset token) that can prove ownership of the digital assets. As another example, the platform operating server 110 may receive a request for lending digital assets from a second user terminal 130b and perform a procedure for generating a token (e.g., a usage right token) that can prove the right to use the digital assets. In the above example, the generation procedure may include an operation in which the platform operating server 110 transmits a generation request to at least one node 120a-120h included in the blockchain network 120. A specific description of the generation procedure will be given below with reference to FIG. 3 or FIG.

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

[0056] In addition to the above examples, the platform operation server 110 may perform various operations required for a trading platform for non-fungible token-based digital assets. For example, the platform operation server 110 may store and manage tokens (e.g., asset tokens or usage rights tokens) received from the user terminal 130 and provide a user with a user interface (UI) for managing tokens. Furthermore, the platform operation server 110 may perform a token purchase or sale procedure in response to a token purchase or sale request from the user terminal 130. That is, the platform operation server 110 may operate as a platform that relays between token sellers and buyers. In one embodiment, virtual assets may be required as a counter-payment for the tokens to initiate a token purchase or sale procedure performed by the platform operation server 110. In one embodiment, tokens may be transferred from a seller's wallet address to a buyer's wallet address as a result of a purchase or sale procedure performed by the platform operation server 110.

[0057] In addition, the platform operation server 110 may interact with the nodes 120a to 120h included in the blockchain network 120 to participate in generating tokens or recording usage logs.

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

[0059] The blockchain network 120 may include one or more nodes 120a to 120h that manage a blockchain. A block may represent a specific data type. Also, a blockchain may represent a data structure in which one or more blocks are linked in the form of a chain. One or more blocks included in the blockchain may be stored independently in each of the multiple nodes 120a to 120h included in the blockchain network 120, or 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 at least one of the following: software or protocol version information, a hash of the transfer block based on the order of block concatenation on the blockchain, a Merkle root, time information indicating the time the block was generated, bits indicating the difficulty of computation, or a nonce, which is a value required for mining to add a new block to the blockchain. The block body may include at least one transaction. A transaction is a collection of data with a specific data structure and may be a unit of information stored in the block body. A transaction may include information regarding the generation or trading of a token. For example, a transaction may be information stating that a first node 120a included in the blockchain network 120 transmits a token to a second node 120b. As another example, a transaction may be information stating that a first node 120a included in the blockchain network 120 transmits a non-fungible token to a second node 120b.

[0060] Each of the at least one node 120a-120h included in the blockchain network 120 may be referred to as a "participant" of the blockchain network 120. The at least one node 120a-120h included in the blockchain network 120 may operate according to a hierarchical structure. This hierarchical structure may include, for example, at least one of a data layer that defines the structure of data handled by the blockchain network 120 and manages the data, a consensus layer that verifies the validity of blocks, performs mining to generate blocks, and handles fees paid to miners during the mining process, a common layer that implements or manages a P2P network protocol, a hash function, a digital signature, encoding, and a common storage, or an application layer where various applications are created or processed.

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

[0062] Each of at least one node 120a to 120h included in the blockchain network 120 may store a smart contract. Accordingly, at least one node 120a to 120h included in the blockchain network 120 may share the same smart contract. The smart contract may be recorded in a block on the blockchain managed by the blockchain network 120. A smart contract may be a document or script written in a programming language such as Solidity, or a program or application running on a virtual machine executed by at least one node 120a to 120h included in the blockchain network 120. A smart contract may be created to execute a specific action when a specific condition is met. In this case, the specific condition may be, for example, input of a specific type of token or a file in a specific format. The specific action may be, for example, transmitting a specific type of token to any node in the blockchain network 120.

[0063] The nodes 120a to 120h may be full nodes, light nodes, master nodes, mining nodes, random nodes, baking nodes, super nodes, etc. Depending on the operation performed by the node, the nodes 120a to 120h may generate tokens (e.g., asset tokens, usage rights tokens) or record usage logs by interacting with the platform operation server 110.

[0064] The nodes 120a to 120h may be implemented as computing devices, such as, but not limited to, a desktop, a laptop, an application server, a proxy server, a cloud server, etc., and may include any type of device equipped with computing capabilities.

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

[0066] The platform operation server 110, the nodes 120a to 120h, and the user terminal 130 can communicate through a network. The network may be implemented as any type of wired or wireless network, such as a local area network (LAN), a wide area network (WAN), a mobile radio communication network, or wireless broadband internet (Wibro).

[0067] Meanwhile, the platform operation server 110, the nodes 120a to 120h, and the user terminal 130 represent functionally distinct elements. That is, two or more components may be embodied in an integrated form in an actual physical environment. For example, the platform operation server 110 and any one of the nodes 120a to 120h may be embodied in the form of different logic within the same computing device. That is, the platform operation server 110 may be embodied to also operate as the nodes 120a to 120h of the blockchain network 120.

[0068] FIG. 2 illustrates a computing device 200 capable of implementing an apparatus according to an embodiment of the present disclosure. In the present disclosure, the computing device 200 may be referred to as an electronic device, and the terms computing device 200 and electronic device may be used interchangeably. The platform operation server 110, nodes 120a-120h, and user terminal 130 described above may be implemented by this computing device. The computing device 200 may include one or more processors 210 or one or more memories 220. In an embodiment, some components may be omitted from the computing device 200, and other components (e.g., a display) may be added to the computing device 200. Additionally or alternatively, some components may be integrated or implemented as a single or multiple individual components. In the present disclosure, one or more processors 210 may be referred to as a processor 210. Unless otherwise specified in the context, the term processor 210 may refer to a collection of one or more processors. Additionally, in the context of this disclosure, one or more memories 220 may be referred to as memories 220. Such reference to memories 220 may refer to a collection of one or more memories, unless the context dictates otherwise.

[0069] At least some of the components in the computing device 200 may be connected to each other via a bus, a general purpose input / output (GPIO), a serial peripheral interface (SPI), a mobile industry processor interface (MIPI), or the like, and may exchange data or signals.

[0070] The processor 210 may perform calculations and data processing related to control or communication with each component of the computing device 200. Specifically, the processor 210 may 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 may load instructions or data into the memory 220, process the instructions or data stored in the memory 220, and store the resulting data from the processing in the memory 220. The processor 210 may also be operatively connected to the components of the computing device 200 to perform various calculations, processing, data generation, processing, and other operations related to the contents disclosed herein.

[0071] The memory 220 may store various data. The data stored in the memory 220 may be 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, the memory 220 may store instructions for the operation of the processor 210 as a computer program. Here, the computer program may include one or more instructions that, when loaded into the memory 220, cause the processor 210 to perform operations according to various embodiments of the subject matter disclosed herein. That is, the processor 210 may perform operations according to various embodiments of the subject matter disclosed herein by executing one or more of the instructions. The memory 220 may also include volatile or non-volatile memory. In one embodiment, the instructions or programs are software stored in the memory 220 and may include an operating system for controlling the resources of the computing device 200, applications, or middleware that provides various functions to applications so that the applications can utilize the resources of the computing device 200.

[0072] In one embodiment, the computing device 200 may further include a communication interface 230. The communication interface 230 may also be referred to as a network interface. The communication interface 230 may establish a wired or wireless communication channel with an external device (e.g., each of the nodes 120a to 120h or each of the user terminals 130) and transmit and receive various data to and from the external device. In one embodiment, the communication interface 230 may include at least one port for connecting to an external device via a wired cable for wired communication with the external device. In this case, the communication interface 230 may communicate with the wired external device through the 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 and can transmit and receive data to and from an external device using short-range communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), or UWB). In one embodiment, the communication interface 230 may include a contactless communication module for contactless communication. Here, the contactless communication may include at least one contactless proximity communication technology, such as near field communication (NFC), radio frequency identification (RFID), or magnetic secure transmission (MST). 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 disclosure herein is not limited to the examples described above.

[0073] In one embodiment, the computing device 200 may further include a display. Here, the display may display various screens under the control of the processor 210. For example, the display may display the results of reading a usage log recorded in the metadata of an asset token under the control of the processor 210. In this case, for example, a web browser or a dedicated application may be installed in the computing device 200 to display the results of reading the usage log on the display. In one embodiment, the web browser or dedicated application may be implemented to provide a user with a user interface to request the generation of tokens (e.g., asset tokens, usage rights tokens) corresponding to digital assets, to trade digital assets, and the like. In addition, the display is configured to be capable of interacting with a user, and may display various screens and receive user inputs under the control of the processor 210. 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, styluses, etc.). Here, the touch sensor panel may have various structures and types, and the disclosure herein is applicable to all of them regardless of the structure and type of the touch sensor panel.

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

[0075] Figures 3, 5, 7, and 8-10 illustrate a non-fungible token processing method according to an embodiment of the present disclosure. While the illustrated non-fungible token processing methods are described as having a specific order of operations, depending on the embodiment, the operations may not necessarily be performed in the illustrated order or sequential order, or all operations may not be performed. Also, while the steps of the non-fungible token processing methods illustrated in Figures 3, 5, and 7 are shown as being performed by different actors, any number of permissible variations in the actors may be possible. For example, the platform operating server 110 may be integrated with any one of the nodes 120a-120h of the blockchain network 120 to perform all of the operations of the platform operating server 110 and the node.

[0076] FIG. 3 is an exemplary flowchart illustrating a method for generating an asset token according to one embodiment of the present disclosure. The asset token generation method illustrated in FIG. 3 involves a user uploading a digital asset to a platform and generating an asset token corresponding to the digital asset. The 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 to the digital asset, and metadata of the asset token may include information indicating the owner of the digital asset. In the present disclosure, the asset token may be referred to as a first token.

[0077] In the disclosure herein, the generation of asset tokens may be understood as minting of asset tokens. Therefore, any known minting-related technology not described herein may be applied to the disclosure herein. For convenience of explanation, the process of generating asset tokens through interaction between the platform operating server 110 and the first node 120a of the blockchain network 120 has been described. However, additional nodes may also be involved in the generation of asset tokens to generate asset tokens. Alternatively, the platform operating server 110 and the first node 120a may each be embodied as logic within a single computing device. In other words, the platform operating server 110 and the first node 120a may be embodied as a single, undivided device, thereby performing the procedure for generating asset tokens.

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

[0079] The platform operating server 110 may preprocess information about the digital asset (S12). Here, preprocessing may refer to an operation of extracting, processing, or modifying at least a portion of the digital asset and information about the digital asset received from the first user terminal 130a, and then storing the extracted digital asset and information about the digital asset again in the platform operating server 110 in order to proceed with the asset token generation procedure. That is, preprocessing may be understood as an operation of processing the digital asset and information about the digital asset so as to conform to a generation protocol for generating an asset token. For example, the platform operating server 110 may extract some of the metadata (e.g., digital asset extension, digital asset address, etc.) of the received digital asset. For example, the platform operating server 110 may extract, delete, or modify at least a portion of the information about the received digital asset. For example, the platform operating server 110 may store the received digital asset in storage (e.g., distributed storage (IPFS), centralized storage (S3), etc.). In addition to the above examples, the platform operation server 110 may perform all operations for preprocessing information about digital assets in a format required by the asset token generation protocol, although preprocessing information about digital assets (S12) may be omitted depending on the embodiment.

[0080] The platform operating server 110 may transmit a request to generate an asset token to the first node 120a (S13). The request to generate an asset token may be understood to be the same as or similar to the operation of the platform operating server 110 transmitting a message to the first node 120a requesting execution of a first smart contract, which will be described later. In various embodiments, the platform operating server 110 may transmit information about the pre-processed digital asset to the first node 120a along with the request to generate an asset token.

[0081] The first node 120a may generate asset tokens based on information about the digital asset and the 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 predetermined conditions and executes a pre-set action when the conditions are met. Here, the first smart contract may refer to a smart contract embodied in code for generating asset tokens. For example, the first smart contract may be implemented with reference to ERC-721 or ERC-1155, which are protocols for generating non-fungible tokens.

[0082] In one embodiment, the first smart contract may be created so that information indicating the usage history of a digital asset corresponding to an asset token (hereinafter referred to as a "usage log") is recorded in the metadata of the asset token. In one embodiment, the usage log may be cumulatively recorded on a webpage linked to 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 a usage log of the digital asset corresponding to the asset token. In another embodiment, the first smart contract may include information for generating a usage rights token. Here, the metadata of the usage rights token may include information for indicating a user of the digital asset (e.g., a user who borrowed the digital asset and a user who sub-lent the digital asset). A user of the digital asset can prove their usage rights using the usage rights token. Here, the information for generating a usage rights token may include, for example, information for executing a procedure for generating a usage rights token in response to a request to lend a digital asset or information regarding the price required to lend a digital asset.

[0083] In yet another embodiment, the first smart contract may be created such that, when a usage rights token is generated using information capable of generating a usage rights token, generation information of the usage rights token is recorded in the metadata of the asset token. In one embodiment, the generation information may be cumulatively recorded in a 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, generation information may be cumulatively recorded in the metadata of the asset token generated based on the first smart contract as usage rights tokens are generated. For example, generation information of the usage rights token may be recorded in the asset token each time a usage rights token is generated. The generation information of the usage rights token may include various information. For example, information regarding the rental period of the digital asset, information regarding the licensee of the digital asset, information regarding the content for 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 character string or an image as the generation information of the usage rights token. As another example, the generation information may be information indicating the fact that a usage rights token has been generated, or information indicating the number of times a usage rights token has been generated. For example, when the first usage rights token is generated, the generation information may have a value of 1, and may be changed to have an accumulated value each time a usage rights token is generated thereafter.

[0084] Since the lending of digital assets according to the disclosure herein is based on usage rights tokens, the generation information of such usage rights tokens may be information indicating the history of 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 lending digital assets and information regarding the generation of the usage rights tokens 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 a usage log. Since recording a usage log in the metadata of an asset token generates a fee (e.g., gas) due to the execution of the smart contract, the recording of a usage log can be encouraged by providing an incentive for recording a usage log. Here, the provision of an incentive may be, for example, an action of transferring a portion of the fee for the loan to the wallet address of the user who records the usage log. However, the scope of the disclosure herein is not limited thereto, and any action for encouraging the recording of a usage log may be included in the scope of the disclosure herein.

[0086] The first node 120a may transmit a notification of asset token generation to the platform operating server 110 (S15). The platform operating server 110 may transmit a notification of asset token generation to the first user terminal 130a (S16). The processes of transmitting the notification of generation (S15, S16) may be performed using various known technologies, and the operation of notifying the generation of an asset token may be included in the scope of the disclosure of this document. Also, depending on the embodiment, at least some of the processes of transmitting the notification of generation (S15, S16) may be omitted.

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

[0088] FIG. 4 illustrates metadata of an asset token according to an embodiment of the present disclosure. The asset token metadata 400 may include attribute information 410. The attribute information 410 may include at least some of the following information: an asset token identifier (the “Token ID” attribute in FIG. 4 ), a URI or URL address of the digital asset, a storage address where the digital asset is stored (the “File URI” attribute in FIG. 4 , e.g., IPFS), an owner of the digital asset (the “Owner” attribute in FIG. 4 ), the price required to lend the digital asset (the “Asset Permission Price” attribute in FIG. 4 ), whether the digital asset can be sublet (the “Binded” attribute in FIG. 4 ), and the profits accumulated from lending the digital asset (the “Total Profit” attribute in FIG. 4 ). In addition to the aforementioned information, the attribute information 410 may further include any information capable of expressing the attributes of the digital asset.

[0089] In one embodiment, the asset token metadata 400 may further include generation information of the usage rights token. The generation information recorded upon generation of the usage rights token, i.e., upon lending of the digital asset, can form a unique heritage for the digital asset. The asset token metadata 400 may also include one or more usage logs 420. The usage logs 420 may be accumulated and recorded in the asset token metadata 400 upon use of the digital asset corresponding to the asset token metadata 400. 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 webpage where the usage logs are recorded. In this case, the entered usage logs can be confirmed by connecting to the URLs according to the usage logs 420 recorded in the asset token metadata 400. The recorded one or more usage logs 420 can form a unique heritage for the digital asset.

[0090] In one embodiment, the representative image of an asset token may be determined as one of multiple sub-digital assets included in a digital asset based on the number of usage log entries or usage token generation information recorded in the asset token metadata. For example, the representative image of an asset token may be determined based on the number of usage log entries or usage token generation information associated with the asset token. As another example, the representative image of an asset token may be determined based on the sum or additive combination of the number of usage log entries and the number of usage token generation information associated with the asset token. Here, multiple sub-digital assets may refer to multiple subordinate digital assets that have common attributes and can be grouped together as a single digital asset. For example, if a person's portrait is a digital asset, the sub-digital assets of the portrait may include a childhood portrait, a youth portrait, a middle-aged portrait, and an old age portrait. For example, if a chair image is a digital asset, the sub-digital assets of the chair image may include a new chair image, a stained chair image, and an old chair image. For example, if a stained image is a digital asset, the sub-digital assets of the image may include multiple images in which at least a portion of the image has been transformed. Such transformations may refer to any transformation of the original image, such as adding or changing a shape, changing a color, 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 number of usage logs or the generation information of the usage rights token). Technology related to dynamic non-fungible tokens (NFTs) may be referenced for determining the representative image. Changing the representative image of the asset token according to the generation information or the number of usage logs of the usage rights token allows the asset token to be represented in a variety of ways, thereby further increasing the value of the asset token. For example, a person's portrait may change from a childhood portrait to an elderly portrait according to the generation information or the number of usage logs of the usage rights token.For example, as the number of usage right token generation information 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 another embodiment, the representative image of an asset token may be determined as one of multiple sub-digital assets included in a digital asset based on the number of pieces of generation information recorded in the metadata of the asset token and the cumulative sum of the lending periods corresponding to the pieces of generation information. For example, if the lending period of the first generation information is one week and the lending period of the second generation information is one day, the first weight applied to the first generation information may be set to be greater than the second weight applied to the second generation information. Thus, even if two pieces of generation information are recorded for "token A" and "token B," the representative image of the token with the longer total lending period may change more quickly. According to this embodiment, the representative image of the asset token can be changed by taking into account not only the number of pieces of generation information but also the lending period corresponding to each piece of generation information. In other words, the representative image of the asset token can be changed by taking into account not only the number of times the digital asset has been lent but also the lending time.

[0092] In yet another embodiment, the representative image of an asset token may be determined as one of multiple sub-digital assets included in a digital asset based on the number of usage logs recorded in the metadata of the asset token and the cumulative sum of the usage periods corresponding to the usage logs. The usage period may refer to the period of use of the digital asset corresponding to the usage log. For example, if the rental period of a digital asset is one month and the usage period for the digital asset used with specific content is one week, this may be understood as meaning that the digital asset was rented for a total of one month and used with the specific content for one week within the rental period. That is, according to this example, the usage period corresponding to the usage log may be one week. As a specific example related to the cumulative sum, if the usage period of a first usage log is one week and the usage period of a second usage log is one day, the first weight applied to the first usage log may be set to be greater than the second weight applied to the second usage log. As a result, even if two usage logs are recorded for "token A" and "token B," the representative image of the token with the longer total usage period may change more quickly. 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, and the representative image of the asset token can be changed. In other words, the representative image of the asset token can be changed taking into consideration not only the number of times the digital asset has been used, but also the duration of use.

[0093] In yet another embodiment, the representative image of an asset token may be determined as one of a plurality of sub-digital assets included in a digital asset based on whether a usage log (or generation information of a usage rights token) recorded in the metadata of the asset token satisfies a specific condition. 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 a specific condition, a weighted value may be assigned to the usage log (or generation information) to calculate the total number of usage logs (or generation information). Furthermore, 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 a specific condition, a sub-digital asset corresponding to the specific condition may be determined as the representative image.

[0094] Here, the specific condition may be a condition related to information about the owner or licensee of the digital asset who used the digital asset. For example, the specific condition may be a condition that a person belonging to "Group A" (e.g., the top 100 people this year) uses the digital asset and is recorded in a usage log. If there is a usage log in which a person belonging to "Group A" uses the digital asset as the owner or licensee, 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 (a condition in which a person belonging to "Group A" uses the digital asset and is recorded in a 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 a "group" lends out the digital asset and usage token generation information is recorded.

[0095] The specific condition may be a condition related to information about content in which a digital asset is used. For example, the specific condition may be a condition in which a digital asset is used in content belonging to "Group B" (e.g., a film nominated for a film festival) and recorded in a usage log. If there is a usage log in which a 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 (a condition in which a digital asset is used in content belonging to "Group B" and recorded in a usage log) may be determined as a representative image. As another example, the specific condition may be a condition in which a digital asset is scheduled to be used in content belonging to "Group B" and recorded in the generation information.

[0096] Other specific conditions may be conditions relating to information on how the digital asset is used (e.g., a condition that the digital asset is used in a specific type of content (e.g., a movie, a drama, a game, an audio clip, etc.) and recorded in a usage log (or generation information)), or conditions relating to information on the time of use of the digital asset (e.g., a condition that the digital asset is used until a specific date and recorded in a usage log (or generation information)). The specific conditions may be a combination of at least some of the above-mentioned conditions.

[0097] In relation to this embodiment, information for determining whether a specific condition is satisfied may be pre-stored in the memory 220 of the platform operating server 110. In addition, the platform operating server 110 may receive information for determining whether a specific condition is satisfied from an external database. In this case, the information for determining whether a specific condition is satisfied may be pre-stored in the external database. For example, the information for determining whether a specific condition is satisfied may include at least some of information about people belonging to "Group A," information about content belonging to "Group B," information about content of a specific type, or information about a specific date.

[0098] FIG. 5 is an exemplary flowchart illustrating a method for generating a usage rights token according to an embodiment of the present disclosure. The usage rights token generation method according to an embodiment relates to generating a usage rights token for a digital asset uploaded to a platform for lending the digital asset. Here, the usage rights token may be a non-fungible token that corresponds one-to-one to a lending request for the digital asset. In one embodiment, the usage rights token may include lending information (e.g., information about the digital asset's licensee, information about the lending period, etc.). In the present disclosure, the usage rights token may be referred to as a second token. The generation of the usage rights token may be understood as minting the usage rights token.

[0099] Although the operation of generating a usage right token through interaction between the platform operating server 110 and the second node 120b of the blockchain network is described, any number of additional nodes may be involved in generating the usage right token. Alternatively, the platform operating server 110 and the second node 120b may be implemented in the form of different logic within the same computing device. That is, the platform operating server 110 and the second node 120b may be implemented as a single, undivided device to perform the procedure of generating a usage right token.

[0100] The second user terminal 130b may transmit a lending request to the platform operating server 110 (S21). The second user terminal 130b may refer to a terminal used by a user who desires to lend a digital asset. The lending request may be understood to be the same as or similar to an operation in which the second user terminal 130b transmits a message requesting the platform operating server 110 to start a procedure for lending a digital asset. In this case, along with the lending request, at least some of the following may be transmitted from the second user terminal 130b to the platform operating server 110 as information on the lending request: information on the user who made the lending request; information on the lending period; information on the intended use of the digital asset (e.g., the content intended to be used, the intended manner of use, the intended time of use, etc.); or information on the digital asset that is the subject of the lending request. In this case, the information on the lending request transmitted along with the lending request may be used to generate a usage rights token, so that the usage rights token may be generated to include at least some of the above information as metadata. In addition, in response to the lending request, virtual assets to pay for the lending of the 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 operating server 110.

[0101] The platform operating server 110 may pre-process information related to the rental request (S22). Here, pre-processing may refer to an operation of extracting, processing, or modifying at least a portion of the information related to the rental request received from the second user terminal 130b, and then storing the extracted information in the platform operating server 110 in order to perform a usage rights token generation procedure. That is, pre-processing may be understood as an operation of processing information related to the rental request in accordance with a generation protocol for generating a usage rights token. For example, the platform operating server 110 may extract, delete, or modify at least a portion of the information related to the rental request. In addition to the above examples, the platform operating server 110 may perform various operations for pre-processing information related to the rental request, and may perform an operation for pre-processing information related to the rental request in a format required by the usage rights token generation protocol. However, depending on the embodiment, the pre-processing of information related to the rental request (S22) may be omitted.

[0102] The platform operating server 110 may transmit a request for generating a usage right token to the second node 120b (S23). The request for generating a usage right token may be understood to be the same as or similar to the operation of the platform operating server 110 transmitting a message requesting the execution of a second smart contract, which will be described later, to the second node 120b. In various embodiments, the platform operating server 110 may transmit information regarding the preprocessed lending request to the second node 120b along with the request for generating a usage right token.

[0103] In one embodiment, the entity making the request to generate a usage right token may be the node that executed the first smart contract, rather than the platform operating server 110. Specifically, the platform operating server 110 causes a specific node included in the blockchain network to execute the first smart contract using information about the processed lending request, and the specific node that executed the first smart contract may transmit a request to generate a usage right token to the second node 120b based on information for generating the usage right token included in the first smart contract. In other words, one or more nodes may be included between the platform operating server 110 and the second node 120b, and may execute a second smart contract related to the generation of a usage right token in conjunction with the first smart contract related to the generation of an asset token.

[0104] The second node 120b may determine whether to generate a usage right token according to the first smart contract (S24). Specifically, the second node 120b may determine whether to generate a usage right token based on information for generating a usage right token included in the first smart contract. For example, the second node 120b may determine whether to generate a usage right token by comparing the virtual assets included in the lending request with information on the lending price of the digital assets included in the first smart contract. In addition to the above examples, the second node 120b may determine whether to generate a usage right token by comparing information on the lending conditions included in the first smart contract with information included in the lending request.

[0105] The second node 120b may generate a usage right token based on the information about the loan request and the second smart contract (S25). Here, the second smart contract may refer to a smart contract implemented as code for generating a usage right token. For example, the second smart contract may be implemented with reference to ERC-721 or ERC-1155, which are protocols for generating non-fungible tokens.

[0106] In one embodiment, when a usage right token is generated, 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. As a result, information related to the generation information may be cumulatively recorded in the attribute information of the metadata of the asset token.

[0107] In another embodiment, when the usage rights token is generated, the amount of virtual assets accompanying the lending request may be accumulated and recorded in the metadata of the asset token. By linking the first smart contract and the second smart contract described above, the amount of virtual assets accompanying the lending request may be accumulated and recorded in the metadata of the asset token. As a result, information regarding accumulated revenue in the attribute information of the metadata of the asset token may be updated.

[0108] Upon generating the usage rights token, the second node 120b may transmit a notification of the generation of the usage rights token to the platform operating server 110 (S26). The platform operating server 110 may transmit a notification of the generation of the asset token to the second user terminal 130b (S27). Here, various known techniques may be referenced for transmitting the notification, and the operation of notifying the generation of the usage rights token may be included within the scope of the disclosure of this document. Also, depending on the embodiment, the processes of transmitting the generation notification (S26, S27) may be omitted.

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

[0110] FIG. 6 is a diagram illustrating metadata of a usage rights token according to an embodiment of the present disclosure. Referring to FIG. 6, the metadata 600 of the usage rights token may include attribute information 610. The attribute information 610 may include at least some of information on the identifier of the usage rights token (the “Permission Token ID” attribute in FIG. 6), the identifier of the asset token corresponding to the usage rights token (the “Token ID” attribute in FIG. 6), the user of the digital asset (the “Owner” attribute in FIG. 6), the usage history of the digital asset (the “Used At” attribute in FIG. 6), and whether the digital asset can be sublet (the “Binded” attribute in FIG. 6). However, in addition to the above-mentioned information that may be included in the attribute information 610, information that can express attributes of the usage rights of the digital asset may also be included. In one embodiment, a usage log may be recorded in the asset token based on information on the usage history of the digital asset recorded in the metadata 600 of the usage rights token. That is, the usage log may be recorded in the asset token by referring to the metadata 600 of the usage rights token, even if the user or the like does not directly input the usage log in the asset token.

[0111] In one embodiment, the metadata of the usage rights token may include information indicating a rental period for the digital asset. Because the usage rights token may be a means for proving the right to use the digital asset, the expiration of the rental period may render the right to use unprovable. Furthermore, because the usage rights token may be transferable, the expiration of the rental period may render the transfer of the usage rights token unprovisionable. Furthermore, the expiration of the rental period may render the recording of usage logs in the asset token or the usage rights token unprovisionable.

[0112] In one embodiment, metadata of a usage rights token may include information indicating whether the digital asset can be subleased. Such information indicating whether subleasing is permitted may be included in the metadata of the usage rights token in Boolean format (e.g., the "Binded" attribute in FIG. 6). For example, a usage rights token designated as subleasable may be uploaded by a licensee to the platform and freely traded with other users. For example, a usage rights token designated as not subleasable may not be tradeable. Such a subleasable setting may be included and embodied in a second smart contract that generates usage rights tokens, or in a first smart contract that generates usage rights tokens in conjunction with the second smart contract.

[0113] FIG. 7 is an exemplary flowchart illustrating a method for recording a usage log according to an embodiment of the present disclosure. The usage log recording method according to an embodiment may be a method for recording a usage log in an asset token corresponding to a digital asset. Here, a digital asset licensee may refer to a person designated as a licensee in the usage token. In one embodiment, the owner of the digital asset may also record a usage log in the asset token. In this case, fees (e.g., gas) incurred for recording the usage log may be borne by the owner. While the usage log recording method according to an embodiment has been described below based on the interaction between the platform operation server 110 and the third node 120c of the blockchain network, additional nodes may also be involved in recording the usage log.

[0114] The third user terminal 130c may transmit a usage log to the platform operating server 1110 (S31). The third user terminal 130c may refer to a terminal used by a licensee of a digital asset or a terminal used by an owner of the digital asset. Here, transmitting the usage log may be expressed as uploading the usage log. At this time, the information uploaded to the platform operating server 1110 as the usage log may be a character string or an image.

[0115] The platform operating server 110 may transmit a usage log recording request to the third node 120c (S32). Specifically, the platform operating server 110 may transmit the usage log recording request to the third node 120c by executing the first smart contract related to the asset token. The usage log recording request may be understood to be the same as or similar to the operation of the platform operating server 110 transmitting a message requesting the third node 120c to start a procedure for recording a usage log.

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

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

[0118] In one embodiment, a usage log may be recorded in the metadata of the asset token based on whether the transmission time of the request to record the usage log is within the rental period of the digital asset. Specifically, by using information about the rental period included in the metadata of the usage right token as a requirement for recording the usage log, the recording of the usage log requested after the rental period has expired may be deactivated.

[0119] In one embodiment, a usage log may be recorded in the metadata of the asset token based on whether the transmission time of the usage log recording request is within a usage log recording period determined based on the rental period of the digital asset. Here, the usage log recording period may be a period that may be determined based on the rental period, and may be a period that is determined periodically or aperiodically within the rental period, or may be a predetermined period after the expiration of the rental period.

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

[0121] In one embodiment, in response to a licensee's usage log recording request, at least a portion of the virtual assets accompanying the digital asset lending request may be transmitted to the licensee's wallet address.

[0122] The third node 120c may transmit a notification of the usage log record to the platform operating server 110 (S34). The platform operating server 110 may transmit a notification of the usage log record to the third user terminal 130c (S35). Here, various known techniques may be used to transmit the notification, and the operation of notifying the usage log record may be included within the scope of the disclosure of this document. Also, depending on the embodiment, the processes of transmitting the notification of the usage log record (S34, S35) may be omitted.

[0123] 8-10 illustrate non-fungible token processing methods according to embodiments of the present disclosure. These methods may involve 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 a processor of a computing device. While each step of such a method may be performed by a single physical computing device, the first step of the method may be performed by a first computing device and the second step of the method may be performed by a second computing device. The following description of FIGS. 8-10 will be continued assuming that the steps of the aforementioned method are performed by any one of multiple nodes 120a-120h of blockchain network 120.

[0124] 8 is a flowchart illustrating a method for withdrawing virtual assets using asset tokens according to one embodiment of the present disclosure. 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 the asset token, at least a portion of the virtual assets recorded in the metadata of the asset token may be transmitted to the wallet address of the asset token owner based on the lending of the digital assets (S100). The withdrawal request may be a request message received by a 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, a withdrawal operation may be implemented according to a withdrawal function defined in the first smart contract. In this way, the asset token owner can generate profits by lending the digital assets corresponding to the asset token.

[0126] 9 is a flowchart illustrating a method for verifying a usage right token according to an embodiment of the present disclosure. The verification of the usage right token may be performed by querying a block in which the usage right token is recorded, without consuming a transaction.

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

[0128] Specifically, in response to a verification request for a usage rights token, at least some of the nodes 120a-120h on the blockchain network may compare the metadata of the usage rights token subject to the verification request with information recorded in the block corresponding to the usage rights token. If the comparison results in the metadata and the information recorded in the block being identical, it may be determined that the usage rights token is free of anomalies or defects. If they are not identical, it may be determined that the usage rights token is free of anomalies or defects. If the verification of the usage rights token results in no anomalies or defects, at least some of the nodes 120a-120h on the blockchain network may transmit at least a portion of the asset token address, usage rights token address, usage rights token identifier, licensee signature, or nonce to the external terminal that transmitted the verification request, e.g., an entity that directly uses the digital asset (e.g., a movie company, a game company, etc.), according to the second smart contract. In other words, the external terminal may receive the above information as a result of the usage rights token passing verification. Here, the nonce is a value that is arbitrarily changed every time a verification request is made, and can be understood as a value to prevent replay attacks that abuse the signature of a licensee. As a result, the right to use a digital asset can be verified using the usage rights token, thereby ensuring reliability in the use of the digital asset.

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

[0130] 10 is a flowchart illustrating a method for transferring a usage right token according to an embodiment of the present disclosure. The transfer of a usage right token may mean that a licensee subleases the usage right token to another person. The transfer of the usage right token may be performed by executing a second smart contract corresponding to the usage right token on a node.

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

[0132] In one embodiment, a node executing a second smart contract related to a usage right token may change information indicating a licensee included in the metadata of the usage right token based on information about the rental period included in the metadata of the usage right token. For example, before the rental period of the usage right token expires, an ownership transfer function of the second smart contract may be activated, thereby enabling the transfer of the usage right token. For example, when the rental period of the usage right token expires, an ownership transfer function of the second smart contract may be deactivated, thereby disabling the transfer of the usage right token.

[0133] In the content disclosed in this document, by recording the usage history of a digital asset in the metadata of the asset token that guarantees the digital asset, the value of the asset token that guarantees the digital asset can be increased. Furthermore, by providing users with a platform for trading digital assets, the utilization of digital assets can be enhanced. The effects of the technical ideas disclosed in this document are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those of ordinary skill in the art from the description of this document.

[0134] Although the steps of a method or algorithm are described in a sequential order in the flowcharts disclosed herein, the steps may be performed in any combinable order, as well as sequentially. The description of flowcharts herein does not preclude variations or modifications to the method or algorithm, and does not imply that any step is essential or preferred. In some embodiments, at least some steps may be performed in parallel, iteratively, or heuristically. In some embodiments, at least some steps may be omitted, and other steps may be added.

[0135] At least one embodiment disclosed herein may increase the value of non-fungible tokens that vouch for 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 that vouches for the digital asset.

[0137] At least one embodiment disclosed herein can increase the utilization of digital assets by providing a platform through which digital assets can be rented.

[0138] At least one embodiment disclosed herein provides a technique for verifying the right to use a digital asset through lending.

[0139] Various embodiments of the subject matter disclosed herein may be embodied as software in a machine-readable storage medium. The software may be software for implementing various embodiments described herein. The software may be deducible from various embodiments described herein by a programmer skilled in the art to which the subject matter disclosed herein pertains. For example, the software may be a program including instructions (e.g., code or code segments) readable by a computing device. An apparatus may be a device, such as a computer, that can operate in response to instructions retrieved from a storage medium. In one embodiment, the apparatus may be a computing device according to various embodiments described herein. In one embodiment, a processor of the apparatus executes the retrieved instructions and causes components of the apparatus to perform functions corresponding to the instructions. A storage medium may refer to any type of recording medium on which information is stored that is readable by a machine. The storage medium may include, for example, a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc. In one embodiment, the storage medium may be embodied in a distributed form across computer systems connected via a network. Software may be stored and executed in a distributed manner across computer systems. The storage medium may be a non-transitory storage medium. A non-transitory storage medium refers to a tangible medium that does not store data semi-permanently or temporarily, and does not include a signal that is propagated transitorily.

[0140] Although the technical idea of ​​the contents disclosed in this document has been described above using various embodiments, the technical idea of ​​the contents disclosed in this document includes various substitutions, modifications, and alterations that can be made within the scope of those skilled in the art to which the contents disclosed in this document pertains. Furthermore, it should be understood that such substitutions, modifications, and alterations are included within the scope of the appended claims.

Claims

1. a communication interface for communicating with at least one node of the blockchain network and an external device; one or more memories for storing at least one instruction; one or more processors communicatively coupled to the communication interface and the one or more memories; The one or more processors execute the at least one instruction to: receiving a lending request for digital assets corresponding to the first token from the user's user terminal; and performing 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; 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 the right to use the digital asset; second metadata of the second token indicating a licensee of the digital asset; An electronic device, wherein, based on the 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.

2. The one or more processors further receiving a usage log (Log) from the user terminal of the user indicating a history of use of the digital asset; based on the receipt of the usage log, a recording procedure is performed to record the usage log for the first token in the first metadata of the first token; The electronic device of claim 1 , wherein the recording procedure includes transmitting a recording request to execute the first smart contract to at least one node of a blockchain network.

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

4. The electronic device of claim 2 , wherein, based on the recording request, virtual assets corresponding to at least a portion of the virtual assets recorded in the first token are transmitted to the wallet address of the licensee.

5. The electronic device of claim 2 , wherein the usage log includes at least one of information about the licensee, 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 at which the digital asset was used.

6. The one or more processors further receiving a verification request for the second token from an external terminal distinct from the user terminal; comparing the second metadata of the second token with information recorded in a block corresponding to the second token based on the verification request; and transmitting at least a part of a first address of the first token, a second address of the second token, an identifier of the second token, a signature of the licensee, or a nonce to the external terminal based on the fact that the second metadata of the second token is identical to the information recorded in the block; The electronic device of claim 2 , wherein the nonce value is a value that is arbitrarily changed based on receipt of a verification request.

7. The electronic device of claim 6, wherein, based on the second metadata of the second token being identical to the information recorded in the block, information indicating a history of use of the digital asset is recorded as the usage log in the first metadata of the first token.

8. The representative image of the first token is The electronic device of claim 2, wherein the first token is determined to be 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 creation information recorded in the first metadata of the first token.

9. The representative image of the first token is The electronic device of claim 8, wherein the digital asset is determined to be one of a plurality of sub-digital assets included in the digital asset based on at least one of a first cumulative sum of the first number and the usage period corresponding to the first number, or a second cumulative sum of the first number and the rental period corresponding to the first number.

10. The representative image of the first token is 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 log or creation information recorded in the first metadata of the first token satisfies a predetermined condition; The electronic device of claim 2, wherein the predetermined condition is a condition related to at least one of information regarding the owner or licensee of the digital asset included in at least one of the usage log or the generation information, information regarding content related to the use of the digital asset, or information regarding the manner of use of the digital asset.

11. The procedure for generating the second token includes: The electronic device of claim 1 , wherein the transaction is performed based on an interaction with at least one node included in the blockchain network.

12. The electronic device of claim 1 , wherein the second metadata of the second token indicates whether the digital asset is available for subleasing.

13. The electronic device of claim 1, wherein the generation information includes at least one of information regarding the rental period of the digital asset, information regarding the licensee, information regarding the content for 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.

14. The electronic device of claim 1 , wherein the loan request involves an operation in which virtual assets corresponding to a price for the loan of the digital asset are transmitted to a wallet address of the electronic device based on the loan request.

15. Based on the generation of the second token, the amount of the virtual asset is recorded in the metadata of the first token; The one or more processors further receiving a withdrawal request for the virtual asset for the first token from the user terminal of the digital asset owner; 15. The electronic device of claim 14, wherein the electronic device is configured to transmit a transmission message to at least one node included in the blockchain network, the transmission message instructing the transfer of at least a portion of the virtual assets to the wallet address of the owner based on the withdrawal request.

16. The one or more processors further receiving a transfer request for the second token from the user terminal of the user; 2. The electronic device of claim 1, configured to transmit a change message to at least one node included in the blockchain network to change information indicating the authorized user of the second token based on the transfer request.

17. the second metadata of the second token indicates a loan period for the digital asset; The one or more processors further 17. The electronic device of claim 16, configured to change information indicating the licensee of the second token based on whether the loan period has expired.

18. The first smart contract includes information that enables generation of a second token that includes lending information of the digital asset as metadata; The electronic device of claim 1 , wherein the digital asset rental information indicates a licensee for the digital asset.

19. 1. A method performed on an electronic device, comprising: receiving a loan request for digital assets corresponding to the first token from a user terminal of the user; and performing 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; 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 the right to use the digital asset; second metadata of the second token indicating a licensee of the digital asset; Based on the 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.

20. receiving, from the user terminal of the user, a usage log indicating a history of how the digital asset has been used; 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; 20. The method of claim 19, wherein the recording procedure includes transmitting a recording request to execute the first smart contract to at least one node of a blockchain network.

Images