WO2020162515A1 - 制御方法、サーバ、および、プログラム - Google Patents

制御方法、サーバ、および、プログラム Download PDF

Info

Publication number
WO2020162515A1
WO2020162515A1 PCT/JP2020/004453 JP2020004453W WO2020162515A1 WO 2020162515 A1 WO2020162515 A1 WO 2020162515A1 JP 2020004453 W JP2020004453 W JP 2020004453W WO 2020162515 A1 WO2020162515 A1 WO 2020162515A1
Authority
WO
WIPO (PCT)
Prior art keywords
fee
transaction
transaction data
distributed ledger
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2020/004453
Other languages
English (en)
French (fr)
Inventor
勇二 海上
淳児 道山
雄揮 廣瀬
哲司 渕上
大森　基司
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN202080012331.0A priority Critical patent/CN113383358A/zh
Priority to JP2020571245A priority patent/JP7402187B2/ja
Publication of WO2020162515A1 publication Critical patent/WO2020162515A1/ja
Priority to US17/392,687 priority patent/US20210365936A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention relates to a control method, a server, and a program.
  • Patent Document 1 in virtual currency, in order to encourage the user to consume the virtual currency without making the virtual currency an investment target, the purchased virtual currency depreciates with the passage of time from the time of purchase of the virtual currency. Is disclosed.
  • the present disclosure provides a control method and the like that can stabilize the processing of each server that manages token transactions.
  • a control method is a plurality of servers that manage token transactions using a plurality of distributed ledgers, each managing one or more distributed ledgers of the plurality of distributed ledgers.
  • Transmitting the fee information including the calculated fee to the terminal receiving from the terminal the first transaction data including the first token amount indicating the amount of tokens involved in the transaction corresponding to the schedule, and receiving the first transaction data.
  • Second transaction data including a second token amount indicating a token amount for the fee is received from a terminal, the received second transaction data is transferred to the plurality of other servers, and the second transaction data is received.
  • the second block including the is stored in the first distributed ledger.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program. It may be realized by any combination of the recording medium and the recording medium.
  • 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 the transaction management system in this embodiment.
  • FIG. 2 is a block diagram schematically showing the configuration of the server according to the present embodiment.
  • FIG. 3 is an explanatory diagram showing an example of the fee calculation information according to the present embodiment.
  • FIG. 4 is an explanatory diagram schematically showing the application transaction data in the present embodiment.
  • FIG. 5 is an explanatory diagram schematically showing payment transaction data according to the present embodiment.
  • FIG. 6 is an explanatory diagram schematically showing the fee transaction data in the present embodiment.
  • FIG. 7 is a flow chart showing an example of processing of the transaction management system in the present embodiment.
  • FIG. 8 is a diagram illustrating an example of a UI displayed on 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 on the display unit of the terminal.
  • FIG. 11 is a diagram showing an example of a UI displayed on the display unit of the terminal.
  • FIG. 12 is a block diagram schematically showing the configuration of the transaction management system in Modification 3.
  • FIG. 13 is a block diagram schematically showing the configuration of the transaction management system in Modification 3.
  • FIG. 14 is a flowchart showing the processing of the server in the modification 4.
  • FIG. 15 is a block diagram schematically showing the configuration of the server in Modification 4 of the embodiment.
  • FIG. 16 is an explanatory diagram showing the data structure of the block chain.
  • FIG. 17 is an explanatory diagram showing the data structure of transaction data.
  • the present disclosure aims to stabilize the processing of the plurality of servers by controlling the timing when the transactions occur so that the processing of the plurality of servers that manage the transaction of the token is not biased to a specific period, and A control method and the like that can reduce consumption of power without performing processing relating to transactions.
  • a control method is a plurality of servers that manage a transaction of tokens by using a plurality of distributed ledgers, each of which has a plurality of distributed ledgers.
  • a control method executed by one of a plurality of servers that manage one or more distributed ledgers, of which the date and time when the first user plans to make a transaction from a terminal operated by the first user The first distributed ledger managed by the one server is received, and the first distributed ledger recorded on the first distributed ledger before the scheduled date and time included in the received application information is received.
  • a first token amount that includes calculating a fee based on a transaction by a user, transmitting fee information including the calculated fee to the terminal, and indicating a token amount for a transaction corresponding to the schedule from the terminal
  • Receiving transaction data transferring the received first transaction data to a plurality of other servers different from the one server of the plurality of servers, and including a first block including the first transaction data.
  • the second transaction data which is stored in the first distributed ledger and includes the second token amount indicating the amount of tokens for the fee, is received from the terminal, and the received second transaction data is transmitted to the plurality of other servers.
  • the second block which is transferred and includes the second transaction data, is stored 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 fee may be calculated by executing the contract code included in the first distributed ledger.
  • control method can reduce power consumption of a plurality of servers that manage token transactions.
  • a consensus algorithm is executed together with the plurality of other servers to store the first block in the first distributed ledger and in the second block.
  • a consensus algorithm may be executed together with the plurality of other servers to store the second block in the first distributed ledger.
  • the distributed ledger is stored after executing the consensus algorithm. Therefore, the control method according to the present disclosure can appropriately manage the token transaction more appropriately by executing the consensus algorithm.
  • a higher fee may be calculated as the balance of the token of the first user in the first distributed ledger increases.
  • a higher fee may be calculated as the elapsed time from the last transaction timing by the first user in the first distributed ledger is longer.
  • the fee information may be information for displaying the fee on the display unit of the terminal.
  • the first user can be prompted to use the token early. Therefore, the timing at which a transaction occurs can be controlled.
  • the token includes a plurality of types of tokens
  • the first distributed ledger includes a plurality of sub distributed ledger different for each type of tokens
  • the schedule included in the application information Based on the transaction by the first user recorded in the plurality of sub-distributed ledgers before the date and time, a plurality of fees are calculated for each token of different types, and in the transmission of the fees, the fees are calculated as the fee information.
  • Information including a plurality of fees may be transmitted to the terminal.
  • the fee information may be information for displaying the fee for each different type of token on the display unit of the terminal.
  • the first user can be encouraged to use the token quickly for each type. Therefore, it is possible to control the timing at which a transaction occurs for each type of token.
  • the fee information may include inquiry information for inquiring of the first user whether to agree with the fee included in the fee information.
  • the timing at which the first user uses the token since it is possible to inquire the first user via the terminal whether or not to agree to the fee, it is possible to adjust the timing at which the first user uses the token. For example, the greater the fee amount, the earlier the token can be used. Therefore, the timing at which a transaction occurs can be controlled.
  • a server is a plurality of servers that manage token transactions using a plurality of distributed ledgers, and each manages one or more distributed ledgers of the plurality of distributed ledgers. Which is one of the plurality of servers, which manages a first distributed ledger of the plurality of distributed ledger, and a terminal operated by the first user, and makes a transaction by the first user.
  • Application information including the scheduled date and time, first transaction data including the first token amount indicating the amount of tokens for the transaction corresponding to the schedule from the terminal, and first token data indicating the amount of tokens for the commission from the terminal.
  • the receiving unit that receives the second transaction data including the amount of 2 tokens, and the first distributed ledger in the management unit are referred to, and the first distributed ledger is included before the scheduled date and time included in the received application information.
  • the receiving unit which includes: a calculating unit that calculates the fee based on the transaction by the first user recorded in 1.; and a transmitting unit that transmits fee information including the calculated fee to the terminal.
  • the transmission unit transfers the received first transaction data to a plurality of other servers different from the one server of 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 causes the transmission unit to receive the received first block.
  • the two transaction data are transferred to the other servers, and the management unit records the second block including the second transaction data in the first distributed ledger.
  • a program according to one aspect of the present invention is a program for causing a computer to execute the above control method.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • it may be realized by any combination of recording media.
  • FIG. 1 is a block diagram schematically showing the configuration of the transaction management system 1 in this embodiment.
  • the transaction management system 1 includes servers 10A, 10B and 10C, and terminals 40, 41 and 42.
  • the devices included in the transaction management system 1 are communicably connected to each other via a network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the servers 10A, 10B, and 10C are also referred to as "server 10A and the like".
  • the multiple servers 10A, 10B, and 10C manage token transactions using multiple distributed ledgers.
  • the server 10A is one of the plurality of servers 10A, 10B, and 10C.
  • the server 10A is one of the plurality of servers 10A, 10B, and 10C holding the distributed ledger.
  • the distributed ledger held by the server 10A stores various transaction data relating to procedures or processing (application, payment, payment of fees, etc.) in transaction of transaction currency. By receiving the transaction data, the server 10A receives the procedure or process in the token transaction.
  • the token is, for example, a token.
  • the token is value information managed by the distributed ledger, corresponds to money, points (royalties), gift certificates or coupons, or can be exchanged.
  • Each of the servers 10B and 10C is a device having the same function as the server 10A, and operates independently of the server 10A. Note that the number of servers is not limited to three and may be any number.
  • the servers 10A and the like are communicably connected to each other, and may be connected via the network N.
  • the server 10A receives transaction data from the terminal 40 or the like or sends a notification to the terminal 40 or the like, but another server (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, token transaction, and payment of a fee to the server 10A or the like.
  • the terminal 40 accepts, 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 the transaction application based on the received input, and transmits the generated application transaction data to the server 10A or the like.
  • the terminal 40 generates transaction data including the planned transaction date and time and the planned transaction amount as the application transaction data.
  • the application transaction data need only include the information indicating the transaction schedule, and need not include the transaction scheduled date and time and the transaction transaction amount.
  • the terminal 40 may receive the fee information received from the server 10A or the like 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. Further, the terminal 40 generates transaction data (also referred to as fee transaction data or second transaction data) for paying the trader X who manages the transaction procedure based on the received fee information, and generates the generated transaction data. It is transmitted to the server 10A or the like. Specifically, the terminal 40 generates transaction data including the amount of the fee included in the fee information as the fee transaction data.
  • the fee transaction data also referred to as fee transaction data or second transaction data
  • the terminal 40 generates transaction data for payment transaction (also referred to as payment transaction data, first transaction data) based on the input for 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 including the same transaction date and time as the scheduled transaction date and time, and the transaction amount of the same amount as the scheduled transaction amount.
  • the fee information may include inquiry information for inquiring of the payer U1 who is the user of the terminal 40 whether to agree with the fee included in the fee information. That is, the terminal 40 may present a UI (User Interface) for inquiring the payer U1 whether or not to agree with 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 when the input indicating consent is received, the fee transaction data is generated, and when the input indicating consent is not received. , It is not necessary to generate fee transaction data.
  • the terminal 40 is, for example, a personal computer, a smartphone, a tablet, or the like.
  • the terminal 41 is a terminal device possessed by the user of the payment destination U2, which is the payment destination for the transaction by the payer U1.
  • the terminal 41 receives, from the server 10A or the like, a notification indicating that payment for the transaction has been made.
  • the terminal 41 may display information indicating that the payment amount included in the payment transaction data has been paid by the 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 trader X.
  • the terminal 42 receives from the server 10A or the like a notification indicating that the payer U1 has paid the fee.
  • the terminal 42 may display information indicating that the amount of the fee included in the fee transaction data was paid by the 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 function of the terminal 41 and may have the function of the terminal 42.
  • the terminal 41 may have the function of the terminal 40, or may have the function of the terminal 42.
  • the terminal 42 may have the function of the terminal 40 or may have the function of the terminal 41.
  • Each of the terminals 40 to 42 operates independently of the other terminals.
  • FIG. 2 is a block diagram schematically showing the configuration of the server 10A in this embodiment.
  • the server 10A includes a processing unit 11, a ledger management unit 12, and a control unit 13.
  • the functional unit included in the server 10A can be realized by, for example, a CPU (Central Processing Unit) executing a program using a memory.
  • a CPU Central Processing Unit
  • the processing unit 11 is a processing unit that manages various information by a distributed ledger.
  • the processing unit 11 provides the received or acquired transaction data to the ledger management unit 12 when the transaction data is received from the device in the transaction management system 1 or when the transaction data generated by the control unit 13 is acquired. It is stored in the distributed ledger.
  • the 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 the distributed ledger. Specifically, when receiving the 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 the 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. Then, the first block including the payment transaction data is stored in the distributed ledger stored in the ledger storage unit 16.
  • the ledger management unit 12 receives the fee transaction data from the terminal 40, transfers the received fee transaction data to the plurality of other servers 10B and 10C, and stores the second block including the second transaction data in the ledger.
  • the data is stored in the distributed ledger stored in the section 16.
  • the ledger management unit 12 stores the transaction data provided by the processing unit 11 in the distributed ledger. Transaction data from the past to the present is stored in the distributed ledger. 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 unit 12 has a storage unit 15 and a ledger storage unit 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 by a method according to the type of distributed ledger.
  • the storage unit 15 also transmits/receives communication data to/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 store the new transaction data.
  • the distributed ledger is a block chain
  • the storage unit 15 generates a block including new transaction data, synchronizes the generated block with the server 10A, and stores the block in the ledger. It is stored in the section 16.
  • the storage unit 15 executes the consensus algorithm together with the 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 the consensus algorithm together with the 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 so as to be difficult to tamper with by using a characteristic such as a hash value. The details will be described later.
  • the distributed ledger stored in the ledger storage unit 16 fee calculation information used for calculating a fee for performing a payment procedure by a payer is stored in advance.
  • the distributed ledger also contains a smart contract code for calculating fees based on the application transaction data. The calculation of the fee will be described later.
  • the distributed ledger is, for example, a block chain, and this case will be described as an example, but a distributed ledger of another method (for example, IOTA or hash graph) can be adopted.
  • 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. , May not be executed.
  • PBFT Practice Byzantine Fault Tolerance
  • PoW Proof of Work
  • PoS Proof of Stake
  • Hyperledger fabric As an example of the distributed ledger technology that does not execute the consensus algorithm, there is Hyperledger fabric.
  • 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 from the terminal 40 the information including the date and time when the payer is expected to make a token transaction. 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 to be performed by the payer U1 is calculated. The control unit 13 sends the fee information including the calculated fee amount to the terminal 40.
  • the control unit 13 calculates, for example, a higher fee as the balance of payer tokens 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 elapsed time from the previous transaction timing by the payer in the distributed ledger is longer. The elapsed time is, for example, the time from the last transaction timing to the timing when the application transaction data is received. Further, for example, in the transaction by the payer in the distributed ledger, the control unit 13 calculates a higher fee as the average of the transaction amount per unit time in the period from the timing of receiving the application transaction data to the predetermined time period is smaller. To do.
  • the transaction volume during the period is, for example, the total amount of payments made by the payer during the period. The payment may be remittance, withdrawal, transfer, or the like.
  • control unit 13 executes the contract code included in the distributed ledger to calculate the fee.
  • the contract code is the code executed to realize the smart contract.
  • the fee charged to the payer is determined based on the fee calculation information and the timing of the transaction application by the payer. Specifically, the fee is (i) the balance of the payer's token in the distributed ledger at the timing of application, (ii) the elapsed time from the last transaction timing by the payer in the distributed ledger, and (iii) the distribution In the transaction by the payer in the ledger, it is determined based on at least one of the average per unit time of the transaction amount in the period from the timing of receiving the application transaction data to the predetermined time.
  • the fee calculation information is, for example, a function or table that defines fees.
  • FIG. 3 is an explanatory diagram showing an example of fee calculation information in the present embodiment.
  • the fee calculation information shown in FIG. 3 is an example of fee calculation information that defines a fee amount by a function.
  • the horizontal axis shows the payer token balance x
  • the vertical axis shows the commission amount F(x) at each balance x.
  • the function F(x) generally 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 a section in which the value is maintained with respect to the change of x.
  • the control unit 13 determines by calculating the amount of commission as follows using the function F(x) which is the commission calculation information shown in FIG.
  • FIG. 4 is an explanatory diagram schematically showing application transaction data in the present embodiment.
  • the application transaction data is generated by the terminal 40 owned by the payer U1 and transmitted to the server 10A or the like.
  • the application transaction data includes a payer ID, a payee ID, a planned payment date and time, a planned payment amount, an instruction, and a signature.
  • the payer ID is an identifier for uniquely identifying the payer in the transaction (payment) schedule.
  • the payee ID is an identifier for uniquely identifying the payee in the transaction (payment) schedule.
  • the scheduled payment date and time is information indicating the timing of the scheduled transaction (payment). Although the scheduled payment date and time indicates the date and time when the transaction is scheduled to be performed, 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 planned payment amount is information indicating the amount 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 calculate the transaction fee.
  • the application transaction data may include information indicating that the transaction data is application transaction data including information indicating that a transaction will be scheduled, instead of the instruction.
  • the server 10A or the like may calculate the fee when it detects that the received transaction data includes information indicating that the 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 indicating that the payer whose payer ID is “aaa001” will pay to the payee whose payee ID is “bbb01”.
  • the planned payment amount is “5” tokens
  • the planned payment date and time is “2018.10.10 15:00”.
  • the signature is the electronic signature of the payer.
  • FIG. 5 is an explanatory diagram schematically showing payment transaction data in the present embodiment.
  • the payment transaction data is generated by the terminal 40 owned by the payer U1 and transmitted to the server 10A or the like.
  • the payment transaction data includes a payer ID, a payee ID, a payment date and time, a payment amount, and a signature.
  • the payer ID is an identifier for uniquely identifying the payer in the transaction (payment).
  • the payee ID is an identifier for uniquely identifying the payee in the transaction (payment).
  • the payment date and time is information indicating the timing of the transaction (payment).
  • the payment date and time indicates the date and time at which the transaction is made, but the time and date at which the transaction is made may not be indicated, and only the day of the date and time may be indicated.
  • the payment amount is information indicating the amount paid in 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 payment transaction data.
  • the payment transaction data shown in FIG. 5 is payment transaction data of a transaction in which the payer whose payer ID is “aaa001” pays to the payee whose payee ID is “bbb01”. In this transaction, the payment amount is “5” token, and the payment date and time is “2018.10.10 15:00”.
  • the signature is the electronic signature of the payer.
  • FIG. 6 is an explanatory diagram schematically showing fee transaction data in the present embodiment.
  • the fee transaction data is generated by the terminal 40 owned by the payer U1 and transmitted to the server 10A or the like.
  • the fee transaction data includes a payer ID, a payee ID, a payment date and time, a fee amount, and a signature.
  • Payer ID is an identifier for uniquely identifying the payer in the payment of transaction fees.
  • 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 of payment of transaction fees. Although the date and time when the fee is paid is shown as the payment date and time, the time when the fee is paid may not be shown, and only the day of the date and time may be shown.
  • the fee amount is information indicating the amount of the transaction fee.
  • 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 the payer whose payer ID is “aaa001” pays a commission to the 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.
  • FIG. 7 is a flow chart showing an example of processing of the transaction management system 1 in the present embodiment.
  • the terminal 40 of the payer U1 accepts an input indicating the scheduled transaction date and time and an input indicating the scheduled transaction amount from the payer U1 (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 of the servers 10A or the like, or may transmit to the plurality of servers.
  • the server 10A or the like receives the application transaction data transmitted by the terminal 40 and stores it in the distributed ledger (S104).
  • the server 10A or the like calculates the amount of the fee required to perform 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 the fee information including the calculated fee amount to the terminal 40 owned by the payer U1 (S106).
  • all of the plurality of servers included in the server 10A or the like may not transmit the fee information to the terminal 40.
  • the server that has finished calculating the amount of the fee may transmit the fee information to the terminal 40, and may also transmit the completion information indicating that the amount of the fee has been calculated to another server.
  • the other server may not transmit the fee information to the terminal 40 if the fee information is not transmitted to the terminal 40 when the completion information is received.
  • 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 amount of the fee included in the fee information (S107). At this time, the terminal 40 may present a UI (User Interface) for inquiring of the payer U1 whether to agree with the amount of the fee included in the fee information.
  • UI User Interface
  • 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 agreement button 52 for accepting an input indicating that the payment of the fee is agreed, and a disagree button 53 for accepting an input indicating that the payment of the fee is not agreed (disagree).
  • the terminal 40 determines whether or not an input indicating consent has been received for the presented UI (S108).
  • the terminal 40 When the terminal 40 receives an input indicating consent (Yes in S108), for example, when the UI 50 receives an input to the consent button 52, the same transaction date and time as the scheduled transaction date and time based on the input received in step S101, and , Payment transaction data including the same transaction amount as the expected transaction amount is generated (S109).
  • the terminal 40 receives an input indicating disagreement, for example, an input to the disagreement button 53 in the UI 50, or an input indicating consent is not received for a certain period of time (No in S108)
  • the processing relating to the transaction is completed. In this case, the terminal 40 may send the end information indicating that the processing has ended to the server 10A or the like.
  • the server 10A or the like Upon receiving the termination information, the server 10A or the like terminates the processing relating to the transaction. It should be noted that the server 10A and the like are not limited to receiving the end information, and if the information (for example, payment transaction data or fee transaction data) is not received from the terminal 40 for a certain period after transmitting the fee information, the server 10A or the like takes the transaction. The processing may be ended.
  • the terminal 40 transmits the generated payment transaction data to the server 10A or the like (S110). At this time, the terminal 40 may send the generated payment transaction data to one of the servers 10A or the like, or may send it to a plurality of servers.
  • the server 10A or the like 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 paid by the payer U1 at the transaction date and time (S112).
  • 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 of the servers 10A or the like, or to a plurality of servers.
  • the server 10A or the like receives the fee transaction data transmitted by the terminal 40 and stores it in the distributed ledger (S115).
  • the server 10A or the like notifies the terminal 42 of the trader X that the payment of the amount of the fee included in the fee transaction data was made by the payer U1 at the transaction date and time (S116).
  • step S109 may be performed after step S113, or may be performed in parallel with step S113.
  • step S110 may be performed after step S114, or may be performed in parallel with step S114.
  • step S111 may be performed after step S115, or may be performed in parallel with step S115.
  • step S112 may be performed after step S116, or may be performed in parallel with step S116.
  • 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, Request to pay a fee. Therefore, for example, by adjusting the amount of the calculated fee amount, it is possible to control the timing of the transaction so that the processes of the plurality of servers that manage the token transaction are not biased to a specific period. .. Therefore, it is possible to stabilize the processing of a plurality of servers and reduce the consumption of electric power without performing the processing related to the transaction.
  • control method can reduce power consumption of a plurality of servers that manage token transactions.
  • the distributed ledger is stored after executing the consensus algorithm. Therefore, the control method according to the present disclosure can appropriately manage the token transaction more appropriately by executing the consensus algorithm.
  • the higher the token balance of the payer U1 in the distributed ledger the higher the fee is calculated.
  • a higher fee is calculated as the elapsed time from the previous transaction timing by the payer U1 in the distributed ledger is longer.
  • the higher the fee is calculated. Therefore, the payer U1 can request a high fee so that the payer U1 does not use the token. Therefore, the payer U1 can be urged to use the token early, and the timing when the transaction occurs can be controlled.
  • 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, it is possible to urge the payer U1 to quickly use the token. Therefore, the timing at which a transaction occurs can be controlled.
  • the fee information includes inquiry information for inquiring the payer U1 whether to agree with the fee included in the fee information. According to this, since it is possible to inquire the payer U1 via the terminal 40 whether or not to agree to the fee, the timing at which the payer U1 uses the token can be adjusted. For example, the greater the fee amount, the earlier the token can be used. Therefore, the timing at which a transaction occurs can be controlled.
  • the token may include multiple types of tokens. That is, the transaction management system 1 may manage transactions of a plurality of types of tokens.
  • the distributed ledger held by the server 10A or the like includes a plurality of sub-distributed ledger different for each different type of token. For example, when there are two types of token A and token B, the distributed ledger includes a sub-distributed ledger A indicating a transaction of the token A and a sub-distributed ledger B indicating a transaction of the token B.
  • the control unit 13 of the server 10A or the like based on the transaction by the payer U1 recorded in the plurality of sub distributed ledgers before the scheduled date and time included in the application information, different types of tokens. Calculate multiple fees for each. 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. At the same time, the control unit 13 calculates the fee B for the transaction of the token B based on the transaction of the token B by the payer U1 recorded in the sub distributed ledger B before the scheduled date and time included in the application information. ..
  • the control unit 13 calculates the transaction amount of the token B in order to increase the distribution amount of the token B. May be less than the transaction fee for the token A.
  • the distribution volume may be, for example, an average of transaction volumes by a plurality of users per unit time in a period from the present time to a predetermined time ago.
  • the transaction volume by a plurality of users may be the sum of the transaction volumes of all users who are using a particular type of token.
  • the average may be an average of users per person in addition to the average per unit time.
  • To make the transaction fee for the token B less than the transaction fee for the token A means that the value of the token A and the value of the token B are the same when compared with a common value for comparison. It is calculated so that the value of token B is less than the value of token A. Further, in this case, for example, in the calculation of the fee, the relationship indicating the fee calculation information for calculating the fee for the token B is more common than the relationship indicating the fee calculation information for calculating the fee for the token A. Even if the commission amount for the value conversion of is adjusted to be small for any balance, any elapsed time, or any average, and the commission of token A and the commission of token B are calculated using the two adjusted relations. Good.
  • the relationship of token B may be made smaller than the relationship of token A by multiplying the amount of charge of 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 by multiplying by a large coefficient. In the adjustment, for example, even if the relationship of the token B is made smaller than the relationship of the token A by subtracting a predetermined amount of the charge from the relationship of the token B (that is, offsetting in the negative direction).
  • the relationship of the token B may be made smaller than the relationship of the token A by adding a predetermined amount of the charge to the relationship of the token A (that is, offsetting in the positive direction).
  • the control unit 13 transmits, as the fee information, a plurality of calculated fees, that is, information including the fee A and the fee B to the terminal 40. In this way, since the fee is calculated for each of a plurality of types of tokens, the transaction amount can be adjusted for each type of token.
  • the terminal 40 Upon receiving the fee information transmitted from the server 10A or the like, the terminal 40 displays the amount of the fee included in the fee information on the display unit 60 of the terminal 40 for each token of a different type (S107). That is, the fee information is information for displaying the fee on the display unit 60 of the terminal 40 for each token of a different type. Therefore, by displaying the fee for each type of token on the display unit of the terminal, it is possible to prompt the payer U1 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.
  • FIG. 9 is a diagram showing an example of the UI 50A displayed by the display unit 60 of the terminal 40.
  • the UI 50A displays the fee A for the transaction of token A.
  • the UI 50A includes an amount 51A of the fee A, an agreement button 52A for receiving an input indicating that the payment of the fee A is agreed, and an unacceptable input for indicating that the payment of the fee A is not agreed (disagree).
  • a consent button 53A and a switching button 54A for switching the display to the UI 50B displaying the fee B are included.
  • the terminal 40 When the terminal 40 receives an input indicating the consent of the token A to the fee A, for example, when the UI 50A receives an input to the consent button 52A, the same transaction date and time as the scheduled transaction date and time based on the input accepted in step S101. , And payment transaction data including the same transaction amount as the planned transaction amount. The generated payment transaction data further includes information indicating that token A will be used in the transaction.
  • the terminal 40 receives an input indicating disagreement, for example, an input to the disagreement button 53A in the UI 50A, or when an input indicating consent is not received for a certain period of time, the process related to the transaction. Or the display is switched to the UI 50B displaying the fee B.
  • FIG. 10 is a diagram showing an example of the UI 50B displayed by the display unit 60 of the terminal 40.
  • the UI 50B displays the fee B for the transaction of token B.
  • the UI 50B includes an amount 51B of the fee B, an agreement button 52B for accepting an input indicating that the user agrees to pay the fee B, and an input for accepting an input indicating that he/she does not agree to pay the fee B (disagree).
  • An agreement button 53B and a switching button 54B for switching the display to the UI 50A displaying the fee A are included.
  • the terminal 40 When the terminal 40 receives an input indicating consent to the fee B of the token B, for example, an input to the consent button 52B in the UI 50B, the same transaction date and time as the scheduled transaction date and time based on the input accepted in step S101. , And payment transaction data including the same transaction amount as the planned transaction amount. The generated payment transaction data further includes information indicating that token B will be used in the transaction.
  • the terminal 40 receives an input indicating disagreement, for example, an input to the disagreement button 53B in the UI 50B, or an input indicating consent is not received for a certain period of time, the process related to the transaction. Or the display is switched to the UI 50A displaying the fee A.
  • the terminal 40 may send the end information indicating that the process has ended to the server 10A or the like.
  • the server 10A or the like terminates the processing relating to the transaction. It should be noted that the server 10A and the like are not limited to receiving the end information, and if the information (for example, payment transaction data or fee transaction data) is not received from the terminal 40 for a certain period after transmitting the fee information, the server 10A or the like takes the transaction. The processing may be ended.
  • FIG. 11 is a diagram showing a UI 50C displayed on the display unit 60 of the terminal 40.
  • the UI 50C is a UI different from the UI 50A and the UI 50B.
  • the UI50C displays the fee A for the transaction of token A, which is the cheaper fee (that is, cheaper) of token A and token B.
  • the UI 50C includes an amount 51C of the fee C, an agreement button 52C for accepting an input indicating that the user agrees to pay the fee C, and an input for accepting an input indicating that he/she does not agree to pay the fee C (disagree).
  • a consent button 53C is included.
  • the UI 50C may further include a switching button for switching the display to the UI for displaying the fee B.
  • each UI may further include a message indicating the reason why the fee to be presented has been calculated.
  • the message may indicate, for example, that the offered fee has been calculated because the payer's token balance in the distributed ledger is a predetermined balance at the scheduled transaction date and time. In this case, the message may indicate that the smaller the token balance, the cheaper the fee. Further, the message may indicate that the presented fee has been calculated, for example, because the elapsed time from the previous transaction timing by the payer in the distributed ledger is a predetermined elapsed time. In this case, the message may indicate that the shorter the elapsed time, the cheaper the fee.
  • the message is, for example, in the transaction by the payer in the distributed ledger, because the average of the transaction amount per unit time in the period from the timing of receiving the application transaction data to the predetermined time is the predetermined average value. , May indicate that the presented fee has been calculated. In this case, the message may indicate that the higher the average value, the cheaper the fee.
  • FIG. 12 is a block diagram schematically showing the configuration of the transaction management system 2 in this modification.
  • the transaction management system 2 includes servers 10A, 10B and 10C, and terminals 40, 41 and 42.
  • the devices included in the transaction management system 2 are communicably connected to each other via a network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the servers 10A, 10B and 10C are connected to each other via the network N.
  • a terminal 40 is connected to the server 10A
  • a terminal 41 is connected to the server 10B
  • a terminal 42 is connected to the server 10C.
  • Such a configuration can be used, for example, when a plurality of groups operate the transaction management system 2 and when connecting servers managed by the respective groups via the network N.
  • the server 10A and the terminal 40 belong to the group A
  • the server 10B and the terminal 41 belong to the group B
  • the server 10C and the terminal 42 belong to the group C.
  • FIG. 13 is a block diagram schematically showing the configuration of the transaction management system 3 in this modification.
  • the transaction management system 3 includes a server 10D and terminals 40, 41 and 42.
  • the devices included in the transaction management system 3 are communicably connected to each other via a network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of mobile phones, and the like.
  • the server 10D and the terminals 40 and 41 are connected to each other via the network N. Further, the terminal 42 is connected to the server 10D.
  • the server 10D and the terminals 40 and 41 each operate as the server 10A and the like in each of the above embodiments.
  • the server 10D and the terminal 42 belong to the group D, and the group D and individual payers U1 and payees U2 operate the transaction management system 3.
  • FIG. 14 is a flowchart showing the processing of the server in this modification.
  • the server 10A or the like receives the application information including the date and time when the payer U1 is scheduled to make a 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 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. 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 the first transaction data including the first token amount indicating the amount of tokens for the transaction corresponding to the transaction schedule from the terminal 40, and receives the received first transaction data from the plurality of servers 10A to 10C.
  • the first block including the first transaction data is transferred to a plurality of other servers different from the server (the server serving as the main body of the processing in step S204) of 10C, and is stored in the first distributed ledger (S204). ).
  • Each of the servers 10A to 10C receives the second transaction data including the second token amount indicating the amount of tokens for the fee from the terminal 40, transfers the received second transaction data to a plurality of other servers, and The second block including the second transaction data is stored in the first distributed ledger (S205).
  • FIG. 15 is a block diagram schematically showing the configuration of the server according to the fourth modification of the embodiment.
  • one server 60A of the plurality of servers includes a processing unit 61 and a control unit 63.
  • the processing unit 61 receives, from the terminal 40 operated by the payer U1 as the first user, application information including the date and time on which the payer U1 is scheduled to make a transaction.
  • 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. To do.
  • the control unit 63 transmits the fee information including the calculated fee to the terminal 40.
  • the processing unit 61 further receives, from the terminal 40, the first transaction data including the first token amount indicating the amount of tokens for the transaction corresponding to the transaction schedule, and receives the received first transaction data from the plurality of servers 10A to 10A.
  • the first block including the first transaction data is transferred to a plurality of other servers different from the server (the server including the processing unit 61) of 10C, and is stored in the first distributed ledger.
  • the processing unit 61 further receives from the terminal 40 the second transaction data including the second token amount indicating the amount of tokens for the fee, and transfers the received second transaction data to a plurality of other servers, Further, the second block including the second transaction data is stored in the first distributed ledger.
  • FIG. 16 is an explanatory diagram showing the data structure of the block chain.
  • a block chain is one in which blocks, which are the recording units, are connected in a chain.
  • Each block has a plurality of transaction data and the hash value of the immediately preceding block.
  • the block B2 includes the hash value of the previous block B1.
  • the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2.
  • 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 a digital signature P2.
  • the transaction body P1 is a 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, more specifically, by encrypting with the private key of the creator. is there.
  • each component may be configured by 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 in a recording medium such as a hard disk or a semiconductor memory.
  • the software that realizes the content management system and the like of the above embodiment is the following program.
  • this program is a plurality of servers that manage a transaction of tokens by using a plurality of distributed ledgers in a computer, each of which manages a plurality of distributed ledgers of the plurality of distributed ledgers.
  • the first transaction data including the first token amount indicating the amount of tokens involved in the transaction corresponding to the schedule is received from the terminal, the fee information including the above-mentioned fee is transmitted to the terminal, and the received first transaction is received.
  • the present disclosure can be used for a transaction management system that manages token transactions.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Databases & Information Systems (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

制御方法は、端末（４０）から、取り引きを行う予定の日時を含む申し込み情報を受信し（Ｓ２０１）、分散台帳を参照し、申し込み情報に含まれる予定の日時以前に分散台帳に記録されている第１ユーザによる取り引きに基づいて手数料を算出し（Ｓ２０２）、算出した手数料を含む手数料情報を端末（４０）に送信し（Ｓ２０３）、取り引きにかかる第１トークン量を含む第１トランザクションデータを受信し、第１トランザクションデータを複数のサーバのうちの一のサーバ（１０Ａ）とは異なる複数の他のサーバ（１０Ｂ、１０Ｃ）に転送し、かつ、第１トランザクションデータを含む第１ブロックを分散台帳に格納し（Ｓ２０４）、手数料にかかる第２トークン量を含む第２トランザクションデータを受信し、受信した第２トランザクションデータを複数の他のサーバに転送し、かつ、第２トランザクションデータを含む第２ブロックを分散台帳に格納する（Ｓ２０５）。

Description

制御方法、サーバ、および、プログラム
　本発明は、制御方法、サーバ、および、プログラムに関する。
　特許文献１には、仮想通貨において、仮想通貨を投資対象とさせずにユーザに仮想通貨の消費を促すために、仮想通貨の購入時からの時間の経過とともに、購入した仮想通貨が減価する仕組みについて開示されている。
特開２０１６－１７０５３０号公報
　しかしながら、仮想通貨などのトークンの取引を管理する複数のサーバの処理が不安定になるおそれがある。
　そこで、本開示は、トークンの取引を管理する各サーバの処理を安定化することができる制御方法などを提供する。
　本発明の一態様に係る制御方法は、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の制御方法は、トークンの取引を管理する各サーバの処理を安定化することができる。
図１は、本実施の形態における取引管理システムの構成を模式的に示すブロック図である。 図２は、本実施の形態におけるサーバの構成を模式的に示すブロック図である。 図３は、本実施の形態における手数料算出情報の一例を示す説明図である。 図４は、本実施の形態における申込トランザクションデータを模式的に示す説明図である。 図５は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。 図６は、本実施の形態における手数料トランザクションデータを模式的に示す説明図である。 図７は、本実施の形態における取引管理システムの処理の一例を示すフロー図である。 図８は、端末の表示部が表示するＵＩの一例を示す図である。 図９は、端末の表示部が表示するＵＩを示す図である。 図１０は、端末の表示部が表示するＵＩの一例を示す図である。 図１１は、端末の表示部が表示するＵＩの一例を示す図である。 図１２は、変形例３における取引管理システムの構成を模式的に示すブロック図である。 図１３は、変形例３における取引管理システムの構成を模式的に示すブロック図である。 図１４は、変形例４におけるサーバの処理を示すフロー図である。 図１５は、実施の形態の変形例４におけるサーバの構成を模式的に示すブロック図である。 図１６は、ブロックチェーンのデータ構造を示す説明図である。 図１７は、トランザクションデータのデータ構造を示す説明図である。
　（本発明の基礎となった知見）
　本発明者は、「背景技術」の欄において記載した、トークンの取り引きに関する技術に関し、以下の問題が生じることを見出した。
　特許文献１に記載の仕組みでは、時間の経過に応じた仮想通貨などのトークンの減価量が予め定められているため、取り引きの状況に応じて取り引きの制御が難しい。例えば、ある期間に多くの取り引きが集中した場合、トークンを管理している複数のサーバの処理負荷が増加して複数のサーバによる処理が不安定になるおそれがある。また、例えば、他の期間では取り引きが生じずに取り引きに関する処理が複数のサーバで行われないおそれがあり、この場合、複数のサーバは、取り引きが発生するのを待機することとなるため、取り引きに関する処理が行われていないのにもかかわらず電力を消費するおそれがある。
　そこで、本開示は、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することで、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる制御方法などを提供する。
　このような問題を解決するために、本発明の一態様に係る制御方法は、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する。
　これによれば、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
　例えば、前記申し込み情報は、前記予定の日時を含む第３トランザクションデータであり、前記複数の分散台帳のそれぞれは、前記第３トランザクションデータに基づいて前記手数料を算出するためのコントラクトコードを含み、前記手数料の算出では、前記第３トランザクションデータを受信すると、前記第１分散台帳に含まれる前記コントラクトコードを実行することで前記手数料を算出してもよい。
　これによれば、手数料の算出を、他の人または他のシステムを介在することなく、早期かつ安全に実行することができる。よって、本開示に係る制御方法は、トークンの取り引きを管理する複数のサーバの消費電力を削減することができる。
　例えば、前記第１ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第１ブロックを前記第１分散台帳に格納し、前記第２ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第２ブロックを前記第１分散台帳に格納してもよい。
　これによれば、コンセンサスアルゴリズムの実行を経て分散台帳を格納する。よって、本開示に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、トークンの取り引きを適切に管理することができる。
　例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザの前記トークンの残高が多いほど高い額の手数料を算出してもよい。
　このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
　例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出してもよい。
　このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
　例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出してもよい。
　このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
　例えば、前記手数料情報は、前記端末の表示部に前記手数料を表示させるための情報であってもよい。
　このため、手数料を端末の表示部に表示させることで、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
　例えば、前記トークンは、複数種類のトークンを含み、前記第１分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含み、前記手数料の算出では、前記申し込み情報に含まれる前記予定の日時以前に前記複数のサブ分散台帳に記録されている前記第１ユーザによる取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出し、前記手数料の送信では、前記手数料情報として、算出した前記複数の手数料を含む情報を前記端末に送信してもよい。
　これによれば、複数種類のトークン毎に手数料を算出するため、トークンの種類毎に取引量の調整を行うことができる。
　例えば、前記手数料情報は、前記端末の表示部に、異なる種類のトークン毎に前記手数料を表示させるための情報であってもよい。
　このため、トークンの種類毎に手数料を端末の表示部に表示させることで、第１ユーザに種類毎にトークンを早く使用するように促すことができる。よって、トークンの種類毎に取り引きが発生するタイミングを制御することができる。
　例えば、前記手数料情報は、前記第１ユーザに前記手数料情報に含まれる前記手数料に同意するか否かを問い合わせる問い合わせ情報を含んでもよい。
　これによれば、端末を介して、手数料に同意するか否かを第１ユーザに問い合わせることができるため、第１ユーザがトークンを使用するタイミングを調整することができる。例えば、手数料の額を大きくするほどトークンを使用するタイミングを早めることができる。よって、取り引きが発生するタイミングを制御することができる。
　また、本発明の一態様にかかるサーバは、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバであって、前記複数の分散台帳のうちの第１分散台帳を管理する管理部と、第１ユーザにより操作された端末から、前記第１ユーザにより取り引きを行う予定の日時を含む申し込み情報と、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータと、前記端末から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータとを受信する受信部と、前記管理部における前記第１分散台帳を参照し、受信された前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて前記手数料を算出する算出部と、前記端末に算出した前記手数料を含む手数料情報を送信する送信部と、を備え、（ｉ）前記受信部が前記第１トランザクションデータを受信すると、前記送信部は、受信された前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記管理部は、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に記録し、（ｉｉ）前記受信部が前記第２トランザクションデータを受信すると、前記送信部は、受信された前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記管理部は、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に記録する。
　これによれば、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
　また、本発明の一態様に係るプログラムは、上記の制御方法をコンピュータに実行させるためのプログラムである。
　上記態様により、上記制御方法と同様の効果を奏する。
　なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態について、図面を参照しながら具体的に説明する。
　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
　（実施の形態）
　本実施の形態において、トークンの取引管理システムの複数のサーバの処理の安定化、および、無駄な電力消費の低減を図ることができる取引管理システムおよびその制御方法などについて説明する。
　図１は、本実施の形態における取引管理システム１の構成を模式的に示すブロック図である。
　図１に示されるように、取引管理システム１は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１および４２とを備える。取引管理システム１が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいう。
　複数のサーバ１０Ａ、１０Ｂ及び１０Ｃは、複数の分散台帳を利用してトークンの取引を管理する。サーバ１０Ａは、複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、取り引き通貨の取り引きにおける手続または処理（申込、支払い、手数料の支払いなど）に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、トークンの取り引きにおける手続または処理を受け付ける。なお、トークンは、例えば、トークンである。トークンは、分散台帳により管理されている価値情報であり、金銭、ポイント（ロイヤリティ）、商品券またはクーポン等に相当し、又は、交換可能である。
　サーバ１０Ｂ及び１０Ｃは、それぞれ、サーバ１０Ａと同じ機能を有する装置であり、サーバ１０Ａとは独立に動作する。なお、サーバの台数は、３に限られず、複数であればよい。また、サーバ１０Ａ等同士は、通信可能に接続されており、ネットワークＮを介して接続されていてもよい。
　ここでは例として、サーバ１０Ａ等のうち、サーバ１０Ａが端末４０等からトランザクションデータを受信したり、端末４０等に通知を送信したりする場合を説明するが、他のサーバ（サーバ１０Ｂまたは１０Ｃ）が上記の処理を行ってもよい。
　端末４０は、支払者Ｕ１が保有する端末装置である。端末４０は、サーバ１０Ａ等に対してトークンの取り引きの申し込み、トークンの取り引き、および、手数料の支払いを行うための端末である。端末４０は、例えば、トークンの取り引きの予定日時を示す入力、および、取り引き予定額を示す入力を支払者Ｕ１から受け付ける。端末４０は、受け付けた入力に基づいて、取り引きの申込のためのトランザクションデータ（申込トランザクションデータ、第３トランザクションデータともいう）を生成し、生成した申込トランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、取り引き予定日時、および、取り引き予定額を含むトランザクションデータを、申込トランザクションデータとして生成する。なお、申込トランザクションデータは、取り引き予定を示す情報を含んでいればよく、取り引き予定日時および取り引き予定額を含んでいなくてもよい。
　また、端末４０は、サーバ１０Ａ等から受信した手数料情報を受信し、受信した手数料情報を表示してもよい。つまり、手数料情報は、端末４０の表示部６０（図８参照）に手数料を表示させるための情報である。また、端末４０は、受信した手数料情報に基づいて手数料を取り引きの手続きを管理する業者Ｘに支払うためのトランザクションデータ（手数料トランザクションデータ、第２トランザクションデータともいう）を生成し、生成したトランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、手数料情報に含まれる手数料の額を含むトランザクションデータを、手数料トランザクションデータとして生成する。
　また、端末４０は、申し込みのための入力に基づいて支払い取り引きのためのトランザクションデータ（支払トランザクションデータ、第１トランザクションデータともいう）を生成し、生成した支払トランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含むトランザクションデータを、支払トランザクションデータとして生成する。手数料情報は、端末４０のユーザである支払者Ｕ１に手数料情報に含まれる手数料に同意するか否かを問い合わせる問い合わせ情報を含んでいてもよい。つまり、端末４０は、手数料情報に含まれる手数料の額に同意するか否かを支払者Ｕ１に問い合わせるＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）を提示してもよい。端末４０は、提示したＵＩに対して同意を示す入力を受け付けたか否かを判定し、同意を示す入力を受け付けた場合に、手数料トランザクションデータを生成し、同意を示す入力を受け付けなかった場合に、手数料トランザクションデータを生成しなくてもよい。
　端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
　端末４１は、支払者Ｕ１による取り引きによる支払いが行われる先である支払先Ｕ２のユーザが保有する端末装置である。端末４１は、取り引きによる支払いが行われたことを示す通知をサーバ１０Ａ等から受信する。端末４１は、通知を受信すると、支払トランザクションデータに含まれる支払額の支払いが支払者Ｕ１によって取り引き日時に行われたことを示す情報を表示してもよい。
　端末４１は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
　端末４２は、業者Ｘが保有する端末装置である。端末４２は、支払者Ｕ１による手数料の支払いが行われたことを示す通知をサーバ１０Ａ等から受信する。端末４２は、通知を受信すると、手数料トランザクションデータに含まれる手数料の額の支払いが支払者Ｕ１によって取り引き日時に行われたことを示す情報を表示してもよい。
　端末４２は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
　端末４０は、さらに、端末４１の機能を有していてもよいし、端末４２の機能を有していてもよい。同様に、端末４１は、端末４０の機能を有していてもよいし、端末４２の機能を有していてもよい。同様に、端末４２は、端末４０の機能を有していてもよいし、端末４１の機能を有していてもよい。各端末４０～４２は、他の端末とは独立に動作する。
　以降において、取引管理システム１が備えるサーバ１０Ａ等の構成について詳細に説明する。
　図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。
　図２に示されるように、サーバ１０Ａは、処理部１１と、台帳管理部１２と、制御部１３とを備える。サーバ１０Ａが備える上記機能部は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）がメモリを用いてプログラムを実行することで実現され得る。
　処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、取引管理システム１内の装置からトランザクションデータを受信した場合、又は、制御部１３が生成したトランザクションデータを取得した場合に、受信又は取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、申込トランザクションデータ、支払トランザクションデータおよび手数料トランザクションデータが含まれる。各トランザクションデータの詳細は後述する。
　台帳管理部１２は、分散台帳を管理している処理部である。具体的には、台帳管理部１２は、トランザクションデータを受信した場合、受信したトランザクションデータを他の複数のサーバに転送し、かつ、受信したトランザクションデータを分散台帳に格納する。例えば、台帳管理部１２は、端末４０から支払トランザクションデータを受信し、受信した支払トランザクションデータを複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちのサーバ１０Ａとは異なる複数の他のサーバ１０Ｂ及び１０Ｃに転送し、かつ、支払トランザクションデータを含む第１ブロックを台帳記憶部１６に記憶されている分散台帳に格納する。また、台帳管理部１２は、端末４０から手数料トランザクションデータを受信し、受信した手数料トランザクションデータを複数の他のサーバ１０Ｂ及び１０Ｃに転送し、かつ、第２トランザクションデータを含む第２ブロックを台帳記憶部１６に記憶されている分散台帳に格納する。
　このように、台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳では、分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記トランザクションデータが改ざんされないように管理されている。
　台帳管理部１２は、格納部１５と、台帳記憶部１６とを有する。
　格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、分散台帳の種別に応じた方式で新しいトランザクションデータを台帳記憶部１６に格納する。また、格納部１５は、サーバ１０Ａ等のうちの他のサーバの格納部１５との間で通信データを送受信し、他のサーバの台帳記憶部１６にも上記新しいトランザクションデータを格納させる。例えば、格納部１５は、分散台帳がブロックチェーンである場合には、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとった上で、上記ブロックを台帳記憶部１６に格納する。格納部１５は、例えば、第１ブロックの分散台帳への格納では、複数の他のサーバ１０Ｂ及び１０Ｃと共にコンセンサスアルゴリズムを実行し、第１ブロックを分散台帳に格納する。また、格納部１５は、例えば、第２ブロックの分散台帳への格納では、複数の他のサーバ１０Ｂ及び１０Ｃと共にコンセンサスアルゴリズムを実行し、第２ブロックを分散台帳に格納する。
　台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータを記憶しており、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている。この詳細は、後述する。
　また、台帳記憶部１６に格納されている分散台帳には、支払者による支払いの手続きを行うための手数料を算出に用いられる手数料算出情報が予め格納されている。また、分散台帳には、申込トランザクションデータに基づいて手数料を算出するためのスマートコントラクトのコードが含まれている。手数料の算出については、後述する。
　なお、分散台帳は、例えばブロックチェーンであり、この場合を例として説明するが、他の方式の分散台帳（例えば、ＩＯＴＡ又はハッシュグラフ等）を採用することも可能である。なお、分散台帳は、新しいデータの格納の際にコンセンサスアルゴリズム（例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）、ＰｏＷ（Ｐｒｏｏｆ　ｏｆ　Ｗｏｒｋ）又はＰｏＳ（Ｐｒｏｏｆ　ｏｆ　Ｓｔａｋｅ））を実行するものであってもよいし、実行しないものであってもよい。コンセンサスアルゴリズムを実行しない分散台帳技術の一例としてＨｙｐｅｒｌｅｄｇｅｒ　ｆａｂｒｉｃがある。
　制御部１３は、トークンの提供に係る処理を制御する処理部である。制御部１３は、申込トランザクションデータを端末４０から受信することにより、支払者がトークンの取り引きを行う予定の日時を含む情報を端末４０から受信する。また、制御部１３は、台帳記憶部１６に格納されている分散台帳を参照し、申込トランザクションデータに含まれる取り引き予定の日時以前に分散台帳に記録されている支払者Ｕ１による取り引きに基づいて、支払者Ｕ１の取り引き予定の取り引きにかかる手数料の額を算出する。制御部１３は、算出した手数料の額を含む手数料情報を端末４０に送信する。
　制御部１３は、例えば、取り引き予定日時における、分散台帳における支払者のトークンの残高が多いほど高い額の手数料を算出する。また、制御部１３は、例えば、分散台帳における支払者による前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する。経過時間は、例えば、前回の取り引きタイミングから申込トランザクションデータを受信したタイミングまでの時間である。また、制御部１３は、例えば、分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する。なお、期間における取引量とは、例えば、支払者の当該期間における支払額の合計である。支払いとは送金、出金、振り込みなどであってもよい。
　なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされる。制御部１３は、申込トランザクションデータを端末４０から受信すると、分散台帳に含まれるコントラクトコードを実行することで手数料を算出する。コントラクトコードは、スマートコントラクトを実現するために実行されるコードである。
　以降において、支払者に請求される、支払者による取り引きにかかる手数料について説明する。
　支払者に請求される手数料は、手数料算出情報に基づいて、支払者による取り引きの申し込みのタイミングに基づいて決定される。具体的には、手数料は、（ｉ）申し込みのタイミングにおける、分散台帳における支払者のトークンの残高、（ｉｉ）分散台帳における支払者による前回の取り引きタイミングからの経過時間、および、（ｉｉｉ）分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均の少なくとも１つに基づいて決定される。手数料算出情報は、例えば、手数料を規定する関数またはテーブルである。
　図３は、本実施の形態における手数料算出情報の一例を示す説明図である。図３に示される手数料算出情報は、手数料額を関数によって規定する手数料算出情報の例である。
　図３において、横軸は、支払者のトークンの残高ｘを示しており、縦軸は、各残高ｘにおける手数料額Ｆ（ｘ）を示している。
　関数Ｆ（ｘ）は、原則として、ｘの増加に対して増加する傾向を有する。言い換えれば、手数料額は、残高が多くなるにつれて増加する傾向を有する。より具体的には、関数Ｆ（ｘ）は、ｘに対して単調増加の関数である。ただし、関数Ｆ（ｘ）は、ｘの変化に対して値を維持する区間を含んでもよい。
　制御部１３は、図３に示される手数料算出情報である関数Ｆ（ｘ）を用いて以下のように手数料額を算出することで決定する。
　以降において、処理部１１が分散台帳に格納する各種トランザクションデータである、（１）申込トランザクションデータ、（２）支払トランザクションデータ、および（３）手数料トランザクションデータについて説明する。
　（１）申込トランザクションデータ
　図４は、本実施の形態における申込トランザクションデータを模式的に示す説明図である。申込トランザクションデータは、支払者Ｕ１が取り引きを行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
　図４に示されるように、申込トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い予定日時と、支払い予定額と、指示と、署名とを含む。
　支払者ＩＤは、取り引き（支払い）予定における支払者を一意に特定するための識別子である。
　支払先ＩＤは、取り引き（支払い）予定における支払先を一意に特定するための識別子である。
　支払い予定日時は、取り引き（支払い）が行われる予定のタイミングを示す情報である。支払い予定日時は、取り引きが行われる予定の日時が示されているが、取り引きが行われる予定の時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
　支払い予定額は、取り引きで支払われる予定の額を示す情報である。額は、例えば、トークンの量である。
　指示は、取り引きにかかる手数料の算出処理をサーバ１０Ａに行わせることを指示するための情報である。なお、申込トランザクションデータは、指示の代わりに、当該トランザクションデータが、取り引きが行われる予定を示す情報が含まれる申込トランザクションデータであることを示す情報を含んでいてもよい。この場合、サーバ１０Ａ等は、申込トランザクションデータを受信した場合、申込トランザクションデータであることを示す情報が受信したトランザクションデータに含まれていることを検出すると、手数料の算出を行ってもよい。
　署名は、当該申込トランザクションデータを生成した装置又は人が付した電子署名である。
　図４に示される申込トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｂｂｂ０１」である支払先に支払う予定を示す申込トランザクションデータである。この取り引きの予定において、支払い予定額は「５」トークンであり、支払い予定日時は「２０１８．１０．１０　１５：００」である。署名は、支払者の電子署名である。
　（２）支払トランザクションデータ
　図５は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。支払トランザクションデータは、支払者Ｕ１が取り引きを行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
　図５に示されるように、支払トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い日時と、支払い額と、署名とを含む。
　支払者ＩＤは、取り引き（支払い）における支払者を一意に特定するための識別子である。
　支払先ＩＤは、取り引き（支払い）における支払先を一意に特定するための識別子である。
　支払い日時は、取り引き（支払い）が行われるタイミングを示す情報である。支払い日時は、取り引きが行われる日時が示されているが、取り引きが行われる時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
　支払い額は、取り引きで支払われる額を示す情報である。額は、例えば、トークンの量である。
　署名は、当該支払トランザクションデータを生成した装置又は人が付した電子署名である。
　図５に示される支払トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｂｂｂ０１」である支払先に支払う取り引きの支払トランザクションデータである。この取り引きにおいて、支払い額は「５」トークンであり、支払い日時は「２０１８．１０．１０　１５：００」である。署名は、支払者の電子署名である。
　（３）手数料トランザクションデータ
　図６は、本実施の形態における手数料トランザクションデータを模式的に示す説明図である。手数料トランザクションデータは、支払者Ｕ１が取り引き行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
　図６に示されるように、手数料トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い日時と、手数料額と、署名とを含む。
　支払者ＩＤは、取り引きにかかる手数料の支払いにおける支払者を一意に特定するための識別子である。
　支払先ＩＤは、取り引きにかかる手数料の支払先を一意に特定するための識別子である。
　支払い日時は、取り引きにかかる手数料の支払いが行われるタイミングを示す情報である。支払い日時は、手数料の支払いが行われる日時が示されているが、手数料の支払いが行われる時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
　手数料額は、取り引きにかかる手数料の額を示す情報である。額は、例えば、トークンの量である。
　署名は、当該申込トランザクションデータを生成した装置又は人が付した電子署名である。
　図６に示される申込トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｆｌｊａｄ４０１９」である支払先に手数料を支払うこと示す手数料トランザクションデータである。この手数料の支払いにおいて、支払い額は「１」トークンであり、支払い予定日時は「２０１８．１０．１０　１５：００」である。署名は、支払者の電子署名である。
　以降において、取引管理システム１の処理について、具体例を説明する。
　図７は、本実施の形態における取引管理システム１の処理の一例を示すフロー図である。
　支払者Ｕ１の端末４０は、支払者Ｕ１から取り引き予定の日時を示す入力、および、取り引き予定の額を示す入力を受け付けて（Ｓ１０１）。
　端末４０は、受け付けた入力に基づいて、取り引き予定の日時、および、取り引き予定の額を含む申込トランザクションデータを生成する（Ｓ１０２）。
　端末４０は、生成した申込トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１０３）。このとき、端末４０は、生成した申込トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、端末４０により送信された申込トランザクションデータを受信し、分散台帳に格納する（Ｓ１０４）。
　サーバ１０Ａ等は、申込トランザクションデータの送信元である端末４０に係る支払者Ｕ１による支払いの手続きを行うために要する手数料の額を算出する（Ｓ１０５）。
　サーバ１０Ａ等は、算出した手数料の額を含む手数料情報を支払者Ｕ１が保有する端末４０に送信する（Ｓ１０６）。この時、サーバ１０Ａ等に含まれる複数のサーバの全てが手数料情報を端末４０に送信しなくてもよい。例えば、手数料の額を算出し終えたサーバは、手数料情報を端末４０に送信すると共に、手数料の額を算出し終えたことを示す完了情報を他のサーバに送信してもよい。他のサーバは、完了情報を受信したときに手数料情報を端末４０へ送信していない場合、手数料情報を端末４０に送信しなくてもよい。
　端末４０は、サーバ１０Ａ等から送信された手数料情報を受信すると、手数料情報に含まれる手数料の額を端末４０に表示させる（Ｓ１０７）。このとき、端末４０は、手数料情報に含まれる手数料の額に同意するか否かを支払者Ｕ１に問い合わせるＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）を提示してもよい。
　図８は、端末４０の表示部６０が表示するＵＩ５０の一例を示す図である。
　ＵＩ５０は、手数料の額５１と、手数料の支払いに同意することを示す入力を受け付けるための同意ボタン５２と、手数料の支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３とを含む。
　端末４０は、提示したＵＩに対して同意を示す入力を受け付けたか否かを判定する（Ｓ１０８）。
　端末４０は、同意を示す入力を受け付けた場合（Ｓ１０８でＹｅｓ）、例えばＵＩ５０において同意ボタン５２への入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する（Ｓ１０９）。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０において不同意ボタン５３への入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合（Ｓ１０８でＮｏ）、当該取り引きに係る処理を終了する。この場合、端末４０は、処理が終了したことを示す終了情報をサーバ１０Ａ等に送信してもよい。サーバ１０Ａ等は、終了情報を受信すると、当該取り引きに係る処理を終了する。なお、サーバ１０Ａ等は、終了情報を受信することに限らずに、手数料情報を送信してから一定期間端末４０から情報（例えば、支払トランザクションデータまたは手数料トランザクションデータ）を受信しない場合、当該取り引きに係る処理を終了してもよい。
　ステップＳ１０９の後で、端末４０は、生成した支払トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１１０）。このとき、端末４０は、生成した支払トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、端末４０により送信された支払トランザクションデータを受信し、分散台帳に格納する（Ｓ１１１）。
　サーバ１０Ａ等は、支払トランザクションデータに含まれる支払額の支払いが支払者Ｕ１によって取り引き日時に行われたことを支払先Ｕ２の端末４１に通知する（Ｓ１１２）。
　また、ステップＳ１０９の後で、端末４０は、手数料情報に基づく、手数料の額を含む手数料トランザクションデータを生成する（Ｓ１１３）。
　端末４０は、生成した手数料トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１１４）。このとき、端末４０は、生成した手数料トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
　サーバ１０Ａ等は、端末４０により送信された手数料トランザクションデータを受信し、分散台帳に格納する（Ｓ１１５）。
　サーバ１０Ａ等は、手数料トランザクションデータに含まれる手数料の額の支払いが支払者Ｕ１によって取り引き日時に行われたことを業者Ｘの端末４２に通知する（Ｓ１１６）。
　なお、ステップＳ１０９は、ステップＳ１１３の後に行われてもよいし、ステップＳ１１３と並行して行われてもよい。また、ステップＳ１１０は、ステップＳ１１４の後に行われてもよいし、ステップＳ１１４と並行して行われてもよい。また、ステップＳ１１１は、ステップＳ１１５の後に行われてもよいし、ステップＳ１１５と並行して行われてもよい。また、ステップＳ１１２は、ステップＳ１１６の後に行われてもよいし、ステップＳ１１６と並行して行われてもよい。
　以上のように、本実施の形態に係る制御方法によれば、受信した申込トランザクションデータに含まれる予定の日時以前に分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出し、手数料を支払うように要求する。このため、例えば、算出する手数料の額の大きさを調整することで、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
　また、手数料の算出を、他の人または他のシステムを介在することなく、早期かつ安全に実行することができる。よって、本開示に係る制御方法は、トークンの取り引きを管理する複数のサーバの消費電力を削減することができる。
　また、コンセンサスアルゴリズムの実行を経て分散台帳を格納する。よって、本開示に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、トークンの取り引きを適切に管理することができる。
　また、手数料の算出では、分散台帳における支払者Ｕ１のトークンの残高が多いほど高い額の手数料を算出する。また、手数料の算出では、分散台帳における支払者Ｕ１による前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する。また、手数料の算出では、分散台帳における支払者Ｕ１による取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する。このため、支払者Ｕ１がトークンを使用していないほど高い額の手数料を要求することができる。よって、支払者Ｕ１にトークンを早く使用するように促すことができ、取り引きが発生するタイミングを制御することができる。
　また、手数料情報は、端末４０の表示部６０に手数料を表示させるための情報である。このため、手数料を端末４０の表示部６０に表示させることで、支払者Ｕ１にトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
　また、手数料情報は、支払者Ｕ１に手数料情報に含まれる手数料に同意するか否かを問い合わせる問い合わせ情報を含む。これによれば、端末４０を介して、手数料に同意するか否かを支払者Ｕ１に問い合わせることができるため、支払者Ｕ１がトークンを使用するタイミングを調整することができる。例えば、手数料の額を大きくするほどトークンを使用するタイミングを早めることができる。よって、取り引きが発生するタイミングを制御することができる。
　（変形例１）
　上記実施の形態では、トークンは、複数種類のトークンを含んでいてもよい。つまり、取引管理システム１は、複数種類のトークンの取り引きを管理していてもよい。この場合、サーバ１０Ａ等が保有する分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含む。分散台帳は、例えば、２種類のトークンＡおよびトークンＢがある場合、トークンＡの取り引きを示すサブ分散台帳Ａと、トークンＢの取り引きを示すサブ分散台帳Ｂとを含む。
　サーバ１０Ａ等の制御部１３は、手数料の算出（Ｓ１０５）において、申し込み情報に含まれる予定の日時以前に複数のサブ分散台帳に記録されている支払者Ｕ１による取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出する。制御部１３は、例えば、申し込み情報に含まれる予定の日時以前にサブ分散台帳Ａに記録されている支払者Ｕ１によるトークンＡの取り引きに基づいて、トークンＡの取り引きにかかる手数料Ａを算出する。これと共に、制御部１３は、申し込み情報に含まれる予定の日時以前にサブ分散台帳Ｂに記録されている支払者Ｕ１によるトークンＢの取り引きに基づいて、トークンＢの取り引きにかかる手数料Ｂを算出する。
　なお、手数料の算出では、制御部１３は、トークンＡの流通量が多く、トークンＢの流通量がトークンＡと比較して少ない場合、トークンＢの流通量を増加させるために、トークンＢの取り引きにかかる手数料をトークンＡの取り引きに係る手数料よりも少なくしてもよい。ここで、流通量とは、例えば、現時点から所定時間前までの期間における、複数のユーザによる取引量の単位時間当たりの平均であってもよい。複数のユーザによる取引量とは、特定の種類のトークンを利用しているユーザ全ての取引量の総和であってもよい。平均とは、単位時間当たりの平均に加えて、さらに、一人当たりのユーザの平均であってもよい。トークンＢの取り引きにかかる手数料をトークンＡの取り引きに係る手数料よりも少なくするとは、トークンＡの価値およびトークンＢの価値を比較するための共通の価値で比較したときに当該価値に換算したときのトークンＢの価値がトークンＡの価値よりも少なくなるように算出することである。また、この場合、例えば、手数料の算出では、トークンＢの手数料を算出するための手数料算出情報を示す関係が、トークンＡの手数料を算出するための手数料算出情報を示す関係よりも、上記の共通の価値換算における手数料額が、どの残高、どの経過時間、またはどの平均においても小さくなるように調整し、調整後の２つの関係を用いてトークンＡの手数料およびトークンＢの手数料を算出してもよい。調整では、例えば、トークンＢの関係における手数料額に１より小さい係数を乗じることで、トークンＢの関係をトークンＡの関係よりも小さくしてもよいし、トークンＡの関係における手数料額に１より大きい係数を乗じることで、トークンＢの関係をトークンＡの関係よりも小さくしてもよい。また、調整では、例えば、トークンＢの関係における手数料額に所定の手数料額を減算する（つまり、負の方向にオフセットする）ことで、トークンＢの関係をトークンＡの関係よりも小さくしてもよいし、トークンＡの関係における手数料額に所定の手数料額を加算する（つまり、正の方向にオフセットする）ことで、トークンＢの関係をトークンＡの関係よりも小さくしてもよい。
　制御部１３は、手数料の送信（Ｓ１０６）において、手数料情報として、算出した複数の手数料、つまり、手数料Ａおよび手数料Ｂを含む情報を端末４０に送信する。このように、複数種類のトークン毎に手数料を算出するため、トークンの種類毎に取引量の調整を行うことができる。
　端末４０は、サーバ１０Ａ等から送信された手数料情報を受信すると、手数料情報に含まれる手数料の額を、異なる種類のトークン毎に端末４０の表示部６０に表示させる（Ｓ１０７）。つまり、手数料情報は、端末４０の表示部６０に、異なる種類のトークン毎に手数料を表示させるための情報である。このため、トークンの種類毎に手数料を端末の表示部に表示させることで、支払者Ｕ１に種類毎にトークンを早く使用するように促すことができる。よって、トークンの種類毎に取り引きが発生するタイミングを制御することができる。
　図９は、端末４０の表示部６０が表示するＵＩ５０Ａの一例を示す図である。
　ＵＩ５０Ａは、トークンＡの取り引きにかかる手数料Ａを表示する。ＵＩ５０Ａは、手数料Ａの額５１Ａと、手数料Ａの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ａと、手数料Ａの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ａと、手数料Ｂを表示するＵＩ５０Ｂに表示を切り替える切り替えボタン５４Ａとを含む。
　端末４０は、トークンＡの手数料Ａへの同意を示す入力を受け付けた場合、例えばＵＩ５０Ａにおいて同意ボタン５２Ａへの入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する。生成される支払トランザクションデータは、トークンＡを取り引きに用いることを示す情報をさらに含む。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０Ａにおいて不同意ボタン５３Ａへの入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合、当該取り引きに係る処理を終了する、または、手数料Ｂを表示するＵＩ５０Ｂに表示を切り替える。
　図１０は、端末４０の表示部６０が表示するＵＩ５０Ｂの一例を示す図である。
　ＵＩ５０Ｂは、トークンＢの取り引きにかかる手数料Ｂを表示する。ＵＩ５０Ｂは、手数料Ｂの額５１Ｂと、手数料Ｂの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ｂと、手数料Ｂの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ｂと、手数料Ａを表示するＵＩ５０Ａに表示を切り替える切り替えボタン５４Ｂとを含む。
　端末４０は、トークンＢの手数料Ｂへの同意を示す入力を受け付けた場合、例えばＵＩ５０Ｂにおいて同意ボタン５２Ｂへの入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する。生成される支払トランザクションデータは、トークンＢを取り引きに用いることを示す情報をさらに含む。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０Ｂにおいて不同意ボタン５３Ｂへの入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合、当該取り引きに係る処理を終了する、または、手数料Ａを表示するＵＩ５０Ａに表示を切り替える。
　なお、処理を終了する場合、端末４０は、処理が終了したことを示す終了情報をサーバ１０Ａ等に送信してもよい。サーバ１０Ａ等は、終了情報を受信すると、当該取り引きに係る処理を終了する。なお、サーバ１０Ａ等は、終了情報を受信することに限らずに、手数料情報を送信してから一定期間端末４０から情報（例えば、支払トランザクションデータまたは手数料トランザクションデータ）を受信しない場合、当該取り引きに係る処理を終了してもよい。
　図１１は、端末４０の表示部６０が表示するＵＩ５０Ｃを示す図である。ＵＩ５０Ｃは、ＵＩ５０ＡおよびＵＩ５０Ｂとは別の例におけるＵＩである。
　ＵＩ５０Ｃは、トークンＡおよびトークンＢのうちで、手数料がお得である（つまり安い）方のトークンＡの取り引きにかかる手数料Ａを表示する。ＵＩ５０Ｃは、手数料Ｃの額５１Ｃと、手数料Ｃの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ｃと、手数料Ｃの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ｃとを含む。なお、ＵＩ５０Ｃは、さらに、手数料Ｂを表示するＵＩに表示を切り替える切り替えボタンを含んでいてもよい。
　なお、各ＵＩには、さらに、提示する手数料が算出されることとなった理由を示すメッセージを含んでいてもよい。メッセージは、例えば、取り引き予定日時における、分散台帳における支払者のトークンの残高が所定の残高であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、トークンの残高が少ないほど手数料が安くなることが示されてもよい。また、メッセージは、例えば、分散台帳における支払者による前回の取り引きタイミングからの経過時間が所定の経過時間であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、経過時間が短いほど手数料が安くなることが示されてもよい。また、メッセージは、例えば、分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均が所定の平均値であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、平均値が大きいほど手数料が安くなることが示されてもよい。
　（変形例２）
　本変形例において、上記各実施の形態の取引管理システムの別の構成について説明する。
　図１２は、本変形例における取引管理システム２の構成を模式的に示すブロック図である。
　図１２に示されるように、取引管理システム２は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１および４２とを備える。取引管理システム２が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
　特に、取引管理システム２では、サーバ１０Ａ、１０Ｂ及び１０Ｃが互いにネットワークＮを介して接続されている。また、サーバ１０Ａに端末４０が接続されており、サーバ１０Ｂに端末４１が接続されており、サーバ１０Ｃに端末４２が接続されている。
　このような構成は、例えば、複数の団体が取引管理システム２を運営する場合において、各団体が管理するサーバを、ネットワークＮを介して接続する場合に利用され得る。例えば、団体Ａにサーバ１０Ａと端末４０とが所属しており、団体Ｂにサーバ１０Ｂと端末４１とが所属しており、団体Ｃにサーバ１０Ｃと端末４２とが所属している。
　サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
　（変形例３）
　本変形例において、上記各実施の形態の取引管理システムの別の構成について説明する。
　図１３は、本変形例における取引管理システム３の構成を模式的に示すブロック図である。
　図１３に示されるように、取引管理システム３は、サーバ１０Ｄと、端末４０、４１および４２とを備える。取引管理システム３が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
　特に、取引管理システム３では、サーバ１０Ｄ、並びに、端末４０および４１が互いにネットワークＮを介して接続されている。また、サーバ１０Ｄに端末４２が接続されている。この場合、サーバ１０Ｄ、端末４０および４１それぞれが、上記各実施の形態におけるサーバ１０Ａ等の動作をする。
　このような構成は、例えば、１以上の団体と１以上の個人とが取引管理システム３を運営する場合において、各団体又は各個人が管理するサーバ又は端末を、ネットワークＮを介して接続する場合に利用され得る。例えば、団体Ｄにサーバ１０Ｄと端末４２とが所属しており、団体Ｄと、個人である支払者Ｕ１及び支払先Ｕ２とが取引管理システム３を運営している。
　サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
　（変形例４）
　ここで、実施の形態の変形例４について説明する。
　図１４は、本変形例におけるサーバの処理を示すフロー図である。
　図１４に示されるように、サーバ１０Ａ等は、第１ユーザとしての支払者Ｕ１により操作された端末４０から、支払者Ｕ１が取り引きを行う予定の日時を含む申し込み情報を受信する（Ｓ２０１）。
　各サーバ１０Ａ～１０Ｃは、当該サーバが管理する第１分散台帳を参照し、受信した申し込み情報に含まれる予定の日時以前に第１分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出する（Ｓ２０２）。
　各サーバ１０Ａ～１０Ｃは、端末４０に算出した手数料を含む手数料情報を送信する（Ｓ２０３）。
　各サーバ１０Ａ～１０Ｃは、端末４０から取り引きの予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した第１トランザクションデータを複数のサーバ１０Ａ～１０Ｃのうちの当該サーバ（ステップＳ２０４の処理の主体となるサーバ）とは異なる複数の他のサーバに転送し、かつ、第１トランザクションデータを含む第１ブロックを第１分散台帳に格納する（Ｓ２０４）。
　各サーバ１０Ａ～１０Ｃは、端末４０から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した第２トランザクションデータを複数の他のサーバに転送し、かつ、第２トランザクションデータを含む第２ブロックを第１分散台帳に格納する（Ｓ２０５）。
　これにより、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。よって、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
　図１５は、実施の形態の変形例４におけるサーバの構成を模式的に示すブロック図である。
　図１５に示されるように、分散台帳を保有している複数のサーバを備える取り引き管理システムにおいて、当該複数のサーバのうちの一のサーバ６０Ａは、処理部６１と制御部６３とを備える。
　処理部６１は、第１ユーザとしての支払者Ｕ１により操作された端末４０から、支払者Ｕ１が取り引きを行う予定の日時を含む申し込み情報を受信する。
　制御部６３は、当該サーバが管理する第１分散台帳を参照し、受信した申し込み情報に含まれる予定の日時以前に第１分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出する。制御部６３は、端末４０に算出した手数料を含む手数料情報を送信する。
　処理部６１は、さらに、端末４０から取り引きの予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した第１トランザクションデータを複数のサーバ１０Ａ～１０Ｃのうちの当該サーバ（当該処理部６１を備えるサーバ）とは異なる複数の他のサーバに転送し、かつ、第１トランザクションデータを含む第１ブロックを第１分散台帳に格納する。また、処理部６１は、さらに、端末４０から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した第２トランザクションデータを複数の他のサーバに転送し、かつ、第２トランザクションデータを含む第２ブロックを第１分散台帳に格納する。
　これにより、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。よって、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
　（補足）
　上記各実施の形態、又は、変形例におけるブロックチェーンについて補足的に説明する。
　図１６は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。
　図１７は、トランザクションデータのデータ構造を示す説明図である。
　図１７に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。
　トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のコンテンツ管理システムなどを実現するソフトウェアは、次のようなプログラムである。
　すなわち、このプログラムは、コンピュータに、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する制御方法を実行させるプログラムである。
　以上、一つまたは複数の態様に係るファンド管理システムなどについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
　本開示は、トークンの取り引きを管理する取引管理システムに利用可能である。
　　１～３　　取引管理システム
　１０Ａ～１０Ｃ、６０Ａ　　サーバ
　１１、６１　　処理部
　１２　　台帳管理部
　１３、６３　　制御部
　１５　　格納部
　１６　　台帳記憶部
　４０～４２　　端末
　５０、５０Ａ～５０Ｃ　　ＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）
　５１、５１Ａ～５１Ｃ　　手数料の額
　５２、５２Ａ～５２Ｃ　　同意ボタン
　５３、５３Ａ～５３Ｃ　　不同意ボタン
　５４Ａ、５４Ｂ　　切り替えボタン
　Ｂ１、Ｂ２、Ｂ３　　ブロック
　Ｎ　　ネットワーク
　Ｕ１　　支払者
　Ｕ２　　支払先
　　Ｘ　　業者

Claims (12)

  1. 　複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、
    　第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、
    　前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、
    　算出した前記手数料を含む手数料情報を前記端末に送信し、
    　前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、
    　前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する
    　制御方法。
  2. 　前記申し込み情報は、前記予定の日時を含む第３トランザクションデータであり、
    　前記複数の分散台帳のそれぞれは、前記第３トランザクションデータに基づいて前記手数料を算出するためのコントラクトコードを含み、
    　前記手数料の算出では、前記第３トランザクションデータを受信すると、前記第１分散台帳に含まれる前記コントラクトコードを実行することで前記手数料を算出する
    　請求項１に記載の制御方法。
  3. 　前記第１ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第１ブロックを前記第１分散台帳に格納し、
    　前記第２ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第２ブロックを前記第１分散台帳に格納する
    　請求項１または２に記載の制御方法。
  4. 　前記手数料の算出では、前記第１分散台帳における前記第１ユーザの前記トークンの残高が多いほど高い額の手数料を算出する
    　請求項１から３のいずれか１項に記載の制御方法。
  5. 　前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する
    　請求項１から４のいずれか１項に記載の制御方法。
  6. 　前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する
    　請求項１から５のいずれか１項に記載の制御方法。
  7. 　前記手数料情報は、前記端末の表示部に前記手数料を表示させるための情報である
    　請求項１から６のいずれか１項に記載の制御方法。
  8. 　前記トークンは、複数種類のトークンを含み、
    　前記第１分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含み、
    　前記手数料の算出では、前記申し込み情報に含まれる前記予定の日時以前に前記複数のサブ分散台帳に記録されている前記第１ユーザによる取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出し、
    　前記手数料の送信では、前記手数料情報として、算出した前記複数の手数料を含む情報を前記端末に送信する
    　請求項１から６のいずれか１項に記載の制御方法。
  9. 　前記手数料情報は、前記端末の表示部に、異なる種類のトークン毎に前記手数料を表示させるための情報である
    　請求項８に記載の制御方法。
  10. 　前記手数料情報は、前記第１ユーザに前記手数料情報に含まれる前記手数料に同意するか否かを問い合わせる問い合わせ情報を含む
    　請求項１から９のいずれか１項に記載の制御方法。
  11. 　複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバであって、
    　前記複数の分散台帳のうちの第１分散台帳を管理する管理部と、
    　第１ユーザにより操作された端末から、前記第１ユーザにより取り引きを行う予定の日時を含む申し込み情報と、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータと、前記端末から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータとを受信する受信部と、
    　前記管理部における前記第１分散台帳を参照し、受信された前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて前記手数料を算出する算出部と、
    　前記端末に算出した前記手数料を含む手数料情報を送信する送信部と、を備え、
    　（ｉ）前記受信部が前記第１トランザクションデータを受信すると、前記送信部は、受信された前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記管理部は、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に記録し、
    　（ｉｉ）前記受信部が前記第２トランザクションデータを受信すると、前記送信部は、受信された前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記管理部は、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に記録する
    　サーバ。
  12. 　請求項１から１０のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。
PCT/JP2020/004453 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム Ceased WO2020162515A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080012331.0A CN113383358A (zh) 2019-02-08 2020-02-06 控制方法、服务器、以及程序
JP2020571245A JP7402187B2 (ja) 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム
US17/392,687 US20210365936A1 (en) 2019-02-08 2021-08-03 Control method, server, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962802856P 2019-02-08 2019-02-08
US62/802,856 2019-02-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/392,687 Continuation US20210365936A1 (en) 2019-02-08 2021-08-03 Control method, server, and recording medium

Publications (1)

Publication Number Publication Date
WO2020162515A1 true WO2020162515A1 (ja) 2020-08-13

Family

ID=71947218

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/004453 Ceased WO2020162515A1 (ja) 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム

Country Status (4)

Country Link
US (1) US20210365936A1 (ja)
JP (1) JP7402187B2 (ja)
CN (1) CN113383358A (ja)
WO (1) WO2020162515A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム
JP7490916B1 (ja) 2024-02-02 2024-05-28 株式会社Synquery 情報処理装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113781227B (zh) * 2021-09-17 2024-03-29 北京快来文化传播集团有限公司 虚拟金币兑换方法、电子设备及计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018515833A (ja) * 2015-03-31 2018-06-14 ナスダック， インコーポレイテッドＮａｓｄａｑ， Ｉｎｃ． ブロックチェーン取引記録のシステムおよび方法
US20180189753A1 (en) * 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11341488B2 (en) * 2017-02-06 2022-05-24 Northern Trust Corporation Systems and methods for issuing and tracking digital tokens within distributed network nodes
US10944546B2 (en) * 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
US10880074B2 (en) * 2018-10-15 2020-12-29 Adobe Inc. Smart contract platform for generating and customizing smart contracts

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018515833A (ja) * 2015-03-31 2018-06-14 ナスダック， インコーポレイテッドＮａｓｄａｑ， Ｉｎｃ． ブロックチェーン取引記録のシステムおよび方法
US20180189753A1 (en) * 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム
JP7490916B1 (ja) 2024-02-02 2024-05-28 株式会社Synquery 情報処理装置

Also Published As

Publication number Publication date
US20210365936A1 (en) 2021-11-25
CN113383358A (zh) 2021-09-10
JP7402187B2 (ja) 2023-12-20
JPWO2020162515A1 (ja) 2021-12-23

Similar Documents

Publication Publication Date Title
US20220156738A1 (en) Methods and systems of using a cryptocurrency system to manage payments and payment alternatives
CN110458543B (zh) 数据处理方法、相关设备及介质
Warren et al. 0x: An open protocol for decentralized exchange on the Ethereum blockchain
CN115147112B (zh) 用于使用数字签名创建可信数字资产转移的方法和系统
CN109478997B (zh) 区块链实现的系统和方法
CN110599323B (zh) 一种资源处理方法及处理设备
US20200020032A1 (en) System and method for cryptocurrency trading
JP2021061021A (ja) 信頼度が低い、または信頼度が皆無の当事者間での価値転送を円滑化する装置、システム、または方法
US20200099518A1 (en) Methods and systems for using digital signatures to create trusted digital asset transfers
WO2018060951A1 (en) A system for trading in a contract-free manner
JP2019523495A (ja) 分散トランザクションコンセンサスネットワークのデジタル財管理
JP2016219014A (ja) リソース転送システム
EP3906517A1 (en) Methods and systems for margin lending and trading on a decentralized exchange
CN111242603B (zh) 基于区块链的乘车结算方法及装置
JP7402187B2 (ja) 制御方法、サーバ、および、プログラム
JP6943282B2 (ja) 仮想通貨の支払代行装置、仮想通貨の支払代行方法およびプログラム
CN110866753A (zh) 一种第三方结算的控制方法、装置、电子设备和存储介质
US20180152429A1 (en) Systems and methods for publicly verifiable authorization
US20200027082A1 (en) Virtual currency payment agent device, virtual currency payment agent method, and program recording medium
CN110930257A (zh) 一种数据处理方法、装置、设备及存储介质
JP7410890B2 (ja) 制御方法、サーバおよびプログラム
JP7503497B2 (ja) 制御方法、ファンド管理システム、及び、プログラム
CN110852731A (zh) 一种基金交易的方法以及相关装置
JP7524066B2 (ja) 制御方法、ファンド管理システム、及び、プログラム
CN112016114A (zh) 基于加密货币的智能合约生成方法、相关设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20752111

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020571245

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20752111

Country of ref document: EP

Kind code of ref document: A1