JP2018097725A - Digital transaction system based on virtual currency - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a digital transaction system based on a virtual currency capable of being used for transactions of various transaction objects.SOLUTION: A digital transaction system based on a virtual currency according to one embodiment of the present invention comprises: a first terminal tool provided with a module for generating a ticket creation transaction including information on a ticket allocation destination and a ticket attribute list; a second terminal tool provided with a message generating unit for generating a ticket purchase message for offering purchase of a ticket; and a third terminal tool serving as an assigning destination of a ticket purchase message, and provided with a transaction generation unit for generating a ticket purchase transaction for transferring the ownership of the ticket to the second terminal tool according to the ticket purchase message. Each transaction is recorded in a distributed chain block ledger in the system.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a digital transaction system based on virtual currency.

  In recent years, payment systems using virtual currency have been developed. As the virtual currency, Bitcoin (registered trademark), Ethereum, Ripple (registered trademark), Litecoin, Monero, Dash, Augur and the like are known. For example, in a virtual currency system using Bitcoin, Bitcoin is traded through a peer-to-peer network and recorded in software, hardware, or a wallet on the web of each user participating in the system. The consistency of Bitcoin transactions (transactions) is that all transactions performed at regular intervals are aggregated into a data structure called a block, and the records of this block are distributed on the network. In addition to the data structure called the aggregated block chain, it is recorded in this blockchain ledger (ledger) and kept by verification using it.

  Patent Document 1 uses a virtual currency that includes block item technology on a peer-to-peer network between terminals and includes position items (PIC) in order to improve security when trading securities. Disclose the trading system. In this system, the position item is a symbol indicating stocks of a specific company (for example, IBM (registered trademark) securities are displayed as “IBM-S”). In addition, the ownership of the virtual currency is broadcast to all terminals in the system by a transaction generated based on public key cryptography, and the address of the receiving terminal and the transition of ownership are included in the broadcasted transaction. Information such as (chain of title) is included. In securities trading, both traders transfer their transactions to a coordinator terminal that they can trust, receive verification from the terminal, and the legitimate location of the virtual currency sent by the senders. In the case of being a voter, these transactions are simultaneously recorded in a blockchain ledger implemented in each terminal on the network. As described above, the transition of the transaction is shared by the terminals participating in the system and verified with each other, thereby maintaining the security of the virtual currency securities transaction.

  Patent Document 2 discloses an electronic ticket transaction system. According to this system, a user can easily purchase electronic coupons for receiving various services without taking time and easily collect the price of electronic coupons that are no longer needed. In addition, it is possible for the service provider to reduce the need to manually sell the electronic coupon or collect a fee for the electronic coupon.

US Patent Application Publication No. 2015/0332395 JP 2008-269624 A

  As described in Patent Document 2, the conventional electronic ticket transaction system is a so-called central management system in which a service provider manages the sale and deletion of electronic coupon tickets in a lump. In such a central management system, if the central management server or the like temporarily fails or an error occurs, the system or electronic ticket may not be used. On the other hand, for the side using the system, various personal information is provided to the central management server, and there is a risk of information leakage and the like. Furthermore, increasing the safety of transactions by the central management server, etc., increases the cost of augmenting manpower and facilities, and ultimately adds a burden to the fee paid by the system user. Will do.

  Patent Document 1 discloses a system that maintains the safety of transactions at a low cost using a virtual currency when trading securities. In this system, a position item (that is, a company name, etc.) is used to incorporate a position item that represents which company the stock belongs to into virtual currency by using several digits of alphanumeric characters, and to trade virtual currency. There are restrictions on the number and types that can be handled as symbols), and a central administrator is required for the role to be determined. When newly registering, a PIC code that has already been used must be considered. In addition, in order to make a transaction with this system, it is essential that there is a coordinator that both traders can trust, and since the coordinator confirms the validity of the trade, it plays an important role in broadcasting the related transaction at the same time. The coordinator will need to pay a commission during the transaction, leading to an increase in transaction costs. In electronic transactions of various transaction objects such as general tickets, services, merchandise and second-hand goods, a flexible and low-cost system that maintains the safety and reliability of transactions is desired.

  Therefore, in view of such circumstances, an object of the present invention is to provide a digital transaction system based on virtual currency that can be applied not only to securities and electronic tickets but also to various transaction objects.

In the following, the digital transaction system based on the virtual currency of the present invention is mainly used for various types of tickets, hotel and event venue reservation rights, or air tickets, or arts, crafts, antiques, excavations, mobiles. Although the system applied to the transaction of an asset or a non-moving asset is described, it is not limited to this. The digital transaction system based on virtual currency according to the present invention includes the following modes, and all items to be traded are hereinafter referred to as “tickets”.
[1]
A digital transaction system based on virtual currency in which a plurality of terminal tools are connected via the Internet,
The first terminal tool of the plurality of terminal tools includes a ticket creation module that generates a ticket creation transaction including information on a ticket assignment destination and a ticket attribute list,
A second terminal tool of the plurality of terminal tools includes a message generation unit that generates a message offering to purchase a ticket (ticket purchase message),
A third terminal tool of the plurality of terminal tools is an assignment destination of the ticket purchase message, and a transaction (ticket purchase transaction) for transferring the ownership of the ticket to the second terminal tool according to the message. ) To generate a transaction generation unit,
The system, wherein the ticket creation transaction and the ticket purchase transaction are recorded in a blockchain ledger distributed and managed in the system.
[2]
The system according to [1], wherein the ticket attribute list includes a ticket serial number, a seat designation number of a venue in the case of an event ticket, and / or the number of times of transfer of ownership of the ticket.
[3]
The message generation unit of the second terminal tool further provides a message (token purchase message) that offers to exchange the real currency for a virtual currency (token) used for ticket purchase in the system at a predetermined rate. ). The system according to [1] or [2].
[4]
A fourth terminal tool of the plurality of terminal tools is an assignment destination of the token purchase message, and in accordance with the message, ownership of the token of the actual currency amount to be exchanged is assigned to the second terminal tool. The system according to [3], further including a transaction generation unit that generates a transaction (token purchase transaction) to be transferred to the tool.
[5]
The third terminal tool generates a message (token sale message) that offers to exchange virtual currency (token) used for ticket purchase transaction in the system with real currency at a predetermined rate. The system according to [4], further comprising:
[6]
The transaction generation unit of the fourth terminal tool, to which the token sale message is allocated, transfers ownership of the token to be exchanged from the third terminal tool to the fourth terminal according to the token sale message. The system according to [5], wherein a transaction to be transferred to a tool (token sale transaction) is generated.
[7]
The system according to [6], wherein the token purchase transaction and the token sale transaction are recorded in the blockchain ledger.
[8]
The ticket creation transaction and the ticket purchase transaction are recorded in a blockchain ledger distributed and managed in the system,
These tickets are trading objects, and are various types of tickets, hotel and event venue reservation rights, air tickets, arts, crafts, antiques, excavated goods, mobile assets, or non-moving assets. Not limited to
The token purchase transaction and the token sale transaction are recorded in a blockchain ledger distributed and managed in the system,
The system according to [7], wherein the token is a virtual currency used to buy and sell a ticket that is a transaction object.

1 is a schematic diagram of a system according to an embodiment of the present invention. It is a block diagram of one implementation of the terminal tool used in the system. It is a schematic diagram showing a flow of ticket and token transactions in the system. It is a conceptual diagram of ticket creation transaction generation. It is a conceptual diagram of ticket purchase message generation. It is a conceptual diagram of ticket purchase message generation. It is a conceptual diagram of ticket purchase message generation. It is a conceptual diagram of ticket purchase transaction generation. It is a conceptual diagram of ticket purchase transaction generation. It is a conceptual diagram of ticket purchase transaction generation. It is a conceptual diagram of token purchase message generation. It is a conceptual diagram of token purchase transaction generation. It is a conceptual diagram of token sale message generation. It is a conceptual diagram of token sale transaction generation. It is a conceptual diagram of member card creation transaction generation. It is a conceptual diagram of ticket purchase message generation using points. It is a conceptual diagram of ticket purchase transaction generation using points. It is a conceptual diagram of point sale message generation. It is a conceptual diagram of point sale transaction generation.

  Hereinafter, various embodiments of the present invention will be described with reference to the drawings. The functions and the like illustrated and described below are examples of one embodiment of the present invention, and may have other functions and other features without departing from the spirit and scope of the present invention. In addition, a digital transaction system and terminal tool based on virtual currency, which will be described below, are a programmable circuit programmed or configured by software and / or firmware, an application specific circuit (application specific integrated circuit (ASIC)) , A programmable logic device (PLD), a field programmable gate array (FPGA), etc.), or a combination thereof.

The unit of virtual currency used in the digital transaction system based on virtual currency of the present invention is called a “token”. Tokens can be exchanged for currency. In this specification, “currency” includes actual currency (yen, US dollar, euro, etc.) and other virtual currency (for example, Bitcoin). Moreover, the symbol used by description of the system which concerns on one Embodiment of this invention has the meaning described in the following table | surfaces although it is not limited.

  FIG. 1 is a conceptual diagram of a system 10 according to an embodiment of the present invention.

  FIG. 2 is a block diagram of the terminal tool 100 used by the user for generating and transmitting / receiving messages and transactions in the system 10.

  Users participating in the system 10 include, but are not limited to: producers, wholesalers, retailers, membership card issuers, customers (sellers, buyers), bookkeepers, tax authorities, and token exchanges The place is included. “Users” include individuals, corporations, various organizations, administrative organizations, and the like.

  Each user who participates in the system 10 participates in the system 10 using a terminal tool 100 (FIG. 2) described later, and the terminal tools 100 are connected so as to communicate with each other via the Internet. Each of the terminal tools 100 included in the system 10 is preferably a node of a peer-to-peer network.

  A block chain ledger for recording various transactions using the block chain technology is recorded on the recording media of the terminal tools 100 of all (or a part of) users who participate in the system 10. In other words, the block chain ledger in which all transactions are recorded is distributed and managed in the system 10. Since each terminal tool 100 mutually verifies the blockchain ledger, the security of the system 10 is maintained from a malicious user or the like who generates a false transaction.

  In addition, the system 10 has a registry as a site for publicly registering information related to tickets for various events such as music concerts and sports matches (for example, names of musicians performing, dates, places, ticket types, etc.). For example, the producer registers information on tickets to be sold in such a registry, so that a user (buyer) who wishes to purchase a ticket can confirm its existence. The registry may not only exist in the system 10, but may also disclose information regarding tickets on a general website or the like.

  The main role of the “producer (PR)” participating in the system 10 is to issue a new ticket that is a transaction object. For example, a music concert ticket in a music concert ticket, a music band, etc. are assumed. Is expected to be a sports organization. The terminal tool 100 used by the producer includes a module (reference numeral 131 in FIG. 2) that generates a ticket creation transaction that enables a new issue of a ticket, which will be described later. In the system 10, only the producer plays a role of issuing a new ticket.

  “Wholesalers” are those who primarily purchase tickets from producers and sell them to retailers and customers. For example, in the case of music concerts, record companies, management offices, event organizers, or industrial communities. Etc. A “retailer” is a person who purchases a ticket from a producer or wholesaler and sells the ticket to a customer (eg, a ticket store, a reseller, etc.).

  The “member card issuer” is a person who newly issues a member card that can be used in the system 10, and a customer having a member card can purchase a ticket using points. The member card issuer is a joint venture by a producer, a sales promotion agent, or the like. The terminal tool 100 used by the membership card issuer includes a module (reference numeral 132 in FIG. 2) that generates a membership card creation transaction.

  A “customer” is a person who purchases a ticket from a wholesaler or a retailer or resells a ticket to another customer. Customers generally purchase tickets mainly to participate in music concerts and the like, but also sell unnecessary tickets.

 The “book keeper” is a person who verifies various transactions broadcast in the system 10 and records the transactions in the block chain ledger. The book keeper plays the same role as, for example, a miner in Bitcoin (registered trademark) and other virtual currency systems. The bookkeeper periodically (for example, every few minutes) performs a predetermined calculation process based on a proof of work (for example, from the beginning of the hash value of the block) for a block that is a set of various transactions that have been broadcast. A book keeper that first finds such a hash value in the system 10 performs a process of finding a hash value having a predetermined number of multiple digits of 0), and the block of the transaction that has been newly broadcast is stored in the block chain ledger. In addition to this, it is a mechanism to get a reward (fee) for the work.

  The “Tax Bureau” is a person who receives a tax related to ticket sales and the like performed on the system 10, and the system 10 receives the tax with tokens. The “exchange” is a person who exchanges tokens and currency according to a predetermined rate.

  The terminal tool 100 may be software that operates on a terminal such as a PC, a smartphone, or a tablet, a web application that is accessed from a web browser and operates on the web, or an embedded CPU or dedicated LSI (ASIC, FPGA). Etc.) may be a dedicated model (hardware). Further, various functions of the terminal tool 100 may be realized by a CPU such as a PC or a smartphone in which the terminal tool 100 is installed executing various processes according to a predetermined program stored in a storage medium. Alternatively, some or all of the functions may be realized by a dedicated LSI that executes processing for realizing those functions.

  The terminal tool 100 includes, as basic functions, a key generation unit 111, an electronic signature generation unit 112, an electronic signature verification unit 113, a message generation unit 114, a message verification unit 115, a message recording unit 116, a transaction generation unit 117, and a transaction verification unit 118. , And a transaction recording unit 119. The terminal tool 100 includes a user interface (I / F) 121 and an Internet I / F 122.

  The terminal tool 100 may include a ticket creation module 131, a membership card creation module 132, and / or an attribute assignment module 133 as add-on modules. These add-on modules are included in the terminal tool 100 of a specific user among the users of the system 10. For example, the terminal tool 100 used by the producer includes a ticket creation module 131 as an add-on module, and the terminal tool 100 used by the membership card issuer includes a membership card creation module 132. The terminal tool 100 used by producers, wholesalers, retailers, customers, and the like may include an attribute assignment module 133. Generally, the terminal tool 100 used by a customer does not include these add-on modules.

  The key generation unit 111 generates a private key / public key pair based on the public key encryption technology, and generates an address of the user of the terminal tool 100 (recipient of the ticket and token) using the generated public key. The key generation unit 111 generates a new private key / public key pair when the user registers in the system 10 via the terminal tool 100 or when the user desires to generate a new key. The user address may be a public key itself generated by the key generation unit 111 or may be generated based on the public key.

  The electronic signature generation unit 112 generates a hash value using a hash function and encrypts various messages and transactions generated by the message generation unit 114 and the transaction generation unit 117 using a secret key generated by the key generation unit 111. To generate those electronic signatures. The electronic signature is generated when a message and transaction are transmitted, and is sent to the destination together with the message and transaction.

  The electronic signature verification unit 113 generates a hash value by decrypting the electronic signature attached to the received message or transaction with the public key of the transmission source, and also uses the hash function from the received message or transaction itself to hash Generate a value. The electronic signature verification unit 113 verifies whether or not the hash values of both are equal, and determines that the received message or transaction is valid if they are equal, and is invalid if they are not equal. For example, as a countermeasure against invalidity, received messages and transactions may be automatically discarded, or a warning for the user may be issued.

  The message generation unit 114 generates an offer message for the other party at the time of ticket purchase, token purchase, token sale, and point sale. In the system 10, a transaction is generated when a user who receives an offer message agrees with the content of the offer message. In other words, if the user who received the offer message does not agree with the offer, no transaction is generated. In this system 10, the agreement between the user who makes the offer and the user who receives it becomes clear in the form of transaction generation. The contents included in the offer message will be described later.

  The message verification unit 115 verifies the content of the received message and / or the message to be transmitted. For example, the message verification unit 115 verifies whether the received message contains necessary information or conforms to a predetermined format. In addition, the message verification unit 115 accesses the blockchain ledger and provides evidence of ticket inventory, token evidence necessary for payment, evidence of points, membership, and membership in the received and / or transmitted messages. It verifies whether information such as card evidence (both will be described later) is recorded in the blockchain ledger and that there are no shortages or errors in tickets and tokens. In the following description, it is assumed that the message to be transmitted and the received message have been verified by the message verification unit 115 (that is, appropriate messages).

  The message recording unit 116 records all or a part of the received message or the transmitted message on a recording medium of the terminal in which the terminal tool 100 is installed, a recording medium of the terminal tool 100, or a cloud storage on the Internet. . For example, the message recording unit 116 may record the received message only until a transaction is generated for the message.

  The transaction generation unit 117 generates a transaction when creating a ticket (that is, issuing a new ticket), purchasing a ticket, purchasing a token, selling a token, selling a point, and issuing a membership card. Broadcast to each terminal tool 100. The transaction is verified by the book keeper and recorded in the blockchain ledger, whereby the transaction is approved in the system 10 and its credit is secured.

  The transaction verification unit 118 verifies the contents of the received transaction and / or the transaction to be transmitted. For example, the transaction verification unit 118 verifies whether information necessary for a transaction to be transmitted is included or conforms to a predetermined format, and the content is based on the content indicated by the received or transmitted message. Also verify whether it exists. In addition, the transaction verification unit 118 accesses the block chain ledger and stores information such as evidence of ticket inventory, token evidence, and point evidence (all will be described later) included in the received transaction and / or the transmitted transaction. It is verified whether it is recorded in the blockchain ledger and whether there are any shortages or errors in the number of offers in the execution quantity. In the system 10, by verifying the transaction transmitted by each terminal tool 100 and / or the received transaction, the verification load of the book keeper is reduced. In the following description, it is assumed that the transaction to be transmitted and the received transaction have been verified by the transaction verification unit 118 (that is, an appropriate transaction).

  The transaction recording unit 119 records a received transaction or a transmitted transaction on a recording medium of a terminal in which the terminal tool 100 is installed, a recording medium included in the terminal tool 100, or a cloud storage on the Internet. By recording the transaction in this way, the terminal tool 100 can manage tickets, points, tokens, etc. possessed by the user.

  The user I / F 121 accepts input from the user via a voice input device such as a microphone, keyboard, mouse, touch pad, or touch panel operation, and displays various processing results on a monitor or notifies the user via a speaker. To do. The Internet I / F 122 is an interface that enables exchange of information such as messages and transactions between the Internet and the terminal tool 100.

  The ticket creation module 131 generates a transaction for creating a ticket. The membership card creation module 132 generates a transaction for creating a membership card. The attribute assignment module 133 changes the assignment of ticket attributes when generating a transaction.

  FIG. 3 is a schematic diagram showing a flow of ticket and token transactions in the system 10 according to the present embodiment.

An outline of a flow of ticket and token transactions in the system 10 will be described with reference to FIG. Assume that the system 10 sells a concert ticket of a musician (producer) with a seller SR. Ticket seller, the producer, is a wholesaler, or retailer, the buyer _BR 1 _{~BR M} is, wholesalers, retailers, or is the customer. Customers who sell unnecessary tickets can also be sellers.

<Purchase of token>
Buyer BR ₁ ~BR _M, it is necessary to purchase a ticket using a virtual currency (token) to be used within the system 10, token purchase message Msg _BTK for the token exchange office _{TEX | BR1:} TEX ~Msg _{BTK |} Send _{BRM: TEX} . Token exchange office TEX, the token has received purchase message _{Msg BTK | BR1: TEX ~Msg BTK} | BRM: according to the _TEX, confirmed that the buyer BR ₁ ~BR _M is the payment of the currency, which corresponds to a token amount to offer Then, the token purchase transaction Tr _{BTK | TEX: BR1 to} Tr _{BTK | TEX: BRM} is generated and transmitted (broadcast). Token purchase transaction _{Tr BTK | TEX: BR1 ~Tr BTK} | TEX: BRM is that to be recorded in the block chain ledger by the book keeper, buyer BR ₁ ~BR _M becomes a legitimate place voters of the token, transaction tickets Sometimes it is possible to use the token. Note that the buyer BR ₁ payment currency from ～BR _M to the token clearinghouse TEX for example interbank remittance and other virtual currencies (e.g. Bitcoin Bitcoin), etc., are carried out outside the system 10.

<Purchase ticket>
Buyer BR ₁ ~BR _M is, to get the ticket seller SR is dealing with information (for example, the hash value of the ticket information, etc.) from such as the seller's web site, verify this information in the registry, such as the information has been registered public about the ticket Then, the ticket purchase messages Msg _{PCH | BR1: SR to} Msg _{PCH | BRM: SR} are transmitted to the seller SR. Seller SR is, ticket purchase has received the message _{Msg PCH | BR1: SR ~Msg PCH} | BRM: depending on the _SR, the ticket purchase transaction _{Tr PCH | SR: BR1 ~Tr PCH} | SR: the send (broadcast) _BRM. Ticket purchase transaction _{Tr PCH | SR: BR1 ~Tr PCH} | SR: BRM is that to be recorded in the block chain ledger by the book keeper, buyer BR ₁ ~BR _M becomes a legitimate place voters of the ticket, the ticket Can be used.

<Sale of token>
The seller SR (or may be a buyer) sends a token sale message Msg _{STK | SR: TEX} to exchange tokens for currency at the token exchange TEX. The token exchange TEX transmits (broadcasts) the token sale transaction Tr _{STK | TEX: SR} in response to the received token sale message Msg _{STK | SR: TEX} . When the token sale transaction Tr _{STK | TEX: SR} is recorded in the block chain ledger by the book keeper, the sold token cannot be used on the seller SR side. Note that currency exchange between the token exchange TEX and the seller SR is performed outside the system 10 by, for example, interbank remittance or other virtual currency (for example, Bitcoin).

  Next, details of messages and transactions used in the system 10 of the present embodiment will be described with reference to FIGS.

  Messages and transactions used in the system 10 include, but are not limited to, ticket creation transactions, ticket purchase messages, ticket purchase transactions, token purchase messages, token purchase transactions, token sale messages, token sale transactions, membership card creation transactions, points A sale message and point sale transaction are included.

1. A ticket creation module 131 is added to the terminal tool 100 used by the ticket creation transaction producer. The ticket creation module 131 generates a ticket creation transaction for newly creating (issuing) a ticket. FIG. 4 is a conceptual diagram of a ticket creation transaction. The module 131 generates the transaction based on the information shown on the left side of FIG. 4, and the result after the transaction (changed information) is shown on the right side of FIG.

The ticket creation module 131 includes, as information about the ticket, the producer's address Ad (vk _PR ), the ticket information TT _PR (α), the producer's electronic signature Sgn (TT _PR (α)), and the ticket information TT _PR (α ) Hash value h (TT _PR (α)) as input, and as the evidence of the tokens necessary for creation, a pair of the address of the other user of the transaction that acquired the past token and the hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. Information regarding the ticket is not limited, but is input by the user (producer) through the user I / F 121, and the evidence of the token is not limited, but is suitable from past transactions recorded in the transaction recording unit 119 by the terminal tool 100. Something is extracted and used. Furthermore, the ticket creation module 131 also needs information on ticket assignment destinations (for example, wholesalers and retailers), and is input by the user (producer) through the user I / F 121, although not limited thereto.

Here, the token provided as evidence of the token in the ticket creation transaction is necessary for the bookkeeper to pay the bookkeeper a fee for recording the ticket creation transaction in the block chain ledger. The difference between the token amount provided in the token evidence and the fee received by the bookkeeper will be recorded in the blockchain ledger as the token change Tk _CNG (ie, back to the producer).

  The fee for the bookkeeper to record various transactions in the blockchain ledger may be determined in advance for the entire system 10 or may be changed as appropriate according to the amount of token circulation. Good.

The ticket creation module 131 generates a ticket creation transaction based on the input information, and the result of the ticket creation transaction includes information about the producer's address Ad (vk _PR ) and the token change Tk _CNG to that address. Also, the ticket creation transaction results, address Ad (vk _CR1) ticket is assigned _CR 1 ~CR M _(using terminal tool 100) ~Ad (vk _CRM), the ticket to each address N _CR1 [TT _PR (α)] to N _CRM [TT _{PR (α)} ], and an attribute list {Attr-list} _CR1 [TT _PR (α )] To {Attr-list} Contains information on _CRM [TT _PR (α)].

Here, in the ticket information TT _PR (α), “PR” is a symbol for identifying a ticket that is different for each producer who created the ticket, and “α” is a ticket type (for example, S seat, A seat). This is a symbol for identifying that the ticket is different for each of the different seats. The ticket information TT _PR (α) includes the ticket type code (identifier), the initial price of the ticket, the expiration date of the ticket, the terms and conditions (for example, inability to exchange, re-entry, and the number of resales. Etc.), the format of the attribute list {Attr-list} and its initial value, the attribute issuer to be designated, and information regarding the conditions at the time of resale.

  Producers may limit the number of times a ticket can be transferred (for example, cannot be transferred after purchase or can be resold only once) and / or limit price increases at the time of transfer (for example, must not be more than 10% higher than the original price). Can be set. By setting in this way, it is possible to prevent, for example, a ticket for a concert of a popular music band from being resold by a malicious reseller with an abnormally high price.

Number of tickets to be allocated for each allocation destination Ad (vk _CR1 ) to Ad (vk _CRM ) in one ticket creation transaction N _CR1 [TT _PR (α)] to N _CRM [TT _PR (α)] and each ticket Attribute list {Attr-list} _CR1 [TT _PR (α)] to {Attr-list} _CRM [TT _PR (α)] can be determined. Note that one ticket may be assigned, or the producer itself.

  The ticket creation transaction is broadcast to each terminal tool 100 of the system 10 and the bookkeeper records the transaction in the blockchain ledger. As a result, a new ticket is issued.

2. The attribute list Attr-list for the attribute list ticket information TT _PR (α) is a list of attributes attached to each ticket. Each attribute is set after creation or according to the type of attribute. The attribute list Attr-list includes, in addition to information related to various attributes of the ticket, a ticket identifier for identifying the corresponding ticket, a serial number of the attribute list, and the like. The attributes of the ticket include, for example, the seat designation number of the concert venue, the number of times the ticket has been transferred up to that point, the number of points attached to the ticket and its expiration date, and the type of membership card that can use the point. .

  The attribute included in the attribute list Attr-list corresponds to one of a fixed attribute, a dynamic attribute, and a rewritable attribute only once.

  The fixed attribute is an attribute that is determined in advance by the producer when the ticket is created and cannot be changed after the ticket is created. For example, the fixed attribute included in the attribute list Attr-list is a serial number of the attribute list of the ticket.

  Dynamic attributes are attributes that can be changed after ticket creation. For example, the dynamic attribute included in the attribute list Attr-list is the number of transfers of the ownership of the ticket, and can be changed as appropriate when a person who sells the ticket generates a transaction.

  An attribute that can be rewritten only once is an attribute that can be rewritten only once by, for example, an attribute issuer after ticket creation. As attribute issuers, wholesalers and retailers are assumed. For example, if a producer has designated a seating area within a concert venue but created a ticket without assigning a specific seat and assigned the ticket to a wholesaler or retailer, the wholesaler or retailer will designate it. Attribute to be written to specify a specific seat in the designated area. After specification, it cannot be rewritten.

3. Ticket Purchase Message A user who wishes to purchase a ticket (ticket buyer) transmits a ticket purchase message through the terminal tool 100 to a user who sells the ticket (ticket seller). The ticket purchase message is an offer message generated by the message generation unit 114 of the buyer's terminal tool 100 and directed from the buyer to the seller, and the seller transfers the ownership of the ticket to the buyer in response to the ticket purchase message. Generate a transaction (ticket purchase transaction). A retailer for a wholesaler has a seller-buyer relationship, a customer for a retailer has a seller-buyer relationship, and each customer who trades a ticket has a seller-buyer relationship. 5A to 5C are conceptual diagrams of ticket purchase message generation. In each figure, the message is generated based on the information shown on the left side, and the result (changed information) is shown on the right side of the figure.

First, the basic form of the ticket purchase message is shown in FIG. 5A. In the ticket purchase message, the seller's address Ad (vk _SR ) and the desired ticket recorded in the blockchain ledger (or published in the registry) are distinguished. Information about the hash value h (TT _PR (α)), the ticket offer price Tk _OFR , and the number of purchases N _OFR is included. In addition, the ticket purchase message optionally includes a minimum desired purchase number Nmin _OFR , a desired attribute list {Attr-list} _OFR for all tickets, an attribute list condition Attr-cond _OFR , and an offer expiry date Exp _OFR. Information etc. may be included.

Desired attribute list {Attr-list} _OFR is a seat desired by the buyer, for example, a window seat or aisle seat when the ticket is an air ticket. The attribute list condition Attr-cond _OFR is, for example, 1 for the window side. This is a specific condition that is applied to the attribute indicated by the desired attribute list {Attr-list} _OFR , such as two aisle sides and three side by side seats.

The message generation unit 114 of the buyer's terminal tool 100 includes information on the seller's address Ad (vk _SR ), the desired ticket hash value h (TT _PR (α)), the offer price Tk _OFR , and the desired purchase number N _OFR , Optionally, information on the minimum desired purchase number Nmin _OFR , the desired attribute list {Attr-list} _OFR , the attribute list condition Attr-cond _OFR , and the offer expiry date Exp _OFR is required. Such information is not limited, but is performed in such a manner that the buyer inputs through the user I / F 121 of the terminal tool 100. Further, the message generation unit 114 sets, as evidence of tokens necessary for ticket purchase, a pair of a destination user of a transaction that acquired a past token and a hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. Although the evidence of the token is not limited, the message generation unit 114 may automatically extract an appropriate one from past transactions recorded in the transaction recording unit 119.

The post-execution result of the ticket purchase message generated by the message generation unit 114 includes information on the product (payment total) of the seller's address Ad (vk _SR ) and the desired purchase number N _OFR to the address and the offer price Tk _OFR , In addition, information about the buyer's address Ad (vk _BR ), the number of tickets purchased for the buyer N _OFR [TT _PR (α)], and token change Tk _{OFR | CNG} [tokens] is included. When the tax bureau is participating in the system 10, the ticket purchase message also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] by the token directed to that address. The amount of tokens required as proof of the token is the sum of the product of the offer price Tk _OFR and the desired number of purchases N _OFR N _OFR × Tk _OFR [tokens] and the tax amount Tk _{OFR | TAX} [tokens] The fee that the bookkeeper receives must also be considered and must be large.

  Next, FIG. 5B is a conceptual diagram of ticket purchase message generation generated by a buyer (primary buyer BRP) who purchases a ticket for a plurality of users (secondary buyers BRS1, BRS2,...).

In FIG. 5B, the message generation unit 114 of the terminal tool 100 of the primary buyer includes the seller's address Ad (vk _SR ), the desired hash value h (TT _PR (α)), the ticket offer price Tk _OFR , and the desired Information on purchase quantity N _OFR and optionally information on minimum desired purchase quantity Nmin _OFR , desired attribute list {Attr-list} _OFR , attribute list condition Attr-cond _OFR , and offer expiry date Exp _OFR To do. These information further includes the addresses Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... for each secondary buyer, the number of ticket purchases N _{OFR | BRS1} [TT _PR (α)], N _{OFR | BRS2} [TT _PR (α)]…, secondary buyer's desired attributes {Attr-list} _{OFR | BRS1} [TT _PR (α)], {Attr-list} _{OFR | BRS2} [TT _PR (α)]… etc Information is also included. Further, the message generation unit 114 uses, as evidence of tokens necessary for ticket purchase, a pair of a destination user of a transaction that acquired a past token and a hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. Such information is not limited, but is input by the user through the user I / F 121. Although the evidence of the token is not limited, the message generation unit 114 may automatically extract an appropriate one from past transactions recorded in the transaction recording unit 119.

The post-execution result of the ticket purchase message generated by the message generator 114 includes the product of the seller's address Ad (vk _SR ) and the desired number of purchases N _OFR for that address and the offer price Tk _OFR [tokens] ), As well as information on the primary buyer's address Ad (vk _BRP ), the number of tickets purchased for the primary buyer N _{OFR | BRP} [TT _PR (α)] and token change Tk _{OFR | CNG} [tokens] included. Also, the ticket purchase message includes the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... and the desired number of tickets purchased for each secondary buyer N _{OFR | BRS1} [TT _PR (α)], Information about N _{OFR | BRS2} [TT _PR (α)]… is also included. In addition, when the tax bureau is participating in the system 10, the ticket purchase message also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] by the token to that address. .

The desired number of purchases N _OFR is the number of purchases desired by the primary buyer N _{OFR | BRP} [TT _PR (α)], the number of purchases desired by the secondary buyer N _{OFR | BRS1} [TT _PR (α)], N _{OFR | BRS2} [TT _It is equal to the sum of the sum of _PR (α)]…. The change Tk _{OFR | CNG} [tokens] must be assigned to the primary buyer's address Ad (vk _BRP ), not the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... . However, the desired purchase number N _{OFR | BRP} of tickets to the primary buyer can be set to zero.

  Next, FIG. 5C is a conceptual diagram of ticket purchase message generation generated by a buyer (primary buyer BRP) who purchases a plurality of types of tickets for a plurality of users (secondary buyers BRS1, BRS2,...).

In FIG. 5C, the message generation unit 114 of the terminal tool 100 of the primary buyer displays a hash value of the ticket for each seller address Ad (vk _SR ), desired ticket types TT _PR1 (a), TT _PR2 (b). Information on h (TT _PR1 (a)), h (TT _PR2 (b)) ..., ticket offer price Tk _{OFR, 1a} , Tk _{OFR, 2b} ... and desired number of purchases N _{OFR, 1a} , N _{OFR, 2b} ... Also, optionally, the minimum desired purchase number Nmin _{OFR, 1a} , Nmin _{OFR, 2b} ..., desired attribute list {Attr-list} _{OFR, 1a} , {Attr-list} _{OFR, 2b} ..., attribute list condition Attr-cond _{OFR , 1a} , Attr-cond _{OFR, 2b} ... And offer expiry date Exp _OFR . The information further includes the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... and the number of tickets purchased by the secondary buyer N for each secondary buyer and ticket type. _{OFR | BRS1,1a} [TT _PR1 (a)], N _{OFR | BRS1,2b} [TT _PR2 (b)]…, N _{OFR | BRS2,1a} [TT _PR1 (a)], N _{OFR | BRS2,2b} [TT _PR2 (b)]…, ticket attributes {Attr-list} _BRS1,1a [TT _PR1 (a)], {Attr-list} _BRS1,2b [TT _PR2 (b)]…, {Attr-list} _{BRS2, 1a} [TT _PR1 (a)], {Attr-list} _BRS2,2b [TT _PR2 (b)] ... etc. are also included. Such information is not limited, but is input by the user through the user I / F 121.

Further, the message generation unit 114 sets, as evidence of tokens necessary for ticket purchase, a pair of a destination user of a transaction that acquired a past token and a hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. Although the evidence of the token is not limited, the message generation unit 114 may automatically extract an appropriate one from past transactions recorded in the transaction recording unit 119.

The post-execution result of the ticket purchase message generated by the message generator 114 includes the seller's address Ad (vk _SR ) and the desired number of purchases N _{OFR, 1a} , N _{OFR, 2b} ... Information about the sum of products (total payment) with each offer price Tk _{OFR, 1a} [tokens], Tk _{OFR, 2b} [tokens]. The ticket purchase message also includes the primary buyer's address Ad (vk _BRP ), the number of purchases for each type of ticket to the primary buyer N _{OFR | BRP, 1a} [TT _PR1 (a)], N _{OFR | BRP, 2b} Contains information about [TT _PR2 (b)] ... and token change Tk _{OFR | CNG} [tokens]. In addition, the ticket purchase message includes the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... and the number of tickets purchased for each secondary buyer type corresponding to the secondary buyer N _{OFR | BRS1,1a} [TT _PR1 (a)], N _{OFR | BRS2,2b} [TT _PR2 (b)]... In addition, when the tax bureau is participating in the system 10, the ticket purchase message also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] by the token to that address. .

The desired purchase number N _{OFR, 1a} , N _{OFR, 2b} … entered for each ticket type is the primary buyer's desired purchase number N _{OFR | BRP, 1a} [TT _PR1 (a)], N _{OFR | BRP, 2b} [TT _PR2 (b)]… and the desired number of purchases by the secondary buyer N _{OFR | BRS1,1a} [TT _PR1 (a)], N _{OFR | BRS2,2b} [TT _PR2 (b)]…, N _{OFR | BRS2,1a} [TT _PR1 (a)], N _{OFR | BRS2,2b} [TT _PR2 (b)] is equivalent to the sum of the sum of.

4). When the ticket purchase message transmitted from the ticket purchase transaction buyer is received by the seller's terminal tool 100, the seller determines whether or not the seller can sell a ticket according to the offer of the buyer. If the sale is possible, the transaction generation unit 117 of the seller's terminal tool 100 generates a transaction (ticket purchase transaction) that transfers the ownership of the ticket to the buyer, and transmits it to each terminal tool 100 in the system 10 ( Broadcast). 6A to 6C are conceptual diagrams of ticket purchase transaction generation. In each figure, the transaction is generated based on the information shown on the left side, and the result (changed information) is shown on the right side of the figure.

First, regarding the basic form of the ticket purchase transaction, in FIG. 6A, when generating the ticket purchase transaction, the transaction generation unit 117 of the seller's terminal tool 100 displays the buyer's address Ad (vk _BR ), the received ticket purchase message Msg _{PCH | BR: SR} and the message require the buyer's electronic signature Sgn (Msg _{PCH | BR: SR} ) as an offer. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, as evidence of the inventory of the ticket, a pair {Ad (vk _PFM1 ), h (Tr _PFM1 )}, {Ad (vk _PFM2 ) of the address of the destination user of the transaction that acquired the past ticket and the hash value of the transaction , h (Tr _PFM2 )}. The evidence of ticket inventory is not limited, but the transaction generation unit 117 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119.

The transaction generation unit 117 generates a ticket purchase transaction according to the received ticket purchase message. After the execution of the ticket purchase transaction, the seller's address Ad (vk _SR ), the actual number of tickets sold to that address N _EXE [TT _PR (α)] and the actual ticket sales price Tk _EXE [ tokens] (total payment) and information about the remaining number of tickets N _REM [TT _PR (α)] that the seller will have after selling the ticket. The ticket purchase transaction includes the buyer's address Ad (vk _BR ), the actual number of sales N _EXE [TT _PR (α)] for the address, and the attribute list {Attr-list set for the sold ticket. } Contains information about _EXE [TT _PR (α)] and token fishing Tk _{EXE | CNG} [tokens]. When the tax bureau is participating in the system 10, the ticket purchase transaction also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] by the token directed to that address.

The remaining number of tickets N _REM [TT _PR (α)] corresponds to the number obtained by subtracting the number N _{EXE of} ticket sales from the sum of the number of tickets acquired in the transaction indicated by the inventory evidence. In addition, the actual ticket sales amount N _EXE [TT _PR (α)] × Tk _EXE [tokens] and tax amount Tk _{EXE | TAX} [tokens] and fishing Tk _{EXE | CNG} The amount minus [tokens] is the fee for the bookkeeper. Further, when the minimum desired purchase number Nmin _OFR is set in the ticket purchase message, the ticket sales number N _EXE [TT _PR (α)] must not be less than the minimum desired purchase number Nmin _OFR .

  The ticket purchase transaction is broadcast toward each terminal tool 100 in the system 10, and the book keeper records the transaction in the blockchain ledger.

  Next, FIG. 6B is a conceptual diagram of ticket purchase transaction generation performed by the seller for a ticket purchase message generated by one buyer (primary buyer) who purchases tickets for a plurality of users (secondary buyers).

In FIG. 6B, the transaction generation unit 117 of the seller's terminal tool 100 displays the primary buyer's address Ad (vk _BRP ), the received ticket purchase message Msg _{PCH | BRP: SR} , and the primary buyer's electronic signature Sgn for that message. (Msg _{PCH | BRP: SR} ) is required as an offer. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, the transaction generation unit 117 uses a pair {Ad (vk _PFM1 ), h (Tr _PFM1 )} of the address of the other party user of the transaction that acquired the past ticket and the hash value of the transaction as evidence of the ticket inventory. {Ad (vk _PFM2 ), h (Tr _PFM2 )} is required. The evidence of ticket inventory is not limited, but the transaction generation unit 117 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119.

The transaction generation unit 117 generates a ticket purchase transaction according to the received ticket purchase message. After the execution of the ticket purchase transaction, the seller's address Ad (vk _SR ), the actual number of tickets sold to that address N _EXE [TT _PR (α)] and the actual ticket sales price Tk _EXE [ tokens] (total payment) and information about the remaining number of tickets N _REM [TT _PR (α)] that the seller will have after selling the ticket. The ticket purchase transaction includes the primary buyer's address Ad (vk _BRP ), the actual number of sales N _{EXE | BRP} [TT _PR (α)] for that address, and the attribute list {Attr- list} Contains information about _{EXE | BRP} [TT _PR (α)] and token change Tk _{EXE | CNG} [tokens]. In addition, the ticket purchase transaction includes the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ... and the actual number of sales N _{EXE | BRS1} [TT _PR (α)], N _{EXE | BRS2} [TT _PR (α)]… and the attribute list {Attr-list} _{EXE | BRS1} [TT _PR (α)], {Attr-list} _{EXE | BRS2} [TT _PR ( Information on α)] ... is included. In addition, if the tax bureau is participating in the system 10, the ticket purchase transaction also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] by the token to that address. .

  The ticket purchase transaction is broadcast toward each terminal tool 100 in the system 10, and the book keeper records the transaction in the blockchain ledger.

  Next, FIG. 6C shows a ticket purchase transaction performed by a seller for a ticket purchase message generated by one buyer (primary buyer BRP) who purchases a plurality of types of tickets for a plurality of users (secondary buyers BRS1, BRS2,...). It is a conceptual diagram of a production | generation.

6C, the transaction generation unit 117 of the seller's terminal tool 100 displays the primary buyer's address Ad (vk _BRP ), the received ticket purchase message Msg _{PCH | BRP: SR} , and the primary buyer's electronic signature Sgn for the message. (Msg _{PCH | BRP: SR} ) is required as an offer. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, the transaction generation unit 117 uses a pair {Ad (vk _PFM1 ), h (Tr _PFM1 )} of the address of the other party user of the transaction that acquired the past ticket and the hash value of the transaction as evidence of the ticket inventory. {Ad (vk _PFM2 ), h (Tr _PFM2 )} is required. The evidence of ticket inventory is not limited, but the transaction generation unit 117 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119.

The transaction generation unit 117 generates a ticket purchase transaction according to the received ticket purchase message. After executing the ticket purchase transaction, the seller's address Ad (vk _SR ) and the actual number of sales for each ticket type N _{EXE, 1a} [TT _PR1 (a)], N _{EXE, 2b} [TT _PR2 (b)]… and the actual sales price Tk _{EXE, 1a} [tokens], Tk _{EXE, 2b} [tokens]… and the product sum (payment total), and the remaining number N for each type of ticket the seller has after sale _{Contains information on REM, 1a} [TT _PR1 (a)], N _{REM, 2b} [TT _PR2 (b)]. The ticket purchase transaction also includes the primary buyer's address Ad (vk _BRP ) and the actual number of sales per ticket to that address N _{EXE | BRP, 1a} [TT _PR1 (a)], N _{EXE | BRP, 2b} [TT _PR2 (b)] ..., attribute list actually set for each ticket {Attr-list} _{EXE | BRP, 1a} [TT _PR1 (a)], {Attr-list} _{EXE | BRP, 2b} [TT _PR2 (b)] ... and information about token fishing Tk _{EXE | CNG} [tokens]. In addition, the ticket purchase transaction includes the secondary buyer's address Ad (vk _BRS1 ), Ad (vk _BRS2 ) ..., and the actual number of sales per ticket for each address N _{EXE | BRS1,1a} [TT _PR1 ( a)], N _{EXE | BRS1,2b} [TT _PR2 (b)]…, N _{EXE | BRS2,1a} [TT _PR1 (a)], N _{EXE | BRS2,2b} [TT _PR2 (a)]…, And the attribute list actually set for each ticket {Attr-list} _{EXE | BRS1,1a} [TT _PR1 (a)], {Attr-list} _{EXE | BRS1,2b} [TT _PR2 (b)]…, {Attr -list} _{EXE | BRS2,1a} [TT _PR1 (a)], {Attr-list} _{EXE | BRS2,2b} [TT _PR2 (b)] ..., contains information about ... If the tax bureau is participating in the system 10, the ticket purchase transaction also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] by the token to that address. .

N _{EXE, 1a} [TT _PR1 (a)], N _{EXE, 2b} [TT _PR2 (b)]… is the number of sales to the primary buyer N _{EXE | BRP, 1a} [TT _PR1 (a )], N _{EXE | BRP, 2b} [TT _PR2 (b)] ... and the number of sales to secondary buyers N _{EXE | BRS1,1a} [TT _PR1 (a)], N _{EXE | BRS2,2b} [TT _PR2 ( b)] ..., N _{EXE | BRS2,1a} [TT _PR1 (a)], N _{EXE | BRS2,2b} [TT _PR2 (b)] ..., equal to the sum of ...

  The ticket purchase transaction is broadcast toward each terminal tool 100 in the system 10, and the book keeper records the transaction in the blockchain ledger.

5. Within the token purchase message system 10, a token is required to purchase a ticket. In order to obtain a token, a user who wants to exchange the currency for the token (token buyer) transmits a token purchase message Msg _BTK to the token exchange through the terminal tool 100. The token purchase message Msg _BTK is a token purchase offer message for the token exchange TEX, and the token exchange TEX exchanges currency for tokens at a predetermined rate in accordance with the token purchase message Msg _BTK . FIG. 7 is a conceptual diagram of token purchase message generation. The message is generated based on the information shown on the left side of the figure, and the result (changed information) is shown on the right side of the figure.

In FIG. 7, the token purchase message includes information on the address Ad (vk _TEX ) of the token exchange, the currency type Currency _OFR used for exchanging the token, the exchange rate Rate _OFR , and the token amount Tk _OFR desired to be exchanged. At least included. Further, the token purchase message optionally includes information on the minimum token amount Tkmin _OFR desired to be exchanged and the offer expiry date Exp _OFR . In addition, the token purchase message also includes information on currency evidence, attribution of ownership of the token and currency after execution, and tax amount Tk _{OFR | TAX} [tokens] to be paid to the tax authority.

The message generator 114 of the terminal tool 100 of the user (token buyer) who exchanges the currency for the token includes the token exchange address Ad (vk _TEX ), the currency type Currency _OFR used for the token exchange, the exchange rate Rate _OFR, exchange hope to token amount Tk _OFR, require information about the expiration date Exp _OFR of the minimum amount Tkmin _OFR and offer, the token you want. Such information is not limited, but is input by the user through the user I / F 121. In addition, when exchanging a virtual currency such as Bitcoin for a token, the message generation unit 114 uses the address of the other user of the transaction that acquired the past virtual currency and the hash value of the transaction as evidence of the virtual currency. The pairs {Ad (vk _PFC1 ), h (Tr _PFC1 )}, {Ad (vk _PFC2 ), h (Tr _PFC2 )} are required. The evidence of virtual currency is evidence in a virtual currency system that exists outside the system 10.

The post-execution result of the token purchase message generated by the message generation unit 114 includes the token exchange address Ad (vk _TEX ), the exchange rate Rate _OFR toward the address, and the token (Tk _OFR + Tk _α ) after the exchange. Contains information about the product (total amount of currency to pay). Here, to describe the token amount Tk _α, it is within the system 10 can not be used for the currency, because the use is only token, of the total token amount which corresponds to the fees paid to tax and book keeper to pay to the Inland Revenue Department Tk _α is automatically added in a form that is added to the desired token amount when purchasing tokens. In addition, the token purchase message includes information on the token buyer's address Ad (vk _BR ) and the offer token amount Tk _OFR [tokens] for the buyer, and if the tax authority is participating in the system 10, It also includes information about the _Tax Office address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] for tokens directed to that address.

6). Token purchase transaction When a token purchase message sent from a user who wants to purchase a token (buyer) is received through the terminal tool 100 of the token exchange TEX, whether the token exchange can follow the token buyer's offer. Judging. When the exchange is possible, the transaction generation unit 117 of the terminal tool 100 of the token exchange generates a transaction (token purchase transaction) for transferring the ownership of the token to be exchanged from the token exchange to the buyer. Broadcast to each terminal tool 100 in the network 10. FIG. 8 is a conceptual diagram of token purchase transaction generation. The transaction is generated based on the information shown on the left side of the figure, and the result (changed information) is shown on the right side of the figure.

In FIG. 8, when generating the token purchase transaction, the transaction generation unit 117 of the token exchange terminal tool 100 receives the token buyer address Ad (vk _BR ), the received token purchase message Msg _{BTK | BR: TEX} , and its The buyer's electronic signature Sgn (Msg _{BTK | BR: TEX} ) is required as an offer for the message. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, the transaction generation unit 117 uses, as proof of the token possessed by the token exchange, a set of a destination user of a transaction that acquired a past token and a hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. The evidence of the token is not limited, but the transaction generation unit 117 automatically extracts and uses an appropriate past transaction recorded in the transaction recording unit 119 of the terminal tool 100 of the token exchange. May be.

The transaction generation unit 117 generates a token purchase transaction according to the received token purchase message. After the execution of the token purchase transaction, the token exchange address Ad (vk _TEX ) and the product of the exchange rate Rate _EXE for that address and the token after exchange (Tk _EXE + Tk _β ) (currency paid) ) And token fishing Tk _{EXE | CNG} [tokens]. The token purchase transaction also includes information regarding the token buyer address Ad (vk _BR ) and the actual token amount Tk _EXE [tokens] exchanged. Here, the token amount Tk _β will be described. Since the currency cannot be used in the system 10 and only the token can be used, the total token amount corresponding to the tax amount paid to the tax bureau and the fee paid to the book keeper Tk _β is automatically added to the token amount to be transferred when purchasing tokens. In addition, the token purchase transaction includes information about the token buyer's address Ad (vk _BR ) and the actual token amount Tk _EXE [tokens] for the buyer. Also included is information on the Tax Authority's address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] by tokens towards that address.

The token purchase transaction is broadcast to each terminal tool 100 in the system 10, and the book keeper records the transaction in the blockchain ledger. The Bookkeeper determines the actual token amount Tk _EXE [tokens] exchanged, the token change Tk _{EXE | CNG} [tokens], and the tax amount Tk _{EXE | TAX} paid to the tax authority from the total amount of tokens indicated in the token evidence. The amount minus the total amount with [tokens] will be obtained as a fee.

7). Token sale message A user who wants to sell a token and exchange it for currency (token seller) generates a token sale message Msg _STK through the terminal tool 100 and transmits it to the token exchange TEX. The token sale message Msg _STK is an offer message for token sale to the token exchange, and the token exchange exchanges tokens to currency at a predetermined rate in response to the token sale message Msg _BTK . FIG. 9 is a conceptual diagram of token sale message generation. The message is generated based on the information shown on the left side of the figure, and the result (changed information) is shown on the right side of the figure.

In FIG. 9, the token sale message includes at least information on the address of the token exchange Ad (vk _TEX ), the currency type Currency _OFR of the token exchange, the exchange rate Rate _OFR , and the desired token amount Tk _OFR. . The token sale message also optionally includes information regarding the minimum token amount Tkmin _OFR desired to be exchanged and the offer expiry date Exp _OFR . In addition, the token sale message also includes information on token evidence, attribution of ownership of the token and currency after execution, and the tax amount Tk _{OFR | TAX} [tokens] due to the token paid to the Tax Department.

The message generation unit 114 of the terminal tool 100 of the user (token seller) who exchanges tokens exchanges the address Ad (vk _TEX ) of the token exchange, the currency type Currency _OFR , the exchange rate Rate _OFR , and the exchange request. You need information about the token amount Tk _OFR , the minimum token amount you want to exchange Tkmin _OFR , and the offer expiry date Exp _OFR . Such information is not limited, but is input by the user through the user I / F 121. In addition, the message generation unit 114 uses, as proof of having a token, a pair of a destination user of a transaction that acquired a past token and a hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, { Ad (vk _PFT2 ), h (Tr _PFT2 )}. Although the evidence of the token is not limited, the message generation unit 114 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119.

The post-execution result of the token sale message generated by the message generation unit 114 includes information on the address Ad (vk _TEX ) of the token exchange and the offer token amount Tk _OFR [tokens] for the address. In addition, the token sale message includes the token seller's address Ad (vk _SR ), the product of the token amount Tk _OFR to be exchanged with the exchange rate Rate _OFR towards the seller (total amount of currency obtained), and the token change Tk Contains information about _{OFR | CNG} [tokens]. In addition, the token sale message includes information on the tax office address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] by the token toward the address when the tax office is participating in the system 10. . The token amount to be entered as token evidence must be greater than the sum of the offer token amount Tk _OFR [tokens] and the tax amount Tk _{OFR | TAX} [tokens].

8). Token sale transaction When a token sale message from a user (seller) who wants to exchange tokens is received through the terminal tool 100 of the token exchange TEX, the token exchange determines whether it can follow the token seller's offer. To do. If the exchange is possible, the transaction generation unit 117 of the token exchange terminal tool 100 generates a transaction (token sale transaction) for transferring the ownership of the token to be exchanged from the seller to the token exchange. Broadcast toward each terminal tool 100. FIG. 10 is a conceptual diagram of token sale transaction generation. The transaction is generated based on the information shown on the left side of the figure, and the result (changed information) is shown on the right side of the figure.

In FIG. 10, when generating a token sale transaction, the transaction generator 117 of the token exchange terminal tool 100 receives the token seller address Ad (vk _SR ), the received token sale message Msg _{STK | SR: TEX} , and the message. Requires the seller's electronic signature Sgn (Msg _{STK | SR: TEX} ) as an offer. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, when exchanging a token with a virtual currency, the transaction generation unit 117 sets a pair of a destination user address of the transaction that acquired the past virtual currency related to the virtual currency and a hash value of the transaction as evidence of the virtual currency. {Ad (vk _PFC1 ), h (Tr _PFC1 )}, {Ad (vk _PFC2 ), h (Tr _PFC2 )} are required. The evidence of virtual currency is evidence in a virtual currency system that exists outside the system 10.

The transaction generation unit 117 generates a token sale transaction according to the received token sale message. The post-execution result of the token sale transaction includes information regarding the token exchange address Ad (vk _TEX ) and the actual token amount Tk _EXE [tokens] to be exchanged for that address. The token sale transaction includes the token seller's address Ad (vk _SR ) and the product of the actual token amount Tk _EXE to be exchanged with the exchange rate Rate _EXE for that address (the amount of currency actually obtained) , And information about token fishing Tk _{EXE | CNG} [tokens]. The token sale transaction also includes information about the tax office address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] by the token to that address if the tax office is participating in the system 10. .

The token sale transaction is broadcast toward each terminal tool 100 in the system 10, and the bookkeeper records the transaction in the blockchain ledger. The Bookkeeper determines the token amount Tk _EXE [tokens], the change amount Tk _{EXE | CNG} [tokens], and the tax amount Tk paid to the Tax Department from the total token amount indicated in the token evidence in the token sale message. You will get the fee minus the sum of _{EXE | TAX} [tokens].

9. Membership card creation transaction A membership card creation module 132 is added to the terminal tool 100 used by the membership card issuer. The membership card creation module 132 generates a membership card creation transaction for newly creating (issuing) a membership card. FIG. 11 is a conceptual diagram of generation of a membership card creation transaction. The module 132 generates the transaction based on the information shown on the left side of FIG. 11, and the result after the transaction (changed information) is shown on the right side of FIG.

The membership card creation module 132 includes the membership card issuer's address Ad (vk _CI ), the membership card information MC _CI (γ), and the issuer's electronic signature Sgn (MC _CI (γ)), And the hash value h (MC _CI (γ)) of the membership card information MC _CI (γ) as input, and the address of the other user of the transaction that acquired the past token as evidence of the token necessary for creation and the transaction A set of hash values {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. The information regarding the membership card is not limited, but is input by the user (member card issuer) through the user I / F 121, and the evidence of the token is not limited, but is suitable from past transactions recorded in the transaction recording unit 119. The member card creation module 132 automatically extracts and uses this. Furthermore, the membership card creation module 132 also needs information on the assignment destination of the membership card, and is input by the user (producer) through the user I / F 121, although not limited thereto.

Here, the token provided as proof of token is necessary for the bookkeeper to pay a fee for registering the membership card creation transaction in the blockchain ledger, and the amount of token provided in the token proof and the bookkeeper The difference from the received fee is recorded in the blockchain ledger as the token change Tk _CNG addressed to the address Ad (vk _CI ) of the member card issuer (that is, returns to the member card issuer side).

The result of the membership card creation transaction generated by the membership card creation module 132 includes information on the address Ad (vk _CI ) of the membership card issuer and the token change Tk _CNG for the address. In addition, the membership card creation transaction includes membership card issuance addresses _{CR1 to CRM} (mainly customers) addresses Ad (vk _CR1 ) to Ad (vk _CRM ), and the number of membership cards N _CR1 [MC _CI (γ)] to N _CRM [MC _CI (γ)] and member card attribute list {Attr-list} _CR1 [MC _CI (γ)] to {Attr-list} _CRM [MC _CI (γ)] Contains information.

Here, in the membership card information MC _CI (γ), “CI” is a symbol for identifying different membership cards for each member card issuer who created the membership card, and “γ” is the type of membership card ( For example, it is a symbol for identifying a different membership card for each rank (platinum card, gold card, silver card, etc.). In addition, membership card information MC _CI (γ) includes membership card type code (identifier), membership card price, membership card expiration date, terms and conditions, attribute list {Attr-list} format and its initial value, and designation. Information regarding the attribute issuer to be used and the conditions for resale.

Number of membership cards for each issuer Ad (vk _CR1 ) to Ad (vk _CRM ) in one membership card creation transaction N _CR1 [TT _PR (α)] to N _CRM [TT _PR (α)] and attribute list {Attr-list} _CR1 [MC _CI (γ)] to {Attr-list} _CRM [MC _CI (γ)] can be determined. In addition, the issue destination may be one or the member card issuer itself.

  The membership card creation transaction generated in this way is broadcast toward each terminal tool 100 in the system 10, and the book keeper records the transaction in the block chain ledger.

10. In the ticket purchase message system 10 using points , the buyer can use the points received from the producer or the like when purchasing a ticket. FIG. 12 is a conceptual diagram of generation of a ticket purchase message using points. In FIG. 12, the message is generated based on the information shown on the left side, and the result (changed information) is shown on the right side of the figure.

  The point use ticket purchase message shown in FIG. 12 is the same as the ticket purchase message shown in FIGS. 5A to 5C, but is different in that it includes information on the use of points. Only this difference will be described.

In FIG. 12, the message generation unit 114 of the buyer's terminal tool 100 generates a hash value h (MC _CI (γ) of the member card information MC _CI (γ) issued by the member card issuer when generating the point purchase ticket purchase message. )) Is required. This information is not limited, but the message generation unit 114 may automatically extract and use a transaction that is evidence of having a membership card from past transactions recorded in the transaction recording unit 119. In addition, the message generation unit 114 sets, as proof of the points used for purchase, a pair of a destination user of the past transaction that acquired the points and a hash value of the transaction {Ad (vk _PFP1 ), h (Tr _PFP1 ) }, {Ad (vk _PFP2 ), h (Tr _PFP2 )}. Further, the message generation unit 114 uses a pair {Ad (vk _PFC ), h (Tr _PFC ) as a proof that the buyer has the membership card, the address of the other user of the past transaction that acquired the membership card and the hash value of the transaction. )}. The proof of the point or the proof with the membership card is not limited, but the message generator 114 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119. Good.

In addition to the elements shown in FIGS. 5A to 5C, the result of the point use ticket purchase message generated by the message generator 114 includes the product of the number of offer tickets N _OFR and the ticket price Tk _OFR (total payment amount: N _OFR x Tk _OFR [tokens]) contains information about the value obtained by subtracting the product of the point-token rate cf _OFR and the number of points used Pt _OFR (payment amount by points: cf _OFR x Pt _OFR [tokens]) . Instead of reducing the amount to be paid with the token, information on the number of points Pt _OFR [points] is added to the seller's address Ad (vk _SR ), and further, the number of points is changed to the buyer's address Ad (vk _BR ) Pt Add information about _{OFR | CNG} [points].

11. Point-Use Ticket Purchase Transaction FIG. 13 is a conceptual diagram of generation of a point-use ticket purchase transaction. The point-use ticket purchase transaction shown in FIG. 13 is the same as the ticket purchase transaction shown in FIGS. 6A to 6C, but is different in that it includes information related to the use of points. Only this difference will be described.

In addition to the elements shown in FIGS. 6A to 6C, the point purchase ticket purchase transaction includes the number of points Pt _EXE [points] actually used for the seller's address Ad (vk _SR ) and the buyer's address Ad. For (vk _BR ), information on the point change Pt _{EXE | CNG} [points] obtained by subtracting the number Pt _EXE [points] actually used from the number of points indicated in the point evidence is also included.

12 The user who owns the point sale message point can sell the point to another user (for example, a member card issuer who issued a member card that can use the point). A user who wants to sell points (point seller) transmits a point sale message Msg _SPT to the point buyer through the terminal tool 100. The point sale message Msg _SPT is an offer message to the point buyer, and the point buyer purchases points at the point-token rate cf _OFR and exchanges them for tokens in response to the point sale message Msg _SPT . FIG. 14 is a conceptual diagram of point sale message generation. The message is generated based on the information shown on the left side of the figure, and the result (changed information) is shown on the right side of the figure.

As shown in FIG. 14, the message generation unit 114 of the terminal tool 100 of the user who sells points (point seller) has the address Ad (vk _BR ) of the point buyer and the hash value of the membership card that can use the points to be sold. Information on h (MC _CI (γ)), the point-token rate cf _OFR , the number of points to sell Pt _OFR , the minimum number of points to sell Ptmin _OFR , and the expiry date Exp _OFR of the offer is required. Such information is not limited, but is input by the user through the user I / F 121. Further, the message generation unit 114 uses, as proof that the seller has points, a pair of a destination user of a past transaction that acquired the points and a hash value of the transaction {Ad (vk _PFP1 ), h (Tr _PFP1 )} , {Ad (vk _PFP2 ), h (Tr _PFP2 )}, and the pair of the addressee user of the transaction that acquired the past token as evidence of the token possessed and the hash value of the transaction {Ad (vk _PFT1 ), h (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. Although the evidence of the token is not limited, the message generation unit 114 may automatically extract and use an appropriate one from past transactions recorded in the transaction recording unit 119. The evidence of the token is at least required as a fee to be paid to the bookkeeper when recording the point sale transaction in the blockchain ledger.

The result of the point sale message generated by the message generation unit 114 includes information regarding the point buyer's address Ad (vk _BR ) and the number of points Pt _OFR [points] toward the address. The point sale message also includes the point seller's address Ad (vk _SR ), the product of the point-token rate cf _OFR and the number of points Pt _OFR [points] and the token change Tk _{OFR | CNG} Information on the total amount (cf _OFR x Pt _OFR + Tk _{OFR | CNG} [tokens]) with [tokens] and fishing of points Pt _{OFR | CNG} [points] obtained by subtracting the number of points sold from the number of points indicated in the point evidence Is also included. In addition, when the tax bureau is participating in the system 10, the point sale message also includes information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{OFR | TAX} [tokens] by the token to that address. .

13. Point Sell Transaction When a point sell message is received at the point buyer's terminal tool 100, the buyer determines whether the point seller's offer can be followed. If it is possible, the transaction generation unit 117 of the buyer's terminal tool 100 generates a transaction that allows the sale of points (point sale transaction) and broadcasts it to each terminal tool 100 in the system 10. FIG. 15 is a conceptual diagram of the point sale transaction generation. In FIG. 15, the transaction is generated based on the information shown on the left side, and the result (changed information) is shown on the right side of the figure.

In FIG. 15, when generating the point sale transaction, the transaction generation unit 117 of the terminal tool 100 of the point buyer receives the point seller address Ad (vk _SR ), the received point sale message Msg _{SPT | SR: BR} , and Requires the seller's electronic signature Sgn (Msg _{SPT | SR: BR} ) for the message. The information is not limited, but the transaction generation unit 117 may automatically extract and use a suitable one of the messages recorded in the message recording unit 116. In addition, the transaction generation unit 117 sets a pair {Ad (vk _PFT1 ), h of the address of the partner user of the past transaction that acquired the token and the hash value of the transaction as evidence of the token for replacing the point. (Tr _PFT1 )}, {Ad (vk _PFT2 ), h (Tr _PFT2 )}. The evidence of the token is not limited, but the transaction generation unit 117 automatically extracts and uses an appropriate past transaction recorded in the transaction recording unit 119 of the terminal tool 100 of the point buyer. May be.

The transaction generation unit 117 generates a point sale transaction according to the received point sale message. The result of the point sale transaction includes an exchange from the point buyer's address Ad (vk _BR ), the number of points actually redeemed for that address Pt _EXE [points] and the token total indicated in the token evidence. Contains information about the remaining token Tk _{EXE | REM} [tokens] minus the token amount transferred to the seller at. In addition, the point sale transaction includes the seller's address Ad (vk _SR ) and the product of the point-token rate cf _EXE and the number of points Pt _EXE actually exchanged for that address (total amount of tokens to be paid) Token fishing Tk _{EXE | CNG} total (total amount of tokens the seller gets: cf _EXE x Pt _EXE + Tk _{EXE | CNG} [tokens]), and point fishing Pt _{EXE | CNG} [points]. In addition, if the tax bureau has participated in the system 10, the point sale transaction will also include information on the tax bureau address Ad (vk _TA ) and the tax amount Tk _{EXE | TAX} [tokens] with tokens towards that address. .

  The point sale transaction generated in this way is broadcast toward each terminal tool 100 in the system 10, and the book keeper records the transaction in the block chain ledger.

(Example embodiment)

The digital transaction system based on virtual currency of the present invention can be applied to general trading objects. In one aspect, the transaction object is a ticket for a music concert, a sports game or other event. In one aspect, the transaction object is a reservation right for a hotel or event venue facility. In this case, in the above embodiment, “ticket” is “reservation right of a hotel or event venue facility”, “producer” is a hotel or resort operating company, event venue operating company, etc., and “retailer” is Being a travel agency, “customers” are users of facilities at hotels and event venues and travelers to resort areas. Moreover, in one aspect, the transaction object is an air ticket (aircraft seat reservation right). In this case, in the above embodiment, the “ticket” is an air ticket, and the “producer” is an airline. In one embodiment, the transaction object is an article that is owned for a relatively long period of time, such as a work of art, a craft, or an excavated article. In this case, in the above embodiment, the “ticket” is a work of art, a craft, an antique, or an excavated item, and the “producer” is, for example, a creator of an art, craft, an antique, or a discoverer of an excavated item. . In this mode, information on ownership of arts, crafts, and excavated items is registered in the blockchain, so it can also be used as a registration system for arts, crafts, antiques, and excavated items. . Further, in one aspect, the transaction object is a mobile asset such as an airplane, a ship, a truck, a car, or a container, and the buyer or seller may be an actual buyer or seller. It may be a transferee. Similarly, in one aspect, the transaction object is a stationary asset such as land, building, house, condominium, event space, etc., and the buyer or seller may be the actual buyer or seller, or the right to use by lease etc. The person who assigns

  Blockchain ledgers can be used for ticket transactions, hotel and event venue reservation rights transactions, airline ticket transactions, arts, crafts, antiques or excavated goods transactions, and mobile and non-moving asset transactions. Accordingly, they may exist separately, or may be a single block chain ledger that integrates them.

In general, a digital transaction system based on virtual currency according to an embodiment of the present invention has the following configuration.
A digital transaction system based on virtual currency in which a plurality of terminal tools are connected via the Internet,
A first terminal tool of the plurality of terminal tools includes a creation module that generates a creation transaction including information on an assignment destination of a transaction object and an attribute list of the transaction object;
A second terminal tool of the plurality of terminal tools includes a message generation unit that generates a message (purchase message) that offers to purchase the transaction object,
A third terminal tool of the plurality of terminal tools is an assignment destination of the purchase message of the transaction object, and the ownership of the transaction object is assigned to the second terminal tool according to the purchase message. A transaction generation unit that generates a transaction to be transferred (purchase transaction)
The creation transaction and the purchase transaction are recorded in a blockchain ledger distributed and managed in the system,
The system according to claim 1, wherein the transaction object is an event ticket, a hotel or event venue reservation right, an air ticket, a work of art, a craft, an antique, an excavated article, a mobile asset, or a non-movable asset.

  The present invention is not limited to the specifically described embodiment.

10 system 100 terminal tool 111 key generation unit 112 electronic signature generation unit 113 electronic signature verification unit 114 message generation unit 115 message verification unit 116 message recording unit 117 transaction generation unit 118 transaction verification unit 119 transaction recording unit 121 user I / F
122 Internet I / F
131 Ticket creation module 132 Member card creation module 133 Attribute assignment module

Claims (8)

A digital transaction system based on virtual currency in which a plurality of terminal tools are connected via the Internet,
The first terminal tool of the plurality of terminal tools includes a ticket creation module that generates a ticket creation transaction including information on a ticket assignment destination and a ticket attribute list,
A second terminal tool of the plurality of terminal tools includes a message generation unit that generates a message offering to purchase a ticket (ticket purchase message),
A third terminal tool of the plurality of terminal tools is an assignment destination of the ticket purchase message, and a transaction (ticket purchase transaction) for transferring the ownership of the ticket to the second terminal tool according to the message. ) To generate a transaction generation unit,
The system, wherein the ticket creation transaction and the ticket purchase transaction are recorded in a blockchain ledger distributed and managed in the system.   The system of claim 1, wherein the ticket attribute list includes a ticket serial number, a venue seat designation number in the case of an event ticket, and / or a number of transfers of ownership of the ticket.   The message generation unit of the second terminal tool further provides a message (token purchase message) that offers to exchange the real currency for a virtual currency (token) used for ticket purchase in the system at a predetermined rate. The system according to claim 1 or 2, wherein:   A fourth terminal tool of the plurality of terminal tools is an assignment destination of the token purchase message, and in accordance with the message, ownership of the token of the actual currency amount to be exchanged is assigned to the second terminal tool. The system according to claim 3, further comprising a transaction generation unit that generates a transaction (token purchase transaction) to be transferred to the tool.   The third terminal tool generates a message (token sale message) that offers to exchange virtual currency (token) used for ticket purchase transaction in the system with real currency at a predetermined rate. The system of claim 4, further comprising:   The transaction generation unit of the fourth terminal tool, to which the token sale message is allocated, transfers ownership of the token to be exchanged from the third terminal tool to the fourth terminal according to the token sale message. The system according to claim 5, wherein a transaction for transferring to a tool (token sale transaction) is generated.   The system of claim 6, wherein the token purchase transaction and the token sale transaction are recorded in the blockchain ledger. The ticket creation transaction and the ticket purchase transaction are recorded in a blockchain ledger distributed and managed in the system,
The ticket is an object to be traded, various types of tickets, hotel and event venue reservation rights, air tickets, arts, crafts, antiques, excavated items, mobile assets, or non-moving assets,
The token purchase transaction and the token sale transaction are recorded in a blockchain ledger distributed and managed in the system,
The system according to claim 7, wherein the token is a virtual currency used to buy and sell a ticket that is a transaction object.