Program, information processing method, and information processing apparatus

Abstract

To provide a program which allows for preferable use of information of non-fungible tokens which are issued by a plurality of issuers or are issued through a plurality of issue routes by the issuers.SOLUTION: The program causes a computer to execute processing of: collecting data of non-fungible or semi-fungible tokens issued to a wallet of a user from a plurality of issuers and recorded in a block chain or the tokens issued to the wallet of the user through a plurality of issue routes from the issuers; and performing prescribed processing on the basis of the collected data.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a program, an information processing method, and an information processing device. [Background technology]

[0002] Systems and services using non-fungible tokens, such as non-fungible tokens (NFTs), have been proposed based on blockchain technology. For example, Patent Document 1 discloses an information processing system that grants a non-fungible token to a user's wallet as a privilege when a combination of multiple non-fungible tokens currently or previously granted to the user's wallet satisfies a predetermined condition. [Prior art documents] [Patent documents]

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

[0004] In one aspect, an object of the present invention is to provide a program, etc. that can make suitable use of information on non-fungible tokens issued by multiple issuers or by an issuer through multiple issuance routes. [Means for solving the problem]

[0005] In one aspect, the program causes a computer to execute a process of collecting data regarding non-fungible or semi-fungible tokens recorded in a blockchain that have been issued to a user's wallet by each of a plurality of issuers, or the tokens that have been issued to a user's wallet by an issuer via each of a plurality of issuance routes, and performing a predetermined process based on the collected data. Effect of the Invention

[0006] In one aspect, information on non-fungible tokens issued by multiple issuers or by an issuer through multiple issuance routes can be suitably utilized. [Brief description of the drawings]

[0007] [Figure 1] An explanatory diagram showing an example of the configuration of an NFT management system. [Diagram 2] FIG. 2 is a block diagram showing an example of the configuration of a server. [Diagram 3] FIG. 1 is an explanatory diagram showing an example of the record layout of a user DB, a token DB, an issuer DB, a channel DB, a contract DB, and a mission DB. [Figure 4] FIG. 2 is a block diagram showing a configuration example of a terminal. [Diagram 5] FIG. 1 is an explanatory diagram showing an overview of a first embodiment. [Figure 6] FIG. 2 is an explanatory diagram showing an example of a display screen of a terminal. [Figure 7] 13 is a flowchart showing a procedure for data collection processing. [Figure 8] 13 is a flowchart showing the steps of an NFT usage process. [Figure 9] FIG. 11 is an explanatory diagram showing an overview of a second embodiment. [Figure 10] FIG. 11 is an explanatory diagram showing an overview of a third embodiment. [Figure 11] 13 is a flowchart showing a procedure for wallet registration processing. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The present invention will now be described in detail with reference to the drawings showing embodiments thereof. (Embodiment 1) FIG. 1 is an explanatory diagram showing a configuration example of an NFT management system. In this embodiment, an NFT management system is described that collects data related to NFTs issued to users by multiple issuers or issued to users via multiple issuance routes (hereinafter referred to as "channels") by issuers, and executes a predetermined process (for example, a process related to a loyalty program described later) based on the collected data. The NFT management system includes an information processing device 1, terminals 2, 2, 2..., issuer servers 3, 3, 3..., and a blockchain network 4 consisting of multiple nodes 40. Each device is communicatively connected via a network N such as the Internet.

[0009] In this embodiment, the token issued to the user is described as an NFT, but the token issued to the user is not limited to one called an NFT, and may be any non-fungible token recorded on the blockchain.

[0010] In addition, although this embodiment will be described as issuing a non-fungible token to a user, the token issued to a user may be a semi-fungible token that has the functions of both a Fungible Token (FT) and an NFT.

[0011] Also, although not specifically mentioned below, an NFT may be issued by an issuer to a user (with the issuer paying the so-called gas fee), or an NFT prepared by an issuer may be issued by a user (with the user paying the gas fee). In either case, this embodiment defines it as an "NFT issued by an issuer to a user."

[0012] In this embodiment, a loyalty program (hereinafter also referred to as "mission") that utilizes NFTs is provided to users. For example, if an NFT issuer is a restaurant, NFTs are distributed (issued) to users' wallets instead of stamps when they visit the restaurant, and users can collect NFTs and use them when visiting the restaurant to receive benefits such as discounts on food and drink prices or the provision of food and drink.

[0013] When providing such a loyalty program, consider the case where multiple businesses participate in the program and each business issues NFTs. In this case, if there is no mechanism for obtaining or using information on the NFTs issued by each business, only a portion of the data can be taken into account in the program, limiting the effectiveness of the program.

[0014] Even if a single business provides a loyalty program, it is conceivable that NFTs may be distributed through various channels, such as directly at offline stores, or online via EC (Electronic Commerce) sites, SNS (Social Networking Services), online communities, metaverses, etc. Even in this case, the information on the NFTs distributed through each channel must be linked, resulting in high management costs.

[0015] Therefore, in this embodiment, data on NFTs issued by each issuer (business operator) or issued by an issuer through each channel is collected and managed in a centralized manner. The collected data is then used to execute a predetermined process. The "predetermined process" refers to a process for determining whether or not the NFT held by the user satisfies a predetermined condition for use in order to implement the above-mentioned loyalty program, but may also be a process for verifying the ownership of the NFT held by the user, or a process for analyzing the collected data.

[0016] The information processing device 1 is an information processing device capable of various information processing and sending and receiving information, such as a server computer, a personal computer, etc. In this embodiment, the information processing device 1 is a server computer, and for simplicity, will be referred to as the server 1 below. The server 1 functions as a management device that manages this system, and collectively manages the data of NFTs issued by each issuer on each channel.

[0017] Terminal 2 is a terminal device owned by each user, such as a smartphone, a personal computer, or a tablet terminal. For example, an application program dedicated to this system (hereinafter referred to as "this app") and a wallet application for receiving NFTs (hereinafter referred to as "wallet app") are installed on terminal 2. Terminal 2 receives NFTs through the wallet app, and can use the NFTs received through the wallet app by executing this app that synchronizes with the wallet app.

[0018] In this embodiment, the processes are executed by dedicated applications (this application and wallet application), but the present embodiment is not limited to this, and the processes may be executed by a Web application.

[0019] The issuer server 3 is a server computer of a business that issues NFTs. Each issuer server 3 issues NFTs to the wallets of users.

[0020] In this embodiment, the issuer server 3 is described as issuing the NFT, but this embodiment is not limited to this, and the NFT may be issued from the user's terminal 2.

[0021] The blockchain network 4 is a network consisting of multiple nodes 40, and manages a blockchain that records NFT transaction history. Each node 40 functions as a miner that verifies NFT transaction data, and shares NFT transaction data (on-chain data) with other nodes 40 through P2P (Peer to Peer) communication.

[0022] 2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a main storage unit 12, a communication unit 13, and an auxiliary storage unit . The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), etc., and performs various information processing, control processing, etc. by reading and executing a program P1 stored in the auxiliary storage unit 14. The main storage unit 12 is a temporary storage area such as an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory), and temporarily stores data required for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing processing related to communication, and transmits and receives information to and from the outside.

[0023] The auxiliary storage unit 14 is a non-volatile storage area such as a large-capacity memory or a hard disk, and stores a program P1 (program product) and other data necessary for the control unit 11 to execute processing. The auxiliary storage unit 14 also stores a user DB141, a token DB142, an issuer DB143, a channel DB144, a contract DB145, and a mission DB146. The user DB141 is a database that stores information on users of the system. The token DB142 is a database that stores information on NFTs (tokens) issued to user wallets. The issuer DB143 is a database that stores information on each issuer. The channel DB144 is a database that stores information on each channel that issues NFTs. The contract DB145 is a database that stores information on smart contracts for NFTs. The mission DB146 is a database that stores information on each mission.

[0024] The auxiliary storage unit 14 may be an external storage device connected to the server 1. The server 1 may be a multi-computer consisting of a plurality of computers, or may be a virtual machine virtually constructed by software.

[0025] In the present embodiment, the server 1 is not limited to the above configuration, and may include, for example, an input unit for accepting operation input, a display unit for displaying images, etc. The server 1 may also include a reading unit for reading a portable storage medium 1a such as a CD (Compact Disk)-ROM or a DVD (Digital Versatile Disc)-ROM, and may read and execute the program P1 from the portable storage medium 1a.

[0026] FIG. 3 is an explanatory diagram showing an example of the record layout of the user DB 141, the token DB 142, the issuer DB 143, the channel DB 144, the contract DB 145, and the mission DB 146.

[0027] The user DB 141 includes a user ID column, a user name column, a wallet address column, and a user information column. The user ID column stores a user ID for identifying each user. The user name column, the wallet address column, and the user information column store a user name, a user's wallet address, and other user information in association with the user ID, respectively. The user information includes information such as a user's email address, purchase data, and behavior data.

[0028] The token DB142 includes a token ID column, a type column, an issuer column, a channel column, an issuing user column, a holder user column, and an NFT information column. The token ID column stores a token ID for identifying each NFT. The type column, the issuer column, the channel column, the issuing user column, the holder user column, and the NFT information column each include, in association with a token ID, the type of NFT, the issuer name that issued the NFT, the channel name that issued the NFT, the wallet address of the user who received the NFT, the wallet address of the user who currently holds the NFT, and other NFT information. The NFT information includes, for example, the name of the NFT, a description, an image URL (Uniform Resource Locator), related links, a contract address, the type of the corresponding blockchain, the creation (issuance) date and time, the issuance serial number, the corresponding brand (issuer), the transfer history of the NFT, and the issuance status of the NFT (issued / not issued, locked / not locked).

[0029] The issuer DB143 includes an issuer ID column, an issuer name column, a contract ID column, and an issuer information column. The issuer ID column stores an issuer ID for identifying each issuer. The issuer name column, the contract ID column, and the issuer information column store an issuer name, a contract ID for identifying a smart contract corresponding to each type of NFT issued by the issuer, and other issuer information. The issuer information includes, for example, information such as the name, description, and category of the issuer (brand).

[0030] The channel DB 144 includes a channel ID column, a channel name column, and a channel information column. The channel ID column stores a channel ID for identifying each channel. The channel name column and the channel information column store a channel name and other channel information in association with the channel ID. The channel information includes information such as the corresponding brand (issuer).

[0031] The contract DB 145 includes a contract ID column and a contract address column. The contract ID column stores a contract ID for identifying each smart contract. The contract address column stores the contract address of the smart contract in association with the contract ID.

[0032] The mission DB 146 includes a mission ID column, a mission name column, a condition for achievement column, and a mission information column. The mission ID column stores a mission ID for identifying each mission. The mission name column, the condition for achievement column, and the mission information column store the mission name, the condition for achievement of the mission, and other mission information in association with the mission ID. The mission information includes, for example, basic information about the mission (such as a mission description and implementation period).

[0033] 4 is a block diagram showing an example of the configuration of the terminal 2. The terminal 2 includes a control unit 21, a main memory unit 22, a communication unit 23, a display unit 24, an input unit 25, and an auxiliary memory unit . The control unit 21 has one or more processors such as CPUs, and performs various information processing by reading and executing a program P2 stored in the auxiliary storage unit 26. The main storage unit 22 is a temporary storage area such as RAM, and temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The communication unit 23 is a communication module for performing processing related to communication, and transmits and receives information to and from the outside. The display unit 24 is a display screen such as a liquid crystal display, and displays images. The input unit 25 is an operation interface such as a touch panel, and accepts operation input from the user.

[0034] The auxiliary storage unit 26 is a non-volatile storage area such as a hard disk, and stores a program P2 (program product) and other data necessary for the control unit 21 to execute processing. The auxiliary storage unit 26 also stores a wallet app A. The wallet app A is an application program that holds the user's private key and is an application that manages NFTs held by the user.

[0035] The terminal 2 may include a reading unit for reading a portable storage medium 2a such as a CD-ROM, and may read and execute the program P2 from the portable storage medium 2a.

[0036] FIG. 5 is an explanatory diagram showing an overview of the first embodiment. FIG. 5 illustrates how data related to NFTs is collected from the blockchain and how data related to NFTs is collected by off-chain data linkage with the issuer. The overview of this embodiment will be described based on FIG. 5.

[0037] As described above, the issuer server 3 of each issuer issues (distributes) NFTs to user wallets through each channel. For example, when an NFT is issued, the server 1 obtains basic NFT information about the NFT from the issuer server 3 (or the terminal 2).

[0038] The NFT information includes at least the contract address of the NFT. Based on the contract address, the server 1 collects data related to the NFT from the blockchain managed by the blockchain network 4. The data includes, for example, information such as the wallet address of the user who currently holds the NFT, the transfer history of the NFT, and the issuance status. The server 1 calls variables and functions of the smart contract based on the contract address and directly references the on-chain data.

[0039] In this embodiment, the server 1 is described as actively and directly referring to on-chain data, but the embodiment is not limited to this, and the server 1 may refer to an event (e.g., transfer of NFT) output when a smart contract is executed. In other words, the server 1 may wait for an event to occur and acquire data when the event occurs as a trigger.

[0040] In addition, the server 1 performs off-chain data exchange with the issuer server 3 to obtain data related to the NFT. The data includes, for example, information such as the issuer's identifier of the user who received the NFT, an email address, and behavioral data. In addition, the server 1 obtains the user's purchasing data, etc. For example, the server 1 transmits data including the user's wallet address, etc. to the issuer server 3 and requests the output of various data.

[0041] The server 1 stores the various data collected above in each database. When a request is received from the user's terminal 2, the server 1 outputs information about the NFTs held by the user to the terminal 2 and displays it.

[0042] FIG. 6 is an explanatory diagram showing an example of a display screen of the terminal 2. FIG. 6A shows an example of a display screen showing the progress of missions for each issuer (brand) and channel. FIG. 6B shows another example of a screen showing the progress of missions. For example, as shown in the center of the screen of FIG. 6A, the terminal 2 displays icons (circles) corresponding to each issuer and channel in different display modes depending on whether the missions can be completed or not (in FIG. 6A, the different display modes are shown by solid and dotted circles). In addition, when an individual issuer (brand) is selected, the terminal 2 displays a list of the number of NFTs required to complete each mission, as shown in FIG. 6B. In this way, the server 1 outputs information on the NFTs held by the user to the terminal 2 based on the data collected above, and displays the progress of missions, etc. in a list.

[0043] The server 1 accepts a request for granting a reward, i.e., a request to use an NFT, from the terminal 2. When a request to use an NFT is accepted, the server 1 determines whether or not the NFT held by the user satisfies predetermined conditions of use (conditions for accomplishing a mission). If it is determined that the conditions of use are met, the server 1 grants a reward to the user.

[0044] In addition, when server 1 receives an inquiry from outside (e.g., issuer server 3), it simply outputs the result of determining whether the NFT held by the user meets the conditions, and the granting of benefits may be performed by someone other than server 1 (e.g., issuer server 3).

[0045] As described above, in this embodiment, even if multiple issuers issue NFTs through multiple channels, data regarding the NFTs issued by each issuer and channel can be managed centrally, and it is possible to determine whether or not the mission corresponding to each issuer and channel can be accomplished.

[0046] In this embodiment, a form of providing a loyalty program to a user has been described, but this embodiment is not limited to this, and the system may be used for data analysis such as visualization of customer behavior data, analysis of customer loyalty, implementation of marketing measures, etc. Since the system holds data across issuers (brands) and channels, it is also useful for analyzing such data.

[0047] It is also possible to provide specific data to existing systems owned by brands (issuers) using the results of aggregating on-chain and off-chain data. For example, by providing the aggregation results to an existing system, data such as "whether a user has NFTs (on-chain data) of A, B, and C, and has a purchase history (off-chain data) for product D," it can be used as a condition for purchases or voting on an e-commerce site or community site.

[0048] In this way, server 1 only needs to be able to perform a specified process based on the collected data, and this "specified process" is not limited to determining whether or not the mission has been accomplished, but may also be analysis of the collected data or proof of ownership of an NFT, etc.

[0049] Fig. 7 is a flowchart showing the procedure of the data collection process. The process for collecting data related to the NFT issued to the user's wallet will be described with reference to Fig. 7. Note that the description will be given assuming that the NFT has already been issued to the user's wallet. The control unit 11 of the server 1 acquires NFT information including at least a contract address for an NFT issued to a user's wallet (step S11). For example, the control unit 11 may acquire the NFT information from the user's terminal 2, or may acquire the NFT information from the associated issuer server 3.

[0050] The control unit 11 of the server 1 collects data related to the NFT from the blockchain based on the contract address of the NFT included in the NFT information acquired in step S11 (step S12). Specifically, the control unit 11 collects data such as the wallet address of the user who currently holds the NFT, the transfer history of the NFT, and the issuance status.

[0051] The control unit 11 collects data related to the NFT off-chain from the issuer server 3 (step S13). Specifically, the control unit 11 collects the issuer's identifier, email address, purchase data, behavioral data, etc. of the user who received the NFT. The control unit 11 stores the data acquired in steps S11 to S13 in each database (step S14) and ends the series of processes.

[0052] Fig. 8 is a flowchart showing the procedure of the NFT usage process. The process content when a user uses an NFT to receive a benefit will be described with reference to Fig. 8. In response to a request from the terminal 2, the control unit 11 of the server 1 outputs information on the NFTs held by the user for each issuer and channel (issuance route) to the terminal 2 and displays it (step S31). The control unit 11 accepts a request to use the NFT (step S32).

[0053] The control unit 11 determines whether the NFT held by the user satisfies a predetermined condition for use (step S33). If it is determined that the condition for use is met (S33: YES), the control unit 11 grants a benefit to the user (step S34). After executing the process of step S34, or if the result of step S33 is NO, the control unit 11 ends the series of processes.

[0054] As described above, according to this first embodiment, it is possible to suitably utilize information on NFTs issued by multiple issuers or issued by an issuer through multiple channels.

[0055] (Embodiment 2) In this embodiment, a form for preventing reuse of an NFT that has already been used will be described. Note that the same reference numerals will be used to designate the same contents as in the first embodiment, and the description thereof will be omitted.

[0056] As described in the first embodiment, a user can achieve a mission and obtain a reward by using an NFT issued by an issuer. However, due to its characteristics, an NFT can be transferred to another wallet. Therefore, if no measures are taken, there is a problem that after completing a mission in a wallet, the user can transfer the NFT to another wallet and clear the mission again. In particular, when an NFT is issued by multiple issuers or channels, it is difficult to consider this problem in advance at the time of issuing the NFT, so it is necessary to be able to take measures against this later.

[0057] Therefore, in this embodiment, such reuse (transfer) of NFTs is prevented. There are several methods for preventing reuse of NFTs. These methods are described below.

[0058] Fig. 9 is an explanatory diagram showing an overview of the embodiment 2. Fig. 9 shows a summary of the method for preventing reuse of an NFT.

[0059] The first method is to issue non-transferable NFTs to users, making the NFT non-transferable in the first place and using only the interoperability of NFTs. Non-transferable NFTs include SBT (Soul Bound Token) and NTT (Non-Transferable Non-Fungible Token). By issuing non-transferable NFTs such as SBT and NTT, the above problem can be solved.

[0060] As a second method, although the NFT is initially in a transferable state, a flag is prepared in the NFT smart contract, and if certain conditions are met, the flag is changed to make the NFT non-transferable (the Transfer function of the smart contract is disabled). "Certain conditions" could be whether or not the NFT has already been used in a mission. When a request to use an NFT is received from a user and the NFT has been used in a mission, the server 1 changes the flag of the smart contract for that NFT and disables the Transfer function. This makes it impossible to transfer an NFT that has already been used in a mission, and solves the above problem.

[0061] In addition, in cases where a user has multiple wallets that are associated with each other, as described below in embodiment 3, NFTs may be transferable only to specific wallets, such as associated wallets, and not to other wallets.

[0062] In addition, if a user has more NFTs than are necessary to complete a mission, it is possible to design the system so that NFTs acquired first are considered to have been used in order, or the NFT that the user wishes to use is selected and considered to have been used. For example, if a total of three NFTs, A to D, are required to complete a mission, and the user has acquired NFTs A, B, A, C, and D (in the order of acquisition), the server 1 may consider A, B, and A to have been used in the order of acquisition, or B, C, and D, as desired by the user, to have been used. In this way, various design changes are possible for the conditions for considering an NFT as used.

[0063] As a third method, it is possible to design the smart contract for the NFT so that, although the NFT is initially in a transferable state, the smart contract for the NFT refers to on-chain data (the usage history of the NFT for missions) and automatically makes the NFT untransferable (disables the Transfer function of the smart contract). In other words, the NFT is made an NFT with a smart contract that makes it untransferable according to the usage history of the NFT, and when the NFT is used, the server 1 outputs the usage history of the NFT to the on-chain (blockchain network 4). This allows the smart contract to refer to the usage history and automatically make the NFT untransferable, solving the above problem.

[0064] As a fourth method, it is possible to provide a marketplace where the NFT smart contract refers to on-chain data (history of NFT usage in missions) and automatically makes the NFT untransferable (disables the smart contract's Transfer function), so that the NFT cannot be bought or sold (transferred) outside of that marketplace. This can also solve the above problem.

[0065] As a fifth method, while the NFT is in a transferable state, a flag indicating whether the NFT has been used or not is prepared in the metadata of the NFT, and if certain conditions are met, the flag is changed to make the NFT ineligible for the mission (making it possible to know whether the NFT has been used or not). "Certain conditions" include whether the NFT has been used for a mission, etc. When the NFT is used, the server 1 updates the flag indicating whether the NFT has been used or not in the metadata of the NFT to "used". This allows the user to determine whether the NFT has been used or not by referring to the flag even if the user tries to reuse the NFT, thereby solving the above problem.

[0066] In addition, when the flag is changed, edits may be made to the image of the NFT, whose storage location is specified in the metadata, to let the user know that the NFT has been used.

[0067] As a sixth method, if an NFT is in a transferable state but has already been used, it is possible to store the fact that the NFT has been used on the blockchain (making it possible to know whether the NFT has been used or not). For example, when an NFT is used, Server 1 updates a flag that is prepared in advance in the smart contract of the NFT on the on-chain data to "used." This can solve the above problem.

[0068] In the above, as the fifth and sixth methods, a flag indicating whether or not an NFT has been used on the metadata or blockchain of an NFT is updated to prevent reuse of the NFT, including by the user who used the NFT. However, the present embodiment is not limited to this, and the user who used the NFT may be able to reuse the NFT. For example, the server 1 recognizes the wallet address when the NFT is used for a mission as the user address of the NFT, and makes the NFT stored in the wallet address reusable. In this case, when an NFT is used, the server 1 may write the wallet address of the user at the time of use of the NFT on the metadata or on-chain data (smart contract) of the NFT instead of the above flag. This enables flexible operation in which people other than the user who used the NFT cannot reuse the NFT even if they receive it, while the user himself can reuse the NFT.

[0069] As a seventh method, it is possible to exclude NFTs with transfer history from the mission. That is, when the server 1 receives a request to use an NFT from a user, it determines whether the NFT has a transfer history, and if it determines that the NFT has a transfer history, it prohibits the use of the NFT. This can solve the above problem.

[0070] As described above, various methods are possible for preventing reuse of NFTs. In this embodiment, any of the first to seventh methods may be adopted, or a combination of multiple methods may be used. Since the other points are the same as those in the first embodiment, the flowchart and other detailed descriptions are omitted in this embodiment.

[0071] As described above, according to the second embodiment, it is possible to suitably prevent the reuse of NFTs.

[0072] (Embodiment 3) In this embodiment, we will explain a form in which, when a user receives NFTs in multiple wallets, the multiple wallets are linked to aggregate data on NFTs held by the user.

[0073] Fig. 10 is an explanatory diagram showing an overview of the third embodiment. An example of a setting screen for associating multiple wallets owned by a user is shown. The overview of this embodiment will be described with reference to Fig. 10.

[0074] As described in the first embodiment, in this system, each issuer distributes NFTs to users through each channel. In this case, a user may receive NFTs in multiple wallets. In this case, it is necessary to integrate the data of NFTs granted to multiple wallets in order to determine whether the mission has been accomplished, but it is inconvenient for a user to transfer and aggregate NFTs in one wallet by himself.

[0075] Therefore, in this embodiment, multiple wallets owned by a user are linked in advance to aggregate data related to NFTs held by the user. For example, as shown on the left side of FIG. 10, terminal 2 displays a list of multiple wallets (wallet app A). ​​Terminal 2 accepts an input to select one of the multiple wallets displayed in the list as the main wallet. When a wallet is selected, authentication is performed based on the private key corresponding to the selected wallet.

[0076] Furthermore, terminal 2 accepts an input to select one or more wallets to be associated with the main wallet, as shown in the center of Fig. 10. When a wallet is selected, authentication is performed based on the private key corresponding to the selected wallet. If authentication is successful, the multiple wallets are registered as the user's wallets, as shown on the right side of Fig. 10. Note that wallets associated with each other can be disconnected later.

[0077] When associating a wallet in the main wallet, if that wallet is already associated with another wallet, the wallet may not be associated with the main wallet. Alternatively, the wallet may be unlinked from the other wallet that is already associated with the main wallet.

[0078] As mentioned above, a user can link multiple wallets and set one of them as the main wallet. Once the main wallet is set, NFTs will be received in the main wallet.

[0079] When a user receives an NFT, the user may be allowed to select a wallet, or the system (server 1) may suggest a receiving wallet. In other words, the NFT may be received in a wallet other than the main wallet.

[0080] When a request to use an NFT is received from a user, the server 1 refers to the multiple wallets associated with each other as described above to acquire data related to the NFT held by the user. The server 1 then determines, based on the acquired data, whether or not the NFT held by the user satisfies the usage conditions (mission achievement conditions) determined according to the issuer and channel. If it is determined that the usage conditions are met, the server 1 grants a reward to the user.

[0081] In addition, if a user receives the same type of NFT in multiple wallets, server 1 may count the NFTs stored in each wallet as one NFT.

[0082] Fig. 11 is a flowchart showing the procedure of wallet registration processing. The processing content when multiple wallets are registered in association with each other will be described with reference to Fig. 11. The control unit 11 of the server 1 causes the terminal 2 to display a list of multiple wallets (wallet application A) (step S301). The control unit 11 accepts an input to select one of the multiple wallets displayed in the list as the main wallet (step S302). The control unit 11 performs authentication based on the private key corresponding to the selected wallet (step S303).

[0083] If the authentication is successful, the control unit 11 accepts an input to select one or more wallets to be associated with the main wallet (step S304). The control unit 11 performs authentication based on the private key corresponding to the selected wallet (step S305). If the authentication is successful, the control unit 11 registers the wallets selected in steps S302 and S304 as the user's wallets in association with each other (step S306), and ends the series of processes.

[0084] As described above, according to the third embodiment, it is also possible to handle cases where NFTs are received in multiple wallets.

[0085] In this embodiment, multiple wallets are linked to determine whether the mission is accomplished, but the embodiment is not limited to this and can also be applied to proof of possession of NFTs. For example, by referring to multiple linked wallets, it can be proven that "the user holds A (stored in wallet a), B (stored in wallet b), and C (stored in wallet c)." In this way, it is sufficient to refer to multiple wallets and obtain data related to the NFTs held by the user, and the specific form is not limited to determining whether the mission is accomplished.

[0086] In addition to determining whether a mission has been accomplished and proving ownership of an NFT, this embodiment is also useful for data analysis, such as visualizing customer behavior data.

[0087] (Variation 1) In the first embodiment, a case has been described in which a user manually links multiple wallets together. Alternatively, the system may regard multiple wallets as the user's wallets and automatically link them together.

[0088] For example, a specific NFT may be distributed (issued) to a user's wallet in advance, and the wallet to which the NFT is attached may be considered to be linked. That is, the server 1 identifies multiple wallets owned by the user by identifying wallets to which the specific NFT is attached. The server 1 then refers to the multiple identified wallets to obtain data on the NFTs owned by the user, and determines whether the conditions for use of the NFT are met based on the data. When a request to use an NFT is received from a user, if the conditions for use are met, the server 1 grants a benefit to the user.

[0089] In this way, multiple wallets may be automatically linked on the system side.

[0090] (Variation 2) There are other possible methods for automatically linking multiple wallets on the system side.

[0091] For example, if user information (e.g., an identifier that can uniquely identify a user) is known at the stage of issuing an NFT, it is possible to write the user information in the metadata of the NFT. When the server 1 receives a request to use an NFT from a user, it identifies multiple wallets owned by the user based on the user information in the metadata of the NFT attached to the wallet. The server 1 then refers to the multiple identified wallets to obtain data on the NFTs held by the user and determines whether or not the conditions for use of the NFT are met. If it is determined that the conditions for use are met, the server 1 grants a benefit to the user.

[0092] When writing user information in metadata, the user information may be encrypted by hashing or the like.

[0093] In this way, it is possible to write user information in advance into the metadata of NFTs, etc.

[0094] (Variation 3) It is also possible to use zero-knowledge proofs (ZKPs) when communicating information about the wallets and NFTs held by users to the system.

[0095] ZKP is a cryptographic technique that allows a prover to make a truthful assertion without revealing details, and in this variant, it is used to prove ownership of wallets and NFTs. By using ZKP, it is possible to prove the wallets that you own, or to select and disclose to the system only the NFTs that you want to disclose from the NFTs attached to multiple wallets, thereby fulfilling the conditions for accomplishing the mission. This solves privacy issues such as not having to disclose the linkage of multiple wallets that a user owns, and disclosing more NFTs than necessary by linking multiple wallets.

[0096] Specifically, when a user uses an NFT, the terminal 2 generates a ZKP to prove ownership of the wallet or the NFT assigned to the wallet. The generated ZKP is verified by the server 1 or a smart contract on the on-chain data (each node 40 of the blockchain network 4), and ownership of the wallet or NFT is proven. The server 1 identifies the wallet or NFT held by the user based on the ZKP and obtains data related to the NFT held by the user. The server 1 determines whether the conditions for use of the NFT are met based on the obtained data, and if it determines that the conditions for use are met, grants a benefit to the user.

[0097] In this way, ZKPs may be used to attest to the wallets a user owns or the NFTs a user holds.

[0098] (Variation 4) There are other possible methods for linking multiple wallets owned by a user.

[0099] For example, when server 1 shares data with issuer server 3 off-chain, it is possible for server 1 to obtain a pair of the issuer's identifier of the user who received the NFT and the wallet address at which the NFT was received from issuer server 3. This enables server 1 to automatically link the user ID on this system with the user's wallet address and manage the list of wallet addresses.

[0100] In addition, the server 1 may receive the shared identifier and wallet address not from the issuer server 3 but from the user (terminal 2).

[0101] In this way, it is possible to link users’ wallet addresses through off-chain data integration.

[0102] The embodiments disclosed herein are illustrative in all respects and should not be considered as limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the scope and meaning equivalent to the claims.

[0103] The matters described in each embodiment can be combined with each other. In addition, the independent claims and dependent claims described in the claims can be combined with each other in any and all combinations regardless of the citation format. Furthermore, the claims use a format in which a claim cites two or more other claims (multi-claim format), but this is not limited to this. They may also be written using a format in which a multiple claim cites at least one other multiple claim (multi-multi claim). [Explanation of symbols]

[0104] 1. Server (information processing device) 11 Control section 12 Main memory 13. Communications Department 14 Auxiliary storage P1 Program 141 User DB 142 Token DB 143 Issuer DB 144 Channel DB 145 Contract DB 146 Mission DB 2. Terminal 21 Control section 22 Main memory 23 Communications Department 24 Display section 25 Input section 26 Auxiliary storage P2 Program A Wallet App 3 Issuer Server 4. Blockchain Network 40 nodes

Claims

1. Collect data on non-fungible or semi-fungible tokens recorded on the blockchain that have been issued to user wallets by each of a plurality of issuers, or on said tokens that have been issued to user wallets by each of a plurality of issuer channels; Execute a given action based on the collected data A program that causes a computer to carry out processing.

2. Obtain a contract address for the token; Collect data about the token from the blockchain based on the contract address. The program according to claim 1.

3. Collecting data about said tokens off-chain from said issuers The program according to claim 1.

4. The predetermined process is a process for determining whether the token held by the user satisfies a predetermined usage condition. The program according to claim 1.

5. The token is a non-transferable token. The program according to claim 4.

6. The token is a token with a smart contract that makes the token non-transferable depending on the token's usage history, When the token is used, the usage history of the token is output on-chain. The program according to claim 4.

7. When the token is used, a flag indicating whether the token has been used or not is updated to "used" on the metadata of the token or on the blockchain. The program according to claim 4.

8. When the token is used, a wallet address of a user who can reuse the token is described on the metadata of the token or on the blockchain. The program according to claim 4.

9. The data regarding the token includes a transfer history of the token; If the token has a transfer history, the use of the token is prohibited. The program according to claim 4.

10. Accepting a setting input for associating the plurality of wallets owned by the user with each other; Refer to the multiple wallets associated with each other to obtain data regarding the tokens held by the user. The program according to claim 1.

11. Identifying the wallet to which the specific token is assigned by assigning the specific token to the multiple wallets owned by the user, thereby identifying the multiple wallets owned by the user; Refer to the identified wallets to obtain data regarding the tokens held by the user. The program according to claim 1.

12. The token is a token in which user information is written in metadata, Identifying a plurality of the wallets owned by the user based on the user information; Refer to the identified wallets to obtain data regarding the tokens held by the user. The program according to claim 1.

13. Obtaining a zero-knowledge proof to prove ownership of the wallet or the token attached to the wallet; By identifying the wallet or the token held by the user based on the zero-knowledge proof, data regarding the token held by the user is obtained. The program according to claim 1.

14. Collect data on non-fungible or semi-fungible tokens recorded on the blockchain that have been issued to user wallets by each of a plurality of issuers, or on said tokens that have been issued to user wallets by each of a plurality of issuer channels; Execute a given action based on the collected data An information processing method in which processing is performed by a computer.

15. An information processing device including a control unit, The control unit: Collect data on non-fungible or semi-fungible tokens recorded on the blockchain that have been issued to user wallets by each of a plurality of issuers, or on said tokens that have been issued to user wallets by each of a plurality of issuer channels; Execute a given action based on the collected data Information processing device.

Images