Information processing methods, information processing systems, and programs

Abstract

This system allows users to purchase items or services with the same experience as purchasing items on conventional e-commerce sites, while providing end-to-end service including user authentication, issuance of ticket NFTs linked to the items or services, and proof of ticket NFT usage. [Solution] Upon receiving a purchase of an item or service by a user, a ticket NFT (Non-Fungible Token) for participation in an event associated with the item or service is issued on the blockchain system. By logging into a wallet application program pre-installed on the user's electronic device, a wallet is generated on the user's electronic device and the ticket NFT is sent.

Description

Technical Field

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

Background Art

[0002] There is known an information processing method in which a ticket NFT for participating in an event is issued on a blockchain system, a wallet address of the holder and a random number generated by the terminal device transmitted from the terminal device of the holder who has issued the ticket NFT are received by the system, a two-dimensional code including the wallet address and the random number generated by the terminal device is acquired by the system, and based on the received wallet address and random number and the wallet address and random number included in the acquired two-dimensional code, it is determined whether or not to allow entry to the event (Patent Document 1).

[0003] There is also known a program that causes a processor of a computer to execute steps of detecting the use of a ticket and, in response to the detection of the use of the ticket, giving a token whose ownership can be clarified to the owner of the ticket (Patent Document 2).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] The present invention enables purchase or reservation of an item or service with the same experience as purchasing an item on a conventional EC site, and provides a seamless process of user authentication, granting of a ticket NFT associated with the item or service, and proof of use of the ticket NFT. [Means for solving the problem]

[0006] To solve the above problem, the information processing method described in claim 1 is: Upon receiving a purchase or reservation of an item or service by a user, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. It is characterized by the following:

[0007] The invention described in claim 2 is the information processing method described in claim 1, The aforementioned wallet is generated when the user logs in to a wallet application program that is pre-installed on the electronic device. It is characterized by the following:

[0008] The invention described in claim 3 is the information processing method described in claim 1, The aforementioned ticket NFT is a non-transferable token. It is characterized by the following:

[0009] The invention described in claim 4 is an information processing method described in any one of claims 1 to 3, Upon detection of the use of the aforementioned ticket NFT, the user is granted a reward NFT (Non-Fungible Token) with clearly defined ownership. It is characterized by the following:

[0010] The invention described in claim 5 is the information processing method described in claim 4, The aforementioned reward NFT has a random drawing request according to a predetermined probability. It is characterized by the following:

[0011] The invention described in claim 6 is the information processing method described in claim 5, A predetermined incentive is given to the user who possesses the aforementioned reward NFT, in proportion to the number of reward NFTs held. It is characterized by the following:

[0012] To solve the aforementioned problems, the information processing system described in claim 7 is: It has a processor, The aforementioned processor, Upon receiving a purchase or reservation of an item or service by a user, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. It is characterized by the following:

[0013] The invention described in claim 8 is an information processing system described in claim 7, The processor, upon detection of the use of the ticket NFT, grants the user a reward NFT whose ownership can be clearly identified. It is characterized by the following:

[0014] To solve the above problem, the program described in claim 9 is: Upon receiving a purchase or reservation of an item or service by a user, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. To have the computer perform the process. It is characterized by the following:

[0015] The invention described in claim 10 is, in the program described in claim 9, Upon detection of the use of the aforementioned ticket NFT, the user is granted a reward NFT whose ownership can be clearly identified. This method is characterized by having a computer perform the processing.

Advantages of the Invention

[0016] According to the invention described in claim 1, an item or service can be purchased or reserved with an experience similar to item purchase on a conventional EC site, and it is possible to provide user authentication, the granting of a ticket NFT associated with the item or service, and the proof of use of the ticket NFT in a seamless manner.

[0017] According to the invention described in claim 2, it is possible to eliminate the need for users to create a wallet.

[0018] According to the invention described in claim 3, it is possible to ensure the identity between the event attendee and the owner.

[0019] According to the invention described in claim 4, it is possible to effectively motivate participation in the event.

[0020] According to the invention described in claim 5, it is possible to effectively motivate participation in the event.

[0021] According to the invention described in claim 6, it is possible to effectively motivate participation in the event.

[0022] According to the invention described in claim 7, an item or service can be purchased or reserved with an experience similar to item purchase on a conventional EC site, and it is possible to provide user authentication, the granting of a ticket NFT associated with the item or service, and the proof of use of the ticket NFT in a seamless manner.

[0023] According to the invention described in claim 8, it is possible to effectively motivate participation in the event.

[0024] According to the invention described in claim 9, an item or service can be purchased or reserved with an experience similar to item purchase on a conventional EC site, and it is possible to provide user authentication, the granting of a ticket NFT associated with the item or service, and the proof of use of the ticket NFT in a seamless manner.

[0025] According to the invention described in claim 10, it is possible to effectively motivate participation in an event. [Brief explanation of the drawing]

[0026] [Figure 1] This figure shows an example of the hardware configuration of an information processing system to which the information processing method according to this embodiment is applied. [Figure 2] This figure shows an example of the hardware configuration of a user terminal according to this embodiment. [Figure 3] This figure shows an example of the hardware configuration of the management server according to this embodiment. [Figure 4] This figure shows an example of the data structure for the user database, item purchase history database, and ticket grant history database. [Figure 5] This diagram shows an example of the data structure for the admission history database and the reward granting history database. [Figure 6] This figure shows an example of the hardware configuration of the ticket inspection terminal according to this embodiment. [Figure 7] This is a block diagram showing an example of the node configuration for the token management ledger. [Figure 8] This is a flowchart showing the user registration process in the information processing system of this embodiment. [Figure 9] This is a flowchart showing the process for purchasing or booking an item or service. [Figure 10] This flowchart shows the procedure for granting ticket NFTs associated with an item or service. [Figure 11] This is a flowchart showing the processing steps for remembering a wallet address. [Figure 12] This is a flowchart showing the ticket verification process for NFTs. [Figure 13] This flowchart shows the processing steps for granting reward NFTs. [Figure 14]This flowchart shows an example of the procedure for executing the lottery for the reward NFT. [Figure 15] This flowchart shows an example of the procedure for receiving reward NFTs. [Modes for carrying out the invention]

[0027] The present invention will now be described in more detail with reference to the drawings, with examples of embodiments and specific examples provided below, but the present invention is not limited to these embodiments and specific examples. Furthermore, it should be noted that the following diagrams are schematic and the proportions of the dimensions may differ from those of reality. For ease of understanding, diagrams of components other than those necessary for the explanation have been omitted as appropriate.

[0028] (1) Overall configuration of the information processing system Figure 1 shows an example of the hardware configuration of an information processing system 1 to which the information processing method according to this embodiment is applied. The information processing system 1 according to this embodiment provides users who purchase or reserve an item or service on an e-commerce (EC) site with a ticket NFT (Non-Fungible Token) to participate in an event associated with the item or service. If the user participates in the event, they are then given a reward NFT (Non-Fungible Token) as proof of participation. The reward NFT has a gacha element, which is a random draw request according to a predetermined probability. In this way, the information processing system 1 allows users to purchase or reserve an item or service with an experience similar to purchasing an item on a conventional e-commerce site, and provides end-to-end service including user authentication, provision of a ticket NFT associated with the item or service, and proof of use of the ticket NFT.

[0029] The information processing system 1 consists of a user terminal 10, a management server 20, and an admission ticket inspection terminal 30. The user terminal 10, the management server 20, and the entry ticket inspection terminal 30 are connected via a network (e.g., the Internet or an intranet). Furthermore, the information processing system 1 is connected to the token management ledger 40 and the external server 50 via a network NW.

[0030] The user terminal 10 is an information processing device used by a user of the information processing system 1. The user terminal 10 is configured to request information from the management server 20 regarding the purchase or reservation of items or services, the use of granted ticket NFTs, and the lottery for reward NFTs. In this respect, the user terminal 10 is an information processing terminal owned by the user who makes the purchase or reservation of items or services, and may include various computers such as smartphones, tablet terminals, personal computers, and wearable devices (smartwatches or smart glasses). In this embodiment, the user terminal 10 will be described using a smartphone, which is a mobile computer that can connect to a network NW, as an example.

[0031] Items or services refer to goods and services sold on e-commerce (EC) sites, and include digital items such as digital photographs, streaming music and videos, and game content, as well as reservations for free live performances and various events. In the following explanation, the purchase or reservation of an item or service may be simply referred to as the purchase of an item.

[0032] The management server 20 accepts the purchase or reservation of an item or service from the user terminal 10, as described later, and transmits the item or service information to the user terminal 10 of the user who purchased or reserved the item or service. The management server 20 also issues a ticket NFT (Non-Fungible Token) for participation in an event associated with the item or service through the token management ledger 40. The ticket NFT will be described later. The management server 20 transmits the issued ticket NFT to the user terminal 10 of the user who purchased or reserved the item or service. The management server 20 also detects the use of the issued ticket NFT (event participation information: ticket tampering information), as described later, and issues a reward NFT (Non-Fungible Token) through the token management ledger 40. The reward NFT will be described later. Finally, the management server 20 transmits the issued reward NFT to the user terminal 10 of the user who purchased or reserved the item or service.

[0033] The entrance ticket inspection terminal 30 verifies the ticket information held in the ticket presented by a person attempting to enter the event venue (hereinafter referred to as "visitor"), notifies the visitor who presents a valid ticket of permission to enter, and also notifies the management server 20 of this. Upon receiving the notification, the management server 20 marks the ticket as used. Marking a ticket as used is also called "tearing" it. In other words, if the ticket pertains to an event held at the event venue, the detection of ticket use is performed by tearing the ticket upon arrival at the event venue. Note that ticket use refers to the user using the ticket to enter the event venue. Furthermore, the functions of the entrance ticket inspection terminal 30 may be included in the user terminal 10.

[0034] Here, the event venue can be a real-world space or a virtual space. For example, a real-world space could be an entertainment venue (e.g., a concert hall, theater, sports venue, exhibition hall, shop, or a combination thereof), public transportation, an office, or a shop. Examples of events include live concerts, meet-and-greets, and autograph sessions.

[0035] The token management ledger 40 is implemented using a distributed ledger called blockchain and consists of multiple nodes 41. Each node 41 is, for example, a personal computer connected to a network. The nodes 41 are connected to the network NW by wired or wireless means and communicate with each other using a peer-to-peer method.

[0036] One of the multiple nodes 41 constituting the token management ledger 40 retrieves data related to token transactions to be recorded, creates a block containing the retrieved data, and adds it to the blockchain. Node 41 sends the information of the added block to the other nodes 41. The other nodes 41 verify the correctness of the received block, and if the correctness is verified, add it to the blockchain. Node 41 then finalizes the blockchain, for example, according to the number of blocks to be linked (number of confirmations). This ensures that the same token management ledger 40 is stored at each node 41. The stored data may be encrypted as appropriate. Thus, the token management ledger 40 stores data by generating units called blocks at regular intervals and linking them together in a chain. Therefore, once data within a block is recorded, it is difficult to retroactively modify that data.

[0037] The external server 50 comprises at least a storage unit and a communication interface. The storage unit stores digital item information and digital content that constitutes tokens. The external server 50 is managed, for example, by a content management company that operates digital items and digital content. The communication interface is configured to control communication between the external server 50 and at least one of the user terminal 10, the management server 20, the entry ticket inspection terminal 30, or the token management ledger 40. The management server 20 may also perform the functions of the external server 50.

[0038] (1.1) Configuration of user terminal 10 Figure 2 shows an example of the hardware configuration of the user terminal 10 according to this embodiment. The user terminal 10 is operated by the user who makes the purchase of an item, and consists of a control unit 11, a display unit 12 that displays a GUI screen that the user can operate, an input unit 13 that receives operation input from the user, a communication unit 14 that communicates with the outside world by wired or wireless connection, and a storage unit 15 that stores programs etc. executed by the control unit 11 and temporary information related to calculations of programs etc. Each component is connected by bus B.

[0039] The control unit 11 consists of a CPU (Central Processing Unit) 11a, a ROM (Read Only Memory) 11b that stores the BIOS (Basic Input / Output System) and operating system (OS) executed by the CPU 11a, and a RAM (Random Access Memory) 11c used as working memory for the CPU 11a. The control unit 11 performs processes such as acquiring, saving, displaying, and transmitting information related to the user terminal 10 through program execution.

[0040] The display unit 12 is composed of, for example, a liquid crystal display or an OLED (Organic Light Emitting Diode) display, and displays GUI screens, image data, etc. Specifically, it displays icons for operation, digital item information, transmitted ticket NFTs, reward NFTs, etc. The display unit 12 is integrated into the user terminal 10 and, in this embodiment, is the screen of a smartphone, and is formed integrally with the input unit 13, which will be described later, as a touch panel.

[0041] The input unit 13 is a device operated by the user, such as a keyboard, pointing device, buttons, microphone, webcam, or switch. Examples of pointing devices include a mouse, trackball, touch panel, or pen tablet. In this embodiment, it is a touch panel and physical buttons integrated with the display unit 12, and a sensor (for example, a camera, vital sensor, or a combination thereof).

[0042] The communication unit 14 consists of a communication interface and the like for communicating with external devices. The user terminal 10 is configured to send and receive various types of information to and from at least one of the following via the communication unit 14: the management server 20, the entry ticket inspection terminal 30, the token management ledger 40, or the external server 50.

[0043] The memory unit 15 is configured to store programs and data. The memory unit 15 is, for example, a combination of ROM (Read Only Memory), RAM (Random Access Memory), and storage (for example, flash memory).

[0044] (1-2) Configuration of the management server 20 Figure 3 shows an example of the hardware configuration of the management server 20 according to this embodiment, Figure 4 shows an example of the data structure of the user DB, item purchase history DB, and ticket grant history DB, and Figure 5 shows an example of the data structure of the entry history DB and benefit grant history DB. The management server 20 includes a control unit 21, a storage unit 22, a communication unit 23, an input unit 24, a display unit 25, and a large-capacity storage unit 26. Each component is connected by bus B.

[0045] The control unit 21 includes arithmetic processing units such as a CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), and DSP (Digital Signal Processor), which are examples of processors. The control unit 21 reads and executes the control program P stored in the storage unit 22, thereby performing various information processing and control processing related to the management server 20. In Figure 3, the control unit 21 is described as a single processor, but it may be a multi-processor system.

[0046] The storage unit 22 includes memory elements such as RAM (Random Access Memory) and ROM (Read Only Memory), and stores control programs P or data necessary for the control unit 21 to execute processing. The storage unit 22 also temporarily stores data necessary for the control unit 21 to execute arithmetic processing.

[0047] The communication unit 23 is a communication module for performing communication-related processing, and it transmits and receives various types of information via the network NW to at least one of the user terminal 10, the entry ticket inspection terminal 30, the token management ledger 40, or the external server 50.

[0048] The input unit 24 is an input device such as a mouse, keyboard, touch panel, or buttons, and outputs the received operation information to the control unit 21.

[0049] The display unit 25 is a liquid crystal display or an organic EL (electroluminescence) display, etc., and displays various information according to the instructions of the control unit 21.

[0050] The large-capacity storage unit 26 includes recording media such as an HDD (Hard disk drive) or an SSD (Solid State Drive). The large-capacity storage unit 26 includes a user (purchaser) database 261, an item purchase history database 262 (item purchase refers to the purchase or reservation of an item or service), a ticket grant history database 263, an admission history database 264, a benefit grant history database 265, and a winning status database 266.

[0051] The User (Purchaser) DB261 stores information about users. As shown in Figure 4(a), the User DB261 includes columns for User ID, Username, Holdings, Wallet, Ticket, and Personal Information. The User ID column stores the User ID to identify each user. The Username column stores the user's name. The Holdings column stores the quantity of Ticket NFTs held by the user. The Wallet column stores wallet information (e.g., the wallet's public key) where the Ticket NFTs held by the user are stored.

[0052] The item purchase history DB262 stores the history of items or services purchased or reserved by users from the e-commerce site. As shown in Figure 4(b), the item purchase history DB262 includes columns for purchase ID, purchaser, date, purchased item, and purchase amount. The Purchase ID column stores the Purchase ID assigned to each individual purchase history when a user purchases an item from the e-commerce site. The Purchaser column stores the User ID of the user who made the purchase. The Date column stores the date on which the user purchased the item. The Purchased Item column stores the name of the item purchased by the user. The Purchase Amount column stores the purchase amount of the item.

[0053] The ticket grant history DB263 stores the history of when ticket NFTs were granted to users (grant history). As shown in Figure 4(c), the ticket grant history DB263 includes an event column and a ticket NFT column.

[0054] The Event column stores event information associated with the purchased item. The Event column further includes Event ID, Event Name, Date and Time, Location, and Image columns. The Event ID column stores the unique ID of each event to identify it. The Event Name column stores the name of the event. The Date and Time column stores the date and time the event is held. The Location column stores the location where the event is held. The Image column stores an image or thumbnail image representing the event.

[0055] The Ticket NFT column stores information about the Ticket NFTs to be granted to the user. The Ticket NFT column further includes a User column, Wallet Address column, Grant Amount column, and Purchase ID column. The User column stores the User ID that identifies the user to whom the Ticket NFT was granted. The Wallet Address column stores the user's wallet address. The wallet address is an address created for each transaction when the user logs into a specific application on the user terminal 10 when purchasing an item, and is a mathematically derived address based on the public key cryptography used in the token management ledger 40. The wallet address is displayed as a string or a QR code (registered trademark). The wallet address is also recorded in the token management ledger 40 and cannot be tampered with. The Grant Amount column stores the quantity of Ticket NFTs granted to the user. The Purchase ID column stores the Purchase ID that identifies the purchase history of the item that triggered the granting of the Ticket NFT.

[0056] As shown in Figure 5(a), the entry history DB264 includes columns for Ticket ID, Event ID, Holder ID, and Entry Date and Time. The Ticket ID column stores the Ticket ID that identifies the ticket. The Event ID column stores the Event ID that identifies the event. The Holder ID column stores the Holder ID that identifies the holder. The Entry Date and Time column stores the date and time information of when the holder of the ticket NFT entered the event.

[0057] The reward granting history DB265 stores information about reward NFTs that are issued as proof of participation when an event is attended using a granted ticket NFT. The reward grant history DB265 includes a reward ID column and a reward column, as shown in Figure 5(b). The reward ID column stores a reward ID that uniquely identifies the reward. The reward column stores the content of the reward. A reward is, for example, the right to participate in a lottery game, which is a random lottery request according to a predetermined probability. As an example of such a lottery request, a gacha system is known where the probability of winning increases with the number of attempts, and eventually a winner is given. It should be noted that there may also be cases where no reward is given as a result of the lottery game.

[0058] The winning status DB266 stores the winning status of the prize NFTs awarded as proof of participation, based on the lottery conducted.

[0059] In this embodiment, the storage unit 22 and the large-capacity storage unit 26 of the management server 20 may be configured as a single storage device. Furthermore, the large-capacity storage unit 26 may be composed of multiple storage devices. Moreover, the large-capacity storage unit 26 may be an external storage device connected to the management server 20. The management server 20 may perform various information processing and control processes on a single computer, or it may be performed in a distributed manner across multiple computers. Furthermore, the management server 20 may be implemented using a cloud server.

[0060] (1-3) Configuration of the entrance ticket inspection terminal 30 Figure 6 shows an example of the hardware configuration of the entrance ticket inspection terminal 30 according to this embodiment. The entrance ticket inspection terminal 30 includes a control unit 31, a display unit 32, an input unit 33, a communication unit 34, a storage unit 35, and an authentication information reading unit 36. Each component is connected by bus B. The control unit 31, storage unit 32, communication unit 33, input unit 34, and display unit 35 of the entrance ticket inspection terminal 30 are the same as those of the control unit 11, display unit 12, input unit 13, communication unit 14, and storage unit 15 of the user terminal 10. The authentication information reading unit 36 ​​reads information necessary to determine whether a visitor is allowed to enter (hereinafter referred to as "authentication information") when a visitor presents their ticket. The function of the authentication information reading unit 36 ​​can also be realized by the camera provided in the user terminal 10. Therefore, the function of the entrance ticket inspection terminal 30 may be incorporated into the user terminal 10. The authentication information includes, for example, at least one of the following: ticket information, visitor features (e.g., facial features / voiceprint / palm print).

[0061] Each ticket has a designated area for reading ticket information, and the ticket information is displayed within this area. The authentication information reading unit 36 ​​can acquire ticket information, for example, by combining a visible light camera with an application that analyzes the image captured by the visible light camera to extract an image of the ticket information and then reconstructs the ticket information from the image.

[0062] (1-4) Configuration of the token management ledger 40 Figure 7 is a block diagram showing an example configuration of node 41 of the token management ledger 40. Node 41 of the token management ledger 40 includes a control unit 411, a storage unit 412, a communication unit 413, a reception unit 414, an output unit 415, a block generation unit 416, a block verification unit 417, and a block sharing unit 418. Each component is connected by bus B.

[0063] The control unit 411 autonomously and in a distributed manner cooperates with the control units of other nodes 41 to always maintain the latest ledger (a copy of the blockchain data) in the storage unit 412. The storage unit 412 stores the ledger containing transactions broadcast to the distributed network, as well as information necessary for verifying the information within a block.

[0064] The communication unit 413 is a communication module for performing communication-related processing. The reception unit 414 receives information from external nodes to be recorded in the decentralized network, which is the token management ledger 40. The output unit 415 outputs information from the token management ledger 40 that it holds in response to a request from an external node.

[0065] The block generation unit 416 generates a block to be added to the token management ledger 40 based on the information received by the reception unit 414. The block generation unit 416 generates a block that includes the information based on the previous block and the information received by the reception unit 414. Furthermore, the block generation unit 416 performs a predetermined consensus process, such as adding a signature, to the blocks it generates or to the blocks generated by other nodes 41 via the block sharing unit 418 (described later), and then adds the blocks to the token management ledger 40 that it manages. The blocks that are ultimately added to the token management ledger 40 are those obtained when multiple nodes 41 perform a predetermined consensus process on the blocks generated by the block generation unit 416.

[0066] The block verification unit 417 verifies the information within a block when adding it to the token management ledger 40 that it maintains.

[0067] The block sharing unit 418 exchanges information among the nodes 41 belonging to the token management ledger 40. More specifically, the block sharing unit 418 transmits information received by the receiving unit 414, blocks generated by the block generation unit 416, and blocks received from other nodes 41 to other nodes 41 as appropriate. This ensures that all nodes 41 share this information and the latest token management ledger 40 as much as possible.

[0068] Note that the configuration in Figure 7 is merely an example, and the specific configuration is not limited to any node 41 of the token management ledger 40 that is capable of performing a predetermined consensus process for multiple nodes 41 to share and manage the token management ledger 40, which is difficult to tamper with, and that can add information to the decentralized network and refer to information recorded in the decentralized network in response to requests from external nodes.

[0069] (2) Processing operation of Information Processing System 1 (2.1) User registration process Figure 8 is a flowchart showing the user registration process in the information processing system 1 of this embodiment. First, the user operates the input section 13 of the user terminal 10 to enter personal information such as their name and apply for membership registration (step S100).

[0070] After step S100, the management server 20 accepts the member registration application (step S101). After step S101, the management server 20 issues a user ID and login password (step S102). At this time, the management server 20 records the user's personal information, user ID, and password as a new record in the user database.

[0071] After step S102, the user terminal 10 receives the issued user ID and login password (step S103).

[0072] (2.2) Item purchase process Figure 9 is a flowchart showing the processing steps when purchasing or reserving (hereinafter simply referred to as "purchase") an item or service (hereinafter simply referred to as "item"). The control unit 11 of the user terminal 10 obtains information about the item from the item DB 261 of the management server 20 via the communication unit 14 (step S110). The information about the item includes the item ID, item name, item image, and price. The control unit 11 displays the obtained information about the item using the display unit 12 (step S111).

[0073] The control unit 11 receives a purchase request for the target item from the user via the input unit 13 (step S112). In response to the received purchase request, the control unit 11 transmits the user ID and purchase information to the management server 20 via the communication unit 14 (step S113). The purchase information includes the item ID, purchase quantity, purchase amount, or payment information. The control unit 21 of the management server 20 receives the user ID and purchase information transmitted from the user terminal 10 via the communication unit 23 (step S120).

[0074] The control unit 21 of the management server 20 retrieves item information from the item DB 261 of the large-capacity storage unit 26 based on the received purchase information (S121). Then, based on the purchase information, the control unit 21 performs payment processing for the item, for example, through a payment system or platform (step S122).

[0075] The control unit 21 stores the purchase history in the purchase history DB 265 of the large-capacity storage unit 26 (step S123). Specifically, the control unit 21 assigns a history ID and stores the item ID, owner ID (purchaser ID), purchase quantity, purchase amount, and purchase date and time as a single record in the purchase history DB 265, associating it with the assigned history ID.

[0076] The control unit 21 sends a message indicating the completion of payment to the user terminal 10 via the communication unit 23 (step S124). The control unit 11 of the user terminal 10 receives the payment completion message sent from the management server 20 via the communication unit 14 (step S114). The control unit 11 of the user terminal 10 displays the received payment completion message via the display unit 12 (step S115) and stores it in the purchase item list in the storage unit 15 (step S116), and then terminates the process.

[0077] (2.3) Ticket NFT assignment process Figure 10 is a flowchart showing the procedure for granting a ticket NFT associated with an item or service (hereinafter simply referred to as "item"). The management server 20 requests the user terminal 10 to install a dedicated application (step S125).

[0078] The user operates the user terminal 10 to obtain the dedicated application (step S117). Specifically, the user installs the dedicated application via the input unit 13 of the user terminal 10. After step S117, the user operates the user terminal 10 to log in to the installed dedicated application (S118). Specifically, the user operates the input section 13 of the user terminal 10 to enter the user ID and login password received in step S103. The user terminal 10, having received the login to the dedicated application, sends the login information to the management server 20 (step S119).

[0079] After step S119, the management server 20 receives the login information sent from the user terminal 10 (step S126). After step S126, the control unit 21 of the management server 20 sends a ticket NFT generation request to one of the nodes 41 of the token management ledger 40 via the communication unit 23 (step S127). The control unit 411 of node 41 of the token management ledger 40 receives the ticket NFT generation request sent from the management server 20 via the communication unit 413 (step S140).

[0080] The control unit 411 of node 41 generates a ticket NFT in response to the received request to generate a ticket NFT (S141). The control unit 411 stores the token ID, owner address, and token URI of the generated ticket NFT in the storage unit 412 (step S142). The control unit 411 transmits the generated ticket NFT to the management server 20 via the communication unit 413 (step S143).

[0081] The control unit 21 of the management server 20 receives the ticket NFT transmitted from node 41 of the token management ledger 40 via the communication unit 23 (step S128). The control unit 21 stores the holder information and the ticket NFT in the large-capacity storage unit 26 (step S129).

[0082] Specifically, the control unit 21 assigns a holder ID. The control unit 21 stores the holder's name, age, gender, and wallet address as a single record in the holder DB 264, associated with the assigned holder ID. The control unit 21 assigns a ticket ID to the ticket NFT issued on the token management ledger 40. The control unit 21 stores the event ID, ticket NFT (token ID, owner address or token URI, etc.) and holder ID as a single record in the ticket DB 263, associated with the assigned ticket ID.

[0083] The control unit 21 of the management server 20 transmits the ticket NFT issued on the token management ledger 40 based on the holder ID to the user terminal 10 via the communication unit 23 (step S1210). The control unit 11 of the user terminal 10 receives the ticket NFT transmitted from the management server 20 via the communication unit 14 (step S1110). The control unit 11 displays the received ticket NFT (token ID, owner address, token URI, etc.) via the display unit 12 (step S1111) and terminates the process. Note that the ticket NFT for participating in an event associated with an item or service may be a non-transferable token such as an SBT (Soulbound Token).

[0084] Figure 11 is a flowchart showing the processing steps when storing a wallet address. The control unit 11 of the user terminal 10 retrieves the holder's wallet address stored in the storage unit 15 (step S1112). The control unit 11 transmits the ticket ID, event ID, and the retrieved holder's wallet address to the management server 20 via the communication unit 14 (step S1113).

[0085] The control unit 21 of the management server 20 receives the ticket ID, event ID, and holder's wallet address transmitted from the user terminal 10 via the communication unit 23 (step S1211). The control unit 21 of the management server 20 stores the received holder's wallet address in the ticket DB 263 of the large-capacity storage unit 26, associating it with the ticket ID and event ID (step S1212), and terminates the process.

[0086] (2.4) Ticket NFT verification process Figure 12 is a flowchart showing the ticket verification process for NFTs. The control unit 11 of the user terminal 10 retrieves all ticket NFTs owned by the holder from node 41 of the token management ledger 40 via the communication unit 14, using the holder's wallet address (step S1114). Each ticket NFT includes a token ID, owner address, token URI, etc.

[0087] The control unit 11 of the user terminal 10 displays a list of acquired ticket NFTs via the display unit 12 (step S1115). The control unit 11 receives the selection of the target ticket NFT by the ticket NFT holder from among the multiple ticket NFTs via the input unit 13 (step S1116). The control unit 11 receives the event entry request from the ticket NFT holder via the input unit 13 (step S1117).

[0088] The control unit 11 of the user terminal 10 retrieves the holder's wallet address stored in the storage unit 15 (step S1118). The control unit 11 generates a two-dimensional code containing the retrieved holder's wallet address using, for example, a two-dimensional code generation library, and displays the generated two-dimensional code using the display unit 12 (step S1119).

[0089] The control unit 31 of the entry ticket inspection terminal 30 reads the two-dimensional code displayed on the user terminal 10 via the authentication information reading unit 36 ​​(step S130). The control unit 31 uses a two-dimensional code analysis library to obtain the holder's wallet address from the read two-dimensional code (step S131). The control unit 31 transmits the event ID that identifies the event and the obtained holder's wallet address to the management server 20 via the communication unit 34 (step S132).

[0090] The control unit 21 of the management server 20 receives the event ID and the holder's wallet address transmitted from the entry ticket inspection terminal 30 via the communication unit 23 (step S1213). Based on the received event ID and the holder's wallet address, the control unit 21 determines whether or not to allow the ticket NFT holder to enter the event.

[0091] Specifically, the control unit 21 of the management server 20 compares the event ID and wallet address received in step S1213 with the ticket data stored in the ticket DB 263 (step S1214). The control unit 21 of the management server 20 determines, based on the matching result, whether or not a wallet address of a holder that matches the received wallet address exists (step S1215). If the control unit 21 determines that a matching wallet address of a holder exists (step S1215: Yes), it determines that entry to the event is permitted (step S1216). The control unit 21 stores the entry history of the ticket NFT holder in the entry history DB 265 of the large-capacity storage unit 26 (step S1217). Specifically, the control unit 21 stores the event ID, holder ID, and entry date and time as a single record in the entry history DB 265, associated with the ticket ID. In this way, the "ticket tearing process" of the ticket NFT is performed.

[0092] If the control unit 21 of the management server 20 determines that no matching holder's wallet address exists (step S1215: No), it determines that entry to the event is denied (step S1218).

[0093] (2.4) Processing of granting reward NFTs Figure 13 is a flowchart showing the processing procedure when granting reward NFTs. If the control unit 21 of the management server 20 has executed the ticket tearing process for the previously issued ticket NFT, it sends a request to generate a reward NFT as an event participation certificate to one of the nodes 41 of the token management ledger 40 via the communication unit 23 (step S1220). The control unit 411 of node 41 of the token management ledger 40 receives the request to generate a reward NFT sent from the management server 20 via the communication unit 413 (step S144).

[0094] The control unit 411 of node 41 generates a reward NFT in response to the received reward NFT generation request (S145). The control unit 411 stores the token ID, owner address, and token URI of the generated reward NFT in the storage unit 412 (step S146). The control unit 411 transmits the generated reward NFT to the management server 20 via the communication unit 413 (step S147).

[0095] The control unit 21 of the management server 20 receives the reward NFT transmitted from node 41 of the token management ledger 40 via the communication unit 23 (step S1221). The control unit 21 stores the holder information and the reward NFT in the large-capacity storage unit 26 (step S1222). Specifically, the control unit 21 of the management server 20 assigns holder IDs. The control unit 21 stores the holder's name, age, gender, and wallet address as a single record in the holder DB 264, associated with the assigned holder ID. The control unit 21 assigns ticket IDs to the reward NFTs issued on the token management ledger 40. The control unit 21 stores the reward ID, reward NFT (token ID, owner address, or token URI, etc.), and holder ID as a single record in the ticket DB 263, associated with the assigned ticket ID.

[0096] The control unit 21 of the management server 20 transmits the reward NFT issued on the token management ledger 40 to the user terminal 10 via the communication unit 23 based on the holder ID (step S1223). The control unit 11 of the user terminal 10 receives the reward NFT transmitted from the management server 20 via the communication unit 14 (step S1120). The control unit 11 displays the received reward NFT (token ID, owner address, token URI, etc.) via the display unit 12 (step S1121) and terminates the process.

[0097] (2.5) Execution process for the prize NFT lottery Figure 14 is a flowchart illustrating an example of the procedure for executing a reward NFT lottery. The reward NFT lottery execution process is a process that, in accordance with the request of the user who has received the reward NFT, performs a random lottery game once according to a predetermined probability. When the user operates the user terminal 10 and instructs the application menu to run the lottery game, the lottery execution process begins. The user has received the reward NFT before the lottery is performed.

[0098] The control unit 11 of the user terminal 10 sends a request to the management server 20 to execute the lottery game (step S1122). This execution request includes the user ID. The control unit 21 of the management server 20 receives the execution request via the communication unit 23 (step S1224). The control unit 21 refers to the value of the ticket column in the holder DB 264 and determines whether the user possesses the reward NFT necessary to participate in the lottery game (step S1225). If the control unit 21 of the management server 20 determines that the user has the reward NFT necessary to participate in the lottery game (step S1225: Yes), it generates a random number (step S1226). The control unit 21 generates, for example, a 128-bit random number.

[0099] The control unit 21 of the management server 20 determines whether or not the winner has been selected (step S1227). Specifically, the control unit 21 determines whether the generated random number matches the value in the latter column of the winning number in the winning status DB 267, or whether some of the digits match, etc. If the control unit 21 of the management server 20 determines that there is a match, it compares the values ​​in the column for the maximum number of winners and the column for the cumulative number of winners in the winning status DB 267, and determines that the person has won if the cumulative number of winners has not reached the maximum number of winners (step S1227; Yes). If the control unit 21 determines that the person has not won (step S1227: No), or if there is a match but the cumulative number of winners has reached the maximum number of winners, it determines that the person has lost. If the control unit 21 determines that the person has not won (step S1227: No), it moves the process to step S1229. If the control unit 21 determines that the person has won (step S1227: Yes), it updates the value in the column for the cumulative number of winners in the winning status DB 267 (step S1228). The control unit 21 generates a notification of winning or losing (step S1229) and sends the notification (lottery result) to the user terminal 10 (step S1230). The control unit 11 of the user terminal 10 receives the notification via the communication unit 14 (step S1123) and displays the notification on the display unit 15 (step S1124).

[0100] If the control unit 21 of the management server 20 determines that the user does not possess the necessary reward NFT to participate in the lottery game (step S1227: No), it sends a notification to the user terminal 10 stating that the lottery game cannot be executed (step S1231). The control unit 11 of the user terminal 10 receives the notification of non-communication via the communication unit 14 (step S1125) and displays the notification of non-communication on the display unit 15 (step S1126).

[0101] (2.6) Processing of reward NFTs Figure 15 is a flowchart showing an example of the procedure for receiving reward NFTs. The process of receiving the bonus NFT is necessary if you win the bonus NFT lottery game. The control unit 11 of the user terminal 10 sends a request to receive the reward to the management server 20 (step S1127). The request includes the user ID. The control unit 21 of the management server 20 receives the request (step S1232). The control unit 21 sends an input screen to the user terminal 10 (step S1233). The control unit 11 of the user terminal 10 receives the input screen (step S1128) and displays it on the display unit 12 (step S1129). The user enters the necessary information. The necessary information includes the winning ID and contact email address. After entering the information, the user instructs to submit. The control unit 11 of the user terminal 10 sends the entered information to the management server 20 via the communication unit 13 (step S1130).

[0102] The control unit 21 of the management server 20 receives information via the communication unit 23 (step S1233). The control unit 21 then determines whether the request is valid or not (step S1234). Specifically, the control unit 21 determines that the request is valid if the user ID of the user making the request is stored in the winning status DB 267 and has not expired, and that it is not valid if it is not stored. If the control unit 21 determines that the request is valid (step S1234: Yes), it stores the received information in the storage unit 22 (step S1235). The control unit 21 sends a notification to the user terminal 10 that the request has been received (step S1236).

[0103] The control unit 11 of the user terminal 10 receives the notification via the communication unit 14 (step S1131). The control unit 11 displays the notification via the display unit 12 (step S1132) and terminates the process. The control unit 21 of the management server 20 separately performs the process of granting benefits to the user based on the stored information. If the control unit 21 of the management server 20 determines that the request is not valid (step S1234: No), it sends a rejection notice to the user terminal 10 indicating that the reward cannot be received (step S1237). The control unit 11 of the user terminal 10 receives the rejection notice via the communication unit 14 (step S1133). The control unit 11 displays the rejection notice on the display unit 12 (step S1134) and terminates the process.

[0104] The processes performed by the user terminal 10, the management server 20, and the entry ticket inspection terminal 30 according to this embodiment are each provided as programs, such as application software. These programs can be provided not only by communication means, but also by being stored on recording media such as CD-ROMs and USB drives.

[0105] In this embodiment, "system" includes both systems composed of multiple devices and systems composed of a single device. The configuration of the information processing system 1 described above is just one example; the information processing system 1 as a whole only needs to have the functionality to perform the processing described above, and some or all of the functions of the management server 20 may be functions of the user terminal 10. [Explanation of Symbols]

[0106] 1. Information Processing System 10. User terminal 11...Control unit, 12...Display unit, 13...Input unit, 14...Communication unit, 15...Storage unit 20. Management Server 21...Control Unit, 22...Storage Unit, 23...Communication Unit, 24...Input Unit, 25...Display Unit, 26...Large Capacity Storage Unit, 261...User DB, 262...Item Purchase History DB, 263...Ticket Issuance History DB, 264...Entry History DB, 265...Benefit Issuance History DB, 266...Winning Status DB 30... Entrance ticket inspection terminal 31... Control unit, 32... Display unit, 33... Input unit, 34... Communication unit, 35... Storage unit, 36... Authentication information reading unit 40. Token Management Ledger 41...Node, 411...Control Unit, 412...Storage Unit, 413...Communication Unit, 414...Reception Unit, 415...Output Unit, 416...Block Generation Unit, 417...Block Verification Unit, 418...Block Sharing Unit 50...External Server

Claims

1. Upon receiving a user's purchase or reservation of an item or service, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. An information processing method characterized by the following:

2. The aforementioned wallet is generated when the user logs in to a wallet application program that is pre-installed on the electronic device. The information processing method according to feature 1.

3. The aforementioned ticket NFT is a non-transferable token. The information processing method according to feature 1.

4. Upon detection of the use of the aforementioned ticket NFT, the user is granted a reward NFT (Non-Fungible Token) with clearly defined ownership. The information processing method according to any one of claims 1 to 3.

5. The aforementioned NFT (Non-Functional Token) has a random drawing request according to a predetermined probability. The information processing method according to feature 4.

6. The user who possesses the aforementioned reward NFT is given a predetermined incentive in proportion to the number of reward NFTs he holds. The information processing method according to feature 5.

7. It has a processor, The aforementioned processor, Upon receiving a user's purchase or reservation of an item or service, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. An information processing system characterized by the following:

8. The processor, upon detection of the use of the ticket NFT, grants the user a reward NFT whose ownership can be clearly identified. The information processing system according to feature 7.

9. Upon receiving a user's purchase or reservation of an item or service, a ticket NFT (Non-Fungible Token) for participation in an event associated with the said item or service is issued on the blockchain system, a wallet is generated on the user's electronic device, and the ticket NFT is sent to the said electronic device. A program that instructs a computer to perform a process.

10. Upon detection of the use of the aforementioned ticket NFT, the user is granted a reward NFT whose ownership can be clearly defined. The program according to claim 9, which causes a computer to perform a process.

Images