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

Abstract

We will build a token economy with a new mechanism that encourages participants to take actions that contribute to the revitalization of the token economy. [Solution] The information processing server 2 is equipped with a server information processing unit 10 that has the following functions: issuing a second type of NFT (Non-Fungible Token) different from a first type to a holder upon request of the holder who owns the first type of NFT; providing a platform for transferring the second type of NFT from the holder to a user; and granting benefits to users who own the second type of NFT depending on the actions of the users in the token economy.

Description

[Technical field]

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

[0002] Blockchain technology has been widely used. There are types of blockchain platforms that use blockchain technology that can issue their own tokens. There are at least two types of tokens: Fungible Token (FT) and Non-Fungible Token (NFT). There are many attempts to build a token economy that uses tokens issued using blockchain technology. A token economy is a unique economic sphere in which participants acquire tokens, circulate tokens, consume tokens, and take other token-related actions, thereby circulating the economy. A token economy is sometimes called an ecosystem, token economy, or simply an economic sphere.

[0003] Regarding this token economy, Patent Document 1 discloses the following technology. That is, in Patent Document 1, a data management system acquires participants' token transaction history and their activity history within the token economy (ecosystem). The data management system calculates a royalty index representing the loyalty level to the token economy (ecosystem) for multiple participants based on the transaction history and activity history. The data management system tally up the royalty indexes for multiple participants and estimate the royalty level of the entire ecosystem. The above technology is disclosed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2023-87990 A Summary of the Invention [Problem to be solved by the invention]

[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 such 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. [Means for solving the problem]

[0007] In order to solve the above problems, the present invention provides a method for issuing a first type of NFT to a holder in response to a request from the holder, Determine whether the holder currently owns the first type of NFT, and if so, The platform issues second-type NFTs to holders and transfers the second-type NFTs from holders to users, and grants rewards to users who own the second-type NFTs based on their actions in the token economy. Effect of the Invention

[0008] According to the present invention configured as described above, a holder who is a participant of 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 has a motivation to possess the first type of NFT, issue a second type of NFT, and further use the platform to transfer the second type of NFT to a user. With this motivation, it is expected that the holder will 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. This action has the effect of promoting the use or circulation of tokens in the token economy, and is an action that contributes to the activation of the token economy. Furthermore, a user who is a participant of the token economy can obtain a second type of NFT by using the provided platform. Furthermore, when a user possesses a second type of NFT, a reward is given according to the action in the token economy. Therefore, the user has a motivation to use the platform to obtain a second type of NFT and take an action to receive a reward. With this motivation, it is expected that users will proactively 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. [Brief description of the drawings]

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

[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 including the Internet, a telephone network, and 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 convenience of explanation, in FIG. 1, the network N and the blockchain network B are depicted 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 by a P2P method. Note that the blockchain network B according to this embodiment includes a network related to the Ethereum layer 2 platform and other networks that can be linked to the blockchain network B. The Ethereum layer 2 platform is, for example, Arbitrum or Polygon. Each node of the blockchain network B stores a blockchain (distributed ledger) using blockchain technology.

[0012] In FIG. 1, the information processing server 2 is depicted outside the blockchain network B. However, the information processing server 2 may function as one of the nodes (however, it does not have to be a full node) that make up the blockchain network B. This also applies to the holder terminal 3 and the user terminal 4. The information processing server 2 may also be configured to request, from another device (for example, a device that functions as an endpoint of the blockchain network B), all or part of the processing that involves sending a transaction to the blockchain network B, executing a specific function of a specific smart contract, checking the state of a specific account in the world state, and other access to the blockchain network B. This also applies to the holder terminal 3 and the user terminal 4.

[0013] Since the blockchain network B is a network related to Ethereum, smart contracts can be registered (deployed) in the blockchain. In the blockchain network B, at least FTs (Fungible Tokens) and NFTs (Non-Fungible Tokens) can be issued using smart contracts. FTs are tokens that have fungibility. In this embodiment, the 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, the NFTs are tokens that comply with ERC-721a.

[0014] In this embodiment, the blockchain network B is a network related to Ethereum, but this is merely an example. The blockchain network B may be a network built on a blockchain platform other than Ethereum. The blockchain may be any of a public chain, a private chain, and a consortium chain. The standards to which FT and NFT comply are not limited to the standards shown in the example. The term "smart contract" is a name that conveniently expresses 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 a function of providing various services, a function of executing processes related to the token economy, and a function of constructing a token economy. Hereinafter, the service provided by the information processing server 2 is referred to as the "Service". The token economy constructed by the information processing server 2 is 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 is referred to as the "Administrator". Hereinafter, the person who may participate in the token economy is referred to as the "Participant". 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 one 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 device that constitutes 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. The holder will be described later. The holder terminal 3 is a terminal used by the holder for convenience, 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. The user will be described later. The user terminal 4 is a terminal used by the user for convenience, and does not mean a terminal used exclusively by the user. The user terminal 4 may be of any type.

[0017] Fig. 2 is a block diagram showing an example of a 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 device and a main storage device. The processing device is a device having an information processing function and includes a CPU. The CPU includes a control device, an arithmetic device, a register, and a cache memory. The main storage device includes a DRAM and other volatile memories. The server information processing unit 10 executes information processing by the processing device reading a program stored in the server storage unit 12 into the main storage device and executing it. That is, the server information processing unit 10 executes information processing by cooperation between hardware and software. The server communication unit 11 includes a communication device having a function of communicating with an external device. The communication device includes a communication control device and a network interface. The server communication unit 11 communicates with the external device by the communication device under the control of the server information processing unit 10. In the following, detailed explanations of communication using the network N by the information processing server 2 and other communications are omitted, assuming that they are appropriately performed by the server communication unit 11. The server storage unit 12 includes a hard disk drive (which may be another magnetic storage device), a ROM, a flash memory, and other non-volatile memories. The server storage unit 12 stores data in the non-volatile memory.

[0019] The holder terminal information processing unit 13 of the holder terminal 3 includes a processing device having an information processing function and a main storage device. The holder terminal information processing unit 13 executes information processing by having the processing device read out a program stored in the holder terminal storage unit 17 into the main storage device and execute it. That is, the holder terminal information processing unit 13 executes information processing by 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 an external device by the communication device under the control of the holder terminal information processing unit 13. In the following, detailed description of communication by the holder terminal 3 using the network N is 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, and other display devices. The holder terminal display unit 15 displays an image 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, and other input devices. The holder terminal input unit 16 detects an 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 non-volatile memory. The holder terminal storage unit 17 stores data in the non-volatile memory.

[0020] The user terminal information processing unit 18 of the user terminal 4 includes a processing device having an information processing function and a main storage device. The processing device reads out a program stored in the user terminal storage unit 22 into the main storage device and executes the program, whereby the user terminal information processing unit 18 executes information processing. That is, the user terminal information processing unit 18 executes information processing by 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 an external device by the communication device under the control of the user terminal information processing unit 18. In the following, detailed description of communication using the network N by the user terminal 4 is 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 an image 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 an 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 a 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 a function to provide various screens related to the service, a function to transmit and receive various information to and from the information processing server 2, and a function to execute other processes related to the service and the token economic sphere. Regarding the processes related to the service and the token economic sphere, the holder terminal information processing unit 13 and the user terminal information processing unit 18 basically execute the processes using the functions of the dedicated application AP (including the OS of the terminal, a web application in which the dedicated application AP can be used, 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 acquire 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] <Outline of the Token Economy> Next, an overview of the Token Economy will be explained. The Token Economy is an economic sphere in which participants take actions related to various tokens (including the Parent NFT, Child NFT, the Utility Token, and the Governance Token, which will be described later) and the economy circulates. Participants in the Token Economy include at least Holders and Users. Holder is a term that conveniently represents a participant in the Token Economy who can acquire a Parent NFT (described later). User is a term that conveniently represents a participant who can acquire a Child NFT (described later) via the transition platform PF (platform) (described later). Holders and Users have registered accounts on the Service, and can log in to their accounts on the Service using their own login information (for example, a combination of a login ID and a password). The terms Holder and User are used to conveniently distinguish participants by their roles. Thus, one person can participate in the Token Economy as a Holder and at the same time participate in the Token Economy as 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 services of the present invention. It is assumed that users will use the basic service SV. The basic service SV is a communication service that enables communication between users. In the basic service SV, users can post messages, contact other users by chat or telephone, create groups, and participate in 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 is 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 (for example, 5,000). The first owner of the first-type NFT is the operator. Hereinafter, the first-type NFT is referred to as a "parent NFT." In other words, the parent NFT does not mean a specific NFT, but an NFT whose type is the first type. The parent NFT can be secondarily sold in a publicly available NFT marketplace (hereinafter referred to as a "public marketplace"). The issuance of the parent NFT by the operator will be described in detail below. The operator deploys a smart contract corresponding to the parent NFT (hereinafter referred to as a "parent NFT-compatible contract") in advance to the blockchain network B. Next, the operator creates a state in the parent NFT-compatible contract in which the token ID, the operator external address, and associated information (including the 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 the operator external address is referred to as an operator external wallet. As a result of the above, a specified number of parent NFTs (owned by the operator) will be issued.

[0025] The metadata of the parent NFT includes the following items: Token ID <item>, Name <item>, Creator <item>, Detailed information <item>, Parent NFT image <item>, Last child NFT issuance date and time <item>. However, the items of the metadata of the parent NFT are not limited to these items. For the parent NFT and other NFTs, the 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 metadata of the parent NFT. In the Parent NFT image <item>, a URI for accessing the image data of the corresponding parent NFT image (hereinafter referred to as "Parent NFT image data") is set. The image of the parent NFT is an image showing a character imitating a person. The content of the image of the parent NFT is different for each parent NFT. An example of an image of a parent NFT is shown in FIG. 5 described later. In the Last child NFT issuance date and time <item>, the last child NFT issuance date and time information is set. The final 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 final child NFT issuance date and time information is a special value. The final child NFT issuance date and time information will be described later. The meaning of the parent NFT will be described later.

[0026] The method of issuing the parent NFT is not limited to the method exemplified in this embodiment. For example, a predetermined amount of parent NFTs may not be issued at once, but may be issued in stages until the issuance amount reaches a predetermined amount. For example, the parent NFT may not be issued using a dedicated smart contract. In this case, as an example, the parent NFT is issued using a public marketplace service. For example, the server information processing unit 10 may mint the parent NFT each time the parent NFT is distributed to a holder.

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

[0028] In addition, regarding the Token Economy, the operator will issue the Governance Token on Ethereum. Hereinafter, the Governance Token will be referred to as "GT". The GT is a Fungible Token (FT) related to the Token Economy. The GT functions as a governance token that is granted the right to exercise influence over the operation of the Token Economy. Hereinafter, the symbol of the GT will be "gt", which will be used as the unit of the GT. The total issuance of the GT is, for example, 10 billion gt. Regarding the issuance of the GT, the operator will deploy a token contract (a smart contract conforming to ERC-20) corresponding to the GT on the blockchain network B. In the token contract, the name, symbol, number of decimal places, total issuance, and other necessary settings of the token will be appropriately set. Once the operator has performed the necessary work, the GT will be subject to trading on a publicly available cryptocurrency exchange (hereinafter referred to as the "public exchange"). As described above, the GT in question is an FT that can be used in the Token Economy and can be traded on public exchanges. The significance of the GT in question will be described later.

[0029] In addition, regarding 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 amount of the UT to be issued will not be set. Regarding the issuance of the UT, the operator will deploy a token contract (a smart contract conforming to ERC-20) corresponding to the UT on the blockchain network B. Various settings will be appropriately set in the token contract. By performing the necessary work by the operator, the UT will be subject to trading on the public exchange. As described above, the UT is an FT that can be used in the Token Economy and can be traded on the public exchange. The meaning of the UT will be described later.

[0030] FIG. 3 is a diagram used to explain the outline of the token economy. The outline of the token economy will be explained below using FIG. 3. However, the explanation using FIG. 3 below is intended to explain the overall picture of the token economy. Various terms related to the token economy, various actions of participants, various processes of the information processing system 1, and the significance of various processes performed by the information processing system 1 will be described later.

[0031] As shown in FIG. 3, the 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 that proves 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). As a result, the holder 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 specified 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 a child NFT based on that parent NFT for a waiting period (a certain period). In this embodiment, the value of the waiting period is "72 hours". A holder can issue a child NFT any number of times as long as he owns the parent NFT, provided that the interval is longer than the waiting period. 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 of the child NFT, the distribution situation of the child NFT or parent NFT, and other situations related to the child NFT or parent NFT.

[0032] As shown in FIG. 3, the server information processing unit 10 provides a migration platform PF. The migration platform PF is a platform for migrating child NFTs from holders to users. The migration 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 the holder as the seller and the user as the buyer. The holder can use the present market MK to set a selling price in Ethereum and sell the child NFT. The user can use the present market MK to purchase the desired child NFT from among the child NFTs on sale. The present pool PL is a platform where the holder supplies child NFTs free of charge and the user acquires the child NFTs supplied by the holder free of charge.

[0033] As shown in FIG. 3, the holder provides the child NFT to the Pool PL free of charge (step F4) or sells the child NFT on the Market MK (step F5). Hereinafter, providing the child NFT to the Pool PL free of charge may be referred to as "providing the child NFT using the Pool PL". Also, selling the child NFT on the Market MK may be referred to as "providing the child NFT using the Market MK". When the holder provides the child NFT using the Pool PL, the server information processing unit 10 grants a privilege to the holder. More specifically, the server information processing unit 10 grants a predetermined amount of the GT to the holder periodically during the pool privilege period. In this embodiment, the pool privilege period is "120 days". In other words, when the holder provides the child NFT using the Pool PL, the holder periodically receives a predetermined amount of the GT from the operator during the pool privilege period of 120 days.

[0034] As shown in FIG. 3, the user acquires a child NFT by using the Pool PL (step F6) or by using 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 the set selling price. At the stage when the user acquires the child NFT, the status of the child NFT is in a suspended state. After purchasing the suspended child NFT, the user uses a predetermined user interface to request that the child NFT be transitioned from a suspended state to an active state (step F8). In response to the request, the server information processing unit 10 sets the child NFT to an active state. Furthermore, after a certain period (validity period + α) has elapsed since the child NFT was set to an active state, the server information processing unit 10 transitions the NFT from an active state to an inactive state (step F9). In this embodiment, the validity period is 90 days.

[0035] As shown in FIG. 3, a user who owns 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 way, the game ticket is granted to a user who owns a valid child NFT. The user who has acquired the game ticket consumes the game ticket to play the subject game (step F12). The subject game is a game played using one or more valid child NFTs, and has a winning or losing outcome. After the subject game ends, the server information processing unit 10 grants a privilege to the user (step F13). More specifically, the server information processing unit 10 grants a predetermined amount of the subject UT to the user. If the user wins the subject game, the server information processing unit 10 grants a larger amount of the subject UT than if the user loses. Furthermore, if the other conditions are the same, when the user acquires a child NFT using the subject market MK, the server information processing unit 10 grants a larger amount of the subject UT compared to when the user acquires the child NFT using the subject pool PL.

[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 challenge an event that increases the combat power of the "valid child NFT" that the user owns. Combat power will be described later. The user also exchanges the UT for legal tender, Ether, or other value on a public exchange. This allows the user to enjoy economic benefits. In addition, the server information processing unit 10 provides various platforms that allow the user to improve his or her own satisfaction or to obtain benefits in exchange for the consumption of 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 called 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 called a "noted user", and the behavior of the user will be explained by focusing on the noted user as appropriate.

[0039] First, the operation of the information processing system 1 in a scene where the holder acquires a parent NFT will be described. This scene corresponds to step F1 in FIG. 3. Here, the holder holds 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 a public exchange, a public marketplace, and other services. The holder external wallet can manage Ether, which is the internal currency of Ethereum, NFTs traded in the public marketplace, and tokens traded in the public exchange. Furthermore, the holder external wallet can manage the parent NFT, the child NFT, the GT in question, and the GT in question.

[0040] The holder acquires the parent NFT, for example, by the following method. For example, the operator distributes the parent NFT he owns to the holder, and the holder acquires the parent NFT. Distributing the parent NFT to the holder means transferring the 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 prior plan, for example. In addition, the operator distributes the parent NFT to one or more holders selected according to a predetermined rule in an event or campaign. When the operator distributes one parent NFT to one 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 one parent NFT in the parent NFT-compatible contract to the holder external address of the one holder. As a result, the parent NFT is distributed to the one holder, and the one holder owns the parent NFT.

[0041] Even if not otherwise specified, the transfer of ownership of the parent NFT and other NFTs by the server information processing unit 10 is appropriately performed by sending necessary transactions to the blockchain network B, updating necessary databases, and executing other necessary processes by the server information processing unit 10. In addition, the method by which a holder acquires a parent NFT is not limited to the method by which the operator distributes it. For example, a holder can acquire a parent NFT by purchasing a parent NFT that has been secondarily sold in a public marketplace. In addition, a holder can 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 that proves the right to issue a Child NFT. By issuing a Child NFT based on the Parent NFT that the Holder owns, the Holder can receive various benefits, as described below. Therefore, the Holder has the motivation to acquire and own the Parent NFT. It is expected that the Holder will proactively take action to acquire and own the Parent NFT, based on this motivation. Such action has the effect of increasing the market value of the Parent NFT and encouraging the use and circulation of tokens in the Token Economy. Therefore, such action activates the Token Economy. In addition, since the Parent NFT can be sold secondarily in a public marketplace, the Holder can sell the Parent NFT in certain cases and obtain economic benefits.

[0043] Next, the operation of the information processing system 1 in a scene where 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, the holder of interest operates the holder terminal 3. The holder of interest also owns one or more parent NFTs.

[0044] The holder of interest starts the dedicated application AP of the holder terminal 3, inputs login information, and logs in to the account of the service. The holder of interest further connects his / her own external wallet to the service of interest. The holder external wallet is connected by inputting necessary information about the holder wallet into a predetermined user interface provided by the function of the dedicated application AP. As shown in the flowchart FA, the holder of interest performs the necessary operation 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 that the instruction has been received (step SA2). Even if not otherwise described, 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 the processing.

[0045] In response to the notification, the server information processing unit 10 collects information necessary for displaying the holder-owned parent NFT list screen 25 (step SB1). In detail, the server information processing unit 10 can refer to the contents of the metadata for any parent NFT and any child NFT, and obtain information recorded in the metadata and information linked to the information recorded in the metadata. In particular, the "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 predetermined items of the metadata for any parent NFT and any child NFT. Setting item values ​​for predetermined items of the metadata includes updating the value of the item value already set in the predetermined item. Note that when accessing the metadata of one NFT, the server information processing unit 10 uses the token URI associated with the token ID of the one NFT in the corresponding smart contract.

[0046] In step SB1, the server information processing unit 10 refers to the holder external wallet of the target holder connected to the service and identifies the parent NFT owned by the target holder. Next, the server information processing unit 10 refers to the metadata for each parent NFT owned by the target holder and obtains the parent NFT image data and the last child NFT issuance date and time information. After processing step SB1, the server information processing unit 10 transmits the parent NFT image data, the 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 target holder to the holder terminal information processing unit 13 (step SB2). Even if not specifically described, 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 from the time of issuance. In light of 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. The unit display area 26 is a selectable area. When the 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 (including various data recorded in the metadata) of the corresponding parent NFT. The above is similar for the other unit display areas. The unit display area 26 on the left side of the figure is an area for NFTs outside the waiting period. The unit display area 26 on the right side of the figure is an area for NFTs during the waiting period. Hereinafter, the unit display area 26 relating to NFTs outside the waiting period will be referred to as a non-waiting period display area 26-1. On the other hand, the unit display area 26 relating to NFTs during the waiting period will be referred to as a waiting period display area 26-2. The holder terminal information processing unit 13 determines whether a parent NFT is in the waiting period or outside the waiting period by 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 waiting period, and otherwise determines that the parent NFT is outside the waiting period. Note that if the last child NFT issuance date and time information is an initial value, the holder terminal information processing unit 13 determines that the parent NFT is outside the waiting period. The server information processing unit 10 may be configured to determine whether the parent NFT is in the waiting period or outside the waiting period and notify the holder terminal information processing unit 13 of the determination result.

[0049] As shown in FIG. 5, the 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 issuing a child NFT based on the corresponding parent NFT. Here, the child NFT has rarity as an attribute. In this embodiment, there are rare and common types of rarity. Rare is rarer than common. Rarity will be described later. The rare issuance request button 29 is a button that requests issuing a child NFT whose rarity is rare (hereinafter referred to as a "rare child NFT"). The common issuance request button 30 is a button that requests issuing a child NFT whose rarity is common (hereinafter referred to as a "common child NFT").

[0050] Information 31 indicating the fee required to issue a rare child NFT (hereinafter referred to as "rare issuance fee") is displayed in association with the rare issuance request button 29. Similarly, information 32 indicating the fee required to issue a common child NFT (hereinafter referred to as "common issuance fee") is displayed in association with the common issuance request button 30. 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 situations related to the child NFT. Note that in this embodiment, the two types of rarity, rare and common, are merely a simplified example. A configuration in which rarity includes types different from those exemplified in this embodiment, such as uncommon and super rare, may also be used.

[0051] As shown in FIG. 5, an image 27 of the corresponding parent NFT is displayed in the waiting period display area 26-2. Information 34 indicating the time required from the current time until the waiting period is completed is displayed below the image 27. The holder terminal information processing unit 13 calculates the time in real time from 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 is left before a new child NFT can be issued based on the corresponding parent NFT.

[0052] 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 operation exemplified in this embodiment. The contents of the screen are also an example. That is, the server information processing unit 10 only needs to collect information necessary for displaying the screen and transmit it to the holder terminal information processing unit 13. When collecting the necessary information, the server information processing unit 10 uses information on the external wallet connected to the service, information on the blockchain of the blockchain network B (particularly information recorded in the storage of the parent NFT-compatible contract), a database on the parent NFT, a database on the holder, and other data as necessary. The above also applies to the display of other screens.

[0053] As shown in the flow chart FA, when the holder of interest issues a child NFT based on one parent NFT, the holder of interest selects the rare issue request button 29 or the common issue request button 30 in the non-waiting period display area 26-1 corresponding to the one parent NFT (step SA4). Hereinafter, the parent NFT corresponding to the selected button (i.e., the parent NFT that is the basis for issuing the child NFT) is referred to as the "designated parent NFT". The consideration required to issue the child NFT is referred to as the "required issuance consideration". In response to the selection of the button, the holder terminal information processing unit 13 notifies the server information processing unit 10 that the button has been selected (step SA5). In response to the notification, the server information processing unit 10 determines whether or not the child NFT can be issued based on the designated parent NFT (step SB3). In step SB3, the server information processing unit 10 at least determines whether or not the holder of interest currently owns the designated parent NFT and whether or not the balance of Ether of the holder of interest is equal to or greater than the required issuance consideration. Regarding the determination as to whether the holder of interest 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 inquires of the blockchain network B as to whether the token ID of the designated parent NFT and the holder external address of the holder of interest are associated in the parent NFT-compatible contract. Then, the server information processing unit 10 makes the above determination based on the result of the inquiry. The inquiry is made by executing an appropriate function of the parent NFT-compatible contract. In addition, regarding the determination as to whether the balance of the Ether of the holder of interest 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 inquiring of the blockchain network B about the balance of Ether of the holder external address of the holder of interest.

[0054] If the 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 on the holder terminal display unit 15 that the child NFT cannot be issued together with information indicating the reason. If the 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 sets the owner of the child NFT as the target holder. In more detail, the server information processing unit 10 sends a transaction to the blockchain network B instructing to associate a new token ID with the target holder's external holder address in the child NFT-compatible contract. In this transaction, the contract address of the child NFT-compatible contract is set as the destination, and a specific function with appropriate parameter values ​​is specified. The transaction is executed according to the Ethereum standard, 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>, via pool 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 ​​to the token ID <item>, name <item>, creator <item>, and detailed information <item> of the metadata of the child NFT. The server information processing unit 10 also sets a value to the rarity <item> in the following manner. That is, when the holder of interest 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 holder of interest requests the issuance of a common child NFT, the server information processing unit 10 sets a common value indicating common to the rarity <item>. In addition, a value indicating a character attribute is set to the character attribute <item>. In this embodiment, there are fire attribute, water attribute, and wood attribute as types of character attributes. However, the types of character attributes 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 from the fire attribute, water attribute, and wood attribute, 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 the child NFT transitions from a stopped state to a valid state to an invalid state when a specific event is triggered. The status of the child NFT when it is issued is a stopped state. The server information processing unit 10 sets a value indicating the stopped state to the status <item>.

[0057] In the stopped state image <item>, a URI is set for accessing image data of the image of the corresponding child NFT in the stopped state (hereinafter, "stopped state image data"). The image of the child NFT in the stopped state is an image that imitates an "egg". In particular, the image of the child NFT in the stopped state is an image that allows the character attributes to be known by appearance. An example of an image of a child NFT in the stopped state is shown in FIG. 6, which will be described later. The server information processing unit 10 generates the stopped state image data using the following model. That is, the model is a model that inputs a value indicating the character attribute, generates an image imitating an egg with appropriate content, and outputs the stopped state image data in which the image is recorded. Then, the server information processing unit 10 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 of the pooling flag <item> (hereinafter referred to as the "pooling flag"), the flag of the selling flag <item> (hereinafter referred to as the "selling flag"), and the flag of 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 the selling price <item> and the validity status date and time information <item> to null values.

[0058] Also, 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 for the required issuance consideration from the holder external address to the operator external address. This processing may be performed in any manner as long as it ultimately creates a state in which the Ether balance of the holder external address is reduced by the required issuance consideration and the Ether balance of the operator external address is increased by the required issuance consideration. This is the same for all processing involving the transfer of Ether. Also, 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 of 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 required 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 target holder has been completed (step SB6). The information includes at least stopped state image data of the issued child NFT. In response to the 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 for the child NFT issued to the target holder, and information that the issuance of the child NFT has been completed. Note that when the image of the stopped child NFT is displayed on the issuance completion notification screen 35, an egg may be laid.

[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 has a motivation to issue a child NFT. It is expected that the holder will proactively take the action of issuing a child NFT based on this motivation. This action has the effect of encouraging the use and circulation of tokens in the token economy. Therefore, taking this action will revitalize the token economy.

[0061] In addition, the server information processing unit 10 has a function of prohibiting the issuance of a child NFT based on a parent NFT for a waiting period (a certain period) after issuing a child NFT in response to a request from a holder who owns a parent NFT (a first type of NFT). This configuration makes it possible to prevent an unlimited amount of child NFTs from being issued, and to maintain an appropriate supply of child NFTs.

[0062] Next, the operation of the information processing system 1 in a scene where the holder provides a child NFT using the migration platform PF will be described. As described above, the holder can selectively execute 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] ● Case where a holder supplies child NFTs to the pool PL of this case First, a case in which a holder supplies a child NFT to the 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 an information processing method by the holder terminal 3, and flow chart FD shows an information processing method by the information processing server 2. In FIG. 7, the holder of interest operates the holder terminal 3.

[0064] The holder of interest starts the dedicated application AP of the holder terminal 3 and logs in to the account of the service. Furthermore, the holder of interest connects his / her own holder external wallet to the service of interest. As shown in the flowchart FC, the holder of interest performs the necessary operation 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 that the instruction has been received (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). The information includes at least image data of each of the stopped child NFTs owned by the holder of interest in a stopped state. 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 the 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 holder of interest. In the example of FIG. 8, the holder of interest 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 (including various data recorded in the metadata) of the corresponding child NFT. 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 pool PL of this case. The market selection button 41 is a button that is selected when selling the corresponding child NFT in the market MK of this case.

[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 the notification, the server information processing unit 10 executes a pool supply-related process (step SD3). In step SD3, the server information processing unit 10 executes a process to transfer the 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 holder external address to the operator external address. Furthermore, the server information processing unit 10 updates the pool in flag of the metadata of the pool specifier NFT from an off value to an on value. The in-pool flag is a flag that manages whether the corresponding child NFT remains in the pool PL. A child NFT remains in the pool PL when the child NFT has not been acquired by a user after being provided to the pool PL. The above process creates a state in which the holder of interest has provided the child NFT to the 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 the 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 flow chart FD, after processing step SD4, the server information processing unit 10 starts the pool privilege granting process (step SD5). The pool privilege granting process is a process of granting the present GT (privilege) to the holder continuously during the pool privilege period (120 days) starting from the timing when the holder supplies the child NFT to the present pool PL. In this embodiment, the server information processing unit 10 grants a certain amount (e.g., 1000gt) of the present GT to the holder periodically (e.g., once a day). When granting the present GT, the server information processing unit 10 sends a transaction to the blockchain network B to transfer a certain amount of the present GT from the operator external address to the holder external address. However, the granting of the present GT may be performed in any manner as long as the balance of the present GT in the holder external address is ultimately increased without shortage. By starting the pool privilege granting process in step SD5, the target holder can continuously receive the grant of the present GT during the pool privilege period.

[0069] The contents of the benefit given to the holder who supplied the child NFT to the pool PL of this case are not limited to the contents exemplified in this embodiment. For example, the server information processing unit 10 may be configured to give a predetermined amount of the GT of this case (or a value other than the GT of this case) to the holder once. The server information processing unit 10 may also be configured to change the quality or quantity of the benefit given to the holder depending on the rarity of the child NFT supplied to the pool PL of this case. In this configuration, for example, when the server information processing unit 10 supplies a rare child NFT to the pool PL of this case, the amount of the GT of this case given is increased compared to when a common child NFT is supplied. The server information processing unit 10 may also be configured to give the GT of this case to the internal address (described later) of the holder. The server information processing unit 10 may also be configured to give another type of FT that can be used in the token economic zone instead of the GT of this case (or together with the GT of this case). In this configuration, the other type of FT does not need to be tradeable on a public exchange. The server information processing unit 10 may also be configured to grant an object other than FT as a privilege. In this configuration, the object may be, for example, points that can be used in the present service, points that are generally used as a point program, a specified discount, an improvement in rank in various services, an NFT (or a child NFT), or an item that can be used in a specified service.

[0070] ● Cases where a holder sells a child NFT on this Market MK Next, a case where a holder sells a child NFT on the market MK 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 flowchart 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 that 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 flow chart 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 this market MK) is referred to as a "market designated child NFT." In response to the selection of this button, the holder terminal information processing unit 13 pops up a selling price related screen 42 for inputting the selling 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 an initial state. As shown in FIG. 10A, the sales price related screen 42 has a sales price input field 43 for inputting the sales price. When a child NFT is purchased by a user in the market MK, the user pays Ether for the set sales price. At that time, a certain percentage (5% in this embodiment) of the sales price is provided to the operator as a fee, and the remainder is provided to the holder of the seller as total revenue. In addition, a display area 44 for displaying the fee and total revenue is provided below the sales price input field 43 on the sales price related screen 42. For example, assume that "0.1 (Ether)" is input as the sales price in the sales price input field 43 of the sales price related screen 42 in the initial state shown in FIG. 10A. Then, the holder terminal information processing unit 13 displays "0.005 (Ether)" as the fee and "0.095 (Ether)" as the total revenue, as shown in FIG. 10B. Below the display area 44, a confirmation button 45 for confirming the input is provided. The noted user inputs the selling price when selling the market specifier NFT in the selling price input field 43, refers to the commission 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 specifier NFT (the approximate amount at which a sale tends to be completed).

[0073] When the holder terminal information processing unit 13 detects that the confirm button 45 has been selected, it notifies the server information processing unit 10 of the selection (step SE4). In response to the notification, the server information processing unit 10 executes child NFT sales-related processing (step SF1). In detail, the server information processing unit 10 changes the on-sale flag of the metadata of the market designator NFT to an on value, and sets information indicating the selling price set by the target user to the selling price <item>. As a result, the market designator NFT is managed as a child NFT on sale in the market MK in question. Although details are omitted, the holder can cancel the sale in the market MK in question at any time. When the sale is canceled, the server information processing unit 10 sets the on-sale flag of the metadata of the corresponding child NFT to an off value, and sets the selling price <item> to a null value. In this embodiment, the server information processing unit 10 is configured to manage the child NFT sold in the market MK in question by the 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 the 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] Next, the operation of the information processing system 1 in a scene where a user acquires a child NFT using the transition platform PF will be described. As described above, with regard to the acquisition of a child NFT, the user can acquire the child NFT using the Pool PL. The user can also purchase the child NFT on 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] ● Cases where a user acquires a child NFT using this Pool PL First, we will explain the case where a user acquires a child NFT using this 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 an information processing method by the user terminal 4, and flowchart FH shows an information processing method by the information processing server 2. In Fig. 11, a user of interest operates the user terminal 4. In the following explanation, the event in which a user acquires a child NFT from this pool PL is referred to as the "this 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 every day (for example, 0:00 a.m.). The server information processing unit 10 manages the latest evaluation value of each user in a predetermined database. The evaluation value is an index indicating the degree of contribution of the user to the basic service SV. In this embodiment, the evaluation value takes a value in the range of 0pp to 100pp (pp is a unit given for convenience), and the higher the value, the higher the degree of contribution. The server information processing unit 10 derives an evaluation value for one user by the following method. That is, the server information processing unit 10 acquires a user action log of the one user stored in the server storage unit 12. The user action log records daily login times for at least the past 30 days. The daily login time is the total login time of the basic service in one day. The server information processing unit 10 then derives the evaluation value using the following model. That is, the model is a model in which normalized values ​​of each of the daily login times for the past 30 days of the user are input as parameters, and an evaluation value is derived and output. In this model, the normalized daily login times are appropriately weighted so that the closer the daily login time is to the current time, the stronger the influence on the derived evaluation 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 evaluation value increases.

[0078] The method of deriving the evaluation value shown in this embodiment is merely a simplified example. In other words, as long as an evaluation value that can be regarded as an index showing the contribution of the service derived from the user's behavior is ultimately derived, any method may be used to derive the evaluation value. For example, the server information processing unit 10 may be configured to derive the evaluation value by taking into account the specific behavior of the user 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. In addition, for example, 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, by the appropriateness of the content of the message. In addition, for example, it is determined by the appropriateness of the way of communicating with others in the group to which the user belongs. The appropriateness of the content of the message and the appropriateness of the way of communicating are determined, for example, by using AI technology.

[0079] The server information processing unit 10 has a function of granting a pool use ticket (electronic ticket) to a user. A user who owns a pool use ticket can perform the pool use event once by consuming one of the tickets. In other words, the pool use ticket functions as a right to acquire a child NFT in the pool PL. The server information processing unit 10 grants the pool use ticket to the 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. A user whose evaluation value is equal to or greater than a certain value corresponds to a user who has a high degree of contribution to the basic service (service).

[0080] As described above, the server information processing unit 10 has a function of preferentially granting the right to acquire child NFTs in the Pool PL to users who have contributed a large amount to the basic service (service) provided in the token economy. This configuration has the following effects. That is, by acquiring child NFTs, users can receive various benefits, as described below. In light of this, it is expected that users will proactively take actions that contribute to the basic service so that they have a chance of acquiring a pool use ticket. Such actions have the effect of revitalizing the basic service, and such actions revitalize the token economy.

[0081] The method of granting the pool use ticket to the user is not limited to the exemplified method. As an example, the group of users from which the user to be granted the ticket is 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 dating back to the present time. When selecting a user, the server information processing unit 10 may take into consideration whether the user has owned a child NFT in the past, 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 pool use ticket of the user. 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 matters necessary for managing the pool use ticket.

[0082] In addition, participants who register an account for the Service are given an internal address to be used in the Service, and an internal wallet associated with the internal address. The internal wallet is a wallet that can be used in 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, a public exchange, or other publicly available services. The internal wallet can manage at least the parent NFT, the child NFT, the GT, and the UT. The user's internal address is called the "user internal address," the user's internal wallet is called the "user internal wallet," the operator's internal address is called the "operator internal address," and the operator's internal wallet is called the "operator internal wallet."

[0083] In the following description using FIG. 11, it is assumed that the noted user has a pool use ticket. Referring to FIG. 11, the noted user starts the dedicated application AP of the user terminal 4, inputs login information, and logs in to the account of the present service. As shown in the flowchart FG, the noted user performs a necessary operation to instruct the consumption of 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 present pool PL (step SH1). Hereinafter, the child NFT selected here is referred to as the "selected child NFT". The server information processing unit 10 identifies the child NFTs remaining in the present 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 internal wallet of the noted user (step SH2). More specifically, the internal child NFT management database 47 is stored in the server storage unit 12. The internal child NFT management database 47 is a database that manages child NFTs. Note that storing an NFT in an internal wallet means that the corresponding internal address and the identification information of the NFT are managed in association with each other, and the NFT is managed by the internal wallet. In the internal child NFT management database 47, the identification information of the child NFT and the internal address that owns the child NFT are stored in association with each other for each child NFT stored in the internal wallet. Therefore, by referring to 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 and associates the identification information of the selected child NFT with the user internal address of the noted user. Furthermore, the server information processing unit 10 changes the in-pool flag of 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 in question. As a result, one of the child NFTs remaining in the Pool PL in question is transferred to the user's internal wallet of the noted user, and the noted user is now in a state of having acquired a child NFT in the service in question.

[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 pool PL to the user of interest has been completed (step SH3). In response to the 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 the user uses the pool PL to acquire a child NFT, there is no need to prepare an external wallet. A certain amount of knowledge is required to acquire an external wallet, and the work of acquiring the wallet is somewhat complicated. In light of this, in this embodiment, the user is provided with an opportunity to acquire a child NFT without preparing an external wallet, which is highly convenient for the user.

[0086] ● Cases where a user acquires a child NFT using this Market MK Next, a case where a user acquires a child NFT using the Market MK will be described. FIG. 12 is a flowchart showing the operation of the information processing system 1 in this case. Flowchart FI shows an information processing method by the user terminal 4, and flow chart FJ shows 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, the user needs to hold 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 holds a user external wallet.

[0087] The noted user starts the dedicated application AP of the user terminal 4, inputs login information, and logs in to the account of the service. Furthermore, the noted user connects his / her user external wallet to the service. As shown in the flowchart FI, the noted user performs the necessary operation to instruct the display of the selling child 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 required for displaying the selling child NFT list screen 48 to the user terminal information processing unit 18 (step SJ1). The information includes a value indicating rarity, a value indicating character attributes, stopped state image data, and selling price information for each child NFT on sale in the market MK. The server information processing unit 10 identifies the child NFT 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 sales child 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 sales child NFT list screen 48. As shown in FIG. 13, the sales child NFT list screen 48 displays a unit display area 49 for each child NFT 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 (including various data recorded in the metadata) of the corresponding child NFT. The unit display area 49 displays an image of the corresponding child NFT, information indicating the rarity, information indicating the selling price, and a purchase button 46. The attention user selects the purchase button 46 corresponding to the child NFT that he or she wishes to purchase (step SI4). Hereinafter, the child NFT corresponding to the selected purchase button 46 is referred to as a "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 holder to the noted user (step SJ2). In step SJ2, the server information processing unit 10 determines at least whether the noted user's Ether balance is equal to or greater than the selling price, and whether the seller 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 a corresponding error process (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 that the child NFT cannot be purchased on the user terminal display unit 20 together with information indicating the reason for the same.

[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). In detail, 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 of the metadata of the purchased child NFT to an off value. Furthermore, the server information processing unit 10 transfers the total revenue amount of Ether 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 the commission amount of Ether derived from the sales price from the user external address of the noted user to the operator external address. With the above, the purchase of the child NFT by the noted user is completed, and the noted user is in a state of having 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 purchase of the child NFT by the focused user has been completed (step SJ5). In response to the notification, the user terminal information processing unit 18 displays information 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. For this reason, holders are expected to actively take actions such as owning parent NFTs, issuing child NFTs, and transferring child NFTs to users using the platform. Such actions have the effect of encouraging the use or circulation of tokens in the token economy, and such actions revitalize the token economy.

[0093] The server information processing unit 10 also has a function of providing, as a platform, the Market MK (first platform) which realizes transactions of child NFTs between holders and users, with the holder as the seller and the user as the buyer, and the Pool PL (second platform) in which the holder provides child NFTs free of charge and the user acquires the child NFTs provided by the holder free of charge. This configuration provides the following effects. That is, the holder can sell the child NFT at a desired selling price using the Market MK. If the total revenue based on the selling price exceeds the necessary issuance costs, the holder can obtain economic benefits. In addition, the more users are active in the token economy, the higher the possibility that the child NFT will be purchased at a higher price and more stably. Therefore, it is expected that the holder will take actions to increase the number of users active in the token economy. If the number of users increases as a result of such actions, the token economy will be activated. On the other hand, the child NFTs sold by the holder in the Market MK are not necessarily sold at the desired selling price. In this embodiment, the server information processing unit 10 provides the present pool PL in addition to the present market MK. Therefore, even if the holder cannot sell the child NFT at the desired selling price, or even if it is assumed that the child NFT cannot be sold, the holder can provide the child NFT using the present pool PL and receive benefits. In other words, according to this embodiment, the holder can supply the child NFT he owns to the present pool PL in any case and receive benefits. Therefore, the holder can issue the child NFT without taking the risk of unsold child NFTs accumulating.

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

[0095] In addition, the user can use the Market MK to acquire the desired child NFT, taking into consideration the rarity, character attributes, and other matters related to the child NFT, on the condition that the user pays a price equivalent to the selling price. In addition, the user can use the Pool PL to acquire the child NFT free of charge, on the condition that the user acquires a pool use ticket. As described above, when granting the UT to a user who has won the Game, the server information processing unit 10 executes the following processing. That is, if the other conditions are the same, the server information processing unit 10 grants a larger amount of the UT when the user acquires the child NFT using the Market MK, compared to when the user acquires the child NFT using the Pool PL. Therefore, even if the user purchases a child NFT in 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 the 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 from the Pool PL and the Market MK.

[0097] Next, the operation of the information processing system 1 in a scene where a user changes a child NFT owned by the user from a suspended state to a valid state will be described. Hereinafter, changing to a valid state may be referred to as "activating". This scene corresponds to step F8 in FIG. 3. Here, when a user acquires a child NFT using the Market MK, the child NFT is stored in the user's user external wallet. When a user activates a child NFT, the child NFT must be stored in the user's internal wallet. In light of 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 the transfer using a predetermined user interface provided by the function of the dedicated app AP. When the instruction is received, 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 transfer 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 of the user terminal 4, enters login information, and logs in to the account of the service. As shown in the 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 that the instruction has been received (step SK2). In response to the notification, the server information processing unit 10 refers to 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). The 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 the 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 showing 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 the 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 (including various data recorded in the metadata) of the corresponding child NFT. As described above, the child NFT has one of the following statuses: suspended, enabled, and disabled. The user-owned child NFT list screen 50 displays the unit display area 51 for each child NFT stored in the user's internal wallet of the focused user, regardless of the 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 a child NFT in a valid state, and unit display area 51-4 is an area relating to a child NFT in an invalid state.

[0101] As shown in FIG. 15, the unit display areas 51-1 and 51-2 related to 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 a button that is operated when activating 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 an "activated child NFT." The user terminal information processing unit 18 notifies the server information processing unit 10 that the activation button 53 has been selected (step SK5). In response to the notification, the server information processing unit 10 executes an activation-related process (step SL2). In more detail, the server information processing unit 10 executes the following process regarding the metadata of the activated child NFT. That is, the server information processing unit 10 determines a fighting power value and sets the determined fighting power value to the fighting power <item>. The server information processing unit 10 randomly determines the fighting power value within a range of 20pt to 50pt when the rarity is rare, and randomly determines the fighting power value within a range of 10pt to 40pt when the rarity is common.

[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 uses a predetermined model to generate image data of an image of the valid state of the valid child NFT (hereinafter referred to as "valid state image data"). The image of the child NFT in the valid state is an image imitating a monster. Then, the server information processing unit 10 sets a predetermined URI to the valid state image <item>. Furthermore, the server information processing unit 10 stores the generated valid state image data in an area indicated by the predetermined URI. Furthermore, the server information processing unit 10 stores valid state transition date and time information indicating the current date and time in the valid state transition date and time <item>. In other words, the valid state transition date and time information is information indicating the date and time when the corresponding child NFT transitioned to the valid state. Through the above processing, the transition of the valid child NFT to the valid state is completed. After the processing of 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, on the user terminal display unit 20, information indicating that the activation has been completed.

[0103] 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 child NFT transitioned to a valid state. Below, focusing on one child NFT, the operation of the information processing system 1 in a scene where a valid child NFT transitions to an invalid state will be described. 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 the attention child NFT transitions from a stopped state to a valid state, the server information processing unit 10 monitors whether 90 days have passed, starting from 0:00 a.m. on the day following the day when the valid state was reached. The server information processing unit 10 may be configured to use another timing derived from the valid state as the starting point. When 90 days have passed, the server information processing unit 10 transitions the attention child NFT to an invalid state with a probability of 3.3% (just an example). In other words, at this stage, it is possible that the attention child NFT will not transition to an invalid state and will remain valid. When transitioning the attention child NFT to an invalid state, the server information processing unit 10 executes the following process for the metadata corresponding to the attention child NFT. That is, the server information processing unit 10 uses a predetermined model to generate invalid state image data that indicates an image of the child NFT in an invalid state. The server information processing unit 10 then sets a predetermined URI to the invalid state image <item> and stores the invalid state image data in the predetermined URI. Furthermore, the server information processing unit 10 changes the value of the status <item> to a value that indicates an invalid state. If the noted child NFT does not transition to an invalid state after 90 days have passed, the server information processing unit 10 transitions the noted child NFT to an invalid state with a probability of 3.3% after one more day has passed (i.e., 91 days after transition to a valid state). In this way, the server information processing unit 10 executes the process of transitioning to an invalid state with a probability of 3.3% every day until the transition to an invalid state is actually performed. By performing the above process, the noted child NFT transitions to an 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 a valid state to an invalid state when a certain period (validity period + α) has passed since the child NFT was made valid.

[0105] <Scene where user acquires game ticket> Next, the operation of the information processing system 1 in a scene where 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. The 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 or not 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 ends the process. In this case, the game ticket is not distributed to the user. In this way, only users who own a valid child NFT 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 an evaluation value of the user (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 or not 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 ends the process. In this case, the 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 the owner of the game ticket and other matters necessary for managing the pool use ticket. The game ticket corresponds to a benefit given to the user. As will be described later, the UT given to the user after the game played by consuming the game ticket also corresponds to a "benefit."

[0107] As described above, the server information processing unit 10 has a function of making the child NFT valid for a certain period of time after the user acquires the child NFT, and a function of granting a reward to the user according to the action of the user who owns the valid child NFT in the token economy. More specifically, the server information processing unit 10 has a function of making the child NFT valid in response to a request from the user who owns the child NFT, a function of transitioning the child NFT from a valid state to an invalid state when a certain period of time has passed since the child NFT was made valid, and a function of granting a reward to the user according to the action of the user who owns the valid child NFT in the token economy. This configuration provides the following effects. That is, the valid state of the child NFT does not continue forever, but only for a certain period of time. Therefore, the user has a motivation to actively engage in the basic service SV and obtain a game ticket while the child NFT is valid and the right to receive a game ticket is valid. Then, under this motivation, the user acts, and the basic service SV is activated, and 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 a privilege to a user who owns a child NFT in accordance with the behavior of the user 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 degree of contribution to the basic service SV based on the behavior of the user who owns the child NFT in the basic service SV, and granting a privilege when the evaluation value is a certain value or more. According to this configuration, it is assumed that the user will actively take actions to receive the privilege. When the user takes the action, the basic service SV is activated, and thus the token economy is activated. Note that the behavior of the user to which the privilege is granted is not limited. In particular, the server information processing unit 10 may be configured to grant a privilege to a user based on an action unrelated to the contribution to the basic service SV. In the present embodiment, the server information processing unit 10 is configured to determine the degree of contribution of the user to the service using the evaluation value. In this regard, the server information processing unit 10 may be configured to determine the degree of contribution using a method other than the method using the evaluation value. As an example, the server information processing unit 10 may be configured to determine the degree of contribution by the same unit as to 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 using an event other than the event of "establishment of the condition that the evaluation value is equal to or greater than a threshold" as a trigger.

[0109] <Scenes where users play the Game> Next, the operation of the information processing system 1 in a scene where 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 starts the dedicated application AP of the user terminal 4, inputs login information, and prepares for the game. The noted user logs in to an account for the service. The noted user then uses a predetermined user interface provided by the user terminal information processing unit 18 to prepare for the game. One aspect of the preparation for the game is forming a party. A party is a combination of one to three valid child NFTs to be used in the game. The noted user uses a predetermined user interface to select one to three valid child NFTs from the valid child NFTs he or she owns, and forms a party. The predetermined user interface displays a list of information on the valid child NFTs owned by the noted user. The user interface is also configured to allow any child NFT to be selected from the listed child NFTs as a child NFT to be included in the party.

[0111] Referring to FIG. 17, the user of interest instructs to start the game (step SN1). The user terminal information processing unit 18 notifies the server information processing unit 10 that the instruction has been received (step SN2). The server information processing unit 10 refers to the internal child NFT management database 47 and other data related to the game, and transmits information required 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 the child NFT belonging to the party, valid state image data, a fighting power value, and a value indicating character attributes. The information transmitted by the server information processing unit 10 also includes, for the “enemy”, image data of the enemy, a fighting power value, and a value indicating character attributes. The server information processing unit 10 generates image data of the enemy, or selects 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 of the game screen 55. As shown in FIG. 18, the game screen 55 displays an image of the effective state, information indicating the fighting power, and information indicating the character attribute for each child NFT belonging to the party. The game screen 55 also displays an image, fighting power, and character attribute for the enemy. In the present 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 the child NFT wins the battle between the child NFT and the enemy, the victory of the noted user is determined, and the present game ends at that point. On the other hand, if all the child NFTs belonging to the party are defeated by the enemy, the defeat of the noted user is determined, and the present game ends. With respect to the battle between one child NFT and the enemy, the user terminal information processing unit 18 comprehensively reflects the fighting power and character attribute of the child NFT and the fighting power and character attribute of the enemy, and further reflects random elements, and determines the victory or defeat of the battle. That is, the server information processing unit 10 determines the outcome of the battle in a manner such that the greater the combat power of the child NFT is in relation to the combat power of the enemy, 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 including a performance of a battle between a child NFT included in the party and an enemy on the game screen 55.

[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 exemplified content. For example, other parameters exist instead of or in addition to fighting power or character attributes. The content of the game may be such that the other parameters are reflected to determine victory or defeat. The other parameters are, for example, stamina, defensive power, or speed. Also, for example, the game may be configured such that a user's operation is accepted while the game is being played, and the operation affects victory or defeat. That is, the items exemplified in this embodiment with respect to parameters are merely examples, and the types of parameters are not limited to the exemplified content. Also, when focusing on a certain parameter, the range of values ​​that the parameter can take, the upper limit, the lower limit, and other parameter-related elements are not limited to the exemplified content. As an example, in a case where fighting power is adopted in the game (naturally, it does not have to be adopted), the range of fighting power that the fighting power can take, the upper limit, the lower limit, the timing of change, the factors that change, etc. are not limited to the exemplified content in this embodiment.

[0114] After the game ends, the user terminal information processing unit 18 notifies the server information processing unit 10 of the outcome (step SN4). In response to the notification, the server information processing unit 10 derives the amount of the UT to be granted to the user of interest as a bonus (step SO2). Hereinafter, the amount of the 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 formula S1. Formula S1: Individual amount = Reference amount x Win / Loss coefficient x Pool related coefficient Here, the reference amount is a fixed amount that is determined in advance. The winning / losing coefficient is a coefficient for reflecting the winning / losing of the game in the individual amount. The winning / losing coefficient is set so that the individual amount is larger when the player wins than when the player loses. The winning / losing 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 by using the pool PL in this case. The pool-related coefficient is set so that the individual amount is larger when the pool PL in this case is not used than when the pool PL in this case is used. The pool-related coefficient is "1.0" when the pool PL in this case is not used, and "0.1" when the pool PL in this case is used. For example, assume that one child NFT was acquired by using the pool PL in this case. Also assume that the reference amount is "1000UT" and that the game is won. In this case, the individual amount of the one child NFT is "100UT" (1000 x 1.0 x 0.1 = 100). After deriving the individual amount 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 of 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 any method that satisfies the following conditions. - All other conditions being equal, the winner of the Game will receive a greater number of tokens. For a given Child NFT, if that Child NFT is acquired using the Market MK, the amount of tokens granted will be greater than if that Child NFT is acquired using the Pool PL. In addition, the server information processing unit 10 may be configured to reflect other elements in deriving the amount of tokens to be granted. The other elements 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 the granted tokens from the operator's internal wallet to the user internal wallet of the noted user (step SO3). More specifically, the server storage unit 12 stores the internal UT management database 56. The database records the balance of the present UT for each internal address, transactions (including deposits and transfers) conducted regarding the present UT, 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, increases the balance of the present UT for the internal address of the noted user by the amount of granted tokens, and decreases the balance of the internal address of the operator by the amount of granted tokens. This completes the granting of the present UT for the amount of granted tokens to the user internal wallet of the noted user. The server information processing unit 10 may be configured to newly issue the 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 locking period of 50 hours, the noted user cannot consume the locked present UT during the locking period, and cannot transfer the locked present UT to a user external wallet. 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 situations related to the present UT. Also, in this configuration, the server information processing unit 10 appropriately updates the internal UT management database 56 to manage the situation related to 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 noted user 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 a privilege to a user in accordance with the actions of the user who owns the child NFT in the token economy. In this embodiment, the "action in the token economy" includes the activity in the basic service that led to the receipt of the game ticket, and the privilege includes the game ticket. The "action in the token economy" includes the action of playing the game by consuming the game ticket, and the privilege includes the UT granted as a result of the game. Due to the above configuration, it is assumed that the user will actively take actions to receive the privilege. This action activates the token economy. In addition, the server information processing unit 10 has a function of granting the UT, which can be used in the token economy and traded on a public exchange, as a privilege in accordance with the actions of the user who owns the child NFT in the token economy. In this way, objects with high utility value and economic value are granted to the user as a privilege, so that the user's satisfaction is high. Furthermore, an incentive can be given to the user to be active in the basic service in order to get the token ticket. The server information processing unit 10 may be configured to grant a user an FT that can be used in the token economy but cannot be traded in the public market as a privilege, instead of or in addition to the UT. The server information processing unit 10 may be configured to grant a target other than an FT to the user as a privilege. In this configuration, the target may be, for example, points that can be used in the service, points that are generally used as a point program, 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] In addition, the server information processing unit 10 has a function of increasing the amount of the UT (amount of benefit) when the child NFT is acquired using the Market MK (first platform) in accordance with the behavior of the user who owns the child NFT in the token economic sphere, compared to when the child NFT is acquired using the Pool PL (second platform). With this configuration, an incentive can be given to the user to actively use the Market MK in question. The token economic sphere in question is activated by the active use of the Market MK in question. In this embodiment, the server information processing unit 10 adjusts the amount of benefit when the Market MK in question is used and when the Pool PL in question is used. In this regard, the server information processing unit 10 may be configured to adjust the quality of the benefit, or adjust the amount and quality of the benefit. As an example, when the server information processing unit 10 grants an item that can be used in a predetermined service as a benefit, an item with a higher rarity is granted when the Market MK in question is used than when the Pool PL in question is used.

[0120] In addition, in this embodiment, the more child NFTs included in the party, the more UT the user can obtain after playing the game. Based on this, the user is motivated to collect many child NFTs in a valid state. In addition, since the user has a higher probability of winning the game if he or she has child NFTs with various character attributes, the user is motivated to obtain child NFTs with various character attributes. Based on these motivations, it is assumed that the user will actively take actions to obtain child NFTs. This action activates the economic sphere. In addition, in the game, the rarity and character attributes of the child NFT affect the probability of winning the game. The reason why rarity has an effect is because the upper limit value of the combat power value changes depending on the rarity. In addition, when using the market MK, the user can select a child NFT taking into consideration the rarity and character attributes, which is highly convenient for the user.

[0121] <Scenes where users use this UT> Next, the operation of the information processing system 1 in a scene where the user uses the UT of the present case will be described. This scene corresponds to step F14 in FIG. 3. The user can consume the UT of the present case stored in his / her internal user wallet to challenge an event that improves the combat power of a desired child NFT. In detail, the user uses the user interface provided by the user terminal information processing unit 18 to give the following instruction. That is, the user designates one of the valid child NFTs stored in his / her internal user wallet. The user then instructs the server information processing unit 10 to consume a certain amount of the UT of the present case to challenge an event that increases the combat power of the designated child NFT. The user terminal information processing unit 18 notifies the server information processing unit 10 that the instruction has been given. In response to the 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 will not exceed the upper limit. The upper limit of rare is 100 points, and the upper limit of common is 80 points. As mentioned above, the upper limit values ​​shown here are merely examples. The server information processing unit 10 appropriately executes the process of transferring a certain amount of the present UT, the process of reflecting the increase in the fighting 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, he or she can obtain more UT than if the user loses. This motivates users to use the UT they have obtained to increase the combat power of their Child NFTs. With this motivation, it is expected that users will proactively take actions that lead to obtaining game tickets, and when they obtain game tickets, they will actively play the Game. Users' actions in this way will promote the revitalization of the Token economy.

[0123] Furthermore, the user can use the UT he or she owns for transactions at a public exchange. As an example, the user can exchange the UT for legal tender, crypto assets, and other values ​​at a public exchange. However, when trading the UT at a public exchange, the user must transfer the UT from his or her own user internal wallet to a user external 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 user internal wallet to the user external wallet. When the 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 of the external wallet, and executes other necessary processes.

[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 acquires Ether when issuing Child NFTs, acquires Ether in response to transactions in the Market MK, and acquires UT in response to the consumption of the UT by Users. 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 one 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] Also, a configuration may be adopted in which a browser (including a program associated with the browser) realizes some or all of the functions of the dedicated application AP. In this configuration, when using the functions of the browser, the holder terminal information processing unit 13 appropriately transmits a request to the server information processing unit 10 and receives a response. In particular, when displaying various screens, the holder terminal information processing unit 13 transmits a request to the server information processing unit 10, receives an HTML file from the server information processing unit 10, and displays the screen based on the HTML file. In addition, in the above embodiment, a specific example of the screen is shown, but the contents of the screen are not limited to the exemplified contents. In addition, in the above embodiment and the modified example, the information processing server 2 is configured to include a storage unit (server storage unit 12). In this regard, 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 appropriately access the other device. In addition, the functional blocks shown in the above embodiment can be realized by any hardware, or by cooperation between any hardware and any software. In other words, these functional blocks are not limited to specific hardware. In addition, the processing units of the flowcharts shown in the figures are divided according to the main processing contents in order to make the processing easier to understand. The present invention is not limited by the way in which the processing units are divided or by their names. The processing of each device can be further divided into more processing units depending on the processing content. Also, one processing unit can be divided so as to include more processing. Also, as long as similar processing can be performed, the processing order of the above flowchart is not limited to the example shown. Also, for example, the information processing server 2 does not need to be a single device. When 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] Further, for example, the embodiment may include the provision of a program executed by the computers of the information processing server 2, the holder terminal 3, and the user terminal 4, or the provision of a recording medium on which the program is recorded so as to be readable by the computer. The recording medium may be a magnetic or optical recording medium or a semiconductor memory device. Specific examples of the recording medium include portable or fixed recording media such as flexible disks, HDDs (Hard Disk Drives), 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] Also, for example, in this embodiment, the server information processing unit 10 is configured to grant a game ticket to the user as a privilege, and grant the UT after the game based on the game ticket. In this regard, the server information processing unit 10 may be configured to grant the UT to the user who owns the child NFT instead of the game ticket. In this case, the game will not be played. In this configuration, in the case of a child NFT acquired using the market MK, the server information processing unit 10 grants a larger amount of UT than when the child NFT is acquired using the pool PL.

[0130] Also, for example, in this 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. [Explanation of symbols]

[0131] 1. Information Processing Systems 2. Information processing server 3 Holder terminal 4. User terminal 10 Server information processing unit (information processing unit) PF Transition Platform (Platform) MK This Market (First Platform) PL This Pool (2nd Platform)

Claims

1. An information processing device that executes processing related to a token economy, A function of determining whether or not the holder currently owns a first type of NFT (Non-Fungible Token) in response to a request from the holder, and if the holder does own a first type of NFT, issuing a second type of NFT different from the first type to the holder; providing a platform for transferring the second type of NFT from the holder to a user; and an information processing unit having a function of granting a reward to the user in accordance with the user's actions in the token economy who owns the second type of NFT.

23. An information processing apparatus comprising:

2. The information processing unit includes: The platform has a function of providing a first platform that realizes transactions of the second type of NFT between the holder and the user, with the holder as a seller and the user as a buyer.

2. The information processing apparatus according to claim 1,

3. The information processing unit includes: The platform has a function of providing a second platform on 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.

2. The information processing apparatus according to claim 1,

4. The information processing unit includes: a first platform that realizes a transaction of the second type of NFT between the holder and the user, with the holder as a seller and the user as a buyer; and a second platform on 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.

2. The information processing apparatus according to claim 1,

5. The information processing unit includes: A function of preferentially granting the right to acquire the second type of NFT on the second platform to the users who have contributed more to the services provided in the token economy.

5. The information processing apparatus according to claim 3, wherein the information processing apparatus is a computer.

6. The information processing unit includes: The second platform is provided with a function of providing a reward to the holder who provides the second type of NFT.

5. The information processing apparatus according to claim 3, wherein the information processing apparatus is a computer.

7. The information processing unit includes: The second platform is provided with a function of granting a Fungible Token (FT) that can be used in the token economy as a privilege to the holder who provides the second type of NFT using the second platform.

7. The information processing apparatus according to claim 6,

8. The information processing unit includes: The second platform is provided with a function of granting the holder who provides the second type of NFT a privilege of the FT that is available in the token economy and can be traded on a publicly open exchange.

8. The information processing apparatus according to claim 7,

9. The information processing unit includes: When granting a reward in accordance with the user's actions in the token economy who owns the second type of NFT, the reward is improved in quality or quantity in a case where the second type of NFT is acquired using the first platform compared to a case where the second type of NFT is acquired using the second platform.

5. The information processing apparatus according to claim 4.

10. The information processing unit includes: A function of making the second type of NFT valid for a certain period of time after the user acquires the second type of NFT; and a function of granting a reward to the user in accordance with the user's actions in the token economy who owns the second type of NFT in the valid state.

2. The information processing apparatus according to claim 1,

11. a function of validating the second type of NFT 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 set to the valid state; and a function of granting a reward to the user in accordance with the user's actions in the token economy who owns the second type of NFT in the valid state.

11. The information processing apparatus according to claim 10,

12. The information processing unit includes: A function of granting a reward to the user who owns the second type of NFT in accordance with the behavior of the user in the service provided in the token economy.

2. The information processing apparatus according to claim 1,

13. The information processing unit includes: A function of deriving an evaluation value indicating a 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 privilege when the evaluation value is equal to or greater than a certain value.

13. The information processing apparatus according to claim 12.

14. The information processing unit includes: and a function of prohibiting issuance of the second type of NFT based on the first type of NFT for a certain period of time after issuing the second type of NFT in response to a request from the holder who owns the first type of NFT.

2. The information processing apparatus according to claim 1,

15. The information processing unit includes: The device has a function of granting FTs that can be used in the token economy as a reward in response to actions in the token economy by the user who owns the second type of NFT.

2. The information processing apparatus according to claim 1,

16. The information processing unit includes: The system has a function of granting the FT that is available in the token economy and can be traded on a publicly open exchange as a reward in response to actions in the token economy by the user who owns the second type of NFT.

16. The information processing apparatus according to claim 15,

17. An information processing system for performing processing related to a token economy, A function of determining whether or not the holder currently owns a first type of NFT (Non-Fungible Token) in response to a request from the holder, and if the holder does own a first type of NFT, issuing a second type of NFT different from the first type to the holder; providing a platform for transferring the second type of NFT from the holder to a user; and an information processing unit having a function of granting a reward to the user in accordance with the user's actions in the token economy who owns the second type of NFT. An information processing system comprising:

18. An information processing method by an information processing device that executes processing related to a token economy, An information processing unit of the information processing device, in response to a request from the holder, determines whether the holder currently owns a first type of NFT (Non-Fungible Token), and if the holder does own a first type of NFT, issues a second type of NFT different from the first type to the holder; 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; The information processing unit of the information processing device grants a reward to the user who owns the second type of NFT in accordance with the user's behavior in the token economy.

23. An information processing method comprising:

Images