Program, method and system

Abstract

To provide a sales system, program and method capable of securing high anonymity to easily secure safety of transaction.SOLUTION: In a sales system that has a function of issuing tokens, which serve as exchange tickets for some kind of product, in response to requests from users, a token management server executes the steps of: detecting the establishment of an issuance request of a non-fungible token that is used to exchange a product and records unique information, which can identify an issuer and an exchangeable product; issuing the non-fungible token in response to the detected issuance request; and granting the issued token to the user related to the issuance request.SELECTED DRAWING: Figure 10

Description

Technical Field

[0001] The present disclosure relates to programs, methods, and systems.

Background Art

[0002] Regarding the provision of various products or services, reservations are widely made via communication means. For example, Patent Document 1 discloses a process of issuing a reservation voucher that proves a reservation based on a reservation of travel products including transportation means and accommodation facilities input by a user from a terminal device. In this system, reservations for a plurality of transportation means and accommodation facilities included in travel products can be made individually in one operation.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the system described in Patent Document 1, when the business operator providing the transportation means or accommodation facility and the business operator arranging the travel are different, it is necessary for both to share the customer information of the user. Customer information includes information that requires particular care in handling, such as an individual's name and address, as well as bank account information. Therefore, in the sales system constructed between the business operator arranging the reservation and the business operator actually providing the product or service, a certain amount of effort is required for managing customer information in order to ensure the security of transactions.

[0005] An object of the present disclosure is to provide a sales system that can easily ensure the security of transactions by guaranteeing high anonymity. [Means for solving the problem]

[0006] A program in one aspect of the present disclosure causes a computer processor to perform the following steps: detect the success of an issuance request for a non-fungible token, which is used for the exchange of goods and on which unique information is recorded that identifies the issuer and the goods that can be exchanged; and issue a non-fungible token in response to the detected issuance request and grant it to the user who made the issuance request. [Brief explanation of the drawing]

[0007] [Figure 1] This is a block diagram showing the configuration of the information processing system according to the first embodiment. [Figure 2] This is a block diagram showing the configuration of a user terminal according to the first embodiment. [Figure 3] This is a block diagram showing the configuration of the token management server according to the first embodiment. [Figure 4] This is a block diagram showing the configuration of the product exchange server according to the first embodiment. [Figure 5] This is a diagram showing the configuration of the distributed ledger system according to the first embodiment. [Figure 6] This figure shows an example of the data structure of a distributed ledger managed by the distributed ledger system according to the first embodiment. [Figure 7] This is an explanatory diagram of one embodiment according to the first embodiment. [Figure 8] This diagram illustrates a typical example of the relationship between the issuer and the redeemer in this disclosure. [Figure 9] This figure shows an example of the data structure in each database according to the first embodiment. [Figure 10] This is a flowchart of the token issuance process according to the first embodiment. [Figure 11] This is a flowchart of the exchange process for merchandise according to the first embodiment. [Figure 12] This is a flowchart of a modified example of the exchange process for merchandise according to the first embodiment. [Figure 13]It is a flowchart of the payment process for the consideration of the exchange according to the first embodiment. [Figure 14] It is a block diagram showing the configuration of the information processing system according to the second embodiment. [Figure 15] It is a block diagram showing the configuration of the token confirmation server according to the second embodiment. [Figure 16] It is a diagram showing an example of the data structure of the distributed ledger according to the second embodiment. [Figure 17] It is a flowchart of the exchange process of commercial materials according to the second embodiment. [Figure 18] It is a block diagram showing the configuration of the information processing system according to the third embodiment.

Modes for Carrying Out the Invention

[0008] <First Embodiment> Hereinafter, the first embodiment of the present invention will be described in detail based on the drawings. In the drawings for explaining the embodiments, the same reference numerals are generally assigned to the same components, and the repeated explanations thereof are omitted.

[0009] (1) Configuration of the information processing system 1 The configuration of the information processing system 1 (hereinafter simply referred to as the system 1) according to the present embodiment will be described. FIG. 1 is a block diagram showing the configuration of the system 1 according to the first embodiment.

[0010] As shown in FIG. 1, the system 1 includes a user terminal 10, a token management server 20, a commercial material exchange server 30, and a distributed ledger system 50. The user terminal 10, the token management server 20, the commercial material exchange server 30, and the distributed ledger system 50 are connected via a network (for example, the Internet) NW.

[0011] The user terminal 10 is an example of an information processing device that sends requests to the token management server 20 and the merchandise exchange server 30. The user terminal 10 is, for example, a smartphone, a tablet terminal, or a personal computer. Note that the user terminal may include the following terminals. · IoT device · Wearable device (a terminal worn on the user's body and used, such as smart glasses, smart watches, smart speakers, head-mounted goggles, smart home appliances, smart wear, smart wigs, etc.) · Implantable device (a terminal built into the user's body and used, such as nanobots, smart eyes, smart contact lenses, etc.)

[0012] The token management server 20 is an example of an information processing device. The token management server 20 provides a response corresponding to the request sent from the user terminal 10 to the user terminal 10. The token management server 20 provides a response corresponding to the request sent from the merchandise exchange server 30 to the merchandise exchange server 30. The token management server 20 is, for example, a web server. The token management server 20 is communicatively connected to the terminal used by the issuer described later.

[0013] The merchandise exchange server 30 is an example of an information processing device. The merchandise exchange server 30 provides a response corresponding to the request sent from the user terminal 10 to the user terminal 10. The merchandise exchange server 30 provides a response corresponding to the request sent from the token management server 20 to the token management server 20. The merchandise exchange server 30 is, for example, a web server. The merchandise exchange server 30 is communicatively connected to the terminal used by the exchanger described later.

[0014] The distributed ledger system 50 manages the distributed ledger in response to requests from the user terminal 10, the token management server 20, or the merchandise exchange server 30.

[0015] (1-1) Configuration of the user terminal 10 The configuration of the user terminal 10 will now be described. Figure 2 is a block diagram showing the configuration of the user terminal 10 according to the first embodiment.

[0016] As shown in Figure 2, the user terminal 10 comprises a storage device 11, a processor 12, an input / output interface 13, and a communication interface 14. The user terminal 10 is connected to a display 15.

[0017] The storage device 11 is configured to store programs and data. The storage device 11 is, for example, a combination of ROM (Read Only Memory), RAM (Random Access Memory), and storage (e.g., flash memory or hard disk).

[0018] The program includes, for example, the following: • OS (Operating System) programs • Programs for applications that perform information processing (e.g., web browsers)

[0019] The data includes, for example, the following: • Databases referenced in information processing • Data obtained by performing information processing (i.e., the results of performing information processing)

[0020] The processor 12 is a computer that realizes the functions of the user terminal 10 by launching programs stored in the storage device 11. The processor 12 is, for example, at least one of the following: ·CPU(Central Processing Unit) ·GPU(Graphic Processing Unit) ·ASIC(Application Specific Integrated Circuit) ·FPGA(Field Programmable Array)

[0021] The input / output interface 13 is configured to acquire information (e.g., user instructions) from an input device connected to the user terminal 10 and to output information (e.g., an image) to an output device connected to the user terminal 10. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. The output devices are, for example, a display 15, a speaker, or a combination thereof.

[0022] The communication interface 14 is configured to control communication between the user terminal 10 and an external device (for example, a token management server 20, a product exchange server 30, or a distributed ledger system 50).

[0023] The display 15 is configured to display images (still images or moving images). The display 15 is, for example, a liquid crystal display or an organic EL display.

[0024] (1-2) Configuration of Token Management Server 20 The configuration of the token management server 20 will now be described. Figure 3 is a block diagram showing the configuration of the token management server 20 according to the first embodiment.

[0025] As shown in Figure 3, the token management server 20 includes a storage device 21, a processor 22, an input / output interface 23, and a communication interface 24.

[0026] The storage device 21 is configured to store programs and data. The storage device 21 is, for example, a combination of ROM, RAM, and storage (e.g., flash memory or hard disk).

[0027] The program includes, for example, the following: • OS programs • Programs for applications that perform information processing.

[0028] The data includes, for example, the following: • Databases referenced in information processing • Results of information processing

[0029] The processor 22 is a computer that implements the functions of the token management server 20 by launching programs stored in the memory device 21. The processor 22 is, for example, at least one of the following: ·CPU GPU ASIC •FPGA

[0030] The input / output interface 23 is configured to acquire information (user instructions) from an input device connected to the token management server 20 and to output information (e.g., an image) to an output device connected to the token management server 20. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. Output devices include, for example, displays, speakers, or a combination thereof.

[0031] The communication interface 24 is configured to control communication between the token management server 20 and external devices (for example, the user terminal 10, the product exchange server 30, and the distributed ledger system 50).

[0032] (1-3) Configuration of the product exchange server 30 The configuration of the product exchange server 30 will now be described. Figure 4 is a block diagram showing the configuration of the product exchange server 30 according to the first embodiment.

[0033] As shown in Figure 4, the product exchange server 30 includes a storage device 31, a processor 32, an input / output interface 33, and a communication interface 34.

[0034] The storage device 31 is configured to store programs and data. The storage device 31 is, for example, a combination of ROM, RAM, and storage (e.g., flash memory or hard disk).

[0035] The program includes, for example, the following: • OS programs • Programs for applications that perform information processing.

[0036] The data includes, for example, the following: • Databases referenced in information processing • Results of information processing

[0037] The processor 32 is a computer that realizes the functions of the product exchange server 30 by launching programs stored in the storage device 31. The processor 32 is, for example, at least one of the following: ·CPU GPU ASIC •FPGA

[0038] The input / output interface 33 is configured to acquire information (user instructions) from an input device connected to the product exchange server 30 and to output information (for example, an image) to an output device connected to the product exchange server 30. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. Output devices include, for example, displays, speakers, or a combination thereof.

[0039] The communication interface 34 is configured to control communication between the product exchange server 30 and external devices (for example, a user terminal 10, a token management server 20, or a distributed ledger system 50).

[0040] (1-4) Configuration of the distributed ledger system 50 The configuration of the distributed ledger system 50 will now be described. Figure 5 is a diagram showing the configuration of the distributed ledger system 50 according to the first embodiment.

[0041] As shown in Figure 5, the distributed ledger system 50 comprises multiple node computers 55-1 to 55-4.

[0042] The node computers 55 are connected to each other via a network (which may include the network NW in Figure 1). In this embodiment, the network may include a public network, a private network, a dedicated line, a VPN (Virtual Private Network), or a combination thereof. The node computers 55 are connected to the network, for example, by wire or wireless. The node computers 55 communicate with each other in a peer-to-peer manner.

[0043] Node computer 55 manages a distributed ledger using, for example, blockchain technology. Specifically, one of the node computers 55 acquires data related to the token transactions to be recorded. Node computer 55 creates a block containing the acquired data and adds it to the blockchain. Node computer 55 sends the information of the added block to other node computers 55. Other node computers 55 verify the correctness of the received block, and if the verification is successful, add the block to the blockchain. Node computer 55 then finalizes the blockchain, for example, according to the number of linked blocks (number of confirmations). This ensures that the same distributed ledger is stored across multiple node computers 55 that constitute the distributed ledger system 50. The stored data is encrypted as appropriate.

[0044] The configuration of the distributed ledger system 50 is not limited to that shown in Figure 5. For example, the distributed ledger system 50 may have five or more node computers 55, or it may have two or three node computers 55. Also, the number of node computers 55 constituting the distributed ledger system 50 may change over time.

[0045] The hardware configuration of the node computer 55 may be the same as or similar to that of any of the terminals or servers described above, so a detailed explanation is omitted. As an example, the node computer 55 includes a processor, storage device, input / output interface, communication interface, input device, output device, or a combination thereof.

[0046] Figure 6 illustrates the data structure of a distributed ledger managed by the distributed ledger system 50. Figure 6 shows an example of the data structure of a distributed ledger. As shown in Figure 6, the distributed ledger system 50 is associated with digital content (e.g., ticket image) via the token database 212 recorded in the token management server 20. Note that the digital content may be stored on an external server instead of the token management server 20. Tokens have their owner information recorded in a distributed ledger, where transaction history is recorded as transaction data. By referring to the distributed ledger, the transaction history of the tokens can be tracked.

[0047] A blockchain consists of blocks that make up contract data, and blocks that contain at least hash values ​​and transaction data. When tokens are transferred between users, new transaction data is generated, and after verification by multiple node computers 55-1 to 55-4 as shown in Figure 5, a new block is added. Furthermore, the distributed ledger, which is a blockchain, may utilize both a public and a private blockchain. In this case, the transaction history of a normal transaction may be recorded on the private blockchain, and the latest information may be periodically reflected on the public blockchain. In other words, the distributed ledger may have a multi-layered structure.

[0048] (2) Outline of the Embodiment An overview of the first embodiment will now be described. Figure 7 is an explanatory diagram of one aspect of the first embodiment.

[0049] (2-1) One embodiment As shown in Figure 7, System 1 is a sales system that has the function of issuing tokens, which serve as vouchers for some kind of product, upon request from a user. Furthermore, System 1 is a sales system that has the function of authorizing the exchanger to provide the goods when the token is transferred from the user to the exchanger.

[0050] In System 1, "merchandise" is a broad concept encompassing goods and services that are the subject of trade, regardless of whether they are tangible or intangible. Merchandise also includes various perks, novelty goods, and commemorative items (hereinafter referred to as "perks") that are not independently the subject of trade. Furthermore, merchandise is not limited to movable property but also includes immovable property. In other words, the goods handled by System 1 refer to the items of commercial transactions that can be obtained by a user, who is a demander, upon fulfilling certain conditions, including payment of fees. Furthermore, tokens may be exchanged for the goods multiple times as a ticket.

[0051] Examples of products include the following: • Various goods (including food and beverages, pharmaceuticals, etc.) sold in physical stores or on e-commerce sites, etc. • Various chemical products, pharmaceuticals, machinery and equipment, materials, and other goods primarily traded between companies. • Real estate such as land and buildings • Digital content such as music, videos, and comics that can be downloaded upon purchase. • Tickets to participate in various events • Tickets for various modes of transportation, accommodation, and tourist facilities (amusement parks, museums, zoos, etc.) • Betting tickets for public gambling • Various types of benefits (including goods, digital content, tickets, and coupons) • Gift certificates (gift cards, merchandise vouchers) that can be used at specific stores. • Securities (stocks, bonds, bills of exchange, checks, etc.) • Various documents such as contracts and certificates Please note that the above is merely an example, and the products include other items as well. Furthermore, invoices, accounts receivable, or accounts payable arising in the course of transactions may also be subject to exchange with tokens.

[0052] Examples of products offered as services include the following: • Provision of food, beverages, and accommodation. • Repair, restoration, cleaning, improvement, processing, and construction of various items. • Various services including education, instruction, training, certification, and consultation. • Services related to medical care, beauty treatments, chiropractic care, massage, nursing care, and welfare. • Various information processing, including viewing and playing digital content provided by electromagnetic means. • Development of various software • Provision of various infrastructure (including public works) • Temporary rental of various tools, equipment (including vehicles), and facilities. • Transportation and travel arrangements • Services related to weddings, funerals, security, and legal matters. Please note that the above is merely an example, and the products include other services as well.

[0053] In System 1, the issuer refers to the entity that issues tokens. Issuers include individuals, corporations, associations, other organizations, and consortia formed for a specific purpose. The issuer can be a private or public organization.

[0054] Issuers include, for example, the following: • Persons who handle specific goods or services • A group of corporations that handle specific goods or services (e.g., XX Prefecture Wine Association, XX Prefecture Public Bath Association) • Persons who have the authority to issue vouchers that can be used for specific goods or services. • Persons who have the authority to issue vouchers that can be used for unspecified goods and services. Please note that the above is merely an example, and the term "issuer" includes all entities that issue tokens, which are redeemable vouchers.

[0055] In System 1, a redeemer refers to an entity that exchanges tokens for merchandise and receives tokens from users, thereby providing the users with the merchandise to which the tokens are applied. Redeemers include individuals, corporations, cooperatives, other organizations, and consortia formed for a specific purpose. The issuer can be a private or public organization.

[0056] Those who can redeem the item include, for example, the following: • A person who produces goods or provides services that he or she produces. • Those who provide goods or services produced by others (e.g., retailers, wholesalers) • A person who arranges the provision of specific goods or services (e.g., an agent). • A person who acts as an intermediary in transactions for the provision of specific goods or services (e.g., a brokerage business) Please note that the above is merely an example, and the term "exchanger" includes all entities that exchange tokens (which are redemption vouchers) for merchandise and provide them to users.

[0057] Figure 8 illustrates a typical example of the relationship between the issuer and the redeemer in this disclosure. In example (1) in the upper part of Figure 8, the issuer and the redeemer are different entities. In this case, the relationship between the issuer and the redeemer is as follows: • Issuer: For example, a general retailer such as a department store that has the right to issue tokens as exchange vouchers. • Exchange recipient: For example, a business cooperative for a specific product, such as the Nationwide XX Association. • Members of the exchange organization: Businesses such as individual stores belonging to the joint organization (those who actually accept the exchange) In this case, an arrangement (contract) regarding the issuance of tokens is made between the general retailer and the business cooperative, and payment terms such as the amount of consideration for exchange and the method of payment are set in the contract. In this case, the payment terms in the contract may apply to all members of the exchange.

[0058] On the other hand, in example (2) in the lower diagram of Figure 8, the issuer's members are the redeemers. In this case, the relationship between the issuer and the redeemers is as follows: • Publisher: For example, a business cooperative for a specific product, such as the Nationwide XX Association. • Redeemer: For example, businesses such as individual stores belonging to a joint organization (those who actually accept the redemption) In this case, an agreement (contract) regarding token issuance is made between the business cooperative and the businesses that are its members. In this case, the payment terms in each contract may be provided to each business.

[0059] Thus, the relationship between issuer and redeemer in this disclosure is not limited to these examples and can be changed at will. For example, multiple issuers and redeemers may be set for a single token. In other words, any business entity can use System 1 as either an issuer or a redeemer in any commercial transaction.

[0060] Specifically, the relationship between issuer and redeemer in this disclosure includes the following examples: • Company A (the exchanger) has another company (the issuer) sell and issue tokens that it can use in its own operations, and when a purchasing user presents the token to Company A, they can exchange it for a service (similar to a gift card at a specific department store). • Company A (the exchanger, issuer) sells and issues tokens that it can use in its own operations and distributes the tokens to purchasing users. When a purchasing user presents the token to Company B (the exchange agent), with whom Company A has a service provision outsourcing contract, they can exchange it for a service (similar to a ticket agency outsourcing ticket issuance operations to a ticket issuing company). • Cooperative A circulates tokens that can be used at each company belonging to Cooperative A, and when a purchasing user presents the token to each company belonging to Cooperative A, they can exchange it for a service (similar to a book card or rice voucher). • Cooperative A sets up tokens that each company belonging to Cooperative A can issue and use. Any company belonging to Cooperative A can sell and issue tokens. Purchasers can exchange their tokens for services at any company belonging to Association A by presenting the token (for example, imagine a scenario where member companies sell and issue rice vouchers without prior permission and then settle the accounts later). In this case, the member company of Association A that issued the token pays a predetermined membership fee to Association A. Association A then uses this as the source of funds to pay the member company that provided the service.

[0061] Here, a token refers to data with asset value that is granted to users who have the right to receive various goods and services through purchase or other means. In this embodiment, the tokens have their owners recorded in a distributed ledger managed by the distributed ledger system 50, and information about who has the right to receive the goods in question is clearly defined. Generally, tokens include fungible tokens and non-fungible tokens.

[0062] Tokens with fungibility refer to data that is treated as an asset equivalent to money, such as cryptocurrencies or points. Non-fungible tokens include, for example, digital content data such as text data commented on a social networking service (SNS), or address information (such as a URL) indicating the address where such data is stored. In this case, the data related to the digital content itself can be copied at will by a third party. On the other hand, even if the original text data on the SNS is copied and reused, the owner can be clearly identified because the owner's information is recorded.

[0063] The digital content included in the token may include, for example, digital images related to the product (including the image of the voucher), digital videos, and digital audio. The image of the voucher may display various information such as the name of the product to be redeemed, owner information, information about the redeemer, information that allows access to the redemption method, and the redemption deadline. However, the image of the voucher that displays at least some of the contents of such a token may be omitted. Digital content linked to tokens in this way is stored, for example, in a token management server 20 that manages digital content. Note that the data of the digital content may be stored on an external server. In this invention, we will explain using a configuration in which non-fungible tokens are used as tokens as an example.

[0064] In System 1, tokens are issued when a user pays a predetermined sales price to the issuer for the issuance of tokens that lead to the purchase of goods, for example. In this process, the token management server 20 issues and grants tokens to the user. Specifically, it grants tokens to the user's wallet, which is managed on the user terminal 10.

[0065] Furthermore, as shown in the lower part of Figure 7, users can receive the target merchandise by exchanging tokens for the merchandise. Transferring the tokens to the exchanger is a condition for the exchange regarding the provision of merchandise. Specifically, the user operates the user terminal 10 to transfer the tokens attached to the wallet to the merchandise exchange server 30 used by the exchanger. After the merchandise exchange server 30 verifies the authenticity of the tokens, if there are no problems, the merchandise exchange server 30 outputs a notification to the exchanger authorizing the exchange of merchandise. Furthermore, the exchange of goods does not necessarily require the transfer of exchange tokens. If an application for exchange is made based on the use of tokens and the authenticity of those tokens is confirmed, the exchange of goods may be permitted.

[0066] In the exchange of merchandise, as shown in the diagram, the exchanger may provide a physical item (a penlight in this example) at the store, or an item usable in a virtual space (a virtual penlight in this example) may be provided to the user terminal 10. Furthermore, the exchange of merchandise is not limited to transactions at a store. For example, by transferring a token to the exchanger on an e-commerce site operated by the exchanger, the user can receive the corresponding item shipped to their home. Alternatively, by transferring a token to the exchanger on an entertainment site that provides various types of digital content related to entertainment, the user can receive the distribution and rights to the digital content corresponding to the merchandise.

[0067] Furthermore, the token of the present invention may, instead of functioning as an exchange voucher used in exchange for specific merchandise as described above, or in conjunction with such function, also function as a discount voucher that applies a discount to the purchase of specific merchandise, such as various coupons. In this case, the extent of the discount applied may be such that the entire amount written on the token is discounted when purchasing the specific merchandise. Alternatively, the extent of the discount applied may be such that the discount is applied to an amount specified by the user when purchasing the specific merchandise, from the remaining discountable amount held by the token. In addition, the merchandise subject to the discount may be a group of merchandise included in a specific category (for example, books in general, alcoholic beverages in general, etc.).

[0068] Furthermore, tokens may be traded on a system that exists outside the distributed ledger system 50 (for example, sometimes called a private chain or second layer). In this case, the trading of virtual items can be carried out using information that identifies the system on which the virtual items held by the user are actually being traded, and the customer's wallet information on that system.

[0069] (3) Database The databases according to the first embodiment will be described below.

[0070] (3-1) Product Database 311 The product database (DB) 311 according to the first embodiment will now be described. Figure 9A shows the data structure of the product DB 311 according to the first embodiment. The product DB 311 is stored in the storage device 31 of the product exchange server 30.

[0071] Product DB311 is a database that stores and manages information about products that can be redeemed using tokens. Product DB311 stores information about various products handled by the redeemer. When a new product is set up by the redeemer, a new record is recorded in Product DB311. Product DB311 includes the fields "Product ID", "Type", "Item", "Name", "Sales Unit", and "Sales Price". Note that the data fields included in Product DB311 can be changed as desired.

[0072] The "Product ID" field stores identification information for identifying a product. The Product ID is a unique value assigned to each product. The Product ID may also be unique for each sales unit.

[0073] The "Type" field stores the category of the product corresponding to the product ID. The product category is a field that stores the category (type) set based on the characteristics, use, and function of the product. Examples of product types include "books," "alcoholic beverages," "clothing," "bonus items," "food and beverages," and "digital content." The category can be set arbitrarily.

[0074] The "Item" field stores the general name of the item corresponding to the item ID. General names for items include "rice," "beer," "cap," "towel," "autographed memorabilia," "beverage," "live video," "discount," "points," and "currency unit."

[0075] The "Name" field stores the "name" of the product corresponding to the product ID. The name includes the product model number, product series name, and product's unique name, as assigned by each manufacturer.

[0076] The "Sales Unit" field stores the quantity per sales unit for the product corresponding to the product ID. For example, the sales unit may include the quantity equivalent to the sales unit, or the mass equivalent to the sales unit.

[0077] The "Sales Price" field stores the sales price for each unit of sale of the product corresponding to the product ID.

[0078] (3-2) Token Master Database 211 The token master database (DB) 211 according to the first embodiment will now be described. Figure 9B shows the data structure of the token master DB 211 according to the first embodiment. The token master DB 211 is stored in the storage device 21 of the token management server 20.

[0079] The Token Master DB211 is a database that stores information about the contents of each type of token. When a new token type is set up, a new record is recorded in the Token Master DB211. The Token Master DB211 stores information set up based on the agreement (contract) between the issuer and the redeemer regarding the issuance of tokens. Token Master DB211 includes the fields "Token Type ID", "Redeemer Information", "Name", "Product ID", "Redemption Method", and "Payment Terms". Note that the data fields included in Token Master DB211 can be changed as needed.

[0080] The "Token Type ID" field stores identification information to distinguish each type of token. Each token type has a unique value assigned to its Token Type ID.

[0081] The "Redeemer Information" field stores information about the issuer who has the right to issue tokens of the type corresponding to the token type ID. As mentioned above, the redeemer may be an organization or multiple individuals.

[0082] The "Name" field stores information about the name of the voucher, which allows you to understand what can be redeemed with the token of the type corresponding to the token type ID.

[0083] The "Product ID" field stores the identification information of the product that can be redeemed with the token corresponding to the token type ID.

[0084] The "Redemption Method" field stores information about how users who own tokens can redeem them.

[0085] The "Payment Terms" field stores information agreed upon between the issuer and the redeemer regarding the payment of consideration for the exchange of the token corresponding to the token ID and the goods, including the amount of consideration and the method of payment to the redeemer.

[0086] Furthermore, the data items managed in the token master DB211 may include, for example, issuer information. Issuer information may include, for example, the name of the organization that has the right to issue tokens.

[0087] (3-3) Token Database 212 The token database (DB) 212 according to the first embodiment will now be described. Figure 9C shows the data structure of the token DB 212 according to the first embodiment. The token DB 212 is stored in the storage device 21 of the token management server 20.

[0088] Token DB212 is a database that stores and manages unique information about tokens that serve as vouchers for merchandise. When a new token is issued, a new record is created in Token DB212. Token DB212 includes the following fields: "Token ID", "Token Type ID", "Issuance Date and Time", "Status", "Ledger ID", and "Digital Content Address". Note that the data fields included in Token DB212 can be modified as needed.

[0089] The "Token ID" field stores identification information used to identify a token. Each token has a unique Token ID.

[0090] The "Token Type ID" field stores the token type ID, which indicates the type of token corresponding to the token ID. The token type ID links the token ID with information set based on the agreement between the issuer and the redeemer regarding the issuance of the token.

[0091] The "Issuance Date and Time" field stores the date and time when the token corresponding to the token ID was issued.

[0092] The "Status" field stores the status of the product corresponding to the product ID. The possible product statuses are "Before Redemption," "Before Settlement," and "Settlement Completed." A status of "For Sale" means that the product in question has not yet been purchased. A status of "Pre-redemption" means that the product in question has been purchased but has not yet been redeemed. A status of "Pending Settlement" means that the product in question has already been sold, but payment for the exchange has not yet been made to the redeemer. A status of "Cleared" means that payment for the exchange of the product has been made to the redeemer, and the series of transactions related to that product has been completed.

[0093] By managing the "Status" field, it becomes possible to set the token corresponding to the token ID as usable only once. Note that information regarding the "Status" field does not necessarily need to be managed. If the "Status" field is not managed, the token corresponding to the token ID can be set as usable repeatedly by circulating it again. Even without managing the "Status" field, transactions occur in accordance with token transfers, so duplicate use of tokens will not occur.

[0094] The "Ledger ID" field stores identification information for a distributed ledger that stores information about the owner of the token corresponding to the token ID.

[0095] The "Owner ID" field stores information about the owner of the token corresponding to the token ID. Note that this field may be omitted as the token owner's information is recorded in the distributed ledger.

[0096] The item "Digital Content Address" stores address information in the token management server 20 where the digital content associated with the token corresponding to the token ID is stored. Examples of digital content include a ticket image displaying at least the following: • Token ID • Products eligible for exchange ·quantity ·status • Redemption method

[0097] (4) Information processing Information processing according to the first embodiment will be described.

[0098] (4-1) Token issuance process The token issuance process according to the first embodiment will now be described. Figure 10 is a flowchart of the token issuance process in System 1.

[0099] The token issuance process shown in Figure 10 can be initiated, for example, upon request from a user. The token issuance process takes place, for example, when a user visits a service site for issuing tokens (hereinafter referred to as the token issuance site) by operating the user terminal 10.

[0100] As shown in Figure 10, the user terminal 10 receives input from the user requesting the issuance of a token (step S101). Specifically, the user terminal 10 logs in to the token issuance site and displays the page related to the logged-in token issuance site on the display 15. The user terminal 10 receives the user's operation regarding the specification of the product for which the token issuance as an exchange voucher as a token issuance request. At this time, the user makes the payment for the costs required for token issuance. The user terminal 10 sends the received token issuance request to the token management server 20.

[0101] Following step S101, the token management server 20 receives a request to issue a token (step S201). Specifically, the token management server 20 receives a token issuance request sent from the user terminal 10.

[0102] After step S201, the token management server 20 detects that the token issuance request has been successful (step S202). Specifically, the token management server 20 checks the received token issuance request and verifies whether the token issuance request is valid. The token management server 20 checks, for example, the following: Refer to the token master DB211 and the product database 311 to check whether a token type has been set for the product included in the issuance request. • Verify that the fees required for token issuance have been paid. If any of this information cannot be verified, the process will terminate. On the other hand, once the above-mentioned items are confirmed, the successful execution of the token issuance request is detected.

[0103] After step S202, the token management server 20 issues a new token (step S203). Specifically, the token management server 20 creates a new record in the token database 212 based on the token issuance request. At this time, the token management server 20 stores the ID of the distributed ledger where the information of the token owner is registered in the "Ledger ID" field in the token database 212. The "Digital Content Address" field stores address information where the data for the digital content associated with the token is stored. Furthermore, the token management server 20 sets the "Status" field in the token DB 212 to "Before redemption".

[0104] After step S203, the token management server 20 instructs the granting of the issued tokens (step S204). Specifically, the token management server 20 instructs the distributed ledger system 50 to record information about the user who made the issuance request as the token owner on the blockchain corresponding to the ledger ID in the distributed ledger.

[0105] After step S204, the distributed ledger system 50 registers the user information as the token owner (step S501). Specifically, the distributed ledger system 50 registers information about the user (for example, the user's wallet information that identifies the user in the distributed ledger) in a new block added to the blockchain corresponding to the ledger ID. In addition, the distributed ledger in the distributed ledger system 50 where information about the token owner is recorded may be linked to another distributed ledger where information proving the user's identity is registered, or to a distributed ledger that verifies identity. This prevents resale that is not intended by the issuer.

[0106] After step S501, the distributed ledger system 50 notifies the granting of tokens (step S502). Specifically, the distributed ledger system 50 notifies the user that tokens have been added to their wallet.

[0107] After step S502, the user terminal 10 receives the token grant (step S102). Specifically, the user terminal 10 receives the token grant by acknowledging that the token has been granted to the wallet. With the above steps completed, the token issuance process is finished.

[0108] (4-2) Exchange of goods The exchange process for merchandise according to the first embodiment will now be described. Figure 11 is a flowchart of the exchange process for merchandise according to the first embodiment.

[0109] The product redemption process shown in Figure 11 can be initiated, for example, upon a user request. The product redemption process is carried out by the user exchanging a store or token for the product on the corresponding e-commerce site.

[0110] As shown in Figure 11, the user terminal 10 accepts the input of the redemption request (step S111). Specifically, the user enters a redemption request for the goods they wish to receive by exchanging tokens on the e-commerce site they are logged into using their user terminal 10. The user terminal 10 then sends the entered redemption request to the goods redemption server 30. The goods redemption request includes, for example, the following information: • Information identifying the user who wishes to redeem the item. • Information identifying the product you wish to exchange. • Information identifying the token used for the exchange

[0111] After step S111, the product exchange server 30 receives the exchange request (step S311). Specifically, the product exchange server 30 receives exchange requests sent from user terminals 10.

[0112] After step S311, the product exchange server 30 issues an instruction for token transfer (step S312). Specifically, the product exchange server 30 sends an instruction to the user terminal 10 to transfer a token that will serve as a voucher for the product to be exchanged.

[0113] After step S312, the user terminal 10 receives an instruction to transfer the token (step S112). Specifically, the user terminal 10 displays instructions for the transfer of the token received from the product exchange server 30 on the display 15 and presents them to the user.

[0114] After step S112, the user terminal 10 applies for the transfer of the token (step S113). Specifically, the user terminal 10 instructs the distributed ledger system 50 to transfer the token to the product exchange server 30 in response to user input. In other words, the user terminal 10 instructs the distributed ledger system 50 to change the information of the token owner recorded on the blockchain corresponding to the ledger ID from information about the user to information about the exchanger.

[0115] After step S113, the distributed ledger system 50 modifies or adds information about the token owner (step S511). Specifically, the distributed ledger system 50 changes or adds information about the owner of the token recorded on the blockchain corresponding to the ledger ID, from information about the user to information about the redeemer (for example, the redeemer's wallet information that identifies the redeemer in the distributed ledger).

[0116] After step S511, the distributed ledger system 50 notifies of any changes or additions to the token owner's information (step S512). Specifically, the distributed ledger system 50 notifies the exchanger that the token has been granted to their wallet.

[0117] After step S512, the product exchange server 30 receives the token transfer (step S313). Specifically, the product exchange server 30 receives the token grant by acknowledging that the token has been granted to the exchanger.

[0118] After step S313, the product exchange server 30 verifies the authenticity of the token (step S314). Specifically, the product exchange server 30 checks the token type from the token ID written on the token and verifies in the token master DB 211 whether it is registered as an exchanger of that token type. If the exchanger is an organization, it verifies whether the organization to which it belongs is registered as an exchanger. The authenticity of the token is verified by confirming that the user is registered as a redeemer. If the user is not registered as a redeemer of that token type, the token is deemed not authentic, and the redemption process is terminated. In other words, the product redemption server 30 verifies the authenticity of the token by checking the information recorded in the token master DB 211, which is set based on the agreement between the issuer and the redeemer regarding the issuance of the token. The token master DB 211 may also verify the authenticity of the token by checking other information linked to the token ID. Here, "other information" used to verify the authenticity of the token includes, for example, information about the original issuer of the token. Information about the original issuer of the token is recorded in the distributed ledger. Furthermore, the product exchange server 30 may verify the information regarding the token included in the token transfer application and confirm the identity of the product redeemable with the token with the product the user is requesting to redeem.

[0119] After step S314, the product exchange server 30 authorizes the provision of the product (step S315). Specifically, the product exchange server 30, for example, when exchanging products on an e-commerce site, authorizes the provision of the products and then arranges for the delivery of the relevant products to the user. Furthermore, the product exchange server 30, for example, when exchanging products on an entertainment site, authorizes the provision of the product and then delivers the relevant product to the user. Furthermore, if, for example, a product exchange takes place at a store, the staff member performing the exchange will be notified that they are authorized to provide the product. The product exchange server 30 notifies the user terminal 10 that it has authorized the provision of the product. Additionally, the product exchange server 30 changes the "Status" item in the token DB212 to "Pre-settlement".

[0120] After step S315, the user terminal 10 receives the merchandise (step S114). Specifically, the user terminal 10 receives a notification from the product exchange server 30 that it has been authorized to provide the product. The exchange process for the merchandise is now complete.

[0121] (4-3) Variations of the process for exchanging merchandise Next, we will explain a modified version of the product exchange process. Figure 12 is a flowchart of a modified version of the product exchange process. Note that Figure 12 omits the illustration of the processing of the distributed ledger system 50. Steps S111 to S112 are identical to the process in Figure 11, so their explanation will be omitted. In this modified version, the authenticity of the token is verified before the token is transferred.

[0122] In step S113, the application for token transfer is made to the product exchange server 30, unlike the process shown in Figure 11. That is, the product exchange server 30 receives information about the token included in the token transfer application.

[0123] After step S113, the product exchange server 30 verifies the authenticity of the token (step S316). Specifically, the product exchange server 30, for example, checks the information about the token included in the token transfer application and verifies the identity of the product redeemable with the token and the product the user is requesting to redeem. The product exchange server 30 may also verify the authenticity of the token using other information associated with the token (including issuer information and redeemer information), as shown in step S314 of Figure 11.

[0124] In step S316, if it is determined that the token is not authentic (No. in step S317), the product exchange server 30 notifies the user that the exchange cannot be completed (step S318). This completes the product exchange process.

[0125] On the other hand, if it is determined in step S316 that the token is authentic (No. in step S317), the product exchange server 30 applies to grant the token (step S319). Specifically, the product exchange server 30 requests the granting of tokens by sending the information included in the token transfer application entered by the user to the distributed ledger system 50. In other words, the product exchange server 30 instructs the distributed ledger system 50 to change the information of the token owner recorded on the blockchain corresponding to the ledger ID from information about the user to information about the exchanger.

[0126] Then, similar to steps S511 and S512 described above in Figure 11, the distributed ledger system 50 modifies or adds information about the token owner and notifies them accordingly. In other words, the distributed ledger system 50 notifies the exchanger that tokens have been granted to the exchanger's wallet.

[0127] After step S319, the product exchange server 30 receives the token transfer (step S320). Specifically, the product exchange server 30 receives the token grant by acknowledging that the token has been granted to the exchanger.

[0128] After step S320, the product exchange server 30 authorizes the provision of the product (step S321). Specifically, the product exchange server 30 authorizes the provision of the product in accordance with a pre-configured manner, similar to step S315 shown in Figure 11 above. The product exchange server 30 notifies the user terminal 10 that it has authorized the provision of the product. Additionally, the product exchange server 30 changes the "Status" item in the token DB212 to "Pre-settlement".

[0129] After step S321, the user terminal 10 receives the merchandise (step S114). Specifically, the user terminal 10 receives a notification from the product exchange server 30 that it has been authorized to provide the product. The exchange process for the merchandise is now complete.

[0130] As explained above, in the product redemption process of this modified example, the product redemption server 30 verifies the authenticity of the token before transferring it to the redeemer. Therefore, if the token is found to be invalid, not only will the provision of the product be denied, but the transaction of transferring the token from the user to the redeemer can be stopped altogether. This allows the redemption process to be stopped without generating transaction processing in the distributed ledger system 50 during the token transfer transaction, thereby ensuring the security of the transaction.

[0131] (4-4) Payment processing for the exchange The payment process for the consideration of the exchange according to the first embodiment will now be explained. Figure 13 is a flowchart of the payment process for the consideration of the exchange according to the first embodiment. The payment of the consideration of the exchange is the process by which the business that provided the goods (the exchanger) recovers from the token issuer the cost related to the sales price of the goods, which was received from the user for the purchase of the goods when the token was issued as an exchange voucher.

[0132] The payment process for exchanges shown in Figure 13 can be initiated, for example, upon request from the exchanger. The payment process for exchanges may also be carried out periodically, for example, by making a lump-sum payment at the end of the following month for exchange records closed at the end of the month.

[0133] As shown in Figure 13, the product exchange server 30 accepts input for payment request (step S231). Specifically, the product exchange server 30 accepts the input of a token ID as a payment request for the consideration entered by the exchanger. The product exchange server 30 sends the payment request for consideration, including the entered token ID, to the token management server 20.

[0134] Following step S231, the token management server 20 receives the application for payment of consideration (step S331). Specifically, the token management server 20 receives a payment request for consideration, which includes the token ID, sent from the product exchange server 30.

[0135] After step S331, the token management server 20 issues an instruction to hand over the token (step S332). Specifically, the token management server 20 sends an instruction to the product exchange server 30 to hand over the tokens included in the payment request.

[0136] Following step S332, the product exchange server 30 receives support for the delivery of the token (step S232). Specifically, the product exchange server 30 displays the instructions for transferring the token received from the token management server 20 on the display 15 and presents them to the user.

[0137] After step S232, the redeemer instructs the delivery of the token (step S233). Specifically, the exchanger instructs the distributed ledger system 50 to transfer the token to the token management server 20 in response to the exchanger's input. In other words, the product exchange server 30 instructs the distributed ledger system 50 to change the information of the token owner recorded on the blockchain corresponding to the ledger ID from information of the exchanger to information of the issuer.

[0138] After step S233, the distributed ledger system 50 modifies or adds information about the token owner (step S531). Specifically, the distributed ledger system 50 changes or adds information about the owner of the token recorded on the blockchain corresponding to the ledger ID, from information about the redeemer to information about the issuer (for example, the issuer's wallet information that identifies the issuer in the distributed ledger).

[0139] After step S531, the distributed ledger system 50 notifies of any changes or additions to the token owner's information (step S532). Specifically, the distributed ledger system 50 notifies the issuer that it has granted tokens to the issuer's wallet.

[0140] Following step S532, the token management server 20 receives the token delivery (step S333). Specifically, the token management server 20 receives notification from the issuer that the token has been granted, thereby receiving the token grant. This allows the token management server 20 to detect the transfer of the token from the exchange agent. The exchange agent refers to the entity that actually exchanged the token for the product (e.g., a store or other business).

[0141] After step S334, the token management server 20 refers to the payment terms and executes the payment in accordance with the payment terms (step S334). Specifically, the token management server 20 refers to the payment terms listed in the token master DB 211, which is associated with the token type ID, and executes payment to the redeemer for the consideration of the exchange. The token management server 20 then notifies the product exchange server 30 that the payment has been executed. Furthermore, the token management server 20 changes the "Status" field in the token DB 212 from "Pending Settlement" to "Settlement Completed". Note that this process can be omitted if the "Status" field is not to be managed.

[0142] After step S334, the product exchange server 30 receives notification of payment for the consideration (step S234). Specifically, the product exchange server 30 receives notification from the token management server 20 that it has executed the payment of the consideration. With the above steps completed, the payment process for the exchange is finished.

[0143] (5) Summary As explained above, in System 1, upon successful issuance of a token, a token that serves as a voucher for a product can be granted to the user. Because the token is non-fungible and the owner's information is registered, it can itself be the subject of commercial transactions as digital data with asset value. Therefore, even if the token voucher circulates among users, the ownership of the token remains clear. This eliminates the need to constantly update and share the owner's information of the token (which acts as a reservation voucher) between the issuer and the redeemer, reducing the effort required for managing personal information. Thus, according to System 1, the security of transactions can be easily ensured by guaranteeing a high level of anonymity.

[0144] Furthermore, once the token's authenticity is verified by the recipient of the token transfer, permission is granted to provide the goods exchangeable for the token to the user. This eliminates the need to share sensitive information, such as personal data, between the issuer and the recipient, reducing the effort required for managing personal information. This, in turn, ensures the security of transactions.

[0145] Furthermore, the unique information contained in the token is linked to information established based on the agreement for the issuance of fungible tokens. Therefore, a clear distinction is maintained between the entity that issued the token and the object to which the token is redeemed.

[0146] Furthermore, in the step of verifying the authenticity of the non-fungible token, the product exchange server 30 verifies the authenticity of the token by checking the information linked to the information set out based on the agreement regarding the issuance of fungible tokens. This prevents fraudulently issued tokens from being used to exchange for products.

[0147] Furthermore, the unique information includes the terms and conditions regarding the compensation paid by the issuer to the consignee who has been entrusted with the exchange of the goods from the user. This allows for the smooth payment of the compensation for the exchange, which is a transaction between the exchanger and the issuer.

[0148] Furthermore, in System 1, when the transfer of goods from the agent exchanging the goods to the issuer of the non-fungible token is detected, the agent is paid the exchange consideration according to the terms and conditions regarding the consideration for the exchange. This allows the exchanger to recover the costs related to the provision of the goods exchanged, from the costs received for issuing the token as an exchange voucher, thus complementing the token's function as an exchange voucher.

[0149] <Second Embodiment> Next, a third embodiment of the present invention will be described in detail with reference to the drawings. In the drawings used to illustrate the embodiments, the same reference numerals are generally used for identical components, and repeated descriptions of them will be omitted.

[0150] (6) Configuration of Information Processing System 2 The configuration of the information processing system 2 (hereinafter simply referred to as System 2) according to this embodiment will now be described. Figure 14 is a block diagram showing the configuration of the information processing system 2 according to the second embodiment.

[0151] As shown in Figure 14, System 2 includes a token verification server 60 in addition to the configuration of System 1 according to the first embodiment. That is, in this embodiment, a server for verifying the authenticity of tokens is provided separately from the product exchange server 30. The administrator of the token verification server 60 may be the exchanger, or a third party that provides a service to the exchanger guaranteeing the authenticity of the tokens.

[0152] The token verification server 60 is connected via the network NW to communicate with the user terminal 10, the token management server 20, the product exchange server 30, and the distributed ledger system 50. The configurations of the user terminal 10, token management server 20, product exchange server 30, and distributed ledger system 50 are identical to those of System 1, therefore their description is omitted. In System 2, the token verification server 60 implements a function to verify the authenticity of the token.

[0153] (7) Configuration of Token Verification Server 60 Next, the configuration of the token verification server 60 will be described. Figure 15 is a block diagram showing the configuration of the token verification server 60 according to the second embodiment.

[0154] As shown in Figure 15, the token verification server 60 includes a storage device 61, a processor 62, an input / output interface 63, and a communication interface 64.

[0155] The storage device 61 is configured to store programs and data. The storage device 61 is, for example, a combination of ROM, RAM, and storage (e.g., flash memory or hard disk).

[0156] The program includes, for example, the following: • OS programs • Programs for applications that perform information processing.

[0157] The data includes, for example, the following: • Databases referenced in information processing • Results of information processing

[0158] The processor 62 is a computer that implements the functions of the token verification server 60 by launching a program stored in the storage device 61. The processor 62 is, for example, at least one of the following: ·CPU GPU ASIC •FPGA

[0159] The input / output interface 63 is configured to acquire information (user instructions) from an input device connected to the token verification server 60 and to output information (e.g., an image) to an output device connected to the token verification server 60. Input devices include, for example, keyboards, pointing devices, touch panels, or combinations thereof. Output devices include, for example, displays, speakers, or a combination thereof.

[0160] The communication interface 64 is configured to control communication between the token verification server 60 and external devices (for example, the user terminal 10, the token management server 20, the product exchange server 30, and the distributed ledger system 50).

[0161] (8) Data structure of distributed ledgers Next, the data structure of the distributed ledger according to this embodiment will be described. Figure 16 is a diagram showing an example of the data structure of the distributed ledger according to the second embodiment. As shown in Figure 16, in the distributed ledger of System 2, various unique pieces of information associated with tokens are stored in the distributed ledger. The distributed ledger stores unique information linked to the token ID, which is associated with transaction information, which is the history of transactions. Examples of unique information linked to the token ID include the following: • Token ID… This is the identification information for the token and also functions as a ledger ID that identifies the blockchain. • Issuance date and time… The date and time the token was issued. • Issuer information… Information about the person who initially issued (minted) the token. • Exchangeable items… Information regarding the contents and quantity of the items eligible for exchange. • Redemption Method…Information on how to redeem your item. • Payment Terms… Information agreed upon regarding payment for the exchange of tokens for merchandise. • Digital content address: Address information where digital content data is stored. Furthermore, the following information, which is not illustrated, may be stored in association with the token ID. • Token expiration date, or validity period from the date of issuance of the token • Number of tokens available Furthermore, information regarding the token owner is recorded in the transaction data of the latest block on the blockchain, linked to the token ID (ledger ID). Past transaction history is also accumulated as transaction data for all blocks. In other words, past transaction history is treated as unique information for each token.

[0162] (9) Exchange of goods The exchange process for merchandise according to the second embodiment will now be described. Figure 17 is a flowchart of the exchange process for merchandise according to the second embodiment. Note that Figure 17 omits the illustration of the processing of the distributed ledger system 50. Steps S111 to S112 are identical to the process in Figure 11, so their explanation will be omitted. In this exchange process, the goods are provided before the tokens are transferred.

[0163] In step S113, the application for token transfer differs from the processing in the first embodiment shown in Figure 11, in that a token is granted to the token verification server 60. That is, the user terminal 10 instructs the distributed ledger system 50 (not shown) to grant a token to the token verification server 60. More specifically, the token verification server 60 instructs the distributed ledger system 50 to change the information of the token owner recorded on the blockchain corresponding to the ledger ID from information about the user to information about the administrator of the token verification server 60. Here, the information about the administrator of the token verification server 60 is, for example, wallet information managed by the administrator of the token verification server 60 in the distributed ledger.

[0164] Then, similar to steps S511 and S512 described above in Figure 11, the distributed ledger system 50 changes or adds information about the token owner from information about the user to information about the token verification server 60, and notifies the token verification server 60 of this change. The token verification server 60 receives the granted token (step S611).

[0165] After step S611, the token verification server 60 verifies whether the token is authentic (step S612). Specifically, the token verification server 60 verifies, for example, the information of the token's issuer among the unique information associated with the token ID recorded in the distributed ledger. If the appropriate issuer information is recorded as the issuer information for the token, the server determines that the token is authentic. The appropriate issuer information that forms the basis of this determination may be stored separately in a reference data table. Furthermore, the token verification server 60 may use other information associated with the token ID (including information about the product, information about the redeemer, and information about the token's transaction history) to verify the authenticity of the token. In this explanation, the token verification server 60 verifies the authenticity of the granted token. However, the authenticity of the token may also be verified before receiving the token using the token information included in the redemption application. In this case, the effort required to transfer the token from the user to the token verification server 60 can be eliminated.

[0166] The token verification server 60 then outputs the result of verifying whether or not the token is authentic. In other words, if it is determined in step S612 that the token is not authentic, the token verification server 60 notifies the user that the redemption is not possible. This terminates the redemption process for the product. At this point, the token verification server 60 may also return the token that was previously granted to the user.

[0167] On the other hand, if it is determined in step S612 that the token is authentic, the token verification server 60 instructs the product exchange server 30 to provide the token (step S613). Specifically, the token verification server 60 notifies the product exchange server 30 of information regarding the product to be provided based on the unique information held by the token, and sends an instruction to the product to be provided to the user.

[0168] After step S613, the product exchange server 30 authorizes the provision of the product (step S341). Specifically, the product exchange server 30 authorizes the provision of the product according to a pre-configured pattern. The product exchange server 30 notifies the user terminal 10 that it has authorized the provision of the product.

[0169] After step S341, the user terminal 10 receives the merchandise (step S114). Specifically, the user terminal 10 receives a notification from the product exchange server 30 that it has been authorized to provide the product.

[0170] After step S114, the user terminal 10 sends a report to the token verification server 60 regarding the receipt of the goods (step S115).

[0171] After step 115, the token verification server 60 receives a report regarding the receipt of the goods (step S614).

[0172] After step S614, the token verification server 60 instructs the token to be sent to the product exchange server 30 (step S615). Specifically, the token verification server 60 applies to the distributed ledger system 50 for the granting of tokens. That is, the token verification server 60 instructs the distributed ledger system 50 to change the information of the token owner recorded on the blockchain corresponding to the ledger ID from information about the user to information about the redeemer.

[0173] Then, similar to steps S511 and S512 described above in Figure 11, the distributed ledger system 50 modifies or adds information about the token owner. In other words, the distributed ledger system 50 notifies the exchanger that tokens have been granted to the exchanger's wallet.

[0174] After step S615, the product exchange server 30 receives the token transfer (step S342). The product exchange server 30 receives the token transfer by receiving the tokens that have been granted to the exchanger from the distributed ledger system 50. With the above steps completed, the exchange process for the merchandise according to this embodiment is finished.

[0175] (10) Summary As explained above, in System 2 according to this embodiment, the authenticity of a token is verified by checking the unique information of the token recorded in the distributed ledger. Therefore, it is not necessary to access the server where each database is stored in order to refer to the database in which information about the token is stored. This ensures the liquidity of the token and enables smoother commercial transactions. Furthermore, in System 2, verifying the authenticity of tokens does not require access to the server where each entity's database is stored. Therefore, the barrier to entry for new exchangers is reduced, and it is expected to become particularly useful when the number of exchangers becomes large. Furthermore, because unique information linked to the token ID is recorded in a distributed ledger, it becomes difficult to tamper with the information, thus eliminating fraudulent activities in transactions conducted via tokens.

[0176] Furthermore, since transactions of goods can be completed simply by verifying information recorded on a distributed ledger, exchangers do not need to join any consortium as exchangers. Therefore, retailers of any size can conduct transactions related to the exchange of goods using the tokens of this invention, enabling highly flexible commercial transactions. Furthermore, tokens, which are exchange vouchers that are extremely difficult to tamper with, can be circulated freely among users, thereby increasing the marketability of goods.

[0177] Furthermore, a token verification server 60, separate from the product exchange server 30, verifies the authenticity of the tokens. This allows for the provision of goods only after verifying the token's authenticity while simultaneously generating token transfer transactions in the distributed ledger. This ensures the security of transactions using tokens.

[0178] <Third Embodiment> Next, a third embodiment of the present invention will be described in detail with reference to the drawings. In the drawings used to illustrate the embodiments, the same reference numerals are generally used for identical components, and repeated descriptions of them will be omitted.

[0179] (11) Configuration of Information Processing System 3 The configuration of the information processing system 3 (hereinafter simply referred to as System 3) according to this embodiment will now be described. Figure 18 is a block diagram showing the configuration of the information processing system 3 according to the second embodiment.

[0180] As shown in Figure 18, System 3 includes a token management and product exchange server 40 instead of the token management server 20 and product exchange server 30 of the first embodiment. In other words, this embodiment applies when the business operator that issues tokens and the business operator that exchanges products are the same.

[0181] The token management and product exchange server 40 is connected to the user terminal 10 and the distributed ledger system 50 via a network NW, enabling communication between them. The other configurations of the information processing system 3 are the same as those in the first embodiment, so their description will be omitted. The configuration of the token management / merchandise redemption server 40 is identical to that of the token management server 20, therefore its explanation is omitted.

[0182] In System 3, the token management / merchandise exchange server 40 implements the functions of the token management server 20 and the merchandise exchange server 30. That is, the token issuance process shown in Figure 10 and the merchandise exchange process shown in Figure 11 or Figure 12 are performed by the user terminal 10, the token management / merchandise exchange server 40, and the distributed ledger system 50. In System 3, the payment process for the exchange shown in Figure 13 is not performed. This is because the business that issues the tokens and the business that exchanges the merchandise are the same, so there is no need to pay the consideration for the exchange.

[0183] (12) Summary As described above, in System 3 according to this embodiment, the token management and product exchange server 40 performs the token issuance process and the product exchange process. Therefore, by enabling users to trade tokens that serve as exchange vouchers with each other, it is expected that transactions related to products will become more active.

[0184] (13) Other variations The storage device 11 may be connected to the user terminal 10 via a network NW. The display 15 may be built into the user terminal 10. The storage device 21 may be connected to the token management server 20 via a network NW. The storage device 31 may be connected to the product exchange server 30 via a network NW. Each of the above information processing steps can be rearranged, provided that no inconsistencies occur in the processing.

[0185] Furthermore, in the above embodiment, the token master DB 211 was associated with the token type ID with information about the issuer and information about the redeemer, but this is not limited to this. For example, an issuer DB containing information about the issuer may be provided separately, and the token master DB 211 may be associated with the token type ID with the issuer identification information recorded in the issuer DB. Alternatively, a separate exchanger database may be established to store information about the exchanger, and the token master database 211 may store the exchanger's identification information recorded in the exchanger database for the token type ID.

[0186] Furthermore, in the above embodiment, payment terms related to the payment of consideration for exchange were associated with the token type ID in the token master DB 211, but this is not limited to this. For example, a separate contract DB may be provided that stores information about the contract contents, including payment terms, and the token master DB 211 may be associated with the token type ID with the identification information of the applicable contract recorded in the contract DB.

[0187] Furthermore, restrictions may be placed on the circulation of tokens by setting an expiration date or a validity period from the date of issuance. Furthermore, the number of times a recirculating token can be used may be limited to one time or within a predetermined number of times by managing the number of status changes in token transactions. The number of times a token can be used may also be limited by the number of times it has been owned by the issuer, redeemer, or user.

[0188] Alternatively, the distributed ledger managed by the distributed ledger system 50 may be equipped with contract data that automatically executes processes according to pre-set rules, and the distributed ledger system 50 may automatically provide the goods to the user triggered by the transfer of tokens to the exchanger. In this case, the rules set in the contract data include the detection of the transfer of tokens to the exchanger as input data, and the output process is pre-set to provide a specific product to the user.

[0189] Furthermore, the distributed ledger managed by the distributed ledger system 50 may contain contract data that automatically executes processes according to pre-set rules. In this case, the distributed ledger system 50 may automatically execute payment of consideration for the exchange of goods to the exchanger, triggered by the transfer of tokens from the exchanger to the issuer. In this case, the contract items set in the contract data include, as input data, the detection of the transfer of tokens to the issuer, and as output processing, the payment of consideration according to the payment conditions for the exchange to the exchanger is pre-set.

[0190] Additionally, some of the data associated with the token ID may be stored within the distributed ledger. In other words, in the first embodiment, at least a portion of the data stored in the token DB212 may be stored within the distributed ledger.

[0191] Furthermore, verification of the authenticity of tokens is not limited to the exchange process for goods, but may also be applied to the payment process for the exchange of goods. In this case, at least the following aspects are included. • After the token is transferred from the redeemer to the issuer, the authenticity of the token is verified, and in response to the verification of authenticity, the issuer pays the redeemer. The process involves the exchanger requesting the issuer to transfer tokens, verifying the authenticity of the tokens, and upon confirmation of their authenticity, transferring the tokens to the issuer and paying the exchanger the corresponding payment. The process involves verifying the authenticity of the token granted by the redeemer to the administrator of the token verification server 60; in response to the verification of authenticity, the issuer pays the redeemer the consideration; and in response to the redeemer receiving the consideration, the token is returned from the administrator of the token verification server 60 to the issuer.

[0192] Although embodiments of the present invention have been described in detail above, the scope of the present invention is not limited to the embodiments described above. Furthermore, the embodiments described above can be improved or modified in various ways without departing from the spirit of the present invention. In addition, the embodiments and modifications described above can be combined. [Explanation of Symbols]

[0193] 1, 2: Information Processing Systems 10: User terminal 10 11:Storage device 12: Processor 20: Token management server 21:Storage device 22: Processor 30: Product exchange server 31: Storage device 22: Processor 40: Token management / merchandise exchange server 41:Storage device 42: Processor 50: Distributed ledger system 55: Node Computer

Claims

1. A program for operating a computer having a processor and a memory, the program causing the processor to: A step of receiving a request for issuing an NFT (Non-fungible token) indicating the right to request exchange for a commodity from a user; In response to the issuance request, granting the NFT to the user by indicating an association of the NFT with information that can identify the user in a distributed ledger; Execute The program, wherein the NFT is associated with information identifying a group of redeemers capable of redeeming the NFT, and the program permits the provision of the merchandise to the user on the condition that the NFT is transferred on the distributed ledger from the user to a redeemer capable of redeeming the NFT.

2. The processor, Detecting that the NFT transferred to the redeemer to provide the product to the user has been transferred from the redeemer to the issuer of the NFT on the distributed ledger; In response to detecting the transfer of the NFT from the redeemer to the issuer, performing a payment of consideration to the redeemer who redeemed the merchandise in accordance with terms associated with the NFT; The program according to claim 1 ,

3. The program described in claim 1, wherein the commercial product is at least one of a real-world item, an item that can be used in a virtual space, and digital content.

4. The issuer of the NFT is a cooperative organization related to the merchandise, The redeemer of the NFT is a member of the consortium; The program according to claim 1.

5. A program for operating a computer having a processor and a memory, the program causing the processor to: A step of receiving, from a user, a request to exchange a non-fungible token (NFT) indicating a right to request exchange for the merchandise; Detecting that the NFT has been transferred on a distributed ledger from the user to a redeemer capable of redeeming the NFT; a step of confirming, based on information about the NFT related to the redemption request and information identifying a group of redeemers consisting of multiple redeemers who can perform the redemption, that the redeemer who is the subject of the redemption request is included in the group of redeemers; permitting the provision of the merchandise to the user in response to detecting the transfer of the NFT and the fact that the redeemer to whom the redemption request is made is included in the redeemer group; A program that executes the following.

6. The processor: Instructing the exchanger to transfer the NFTs transferred to the exchanger to provide the merchandise to the user from the exchanger to the issuer of the NFTs on the distributed ledger; receiving a notification of payment of consideration from the issuer to the redeemer in response to the transfer of the NFT from the redeemer to the issuer; The program according to claim 5, which causes the program to execute the following.

7. The program described in claim 5, wherein the commercial product is at least one of a real-world item, an item that can be used in a virtual space, and digital content.

8. The processor: and confirming the authenticity of the NFT related to the redemption request; The program according to claim 5, wherein in the step of permitting the provision of the merchandise to the user, the provision of the merchandise to the user is permitted in accordance with confirmation of the authenticity of the NFT related to the exchange request.

9. The issuer of the NFT is a cooperative organization related to the merchandise, The redeemer of the NFT is a member of the consortium; The program according to claim 5.

10. A system comprising a first computer and a second computer, The first computer A means for receiving a request from a user to issue a non-fungible token (NFT) indicating the right to request exchange for a commodity; A means for granting the NFT to the user in response to the issuance request from the user by instructing the NFT to be associated with information that can identify the user in a distributed ledger; Equipped with The NFT is associated with information identifying a group of redeemers who are capable of redeeming the NFT, and the provision of the product to the user is permitted on the condition that the NFT is transferred from the user to the redeemers who are capable of redeeming the NFT on the distributed ledger; The second computer A means for receiving a request from a user to exchange the NFT for the merchandise; means for detecting that the NFT has been transferred from the user to the redeemer on the distributed ledger; A means for confirming that the redeemer who is the subject of the redemption request is included in the redeemer group based on information about the NFT related to the redemption request and information identifying a redeemer group consisting of multiple redeemers who are able to redeem the NFT; a means for permitting provision of the merchandise to the user in response to detection of transfer of the NFT and the fact that the redeemer to whom the redemption request is made is included in the redeemer group; A system comprising:

11. The first computer A means for detecting that the NFT transferred to the redeemer to provide the product to the user has been transferred from the redeemer to the issuer of the NFT on the distributed ledger; a means for, in response to detecting a transfer of the NFT from the redeemer to the issuer, executing a payment of consideration to the redeemer who redeemed the merchandise in accordance with conditions associated with the NFT; Equipped with The second computer A means for instructing the transfer of the NFT transferred to the redeemer to provide the product to the user from the redeemer to the issuer of the NFT on the distributed ledger; A means for receiving a notification of payment of consideration from the issuer to the redeemer in response to the transfer of the NFT from the redeemer to the issuer; The system of claim 10, comprising:

12. The system described in claim 10, wherein the commercial product is at least one of a real-world item, an item that can be used in a virtual space, and digital content.

13. The issuer of the NFT is a cooperative organization related to the merchandise, The redeemer of the NFT is a member of the consortium; The system of claim 10.

14. A method implemented on a computer having a processor and a memory, wherein the processor: A step of receiving a request for issuing an NFT (Non-fungible token) indicating the right to request exchange for a commodity from a user; In response to the issuance request, granting the NFT to the user by indicating an association of the NFT with information that can identify the user in a distributed ledger; Run The method, wherein the NFT is associated with information identifying a group of redeemers capable of redeeming the NFT, and the provision of the merchandise to the user is permitted on the condition that the NFT is transferred on the distributed ledger from the user to a redeemer capable of redeeming the NFT.

15. An information processing device comprising a control unit and a storage unit, wherein the control unit: A step of receiving a request for issuing an NFT (Non-fungible token) indicating the right to request exchange for a commodity from a user; In response to the issuance request, granting the NFT to the user by indicating an association of the NFT with information that can identify the user in a distributed ledger; Run An information processing device in which the NFT is associated with information identifying a group of redeemers consisting of multiple redeemers who are able to redeem the NFT, and the product is permitted to be provided to the user on the condition that it is transferred from the user to a redeemer who is able to redeem the NFT on the distributed ledger.

16. A method implemented on a computer having a processor and a memory, wherein the processor: A step of receiving, from a user, a request to exchange a non-fungible token (NFT) indicating a right to request exchange for the merchandise; Detecting that the NFT has been transferred on a distributed ledger from the user to a redeemer capable of redeeming the NFT; a step of confirming, based on information about the NFT related to the redemption request and information identifying a group of redeemers consisting of multiple redeemers who can perform the redemption, that the redeemer who is the subject of the redemption request is included in the group of redeemers; permitting the provision of the merchandise to the user in response to detecting the transfer of the NFT and the fact that the redeemer to whom the redemption request is made is included in the redeemer group; How to do it.

17. An information processing device comprising a control unit and a storage unit, wherein the control unit: A step of receiving, from a user, a request to exchange a non-fungible token (NFT) indicating a right to request exchange for the merchandise; Detecting that the NFT has been transferred on a distributed ledger from the user to a redeemer capable of redeeming the NFT; a step of confirming, based on information about the NFT related to the redemption request and information identifying a group of redeemers consisting of multiple redeemers who can perform the redemption, that the redeemer who is the subject of the redemption request is included in the group of redeemers; permitting the provision of the merchandise to the user in response to detecting the transfer of the NFT and the fact that the redeemer to whom the redemption request is made is included in the redeemer group; An information processing device that executes the above.

Images