Non-fungible token generation system and non-fungible token generation method

Abstract

To avoid the complexity of holding NFTs in stock in order to facilitate provision of the NFTs.SOLUTION: A non-fungible token generation system is configured to: receive a non-fungible token request including identification information; identify the type of a target non-fungible token to be generated, on the basis of the identification information included in the non-fungible token request; generate the target non-fungible token of the identified type; and transmit the generated target non-fungible token. The system can generate a plurality of types of target non-fungible tokens.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a non-fungible token generation system and a non-fungible token generation method. This application claims priority based on Japanese Application No. 2021-053535 filed on March 26, 2021, and incorporates all the descriptions described in the above Japanese application.

Background Art

[0002] Patent Document 1 discloses Ethereum, which is an example of a blockchain. The cryptocurrency (virtual currency) used in Ethereum is called Ether. Ether has fungibility, similar to legal tender. That is, Ether is a type of fungible token (fungible token).

[0003] Tokens that can be used in blockchains such as Ethereum include, in addition to fungible tokens, non-fungible tokens (Non-Fungible Token; non-fungible token, hereinafter sometimes referred to as "NFT"). NFTs are tokens issued in accordance with, for example, the Ethereum Request for Comments (ERC) 721 standard. NFTs compliant with the ERC721 standard are called NFT-721 tokens.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] NFTs may be provided upon request for purposes such as sales. For example, a system for selling NFTs is configured to transmit purchased NFTs to prospective buyers upon request. In this case, the system needs to maintain a large inventory of NFTs in advance to prepare for the possibility of many NFTs being purchased.

[0006] When a system holds NFTs as inventory, inventory management becomes complicated. For example, if there are few NFTs in inventory, there is a risk of running out of stock. Conversely, to avoid running out of stock, the system administrator needs to generate a huge number of NFTs in advance and store them in the system. If the system is allowed to hold a large amount of NFTs as inventory, the system administrator will bear the burden of generating a huge number of NFTs in advance. In particular, if the system is configured to provide multiple types of NFTs, it becomes necessary to prepare a large number of NFTs for each type, which is extremely complicated.

[0007] Furthermore, while it might be possible to generate the necessary NFTs only after the need arises, obtaining information on what kind of NFTs should be generated can be difficult. This could lead to time-consuming and cumbersome NFT generation processes.

[0008] Therefore, in order to facilitate the provision of NFTs, it is desirable to avoid the complexities described above.

[0009] One aspect of this disclosure is a nonfungible token generation system. The system of the disclosure is configured to receive a nonfungible token request having identification information, identify the type of purpose nonfungible token to be generated based on the identification information in the nonfungible token request, generate the purpose nonfungible token of the identified type, and transmit the generated purpose nonfungible token, and is capable of generating multiple types of purpose nonfungible tokens. The system of the disclosure is a nonfungible token generation system configured to perform a process for generating nonfungible tokens, comprising a database having multiple source data, wherein the process for generating nonfungible tokens may include receiving a nonfungible token request having identification information, and generating a nonfungible token using data selected from the multiple source data in the database based on the received identification information.

[0010] Another aspect of this disclosure is a method for generating a nonfungible token performed by a fungible token generation system. The method of disclosure comprises receiving a nonfungible token request having identification information, generating a purpose nonfungible token of a type identified based on the identification information in the nonfungible token request, and transmitting the generated purpose nonfungible token. The method of disclosure is a method for generating a nonfungible token performed by a nonfungible token generation system, wherein the nonfungible token generation system comprises a database comprising a plurality of material data, and the method may comprise receiving a nonfungible token request having identification information, and generating a nonfungible token using data selected from the plurality of material data in the database based on the received identification information.

[0011] Further details will be described in the embodiments below. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 is a diagram illustrating the configuration of a non-fungible token generation system according to the first embodiment. [Figure 2] Figure 2 is an explanatory diagram illustrating the relationship between box NFTs, pack NFTs, and card NFTs. [Figure 3] Figure 3 is a timing chart for the NFT generation process. [Figure 4] Figure 4 shows the operation screen on the user terminal. [Figure 5] Figure 5 is a flowchart showing the operations and procedures for making an NFT request on a user terminal. [Figure 6] Figure 6 is a flowchart of the target NFT generation process. [Figure 7] Figure 7 is a diagram illustrating the structure of a smart contract. [Figure 8] Figure 8 is a flowchart of the processing performed by the first module. [Figure 9] Figure 9 is a flowchart of the processing performed by the second module. [Figure 10] Figure 10 is a flowchart of the processing performed by the third module. [Figure 11] Figure 11 is a flowchart of the processing performed by the fourth module. [Figure 12] Figure 12 is a flowchart of the processing performed by the fifth module. [Figure 13] Figure 13 is a diagram illustrating the configuration of a non-fungible token generation system according to the second embodiment. [Figure 14] Figure 14 is a flowchart of the processing by the smart contract according to the second embodiment. [Figure 15] Figure 15 is a diagram illustrating the configuration of a non-fungible token generation system according to the third embodiment. [Figure 16] Figure 16 is a flowchart of the processing performed by the smart contract according to the third embodiment. [Figure 17] Figure 17 is an explanatory diagram illustrating the generation of the objective non-fungible token. [Figure 18] FIG. 18 is a configuration diagram of a non-fungible token generation system according to the fifth embodiment. [Figure 19] FIG. 19 is a configuration diagram of a non-fungible token generation system according to the sixth embodiment. [Figure 20] FIG. 20 is a configuration diagram of a non-fungible token generation system according to the seventh embodiment. [Figure 21] FIG. 21 is a configuration diagram of a non-fungible token generation system according to the eighth embodiment.

Embodiments for Carrying Out the Invention

[0013] <1. Overview of a Non-Fungible Token Generation System and a Method Executed by the Non-Fungible Token Generation System>

[0014] (1) A non-fungible token generation system according to an embodiment (hereinafter sometimes simply referred to as the "system") is configured to generate non-fungible tokens. Transactions of non-fungible tokens and fungible tokens may be recorded on the blockchain. Owners of non-fungible tokens may be recorded on the blockchain. Non-fungible tokens recorded on the blockchain may be made public on the blockchain and may be referable. Non-fungible tokens may be used, for example, as items or characters traded in computer games, digital trading cards, digital tickets, digital certificates, or other digital data. Digital trading cards are also called digital collectible cards. Non-fungible tokens may, for example, be tokens issued in accordance with the Ethereum Request for Comments (ERC) 721 standard. Non-fungible tokens may have their own value that distinguishes them from other non-fungible tokens. For this reason, non-fungible tokens have a unique identifier that enables them to be distinguished from other non-fungible tokens. The identifier of an NFT may be, for example, an address or other identifier that points to the non-fungible token on the blockchain. The identifier for an NFT is also called the NFT-ID.

[0015] The system according to this embodiment may consist of a single computer or a computer network consisting of multiple computers. The computer network may be, for example, the internet. The computer network may be a P2P computer network. A P2P computer network is, for example, a network in which multiple computers are connected by the internet. The system may include a computer network that constitutes a blockchain.

[0016] The provision of non-fungible tokens by the system is, for example, for the sale, transfer, or exchange of non-fungible tokens for other non-fungible tokens. Non-fungible tokens provided by the system for sale, transfer, or exchange are called purpose non-fungible tokens. Purpose non-fungible tokens are provided when the system transmits them.

[0017] The system according to this embodiment may be configured, for example, to receive a non-fungible token request, generate a target non-fungible token in response to the non-fungible token request, and transmit the target non-fungible token. The number of target non-fungible tokens generated may be one or more. The system can generate a target non-fungible token as a trigger upon receiving a non-fungible token request. The system can generate a target non-fungible token in response to a non-fungible token request each time it receives one. The system does not need to possess a target non-fungible token in response to a non-fungible token request prior to receiving one. In other words, the system does not need to maintain an inventory of target non-fungible tokens to be provided.

[0018] The aforementioned non-fungible token request is, for example, a command requesting the system to send a target non-fungible token. The non-fungible token request is, for example, a command indicating a desire to purchase or acquire a target non-fungible token, or a command indicating a desire to exchange one non-fungible token for a target non-fungible token. The non-fungible token request may explicitly request the system to send a target non-fungible token, or it may be a command that does not express an explicit request, but allows the system to determine that sending a target non-fungible token is necessary in response to its reception. For example, the system may be configured to consider the reception of a token as a non-fungible token request. A token considered as a non-fungible token request is called a "requested token." A requested token is, for example, a fungible token or a non-fungible token. The non-fungible token request may also include a requested token and information other than the token. The requested token may be sent together with a command as a non-fungible token request.

[0019] The nonfungible token request may be sent to the system via the network. The sender of the nonfungible token request may be, for example, the terminal of the user receiving the target nonfungible token, a third-party computer operating on behalf of the user receiving the target nonfungible token, or any other computer that will receive the target nonfungible token. If the transmission of the nonfungible token request includes the transmission of a request token, the sender of that request token is the account of the user who owns the request token (the user's address on the blockchain). The recipient of the target nonfungible token may be the sender of the nonfungible token request or a recipient other than the sender of the nonfungible token request. The recipient of the target nonfungible token may be, for example, the account of the user who owns the request token (the user's address on the blockchain).

[0020] The system may generate and transmit one purpose nonfungible token in response to a single nonfungible token request. Alternatively, the system may generate and transmit multiple purpose nonfungible tokens in response to a single nonfungible token request. In this case, the system can provide multiple purpose nonfungible tokens in a single transaction.

[0021] The system can generate multiple types of purpose-specific nonfungible tokens. In this case, the system can provide various types of purpose-specific nonfungible tokens. The system can also generate multiple types of purpose-specific nonfungible tokens in response to a single nonfungible token request. In this case, the system can provide multiple types of purpose-specific nonfungible tokens at once. The type of purpose-specific nonfungible token may be, for example, the type of NFT of the purpose-specific nonfungible token described below, or it may be a category or genre of the purpose-specific nonfungible token. The type of purpose-specific nonfungible token can be identified by the system. The category may indicate, for example, the classification set for the card NFT described below. The type may indicate, for example, the classification of card NFT, pack NFT, box NFT described below. The type of purpose-specific nonfungible token may be the type of ticket NFT described below, or the type of certificate NFT described below.

[0022] Here, "type" may be distinguished by the differences between each individual nonfungible token, but preferably, it is a property that can be identified by the system as common to two or more nonfungible tokens. If multiple nonfungible tokens are of the same type, at least a portion of the constituent data that makes up the nonfungible token may be common. Conversely, if the types of nonfungible tokens are different, the constituent data that makes up the target nonfungible token may be different.

[0023] The nonfungible token request may have identification information. This identification information may be used to identify the type of purpose nonfungible token to be generated. Because the nonfungible token request has this identification information, when the system receives the request, it can identify the type of purpose nonfungible token to be generated and generate an appropriate purpose nonfungible token according to the request. Therefore, a system receiving a nonfungible token request can autonomously generate the appropriate type of purpose nonfungible token.

[0024] The aforementioned identification information may be the nonfungible token request itself. For example, if multiple commands for a nonfungible token request are available, corresponding to multiple types of the target nonfungible token, the nonfungible token request itself may be used to identify the type of target nonfungible token.

[0025] The aforementioned identification information may be information included in a non-fungible token request. For example, a command used in common for multiple types of purpose non-fungible token requests may include a parameter indicating the type of purpose non-fungible token.

[0026] The aforementioned identification information may be information transmitted with the non-fungible token request. For example, information transmitted with a non-fungible token request may be, for example, a non-fungible token, a fungible token, or other digital data to be exchanged for a target non-fungible token. Here, "transmitted with a non-fungible token request" does not mean that the information must be transmitted exactly at the same time as the non-fungible token request; it is sufficient if the information is associated with or linked to the non-fungible token request and can be substantially considered to have been transmitted with the non-fungible token request, even if there is some time difference. The aforementioned identification information may be the number or type of the requested tokens.

[0027] If a non-fungible token request includes request-transmitting tokens, the identification information may be, for example, the number of request-transmitting tokens. Request-transmitting tokens are, for example, fungible tokens used as consideration for purchasing a target non-fungible token. In this case, the type of target non-fungible token may be identified according to the number of fungible tokens as request-transmitting tokens. The number of non-fungible tokens as request-transmitting tokens may correspond to the price of the target non-fungible token. The identification information may also be the number of non-fungible tokens as request-transmitting tokens. The identification information may also be the type of request-transmitting tokens. Request-transmitting tokens are, for example, other non-fungible tokens exchanged for a target non-fungible token. In this case, the type of target non-fungible token may be identified according to the type of non-fungible token as request-transmitting tokens. The identification information may also be information indicating the difference between whether the request-transmitting tokens are non-fungible tokens or fungible tokens. In this case, for example, if the request transmission token is a non-fungible token, the target non-fungible token may be identified as a first type, and if the request transmission token is a fungible token, the target non-fungible token may be identified as a second type.

[0028] The aforementioned identification information may be any one of the aforementioned identification information pieces or a combination of two or more. Using a combination of two or more pieces of information makes it easier to identify the appropriate type from among various types.

[0029] Generating the aforementioned nonfungible token may involve generating the aforementioned nonfungible token of a type identified based on the identification information. In this case, the system can generate the appropriate type of nonfungible token identified based on the identification information contained in the nonfungible token request. Therefore, the system does not need to have a prior stock of each type of nonfungible token. The system can generate nonfungible tokens using material data it possesses even before receiving a nonfungible token request. The system can determine the material data used for generating nonfungible tokens based on the identification information.

[0030] (2) Receiving the non-fungible token request includes receiving a request sending token which is a fungible token or a non-fungible token, and the type of the target non-fungible token is preferably identified using the number or type of the request sending token as the identification information.

[0031] (3) Preferably the system is configured to receive both fungible tokens and non-fungible tokens as request transmission tokens. Preferably, when a fungible token is received as a request transmission token, the type of the target non-fungible token is identified based on the number of fungible tokens received as request transmission tokens, and when a non-fungible token is received as a request transmission token, the type of the target non-fungible token is identified based on the type of non-fungible token received as a request transmission token.

[0032] (4) The system may include a contract computer that executes smart contracts on the blockchain. A smart contract is software (computer program) that is executed by computers that make up the blockchain. A smart contract is implemented on the blockchain, for example, by the system administrator, so that it is executed on the blockchain. A contract computer is one of the computers that make up the computer network system that makes up the blockchain. The computer that functions as a contract computer among the multiple computers that make up the computer network that makes up the blockchain may change dynamically.

[0033] Preferably, the smart contract is configured to receive a non-fungible token request having the identification information, identify the type of target non-fungible token to be generated based on the identification information in the non-fungible token request, generate the identified type of target non-fungible token, and transmit the generated target non-fungible token. Preferably, the contract computer is capable of generating multiple types of target non-fungible tokens. In the system, a user computer that accepts user selection operations may be used. Preferably, the user computer is configured to identify the number or type of requested tokens in accordance with the user's selection operation and to transmit the identified number or type of requested tokens to the smart contract. In this case, the number or type of requested tokens in accordance with the user's selection operation is identified, and that number or type of requested tokens may become the identification information. The source of the requested tokens is, for example, the user's account on the blockchain (the user's address on the blockchain), in which case the user computer will perform the request token transmission process on behalf of the user. The user computer is, for example, the server 350 or user terminal 300 described later. The user computer only needs to be a computer that operates for the user and does not need to be owned by the user. In other words, the user computer does not need to be the user terminal 300, but may be a server owned or managed by someone other than the user (for example, the system administrator).

[0034] (5) The generation of the non-fungible token preferably includes generating the target non-fungible token using data selected from a plurality of material data based on the received identification information. The use of data selected based on the identification information may be the selected material data itself, or a copy of the selected material data may be used. The generation of the non-fungible token preferably includes incorporating configuration data into the initial non-fungible token issued by executing the non-fungible token issuance process in the blockchain. The configuration data is preferably generated based on the identification information. The material data is preferably stored in the system in association with the identification information, or in association with the type identified based on the identification information.

[0035] The process of issuing non-fungible tokens on a blockchain is carried out, for example, by executing a command for issuing non-fungible tokens. This command is provided, for example, on the blockchain where the non-fungible tokens are issued. The non-fungible token issuance process is executed on the computers that make up the blockchain. Non-fungible tokens issued through this process are assigned a non-fungible token identifier (NFT-ID). This identifier is assigned to each non-fungible token to uniquely identify it. The non-fungible token identifier may be the address of the non-fungible token on the blockchain, or it may be any other identifier. The system may retrieve the identifier of the issued non-fungible token.

[0036] The initial nonfungible token is a token issued by the nonfungible token issuance process and may be an incomplete nonfungible token in which the configuration data has not been incorporated. The target nonfungible token is completed when the configuration data is incorporated into the initial nonfungible token. The initial nonfungible token has at least a nonfungible token identifier. In addition to the identifier, the initial nonfungible token may also contain other necessary information. The incorporation of the configuration data may occur almost simultaneously with the issuance of the initial nonfungible token, or it may occur after the issuance of the initial nonfungible token.

[0037] The aforementioned configuration data is, for example, at least one of image data, sound data, and text data. The aforementioned configuration data may be a single data or a combination of multiple data. Image data and text data may be used to display the non-fungible tokens held by the user or a third party on their terminal. Sound data may be output along with the display of image data or text data on the terminal of the user or a third party holding the non-fungible token. Image data may be video data or still image data. Image data may correspond to the subject matter of the trading cards described later, the contents of the tickets described later, or the contents of the warranty certificate or the product covered by the warranty described later.

[0038] Since the configuration data can be generated based on the type identified based on the identification information, appropriate configuration data corresponding to the type can be incorporated into the initial nonfungible token. For purpose nonfungible tokens of the same type, at least one common data corresponding to that type can be incorporated as the configuration data. In other words, if multiple purpose nonfungible tokens are of the same type, those purpose nonfungible tokens may have at least one common configuration data. Also, if multiple purpose nonfungible tokens are of different types, there may be differences in configuration data corresponding to the difference in type. Even with such differences in the types of purpose nonfungible tokens, the system can identify the type from the nonfungible token request and determine the appropriate configuration data.

[0039] (6) The objective nonfungible token preferably has an identifier that indicates a copy of the selected data.

[0040] The identifier indicating the replicated data is preferably a uniform resource identifier indicating the replicated data. The non-fungible token issuance process is preferably performed after receiving the non-fungible token request. In this case, there is no need to issue the initial non-fungible token before receiving the non-fungible token request and prepare it as inventory in advance. The configuration data is preferably generated as unique data for the target non-fungible token using material data determined using the identification information from among multiple material data that can also be used to generate other configuration data. In this case, the configuration data incorporated into the target non-fungible token becomes unique data for each individual target non-fungible token, easily creating scarcity value. The configuration data can be generated by replicating material data that is commonly used to generate other configuration data. Some configuration data can be saved with a different file name or in a different location than other configuration data, making it unique and distinguishable from other configuration data even if the data content is the same. The configuration data can be more easily distinguished from other configuration data by adding data such as a serial number, other characters or symbols, or image data to the data obtained by replicating the material data. Incorporating the configuration data into the initial non-fungible token is preferably done by associating the identifier of the configuration data with the initial non-fungible token. The identifier of the configuration data is, for example, the uniform resource identifier (URI) of the configuration data. The URI is, for example, a uniform resource locator (URL). The generated configuration data is stored, for example, on a data server on the internet, and the URI or URL can function as an identifier indicating the configuration data stored on that data server. The URI may also be a uniform resource name (URN).

[0041] (8) Preferably the system is configured to further identify the number of target nonfungible tokens to be generated based on the identification information. In this case, the identification information is also used as information for identifying the number of target nonfungible tokens to be generated.

[0042] The system may comprise a first computer and a second computer. The first computer and the second computer may each consist of a single computer or multiple computers connected via a network. The first computer may be a computer network system that constitutes a blockchain. Preferably, the first computer and the second computer are connected via a network. Preferably, the second computer contains multiple source data that are candidates or sources for the configuration data.

[0043] Preferably, the first computer is configured to perform a first process that includes at least receiving the non-fungible token request, identifying the type using the information contained in the non-fungible token request, and issuing the initial non-fungible token by executing the non-fungible token issuance process. Since the first process includes a non-fungible token issuance process in the blockchain, it is preferable that it is executed by a smart contract implemented in the blockchain.

[0044] The second computer is preferably configured to perform a second process of selecting material data to be the configuration data from among the plurality of material data according to the type identified by the first computer. The second process may further include saving a copy of the selected material data as the configuration data. A URI (URL) indicating the saved configuration data is provided from the second computer to the smart contract (first computer), and the smart contract (first computer) can associate the URI (URL) with an initial non-fungible token. The second computer is preferably a computer provided separately from the blockchain. The second computer is, for example, a server computer managed by the system administrator.

[0045] By executing the first and second processes on separate computers, each process can be managed independently, making management easier. In particular, since the second process handles a wide variety of material data, separating it from the first process allows for avoidance or minimization of changes to the first process even if the material data changes. Furthermore, since smart contracts sometimes have limitations on the amount of program code that can be written (the number of processes that can be written), if the first process is executed by a smart contract, separating the first and second processes makes it easy to avoid an increase in the number of processes in the first process.

[0046] The second process is preferably executed when the second computer detects that the first computer has issued the initial non-fungible token. In this case, the second process can be started as a trigger when the first computer issues the initial non-fungible token. The second computer may detect that the first computer has issued the initial non-fungible token by receiving a notification from the first computer. Alternatively, the second computer may monitor the behavior of the first computer (the smart contract that executes the first process) and spontaneously detect that the initial non-fungible token has been issued without notification from the first computer. Since the issuance of non-fungible tokens and the contents of the issued non-fungible tokens are recorded in a recordable format on the blockchain, the second computer may detect the issuance of initial non-fungible tokens by the first computer by checking the non-fungible token issuance status and contents on the blockchain.

[0047] The first computer (smart contract) may issue an initial nonfungible token that contains information indicating the type of target nonfungible token. In this case, the second computer can refer to the information contained in the issued initial nonfungible token on the blockchain, identify the type of target nonfungible token, determine appropriate configuration data according to that type, and incorporate that configuration data into the initial nonfungible token.

[0048] The second computer may be configured to obtain from the first computer generation conditions that include information indicating the type of the target nonfungible token.

[0049] (9) Receiving the nonfungible token request may include receiving a request token which is a nonfungible token. The nonfungible token which is a request token preferably has identification information used to identify the type of the target nonfungible token to be generated. The identification information of the nonfungible token which is a request token is, for example, information indicating the type of the nonfungible token which is a request token. The system can identify the target nonfungible token to be generated based on the identification information of the nonfungible token which is a request token. The identification information may also have information used as configuration data incorporated into the target nonfungible token. In this case, the system can generate the target nonfungible token by using the information of the nonfungible token which is a request token as at least part of the configuration data incorporated into the target nonfungible token.

[0050] (10) The identification information of the nonfungible token request preferably includes data indicating one of the plurality of material data. The system preferably includes a generation private key for generating the target nonfungible token and is configured to generate the target nonfungible token using the generation private key.

[0051] A method according to an embodiment may be a method for generating a nonfungible token performed by a nonfungible token generation system. The method includes receiving a nonfungible token request having identification information, generating a purpose nonfungible token of a type identified based on the identification information in the nonfungible token request, and transmitting the generated purpose nonfungible token. Another method according to an embodiment is a method for generating a nonfungible token performed by a nonfungible token generation system, the nonfungible token generation system may include a database containing a plurality of material data. The method may include receiving a nonfungible token request having identification information, and generating a nonfungible token using data selected from the plurality of material data in the database based on the received identification information. A system according to an embodiment is a nonfungible token generation system configured to perform a process for generating a nonfungible token, and may include a database containing a plurality of material data. The process for generating a nonfungible token may include receiving a nonfungible token request having identification information, and generating a nonfungible token using data selected from the plurality of material data in the database based on the received identification information. Preferably, the system includes a generation private key for generating the non-fungible token and is configured to generate the non-fungible token using the private key.

[0052] The computer program according to the embodiment causes a processor to execute at least one of the disclosed processes. The computer program is stored in a computer-readable, non-temporary storage medium.

[0053] <2. Examples of nonfungible token generation systems and methods implemented by nonfungible token generation systems>

[0054] Preferred embodiments will be described below with reference to the drawings. The following description is an example of a preferred embodiment and does not limit the present invention.

[0055] <2.1 First Embodiment: Card NFT Generation System>

[0056] Figure 1 shows an example of a non-fungible token generation system 10 (NFT generation system) according to the first embodiment. The system 10 according to the first embodiment may include a smart contract 101 implemented in a computer network system 100 such as a blockchain. The smart contract 101 is software (computer program) implemented in the computer network system 100 (first computer) such as a blockchain, and automatically executes a predetermined protocol. The smart contract 101 according to the embodiment has a contract address, which is an address in the blockchain. The smart contract 101 is stored in the contract address. The smart contract 101 is executed by being called by another computer. The computer that calls the smart contract 101 is, for example, a server 350 that operates on behalf of a user, or a user terminal 300. The server 350 is, for example, an application server accessed by the user terminal 300. The server 350 may constitute the system 10. The server 350 may be located on a network such as the Internet. The smart contract 101 is configured to execute an NFT generation process (first process) according to the embodiment. The blockchain is composed of a P2P computer network in which multiple computers are interconnected, as shown in Figure 1. The smart contract 101 can be executed by any of the multiple computers that make up the computer network system 100.

[0057] The system 10 according to the first embodiment includes a server 200 (second computer). The server 200 assists, for example, in processing in the smart contract 101 (first processing; NFT generation processing). The server 200 may also assist in processing in the user terminal 300, which will be described later. The server 200 may also perform other processing for the management of the system 10. The system 10 may also include the aforementioned server 350 as one of its components.

[0058] Server 200 (second computer) is connected to computer network system 100 (first computer), on which smart contract 101 is implemented, via a network such as the Internet. Server 200 and smart contract 101 can communicate with each other.

[0059] Server 200 is comprised of a computer comprising a processor 210 and memory 220. The aforementioned server 350 is similar. Servers 200 and 350 may be comprised of multiple computers. Memory 220 is connected to the processor 210. Memory 220 comprises, for example, primary storage and secondary storage. Primary storage is, for example, RAM. Secondary storage is, for example, a hard disk drive (HDD) or solid-state drive (SSD). Memory 220 contains a computer program 260 executed by the processor 210. The processor 210 reads and executes the computer program 260 stored in memory 220. The computer program 260 has program code for processing to be performed by server 200. Processing to be performed by server 200 includes, for example, the NFT configuration data embedding process 212 (second process) described later.

[0060] The memory 220 includes a database 230. The database 230 includes, for example, NFT material data 240 (a database of material data). The database 230 contains multiple material data. The system 10 can generate a non-fungible token using data selected from the multiple material data. The database 230 may further include NFT generation rules 250. The NFT material data 240 and NFT generation rules 250 will be described later. The database 230 contains material data even before receiving a non-fungible token request (NFT request) as described later. Therefore, when generating an NFT, the system 10 does not need to receive material data it already possesses from outside the system 10.

[0061] The system 10 according to the first embodiment generates digital card NFTs in order to provide a service for selling and exchanging digital card NFTs. The system 10 may also provide a service for distributing digital card NFTs free of charge. The system 10 can communicate via a network with a terminal 300 (user terminal) owned by a user who wishes to purchase or exchange a digital card NFT. The user terminal 300 is, for example, a smartphone, tablet, wearable device, personal computer, or other computer owned by the user. The system 10 according to the first embodiment is configured to generate multiple types of NFTs (digital card NFTs; purpose NFTs). When the system 10 according to the first embodiment receives a non-fungible token request generated based on an operation by a user who wishes to acquire an NFT, it is configured to generate an NFT and record on the blockchain that the owner of the generated NFT is the user. For example, the system 10 according to the first embodiment generates an NFT of a type selected by the user from among multiple types of NFTs and sends it to the user (user account on the blockchain). The database 230 may contain material data corresponding to each of the multiple types. System 10 can select material data corresponding to the type of NFT to be created from among the multiple material data contained in database 230, and generate an NFT using the selected data. In addition to material data, System 10 may also generate an NFT using data received from outside System 10.

[0062] The digital card NFT provided by the system 10 according to the first embodiment is, for example, a digital trading card that has been converted into an NFT. NFT conversion means recording data or identifiers such as URIs that directly or indirectly represent the data as tokens on the blockchain. The digital card is a digitized trading card. The digital trading card is displayed on a computer screen. Hereinafter, the digital card NFT will be referred to as a card NFT (cardNFT). The card NFT can be traded with any third party. Transaction records of the card NFT and past and present owners of the card NFT are recorded on the blockchain. The card NFT and other NFTs can also be traded on exchange computers outside of the system 10.

[0063] Trading cards are also called collectible cards. Trading cards have various images corresponding to the subject matter of the trading card and are sold for collection or exchange. The subject matter images include, for example, celebrities, singers, athletes, other famous people, characters from comics, games, and animation, game items, vehicles, machines, tools, animals, plants, etc. Images are displayed on the computer screen of the card NFT holder or a third party's computer that can access the card NFT, for display purposes. Trading cards may have different values ​​depending on the subject matter image, etc. Trading cards with a small number of issued cards may have rarity value.

[0064] As shown in Figure 2, the card NFT according to this embodiment is composed of image data D1, D2, D3, etc., which serve as the subject matter for the card NFT. In addition, the card NFT according to this embodiment is assigned multiple categories C1, C2, C3. Categories C1, C2, and C3 are types of card NFTs set by the system administrator and indicate the rank, genre, or characteristics of the card NFT. Even if card NFTs have the same image data D1, D2, and D3, if the categories C1, C2, and C3 assigned to the card are different, they will be treated as different types of card NFTs. Therefore, if the number of categories is M and the number of subject matter image data prepared in the system 10 is N, the number of types of card NFTs can be M × N. Thus, a very large number of types of card NFTs can exist, increasing the enjoyment of collecting and exchanging card NFTs for users.

[0065] In one embodiment, card NFTs may be sold or traded in units called packs. One pack can be exchanged for one or more card NFTs using system 10. In other words, the holder of a pack has the right to exchange the pack for one or more card NFTs. However, the user does not know what kind of card NFTs the pack will be exchanged for until the exchange actually takes place. In the first embodiment, the pack is also NFTized. An NFTized pack is called a pack NFT (packNFT).

[0066] In this embodiment, the pack NFT only indicates that it is exchangeable for one or more card NFTs, and does not indicate what card NFTs the pack NFT will actually be exchanged for before the exchange. Furthermore, the pack NFT does not contain the card NFTs that will be exchanged for it, nor does it contain any information about the card NFTs that will be exchanged for it. Therefore, even if a user possesses a pack NFT, they will not know what card NFTs the pack NFT will be exchanged for until the exchange actually takes place. As a result, a user who possesses a pack NFT can have an experience similar to that of possessing an unopened physical pack. That is, just as an unopened physical pack containing trading cards offers the enjoyment of not knowing what trading cards are inside until it is opened, a pack NFT also offers the enjoyment of not knowing what card NFTs will be obtained until they are exchanged for them.

[0067] Pack NFTs can be traded with any third party. Transaction records and past and present NFT ownership are recorded on the blockchain. Because pack NFTs are tradable, they can also be resold. If a particular type of pack NFT is sold in limited quantities, it can be expected to have scarcity value.

[0068] As shown in Figure 2, examples of pack NFTs include pack6NFT, which can be exchanged for six card NFTs, and pack3NFT, which can be exchanged for three card NFTs. The availability of multiple types of pack NFTs improves user convenience.

[0069] In one embodiment, pack NFTs can be sold or traded in units called boxes. One box can be exchanged for multiple pack NFTs using the system. Here, as an example, as shown in Figure 2, one box can be exchanged for six pack6NFTs. In other words, the holder of a box has the right to exchange the box for six packs. In the first embodiment, the box is also NFT-enabled. An NFT-enabled box is called a box NFT (boxNFT).

[0070] In this embodiment, the box NFT merely indicates that it is interchangeable with multiple pack NFTs, and does not indicate which pack NFT it will actually be exchanged with before the exchange. Furthermore, the box NFT does not contain the pack NFTs that it will be exchanged with, nor does it contain any information about the pack NFTs that it will be exchanged with.

[0071] Box NFTs can be traded with any third party. Transaction records and past and present owners of Box NFTs are recorded on the blockchain. Because Box NFTs are tradable, they can also be resold. If a particular type of Box NFT is sold in limited quantities, scarcity value can be expected.

[0072] As described above, the NFTs provided by the system 10 according to the first embodiment include three types: card NFTs, pack NFTs, and box NFTs. In other words, the NFTs provided by the system 10 according to the first embodiment include at least three types. Furthermore, the card NFTs provided by the system 10 according to the first embodiment have M categories. In other words, the card NFTs provided by the system 10 according to the first embodiment include at least M types. Thus, the system 10 according to the first embodiment can provide the user with multiple types of NFTs. In this embodiment, the type (type or category) set for each NFT can be identified by the system 10 using the identification information that each NFT possesses. The identification information may be image data possessed by each NFT, in which case the type of image data represents the type of NFT. The identification information may also be characters or symbols representing the type of NFT possessing that identification information. Note that if the NFT that is a request transmission token has identification information indicating the type of NFT, the NFT that is a request transmission token itself can be used as identification information to identify the type of target NFT. Specifically, the identification information held by the NFT, which is the request transmission token, can be used as identification information to identify the type of non-fungible token to be generated.

[0073] Furthermore, if the number of image data types embedded in the card NFT is N, then the card NFTs provided by the system 10 according to the first embodiment will have at least N types. In addition, considering the categories of card NFTs and the types of image data embedded in them, there may be M × N types of card NFTs. Pack NFTs and box NFTs may also have multiple types. Depending on the type, differences can be made between the card NFTs and pack NFTs obtained through exchange.

[0074] Box NFTs and Pack NFTs can function as request-transmitting tokens (request-transmitting non-fungible tokens) that can be exchanged by System 10 for target non-fungible tokens. In other words, the type of target non-fungible token generated by the Box NFT and Pack NFT will differ depending on the request-transmitting token received by System 10.

[0075] Figure 3 shows the flow of the NFT generation process executed by system 10. The NFT generation process shown in Figure 3 is executed by smart contract 101, but server 200 handles a part of that process (second process). The process executed by smart contract 101 (first computer; contract computer) is called the first process, and the process executed by server 200 (second computer) is called the second process. The division of roles between smart contract 101 and server 200 described here is just one example; the division of roles is not particularly limited, and it is not required to be divided at all.

[0076] In the NFT generation process shown in Figure 3, first, a non-fungible token request (NFT request) is sent from a computer such as a user terminal 300 to the system 10 (step S11). The NFT request is received, for example, by a smart contract 101 (step S21). The NFT request may be sent from the server 350 to the smart contract 101, or from the user terminal 300 to the smart contract 101 via the server 350. The user has a blockchain address in order to use the blockchain. The blockchain address may be represented, for example, as 0x00000. The blockchain address is also called a blockchain account. The user has a private key that corresponds to the blockchain account. The private key is stored, for example, on the user terminal 300 or another device. The private key is used to digitally sign transactions recorded on the blockchain.

[0077] Figure 4 shows the operation screen 310 for NFT requests on a user terminal 300 (user computer). The user terminal 300 has a user application program installed for purchasing, exchanging, and managing NFTs. The operation screen 310 shown in Figure 4 is displayed on the user terminal 300's screen by the user application program. The user application program can also display NFTs owned by the user or NFTs that the user intends to purchase or exchange on the user terminal 300's screen. The operation screen 310 shown in Figure 4 may also be displayed on the user terminal 300's screen by a server 350 (user computer) accessed by the user terminal 300.

[0078] As shown in Figure 4, the operation screen 310 includes buttons 311, 312, 313, 314, and 315. Button 311 accepts the operation to purchase a box containing 6 packs (box NFT). Button 312 accepts the operation to purchase a pack containing 6 cards (pack6NFT). Button 313 accepts the operation to purchase a pack containing 3 cards (pack3NFT). Button 314 accepts the operation to exchange a box NFT for a pack containing 6 cards (pack6NFT). The operation to exchange a box NFT for a pack containing 6 cards (pack6NFT) may also be called the box NFT opening operation (openbox operation). Button 315 is the operation to exchange a pack NFT (pack6NFT or pack3NFT) for 6 or 3 card NFTs.

[0079] Here, on the operation screen 310, the operation in which the user selects button 311 is referred to as a "Type 1 request operation," the operation in which the user selects button 312 is referred to as a "Type 2 request operation," the operation in which the user selects button 313 is referred to as a "Type 3 request operation," the operation in which the user selects button 314 is referred to as a "Type 4 request operation," and the operation in which the user selects button 315 is referred to as a "Type 5 request operation." In this way, the user can perform selection operations on buttons 311, 312, 313, 314, and 315 on the operation screen 310. The user terminal 300, which is the user's computer, or the server 350 can receive the user's selection operations.

[0080] In the first embodiment, the first type request is a request for a box NFT, the second type request is a request for a pack6NFT, the third type request is a request for a pack3NFT, the fourth type request is a request for a pack6NFT, and the fifth type request is a request for a card NFT. The request here is a request to the system 10 to send an NFT.

[0081] The first type of request is also a request to exchange the required number of fungible tokens for a box NFT. A fungible token is, for example, a cryptocurrency such as Ethereum or Bitcoin. Hereafter, fungible tokens will also be referred to as "FT".

[0082] A second-type request is also a request to exchange the required number of FTs for pack6NFTs. A third-type request is also a request to exchange the required number of FTs for pack3NFTs. The required number of FTs may vary depending on the type of NFT being exchanged. Thus, a request may ask system 10 to provide NFTs in exchange for FTs.

[0083] A fourth type request is also a request to exchange a box NFT for a pack6NFT. A fifth type request is also a request to exchange a pack6NFT or pack3NFT for a card NFT. Thus, a request may ask system 10 to provide another type of NFT in exchange for providing one type of NFT to system 10. In this case, the type of NFT provided by system 10 may be determined by the type of NFT provided to system 10.

[0084] As described above, in the embodiment, the user terminal 300 or server 350, which is a user computer, is configured to identify the number of fungible tokens or the type of non-fungible tokens to be sent as request transmission tokens in response to the user's selection via button selection operation, and to send the identified number or type of request transmission tokens to the smart contract 101.

[0085] In one embodiment, the smart contract 101 is configured to generate and send the target nonfungible token only when it receives a predetermined number of tokens or a predetermined type of token (request token). That is, the smart contract 101 is configured not to generate and send the target nonfungible token if it receives a number of tokens other than the predetermined number, and not to generate and send the target nonfungible token if it receives tokens of a type other than the predetermined type. Therefore, the user terminal 300 or server 350, which is a user computer, functions to send only the appropriate request token to the smart contract 101 according to the user's selection operation.

[0086] Figure 5 shows the operations and procedures for making an NFT request on the user terminal 300. Note that some or all of the procedures shown in Figure 5 may be executed by the server 350 accessed by the user terminal 300. If the user wishes to purchase a box NFT, they perform the operation of selecting button 311, i.e., the operation of a first type request (step S51). When the user terminal 300, which is the user's computer, or the server 350 receives the operation of a first type request, it sends the first type request to the smart contract 101 (see step S11 in Figure 3). When the operation of a first type request is performed, the transmission of the NFT request includes calling the first module 111 (see Figure 7) corresponding to the first type request in the smart contract 101, and sending the number of FTs required to acquire the box NFT to the smart contract 101 (step S56 in Figure 5). FT transmission is performed, for example, by sending FT from the user's address on the blockchain (user account on the blockchain) to the contract address of smart contract 101. The transmission of FT from the user account to smart 01 can be performed, for example, by server 350. The user terminal 300, which is the user's computer, or server 350, in accordance with the user's selection on the operation screen 310 (selection of button 311), identifies that the token to be sent (requested transmission token) is FT, and the required number of FT, and sends the identified number of FT to smart contract 101.

[0087] If a user wishes to purchase a pack6NFT, they perform the operation of selecting button 312, i.e., the operation of a second type request (step S52). When the user's computer, the user terminal 300, or the server 350, receives the operation of a second type request, it sends the second type request to the smart contract 101 (see step S11 in Figure 3). When a second type request is made, the transmission of the NFT request includes calling the second module 112 (see Figure 7) corresponding to the second type request in the smart contract 101, and sending the number of FTs required to obtain the pack6NFT to the smart contract 101 (step S56 in Figure 5). The user's computer, the user terminal 300, or the server 350, in response to the user selecting button 312, identifies that the token to be sent (request transmission token) is an FT, and the required number of FTs, and has the smart contract 101 send the identified number of FTs.

[0088] If a user wishes to purchase a pack3NFT, they perform the operation of selecting button 313, i.e., the operation of a third-type request (step S53). When the user's computer, the user terminal 300, or the server 350, receives the operation of a third-type request, it sends the third-type request to the smart contract 101 (see step S11 in Figure 3). When a third-type request is made, the transmission of the NFT request includes calling the third module 113 (see Figure 7) corresponding to the third-type request in the smart contract 101, and sending the number of FTs required to obtain the pack3NFT to the smart contract 101 (step S56 in Figure 5). The user's computer, the user terminal 300, or the server 350, in response to the user selecting button 313, identifies that the token to be sent (request transmission token) is an FT, and the required number of FTs, and has the smart contract 101 send the identified number of FTs.

[0089] If a user wishes to exchange a box NFT for a pack6NFT, they perform the operation of selecting button 314, i.e., the operation of a fourth type request (step S54). When the user's computer, the user terminal 300 or server 350, receives the operation of a fourth type request, it sends the fourth type request to the smart contract 101 (see step S11 in Figure 3). When a fourth type request is performed, the transmission of the NFT request includes calling the fourth module 114 (see Figure 7) corresponding to the fourth type request in the smart contract 101, and also sending the box NFT to the smart contract 101 (step S57 in Figure 5). The user's computer, the user terminal 300 or server 350, in response to the user selecting button 314, identifies that the type of token to be sent (request token) is a box NFT and has the identified box NFT sent to the smart contract 101.

[0090] If a user wishes to exchange a pack6NFT or pack3NFT for a card NFT, they perform the operation of selecting button 315, i.e., the operation of a fifth type request (step S55). When the user terminal 300, which is the user's computer, or the server 350 receives the operation of a fifth type request, it sends the fifth type request to the smart contract 101 (see step S11 in Figure 3). When a fifth type request is made, the transmission of the NFT request involves calling the fifth module 115 (see Figure 7) corresponding to the fifth type request in the smart contract 101, and sending either a pack6NFT or a pack3NFT to the smart contract 101 (step S58 in Figure 5). Which of the pack6NFT and pack3NFT is sent can be selected by the user's selection operation. Note that the operation of a fifth type request may also be an operation to select a pack6NFT or pack3NFT owned by the user. The user terminal 300 or server 350, which is a user computer, identifies the type of token to be sent (requested token) as pack6NFT and pack3NFT in response to the user's selection, and sends the identified pack6NFT and pack3NFT to the smart contract 101.

[0091] Returning to Figure 3, when system 10 receives an NFT request sent from user terminal 300 (step S21), it generates a target non-fungible token (target NFT) in response to the NFT request (step S22). System 10 has a generation private key (secret key) used to generate the target NFT, and uses this generation private key to generate the target NFT. For example, system 10 uses the generation private key to digitally sign the transaction for generating the target NFT. The digitally signed transaction is recorded on the blockchain. Because system 10 has the generation private key, it can generate the NFT that the user will acquire without using the user's private key. Then, system 10 sends the generated target NFT to user terminal 300 (user account) (step S23). The sent target NFT is received by user terminal 300 (step S12). Furthermore, the transmission of the target NFT only needs to be an operation that changes the owner of the target NFT on the blockchain to the user and brings the target NFT into the user's account. In other words, it is sufficient for system 10 to be configured to record on the blockchain that the owner of the generated target NFT is the aforementioned user.

[0092] In other words, the target NFT does not need to be physically transmitted to a specific device, such as the user terminal 300; it is sufficient for it to be transmitted to a user account (the user's blockchain address) that the user can access via the terminal 300. The user account is, for example, an account on the blockchain, and such an account can be identified by a unique address on the blockchain. The owner of the target NFT transmitted to the user account becomes that user, and that user can view the target NFT by displaying it on the user terminal 300. The system 10 may recognize the source of the NFT request by the user account described above, and the destination of the target NFT may also be recognized by the user account described above. The system 10 may recognize the source of the NFT request as the destination of the target NFT. In other words, the system 10 may transmit the target NFT to the source of the NFT request. The system 10 may acquire data indicating the destination of the target NFT at the same time as receiving the NFT request, or after receiving the NFT request.

[0093] Figure 6 shows the process of generating the aforementioned target NFT (step S22). System 10 uses the information (identification information) contained in the received NFT request to identify the type of target NFT to be generated (step S61). Here, the "identification information" used to identify the type of target NFT is the NFT request itself. In other words, the type of target NFT to be generated is identified depending on whether the NFT request is a first-type request, a second-type request, a third-type request, a fourth-type request, or a fifth-type request. The "identification information" may also be the number or type of request transmission tokens, and the type of target NFT to be generated can be identified by the number or type of request transmission tokens. The "identification information" may also be other data contained in the NFT request.

[0094] Furthermore, system 10 determines the generation conditions for the target NFT according to the identified type (step S61). The generation conditions are used when generating the target NFT. The generation conditions indicate, for example, what kind of target NFT should be generated. The generation conditions may also indicate the number of target NFTs to be generated (number of issues). The aforementioned "identification information" may indicate the number of target NFTs to be generated. The generation conditions will be described later.

[0095] System 10 issues initial NFTs according to the generation conditions (step S62). For example, System 10 issues a number of initial NFTs corresponding to the number of NFTs to be issued as indicated by the generation conditions. The issuance of initial NFTs is achieved by executing an NFT issuance command provided in the blockchain used by System 10. When an NFT issuance command is executed in the blockchain, the computers constituting the blockchain, upon receiving the NFT issuance command, execute the process of issuing NFTs in the blockchain. The issued NFTs are recorded in the ledger of the blockchain, and the record is made public. NFTs issued in the blockchain are assigned a unique identifier (NFT address or NFT-ID). After executing the NFT issuance command for initial NFT issuance, System 10 waits until the initial NFTs are issued in the blockchain. The waiting time varies depending on the blockchain, but a shorter waiting time is preferable. After the waiting time, System 10 can obtain the identifiers of the issued initial NFTs.

[0096] Next, system 10 executes the NFT configuration data embedding process 212 (see Figures 2 and 6). The NFT configuration data embedding process 212 obtains the generation conditions for the target NFT and the identifier of the initial NFT, and associates the NFT configuration data corresponding to the generation conditions (for example, the type of target NFT) with the identifier of the initial NFT. Multiple NFT material data 240, which are candidates for NFT configuration data, are stored in the database 230. In the NFT configuration data embedding process 212, system 10 determines the material data corresponding to the type of target NFT from among the multiple NFT material data 240 according to the generation conditions, and generates configuration data using that material data. Alternatively, the determined material data may be used as is as configuration data. The configuration data may be, for example, image data and character data. System 10 performs a process to associate the generated configuration data with the identifier of the initial NFT. As a result, the initial NFT and the configuration data are integrated, and the target NFT is generated. This completes the generation of the target NFT (step S63). The embedded process 212 may be executed by the smart contract 101 (the contract computer that executes the smart contract 101; the first computer) or by the server 200 (the second computer).

[0097] For the purposes of this explanation, steps S21, S22, and S23 are referred to as the first process, and process 212 is referred to as the second process. For the purposes of this explanation, the first process is executed by the smart contract 101 (first computer) in Figure 1, and the second process is executed by the server 200 (second computer). Also, for the purposes of this explanation, steps S61, S62, and S63 of the process for generating the target NFT (step S22) are the first process, and embedded process 212 is the second process.

[0098] The NFT configuration data embedding process 212 is executed when the server 200 detects the issuance of an initial NFT by the smart contract 101. Detection of NFT issuance is performed, for example, by the server 200 monitoring the occurrence of an NFT issuance event in the smart contract 101. In other words, process 212 is an event-driven process. An NFT issuance event is an action that occurs in the smart contract 101, for example, when the smart contract 101 executes an NFT issuance command.

[0099] When server 200 detects the occurrence of an NFT issuance command, it obtains the generation conditions for the target NFT and the identifier of the initial NFT. The generation conditions and the identifier of the initial NFT may be obtained from smart contract 101. According to the obtained generation conditions, server 200 determines from among multiple NFT material data 240 the data appropriate for the type of target NFT and generates configuration data. Server 200 performs a process to associate the generated configuration data with the identifier of the initial NFT held by smart contract 101, and completes the target NFT. In other words, system 10 generates the target NFT using data selected from among multiple material data 240 based on identification information. Selecting data based on identification information may include selecting data based on the type of target NFT identified based on the identification information. The generated target NFT has the configuration data embedded in it. An NFT with the configuration data embedded has, for example, a uniform resource identifier (URI) that indicates the configuration data. Here, the URI indicating the configuration data may be provided in the NFT's metadata. Furthermore, the URI indicating metadata may be included in the NFT's index data. Note that the initial NFT issuance (step S62) and the embedding process 212 do not need to be performed separately; the NFT with the configuration data embedded may be generated in step S62. When the server 200 completes process 212, it sends an embedding completion notification to the smart contract 101. Upon receiving the embedding completion notification, the smart contract 101 recognizes that the generation of the target NFT is complete (step S63) and sends the target NFT (step S23 in Figure 3). The sending of the target NFT involves recording the owner on the blockchain so that the new owner of the target NFT becomes the recipient (user account). In other words, the sending of the target NFT constitutes a transfer or sale of the target NFT.

[0100] In one embodiment, as an example, smart contract 101 comprises a first smart contract 110 and a second smart contract 120, as shown in Figures 1 and 7. That is, in this embodiment, the software constituting the first smart contract 110 and the software constituting the second smart contract are implemented on the blockchain so as to be executed on a computer network system for blockchain. The first smart contract 110 and the second smart contract 120 are able to communicate with each other.

[0101] The first smart contract 110 shown in Figure 7 includes, as an example, a first module 111, a second module 112, a third module 113, a fourth module 114, a fungible token count determination module 116 (FT count determination module), and an NFT type determination module 117. The second smart contract 120 shown in Figure 7 includes, as an example, a fifth module 115. Here, "module" can refer to a software module. A "module" is, for example, a function, procedure, or subroutine defined in a computer program. Each module can be executed by any computer in the computer network that constitutes the blockchain.

[0102] Module 111 is a boxNFT purchase module that defines the process for purchasing a box NFT. Module 212 is a pack6NFT purchase module that defines the process for purchasing a pack6NFT. Module 313 is a pack6NFT purchase module that defines the process for purchasing a pack3NFT. Module 414 is a box exchange module that defines the process for exchanging a box NFT for a pack containing six cards (pack6NFT). Module 515 is a back exchange module that defines the process for exchanging a pack NFT (pack6NFT or pack3NFT) for six or three card NFTs.

[0103] The FT count determination module 116 is a module that is called when smart contract 101 (first smart contract 110) determines whether the number of FTs received matches the number of FTs required to purchase the target NFT. The NFT type determination module 117 is a module that is called when smart contract 101 (first smart contract 110 or second smart contract 120) determines the type (kind) of the NFT received. The NFT type determination module 117 may also function as a token determination module that determines the type of token, such as whether the received token is an FT or an NFT.

[0104] In this embodiment, if the NFT request is of type 1, the first module 111 is called; if it is of type 2, the second module 112 is called; if it is of type 3, the third module 113 is called; if it is of type 4, the fourth module 114 is called; and if it is of type 5, the fifth module 115 is called. In other words, the module to be called is determined by the type of NFT request. Alternatively, the module to be called may be determined by the number or type of request tokens sent to the smart contract 101. In this way, the system 10 identifies the type of NFT request and selects the modules 111, 112, 113, 114, and 115 to be executed. The system 10 executes the first module 111 if the NFT request is of type 1, the second module 112 if it is of type 2, the third module 113 if it is of type 3, the fourth module 114 if it is of type 4, and the fifth module 115 if it is of type 5.

[0105] Figure 8 shows the processing procedure in the first module 111 (box NFT purchase module). First, the first smart contract 110 receives a first type request from the user terminal 300, which is the user's computer, or from the server 350. Along with the first type request, the required number of FTs are also received. Receiving the required number of FTs for the box NFT may be considered as receiving the first type request. The transmission of FTs to the first module 111 and the other modules 112 and 113 involves an operation to change the owner of the FTs from the sender (user account) to the smart contract 101 or the account of the administrator of the smart contract 101. In other words, the FTs are considered to have been paid by the user. The change of ownership is recorded on the blockchain.

[0106] Since the first type request is a call to the first module 111, the first module 111 is started. In the processing in the first module 111, it is first determined whether the quantity of FTs received with the first type request matches the required number of box NFTs to be purchased (step S81). This determination is performed by the FT quantity determination module 116. The required number of box NFTs to be purchased has been notified to the user terminal in advance.

[0107] If the quantity of FTs does not match the required number for purchasing the box NFT, error processing is performed, such as notifying the user terminal 300 of this (step S82). In this case, processing in the first module 111 is terminated. The smart contract 101, having received the required number of FTs to acquire the box NFT, may identify the first module 111 as the module that should start operating and start the identified first module 111. In other words, the number of FTs represents identification information, and the number of FTs as identification information determines the generation condition. In this case, steps S81 and S82 are optional, and execution starts from step S83. Furthermore, as in the embodiment, if the smart contract 101 can receive both FTs and NFTs, the smart contract 101 may have a function to determine whether the received token (request sending token) is an FT or an NFT.

[0108] If the quantity of FTs matches the required number of box NFTs to be purchased, the generation conditions for the target NFT are then determined (step S83). Here, the generation conditions are determined to be the number of target NFTs to be issued P=1 and the type of target NFT T=first type (box). These generation conditions indicate that one box NFT of type 1 should be issued as the target NFT. The generation conditions may be determined depending on the number of FTs received.

[0109] Next, according to the generation conditions, the initial NFT issuance process for P (1) initial NFTs is executed, and the identifiers of the initial NFTs are obtained (step S84). The initial NFT issuance process may be performed such that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T = first type (box).

[0110] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates a box NFT which is the target NFT (step S85). The server 200 may also obtain generation conditions such as "initial NFT type T" by referring to the initial NFT record in the blockchain.

[0111] In the NFT configuration data embedding process, according to the type of target NFT T = first type (box), configuration data for the box NFT (e.g., image data for the box NFT, character data indicating the name of the box NFT, etc.) is selected from among multiple NFT material data 240. The multiple material data 240 contained in the database 230 include material data for the box NFT which is first type (box). The system 10 may select material data to be the configuration data based on the type T identified based on the received identification information. Other data besides the material data 240 (e.g., the serial number of the box NFT) may be added to the configuration data. Then, the configuration data for the box NFT is embedded in the initial NFT, and the box NFT is completed. Note that the configuration data may also be embedded when the initial NFT is issued. When the box NFT is completed, the server 200 sends a completion notification to the smart contract 101. Upon receiving the embedding completion notification, smart contract 101 recognizes the completion of box NFT generation (step S86) and sends the box NFT to the user account that is the source of the FT (step S87).

[0112] As described above, the user can obtain a box NFT in exchange for payment of FT. Since the system 10 according to this embodiment generates the box NFT after the FT has been paid, it does not need to hold the box NFT to be given to the user before the FT has been paid. The fact that the NFT to be generated by the system 10 is a box NFT can be identified by the number of FTs sent to the smart contract 101.

[0113] Figure 9 shows the processing procedure in the second module 112 (pack6NFT purchase module). First, the first smart contract 110 receives a second-type request from the user terminal 300, which is a user computer, or from the server 350. Along with the second-type request, the required number of FTs are also received. The receipt of the required number of FTs for pack6NFTs may be considered as the receipt of the second-type request.

[0114] Since the second type request is a call to the second module 112, the second module 112 is started. In the processing in the second module 112, it is first determined whether the quantity of FTs received with the second type request matches the required number of pack6NFTs to be purchased (step S91). This determination is performed by the FT quantity determination module 116. The required number of pack6NFTs to be purchased has been notified to the user terminal in advance.

[0115] If the number of FTs does not match the required number for purchasing pack6NFTs, error processing is performed, such as notifying the user terminal 300 of this (step S92). In this case, processing in the second module 112 is terminated. The smart contract 101, having received the required number of FTs to acquire pack6NFTs, may identify the second module 112 as the module that should start operating and start the identified second module 112. In other words, the number of FTs represents identification information, and the number of FTs as identification information determines the generation condition. In this case, steps S91 and S92 are optional, and execution starts from step S93.

[0116] If the quantity of FTs matches the required number for purchasing pack6NFTs, the generation conditions for the target NFT are then determined (step S93). Here, the generation conditions are determined to be the number of target NFTs issued P=1 and the type of target NFT T=second type (pack6). These generation conditions indicate that one pack6NFT of type 2 should be issued as the target NFT. The generation conditions may be determined depending on the number of FTs received.

[0117] Next, according to the generation conditions, the initial NFT issuance process for P (1) initial NFTs is executed, and the identifiers of the initial NFTs are obtained (step S94). The initial NFT issuance process may be performed such that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T = second type (pack6).

[0118] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates the target NFT, which is a pack6NFT (step S95). The server 200 may also obtain the generation conditions, such as "Target NFT type T," by referring to the initial NFT record in the blockchain. In the NFT configuration data embedding process, according to the target NFT type T = second type (pack6), configuration data for the pack6NFT (e.g., image data for the pack6NFT, character data indicating the name of the pack6NFT, etc.) is selected from among the multiple NFT material data 240. The multiple material data 240 contained in the database 230 include material data for the pack6NFT, which is of second type (pack6). The system 10 may select material data to become configuration data based on the type T identified based on the received identification information. Other data besides the material data 240 (e.g., the serial number of the pack6NFT) may be added to the configuration data. Then, the configuration data for pack6NFT is incorporated into the initial NFT, and the pack6NFT is completed. Note that the configuration data may also be incorporated when the initial NFT is issued. When the pack6NFT is completed, the server 200 sends a completion notification to the smart contract 101. When the smart contract 101 receives the incorporation completion notification, it recognizes that the generation of the pack6NFT is complete (step S96) and sends the pack6NFT to the user account that is the source of the FT (step S97).

[0119] As described above, the user can obtain a pack6NFT in exchange for payment of FTs. Since the system 10 according to this embodiment generates the pack6NFT after the FTs have been paid, it does not need to hold any pack6NFTs to be given to the user before the FTs are paid. The fact that the NFT to be generated by the system 10 is a pack6NFT can be identified by the number of FTs sent to the smart contract 101.

[0120] Figure 10 shows the processing procedure in the third module 113 (pack3NFT purchase module). First, the first smart contract 110 receives a third-type request from the user terminal 300, which is a user computer, or from the server 350. Along with the third-type request, the required number of FTs are also received. The receipt of the required number of FTs for pack3NFT may be considered as the receipt of the third-type request.

[0121] Since the third type request is a call to the third module 113, the third module 113 is started. In the processing in the third module 113, it is first determined whether the quantity of FTs received with the third type request matches the required number of pack3NFTs to be purchased (step S101). This determination is performed by the FT quantity determination module 116. The required number of pack3NFTs to be purchased has been notified to the user terminal in advance.

[0122] If the number of FTs does not match the required number for purchasing pack3NFTs, error processing is performed, such as notifying the user terminal 300 of this (step S102). In this case, processing in the third module 113 is terminated. The smart contract 101, having received the required number of FTs to acquire pack3NFTs, may identify the third module 113 as the module that should start operating and start the identified third module 113. In other words, the number of FTs represents identification information, and the number of FTs as identification information determines the generation condition. In this case, steps S101 and S102 are optional, and execution starts from step S103.

[0123] If the quantity of FTs matches the required number for purchasing pack3NFTs, the generation conditions for the target NFT are then determined (step S103). Here, the generation conditions are determined to be the number of target NFTs issued P=1 and the type of target NFT T=third type (pack3). These generation conditions indicate that one pack3NFT of type 3 should be issued as the target NFT. The generation conditions may be determined depending on the number of FTs received.

[0124] Next, according to the generation conditions, the initial NFT issuance process for P (1) initial NFTs is executed, and the identifiers of the initial NFTs are obtained (step S104). The initial NFT issuance process may be performed such that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T = third type (pack3).

[0125] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates the target NFT, which is pack3NFT (step S105). The server 200 may also obtain the generation conditions, such as "Target NFT type T," by referring to the initial NFT record in the blockchain. In the NFT configuration data embedding process, according to the target NFT type T = third type (pack3), configuration data for pack3NFT (e.g., image data for pack3NFT, character data indicating the name of pack3NFT, etc.) is selected from among multiple NFT material data 240. The multiple material data 240 contained in the database 230 include material data for pack3NFT, which is third type (pack3). The system 10 may select material data to become configuration data based on the type T identified based on the received identification information. Other data besides the material data 240 (e.g., the serial number of pack3NFT) may be added to the configuration data. Then, the configuration data for pack3NFT is incorporated into the initial NFT, and the pack3NFT is completed. Note that the configuration data may also be incorporated when the initial NFT is issued. When the pack3NFT is completed, the server 200 sends a completion notification to the smart contract 101. When the smart contract 101 receives the incorporation completion notification, it recognizes that the generation of the pack3NFT is complete (step S106) and sends the pack3NFT to the user account that is the source of the FT (step S107).

[0126] As described above, the user can obtain a pack3NFT in exchange for payment of FTs. Since the system 10 according to this embodiment generates the pack3NFT after the FTs have been paid, it does not need to hold any pack3NFTs to be given to the user before the FTs are paid. The fact that the NFT to be generated by the system 10 is a pack3NFT can be identified by the number of FTs sent to the smart contract 101.

[0127] Figure 11 shows the processing procedure in the fourth module 114 (box exchange module). First, the first smart contract 110 receives a fourth type request from the user terminal 300, which is the user's computer, or from the server 350. Along with the fourth type request, an NFT (box NFT) is also received. The transmission of the box NFT by the fourth module 114 involves changing the owner of the box NFT from the sender (user account) to the smart contract 101 or the account of the administrator of the smart contract 101. In other words, the box NFT is transferred from the user to the smart contract. The change in ownership of the NFT is recorded on the blockchain. The act of transferring the box NFT may be considered as the receipt of a fourth type request.

[0128] Since the fourth type request is a call to the fourth module 114, the fourth module 114 is started. In the processing of the fourth module 114, it is first determined whether the type of NFT received with the fourth type request is a box NFT (step S111). This determination is performed by the NFT type determination module 117. The determination of the NFT type is based, for example, on information indicating the type T contained in the NFT to be determined, or on the type T indicated by the record of the NFT to be determined in the blockchain.

[0129] If the type of NFT received is not a box NFT, error processing is performed, such as notifying the user terminal 300 of this (step S112). In this case, processing in the fourth module 114 is terminated. The smart contract 101, having received a box NFT, may identify the fourth module 114 as the module that should start operating and start the identified fourth module 114. In other words, the type of NFT received (box NFT) represents identification information, and the type of NFT as identification information determines the generation conditions. In this case, steps S111 and S112 are optional, and execution starts from step S113.

[0130] If the type of NFT received is a box NFT, the generation conditions for the target NFT are then determined (step S113). Here, the generation conditions are determined to be the number of target NFTs to be issued P=6 and the type of target NFT T=second type (pack6). These generation conditions indicate that six pack6NFTs of type 2 should be issued as the target NFTs. In other words, the box NFT is exchanged for six pack6NFTs. The generation conditions may be determined depending on whether the type of NFT received is a box NFT.

[0131] Next, according to the generation conditions, the initial NFT issuance process for P (6) initial NFTs is executed, and identifiers for the initial NFTs are obtained (step S114). The initial NFT issuance process may also be performed so that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T = second type (pack6).

[0132] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates the target NFT, which is pack6NFT (step S115). The server 200 may also obtain the generation conditions, such as "Target NFT type T," by referring to the initial NFT record in the blockchain. In the NFT configuration data embedding process, according to the target NFT type T = second type (pack6), configuration data for pack6NFT (e.g., image data for pack6NFT, character data indicating the name of pack6NFT, etc.) is selected from among multiple NFT material data 240. The multiple material data 240 contained in the database 230 include material data for pack6NFT, which is second type (pack6). The system 10 may select material data to become configuration data based on the type T identified based on the received identification information. Other data besides the material data 240 (e.g., the serial number of pack6NFT) may be added to the configuration data. Configuration data is generated for six NFTs. Then, configuration data for pack6NFT is embedded into each of the six initial NFTs, completing the six pack6NFTs. Note that the configuration data may also be embedded when the initial NFTs are issued. Once the six pack6NFTs are completed, the server 200 sends a completion notification to the smart contract 101. Upon receiving the embedding completion notification, the smart contract 101 recognizes the completion of the generation of the six pack6NFTs (step S116) and sends the pack6NFTs to the user account that sent the box NFT (step S117).

[0133] As described above, the user can obtain six pack6NFTs instead of handing over the box NFT. In other words, the user has the same experience as opening a box containing six packs. Since the system 10 according to this embodiment generates the pack6NFTs after the box NFT is handed over, it does not need to hold the pack6NFTs to be given to the user before the box NFT is handed over. The fact that the NFT that system 10 should generate is a pack6NFT can be identified by the fact that the type of NFT sent to the smart contract 101 is a box NFT.

[0134] Figure 12 shows the processing procedure in the fifth module 115 (pack exchange module). First, the first smart contract 110 receives a fifth-type request from the user terminal 300, which is the user's computer, or from the server 350. Along with the fifth-type request, an NFT (pack6NFT or pack3NFT) is also received. The transmission of the pack NFT by the fifth module 115 involves changing the owner of the pack NFT from the sender (user account) to the smart contract 101 or the account of the administrator of the smart contract 101. In other words, the pack NFT is transferred from the user to the smart contract. The change of NFT ownership is recorded on the blockchain. Performing a pack6NFT or pack3NFT may be considered as receiving a fifth-type request.

[0135] Furthermore, when sending a Type 5 request, information (combination information) indicating the combination of categories C1, C2, C3, ... for each of the multiple cardNFTs exchanged with the sent pack6NFT or pack3NFT is also transmitted.

[0136] In this embodiment, the server 200 includes an NFT generation rule 250 for determining the types of multiple cardNFTs to be exchanged for a pack6NFT or pack3NFT. One example of an NFT generation rule 250 is a combination of categories C1, C2, C3, ... for each of the multiple cardNFTs to be exchanged for a pack6NFT or pack3NFT. Many combination patterns of categories C1, C2, C3 are set in the NFT generation rule 250. For example, one example of a combination pattern for a pack6NFT is two card NFTs of category C1, two card NFTs of category C3, one card NFT of category C4, and one card NFT of category C6. One example of a combination pattern for a pack3NFT is one card NFT of category C2, one card NFT of category C4, and one card NFT of category C5. Card NFTs of categories that occur infrequently in the NFT generation rule 250 may be treated as rare cards.

[0137] In one embodiment, for example, when a user terminal 300 (or its application program) or server 350 sends a fifth-type request, it accesses server 200 and obtains information (combination information) indicating the combination of categories C1, C2, C3, ... for each of the multiple cardNFTs to be exchanged with pack6NFT or pack3NFT. The obtained combination information is sent to the smart contract 101 along with the fifth-type request as information used to identify the type of target NFT.

[0138] Since the fifth type request is a call to the fifth module 115 in the second smart contract 120, when the smart contract 101 receives the fifth type request, the fifth module 115 starts operating. In the processing of the fifth module 115, it is first determined whether the type of NFT received with the fifth type request is pack6NFT or pack3NFT (step S121). This determination is performed by the NFT type determination module 117.

[0139] If the type of NFT received is not pack6NFT or pack3NFT, error processing is performed, such as notifying the user terminal 300 of this (step S122). In this case, processing in the fifth module 115 is terminated. The smart contract 101, having received pack6NFT or pack3NFT, may identify the fifth module 115 as the module that should start operating and start the identified fifth module 115. In other words, the type of NFT received (pack6NFT or pack3NFT) represents identification information, and the type of NFT as identification information determines the generation conditions. In this case, steps S121 and S122 are optional, and execution starts from step S213.

[0140] If the type of NFT received is pack6NFT or pack3NFT, the conditions for generating the target NFT are determined according to the type and combination information of the received NFT (step S123). Here, if the received NFT is pack6NFT, the NFT generation conditions are determined as follows: the number of target NFTs to be issued P=6, the type of target NFT T=Type 4 (card), and the category and number of target card NFTs to be generated. The category and number of card NFTs to be generated are determined according to the combination information received. These generation conditions indicate that 6 cardNFTs of Type 4 should be issued as the target NFTs. In other words, pack6NFT is exchanged for 6 cardNFTs. These generation conditions also indicate the category and the number of each category of the 6 cardNFTs to be generated. For example, as mentioned above, there are 2 card NFTs of Category C1, 2 card NFTs of Category C3, 1 card NFT of Category C4, and 1 card NFT of Category C6.

[0141] If the received NFT is pack3NFT, the NFT generation conditions are determined as follows: the number of target NFTs to be issued P=3, the type of target NFT T=Type 4 (card), and the categories and number of card NFTs to be generated. These generation conditions indicate that three cardNFTs of Type 4 should be issued as the target NFTs. In other words, pack3NFT will be exchanged for three cardNFTs. These generation conditions also indicate the categories and the number of each category of the six cardNFTs to be generated. For example, as mentioned above, there will be one card NFT of Category C2, one card NFT of Category C4, and one card NFT of Category C5.

[0142] The category and number of target card NFTs to be generated may be obtained by smart contract 120 from server 200.

[0143] Next, according to the generation conditions, the initial NFT issuance process for P (6 or 3) initial NFTs is executed, and identifiers for the P initial NFTs are obtained (step S124). The initial NFT issuance process may be performed such that each initial NFT issued contains data indicating the type of target NFT T = fourth type (card) and generation conditions such as category.

[0144] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions and identifier of the target NFT, executes the NFT configuration data embedding process, and generates the target NFT, which is a cardNFT (step S125). The server 200 may also obtain the generation conditions such as the "target NFT type T" and "category" of each initial NFT by referring to the record of each initial NFT in the blockchain. In the NFT configuration data embedding process, according to the target NFT type T = fourth type (card) and "category", configuration data for the cardNFT is selected from among multiple NFT material data 240. The multiple material data 240 contained in the database 230 include material data for cardNFTs which are of fourth type (card). The system 10 may select material data to be the configuration data based on the type T identified based on the received identification information. The configuration data for cardNFT includes, for example, image data indicating the cardNFT categories C1, C2, C3, etc., text data indicating the cardNFT category name, and image data D1, D2, D3, etc., corresponding to the cardNFT subject matter. The category name indicates a rank, such as platinum, gold, or silver.

[0145] Image data indicating cardNFT categories C1, C2, C3, etc., and text data indicating the category name of the cardNFT are selected from multiple NFT material data 240 according to the "category" indicated by the generation conditions. Image data D1, D2, D3, etc., corresponding to the subject of the cardNFT are randomly determined by the server 200 from among the material data that are candidates for image data corresponding to the subject of the cardNFT. For example, if the subject of the cardNFT is a player of a certain sports team, image data of multiple players belonging to that sports team are registered as candidates for image data D1, D2, D3 corresponding to the subject of the cardNFT. The server 200 randomly determines the image data corresponding to the subject of the cardNFT from among these candidates. Note that the subject of the cardNFT may be determined according to the type of pack6 or pack3. For example, there may be a pack6NFT for Team A that is exchanged for a cardNFT of a player from Team A, and a pack6NFT for Team B that is exchanged for a cardNFT of a player from Team B. In this case, if system 10 receives pack6NFT for team A, it may generate a card NFT for a player belonging to team A using image data selected from multiple image data of team A's players. Similarly, if system 10 receives pack6NFT for team B, it may generate a card NFT for a player belonging to team B using image data selected from multiple image data of team B's players.

[0146] In this embodiment, in addition to image data corresponding to the subject matter, image data corresponding to the category is also attached to the card NFT, resulting in a greater variety of card NFTs and increasing the enjoyment of collecting them. For example, even if card NFTs have image data of the same player, one with an image from category C1 and one with an image from category C2 may be recognized as different types of cards. For example, even if multiple card NFTs have the same image data of a certain player, one with the text indicating "Platinum" and an image related to "Platinum" (category C1) and one with the text indicating "Gold" and an image related to "Gold" (category C2) may be recognized as different types of cards. Even if card NFTs have image data of the same player, their value may differ because they belong to different categories.

[0147] In this way, configuration data for P (6 or 3) NFTs is generated. Then, the configuration data for the cardNFT is incorporated into each of the P initial NFTs, completing the P (6 or 3) cardNFTs. Note that the configuration data may be incorporated when the initial NFTs are issued. When the P cardNFTs are completed, the server 200 sends a completion notification to the smart contract 101. Upon receiving the incorporation completion notification, the smart contract 101 recognizes the completion of the generation of the P cardNFTs (step S126) and sends the cardNFTs to the user account that sent the pack NFT (step S127). Note that the configuration data may include identification information to distinguish each cardNFT from other cardNFTs, such as the serial number of the cardNFT. Having identification information to make cardNFTs unique can increase the scarcity value of a cardNFT, even if it has common material data that can be used by other cardNFTs.

[0148] As described above, the user can obtain P cardNFTs in exchange for handing over the box NFT. In other words, the user can have the same experience as opening a pack containing 6 or 3 cards. Since the system 10 according to the embodiment generates cardNFTs after the pack NFT is handed over, it does not need to hold cardNFTs to be given to the user before the pack NFT is handed over. In particular, in the system 10 according to the embodiment, there may be many types of cardNFTs, M x N (number of categories M x image data N corresponding to the subject matter), but it is not necessary to generate such a large number of cardNFTs in advance and have the system 10 hold them.

[0149] Furthermore, in the system 10 according to this embodiment, the type of cardNFT that will be exchanged for a pack6NFT or pack3NFT is not predetermined. Therefore, it is unnecessary to pre-assign the cardNFT to be exchanged for each of the many pack6NFTs or pack3NFTs that will be sold. The fact that the NFT that system 10 should generate is a cardNFT can be identified by the type of NFT sent to the smart contract 101, which is either a pack6NFT or a pack3NFT. In addition, the smart contract 101 of this embodiment can identify what type of purpose nonfungible token should be generated based on the number or type of request tokens received, and generate an appropriate purpose nonfungible token.

[0150] As described above, the smart contract 101 according to this embodiment is configured to generate and send what kind of purpose NFT depending on what kind of request transmission token it receives. In this embodiment, the trigger for starting (activating) the smart contract 101 is when the user sends something to the smart contract 101. More specifically, the trigger for starting (activating) the smart contract 101 is when the user sends some kind of token (request transmission token) to the smart contract 101.

[0151] <2.2 Second Embodiment: Ticket NFT Generation System>

[0152] Figure 13 shows an example of the system 20 according to the second embodiment. In the second embodiment, aspects not specifically described are the same as those of the system 10 according to the first embodiment.

[0153] The system 20 according to the second embodiment comprises a smart contract 102 implemented in a computer network system such as a blockchain, and a server 200. The system 20 according to the second embodiment generates digital ticket NFTs in order to provide a service for selling or issuing digital ticket NFTs. The system 20 can communicate via the network with terminals 300 (user terminals) owned by users who wish to purchase or issue digital ticket NFTs.

[0154] The smart contract 102 according to the second embodiment is configured to execute a ticket NFT generation process. The server 200 according to the second embodiment is configured to execute an NFT configuration data embedding process 212. The server 200 according to the second embodiment may also execute a reservation acceptance process 215 from a user for issuing a ticket NFT.

[0155] The digital ticket NFT provided by the system 20 according to the second embodiment is a ticket that has been converted into an NFT. The digital ticket NFT is displayed on a computer screen. Hereinafter, the digital ticket NFT will be referred to as the ticket NFT. The ticket NFT can also be traded with any third party.

[0156] Tickets are, for example, tickets to attend events such as concerts, live performances, plays, movies, and seminars; tickets to enter facilities such as art museums and museums; and tickets to use transportation such as trains, airplanes, and buses. They are also exchange tickets or vouchers for receiving goods or services. Tickets may include discount coupons for purchasing goods or services.

[0157] The ticket NFT according to this embodiment is constructed by incorporating constituent data, such as image data or text data indicating that it is a ticket, into an NFT issued on the blockchain. The NFT with the incorporated constituent data has, for example, the constituent data itself or a URI that directly or indirectly indicates the constituent data. The URI may directly or indirectly indicate the constituent data. For example, if it is a ticket NFT for an event, it will have image data or text data for the event incorporated into it. The constituent data incorporated into the ticket NFT may differ depending on the purpose of the ticket NFT (e.g., a specific event). Therefore, there may be multiple types of ticket NFTs.

[0158] The system 20 according to the second embodiment can generate and provide to the user a ticket NFT of a type corresponding to the type and purpose of the event. As shown in Figure 13, the system 20 according to the second embodiment receives a ticket NFT request (NFT request) from a user terminal 300, which is a user computer, and sends the ticket NFT as the target NFT to the user's account. The ticket NFT request here is made as a call to the ticket issuance smart contract 102. When the ticket issuance smart contract 102 is called, it executes the ticket NFT generation process.

[0159] Figure 14 shows the procedure for generating a ticket NFT in the ticket issuance smart contract 102. First, smart contract 102 receives an NFT request from a user terminal 300 or the like, which is a user computer. The NFT request may also be received from a server, which is a user computer. The NFT request here is a request for the issuance of a ticket NFT. For the NFT request, FT is received as payment for purchasing the ticket NFT. Sending FT involves changing the owner of the FT from the sender (user account) to smart contract 101 or the account of the administrator of smart contract 101. In other words, the FT as payment for purchasing the ticket NFT is paid by the user. The change of ownership is recorded on the blockchain. Receiving a ticket NFT request may also be done by receiving an NFT to be exchanged for the ticket NFT (ticket exchange NFT). The ticket exchange NFT may contain the ticket information described later. Smart contract 102 can generate a ticket NFT using the ticket information contained in the ticket exchange NFT.

[0160] Furthermore, smart contract 102 also receives ticket information along with the NFT request. Ticket information includes, for example, the ticket number, event name, reserved seat information, event date, and event name. Ticket information is generated, for example, by the reservation acceptance process 215 of server 200, and the ticket information generated upon successful reservation acceptance is sent to the ticket reservation application program on the user terminal. The ticket reservation application program can have a user computer, such as user terminal 300 (computer), execute the process of sending the NFT request along with the received ticket information to smart contract 102. Ticket information can be used as identification information to identify the type of ticket NFT that is the target NFT. The type of ticket NFT to be generated may be represented by the number or type of FTs or NFTs (ticket exchange NFTs) received by smart contract 102 as request transmission tokens.

[0161] When smart contract 102 receives an NFT request, it determines whether the quantity of FTs received matches the required number of ticket NFTs to be purchased (step S141). This determination is performed by the FT quantity determination module 116. The required number of ticket NFTs to be purchased has been notified to the user terminal in advance.

[0162] If the quantity of FTs does not match the required number of NFTs to purchase, error handling is performed, such as notifying the user terminal 300 of this fact (step S142). In this case, the ticket issuance process is terminated.

[0163] If the quantity of FTs matches the required number for purchasing ticket NFTs, the conditions for generating the target NFT are then determined (step S143). Here, the number of target NFTs to be issued P=1 and the type of target NFT T=E event are determined as the conditions based on the received ticket information. These conditions indicate that one ticket NFT for event E should be issued as the target NFT. The conditions for generating the target NFT may also be determined by the number or type of FTs or NFTs (ticket redemption NFTs) received by smart contract 102 as request sending tokens.

[0164] Next, according to the generation conditions, the initial NFT issuance process for P (1) initial NFTs is executed, and the identifiers of the initial NFTs are obtained (step S144). The initial NFT issuance process may be performed such that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T=E event.

[0165] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates the target NFT, which is a ticket NFT (step S145). The server 200 may also obtain generation conditions such as "initial NFT type T" by referring to the initial NFT record in the blockchain.

[0166] In the NFT configuration data embedding process, according to the type of target NFT T = E-event, configuration data for the E-event (e.g., image data for the E-event, character data indicating the name of the E-event, ticket number, seat, date, etc.) is selected from among multiple NFT material data 240. The database 230 contains multiple material data 240, corresponding to the multiple types of events. In other words, the database 230 contains material data for E-events. Based on the type T identified based on the received identification information, the system 20 can select the material data to be used as configuration data from among the multiple material data. Here, since the ticket information (E-event) received as identification information indicates one of the multiple material data, the system 20 can select the data to be embedded in the NFT from among the multiple material data based on the identification information (E-event). Then, the configuration data for the E-event is embedded in the initial NFT, and the ticket NFT for the E-event is completed. The name of the E-event, etc., is common material data that can also be used to generate other configuration data, and the ticket number, etc., is information to make the configuration data unique. The configuration data may be incorporated when the initial NFT is issued. System 20 has a private key used to generate the ticket NFT, and uses that private key to generate the ticket NFT. System 10 has a private key for NFT generation, so it can generate the ticket NFT without using the user's private key. When the ticket NFT is completed, Server 200 sends a completion notification to Smart Contract 102. When Smart Contract 102 receives the incorporation completion notification, it recognizes that the ticket NFT generation is complete (step S146) and sends the ticket NFT to the user account that sent the FT (step S147).

[0167] As described above, the user can obtain a ticket NFT in exchange for payment of the FT. Since the system 20 according to this embodiment generates the ticket NFT after the FT is paid, it does not need to hold various types of ticket NFTs to be given to the user before the FT is paid. Furthermore, a ticket NFT request does not necessarily have to be accompanied by payment for the purchase of the ticket NFT.

[0168] <2.3 Third Embodiment: Certificate NFT Generation System>

[0169] Figure 15 shows an example of the system 30 according to the third embodiment. In the third embodiment, aspects not specifically described are the same as those of the system 10 according to the first embodiment and the system 20 according to the second embodiment.

[0170] The system 30 according to the third embodiment includes a smart contract 103 implemented in a computer network system such as a blockchain, and a server 200. The system 30 according to the third embodiment generates certificate NFTs in order to provide certificate NFTs such as guarantee certificate NFTs. The system 30 can communicate via the network with a user computer such as a terminal 300 (user terminal) owned by a user who wishes to issue a certificate NFT.

[0171] The smart contract 103 according to the third embodiment is configured to execute certificate NFT generation processing. The server 200 according to the second embodiment is configured to execute NFT configuration data embedding processing 212.

[0172] The certificate NFT provided by the system 30 according to the third embodiment is an NFT representation of a certificate, such as a guarantee certificate. The certificate NFT is displayed on a computer screen. The certificate NFT can also be traded with any third party.

[0173] A warranty certificate is a document that certifies any guarantee regarding, for example, everyday goods, jewelry, electrical products, electronic products, machinery, or other goods, services, or rights (rights, obligations, or responsibilities). The certificate is a document that certifies the aforementioned guarantee or other facts.

[0174] The warranty certificate NFT according to this embodiment is constructed by incorporating constituent data, such as image data or text data indicating that it is a warranty certificate, into an NFT issued on the blockchain. An NFT with incorporated constituent data has, for example, the constituent data itself or a URI that indicates the constituent data. The URI may directly or indirectly indicate the constituent data. For example, if a warranty certificate NFT functions as a warranty certificate that guarantees repairs for imperfections, defects, or malfunctions of products such as home appliances, it may incorporate image data of the home appliance and text data indicating the warranty details. The constituent data incorporated into the certificate NFT may differ depending on the type of certificate. Therefore, there may be multiple types of warranty certificate NFTs.

[0175] The system 30 according to the third embodiment can generate a warranty certificate NFT corresponding to the type of product covered by the warranty and provide it to the user. As shown in Figure 15, the system 30 according to the third embodiment receives a certificate NFT request from the user terminal 300, generates a warranty certificate NFT as the target NFT, and sends it to the user terminal 300 (user account). The warranty period for the product covered by the warranty may be calculated from the date of purchase of the product (warranty start date), or from the date on which the warranty certificate NFT is issued on the blockchain (warranty start date).

[0176] Figure 16 shows the procedure for issuing a warranty certificate in the warranty certificate issuance smart contract 103. First, the smart contract 103 receives an NFT request from the user terminal 300. The NFT request here is a request for the issuance of a warranty certificate NFT. Along with the NFT request, the smart contract 103 also receives product information of the product covered by the warranty. The product information includes at least one of the following: product name, date and time of purchase, place of purchase, and product-specific code (product-specific identifier). Preferably, the product information is recorded in a machine-readable code (e.g., a 2D code) attached to the product or documents or other objects attached to the product. For example, the user terminal 300 can obtain the product information by reading the 2D code with its camera (code reader). The product information may also exist as electronic data stored on a computer on the network (e.g., server 200), indicated by a URI (Uniform Resource Identifier) ​​indicated by the machine-readable code. In this case, the user terminal 300's camera reads the code, and by accessing the URI indicated by that code via the network, product information can be obtained.

[0177] Product information is used to identify the type of NFT that is the intended NFT, which is a certificate of authenticity NFT.

[0178] When smart contract 103 receives an NFT request, it determines whether the received product information is valid (step S161). This determination is, for example, whether the product-specific code actually exists.

[0179] If the quantity of FT indicates that the product information is unsuitable, error processing is performed, such as notifying the user terminal 300 of this (step S162). In this case, the warranty certificate issuance process is terminated.

[0180] If the product information is appropriate, the generation conditions for the target NFT are then determined (step S163). Here, the generation conditions are determined based on the received product information, with the number of target NFTs to be issued P=1 and the type of target NFT T=G product. These generation conditions indicate that one certificate NFT for product G should be issued as the target NFT.

[0181] Next, according to the generation conditions, the initial NFT issuance process for P (1) initial NFTs is executed, and the identifiers of the initial NFTs are obtained (step S164). The initial NFT issuance process may be performed so that the issued initial NFTs include data indicating the generation conditions, such as the type of target NFT T=G product.

[0182] When the server 200 detects the issuance of an initial NFT, it obtains the generation conditions for the target NFT and the identifier of the initial NFT, executes the NFT configuration data embedding process, and generates the guarantee certificate NFT, which is the target NFT (step S165). The server 200 may also obtain generation conditions such as "initial NFT type T" by referring to the initial NFT record in the blockchain.

[0183] In the NFT configuration data embedding process, according to the type of target NFT T = G product, configuration data for product G (for example, image data for product G, name of product G, purchase date and time of product G, purchase location of product G, and character data indicating the product-specific code (product-specific identifier) ​​and warranty period) is selected from multiple NFT material data 240. The multiple material data 240 contained in the database 230 have multiple material data depending on the multiple types of products. In other words, the database 230 contains material data for product G. Based on the type T identified based on the received identification information, the system 30 can select the material data to be embedded in the NFT from among the multiple material data. Here, since the product information (product G) received as identification information indicates one of the multiple material data, the system 30 can select the data to be embedded in the NFT from among the multiple material data based on the identification information (product G). Then, when the configuration data for product G is embedded in the initial NFT, the warranty certificate NFT for product G is completed. Note that the configuration data may also be embedded when the initial NFT is issued. System 30 has a private key used to generate a warranty certificate NFT, and uses that private key to generate the warranty certificate NFT. System 10 has a private key for NFT generation, so it can generate a warranty certificate NFT without using the user's private key. When the warranty certificate NFT is completed, Server 200 sends a completion notification to Smart Contract 103. When Smart Contract 103 receives the embedding completion notification, it recognizes that the generation of the warranty certificate NFT is complete (step S166) and sends the warranty certificate NFT to the user account that sent the NFT request (step S167). The name of the G product, etc., is common material data that can also be used to generate other configuration data, and the product-specific code, etc., is information to make the configuration data unique.

[0184] As described above, the user can obtain a warranty certificate NFT. Since the system 30 according to this embodiment generates a warranty certificate NFT after receiving an NFT request, there is no need to prepare a warranty certificate NFT before the NFT request (for example, between the time a product is manufactured and the time it is sold), and the effort of creating a warranty certificate NFT for products that have not yet been sold can be eliminated.

[0185] <2.4 Fourth Embodiment: Storage and Reference of Configuration Data>

[0186] Figure 17 shows a method for storing and referencing configuration data that can be used in the embodiments described above and below. The source data database 240 stores multiple source data. For example, suppose the multiple source data includes a first source data, and the first source data is image data of a certain talent. The first source data is duplicated and stored as first configuration data in the configuration data database 245 of the server 200. In other words, the first configuration data is a duplicate of the first source data. The first configuration data exists as separate data from the first source data by having a different file name or being stored in a different location. On a network such as the Internet, the first configuration data is indicated by a first URI (first uniform resource identifier). The first target NFT is generated when the first configuration data is incorporated into the first initial NFT.

[0187] Furthermore, the first source data is duplicated and stored as second configuration data in the configuration data database 245 of server 200. In other words, the second configuration data is a duplicate of the first source data. The second configuration data exists as separate data from the first source data and the first configuration data by having a different file name or being stored in a different location. On networks such as the Internet, the second configuration data is indicated by a second URI (second uniform resource identifier) ​​that is different from the first URI. The second target NFT is generated when the second configuration data is incorporated into a second initial NFT that is different from the first initial NFT.

[0188] Therefore, the first-purpose NFT and the second-purpose NFT have the same image data of the same talent as constituent data. In other words, the first constituent data of the first-purpose NFT is generated from the first source data that was also used to generate the second constituent data of the second-purpose NFT. However, the first and second constituent data stored in the constituent data database 245 are separate data. That is, the first constituent data is unique data for the first-purpose NFT and will not be incorporated into any other NFT. Similarly, the second constituent data is unique data for the second-purpose NFT and will not be incorporated into the second-purpose NFT. Therefore, each of the first-purpose NFT and the second-purpose NFT can be made unique. For example, by adding the talent's signature image to the first-purpose NFT, a difference in value can be created between it and the second-purpose NFT. Also, the ownership history of the first-purpose NFT can be used to create a difference in value between it and the second-purpose NFT.

[0189] Incorporating the first configuration data into the first initial NFT, which will become the first objective NFT, may, for example, involve writing the first URI or an identifier associated with the first URI into the first initial NFT. The first URI indicates the first configuration data, which is the replicated data. Because the first objective NFT has the first URI, the server 200 can accept network access via the first URI and display the first configuration data on the terminal of the owner of the first objective NFT. The identifier associated with the first URI only needs to be information that the server 200 uses to recognize the first URI. Furthermore, because the first objective NFT has an identifier associated with the first URI, the server 200 can accept network access using the identifier associated with the first URI, identify the first URI from that identifier, and display the first configuration data indicated by that first URI on the terminal of the owner of the first objective NFT. The same applies to the second objective NFT.

[0190] Furthermore, in order to incorporate the first configuration data into the first initial NFT which will become the first target NFT, the server 200 may be configured to set a correspondence between the identifier (NFT-ID) of the first target NFT (first initial NFT) and the first URI. The server 200 accepts network access using the identifier (NFT-ID) of the first target NFT, identifies the first URI from the identifier (NFT-ID) of the first target NFT, and can display the first configuration data indicated by that first URI on the terminal of the owner of the first target NFT. The same applies to the second NFT.

[0191] Database 246 can be configured, for example, by IPFS (InterPlanetary File System). IPFS is an example of a P2P (Peer to Peer) distributed file system. In IPFS, stored data (content) is specified by a URI using a hash value obtained from that data. This URI is an identifier that indicates configuration data and is also called a content identifier. To incorporate configuration data into an NFT, for example, a URI that specifies the configuration data (content) stored in IPFS can be written to the NFT. That is, an NFT can have a URI that indicates the configuration data stored in IPFS. An NFT may have configuration data (content), metadata that includes a URI indicating the configuration data (content), and index data that includes a URI indicating the metadata. The index data may include the NFT identifier (NFT-ID; token identifier) ​​and the NFT owner (owner blockchain address). For example, the index data may be recorded on the blockchain, and the configuration data and metadata may be recorded in IPFS. The initial NFT mentioned above may have index data but not metadata and configuration data. Metadata and configuration data can be added to an NFT through the incorporation process of the configuration data. Index data recorded on the blockchain may have a URI that directly points to configuration data stored outside the blockchain, such as in IPFS, or it may have a URI that indirectly points to the configuration data, such as a URI that points to metadata containing a URI that directly points to the configuration data. Thus, it is not necessary for all of an NFT to be recorded on the blockchain; it is sufficient if at least some of the data, such as the index data, is recorded on the blockchain.

[0192] <2.5 Fifth Embodiment>

[0193] Figure 18 shows an example of a system 50 according to the fifth embodiment. In the fifth embodiment, aspects not specifically described are the same as those of systems 10, 20, and 30 according to the previously described embodiments.

[0194] System 50 can receive an NFT request from a computer such as terminal 300, which has a code C1 indicating image P1 (step S181A). Code C1 may be identification information for system 50 to identify the type of target NFT. The database 230 provided by system 50 contains multiple source data P1, P2, and P3, and each source data P1, P2, and P3 is associated with a code C1, C2, and C3. Code C1 associated with source data P1, P2, and P3 indicates the corresponding source data P1, P2, and P3. In step S181A, system 50 selects a first source data P1 corresponding to the code C1 received and generates a target NFT using the selected first source data P1 (step S182). The target NFT generated using the first source data P1 may be an NFT of the type "having image P1". The target NFT generated using the first source data P1 may include, for example, an identifier for the first source data (e.g., a URI), or an identifier for a copy of the first source data (e.g., a URI).

[0195] Furthermore, the system 50 may receive an NFT request from a computer such as a terminal 300, which has a code C2 indicating an image P2 (step S181B). Code C2 may be identification information for the system 50 to identify the type of target NFT. The system 50 selects a second source data P2 corresponding to the code C2 received in step S181B and generates the target NFT using the selected second source data P2 (step S182). The target NFT generated using the second source data P2 may be an NFT of the type "having an image P2". The target NFT generated using the second source data P2 may include, for example, an identifier for the second source data (e.g., a URI), or an identifier for a copy of the second source data (e.g., a URI).

[0196] Since system 50 possesses material data such as images used to generate NFTs, it can generate NFTs without having to obtain material data used to generate NFTs from an external computer such as terminal 300. However, system 50 may obtain some of the material data used to generate NFTs from an external computer. System 50 can generate NFTs using at least the material data P1, P2, and P3 that it possesses before receiving an NFT request (steps S181A, S181B).

[0197] <2.6 Sixth Embodiment>

[0198] Figure 19 shows an example of a system 60 according to the sixth embodiment. In the sixth embodiment, aspects not specifically described are the same as those of systems 10, 20, 30, and 50 according to the previously described embodiments.

[0199] System 60 can receive NFT requests from computers such as terminal 300 (not shown) (step S191). An NFT request contains data indicating the type of NFT to be generated. The data indicating the type may be identification information for System 50 to identify the type of NFT. The database 230 provided by System 60 contains material data corresponding to multiple types. For example, the database 230 shown in Figure 19 contains multiple material data P11, P12, P13 for a first type (TYPE_A) and multiple material data P21, P22, P23 for a second type (TYPE_B).

[0200] When system 60 receives an NFT request that has data indicating a first type (TYPE_A) as identification information (step S191A), it identifies that the type is the first type (TYPE_A) based on the NFT request. Furthermore, system 60 selects material data (e.g., image P12) to be used to generate the target NFT from among a plurality of material data P11, P12, P13 corresponding to the identified type. The material data used to generate the target NFT is selected from among a plurality of material data P11, P12, P13 corresponding to the identified type (TYPE_A) according to a predetermined rule or randomly. System 60 generates the target NFT using the selected material data (step S192). The generated target NFT may be an NFT of type TYPE_A.

[0201] When system 60 receives an NFT request that has data indicating a second type (TYPE_B) as identification information (step S191B), it identifies that the type is the second type (TYPE_B) based on the NFT request. Furthermore, system 60 selects material data (e.g., image P23) to be used to generate the target NFT from among a plurality of material data P21, P22, P23 corresponding to the identified type. The material data used to generate the target NFT is selected from among a plurality of material data P21, P22, P23 corresponding to the identified type (TYPE_B) according to a predetermined rule or randomly. System 60 generates the target NFT using the selected material data (step S192). The generated target NFT may be an NFT of type TYPE_B.

[0202] <2.7 Seventh Embodiment>

[0203] Figure 20 shows an example of a system 70 according to the seventh embodiment. In the seventh embodiment, aspects not specifically described are the same as those of systems 10, 20, 30, 50, and 60 according to the previously described embodiments.

[0204] System 70 may receive an NFT request from a user terminal 300 (not shown) (step S191). An NFT request may have a code. The code is data assigned or notified to a user who wishes to obtain an NFT. The code may be credentials for the user to obtain the NFT. For example, a first user can receive an NFT by sending a first code assigned or notified to the first user to System 70. Similarly, a second user can receive an NFT by sending a second code assigned or notified to the second user to System 70, and a third user can receive an NFT by sending a third code assigned or notified to the third user to System 70.

[0205] The code may be identification information for system 70 to identify the type of target NFT. The code may also be data for system 70 to identify the type of source data. The database 230 provided by system 70 contains source data corresponding to multiple types. For example, the database 230 shown in Figure 20 contains multiple source data P11, P12, P13 for the first type (TYPE_A) and multiple source data P21, P22, P23 for the second type (TYPE_B).

[0206] System 70 may have a code list (not shown) that shows a list of codes that it may receive. Each of the multiple codes included in the code list is associated with a type. For example, in System 70, the first and second codes are associated with the first type (TYPE_A), and the third code is associated with the second type (TYPE_B). In this case, when System 70 receives an NFT request having the first code (step S201A), or when it receives an NFT request having the second code (step S201B), it identifies that the type of the source data is the first type (TYPE_A) based on the received code. From the source data P11, P12, P13 for the first type (TYPE_A), System 70 selects the source data (e.g., image P11) to be used to generate the target NFT. The source data used to generate the target NFT is selected from multiple source data P11, P12, P13 corresponding to the identified type (TYPE_A) according to a predetermined rule or randomly. System 70 generates the target NFT using the selected material data (step S202). The generated target NFT may be an NFT of type TYPE_A.

[0207] When system 70 receives an NFT request having a third code (step S201C), it identifies that the type of source data is the second type (TYPE_B) based on the received code. From the source data P21, P22, and P23 for the second type (TYPE_B), system 70 selects source data (e.g., image P22) to be used to generate the target NFT. The source data used to generate the target NFT is selected from a plurality of source data P21, P22, and P23 corresponding to the identified type (TYPE_B) according to a predetermined rule or randomly. System 70 generates the target NFT using the selected source data (step S202). The generated target NFT may be an NFT of type TYPE_B.

[0208] Furthermore, if an NFT request does not contain identification information such as a code, systems 10, 20, 30, 50, 60, and 70, upon receiving the NFT request, may select the source data to be used to generate the target NFT from among multiple identification data, either according to a predetermined rule or randomly.

[0209] <2.7 Seventh Embodiment: Use of Private Key>

[0210] Figure 21 illustrates the technology for handling private keys. The technology shown in Figure 21 can be adopted in the system 10 of the first embodiment and in the systems of other embodiments. Smart contracts 110 and 120, upon receiving an NFT request (step S212), digitally sign the transaction for NFT generation using one or more private keys Key1, Key2, and Key3 held by the server 200 of smart contracts 110 and 120 (step S213). The digitally signed transaction is recorded on the blockchain. This generates an NFT (step S214). Because smart contracts 110 and 120 on the blockchain are accessible to third parties, if they possess a private key, there is a risk that the private key could be known to a third party. By having an external computer such as the server 200 hold the NFT generation private keys Key1, Key2, and Key3, the private keys Key1, Key2, and Key3 can be securely stored.

[0211] When smart contracts 110 and 120 require NFT generation (step S214), they notify server 200 and obtain a private key for digital signature. Server 200 appropriately selects one private key from among multiple private keys Key1, Key2, and Key3 to be used for NFT generation and provides it to smart contracts 110 and 120. Smart contracts 110 and 120 digitally sign using the obtained private key. In other words, system 10 generates NFTs using smart contracts 110 and 120, but generates the NFTs using private keys stored on a computer 200 outside of smart contracts 110 and 120. Note that server 200 may also perform the digital signature.

[0212] In Figure 21, smart contracts 110 and 120 can receive an NFT request from the web server 350 (step S212). The web server 350 is an example of a user computer shown in Figure 1. The web server 350 can provide a user interface to the user terminal 300. The user interface is, for example, a website that displays the image to be converted into an NFT and accepts user operations for obtaining the NFT. The user can sign in to the website using the user terminal 300 (step S211). The user's private key 301 is used for signing in. The user has a blockchain address 302 corresponding to the private key 301. In Figure 21, the user's blockchain address 302 is, for example, 0x13579. The blockchain address 302 can be generated from the private key 301.

[0213] By signing in to the website using the private key 301, users can manipulate the blockchain through the website. In other words, the web server 350 can digitally sign transactions recorded on the blockchain using the private key 301 for users who have signed in to the website. The digital signature may also be performed by the user terminal 300.

[0214] One example of blockchain operation by the web server 350 is the invocation of smart contracts 1110 and 120 (step S212). The invocation of smart contracts here also constitutes the sending of an NFT request to the smart contracts.

[0215] When smart contracts 110 and 120 are invoked, the user's blockchain address 302 is sent to smart contracts 110 and 120. Smart contract 302 then sends the generated NFT to the receiving blockchain address 302. In this way, smart contracts 110 and 120 can receive both the NFT request and the destination address 302 for the generated NFT. Note that blockchain address 302 may also be sent to smart contracts 110 and 120 after they have been invoked.

[0216] According to the technology shown in Figure 21, the user only needs to provide the system 10 (e.g., smart contracts 110, 120) with the blockchain address 302 to which the generated NFT will be sent. The user does not need to provide the system 10 (e.g., smart contracts 110, 120) with their private key 301 for NFT generation. Therefore, it is easier to ensure the confidentiality of the user's private key 301.

[0217] Since the private keys used to generate the NFT are not the user's private key 301, but rather the private keys Key1, Key2, and Key3 owned by system 10, system 10 is the owner of the NFT at the time of its generation. However, after the NFT is generated, it is sent to the user's address 302, so the user becomes the owner of the generated NFT.

[0218] The present invention is not limited to the above embodiments, and various modifications are possible.

[0219] The system according to the embodiment may be as follows: That is, the system according to the embodiment is a nonfungible token generation system configured to perform a process for generating a nonfungible token, and may include a database containing a plurality of material data. The process for generating the nonfungible token may include, upon receiving a nonfungible token request, selecting data from the plurality of material data contained in the database according to a predetermined rule or randomly, and generating a nonfungible token using the selected data.

[0220] The method according to the embodiment may be as follows: That is, the method according to the embodiment is a nonfungible token generation method performed by a nonfungible token generation system, wherein the nonfungible token generation system may include a database containing a plurality of material data. The method may include, upon receiving a nonfungible token request, selecting data from the plurality of material data contained in the database according to a predetermined rule or randomly, and generating a nonfungible token using the selected data. [Explanation of Symbols]

[0221] 10: Non-fungible token generation system 20: Non-fungible token generation system 30: Non-fungible token generation system 50: Non-fungible token generation system 60: Non-fungible token generation system 70: Non-fungible token generation system 100: Computer Network Systems 101: Smart Contracts 102: Ticket Issuance Smart Contract 103: Smart Contract for Issuing Warranty Certificates 110: First Smart Contract 111: Module 1 112: Module 2 113: Module 3 114: Module 4 115: Module 5 116: Fungible Token Count Determination Module 117: NFT Type Determination Module 120: Second Smart Contract 200: Server 210: Processor 212: NFT configuration data embedding process 215: Reservation processing 220: Memory 230: Database 240: NFT material data (database of material data) 245: Database of configuration data 250 :NFT generation rules 260: Computer Programs 300: User terminal (user computer) 301: Private Key 302: Blockchain Address 310: Operation screen 311: Button 312: Button 313: Button 314: Button 315: Button 350: Server (Application server; user computer) C1: Category C2: Category C3: Category D1: Image data D2: Image data D3: Image data M: Number of category data N: Number of image data P: Number of units issued T: Type

Claims

1. A non-fungible token generation method executed by a system having multiple material data used to generate multiple types of non-fungible tokens, When a non-fungible token request is received from the user's terminal, a non-fungible token to be provided to the user is generated from material data identified by the non-fungible token request among the plurality of material data. A non-fungible token generation method comprising:

2. A non-fungible token generation method executed by a system having a plurality of material data including first material data and second material data, capable of generating a first type of non-fungible token using the first material data, and capable of generating a second type of non-fungible token using the second material data, When a request for the first type of non-fungible token is received from a user terminal, the system uses first material data stored in the system to generate the first type of non-fungible token for provision to the user; When a request for the second type of non-fungible token is received from a user terminal, the system uses the second material data stored in the system to generate the second type of non-fungible token for provision to the user. A non-fungible token generation method comprising:

3. A system having a plurality of material data and capable of generating a plurality of types of non-fungible tokens using the plurality of material data, Generate a non-fungible token of a type corresponding to the non-fungible token request from the user's terminal using material data corresponding to the non-fungible token request from the plurality of material data possessed by the system, in order to provide the non-fungible token to the user; A system that is configured to run

4. A system having a plurality of material data including first material data and second material data, capable of generating a first type of non-fungible token using the first material data, and capable of generating a second type of non-fungible token using the second material data, When a request for the first type of non-fungible token is received from a user terminal, the system uses first material data stored in the system to generate the first type of non-fungible token for provision to the user; When a request for the second type of non-fungible token is received from a user terminal, the system uses the second material data stored in the system to generate the second type of non-fungible token for provision to the user. A system that is configured to run

Images