WO2017010455A1 - 契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム - Google Patents

契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム Download PDF

Info

Publication number
WO2017010455A1
WO2017010455A1 PCT/JP2016/070415 JP2016070415W WO2017010455A1 WO 2017010455 A1 WO2017010455 A1 WO 2017010455A1 JP 2016070415 W JP2016070415 W JP 2016070415W WO 2017010455 A1 WO2017010455 A1 WO 2017010455A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
agreement
transaction
user
block chain
Prior art date
Application number
PCT/JP2016/070415
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 EP16824435.8A priority Critical patent/EP3324355B1/en
Priority to US15/743,523 priority patent/US10848315B2/en
Priority to JP2017528672A priority patent/JP6483827B2/ja
Priority to CN201680041624.5A priority patent/CN107851253B/zh
Publication of WO2017010455A1 publication Critical patent/WO2017010455A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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 involving digital signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3226Cryptographic 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 a predetermined code, e.g. password, passphrase or PIN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present invention relates to a method of agreeing a contract using a block chain mechanism.
  • the present invention relates to a technique for leaving a trail of a contract agreed between related parties.
  • Non-Patent Document 1 a mechanism capable of ensuring reliability without requiring centralized management as described above is spreading mainly in digital virtual currency.
  • blockchain the reliability of the information exchanged is secured by a consensus building process in the network formed by all participants, and fraud such as tampering and double use is prevented throughout the system. Therefore, the soundness is maintained (Non-Patent Document 1).
  • the blockchain functions as a huge ledger that is shared by all participants on a P2P (Peer to Peer) network, in which virtual currency transaction information between participants is collected as a single unit called a block. For example, the transaction “Mr. A handed over three coins to Mr. B” is shared by all. If this blockchain is regarded as a single ledger that records the contents of transactions of all participants, it can be applied to various transactions other than currency.
  • P2P Peer to Peer
  • the block chain is applied as a trail when a contract is exchanged between a plurality of persons.
  • a contract refers to a sales contract, a certificate of transfer, an application form, a license, etc., and is a document showing the contents of a contract exchanged between two or more individuals or institutions. In that case, leaving a trail of how the consensus was formed between the two parties is a public proof when claiming rights.
  • one transaction includes, for example, the hash value of the previous transaction, the address of the remittance source, the address of the remittance destination, the payment amount, and the electronic signature of the remittance source.
  • All participants who share the blockchain with them can publicly confirm the contents of the transaction. Therefore, in order to apply this to the contract agreement trail, a similar effect can be expected by adding information about the contract to the transaction.
  • the above-mentioned address indicates, for example, a hash value of a public key for electronic signature in the block chain technology.
  • the issue is how to prove that the contract contents are agreed between two or more parties.
  • the electronic signature method employed in the virtual currency blockchain is composed only of the electronic signature of the remittance source, and the electronic signature of the remittance destination is not required.
  • a contract is exchanged between two or more parties, a contract is not established when a one-way contract is issued, and it is necessary to agree with all parties involved in the contract.
  • a trail of contract agreement by the receiver does not remain in the transaction.
  • a method of including the digital signatures of all parties involved in one transaction can be considered.
  • the virtual currency employs a mechanism called multi-signature, and an address where a transaction is not approved can be created without a certain number of electronic signatures.
  • multiple electronic signatures per transaction such as which electronic signatures are required in advance, how to share a transaction before approval among related parties, where to collect multiple private keys and sign
  • the procedure for including a signature is cumbersome.
  • the present invention has been made in view of the above circumstances, and maintains a form of one electronic signature in one transaction, and leaves a contract trail on the blockchain in a simple manner while agreeing between the parties concerned.
  • This is the first purpose.
  • the second purpose is to keep a trail of the contract in the blockchain while maintaining the reliability with a simple method while maintaining the form of one electronic signature in one transaction and obtaining an agreement between the parties concerned. To do.
  • the contract agreement method is a contract agreement method performed between a plurality of devices connected to a distributed network sharing a block chain.
  • the gist is to generate a transaction addressed to the device of the issuer who issued the document.
  • the contract agreement method is the contract agreement method according to claim 1, wherein each of the plurality of devices generates an encryption key and a decryption key of the contract,
  • the step of decrypting the contract included in the transaction with the decryption key of the own device, the decrypted contract and the contract to be agreed
  • a step of encrypting the agreement to be agreed using an encryption key of another device and the step of broadcasting includes at least an agreement or non-conformance of the user of the device with respect to the agreement.
  • Generating a transaction addressed to the other device including a proof of agreement, the electronic signature of the user of the device, and the encrypted contract; And summarized in that broadcast to Ttowaku.
  • the contract agreement method according to claim 3 is the contract agreement method according to claim 2, wherein the issuer's device matches the agreement decrypted with its own decryption key and the agreement to be agreed upon.
  • the gist is to verify the identity of contracts to be contracted based on whether or not to do so.
  • the contract agreement method according to claim 4 is the contract agreement method according to any one of claims 1 to 3, wherein the issuer's device is a third proof as a proof of agreement on the contract.
  • the gist is to generate a transaction addressed to a person's device.
  • the contract agreement method according to claim 5 is the contract agreement method according to any one of claims 1 to 4, wherein the network is a P2P network.
  • the agreement verification method according to claim 6 is an agreement verification method for verifying an agreement of a contract made by the contract agreement method according to any one of claims 1 to 5 using an agreement verification device. Based on whether the public key for the electronic signature included in the transaction that is the starting point of the chain matches the public key for the electronic signature of the user of the device that receives the transaction that is the end point of the chain, the trail of the contract agreement The gist is to include a step of determining presence or absence.
  • the contract agreement system wherein the plurality of devices each have an agreement for a contract to be agreed upon, wherein the plurality of devices are connected to a distributed network sharing a block chain.
  • the identifier of the agreement subject to agreement, and the identifier of the agreement included in the transaction and the identifier of the agreement subject to agreement are at least the own device user for the agreement Proof of agreement or non-agreement, the electronic signature of the device user, and the agreement
  • a generation unit that generates a transaction addressed to another device including the identifier of the contract and broadcasts to the network, and a block of the storage unit in a block chain in which the generated transaction is chained to the previous user transaction.
  • a chain update controller wherein the plurality of devices chain user transactions related to the contract
  • the contract agreement system is the contract agreement system according to claim 7, wherein each of the plurality of devices includes a generation unit that generates an encryption key and a decryption key of the contract, and a block chain.
  • the decryption unit for decrypting the contract included in the transaction with the decryption key of the own device, the decrypted contract, and the agreement target An encryption unit that encrypts the agreement to be agreed using an encryption key of another device, and the generation unit that broadcasts at least the self-contract for the agreement.
  • Generating a transaction addressed to the other device including a proof of agreement or non-agreement of the device user, the electronic signature of the device user, and the encrypted contract; And summarized in that the broadcast network.
  • the contract agreement system according to claim 9 is the contract agreement system according to claim 8, wherein the issuer's device matches the agreement decrypted with its own decryption key and the agreement to be agreed upon.
  • the gist is to verify the identity of contracts to be contracted based on whether or not to do so.
  • the contract agreement system according to claim 10 is the contract agreement system according to any one of claims 7 to 9, wherein the issuer's device is a third proof as a proof of agreement on the contract.
  • the gist is to generate a transaction addressed to a person's device.
  • the contract agreement system according to claim 11 is the contract agreement system according to any one of claims 7 to 10, wherein the network is a P2P network.
  • the agreement verification apparatus is included in a transaction that is a starting point of a chain in the agreement verification apparatus that verifies the agreement of the contract performed by the contract agreement system according to any one of claims 7 to 11.
  • a verification unit that determines whether or not a contract agreement trail exists based on whether or not the electronic signature public key matches the electronic signature public key of the user of the device that receives the transaction at the end of the chain Is the gist.
  • a transaction indicating a consensus trail for a contract to be agreed is chained as a block chain.
  • collation comparing the contract identifier included in the transaction with the contract target identifier
  • the contract identifier included in the transaction and the identifier of the contract to be agreed agree with, at least, a proof of agreement or non-agreement of the user of the device with respect to the contract, and the user of the device
  • a traffic addressed to another contract agreement device including an electronic signature and an identifier of the agreement to be agreed.
  • a generation unit that generates a transaction and broadcasts it to the network; and a control unit that updates the block chain of the storage unit with a block chain in which the generated transaction is chained to the previous user's transaction.
  • the contract agreement apparatus is the contract agreement apparatus according to claim 13, wherein a generation unit that generates an encryption key and a decryption key of the contract and a previous user last chained to the block chain When the transaction is addressed to the own device, the decryption unit that decrypts the contract included in the transaction with the decryption key of the own device, and the decrypted contract and the agreement to be agreed upon match An encryption unit that encrypts the contract to be agreed using an encryption key of another contract agreement apparatus, and the generation unit that broadcasts at least the agreement or non-conformance of the user of the apparatus with respect to the contract Generate a transaction addressed to the other contract agreement device including the proof of agreement, the electronic signature of the user of the device, and the encrypted contract, and send it to the network And it is required to load cast.
  • the agreement verification apparatus is an agreement verification apparatus for verifying an agreement of a contract performed by the contract agreement apparatus according to claim 13 or 14, wherein the agreement verification apparatus includes an electronic signature included in a transaction that is a starting point of a chain. And a verification unit that determines whether there is a trail of a contract agreement based on whether the public key for the electronic signature of the user of the user of the device that receives the transaction at the end of the chain matches the public key To do.
  • the gist of the contract agreement program according to claim 16 is to cause a computer to execute the contract agreement method according to any one of claims 1 to 5.
  • the gist of the agreement verification program according to claim 17 is to cause a computer to execute the agreement verification method according to claim 6.
  • the present invention it is possible to leave a trail of a contract on the block chain by a simple method while maintaining a form of one electronic signature for one transaction and obtaining an agreement between the parties concerned.
  • the contract trail is left in the blockchain while maintaining the reliability in a simple manner while agreeing between the parties concerned. Can do.
  • the existing blockchain technology is used as a trail of contract agreement. Specifically, for a transaction of an issued contract, the receiver generates a transaction including consensus for the contract and links it. Then, after the transaction is chained among all parties concerned, the last transaction is returned to the contract issuer and the chain is closed. Furthermore, the issuer of the contract generates a transaction addressed to a third party address so that the non-related parties can prove and guarantee that the agreement has been reached by all the related parties. As a result, it is possible to leave a trail of contract agreement while maintaining the same form of one electronic signature per transaction as in the prior art.
  • the total number of parties involved in the contract is, for example, three, the contract issuer who intends to enter the contract and leave a trail of the contract agreement, and the person who received the request agrees to the contract I will be a person.
  • an intermediary is set as a person who guarantees a contract agreement made by all parties concerned.
  • the mediator is a person corresponding to the third party described above. For example, a person who is not directly related to the contract, such as a service provider of the contract agreement system or a guarantee organization of the contract agreement, is preferable.
  • the contract agreement system 100 includes an issuer-side terminal 1 used by a contract issuer, two agreement-side terminals 3a, 3b used by two agreement parties, and an intermediary. And an intermediary-side terminal 5 used by the company. All terminals are connected in an autonomous and distributed manner by a P2P network 50 sharing a block chain.
  • Each terminal is provided with a plurality of common functional units, and includes a block chain storage unit 11, a block chain control unit 12, and a transaction generation unit 13. Other functional units will be described later.
  • the block chain storage unit 11 has a function of storing a block chain.
  • a block chain refers to a transaction chained as a block that shows a trail of consensus on a contract to be agreed.
  • the block chain control unit 12 has a function of always holding the latest block chain in the block chain storage unit 11 in cooperation with the block chain control unit of another terminal in an autonomous and distributed manner. Further, it also has a function of acquiring a block chain from the block chain storage unit 11 and providing it to the transaction generation unit 13.
  • the transaction generation unit 13 has a function of generating a transaction related to the own terminal user and broadcasting it to the P2P network 50 when the validity of the previous user transaction is confirmed.
  • one transaction includes the hash value of the previous transaction, the sender address, the recipient address, the payment amount, and the sender's electronic signature.
  • the transaction used in the present embodiment refers to evidence data of a contract agreement that further includes information on the agreement to be agreed and information on the agreement of the parties to the agreement, and the sender's electronic signature is given. Accordingly, it is possible to record the presence or absence of the agreement of the parties with respect to the contract while maintaining the same form as the conventional one of one electronic signature per transaction.
  • FIG. 3 illustrates an operation in which a sender generates a transaction, and after a blockchain approval operation is performed, a receiver confirms the transaction. This operation is used not only for the present embodiment but also for virtual currency transactions using a block chain.
  • the sender's terminal generates a transaction with an electronic signature specifying that the sender's address is addressed to the recipient's address (step S101), and broadcasts it on the P2P network (step S102).
  • the approval terminal on the P2P network collects the transactions broadcast on the network, and performs the approval work collectively in units of blocks (step S103).
  • the approval work in virtual currency, a method of performing a complicated hash calculation called proof of work, a method of consuming coin years called proof of stake, and the like have been proposed.
  • proof of work a method of performing a complicated hash calculation
  • proof of stake a method of consuming coin years
  • proof of stake a method of consuming coin years
  • step S104 when the receiver's terminal finds a transaction embedded in the block chain (step S104), as shown in FIG. 4, the sender's public key is used to verify the electronic signature of the transaction and the hash value By performing collation or the like, it is verified that the previous transaction has been delivered from a valid sender (step S105).
  • This verification method can be implemented by a known technique and is described in Non-Patent Document 1, for example.
  • the receiver terminal When the validity of the sender of the transaction is confirmed, the receiver terminal generates a transaction for the next partner with reference to the transaction (step S106). This “recipient” becomes the “sender” in step S101.
  • the operation of the contract agreement system 100 will be described with reference to FIG. It is assumed that all terminals receive a transaction through an approval operation at the approval terminal, and the latest block chain is always stored. Further, the parties other than the intermediary have the same electronic contract to be agreed in advance, and the contract is hashed and the hash value is held in advance in the terminal.
  • the hashing of the contract has the purpose of preventing tampering in the middle and the purpose of concealing the contents of the contract from a third party, but it is sufficient that the contract contents indicated by the transaction can be compared with the contract to be agreed. Therefore, the contract ID may be used instead.
  • a contract is created by leaving a series of flows: "Start transaction chaining from the issuer, generate transactions among the parties involved, chain contract transactions, and finally return to the issuer.”
  • a trail of agreement The contents of the generated transaction are as shown in FIG. 2, and the agreement history between the parties can be traced from the hash value of the previous transaction.
  • an intermediary provides a previous transaction necessary for an issuer to generate a transaction.
  • the broker side terminal 5 generates a transaction addressed to the issuer (step S201). As described above, this transaction is broadcast on the P2P network, collected, approved, and chained by the approval terminal, and synchronized with other terminals. This process is performed every time a transaction is broadcast. Hereinafter, the description thereof is omitted.
  • the issuer-side terminal 1 refers to the transaction from the intermediary and generates a transaction addressed to the agreeer A from the issuer including the hash value of the contract (Step S202). At this time, an agreement state indicated by a Boolean value or a specific value is also included in the transaction.
  • the contractor side terminal 3a extracts a transaction addressed to itself from the latest block chain, and confirms whether the hash value of the contract included in the transaction matches the hash value of the contract held by the terminal ( Step S203).
  • the contractor side terminal 3a subsequently verifies the electronic signature and recalculates the hash value of the transaction as proof that the contract has been agreed, and the hash of the contract A transaction addressed to another contractor B including the value and the state of the agreement is generated (step S204).
  • the contractor B performs the same contract confirmation work as the contractor A (step S205), and generates a transaction addressed to the original issuer as a trail in which the agreement is confirmed (step S206). . If there are other contractors, the hash value of the contract document and transaction generation are similarly performed with the contractors to further chain the transactions.
  • the issuer-side terminal 1 also verifies the hash value of the contract document in the issuer-side terminal 1 to confirm that the agreement has been agreed among all the parties concerned (step S207). ).
  • the issuer-side terminal 1 generates a transaction addressed to the mediator as a proof that the agreement of the target contract has been obtained (step S208).
  • the purpose of this is to ensure that the issuer that is the starting point confirms the agreement of the relevant contract, and that no further transactions are linked between the parties due to renewal of the agreement.
  • transition pattern of the transaction destination will be described.
  • Various transition patterns are conceivable.
  • the transition pattern of FIG. 5 the transition pattern of FIG.
  • transition patterns such as (A) or (C) in FIG. (A) indicates that the initial transaction received by the issuer is not a transaction received from an intermediary, but a transaction generated as a reward for approval work or the like.
  • a third party on the P2P network collects transactions and connects new blockchains to approve transactions and receive new coins (transactions) as rewards (so-called “mining”)
  • a transition pattern is assumed.
  • (C) shows a case where the topology of consensus building is a more complicated state.
  • the input (sender) and output (receiver) can be designated as N: N. That is, a transaction can be branched and output, or a plurality of inputs can be added together and combined into one output. Therefore, it is possible to set up consensus formation for complex routes as shown in (c), so that the end of the chain of transactions finally returns to the issuer even if there is a branch in the middle. By doing so, it is possible to prove the agreement between the parties concerned.
  • the end of the transaction chain must be the issuer, and the issuer must designate the transaction as a designated third party ( By passing it to an intermediary), it is possible to leave a trail of consensus on the contract between the parties on the P2P network.
  • the contract agreement device 7 is a device used by an intermediary, an issuer, and a contractor, and includes a block chain storage unit 11, a block chain control unit 12, a contract verification unit 14, a destination setting unit 15, and a transaction generation.
  • the unit 13 and the data holding unit 16 are provided.
  • the data holding unit 16 has a function of holding various data necessary for generating a transaction.
  • Each device has a unique address, and holds, for example, a hash value of a public key paired with a private key necessary for an electronic signature, as in the virtual currency mechanism.
  • the contract ID for identifying the contract to be agreed is held.
  • the hash value of the contract is used to make it a value that can be collated with the corresponding contract.
  • the contract route is held. In the contract route, the addresses of the issuer, the agreeer, and the mediator are described, and the destination of the transaction for realizing the route of the selected transition pattern is described.
  • the block chain storage unit 11 has a function of storing a block chain approved by an approval terminal, chained to the previous block chain, and further synchronized with another device.
  • the block chain control unit 12 cooperates with the block chain control unit of other devices in an autonomous and distributed manner to always hold the latest block chain in the block chain storage unit 11, that is, the existing chained latest block chain. It has a synchronization function to update the blockchain. Further, it has a function of acquiring a block chain from the block chain storage unit 11 and referring to a transaction addressed to the address of the own device.
  • the contract verification unit 14 compares the contract ID included in the transaction with the contract ID of the data holding unit 16 and compares the two contract documents. A function is provided for comparing whether the IDs match.
  • the destination setting unit 15 has a function of specifying the destination of the next transaction with reference to the contract route and address of the data holding unit 16 and transmitting the destination to the transaction generation unit 13.
  • the transaction generation unit 13 uses the destination transmitted from the destination setting unit 15 and includes the contract ID, the presence / absence of agreement, the electronic signature of the agreement party, etc. It has a function of generating a transaction of its own device consensus and broadcasting it to a P2P network.
  • the block chain control unit 12 receives the block chain after chaining and updates the block chain in the block chain storage unit 11 ( Step S301).
  • the block chain control unit 12 acquires the latest updated block chain from the block chain storage unit 11, and refers to the previous user transaction (step S302).
  • the contract verification unit 14 compares the contract ID included in the transaction with the contract ID of the data holding unit 16 (step S303). .
  • the destination setting unit 15 refers to the contract route and address of the data holding unit 16 and specifies the destination of the next transaction (step S304).
  • the transaction generation unit 13 generates a transaction including the contract ID, the presence / absence of agreement by the own device contractor, the electronic signature of the contractor using the specified destination, and broadcasts it to the P2P network. (Step S305).
  • each contractor or the like has a contract agreement apparatus 7 having such a function, and the transactions of each party are chained among those parties. Generate a transaction addressed to the issuer's contract agreement device.
  • the user of the contract agreement system 100 simply sets the address, the contract route, the contract document ID, the presence / absence of agreement, the electronic signature, etc. in the contract agreement device, and the trail of the contract agreement on the blockchain (on the P2P network) ).
  • the contract agreement trail left on the blockchain can be easily verified from any terminal or device on the P2P network as long as the blockchain system exists. Therefore, an agreement verification apparatus used for verifying the agreement later will be described.
  • the agreement verification apparatus 9 includes a data holding unit 91, a block chain storage unit 92, a block chain control unit 93, and an agreement verification unit 94.
  • the other functional units other than the agreement verification unit 94 have the same functions as the functional units having the same name that the contract agreement apparatus 7 has.
  • the block chain control unit 93 acquires the contract ID to be verified from the data holding unit 91, and takes out the corresponding transaction chain from the block chain storage unit 92 (step S401).
  • the agreement verification unit 94 compares the address included in the transaction that is the starting point of the extracted transaction chain with the address that receives the transaction at the end of the chain, and determines whether there is an agreement trail based on the comparison result. (Step S402). By confirming that the last transaction has been sent to the address of the designated intermediary, the trail of the contract agreement can be verified.
  • the agreement verification unit 94 displays that a trail of the contract agreement exists as a verification result (step S403).
  • the contents of the parameters included in the transaction may be displayed together. For example, as shown in FIG. 2, when the state of the agreement is returned to the issuer with false (non-agreement), the agreementr A also displays that the agreement has not been made.
  • the transactions of the parties concerned are chained between the contract agreement devices of the parties involved in the contract of the contract, and the last device is connected to the issuer's device that issued the contract. Since the transaction is generated to the destination, the trail of the contract agreement between the two parties can be recorded on the block chain by a simpler method without performing a complicated procedure. Also, in this embodiment, since the agreement trail of the contract is maintained on the autonomous decentralized network without using a centralized mechanism, even if the agreement trail is lost in some devices, As long as there is a blockchain system in place, the trail can be kept permanently.
  • the hash value of the public key of the sender and the receiver has been described as an example of the address of the sender and the receiver.
  • An arbitrary value may be used instead of the hash value.
  • the P2P network has been described as an example. However, it is not always necessary to use a network composed of literally pure peer-to-peer. In recent Bitcoin, there are also nodes that serve as hubs, for example, and it may be a distributed network that shares a block chain.
  • the contract agreement apparatus 7 and the agreement verification apparatus 9 described in the present embodiment can be realized by a computer having a calculation function such as a CPU and a storage function such as a memory. It is also possible to create a program for causing a computer to function as each of these devices and a storage medium for the program.
  • a cryptographic key pair for the contract is used separately from the electronic signature key pair at each terminal of the parties concerned.
  • the transaction receiver sends the encryption key of the key pair to the transaction sender in advance for public use.
  • the sender encrypts the contract using the encryption key sent from the receiver, and generates a transaction addressed to the receiver including the encrypted contract.
  • the recipient decrypts the encrypted contract with the other decryption key it has.
  • the first issuer encrypts the contract and the recipient decrypts it, and when the recipient sends it, it encrypts with the next recipient's encryption key, and by repeating this, only the parties involved in the transaction chain Keep an encrypted contract that can be decrypted.
  • each transaction includes a contract encrypted with a different encryption key by each party, so that a trail of the contract can be left in the blockchain while maintaining reliability.
  • the contract agreement system 100 includes an issuer-side terminal 1 used by a contract issuer, two agreement-side terminals 3a and 3b used by two agreement parties, And an intermediary terminal 5 used by the intermediary. All terminals are connected in an autonomous and distributed manner by a P2P network 50 sharing a block chain.
  • Each terminal is provided with a plurality of common functional units, and includes a block chain storage unit 11, a block chain control unit 12, a transaction generation unit 13, and a contract encryption unit 17. Other functional units will be described later.
  • the block chain storage unit 11 has a function of storing a block chain.
  • a block chain refers to a transaction chained as a block that shows a trail of consensus on a contract to be agreed.
  • the block chain control unit 12 has a function of always holding the latest block chain in the block chain storage unit 11 in cooperation with the block chain control unit of another terminal in an autonomous and distributed manner. Further, it also has a function of acquiring a block chain from the block chain storage unit 11 and providing it to the transaction generation unit 13 or the contract encryption unit 17.
  • the transaction generation unit 13 has a function of generating a transaction related to the own terminal user and broadcasting it to the P2P network 50 when the validity of the previous user transaction is confirmed.
  • the contract encryption unit 17 has a function of generating a key pair composed of a pair of encryption key and decryption key, and transmitting the encryption key to another terminal for public use. Also, it has a function of encrypting a contract (contract document) using an encryption key transmitted from another terminal.
  • the transaction is described in detail.
  • the contract to be agreed is specified, the consensus of the parties concerned with the contract is recorded, and the contents of the contract are concealed.
  • FIG. Encrypted the transaction used in the present embodiment includes an encrypted agreement to be agreed and information on the agreement of the parties concerned with the agreement, and evidence of the agreement with the sender's electronic signature. Refers to data. Accordingly, it is possible to record the presence or absence of the agreement of the parties with respect to the contract while maintaining the same form as the conventional one of one electronic signature per transaction. Further, by encrypting the contract, the contract content can be held in a highly reliable state.
  • the issuer-side terminal 1, the agreeer-side terminal 3a, and the agreeer-side terminal 3b each generate a key pair for encrypting a contract to be agreed (step S501).
  • each of these terminals stores a decryption key in the generated key pair and sends the paired encryption key to the sender of the transaction (step S502).
  • the sending route and sending method are arbitrary. It is not always necessary to use a block chain or a P2P network, and notification may be made by mail or verbal communication via the Internet or a telephone line.
  • the order of sending the encryption keys between the terminals is also arbitrary.
  • each of these terminals holds the encryption key sent from the transaction receiver. Then, the issuer side terminal 1 that is the issuer of the contract encrypts the contract to be agreed using the encryption key from the agreement side terminal 3a (step S503).
  • a contract is created by leaving a series of flows: "Start transaction chaining from the issuer, generate transactions among the parties involved, chain contract transactions, and finally return to the issuer.”
  • a trail of agreement The contents of the generated transaction are as shown in FIG. 11, and the history of agreement between the parties can be traced from the hash value of the previous transaction.
  • an intermediary provides a previous transaction necessary for an issuer to generate a transaction.
  • the broker side terminal 5 generates a transaction addressed to the issuer (step S601). As described in the first embodiment, this transaction is broadcast on the P2P network, collected, approved, and chained by the approval terminal and synchronized with other terminals. This process is performed every time a transaction is broadcast. Hereinafter, the description thereof is omitted.
  • issuer side terminal 1 refers to the transaction from the intermediary and generates a transaction addressed to issuer A from the issuer including the contract encrypted with the encryption key of agreement A (step). S602). At this time, an agreement state indicated by a Boolean value or a specific value is also included in the transaction.
  • the contractor side terminal 3a extracts the transaction addressed to itself from the latest block chain, decrypts the encrypted contract included in the transaction with its own decryption key, and holds the contract stored by itself. To confirm the identity of the contract (step S603).
  • the contractor side terminal 3a subsequently encrypts the contract again using the contractor B's encryption key (step S604).
  • the contractor side terminal 3a verifies the electronic signature as a proof that the contract is agreed, recalculates the hash value of the transaction, and includes the contract and the state of the agreement encrypted with the encryption key of the contractor B Then, a transaction addressed to the consensus B is generated (step S605).
  • the contractor B decrypts the contract included in the transaction of the contractor A by using its own decryption key, and performs the contract confirmation work (step S606).
  • the corresponding contract is re-encrypted using the encryption key of the subscriber (step S607), and a transaction addressed to the original issuer is generated as a trail that the agreement has been confirmed (step S608). If there is another contractor, the contract is collated with the contractor and a transaction is generated, and the transaction is further chained.
  • the issuer-side terminal 1 also uses the decryption key of the issuer-side terminal 1 to decrypt the contract included in the transaction of the contractor B, and performs the confirmation of the contract. It is confirmed that the agreement has been agreed among all the parties concerned (step S609).
  • the issuer can notice that the contract is falsified somewhere in the path.
  • the hash value of the contract document is stored at the time of the first issuance, and compared with the hash value of the contract document included in the transaction from the contractor B. It is conceivable to verify the identity of the contract based on whether or not.
  • the issuer terminal 1 generates a transaction addressed to the intermediary as proof that the agreement of the target contract can be obtained and that the contract has not been tampered with (step S610).
  • the purpose of this is to ensure that the issuer that is the starting point confirms the agreement of the relevant contract, and that no further transactions are linked between the parties due to renewal of the agreement. Also, since the encrypted contracts included in each transaction are encrypted with different keys, are they agreed to the same document even if a third party later confirmed the agreement? Can not be confirmed. Therefore, it is necessary to leave a proof that the issuer who has received the transaction at the end confirms whether or not tampering has occurred, and this corresponds to the transaction addressed to the broker.
  • transition pattern of the transaction destination is the same as the transition pattern described in the first embodiment, and a description thereof is omitted here.
  • the end of the transaction chain must be the issuer, and the issuer must designate the transaction as a designated third party ( By passing it to an intermediary), it is possible to leave a trail of consensus on the contract between the parties on the P2P network. Further, by encrypting the contract, the contract content can be held in a highly reliable state.
  • the contract agreement device 7 is a device used by an intermediary, an issuer, and a contractor, and includes a block chain storage unit 11, a block chain control unit 12, a contract decryption unit 18, a contract verification unit 14, and a contract.
  • the encryption unit 17, the destination setting unit 15, the transaction generation unit 13, the contract key pair generation unit 19, and the data holding unit 16 are configured.
  • the data holding unit 16 has a function of holding various data necessary for generating a transaction.
  • Each device has a unique address, and holds, for example, a hash value of a public key paired with a private key necessary for an electronic signature, as in the virtual currency mechanism.
  • the contract route is held. In the contract route, the addresses of the issuer, the agreeer, and the mediator are described, and the destination of the transaction for realizing the route of the selected transition pattern is described. Furthermore, a contract key pair for encrypting the contract is held.
  • the block chain storage unit 11 has a function of storing a block chain approved by an approval terminal, chained to the previous block chain, and further synchronized with another device.
  • the block chain control unit 12 cooperates with the block chain control unit of other devices in an autonomous and distributed manner to always hold the latest block chain in the block chain storage unit 11, that is, the existing chained latest block chain. It has a synchronization function to update the blockchain. Further, it has a function of acquiring a block chain from the block chain storage unit 11 and referring to a transaction addressed to the address of the own device.
  • the contract decryption unit 18 has a function of decrypting a contract included in the transaction with the decryption key of the data holding unit 16 when the last chained user's transaction is addressed to the own device.
  • the contract verification unit 14 has a function of comparing the decrypted contract document with the contract document held by itself and comparing whether the two contract documents match.
  • the contract encryption unit 17 has a function of encrypting a contract using an encryption key transmitted from another device when two contracts to be compared match.
  • the destination setting unit 15 has a function of specifying the destination of the next transaction with reference to the contract route and address of the data holding unit 16 and transmitting the destination to the transaction generation unit 13.
  • the transaction generation unit 13 generates a transaction of the device agreement party including the encrypted contract, the presence / absence of the agreement, the electronic signature of the agreement party, and the like using the destination transmitted from the destination setting unit 15, and the P2P network It has a function to broadcast to.
  • the contract key pair generation unit 19 has a function of generating a contract key pair composed of a pair of encryption key and decryption key, storing the contract key pair in the data holding unit 16, and transmitting only the encryption key to another device for public use. I have. As described above, this function may be provided in the contract encryption unit 17.
  • the block chain control unit 12 receives the block chain after chaining and updates the block chain in the block chain storage unit 11 ( Step S701).
  • the block chain control unit 12 acquires the latest updated block chain from the block chain storage unit 11 and refers to the previous user transaction (step S702).
  • the contract decryption unit 18 decrypts the contract included in the transaction with its own decryption key held in the data holding unit 16 when the last chained user's transaction is addressed to its own device. (Step S703).
  • the contract verification unit 14 compares the decrypted contract with the contract held by itself (step S704).
  • the user himself / herself may visually confirm these contracts, or may acquire a hash value of a contract confirmed in advance and collate using the hash value or the like.
  • the contract encryption unit 17 encrypts the corresponding contract again using the encryption key transmitted from the other device (step S705).
  • the destination setting unit 15 identifies the destination of the next transaction with reference to the contract route and address of the data holding unit 16 (step S706).
  • the transaction generation unit 13 generates a transaction including the re-encrypted contract, the presence / absence of agreement by the own device contractor, the electronic signature of the contractor, etc. using the specified destination, and P2P Broadcast to the network (step S707).
  • each contractor or the like has a contract agreement apparatus 7 having such a function, and the transactions of each party are chained among those parties. Generate a transaction addressed to the issuer's contract agreement device. Also, the contract contained in the transaction is encrypted using the receiver's encryption key. As a result, the user of the contract agreement system 100 simply sets the address, the contract route, the contract, the key pair for the contract, the presence / absence of the agreement, the electronic signature, etc. in the contract agreement device, and the trail of the contract agreement is blocked. It can remain on top (on the P2P network) while maintaining reliability.
  • the contract agreement trail left on the blockchain can be easily verified from any terminal or device on the P2P network as long as the blockchain system exists. Therefore, an agreement verification apparatus used for verifying the agreement later will be described.
  • the agreement verification device 9 includes a data holding unit 91, a block chain storage unit 92, a block chain control unit 93, and an agreement verification unit 94 also in the present embodiment. Composed.
  • the other functional units other than the data holding unit 91 and the agreement verification unit 94 have the same functions as the functional units having the same name that the contract agreement apparatus 7 has.
  • the data holding unit 91 holds a contract ID for identifying a contract.
  • the hash value of the contract is used to make it a value that can be collated with the corresponding contract.
  • the block chain control unit 93 acquires the contract ID to be verified from the data holding unit 91, and takes out the corresponding transaction chain from the block chain storage unit 92 (step S801).
  • the agreement verification unit 94 compares the address included in the transaction that is the starting point of the extracted transaction chain with the address that receives the transaction at the end of the chain, and determines whether there is an agreement trail based on the comparison result. (Step S802). By confirming that the last transaction has been sent to the address of the designated intermediary, the trail of the contract agreement can be verified.
  • the agreement verification unit 94 displays that a contract agreement trail exists as a verification result (step S803).
  • the contents of the parameters included in the transaction may be displayed together. For example, as shown in FIG. 11, when the state of the agreement is returned to the issuer with “false” (non-agreement), the agreementr A also displays that the agreement is not made.
  • the transactions of the parties concerned are chained between the contract agreement devices of the parties involved in the contract of the contract, and the last device is connected to the issuer's device that issued the contract. Since the transaction is generated to the destination, the trail of the contract agreement between the two parties can be recorded on the block chain by a simpler method without performing a complicated procedure. Also, in this embodiment, since the agreement trail of the contract is maintained on the autonomous decentralized network without using a centralized mechanism, even if the agreement trail is lost in some devices, As long as there is a blockchain system in place, the trail can be kept permanently.
  • the contract is encrypted and held on the block chain, so even if the contents of the contract are not held in each terminal, it is received as long as it holds the decryption key.
  • the hash value of the public key of the sender and the receiver has been described as an example of the address of the sender and the receiver.
  • An arbitrary value may be used instead of the hash value.
  • the P2P network has been described as an example. However, it is not always necessary to use a network composed of literally pure peer-to-peer. In recent Bitcoin, there are also nodes that serve as hubs, for example, and it may be a distributed network that shares a block chain.
  • the contract agreement apparatus 7 and the agreement verification apparatus 9 described in the present embodiment can be realized by a computer having a calculation function such as a CPU and a storage function such as a memory. It is also possible to create a program for causing a computer to function as each of these devices and a storage medium for the program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Software Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに残す。また、1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに信頼性を保持しながら残す。契約合意に関わる発行者側端末1、合意者側端末3a及び合意者側端末3bの各トランザクションを連鎖させ、最後の合意者側端末3bは、契約発行元の発行者側端末1に宛ててトランザクションを生成する。また、それら各端末は、契約書を暗号化するための鍵ペアを予め生成してその暗号化鍵をトランザクションの送り手の端末に送付しておき、その送り手の端末は、自端末ユーザのトランザクションに含める契約書を該受け手の暗号化鍵を用いて暗号化する。

Description

契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム
 本発明は、ブロックチェーンの仕組みを用いて契約を合意する方法に関する。特に、本発明は、関係者間で合意した契約の証跡を残す技術に関する。
 情報の発信元を保証するための技術として電子署名がある。電子署名を実現するための仕組みとして、現在最も普及しているのは公開鍵暗号方式に基づくものである。また、電子署名された情報において、用いられた電子鍵が確かに情報発信者のものであることを示すためには、通常、信頼できる第三者機関を利用することになる。信頼できる第三者機関が中央集権的な管理を行うことにより、個人と利用する鍵の情報が紐づけられることで信頼性が担保される。
 一方で、上記の様に中央集権的な管理を必要とせずに、信頼性を担保可能な仕組みがデジタル仮想通貨を中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みでは、やり取りされる情報の信頼性を参加者全体で形成されるネットワーク内での合意形成のプロセスによって担保し、かつ、改ざんや二重使用等の不正を系全体で防ぐことにより、健全性を保持している(非特許文献1)。
斉藤、"ビットコイン-人間不在のデジタル巨石貨幣"、WIDE Technical-Report in 2013、WIDE Project、2013年12月31日
 ブロックチェーンは、参加者間の仮想通貨の取引情報がトランザクションとしてブロックという1つの単位でまとめられ、P2P(Peer to Peer)ネットワークにて参加者全員に共有される一つの巨大な元帳として機能する。例えば、「AさんはBさんに3枚のコインを渡した。」というトランザクションが全員で共有される。このブロックチェーンを参加者全ての取引の内容を記録した一つの元帳と捉えると、通貨以外の様々な取引に応用することができる。
 そこで、本発明では、そのブロックチェーンを複数者間で契約書を交わす際の証跡として応用する。契約書とは、売買契約、譲渡証、申込書、許諾書等を指し、二者間以上の個人又は機関で交わされる契約の内容を示した文書である。その際、二者間以上での合意形成がどのように行われたのかを証跡として残しておくことは、権利を主張する際の公的な証明となる。
 ここで、前述した仮想通貨の場合、1つのトランザクションには、例えば、一つ前のトランザクションのハッシュ値、送金元のアドレス、送金先のアドレス、支払い額及び送金元の電子署名が含められており、それらによってブロックチェーンを共有する全ての参加者は取引の内容を公的に確認することができる。それゆえ、これを契約合意の証跡に応用するため、契約に関する情報をトランザクションに追加しておくことで同様の効果が期待される。なお、前述のアドレスとは、例えば、ブロックチェーン技術において電子署名用の公開鍵のハッシュ値を指す。
 しかし、仮想通貨としてのブロックチェーンを契約合意の証跡に応用する場合、契約内容が二者間以上で合意されたことをどのように証明するかといった点が課題となる。仮想通貨のブロックチェーンに採用されている電子署名方式は、前述の通り送金元の電子署名のみによって成り立っており、送金先の電子署名は必要とされていない。一方、二者間以上において契約書を交わす場合、一方的な契約の発行では契約は成り立たず、必ず契約当事者である全ての関係者の合意が必要となる。しかし、ブロックチェーンを形成する1つのトランザクションには送り手の電子署名しか含まれていないため、受け手による契約合意の証跡は該トランザクションに残らないことになる。
 その課題に対する単純な解決方法として、例えば、全ての関係者の電子署名を1つのトランザクションに含める方法が考えられる。仮想通貨にはマルチシグネチャという仕組みが採用されており、一定数以上の電子署名がなければトランザクションが承認されないアドレスを作成することができる。しかし、事前にどの電子署名を必要とするのか、承認前のトランザクションを関係者間でどのように共有するのか、複数の秘密鍵をどこに集めて署名を行うのか等、1つのトランザクションに複数の電子署名を含める手続きは煩雑である。
 また、契約に関する情報をトランザクションに追加した場合、その契約の内容が第三者に読み取られるという課題もある。これは、トランザクションに含まれる契約取引の内容が公開されており、関係者以外にも容易に読み取られる状況にあるからである。
 その2つめの課題に対する単純な解決方法として、例えば、契約内容を共通鍵で暗号化することも考えられる。しかし、関係者数が増えるほど共通鍵の受け渡しによる鍵の流出リスクは高まることになる。つまり、ブロックチェーン上に保持された契約情報のセキュリティを高めつつ関係者だけが読み取れる仕組みを構築することは容易ではない。
 本発明は、上記事情を鑑みてなされたものであり、1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに残すことを第1の目的とする。また、1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに信頼性を保持しながら残すことを第2の目的とする。
 以上の課題を解決するため、請求項1に記載の契約合意方法は、ブロックチェーンを共有する分散型のネットワークに接続された複数の装置間で行う契約合意方法において、前記複数の装置は、それぞれ、合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶部に記憶するステップと、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較するステップと、前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストするステップと、前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新するステップと、を備え、前記複数の装置は、前記契約書の契約に関わるユーザのトランザクションを連鎖させ、前記連鎖を行う最後の装置は、前記契約書を発行した発行者の装置に宛ててトランザクションを生成することを要旨とする。
 請求項2に記載の契約合意方法は、請求項1に記載の契約合意方法において、前記複数の装置は、それぞれ、前記契約書の暗号鍵及び復号鍵を生成するステップと、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化するステップと、前記復号化された契約書と前記合意対象の契約書とが一致する場合、他装置の暗号鍵を用いて前記合意対象の契約書を暗号化するステップと、を更に備え、前記ブロードキャストするステップでは、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを要旨とする。
 請求項3に記載の契約合意方法は、請求項2に記載の契約合意方法において、前記発行者の装置は、自装置の復号鍵で復号化した契約書と前記合意対象の契約書とが一致するか否かに基づき、契約すべき契約書の同一性を照合することを要旨とする。
 請求項4に記載の契約合意方法は、請求項1乃至3のいずれかに記載の契約合意方法において、前記発行者の装置は、前記契約書に対する合意性の証跡が取れた証明として、第三者の装置に宛ててトランザクションを生成することを要旨とする。
 請求項5に記載の契約合意方法は、請求項1乃至4のいずれかに記載の契約合意方法において、前記ネットワークは、P2Pネットワークであることを要旨とする。
 請求項6に記載の合意検証方法は、請求項1乃至5のいずれかに記載された契約合意方法で行われた契約の合意を合意検証装置で検証する合意検証方法において、前記合意検証装置は、連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定するステップ、を備えることを要旨とする。
 請求項7に記載の契約合意システムは、ブロックチェーンを共有する分散型のネットワークに接続された複数の装置を備えた契約合意システムにおいて、前記複数の装置は、それぞれ、合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶する記憶部と、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較する照合部と、前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストする生成部と、前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新する制御部と、を備え、前記複数の装置は、前記契約書の契約に関わるユーザのトランザクションを連鎖させ、前記連鎖を行う最後の装置は、前記契約書を発行した発行者の装置に宛ててトランザクションを生成することを要旨とする。
 請求項8に記載の契約合意システムは、請求項7に記載の契約合意システムにおいて、前記複数の装置は、それぞれ、前記契約書の暗号鍵及び復号鍵を生成する生成部と、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化する復号化部と、前記復号化された契約書と前記合意対象の契約書とが一致する場合、他装置の暗号鍵を用いて前記合意対象の契約書を暗号化する暗号化部と、を更に備え、前記ブロードキャストする生成部は、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを要旨とする。
 請求項9に記載の契約合意システムは、請求項8に記載の契約合意システムにおいて、前記発行者の装置は、自装置の復号鍵で復号化した契約書と前記合意対象の契約書とが一致するか否かに基づき、契約すべき契約書の同一性を照合することを要旨とする。
 請求項10に記載の契約合意システムは、請求項7乃至9のいずれかに記載の契約合意システムにおいて、前記発行者の装置は、前記契約書に対する合意性の証跡が取れた証明として、第三者の装置に宛ててトランザクションを生成することを要旨とする。
 請求項11に記載の契約合意システムは、請求項7乃至10のいずれかに記載の契約合意システムにおいて、前記ネットワークは、P2Pネットワークであることを要旨とする。
 請求項12に記載の合意検証装置は、請求項7乃至11のいずれかに記載された契約合意システムで行われた契約の合意を検証する合意検証装置において、連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定する検証部、を備えることを要旨とする。
 請求項13に記載の契約合意装置は、ブロックチェーンを共有する分散型のネットワークに接続された契約合意装置において、合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶する記憶部と、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較する照合部と、前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他契約合意装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストする生成部と、前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新する制御部と、を備えることを要旨とする。
 請求項14に記載の契約合意装置は、請求項13に記載の契約合意装置において、前記契約書の暗号鍵及び復号鍵を生成する生成部と、前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化する復号化部と、前記復号化された契約書と前記合意対象の契約書とが一致する場合、他契約合意装置の暗号鍵を用いて前記合意対象の契約書を暗号化する暗号化部と、を更に備え、前記ブロードキャストする生成部は、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他契約合意装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを要旨とする。
 請求項15に記載の合意検証装置は、請求項13又は14に記載された契約合意装置で行われた契約の合意を検証する合意検証装置において、連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定する検証部、を備えることを要旨とする。
 請求項16に記載の契約合意プログラムは、請求項1乃至5のいずれかに記載の契約合意方法をコンピュータに実行させることを要旨とする。
 請求項17に記載の合意検証プログラムは、請求項6に記載の合意検証方法をコンピュータに実行させることを要旨とする。
 本発明によれば、1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに残すことができる。また、本発明によれば、1つのトランザクションに1つの電子署名という形態を保持しつつ、関係者間で合意を取りながら簡易な方法で契約の証跡をブロックチェーンに信頼性を保持しながら残すことができる。
第1の実施の形態に係る契約合意システムの全体構成を示す図である。 第1の実施の形態に係るトランザクションの例を示す図である。 ブロックチェーンの形成動作を示す図である。 ブロックチェーンのイメージを示す図である。 第1の実施の形態に係る契約合意システムの全体動作を示す図である。 トランザクションの宛先の遷移パターンの例を示す図である。 第1の実施の形態に係る契約合意装置の機能ブロックを示す図である。 合意検証装置の機能ブロックを示す図である。 第1の実施の形態に係るトランザクションの別例を示す図である。 第2の実施の形態に係る契約合意システムの全体構成を示す図である。 第2の実施の形態に係るトランザクションの例を示す図である。 第2の実施の形態に係る契約合意前の事前動作を示す図である。 第2の実施の形態に係る契約合意システムの全体動作を示す図である。 第2の実施の形態に係る契約合意装置の機能ブロックを示す図である。 第2の実施の形態に係るトランザクションの別例を示す図である。
 <第1の実施の形態>
 本発明では、契約合意の証跡として既存のブロックチェーン技術を利用する。具体的には、発行された契約のトランザクションに対して、受け手は、その契約に対する合意性を含めたトランザクションを生成して連鎖させる。そして、全ての関係者間でトランザクションを連鎖させた後、最後のトランザクションを契約の発行者に返却してその連鎖を閉じる。さらに、契約の発行者は、全関係者で合意が取れたことを非関係者が証明・保証できるようにするため、第三者のアドレス宛にトランザクションを発生させる。これにより、1つのトランザクションに1名の電子署名という従来と同様の形態を保ちながら契約合意の証跡を残すことができる。
 以下、本発明を実施する一実施の形態について図面を用いて説明する。
 まず、図1を参照しながら、契約合意システム100の全体構成について説明する。本実施の形態では、契約に関わる関係者の総数を例えば3人とし、契約を締結して契約合意の証跡を残そうとする者を契約の発行者、その要求を受けた者を契約の合意者とする。また、全ての関係者で行われた契約合意を保証する者として仲介者を設定する。仲介者は、前述した第三者に相当する者である。例えば、契約合意システムのサービス提供者、契約合意の保証機関等、契約に直接関係のない者が好ましいが、合意者の中から選出してもよい。
 図1に示したように、契約合意システム100は、契約の発行者が使用する発行者側端末1と、2人の合意者がそれぞれ使用する2つの合意者側端末3a,3bと、仲介者が使用する仲介者側端末5と、を備えて構成される。全ての端末は、ブロックチェーンを共有するP2Pネットワーク50により自律分散的に接続されている。
 各端末は、共通する複数の機能部をそれぞれ備え、ブロックチェーン記憶部11と、ブロックチェーン制御部12と、トランザクション生成部13と、で構成される。これら以外の機能部については後述する。
 ブロックチェーン記憶部11は、ブロックチェーンを記憶する機能を備えている。ブロックチェーンとは、合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されているものを指す。
 ブロックチェーン制御部12は、他端末のブロックチェーン制御部と自律分散的に協調して、常に最新のブロックチェーンをブロックチェーン記憶部11に保持する機能を備えている。また、ブロックチェーン記憶部11からブロックチェーンを取得し、トランザクション生成部13に提供する機能も備えている。
 トランザクション生成部13は、前ユーザのトランザクションに対する正当性等が確認された場合、自端末ユーザに関するトランザクションを生成し、P2Pネットワーク50にブロードキャストする機能を備えている。
 ここで、トランザクションについて詳述する。従来の仮想通貨の場合、前述したように、1つのトランザクションに、一つ前のトランザクションのハッシュ値、送り手のアドレス、受け手のアドレス、支払い額及び送り手の電子署名が含められていた。一方、本実施の形態では、合意対象の契約を特定し、かつ、その契約に対する関係者の合意性を記録するため、図2に示すように、従来のトランザクションに対して契約書のハッシュ値及び合意の状態を追加する。すなわち、本実施の形態で用いるトランザクションとは、合意対象の契約書及び該合意対象に対する関係者の合意性に関する情報を更に含み、送り手の電子署名が付与された契約合意の証拠データを指す。これにより、1つのトランザクションに1名の電子署名という従来と同様の形態を保持しつつ、契約に対する当事者の合意の有無を記録することができる。
 以上が契約合意システム100の構成端末の備える機能である。なお、図1には示していないが、ブロックチェーンの系を保つため、仮想通貨の場合と同様に、トランザクションの承認作業を通じてブロックチェーンを連鎖させる承認端末がP2Pネットワーク50上に存在している。
 次に、契約合意システム100の動作について説明する。その前に、図3を参照しながら、ブロックチェーンが形成される既存動作について説明する。図3は、送り手がトランザクションを生成し、ブロックチェーンの承認作業が行われた後、受け手が該トランザクションを確認する動作を説明している。この動作は、本実施の形態のみならず、ブロックチェーンを用いた仮想通貨の取引にも用いられている。
 まず、送り手の端末が、送り手のアドレスから受け手のアドレスに宛てることを明記した電子署名付きのトランザクションを生成し(ステップS101)、P2Pネットワーク上にブロードキャストする(ステップS102)。
 次に、P2Pネットワーク上の承認端末は、そのネットワーク上にブロードキャストされたトランザクションを収集し、ブロックという単位でまとめて承認作業を行う(ステップS103)。この承認作業について、仮想通貨では、プルーフ・オブ・ワークと呼ばれる複雑なハッシュ計算を行う方法、プルーフ・オブ・ステイクと呼ばれるコイン年数を消費する方法等が提案されている。本実施の形態では、それらの方式によらず、承認作業を行い、ブロックチェーンにトランザクションを組み込む、つまり、収集したトランザクションを一つ前のトランザクションに連鎖させる処理を行うものとする。連鎖後のトランザクションは、全ての端末で同期されることになる。
 次に、受け手の端末が、ブロックチェーンに組み込まれたトランザクションを発見すると(ステップS104)、図4に示すように、送り手の公開鍵を用いて該トランザクションの電子署名を検証すると共にハッシュ値の照合等を行うことにより、一つ前のトランザクションが正当な送り手から渡されたことを検証する(ステップS105)。この検証方法については公知の技術で実施可能であり、例えば非特許文献1に記載されている。
 そして、トランザクションの送り手の正当性が確認された場合、受け手の端末は、そのトランザクションを参照して次の相手に対するトランザクションを生成する(ステップS106)。この「受け手」がステップS101の「送り手」となる。
 以上のステップを複数の端末で繰り返し行うことにより、トランザクションの連鎖が形成される。本実施の形態では、このトランザクションの連鎖を利用して契約合意の証跡を残すようにしている。
 次に、図5を参照しながら、契約合意システム100の動作について説明する。なお、全ての端末は承認端末での承認作業を通じてトランザクションを受信し、常に最新のブロックチェーンが記憶されているものとする。また、仲介者を除く関係者は、合意すべき同一の電子契約書を予め所持しており、該契約書をハッシュ化してそのハッシュ値を端末に事前に保持しておくものとする。契約書のハッシュ化には途中の改ざんを防止する目的と第三者から契約の内容を隠蔽する目的があるが、トランザクションが示す契約の内容が合意すべき契約書と照合できればよい。そのため、契約書のIDを代用してもよい。
 本実施の形態では、“発行者を起点としてトランザクションの連鎖を開始し、関係者間でトランザクションを生成して契約取引を連鎖させ、最後に発行者へ戻す”という一連の流れを残すことで契約合意の証跡とする。生成されるトランザクションの内容については図2に示した通りであり、前のトランザクションのハッシュ値等より関係者間の合意の履歴を辿ることができる。本実施の形態では、発行者がトランザクションを生成するために必要な前トランザクションについては仲介者が提供するものとする。
 まず、仲介者側端末5が、発行者宛てのトランザクションを生成する(ステップS201)。このトランザクションは、前述した通り、P2Pネットワーク上にブロードキャストされ、承認端末により収集、承認、連鎖の各処理が行われ、他端末との間で同期される。また、この処理は、トランザクションがブロードキャストされる毎に行われる。以降、その説明は省略する。
 次に、発行者側端末1は、仲介者からのトランザクションを参照し、契約書のハッシュ値を含めて、発行者から合意者Aに宛てたトランザクションを生成する(ステップS202)。このとき、ブール値や特定の値で示される合意の状態もトランザクションに包含される。
 次に、合意者側端末3aは、最新のブロックチェーンから自身宛のトランザクションを取り出し、該トランザクションに含まれる契約書のハッシュ値と自端末の持つ契約書のハッシュ値が一致するかを確認する(ステップS203)。
 そして、契約書の同一性が確認されると、続いて、合意者側端末3aは、その契約に合意をした証明として電子署名の検証やトランザクションのハッシュ値の再計算を行い、契約書のハッシュ値及び合意の状態を含めて、別の合意者Bに宛てたトランザクションを生成する(ステップS204)。
 次に、合意者Bにおいても合意者Aと同様の契約書の確認作業を実施し(ステップS205)、合意の確認が取れた証跡として元の発行者に宛てたトランザクションを生成する(ステップS206)。なお、他にも合意者が存在する場合には、同様にその合意者との間でも契約書のハッシュ値の照合及びトランザクションの生成を行い、トランザクションを更に連鎖させる。
 その後、発行者側端末1は、該発行者側端末1においても契約書のハッシュ値の照合を行うことにより、該当する契約書について全ての関係者間で合意が取れたことを確かめる(ステップS207)。
 最後に、発行者側端末1は、対象の契約に対する合意性の証跡が取れた証明として、仲介者に宛ててトランザクションを生成する(ステップS208)。これは、該当する契約書の合意を起点である発行者が確認し、合意の取り直し等でこれ以上トランザクションが関係者間で繋がらないことを保証することを目的としている。
 以上が契約合意システム100の動作である。
 ここで、トランザクションの宛先の遷移パターンについて説明する。様々な遷移パターンが考えられるが、図5のケースは図6(ア)の遷移パターンがそれに相当する。その他、同図の(イ)又は(ウ)のような遷移パターンも考えられる。(イ)は、発行者が受け取る最初のトランザクションが、仲介者から受けたものではなく、承認作業等の報酬として生成したトランザクションであることを示している。仮想通貨では、P2Pネットワーク上の第三者がトランザクションを収集して新たなブロックチェーンを繋ぐことで取引の承認作業を行い、報酬として新規のコイン(トランザクション)を受け取る(いわゆる“採掘”)ような遷移パターンが想定されている。(ウ)は、合意形成のトポロジーがより複雑な状態である場合を示している。仮想通貨のトランザクションは入力(送り手)と出力(受け手)をN:Nの複数に指定することができる。即ちトランザクションを分岐して出力したり、複数の入力を合算して一つの出力にまとめたりすることができる。そのため、(ウ)のように複雑な経路の合意形成を設定することも可能であり、途中で分岐があった場合であっても、最終的にトランザクションの連鎖の終点が発行者に戻るようにすることにより、関係者間での合意を証明することができる。
 以上説明したように、必要な合意形成の経路が変化した場合であっても、トランザクションの連鎖の終点を必ず発行者とし、その発行者は合意性確認の保証としてトランザクションを指定の第三者(仲介者)へ渡すことにより、関係者間において契約に対する合意性の証跡をP2Pネットワーク上に残すことができる。
 次に、図7を参照しながら、契約合意システム100を構成する端末(契約合意装置)について詳述する。この契約合意装置7は、仲介者、発行者及び合意者が利用する装置であり、ブロックチェーン記憶部11と、ブロックチェーン制御部12と、契約照合部14と、宛先設定部15と、トランザクション生成部13と、データ保持部16と、を備えて構成される。
 データ保持部16は、トランザクションの生成に必要な様々なデータを保持する機能を備えている。各装置はそれぞれ固有のアドレスを持ち、例えば、仮想通貨の仕組みと同様に、電子署名に必要な秘密鍵とペアになる公開鍵のハッシュ値をアドレスとして保持する。また、合意対象の契約書を識別する契約書IDを保持する。例えば、契約書のハッシュ値を利用して該当の契約書との照合が可能な値とする。更に、契約経路を保持する。契約経路には、発行者、合意者及び仲介者の各装置のアドレスが記載され、選定された遷移パターンの経路を実現するためのトランザクションの宛先が記載されている。
 ブロックチェーン記憶部11は、承認端末により承認され、前のブロックチェーンに連鎖され、更に他装置との間で同期されたブロックチェーンを記憶する機能を備えている。
 ブロックチェーン制御部12は、他装置のブロックチェーン制御部と自律分散的に協調して、常に最新のブロックチェーンをブロックチェーン記憶部11に保持する機能、つまり、連鎖された最新のブロックチェーンで既存のブロックチェーンを更新する同期機能を備えている。また、ブロックチェーン記憶部11からブロックチェーンを取得して、自装置のアドレスに宛てたトランザクションを参照する機能を備えている。
 契約照合部14は、最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、該トランザクションに含まれる契約書IDとデータ保持部16の契約書IDとを比較して、それら2つの契約書IDが一致するかを比較する機能を備えている。
 宛先設定部15は、データ保持部16の契約経路とアドレスを参照して次のトランザクションの宛先を特定し、トランザクション生成部13に伝達する機能を備えている。
 トランザクション生成部13は、比較対象である2つの契約書IDが一致する場合、宛先設定部15から伝達された宛先を用いて、契約書ID、合意の有無、合意者の電子署名等を含めて自装置合意者のトランザクションを生成し、P2Pネットワークへブロードキャストする機能を備えている。
 続いて、契約合意装置7の動作について説明する。
 まず、承認端末により、P2Pネットワーク上にブロードキャストされたトランザクションが承認及び連鎖された後、ブロックチェーン制御部12が、連鎖後のブロックチェーンを受信し、ブロックチェーン記憶部11のブロックチェーンを更新する(ステップS301)。
 次に、ブロックチェーン制御部12が、更新された最新のブロックチェーンをブロックチェーン記憶部11から取得して、前ユーザのトランザクションを参照する(ステップS302)。
 次に、契約照合部14が、最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、該トランザクションに含まれる契約書IDとデータ保持部16の契約書IDとを比較する(ステップS303)。
 そして、比較対象である2つの契約書IDが一致する場合、宛先設定部15が、データ保持部16の契約経路とアドレスを参照して次のトランザクションの宛先を特定する(ステップS304)。
 最後に、トランザクション生成部13が、特定された宛先を用いて、契約書ID、自装置合意者による合意の有無、その合意者の電子署名等を含めたトランザクションを生成し、P2Pネットワークへブロードキャストする(ステップS305)。
 以上が契約合意装置7の動作である。本実施の形態では、このような機能を持つ契約合意装置7を合意者等がそれぞれ備え、それらの関係者間で各関係者のトランザクションを連鎖させ、その最後の契約合意装置は、契約書を発行した発行者の契約合意装置に宛ててトランザクションを生成する。これにより、契約合意システム100の利用者は、アドレス、契約経路、契約書ID、合意の有無、電子署名等を契約合意装置に設定するだけで、契約合意の証跡をブロックチェーン上(P2Pネットワーク上)に残すことができる。
 最後に、合意検証装置について説明する。ブロックチェーン上に残された契約合意の証跡は、そのブロックチェーンの系が存在する限りP2Pネットワーク上の任意の端末又は装置から容易に検証することが可能である。そこで、後々に合意の検証を行うために用いる合意検証装置について説明する。
 図8に示すように、合意検証装置9は、データ保持部91と、ブロックチェーン記憶部92と、ブロックチェーン制御部93と、合意検証部94と、を備えて構成される。合意検証部94を除く他の機能部は、契約合意装置7の持つ同一名称の各機能部と同様の機能を備える。
 合意検証部94は、連鎖の起点となるトランザクションに含まれるアドレス(=電子署名用の公開鍵のハッシュ値)と、連鎖の終点となるトランザクションを受け取る装置のアドレスとを比較し、それら2つのアドレスが一致するか否かに基づき契約合意の証跡の有無を判定する検証機能を備えている。
 続いて、合意検証装置9の動作について説明する。
 まず、ブロックチェーン制御部93は、検証対象の契約書IDをデータ保持部91から取得し、該当するトランザクションの連鎖をブロックチェーン記憶部92から取り出す(ステップS401)。
 次に、合意検証部94は、取り出したトランザクションの連鎖の起点となるトランザクションに含まれるアドレスと、連鎖の終点でトランザクションを受け取るアドレスとを比較し、その比較結果に基づき合意の証跡の有無を判定する(ステップS402)。最後のトランザクションが指定の仲介者のアドレスに宛てて送信されているかを確認することで、契約合意の証跡を検証することができる。
 その後、合意検証部94は、それら2つのアドレスが一致している場合、契約合意の証跡が存在することを検証結果として表示する(ステップS403)。その際、トランザクションに含まれるパラメータの内容を併せて表示してもよい。例えば、図2に示したように合意の状態がfalse(非合意)のまま発行者に返っている場合、合意者Aは合意をしていない旨を併せて表示する。
 以上より、本実施の形態によれば、契約書の契約に関わる関係者の契約合意装置間で各関係者のトランザクションを連鎖させ、その最後の装置は、契約書を発行した発行者の装置に宛ててトランザクションを生成するので、煩雑な手続きを行うことなく、より簡易な方法で二者間以上の契約合意の証跡をブロックチェーン上に記録することができる。また、本実施の形態では、中央集権的な仕組みを用いることなく、自律分散的なネットワーク上に契約の合意証跡を保持するので、一部の装置で合意の証跡が失われたとしても、該当するブロックチェーンの系が存在する限りは証跡を永久的に保持することができる。
 なお、本実施の形態では、図2に示したように、送り手と受け手のアドレスとして送り手と受け手の公開鍵のハッシュ値を例に説明したが、図9に示すように、公開鍵のハッシュ値に代えて任意の値を用いてもよい。
 なお、本実施の形態では、P2Pネットワークを例に説明したが、必ずしも文字通りの純粋なピアツーピアで構成されるネットワークを用いる必要はない。最近のビットコインでは例えばハブとなるようなノードも存在しており、広くはブロックチェーンを共有する分散型のネットワークであればよい。
 最後に、本実施の形態で説明した契約合意装置7及び合意検証装置9は、CPU等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現できる。また、それら各装置としてコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。
 <第2の実施の形態>
 本発明では、契約内容のセキュリティについて、関係者の各端末において電子署名用の鍵ペアとは別に、契約書に対する暗号用の鍵ペアを使用する。トランザクションの受け手は、その鍵ペアの暗号鍵を公開用として事前にトランザクションの送り手に送付しておく。一方、その送り手は、受け手から送付された暗号鍵を用いて契約書を暗号化し、暗号化後の契約書を含めて受け手宛にトランザクションを生成する。受け手は、自身の持つもう一方の復号鍵で該暗号化された契約書を復号化する。つまり、最初の発行者が契約書を暗号化して受け手が復号し、その受け手が送信する際には次の受け手の暗号鍵で暗号化し、これを繰り返すことでトランザクションの連鎖上に関係者のみが解読できる暗号化された契約書を保持する。これにより、個々のトランザクションには各関係者により異なる暗号鍵でそれぞれ暗号化された契約書が含まれるので、契約の証跡をブロックチェーンに信頼性を保持しながら残すことができる。
 なお、暗号化された契約書はトランザクションの受け手しか復号できないため、他の関係者においても同一の契約について合意したか否かを判断することができなくなる。しかし、トランザクションの終点で最後のトランザクションが契約の発行者へ返却されるので、その発行者においては、関係者間で合意された契約内容の全体を把握することができ、契約書の暗号化データの値を逐次比較することにより、連鎖の途中で契約内容が変更されていればそれに気付くことができる。
 以下、本発明を実施する一実施の形態について図面を用いて説明する。
 まず、図10を参照しながら、契約合意システム100の全体構成について説明する。契約合意システム100は、第1の実施の形態と同様に、契約の発行者が使用する発行者側端末1と、2人の合意者がそれぞれ使用する2つの合意者側端末3a,3bと、仲介者が使用する仲介者側端末5と、を備えて構成される。全ての端末は、ブロックチェーンを共有するP2Pネットワーク50により自律分散的に接続されている。
 各端末は、共通する複数の機能部をそれぞれ備え、ブロックチェーン記憶部11と、ブロックチェーン制御部12と、トランザクション生成部13と、契約暗号化部17と、で構成される。これら以外の機能部については後述する。
 ブロックチェーン記憶部11は、ブロックチェーンを記憶する機能を備えている。ブロックチェーンとは、合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されているものを指す。
 ブロックチェーン制御部12は、他端末のブロックチェーン制御部と自律分散的に協調して、常に最新のブロックチェーンをブロックチェーン記憶部11に保持する機能を備えている。また、ブロックチェーン記憶部11からブロックチェーンを取得し、トランザクション生成部13又は契約暗号化部17に提供する機能も備えている。
 トランザクション生成部13は、前ユーザのトランザクションに対する正当性等が確認された場合、自端末ユーザに関するトランザクションを生成し、P2Pネットワーク50にブロードキャストする機能を備えている。
 契約暗号化部17は、一対の暗号鍵と復号鍵からなる鍵ペアを生成し、暗号鍵を公開用として他端末へ送信する機能を備えている。また、他端末から送信された暗号鍵を用いて契約書(契約文書)を暗号化する機能も備えている。
 ここで、トランザクションについて詳述する。本実施の形態では、合意対象の契約を特定し、その契約に対する関係者の合意性を記録し、更に契約内容を秘匿するため、図11に示すように、従来のトランザクションに対して契約書(暗号化したもの)及び合意の状態を追加する。すなわち、本実施の形態で用いるトランザクションとは、暗号化された合意対象の契約書及び該合意対象に対する関係者の合意性に関する情報を更に含み、送り手の電子署名が付与された契約合意の証拠データを指す。これにより、1つのトランザクションに1名の電子署名という従来と同様の形態を保持しつつ、契約に対する当事者の合意の有無を記録することができる。また、契約書の暗号化により、契約内容を信頼性が高い状態で保持することができる。
 以上が契約合意システム100の構成端末の備える機能である。なお、図10には示していないが、第1の実施の形態と同様に、ブロックチェーンの系を保つため、仮想通貨の場合と同様に、トランザクションの承認作業を通じてブロックチェーンを連鎖させる承認端末がP2Pネットワーク50上に存在している。
 次に、契約合意システム100の動作について説明する。ブロックチェーンの形成動作については、第1の実施の形態で説明した形成動作と同様のため、ここでの説明は省略する。
 まず、図12を用いて、契約合意の手続に入る前の事前動作について説明する。なお、発行者及び全ての合意者は、合意すべき同一の電子契約書を予め所持しているものとする。また、仮想通貨の場合と同様に、ブロックチェーンを利用するための準備として、電子署名用の鍵ペアの生成や各端末への自端末のアドレス通知等は既に行われているものとする。
 まず、発行者側端末1、合意者側端末3a及び合意者側端末3bは、それぞれ、合意対象の契約書を暗号化するための鍵ペアを生成する(ステップS501)。
 次に、それら各端末は、それぞれ、生成した鍵ペアのうち復号鍵を保存し、その対となる暗号鍵をトランザクションの送り手に送付する(ステップS502)。その送付経路や送付方法については任意である。必ずしもブロックチェーンやP2Pネットワークを用いる必要はなく、インターネットや電話回線等を通じてメールや口頭で通知するようにしてもよい。また、それら各端末間における各暗号鍵の送付順序についても任意である。
 その後、それら各端末は、それぞれ、トランザクションの受け手から送付された暗号鍵を保持する。そして、契約の発行元である発行者側端末1は、合意者側端末3aからの暗号鍵を用いて合意対象の契約書を暗号化する(ステップS503)。
 続いて、図13を用いて、図12の事前動作に引き続いて行われるブロックチェーンの生成動作について説明する。なお、全ての端末は承認端末での承認作業を通じてトランザクションを受信し、常に最新のブロックチェーンが記憶されているものとする。
 本実施の形態では、“発行者を起点としてトランザクションの連鎖を開始し、関係者間でトランザクションを生成して契約取引を連鎖させ、最後に発行者へ戻す”という一連の流れを残すことで契約合意の証跡とする。生成されるトランザクションの内容については図11に示した通りであり、前のトランザクションのハッシュ値等より関係者間の合意の履歴を辿ることができる。本実施の形態では、発行者がトランザクションを生成するために必要な前トランザクションについては仲介者が提供するものとする。
 まず、仲介者側端末5が、発行者宛てのトランザクションを生成する(ステップS601)。このトランザクションは、第1の実施の形態で説明した通り、P2Pネットワーク上にブロードキャストされ、承認端末により収集、承認、連鎖の各処理が行われ、他端末との間で同期される。また、この処理は、トランザクションがブロードキャストされる毎に行われる。以降、その説明は省略する。
 次に、発行者側端末1は、仲介者からのトランザクションを参照し、合意者Aの暗号鍵で暗号化した契約書を含めて、発行者から合意者Aに宛てたトランザクションを生成する(ステップS602)。このとき、ブール値や特定の値で示される合意の状態もトランザクションに包含される。
 次に、合意者側端末3aは、最新のブロックチェーンから自身宛のトランザクションを取り出し、該トランザクションに含まれる暗号化された契約書を自身の復号鍵で復号化し、自身で保持していた契約書と比較することにより、契約書の同一性を確認する(ステップS603)。
 そして、契約書の同一性が確認されると、続いて、合意者側端末3aは、合意者Bの暗号鍵を用いて該当の契約書を再度暗号化する(ステップS604)。
 その後、合意者側端末3aは、その契約に合意をした証明として電子署名の検証やトランザクションのハッシュ値の再計算を行い、合意者Bの暗号鍵で暗号化した契約書及び合意の状態を含めて、合意者Bに宛てたトランザクションを生成する(ステップS605)。
 次に、合意者Bにおいても合意者Aと同様に、自身の復号鍵を用いて合意者Aのトランザクションに含まれる契約書を復号化して契約書の確認作業を実施し(ステップS606)、発行者の暗号鍵を用いて該当の契約書を再度暗号化して(ステップS607)、合意の確認が取れた証跡として元の発行者に宛てたトランザクションを生成する(ステップS608)。なお、他にも合意者が存在する場合には、同様にその合意者との間でも契約書の照合及びトランザクションの生成を行い、トランザクションを更に連鎖させる。
 その後、発行者側端末1は、該発行者側端末1においても、自身の復号鍵を用いて合意者Bのトランザクションに含まれる契約書を復号化して契約書の確認作業を実施し、該当する契約書について全ての関係者間で合意が取れたことを確かめる(ステップS609)。ここで、最初に発行した契約の内容と相違があれば、発行者は、経路のどこかで契約書の改ざんがなされていることに気付くことができる。その際の確認方法としては、例えば、最初の発行の際に契約書のハッシュ値を保存しておき、合意者Bからのトランザクションに含まれている契約書のハッシュ値と比較し、一致するか否かに基づき契約書の同一性を照合することが考えられる。
 最後に、発行者側端末1は、対象の契約に対する合意性の証跡が取れ、かつ、契約書の改ざんがなされていないことの証明として、仲介者に宛ててトランザクションを生成する(ステップS610)。これは、該当する契約書の合意を起点である発行者が確認し、合意の取り直し等でこれ以上トランザクションが関係者間で繋がらないことを保証することを目的としている。また、各トランザクションにそれぞれ含まれている暗号化された契約書は、異なる鍵でそれぞれ暗号化されているため、後に第三者が合意を確認しようとしても同じ文書について合意されたものであるかを確認することができない。そのため、最後にトランザクションを受け取った発行者が改ざんの有無を確認した証を残す必要があり、これが仲介者に宛てたトランザクションに該当する。
 以上が契約合意システム100の動作である。
 なお、トランザクションの宛先の遷移パターンについては、第1の実施の形態で説明した遷移パターンと同様のため、ここでの説明は省略する。
 以上説明したように、必要な合意形成の経路が変化した場合であっても、トランザクションの連鎖の終点を必ず発行者とし、その発行者は合意性確認の保証としてトランザクションを指定の第三者(仲介者)へ渡すことにより、関係者間において契約に対する合意性の証跡をP2Pネットワーク上に残すことができる。また、契約書の暗号化により、契約内容を信頼性が高い状態で保持することができる。
 次に、図14を参照しながら、契約合意システム100を構成する端末(契約合意装置)について詳述する。この契約合意装置7は、仲介者、発行者及び合意者が利用する装置であり、ブロックチェーン記憶部11と、ブロックチェーン制御部12と、契約復号化部18と、契約照合部14と、契約暗号化部17と、宛先設定部15と、トランザクション生成部13と、契約書用鍵ペア生成部19と、データ保持部16と、を備えて構成される。
 データ保持部16は、トランザクションの生成に必要な様々なデータを保持する機能を備えている。各装置はそれぞれ固有のアドレスを持ち、例えば、仮想通貨の仕組みと同様に、電子署名に必要な秘密鍵とペアになる公開鍵のハッシュ値をアドレスとして保持する。また、契約経路を保持する。契約経路には、発行者、合意者及び仲介者の各装置のアドレスが記載され、選定された遷移パターンの経路を実現するためのトランザクションの宛先が記載されている。更に、契約書に対して暗号化を施すための契約書用鍵ペアを保持する。
 ブロックチェーン記憶部11は、承認端末により承認され、前のブロックチェーンに連鎖され、更に他装置との間で同期されたブロックチェーンを記憶する機能を備えている。
 ブロックチェーン制御部12は、他装置のブロックチェーン制御部と自律分散的に協調して、常に最新のブロックチェーンをブロックチェーン記憶部11に保持する機能、つまり、連鎖された最新のブロックチェーンで既存のブロックチェーンを更新する同期機能を備えている。また、ブロックチェーン記憶部11からブロックチェーンを取得して、自装置のアドレスに宛てたトランザクションを参照する機能を備えている。
 契約復号化部18は、最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、該トランザクションに含まれる契約書をデータ保持部16の復号鍵で復号化する機能を備えている。
 契約照合部14は、復号化された契約書と自身が保持する契約書とを比較して、それら2つの契約書が一致するかを比較する機能を備えている。
 契約暗号化部17は、比較対象である2つの契約書が一致する場合、他装置から送信された暗号鍵を用いて契約書を暗号化する機能を備えている。
 宛先設定部15は、データ保持部16の契約経路とアドレスを参照して次のトランザクションの宛先を特定し、トランザクション生成部13に伝達する機能を備えている。
 トランザクション生成部13は、宛先設定部15から伝達された宛先を用いて、暗号化した契約書、合意の有無、合意者の電子署名等を含めて自装置合意者のトランザクションを生成し、P2Pネットワークへブロードキャストする機能を備えている。
 契約書用鍵ペア生成部19は、一対の暗号鍵と復号鍵からなる契約書用鍵ペアを生成してデータ保持部16に保存させ、暗号鍵のみを公開用として他装置へ送信する機能を備えている。前述した通り、この機能は契約暗号化部17が備えるようにしてもよい。
 続いて、契約合意装置7の動作について説明する。
 まず、承認端末により、P2Pネットワーク上にブロードキャストされたトランザクションが承認及び連鎖された後、ブロックチェーン制御部12が、連鎖後のブロックチェーンを受信し、ブロックチェーン記憶部11のブロックチェーンを更新する(ステップS701)。
 次に、ブロックチェーン制御部12が、更新された最新のブロックチェーンをブロックチェーン記憶部11から取得して、前ユーザのトランザクションを参照する(ステップS702)。
 次に、契約復号化部18が、最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、該トランザクションに含まれる契約書をデータ保持部16で保持している自身の復号鍵で復号化する(ステップS703)。
 次に、契約照合部14が、復号化された契約書と自身が保持する契約書とを比較する(ステップS704)。このとき、ユーザ自身がそれらの契約書を目視して確認してもよいし、事前に確認した契約書のハッシュ値を取得しておき、そのハッシュ値等を利用して照合してもよい。
 そして、比較対象である2つの契約書が一致する場合、契約暗号化部17が、他装置から送信された暗号鍵を用いて該当の契約書を再度暗号化する(ステップS705)。
 その後、宛先設定部15が、データ保持部16の契約経路とアドレスを参照して次のトランザクションの宛先を特定する(ステップS706)。
 最後に、トランザクション生成部13が、特定された宛先を用いて、再度暗号化された契約書、自装置合意者による合意の有無、その合意者の電子署名等を含めたトランザクションを生成し、P2Pネットワークへブロードキャストする(ステップS707)。
 以上が契約合意装置7の動作である。本実施の形態では、このような機能を持つ契約合意装置7を合意者等がそれぞれ備え、それらの関係者間で各関係者のトランザクションを連鎖させ、その最後の契約合意装置は、契約書を発行した発行者の契約合意装置に宛ててトランザクションを生成する。また、トランザクションに含まれる契約書を受け手の暗号鍵を用いて暗号化する。これにより、契約合意システム100の利用者は、アドレス、契約経路、契約書、契約書用鍵ペア、合意の有無、電子署名等を契約合意装置に設定するだけで、契約合意の証跡をブロックチェーン上(P2Pネットワーク上)に信頼性を保持しながら残すことができる。
 最後に、合意検証装置について説明する。ブロックチェーン上に残された契約合意の証跡は、そのブロックチェーンの系が存在する限りP2Pネットワーク上の任意の端末又は装置から容易に検証することが可能である。そこで、後々に合意の検証を行うために用いる合意検証装置について説明する。
 図8に示したように、合意検証装置9は、本実施の形態においても、データ保持部91と、ブロックチェーン記憶部92と、ブロックチェーン制御部93と、合意検証部94と、を備えて構成される。データ保持部91と合意検証部94を除く他の機能部は、契約合意装置7の持つ同一名称の各機能部と同様の機能を備える。
 データ保持部91は、契約書を識別する契約書IDを保持する。例えば、契約書のハッシュ値を利用して該当の契約書との照合が可能な値とする。
 合意検証部94は、連鎖の起点となるトランザクションに含まれるアドレス(=電子署名用の公開鍵のハッシュ値)と、連鎖の終点となるトランザクションを受け取る装置のアドレスとを比較し、それら2つのアドレスが一致するか否かに基づき契約合意の証跡の有無を判定する検証機能を備えている。
 続いて、合意検証装置9の動作について説明する。
 まず、ブロックチェーン制御部93は、検証対象の契約書IDをデータ保持部91から取得し、該当するトランザクションの連鎖をブロックチェーン記憶部92から取り出す(ステップS801)。
 次に、合意検証部94は、取り出したトランザクションの連鎖の起点となるトランザクションに含まれるアドレスと、連鎖の終点でトランザクションを受け取るアドレスとを比較し、その比較結果に基づき合意の証跡の有無を判定する(ステップS802)。最後のトランザクションが指定の仲介者のアドレスに宛てて送信されているかを確認することで、契約合意の証跡を検証することができる。
 その後、合意検証部94は、それら2つのアドレスが一致している場合、契約合意の証跡が存在することを検証結果として表示する(ステップS803)。その際、トランザクションに含まれるパラメータの内容を併せて表示してもよい。例えば、図11に示したように合意の状態がfalse(非合意)のまま発行者に返っている場合、合意者Aは合意をしていない旨を併せて表示する。
 以上より、本実施の形態によれば、契約書の契約に関わる関係者の契約合意装置間で各関係者のトランザクションを連鎖させ、その最後の装置は、契約書を発行した発行者の装置に宛ててトランザクションを生成するので、煩雑な手続きを行うことなく、より簡易な方法で二者間以上の契約合意の証跡をブロックチェーン上に記録することができる。また、本実施の形態では、中央集権的な仕組みを用いることなく、自律分散的なネットワーク上に契約の合意証跡を保持するので、一部の装置で合意の証跡が失われたとしても、該当するブロックチェーンの系が存在する限りは証跡を永久的に保持することができる。
 また、本実施の形態によれば、契約書を暗号化してブロックチェーン上に保持するので、契約の内容を各端末に保持していなくても復号鍵さえ保持していれば、自身が受けたトランザクションに含まれる暗号化された契約を解読できる。復号鍵の受け渡しが関係者間で発生しないので、信頼性高く契約の内容を保持することができる。
 なお、本実施の形態では、図11に示したように、送り手と受け手のアドレスとして送り手と受け手の公開鍵のハッシュ値を例に説明したが、図15に示すように、公開鍵のハッシュ値に代えて任意の値を用いてもよい。
 なお、本実施の形態では、P2Pネットワークを例に説明したが、必ずしも文字通りの純粋なピアツーピアで構成されるネットワークを用いる必要はない。最近のビットコインでは例えばハブとなるようなノードも存在しており、広くはブロックチェーンを共有する分散型のネットワークであればよい。
 最後に、本実施の形態で説明した契約合意装置7及び合意検証装置9は、CPU等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現できる。また、それら各装置としてコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。
 1…発行者側端末
 3a,3b…合意者側端末
 5…仲介者側端末
 7…契約合意装置
 9…合意検証装置
 11…ブロックチェーン記憶部
 12…ブロックチェーン制御部
 13…トランザクション生成部
 14…契約照合部
 15…宛先設定部
 16…データ保持部
 17…契約暗号化部
 18…契約復号化部
 19…契約書用鍵ペア生成部
 50…P2Pネットワーク
 91…データ保持部
 92…ブロックチェーン記憶部
 93…ブロックチェーン制御部
 94…合意検証部
 100…契約合意システム
 S101~S106,S201~S208,S301~S305,S401~S403、S501~S503、S601~S610、S701~S707、S801~S803…ステップ

Claims (17)

  1.  ブロックチェーンを共有する分散型のネットワークに接続された複数の装置間で行う契約合意方法において、
     前記複数の装置は、それぞれ、
     合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶部に記憶するステップと、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較するステップと、
     前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストするステップと、
     前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新するステップと、を備え、
     前記複数の装置は、前記契約書の契約に関わるユーザのトランザクションを連鎖させ、前記連鎖を行う最後の装置は、前記契約書を発行した発行者の装置に宛ててトランザクションを生成することを特徴とする契約合意方法。
  2.  前記複数の装置は、それぞれ、
     前記契約書の暗号鍵及び復号鍵を生成するステップと、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化するステップと、
     前記復号化された契約書と前記合意対象の契約書とが一致する場合、他装置の暗号鍵を用いて前記合意対象の契約書を暗号化するステップと、を更に備え、
     前記ブロードキャストするステップでは、
     少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを特徴とする請求項1に記載の契約合意方法。
  3.  前記発行者の装置は、
     自装置の復号鍵で復号化した契約書と前記合意対象の契約書とが一致するか否かに基づき、契約すべき契約書の同一性を照合することを特徴とする請求項2に記載の契約合意方法。
  4.  前記発行者の装置は、
     前記契約書に対する合意性の証跡が取れた証明として、第三者の装置に宛ててトランザクションを生成することを特徴とする請求項1乃至3のいずれかに記載の契約合意方法。
  5.  前記ネットワークは、
     P2Pネットワークであることを特徴とする請求項1乃至4のいずれかに記載の契約合意方法。
  6.  請求項1乃至5のいずれかに記載された契約合意方法で行われた契約の合意を合意検証装置で検証する合意検証方法において、
     前記合意検証装置は、
     連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定するステップ、
     を備えることを特徴とする合意検証方法。
  7.  ブロックチェーンを共有する分散型のネットワークに接続された複数の装置を備えた契約合意システムにおいて、
     前記複数の装置は、それぞれ、
     合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶する記憶部と、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較する照合部と、
     前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストする生成部と、
     前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新する制御部と、を備え、
     前記複数の装置は、前記契約書の契約に関わるユーザのトランザクションを連鎖させ、前記連鎖を行う最後の装置は、前記契約書を発行した発行者の装置に宛ててトランザクションを生成することを特徴とする契約合意システム。
  8.  前記複数の装置は、それぞれ、
     前記契約書の暗号鍵及び復号鍵を生成する生成部と、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化する復号化部と、
     前記復号化された契約書と前記合意対象の契約書とが一致する場合、他装置の暗号鍵を用いて前記合意対象の契約書を暗号化する暗号化部と、を更に備え、
     前記ブロードキャストする生成部は、
     少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを特徴とする請求項7に記載の契約合意システム。
  9.  前記発行者の装置は、
     自装置の復号鍵で復号化した契約書と前記合意対象の契約書とが一致するか否かに基づき、契約すべき契約書の同一性を照合することを特徴とする請求項8に記載の契約合意システム。
  10.  前記発行者の装置は、
     前記契約書に対する合意性の証跡が取れた証明として、第三者の装置に宛ててトランザクションを生成することを特徴とする請求項7乃至9のいずれかに記載の契約合意システム。
  11.  前記ネットワークは、
     P2Pネットワークであることを特徴とする請求項7乃至10のいずれかに記載の契約合意システム。
  12.  請求項7乃至11のいずれかに記載された契約合意システムで行われた契約の合意を検証する合意検証装置において、
     連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定する検証部、
     を備えることを特徴とする合意検証装置。
  13.  ブロックチェーンを共有する分散型のネットワークに接続された契約合意装置において、
     合意対象の契約書に対する合意性の証跡を示すトランザクションがブロックとして連鎖されるブロックチェーンを記憶する記憶部と、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とを比較する照合部と、
     前記トランザクションに含まれる契約書の識別子と前記合意対象の契約書の識別子とが一致する場合、少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記合意対象の契約書の識別子と、を含む他契約合意装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストする生成部と、
     前記生成されたトランザクションが前記前ユーザのトランザクションに連鎖されたブロックチェーンで前記記憶部のブロックチェーンを更新する制御部と、
     を備えることを特徴とする契約合意装置。
  14.  前記契約書の暗号鍵及び復号鍵を生成する生成部と、
     前記ブロックチェーンに最後に連鎖された前ユーザのトランザクションが自装置宛ての場合、当該トランザクションに含まれる契約書を自装置の前記復号鍵で復号化する復号化部と、
     前記復号化された契約書と前記合意対象の契約書とが一致する場合、他契約合意装置の暗号鍵を用いて前記合意対象の契約書を暗号化する暗号化部と、を更に備え、
     前記ブロードキャストする生成部は、
     少なくとも、前記契約書に対する自装置ユーザの合意又は非合意の証と、前記自装置ユーザの電子署名と、前記暗号化された契約書と、を含む前記他契約合意装置宛てのトランザクションを生成し、前記ネットワークへブロードキャストすることを特徴とする請求項13に記載の契約合意装置。
  15.  請求項13又は14に記載された契約合意装置で行われた契約の合意を検証する合意検証装置において、
     連鎖の起点となるトランザクションに含まれる電子署名用の公開鍵と連鎖の終点となるトランザクションを受け取る装置のユーザの電子署名用の公開鍵とが一致するか否かに基づき、契約合意の証跡の有無を判定する検証部、
     を備えることを特徴とする合意検証装置。
  16.  請求項1乃至5のいずれかに記載の契約合意方法をコンピュータに実行させることを特徴とする契約合意プログラム。
  17.  請求項6に記載の合意検証方法をコンピュータに実行させることを特徴とする合意検証プログラム。
PCT/JP2016/070415 2015-07-13 2016-07-11 契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム WO2017010455A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP16824435.8A EP3324355B1 (en) 2015-07-13 2016-07-11 Contract agreement method, agreement verification method, contract agreement system, agreement verification device, contract agreement device, contract agreement program and agreement verification program
US15/743,523 US10848315B2 (en) 2015-07-13 2016-07-11 Contract agreement method, agreement verification method, contract agreement system, agreement verification device, contract agreement device, contract agreement program and agreement verification program
JP2017528672A JP6483827B2 (ja) 2015-07-13 2016-07-11 契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム
CN201680041624.5A CN107851253B (zh) 2015-07-13 2016-07-11 合约合意方法、合意验证方法、合约合意系统、合意验证装置、合约合意装置、计算机可读记录介质

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2015139490 2015-07-13
JP2015-139495 2015-07-13
JP2015139495 2015-07-13
JP2015-139490 2015-07-13

Publications (1)

Publication Number Publication Date
WO2017010455A1 true WO2017010455A1 (ja) 2017-01-19

Family

ID=57757367

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/070415 WO2017010455A1 (ja) 2015-07-13 2016-07-11 契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム

Country Status (5)

Country Link
US (1) US10848315B2 (ja)
EP (1) EP3324355B1 (ja)
JP (1) JP6483827B2 (ja)
CN (1) CN107851253B (ja)
WO (1) WO2017010455A1 (ja)

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017195627A (ja) * 2017-06-23 2017-10-26 株式会社エヌ・ティ・ティ・データ 情報処理装置、情報処理方法およびプログラム
CN107341702A (zh) * 2017-03-08 2017-11-10 阿里巴巴集团控股有限公司 一种业务处理的方法及装置
CN107911216A (zh) * 2017-10-26 2018-04-13 矩阵元技术(深圳)有限公司 一种区块链交易隐私保护方法及系统
JP6340107B1 (ja) * 2017-04-10 2018-06-06 アイビーシー株式会社 電子証明システム
JP2018128823A (ja) * 2017-02-08 2018-08-16 株式会社サテライトオフィス 電子ファイル証明システム
WO2018150606A1 (ja) * 2016-02-18 2018-08-23 株式会社野村総合研究所 情報処理装置、情報処理方法およびコンピュータプログラム
JP2018160828A (ja) * 2017-03-23 2018-10-11 沖電気工業株式会社 送金元装置、送金先装置、送金方法、受金方法、プログラムおよび送金システム
JP2018182710A (ja) * 2017-08-10 2018-11-15 アイビーシー株式会社 電子証明システム
CN108920978A (zh) * 2018-06-26 2018-11-30 赛飞特工程技术集团有限公司 一种基于区块链技术的安全生产信息共享方法
WO2018230648A1 (ja) * 2017-06-16 2018-12-20 株式会社Zweispace Japan ランダム仲介手数料設定機能を有する不動産仲介システム、不動産仲介方法、及び不動産仲介プログラム
CN109145275A (zh) * 2018-08-07 2019-01-04 广东工业大学 一种区块链电子合同管理和智能生成系统及方法
JP2019009767A (ja) * 2018-03-01 2019-01-17 株式会社エヌ・ティ・ティ・データ 情報処理装置
KR101918446B1 (ko) * 2018-03-16 2019-01-29 윤경민 이중보안 블록체인 인증시스템 및 그 방법
JP2019040621A (ja) * 2018-11-07 2019-03-14 株式会社Zweispace Japan 取引仲介システム、取引仲介方法及び取引仲介プログラム
WO2019054043A1 (ja) * 2017-09-14 2019-03-21 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
JP2019073394A (ja) * 2017-09-11 2019-05-16 アクセンチュア グローバル ソリューションズ リミテッド 運送システムのための分散型台帳技術
JP2019515534A (ja) * 2016-04-29 2019-06-06 エヌチェーン ホールディングス リミテッドNchain Holdings Limited 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
KR20190088530A (ko) * 2017-05-31 2019-07-26 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
KR20190091484A (ko) * 2017-03-28 2019-08-06 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
JP2019145926A (ja) * 2018-02-17 2019-08-29 渡辺 浩志 チップウォレット
JP2019161580A (ja) * 2018-03-16 2019-09-19 日本電気株式会社 データ送信装置、データ送受信システム、データ受信装置、データ送信方法、プログラム
KR20190108521A (ko) * 2018-03-14 2019-09-24 주식회사 아이시티코리아 블록체인 기반 스마트 계약시스템 및 그 방법
KR20190119576A (ko) * 2017-07-14 2019-10-22 알리바바 그룹 홀딩 리미티드 블록체인 기반 데이터 프로세싱 방법 및 디바이스
WO2020008623A1 (ja) * 2018-07-06 2020-01-09 株式会社日立製作所 リソース融通支援システム、リソース融通支援方法、および、リソース融通支援装置
CN110754070A (zh) * 2017-06-20 2020-02-04 区块链控股有限公司 最近交易在区块链网络上的快速传播
KR20200018069A (ko) * 2018-08-10 2020-02-19 고하준 중재노드를 이용한 블록체인 안전결제 방법 및 그 시스템
JP2020028052A (ja) * 2018-08-14 2020-02-20 株式会社Skill データ管理方法
JP2020511019A (ja) * 2017-02-24 2020-04-09 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited 鍵確立およびデータ送信の方法および装置
JP2020512610A (ja) * 2017-05-22 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited ブロックチェーンサービス受付けおよびコンセンサス方法およびデバイス
JP2020512617A (ja) * 2017-02-17 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited ブロックチェーン・システムならびにデータ記憶方法および装置
JP2020512779A (ja) * 2017-03-28 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited トランザクション要求を処理するための方法及び装置
WO2020085347A1 (ja) * 2018-10-22 2020-04-30 力 松永 ブロックチェーンを用いた建築工程管理システムおよびそれを利用したデータ取引システム
KR20200055410A (ko) * 2018-11-13 2020-05-21 주식회사 싸이투코드 디지털 컨텐츠 원본 확인키를 이용한 블록체인 방식의 계약 단말 및 방법
JP2020516164A (ja) * 2017-04-07 2020-05-28 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンを使用した安全なデータレコード配信のための方法及びシステム
JP2020517034A (ja) * 2017-03-31 2020-06-11 シングラフィー インコーポレイテッド 電子文書を締結して配送するためのシステム及び方法
JP2020517134A (ja) * 2017-04-11 2020-06-11 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーン上の迅速な分散型総意
JP2020091568A (ja) * 2018-12-04 2020-06-11 セイコーエプソン株式会社 提供装置及び処理システム
JP2020091569A (ja) * 2018-12-04 2020-06-11 セイコーエプソン株式会社 提供装置及び処理システム
JP2020516976A (ja) * 2017-01-31 2020-06-11 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンを用いて実施される機械実行可能コントラクトの状態を決定する、コンピュータにより実装されるシステム及び方法
JP2020150428A (ja) * 2019-03-14 2020-09-17 公立大学法人広島市立大学 ブロックチェーン取引作成プロトコル、及びブロックチェーンアドレス作成方法
JP2020532217A (ja) * 2017-08-29 2020-11-05 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンにおけるアンロックトランザクションのアウトプットに対する制約
JP2020532817A (ja) * 2017-09-05 2020-11-12 シェルターズーム コーポレイション ブロックチェーン式不動産販売および賃貸システム
WO2021020407A1 (ja) * 2019-08-01 2021-02-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及び、プログラム
JP2021015387A (ja) * 2019-07-11 2021-02-12 株式会社サイトビジット スマートコントラクトシステム及びプログラム
US20210056070A1 (en) * 2016-02-03 2021-02-25 Luther Systems Us Incorporated System and method for secure management of digital contracts
WO2021125108A1 (ja) * 2019-12-19 2021-06-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、装置、および、プログラム
US11093628B2 (en) 2019-02-14 2021-08-17 International Business Machines Corporation Cross-domain content-lifecycle management
CN113612741A (zh) * 2020-12-01 2021-11-05 支付宝(杭州)信息技术有限公司 一种物品流通记录的存证方法、装置、设备和存储介质
JP2022509590A (ja) * 2018-11-13 2022-01-21 サイツコード カンパニー リミテッド 位置情報を用いたブロックチェーン方式の契約端末及び方法
JP2022020603A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 取引方式に基づく電子契約証拠保存システム
JP2022020604A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 分散型電子契約証明プラットフォーム
US11314727B2 (en) 2017-08-22 2022-04-26 Nec Corporation Blockchain management apparatus, blockchain management method, and program
JP2022125129A (ja) * 2019-07-11 2022-08-26 株式会社サイトビジット スマートコントラクトシステム及びプログラム
US11522849B2 (en) 2018-04-09 2022-12-06 Mitsubishi Electric Corporation Authentication system and computer readable medium
JP2022551417A (ja) * 2019-10-21 2022-12-09 ソン・ミン・ユン 金融取引システムおよびその方法
US11652647B2 (en) 2018-04-09 2023-05-16 Mitsubishi Electric Corporation Authentication system and computer readable medium
WO2023084788A1 (ja) * 2021-11-15 2023-05-19 日本電信電話株式会社 無線通信方法、無線基地局、及び無線通信システム

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US11195177B1 (en) * 2015-08-21 2021-12-07 United Services Automobile Association (Usaa) Distributed ledger systems for tracking recurring transaction authorizations
US11188907B1 (en) * 2015-08-21 2021-11-30 United Services Automobile Association (Usaa) ACH authorization validation using public blockchains
JP2017184198A (ja) * 2016-03-31 2017-10-05 ソニー株式会社 イメージセンサ、撮像装置、イメージセンサ特定方法、画像偽造防止方法および画像改変制限方法
GB201613144D0 (en) * 2016-07-29 2016-09-14 Eitc Holdings Ltd Computer-implemented method and system
US10491402B2 (en) * 2016-07-29 2019-11-26 Magic Leap, Inc. Secure exchange of cryptographically signed records
US11651360B2 (en) * 2016-11-21 2023-05-16 Kyndryl, Inc. Triggering actions responsive to blockchain transactions
CN106991334B (zh) 2016-11-24 2021-03-02 创新先进技术有限公司 一种数据存取的方法、系统及装置
US10657225B2 (en) * 2016-12-29 2020-05-19 Red Hat, Inc. Providing blockchain-based subscription-as-a-service management
KR20180083602A (ko) * 2017-01-13 2018-07-23 삼성전자주식회사 전자 장치 및 이의 제어 방법
US10824759B1 (en) * 2017-01-25 2020-11-03 State Farm Mutual Automobile Insurance Company Systems and methods for verifying agent sales data via blockchain
US20180247258A1 (en) * 2017-02-28 2018-08-30 Dais Technology, Inc. Operating system for on-demand economy
CN106960165B (zh) * 2017-03-13 2020-12-22 广东网金控股股份有限公司 一种基于区块链智能合约实现电子合同多方会签的方法
JP2020521257A (ja) * 2017-05-18 2020-07-16 コデックス エルエルシーCodex Llc ブロックチェーンを使用した分散型デジタルコンテンツ配信システムおよびプロセス
JP7194127B2 (ja) * 2017-06-14 2022-12-21 エヌチェーン ライセンシング アーゲー ネットワークの障害時におけるオフ・ブロックチェーン・チャネルに関して生じるセキュリティ関連脆弱性に対処するためのシステム及び方法
US10944546B2 (en) 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
US20190164157A1 (en) * 2017-11-28 2019-05-30 American Express Travel Related Services Company, Inc. Transaction authorization process using blockchain
CN108846747A (zh) * 2018-05-24 2018-11-20 阿里巴巴集团控股有限公司 一种基于区块链的虚拟资源交付、众筹方法及装置
US11397960B2 (en) * 2018-06-11 2022-07-26 International Business Machines Corporation Direct marketing via chained interactions in a blockchain
CN109359971B (zh) 2018-08-06 2020-05-05 阿里巴巴集团控股有限公司 区块链交易方法及装置、电子设备
CN112651740A (zh) 2018-08-30 2021-04-13 创新先进技术有限公司 区块链交易方法及装置、电子设备
CN111833186A (zh) 2018-09-20 2020-10-27 创新先进技术有限公司 基于区块链的交易方法、装置和节点设备
CN109492983B (zh) * 2018-09-26 2023-04-07 深圳壹账通智能科技有限公司 基于区块链智能合约的电子印章签署方法、装置、设备和介质
CN109409876A (zh) * 2018-09-27 2019-03-01 深圳壹账通智能科技有限公司 基于区块链的电子合同签署方法、装置、设备及存储介质
US11012242B1 (en) 2018-09-28 2021-05-18 Wells Fargo Bank, N.A. Systems and methods for trusted chain code system
CN109583886B (zh) 2018-09-30 2020-07-03 阿里巴巴集团控股有限公司 基于区块链的交易方法、装置和汇出方设备
CN109462540A (zh) * 2018-10-12 2019-03-12 彩讯科技股份有限公司 邮件存证方法、装置和系统
KR102204231B1 (ko) * 2018-10-29 2021-01-18 에스케이텔레콤 주식회사 블록체인 기반 분산 원장 관리 방법
CN109858284A (zh) * 2018-11-28 2019-06-07 阿里巴巴集团控股有限公司 一种证据的采集记录方法、装置及电子设备
US11616816B2 (en) * 2018-12-28 2023-03-28 Speedchain, Inc. Distributed ledger based document image extracting and processing within an enterprise system
US10958637B2 (en) * 2018-12-28 2021-03-23 Mox-SpeedChain, LLC Preselected issuance and data operations loops in a hybrid distributed network ecosystem
EP3568826B1 (en) 2018-12-29 2021-09-29 Advanced New Technologies Co., Ltd. System and method for information protection
CN109767222A (zh) * 2019-01-21 2019-05-17 中国联合网络通信集团有限公司 基于区块链的航班延误险投保方法及系统
WO2020199135A1 (zh) * 2019-04-02 2020-10-08 武汉龙津科技有限公司 一种通证设计及其操作权限管理的方法与系统
US10990563B2 (en) 2019-04-11 2021-04-27 Advanced New Technologies Co., Ltd. Information read/write method and apparatus based on blockchain
WO2020254923A1 (en) * 2019-06-15 2020-12-24 Indian Institute Of Technology, Delhi Method in blockchain systems for fast stabilization and increased responsiveness using links
SE544149C2 (en) * 2019-06-25 2022-01-11 Coined Invest Pool Company Ab Method and system for performing electronic transactions
JP7422154B2 (ja) * 2019-08-01 2024-01-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及び、プログラム
CN110688668A (zh) * 2019-09-02 2020-01-14 平安普惠企业管理有限公司 一种电子合同存储方法及装置、电子设备
CN110941674A (zh) * 2019-11-26 2020-03-31 北京海益同展信息科技有限公司 基于区块链的合规审计方法、装置、系统及存储介质
US11829765B2 (en) 2021-03-31 2023-11-28 International Business Machines Corporation Computer mechanism for analytic orchestration and entitled execution
US20220358458A1 (en) * 2021-05-04 2022-11-10 Gray Matters, Inc. Secure blockchain supply management system
CN114189573B (zh) * 2022-02-15 2022-05-17 中国汽车技术研究中心有限公司 一种can信号解析方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052128A1 (fr) * 2000-01-13 2001-07-19 Yutaka Yasukura Procede d'interrogation par voie electronique
JP2002049590A (ja) * 2000-08-04 2002-02-15 Hitachi Ltd 電子公証システム
JP2002170058A (ja) * 2000-11-21 2002-06-14 Riccardo Genghini アクティブ識別管理による商取引の自動実行システム

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004506361A (ja) * 2000-08-04 2004-02-26 ファースト データ コーポレイション デバイスの検証ステータスを提供することによる電子通信におけるエンティティ認証
US20020038424A1 (en) * 2000-09-22 2002-03-28 Joao Raymond Anthony Apparatus and method for providing security for electronic signatures
JP2003016397A (ja) * 2001-04-23 2003-01-17 Sony Corp データ処理システム、メモリデバイス、データ処理装置、およびデータ処理方法、並びにプログラム
CN1745395A (zh) * 2003-01-24 2006-03-08 赫斯能量贸易有限责任公司 有保证的现货交割期货合约及其方法和系统
TWI351864B (en) * 2005-03-25 2011-11-01 Via Tech Inc Apparatus and method for employing cyrptographic f
US9514117B2 (en) * 2007-02-28 2016-12-06 Docusign, Inc. System and method for document tagging templates
CN101510168B (zh) * 2008-11-07 2012-06-27 慧帝科技(深圳)有限公司 一种快闪记忆体的存取方法和记忆体装置
CN102184495B (zh) * 2011-04-21 2016-09-28 天地融科技股份有限公司 一种网络支付方法及系统
US9268758B2 (en) * 2011-07-14 2016-02-23 Docusign, Inc. Method for associating third party content with online document signing
US8868916B2 (en) * 2011-09-30 2014-10-21 Adobe Systems Incorporated Self-contained electronic signature
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
US8897424B2 (en) * 2012-07-11 2014-11-25 Oracle International Corporation Automatic clustering and visualization of data trends
US20140067588A1 (en) * 2012-09-05 2014-03-06 Mafcote, Inc. Interface for product design customization
US9876775B2 (en) * 2012-11-09 2018-01-23 Ent Technologies, Inc. Generalized entity network translation (GENT)
US20140324662A1 (en) * 2013-03-15 2014-10-30 Open Access Technology International, Inc. Systems and Methods for Trading Electrical Power
US9595034B2 (en) * 2013-10-25 2017-03-14 Stellenbosch University System and method for monitoring third party access to a restricted item
WO2015106285A1 (en) * 2014-01-13 2015-07-16 Yago Yaron Edan Verification method
WO2015148725A2 (en) * 2014-03-25 2015-10-01 Mark Stephen Meadows Systems and methods for executing cryptographically secure transactions using voice and natural language processing
US10340038B2 (en) * 2014-05-13 2019-07-02 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain, systems and methods
US9614681B2 (en) * 2015-01-09 2017-04-04 Adobe Systems Incorporated Private electronic signature service for electronic documents
US9965628B2 (en) * 2015-03-02 2018-05-08 Dell Products Lp Device reporting and protection systems and methods using a secure distributed transactional ledger
US10484168B2 (en) * 2015-03-02 2019-11-19 Dell Products L.P. Methods and systems for obfuscating data and computations defined in a secure distributed transaction ledger
US10158480B1 (en) * 2015-03-16 2018-12-18 Winklevoss Ip, Llc Autonomous devices
US20160300223A1 (en) * 2015-04-08 2016-10-13 Portable Data Corporation Protected data transfer across disparate networks
US10740732B2 (en) * 2015-05-20 2020-08-11 Ripple Luxembourg S.A. Resource transfer system
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US10841082B2 (en) * 2015-11-24 2020-11-17 Adi BEN-ARI System and method for blockchain smart contract data privacy
US20170178127A1 (en) * 2015-12-18 2017-06-22 International Business Machines Corporation Proxy system mediated legacy transactions using multi-tenant transaction database
FR3061330B1 (fr) * 2016-12-28 2019-05-24 Bull Sas Systeme et procede pour la creation et la gestion d'autorisations decentralisees pour des objets connectes
KR102115660B1 (ko) * 2018-08-10 2020-05-26 고하준 중재노드를 이용한 블록체인 안전결제 방법 및 그 시스템
US20200151712A1 (en) * 2018-11-08 2020-05-14 The Trustees Of Princeton University System and method for smart contracts

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052128A1 (fr) * 2000-01-13 2001-07-19 Yutaka Yasukura Procede d'interrogation par voie electronique
JP2002049590A (ja) * 2000-08-04 2002-02-15 Hitachi Ltd 電子公証システム
JP2002170058A (ja) * 2000-11-21 2002-06-14 Riccardo Genghini アクティブ識別管理による商取引の自動実行システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"EC - Kessai no Shin Model", PROJECT DESIGN, 1 April 2015 (2015-04-01), pages 42 - 43, XP009508375 *
HIROYUKI TOTAKE: "Bit Coin' wa Honto ni ''Abunai'' noka Kessai System to shite no ''Kaso Tsuka'' no Jitsuryoku", CARDWAVE, vol. 27, no. 3, 1 June 2014 (2014-06-01), pages 20 - 25, XP009508386 *

Cited By (126)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210056070A1 (en) * 2016-02-03 2021-02-25 Luther Systems Us Incorporated System and method for secure management of digital contracts
US11687486B2 (en) * 2016-02-03 2023-06-27 Luther Systems Us Incorporated System and method for secure management of digital contracts
JPWO2018150606A1 (ja) * 2016-02-18 2019-11-07 株式会社野村総合研究所 情報処理装置、情報処理方法およびコンピュータプログラム
WO2018150606A1 (ja) * 2016-02-18 2018-08-23 株式会社野村総合研究所 情報処理装置、情報処理方法およびコンピュータプログラム
JP2019515534A (ja) * 2016-04-29 2019-06-06 エヌチェーン ホールディングス リミテッドNchain Holdings Limited 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
JP7029408B2 (ja) 2016-04-29 2022-03-03 エヌチェーン ホールディングス リミテッド 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
JP7132223B2 (ja) 2017-01-31 2022-09-06 エヌチェーン ホールディングス リミテッド ブロックチェーンを用いて実施される機械実行可能コントラクトの状態を決定する、コンピュータにより実装されるシステム及び方法
JP2020516976A (ja) * 2017-01-31 2020-06-11 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンを用いて実施される機械実行可能コントラクトの状態を決定する、コンピュータにより実装されるシステム及び方法
US11900363B2 (en) 2017-01-31 2024-02-13 Nchain Licensing Ag Computer-implemented system and method for determining the state of a machine executable contract implemented using a blockchain
JP7461423B2 (ja) 2017-01-31 2024-04-03 エヌチェーン ライセンシング アーゲー ブロックチェーンを用いて実施される機械実行可能コントラクトの状態を決定する、コンピュータにより実装されるシステム及び方法
JP2018128823A (ja) * 2017-02-08 2018-08-16 株式会社サテライトオフィス 電子ファイル証明システム
US10855449B2 (en) 2017-02-17 2020-12-01 Advanced New Technologies Co., Ltd. Blockchain system and data storage method and apparatus
JP2020512617A (ja) * 2017-02-17 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited ブロックチェーン・システムならびにデータ記憶方法および装置
JP2020511019A (ja) * 2017-02-24 2020-04-09 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited 鍵確立およびデータ送信の方法および装置
US10797861B2 (en) 2017-02-24 2020-10-06 Alibaba Group Holding Limited Secure data transactions
US10878130B2 (en) 2017-02-24 2020-12-29 Advanced New Technologies Co., Ltd. Secure data transactions
AU2018231022B2 (en) * 2017-03-08 2020-10-08 Advanced New Technologies Co., Ltd. Business processing method and apparatus
CN107341702A (zh) * 2017-03-08 2017-11-10 阿里巴巴集团控股有限公司 一种业务处理的方法及装置
KR102221326B1 (ko) 2017-03-08 2021-03-03 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 비즈니스 프로세싱 방법 및 장치
TWI736705B (zh) * 2017-03-08 2021-08-21 開曼群島商創新先進技術有限公司 業務處理方法和裝置
WO2018165104A1 (en) * 2017-03-08 2018-09-13 Alibaba Group Holding Limited Business processing method and apparatus
KR20190068542A (ko) * 2017-03-08 2019-06-18 알리바바 그룹 홀딩 리미티드 비즈니스 프로세싱 방법 및 장치
JP2020501220A (ja) * 2017-03-08 2020-01-16 アリババ グループ ホウルディング リミテッド 業務処理方法および装置
CN107341702B (zh) * 2017-03-08 2020-06-23 创新先进技术有限公司 一种业务处理的方法及装置
RU2737361C1 (ru) * 2017-03-08 2020-11-27 Алибаба Груп Холдинг Лимитед Способ и устройство бизнес-обработки
US10796379B2 (en) 2017-03-08 2020-10-06 Alibaba Group Holding Limited Handing requests in a consensus network
JP2018160828A (ja) * 2017-03-23 2018-10-11 沖電気工業株式会社 送金元装置、送金先装置、送金方法、受金方法、プログラムおよび送金システム
JP2020512779A (ja) * 2017-03-28 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited トランザクション要求を処理するための方法及び装置
KR20190091484A (ko) * 2017-03-28 2019-08-06 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
US11438165B2 (en) 2017-03-28 2022-09-06 Advanced New Technologies Co., Ltd. Method and apparatus for processing transaction requests
JP7007398B2 (ja) 2017-03-28 2022-01-24 アドバンスド ニュー テクノロジーズ カンパニー リミテッド トランザクション要求を処理するための方法及び装置
US10887112B2 (en) 2017-03-28 2021-01-05 Advanced New Technologies Co., Ltd. Blockchain consensus method and device
KR102208186B1 (ko) 2017-03-28 2021-01-29 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 블록체인 합의 방법 및 디바이스
JP7187532B2 (ja) 2017-03-31 2022-12-12 シングラフィー インコーポレイテッド 電子文書を締結して配送するためのシステム及び方法
JP2020517034A (ja) * 2017-03-31 2020-06-11 シングラフィー インコーポレイテッド 電子文書を締結して配送するためのシステム及び方法
JP7029468B2 (ja) 2017-04-07 2022-03-03 エヌチェーン ホールディングス リミテッド ブロックチェーンを使用した安全なデータレコード配信のための方法及びシステム
JP2022069474A (ja) * 2017-04-07 2022-05-11 エヌチェーン ホールディングス リミテッド ブロックチェーンを使用した安全なデータレコード配信のための方法及びシステム
JP2020516164A (ja) * 2017-04-07 2020-05-28 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンを使用した安全なデータレコード配信のための方法及びシステム
JP6340107B1 (ja) * 2017-04-10 2018-06-06 アイビーシー株式会社 電子証明システム
JP2018182487A (ja) * 2017-04-10 2018-11-15 アイビーシー株式会社 電子証明システム
JP2020517134A (ja) * 2017-04-11 2020-06-11 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーン上の迅速な分散型総意
JP2022044677A (ja) * 2017-04-11 2022-03-17 エヌチェーン ホールディングス リミテッド ブロックチェーン上の迅速な分散型総意
JP7319404B2 (ja) 2017-04-11 2023-08-01 エヌチェーン ライセンシング アーゲー ブロックチェーン上の迅速な分散型総意
JP7012741B2 (ja) 2017-04-11 2022-01-28 エヌチェーン ホールディングス リミテッド ブロックチェーン上の迅速な分散型総意
JP2020512610A (ja) * 2017-05-22 2020-04-23 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited ブロックチェーンサービス受付けおよびコンセンサス方法およびデバイス
KR20190088530A (ko) * 2017-05-31 2019-07-26 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
KR102140414B1 (ko) * 2017-05-31 2020-08-03 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
KR20200086381A (ko) * 2017-05-31 2020-07-16 알리바바 그룹 홀딩 리미티드 블록체인 합의 방법 및 디바이스
US10706023B2 (en) 2017-05-31 2020-07-07 Alibaba Group Holding Limited Blockchain consensus method and device
US11126596B2 (en) 2017-05-31 2021-09-21 Advanced New Technologies Co., Ltd. Blockchain consensus method and device
KR102340223B1 (ko) 2017-05-31 2021-12-16 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 블록체인 합의 방법 및 디바이스
WO2018230648A1 (ja) * 2017-06-16 2018-12-20 株式会社Zweispace Japan ランダム仲介手数料設定機能を有する不動産仲介システム、不動産仲介方法、及び不動産仲介プログラム
JP2019003503A (ja) * 2017-06-16 2019-01-10 株式会社Zweispace Japan ランダム仲介手数料設定機能を有する不動産仲介システム、不動産仲介方法、及び不動産仲介プログラム
JP7154234B6 (ja) 2017-06-20 2022-11-28 エヌチェーン ライセンシング アーゲー ブロックチェーン・ネットワークにおける高速伝搬のための方法及び特殊ネットワーク・ノード
CN110754070A (zh) * 2017-06-20 2020-02-04 区块链控股有限公司 最近交易在区块链网络上的快速传播
JP7154234B2 (ja) 2017-06-20 2022-10-17 エヌチェーン ホールディングス リミテッド ブロックチェーン・ネットワークにおける高速伝搬のための方法及び特殊ネットワーク・ノード
JP2020524434A (ja) * 2017-06-20 2020-08-13 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーン・ネットワークにおける高速伝搬のための方法及び特殊ネットワーク・ノード
CN110754070B (zh) * 2017-06-20 2022-12-06 区块链控股有限公司 最近交易在区块链网络上的快速传播
JP2017195627A (ja) * 2017-06-23 2017-10-26 株式会社エヌ・ティ・ティ・データ 情報処理装置、情報処理方法およびプログラム
KR102144645B1 (ko) 2017-07-14 2020-08-18 알리바바 그룹 홀딩 리미티드 블록체인 기반 데이터 프로세싱 방법 및 디바이스
JP2020510330A (ja) * 2017-07-14 2020-04-02 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited ブロックチェーンベースのデータ処理の方法およびデバイス
KR20190119576A (ko) * 2017-07-14 2019-10-22 알리바바 그룹 홀딩 리미티드 블록체인 기반 데이터 프로세싱 방법 및 디바이스
US11269916B2 (en) 2017-07-14 2022-03-08 Advanced New Technologies Co., Ltd. Blockchain-based data processing method and device
US11947564B2 (en) 2017-07-14 2024-04-02 Advanced New Technologies Co., Ltd. Blockchain-based data processing method and device
JP2018182710A (ja) * 2017-08-10 2018-11-15 アイビーシー株式会社 電子証明システム
US11314727B2 (en) 2017-08-22 2022-04-26 Nec Corporation Blockchain management apparatus, blockchain management method, and program
JP7203828B2 (ja) 2017-08-29 2023-01-13 エヌチェーン ライセンシング アーゲー ブロックチェーンにおけるアンロックトランザクションのアウトプットに対する制約
JP2020532217A (ja) * 2017-08-29 2020-11-05 エヌチェーン ホールディングス リミテッドNchain Holdings Limited ブロックチェーンにおけるアンロックトランザクションのアウトプットに対する制約
JP7282093B2 (ja) 2017-09-05 2023-05-26 シェルターズーム コーポレイション ブロックチェーン式不動産販売および賃貸システム
JP2020532817A (ja) * 2017-09-05 2020-11-12 シェルターズーム コーポレイション ブロックチェーン式不動産販売および賃貸システム
US11037095B2 (en) 2017-09-11 2021-06-15 Accenture Global Solutions Limited Distributed ledger technology for freight system
JP2019073394A (ja) * 2017-09-11 2019-05-16 アクセンチュア グローバル ソリューションズ リミテッド 運送システムのための分散型台帳技術
CN111095254A (zh) * 2017-09-14 2020-05-01 索尼公司 信息处理设备、信息处理方法和程序
WO2019054043A1 (ja) * 2017-09-14 2019-03-21 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
CN111095254B (zh) * 2017-09-14 2023-09-29 索尼公司 信息处理设备、信息处理方法和程序
EP3683710A4 (en) * 2017-09-14 2020-10-14 Sony Corporation INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING PROCESS AND PROGRAM
US11403424B2 (en) 2017-09-14 2022-08-02 Sony Corporation Information processing apparatus and information processing method
WO2019080933A1 (zh) * 2017-10-26 2019-05-02 云图有限公司 一种区块链交易隐私保护方法及系统
CN107911216B (zh) * 2017-10-26 2020-07-14 矩阵元技术(深圳)有限公司 一种区块链交易隐私保护方法及系统
CN107911216A (zh) * 2017-10-26 2018-04-13 矩阵元技术(深圳)有限公司 一种区块链交易隐私保护方法及系统
JP2019145926A (ja) * 2018-02-17 2019-08-29 渡辺 浩志 チップウォレット
JP2019009767A (ja) * 2018-03-01 2019-01-17 株式会社エヌ・ティ・ティ・データ 情報処理装置
KR102113265B1 (ko) * 2018-03-14 2020-05-20 주식회사 아이시티코리아 블록체인 기반 스마트 계약시스템 및 그 방법
KR20190108521A (ko) * 2018-03-14 2019-09-24 주식회사 아이시티코리아 블록체인 기반 스마트 계약시스템 및 그 방법
KR101918446B1 (ko) * 2018-03-16 2019-01-29 윤경민 이중보안 블록체인 인증시스템 및 그 방법
JP2019161580A (ja) * 2018-03-16 2019-09-19 日本電気株式会社 データ送信装置、データ送受信システム、データ受信装置、データ送信方法、プログラム
US11522849B2 (en) 2018-04-09 2022-12-06 Mitsubishi Electric Corporation Authentication system and computer readable medium
US11652647B2 (en) 2018-04-09 2023-05-16 Mitsubishi Electric Corporation Authentication system and computer readable medium
CN108920978A (zh) * 2018-06-26 2018-11-30 赛飞特工程技术集团有限公司 一种基于区块链技术的安全生产信息共享方法
JPWO2020008623A1 (ja) * 2018-07-06 2020-12-17 株式会社日立製作所 リソース融通支援システム、リソース融通支援方法、および、リソース融通支援装置
WO2020008623A1 (ja) * 2018-07-06 2020-01-09 株式会社日立製作所 リソース融通支援システム、リソース融通支援方法、および、リソース融通支援装置
CN109145275A (zh) * 2018-08-07 2019-01-04 广东工业大学 一种区块链电子合同管理和智能生成系统及方法
KR102115660B1 (ko) * 2018-08-10 2020-05-26 고하준 중재노드를 이용한 블록체인 안전결제 방법 및 그 시스템
KR20200018069A (ko) * 2018-08-10 2020-02-19 고하준 중재노드를 이용한 블록체인 안전결제 방법 및 그 시스템
JP2020028052A (ja) * 2018-08-14 2020-02-20 株式会社Skill データ管理方法
WO2020085347A1 (ja) * 2018-10-22 2020-04-30 力 松永 ブロックチェーンを用いた建築工程管理システムおよびそれを利用したデータ取引システム
WO2020085346A1 (ja) * 2018-10-22 2020-04-30 力 松永 ブロックチェーンシステムおよびブロックチェーンシステムを利用したデータ取引システム
JP6743321B1 (ja) * 2018-10-22 2020-08-19 力 松永 ブロックチェーンシステムおよびブロックチェーンシステムを利用したデータ取引システム
JPWO2020085347A1 (ja) * 2018-10-22 2021-02-15 力 松永 ブロックチェーンを用いた建築工程管理システムおよびそれを利用したデータ取引システム
JPWO2020085348A1 (ja) * 2018-10-22 2021-02-15 力 松永 ブロックチェーンを用いた物流管理システムおよびそれを利用したデータ取引システム
WO2020085348A1 (ja) * 2018-10-22 2020-04-30 力 松永 ブロックチェーンを用いた物流管理システムおよびそれを利用したデータ取引システム
JP2019040621A (ja) * 2018-11-07 2019-03-14 株式会社Zweispace Japan 取引仲介システム、取引仲介方法及び取引仲介プログラム
JP7005015B2 (ja) 2018-11-07 2022-01-21 株式会社Zweispace Japan 取引仲介システム、取引仲介方法及び取引仲介プログラム
JP2022509590A (ja) * 2018-11-13 2022-01-21 サイツコード カンパニー リミテッド 位置情報を用いたブロックチェーン方式の契約端末及び方法
KR20200055410A (ko) * 2018-11-13 2020-05-21 주식회사 싸이투코드 디지털 컨텐츠 원본 확인키를 이용한 블록체인 방식의 계약 단말 및 방법
KR102178583B1 (ko) * 2018-11-13 2020-11-13 주식회사 싸이투코드 디지털 컨텐츠 원본 확인키를 이용한 블록체인 방식의 계약 단말 및 방법
JP7243154B2 (ja) 2018-12-04 2023-03-22 セイコーエプソン株式会社 提供装置及び処理システム
JP2020091569A (ja) * 2018-12-04 2020-06-11 セイコーエプソン株式会社 提供装置及び処理システム
JP2020091568A (ja) * 2018-12-04 2020-06-11 セイコーエプソン株式会社 提供装置及び処理システム
JP7243155B2 (ja) 2018-12-04 2023-03-22 セイコーエプソン株式会社 提供装置及び処理システム
US11093628B2 (en) 2019-02-14 2021-08-17 International Business Machines Corporation Cross-domain content-lifecycle management
JP2020150428A (ja) * 2019-03-14 2020-09-17 公立大学法人広島市立大学 ブロックチェーン取引作成プロトコル、及びブロックチェーンアドレス作成方法
JP7291272B2 (ja) 2019-07-11 2023-06-14 フリーサイン株式会社 スマートコントラクトシステム及びプログラム
JP2022125129A (ja) * 2019-07-11 2022-08-26 株式会社サイトビジット スマートコントラクトシステム及びプログラム
JP7157015B2 (ja) 2019-07-11 2022-10-19 フリーサイン株式会社 スマートコントラクトシステム及びプログラム
JP2021015387A (ja) * 2019-07-11 2021-02-12 株式会社サイトビジット スマートコントラクトシステム及びプログラム
WO2021020407A1 (ja) * 2019-08-01 2021-02-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及び、プログラム
JP7422155B2 (ja) 2019-08-01 2024-01-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及び、プログラム
JP2022551417A (ja) * 2019-10-21 2022-12-09 ソン・ミン・ユン 金融取引システムおよびその方法
JP7324941B2 (ja) 2019-10-21 2023-08-10 ソン・ミン・ユン 金融取引システムおよびその方法
WO2021125108A1 (ja) * 2019-12-19 2021-06-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、装置、および、プログラム
JP2022020603A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 取引方式に基づく電子契約証拠保存システム
JP2022020604A (ja) * 2020-07-20 2022-02-01 江蘇傲為控股有限公司 分散型電子契約証明プラットフォーム
CN113612741B (zh) * 2020-12-01 2023-08-08 支付宝(杭州)信息技术有限公司 一种物品流通记录的存证方法、装置、设备和存储介质
CN113612741A (zh) * 2020-12-01 2021-11-05 支付宝(杭州)信息技术有限公司 一种物品流通记录的存证方法、装置、设备和存储介质
WO2023084788A1 (ja) * 2021-11-15 2023-05-19 日本電信電話株式会社 無線通信方法、無線基地局、及び無線通信システム

Also Published As

Publication number Publication date
CN107851253B (zh) 2022-03-04
US10848315B2 (en) 2020-11-24
JP6483827B2 (ja) 2019-03-13
EP3324355A1 (en) 2018-05-23
EP3324355B1 (en) 2020-08-26
CN107851253A (zh) 2018-03-27
EP3324355A4 (en) 2019-03-06
JPWO2017010455A1 (ja) 2018-05-24
US20180205555A1 (en) 2018-07-19

Similar Documents

Publication Publication Date Title
JP6483827B2 (ja) 契約合意方法、合意検証方法、契約合意システム、合意検証装置、契約合意装置、契約合意プログラム及び合意検証プログラム
US11032086B2 (en) Certificate authority master key tracking on distributed ledger
JP6511017B2 (ja) 契約合意方法、合意検証方法、契約合意装置および合意検証装置
KR102139897B1 (ko) 정보 보호를 위한 시스템 및 방법
JP6524347B2 (ja) 情報共有システム
US20200084027A1 (en) Systems and methods for encryption of data on a blockchain
US11483298B2 (en) Information masking using certificate authority
KR101936080B1 (ko) 안전한 스마트 홈 환경을 위한 ksi 기반 인증 및 통신 방법 및 이를 위한 시스템
RU2300845C2 (ru) Способ и системы для обеспечения безопасного распределения данных через сети общего пользования
KR102307574B1 (ko) 블록체인을 기반으로 한 클라우드 데이터 저장 시스템 및 데이터 저장 방법
KR101425552B1 (ko) 제어가능 연결성을 제공하는 그룹서명 시스템 및 방법
JP2019515373A (ja) ブロックチェーンIoT装置のためのオペレーティングシステム
KR20200066258A (ko) 정보 보호를 위한 시스템 및 방법
CN113014392A (zh) 基于区块链的数字证书管理方法及系统、设备、存储介质
CN115176441A (zh) 基于身份的公钥生成协议
JP2020501425A (ja) 情報保護のシステム及び方法
JPWO2020050390A1 (ja) 権利者端末、利用者端末、権利者プログラム、利用者プログラム、コンテンツ利用システムおよびコンテンツ利用方法
CN109146479A (zh) 基于区块链的数据加密方法
WO2021154157A1 (en) Blockchain-based data exchange
CN108876381A (zh) 基于智能合约的安全交易方法
WO2020085378A1 (ja) 権利者端末、利用者端末、権利者プログラム、利用者プログラム、コンテンツ利用システムおよびコンテンツ利用方法
CN109687961B (zh) 基于对称密钥池路由装置的抗量子计算区块链交易方法和系统
Kurbatov et al. Global Digital Identity and Public Key Infrastructure
JP2008186064A (ja) 分散認証システム、分散認証方法、及び分散認証プログラム
CN109146684A (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: 16824435

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017528672

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15743523

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016824435

Country of ref document: EP