Information processing system, method and program

Abstract

To increase the convenience and the flexibility when managing the amount of values to pay for a transaction as data.SOLUTION: The information processing system includes: a replaceable token issuing unit for issuing, on a block chain, the amount of a replaceable token which corresponds to the amount of a payment value of a purchaser of a product, in response to purchase of the product; and a replaceable token management unit for providing at least a part of the issued replaceable token to a user who is to receive at least a part of the payment value.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] Conventionally, the amount of value to be paid in a transaction of goods or services is recorded as data in a ledger file, etc., and the fulfillment of the payment is confirmed. However, this confirmation method has a problem in that it is not convenient or flexible in terms of data management.

[0005] In view of the above problems, an object of the present disclosure is to improve the convenience and flexibility when managing the amount of value to be paid in a transaction as data. [Means for solving the problem]

[0006] One example of the present disclosure is an information processing system including: a fungible token issuing means that, when a product is purchased, issues on a blockchain a quantity of fungible tokens corresponding to the amount of value paid by a purchaser of the product; and a fungible token management means that grants at least a portion of the issued fungible tokens to a wallet of a user who is to receive at least a portion of the payment value.

[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. Effect of the Invention

[0008] According to the present disclosure, it is possible to improve the convenience and flexibility in managing the amount of value to be paid in a transaction as data. [Brief description of the drawings]

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

[0010] Hereinafter, embodiments of the system, information processing device, method, and program according to the present disclosure will be described with reference to the drawings. However, the embodiments described below are merely examples of the embodiment, and the system, information processing device, method, and program according to the present disclosure are not limited to the specific configurations described below. In carrying out 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 is different from fungible tokens (hereinafter, "FT") such as cryptocurrencies, which can be substituted by other tokens if the amount is the same, and is a token for indicating the owner of an object that cannot be substituted by other things. In this embodiment, an example will be described in which an NFT is 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, the technology that can be adopted to issue and trade NFTs is not limited.

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

[0014] In addition, various technologies for generating and trading NFTs have been proposed in the past. In such technologies, a content-oriented data management system is used to refer to 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 is used, which includes a hash value of the content data. However, in the conventional method, the resource identifier in the data management system is directly registered in the blockchain, so it is difficult to move the storage location of the content data in response to various requests (e.g., moving the content data from a location-oriented data management system to a content-oriented data management system). In view of the above problems, the system according to this embodiment is intended to solve all or at least a 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] <System configuration> 1 is a schematic diagram showing the configuration of a system according to the present embodiment. The system according to the present embodiment includes an information processing device 1 and a plurality of user terminals 9 that are connected to a network and capable of communicating with each other. The system according to the present embodiment is also connected to a first data management system 5, a second data management system 6, and a blockchain 7.

[0016] The information processing device 1 is a computer including a central processing unit (CPU) 11, a read only memory (ROM) 12, a random access memory (RAM) 13, a storage device 14 such as an electrically erasable and programmable read only memory (EEPROM) or a hard disk drive (HDD), a communication unit 15 such as a network interface card (NIC), etc. However, the specific hardware configuration of the information processing device 1 can be omitted, replaced, or added as appropriate depending on the embodiment. In addition, 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.

[0017] The user terminal 9 is a terminal device used by a user. The user terminal 9 is a computer equipped with a CPU, a ROM, a RAM, a storage device, a communication unit, an input device, an output device, and the like (not shown). However, the specific hardware configuration of the user terminal 9 can be omitted, replaced, or added as appropriate depending on the embodiment. In addition, 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. The user connects to the information processing device 1 via these user terminals 9 and manages the system, manages NFTs and FTs, participates in the marketplace, trades NFTs, and the like.

[0018] The first data management system 5 manages data of content related to NFT (data as the substance of the 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.

[0019] The second data management system 6 manages content data in the same manner 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 in which the InterPlanetary File System (IPFS) is used as the second data management system 6 will be described.

[0020] 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 who have an account (for example, a user ID issued by an administrator of an NFT marketplace) managed by a specific management entity can participate. For this reason, in this embodiment, the wallets of each user, including the purchaser of the NFT, are managed by being linked to the account. Here, wallet addresses corresponding to each of the wallets of each user are generated appropriately. However, the type of blockchain that can be used to implement the technology according to the present disclosure is not limited, and a consortium blockchain in which only users of accounts corresponding to each of a plurality of specific management entities can participate may be used, or a public blockchain may be used. In addition, the same blockchain may be used for issuing NFTs, trading NFTs, issuing FTs, and trading FTs, or a different blockchain may be additionally used.

[0021] 2 is a diagram showing an outline of the functional configuration of the information processing device 1 according to this embodiment. The information processing device 1 functions as an information processing device including a content identifier generating unit 21, a hash value acquiring unit 22, a metadata generating unit 23, a metadata adding unit 24, a metadata identifier acquiring unit 25, an NFT issuing unit 26, a content data adding unit 27, a payment accepting unit 31, an NFT managing unit 32, an FT issuing unit 33, an FT managing unit 34, a value receipt confirming unit 35, and a point granting unit 36, by a program recorded in the storage device 14 being read into the RAM 13 and executed by the CPU 11 to control each piece of hardware included in the information processing device 1. Note that in this embodiment and other embodiments described later, each function included in the information processing device 1 is executed by the CPU 11, which is a general-purpose processor, but some or all of these functions may be executed by one or more dedicated processors.

[0022] 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 according to 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 according to the IPFS protocol (i.e., by performing a hash operation including the content data as a key).

[0023] 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 may be calculated by another computer. In addition, in calculating the hash value, an algorithm different from that used in generating 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.

[0024] The metadata generating unit 23 generates metadata of the content, including the hash value acquired by the hash value acquiring 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 uses 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.

[0025] 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 indicates the metadata is issued from the second data management system 6.

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

[0027] The NFT issuing unit 26 issues an NFT linked to the metadata and content by recording token data including a metadata identifier in the blockchain 7 (by attaching it to the wallet of the owner). In this embodiment, by doing so, the content is indirectly linked to the NFT via the metadata. However, the content may be directly linked to the NFT by including a hash value or CID of the content in the token data. In addition, in this embodiment, multiple NFTs linked to one content may be issued. In this case, the NFT issuing unit 26 issues multiple NFTs linked to one content by adopting a method of generating multiple metadata including a combination of a common content identifier (CID) and additional data different from each other (e.g., serial number) and recording multiple token data corresponding to the generated multiple metadata in the blockchain 7, or a method of recording multiple token data including a combination of a common metadata identifier and additional data different from each other (e.g., serial number) in the blockchain 7.

[0028] The content data adding unit 27 adds the content data managed by the location-oriented first data management system 5 to the content-oriented second data management system 6 according to an instruction 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.

[0029] The payment acceptance unit 31 accepts the payment of the payment value by the purchaser via a payment means linked to the account held by the purchaser. Here, the purchaser can use legal 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, and for example, cryptocurrency such as Bitcoin and Ethereum may be used. In addition, in this embodiment, a credit card, a debit card, electronic money, etc. are assumed as a payment means when paying legal currency, and a point management system of a point administrator is assumed as a payment means when paying points. However, the payment means is not limited to the examples in this embodiment, and various payment means that are known or will appear in the future may be adopted, regardless of whether they are prepaid or postpaid. For example, when cryptocurrency is used for payment, a blockchain network for the target cryptocurrency is used as a payment means.

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

[0031] When a product is purchased, the FT issuing unit 33 issues an FT (private FT) in an amount corresponding to the amount of payment value (e.g., Japanese yen or points) by the purchaser of the product on the blockchain 7. The FT issued here and managed by the FT management unit 34 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 in an amount corresponding to the amount of payment value (e.g., Bitcoin or Ethereum) on the blockchain 7. In addition, in this embodiment, an example is described in which the FT issued by the FT issuing unit 33 enters the system administrator's wallet and then moves 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.

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

[0033] 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 wallet of the user. When the value receipt confirmation unit 35 confirms the receipt of the value (which may be scheduled for receipt or may be completed), the FT management unit 34 transitions the amount of FT corresponding to the amount of value whose receipt has been confirmed by the value receipt confirmation unit 35, out of the FT granted to the user's wallet, to an unusable state or moves it to a wallet other than the wallet of the user.

[0034] The point giving unit 36 ​​gives points that can be used as at least a part of the payment value when purchasing a product to an account held by the purchaser. In addition, when a first product is purchased, the point giving unit 36 ​​may give points that can be used as at least a part of the payment value for a second product different from the first product. For example, when an NFT is purchased in the marketplace, the point giving unit 36 ​​gives points calculated based on the purchase price (for example, points equivalent to 1% of the purchase price) to the account of the purchaser. The points given here can be used as part or all of the purchase price when purchasing another NFT, and the payment receiving 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.

[0035] <Processing flow> Next, a flow of processing executed in the system according to the present embodiment will be described. Note that the specific contents and processing order of the processing described below are an example for implementing the present disclosure. The specific contents and processing order may be appropriately selected according to the embodiment of the present disclosure.

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

[0037] In steps S101 to S103, a CID is generated according to the content data. The information processing device 1 accepts an input of content data from a content provider (step S101). Here, the type of content and the format of data that can be handled by this system are not limited. Various objects can be handled as content, such as moving images, still images, sounds (any kind of sound is acceptable, and examples include 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 when these contents are held as data is not limited.

[0038] When content data is input from a content provider, the content identifier generating 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) or not (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 stored in a conventional location-oriented first data management system 5 (CDN in the example shown in this embodiment). In this embodiment, the information processing device 1 stores the content data in the first data management system using the CDN (step S103). In addition, the CID generated in step S102 can be used as an index (for example, a file name or a search key) indicating the content data in the location-oriented first data management system 5 even when the content data is added to the location-oriented first data management system 5. Thereafter, the process proceeds to step S104.

[0039] 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). Then, the metadata generation unit 23 creates an electronic signature using the hash value calculated in step S104 and the private key of the content provider (step S105). Details of the electronic signature process are omitted because any conventional or future electronic signature technology may be used. Note that a 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. When the electronic signature is created, the metadata generation unit 23 generates metadata of the content including the hash value calculated in step S104, the electronic signature generated in step S105, and a URI (resource identifier) ​​referenced when acquiring the content data (step S106). Here, the URI in the metadata includes the CID generated in step S102 according to the IPFS protocol. This makes it possible to acquire content data from IPFS by specifying the URI, even if the content data is added to IPFS in the future. Then, the process proceeds to step S107.

[0040] In steps S107 and S108, the metadata is stored. The metadata adding unit 24 adds the metadata generated in the process 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 indicates the data to be added (metadata here) is issued using a hash value obtained using the data to be added (metadata here) as a key. This CID functions as a permanent record that indicates that the data existed at the time of addition. As described above, the CID is based on the hash value of the data to be added, and the CID issued for the exact same data is the same, and the CID for the same data is immutable. 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). After that, the process proceeds to step S109.

[0041] 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). Then, the NFT issuing unit 26 directly records the created token data on the blockchain 7, thereby attaching and issuing an NFT to which the metadata and content are linked, to the owner's wallet (step S110). After that, the processing shown in the drawing ends.

[0042] 4 is a diagram showing examples of items that can be adopted for metadata and token data in this embodiment, including the token data listed below. Note that a token in the form of a collectible in which multiple NFTs are issued for one piece of content is assumed. - tokenID - collectibleID - serialNumber (serial number. If you want to issue multiple NFTs linked to one piece of content, you can issue multiple NFTs 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 the NFT when it is issued, including the CID of the metadata.)

[0043] The metadata also includes the data listed below. - title (token title) - description (token description) - image (URL of the content or a thumbnail of the content, accessible from a browser) - contentProviderName (name of the content provider) - contentURI (the URI to reference the content data (including the CID)) - contentHash (hash value of content data) - contentSignature (digital signature of content data)

[0044] 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 distribution of value as royalties, including wallet address and royalty percentage) - externalURL (URL that directs the user to a service or content page) - rarity (rarity of the content or NFT) - series (content series information)

[0045] In addition, the metadata and / or token data may further include information on the content provider, information on performers related to the content, credit information related to intellectual property rights (copyright, trademark, performer's rights, etc.) related to the content, information on the group related to the content, date and time information related to the content, location information related to the content (performance venue, etc., which may include metaverse and distribution performance), event information related to the content (series / season name, performance name, concept, etc. related to a sports game). Here, the performers include actors and performers, athletes in sports content, and members in idol / band content, the groups include team names in sports content, group names in idol content, and group names in band content, and the date and time include the release date and recording date and time of the content. These pieces of information may be included in the metadata and / or content data as independent items, or may be described in comprehensive items such as the above-mentioned "description" and "series". In addition, the information on the performers may include the role of the performer in the content (position (such as "pitcher") in sports content, position in idol content, instrument in band content, etc.).

[0046] 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 in the blockchain 7 as being included in the token data, so that 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, and it is possible to guarantee the identity of the content data without affecting the 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.

[0047] 5 is a schematic diagram showing an example of the flow of the primary sales process of 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.

[0048] In steps S201 to S203, a purchase request for an NFT is received and payment value is settled. When an NFT is put up for sale on the marketplace by a content provider 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 carries out payment procedures. Note that the number of NFTs that a buyer can purchase in one go is not limited to one, and the buyer may purchase multiple NFTs in one go. Furthermore, the multiple NFTs may be a pack containing multiple NFTs created by the seller.

[0049] Here, the method of determining the price is not limited, and for example, a method may be adopted in which the purchaser agrees to a price presented in advance by the seller and the purchaser can purchase the item, or a method may be adopted within an appropriate range in which the price is changed to determine an agreeable price between the seller and the purchaser, as in an auction. The payment acceptance unit 31 accepts the payment of the payment value by the purchaser via a payment means linked to the account held by the purchaser (step S201). The value paid by the purchaser (in the example shown in the figure, 1,000 yen in Japanese yen, which is the legal currency of Japan) is deposited in the payment service (step S202), and the management system notifies the information processing device 1 that manages the marketplace that the payment (settlement) of the value has been made and completed (step S203). Thereafter, the process proceeds to step S204. Here, the payment service may be a financial system that can manage or link with the account of the system administrator. The payment of the value to the payment service (for example, deposit of legal currency) may be made before the settlement in the manner of step S202, or may be made after the settlement in the manner of deferred payment or the like.

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

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

[0052] 6 is a schematic diagram showing an example of the flow of the periodic tallying process according to this embodiment. The process shown in this schematic diagram is executed at a predetermined period (for example, once a month). 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.

[0053] First, the information processing device 1 subtracts a fee (50 yen in the example shown in the figure) as necessary from the value (1,000 yen in the example shown in the figure) paid by the purchaser and deposited in the settlement 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). After that, the process proceeds to step S303.

[0054] 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). The operator terminal that has received the notification of the completion of the remittance acquires sales records including the product name, the content provider name, the selling price, the payment ID, etc. for the specified period (e.g., the month) from the information processing device 1 that manages the marketplace (step S304). The information processing device 1 also authenticates the amount remitted to the marketplace account in step S302 with the system that manages the marketplace account (e.g., a bank system, etc.) (step S305). Thereafter, the processing shown in the drawing ends.

[0055] Fig. 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 a month) when the regular counting processing described with reference to Fig. 6 is completed. 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.

[0056] First, the value receipt confirmation unit 35 confirms that the seller and right holder of the product are scheduled to receive the amount of value (800 yen in the example shown in the figure) corresponding to the FT granted to the wallet of the content provider by referring to the wallet of the content provider, and further generates a payment list for transferring the actual value to the seller and right holder of the product (step S401). Note that in FIG. 7, 0 Coin is shown in the wallet of the content provider after the completion of the process, but 800 Coin is granted at the time of confirmation in step S401 (see FIG. 6), and it is understood that the content provider is scheduled 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 the like. When the receipt of the value (here, scheduled receipt) is confirmed in step S401, the FT management unit 34 incinerates the amount of FT (800 Coin in the example shown in the figure) corresponding to the amount of value (800 yen in the example shown in the figure) whose receipt was confirmed in step S401, out of the FTs granted to the wallet of the content provider, and transitions it to an unusable state (step S402). The process then proceeds to step S403.

[0057] The operator terminal acquires a payment list for the predetermined period (the month in this embodiment) from the information processing device 1 (step S403), and instructs the bank system to transfer the value (800 yen in the illustrated example) to be received by the seller and right holder of the product 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, which is the amount obtained by subtracting the 800 yen 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 process illustrated in the figure ends.

[0058] 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.

[0059] 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 that the seller and right holder of the product are scheduled to receive the amount of value (800 yen in the example shown in the figure) corresponding to the FT granted to the wallet of the content provider by referring to the wallet of the content provider. Note that in FIG. 8, 0 Coin is shown in the wallet of the content provider after the completion of the process, but 800 Coin is granted at the time of confirmation in step S501 (see FIG. 6), and it is understood that the content provider is scheduled to receive 800 yen. Then, when a withdrawal request is received from the content provider, the FT management unit 34 incinerates the amount of FT (800 Coin in the example shown in the figure) corresponding to the amount of value requested to be withdrawn in step S501 (800 yen in the example shown in the figure) among the FT granted to the wallet of the content provider, and transitions to an unusable state (step S502). After that, the process proceeds to step S503.

[0060] 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, which is the amount 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.

[0061] 9 is a schematic diagram showing an example of the flow of the secondary sales process of 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.

[0062] In steps S601 to S603, a purchase request for an NFT is received, and payment of the payment value is made. When an NFT is put up for sale on the marketplace by a seller, and the seller (here, a content provider or a user who purchased an NFT from another user) and the purchaser agree on the price of the NFT, the purchaser transmits a request to purchase the NFT to the information processing device 1 and performs a payment procedure. Note that the method of determining the price, the type of value used to pay for the NFT purchase price, 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 the payment of the payment value by the purchaser via the payment method linked to the account held by the purchaser (step S601). The value paid by the purchaser (1,000 yen in the example shown in the figure) is deposited in the payment service (step S602), and the management system notifies the information processing device 1 that the payment of the value has been made (step S603). After that, the process proceeds to step S604. It should be noted that payment of value to the payment service (for example, deposit of legal tender) may be performed before the payment in the manner of step S602, or may be performed after the payment in the manner of deferred payment or the like.

[0063] 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 an FT (50 Coins in the example shown in the figure, where the royalty is set to 5%) equivalent to the amount of value to be received by the content provider (right holder related to the product) out of the issued FT to the wallet of the content provider (step S605), grants an FT (50 Coins in the example shown in the figure, where the margin is set to 5%) equivalent to the amount of value to be received by the system administrator to the margin processing wallet of the marketplace (step S606), and grants an FT (900 Coins in the example shown in the figure) equivalent to the amount of value to be received by the seller of the product to the wallet of the user who is the seller of the product (step S607). In this embodiment, royalties and / or margins may be calculated by referring to "royaltyInfo" included in the metadata and / or token data.

[0064] Here, the NFT management unit 32 moves 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 movement of the NFT is performed simultaneously and inseparably with the granting of the FT to be received by the seller and / or the right owner to the wallet of the seller and / or the right owner (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 transferred to the seller's wallet and the NFT transferred from the seller to the buyer as an input to indicate the current owner and an output to indicate the transfer destination, so that the NFT is not 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 electronic signatures for the input and output 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 a transaction to transfer an NFT and / or an FT based on a transaction format that takes the form of an Unspent Transaction Output (UTXO), for example. 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 an NFT once sold, as well as transactions in which a general user sells an NFT as a content provider). However, such transaction processing on the blockchain 7 may also be adopted in transactions other than C2C (for example, B2C transactions). That is, even in the primary sales process described with reference to FIG. 5, the movement of the NFT may be performed simultaneously and inseparably with the granting of the FT to be received by the seller and / or right holder to the wallet of the seller and / or right holder. After that, the FT management unit 34 burns the FT granted to the margin processing wallet and transitions it to an unusable state (step S608), and the process shown in the figure ends.

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

[0066] <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 that is not centralized for data management while preventing data tampering, and also to allow users participating in a transaction to refer to the data (here, FT) that manages the amount of value.

[0067] Furthermore, according to the technology disclosed in the above embodiment, even if there are circumstances where a content provider does not want to store content in IPFS, it is possible to change the storage destination of the content to IPFS according to the request 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 the content data from the storage location of the metadata and including an IPFS-type CID in the metadata, it is possible to prevent the generation or tampering of counterfeit NFTs by third parties and to easily move NFTs to other blockchains (for example, switching from a private NFT to a public NFT (standard-type NFT)).

[0068] <Variations> FIG. 10 is a diagram showing an outline of the functional configuration of the information processing device 1b according to the 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 operating the FT according to the actual transfer of value is used to manage the value paid in a transaction of NFT, but the value management using FT described above may be used to manage the value to be paid in a transaction of products, services, etc. other than NFT. In this case, except that the trigger for starting the process is a product, service, etc. other than NFT, the contents of the processing by each functional unit are roughly the same. The information processing device 1b functions as an information processing device equipped with a payment acceptance unit 31, a FT issuing unit 33, a FT management unit 34, and a value receipt confirmation unit 35 by reading a program recorded in a storage device into a RAM and executing it by a CPU, and controlling each hardware equipped in the information processing device 1b.

[0069] FIG. 11 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 an identifier of the metadata in the blockchain 7 is performed together with the management of the value, but the metadata-related process can be widely used for NFT-related technologies. The information processing device 1c functions as an information processing device including a content identifier generating unit 21, a hash value acquiring unit 22, a metadata generating unit 23, a metadata adding unit 24, a metadata identifier acquiring unit 25, and an NFT issuing unit 26, by reading a program recorded in a storage device into a RAM and executing it by a CPU to control each hardware included in the information processing device 1c.

[0070] In addition, in the embodiment described above, an example was described in which metadata was added to IPFS. However, like content data, metadata may also be stored in a location-oriented data management system such as a CDN without being added to the content-oriented data management system, and only a CID may be generated and issued.

[0071] In the above-described embodiment, an example in which a blockchain is used as a distributed ledger has been described, but a distributed ledger that can be adopted in implementing 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]

[0072] 1. Information processing device

Claims

1. a fungible token issuing means for issuing, on a blockchain, a fungible token that is used to indicate the amount of payment value to be paid by a purchaser to purchase the product when a purchase request for the product is received, but is not used as the payment value itself, the amount of the fungible token corresponding to the amount of the payment value; A fungible token management means for granting, to a wallet of a user who is to receive at least a portion of the payment value, an amount of the fungible tokens issued by the fungible token issuing means, the amount of the fungible tokens corresponding to an amount of value that the user is to receive; and a value receipt confirmation means for confirming that a user who is to receive at least a portion of the payment value receives or has received an amount of value corresponding to the fungible token granted to the wallet of the user, The fungible token management means transitions the fungible tokens, of the fungible tokens granted to the user's wallet, in an amount corresponding to the amount of value whose receipt has been confirmed by the value receipt confirmation means, to an unusable state or moves the fungible tokens to a system administrator's wallet. Information processing system.

2. The fungible token management means assigns a first portion of the issued fungible token to a wallet of the seller of the product, and assigns a second portion of the issued fungible token to a wallet of a system administrator or transitions the second portion to an unusable state. The information processing system according to claim 1 .

3. the first portion of the fungible token corresponds to an amount of the payment value that the merchant is to receive; the second portion of the fungible token corresponds to an amount of the payment value to be received by the system administrator; The information processing system according to claim 2 .

4. The fungible token management means further grants a third portion of the issued fungible token to a wallet of a right holder related to the product.

4. The information processing system according to claim 2 or 3.

5. the third portion of the fungible tokens corresponds to an amount of the payment value that the rights holder should receive; 5. The information processing system according to claim 4.

6. The product includes a certain right or data related to the content linked to the non-fungible token, The system further includes a non-fungible token management means for transferring the non-fungible token related to the purchased product to the purchaser's wallet. The information processing system according to claim 1 .

7. the blockchain is a blockchain in which only users who have accounts managed by a predetermined management entity can participate as the purchaser, The purchaser's wallet is managed in association with the account. The information processing system according to claim 1 .

8. and a payment receiving means for receiving payment of the payment value by the purchaser via a payment means linked to the account held by the purchaser. The information processing system according to claim 7.

9. The system further comprises a point granting means for granting points, which can be used as at least a part of the payment value when purchasing the product, to the account held by the purchaser.

9. The information processing system according to claim 7 or 8.

10. the point granting means grants points that can be used as at least a part of a payment value for a second product different from the first product when the first product is purchased; The information processing system according to claim 9.

11. The computer a fungible token issuing step of issuing, on a blockchain, a fungible token in an amount corresponding to the amount of payment value, the fungible token being used to indicate the amount of payment value to be paid by the purchaser to purchase the product when a purchase request for the product is received, but not used as the payment value itself; a fungible token management step of granting, to a wallet of a user who is to receive at least a portion of the payment value, an amount of the fungible tokens issued in the fungible token issuing step, the amount of the fungible tokens corresponding to an amount of value that the user is to receive; A value receipt confirmation step in which a user who is to receive at least a portion of the payment value receives or confirms that the user has received an amount of value corresponding to the fungible token granted to the wallet of the user; In the fungible token management step, among the fungible tokens granted to the user's wallet, an amount of the fungible tokens corresponding to an amount of value whose receipt has been confirmed in the value receipt confirmation step is transitioned to an unusable state or moved to a system administrator's wallet. method.

12. On the computer, a fungible token issuing step of issuing, on a blockchain, a fungible token in an amount corresponding to the amount of payment value, the fungible token being used to indicate the amount of payment value to be paid by the purchaser to purchase the product when a purchase request for the product is received, but not used as the payment value itself; a fungible token management step of granting, to a wallet of a user who is to receive at least a portion of the payment value, an amount of the fungible tokens issued in the fungible token issuing step, the amount of the fungible tokens corresponding to an amount of value that the user is to receive; a value receipt confirmation step in which a user who is to receive at least a portion of the payment value receives or confirms that the user has received an amount of value corresponding to the fungible token granted to the wallet of the user; In the fungible token management step, among the fungible tokens granted to the user's wallet, an amount of the fungible tokens corresponding to an amount of value whose receipt has been confirmed in the value receipt confirmation step is transitioned to an unusable state or moved to a system administrator's wallet. program.

Images