JP7021747B2 - 決済システム、決済方法、利用者装置、決済プログラム - Google Patents

決済システム、決済方法、利用者装置、決済プログラム Download PDF

Info

Publication number
JP7021747B2
JP7021747B2 JP2018176397A JP2018176397A JP7021747B2 JP 7021747 B2 JP7021747 B2 JP 7021747B2 JP 2018176397 A JP2018176397 A JP 2018176397A JP 2018176397 A JP2018176397 A JP 2018176397A JP 7021747 B2 JP7021747 B2 JP 7021747B2
Authority
JP
Japan
Prior art keywords
transaction
payment
blockchain
template
service provider
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018176397A
Other languages
English (en)
Other versions
JP2020047104A (ja
Inventor
大喜 渡邊
盛徳 大橋
滋 藤村
篤 中平
浩太 日高
順一 岸上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NATIONAL UNIVERSITY CORPORATION MURORAN INSTITUTE OF TECHNOLOGY
Nippon Telegraph and Telephone Corp
Original Assignee
NATIONAL UNIVERSITY CORPORATION MURORAN INSTITUTE OF TECHNOLOGY
Nippon Telegraph and Telephone Corp
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 NATIONAL UNIVERSITY CORPORATION MURORAN INSTITUTE OF TECHNOLOGY, Nippon Telegraph and Telephone Corp filed Critical NATIONAL UNIVERSITY CORPORATION MURORAN INSTITUTE OF TECHNOLOGY
Priority to JP2018176397A priority Critical patent/JP7021747B2/ja
Priority to US17/275,103 priority patent/US11893583B2/en
Priority to PCT/JP2019/037063 priority patent/WO2020059865A1/ja
Publication of JP2020047104A publication Critical patent/JP2020047104A/ja
Application granted granted Critical
Publication of JP7021747B2 publication Critical patent/JP7021747B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

特許法第３０条第２項適用 ２０１８年７月３０日開催 Ｔｈｅ ２０１８ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｂｌｏｃｋｃｈａｉｎ（Ｂｌｏｃｋｃｈａｉｎ－２０１８） Ｈａｌｉｆａｘ Ｃｏｎｖｅｎｔｉｏｎ Ｃｅｎｔｅｒにて公開した。
本発明は、ブロックチェーンの技術に関し、特に、複数のブロックチェーンを連携させる技術に関する。
中央集権的な管理を必要とせずに、信頼性を担保可能な仕組みがデジタル仮想通貨ビットコインを中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みにおいては、やり取りされる情報の信頼性が分散ネットワーク内の合意形成のプロセスによって担保され、かつ、改ざんや二重使用などの不正を系全体で防ぐことで健全性が保たれる。
ブロックチェーンでは、参加者間の仮想通貨の取引情報（トランザクション）が「ブロック」という単位でまとめられ、各ブロックは数珠つなぎとなって時系列順に管理される。新たなブロックの承認は、Proof of Workなどの分散ネットワークにおける合意アルゴリズムによって形成される。新たなブロックの承認は、ブロック内部に記録された通貨取引が系全体で合意されたことを示す。このブロックチェーンを用いて管理される一連の取引情報の帳簿を「分散台帳」と呼び、ネットワークに参加する各ノード（端末）は同一の分散台帳を保持している。
ところで、ビットコインにおいて、オフチェーン取引と呼ばれる実装上の工夫がなされている。オフチェーン取引とは、全ての取引をブロックチェーンに記録するのではなく、ブロックチェーン外で実施した２者間の取引のうち、最終的な結果のみをブロックチェーンに記録する方式である。非特許文献１に示すように、オフチェーン取引の一方式であるペイメントチャネルでは、２者間の利用者で不完全なトランザクションのやりとりをすることで、仮想的な支払いを実現するチャネルを構築することができる。
bitcoin wiki, "Payment channels", https://en.bitcoin.it/wiki/Payment_channels
「Spillman-style payment channels」、「CLTV-style payment channels」など単方向のペイメントチャネルを応用して、仮想通貨ブロックチェーン用のトランザクションから、電子署名と支払金額を除いた不完全なトランザクションを作成し、この不完全なトランザクションを他のブロックチェーン内で更新していくことにより、仮想通貨ブロックチェーンに接続しなくても他のブロックチェーン上で、仮想的なビットコインの支払いを可能にすることが考えられる。
この方法では、利用者からサービス提供者へサービスの対価の支払いを行うことができるが、逆の方向に（サービス提供者から利用者へ）支払いを行うことはできない。すなわち、支払いのキャンセルが発生した際に、サービス提供者から同じチャネルを用いて利用者に対して返金することができない。
これは、サービス提供者のみが最新の不完全トランザクションから生成したトランザクションを、仮想通貨ブロックチェーンにブロードキャストする権利を持っており、利用者のみが不完全なトランザクションの金額を更新していく形態であることに起因する。例えば利用者が前回更新した支払金額をキャンセルし、前回の支払金額よりも低い支払金額で不完全なトランザクションを更新したとして、最終的にどの時点の不完全なトランザクションの支払金額でトランザクションを生成し、仮想通貨ブロックチェーンにブロードキャストするかは、サービス提供者により決定される。
そのため、サービス提供者が、キャンセルを反映した低い支払金額のトランザクションを仮想通貨ブロックチェーンにブロードキャストするのではなく、キャンセル前の高い支払金額のトランザクションを仮想通貨ブロックチェーンにブロードキャストする可能性は否定できない。
本発明は、上記課題を鑑みてなされたものであり、本発明の目的は、複数のブロックチェーンを効率的に連携し、利用者とサービス提供者とが合意した支払いのキャンセルを、仮想通貨ブロックチェーンに反映させることにある。
上記目的を達成するため、第１の本発明は、第１ブロックチェーンと、第２ブロックチェーンとを連携した決済システムであって、トランザクションの雛形を含む雛形情報トランザクションを、第１ブロックチェーンのネットワークに送信するサービス提供者装置と、第１ブロックチェーンに登録された前記トランザクションの雛形を用いて生成される電子署名と、支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信する利用者装置と、第１ブロックチェーンに含まれるスマートコントラクトと、を備え、前記スマートコントラクトは、前記支払情報トランザクションに含まれる電子署名を、前記支払金額と前記トランザクションの雛形とを用いて検証し、前記サービス提供者装置は、第１ブロックチェーンに登録された前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて決済トランザクションを生成し、第２ブロックチェーンのネットワークに送信し、前記トランザクションの雛型には複数の出力条件が設定され、前記決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となることを特徴とする。
第２の本発明は、第１ブロックチェーンと、第２ブロックチェーンとを連携した決済方法であって、サービス提供者装置は、トランザクションの雛形を含む雛形情報トランザクションを、第１ブロックチェーンのネットワークに送信し、利用者装置は、第１ブロックチェーンに登録された前記トランザクションの雛形を用いて電子署名を生成し、前記電子署名と、支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信し、第１ブロックチェーンに含まれるスマートコントラクトは、前記支払情報トランザクションに含まれる電子署名を、前記支払金額と前記トランザクションの雛形とを用いて検証し、前記サービス提供者装置は、第１ブロックチェーンに登録された前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて決済トランザクションを生成し、第２ブロックチェーンのネットワークに送信し、前記トランザクションの雛型には複数の出力条件が設定され、前記決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となることを特徴とする。
第３の本発明は、第１ブロックチェーンと、第２ブロックチェーンとを連携した決済システムにおける利用者装置であって、所定金額の保証金を送金する送金トランザクションを、第２ブロックチェーンのネットワークに送信する送金トランザクション生成部と、サービス提供者装置により第１ブロックチェーンに登録されたトランザクションの雛形を用いて電子署名を生成し、当該電子署名と支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信する支払トランザクション生成部と、を備え、前記トランザクションの雛型には複数の出力条件が設定され、前記サービス提供者装置により、前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて生成された決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となることを特徴とする。
第４の本発明は、上記利用者装置として、コンピュータを機能させることを特徴とする決済プログラムである。
本発明によれば、複数のブロックチェーンを効率的に連携し、利用者とサービス提供者とが合意した支払いのキャンセルを、仮想通貨ブロックチェーンに反映させることができる。
本発明の実施形態に係る決済システムの全体構成を示す図である。 ブロックチェーンクライアントの構成を示すブロック図である。 「設定」処理を示す概念図である。 送金トランザクションの出力条件を示す図である。 トランザクション雛形のイメージ図である。 トランザクション雛形の出力条件を示すスクリプトの例である。 「支払」処理を示す概念図である。 利用者装置の電子署名の作成処理を示すフローチャートである。 ブリッジングコントラクトの支払い検証処理を示すフローチャートである。 「キャンセル」処理を示す概念図である。 「決済」処理を示す概念図である。 仮想通貨型ブロックチェーンにおけるトランザクションの関係を示す図である。
以下、本発明の実施の形態について、図面を参照して説明する。
図１は、本発明の実施の形態に係る決済システムの全体構成図である。本決済システムは、仮想通貨型ブロックチェーン（第２ブロックチェーン）での仮想通貨による支払いと、スマートコントラクト型ブロックチェーン（第１ブロックチェーン）によるサービス提供とを連携したシステムである。
仮想通貨型ブロックチェーンは、当該ブロックチェーンのＰ２Ｐネットワーク３（以下、「仮想通貨型ネットワーク」）に参加するノードによって共有される分散台帳である。仮想通貨型ブロックチェーンには、仮想通貨の取引履歴が登録される。どこからどこにいくらの仮想通貨を移動するかといった取引情報を記載したトランザクションが仮想通貨型ネットワーク３にブロードキャストされると、そのトランザクションを含むブロックが生成されて、生成されたブロックが仮想通貨型ブロックチェーンの末尾に追加される。
スマートコントラクト型ブロックチェーンは、当該ブロックチェーンのＰ２Ｐネットワーク４（以下、「スマートコントラクト型ネットワーク」）に参加するノードによって共有される分散台帳である。トランザクションがスマートコントラクト型ネットワーク４にブロードキャストされると、そのトランザクションを含むブロックが生成され、生成されたブロックがスマートコントラクト型ブロックチェーンの末尾に追加される。ブロックが追加されると、当該ブロックに含まれるトランザクションを入力として、参加ノードの端末上で事前に登録されたスクリプトコード（即ちスマートコントラクト）が実行され、分散台帳が更新される。このようなスマートコントラクト型ブロックチェーンを実現する基盤として例えば、Ethereum、Hyperledger Fabricなどが挙げられる。
利用者装置１は、スマートコントラクト型ブロックチェーンが提供するサービスの利用者が使用する装置である。利用者装置１は、トランザクション生成部１１と、キャンセル処理部１２と、ブロックチェーンクライアント１３とを備える。
トランザクション生成部１１は、後述する「設定」、「支払」、「決済」および「キャンセル（取消）」の処理（ステップ）において、必要なトランザクションを生成する。生成したトランザクションは、ブロックチェーンクライアント１３を介して、対応するブロックチェーンのネットワーク３、４に送信される。
「設定」処理では、トランザクション生成部１１は、「利用者のアドレスからマルチシグアドレスへのデポジットを行う送金トランザクション」（送金トランザクション）を生成し、仮想通貨型ネットワーク３に送信する（ステップＳ１）。その後、利用者装置１は、「デポジット情報を登録するトランザクション」（保証金情報トランザクション）を生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ２）。
「支払」処理および「キャンセル」処理では、トランザクション生成部１１は、「支払いを示す電子署名と支払金額を登録するトランザクション」（支払情報トランザクション）を生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ３）。
「決済」処理では、トランザクション生成部１１は、サービス提供者がキャンセルの同意を反故にした場合、「決済トランザクションのサービス提供者が受け取るはずの資金を利用者のアドレスに送金するトランザクション」（ペナルティトランザクション）を生成し、仮想通貨型ネットワーク３に送信する（ステップＳ８）。
キャンセル処理部１２は、スマートコントラクト型ブロックチェーンに登録した支払情報トランザクションをキャンセルする場合に、キャンセル要求をサービス提供者装置２に送信する。
図２は、ブロックチェーンクライアント１３の構成を示すブロック図である。本実施形態の利用者装置１は、仮想通貨型ネットワーク３およびスマートコントラクト型ネットワーク４と接続する。このため、ブロックチェーンクライアント１３は、仮想通貨型ブロックチェーンクライアント１４と、スマートコントラクト型ブロックチェーンクライアント１５とを備える。
仮想通貨型ブロックチェーンクライアント１４は、分散台帳１４１、と、ブロックチェーン制御部１４２とを備える。分散台帳１４１には、ブロックチェーン制御部１４２を介して、仮想通貨型ネットワーク３に接続された全ての端末（装置）と緩やかに同期することによって、リアルタイムに近い形で最新状態のブロックチェーンが記憶されている。
ブロックチェーン制御部１４２は、仮想通貨型ネットワーク３に接続された端末と自律分散的に協調してブロックチェーンの系を維持する。具体的には、ブロックチェーン制御部１４２は、分散台帳１４１にアクセスし、分散台帳１４１のブロックチェーンを読み出し、または、更新する。ブロックチェーン制御部１４２は、トランザクションを仮想通貨型ネットワーク３に送信する。
スマートコントラクト型ブロックチェーンクライアント１５は、分散台帳１５１と、ブロックチェーン制御部１５２とを備える。分散台帳１５１およびブロックチェーン制御部１５２は、分散台帳１４１およびブロックチェーン制御部１４２と同様である。
サービス提供者装置２は、スマートコントラクト型ブロックチェーン上でサービスを運営するサービス提供者が使用する装置である。サービス提供者は、利用者からの支払いを受けて何らかのサービス（例えば、デジタルコンテンツの権利登録など）を、利用者に提供する。
サービス提供者装置２は、トランザクション生成部２１と、トランザクション雛形生成部２２と、ブロックチェーンクライアント２３とを備える。
トランザクション生成部２１およびトランザクション雛形生成部２２は、「設定」、「支払」、「キャンセル」および「決済」の処理のうち、「設定」、「キャンセル」および「決済」において必要なトランザクションを生成する。
「設定」処理および「キャンセル」処理では、トランザクション雛形生成部２２は、「トランザクション雛形を登録するトランザクション」（雛形情報トランザクション）を生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ４）。トランザクション雛形については、後述する。
「キャンセル」処理では、トランザクション生成部２１は、トランザクション雛形の出力条件であるハッシュの原像を登録するトランザクション」（原像トランザクション）を生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ９）。
「決済」処理では、トランザクション生成部２１は、「マルチシグアドレスのデポジットを決済するトランザクション」（決済トランザクション）を生成し、仮想通貨型ネットワーク３に送信する（ステップＳ５）。また、トランザクション生成部２１は、「決済を実行して、マルチシグアドレスからサービス提供者へのアドレスへの支払いを確定するトランザクション」（決済実行トランザクション）を生成し、仮想通貨型ネットワーク３に送信する（ステップＳ１０）。
ブロックチェーンクライアント２３は、利用者装置１のブロックチェーンクライアント１３（図２参照）と同様であるため、ここでは説明を省略する。
本実施形態の特徴として、スマートコントラクト型ネットワーク４上には、２つのスマートコントラクトが事前に登録されている。具体的には、スマートコントラクト型ブロックチェーンのプロトコルに従って、ブリッジングコントラクト４１およびサービスコントラクト４２が、当該ネットワーク４に接続された各端末上の分散台帳１５１に登録されている。
ブリッジングコントラクトは、仮想通貨型ブロックチェーンとスマートコントラクト型ブロックチェーンとを連携するスマートコントラクトである。ブリッジングコントラクトは、利用者装置１から支払いに関する情報（電子署名、支払金額）を受け取り、その正当性を検証する。
サービスコントラクトは、ブリッジングコントラクトが支払情報の正当性を確認した後に、サービス提供者が実施するサービス（例えば、コンテンツの権利移転など）を実行するスマートコントラクトである。
どちらのスマートコントラクトも、格納している変数の状態を確認・参照するAPI（Application Programming Interface）を備える。例えば、利用者装置１は、APIを用いて、自身の分散台帳１５１からサービスコントラクトの実行結果を取得する（ステップＳ６）。また、サービス提供者装置２は、APIを用いて、自身の分散台帳からブリッジングコントラクトに登録されたデポジット情報および支払情報を取得する（ステップＳ７）。なお、図１のステップＳ６およびＳ７の破線は、自身の装置に格納された分散台帳を参照する処理を示す。
次に、本実施形態の処理を説明する。本実施形態では、「設定」、「支払」および「決済」の３つの基本処理と、応用的な「キャンセル」の応用処理とを行う。
図３に、「設定」処理の概念図を示す。「設定」処理では、次の「支払」処理のために必要な準備をする。
まず、利用者装置１は、送金トランザクションを生成し、送金トランザクションを仮想通貨型ネットワーク３に送信（ブロードキャスト）する（ステップＳ１１）。送金トランザクションは、利用者のアドレス（ウォレット）から、利用者とサービス提供者とが共同で管理するマルチシグアドレス宛に、所定の金額のデポジット（保証金）を送金するトランザクションである。
マルチシグアドレスは、仮想通貨型ブロックチェーンにおいて、出金の際にトランザクションに対して複数人の電子署名を必要とするアドレスのことである。本実施形態では、利用者の電子署名と、サービス提供者の電子署名とが必要なマルチシグアドレスを用いる。ここでは、例えば、1.0BTCがマルチシグアドレスに送金されたとする。
送金トランザクションが仮想通貨型ネットワーク３に送信されることにより、送金トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックが仮想通貨型ネットワーク３に接続された全ての端末の分散台帳（ブロックチェーン）に反映される。ここでは、仮想通貨型ブロックチェーンにおいて、利用者のアドレスから、マルチシグアドレス宛に、1.0BTCのデポジットが送金されたことが確定する。
本実施形態においては、送金トランザクションには、所定の期間（第１期間）が経過すると、利用者装置１の電子署名のみで、送金トランザクションの利用が可能となる出力条件が設定されている。具体的には、ステップＳ１１の送金トランザクションがブロックチェーンに含まれてから一定の期間が経過すると、利用者のみの電子署名で出金することができる。すなわち、利用者は送金トランザクションを含むブロックがブロックチェーンに登録されてれから、一定の期間が経過した後は、送金トランザクションを次のトランザクションの入力（インプット）として使用することができる。このような時間制限を「タイムロック」と呼ぶ。タイムロックの期間は、例えば、Ｓ１１の送金トランザクションがブロックチェーンに含まれた後に、当該ブロックの後ろに所定の数のブロック（例えば、100ブロック）が接続する時間とする。送金トランザクションにこのような出力条件を設定することで、利用者は、タイムロックの期間が経過した後は、マルチシグアドレスのデポジットを、自身のアドレスに返金（送金）することができるようになる。
このマルチシグアドレスにタイムロックを施すことで、サービス提供者による決済トランザクションが送信されず、サービス提供者との連絡が途絶え、利用者のデポジットがデッドロックされてしまうことを防ぐことができる。例えば100ブロックのタイムロックがかかっていた場合に、100ブロック以上経過すると、利用者は、返金トランザクションを生成し、利用者の電子署名のみでマルチシグアドレスに送金されたデポジットを、利用者のアドレスに送金（返金）できる。
ビットコインでは、トランザクションの出力に対してスクリプトによって出力条件を規定することができる。タイムロックは、トランザクションの属性の１つで、タイムロックで指定した時間または時刻までトランザクションが承認されない（マイナーによるブロックの生成時に不正なトランザクションとして扱われる）ようにするものである。
図４は、本実施形態における、送金トランザクションの出力条件を説明するための図である。図４（ａ）は、送金トランザクションの出力条件の概念図である。図４（ａ）の「User」は利用者を示し、「SP」はサービス提供者を示す。図示する例では、「User」（利用者）の電子署名および「SP」（サービス提供者）の電子署名のマルチシグアドレスであることの条件と、タイムロックで指定した時刻以後（ここでは、100ブロック以後）は、「User」の電子署名のみで利用可能であることを示している。図４（ｂ）は、図４（ａ）に示す出力条件のビットコインにおけるスクリプトの例である。
次に、利用者装置１は、デポジットに関するデポジット情報を登録するためのトランザクション（保証金情報トランザクション）を、スマートコントラクト型ネットワーク４に送信する（ステップＳ１２）。当該トランザクションは、デポジット情報として、少なくとも送金したデポジットの金額を含み、ステップＳ１１の送金トランザクションのID、マルチシグアドレスなどの情報を、さらに含んでも良い。
このトランザクションがスマートコントラクト型ネットワーク４に送信されることにより、当該トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に反映される。これにより、全ての端末において、分散台帳のブリッジングコントラクトが管理するストレージ領域に、デポジット情報が登録される。
サービス提供者装置２は、自身の分散台帳に登録されているブリッジングコントラクトから、利用者装置１が登録したデポジット情報を取得する（ステップＳ１３）。サービス提供者装置２は、取得したデポジット情報を用いて、トランザクションの雛型（トランザクション雛形）を作成する（ステップＳ１４）。ここで、トランザクション雛形は、仮想通貨型ブロックチェーンのトランザクションを変形した、不完全なトランザクションの形式である。具体的には、後述する「決済」処理で「マルチシグアドレスからの送金を示す決済トランザクション」から、「送金額」および「すべての電子署名」の情報を除外したトランザクションである。
図５に、トランザクション雛形のイメージを図示する。図示する例では、入力に必要な「全ての電子署名」および出力に必要な「送金額」は、「null」(空欄)となっている。また、図示する例では、２つの出力（出力１、出力２）を有し、２種類の送金額が記載されている。１つは、基本的にはサービス提供者に送金する金額であり、もう１つは利用者へのお釣として送金する金額である。なお、出力１の宛先には、次に説明する出力条件（条件１、条件２）を指定するスクリプトのハッシュ値が設定されている。
また、ステップＳ１１では、マルチシグアドレスには1.0BTCがデポジットされている。次の「支払」処理では、利用者装置１は、このデポジットの範囲（1.0BTC）で、トランザクション雛形の「送金額（すなわち支払金額とお釣）」と「電子署名」とを更新して支払情報トランザクションを生成し、ブリッジングコントラクトに提出することになる。
本実施形態においては、トランザクション雛形の出力１には複数の出力条件が設定され、後述する「決済」処理の決済トランザクションは、複数の出力条件のいずれかを満たした場合に利用可能となる。ここでは、以下の２つの出力条件が課せられている。
図６に、条件１、２の出力条件を表したビットコインのスクリプトの例を示す。
条件１：トランザクション雛形（不完全なトランザクション）の出力は、タイムロックによって制限される。サービス提供者装置２は、指定されたタイムロックの一定の期間（第２期間）が経過すると、当該トランザクション雛形を用いて生成した決済トランザクションを、次のトランザクションの入力（インプット）として使用することができる。なお、タイムロックの一定の期間は、図６に示すスクリプトに設定され、Ｓ１５でトランザクション雛形とともに、当該スクリプトはスマートコントラクト型ネットワーク４に送信され、全ての端末の分散台帳に反映される。利用者は、自身の分散台帳に登録されたスクリプトを見てタイムロックの時間を確認することができる。図６に示す例では、一定の期間は、送金トランザクション（図２：Ｓ１１）がブロックチェーンに含まれた後に、110個のブロックがその後ろに接続する時間である。
条件２：トランザクション雛形の出力は、ハッシュロックによって制限される。利用者は、ハッシュの原像（元のデータ）と、その署名とを使用して、スクリプトのロックを解除することができる。ここで「ハッシュロック」とは、指定されたハッシュに対応する原像を次のトランザクションの入力において提出することで、トランザクション雛形を用いて生成される決済トランザクションが使用可能になる条件である。
本実施形態では、サービス提供者装置２は、トランザクション雛形を生成する際に任意の原像を生成し、当該原像のハッシュをスクリプトに設定する。ただし、設定の段階では原像は公開しない。条件１で述べたように、スクリプトはスマートコントラクト型ネットワーク４を介して利用者にも共有されているため、利用者装置１がハッシュの原像を取得できれば、本スクリプトと、原像と、利用者の署名とを合わせて決済トランザクションが使用可能となる。
条件１および条件２は、トランザクション雛形が「決済」処理を経て、完全な決済トランザクションとして仮想通貨型ブロックチェーンに記録された後に機能する（後述する「決済」処理を参照）。条件１または条件２のどちらか一方の条件が満たされた場合にのみ、決済トランザクションは使用可能になる。
条件１は、サービス提供者装置２が、指定したタイムロック後にのみ、マルチシグアドレスからの送金を自身のアドレス（ウォレット）に移すことができることを示している。具体的には、「決済」処理で、完全なトランザクションである決済トランザクションとしてブロードキャストされ、当該決済トランザクションがブロックチェーンに含まれた後に、一定数のブロックが後ろに接続する時間分（例えば110ブロック）経過後に、マルチシグアドレスから送金された資金のうち、自身が受け取る資金（図５の出力１の支払金額）を自由に移動できるようになる。
もし、この待機時間の間に、サービス提供者が裏切り行為（「キャンセル処理」を参照）を行った場合、利用者は、条件２でマルチシグアドレスから送金された資金を全て（出力１・出力２ともに）取り戻す、すなわち、自身のアドレスに送金（返金）することができる。
条件２では、スクリプトに指定されたハッシュロックに対応する原像を、当該決済トランザクションに後続するトランザクションの入力に指定した場合、当該決済トランザクションは、利用者の電子署名のみで利用可能となる。この条件２は、キャンセルを成立させるために、サービス提供者に対するペナルティとして設定されている。詳細は、後述する「キャンセル」処理で説明する。
なお、条件１または条件２の実行順序は、(1)サービス提供者によって「キャンセルの合意」に対する裏切り行為が行われた場合、条件１のタイムロックの経過前に利用者が条件２を用いて、決済トランザクションでサービス提供者が入手するはずの資金（出力１）を、利用者の署名のみで自身のアドレスに送金する、(2) サービス提供者による裏切り行為が行われなかった場合、条件１のタイムロックの経過後に、サービス提供者が条件１を用いて決済トランザクションでサービス提供者が入手するはずの資金（出力１）を自身のアドレスに送金する、という順番になる。
そして、サービス提供者装置２は、仮想通貨型ブロックチェーンにおいて、ステップＳ１１で送信された送金トランザクションを含むブロックが確定するのに十分な時間を経た上で、ステップＳ１４で生成したトランザクション雛形を含む雛形情報トランザクションを、スマートコントラクト型ネットワーク４に送信する（ステップＳ１５）。
これにより、当該雛形情報トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に反映される。ここでは、トランザクション雛形は、スマートコントラクト型ブロックチェーンのブリッジングコントラクトに登録される。
この時、サービス提供者装置２は、雛形情報トランザクションに、トランザクション雛形の他に、次の支払処理で行われる電子署名の検証に必要な情報（例えば、利用者装置１の仮想通貨のアドレスに関する公開鍵）と、決済処理の検証に必要な情報（例えば、図６に示すスクリプト）とを含めて送信し、ブリッジングコントラクトに登録してもよい。あるいは、ブリッジングコントラクトが、事前に電子署名の検証に必要な情報、および、決済処理の検証に必要な情報を保持していても良い。
次に、「支払」処理について説明する。
図７に、「支払」処理の概念図を示す。図７では、支払金額を更新しながら３回の支払処理を行う例を示す。
まず、１回目の支払いにおいて、利用者装置１は、「設定」処理でサービス提供者装置２が登録したトランザクション雛形を、自身の分散台帳のブリッジングコントラクトから取得する（ステップＳ２１）。そして、利用者装置１は、トランザクション雛形から電子署名１を作成する（ステップＳ２２）。
図８は、利用者装置１のステップＳ２１およびステップＳ２２の処理を示すフローチャートである。利用者装置１は、前述のとおり、ブリッジングコントラクトからトランザクション雛形を取得する（ステップＳ２１）。そして、利用者装置１は、取得したトランザクション雛形に支払金額１（ここでは、0.3BTCとする）を設定し、署名前トランザクション１を生成する（ステップＳ２２１）。そして、利用者装置１は、署名前トランザクション１に対して、マルチシグアドレスに対応する利用者の秘密鍵で電子署名１を生成する（ステップＳ２２３）。
図７に戻り、利用者装置１は、支払金額１と電子署名１とを含み、これらの情報をブリッジングコントラクトに登録するためのトランザクション（支払情報トランザクション）を生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ２３）。これにより、当該トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に反映される。ここでは、スマートコントラクト型ブロックチェーンにおいて、支払金額１と電子署名１とが各端末のブリッジングコントラクトに登録される。
本トランザクションを含むブロックが分散台帳に登録される時、全ての端末上で、ブリッジングコントラクトによる所定の処理（支払い検証）が実行される（ステップＳ２４）。
図９は、ブリッジングコントラクトが行うステップＳ２４の検証処理を示すフローチャートである。まず、ブリッジングコントラクトは、ステップＳ２３で利用者装置１が送信した「電子署名１と支払金額１（0.3BTC）とを登録するトランザクション」を取得する（ステップＳ２４１）。ブリッジングコントラクトは、取得したトランザクションの支払金額１と、その支払手数料（仮想通貨型ブロックチェーンにおいてマイナーに支払う手数料など）とを合わせた金額がデポジット金額（1.0BTC)を超えていないかを検証する（ステップＳ２４２）。
超えていないことが検証された場合（正当性が検証された場合）、ブリッジングコントラクトは、支払情報トランザクションに含まれる電子署名１を、支払金額とトランザクションの雛形とを用いて検証する。具体的には、ブリッジングコントラクトは、設定処理（図３参照）で事前にブリッジングコントラクトに登録されたトランザクション雛形に、支払金額１を設定して署名前トランザクションを作成する（ステップＳ２４３）。支払金額１を設定する際には、利用者へのお釣となる送金額（1.0BTC-0.3BTC-支払手数料）もブリッジングコントラクト上で適切に計算され、設定される。次に、ブリッジングコントラクトは、作成した署名前トランザクションを用いて、電子署名１を検証する（ステップＳ２４４）。
この電子署名の検証方法として、ビットコインなどで用いられているECDSA方式の電子署名では、署名前のメッセージと電子署名とを用いて、検証用の公開鍵を復元できることが知られている。
そこで、ブリッジングコントラクトは、例えば図３のステップＳ１５などで事前に登録しておいた署名検証に必要な情報（公開鍵、公開鍵のハッシュなど）を利用して、ステップＳ２４１で取得したトランザクションの電子署名１の正当性を検証する。すなわち、ブリッジングコントラクトは、生成した署名前トランザクションと、利用者装置１から送信された電子署名１とを用いて公開鍵を復元し、復元した公開鍵と事前に登録しておいた公開鍵とが一致する場合、電子署名１は正当であると検証する。一方、復元した公開鍵と事前に登録しておいた公開鍵とが一致しない場合、ブリッジングコントラクトは、電子署名１は正当でないと検証する。
そして、ブリッジングコントラクトは、電子署名１の正当性が検証された場合、サービスコントラクトを呼び出す（ステップＳ２４５）。
図７に戻り、電子署名１が正当であると検証された場合、ブリッジングコントラクトは、その支払金額１に応じたサービスを実行するためにサービスコントラクトを呼び出す。（ステップＳ２５）。具体的には、ブリッジングコントラクトは、支払金額１などをパラメータとして、サービスコントコントラクトのメソッドを呼び出す（ステップＳ２５）。これにより、サービスコントラクトは、支払金額に応じた所定のサービス（例えばデジタルコンテンツの権利移転など）を実行する。
図７では、利用者装置１は、ステップＳ２１～Ｓ２５の支払処理を３回の実施し、その都度、サービスコントラクトによるサービスが実施される。２回目の支払処理（ステップＳ３１～Ｓ３５）および３回目の支払処理（ステップＳ３１～Ｓ３５）は、１回目の支払処理（ステップＳ２１～Ｓ２５）と同様である。
ただし、支払金額は、支払金額１(0.3BTC)＜支払金額２(0.6BTC)＜支払金額３(0．9BTC)の関係が成り立ち、最後の支払金額(0.9BTC)が最終的な決済金額となる。ここで、２回目以降の支払金額は、前回の支払金額に今回のサービス分の支払金額を加算したものである。図７に示す例では、利用者装置１は、３回の支払いを行い、その都度0.3BTC分のサービスが提供されることを示している。
なお、図７では、利用者装置１は、３回に渡っての支払情報トランザクションを、スマートコントラクト型ネットワーク４にブロードキャストしているが（ステップＳ２３、Ｓ３３、Ｓ４３）、もし、３回目の支払いで、下記で説明する「決済」処理を行なった場合、サービス提供者装置２は、１回目と２回目の支払情報を用いて決済を行うことはできない。例え１回目と２回目の支払情報を用いて決済トランザクションを生成し、ブロードキャストしたとしても、仮想通貨型ブロックチェーンの合意検証のプロセスで弾かれ、ネットワーク的に無効となる。
ここまでで、「設定」および「支払い」の処理について説明した。ここで、通常の支払いとは別のフローとなる「支払い」の「キャンセル」処理について説明する。「キャンセル」処理では、「支払い」処理とは異なり、先に登録した支払金額よりも、低い金額を登録することが可能である。キャンセルは以前の支払いを無効にするために、新たなトランザクション雛形を登録する必要がある。
図１０に、「キャンセル」処理の概要を示す。図１０に示す処理が行われることで、利用者およびサービス提供者との間で、「支払の」処理のキャンセルが合意されたと見なされる。
利用者装置１は、サービス提供者装置２にキャンセル要求を送信する（ステップＳ７１）。
サービス提供者装置２は、キャンセル要求を受信すると、新しいトランザクション雛形（他のトランザクション雛形）を生成する（ステップＳ７２）。具体的には、サービス提供者装置２は、新しい原像を生成し、当該原像のハッシュを用いて新しいトランザクション雛形および出力条件のスクリプトを生成する。新たなトランザクション雛形および出力条件のスクリプトは、「設定」処理のトランザクション雛形（図３：Ｓ１４）および出力条件のスクリプト（図６）と、原像のハッシュのみが異なり、その他は同様である。なお、原像は、特に指定しないが、簡単に推測できないものである必要がある。
サービス提供者装置２は、ステップＳ７２で生成したトランザクション雛形を含む雛形情報トランザクションを、スマートコントラクト型ネットワーク４に送信する（ステップＳ７３）。これにより、当該雛形情報トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に反映される。ここでは、新たなトランザクション雛形は、スマートコントラクト型ブロックチェーンのブリッジングコントラクトに登録される。
この時、サービス提供者装置２は、雛形情報トランザクションに、新たなトランザクション雛形の他に、キャンセル処理で行われる電子署名の検証に必要な情報（例えば、利用者装置１の仮想通貨のアドレスに関する公開鍵）と、決済処理の検証に必要な情報（例えば、出力条件を示すスクリプト）とを含めて送信し、ブリッジングコントラクトに登録してもよい。あるいは、ブリッジングコントラクトが、事前に電子署名の検証に必要な情報、および、決済処理の検証に必要な情報を保持していても良い。
利用者装置１は、新しいトランザクション雛形を、自身の分散台帳のブリッジングコントラクトから取得する（ステップＳ７４）。そして、利用者装置１は、図７のＳ２２およびＳ２３と同様に、新たな電子署名を生成し、新たなトランザクション雛形を用いて新たな支払情報（支払金額、電子署名）をブリッジングコントラクトに登録するための支払情報トランザクション（他の支払情報トランザクション）をスマートコントラクト型ネットワーク４に送信する（ステップＳ７５、Ｓ７６）。これにより、支払情報トランザクションを含むブロックが生成され、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に登録される。新たな支払情報の支払金額は、「支払処理」の最新の支払情報トランザクションの支払金額よりも低い金額である。
新たな支払情報トランザクションを含むブロックが分散台帳に登録されると、全ての端末上で、ブリッジングコントラクトによる支払い検証が実行される（ステップＳ７７）。すなわち、ブリッジングコントラクトは、新たな支払情報トランザクションの支払金額および電子証明を検証する。ブリッジングコントラクトは、図７のＳ２４と同様の支払い検証を行う。さらに、ブリッジングコントラクトは、新たな支払金額が、前回の支払情報トランザクションの支払金額よりも低い金額であるか否かを検証し、低い金額の場合、新たな支払金額は正当であると判断する。
サービス提供者装置２は、自身の分散台帳から新たな支払情報トランザクションを取得し、当該トランザクションの支払金額をサービス提供者に提示する。サービス提供者は、支払金額を確認して、利用者が要求したキャンセルに合意するか否かを判断する。サービス提供者は、利用者のキャンセル要求が不当なものである場合など、利用者からのキャンセル要求に合意しないと判断することもできる。合意しない場合は、サービス提供者装置２は、次のステップＳ７９を行わない。
サービス提供者がキャンセルに合意する場合、サービス提供者装置２は、古いトランザクション雛型（図３：Ｓ１５）の条件２で設定したハッシュの元となる原像を、ブリッジングコントラクトに登録するための原像トランザクションを生成し、スマートコントラクト型ネットワーク４に送信する（ステップＳ７９）。これにより、原像トランザクションを含むブロックが生成され、当該ブロックがスマートコントラクト型ネットワーク４に接続された全ての端末の分散台帳に登録される。これにより、古いトランザクション雛型における条件２のハッシュの原像が利用者装置１に共有される。本実施形態では、サービス提供者装置２が原像トランザクションを送信することで、サービス提供者が、キャンセルに合意したとみなされる。
原像トランザクションを含むブロックが各端末の分散台帳に登録されると、全ての端末上で、ブリッジングコントラクトによるサービスの取り消し処理が実行される（ステップＳ８０）。ブリッジングコントラクトは、Ｓ７４の支払金額に応じて、既に実行されたサービスを取り消すためにサービスコントラクトを呼び出す。具体的には、ブリッジングコントラクトは、所定の金額（例えば、前回の支払金額と今回お支払金額との差分金額）をパラメータとして、サービスコントコントラクトのメソッドを呼び出す。これにより、サービスコントラクトは、差分金額に応じた所定のサービスを取り消す。
最後に「決済」処理について説明する。
図１１は、「決済」処理を示す図である。サービス提供者装置２は、任意のタイミングで支払いを締めて、仮想通貨型ブロックチェーン上に支払いを反映させる。まず、サービス提供者装置２は、最終的な支払金額と、電子署名と、トランザクション雛形とを、自身の分散台帳（ブリッジングコントラクト）から取得する（ステップＳ５１）。
ここで、最終的な支払金額と、電子署名と、トランザクション雛形とは、キャンセル処理が行われていない場合は、図７の支払金額３と、電子署名３と、トランザクション雛形であり、キャンセル処理が行われた場合は、図１０の新たな支払金額と、電子署名と、トランザクション雛形である。
そして、サービス提供者装置２は、トランザクション雛形にＳ５１で取得した支払金額と電子署名とを設定して決済トランザクションを生成する。この時点の決済トランザクションは、「利用者装置１のみの電子署名が付与された、マルチシグアドレスから送金するトランザクション」である。すなわち、この時点の決済トランザクションは、サービス提供者装置２の電子署名がないため、有効なトランザクションではない。
そこで、サービス提供者装置２は、マルチシグアドレスからの送金を有効にするために、決済トランザクションに、自身の端末上でマルチシグに対応する自身の秘密鍵で電子署名を付与し、仮想通貨型ブロックチェーン上で有効となる決済トランザクションを作成する（ステップＳ５２）。署名後の決済トランザクションは、利用者とサービス提供者の２つの電子署名を持つため仮想通貨型ブロックチェーン上で有効となる。
サービス提供者装置２は、署名後の決済トランザクションを仮想通貨型ネットワーク３に送信する（ステップＳ５３）。サービス提供者は、送金トランザクション（図３のＳ１１）の出力条件により、当該送金トランザクションのブロックが分散台帳に登録されてから100ブロックが接続されるまでの前に、決済トランザクションを送信する必要がある。
決済トランザクションが仮想通貨型ネットワーク３に送信されることにより、決済トランザクションを含むブロックが生成され、端末間のゆるやかな同期により、当該ブロックが仮想通貨型ネットワーク３に接続された全ての端末の分散台帳に反映される。
これにより、決済トランザクションの出力２のお釣りは、利用者のアドレスに送金される。一方、決済トランザクションの出力１の支払金額については、仮想通貨型ブロックチェーンにおいて、決済トランザクション（トランザクション雛形）の出力１の宛先で設定されたハッシュが示すスクリプトの条件１、２のいずれかを満たした場合、当該決済トランザクションの使用が可能となる。
これにより、本実施形態では、サービス提供者に支払いのキャンセルを履行させる。すなわち、本実施形態では、サービス提供者が原像トランザクションを送信することで、利用者が要求するキャンセルに合意したにもかかわらず、それを反故にする取引を防止することができる。
具体的には、サービス提供者がマルチシグアドレスに送金されたデポジットから所定の支払金額を得ることができるのは、条件１のタイムロックで指定された期間の経過後である。図示する例では、送金トランザクション（図３のＳ１１）のブロックが分散台帳に登録されてから110ブロックが接続された期間（T2）の経過後である。すなわち、サービス提供者装置２は、決済トランザクションに指定された支払金額を自身のアドレスに送金するための決済実行トランザクションは、条件１のタイムロック期間経過後（T2）となる（ステップＳ５６）。
また、サービス提供者装置２は、キャンセルに合意した場合、図１０のステップＳ７９において、古いトランザクション雛形で使用したハッシュの原像をブリッジングコントラクトの分散台帳に登録することで利用者に公開している。そのため、サービス提供者が、キャンセルの合意を反故にすることで利用者を裏切り、キャンセルしたはずの古いトランザクション雛形を用いて決済トランザクションを送信した場合であっても、利用者は、公開されたハッシュの原像を用いることで、条件２のハッシュロックの解除することができる。
この場合、利用者は、条件１のタイムロックの期間（T2）が経過する前に、決済トランザクションで指定された出力１の支払金額を自身のアドレスに送金するためのペナルティトランザクションを送信し、自身のアドレスにサービス提供者に支払われるはずの支払金額を取り戻すことができる（ステップＳ５５）。なお、決済トランザクションの出力２のお釣りは、決済トランザクション（Ｓ５３）がブロックチェーンに登録されることにより、利用者のアドレスに送金される。
このように本実施形態では、サービス提供者がキャンセルに合意した場合、条件２による利用者のペナルティトランザクションがペナルティ（罰金）として機能するため、サービス提供者は利用者を裏切るような行動が取り難くなる。すなわち、決済トランザクション（トランザクション雛形）に出力条件を課すことで、利用者よりも前に、サービス提供者が決済トランザクションの出力１の支払金額を自身のアドレスに送金することは難しい。
以下に、キャンセル処理が行われていない場合と、キャンセル処理が行われている場合とに分けて、Ｓ５３以降の処理を説明する。
＜キャンセル処理が行われていない場合＞
サービス提供者装置２は、図７の支払金額３と、電子署名３と、トランザクション雛形とを用いて生成した決済トランザクションを仮想通貨型ネットワーク３に送信する（ステップＳ５３）。サービス提供者装置２は、送金トランザクション（図３のＳ１１）の出力条件で指定された期間（T1）までの間に、決済トランザクションを送信する。
そして、サービス提供者装置２は、条件１のタイムロックで指定された期間（T2）の経過後に、決済トランザクションに指定された支払金額（出力１）を自身のアドレスに送金するための決済実行トランザクションを、仮想通貨型ネットワーク３に送信する（ステップＳ５６）。
これにより、マルチシグアドレスから、サービス提供者のアドレス宛に、0.9BTCの支払金額３が送金され、決済が完了する。
なお、サービス提供者装置２が決済トランザクションを仮想通貨型ネットワーク３に送信するまで（ステップＳ５３）、すなわちサービス提供者が支払いを締めるまで、利用者装置１は、図５に示すｎ回目の支払処理を行い、支払金額を書き換えて、追加のサービス提供を受けることができる。
＜キャンセル処理が行われている場合＞
サービス提供者装置２は、原則として、キャンセル処理で登録された新たな支払金額と、電子署名と、トランザクション雛形とを用いて生成した決済トランザクションを仮想通貨型ネットワーク３に送信する（ステップＳ５３）。サービス提供者装置２は、送金トランザクション（図３のＳ１１）の出力条件で指定された期間（T1）までの間に、決済トランザクションを送信する。
ここで、利用者は、サービス提供者がペナルティを承知で利用者を裏切る（キャンセルを反故にする）ことに備えて、仮想通貨型ブロックチェーンに決済トランザクションが含まれるかどうかを監視し、決済トランザクションを検証する（Ｓ５４）。具体的には、利用者装置１は、自身の分散台帳を参照して、決済トランザクションが存在するか否か、また、決済トランザクションが存在する場合は、当該決済トランザクションの支払金額が、キャンセル処理で送信した支払金額であるか否かを検証する。
決済トランザクションの支払金額がキャンセル処理で送信した支払金額でない場合（検証ＮＧの場合）、利用者装置１は、条件１の期間（T2）が経過する前に、決済トランザクションの出力１で指定された支払金額を自身のアドレスに送金するためのペナルティトランザクションを仮想通貨型ネットワーク３に送信する（ステップＳ５５）。これにより、利用者は、決済トランザクションでサービス提供者に支払われるはずの支払金額（出力１）を、ペナルティとして自身のアドレスに戻すことができる。なお、決済トランザクションが送信されない場合、利用者装置１は、送金トランザクションでマルチシグアドレスに対して送金したデポジットを自身のアドレスに返金するための返金トランザクションを送信する。
決済トランザクションの支払金額がキャンセル処理で送信した支払金額の場合（検証ＯＫの場合）、利用者装置１はＳ５５のペナルティトランザクションを送信しない。これにより、サービス提供者装置２は、条件１の期間（T2）の経過後に、決済実行トランザクションを送信する（Ｓ５６）。これにより、サービス提供者は、決済トランザクションの出力１に指定された、キャンセル処理で合意した支払金額を自身のアドレスに送金することができる。
図１２に、仮想通貨型ブロックチェーンにおけるトランザクションの関係を示す。送金トランザクション１２１は、図３のＳ１１で説明したように、利用者が1.0BTCのデポジットをマルチシグアドレスに送金するためのトランザクションである。この送金トランザクションの出力条件（例えば100ブロックのタイムロック）の間に、決済トランザクション１２３（図１１：Ｓ５３）が送信されない場合、利用者は、返金トランザクション１２２を送信し、送金トランザクションで送金した1.0BTCのデポジットを自身のアドレスに取り戻す。これにより、サービス提供者との連絡が途絶え、利用者のデポジットがデッドロックされてしまうことを防ぐことができる。
一方、送金トランザクションの出力条件の間に決済トランザクション１２３（図１１：Ｓ５３）が送信された場合であって、サービス提供者がキャンセル処理の合意を反故にした場合、利用者は、決済トランザクション（出力１）の条件２によりペナルティトランザクション１２４（図１１：Ｓ５５）を送信し、決済トランザクションの出力１に設定された支払金額（0.7BTC）を、自身（利用者）のアドレスに送金する。
また、決済トランザクション１２３が送信された場合であって、キャンセル処理が行われていない場合または合意したキャンセル処理が正しく履行されている場合、サービス提供者は、決済トランザクション（出力１）の条件１により決済実行トランザクション１２５（図１１：Ｓ５６）を送信し、決済トランザクションの出力１に設定された支払金額（0.7BTC）を、自身（サービス提供者）のアドレスに送金する。
なお、決済トランザクションの出力２のお釣り（0.3BTC）は、決済トランザクションがブロックチェーンに登録されると、利用者のアドレスへ送金される。
本実施形態では、送金トランザクションのタイムロックの期間（T1）と、決済トランザクション（トランザクション雛形）の条件１のタイムロックの期間（T2）とを調整することで、利用者端末１の仮想通貨型ブロックチェーンへの監視コストを下げる。具体的には、タイムロックの期間をT1＜T2とすることで、送信トランザクションへのタイムロックよりも、決済トランザクションへのタイムロックが必ず長くなるように設定する。これにより、サービス提供者は、T1のタイムロックが切れる前に決済トランザクションの送信（ステップＳ５３）を行わなければならず、また、決済トランザクションの送信を行ったとしても、T1を経過しT2までは、決済トランザクションを利用（出力１の支払金額を自身のアドレスに送金）することができない。
したがって、トランザクション雛形とともに登録される条件１のT2が、T1より長いことが保証できれば、利用者装置１は、少なくともT１までの時間は、サービス提供者装置２の決済トランザクションを監視する必要はなく、T1からT2までの間に決済トランザクションを確認すればよい。より具体的には、利用者装置１はT1からT2の間で仮想通貨型ネットワーク３に接続し、または、自身の分散台帳を参照し、「決済トランザクションが既にブロックに含まれているか否か」、「決済トランザクションが正当か否か」を確認する（Ｓ５４）。したがって、T1とT2の期間が設定されていることにより、利用者装置が仮想通貨型ブロックチェーンに接続する期間が限定され、常時ブロックチェーンを監視する必要性がなくなる。
本実施形態では、T1＜T2であることを、スマートコントラクトを用いて保証する。具体的には、トランザクション雛形を登録する際に（図３のステップＳ１５、および、図１０のステップＳ７３）、ブリッジングコントラクトは、送金トランザクションのタイムロックの期間（T1）よりも、トランザクション雛形のタイムロックの期間（T2）が長いか否かを検証し、T1＜T2を満たしていない場合は、エラーメッセージをサービス提供者装置２に送信する。なお、T1については、図５に示すように、トランザクション雛形の入力（スクリプト）に設定されている。
以上説明した本実施形態では、トランザクションの雛型（出力１）には複数の出力条件が設定され、決済トランザクションは、複数の出力条件のいずれかを満たした場合に、利用可能となる。これにより、本実施形態では、複数のブロックチェーンを効率的に連携し、利用者とサービス提供者とが合意した支払いのキャンセルを、仮想通貨ブロックチェーンに反映させることができる。具体的には、サービス提供者が、キャンセルの合意を反故にすることで利用者を裏切り、キャンセルしたはずの古いトランザクション雛形を用いて決済トランザクションを送信した場合であっても、利用者は、キャンセル処理でサービス提供者が公開したハッシュの原像を用いることで、条件２のハッシュロックの解除することができる。すなわち、利用者は、条件１のタイムロックの期間が経過する前に、決済トランザクションで指定された支払金額を自身のアドレスに送金するためのペナルティトランザクションを送信し、自身のアドレスにデポジットを取り戻すことができる。
このように本実施形態では、トランザクション雛形に出力条件を課すことで、サービス提供者がキャンセルに合意した場合、条件２による利用者のペナルティトランザクションがペナルティとして機能し、また、条件１のタイムロックの制約があるため、サービス提供者が、利用者よりも前に決済トランザクションの支払金額を自身のアドレスに送金することは難しい。したがって、サービス提供者は利用者を裏切るような行動が取り難くなる。
また、本実施形態では、図１０に示すキャンセル処理を行うことで、利用者は、送信済みの支払情報トランザクションをキャンセルすることができる。また、サービス提供者が原像トランザクションを送信することで、利用者は、サービス提供者がキャンセルの合意したことを確認することができる。
また、本実施形態では、利用者装置は、マルチシグアドレスへ所定金額の保証金を送金する送金トランザクションを、仮想通貨ブロックチェーンのネットワークに送信し、送金トランザクションには、第１期間（T1）が経過すると利用者装置の電子署名のみで、送金トランザクションの利用が可能となる出力条件が設定されている。これにより、本実施形態では、サービス提供者との連絡が途絶え、利用者のデポジットがデッドロックされてしまうことを防ぐことができる。
また、本実施形態では、トランザクション雛形の複数の出力条件には、決済トランザクションが第２期間の経過後に利用可能となるタイムロックが含まれ、スマートコントラクトは、第１期間よりも、第２期間が長いか否かを検証する。これにより、本実施形態では、利用者が仮想通貨型ブロックチェーン（仮想通貨型ネットワーク３または自身の分散台帳）を確認する期間が限定され、常時ブロックチェーンに接続し決済トランザクション等を監視する必要がなく、運用コストが低減する。
また、本実施形態では、「支払」処理においてサービス提供者装置２は介在せず、支払の検証からサービスの提供までをスマートコントラクト型ブロックチェーン上で全て実行する。これにより、本実施形態では、サービス提供者装置２は、支払いの検証からサービスの提供まで、スマートコントラクト型ブロックチェーンへの接続を必要としない。すなわち、サービス提供者装置２は、スマートコントラクト型ブロックチェーンを常に監視する必要がないため、運用コストが低減する。
また、本実施形態では、支払の検証からサービスの提供までの間、サービス提供者装置２が仲介しないため、サービス提供者装置２の故障またはサービス提供者の不正により、一連の支払処理が正しく実行されない状況を回避することができる。
また、本実施形態では、支払の検証からサービスの提供を、スマートコントラクト型ブロックチェーンのブリッジングコントラクトおよびサービスコントラクトが、自律的に実行するため、より透明性が高く監査可能なシステムを構築することができる。
また、本実施形態では、トランザクション雛形をスマートコントラクト型ブロックチェーンに登録し、利用者装置１およびサービス提供者装置２は、自身の分散台帳からトランザクション雛形を取得して利用するため、トランザクションの送信数を削減し、ブロックの肥大化を抑制し、また、ブロックの計算コストも削減することができる。
また、本実施形態では、利用者の電子署名とサービス提供者の電子署名とが必要なマルチシグアドレスを利用したトランザクションを使用する。これにより、利用者装置１が、勝手に決済トランザクションを仮想通貨型ブロックチェーンに登録し、仮想通貨を使用することを防止することができる。すなわち、本実施形態では、サービス提供者装置２のみが、決済トランザクションに自身の電子署名を付与して仮想通貨型ブロックチェーンに登録することができる。すなわち、サービス提供者装置２が、決済のタイミングを制御することができ、任意のタイミングで決済を確定させることができる。
なお、上記説明した利用者装置１およびサービス提供者装置２は、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、利用者装置１およびサービス提供者装置２の各機能は、利用者装置１用のプログラムの場合は利用者装置１のCPUが、サービス提供者装置２用のプログラムの場合はサービス提供者装置２のCPUが、それぞれ実行することにより実現される。
また、利用者装置１用のプログラム、および、サービス提供者装置２用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
また、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、本実施形態のスマートコントラクトは、図１に示すように、ブリッジングコントラクトと、サービスコントラクトの２つの種類のスマートコントラクトを備える。しかしながら、１つのスマートコントラクトが、ブリッジングコントラクトとサービスコントラクトの両方の機能を備えることとしてもよい。
また、本実施形態では、１つのサービスコントラクトの場合を例として説明したが、サービスコントラクトは複数あってもよい。この場合、各サービスコントラクトは、それぞれ異なる種類のサービスを実施し、ブリッジングコントラクトは、支払情報トランザクションで指定されたサービスに対応するサービスコントラクトを呼び出す。
１ ：利用者装置
１１：トランザクション生成部
１２：キャンセル処理部
１３：ブロックチェーンクライアント
１４：仮想通貨用ブロックチェーンクライアント
１５：スマートコントラクト用ブロックチェーンクライアント
２ ：サービス提供者装置
２１：トランザクション生成部
２２：トランザクション雛形生成部
２３：ブロックチェーンクライアント
２４：仮想通貨用ブロックチェーンクライアント
２５：スマートコントラクト用ブロックチェーンクライアント
３ ：仮想通貨型ブロックチェーンのネットワーク
４ ：スマートコントラクト型ブロックチェーンのネットワーク
４１：ブリッジングコントラクト
４２：サービスコントラクト

Claims (7)

  1. 第１ブロックチェーンと、第２ブロックチェーンとを連携した決済システムであって、
    トランザクションの雛形を含む雛形情報トランザクションを、第１ブロックチェーンのネットワークに送信するサービス提供者装置と、
    第１ブロックチェーンに登録された前記トランザクションの雛形を用いて生成される電子署名と、支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信する利用者装置と、
    第１ブロックチェーンに含まれるスマートコントラクトと、を備え、
    前記スマートコントラクトは、前記支払情報トランザクションに含まれる電子署名を、前記支払金額と前記トランザクションの雛形とを用いて検証し、
    前記サービス提供者装置は、第１ブロックチェーンに登録された前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて決済トランザクションを生成し、第２ブロックチェーンのネットワークに送信し、
    前記トランザクションの雛型には複数の出力条件が設定され、前記決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となること
    を特徴とする決済システム。
  2. 請求項１記載の決済システムであって、
    前記利用者装置は、前記支払情報トランザクションのキャンセル要求を前記サービス提供者装置に送信し、前記サービス提供者装置により第１ブロックチェーンに登録された他のトランザクションの雛形を用いて生成される他の電子署名と、他の支払金額とを含むキャンセル用の他の支払情報トランザクションを、第１ブロックチェーンのネットワークに送信し、
    前記サービス提供者装置は、前記他のトランザクションの雛型を含む他の雛形情報トランザクションを第１ブロックチェーンのネットワークに送信し、第１ブロックチェーンに登録された前記他の支払情報トランザクションに対するサービス提供者からの合意を受け付けた場合、前記複数の出力条件に含まれるハッシュロックで指定されたハッシュの原像を含む原像トランザクションを、第１ブロックチェーンのネットワークに送信すること
    を特徴とする決済システム。
  3. 請求項１記載の決済システムであって、
    前記利用者装置は、マルチシグアドレスへ所定金額の保証金を送金する送金トランザクションを、第２ブロックチェーンのネットワークに送信し、
    前記送金トランザクションには、第１期間が経過すると前記利用者装置の電子署名のみで、前記送金トランザクションの利用が可能となる出力条件が設定されていること
    を特徴とする決済システム。
  4. 請求項３記載の決済システムであって、
    前記複数の出力条件には、前記決済トランザクションが第２期間の経過後に利用可能となるタイムロックが含まれ、
    前記スマートコントラクトは、第１期間よりも、第２期間が長いか否かを検証すること
    を特徴とする決済システム。
  5. 第１ブロックチェーンと、第２ブロックチェーンとを連携した決済方法であって、
    サービス提供者装置は、
    トランザクションの雛形を含む雛形情報トランザクションを、第１ブロックチェーンのネットワークに送信し、
    利用者装置は、
    第１ブロックチェーンに登録された前記トランザクションの雛形を用いて電子署名を生成し、
    前記電子署名と、支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信し、
    第１ブロックチェーンに含まれるスマートコントラクトは、前記支払情報トランザクションに含まれる電子署名を、前記支払金額と前記トランザクションの雛形とを用いて検証し、
    前記サービス提供者装置は、第１ブロックチェーンに登録された前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて決済トランザクションを生成し、第２ブロックチェーンのネットワークに送信し、
    前記トランザクションの雛型には複数の出力条件が設定され、前記決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となること
    を特徴とする決済方法。
  6. 第１ブロックチェーンと、第２ブロックチェーンとを連携した決済システムにおける利用者装置であって、
    所定金額の保証金を送金する送金トランザクションを、第２ブロックチェーンのネットワークに送信する送金トランザクション生成部と、
    サービス提供者装置により第１ブロックチェーンに登録されたトランザクションの雛形を用いて電子署名を生成し、当該電子署名と支払金額とを含む支払情報トランザクションを、第１ブロックチェーンのネットワークに送信する支払トランザクション生成部と、を備え、
    前記トランザクションの雛型には複数の出力条件が設定され、前記サービス提供者装置により、前記トランザクションの雛形と、前記電子署名と、前記支払金額とを用いて生成された決済トランザクションは、前記複数の出力条件のいずれかを満たした場合に、利用可能となること
    を特徴とする利用者装置。
  7. 請求項６に記載の利用者装置として、コンピュータを機能させることを特徴とする決済プログラム。
JP2018176397A 2018-09-20 2018-09-20 決済システム、決済方法、利用者装置、決済プログラム Active JP7021747B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018176397A JP7021747B2 (ja) 2018-09-20 2018-09-20 決済システム、決済方法、利用者装置、決済プログラム
US17/275,103 US11893583B2 (en) 2018-09-20 2019-09-20 Settlement system, settlement method, user device, and settlement program
PCT/JP2019/037063 WO2020059865A1 (ja) 2018-09-20 2019-09-20 決済システム、決済方法、利用者装置、決済プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018176397A JP7021747B2 (ja) 2018-09-20 2018-09-20 決済システム、決済方法、利用者装置、決済プログラム

Publications (2)

Publication Number Publication Date
JP2020047104A JP2020047104A (ja) 2020-03-26
JP7021747B2 true JP7021747B2 (ja) 2022-02-17

Family

ID=69887143

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018176397A Active JP7021747B2 (ja) 2018-09-20 2018-09-20 決済システム、決済方法、利用者装置、決済プログラム

Country Status (3)

Country Link
US (1) US11893583B2 (ja)
JP (1) JP7021747B2 (ja)
WO (1) WO2020059865A1 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11468431B2 (en) 2018-11-20 2022-10-11 Forte Labs, Inc. System and method for authorizing blockchain network transactions
EP3862957B1 (en) * 2019-01-03 2024-04-24 Huawei Technologies Co., Ltd. Blockchain-based data processing method, device and medium
US11880809B2 (en) 2019-10-10 2024-01-23 Frontage Road Holdings, Llc Blockchain cross-chain non-fungible token exchange
US20210110360A1 (en) * 2019-10-10 2021-04-15 Forte Labs, Inc. Cryptocurrency Exchange Without Bond Backing
CN112365119B (zh) * 2020-09-23 2023-04-25 四川大学 一种基于分布式数据库支撑的配电网电能分布式交易模型
WO2022101980A1 (ja) * 2020-11-10 2022-05-19 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 決済支援システム、及び決済支援方法
CN112801785B (zh) * 2021-01-13 2023-10-20 中央财经大学 基于区块链智能合约的公平数据交易方法及装置
CN112583608B (zh) * 2021-02-24 2021-05-28 浙江口碑网络技术有限公司 协作处理方法、装置及设备
CN112926980A (zh) * 2021-02-26 2021-06-08 贵州鑫众搏骏科技有限公司 一种基于区块链的支付数据交易方法
WO2022224365A1 (ja) 2021-04-20 2022-10-27 富士通株式会社 制御方法、制御プログラム、および情報処理装置
CN117280369A (zh) * 2021-04-22 2023-12-22 松下电器（美国）知识产权公司 控制方法、终端、以及程序
US11494799B1 (en) * 2021-05-14 2022-11-08 William C. Rehm Supporting action tracking and deeds between multiple parties
WO2022254589A1 (ja) * 2021-06-01 2022-12-08 富士通株式会社 制御方法、制御プログラム、情報処理装置、およびシステム
US20230130347A1 (en) * 2021-10-26 2023-04-27 Mastercard Asia/Pacific Pte. Ltd. Methods and systems for generating and validating transactions on a distributed ledger
KR102634318B1 (ko) * 2022-02-22 2024-02-08 주식회사 원유니버스 어플리케이션 데이터의 블록체인 저장 방법 및 이를 이용하는 시스템
WO2024013856A1 (ja) * 2022-07-12 2024-01-18 富士通株式会社 連携プログラム、連携方法及び情報処理装置
CN117556471B (zh) * 2024-01-12 2024-05-03 广东通莞科技股份有限公司 基于区块链的结算数据处理方法及***

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017204070A (ja) 2016-05-10 2017-11-16 日本電信電話株式会社 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム
WO2018020389A2 (en) 2016-07-29 2018-02-01 Chain Holdings Limited Blockchain implemented method and system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US20170085545A1 (en) * 2015-07-14 2017-03-23 Fmr Llc Smart Rules and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US10402792B2 (en) * 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
WO2017098519A1 (en) * 2015-12-08 2017-06-15 Tallysticks Limited A system and method for automated financial transaction validation, processing and settlement using blockchain smart contracts
US20220156725A1 (en) * 2020-11-18 2022-05-19 International Business Machines Corporation Cross-chain settlement mechanism

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017204070A (ja) 2016-05-10 2017-11-16 日本電信電話株式会社 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム
WO2018020389A2 (en) 2016-07-29 2018-02-01 Chain Holdings Limited Blockchain implemented method and system

Also Published As

Publication number Publication date
US11893583B2 (en) 2024-02-06
JP2020047104A (ja) 2020-03-26
WO2020059865A1 (ja) 2020-03-26
US20220051235A1 (en) 2022-02-17

Similar Documents

Publication Publication Date Title
JP7021747B2 (ja) 決済システム、決済方法、利用者装置、決済プログラム
US20220084020A1 (en) System and method for scaling blockchain networks with secure off-chain payment hubs
JP7011203B2 (ja) 決済システム、決済方法、利用者装置、決済プログラム
EP3688929B1 (en) System and method for providing privacy and security protection in blockchain-based private transactions
Miller et al. Sprites and state channels: Payment networks that go faster than lightning
Robinson et al. Atomic crosschain transactions for ethereum private sidechains
US20200193432A1 (en) Method and system for settling a blockchain transaction
CN110089069B (zh) 用于信息保护的***和方法
EP3396612A1 (en) Method and system for creating a user identity
Poon et al. The bitcoin lightning network
Lind et al. Teechain: Scalable blockchain payments using trusted execution environments
US20200327498A1 (en) Business Process Execution on a Blockchain Platform
WO2021218459A1 (zh) 跨链交互方法、装置和***
CN110730963B (zh) 用于信息保护的***和方法
CN110169015A (zh) 在分布式***中的网络节点之间达成共识
JP2016219014A (ja) リソース転送システム
CN109741068B (zh) 网银跨行签约方法、装置及***
JP6218979B1 (ja) ブロックチェーンを利用した金融取引方法およびシステム
JP7304963B2 (ja) プログラム、データ認証方法、およびコンピュータ装置
Aumayr et al. Thora: Atomic and privacy-preserving multi-channel updates
Mohanty et al. n-htlc: Neo hashed time-lock commitment to defend against wormhole attack in payment channel networks
KR20220045025A (ko) 탈중앙화된 트랜잭션의 통신 프로토콜을 위한 방법 및 시스템
CN111738857B (zh) 应用于区块链的隐匿支付证明的生成与验证方法及装置
JP2018535500A (ja) リソース転送システム内の一時的コンセンサスネットワーク
Zhang et al. Boros: Secure and efficient off-blockchain transactions via payment channel hub

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180926

A80 Written request to apply exceptions to lack of novelty of invention

Free format text: JAPANESE INTERMEDIATE CODE: A80

Effective date: 20180927

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200728

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211102

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211210

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220125

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220127

R150 Certificate of patent or registration of utility model

Ref document number: 7021747

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150