特表 2024-547030 分散型台帳ベースのマルチ通貨の決済及び精算

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-26

(54)【発明の名称】分散型台帳ベースのマルチ通貨の決済及び精算

(51)【国際特許分類】

   G06Q 20/00 20120101AFI20241219BHJP

【ＦＩ】

G06Q20/00

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024536412

(86)(22)【出願日】2022-12-16

(85)【翻訳文提出日】2024-08-14

(86)【国際出願番号】 SG2022050914

(87)【国際公開番号】W WO2023113698

(87)【国際公開日】2023-06-22

(31)【優先権主張番号】17/644,892

(32)【優先日】2021-12-17

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】524229299

【氏名又は名称】パーティオール・ピーティーイー・リミテッド

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(72)【発明者】

【氏名】マレラ，ナビーン

(72)【発明者】

【氏名】オッディラジュ，スリムク

(72)【発明者】

【氏名】アッタード，マーク・ジェイ

(72)【発明者】

【氏名】ブチャール，アトゥル

(72)【発明者】

【氏名】デソウザ，キース

(72)【発明者】

【氏名】テイ，ジェンキアン

(72)【発明者】

【氏名】リー，ムー・フア

(72)【発明者】

【氏名】キーム，ヌ・フェン

(72)【発明者】

【氏名】ロー，チャン・チン

【テーマコード（参考）】

5L020

【Ｆターム（参考）】

5L020AA21

(57)【要約】

分散型台帳システムは、分散型台帳ネットワークにおけるブロックチェーン・ベースの分散型台帳に第１参加銀行預金口座を維持する第１参加銀行と関連する第１分散型台帳ノードと、ブロックチェーン・ベースの分散型台帳に第２参加銀行預金口座を維持する第２参加銀行と関連する第２分散型台帳ノードと、ブロックチェーン・ベースの分散型台帳にリクイディティ・プロバイダ預金口座を維持するリクイディティ・プロバイダと関連する第３分散型台帳ノードとを含み得る。コンセンサス・アルゴリズムは、分散型台帳ノードにおいて動作し、ブロックチェーン・ベースの分散型台帳をアップデートし、そこにおいて、分散型台帳ノードにわたってのブロックチェーン・ベースの分散型台帳の複数のコピーと、第１参加銀行預金口座、第２参加銀行預金口座、及び／又はリクイディティ・プロバイダ預金口座と関係するトランザクションとが、ブロックチェーン・ベースの分散型台帳へのブロックへ付加される。

【特許請求の範囲】

【請求項1】

分散型台帳システムであって、
分散型台帳ネットワークにおけるブロックチェーン・ベースの分散型台帳に第１参加銀行預金口座を維持する第１参加銀行と関連する第１分散型台帳ノードと、
前記分散型台帳ネットワークにおける前記ブロックチェーン・ベースの分散型台帳に第２参加銀行預金口座を維持する第２参加銀行と関連する第２分散型台帳ノードと、
前記分散型台帳ネットワークにおける前記ブロックチェーン・ベースの分散型台帳にリクイディティ・プロバイダ預金口座を維持するリクイディティ・プロバイダと関連する第３分散型台帳ノードと
を含み、
コンセンサス・アルゴリズムは、前記分散型台帳ノードにおいて動作し、前記分散型台帳ノードにまたがって存在する前記ブロックチェーン・ベースの分散型台帳の複数のコピーと、前記第１参加銀行預金口座、前記第２参加銀行預金口座、及び／又は前記リクイディティ・プロバイダ預金口座と関係するトランザクションとが、前記ブロックチェーン・ベースの分散型台帳へのブロックに付加される、ブロックチェーン・ベースの分散型台帳をアップデートする
分散型台帳システム。

【請求項2】

請求項１の分散型台帳システムであって、前記トランザクションはデポジット・トランザクションを含む、分散型台帳システム。

【請求項3】

請求項１の分散型台帳システムであって、前記トランザクションは引き出しトランザクションを含む、分散型台帳システム。

【請求項4】

請求項１の分散型台帳システムであって、前記トランザクションはトランスファー・トランザクションを含む、分散型台帳システム。

【請求項5】

請求項１の分散型台帳システムであって、前記第１参加銀行預金口座と前記第２参加銀行預金口座と前記リクイディティ・プロバイダ預金口座とに関してのバランスおよびトランザクションの情報は、それぞれ、前記第１参加銀行と前記第２参加銀行と前記リクイディティ・プロバイダにプライベートなものである、分散型台帳システム。

【請求項6】

請求項１の分散型台帳システムであって、前記第１参加銀行と前記第２参加銀行との間でのトランザクションに関してのトランザクション・ペイロードは、前記第１参加銀行と前記第２参加銀行にプライベートなものである、分散型台帳システム。

【請求項7】

請求項６の分散型台帳システムであって、前記第１参加銀行と前記第２参加銀行との間での前記トランザクションに関しての前記トランザクション・ペイロードは、前記第１参加銀行と前記第２参加銀行とに関してのプライベート・ステートへ書き込まれ、前記トランザクション・ペイロードのハッシュは、前記分散型台帳へ書き込まれる、分散型台帳システム。

【請求項8】

分散型台帳ベースのマルチ通貨の決済及び精算の方法であって、
第１金融機関のための第１分散型台帳ノードで、支払人から、第２金融機関と関連する受取人へ資金をトランスファーするためのトランスファー・リクエストを受け取ることと、
前記第１分散型台帳ノードにより、対称鍵を生成することと、
前記第１分散型台帳ノードにより、前記対称鍵を用いて前記トランザクションに関するトランザクション・ペイロードを暗号化することと、
前記第１分散型台帳ノードにより、第２金融機関のための公開鍵を取り出すことと、
前記第１分散型台帳ノードにより、前記第１金融機関のための秘密鍵と前記第２金融機関のための前記公開鍵とを用いて第１金融機関／第２金融機関共有鍵を生成することと、
前記第１分散型台帳ノードにより、前記第１金融機関／第２金融機関共有鍵を用いて前記対称鍵を暗号化することと、
前記第１分散型台帳ノードにより、暗号化した前記トランザクション・ペイロードと暗号化した前記対称鍵とを前記第２金融機関のための第２分散型台帳ノードへ送ることと、前記第２分散型台帳ノードは、前記第１金融機関のための公開鍵と前記第２金融機関のための秘密鍵とを用いて前記第１金融機関／第２金融機関共有鍵を生成し、前記第１金融機関／第２金融機関共有鍵を用いて前記対称鍵の暗号解除を行い、前記対称鍵を用いて前記トランザクション・ペイロードの暗号解除を行い、前記トランザクション・ペイロードを第２金融機関プライベート・ステートへ書き込むことと、
前記第１分散型台帳ノードにより、リクイディティ・プロバイダのための公開鍵を取り出すことと、
前記第１分散型台帳ノードにより、前記第１金融機関のための秘密鍵と前記リクイディティ・プロバイダのための前記公開鍵とを用いて第１金融機関／リクイディティ・プロバイダ共有鍵を生成することと、
前記第１分散型台帳ノードにより、前記第１金融機関／リクイディティ・プロバイダ共有鍵を用いて前記対称鍵を暗号化することと、
前記第１分散型台帳ノードにより、暗号化した前記トランザクション・ペイロードと暗号化した前記対称鍵とを前記リクイディティ・プロバイダのためのリクイディティ・プロバイダ分散型台帳ノードへ送ることと、前記リクイディティ・プロバイダ分散型台帳ノードは、前記第１金融機関のための公開鍵と前記リクイディティ・プロバイダのための秘密鍵とを用いて前記金融機関／リクイディティ・プロバイダ共有鍵を生成し、前記金融機関／リクイディティ・プロバイダ共有鍵を用いて前記対称鍵の暗号解除を行い、前記対称鍵を用いて前記トランザクション・ペイロードの暗号解除を行い、前記トランザクション・ペイロードをリクイディティ・プロバイダ・プライベート・ステートへ書き込むことと、
前記第１分散型台帳ノードにより、暗号化された前記トランザクション・ペイロードのハッシュを生成することと、
前記第１分散型台帳ノードにより、暗号化された前記トランザクション・ペイロードの前記ハッシュを前記分散型台帳へ提出することと、
を含み、
前記第１分散型台帳ノードにおけるスマート・コントラクトは、前記第１金融機関に関する口座がトランザクションのための十分な資金を有することを確認し、前記資金を、前記分散型台帳における前記第１金融機関に関する前記口座から前記分散型台帳における前記第２金融機関に関する口座へ自動的にトランスファーする、
方法。

【請求項9】

請求項８の方法であって、前記スマート・コントラクトは、更に、前記第１金融機関の前記口座と前記第２金融機関の前記口座とに関してバランス・ラダーを再計算する、方法。

【請求項10】

請求項８の方法であって、前記第１金融機関分散型台帳ノードと前記リクイディティ・プロバイダ分散型台帳ノードとが前記トランザクション・ペイロードの暗号解除を行い、それをそれらそれぞれのプライベート・ステートへ書き込んだ後に、暗号化された前記トランザクション・ペイロードの前記ハッシュが生成される、方法。

【請求項11】

請求項８の方法であって、前記スマート・コントラクトは、更に、前記第１金融機関に関する前記口座又は前記第２金融機関に関する前記口座が閉鎖又は凍結されていないことを確認する、方法。

【請求項12】

請求項８の方法であって、前記確認の結果は、前記第２分散型台帳ノードと前記リクイディティ・プロバイダ分散型台帳ノードとで実行されるスマート・コントラクトへ複写される、方法。

【請求項13】

請求項８の方法であって、前記第１金融機関に関する前記口座から前記第２金融機関に関する前記口座への前記資金のトランスファーは、支払人と受取人との間の個別のアグリーメントに基づく、方法。

【請求項14】

分散型台帳ネットワークにおけるプライベート・ステート再同期の方法であって、
リクイディティ・プロバイダのためのリクイディティ・プロバイダ分散型台帳ノードにおいて実行されるスマート・コントラクトにより、前記リクイディティ・プロバイダ分散型台帳ノードでの第１金融機関と関連する複数のアカウンティング・エントリのそれぞれのハッシュを生成することと、
前記スマート・コントラクトにより、第１金融機関分散型台帳ノードへ前記ハッシュを送ることと、前記第１金融機関分散型台帳ノードは、前記第１金融機関分散型台帳ノードに関してのプライベート・ステートにおける複数のアカウンティング・エントリのそれぞれのハッシュを生成し、前記リクイディティ・プロバイダ分散型台帳ノードからの前記ハッシュと前記第１金融機関分散型台帳ノードにより生成された前記ハッシュとを比較することと、
前記スマート・コントラクトにより、前記リクイディティ・プロバイダ分散型台帳ノードにおける前記複数のアカウンティング・エントリのうちの１以上のものと、前記第１金融機関台帳ノードにおける前記複数のアカウンティング・エントリのうちの前記１以上のものとを再同期することと
を含む方法。

【請求項15】

請求項１４の方法であって、再同期された前記複数のアカウンティング・エントリのうちの前記１以上のものは、前記第１金融機関分散型台帳ノードにより生成されたハッシュと一致しない前記リクイディティ・プロバイダ分散型台帳ノードからのハッシュを有するもとの識別される、方法。

【請求項16】

請求項１４の方法であって、前記リクイディティ・プロバイダ分散型台帳ノードで実行される前記スマート・コントラクトは周期的にハッシュを生成する、方法。

【請求項17】

請求項１４の方法であって、前記リクイディティ・プロバイダ分散型台帳ノードで実行される前記スマート・コントラクトは、前記第１金融機関分散型台帳ノードにおけるプライベート・ステート・ダイバージェンスに応答してハッシュを生成する、方法。

【請求項18】

分散型台帳ベースの多層負債のための方法であって、
支払人側参加銀行分散型台帳ノードにより、或る額を、分散型台帳ネットワークにおける分散型台帳のオンチェーン支払人側口座へトランスファーする命令を受け取ることと、
前記支払人側参加銀行分散型台帳ノードにより、前記額に関してオフチェーン支払人側口座の借方への記入を行い、前記額の前記支払人側オンチェーン口座の貸方への記入を行うことと、
前記支払人から及び前記支払人側参加銀行により、前記支払人側オンチェーン口座の借方への記入を行い、受取人側オンチェーン口座の貸方への記入を行って支払を行う命令を受け取ることと、前記受取人側オンチェーン口座は、前記分散型台帳ネットワークにおける別の参加銀行に属することと、
前記支払人側参加銀行分散型台帳ノードにより及び前記リクイディティ・プロバイダ分散型台帳ノードへ、支払人側参加銀行のオンチェーン口座への資金のデポジットを要求することと、前記リクイディティ・プロバイダ分散型台帳ノードは、支払人側参加銀行オフチェーン口座の借方への記入を行い、前記支払人側参加銀行オンチェーン口座の貸方への記入を行うことと、
前記支払人側参加銀行分散型台帳ノードにより、受取人側オンチェーン口座への支払トランスファーを開始するために前記分散型台帳における第１スマート・コントラクトを呼び出すことと、前記第１スマート・コントラクトは、前記リクイディティ・プロバイダ分散型台帳ノードへ前記支払の精算を成し遂げるように通知し、前記リクイディティ・プロバイダ分散型台帳ノードは、第２スマート・コントラクトを呼び出して、前記支払人側参加銀行オンチェーン口座の借方への記入と前記支払人側参加銀行オンチェーン口座の貸方への記入とが行われるようにし、前記受取人側参加銀行分散型台帳ノードと前記受取人側参加銀行分散型台帳ノードへ、精算が完了したことを通知し、前記受取人側参加銀行分散型台帳ノードは、第３スマート・コントラクトを呼び出して、前記受取人側参加銀行オンチェーン口座の借方への記入と前記受取人側オンチェーン預金口座の貸方への記入とが行われるようにすることと
を含む方法。

【請求項19】

請求項１８の方法であって、前記支払人側参加銀行分散型台帳ノードは、一対のつなぎ勘定を用いて、前記額に関して前記オフチェーン支払人側口座の借方への記入を行い、前記額の前記支払人側オンチェーン口座の貸方への記入を行う、方法。

【請求項20】

請求項１８の方法であって、前記受取人側参加銀行は、前記受取人のオンチェーン預金口座の借方への記入を行い、資金をオフチェーン預金口座へトランスファーするように、構成される、方法。

【発明の詳細な説明】

【技術分野】

【0001】

発明の背景
１． 発明の分野
[0001] 実施形態は、複数の別個のエンティティにわたっての分散型台帳ベースのマルチ通貨の決済及び精算に関する。

【背景技術】

【0002】

２． 関連する技術の説明
[0002] 典型的には、銀行ベースのブロックチェーン支払ネットワークは、１レベルの負債(one level of liabilities)を用いるか、又は、それらはオブジェクト貨幣（object money）の使用を提案する。すなわち、負債は、１つのエンティティ（例えば、市中銀行、中央銀行、又は１つの受託組織／管理会社）に存在する。１レベルの負債を用いるモデルは、特に、全ての参加者が１つのエンティティとの直接的な関係を要求する場合には、規模の変更が難しい。そのようなモデルは、リスクや業務上の理由があるため、規模の変更を行うことは、難しいが興味をそそられる。

【発明の概要】

【0003】

発明の概要
[0003] 複数の異なるエンティティにわたっての分散型台帳ベースのマルチ通貨の決済及び精算が開示される。１つの実施形態では、分散型台帳システムは、分散型台帳ネットワークにおけるブロックチェーン・ベースの分散型台帳に第１参加銀行預金口座を維持する第１参加銀行と関連する第１分散型台帳ノードと、前記分散型台帳ネットワークにおける前記ブロックチェーン・ベースの分散型台帳に第２参加銀行預金口座を維持する第２参加銀行と関連する第２分散型台帳ノードと、前記分散型台帳ネットワークにおける前記ブロックチェーン・ベースの分散型台帳にリクイディティ・プロバイダ預金口座を維持するリクイディティ・プロバイダと関連する第３分散型台帳ノードとを含も得る。コンセンサス・アルゴリズムは、前記分散型台帳ノードにおいて動作し、前記ブロックチェーン・ベースの分散型台帳をアップデートし、そこにおいては、前記分散型台帳ノードにわたって存在する前記ブロックチェーン・ベースの分散型台帳の複数のコピーと、前記第１参加銀行預金口座、前記第２参加銀行預金口座、及び／又は前記リクイディティ・プロバイダ預金口座と関係するトランザクションとが、前記ブロックチェーン・ベースの分散型台帳へのブロックへ付加される。

【0004】

[0004] １つの実施形態では、前記トランザクションはデポジット・トランザクションを含み得る。

【0005】

[0005] １つの実施形態では、前記トランザクションは引き出しトランザクションを含み得る。

【0006】

[0006] １つの実施形態では、前記トランザクションはトランスファー・トランザクションを含み得る。

【0007】

[0007] １つの実施形態では、前記第１参加銀行預金口座と前記第２参加銀行預金口座と前記リクイディティ・プロバイダ預金口座とに関してのバランスおよびトランザクションの情報は、それぞれ、前記第１参加銀行と前記第２参加銀行と前記リクイディティ・プロバイダとのプライベートなものであり得る。

【0008】

[0008] １つの実施形態では、前記第１参加銀行と前記第２参加銀行との間でのトランザクションに関してのトランザクション・ペイロードは、前記第１参加銀行と前記第２参加銀行とのプライベートなものであり得る。

【0009】

[0009] １つの実施形態では、前記第１参加銀行と前記第２参加銀行との間での前記トランザクションに関しての前記トランザクション・ペイロードは、前記第１参加銀行と前記第２参加銀行とに関してのプライベート・ステートへ書き込まれ得、前記トランザクション・ペイロードのハッシュは、前記分散型台帳へ書き込まれ得る。

【0010】

[0010] 別の実施形態によると、分散型台帳ベースのマルチ通貨の決済及び精算の方法は、第１金融機関のための第１分散型台帳ノードで、支払人から、第２金融機関と関連する受取人へ資金をトランスファーするためのトランスファー・リクエストを受け取ることと、前記第１分散型台帳ノードにより、対称鍵を生成することと、前記第１分散型台帳ノードにより、前記対称鍵を用いて前記トランザクションに関するトランザクション・ペイロードを暗号化することと、前記第１分散型台帳ノードにより、第２金融機関のための公開鍵を取り出すことと、前記第１分散型台帳ノードにより、前記第１金融機関のための秘密鍵と前記第２金融機関のための前記公開鍵とを用いて第１金融機関／第２金融機関共有鍵を生成することと、前記第１分散型台帳ノードにより、前記第１金融機関／第２金融機関共有鍵を用いて前記対称鍵を暗号化することと、前記第１分散型台帳ノードにより、暗号化した前記トランザクション・ペイロードと暗号化した前記対称鍵とを前記第２金融機関のための第２分散型台帳ノードへ送ることと、前記第２分散型台帳ノードは、前記第１金融機関のための公開鍵と前記第２金融機関のための秘密鍵とを用いて前記第１金融機関／第２金融機関共有鍵を生成し、前記第１金融機関／第２金融機関共有鍵を用いて前記対称鍵の暗号解除を行い、前記対称鍵を用いて前記トランザクション・ペイロードの暗号解除を行い、前記トランザクション・ペイロードを第２金融機関プライベート・ステートへ書き込むことと、前記第１分散型台帳ノードにより、リクイディティ・プロバイダのための公開鍵を取り出すことと、前記第１分散型台帳ノードにより、前記第１金融機関のための秘密鍵と前記リクイディティ・プロバイダのための前記公開鍵とを用いて第１金融機関／リクイディティ・プロバイダ共有鍵を生成することと、前記第１分散型台帳ノードにより、前記第１金融機関／リクイディティ・プロバイダ共有鍵を用いて前記対称鍵を暗号化することと、前記第１分散型台帳ノードにより、暗号化した前記トランザクション・ペイロードと暗号化した前記対称鍵とを前記リクイディティ・プロバイダのためのリクイディティ・プロバイダ分散型台帳ノードへ送ることと、前記リクイディティ・プロバイダ分散型台帳ノードは、前記第１金融機関のための公開鍵と前記リクイディティ・プロバイダのための秘密鍵とを用いて前記金融機関／リクイディティ・プロバイダ共有鍵を生成し、前記金融機関／リクイディティ・プロバイダ共有鍵を用いて前記対称鍵の暗号解除を行い、前記対称鍵を用いて前記トランザクション・ペイロードの暗号解除を行い、前記トランザクション・ペイロードをリクイディティ・プロバイダ・プライベート・ステートへ書き込むことと、前記第１分散型台帳ノードにより、暗号化された前記トランザクション・ペイロードのハッシュを生成することと、前記第１分散型台帳ノードにより、暗号化された前記トランザクション・ペイロードの前記ハッシュを前記分散型台帳へ提出することと、を含み得るものであり、前記第１分散型台帳ノードにおけるスマート・コントラクトは、前記第１金融機関に関する口座がトランザクションのための十分な資金を有することを確認し、前記資金を、前記分散型台帳における前記第１金融機関に関する前記口座から前記分散型台帳における前記第２金融機関に関する口座へ自動的にトランスファーする。

【0011】

[0011] １つの実施形態では、前記スマート・コントラクトは、更に、前記第１金融機関に関しての前記口座と前記第２金融機関に関しての前記口座とに関してのバランス・ラダー(balance ladder)を再計算し得る。

【0012】

[0012] １つの実施形態では、前記第１金融機関分散型台帳ノードと前記リクイディティ・プロバイダ分散型台帳ノードとが前記トランザクション・ペイロードの暗号解除を行い、それをそれらそれぞれのプライベート・ステートへ書き込んだ後に、暗号化された前記トランザクション・ペイロードの前記ハッシュが生成され得る。

【0013】

[0013] １つの実施形態では、前記スマート・コントラクトは、更に、前記第１金融機関に関する前記口座又は前記第２金融機関に関する前記口座が閉鎖又は凍結されていないことを確認し得る。

【0014】

[0014] １つの実施形態では、前記確認の結果は、前記第２分散型台帳ノードと前記リクイディティ・プロバイダ分散型台帳ノードとで実行されるスマート・コントラクトへ複写され得る。

【0015】

[0015] １つの実施形態では、前記第１金融機関に関する前記口座から前記第２金融機関に関する前記口座への前記資金のトランスファーは、支払人と受取人との間での個別のアグリーメントに基づき得る。

【0016】

[0016] 別の実施形態によると、分散型台帳ネットワークにおけるプライベート・ステート再同期の方法は、リクイディティ・プロバイダのためのリクイディティ・プロバイダ分散型台帳ノードにおいて実行されるスマート・コントラクトにより、前記リクイディティ・プロバイダ分散型台帳ノードでの第１金融機関と関連する複数のアカウンティング・エントリのそれぞれのハッシュを生成することと、前記スマート・コントラクトにより、第１金融機関分散型台帳ノードへ前記ハッシュを送ることと、前記第１金融機関分散型台帳ノードは、前記第１金融機関分散型台帳ノードに関してのプライベート・ステートにおける複数のアカウンティング・エントリのそれぞれのハッシュを生成し、前記リクイディティ・プロバイダ分散型台帳ノードからの前記ハッシュと前記第１金融機関分散型台帳ノードにより生成された前記ハッシュとを比較することと、前記スマート・コントラクトにより、前記リクイディティ・プロバイダ分散型台帳ノードにおける前記複数のアカウンティング・エントリのうちの１以上のものと、前記第１金融機関台帳ノードにおける前記複数のアカウンティング・エントリのうちの前記１以上のものとを再同期することとを含み得る。

【0017】

[0017] １つの実施形態では、再同期された前記複数のアカウンティング・エントリのうちの前記１以上のものは、前記第１金融機関分散型台帳ノードにより生成されたハッシュと一致しない前記リクイディティ・プロバイダ分散型台帳ノードからのハッシュを有するもとの識別され得る。

【0018】

[0018] １つの実施形態では、前記リクイディティ・プロバイダ分散型台帳ノードで実行される前記スマート・コントラクトは周期的にハッシュを生成し得る。

【0019】

[0019] １つの実施形態では、前記リクイディティ・プロバイダ分散型台帳ノードで実行される前記スマート・コントラクトは、前記第１金融機関分散型台帳ノードにおけるプライベート・ステート・ダイバージェンスに応答してハッシュを生成し得る。

【0020】

[0020] 別の実施形態によると、分散型台帳ベースの多層負債のための方法は、支払人側参加銀行分散型台帳ノードにより、或る額を、分散型台帳ネットワークにおける分散型台帳のオンチェーン支払人側口座へトランスファーする命令を受け取ることと、前記支払人側参加銀行分散型台帳ノードにより、前記額に関してオフチェーン支払人側口座の借方への記入を行い、前記額の前記支払人側オンチェーン口座の貸方への記入を行うことと、前記支払人から及び前記支払人側参加銀行により、前記支払人側オンチェーン口座の借方への記入を行い、受取人側オンチェーン口座の貸方への記入を行って支払を行う命令を受け取ることと、前記受取人側オンチェーン口座は、前記分散型台帳ネットワークにおける別の参加銀行に属することと、前記支払人側参加銀行分散型台帳ノードにより及び前記リクイディティ・プロバイダ分散型台帳ノードへ、支払人側参加銀行のオンチェーン口座への資金のデポジットを要求することと、前記リクイディティ・プロバイダ分散型台帳ノードは、支払人側参加銀行オフチェーン口座の借方への記入を行い、前記支払人側参加銀行オンチェーン口座の貸方への記入を行うことと、前記支払人側参加銀行分散型台帳ノードにより、受取人側オンチェーン口座への支払トランスファーを開始するために前記分散型台帳における第１スマート・コントラクトを呼び出すことと、前記第１スマート・コントラクトは、前記リクイディティ・プロバイダ分散型台帳ノードへ前記支払の精算を成し遂げるように通知し、前記リクイディティ・プロバイダ分散型台帳ノードは、第２スマート・コントラクトを呼び出して、前記支払人側参加銀行オンチェーン口座の借方への記入と前記支払人側参加銀行オンチェーン口座の貸方への記入とが行われるようにし、前記受取人側参加銀行分散型台帳ノードと前記受取人側参加銀行分散型台帳ノードへ、精算が完了したことを通知し、前記受取人側参加銀行分散型台帳ノードは、第３スマート・コントラクトを呼び出して、前記受取人側参加銀行オンチェーン口座の借方への記入と前記受取人側オンチェーン預金口座の貸方への記入とが行われるようにすることとを含み得る。

【0021】

[0021] １つの実施形態では、前記支払人側参加銀行分散型台帳ノードは、一対のつなぎ勘定(bridging account)を用いて、前記額に関して前記オフチェーン支払人側口座の借方への記入を行い、前記額の前記支払人側オンチェーン口座の貸方への記入を行うことができる。

【0022】

[0022] １つの実施形態では、前記受取人側参加銀行は、前記受取人のオンチェーン預金口座の借方への記入を行い、資金をオフチェーン預金口座へトランスファーするように、構成することができる。

【0023】

[0023] 本発明の完全な理解を容易にするために、ここで添付の図面を参照する。図面は、本発明を限定するものと解釈すべきではなく、単に、様々な構成及び実施形態を例示することを意図している。

【図面の簡単な説明】

【0024】

【図1】図１は、実施形態に従った、複数の個別のエンティティにわたっての分散型台帳ベースのマルチ通貨の決済及び精算のためのシステムを示す。

【図2】図２は、分散型台帳ベースのマルチ通貨の決済及び精算のための方法を示す。

【図3】図３は、１つの実施形態に従った、分散型台帳ネットワークにおけるプライベート・ステート再同期のための方法を示す。

【図4】図４は、実施形態に従った、層になった負債及びリクイディティ・プロバイダを伴った、共有される台帳の具体例を示す。

【図5】図５は、１つの実施形態に従った、分散型台帳ベースの多層の負債のための方法を示す。

【図6A】図６Ａは、実施形態に従った、リクイディティ・プロバイダ銀行を介しての分散型台帳の預金口座への資金の直接的な預金のための例示のフローを示す。

【図6B】図６Ｂは、実施形態に従った、リクイディティ・プロバイダ銀行を介しての直接的な引き出しのための例示のフローを示す。

【図7A】図７Ａは、実施形態に従った、参加銀行を介しての分散型台帳の預金口座への資金の預金のための例示のフローを示す。

【図7B】図７Ｂは、実施形態に従った、参加銀行を介しての直接的な引き出しのための例示のフローを示す。

【図8】図８は、実施形態に従った、参加銀行間でのトランスファーのための例示のフローを示す。

【発明を実施するための形態】

【0025】

[0034] 米国仮特許出願シリアル番号６３／０７１７２１と米国仮特許出願シリアル番号６３／０７１７２７とのそれぞれの開示の全体を、この参照により、ここに組み込む。

【0026】

[0035] 実施形態は、複数の別個のエンティティにわたっての分散型台帳ベースのマルチ通貨の決済及び精算に関する。実施形態は、複数の金融機関が、共有される分散型台帳を、ノストロ口座(nostro account)、預金口座（deposit account）などのそれらそれぞれの台帳として用いることを、容易にする。従って、口座間での精算が簡素にされ得る。

【0027】

[0036] １つの実施形態では、分散型台帳は、許可型の分散型台帳であり得る。

【0028】

[0037] 例えば、実施形態は、層になった構成を用いることにより、複数の関係者（parties）間での負債の精算を容易にする。利点は、各銀行がそれら銀行の既存のリスク内及び資本枠組内で作業するようにする能力を含む。しかしながら、ネットワークは、何れの銀行のインフラストラクチャからも独立している分散型ホスティングがなされるので、任意の時点（例えば、１日の２４時間、１週間の７日）でトランスファーを行うことを、容易にすることができる。従って、銀行は、それらの支店銀行営業時間や他の銀行の営業時間についての制限無しに、預金負債のトランスファーを行うことができる。

【0029】

[0038] 実施形態は、下記の利点、（１）各層からリクイディティ・プロバイダにわたっての可視性を伴った即座の、層になった負債のデポジット、トランスファー、及び引き出しの能力と、（２）低い層の負債が高い層の預金で１：１で裏書き(backed)されることを保証して、新たな貨幣乗数効果(money multiplier effect)がないようにする能力と、（３）条件付き支払のためのビジネス・ルールとロジックとを用いて各層での預金をプログラムする能力と、（４）マーケット・メーカーがペイメント・バーサス・ペイメント方法におけるクロス通貨トランザクション（例えば、トランザクションの双方のレッグに関する預金を同時に精算するか、又は全くしない）を容易にする能力と、（５）法人顧客が銀行へ直接に指示することなく銀行非依存型インターフェースを介して預金口座を保持すること及び互いに支払を行うことを可能とする能力と、のうちの幾つか又は全てを提供し得る。銀行は、負債について、なおも最終的に責任があるが、トランスファーを容易にするために他のユーザ経験又はサービス・プロバイダが入ることを可能とする。実施形態は、これらの能力の幾つか又は全てを提供することができ、かつ会計、流動性供給、スクリーニング、チェックなどに関連する既存の銀行処理を維持することを保つことができる。

【0030】

[0039] ここで用いる用語「発行銀行（Issuing Bank）」又は「リクイディティ・プロバイダ」は、ブロックチェーン台帳に記録された直接的参加銀行の預金口座（例えば、要求払預金口座（ＤＤＡ）、ＣＡＳＡ口座など）に関するレコードの銀行を指し（即ち、そのような口座により証明されている預金負債は、発行銀行の負債として強制執行可能であり、直接的参加銀行の預金資産を表す）、そのような口座に関しての精算及び決済のサービスを提供する。「直接的参加銀行（direct participant bank）」は、ブロックチェーン台帳に記録された発行銀行に預金口座を保持する銀行を指す。幾つかの図面では、米国ドル（ＵＳＤ）の発行銀行が、分散型台帳の技術を用いて、決済及び精算のサービスを提供する。

【0031】

[0040] 実施形態では、ペイメント・バーサス・ペイメント又はＰｖＰのプロセスが提供され得る。ＰｖＰに関しては、フォーリン・エクスチェンジ（ＦＸ）・レートは、取引相手方金融機関により明確に提供されないであろう。各金融機関は、それらが支払う額及び通貨、及びそれらが受け取る予定の等しい額及び通貨を、提供することができる。この情報から、暗示されるＦＸレートを計算することができる。しかし、関係者は、ＦＸレートではなく、交換される額に同意するであろう。従って、ＰｖＰはエスクロー型の取り決めにも用いられ得るが、それはＦＸトレードの直接的結果ではない。

【0032】

[0041] 交換される額及び通貨に加えて、相手方は、バリュー・デート、及びトレード・ブッキングへの参照などのようなトランザクション参照を、提供することができる。双方の相手方により提供されるバリュー・デート及びトランザクション参照が一致するかぎり、ＰｖＰエクスチェンジを実行することができる。一致することは、双方の相手方の間での以前のアグリーメントの証拠である。

【0033】

[0042] 図１を参照すると、実施形態に従った分散型台帳ベースのマルチ通貨の決済及び精算のためのシステムのアーキテクチャ図である。システム１００は、複数の金融機関１１０（例えば、１１０_１、１１０_２、・・・、１１０_ｎ）を含むことができる。金融機関は、発行銀行、リクイディティ・プロバイダ、直接的参加銀行などを含むことができる。例えば、参加銀行は、法人を顧客として持つ金融機関であり、リクイディティ・プロバイダは、参加銀行を顧客として持つ金融機関である。

【0034】

[0043] 金融機関１１０は、ノードとして分散型台帳１２０とインターフェースすることができ、分散型台帳１２０にノストロ口座又は預金口座を維持することができる。１つの実施形態では、分散型台帳１２０での口座は、フィアット通貨、ステーブルコインなどを含めての任意の通貨のものであり得る。

【0035】

[0044] 金融機関１１０は、それぞれ、法人顧客や他の金融機関などのような複数の顧客（示さず）を有することができ、金融機関１１０は、それらの顧客のために分散型台帳１２０に口座を維持することができる。

【0036】

[0045] １つの実施形態では、分散型台帳１２０は、参加金融機関１１０のみがアクセス可能な、許可型の分散型台帳とすることができる。１つの実施形態では、分散型台帳１２０の口座におけるデータは、口座を維持したりトランザクションに関連するなどの金融機関１１０に関してプライベートとすることができる。例えば、データは、ホスト金融機関１１０のための秘密鍵を用いて暗号化することができる。

【0037】

[0046] １つの実施形態では、分散型台帳１２０は、ブロックチェーン・ベースの分散型台帳システムとすることができる。コンセンサス・アルゴリズムは、各参加金融機関１１０のためのノードなどのような複数の分散型コンピュータ・ノードで動作することができる。分散型台帳１２０の複数のコピーが、複数の分散型コンピュータ・ノードにわたって存在し得る。コンセンサス・アルゴリズムは、分散型コンピュータ・ノードのそれぞれで動作することができ、また、ブロックチェーン・ベースのシステムへブロックを付加することにより分散型台帳１２０を更新することができる。

【0038】

[0047] １つの実施形態では、各ノードは、各金融機関１１０に関してのパブリック・ステートとプライベート・ステートとを格納することができる。

【0039】

[0048] そのようなステートを含む分散型台帳の例は、米国特許出願シリアル番号６２／３１６８４１と米国特許番号１０７４９８４８とに開示されており、これらの開示の全体を、この参照により、ここに組み込む。

【0040】

[0049] １つの実施形態では、分散型台帳１２０へスマート・コントラクトを配置することができる。スマート・コントラクトは、データベース機能を含めての様々な機能を行うことができる。

【0041】

[0050] １つの実施形態では、追加の分散型台帳１２５（例えば、「サイド・チェーン」）を、必要に応じて且つ／又は望まれる場合には、提供することができる。例えば、サイド・チェーンは、フォーリン・エクスチェンジ・レートのアグリーメント、契約などについての情報を提供することができる。

【0042】

[0051] 実施形態は、金融機関１１０やそれらの顧客などのようなネットワーク参加者が、フォーリン・エクスチェンジ・トレードなどのようなサービスを提供することを可能にし、会社間でのトランスファーや外国為替預金の最適化などを提供する。システム１００はエコシステムを提供し、そこでは、ネットワーク参加者はスマート・コントラクトを配置することができ、それは預金口座トランスファーの基礎的能力の最上部へオーバーレイされる。

【0043】

[0052] 実施形態では、スマート・コントラクトのオラクルは、分散型台帳１２０に配置することができ、マーケット・データ・フィード（例えば、フォーリン・エクスチェンジ・レートのフィード、株価のフィードなど）を提供することができ、プライス・ディスカバリ機構として金融機関１１０により課されるトランザクション手数料をパブリッシュすることができる。金融機関１１０は、それら自体の鍵管理システム（ＫＭＳ）（示さず）でそれら自体の秘密鍵を管理することができ、それらの対応する公開鍵は、参加者のスマート・コントラクトのレジストリの分散型台帳１２０に格納することができ、そこでは登録された鍵のみが処理を行うことを許可される。

【0044】

[0053] 実施形態では、分散型台帳１２０の各口座は、様々なデート（date）を有することができ、それは、エンティティが台帳へポストされた日付（即ち、精算が行われたとき）である精算デートと、金融機関の総勘定台帳システムへブッキングするために用いられる業務日であるブック・デートと、利息発生目的(interest accrual purpose)のために用いられるバリュー・デートと、クレジット・リスクを予想するために用いられるエクスポージャー・デートとを含む。精算デートとブック・デートとは、週末及び非営業日に精算が行われたときには異なり得るが、その理由は、総勘定台帳は通常は非営業日に動作しないからである。

【0045】

[0054] これらのデートの組み合わせを、分散型台帳における個々のバランス・ラダー（ladder）を作成して維持するために、用いることができる。例えば、（１）利息発生を認識するために用いられる毎日のバランスである、バリュー・デート付きバランス・ラダー、（２）口座保持者が使用／引き出しする資金の毎日の予想されるアベイラビリティである、利用可能バランス・ラダー、（３）予想される将来のデビットを本日の使用には用いることができないものと認識する、口座保持者が使用／引き出しする資金の毎日の予想されるアベイラビリティである、決済される資金（cleared funds）バランス・ラダーである。そのような能力は、利付き口座及びオーバードラフト／クレジットの機能のサポートを提供する。

【0046】

[0055] 図２を参照すると、分散型台帳ベースのマルチ通貨の決済及び精算のための方法が、実施形態に従って開示されている。

【0047】

[0056] ステップ２００において、金融機関は、分散型台帳に、それらの顧客のためにノストロ口座、預金口座などのような口座を維持することができる。１つの実施形態では、分散型台帳は、許可型の分散型台帳とすることができ、トランザクションは、トランザクションの関係者ではないエンティティに対してプライベートとすることができる。

【0048】

[0057] ステップ２０５において、第１金融機関は、トランスファー・リクエストを、その分散型台帳ノードへ提出することができる。トランスファー・リクエストは、資金を第２金融機関へ送金するためのものとすることができる。

【0049】

[0058] ステップ２１０において、第１金融機関の分散型台帳ノードは、対称鍵を生成することができ、その対称鍵を用いてトランザクション・ペイロードを暗号化することができる。

【0050】

[0059] ステップ２１５において、第１金融機関は、第２金融機関の公開鍵をルックアップすることができ、第１金融機関の秘密鍵と第２金融機関の公開鍵とを用いて第１金融機関／第２金融機関共有鍵を生成することができる。

【0051】

[0060] ステップ２２０において、第１金融機関の分散型台帳ノードは、第１金融機関／第２金融機関共有鍵を用いて対称鍵を暗号化することができる。

【0052】

[0061] ステップ２２５において、第１金融機関の分散型台帳ノードは、暗号化したトランザクション・ペイロードと暗号化した対称鍵とを、第２金融機関の分散型台帳ノードへ送ることができる。

【0053】

[0062] ステップ２３０において、第２金融機関の分散型台帳ノードは、第１金融機関の公開鍵と第２金融機関の秘密鍵とを用いて、第１金融機関／第２金融機関共有鍵を生成することができる。

【0054】

[0063] ステップ２３５において、第２金融機関の分散型台帳ノードは、第１金融機関／第２金融機関共有鍵を用いて対称鍵の暗号解除を行うことができ、トランザクション・ペイロードの暗号解除のために対称鍵を用いることができる。第２金融機関の分散型台帳ノードは、暗号解除したトランザクション・ペイロードをそのプライベート・ステートへ書き込むことができる。

【0055】

[0064] ステップ２４０において、第１金融機関は、リクイディティ・プロバイダの公開鍵をルックアップすることができ、第１金融機関の秘密鍵とリクイディティ・プロバイダの公開鍵とを用いて、リクイディティ・プロバイダ金融機関と共に使用するために第１金融機関／リクイディティ・プロバイダ共有鍵を生成することができる。

【0056】

[0065] ステップ２４５において、第１金融機関の分散型台帳ノードは、第１金融機関／リクイディティ・プロバイダ共有鍵を用いて対称鍵を暗号化することができる。

【0057】

[0066] ステップ２５０において、第１金融機関の分散型台帳ノードは、暗号化したトランザクション・ペイロードと暗号化した対称鍵とを、リクイディティ・プロバイダの分散型台帳ノードへ送ることができる。

【0058】

[0067] ステップ２５５において、リクイディティ・プロバイダの分散型台帳ノードは、第１金融機関の公開鍵とリクイディティ・プロバイダの秘密鍵とを用いて、第１金融機関／リクイディティ・プロバイダ共有鍵を生成することができる。

【0059】

[0068] ステップ２６０において、リクイディティ・プロバイダの分散型台帳ノードは、第１金融機関／リクイディティ・プロバイダ共有鍵を用いて対称鍵の暗号解除を行うことができ、トランザクション・ペイロードの暗号解除を行うために対称鍵を用いることができる。リクイディティ・プロバイダの分散型台帳ノードは、暗号解除したトランザクション・ペイロードをそのプライベート・ステートへ書き込むことができる。

【0060】

[0069] ステップ２６５において、第１金融機関の分散型台帳ノードは、暗号化したトランザクション・ペイロードのハッシュを生成することができ、そのハッシュを分散型台帳へ提出することができる。実施形態では、ハッシュは、暗号化したペイロードが第２金融機関とリクイディティ・プロバイダとのとの双方へ送られて、双方がトランザクション・ペイロードの暗号解除を行った後の場合のみ、分散型台帳へ提出することができる。

【0061】

[0070] ステップ２７０において、スマート・コントラクトは、第１金融機関の口座がトランザクションのための十分な資金を有することや、クレジット口座番号（crediting account number）が存在するか否かや、その口座が閉鎖又は凍結されていないことなどを、証明することができる。例えば、第１金融機関が第１金融機関の分散型台帳ノードからトランザクションをトリガしているので、第１金融機関の分散型台帳ノードのスマート・コントラクトは、この証明を行う。証明の結果、即ち、検証に成功したか否か及び障害コードではないか否かが、次に、トランザクションの関係者である他の分散型台帳ノードの他のスマート・コントラクトへ複写される。

【0062】

[0071] ステップ２７５において、スマート・コントラクトは、資金を第１金融機関の口座から第２金融機関の口座へ自動的にトランスファーすることができる。１つの実施形態では、何らかのフォーリン・エクスチェンジが必要であれば、スマート・コントラクトは、フォーリン・エクスチェンジ・レートを指定する関係者間でのアグリーメントを引き出し、外部のソースなどからフォーリン・エクスチェンジ・レートを受け取ることができる。

【0063】

[0072] ステップ２８０において、スマート・コントラクトは、資金の移動に起因して口座に関してのバランス・ラダーを再計算することができる。

【0064】

[0073] 実施形態はプライバシー制約をインプリメントするので、分散型台帳ネットワークの全ての分散型台帳ノードが分散型台帳の同じコピーを有するものではなく、これは、「プライベート・ステート・ダイバージェンス」を生じさせることになり、これは、分散型台帳ノードは一般的には同期していないことを意味する。これは、コンセンサス機構を使用することを妨げ、送信におけるデータ損失を検出することに対しての異なるアプローチを必要とする。

【0065】

[0074] 例えば、ノストロ口座はリクイディティ・プロバイダのブックに保持されるので、リクイディティ・プロバイダの分散型台帳ノードの中のプライベート・データは、常に「ゴールデン・ソース」である。従って、実施形態では、リクイディティ・プロバイダのノストロ口座へポストされる全てのアカウンティング・エントリは、常に、リクイディティ・プロバイダの分散型台帳ノードから起きたものであり、次に、トランザクションの関係者である金融機関へ送られ得る。ネットワーク障害のためにデータがなくなった場合、それは、トランザクションの関係者である金融機関がそれらのアップデートを受け取らないという結果となる可能性が高く、従って、それらの金融機関の分散型台帳ノードにおけるアカウンティング・エントリは、リクイディティ・プロバイダのレコードから「ダイバージ」する。

【0066】

[0075] 従って、図３を参照すると、ステップ３０５において、特定の時間間隔やオンデマンドなどで、リクイディティ・プロバイダの分散型台帳ノードで実行されるスマート・コントラクトは、特定の口座に関しての時間窓の間に生成されたアカウンティング・エントリのハッシュを生成することができ、ステップ３１０において、そのハッシュを、その口座を有するそれぞれの金融機関へ送ることができる。

【0067】

[0076] ステップ３１５において、受取側の金融機関の分散型台帳ノードのスマート・コントラクトもまた、それ自体のプライベート・ステートに基づいてアカウンティング・エントリのハッシュを生成することができ、リクイディティ・プロバイダの分散型台帳ノードのスマート・コントラクトから受け取ったハッシュに対して、生成したハッシュを調整することができる。

【0068】

[0077] ステップ３２０において、受取側の金融機関の分散型台帳ノードのスマート・コントラクトは、ハッシュを比較することができ、不一致があった場合、ステップ３２５において、受取側の金融機関の分散型台帳ノードのスマート・コントラクトは、不一致の原因となったエンティティを特定することができ、通知を生成することができる。

【0069】

[0078] ステップ３３０において、リクイディティ・プロバイダの分散型台帳ノードから受取側の金融機関のプライベート・ステートへのアカウンティング・エントリの再同期を、行うことができる。

【0070】

[0079] 図４を参照すると、層になった負債及びリクイディティ・プロバイダを伴った共有される台帳の用例が、実施形態に従って提供されている。例えば、システム４００は、ＵＳＤリクイディティ・プロバイダ４１０及びＳＧＤリクイディティ・プロバイダ４５０などのようなリクイディティ・プロバイダ（例えば、層１）を含むことができる。各リクイディティ・プロバイダは発行銀行負債を有する。

【0071】

[0080] それぞれの参加銀行４２０、４２２、４６０、４６２は、リクイディティ・プロバイダと相互に作用することができる複数の参加銀行（例えば、層２）を有することができる。参加銀行４２０、４２２、４６０、４６２は、ＡＭＬ／ＣＦＴ制御に基づいて許可されたトランスファーを行うことができる。

【0072】

[0081] それぞれの参加銀行４２０、４２２、４６０、４６２は、法人口座４３０、４３２、４３４、４７０、４７２、４７４を持つその法人顧客（層３）を有することができ、それぞれの法人口座４３０、４３２、４３４、４７０、４７２、４７４は、口座に特有の規則を有することができる。

【0073】

[0082] 実施形態は、共有台帳を持つコルレス銀行業務モデルを複製することができ、カスタム化した規則を用いて法人顧客への拡張したアクセスを提供することができ、マルチ通貨ネットワークを提供することができ、中央銀行デジタル通貨へと延びることができる。

【0074】

[0083] 従って、発行銀行負債は、複数の層で共有することができる。

【0075】

[0084] 図５を参照すると分散型台帳ベースの多層の負債のための方法が実施形態に従って開示されている。

【0076】

[0085] ステップ５０５において、法人顧客（例えば、支払人）は、分散型台帳ネットワークにおける分散型台帳のその支払人の口座へデポジットするように、その参加銀行（例えば、支払人参加銀行）で命令を開始することができる。この口座は、「オンチェーン」口座と称され得る。１つの実施形態では、これは、支払人のオンチェーン口座が十分な資金を有する場合には、必要ではないかもしれない。

【0077】

[0086] ステップ５１０において、支払人参加銀行は、支払人のオフチェーン口座の借方への記入を行うことができ、分散型台帳の支払人のオンチェーン口座の貸方への記入を行うことができる。オフチェーン口座とオンチェーン口座とは異なるプラットフォームにあるので、支払人参加銀行は、資金の移動を容易にするためにつなぎ勘定（bridging account）を用いることができる。つなぎ勘定は、受取人参加銀行の総勘定台帳との金融的調整のために用いることができる。

【0078】

[0087] 例えば、つなぎ勘定は、一般的には、対で用いられる。つなぎ（bridging）は、資金が或る下位台帳（sub-ledger）（例えば、金融機関のシステム）から別の下位台帳（例えば、分散型台帳）へ動いたときに生じる。従って、互いを忠実に写すつなぎ勘定は、それぞれの側に提供される。双方のつなぎ勘定は、１日の終わりに２つの異なる下位台帳により総勘定台帳（general ledger）（ＧＬ）へ供給することができ、ＧＬは、双方のつなぎ勘定の位置が同じあることを確認し、そうではない場合は、調整のための中断を生じさせる。

【0079】

[0088] ステップ５１５において、支払人は、支払人参加銀行へ、支払を行うように命令することができ、支払人のオンチェーン口座の借方への記入を行い、別の参加銀行に属する受取人のオンチェーン口座の貸方への記入を行うようにする。双方の口座は同じブロックチェーン・ネットワーク上にある。

【0080】

[0089] ステップ５２０において、支払人参加銀行は、銀行間での精算を目的としてリクイディティ・プロバイダが支払人参加銀行のオンチェーン口座へ資金をデポジットすることを、要求することができる。

【0081】

[0090] ステップ５２５において、リクイディティ・プロバイダは、支払人参加銀行のオフチェーン口座の借方への記入を行うことができ、支払人参加銀行のオンチェーン口座の貸方への記入を行うことができる。１つの実施形態では、リクイディティ・プロバイダは、リクイディティ・プロバイダの下位台帳間での横断を行えるように内部つなぎ勘定を用いることができる。

【0082】

[0091] ステップ５２０及び５２５は、参加銀行のオンチェーン口座が十分な資金を有する場合には、必要ではないかもしれない。

【0083】

[0092] ステップ５３０において、支払人参加銀行は、受取人への支払トランスファーを開始するために、分散型台帳の第１スマート・コントラクトを呼び出すことができる。

【0084】

[0093] ステップ５３５において、スマート・コントラクトは、リクイディティ・プロバイダへ、支払人参加銀行とその支払に対しての受取人参加銀行との間の精算を行うように、通知することができる。

【0085】

[0094] ステップ５４０において、リクイディティ・プロバイダは、支払人参加銀行のオンチェーン口座の借方への記入を行い、受取人参加銀行のオンチェーン口座の貸方への記入を行うように、及び精算が完了したことを双方の参加銀行へ伝えるように、第２スマート・コントラクトを呼び出すことができる。

【0086】

[0095] ステップ５４５において、受取人参加銀行は、そのオンチェーン口座の借方への記入を行い、受取人のオンチェーン口座の貸方への記入を行うように、第３スマート・コントラクトを呼び出すことができる。

【0087】

[0096] ステップ５５０において、受取人は、オプションとして、受取人参加銀行へ、資金を受取人のオンチェーン口座から引き落とすように、及び資金を受取人のオフチェーン口座の貸方へ記入するように、命令することができる。ステップ５５５において、受取人参加銀行は、次に、受取人のオンチェーン口座の借方への記入を行うことができ、２つの下位台帳を交差させるように第２組の内部つなぎ勘定を用いて、資金を支払人のオフチェーン口座へトランスファーすることができる。

【0088】

[0097] １つの実施形態では、スマート・コントラクトは、下記の特徴、（１）分散型台帳でデビットとクレジットとが自動的にポストされることを保証すること、（２）金融機関が命令を処理又は解決することを辞退するようにする能力（例えば、金融機関の内部システムが制裁についての関心事を特定したとき）、（３）処理中にトランザクションの関係者へ通知を提供すること、（４）スマート・コントラクトからトランザクションの詳細を抽出し、金融機関のシステム（例えば、ＡＭＬ、詐欺など）へ提供すること、及び（５）クレジットのリスクの露出を避けるように、クレジットが生じる前にデビットが成功であることを保証すること、のうちの少なくとも幾つかを提供することができる。例えば、デビット口座がオフチェーンである場合、金融機関のシステムは、オンチェーンのクレジットが生じるように、スマート・コントラクトへコンファメーションを提供する必要がある。オンチェーンのクレジットが成功しない場合（例えば、口座が凍結、誤った口座番号など）、スマート・コントラクトは、デビットの取り消しを行うように、金融機関のシステムへ応答を返す。同様に、クレジット口座がオフチェーンである場合、スマート・コントラクトは、最初に、オンチェーン口座の借方への記入を行い、オフチェーン口座の貸方への記入を行うことを金融機関のシステムに要求する。金融機関のシステムが貸方への記入を辞退した場合、スマート・コントラクトは、クレジット・バック（credit-back）・エントリをオンチェーン口座へポストする。

【0089】

[0098] 図６Ａ及び６Ｂ、７Ａ及び７Ｂ、及び８は、分散型台帳ネットワークにおける層になった負債のモデルの使用についての例を提供する。それらは単なる例であり、限定するものではないことに、留意されたい。

【0090】

[0099] 図６Ａ及び６Ｂを参照すると、分散型台帳における預金口座への資金の直接的デポジット（図６Ａ）、及び直接的引き出し（図６Ｂ）のための例示のフローが開示されている。図６Ａにおいて、参加銀行は、参加銀行のオフチェーン口座の借方への記入を行い得るリクイディティ・プロバイダへ、デポジット命令を提供することができ、コントラ・エントリーのために双方の台帳の追加のつなぎ勘定を用いて、参加銀行のオンチェーン口座の貸方への記入を行うことができる。参加銀行は、ユーザ・インターフェースを用いて、そのバランスを見ることができる。

【0091】

[00100] 図６Ａの下部は、デポジット処理のための例示のモデルとアカウンティングとを示す。

【0092】

[00101] 図６Ｂは、実施形態に従った直接的な引き出しの処理を示す。参加銀行は、例えば、参加銀行のユーザ・インターフェースを用いて、及びマルチ通貨ネットワークを介して、引き出しを要求する。マルチ通貨ネットワークは、参加銀行のオンチェーン預金口座の借方への記入を行うことができ、次に、リクイディティ・プロバイダは、コントラ・エントリーのために双方の台帳の追加のつなぎ勘定を用いて、参加銀行のオフチェーン預金口座の貸方への記入を行うことができる。

【0093】

[00102] 図６Ｂの下部は、引き出しの処理のための例示のアカウンティングを示す。

【0094】

[00103] 図７Ａ及び７Ｂを参照すると、参加銀行を介しての分散型台帳における預金口座への資金のデポジット（図７Ａ）と、参加銀行を介しての直接的引き出し（図７Ｂ）との例示のフローが、実施形態に従って開示されている。

【0095】

[00104] 図７Ａにおいて、参加銀行の法人顧客（例えば、ベータ社）は、参加銀行へのデポジット命令を提供することができる。参加銀行は、法人顧客のオフチェーン口座の借方への記入と、そのオンチェーン口座の貸方への記入とを行うことができる。参加銀行は、参加銀行による法人顧客の預金口座のオフチェーン預金口座の借方への記入を行うことができ、参加銀行のオフチェーンのつなぎ勘定の貸方への記入を行うことができる。次に、その額は、マルチ通貨ネットワークにおける参加銀行のオンチェーンのつなぎ勘定へ書き込むことができ、次に、ベータのオンチェーン口座へ書き込むことができる。法人顧客に関するバランスは参加銀行の負債であり、これは参加銀行に保持されるリクイディティ・プロバイダの負債を頼りに出されたものである。

【0096】

[00105] 法人顧客は、ユーザ・インターフェースを用いて、法人顧客のオンチェーン預金口座のバランスを見ることができる。実施形態では、法人顧客のためのユーザ・インターフェースは、参加銀行により提供することができ、参加銀行のブロックチェーン・ノードへ質問を行うことができる。

【0097】

[00106] 図７Ａの下部は、デポジット処理のための例示のモデルとアカウンティングとを示す。

【0098】

[00107] 図７Ｂは、実施形態に従った参加銀行を介しての引き出し処理を示す。法人顧客（例えば、ベータ社）は、マルチ通貨ネットワークへ引き出しを要求することができ、それは、参加銀行により法人顧客のオンチェーン預金口座の借方への記入と、参加銀行のオンチェーンのつなぎ勘定の貸方への記入とを行うことができる。次に、リクイディティ・プロバイダは、参加銀行のオフチェーンのつなぎ勘定の借方への記入と、法人顧客による法人顧客のオフチェーン預金口座の貸方への記入とを行うことができる。

【0099】

[00108] 図７Ｂの下部は、引き出し処理のための例示のアカウンティングを示す。

【0100】

[00109] 図８を参照すると、参加銀行にわたってのトランスファーのための例示のフローが実施形態に従って提供されている。１つの実施形態では、第１法人顧客（例えば、ベータ社）は、マルチ通貨ネットワークへ支払トランスファー命令を提出することができる。ベータ社のための参加銀行（例えば、参加銀行１）は、ベータ社のオンチェーン口座の借方への記入と、参加銀行１のオンチェーン口座の貸方への記入とを行うことができる。次に、参加銀行１のオンチェーン口座は、その額に対して借方への記入がなされ得、第２参加銀行（参加銀行２）に関してのオンチェーン口座は貸方への記入がなされ得る。次に、第２参加銀行のオンチェーン口座は借方への記入がなされ得、第２法人顧客（アルファ社）のオンチェーン口座は貸方への記入がなされ得る。アルファ社は、ユーザ・インターフェースを用いてバランスを見ることができる。

【0101】

[00110] 更に、アルファ社は、参加銀行２により提供されるユーザ・インターフェースを用いてバランスを見ることができ、それは、参加銀行２のブロックチェーン・ノードへ質問を行うことができる。

【0102】

[00111] 図８の下部は、トランスファー処理のための例示のアカウンティングを示す。

【0103】

[00112] 幾つかの実施形態を開示したが、それらの実施形態は互いに排他的ではなく、１つの実施形態からの特定の構成要素や特徴を別の実施形態で使用でき得ることを、認識すべきである。

【0104】

[00113] 以下において、本発明のシステム及び方法の実施の一般的な特徴について説明する。

【0105】

[00114] 発明のシステム又は発明のシステムの一部は、例えば汎用コンピュータなどのような「処理マシン」の形とすることができる。ここで用いる「処理マシン」という用語は、少なくとも１つのメモリを用いる少なくとも１つのプロセッサを含むものと理解される。メモリは命令の組を格納する。命令は、処理マシンの１つのメモリ又は複数のメモリに、永久的又は一時的に格納され得る。プロセッサは、データを処理するために、１又は複数のメモリに格納された命令を実行する。命令の組は、上述のタスクなどのような特定の１又は複数のタスクを行うための様々な命令を含むことができる。特定のタスクを行うためのそのような命令の組は、プログラム、ソフトウェア・プログラム、又は単にソフトウェアとして特徴付けすることができる。

【0106】

[00115] １つの実施形態では、処理マシンは特化型のプロセッサであり得る。

【0107】

[00116] 上述のように、処理マシンは、データを処理するために、１又は複数のメモリに格納された命令を実行する。このデータの処理は、例えば、処理マシンの１又は複数のユーザによるコマンドに応答してのもの、前の処理に応答してのもの、別の処理マシンによるリクエスト及び／又は何れかの他の入力に応答してのものであり得る。

【0108】

[00117] 上述のように、発明を実施するために用いられる処理マシンは、汎用コンピュータとすることができる。しかし、上述の処理マシンは、多種の他の技術のうちの任意のものを用いることもでき、それに含まれるのは、特定用途向けコンピュータや、例えば、マイクロコンピュータ、ミニコンピュータ又はメインフレーム、プログラムされたマイクロプロセッサ、マイクロコントローラ、周辺集積回路素子、ＣＳＩＣ（カスタムＩＣ）やＡＳＩＣ（特定用途向け集積回路）や他の集積回路、ロジック回路、デジタル信号プロセッサ、ＦＰＧＡやＰＬＤやＰＬＡやＰＡＬなどのようなプログラマブル論理回路、又は発明の処理のステップを実施することができる任意の他のデバイス又はデバイスの配列を含むコンピュータ・システムである。

【0109】

[00118] 発明を実施するために用いられる処理マシンは、適切なオペレーティング・システムを用いることができる。

【0110】

[00119] 上述の発明の方法を実施するために、処理マシンのプロセッサ及び／又はメモリが同じ地理的場所に物理的に位置する必要がないことは、理解される。すなわち、処理マシンにより用いられるプロセッサ及びメモリのそれぞれは、地理的に異なる場所に位置することができ、通信するように任意の適切な形で接続することができる。更に、プロセッサ及び／又はメモリのそれぞれが、機器の異なる物理的部分により構成され得ることが、理解される。従って、プロセッサが１つの場所における機器の１つの部分である必要はなく、また、メモリが別の場所における機器の別の１つの部分である必要はない。即ち、プロセッサが２つの異なる場所における機器の２つの部分であり得る、ということが考えられている。機器の２つの異なる部分は任意の適切な形で接続することができる。更に、メモリは、２以上の物理的位置にあるメモリの２以上の部分を含むことができる。

【0111】

[00120] 更に説明すると、上述の処理は、様々なコンポーネント及び様々なメモリにより行われる。しかし、上述のように２つの異なるコンポーネントにより行われる処理は、発明の更なる実施形態によると、１つのコンポーネントにより行うことができると理解される。更に、上述のように１つの個別のコンポーネントにより行われる処理は、２つの個別のコンポーネントにより行うことができる。同様に、上述のように２つの個別のメモリ部分により行われるメモリ格納は、発明の更なる実施形態によると、１つのメモリ部分により行うことができる。更に、上述のように１つの個別のメモリ部分により行われるメモリ格納は、２つのメモリ部分により行うことができる。

【0112】

[00121] 更に、様々なプロセッサ及び／又はメモリの間での通信を提供するために、及び発明のプロセッサ及び／又はメモリが任意の他のエンティティと通信することを可能とするために、即ち、例えば、更なる命令を得るように、又はリモート・メモリ・ストアへアクセスする又はそれを使用するように、様々な技術を用いることができる。そのような通信を提供するために用いられるそのような技術は、例えば、ネットワーク、インターネット、イントラネット、エクストラネット、ＬＡＮ、イーサネット、セル・タワーや衛星を介してのワイヤレス通信、又は通信を提供する任意のクライアント・サーバ・システムを含み得る。そのような通信技術は、例えば、ＴＣＰ／ＩＰやＵＤＰやＯＳＩなどのような、任意の適切なプロトコルを用いることができる。

【0113】

[00122] 上述のように、命令の組は、発明の処理において用いることができる。命令の組は、プログラム又はソフトウェアの形であり得る。ソフトウェアは、例えば、システム・ソフトウェア又はアプリケーション・ソフトウェアの形であり得る。ソフトウェアはまた、例えば、個別のプログラムの集合体や、大きいプログラム内のプログラム・モジュールや、プログラム・モジュールの一部という形であり得る。また、用いられるソフトウェアは、オブジェクト指向プログラミングの形のモジュール型プログラミングを含むことができる。ソフトウェアは、処理マシンへ、処理されているデータを用いて何をするかを伝える。

【0114】

[00123] 更に、発明の実施又は動作において用いられる命令又は命令の組は、処理マシンが命令を読めるように、適切な形であり得ることが理解される。例えば、プログラムを形成する命令は、１又は複数のプロセッサが命令を読むことを可能とするように機械語又はオブジェクト・コードへと変換される適切なプログラミング言語の形とすることができる。即ち、特定のプログラミング言語で書かれたプログラミング・コード又はソース・コードの行は、コンパイラやアセンブラやインタープリタを用いて機械語へと変換される。機械語は、例えば、特定の型の処理マシン、即ち、特定の型のコンピュータに特定的なバイナリ・コードの機械命令である。コンピュータは、機械語を理解する。

【0115】

[00124] 発明の様々な実施形態に従って任意の適切なプログラミング言語を用いることができる。また、望まれ得る場合には、発明の実施で用いる命令及び／又はデータは、任意の圧縮や暗号の技術やアルゴリズムを用いることができる。暗号化モジュールを、データを暗号化するために用いることができる。更に、例えば、適切な暗号解除モジュールを用いて、ファイルや他のデータの暗号解除を行うことができる。

【0116】

[00125] 上述のように、発明は、例として、例えば、少なくとも１つのメモリを含むコンピュータ又はコンピュータ・システムを含む処理マシンの形で、実施することができる。コンピュータのオペレーティング・システムが上述の動作を行うことを可能にする命令の組、即ち、例としてはソフトウェアは、上述のように多種の媒体の任意のもの又は１つの媒体に含まれ得ることが、理解される。更に、命令の組により処理されるデータはまた、多種の媒体の任意のもの又は１つの媒体に含まれることができる。即ち、発明で用いられる命令の組及び／又はデータを保持するために用いられる特定の媒体、即ち、処理マシンのメモリは、例えば、様々な物理的な形又は伝送の形とすることができる。例として、媒体は、紙、紙トランスペアレンシー、コンパクト・ディスク、ＤＶＤ、集積回路、ハード・ディスク、フロッピー・ディスク、光ディスク、磁気テープ、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＰＲＯＭ、ワイヤ、ケーブル、ファイバ、通信チャンネル、衛星通信、メモリ・カード、ＳＩＭカード、又は他のリモート通信、また、発明のプロセッサにより読まれることができる任意の他のデータ媒体やデータ・ソースの形とすることができる。

【0117】

[00126] 更に、発明を実施する処理マシンで用いられる１又は複数のメモリは、望まれるようにメモリが命令やデータや他の情報を保持することを可能とするために、多種の形のうちの任意のものとすることができる。従って、メモリは、データを保持するためのデータベースの形とすることができる。データベースは、例えば、フラット・ファイル構成やリレーショナル・データベース構成などのような、任意の望まれるファイル構成を用いることができる。

【0118】

[00127] 発明のシステム及び方法において、様々な「ユーザ・インターフェース」を用いて、発明を実施するために用いられる１又は複数の処理マシンとユーザがインターフェースすることを可能とすることができる。ここで用いられるユーザ・インターフェースは、ユーザが処理マシンと対話することを可能とするものであり処理マシンにより用いられるものである任意のハードウェア、ソフトウェア、又はハードウェアとソフトウェアとの組み合わせを含む。ユーザ・インターフェースは、例えば、ダイアログ・スクリーンの形とすることができる。また、ユーザ・インターフェースは、マウス、タッチ・スクリーン、キーボード、キーパッド、音声読取装置、音声認識装置、ダイアログ・スクリーン、メニュー・ボックス、リスト、チェックボックス、トグル・スイッチ、プッシュボタン、又は処理マシンが命令の組を処理するときにその動作に関する情報をユーザが受け取ることを可能とし、且つ／又は処理マシンへ情報を提供する任意の他のデバイスのうちの任意のものを、含むことができる。従って、ユーザ・インターフェースは、ユーザと処理マシンとの間での通信を提供する任意のデバイスである。ユーザによりユーザ・インターフェースを介して処理マシンへ提供される情報は、例えば、コマンド、選択されたデータ、又は何らかの他の入力の形とすることができる。

【0119】

[00128] 上記で検討したように、ユーザ・インターフェースは、処理マシンがユーザのためにデータを処理するように命令の組を実行する処理マシンにより、用いられる。ユーザ・インターフェースは、典型的には、情報を運ぶため又はユーザから情報を受け取るためにユーザと対話するために、処理マシンにより用いられる。しかし、発明のシステム及び方法の幾つかの実施形態によると、発明の処理マシンにより用いられるユーザ・インターフェースと人間であるユーザが実際に対話することが必要ではないことを、理解すべきである。むしろ、発明のユーザ・インターフェースは、人間であるユーザではなく、他の処理マシンとの対話、即ち、情報の搬送及び受け取りを行い得ることが、考えられている。従って、他の処理マシンを、ユーザとして特徴付けすることができる。更に、発明のシステム及び方法で用いられるユーザ・インターフェースは、部分的に、別の１または複数の処理マシンと対話することができ、それと共に、部分的に、人間のユーザと対話することが、考えられている。

【0120】

[00129] 本発明が広く役立ち応用できることが、当業者には容易に理解される。本発明のここで説明したもの以外の多くの実施形態及び改造、及び多くの変形、変更、および等価の構成が、発明の実体又は範囲から離れることなく、本発明及び本発明の上記の説明から明らかであるか、又はそれらにより合理的に提案されている。

【0121】

[00130] 従って、ここで本発明の例示的実施形態と関連して詳細に本発明を説明したが、この開示は本発明の単なる用例及び例示であり、発明の実施可能な開示を提供するためになされたことが、理解される。従って、上述の説明は、本発明が解釈されることや限定されること、また、何れの他のそのような実施形態や改造や変形や変更や等価の構成を除くことを、意図していない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7A】

【図7B】

【図8】

【国際調査報告】