JP2023180915A - Non-fungible token management device - Google Patents

Abstract

To provide a non-fungible token management device that can issue non-fungible tokens coordinated with information in real society in a block chain.SOLUTION: A management server 200 is configured comprising: an issuance request unit 506 that generates a request for issuing non-fungible tokens including service provider information on a service provider providing a service to users and use information on the service used by the users in a block chain formed by a computer connected with a network; a giving request unit 507 that generates a request for giving the non-fungible tokens issued in the block chain to persons allowed to acquire the tokens; and a rewriting request unit 508 that generates a request for rewriting the information included in the non-fungible tokens issued in the block chain based on the use information on the service used by the users included in the persons allowed to acquire the tokens.SELECTED DRAWING: Figure 3

Description

The present disclosure relates to a non-fungible token management device that can register non-fungible tokens in a blockchain and update information included in the non-fungible tokens registered in the blockchain.

An example of a content output system using non-fungible tokens that can register non-fungible tokens in a blockchain and update information included in the non-fungible tokens registered in the blockchain is disclosed in Patent Document 1. It is described in. Patent Document 1 discloses a content output system that includes a user terminal capable of outputting digital content and a blockchain that holds non-fungible tokens (hereinafter referred to as "NFT") associated with the digital content. Or the smart contract associated with this includes text data that can be rewritten by the owner of the digital content, and the user terminal refers to the text data on the blockchain, updates the digital content, and outputs the digital content. A content output system is described.

Patent No. 7043672

The inventor of the present application believes that the technology described in Patent Document 1 is a system for issuing non-fungible tokens mainly for digital contents traded in a virtual society, such as digital art, and that We recognized the issue that there is nothing that is linked to information.

The purpose of the present disclosure is to provide a non-fungible token management device that can issue non-fungible tokens linked to information in the actual society on a blockchain.

A non-fungible token management device according to the present disclosure stores a non-fungible token that includes service provider information of a service provider that provides a service to a user and usage information of the service by the user. an issuance request unit that generates a request to issue on a blockchain formed by a computer; an grant request unit that generates a request to grant the non-fungible token issued on the blockchain to a person who can obtain it; and the blockchain. a rewriting request unit that generates a request to rewrite information included in the non-fungible token issued by the non-fungible token based on the usage information by the user included in the acquirer.

The non-fungible token management device of the present disclosure can issue non-fungible tokens linked to information in actual society on a blockchain.

FIG. 1 is a schematic diagram showing an overview of a non-fungible token management system including a non-fungible token management device of the present disclosure. 1 is a schematic diagram showing an overview of a non-fungible token management device of the present disclosure; FIG. FIG. 2 is a schematic diagram showing an overview of a customer terminal. It is a schematic diagram showing an outline of a store terminal. FIG. 3 is a diagram illustrating an example of store information stored in a store information storage unit of the non-fungible token management device of the present disclosure. FIG. 7 is a diagram illustrating an example of store visit history information stored in a store visit history information storage unit of the non-fungible token management device of the present disclosure. FIG. 3 is a diagram illustrating an example of a usage information input screen displayed on a display of a store terminal connected to a non-fungible token management device. It is a figure showing an example of a passcode input screen displayed on a display of a store terminal. It is a figure showing an example of a reading code issue screen displayed on a display of a store terminal. FIG. 3 is a diagram illustrating an example of a confirmation screen displayed on a display of a customer terminal connected to a non-fungible token management device. It is a figure which shows the example of the completion screen displayed on the display of a customer terminal. 2 is a flowchart illustrating example 1 of control performed in a non-fungible token management system. 12 is a flowchart showing a second example of control performed in the non-fungible token management system. 12 is a flowchart showing a third example of control performed in the non-fungible token management system. FIG. 2 is a diagram illustrating an overview of store food and drink takeout information displayed on a display of a customer terminal. 2 is a diagram showing an example of store visit frequency information stored in a store visit history information storage unit of the non-fungible token management device of FIG. 1. FIG. 12 is a flowchart showing a fourth example of control performed in the non-fungible token management system. 12 is a diagram showing an example of a reward selection screen displayed on a customer terminal in control example 6. FIG. 12 is a flowchart showing a seventh example of control performed in the non-fungible token management system.

<Summary>
The non-fungible token management device of the present disclosure is connected to a user terminal and a service provider terminal via a network, and has a function of acquiring user information and service provider information. The non-fungible token management device has a function of outputting a request to issue a non-fungible token containing the acquired user information and service provider information on a blockchain on the network. The non-fungible token management device also has a function of outputting a request to rewrite the non-fungible token registered in the blockchain. Hereinafter, embodiments of the non-fungible token management device of the present disclosure will be described in detail based on the drawings. In addition, in all the figures for explaining the embodiment, the same parts are given the same reference numerals in principle, and repeated explanations thereof will be omitted.

<Overall configuration>
An example of a non-fungible token management system including the non-fungible token management device of the present disclosure is shown in FIG. The non-fungible token management system 10 manages non-fungible tokens issued on the blockchain 500 on the network 501. The non-fungible token management system 10 includes a customer terminal 100, a management server 200, a store terminal 300, a blockchain 500, and a custody device 509. Management server 200 is connected to customer terminal 100 via network 501. Store terminal 300 is connected to management server 200 via network 501. Blockchain 500 is maintained by multiple distributed computers connected to network 501. The custody device 509 is connected to the network 501. Customer terminal 100 is an example of a user terminal. Store terminal 300 is an example of a service provider terminal. The plurality of distributed computers connected to the network 501 may include any one of the customer terminal 100, the management server 200, and the store terminal 300. The management server 200 corresponds to the non-fungible token management device of the present disclosure. The network 501 includes networks constructed either wirelessly or wired, and networks constructed both wirelessly and wired.

The blockchain 500 is a public blockchain in which an unspecified number of participants can participate using computers connected to a network 501. In other words, the network 501 is a Web3 type Internet based on the public blockchain 500. Blockchain 500 uses non-fungible tokens (NFTs) as transaction history for all data including store information and customer information, and is organized into blocks 500A, 500B, and 500C, and each block 500A , 500B, and 500C are connected like a single chain. The blockchain 500 registers (authenticates) the non-fungible token issued by the management server 200, and holds (saves) the non-fungible token in a rewritable state. Blockchain 500 includes smart contracts as programs that operate autonomously.

Further, a computer connected to the network 501 plays the role of an issuing unit 502, a rewriting unit 504, and a non-fungible token providing unit 503. The issuing unit 502 has a function of issuing non-fungible tokens, which are requested to be issued by the management server 200, using the blockchain 500. The non-fungible token granting unit 503 has a function of selling non-fungible tokens registered in the blockchain 500 to buyers and a function of granting non-fungible tokens registered in the blockchain 500 free of charge. have The rewriting unit 504 has a function of rewriting at least one of the information included in the non-fungible token registered in the blockchain 500 or the information of the smart contract associated with the non-fungible token.

Stores provide services to customers. A customer is an example of a user of a service provided by a service provider, and can also be defined as a consumer. Services include selling products, lending products, transporting products, providing services, etc. Products include objects such as liquids, gases, and solids, as well as foods, dishes, software, etc. Services include the financial industry, communications industry, education industry, real estate industry, leisure industry, entertainment industry, etc. Stores include both physical stores and virtual stores (shops on the Internet). Examples of actual stores include cafeterias, restaurants, entertainment facilities, banks, and the like. Usage information that indicates that a customer uses a store includes that the customer visits the store, the number of times the customer visits the store, the customer orders a product at the store, the customer makes a reservation for a product, and the customer visits the store. This includes eating and drinking, customers paying for purchases at stores, etc. Additionally, if the store is a virtual store, the usage information includes information such as the customer accessing or logging into the virtual store, the number of times the customer accesses or logs into the virtual store, the customer conducting electronic commerce at the virtual store, etc. . When the store is an actual store, the store terminal 300 is installed or movably placed in a space within the store.

Store usage information is an example of usage information on how a user uses a service provided by a service provider. When the store is a virtual store, the services provided by the store include providing web services, videos and animations that can be viewed or downloaded, games, music, etc. to customers. Regardless of the service, usage information includes an ID for identifying the user, credit card information, and the like. Furthermore, the use of the service includes payment according to the use of the service. Payment includes payment by credit card, payment by reading a QR code (registered trademark), and payment by crypto assets. Further, predetermined hardware and software are installed in the customer terminal 100, the management server 200, and the store terminal 300. For example, the customer terminal 100, the management server 200, and the store terminal 300 each include a computer having an input port, an output port, a processor, a memory, and the like.

The customer terminals 100 include members who are provided with applications from the management server 200 and non-members who are not provided with applications from the management server 200. Furthermore, the customer terminal 100 may be either a fixed terminal or a portable terminal. Fixed terminals include desktop personal computers. Portable terminals include tablet terminals and smartphones. As shown in FIG. 2, the customer terminal 100 includes an input section 100A, a display 15, a reading section 51, a control section 52, a communication section 53, and a storage section 91. The input unit 100A includes a touch panel, buttons, a keyboard, a mouse, a stick, and the like. The customer terminal 100 receives inputs and operations of various signals and information from the input section 100A and the reading section 51. The control unit 52 processes signals and information input from the input unit 100A and the reading unit 51. The control unit 52 performs various processes and judgments based on programs, data, information, etc. stored in the storage unit 91, and controls the display on the display 14. The control unit 52 causes the communication unit 53 to output a signal, and processes the signal input from the communication unit 53. The communication unit 53 can mutually transmit and receive signals between the customer terminal 100 and the management server 200 via the network 501. The communication unit 53 can also mutually transmit and receive signals via the network 501 with a plurality of distributed computers that construct a blockchain.

The customer terminal 100 receives an application for performing payment processing from the management server 200 and has it installed in advance. In addition, after installing the application on the customer terminal 100, information sent from the customer terminal 100 to the management server 200, such as credit card information owned by the customer, email address, domain, various service accounts, and information selected by the customer in advance. Information such as the type of reward received and the ID pass is registered in the storage unit 256 of the management server 200.

When using an application on the customer terminal 100, information on the credit card owned by the customer is registered in the management server 200 in advance. Therefore, while the application is running, the customer terminal 100 can perform payment processing for the amount used at the store by reading a reading code generated by the management server 200, such as a QR code or a barcode. . Note that payment of the usage amount includes payment using crypto assets, credit cards, cash, gift certificates, complimentary coupons, and discount coupons. Crypto assets include Bitcoin and Ethereum. The customer terminal 100 includes a location information acquisition unit 90 that acquires the current location. The position information acquisition unit 90 is typically a GPS (Global Positioning System) device that receives GPS satellite signals and obtains position information.

The management server 200 is managed by a token issuer who intends to issue non-fungible tokens on the blockchain 500, and has a function of issuing non-fungible tokens. A token issuer can also be defined as a business operator. Management server 200 provides various applications to customer terminal 100 and store terminal 300. As shown in FIG. 3, the management server 200 includes a control section 50, a storage section 256, and a communication section 257. The communication unit 257 can transmit and receive signals between the customer terminal 100 and the store terminal 300. The communication unit 257 can also receive signals from the blockchain. The control unit 50 can transmit and receive signals between the storage unit 256 and the communication unit 257.

The control unit 50 includes a notification processing unit 210, a cryptocurrency grant unit 220, a screen generation unit 230, an information update unit 240, an authentication unit 80, a determination unit 85, a reward presentation unit 81, a reward grant unit 82, an issuance request unit 506, a grant It includes a requesting section 507, a rewriting requesting section 508, and a specific service providing section 505. The storage unit 256 includes a store information storage unit 251, a store visit history information storage unit 252, and a program storage unit 258. The program storage unit 258 stores various programs and applications that cause the management server 200 to operate and function. Further, the program storage unit 258 stores various programs and applications to be provided to the customer terminal 100, the store terminal 300, and the computer connected to the network 501.

The management server 200 obtains (receives) the store ID, the number of customers visiting the store, the customer ID, the amount spent by the customer at the store, etc. from the store terminal 300. The number of customers who visited the store includes the number of customers who accessed the store. The screen generation unit 230 of the management server 200 generates a reading code for paying the usage amount based on the store ID for identifying the store, the number of people, and the amount. Further, the screen generation unit 230 provides the store terminal 300 with a read code issuing screen including the read code.

The information update unit 240 of the management server 200 acquires a customer ID (application ID (ID of the application itself assigned to the customer), etc.) at the time of payment. The information update unit 240 also includes a customer ID for identifying the customer, a store ID obtained by reading the reading code on the customer terminal 100, the date and time of visit, the amount spent by the customer, and the customer's information. It is stored in the store visit history information storage unit 252 in association with the number of people who came to the store. The store visit date and time includes the date and time when the customer visited the store and the date and time when the customer accessed the store.

The notification processing unit 210 of the management server 200 refers to the store visit history information stored in the store visit history information storage unit 252 and sends a message or coupon to a customer terminal 100 that is confirmed not to have visited the store for a predetermined period of time or more. . More specifically, the notification processing unit 210 periodically acquires store visit history information from the store visit history information storage unit 252 (for example, every other day), and provides information to the customer terminal 100 of a customer who has not visited the store for a predetermined interval or longer. Send messages and coupons. For example, the notification processing unit 210 of the management server 200 sends a message such as "You have not visited the store for over a month" to the customer terminal 100.

Furthermore, the notification processing unit 210 transmits coupons and the like related to food and drinks that have been ordered in the past to the customer terminal 100 based on the order information that constitutes the store visit history information. The determining unit 85 has a function of determining signals, information, and data. Further, the determining unit 85 has a function of determining whether a customer included in the purchasers (holders) of non-fungible tokens has used a specific store among the stores that is not included in the purchasers of non-fungible tokens. have The authentication unit 80 of the management server 200 authenticates that the customer has used the store.

The reward presentation unit 81 of the management server 200 presents multiple types of rewards to the customer. A reward granting unit (reward providing unit) 82 of the management server 200 grants (provides) rewards to customers. Additionally, the reward granting unit 82 has a function of referencing information included in non-fungible tokens registered in the blockchain 500 from outside the blockchain 500 and providing rewards to customers based on the reference results. have The reward granting unit has the function of providing customers with at least one of the rewards purchased from the reward trading market using the fees that the token issuer obtains from the store, or the rewards held by the token issuer. It also has. Note that the rewards will be described later.

More specifically, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252 and determines at least one of the store visit date and time (time zone), amount, and number of people that constitute the store visit history information. A corresponding coupon is specified based on one or more conditions, and the specified coupon is transmitted to the customer terminal 100. Then, it becomes possible to recommend recommended menus and coupons to the customer via the application based on the time period in which the customer ate at the store and the amount spent. In addition, the management server 200 uses the AI function to learn the stores visited by the customer, the menus selected by the customer at the store, hobbies and preferences such as food, cooking, etc., and selects stores based on the learning results and recommends them to the customer. It is also possible to do so. Note that the language of the information transmitted from the management server 200 to the customer terminal 100 and the store terminal 300 is not limited to Japanese, and may be any type of language such as English, Chinese, Korean, French, German, etc.

The notification processing unit 210 also acquires information on related stores (stores in other groups in the case of multiple store development) from the store information storage unit 251. Then, the customer's preferences and behavior patterns are estimated based on the time period in which the customer ate and the amount of food, etc., and coupons for related stores are sent to the customer terminal 100. This makes it possible to increase sales for the entire group, including related stores, especially in cases where the company has multiple stores.

The crypto currency granting unit 220 of the management server 200 multiplies the food and drink price (the amount paid by the customer) by a predetermined percentage (for example, 5% or more) to calculate the success fee amount to be charged to the store (from the store to the management server 200). (paid to the operator). Then, the notification processing unit 210 of the management server 200 transmits the success fee amount corresponding to the amount calculated by the cryptocurrency granting unit 220 to the store terminal 300.

The crypto currency granting unit 220 of the management server 200 calculates the amount of crypto currency to be given to the customer by multiplying the food and drink price by a predetermined percentage (for example, 1% or more). Then, the notification processing unit 210 of the management server 200 transmits the amount of crypto currency corresponding to the amount calculated by the crypto currency granting unit 220 to the customer terminal 100. Note that the crypto currency granting unit 220 may calculate the crypto currency amount to be given to the customer by multiplying the success fee amount by a predetermined percentage (for example, 10 to 40%). That is, the crypto currency granting unit 220 calculates a portion of the success fee amount as crypto currency.

The issuance request unit 506 has a function of generating a request to issue a non-fungible token on the blockchain 500 that includes store information regarding the store and usage information indicating that the customer used the store. The grant request unit 507 has a function of generating a request to grant non-fungible tokens held in the blockchain 500 to a customer, which is an example of a person who can obtain them. The rewrite request unit 508 requests at least one of the information included in the non-fungible token registered in the blockchain 500 or the information of the smart contract associated with the non-fungible token, based on usage information by the customer. It has a function to generate a request to rewrite information. The specific service providing unit 505 has a function of providing specific services to customers that can be enjoyed by customers included in the purchasers of non-fungible tokens. The specific service providing unit 505 also has a function of providing non-fungible tokens to the customer terminal 100 free of charge.

Further, the control unit 50 has a function of accepting purchase orders for non-fungible tokens on the network 501 and generating a platform for selling non-fungible tokens. Furthermore, the control unit 50 references information included in non-fungible tokens registered in the blockchain 500 from outside the blockchain 500, and based on the reference results, the token issuer provides the information to the customer. It has the function of managing services. Managing services provided to customers means authentication of services provided by token issuers to customers, services or rooms available only to specific customers, special preferential information, etc., and services after authentication. It also includes the meaning of being used for provision.

The store terminals 300 include member stores (registrants) to which the management server 200 provides applications, or non-member stores (non-registrants) to which the management server 200 does not provide applications. As shown in FIG. 4, the store terminal 300 includes an input section 300A, a display 20, a reading section 54, a computer 55, a storage section 57, and a communication section 56. The reading unit 54 includes a camera, a scanner, a barcode reader, a magnetic sensor, an optical sensor, and the like. The magnetic sensor may be either a contact type or a non-contact type. The input unit 300A includes a touch panel, buttons, a keyboard, a mouse, a stick, and the like. The store terminal 300 receives inputs and operations of various signals and information from the input section 300A and the reading section 54. The computer 55 is connected to the reading section 54, the storage section 57, the communication section 56, the display 20, and the input section 300A so as to be able to send and receive signals.

The storage unit 57 stores data, information, applications, programs, and the like. The computer 55 performs processing, judgment, and control based on information, data, etc. stored in the storage unit 57. The computer 55 processes signals and information input from the input section 300A and the reading section 54. Computer 55 controls the content displayed on display 20. The computer 55 causes the communication section 56 to output a signal, and processes the signal input from the communication section 56 . The communication unit 56 can mutually transmit and receive signals between the customer terminal 100 and the management server 200 via the network 501. Further, the communication unit 56 can mutually transmit and receive signals via the network 501 with a plurality of distributed computers that construct a blockchain.

Furthermore, by operating the input unit 100A, the customer can select in advance the reward to receive and transmit the information to the management server 200 and the store terminal 300. Information transmitted from the customer terminal 100 and the management server 200 to the store terminal 300 is stored in the storage unit 57.

Various applications are installed on the store terminal 300. The application installed on the store terminal 300 is provided by the management server 200. The store terminal 300 accumulates store visit history information when a customer uses the customer terminal 100 to read a reading code to make a payment. Specifically, when the customer reads the reading code with the customer terminal 100, the store terminal 300 acquires the customer ID, the date and time of visit, and the amount spent (payment amount). Then, the store terminal 300 calculates the amount of crypto currency by multiplying the obtained amount by a predetermined ratio. The store terminal 300 transmits information associating the acquired customer ID, date and time of store visit, amount of money, and amount of cryptocurrency to the management server 200, and the management server 200 stores the received information in the store visit history information storage section 252. Remember.

The custody device 509 is a computer that can be connected to the customer terminal 100, the management server 200, and the store terminal 300 via the network 501. It has a function to keep non-fungible tokens from a purchaser (holder) of non-fungible tokens, and a function to issue a request to rewrite the non-fungible tokens registered in the blockchain 500. Further, the custody device 509 has a function of acquiring a non-fungible token and keeping the non-fungible token from a holder who has a private key used for security of the blockchain 500. The custody device 509 is managed by a depositor who does not have a private key.

<Store information>
FIG. 5 is a diagram illustrating an overview of a configuration example of store information stored in store information storage unit 251 of management server 200 in Embodiment 1 of the present disclosure. Store information is an example of service provider information. As shown in FIG. 5, the store information includes a store ID, a group ID, a store name, a store address, and a success fee amount. The store ID indicates a code for identifying the store. The group ID indicates a code for identifying a group in the case of a multi-store development. The store name indicates the name of the store. The store address indicates the address of the store. The success fee amount indicates the amount of success fee charged to the store by the server operator. Furthermore, if the store is a virtual store, the store information includes all services provided at the virtual store.

<Store visit history information>
FIG. 6 is a diagram illustrating an overview of a configuration example of store visit history information stored in store visit history information storage unit 252 of management server 200 in Embodiment 1 of the present disclosure. Store visit history information is an example of service usage information by users. As shown in FIG. 6, the store visit history information includes a store ID, a passcode, a customer ID, a visit date and time, a payment amount, the number of people, and a reward offer amount. A passcode is a code assigned in association with personal information such as the name of a store employee, and is used to identify the employee. The customer ID indicates a code for identifying the customer. The store visit date and time indicates the date and time when the customer visited the store. The payment amount indicates the amount paid by the customer at the store. The number of people indicates the number of customers visiting the store. The crypto currency amount indicates the amount of crypto currency given to the customer by the management server 200.

<Usage information input screen>
FIG. 7 is a diagram illustrating an overview of a configuration example of usage information input screen 11 displayed on display 20 of store terminal 300 in Embodiment 1 of the present disclosure. The usage information input screen 11 is provided by the screen generation unit 230 of the management server 200. As shown in FIG. 7, the usage information input screen 11 displays a number of people input field 1310, an amount input field 1320, a confirmation button 1330, and a reading code reading start button 1340.

The number of customers input field 1310 accepts input of the number of customers visiting the store. The amount input field 1320 accepts input of the amount spent by the customer at the store. When the confirm button 1330 accepts the input, the store terminal 300 transmits the number of people input in the number of people input field 1310 and the amount input in the amount input field 1320 to the management server 200.

<Passcode entry screen>
When the reading code reading start button 1340 is selected, the store terminal 300 causes the display 20 to display the passcode input screen 12 of FIG. 8 provided by the management server 200. A passcode input button 1410 is displayed on the passcode input screen 12. When the passcode input button 1410 accepts input, the passcode is input. The store terminal 300 transmits the input passcode, the number of people input via the usage information input screen 11 of FIG. 4, and the amount of money to the management server 200.

<Reading code issuing screen>
When the passcode is input, the store terminal 300 causes the display 20 to display the reading code issuing screen 13 shown in FIG. 9 provided by the management server 200. The reading code issuing screen 13 displays a number of people display field 1510, an amount display field 1520, a reading code 1530, and a completion button 1540.

In the number of people display field 1510, the number of people entered on the usage information input screen 11 of FIG. 4 is displayed. The amount of money entered on the usage information input screen 11 is displayed in the amount display field 1520. When the completion button 1540 accepts an input after the reading code 1530 is read by the customer terminal 100, the store terminal 300 sends a notification to the management server 200 that the completion button 1540 has accepted the input.

<Confirmation screen>
When the management server 200 receives the notification that the completion button 1540 has accepted the input, it generates a confirmation screen and provides the generated confirmation screen to the customer terminal 100 shown in FIG. 10. A confirmation screen 15 is displayed on the display 14 of the customer terminal 100. As shown in FIG. 10, the confirmation screen 15 displays an amount display field 1610, an approval/rejection button 1620, and an approval button 1630. The amount display field 1610 displays the amount input in the amount input field 1320.

<Completion screen>
When the approval button 1630 accepts the input, the customer terminal 100 causes the display 14 to display the completion screen 16 of FIG. 11 provided by the management server 200. A completion button 1710 is displayed on the completion screen 16. Additionally, on the completion screen, a message indicating when the crypto currency will be awarded, such as "The cryptocurrency will be awarded at the current market rate within 15 days," is displayed. When the completion button 1710 accepts the input, a series of processes from payment processing to cryptocurrency processing is completed.

<Control example 1>
FIG. 12 is a flowchart showing control example 1 performed by the non-fungible token management system 10 of the present disclosure. First, in S901, the display 20 of the store terminal 300 displays the usage information input screen 11. Then, when customers visit the store, the number of customers input field 1310 on the usage information input screen 11 accepts input of the number of customers who visited the store. Further, the amount input field 1320 of the usage information input screen 11 accepts input of the amount used by the customer. The usage information input screen 11 is provided by the management server 200.

When the confirm button 1330 accepts the input, the store terminal 300 transmits the number of people input in the number of people input field 1310 in S901 and the amount input in the amount input field 1320 to the management server 200 in S902. Then, when the reading code reading start button 1340 accepts an input (selection), the process advances to S903.

Next, in S903, the management server 200 receives the number of people and the amount sent in S902. Next, in S904, the screen generation unit 230 of the management server 200 provides the passcode entry screen 12 to the store terminal 300. Next, in S905, the display 20 of the store terminal 300 displays the passcode input screen 12. The passcode input screen 12 displays a passcode input button 1410 and accepts input of the passcode. Next, in S906, the store terminal 300 transmits the input passcode and store ID to the management server 200. The management server 200 receives the passcode and store ID transmitted from the store terminal 300 in S907.

Next, in S908, the screen generation unit 230 of the management server 200 generates a reading code for making payment based on the store ID, the number of people, and the amount received in S903. Further, the screen generating unit 230 generates the reading code issuing screen 13 based on the generated reading code, the number of people received in S903, and the amount. Next, in S909, the screen generation unit 230 of the management server 200 provides the store terminal 300 with the reading code issuing screen 13 generated in S908.

Next, in S910, the store terminal 300 displays the reading code issuing screen 13 on the display 20. Then, after the reading code 1530 is read (approved) by the reading unit 51 of the customer terminal 100, the store terminal 300 accepts the input of the completion button 1540. When the completion button 1540 accepts the input, in S911 the store terminal 300 transmits a notification to the management server 200 that the completion button has accepted the input.

In S912, the authentication unit 80 of the management server 200 receives a notification that the completion button 1540 has accepted the input. Further, the determination unit 85 of the management server 200 authenticates that the customer has used the store. Then, the screen generation unit 230 of the management server 200 generates the confirmation screen 15 in step S912.

Next, in S913, the screen generation unit 230 of the management server 200 provides the generated confirmation screen 15 to the customer terminal 100. Next, in S914, the customer terminal 100 displays the confirmation screen 15 on the display 14 and accepts input from the approval button 1630. More specifically, the customer terminal 100 displays an amount display field 1610, an approval/rejection button 1620, and an approval button 1630 on the confirmation screen 15, and the approval button 1630 accepts input. Note that after S914, approval approval information is transmitted from the customer terminal 100 to the management server 200.

Next, in S915, the customer terminal 100 sends to the management server 200 the customer ID, the store ID, the passcode, the date and time of visit, the amount, and the number of people acquired by reading the reading code 1530. Send.

Next, in S916, the management server 200 receives the customer ID, store ID, passcode, date and time of visit, amount of money, and number of people transmitted in S915. Then, the crypto currency granting unit 220 of the management server 200 calculates the success fee amount to be charged to the store by multiplying the received amount (food and drink price) by a predetermined percentage (for example, 5% or more). Further, the crypto currency granting unit 220 calculates the crypto currency amount to be given to the customer by multiplying the amount (food and drink cost) by a predetermined percentage (for example, 1% or more).

Next, in S917, the management server 200 matches the store ID, passcode, customer ID, visit date and time, amount, number of people, and crypto currency amount calculated in S916 received in S916. The information is stored in the store visit history information storage section 252. Next, in S918, the screen generation unit 230 of the management server 200 provides the completion screen 16 to the customer terminal 100 and the store terminal 300. The notification processing unit 210 of the management server 200 transmits the calculated amount of cryptocurrency to the customer terminal 100. Further, the notification processing unit 210 of the management server 200 transmits the calculated success fee amount to the store terminal 300.

Next, the customer terminal 100 displays the completion screen 16 on the display 20 in step S919, and the store terminal 300 displays the completion screen 16 on the display 20. A completion button 1710 is displayed on the completion screen 16, and when the completion button 1710 accepts an input, a series of processing from payment processing to cryptocurrency processing is completed.

As described above, when control example 1 is performed, the screen generation unit 230 of the management server 200 generates the reading code 1530 for making payment based on the store ID, the number of people, and the amount, and the reading code 1530 is provided to the store terminal 300. The information update unit 240 associates the customer ID with the store ID, store visit date and time, amount of money, and number of people acquired by reading the reading code 1530 with the customer terminal 100, and stores the store visit history information storage unit 252. to be memorized. Therefore, the management server 200 can facilitate the payment of the usage amount between the store and the customer, and can also enable customer relationship management (CRM). Further, the store can utilize the information sent from the management server 200 to the store terminal 300 for point of sale (POS) management.

Further, the notification processing unit 210 of the management server 200 refers to the store visit history information stored in the store visit history information storage unit 252, and sends at least one of a message or a coupon to the customer terminal 100 of a customer who has not visited the store for a predetermined period of time or more. By sending this message, you can encourage customers to visit your store next time.

Further, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252, and based on at least one of the store visit date and time, the amount, and the number of people, which constitute the store visit history information. By identifying the corresponding coupon and transmitting the identified coupon to the customer terminal 100, it is possible to encourage the customer to visit the store next time or later with higher accuracy, taking into consideration the customer's behavior pattern.

In addition, the crypto currency grant unit 220 calculates the crypto currency amount to be given to the customer by multiplying the amount by a predetermined ratio, and the notification processing unit 210 transmits the crypto currency amount to the customer terminal 100 to Incentives can be given based on store visit performance. Furthermore, the crypto currency granting unit 220 calculates the success fee amount to be paid from the store to the administrator of the management server 200 by multiplying the amount by a predetermined percentage. Further, the crypto currency giving unit 220 calculates the amount of virtual currency to be given to the customer by multiplying the success fee amount by a predetermined ratio. Furthermore, the notification processing unit 210 transmits the success fee amount to the store terminal 300 and also transmits the virtual currency amount to the customer terminal 100. Therefore, a part of the success fee paid to the administrator of the management server 200 can be given to the customer as an incentive depending on the customer's store visit record.

<Control example 3>
FIG. 13 is a flowchart showing a third example of control performed by the non-fungible token management system 10. First, customer terminal 100 receives beacon device identification information periodically transmitted from beacon device 400 in step S1601. Next, the customer terminal 100 transmits the beacon device identification information, the customer ID, and the current store visit time to the management server 200 in step S1602.

Management server 200 receives beacon device identification information, customer ID, and store visit time in step S1603. Then, the information update unit 240 of the management server 200 searches the store information storage unit 251 using the received beacon device identification information as a key, and acquires the corresponding store information.

Next, in S1604, the information update unit 240 of the management server 200 stores check-in information associated with the customer ID, store visit time, store ID, group ID, store name, and store address in the check-in information storage unit 253. do. Next, in S1605, the matching unit 250 searches the payment information storage unit 255 using the customer ID as a key, and obtains the corresponding payment information.

Next, in S1606, the matching unit 250 matches whether the check-in information and the payment information match. More specifically, the collation unit 250 compares "customer ID, store ID, group ID, store name, and store address that constitute check-in information" and "customer ID, store ID, and group ID that constitute payment information." , store name, and store address” match.

In addition, the collation unit 250 identifies "customer ID, store ID, group ID, store name, and store address that constitute check-in information" and "customer ID, store ID, group ID, and store name that constitute payment information". , store address" may match or not. This makes it possible to check the store where the payment is actually made and the store specified by the information from the beacon device 400, thereby increasing the accuracy of the payment.

If the matching unit 250 determines that the check-in information and payment information do not match in step S1606, the screen generation unit 230 of the management server 200 outputs an error message such as "Payment is not possible" and ends the entire process. do. If the matching unit 250 determines in step S1606 that the check-in information and payment information match, the customer terminal 100 performs the process of step S1607.

Next, in step S1607, the customer terminal 100 receives input of predetermined card information on the card information input screen displayed on the display, and then logs into the management server 200. The customer terminal 100 then transmits the card information to the management server 200 in step S1608.

Next, in step S1609, the management server 200 acquires the detailed information linked to the customer ID of the card information received from the customer terminal 100 from the detailed information storage unit 254. Next, in step S1610, customer terminal 100 displays detailed information on the display after logging in.

Thereafter, in step S1611, the customer terminal 100 performs payment processing by having the customer use the credit card linked with the detailed information. Next, customer terminal 100 transmits payment information to management server 200 in S1612.

Next, the management server 200 calculates the amount of virtual currency based on the payment information received from the customer terminal 100 in step S1613. Next, in step S1614, the management server 200 returns (sends) a portion of the virtual currency amount to the address or domain specified by the customer (user) operating the customer terminal 100.

Next, in step S1615, the management server 200 pays the store terminal 300 for a portion of the payment amount calculated based on the above-mentioned payment information. Thereafter, in step S1616, the management server 200 overwrites the payment information received from the customer terminal 100 over the detailed information retrieved from the detailed information storage unit 254 and performs update registration.

As described above, when the control example of FIG. 13 is performed, the collation unit 250 checks the check-in information including the customer ID and the store information specified from the beacon device identification information, and the payment information stored in advance. By comparing the information, it becomes possible to compare the store where the payment is to be made and the information from the beacon device 400, and it is possible to improve the accuracy of the payment.

Further, as a prerequisite for using a credit card, a check-in function via the beacon device 400 can be implemented, and security associated with credit card payments can be enhanced. Furthermore, immediately after the customer terminal 100 receives the beacon identification information from the beacon device 400, the management server 200 can recognize the customer and the store. becomes possible.

<Control example 3>
FIG. 14 is a flowchart showing a third example of control performed by the non-fungible token management system 10. First, in S1701, the customer terminal 100 reads a QR code at a store where the customer has visited. Next, in S1702, the customer terminal 100 transmits reading information corresponding to the QR code read by the customer terminal 100 in S1701 to the management server 200.

Next, in step S1703, the management server 200 receives the read information transmitted from the customer terminal 100, and stores it in the check-in information storage unit 253. Then, the information update unit 240 of the management server 200 searches the store information storage unit 251 using the received reading information as a key, and acquires the corresponding store information.

Next, the information update unit 240 of the management server 200 issues a one-time pass in step S1704. Next, the management server 200 transmits the one-time pass to the customer terminal 100 in step S1705. Then, the customer terminal 100 displays the one-time pass on the display in step S1706.

Next, the customer terminal 100 transmits the one-time pass displayed on the display to the management server 200 in step S1707. Next, in step S1708, the store terminal 300 receives the one-time pass transmitted from the customer terminal 100 and accepts the input. Next, store terminal 300 receives input of amount and number of people in step S1709.

Thereafter, in S1710, the store terminal 300 transmits to the management server 200 the amount and number of people input in S1709. Next, in S1711, the management server 200 receives the amount, number of people, and one-time pass transmitted from the store terminal 300 in S1710. Next, the management server 200 transmits the received amount, number of people, and one-time pass to the customer terminal 100 in step S1712.

Next, in step S1713, the customer terminal 100 receives the amount, number of people, and one-time pass sent from the management server 200, and displays a consent screen on the display. Next, customer terminal 100 transmits the consent screen displayed on the display to management server 200 in step S1714.

Next, in step S1715, the management server 200 receives the consent screen transmitted from the customer terminal 100, and stores whether or not the consent is granted in the check-in information storage unit 253. Next, management server 200 transmits a completion screen to customer terminal 100 and store terminal 300 in step S1716. Thereafter, customer terminal 100 and store terminal 300 receive the transmitted completion screen and display it on their respective displays in S1717.

As described above, according to control example 3 in FIG. 14, by comparing check-in information including customer information and store information specified by reading a QR code with pre-stored payment information, It is now possible to check the store where the payment is being made and customer information, increasing the accuracy of the payment. Furthermore, even for stores that do not have smartphones, tablets, etc., the management server 200 can perform payment by installing a QR code printed on paper in the store and having the QR code read by the customer terminal 100.

<Control example 4>
Another example of control performed by the non-fungible token management system 10 will be explained. In another control example, it is assumed that a customer who visits a store takes out food and drink. In this case, the notification processing unit 210 of the management server 200 refers to the store visit history information stored in the store visit history information storage unit 252 and the store information stored in the store information storage unit 251, and Take-out information on food and drink at the store visited or its related stores is transmitted to the customer terminal 100. This will be explained based on FIG. 15.

FIG. 15 is a diagram illustrating an overview of store food and drink takeout information displayed on the display of customer terminal 100 in Embodiment 4 of the present disclosure. As shown in FIG. 18, on the display of the customer terminal 100, stores near the customer's current location where food and beverages can be taken out are displayed on a map 1910. Here, the management server 200 acquires the current location of the customer terminal 100 transmitted from the customer terminal 100. Then, the management server 200 determines the current location of the customer terminal 100, the store visit history information stored in the store visit history information storage section 252, and the store information stored in the store information storage section 251, based on the customer's current location. By transmitting to the customer terminal 100 information on stores where food and drinks can be taken out around the current location, the above information is displayed on the display of the customer terminal 100.

Note that the map 1910 displayed on the display of the customer terminal 100 does not have to be about the current location of the customer terminal 100, but may be a map about a predetermined area specified by the customer terminal 100.

In addition, the management server 200 refers to the store visit history information stored in the store visit history information storage unit 252, and uses a social network service (hereinafter referred to as SNS) by a customer different from the customer who wants take-out information on food and beverages. Service), and sends food and drink takeout information at stores that have received more than a predetermined number of impressions (for example, 500,000 or more impressions) to the customer terminal 100 of a customer who wants food and drink takeout information. It's okay.

In this case, an application for using SNS is installed on the customer terminal 100, and it is possible to post a review of the store. Review postings include customers' own impressions of the atmosphere in the restaurant, comments by customers about the food, photos of the customers eating the food, photos of the food that actually came out, etc. The above application is configured to be switchable between, for example, a post function for eat-in and a post function for take-out.

According to FIG. 15, detailed store information 1920 including the take-out menu of food and drink at the selected store is displayed on the display of the customer terminal 100. The customer can decide which store to visit for take-out based on such information and actually visit the store. When a customer visits the store, the overall processing of the payment system shown in FIG. 9 is executed.

Here, the notification processing unit 210 of the management server 200 refers to the visit history information regarding takeout visits stored in the store visit history information storage unit 252, and sends a message or a coupon to the customer terminal 100 of the customer who visited the takeout store. By sending at least one of them, the customer may be encouraged to visit the store next time. Furthermore, the notification processing unit 210 sends at least one of a message and a coupon to the customer terminals 100 of customers who actually visited the store for takeout, as well as to the customer terminals 100 of customers who showed interest in the store shown in FIG. You can also send it. Note that whether or not a customer has shown interest in a store can be determined using a well-known method, such as by analyzing the customer's selection from a list of stores displayed on the map 1910, for example.

The process described above can also be applied when a customer receives food and drink delivered. In this case, the notification processing unit 210 of the management server 200 transmits to the customer terminal 100 food and drink delivery information at stores that the customer has visited in the past, their related stores, or stores posted on SNS. The customer can then decide on a store based on the information displayed on the display of the customer terminal 100, and receive food and drinks delivered from the store. In this case, control example 1 shown in FIG. 12 may be executed between the store terminal 300 and the management server 200, using the store terminal 300 as a terminal owned by the delivery person.

Also, when a customer receives food and drink delivery, the notification processing unit 210 of the management server 200 refers to the store visit history information regarding the use of delivery stored in the store visit history information storage unit 252, and uses the delivery service. By sending at least one of a message or a coupon to the customer terminal 100 of the customer who has visited the store, the customer may be encouraged to visit the store next time.

<Effects of control example 4>
As described above, according to control example 4, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252, and the customer terminal 100 of the customer who visited the store for takeout or the customer who used delivery. By sending at least one of a message or a coupon to the customer, it is possible to encourage the customer to visit the store next time. In this way, according to the fourth embodiment, good customer relationship management can be achieved.

<Control example 5>
A fifth control example performed by the non-fungible token management system 10 will be described. In control example 5, preferential treatment is applied to the customer depending on the number of times the customer visits the store. Specifically, the notification processing unit 210 of the management server 200 refers to the store visit history information stored in the store visit history information storage unit 252 and transmits preferential treatment for the customer to the customer terminal 100. Here, the store visit history information storage section 252 stores visit frequency information based on the date and time of the store visit. FIG. 16 is a diagram illustrating an example of store visit frequency information stored in the store visit history information storage unit 252. As shown in FIG. 16, the store visit count information includes a customer ID, store ID, group ID, visit date and time, store name, and store visit count.

In this embodiment, for example, the stage of the customer's membership status is determined according to the number of visits to the store, and the customer can receive preferential treatment according to each stage. In order to encourage participation in such a preferential membership program, for example, in control example 1 shown in FIG. Alternatively, customers who have become store members by other means may be automatically allowed to participate in the program. Note that the number of visits to the store may be counted for dine-in visits or take-out visits.

Furthermore, the results of posting to SNS may be taken into consideration in determining the stage of the customer's membership status. For example, the stage of a customer's membership status may be determined based on the number of times the customer visits the store and the number of impressions of the customer's SNS posts about the store.

Then, the notification processing unit 210 of the management server 200 refers to the number of store visit information based on the store visit date and time stored in the store visit history information storage unit 252, and selects at least one message or coupon according to the stage of the customer's membership status. By transmitting one to the customer terminal 100, it is possible to encourage the customer to visit the store next time.

<Effects of Control Example 5>
As described above, when control example 5 is performed, good customer relationship management can be achieved.

<Control example 6>
The management server 200 in FIG. 1 can execute control example 6. When control example 6 is executed, the customer can select any reward from a plurality of types of rewards by using the store.

FIG. 17 is a flowchart showing control example 6 performed by the management server 200, that is, a reward granting method. First, the authentication unit 80 of the management server 200 authenticates that the customer has used the store in step S10. This authentication can be performed, for example, in step S912 of FIG. 12 or step S1613 of FIG. 13 when the customer makes a payment. The management server 200 presents multiple types of rewards to the customer in step S11 following step S10. In step S11, the management server 200 presents a reward presentation screen 60 on the display 14 of the customer terminal 100, as shown in FIG.

A virtual currency button 61, a synchro point button 62, a common point button 63, and a selection button 64 are displayed on the reward presentation screen 60. The virtual currency button 61 is operated when the customer wishes to obtain virtual currency. The synchro point button 62 is operated when the customer desires to obtain synchro points. The synchronization point is provided to the customer by the administrator of the management server 200. The synchro points can be used for purchasing e-gifts provided by the administrator of the management server 200, purchasing complimentary tickets, making payments to stores, and the like. The common points are used for a common point service provided by a vendor (either an individual or an organization) different from the administrator of the management server 200. Common point services include product payments, product discounts, complimentary coupons, etc. These virtual currencies, synchro points, common points, unique tokens issued by token issuers, and virtual currencies are multiple types of rewards.

The customer operates any one of the virtual currency button 61, synchro point button 62, and common point button 63 on the reward presentation screen 60, and also operates the selection button 64. Then, the management server 200 determines the reward selected by the customer in step S12. Specifically, the management server 200 receives the reward selection information transmitted from the customer terminal 100 before step S11 and stored in the storage unit 256, or the reward selection information transmitted from the customer terminal 100 after step S11. The determination in step S12 is made based on the reward selection information. Next, the management server 200 grants the reward selected by the customer to the customer in step S13, and ends the process of FIG. 17. The reward given to the customer by the management server 200 is determined according to the payment amount. The customer receives rewards at the email address, domain, account for various services, etc. registered in the management server 200. After receiving a reward, the customer can also access the management server 200 and change the type of reward.

Furthermore, a modification example of control example 6 in FIG. 17 is as follows. The customer may set in advance the rewards that the customer will receive after the customer terminal 100 installs the application and before the customer visits the store. In this case, the management server 200 performs the process in step S10 of FIG. 17, skips the processes in steps S11 and S12, and performs the process in step S13.

Furthermore, the object that the customer terminal 100 reads with the reading unit 51 is not limited to the reading code 1530 in FIG. 9 . For example, the management server 200 can perform the authentication in step S10 by reading the store's authentication object 70 with the reading unit 51 of the customer terminal 100 and sending a signal from the customer terminal 100 to the management server 200. . The authentication object 70 includes a receipt issued by a store after payment of the amount and to which a barcode or QR code is attached. Further, the authentication object 70 may be a card with an IC chip that is provided separately from the store terminal 300 and does not have a communication function. Furthermore, the management server 200 may perform authentication using the history of cashless payments that the customer has made at stores in the past.

Further, the reading unit 54 of the store terminal 300 reads the customer's authentication target 71 in addition to processing the amount of payment, and sends a signal from the store terminal 300 to the management server 200, so that the management server 200 performs the authentication in step S10. It is also possible to do this. Furthermore, the reading unit 54 of the store terminal 300 reads the customer's authentication target 71 separately from the payment processing, and sends a signal from the store terminal 300 to the management server 200, so that the management server 200 performs step S10. It is also possible to perform authentication. In other words, the authentication of "the customer's use of the store" performed by the authentication unit 80 does not matter whether or not there is a payment process. The authentication object 71 includes a credit card owned by the customer and a personal identification card owned by the customer. Personal identification cards include driver's licenses with IC chips, My Number cards with QR codes, and the like. Further, the authentication object 71 may be a customer's fingerprint, retina, vein, or the like. That is, the authentication performed by the management server 200 in step S10 may be biometric authentication.

Furthermore, if the store is a virtual store, at any time the customer logs into the virtual store, reserves the product, purchases the product, or pays for the purchase using a credit card, A signal can be transmitted from the store terminal 300 to the management server 200, and the management server 200 can perform the authentication in step S10.

Furthermore, the authentication in step S10 in FIG. 17 is not limited to being performed simultaneously with the payment when the customer uses the store. For example, it may be performed after a certain period of time, for example, two weeks, after the payment of the usage amount at the store. Furthermore, when making a payment for the first time in a predetermined month, the process of step S10 may be performed depending on the usage of the store in the previous month.

<Effects of Control Example 6>
Customers can select their desired reward from multiple types of rewards. In other words, the application that makes the non-fungible token management system 10 function functions as a multi-reward return system. Therefore, it is possible to motivate customers to use the store and increase the number of times they use the store. Furthermore, it is possible to reduce the risks that customers face when purchasing virtual currency, lower the hurdles for purchasing virtual currency, and expect the use of virtual currency to expand.

<Others>
Furthermore, the store terminal 300 may have a function of displaying the store visit frequency, repeat rate, etc. for each customer on the display 20 based on the store visit frequency information shown in FIG. 16, that is, a dashboard function. .

Furthermore, if the customer uses the store for the first time and the process in step S911 in FIG. 12 is performed, or if the customer uses the store for the first time and the process in step S10 in FIG. 17 is performed, step S13 In this case, the management server 200 may issue a customer-specific membership card to the customer terminal 100. Although this membership card is a digital membership card, a digital membership card and a physical membership card may be used together.

Furthermore, in parallel with the processing in step S911 in FIG. 12 and step S10 in FIG. Member rank (status) can be determined step by step for each store based on at least one condition of the total approved amount. Then, the management server 200 can automatically store customer visit information linked to the membership rank in the store visit history information storage section 252. The customer's store visit information is at least one of the following conditions: the number of times the customer visited the store within a predetermined period, the total number of times the customer visited the store, and the total amount of money settled by the customer at the store. The management server 200 can transmit the store visit information stored in the store visit history information storage section 252 to the store terminal 300 for each store. The management server 200 can transmit store visit information linked to membership rank to the customer terminal 100.

Furthermore, when the management server 200 transmits to the store terminal 300 that the process of step S911 in FIG. 12 or the process of step S10 in FIG. A complimentary ticket, coupon, prepaid meal ticket, etc. may be issued to the customer terminal 100. Control examples 1 to 6 can also be executed when a customer uses a virtual store.

<Control example 7>
An overview of the processing performed by the management server 200 in relation to the blockchain 500 held by a plurality of computers connected to the network 501 will be described with reference to FIG. 19. The customer terminal 100 and the store terminal 300 log in to the platform of the network 501, and processes such as creating an account, creating a wallet, and depositing money are performed. A plurality of computers, customer terminals 100, management servers 200, and store terminals 300 distributed on the network 501 can participate in, monitor, and view the blockchain 500.

Customer terminal 100 transmits information and data to management server 200 in step S600. The information and data sent from the customer terminal 100 to the management server 200 include all of the customer information, usage information, etc. described above. Further, the store terminal 300 transmits information and data to the management server 200 in step S601. The information and data sent from the store terminal 300 to the management server 200 includes all of the store information, store visit history, etc. described above.

In step S602, the management server 200 processes the information and data and stores the processing results in the storage unit 256. In addition, the management server 200 issues a non-fungible token containing data including acquired customer information and store information, a reward granting history, etc. on the blockchain 500 of the network 501, and requests to sell the non-fungible token. is output in step S603. Furthermore, the non-fungible token that the management server 200 requests to sell also has a membership card, membership number, etc. recorded thereon. That is, the management server 200 creates a wallet and uploads data and information to a plurality of distributed computers on the platform of the network 501. The wallet generates and stores private keys. When a remittance operation is performed using a wallet, information such as the remittance amount, sender, recipient, etc. is converted into data and recorded in the blockchain 500 as a transaction. Transaction data is decrypted with the private key. In the blockchain 500, a non-fungible token is issued (registered) in a block, for example, block 500A, in step S604, and the non-fungible token is posted on the platform in step S605. In other words, an environment is created in which the non-fungible token granting unit 503 can sell and grant non-fungible tokens for free.

The processes of steps S600, S601, S602, and S603 are repeated at predetermined time intervals, and the management server 200 issues a request to the network 501 in step S606 to rewrite the substitutability token issued by the network 501. Here, the information included in the non-fungible token that the management server 200 requests to rewrite or the information in the smart contract that requests rewriting includes the number of stores used by the customer, the amount approved by the customer at each store, and the monthly amount. It includes information indicating the degree of service usage determined from the average payment amount at , the number of times a customer used each store, and the average number of times a store was used per month. Then, in step S607, the network 501 performs a process of rewriting the non-fungible token. For example, the rewritten non-fungible token is recorded in block 500B.

A person who desires to hold (possess) non-fungible tokens can operate customer terminal 100 and place an order to purchase non-fungible tokens sold on network 501 in step S608. A person who wishes to hold (own) non-fungible tokens can operate store terminal 300 to place an order to purchase non-fungible tokens sold on network 501 in step S609. The network 501 performs a process of selling non-fungible tokens to the customer terminal 100 and store terminal 300 in step S610. Further, in step S610, the purchaser (holder) of the non-fungible token is recorded in a predetermined block, for example, block 500C. The customer terminal 100 acquires (purchases) a non-fungible token in step S611. The store terminal 300 acquires (purchases) a non-fungible token in step S612. Note that after step S605, steps S606 and S707 may be skipped and at least one of step S608 and step S609 may be performed.

Furthermore, when a non-fungible token is issued on the blockchain 500 of the network 501, at least one of customer information or store information is sent to the network 501 without going through the management server 200, and the blockchain 500 smart The contract may perform processing to rewrite the non-fungible token. Furthermore, in executing the control example of FIG. 17, the management server 200 performs the authentication process of step S10 of FIG. 17 by referring to the non-fungible token of the blockchain 500, and processes the steps S11, S12, and S13 It is also possible to do this.

Furthermore, the reward granting unit 82 of the management server 200 distributes at least one of the rewards purchased from the reward trading market using the fees that the token issuer obtains from stores, or the rewards held by the token issuer. , may be provided to the customer terminal 100 in step S13 of FIG. Furthermore, a token issuer who intends to issue non-fungible tokens using blockchain 500 or a custodian who keeps non-fungible tokens from a purchaser is registered in blockchain 500 on network 501. Non-fungible tokens may be rewritable. In this case, the smart contract of the blockchain 500 is stored in advance so that a person who is not the holder of the non-fungible token is permitted to rewrite the non-fungible token.

The specific service providing unit 505 has a function of providing the customer terminal 100 with a specific service that can be enjoyed by customers included in the purchasers of non-fungible tokens when control example 7 in FIG. 19 is performed. The specific service is a service that can be used only by authenticated customers, and an example of customer authentication is performed in step S10 in FIG. 17. The specific service includes, for example, the use of a specific store and the use of a specific store's services. The services of a specific store are services that are not provided at other stores. The specific service can also be changed for each piece of information held by the non-fungible token. Services available only to authenticated customers may be provided by the token issuer who is the administrator of the management server 200. Further, the specific service providing unit 505 may issue an instruction to the network 501 so that the non-fungible token granting unit 503 grants a non-fungible token to the customer terminal 100 free of charge.

The determination unit 85 of the management server 200 determines whether a customer included in the purchaser used a specific store among the stores that is not included in the purchaser when control example 7 in FIG. 19 is performed. It may also have the function of Then, the rewriting request unit 508 issues a request to rewrite the information included in the non-fungible token registered in the blockchain 500 based on the usage information only when a customer included in the purchaser uses the specific store. , may be output in step S606. Further, the custody device 509 shown in FIG. 1 may issue a request to rewrite the non-fungible token registered in the blockchain 500.

<Effects of this embodiment>
The original value of non-fungible tokens is unique ownership data, and what is valuable is ownership data, so there is demand in the non-fungible token trading market, and people who own non-fungible tokens The value of doing so itself becomes a digital asset. Consumption data of customers (users) in actual society is written on the blockchain 500 as non-fungible tokens, and each time a customer uses a store, the non-fungible token is updated, thereby contributing to the society. It becomes the customer's unique value, representing the customer's contribution to the token issuer.

In addition, the non-fungible token issuer issues a non-fungible token equipped with a membership card and membership number, and the consumption data of customers who hold the non-fungible token is updated on the blockchain 500 of the network 501. can be made. Therefore, those who wish to hold non-fungible tokens and those who are interested in non-fungible tokens can freely access the non-fungible token trading market. In addition, non-fungible tokens become unique digital assets held by customers, that is, consumers.

Furthermore, the supply of non-fungible tokens is visualized on Blockchain 500, making them a more premium digital asset for token issuing customers. As a result, customers who use the token issuer's services will be able to receive rewards from the token issue and receive special services by using the service more. Furthermore, token issuers can utilize non-fungible token membership cards with premium value to build deeper relationships with customers with high membership ranks (status), such as loyal customers. Furthermore, as services based on Web3 rapidly accelerate, blockchain technology can be used to revitalize consumption in actual society and help token issuers solve marketing issues.

<Supplementary explanation>
It goes without saying that the present disclosure is not limited to the embodiments, and can be modified in various ways without departing from the gist thereof. For example, the store terminal 300 may be used by either a member store (registrant) that receives applications from the management server 200 or a non-member store (non-register). The determining unit 85 may have a function of determining whether the service used by the user is a service provided by an affiliated store or a service provided by a non-affiliated store. The premise is that the payment application or credit card used by the user for payment using the services of the service provider is affiliated with the token issuer who is the operator of the management server 200. Then, when the user makes a payment for using the service, usage information for the service is sent to the management server 200 via the network 501. The rewriting request unit 508 updates the blockchain based on the usage information, regardless of whether the service used by the user is a service provided by a registrant or a service provided by a non-registrant. A request to rewrite information included in a non-fungible token registered in 500 can be generated.

The stores described with reference to the figures in FIGS. 1 to 19 are examples of service providers, and the service providers of the present disclosure include sports teams, local governments, and the like. The sports team may be a soccer team, a basketball team, a baseball team, etc. The services provided by sports teams include sports and practice guidance, sales and rental of equipment used in sports, rental of playing fields, etc. Local governments are prefectures, towns, and villages, etc., and the services provided by local governments include resident/family registration affairs, pension/insurance affairs, nursing care services, garbage disposal services, firefighting services, etc.

If the service provider is a sports team, the service provider information includes information on the overall services provided by the sports team. When the service provider is a local government, the service provider information includes all services provided by the local government. The usage information includes payment using synchro points, use of a web service that obtains information by linking customer IDs, payment when using a product delivery system, and the like. The above service providers can be replaced with the service providers described with reference to the diagrams of FIGS. 1 to 19. Further, the services provided by the above-mentioned service providers can be replaced with the services described with reference to the diagrams of FIGS. 1 to 19.

In addition, when a local government issues non-fungible tokens, stores in that local government are managed so that the non-fungible tokens recorded in the blockchain 500 are rewritten based on usage information used by users. The server 200 may issue the instruction. Furthermore, the issuer of the non-fungible token is not limited to the operator of the management server 200, but may also be a store, a local government, a sports team, a web service provider, or the like. In other words, the store issues a non-fungible token issuance request to the network 501 using the store terminal 300. Furthermore, local governments can issue a request for issuance of non-fungible tokens to the network 501 using a dedicated terminal. Further, the sports team can issue a non-fungible token issuance request to the network 501 using a dedicated terminal. A web service provider can issue a non-fungible token issuance request to the network 501 using a dedicated terminal.

In addition, as mentioned above, non-fungible tokens are entrusted to the holder who has obtained the non-fungible token and has the private key used for the security of the blockchain 500, and the custodian without the private key manages the non-fungible token. A storage device 509 is provided to store the information. Therefore, although not shown in FIG. 19, the custody device 509 in FIG. 1 may generate a request to rewrite the non-fungible token registered in the blockchain. The request generated by the custody device 509 may be sent to the blockchain 500 via the management server 200 or may be sent to the blockchain 500 without passing through the management server 200.

Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. . Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with other configurations. For example, the reward granting device and reward granting method of the present disclosure can be applied to stores that do not have passcodes. Therefore, in stores that do not have passcodes, operations, processes, judgments, etc. related to passcodes, which are described in this disclosure, are omitted.

Further, each of the configurations, functions, and processing units described above may be partially or entirely realized by hardware (for example, an integrated circuit), module, or unit. Furthermore, each of the configurations, functions, and processing units described above may be realized by software by a processor interpreting and executing programs that implement the respective functions. Information such as programs, tables, files, etc. that implement each function can be stored in a memory, a recording device such as a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD. The storage unit 256 may be built into the management server 200 or connected to the management server 200 by wire or wirelessly. The storage unit 57 may be either built into the store terminal 300 or externally attached to the store terminal 300. The non-fungible token management device may be a workstation, host computer, or mainframe in addition to the management server.

This embodiment also discloses the following non-fungible token management system. In a non-fungible token management system that includes a user terminal, a service provider terminal, and a management server that are interconnected via a network, service user information regarding a service provider who provides services to a user, and the user an issuing department that issues non-fungible tokens containing usage information indicating that the user has used the service, on a blockchain formed by computers connected to a network, and the non-fungible tokens that are issued on the blockchain; a non-fungible token granting unit that grants a non-fungible token to a person who can acquire it; and a non-fungible token granting unit that grants information included in the non-fungible token issued on the blockchain based on the usage information of the user included in the person who can acquire it. A non-fungible token management system, comprising: a rewriting unit that rewrites the token before it is given to the acquirer.

The following information processing program is also disclosed in this embodiment. For example, a non-fungible token management device that generates a request for a blockchain formed by a computer connected to a network may be used as a service provider information of a service provider that provides a service to a user, and the service provided by the user. issuance request means for generating a request to issue a non-fungible token on the blockchain, including usage information of the non-fungible token; Functions as a token granting means, and a rewriting request means that generates a request to rewrite information included in the non-fungible token issued on the blockchain based on the usage information by the user included in the acquirer. A non-fungible token management program is disclosed. Step S603 in FIG. 19 is an example of issue request means and grant request means, and step S606 is an example of rewrite request means. Customers who are users of stores, users who receive services from service providers, people who wish to purchase non-fungible tokens, and acquirers who acquire non-fungible tokens for free are examples of people who can acquire them. .

The present disclosure can be used as a non-fungible token management device that can register non-fungible tokens in a blockchain and update information included in non-fungible tokens registered in the blockchain.

50... Control unit, 82... Reward grant unit, 85... Judgment unit, 200... Management server, 500... Block chain, 501... Network, 506... Issue request unit, 507... Grant request unit, 508... Rewrite request unit, 509... Storage device

Claims (8)

A request to issue a non-fungible token containing service provider information of a service provider that provides a service to a user, and information on how the service is used by the user, on a blockchain formed by computers connected to a network. an issuance request unit that generates
a grant request unit that generates a request to grant the non-fungible token issued on the blockchain to a person who can obtain it;
a rewriting request unit that generates a request to rewrite information included in the non-fungible token issued on the blockchain based on the usage information by the user included in the acquirer;
A non-fungible token management device having: The non-fungible token management device according to claim 1,
The rewriting request unit generates a request to rewrite information included in the non-fungible token or a request to rewrite information in a smart contract associated with the non-fungible token, based on the usage information. Token management device. The non-fungible token management device according to claim 1 or 2,
A token issuer who refers to the information included in the non-fungible token registered in the blockchain from outside the blockchain and issues the non-fungible token based on the reference result, issues the non-fungible token to the user. A non-fungible token management device, further comprising a control unit that manages the service provided to the non-fungible token management device. The non-fungible token management device according to claim 3,
The control unit controls at least one of the rewards purchased from a reward trading market using fees acquired by the token issuer from the service provider, or the rewards held by the token issuer. A non-fungible token management device that grants a non-fungible token to the user. The non-fungible token management device according to claim 2,
The information included in the non-fungible token that the rewrite requesting unit requests rewriting, or the information on the smart contract that the rewriting requesting unit requests rewriting, includes the number of service providers used by the user, A non-fungible token management device that includes information indicating a degree of use of the service determined from an amount settled by the user by using the service, and a number of times the user uses the service. The non-fungible token management device according to claim 1 or 2,
A depository device that acquires the non-fungible token and is managed by a custodian who does not have the private key, entrusts the non-fungible token from the holder who has the private key used for the security of the blockchain. Further provided,
A non-fungible token management device, wherein the rewriting request unit or the custody device generates a request to rewrite the non-fungible token registered in the blockchain. The non-fungible token management device according to claim 1 or 2,
The non-fungible token management device further includes a specific service providing unit that provides a specific service to the users included in the users who can obtain the non-fungible token. The non-fungible token management device according to claim 1 or 2,
The service provider is:
a registrant registered by the token issuer that issues the non-fungible token;
a non-registered person who is not registered by said token issuer;
including;
further comprising a determination unit that determines whether the service used by the user is a service provided by the registrant or a service provided by the non-registrant;
The rewriting request unit is configured to update the service based on the usage information regardless of whether the service used by the user is a service provided by the registrant or a service provided by the non-registrant. A non-fungible token management device having a function of generating a request to rewrite information included in the non-fungible token registered in the blockchain.

Images