知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024042024
(43)【公開日】2024-03-27
(54)【発明の名称】ブロックチェーン上のセキュアなピアツーピア通信の方法
(51)【国際特許分類】
G06Q 20/06 20120101AFI20240319BHJP
【ＦＩ】
G06Q20/06
【審査請求】有
【請求項の数】8
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024009122
(22)【出願日】2024-01-25
(62)【分割の表示】P 2022142203の分割
【原出願日】2017-04-10
(31)【優先権主張番号】1606067.5
(32)【優先日】2016-04-11
(33)【優先権主張国・地域又は機関】GB
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ライト，クレイグ スティーヴン
(72)【発明者】
【氏名】サヴァナ，ステファヌ
(57)【要約】 （修正有）
【課題】ブロックチェーンを介して少なくとも２つのパーティの間で行われる融資のような交換プロセスを制御する方法及びシステムを提供する。
【解決手段】コンピュータにより実施される方法であって、少なくとも２つのパーティ間でブロックチェーンを介して行われる担保資産のセキュアな交換及び／又は通信処理を制御するよう構成され、ｎ人のうちのｍ人のマルチシグネチャ構成を有する第１Ｒｅｄｅｅｍスクリプトを生成するステップを含む。ｍは、２と貸し手により要求される公開鍵の数との和であり、ｎは、ｍとメタデータブロックの数とに基づく。方法はまた、第１Ｒｅｄｅｅｍスクリプトアドレスに前記担保資産を支払うために、担保トランザクションを生成するステップと、秘密鍵を用いて前記担保トランザクションに署名するステップと、担保トランザクションを前記ブロックチェーンにコミットするステップと、を含む。
【選択図】なし
【解決手段】コンピュータにより実施される方法であって、少なくとも２つのパーティ間でブロックチェーンを介して行われる担保資産のセキュアな交換及び／又は通信処理を制御するよう構成され、ｎ人のうちのｍ人のマルチシグネチャ構成を有する第１Ｒｅｄｅｅｍスクリプトを生成するステップを含む。ｍは、２と貸し手により要求される公開鍵の数との和であり、ｎは、ｍとメタデータブロックの数とに基づく。方法はまた、第１Ｒｅｄｅｅｍスクリプトアドレスに前記担保資産を支払うために、担保トランザクションを生成するステップと、秘密鍵を用いて前記担保トランザクションに署名するステップと、担保トランザクションを前記ブロックチェーンにコミットするステップと、を含む。
【選択図】なし
【特許請求の範囲】
【請求項1】
開始側と１つ以上の応答側との間のブロックチェーン上のセキュアなピアツーピア通信の方法であって、前記方法は、
前記ブロックチェーンに第１トランザクションを発行するステップであって、前記第１トランザクションは、前記開始側により署名され、デジタル通貨の第１の額を含む提案コントラクトに関連する第１メタデータを含む、ステップと、
前記ブロックチェーンに少なくとも１つの第２トランザクションを発行するステップであって、各々の前記第２トランザクションは、各々の応答側により署名され、各々のデジタル通貨の第２の額を含む前記提案コントラクトに関連する各々の第２メタデータを含む、ステップと、
以下：
前記第１トランザクションと前記少なくとも１つの第２トランザクションを前記提案コントラクトに関連するとして識別し、
各々の前記第２の額の和が前記第１の額より大きい又は等しいことを決定する、
ことにより、前記第１トランザクションと前記少なくとも１つの第２トランザクションを照合するステップと、
前記第１メタデータと各々の前記第２メタデータとに基づきコントラクトを生成するステップであって、前記コントラクトは、デジタル通貨の第４の額の転送に関連し、前記第４の額は各々の前記第２の額の和より少ない又は等しい、ステップと、
前記ブロックチェーンに少なくとも１つの第３トランザクションを発行するステップであって、各々の前記第３トランザクションは、第２トランザクションに対応し、対応する前記応答側により署名され、前記コントラクトへの参照を含み、各々のデジタル通貨の第３の額を前記開始側へ転送し、各々の前記第３の額の和は前記第４の額に等しい、ステップと、
を含む方法。
前記ブロックチェーンに第１トランザクションを発行するステップであって、前記第１トランザクションは、前記開始側により署名され、デジタル通貨の第１の額を含む提案コントラクトに関連する第１メタデータを含む、ステップと、
前記ブロックチェーンに少なくとも１つの第２トランザクションを発行するステップであって、各々の前記第２トランザクションは、各々の応答側により署名され、各々のデジタル通貨の第２の額を含む前記提案コントラクトに関連する各々の第２メタデータを含む、ステップと、
以下：
前記第１トランザクションと前記少なくとも１つの第２トランザクションを前記提案コントラクトに関連するとして識別し、
各々の前記第２の額の和が前記第１の額より大きい又は等しいことを決定する、
ことにより、前記第１トランザクションと前記少なくとも１つの第２トランザクションを照合するステップと、
前記第１メタデータと各々の前記第２メタデータとに基づきコントラクトを生成するステップであって、前記コントラクトは、デジタル通貨の第４の額の転送に関連し、前記第４の額は各々の前記第２の額の和より少ない又は等しい、ステップと、
前記ブロックチェーンに少なくとも１つの第３トランザクションを発行するステップであって、各々の前記第３トランザクションは、第２トランザクションに対応し、対応する前記応答側により署名され、前記コントラクトへの参照を含み、各々のデジタル通貨の第３の額を前記開始側へ転送し、各々の前記第３の額の和は前記第４の額に等しい、ステップと、
を含む方法。
【請求項2】
前記ブロックチェーンに複数の更なるトランザクションを発行するステップであって、各トランザクションは前記応答側の１つにデジタル通貨の額を返済する、ステップ、
を更に含む請求項１に記載の方法。
を更に含む請求項１に記載の方法。
【請求項3】
前記第１メタデータは、前記提案コントラクトに関連する返済スケジュールに関連する情報を含む、請求項１に記載の方法。
【請求項4】
前記第１メタデータは、前記返済スケジュールが満たされない場合に、前記開始側から少なくとも１つの応答側へ転送されるべき資産に関連する情報を含む、請求項３に記載の方法。
【請求項5】
前記第１メタデータ及び前記第２メタデータは、各々、１つ以上のコンピュータベースのレポジトリに格納された第１情報及び第２情報への参照であり、前記コントラクトは前記第１情報及び前記第２情報に基づく、請求項１に記載の方法。
【請求項6】
前記レポジトリの少なくとも１つは、分散ハッシュテーブルである、請求項５に記載の方法。
【請求項7】
前記第１トランザクションと前記少なくとも１つの第２トランザクションを識別することは、前記ブロックチェーンを監視して、前記提案コントラクトに関連するメタデータを含む少なくとも１つのトランザクションを識別することを含む、請求項１に記載の方法。
【請求項8】
コンピュータにより実装されるシステムであって、請求項１～７のいずれかに記載のブロックチェーン上のセキュアなピアツーピア通信の方法を実行するよう構成され、
ブロックチェーンと、
前記ブロックチェーンと通信するために構成される複数のコンピューティング装置と、
を含むシステム。
ブロックチェーンと、
前記ブロックチェーンと通信するために構成される複数のコンピューティング装置と、
を含むシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、トークン化方法及びトークン化システムに関する。特に、本発明は、コントラクト（取引、contract）の転送に関する。本発明は、Ｐ２Ｐ貸付プロセスと共に使用することに適して良い。本発明は、ピアツーピア分散ネットワークと関連して使用されて良い。本発明は、（限定ではないが）ビットコインブロックチェーンを含むブロックチェーンに関連する技術であり得る。
【発明の概要】
【0002】
本願明細書で、用語「ブロックチェーン」は、あらゆる形式の電子的な、コンピュータに基づく、分散台帳を含むよう使用される。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装及びプロトコルが本発明の範囲に含まれることに留意すべきである。
【0003】
ブロックチェーンは、ブロックにより構成される、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピア電子台帳である。また、ブロックはトランザクションにより構成される。各トランザクションは、ブロックチェーンシステム内で参加者間のデジタル資産の制御の転送を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに埋め込まれたスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。
【0004】
トランザクションがブロックチェーンに書き込まれるために、「検証され」なければならない。ネットワークノード（マイナー）は、各トランザクションが有効であることを保証するために作業を実行し、無効なトランザクションはネットワークから拒否される。ノードにインストールされたソフトウェアクライアントは、自身のロック及びアンロックスクリプトを実行することにより、この検証作業を未使用トランザクション（ＵＴＸＯ）に対して実行する。ロック及びアンロックスクリプトの実行が真と評価した場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、ｉ）トランザクションを受信した第１ノードにより検証され、トランザクションが検証された場合に、ノードは該トランザクションをネットワーク内の他のノードに中継し、ｉｉ）マイナーにより構築された新しいブロックに追加し、ｉｉｉ）マインされ、つまり過去のトランザクションの公開台帳に追加されなければならない。
【0005】
ブロックチェーン技術は、暗号通貨実装の使用で最も広く知られているが、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステム、及びブロックチェーンに格納可能なデータの両方の使用を探索し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動タスク及びプロセスのために使用できれば、非常に有利である。このようなソリューションは、それらの用途において一層多様でありながら、ブロックチェーンの利点（例えば、永久的、イベントの耐タンパレコード、分散プロセス、等）を利用できる。
【0006】
現在の研究の一分野は、「スマートコントラクト（smart contracts）」の実装のためのブロックチェーンの使用である。これらは、機械可読取引又は合意の条件の実行を自動化するために設計されたコンピュータプログラムである。自然言語で記述され得る従来の取引と異なり、スマートコントラクトは、結果を生成するためにインプットを処理できるルールを含み、該結果に依存して動作を実行させることのできる、機械実行可能プログラムである。ブロックチェーンに関連する関心の他の分野は、ブロックチェーンを介する現実世界のエンティティを表し転送するための「トークン」（又は「カラードコイン」）の使用である。潜在的に機密な又は秘密のアイテムは、識別可能な意味又は値を有しないトークンにより表現できる。したがって、トークンは、現実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能する。
【0007】
本発明は、異なるパーティ間のセキュアな電子通信及び転送を可能にするブロックチェーンに基づくメカニズムに、上述の概念を組み込む。本発明の１つの利点は、本発明が、パーティ間のセキュア通信チャネルの構築及び使用を可能にし、並びにチャネルを管理するために制御、管理、介入又は追加パーティ若しくはエンティティによる参加の必要無しにセキュアに発行されたコントラクトの取り込みを可能にすることである。
【0008】
このようなソリューションの１つの説明のための用途は、ピアツーピア融資である。融資は、金融サービス市場になくてはならない部分であり、前渡し金の後の支払を交換条件として、借り手が貸し手から資金を受けることを可能にする。銀行のような金融機関を介する伝統的な融資は、近年、一般により高い個人的報酬のために、個人がプール金を借り手に貸すピアツーピア（Ｐ２Ｐ）融資を通じて拡張されているが、前渡し金を失うリスクが増大する。
【0009】
多数のＰ２Ｐプールが存在し、それら自身の特注の取引所が、Ｐ２Ｐ融資プロセス（例えば、Ｚｏｐａ、Ｆｕｎｄｉｎｇサークル）に参加するためにそれらのアプリケーションへの個人登録を要求する。これらの貸し付けは、伝統的な銀行ネットワーク及びそれらの操業する領域内の基盤により裏打ちされない。したがって、Ｐ２Ｐ融資のための現在のシステムは、本来、制限的であり複雑である。
【0010】
代替ソリューションを提供することは有利である。このソリューションの利点は、例えば、洗練された融資プロセスが実行可能でありながら、ローカルな特注取引所の必要を除去することであり得る。ブロックチェーンの知られている利点（例えば、その耐タンパ性、トランザクションの永久的記録）は、都合良く利用され得る。このソリューションは、全く新しいアーキテクチャ及び技術プラットフォームを提供し得る。このような改良されたソリューションが考案されている。
【0011】
したがって、本発明によると、添付の請求の範囲に定められるような方法及びシステムが提供される。
【0012】
したがって、本発明によると、ブロックチェーンにより（つまり、それを使用して）行われるプロセスの実行を制御する方法及び対応するシステムが提供される。ブロックチェーンは、ビットコインブロックチェーンであって良く、又はそうでなくて良い。プロセスは、通信、交換、又は転送プロセスであって良い。プロセスは、デジタル資産又はブロックチェーン上で参照され若しくは提示される任意の種類の資産の転送、通信若しくは交換、を含み得る。非制御プロセスは、例えば融資プロセスであって良い。これは、複数のブロックチェーンユーザの間で行われるピアツーピア融資プロセスであって良い。用語「ユーザ」又は「パーティ」は、人間又は機械に基づくエンティティを表すことがある。各ブロックチェーンユーザは、プロセスに参加するために適切に構成されたハードウェア及びソフトウェア（例えば、ビットコインクライアントをインストールされたコンピュータ）を使用して良い。本発明は、パーティ間のセキュアな通信／転送を保証するための暗号技術の使用も含むので、セキュリティソリューション、システム、及び／又は方法も参照し得る。
【0013】
本発明は、本願明細書に含まれる表１～８で及び／又は本願明細書に説明されるような使用例／シナリオで実質的に説明されるような方法を含み得る。
【0014】
追加又は代替として、本発明は、構成されたコンピュータにより実施される方法を含み得る。本発明は、ブロックチェーンを介して少なくとも２つのパーティ間で行われる交換プロセスを制御するよう構成されて良い。本方法は、ブロックチェーントランザクションを生成するステップであって、ブロックチェーントランザクションは、開始パーティに関連付けられた暗号公開鍵、及び、文書のハッシュとＲｅｄｅｅｍアドレスとデジタル通貨の額とを含むメタデータ、を含むＲｅｄｅｅｍスクリプトを含む、ステップと、Ｒｅｄｅｅｍスクリプトにデジタル通貨を支払うために、第２ブロックチェーントランザクションを生成するステップと、を有して良い。
【0015】
文書は、交換関連文書であって良い。これは、パーティ間で行われる又は通信される交換又は転送に関連して良い。交換は、任意の種類の資産、デジタル、又はその他に関連して良い。
【0016】
したがって、本発明は、通貨を支払うための更なるブロックチェーントランザクションを使用するステップを更に含んで良い。これは、更なるトランザクションが公衆に利用可能になり、したがってブロックチェーンに一旦発行されると他のパーティにより検出できるという利点を提供する。更なるトランザクションは、応答、例えば別のパーティからのオファーをトリガするために必要な情報を提供できる。したがって、交換プロセスは、代替媒体ではなく、ブロックチェーン上のマルチトランザクションメカニズムを介して実施できる。第１及び第２トランザクションは、同じパーティにより生成されて良い。トランザクションは、マルチシグネチャブロックチェーントランザクションであって良い。
【0017】
第１及び／又は第２トランザクションは、ブロックチェーンから、オフブロックに格納された招待（オファー／要求）へのアクセスを提供して良い。招待は、コントラクトに参加するための招待であって良い。
【0018】
交換は、融資であって良く、又は融資に関連して良い。スマートコントラクト（及び関連付けられたブロックチェーントランザクション）は、複数の参加者、例えば、貸し手／借り手が、ブロックチェーン上のトランザクションを介して生じる１又は複数の応答により互いに照合されるという条件の下で形成されて良い。
【0019】
招待は、電子形式で格納された構造化文書であって良い。
【0020】
デジタル通貨は、ビットコイン（ＢＴＣ）であって良く、又はそうでなくて良い。レポジトリは、招待を格納できる任意の種類のコンピュータに基づくリソースであって良い。レポジトリは、サーバを有し、又はサーバに収容されて良い。レポジトリは、ブロックチェーンと別個であって良い。したがって、招待は、「ブロック外（オフブロック、off－block）」に保持されて良い。
【0021】
位置への参照は、ＵＲＩ又は招待の位置を識別する他の手段を有して良い。
【0022】
招待は公衆に利用可能であって良く、又は招待の内容へのアクセスを認可パーティに制限するために何らかのセキュリティメカニズムが使用されて良い。招待は、中央位置に格納されて良く、又は分散されて良い。好適な実施形態では、招待は、公衆にアクセス可能であり、分散ハッシュテーブル（Distributed Hash Table：ＤＨＴ）に格納されて良い。
【0023】
通貨は、任意の種類のデジタル通貨であって良い。通貨はビットコインであって良い。通貨はトークン化された通貨であって良い。転送は、任意の種類の商品又はサービスの転送であって良い。望ましくは、転送は、トランザクション（Ｔｘ）を用いてブロックチェーンを介して行われる。
【0024】
開始パーティは、見込み借り手又は貸し手であって良い。招待は、融資の要求又はオファーに関連する情報を有する文書又はファイルであって良い。これはデジタルファイルであって良い。
【0025】
方法は、第１トランザクションをブロックチェーンに発行するステップを含んで良い。
【0026】
招待は、転送に関連付けられた返済スケジュールに関連する情報、及び／又は、開始パーティに関連付けられた第２パーティ、を含んで良い。
【0027】
方法は、応答を生成するステップであって、応答は、応答パーティに関連付けられ且つ招待への参照を含む、ステップと、コンピュータに基づくレポジトリに応答を格納するステップと、更なる（マルチシグネチャ）ブロックチェーントランザクションを生成するステップであって、更なるブロックチェーントランザクションは、Ｒｅｄｅｅｍスクリプトであって、応答パーティに関連付けられた暗号公開鍵と、応答のハッシュ及びレポジトリ内の自身の位置への参照を含むメタデータと、を含むＲｅｄｅｅｍスクリプトと、デジタル通貨の額と、を含む、ステップと、を含んで良い。
【0028】
応答は、招待と同じレポジトリ、又は異なるレポジトリに格納されて良い。応答は、電子ファイルであって良い。招待及び／又は応答を格納するレポジトリは、分散ハッシュテーブル（ＤＨＴ）であって良い。
【0029】
方法は、招待又は応答に関連付けられた交換スケジュールを生成するステップであって、スケジュールは少なくとも１つの交換額及び／又は交換日に関連するデータを含む、ステップと、スケジュールの中の各交換についてＰ２ＳＨアドレスを生成するステップと、を含んで良い。
【0030】
交換スケジュールは、返済スケジュールであって良い。交換額及び／又は日は、招待又は応答に関連付けられた融資額の返済に関連して良い。
【0031】
方法は、交換スケジュールに従い交換を行うために、ブロックチェーンにトランザクションを発行するステップ、を含んで良い。
【0032】
方法は、招待及び／又は応答に関連付けられたメタデータを有する少なくとも１つのトランザクションを識別するためにブロックチェーンを監視するステップを更に有して良い。
【0033】
少なくとも１つの監視するステップは、実質的に以下の表２に示すように実行されて良い。
【0034】
方法は、招待に関連付けられたメタデータを含む少なくとも１つのトランザクション及び応答に関連付けられたメタデータを含む少なくとも１つのトランザクションを識別するために、ブロックチェーンを監視するステップと、メタデータの間に対応があるか否かを決定するために、識別したトランザクションからのメタデータを比較するステップと、を更に有して良い。
【0035】
少なくとも２つのブロックチェーントランザクションは、招待及び応答に含まれるデータの間で一致（対応）があるか否かを評価するために比較されて良い。
【0036】
方法は、開始パーティ及び応答パーティに関連付けられ且つデータを含むスマートコントラクトを生成するステップであって、データは、招待及び／又は応答、開始パーティ及び／又は応答パーティ、保証人及び／又は世話人のような第三者、あるパーティから別のパーティへ転送されるべき少なくとも１つの資産、返済スケジュール、に関連する、ステップ、を更に有して良い。
【0037】
少なくとも１つのステップは、実質的に以下の表４に示すように実行されて良い。
【0038】
スマートコントラクトは、招待及び応答に含まれるデータの間で一致（対応）があることが決定された場合に、生成されて良い。スマートコントラクトは、自動プロセスにより、つまりコンピュータにより生成されて良い。
【0039】
方法は、レポジトリにスマートコントラクトを発行するステップ、及び／又は、ブロックチェーンにトランザクションを発行するステップであって、トランザクションは少なくとも１つの公開鍵とスマートコントラクトへの参照とを含むＲｅｄｅｅｍスクリプトを有する、ステップ、を更に有して良い。
【0040】
本発明は、前述の請求項の方法を実行するよう構成されたコンピュータにより実装されるシステムであって、ブロックチェーンと、ブロックチェーンと通信するよう構成される複数のコンピューティング装置と、を含むシステムを更に含み得る。
【0041】
追加又は代替として、本発明は、上述の方法のステップのうちの任意のもの又は全部を実行するよう配置され及び構成されたコンピュータにより実装されるシステムを提供し得る。
【0042】
追加又は代替として、本発明は、ブロックチェーンを介して少なくとも２つのパーティ間で行われる貸付プロセスを制御するよう構成されたコンピュータにより実装されるシステムであって、該システムは、２以上のパーティ間の転送のための招待を格納するコンピュータに基づくレポジトリであって、コントラクトは開始パーティに関連付けられる、レポジトリと、第１マルチシグネチャトランザクションを有するブロックチェーンであって、該第１マルチシグネチャトランザクションは、開始パーティに関連付けられた暗号公開鍵と招待及びレポジトリ内の自身の位置への参照を含むメタデータとを含むＲｅｄｅｅｍスクリプト、及びデジタル通貨の額、を含む、ブロックチェーンと、を有するシステムを含み得る。システムを有し得る。
【0043】
本発明のある実施形態又は態様に関連して本願明細書に記載された任意の特徴は、任意の他の実施形態又は態様に関連して使用されても良い。例えば、方法に関連して記載された特徴は、システムに適用されても良く、逆も同様である。
【0044】
したがって、本発明は、限定ではないが、以下を含む種々の技術的利点を提供し得る。
・本発明は、セキュアな通信チャネルがピアツーピアネットワーク上のパーティ間に設定されること可能にする。
・通信は、第三者による介入の必要無しに、該パーティ自身の間で安全に行うことができる。
・本発明は、ブロックチェーンを介して行われるマルチパーティ交換又は転送の制御及び実施を可能にする。
・転送（例えば、返済）は、永久的な、耐タンパ性のある、タイムスタンプされたレコードを提供するブロックチェーンを介して行うことができる。
・本発明は、セキュアな通信チャネルがピアツーピアネットワーク上のパーティ間に設定されること可能にする。
・通信は、第三者による介入の必要無しに、該パーティ自身の間で安全に行うことができる。
・本発明は、ブロックチェーンを介して行われるマルチパーティ交換又は転送の制御及び実施を可能にする。
・転送（例えば、返済）は、永久的な、耐タンパ性のある、タイムスタンプされたレコードを提供するブロックチェーンを介して行うことができる。
【0045】
本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。
【図面の簡単な説明】
【0046】
本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
【図1】従来知られているような、複数のコンピューティング装置を含むＰ２Ｐネットワークを示す。本発明はＰ２Ｐシステムを用いて実施され得る。
【図2】記載される主な使用例におけるパーティの各々の相対的位置決めを示す。
【図3】１０ビットコインを借りたいボブのメタデータを示す。
【図4】２０ビットコインを貸したいアリスのメタデータを示す。
【図5】相互に合意可能な条項で融資に入る、２つの参加者の意欲を発行するトランザクションの照合を示す。
【図6】ボブにより引き下ろされるアリスによる融資の前払いを示す。
【図7】アリスにより前払いされた資金をボブが引き下ろすことを可能にする、ボブからのインプットを示す。
【図8】アリスに返済するためのボブからのインプットを示す。
【図9】ボブの返済を受信するためのアリスからのインプットを示す。
【図10】１０ビットコインを借りたい及び保証人を提供する意向であるボブのメタデータを示す。
【図11】２０ビットコインを貸したいアリスのメタデータを示す。
【図12】相互に合意可能な条項で融資に入る、ボブ及びアリスの意欲を発行するトランザクションの照合を示す。
【図13】ボブにより引き下ろされるアリスによる融資の前払いを示す。
【図14】アリスにより前払いされた資金をボブが引き下ろすことを可能にする、ボブからのインプットを示す。
【図15】アリスに返済するためのボブからのインプットを示す。
【図16】ボブの返済を受信するためのアリスからのインプットを示す。
【図17】３０ビットコインを借りたいボブのメタデータを示す。
【図18】１０ビットコインを貸したいアリスのメタデータを示す。
【図19】２０ビットコインを貸したいイブのメタデータを示す。
【図20】相互に合意可能な条項で融資に入る、３つの参加者の意欲を発行する、実行する照合プロセスを示す。
【図21】ボブが、世話人により所有されるエスクロー口座への要求担保をロックすることを示す。
【図22】交渉条項を含むコントラクト文書の構築を示す。
【図23】イブ及びアリスにより提供される融資前払いを引き下ろすためのボブからのインプットを示す。
【図24】アリス及びイブに返済するためのボブからのインプットを示す。
【図25】アリス及びイブに返済するアウトプットを示す。
【図26】担保を再請求するためのボブからのインプットを示す。
【図27】￡１５，０００を借りるボブの要望を示すためのボブからのメタデータを示す。
【図28】￡１５，０００を貸したい要望を示すアリスからのメタデータを示す。
【図29】相互に合意可能な条項で融資に入る、ボブ及びアリスの意欲を発行する照合プロセスを示す。
【図30】交渉条項を含むコントラクト文書の構築を示す。
【図31】アリスからの融資前払いを引き下ろすためのボブからのインプットを示す。
【図32】アリスへの返済を行うためのボブからのインプットを示す。
【図33】ボブからの返済を徴収するためのアリスからのインプットを示す。
【発明を実施するための形態】
【0047】
図１は、従来技術によるＰ２Ｐネットワークを示す。Ｐ２Ｐシステムは、「ノード」又は「ピア」として知られる相互接続されたコンピューティング装置の間でワーク及びタスクを共有する分散型アーキテクチャである。このようなネットワークは、どの個別コンピュータも「責任がある」として指定されない分散型である。近年、Ｐ２Ｐアーキテクチャは、ビットコインブロックチェーンの実装及びビットコインの影響を受けた適応のために使用されている。
【0048】
以下の用語は、本願明細書で使用され、以下の意味に従い解釈され得る。
【0049】
【表0】
【0050】
本願明細書で使用される例は、貸付プロセスに関するが、本発明はこれに関して限定されない。纏めると、この説明のための実施形態は、借り手又は貸し手からブロックチェーンへの、見込みコントラクトの発行を可能にして、相手パーティが該コントラクトに結合する又は該コントラクトに代替条項をオファーすることを可能にする、技術的ソリューションを提供する。知られているソリューションは、本願明細書に記載の方法で上述の動作を実行する技術的メカニズムを提供しない。
【0051】
留意すべきことに、コントラクトは、借り手と貸し手の間の相互に許容可能な条項が合意されるときにのみ、形成される。借り手の要件を満たすために不十分な資金しか提出されない場合、コントラクトは形成されない。
【0052】
本発明のプロセスの主な要素は以下の通りである：
開始人は、提案されるコントラクトをブロックチェーンに発行する。提案されるコントラクトは以下を記述する：
・彼らが何を借りたいか；
・彼らが借りたい量；
・支払頻度及び期間。
開始人は、提案されるコントラクトをブロックチェーンに発行する。提案されるコントラクトは以下を記述する：
・彼らが何を借りたいか；
・彼らが借りたい量；
・支払頻度及び期間。
【0053】
コントラクトは、コントラクトの位置へのポインタ又は参照と、コントラクトのハッシュと、を含むトランザクションにより、ブロックチェーン上に公衆に発行される。コントラクト自体は、オフブロックであり（つまり、ブロックチェーン内に無い）、詳細事項は利率、場所、及び資産の詳細事項を含み得る。したがって、現実には、コントラクト自体は、ブロックチェーン内で公表されなくて良いが、ブロックチェーン上のトランザクション内のメタデータにより提示され及び／又はアクセス可能である。コントラクトは、非常に複雑であるが、提供されるデータに基づき分類可能であって良い。コントラクト自体は、幾つかの実施形態ではルックアップキーとして機能するコントラクトのハッシュと共に分散ハッシュテーブル（ＤＨＴ）として実装され得るコンピュータに基づくレジストリ又はレポジトリ内に保持されて良い。
【0054】
一例では、ピアは、特定種類の融資を見付け、彼らの利率を探し、支払スケジュールを質問するために、ブロックチェーンを観察し検索するソフトウェアツールを使用できる。この情報へのアクセスを有することは、見込み投資家が、リスクを計算し、どのコントラクトに彼らが入札したいかを決定することを可能にする。このように、本発明は、融資又は見込み融資に関連する情報が容易に且つ自由に入手可能にできるという有意な利点を提供する。
【0055】
見込み相手パーティは、２つのメカニズムのうちの１つで入札する。
【0056】
保証契約と同じ基礎で（しかし、これは、借り手が開始人である場合にのみ実現可能である）、保証契約モデルの場合、これは、借り手が資金を募るためにコントラクト内で定義された設定期間のみを有することを意味する。３０日間で１５ビットコインの資金を募ることを望むコントラクトの例を考える。ユーザＡは８ビットコインを入札し、ユーザＢは２ビットコインを入札し、ユーザＣは５ビットコインを入札する。３つの入札全部が３０日の期間内に到着した場合、コントラクトは有効である。しかしながら、ユーザＣの入札が３０日の予定表の前に現れない場合、１０ビットコインしか誓約されないので、コントラクトは終了し、更なる動作は行われない。
【0057】
又は、
開始人と同じメカニズムを用いる。ここで、コントラクトはブロックチェーンにブロードキャストされる。ブロードキャストに基づき、コントラクト自体は、生成された任意のオファーの有効期間を決定する。
開始人と同じメカニズムを用いる。ここで、コントラクトはブロックチェーンにブロードキャストされる。ブロードキャストに基づき、コントラクト自体は、生成された任意のオファーの有効期間を決定する。
【0058】
全ての入札の合計が要求した融資額に等しくなると、ブロックチェーントランザクションは有効になる。未完了（したがって未だ有効になっていない）トランザクションのコピーを非公式に巡回することにより、検証プロセスが実行され得る。見込み貸し手は、次に、未完了トランザクションのコピーを取り、（トランザクションの別個のインプット部分に）彼らの誓約額を有する新しいバージョンを生成することにより、ＢＴＣのような通貨を誓約できる。トランザクションは、全ての誓約の合計額がアウトプット部分で指定された閾に達するまで、無効のままである。しかしながら、統計が閾を超えると、トランザクションは有効になり、ネットワークへブロードキャストされて良い。この技術は「ANYONE－CAN－PAY」フラグを使用する。
【0059】
この場合、スマートコントラクトは、該スマートコントラクトが有効になると、ブロックチェーンに発行される。トランザクションは以下を含む：
・スマートコントラクトによりカバーされる条項；
・ビットコイン又はトークン化フォーマットの金銭が、投資家から借り手に解放される。
・スマートコントラクトによりカバーされる条項；
・ビットコイン又はトークン化フォーマットの金銭が、投資家から借り手に解放される。
【0060】
何が借りられたかを詳述する融資メモが交付される。これは、トランザクションとして実装される。これは、借り手のＰ２ＳＨ（Pay－to－Script Hash）アドレスに返送される。借り手は、彼らが融資された金銭を使用できるようにするために、このハッシュアドレスに一致するスクリプトを提供しなければならない。Ｐ２ＳＨアドレスは、全ての返済の詳細事項も含む。返済の詳細事項は、Ｒｅｄｅｅｍスクリプト内のメタデータとして実装される。
【0061】
コントラクトが規則的返済を含む場合、これらのスケジュールが生成される。投資家に返済するために、各支払のＰ２ＳＨアドレスが生成される。例えば、１ビットコインの規則的支払のために、ユーザＡが５０％を提出し、ユーザＢが３０％を提出し、ユーザＣが２０％を提出する場合、以下の額が各ユーザに支払われる：
ユーザＡ：０．５ビットコイン、
ユーザＢ：０．３ビットコイン、
ユーザＣ：０．２ビットコイン。
ユーザＡ：０．５ビットコイン、
ユーザＢ：０．３ビットコイン、
ユーザＣ：０．２ビットコイン。
【0062】
各支払は次々に行われ、対応するトランザクションは知られているブロックチェーン技術に従いタイムスタンプされる。返済は、実際の返済額と生じた任意の利子との間で分離され得る。これは、融資に関与する任意のパーティが、ブロックチェーンを介して、支払が行われたかどうか及び何時行われたかを知ることを可能にする。借り手は、予定された支払を早く支払うこと、及びそのためにタイムスタンプで可視であることも、可能である。したがって、本発明は、ブロックチェーンを介して融資関連データを共有する及び交換する拡張メカニズムを提供する。
【0063】
幾つかの例は、以下に単に説明のために提供され、限定を意図しない。
【0064】
＜例示的なシナリオ１－保証人又は担保を有しない標準的融資＞
このシナリオは、図３～９を参照して説明される。ボブは、１０ビットコイン（ＢＴＣ）の融資を要求するが、それを保証するための担保を有しない。彼は、以下を有するために融資を要求する：
・１年率（one year rate）、
・毎月の支払、
・１０％の利率。
このシナリオは、図３～９を参照して説明される。ボブは、１０ビットコイン（ＢＴＣ）の融資を要求するが、それを保証するための担保を有しない。彼は、以下を有するために融資を要求する：
・１年率（one year rate）、
・毎月の支払、
・１０％の利率。
【0065】
ボブは、適切にプログラムされたコンピューティング（クライアント）装置を用いてトランザクションメタデータを生成し、図５に示すようなブロックチェーントランザクションの中のＰ２ＳＨ（pay－to－script－hash）内で該メタデータを提供する。ボブにより生成されたメタデータは図３に示される。
【0066】
このようなシナリオでは、借り手自身の評判が担保として使用される。見込み貸し手は、融資が疑似的匿名方法で前払いされることを可能にする、要求文書の部分として又はブロックチェーンから直接に提供される情報を用いて、ボブの信用価値を評価するための複数のルートを有する。信用価値を評価する方法は、本発明の範囲を超え、借り手の信用価値が評価される方法は本願明細書に関連しない。
【0067】
要求額が調達されるときだけ、以下の２列（line）の署名アドレスで維持される信用の列（line）と共に、支払スケジュールが生成される：
借り手（Borrower）
投資家（Investor）。
借り手（Borrower）
投資家（Investor）。
【0068】
毎月の支払の各々は，投資家の署名アドレスに対して行われる。支払額は、支払われるべき未払い残高及び利子に従い計算される。１０ビットコインが調達されない場合、コントラクトは無効であると考えられる。
【0069】
アリスは、担保無し、最低利率９％で、最大６０ヶ月まで、２０ビットコインを貸し出す彼女の意欲を示すメタデータを生成する。図４は、このような合意に至るアリスの意欲に関して生成されたメタデータを示す。
【0070】
図５に示されるように、１０ビットコインを借りたいというボブの要望、及び２０ビットコインを貸したいというアリスの意欲は、ブロックチェーンへトランザクションとして発行される。ボブ及びアリスに関して生成されたトランザクションは、照合され、アリスにより調達される融資の形式で形成される（図６を参照）。図８に、融資のボブの返済を示す。図９は、アリスがボブから返済を受信することを示す。
【0071】
「照合」は、個々のトランザクションの中の少なくとも１つのアイテム又は要素のミラーリングが存在すること、つまり個々のトランザクションの間に対応が存在することを意味すると解釈できる。当業者は、照合プロセスが様々な方法で実行できることを理解する。一実施形態では、照合プロセスは、単純なアルゴリズムを用いて実行される。該アルゴリズムにより、借り手からの要求値は、貸し手からの対応するオファー値に対して照合される。これは、最小－最大範囲が重なり合うこと（値が範囲内で表現される場合）、又は実際の値が直接照合されること（つまり、要求及びオファーの両方がＢＴＣに対してであり、又は両方が特定トークンに対してである、等）を保証することにより、行うことができる。
【0072】
＜シナリオ２－保証人のいる標準的な融資＞
ボブは、１０ビットコインの融資を要求するが、それを保証するための担保を有しない。彼は１４歳であり、したがってマイナーと考えられるので、彼は強力なブロックチェーンの評判を有しない。代わりに、ボブは、保証人の役目を務めるよう彼の母であるイブに連絡する。図１０に示すメタデータは、このインプットを記述するために生成される。図１０に示す情報はメタデータに含まれ、ボブ及びイブの評判のチェックを助けるために使用され得る。
ボブは、１０ビットコインの融資を要求するが、それを保証するための担保を有しない。彼は１４歳であり、したがってマイナーと考えられるので、彼は強力なブロックチェーンの評判を有しない。代わりに、ボブは、保証人の役目を務めるよう彼の母であるイブに連絡する。図１０に示すメタデータは、このインプットを記述するために生成される。図１０に示す情報はメタデータに含まれ、ボブ及びイブの評判のチェックを助けるために使用され得る。
【0073】
留意すべきことに、任意の種類の条件がコントラクトに添付できる。これは、条件コードの別個のリストを維持することにより達成される。図１０の例では、「保証人」を示すために使用される条件コードは、「０ｘ０００３」に（適宜）設定される。メタデータの最初の２バイトは、条件コードが何かを示し、メタデータの残りの部分は、条件コードの値に依存してフォーマットされる。このフォーマットは、条件コードの別個リストの中で指定される。図１０の例では、メタデータの次の２０バイトは、保証人の公開鍵のハッシュを表す。
【0074】
要求額が調達されるときだけ、以下の３列（line）の署名アドレスで維持される信用の列（line）と共に、支払スケジュールが生成される：
借り手（Borrower）
投資家（Investor）
保証人（Guarantor）。
借り手（Borrower）
投資家（Investor）
保証人（Guarantor）。
【0075】
毎月の支払の各々は、投資家の署名アドレスに対して行われる。支払額は、支払われるべき未払い残高及び利子に従い計算される。１０ビットコインが調達されない場合、コントラクトは無効であると考えられる。
【0076】
アリスは、担保無し、最低利率９％で、最大５年まで、２０ビットコインを貸し出す彼女の要望を示す、図１１に示すようなメタデータを生成する。
【0077】
図１２は、１０ビットコインを借りたい要望を示すボブと、２０ビットコインを貸したい要望を示すアリスと、の結果として生成される要求を示す。２つの要求は照合され、次にコントラクトが構築される。このコントラクトは、アリスにより調達される１０ビットコインの融資である。融資は、１２ヶ月に渡り年率９％で１０ビットコインである。これを図１３に示す。
【0078】
【0079】
＜例示的シナリオ３－担保として資産を使用する＞
アンドリューは、彼の家に行っている増築に資金調達するために、６０ビットコインを借りたいと思う。彼は、融資のための担保として、住宅担保貸付の最大５％までと決める。アンドリューは、彼の要求のメタデータに含まれる彼のＩＤにより知られている。これは、彼の信用格付けが何であるかを確立することを容易にする。見込み貸し手は、アンドリューがお金を借りローンを返済した前のブロックチェーントランザクションについてのアンドリューの鍵ペアを問い合わせることができる。これから、彼らは入札を行う価値があるかどうかを決定できる。アンドリューの要求のメタデータは図１７に示される。
アンドリューは、彼の家に行っている増築に資金調達するために、６０ビットコインを借りたいと思う。彼は、融資のための担保として、住宅担保貸付の最大５％までと決める。アンドリューは、彼の要求のメタデータに含まれる彼のＩＤにより知られている。これは、彼の信用格付けが何であるかを確立することを容易にする。見込み貸し手は、アンドリューがお金を借りローンを返済した前のブロックチェーントランザクションについてのアンドリューの鍵ペアを問い合わせることができる。これから、彼らは入札を行う価値があるかどうかを決定できる。アンドリューの要求のメタデータは図１７に示される。
【0080】
家の権利証書の所有権はトークン化され（つまり、ブロックチェーントランザクション内のメタデータの中で提示される）、ユーザは５％の住宅担保貸付の所有権を容易に交換できる。システムは、次に、１０ビットコインを調達する必要をブロードキャストするために使用される。要求額が調達されるときだけ、借り手と投資家の詳細事項を含む２列（line）の署名アドレスで維持される信用の列（line）と共に、支払スケジュールが生成される。
【0081】
返済が行われるとき、貸し手アドレスの各々は、投資のために割り当てられたシェア（share、持分）で支払われる。例えば、貸し出し額において６０／４０の分割で２人の貸し手が存在する場合、１人の貸し手は返済の６０％を得て、他方は４０％を得る。交換可能（redeemable）コントラクトは、借り手のスクリプトハッシュアドレスへの支払に、返済をリンクする。
【0082】
アリスは、９％の最低利率で最大５年間、１０ビットコインを貸したいと思うが、保証を望む。この要求により生成されたメタデータは図１８に示される。
【0083】
イブは、９．７５％の最低利率で最大５年間、２０ビットコインを貸したいと思う。この要求により生成されたメタデータは図１９に示される。ボブ、イブ、及びアリスにより生成されたトランザクションは、次に、図２０により示されるように照合される。
【0084】
【0085】
【0086】
【0087】
＜例示的シナリオ４－フィアット通貨を借りる＞
アンドリューは、￡１５，０００を借りたいが、ブロックチェーンにより彼の口座を管理したいと望む。アンドリューの要求に関して生成されたメタデータは図２７に示される。このシナリオでは、貸し手は、資金を前払いするために、「生の」ビットコインではなく、トークン化された通貨を貸し出す。
アンドリューは、￡１５，０００を借りたいが、ブロックチェーンにより彼の口座を管理したいと望む。アンドリューの要求に関して生成されたメタデータは図２７に示される。このシナリオでは、貸し手は、資金を前払いするために、「生の」ビットコインではなく、トークン化された通貨を貸し出す。
【0088】
アリスは、要求の中で、彼女が１０％以上の率で毎月の支払により１２ヶ月の間、ブロックチェーン上で融資を提供したいことを示す。この要求に応答して生成されたメタデータは図２８に示される。
【0089】
【0090】
【0091】
＜技術的仕様＞
最も簡単には、融資は、貸し手が金銭又は他の資産を借り手に前貸しする、貸し手と借り手との間の取り決めである。本発明は、これらの資産及び合意を交換し及び発行するための技術的媒体としてブロックチェーンを利用する。本願明細書の記載はＢＴＣ又はＢＴＣにより実現されるトークン化された通貨の貸し出しに焦点を当てるが、本発明は限定されないこと、及び他の通貨又はブロックチェーンプロトコルが使用できることに留意すべきである。
最も簡単には、融資は、貸し手が金銭又は他の資産を借り手に前貸しする、貸し手と借り手との間の取り決めである。本発明は、これらの資産及び合意を交換し及び発行するための技術的媒体としてブロックチェーンを利用する。本願明細書の記載はＢＴＣ又はＢＴＣにより実現されるトークン化された通貨の貸し出しに焦点を当てるが、本発明は限定されないこと、及び他の通貨又はブロックチェーンプロトコルが使用できることに留意すべきである。
【0092】
本発明は、特に下の有利な特徴を与え得る：
・本発明は、他の場所で保持されるサポート情報と共に、融資をブロックチェーン上に発行することを助けるためのオファー及び／又は要求を可能にする。
・本発明は、他の場所で保持される追加サポート情報と共に、融資コントラクトがブロックチェーン上に発行されることを可能にする。
・本発明は、複数の貸し手が融資に参加することを可能にする。
・本発明は、複数の借り手が融資に参加することを可能にする。
・本発明は、借り手が１又は複数の保証人と共に引き下ろすことを可能にする。
・本発明は、借り手が、サポートする担保の提供を通じて引き下ろすことを可能にする。ここで、担保は、ブロックチェーン上に又はその外部にホストできる。
・本発明は、融資コントラクトが、種々の返済、及びそれに対して指定された返済計算の任意の特性を有することを可能にする。システムは、この基本基盤がブロックチェーンを用いて実施されることを可能にする。
・本発明は、貸し手の間の競合入札が行われることを可能にする。
・本発明は、借り手の間の競合入札が行われることを可能にする。
・本発明は、借り手又は貸し手のいずれかが特定融資の開始人になることを可能にする。
・本発明は、他の場所で保持されるサポート情報と共に、融資をブロックチェーン上に発行することを助けるためのオファー及び／又は要求を可能にする。
・本発明は、他の場所で保持される追加サポート情報と共に、融資コントラクトがブロックチェーン上に発行されることを可能にする。
・本発明は、複数の貸し手が融資に参加することを可能にする。
・本発明は、複数の借り手が融資に参加することを可能にする。
・本発明は、借り手が１又は複数の保証人と共に引き下ろすことを可能にする。
・本発明は、借り手が、サポートする担保の提供を通じて引き下ろすことを可能にする。ここで、担保は、ブロックチェーン上に又はその外部にホストできる。
・本発明は、融資コントラクトが、種々の返済、及びそれに対して指定された返済計算の任意の特性を有することを可能にする。システムは、この基本基盤がブロックチェーンを用いて実施されることを可能にする。
・本発明は、貸し手の間の競合入札が行われることを可能にする。
・本発明は、借り手の間の競合入札が行われることを可能にする。
・本発明は、借り手又は貸し手のいずれかが特定融資の開始人になることを可能にする。
【0093】
以下に、説明を目的として一連の鍵使用例を記載する。
【0094】
＜融資の開始＞
借り手又は貸し手（開始人）は、彼（彼女）が入りたいと思う融資に関する広範な市場にオファーを発行したいと望む。
借り手又は貸し手（開始人）は、彼（彼女）が入りたいと思う融資に関する広範な市場にオファーを発行したいと望む。
【0095】
［表１］
【0096】
【表1】
この使用例に対する２つの拡張がある：
・［１１０］保証人のいる融資を要求する。この状況では、要求は借り手から生じなければならない。
・［１２０］担保のある融資を要求する。
【0097】
＜変形＞
この使用例は、変形［１０５］を有し、世話人が融資要求の管理に関与する。このシナリオは以下のステップを有する。
この使用例は、変形［１０５］を有し、世話人が融資要求の管理に関与する。このシナリオは以下のステップを有する。
【0098】
【表2】
この例示的な使用状況では、借り手は、融資要求を引き下ろすために準備された保証人に関する情報を提供したいと望む。
【0099】
【表3】
この例では、借り手は、見込み貸し手に安心として提供するために彼らが用意された担保に関する情報を含めたいと望む。
【0100】
このシナリオは、以下の変更と共に説明される。
【0101】
【表4】
【0102】
【表5】
この例では、見込み融資参加者、つまり借り手、貸し手、又は世話人は、彼らが、ブロックチェーンに発行される新しい要求に確実に気付く必要がある。
【0103】
［表２］
【0104】
【表6】
この例では、応答人は、ブロックチェーンに発行された融資オファー及び／又は要求に応答したいと望む。
【0105】
［表３］
【0106】
【表7】
【0107】
＜詳細事項を照合する＞
この例では、世話人は、世話人のサービスと引き換えに関心パーティ間で結合コントラクトを生成するために、見込み融資要求及び／又は融資オファーを照合したいと望む。
この例では、世話人は、世話人のサービスと引き換えに関心パーティ間で結合コントラクトを生成するために、見込み融資要求及び／又は融資オファーを照合したいと望む。
【0108】
＜主な成功シナリオ＞
［表４］
［表４］
【0109】
【表8】
この例では、貸し手は、合意した条項に従い引き下ろしできるように、借り手に融資のための資金を前払したいと望む。
【0110】
［表５］
【0111】
【表9】
この例では、借り手は、融資を受けるために、エスクロー期間に資金のための合意した担保を置きたいと望む。
【0112】
［表６］
【0113】
【表10】
この例では、借り手は、前払いされた資金を引き下ろし、融資合意に入る。
【0114】
【表11】
この例では、借り手は、合意した条項及び条件に従い、融資に対して返済を行いたいと望む。
【0115】
【表12】
この例では、借り手は、融資の条項が満たされると、公開された融資を保証するために使用された担保を有したいと望む。
【0116】
【表13】
上述の使用例は、世話人及び貸し手を別個のエンティティとして記載した。しかしながら、多数の現実世界のシナリオでは、世話人及び貸し手は、同じエンティティであり得る。これは、必要なステップを変更しないが、開発の複雑さを簡略化する。
【0117】
＜世話人の除去＞
上述の使用例は、貸し手と借り手との間でトランザクションを仲介するために、世話人エージェントに依存する。上述のシナリオでは、世話人は、貸し手及び借り手の両者のためのプロセスに（交渉を促進する、及び返済を決定する点で）物的価値を追加するとして議論されたが、貸し手から借り手に資金を直接前払いするために、保険コントラクトを使用することが可能である。このシナリオでは、以下の通りである。
・借り手は、引き下ろしスクリプトアドレスを生成する責任がある。これは機能上確定的なので、貸し手は、生成されたスクリプトアドレスが提案された融資に関連付けられたメタデータと一致することを検証することもできる。
・貸し手の融資トランザクションは次に僅かに手直しされる：
＋貸し手のインプットは、明らかに、変更無しで前払いされている融資のインプットである；
＋これは、貸し手が２つのトランザクションで前払いすることを要求して良い。１つ目は明示的目標インプット値によりアウトプットを生成するため、２つ目は融資を前払いするためである；
＋アウトプット値は、所与の貸し手からの前払い額に拘わらず、要求された融資の合計値である；
＋インプット署名は、署名が貸し手のインプットに制限されること及びトランザクションのインプットの全部ではないことを意味するSIGHASH_ALL|SIGHASH_ANYONECANPAYを用いて署名される。
・借り手は、次に、十分な資金が種々の貸し手からプールにコミットされると、任意の時点で融資を引き下ろしできる。
上述の使用例は、貸し手と借り手との間でトランザクションを仲介するために、世話人エージェントに依存する。上述のシナリオでは、世話人は、貸し手及び借り手の両者のためのプロセスに（交渉を促進する、及び返済を決定する点で）物的価値を追加するとして議論されたが、貸し手から借り手に資金を直接前払いするために、保険コントラクトを使用することが可能である。このシナリオでは、以下の通りである。
・借り手は、引き下ろしスクリプトアドレスを生成する責任がある。これは機能上確定的なので、貸し手は、生成されたスクリプトアドレスが提案された融資に関連付けられたメタデータと一致することを検証することもできる。
・貸し手の融資トランザクションは次に僅かに手直しされる：
＋貸し手のインプットは、明らかに、変更無しで前払いされている融資のインプットである；
＋これは、貸し手が２つのトランザクションで前払いすることを要求して良い。１つ目は明示的目標インプット値によりアウトプットを生成するため、２つ目は融資を前払いするためである；
＋アウトプット値は、所与の貸し手からの前払い額に拘わらず、要求された融資の合計値である；
＋インプット署名は、署名が貸し手のインプットに制限されること及びトランザクションのインプットの全部ではないことを意味するSIGHASH_ALL|SIGHASH_ANYONECANPAYを用いて署名される。
・借り手は、次に、十分な資金が種々の貸し手からプールにコミットされると、任意の時点で融資を引き下ろしできる。
【0118】
留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する（comprising又はcomprises）」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する（comprises）」は「含む（includes）又は構成される（consists of）」を意味し、「有する（comprising）」は「含む（including）又は構成される（including of）」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、１つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることが出来ないことを示すものではない。
【符号の説明】
【0119】
１００ 融資を開始する
２００ ブロックチェーンを監視する
３００ 融資に応答する
４００ 詳細事項を照合する
５００ 資金を前払いする
６００ 担保を前払いする
７００ 引き出し
８００ 返済する
９００ 担保を解放する
２００ ブロックチェーンを監視する
３００ 融資に応答する
４００ 詳細事項を照合する
５００ 資金を前払いする
６００ 担保を前払いする
７００ 引き出し
８００ 返済する
９００ 担保を解放する
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【外国語明細書】