JP7402187B2 - Control method, server, and program - Google Patents

Description

The present invention relates to a control method, a server, and a program.

Patent Document 1 describes a mechanism in which purchased virtual currency depreciates over time from the time of purchase, in order to encourage users to consume virtual currency without making virtual currency an investment target. is disclosed.

Japanese Patent Application Publication No. 2016-170530

However, there is a risk that the processing of multiple servers that manage transactions of tokens such as virtual currency may become unstable.

Therefore, the present disclosure provides a control method that can stabilize the processing of each server that manages token transactions.

A control method according to one aspect of the present invention includes a plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which manages one or more distributed ledgers among the plurality of distributed ledgers. A control method executed by one of a plurality of servers, the method comprising: receiving application information including a scheduled date and time for a transaction by the first user from a terminal operated by a first user; refers to a first distributed ledger managed by a server of , and calculates a fee based on a transaction by the first user recorded in the first distributed ledger before the scheduled date and time included in the received application information. , transmitting fee information including the calculated fee to the terminal, receiving first transaction data including a first token amount indicating the amount of tokens required for the transaction corresponding to the schedule from the terminal, and receiving the received first transaction data. transferring one transaction data to a plurality of other servers different from the one server among the plurality of servers, and storing a first block including the first transaction data in the first distributed ledger, and receiving second transaction data including a second token amount indicating the amount of tokens required for the fee from a terminal, transferring the received second transaction data to the plurality of other servers, and transmitting the second transaction data to the plurality of other servers; A second block including the second block is stored in the first distributed ledger.

Note that these comprehensive or specific aspects may be realized by a system, a device, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, and the system, device, integrated circuit, computer program and a recording medium may be used in any combination.

The control method of the present disclosure can stabilize the processing of each server that manages token transactions.

FIG. 1 is a block diagram schematically showing the configuration of a transaction management system in this embodiment. FIG. 2 is a block diagram schematically showing the configuration of the server in this embodiment. FIG. 3 is an explanatory diagram showing an example of fee calculation information in this embodiment. FIG. 4 is an explanatory diagram schematically showing application transaction data in this embodiment. FIG. 5 is an explanatory diagram schematically showing payment transaction data in this embodiment. FIG. 6 is an explanatory diagram schematically showing fee transaction data in this embodiment. FIG. 7 is a flow diagram showing an example of processing of the transaction management system in this embodiment. FIG. 8 is a diagram illustrating an example of a UI displayed by the display unit of the terminal. FIG. 9 is a diagram showing a UI displayed on the display unit of the terminal. FIG. 10 is a diagram illustrating an example of a UI displayed by a display unit of a terminal. FIG. 11 is a diagram illustrating an example of a UI displayed by a display unit of a terminal. FIG. 12 is a block diagram schematically showing the configuration of a transaction management system in Modification 3. FIG. 13 is a block diagram schematically showing the configuration of a transaction management system in Modification 3. FIG. 14 is a flow diagram illustrating server processing in Modification 4. FIG. 15 is a block diagram schematically showing the configuration of a server in Modification 4 of the embodiment. FIG. 16 is an explanatory diagram showing the data structure of the blockchain. FIG. 17 is an explanatory diagram showing the data structure of transaction data.

(Findings that formed the basis of the present invention)
The present inventors have found that the following problems occur regarding the technology related to token transactions described in the "Background Art" section.

In the mechanism described in Patent Document 1, the amount of depreciation of tokens such as virtual currency over time is determined in advance, so it is difficult to control transactions depending on the transaction status. For example, if a large number of transactions are concentrated in a certain period, the processing load on multiple servers managing tokens may increase, and the processing by the multiple servers may become unstable. Also, for example, during other periods, there is a risk that no transaction will occur and transaction-related processing will not be performed on multiple servers. In this case, multiple servers will have to wait for the transaction to occur, so the Power may be consumed even though no related processing is being performed.

Therefore, the present disclosure aims to stabilize the processing of multiple servers by controlling the timing at which transactions occur so that the processing of multiple servers that manage token transactions is not concentrated in a specific period, and Provided is a control method and the like that can reduce power consumption due to transaction-related processing not being performed.

In order to solve such problems, a control method according to one aspect of the present invention includes a plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which manages token transactions using a plurality of distributed ledgers. A control method executed by one of a plurality of servers that manage one or more of the distributed ledgers, the date and time when the first user is scheduled to conduct a transaction from a terminal operated by the first user. , and refers to a first distributed ledger managed by the one server, and refers to the first distributed ledger that is recorded on the first distributed ledger before the scheduled date and time included in the received application information. A first information processing unit that calculates a fee based on a transaction by a user, transmits fee information including the calculated fee to the terminal, and sends fee information from the terminal to the terminal including a first token amount indicating the amount of tokens required for the transaction corresponding to the schedule. receiving transaction data, transferring the received first transaction data to a plurality of other servers different from the one server among the plurality of servers, and transmitting a first block including the first transaction data; receiving second transaction data stored in the first distributed ledger and including a second token amount indicating the amount of tokens required for the fee from the terminal, and transmitting the received second transaction data to the plurality of other servers; and storing a second block including the second transaction data in the first distributed ledger.

According to this, it is possible to control the timing at which transactions occur so that the processing of the plurality of servers that manage token transactions is not concentrated in a specific period. Therefore, it is possible to stabilize the processing of the plurality of servers, and to reduce power consumption due to transaction-related processing not being performed.

For example, the application information is third transaction data including the scheduled date and time, each of the plurality of distributed ledgers includes a contract code for calculating the fee based on the third transaction data, and In calculating the fee, upon receiving the third transaction data, the fee may be calculated by executing the contract code included in the first distributed ledger.

According to this, the fee can be calculated quickly and safely without the intervention of another person or other system. Therefore, the control method according to the present disclosure can reduce power consumption of multiple servers that manage token transactions.

For example, in storing the first block in the first distributed ledger, a consensus algorithm is executed together with the plurality of other servers, the first block is stored in the first distributed ledger, and the second block is stored in the first distributed ledger. In storing the second block in the first distributed ledger, a consensus algorithm may be executed together with the plurality of other servers, and the second block may be stored in the first distributed ledger.

According to this, a distributed ledger is stored after executing a consensus algorithm. Therefore, the control method according to the present disclosure can more easily manage token transactions appropriately by executing a consensus algorithm.

For example, in calculating the fee, the larger the balance of the token of the first user in the first distributed ledger, the higher the fee may be calculated.

Therefore, the first user can be urged to use the token quickly. Therefore, the timing at which a transaction occurs can be controlled.

For example, in calculating the fee, the longer the elapsed time from the timing of the previous transaction by the first user in the first distributed ledger, the higher the fee may be calculated.

Therefore, the first user can be urged to use the token quickly. Therefore, the timing at which a transaction occurs can be controlled.

For example, in calculating the fee, the smaller the average transaction amount per unit time is for the transaction by the first user in the first distributed ledger from the current time to a predetermined time, the higher the fee is calculated. Good too.

Therefore, the first user can be urged to use the token quickly. Therefore, the timing at which a transaction occurs can be controlled.

For example, the fee information may be information for displaying the fee on a display unit of the terminal.

Therefore, by displaying the fee on the display section of the terminal, it is possible to urge the first user to use the token quickly. Therefore, the timing at which a transaction occurs can be controlled.

For example, the token includes a plurality of types of tokens, the first distributed ledger includes a plurality of different sub-distributed ledgers for different types of tokens, and in calculating the fee, the schedule included in the application information is A plurality of fees are calculated for each different type of token based on transactions by the first user recorded in the plurality of sub-distributed ledgers before the date and time, and when sending the fee, the calculated fee information is used as the fee information. Information including multiple fees may be sent to the terminal.

According to this, since fees are calculated for each of a plurality of types of tokens, it is possible to adjust the transaction amount for each type of token.

For example, the fee information may be information for displaying the fee for each different type of token on the display unit of the terminal.

Therefore, by displaying the fee for each type of token on the display section of the terminal, it is possible to urge the first user to quickly use the token for each type. Therefore, it is possible to control the timing at which a transaction occurs for each type of token.

For example, the fee information may include inquiry information that asks the first user whether or not he or she agrees to the fee included in the fee information.

According to this, since it is possible to inquire of the first user whether or not he or she agrees to the fee via the terminal, the timing at which the first user uses the token can be adjusted. For example, the larger the fee amount, the sooner the tokens can be used. Therefore, the timing at which a transaction occurs can be controlled.

Further, the server according to one aspect of the present invention is a plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which manages one or more distributed ledgers among the plurality of distributed ledgers. A management unit that manages a first distributed ledger of the plurality of distributed ledgers and a terminal operated by the first user, and a server that manages a transaction by the first user from a terminal operated by the first user. application information including the scheduled date and time; first transaction data including a first token amount indicating the amount of tokens required for the transaction corresponding to the schedule from the terminal; and first transaction data indicating the amount of tokens required for the transaction from the terminal a receiving unit that receives second transaction data including an amount of 2 tokens; a calculation unit that calculates the fee based on the transaction by the first user recorded in the first user; and a transmission unit that transmits fee information including the calculated fee to the terminal, (i) the reception unit receives the first transaction data, the transmitter transfers the received first transaction data to a plurality of other servers different from the one server among the plurality of servers, and The management unit records a first block including the first transaction data in the first distributed ledger, and (ii) when the reception unit receives the second transaction data, the transmission unit records the first block including the first transaction data. 2 transaction data to the plurality of other servers, and the management unit records a second block including the second transaction data in the first distributed ledger.

According to this, it is possible to control the timing at which transactions occur so that the processing of the plurality of servers that manage token transactions is not concentrated in a specific period. Therefore, it is possible to stabilize the processing of the plurality of servers, and to reduce power consumption due to transaction-related processing not being performed.

Further, a program according to one aspect of the present invention is a program for causing a computer to execute the above control method.

The above aspect provides the same effects as the control method described above.

Note that these comprehensive or specific aspects may be realized by a system, a device, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, and the system, device, integrated circuit, computer program Alternatively, it may be realized using any combination of recording media.

Hereinafter, embodiments will be specifically described with reference to the drawings.

Note that the embodiments described below are all inclusive or specific examples. The numerical values, shapes, materials, components, arrangement positions and connection forms of the components, steps, order of steps, etc. shown in the following embodiments are merely examples, and do not limit the present invention. Further, among the constituent elements in the following embodiments, constituent elements that are not described in the independent claims indicating the most significant concept will be described as arbitrary constituent elements.

(Embodiment)
In this embodiment, a transaction management system and its control method that can stabilize the processing of a plurality of servers of a token transaction management system and reduce wasteful power consumption will be described.

FIG. 1 is a block diagram schematically showing the configuration of a transaction management system 1 in this embodiment.

As shown in FIG. 1, the transaction management system 1 includes servers 10A, 10B, and 10C, and terminals 40, 41, and 42. Each device included in the transaction management system 1 is communicably connected to each other via a network N. Network N may be comprised of any communication line or network, and includes, for example, the Internet, a mobile phone carrier network, and the like. The servers 10A, 10B, and 10C are also referred to as "servers 10A, etc."

The multiple servers 10A, 10B, and 10C manage token transactions using multiple distributed ledgers. Server 10A is one of multiple servers 10A, 10B, and 10C. Server 10A is one of a plurality of servers 10A, 10B, and 10C that hold distributed ledgers. The distributed ledger held by the server 10A stores various transaction data related to procedures or processes (application, payment, fee payment, etc.) in transactions of transaction currencies. By receiving the transaction data, the server 10A accepts procedures or processes in token transactions. Note that the token is, for example, a token. A token is value information managed by a distributed ledger, and is equivalent to money, points (royalty), gift certificates, coupons, etc., or is exchangeable.

Servers 10B and 10C are devices that each have the same functions as server 10A, and operate independently of server 10A. Note that the number of servers is not limited to three, and may be any number. Further, the servers 10A and the like are communicably connected to each other, and may be connected via a network N.

Here, as an example, a case will be explained in which the server 10A among the servers 10A, etc. receives transaction data from the terminal 40, etc., and sends notifications to the terminal 40, etc., but other servers (server 10B or 10C) may perform the above processing.

The terminal 40 is a terminal device owned by the payer U1. The terminal 40 is a terminal for applying for a token transaction, performing a token transaction, and paying a fee to the server 10A or the like. The terminal 40 receives, for example, an input indicating the scheduled date and time of the token transaction and an input indicating the scheduled transaction amount from the payer U1. The terminal 40 generates transaction data (also referred to as application transaction data or third transaction data) for applying for a transaction based on the received input, and transmits the generated application transaction data to the server 10A or the like. Specifically, the terminal 40 generates transaction data including a scheduled transaction date and time and a scheduled transaction amount as application transaction data. Note that the application transaction data only needs to include information indicating the transaction schedule, and does not need to include the transaction schedule date and time and the transaction schedule amount.

Further, the terminal 40 may receive fee information received from the server 10A, etc., and display the received fee information. That is, the fee information is information for displaying the fee on the display unit 60 (see FIG. 8) of the terminal 40. The terminal 40 also generates transaction data (also referred to as fee transaction data or second transaction data) for paying a fee to the trader X who manages transaction procedures based on the received fee information, and transmits the generated transaction data. It is transmitted to the server 10A, etc. Specifically, the terminal 40 generates transaction data including the fee amount included in the fee information as fee transaction data.

Further, the terminal 40 generates transaction data for a payment transaction (also referred to as payment transaction data or first transaction data) based on the input for the application, and transmits the generated payment transaction data to the server 10A or the like. Specifically, the terminal 40 generates, as payment transaction data, transaction data that includes a transaction date and time that is the same as the scheduled transaction date and time, and a transaction amount that is the same as the scheduled transaction amount. The fee information may include inquiry information that inquires of the payer U1, who is the user of the terminal 40, whether or not he or she agrees to the fee included in the fee information. That is, the terminal 40 may present a UI (User Interface) that inquires of the payer U1 whether or not he or she agrees to the amount of the fee included in the fee information. The terminal 40 determines whether or not an input indicating consent has been received for the presented UI, and generates fee transaction data if the input indicating consent is received, and generates fee transaction data if the input indicating consent is not received. , no fee transaction data needs to be generated.

The terminal 40 is, for example, a personal computer, a smartphone, a tablet, or the like.

The terminal 41 is a terminal device owned by a user of a payee U2 to whom payment is made in a transaction by the payer U1. The terminal 41 receives a notification from the server 10A or the like indicating that the payment for the transaction has been made. Upon receiving the notification, terminal 41 may display information indicating that payment of the payment amount included in the payment transaction data was made by payer U1 at the transaction date and time.

The terminal 41 is, for example, a personal computer, a smartphone, a tablet, or the like.

The terminal 42 is a terminal device owned by the company X. The terminal 42 receives a notification from the server 10A or the like indicating that the fee has been paid by the payer U1. Upon receiving the notification, terminal 42 may display information indicating that payment of the fee amount included in the fee transaction data was made by payer U1 at the transaction date and time.

The terminal 42 is, for example, a personal computer, a smartphone, a tablet, or the like.

The terminal 40 may further have the functions of the terminal 41 or the functions of the terminal 42. Similarly, the terminal 41 may have the functions of the terminal 40 or the functions of the terminal 42. Similarly, the terminal 42 may have the functions of the terminal 40 or the functions of the terminal 41. Each terminal 40-42 operates independently of other terminals.

Hereinafter, the configuration of the server 10A and the like included in the transaction management system 1 will be described in detail.

FIG. 2 is a block diagram schematically showing the configuration of the server 10A in this embodiment.

As shown in FIG. 2, the server 10A includes a processing section 11, a ledger management section 12, and a control section 13. The above functional units included in the server 10A can be realized by, for example, a CPU (Central Processing Unit) executing a program using a memory.

The processing unit 11 is a processing unit that manages various information using a distributed ledger. When the processing unit 11 receives transaction data from a device in the transaction management system 1 or acquires transaction data generated by the control unit 13, the processing unit 11 provides the received or acquired transaction data to the ledger management unit 12. This allows it to be stored in a distributed ledger. Transaction data includes application transaction data, payment transaction data, and fee transaction data. Details of each transaction data will be described later.

The ledger management unit 12 is a processing unit that manages a distributed ledger. Specifically, when receiving transaction data, the ledger management unit 12 transfers the received transaction data to a plurality of other servers, and stores the received transaction data in a distributed ledger. For example, the ledger management unit 12 receives payment transaction data from the terminal 40, and transfers the received payment transaction data to a plurality of other servers 10B and 10C different from the server 10A among the plurality of servers 10A, 10B, and 10C. and storing the first block containing the payment transaction data in the distributed ledger stored in the ledger storage unit 16. The ledger management unit 12 also receives fee transaction data from the terminal 40, transfers the received fee transaction data to a plurality of other servers 10B and 10C, and stores a second block containing the second transaction data in the ledger. The information is stored in the distributed ledger stored in the unit 16.

In this way, the ledger management unit 12 stores the transaction data provided from the processing unit 11 in the distributed ledger. The distributed ledger stores transaction data from the past to the present. In the distributed ledger, the transaction data is managed so as not to be tampered with, based on the characteristic that it is difficult to tamper with the information recorded in the distributed ledger.

The ledger management section 12 includes a storage section 15 and a ledger storage section 16.

The storage unit 15 is a processing unit that stores new transaction data to be stored in the distributed ledger in the ledger storage unit 16. The storage unit 15 stores new transaction data in the ledger storage unit 16 using a method according to the type of distributed ledger. Further, the storage unit 15 transmits and receives communication data to and from the storage unit 15 of another server such as the server 10A, and causes the ledger storage unit 16 of the other server to also store the new transaction data. For example, when the distributed ledger is a blockchain, the storage unit 15 generates a block containing new transaction data, synchronizes the generated block between the servers 10A, etc., and stores the block in the ledger. It is stored in section 16. For example, when storing the first block in the distributed ledger, the storage unit 15 executes a consensus algorithm together with a plurality of other servers 10B and 10C, and stores the first block in the distributed ledger. Further, for example, when storing the second block in the distributed ledger, the storage unit 15 executes a consensus algorithm together with a plurality of other servers 10B and 10C, and stores the second block in the distributed ledger.

The ledger storage unit 16 is a storage device that stores a distributed ledger. The distributed ledger stored in the ledger storage unit 16 stores one or more transaction data, and is managed using characteristics such as hash values so that it is difficult to falsify. The details will be described later.

Further, the distributed ledger stored in the ledger storage unit 16 stores in advance fee calculation information used to calculate the fee for the payment procedure by the payer. The distributed ledger also includes smart contract code for calculating fees based on application transaction data. The calculation of fees will be described later.

Note that the distributed ledger is, for example, a blockchain, and this case will be described as an example, but it is also possible to employ other types of distributed ledgers (for example, IOTA or hash graph). Note that the distributed ledger may execute a consensus algorithm (for example, PBFT (Practical Byzantine Fault Tolerance), PoW (Proof of Work), or PoS (Proof of Stake)) when storing new data. , it may not be executed. Hyperledger fabric is an example of a distributed ledger technology that does not execute a consensus algorithm.

The control unit 13 is a processing unit that controls processing related to token provision. By receiving the application transaction data from the terminal 40, the control unit 13 receives information including the date and time when the payer plans to transact the token from the terminal 40. Further, the control unit 13 refers to the distributed ledger stored in the ledger storage unit 16, and based on the transaction by the payer U1 recorded in the distributed ledger before the scheduled transaction date and time included in the application transaction data, The amount of the fee for the transaction scheduled for the payer U1 is calculated. The control unit 13 transmits fee information including the calculated fee amount to the terminal 40.

For example, the control unit 13 calculates a higher fee as the balance of the payer's token in the distributed ledger at the scheduled transaction date and time increases. Further, the control unit 13 calculates, for example, a higher fee as the time elapsed from the timing of the previous transaction by the payer in the distributed ledger increases. The elapsed time is, for example, the time from the timing of the previous transaction to the timing at which the application transaction data was received. In addition, for example, in a transaction by a payer in a distributed ledger, the control unit 13 calculates a higher fee as the average per unit time of the transaction amount in the period from the timing of receiving application transaction data to a predetermined time is smaller. do. Note that the transaction amount in a period is, for example, the total amount paid by the payer in the period. Payment may be remittance, withdrawal, transfer, etc.

Note that part or all of the above processing by the control unit 13 is performed by a smart contract realized by executing a contract code stored in the ledger storage unit 16. When the control unit 13 receives the application transaction data from the terminal 40, it calculates the fee by executing the contract code included in the distributed ledger. Contract code is code that is executed to implement a smart contract.

Below, we will explain the fees charged to the payer for transactions by the payer.

The fee charged to the payer is determined based on the fee calculation information and based on the timing of the payer's application for the transaction. Specifically, the fee is calculated based on (i) the balance of the payer's token in the distributed ledger at the timing of the application, (ii) the elapsed time since the timing of the last transaction by the payer in the distributed ledger, and (iii) the balance of the payer's token in the distributed ledger at the timing of the application. In a transaction by a payer in the ledger, the determination is made based on at least one of the average transaction amount per unit time for a period from the timing of receiving the application transaction data to a predetermined period of time before. The fee calculation information is, for example, a function or a table that defines fees.

FIG. 3 is an explanatory diagram showing an example of fee calculation information in this embodiment. The fee calculation information shown in FIG. 3 is an example of fee calculation information that defines the fee amount by a function.

In FIG. 3, the horizontal axis indicates the payer's token balance x, and the vertical axis indicates the fee amount F(x) for each balance x.

In principle, the function F(x) has a tendency to increase as x increases. In other words, the fee amount tends to increase as the balance increases. More specifically, the function F(x) is a monotonically increasing function with respect to x. However, the function F(x) may include an interval in which the value is maintained despite changes in x.

The control unit 13 determines the fee amount by calculating it as follows using the function F(x) which is the fee calculation information shown in FIG.

Hereinafter, various transaction data stored in the distributed ledger by the processing unit 11, which are (1) application transaction data, (2) payment transaction data, and (3) fee transaction data, will be explained.

(1) Application transaction data FIG. 4 is an explanatory diagram schematically showing application transaction data in this embodiment. The application transaction data is generated by the terminal 40 owned by the payer U1 when the payer U1 performs a transaction, and is transmitted to the server 10A or the like.

As shown in FIG. 4, the application transaction data includes a payer ID, a payee ID, a scheduled payment date and time, a scheduled payment amount, instructions, and a signature.

The payer ID is an identifier for uniquely identifying a payer in a transaction (payment) schedule.

The payee ID is an identifier for uniquely identifying a payee in a transaction (payment) schedule.

The scheduled payment date and time is information indicating the scheduled timing of a transaction (payment). The scheduled payment date and time indicates the date and time when the transaction is scheduled to be performed, but the scheduled time when the transaction is scheduled to be performed may not be indicated, and only the day of the date and time may be indicated.

The scheduled payment amount is information indicating the amount scheduled to be paid in the transaction. The amount is, for example, the amount of tokens.

The instruction is information for instructing the server 10A to perform calculation processing for fees related to transactions. Note that instead of the instruction, the application transaction data may include information indicating that the transaction data is application transaction data that includes information indicating that a transaction is scheduled to be performed. In this case, when the server 10A or the like receives the application transaction data, it may calculate the fee if it detects that the received transaction data includes information indicating that it is application transaction data.

The signature is an electronic signature given by the device or person who generated the application transaction data.

The application transaction data shown in FIG. 4 is application transaction data in which a payer whose payer ID is "aaa001" plans to pay to a payee whose payee ID is "bbb01." In this transaction schedule, the scheduled payment amount is "5" tokens, and the scheduled payment date and time is "2018.10.10 15:00". The signature is the electronic signature of the payer.

(2) Payment transaction data FIG. 5 is an explanatory diagram schematically showing payment transaction data in this embodiment. Payment transaction data is generated by the terminal 40 owned by the payer U1 and transmitted to the server 10A or the like when the payer U1 performs a transaction.

As shown in FIG. 5, the payment transaction data includes a payer ID, payee ID, payment date and time, payment amount, and signature.

The payer ID is an identifier for uniquely identifying a payer in a transaction (payment).

The payee ID is an identifier for uniquely identifying the payee in a transaction (payment).

The payment date and time is information indicating the timing of a transaction (payment). The payment date and time indicates the date and time when the transaction is performed, but the time at which the transaction is performed may not be indicated, and only the day of the date and time may be indicated.

The payment amount is information indicating the amount to be paid in the transaction. The amount is, for example, the amount of tokens.

A signature is an electronic signature of the device or person that generated the payment transaction data.

The payment transaction data shown in FIG. 5 is payment transaction data of a transaction in which a payer whose payer ID is "aaa001" makes a payment to a payee whose payee ID is "bbb01." In this transaction, the payment amount is "5" tokens, and the payment date and time is "2018.10.10 15:00". The signature is the electronic signature of the payer.

(3) Fee transaction data FIG. 6 is an explanatory diagram schematically showing fee transaction data in this embodiment. The fee transaction data is generated by the terminal 40 owned by the payer U1 when the payer U1 makes a transaction, and is transmitted to the server 10A or the like.

As shown in FIG. 6, the fee transaction data includes a payer ID, a payee ID, a payment date and time, a fee amount, and a signature.

The payer ID is an identifier for uniquely identifying a payer in payment of a transaction fee.

The payee ID is an identifier for uniquely identifying the payee of the transaction fee.

The payment date and time is information indicating the timing at which the transaction fee will be paid. The payment date and time indicates the date and time when the fee is paid, but the time when the fee is paid may not be indicated, and only the day of the date and time may be indicated.

The fee amount is information indicating the amount of the fee required for the transaction. The amount is, for example, the amount of tokens.

The signature is an electronic signature given by the device or person who generated the application transaction data.

The application transaction data shown in FIG. 6 is fee transaction data indicating that a payer whose payer ID is "aaa001" pays a fee to a payee whose payee ID is "fljad4019." In the payment of this fee, the payment amount is "1" token, and the scheduled payment date and time is "2018.10.10 15:00". The signature is the electronic signature of the payer.

Hereinafter, a specific example of the processing of the transaction management system 1 will be explained.

FIG. 7 is a flow diagram showing an example of processing of the transaction management system 1 in this embodiment.

The terminal 40 of the payer U1 receives an input from the payer U1 indicating the date and time of the scheduled transaction and an input indicating the amount of the scheduled transaction (S101).

The terminal 40 generates application transaction data including the scheduled transaction date and time and the scheduled transaction amount based on the received input (S102).

The terminal 40 transmits the generated application transaction data to the server 10A, etc. (S103). At this time, the terminal 40 may transmit the generated application transaction data to one server, such as the server 10A, or to a plurality of servers.

The server 10A etc. receives the application transaction data transmitted by the terminal 40 and stores it in the distributed ledger (S104).

The server 10A etc. calculates the amount of the fee required for the payment procedure by the payer U1 related to the terminal 40 that is the transmission source of the application transaction data (S105).

The server 10A or the like transmits fee information including the calculated fee amount to the terminal 40 held by the payer U1 (S106). At this time, it is not necessary for all of the plurality of servers included in the server 10A etc. to transmit fee information to the terminal 40. For example, the server that has finished calculating the fee amount may transmit fee information to the terminal 40 and also send completion information indicating that it has finished calculating the fee amount to another server. If the other servers do not transmit the fee information to the terminal 40 when receiving the completion information, they do not need to transmit the fee information to the terminal 40.

Upon receiving the fee information transmitted from the server 10A or the like, the terminal 40 causes the terminal 40 to display the fee amount included in the fee information (S107). At this time, the terminal 40 may present a UI (User Interface) that asks the payer U1 whether or not he or she agrees to the amount of the fee included in the fee information.

FIG. 8 is a diagram showing an example of the UI 50 displayed by the display unit 60 of the terminal 40.

The UI 50 includes a fee amount 51, an agree button 52 for accepting input indicating consent to the fee payment, and a disapproval button 53 for accepting input indicating not agreeing to the fee payment (disagree). including.

The terminal 40 determines whether an input indicating consent to the presented UI has been received (S108).

When the terminal 40 receives an input indicating consent (Yes at S108), for example, when it receives an input to the consent button 52 on the UI 50, the terminal 40 selects the same transaction date and time as the scheduled transaction date and time based on the input received at step S101, and , generates payment transaction data including a transaction amount that is the same as the scheduled transaction amount (S109). On the other hand, if the terminal 40 receives an input indicating disagreement, for example, if it accepts an input to the disagreement button 53 on the UI 50, or if it does not accept an input indicating agreement for a certain period of time (No in S108), Finish the processing related to the transaction. In this case, the terminal 40 may transmit end information indicating that the process has ended to the server 10A or the like. Upon receiving the termination information, the server 10A and the like terminate the processing related to the transaction. Note that the server 10A etc. is not limited to receiving termination information, but if information (for example, payment transaction data or fee transaction data) is not received from the terminal 40 for a certain period of time after transmitting fee information, the server 10A etc. Such processing may be terminated.

After step S109, the terminal 40 transmits the generated payment transaction data to the server 10A or the like (S110). At this time, the terminal 40 may transmit the generated payment transaction data to one server such as the server 10A, or to a plurality of servers.

The server 10A etc. receives the payment transaction data transmitted by the terminal 40 and stores it in the distributed ledger (S111).

The server 10A or the like notifies the terminal 41 of the payee U2 that the payment amount included in the payment transaction data has been made by the payer U1 on the transaction date and time (S112).

Further, after step S109, the terminal 40 generates fee transaction data including the amount of the fee based on the fee information (S113).

The terminal 40 transmits the generated fee transaction data to the server 10A, etc. (S114). At this time, the terminal 40 may transmit the generated fee transaction data to one server such as the server 10A, or to a plurality of servers.

The server 10A etc. receives the fee transaction data transmitted by the terminal 40 and stores it in the distributed ledger (S115).

The server 10A etc. notifies the terminal 42 of the merchant X that the payment of the fee included in the fee transaction data was made by the payer U1 on the transaction date and time (S116).

Note that step S109 may be performed after step S113, or may be performed in parallel with step S113. Moreover, step S110 may be performed after step S114, or may be performed in parallel with step S114. Moreover, step S111 may be performed after step S115, or may be performed in parallel with step S115. Moreover, step S112 may be performed after step S116, or may be performed in parallel with step S116.

As described above, according to the control method according to the present embodiment, the fee is calculated based on the transaction by the payer U1 recorded in the distributed ledger before the scheduled date and time included in the received application transaction data, Require a fee to be paid. Therefore, for example, by adjusting the size of the calculated fee amount, it is possible to control the timing at which transactions occur so that the processing of multiple servers that manage token transactions is not concentrated in a specific period. . Therefore, it is possible to stabilize the processing of the plurality of servers, and to reduce power consumption due to transaction-related processing not being performed.

Further, commission calculation can be performed quickly and safely without the intervention of another person or other system. Therefore, the control method according to the present disclosure can reduce power consumption of multiple servers that manage token transactions.

It also stores the distributed ledger after executing the consensus algorithm. Therefore, the control method according to the present disclosure can more easily manage token transactions appropriately by executing a consensus algorithm.

Furthermore, in calculating the fee, the larger the token balance of the payer U1 in the distributed ledger is, the higher the fee is calculated. Furthermore, in calculating the fee, the longer the time elapsed from the timing of the previous transaction by the payer U1 in the distributed ledger, the higher the fee is calculated. Furthermore, in calculating the fee, in a transaction by the payer U1 in the distributed ledger, the smaller the average per unit time of the transaction amount in the period from the current time to a predetermined time before, the higher the fee is calculated. Therefore, the less the payer U1 uses the token, the higher the fee can be demanded. Therefore, the payer U1 can be urged to use the token early, and the timing at which the transaction occurs can be controlled.

Further, the fee information is information for displaying the fee on the display unit 60 of the terminal 40. Therefore, by displaying the fee on the display unit 60 of the terminal 40, the payer U1 can be urged to use the token quickly. Therefore, the timing at which a transaction occurs can be controlled.

The fee information also includes inquiry information that inquires of the payer U1 whether he or she agrees to the fee included in the fee information. According to this, it is possible to inquire of the payer U1 whether or not he agrees to the fee via the terminal 40, so it is possible to adjust the timing at which the payer U1 uses the token. For example, the larger the fee amount, the sooner the tokens can be used. Therefore, the timing at which a transaction occurs can be controlled.

(Modification 1)
In the above embodiment, the token may include multiple types of tokens. That is, the transaction management system 1 may manage transactions of multiple types of tokens. In this case, the distributed ledger held by the server 10A etc. includes a plurality of different sub-distributed ledgers for different types of tokens. For example, when there are two types of tokens A and B, the distributed ledger includes a sub-distributed ledger A that indicates transactions for token A, and a sub-distributed ledger B that indicates transactions for token B.

In calculating the fee (S105), the control unit 13 of the server 10A etc. uses different types of tokens based on the transactions by the payer U1 recorded in the plurality of sub-distributed ledgers before the scheduled date and time included in the application information. Calculate multiple fees for each transaction. For example, the control unit 13 calculates the fee A for the transaction of the token A based on the transaction of the token A by the payer U1 recorded in the sub-distributed ledger A before the scheduled date and time included in the application information. Along with this, the control unit 13 calculates a fee B for the transaction of token B based on the transaction of token B by payer U1 recorded in sub-distributed ledger B before the scheduled date and time included in the application information. .

In addition, in calculating the fee, if the amount of circulation of token A is large and the amount of circulation of token B is small compared to token A, the control unit 13 performs a transaction of token B in order to increase the amount of circulation of token B. The fee for the transaction may be lower than the fee for the transaction of token A. Here, the amount of circulation may be, for example, the average amount of transactions by a plurality of users per unit time during a period from the current time to a predetermined time ago. The amount of transactions by multiple users may be the total amount of transactions of all users using a specific type of token. The average may be an average per user in addition to an average per unit time. Making the fees for transactions of Token B lower than the fees for transactions of Token A means that when the value of Token A and the value of Token B are compared using a common value, when converted to that value. This is to calculate the value of token B so that it is less than the value of token A. In addition, in this case, for example, in calculating the fee, the relationship indicating the fee calculation information for calculating the fee for token B is more common than the relationship indicating the fee calculation information for calculating the fee for token A. Even if you adjust the fee amount in value conversion to be smaller for any balance, any elapsed time, or any average, and calculate the fee for token A and the fee for token B using the two adjusted relationships. good. In the adjustment, for example, by multiplying the fee amount in the relationship of token B by a coefficient smaller than 1, the relationship of token B may be made smaller than the relationship of token A, or the fee amount in the relationship of token A may be made smaller than the relationship of token A. By multiplying by a large coefficient, the relationship for token B may be made smaller than the relationship for token A. In addition, in the adjustment, for example, by subtracting a predetermined fee amount from the fee amount in the relationship of token B (that is, offsetting it in the negative direction), even if the relationship of token B is made smaller than the relationship of token A. Alternatively, the relationship of token B may be made smaller than the relationship of token A by adding a predetermined fee amount to the fee amount in the relationship of token A (that is, offset in the positive direction).

In transmitting the fee (S106), the control unit 13 transmits information including the plurality of calculated fees, that is, the fee A and the fee B, to the terminal 40 as fee information. In this way, since fees are calculated for each of multiple types of tokens, it is possible to adjust the transaction amount for each type of token.

When the terminal 40 receives the fee information transmitted from the server 10A or the like, the terminal 40 displays the fee amount included in the fee information on the display unit 60 of the terminal 40 for each different type of token (S107). That is, the fee information is information for displaying the fee for each different type of token on the display unit 60 of the terminal 40. Therefore, by displaying the fee for each type of token on the display section of the terminal, it is possible to urge the payer U1 to use the tokens for each type quickly. Therefore, it is possible to control the timing at which a transaction occurs for each type of token.

FIG. 9 is a diagram showing an example of the UI 50A displayed on the display unit 60 of the terminal 40.

The UI 50A displays the fee A required for the transaction of the token A. The UI 50A includes an amount 51A of the fee A, an agree button 52A for accepting an input indicating consent to the payment of the fee A, and an agree button 52A for accepting an input indicating not agreeing to the payment of the fee A (disagree). It includes an consent button 53A and a switching button 54A for switching the display to UI 50B that displays fee B.

When the terminal 40 receives an input indicating consent to the fee A of the token A, for example, when receiving an input to the consent button 52A on the UI 50A, the terminal 40 selects a transaction date and time that is the same as the scheduled transaction date and time based on the input received in step S101. , and generating payment transaction data including a transaction amount equal to the scheduled transaction amount. The generated payment transaction data further includes information indicating that token A is used in the transaction. On the other hand, if the terminal 40 receives an input indicating disagreement, for example, if it accepts an input to the disagreement button 53A on the UI 50A, or if it does not accept an input indicating consent for a certain period of time, the terminal 40 performs processing related to the transaction. or switch the display to UI 50B that displays fee B.

FIG. 10 is a diagram showing an example of the UI 50B displayed on the display unit 60 of the terminal 40.

The UI 50B displays the fee B required for the transaction of the token B. The UI 50B includes an amount 51B of fee B, an agree button 52B for accepting input indicating consent to the payment of fee B, and an agree button 52B for accepting input indicating not agreeing to the payment of fee B (disagree). It includes a consent button 53B and a switching button 54B that switches the display to the UI 50A that displays the fee A.

When the terminal 40 receives an input indicating consent to the fee B of the token B, for example, when receiving an input to the consent button 52B on the UI 50B, the terminal 40 selects the same transaction date and time as the scheduled transaction date and time based on the input received in step S101. , and generating payment transaction data including a transaction amount equal to the scheduled transaction amount. The generated payment transaction data further includes information indicating that token B is used in the transaction. On the other hand, if the terminal 40 receives an input indicating disagreement, for example, if it accepts an input to the disagreement button 53B on the UI 50B, or if it does not accept an input indicating consent for a certain period of time, the terminal 40 performs processing related to the transaction. or switch the display to UI 50A that displays fee A.

Note that when terminating the process, the terminal 40 may transmit termination information indicating that the process has ended to the server 10A or the like. Upon receiving the termination information, the server 10A and the like terminate the processing related to the transaction. Note that the server 10A etc. is not limited to receiving termination information, but if information (for example, payment transaction data or fee transaction data) is not received from the terminal 40 for a certain period of time after transmitting fee information, the server 10A etc. Such processing may be terminated.

FIG. 11 is a diagram showing the UI 50C displayed by the display unit 60 of the terminal 40. UI50C is a UI in a different example from UI50A and UI50B.

The UI 50C displays the fee A required for the transaction of token A, which has a better fee (that is, cheaper) between token A and token B. The UI 50C includes an amount 51C of the fee C, an agree button 52C for accepting an input indicating consent to the payment of the fee C, and an agree button 52C for accepting an input indicating not agreeing to the payment of the fee C (disagree). and an agree button 53C. Note that the UI 50C may further include a switching button for switching the display to a UI that displays the fee B.

Note that each UI may further include a message indicating the reason for calculating the fee to be presented. The message may indicate, for example, that the proposed fee was calculated because the balance of the payer's token in the distributed ledger at the scheduled transaction date and time is a predetermined balance. In this case, the message may indicate that the lower the token balance, the lower the fee. The message may also indicate that the proposed fee was calculated because, for example, a predetermined amount of time has elapsed since the timing of the last transaction by the payer in the distributed ledger. In this case, the message may indicate that the shorter the elapsed time, the lower the fee. In addition, the message may be sent, for example, because in a transaction by a payer in a distributed ledger, the average transaction amount per unit time for a period from the timing of receiving application transaction data to a predetermined time is a predetermined average value. , may indicate that the proposed fee has been calculated. In this case, the message may indicate that the higher the average value, the lower the fee.

(Modification 2)
In this modification, another configuration of the transaction management system of each of the above embodiments will be described.

FIG. 12 is a block diagram schematically showing the configuration of the transaction management system 2 in this modification.

As shown in FIG. 12, the transaction management system 2 includes servers 10A, 10B, and 10C, and terminals 40, 41, and 42. Each device included in the transaction management system 2 is communicably connected to each other via a network N. Network N may be comprised of any communication line or network, and includes, for example, the Internet, a mobile phone carrier network, and the like.

In particular, in the transaction management system 2, servers 10A, 10B, and 10C are connected to each other via a network N. Further, a terminal 40 is connected to the server 10A, a terminal 41 is connected to the server 10B, and a terminal 42 is connected to the server 10C.

Such a configuration can be used, for example, when a plurality of organizations operate the transaction management system 2 and the servers managed by each organization are connected via the network N. For example, the server 10A and the terminal 40 belong to the group A, the server 10B and the terminal 41 belong to the group B, and the server 10C and the terminal 42 belong to the group C.

The operations of the server 10A, etc. and the terminal 40, etc. are the same as in each of the embodiments described above, so a description thereof will be omitted.

(Modification 3)
In this modification, another configuration of the transaction management system of each of the above embodiments will be described.

FIG. 13 is a block diagram schematically showing the configuration of the transaction management system 3 in this modification.

As shown in FIG. 13, the transaction management system 3 includes a server 10D and terminals 40, 41, and 42. Each device included in the transaction management system 3 is communicably connected to each other via a network N. Network N may be comprised of any communication line or network, and includes, for example, the Internet, a mobile phone carrier network, and the like.

In particular, in the transaction management system 3, a server 10D and terminals 40 and 41 are connected to each other via a network N. Further, a terminal 42 is connected to the server 10D. In this case, the server 10D and the terminals 40 and 41 each operate as the server 10A in each of the above embodiments.

Such a configuration is applicable, for example, when one or more organizations and one or more individuals operate the transaction management system 3, and servers or terminals managed by each organization or each individual are connected via the network N. can be used for. For example, the server 10D and the terminal 42 belong to an organization D, and the transaction management system 3 is operated by the organization D and the individual payer U1 and payee U2.

The operations of the server 10A, etc. and the terminal 40, etc. are the same as in each of the embodiments described above, so a description thereof will be omitted.

(Modification 4)
Here, a fourth modification of the embodiment will be described.

FIG. 14 is a flow diagram showing the processing of the server in this modification.

As shown in FIG. 14, the server 10A etc. receives application information including the date and time when the payer U1 plans to conduct the transaction from the terminal 40 operated by the payer U1 as the first user (S201).

Each of the servers 10A to 10C refers to the first distributed ledger managed by the server, and charges fees based on transactions by the payer U1 recorded in the first distributed ledger before the scheduled date and time included in the received application information. is calculated (S202).

Each of the servers 10A to 10C transmits fee information including the calculated fee to the terminal 40 (S203).

Each of the servers 10A to 10C receives first transaction data including a first amount of tokens indicating the amount of tokens involved in a transaction corresponding to a transaction schedule from the terminal 40, and transfers the received first transaction data to the plurality of servers 10A to 10C. 10C to a plurality of other servers different from the server (the server that is the subject of processing in step S204), and store the first block containing the first transaction data in the first distributed ledger (S204 ).

Each of the servers 10A to 10C receives second transaction data including a second token amount indicating the amount of tokens required for the fee from the terminal 40, transfers the received second transaction data to a plurality of other servers, and A second block including second transaction data is stored in the first distributed ledger (S205).

This makes it possible to control the timing at which transactions occur so that the processes of the multiple servers that manage token transactions are not concentrated in a specific period. Therefore, it is possible to stabilize the processing of the plurality of servers, and to reduce power consumption due to transaction-related processing not being performed.

FIG. 15 is a block diagram schematically showing the configuration of a server in Modification 4 of the embodiment.

As shown in FIG. 15, in a transaction management system including a plurality of servers holding distributed ledgers, one server 60A among the plurality of servers includes a processing section 61 and a control section 63.

The processing unit 61 receives application information including the scheduled date and time of the transaction by the payer U1 from the terminal 40 operated by the payer U1 as the first user.

The control unit 63 refers to the first distributed ledger managed by the server and calculates the fee based on the transaction by the payer U1 recorded in the first distributed ledger before the scheduled date and time included in the received application information. do. The control unit 63 transmits fee information including the calculated fee to the terminal 40.

The processing unit 61 further receives first transaction data including a first token amount indicating the amount of tokens required for the transaction corresponding to the transaction schedule from the terminal 40, and transmits the received first transaction data to the plurality of servers 10A to 10A. 10C to a plurality of other servers different from the server (the server including the processing unit 61), and store the first block containing the first transaction data in the first distributed ledger. Further, the processing unit 61 further receives second transaction data including a second token amount indicating the amount of tokens required for the fee from the terminal 40, transfers the received second transaction data to a plurality of other servers, and storing a second block including second transaction data in the first distributed ledger.

This makes it possible to control the timing at which transactions occur so that the processes of the multiple servers that manage token transactions are not concentrated in a specific period. Therefore, it is possible to stabilize the processing of the plurality of servers, and to reduce power consumption due to transaction-related processing not being performed.

(supplement)
The blockchain in each of the above embodiments or modified examples will be supplementarily explained.

FIG. 16 is an explanatory diagram showing the data structure of the blockchain.

A blockchain is a chain of blocks, which are its recording units. Each block has a plurality of transaction data and a hash value of the immediately previous block. Specifically, block B2 includes the hash value of the previous block B1. Then, a hash value calculated from the plurality of transaction data included in block B2 and the hash value of block B1 is included in block B3 as the hash value of block B2. In this way, by connecting blocks in a chain while including the contents of the previous block as a hash value, falsification of recorded transaction data is effectively prevented.

If past transaction data is changed, the hash value of the block will become a different value than before the change, and in order to make the tampered block appear to be correct, all subsequent blocks must be recreated, which requires a lot of work. is extremely difficult in reality. Using this property, blockchain is guaranteed to be difficult to tamper with.

FIG. 17 is an explanatory diagram showing the data structure of transaction data.

The transaction data shown in FIG. 17 includes a transaction body P1 and an electronic signature P2. The transaction body P1 is the data body included in the transaction data. The electronic signature P2 is generated by signing the hash value of the transaction body P1 with the signature key of the creator of the transaction data, or more specifically, by encrypting it with the private key of the creator. be.

Since the transaction data has the electronic signature P2, it is virtually impossible to tamper with it. This prevents falsification of the transaction body.

Note that in the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory. Here, the software that implements the content management system of the above embodiment is the following program.

That is, this program provides a computer with a plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which manages one or more distributed ledgers among the plurality of distributed ledgers. A control method executed by one of the servers, wherein application information including a scheduled date and time of a transaction by the first user is received from a terminal operated by a first user; calculates a fee based on a transaction by the first user recorded in the first distributed ledger before the scheduled date and time included in the received application information, with reference to a first distributed ledger managed by transmitting fee information including the fee charged to the terminal to the terminal, receiving first transaction data including a first token amount indicating the amount of tokens required for the transaction corresponding to the schedule from the terminal, and receiving the received first transaction; transmitting data to a plurality of other servers different from the one server among the plurality of servers, storing a first block including the first transaction data in the first distributed ledger, and transmitting the data from the terminal receiving second transaction data including a second token amount indicating the amount of tokens required for the fee, transferring the received second transaction data to the plurality of other servers, and including the second transaction data; This is a program that executes a control method for storing a second block in the first distributed ledger.

Although the fund management system and the like according to one or more aspects have been described above based on the embodiments, the present invention is not limited to these embodiments. Unless departing from the spirit of the present invention, various modifications that can be thought of by those skilled in the art to this embodiment, and embodiments constructed by combining components of different embodiments are within the scope of one or more embodiments. may be included within.

The present disclosure can be used in transaction management systems that manage token transactions.

1-3 Transaction management system 10A-10C, 60A Server 11, 61 Processing section 12 Ledger management section 13, 63 Control section 15 Storage section 16 Ledger storage section 40-42 Terminal 50, 50A-50C UI (User Interface)
51, 51A-51C Fee amount 52, 52A-52C Agree button 53, 53A-53C Disagree button 54A, 54B Switch button B1, B2, B3 Block N Network U1 Payer U2 Payee X Vendor

Claims (12)

A plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which is executed by one of the plurality of servers that manages one or more distributed ledgers of the plurality of distributed ledgers. A control method comprising:
receiving application information including the date and time when the first user plans to conduct the transaction from a terminal operated by the first user;
Referring to a first distributed ledger managed by the one server, a fee is charged based on a transaction by the first user recorded in the first distributed ledger before the scheduled date and time included in the received application information. Calculate,
transmitting fee information including the calculated fee to the terminal;
receiving first transaction data including a first token amount indicating the amount of tokens involved in the transaction corresponding to the schedule from the terminal, and transmitting the received first transaction data to the one server of the plurality of servers; transfers the first block including the first transaction data to a plurality of different other servers, and stores the first block including the first transaction data in the first distributed ledger;
receiving second transaction data including a second token amount indicating the amount of tokens required for the fee from the terminal, transferring the received second transaction data to the plurality of other servers, and transmitting the second transaction data to the plurality of other servers; A control method comprising: storing a second block containing data in the first distributed ledger. The application information is third transaction data including the scheduled date and time,
Each of the plurality of distributed ledgers includes a contract code for calculating the fee based on the third transaction data,
The control method according to claim 1, wherein in calculating the fee, when the third transaction data is received, the fee is calculated by executing the contract code included in the first distributed ledger. Storing the first block in the first distributed ledger involves executing a consensus algorithm together with the plurality of other servers and storing the first block in the first distributed ledger;
The control according to claim 1 or 2, wherein in storing the second block in the first distributed ledger, a consensus algorithm is executed together with the plurality of other servers, and the second block is stored in the first distributed ledger. Method. The control method according to any one of claims 1 to 3, wherein in calculating the fee, the larger the balance of the token of the first user in the first distributed ledger, the higher the fee is calculated. The control method according to any one of claims 1 to 4, wherein in calculating the fee, the longer the elapsed time from the timing of the previous transaction by the first user in the first distributed ledger, the higher the fee is calculated. . In calculating the fee, the fee is calculated such that the smaller the average per unit time of the transaction amount in the period from the current time to a predetermined time before in the transaction by the first user in the first distributed ledger, the higher the fee is calculated. 5. The control method according to any one of 5 to 5. The control method according to any one of claims 1 to 6, wherein the fee information is information for displaying the fee on a display unit of the terminal. The token includes multiple types of tokens,
The first distributed ledger includes a plurality of different sub-distributed ledgers for different types of tokens,
In calculating the fees, multiple fees are calculated for different types of tokens based on transactions by the first user that are recorded in the plurality of sub-distributed ledgers before the scheduled date and time included in the application information. ,
The control method according to any one of claims 1 to 6, wherein in transmitting the fee, information including the calculated plurality of fees is transmitted to the terminal as the fee information. The control method according to claim 8, wherein the fee information is information for displaying the fee for each different type of token on a display unit of the terminal. The control method according to any one of claims 1 to 9, wherein the fee information includes inquiry information that asks the first user whether or not he or she agrees to the fee included in the fee information. A plurality of servers that manage token transactions using a plurality of distributed ledgers, each of which is one of the plurality of servers that manage one or more distributed ledgers among the plurality of distributed ledgers. hand,
a management unit that manages a first distributed ledger among the plurality of distributed ledgers;
Application information including a scheduled date and time for a transaction by the first user is sent from a terminal operated by the first user, and application information including a first token amount indicating the amount of tokens required for the transaction corresponding to the schedule is sent from the terminal. a receiving unit that receives one transaction data and second transaction data including a second amount of tokens indicating an amount of tokens required for a fee from the terminal;
Referring to the first distributed ledger in the management unit, the fee is paid based on the transaction by the first user recorded in the first distributed ledger before the scheduled date and time included in the received application information. A calculation unit that calculates;
a transmitting unit that transmits fee information including the calculated fee to the terminal,
(i) When the receiving unit receives the first transaction data, the transmitting unit transmits the received first transaction data to a plurality of other servers different from the one server among the plurality of servers. and the management unit records a first block including the first transaction data in the first distributed ledger;
(ii) When the receiving unit receives the second transaction data, the transmitting unit transfers the received second transaction data to the plurality of other servers, and the managing unit transfers the second transaction data to the second transaction data. A server that records a second block containing transaction data on the first distributed ledger. A program for causing a computer to execute the control method according to claim 1.

Images