Information processing device, information processing system, and information processing method

Abstract

An information processing server 2 comprises a server information processing unit 10 which includes: a function for issuing, to a holder owning a first type of non-fungible token (NFT), a second type of NFT different from the first type, in response to a request from the holder; a function for providing a platform for transferring the second type of NFT from the holder to a user; and a function for giving a privilege to the user in response to an action in a token economic zone by the user who owns the second type of NFT.

Description

Information processing device, information processing system, and information processing method

[0001] The present invention relates to an information processing device, an information processing system, and an information processing method related to a token economy.

[0002] Blockchain technology has become widely used. Some blockchain platforms that use blockchain technology can issue their own tokens. Tokens are divided into at least two types: Fungible Tokens (FTs) and Non-Fungible Tokens (NFTs). There have been widespread attempts to build token economies that utilize tokens issued using blockchain technology. A token economy is a unique economic sphere in which participants acquire tokens, circulate tokens, consume tokens, and engage in other token-related activities, thereby circulating the economy. A token economy is also sometimes called an ecosystem, token economy, or simply an economic sphere.

[0003] Regarding this token economy, Patent Literature 1 discloses the following technology. Specifically, in Patent Literature 1, a data management system acquires participants' token transaction histories and their activity histories within the token economy (ecosystem). The data management system calculates a loyalty index representing the loyalty level of multiple participants to the token economy (ecosystem) based on the transaction histories and activity histories. The data management system aggregates the loyalty indices for multiple participants and estimates the loyalty level of the entire ecosystem. The above technology is disclosed.

[0004] JP 2023-87990 A

[0005] Regarding the construction of a token economy, it is necessary to build a token economy with a new mechanism that encourages participants to take actions that contribute to the revitalization of the token economy, because the revitalization of the token economy will enable its sustainable growth.

[0006] The present invention has been made to solve these problems, and aims to build a token economy with a new mechanism that encourages participants to take actions that contribute to the revitalization of the token economy.

[0007] To solve the above-mentioned problems, the present invention provides a platform for issuing a second type of NFT to a holder who owns a first type of NFT in response to a request from the holder, transferring the second type of NFT from the holder to a user, and granting rewards to users who own the second type of NFT in response to their actions in the token economy.

[0008] According to the present invention configured as described above, a holder who is a participant in the token economy can issue a second type of NFT by possessing a first type of NFT. Furthermore, the holder can transfer the second type of NFT to a user using the provided platform. Therefore, the holder is motivated to possess the first type of NFT, issue a second type of NFT, and then use the platform to transfer the second type of NFT to a user. Based on this motivation, the holder is expected to actively take the action of possessing the first type of NFT, issuing a second type of NFT, and using the platform to transfer the second type of NFT to a user. Such an action has the effect of promoting the use or circulation of tokens in the token economy and contributes to the revitalization of the token economy. Furthermore, a user who is a participant in the token economy can acquire a second type of NFT using the provided platform. Furthermore, if the user possesses a second type of NFT, a reward is granted based on the user's actions in the token economy. Therefore, the user is motivated to use the platform to acquire a second type of NFT and receive a reward. With this motivation, it is expected that users will actively acquire the second type of NFT through the platform and take actions to receive benefits in the token economy. Such actions have the effect of encouraging the use or circulation of tokens within the token economy and contribute to the revitalization of the token economy. As described above, according to the present invention, it is possible to build a token economy with a new mechanism that encourages participants to take actions that contribute to the revitalization of the token economy.

[0009] FIG. 1 is a diagram illustrating an example of the configuration of an information processing system according to an embodiment. FIG. 2 is a block diagram illustrating an example of the functional configuration of a holder terminal, a user terminal, and an information processing server according to an embodiment. FIG. 3 is a diagram used to explain an overview of the token economy. FIG. 4 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 5 is a diagram illustrating an example of a list screen of parent NFTs owned by a holder. FIG. 6 is a diagram illustrating an example of an issuance completion notification screen. FIG. 7 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 8 is a diagram illustrating an example of a list screen of child NFTs owned by a holder. FIG. 9 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 10 is a diagram illustrating an example of a sales price related screen. FIG. 11 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 12 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 13 is a diagram illustrating an example of a seller NFT list screen. FIG. 14 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 15 is a diagram illustrating an example of a user-owned child NFT list screen. FIG. 16 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 17 is a flowchart illustrating an example of the operation of an information processing system according to an embodiment. FIG. 18 is a diagram showing an example of a scene on the game screen.

[0010] An embodiment will be described below with reference to the drawings. Fig. 1 is a diagram showing an example of the configuration of an information processing system 1 according to this embodiment. As shown in Fig. 1, the information processing system 1 includes an information processing server 2 (information processing device, computer), one or more holder terminals 3 (information processing device, computer), and one or more user terminals 4 (information processing device, computer). The information processing server 2, the holder terminals 3, and the user terminals 4 can be connected to a network N, which may include the Internet, a telephone network, or other communication networks.

[0011] As shown in FIG. 1, an information processing server 2, a holder terminal 3, and a user terminal 4 can be connected to a blockchain network B via a network N. For ease of explanation, FIG. 1 depicts the network N and the blockchain network B separately. The blockchain network B is a P2P distributed network related to Ethereum, in which a large number of nodes are connected to each other using a P2P method. Note that the blockchain network B according to this embodiment includes a network related to the Ethereum Layer 2 platform and a network that can be linked to other blockchain networks B. Examples of the Ethereum Layer 2 platform are Arbitrum or Polygon. Each node in the blockchain network B stores a blockchain (distributed ledger) using blockchain technology.

[0012] Note that in FIG. 1, the information processing server 2 is depicted outside the blockchain network B. However, the information processing server 2 may be configured to function as one of the nodes (however, it does not have to be a full node) that make up the blockchain network B. The same applies to the holder terminal 3 and the user terminal 4. The information processing server 2 may also be configured to request other devices (for example, devices that function as endpoints of the blockchain network B) to send transactions to the blockchain network B, execute specific functions of specific smart contracts, check the status of specific accounts in the world state, and perform all or part of other processing that involves accessing the blockchain network B. The same applies to the holder terminal 3 and the user terminal 4.

[0013] Because blockchain network B is an Ethereum-related network, smart contracts can be registered (deployed) on the blockchain. Blockchain network B can at least issue FTs (Fungible Tokens) and NFTs (Non-Fungible Tokens) using smart contracts. FTs are fungible tokens. In this embodiment, FTs are tokens that comply with ERC-20. NFTs are tokens that do not have fungibility. NFTs are widely used to prove the uniqueness and ownership of digital assets. In this embodiment, NFTs are tokens that comply with ERC-721a.

[0014] In this embodiment, blockchain network B is a network related to Ethereum, but this is merely an example. Blockchain network B may be a network built on a blockchain platform other than Ethereum. The blockchain may be a public chain, a private chain, or a consortium chain. The standards to which FT and NFT comply are not limited to the standards shown in the examples. The term "smart contract" is a convenient name for a program unit (a collection of program modules and associated data) registered in a blockchain. In other words, a smart contract may be an object that has the functions described below as the functions of a smart contract.

[0015] The information processing server 2 has the functions of providing various services, executing processes related to the token economy, and establishing a token economy. Hereinafter, the service provided by the information processing server 2 will be referred to as the "Service." The token economy established by the information processing server 2 will be referred to as the "Token Economy." The Service and the Token Economy will be described later. Hereinafter, the entity that operates the Service via the information processing server 2 will be referred to as the "Administrator." Hereinafter, those who may participate in the token economy will be referred to as "Participants." Participants include holders and users, which will be described later. In FIG. 1 and FIG. 2, which will be described later, the information processing server 2 is represented by a single block. However, this does not mean that the information processing server 2 is composed of a single server device. For example, the information processing server 2 may be composed of multiple server devices. In this case, the server devices that constitute the information processing server 2 may include a web server or a web application server.

[0016] The holder terminal 3 is a terminal (computer) used by the holder. More about holders will be described later. The holder terminal 3 is a convenient reference to a terminal used by the holder, and does not mean a terminal used exclusively by the holder. The holder terminal 3 may be of any type. For example, a tablet computer (including a so-called smartphone), a desktop computer, or a notebook computer can function as the holder terminal 3. The user terminal 4 is a terminal (computer) used by a user. More about users will be described later. The user terminal 4 is a convenient reference to a terminal used by a user, and does not mean a terminal used exclusively by a user. The user terminal 4 may be of any type.

[0017] 2 is a block diagram showing an example of the functional configuration of the information processing server 2, the holder terminal 3, and the user terminal 4. As shown in Fig. 2, the information processing server 2 includes, as its functional configuration, a server information processing unit 10 (information processing unit), a server communication unit 11, and a server storage unit 12. The holder terminal 3 includes, as its functional configuration, a holder terminal information processing unit 13 (information processing unit), a holder terminal communication unit 14, a holder terminal display unit 15, a holder terminal input unit 16, and a holder terminal storage unit 17. The user terminal 4 includes, as its functional configuration, a user terminal information processing unit 18 (information processing unit), a user terminal communication unit 19, a user terminal display unit 20, a user terminal input unit 21, and a user terminal storage unit 22.

[0018] The server information processing unit 10 of the information processing server 2 includes a processing unit and a main memory. The processing unit is a device with information processing capabilities and includes a CPU. The CPU includes a control unit, an arithmetic unit, a register, and a cache memory. The main memory includes a DRAM and other volatile memory. The server information processing unit 10 executes information processing by having the processing unit load a program stored in the server memory unit 12 into the main memory and execute it. In other words, the server information processing unit 10 executes information processing through cooperation between hardware and software. The server communication unit 11 includes a communication unit with the function of communicating with external devices. The communication unit includes a communication control unit and a network interface. The server communication unit 11 communicates with external devices via the communication unit under the control of the server information processing unit 10. Hereinafter, detailed description of communication using the network N by the information processing server 2 and other communications will be omitted, assuming that they are appropriately performed by the server communication unit 11. The server memory unit 12 includes a hard disk drive (or other magnetic storage device), ROM, flash memory, and other nonvolatile memory. The server memory unit 12 stores data in the nonvolatile memory.

[0019] The holder terminal information processing unit 13 of the holder terminal 3 includes a processing device with information processing capabilities and a main memory device. The holder terminal information processing unit 13 performs information processing by having the processing device read a program stored in the holder terminal storage unit 17 into the main memory device and execute it. In other words, the holder terminal information processing unit 13 performs information processing through cooperation between hardware and software. The holder terminal communication unit 14 includes a communication device having a communication control device and a network interface. The holder terminal communication unit 14 communicates with external devices via the communication device under the control of the holder terminal information processing unit 13. Hereinafter, detailed description of communication using the network N by the holder terminal 3 will be omitted, assuming that it is appropriately performed by the holder terminal communication unit 14. The holder terminal display unit 15 includes a liquid crystal panel, an organic EL panel, or other display device. The holder terminal display unit 15 displays images on the display device under the control of the holder terminal information processing unit 13. The holder terminal input unit 16 includes a keyboard, a mouse, a touch panel, or other input device. The holder terminal input unit 16 detects input to the input device and outputs the detection result to the holder terminal information processing unit 13. The holder terminal storage unit 17 includes a nonvolatile memory and stores data in the nonvolatile memory.

[0020] The user terminal information processing unit 18 of the user terminal 4 includes a processing device with information processing capabilities and a main memory device. The user terminal information processing unit 18 performs information processing by having the processing device read a program stored in the user terminal storage unit 22 into the main memory device and execute it. In other words, the user terminal information processing unit 18 performs information processing through cooperation between hardware and software. The user terminal communication unit 19 includes a communication device having a communication control device and a network interface. The user terminal communication unit 19 communicates with external devices via the communication device under the control of the user terminal information processing unit 18. Hereinafter, detailed description of communication using the network N by the user terminal 4 will be omitted, assuming that it is appropriately performed by the user terminal communication unit 19. The user terminal display unit 20 includes a display device. The user terminal display unit 20 displays images on the display device under the control of the user terminal information processing unit 18. The user terminal input unit 21 includes an input device. The user terminal input unit 21 detects input to the input device and outputs the detection result to the user terminal information processing unit 18. The user terminal storage unit 22 includes non-volatile memory. The user terminal storage unit 22 stores data in a non-volatile memory.

[0021] As shown in FIG. 2 , a dedicated application AP (hereinafter referred to as the “dedicated application AP”) is installed in each of the holder terminal storage unit 17 of the holder terminal 3 and the user terminal storage unit 22 of the user terminal 4. The dedicated application AP is dedicated software that implements functions such as providing various screens related to the Service, transmitting and receiving various information to and from the information processing server 2, and executing other processes related to the Service and the Token Economy. With regard to processes related to the Service and the Token Economy, the holder terminal information processing unit 13 and the user terminal information processing unit 18 basically execute processes using the functions of the dedicated application AP (including the terminal's OS, web applications that the dedicated application AP can use, and other programs that can cooperate with the dedicated application AP). Even if not specifically described, the holder terminal information processing unit 13 and the user terminal information processing unit 18 execute the following processes as necessary. That is, the holder terminal information processing unit 13 and the user terminal information processing unit 18 communicate with the server information processing unit 10 of the information processing server 2 as necessary and obtain necessary information from the server information processing unit 10. Furthermore, the holder terminal information processing unit 13 and the user terminal information processing unit 18 communicate with the server information processing unit 10 as necessary, request the server information processing unit 10 to execute necessary processing, and obtain the processing results. The information processing server 2 stores all the information to be provided to the holder terminal information processing unit 13 and the user terminal information processing unit 18. Furthermore, the server information processing unit 10 has a function of executing processing in response to requests from the holder terminal information processing unit 13 and the user terminal information processing unit 18.

[0022] <Overview of the Token Economy> Next, we will explain the overview of the Token Economy. The Token Economy is an economy in which participants take actions related to various tokens (including the parent NFT, child NFT, utility token, and governance token described below) and the economy circulates. Participants in the Token Economy include at least holders and users. The term "holder" is a convenient term to refer to participants in the Token Economy who can acquire parent NFTs (described below). The term "user" is a convenient term to refer to participants who can acquire child NFTs (described below) through the transition platform PF (platform) (described below). Holders and users register accounts with the Service and can log in to their accounts on the Service using their own login information (e.g., a combination of a login ID and password). The terms "holder" and "user" are used to conveniently distinguish participants by role. Therefore, one person can participate in the Token Economy as both a holder and a user.

[0023] The server information processing unit 10 of the information processing server 2 provides a basic service SV (service) as one of the present services. It is assumed that users will use the basic service SV. The basic service SV is a communication service that enables communication between users. With the basic service SV, users can post messages, chat with other users or contact them by phone, create groups, and join groups created by other users. A group is a closed community, and users belonging to the group can communicate with each other. Note that the content of the basic service SV in this embodiment is an example. The basic service SV may be any service that can be used by users. For example, the basic service SV may be a business communication service, a video posting / viewing service, a text posting service, or an online shopping service.

[0024] In the present token economy, the operator issues a predetermined number of first-type NFTs (e.g., 5,000 units). The initial owner of the first-type NFTs is the operator. Hereinafter, the first-type NFTs are referred to as "parent NFTs." In other words, a parent NFT does not refer to a specific NFT, but rather to an NFT of the first type. The parent NFTs can be secondary sold in a publicly available NFT marketplace (hereinafter referred to as the "public marketplace"). The operator's issuance of parent NFTs is described in detail below. The operator first deploys a smart contract corresponding to the parent NFT (hereinafter referred to as the "parent NFT-compatible contract") to blockchain network B. Next, the operator creates a state in the parent NFT-compatible contract in which a token ID, an operator external address, and associated information (including a token URI) are associated with each of the predetermined number of parent NFTs. The operator external address is the address of the operator's external account in Ethereum. Hereinafter, a wallet associated with an operator external address will be referred to as an operator external wallet. As a result of the above, a state is created in which a predetermined number of parent NFTs (owned by the operator) have been issued.

[0025] The metadata of a parent NFT includes the following items: Token ID <item>, Name <item>, Creator <item>, Detailed Information <item>, Parent NFT Image <item>, and Last Child NFT Issuance Date <item>. However, the items of the parent NFT metadata are not limited to these items. For parent NFTs and other NFTs, metadata can be accessed based on the corresponding token URI of the corresponding smart contract. Appropriate values ​​are set for the Token ID <item>, Name <item>, Creator <item>, and Detailed Information <item> of the parent NFT metadata. A URI for accessing the image data of the corresponding parent NFT image (hereinafter referred to as "parent NFT image data") is set for the Parent NFT Image <item>. The parent NFT image is an image depicting a character resembling a person. The content of the parent NFT image varies for each parent NFT. Figure 5, described below, shows an example of a parent NFT image. The last child NFT issuance date and time information is set in the last child NFT issuance date and time <item>. The last child NFT issuance date and time information is information indicating the date and time when the child NFT was last issued based on the corresponding parent NFT. The initial value of the last child NFT issuance date and time information is a special value. The last child NFT issuance date and time information will be described later. The significance of the parent NFT will be described later.

[0026] The method for issuing parent NFTs is not limited to the method exemplified in this embodiment. For example, instead of issuing a predetermined number of parent NFTs at once, parent NFTs may be issued in stages until the predetermined number is reached. Furthermore, parent NFTs may not be issued using a dedicated smart contract. In this case, parent NFTs are issued using a public marketplace service, for example. Furthermore, the server information processing unit 10 may mint parent NFTs each time they are distributed to a holder.

[0027] Furthermore, with regard to the Token Economy, the operator deploys a smart contract to blockchain network B for issuing a second type of NFT, different from the first type. Hereinafter, the second type of NFT will be referred to as a "child NFT." In other words, a child NFT does not refer to a specific NFT, but rather to an NFT of the second type. Hereinafter, a smart contract for issuing a child NFT will be referred to as a "child NFT-compatible contract." The meaning of a child NFT will be explained later.

[0028] Furthermore, with regard to the Token Economy, the Operator will issue the Governance Token on Ethereum. Hereinafter, the Governance Token will be referred to as the "GT." The GT is a Fungible Token (FT) for the Token Economy. The GT functions as a governance token granted the right to exercise influence over the operation of the Token Economy. Hereinafter, the symbol for the GT will be "gt," which will be used as the unit of measurement for the GT. The total issuance of the GT is, for example, 10 billion gt. With regard to the issuance of the GT, the Operator will deploy a token contract (an ERC-20 compliant smart contract) corresponding to the GT to blockchain network B. The token name, symbol, number of decimal points, total issuance amount, and other necessary settings will be appropriately configured in the token contract. Once the Operator has completed the necessary steps, the GT will become available for trading on publicly available cryptocurrency exchanges (hereinafter referred to as "public exchanges"). As described above, the GT is an FT that can be used in the Token Economy and traded on public exchanges. The significance of the GT will be explained later.

[0029] Furthermore, with regard to the Token Economy, the Operator will issue the Utility Token on Ethereum. Hereinafter, the Utility Token will be referred to as the "UT." The UT is an FT related to the Token Economy. The UT will circulate in the Token Economy and function as a utility token that can be used within the Service. Hereinafter, the symbol for the UT will be "ut," which will be used as the unit of the UT. The total issuance amount of the UT will not be set. With regard to the issuance of the UT, the Operator will deploy a token contract (a smart contract compliant with ERC-20) corresponding to the UT to blockchain network B. Various settings will be appropriately configured in the token contract. Once the Operator has performed the necessary work, the UT will become subject to trading on public exchanges. As described above, the UT is an FT that can be used in the Token Economy and traded on public exchanges. The significance of the UT will be explained below.

[0030] Figure 3 is a diagram used to explain the overview of the token economy. The following explains the overview of the token economy using Figure 3. However, the following explanation using Figure 3 is intended to provide an overall picture of the token economy. The various terms related to the token economy, the various actions of participants, the various processes of the information processing system 1, and the significance of the various processes performed by the information processing system 1 will be described later.

[0031] As shown in FIG. 3, a holder acquires a parent NFT (step F1). The owner of the parent NFT is granted the right to issue a child NFT. In other words, the parent NFT functions as a certificate certifying the right to issue a child NFT. While in possession of the parent NFT, the holder requests the server information processing unit 10 of the information processing server 2 to issue a child NFT based on the parent NFT (step F2). In response to the request, the server information processing unit 10 issues the child NFT to the holder (step F3). The holder then acquires and owns the child NFT. The holder pays a fee to the operator when issuing the child NFT. The child NFT has an attribute called a status. The status of the child NFT transitions from a suspended state to a valid state to an invalid state when a specific event is triggered. When the child NFT is issued, the status of the child NFT is suspended. After issuing a child NFT in response to a request from a holder who owns a parent NFT, the server information processing unit 10 prohibits the issuance of child NFTs based on that parent NFT for a waiting period (a certain period of time). In this embodiment, the waiting period is 72 hours. A holder can issue child NFTs any number of times as long as they own the parent NFT, provided that they wait an interval equal to or longer than the waiting period. Note that the specific value of the waiting period is not limited to 72 hours. The server information processing unit 10 may also be configured to dynamically change the value of the waiting period based on the supply and demand situation for child NFTs, the distribution situation of child NFTs or parent NFTs, and other circumstances related to the child NFT or parent NFT.

[0032] As shown in FIG. 3, the server information processing unit 10 provides a transfer platform PF. The transfer platform PF is a platform for transferring child NFTs from holders to users. The transfer platform PF includes the present Market MK (first platform) and the present Pool PL (second platform). The present Market MK is a platform that realizes transactions of child NFTs between holders and users, with holders as sellers and users as buyers. Holders can use the present Market MK to set a sales price denominated in Ethereum and sell child NFTs. Users can use the present Market MK to purchase desired child NFTs from among the child NFTs currently for sale. The present Pool PL is a platform where holders supply child NFTs free of charge and users can acquire the child NFTs supplied by the holders free of charge.

[0033] As shown in FIG. 3, the Holder either provides the Child NFTs to the Pool PL free of charge (step F4) or sells the Child NFTs on the Market MK (step F5). Hereinafter, providing the Child NFTs to the Pool PL free of charge may be referred to as "providing the Child NFTs using the Pool PL." Selling the Child NFTs on the Market MK may be referred to as "providing the Child NFTs using the Market MK." When the Holder provides the Child NFTs using the Pool PL, the server information processing unit 10 grants the Holder a benefit. More specifically, the server information processing unit 10 periodically grants the Holder a predetermined amount of the GT during the Pool Benefit Period. In this embodiment, the Pool Benefit Period is 120 days. In other words, when the Holder provides the Child NFTs using the Pool PL, the Holder periodically receives a predetermined amount of the GT from the operator during the Pool Benefit Period of 120 days.

[0034] As shown in FIG. 3 , a user acquires a child NFT using the Pool PL (step F6) or the Market MK (step F7). When using the Pool PL, the user acquires the child NFT free of charge. When using the Market MK, the user purchases the child NFT by paying a set sales price. When the user acquires the child NFT, the child NFT's status is inactive. After purchasing the inactive child NFT, the user requests, using a specified user interface, that the child NFT be transitioned from the inactive state to the active state (step F8). In response to the request, the server information processing unit 10 transitions the child NFT to the active state. Furthermore, after a certain period (the active period + α) has elapsed since the child NFT was transitioned to the active state, the server information processing unit 10 transitions the NFT from the active state to the inactive state (step F9). In this embodiment, the active period is 90 days.

[0035] As shown in FIG. 3, a user who possesses a valid child NFT uses the basic service SV (step F10). The server information processing unit 10 grants a game ticket based on the user's behavior in the basic service SV (step F11). In this manner, a game ticket is granted to a user who possesses a valid child NFT. The user who has acquired the game ticket consumes the game ticket to play the Game (step F12). The Game is a game played using one or more valid child NFTs, and has a winning or losing outcome. After the Game ends, the server information processing unit 10 grants the user a bonus (step F13). More specifically, the server information processing unit 10 grants the user a predetermined amount of the UT. If the user wins the Game, the server information processing unit 10 grants the user a larger amount of the UT than if the user loses. Furthermore, if other conditions are the same, the server information processing unit 10 will grant a larger amount of UT in this case when a user acquires a child NFT using the market MK in this case compared to when the user acquires the child NFT using the pool PL in this case.

[0036] The user who has acquired the UT uses the UT (step F14). In this embodiment, the user can use the UT in at least the following ways. That is, the user can consume the UT to participate in events that increase the combat power of the "valid child NFT" that the user owns. Combat power will be described later. The user can also exchange the UT for legal tender, Ether, or other value on a public exchange, thereby enjoying economic benefits. In addition, the server information processing unit 10 provides various platforms that allow users to improve their satisfaction or earn profits in exchange for consuming the UT.

[0037] The above is an overview of the Token Economy. As explained above, in the Token Economy, participants (holders) and participants (users) take actions related to various tokens, which circulates the economy.

[0038] Next, the operation of the information processing system 1 will be explained by dividing it into scenes. In the following explanation, one of the holders will be referred to as a "noted holder," and the behavior of the holder will be explained by focusing on the noted holder as appropriate. Also, one of the users will be referred to as a "noted user," and the behavior of the user will be explained by focusing on the noted user as appropriate.

[0039] <Scene in which a Holder Acquires a Parent NFT> First, the operation of the information processing system 1 in a scene in which a Holder acquires a Parent NFT will be described. This scene corresponds to step F1 in FIG. 3. Here, the Holder possesses a Holder external wallet. The Holder external wallet is a wallet associated with at least the address of the Holder's external account in Ethereum (hereinafter referred to as the "Holder external address"). The Holder external wallet can be connected to public exchanges, public marketplaces, and other services. The Holder external wallet can manage Ether, which is Ethereum's internal currency, NFTs traded in public marketplaces, and tokens traded on public exchanges. Furthermore, the Holder external wallet can manage the Parent NFT, Child NFTs, the GT, and the GT.

[0040] A holder acquires a parent NFT, for example, by the following method. For example, the operator distributes a parent NFT that the operator owns to the holder, and the holder thereby acquires the parent NFT. Distributing a parent NFT to a holder means transferring ownership of the parent NFT from the operator to the holder. The operator distributes the parent NFT to one or more specific holders according to a pre-planned plan, for example. Furthermore, the operator distributes the parent NFT to one or more holders selected according to predetermined rules during an event or campaign. When the operator distributes a parent NFT to a holder, the information processing server 2 executes the following process. That is, the server information processing unit 10 of the information processing server 2 sends an appropriate transaction to the blockchain network B and changes the address associated with the token ID of the parent NFT in the parent NFT-compatible contract to the holder's external holder address. As a result, the parent NFT is distributed to the one holder, and the one holder comes into possession of the parent NFT.

[0041] Unless otherwise specified, the transfer of ownership of the parent NFT and other NFTs by the server information processing unit 10 is appropriately performed by the server information processing unit 10 sending the necessary transactions to the blockchain network B, updating the necessary databases, and executing other necessary processes. Furthermore, the method by which a holder acquires a parent NFT is not limited to distribution by the operator. For example, a holder can acquire a parent NFT by purchasing a parent NFT that has been resold in a public marketplace. A holder can also acquire a parent NFT by receiving a transfer of the parent NFT from another holder who owns the parent NFT.

[0042] The Parent NFT functions as a certificate certifying the right to issue Child NFTs. By issuing Child NFTs based on the Parent NFTs they own, holders can receive various benefits, as described below. Therefore, holders are motivated to acquire and own Parent NFTs. Driven by this motivation, holders are expected to proactively take action to acquire and own Parent NFTs. Such actions have the effect of increasing the market value of Parent NFTs and encouraging the use and circulation of tokens in the Token Ecosystem. Therefore, such actions revitalize the Token Ecosystem. Furthermore, because Parent NFTs can be resold in public marketplaces, holders can, in certain cases, sell Parent NFTs and obtain economic benefits.

[0043] <Scene in which a holder issues a child NFT based on a parent NFT> Next, the operation of the information processing system 1 in a scene in which a holder issues a child NFT based on a parent NFT will be described. This scene corresponds to steps F2 and F3 in FIG. 3. FIG. 4 is a flowchart showing an example of the operation of the holder terminal 3 and the information processing server 2 in this scene. Flowchart FA shows an information processing method by the holder terminal 3, and flow chart FB shows an information processing method by the information processing server 2. In FIG. 4, a target holder operates the holder terminal 3. The target holder also owns one or more parent NFTs.

[0044] The holder of interest launches the dedicated application AP on the holder terminal 3, enters login information, and logs in to the account for the service. The holder of interest then connects his or her own external wallet to the service. The holder's external wallet is connected by entering necessary information about the holder's wallet into a predetermined user interface provided by the dedicated application AP. As shown in flowchart FA, the holder of interest performs the necessary operations to instruct the display of the holder-owned parent NFT list screen 25 ( FIG. 5 ) (step SA1). The holder terminal information processing unit 13 notifies the server information processing unit 10 of the instruction (step SA2). Even if not otherwise specified, when notifying the server information processing unit 10, the holder terminal information processing unit 13 and the user terminal information processing unit 18 also transmit information necessary for the server information processing unit 10 to execute its processing.

[0045] In response to the notification, the server information processing unit 10 collects information necessary to display the holder-owned parent NFT list screen 25 (step SB1). Specifically, the server information processing unit 10 can reference the contents of the metadata for any parent NFT and any child NFT to acquire information recorded in the metadata and information linked to the information recorded in the metadata. In particular, "information linked to information recorded in the metadata" includes image data (image data of the corresponding image) stored in the URI recorded in the metadata. Furthermore, the server information processing unit 10 can set item values ​​for specific metadata items for any parent NFT and any child NFT. Setting item values ​​for specific metadata items includes updating the item values ​​already set for the specific items. When accessing the metadata for a given NFT, the server information processing unit 10 uses the token URI associated with the token ID of the given NFT in the corresponding smart contract.

[0046] In step SB1, the server information processing unit 10 references the holder's external wallet connected to the service and identifies parent NFTs owned by the holder. Next, the server information processing unit 10 references metadata for each parent NFT owned by the holder and acquires parent NFT image data and last child NFT issuance date and time information. After processing step SB1, the server information processing unit 10 transmits parent NFT image data, last child NFT issuance date and time information, and other information required for displaying the holder-owned parent NFT list screen 25 for each parent NFT owned by the holder to the holder terminal information processing unit 13 (step SB2). Even if not otherwise specified, the server information processing unit 10 collects and transmits information required for processing when causing the holder terminal information processing unit 13 and the user terminal information processing unit 18 to display a screen or perform other processing.

[0047] The holder terminal information processing unit 13 displays a holder-owned parent NFT list screen 25 on the holder terminal display unit 15 based on the information received from the server information processing unit 10 (step SA3). FIG. 5 is a diagram showing an example of the holder-owned parent NFT list screen 25. As described above, when the owner of a parent NFT issues a child NFT based on the parent NFT, the owner cannot issue a new child NFT until the waiting period (72 hours in this embodiment) has elapsed since the parent NFT was issued. Based on this, hereinafter, a parent NFT during the waiting period will be referred to as a "waiting period NFT," and a parent NFT outside the waiting period will be referred to as a "non-waiting period NFT." A holder cannot issue a child NFT based on an NFT during the waiting period.

[0048] As shown in FIG. 5 , the holder-owned parent NFT list screen 25 displays a unit display area 26 for each parent NFT owned by the target holder. In the example of FIG. 5 , the target holder owns two parent NFTs, and the holder-owned parent NFT list screen 25 displays a unit display area 26 for each of the two parent NFTs. Note that the unit display area 26 is a selectable area. When a unit display area 26 is selected, the holder terminal information processing unit 13 cooperates with the server information processing unit 10 to display detailed information about the corresponding parent NFT (including various data recorded in the metadata). The same applies to the other unit display areas. The unit display area 26 on the left side of the figure is an area for NFTs outside the standby period. The unit display area 26 on the right side of the figure is an area for NFTs during the standby period. Hereinafter, the unit display area 26 for NFTs outside the standby period will be referred to as a non-standby period display area 26-1. On the other hand, the unit display area 26 for NFTs during the standby period will be referred to as a standby period display area 26-2. The holder terminal information processing unit 13 determines whether a parent NFT is in or outside the standby period using the following method. That is, if the time from the date and time indicated by the last child NFT issuance date and time information of the parent NFT to the current time is within 72 hours, the holder terminal information processing unit 13 determines that the parent NFT is in the standby period; otherwise, it determines that the parent NFT is outside the standby period. Note that if the last child NFT issuance date and time information is the initial value, the holder terminal information processing unit 13 determines that the parent NFT is outside the standby period. Alternatively, the server information processing unit 10 may determine whether the parent NFT is in or outside the standby period and notify the holder terminal information processing unit 13 of the determination result.

[0049] As shown in FIG. 5 , an image 27 of the corresponding parent NFT is displayed in the non-waiting period display area 26-1. Below the image 27, information 28 is displayed indicating that a child NFT can be issued based on the corresponding parent NFT. Below the information 28, a rare issuance request button 29 and a common issuance request button 30 are displayed. Both the rare issuance request button 29 and the common issuance request button 30 are buttons that request the issuance of a child NFT based on the corresponding parent NFT. Here, a child NFT has rarity as an attribute. In this embodiment, there are two types of rarity: rare and common. Rare is rarer than common. Rarity will be described later. The rare issuance request button 29 is a button that requests the issuance of a child NFT with rare rarity (hereinafter referred to as a "rare child NFT"). The common issuance request button 30 is a button that requests the issuance of a child NFT with common rarity (hereinafter referred to as a "common child NFT").

[0050] Corresponding to the rare issuance request button 29, information 31 indicating the fee required to issue a rare child NFT (hereinafter referred to as the "rare issuance fee") is displayed. Similarly, corresponding to the common issuance request button 30, information 32 indicating the fee required to issue a common child NFT (hereinafter referred to as the "common issuance fee") is displayed. The rare issuance fee is higher than the common issuance fee. In this embodiment, the values ​​of the rare issuance fee and the common issuance fee are both set by the operator. However, the server information processing unit 10 may be configured to dynamically and automatically set the value of each fee based on the supply and demand situation of the child NFT, the distribution situation, and other circumstances related to the child NFT. Note that in this embodiment, the two types of rarity, rare and common, are merely a simplified example. Rarity may also include types other than those illustrated in this embodiment, such as uncommon and super rare.

[0051] As shown in FIG. 5 , an image 27 of the corresponding parent NFT is displayed in the standby period display area 26-2. Below the image 27, information 34 indicating the time required from the current time until the standby period is completed is displayed. The holder terminal information processing unit 13 calculates the time in real time based on the relationship between the date and time indicated by the last child NFT issuance date and time information and the current date and time, and updates the information 34. By referring to the information 34, the holder of interest can accurately grasp how much time remains until a new child NFT can be issued based on the corresponding parent NFT.

[0052] Note that the processing of the server information processing unit 10 and the holder terminal information processing unit 13 when displaying the holder-owned parent NFT list screen 25 is not limited to the operations exemplified in this embodiment. The contents of this screen are merely an example. That is, the server information processing unit 10 simply collects the information necessary to display this screen and transmits it to the holder terminal information processing unit 13. When collecting the necessary information, the server information processing unit 10 uses information about external wallets connected to the service, information about the blockchain of blockchain network B (particularly information recorded in the storage of the parent NFT-compatible contract), a database related to parent NFTs, a database related to holders, and other data as needed. The same applies to the display of other screens.

[0053] As shown in flowchart FA, when a target holder wishes to issue a child NFT based on a parent NFT, the target holder selects the rare issuance request button 29 or the common issuance request button 30 in the non-waiting period display area 26-1 corresponding to the target parent NFT (step SA4). Hereinafter, the parent NFT corresponding to the selected button (i.e., the parent NFT that serves as the basis for issuing the child NFT) will be referred to as the "designated parent NFT." The amount required to issue the child NFT will be referred to as the "required issuance amount." In response to the button selection, the holder terminal information processing unit 13 notifies the server information processing unit 10 that the button was selected (step SA5). In response to this notification, the server information processing unit 10 determines whether a child NFT can be issued based on the designated parent NFT (step SB3). In step SB3, the server information processing unit 10 determines at least whether the target holder currently owns the designated parent NFT and whether the target holder's Ether balance is equal to or exceeds the required issuance amount. To determine whether the target holder currently owns the designated parent NFT, the server information processing unit 10 executes, for example, the following process. That is, the server information processing unit 10 queries the blockchain network B to determine whether the token ID of the designated parent NFT and the target holder's external holder address are associated in the parent NFT-compatible contract. The server information processing unit 10 then makes the above determination based on the results of the query. The query is made by executing an appropriate function of the parent NFT-compatible contract. Furthermore, to determine whether the target holder's Ether balance is equal to or greater than the required issuance amount, the server information processing unit 10 executes, for example, the following process. That is, the server information processing unit 10 executes the above determination by querying the blockchain network B about the Ether balance of the target holder's external address.

[0054] If a child NFT cannot be issued based on the designated parent NFT (step SB3: NO), the server information processing unit 10 executes error processing (step SB4). In this case, the issuance of the child NFT is not executed. As an example, the server information processing unit 10 controls the holder terminal information processing unit 13 to display information indicating that the child NFT cannot be issued on the holder terminal display unit 15, along with information indicating the reason. If a child NFT can be issued based on the designated parent NFT (step SB3: YES), the server information processing unit 10 executes child NFT issuance-related processing related to the issuance of the child NFT (step SB5). In step SB5, the server information processing unit 10 mints the child NFT, issues the child NFT, and designates the owner of the child NFT as the target holder. More specifically, the server information processing unit 10 sends a transaction to the blockchain network B instructing the child NFT-compatible contract to associate a new token ID with the target holder's external holder address. The transaction is addressed to the contract address of the child NFT-compatible contract and specifies a predetermined function with appropriate parameter values. The transaction is executed according to Ethereum standards, and the execution results are reflected in various states, resulting in a new child NFT being minted for the holder of interest, who then owns the child NFT.

[0055] Furthermore, the server information processing unit 10 sets values ​​for various items of metadata linked to the token URI of the child NFT. The metadata of the child NFT includes the following items: Token ID <item>, Name <item>, Creator <item>, Detailed Information <item>, Rarity <item>, Character Attributes <item>, Combat Power <item>, Status <item>, Stopped State Image <item>, Valid State Image <item>, Invalid State Image <item>, Pooled Flag <item>, On Sale Flag <item>, Pooled Flag <item>, Selling Price <item>, Valid State Transition Date and Time <item>. However, the items of the metadata of the child NFT are not limited to these items.

[0056] The server information processing unit 10 sets appropriate values ​​for the token ID (item), name (item), creator (item), and detailed information (item) of the child NFT's metadata. The server information processing unit 10 also sets a value for the rarity (item) in the following manner. That is, when the target holder requests the issuance of a rare child NFT, the server information processing unit 10 sets a rare value indicating rare to the rarity (item). On the other hand, when the target holder requests the issuance of a common child NFT, the server information processing unit 10 sets a common value indicating common to the rarity (item). Furthermore, a value indicating a character attribute is set in the character attribute (item). In this embodiment, the character attribute types include fire, water, and wood. However, the character attribute types exemplified in this embodiment are merely examples. Of course, other types may exist instead of or in addition to these types. The server information processing unit 10 randomly selects one of the fire, water, and wood attributes and sets a value indicating the selected character attribute to the character attribute (item). The server information processing unit 10 also sets a null value to the combat power <item>. A value indicating the status of the child NFT is set to the status <item>. As described above, the status of a child NFT transitions from a stopped state to a valid state to an invalid state when a specific event is triggered. The status of a child NFT when issued is a stopped state. The server information processing unit 10 sets a value indicating the stopped state to the status <item>.

[0057] The stopped-state image <item> is set with a URI for accessing image data of the stopped-state image of the corresponding child NFT (hereinafter referred to as "stopped-state image data"). The image of a stopped-state child NFT is an image that resembles an egg. In particular, the image of a stopped-state child NFT is an image that allows the character attributes to be clearly seen at a glance. Figure 6, which will be described later, shows an example of an image of a stopped-state child NFT. The server information processing unit 10 generates stopped-state image data using the following model. That is, the model inputs values ​​indicating character attributes, generates an image that resembles an egg with appropriate content, and outputs stopped-state image data in which the image is recorded. The server information processing unit 10 then sets a specified URI to the stopped-state image <item>. Furthermore, the server information processing unit 10 stores the generated stopped-state image data in the area indicated by the specified URI. The server information processing unit 10 also sets null values ​​to both the valid-state image <item> and the invalid-state image <item>. The server information processing unit 10 also sets the flag for the pooling flag <item> (hereinafter referred to as the "pooling flag"), the flag for the selling flag <item> (hereinafter referred to as the "selling flag"), and the flag for the via pool flag <item> (hereinafter referred to as the "via pool flag") to OFF. These flags will be described later. The server information processing unit 10 also sets null values ​​for the selling price <item> and the validity date and time information <item>.

[0058] Furthermore, in the child NFT issuance-related processing of step SB5, the server information processing unit 10 sends a predetermined transaction to the blockchain network B and transfers Ether equivalent to the required issuance amount from the holder external address to the operator external address. This processing may be performed in any manner as long as it ultimately results in a state in which the Ether balance in the holder external address is reduced by the required issuance amount and the Ether balance in the operator external address is increased by the required issuance amount. This is the same for all processing involving the transfer of Ether. Furthermore, in the child NFT issuance-related processing of step SB5, the server information processing unit 10 updates the value of the final child NFT issuance date and time information in the metadata of the designated parent NFT to a value indicating the current date and time.

[0059] After processing step SB5, the server information processing unit 10 transmits information necessary for displaying the issuance completion notification screen 35 to the holder terminal information processing unit 13, and notifies the holder terminal information processing unit 13 that the issuance of the child NFT to the selected holder has been completed (step SB6). This information includes at least image data of the issued child NFT in a stopped state. In response to this notification, the holder terminal information processing unit 13 displays the issuance completion notification screen 35 ( FIG. 6 ) on the holder terminal display unit 15. FIG. 6 is a diagram showing an example of the issuance completion notification screen 35. As shown in FIG. 6 , the issuance completion notification screen 35 displays an image of the stopped child NFT issued to the selected holder and information indicating that the issuance of the child NFT has been completed. Note that the issuance completion notification screen 35 may be configured to display an egg-laying effect when the image of the stopped child NFT is displayed.

[0060] As described above, the server information processing unit 10 has a function of issuing a child NFT (a second type of NFT) to a holder who owns a parent NFT (a first type of NFT) in response to a request from the holder. By issuing a child NFT, the holder can receive various benefits, as described below. For this reason, a holder who owns a parent NFT is motivated to issue a child NFT. It is expected that, motivated by this motivation, the holder will actively take action to issue a child NFT. This action has the effect of encouraging the use and circulation of tokens in the token economy. Therefore, this action will revitalize the token economy.

[0061] The server information processing unit 10 also has a function of prohibiting the issuance of child NFTs based on a parent NFT (a first-type NFT) for a waiting period (a fixed period) after issuing a child NFT in response to a request from a holder who owns the parent NFT. This configuration prevents an unlimited number of child NFTs from being issued, and maintains an appropriate supply of child NFTs.

[0062] <Scene in which a Holder Provides Child NFTs Using the Migration Platform PF> Next, the operation of the information processing system 1 in a scene in which a Holder provides child NFTs using the migration platform PF will be described. As described above, a Holder can selectively perform either the action of supplying a suspended child NFT to the Pool PL (the action of providing a child NFT using the Pool PL) or the action of selling a suspended child NFT on the Market MK (the action of providing a child NFT using the Market MK). Below, the operation of the system when the Pool PL is used and the operation of the system when the Market MK is used will be described in order.

[0063] A case in which a holder supplies a child NFT to the present pool PL First, a case in which a holder supplies a child NFT to the present pool PL will be described. This case corresponds to step F4 in FIG. 3. FIG. 7 is a flowchart showing the operation of the information processing system 1 in this case. Flowchart FC shows the information processing method by the holder terminal 3, and flow chart FD shows the information processing method by the information processing server 2. In FIG. 7, the target holder operates the holder terminal 3.

[0064] The noted holder launches the dedicated application AP on the holder terminal 3 and logs in to the account for the service. Furthermore, the noted holder connects his / her own holder external wallet to the service. As shown in flowchart FC, the noted holder performs the necessary operations to instruct the display of the holder-owned child NFT list screen 37 ( FIG. 8 ) (step SC1). The holder terminal information processing unit 13 notifies the server information processing unit 10 of the instruction (step SC2). In response to the notification, the server information processing unit 10 collects information necessary for displaying the holder-owned child NFT list screen 37 (step SD1). This information includes at least the stopped-state image data of each stopped child NFT owned by the noted holder. The server information processing unit 10 then transmits the collected information to the holder terminal information processing unit 13 (step SD2).

[0065] The holder terminal information processing unit 13 displays a holder-owned child NFT list screen 37 on the holder terminal display unit 15 based on the information received from the server information processing unit 10 (step SC3). FIG. 8 is a diagram showing an example of the holder-owned child NFT list screen 37. As shown in FIG. 8, the holder-owned child NFT list screen 37 displays a unit display area 38 for each child NFT owned by the target holder. In the example of FIG. 8, the target holder owns three child NFTs, and the holder-owned child NFT list screen 37 displays a unit display area 38 for each of the three child NFTs. When a unit display area 38 is selected, the holder terminal information processing unit 13 cooperates with the server information processing unit 10 to display detailed information about the corresponding child NFT (including various data recorded in the metadata). As shown in FIG. 8, an image 39 of the corresponding child NFT is displayed in the unit display area 38. Below the image 39, a pool selection button 40 and a market selection button 41 are displayed. The pool selection button 40 is a button that is selected when supplying the corresponding child NFT to the present pool PL. The market selection button 41 is a button that is selected when selling the corresponding child NFT in the present market MK.

[0066] The target holder selects the pool selection button 40 (step SC4). Hereinafter, the child NFT corresponding to the selected pool selection button 40 (i.e., the child NFT to be supplied to the pool PL) is referred to as the "pool specifier NFT." The holder terminal information processing unit 13 notifies the server information processing unit 10 that the pool selection button 40 has been selected (step SC5). In response to this notification, the server information processing unit 10 executes pool supply-related processing (step SD3). In step SD3, the server information processing unit 10 executes processing to transfer ownership of the pool specifier NFT from the target holder to the operator. Specifically, the server information processing unit 10 sends a predetermined transaction to the blockchain network B and changes the address associated with the token ID of the pool specifier NFT in the child NFT-compatible contract from the target holder's external holder address to the operator's external address. Furthermore, the server information processing unit 10 updates the pooling flag in the metadata of the pool specifier NFT from an OFF value to an ON value. The pooling flag is a flag that manages whether the corresponding child NFT remains in the current Pool PL. A child NFT remaining in the current Pool PL means that the child NFT has not been acquired by a user since it was supplied to the current Pool PL. The above process creates a state in which the target holder has supplied the child NFT to the current Pool PL.

[0067] After processing step SD3, the server information processing unit 10 notifies the holder terminal information processing unit 13 that the supply of the child NFT to the present pool PL has been completed (step SD4). As shown in flowchart FC, in response to the notification of step SD4, the holder terminal information processing unit 13 displays information indicating that the supply of the child NFT to the present pool PL has been completed on the holder terminal display unit 15 (step SC6).

[0068] As shown in the flowchart FD, after processing step SD4, the server information processing unit 10 starts the pool reward granting process (step SD5). The pool reward granting process is a process of continuously granting the GT (benefit) to the holder for the pool reward period (120 days), starting from the time the holder supplies the child NFT to the pool PL. In this embodiment, the server information processing unit 10 periodically (e.g., daily) grants a certain amount (e.g., 1,000 gt) of the GT to the holder. When granting the GT, the server information processing unit 10 sends a transaction to the blockchain network B to transfer a certain amount of the GT from the operator's external address to the holder's external address. However, the granting of the GT may be performed in any manner as long as the balance of the GT in the holder's external address ultimately increases sufficiently. By starting the pool reward granting process in step SD5, the target holder can continuously receive the GT during the pool reward period.

[0069] The benefits granted to holders who supply child NFTs to Pool PL are not limited to those exemplified in this embodiment. For example, the server information processing unit 10 may be configured to grant a predetermined amount of the present GT (or a value other than the present GT) to a holder once. The server information processing unit 10 may also be configured to change the quality or quantity of the benefits granted to a holder depending on the rarity of the child NFTs supplied to Pool PL. In this configuration, for example, when supplying rare child NFTs to Pool PL, the server information processing unit 10 grants a larger amount of the present GT compared to when supplying common child NFTs. The server information processing unit 10 may also grant the present GT to the holder's internal address (described below). The server information processing unit 10 may also grant other types of FTs available in the token economy instead of (or together with) the present GT. In this configuration, the other types of FTs do not need to be tradable on a public exchange. The server information processing unit 10 may also be configured to grant a reward other than an FT. In this configuration, the reward may be, for example, points that can be used in the service, points commonly used in point programs, a specified discount, an improvement in rank in various services, an NFT (which may be a child NFT), or an item that can be used in a specified service.

[0070] A Case in Which a Holder Sells a Child NFT on the Market MK of This Case Next, a case in which a holder sells a child NFT on the Market MK of this case will be described. This case corresponds to step F5 in FIG. 3. FIG. 9 is a flowchart showing the operation of the information processing system 1 in this case. Flowchart FE shows an information processing method by the holder terminal 3, and flow chart FF shows an information processing method by the information processing server 2. In FIG. 9, a holder of interest operates the holder terminal 3. The processing procedure of the flowchart in FIG. 9 is the same as the processing procedure of the flowchart in FIG. 7 until the holder-owned child NFT list screen 37 is displayed in step SC3. The processing after the holder-owned child NFT list screen 37 is displayed in step SC3 will be described below.

[0071] As shown in flowchart FE, the holder of interest selects the market selection button 41 (step SE1). Hereinafter, the child NFT corresponding to the selected market selection button 41 (i.e., the child NFT to be sold in the market MK) will be referred to as the "market designator NFT." In response to the selection of this button, the holder terminal information processing unit 13 pops up a sales price related screen 42 for inputting the sales price on the holder-owned child NFT list screen 37 (step SE2).

[0072] FIG. 10A is a diagram showing an example of a sales price-related screen 42 in its initial state. As shown in FIG. 10A, the sales price-related screen 42 includes a sales price input field 43 for inputting the sales price. When a user purchases a child NFT in the market MK, the user pays the set sales price in Ether. At that time, a certain percentage of the sales price (5% in this embodiment) is provided to the operator as a commission, and the remainder is provided to the seller's holder as total revenue. Below the sales price input field 43 on the sales price-related screen 42, a display area 44 for displaying the commission and total revenue is provided. For example, assume that "0.1 (Ether)" is entered as the sales price in the sales price input field 43 of the sales price-related screen 42 in its initial state shown in FIG. 10A. Then, the holder terminal information processing unit 13 displays "0.005 (Ether)" as the commission and "0.095 (Ether)" as the total revenue, as shown in FIG. 10B. Below the display area 44, a Confirm button 45 for confirming the input is provided. The noted user enters the selling price when selling the market designator NFT in the selling price input field 43, refers to the fees and total revenue, and then selects the Confirm button 45 (step SE3). As described above, the noted holder sets the selling price using the provided user interface. Note that the selling price-related screen 42 may be configured to display the market price of the market designator NFT (the approximate amount at which a sale tends to be completed).

[0073] Upon detecting that the Confirm button 45 has been selected, the holder terminal information processing unit 13 notifies the server information processing unit 10 of this (step SE4). In response to this notification, the server information processing unit 10 executes child NFT sales-related processing (step SF1). Specifically, the server information processing unit 10 changes the on-sale flag in the metadata of the market designator NFT to an ON value and sets information indicating the sales price set by the target user in the sales price <item>. As a result, the market designator NFT is managed as a child NFT on sale in the current market MK. While details are omitted, the holder can cancel the sale in the current market MK at any time. When the sale is canceled, the server information processing unit 10 changes the on-sale flag in the metadata of the corresponding child NFT to an OFF value and sets the sales price <item> to a null value. In this embodiment, the server information processing unit 10 manages child NFTs sold in the current market MK based on information recorded in the metadata. However, the management method is not limited to the example method. For example, the server information processing unit 10 may be configured to use a database to manage child NFTs sold in the market MK.

[0074] After processing step SF1, the server information processing unit 10 notifies the holder terminal information processing unit 13 that sales of the market specifier NFT have begun (step SF2). In response to this notification, the holder terminal information processing unit 13 displays information that sales of the market specifier NFT have begun on the holder terminal display unit 15 (step SE5).

[0075] <Scene in which a user acquires a child NFT using the migration platform PF> Next, the operation of the information processing system 1 in a scene in which a user acquires a child NFT using the migration platform PF will be described. As described above, with regard to the acquisition of child NFTs, a user can acquire child NFTs using the Pool PL. In addition, a user can purchase child NFTs at the Market MK. Below, the operation of the system when the Pool PL is used and the operation of the system when the Market MK is used will be described in order.

[0076] A case in which a user acquires a child NFT using the present Pool PL First, we will explain the case in which a user acquires a child NFT using the present Pool PL. This case corresponds to step F6 in FIG. 3. FIG. 11 is a flowchart showing the operation of the information processing system 1 in this case. Flowchart FG shows the information processing method by the user terminal 4, and flow chart FH shows the information processing method by the information processing server 2. In FIG. 11, the user of interest operates the user terminal 4. In the following explanation, the event in which a user acquires a child NFT from the present Pool PL is referred to as the "present Pool usage event."

[0077] Here, the server information processing unit 10 has a function of deriving an evaluation value for each user at a fixed timing each day (e.g., 12:00 AM). The server information processing unit 10 manages the most recent evaluation value for each user in a predetermined database. The evaluation value is an index indicating the user's degree of contribution to the basic service SV. In this embodiment, the evaluation value ranges from 0 pp to 100 pp (pp is a unit of convenience), with a higher value indicating a higher degree of contribution. The server information processing unit 10 derives an evaluation value for each user using the following method. That is, the server information processing unit 10 acquires the user action log for the user stored in the server storage unit 12. The user action log records daily login times for at least the past 30 days. Daily login time is the total login time for basic services in one day. The server information processing unit 10 then derives the evaluation value using the following model. That is, the model inputs normalized values ​​of the user's daily login times for the past 30 days as parameters, derives, and outputs an evaluation value. In this model, the normalized daily login times are weighted appropriately so that the closer a daily login time is to the current time, the stronger its influence on the derived rating value. Therefore, the longer a user is logged in to a basic service in a time period closer to the current time, the more effectively the rating value increases.

[0078] The method for deriving the evaluation value shown in this embodiment is merely a simplified example. In other words, any method may be used to derive the evaluation value as long as it ultimately derives an evaluation value that can be considered an index of the contribution of the user's behavior to the service. For example, the server information processing unit 10 may be configured to derive the evaluation value by taking into account the user's specific behavior within the service. In this embodiment, the specific behavior is determined, for example, based on the number of messages posted or the number of groups created. Alternatively, the server information processing unit 10 may be configured to derive the evaluation value by taking into account whether the user is behaving "good" within the service. In this embodiment, whether the behavior is good is determined, for example, based on the appropriateness of the content of the message. Alternatively, for example, the appropriateness of the manner in which the user communicates with others within the group to which the user belongs is determined. The appropriateness of the content of the message and the appropriateness of the manner in which the user communicates are determined, for example, using AI technology.

[0079] The server information processing unit 10 has a function of granting pool use tickets (electronic tickets) to users. A user who possesses a pool use ticket can participate in the pool use event once by consuming one of the tickets. In other words, the pool use ticket functions as the right to acquire a child NFT in the pool PL. The server information processing unit 10 grants the pool use ticket to a user in the following manner. That is, the server information processing unit 10 executes the following process at a predetermined timing when a child NFT remains in the pool PL. That is, the server information processing unit 10 randomly selects one user from a group of users whose evaluation value is equal to or greater than a certain value. The server information processing unit 10 then grants the pool use ticket to the selected user. Users whose evaluation value is equal to or greater than a certain value are equivalent to users who have made a high contribution to the basic service (service).

[0080] As described above, the server information processing unit 10 has a function that gives priority to users who have made a high contribution to the basic services (services) provided in the token economy in granting them the right to acquire child NFTs in the Pool PL. This configuration provides the following advantages. That is, by acquiring child NFTs, users can receive various benefits, as described below. Based on this, it is expected that users will actively take actions that contribute to the basic services so that they have a chance of obtaining pool use tickets. Such actions have the effect of revitalizing the basic services, which in turn revitalizes the token economy.

[0081] The method of granting a pool use ticket to a user is not limited to the above-described method. For example, the group of users from which the user to be granted the ticket may be selected may be a set of all users. The group of users may also be a set of users who have logged in to the service within a certain period of time prior to the present. When selecting a user, the server information processing unit 10 may also consider whether the user has previously owned a child NFT or whether the user currently owns a child NFT. The pool use ticket may also be configured to have an expiration date. In this case, if a user who has received a pool use ticket does not consume the pool use ticket by the expiration date, the server information processing unit 10 will invalidate the user's pool use ticket. The server information processing unit 10 uses a database related to pool use tickets to manage the owner of the pool use ticket and other information necessary for managing the pool use ticket.

[0082] In addition, participants who register an account with the Service are assigned an internal address to be used with the Service, as well as an internal wallet associated with the internal address. An internal wallet is a wallet that can be used with the Service, and information about the internal wallet is basically managed in the database of the information processing server 2. Therefore, the internal wallet cannot be connected to a public marketplace, public exchange, or other publicly available services. The internal wallet can manage at least the parent NFT, child NFT, the GT, and the UT. The user's internal address is referred to as the "user internal address," the user's internal wallet is referred to as the "user internal wallet," the operator's internal address is referred to as the "operator internal address," and the operator's internal wallet is referred to as the "operator internal wallet."

[0083] In the following description using FIG. 11 , it is assumed that the target user possesses a pool use ticket. Referring to FIG. 11 , the target user launches the dedicated application AP on the user terminal 4, enters login information, and logs in to the account for the service. As shown in flowchart FG, the target user performs the necessary operations to instruct the server information processing unit 10 to consume the pool use ticket (step SG1). The user terminal information processing unit 18 notifies the server information processing unit 10 of the instruction (step SG2). In response to the notification, the server information processing unit 10 randomly selects one child NFT from among the child NFTs remaining in the pool PL (step SH1). Hereinafter, the selected child NFT is referred to as the "selected child NFT." The server information processing unit 10 identifies the child NFTs remaining in the pool PL based on the in-pool flag.

[0084] Next, the server information processing unit 10 executes a process of transferring the selected child NFT to the user's internal wallet of the noted user (step SH2). More specifically, the server storage unit 12 stores an internal child NFT management database 47. The internal child NFT management database 47 is a database that manages child NFTs. Storage of an NFT in an internal wallet means that the corresponding internal address and the identification information of the NFT are associated and managed, and the NFT is managed by the internal wallet. The internal child NFT management database 47 stores, for each child NFT stored in the internal wallet, the identification information of the child NFT and the internal address that owns the child NFT, in association with each other. Therefore, by referencing the internal child NFT management database 47, the internal address that owns the child NFT can be identified. In step SH2, the server information processing unit 10 updates the internal child NFT management database 47, associating the identification information of the selected child NFT with the user's internal address of the noted user. Furthermore, the server information processing unit 10 changes the pooling flag in the metadata of the selected child NFT to an OFF value and changes the via-pool flag to an ON value. The via-pool flag is a flag that manages whether the child NFT acquired by the user has passed through the Pool PL. As a result, one of the child NFTs remaining in the Pool PL is transferred to the user's internal wallet, and the user in question has acquired the child NFT in the service.

[0085] After processing step SH2, the server information processing unit 10 notifies the user terminal information processing unit 18 that the transfer of the child NFT from the present pool PL to the user of interest has been completed (step SH3). In response to this notification, the user terminal information processing unit 18 displays information indicating that the transfer has been completed on the user terminal display unit 20 (step SG3). Here, when a user acquires a child NFT using the present pool PL, the user does not need to prepare an external wallet. Obtaining an external wallet requires a certain level of knowledge, and the process of acquiring one can be somewhat complicated. In light of this, this embodiment provides users with the opportunity to acquire a child NFT without preparing an external wallet, providing high user convenience.

[0086] A case in which a user acquires a child NFT using the Market MK in question will now be described. FIG. 12 is a flowchart illustrating the operation of the information processing system 1 in this case. Flowchart FI illustrates an information processing method by the user terminal 4, and flow chart FJ illustrates an information processing method by the information processing server 2. In FIG. 12, the user of interest operates the user terminal 4. Here, when purchasing a child NFT using the Market MK in question, the user needs to possess an external wallet. Hereinafter, the user's external wallet will be referred to as a "user external wallet," and the address of the external account managed in the user external wallet will be referred to as a "user external address." In the description of FIG. 12, the user of interest possesses a user external wallet.

[0087] The noted user launches the dedicated app AP on the user terminal 4, enters login information, and logs in to the account for the service. Furthermore, the noted user connects his or her external user wallet to the service. As shown in flowchart FI, the noted user performs the necessary operations to instruct the display of the seller NFT list screen 48 ( FIG. 13 ) (step SI1). The user terminal information processing unit 18 notifies the server information processing unit 10 of the instruction (step SI2). In response to the notification, the server information processing unit 10 transmits information necessary for displaying the seller NFT list screen 48 to the user terminal information processing unit 18 (step SJ1). This information includes, for each child NFT on sale in the market MK, a value indicating rarity, a value indicating character attributes, stopped-state image data, and sales price information. The server information processing unit 10 identifies the child NFTs on sale based on the on-sale flag. The server information processing unit 10 also collects various information based on metadata.

[0088] The user terminal information processing unit 18 displays a seller NFT list screen 48 on the user terminal display unit 20 based on the received information (step SI3). FIG. 13 is a diagram showing an example of the seller NFT list screen 48. As shown in FIG. 13, the seller NFT list screen 48 displays a unit display area 49 for each child NFT currently on sale. When the unit display area 49 is selected, the user terminal information processing unit 18 cooperates with the server information processing unit 10 to display detailed information about the corresponding child NFT (including various data recorded in the metadata). The unit display area 49 displays an image of the corresponding child NFT, information indicating its rarity, information indicating its selling price, and a purchase button 46. The user of interest selects the purchase button 46 corresponding to the child NFT they wish to purchase (step SI4). Hereinafter, the child NFT corresponding to the selected purchase button 46 will be referred to as the "purchased child NFT." The user terminal information processing unit 18 notifies the server information processing unit 10 that the purchase button 46 has been selected (step SI5).

[0089] In response to the notification of step SI5, the server information processing unit 10 determines whether the purchased child NFT can be transferred from the seller's holder to the target user (step SJ2). In step SJ2, the server information processing unit 10 determines at least whether the target user's Ether balance is equal to or greater than the sales price and whether the seller's holder currently owns the purchased child NFT. If the purchased child NFT cannot be transferred (step SJ2: NO), the server information processing unit 10 executes the corresponding error processing (step SJ3). In this case, the child NFT is not transferred. As an example, the server information processing unit 10 controls the user terminal information processing unit 18 to display information on the user terminal display unit 20 indicating that the child NFT cannot be purchased, along with information indicating the reason for the failure.

[0090] On the other hand, if the transfer of the purchased child NFT is possible (step SJ2: YES), the server information processing unit 10 executes child NFT sale-related processing (step SJ4). Specifically, the server information processing unit 10 sends a predetermined transaction to the blockchain network B and changes the address associated with the token ID of the purchased child NFT in the child NFT-compatible contract to the user external address of the noted user. Furthermore, the server information processing unit 10 changes the on-sale flag in the metadata of the purchased child NFT to an off value. Furthermore, the server information processing unit 10 transfers Ether equivalent to the total revenue derived from the sales price from the user external address of the noted user to the holder external address of the seller holder. Furthermore, the server information processing unit 10 transfers Ether equivalent to the commission derived from the sales price from the user external address of the noted user to the operator external address. This completes the purchase of the child NFT by the noted user, and the noted user has acquired the child NFT.

[0091] After processing step SJ4, the server information processing unit 10 notifies the user terminal information processing unit 18 that the target user has completed the purchase of the child NFT (step SJ5). In response to this notification, the user terminal information processing unit 18 displays information indicating that the purchase of the child NFT has been completed on the user terminal display unit 20 (step SI6).

[0092] As described above, the server information processing unit 10 has a function of providing a transfer platform PF (platform) for transferring child NFTs (second-type NFTs) from holders to users. Holders can receive various benefits by transferring child NFTs to users using the transfer platform PF. Users can also receive various benefits by acquiring child NFTs using the transfer platform PF. Therefore, holders are expected to actively take actions such as owning parent NFTs, issuing child NFTs, and transferring the child NFTs to users using the platform. Such actions have the effect of encouraging the use or circulation of tokens in the token economy, thereby revitalizing the token economy.

[0093] The server information processing unit 10 also has the functionality to provide two platforms: the Market MK (first platform), which enables transactions of child NFTs between holders and users, with holders acting as sellers and users acting as buyers; and the Pool PL (second platform), through which holders provide child NFTs free of charge and users acquire the child NFTs provided by the holders free of charge. This configuration provides the following benefits: Holders can use the Market MK to sell child NFTs at a desired selling price. If the total revenue based on the selling price exceeds the necessary issuance costs, the holder can obtain economic benefits. Furthermore, the more users active in the token economy, the higher the chance of child NFTs being purchased at a higher and more stable rate. Therefore, holders are expected to take actions that increase the number of users active in the token economy. If such actions increase the number of users, the token economy will be revitalized. However, child NFTs sold by holders on the Market MK are not necessarily sold at the desired selling price. In this embodiment, the server information processing unit 10 provides the Pool PL in addition to the Market MK. Therefore, even if a holder cannot sell a child NFT at the desired selling price, or even if the holder assumes that the child NFT will not be sold, the holder can provide the child NFT using the Pool PL and receive benefits. In other words, according to this embodiment, the holder can supply the child NFT they own to the Pool PL and receive benefits under any circumstances. Therefore, the holder can issue child NFTs without taking the risk of unsold child NFTs accumulating.

[0094] Here, the server information processing unit 10 has a function of granting a benefit to a holder who provides a child NFT using the Pool PL. Specifically, the benefit granted in this embodiment is the GT. The GT is an FT that can be used in the Token Ecosystem and traded on a public exchange. Because of this configuration, a holder can receive benefits for providing a child NFT even if the holder provides the child NFT using the Pool PL rather than the Market MK. In particular, since the GT is tradable on a public exchange, a holder may be able to enjoy economic benefits by trading the received GT on a public exchange and exchanging it for other value. The GT is also a governance token that is granted the right to exercise influence over the operation of the Token Ecosystem. Therefore, a holder can maintain ownership of the GT and exert influence over the operation of the Token Ecosystem.

[0095] Furthermore, users can acquire desired child NFTs using the Market MK, taking into consideration rarity, character attributes, and other child NFT-related factors, provided they pay a price equivalent to the sales price. Users can also acquire child NFTs free of charge using the Pool PL, provided they obtain a pool usage ticket. As described above, when granting the UT to a user who wins the Game, the server information processing unit 10 executes the following process. That is, if a user acquires a child NFT using the Market MK, the server information processing unit 10 grants a larger amount of the UT than if the user acquires the child NFT using the Pool PL, assuming other conditions are the same. Therefore, even if a user purchases a child NFT through the Market MK, the user can receive a sufficient benefit commensurate with the price paid.

[0096] In this embodiment, the server information processing unit 10 provides the Pool PL and the Market MK. In this regard, the server information processing unit 10 may be configured to provide a platform for either the Pool PL or the Market MK. The sales method for child NFTs in the Market MK may be an auction method. The server information processing unit 10 may be configured to provide a platform of a different type for the Pool PL and the Market MK.

[0097] <Scene in which a user transitions a child NFT from a suspended state to an active state> Next, the operation of the information processing system 1 in a scenario in which a user transitions a child NFT they own from a suspended state to an active state will be described. Hereinafter, transitioning to an active state may be referred to as "activating." This scenario corresponds to step F8 in FIG. 3. When a user acquires a child NFT using the Market MK, the child NFT is stored in the user's external wallet. When a user activates a child NFT, the child NFT must be stored in the user's internal wallet. Based on this, when a user acquires a child NFT using the Market MK, the user transfers the child NFT from the user's external wallet to the user's internal wallet before activating the child NFT. The user instructs this transfer using a specific user interface provided by the dedicated app AP. Upon receiving this instruction, the server information processing unit 10 sends a transaction to the blockchain network B and changes the owner of the corresponding child NFT to the operator. Furthermore, the server information processing unit 10 updates the internal child NFT management database 47, and associates the identification information of the child NFT with the user's internal address. This completes the migration of the child NFT to the user's internal wallet.

[0098] Fig. 14 is a flowchart showing the operation of the information processing system 1 in this scene. Flowchart FK shows an information processing method by the user terminal 4, and flowchart FL shows an information processing method by the information processing server 2. In Fig. 14, a user of interest operates the user terminal 4. Also in Fig. 14, one or more child NFTs in a suspended state are stored in the user internal wallet of the user of interest.

[0099] The noted user launches the dedicated app AP on the user terminal 4, enters login information, and logs in to the account for the service. As shown in flowchart FK, the noted user performs the necessary operations to instruct the display of the user-owned child NFT list screen 50 ( FIG. 15 ) (step SK1). The holder terminal information processing unit 13 notifies the server information processing unit 10 of the instruction (step SK2). In response to the notification, the server information processing unit 10 references the internal child NFT management database 47 and transmits information necessary for displaying the user-owned child NFT list screen 50 to the user terminal information processing unit 18 (step SL1). This information includes information necessary for displaying the unit display area 51 for each child NFT stored in the noted user's internal wallet.

[0100] As shown in flowchart FK, the user terminal information processing unit 18 displays a user-owned child NFT list screen 50 on the user terminal display unit 20 based on the received information (step SK3). FIG. 15 is a diagram illustrating an example of the user-owned child NFT list screen 50. As shown in FIG. 15, the user-owned child NFT list screen 50 displays a unit display area 51 for each child NFT stored in the user's internal wallet of the focused user. When a unit display area 51 is selected, the user terminal information processing unit 18 cooperates with the server information processing unit 10 to display detailed information about the corresponding child NFT (including various data recorded in the metadata). As described above, a child NFT can have one of the following statuses: suspended, enabled, or disabled. The user-owned child NFT list screen 50 displays a unit display area 51 for each child NFT stored in the user's internal wallet of the focused user, regardless of its status. In FIG. 15, unit display areas 51-1 and 51-2 are areas relating to child NFTs in a stopped state, unit display area 51-3 is an area relating to child NFTs in a valid state, and unit display area 51-4 is an area relating to child NFTs in an invalid state.

[0101] As shown in FIG. 15, the unit display areas 51-1 and 51-2 for the stopped state display an image 52 of a child NFT based on the stopped state image data. Below the image 52, an activation button 53 is operated to activate a stopped child NFT. The user of interest selects the activation button 53 corresponding to the child NFT to be activated (step SK4). Hereinafter, the child NFT corresponding to the selected activation button 53 is referred to as the "activated child NFT." The user terminal information processing unit 18 notifies the server information processing unit 10 that the activation button 53 was selected (step SK5). In response to this notification, the server information processing unit 10 executes activation-related processing (step SL2). More specifically, the server information processing unit 10 executes the following processing with respect to the metadata of the activated child NFT. That is, the server information processing unit 10 determines a combat power value and sets the determined combat power value in the combat power <item>. If the rarity is rare, the server information processing unit 10 randomly determines the combat power value within the range of 20 pt to 50 pt, and if the rarity is common, the server information processing unit 10 randomly determines the combat power value within the range of 10 pt to 40 pt.

[0102] Furthermore, the server information processing unit 10 changes the value of the status <item> from a value indicating a stopped state to a value indicating a valid state. Furthermore, the server information processing unit 10 generates image data of an image of the valid state of the validating child NFT (hereinafter referred to as "validating state image data") using a predetermined model. The image of the validating child NFT is an image of a monster. The server information processing unit 10 then sets a predetermined URI to the validating state image <item>. Furthermore, the server information processing unit 10 stores the generated validating state image data in the area indicated by the predetermined URI. The server information processing unit 10 also stores validating state transition date and time information indicating the current date and time in the validating state transition date and time <item>. In other words, the validating state transition date and time information is information indicating the date and time when the corresponding child NFT transitioned to the valid state. The above processing completes the transition of the validating child NFT to the valid state. After processing step SL2, the server information processing unit 10 notifies the user terminal information processing unit 18 that the activation has been completed (step SL3). In response to the notification, the user terminal information processing unit 18 displays information indicating that the activation has been completed on the user terminal display unit 20 .

[0103] <Scene in which a child NFT in a valid state transitions to an invalid state> As described above, a child NFT automatically transitions to an invalid state at a predetermined timing after the validity period (90 days) has elapsed since the transition to the valid state. Focusing on one child NFT, the operation of the information processing system 1 in a scene in which a child NFT in a valid state transitions to an invalid state will be described below. This scene corresponds to step F9 in FIG. 3. The child NFT of interest is referred to as the "child NFT of interest."

[0104] When a target child NFT transitions from a disabled state to a valid state, the server information processing unit 10 monitors whether 90 days have passed, starting from 0:00 AM on the day following the day when the valid state was entered. The server information processing unit 10 may also be configured to use a different timing derived from the timing when the valid state was entered as the starting point. If 90 days have passed, the server information processing unit 10 transitions the target child NFT to an invalid state with a probability of 3.3% (this is just an example). In other words, there is a possibility that the target child NFT will not transition to an invalid state at this stage and will remain valid. When transitioning the target child NFT to an invalid state, the server information processing unit 10 performs the following processing on the metadata corresponding to the target child NFT. That is, the server information processing unit 10 generates invalid state image data representing an image of the invalid child NFT using a specified model. The server information processing unit 10 then sets a specified URI for the invalid state image <item> and stores the invalid state image data in the specified URI. The server information processing unit 10 then changes the value of the status <item> to a value indicating the invalid state. If the target child NFT does not transition to the invalid state after 90 days have passed, the server information processing unit 10 transitions the target child NFT to the invalid state with a 3.3% probability after one more day has passed (i.e., 91 days after transitioning to the valid state). In this way, the server information processing unit 10 executes the process of transitioning to the invalid state with a 3.3% probability every day until the transition to the invalid state actually occurs. By performing the above process, the target child NFT transitions to the invalid state at some point after 90 days have passed since it became valid. In other words, the server information processing unit 10 transitions the child NFT from the valid state to the invalid state when a certain period (validity period + α) has passed since the child NFT was set to the valid state.

[0105] <Scene in which a user acquires a game ticket> Next, the operation of the information processing system 1 in a scene in which a user acquires a game ticket will be described. This scene corresponds to steps F10 and F11 in Fig. 3. Fig. 16 is a flowchart showing the operation of the information processing system 1 in this scene. Flowchart FM shows an information processing method by the information processing server 2. The information processing server 2 executes the process shown in the flowchart in Fig. 16 for each user, triggered by a fixed time each day.

[0106] The server information processing unit 10 refers to the internal child NFT management database 47 and determines whether the user owns a valid child NFT (step SM1). If the user does not own a valid child NFT (step SM1: NO), the server information processing unit 10 terminates the process. In this case, a game ticket is not distributed to the user. In this way, only users who own valid child NFTs are eligible to receive a game ticket. If the user owns a valid child NFT (step SM1: YES), the server information processing unit 10 acquires the user's evaluation value (step SM2). As described above, an evaluation value is periodically derived for each user and managed in a predetermined database. Next, the server information processing unit 10 determines whether the evaluation value is equal to or greater than a predetermined threshold (step SM3). If the evaluation value is not equal to or greater than the threshold (step SM3: NO), the server information processing unit 10 terminates the process. In this case, a game ticket is not distributed to the user. On the other hand, if the evaluation value is equal to or greater than the threshold (step SM3: YES), the server information processing unit 10 distributes a game ticket to the user. The server information processing unit 10 uses a database related to game tickets to manage information necessary for managing game ticket owners and other pool use tickets. Game tickets correspond to benefits given to users. As will be described later, the UT given to a user after playing the game using a game ticket also corresponds to a "benefit."

[0107] As described above, the server information processing unit 10 has the function of validating a child NFT for a certain period of time after the user acquires the child NFT, and the function of granting a reward to the user in accordance with the user's actions in the token economy while the user owns the valid child NFT. More specifically, the server information processing unit 10 has the function of validating a child NFT in response to a request from the user who owns the child NFT, the function of transitioning the child NFT from a valid state to an invalid state after a certain period of time has elapsed since the child NFT was validated, and the function of granting a reward to the user in accordance with the user's actions in the token economy while the user owns the valid child NFT. This configuration achieves the following effects. That is, the valid state of the child NFT does not last forever, but only for a certain period of time. Therefore, the user is motivated to actively participate in the basic service SV and acquire game tickets while the child NFT is valid and the right to receive game tickets is valid. Then, when the user acts with this motivation, the basic service SV is activated, and ultimately the token economy is activated. In this embodiment, the server information processing unit 10 is configured to activate the child NFT in response to a user request. In this regard, the server information processing unit 10 may be configured to activate the child NFT using a different event as a trigger.

[0108] The server information processing unit 10 also has a function of granting rewards to users who own child NFTs based on their actions in the basic service SV provided in the token economy. More specifically, the server information processing unit 10 has a function of deriving an evaluation value indicating the user's contribution to the basic service SV based on the user's actions in the basic service SV, and granting rewards when the evaluation value is equal to or greater than a certain level. This configuration is expected to encourage users to proactively take actions to receive rewards. The user's actions will activate the basic service SV, which in turn activates the token economy. Note that the user's actions that are eligible for rewards are not limited. In particular, the server information processing unit 10 may be configured to grant rewards to users based on actions unrelated to their contribution to the basic service SV. In this embodiment, the server information processing unit 10 is configured to use an evaluation value to determine the user's contribution to the service. In this regard, the server information processing unit 10 may be configured to determine the contribution level using a method other than the evaluation value. For example, the server information processing unit 10 may be configured to determine the degree of contribution by the same department based on whether the user has performed a predetermined action that contributes to the service. The predetermined action may be, for example, answering a questionnaire or viewing designated content. The server information processing unit 10 may also be configured to grant a game ticket triggered by an event other than the condition that the evaluation value is equal to or greater than a threshold.

[0109] <Scene in which a user plays the game> Next, the operation of the information processing system 1 in a scene in which a user plays the game will be described. This scene corresponds to steps F12 and F13 in FIG. 3. FIG. 17 is a flowchart showing an example of the operation of the information processing system 1 in this scene. Flowchart FN shows an information processing method by the user terminal 4, and flow chart FO shows an information processing method by the information processing server 2. In FIG. 17, a user of interest operates the user terminal 4. It is assumed that the user of interest holds a game ticket.

[0110] The noted user launches the dedicated application AP on the user terminal 4 and enters login information to prepare for the Game. The noted user logs in to the account for the Service. Next, the noted user prepares for the Game using a predetermined user interface provided by the user terminal information processing unit 18. One step in preparing for the Game is forming a party. A party is a combination of one to three active child NFTs to be used in the Game. The noted user uses the predetermined user interface to select one to three active child NFTs from those he or she owns and form a party. The predetermined user interface displays a list of information about the active child NFTs owned by the noted user. The user interface is also configured to allow the user to select any of the listed child NFTs as a child NFT to be included in the party.

[0111] Referring to FIG. 17, the user of interest instructs the game to begin (step SN1). The user terminal information processing unit 18 notifies the server information processing unit 10 of the instruction (step SN2). The server information processing unit 10 references the internal child NFT management database 47 and other data related to the game, and transmits information necessary for displaying the game screen 55 (FIG. 18) and progressing through the game to the user terminal information processing unit 18 (step SN3). The information transmitted by the server information processing unit 10 includes, for child NFTs belonging to the party, valid state image data, a fighting power value, and a value indicating character attributes. For "enemies," the information transmitted by the server information processing unit 10 also includes, for "enemies," image data of the enemy, a fighting power value, and a value indicating character attributes. The server information processing unit 10 generates enemy image data or selects it from prepared data. The server information processing unit 10 also randomly determines the enemy's fighting power and character attributes according to certain rules.

[0112] FIG. 18 is a diagram showing an example of a scene on the game screen 55. As shown in FIG. 18, the game screen 55 displays an image of the active state, information indicating the fighting power, and information indicating the character attributes for each child NFT belonging to the party. The game screen 55 also displays an image, fighting power, and character attributes for the enemy. In the game, a battle takes place between the party and the enemy, and victory or defeat is determined. More specifically, the child NFTs belonging to the party fight the enemy one by one in turn. If a child NFT wins a battle against the enemy, the noted user is declared victorious, and the game ends at that point. On the other hand, if all child NFTs belonging to the party are defeated by the enemy, the noted user is declared defeated, and the game ends. With respect to a battle between a child NFT and an enemy, the user terminal information processing unit 18 comprehensively reflects the fighting power and character attributes of the child NFT and the fighting power and character attributes of the enemy, and also reflects random elements, to determine the outcome of the battle. That is, the server information processing unit 10 determines the winner of the battle in a manner such that the greater the combat power of the child NFT in relation to the enemy's combat power, the higher the probability that the user will win, and the more compatible the character attribute of the child NFT is with the character attribute of the enemy, the higher the probability that the user will win. In this embodiment, it is defined that the water attribute is compatible with the fire attribute, the fire attribute is compatible with the wood attribute, and the wood attribute is compatible with the water attribute. Note that the server information processing unit 10 may be configured to determine the outcome of the battle. The user terminal information processing unit 18 displays a video on the game screen 55, including a depiction of a battle between a child NFT included in the party and an enemy.

[0113] The content of the Game shown in this embodiment is a very simplified example. The content of the Game is not limited to the illustrated content. For example, other parameters may be present instead of or in addition to fighting power or character attributes. The content of the Game may also be such that victory or defeat is determined by reflecting these other parameters. These other parameters may be, for example, stamina, defensive power, or speed. Furthermore, for example, the Game may be configured such that user operations are accepted while the Game is being played, and these operations affect victory or defeat. In other words, the items exemplified regarding parameters in this embodiment are merely examples, and the types of parameters are not limited to the illustrated content. Furthermore, when focusing on a single parameter, the range, upper and lower limits, and other parameter-related elements of that parameter are not limited to the illustrated content. For example, in cases where fighting power is used in the Game (although, of course, it is not necessary to use fighting power), the range, upper and lower limits, timing of change, factors that cause change, etc. of fighting power are not limited to the illustrated content.

[0114] After the game ends, the user terminal information processing unit 18 notifies the server information processing unit 10 of the results of the win or loss (step SN4). In response to this notification, the server information processing unit 10 derives the amount of UT to be granted to the noted user as a bonus (step SO2). Hereinafter, this amount of UT will be referred to as the "amount of granted tokens." More specifically, the server information processing unit 10 derives an individual amount for each child NFT belonging to the party using the following calculation formula S1. Calculation formula S1: Individual amount = Reference amount × Win / Loss coefficient × Pool-related coefficient. Here, the reference amount is a predetermined fixed amount. The win / loss coefficient is a coefficient for reflecting the win or loss of the game in the individual amount. The win / loss coefficient is set so that the individual amount is larger when the player wins the game than when the player loses. The win / loss coefficient is "1.0" when the player wins the game and "0.5" when the player loses. The pool-related coefficient is a coefficient for reflecting in the individual amount whether the child NFT was acquired using the pool PL. The pool-related coefficient is set so that the individual amount is larger when the Pool PL is not being used than when it is being used. The pool-related coefficient is "1.0" when the Pool PL is not being used, and "0.1" when it is being used. For example, suppose one child NFT was acquired using the Pool PL. Also, suppose the reference amount is "1000 UT" and the game is won. In this case, the individual amount of the one child NFT is "100 UT" (1000 x 1.0 x 0.1 = 100). After deriving the individual amounts for each child NFT belonging to the party, the server information processing unit 10 derives the amount of granted tokens by adding up each of the individual amounts.

[0115] The method for deriving the amount of granted tokens is not limited to the method exemplified in this embodiment. That is, the amount of granted tokens may be derived by a method that satisfies the following conditions: - Other conditions being equal, winning the game will result in a larger amount of granted tokens. - For a given child NFT, if that child NFT is acquired using the market MK, the amount of granted tokens will be larger than if that child NFT is acquired using the pool PL. Furthermore, the server information processing unit 10 may be configured to reflect other factors when deriving the amount of granted tokens. The other factors may be, for example, the rarity of the child NFT.

[0116] After processing step SO2, the server information processing unit 10 transfers the present UT for the amount of granted tokens from the operator's internal wallet to the user's internal wallet (step SO3). More specifically, the server storage unit 12 stores an internal UT management database 56. This database records the balance of the present UT for each internal address, transactions related to the present UT (including deposits and transfers), and other information necessary for managing the present UT. In step SO3, the server information processing unit 10 updates the internal UT management database 56, increasing the balance of the present UT for the internal address of the noted user by the amount of granted tokens and decreasing the balance for the operator's internal address by the amount of granted tokens. This completes the granting of the present UT for the amount of granted tokens to the user's internal wallet. The server information processing unit 10 may also be configured to issue new present UT for the amount of granted tokens according to rules.

[0117] Regarding the granting of the present UT, the server information processing unit 10 may be configured to grant the present UT locked for a locking period. For example, if the locked present UT is granted for a 50-hour locking period, the user of interest cannot consume the locked present UT or transfer it to a user external wallet during the locking period. In this configuration, the server information processing unit 10 dynamically changes the locking period based on the supply and demand situation of the present UT, the circulation situation of the present UT, and other circumstances related to the present UT. Furthermore, in this configuration, the server information processing unit 10 appropriately updates the internal UT management database 56 to manage the status of the locking of the present UT. After processing step SO3, the server information processing unit 10 notifies the user terminal information processing unit 18 that the granting of the present UT to the user of interest has been completed (step SO4). The user terminal information processing unit 18 displays information indicating that the granting of the present UT has been completed on the user terminal display unit 20 (step SN5).

[0118] As described above, in this embodiment, the server information processing unit 10 has a function of granting rewards to users who own child NFTs in accordance with their actions in the token economy. In this embodiment, "actions in the token economy" include activities in the basic service that led to the receipt of a game ticket, and rewards include game tickets. "Actions in the token economy" include actions such as consuming a game ticket to play the game, and rewards include the UT awarded as a result of the game. Due to the above configuration, it is expected that users will actively take actions to receive rewards. Such actions will revitalize the token economy. Furthermore, the server information processing unit 10 has a function of granting rewards in the form of the UT, which can be used in the token economy and traded on a public exchange, in accordance with actions taken in the token economy by users who own child NFTs. Since rewards are thus granted to users with items of high utility value and economic value, user satisfaction is high. Furthermore, users can be given an incentive to actively engage in the basic service in order to obtain token tickets. The server information processing unit 10 may be configured to grant users FTs as a benefit, which can be used in the token economy but cannot be traded in the public market, instead of or in addition to the UT. The server information processing unit 10 may be configured to grant users an object other than FT as a benefit. In this configuration, the object may be, for example, points that can be used in the service, points commonly used in point programs, a specified discount, an improvement in rank in various services, an NFT (which may be a child NFT), or an item that can be used in a specified service.

[0119] Furthermore, when granting the UT (benefit) to a user who owns a child NFT in response to their actions in the token economy, the server information processing unit 10 has a function of increasing the amount of the UT (benefit) when the child NFT is acquired using the Market MK (first platform) compared to when the child NFT is acquired using the Pool PL (second platform). This configuration provides users with an incentive to actively use the Market MK. Active use of the Market MK revitalizes the token economy. In this embodiment, the server information processing unit 10 adjusts the amount of the benefit when the Market MK is used and when the Pool PL is used. In this regard, the server information processing unit 10 may be configured to adjust the quality of the benefit, or adjust the quantity and quality of the benefit. For example, when the server information processing unit 10 grants an item that can be used in a specific service as a benefit, a rarer item is granted when the Market MK is used compared to when the Pool PL is used.

[0120] In addition, in this embodiment, the more child NFTs included in a party, the greater the amount of UT a user can obtain after playing the Game. Based on this, users are motivated to collect as many active child NFTs as possible. Furthermore, because possessing child NFTs with diverse character attributes increases the probability of winning the Game, users are motivated to acquire child NFTs with diverse character attributes. Driven by this motivation, users are expected to proactively take actions to acquire child NFTs. Such actions stimulate the Economic Zone. Furthermore, in the Game, the rarity and character attributes of child NFTs affect the probability of winning the Game. Rarity has an impact because the upper limit of combat power varies depending on the rarity. Furthermore, when using the Market MK, users can select child NFTs taking rarity and character attributes into consideration, providing greater user convenience.

[0121] <Scenes in which a user uses the UT> Next, the operation of the information processing system 1 in a scene in which a user uses the UT will be described. This scene corresponds to step F14 in FIG. 3. The user can consume the UT stored in their own internal user wallet to challenge an event that improves the combat power of a desired child NFT. More specifically, the user uses the user interface provided by the user terminal information processing unit 18 to issue the following instruction. That is, the user designates one of the active child NFTs stored in their own internal user wallet. The user then instructs the server information processing unit 10 to consume a certain amount of the UT to challenge an event that improves the combat power of the designated child NFT. The user terminal information processing unit 18 notifies the server information processing unit 10 of this instruction. In response to this notification, the server information processing unit 10 randomly increases the combat power value of the designated child NFT within a range of 1 to 5 points. However, the upper limit of the combat power value is determined by the rarity, and the combat power value cannot exceed this upper limit. The upper limit for rares is 100 points, and for commons it is 80 points. As mentioned above, the upper limits shown here are merely examples. The server information processing unit 10 appropriately performs the process of transferring a certain amount of the UT, the process of reflecting the increase in combat power value in the metadata, and other necessary processes.

[0122] As mentioned above, the higher the combat power, the higher the probability of winning the Game. If a user wins the Game, they can acquire more UT than if they lose. This motivates users to use the UT they acquire to increase the combat power of their child NFTs. Driven by this motivation, users are expected to proactively take actions that lead to the acquisition of game tickets, and, once they have acquired game tickets, to proactively play the Game. Users' actions in this way contribute to the activation of the Token Ecosystem.

[0123] In addition, users can use the UT they own for transactions on public exchanges. As an example, users can exchange the UT for legal tender, crypto assets, or other value using public exchanges. However, to trade the UT on a public exchange, users must transfer the UT from their internal user wallet to an external user wallet. The user terminal information processing unit 18 cooperates with the server information processing unit 10 to provide a user interface for transferring the UT from the internal user wallet to the external user wallet. When a transfer of the UT is instructed via the user interface, the server information processing unit 10 updates the internal UT management database 56, sends a transaction that changes the balance in the external wallet, and performs other necessary processing.

[0124] The UT may also be consumed in the following manner. That is, the operator provides a platform for exchanging the UT for items that can be used in the Service. The items are, for example, icons that can be used in the user's profile in the basic service or stamps that can be used in chat. The user then exchanges the UT for the items.

[0125] <Others regarding the Token Economy> The Operator will acquire Ether when Child NFTs are issued, acquire Ether in response to transactions on the Market MK, and acquire UT in response to users' consumption of the UT. The Operator will use the acquired Ether and UT in a way that improves the convenience and satisfaction of participants (including holders and users), benefits participants, and revitalizes the Service and the Token Economy.

[0126] Although one embodiment of the present invention has been described above, the above embodiment is merely an example of a specific embodiment for carrying out the present invention, and the technical scope of the present invention should not be interpreted as being limited thereby. In other words, the present invention can be carried out in various forms without departing from the gist or main characteristics thereof.

[0127] Alternatively, a browser (including a program associated with the browser) may be configured to implement some or all of the functions of the dedicated application AP. In this configuration, when using the browser's functions, the holder terminal information processing unit 13 appropriately sends requests to the server information processing unit 10 and receives responses. In particular, when displaying various screens, the holder terminal information processing unit 13 sends requests to the server information processing unit 10, receives HTML files from the server information processing unit 10, and displays the screens based on the HTML files. While specific examples of screens are shown in the above embodiment, the screen contents are not limited to those shown. In the above embodiment and modified examples, the information processing server 2 is configured to include a storage unit (server storage unit 12). Alternatively, a storage unit may be provided in another device that can communicate with the information processing server 2, and the information processing server 2 may access the other device as needed. The functional blocks shown in the above embodiment can be implemented using any hardware or a combination of any hardware and any software. In other words, these functional blocks are not limited to specific hardware. The processing units in the flowcharts shown in the figures are divided according to the main processing content to facilitate understanding of the processing. The present invention is not limited by the way in which the processing units are divided or the names of the processing units. The processing of each device can be divided into even more processing units depending on the processing content. Furthermore, one processing unit can also be divided so that it includes even more processing. Furthermore, as long as similar processing can be performed, the processing order of the above flowchart is not limited to the example shown. Furthermore, for example, the information processing server 2 does not have to be a single device. If the information processing server 2 is composed of multiple server devices, the information processing units of the multiple server devices work together to function as an "information processing unit."

[0128] Furthermore, for example, embodiments may include providing a program executed by the computers of the information processing server 2, the holder terminal 3, and the user terminal 4, or providing a recording medium on which the program is recorded in a computer-readable manner. The recording medium may be a magnetic or optical recording medium or a semiconductor memory device. Specific examples include portable or fixed recording media such as flexible disks, hard disk drives (HDDs), CD-ROMs (Compact Disc Read Only Memory), DVDs (Digital Versatile Discs), Blu-ray (registered trademark) discs, magneto-optical disks, flash memories, and card-type recording media.

[0129] In this embodiment, the server information processing unit 10 grants a game ticket to a user as a benefit, and grants the UT after the game based on the game ticket. In this regard, the server information processing unit 10 may grant the UT to a user who owns a child NFT instead of a game ticket. In this case, the game will not be played. In this configuration, the server information processing unit 10 grants a larger amount of UT in the case of a child NFT acquired using the Market MK than in the case of a child NFT acquired using the Pool PL.

[0130] In addition, for example, in the present embodiment, the server information processing unit 10 manages the FTs and NFTs managed in the internal wallet in a so-called off-chain manner using a database. In this regard, the server information processing unit 10 may be configured to manage the FTs and NFTs in a so-called on-chain manner using a blockchain.

[0131] 1 Information Processing System 2 Information Processing Server 3 Holder Terminal 4 User Terminal 10 Server Information Processing Unit (Information Processing Unit) PF Migration Platform (Platform) MK Market (First Platform) PL Pool (Second Platform)

Claims

1. An information processing device that executes processing related to a token economy, comprising: an information processing unit having the following functions: a function of issuing a second type of NFT (Non-Fungible Token) different from a first type to a holder of a first type of NFT in response to a request from the holder; a function of providing a platform for transferring the second type of NFT from the holder to a user; and a function of granting a benefit to the user who owns the second type of NFT in response to the user's actions in the token economy.

2. The information processing device according to claim 1, characterized in that the information processing unit has a function of providing as the platform a first platform that realizes transactions of the second type of NFT between the holder as a seller and the user as a buyer.

3. The information processing device according to claim 1, characterized in that the information processing unit has a function of providing as the platform a second platform through which the holder provides the second type of NFT free of charge and the user obtains the second type of NFT provided by the holder free of charge.

4. The information processing device according to claim 1, characterized in that the information processing unit has a function to provide as the platform: a first platform that realizes a transaction of the second type of NFT between the holder and the user, with the holder as the seller and the user as the buyer; and a second platform where the holder provides the second type of NFT free of charge and the user obtains the second type of NFT provided by the holder free of charge.

5. The information processing device according to claim 3 or 4, characterized in that the information processing unit has a function of granting the right to acquire the second type of NFT on the second platform preferentially to users who have made a high contribution to the services provided in the token economy.

6. The information processing device according to claim 3 or 4, characterized in that the information processing unit has a function of granting a benefit to the holder who provides the second type of NFT using the second platform.

7. The information processing device according to claim 6, characterized in that the information processing unit has a function of granting a Fungible Token (FT) that can be used in the token economy as a reward to the holder who provides the second type of NFT using the second platform.

8. The information processing device according to claim 7, characterized in that the information processing unit has a function of granting, as a bonus, to the holder who has provided the second type of NFT using the second platform, the FT that can be used in the token economy and traded on a publicly open exchange.

9. The information processing device of claim 4, characterized in that, when granting benefits based on the actions of the user who owns the second type of NFT in the token economy, the information processing unit has a function of improving the quality or quantity of benefits when the second type of NFT is acquired using the first platform compared to when the second type of NFT is acquired using the second platform.

10. The information processing device according to claim 1, characterized in that the information processing unit has a function of validating the second type of NFT for a certain period of time after the user acquires the second type of NFT, and a function of granting a benefit to the user who owns the second type of NFT in the valid state depending on the user's actions in the token economy.

11. The information processing device according to claim 10, characterized in that it has the following functions: a function of making the second type of NFT valid in response to a request from the user who owns the second type of NFT; a function of transitioning the second type of NFT from the valid state to an invalid state when a certain period of time has elapsed since the second type of NFT was made valid; and a function of granting a benefit to the user who owns the second type of NFT in the valid state in response to the user's actions in the token economy.

12. The information processing device according to claim 1, characterized in that the information processing unit has a function of granting benefits to the user who possesses the second type of NFT in accordance with the behavior of the user in services provided in the token economy.

13. The information processing device according to claim 12, characterized in that the information processing unit has a function of deriving an evaluation value indicating the degree of contribution to the service based on the behavior of the user who owns the second type of NFT in the service, and granting a benefit if the evaluation value is above a certain level.

14. The information processing device according to claim 1, characterized in that the information processing unit has a function of prohibiting the issuance of the second type NFT based on the one first type NFT for a certain period of time after issuing the second type NFT in response to a request from the holder who owns the one first type NFT.

15. The information processing device according to claim 1, characterized in that the information processing unit has a function of granting an FT that can be used in the token economy as a reward in accordance with the actions of the user who owns the second type of NFT in the token economy.

16. The information processing device according to claim 15, characterized in that the information processing unit has a function of granting the FT, which is usable in the token economy and tradeable on a publicly open exchange, as a benefit in response to actions in the token economy by the user who owns the second type of NFT.

17. An information processing system that performs processing related to a token economy, comprising: an information processing unit having the following functions: a function of issuing a second type of NFT (Non-Fungible Token) different from a first type to a holder of a first type of NFT in response to a request from the holder; a function of providing a platform for transferring the second type of NFT from the holder to a user; and a function of granting benefits to the user who owns the second type of NFT in response to the user's actions in the token economy.

18. An information processing method by an information processing device that executes processing related to a token economy, comprising: a step in which an information processing unit of the information processing device issues a second type of NFT (Non-Fungible Token) different from the first type to a holder in response to a request from the holder who owns the first type of NFT; a step in which the information processing unit of the information processing device provides a platform for transferring the second type of NFT from the holder to a user; and a step in which the information processing unit of the information processing device grants a benefit to the user who owns the second type of NFT in response to the user's actions in the token economy.

Images