JP7720804B2 - Information processing system, method and program - Google Patents

Description

This disclosure relates to distributed ledgers such as blockchains.

Technology for generating and trading non-fungible tokens using blockchain has been proposed (see Non-Patent Documents 1 and 2).

William Entriken, 3 others, “EIP-721: Non-Fungible Token Standard” https://eips.ethereum.org/EIPS/eip-721 Witek Radomski, 5 others, “EIP-1155: Multi Token Standard” https://eips.ethereum.org/EIPS/eip-1155

Various technologies have been proposed for generating and trading NFTs, but apart from the generation of new NFTs, the trigger for NFTs being added to a user's wallet is typically the transfer of NFTs in exchange for payment of a fee as agreed upon between users. Even when a user is granted a benefit following an NFT transaction, this has typically only been an additional benefit other than the NFT sent to the user outside of the blockchain.

In light of the above-mentioned problems, the objective of this disclosure is to add variety to NFT transactions.

One example of the present disclosure is an information processing system that includes a determination means that determines 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 that grants 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.

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 or programs through electrical, magnetic, optical, mechanical, or chemical action and can be read by a computer, etc.

In light of the above-mentioned problems, the objective of this disclosure is to add variety to NFT transactions.

1 is a schematic diagram illustrating a configuration of a system according to an embodiment. FIG. 1 is a diagram illustrating an outline of a functional configuration of an information processing apparatus according to an embodiment. FIG. 1 is a schematic diagram illustrating an example of the flow of an NFT issuing process according to an embodiment. FIG. 10 is a diagram illustrating examples of items that can be employed in metadata and token data in an embodiment. FIG. 1 is a schematic diagram illustrating an example of the flow of a primary sales process for an NFT according to an embodiment. FIG. 10 is a schematic diagram illustrating an example of the flow of a periodic aggregation process according to the embodiment. FIG. 2 is a schematic diagram illustrating an example of a flow of a regular remittance process according to an embodiment. FIG. 10 is a schematic diagram illustrating an example of the flow of an on-demand remittance process according to an embodiment. FIG. 1 is a schematic diagram illustrating an example of a flow of a secondary sales process for an NFT according to an embodiment. 10 is a flowchart illustrating an example of the flow of a benefit granting process according to the embodiment. FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation. FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation. FIG. 10 is a diagram illustrating an outline of the functional configuration of an information processing device according to a variation.

Embodiments of a system, information processing device, method, and program according to the present disclosure will be described below with reference to the drawings. However, the embodiments described below are merely examples, and the system, information processing device, method, and program according to the present disclosure are not limited to the specific configurations described below. When implementing the present disclosure, specific configurations may be adopted as appropriate depending on the implementation mode, and various improvements and modifications may be made.

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

A non-fungible token (hereinafter "NFT") is a type of cryptographic token. 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, we will explain an example 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.

Traditionally, when trading goods, services, etc., the amount of value to be paid is recorded as data in a ledger file or similar, and payment fulfillment is confirmed. However, this confirmation method uses a centralized system to manage the data, and there is a risk 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 light of the above issues, the system of this embodiment aims to solve all or at least part of the above problems by issuing an FT of the same amount to indicate the amount of value to be paid in a transaction, and manipulating the FT in accordance with the actual transfer of value.

Various technologies for generating and trading NFTs have also been proposed. In these technologies, a content-oriented data management system is used to reference the content data that is the subject of the NFT, and a resource identifier (e.g., a URI) issued by the content-oriented data management system and containing a hash value of the content data is used. However, with conventional methods, the resource identifier in the data management system is directly registered on 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 issues, the system of this embodiment assigns the resource identifier regardless of the storage location of the content data, generates metadata containing the resource identifier, and registers token data containing the metadata identifier on the blockchain, thereby resolving all or at least part of the above issues.

Furthermore, with the exception of the creation of new NFTs, NFTs have typically been granted to a user's wallet when the NFT is transferred in exchange for a fee agreed upon between users. Even when a user is granted a reward following an NFT transaction, the reward is limited to an additional reward 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 issues, the system according to this embodiment adds variety to NFT transactions by granting 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.

<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.

The information processing device 1 is a computer equipped with 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), and a communication unit 15 such as a NIC (Network Interface Card). 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.

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, storage device, communication unit, input device, 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.

The first data management system 5 manages content data related to NFT (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.

The second data management system 6, like the first data management system 5, manages content data. 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 (such as information called a URI, URN, or CID) 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.

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 NFT marketplace administrator) can participate. For this reason, in this embodiment, the wallets of each user, including NFT purchasers, 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 NFT issuance, NFT trading, FT issuance, and FT trading, or different blockchains may be used additionally.

FIG. 2 is a diagram showing an outline of the functional configuration of the information processing device 1 according to this embodiment. When a program recorded in the storage device 14 is loaded into the RAM 13 and executed by the CPU 11 to control each piece of hardware provided in the information processing device 1, 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 FT issuance unit 33, an FT management unit 34, a value receipt confirmation unit 35, a points granting unit 36, a determination unit 41, a bonus data generation unit 42, and a bonus granting unit 43. Note that in this embodiment and other embodiments described below, each function provided by 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.

The content identifier generation unit 21 generates a content identifier according to the content identifier generation procedure for the content-oriented second data management system 6 (IPFS), regardless of whether the content data is added to 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, at least initially, managed by the content-oriented second data management system 6, a CID is generated according to the IPFS protocol (i.e., by performing a hash operation that includes the content data as a key).

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

The metadata generation unit 23 generates content metadata 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 other private keys, such as the private key of a system administrator, may also be used.

The metadata addition 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.

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.

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 (and assigns it to the owner's wallet). In this embodiment, this indirectly links the content 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. In this embodiment, multiple NFTs linked to a single piece of content may be issued. In this case, the NFT issuing unit 26 issues multiple NFTs linked to a single piece of content by employing a method such as generating multiple pieces of metadata including a combination of a common content identifier (CID) and different additional data (e.g., a serial number) and recording multiple pieces of token data corresponding to the generated multiple pieces of metadata on the blockchain 7, or by recording multiple pieces of token data including a combination of a common metadata identifier and different additional data (e.g., a serial number) on the blockchain 7.

The content data addition unit 27 adds content data managed by the location-oriented first data management system 5 to the content-oriented second data management system 6 using the content identifier generated by the content identifier generation unit 21 in accordance with instructions from the administrator. However, the content data may also be added to the second data management system 6 from the beginning.

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 legal tender, 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, and cryptocurrencies such as Bitcoin and Ethereum may be used, for example. Furthermore, in this embodiment, credit cards, debit cards, electronic money, etc. are assumed to be the payment method when paying legal tender, and the point administrator's point management system is assumed to be the payment method when paying points. However, the payment method is not limited to the examples given in this embodiment, and 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.

The NFT management unit 32 moves the NFT associated with 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.).

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 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 (described below) 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 another type of FT, a cryptocurrency, is used to purchase the product, the FT issuing unit 33 issues an FT on the blockchain 7 in an amount corresponding to the payment value (e.g., Bitcoin or Ethereum). Furthermore, while this embodiment describes an example 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, the destination of the FT at the time of issuance is not limited to the system administrator's wallet and may be issued to the wallet of the purchaser user.

The FT management unit 34 grants (records on 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 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 (so-called burning of the cryptocurrency coin or flagging the cryptocurrency coin), and a third portion to the wallet of the rights holder (IP holder; this is not limited to companies that primarily sell products, but also includes individuals who hold copyrights or portrait rights, etc.) related to the product. Here, the first portion of the FT corresponds to the amount of value to be received by the seller (as sales revenue from product sales), the second portion corresponds to the amount of value to be received by the system administrator (as brokerage fees or system usage fees), and the third portion corresponds to the amount of value to be received by the rights holder (as royalties) from the payment value. In this embodiment, assigning a token to a wallet refers to associating, sending, moving, transferring, etc. the token with the wallet address corresponding to the wallet.

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 that the value has been received (this may be due to be received or may be that the receipt has been 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.

The point granting unit 36 grants points to the purchaser's account that can be used as at least part 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 part 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.

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). The predetermined condition for granting a bonus NFT is not limited here, but for example, the determination unit 41 determines that a combination of multiple NFTs currently or previously granted to a user's wallet satisfies the predetermined condition if it includes NFTs related to a predetermined number or more products in a product set consisting of a predetermined number of products.

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

The bonus data generation unit 42 generates bonus data to be given to the user as a bonus by combining data (serial numbers, content, etc.) related to multiple NFTs that are currently or have been granted in the past to the user's wallet. Once the bonus data is generated, an NFT of the bonus data (hereinafter referred to as a "bonus NFT") is issued by the NFT issuing unit 26.

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 the bonus data, such as adding new background music to this digest video. Furthermore, when creating the 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) 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.

When the determination unit 41 determines that a user satisfies certain conditions, the reward granting unit 43 grants an NFT as a reward to the user's wallet. Note that the specific processing method for granting a reward NFT to a user's wallet is the same as the NFT transfer performed by the NFT management unit 32.

<Processing flow>
Next, the 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.

Figure 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 intended to be associated with the NFT to be sold is entered into the system.

In steps S101 to S103, a CID is generated according to the content data. The information processing device 1 accepts input of content data from a content provider (step S101). The type of content and data format that can be handled by this system are not limited. A variety of objects can be handled as content, including videos, 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 format in which this content is stored as data is not limited either.

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 added to IPFS (second data management system 6) (step S102). Therefore, the CID includes a hash value of the content data calculated using a predetermined hash algorithm. This embodiment describes an example 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 this embodiment, a CDN). In this embodiment, the information processing device 1 stores the content data in the first data management system that uses a CDN (step S103). Furthermore, when adding content data to the location-oriented first data management system 5, the CID generated in step S102 can also be used as an index (e.g., file name or search key) that identifies the content data in the location-oriented first data management system 5. Processing then proceeds to step S104.

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 containing 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, as 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 (step S106), 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. Here, the URI in the metadata includes the CID generated in step S102 according to the IPFS protocol. This means that even if content data is added to IPFS in the future, it will be possible to obtain the content data from IPFS by specifying the URI. Processing then proceeds to step S107.

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). When data is uploaded to IPFS, data larger than a predetermined size is divided (chunked), and a content identifier (CID) uniquely identifying the data to be added (metadata) is issued using a hash value calculated using the data to be added (metadata) as a key. This CID functions as a permanent record indicating that the data existed at the time it was added. As described above, the CID is based on the hash value of the data to be added, and CIDs issued for identical data are identical and remain unchanged. The metadata identifier acquiring unit 25 then acquires the CID issued by IPFS as a metadata CID (referred to as a "metadata CID" to distinguish it from the CID for the content data generated in step S102) (step S108). Processing then proceeds to step S109.

In steps S109 and 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 attaching and issuing an NFT linked to the metadata and content to the owner's wallet (step S110). After that, the processing shown in the diagram ends.

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 (token ID)
- 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 the same piece of content.)
- maxTokens (the maximum number of NFTs that can be issued for a collectible)
tokenMetadataURI (a URI for referencing metadata from an NFT when it is issued, including the CID of the metadata)

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 (including CID) for referencing content data)
- contentHash (hash value of content data)
- contentSignature (digital signature of content data)

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)
- externalURL (URL that directs users to a service or content page)
- rarity (rarity of the content or NFT)
- series (content series information)

The metadata and/or token data may also 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.) associated with 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 also include the metaverse and live streaming performances), and event information related to the content (such as the series/season name or performance name for 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 time of the content and the recording date and time. Each of these pieces of information may be included as an independent item in the metadata and/or content data, or may be listed in a comprehensive item such as the "description" or "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).

According to the NFT issuance process described above, the CID of the content data generated according to the IPFS protocol is stored in the metadata, and the CID of the metadata is recorded on the blockchain 7 as part of 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 by 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 NFT that has already been generated. 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.

Figure 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.

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 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 in packs containing one or more random NFTs. In this case, the NFT management unit 32 transfers the NFT associated with a randomly selected product acquired by the buyer to the buyer's wallet in the process of transferring NFTs to the buyer's wallet, as described below.

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 may be adopted, as appropriate, in which the price is fluctuated to determine a price that is agreeable between the seller and the buyer, such as an auction. The payment acceptance unit 31 accepts the payment of the payment value by the buyer via a payment method linked to the buyer's account (step S201). The value paid by the buyer (in the example shown in the figure, 1,000 yen in Japanese yen, the legal currency of Japan) is deposited into the payment service (step S202), and the management system notifies the information processing device 1, which manages the marketplace, that the payment (settlement) of the value has been completed (step S203). The processing then proceeds to step S204. 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, depositing legal tender) may be made before the settlement, as in step S202, or after the settlement, such as in a deferred payment format.

In steps S204 to S207, value management using FT is carried out. 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 related 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 FT of the issued FT equivalent to the amount of value to be received by the system administrator (200 Coins in the illustrated example, with a margin set to 20%) to the marketplace margin processing wallet (step S205), and assigns FT equivalent to the amount of value to be received by the product seller and rights holder (800 Coins in the illustrated example) to the wallet of the content provider, who is the seller of the product (step S206).

In conjunction with the primary sales process, the NFT management unit 32 transfers the NFTs associated with the purchased product from the seller's wallet to the buyer's wallet. At this time, the transfer of NFTs may be performed simultaneously and inseparably with the granting of the FTs to be received by the seller and/or rights holder to the seller's and/or rights holder's wallet (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 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.

Figure 6 is a schematic diagram showing an example of the flow of the periodic aggregation process according to this embodiment. The process shown in this schematic diagram is executed at predetermined intervals (e.g., 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 at the time the process shown in this diagram is completed.

First, the information processing device 1 deducts a fee (50 yen in the example shown) as necessary from the value paid by the purchaser (1,000 yen in the example shown) 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) to the marketplace account (step S302). Then, processing proceeds to step S303.

The information processing device 1 notifies the administrator's user terminal 9 (hereinafter referred to as the "operator terminal") that the remittance has been completed (step S303). Upon receiving the notification of the remittance completion, the operator terminal acquires sales records for the specified period (e.g., the specified month) from the information processing device 1 that manages the marketplace (step S304), including the product name, content provider name, sales price, payment ID, etc. Furthermore, the information processing device 1 authenticates the amount remitted to the marketplace account in step S302 with the system that manages the marketplace account (e.g., a banking system, etc.) (step S305). The processing shown in the diagram then ends.

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 (e.g., once per month) upon completion of the regular aggregation processing described with reference to Figure 6. Note that the amount of value and FT shown in each account or wallet in the diagram are the amount of value and FT in each account or wallet upon completion of the processing shown in this diagram.

First, the value receipt confirmation unit 35 references the content provider's wallet to confirm that the product seller and rights holder plan to receive an amount of value corresponding to the FT granted to the content provider's wallet (800 yen in the illustrated example), and then generates a payment list for transferring the actual value to the product seller and rights holder (step S401). Note that in Figure 7, the content provider's wallet shows 0 Coins after processing is complete, but at the time of confirmation in step S401, 800 Coins have been granted (see Figure 6), indicating that the content provider plans to receive 800 yen. Here, the payment list is a list that includes the content provider's name, payment amount (800 yen), information related to the payee such as an account, etc. When receipt of value (in this case, planned receipt) is confirmed in step S401, the FT management unit 34 burns the amount of FT (800 Coins in the example shown) that corresponds to the amount of value confirmed to have been received in step S401 (800 yen in the example shown), out of the FT granted to the content provider's wallet, and transitions it to an unusable state (step S402). Processing then proceeds to step S403.

The operator terminal acquires a payment list for the specified period (the current 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, calculated by subtracting the 800 yen to be transferred to the content provider's account from the 950 yen deposited in the account in Figure 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.

Figure 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 FT shown in each account or wallet in the diagram are the amount of value and FT in each account or wallet upon completion of the processing shown in this diagram.

First, the information processing device 1 receives a withdrawal request from the content provider's user terminal 9 (step S501). Here, the value receipt confirmation unit 35 references the content provider's wallet to confirm that the product seller and rights holder plan to receive an amount of value corresponding to the FT granted to the content provider's wallet (800 yen in the illustrated example). Note that in FIG. 8, the content provider's wallet shows 0 Coins after processing is complete, but at the time of confirmation in step S501, 800 Coins had been granted (see FIG. 6), indicating that the content provider plans to receive 800 yen. Then, upon receiving a withdrawal request from the content provider, the FT management unit 34 burns the amount of FT granted to the content provider's wallet (800 Coins in the illustrated example) corresponding to the amount of value requested for withdrawal in step S501 (800 yen in the illustrated example), and transitions the wallet to an unusable state (step S502). Processing then proceeds to step S503.

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 example shown in the figure) 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 example shown in the figure, calculated by subtracting the 800 yen to be transferred to the content provider's account from the 950 yen deposited in the account in Figure 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.

Figure 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 upon completion of the process shown in this diagram.

In steps S601 to S603, a request to purchase an NFT is received and payment of the payment value is made. The seller puts the NFT up for sale on the marketplace. Once the seller (here, a content provider or a user who purchased the NFT from 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 from 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). Processing then proceeds to step S604. Note 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, etc.

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 illustrated example) corresponding to the amount of value paid by the purchaser in step S601 (1,000 yen in the illustrated example) to the marketplace payment wallet (step S604). The FT management unit 34 then assigns, to the content provider's wallet, an FT equivalent to the amount of value to be received by the content provider (the rights holder of the product) (50 Coins in the illustrated example, where the royalty is set to 5%) (step S605), an FT equivalent to the amount of value to be received by the system administrator (50 Coins in the illustrated example, where the margin is set to 5%) (step S606), and an FT equivalent to the amount of value to be received by the product seller (900 Coins in the illustrated example) (step S607). In this embodiment, royalties and/or margins may be calculated by referring to "royaltyInfo" included in the metadata and/or token data.

Here, the NFT management unit 32 transfers the NFT related to the purchased product from the seller's wallet to the buyer's wallet. At this time, it is preferable that 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 the NFT on the blockchain 7, the NFT management unit 32 and the FT management unit 34 use both the FT to be transferred to the seller's wallet and the NFT to be transferred from the seller to the buyer as inputs to indicate the current owner and outputs to indicate 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 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, an Unspent Transaction Output (UTXO). Such transaction processing on the blockchain 7 is effective for increasing the security of transactions, particularly in C2C transactions (including secondary transactions between users of NFTs that have already been sold, as well as transactions in which general users sell NFTs as content providers). However, such transaction processing on the blockchain 7 may also be employed 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 performed simultaneously and inseparably with the transfer of FTs to be received by the seller and/or rights holder to the wallet of the seller and/or rights holder. The FT management unit 34 then burns the FT attached to the margin processing wallet, transitioning it to an unusable state (step S608), and the processing shown in the diagram ends.

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 Figures 6 to 8, and therefore will not be explained further.

Figure 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, or when an execution instruction is input by an administrator, etc. Furthermore, the process shown in this flowchart may be executed at a pre-scheduled timing (for example, at the end of a reward granting campaign period) or periodically (for example, on the monthly reward granting day).

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) to obtain a list of NFTs currently owned by the target user (step S701). Here, the target user's token acquisition history can be obtained by querying a database managed by the service provider for purchase history linked to the target user's account. Note that while this flowchart illustrates obtaining a list of NFTs currently owned by the target user, it is also possible to obtain a list of NFTs that the target user has previously owned (i.e., regardless of whether the target user currently owns those NFTs).

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 result of the determination is that the predetermined condition is not met (NO in step S702), the processing shown in this flowchart ends. On the other hand, if the result of the determination is that the predetermined condition is met (YES in step S702), the processing proceeds to step S703.

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 (bonus NFT) of the bonus data (step S704). Processing then proceeds to step S705.

In step S705, a bonus NFT is granted. The bonus granting unit 43 grants the bonus NFT to the target user's wallet. The processing shown in this flowchart then ends.

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

<Other effects>
According to the technology disclosed in the above embodiment, by issuing an FT of the same amount to indicate the amount of value to be paid in a transaction and manipulating the FT in accordance with 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.

Furthermore, according to the technology disclosed in the above embodiment, even in circumstances where a content provider does not wish to store content in IPFS, it is possible to change the content storage destination to IPFS in response to the requests of the content provider or user (owner, seller, purchaser, etc.) while providing other options for the storage destination. From another perspective, by separating the storage location of content data from the storage location of metadata and including an IPFS-based CID in the metadata, it becomes easier to move NFTs to other blockchains (for example, switching from a private NFT to a public NFT (standard-based NFT)) while preventing the creation or tampering of counterfeit NFTs by third parties.

<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 in accordance with 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 generally similar, 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, an FT issuance unit 33, an 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 by a CPU, which controls each piece of hardware provided in the information processing device 1b.

Figure 12 is a diagram showing an outline of the functional configuration of a variation of an information processing device 1c. 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 described above, but metadata-related processing can be widely used for NFT-related technologies. The information processing device 1c functions as an information processing device equipped with a content identifier generation unit 21, hash value acquisition unit 22, metadata generation unit 23, metadata addition unit 24, metadata identifier acquisition unit 25, and NFT issuance unit 26 by having a program recorded in a storage device read into RAM and executed by a CPU, which controls each piece of hardware provided in the information processing device 1c.

Figure 13 is a diagram showing an outline of the functional configuration of a variation of the information processing device 1d. In the embodiment described above, an example was described in which bonus NFTs are awarded in a system capable of generating and trading NFTs that are the subject of trading. However, the awarding of bonus NFTs can be widely used for NFT-related technologies, and may be implemented as a system that awards bonus NFTs in a system that does not have the functionality for generating and trading NFTs that are the subject of trading described above. The information processing device 1d functions as an information processing device equipped with a determination unit 41, bonus data generation unit 42, and bonus award unit 43, as a program recorded in the storage device is read into RAM and executed by the CPU, which controls each piece of hardware provided in the information processing device 1d.

Furthermore, in the embodiment described above, an example was described in which metadata was added to IPFS, but like content data, metadata may also not be added to a content-oriented data management system such as IPFS, but may instead be stored in a location-oriented data management system such as a CDN, with only a CID being generated and issued.

Note that, while the above-described embodiment describes an example in which a blockchain is used as a distributed ledger, the distributed ledger that can be used to implement the technology disclosed herein is not limited to so-called blockchain. Distributed ledgers other than blockchain may also be used as long as they have the functions and configuration required to realize the technology disclosed herein.

1. Information processing device

Claims (7)

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 a plurality of the 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: 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 . 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 . 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 . 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 . 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. 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.