JP7378451B2 - デジタル不換通貨 - Google Patents

Description

関連出願の相互参照
本出願は、２０１８年１１月９日に出願された米国特許出願６２／７５８，４３０号の優先権の利益を主張するものであり、その内容全体があらゆる目的のために参照により本明細書に組み込まれる。

暗号通貨は、交換の媒体として機能するように設計されたデジタルまたは仮想通貨である。従来の暗号通貨は、取引を保護および検証するとともに、特定の暗号通貨の新しい単位の作成を制御するために暗号を使用する。

多くの暗号通貨は分散化されている。一般的な暗号通貨インフラストラクチャでは、ノードを使用して、１つのノードがいかなる他のノードよりも制御を有しない状態で取引を生成および検証する。

暗号通貨システムは、不換通貨システムよりも優れている。例えば、暗号通貨金銭の転送は、従来の不換通貨金銭の送金よりも高速である。最後に、いくつかの暗号通貨はブロックチェーンを使用するので、ブロックチェーンは取引の不変の記録であることから、このような暗号通貨はしばしば信頼される。

暗号通貨は利点を有するが、一般に、不換通貨のような規制の対象にはならない。さらに、暗号通貨には電子デバイスの使用が必要となるため、政府がそれらの不換通貨システムを完全に暗号通貨に転換することは現実的ではない。ある国の人口の一部は電子デバイスを有さない可能性があるため、不換通貨を暗号通貨に完全に変換することは実用的ではない。

本発明の実施形態は、この問題および他の問題に、個別におよび集合的に対処する。

実施形態は、物理通貨に基づいて生成されたデジタル不換通貨を管理するためのデジタル不換通貨システムを提供する。実施形態は、デジタル通貨を管理するためのプライベート許可分散型台帳プラットフォームを提供する。デジタル通貨は、対応する物理通貨の記番号などのデータと関連付けてブロックチェーンに記録されてもよく、これにより中央事業体がデジタル通貨の量および値を管理することを可能にする。

いくつかの実施形態では、コンピュータにより実行される方法は、中央事業体コンピュータによって、デジタル通貨に対する要求を受信することであって、要求が、物理通貨の記番号および額面金額を含む、受信することと、中央事業体コンピュータによって、額面金額に対する、かつ記番号に紐付けられたデジタル通貨を生成することであって、デジタル通貨をブロックチェーンに記録することを含む、生成することと、中央事業体コンピュータによって、デジタル通貨の生成の通知を送信することと、中央事業体コンピュータによって、不換通貨システム内の流通からの物理通貨の除去を引き起こすことであって、生成することが、デジタル通貨をブロックチェーンに記録することを含む、生成することと、を含み得る。

いくつかの実施形態では、方法は、デジタルウォレットに記憶された秘密鍵を使用して、デジタル通貨をデジタルウォレットに関連付けることをさらに含み得る。いくつかの実施形態では、デジタルウォレットの秘密鍵は、スマートカードのチップまたはユーザデバイスのセキュアエレメントに記憶される。

いくつかの実施形態では、方法は、中央事業体コンピュータによって、取引処理ネットワークから、中央事業体コンピュータの信頼される証明書を受信することと、信頼される証明書を使用してデジタル通貨を生成することと、をさらに含み得る。いくつかの実施形態では、デジタル通貨の生成の通知を送信する前に、ブロックチェーンにデジタル通貨を記録することは、複数の検証事業体によって検証される。いくつかの実施形態では、デジタル通貨は、中央事業体コンピュータの公開鍵を使用してブロックチェーンに記録される。いくつかの実施形態では、流通からの物理通貨の除去を引き起こすことは、物理通貨を物理的に破棄することを含み、物理通貨は、不換通貨である。

いくつかの実施形態では、デジタル通貨に対する要求は、第１の要求であり、物理通貨は、第１の物理通貨であり、方法は、中央事業体のコンピュータによって、第２のデジタル通貨に対する要求を受信することであって、第２の要求が、物理通貨の記番号および第２の額面金額を含み、第２の物理通貨の記番号および額面金額は、第１の物理通貨の記番号および額面金額と同じである、受信することと、中央事業体のコンピュータによって、記番号および額面金額に対応するデジタル通貨がブロックチェーンにすでに記録されていることを決定することと、第２の要求に基づいて第２のデジタル通貨を生成することを控えることと、をさらに含む。

いくつかの実施形態では、ブロックチェーンは、複数のブロックを含み、複数のブロックのうちの少なくとも１つのブロックが、複数の取引のデータを記憶し、複数の取引が、額面金額に関連付けられた金額のデジタル通貨がデジタルウォレットに関連付けられた公開鍵に対して作成されていることを示す第１の記録を含む。いくつかの実施形態では、ブロックチェーンは、複数のブロックを含み、複数のブロックのうちの少なくとも１つのブロックが、複数の取引のデータを記憶し、複数の取引が、流通からの物理通貨の除去を記録する第２の記録を含む。いくつかの実施形態では、デジタル通貨をブロックチェーンに記録することは、ブロックチェーン内のブロック内の記録を生成し、記録は、物理通貨の通貨タイプおよび物理通貨の記番号を含む。

いくつかの実施形態では、中央事業体コンピュータは、プロセッサと、方法を実行するためにプロセッサによって実行可能であるコードを含む非一時的コンピュータ可読媒体であって、方法は、中央事業体コンピュータによって、デジタル通貨に対する要求を受信することであって、要求が、物理通貨の記番号および額面金額を含む、受信することと、中央事業体コンピュータによって、額面金額に対する、かつ記番号に紐付けられたデジタル通貨を生成することであって、生成することが、デジタル通貨をブロックチェーンに記録することを含む、生成することと、中央事業体コンピュータによって、デジタル通貨の生成の通知を送信することと、中央事業体コンピュータによって、不換通貨システム内の流通からの物理通貨の除去を引き起こすことと、を含む、非一時的コンピュータ可読媒体と、を備える。

いくつかの実施形態では、コンピュータにより実行される方法は、ブロックチェーンを記憶するブロックチェーンノードによって、不換通貨システムからの額面金額を有する物理通貨の除去に関連するアクションを記録する要求を受信することと、ブロックチェーンノードによって、不換通貨システムからの額面金額を有する物理通貨の除去に関連するアクションの記録をブロックチェーンに記録することと、ブロックチェーンノードによって、額面金額に等しい金額のデジタル通貨を記録する要求を受信することであって、デジタル通貨が、ユーザの公開鍵に関連付けられている、受信することと、ブロックチェーンノードによって、額面金額に等しい金額のデジタル通貨を記録することと、を含む。

いくつかの実施形態では、方法は、ブロックチェーンノードによって、第１のユーザと第２のユーザとの間の取引を記録する要求を受信することであって、要求が、第１のユーザの公開鍵、第２のユーザの公開鍵、および取引金額を含む、受信することと、第１のユーザと第２のユーザとの間の取引の記録を記録することであって、取引の記録が、第１のユーザの公開鍵、第２のユーザの公開鍵、および取引金額を不換通貨システムからの額面金額を有する物理通貨の除去に関連する、ブロックチェーンに対するアクションとともにブロック内に含む、記録することと、をさらに含む。いくつかの実施形態では、記録は、物理通貨の通貨タイプをさらに含む。いくつかの実施形態では、額面金額に等しい金額のデジタル通貨が、記録に記録され、記録が、物理通貨の通貨タイプおよび物理通貨の記番号をさらに含む。

いくつかの実施形態では、ブロックチェーンノードは、銀行サーバコンピュータである。いくつかの実施形態では、要求は、第１のユーザの秘密鍵を使用して署名される。いくつかの実施形態では、方法は、第１のユーザの公開鍵を使用して第１のユーザのデジタル署名を検証することをさらに含む。いくつかの実施形態では、方法は、複数の追加のブロックチェーンノードとコンセンサスを達成することをさらに含む。いくつかの実施形態では、コンセンサスは、プルーフオブステーク、ビザンチンフォールトトレラントアルゴリズム、またはクラッシュフォールトトレラントアルゴリズムのうちの１つを使用して達成される。いくつかの実施形態では、ブロックチェーンノードは、ブロックチェーンへの書き込む許可を得るために証明書を使用する。

様々な実施形態による、デジタル不換通貨を管理するためのエコシステムの例を示す。 様々な実施形態による、中央事業体コンピュータのブロック図を示す。 様々な実施形態による、現金をデジタル不換通貨に変換する中央事業体を示すステップのフローチャートの例を示す。 様々な実施形態による、銀行券をデジタル不換通貨に交換する事業体を示すステップのフローチャートの例を示す。 様々な実施形態による、ブロックチェーン上の許可を管理するための例示的な構成要素を示す。 図６－１～図６－２は、様々な実施形態による、デジタル不換通貨を使用した資産管理のためのステップのフローチャートの例を示す。 図６－１～図６－２は、様々な実施形態による、デジタル不換通貨を使用した資産管理のためのステップのフローチャートの例を示す。 様々な実施形態による、ブロックチェーン上のデジタル不換通貨取引を記録するために使用されるデータおよびメタデータの例を示す。 様々な実施形態による、ブロックチェーン上のデジタル不換通貨取引を記録するために使用されるデータおよびメタデータの例を示す。 様々な実施形態による、ブロックチェーン上のデジタル不換通貨取引を記録するために使用されるデータおよびメタデータの例を示す。 様々な実施形態による、デジタル不換通貨を管理するための例示的なインターフェースを示す。 イーサリアムフレームワークを使用してデジタル不換通貨システムを実装する例示的な実施形態を示す。 イーサリアムフレームワークを使用してデジタル不換通貨システムを実装する例示的な実施形態を示す。 イーサリアムフレームワークを使用してデジタル不換通貨システムを実装する例示的な実施形態を示す。 イーサリアムフレームワークを使用してデジタル不換通貨システムを実装する例示的な実施形態を示す。

実施形態は、デジタル不換通貨を提供し、デジタル不換通貨は、物理通貨をデジタル通貨に変換するために使用され得る。現金のデジタル化は、ユーザが分散型台帳技術を使用してデジタル取引を実施することを可能にし得る。異なるユーザ間でデジタル通貨を転送するための取引は、従来の通貨を使用する取引で必要とされた清算または決済を必要とすることなく、リアルタイムかつアトミックに行われてもよい。デジタル不換通貨は、あらゆる値の変動を避けるために、不換紙幣の交換レートに固定されたままであってもよい。

様々な実施形態によれば、デジタル通貨は、物理通貨の記番号に基づいて発行され得る。様々な実施形態によれば、デジタル通貨は、物理通貨の記番号と関連付けられ、これを使用して追跡可能であり得る。様々な実施形態によれば、取引処理ネットワークは、管理者の役割を中央事業体に割り当ててもよく、中央事業体は、物理不換通貨をデジタル不換通貨に変換する排他的な許可を有してもよい。

本明細書で考察される例示的な実施形態によれば、支払エコシステムは、完全に（例えば、１００％）デジタルになり得る。様々な実施形態によれば、現金は、フリクションのない様式で市場から除去され得、支払エコシステムが改善され得る。ユーザは、安全、高速、かつ信頼性の高い方式で取引を実施するために、地元の物理通貨と同じ額面金額のデジタル通貨（例えば、米国にいるユーザＡの場合は１００ドル、メキシコにいるユーザＢの場合は２００ペソなど）を保持してもよい。

本発明の実施形態は、現金を中央事業体によって規制されたデジタル不換通貨に償還することを可能にする。実施形態はさらに、業界全体で許可され、共有され、不変の取引複製台帳を提供する。実施形態は、銀行券の複製を防止するために、銀行券の記番号および額面金額を記録し得る。実施形態は、（利用可能な場合）チップまたはモバイルデバイスのセキュアエレメント上に取引署名秘密鍵を記憶することによって、取引のセキュリティを確保し得る。実施形態はまた、ユーザの匿名性も可能にし得る。

実施形態は、決済および清算処理を必要とせずに、デジタル不換通貨を使用する取引を即時に処理し、完了させることを可能にする。様々な実施形態によれば、デジタル不換通貨を使用する取引は、クロスボーダー送金を必要とせずに、通貨間で直ちに処理され、完了され得る。さらに、事業体がデジタル不換通貨を使用して取引を行う場合、その取引はブロックチェーン取引であるため、追跡可能である。様々な実施形態によれば、事業体は、デジタル不換通貨を使用して、デジタル通貨プラットフォームで匿名で取引することができる。いくつかの実施形態では、事業体は、デジタル不換通貨を使用してデジタル通貨プラットフォーム上で取引を実施するために、自身を識別する必要があり得る。

本発明の特定の実施形態を考察する前に、いくつかの用語を詳細に説明することができる。

「中央事業体」とは、何かを規制する事業体を指すことができる。中央事業体は、中央銀行であり得、中央銀行は貨幣供給量を規制する。中央事業体は、金融政策を実施し、通貨を発行することができる。中央事業体は、国などの地域で通貨を作成または破棄する独占権を維持することができる。中央事業体は、そのような地域の政府と関連付けられてもよい。

「物理通貨」とは、紙幣または硬貨など、現金などの物理的な形態で利用可能な通貨を指すことができる。物理通貨は、物品またはサービスと交換する手段である。物理通貨は通常、中央事業体によって発行および規制される。

「デジタル通貨」とは、電子形式で利用可能な通貨を指すことができる。物理通貨と同様に、デジタル通貨は、商品またはサービスと交換することができる。デジタル通貨には、暗号により保護されたデジタル通貨の一タイプである暗号通貨が含まれる。

「不換通貨」とは、多くの場合、政府規制によって金銭として確立されている本質的な値を有さない通貨である。

「ブロックチェーン」は、暗号化によって紐付けられる記録の増大するリストであり得る。いくつかの実施形態では、ブロックチェーンは、多くのコンピューティングデバイス上にあるデジタル台帳の中にあり得る。取引は、ブロックのセットに記録され得る。各ブロックは、１つ以上の前のブロックのハッシュを含み得る。したがって、各取引の記録は、後続のすべてのブロックの変更およびネットワークの共謀を伴わずに、遡及的に変更することはできない。

「暗号通貨ネットワーク」は、暗号通貨台帳の維持に関与する１つ以上のコンピュータを含み得る。いくつかの暗号通貨ネットワークでは、分散型暗号通貨台帳はブロックチェーンを含み得る。暗号通貨ネットワークの例としては、ビットコイン、ライトコイン、イーサリアム、ジーキャッシュ、ダッシュ、リップル、およびモネロを含むがこれに限定されない、任意の好適な暗号通貨を管理するコンピュータのネットワークが挙げられる。

「鍵」は、データを別の表現に変換するための暗号アルゴリズムで使用される情報の一部を含むことができる。暗号アルゴリズムは元データを代替表現へと変換する暗号化アルゴリズム、または暗号化された情報を元データへと戻す変換を行う復号アルゴリズムであり得る。暗号アルゴリズムの例として、トリプルデータ暗号化規格（ＴＤＥＳ）、データ暗号化規格（ＤＥＳ）、高度暗号化規格（ＡＥＳ）などが挙げられる。

「取引処理ネットワーク」は、データ処理サブシステム、ネットワーク、および認証サービス、例外ファイルサービス、ならびに清算および決済サービス（利用可能な場合）をサポートし、配信するのに使用される操作であってもよい。取引処理システムの例としては、ＶｉｓａＮｅｔ（商標）がある。ＶｉｓａＮｅｔ（商標）などの取引処理システムは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。取引処理ネットワークは、サーバコンピュータを含んでもよい。

「サーバコンピュータ」は通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。

「デジタルウォレット」とは、個人がオンライン取引を行うことを可能にする電子デバイスまたはオンラインサービスであり得る。デジタルウォレットは、ユーザプロファイル情報、支払証明書、銀行口座情報、暗号通貨アカウント情報、１つ以上のデジタルウォレット識別子および／または同様のものを記憶してもよく、小売購入、デジタル物品購入、公共料金支払、ゲームウェブサイトからのゲームまたはゲームクレジットの購入、ユーザ間の資金移動および／または同様のもの用の、ｅコマース取引、ソーシャルネットワーク取引、送金／個人的支払、モバイルコマース取引、近接支払、ゲームおよび／または同様のものであるがこれらに限定されない、様々な取引で使用することができる。デジタルウォレットは、購入および支払プロセスを合理化するように設計されてもよい。デジタルウォレットは、アカウント番号の入力または物理的カードの提示を必要とせずに支払いを行うように、ユーザが１つ以上の支払カードをデジタルウォレットに読み込むことを可能にしてもよい。

「ハッシュ」または「ハッシュ値」は、任意のサイズ（例えば、テキストの文字列）のデータから生成される値（一般に固定サイズ）である。ハッシュは、例えば、数値または文字列値であり得る。ハッシュは、データ自体よりも大幅に小さくてもよい。ハッシュは、他のデータが同じハッシュ値を生成する可能性が極めて低く、ハッシュ値に基づいてデータを再構築することが非常に困難であるように「ハッシュ関数」によって生成されてもよい。

「プロセッサ」は、任意の好適なデータ計算デバイス（単数または複数）を含むことができる。プロセッサは、所望の機能を達成するためにともに動作する、１つ以上のマイクロプロセッサを備えることができる。プロセッサは、ユーザおよび／またはシステム生成要求を実行するプログラム構成要素を実行するのに適切な、少なくとも１つの高速データプロセッサを備えるＣＰＵを含んでもよい。ＣＰＵは、ＡＭＤのアスロン、デュロン、および／もしくはオプテロン、ＩＢＭおよび／もしくはモトローラのＰｏｗｅｒＰＣ、ＩＢＭおよびソニーのセルプロセッサ、インテルのセレロン、アイテニウム、ペンティアム（登録商標）、ジーオン、および／もしくはＸＳｃａｌｅ、ならびに／または同様のプロセッサ（複数可）などのマイクロプロセッサであり得る。

「メモリ」は、電子データを記憶することができる、任意の好適なデバイス（単数または複数）であり得る。好適なメモリは、所望の方法を実行するためにプロセッサによって実行され得る命令を記憶する、非一時的コンピュータ可読媒体を含み得る。メモリの例として、１つ以上のメモリチップ、ディスクドライブなどが含まれ得る。こうしたメモリは、任意の好適な電気的、光学的、および／または磁気的な動作モードを使用して動作することができる。

図１は、いくつかの実施形態による、デジタル不換通貨を管理するためのシステム１００の概略的概要を示す。図１に示すように、システム１００は、中央事業体１０４、ブロックチェーン１１２、１つ以上の検証事業体（例えば、検証事業体Ａ １１０Ａ、検証事業体Ｂ １１０Ｂ、および検証事業体Ｃ １１０Ｃ）、および取引処理ネットワーク１０６を含み得る。システム１００は、償還事業体１０２および１つ以上のユーザ１０８をさらに含み得る。

いくつかの実施形態では、デジタル不換通貨は、ブロックチェーン１１２を使用して管理される。上述したように、ブロックチェーン１１２は、複数の分散型ノードによって記憶および検証される分散型台帳の一タイプであり、ここで情報は暗号化され、紐付けられたブロックに記録される。追加的にまたは代替的に、デジタル不換通貨は、ハッシュグラフなどの別のタイプの分散型台帳技術を使用して管理されてもよい。システム１００内の事業体は、ブロックチェーンノード（例えば、事業体１１０Ａ、１１０Ｂ、および１１０Ｃ、取引処理ネットワーク１０６、ならびに検証中央事業体１０４）として機能し得る。ブロックチェーンノードは各々、ブロックチェーン１１２を記憶し、ブロックチェーン１１２上の取引を記録および監視し得る。

いくつかの実施形態では、取引処理ネットワーク１０６は、システム１００全体の許可を管理する。取引処理ネットワーク１０６は、事業体（例えば、中央事業体１０４、ユーザ１０８、検証事業体１１０Ａ～１１０Ｃなど）が果たし得る特定の役割を識別し、ネットワークおよびチャネル（例えば、チャネル管理者、読み取り担当者、書き込み担当者など）の文脈で、アクセス権を定義するための基礎を設定し得る。さらに、取引処理ネットワーク１０６は、許可の取り消しおよび／または許可が取り消された事業体のリストの識別を可能にし得る。

いくつかの実施形態では、取引処理ネットワーク１０６は、中央事業体１０２、検証事業体１１０Ａ～１１０Ｃ、およびユーザ１０８などの当事者のネットワーク識別情報を管理するための認証局構成要素として機能する。例えば、検証事業体１１０Ａ～１１０Ｃは銀行（組織）であり、その各々が特定の許可を有してもよい。中央事業体１０４は、異なる一連の許可を有してもよく、ユーザ１０８は、別の一連の許可を有してもよい。すべての事業体の許可された識別情報の要件により、ネットワークアクティビティの制御が可能になり、すべての取引が最終的に登録された事業体に対して追跡可能であることが保証される。取引処理ネットワーク１０６は、ネットワークへの参加が認証された各メンバー（組織または個人）にルート証明書を発行してもよい。この証明書に基づくネットワークメンバーシップおよびアクションの制御により、メンバーは、特定のユーザ識別情報によって、プライベートおよび機密のチャネル、アプリケーション、データへのアクセスを制限することが可能になる。

取引処理ネットワーク１０６は、プライベート許可分散型台帳技術の信頼されるアーキテクトとして機能し得る。取引処理ネットワークは、スマートコントラクトデプロイヤとして機能する。スマートコントラクトは、ブロックチェーンに取引条件を記録することによって、取引の実行をデジタル的に制御し得る。スマートコントラクトは、ブロックチェーンからそのセキュリティ／信頼を獲得し、同業者間の基本的なコンセンサスを得る、信頼される分散型アプリケーションとして機能し得る。スマートコントラクトは、署名され、ブロックチェーン内のノード間の検証に関連付けられたコンセンサスを有するデータを含み得る。これにより、スマートコントラクトが否認されることが防止される。

いくつかの実施形態では、取引処理ネットワーク１０６は、メンバーシップサービスプロバイダ（ＭＳＰ）として機能し得る。ＭＳＰとして、取引処理ネットワーク１０６は、ブロックチェーン１１２上の許可を管理することができる。異なる事業体は、所与の時間で、デジタル不換通貨に対応するブロックチェーン１１２上の取引を作成、転送、および／または検証する権利を有し得る。

いくつかの実施形態では、中央事業体１０４は、中央銀行などの、ある地域（例えば、国）における金銭およびクレジットの生産および分配に責任を負う事業体である。中央事業体１０４は、デジタル通貨の値を規制するために、物理通貨をデジタル通貨に変換する排他的許可を有し得る。中央事業体１０４は、ブロックチェーン１１２を含み得るブロックチェーンネットワークのノードであってもよい。中央事業体１０４は、デジタル通貨が生成されるタイミングおよび量を制御し得る。中央事業体１０４は、デジタル不換通貨の対応する単位の生成に関連して、物理通貨の単位の破棄をさらに管理してもよい。例えば、デジタル不換通貨のドル値が生成されるたびに、中央事業体１０４は、デジタル不換通貨の値を規制するために、対応する物理的なドル紙幣が流通から除去されることを保証する。こうした機能性は、図２に関してさらに後述するように、中央事業体コンピュータ２００によって実施され得る。

いくつかの実施形態では、中央事業体１０４は、ブロックチェーンネットワーク上のノードであり得る。中央事業体１０４は、ブロックチェーン１１２上にアカウントを有してもよく、デジタル通貨は、中央事業体１０４のアカウントに割り当てられ得る。中央事業体１０４は、ブロックチェーン上のエントリを管理するための証明書および／または暗号鍵を維持し得る。具体的には、中央事業体１０４は、公開鍵および秘密鍵を記憶して、廃止された銀行券から変換されたデジタル通貨の所有権を譲渡する署名を生成し、その検証を許可してもよい。

検証事業体（例えば、検証事業体Ａ１１０Ａ、検証事業体Ｂ１１０Ｂ、および検証事業体Ｃ１１０Ｃ）は、ブロックチェーンノードであり、これらは銀行などの同業者であり得る。検証事業体１１０Ａ～１１０Ｃは、取引を検証する機能を含んでもよい。検証事業体１１０Ａ～１１０Ｃは、送信された取引１１６を受信し、送信された取引１１６を検証すると、検証された取引１１８をブロックチェーン１１２に記録し得る。検証事業体は、デジタル通貨と物理通貨との両方に関連する取引を検証し、記録する機能をさらに含み得る。検証事業体１１０Ａ～１１０Ｃは、以下でさらに詳述するように、互いにコンセンサスを達成して、取引を確定し得る。

償還事業体１０２は、デジタル不換通貨との交換のために、物理通貨を受け入れてもよい。償還事業体１０２は、現金自動預払機（ＡＴＭ）および／または銀行の所在地であってもよい。例えば、ユーザは、ＡＴＭまたは銀行窓口の窓口係に物理通貨を提供することができる。償還事業体１０２は、物理通貨を特徴付ける情報を、中央事業体１０４および／またはブロックチェーンの他のノードに送信し得る。償還事業体１０２はさらに、流通から物理通貨を除去するために、物理通貨を保護し、適切な当事者に輸送し得る。例えば、償還事業体１０２は、中央事業体１０４または中央事業体１０４のエージェントに物理通貨を送信して、デジタル通貨に変換された物理通貨を破棄してもよい。

ユーザ１０８は、特定の時間にデジタル通貨を保持する個人などの事業体であり得る。各ユーザ１０８は、デジタルウォレットが格納される対応するユーザデバイス（例えば、ユーザデバイス１０８Ａおよびユーザデバイス１０８Ｂを有してもよい。デジタルウォレットは、ユーザの特定のデジタルウォレットにデジタル通貨を割り当てる取引に署名し、これを検証するために使用される鍵１１４Ａおよび１１４Ｂを記憶してもよい。実施形態は、非接触チップ（携帯電話上のカードをタップすることによる）またはセキュアエレメントを使用して、ブロックチェーン上の取引に署名するためにユーザが使用する秘密鍵を記憶してもよい。公開／秘密鍵ペアは、ユーザに関連付けられたデジタルウォレットに割り当てられてもよい。このような鍵は、対応するユーザの鍵と呼ぶことができる。

図２は、様々な実施形態による、中央事業体コンピュータ２００のブロック図を示す。中央事業体コンピュータ２００は、ネットワークインターフェース２０２と、プロセッサ２０４と、メモリ２０６と、コンピュータ可読媒体２０８と、を含む。

プロセッサ２０４は、１つ以上の集積回路（例えば、１つ以上のシングルコアもしくはマルチコアマイクロプロセッサおよび／またはマイクロコントローラ）として実装され得る。プロセッサ２０４は、中央事業体コンピュータ２００の動作を制御するために使用され得る。プロセッサ２０４は、メモリ２０６に記憶されたプログラムコードまたはコンピュータ可読コードに応答して、様々なプログラムを実行することができる。プロセッサ２０４は、多数の同時に実行されるプログラムまたはプロセスを維持する機能を含み得る。

ネットワークインターフェース２０２は、中央事業体コンピュータ２００が償還事業体１０２、ユーザ１０８などの他の事業体と通信することを可能にするように、１つ以上の通信ネットワークに接続するように構成され得る。例えば、償還事業体１０２との通信は、直接、間接、および／またはアプリケーションプログラミングインターフェース（ＡＰＩ）を介してであり得る。

メモリ２０６は、任意の数の不揮発性メモリ（例えば、フラッシュメモリ）および揮発性メモリ（例えば、ＤＲＡＭ、ＳＲＡＭ）の任意の組み合わせ、もしくは任意の他の非一時的記憶媒体、または媒体の組み合わせを使用して実装され得る。

コンピュータ可読媒体２０８は、記憶および／または送信のための１つ以上の非一時的媒体を備えてもよい。好適な媒体には、例として、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはコンパクトディスク（ＣＤ）もしくはＤＶＤ（デジタル多目的ディスク）などの光媒体、フラッシュメモリ、および同類のものが挙げられる。コンピュータ可読媒体２０８は、そのような記憶または送信デバイスの任意の組み合わせであってもよい。

コンピュータ可読媒体２０８は、一連の命令またはコマンドとして記憶されるソフトウェアコードを含んでもよい。コンピュータ可読媒体２０８は、方法を実施するために、プロセッサ２０４によって実行可能なコードを含み、方法は、デジタル通貨に対する要求を受信することであって、要求は、物理通貨の記番号および額面金額を含む、受信することと、中央事業体コンピュータによって、額面金額に対する、かつ記番号に紐付けられたデジタル通貨を生成することであって、デジタル通貨をブロックチェーンに記録することを含む、生成することと、中央事業体コンピュータによって、デジタル通貨の生成の通知を送信することと、中央事業体コンピュータによって、不換通貨システム内の流通からの物理通貨の除去を引き起こすことであって、生成することが、デジタル通貨をブロックチェーンに記録することを含む、生成することと、を含む。

コンピュータ可読媒体２０８は、通信モジュール２１０と、デジタル通貨生成モジュール２１２と、規制モジュール２１４と、検証モジュール２１６と、を含み得る。これらのモジュールの各々は、プロセッサ２０４と連携して、後述される機能を実施するように構成されたコードを含み得る。

通信モジュール２１０は、プロセッサ２０４に、メッセージの生成、メッセージの転送、メッセージの再フォーマット、および／またはその他の方法での他の事業体との通信を行わせるコードを含み得る。

デジタル通貨生成モジュール２１２は、プロセッサ２０４にデジタル通貨を生成させるコードを含み得る。デジタル通貨生成モジュール２１２は、プロセッサ２０４と連携して、ブロックチェーンにデプロイ取引を構築してデプロイ取引を提出し、結果としてデジタル通貨を生成するように構成されたコードを含み得る。

規制モジュール２１４は、プロセッサ２０４に、流通中の通貨の金額を規制させるコードを含み得る。規制モジュール２１４は、プロセッサ２０４と連携して、流通中のデジタルおよび／または物理通貨の金額を評価し得る。規制モジュール２１４は、プロセッサ２０４と協力して、デジタルおよび／または物理通貨を流通から除去すべきであると決定し得る。デジタル通貨の文脈において、規制モジュール２１４は、プロセッサ２０４と連携して、特定のデジタル通貨ユニットをブロックチェーンに追加するか、またはブロックチェーンから除去すべきであると決定し得る。物理通貨の文脈において、規制モジュール２１４は、プロセッサ２０４と連携して、物理通貨が流通から除去されるべきであると決定し、物理通貨の流通から除去させることができる。規制モジュール２１４は、例えば、物理通貨をシュレッダーにかける、焼却する、または保管するように別の事業体に指示し得る。

検証モジュール２１６は、プロセッサ２０４にブロックチェーン上の取引を検証させるコードを含み得る。検証モジュール２１６は、プロセッサ２０４と連携して、署名事業体の公開鍵を使用してデジタル署名を検証するように構成されたコードを含み得る。デジタル通貨生成モジュール２１２は、プロセッサ２０４と連携して、ブロックチェーン上の他のノードとコンセンサスを達成するように構成されたコードを含み得る。コンセンサス機構は、実装されたプロトコルによって異なってもよい。さらに後述するいくつかの例示的なコンセンサス機構は、プルーフオブステーク、ビザンチンフォールトトレラントアルゴリズム、およびクラッシュフォールトトレラントアルゴリズムである。

図３は、様々な実施形態による、物理通貨をデジタル不換通貨に変換するための方法３００の例を示すフローチャートを示す。方法３００は、中央事業体３０２（図１の中央事業体１０４と実質的に類似してもよい）によって、ブロックチェーン３０６（図１のブロックチェーン１１２と実質的に類似してもよい）を介して実施され得る。方法３００は、例えば、中央事業体３０２によって保持される物理通貨が使用不可能な場合に実施され得る。物理紙幣が破れ、または他の場合には疲弊することがあり、中央事業体３０２は物理通貨を廃止することができる。別の例として、方法３００は、銀行がデジタル通貨の物理通貨を償還するときに実施され得る。

Ｓ３１０において、中央事業体３０２は、物理通貨を受信する。中央事業体３０２は、銀行から（使用不可能または使用可能な形態で）物理通貨を受信し得る。中央事業体は、物理通貨をデジタル通貨に変換すべきであると決定し得る。例えば、中央事業体３０２は、物理通貨を検査し、物理通貨が使用不可能であると決定し得る。別の例として、中央事業体３０２は、現地の銀行から、物理通貨をデジタル通貨に変換するための要求を受信してもよい。

Ｓ３２０において、中央事業体３０２は、流通から物理通貨を除去する。中央事業体３０２は、物理通貨を破棄してもよい。中央事業体３０２は、例えば、物理通貨をシュレッダーにかけるか、または焼却してもよい。追加的にまたは代替的に、中央事業体３０２は、中央事業体３０２のエージェント（例えば、シュレッダー会社）などの別の事業体に、中央事業体３０２の指示で物理通貨を破棄させてもよい（例えば、物理通貨の破棄を要求するメッセージを中央事業体３０２のエージェントに送信する）。追加的にまたは代替的に、中央事業体は、安全な場所に物理通貨を保管することによって、流通から物理通貨を除去し得る。

いくつかの実施形態では、１つ以上のブロックチェーンノードは、不換通貨システムからの額面金額を有する物理通貨の、ブロックチェーンからの除去に関連するアクションをさらに記録し得る。ブロックチェーンノードは、特定の物理通貨単位が流通から除去されたことを示す記録を記憶し得る。例えば、物理通貨を破棄する前に、中央事業体３０２は、物理通貨の額面金額（例えば、１ドル、５ドル、２０ドルなど）、物理通貨の記番号、および／または場所などを含む、物理通貨に関する情報を記録し得る。

Ｓ３３０において、中央事業体３０２は、ブロックチェーンにスマートコントラクトをデプロイする。スマートコントラクトは、失効した物理通貨の記番号および額面金額を含む。スマートコントラクトは、契約の交渉または履行をデジタル的に促進、検証、および／または強制することを意図したコンピュータプロトコルを指すことができる。スマートコントラクトは、第三者を介さずに信頼できる取引を実施することを可能にし得る。スマートコントラクトは、ブロックチェーン３０６上のチェーンコードの形態であってもよい。

Ｓ３４０において、中央事業体３０２は、ブロックチェーン３０６上の物理通貨の値をデジタル通貨に変換する。中央事業体３０２は、ブロックチェーン３０６上に記録を生成することによって、ブロックチェーン３０６上にデジタル通貨を生成し得る。いくつかの実施形態では、デジタル通貨を生成することは、新しい通貨を生成する許可を検証するための証明書の使用を伴い得る。追加的にまたは代替的に、デジタル通貨を生成することは、暗号ハッシュ関数を用いて数学的問題を解決することを伴い得る。

Ｓ３５０において、ブロックチェーン３０６は、中央事業体のブロックチェーンアカウント３０４においてデジタル不換通貨を利用可能にする。デジタル不換通貨は、中央事業体の公開鍵などの中央事業体ブロックチェーンアカウント３０４の識別子と関連付けてブロックチェーン３０６に記録されてもよく、この識別子は、デジタル不換通貨が中央事業体３０２に割り当てられていることを示すために、ブロックチェーンの取引データに記録されてもよい。

いくつかの実施形態では、記憶された記番号は、偽造された物理通貨の使用を防止するために使用され得る。物理通貨をデジタル通貨で置き換えた後（例えば、第１の要求に基づいて）、中央事業体コンピュータは、デジタル通貨の第２の要求を受信し得る。第２の要求は、第２の物理通貨の記番号および額面金額を含む。第２の物理通貨は、以前に破棄された物理通貨の偽造であり、第２の物理通貨の記番号および額面金額は、第１の物理通貨の記番号および額面金額と同じである。中央事業体コンピュータは、記番号および額面金額に対応するデジタル通貨がブロックチェーンにすでに記録されていることを決定する。例えば、中央事業体コンピュータは、ブロックチェーンおよび／または世界状態データベース（図７Ａに関して後述される）に問い合わせて、特定の記番号が、生成されたデジタル通貨ですでに使用されているかどうかをチェックしてもよい。記番号がすでに使用されていることを決定することに基づいて、中央事業体コンピュータは、第２の要求に基づいて第２のデジタル通貨を生成することを控える。

同様に、流通から除去された物理通貨の記番号を記録することによって、偽造券の使用を防止することができる。例えば、破棄されるはずの銀行券が後の取引で再出現した場合、中央事業体は、額面金額および記番号に基づいて、銀行券を破棄するように最初に要求した銀行の名前を識別するために、ブロックチェーンをチェックすることができる。

図４は、様々な実施形態による、ユーザが物理通貨をデジタル不換通貨に交換するための方法４００の例を示すフローチャートを示す。方法４００は、中央事業体４０４（図１の中央事業体１０４と実質的に類似してもよい）、償還事業体４０３（図１の償還事業体１０２と実質的に類似してもよい）、および対応するブロックチェーンアカウント４０２を有するユーザ４０１（図１のユーザ１０８と実質的に類似してもよい）によって、ブロックチェーン４０６（図１のブロックチェーン１１２と実質的に類似してもよい）を介して実施されてもよい。

Ｓ４１０において、ユーザ４０１は、償還事業体４０３（例えば、ＡＴＭまたは銀行の所在地）に物理通貨（例えば、１つ以上の現金券）を提供する。例として、ユーザ４０１は、ＡＴＭに行き、１００ドル札を挿入し得る。次いで、ユーザ４０１は、物理通貨をデジタル不換通貨に償還するための選択肢を選択するボタンを操作し得る。別の例として、ユーザ４０１は銀行に入り、１００ドル札を窓口係に手渡して、１００ドル札をデジタル不換通貨に償還したいと窓口係に口頭で指示し得る。

Ｓ４２０において、償還事業体４０３は、物理通貨をデジタル不換通貨に変換するための要求を中央事業体４０４に送信する。要求は、物理通貨の額面金額（例えば、１００ドル）および物理通貨の記番号（例えば、特定の紙幣の記番号）を含み得る。償還事業体４０３は、例えば、ネットワークを介して電子メッセージによって、および／または中央事業体４０４によって公開されるアプリケーションプログラミングインターフェース（ＡＰＩ）へのプッシュを介して、要求を送信してもよい。

Ｓ４３０において、中央事業体４０４は、物理通貨の記番号および額面金額を含むスマートコントラクトをブロックチェーンにデプロイする。中央事業体４０４は、図３のＳ３３０に関して上述したのと同様の方式で、ブロックチェーンにスマートコントラクトをデプロイし得る。スマートコントラクトは、物理通貨の記番号を含み得る。記番号は、物理通貨に印刷され、偽造防止に使用される文字と数字との組み合わせであり得る。デジタル通貨記録に記番号を含めることによって、デジタル通貨に同様の機能を提供することができる。スマートコントラクトは、物理通貨の額面金額（例えば、Ｓ４１０において償還された物理通貨の表面に記載される１ドル、１００ドルなど）を含み得る。

Ｓ４４０において、中央事業体４０４は、銀行券の値をブロックチェーン上のデジタル不換通貨に変換する。スマートコントラクトは、一連の検証事業体（図４には示されない。図１の検証事業体１１０Ａ～１１０Ｃを参照）がブロックチェーン上で取引を検証し、記録したら、中央事業体のブロックチェーンアカウント４０５に保持されるデジタル通貨に確定され得る。ブロックチェーン上のデジタル不換通貨への銀行券の値の変換は、中央事業体のブロックチェーンアカウントのアドレスを、取引のブロックチェーン記録に記録することを含み得る。

Ｓ４５０において、中央事業体４０４は、物理通貨に対応するデジタル不換通貨がブロックチェーン上にあることを償還事業体４０３に通知する。中央事業体４０４は、償還事業体４０３に通知を送信し得る。通知は、取引金額、記番号、送信先アドレス、宛先アドレスなどの情報を含み得る。

Ｓ４６０において、償還事業体４０３は、物理通貨を破棄する。あるいは、この確認を受信すると、償還事業体４０３は、物理通貨を中央事業体４０４または中央事業体４０４のエージェントに送信して、物理通貨を破棄してもよい。いくつかの実施形態では、償還事業体４０３は、破棄または破棄のための一括送信の前に、破棄のために予定された物理通貨を保管してもよい。いくつかの実施形態では、物理通貨は、破棄することなく（例えば、金庫に封印することによって）、流通から除去されてもよい。

Ｓ４７０において、中央事業体ブロックチェーンアカウント４０５は、ユーザ４０１への転送をブロックチェーンに記録する。ユーザ４０１のデジタルウォレットのアドレス、ユーザ４０１のデジタルウォレットの公開鍵、転送金額、および／または中央事業体４０４の秘密鍵を使用して生成された署名などの情報を含む転送取引は、ブロックチェーンに記録され得る。

Ｓ４８０において、デジタル通貨はユーザアカウントに関連付けられる。データは、ユーザ４０１のブロックチェーンアカウント４０２に記憶されてもよく、これは、デジタル通貨がここでユーザ４０１によって保持されることを示す。かかる情報は、取引金額、取引識別子、および記番号を含み得る。したがって、方法は、デジタルウォレットに記憶された秘密鍵を使用して、デジタル通貨をデジタルウォレットに関連付けることを含み得る。これにより、デジタル通貨がウォレットに安全に記憶され、秘密鍵を保持するユーザ４０１によってのみ転送され得ることを確実にし得る。

Ｓ４９０において、デジタル通貨は、ユーザ４０１のモバイルウォレット内のユーザ４０１のアカウントに記録される。ユーザデバイスに記憶されたモバイルウォレットは、そのモバイルウォレットに関連付けられたデジタル通貨の金額を追跡し得る。モバイルウォレットは、ユーザ４０１がユーザの現在のデジタル不換通貨の保持量を正確に把握することができるように、以前に記憶された金額を増加することができる。いくつかの実施形態では、デジタル通貨は、事業体秘密鍵で保護された事業体モバイルウォレット上の値に変換される。

一度発行されると、ユーザまたは銀行などの事業体は、電子通貨をウォレットからウォレットに転送するか、またはデジタル通貨をスマートカードに記憶し、スマートカードを別の事業体に転送してもよい。いくつかの実施形態では、事業体は、デジタル通貨を最小の構成要素（例えば、米国ペニーに類似する）まで分割することができ得る。各小額の金額は、秘密鍵に関連付けられてもよく、事業体のモバイルウォレットは秘密鍵を記憶してもよい。事業体は、現金銀行券を交換することによって取得した最初のデジタル通貨よりも小さな金額を他の事業体に転送し得る。第１の事業体は、その値／金額に関連付けられた秘密鍵を第２の事業体と単に共有することによって、値を第２の事業体に転送し得る。

図５は、様々な実施形態による、ブロックチェーン上の許可を管理するための例示的な構成要素５００を示す。図１に関して上述したように、取引処理ネットワーク１０６は、ブロックチェーン上でアクションを実施するための許可を制御する認証局およびメンバーシップサービスプロバイダとして機能してもよく、これは、図５に関して説明したような証明書スキームを使用して実装されてもよい。ＭＳＰ５０２は、取引処理ネットワーク１０６であり得る。追加的にまたは代替的に、ローカルＭＳＰ ５０２は、組織のメンバーの許可を制御するために、銀行などの組織内で割り当てられてもよい。

ＭＳＰ ５０２は、デジタル不換通貨インフラストラクチャにおいて事業体が果たすことができる特定の役割を識別し得る。例えば、（図１に示す事業体を参照して）中央事業体１０４は、デジタル通貨を作成または破棄する単独の許可を付与され得る。ユーザ１０８は、デジタル通貨を互いに転送する許可を付与され得る。検証事業体１１０Ａ～１１０Ｃは、取引を検証してブロックチェーンに記録する許可を付与され得る。このような許可に基づいて、ＭＳＰ ５０２はアクセス権限を定義するための基礎を設定する。このようなアクセス権限は、ネットワークおよびチャネル（例えば、チャネル管理者、読み取り担当者、書き込み担当者など）の文脈にあってもよい。さらに、ＭＳＰ ５０２は、失効した識別情報のリストの識別を可能にし得る。ＭＳＰ ５０２は、後に考察されるように、ブロックチェーン上の許可を制御するための証明書および鍵を記憶するための複数のフォルダを管理してもよい。

ＭＳＰ ５０２は、すべてのメンバー組織（例えば、特定の銀行）およびそのユーザ（例えば、銀行の特定の部門または従業員）のネットワーク識別情報を管理し得る。ＭＳＰ ５０２は、アクセス制御リスト（ＡＣＬ）に基づくネットワークアクティビティ制御を有効にするために、すべてのユーザに対して許可された識別情報を確立し得る。この識別情報は、すべての取引が、最終的に登録ユーザに対して追跡可能であることを保証するために使用され得る。

ルートＣＡフォルダ５０４は、ＭＳＰ ５０２によって信頼される事業体の自己署名証明書（例えば、Ｘ．５０９証明書など）のリストを含み得る。ＭＳＰ ５０２は、ネットワークへの参加が認証された各メンバー（組織または個人）にルート証明書（ｒｏｏｔＣｅｒｔ）を発行することができる。いくつかの実施形態では、ＭＳＰフォルダに少なくとも１つのルートＣＡ証明書が必要である。ルートＣＡフォルダ５０４は、ＣＡを、対応する組織のメンバーとみなされるために他のすべての証明書が派生される必要のあるＣＡから識別するので、最も重要なフォルダであり得る。

また、ＭＳＰ ５０２は、各メンバー構成要素、サーバ側アプリケーション、および場合によってはユーザに、登録証明書（ｅＣｅｒｔ）を発行することもできる。また、各登録ユーザは、取引証明書（ｔＣｅｒｔ）の割り当ても許可され得る。各ｔＣｅｒｔは１つのネットワーク取引を認証する。認証局（ＣＡ）は、組織がネットワークで認証を行うための証明書を発行する。

中間ＣＡフォルダ５０６は、組織によって信頼される中間ＣＡの証明書（例えば、Ｘ．５０９証明書）のリストを含み得る。様々な実施形態によれば、各証明書は、ＭＳＰ内のルートＣＡのうちの１つ、または中間ＣＡによって署名されなければならず、この発行ＣＡのチェーンは、最終的に信頼されるルートＣＡにつながる。中間ＣＡは、組織の異なる下位区分を表すか（ＯＲＧ１－ＭＡＮＵＦＡＣＴＵＲＩＮＧおよびＯＲＧ１－ＤＩＳＴＲＩＢＵＴＩＯＮがＯＲＧ１に対して行うように）、または組織自体を表し（組織の識別情報管理に商用ＣＡを利用する場合のように）得る。後者の場合、中間ＣＡは組織の下位区分を表すために使用され得る。いくつかの実施形態によれば、機能しているネットワークは、中間ＣＡを有しない場合があり、その場合、このフォルダは空であり得る。ルートＣＡフォルダと同様に、中間ＣＡフォルダは、組織のメンバーとみなされるために証明書を発行する必要があるＣＡを定義する。

組織単位（ＯＵ）５０８は、ファイル（例えば、＄ＦＡＢＲＩＣ＿ＣＦＧ＿ＰＡＴＨ／ｍｓｐ／ｃｏｎｆｉｇ．ｙａｍｌファイル）にリストされてもよく、ＭＳＰによって表される組織の一部とみなされるメンバーを含んでもよい。組織単位５０８のリストは、ＣＡが、組織のメンバーを、特定のＯＵ５０８を有する識別情報（例えば、ＭＳＰ指定のＣＡのうちの１つによって署名されたもの）を保持する組織のメンバーに制限することを可能にし得る。様々な実施形態によると、ＯＵ５０８を指定することは任意選択であってもよい。ＯＵ ５０８がリストされていない場合、ルートＣＡおよび中間ＣＡフォルダによって識別されるすべての識別情報は、組織のメンバーとみなされ得る。

管理者フォルダ５１０は、組織の管理者の役割を有するアクターを定義する識別情報のリストを含み得る。標準ＭＳＰ ５０２タイプの場合、リストに１つ以上の証明書（例えば、Ｘ．５０９証明書など）があるべきである。ただし、管理者の役割を有するアクターが、必ずしも特定のリソースを管理しなくてもよい。所定の識別情報がシステムの管理に関して有する実際の力は、システムリソースを管理するポリシーによって決定され得る。例えば、チャネルポリシーは、ＯＲＧ１－ＭＡＮＵＦＡＣＴＵＲＩＮＧ管理者がチャネルに新しい組織を追加する権限を有するのに対し、ＯＲＧ１－ＤＩＳＴＲＩＢＵＴＩＯＮ管理者はそのような権限を有しないことを規定し得る。証明書がＲＯＬＥ属性（例えば、アクターが管理者であることを指定する）を有しても、これはブロックチェーンネットワークではなく、組織内でのアクターの役割を指す。これは、組織単位属性の目的と類似しており、組織単位属性は、定義されている場合は、組織内のアクターの場所を指す。ＲＯＬＥ属性は、ある組織（または特定の組織）の任意の管理者が特定のチャネル機能（チェーンコードのインスタンス化など）を実施することを許可するようにチャネルのポリシーが書かれている場合、チャネルレベルの管理権を付与するために使用され得る。したがって、組織的役割は、ネットワークの役割を与えることができる。

失効した証明書フォルダ５１２は、失効したアクターの身元に関する識別情報が含まれ得る。ＭＳＰ ５０２は、アクター自体の識別情報を記憶することを控えてもよい。証明書に基づく識別情報の場合、これらの識別子はサブジェクト鍵識別子（ＳＫＩ）および権限アクセス識別子（ＡＫＩ）と呼ばれる文字列のペアであり、証明書が失効していないことを確認するために証明書が使用されるたびにチェックされる。このリストは、ＣＡ証明書失効リスト（ＣＲＬ）と同じものであってもよいが、組織からのメンバーシップの失効に関連する場合もある。その結果、ローカルまたはチャネルのＭＳＰの管理者は、ＣＡの更新済みＣＲＬを広告することによって、アクターまたはノードを組織から迅速に失効させることができる。この「リストのリスト」は任意選択であってもよく、証明書が失効したときのみ入力されてもよい。

署名証明書フォルダ５１４は、ノードの識別情報、すなわち、キーストアの内容と組み合わせて、ノードがそのチャネルおよびネットワークの他の参加者に送信するメッセージにおいて自身を認証することを可能にする暗号材料を含み得る。証明書に基づく識別情報の場合、フォルダは、証明書（Ｘ．５０９証明書など）を含む。これは、例えば、同業者が取引提案応答に付け、同業者がそれを承認したことを示す証明書であり、その後、検証時に結果として生じる取引の承認ポリシーに対してチェックされ得る。

キーストアフォルダ５１６は、暗号鍵を記憶してもよい。いくつかの実施形態では、キーストアフォルダは秘密鍵を記憶する。キーストアフォルダは、同業者または注文者ノード （またはクライアントのローカルＭＳＰにおいて）のローカルＭＳＰに対して定義されてもよく、またノード署名鍵を含む。この鍵は、ノード識別情報フォルダに含まれるノード識別情報と暗号的に一致し、データに署名するために使用される（例えば、取引提案応答に署名するため）。このフォルダは、ローカルＭＳＰに必須であり得、正確に１つの秘密鍵のみを含む必要がある。このフォルダへのアクセスは、同業者に対する管理責任を有するユーザの識別情報のみに制限され得る。チャネルＭＳＰの構成は、チャネルＭＳＰが識別情報検証機能を提供することのみを目的とし、署名能力を提供しないため、このフォルダを含まない場合がある。

トランスポートレイヤーセキュリティ（ＴＬＳ）ルートＣＡフォルダ５１８は、ＴＬＳ通信のためにこの組織が信頼されるルートＣＡの自己署名証明書（たと場、Ｘ．５０９証明書など）のリストを含み得る。ＴＬＳ通信の例としては、同業者が、台帳の更新を受信することができるように、別のノード（Ｈｙｐｅｒｌｅｄｇｅｒの実施形態における注文者など）に接続する必要がある場合であり得る。ＭＳＰ ＴＬＳ情報は、ネットワーク内のノード、つまり、ネットワークを消費するアプリケーションおよび管理者ではなく、同業者および注文者に関係する。いくつかの実施形態では、このフォルダに少なくとも１つの ＴＬＳルートＣＡ Ｘ．５０９証明書が必要である。

ＴＬＳ中間ＣＡフォルダ５２０は、ＴＬＳ通信のためにこのＭＳＰによって表される組織によって信頼されるリスト中間ＣＡ証明書ＣＡを含み得る。このフォルダは、組織のＴＬＳ証明書に商用ＣＡを使用する場合に特に有用である。メンバーシップの中間ＣＡと同様に、中間ＴＬＳ ＣＡの指定は任意選択であってもよい。

この証明書に基づくネットワークメンバーシップおよびアクションの制御により、メンバーは、特定のユーザ識別情報によって、プライベートおよび機密のチャネル、アプリケーション、データへのアクセスを制限することが可能になる。本明細書で考察される様々な実施形態によれば、取引処理ネットワークは、コンテナを提供してもよく、中央事業体は、内容を提供することを許可された唯一の利害関係者であってもよい。その後、内容は別のユーザアカウントから転送され得る。言い換えれば、デジタル不換通貨資産は、特定の時点で特定のユーザによって所有され得る。異なる利害関係者は、それらのｔＣｅｒｔを使用して認証され得る。

デジタル不換通貨インフラストラクチャの管理に使用されるチェーンコードは、様々なアプリケーションによって送信された取引を通じて台帳の状態を初期化および管理し得る。チェーンコードは、ネットワークのメンバーによって同意されたビジネスロジックを処理してもよく、そのようなものとして、チェーンコードはスマートコントラクトとみなされ得る。資産管理アプリケーションは、非検証同業者をブートストラップし、資産管理チェーンコードをデプロイ、呼び出し、クエリするための機密取引を構成し得る。特に、あるシナリオでは、第１の事業体（例えば、Ａｌｉｃｅ）は、チェーンコードデプロイヤであり得る。第２の事業体（例えば、Ｂｏｂ）は、チェーンコード管理者および資産所有者であり得る。第３の事業体（例えば、Ｃｈａｒｌｉｅ）は、資産所有者であり得る。Ａｌｉｃｅは、Ｂｏｂに管理者役割をデプロイし、割り当ててもよい。Ｂｏｂは、資産「Ｐｉｃａｓｓｏ」をＣｈａｒｌｉｅに割り当ててもよく、Ｃｈａｒｌｉｅは、Ｐｉｃａｓｓｏの所有権をＤａｖｅに転送してもよい。

図６は、第１の事業体がデジタル不換通貨資産を第２の事業体に送信する場合の、デジタル不換通貨を使用した資産管理のための例示的な方法６００を示すフローチャートである。方法６００は、ブロックチェーン６１０（図１のブロックチェーン１１２と実質的に類似してもよい）を介して、取引処理ネットワーク６０２（図１の取引処理ネットワーク１０６と実質的に類似してもよい）、中央事業体６０４（図１の中央事業体１０４と実質的に類似してもよい）、ならびに２人のユーザ、Ａｌｉｃｅ ６０６およびＢｏｂ ６０８（図１のユーザ１０８と実質的に類似してもよい）によって実施されてもよい。

Ｓ６２０において、取引処理ネットワーク６０２は、帯域外チャネルを介して、中央事業体６０４から取引証明書（ｔＣｅｒｔ）（「ＣＢＣｅｒｔ」）を取得する。取引処理ネットワーク６０２は、ｔＣｅｒｔを評価および検証してもよい。取引処理ネットワーク６０２は、中央事業体６０４が、ブロックチェーン６１０上で取引を開始する許可を有することを決定し得る。

Ｓ６２２において、取引処理ネットワーク６０２は、デプロイ取引構成を生成する。デプロイ取引構成は、ＣＢＣｅｒｔからの証明書、またはそのバイナリ形式をメタデータとして含み得る。

Ｓ６２４において、取引処理ネットワーク６０２は、デプロイ取引をブロックチェーンに送信する。取引処理ネットワーク６０２は、取引データをブロックチェーンに記憶してもよく、このブロックチェーンは、Ｓ６２０においてｔＣｅｒｔを検証することに基づいて、中央事業体が管理権を有することを指定する情報を含み得る。

Ｓ６２６において、中央事業体６０４は、チェーンコードの管理者になる。ｔＣｅｒｔ、ＣＢＣｅｒｔ、およびその他のメタデータを含み得る、デプロイされた取引情報に基づいて、中央事業体６０４は、ユーザＡｌｉｃｅ ６０６などの他の事業体の証明書を検証する管理権限を引き受けてもよい。

Ｓ６２８において、中央事業体６０４は、第１のユーザ、Ａｌｉｃｅ ６０６のｔＣｅｒｔ（「ＡｌｉｃｅＣｅｒｔ」）を取得し得る。中央事業体６０４は、帯域外チャネルを介してＡｌｉｃｅＣｅｒｔを取得し得る。例えば、Ａｌｉｃｅ ６０６は、デジタル不換通貨の転送を開始し得る。Ａｌｉｃｅ ６０６は、ユーザデバイスを介して、ユーザ証明書ＡｌｉｃｅＣｅｒｔ、Ａｌｉｃｅ公開鍵、および／またはＡｌｉｃｅ ６０６が保持するデジタルウォレットに関連付けられたアドレスを含むがこれに限定されない、転送を開始するための情報を送信し得る。

Ｓ６３０において、中央事業体６０４は、呼び出し取引構成を生成する。中央事業体６０４は、アクセス権を取得するために、その証明書ＣＢＣｅｒｔを使用して呼び出し取引構成を生成し、デジタル通貨をＡｌｉｃｅ ６０６に割り当てるための割り当て関数を呼び出し得る。いくつかの実施形態では、割り当て関数は、デジタル不換通貨がＡｌｉｃｅ ６０６の証明書であるＡｌｉｃｅＣｅｒｔを使用してＡｌｉｃｅ ６０６に割り当てられることを示すパラメータ（「デジタル不換通貨」、Ｂａｓｅ６４（ＤＥＲ（ＡｌｉｃｅＣｅｒｔ）））を渡し得る。

Ｓ６３２において、中央事業体６０４は、次いで、ブロックチェーン６１０に取引を提出し得る。中央事業体６０４は、中央事業体６０４の公開鍵および／またはアドレス（例えば、「送信元」フィールド内）ならびにＡｌｉｃｅ ６０６の公開鍵および／またはアドレス（例えば、「宛先」フィールド内）を含み得る、ブロックチェーン上のブロックに取引データを記憶し得る。取引データは、金額、通貨タイプ、記番号、および証明書情報（例えば、ＣＢＣｅｒｔ、ＡｌｉｃｅＣｅｒｔ、および／またはｔＣｅｒｔ）をさらに含み得る。

Ｓ６３４において、Ａｌｉｃｅ ６０６は、中央事業体の呼び出し取引構成で識別されたデジタル不換通貨の所有者になる。１つ以上の検証事業体がブロックチェーン上で取引を検証することができ、その時点でＡｌｉｃｅ ６０６は、正式にデジタル不換通貨の新しい所有者とみなされ得る。

Ｓ６３６において、Ａｌｉｃｅ ６０６は、第２のユーザであるＢｏｂのｔＣｅｒｔ（「ＢｏｂＣｅｒｔ」）を取得し得る。Ａｌｉｃｅ ６０６は、Ａｌｉｃｅ ６０６からＢｏｂ ６０８へのデジタル通貨の転送の開始に関連付けて、ＢｏｂＣｅｒｔを取得し得る。例えば、Ｂｏｂ ６０８は、ユーザデバイスを介して、Ｂｏｂ ６０６に情報を送信して、ユーザ証明書ＢｏｂＣｅｒｔ、およびＢｏｂ ６０８が保持するデジタルウォレットに関連付けられたアドレスまたは公開鍵を含むがこれに限定されない、転送を開始するための情報をＡｌｉｃｅ ６０６に転送し得る。いくつかの実施形態では、アドレスは公開鍵の変更された形態である。

Ｓ６３８において、Ａｌｉｃｅ ６０６は呼び出し取引を構成し得る。Ａｌｉｃｅ ６０６は、ＡｌｉｃｅＣｅｒｔを使用して転送関数を呼び出すために、呼び出し取引を構成し得る。転送関数は、パラメータ（「デジタル不換通貨」、Ｂａｓｅ６４（ＤＥＲ（ＢｏｂＣｅｒｔ）））として渡され得る。

その後、Ｓ６４０において、Ａｌｉｃｅ ６０６は、ブロックチェーン６１０に取引を提出し得る。Ａｌｉｃｅは、取引金額およびＢｏｂのデジタルウォレットアドレスなどの情報をブロックチェーンに送信し得る。また、この情報はさらに、Ａｌｉｃｅの秘密鍵を使用して署名されてもよく、この秘密鍵は、Ａｌｉｃｅのユーザデバイスのセキュアエレメントおよび／またはＡｌｉｃｅの支払カード上のチップから取得されてもよい。また、この情報は、Ａｌｉｃｅの公開鍵および／またはデジタルウォレットアドレスをさらに含み得る。いくつかの実施形態では、ユーザは、図８に関して示し、後述するように、ユーザインターフェースを使用して取引を開始し得る。

Ｓ６４２において、Ｂｏｂ ６０８は、呼び出し取引構成で識別されるデジタル不換通貨の所有者になる。Ｂｏｂは、ブロックチェーン上の複数の記録事業体によって検証／記録される取引の対象となるデジタル不換通貨の所有者となり得る。検証事業体は、Ｂｏｂおよび／またはＡｌｉｃｅの公開鍵をさらに確認して、取引を検証し得る。

Ｓ６４２の後、Ｂｏｂ ６０８は、デジタル不換通貨資産が複数の事業体間で渡されるように、デジタル通貨を別の事業体などに転送し得る。例えば、Ａｌｉｃｅ ６０６（または代替的にもしくは追加的に、取引処理ネットワーク６０２）は、帯域外チャネルを介して、Ｂｏｂ ６０８のｔＣｅｒｔ（「ＢｏｂＣｅｒｔ」）を取得し得る。Ａｌｉｃｅ ６０６は、Ｂｏｂ ６０８のｔＣｅｒｔ（ＢｏｂＣｅｒｔ）またはそのバイナリ形式の証明書をメタデータとして含む、デプロイ取引構成を生成し得る。次いで、Ａｌｉｃｅ ６０６は、デプロイ取引をブロックチェーン６１０に提出し得る。Ｂｏｂ ６０８は、チェーンコードの管理者になる。後日、Ｂｏｂ ６０８は、別のユーザであるＣｈａｒｌｉｅのｔＣｅｒｔ（「ＣｈａｒｌｉｅＣｅｒｔ」）を取得し得る。Ｂｏｂ ６０８は、アクセス権を取得するために、自身のｔＣｅｒｔ（例えば、ＢｏｂＣｅｒｔ）を使用して呼び出し取引構成を生成し、パラメータ（「デジタル不換通貨」、Ｂａｓｅ６４（ＤＥＲ（ＣｈａｒｌｉｅＣｅｒｔ）））として渡される割り当て関数を呼び出し得る。次いで、Ｂｏｂ ６０８は、ブロックチェーン６１０に取引を提出し得る。こうすることで、ＣｈａｒｌｉｅはＢｏｂ ６０８の呼び出し取引構成で識別されたデジタル不換通貨の所有者になる。後日、Ｃｈａｒｌｉｅは別のユーザであるＤａｖｅのｔＣｅｒｔ（「ＤａｖｅＣｅｒｔ」）を取得し得る。Ｃｈａｒｌｉｅは、ｔＣｅｒｔ（ＣｈａｒｌｉｅＣｅｒｔ）を使用して呼び出し取引を構成し、転送関数をパラメータ（「デジタル不換通貨」、Ｂａｓｅ６４（ＤＥＲ（ＤａｖｅＣｅｒｔ）））として渡し得る。Ｃｈａｒｌｉｅは、取引をブロックチェーン６１０に提出し得る。こうすることで、ＤａｖｅはＣｈａｒｌｉｅの呼び出し取引構成で識別されたデジタル不換通貨の所有者になる。

図７Ａ～図７Ｃは、様々な実施形態による、ブロックチェーン上のデジタル不換通貨取引を記録するために使用されるデータおよびメタデータの例を示す。図７Ａは、ブロックチェーンを含む台帳を示す。図７Ｂおよび図７Ｃは、ブロックチェーンに記憶され得るデータを示す。

図７Ａは、いくつかの実施形態による台帳７０２を示す。台帳７０２は、ブロックチェーン７０４と、世界状態データベース７０６と、を含む。いくつかの実施形態では、台帳７０２は、デジタル通貨取引に関連するデータを記憶するための分散型台帳である。台帳７０２は、図１に関して上述したように、１つ以上のブロックチェーンノードによって記憶され得る。

いくつかの実施形態では、世界状態データベース７０６は、一組の台帳状態の現在値を保持するデータベースである。例えば、世界状態データベース７０６は、デジタル通貨の各単位の現在の保持者を指定してもよい（例えば、Ａｌｉｃｅはデジタル通貨で４００ドル、Ｂｏｂはデジタル通貨で３００ドル、銀行Ｘはデジタル不換通貨で１，０００万ドル、など）。

いくつかの実施形態では、ブロックチェーン７０４は、世界状態を決定する変更を記録する取引ログである。ブロックチェーン７０４は、図１に関して上述したブロックチェーン１１２と実質的に類似してもよい。ブロックチェーン７０４は、図７Ｂおよび図７Ｃに関して後述するように、データを記憶し得る。

図７Ｂは、ブロックチェーン７０４上のデータを示す。ブロックチェーン７０４は、複数のブロック（例えば、ブロック０ ７０７、ブロック１ ７１４、およびブロック２ ７２２、ブロックチェーン内に最大数千または数百万のブロックがあり得る）を含む。

ブロック０ ７０７は、チェーンの第１のブロック、すなわちジェネシスブロックである。ブロック０ ７０７はブロックチェーンの基盤を形成する。ブロックチェーンの第１のブロックに対して、ブロックデータ７１０およびブロックメタデータ７１２は空であってもよい。ブロック０ ７０７は、ヘッダ７０８を含む。ジェネシスブロックのヘッダ７０８は、ブロック０ ７０７を、文字、および数字などのチェーン内の他のブロックに紐付けるために使用されるデータを含み得る。このデータは、ハッシュ化および／またはハッシュ化解除された形式で記憶され得る。

ブロック１ ７１４は、チェーン内の第２のブロックである。ブロック１ ７１４は、ブロックデータ１ ７１８を含む。ブロックデータ１ ７１８は、一連の取引（例えば、チェーンコード）のデータを記憶する。図７Ｂでは、取引１に関する情報が示されており、この場合、ＳｈｅｉｌａはＢｒｕｃｅにデジタル通貨で２０ドル送信する。取引１に関するデータはブロック１に記憶され、このデータは、Ｓｈｅｉｌａのパブリックアドレス（例えば、Ｓｈｅｉｌａのデジタルウォレットの公開鍵）、Ｂｒｕｃｅのパブリックアドレス（例えば、Ｂｒｕｃｅのデジタルウォレットの公開鍵）、資産金額（例えば、２０ドル）、および送信元の通貨（例えば、米ドル）を含む。簡略化のために図７Ｂには１つの取引が示されているが、１つのブロックは数百または数千の取引を含み得る。

ブロック１ ７１４は、ブロックメタデータ１ ７２０をさらに含む。ブロックメタデータ１ ７２０は、いくつかの実施形態では、内部に記録された取引に対する当事者に関する識別情報を含み得る。ブロック１のメタデータ７３０は、ブロック１ ７１４の情報に関するデータを含み得る。ブロック１ ７１４は、ヘッダ１ ７１６をさらに含む。ヘッダ１ ７１６は、ブロック番号（例えば、ブロック１）を含み得る。ヘッダ１は、現在のブロックハッシュを含み得る。現在のブロックハッシュは、現在のブロック、ブロック１ ７１４の内容の全部または一部に基づいて生成され得る。ヘッダ１ ７１６は、前のブロックおよびそれ以前のブロック（例えば、マークルルート）、ブロック０ ７０７の全体または一部をハッシュ化することによって生成された前のブロックハッシュを含み得る。場合によっては、前のブロックおよび／または現在のブロックのハッシュ化された内容に、ナンス値が追加される。ナンス値を有するハッシュ化された内容は、更新されたハッシュ化された値を生成するために再度ハッシュ化され得る。この更新されたハッシュ値は、ブロックをより安全な様式で紐付けるために記憶され得る。

ブロック２ ７２２は、チェーン中の第３のブロックである。ブロック２ ７２２は、ブロックデータ２ ７２６を含む。２つの取引のデータはわかりやすく表示されるが、多くの取引のデータはブロック２ ７２２に記憶され得る。図７Ｂに示すように、ブロックデータ２ ７２６は、取引２（例えば、チェーンコード）のためのデータを含んでもよく、ここで銀行券は破棄される。取引２のデータは、銀行券通貨（例えば、米ドル）、金額（例えば、５０ドル）、および記番号（例えば、破棄された物理通貨の記番号）を含む。

ブロック２ ７２２は、ブロックメタデータ２ ７２８をさらに含む。ブロックメタデータ２ ７２８は、ブロック２ ７２２内のデータに関するデータであり得る。ブロック２ ７２２は、ヘッダ２ ７３０をさらに含む。ヘッダ２ ７３０は、ブロック番号（例えば、ブロック２）を含み得る。ヘッダ２ ７３０は、ブロック７２２の現在のブロックハッシュおよびブロック１ ７１４の前のブロックハッシュを含んでもよく、これらはマークルルートであってもよい。現在のブロック ハッシュおよび前のブロックハッシュは、ブロック１ ７１４に関して上述したものと類似してもよい。

ブロックデータ２ ７２６は、取引３ ７３５のデータをさらに含む。取引３ ７３５のデータは、ヘッダ３ ７３５Ａ、署名３ ７３５Ｂ、提案３ ７３５Ｃ、応答３ ７３５Ｄ、および承認３ ７３５Ｅを含む。取引３ ７３５のデータは、図７Ｃにさらに詳細に示される。

ヘッダ３ ７３５Ａは、特定の取引に関連付けられ、取引に関するいくつかの重要なメタデータ（例えば、当事者識別情報、証明書、またはアドレスなどの取引に関する識別情報）を捕捉する。署名３ ７３５Ｂは、暗号署名を含む。暗号署名は、特定のデジタルウォレットの秘密鍵を使用して作成され得る。秘密鍵は、チップカードまたはセキュアエレメントに記憶され得る。

提案３ ７３５Ｃは、アプリケーションがチェーンコードに提供した入力パラメータを符号化し、提案された台帳の更新を作成する。入力パラメータは、資産（例えば、デジタル通貨の単位）および／または廃止された銀行券（例えば、特定の記番号を有する物理的なものが廃止／破棄されたことを示す表記）を指定し得る。

応答３ ７３５Ｄは、読み書きセットであり得る、世界状態の前後の値を捕捉する。応答３ ７３５Ｄは、チェーンコードの出力であり得る。取引が正常に検証されると、応答３ ７３５Ｄが台帳７０２に適用され、世界状態データベース７０６の世界状態を更新する。

承認３ ７３５Ｅは、各必要な検証事業体からの署名入り取引応答のリストである。承認ポリシーを満たすのに十分であるとみなされる、検証事業体の特定のサブセットが必要とされ得る。こうした承認ポリシーは、例えば、中央事業体および／または取引処理ネットワークによって事前構成され得る。

図８は、様々な実施形態による、デジタル不換通貨を管理するための例示的なインターフェース８０４を示す。インターフェース８０４は、スマートフォン、タブレット、またはパーソナルコンピュータなどのユーザデバイス８０２上に表示され得る。

デジタル不換通貨を管理するためのインターフェース８０４は、デジタル不換通貨を送信するためのユーザ入力を受け入れるためのインターフェース要素を含む。インターフェース８０４は、デジタルウォレットがチップカードで開始されるべきことを示すインジケータ８０６を含み得る。これは、ウォレットの秘密鍵がチップカードに記憶されている場合に適用され得る。

デジタル不換通貨を管理するためのインターフェース８０４は、送信者アカウント８１０の資金および通貨のフィールドをさらに含む。利用可能な送信者アカウントのユーザ選択を受信すると、インターフェース８０４は、対応するアカウント内の利用可能な資金を通貨（例えば、米ドル、および英国ポンドなど）とともに表示し得る。同様に、インターフェース８０４は、受取人アカウント８１４の資金および通貨のフィールドを使用して、選択された受取人アカウント内で利用可能な資金および通貨を表示し得る。

デジタル不換通貨を管理するためのインターフェース８０４は、送信する金額のフィールド８１６および送信ボタン８１８をさらに含む。送信する金額のフィールド８１６は、ユーザが入力した、または別の方法で提供する数字を受け入れるように構成されたフォームフィールドであり得る。例えば、８１６を送信する金額として、ユーザはフィールドに１５０ドルと入力することができる。必要な情報が提供されると、インターフェース８０４は、送信ボタン８１８に対するユーザの操作を受け入れることができる。送信ボタン８１８に対するユーザの操作を検出すると、ブロックチェーン上で取引を模倣するために、取引詳細はバックエンドに送信され得る。

いくつかの実施形態では、イーサリアムは、本明細書に記載される様々な態様を実施するために使用され得る。イーサリアムは、ブロックチェーンフレームワーク実装である。イーサリアムは、オープンソースプラットフォームであり、Ｅｔｈｅｒｅｕｍ：Ａ Ｓｅｃｕｒｅ Ｄｅｃｅｎｔｒａｌｉｓｅｄ Ｇｅｎｅｒａｌｉｓｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｌｅｄｇｅｒ ｂｙ Ｄｒ．Ｇａｖｉｎ Ｗｏｏｄおよびｅｔｈｅｒｅｕｍ．ｏｒｇに詳細に記載されている。

いくつかの実施形態では、デジタル不換通貨は、図９Ａ～図９Ｄに示すように、イーサリアムを使用して実装され得る。図９Ａでは、アカウント情報９００は、システム内の事業体について確立される。イーサリアムアカウントは、取引処理ネットワーク、中央事業体、およびＡｌｉｃｅおよびＢｏｂなどのユーザのために確立される。各事業体のイーサリアムアカウントは、パブリックアドレス－取引処理ネットワーク（ＴＰＮ）パブリックアドレス９０２、Ａｌｉｃｅのパブリックアドレス９０４、Ｂｏｂのパブリックアドレス９０６、および中央事業体のパブリックアドレス９０８によって定義される。

パブリックアドレス９０２～９０８はベクターイーサリアムアカウントに表示され、イーサリアムアカウントベクターの各要素の残高は下に表示される。Ａｌｉｃｅのアカウント残高９１０は０である。Ｂｏｂのアカウント残高９１２は０である。中央事業体のアカウント残高９１４は、１０単位のデジタル不換通貨である。

図９Ｂでは、ブロックチェーン上にコンテナが作成される。コンテナアドレス９２０は、ブロックチェーン上に新しいデジタル不換通貨を確立するためのコントラクトを表す。コンテナは、ブロックチェーン上の中央事業体の取引処理ネットワークによって作成され得る。ブロック番号９２２および受信時間９２４を含むパラメータを有する、イーサリアムブロックが生成される。

図９Ｂは、ブロック内に含まれる取引をさらに示す。取引１は、ハッシュ値９２６によって特徴付けられる。取引１は、取引処理ネットワーク９０２のパブリックアドレスによって示されるように、取引処理ネットワークからのものである。コンテナデータ９２８は、現在のブロックへの入力としてさらに提供される。

図９Ｃは、中央事業体が２デジタル不換通貨をＡｌｉｃｅに送信する第２の取引９３０を示す。取引は、「宛先」フィールドにＡｌｉｃｅのパブリックアドレス９０４、「送信元」フィールドに中央事業体のパブリックアドレス９０８が示されるように、中央事業体からＡｌｉｃｅへのものである。Ａｌｉｃｅの残高９３２は現在、２デジタル不換通貨であり、中央事業体残高９３４は現在、８デジタル不換通貨である。取引は、ハッシュ９３６に関連付けて記録され、ブロック番号６０２（９４４）にある。取引９４２の値は２００００００００であり、これは、中央事業体が２デジタル不換通貨をＡｌｉｃｅに送信したことを示している。取引データは、入力９４０をさらに含み、入力９４０は、デジタル不換通貨に当初変換された物理通貨の記番号を含む。

図９Ｄは、Ａｌｉｃｅが１デジタル不換通貨をＢｏｂに送信する第３の取引９５０を示す。取引は、「送信元」フィールドにＡｌｉｃｅのパブリックアドレス９０４、「宛先」フィールドにＢｏｂのパブリックアドレス９０６が示されるように、ＡｌｉｃｅからＢｏｂへのものである。Ａｌｉｃｅの残高９５２は、１デジタル不換通貨となり、Ｂｏｂの残高９５４は、１デジタル不換通貨となった。取引は、取引を識別するハッシュ９５６に関連付けて記録され、ブロック番号６０５（９５８）である。取引９６０の値は１００００００００であり、Ａｌｉｃｅは、１デジタル不換通貨をＢｏｂに送信したことを示している。

いくつかの実施形態では、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃを使用して、本明細書に記載される様々な態様を実施してもよい。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃは、ブロックチェーンフレームワーク実装であり、Ｔｈｅ Ｌｉｎｕｘ（登録商標） ＦｏｕｎｄａｔｉｏｎがホストするＨｙｐｅｒｌｅｄｇｅｒプロジェクトのうちの１つである。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃは、モジュラーアーキテクチャを用いるアプリケーションまたはソリューションの開発の基盤として意図されており、コンセンサスおよびメンバーシップサービスなどの構成要素をプラグアンドプレイであることを可能にする。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃは、コンテナ技術を活用して、システムのアプリケーションロジックを備えるチェーンコードと呼ばれるスマートコントラクトをホストする。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃは、すべてのユーザおよび構成要素が既知の識別情報を有する許可型ネットワークである。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃは、匿名性を促進し、取引を検証するために暗号通貨および重い計算義務に依存せざるを得ない従来のブロックチェーン実装とは大きく異なる。

ネットワーク（Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃなど）には、台帳、スマートコントラクト、同業者、注文サービス、チャネル、およびファブリック認証局などの様々な構成要素を含み得る。上述された図５は、例示的なメンバーシップサービスプロバイダ（ＭＳＰ）の構造および／または役割を示す。識別情報が検証可能であるためには、その識別情報は信頼される機関からのものでなければならない。メンバーシップサービスプロバイダ（ＭＳＰ）は、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃで信頼される機関として機能することができる。より具体的には、ＭＳＰは、組織の有効な識別情報を管理するルールを定義する構成要素を含み得る。Ｈｙｐｅｒｌｅｄｇｅｒ ＦａｂｒｉｃのデフォルトＭＳＰ実装は、Ｘ．５０９証明書を、従来の公開鍵基盤（ＰＫＩ）階層モデルを採用した識別情報として使用する。他の証明書は、様々な実施形態に従って使用され得る。

いくつかの実施形態では、ブロックチェーンは、プラガブルコンセンサスプロトコルを使用して実装され得る。プラガブルコンセンサスプロトコルの例としては、“Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ”ｂｙ Ｍｉｇｕｅｌ Ｃａｓｔｒｏ ａｎｄ Ｂａｒｂａｒａ Ｌｉｓｋｏｖ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｔｈｉｒｄ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，Ｆｅｂ．１９９９に記述されているビザンチンフォールトトレランスアルゴリズムが挙げられる。別の例としては、“Ｉｎ Ｓｅａｒｃｈ ｏｆ Ｕｎｄｅｒｓｔａｎｄａｂｌｅ Ｃｏｎｓｅｎｓｕｓ Ａｌｇｏｒｉｔｈｍ”ｂｙ Ｄｉｅｇｏ Ｏｎｇａｒｏ ａｎｄ Ｊｏｈｎ Ｏｕｓｔｅｒｈｏｕｔ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＵＳＥＮＩＸ ＡＴＣ’１４，Ｊｕｎｅ ２０１４に記載されている分散型コンセンサスアルゴリズムなどの、クラッシュフォールトトレランスアルゴリズムが挙げられる。

いくつかの実施形態では、コンセンサス機構は、プルーフオブステークである。プルーフオブステークは、保持するデジタル通貨の金額などの要因に基づいて、ブロックチェーンのノードに検証権利を割り当てる。プルーフオブステークは、検証当事者が膨大な計算能力を要する計算を行うことを必要とする、より一般的なプルーフオブワークアルゴリズムよりも著しく効率的である。プルーフオブステークアルゴリズムの一例であるＯｒｏｂｏｒｏｓは、“Ｏｕｒｏｂｏｒｏｓ：Ａ ｐｒｏｖａｂｌｙ Ｓｅｃｕｒｅ Ｐｒｏｏｆ－ｏｆ－Ｓｔａｋｅ Ｂｌｏｃｋｃｈａｉｎ Ｐｒｏｔｏｃｏｌ”ｂｙ Ａｇｇｅｌｏｓ Ｋｉａｙｉａｓ ｅｔ．ａｌ，Ｊｕｌｙ ２０１９に記載されている。

実施形態は、一方の当事者（証明者）が、値ｘを知っているという事実とは別にいかなる情報も伝えずに、値ｘを知っていることを他方の当事者（検証者）に証明することができるゼロ知識証明を使用して実装されてもよい。

実施形態は、ＡＰＩを使用して実装され得る。いくつかの実施形態では、取引処理ネットワークは、すべての参加者に対してシングルポイントアクセスを提供するために使用することができるＡＰＩを公開してもよい。いくつかの実施形態では、ＡＰＩは、デジタル通貨を第１の通貨タイプ（例えば、ドル）から第２の通貨タイプ（例えば、シリング）に変換するために使用されてもよい。このように、デジタル不換通貨は、通貨換算のための比較的単純でフリクションの少ないプラットフォームを提供することができる。いくつかの実施形態では、ソース通貨およびターゲット通貨を取引メタデータに含めることができ、通貨交換は、デジタル不換通貨の転送とシームレスに実施することができる。

Ｈｙｐｅｒｌｅｄｇｅｒ ｆａｂｒｉｃなどの実施形態は、モジュール化および構成可能なアーキテクチャを提供し広範なユースケースのための革新、汎用性、および最適化を可能にする。

いくつかの実施形態では、記録は監査可能であってもよく、構成可能な透明性を提供する。識別情報は、取引処理ネットワークによって維持され得る。この識別情報は、特定のレベルのアクセス制御を管理するために使用することができ、例えば、このユーザは台帳を読むことはできるが、資産を交換または転送することはできない）。Ｈｙｐｅｒｌｅｄｇｅｒ ｆａｂｒｉｃなどの実施形態は、プライバシーが重要な運用要件であるネットワークをサポートするため、プライバシーを提供することができる。プライバシーは、例えば、チャネルを使用して制御することができる。匿名性は、全体的または部分的に提供され得る。例えば、銀行名は、取引に関連付けてブロックチェーンに記録され得るが、個々のユーザの名前は記録され得ない。別の例として、識別情報は、例えば、取引閾値および中央事業体の要件に基づいて、限定された方式で記録され得る。具体的な例としては、１，０００ドル未満の取引は匿名のままでもよく、１，０００ドル以上の取引は関与する事業体の識別情報で記録されてもよい。

実施形態は、複数の利点を提供する。上述したように、従来の暗号通貨システムは、ボラティリティおよび高い電力使用量などの問題がある。これらの問題の多くは、取引処理ネットワークおよび中央事業体によって管理される、プライベート許可型ネットワークを使用して、通貨の流れを高速化および管理することで解決することができる。

有利には、様々なコンセンサスアルゴリズム（例えば、ビザンチンまたはクラッシュフォールトトレラント）が実装され得る。その結果、許可型ネットワークを使用すると、従来のパブリックネットワークで使用される計算上高価な方法と比較して、はるかに高い取引スループット率および性能を提供することができる。

物理通貨は、分散型台帳技術を使用して現金取引を模倣およびデジタル化することによって市場から得ることができる。デジタル通貨は、不換通貨に紐付けられたままであってもよく、中央事業体（例えば、連邦国銀行）によって規制されてもよい。これにより、従来の暗号通貨システムに関連付けられたボラティリティを防止し、中央事業体が金融システムに対する制御を維持することを可能にし得る。

加えて、偽造券の使用および償還を防止し、セキュリティを強化する機会もある。様々な実施形態によれば、事業体がデジタル不換通貨への変換のために物理通貨を中央事業体に引き渡す場合、物理通貨の記番号が、物理通貨がすでに変換されていることを示す場合、変換は拒否され得る。したがって、記番号に対して偽造警告が発せられてもよく、これは、最初の変換およびその後の隠蔽要求の両方に影響を与えてもよい。償還された記番号の監視は、偽造された物理券の使用を防止するためにさらに使用され、金融システム全体のセキュリティを強化することができる。

実施形態はまた、取引に署名するために使用される秘密鍵を記憶するために、チップカードおよび／または携帯電話のセキュアエレメントを使用してことによってセキュリティを強化し得る。いくつかの実施形態では、ユーザは、デジタル不換通貨の所定の金額／値に関連付けられた秘密鍵をスマートカードに記憶し、所定の金額／値のデジタル不換紙幣を、スマートカードに転送するだけで、別の事業体に転送することができる。

本出願に記載のソフトウェア構成要素または機能のいずれかは、例えば、従来のもしくはオブジェクト指向の技法を使用した、例えば、Ｊａｖａ、Ｃ＋＋、またはＰｅｒｌなどの任意の好適なコンピュータ言語を使用する、プロセッサによって実行されるソフトウェアコードとして実装されてもよい。ソフトウェアコードは、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはＣＤ－ＲＯＭのような光媒体などの、コンピュータ可読媒体上の一連の命令またはコマンドとして記憶されてもよい。そのようなコンピュータ可読媒体は、単一の計算装置上またはその内部にあってもよく、システムまたはネットワーク内の異なる計算装置上もしくはその内部に存在し得る。

上の記載は例示であり、限定するものではない。本開示を検討することにより、本発明の多くの変形が、当業者にとって明らかになるであろう。したがって、本発明の範囲は、上記の明細書を参照して決定され得るのではなく、それらの全範囲または同等物とともに、係属中の特許請求の範囲を参照して決定され得る。

任意の実施形態の１つ以上の特徴は、本発明の範囲から逸脱することなく、任意の他の実施形態の１つ以上の特徴と組み合わせてもよい。

「１つの（ａ）」、「１つの（ａｎ）」、または「その（ｔｈｅ）」の列挙は、特に反対の指示がない限り、「１つ以上」を意味することを意図する。

上で言及したすべての特許、特許出願、刊行物、および記載は、あらゆる目的のためにそれらの全体が参照により本明細書に組み込まれる。いずれも先行技術と認められない。

Claims (12)

1. コンピュータ実装方法であって、
   償還事業体コンピュータによって、当該償還事業体コンピュータに取引を検証する許可を与える第１の証明書を取引処理ネットワークから受信することと、
   前記償還事業体コンピュータによって中央事業体コンピュータに、デジタル通貨に対する要求を送信することであって、前記要求が物理通貨の記番号と額面金額を含み、前記中央事業体コンピュータは、当該中央事業体コンピュータにデジタル通貨を生成または破棄する許可を与える第２の証明書を保持する、送信することと、
   前記デジタル通貨が生成されたという通知を前記償還事業体コンピュータによって受信することであって、前記デジタル通貨が前記要求と前記第２の証明書に基づいて前記中央事業体コンピュータによって生成され、前記デジタル通貨を生成することが、前記記番号と前記額面金額を含むレコードにブロックチェーン上の前記デジタル通貨を記録することを含む、受信することと、
   前記通知の受信に応答して、前記償還事業体コンピュータによって、流通からの前記物理通貨の削除を引き起こす、コンピュータ実装方法。
2. 前記ブロックチェーン上の前記デジタル通貨の前記記録が、複数の検証実体によって検証され、前記複数の検証実体は、前記第１の証明書を使用してブロックチェーン上のデジタル通貨を記録する償還事業体コンピュータを含む、請求項１に記載の方法。
3. 流通からの前記物理通貨の削除を引き起こすことが、前記物理通貨を物理的に破棄することを含み、前記物理通貨が不換通貨である、請求項１に記載の方法。
4. 前記物理通貨が第一の物理通貨であり、前記方法が、
   前記償還事業体コンピュータによって前記中央事業体コンピュータに、デジタル通貨に対する第二の要求を送信することであって、前記第二の要求が第二の物理通貨の記番号およびが額面金額を含み、前記第二の物理通貨の前記記番号および前記額面金額が、前記第一の物理通貨の前記記番号および前記額面金額と同じである、送信することと、
   前記償還事業体コンピュータによって前記中央事業体コンピュータから、前記第二の要求に基づいて第二のデジタル通貨を生成することを避ける前記中央事業体コンピュータの表示を受信することであって、前記記番号および額面金額に対応する前記デジタル通貨が前記ブロックチェーンに既に記録されていることを判定する前記中央事業体コンピュータに応答する、受信することと、をさらに含む、請求項１に記載の方法。
5. 前記償還事業体コンピュータによって、前記デジタル通貨の償還のための前記物理通貨を受領することをさらに含む、請求項１に記載の方法。
6. 前記償還事業体コンピュータに関連付けられた銀行にてユーザーから前記物理通貨が受領される、請求項１に記載の方法。
7. 前記物理通貨が使用不可能であることを判定することであって、前記デジタル通貨に対する前記要求が前記判定に応答して送信される、判定することをさらに含む、請求項１に記載の方法。
8. 前記デジタル通貨が、前記中央事業体コンピュータの公開鍵を使用して前記ブロックチェーンに記録される、請求項１に記載の方法。
9. 前記ブロックチェーンが複数のブロックを含み、前記複数のブロックのうちの少なくとも一つのブロックが複数の取引のデータを記憶し、前記複数の取引が、流通からの前記物理通貨の前記削除を記録する第二の記録を含む、請求項１に記載の方法。
10. 前記ブロックチェーンが複数のブロックを含み、前記複数のブロックのうちの少なくとも一つのブロックが複数の取引のデータを記憶し、前記複数の取引が、デジタルウォレットに関連付けられた公開鍵を含む記録を含む、請求項１に記載の方法。
11. コンピュータシステムを制御して、請求項１－１０のいずれか一項に記載の方法を実施するための複数の命令を記憶しているコンピュータ可読媒体。
12. システムであって、
    請求項１１に記載の前記コンピュータ可読媒体と、
    前記コンピュータ可読媒体上に記憶された命令を実行するための一つ以上のプロセッサと、を備える、システム。