WO2019186978A1 - 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム - Google Patents

電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム Download PDF

Info

Publication number
WO2019186978A1
WO2019186978A1 PCT/JP2018/013481 JP2018013481W WO2019186978A1 WO 2019186978 A1 WO2019186978 A1 WO 2019186978A1 JP 2018013481 W JP2018013481 W JP 2018013481W WO 2019186978 A1 WO2019186978 A1 WO 2019186978A1
Authority
WO
WIPO (PCT)
Prior art keywords
verification
data
bid
transaction
price
Prior art date
Application number
PCT/JP2018/013481
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 PCT/JP2018/013481 priority Critical patent/WO2019186978A1/ja
Priority to JP2020508774A priority patent/JP7364238B2/ja
Priority to US16/975,555 priority patent/US20200402171A1/en
Publication of WO2019186978A1 publication Critical patent/WO2019186978A1/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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/279—Recognition of textual entities
    • G06F40/289—Phrasal analysis, e.g. finite state techniques or chunking
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time 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/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/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; 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/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services

Definitions

  • the present invention relates to an electronic transaction system, a transaction server, a verification server, an electronic transaction method, and a program.
  • Patent Document 1 discloses an electronic transaction system using a network.
  • Patent Document 2 discloses systems for buying and selling power on a network.
  • Patent Document 3 disclose systems for buying and selling power on a network.
  • Patent Document 4 discloses that the output of each server performs a proper process on the input and then replaces the order, and efficiently proves and verifies with less calculation amount and communication amount. Providing a method and apparatus is provided.
  • Non-Patent Document 2 and Non-Patent Document 3 disclose a technique for proving that a plaintext of a certain ciphertext is within a predetermined range (range) without revealing the plaintext.
  • Non-Patent Document 1 discloses a technology that uses a block chain for power trading. According to the technology of Non-Patent Document 1, individual users can estimate power surplus and deficiency based on their own power consumption and power generation amount, and perform power transactions on the block chain to realize power interchange.
  • Non-Patent Document 1 individual order information (bid data) is registered in plain text, and at least participants of the power interchange system can grasp the order status of others. If the order situation of others can be grasped, there is a possibility that fair trade may be impaired. For example, even though there is no willingness to buy and sell, a large number of bids can be made, making it appear as if the demand for electricity is strong, and it is possible to allow fraud that realizes selling electricity at an advantageous price.
  • the main object of the present invention is to provide an electronic transaction system, a transaction server, a verification server, an electronic transaction method, and a program that contribute to providing a fair transaction.
  • a plurality of management servers providing an electronic bulletin board, a terminal for writing bid data including an encrypted price to the electronic bulletin board, and the written bid data
  • a transaction server that decrypts the encrypted price and executes a transaction using the decrypted price in accordance with the Zaraba method.
  • the terminal obtains bid data including an encrypted price written on an electronic bulletin board provided by a plurality of management servers, and decrypts the encrypted price. Then, there is provided a transaction server that executes a transaction using the decrypted price by the Zaraba method.
  • the terminal obtains bid data including an encrypted price written on an electronic bulletin board provided by a plurality of management servers, and decrypts the encrypted price.
  • the encrypted price of the bid data subject to verifying the legitimacy of the transaction by the transaction server is executed, and the uncommitted bid data is encrypted.
  • a verification server for generating verification data including a verification character string for verifying the legitimacy of the transaction of the transaction server.
  • the terminal obtains bid data including an encrypted price written on an electronic bulletin board provided by a plurality of management servers;
  • an electronic transaction method including a step of decrypting a converted price and a step of executing a transaction using the decrypted price according to the Zaraba method.
  • the bid data including the encrypted price written by the terminal on the electronic bulletin board provided by the plurality of management servers is acquired in the computer mounted on the transaction server.
  • a program for executing a process, a process of decrypting the encrypted price, and a process of executing a transaction using the decrypted price by the Zaraba method can be recorded on a computer-readable storage medium.
  • the storage medium may be non-transient such as a semiconductor memory, a hard disk, a magnetic recording medium, an optical recording medium, or the like.
  • the present invention can also be embodied as a computer program product.
  • an electronic transaction system a transaction server, a verification server, an electronic transaction method, and a program that contribute to providing a fair transaction are provided.
  • connection lines between the blocks in each drawing include both bidirectional and unidirectional directions.
  • the unidirectional arrow schematically shows the main signal (data) flow and does not exclude bidirectionality.
  • an input port and an output port exist at each of an input end and an output end of each connection line, although they are not explicitly shown. The same applies to the input / output interface.
  • the electronic transaction system includes a plurality of management servers 101, a terminal 102, and a transaction server 103 (see FIG. 1).
  • the plurality of management servers 101 provide an electronic bulletin board.
  • the terminal 102 writes bid data including the encrypted price on the electronic bulletin board.
  • the transaction server 103 acquires the written bid data, decrypts the encrypted price, and executes the transaction by the Zaraba method (price priority, time priority) using the decrypted price.
  • the terminal 102 encrypts the bid data with, for example, the public key of the transaction server 103 and registers it on the electronic bulletin board.
  • the encrypted bid data can be decrypted by the transaction server 103 having a secret key, and other participants cannot know its contents. As a result, the information regarding the bid is kept secret, and the electronic trading system can provide a fair trade.
  • FIG. 2 is a diagram illustrating an example of the configuration of the electronic transaction system according to the first embodiment.
  • the electronic transaction system includes a transaction server 10, a plurality of terminals 20-1 to 20-N (N is a positive integer, the same applies hereinafter), and a data management system 30. .
  • the transaction server 10, the terminals 20-1 to 20-N, and the data management system 30 are connected to each other via a network such as the Internet.
  • the transaction target of the electronic transaction system is not particularly limited, the disclosure of the present application mainly explains “electric power” as the target of the transaction.
  • the electronic trading system disclosed in the present application can also be applied to trading of financial products such as stocks.
  • the transaction server 10 is a device that mediates orders for buyers and sellers of electricity.
  • Terminals 20-1 to 20-N are terminals used by participants in power transactions.
  • an information processing apparatus such as a personal computer or a smartphone corresponds to the terminal.
  • terminal 20 when there is no particular reason for distinguishing the terminals 20-1 to 20-N, they are simply expressed as “terminal 20”.
  • the terminal used by the user is referred to as “buyer terminal”.
  • the terminal used by the user is denoted as “seller terminal”.
  • the data management system 30 is a system operated by an organization independent of the operating entity of the transaction server 10 and the participants (bidders; sellers, buyers) of the power transaction.
  • the data management system 30 is a system that provides an electronic bulletin board that can be additionally written and read out to the outside (third party). More specifically, the data management system 30 can add information to any subject, read out the written information, and erase or tamper the information once written. Provide no electronic bulletin board.
  • the data management system 30 provides an electronic bulletin board having the above features by a so-called technology called a block chain.
  • power trading data information necessary for power trading
  • the data management system 30 is a system that provides an electronic bulletin board to any subject
  • the electronic bulletin board includes data irrelevant to the power transaction data. .
  • the data management system 30 includes a plurality of management servers 40-1 to 40-4. 2 is not intended to limit the number of management servers constituting the data management system 30 to four.
  • the data management system 30 may be configured to include two or more management servers. Similarly to the terminal 20, when there is no particular reason for distinguishing the management servers 40-1 to 40-4, they are simply expressed as “management server 40”.
  • the plurality of management servers 40 constituting the data management system 30 are directly connected to each other as shown in FIG. That is, the data management system 30 includes a plurality of management servers 40 connected by P2P (Peer to Peer).
  • P2P Peer to Peer
  • each of the plurality of management servers 40 connected in P2P has a data management ledger for managing data (for example, power transaction data) received from the outside.
  • the data management system 30 distributes and manages the data management ledger among a plurality of management servers 40.
  • the management server 40 constituting the data management system 30 adds the power transaction data to the data management ledger every time a request for writing the power transaction data on the electronic bulletin board is received from the transaction server 10 or the terminal 20.
  • Each management server 40 generates data that proves the validity of the data to be added to the data management ledger.
  • the management server 40 uses the digital signature (digital signature) of each management server 40 as data for proving the validity of the additional data.
  • the management server 40 attaches the electronic signature to the data added to the data management ledger and distributes it to the other management servers 40.
  • the other management server 40 receives the additional data, it verifies its validity and updates its own data management ledger.
  • FIG. 3 is a sequence diagram showing an example of an operation outline of the electronic trading system according to the first embodiment.
  • Participants wishing to sell electricity are classified into the type of sale (sell order), an identifier (participant ID; IDentifier) for identifying themselves, the amount of power (quantity) desired to be sold, and the desired sale price (price).
  • the "seller bid data” including this is written on the electronic bulletin board (seller bid; step S01).
  • the seller terminal encrypts the seller bid data with the public key of the transaction server 10 and transmits it to the data management system 30.
  • the data shown in FIG. 4A is encrypted and written on the electronic bulletin board.
  • a participant who wishes to purchase electricity will display “buyer bid data” including the type of purchase (buy order), a participant ID for identifying himself / herself, the amount of power desired to purchase, and the desired purchase amount. (Buyer bid; step S02).
  • the buyer terminal encrypts the buyer bid data with the public key of the transaction server 10 and transmits it to the data management system 30.
  • the data shown in FIG. 4B is encrypted and written on the electronic bulletin board.
  • the terminal 20 may encrypt only the quantity without encrypting all of the four items (trade type, participant ID, quantity, price) shown in FIG. This is because the security of the transaction can be ensured at least if the quantity is encrypted.
  • the terminal 20 according to the first embodiment writes the bid data including the encrypted price on the electronic bulletin board.
  • bid data when it is not necessary to distinguish seller bid data and buyer bid data, they are simply referred to as “bid data”.
  • the transaction server 10 periodically accesses the electronic bulletin board and acquires bid data (step S03).
  • the transaction server 10 decrypts the ciphertext of the acquired bid data using its own private key (step S04).
  • the transaction server 10 executes a transaction using the acquired bid data at a predetermined timing or the like (step S05). Details of transaction processing by the transaction server 10 will be described later.
  • the transaction server 10 writes the transaction result on the electronic bulletin board.
  • TXID Transaction ID for specifying the bid data
  • the transaction server 10 writes the transaction result on the electronic bulletin board using the TXID. Specifically, when a selling bid and a buying bid are established (contracted), the transaction server 10 writes data including the TXID of the contracted bid data as “contract data” on the electronic bulletin board (see FIG. 5). .
  • the transaction server 10 designates the contracted TXID, and writes the deletion data indicating that the TXID is deleted from the transaction place on the electronic bulletin board. With the deletion data, the terminal 20 can grasp the bid data (uncommitted bid data) remaining in the transaction field.
  • the seller and the buyer access the electronic bulletin board, acquire the contract data, and confirm the transaction result (Step S06, Step S07). That is, the terminal 20 (seller terminal, buyer terminal) acquires the contract data written on the electronic bulletin board and confirms whether or not its bid has been executed.
  • the terminal 20 can grasp the state of the bid data (contracted, uncommitted) by referring to the contract data. Alternatively, the terminal 20 can confirm whether or not its bid has been executed by confirming the deletion data.
  • the terminal 20 can grasp that its bid has been executed. On the other hand, if the TXID described in the contract data does not correspond to its own bid, the terminal 20 does not execute its bid and remains on the electronic bulletin board (transaction place) as an uncommitted bid. Can be grasped.
  • FIG. 6 shows that sell bids with TXIDs “01” and “02” have been performed, and then buy bids with TXID “03” have been performed. Thereafter, a sell bid with a TXID of “01” and a buy bid with a TXID of “03” are contracted and written as contract data with a TXID of “04” on the electronic bulletin board.
  • PID shown in FIG. 6 indicates a participant ID.
  • the transaction server 10 and the terminal 20 confirm the power transaction data (bid data, contract data) as shown in FIG. 6, and the sell bid with TXID “02” remains on the electronic bulletin board as uncommitted bid data. It can also be confirmed.
  • the transaction server 10 can grasp the latest bid situation (bid data remaining in an uncommitted state) by tracing the power transaction data written on the electronic bulletin board since the system was operated.
  • the terminal 20 can grasp the latest bid situation by tracing the power transaction data written on the electronic bulletin board.
  • the terminal 20 can grasp the situation (confirmed, uncommitted) regarding its own bid, since the bid data is encrypted, details of the bid data remaining on the electronic bulletin board (at least the price) Details) cannot be known.
  • FIG. 7 is a block diagram illustrating an example of a hardware configuration of the transaction server 10 according to the first embodiment.
  • the transaction server 10 can be configured by an information processing device (computer) and has a configuration illustrated in FIG.
  • the transaction server 10 includes a CPU (Central Processing Unit) 11, a memory 12, an input / output interface 13, and a NIC (Network Interface Card) 14 that are communication means, which are connected to each other via an internal bus.
  • Transaction server 10 may include hardware (not shown), and may not include input / output interface 13 as necessary. Further, the number of CPUs and the like included in the transaction server 10 is not limited to the example illustrated in FIG. 7. For example, a plurality of CPUs 11 may be included in the transaction server 10.
  • the memory 12 is a RAM (Random Access Memory), a ROM (Read Only Memory), or an auxiliary storage device (hard disk or the like).
  • the input / output interface 13 is a means to be an interface of a display device and an input device (not shown).
  • the display device is, for example, a liquid crystal display.
  • the input device is a device that accepts user operations such as a keyboard and a mouse, for example.
  • the function of the transaction server 10 is realized by various processing modules described later.
  • the processing module is realized, for example, by the CPU 11 executing a program stored in the memory 12.
  • the program can be downloaded through a network or updated using a storage medium storing the program.
  • the processing module may be realized by a semiconductor chip. That is, it is sufficient if there is a means for executing the function performed by the processing module with some hardware and / or software.
  • terminal 20 and the management server 40 can also be configured by an information processing device in the same manner as the transaction server 10, and the basic hardware configuration is not different from the transaction server 10, so description thereof is omitted.
  • the transaction server 10 acquires bid data written on the electronic bulletin board and decrypts the encrypted price. Furthermore, the transaction server 10 executes a transaction using the decrypted price by the Zaraba method.
  • FIG. 8 is a block diagram illustrating an example of a processing configuration of the transaction server 10 according to the first embodiment.
  • the transaction server 10 includes a communication control unit 201, a data management unit 202, a decryption unit 203, a transaction execution unit 204, and a storage unit 205.
  • the communication control unit 201 is means for controlling the NIC 14 and realizing communication with other devices (mainly, the management server 40).
  • the communication control unit 201 is also means for distributing a message (packet) received from another apparatus to each processing module, or transmitting a message acquired from each processing module to another apparatus.
  • the storage unit 205 is realized by the memory 12 and is means for storing information necessary for processing of each processing module.
  • the data management unit 202 is a means for accessing the electronic bulletin board and managing power transaction data (bid data, contract data, deletion data).
  • the data management unit 202 periodically accesses the electronic bulletin board, and acquires bid data newly written on the electronic bulletin board (the transaction server 10 has never acquired).
  • the data management unit 202 delivers the acquired bid data to the decryption unit 203. Further, the data management unit 202 writes the transaction result (contract data, deletion data) by the transaction execution unit 204 on the electronic bulletin board via the communication control unit 201.
  • the decryption unit 203 is a means for decrypting the bid data encrypted with the public key of the transaction server 10. More specifically, the decryption unit 203 decrypts the encrypted bid data using the secret key, and stores the decryption result (plain text bid data) in the storage unit 205.
  • the transaction execution unit 204 is a means for executing a transaction (electric power transaction) using bid data.
  • the transaction execution unit 204 realizes electric power transaction by a so-called “zalaba method”. More specifically, the transaction execution unit 204 establishes a transaction in order from the number of selling bids and buying bids that have the same price and quantity.
  • the transaction execution unit 204 establishes a transaction in accordance with the “priority principle of price” and the “priority of time priority”. For example, in the case of a buy order (buy bid), a buy order with a higher price takes precedence over a buy order with a lower price, and in the case of a sell order, a sell order with a lower price takes precedence over a sell order with a higher price. Transaction is completed. In the case of orders with the same price, the earlier bid is given priority and the transaction is completed.
  • the transaction execution unit 204 manages the bid status (uncommitted bid data) using the “bid management table” and executes the transaction using the table.
  • the bid management table is table information in which uncommitted bid prices are arranged in order for each of a sell order and a buy order.
  • FIG. 9 is a diagram showing an example of a bid management table. As shown in FIG. 9, the quantity of uncommitted bid data is arranged and managed in order of price. Note that in the drawings including FIG. 9, the units of quantity (sell quantity, buy quantity) and price are not shown, but these units can be arbitrary. For example, the unit of quantity can be “kWh” and the unit of price can be “1 yen”.
  • the transaction execution unit 204 or the data management unit 202 can create a bid management table as shown in FIG. 9 by tracing the power transaction data written on the electronic bulletin board since the system was operated.
  • the power transaction by the transaction execution unit 204 is performed according to the principle of price priority and the principle of time priority. Therefore, the management of the bid data included in each price is actually managed, not the management based on the simple combination of the price and quantity as shown in FIG. For example, as described in a balloon in FIG. 9, details of uncommitted bid data (participant ID, quantity, bid time) are managed for each price.
  • the bidding data generation date and time may be used.
  • the transaction execution unit 204 makes a sell bid and a buy bid, the transaction result is reflected in the bid management table.
  • the transaction execution unit 204 acquires the bid data stored in the storage unit 205, and sequentially processes the bid data with the oldest bid time (time stamp).
  • the transaction execution unit 204 performs processing according to the flowchart shown in FIG.
  • the transaction execution unit 204 performs processing according to the flowchart shown in FIG.
  • step S101 shown in FIG. 10 the transaction executing unit 204 determines whether or not the selling price (desired amount of sale) of the seller bid data to be processed is equal to or less than the maximum amount of the buying price (desired purchase amount) managed by the bid management table. Determine whether. For example, in the example shown in FIG. 9, the magnitude of “19”, which is the highest price of the selling price and the buying price, is compared.
  • step S101 If the selling price is higher than the highest bid price (step S101, No branch), the transaction execution unit 204 reflects the seller bid data to be processed in the bid management table and ends the process (step S102).
  • the transaction execution unit 204 determines whether or not the selling quantity (desired power amount for sale) is less than or equal to the quantity of the maximum buying price (step S103). ). For example, in the example shown in FIG. 9, the magnitude of “40” that is the quantity of the selling price and the maximum buying price is compared.
  • the transaction execution unit 204 makes an order from the oldest bid time of the buying bid (step S104). For example, in the example shown in FIG. 9, if the selling quantity is “30”, the selling bid, the oldest buying bid (bid time; 12:01) and the second oldest buying bid (bid time; 12). :)).
  • the transaction execution unit 204 reflects the transaction result (contract result) in the bid management table and ends the process (step S105).
  • step S103 If the selling quantity is larger than the highest bid price (step S103, No branch), the transaction execution unit 204 commits all the selling quantities of the target selling bid at the highest bid price (step S106).
  • the transaction execution unit 204 reflects the transaction result (contract result) in the bid management table (step S107).
  • step S108 the transaction execution unit 204 determines whether or not there is a sales quantity that has not been executed in the process of step S106 among the sales quantities of the seller bid data. For example, in the example shown in FIG. 9, if the selling quantity is “50”, the selling quantity “40” is executed at “19” which is the highest purchase price, and the remaining selling quantity is “10”.
  • step S108 If there is a remaining sale quantity (step S108, Yes branch), the transaction execution unit 204 returns to step S101 and continues the process. Specifically, the transaction execution unit 204 processes the unsold balance using a bid management table that reflects the result of contracting some sales quantities. For example, in the above example, the unsold quantity “10” is executed as a bid bid for the price “18”.
  • step S108 If there is no remaining sales quantity (step S108, No branch), the transaction execution unit 204 ends the process.
  • step S201 shown in FIG. 11 the transaction execution unit 204 determines whether or not the bid price (desired purchase price) of the buyer bid data to be processed is equal to or greater than the minimum price (desired sell price) managed by the bid management table. Determine whether.
  • step S201 If the buying price is lower than the minimum selling price (step S201, No branch), the transaction execution unit 204 reflects the buyer bid data to be processed in the bid management table and ends the process (step S202).
  • the transaction execution unit 204 determines whether or not the purchase quantity (desired power amount for purchase) is less than or equal to the minimum price of the selling price (step S203). ).
  • step S203 If the purchase quantity is less than or equal to the minimum selling price (step S203, Yes branch), the transaction execution unit 204 executes contracts in ascending order of seller bidding time (step S204).
  • the transaction execution unit 204 reflects the transaction result (contract result) in the bid management table and ends the process (step S205).
  • step S203 If the buying quantity is larger than the minimum selling price (step S203, No branch), the transaction execution unit 204 commits all the buying quantities of the target buying bids at the minimum selling price (step S206).
  • the transaction execution unit 204 reflects the transaction result (contract result) in the bid management table (step S207).
  • step S208 the transaction execution unit 204 determines whether or not there is a purchase quantity that has not been executed in step S206 among the purchase quantities of the buyer bid data.
  • step S208 If there is a remaining purchase quantity (step S208, Yes branch), the transaction execution unit 204 returns to step S201 and continues the process.
  • step S208 If there is no remaining purchase quantity (step S208, No branch), the transaction execution unit 204 ends the process.
  • the transaction execution unit 204 stores the transaction result (contract data, deletion data) in the storage unit 205 as necessary when the process regarding the bid data newly acquired by the data management unit 202 is completed.
  • the data management unit 202 writes the transaction result (contract data, deletion data) by the transaction execution unit 204 on the electronic bulletin board via the communication control unit 201.
  • FIG. 12 is a block diagram illustrating an example of a processing configuration of the terminal 20 according to the first embodiment.
  • the terminal 20 includes a communication control unit 301, a bid data management unit 302, and a storage unit 303.
  • the communication control unit 301 is means for realizing communication with other devices (mainly, the management server 40).
  • the communication control unit 301 is also means for distributing a message (packet) received from another device to each processing module or transmitting a message acquired from each processing module to another device.
  • the storage unit 303 is means for storing information necessary for processing of each processing module.
  • the bid data management unit 302 is a means for managing bid data (seller bid data, buyer bid data). Specifically, the bid data management unit 302 generates bid data as shown in FIG. 4 in response to an operation by a user (seller, buyer).
  • the bid data management unit 302 encrypts the generated bid data using the public key of the transaction server 10.
  • the bid data management unit 302 writes the encrypted bid data on the electronic bulletin board.
  • the bid data management unit 302 acquires the contract data described on the electronic bulletin board. If the acquired contract data has the TXID assigned to its bid data, the bid data management unit 302 determines that its bid has been contracted. At that time, the bid data management unit 302 may take measures such as displaying the contract result on the liquid crystal display.
  • the management server 40 constituting the data management system 30 is a device that provides an electronic bulletin board using block chain technology.
  • An electronic bulletin board using a block chain is obvious to those skilled in the art, and a description thereof is omitted.
  • the participant encrypts his / her bid data with the public key of the transaction server 10 and registers it on the electronic bulletin board.
  • the encrypted bid data can be decrypted by the transaction server 10 having a secret key, and the participant (terminal 20) cannot know the contents.
  • the information regarding the bid is kept confidential, and the electronic transaction system according to the first embodiment can provide a fair transaction.
  • power transaction data (bid data, contract data, deletion data) is exchanged via an electronic bulletin board realized by blockchain technology.
  • fraud data rewriting, etc.
  • the fairness of the electronic transaction system is ensured by encrypting the bid data.
  • the participant cannot confirm whether or not the transaction (agreement of bid, uncommitted) is valid by the transaction server 10. This is because the bid data is encrypted with the public key of the transaction server 10, so that the participant can only obtain the encrypted bid data even when accessing the electronic bulletin board.
  • FIG. 13 is a diagram illustrating an example of a configuration of an electronic transaction system according to the second embodiment. Referring to FIG. 13, a verification server 50 is added to the electronic transaction system according to the first embodiment shown in FIG.
  • the verification server 50 is a device that provides information for verifying the legitimacy of the transaction by the transaction server 10. More specifically, the verification server 50 uses the encrypted price of the uncommitted bid data and the encrypted price of the bid data to be verified for the transaction of the transaction server 10. The verification data including the verification character string for verifying the validity of is generated. Details of the verification server 50 will be described later.
  • step S07 can be the same as that described with reference to FIG.
  • the terminal 20a (seller terminal, buyer terminal) requests the verification server 50 to generate the verification data when the transaction result (contract data) by the transaction server 10 is written on the electronic bulletin board and the validity of the transaction is to be verified. To do. Specifically, the terminal 20a designates the type of trading for which verification is requested and the TXID of the bid data to be verified, and transmits a “verification data generation request” to the verification server 50 (step S08).
  • FIG. 14 illustrates a case where the seller terminal verifies the legitimacy regarding the processing of seller bid data.
  • the verification server 50 can verify the legitimacy of the transaction by the transaction server 10 without giving the verifier (terminal 20a) information such as the price described in each bid data. Generate a validation string.
  • the verification server 50 writes information including the generated verification character string as “verification data” on the electronic bulletin board (step S09).
  • the verification server 50 generates verification data in response to the reception of the verification data generation request, and writes the generated verification data on the electronic bulletin board.
  • the terminal 20a (the seller terminal in FIG. 14) acquires the verification data written on the electronic bulletin board, and verifies the legitimacy of the transaction by the transaction server 10 using the verification character string included in the verification data. More specifically, the terminal 20a inputs a verification character string included in the verification data to a verification function to be described later, and whether or not the processing of the bid data by the verification server 50 is valid based on the output result of the verification function. Determine.
  • the terminal 20a can verify whether or not its bid data is correctly processed, but cannot obtain information other than the verification result from the verification data. Specifically, the terminal 20a cannot know the bid price of others. That is, the electronic transaction system according to the second embodiment can verify the legitimacy of the transaction by the transaction server 10 without providing any information to the terminal 20a, with the verification server 50 as the prover and the terminal 20a as the verifier. To realize "zero knowledge proof". That is, the verification on the validity of the transaction of the verification server 50 is a zero knowledge proof that the terminal 20a cannot know the price of the bid data and can verify the validity of the transaction by the verification server 50.
  • FIG. 15 is a diagram illustrating an example of a processing configuration of the terminal 20a according to the second embodiment.
  • the terminal 20 a according to the second embodiment further includes a transaction verification unit 304.
  • the transaction verification unit 304 is a means for verifying the legitimacy of the transaction of the transaction server 10.
  • the transaction verification unit 304 acquires verification data from the electronic bulletin board, and verifies the legitimacy of the transaction by the transaction server 10 using the verification character string included in the verification data. The detailed operation of the transaction verification unit 304 will be described later together with the verification character string generation operation by the verification server 50.
  • the bid data management unit 302 of the terminal 20a encrypts at least the price among the four elements (buying and selling type, participant ID, quantity, and price) forming the bid data.
  • the bid data management unit 302 generates a ciphertext having homomorphism from the price of the bid data using the public key of the transaction server 10.
  • the prices of the bid data are encrypted by an encryption method having homomorphism, thereby enabling calculation of the encrypted prices.
  • the bid data management unit 302 may encrypt the individual element separately (individually) from the price.
  • the verification server 50 generates a verification character string that makes it possible to verify the validity of the transaction by the transaction server 10 in response to a verification data generation request from the terminal 20a, and sends the verification data including the generated verification character string to the electronic bulletin board. Write.
  • FIG. 16 is a diagram illustrating an example of a processing configuration of the verification server 50 according to the second embodiment.
  • the verification server 50 includes a communication control unit 401, a verification data generation unit 402, and a storage unit 403.
  • the communication control unit 401 is means for realizing communication with other devices (mainly, the management server 40).
  • the communication control unit 401 is also means for distributing a message (packet) received from another device to each processing module or transmitting a message acquired from each processing module to another device.
  • the storage unit 403 is means for storing information necessary for processing of each processing module.
  • the verification data generation unit 402 is a means for generating verification data for verifying the legitimacy of the transaction by the transaction server 10 in response to a request from the terminal 20a.
  • the verification data generation unit 402 uses the power transaction data (bid data, contract data) registered in the electronic bulletin board to generate a verification character string that proves the validity of the transaction by the transaction server 10. Generate.
  • the verification data generation unit 402 generates verification data related to the following four transactions by the transaction server 10.
  • the first transaction is when the selling bid is not closed and remains on the electronic bulletin board as uncommitted bid data.
  • the second transaction is when the selling bid is closed and disappears from the electronic bulletin board.
  • the third transaction is a case where the purchase contract cannot be executed and remains on the electronic bulletin board as uncommitted bid data.
  • the fourth transaction is a case where a bid for bid is executed and disappears from the electronic bulletin board.
  • the verification data generation unit 402 determines which of the above four transactions is to be verified from information acquired from the terminal 20a (trading target and verification target and TXID) and information obtained from the electronic bulletin board (bid data and contract data). It can be judged whether there is. Specifically, the verification data generation unit 402 indicates that the first transaction is the target if the sales type acquired from the terminal 20a is “sell” and the acquired TXID is not included in the contract data. I can grasp. Similarly, if the trade type acquired from the terminal 20a is “Sell” and the acquired TXID is included in the contract data, the verification data generation unit 402 can grasp that the second transaction is the target. .
  • the verification data generation unit 402 generates a verification character string that can verify the validity of the four transactions by the methods disclosed in Non-Patent Documents 2 and 3.
  • Non-Patent Documents 2 and 3 disclose a technique for proving that a plaintext of a certain ciphertext is within a predetermined range (range) without revealing the plaintext.
  • a person skilled in the art can easily generate a verification character string that proves that the result of addition (subtraction) of two ciphertexts falls within a predetermined range (range) using this method.
  • the non-patent documents 2 and 3 include a generation function F for generating the verification character string, a verification character string S generated by the generation function F, and validity verification by the verification character string S.
  • a verification function G for realizing each is disclosed.
  • the generation function F and the verification function G are described as one function, but F and G may be processed interactively between a device that generates verification data and a device that performs verification.
  • the generation function F receives the first cipher, the second cipher, and a random number as inputs.
  • Each of the first cipher and the second cipher has a price encrypted by a homomorphic encryption method.
  • these two ciphers are described using TXIDs having prices corresponding to the first cipher and the second cipher. For example, when a price (encrypted price) with TXID “01” is represented as the first cipher, it is represented as E 1 (01). Similarly, when the price of the TXID is expressed as the second cipher, it is expressed as E 2 (01).
  • the random number input to the generation function F is denoted as R1.
  • the generation function F generates a verification character string S in accordance with the input of the three parameters as shown in the following formula (1).
  • F (first cipher E 1 , second cipher E 2 , random number R 1) S (1)
  • the generation function F indicates that the verification result by the verification function G is “true” when the result (difference value) obtained by subtracting the second cipher from the first cipher (encrypted price) is positive or zero. It is designed to be.
  • the verification function G receives the verification character string S and a random number as inputs.
  • the random number input to the verification function G is denoted as R2.
  • the verification function G outputs whether the verification using the verification character string S is “true” or “false” as shown in the following equation (2).
  • G (S, R2) true / false (2)
  • the output of the verification function G being “true” proves that the generation condition of the verification character string S (the difference value between the first cipher and the second cipher is positive or zero) is satisfied. That the output of the verification function G is “false” proves that the generation condition of the verification character string S is not satisfied.
  • the verification data generation unit 402 "The selling price of the selling bid data to be verified is higher than the buying price of uncommitted buy bid data.”
  • the verification character string that proves the following proposition (hereinafter referred to as the first proposition) is generated.
  • the verification data generation unit 402 uses the verification character string S certifying the first proposition, the encrypted bid price of the uncommitted buy bid data as the second cipher, and the sell bid data to be verified as encrypted.
  • the selling price is handled as the first cipher, and a verification character string S is generated.
  • the verification data generation unit 402 generates a verification character string S for each uncommitted buy bid data.
  • the verification data generation unit 402 writes verification data including a plurality of generated verification character strings S and TXID of selling bid data to be verified on the electronic bulletin board. With this verification data, it is possible to verify the validity of the unsettled sale bid data to be verified.
  • TXIDs corresponding to uncommitted bid data are shown in parentheses in the quantity field.
  • the verification data generation unit 402 uses the second cipher for the encrypted bid price of each of the three unsettled buy bid data, and the encrypted bid price for the bid data to be verified as the first.
  • Each of the encryptions is set, and the following verification character string S is generated using the generation function F.
  • Each of E 1 and E 2 described in the above formulas (3) to (5) indicates the first cipher and the second cipher, and the numbers in parentheses indicate the TXID set for the first cipher and the second cipher. .
  • the number following the verification character string S is a suffix for distinguishing the generated verification character string S, and the number in parentheses indicates the TXID input to the generation function F. Note that the TXID in parentheses of the verification character string S is managed by the verification data generation unit 402 at the time of generating each verification character string S and is associated with the generated verification character string S.
  • the verification data generation unit 402 writes the three verification character strings S shown in the expressions (3) to (5) and the corresponding TXID as “verification data” on the electronic bulletin board.
  • the verification data generation unit 402 also writes the TXID that identifies the selling bid data that the written verification data is the target of verification.
  • TXID 30, S 1 (30, 21), S 2 (30, 22), S 3 (30, 23 ) Is written as verification data on the electronic bulletin board.
  • the transaction verification unit 304 of the terminal 20a acquires verification data including the verification character string S from the electronic bulletin board (step S301).
  • the transaction verification unit 304 confirms the TXID associated with each verification character string S, and determines whether or not it matches the TXID of the bid data that has not been promised at the time of selling bid (step S302).
  • the transaction verification unit 304 determines that the verification data is insufficient and ends the process. For example, even though there are four uncommitted data on the electronic bulletin board, when three verification character strings S are included in the verification data, it is determined that the verification data is insufficient. In this case, the terminal 20a takes measures such as notifying the verification server 50 to that effect.
  • the transaction verification unit 304 inputs the verification character string S and the random number R2 to the verification function G, and confirms the authenticity of each verification character string S (step S303). .
  • step S304 If all the determination results by the verification function G are “true” (step S304, Yes branch), the transaction verification unit 304 determines that it is justified that its own bid data is uncommitted (step S305). ). The fact that all the determination results are “true” means that the selling price in its own selling bid data is higher than the buying price of uncommitted buying bid data remaining at the time of selling bid. Therefore, the transaction verification unit 304 can determine that the sale bid data of itself is not agreed.
  • step S304 if at least a part of the determination result by the verification function G is “false” (step S304, No branch), the transaction verifying unit 304 is unjustified that its own bid data is uncommitted. (Step S306).
  • the fact that at least a part of the determination result is “false” means that there is uncommitted buy bid data having a higher bid price than the sell price in the own bid data. Accordingly, the transaction verification unit 304 can determine that the sale bid data of itself is not fulfilled.
  • the price with TXID “30” (the selling price of the seller's bid) is the price with TXID “21” (uncommitted). Higher than the bid price).
  • all the verification character strings S are “true”, it is proved that the selling price to be verified (encrypted selling price) is higher than all the unsettled buying prices (encrypted selling price).
  • the verification data generation unit 402 generates two verification character strings that enable verification of two propositions (second proposition, third proposition).
  • the second proposition is “The bid price of the contracted bid data is the highest bid price of the uncommitted bid data.” It is a proposition.
  • the third proposition is "The selling price of the selling bid data to be verified is less than or equal to the highest bid price of uncommitted buying bid data.” It is a proposition.
  • the second proposition proves that, among the uncommitted buy bid data immediately before the sale bid data to be verified is executed, the bid price of the executed bid data is the highest bid price at the time of the execution. Validity is proved.
  • the third proposition proves the correctness of selling bid data.
  • the verification data generation unit 402 calculates possible combinations of bid prices of uncommitted buy bid data, and proves the second proposition using the bid prices of the respective bid data as the first cipher and second cipher.
  • a verification character string S is generated.
  • the verification data generation unit 402 applies the verification function G to the generated plurality of verification character strings S (inputs the verification character string S and a random number to the verification function G), and obtains its true / false. If the verification result is “true”, the verification data generation unit 402 can grasp that the price of the first cipher is higher than the price of the second cipher. If the verification result is “false”, the verification data generation unit 402 can grasp that the price of the first cipher is lower than the price of the second cipher. Based on the verification result, the verification data generation unit 402 identifies the TXID whose purchase price is the highest purchase price.
  • the possible combinations of TXIDs of uncommitted buy bid data are (21, 22), (21, 23), (22, 23). Therefore, the verification data generation unit 402 inputs the bid price encrypted for each of these combinations to the generation function F. Specifically, the verification data generation unit 402 generates the following verification character string S using the generation function F.
  • F (E 1 (21), E 2 (22), R1) S 4 (21, 22) (6)
  • F (E 1 (21), E 2 (23), R1 ′) S 5 (21, 23) (7)
  • F (E 1 (22), E 2 (23), R1 ′′) S 6 (22, 23) (8)
  • the number in parentheses of the verification character string S is the TXID used when generating the verification character string S, and the verification data generation unit 402 manages and generates the verification character string S in accordance with the generation of each verification character string S. It is associated with the character string S.
  • the TXID whose purchase price is the highest purchase price is specified. For example, if the verification result of equation (6) (true / false by the verification function G) is “true”, the bid price of the buy bid data whose TXID is “21” is the buy bid data whose TXID is “22”. It means that it is higher than the buying price. By determining whether the formulas (6) to (8) are true or false, it is possible to specify that the bid price of the buy bid data with TXID “21” is the highest bid price.
  • the verification data generating unit 402 generates the verification character string S that proves the third proposition by treating the highest bid price as the first cipher and the selling price of the verification target bid data as the second cipher.
  • the verification data generation unit 402 writes the verification character string S generated corresponding to each of the second proposition and the third proposition and the corresponding TXID on the electronic bulletin board. At that time, the verification data generation unit 402 also writes the TXID that identifies the selling bid data that the written verification data is the target of verification.
  • the transaction verification unit 304 acquires verification data including the verification character string S for the second proposition and the verification character string S for the third proposition from the electronic bulletin board (step S401).
  • the transaction verification unit 304 confirms the TXID attached to the verification character string S of the second proposition, and determines whether or not it matches the TXID of the bid data that has not been promised at the time of the bid for sale (step). S402).
  • step S402 determines that the verification data is insufficient and ends the process. If the TXIDs match (step S402, Yes branch), the transaction verification unit 304 executes the processing after step S403.
  • the transaction verification unit 304 inputs the verification character string S for the second proposition and the random number R2 to the verification function G and confirms the authenticity (step S403).
  • the transaction verification unit 304 identifies the TXID of the purchase bid data having the highest purchase price according to the determination result (true / false) by the verification function G (step S404). Specifically, the transaction verification unit 304 identifies TXID whose purchase price is the highest purchase price by the same processing as the verification data generation unit 402 of the verification server 50.
  • the transaction verification unit 304 indicates that the bid price of the bid data whose TXID is “21” is the highest bid price. Identifies it.
  • the transaction verification unit 304 identifies the selling bid data and the TXID of the contracted bid data based on the contract data written on the electronic bulletin board (step S405).
  • the transaction verification unit 304 determines whether or not the two TXIDs match (step S406).
  • the transaction verification unit 304 determines that the own bid data and the contracted bid data are invalid. Determination is made (step S407). The fact that the two TXIDs are different is to indicate that the selling bid to be verified is promised as a buying bid other than the highest bid price.
  • the transaction verification unit 304 executes the processing after step S408.
  • the processes after step S408 are verification processes based on the third proposition.
  • the transaction verification unit 304 inputs the verification character string S for the third proposition and the random number R2 to the verification function G, and confirms the authenticity (step S408).
  • step S409 Yes branch
  • the transaction verification unit 304 determines that the sale bid data of the transaction is valid (step S410).
  • the fact that the determination result is “true” means that the selling price in the own selling bid data is lower than the maximum buying price of the agreed buy bid data. Accordingly, the transaction verification unit 304 can determine that the sale bid data of itself is contracted.
  • step S409 determines that the transaction verification unit 304 is unfair (step S407).
  • the fact that the determination result is “false” means that the selling price in its own selling bid data is higher than the highest bid price of uncommitted buying bid data. Accordingly, the transaction verification unit 304 can determine that the sale bid data of itself is unfair.
  • the verification target is purchase bid data
  • the legitimacy of the transaction by the transaction server 10 can be verified by the same method as the selling bid.
  • a verification character string that enables verification of the correctness related to a bid bid can be generated by appropriately replacing the first and second ciphers input to the generation function F.
  • the verification data generation unit 402 “Bid price of buy bid data to be verified is lower than sell price of unsold sell bid data”
  • the verification character string that proves the following proposition (hereinafter referred to as the fourth proposition) is generated.
  • the verification data generation unit 402 uses the verification character string S certifying the fourth proposition, the encrypted bid price of unsettled selling bid data as the first cipher, and the buying bid data to be verified as encrypted.
  • the selling price is handled as the second cipher, and a verification character string S is generated.
  • the verification data generation unit 402 generates a verification character string S for each unsettled sale bid data.
  • the verification data generation unit 402 writes verification data including the generated plurality of verification character strings S and the TXID of the purchase bid data to be verified on the electronic bulletin board. With this verification data, it is possible to verify the validity of the unsettled purchase bid data to be verified.
  • the transaction verification unit 304 of the terminal 20a acquires verification data including the verification character string S from the electronic bulletin board (step S501).
  • the transaction verification unit 304 confirms the TXID associated with each verification character string S, and determines whether or not it matches the TXID of the sale bid data that has not been promised at the time of the bid bidding (step S502).
  • step S502 If the TXIDs do not match (step S502, No branch), the transaction verification unit 304 determines that the verification data is insufficient and ends the process.
  • the transaction verification unit 304 inputs the verification character string S and the random number R2 to the verification function G, and confirms the authenticity of each verification character string S (step S503). .
  • step S504 If all the determination results based on the verification function G are “true” (step S504, Yes branch), the transaction verification unit 304 determines that it is justified that its own bid data is uncommitted (step S505). ).
  • step S504 If at least a part of the determination result by the verification function G is “false” (step S504, No branch), the transaction verification unit 304 is unfair that its own bid data is uncommitted. Judgment is made (step S506).
  • the verification data generation unit 402 In order to prove the validity of the fourth transaction, the verification data generation unit 402 generates two verification character strings that prove two propositions (fifth proposition and sixth proposition).
  • the fifth proposition is “The selling price of the contracted bid data is the minimum selling price of the unsold bid data.” It is a proposition.
  • the sixth proposition is "The bid price of the bid data to be verified is greater than or equal to the minimum bid price of unsold sell bid data.” It is a proposition.
  • the fifth proposition proves that the unsold sell bid data just before the bid bid data to be verified is closed, and that the sold price of the sold bid data is the minimum sell price at the time of the contract. Validity is proved.
  • the sixth proposition proves the validity of executing the bid bidding data.
  • the verification data generation unit 402 calculates possible combinations of selling prices of unsettled selling bid data, and proves the fifth proposition using the selling prices of the selling bid data constituting the combinations as the first cipher and the second cipher.
  • a verification character string S is generated.
  • the verification data generation unit 402 applies the verification function G to the generated plurality of verification character strings S (inputs the verification character string S and a random number to the verification function G), and obtains its true / false. If the verification result is “true”, the verification data generation unit 402 can grasp that the price of the first cipher is higher than the price of the second cipher. If the verification result is “false”, the verification data generation unit 402 can grasp that the price of the first cipher is lower than the price of the second cipher. The verification data generation unit 402 identifies TXID whose selling price is the minimum selling price based on the verification result.
  • the verification data generation unit 402 generates the verification character string S that proves the sixth proposition by treating the minimum selling price as the second cipher and the buy price of the bid data to be verified as the first cipher.
  • the verification data generation unit 402 writes the verification character string S generated corresponding to each of the fifth proposition and the sixth proposition and the corresponding TXID on the electronic bulletin board. At that time, the verification data generation unit 402 also writes a TXID that specifies the bid data for which the written verification data is to be verified.
  • the transaction verification unit 304 acquires verification data including the verification character string S for the fifth proposition and the verification character string S for the sixth proposition from the electronic bulletin board (step S601).
  • the transaction verification unit 304 confirms the TXID attached to the verification character string S of the fifth proposition, and determines whether or not it matches with the TXID of the sale bid data that has not been promised at the time of the bid bidding (step). S602).
  • step S602 determines that the verification data is insufficient and ends the process. If the TXIDs match (step S602, Yes branch), the transaction verification unit 304 executes the processing after step S603.
  • the transaction verification unit 304 inputs the verification character string S for the fifth proposition and the random number R2 to the verification function G, and confirms the authenticity (step S603).
  • the transaction verifying unit 304 specifies the TXID of the selling bid data whose selling price is the minimum amount according to the determination result (true / false) by the verification function G (step S604).
  • the transaction verification unit 304 identifies its own bid data and the TXID of the bid data sold by the contract data written on the electronic bulletin board (step S605).
  • the transaction verification unit 304 determines whether or not the two TXIDs match (step S606).
  • step S606 When the TXID specified from the verification character string S and the TXID specified from the contract data do not match (step S606, No branch), the transaction verification unit 304 determines that its own bid data and the sold bid data contracted are invalid. Determination is made (step S607).
  • the transaction verification unit 304 executes the processing after step S608.
  • the processing after step S608 is verification processing according to the sixth proposition.
  • the transaction verification unit 304 inputs the verification character string S for the sixth proposition and the random number R2 to the verification function G and confirms the authenticity (step S608).
  • step S609 If the determination result by the verification function G is “true” (step S609, Yes branch), the transaction verification unit 304 determines that the purchase bid data of itself is valid (step S610).
  • step S609 If the determination result by the verification function G is “false” (step S609, No branch), the transaction verification unit 304 determines that the purchase bid data of itself is unfair (step S607).
  • the verification character strings related to the above four transactions allow verification of whether the transaction server 10 is executing a transaction in accordance with the “price priority principle”.
  • the terminal 20a may confirm the time stamp of each bid data.
  • the verification server 50 generates a verification character string that enables verification of whether or not the transaction of the transaction server 10 is valid.
  • the terminal 20a that wants to verify the legitimacy of the transaction verifies the legitimacy of the transaction using the verification character string. At that time, the terminal 20a cannot know the price of uncommitted bid data. This is because the information obtained from the verification character string remains in the size of the two ciphertexts.
  • zero knowledge proof for verifying the validity of the transaction by the transaction server 10 is realized without giving any information about the price to the terminal 20a. In other words, the transaction server 10 is monitored for transactions from the terminal 20a by the zero knowledge proof, and cannot perform fraud contrary to the principle of the Zaraba method.
  • the encrypted bid price is shared by the transaction server 10, the prover (verification server 50), and the verifier (terminal 20), and the fraud that the transaction server 10 deletes the bid itself cannot be performed.
  • the fact that the fraud cannot be done is secured by an electronic bulletin board using blockchain technology.
  • FIG. 2 the structure (FIG. 2, FIG. 13) of the electronic transaction system demonstrated in 1st and 2nd embodiment is an illustration, Comprising: It is not the meaning which limits the structure of a system.
  • the function of the verification server 50 may be incorporated in the transaction server 10.
  • the terminal 20 encrypts the bid data using the public key of the transaction server 10.
  • a common key may be distributed to each terminal 20, and the terminal 20 may encrypt bid data using the common key.
  • the terminal 20 should just be able to specify the common key used for the decryption in the transaction server 10 without encrypting the participant ID.
  • the encryption method disclosed in the present application is not limited to a public key encryption infrastructure using a public key and a secret key.
  • the transaction server 10 may periodically write data (a list of uncommitted bid data) indicating the latest bid status on the electronic bulletin board.
  • the verification server 50 generates verification data in response to receiving a verification data generation request from the terminal 20a.
  • the verification server 50 may generate verification data and write it on the electronic bulletin board without receiving the verification data generation request.
  • the verification server 50 may generate verification data indicating the validity of each of the selling bid and the buying bid and register it on the electronic bulletin board.
  • [Appendix 1] The electronic trading system according to the first aspect described above.
  • [Appendix 2] Verifying the legitimacy of the transaction of the transaction server using the encrypted price of the uncommitted bid data and the encrypted price of the bid data to be verified by the transaction server
  • [Appendix 3] The transaction server The electronic transaction system according to appendix 2, wherein the contract data including the ID (Identifier) of the agreed sale bid data and the ID of the purchase bid data is written on the electronic bulletin board.
  • the terminal The electronic transaction system according to appendix 3, preferably acquiring the written contract data and confirming whether or not its bid has been executed.
  • the terminal transmits a verification data generation request including an ID of bid data to be verified to the verification server, Preferably, the verification server generates the verification data in response to receiving the verification data generation request, and writes the generated verification data on the electronic bulletin board.
  • the terminal The written verification data is acquired, a verification character string included in the verification data is input to a verification function, and based on an output result of the verification function, the transaction of the verification target bid data by the transaction server is valid.
  • the electronic trading system according to appendix 5, preferably for determining whether or not there has been.
  • the verification on the validity of the transaction of the transaction server is a zero knowledge proof that the terminal cannot know the price of the bid data and can verify the validity of the transaction by the transaction server, preferably Appendix 6. Electronic transaction system.
  • the verification server When generating the verification data regarding the sale bid data not being fulfilled, The verification character string that proves the first proposition that the selling price of the selling bid data to be verified is higher than the buying price of the uncommitted buying bid data is generated, preferably according to any one of appendices 2 to 7 Electronic trading system.
  • the verification server When generating the verification data regarding the execution of sell bid data, The verification string proving the second proposition that the bid price of the contracted bid data is the highest bid price of the uncommitted bid data; The verification character string that proves the third proposition that the selling price of the selling bid data to be verified is less than or equal to the highest bid price of uncommitted buying bid data is generated, preferably any one of appendices 2 to 8 The electronic transaction system according to 1.
  • the verification server When generating the verification data regarding the fact that the bid bidding data was not executed, The verification character string that proves the fourth proposition that the bid price of the buy bid data to be verified is lower than the sell price of the unsettled sell bid data is preferably generated, preferably according to any one of appendices 2 to 9 Electronic trading system.
  • the verification server When generating the verification data regarding the purchase bid data being executed, The verification character string certifying the fifth proposition that the selling price of the contracted selling bid data is the minimum selling price of the unsold selling bid data; The verification character string that proves the sixth proposition that the bid price of the bid data to be verified is equal to or greater than the minimum price of the unsold bid data, preferably any one of appendices 2 to 10
  • the electronic transaction system according to 1.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Health & Medical Sciences (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Public Health (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Water Supply & Treatment (AREA)
  • Primary Health Care (AREA)
  • Technology Law (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

公平な取引を提供する電子取引システムを提供する。電子取引システムは、複数の管理サーバと、端末と、取引サーバと、含む。複数の管理サーバは、電子掲示板を提供する。端末は、暗号化された価格を含む入札データを電子掲示板に書き込む。取引サーバは、書き込まれた入札データを取得し、暗号化された価格を復号し、復号された価格を用いてザラバ方式により取引を実行する。

Description

電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム
　本発明は、電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムに関する。
　近年、通信技術や情報処理技術の発展と共に、ネットワーク上にて種々のサービスが提供されている。例えば、特許文献１には、ネットワークを用いた電子取引システムが開示されている。また、特許文献２、特許文献３及び非特許文献１には、電力の売買をネットワーク上で行うためのシステムが開示されている。
　ネットワーク上で取引等を行う場合には、情報漏洩や不正の防止が重要となる。この点に関して、特許文献４には、各サーバの出力が入力に対して適正な処理を行った後にその順序を置換したものであることをより少ない計算量、通信量で効率的に証明、検証する方法及び装置を提供する、と記載されている。
　非特許文献２及び非特許文献３は、ある暗号文の平文が所定の範囲（レンジ）に収まることを、平文を明かさずに証明する手法を開示している。
特許第２００２－２１５９３５号公報 特許第６１７７４１０号公報 特許第６２３４５４０号公報 特開２００１－２１７８２４号公報
田中謙司等、"ブロックチェーンを用いた電力融通取引プラットフォームの一提案"、２０１８年１月２３日、ＳＣＩＳ２０１８ Jan Camenisch, etc、"Efficient Protocols for Set Membership and Range Proofs"、2008、Proceedings of the 14th International Conference on the Theory and Application of Cryptology and Information Security, 234-252 ODED GOLDREICH, etc、"Proofs that Yield Nothing But Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems"、July 1991、Journal of the ACM (JACM) Volume 38
　なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
　上述のように、ネットワーク上では種々のサービスが提供されている。特に、非特許文献１には、電力取引にブロックチェーンを活用する技術が開示されている。非特許文献１の技術によれば、個々のユーザが自身の電力消費量や発電量に基づき、電力の過不足を推定し、ブロックチェーン上で電力取引を行うことで電力融通が実現できる。
　しかし、非特許文献１では、個々の発注情報（入札データ）は平文で登録されており、少なくとも電力融通システムの参加者は、他人の発注状況を把握可能となっている。他人の発注状況が把握可能であると、公平な取引を損なう可能性がある。例えば、売買する意志は無いにもかかわらず、大量の買い入札を行いあたかも電力需要が旺盛であるかのように見せかけ、有利な価格で売電を実現するような不正を許しかねない。
　本発明は、公平な取引を提供することに寄与する電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムを提供することを主たる目的とする。
　本発明乃至開示の第１の視点によれば、電子掲示板を提供する、複数の管理サーバと、暗号化された価格を含む入札データを前記電子掲示板に書き込む、端末と、前記書き込まれた入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバと、を含む、電子取引システムが提供される。
　本発明乃至開示の第２の視点によれば、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバが提供される。
　本発明乃至開示の第３の視点によれば、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、未約定な入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバが提供される。
　本発明乃至開示の第４の視点によれば、取引サーバにおいて、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得するステップと、前記暗号化された価格を復号するステップと、前記復号された価格を用いてザラバ方式により取引を実行するステップと、を含む、電子取引方法が提供される。
　本発明乃至開示の第５の視点によれば、取引サーバに搭載されたコンピュータに、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得する処理と、前記暗号化された価格を復号する処理と、前記復号された価格を用いてザラバ方式により取引を実行する処理と、を実行させるプログラムが提供される。
　なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明乃至開示の各視点によれば、公平な取引を提供することに寄与する電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムが、提供される。
一実施形態の概要を説明するための図である。 第１の実施形態に係る電子取引システムの構成の一例を示す図である。 第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。 入札データを説明するための図である。 約定データの一例を示す図である。 データ管理システムが提供する電子掲示板に書き込まれたデータの一例を示す図である。 第１の実施形態に係る取引サーバのハードウェア構成の一例を示すブロック図である。 第１の実施形態に係る取引サーバの処理構成の一例を示すブロック図である。 入札管理テーブルの一例を示す図である。 取引実行部の動作の一例を示すフローチャートである。 取引実行部の動作の一例を示すフローチャートである。 第１の実施形態に係る端末の処理構成の一例を示すブロック図である。 第２の実施形態に係る電子取引システムの構成の一例を示す図である。 第２の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。 第２の実施形態に係る端末の処理構成の一例を示す図である。 第２の実施形態に係る検証サーバの処理構成の一例を示す図である。 第２の実施形態に係る検証サーバの動作を説明するための図である。 第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。 第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。 第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。 第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。
　初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。
　一実施形態に係る電子取引システムは、複数の管理サーバ１０１と、端末１０２と、取引サーバ１０３と、含む（図１参照）。複数の管理サーバ１０１は、電子掲示板を提供する。端末１０２は、暗号化された価格を含む入札データを電子掲示板に書き込む。取引サーバ１０３は、書き込まれた入札データを取得し、暗号化された価格を復号し、復号された価格を用いてザラバ方式（価格優先、時間優先）により取引を実行する。
　上記電子取引システムにおいて、端末１０２は、入札データを、例えば、取引サーバ１０３の公開鍵により暗号化し、電子掲示板に登録する。暗号化された入札データを復号できるのは、秘密鍵を有する取引サーバ１０３であり、他の参加者は、その内容を知ることができない。その結果、入札に係る情報の秘密が保持され、上記電子取引システムは公平な取引を提供できる。
　以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
［第１の実施形態］
　第１の実施形態について、図面を用いてより詳細に説明する。
［システム構成概略］
　図２は、第１の実施形態に係る電子取引システムの構成の一例を示す図である。図２を参照すると、電子取引システムは、取引サーバ１０と、複数の端末２０－１～２０－Ｎ（Ｎは正の整数、以下同じ）と、データ管理システム３０と、を含んで構成される。
　取引サーバ１０、端末２０－１～２０－Ｎ及びデータ管理システム３０のそれぞれは、インターネット等のネットワークを介して相互に接続されている。
　電子取引システムの取引対象は特に限定されないが、本願開示では主に「電力」を取引の対象として説明を行う。但し、本願開示の電子取引システムは、株式等の金融商品等の取引にも適用可能である。
　取引サーバ１０は、電力の買い手と売り手の注文を仲介する装置である。
　端末２０－１～２０－Ｎは、電力取引の参加者が使用する端末である。例えば、パーソナルコンピュータやスマートフォン等の情報処理装置が、上記端末に相当する。なお、以降の説明において、端末２０－１～２０－Ｎを区別する特段の理由が無い場合には、単に「端末２０」と表記する。
　また、端末２０の使用者が買電を希望する場合に、当該使用者が利用する端末を「買い手端末」と表記する。同様に、端末２０の使用者が売電を希望する場合に、当該使用者が利用する端末を「売り手端末」と表記する。
　データ管理システム３０は、取引サーバ１０の運営主体や電力取引の参加者（入札者；売り手、買い手）から独立した立場の機関等が運営するシステムである。データ管理システム３０は、外部（第３者）に対し追記及び読み出しの可能な電子掲示板を提供するシステムである。より具体的には、データ管理システム３０は、どのような主体でも情報を追記できると共に、書き込まれた情報を読み出すことができ、且つ、一度書き込まれた情報は消去されたり改竄されたりすることのない電子掲示板を提供する。データ管理システム３０は、所謂、ブロックチェーンと称される技術により上記特徴を持つ電子掲示板を提供する。
　図２に示す電子取引システムでは、電力取引に必要な情報（以下、電力取引データと表記する）の授受を、ブロックチェーンにより実現される電子掲示板を介して行う。なお、上述のように、データ管理システム３０は、いずれの主体に対しても電子掲示板を提供するシステムであるため、当該電子掲示板には上記電力取引データとは無関係なデータが混在することとなる。
　データ管理システム３０は、複数の管理サーバ４０－１～４０－４から構成されている。なお、図２の例示は、データ管理システム３０を構成する管理サーバの台数を４台に限定する趣旨ではない。データ管理システム３０は２台以上の管理サーバを含んで構成されていればよい。また、端末２０と同様に、管理サーバ４０－１～４０－４を区別する特段の理由がない場合には、単に「管理サーバ４０」と表記する。
　データ管理システム３０をなす複数の管理サーバ４０は、図２に示すように、相互に直接接続されている。即ち、データ管理システム３０は、Ｐ２Ｐ（Peer to Peer）接続された複数の管理サーバ４０を含んで構成される。
　データ管理システム３０では、Ｐ２Ｐ接続された複数の管理サーバ４０それぞれが、外部から受信したデータ（例えば、電力取引データ）を管理するためのデータ管理台帳を有する。データ管理システム３０は、当該データ管理台帳を複数の管理サーバ４０に分散し共有して、管理する。
　データ管理システム３０をなす管理サーバ４０は、取引サーバ１０や端末２０から電力取引データを電子掲示板に書き込む旨の要求を取得するたびに、データ管理台帳に当該電力取引データを追記する。また、各管理サーバ４０は、当該データ管理台帳に追記するデータの正当性を証明するデータを生成する。具体的には、管理サーバ４０は、上記追記データの正当性を証明するデータとして各管理サーバ４０の電子署名（デジタル署名）を用いるものとする。
　電子署名の生成が終了すると、管理サーバ４０は、データ管理台帳への追記データに電子署名を付して、他の管理サーバ４０に配布する。他の管理サーバ４０は、当該追記データを受信すると、その正当性を検証した後に自身のデータ管理台帳を更新する。
［システム動作概略］
　次に、図面を参照しつつ、第１の実施形態に係る電子取引システムの動作概略を説明する。
　図３は、第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。
　売電を希望する参加者は、売買の種別（売り注文）、自身を特定する識別子（参加者ＩＤ；IDentifier）と、売却を希望する電力量（数量）と、売却希望額（価格）、を含む「売り手入札データ」を電子掲示板に書き込む（売り手入札；ステップＳ０１）。
　その際、売り手端末は、売り手入札データを取引サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４（ａ）に示すデータが暗号化され、電子掲示板に書き込まれる。
　同様に、買電を希望する参加者は、売買の種別（買い注文）、自身を特定する参加者ＩＤ、購入を希望する電力量と、購入希望額、を含む「買い手入札データ」を電子掲示板に書き込む（買い手入札；ステップＳ０２）。
　買い手端末は、買い手入札データを取引サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４（ｂ）に示すデータが暗号化され、電子掲示板に書き込まれる。
　端末２０は、図４に示す４つの項目（売買種別、参加者ＩＤ、数量、価格）の全てを暗号化せずに、数量だけを暗号化してもよい。少なくとも数量が暗号化されていれば取引の安全は確保できるためである。このように、第１の実施形態に係る端末２０は、暗号化された価格を含む入札データを電子掲示板に書き込む。
　なお、以降の説明において、売り手入札データと買い手入札データを区別する必要が無い場合には、単に「入札データ」と表記する。
　取引サーバ１０は、電子掲示板に定期的にアクセスし、入札データを取得する（ステップＳ０３）。
　取得した入札データは暗号化されているので、取引サーバ１０は、自身の秘密鍵を用いて取得した入札データの暗号文を復号する（ステップＳ０４）。
　取引サーバ１０は、予め定めたタイミング等で、取得した入札データを用いた取引を実行する（ステップＳ０５）。取引サーバ１０による取引処理の詳細は後述する。
　取引サーバ１０は、取引結果を電子掲示板に書き込む。
　なお、電子掲示板に入札データが書き込まれると、当該入札データを特定するためのトランザクションＩＤ（以下、ＴＸＩＤと表記する）が付与される。取引サーバ１０は、当該ＴＸＩＤを利用して取引結果を電子掲示板に書き込む。具体的には、取引サーバ１０は、売り入札と買い入札が成立（約定）した場合には、当該約定した入札データのＴＸＩＤを含むデータを「約定データ」として電子掲示板に書き込む（図５参照）。
　また、取引サーバ１０は、約定したＴＸＩＤを指定し、当該ＴＸＩＤを取引の場から削除した旨の削除データを電子掲示板に書き込む。当該削除データにより、端末２０は、取引の場に残る入札データ（未約定な入札データ）を把握することができる。
　売り手と買い手は、電子掲示板にアクセスし、約定データを取得し、取引結果を確認する（ステップＳ０６、ステップＳ０７）。つまり、端末２０（売り手端末、買い手端末）は、電子掲示板に書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する。
　端末２０は、約定データを参照することで、自身の入札データの状態（約定、未約定）を把握できる。あるいは、端末２０は、削除データを確認することによっても自身の入札が約定したか否かを確認できる。
　端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応するものであれば、自身の入札が約定したことを把握できる。一方、端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応したものでなければ、自身の入札は約定せず、未約定な入札として電子掲示板（取引の場）に残っていることが把握できる。
　例えば、図６に示すような電力取引データ（入札データ、約定データ）が電子掲示板に書き込まれているとする。図６は、ＴＸＩＤが「０１」、「０２」の売り入札が行われ、その後、ＴＸＩＤが「０３」の買い入札が行われていることを示している。その後、ＴＸＩＤが「０１」の売り入札とＴＸＩＤが「０３」の買い入札が約定し、ＴＸＩＤが「０４」の約定データとして電子掲示板に書き込まれている。なお、図６に示す「ＰＩＤ」は参加者ＩＤを示す。
　取引サーバ１０、端末２０は、図６に示すような電力取引データ（入札データ、約定データ）を確認することで、ＴＸＩＤが「０２」の売り入札は未約定な入札データとして電子掲示板に残っていることも確認できる。
　つまり、取引サーバ１０は、システム稼働時からの電子掲示板に書き込まれた電力取引データをトレースすることで最新の入札状況（未約定な状態で残っている入札データ）を把握することができる。同様に、端末２０は、電子掲示板に書き込まれた電力取引データをトレースすることで、最新の入札状況を把握することができる。
　但し、端末２０は、自身の入札に関する状況（約定済み、未約定）を把握することができるが、入札データは暗号化されているため、電子掲示板に残っている入札データの詳細（少なくとも価格の詳細）を知ることはできない。
［ハードウェア構成］
　次に、第１の実施形態に係る電子取引システムを構成する各種装置のハードウェア構成を説明する。
　図７は、第１の実施形態に係る取引サーバ１０のハードウェア構成の一例を示すブロック図である。
　取引サーバ１０は、情報処理装置（コンピュータ）により構成可能であり、図７に例示する構成を備える。例えば、取引サーバ１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インターフェイス１３及び通信手段であるＮＩＣ（Network Interface Card）１４等を備える。
　但し、図７に示す構成は、取引サーバ１０のハードウェア構成を限定する趣旨ではない。取引サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス１３を備えていなくともよい。また、取引サーバ１０に含まれるＣＰＵ等の数も図７の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ１１が取引サーバ１０に含まれていてもよい。
　メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）である。
　入出力インターフェイス１３は、図示しない表示装置や入力装置のインターフェイスとなる手段である。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
　取引サーバ１０の機能は、後述する各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ１２に格納されたプログラムをＣＰＵ１１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段があればよい。
　なお、端末２０や管理サーバ４０も取引サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は取引サーバ１０と相違する点は無いので説明を省略する。
［取引サーバの処理構成］
　次に、取引サーバ１０の詳細について説明する。取引サーバ１０は、電子掲示板に書き込まれた入札データを取得し、暗号化された価格を復号する。さらに、取引サーバ１０は、復号された価格を用いてザラバ方式により取引を実行する。
　図８は、第１の実施形態に係る取引サーバ１０の処理構成の一例を示すブロック図である。図８を参照すると、取引サーバ１０は、通信制御部２０１と、データ管理部２０２と、復号部２０３と、取引実行部２０４と、記憶部２０５と、を含んで構成される。
　通信制御部２０１は、ＮＩＣ１４を制御し、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部２０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
　記憶部２０５は、メモリ１２により実現され、各処理モジュールの処理に必要な情報等を記憶する手段である。
　データ管理部２０２は、電子掲示板にアクセスし、電力取引データ（入札データ、約定データ、削除データ）を管理する手段である。データ管理部２０２は、電子掲示板に定期的にアクセスし、電子掲示板に新規に書き込まれた（取引サーバ１０が一度も取得していない）入札データを取得する。データ管理部２０２は、取得した入札データを復号部２０３に引き渡す。また、データ管理部２０２は、取引実行部２０４による取引結果（約定データ、削除データ）を、通信制御部２０１を介して電子掲示板に書き込む。
　復号部２０３は、取引サーバ１０の公開鍵で暗号化されている入札データを復号する手段である。より具体的には、復号部２０３は、暗号化されている入札データを、秘密鍵を用いて復号し、復号結果（平文の入札データ）を記憶部２０５に格納する。
　取引実行部２０４は、入札データを用いた取引（電力取引）を実行する手段である。取引実行部２０４は、所謂、ザラバ方式と称される手法により電力取引を実現する。より具体的には、取引実行部２０４は、多数の売り入札と買い入札のなかで価格と数量が一致したものから順に取引を成立させていく。
　より具体的には、取引実行部２０４は、「価格優先の原則」と「時間優先の原則」に従って取引を成立させていく。例えば、買い注文（買い入札）であれば、安い価格の買い注文よりも高い価格の買い注文が優先され、売り注文であれば、高い価格の売り注文よりも安い価格の売り注文が優先されて取引が成立する。同じ価格の注文の場合には、より早く入札があった方が優先され取引が成立する。
　取引実行部２０４は、「入札管理テーブル」を用いて入札状況（未約定な入札データ）を管理し、当該テーブルを用いて取引を実行する。入札管理テーブルとは、売り注文、買い注文それぞれについて、未約定な入札価格を順に並べたテーブル情報である。
　図９は、入札管理テーブルの一例を示す図である。図９に示すように、未約定な入札データの数量が価格順に並べられ、管理される。なお、図９を含む図面において、数量（売り数量、買い数量）や価格の単位を記載していないが、これらの単位は任意とすることができる。例えば、数量の単位は「ｋＷｈ」とし、価格の単位は「１円」とすることができる。
　取引実行部２０４又はデータ管理部２０２が、システム稼働時からの電子掲示板に書き込まれた電力取引データをトレースすることで図９に示すような入札管理テーブルを作成できる。
　ここで、上述のように、取引実行部２０４による電力取引は、価格優先の原則と時間優先の原則に従って行われる。そのため、図９に示すような価格と数量だけの単純な組み合わせによる管理ではなく、実際には、各価格に含まれる入札データの詳細が管理されている。例えば、図９の吹き出しに記載したように、価格ごとに未約定な入札データの詳細（参加者ＩＤ、数量、入札時間）が管理される。
　なお、参加者ＩＤ及び数量は入札データに記載された情報を用いればよい。入札時間に関しては、入札データの生成日時（タイムスタンプ）を用いればよい。また、取引実行部２０４が、売り入札と買い入札を約定させた場合には、当該約定の結果を入札管理テーブルに反映する。
　続いて、図１０及び図１１を参照しつつ、取引実行部２０４の動作を説明する。
　取引実行部２０４は、記憶部２０５に格納された入札データを取得し、入札時間（タイムスタンプ）が古い入札データから順に処理をしていく。
　その際、取引実行部２０４は、入札データが「売り手入札データ」であった場合には、図１０に示すフローチャートに従って処理をする。取引実行部２０４は、入札データが「買い手入札データ」であった場合には、図１１に示すフローチャートに従って処理をする。
　初めに、入札データが「売り手入札データ」である場合の取引実行部２０４の動作を説明する。
　図１０に示すステップＳ１０１において、取引実行部２０４は、処理対象となる売り手入札データの売値（売却希望額）が入札管理テーブルにより管理される買値（購入希望額）の最高額以下であるか否かを判定する。例えば、図９に示す例では、売値と買値の最高額である「１９」の大小が比較される。
　売値が買値の最高額よりも高ければ（ステップＳ１０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の売り手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ１０２）。
　売値が買値の最高額以下であれば（ステップＳ１０１、Ｙｅｓ分岐）、取引実行部２０４は、売り数量（売却希望電力量）が買値最高額の数量以下であるか否かを判定する（ステップＳ１０３）。例えば、図９に示す例では、売り数量と買値最高額の数量である「４０」の大小が比較される。
　売り数量が買値最高額の数量以下であれば（ステップＳ１０３、Ｙｅｓ分岐）、取引実行部２０４は、買い入札の入札時間の古い順に約定する（ステップＳ１０４）。例えば、図９に示す例では、売り数量が「３０」であれば、売り入札と、入札時間の最も古い買い入札（入札時間；１２：０１）及び２番目に古い買い入札（入札時間；１２：１０）と、が約定する。
　取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ１０５）。
　売り数量が買値最高額の数量より大きければ（ステップＳ１０３、Ｎｏ分岐）、取引実行部２０４は、対象となる売り入札の売り数量の全てを買値最高額にて約定する（ステップＳ１０６）。
　取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ１０７）。
　ステップＳ１０８において、取引実行部２０４は、売り手入札データの売り数量のうち、ステップＳ１０６の処理にて約定しなかった売り数量が存在するか否かを判定する。例えば、図９に示す例では、売り数量が「５０」であれば、買値最高額である「１９」にて売り数量「４０」が約定し、売り数量の残は「１０」となる。
　売り数量の残が存在すれば（ステップＳ１０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ１０１に戻り処理を継続する。具体的には、取引実行部２０４は、一部の売り数量が約定した結果が反映された入札管理テーブルを用いて、売り残が処理される。例えば、上記の例では、売り残の数量「１０」は、価格「１８」の買い入札と約定することになる。
　売り数量の残が存在しなければ（ステップＳ１０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。
　次に、入札データが「買い手入札データ」である場合の取引実行部２０４の動作を説明する。
　図１１に示すステップＳ２０１において、取引実行部２０４は、処理対象となる買い手入札データの買値（購入希望額）が入札管理テーブルにより管理される売値（売却希望額）の最低額以上であるか否かを判定する。
　買値が売値の最低額よりも低ければ（ステップＳ２０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の買い手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ２０２）。
　買値が売値の最低額以上であれば（ステップＳ２０１、Ｙｅｓ分岐）、取引実行部２０４は、買い数量（購入希望電力量）が売値最低額の数量以下であるか否かを判定する（ステップＳ２０３）。
　買い数量が売値最低額の数量以下であれば（ステップＳ２０３、Ｙｅｓ分岐）、取引実行部２０４は、売り手入札の入札時間の古い順に約定する（ステップＳ２０４）。
　取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ２０５）。
　買い数量が売値最低額の数量より大きければ（ステップＳ２０３、Ｎｏ分岐）、取引実行部２０４は、対象となる買い入札の買い数量の全てを売値最低額にて約定する（ステップＳ２０６）。
　取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ２０７）。
　ステップＳ２０８において、取引実行部２０４は、買い手入札データの買い数量のうち、ステップＳ２０６の処理にて約定しなかった買い数量が存在するか否かを判定する。
　買い数量の残が存在すれば（ステップＳ２０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ２０１に戻り処理を継続する。
　買い数量の残が存在しなければ（ステップＳ２０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。
　取引実行部２０４は、データ管理部２０２が新たに取得した入札データに関する処理を終了すると、必要に応じて取引結果（約定データ、削除データ）を記憶部２０５に記憶する。データ管理部２０２は、取引実行部２０４による上記取引結果（約定データ、削除データ）を、通信制御部２０１を介して電子掲示板に書き込む。
［端末の処理構成］
　次に、端末２０の詳細について説明する。
　図１２は、第１の実施形態に係る端末２０の処理構成の一例を示すブロック図である。図１２を参照すると、端末２０は、通信制御部３０１と、入札データ管理部３０２と、記憶部３０３と、を含んで構成される。
　通信制御部３０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部３０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
　記憶部３０３は、各処理モジュールの処理に必要な情報等を記憶する手段である。
　入札データ管理部３０２は、入札データ（売り手入札データ、買い手入札データ）に関する管理を行う手段である。具体的には、入札データ管理部３０２は、ユーザ（売り手、買い手）による操作に応じて、図４に示すような入札データを生成する。
　さらに、入札データ管理部３０２は、生成した入札データを取引サーバ１０の公開鍵を用いて暗号化する。入札データ管理部３０２は、当該暗号化された入札データを電子掲示板に書き込む。
　また、入札データ管理部３０２は、電子掲示板に記載された約定データを取得する。取得した約定データが自身の入札データに付与されたＴＸＩＤを有するものであれば、入札データ管理部３０２は、自身の入札は約定したものと判断する。その際、入札データ管理部３０２は、約定結果を液晶ディスプレイに表示する等の対応を行ってもよい。
［管理サーバ］
　データ管理システム３０をなす管理サーバ４０は、ブロックチェーン技術を用いて電子掲示板を提供する装置である。ブロックチェーンを利用した電子掲示板は当業者にとって明らかで有り、その説明を省略する。
　以上のように、第１の実施形態に係る電子取引システムでは、参加者は、自身の入札データを取引サーバ１０の公開鍵により暗号化し、電子掲示板に登録している。暗号化された入札データを復号できるのは、秘密鍵を有する取引サーバ１０であり、参加者（端末２０）は、その内容を知ることができない。その結果、入札に係る情報の秘密が保持され、第１の実施形態に係る電子取引システムは公平な取引を提供できる。
　また、第１の実施形態に係る電子取引システムでは、ブロックチェーン技術により実現される電子掲示板を介して電力取引データ（入札データ、約定データ、削除データ）のやり取りを行う。その結果、取引サーバ１０による約定データに対する不正（データの書き換え等）等を防止することができる。
［第２の実施形態］
　続いて、第２の実施形態について図面を参照して詳細に説明する。
　第１の実施形態では、入札データを暗号化することで、電子取引システムの公正性を確保している。しかし、参加者は、取引サーバ１０により取引（入札の約定、未約定）が正当なものであるか否かを確認することができない。入札データは取引サーバ１０の公開鍵にて暗号化されているため、参加者は、電子掲示板にアクセスしても暗号化された入札データを取得できるに留まるためである。
　換言すれば、取引所（取引サーバ１０の管理者）が本来の取引（例えば、価格優先の原則等）を遂行せず、不正な取引を行う余地がある。例えば、参加者Ａの買値が参加者Ｂの買値よりも高いにもかかわらず、参加者Ｂの入札を優先して約定させるといった取引が生じ得る。第２の実施形態では、このような取引所（取引サーバ１０の管理者）による不正を防止する電子取引システムについて説明する。
　図１３は、第２の実施形態に係る電子取引システムの構成の一例を示す図である。図１３を参照すると、図２に示す第１の実施形態に係る電子取引システムに検証サーバ５０が追加されている。
　検証サーバ５０は、取引サーバ１０による取引の正当性を検証するための情報を提供する装置である。より具体的には、検証サーバ５０は、未約定な入札データの暗号化された価格と、正当性を検証する対象となる入札データの暗号化された価格と、を用いて取引サーバ１０の取引の正当性を検証するための検証文字列を含む検証データを生成する。検証サーバ５０の詳細は後述する。
　第２の実施形態に係る取引サーバ１０の構成、動作は第１の実施形態にて説明した内容と相違する点はないので、取引サーバ１０の図７、図８等に相当する説明を省略する。
　初めに、図１４を参照しつつ、第２の実施形態に係る電子取引システムの動作概要を説明する。図１４において、ステップＳ０７までの処理は図３を参照して説明した内容と同一とすることができるので、その説明を省略する。
　端末２０ａ（売り手端末、買い手端末）は、取引サーバ１０による取引結果（約定データ）が電子掲示板に書き込まれ、当該取引の正当性を検証したい場合に、検証サーバ５０に上記検証データの生成を要求する。具体的には、端末２０ａは、検証を要求する売買の種別と検証対象となる入札データのＴＸＩＤを指定し、検証サーバ５０に対して「検証データ生成要求」を送信する（ステップＳ０８）。なお、図１４では、売り手端末が売り手入札データの処理に関する正当性を検証する場合を図示している。
　検証サーバ５０は、上記検証データ生成要求を受信すると、検証者（端末２０ａ）には各入札データに記載された価格等の情報を与えずに、取引サーバ１０による取引の正当性を検証可能とする検証文字列を生成する。検証サーバ５０は、当該生成した検証文字列を含む情報を「検証データ」として電子掲示板に書き込む（ステップＳ０９）。このように、検証サーバ５０は、検証データ生成要求の受信に応じて検証データを生成し、生成された検証データを電子掲示板に書き込む。
　端末２０ａ（図１４では、売り手端末）は、電子掲示板に書き込まれた検証データを取得し、当該検証データに含まれる検証文字列を用いて取引サーバ１０による取引の正当性を検証する。より具体的には、端末２０ａは、検証データに含まれる検証文字列を後述する検証関数に入力し、当該検証関数の出力結果に基づき、検証サーバ５０による入札データの処理が正当であったか否かを判定する。
　なお、端末２０ａは、自身の入札データが正しく処理されたか否かを検証することはできるが、検証データから上記検証結果以外の情報を得ることはできない。具体的には、端末２０ａは、他者の入札価格等を知ることはできない。即ち、第２の実施形態に係る電子取引システムは、検証サーバ５０を証明者、端末２０ａを検証者とし、端末２０ａに何らの情報を与えることなく、取引サーバ１０による取引の正当性を検証可能とする「零知識証明」を実現する。つまり、検証サーバ５０の取引の正当性に関する検証は、端末２０ａが入札データの価格を知ることはできず、且つ、検証サーバ５０による取引の正当性を検証可能とする、零知識証明である。
　続いて、端末２０ａ及び検証サーバ５０の各装置について説明する。
［端末の処理構成］
　図１５は、第２の実施形態に係る端末２０ａの処理構成の一例を示す図である。図１５を参照すると、第２の実施形態に係る端末２０ａは、取引検証部３０４をさらに備えている。
　取引検証部３０４は、取引サーバ１０の取引に関する正当性を検証する手段である。取引検証部３０４は、電子掲示板から検証データを取得し、当該検証データに含まれる検証文字列を用いて、取引サーバ１０による取引の正当性を検証する。取引検証部３０４の詳細動作は、検証サーバ５０による検証文字列の生成動作と合わせて後述する。
　なお、第２の実施形態に係る端末２０ａの入札データ管理部３０２は、入札データをなす４要素（売買種別、参加者ＩＤ、数量、価格）のうち、少なくとも価格を暗号化する。その際、入札データ管理部３０２は、入札データの価格から取引サーバ１０の公開鍵を用いつつ準同型性を有する暗号文を生成する。第２の実施形態では、準同型性を有する暗号方式により入札データの価格を暗号化することで、暗号化された価格同士の演算を可能とする。
　端末２０ａが、他の要素（例えば、電力量）を暗号化する場合には、入札データ管理部３０２は、当該他の要素を価格とは別に（個別に）暗号化すればよい。
［検証サーバの処理構成］
　続いて、検証サーバ５０の詳細について説明する。なお、検証サーバ５０のハードウェア構成は、取引サーバ１０等と同一とすることができるので説明を省略する。
　検証サーバ５０は、端末２０ａからの検証データ生成要求に応じて取引サーバ１０による取引の正当性を検証可能とする検証文字列を生成し、当該生成した検証文字列を含む検証データを電子掲示板に書き込む。
　図１６は、第２の実施形態に係る検証サーバ５０の処理構成の一例を示す図である。図１６を参照すると、検証サーバ５０は、通信制御部４０１と、検証データ生成部４０２と、記憶部４０３と、を含んで構成される。
　通信制御部４０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部４０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
　記憶部４０３は、各処理モジュールの処理に必要な情報等を記憶する手段である。
　検証データ生成部４０２は、端末２０ａからの要求に応じて、取引サーバ１０による取引の正当性を検証するための検証データを生成する手段である。検証データ生成部４０２は、検証データ生成要求を受信すると、電子掲示板に登録された電力取引データ（入札データ、約定データ）を用いて、取引サーバ１０による取引の正当性を証明する検証文字列を生成する。
　検証データ生成部４０２は、取引サーバ１０による以下の４つの取引に関する検証データを生成する。
　第１の取引は、売り入札が約定せず、未約定な入札データとして電子掲示板に残る場合である。
　第２の取引は、売り入札が約定し、電子掲示板から消える場合である。
　第３の取引は、買い約定が約定せず、未約定な入札データとして電子掲示板に残る場合である。
　第４の取引は、買い入札が約定し、電子掲示板から消える場合である。
　なお、検証データ生成部４０２は、端末２０ａから取得する情報（検証対象の売買とＴＸＩＤ）と電子掲示板から得られる情報（入札データ、約定データ）から、上記４つの取引のうちいずれが検証対象であるか判断できる。具体的には、検証データ生成部４０２は、端末２０ａから取得した売買種別が「売り」であって、取得したＴＸＩＤが約定データに含まれていなければ、上記第１の取引が対象であると把握できる。同様に、検証データ生成部４０２は、端末２０ａから取得した売買種別が「売り」であって、取得したＴＸＩＤが約定データに含まれていれば、上記第２の取引が対象であると把握できる。
　検証データ生成部４０２は、上記４つの取引の正当性を検証可能とする検証文字列を非特許文献２、３に開示された手法により生成する。非特許文献２、３は、ある暗号文の平文が所定の範囲（レンジ）に収まることを、平文を明かさずに証明する手法を開示している。当業者であれば、当該手法を用いて、２つの暗号文の加算（減算）の結果が所定の範囲（レンジ）に収まることを証明する検証文字列を容易に生成することができる。
　具体的には、上記非特許文献２、３には、上記検証文字列を生成するための生成関数Ｆ、当該生成関数Ｆにより生成された検証文字列Ｓ、検証文字列Ｓによる正当性検証を実現するための検証関数Ｇがそれぞれ開示されている。以下では、生成関数Ｆや検証関数Ｇをそれぞれ１つの関数として記述するが、Ｆ、Ｇは検証データを生成する装置と、検証する装置の間で対話的に処理されるものでもよい。
　生成関数Ｆは、第１暗号、第２暗号、乱数を入力とする。第１暗号、第２暗号のそれぞれは、準同型暗号方式により暗号化された価格である。以下の説明では、第１暗号、第２暗号に対応する価格のＴＸＩＤを用いてこれら２つの暗号を表記する。例えば、ＴＸＩＤが「０１」の価格（暗号化された価格）を第１暗号として表記する場合には、Ｅ１（０１）と表記する。同様に、上記ＴＸＩＤの価格を第２暗号として表記する場合には、Ｅ２（０１）と表記する。また、生成関数Ｆに入力する乱数をＲ１と表記する。
　生成関数Ｆは、下記の式（１）に示すように、上記３つのパラメータの入力に応じて、検証文字列Ｓを生成する。
Ｆ（第１暗号Ｅ１、第２暗号Ｅ２、乱数Ｒ１）＝Ｓ・・・（１）
　ここでは、上記生成関数Ｆは、第１暗号（暗号化された価格）から第２暗号を減算した結果（差分値）が正又はゼロである場合に、検証関数Ｇによる検証結果が「真」となるように設計されている。
　検証関数Ｇは、上記検証文字列Ｓと乱数を入力とする。検証関数Ｇに入力する乱数をＲ２と表記する。検証関数Ｇは、下記の式（２）に示すように、検証文字列Ｓを用いた検証が「真」であるか「偽」であるかを出力する。
Ｇ（Ｓ、Ｒ２）＝真／偽　・・・（２）
　検証関数Ｇの出力が「真」であることは、検証文字列Ｓの生成条件（第１暗号と第２暗号の差分値が正又はゼロ）が成立していることを証明する。検証関数Ｇの出力が「偽」であることは、検証文字列Ｓの生成条件は不成立であることを証明する。
　以下、取引サーバ１０による上記４つの取引について検証データ生成部４０２の検証データ生成動作と、端末２０ａの取引検証部３０４による検証動作と、を合わせて説明する。
［第１の取引；売り入札が未約定］
［検証データの生成動作］
　第１の取引の正当性を検証可能とするため、検証データ生成部４０２は、
「未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高い」
という命題（以下、第１命題と表記する）を証明する検証文字列を生成する。
　検証データ生成部４０２は、上記第１命題を証明する検証文字列Ｓを、未約定な買い入札データの暗号化された買値を上記第２暗号、検証対象となる売り入札データの暗号化された売値を上記第１暗号としてそれぞれ扱い、検証文字列Ｓを生成する。検証データ生成部４０２は、未約定な買い入札データのそれぞれについて、検証文字列Ｓを生成する。
　検証データ生成部４０２は、生成した複数の検証文字列Ｓと、検証対象となる売り入札データのＴＸＩＤと、を含む検証データを電子掲示板に書き込む。当該検証データにより、検証対象の売り入札データが未約定であることの正当性が検証可能となる。
　例えば、検証対象の売り入札データが電子掲示板に書き込まれる直前の入札状況が図１７（ａ）のとおりとする。また、検証対象の売り入札データは、図１７（ｂ）のとおりとする。なお、図１７（ａ）には、数量のフィールドに未約定な入札データに対応するＴＸＩＤを括弧書きにて併記している。
　図１７に示す状況の場合、検証データ生成部４０２は、未約定な３つの買い入札データそれぞれの暗号化された買値を第２暗号、検証対象の売り入札データの暗号化された売値を第１暗号にそれぞれ設定し、生成関数Ｆを用いて以下の検証文字列Ｓを生成する。
Ｆ（Ｅ１（３０）、Ｅ２（２１）、Ｒ１）＝Ｓ１（３０、２１）・・・（３）
Ｆ（Ｅ１（３０）、Ｅ２（２２）、Ｒ１’）＝Ｓ２（３０、２２）・・・（４）
Ｆ（Ｅ１（３０）、Ｅ２（２３）、Ｒ１’’）＝Ｓ３（３０、２３）・・・（５）
　上記式（３）～（５）に記載したＥ１、Ｅ２のそれぞれは、第１暗号及び第２暗号を示し、その括弧内の数字は第１暗号及び第２暗号に設定したＴＸＩＤを示す。また、検証文字列Ｓに続く数字は生成された検証文字列Ｓを区別するためのサフィックスであり、括弧内の数字は生成関数Ｆに入力したＴＸＩＤを示す。なお、検証文字列Ｓの括弧内のＴＸＩＤは、検証データ生成部４０２が、各検証文字列Ｓの生成時に合わせて管理し、生成した検証文字列Ｓと対応付けておく。
　検証データ生成部４０２は、式（３）～（５）に示す３つの検証文字列Ｓ及び対応するＴＸＩＤを「検証データ」として電子掲示板に書き込む。検証データ生成部４０２は、書き込んだ検証データが検証の対象とした売り入札データを特定するＴＸＩＤも併せて書き込む。
　上記の例では、ＴＸＩＤが「３０」の売り入札データが検証対象の入札データであるので、ＴＸＩＤ＝３０、Ｓ１（３０、２１）、Ｓ２（３０、２２）、Ｓ３（３０、２３）が検証データとして電子掲示板に書き込まれる。
［第１の取引；売り入札が未約定］
［検証データによる検証動作］
　続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図１８を参照しつつ説明する。
　端末２０ａの取引検証部３０４は、検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ３０１）。
　次に、取引検証部３０４は、各検証文字列Ｓに付随するＴＸＩＤを確認し、売り入札時点で未約定であった買い入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ３０２）。
　ＴＸＩＤが一致しなければ（ステップＳ３０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。例えば、電子掲示板には４つの未約定なデータが存在するにも関わらず、３つの検証文字列Ｓが検証データに含まれる場合には、当該検証データは不十分と判断される。この場合、端末２０ａはその旨を検証サーバ５０に通知する等の対応をする。
　ＴＸＩＤが一致すれば（ステップＳ３０２、Ｙｅｓ分岐）、取引検証部３０４は、検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、検証文字列Ｓそれぞれについての真偽を確認する（ステップＳ３０３）。
　取引検証部３０４は、検証関数Ｇによる全ての判定結果が「真」であれば（ステップＳ３０４、Ｙｅｓ分岐）、自身の売り入札データが未約定であることは正当であると判断する（ステップＳ３０５）。全ての判定結果が「真」であるという事実は、自身の売り入札データにおける売値は、売り入札の時点に残る未約定な買い入札データの買値よりも高いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定しないことは、正当と判断できる。
　対して、取引検証部３０４は、検証関数Ｇによる判定結果のうち少なくとも一部の結果が「偽」であれば（ステップＳ３０４、Ｎｏ分岐）、自身の売り入札データが未約定であることは不当であると判断する（ステップＳ３０６）。少なくとも一部の判定結果が「偽」であるという事実は、自身の売り入札データにおける売値よりも買値が高い未約定な買い入札データが存在することを意味する。従って、取引検証部３０４は、自身の売り入札データが約定しないことは、不当と判断できる。
　図１７に示す上述の例では、検証文字列Ｓ１（３０、２１）が真であれば、ＴＸＩＤが「３０」の価格（売り手入札の売値）は、ＴＸＩＤが「２１」の価格（未約定な買値）よりも高いことを示す。同様に、検証文字列Ｓ２（３０、２２）が真であれば、検証対象の売値（ＴＸＩＤ＝３０）は、未約定な買値（ＴＸＩＤ＝２２）よりも高い事を示す。このように、検証文字列Ｓが全て「真」であれば、検証対象の売値（暗号化された売値）が、未約定な買値（暗号化された買値）の全てよりも高いことが証明される。
［第２の取引；売り入札が約定］
［検証データの生成動作］
　続いて、第２の取引に関する検証データの生成について説明する。第２の取引の正当性を証明するには、検証データ生成部４０２は、２つの命題（第２命題、第３命題）を検証可能とする２つの検証文字列を生成する。
　第２命題は、
「約定した買い入札データの買値は、未約定な買い入札データの買値最高額である」
という命題である。
　第３命題は、
「検証対象とする売り入札データの売値が、未約定な買い入札データの買値最高額以下である」
という命題である。
　第２命題により、検証対象の売り入札データが約定する直前の未約定な買い入札データのうち、約定した買い入札データの買値が当該約定時の買値最高額であることが証明され、約定価格の正当性が証明される。また、第３命題により、売り入札データを約定することの正当性が証明される。
　検証データ生成部４０２は、未約定な買い入札データの買値の取り得る組み合わせを算出し、当該組み合わせをなす各買い入札データそれぞれの買値を第１暗号、第２暗号として、第２命題を証明する検証文字列Ｓを生成する。
　その後、検証データ生成部４０２は、生成した複数の検証文字列Ｓに検証関数Ｇを適用して（検証関数Ｇに検証文字列Ｓと乱数を入力して）、その真偽を得る。検証データ生成部４０２は、検証結果が「真」であれば第１暗号の価格が第２暗号の価格よりも高いことが把握できる。また、検証結果が「偽」であれば、検証データ生成部４０２は、第１暗号の価格は第２暗号の価格よりも低いことが把握できる。検証データ生成部４０２は、当該検証結果に基づき、買値が買値最高額であるＴＸＩＤを特定する。
　例えば、図１７の例では、未約定な買い入札データのＴＸＩＤの取り得る組み合わせは、（２１、２２）、（２１、２３）、（２２、２３）である。そこで、検証データ生成部４０２は、これらの各組み合わせについて暗号化された買値を生成関数Ｆに入力する。具体的には、検証データ生成部４０２は、生成関数Ｆを用いて以下の検証文字列Ｓを生成する。
Ｆ（Ｅ１（２１）、Ｅ２（２２）、Ｒ１）＝Ｓ４（２１、２２）・・・（６）
Ｆ（Ｅ１（２１）、Ｅ２（２３）、Ｒ１’）＝Ｓ５（２１、２３）・・・（７）
Ｆ（Ｅ１（２２）、Ｅ２（２３）、Ｒ１’’）＝Ｓ６（２２、２３）・・・（８）
　なお、検証文字列Ｓの括弧内の数字は検証文字列Ｓを生成する際に使用したＴＸＩＤであり、検証データ生成部４０２が、各検証文字列Ｓの生成時に合わせて管理し、生成した検証文字列Ｓと対応付けておく。
　式（６）～（８）の検証文字列Ｓ４～Ｓ６を用いた検証結果により、買値が買値最高額であるＴＸＩＤが特定される。例えば、式（６）の検証結果（検証関数Ｇによる真偽）が「真」であれば、ＴＸＩＤが「２１」である買い入札データの買値が、ＴＸＩＤが「２２」である買い入札データの買値より高いことを意味する。式（６）～（８）の真偽を判定することで、ＴＸＩＤが「２１」の買い入札データの買値が買値最高額であると特定できる。
　検証データ生成部４０２は、買値最高額を上記第１暗号、検証対象の売り入札データの売値を上記第２暗号としてそれぞれ扱い、第３命題を証明する検証文字列Ｓを生成する。
　例えば、図１７の例では、第２命題の検証文字列Ｓを生成した際に、ＴＸＩＤが「２１」の買い入札データの買値が買値最高額であることが判明している。そこで、検証データ生成部４０２は、以下の式（９）で示される検証文字列Ｓを生成する。
Ｆ（Ｅ１（２１）、Ｅ２（３０）、Ｒ１）＝Ｓ７（２１、３０）・・・（９）
　検証データ生成部４０２は、第２命題、第３命題それぞれに対応して生成した検証文字列Ｓ及び対応するＴＸＩＤを電子掲示板に書き込む。その際、検証データ生成部４０２は、書き込んだ検証データが検証の対象とした売り入札データを特定するＴＸＩＤも併せて書き込む。
　上述の例では、ＴＸＩＤが「３０」の売り入札データが検証対象の入札データである。従って、ＴＸＩＤ＝３０、Ｓ４（２１、２２）、Ｓ５（２１、２３）、Ｓ６（２２、２３）、Ｓ７（２１、３０）が検証データとして電子掲示板に書き込まれる。上記検証文字列Ｓ４～Ｓ７を含むデータが、売り入札データが約定したことの正当性を示す検証データとして電子掲示板に書き込まれる。
［第２の取引；売り入札が約定］
［検証データによる検証動作］
　続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図１９を参照しつつ説明する。
　取引検証部３０４は、第２命題用の検証文字列Ｓと第３命題用の検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ４０１）。
　次に、取引検証部３０４は、第２命題の検証文字列Ｓに付随するＴＸＩＤを確認し、売り入札時点で未約定であった買い入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ４０２）。
　ＴＸＩＤが一致しなければ（ステップＳ４０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。ＴＸＩＤが一致すれば（ステップＳ４０２、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ４０３以降の処理を実行する。
　取引検証部３０４は、第２命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ４０３）。
　取引検証部３０４は、検証関数Ｇによる判定結果（真偽）に応じて、買値が最高額であった買い入札データのＴＸＩＤを特定する（ステップＳ４０４）。具体的には、取引検証部３０４は、検証サーバ５０の検証データ生成部４０２と同様の処理により、買値が買値最高額であるＴＸＩＤを特定する。
　上述の例では、式（６）～（８）により示される検証文字列Ｓを用いた判定結果により、取引検証部３０４は、ＴＸＩＤが「２１」である買い入札データの買値が買値最高額であると特定する。
　次に、取引検証部３０４は、電子掲示板に書き込まれた約定データにより、自身の売り入札データと約定した買い入札データのＴＸＩＤを特定する（ステップＳ４０５）。
　取引検証部３０４は、上記２つのＴＸＩＤが一致するか否かを判定する（ステップＳ４０６）。
　取引検証部３０４は、検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが不一致の場合（ステップＳ４０６、Ｎｏ分岐）、自身の売り入札データと約定した買い入札データは不当であると判定する（ステップＳ４０７）。２つのＴＸＩＤが異なるという事実は、検証対象の売り入札が、買値最高額以外の買い入札と約定したことを示すためである。
　検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが一致する場合（ステップＳ４０６、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ４０８以降の処理を実行する。ステップＳ４０８以降の処理は、第３命題による検証処理である。
　第２命題の正当性が確認されると、取引検証部３０４は、第３命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ４０８）。
　取引検証部３０４は、検証関数Ｇによる判定結果が「真」であれば（ステップＳ４０９、Ｙｅｓ分岐）、自身の売り入札データが約定したことは正当であると判定する（ステップＳ４１０）。判定結果が「真」であるという事実は、自身の売り入札データにおける売値は、約定した買い入札データの買値最高額よりも安いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定したことは、正当と判断できる。
　対して、取引検証部３０４は、検証関数Ｇによる判定結果が「偽」であれば（ステップＳ４０９、Ｎｏ分岐）、自身の売り入札データが約定したことは不当であると判断する（ステップＳ４０７）。判定結果が「偽」であるという事実は、自身の売り入札データにおける売値は、未約定な買い入札データの買値最高額よりも高いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定したことは、不当と判断できる。
　図１７に示す上述の例では、検証文字列Ｓ４～Ｓ６により、「２１」が買値最高額のＴＸＩＤであると特定される。その後、検証文字列Ｓ７により、自身の売り入札の売値（ＴＸＩＤ＝３０）と買値最高額（ＴＸＩＤ＝２１）の大小が検証される。自身の売値よりも買値最高額が高ければ、検証対象の売り入札が約定することは正当と判断できる。
　続いて、検証対象が買い入札データの場合について説明する。検証対象が買い入札の場合も売り入札と同様の手法により取引サーバ１０による取引の正当性が検証できる。例えば、買い入札に関する検証文字列を生成する際、生成関数Ｆに入力する第１暗号、第２暗号を適宜入れ替えることで買い入札に関する正当性を検証可能とする検証文字列を生成できる。
［第３の取引；買い入札が未約定］
［検証データの生成動作］
　第３の取引の正当性を証明するには、検証データ生成部４０２は、
「未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低い」
という命題（以下、第４命題と表記する）を証明する検証文字列を生成する。
　検証データ生成部４０２は、上記第４命題を証明する検証文字列Ｓを、未約定な売り入札データの暗号化された買値を上記第１暗号、検証対象となる買い入札データの暗号化された売値を上記第２暗号としてそれぞれ扱い、検証文字列Ｓを生成する。検証データ生成部４０２は、未約定な売り入札データのそれぞれについて、検証文字列Ｓを生成する。
　検証データ生成部４０２は、生成した複数の検証文字列Ｓと、検証対象となる買い入札データのＴＸＩＤと、を含む検証データを電子掲示板に書き込む。当該検証データにより、検証対象の買い入札データが未約定であることの正当性が検証可能となる。
［第３の取引；買い入札が未約定］
［検証データによる検証動作］
　続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図２０を参照しつつ説明する。
　端末２０ａの取引検証部３０４は、検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ５０１）。
　次に、取引検証部３０４は、各検証文字列Ｓに付随するＴＸＩＤを確認し、買い入札時点で未約定であった売り入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ５０２）。
　ＴＸＩＤが一致しなければ（ステップＳ５０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。
　ＴＸＩＤが一致すれば（ステップ５０２、Ｙｅｓ分岐）、取引検証部３０４は、検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、検証文字列Ｓそれぞれについての真偽を確認する（ステップＳ５０３）。
　取引検証部３０４は、検証関数Ｇによる全ての判定結果が「真」であれば（ステップＳ５０４、Ｙｅｓ分岐）、自身の買い入札データが未約定であることは正当であると判断する（ステップＳ５０５）。
　取引検証部３０４は、検証関数Ｇによる判定結果のうち少なくとも一部の結果が「偽」であれば（ステップＳ５０４、Ｎｏ分岐）、自身の買い入札データが未約定であることは不当であると判断する（ステップＳ５０６）。
［第４の取引；買い入札が約定］
［検証データの生成動作］
　第４の取引の正当性を証明するには、検証データ生成部４０２は、２つの命題（第５命題、第６命題）を証明する２つの検証文字列を生成する。
　第５命題は、
「約定した売り入札データの売値は、未約定な売り入札データの売値最低額である」
という命題である。
　第６命題は、
「検証対象とする買い入札データの買値が、未約定な売り入札データの売値最低額以上である」
という命題である。
　第５命題により、検証対象の買い入札データが約定する直前の未約定な売り入札データのうち、約定した売り入札データの売値が当該約定時の売値最低額であることが証明され、約定価格の正当性が証明される。また、第６命題により、買い入札データを約定することの正当性が証明される。
　検証データ生成部４０２は、未約定な売り入札データの売値の取り得る組み合わせを算出し、当該組み合わせをなす各売り入札データそれぞれの売値を第１暗号、第２暗号として、第５命題を証明する検証文字列Ｓを生成する。
　その後、検証データ生成部４０２は、生成した複数の検証文字列Ｓに検証関数Ｇを適用して（検証関数Ｇに検証文字列Ｓと乱数を入力して）、その真偽を得る。検証データ生成部４０２は、検証結果が「真」であれば第１暗号の価格が第２暗号の価格よりも高いことが把握できる。また、検証結果が「偽」であれば、検証データ生成部４０２は、第１暗号の価格は第２暗号の価格よりも低いことが把握できる。検証データ生成部４０２は、当該検証結果に基づき、売値が売値最低額であるＴＸＩＤを特定する。
　検証データ生成部４０２は、売値最低額を上記第２暗号、検証対象の買い入札データの買値を上記第１暗号としてそれぞれ扱い、第６命題を証明する検証文字列Ｓを生成する。
　検証データ生成部４０２は、第５命題、第６命題それぞれに対応して生成した検証文字列Ｓ及び対応するＴＸＩＤを電子掲示板に書き込む。その際、検証データ生成部４０２は、書き込んだ検証データが検証の対象とした買い入札データを特定するＴＸＩＤも併せて書き込む。
［第４の取引；買い入札が約定］
［検証データによる検証動作］
　続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図２１を参照しつつ説明する。
　取引検証部３０４は、第５命題用の検証文字列Ｓと第６命題用の検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ６０１）。
　次に、取引検証部３０４は、第５命題の検証文字列Ｓに付随するＴＸＩＤを確認し、買い入札時点で未約定であった売り入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ６０２）。
　ＴＸＩＤが一致しなければ（ステップＳ６０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。ＴＸＩＤが一致すれば（ステップＳ６０２、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ６０３以降の処理を実行する。
　取引検証部３０４は、第５命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ６０３）。
　取引検証部３０４は、検証関数Ｇによる判定結果（真偽）に応じて、売値が最低額であった売り入札データのＴＸＩＤを特定する（ステップＳ６０４）。
　次に、取引検証部３０４は、電子掲示板に書き込まれた約定データにより、自身の買い入札データと約定した売り入札データのＴＸＩＤを特定する（ステップＳ６０５）。
　取引検証部３０４は、上記２つのＴＸＩＤが一致するか否かを判定する（ステップＳ６０６）。
　取引検証部３０４は、検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが不一致の場合（ステップＳ６０６、Ｎｏ分岐）、自身の買い入札データと約定した売り入札データは不当であると判定する（ステップＳ６０７）。
　検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが一致する場合（ステップＳ６０６、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ６０８以降の処理を実行する。ステップＳ６０８以降の処理は、第６命題による検証処理である。
　第５命題の正当性が確認されると、取引検証部３０４は、第６命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ６０８）。
　取引検証部３０４は、検証関数Ｇによる判定結果が「真」であれば（ステップＳ６０９、Ｙｅｓ分岐）、自身の買い入札データが約定したことは正当であると判定する（ステップＳ６１０）。
　取引検証部３０４は、検証関数Ｇによる判定結果が「偽」であれば（ステップＳ６０９、Ｎｏ分岐）、自身の買い入札データが約定したことは不当であると判断する（ステップＳ６０７）。
　なお、上記４つの取引に関する検証文字列は、「価格優先の原則」に従って取引サーバ１０が取引を実行しているか検証可能とするものである。取引サーバ１０が「時間優先の原則」に従って取引を実行しているか否かを検証するには、端末２０ａは、各入札データのタイムスタンプを確認すればよい。
　以上のように、第２の実施形態では、検証サーバ５０が取引サーバ１０の取引が正当であるか否かを検証可能とする検証文字列を生成する。取引の正当性を検証したい端末２０ａは、当該検証文字列を用いて取引の正当性を検証する。その際、端末２０ａは、未約定な入札データの価格を知ることはできない。検証文字列から得られる情報は、２つの暗号文の大小に留まるからである。このように、第２の実施形態では、端末２０ａに対して価格に関する何らの情報を与えず、取引サーバ１０による取引の正当性を検証する零知識証明を実現する。換言すれば、取引サーバ１０は、上記零知識証明により端末２０ａから取引を監視されることになり、ザラバ方式の原則に反するような不正を行うことができない。また、暗号化された入札価格は、取引サーバ１０、証明者（検証サーバ５０）及び検証者（端末２０）にて共有されており、取引サーバ１０が入札自体を抹消するような不正はできない。当該不正ができないことは、ブロックチェーン技術を用いた電子掲示板により担保されている。
［変形例］
　なお、第１及び第２の実施形態にて説明した電子取引システムの構成（図２、図１３）は例示であって、システムの構成を限定する趣旨ではない。例えば、検証サーバ５０の機能が取引サーバ１０に組み込まれていてもよい。
　上記実施形態では、端末２０が取引サーバ１０の公開鍵を用いて入札データを暗号化することを説明した。しかし、端末２０それぞれに共通鍵を配布し、端末２０は当該共通鍵を用いて入札データを暗号化してもよい。その場合、端末２０は、参加者ＩＤを暗号化せず、取引サーバ１０にて復号に使用する共通鍵を特定可能とすればよい。本願開示の暗号方式は、公開鍵及び秘密鍵を用いる公開鍵暗号基盤に限定されない。
　上記実施形態では、取引サーバ１０や端末２０がシステム稼働時からの電力取引データをトレースすることで最新の入札状況を把握できることを説明した。しかし、システムの稼働が長期に亘ると入札状況の把握に多大な労力（コスト）が必要となる。そこで、取引サーバ１０等が定期的に最新の入札状況を示すデータ（未約定な入札データの一覧）を電子掲示板に書き込んでもよい。
　上記第２の実施形態では、検証サーバ５０は、端末２０ａからの検証データ生成要求の受信に応じて検証データを生成している。しかし、検証サーバ５０は、検証データ生成要求を受信しなくとも検証データを生成し、電子掲示板に書き込んでもよい。例えば、検証サーバ５０は、取引が約定するたびに、売り入札及び買い入札それぞれの正当性を示す検証データを生成し、電子掲示板に登録してもよい。
　また、上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態は、内容が相反しない範囲で組み合わせることができる。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
　上述の第１の視点に係る電子取引システムのとおりである。
［付記２］
　未約定な入札データの暗号化された価格と、前記取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバをさらに備える、好ましくは付記１の電子取引システム。
［付記３］
　前記取引サーバは、
　約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記電子掲示板に書き込む、好ましくは付記２の電子取引システム。
［付記４］
　前記端末は、
　前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、好ましくは付記３の電子取引システム。
［付記５］
　前記端末は、前記検証サーバに対して、検証対象となる入札データのＩＤを含む検証データ生成要求を送信し、
　前記検証サーバは、前記検証データ生成要求の受信に応じて前記検証データを生成し、前記生成された検証データを前記電子掲示板に書き込む、好ましくは付記４の電子取引システム。
［付記６］
　前記端末は、
　前記書き込まれた検証データを取得し、前記検証データに含まれる検証文字列を検証関数に入力し、前記検証関数の出力結果に基づき、前記取引サーバによる前記検証対象の入札データの取引が正当であったか否かを判定する、好ましくは付記５の電子取引システム。
［付記７］
　前記取引サーバの取引の正当性に関する検証は、前記端末が入札データの価格を知ることはできず、且つ、前記取引サーバによる取引の正当性を検証可能とする、零知識証明である、好ましくは付記６の電子取引システム。
［付記８］
　前記検証サーバは、
　売り入札データが約定しなかったことに関する前記検証データを生成する場合には、
　未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高いという、第１命題を証明する前記検証文字列を生成する、好ましくは付記２乃至７のいずれか一に記載の電子取引システム。
［付記９］
　前記検証サーバは、
　売り入札データが約定したことに関する前記検証データを生成する場合には、
　約定した買い入札データの買値は未約定な買い入札データの買値最高額である、という第２命題を証明する前記検証文字列と、
　検証対象とする売り入札データの売値は未約定な買い入札データの買値最高額以下である、という第３命題を証明する前記検証文字列と、を生成する、好ましくは付記２乃至８のいずれか一に記載の電子取引システム。
［付記１０］
　前記検証サーバは、
　買い入札データが約定しなかったことに関する前記検証データを生成する場合には、
　未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低いという、第４命題を証明する前記検証文字列を生成する、好ましくは付記２乃至９のいずれか一に記載の電子取引システム。
［付記１１］
　前記検証サーバは、
　買い入札データが約定したことに関する前記検証データを生成する場合には、
　約定した売り入札データの売値は未約定な売り入札データの売値最低額である、という第５命題を証明する前記検証文字列と、
　検証対象とする買い入札データの買値は未約定な売り入札データの売値最低額以上である、という第６命題を証明する前記検証文字列と、を生成する、好ましくは付記２乃至１０のいずれか一に記載の電子取引システム。
［付記１２］
　前記複数の管理サーバは、相互に直接接続され、
　前記複数の管理サーバのそれぞれが、外部から受信したデータを管理するためのデータ管理台帳を有し、外部の装置からデータを電子掲示板に書き込む旨の要求を取得するたびに、前記データ管理台帳にデータを追記する、好ましくは付記１乃至１１のいずれか一に記載の電子取引システム。
［付記１３］
　上述の第２の視点に係る取引サーバのとおりである。
［付記１４］
　上述の第３の視点に係る検証サーバのとおりである。
［付記１５］
　上述の第４の視点に係る電子取引方法のとおりである。
［付記１６］
　上述の第５の視点に係るプログラムのとおりである。
　なお、付記１３～１６の形態は、付記１の形態と同様に、付記２の形態～付記１２の形態に展開することが可能である。
　なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
１０、１０３　取引サーバ
１１　ＣＰＵ（Central Processing Unit）
１２　メモリ
１３　入出力インターフェイス
１４　ＮＩＣ（Network Interface Card）
２０、２０ａ、２０－１～２０－Ｎ、２０ａ－１～２０ａ－Ｎ、１０２　端末
３０　データ管理システム
４０、４０－１～４０－４、１０１　管理サーバ
５０　検証サーバ
２０１、３０１、４０１　通信制御部
２０２　データ管理部
２０３　復号部
２０４　取引実行部
２０５、３０３、４０３　記憶部
３０２　入札データ管理部
３０４　取引検証部
４０２　検証データ生成部

Claims (16)

  1. 　電子掲示板を提供する、複数の管理サーバと、
    　暗号化された価格を含む入札データを前記電子掲示板に書き込む、端末と、
    　前記書き込まれた入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバと、
    　を含む、電子取引システム。
  2. 　未約定な入札データの暗号化された価格と、前記取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバをさらに備える、請求項１の電子取引システム。
  3. 　前記取引サーバは、
    　約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記電子掲示板に書き込む、請求項２の電子取引システム。
  4. 　前記端末は、
    　前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、請求項３の電子取引システム。
  5. 　前記端末は、前記検証サーバに対して、検証対象となる入札データのＩＤを含む検証データ生成要求を送信し、
    　前記検証サーバは、前記検証データ生成要求の受信に応じて前記検証データを生成し、前記生成された検証データを前記電子掲示板に書き込む、請求項４の電子取引システム。
  6. 　前記端末は、
    　前記書き込まれた検証データを取得し、前記検証データに含まれる検証文字列を検証関数に入力し、前記検証関数の出力結果に基づき、前記取引サーバによる前記検証対象の入札データの取引が正当であったか否かを判定する、請求項５の電子取引システム。
  7. 　前記取引サーバの取引の正当性に関する検証は、前記端末が入札データの価格を知ることはできず、且つ、前記取引サーバによる取引の正当性を検証可能とする、零知識証明である、請求項６の電子取引システム。
  8. 　前記検証サーバは、
    　売り入札データが約定しなかったことに関する前記検証データを生成する場合には、
    　未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高いという、第１命題を証明する前記検証文字列を生成する、請求項２乃至７のいずれか一項に記載の電子取引システム。
  9. 　前記検証サーバは、
    　売り入札データが約定したことに関する前記検証データを生成する場合には、
    　約定した買い入札データの買値は未約定な買い入札データの買値最高額である、という第２命題を証明する前記検証文字列と、
    　検証対象とする売り入札データの売値は未約定な買い入札データの買値最高額以下である、という第３命題を証明する前記検証文字列と、を生成する、請求項２乃至８のいずれか一項に記載の電子取引システム。
  10. 　前記検証サーバは、
    　買い入札データが約定しなかったことに関する前記検証データを生成する場合には、
    　未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低いという、第４命題を証明する前記検証文字列を生成する、請求項２乃至９のいずれか一項に記載の電子取引システム。
  11. 　前記検証サーバは、
    　買い入札データが約定したことに関する前記検証データを生成する場合には、
    　約定した売り入札データの売値は未約定な売り入札データの売値最低額である、という第５命題を証明する前記検証文字列と、
    　検証対象とする買い入札データの買値は未約定な売り入札データの売値最低額以上である、という第６命題を証明する前記検証文字列と、を生成する、請求項２乃至１０のいずれか一項に記載の電子取引システム。
  12. 　前記複数の管理サーバは、相互に直接接続され、
    　前記複数の管理サーバのそれぞれが、外部から受信したデータを管理するためのデータ管理台帳を有し、外部の装置からデータを電子掲示板に書き込む旨の要求を取得するたびに、前記データ管理台帳にデータを追記する、請求項１乃至１１のいずれか一項に記載の電子取引システム。
  13. 　端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバ。
  14. 　端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、未約定な入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバ。
  15. 　取引サーバにおいて、
    　端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得するステップと、
    　前記暗号化された価格を復号するステップと、
    　前記復号された価格を用いてザラバ方式により取引を実行するステップと、
    　を含む、電子取引方法。
  16. 　取引サーバに搭載されたコンピュータに、
    　端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得する処理と、
    　前記暗号化された価格を復号する処理と、
    　前記復号された価格を用いてザラバ方式により取引を実行する処理と、
    　を実行させるプログラム。
PCT/JP2018/013481 2018-03-29 2018-03-29 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム WO2019186978A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2018/013481 WO2019186978A1 (ja) 2018-03-29 2018-03-29 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム
JP2020508774A JP7364238B2 (ja) 2018-03-29 2018-03-29 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム
US16/975,555 US20200402171A1 (en) 2018-03-29 2018-03-29 Electronic transaction system, transaction server, verification server, method of transaction, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/013481 WO2019186978A1 (ja) 2018-03-29 2018-03-29 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2019186978A1 true WO2019186978A1 (ja) 2019-10-03

Family

ID=68059589

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/013481 WO2019186978A1 (ja) 2018-03-29 2018-03-29 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム

Country Status (3)

Country Link
US (1) US20200402171A1 (ja)
JP (1) JP7364238B2 (ja)
WO (1) WO2019186978A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020021048A (ja) * 2018-08-03 2020-02-06 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ データ流通方法、認証サーバ及びデータ構造

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7327480B2 (ja) * 2019-06-25 2023-08-16 日本電気株式会社 電子取引システム、取引管理サーバ、電子取引方法及びプログラム
CN115955364B (zh) * 2023-03-13 2023-06-02 长沙市中智信息技术开发有限公司 一种网络竞价交易系统的用户身份信息保密方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001357252A (ja) * 2000-04-04 2001-12-26 Internatl Business Mach Corp <Ibm> セキュア・コプロセッサを使用した安全オークション・マーケット
JP2006196028A (ja) * 1999-07-23 2006-07-27 Toshiba Corp 情報証明方法
WO2007063876A1 (ja) * 2005-12-01 2007-06-07 Nec Corporation 電子入札システムおよび電子入札方法
JP2008020871A (ja) * 2006-07-14 2008-01-31 Hitachi Software Eng Co Ltd 秘密分散情報処理システム
JP2017059872A (ja) * 2015-09-14 2017-03-23 Kddi株式会社 入札システム、入札方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074330A1 (en) * 2001-10-11 2003-04-17 Nokia Corporation Efficient electronic auction schemes with privacy protection
AUPS095702A0 (en) * 2002-03-07 2002-03-28 Ozb2B Pty Ltd System and method for conducting online auctions
US8024274B2 (en) * 2006-05-05 2011-09-20 President And Fellows Of Harvard College Practical secrecy-preserving, verifiably correct and trustworthy auctions
US8843997B1 (en) * 2009-01-02 2014-09-23 Resilient Network Systems, Inc. Resilient trust network services
US8239331B2 (en) * 2009-09-18 2012-08-07 Google Inc. Auction verification
US10740834B2 (en) * 2009-10-12 2020-08-11 Jeffrey Brian Gray System and method for implementing a hybrid marketplace
US8751355B2 (en) * 2010-09-29 2014-06-10 Stephen Edward Rossi System and method for credit enhancing a debt issuance and creating a present value investable arbitrage
US10257173B2 (en) * 2014-10-22 2019-04-09 Openeye Scientific Software, Inc. Secure comparison of information
US11170363B1 (en) * 2016-11-28 2021-11-09 Wells Fargo Bank, N.A. Secure processing of online purchase using a mobile wallet
US10853808B1 (en) * 2016-12-18 2020-12-01 Mark Lawrence Method and apparatus for controlled products
US10861039B2 (en) * 2017-04-12 2020-12-08 Royal Bank Of Canada Bid platform
CN108171494A (zh) * 2017-11-23 2018-06-15 阿里巴巴集团控股有限公司 一种数据处理方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006196028A (ja) * 1999-07-23 2006-07-27 Toshiba Corp 情報証明方法
JP2001357252A (ja) * 2000-04-04 2001-12-26 Internatl Business Mach Corp <Ibm> セキュア・コプロセッサを使用した安全オークション・マーケット
WO2007063876A1 (ja) * 2005-12-01 2007-06-07 Nec Corporation 電子入札システムおよび電子入札方法
JP2008020871A (ja) * 2006-07-14 2008-01-31 Hitachi Software Eng Co Ltd 秘密分散情報処理システム
JP2017059872A (ja) * 2015-09-14 2017-03-23 Kddi株式会社 入札システム、入札方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020021048A (ja) * 2018-08-03 2020-02-06 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ データ流通方法、認証サーバ及びデータ構造
JP7458150B2 (ja) 2018-08-03 2024-03-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ データ流通方法及び認証サーバ

Also Published As

Publication number Publication date
JP7364238B2 (ja) 2023-10-18
JPWO2019186978A1 (ja) 2021-03-11
US20200402171A1 (en) 2020-12-24

Similar Documents

Publication Publication Date Title
CN108781161B (zh) 用于控制和分发数字内容的区块链实现的方法
US20200058023A1 (en) Decentralized Data Marketplace
CN107180350B (zh) 一种基于区块链的多方共享交易元数据的方法、装置及系统
US11232415B2 (en) Method for cryptographically managing title transactions
WO2019105407A1 (zh) 一种适合区块链隐私保护的零知识证明方法和介质
US20170134161A1 (en) Blockchaining for media distribution
CN107145768A (zh) 版权管理方法和系统
US12010236B2 (en) Blockchain-based crowdsourcing
WO2020051710A1 (en) System and process for managing digitized security tokens
US11729000B2 (en) Methods and systems for introducing self-contained intent functionality into decentralized computer networks
KR102074381B1 (ko) 블록체인 기반의 익명 거래 수행 방법, 장치 및 기록 매체
US20230360042A1 (en) Method, system, and computer-readable medium for secured multi-lateral data exchange over a computer network
JP2011154532A (ja) クラウドコンピューティングシステム
Tzianos et al. Hermes: An open and transparent marketplace for IoT sensor data over distributed ledgers
JP7364238B2 (ja) 電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラム
US11870654B2 (en) Methods and systems for introducing self-contained intent functionality into decentralized computer networks
JP2023500260A (ja) 代理相互台帳認証
Baranwal Blockchain based full privacy preserving public procurement
Liu et al. STEB: A secure service trading ecosystem based on blockchain
CN116664298A (zh) 基于区块链的去中心化数据交易系统的实现方法和装置
JP7327480B2 (ja) 電子取引システム、取引管理サーバ、電子取引方法及びプログラム
Shih et al. A secure multi-item e-auction mechanism with bid privacy
US20240013170A1 (en) Method for secure, traceable and privacy-preserving digital currency transfer with anonymity revocation on a distributed ledger
Futoransky et al. Secure exchange of digital goods in a decentralized data marketplace
CN112116414A (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: 18911531

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020508774

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: 18911531

Country of ref document: EP

Kind code of ref document: A1