Non-fungible token management device

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

[Technical field]

[0001] The present disclosure relates to a non-fungible token management device that can register non-fungible tokens on a blockchain and update information contained in the non-fungible tokens registered on the blockchain. [Background technology]

[0002] An example of a content output system using a non-fungible token that can register a non-fungible token on a blockchain and update information included in the non-fungible token registered on the blockchain is described in Patent Document 1. Patent Document 1 describes a content output system that includes a user terminal capable of outputting digital content and a blockchain that holds a non-fungible token (hereinafter referred to as "NFT") associated with the digital content, in which the NFT or a smart contract associated therewith 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. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7043672 Summary of the Invention [Problem to be solved by the invention]

[0004] The inventors of the present application recognized the problem that the technology described in Patent Document 1 is a system for issuing non-fungible tokens that is primarily intended for digital content traded in a virtual world, such as digital art, and does not link to information in the real world.

[0005] The objective of the present disclosure is to provide a non-fungible token management device that can issue non-fungible tokens linked to information in the real world using a blockchain. [Means for solving the problem]

[0006] The non-fungible token management device disclosed herein includes an issuance request unit that generates a request to issue a non-fungible token on a blockchain formed by a computer connected to a network, the non-fungible token including service provider information of a service provider that provides a service to a user and usage information of the service by the user, an assignment request unit that generates a request to assign the non-fungible token issued on the blockchain to an acquirer, and a rewrite 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. Effect of the Invention

[0007] The non-fungible token management device disclosed herein can issue non-fungible tokens linked to information in the real world on a blockchain. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram showing an overview of a non-fungible token management system including a non-fungible token management device according to the present disclosure. [Diagram 2] FIG. 1 is a schematic diagram showing an overview of a non-fungible token management device of the present disclosure. [Diagram 3] FIG. 2 is a schematic diagram showing an overview of a customer terminal. [Figure 4] FIG. 2 is a schematic diagram showing an overview of a store terminal. [Diagram 5] A figure showing an example of store information stored in a store information storage unit of the non-fungible token management device of the present disclosure. [Figure 6] A figure showing an example of visit history information stored in the visit history information storage unit of the non-fungible token management device of the present disclosure. [Figure 7] A figure showing an example of a usage information input screen displayed on the display of a store terminal connected to a non-fungible token management device. [Figure 8] FIG. 13 is a diagram showing an example of a passcode input screen displayed on a display of a store terminal. [Figure 9] FIG. 13 is a diagram showing an example of a read code issuing screen displayed on a display of a store terminal. [Figure 10] A figure showing an example of a confirmation screen displayed on the display of a customer terminal connected to the non-fungible token management device. [Figure 11] FIG. 13 is a diagram showing an example of a completion screen displayed on the display of a customer terminal. [Figure 12] 11 is a flowchart showing a first control example performed in the non-fungible token management system. [Figure 13] 11 is a flowchart showing a second control example performed in the non-fungible token management system. [Figure 14] 11 is a flowchart illustrating a third control example performed in the non-fungible token management system. [Figure 15] A diagram showing an overview of the store's take-out food and drink information displayed on the display of a customer terminal. [Figure 16] A figure showing an example of number of visits information stored in the visit history information storage unit of the non-fungible token management device of Figure 1. [Figure 17] 11 is a flowchart showing a fourth control example performed in the non-fungible token management system. [Figure 18] FIG. 13 is a diagram showing an example of a reward selection screen displayed on a customer terminal in control example 6. [Figure 19] 11 is a flowchart showing a seventh control example performed in the non-fungible token management system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] <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 including 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 a non-fungible token registered in the blockchain. Hereinafter, an embodiment of the non-fungible token management device of the present disclosure will be described in detail with reference to the drawings. In addition, in all drawings for explaining the embodiment, the same parts are generally designated by the same reference numerals, and repeated explanations thereof will be omitted.

[0010] <Overall composition> An example of a non-fungible token management system including a non-fungible token management device of the present disclosure is shown in FIG. 1. The non-fungible token management system 10 manages non-fungible tokens issued in a blockchain 500 on a 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 deposit device 509. The management server 200 is connected to the customer terminal 100 through the network 501. The store terminal 300 is connected to the management server 200 through the network 501. The blockchain 500 is held by a plurality of distributed computers connected to the network 501. The deposit device 509 is connected to the network 501. The customer terminal 100 is an example of a user terminal. The store terminal 300 is an example of a service provider terminal. The plurality of distributed computers connected to the network 501 may include any of the customer terminal 100, the management server 200, and the store terminal 300. The management server 200 corresponds to a non-fungible token management device of the present disclosure. The network 501 includes a network that is constructed using either wireless or wired networks, and a network that is constructed using both wireless and wired networks.

[0011] The blockchain 500 is a public blockchain in which an unspecified number of participants can participate by using a computer connected to the network 501. In other words, the network 501 is a Web3 type Internet based on the public blockchain 500. The blockchain 500 is a distributed database in which all data including store information and customer information is treated as a transaction history using non-fungible tokens (NFTs), and is organized into blocks 500A, 500B, and 500C, and the blocks 500A, 500B, and 500C are connected like a single chain. The blockchain 500 registers (authenticates) the non-fungible tokens issued by the management server 200, and holds (stores) the non-fungible tokens in a rewritable state. The blockchain 500 has smart contracts as autonomously operating programs.

[0012] In addition, computers connected to the network 501 serve as an issuing unit 502, a rewriting unit 504, and a non-fungible token granting unit 503. The issuing unit 502 has a function of issuing a non-fungible token requested to be issued by the management server 200 in the blockchain 500. The non-fungible token granting unit 503 has a function of selling a non-fungible token registered in the blockchain 500 to a purchaser, and a function of granting a non-fungible token registered in the blockchain 500 free of charge. The rewriting unit 504 has a function of rewriting at least one of information included in a non-fungible token registered in the blockchain 500 or information of a smart contract associated with the non-fungible token.

[0013] A store provides 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 the sale of goods, the rental of goods, the transportation of goods, the provision of services, and the like. Goods include objects such as liquids, gases, and solids, as well as food, cooking, and software. Services include financial services, communications services, education services, real estate services, leisure services, and entertainment services. Stores include both real stores and virtual stores (shops on the Internet). Examples of real stores include cafeterias, restaurants, entertainment facilities, and banks. Usage information indicating a customer's use of a store includes a customer's visit to the store, the number of times the customer visits the store, a customer's ordering of a product at the store, a customer's reservation of a product, a customer's eating and drinking at the store, a customer's payment of the purchase amount at the store, and the like. If the store is a virtual store, the usage information includes a customer's access to or login to the virtual store, the number of times the customer accesses or logs in to the virtual store, a customer's electronic commerce at the virtual store, and the like. When the store is an actual store, the store terminal 300 is installed or movably placed in the space within the store.

[0014] The store usage information is an example of usage information in which a user uses a service provided by a service provider. If the store is a virtual store, the services provided by the store include providing web services, viewable or downloadable videos and animations, games, music, etc. to customers. Regardless of the service, the usage information also includes an ID that identifies the user, credit card information, etc. Furthermore, the use of the service also 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 cryptocurrency. In addition, the customer terminal 100, the management server 200, and the store terminal 300 are implemented with predetermined hardware and software. For example, the customer terminal 100, the management server 200, and the store terminal 300 each include an input port, an output port, and a computer having a processor, memory, etc.

[0015] The customer terminal 100 includes affiliated users to whom applications are provided from the management server 200, and non-affiliated users to whom applications are not provided from the management server 200. The customer terminal 100 may be either a fixed terminal or a portable terminal. The fixed terminal includes a desktop personal computer. The portable terminal includes a tablet terminal and a smartphone. As shown in FIG. 2, the customer terminal 100 includes an input unit 100A, a display (display unit) 15, a reading unit 51, a control unit 52, a communication unit 53, and a memory unit 91. The input unit 100A includes a touch panel, a button, a keyboard, a mouse, a stick, etc. The customer terminal 100 accepts input and operation of various signals and information from the input unit 100A and the reading unit 51. The control unit 52 processes the 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 the programs, data, information, etc. stored in the memory unit 91, and controls the display of the display 14. The control unit 52 causes the communication unit 53 to output a signal, and processes a signal input from the communication unit 53. The communication unit 53 can transmit and receive signals between the client terminal 100 and the management server 200 via a network 501. The communication unit 53 can also transmit and receive signals between a plurality of distributed computers constructing a blockchain via the network 501.

[0016] An application for performing payment processing is provided from the management server 200 and pre-installed on the customer terminal 100. After the application is installed on the customer terminal 100, information to be transmitted from the customer terminal 100 to the management server 200, such as information on the customer's credit card, email address, domain, accounts for various services, the type of reward previously selected by the customer, ID pass, etc., is registered in the storage unit 256 of the management server 200.

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

[0018] The management server 200 is managed by a token issuer who intends to issue a non-fungible token in the blockchain 500, and has a function of issuing a non-fungible token. The token issuer can also be defined as a business operator. The management server 200 provides various applications to the customer terminal 100 and the store terminal 300. As shown in FIG. 3, the management server 200 has a control unit 50, a memory unit 256, and a communication unit 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 memory unit 256 and the communication unit 257.

[0019] The control unit 50 has a notification processing unit 210, a cryptocurrency granting unit 220, a screen generating unit 230, an information updating unit 240, an authentication unit 80, a judgment unit 85, a reward presentation unit 81, a reward granting unit 82, an issuance request unit 506, a grant request unit 507, a rewrite request unit 508, and a specific service providing unit 505. The storage unit 256 has 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 operate and function the management server 200. The program storage unit 258 also stores various programs and applications to be provided to the customer terminal 100, the store terminal 300, and computers connected to the network 501.

[0020] The management server 200 obtains (receives) from the store terminal 300 the store ID, the number of customers who visited the store, the customer ID, the amount used by the customers at the store, etc. 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 read code for settling the amount used based on the store ID for identifying the store, the number of customers, and the amount. The screen generation unit 230 also provides the store terminal 300 with a read code issuance screen including the read code.

[0021] The information update unit 240 of the management server 200 acquires a customer ID (such as an application ID (ID of the application itself assigned to the customer)) at the time of payment. The information update unit 240 also associates the customer ID for identifying the customer, the store ID acquired when the reading code is read by the customer terminal 100, the store visit date and time, the amount used by the customer, and the number of people who visited the store in the store visit history information storage unit 252. 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.

[0022] 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 messages and coupons to customer terminals 100 that are confirmed to have not visited the store for a predetermined period of time or more. More specifically, the notification processing unit 210 periodically (e.g., every other day) obtains the store visit history information from the store visit history information storage unit 252, and transmits messages and coupons to customer terminals 100 of customers who have not visited the store for a predetermined period of time or more. For example, the notification processing unit 210 of the management server 200 transmits a message such as "You have not visited the store for more than a month" to the customer terminal 100.

[0023] The notification processing unit 210 also transmits coupons and the like related to food and drink previously ordered to the customer terminal 100 based on the order information constituting the store visit history information. The determination unit 85 has a function of determining signals, information, and data. The determination unit 85 also has a function of determining whether a customer included in the purchasers (holders) of a non-fungible token has used a specific store among the stores that is not included in the purchasers of a non-fungible token. The authentication unit 80 of the management server 200 authenticates that the customer has used the store.

[0024] The reward presentation unit 81 of the management server 200 presents multiple types of rewards to the customer. The reward granting unit (reward provision unit) 82 of the management server 200 grants (provides) rewards to the customer. The reward granting unit 82 also has a function of referring to information contained in non-fungible tokens registered in the blockchain 500 from outside the blockchain 500 and providing rewards to the customer based on the reference results. The reward granting unit further has a function of providing at least one of rewards purchased from the reward trading market using fees obtained by the token issuer from stores as a source of funds, or rewards held by the token issuer to the customer. Rewards will be described later.

[0025] More specifically, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252, identifies a corresponding coupon based on at least one of the conditions of the store visit date and time (time period), the amount, and the number of people that constitute the store visit history information, and transmits the identified coupon to the customer terminal 100. Then, based on the time period when the customer ate and drank at the store and the amount used, it becomes possible to recommend recommended menus and coupons to the customer via an application. In addition, the management server 200 can learn the store visited by the customer, the menu selected by the customer at the store, the hobbies and preferences of food, cooking, etc., by the AI ​​function, and select a store based on the learning result and recommend it to the customer. 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 any language type is possible, such as English, Chinese, Korean, French, German, etc.

[0026] The notification processor 210 also acquires information on related stores (stores in other groups in the case of multiple stores) from the store information storage unit 251. Then, based on the time period when the customer drank and the amount, the notification processor 210 estimates the customer's preferences and behavior patterns, and transmits coupons for the related stores to the customer terminal 100. This makes it possible to increase sales across the entire group, including the related stores, particularly in the case of multiple stores.

[0027] The cryptocurrency granting unit 220 of the management server 200 calculates the success fee to be charged to the store (paid from the store to the operator of the management server 200) by multiplying the meal price (the amount paid by the customer) by a predetermined rate (e.g., 5% or more). 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.

[0028] The cryptocurrency granting unit 220 of the management server 200 calculates the amount of cryptocurrency to be granted to the customer by multiplying the meal fee by a predetermined rate (e.g., 1% or more). Then, the notification processing unit 210 of the management server 200 transmits the amount of cryptocurrency corresponding to the amount calculated by the cryptocurrency granting unit 220 to the customer terminal 100. The cryptocurrency granting unit 220 may also calculate the amount of cryptocurrency to be granted to the customer by multiplying the success fee amount by a predetermined rate (e.g., 10 to 40%). In other words, the cryptocurrency granting unit 220 calculates a portion of the success fee amount as cryptocurrency.

[0029] The issuance request unit 506 has a function of generating a request to issue a non-fungible token in the blockchain 500, including store information about the store and usage information indicating that the customer has used the store. The grant request unit 507 has a function of generating a request to grant the non-fungible token held in the blockchain 500 to a customer, who is an example of an acquirer. The rewrite request unit 508 has a function of generating a request to rewrite at least one of information included in the non-fungible token registered in the blockchain 500 and information of a smart contract associated with the non-fungible token, based on the usage information by the customer. The specific service providing unit 505 has a function of providing a specific service that can be enjoyed by a customer included in the purchaser of the non-fungible token to the customer. The specific service providing unit 505 also has a function of granting the non-fungible token to the customer terminal 100 free of charge.

[0030] Furthermore, the control unit 50 has a function of receiving purchase orders for non-fungible tokens on the network 501 and generating a platform for selling non-fungible tokens. Furthermore, the control unit 50 has a function of referring to information contained in non-fungible tokens registered in the blockchain 500 from outside the blockchain 500 and managing services provided by token issuers to customers based on the reference results. Managing services provided to customers also means using the information to authenticate services provided by token issuers to customers, services or rooms available only to specific customers, special preferential information, etc., and to provide services after authentication.

[0031] The store terminal 300 includes an affiliated store (registered person) to which an application is provided from the management server 200, and a non-affiliated store (non-registered person) to which an application is not provided from the management server 200. As shown in FIG. 4, the store terminal 300 includes an input unit 300A, a display (display unit) 20, a reading unit 54, a computer 55, a memory unit 57, and a communication unit 56. The reading unit 54 includes a camera, a scanner, a barcode reader, a magnetic sensor, an optical sensor, etc. The magnetic sensor may be either a contact type or a non-contact type. The input unit 300A includes a touch panel, a button, a keyboard, a mouse, a stick, etc. The store terminal 300 accepts input and operation of various signals and information from the input unit 300A and the reading unit 54. The computer 55 is connected to the reading unit 54, the memory unit 57, the communication unit 56, the display 20, and the input unit 300A so as to be able to send and receive signals.

[0032] The storage unit 57 stores data, information, applications, programs, etc. The computer 55 performs processing, judgment, and control based on the information, data, etc. stored in the storage unit 57. The computer 55 processes signals and information input from the input unit 300A and the reading unit 54. The computer 55 controls the display content of the display 20. The computer 55 outputs signals from the communication unit 56 and processes signals input from the communication unit 56. The communication unit 56 can transmit and receive signals between the customer terminal 100 and the management server 200 via the network 501. In addition, the communication unit 56 can transmit and receive signals between multiple distributed computers that construct the blockchain via the network 501.

[0033] Furthermore, a customer can operate the input unit 100A to select a reward to be received in advance and transmit the information to the management server 200 and the store terminal 300. The information transmitted from the customer terminal 100 and the management server 200 to the store terminal 300 is stored in the storage unit 57.

[0034] Various applications are installed in the store terminal 300. The applications installed in the store terminal 300 are provided by the management server 200. When a customer makes a payment by reading a read code using the customer terminal 100, the store terminal 300 accumulates store visit history information. Specifically, when a customer reads a read code with the customer terminal 100, the store terminal 300 acquires the customer ID, the store visit date and time, and the usage amount (payment amount). The store terminal 300 then calculates the amount of cryptocurrency by multiplying the acquired amount by a predetermined rate. The store terminal 300 transmits information associating the acquired customer ID, the store visit date and time, the amount, and the amount of cryptocurrency to the management server 200, and the management server 200 stores the received information in the store visit history information storage unit 252.

[0035] The depository 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 of depositing non-fungible tokens from purchasers (holders) of non-fungible tokens, and a function of issuing requests to rewrite non-fungible tokens registered in the blockchain 500. The depository device 509 also has a function of acquiring non-fungible tokens and depositing non-fungible tokens from holders who have a private key used for the security of the blockchain 500. The depository device 509 is managed by a depository who does not have a private key.

[0036] <Store Information> FIG. 5 is a diagram showing an outline of an example of the configuration of store information stored in the store information storage unit 251 of the management server 200 in the first embodiment of the present disclosure. The store information is an example of service provider information. As shown in FIG. 5, the store information is composed of 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 a store. The group ID indicates a code for identifying a group in the case of a multi-store operation, etc. 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 the 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.

[0037] <Visit history information> FIG. 6 is a diagram showing an outline of an example of the configuration of the store visit history information stored in the store visit history information storage unit 252 of the management server 200 in the first embodiment of the present disclosure. The store visit history information is an example of service usage information by a user. As shown in FIG. 6, the store visit history information includes a store ID, a passcode, a customer ID, a store visit date and time, a payment amount, a number of people, and a reward offer amount. The 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 a 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 who visited the store. The cryptocurrency amount indicates the amount of cryptocurrency granted to the customer by the management server 200.

[0038] <User information entry screen> Fig. 7 is a diagram showing an outline of a configuration example of the usage information input screen 11 displayed on the display 20 of the store terminal 300 in the first embodiment of the present disclosure. The usage information input screen 11 is provided by the screen generating 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 confirm button 1330, and a read code reading start button 1340.

[0039] The number of customers input field 1310 accepts input of the number of customers who visited 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 input, the store terminal 300 transmits the number of people input in the number of customers input field 1310 and the amount input in the amount input field 1320 to the management server 200.

[0040] <Passcode entry screen> When the read code reading start button 1340 is selected, the store terminal 300 displays the passcode entry screen 12 of FIG. 8 provided by the management server 200 on the display 20. A passcode entry button 1410 is displayed on the passcode entry screen 12. A passcode is entered by the passcode entry button 1410 accepting an entry. The store terminal 300 transmits the entered passcode, the number of people and the amount entered via the usage information entry screen 11 of FIG. 4 to the management server 200.

[0041] <Read code issuing screen> When the passcode is entered, the store terminal 300 displays the read code issuance screen 13 of Fig. 9 provided by the management server 200 on the display 20. The read code issuance screen 13 displays a number of people display field 1510, an amount display field 1520, a read code 1530, and a done button 1540.

[0042] The number of people display field 1510 displays the number of people entered on the usage information input screen 11 of Fig. 4. The amount display field 1520 displays the amount entered on the usage information input screen 11. After the customer terminal 100 reads the read code 1530, when the completion button 1540 accepts the input, the store terminal 300 transmits a notification to the management server 200 that the completion button 1540 has accepted the input.

[0043] <Confirmation screen> When the management server 200 receives a 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 accepted as input by the amount input field 1320.

[0044] <Completion screen> When the approval button 1630 accepts input, the client terminal 100 causes the completion screen 16 of FIG. 11 provided by the management server 200 to be displayed on the display 14. A completion button 1710 is displayed on the completion screen 16. The completion screen also displays a message indicating the time when the cryptocurrency will be granted, such as "It will be granted at the current market rate within 15 days." When the completion button 1710 accepts input, a series of processes from the payment process to the cryptocurrency process is completed.

[0045] <Control example 1> 12 is a flowchart showing a first control example 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 a customer visits the store, the number of customers input field 1310 of the usage information input screen 11 accepts input of the number of customers who visited the store. In addition, 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.

[0046] When the Confirm button 1330 accepts input, in S902, the store terminal 300 transmits the number of people entered in the number of people input field 1310 in S901 and the amount entered in the amount input field 1320 to the management server 200. Then, when the read code reading start button 1340 accepts input (selection), the process proceeds to S903.

[0047] Next, in S903, the management server 200 receives the number of people and the amount transmitted in S902. Next, in S904, the screen generation unit 230 of the management server 200 provides the passcode input 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 a passcode. Next, in S906, the store terminal 300 transmits the input passcode and store ID to the management server 200. In S907, the management server 200 receives the passcode and store ID transmitted from the store terminal 300.

[0048] Next, in S908, the screen generation unit 230 of the management server 200 generates a read code for payment based on the store ID and the number of people and amount received in S903. The screen generation unit 230 also generates a read code issuance screen 13 based on the generated read code and the number of people and amount received in S903. Next, in S909, the screen generation unit 230 of the management server 200 provides the read code issuance screen 13 generated in S908 to the store terminal 300.

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

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

[0051] 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 of 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 / rejection information is sent from the customer terminal 100 to the management server 200.

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

[0053] Next, in S916, the management server 200 receives the customer ID, store ID, passcode, visit date and time, amount, and number of people sent in S915. The cryptocurrency granting unit 220 of the management server 200 then multiplies the received amount (food and drink cost) by a predetermined rate (e.g., 5% or more) to calculate the success fee to be charged to the store. The cryptocurrency granting unit 220 also multiplies the amount (food and drink cost) by a predetermined rate (e.g., 1% or more) to calculate the amount of cryptocurrency to grant to the customer.

[0054] Next, in S917, the management server 200 associates the store ID, passcode, customer ID, visit date and time, amount, number of people, and the cryptocurrency amount calculated in S916 received in S916 and stores them in the store visit history information storage unit 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 cryptocurrency amount to the customer terminal 100. In addition, the notification processing unit 210 of the management server 200 transmits the calculated success fee amount to the store terminal 300.

[0055] Next, in step S919, the customer terminal 100 displays the completion screen 16 on the display 20, 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 input, a series of processes from the payment process to the cryptocurrency process is completed.

[0056] As described above, when the control example 1 is performed, the screen generating unit 230 of the management server 200 generates the read code 1530 for settlement based on the store ID, the number of people, and the amount, and provides the read code issuing screen 13 including the read code 1530 to the store terminal 300. The information updating unit 240 stores the customer ID, the store ID, the visit date and time, the amount, and the number of people acquired by reading the read code 1530 with the customer terminal 100, in the store visit history information storage unit 252 in association with each other. Therefore, the management server 200 can facilitate settlement of the usage amount between the store and the customer, and can enable customer relationship management (CRM). In addition, the store can utilize the information transmitted from the management server 200 to the store terminal 300 for point of sale information management (POS).

[0057] In addition, 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 specified period of time or more, thereby encouraging the customer to visit the store again or later.

[0058] In addition, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252, and identifies a corresponding coupon based on at least one of the store visit date and time, amount, and number of people that constitute the store visit history information, and sends the identified coupon to the customer terminal 100, thereby making it possible to encourage the customer to visit the store again or later with greater accuracy, while taking into account the customer's behavioral patterns.

[0059] Moreover, the cryptocurrency granting unit 220 multiplies the amount by a predetermined rate to calculate the amount of cryptocurrency to be granted to the customer, and the notification processing unit 210 transmits the amount of cryptocurrency to the customer terminal 100, thereby allowing an incentive to be granted to the customer according to the customer's store visit record. Furthermore, the cryptocurrency granting unit 220 multiplies the amount by a predetermined rate to calculate the amount of success fee to be paid from the store to the administrator of the management server 200. Furthermore, the cryptocurrency granting unit 220 multiplies the amount of success fee by a predetermined rate to calculate the amount of virtual currency to be granted to the customer. Furthermore, the notification processing unit 210 transmits the amount of success fee to the store terminal 300, and transmits the amount of virtual currency to the customer terminal 100. Therefore, a part of the success fee paid to the administrator of the management server 200 can be granted to the customer as an incentive according to the customer's store visit record.

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

[0061] In step S1603, the management server 200 receives the beacon device identification information, the customer ID, and the visit time. 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 obtains the corresponding store information.

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

[0063] Next, in S1606, the collation unit 250 verifies whether the check-in information and the payment information match. More specifically, the collation unit 250 verifies whether the "customer ID, store ID, group ID, store name, and store address that constitute the check-in information" match the "customer ID, store ID, group ID, store name, and store address that constitute the payment information."

[0064] The matching unit 250 may check whether the "customer ID, store ID, group ID, store name, and store address constituting the check-in information" and the "customer ID, store ID, group ID, store name, and store address constituting the payment information" match in part. This makes it possible to match the store where the payment is actually made with the store specified by the information from the beacon device 400, thereby improving the accuracy of the payment.

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

[0066] Next, in step S1607, the customer terminal 100 accepts input of predetermined card information on the card information input screen displayed on the display, and logs in to the management server 200. Then, in step S1608, the customer terminal 100 transmits the card information to the management server 200.

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

[0068] Thereafter, the customer terminal 100 performs a payment process by having the customer use the credit card linked to the statement information in step S1611. Next, the customer terminal 100 transmits the payment information to the management server 200 in S1612.

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

[0070] Next, in step S1615, the management server 200 pays a part of the payment amount calculated based on the above-mentioned payment information to the store terminal 300. After that, in step S1616, the management server 200 overwrites the detailed information called up from the detailed information storage unit 254 with the payment information received from the customer terminal 100, and updates and registers the detailed information.

[0071] As described above, when the control example of FIG. 13 is performed, the matching unit 250 matches the check-in information, including the customer ID and the store information identified from the beacon device identification information, with the pre-stored payment information, thereby making it possible to match the store where the payment is made with the information from the beacon device 400, thereby improving the accuracy of the payment.

[0072] In addition, a check-in function can be realized via the beacon device 400, assuming that a credit card is used, and security associated with credit card payment can be improved. Furthermore, the management server 200 can recognize the customer and the store immediately after the customer terminal 100 receives the beacon identification information from the beacon device 400, and payment can be made while maintaining security from the time of check-in (immediately after check-in).

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

[0074] 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 read information as a key, and acquires the corresponding store information.

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

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

[0077] Thereafter, in S1710, the store terminal 300 transmits the amount and number of people input in S1709 to the management server 200. 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, in step S1712, the management server 200 transmits the received amount, number of people, and one-time pass to the customer terminal 100.

[0078] 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 the consent screen on the display. Next, in step S1714, the customer terminal 100 transmits the consent screen displayed on the display to the management server 200.

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

[0080] 14, by comparing check-in information including customer information and store information identified by reading the QR code with pre-stored payment information, it becomes possible to match the store where payment is made with the customer information, improving the accuracy of payment. Also, even in stores that do not have smartphones, tablets, etc., the management server 200 can make payment by installing a QR code printed on paper in the store and having the customer terminal 100 read the QR code.

[0081] <Control Example 4> Another control example performed by the non-fungible token management system 10 will be described. In this other 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 transmits to the customer terminal 100 information about takeout food and drink at a store that the customer has previously visited or an associated store. This will be described with reference to FIG. 15.

[0082] Fig. 15 is a diagram showing an overview of take-out food and drink information of a store displayed on the display of the customer terminal 100 in the fourth embodiment of the present disclosure. As shown in Fig. 18, the display of the customer terminal 100 displays stores that offer take-out food and drink in the vicinity of the customer's current location 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 transmits to the customer terminal 100 information on stores that offer take-out food and drink in the vicinity of the customer's current location based on the acquired current location of the customer terminal 100, 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, thereby displaying the above on the display of the customer terminal 100.

[0083] The map 1910 displayed on the display of the customer terminal 100 does not have to be a map of the area around the current location of the customer terminal 100, but may be a map of a predetermined area designated by the customer terminal 100.

[0084] In addition, the management server 200 may refer to the store visit history information stored in the store visit history information storage unit 252, and transmit information about take-out food and beverages at a store that has been posted to a social networking service (hereinafter, SNS: Social Networking Service) by a customer other than the customer who desires the information about take-out food and beverages and has received a predetermined number of impressions (for example, more than 500,000 impressions) to the customer terminal 100 of the customer who desires the information about take-out food and beverages.

[0085] In this case, an application for using SNS is installed on the customer terminal 100, and reviews of the store can be posted. The reviews posted include the customer's own impressions of the atmosphere in the store, comments on the food by the customer, photos of the customer eating the food, photos of the food that was actually served, etc. The above application is configured to be switchable between a posting function for eat-in and a posting function for take-out, for example.

[0086] 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 the customer visits the store, the overall process of the payment system shown in FIG. 9 above is executed.

[0087] Here, the notification processing unit 210 of the management server 200 may refer to the store visit history information about take-out visits stored in the store visit history information storage unit 252, and send at least one of a message or a coupon to the customer terminal 100 of the customer who visited the store for take-out, thereby encouraging the customer to visit the store for eat-in from the next time onwards. Furthermore, the notification processing unit 210 may send at least one of a message or a coupon not only to the customer terminal 100 of the customer who actually visited the store for take-out, but also to the customer terminal 100 of the customer who showed interest in the store shown in FIG. 15. Whether or not the customer showed interest in the store can be determined using a well-known method, for example, by analyzing the customer's selection from the list of stores displayed on the map 1910.

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

[0089] Furthermore, even when a customer receives food and beverages via delivery, the notification processing unit 210 of the management server 200 may refer to the store visit history information regarding the use of delivery stored in the store visit history information storage unit 252, and send at least one of a message or a coupon to the customer terminal 100 of the customer who used the delivery service, thereby encouraging the customer to visit the store for eat-in on their next visit or later.

[0090] <Effects of Control Example 4> As described above, according to the fourth control example, the notification processing unit 210 refers to the store visit history information stored in the store visit history information storage unit 252, and transmits at least one of a message and a coupon to the customer terminal 100 of a customer who has visited the store for takeout or a customer who has used delivery, thereby encouraging the customer to visit the store next time or later. In this way, according to the fourth embodiment, good customer relationship management can be achieved.

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

[0092] In this embodiment, for example, the stage of a 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 the control example 1 shown in FIG. 12 above, a screen for selecting participation in the program may be displayed on the display of the store terminal 300 together with the read code, or a customer who has become a store member by another means may be automatically allowed to participate in the program. The number of visits to a store may be counted as visits for eat-in or take-out.

[0093] In addition, the stage of a customer's membership status may be determined based on the results of posts on SNS. For example, the stage of a customer's membership status may be determined based on the number of visits the customer makes to a store and the number of impressions of the customer's posts on SNS about the store.

[0094] The notification processing unit 210 of the management server 200 then refers to the number of visits information based on the visit date and time stored in the visit history information storage unit 252, and sends at least one of a message or a coupon to the customer terminal 100 depending on the stage of the customer's membership status, thereby encouraging the customer to visit the store again or later.

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

[0096] <Control Example 6> The management server 200 in Fig. 1 can execute control example 6. When control example 6 is executed, a customer can select one of a plurality of types of rewards by using the store.

[0097] FIG. 17 is a flowchart showing a sixth control example performed by the management server 200, that is, a reward granting method. First, in step S10, the authentication unit 80 of the management server 200 authenticates that the customer has used the store. 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. In step S11 following step S10, the management server 200 presents multiple types of rewards to the customer. 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. 18.

[0098] The reward presentation screen 60 displays a virtual currency button 61, a synchro point button 62, a common point button 63, and a selection button 64. 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 wishes to obtain synchro points. Synchro points are provided to customers by the administrator of the management server 200. Synchro points can be used to purchase e-gifts provided by the administrator of the management server 200, purchase complimentary coupons, make payments to stores, and the like. Common points are used for a common point service provided by a business (which may be an individual or an organization) different from the administrator of the management server 200. The common point service includes payment for products, discounts on products, complimentary coupons, and the like. These virtual currencies, synchro points, common points, unique tokens issued by token issuers, and virtual currencies are multiple types of rewards.

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

[0100] Further, a modification of the control example 6 in Fig. 17 is as follows. After the customer terminal 100 installs the application and before the customer visits the store, the customer may set the reward to be received in advance. In this case, the management server 200 performs the process of step S10 in Fig. 17, skips the processes of steps S11 and S12, and performs the process of step S13.

[0101] Furthermore, the object read by the reading unit 51 of the customer terminal 100 is not limited to the read code 1530 in FIG. 9. For example, the authentication object 70 of the store can be read by the reading unit 51 of the customer terminal 100 and a signal can be sent from the customer terminal 100 to the management server 200, so that the management server 200 can perform authentication in step S10. The authentication object 70 includes a receipt issued by the store after the payment is made and to which a barcode or QR code is attached. The authentication object 70 may also 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 usage history of cashless payments that the customer has made at the store in the past.

[0102] Also, the reading unit 54 of the store terminal 300 can read the authentication target 71 of the customer together with the payment processing of the amount, and the management server 200 can perform the authentication in step S10 by sending a signal from the store terminal 300 to the management server 200. Furthermore, the reading unit 54 of the store terminal 300 can read the authentication target 71 of the customer separately from the payment processing of the amount, and the management server 200 can perform the authentication in step S10 by sending a signal from the store terminal 300 to the management server 200. In other words, the authentication of "the customer's use of the store" performed by the authentication unit 80 does not depend on the presence or absence of the payment processing of the amount. The authentication target 71 includes a credit card owned by the customer and a personal identification card owned by the customer. The personal identification card includes a driver's license with an IC chip, a My Number card with a QR code, etc. Also, the authentication target 71 may be a fingerprint, a retina, a vein, etc. of the customer. In other words, the authentication performed by the management server 200 in step S10 may be biometric authentication.

[0103] Furthermore, if the store is a virtual store, a signal can be sent from the store terminal 300 to the management server 200 at any one of the following times: when the customer logs in to the virtual store, when the customer reserves a product, when the customer purchases a product, or when the customer pays for the product by credit card, and the management server 200 can perform authentication in step S10.

[0104] Furthermore, the authentication in step S10 in Fig. 17 is not limited to being performed at the same time as the payment when the customer uses the store. For example, it may be performed a certain period of time, such as two weeks, after the payment of the amount used at the store. Also, when making a payment for the first time in a specified month, the processing of step S10 may be performed according to the use of the store in the previous month.

[0105] <Effects of Control Example 6> Customers can select the reward they want from multiple types of rewards. In other words, the application that operates the non-fungible token management system 10 functions as a multi-reward return system. This can motivate customers to use stores and promote an increase in the number of times they visit stores. Furthermore, it can reduce the risks for customers when they purchase virtual currency, lowering the barrier to purchasing virtual currency and expected to expand the use of virtual currency.

[0106] <Other> Furthermore, the shop terminal 300 may have a function to display the frequency of visits, repeat rate, etc. for each customer on the display 20 based on the visit frequency information shown in FIG. 16, that is, a dashboard function.

[0107] Furthermore, when a customer uses a store for the first time and the process of step S911 in Fig. 12 is performed, or when a customer uses a store for the first time and the process of step S10 in Fig. 17 is performed, in step S13, a customer-specific membership card may be issued from the management server 200 to the customer terminal 100. This membership card is a digital membership card, but a digital membership card and a physical membership card may be used together.

[0108] Furthermore, in parallel with the processing of step S911 in FIG. 12 and step S10 in FIG. 17, the management server 200 can determine a member rank (status) for each store in stages based on at least one of the conditions of the number of times the customer visits the store within a predetermined period, the total number of times the customer visits the store, and the total amount of money settled by the customer at the store. The management server 200 can automatically store the store visit information of the customer linked to the member rank in the store visit history information storage unit 252. The store visit information of the customer is at least one of the conditions of the number of times the customer visits the store within a predetermined period, the total number of times the customer visits 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 unit 252 to the store terminal 300 for each store. The management server 200 can transmit the store visit information linked to the member rank to the customer terminal 100.

[0109] Furthermore, when the management server 200 transmits to the store terminal 300 a notice that the processing of step S911 in Fig. 12 or the processing of step S10 in Fig. 17 has been performed, the store terminal 300 may issue a store-specific complimentary ticket, coupon, prepaid meal ticket, or the like to the customer terminal 100 via the management server 200. Control examples 1 to 6 can also be executed when a customer uses a virtual store.

[0110] <Control Example 7> An overview of the processing performed by the management server 200 in relation to the blockchain 500 held by multiple computers connected to the network 501 will be described with reference to Fig. 19. The customer terminal 100 and the store terminal 300 log into the platform of the network 501, and processes such as account creation, wallet creation, and deposit are performed. The multiple computers, customer terminal 100, management server 200, and store terminal 300 distributed on the network 501 can participate in the blockchain 500 and can monitor and view it.

[0111] In step S600, the customer terminal 100 transmits information and data to the management server 200. The information and data transmitted from the customer terminal 100 to the management server 200 includes all of the above-mentioned customer information, usage information, etc. Furthermore, the store terminal 300 transmits information and data to the management server 200 in step S601. The information and data transmitted from the store terminal 300 to the management server 200 includes all of the above-mentioned store information, store visit history, etc.

[0112] In step S602, the management server 200 processes the information and data, and stores the processing result in the storage unit 256. In addition, the management server 200 issues a non-fungible token including the acquired data including customer information and store information, reward grant history, etc., in the blockchain 500 of the network 501, and outputs a request to sell the non-fungible token in step S603. In addition, the non-fungible token requested for sale by the management server 200 also records a membership card and a membership number, etc. 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 a private key. When a remittance operation is performed using the wallet, information such as the remittance amount, remitter, recipient, etc. is digitized and recorded in the blockchain 500 as a transaction. The transaction data is decrypted with the private key. In the blockchain 500, in step S604, a non-fungible token is issued (registered) in a block, for example, block 500A, and the non-fungible token is posted on the platform in step S605. That is, an environment is created in which the non-fungible token granting unit 503 can sell and grant the non-fungible token free of charge.

[0113] The processes of steps S600, S601, S602, and S603 are repeated at predetermined time intervals, and the management server 200 issues a request to rewrite the fungible token issued by the network 501 to the network 501 in step S606. Here, the information included in the non-fungible token requested to be rewritten by the management server 200, or the information of the smart contract requested to be rewritten, includes information indicating the degree of use of the service calculated from the number of stores used by the customer, the amount settled by the customer at each store, the average monthly settlement amount, the number of times the customer used each store, and the average number of times the store was used in a month. Then, in step S607, the process of rewriting the non-fungible token is performed in the network 501. For example, the rewritten non-fungible token is recorded in the block 500B.

[0114] A person who wishes to hold (own) a non-fungible token can operate the customer terminal 100 and place an order to purchase the non-fungible token being sold on the network 501 in step S608. A person who wishes to hold (own) a non-fungible token can operate the store terminal 300 and place an order to purchase the non-fungible token being sold on the network 501 in step S609. The network 501 performs a process of selling the non-fungible token to the customer terminal 100 and the store terminal 300 in step S610. Also, 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) the non-fungible token in step S611. The store terminal 300 acquires (purchases) the non-fungible token in step S612. After step S605, steps S606 and S607 may be skipped and at least one of step S608 and step S609 may be performed.

[0115] Furthermore, when a non-fungible token is issued in the blockchain 500 of the network 501, at least one of customer information and store information may be transmitted to the network 501 without passing through the management server 200, and a smart contract of the blockchain 500 may perform a process of rewriting the non-fungible token. Furthermore, when executing the control example of FIG. 17, the management server 200 may refer to the non-fungible token of the blockchain 500 to perform the authentication process of step S10 in FIG. 17 and the processes of steps S11, S12, and S13.

[0116] Furthermore, the reward granting unit 82 of the management server 200 may provide at least one of the rewards purchased from the reward trading market using the fee acquired from the store by the token issuer as a source of funds or the rewards held by the token issuer to the customer terminal 100 in step S13 of FIG. 17. Furthermore, a token issuer who intends to issue a non-fungible token using the blockchain 500, or a depositor who holds a non-fungible token from a purchaser, may be able to rewrite the non-fungible token registered in the blockchain 500 on the network 501. In this case, the smart contract of the blockchain 500 is pre-stored so that a person who is not a holder of the non-fungible token is permitted to rewrite the non-fungible token.

[0117] 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 the non-fungible token when the control example 7 of 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 of FIG. 17. The specific service includes, for example, use of a specific store and use of a service of a specific store. The service of a specific store is a service that is not provided in other stores. The specific service can also be changed for each piece of information held by the non-fungible token. The service that can be used only by authenticated customers may be provided by a token issuer who is an administrator of the management server 200. In addition, the specific service providing unit 505 may instruct the network 501 to grant a non-fungible token to the customer terminal 100 free of charge from the non-fungible token granting unit 503.

[0118] The judgment unit 85 of the management server 200 may have a function of judging whether or not a specific store not included in the purchaser has been used among the stores when control example 7 of FIG. 19 is performed. Then, the rewrite request unit 508 may issue a request in step S606 to rewrite information included in the non-fungible token registered in the blockchain 500 based on the usage information only when a specific store has been used by a customer included in the purchaser. Also, the depository device 509 shown in FIG. 1 may issue a request to rewrite the non-fungible token registered in the blockchain 500.

[0119] <Effects of this embodiment> The original value of a non-fungible token is the unique ownership data, and when something valuable becomes ownership data, there is demand for it in the trading market for non-fungible tokens, and the value of owning a non-fungible token itself becomes a digital asset. By writing consumption data of customers (users) in the real world as non-fungible tokens on the blockchain 500 and updating the non-fungible tokens every time the customer uses a store, the non-fungible tokens become the unique value of the customer, which indicates the customer's contribution to society and the customer's contribution to the token issuer.

[0120] Furthermore, a non-fungible token issuer can issue a non-fungible token carrying a membership card and a membership number, and create a system in which consumption data of a customer who holds a non-fungible token is updated on the blockchain 500 of the network 501. Therefore, those who wish to hold a non-fungible token and those who are interested in a non-fungible token can freely access the trading market for the non-fungible token. Furthermore, a non-fungible token becomes a unique digital asset held by a customer, that is, a consumer.

[0121] Furthermore, since the supply of non-fungible tokens is made visible on the blockchain 500, they become a more premium digital asset for the customers of the token issuer. This allows customers who use the token issuer's services to receive rewards from the token issuer and special services by using the services more. Furthermore, token issuers can use membership cards with non-fungible tokens, which have premium value, to build deeper relationships with customers with high membership ranks (status), such as loyal customers. Furthermore, as Web3-based services rapidly accelerate, blockchain technology can be used to stimulate consumption in real society and to help token issuers solve marketing issues.

[0122] <Supplementary explanation> The present disclosure is not limited to the embodiment, and it goes without saying that various modifications are possible within the scope of the present disclosure. For example, the store terminal 300 may be used by either an affiliated store (registered person) that receives an application from the management server 200, or a non-affiliated store (non-registered person). The determination 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. As a prerequisite, the payment application or credit card used by the user for payment to use the service of the service provider must be affiliated with the token issuer that is the operator of the management server 200. When the user makes a payment for using the service, the usage information of the service is sent to the management server 200 via the network 501. The rewrite request unit 508 can generate a request to rewrite information included in the non-fungible token registered in the blockchain 500 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.

[0123] The stores described with reference to Figs. 1 to 19 are examples of service providers, and service providers in the present disclosure include sports teams, local governments, etc. The sports teams may be any of soccer teams, basketball teams, baseball teams, etc. Services provided by sports teams include sports and practice instruction, sale and rental of equipment used in sports, rental of playing fields, etc. The local governments are prefectures, cities, towns, villages, etc., and services provided by local governments include resident and family registry affairs, pension and insurance affairs, nursing care services, waste disposal services, firefighting services, etc.

[0124] If the service provider is a sports team, the service provider information includes information on all services provided by the sports team. If the service provider is a local government, the service provider information includes all services provided by the local government. The usage information includes payment by synchro points, use of a web service that obtains information by linking customer IDs, payment when using a product delivery system, etc. The above service providers can be replaced with the service providers described with reference to Figures 1 to 19. In addition, the services provided by the above service providers can be replaced with the services described with reference to Figures 1 to 19.

[0125] Furthermore, when a local government issues a non-fungible token, the management server 200 may issue an instruction to rewrite the non-fungible token recorded in the blockchain 500 based on the usage information of a user using a store in the local government. Furthermore, the issuer of the non-fungible token is not limited to the operator of the management server 200, but may be a store, a local government, a sports team, a web service provider, etc. That is, a store can issue a request for issuing a non-fungible token to the network 501 using the store terminal 300. Furthermore, a local government can issue a request for issuing a non-fungible token to the network 501 using a dedicated terminal. Furthermore, a sports team can issue a request for issuing a non-fungible token to the network 501 using a dedicated terminal. A web service provider can issue a request for issuing a non-fungible token to the network 501 using a dedicated terminal.

[0126] As described above, a custody device 509 is provided that acquires non-fungible tokens and receives non-fungible tokens from holders who have a private key used for the security of the blockchain 500, and is managed by a custodian who does not have the private key. For this reason, although not shown in FIG. 19, the custody device 509 in FIG. 1 may generate a request to rewrite a 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.

[0127] 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. Also, a part of the configuration of each embodiment may be added, deleted, or replaced with another configuration. For example, the reward granting device and reward granting method disclosed herein are applicable even in stores that do not have passcodes. Therefore, in stores that do not have passcodes, the operations, processes, judgments, etc. related to passcodes described in the present disclosure are omitted.

[0128] Furthermore, each of the above configurations, functions, and processing units may be realized in part or in whole by hardware (for example, an integrated circuit), a module, or a unit. Also, each of the above configurations, functions, and processing units may be realized by software by a processor interpreting and executing a program that realizes each function. Information such as a program, table, and file that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD. The storage unit 256 may be either one built into the management server 200 or one connected to the management server 200 by wire or wirelessly. The storage unit 57 may be either one built into the store terminal 300 or one externally attached to the store terminal 300. The non-fungible token management device may be a management server, or may be one called a workstation, a host computer, or a mainframe.

[0129] The present embodiment also discloses the following non-fungible token management system: A non-fungible token management system having a user terminal, a service provider terminal, and a management server connected to each other via a network, the non-fungible token management system including service user information related to a service provider who provides a service to a user and usage information indicating that the user has used the service, the non-fungible token management system including an issuing unit that issues a non-fungible token including service user information related to a service provider who provides a service to a user and usage information indicating that the user has used the service, in a blockchain formed by a computer connected to the network, a non-fungible token granting unit that grants the non-fungible token issued in the blockchain to an acquirer, and a rewriting unit that rewrites information included in the non-fungible token issued in the blockchain before it is granted to the acquirer, based on the usage information of the user included in the acquirer.

[0130] The present embodiment also discloses the following information processing program. For example, a non-fungible token management program is disclosed that causes a non-fungible token management device that generates a request for a blockchain formed by a computer connected to a network to function as an issuance request means that generates a request to issue a non-fungible token in the blockchain, including service provider information of a service provider that provides a service to a user and information on the use of the service by the user, a non-fungible token granting means that generates a request to grant the non-fungible token issued in the blockchain to an acquirer, and a rewrite requesting means that generates a request to rewrite information included in the non-fungible token issued in the blockchain based on the use information by the user included in the acquirer. Step S603 in FIG. 19 is an example of an issuance requesting means and a granting requesting means, and step S606 is an example of a rewrite requesting means. A customer as a user of a store, a user who receives a service from a service provider, a person who wishes to purchase a non-fungible token, and an acquirer who acquires a non-fungible token free of charge are examples of acquirers. [Industrial Applicability]

[0131] The present disclosure can be used as a non-fungible token management device that can register non-fungible tokens on a blockchain and update information contained in non-fungible tokens registered on the blockchain. [Explanation of symbols]

[0132] 50...control unit, 82...reward granting unit, 85...determination unit, 200...management server, 500...blockchain, 501...network, 506...issuance request unit, 507...grant request unit, 508...rewrite request unit, 509...custody device

Claims

1. an issuance request unit that generates a request to issue a non-fungible token, including service provider information of a service provider that provides a service to a user and information on the use of the service by the user, on a blockchain formed by a computer connected to the network in response to an issuance request from a token issuer that requests the issuance of the non-fungible token; An assignment request unit that generates a request to assign the non-fungible token issued on the blockchain to the user; A rewrite request unit that generates a request to rewrite information included in the non-fungible token issued by the blockchain based on the usage information by the user in response to transmission information from the user and / or the service provider; having A non-fungible token management device further comprising a control unit in which a token issuer that requests the issuance of a non-fungible token manages the services provided by the service provider to the user based on information contained in the non-fungible token registered on the blockchain.

2. 2. The non-fungible token management device according to claim 1, The rewrite request unit generates a request to rewrite information contained in the non-fungible token, or a request to rewrite information of a smart contract associated with the non-fungible token, based on the usage information.

3. 2. The non-fungible token management device according to claim 1, The control unit is a non-fungible token management device that grants to the user at least one of the rewards purchased from a reward trading market separate from the service provided by the service provider, or the rewards held by the token issuer, using the fees obtained by the token issuer from the service provider as a source of funds.

4. an issuance request unit that generates a request to issue a non-fungible token, including service provider information of a service provider that provides a service to a user and information on the use of the service by the user, on a blockchain formed by a computer connected to the network in response to an issuance request from a token issuer that requests the issuance of the non-fungible token; An assignment request unit that generates a request to assign the non-fungible token issued on the blockchain to the user; A rewrite 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 in response to transmission information from the user and / or the service provider; having The rewrite request unit generates a request to rewrite information included in the non-fungible token or a request to rewrite information of a smart contract associated with the non-fungible token based on the usage information; A non-fungible token management device, wherein the information contained in the non-fungible token for which the rewrite request unit requests to be rewritten, or the information of the smart contract for which the rewrite request unit requests to be rewritten, includes information indicating the degree of usage of the service calculated from one or more of the number of service providers used by the user, the amount settled at each store by the user by using the service, the average monthly payment amount by the user by using the service, the number of times the user has used the service, and the average number of times the user has used the service by the user by using the service.

5. an issuance request unit that generates a request to issue a non-fungible token, including service provider information of a service provider that provides a service to a user and information on the use of the service by the user, on a blockchain formed by a computer connected to the network in response to an issuance request from a token issuer that requests the issuance of the non-fungible token; An assignment request unit that generates a request to assign the non-fungible token issued on the blockchain to the user; A rewrite 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 in response to transmission information from the user and / or the service provider; having A depository device is further provided, which acquires the non-fungible token and deposits the non-fungible token from a holder who has a private key used for security of the blockchain, and is managed by a depository who does not have the private key; A non-fungible token management device in which the rewrite request unit or the depository device generates a request to rewrite the non-fungible token registered in the blockchain.

6. 3. The non-fungible token management device according to claim 1, A non-fungible token management device further provided with a specific service providing unit that provides a specific service to the user of the non-fungible token.

Images