WO2021152769A1 - ピアツーピア端末及び約定取引システム - Google Patents

ピアツーピア端末及び約定取引システム Download PDF

Info

Publication number
WO2021152769A1
WO2021152769A1 PCT/JP2020/003410 JP2020003410W WO2021152769A1 WO 2021152769 A1 WO2021152769 A1 WO 2021152769A1 JP 2020003410 W JP2020003410 W JP 2020003410W WO 2021152769 A1 WO2021152769 A1 WO 2021152769A1
Authority
WO
WIPO (PCT)
Prior art keywords
peer
contract
terminal
result
contract result
Prior art date
Application number
PCT/JP2020/003410
Other languages
English (en)
French (fr)
Inventor
悠太 奥村
拓也 小田
裕矢 梶川
田中　圭介
クサヴィエ デファゴ
Original Assignee
三菱電機株式会社
国立大学法人東京工業大学
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 三菱電機株式会社, 国立大学法人東京工業大学 filed Critical 三菱電機株式会社
Priority to JP2020537559A priority Critical patent/JP6854981B1/ja
Priority to CN202080094187.XA priority patent/CN114981830A/zh
Priority to PCT/JP2020/003410 priority patent/WO2021152769A1/ja
Priority to US17/782,665 priority patent/US20230020147A1/en
Publication of WO2021152769A1 publication Critical patent/WO2021152769A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/08—Auctions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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

Definitions

  • This disclosure relates to peer-to-peer terminals and contract trading systems.
  • a contract transaction system has been proposed in which a person who wants to sell content and a person who wants to purchase content are matched via a network to complete a contract transaction.
  • a user who desires to trade financial assets operates a client terminal device (paragraph 0012). Further, the exchange server device receives the transaction information transmitted from each client terminal device via the network, and processes the transaction summarization based on the received transaction information (paragraph 0013).
  • the conventional contract trading system represented by the financial asset trading system described in Patent Document 1 adopts a client-server model. Therefore, the server performs a process of concluding a contract transaction. Therefore, the server becomes a single point of failure. Therefore, if the server fails, the contract trading system cannot be maintained. In addition, in order to prevent unauthorized access to the server and malware infection, the security strength of the server must be increased. Therefore, there is a cost for increasing the security strength of the server.
  • P2P peer-to-peer
  • Peer to Peer peer-to-peer
  • the P2P network does not have a single point of failure like the server described above.
  • the P2P network does not have a terminal that manages the whole like the above-mentioned server. Therefore, when each terminal provided in the P2P network performs a process of establishing a contract transaction, the plurality of contract results calculated by the plurality of terminals may not be the same. Therefore, it is not possible to specify one contract result to be relied on.
  • This disclosure was made in view of these issues. It is an object of the present disclosure to provide a contract trading system that does not have a single point of failure and can identify one contract result to be relied on from a plurality of contract results that are not the same.
  • This disclosure relates to peer-to-peer terminals.
  • the peer-to-peer terminal includes a bid data acquisition unit, a bid data transmission unit, a contract result calculation unit, a contract result transmission unit, a contract result reception unit, and a contract result selection unit.
  • the bid data acquisition department acquires bid data.
  • the bid data transmission unit transmits the bid data to other peer-to-peer terminals.
  • the contract result calculation unit calculates the contract result from the bid data group acquired by the bid data acquisition unit.
  • the contract result transmission unit transmits the contract result to other peer-to-peer terminals.
  • the contract result receiving unit receives other contract results calculated by the other peer-to-peer terminal from the other peer-to-peer terminal.
  • the contract result selection department selects one contract result from the contract result and other contract results.
  • This disclosure is also directed to a contract trading system equipped with the peer-to-peer terminal.
  • a contract transaction can be concluded in a peer-to-peer network composed of a plurality of peer-to-peer terminals. This makes it possible to provide a contract trading system that does not have a single point of failure. Further, it is possible to provide a contract trading system capable of specifying one contract result to be relied on from a plurality of contract results that are not the same.
  • FIG. 5 is a network diagram schematically illustrating a peer-to-peer (P2P) network composed of a plurality of terminals provided in the contract trading system of the first embodiment. It is a block diagram which shows typically the hardware composition of each terminal provided in the contract transaction system of Embodiment 1.
  • FIG. It is a flowchart which illustrates the flow of the process performed by each terminal provided in the contract trading system of Embodiment 1.
  • FIG. It is a figure which illustrates the example of the bid data acquired by each terminal provided in the contract trading system of Embodiment 1.
  • FIG. It is a figure which illustrates the example of the contract result calculated by the terminal provided in the contract transaction system of Embodiment 1.
  • FIG. It is a figure which illustrates the example of the selection index referred to by each terminal provided in the contract trading system of Embodiment 1.
  • FIG. It is a figure which illustrates the example of the block stored in each terminal provided in the contract trading system of Embodiment 1.
  • FIG. It is a block diagram which schematically illustrates the contract trading system of Embodiment 2. It is a flowchart which illustrates the flow of the process performed by each terminal provided in the contract transaction system of Embodiment 2. It is a figure which illustrates the example of the incentive ratio referred to by each terminal provided in the contract trading system of Embodiment 2. It is a figure which illustrates the example of the incentive calculated by each terminal provided in the contract trading system of Embodiment 2.
  • FIG. 1 is a block diagram schematically showing the contract trading system of the first embodiment.
  • the contract transaction system 1 of the first embodiment illustrated in FIG. 1 acquires the bid data 101 created by the user.
  • the acquired bid data 101 represents the content of the bid expressing the intention to trade the product.
  • the bid data 101 is buy bid data or sell bid data.
  • the bid data represents the content of the bid that expresses the intention to buy the product.
  • the sell / bid data represents the content of the sell / bid that expresses the intention to sell the product.
  • Merchandise includes securities, electricity, gas, wheat, gold, etc.
  • the contract transaction system 1 concludes a contract transaction between a buy bid and a sell bid, and calculates a contract result 102 indicating the result of the contract transaction that has been completed.
  • the buyer user who created the bid data can buy the product at a price lower than the bid price represented by the bid data
  • the seller user who created the bid data can buy the product.
  • a contract transaction is concluded so that the product can be sold at a price higher than the bid price represented by the bid data.
  • the deadline for bidding is set in the contract transaction system 1.
  • the contract transaction system 1 has contents represented by the bid data acquired by the set deadline of the bid and the contents represented by the sell bid data acquired by the set deadline of the bid.
  • a contracted transaction is concluded between the bid and the bid.
  • the contract transaction system 1 closes a contract transaction at a set deadline for bidding.
  • the bid deadline is set, for example, at regular time intervals.
  • the fixed time interval is, for example, a 5-minute interval.
  • TT 0:00, TT: 05, TT: 10, TT: 15, TT: 20, TT: 25, TT: 30, TT: 35, TT: 40, TT: 45, TT: 50 and TT: 55 are set as bid deadlines.
  • the contract trading system 1 includes a plurality of terminals 11 and a certificate authority 12 as shown in FIG. Of the plurality of terminals 11, only the terminals 11a and 11b are shown in FIG.
  • the terminal 11a is treated as each terminal 11x included in the plurality of terminals 11, and the terminal 11b is treated as another terminal 11y included in the plurality of terminals 11.
  • Each terminal 11x is a P2P terminal constituting a peer-to-peer (P2P) network.
  • P2P peer-to-peer
  • Each terminal 11x acquires bid data 101.
  • the acquired bid data 101 includes bid data 101x received by each terminal 11x from terminals not included in the plurality of terminals 11, and bid data 101y received by each terminal 11x from other terminals 11y included in the plurality of terminals 11. Alternatively, it is bid data (not shown) created in each terminal 11x. As a result, each terminal 11x acquires the bid data group 103.
  • each terminal 11x transmits the acquired bid data 101 to another terminal 11y.
  • each terminal 11x concludes a contract transaction between a buy bid and a sell bid, and calculates a contract result 102x indicating the result of the contracted transaction.
  • the plurality of contract results 102x calculated by the plurality of terminals 11 are also the same.
  • the plurality of bid data groups 103 are not the same due to the influence of communication delay, the topology of the P2P network composed of the plurality of terminals 11, the plurality of contract results 102x may not be the same.
  • Each terminal 11x selects one contract result to be relied on from the plurality of contract results 102x when the plurality of contract results 102x are not the same.
  • the certificate authority 12 issues a digital certificate 104 for each terminal 11x.
  • FIG. 2 is a network diagram schematically illustrating a P2P network composed of a plurality of terminals provided in the contract trading system of the first embodiment.
  • the P2P network 21 illustrated in FIG. 2 includes a plurality of terminals 11.
  • FIG. 2 shows only the terminals 11a, 11b, 11c, 11d, 11e and 11f among the plurality of terminals 11.
  • the P2P network 21 includes a plurality of communication lines 22.
  • Each communication line 22x included in the plurality of communication lines 22 connects two terminals included in the plurality of terminals 11 so as to be able to communicate with each other.
  • Each terminal 11x knows the address of the terminal communicably connected to each terminal 11x, can transmit data to the terminal, and can receive data from the terminal.
  • Each terminal 11x is operated by one user who exclusively owns each terminal 11x. Therefore, the terminals 11a, 11b, 11c, 11d, 11e, 11f, ... Are operated by the users A, B, C, D, E, F, ..., Respectively. Each terminal 11x may be operated by two or more users who share each terminal 11x.
  • FIG. 3 is a block diagram schematically illustrating the hardware configuration of each terminal provided in the contract transaction system of the first embodiment.
  • Each terminal 11x is composed of a personal computer (PC) 31 illustrated in FIG.
  • PC personal computer
  • Each terminal 11x may be configured by an information processing device other than the PC 31.
  • each terminal 11x may be configured by a smartphone, a tablet, or the like.
  • the PC 31 includes a processor 32, a memory 33, and a storage 34.
  • the contract transaction program 35 is installed in the storage 34.
  • the contract transaction program 35 may be installed by writing the contract transaction program 35 read from the external recording medium 36 to the storage 34, or writing the contract transaction program 35 received via the network 37 to the storage 34. It may be done by.
  • the processor 32 is a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processing device (DSP), and the like.
  • the memory 33 is a random access memory (RAM) or the like.
  • the storage 34 is a hard disk drive, a solid state drive, a RAM disk, or the like.
  • the external recording medium 36 is a compact disc (CD), a digital multipurpose disc (DVD), a Blu-ray disc (BD), a universal serial bus (USB) memory, or the like.
  • the memory 33, the storage 34, and the external recording medium 36 are non-temporary, computer-readable recording media on which the contract transaction program 35 is recorded.
  • the contract transaction program 35 installed in the storage 34 is loaded into the memory 33, and the loaded contract transaction program 35 is executed by the processor 32.
  • the PC 31 operates as each terminal 11x.
  • each terminal 11x has an authentication information acquisition unit 41, a bid data acquisition unit 42, a bid data transmission unit 43, a contract result calculation unit 44, and a contract result transmission.
  • a unit 45, a contract result receiving unit 46, a contract result verification unit 47, a contract result selection unit 48, a block receiving unit 49, a block selection unit 50, and a contract result storage unit 51 are provided.
  • the bid data acquisition unit 42 includes a bid data reception unit 54 and a bid data creation unit 55.
  • These elements are configured by loading the contract transaction program 35 installed in the storage 34 into the memory 33 and executing the loaded contract transaction program 35 by the processor 32. Some of these elements may consist of hardware that does not execute the program.
  • FIG. 4 is a flowchart illustrating a flow of processing performed by each terminal provided in the contract transaction system of the first embodiment.
  • Each terminal 11x executes steps S101 to S111 shown in FIG.
  • step S101 the authentication information acquisition unit 41 performs the authentication information acquisition process. At that time, the authentication information acquisition unit 41 acquires the digital certificate 104 of each terminal 11x from the certificate authority 12, and stores the acquired digital certificate 104 of each terminal 11x.
  • the digital certificate 104 to be obtained is, for example, a public key infrastructure standard X.I. It is a digital certificate conforming to 509.
  • the bid data acquisition unit 42 performs the bid data acquisition process. At that time, the bid data acquisition unit 42 acquires the bid data 101 and saves the acquired bid data 101. As a result, the bid data acquisition unit 42 acquires the bid data group 103 and saves the acquired bid data group 103.
  • the acquired bid data 101 is received by the bid data receiving unit 54 from the bid data 101x received by the bid data receiving unit 54 from terminals not included in the plurality of terminals 11 and from other terminals 11y included in the plurality of terminals 11.
  • the creation of bid data on each terminal 11x is performed by the user of each terminal 11x operating each terminal 11x.
  • the terminals not included in the plurality of terminals 11 are terminals owned by the user and the like.
  • the terminal owned by the user is a smartphone or the like owned by the user.
  • FIG. 5 is a diagram illustrating an example of bid data acquired by each terminal provided in the contract transaction system of the first embodiment.
  • the acquired bid data 101 includes a bid data identifier (ID) 111, a time stamp 112, a terminal ID 113, a user ID 114, a product 115, a bid quantity 116, a bid unit price 117, and a trading category 118. And digital certificate 119.
  • the bid data ID 111, the time stamp 112, the terminal ID 113, the user ID 114, the product 115, the bid quantity 116, the bid unit price 117, the trading category 118, and the digital certificate 119 are from the first column to the ninth column of the table, respectively. It is described in.
  • the bid data ID 111 identifies the bid data 101.
  • the bid data ID 111 is determined so as not to overlap with the bid data ID included in other bid data.
  • the bid data ID 111 is a hash value or the like returned when the information of the terminal on which the bid data 101 is created, the time when the bid data 101 is created, or the like is given to the hash function as an argument.
  • the time stamp 112 indicates the time when the bid data 101 was created.
  • the time stamp 112 has an expression format of "yyyy / MM / dd / hh: mm: ss".
  • Yyyy indicates the year.
  • MM indicates the month.
  • Dd indicates the day.
  • Hh indicates the time.
  • Mm indicates a minute.
  • Ss indicates seconds.
  • the terminal ID 113 identifies the terminal on which the bid data 101 was created.
  • the user ID 114 identifies the user who created the bid data 101.
  • the product 115, the bid quantity 116, the bid unit price 117, and the trading category 118 indicate the product, the bid quantity, the bid unit price, and the trading category, which constitute the content of the bid represented by the bid data 101, respectively.
  • the buying and selling category 118 indicates whether the bid data 101 is the buy bid data or the sell bid data.
  • the fact that the trading category 118 is "buy” indicates that the bid data 101 is the bid data.
  • the fact that the buying / selling category 118 is "sell" indicates that the bidding data 101 is selling / bidding data.
  • the digital certificate 119 is a digital certificate of the terminal on which the bid data 101 is created.
  • the bid data ID 111 is, for example, "0002”.
  • the time stamp 112 is "2019/01/01/00: 00:30”.
  • the terminal ID 113 becomes the terminal ID of the terminal A.
  • the user ID 114 becomes the user ID of the user A.
  • the product 115 is "X”.
  • the bid quantity 116 is "2.0”.
  • the bid unit price 117 is "12”.
  • the trading category 118 is "buy”.
  • the digital certificate 119 becomes a "certificate A" which is a digital certificate of the terminal A.
  • the bid data transmission unit 43 performs the bid data transmission process. At that time, the bid data transmission unit 43 transmits the acquired bid data 101 to the other terminal 11y. The bid data transmission unit 43 broadcasts the acquired bid data 101 to another terminal 11y.
  • the contract result calculation unit 44 performs the contract result calculation process. At that time, the contract result calculation unit 44 calculates the contract result 102x from the acquired bid data group 103, and stores the calculated contract result 102x. When the bid deadline is set at 5-minute intervals, the contract result calculation unit 44 calculates the contract result 102x at 5-minute intervals. For example, when the current time is 00:05:00 on January 01, 2019, the execution result calculation unit 44 indicates a time stamp 112 indicating the time before 00:05:00 on January 01, 2019. The contract result 102x is calculated from the bid data group 103 including the bid data 101 including. The contract result calculation unit 44 concludes a contract transaction between a buy bid and a sell bid for each type of product 115. The combination of the buy bid and the sell bid to conclude the contract transaction, the contract amount and the contract price are determined by, for example, the same method as the pre-opening Itayose in the stock market.
  • FIG. 6 is a diagram illustrating an example of a contract result calculated by a terminal provided in the contract transaction system of the first embodiment.
  • 6 (a), 6 (b) and 6 (c) show the contract result 121a calculated by the terminal 11a, the contract result 121b calculated by the terminal 11b, and the contract result calculated by the terminal 11c, respectively.
  • An example of 121c is illustrated.
  • Each of the contract results 121x included in the contract results 121a, 121b and 121c includes the header 131 and the body 132 as shown in FIG.
  • the header 131 includes a contract result ID 141, a time stamp 142, a terminal ID 143, and a digital certificate 144.
  • the contract result ID 141, the time stamp 142, the terminal ID 143, and the digital certificate 144 are described in the first to fourth columns of the table, respectively.
  • the contract result ID 141 specifies each contract result 121x.
  • the contract result ID 141 is determined so as not to overlap with the contract result ID included in other contract results.
  • the contract result ID 141 is information on the terminal that calculated each contract result 121x, a hash value returned when the time at which each contract result 121x is calculated is given to the hash function as an argument, and the like.
  • the time stamp 142 indicates the time when each contract result 121x was calculated.
  • the time stamp 142 has an expression format of "yyyy / MM / dd / hh: mm: ss".
  • Yyyy indicates the year.
  • MM indicates the month.
  • Dd indicates the day.
  • Hh indicates the time.
  • Mm indicates a minute.
  • Ss indicates seconds.
  • the terminal ID 143 identifies the terminal for which each contract result 121x has been calculated.
  • the digital certificate 144 is a digital certificate of the terminal that calculated each contract result 121x.
  • the body 132 includes a buy bid data ID 151, a sell bid data ID 152, a contracted amount of 153, and a contracted unit price of 154.
  • the buy bid data ID 151, the sell bid data ID 152, the contracted amount 153, and the contracted unit price 154 are described in the first to fourth columns of the table, respectively.
  • the buy bid data ID 151 and the sell bid data ID 152 specify the buy bid data and the sell bid data representing the contents of the buy bid and the sell bid for which the contract transaction has been established, respectively.
  • the contracted amount 153 and the contracted unit price 154 indicate the contracted amount and the contracted unit price that constitute the contents of the executed contracted transaction, respectively.
  • the bid data ID 151 and the bid data ID 152 which represent the contents of the bid and the bid for which the contract transaction has been completed, are associated with each other.
  • each terminal 11x In order to conclude a contract transaction on the P2P network 21, each terminal 11x, not the server, must calculate the contract result 102x. However, when each terminal 11x calculates the contract result 102x, the plurality of bid data groups 103 acquired by the plurality of terminals 11 may not be the same due to the influence of communication delay, the topology of the P2P network 21, and the like. .. As a result, the plurality of contract results 102x calculated by the plurality of terminals 11 may not be the same.
  • the bid data group 103 acquired by the terminal 11a is composed of bid data 101 including the bid data IDs 111 of "0001", "0002", and "0003"
  • the bid data group 103 acquired by the terminal 11b is "0001".
  • the bid data group 103 including the bid data ID 111 of “0002” and the bid data group 103 acquired by the terminal 11c is composed of the bid data 101 including the bid data ID 111 of “0002” and “0003”, FIG.
  • the contract result 121a calculated by the terminal 11a, the contract result 121b calculated by the terminal 11b, and the contract result 121c calculated by the terminal 11c are not the same.
  • the selection of one contract result that is the final result from these contract results 121a, 121b and 121c is performed when the contract result selection process is performed in step S108.
  • the contract result transmission unit 45 performs the contract result transmission process. At that time, the contract result transmission unit 45 transmits the calculated contract result 102x to another terminal 11y. Further, the contract result transmitting unit 45 transmits the received other contract result 102y to the other terminal 11y when another contract result 102y received from the other terminal 11y by the contract result receiving unit 46 exists. .. The contract result transmission unit 45 broadcasts the calculated contract result 102x and the received other contract result 102y to the other terminal 11y.
  • the contract result receiving unit 46 performs the contract result receiving process. At that time, the contract result receiving unit 46 receives the other contract result 102y calculated by the other terminal 11y from the other terminal 11y, and stores the received other contract result 102y.
  • the contract result verification unit 47 performs the contract result verification process. At that time, the contract result verification unit 47 verifies the other contract result 102y received, and based on the result of the verified verification, the other contract result 102y is selected as a candidate for one contract result in step S108. It is determined whether or not. If the contract result verification unit 47 does not use the received other contract result 102y as a candidate for one selected contract result, the contract result verification unit 47 deletes the other contract result 102y.
  • the contract result verification unit 47 verifies whether or not the other contract result 102y is consistent. If the other contract results 102y received are consistent, the contract result verification unit 47 selects the other contract results 102y as one candidate for the contract result to be selected. Further, when the other contract result 102y received is not consistent, the contract result verification unit 47 deletes the other contract result 102y without making it a candidate for one selected contract result.
  • Verification of whether or not there is consistency includes, for example, the following verification.
  • the digital certificate 119 included in each of the bid data ID 151 included in the other contract result 102y and the bid data 101 specified by the sell bid data ID 152 matches the digital certificate 104 obtained from the certificate authority 12. Verification of whether to do, (2) Verification of whether or not the digital certificate 144 included in the other contract result 102y matches the digital certificate 104 obtained from the certificate authority 12. (3) The time indicated by the time stamp 112 included in each of the bid data ID 151 included in the other contract result 102y and the bid data 101 specified by the sell bid data ID 152 is a time stamp included in the other contract result 102y.
  • the bid unit price 117 included in the bid data 101 specified by the bid data ID 151 included in the other contract result 102y is the sale specified by the bid data ID 152 associated with the bid data ID 151. Verification of whether or not the bid unit price included in the bid data 101 is 117 or less, (5) The bid unit price 117 included in the sell / bid data 101 specified by the sell / bid data ID 152 included in the other contract result 102y is the buy specified by the buy / bid data ID 151 associated with the sell / bid data ID 152.
  • Verification of whether or not the bid unit price included in the bid data 101 is 117 or more, (6) The total of the bid quantity 116 included in the buy bid data 101 specified by the buy bid data ID 151 included in the other contract result 102y is specified by the sell bid data ID 152 associated with the buy bid data ID 151. Verification of whether or not the bid quantity is 116 or less included in the sell bid data 101, and (7) the bid quantity 116 included in the sell bid data 101 specified by the sell bid data ID 152 included in the other contract result 102y. Verification of whether or not the total is less than or equal to the bid quantity 116 included in the buy / bid data 101 specified by the buy / bid data ID 151 associated with the sell / bid data ID 152.
  • the contract result selection unit 48 performs the contract result selection process. At that time, the contract result selection unit 48 selects one contract result from the calculated contract result 102x and the other contract results 102y received. When it is determined whether or not the other contract result 102y is to be selected as a candidate for one contract result, the contract result selection unit 48 is one of the contract result 102x and the other candidate contract result 102y. Select the contract result of. When the bid deadline is set at 5 minute intervals, the contract result selection unit 48 selects one contract result at 5 minute intervals, and the contract result 102x calculated in the past 5 minutes and other contract results. Select one contract result from 102y. The contract result selection unit 48 selects one contract result based on the selection index 107.
  • FIG. 7 is a diagram illustrating an example of a selection index referred to by each terminal provided in the contract trading system of the first embodiment.
  • the selection index 107 shown in FIG. 7 is a selection index of "maximum contracted total amount".
  • the selection index 107 is the selection index of "maximum contract total amount”
  • the contract result having the maximum total of the contract amount 153 included in the calculated contract result 102x and the other contract results 102y received is selected. It becomes one contract result to be done.
  • the bid deadline is set at 5-minute intervals, and the current time is January 01, 2019 00:10:00 and calculated at January 01, 2019 00:05:00.
  • the total of the contract amount 153 included in the contract result 121b is 3.0
  • the total of the contract amount 153 included in the contract result 121c is 3.0.
  • the total is 1.0. Therefore, the contract result 121a in which the total of the contracted quantities 153 is 4.0, which is the maximum, becomes one contract result to be selected. Thereby, even if the plurality of contract results 102x calculated by the plurality of terminals 11 are not the same, one contract result to be relied on can be specified.
  • the block receiving unit 49 performs the block receiving process. At that time, the block receiving unit 49 receives the past block 108 including the past one contract result selected before the one contract result is selected in step S108 from the other terminal 11y.
  • the block receiving unit 49 receives the past block 108 from the other terminal 11y when the past block 108 is not stored in each terminal 11x. For example, the deadline for bidding is set at 5 minute intervals, and the previous contract result including one contract result selected 5 minutes ago at 00:00:00 on January 01, 2019 due to a failure of the terminal 11a, etc. If the block is not saved in the terminal 11a and the terminal 11a recovers at 00:05:00 on January 01, 2019, the block receiver 49 provided in the terminal 11a sets the previous block to another. Receive from terminal 11y.
  • the block selection unit 50 performs the block selection process. At that time, the block selection unit 50 selects a past block 108 to be followed by a new block from a plurality of past blocks received by the block reception unit 49, and stores the selected past block 108.
  • the selected past block 108 is the largest number of past blocks determined by taking a majority vote in a plurality of past blocks received by the block receiving unit 49.
  • the contract result storage unit 51 performs the contract result storage process. At that time, the contract result storage unit 51 saves one selected contract result and updates the bid data 101.
  • the updated bid data 101 is bid data obtained by replacing the bid quantity included in the bid data 101 before update with a new bid quantity obtained by subtracting a contracted amount from the bid quantity.
  • the contract result storage unit 51 saves a new block including one selected contract result. The new block to be saved follows the selected past block 108.
  • FIG. 8 illustrates an example of a block stored in each terminal provided in the contract trading system of the first embodiment.
  • the new block 161 is made to follow the previous block 162 as shown in FIG.
  • the new block 161 contains one selected contract result 171 and a hash value 172.
  • the previous block 162 contains one execution result 173 and a hash value 174 selected 5 minutes ago.
  • the hash value 174 is a hash value returned when a block (not shown) two times before is given to the hash function 175 as an argument.
  • the hash value 172 is a hash value returned when the previous block 162 is given as an argument to the hash function 175.
  • the first embodiment it is not necessary to conclude a contract transaction on the server as in the case where the client-server model is adopted, and the P2P network 21 composed of a plurality of terminals 11 It is possible to conclude a contract transaction at. Thereby, it is possible to provide the contract trading system 1 having no single point of failure.
  • one contract result 171 to be relied on can be specified from a plurality of contract results that are not the same.
  • FIG. 9 is a block diagram schematically illustrating the contract trading system of the second embodiment.
  • FIG. 10 is a flowchart illustrating the flow of processing performed by each terminal provided in the contract transaction system of the second embodiment.
  • the contract transaction system 2 of the second embodiment shown in FIG. 9 differs from the contract transaction system 1 of the first embodiment shown in FIG. 1 mainly in the following points. Regarding points not described below, the same configuration as that adopted in the contract trading system 1 is also adopted in the contract trading system 2.
  • Each terminal 11x provided in the contract transaction system 2 further includes an incentive calculation unit 52 as shown in FIG. Further, each terminal 11x provided in the contract transaction system 2 further executes step S112 as shown in FIG.
  • step S112 the incentive calculation unit 52 performs the incentive calculation process. At that time, the incentive calculation unit 52 calculates the incentive for the terminal that has calculated one of the selected contract results. The user of the terminal can obtain the calculated incentive. The incentive calculation unit 52 calculates the incentive based on the incentive ratio 109.
  • FIG. 11 is a diagram illustrating an example of an incentive ratio referred to by each terminal provided in the contract trading system of the second embodiment.
  • FIG. 12 is a diagram illustrating an example of an incentive calculated by each terminal provided in the contract trading system of the second embodiment.
  • the incentive ratio 109 shown in FIG. 11 is an incentive ratio of “1%”. If the incentive ratio 109 is an incentive ratio of "1%” and one of the selected contract results is the contract result 121a shown in FIG. 6 (a), the incentive 181 shown in FIG. 12 is calculated. NS.
  • the incentive 181 illustrated in FIG. 12 includes a buy bid data ID 191 and a sell bid data ID 192 and a commission 193.
  • the buy bid data ID 191 and the sell bid data ID 192 and the commission 193 are described in the first to third columns of the table, respectively.
  • the buy bid data ID 191 and the sell bid data ID 192 specify the buy bid data and the sell bid data representing the contents of the buy bid and the sell bid for which the contract transaction has been established, respectively.
  • the commission 193 indicates a commission paid to the user of the terminal that has calculated the contract result indicating the result of the executed contract transaction.
  • the commission 193 is the product of the contract amount 153 included in the contract result indicating the result of the executed contract transaction, the contract unit price 154 included in the contract result, and the incentive ratio 109.
  • the bid bid has a bid bid having the content represented by the bid data specified by the bid data ID 191 "0001" and a content represented by the bid data specified by the bid data ID 192 "0002".
  • the buyer user B who created the bid data specified by the bid data ID 191 of "0001” pays the fee 193 of "0.345” to the user A of the terminal 11a having the digital certificate 144 of "certificate A”. ..
  • the bid bid has a content represented by the bid data specified by the bid data ID 191 of "0003” and a content represented by the bid data specified by the bid data ID 192 of "0002".
  • the buyer user C who created the bid data specified by the bid data ID 191 of "0003” pays the fee 193 of "0.11" to the user A of the terminal 11a having the digital certificate of "certificate A".
  • the buying user and the selling user may pay the fee 193 in half.
  • the selling user may pay a fee of 193.
  • step S111 the contract result storage unit 51 performs the contract result storage process. At that time, the contract result storage unit 51 stores the incentive 181 calculated together with one selected contract result, and updates the bid data 101.
  • the second embodiment has the same effect as that of the first embodiment.
  • the second embodiment has the effects described below.
  • FIG. 13 is a diagram schematically illustrating an example of the topology of the P2P network.
  • the communication line 202 for communicably connecting the terminal set 201a including the terminal 11a and the terminal set 201b including the terminal 11b is the terminal 11a and the terminal 11b. It consists only of a communication line 203 that connects the two to each other so as to be able to communicate with each other. Therefore, when the communication via the communication line 203 is cut off, the P2P network 21 is divided, and the contract result calculated in the terminal set 201a and the contract result calculated in the terminal set 201b are different from each other. become.
  • the user of the terminal who has calculated one of the selected contract results can obtain the incentive 181. Therefore, in order to obtain the incentive 181, there is a motivation to increase the bid data 101 received by each terminal 11x and increase the bid data 101 reflected in the contract result 102x calculated by each terminal 11x. Then, in order to increase the bid data 101 received by each terminal 11x, it is effective to increase the number of terminals to which each terminal 11x is communicably connected. Therefore, the communication lines 22 constituting the plurality of communication lines 22 There is an incentive to increase the number of. As a result, it is possible to suppress that the P2P network 21 is divided, and it is possible to suppress that the contract result calculated in the terminal set 201a and the contract result calculated in the terminal set 201b are different from each other. can.
  • FIG. 14 is a block diagram schematically illustrating the contract trading system of the third embodiment.
  • FIG. 15 is a flowchart illustrating the flow of processing performed by each terminal provided in the contract transaction system of the third embodiment.
  • the contract transaction system 3 of the third embodiment shown in FIG. 14 differs from the contract transaction system 1 of the first embodiment shown in FIG. 1 mainly in the following points. Regarding points not described below, the same configuration as that adopted in the contract trading system 1 is also adopted in the contract trading system 3.
  • Each terminal 11x provided in the contract transaction system 3 further includes a terminal evaluation unit 53 as shown in FIG. Further, each terminal 11x provided in the contract transaction system 3 further executes step S113 as shown in FIG.
  • step S113 the terminal evaluation unit 53 performs the terminal evaluation process. At that time, the terminal evaluation unit 53 evaluates the other terminal 11y, and selects the terminal of the transmission source of the past block 108 from the other terminal 11y based on the result of the evaluation. The terminal evaluation unit 53 evaluates the other terminal 11y based on the evaluation index 110.
  • FIG. 16 is a diagram illustrating an example of an evaluation index referred to by each terminal provided in the contract trading system of the third embodiment.
  • the evaluation index 110 illustrated in FIG. 16 is an evaluation index called "the number of times the contract result is calculated".
  • the terminal evaluation unit 53 refers to the past block that has already been received and extracts another terminal 11y for which the contract result has been calculated. Further, the terminal evaluation unit 53 arranges the other terminals 11y in descending order by the number of times the contract result is calculated, and sets the other terminal 11y of the set number of higher ranks as the terminal of the transmission source of the past block 108.
  • step S109 the block receiving unit 49 performs the block receiving process. At that time, the block receiving unit 49 receives the past block 108 from the terminal of the source of the selected past block 108.
  • the third embodiment has the same effect as that of the first embodiment.
  • the third embodiment has the effects described below.
  • the block receiving unit 49 receives a plurality of past blocks from a plurality of other terminals 11y when the past block 108 is not stored in each terminal 11x. Further, the block selection unit 50 selects the past block 108 to which a new block is succeeded from the plurality of received past blocks.
  • the past block 108 to be selected is determined by taking a majority vote in the plurality of received past blocks. However, in order to make the result of the majority vote credible, the block receiving unit 49 must receive a large number of past blocks, and the load applied to each terminal 11x when the block receiving process is performed is large. Become.
  • the past block 108 is received from the selected source terminal of the past block 108. Therefore, it is not necessary for the block receiving unit 49 to receive a large number of past blocks, and the load applied to each terminal 11x when the block receiving process is performed is reduced.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

単一障害点を有さず、同じでない複数の約定結果から依拠すべきひとつの約定結果を特定することができる約定取引システムを提供する。ピアツーピア端末は、入札データ取得部、入札データ送信部、約定結果算出部、約定結果送信部、約定結果受信部及び約定結果選定部を備える。入札データ取得部は、入札データを取得する。入札データ送信部は、入札データを他のピアツーピア端末に送信する。約定結果算出部は、入札データ取得部により取得された入札データ群から約定結果を算出する。約定結果送信部は、約定結果を他のピアツーピア端末に送信する。約定結果受信部は、他のピアツーピア端末により算出された他の約定結果を他のピアツーピア端末から受信する。約定結果選定部は、約定結果及び他の約定結果からひとつの約定結果を選定する。

Description

ピアツーピア端末及び約定取引システム
　本開示は、ピアツーピア端末及び約定取引システムに関する。
　コンテンツを販売したい者とコンテンツを購入したい者とをネットワークを介してマッチングして約定取引を成立させる約定取引システムが提案されている。
　例えば、特許文献１に記載された金融資産取引システムにおいては、金融資産の取引を望むユーザが、クライアント端末装置を操作する（段落００１２）。また、取引所サーバ装置が、各クライアント端末装置からネットワーク経由で送信されてくる取引情報を受信し、受信した取引情報に基づいて取引の取りまとめの処理を行う（段落００１３）。
実用新案登録第３２１９５１６号公報
　特許文献１に記載された金融資産取引システムに代表される従来の約定取引システムは、クライアントサーバモデルを採用する。このため、サーバが約定取引を成立させる処理を行う。このため、サーバが単一障害点となる。したがって、サーバが故障した場合は、約定取引システムを維持することができない。また、サーバへの不正アクセス、マルウェアの感染を阻止するためには、サーバのセキュリティ強度を高くしなければならない。したがって、サーバのセキュリティ強度を高くするためのコストがかかる。
　一方、ブロックチェーン等のピアツーピア（Ｐ２Ｐ；Peer to Peer）ネットワークにおいては、対等の端末同士が互いに通信を行う。このため、Ｐ２Ｐネットワークは、上述したサーバのような単一障害点を有さない。しかし、Ｐ２Ｐネットワークは、上述したサーバのような全体を管理する端末を備えない。このため、Ｐ２Ｐネットワークに備えられる各端末が約定取引を成立させる処理を行った場合に、複数の端末によりそれぞれ算出される複数の約定結果が同じでないことがある。このため、依拠すべきひとつの約定結果を特定することができない。
　本開示は、これらの問題に鑑みてなされた。本開示は、単一障害点を有さず、同じでない複数の約定結果から依拠すべきひとつの約定結果を特定することができる約定取引システムを提供することを目的とする。
　本開示は、ピアツーピア端末に関する。
　ピアツーピア端末は、入札データ取得部、入札データ送信部、約定結果算出部、約定結果送信部、約定結果受信部及び約定結果選定部を備える。
　入札データ取得部は、入札データを取得する。
　入札データ送信部は、入札データを他のピアツーピア端末に送信する。
　約定結果算出部は、入札データ取得部により取得された入札データ群から約定結果を算出する。
　約定結果送信部は、約定結果を他のピアツーピア端末に送信する。
　約定結果受信部は、他のピアツーピア端末により算出された他の約定結果を他のピアツーピア端末から受信する。
　約定結果選定部は、約定結果及び他の約定結果からひとつの約定結果を選定する。
　本開示は、当該ピアツーピア端末を備える約定取引システムにも向けられる。
　本開示によれば、複数のピアツーピア端末により構成されるピアツーピアネットワークにおいて約定取引を成立させることができる。これにより、単一障害点を有さない約定取引システムを提供することができる。また、同じでない複数の約定結果から、依拠すべきひとつの約定結果を特定することができる約定取引システムを提供することができる。
　本開示の目的、特徴、局面及び利点は、以下の詳細な説明と添付図面とによって、より明白となる。
実施の形態１の約定取引システムを模式的に図示するブロック図である。 実施の形態１の約定取引システムに備えられる複数の端末により構成されるピアツーピア（Ｐ２Ｐ）ネットワークを模式的に図示するネットワーク図である。 実施の形態１の約定取引システムに備えられる各端末のハードウェア構成を模式的に図示するブロック図である。 実施の形態１の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。 実施の形態１の約定取引システムに備えられる各端末により取得される入札データの例を図示する図である。 実施の形態１の約定取引システムに備えられる端末により算出される約定結果の例を図示する図である。 実施の形態１の約定取引システムに備えられる各端末により参照される選定指標の例を図示する図である。 実施の形態１の約定取引システムに備えられる各端末に保存されるブロックの例を図示する図である。 実施の形態２の約定取引システムを模式的に図示するブロック図である。 実施の形態２の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。 実施の形態２の約定取引システムに備えられる各端末により参照されるインセンティブ比率の例を図示する図である。 実施の形態２の約定取引システムに備えられる各端末により算出されるインセンティブの例を図示する図である。 Ｐ２Ｐネットワークのトポロジーの例を模式的に図示する図である。 実施の形態３の約定取引システムを模式的に図示するブロック図である。 実施の形態３の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。 実施の形態３の約定取引システムに備えられる各端末により参照される評価指標の例を図示する図である。
　１　実施の形態１
　１．１　約定取引システムの概略
　図１は、実施の形態１の約定取引システムを模式的に図示するブロック図である。
　図１に図示される実施の形態１の約定取引システム１は、ユーザにより作成された入札データ１０１を取得する。取得される入札データ１０１は、商材を取引する意思を有することを表明する入札の内容を表す。入札データ１０１は、買入札データ又は売入札データである。買入札データは、商材を買う意思を有することを表明する買入札の内容を表す。売入札データは、商材を売る意思を有することを表明する売入札の内容を表す。商材は、証券、電力、ガス、小麦、金等である。
　また、約定取引システム１は、買入札と売入札との間で約定取引を成立させ、成立させた約定取引の結果を示す約定結果１０２を算出する。約定取引システム１は、買入札データを作成した買い方のユーザが、買入札データにより表される入札価格以下の価格で商材を買うことができ、売入札データを作成した売り方のユーザが、売入札データにより表される入札価格以上の価格で商材を売ることができるように、約定取引を成立させる。
　約定取引システム１には、入札の締め切り時刻が設定される。約定取引システム１は、設定された入札の締め切り時刻までに取得した買入札データにより表される内容を有する買入札と、設定された入札の締め切り時刻までに取得した売入札データにより表される内容を有する売入札と、の間で約定取引を成立させる。約定取引システム１は、設定された入札の締め切り時刻に約定取引を成立させる。入札の締め切り時刻は、例えば、一定時間間隔で設定される。一定時間間隔は、例えば、5分間隔である。一定時間間隔が5分間隔である場合は、例えば、任意の時TTについて、TT時00分、TT時05分、TT時10分、TT時15分、TT時20分、TT時25分、TT時30分、TT時35分、TT時40分、TT時45分、TT時50分及びTT時55分が入札の締め切り時刻に設定される。
　１．２　約定取引システムに備えられる要素
　約定取引システム１は、図１に図示されるように、複数の端末１１及び認証局１２を備える。図１には、複数の端末１１のうち、端末１１ａ及び１１ｂのみが図示される。
　図１においては、便宜上、端末１１ａが、複数の端末１１に含まれる各端末１１ｘとして扱われており、端末１１ｂが、複数の端末１１に含まれる他の端末１１ｙとして扱われている。
　各端末１１ｘは、ピアツーピア（Ｐ２Ｐ）ネットワークを構成するＰ２Ｐ端末である。
　各端末１１ｘは、入札データ１０１を取得する。取得される入札データ１０１は、複数の端末１１に含まれない端末から各端末１１ｘが受信する入札データ１０１ｘ、複数の端末１１に含まれる他の端末１１ｙから各端末１１ｘが受信する入札データ１０１ｙ、又は各端末１１ｘにおいて作成される図示されない入札データである。これにより、各端末１１ｘは、入札データ群１０３を取得する。
　また、各端末１１ｘは、取得した入札データ１０１を他の端末１１ｙに送信する。
　また、各端末１１ｘは、買入札と売入札との間で約定取引を成立させ、成立させた約定取引の結果を示す約定結果１０２ｘを算出する。
　複数の端末１１によりそれぞれ取得される複数の入札データ群１０３が同じである場合は、複数の端末１１によりそれぞれ算出される複数の約定結果１０２ｘも同じである。しかし、通信の遅延、複数の端末１１により構成されるＰ２Ｐネットワークのトポロジー等の影響により当該複数の入札データ群１０３が同じでない場合は、当該複数の約定結果１０２ｘが同じでないことがある。各端末１１ｘは、当該複数の約定結果１０２ｘが同じでない場合に、当該複数の約定結果１０２ｘから依拠すべきひとつの約定結果を選定する。
　認証局１２は、各端末１１ｘのデジタル証明書１０４を発行する。
　１．３　Ｐ２Ｐネットワーク
　図２は、実施の形態１の約定取引システムに備えられる複数の端末により構成されるＰ２Ｐネットワークを模式的に図示するネットワーク図である。
　図２に図示されるＰ２Ｐネットワーク２１は、複数の端末１１を備える。図２には、複数の端末１１のうち、端末１１ａ，１１ｂ，１１ｃ，１１ｄ，１１ｅ及び１１ｆのみが図示される。
　Ｐ２Ｐネットワーク２１は、図２に図示されるように、複数の通信線２２を備える。複数の通信線２２に含まれる各通信線２２ｘは、複数の端末１１に含まれるふたつの端末を互いに通信可能に接続する。
　各端末１１ｘは、各端末１１ｘに通信可能に接続された端末のアドレスを知っており、当該端末にデータを送信することができ、当該端末からデータを受信することができる。
　各端末１１ｘは、各端末１１ｘを専有するひとりのユーザにより操作される。したがって、端末１１ａ，１１ｂ，１１ｃ，１１ｄ，１１ｅ，１１ｆ，・・・は、それぞれ、ユーザA,B,C,D,E,F,・・・により操作される。各端末１１ｘが、各端末１１ｘを共有するふたり以上のユーザにより操作されてもよい。
　１．４　各端末のハードウェア構成
　図３は、実施の形態１の約定取引システムに備えられる各端末のハードウェア構成を模式的に図示するブロック図である。
　各端末１１ｘは、図３に図示されるパーソナルコンピューター（ＰＣ）３１により構成される。各端末１１ｘが、ＰＣ３１以外の情報処理装置により構成されてもよい。例えば、各端末１１ｘが、スマートフォン、タブレット等により構成されてもよい。
　ＰＣ３１は、図３に図示されるように、プロセッサ３２、メモリ３３及びストレージ３４を備える。
　ストレージ３４には、約定取引プログラム３５がインストールされる。約定取引プログラム３５のインストールは、外部記録媒体３６から読み出した約定取引プログラム３５をストレージ３４に書き込むことにより行われてもよいし、ネットワーク３７を経由して受信した約定取引プログラム３５をストレージ３４に書き込むことにより行われてもよい。
　プロセッサ３２は、中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、デジタル信号処理装置（ＤＳＰ）等である。メモリ３３は、ランダムアクセスメモリ（ＲＡＭ）等である。ストレージ３４は、ハードディスクドライブ、ソリッドステートドライブ、ＲＡＭディスク等である。外部記録媒体３６は、コンパクトディスク（ＣＤ）、デジタル多目的ディスク（ＤＶＤ）、ブルーレイディスク（ＢＤ）、ユニバーサルシリアルバス（ＵＳＢ）メモリ等である。
　メモリ３３、ストレージ３４及び外部記録媒体３６は、約定取引プログラム３５を記録した非一時的でコンピュータ読み取り可能な記録媒体である。
　ＰＣ３１においては、ストレージ３４にインストールされた約定取引プログラム３５がメモリ３３にロードされ、ロードされた約定取引プログラム３５がプロセッサ３２により実行される。これにより、ＰＣ３１は、各端末１１ｘとして動作する。
　１．５　各端末に備えられる要素
　各端末１１ｘは、図１に図示されるように、認証情報取得部４１、入札データ取得部４２、入札データ送信部４３、約定結果算出部４４、約定結果送信部４５、約定結果受信部４６、約定結果検証部４７、約定結果選定部４８、ブロック受信部４９、ブロック選定部５０及び約定結果保存部５１を備える。入札データ取得部４２は、入札データ受信部５４及び入札データ作成部５５を備える。
　これらの要素は、ストレージ３４にインストールされた約定取引プログラム３５がメモリ３３にロードされ、ロードされた約定取引プログラム３５がプロセッサ３２により実行されることにより、構成される。これらの要素の一部がプログラムを実行しないハードウェアにより構成されてもよい。
　１．６　各端末が行う処理の流れ
　図４は、実施の形態１の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。
　各端末１１ｘは、図４に図示されるステップＳ１０１からＳ１１１までを実行する。
　ステップＳ１０１においては、認証情報取得部４１が、認証情報取得処理を行う。認証情報取得部４１は、その際に、各端末１１ｘのデジタル証明書１０４を認証局１２から取得し、取得した各端末１１ｘのデジタル証明書１０４を保存する。取得されるデジタル証明書１０４は、例えば、国際電気通信連合の電気通信標準化部門（ＩＴＵ－Ｔ）により定められた、公開鍵基盤の規格Ｘ．５０９に準拠するデジタル証明書である。
　続くステップＳ１０２においては、入札データ取得部４２が、入札データ取得処理を行う。入札データ取得部４２は、その際に、入札データ１０１を取得し、取得した入札データ１０１を保存する。これにより、入札データ取得部４２は、入札データ群１０３を取得し、取得した入札データ群１０３を保存する。取得される入札データ１０１は、複数の端末１１に含まれない端末から入札データ受信部５４が受信する入札データ１０１ｘ、複数の端末１１に含まれる他の端末１１ｙから入札データ受信部５４が受信する入札データ１０１ｙ、入札データ作成部５５を用いて各端末１１ｘにおいて作成される図示されない入札データ等である。各端末１１ｘにおける入札データの作成は、各端末１１ｘのユーザが各端末１１ｘを操作することにより行われる。複数の端末１１に含まれない端末は、ユーザが所有する端末等である。ユーザが所有する端末は、ユーザが所有するスマートフォン等である。
　図５は、実施の形態１の約定取引システムに備えられる各端末により取得される入札データの例を図示する図である。
　取得される入札データ１０１は、図５に図示されるように、入札データ識別子（ＩＤ）１１１、タイムスタンプ１１２、端末ＩＤ１１３、ユーザＩＤ１１４、商材１１５、入札数量１１６、入札単価１１７、売買区分１１８及びデジタル証明書１１９を含む。
　入札データＩＤ１１１、タイムスタンプ１１２、端末ＩＤ１１３、ユーザＩＤ１１４、商材１１５、入札数量１１６、入札単価１１７、売買区分１１８及びデジタル証明書１１９は、それぞれ、テーブルの第１列目から第９列目までに記述される。
　入札データＩＤ１１１は、入札データ１０１を特定する。入札データＩＤ１１１は、他の入札データに含まれる入札データＩＤと重複しないように決定される。入札データＩＤ１１１は、入札データ１０１が作成された端末の情報、入札データ１０１が作成された時刻等を引数としてハッシュ関数に与えた場合に返されるハッシュ値等である。
　タイムスタンプ１１２は、入札データ１０１が作成された時刻を示す。タイムスタンプ１１２は、「yyyy/MM/dd/hh:mm:ss」という表現形式を有する。「yyyy」は、年を示す。「MM」は、月を示す。「dd」は、日を示す。「hh」は、時を示す。「mm」は、分を示す。「ss」は、秒を示す。
　端末ＩＤ１１３は、入札データ１０１が作成された端末を特定する。
　ユーザＩＤ１１４は、入札データ１０１を作成したユーザを特定する。
　商材１１５、入札数量１１６、入札単価１１７及び売買区分１１８は、それぞれ、入札データ１０１により表される入札の内容を構成する商材、入札数量、入札単価及び売買区分を示す。売買区分１１８は、入札データ１０１が買入札データ及び売入札データのいずれであるのかを示す。売買区分１１８が「買」であることは、入札データ１０１が買入札データであることを示す。売買区分１１８が「売」であることは、入札データ１０１が売入札データであることを示す。
　デジタル証明書１１９は、入札データ１０１が作成された端末のデジタル証明書である。
　商材「X」を入札単価「12」で入札数量「2.0」だけ買う意思を有することを表明する買入札の内容を表す買入札データを2019年01月01日00時00分30秒にユーザAが端末Aにおいて作成した場合は、入札データＩＤ１１１は、例えば、「0002」となる。また、タイムスタンプ１１２は、「2019/01/01/00:00:30」となる。また、端末ＩＤ１１３は、端末Aの端末ＩＤとなる。また、ユーザＩＤ１１４は、ユーザAのユーザＩＤとなる。また、商材１１５は、「X」となる。また、入札数量１１６は、「2.0」となる。また、入札単価１１７は、「12」となる。また、売買区分１１８は、「買」となる。また、デジタル証明書１１９は、端末Aのデジタル証明書である「証明書A」となる。
　続くステップＳ１０３においては、入札データ送信部４３が、入札データ送信処理を行う。入札データ送信部４３は、その際に、取得された入札データ１０１を他の端末１１ｙに送信する。入札データ送信部４３は、取得された入札データ１０１を他の端末１１ｙにブロードキャストする。
　続くステップＳ１０４においては、約定結果算出部４４が、約定結果算出処理を行う。約定結果算出部４４は、その際に、取得された入札データ群１０３から約定結果１０２ｘを算出し、算出した約定結果１０２ｘを保存する。入札の締め切り時刻が5分間隔で設定される場合は、約定結果算出部４４は、5分間隔で約定結果１０２ｘを算出する。例えば、約定結果算出部４４は、現在の時刻が2019年01月01日00時05分00秒である場合は、2019年01月01日00時05分00秒以前の時刻を示すタイムスタンプ１１２を含む入札データ１０１からなる入札データ群１０３から約定結果１０２ｘを算出する。約定結果算出部４４は、商材１１５の種類ごとに買入札と売入札との間で約定取引を成立させる。約定取引を成立させる買入札と売入札との組み合わせ、約定数量及び約定価格は、例えば、株式市場における開場前の板寄せと同様の方法により決定される。
　図６は、実施の形態１の約定取引システムに備えられる端末により算出される約定結果の例を図示する図である。
　図６（ａ）、図６（ｂ）及び図６（ｃ）は、それぞれ、端末１１ａにより算出される約定結果１２１ａ、端末１１ｂにより算出される約定結果１２１ｂ、及び端末１１ｃにより算出される約定結果１２１ｃの例を図示する。
　約定結果１２１ａ，１２１ｂ及び１２１ｃに含まれる各約定結果１２１ｘは、図６に図示されるように、ヘッダ１３１及びボディ１３２を含む。
　ヘッダ１３１は、図６に図示されるように、約定結果ＩＤ１４１、タイムスタンプ１４２、端末ＩＤ１４３及びデジタル証明書１４４を含む。
　約定結果ＩＤ１４１、タイムスタンプ１４２、端末ＩＤ１４３及びデジタル証明書１４４は、それぞれ、テーブルの第１列目から第４列目までに記述される。
　約定結果ＩＤ１４１は、各約定結果１２１ｘを特定する。約定結果ＩＤ１４１は、他の約定結果に含まれる約定結果ＩＤと重複しないように決定される。約定結果ＩＤ１４１は、各約定結果１２１ｘを算出した端末の情報、各約定結果１２１ｘが算出された時刻等を引数としてハッシュ関数に与えた場合に返されるハッシュ値等である。
　タイムスタンプ１４２は、各約定結果１２１ｘが算出された時刻を示す。タイムスタンプ１４２は、「yyyy/MM/dd/hh:mm:ss」という表現形式を有する。「yyyy」は、年を示す。「MM」は、月を示す。「dd」は、日を示す。「hh」は、時を示す。「mm」は、分を示す。「ss」は、秒を示す。
　端末ＩＤ１４３は、各約定結果１２１ｘを算出した端末を特定する。
　デジタル証明書１４４は、各約定結果１２１ｘを算出した端末のデジタル証明書である。
　ボディ１３２は、図６に図示されるように、買入札データＩＤ１５１、売入札データＩＤ１５２、約定数量１５３及び約定単価１５４を含む。
　買入札データＩＤ１５１、売入札データＩＤ１５２、約定数量１５３及び約定単価１５４は、それぞれ、テーブルの第１列目から第４列目までに記述される。
　買入札データＩＤ１５１及び売入札データＩＤ１５２は、それぞれ、約定取引が成立させられた買入札及び売入札の内容を表す買入札データ及び売入札データを特定する。
　約定数量１５３及び約定単価１５４は、それぞれ、成立させられた約定取引の内容を構成する約定数量及び約定単価を示す。
　ボディ１３２においては、約定取引が成立させられた買入札及び売入札の内容をそれぞれ表す買入札データＩＤ１５１及び売入札データＩＤ１５２が互いに紐づけられる。
　Ｐ２Ｐネットワーク２１において約定取引を成立させるためには、サーバではなく各端末１１ｘが約定結果１０２ｘを算出しなければならない。しかし、各端末１１ｘが約定結果１０２ｘを算出する場合は、通信の遅延、Ｐ２Ｐネットワーク２１のトポロジー等の影響により、複数の端末１１によりそれぞれ取得される複数の入札データ群１０３が同じでないことがある。その結果として、複数の端末１１によりそれぞれ算出される複数の約定結果１０２ｘが同じでないことがある。例えば、端末１１ａにより取得された入札データ群１０３が「0001」、「0002」及び「0003」という入札データＩＤ１１１を含む入札データ１０１からなり、端末１１ｂにより取得された入札データ群１０３が「0001」及び「0002」という入札データＩＤ１１１を含む入札データ１０１からなり、端末１１ｃにより取得された入札データ群１０３が「0002」及び「0003」という入札データＩＤ１１１を含む入札データ１０１からなる場合は、図６に図示されるように、端末１１ａにより算出される約定結果１２１ａ、端末１１ｂにより算出される約定結果１２１ｂ、及び端末１１ｃにより算出される約定結果１２１ｃは、同じではない。これらの約定結果１２１ａ，１２１ｂ及び１２１ｃからの最終結果となるひとつの約定結果の選定は、ステップＳ１０８において約定結果選定処理が行われる際に行われる。
　続くステップＳ１０５においては、約定結果送信部４５が、約定結果送信処理を行う。約定結果送信部４５は、その際に、算出された約定結果１０２ｘを他の端末１１ｙに送信する。また、約定結果送信部４５は、約定結果受信部４６により他の端末１１ｙから受信された他の約定結果１０２ｙが存在する場合は、受信された他の約定結果１０２ｙを他の端末１１ｙに送信する。約定結果送信部４５は、算出された約定結果１０２ｘ及び受信された他の約定結果１０２ｙを他の端末１１ｙにブロードキャストする。
　続くステップＳ１０６においては、約定結果受信部４６が、約定結果受信処理を行う。約定結果受信部４６は、その際に、他の端末１１ｙにより算出された他の約定結果１０２ｙを他の端末１１ｙから受信し、受信した他の約定結果１０２ｙを保存する。
　続くステップＳ１０７においては、約定結果検証部４７が、約定結果検証処理を行う。約定結果検証部４７は、その際に、受信された他の約定結果１０２ｙの検証を行い、行った検証の結果に基づいて他の約定結果１０２ｙをステップＳ１０８において選定されるひとつの約定結果の候補とするか否かを判定する。また、約定結果検証部４７は、受信された他の約定結果１０２ｙを選定されるひとつの約定結果の候補としなかった場合は、当該他の約定結果１０２ｙを削除する。
　約定結果検証部４７は、受信された他の約定結果１０２ｙの検証を行う際に、他の約定結果１０２ｙが整合性を有するか否かの検証を行う。約定結果検証部４７は、受信された他の約定結果１０２ｙが整合性を有する場合は、他の約定結果１０２ｙを選定されるひとつの約定結果の候補とする。また、約定結果検証部４７は、受信された他の約定結果１０２ｙが整合性を有しない場合は、他の約定結果１０２ｙを選定されるひとつの約定結果の候補とせず削除する。
　整合性を有するか否かの検証は、例えば、下記の検証を含む。
　（１）他の約定結果１０２ｙに含まれる買入札データＩＤ１５１及び売入札データＩＤ１５２により特定される入札データ１０１の各々に含まれるデジタル証明書１１９が認証局１２から取得されたデジタル証明書１０４と一致するか否かの検証、
　（２）他の約定結果１０２ｙに含まれるデジタル証明書１４４が認証局１２から取得されたデジタル証明書１０４と一致するか否かの検証、
　（３）他の約定結果１０２ｙに含まれる買入札データＩＤ１５１及び売入札データＩＤ１５２により特定される入札データ１０１の各々に含まれるタイムスタンプ１１２により示される時刻が他の約定結果１０２ｙに含まれるタイムスタンプ１４２により示される時刻以前であるか否かの検証、
　（４）他の約定結果１０２ｙに含まれる買入札データＩＤ１５１により特定される買入札データ１０１に含まれる入札単価１１７が、当該買入札データＩＤ１５１に紐づけられた売入札データＩＤ１５２により特定される売入札データ１０１に含まれる入札単価１１７以下であるか否かの検証、
　（５）他の約定結果１０２ｙに含まれる売入札データＩＤ１５２により特定される売入札データ１０１に含まれる入札単価１１７が、当該売入札データＩＤ１５２に紐づけられた買入札データＩＤ１５１により特定される買入札データ１０１に含まれる入札単価１１７以上であるか否かの検証、
　（６）他の約定結果１０２ｙに含まれる買入札データＩＤ１５１により特定される買入札データ１０１に含まれる入札数量１１６の合計が、当該買入札データＩＤ１５１に紐づけられる売入札データＩＤ１５２により特定される売入札データ１０１に含まれる入札数量１１６以下であるか否かの検証、及び
　（７）他の約定結果１０２ｙに含まれる売入札データＩＤ１５２により特定される売入札データ１０１に含まれる入札数量１１６の合計が、当該売入札データＩＤ１５２に紐づけられる買入札データＩＤ１５１により特定される買入札データ１０１に含まれる入札数量１１６以下であるか否かの検証。
　続くステップＳ１０８においては、約定結果選定部４８が、約定結果選定処理を行う。約定結果選定部４８は、その際に、算出された約定結果１０２ｘ及び受信された他の約定結果１０２ｙからひとつの約定結果を選定する。約定結果選定部４８は、他の約定結果１０２ｙを選定されるひとつの約定結果の候補とするか否かが判定されている場合は、約定結果１０２ｘ及び候補とされた他の約定結果１０２ｙからひとつの約定結果を選定する。入札の締め切り時刻が5分間隔で設定される場合は、約定結果選定部４８は、5分間隔でひとつの約定結果を選定し、過去の5分間に算出された約定結果１０２ｘ及び他の約定結果１０２ｙからひとつの約定結果を選定する。約定結果選定部４８は、選定指標１０７に基づいてひとつの約定結果を選定する。
　図７は、実施の形態１の約定取引システムに備えられる各端末により参照される選定指標の例を図示する図である。
　図７に図示される選定指標１０７は、「約定総量最大」という選定指標である。選定指標１０７が「約定総量最大」という選定指標である場合は、算出された約定結果１０２ｘ及び受信された他の約定結果１０２ｙに含まれる、約定数量１５３の合計が最大である約定結果が、選定されるひとつの約定結果となる。例えば、入札の締め切り時刻が5分間隔で設定され、現在の時刻が2019年01月01日00時10分00秒であり2019年01月01日00時05分00秒に算出された、図６（ａ）に図示される約定結果１２１ａ、図６（ｂ）に図示される約定結果１２１ｂ、及び図６（ｃ）に図示される約定結果１２１ｂからひとつの約定結果が選定される場合を考える。この場合は、約定結果１２１ａに含まれる約定数量１５３の合計が3.0+1.0=4.0であり、約定結果１２１ｂに含まれる約定数量１５３の合計が3.0であり、約定結果１２１ｃに含まれる約定数量１５３の合計が1.0である。このため、約定数量１５３の合計が最大の4.0である約定結果１２１ａが、選定されるひとつの約定結果となる。これにより、複数の端末１１によりそれぞれ算出された複数の約定結果１０２ｘが同じでない場合でも、依拠すべきひとつの約定結果を特定することができる。
　続くステップＳ１０９においては、ブロック受信部４９が、ブロック受信処理を行う。ブロック受信部４９は、その際に、ステップＳ１０８においてひとつの約定結果が選定される前に選定された過去のひとつの約定結果を含む過去のブロック１０８を他の端末１１ｙから受信する。ブロック受信部４９は、過去のブロック１０８が各端末１１ｘに保存されていない場合に、過去のブロック１０８を他の端末１１ｙから受信する。例えば、入札の締め切り時刻が5分間隔で設定され、端末１１ａの故障等の理由により5分前の2019年01月01日00時00分00秒に選定されたひとつの約定結果を含む前回のブロックが端末１１ａに保存されておらず、端末１１ａが2019年01月01日00時05分00秒に復旧した場合は、端末１１ａに備えられるブロック受信部４９が、当該前回のブロックを他の端末１１ｙから受信する。
　続くステップＳ１１０においては、ブロック選定部５０が、ブロック選定処理を行う。ブロック選定部５０は、その際に、ブロック受信部４９により受信された複数の過去のブロックから、新たなブロックを後続させる過去のブロック１０８を選定し、選定した過去のブロック１０８を保存する。選定される過去のブロック１０８は、ブロック受信部４９により受信された複数の過去のブロックにおいて多数決を取ることにより決められる最多数となる過去のブロックである。
　続くステップＳ１１１においては、約定結果保存部５１が、約定結果保存処理を行う。約定結果保存部５１は、その際に、選定されたひとつの約定結果を保存し、入札データ１０１を更新する。更新後の入札データ１０１は、更新前の入札データ１０１に含まれる入札数量を、当該入札数量から約定数量を減ずることにより得られる新たな入札数量に置き換えることにより得られる入札データである。約定結果保存部５１は、選定されたひとつの約定結果を保存する際に、選定されたひとつの約定結果を含む新たなブロックを保存する。保存される新たなブロックは、選定された過去のブロック１０８に後続する。
　図８は、実施の形態１の約定取引システムに備えられる各端末に保存されるブロックの例を図示するである。
　新たなブロック１６１は、図８に図示されるように、前回のブロック１６２に後続させられる。
　新たなブロック１６１は、選定されたひとつの約定結果１７１及びハッシュ値１７２を含む。前回のブロック１６２は、5分前に選定されたひとつの約定結果１７３及びハッシュ値１７４を含む。ハッシュ値１７４は、図示されない前々回のブロックを引数としてハッシュ関数１７５に与えた場合に返されるハッシュ値である。ハッシュ値１７２は、前回のブロック１６２を引数としてハッシュ関数１７５に与えた場合に返されるハッシュ値である。
　１．７　実施の形態１の効果
　実施の形態１によれば、クライアントサーバモデルが採用された場合のようにサーバにおいて約定取引を成立させる必要がなく、複数の端末１１により構成されるＰ２Ｐネットワーク２１において約定取引を成立させることができる。これにより、単一障害点を有しない約定取引システム１を提供することができる。また、同じでない複数の約定結果から、依拠すべきひとつの約定結果１７１を特定することができる。
　２　実施の形態２
　２．１　実施の形態１と実施の形態２との相違
　図９は、実施の形態２の約定取引システムを模式的に図示するブロック図である。図１０は、実施の形態２の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。
　図９に図示される実施の形態２の約定取引システム２は、図１に図示される実施の形態１の約定取引システム１と主に下述する点で相違する。下述されない点については、約定取引システム１において採用される構成と同様の構成が約定取引システム２においても採用される。
　約定取引システム２に備えられる各端末１１ｘは、図９に図示されるように、インセンティブ算出部５２をさらに備える。また、約定取引システム２に備えられる各端末１１ｘは、図１０に図示されるように、ステップＳ１１２をさらに実行する。
　ステップＳ１１２においては、インセンティブ算出部５２が、インセンティブ算出処理を行う。インセンティブ算出部５２は、その際に、選定されたひとつの約定結果を算出した端末についてインセンティブを算出する。当該端末のユーザは、算出されたインセンティブを得ることができる。インセンティブ算出部５２は、インセンティブ比率１０９に基づいてインセンティブを算出する。
　図１１は、実施の形態２の約定取引システムに備えられる各端末により参照されるインセンティブ比率の例を図示する図である。図１２は、実施の形態２の約定取引システムに備えられる各端末により算出されるインセンティブの例を図示する図である。
　図１１に図示されるインセンティブ比率１０９は、「1%」というインセンティブ比率である。インセンティブ比率１０９が「1%」というインセンティブ比率であり、選定されるひとつの約定結果が図６（ａ）に図示される約定結果１２１ａである場合は、図１２に図示されるインセンティブ１８１が算出される。
　図１２に図示されるインセンティブ１８１は、買入札データＩＤ１９１、売入札データＩＤ１９２及び手数料１９３を含む。買入札データＩＤ１９１、売入札データＩＤ１９２及び手数料１９３は、それぞれ、テーブルの第１列目から第３列目までに記述される。買入札データＩＤ１９１及び売入札データＩＤ１９２は、それぞれ、約定取引が成立させられた買入札及び売入札の内容を表す買入札データ及び売入札データを特定する。手数料１９３は、成立させられた約定取引の結果を示す約定結果を算出した端末のユーザに支払われる手数料を示す。手数料１９３は、成立させられた約定取引の結果を示す約定結果に含まれる約定数量１５３と当該約定結果に含まれる約定単価１５４とインセンティブ比率１０９との積である。したがって、「0001」という買入札データＩＤ１９１により特定される買入札データにより表される内容を有する買入札と、「0002」という売入札データＩＤ１９２により特定される売入札データにより表される内容を有する売入札と、の間で成立させられた約定取引の結果を示す約定結果１２１ａを算出した端末１１ａのユーザAに支払われる手数料１９３は、3.0×11.5×1%＝0.345である。「0001」という買入札データＩＤ１９１により特定される買入札データを作成した買い方のユーザBは、「証明書A」というデジタル証明書１４４を有する端末１１ａのユーザAに「0.345」という手数料１９３を支払う。また、「0003」という買入札データＩＤ１９１により特定される買入札データにより表される内容を有する買入札と、「0002」という売入札データＩＤ１９２により特定される売入札データにより表される内容を有する売入札と、の間で成立させられた約定取引の結果を示す約定結果１２１ａを算出した端末AのユーザAに支払われる手数料１９３は、1.0×11×1%＝0.11である。「0003」という買入札データＩＤ１９１により特定される買入札データを作成した買い方のユーザCは、「証明書A」というデジタル証明書を有する端末１１ａのユーザAに「0.11」という手数料１９３を支払う。買い方のユーザ及び売り方のユーザが手数料１９３を折半して支払ってもよい。売り方のユーザが手数料１９３を支払ってもよい。
　ステップＳ１１１においては、約定結果保存部５１が、約定結果保存処理を行う。約定結果保存部５１は、その際に、選定されたひとつの約定結果とともに算出されたインセンティブ１８１を保存し、入札データ１０１を更新する。
　２．２　実施の形態２の効果
　実施の形態２は、実施の形態１の効果と同様の効果を有する。
　加えて、実施の形態２は、下述する効果を有する。
　図１３は、Ｐ２Ｐネットワークのトポロジーの例を模式的に図示する図である。
　Ｐ２Ｐネットワーク２１が図１３に図示されるトポロジーを有する場合は、端末１１ａを含む端末集合２０１ａと端末１１ｂを含む端末集合２０１ｂとを互いに通信可能に接続する通信線２０２が、端末１１ａと端末１１ｂとを互いに通信可能に接続する通信線２０３のみからなる。このため、通信線２０３を経由する通信が絶たれた場合は、Ｐ２Ｐネットワーク２１が分断され、端末集合２０１ａにおいて算出される約定結果と、端末集合２０１ｂにおいて算出される約定結果と、が互いに異なることになる。
　実施の形態２においては、選定されるひとつの約定結果、すなわち、約定数量１５３の合計が最大である約定結果を算出した端末のユーザがインセンティブ１８１を得ることができる。このため、インセンティブ１８１を得るために、各端末１１ｘが受信する入札データ１０１を増やし、各端末１１ｘが算出する約定結果１０２ｘに反映される入札データ１０１を増やす動機付けが存在する。そして、各端末１１ｘが受信する入札データ１０１を増やすためには、各端末１１ｘが通信可能に接続される端末の数を増やすことが有効であるため、複数の通信線２２を構成する通信線２２の数を増やす動機付けが存在する。その結果として、Ｐ２Ｐネットワーク２１が分断されることを抑制することができ、端末集合２０１ａにおいて算出される約定結果と、端末集合２０１ｂにおいて算出される約定結果と、が互いに異なることを抑制することができる。
　３　実施の形態３
　３．１　実施の形態１と実施の形態３との相違
　図１４は、実施の形態３の約定取引システムを模式的に図示するブロック図である。図１５は、実施の形態３の約定取引システムに備えられる各端末が行う処理の流れを図示するフローチャートである。
　図１４に図示される実施の形態３の約定取引システム３は、図１に図示される実施の形態１の約定取引システム１と主に下述する点で相違する。下述されない点については、約定取引システム１において採用される構成と同様の構成が約定取引システム３においても採用される。
　約定取引システム３に備えられる各端末１１ｘは、図１４に図示されるように、端末評価部５３をさらに備える。また、約定取引システム３に備えられる各端末１１ｘは、図１５に図示されるように、ステップＳ１１３をさらに実行する。
　ステップＳ１１３においては、端末評価部５３が、端末評価処理を行う。端末評価部５３は、その際に、他の端末１１ｙの評価を行い、行った評価の結果に基づいて他の端末１１ｙから過去のブロック１０８の送信元の端末を選定する。端末評価部５３は、評価指標１１０に基づいて他の端末１１ｙの評価を行う。
　図１６は、実施の形態３の約定取引システムに備えられる各端末により参照される評価指標の例を図示する図である。
　図１６に図示される評価指標１１０は、「約定結果算出回数」という評価指標である。評価指標１１０が「約定結果算出回数」という評価指標である場合は、端末評価部５３は、既に受信した過去のブロックを参照し、約定結果を算出した他の端末１１ｙを抽出する。また、端末評価部５３は、約定結果を算出した回数で他の端末１１ｙを降順で並べ、上位の設定された数の他の端末１１ｙを過去のブロック１０８の送信元の端末にする。
　続くステップＳ１０９においては、ブロック受信部４９が、ブロック受信処理を行う。ブロック受信部４９は、その際に、選定された過去のブロック１０８の送信元の端末から過去のブロック１０８を受信する。
　３．２　実施の形態３の効果
　実施の形態３は、実施の形態１の効果と同様の効果を有する。
　加えて、実施の形態３は、下述する効果を有する。
　実施の形態１においては、ブロック受信部４９が、過去のブロック１０８が各端末１１ｘに保存されていない場合に、複数の他の端末１１ｙから複数の過去のブロックを受信する。また、ブロック選定部５０が、受信された複数の過去のブロックから、新たなブロックが後続させられる過去のブロック１０８を選定する。選定される過去のブロック１０８は、受信された複数の過去のブロックにおいて多数決を取ることにより決められる。しかし、多数決の結果を信用に値するものにするためには、ブロック受信部４９が多数の過去のブロックを受信しなければならず、ブロック受信処理が行われる際に各端末１１ｘにかかる負荷が大きくなる。
　これに対して、実施の形態３においては、含む過去のブロックが各端末１１ｘに保存されていない場合に、選定された、過去のブロック１０８の送信元の端末から過去のブロック１０８を受信する。このため、ブロック受信部４９が多数の過去のブロックを受信する必要がなく、ブロック受信処理が行われる際に各端末１１ｘにかかる負荷が小さくなる。
　なお、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。
　実施の形態は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、実施の形態がそれに限定されるものではない。例示されていない無数の変形例が、想定され得るものと解される。
　１，２，３　約定取引システム、１１　複数の端末、１２　認証局、２１　Ｐ２Ｐネットワーク、４１　認証情報取得部、４２　入札データ取得部、４３　入札データ送信部、４４　約定結果算出部、４５　約定結果送信部、４６　約定結果受信部、４７　約定結果検証部、４８　約定結果選定部、４９　ブロック受信部、５０　ブロック選定部、５１　約定結果保存部、５２　インセンティブ算出部、５３　端末評価部。

Claims (9)

  1. 　入札データを取得する入札データ取得部と、
    　前記入札データを他のピアツーピア端末に送信する入札データ送信部と、
    　前記入札データ取得部により取得された入札データ群から約定結果を算出する約定結果算出部と、
    　前記約定結果を前記他のピアツーピア端末に送信する約定結果送信部と、
    　前記他のピアツーピア端末により算出された他の約定結果を前記他のピアツーピア端末から受信する約定結果受信部と、
    　前記約定結果及び前記他の約定結果からひとつの約定結果を選定する約定結果選定部と、
    を備えるピアツーピア端末。
  2. 　前記ひとつの約定結果は、前記約定結果及び前記他の約定結果に含まれる、約定数量の合計が最大である約定結果である
    請求項１のピアツーピア端末。
  3. 　前記ひとつの約定結果を算出したピアツーピア端末についてインセンティブを算出するインセンティブ算出部をさらに備える
    請求項１又は２のピアツーピア端末。
  4. 　前記ひとつの約定結果が選定される前に選定された過去のひとつの約定結果を含む過去のブロックを前記他のピアツーピア端末から受信するブロック受信部と、
    　前記過去のブロックに後続し前記ひとつの約定結果を含む新たなブロックを保存する約定結果保存部と、
    をさらに備える請求項１から３までのいずれかのピアツーピア端末。
  5. 　前記ブロック受信部は、複数の過去のブロックを受信し、
    　前記複数の過去ブロックから前記過去のブロックを選定するブロック選定部をさらに備える
    請求項４のピアツーピア端末。
  6. 　前記他のピアツーピア端末の評価を行い、前記評価の結果に基づいて前記他のピアツーピア端末から前記過去のブロックの送信元のピアツーピア端末を選定する端末評価部をさらに備え、
    　前記ブロック受信部は、前記過去のブロックの送信元のピアツーピア端末から前記過去のブロックを受信する
    請求項４又は５のピアツーピア端末。
  7. 　前記他の約定結果の検証を行い、前記検証の結果に基づいて前記他の約定結果を前記ひとつの約定結果の候補とするか否かを判定する約定結果検証部をさらに備え、
    　前記約定結果選定部は、前記約定結果及び前記ひとつの約定結果の候補とされた他の約定結果から前記ひとつの約定結果を選定する
    請求項１から６までのいずれかのピアツーピア端末。
  8. 　前記ピアツーピア端末のデジタル証明書を認証局から取得する認証情報取得部をさらに備え、
    　前記入札データは、前記入札データが作成されたピアツーピア端末のデジタル証明書を含み、
    　前記約定結果は、前記約定結果を算出したピアツーピア端末のデジタル証明書を含む
    請求項１から７までのいずれかのピアツーピア端末。
  9. 　複数のピアツーピア端末を備え、
    　前記複数のピアツーピア端末の各々は、請求項１から８までのいずれかのピアツーピア端末である
    約定取引システム。
PCT/JP2020/003410 2020-01-30 2020-01-30 ピアツーピア端末及び約定取引システム WO2021152769A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2020537559A JP6854981B1 (ja) 2020-01-30 2020-01-30 ピアツーピア端末及び約定取引システム
CN202080094187.XA CN114981830A (zh) 2020-01-30 2020-01-30 点对点终端以及合约交易系统
PCT/JP2020/003410 WO2021152769A1 (ja) 2020-01-30 2020-01-30 ピアツーピア端末及び約定取引システム
US17/782,665 US20230020147A1 (en) 2020-01-30 2020-01-30 Peer-to-peer terminal and contract transaction system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/003410 WO2021152769A1 (ja) 2020-01-30 2020-01-30 ピアツーピア端末及び約定取引システム

Publications (1)

Publication Number Publication Date
WO2021152769A1 true WO2021152769A1 (ja) 2021-08-05

Family

ID=75267893

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/003410 WO2021152769A1 (ja) 2020-01-30 2020-01-30 ピアツーピア端末及び約定取引システム

Country Status (4)

Country Link
US (1) US20230020147A1 (ja)
JP (1) JP6854981B1 (ja)
CN (1) CN114981830A (ja)
WO (1) WO2021152769A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004341651A (ja) * 2003-05-13 2004-12-02 Nippon Telegr & Teleph Corp <Ntt> 分散型オークションシステム
JP2018521437A (ja) * 2015-07-09 2018-08-02 リキッド マーケッツ グループ インコーポレイテッド ブロックチェーン技術を用いて証券取引を売買、決済、および清算するためのシステムおよび方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004341651A (ja) * 2003-05-13 2004-12-02 Nippon Telegr & Teleph Corp <Ntt> 分散型オークションシステム
JP2018521437A (ja) * 2015-07-09 2018-08-02 リキッド マーケッツ グループ インコーポレイテッド ブロックチェーン技術を用いて証券取引を売買、決済、および清算するためのシステムおよび方法

Also Published As

Publication number Publication date
CN114981830A (zh) 2022-08-30
JP6854981B1 (ja) 2021-04-07
JPWO2021152769A1 (ja) 2021-08-05
US20230020147A1 (en) 2023-01-19

Similar Documents

Publication Publication Date Title
US20210272140A1 (en) Systems and methods for an online music marketplace
CN107085807B (zh) 一种基于区块链的数据资产交易方法
Malik et al. Blockchain technology for creative industries: Current state and research opportunities
US20200143469A1 (en) Technological improvements to networked computer systems having particularized components that are specially programmed to unconventionally effectuate efficient blockchain storage
US7729950B2 (en) Method and system for auctioning assets and valuing same
US20160098788A1 (en) Method and system for sealed bid auctions
Cameron et al. Consumer motivations and concerns in online auctions: an exploratory study
Zhang et al. Combining trust modeling and mechanism design for promoting honesty in e‐marketplaces
US20230131603A1 (en) Initiating a workflow in a digital token transaction system based on a recognized activity in a food delivery system
CA3003562C (en) Method and system for sealed bid auctions
US20230245101A1 (en) Cost analytics for cryptographic tokens that link to real world objects
US20230274244A1 (en) Trading analytics for cryptographic tokens that link to real world objects
JP6854981B1 (ja) ピアツーピア端末及び約定取引システム
TWI776089B (zh) 遊戲帳號的交易方法
Girasa Technology Underlying Cryptocurrencies and Types of Cryptocurrencies
US20230117135A1 (en) Configuring a set of digital tokens with a temporal attribute that determines a timing of redemption of the set of digital tokens for a corresponding set of items
US20230124040A1 (en) Event stream generation and analytics for cryptographic tokens that link to real world objects
TWI766144B (zh) 遊戲帳號估價方法及其系統
TW201201130A (en) System and method for matching transactions in internet
Lin et al. Reputation, Reputation System and Reputation Distribution-An Exploratory Study in Online Consumer-to-Consumer Auctions
KR102541047B1 (ko) 위탁매매 전자상거래에 있어서 실행되는 nft에 대한 비일시적 저장매체 및 제어 방법
US20240037620A1 (en) Systems and Methods for Verifying Transaction Authenticity Using Securitized Token-Based System
WO2021082020A1 (zh) 游戏账号估价方法及系统
JP7196137B2 (ja) 封印入札競売の方法とシステム
US20240070768A1 (en) Bidder buyer pool system

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2020537559

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 20916906

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20916906

Country of ref document: EP

Kind code of ref document: A1