JP2023157295A - Information processing method, information processing device, and program - Google Patents

Abstract

To provide an information processing method and the like that allow a block chain network used in receiving a transaction object NFT to be specified.SOLUTION: An information processing method includes: receiving, when a purchaser of a transaction object including goods or a service receives a transaction object NFT corresponding to the transaction object, selection as to whether to receive it via a public block chain network or to receive it via a private block chain network; giving, when receiving selection of the public block chain network, the transaction object NFT to the purchaser on the public block chain network and performing processing of providing the transaction object; and giving, when receiving selection of the private block chain network, the transaction object NFT to the purchaser on the private block chain network and performing processing of providing the transaction object.SELECTED DRAWING: Figure 1

Description

The present invention relates to an information processing method, an information processing device, and a program.

In recent years, non-fungible token type electronic ticket issuance technology has been attracting attention. Patent Document 1 discloses an electronic ticket management system that can guarantee the ownership history of tickets throughout the period before and after the performance, and can add utility value to the ticket other than participation in the performance. .

Patent No. 6967116

However, the invention according to Patent Document 1 has a problem in that a ticket purchaser cannot specify a blockchain network to be used when receiving a ticket NFT (Non-Fungible Token).

One aspect of the present invention is to provide an information processing method and the like that can specify a blockchain network to be used when receiving NFTs to be traded (for example, ticket NFTs).

According to one aspect of the information processing method, when a purchaser of a transaction object including goods or services receives a transaction object NFT corresponding to the transaction object, the purchaser receives the transaction object NFT through a public blockchain network or through a private blockchain network. If the selection of the public blockchain network is accepted, granting the transaction target NFT to the purchaser on the public blockchain network, and performing a process of providing the transaction target; When the selection of the private blockchain network is accepted, the transaction target NFT is granted to the purchaser on the private blockchain network, and the transaction target is provided. .

In one aspect, it becomes possible to specify the blockchain network to be used when receiving NFTs to be traded.

It is an explanatory diagram showing an outline of a ticket purchase system. FIG. 2 is a block diagram showing a configuration example of a server. It is an explanatory diagram showing an example of record layout of purchaser DB and ticket DB. It is an explanatory diagram showing an example of record layout of purchase history DB and network DB. FIG. 2 is a block diagram showing an example of the configuration of a node. FIG. 2 is a block diagram showing a configuration example of a purchaser terminal. FIG. 6 is an explanatory diagram illustrating ticket issuance processing when refusing to receive a ticket NFT. It is an explanatory diagram explaining ticket issuance processing when receiving a ticket NFT. It is an explanatory diagram showing an example of a ticket purchase confirmation screen. It is an explanatory diagram showing an example of a display screen of a privilege. It is a flowchart showing a processing procedure when issuing a ticket to which a ticket NFT is not attached. It is a flowchart showing a processing procedure when issuing a ticket to which a ticket NFT is attached. It is a flowchart showing a processing procedure of a subroutine of processing for issuing a ticket NFT. It is an explanatory diagram explaining ticket NFT change processing. It is a flowchart showing a processing procedure when performing ticket NFT change processing. It is a flowchart showing the processing procedure of a subroutine of processing for changing a ticket NFT. It is an explanatory diagram showing an example of a selection acceptance screen of a blockchain network. It is a flowchart which shows the processing procedure when giving a part of transfer cost to a related party. FIG. 2 is an explanatory diagram illustrating a process of allocating costs to related parties using a smart contract.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described in detail below based on drawings showing embodiments thereof.

(Embodiment 1)
In Embodiment 1, when a purchaser of a transaction object receives the transaction object NFT corresponding to the transaction object, the transaction object NFT is granted to the purchaser on the selected blockchain network, and the transaction object's NFT is granted to the purchaser on the selected blockchain network. This relates to a form of executing provision processing.

The transaction object includes goods or services. Products are, for example, digital content (music, movie or game characters, etc.), art works (paintings, sculptures, illustrations, photographs, etc.), tickets (admission tickets) for concerts, competitions, amusement parks, etc., or traded as goods. This includes clothes, shoes, bags, furniture, etc. Services include, for example, fan club services, sports club member services, and the like. In this embodiment, an example in which the transaction object is a ticket will be described, but the present invention can be similarly applied to other types of transaction objects. In the following, for the sake of brevity, the transaction object will be read as a ticket.

NFT is digital data with a certificate of authenticity or ownership certificate, and like virtual currency, blockchain technology is used for data management, making it impossible to tamper with or forge. Ticket NFT is issued on a blockchain system, and by linking the ticket and NFT, it is proof that the person owns the ticket.

FIG. 1 is an explanatory diagram showing an overview of the ticket purchasing system. The system of this embodiment includes an information processing device 1, a public blockchain system 2, a private blockchain system 3, and an information processing terminal 4, and each device transmits and receives information via a network N such as the Internet.

The information processing device 1 is an information processing device that processes, stores, transmits and receives various information. The information processing device 1 is, for example, a server device, a personal computer, a general-purpose tablet PC (personal computer), or the like. In this embodiment, the information processing device 1 is assumed to be a server device, and will be read as server 1 below for brevity.

The public blockchain system 2 is a public distributed ledger technology or distributed network. The public blockchain system 2 is composed of a plurality of nodes 21 that perform consensus processing. Each of the nodes 21 maintains a copy of the blockchain data throughout the execution of the consensus process. The public blockchain system 2 stores data by generating data units called blocks at regular intervals and connecting them like a chain.

The public blockchain system 2 is autonomously managed through the use of a peer-to-peer network and distributed timestamp servers. Since data is stored in a chain, once data in a block is stored, it is difficult to modify the data retroactively. The unit of data may be an individual transaction instead of a block. Furthermore, data may be stored in a storage format other than a chain, such as a directed acyclic graph. In the following, for the sake of brevity, public blockchain system 2 will be read as public BC2.

Public BC2 is a blockchain that does not have an administrator, and anyone who can connect to network N such as the Internet can participate in transactions without permission. Since public BC2 is completely open, the legitimacy of transactions can be ensured through mining approval without an administrator. Public BC2 is a decentralized network that does not require a trusted administrator due to information sharing and mutual monitoring.

The private blockchain system 3 is a private distributed ledger technology or distributed network. Note that the configuration of the private blockchain system 3 is the same as the configuration of the public BC 2, so a description thereof will be omitted. In the following, for the sake of brevity, private blockchain system 3 will be read as private BC3.

Private BC3 is a blockchain that has a specific administrator (operator) and can only be used by limited participants. Private BC3 is a centralized network, and although it is not transparent, privacy is ensured because it is not disclosed to the outside world, and data can be stored on the blockchain within a closed system.

Unlike the public BC 2 where the total number of participants is unknown, the private BC 3 knows the number of participants, so it is possible to obtain agreement by majority vote. Furthermore, since the number of nodes 21 in the public BC 2 is greater than the number of nodes 31 in the private BC 3, it takes time and transaction time to form a consensus.

In addition, in this embodiment, although the example of public BC2 and private BC3 was demonstrated, it is not limited to this. For example, it can be similarly applied to consortium blockchain networks.

The information processing terminal 4 is a terminal device that purchases tickets and receives ticket NFTs corresponding to the tickets. The information processing terminal 4 is an information processing device such as a smartphone, a mobile phone, a wearable device such as an Apple Watch (registered trademark), a tablet, or a personal computer terminal. In the following, for the sake of brevity, the information processing terminal 4 will be read as the purchaser terminal 4.

The server 1 according to the present embodiment accepts a selection from a ticket purchaser as to whether to receive the ticket NFT corresponding to the ticket using the public BC 2 or the private BC 3. When the server 1 receives the selection of the public BC2, it grants the purchaser a ticket NFT on the public BC2, and executes the process of providing the ticket. When the server 1 receives the selection of the private BC 3, it grants the purchaser a ticket NFT on the private BC 3 and executes the process of providing the ticket.

FIG. 2 is a block diagram showing an example of the configuration of the server 1. As shown in FIG. The server 1 includes a control section 11 , a storage section 12 , a communication section 13 , an input section 14 , a display section 15 , a reading section 16 , and a large-capacity storage section 17 . Each configuration is connected by bus B.

The control unit 11 includes arithmetic processing units such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), and a GPU (Graphics Processing Unit), and reads out a control program 1P (program product) stored in the storage unit 12. When executed, various information processing, control processing, etc. related to the server 1 are performed. The control program 1P also includes programs that execute processing such as generation and execution of smart contracts such as Ethereum and Mist Wallet, remittance of virtual currency, account creation, and mining. Note that although the control unit 11 is described as being a single processor in FIG. 2, it may be a multiprocessor.

The storage unit 12 includes memory elements such as a RAM (Random Access Memory) and a ROM (Read Only Memory), and stores a control program 1P or data necessary for the control unit 11 to execute processing. Further, the storage unit 12 temporarily stores data and the like necessary for the control unit 11 to perform arithmetic processing. The communication unit 13 is a communication module for performing communication-related processing, and sends and receives information to and from the node 21 of the public BC 2, the node 31 of the private BC 3, the purchaser terminal 4, etc. via the network N.

The input unit 14 is an input device such as a mouse, a keyboard, a touch panel, or a button, and outputs the received operation information to the control unit 11. The display unit 15 is a liquid crystal display, an organic EL (electroluminescence) display, or the like, and displays various information according to instructions from the control unit 11.

The reading unit 16 reads a portable storage medium 1a including a CD (Compact Disc)-ROM or a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 16 and store it in the mass storage unit 17. Alternatively, the control unit 11 may download the control program 1P from another computer via the network N or the like and store it in the mass storage unit 17. Furthermore, the control unit 11 may read the control program 1P from the semiconductor memory 1b.

The large-capacity storage unit 17 includes a recording medium such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The mass storage unit 17 includes a purchaser DB (database) 171, a ticket DB 172, a purchase history DB 173, and a network DB 174.

The purchaser DB 171 stores information regarding purchasers. The ticket DB 172 stores information regarding tickets. The purchase history DB 173 stores the purchase history of tickets purchased by the purchaser. Network DB 174 stores information regarding the blockchain network.

Note that in this embodiment, the storage section 12 and the large-capacity storage section 17 may be configured as an integrated storage device. Furthermore, the large-capacity storage section 17 may be configured with a plurality of storage devices. Furthermore, the large-capacity storage section 17 may be an external storage device connected to the server 1.

The server 1 may perform various information processing, control processing, etc. on a single computer, or may be distributed and executed on multiple computers. Further, the server 1 may be realized by a plurality of virtual machines provided within one server, or may be realized using a cloud server.

FIG. 3 is an explanatory diagram showing an example of the record layout of the purchaser DB 171 and the ticket DB 172.
The purchaser DB 171 includes a purchaser ID column, a name column, a payment method column, and a registered card column. The purchaser ID column stores uniquely specified IDs of purchasers in order to identify each purchaser. The name column stores the name of the purchaser.

The payment method column stores the payment method used when the purchaser purchases a ticket. Payment methods include, for example, cash, bank account transfer, cashless payment (credit card, code payment, electronic money payment, etc.), virtual currency (crypto assets), and the like. Note that the payment method in this embodiment is exemplified as payment by credit card. The registered card column stores information such as the card number and expiration date registered when making a payment using a credit card or the like.

The ticket DB 172 includes a ticket ID column, a category column, a seat type column, a content column, an amount column, and a fee column. The ticket ID column stores a uniquely specified ticket ID in order to identify each ticket. The category column stores the ticket category (eg, concert or competition). The seat type column stores the type of seat (for example, regular seat or reserved seat). The content column stores the content of the ticket. The amount column stores the amount of the ticket. The fee column stores ticket issuance fees.

FIG. 4 is an explanatory diagram showing an example of the record layout of the purchase history DB 173 and the network DB 174.
The purchase history DB 173 includes a purchaser ID column, a ticket ID column, an amount column, a fee column, a purchase date and time column, an NFT receipt status column, a network ID column, a type column, and a ticket NFT column. The purchaser ID column stores a purchaser ID that identifies the purchaser. The ticket ID column stores ticket IDs that identify tickets. The amount column stores the amount paid by the purchaser. The fee column stores the issuance fee paid at the time of ticket purchase. The purchase date and time column stores date and time information when the purchaser purchased the ticket.

The NFT receipt status column stores the ticket NFT receipt status corresponding to the purchased ticket. The receiving status includes, for example, receiving or refusing to receive. The network ID column stores a network ID that identifies a blockchain network. The type column stores the type of blockchain network.

The ticket NFT column stores ticket NFTs issued on the public BC2 or private BC3. For example, a ticket NFT that can prove "value" may be issued on public BC2 using ERC721, which is one of Ethereum's smart contract standards. When ERC721 is used, the ticket NFT includes a token ID, an owner address, a token URI (Uniform Resource Identifier), and the like.

For example, the ticket NFT column stores an index on the blockchain that includes the token ID, owner address, token URI, etc. of the ticket NFT. Note that when the ticket NFT is issued, the token ID, owner address, token URI, etc. of the ticket NFT are stored on the blockchain. The token URI is an attribute that indicates the location of metadata for the ticket NFT. The location of the metadata is, for example, the URL (Uniform Resource Locator) of the target data (image, video, etc.). Note that the metadata itself may be stored in an external database device, for example, in JSON (JavaScript Object Notation) format.

The network DB 174 includes a network ID column, a type column, a name column, and a benefit column. The network ID column stores network IDs of blockchain networks that are uniquely identified in order to identify each blockchain network. The type column stores the type of blockchain network. Types of blockchain networks include public blockchain networks, private blockchain networks, consortium blockchain networks, and the like. The name column stores the name of the blockchain network.

The benefit column stores available benefit information in the target blockchain network. Since the ticket NFT is issued separately from the ticket, a purchaser (user) who does not use it for admission can own only the ticket NFT. By providing various benefits to the ticket NFT, the added value of the ticket NFT is increased. Benefits include, for example, distribution and viewing of content such as music, videos, or images, discounts when purchasing related products, participation in specific events, point redemption, or receiving special goods (e.g., books, magazines, or gift cards). include. Further, it is possible to give more benefits to a ticket NFT issued on the public BC2 than to a ticket NFT issued on the private BC3.

Note that the storage format of each DB described above is an example, and other storage formats may be used as long as the relationship between data is maintained.

FIG. 5 is a block diagram showing an example of the configuration of a node. FIG. 5A is a block diagram showing a configuration example of the node 21 of the public BC 2. As shown in FIG.
The node 21 of the public BC 2 includes a control section 211, a storage section 212, a communication section 213, a reception section 214, an output section 215, a block generation section 216, a block verification section 217, and a block sharing section 218. Each configuration is connected by bus B.

The control unit 211 cooperates with the control units of other nodes 21 (terminals) in an autonomous and decentralized manner to always maintain the latest blockchain (ledger: copy of blockchain data) in the storage unit 212. The storage unit 212 stores a blockchain (ledger) that includes transactions broadcast to a distributed network, information necessary for verification processing of information in the block, and the like.

The communication unit 213 is a communication module for performing processing related to communication. The reception unit 214 receives information to be recorded in a distributed network, which is a blockchain managed by the public BC 2, from an external node. The output unit 215 outputs blockchain information held by itself in response to a request from an external node.

The block generation unit 216 generates a block to be added to the blockchain based on the information received by the reception unit 214. The block generation unit 216 generates a block including information based on the previous block and information received by the reception unit 214. In addition, the block generation unit 216 searches for a nonce as a predetermined consensus process for blocks generated by itself or blocks generated by nodes 21 of other blockchains via a block sharing unit 218 (described later). After processing or adding a signature, the block is added to the blockchain (ledger) that it manages. Note that the block generated by the block generation unit 216 by a plurality of nodes 21 performing a predetermined consensus process becomes the block finally added to the public BC2.

The block verification unit 217 verifies the information in the block when adding a block to the blockchain it owns. Normally, the block to be added is the block for which the rule is satisfied earliest in the group of nodes 21 including the own node, but in consideration of the case where a malicious node 21 is included, etc. You may also verify whether the requirements are met.

The block sharing unit 218 exchanges information between the nodes 21 belonging to the public BC 2. More specifically, the block sharing unit 218 appropriately transmits the information received by the reception unit 214, the block generated by the block generation unit 216, the block received from other nodes 21, etc. to other nodes 21. This allows all nodes 21 to share this information and the latest public BC2 as much as possible.

Note that the configuration in FIG. 5A is just an example, and the blockchain node 21 is capable of executing a predetermined consensus process for sharing and managing the public BC2, which is difficult to tamper with, among multiple nodes. The specific configuration does not matter as long as the node can add information to the distributed network and refer to information recorded in the distributed network in response to a request from the distributed network.

FIG. 5B is a block diagram showing a configuration example of the node 31 of the private BC 3. The node 31 of the private BC 3 includes a control section 311, a storage section 312, a communication section 313, a reception section 314, an output section 315, a block generation section 316, a block verification section 317, and a block sharing section 318. Note that the configuration of the node 31 of the private BC 3 is the same as the configuration of the node 21 of the public BC 2, so a description thereof will be omitted.

Note that the server 1 may be the node 21 of the public BC 2 or the node 31 of the private BC 3.

FIG. 6 is a block diagram showing an example of the configuration of the purchaser terminal 4. As shown in FIG. The purchaser terminal 4 includes a control section 41, a storage section 42, a communication section 43, an input section 44, and a display section 45. Each configuration is connected by bus B.

The control unit 41 includes arithmetic processing units such as a CPU and an MPU, and performs various information processing and control processing related to the purchaser terminal 4 by reading and executing a control program 4P (program product) stored in the storage unit 42. etc. Furthermore, the control program 4P includes programs that execute processes such as generation and execution of smart contracts such as Ethereum and Mist Wallet, remittance of virtual currency, account creation, and mining. Note that although the control unit 41 is described as being a single processor in FIG. 6, it may be a multiprocessor.

The storage unit 42 includes memory elements such as RAM and ROM, and stores the control program 4P or data necessary for the control unit 41 to execute processing. Furthermore, the storage unit 42 temporarily stores data and the like necessary for the control unit 41 to perform arithmetic processing. The communication unit 43 is a communication module for performing communication-related processing, and sends and receives information to and from the server 1 and the like via the network N. The input unit 44 may be a keyboard, a mouse, or a touch panel integrated with the display unit 45. The display section 45 is a liquid crystal display, an organic EL display, or the like, and displays various information according to instructions from the control section 41.

FIG. 7 is an explanatory diagram illustrating a ticket issuance process when refusing to receive a ticket NFT.
When the purchaser terminal 4 receives instruction information indicating whether or not the ticket purchaser receives the ticket NFT, the purchaser terminal 4 determines whether or not the ticket purchaser receives the ticket NFT based on the received instruction information. When the purchaser terminal 4 determines that the ticket NFT has not been received, the purchaser terminal 4 transmits instruction information regarding receipt of the ticket NFT to the server 1 in association with the purchaser ID and the ticket ID. The server 1 receives the purchaser ID, ticket ID, and instruction information transmitted from the purchaser terminal 4. The server 1 generates only an admission code based on the received purchaser ID and ticket ID.

The entrance code is, for example, a two-dimensional code or a one-dimensional code. A two-dimensional code is a display type code that has information in the horizontal and vertical directions, unlike a one-dimensional code that only has information in the horizontal direction. Typical two-dimensional codes are, for example, QR Code (registered trademark), DataMatrix (registered trademark), or VeriCode (registered trademark). The one-dimensional code is, for example, a barcode. This embodiment will be described as an example in which a QR code for admission is read.

Specifically, the server 1 uses a two-dimensional code generation library to generate a QR code that includes the purchaser ID of the purchaser and the ticket ID of the target ticket purchased by the purchaser. Note that the items embedded in the two-dimensional code are not limited to the above-mentioned purchaser ID and ticket ID, but arbitrary items may be set according to actual needs.

The server 1 stores the amount, fee, purchase date and time, and NFT reception status of "reception refused" in the purchase history DB 173 as one record in association with the purchaser ID and ticket ID. The server 1 transmits the generated QR code for admission to the purchaser terminal 4 of the purchaser. The purchaser terminal 4 receives the QR code for admission transmitted from the server 1, and displays the received QR code on the screen.

Note that the QR code for admission may be sent to the purchaser using email, SNS (Social Networking Service), SMS (Short Message Service), or the like. Alternatively, the QR code for admission may be printed and sent to the purchaser by mail or the like.

FIG. 8 is an explanatory diagram illustrating the ticket issuance process when receiving a ticket NFT. When the purchaser terminal 4 receives instruction information indicating whether or not the ticket purchaser receives the ticket NFT, the purchaser terminal 4 determines whether or not the ticket purchaser receives the ticket NFT based on the received instruction information. When the purchaser terminal 4 determines to receive the ticket NFT, it acquires a plurality of blockchain networks from the network DB 174 of the server 1 in order to select a blockchain network to be used when receiving the ticket NFT. The purchaser terminal 4 displays the plurality of acquired blockchain networks in a selectable manner.

The blockchain network includes public BC2, private BC3, etc. The public BC2 includes, for example, the Bitcoin (registered trademark) network, the Ethereum (registered trademark) network, the Polygon network, or the like. The private BC 3 includes, for example, a Hyperledger Fabric network, a permission type Quorum network, or the like.

The purchaser terminal 4 accepts the purchaser's selection of a blockchain network. The purchaser terminal 4 transmits instruction information regarding receipt of the ticket NFT and the network ID of the selected blockchain network to the server 1 in association with the purchaser ID and ticket ID. The server 1 receives the purchaser ID, ticket ID, instruction information, and network ID transmitted from the purchaser terminal 4.

The server 1 acquires the type of blockchain network corresponding to the network ID from the network DB 174 according to the received instruction information and network ID. The server 1 determines whether the selected blockchain network is a public BC2 or a private BC3, depending on the type of acquired blockchain network.

When the server 1 determines that the selected blockchain network is the public BC2, it creates (issues) a ticket NFT on the public BC2. For example, if the selected blockchain network is Ethereum, the server 1 creates a ticket NFT using ERC721, which is one of Ethereum's smart contract standards.

If the ERC721 standard is used, all ticket NFTs on the public BC2 are disclosed, but since they cannot be tampered with, it becomes possible to add owner or attribution information, etc. The token ID, owner address, token URI, etc. of the created ticket NFT are stored on the public BC2.

Note that when the ticket NFT is issued to the administrator, the administrator transfers the ticket NFT held by the administrator to the target purchaser. In this case, the public BC2 inherits the token ID and token URI (metadata location) of the ticket NFT. The public BC2 changes the owner address of the ticket NFT from the administrator's owner address to the target purchaser's owner address. The public BC 2 records the token ID (unchanged) of the ticket NFT after the transfer, the owner address after the change, the token URI (unchanged), etc.

In addition, ticket NFT owners can freely trade ticket NFTs in the same way as crypto assets by buying, selling, or transferring ticket NFTs.

When the server 1 determines that the selected blockchain network is a private BC 3 according to the type of acquired blockchain network, it creates a ticket NFT on the private BC 3.

The server 1 creates the above-mentioned ticket NFT and also generates a QR code for admission. Note that the QR code generation process is the same as the QR code generation process described above, so a description thereof will be omitted. The server 1 associates the purchaser ID and ticket ID with the amount, fee, purchase date and time, NFT receipt status of "receipt", network ID, blockchain network type, and ticket NFT (for example, token ID, owner address or token URI) is stored in the purchase history DB 173 as one record.

The server 1 transmits the created ticket NFT and the generated QR code for admission to the purchaser terminal 4. The purchaser terminal 4 receives the ticket NFT and QR code for admission transmitted from the server 1, and displays the received ticket NFT and QR code for admission on the screen. For example, the purchaser terminal 4 displays the token ID, owner address, and token URI of the ticket NFT on the screen along with the QR code for admission. The token URI is, for example, the URL of a benefit page that indicates a benefit (for example, an image or a video) given to the ticket NFT. When the purchaser terminal 4 receives a touch operation of the token URI, the purchaser terminal 4 displays an image or video posted on the site specified by the URL of the benefit page.

FIG. 9 is an explanatory diagram showing an example of a ticket purchase confirmation screen. FIG. 9A is a purchase confirmation screen when refusing to receive the ticket NFT. FIG. 9B is a purchase confirmation screen when receiving a ticket NFT. 9A or 9B includes a ticket display field 11a, a receipt check box 11b, a payment field 11c, and a purchase button 11d.

The ticket display field 11a is a display field that displays the contents of the ticket. The receipt check box 11b is a check box that allows the purchaser to select whether or not to receive the ticket NFT corresponding to the ticket when purchasing the ticket. The payment field 11c is a field for accepting payment method settings. The purchase button 11d is a button for purchasing a ticket.

The purchaser terminal 4 transmits the purchaser ID and ticket ID to the server 1. The server 1 receives the purchaser ID and ticket ID transmitted from the purchaser terminal 4. The server 1 acquires information (card number, expiration date, etc.) regarding the registered card registered in advance from the purchaser DB 171 based on the received purchaser ID. Based on the ticket ID, the server 1 acquires ticket information including the ticket seat type, contents (name, opening date and time, etc.), price, fee, etc. from the ticket DB 172.

The server 1 transmits the acquired ticket information and information regarding the registered card to the purchaser terminal 4. The purchaser terminal 4 receives and displays the ticket information and information regarding the registered card transmitted from the server 1. Specifically, the purchaser terminal 4 displays the received ticket information in the ticket display field 11a, and displays information regarding the registered card in the payment field 11c.

When the purchaser terminal 4 receives the check operation of the receipt check box 11b, it acquires instruction information indicating whether or not to receive the ticket NFT. When the purchaser terminal 4 determines to receive the ticket NFT (checks the receipt checkbox 11b) according to the acquired instruction information, the purchaser terminal 4 acquires information regarding the plurality of blockchain networks from the network DB 174 of the server 1. Information regarding the blockchain network includes a network ID, a network name, and the like.

The purchaser terminal 4 generates a network selection field 11e and a benefit display button 11f, and displays the generated network selection field 11e and benefit display button 11f on the screen (FIG. 9B). The network selection field 11e is a combo box for selecting a blockchain network. The purchaser terminal 4 sets the acquired plurality of blockchain networks in the network selection column 11e.

When the purchaser terminal 4 receives the selection operation in the network selection column 11e, it acquires the network ID of the selected blockchain network. When the purchaser terminal 4 receives a touch (click) operation on the benefit display button 11f, the purchaser terminal 4 transitions to a benefit display screen (FIG. 10) to be described later. When the purchaser terminal 4 receives a touch operation on the purchase button 11d, the purchaser terminal 4 sends instruction information regarding receipt of the ticket NFT and the network ID of the selected blockchain network to the server 1 in association with the purchaser ID and ticket ID. Send.

FIG. 10 is an explanatory diagram showing an example of a privilege display screen. Available benefits in public BC2 or private BC3 may be different. The purchaser confirms the benefits of public BC2 and private BC3, and then selects the blockchain network for issuing the ticket NFT.

The specific display screen includes a public BC2 benefit display field 11g, a private BC3 benefit display field 11h, and a back button 11i. The public BC2 benefit display column 11g stores available benefit information in the public BC2. The private BC3 benefit display column 11g stores available benefit information in the private BC3. The return button 11i is a button to return to the previous screen.

The purchaser terminal 4 acquires available benefit information in the public BC 2 and available benefit information in the private BC 3 from the network DB 174 of the server 1, depending on the type of blockchain network. The purchaser terminal 4 displays the obtained benefit information available in the public BC2 in the public BC2 benefit display column 11g. The purchaser terminal 4 displays the obtained benefit information available in the private BC3 in the private BC3 benefit display column 11h.

Note that in this embodiment, an example of benefits given according to the type of blockchain network has been described, but the invention is not limited to this. For example, benefits may be given for each blockchain network. When the purchaser terminal 4 receives a touch operation on the back button 11i, the purchaser terminal 4 transitions to a purchase confirmation screen (FIG. 9B) for receiving a ticket NFT.

FIG. 11 is a flowchart showing the processing procedure when issuing a ticket to which a ticket NFT is not attached. The control unit 41 of the purchaser terminal 4 receives, through the input unit 44, instruction information for the ticket purchaser to refuse to receive the ticket NFT (step S401). The control unit 41 transmits the purchaser ID, the ticket ID of the target ticket purchased by the purchaser, and the received instruction information to the server 1 through the communication unit 43 (step S402).

The control unit 11 of the server 1 receives the purchaser ID, ticket ID, and instruction information transmitted from the purchaser terminal 4 through the communication unit 13 (step S101). The control unit 11 uses a two-dimensional code generation library to generate an admission code (for example, a QR code) including the purchaser ID and ticket ID (step S102).

The control unit 11 stores the purchase information in the purchase history DB 173 of the mass storage unit 17 in association with the purchaser ID and ticket ID (step S103). Specifically, the control unit 11 stores the amount, fee, purchase date and time, and NFT reception status of "reception refused" in the purchase history DB 173 as one record in association with the purchaser ID and ticket ID.

The control unit 11 transmits the generated admission code to the purchaser terminal 4 via the communication unit 13 (step S104). The control unit 41 of the purchaser terminal 4 receives the admission code transmitted from the server 1 through the communication unit 13 (step S403). The control unit 41 displays the received entrance code on the display unit 45 (step S404), and ends the process.

FIG. 12 is a flowchart showing the processing procedure when issuing a ticket to which a ticket NFT is attached. The control unit 41 of the purchaser terminal 4 receives, through the input unit 44, instruction information for the ticket purchaser to receive the ticket NFT (step S411). The control unit 41 acquires a plurality of blockchain networks from the network DB 174 of the mass storage unit 17 of the server 1 via the communication unit 43 (step S412).

The control unit 41 displays the acquired plurality of blockchain networks on the display unit 45 (step S413). The control unit 41 receives the purchaser's selection of a blockchain network through the input unit 44 (step S414). The control unit 41 transmits the purchaser ID, ticket ID, instruction information, and network ID of the selected blockchain network to the server 1 via the communication unit 43 (step S415).

The control unit 11 of the server 1 receives the purchaser ID, ticket ID, instruction information, and network ID transmitted from the purchaser terminal 4 through the communication unit 13 (step S111). The control unit 11 uses a two-dimensional code generation library to generate an admission code (for example, a QR code) including the purchaser ID and ticket ID (step S112). The control unit 11 executes a subroutine for issuing a ticket NFT (step S113). Note that the subroutine for ticket NFT issuance processing will be described later.

The control unit 11 stores the purchase information in the purchase history DB 173 of the mass storage unit 17 in association with the purchaser ID and ticket ID (step S114). Specifically, the control unit 11 associates the purchaser ID and ticket ID with the amount, fee, purchase date and time, NFT receipt status of "receipt", and ticket NFT (contract address or token ID, etc.). It is stored in the purchase history DB 173 as one record.

The control unit 11 transmits the generated admission code and the generated ticket NFT to the purchaser terminal 4 via the communication unit 13 (step S115). The control unit 41 of the purchaser terminal 4 receives the admission code and ticket NFT transmitted from the server 1 through the communication unit 13 (step S416). The control unit 41 displays the received admission code and ticket NFT on the display unit 45 (step S417), and ends the process.

FIG. 13 is a flowchart showing a subroutine processing procedure for issuing a ticket NFT. The control unit 11 of the server 1 acquires the type of the blockchain network from the network DB 174 of the mass storage unit 17 according to the network ID (step S01). The control unit 11 determines whether the selected blockchain network is the public BC2 according to the type of the acquired blockchain network (step S02).

When the control unit 11 determines that the selected blockchain network is the public BC2 (YES in step S02), it issues a ticket NFT to the purchaser on the public BC2 (step S03). The control unit 11 ends the ticket NFT issuing subroutine and returns. For example, if the selected blockchain network is Ethereum, the control unit 11 issues a ticket NFT using ERC721, which is one of Ethereum's smart contract standards.

Specifically, the control unit 11 transmits a ticket NFT issuance instruction to one of the nodes 21 of the public BC 2 through the communication unit 13. The control unit 211 of the node 21 of the public BC 2 receives the ticket NFT issuance instruction transmitted from the server 1 through the communication unit 213. The control unit 211 of the node 21 issues the ticket NFT on the public BC 2 in accordance with the received issuing instruction. The control unit 211 of the node 21 stores the token ID, owner address, and token URI of the issued ticket NFT in the storage unit 212. The control unit 211 of the node 21 transmits the issued ticket NFT to the server 1 through the communication unit 213. The control unit 11 of the server 1 receives the ticket NFT transmitted from the node 21 of the public BC 2 through the communication unit 13.

When the control unit 11 determines that the selected blockchain network is not the public BC2 (NO in step S02), it issues a ticket NFT to the purchaser on the selected private BC3 (step S04). The control unit 11 ends the ticket NFT issuing subroutine and returns.

Specifically, the control unit 11 transmits a ticket NFT issuance instruction to one of the nodes 31 of the private BC 3 via the communication unit 13. The control unit 311 of the node 31 of the private BC 3 receives the ticket NFT issuance instruction transmitted from the server 1 through the communication unit 313. The control unit 311 of the node 31 issues the ticket NFT on the private BC 3 in accordance with the received issuing instruction. The control unit 311 of the node 31 stores the token ID, owner address, and token URI of the issued ticket NFT in the storage unit 312. The control unit 311 of the node 31 transmits the issued ticket NFT to the server 1 through the communication unit 313. The control unit 11 of the server 1 receives the ticket NFT transmitted from the node 31 of the private BC 3 through the communication unit 13.

According to this embodiment, it is possible to provide a purchaser with a ticket to which a ticket NFT can be attached.

According to this embodiment, when a ticket purchaser receives a ticket NFT corresponding to the ticket, it becomes possible to select whether to receive it through the public BC 2 or the private BC 3.

According to this embodiment, by separating the ticket and the ticket NFT, it becomes possible to issue only the ticket without the ticket NFT attached to the purchaser.

(Embodiment 2)
Embodiment 2 relates to a form in which a ticket NFT issued on the private BC 3 is changed to a ticket NFT on the public BC 2. Note that descriptions of contents that overlap with those of Embodiment 1 will be omitted.

FIG. 14 is an explanatory diagram illustrating ticket NFT change processing. When the server 1 receives a request to change the ticket NFT of owner A issued on the private BC, the server 1 changes the private BC 3 to the private BC 3 via a cross-chain network that is independently interconnected to the private BC 3 and the public BC 2. Change the ticket NFT issued above to a ticket NFT on public BC2.

A cross-chain network is a network built based on a protocol that allows value to be transferred accurately and quickly between multiple blockchains. Cross-chain networks include, for example, Polkadot, Cosmos, International Blockchain Consulting (IBC), Atomic Swaps, or PolyNetwork. Note that the present invention is not limited to the exemplary cross-chain network, and any network and protocol capable of interconnecting different blockchains may be used.

Below, a ticket NFT change process when using IBC will be explained. The server 1 receives from the purchaser terminal 4 a request to change the ticket NFT (hereinafter referred to as old ticket NFT) issued on the private BC 3 and the network ID of the public BC 2 to which the change is to be made. The server 1 transmits a lock instruction to lock the old ticket NFT on the private BC 3 to any node 31 of the private BC 3 via the IBC. The node 31 of the private BC 3 locks the old ticket NFT in response to the lock instruction sent from the server 1 via the IBC.

The server 1 transmits an issuance notification for issuing a new ticket NFT to any node 21 of the public BC 2 corresponding to the network ID of the public BC 2 to be changed via the IBC. The node 21 of the relevant public BC 2 issues a ticket NFT (hereinafter referred to as new ticket NFT) on the relevant public BC 2 in response to the new ticket NFT issuance notification sent from the server 1 via the IBC. do. For example, the node 21 of the public BC 2 issues a new token ID and owner address, and inherits the token URI (metadata location) from the original private BC 3.

The server 1 sends a burn notification of the old ticket NFT to any node 31 of the private BC 3 via the IBC. The node 31 of the private BC 3 burns the old ticket NFT in response to the old ticket NFT burn notification sent from the server 1 via the IBC. Burning is effectively destroying a token by sending it to an address that does not have the private key to own the token ID.

By performing the above processing, it is possible for the owner of the ticket NFT to change the old ticket NFT issued on the private BC 3 to a new ticket NFT on the public BC 2.

FIG. 15 is a flowchart showing the processing procedure when changing the ticket NFT. After issuing the ticket NFT on the private BC 3, the control unit 11 of the server 1 acquires the plurality of public BCs 2 and available benefit information in each public BC 2 from the network DB 174 of the mass storage unit 17 (step S121). . The benefit information is, for example, information indicating benefits such as the application of discounts when distributing/viewing content such as music, videos, or images, or purchasing related products.

The control unit 11 transmits, via the communication unit 13, guidance information for changing the ticket NFT to a ticket NFT on the public BC 2, the acquired plurality of public BCs 2, and available benefit information on each public BC 2 to the purchaser terminal 4. (Step S122). The control unit 41 of the purchaser terminal 4 receives the guidance information, the plurality of public BCs 2, and the benefit information transmitted from the server 1 through the communication unit 43 (step S421).

The control unit 41 displays the received guidance information, the plurality of public BCs 2, and the benefit information on the display unit 45 (step S422). The control unit 41 receives the purchaser's selection of the public BC 2 through the input unit 44 in accordance with the guide information and benefit information (step S423). The control unit 41 transmits the purchaser ID and the network ID of the selected public BC 2 to the server 1 via the communication unit 43 (step S424).

The control unit 11 of the server 1 receives the purchaser ID and network ID transmitted from the purchaser terminal 4 through the communication unit 13 (step S123). The control unit 11 executes a subroutine for changing the ticket NFT (step S124). Note that the subroutine for ticket NFT change processing will be described later.

The control unit 11 updates the purchase information based on the received purchaser ID (step S125). Specifically, based on the purchaser ID, the control unit 11 stores the network ID of the public BC 2, the type of blockchain network that is "public", and information issued on the public BC 2 in the purchase history DB 173 of the mass storage unit 17. Update the ticket NFT.

The control unit 11 transmits the changed ticket NFT to the purchaser terminal 4 via the communication unit 13 (step S126). The control unit 41 of the purchaser terminal 4 receives the changed ticket NFT transmitted from the server 1 through the communication unit 13 (step S425). The control unit 41 displays the received changed ticket NFT on the display unit 45 (step S426), and ends the process.

FIG. 16 is a flowchart showing a subroutine processing procedure for changing a ticket NFT. The control unit 11 of the server 1 transmits a lock instruction to lock the old ticket NFT on the private BC 3 to any node 31 of the private BC 3 via the communication unit 13 via a cross-chain network (for example, IBC) ( Step S11). The control unit 311 of the node 31 of the private BC 3 receives the lock instruction transmitted from the server 1 via the cross-chain network by the communication unit 313 (step S12). The control unit 311 of the node 31 locks the old ticket NFT in response to the received lock instruction (step S13).

The control unit 11 of the server 1 causes the communication unit 13 to send an issuance notification for issuing a new ticket NFT to any node 21 of the public BC 2 corresponding to the network ID of the public BC 2 to be changed via the cross-chain network. Transmit (step S14). The control unit 211 of the node 21 of the corresponding public BC 2 receives the new ticket NFT issuance notification transmitted from the server 1 via the communication unit 213 via the cross-chain network (step S15). The control unit 211 of the node 21 issues a new ticket NFT on the public BC 2 in response to the received issuance notification (step S16).

The control unit 11 of the server 1 transmits a burn notification to burn the old ticket NFT to any node 31 of the private BC 3 via the cross-chain network by the communication unit 13 (step S17). The control unit 311 of the node 31 receives the old ticket NFT burn notification transmitted from the server 1 via the communication unit 313 via the cross-chain network (step S18). The control unit 311 of the node 31 burns the old ticket NFT in response to the received burn notification (step S19). The control unit 11 of the server 1 ends the ticket NFT change processing subroutine and returns.

Further, when a ticket NFT issued on the private BC 3 is changed to a ticket NFT on the public BC 2, a privilege can be given to the owner. For example, the owner may be provided with benefits such as viewing video content or applying a discount when shopping.

According to this embodiment, it is possible to change a ticket NFT issued on the private BC 3 to a ticket NFT on the public BC 2.

(Embodiment 3)
Embodiment 3 relates to a form in which a ticket NFT corresponding to the ticket is issued on the website of a provider that provides the ticket. Note that descriptions of contents that overlap with those of Embodiments 1 and 2 will be omitted.

A ticket NFT corresponding to the ticket can be issued and sold on the website of the ticket provider. Specifically, the server 1 outputs a reception screen on the provider's website that accepts the selection of either the public BC 2 or the private BC 3. The server 1 accepts the purchaser's selection of a blockchain network on the output reception screen. The server 1 executes the ticket NFT issuance procedure on the selected blockchain network.

Further, the server 1 displays the first wallet address of the provider's ticket NFT on the public BC2 and the second wallet address of the ticket NFT on the private BC3 on the provider's website.

FIG. 17 is an explanatory diagram showing an example of a blockchain network selection acceptance screen. The selection reception screen includes a ticket display field 12a, a network selection field 12b, and an issue button 12c. The ticket display field 12a is a display field that displays the contents of the ticket. The network selection field 12b is a selection field for selecting a blockchain network. The issue button 12c is a button for issuing a ticket NFT.

Based on the ticket ID, the server 1 acquires ticket information including the ticket seat type, contents (name, opening date and time, etc.), price, fee, etc. from the ticket DB 172. The server 1 acquires information regarding multiple blockchain networks from the network DB 174. Information regarding the blockchain network includes network ID, type, network name, etc.

Server 1 obtains the provider's wallet address on each blockchain network. Note that the provider's wallet address may be stored in advance in the storage unit 12 or the mass storage unit 17 for each blockchain network. The server 1 transmits the acquired ticket information, information regarding a plurality of blockchain networks, and the provider's wallet address on each blockchain network to the provider's website.

The server 1 displays ticket information in the ticket display field 12a on the website. The server 1 displays information regarding each blockchain network (network name, type, etc.) and the provider's wallet address in each network selection column 12b on the website.

When the provider selects a blockchain network through the network selection field 12b, the server 1 acquires the network ID of the blockchain network selected through the network selection field 12b. When the provider touches (clicks) the issue button 12c, the server 1 executes ticket NFT issue processing (issuance procedure) on the corresponding blockchain network based on the acquired network ID. Note that the ticket NFT issuance process is the same as in the first embodiment, so the explanation will be omitted.

According to this embodiment, it is possible to issue a ticket NFT corresponding to the ticket on the website of the provider that provides the ticket.

(Embodiment 4)
Embodiment 4 relates to a mode in which, when a ticket NFT is transferred, a part of the cost associated with the transfer is given to the person concerned with the ticket. Note that descriptions of contents that overlap with those of Embodiments 1 to 3 will be omitted.

The ticket NFT corresponding to the ticket purchased by the first purchaser can be transferred to the second purchaser. If the ticket NFT is transferred, there will be costs associated with the transfer. Further, a part of the incurred expenses can be given to the person concerned with the ticket. For example, the parties involved in the ticket include, as an example of a concert ticket, a planner who plans a concert, an operator who operates a concert, an organizer or performer of the concert, and the like.

FIG. 18 is a flowchart illustrating the processing procedure for allocating a portion of the transfer fee to a related party. When the ticket NFT is transferred, the control unit 11 of the server 1 obtains the transfer fee associated with the transfer (step S131). For example, if the transfer fee is stored in the storage unit 12 or the large-capacity storage unit 17, the control unit 11 acquires the transfer fee from the storage unit 12 or the large-capacity storage unit 17.

The control unit 11 acquires stakeholder information in the ticket corresponding to the ticket NFT (step S132). The related party information includes, for example, a related party ID or a transfer fee receiving method (for example, account information or wallet address), and is stored in advance in the storage unit 12 or the mass storage unit 17. Note that the number of related parties may be one or more.

Based on the acquired transfer fee and related party information, the control unit 11 calculates a fee (part of the transfer fee) to be given to the related party based on a predetermined standard (step S133). For example, the transfer fee may be multiplied by a predetermined percentage (for example, 5%) to calculate the fee to be given to the parties involved. It should be noted that the cost given to the parties concerned may be a fixed amount.

The control unit 11 grants the calculated fee to the person concerned based on the method of receiving the transfer fee included in the person concerned information (step S134), and ends the process. Note that there are no particular limitations on the method of allocating expenses to the parties involved, and legal currency (remittance via account, cash, credit card, etc.) or crypto assets such as Bitcoin or Ethereum may be used.

Furthermore, smart contracts on the blockchain can allocate a portion of the transfer cost to each party.
FIG. 19 is an explanatory diagram illustrating the process of allocating costs to related parties using a smart contract. Owner A, who owns the ticket NFT, can transfer the ticket NFT to owner B. For example, when a ticket NFT is issued to owner A using ERC721, the ticket NFT includes a token ID, an owner address, and a token URI.

When the ticket NFT owner A transfers the ticket NFT to the owner B, the transfer of the ticket NFT can be done by changing the address of the owner A to the address of the owner B on ERC721. complete it. A portion of the costs incurred due to the transfer of the ticket NFT will be given to each person involved in the ticket using a smart contract.

A smart contract is a system in which the definition of execution conditions and contract contents is programmed in advance and incorporated into a transaction, and when a transaction that meets the execution conditions and contract contents occurs, the contract is automatically executed.

The server 1 generates a smart contract code that describes the necessary execution conditions, contract details, wallet addresses of each party, etc. to perform the process of allocating expenses to each party. The server 1 records in advance a transaction including the generated smart contract code on a blockchain (public BC2 or private BC3).

In this embodiment, the smart contract code defines a contract to pay a fee (virtual currency) calculated according to predetermined standards to the wallet address of each party when the ticket NFT is transferred. There is. Note that in this embodiment, a single smart contract is included in a single transaction, but the present invention is not limited to this. For example, multiple linked smart contracts may be included in a single or multiple transactions.

As illustrated, the transaction includes the code of the smart contract, the token ID corresponding to the ticket NFT, the transfer fee, and the electronic signatures of each party (eg, party A and party B). If the execution conditions regarding the transfer of the ticket NFT are met, the blockchain will pay the amount of virtual currency determined in the contract from the wallet address of owner B (transferee) to the wallet addresses of each party involved. .

For example, if the transfer cost is 100 virtual currencies, based on the contract details, 10 virtual currencies, which is 10% of the transfer cost, will be given to party A, and 20 virtual currency, which is 20% of the transfer cost, will be given to the party A. It may be given to Person B. Note that owner B's virtual currency may be deposited in the smart contract in advance. In this case, the corresponding amount of virtual currency from the deposited virtual currency will be paid to each party's wallet address.

According to this embodiment, when a ticket NFT corresponding to a ticket is transferred, a part of the cost associated with the transfer can be given to the person concerned with the ticket.

The embodiments disclosed herein are illustrative in all respects and should be considered not to be restrictive. The scope of the present invention is indicated by the claims rather than the above-mentioned meaning, and is intended to include meanings equivalent to the claims and all changes within the scope.

Items described in each embodiment can be combined with each other. Moreover, the independent claims and dependent claims recited in the claims may be combined with each other in any and all combinations, regardless of the form in which they are cited. Furthermore, although the scope of claims uses a format in which claims refer to two or more other claims (multi-claim format), the invention is not limited to this format. It may be written using a multi-claim format that cites at least one multi-claim (multi-multi-claim).

1 Information processing device (server)
11 Control section 12 Storage section 13 Communication section 14 Input section 15 Display section 16 Reading section 17 Mass storage section 171 Purchaser DB
172 Ticket DB
173 Purchase history DB
174 Network DB
1a Portable storage medium 1b Semiconductor memory 1P Control program 2 Public blockchain system (Public BC)
21 node 211 control unit 212 storage unit 213 communication unit 214 reception unit 215 output unit 216 block generation unit 217 block verification unit 218 block sharing unit 3 private blockchain system (private BC)
31 node 311 control unit 312 storage unit 313 communication unit 314 reception unit 315 output unit 316 block generation unit 317 block verification unit 318 block sharing unit 4 information processing terminal (purchaser terminal)
41 Control unit 42 Storage unit 43 Communication unit 44 Input unit 45 Display unit 4P control program

Claims (12)

When a purchaser of a transaction object including goods or services receives a transaction object NFT corresponding to the transaction object, the purchaser receives a choice of receiving the transaction object through a public blockchain network or a private blockchain network;
If the selection of the public blockchain network is accepted, granting the purchaser the NFT to be traded on the public blockchain network, and performing a process of providing the transaction target;
An information processing method, wherein when the selection of the private blockchain network is accepted, an NFT to be traded is granted to the purchaser on the private blockchain network, and a process for providing the transaction target is executed. The information processing method according to claim 1, wherein the transaction object is not added to the transaction object NFT. After issuing the NFT to be traded on the private blockchain network, receiving a change request to change the issued NFT to be traded to an NFT to be traded on the public blockchain network;
The information processing method according to claim 1 or 2, wherein the NFT to be traded is changed to an NFT to be traded on the public blockchain network in accordance with a received change request. Selectable output of multiple public blockchain networks,
The information processing method according to claim 1 or 2, wherein a selection of a public blockchain network is accepted from a plurality of output public blockchain networks. Selectable output of multiple public blockchain networks,
The information processing method according to claim 3, wherein a selection of a public blockchain network is accepted from a plurality of output public blockchain networks. 3. The information processing method according to claim 1, wherein when the NFT to be traded is transferred, a part of the cost associated with the transfer is given to a person related to the NFT to be traded. Accepting a selection as to whether or not to receive the NFT to be traded,
The information processing method according to claim 1 or 2, wherein when a selection not to receive the NFT to be traded is accepted, processing for providing the NFT to be traded is executed without issuing the NFT to be traded. Outputting a screen on the website of the provider that provides the transaction object to accept the selection of either a public blockchain network or a private blockchain network,
Accept the network selection on the output screen,
The information processing method according to claim 1 or 2, further comprising executing an issuance procedure for the NFT to be traded on a selected network. A first wallet address on a public blockchain network of the NFT to be traded of the provider and a second wallet address on a private blockchain network of the NFT to be traded of the provider are displayed on the website. Information processing method described. When event ticket purchasers receive their ticket NFTs, they will be given the choice of receiving them via a public blockchain network or a private blockchain network;
If the selection of the public blockchain network is accepted, granting a ticket NFT to the ticket purchaser on the public blockchain network and issuing an entry code to the event;
3. When the selection of the private blockchain network is accepted, a ticket NFT is granted to the ticket purchaser on the private blockchain network, and an entry code to the event is issued. Information processing method. When a purchaser of a transaction object including goods or services receives the transaction object NFT corresponding to the transaction object, a reception unit accepts a selection of whether to receive it through a public blockchain network or a private blockchain network; ,
a first execution unit that, when receiving the selection of the public blockchain network, grants the purchaser the NFT to be traded on the public blockchain network and executes a process for providing the transaction target;
an information processing unit that, when receiving the selection of the private blockchain network, grants the purchaser the NFT to be traded on the private blockchain network and executes a process of providing the transaction target; Device. When a purchaser of a transaction object including goods or services receives a transaction object NFT corresponding to the transaction object, the purchaser receives a choice of receiving the transaction object through a public blockchain network or a private blockchain network;
If the selection of the public blockchain network is accepted, granting the purchaser the NFT to be traded on the public blockchain network, and performing a process of providing the transaction target;
A program that causes a computer to perform a process of granting a transaction target NFT to the purchaser on the private blockchain network and executing a process of providing the transaction target when the selection of the private blockchain network is accepted.

Images