Digital asset management system, method, and program

Abstract

[Problem] To improve convenience and security in the management of digital assets to which a user has rights in a prescribed service. [Solution] A digital asset management system 100 is provided with: a lock instruction unit 22 which instructs a corresponding service to lock digital assets to which a first user 9 has rights; a NFT issuing unit 23 which, in relation to the locked digital assets, issues a NFT having the first user designated as the owner; an unlock instruction unit 25 which instructs the corresponding service to unlock the digital assets, and which, at the time of the unlocking, instructs that a user corresponding to the owner of the NFT be set as the user having rights to the digital assets and that the digital assets be unlocked; and a NFT invalidating unit 26 which transitions the NFT to an unusable state when the digital assets are unlocked.

Description

Digital asset management system, method and program

[0001] The present disclosure relates to digital asset management techniques.

[0002] Conventionally, technologies for generating and trading non-fungible tokens using blockchain have been proposed (see Non-Patent Documents 1 and 2).

[0003] In addition, an electronic ticket management system has been proposed that includes an electronic ticket issuing means for issuing non-fungible token-type electronic tickets by assigning parameters that add utility value for purposes other than participation in a performance, an issuance information registration means for registering electronic ticket issuance information including a token ID, ticket ID, owner ID, and parameters in a distributed ledger, an electronic ticket transfer means for creating transfer information including the owner ID before and after the change when ownership of the electronic ticket is transferred, and a transfer information registration means for registering the transfer information in a distributed ledger (see Patent Document 1).

[0004] Japanese Patent Application Laid-Open No. 2022-002008

[0005] William Entriken, 3 others, “EIP-721: Non-Fungible Token Standard” https: / / eips.ethereum.org / EIPS / eip-721Witek Radomski, 5 others, “EIP-1155: Multi Token Standard” https: / / eips.ethereum.org / EIPS / eip-1155

[0006] Previously, there were issues with convenience and security when managing digital assets without using non-fungible tokens. Furthermore, while various technologies have been proposed for managing and trading digital assets by generating non-fungible tokens, the mechanisms for management, use, or disposal are premised on the fact that non-fungible tokens have been attached, and when attempting to attach non-fungible tokens to conventional digital assets that are not premised on management using non-fungible tokens and manage them, it has become necessary to build a new system for the use or disposal of the assets.

[0007] In view of the above-mentioned problems, an object of the present disclosure is to improve the convenience and security of managing digital assets to which a user has rights in a given service.

[0008] One example of the present disclosure is a digital asset management system comprising: a lock instruction means for instructing a corresponding service to perform a locking process to restrict the use or disposal of a digital asset provided by the corresponding service and to which a first user has rights; a non-fungible token issuance means for issuing, on a distributed ledger, a non-fungible token with the first user as the holder for the digital asset locked by the corresponding service, in association with metadata indicating data related to the digital asset; an unlock instruction means for instructing the corresponding service to perform an unlocking process to remove restrictions on the use or disposal of the digital asset locked by the corresponding service, the unlock instruction means instructing the corresponding service to set a user corresponding to the holder of the non-fungible token at the time of the unlocking process as a user who has rights to the digital asset and unlock it; and a non-fungible token invalidation means for transitioning the non-fungible token related to the unlocking process to an unusable state during the unlocking process.

[0009] The present disclosure can be understood as an information processing device, a system, a method executed by a computer, or a program executed by a computer. The present disclosure can also be understood as such a program recorded on a recording medium readable by a computer or other device, machine, etc. Here, a recording medium readable by a computer, etc. refers to a recording medium that stores information such as data and programs by electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer, etc.

[0010] According to the present disclosure, it is possible to improve the convenience and security of managing digital assets to which a user has rights in a given service.

[0011] FIG. 1 is a schematic diagram showing the configuration of a system according to an embodiment. FIG. 2 is a diagram showing an outline of the functional configuration of a system according to an embodiment. FIG. 3 is a flowchart showing the flow of advance preparation processing according to an embodiment. FIG. 4 is a flowchart (1) showing the flow of account linking processing according to an embodiment. FIG. 5 is a flowchart (2) showing the flow of account linking processing according to an embodiment. FIG. 6 is a diagram showing an overview of check-in according to an embodiment. FIG. 7 is a flowchart showing the flow of check-in processing according to an embodiment. FIG. 8 is a diagram showing an overview of NFT transactions according to an embodiment. FIG. 9 is a flowchart showing the flow of listing processing according to an embodiment. FIG. 10 is a flowchart showing the flow of rights transfer processing according to an embodiment. FIG. 11 is a diagram showing an overview of check-out according to an embodiment. FIG. 12 is a flowchart showing the flow of check-out processing according to an embodiment. FIG. 13 is a diagram showing an overview of digital asset usage according to an embodiment.

[0012] Hereinafter, embodiments of a system, an information processing device, a method, and a program according to the present disclosure will be described with reference to the drawings. However, the embodiments described below are merely examples, and the system, the information processing device, the method, and the program according to the present disclosure are not limited to the specific configurations described below. In implementing the present disclosure, a specific configuration according to the embodiment may be appropriately adopted, and various improvements and modifications may be made.

[0013] In this embodiment, an embodiment of the technology disclosed herein is described in which it is implemented for a digital asset management system that issues NFTs based on digital assets provided by a specified compatible service, makes them available for viewing, listing, and purchase on the digital asset management system, and then returns the digital assets to a state where they can be used in the original compatible service as the latest owner's digital assets. However, the present disclosure can be widely used to improve the convenience and security of transfers of rights to digital assets to which users have rights that are managed by compatible services, and the application of the present disclosure is not limited to the examples shown in the embodiment.

[0014] Conventionally, there have been issues with convenience and security regarding the management and transfer of rights to digital assets without using non-fungible tokens. Furthermore, various technologies have been proposed for managing and trading digital assets by generating non-fungible tokens, but the mechanisms for management, use, or disposal are premised on the fact that non-fungible tokens are attached. Therefore, when attempting to attach non-fungible tokens to conventional digital assets that are not premised on management using non-fungible tokens and manage them, it has become necessary to build a new system for their use or disposal. In consideration of the above-mentioned problems, the system according to this embodiment is intended to solve all or at least part of the above-mentioned problems.

[0015] A non-fungible token (hereinafter, "NFT") is a type of cryptographic token, and unlike fungible tokens (hereinafter, "FT") such as cryptocurrencies, which can be substituted with other tokens of the same amount, a non-fungible token is a token that indicates a person who has some right over an object that cannot be substituted with anything else. In this embodiment, an example will be described in which an NFT is issued and traded by recording data (e.g., data including a hash value) indicating the correspondence between the NFT and the object on a so-called blockchain. However, there are no limitations on the technology that can be employed to issue and trade NFTs.

[0016] <System Configuration> Figure 1 is a schematic diagram showing the configuration of a digital asset management system 100 according to this embodiment. The system according to this embodiment includes an information processing device 1 that is connected to a network and can communicate with each other, and multiple user terminals 9. The digital asset management system 100 according to this embodiment is also connected to one or more compatible services 5 that provide digital assets to users, and a blockchain 7.

[0017] The information processing device 1 is a computer including a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a storage device 14 such as an EEPROM (Electrically Erasable and Programmable Read Only Memory) or an HDD (Hard Disk Drive), a communication unit 15 such as a NIC (Network Interface Card), etc. However, the specific hardware configuration of the information processing device 1 can be omitted, replaced, or added as appropriate depending on the embodiment. Furthermore, the information processing device 1 is not limited to a device consisting of a single housing. The information processing device 1 may be realized by a plurality of devices using so-called cloud or distributed computing technology.

[0018] The user terminal 9 is a terminal device used by a user. The user terminal 9 is a computer equipped with a CPU, ROM, RAM, a storage device, a communication unit, an input device, an output device, etc. (not shown). However, the specific hardware configuration of the user terminal 9 can be omitted, replaced, or added as appropriate depending on the embodiment. Furthermore, the user terminal 9 is not limited to a device consisting of a single housing. The user terminal 9 may be realized by multiple devices using so-called cloud or distributed computing technology, etc. Users connect to the information processing device 1 via these user terminals 9 to manage NFTs and FTs, participate in the marketplace, trade NFTs, etc.

[0019] The corresponding service 5 may be any service that provides a user with some kind of digital asset, and may be referred to as a digital asset provider, a digital asset platform, or the like. The types of services provided by the corresponding service 5 and the types of digital assets provided are not limited. For example, the corresponding service 5 may be a game service that provides a user with game items or game data as digital assets, a ticket service that provides a user with an electronic ticket or a physical ticket reservation right as a digital asset, or an e-book service that provides a user with a right to read e-books as a digital asset. The corresponding service 5 may also provide a user with a service usage right for some kind of service as a digital asset.

[0020] Furthermore, in this disclosure, digital data to which a user has been granted some right is referred to as a "digital asset," regardless of whether it is recorded in a distributed ledger. In this disclosure, a "digital asset" is not limited to a digital asset whose right can be verified using distributed ledger technology, such as by issuing an NFT. The target digital asset may be fungible, such as a game item whose number is only managed, or non-fungible, such as a reserved seat ticket or a ticket with an entrance number.

[0021] In this embodiment, data as the entity of a digital asset (hereinafter referred to as "digital asset data") is managed by the corresponding service 5. That is, the corresponding service 5 has a data management system, and the data management system manages data of digital assets to which rights are granted to users, by linking it with at least the users who have the rights. The type of data management system that can be adopted in this embodiment is not limited, and may be a closed data management system within the corresponding service 5, a so-called location-oriented data management system such as a Content Delivery Network (CDN), or a so-called content-oriented data management system such as an InterPlanetary File System (IPFS).

[0022] Furthermore, when issuing NFTs, the digital asset management system 100 may manage data to be referenced when trading NFTs, separate from the master data managed by the corresponding service 5. The management method for the data managed by the digital asset management system 100 is also not limited, and a closed data management system, a location-oriented data management system, or a content-oriented data management system may be adopted.

[0023] The blockchain 7 is used to issue and trade NFTs and FTs by registering data. In this embodiment, a so-called private blockchain is used as the blockchain, in which only users with accounts managed by a specified management entity (e.g., user IDs issued by the administrator of the digital asset management system 100) can participate. Therefore, in this embodiment, the wallets of each user, including purchasers of NFTs, are managed in association with the accounts. Here, wallet addresses corresponding to each user's wallet are generated as appropriate. However, the type of blockchain that can be used to implement the technology disclosed herein is not limited; a consortium blockchain in which only users with accounts corresponding to multiple specific management entities can participate may be used, or a public blockchain may be used. Furthermore, the same blockchain may be used for issuing NFTs, trading NFTs, and issuing FTs and trading FTs, or different blockchains may be additionally used.

[0024] 2 is a diagram showing an outline of the functional configuration of the digital asset management system 100 according to this embodiment. The digital asset management system 100, which includes the information processing device 1 and the user terminal 9, functions as the digital asset management system 100 including an account linking unit 21, a lock instruction unit 22, an NFT issuing unit 23, an NFT management unit 24, an unlock instruction unit 25, and an NFT invalidation unit 26, by reading a program recorded in a storage device into RAM and executing it by a CPU to control each piece of hardware provided in the information processing device 1 and the user terminal 9. Note that in this embodiment and other embodiments described below, each function provided in the digital asset management system 100 is executed by a CPU, which is a general-purpose processor, but some or all of these functions may be executed by one or more dedicated processors.

[0025] The account linking unit 21 maintains a correspondence between an account (user ID) for identifying a user in the compatible service 5 and an account (user ID) for identifying an NFT holder in the digital asset management system 100. The location where the data indicating the correspondence is maintained is not limited, and may be maintained in any of the compatible service 5, the server of the digital asset management system 100, the user terminal 9, or an external database.

[0026] The lock instruction unit 22 instructs the corresponding service 5 to perform a lock process to restrict the use or disposal of a digital asset provided by the corresponding service 5 and to which the first user has rights. The lock process instruction may be sent directly from the user terminal 9 to the corresponding service 5, or may be sent to the corresponding service 5 from the digital asset management system 100, which has received a check-in request from the user terminal 9. In this embodiment, the conversion from the corresponding service 5 for digital asset management to the digital asset management system 100 by issuing an NFT based on the digital asset is referred to as a "check-in." The lock process instruction for the digital asset may be sent directly from the user terminal 9 to the corresponding service 5, or may be sent from the user terminal 9 to the corresponding service 5 together with the check-in request. At this time, after receiving the lock process instruction, the corresponding service 5 requests the digital management system 100 to generate an NFT. At this time, the digital management system 100 does not send a lock process instruction to the corresponding service 5, but instead sends an NFT issuance notification to the corresponding service 5 or the user terminal 9.

[0027] The NFT issuing unit 23 records token data including a metadata identifier for a digital asset locked by the compatible service 5 on the blockchain 7, thereby making the first user the holder, and issues (attaches to the holder's wallet) an NFT in which metadata indicating data related to the digital asset is linked (associated) with the digital asset. In this embodiment, by doing so, the digital asset is indirectly linked to the NFT via the metadata. However, the digital asset may also be directly linked to the NFT by including a hash value or CID of the digital asset in the token data. Also, in this embodiment, multiple NFTs linked to a single digital asset may be issued. In this case, the NFT issuing unit 23 issues multiple NFTs linked to a single digital asset by employing a method such as generating multiple pieces of metadata including combinations of a common content identifier (CID) and different additional data (e.g., serial numbers) and recording multiple pieces of token data corresponding to the generated multiple pieces of metadata on the blockchain 7, or a method such as recording multiple pieces of token data including combinations of a common metadata identifier and different additional data (e.g., serial numbers) on the blockchain 7. The digital asset management system 100 may generate a new wallet (wallet address) to which the NFT will be issued when the NFT is issued. The new wallet may be generated after the correspondence between the user ID in the corresponding service 5 and the user ID in the digital asset management system 100 is maintained (account linking).

[0028] Here, "issuing" an NFT includes minting, issuing, creating, and generating. In this embodiment, an example is mainly described in which an NFT minted by the NFT issuing unit 23 is directly transferred to a user's wallet, but, for example, the NFT issuing unit 23 may issue an NFT by first minting the NFT in a system administrator's wallet and then transferring the NFT to a user's wallet.

[0029] Furthermore, in this embodiment, when issuing an NFT, the NFT issuing unit 23 may supplement the data related to the digital asset acquired from the compatible service 5 with information that the compatible service 5 does not have as master data as metadata for the NFT and write it to the blockchain. Specifically, for example, the NFT issuing unit 23 may record metadata including attribute data generated by the digital asset management system 100 on an external server outside the distributed ledger (in this embodiment, an external server outside the blockchain 7), or may record it in the distributed ledger. Metadata including data acquired from a service other than the compatible service 5 may be recorded on an external server outside the blockchain 7, or may be recorded in the blockchain 7. Here, the blockchain refers to a blockchain network composed of one or more nodes (such as a server device).

[0030] The method for generating attribute data by the digital asset management system 100 is not limited, but for example, the NFT issuing unit 23 may generate data to be included in metadata by inputting digital asset data into a trained model trained using training data in which data related to the digital asset is used as input values ​​and attribute data of the digital asset is used as output values, and outputting estimated attribute data. The training data can be created, for example, by merging data of a user who has linked their account between a compatible service and the digital asset management system (after obtaining approval from the user, if necessary).

[0031] Furthermore, there are no limitations on the method by which the digital asset management system 100 obtains data from services other than the corresponding service 5, but for example, the NFT issuing unit 23 can obtain data linked to the target user in other services (e.g., e-commerce services, social networking services, etc.) linked to the digital asset management system 100 (after obtaining approval from the user, if necessary).

[0032] The NFT management unit 24 manages the NFTs issued by the NFT issuing unit 23 and assigned to the user's wallet. In this embodiment, the digital assets may include certain rights and other benefits (points, data, etc.) related to the digital assets linked to the NFTs.

[0033] In this embodiment, the NFT management unit 24 registers the NFT issued by the NFT issuing unit 23 in the marketplace according to the operation of the holder of the NFT, thereby making the NFT available for purchase by other users, including the second user. Furthermore, the NFT management unit 24 accepts a purchase operation from the second user for the NFT registered in the marketplace. Then, if the purchase is approved, the NFT management unit 24 changes the holder of the NFT from the first user who is the seller to the second user who is the purchaser.

[0034] In addition, in response to a request (API call, etc.) from a corresponding service or the digital asset management system 100 itself, the NFT management unit 24 refers to the user's wallet and obtains a list of NFTs currently held by the target user.

[0035] The unlock instruction unit 25 instructs the corresponding service 5 to perform an unlock process to remove restrictions on the use or disposal of a digital asset locked by the corresponding service 5. Here, the unlock instruction unit 25 instructs the corresponding service 5 to set a user corresponding to the holder of the NFT related to the digital asset to be unlocked at the time of the unlock process as a user who has rights to the digital asset, and unlock the digital asset. In other words, if the holder of the NFT has changed to a second user at the time of unlocking, the unlock instruction unit 25 instructs the corresponding service 5 to perform an unlock process to set the second user who has become the holder of the NFT due to the change of holder as a user who has rights to the digital asset, and unlock the digital asset. On the other hand, if the holder of the NFT remains the first user at the time of unlocking, the unlock instruction unit 25 instructs the corresponding service 5 to perform an unlock process to set the first user who is the holder of the NFT at the time of locking as a user who has rights to the digital asset, and unlock the digital asset. At this time, the unlock instruction unit 25 can identify the user ID of the NFT holder in the corresponding service 5 by referring to the correspondence relationship created by the account linking unit 21.

[0036] As with the locking process, the unlocking instruction may be sent directly from the user terminal 9 to the corresponding service 5, or may be sent from the digital asset management system 100, which has received a checkout request from the user terminal 9, to the corresponding service 5. In this embodiment, the reconversion of digital asset management from the digital asset management system 100 to the corresponding service 5 by transitioning the NFT issued for the digital asset to an unusable state is referred to as "checkout." The unlocking instruction for the digital asset may be sent directly from the user terminal 9 to the corresponding service 5, or may be sent from the user terminal 9 to the corresponding service 5 together with the checkout request. At this time, after receiving the unlocking instruction, the corresponding service 5 sends an NFT deletion request (invalidation request, burning request) to the digital management system 100. At this time, the digital management system 100 does not send an unlocking instruction to the corresponding service 5, but instead sends an NFT burning notification to the corresponding service 5 or the user terminal 9.

[0037] During the unlocking process, the NFT invalidation unit 26 transitions the NFT related to the unlocking process to an unusable state. The method for transitioning the NFT to an unusable state is not limited, but for example, the NFT invalidation unit 26 may transition the NFT related to the unlocking process to an unusable state by burning the NFT. Methods for transitioning the NFT to an unusable state include transferring the NFT to a predetermined invalid wallet address and assigning a predetermined flag. Transitioning the NFT to an unusable state makes it possible to prevent situations such as duplicate transfers of digital assets.

[0038] <Processing Flow> Next, the processing flow executed in the system according to this embodiment will be described. Note that the specific content and processing order of the processing described below are an example for implementing the present disclosure. The specific processing content and processing order may be selected as appropriate depending on the embodiment of the present disclosure.

[0039] 3 is a flowchart showing the flow of advance preparation processing according to this embodiment. The processing shown in this flowchart is executed as advance preparation to enable asset management conversion to the digital asset management system 100 for digital assets provided in the corresponding service 5.

[0040] In the corresponding service 5, content data that forms the basis of digital assets is set in advance and stored on the server of the corresponding service 5. Digital assets are generated by assigning rights to users for the content data set here. The corresponding service 5 shares this content data with the digital asset management system 100, and the digital asset management system 100 stores data related to the shared content data (the content itself or content attributes (parameters)) as metadata in the blockchain 7 for each piece of content data. Here, data related to content data may be, for example, item specifications, name, images, etc. for game items; event details (artist name, event name, etc.), venue, and event date for tickets; or the content of e-books for e-books. Note that the digital asset management system 100 may store some of the data related to the content data as metadata and the rest as token data.

[0041] Then, when an NFT is issued for a digital asset based on content data in the check-in process described below, the content data is linked to the NFT using an identifier (serial number or token ID) assigned to each piece of content data and stored in the blockchain 7. As a result, in the process of deleting the NFT, unlocking the status of the digital asset, and setting a rights owner in the check-out process (see steps S407 to S410 in FIG. 12), various information about the content data written in the metadata corresponding to the NFT on the blockchain 7 is referenced and used to identify the digital asset for which a rights owner is to be set.

[0042] The content of the data recorded in the blockchain 7 for each piece of content data is not limited, but may include, for example, the following: (1) Common metadata for game items - Collectible ID (item ID mapped on the corresponding service 5 side) - Asset Provider ID (ID of the corresponding service 5. Here, the ID of the game service provider.) - Name (name. Here, the item name.) (2) Common metadata for tickets - Collectible ID (event ID mapped on the corresponding service 5 side) - Asset Provider ID (ID of the corresponding service 5. Here, the ID of the ticket service provider.) - Name (name. Here, the event name + seat type + seat name.)

[0043] Furthermore, in this embodiment, the following items may be used as items included in the metadata: external URL (URL that leads the user to a service or content page); rarity (rarity of the content or NFT); series (series information of the content);

[0044] In this embodiment, we describe a case in which data common to the content is recorded in advance on the blockchain 7, but the data common to the content may also be recorded on the blockchain 7 when an NFT related to the digital asset, as described below, is issued.

[0045] In addition, the metadata may further include information on the corresponding service 5, information on performers related to the content, credit information related to intellectual property rights (copyright, trademark, performer's rights, etc.) related to the content, information on the group related to the content, date and time information related to the content, location information related to the content (such as an event venue, which may also include a metaverse or streaming event), and event information related to the content (such as the series / season name or event name of a sports game, concept, etc.). Here, performers include actors, musicians, athletes in sports content, and members in idol / band content. Groups include team names in sports content, group names in idol content, and group names in band content. Dates and times include the release date and time of the content and the recording date and time. These pieces of information may be included as independent items in the metadata and / or digital asset data, or may be listed in comprehensive items such as the "description" and "series" mentioned above. Performer information may also include the performer's role in the content (such as their position in sports content (e.g., "pitcher"), their position in idol content, or their instrument in band content).

[0046] Furthermore, while the above example shows an example in which the master data / digital asset ID of the digital asset held by the corresponding service 5 is written as metadata, in order to enable the digital asset management system 100 to manage digital assets for which the corresponding service 5 does not have master data or for which the metadata is insufficient, the digital asset management system 100 may supplement the metadata on the blockchain 7 with various profiles / attributes.

[0047] 4 and 5 are flowcharts showing the flow of account linking processing according to this embodiment. The processing shown in this flowchart is executed when the user terminal 9, which has received an account linking instruction or a check-in / check-out operation from the user, sends an account confirmation request to the server of the corresponding service 5.

[0048] Upon receiving the account confirmation request (step S001), the corresponding service 5 checks whether the user's account in the digital asset management system 100 has been linked to the corresponding service 5 account, and whether the user has registered an NFT wallet (hereinafter simply referred to as "wallet") in the digital asset management system 100 (steps S002 and S003). This check may be performed by referencing the account information recorded in the data of the account logged in to the corresponding service 5. If the accounts are linked and wallet registration has been confirmed, the user terminal 9, upon receiving a notification from the corresponding service 5, notifies the user that the account linking process has been completed (step S020). When the account linking process is completed, the process shown in this flowchart ends. As mentioned above, wallet registration is not required for the account linking process.

[0049] On the other hand, if the account is not yet linked (unlinked), the corresponding service 5 connects the user terminal to the digital asset management system 100. The account linking unit 21 of the connected digital asset management system 100 determines whether the user has already opened an account with the digital asset management system 100 (step S004). This determination may be made by receiving a request from the user for registration or by a login attempt. If the determination indicates that the user has not already opened an account with the digital asset management system 100, the account linking unit 21 displays an account opening page on the user terminal 9 (step S005) and prompts the user to open a new account (steps S006 and S007). The account opening process may use conventional or future account management technology, and therefore will not be described here.

[0050] If the user has already opened an account with the digital asset management system 100, or if a new account has been opened, the account linking unit 21 prompts the user to log in to the user's account (steps S008 to S010). The login process may use conventional or future account management technology, and therefore will not be described here. Once the login is complete, the account linking unit 21 authorizes the server of the corresponding service 5 to link the user ID associated with the account (step S011). The corresponding service 5 retains the user ID for a certain period of time (step S012), enabling the user of the corresponding service 5 to perform NFT-related operations (e.g., API calls) on the corresponding service 5. The process then proceeds to confirming the registration status of the NFT wallet.

[0051] If the accounts are already linked (or the accounts are newly linked) but the registration of the NFT wallet has not been confirmed (is unconfirmed), the corresponding service 5 specifies the user ID and checks the registration status of the NFT wallet with the digital asset management system 100 (step S013; specifically, it calls an API provided by the digital asset management system 100 for checking the registration status of the NFT wallet). Upon receiving the inquiry about the registration status of the NFT wallet, the account linking unit 21 of the digital asset management system 100 checks whether an NFT wallet has been registered for the specified user ID (step S014). If an NFT wallet has been registered for the specified user ID (YES in step S015), the user terminal 9, which has received a notification from the corresponding service 5, notifies the user that the account linking process has been completed (step S020), and the process shown in this flowchart ends.

[0052] On the other hand, if an NFT wallet has not yet been registered for the specified user ID (NO in step S015), the account linking unit 21 of the digital asset management system 100 displays a registration interface on the user terminal 9 to prompt the user to create and register an NFT wallet (step S016), and registers an NFT wallet for the user by receiving information entered by the user in accordance with the registration interface from the user terminal 9 (step S017) (step S018). Here, the NFT wallet registration process is generally similar to conventional wallet registration, and therefore a description thereof will be omitted. Upon completion of the NFT wallet registration, the account linking unit 21 notifies the compatible service 5 that the wallet registration has been completed (step S019). Upon receiving the notification from the compatible service 5, the user terminal 9 notifies the user that the account linking process has been completed (step S020), and the process shown in this flowchart ends. In addition, instead of registering a wallet, confirmation regarding the issuance and registration of a user ID (membership registration) in the digital asset management system 100 and display of a registration interface may be performed.

[0053] 6 is a diagram showing an overview of check-in according to this embodiment. When a user makes a check-in request to the corresponding service 5, the corresponding service 5 deletes the rights information for the digital asset and locks the status of the digital asset. The corresponding service 5 then requests the digital asset management system 100 to issue an NFT related to the target digital asset. Upon receiving the request, the digital asset management system 100 issues an NFT related to the target digital asset. The flow of check-in processing according to this embodiment will be described below with reference to a flowchart.

[0054] 7 is a flowchart showing the flow of check-in processing according to this embodiment. The processing shown in this flowchart is executed when a check-in processing start operation is performed on the user terminal 9 of a user who wishes to transfer the management of digital assets provided by the corresponding service 5 to the digital asset management system 100.

[0055] In steps S101 to S103, a list of digital assets that can be checked in is presented and a check-in request is made. The user terminal 9, which has received an operation to start the check-in process from the user, transmits a request to start the check-in operation to the server of the corresponding service 5 (step S101). Upon receiving the request to start the check-in operation transmitted from the user terminal 9, the corresponding service 5 generates a list of digital assets that can be transferred for management to the digital asset management system 100 (i.e., can be checked in) from among the digital assets provided by the corresponding service 5 to which the user has rights (owns), and transmits the list to the user terminal 9 (step S102). Here, for example, if the digital assets are game items, items that are set to be in use in the game are excluded from the list.

[0056] Upon receiving the list, the user terminal 9 outputs (for example, displays on a display) the list of digital assets available for check-in so that the user can confirm it, and accepts the user's selection of the digital asset to be checked in. When the selection of the digital asset to be checked in is accepted, the user terminal 9 sends a check-in request to the server of the corresponding service 5, specifying the digital asset to be checked in (step S103). Then, the process proceeds to step S104.

[0057] In steps S104 to S106, the status of the digital asset related to the check-in request is locked and the rights information is deleted. When the corresponding service 5 receives a check-in request transmitted from the user terminal 9, it locks the status of the digital asset related to the check-in request (the checked-in digital asset) among the digital assets provided by the corresponding service 5 to which the user has rights (owns) (step S104) and deletes the user's rights information assigned to the checked-in digital asset (step S105). The specific method for deleting the rights information is not limited here, but may be, for example, by deleting the linkage of the item to the user data or deleting the item from the user library. This restricts the use or disposal of the checked-in digital asset. The process then proceeds to step S106.

[0058] In steps S106 to S108, an NFT for the checked-in digital asset is issued. The corresponding service 5 transmits a request for linking a user ID, a request for linking parameters of the checked-in digital asset, and a request for generating an NFT related to the linked user ID and parameters to the server of the digital asset management system 100 (step S106). Specifically, the corresponding service 5 calls an API for linking a user ID, an API for linking parameters of the checked-in digital asset, and an API for generating an NFT related to the linked user ID and parameters, all of which are provided by the digital asset management system 100. Upon receiving the NFT generation request, the NFT issuing unit 23 of the digital asset management system 100 identifies the wallet held by the user by referencing the linked user ID (step S107) and issues an NFT for the linked checked-in digital asset to the identified user's wallet (step S108). Processing then proceeds to step S109. Here, if the NFT issuing unit 23 cannot identify the wallet held by the user, the digital asset management system 100 may issue a new wallet (wallet address) for the user.

[0059] More specifically, the NFT issuing unit 23 calculates a hash value using a predetermined hash algorithm based on a key containing parameters of the digital asset to be checked in. The NFT issuing unit 23 then creates a digital signature using the calculated hash value and the private key of the corresponding service 5. Details of the digital signature process are omitted here, as conventional or future digital signature technologies may be used. The public key corresponding to the private key used here is published on the marketplace. This allows anyone who can obtain the public key to verify the authenticity of the digital asset. Once the digital signature is created, the NFT issuing unit 23 generates metadata for the digital asset, including the hash value, the digital signature, and a resource identifier referenced when acquiring digital asset data. The URI in the metadata may include a CID generated in advance according to the IPFS protocol. This makes it possible to acquire digital asset data from IPFS by specifying the URI, even when the digital asset data is added to IPFS. The token data is then recorded on the blockchain 7, and an NFT is issued. The NFT issuing unit 23 creates token data including the metadata CID, and by recording the created token data directly on the blockchain 7, issues an NFT linked to the metadata and digital assets by attaching it to the holder's wallet.

[0060] In steps S109 to S111, a notification of check-in completion is issued. When an NFT for the digital asset to be checked in is issued, the digital asset management system 100 notifies the user terminal 9 that check-in is complete (step S109). The user terminal 9 then outputs (e.g., displays on a display) the notification content to allow the user to confirm it (step S110), and allows the user to confirm the issued NFT (step S111). The processing shown in this flowchart then ends.

[0061] Here, the token data listed below can be used as token data for an NFT, for example. Note that the example shown below assumes a collectible token in which multiple NFTs are issued for one digital asset (i.e., a form in which the same type of game item is managed by number). The token used may be changed as appropriate depending on the type of digital asset. - tokenID (token ID) - tokenMetadataURI (a URI for referencing metadata from an NFT when it is issued, including the CID of the metadata.)

[0062] The metadata may further include attributes of the digital asset data in addition to location information (including URIs and CIDs) for referencing the digital asset data commonly used in NFTs, a hash value of the digital asset data, and a digital signature of the digital asset data.

[0063] Furthermore, the digital asset management system 100 may supplement various data into metadata on the blockchain 7, just as when registering content data on the blockchain in the above-described advance preparation process. In this case, when issuing an NFT, the NFT issuing unit 23 supplements, as metadata corresponding to the NFT, information that the compatible service 5 does not have as master data, in addition to data related to the digital asset acquired from the compatible service 5. The method of storing data is as described above in the explanation of the NFT issuing unit 23.

[0064] 8 is a diagram showing an overview of NFT transactions according to this embodiment. When a first user puts an NFT up for sale on a marketplace and a second user purchases the NFT, ownership of the NFT is transferred from the first user to the second user. Below, the flow of the listing process and rights transfer process for NFT transactions according to this embodiment will be described with reference to flowcharts.

[0065] 9 is a flowchart showing the flow of the listing process according to this embodiment. The process shown in this flowchart is executed when an operation to start the listing process is performed on the user terminal 9 of a user who wishes to transfer the rights to a digital asset whose management has been transferred to the digital asset management system 100.

[0066] In steps S201 to S205, a user interface for accepting input of listing information is output in response to a user's operation to start the listing process. Upon receiving the user's operation to start the listing process (step S201), the user terminal 9 requests a page (hereinafter referred to as a "my collection page") on which the user can view the NFTs he or she owns from the server of the digital asset management system 100 (step S202). The NFT management unit 24 of the digital asset management system 100, upon receiving the request, transmits the target user's my collection page to the user terminal 9 (step S203). Upon receiving the my collection page, the user terminal 9 outputs the my collection page so that the user can view it (e.g., displays it on a display), accepts the user's selection of the desired NFT, and notifies the digital asset management system 100 of the selected NFT (step S204). Upon receiving the notification, the NFT management unit 24 of the digital asset management system 100 displays a user interface (dialog) for accepting input of listing information on the user terminal 9 (step S205). Then, the process proceeds to step S206.

[0067] In steps S206 to S209, the NFT is put up for sale on the marketplace. The user terminal 9 accepts the listing information input from the user, including the listing price of the NFT (step S206) and consent to the terms of NFT transactions in the digital asset management system 100 (step S207), in accordance with a user interface for accepting listing information input. The listing process is then completed by transmitting this information to the digital asset management system 100 (step S208). Upon receiving the listing information, the digital asset management system 100 registers the corresponding NFT on the marketplace, and the listed NFT is then displayed on the marketplace of the digital asset management system 100 (step S209). The process shown in this flowchart then ends.

[0068] Here, the method for determining the auction price of an NFT is not limited. For example, a method may be adopted in which the NFT becomes available for purchase if the buyer agrees to a price previously presented by the seller, or a method may be adopted within an appropriate range in which the price is fluctuated to determine a price that is agreeable between the seller and the buyer, such as in an auction.

[0069] 10 is a flowchart showing the flow of the rights transfer process according to this embodiment. The process shown in this flowchart is executed when a start operation for the rights transfer process is performed on the user terminal 9b of a second user who wishes to acquire the rights to a digital asset put up for sale in the digital asset management system 100.

[0070] As described above, the put up NFTs are displayed in the marketplace of the digital asset management system 100. The user terminal 9b of a second user who wishes to acquire the rights to a digital asset put up for sale in the digital asset management system 100 requests a page on which the NFTs put up for sale in the marketplace of the digital asset management system 100 can be viewed from the server of the digital asset management system 100, and the NFT management unit 24 of the digital asset management system 100, which receives the request, sends marketplace data including a list of NFTs currently available for purchase and a user interface for purchasing to the user terminal 9b.

[0071] In steps S301 to S305, the user selects the NFT they wish to purchase and transmits the entered rights transfer information. The user terminal 9b, having received the marketplace data, outputs (e.g., displays on a display) a list of NFTs offered on the marketplace so that the user can view it. The user selects the desired NFT according to the user's operation and adds the selected NFT to a shopping cart (a so-called shopping cart used in e-commerce) (step S301). Then, upon receiving a user operation to proceed from the shopping cart to a purchase screen, the user terminal 9b transmits a purchase request to the digital asset management system 100 (step S302). Upon receiving the purchase request, the NFT management unit 24 of the digital asset management system 100 transmits purchase confirmation screen data, including a user interface for accepting rights transfer information input, to the user terminal 9b (step S303). Upon receiving the purchase confirmation screen data, the user terminal 9b outputs the purchase confirmation screen so that it can be viewed by the user (for example, displays it on a display), accepts input of information for the transfer of rights from the second user, including input of a payment method and an instruction to complete the order / payment (step S304), and transmits this information to the digital asset management system 100 (step S305). That is, once the seller puts the NFT up for sale on the marketplace and the seller (here, a user who purchased the NFT from the compatible service 5 or another user) and the buyer agree on the price of the NFT, the buyer transmits a request to purchase the NFT to the information processing device 1 and proceeds to the payment procedure. Processing then proceeds to step S306.

[0072] In steps S306 to S308, the NFT is transferred and payment value is assigned. The NFT management unit 24 of the digital asset management system 100, which has received the rights transfer information, identifies the wallets held by the first and second users by referencing the user IDs of the first and second users (step S306) and transfers the target NFT from the wallet of the first user to the wallet of the second user (step S307). The NFT management unit 24 of the digital asset management system 100 also assigns the value paid by the second user to the first user upon the transfer to the first user (step S308). Processing then proceeds to step S309.

[0073] In this case, the transfer of NFTs is preferably performed simultaneously and inseparably with the transfer of value to be received by the seller and / or rights holder (if the value is FT, the FT is transferred to the wallet of the seller and / or rights holder). For example, the NFT management unit 24 may process transactions to transfer NFTs and / or FTs based on a transaction format in the form of an Unspent Transaction Output (UTXO), or may process transactions to transfer NFTs and / or FTs in the form of a smart contract. Such transaction processing on the blockchain 7 is effective for enhancing transaction security, particularly in C2C transactions (including secondary transactions between users of NFTs once sold, as well as transactions in which general users sell NFTs as part of the corresponding service 5). However, the timing of NFT transfer is not limited to the example shown here.

[0074] In this embodiment, the type of value used as consideration for a transaction is not limited. The value used as consideration for a transaction may be cryptocurrency, legal tender, electronic value such as points issued by an administrator, or electronic money. In this embodiment, a credit card, debit card, electronic money, or the like is assumed as a payment method for paying legal tender, and a point management system of a point administrator is assumed as a payment method for paying points. However, the payment method is not limited to the examples given in this embodiment, and various known or future payment methods may be adopted, regardless of whether they are prepaid or postpaid. For example, when cryptocurrency is used for payment, a blockchain network for the target cryptocurrency is used as the payment method. When the value used as consideration for a transaction is cryptocurrency, the granting of the value may be recorded on the blockchain together with the transfer of the NFT.

[0075] In steps S309 to S311, notification of transaction completion is made. Once the transfer of the NFT and the assignment of value (if any) are complete, the NFT management unit 24 of the digital asset management system 100 notifies the user terminal 9a of the first user and the user terminal 9b of the second user that the transaction is complete (step S309). The user terminal 9a of the first user and the user terminal 9b of the second user that received the notification output a message indicating that the transaction has been completed so that the first user and the second user can confirm the message (steps S310 and S311). The processing shown in this flowchart then ends.

[0076] Note that a purchaser is not limited to purchasing one NFT at a time; a purchaser may purchase multiple NFTs at a time. Furthermore, multiple NFTs may be a pack containing multiple NFTs created by a seller. NFTs may also be sold as a pack containing one or more random NFTs. In this case, the NFT management unit 24 will move the NFT associated with the product randomly selected and acquired by the purchaser to the purchaser's wallet when transferring NFTs to the purchaser's wallet, as described below.

[0077] 11 is a diagram showing an overview of checkout according to this embodiment. When a user makes a checkout request to the corresponding service 5, the corresponding service 5 requests the digital asset management system 100 to burn the NFT related to the target digital asset. Upon receiving the request, the digital asset management system 100 burns the NFT related to the target digital asset and notifies the corresponding service 5. In addition to burning the NFT, the corresponding service 5 unlocks the status of the corresponding digital asset and grants the rights to the digital asset to the user of the account corresponding to the holder of the burned NFT. The flow of the checkout process according to this embodiment will be described below with reference to a flowchart.

[0078] 12 is a flowchart showing the flow of checkout processing according to this embodiment. The processing shown in this flowchart is executed when an operation to start checkout processing is performed on the user terminal 9 of a user who wishes to transfer the management entity of a digital asset that has been transferred from the corresponding service 5 to the digital asset management system 100 back to the corresponding service 5.

[0079] In steps S401 to S406, a list of digital assets available for checkout is presented and a checkout request is made. When the user initiates the checkout process, the user terminal 9 requests data for verifying the NFTs held by the user from the server of the corresponding service 5 (step S401). The corresponding service 5, having received the request, transmits a request to link the user IDs and a request to verify the NFTs held by the user with the linked user ID to the server of the digital asset management system 100 (step S402). Specifically, the corresponding service 5 calls an API for linking the user IDs and an API for verifying the NFTs held by the user with the linked user ID, both of which are provided by the digital asset management system 100.

[0080] The NFT management unit 24 of the digital asset management system 100, which has received a request to link a user ID and a request to confirm NFTs held by the user with the linked user ID, references the linked user ID and the wallet held by the user to obtain a list of NFTs held by the identified user and transmits the list to the corresponding service 5 (step S403). Then, the corresponding service 5, which has received the list, transmits a checkout-available NFT list, which is a list of NFTs from which NFTs being put up for sale have been removed from the list as options for checkout, to the user terminal 9 (step S404). However, the NFTs being put up for sale may have been removed at the time the digital asset management system 100 obtains the list, or may be removed when the corresponding service 5 transmits the list to the user terminal 9, or may be removed when the user terminal 9 displays the list.

[0081] The user terminal 9 that has received the list outputs (for example, displays on a display) a list of NFTs that the user of the user terminal 9 owns but that are not being put up for sale (checkout-available NFT list) so that the user can check it (step S405), accepts selection of the desired NFT from the user, and transmits a checkout request for the selected NFT to the corresponding service 5 (step S406). Then, the process proceeds to step S407.

[0082] In steps S407 to S411, the NFT of the digital asset to be checked out is burned, and the status of the digital asset related to the checkout request is unlocked and rights information is set. Upon receiving the checkout request, the corresponding service 5 transmits a request to link the user ID and a request to delete the target NFT to the server of the digital asset management system 100 (step S407). Specifically, the corresponding service 5 calls an API for linking the user ID and an API for deleting the target NFT, both of which are provided by the digital asset management system 100. In this case, the NFT to be deleted may be specified by a token ID.

[0083] The NFT invalidation unit 26 of the digital asset management system 100, which has received the request to link the user ID and the request to delete the target NFT, identifies the user's wallet and NFT by referencing the user ID and token ID, and performs an operation to burn the target NFT on the blockchain 7 (step S408), causing the blockchain 7 to burn the target NFT (step S409), transitioning the target NFT to an unusable state. Completion of the burning is notified to the server of the target service 5.

[0084] In conjunction with burning the target NFT, the unlock instruction unit 25 of the digital asset management system 100, instructing the server of the corresponding service 5 to set the digital asset related to the target NFT as the user who holds (possesses) the rights to the digital asset before the target NFT was burned, and unlocks the status of the digital asset (the digital asset to be checked out) (step S410). This allows the most recent user to use or dispose of the digital asset to be checked out. The corresponding service 5 then notifies the user terminal 9 of the user who holds the rights to the unlocked digital asset (i.e., the user who performed the checkout operation) that the digital asset has been unlocked and is now available for use, etc. (step S411). The process shown in this flowchart then ends.

[0085] 13 is a diagram showing an overview of digital asset usage according to this embodiment. A user who has been granted rights to a target digital asset through checkout can use or dispose of the digital asset in the corresponding service 5. For example, if the digital asset is a game item, the user can use, transfer, sell, or discard the item in the game. If the digital asset is a ticket, the user can use the ticket to participate in an event and can transfer or sell the ticket within the rules of the corresponding service 5. If the digital asset is an e-book, the user can read the e-book and can transfer or sell the e-book within the rules of the corresponding service 5.

[0086] Furthermore, in this embodiment, the digital asset management system 100 may perform a check-in process again for the check-out target digital asset that was unlocked by burning the target NFT, according to the aforementioned flowchart, etc. The NFT of the digital asset issued by the second check-in process is different from the NFT of the digital asset before the immediately preceding check-out process (the burned NFT). In other words, for the same digital asset, the token ID (NFT identifier) ​​of the NFT issued by the Nth (N>1, where N is a natural number) check-in process is different from the token ID of the NFT issued by the N-1th check-in process. This eliminates the need to comprehensively manage the NFTs corresponding to each of a vast group of digital assets, enabling the efficient use of blockchain networks in digital asset management.

[0087] <Effects> According to the technology disclosed in the above embodiment, in a specified service that manages digital assets without using non-fungible tokens, it is possible to improve the convenience and security of managing digital assets without building a function for using or disposing of digital assets that is based on non-fungible tokens into the specified service.

[0088] <First Variation> Although the above-described embodiment describes an example using one blockchain, the technology disclosed herein can employ multiple blockchains. For example, NFTs generated by a check-in process may be transferred to a public blockchain and traded on the public blockchain. Furthermore, the marketplace may support so-called multi-chain transfers of NFTs and / or FTs.

[0089] <Second Variation> In the embodiment described above, an NFT issued by check-in is assigned to the wallet of a first user and then listed on a marketplace in response to an operation by the first user, but a specification may be adopted in which an NFT issued by check-in is temporarily assigned to a generating wallet (administrator wallet) and then assigned to the wallet of the first user when the item is listed. Also, a specification may be adopted in which an NFT issued by check-in is temporarily assigned to a generating wallet (administrator wallet) and then assigned to the wallet of the second user when the item is transferred to the second user.

[0090] <Third Variation> In the above-described embodiment, check-in is performed by a user who is a seller. However, digital assets managed by a compatible service may be converted in response to a purchase request from a user who is a buyer. For example, if the compatible service is an e-book service, a user who wishes to purchase an e-book selects a desired e-book from a list of e-books sold on the compatible service and submits a purchase request. Upon receiving the purchase request, the compatible service performs a check-in process for the selected e-book, thereby converting management to the digital asset management system. The digital asset management system issues an NFT for the e-book and transfers the NFT to the user who is a buyer, thereby completing the purchase process for the e-book. The user who is a buyer issues a check-out request for the NFT attached to their wallet to the compatible service and / or the digital asset management system. Upon completion of check-out, the compatible service allows the user who is a buyer to view the e-book on an e-book reader. In this case, the compatible service may check the blockchain to confirm that the NFT has been burned before allowing viewing. The digital asset may be audio content or video content instead of an e-book. The corresponding service may be a streaming service for the digital asset or a download service for the digital asset.

[0091] <Fourth Variation> In the above-described embodiment, an example has been described in which a blockchain is used as a distributed ledger, but the distributed ledger that can be used to implement the technology according to the present disclosure is not limited to a so-called blockchain. A distributed ledger other than a blockchain may be used as long as it has the functions and configuration required to realize the technology according to the present disclosure.

[0092] 100 Digital asset management system 1 Information processing device 5 Corresponding service

Claims

1. A digital asset management system comprising: a lock instruction means for instructing a corresponding service to perform a locking process to restrict the use or disposal of a digital asset provided by the corresponding service and to which a first user has rights; a non-fungible token issuing means for issuing on a distributed ledger a non-fungible token, the holder of which is the first user, for the digital asset locked by the corresponding service, in association with metadata indicating data related to the digital asset; an unlock instruction means for instructing the corresponding service to perform an unlocking process to lift the restrictions on the use or disposal of the digital asset locked by the corresponding service, the unlock instruction means instructing the corresponding service to set a user corresponding to the holder of the non-fungible token at the time of the unlocking process as a user who has rights to the digital asset and unlock it; and a non-fungible token invalidation means for transitioning the non-fungible token related to the unlocking process to an unusable state during the unlocking process.

2. A digital asset management system as described in claim 1, further comprising a non-fungible token management means for changing the holder of the non-fungible token from the first user to a second user, wherein the unlock instruction means instructs the corresponding service to perform the unlock process by setting the second user, who has become the holder of the non-fungible token as a result of the holder change, as the user who has the rights to the digital asset and unlocking it.

3. The digital asset management system of claim 2, wherein the non-fungible token management means makes the non-fungible token available for purchase by other users including the second user by registering the non-fungible token in a marketplace in accordance with an operation of the holder of the non-fungible token, accepts a purchase operation from the second user for the non-fungible token registered in the marketplace, and, if the purchase is approved, changes the holder of the non-fungible token to the second user who performed the purchase operation.

4. A digital asset management system as described in claim 2, further comprising an account linking means for maintaining a correspondence between user identification information for identifying the user in the corresponding service and user identification information for identifying the holder of the non-fungible token in the digital asset management system, wherein the unlock instruction means instructs the corresponding service to set the second user identified by referring to the correspondence as a user having rights to the digital asset and unlock it.

5. The digital asset management system of claim 1, wherein the non-fungible token issuing means, when issuing the non-fungible token, records in the distributed ledger the metadata including data generated by the digital asset management system in addition to data related to the digital asset obtained from the corresponding service.

6. The digital asset management system of claim 5, wherein the non-fungible token issuing means inputs data on a digital asset into a trained model having data related to the digital asset as input values ​​and attribute data of the digital asset as output values, and outputs estimated attribute data as output, thereby generating data to be included in the metadata, and recording the metadata including the generated data in the distributed ledger.

7. The digital asset management system of claim 1, wherein the non-fungible token issuing means, when issuing the non-fungible token, records in the distributed ledger the metadata including data related to the digital asset obtained from the corresponding service, as well as data obtained by the digital asset management system from services other than the corresponding service.

8. The digital asset management system according to claim 1, wherein the non-fungible token invalidation means, upon the unlocking process, burns the non-fungible token related to the unlocking process, thereby transitioning the non-fungible token to an unusable state.

9. The digital asset management system of claim 1, wherein the digital assets provided by the corresponding services include any of game items or game data provided by a game service, electronic tickets or physical ticket reservation rights provided by a ticket service, e-book viewing rights provided by an e-book service, and service usage rights provided by any service.

10. A method in which a computer of a digital asset management system executes the following steps: a lock instruction step of instructing a corresponding service to perform a locking process to restrict the use or disposal of a digital asset provided by the corresponding service and to which a first user has rights; a non-fungible token issuance step of issuing a non-fungible token, whose holder is the first user, on a distributed ledger for the digital asset locked by the corresponding service, in association with metadata indicating data related to the digital asset; an unlock instruction step of instructing the corresponding service to perform an unlocking process to lift restrictions on the use or disposal of the digital asset locked by the corresponding service, the unlock instruction step instructing the corresponding service to set a user corresponding to the holder of the non-fungible token at the time of the unlocking process as a user who has rights to the digital asset and unlock it; and a non-fungible token invalidation step of transitioning the non-fungible token related to the unlocking process to an unusable state during the unlocking process.

11. A program for causing a computer of a digital asset management system to execute the following steps: a lock instruction step of instructing a corresponding service to perform a locking process to restrict the use or disposal of a digital asset provided by the corresponding service and to which a first user has rights; a non-fungible token issuance step of issuing a non-fungible token, whose holder is the first user, on a distributed ledger for the digital asset locked by the corresponding service, in association with metadata indicating data related to the digital asset; an unlock instruction step of instructing the corresponding service to perform an unlocking process to lift restrictions on the use or disposal of the digital asset locked by the corresponding service, the unlock instruction step instructing the corresponding service to set a user corresponding to the holder of the non-fungible token at the time of the unlocking process as a user who has rights to the digital asset and unlock it; and a non-fungible token invalidation step of transitioning the non-fungible token related to the unlocking process to an unusable state during the unlocking process.

Images