Information processing system, method and program

Abstract

To provide a variation to transaction of NFTs.SOLUTION: An information processing system includes: a determination unit for determining whether a combination of a plurality of non-replaceable tokens which are being provided to a wallet of a user or was provided to a wallet of a user in a block chain satisfies a predetermined condition; and a privilege provision unit for providing a non-replaceable token as a privilege to a wallet of a user when it is determined that the predetermined condition is satisfied for the user.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] This disclosure relates to distributed ledgers such as blockchains. [Background technology]

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

[0003] [Non-Patent Document 1] William Entriken, 3 others, “EIP-721: Non-Fungible Token Standard” https: / / eips.ethereum.org / EIPS / eip-721 [Non-patent document 2] Witek Radomski, 5 others, “EIP-1155: Multi Token Standard” https: / / eips.ethereum.org / EIPS / eip-1155 Summary of the Invention [Problem to be solved by the invention]

[0004] Various technologies for generating and trading NFTs have been proposed in the past, but apart from the creation of new NFTs, the trigger for an NFT to be added to a user's wallet is generally the transfer of the NFT in exchange for a fee agreed upon between users. Even when a user is granted a benefit following an NFT transaction, the benefit is limited to additional benefits other than the NFT, and is sent to the user outside of the blockchain.

[0005] In view of the above-mentioned problems, the present disclosure aims to add variety to NFT trading. [Means for solving the problem]

[0006] An example of the present disclosure is an information processing system including a determination means for determining whether a combination of multiple non-fungible tokens currently or previously granted to a user's wallet in a blockchain satisfies a predetermined condition, and a reward granting means for granting a non-fungible token as a reward to the user's wallet when the determination means determines that the predetermined condition is satisfied for the user.

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

[0008] In view of the above-mentioned problems, the present disclosure aims to add variety to NFT trading. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a schematic diagram illustrating a configuration of a system according to an embodiment. [Figure 2] FIG. 1 is a diagram illustrating an outline of a functional configuration of an information processing apparatus according to an embodiment. [Figure 3] FIG. 1 is a schematic diagram showing an example of the flow of an NFT issuance process according to an embodiment. [Figure 4] FIG. 10 is a diagram illustrating examples of items that can be employed as metadata and token data in an embodiment. [Figure 5] FIG. 1 is a schematic diagram showing an example of the flow of the primary sales process for an NFT according to an embodiment. [Figure 6]FIG. 10 is a schematic diagram illustrating an example of the flow of a periodic aggregation process according to the embodiment. [Figure 7] FIG. 2 is a schematic diagram illustrating an example of a flow of a regular remittance process according to an embodiment. [Figure 8] FIG. 10 is a schematic diagram illustrating an example of the flow of an on-demand remittance process according to an embodiment. [Figure 9] FIG. 1 is a schematic diagram showing an example of the flow of the secondary sales process for an NFT according to an embodiment. [Figure 10] 10 is a flowchart illustrating an example of the flow of a benefit granting process according to the embodiment. [Figure 11] FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation. [Figure 12] FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation. [Figure 13] FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation. DETAILED DESCRIPTION OF THE INVENTION

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

[0011] In this embodiment, an embodiment in which the technology according to the present disclosure is implemented for a system for generating and trading non-fungible tokens will be described. However, the present disclosure can be widely used for non-fungible token-related technology, fungible token-related technology, or blockchain-related technology, and the application of the present disclosure is not limited to the examples shown in the embodiment.

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

[0013] Conventionally, the amount of value to be paid in a transaction of goods, services, etc. is recorded as data in a ledger file or the like, and the fulfillment of payment is confirmed. However, such a confirmation method uses a centralized system for data management, and there is a possibility that the data may be tampered with, or depending on the data management method, the data may not be visible to some users participating in the transaction. In consideration of the above-mentioned problems, the system according to this embodiment issues an FT of the same amount to indicate the amount of value to be paid in a transaction, and manipulates the FT according to the actual transfer of value, thereby solving all or at least part of the above problems.

[0014] Furthermore, various technologies for generating and trading NFTs have been proposed. In these technologies, a content-oriented data management system is used to reference content data that is the subject of an NFT, and a resource identifier (e.g., a URI) issued by the content-oriented data management system and including a hash value of the content data is used. However, in conventional methods, the resource identifier in the data management system is directly registered in the blockchain, making it difficult to move the storage location of content data in response to various requests (e.g., moving content data from a location-oriented data management system to a content-oriented data management system). In consideration of the above-mentioned problems, the system according to the present embodiment aims to solve all or at least part of the above problems by assigning the resource identifier regardless of the storage location of the content data, generating metadata including the resource identifier, and registering token data including the identifier of the metadata in the blockchain.

[0015] Furthermore, in the past, the trigger for adding an NFT to a user's wallet, excluding the creation of a new NFT, was typically the transfer of the NFT in exchange for a payment agreed upon between users, and even when a user was granted a benefit following an NFT transaction, the benefit was limited to an additional benefit other than the NFT (e.g., physical reward goods or tickets) sent to the user outside of the blockchain. In consideration of the above-mentioned problems, the system according to this embodiment adds variety to NFT transactions by adding a reward NFT to the user's wallet when it is determined that the combination of NFTs currently granted to the user's wallet meets certain conditions.

[0016] <System configuration> 1 is a schematic diagram showing the configuration of a system according to this embodiment. The system according to this embodiment includes an information processing device 1 and a plurality of user terminals 9, which are connected to a network and thereby capable of communicating with each other. The system according to this embodiment is also connected to a first data management system 5, a second data management system 6, and a blockchain 7.

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

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

[0019] The first data management system 5 manages data of content related to NFTs (data as the actual content; hereinafter referred to as "content data"). In this embodiment, the first data management system 5 is a so-called location-oriented data management system, and data managed by the first data management system 5 is referenced by specifying information indicating the location where the data is stored (for example, information called a URL, address, file path, etc.). More specifically, in this embodiment, an example will be described in which a Content Delivery Network (CDN) is used as the first data management system 5.

[0020] The second data management system 6 manages content data in the same way as the first data management system 5. However, unlike the first data management system 5, the second data management system 6 is a so-called content-oriented data management system, and data managed by the second data management system 6 is referenced by specifying a unique identifier (for example, information called a URI, URN, CID, or the like) attached to the data, regardless of where the data is stored. More specifically, in this embodiment, an example will be described in which the InterPlanetary File System (IPFS) is used as the second data management system 6.

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

[0022] 2 is a diagram illustrating an outline of the functional configuration of the information processing device 1 according to this embodiment. A program stored in the storage device 14 is loaded into the RAM 13, executed by the CPU 11, and controls each piece of hardware included in the information processing device 1. As a result, the information processing device 1 functions as an information processing device including a content identifier generation unit 21, a hash value acquisition unit 22, a metadata generation unit 23, a metadata addition unit 24, a metadata identifier acquisition unit 25, an NFT issuance unit 26, a content data addition unit 27, a payment acceptance unit 31, an NFT management unit 32, an NFT issuance unit 33, an NFT management unit 34, a value receipt confirmation unit 35, a point granting unit 36, a determination unit 41, a bonus data generation unit 42, and a bonus granting unit 43. In this embodiment and other embodiments described below, each function included in the information processing device 1 is executed by the CPU 11, which is a general-purpose processor; however, some or all of these functions may be executed by one or more dedicated processors.

[0023] Regardless of whether the content data is added to the content-oriented second data management system 6 (IPFS), the content identifier generation unit 21 generates a content identifier in accordance with a content identifier generation procedure for the second data management system 6. That is, in the system according to this embodiment, even if the content data is managed by the location-oriented first data management system 5 and is not managed by the content-oriented second data management system 6, at least initially, a CID is generated in accordance with the IPFS protocol (i.e., by performing a hash operation that includes the content data as a key).

[0024] The hash value acquisition unit 22 acquires a hash value generated based on a key including content data. The acquired hash value may be calculated by the information processing device 1 or by another computer. In addition, when calculating the hash value, an algorithm different from that used to generate the CID by the content identifier generation unit 21 may be used, or a similar algorithm may be used, or the calculation process may be shared with the CID.

[0025] The metadata generation unit 23 generates metadata for the content, including the hash value acquired by the hash value acquisition unit 22, a digital signature generated using the hash value and a predetermined private key, and a resource identifier referenced when acquiring the content data. In this embodiment, the resource identifier is a uniform resource identifier (URI) including a content identifier (CID) that uniquely identifies the content. The predetermined private key used for the digital signature may be the private key of the content provider, but may also be another private key, such as the private key of a system administrator.

[0026] The metadata adding unit 24 adds the metadata to the second data management system 6. Here, since the second data management system 6 is a content-oriented data management system (IPFS in this embodiment) as described above, when the metadata is added to the second data management system 6, a metadata identifier (CID) that uniquely identifies the metadata is issued from the second data management system 6.

[0027] The metadata identifier acquisition unit 25 acquires an identifier (CID) issued by the content-oriented second data management system 6 when adding metadata to the second data management system 6 as a metadata identifier that uniquely identifies the metadata.

[0028] The NFT issuing unit 26 issues an NFT linked to the metadata and content by recording token data including a metadata identifier on the blockchain 7 (by assigning it to the owner's wallet). In this embodiment, by doing so, the content is indirectly linked to the NFT via the metadata. However, the content may also be directly linked to the NFT by including a hash value or CID of the content in the token data. Also, in this embodiment, multiple NFTs linked to one piece of content may be issued. In this case, the NFT issuing unit 26 issues multiple NFTs linked to one piece of content by employing a method of generating multiple pieces of metadata including a combination of a common content identifier (CID) and different additional data (e.g., serial numbers) and recording multiple pieces of token data corresponding to the generated multiple pieces of metadata on the blockchain 7, or a method of recording multiple pieces of token data including a combination of a common metadata identifier and different additional data (e.g., serial numbers) on the blockchain 7, or the like.

[0029] The content data adding unit 27 adds content data managed by the location-oriented first data management system 5 to the content-oriented second data management system 6 according to instructions from the administrator, using the content identifier generated by the content identifier generating unit 21. However, the content data may be added to the second data management system 6 from the beginning.

[0030] The payment acceptance unit 31 accepts payment of the payment value by the purchaser via a payment method linked to the purchaser's account. Here, the purchaser can use fiat currency, points issued by the administrator, electronic value such as electronic money, etc., as the value used to pay the NFT purchase price. The type of value used to pay the NFT purchase price is not limited; for example, cryptocurrencies such as Bitcoin and Ethereum may be used. Furthermore, in this embodiment, credit cards, debit cards, electronic money, etc. are assumed as payment methods for paying fiat currency, and the point administrator's point management system is assumed as payment methods for paying points. However, the payment method is not limited to the examples given in this embodiment; various known or future payment methods may be used, regardless of whether they are prepaid or postpaid. For example, when cryptocurrency is used for payment, the blockchain network for the target cryptocurrency is used as the payment method.

[0031] The NFT management unit 32 moves the NFT related to the product acquired by the user to the user's wallet. Note that in this embodiment, the product may include certain rights related to the content linked to the NFT or other benefits (points, data, etc.).

[0032] When a product is purchased, the FT issuing unit 33 issues an FT (private FT) on the blockchain 7 in an amount corresponding to the amount of payment value (e.g., Japanese yen or points) made by the purchaser of the product. The FT issued here and managed by the FT management unit 34, which will be described later, is used to indicate the amount of value related to the transaction, and is not used as the value related to the transaction itself. In other words, even if a cryptocurrency that is another type of FT is used to purchase the product, the FT issuing unit 33 issues an FT on the blockchain 7 in an amount corresponding to the amount of payment value (e.g., Bitcoin or Ethereum). Also, in this embodiment, an example is described in which the FT issued by the FT issuing unit 33 is temporarily stored in the system administrator's wallet and then moved to each wallet, but the destination of the FT at the time of issuance is not limited to the system administrator's wallet, and it may be issued to the wallet of the user who is the purchaser.

[0033] The FT management unit 34 grants (records in the blockchain 7) an amount of FT issued by the FT issuing unit 33 to the wallet of a user who is to receive at least a portion of the payment value, the amount corresponding to the amount of value that the user is to receive. More specifically, the FT management unit 34 grants a first portion of the issued FT to the wallet of the product seller, a second portion to the wallet of the system administrator or transitions the cryptocurrency coin to an unusable state (by burning the cryptocurrency coin or flagging the cryptocurrency coin), and a third portion to the wallet of the rights holder (IP holder, which is not limited to companies that primarily sell products but also includes individuals who hold copyrights, portrait rights, etc.) related to the product. Here, the first portion of the FT corresponds to the amount of value that the seller is to receive (as sales from product sales), the second portion corresponds to the amount of value that the system administrator is to receive (as brokerage fees or system usage fees) from the payment value, and the third portion corresponds to the amount of value that the rights holder is to receive (as royalties) from the payment value. In this embodiment, assigning a token to a wallet refers to associating, transmitting, moving, transferring, or the like, the token to a wallet address corresponding to the wallet.

[0034] The value receipt confirmation unit 35 confirms that the user who is to receive at least a portion of the payment value will receive or has received an amount of value corresponding to the FT granted to the user's wallet. When the value receipt confirmation unit 35 confirms the receipt of value (which may be scheduled for receipt or may be receipt completed), the FT management unit 34 transitions the amount of FT granted to the user's wallet that corresponds to the amount of value whose receipt has been confirmed by the value receipt confirmation unit 35 to an unusable state or moves it to a wallet other than the user's wallet.

[0035] The point granting unit 36 grants points to the purchaser's account that can be used as at least a portion of the payment value when purchasing a product. Furthermore, when a first product is purchased, the point granting unit 36 may grant points that can be used as at least a portion of the payment value for a second product that is different from the first product. For example, when an NFT is purchased on the marketplace, the point granting unit 36 grants points calculated based on the purchase price (e.g., points equivalent to 1% of the purchase price) to the purchaser's account. The points granted here can be used as part or all of the purchase price when purchasing another NFT, and the payment accepting unit 31 can apply an amount of points designated by the user from the point balance linked to the user's account to the purchase price of the NFT.

[0036] The determination unit 41 determines whether a combination of multiple NFTs currently or previously granted to a user's wallet in the blockchain satisfies a predetermined condition by referencing the user's wallet or token acquisition history (purchase history). Here, the predetermined condition for granting a bonus NFT is not limited, but for example, the determination unit 41 determines that the predetermined condition is satisfied if the combination of multiple NFTs currently or previously granted to a user's wallet includes NFTs related to a predetermined number or more products out of a product set consisting of a predetermined number of products.

[0037] For example, a predetermined condition may be set such that multiple NFTs relating to three or more pieces of content out of ten pre-specified pieces of content for each of which an NFT has been issued are assigned to one user's wallet. Alternatively, a predetermined condition may be set such that NFTs issued based on two pieces of pre-specified content are assigned to one user's wallet. However, the specific conditions to be set are not limited, and various conditions may be set.

[0038] The reward data generator 42 generates reward data to be given to the user as a reward by combining data (serial numbers, content, etc.) related to multiple NFTs currently or previously assigned to the user's wallet. Once the reward data is generated, an NFT for the reward data (hereinafter, "reward NFT") is issued by the NFT issuing unit 26.

[0039] For example, the bonus data generation unit 42 can generate bonus data by automatically combining and editing content related to multiple NFTs currently or previously granted to the user's wallet. More specifically, if the content in the above example is a video, the bonus data generation unit 42 can automatically generate a digest video of the video related to the NFTs owned by the user and use this digest video as bonus data. Furthermore, content other than the content related to the NFTs owned by the user may be used to create bonus data, such as by adding new background music to this digest video. Furthermore, when creating bonus data, meta information related to the content, such as the content's serial number, may also be referenced, and data generated based on the meta information (e.g., meta information text, etc.) may be inserted into the content. The specific method for generating bonus data is not limited to the example shown in this embodiment, and various existing or future automatic content generation technologies may be used.

[0040] When the determination unit 41 determines that a predetermined condition is satisfied for a user, the reward granting unit 43 grants an NFT as a reward to the user's wallet. Note that the specific processing method for granting the reward NFT to the user's wallet is the same as the transfer of an NFT by the NFT management unit 32.

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

[0042] 3 is a schematic diagram showing an example of the flow of the NFT issuance process according to this embodiment. The process shown in this schematic diagram is executed when content data that is to be associated with an NFT to be sold is input into the system.

[0043] In steps S101 to S103, a CID is generated according to the content data. The information processing device 1 receives input of content data from a content provider (step S101). The types of content and data formats that can be handled by this system are not limited. Various objects can be handled as content, such as moving images, still images, sound (any type of sound, including music, environmental sounds, human voices, animal cries, etc.), three-dimensional models, drawings, text, in-game objects (in-game characters, items, cards, etc.), tickets, etc., and the data formats in which these contents are stored as data are not limited either.

[0044] When content data is input from a content provider, the content identifier generation unit 21 generates a CID according to the IPFS protocol, regardless of whether the content data is to be added to IPFS (the second data management system 6) (step S102). Therefore, the CID includes a hash value of the content data calculated using a predetermined hash algorithm. In this embodiment, an example will be described in which the content data is not initially added to IPFS but is instead stored in a conventional location-oriented first data management system 5 (in the example shown in this embodiment, a CDN). In this embodiment, the information processing device 1 stores the content data in the first data management system using a CDN (step S103). Furthermore, even when the content data is added to the location-oriented first data management system 5, the CID generated in step S102 can be used as an index (e.g., a file name or a search key) identifying the content data in the location-oriented first data management system 5. Then, the process proceeds to step S104.

[0045] In steps S104 to S106, metadata is generated. The hash value acquisition unit 22 calculates a hash value using a predetermined hash algorithm based on the key including the content data obtained in step S101 (step S104). The metadata generation unit 23 then creates a digital signature using the hash value calculated in step S104 and the content provider's private key (step S105). Details of the digital signature process are omitted here because any conventional or future digital signature technology may be used. The public key corresponding to the private key used here is made public in the marketplace. This allows anyone who can obtain the public key to verify the authenticity of the content. Once the digital signature is created, the metadata generation unit 23 generates content metadata including the hash value calculated in step S104, the digital signature generated in step S105, and a URI (resource identifier) referenced when acquiring the content data (step S106). The URI in the metadata includes the CID generated in step S102 according to the IPFS protocol. This allows the user to retrieve content data from IPFS by specifying the URI, even if that content data is added to IPFS in the future. Then, the process proceeds to step S107.

[0046] In steps S107 and S108, the metadata is saved. The metadata adding unit 24 adds the metadata generated in the processes up to step S106 to IPFS (step S107). In IPFS, when data is uploaded, data larger than a predetermined size is divided (chunked), and a content identifier (CID) that uniquely identifies the added data (metadata in this case) is issued using a hash value calculated using the added data (metadata in this case) as a key. This CID functions as a permanent record indicating that the data existed at the time of addition. As described above, the CID is based on the hash value of the added data, and the CID issued for identical data is the same, and the CID for identical data remains unchanged. Then, the metadata identifier acquiring unit 25 acquires the CID issued from IPFS as a metadata CID (referred to as a "metadata CID" to distinguish it from the CID of the content data generated in step S102) (step S108). The process then proceeds to step S109.

[0047] In steps S109 to S110, the token data is recorded on the blockchain 7, thereby issuing an NFT. The NFT issuing unit 26 creates token data including a metadata CID (step S109). The NFT issuing unit 26 then records the created token data directly on the blockchain 7, thereby assigning and issuing an NFT linked to the metadata and content to the owner's wallet (step S110). Thereafter, the processing shown in the drawing ends.

[0048] 4 is a diagram showing examples of items that can be used for metadata and token data in this embodiment, including the following token data. Note that this assumes a collectible token in which multiple NFTs are issued for one piece of content. - tokenID - collectibleID - serialNumber (serial number. If you want to issue multiple NFTs linked to one piece of content, you can do so by setting one collectible ID and multiple different serial numbers for one piece of content.) - maxTokens (the maximum number of NFTs that can be issued for a collectible) - tokenMetadataURI (The URI for referencing metadata from an NFT when it is issued, including the CID of the metadata.)

[0049] The metadata also includes the following data: - title (token title) - description (token description) - image (URL of the content or thumbnail of the content, accessible from a browser) - contentProviderName (Name of the content provider) - contentURI (URI for referencing the content data (including CID)) - contentHash (hash value of content data) - contentSignature (digital signature of content data)

[0050] Furthermore, in this embodiment, the items exemplified below may be adopted as items included in the metadata and / or token data. - royaltyInfo (Information used to verify royalty value distribution, including wallet address and royalty percentage) - external URL (URL that directs users to a service or content page) - rarity (rarity of content or NFT) - series (content series information)

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

[0052] According to the NFT issuance process described above, the CID of the content data generated in accordance with the IPFS protocol is stored in metadata, and the CID of the metadata is recorded on the blockchain 7 as being included in the token data. Therefore, even if content data that was not added to IPFS when the NFT was issued is later added to IPFS by the content data addition unit 27, the CID issued from IPFS will be the same as the CID generated in step S102, making it possible to guarantee the identity of the content data without affecting the already-generated NFT. In other words, according to the NFT issuance process described above, even if the content data that is the subject of the NFT was not initially added to IPFS, the content data can be added to IPFS at any time.

[0053] 5 is a schematic diagram showing an example of the flow of the primary sales process for NFTs according to this embodiment. The process shown in this schematic diagram is executed when a purchase request is sent from the user terminal 9 of a user who wishes to purchase an NFT. Note that the amount of value and the amount of FT shown in each account or wallet in the diagram are the amount of value and the amount of FT in each account or wallet when the process shown in this diagram is completed.

[0054] In steps S201 to S203, a request to purchase an NFT is received and payment of the payment value is made. When an NFT is put up for sale by a content provider on the marketplace and the seller (here, the content provider) and the buyer agree on the price of the NFT, the buyer transmits a request to purchase one or more NFTs to the marketplace managed by the information processing device 1 and completes the payment procedure. Note that a buyer is not limited to purchasing one NFT at a time; a buyer may purchase multiple NFTs at once. Furthermore, multiple NFTs may be a pack containing multiple NFTs created by the seller. NFTs may also be sold as a pack containing one or more random NFTs. In this case, the NFT management unit 32 moves the NFT associated with the randomly selected product acquired by the buyer to the buyer's wallet in the process of transferring NFTs to the buyer's wallet, which will be described later.

[0055] Here, the method for determining the price is not limited. For example, a method may be adopted in which the purchaser agrees to a price previously presented by the seller and the purchaser can purchase the item. Alternatively, a method in which the price is fluctuated to determine a price that is agreeable between the seller and the purchaser, such as an auction, may be adopted to an appropriate extent. The payment acceptance unit 31 accepts the purchaser's payment of the payment value via a payment method linked to the purchaser's account (step S201). The value paid by the purchaser (in the illustrated example, 1,000 yen in Japanese yen, which is legal tender in Japan) is deposited into the payment service (step S202), and the management system notifies the information processing device 1 managing the marketplace that the payment (settlement) of the value has been completed (step S203). Thereafter, the process proceeds to step S204. Here, the payment service may be a financial system capable of managing or linking with the system administrator's account. The payment of the value to the payment service (for example, deposit of legal tender) may be made before the settlement, as in step S202, or after the settlement, as in a deferred payment mode, etc.

[0056] In steps S204 to S207, value management using FTs is performed. The FT issuing unit 33 issues an amount of FT (1,000 Coins in the illustrated example. Hereinafter, the name of the FT issued in this embodiment will be described as "Coins." However, the name of the FT according to this disclosure is not limited) corresponding to the amount of value paid by the purchaser in step S201 (1,000 yen in the illustrated example) to the marketplace payment wallet (system administrator's wallet) (step S204). Then, the FT management unit 34 assigns an FT equivalent to the amount of value to be received by the system administrator (in the illustrated example, the margin is set to 20%, so 200 Coins) from the issued FT to the marketplace margin processing wallet (step S205), and assigns an FT equivalent to the amount of value to be received by the seller and rights holder of the product (800 Coins in the illustrated example) to the wallet of the content provider who is the seller of the product (step S206).

[0057] In conjunction with the primary sales process, the NFT management unit 32 transfers the NFTs related to the purchased product from the seller's wallet to the buyer's wallet. At this time, the transfer of the NFTs may be performed simultaneously and inseparably with the granting of FTs to be received by the seller and / or rights holder to the seller's and / or rights holder's wallets (steps S205 and S206), similar to the processing of steps S605 to S607 of the secondary sales process described below (see FIG. 9). However, the timing of the transfer of the NFTs is not limited to the example shown here. The FT management unit 34 then burns the FTs granted to the margin processing wallet, transitioning it to an unusable state (step S207), and the processing shown in the figure ends.

[0058] 6 is a schematic diagram showing an example of the flow of periodic aggregation processing according to this embodiment. The processing shown in this schematic diagram is executed at predetermined intervals (for example, once per month). Note that the amount of value and the amount of FT shown in each account or wallet in the diagram are the amount of value and the amount of FT in each account or wallet when the processing shown in this diagram is completed.

[0059] First, the information processing device 1 deducts a fee (50 yen in the example shown in the figure) as needed from the value (1,000 yen in the example shown in the figure) paid by the purchaser and deposited into the payment service in step S202 of the primary sales process described with reference to Fig. 5 (step S301), and transfers the remainder (950 yen in the example shown in the figure) to the marketplace account (step S302). Then, the process proceeds to step S303.

[0060] The information processing device 1 notifies the administrator's user terminal 9 (hereinafter referred to as the "operator terminal") of the completion of the remittance (step S303). Upon receiving the notification of the completion of the remittance, the operator terminal acquires sales records including the product name, content provider name, sales price, payment ID, etc. for the specified period (e.g., the current month) from the information processing device 1 that manages the marketplace (step S304). The information processing device 1 also authenticates the remittance amount to the marketplace account in step S302 with the system that manages the marketplace account (e.g., a bank system, etc.). Thereafter, the processing shown in the drawing ends.

[0061] Figure 7 is a schematic diagram showing an example of the flow of regular remittance processing according to this embodiment. The processing shown in this schematic diagram is executed at predetermined intervals (for example, once per month) upon completion of the regular aggregation processing described with reference to Figure 6. Note that the amount of value and the amount of FT shown in each account or wallet in the diagram are the amount of value and the amount of FT in each account or wallet at the time when the processing shown in this diagram is completed.

[0062] First, the value receipt confirmation unit 35 confirms, by referring to the content provider's wallet, that the product seller and right holder plan to receive an amount of value (800 yen in the illustrated example) corresponding to the FT granted to the content provider's wallet. Furthermore, the value receipt confirmation unit 35 generates a payment list for transferring the actual value to the product seller and right holder (step S401). Note that in FIG. 7, the content provider's wallet shows 0 Coin after the completion of processing, but at the time of confirmation in step S401, 800 Coin has been granted (see FIG. 6), indicating that the content provider plans to receive 800 yen. Here, the payment list is a list including the name of the content provider, the payment amount (800 yen), information related to the payee such as an account, and so on. When the receipt of value (here, planned receipt) is confirmed in step S401, the FT management unit 34 burns the amount of FT (800 Coin in the illustrated example) corresponding to the amount of value (800 yen in the illustrated example) whose receipt was confirmed in step S401, from among the FTs granted to the content provider's wallet, and transitions it to an unusable state (step S402). Thereafter, the process proceeds to step S403.

[0063] The operator terminal acquires a payment list for the specified period (the month in this embodiment) from the information processing device 1 (step S403), and instructs the bank system to transfer the value to be received by the product seller and rights holder (800 yen in the illustrated example) from the marketplace account to the content provider's account according to the acquired payment list (step S404). Here, the value remaining in the marketplace account after the transfer (150 yen in the illustrated example, obtained by subtracting the 800 yen to be transferred to the content provider's account from the 950 yen deposited in the account in FIG. 6) is the value to be received by the system administrator. When the transfer of the instructed value is completed (step S405), the processing shown in the figure ends.

[0064] 8 is a schematic diagram showing an example of the flow of on-demand remittance processing according to this embodiment. The processing shown in this schematic diagram is executed when a value withdrawal request is sent from the content provider's user terminal 9. Note that the amount of value and the amount of FT shown in each account or wallet in the diagram are the amount of value and the amount of FT in each account or wallet when the processing shown in this diagram is completed.

[0065] First, the information processing device 1 receives a withdrawal request from the user terminal 9 of the content provider (step S501). Here, the value receipt confirmation unit 35 confirms by referring to the content provider's wallet that the seller of the product and the right holder plan to receive the amount of value (800 yen in the illustrated example) corresponding to the FT granted to the content provider's wallet. Note that in FIG. 8, the content provider's wallet shows 0 Coin after the process is completed, but at the time of confirmation in step S501, 800 Coin has been granted (see FIG. 6), and it is clear that the content provider plans to receive 800 yen. Then, when the withdrawal request from the content provider is received, the FT management unit 34 burns the amount of FT (800 Coin in the illustrated example) corresponding to the amount of value requested for withdrawal in step S501 (800 yen in the illustrated example) from the FT granted to the content provider's wallet, and transitions it to an unusable state (step S502). Then, the process proceeds to step S503.

[0066] In accordance with the withdrawal request received in step S501, the information processing device 1 instructs the bank system to transfer the value to be received by the product seller and rights holder (800 yen in the illustrated example) from the marketplace account to the content provider's account (step S503). Here, the value remaining in the marketplace account after the transfer (150 yen in the illustrated example, obtained by subtracting the 800 yen to be transferred to the content provider's account from the 950 yen deposited in the account in FIG. 6) is the value to be received by the system administrator. When the transfer of the instructed value is completed (step S504), the processing shown in the figure ends.

[0067] 9 is a schematic diagram showing an example of the flow of the secondary sales process for NFTs according to this embodiment. The process shown in this schematic diagram is executed when a purchase request is sent from the user terminal 9 of a user who wishes to purchase an NFT. Note that the amount of value and the amount of FT shown in each account or wallet in the diagram are the amount of value and the amount of FT in each account or wallet when the process shown in this diagram is completed.

[0068] In steps S601 to S603, a purchase request for an NFT is received and payment of the payment value is made. The seller puts the NFT up on the marketplace, and once the seller (here, a user who purchased the NFT from a content provider or another user) and the buyer agree on the price of the NFT, the buyer sends a request to purchase the NFT to the information processing device 1 and completes the payment procedure. Note that the method for determining the price, the type of value used to pay for the NFT, and the payment method are not limited, as in the primary sales process described with reference to FIG. 5. The payment acceptance unit 31 accepts payment of the payment value by the buyer via the payment method linked to the buyer's account (step S601). The value paid by the buyer (1,000 yen in the illustrated example) is deposited into the payment service (step S602), and the management system notifies the information processing device 1 that payment of the value has been made (step S603). The process then proceeds to step S604. It should be noted that payment of value to the payment service (for example, deposit of legal tender) may be made before the payment in the manner of step S602, or may be made after the payment in the manner of deferred payment or the like.

[0069] In steps S604 to S608, value management using FT is performed. The FT issuing unit 33 issues an amount of FT (1,000 Coins in the example shown in the figure) corresponding to the amount of value paid by the purchaser in step S601 (1,000 yen in the example shown in the figure) to the payment wallet of the marketplace (step S604). Then, the FT management unit 34 grants, from the issued FT, an FT equivalent to the amount of value to be received by the content provider (rights holder of the product) (50 Coins in the example shown in the figure, where the royalty is set to 5%) to the wallet of the content provider (step S605), an FT equivalent to the amount of value to be received by the system administrator (50 Coins in the example shown in the figure, where the margin is set to 5%) to the margin processing wallet of the marketplace (step S606), and an FT equivalent to the amount of value to be received by the seller of the product (900 Coins in the example shown in the figure) to the wallet of the user who is the seller of the product (step S607). In this embodiment, the royalty and / or margin may be calculated by referring to "royaltyInfo" included in the metadata and / or token data.

[0070] Here, the NFT management unit 32 transfers the NFT associated with the purchased product from the seller's wallet to the buyer's wallet. Preferably, the transfer of the NFT is performed simultaneously and inseparably with the granting of the FT to be received by the seller and / or rights holder to the seller's and / or rights holder's wallet (steps S605 to S607). That is, in a transaction for transferring an NFT on the blockchain 7, the NFT management unit 32 and the FT management unit 34 use both the FT transferred to the seller's wallet and the NFT transferred from the seller to the buyer as inputs indicating the current owner and outputs indicating the transfer destination, thereby preventing the NFT from being transferred to the buyer unless the seller receives the FT. At this time, the NFT management unit 32 and the FT management unit 34 can complete the transaction by publishing the digital signatures for the inputs and outputs for both the seller and the buyer together on the network. The NFT management unit 32 and / or the FT management unit 34 may process transactions to transfer NFTs and / or FTs based on a transaction format that takes the form of, for example, UTXO (Unspent Transaction Output). Such transaction processing on the blockchain 7 is effective for enhancing transaction security, particularly in C2C transactions (including secondary transactions between users of NFTs that have already been sold, as well as transactions in which ordinary users sell NFTs as content providers). However, such transaction processing on the blockchain 7 may also be adopted in transactions other than C2C (e.g., B2C transactions). That is, even in the primary sales processing described with reference to FIG. 5, the transfer of NFTs may be executed simultaneously and inseparably with the granting of FTs to be received by the seller and / or rights holder to the seller's and / or rights holder's wallet. Thereafter, the FT management unit 34 burns the FTs granted to the margin processing wallet and transitions them to an unusable state (step S608), and the processing shown in the figure ends.

[0071] The details of the tallying process and remittance process that are executed after the secondary sales process is completed are the same as those described above with reference to FIGS. 6 to 8, and therefore will not be described here.

[0072] 10 is a flowchart showing an example of the flow of the reward granting process according to this embodiment. The process shown in this flowchart is executed when a new NFT is granted to a user's wallet, when an execution instruction is input by an administrator, or when other triggers occur. The process shown in this flowchart may be executed at a pre-booked timing (for example, at the closing time of a reward granting campaign period) or periodically (for example, on the monthly reward granting day).

[0073] In steps S701 and S702, it is determined whether the conditions for granting a bonus NFT are met. The determination unit 41 references the user's wallet or token acquisition history (purchase history) and acquires a list of NFTs currently owned by the target user (step S701). Here, the target user's token acquisition history can be acquired by querying a database managed by the service provider about the purchase history linked to the target user's account. Note that in this flowchart, a list of NFTs currently owned by the target user is acquired, but instead of such a list, a list of NFTs that the target user has previously owned (i.e., regardless of whether the target user currently owns the NFT) may be acquired.

[0074] Then, the determination unit 41 determines whether the combination of multiple NFTs listed in the acquired list satisfies a predetermined condition (step S702). If the determination result shows that the predetermined condition is not met (NO in step S702), the processing shown in this flowchart ends. On the other hand, if the determination result shows that the predetermined condition is met (YES in step S702), the processing proceeds to step S703.

[0075] In steps S703 and S704, a bonus NFT is issued. The bonus data generation unit 42 generates bonus data to be given to the user as a bonus (step S703). Once the bonus data is generated, the NFT issuing unit 26 issues an NFT of the bonus data (bonus NFT) (step S704). Then, the process proceeds to step S705.

[0076] In step S705, the reward NFT is granted. The reward granting unit 43 grants the reward NFT to the target user's wallet. After that, the processing shown in this flowchart ends.

[0077] In the above-described reward granting process, an example has been described in which reward data and a reward NFT are automatically generated when a reward NFT is granted, but the reward data and reward NFT may be prepared in advance. In this case, the reward data generation unit 42 may be omitted, and the reward NFT may be granted in advance to the administrator's wallet, etc.

[0078] <Other effects> According to the technology disclosed in the above embodiment, by issuing an equal amount of FT to indicate the amount of value to be paid in a transaction and manipulating the FT according to the actual transfer of value, it becomes possible to suitably manage the value to be paid in a transaction as data, such as royalties, margins, seller profits, etc. For example, according to the above embodiment, it becomes possible to use a decentralized system for data management while preventing data tampering, and also to enable users participating in a transaction to refer to the data (here, FT) that manages the amount of value themselves.

[0079] Furthermore, according to the technology disclosed in the above embodiment, even in cases where a content provider does not wish to store content in IPFS, other options for the storage destination can be provided, and the content storage destination can be changed to IPFS in response to the request of the content provider or user (owner, seller, purchaser, etc.). From another perspective, by separating the storage location of content data from the storage location of metadata and including an IPFS-style CID in the metadata, it becomes easy to move NFTs to another blockchain (for example, switching from a private NFT to a public NFT (a standard-style NFT)) while preventing the creation or tampering of counterfeit NFTs by third parties.

[0080] <Variations> FIG. 11 is a diagram illustrating an outline of the functional configuration of an information processing device 1b according to a variation. In the embodiment described above, an example was described in which a process of issuing an amount of FT corresponding to the amount of value to be paid in a transaction and manipulating the FT according to the actual transfer of value was used to manage the value paid in an NFT transaction. However, the value management using FT described above may also be used to manage the value to be paid in transactions of products, services, etc. other than NFTs. In this case, the content of the processing by each functional unit is roughly the same, except that the trigger for starting the processing is a product, service, etc. other than NFTs. The information processing device 1b functions as an information processing device including a payment acceptance unit 31, a FT issuance unit 33, a FT management unit 34, and a value receipt confirmation unit 35, by reading a program recorded in a storage device into RAM and executing it with a CPU, which controls each hardware provided in the information processing device 1b.

[0081] 12 is a diagram showing an outline of the functional configuration of an information processing device 1c according to a variation. In the embodiment described above, an example was described in which the process of generating metadata including a resource identifier and registering token data including the metadata identifier in the blockchain 7 was performed in conjunction with the value management. However, metadata-related processing can be widely used for NFT-related technologies. The information processing device 1c functions as an information processing device including a content identifier generation unit 21, a hash value acquisition unit 22, a metadata generation unit 23, a metadata addition unit 24, a metadata identifier acquisition unit 25, and an NFT issuance unit 26, by reading a program recorded in a storage device into RAM and executing it with a CPU, which controls each piece of hardware included in the information processing device 1c.

[0082] 13 is a diagram showing an outline of the functional configuration of an information processing device 1d according to a variation. In the embodiment described above, an example was described in which a bonus NFT is granted in a system capable of generating and trading NFTs that are subject to trading. However, the granting of bonus NFTs can be widely used for NFT-related technologies, and may be implemented as a system that grants bonus NFTs in a system that does not have the functionality for generating and trading NFTs that are subject to trading described above. The information processing device 1d functions as an information processing device including a determination unit 41, a bonus data generation unit 42, and a bonus granting unit 43, by loading a program recorded in a storage device into RAM and executing it with a CPU, which controls each piece of hardware provided in the information processing device 1d.

[0083] Furthermore, in the above-described embodiment, an example of adding metadata to IPFS was described, but like content data, metadata may also be stored in a location-oriented data management system such as a CDN without being added to a content-oriented data management system such as IPFS, and only a CID may be generated and issued.

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

[0085] 1. Information processing equipment

Claims

1. A determination means for determining whether a combination of multiple non-fungible tokens currently or previously assigned to a wallet of a user in a blockchain satisfies a predetermined condition; A reward data generation means for generating reward data by combining data relating to the plurality of non-fungible tokens currently or previously assigned to the user's wallet; a non-fungible token issuing means for issuing a non-fungible token for the privilege data; a reward granting means for granting a non-fungible token of the reward data as a reward to the wallet of the user when the determining means determines that the predetermined condition is satisfied for the user; An information processing system comprising:

2. The system further includes a non-fungible token management means for transferring the non-fungible tokens relating to the products acquired by a user to the wallet of the user. The information processing system according to claim 1 .

3. The non-fungible token management means moves the non-fungible tokens related to the products randomly selected and acquired by the user to the wallet of the user. The information processing system according to claim 2 .

4. The determination means determines that the predetermined condition is satisfied when a combination of the plurality of non-fungible tokens currently or previously granted to the wallet of the one user includes non-fungible tokens related to a predetermined number or more of products in a product set consisting of a predetermined plurality of products. The information processing system according to claim 1 .

5. The determination means determines whether the predetermined condition is satisfied for the user by referring to the user's wallet or token acquisition history. The information processing system according to any one of claims 1 to 4.

6. The computer a determination step of determining whether a combination of multiple non-fungible tokens currently or previously assigned to a wallet of a user in a blockchain satisfies a predetermined condition; a reward data generation step of generating reward data by combining data relating to the plurality of non-fungible tokens currently or previously assigned to the user's wallet; a non-fungible token issuing step of issuing a non-fungible token for the privilege data; a reward granting step of granting a non-fungible token of the reward data as a reward to the wallet of the user when it is determined in the determining step that the predetermined condition is satisfied for the user; How to do it.

7. On the computer, a determination step of determining whether a combination of multiple non-fungible tokens currently or previously assigned to a wallet of a user in a blockchain satisfies a predetermined condition; a reward data generation step of generating reward data by combining data relating to the plurality of non-fungible tokens currently or previously assigned to the user's wallet; a non-fungible token issuing step of issuing a non-fungible token for the privilege data; a reward granting step of granting a non-fungible token of the reward data as a reward to the wallet of the user when it is determined in the determining step that the predetermined condition is satisfied for the user; A program to execute.

Images