JP7141193B2 - ブロックチェーン・ネットワークに対するドキュメント・アクセス - Google Patents

Description

本出願は、一般に、ブロックチェーン・ネットワークに関連しており、より詳細には、ブロックチェーンに対するドキュメント・アクセスおよび処理に関連している。

台帳は、一般に、トランザクションが記録される会計簿として定義される。分散型台帳は、複数のコンピュータに全体的または部分的に複製された台帳である。暗号分散型台帳（ＣＤＬ：Cryptographic Distributed Ledger）は、不可逆性（一度トランザクションが記録されると、そのトランザクションを無効にすることができない）、アクセス可能性（任意の関係者がＣＤＬに全体的または部分的にアクセスできる）、経時的でタイムスタンプが付けられている（すべての関係者が、トランザクションがいつ台帳に追加されたかを知る）、合意に基づく（トランザクションは、ネットワーク上の関係者によって、通常は全員一致で、是認された場合にのみ追加される）、検証可能性（すべてのトランザクションが暗号によって検証され得る）という特性のうちの少なくとも一部を有することができる。ブロックチェーンは、ＣＤＬの例である。本明細書における説明および図は、ブロックチェーンに関して説明されているが、本出願は任意のＣＤＬに同様に適用される。

分散型台帳は、継続的に増大するレコードのリストであり、通常は、他のブロックに関連する暗号学的ハッシュを格納することなどの、暗号手法を適用する。ブロックチェーンは、分散型台帳の１つの一般的例であり、情報を格納するためのパブリックな台帳として使用されてよい。ブロックチェーンは、主に金融トランザクションに使用されるが、商品およびサービスに関連するさまざまな情報（すなわち、製品、パッケージ、状態など）を格納することができる。非集中的方式は、権限および信用を非集中的ネットワークに提供し、そのノードが継続的かつ連続的にトランザクションをパブリックな「ブロック」に記録できるようにし、ブロックチェーンと呼ばれる一意の「チェーン」を作成する。暗号は、トランザクション・ソースの認証を保護するためにハッシュ・コードを介して使用され、中央の仲介を取り除く。ブロックチェーンは、ブロックチェーンのブロック内の継続的に増大するレコードのリストを維持する分散データベースであり、変更不可能な特性のため、改ざんおよび改訂から保護される。各ブロックは、タイムスタンプおよび前のブロックへのリンクを含む。ブロックチェーンは、情報の保持、追跡、転送、および検証に使用され得る。ブロックチェーンは分散システムであるため、トランザクションをブロックチェーン台帳に追加する前に、すべてのピアが合意状態に達する必要がある。

従来、安全なゲートウェイを含むエンティティ間のドキュメントの転送は、ドキュメントの転送および受信の検証の変更不可能なレコードを欠いていた。そのため、複数のエンティティのブロックチェーン・ネットワークが、すべての転送されたドキュメントの受信レコードを提供し、これらの制限を克服することが必要である。

本発明の１つの態様は、第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードを含んでいるブロックチェーン・ネットワークを構成することと、第１のブロックチェーン・ノードによって、データ参照を第２のブロックチェーン・ノードに提供することと、第２のブロックチェーン・ノードによって、第１のブロックチェーン・ノードからのドキュメントにアクセスすることと、第２のブロックチェーン・ノードによって、ドキュメントの受信の証明を共有ブロックチェーン台帳に提供することとのうちの１つまたは複数を含んでいる方法を提供する。

別の態様は、ルート・ノードを含んでいるクラウド・ブローカ、ならびに第１および第２のブロックチェーン・ノードを含んでいるブロックチェーン・ネットワークを含むシステムを提供する。第１のブロックチェーン・ノードは、データ参照を提供するように構成される。第２のブロックチェーン・ノードは、データ参照を第１のブロックチェーン・ノードから受信し、それに応じて、第１のブロックチェーン・ノードからのドキュメントにアクセスし、ドキュメントの受信の証明を共有ブロックチェーン台帳に提供するように構成される。

さらに別の態様は、プロセッサによって読み取られた場合に、プロセッサに、第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードを含んでいるブロックチェーン・ネットワークを構成することと、第１のブロックチェーン・ノードによって、データ参照を第２のブロックチェーン・ノードに提供することと、第２のブロックチェーン・ノードによって、第１のブロックチェーン・ノードからのドキュメントにアクセスすることと、第２のブロックチェーン・ノードによって、ドキュメントの受信の証明を共有ブロックチェーン台帳に提供することとのうちの１つまたは複数を実行させる命令を含んでいる非一過性コンピュータ可読媒体を提供する。

実施形態例に記載されている、ブロックチェーンを含むドキュメント共有システムのネットワーク図である。 実施形態例に記載されている、ブロックチェーン内の共有台帳のコンテンツのネットワーク図である。 実施形態例に記載されている、例示的なピア・ノード・ブロックチェーン・アーキテクチャの構成を示す図である。 実施形態例に記載されている、例示的なピア・ノード・ブロックチェーン構成を示す図である。 実施形態例に記載されている、許可型ブロックチェーン・ネットワークを示す図である。 実施形態例に記載されている、ブロックチェーン構成を実行するためのシステム・メッセージ図である。 実施形態例に記載されている、ドキュメントの転送を実行するためのシステム・メッセージ図である。 実施形態例に記載されている、ブロックチェーン内でドキュメントの転送を構成して処理する例示的な方法のフロー図である。 実施形態例に記載されている、ブロックチェーンを使用するドキュメント編集プロセスのフロー図である。 実施形態例に記載されている、本明細書において説明されている１つまたは複数の動作に従って、ブロックチェーンに対してさまざまな動作を実行するように構成された例示的な物理的インフラストラクチャを示す図である。 実施形態例に記載されている、ブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された、契約当事者および仲介サーバ間での例示的なスマート・コントラクトの構成を示す図である。 実施形態例のうちの１つまたは複数をサポートするように構成された例示的なコンピュータ・システムを示す図である。

本明細書の図において概略的に説明され、示されているように、本明細書のコンポーネントが、多種多様な異なる構成で配置および設計されてよいということが、容易に理解されるであろう。したがって、添付の図において表された方法、装置、非一過性コンピュータ可読媒体、およびシステムのうちの少なくとも１つの実施形態に関する以下の詳細な説明は、請求されている適用の範囲を制限するよう意図されておらず、単に選択された実施形態を代表している。

本明細書全体を通して説明された特徴、構造、または特性は、１つまたは複数の実施形態において、任意の適切な方法で組み合わせられてよい。例えば、語句「実施形態例」、「一部の実施形態」、またはその他の同様の言葉の使用は、本明細書全体を通じて、実施形態に関連して説明された特定の特徴、構造、または特性が少なくとも１つの実施形態に含まれてよいということを指している。したがって、語句「実施形態例」、「一部の実施形態において」、「その他の実施形態において」、またはその他の同様の言葉の出現は、本明細書全体を通じて、必ずしもすべてが実施形態の同じグループを指しておらず、説明された特徴、構造、または特性は、１つまたは複数の実施形態において、任意の適切な方法で組み合わせられてよい。

加えて、「メッセージ」という用語が実施形態の説明において使用されていることがあるが、本出願は、パケット、フレーム、データグラムなどの多くの種類のネットワーク・データに適用されてよい。「メッセージ」という用語は、パケット、フレーム、データグラム、および任意のこれらと同等のものも含む。さらに、特定の種類のメッセージおよび信号伝達が実施形態例において示されることがあるが、それらは特定の種類のメッセージに限定されず、本出願は特定の種類の信号伝達に限定されない。実施形態例は、ブロックチェーンのための生体測定脅威インテリジェンス処理（biometric threat intelligence processing）を実現する方法、デバイス、ネットワーク、またはシステム、あるいはその組み合わせを提供する。

ブロックチェーンは、互いに通信する複数のノードを含んでいる分散システムである。ブロックチェーンは、チェーンコード（例えば、スマート・コントラクトなど）と呼ばれるプログラムを操作し、状態および台帳のデータを保持し、トランザクションを実行する。一部のトランザクションは、チェーンコード上で呼び出される動作である。一般に、ブロックチェーン・トランザクションは、特定のブロックチェーン・メンバーによって「承認（endorsed）」されなければならず、承認されたトランザクションのみが、ブロックチェーンにコミットされてよく、ブロックチェーンの状態に影響を与える。承認されていない他のトランザクションは、無視される。管理機能およびパラメータのための１つまたは複数の特殊なチェーンコードが存在することがあり、それらは、システム・チェーンコードと総称される。

ノードは、ブロックチェーン・システムの通信エンティティである。「ノード」は、異なる種類の複数のノードが同じ物理サーバ上で実行され得るという意味で、論理機能を実行してよい。ノードは、信頼できるドメイン内でグループ化され、さまざまな方法でそれらのノードを制御する論理エンティティに関連付けられる。ノードは、トランザクション呼び出しをエンドーサ（例えば、ピア）にサブミットし、トランザクション提案を順序付けサービス（例えば、順序付けノード）にブローキャストするクライアントまたはサブミット・クライアント・ノードなどの、さまざまな種類を含んでよい。別の種類のノードは、クライアントがサブミットしたトランザクションを受信し、トランザクションをコミットし、ブロックチェーン・トランザクションの台帳の状態およびコピーを維持することができるピア・ノードである。ピアはエンドーサの役割を持つこともできるが、これは必須要件ではない。順序付けサービス・ノードまたはオーダラは、すべてのノードのための通信サービスを実行するノードであり、トランザクションをコミットし、ブロックチェーンのワールドステートを変更するときに、システム内のピア・ノードの各々へのブロードキャストなどの、配信保証を実施し、それは、通常は制御情報および設定情報を含んでいる初期ブロックチェーン・トランザクションの別の名前である。

台帳は、ブロックチェーンのすべての状態遷移の順序付けられた不正使用防止機能付きレコードである。状態遷移は、参加している関係者（例えば、クライアント・ノード、順序付けノード、エンドーサ・ノード、ピア・ノードなど）によってサブミットされたチェーンコード呼び出し（すなわち、トランザクション）から生じてよい。トランザクションは、１つまたは複数のオペランド（作成、更新、削除など）として台帳にコミットされているアセットのキーと値のペアのセットをもたらしてよい。台帳は、変更不可能な順序付けられたレコードをブロックに格納するために使用されるブロックチェーン（チェーンとも呼ばれる）を含む。台帳は、ブロックチェーンの現在の状態を維持する状態データベースも含む。通常は、１つのチャネルにつき１つの台帳が存在する。各ピア・ノードは、それらのピア・ノードがメンバーになっているチャネルごとに、台帳のコピーを維持する。

チェーンは、ハッシュ・リンク・ブロックとして構造化されたトランザクション・ログであり、各ブロックはＮ個のトランザクションのシーケンスを含んでおり、Ｎは１以上である。ブロック・ヘッダは、ブロックのトランザクションのハッシュ、および前のブロックのヘッダのハッシュを含んでいる。このようにして、台帳のすべてのトランザクションが順序付けられ、暗号によって互いにリンクされてよい。したがって、ハッシュ・リンクを壊さずに台帳データを改ざんすることはできない。直前に追加されたブロックチェーンのブロックのハッシュは、それ以前に発生したチェーン上のすべてのトランザクションを表し、すべてのピア・ノードが一貫性のある信頼できる状態にあることを保証できるようにする。チェーンは、ブロックチェーンのワークロードの追記のみの性質を効率的にサポートするピア・ノードのファイル・システム（すなわち、ローカル、取り付けられたストレージ、クラウドなど）に格納されてよい。

変更不可能な台帳の現在の状態は、チェーンのトランザクション・ログに含まれているすべてのキーの最新の値を表す。現在の状態は、チャネルに知られている最新のキーの値を表すため、世界状態と呼ばれることもある。チェーンコード呼び出しは、台帳の現在の状態のデータに対してトランザクションを実行する。それらのチェーンコードの相互作用を効率的にするために、最新のキーの値が状態データベースに格納されてよい。状態データベースは、単にチェーンのトランザクション・ログへのインデックス付きビューであってよく、したがって、いつでもチェーンから再生成され得る。状態データベースは、ピア・ノードの起動時に、トランザクションが受け取られる前に、自動的に回復されてよい（または必要な場合に生成されてよい）。

ビジネス・データを交換するビジネス・パートナーに関し、１つのパートナーが、そのビジネス・パートナーとの間でデータを送信および受信できるゲートウェイを構成することが、一般に必要とされる。従来、ベスト・プラクティスは、トランスポート・レベルの要件およびセキュリティ・レベルの要件などの、商取引パートナー間の交換の詳細を定義する交換プロファイルを（例えば、Ｂ２Ｂ ＣＰＡ仕様に基づいて）設定ことである。しかし、このプロセスは、交換の詳細を定義するために、複数の関係者による手動のプロセスを伴うため、通常、かなりの労力を必要とする。また、これらのゲートウェイが、通常は保護されたネットワーク内に位置し、組織のファイアウォールが、構成の目的でインターネットからゲートウェイを接続することを非常に困難にするため、接続性が別の大きな問題になることがある。これらの問題を解決するには、ビジネス・パートナー間のスマート・コントラクトでドキュメントの転送を管理できるように、仮想的に接続されたビジネス・ネットワークを設定するメカニズムが必要になる。

図１は、実施形態例に従って、ブロックチェーン内のドキュメント共有システムの論理ネットワーク図を示している。図１を参照すると、ネットワーク１００が、ブロックチェーン・ノード１０４を含むブロックチェーン・ネットワーク１１２を含んでいる。ブロックチェーン・ノード１０４は、任意の種類のドキュメント１３６を共有することを望んでいるさまざまな組織を表している。ブロックチェーン・ネットワーク１１２への参加者が明確に定義された組織であることから、ブロックチェーン・ネットワーク１１２は、通常、許可型ブロックチェーンである。しかし、パブリック・ブロックチェーン（例えば、イーサリアム）も、適切に変更されて、この目的に使用され得る。ブロックチェーン・ノード１０４のいずれかは、他のブロックチェーン・ノード１０４とドキュメントを共有する発信ノード１０４であってよい。任意の数のブロックチェーン・ノード１０４がブロックチェーン・ネットワーク１１２に含まれてよく、３つのブロックチェーン・ノード１０４Ａ、１０４Ｂ、および１０４Ｎが示されている。ブロックチェーン技術は、ビジネス・パートナーまたはノード１０４間の仮想ネットワークを確立し、そこで、逆トンネル技術がパートナーによるブロックチェーン・インフラストラクチャのセットアップを可能にする。

ブロックチェーン・ノード１０４の各々にはゲートウェイ１１６が関連付けられており、それらのゲートウェイは、ブロックチェーン・ノード１０４Ａに関連付けられたゲートウェイ１１６Ａ、ブロックチェーン・ノード１０４Ｂに関連付けられたゲートウェイ１１６Ｂ、ブロックチェーン・ノード１０４Ｎに関連付けられたゲートウェイ１１６Ｎとして示されている。ゲートウェイ１１６は、それぞれ、通信パラメータ（例えば、暗号化、認証情報、およびポート）を含んでいる構成を含む。手動のプロセス（例えば、Ｂ２Ｂ ＣＰＡプロファイル）を使用してゲートウェイ構成を交換するための既存の慣行である、このプロセスを自動化するための主要な課題は、ゲートウェイ１１６が通常、他のシステムがゲートウェイにアクセスして構成するのを防ぐ分離されたネットワーク内に位置することである。ＣＰＡファイルは、２つのパートナーが協力し、Ｂ２Ｂドキュメントを交換するために必要な、有効かつ可視の実施可能な対話を列挙するＸＭＬドキュメントである。ＣＰＡファイルは、通信プロトコル、信頼できるメッセージング・プロセス情報、要求および応答のセキュリティ、メッセージ伝達、ならびにドキュメント・エンベロープの詳細を含む。

ブロックチェーンは、パートナーが認証情報を交換し、通信用の仮想プライベート・ネットワーク（ＶＰＮ：virtual private network）を設定するためのインフラストラクチャを提供するが、ブロックチェーン・ネットワークをビジネス間（Ｂ２Ｂ：business-to-business）の使用事例に使用することの別の課題は、パートナーが、多くの場合、重要なデータまたはドキュメントをブロックチェーン内の組織の外部に配置することを好まないということである。現在、一般的な方法は、機密データまたは機密ドキュメントを（ポインタ、ＵＲＬ、およびドキュメントの有効性を証明するために含まれるハッシュと共に）別のデータ・ストア内に置くことである。

ブロックチェーン・ネットワーク１１２は、１つまたは複数のクラウド・ブローカ１２０を含んでおり、クラウド・ブローカ１２０は、ルート・ノード１２８と、ブロックチェーン・ノード１０４の各々が署名するスマート・コントラクト１２４とを含んでいる。スマート・コントラクト１２４は、ルート・ノード１２８のＩＰアドレスまたはポート識別子あるいはその両方と、ドキュメント１３６を転送することを望んでいるビジネス・パートナー／ブロックチェーン・ノード１０４の各々の認証情報のセットとを含む。スマート・コントラクト１２４内の通信の合意は、クラウド・ブローカ１２０上で作成され、各ゲートウェイ１１６にインポートされてよい。スマート・コントラクト１２４内の通信の合意に基づいて、制限された範囲（例えば、署名された通信の合意またはスマート・コントラクト１２４を有するパートナー１０４のみが参加できる）で、各パートナーがブロックチェーン・ネットワーク１１２に参加し得る。

ドキュメント１３６は、ブロックチェーン・ノード１０４間のブロックチェーン・トランザクション１３２の外部で転送される。１つまたは複数のドキュメント１３６または構成を共有する準備ができたときに、発信ノード１０４がデータのデータ参照（例えば、ＵＲＬ）をブロックチェーン・ネットワーク１１２に送信する。その後、スマート・コントラクト１２４に署名した参加ノード１０４は、データ参照を介してドキュメント１３６にアクセスし、それらの認証情報を使用して、参加ノード１０４自身のネットワーク・ストレージにコピーを取得することができる。参加ノード１０４は、ドキュメントのハッシュ１５０、ソルト１５４、およびそれら自身の識別子１５８を結合してレシート１４４を形成し、レシート１４４に署名し、ブロックチェーン・トランザクション１３２を作成することによって、参加ノード１０４がドキュメント１３６を受信したことの証明を提供する。この証明の提供は、参加ノード１０４がドキュメント１３６にアクセスし、ドキュメント１３６をハッシュした場合にのみ実行されてよい。

ソルトは、データ、パスワード、またはパスフレーズを「ハッシュする」一方向性関数への追加入力として使用されるランダムなデータである。ソルトは、ノンスの概念に密接に関連している。ソルトの主要な機能は、辞書攻撃に対して、またはそのハッシュされた同等のもの、事前に計算されたレインボー・テーブル攻撃に対して防御することである。ソルトは、ストレージ内のパスワードを保護するために使用されることがある。歴史的に、パスワードは、平文でシステムに格納されることがあったが、時間がたつにつれて、システムから読み取られることに対してユーザのパスワードを保護するために、追加の予防手段が開発された。ソルトは、そのような手段のうちの１つである。

ブロックチェーン・ノード１０４間でドキュメント１３６を転送することに応答して、ドキュメント１３６を受信するブロックチェーン・ノード１０４によって、ブロックチェーン・トランザクション１３２が生成される。ブロックチェーン・トランザクション１３２は、図２および図７を参照して説明されているように、レシートを、各ブロックチェーン・ノード１０４に関連付けられている分散された共有台帳１０８に格納する。本出願は、有利なことに、各パートナーが重要なデータおよびドキュメントをオンプレミスに維持することを可能にしながら、ピア間またはパートナー間の保護されたドキュメントの転送を可能にする。要約すると、本出願は、クラウド・ブローカ１２０を活用することによって、ビジネス・パートナーが通信ネットワークを確立するためのメカニズムを提供する。ネットワーク１１２が確立された後に、パートナーは、ゲートウェイ１１６の構成およびビジネス・ドキュメント１３６の両方を、ブロックチェーン・ネットワーク１１２内に格納された否認不可なレコードと共に、交換できる。パートナーは、データ参照を他のパートナーに送信することによって、ドキュメント１３６をオンプレミスに維持してよく、データ参照を有するパートナーは、ドキュメント１３６を取り出すべきかどうかを判断することができるが、これらのパートナーのアクセス・レコードがブロックチェーン内で維持される。

図２は、実施形態例に従って、ブロックチェーン内の共有台帳１０８のコンテンツの図を示している。図２を参照すると、共有台帳１０８は、レシート内容１４４を含んでいる。ドキュメント１３６を受信する各ブロックチェーン・ノード１０４は、図７に関してさらに詳細に説明されているように、レシート１４４を作成し、レシート内容１４４をブロックチェーンに格納するためのブロックチェーン・トランザクションを生成する。ブロックチェーンが、受信されたすべてのドキュメント１３６のレシート１４４を含んでいるため、ブロックチェーン上には、共有台帳１０８に格納されたレシート１４４のグループが存在し、このグループは、図２ではレシート１４４Ａ～レシート１４４Ｎとして識別される。

レシート内容１４４はそれぞれ、ドキュメントのハッシュ１５０、ソルト１５４、および受信ノード識別子１５８のうちの１つまたは複数を含んでいる。レシート１４４Ａ～１４４Ｎに対応するＮ個のレシート１４４に関して、ドキュメントの対応するハッシュ１５０Ａ～１５０Ｎ、ソルト１５４Ａ～１５４Ｎ、および受信ノード識別子１５８Ａ～１５８Ｎがそれぞれ存在する。ハッシュは、任意のサイズのデータを固定サイズのデータにマッピングするために使用できる関数である。したがって、ドキュメントのハッシュ１５０は、ハッシュされたドキュメントを固定サイズに縮小する。ソルト１５４は、データを「ハッシュする」一方向性関数への追加入力として使用されるランダムなデータである。受信ノード識別子１５８は、受信ノード１０４を一意に識別する任意の英数字またはその他の種類の文字列である。

場合によっては、参加ノード１０４は、レシート１４４を作成してブロックチェーンにサブミットしないことによって、不正なドキュメント１３６を受信するリスクを受け入れることを選択してよい。しかし、不正なドキュメント１３６を受信することには、ビジネス・コストまたはその他の逆効果があることがある。参加ノード１０４が、ドキュメント１３６にアクセスしたことを否定する場合、参加ノード１０４がアクセスしたことの（共有台帳１０８に格納されているレシート１４４を介した）証明が存在する。

図３は、実施形態例に従って、ブロックチェーン・アーキテクチャの構成２００を示している。図３を参照すると、ブロックチェーン・アーキテクチャ２００は、特定のブロックチェーン要素、例えば、ブロックチェーン・ノードのグループ２０２を含んでよい。ブロックチェーン・ノード２０２は、１つまたは複数のノード２０４～２１０を含んでよい（単に例として、４つのノードが示されている）。これらのノードは、ブロックチェーン・トランザクションの追加および検証プロセス（合意）などの、複数の活動に参加する。ブロックチェーン・ノード２０４～２１０のうちの１つまたは複数は、トランザクションを承認してよく、アーキテクチャ２００内のすべてのブロックチェーン・ノードのための順序付けサービスを提供してよい。ブロックチェーン・ノードは、ブロックチェーン認証を開始し、ブロックチェーン層２１６に格納されたブロックチェーンの変更不可能な台帳に書き込もうとしてよく、この書き込みのコピーが、基盤になる物理的インフラストラクチャ２１４にも格納されてよい。ブロックチェーンの構成は、格納されたプログラム／アプリケーション・コード２２０（例えば、チェーンコード、スマート・コントラクトなど）にアクセスして実行するためにアプリケーション・プログラミング・インターフェイス（ＡＰＩ：application programming interfaces）２２２にリンクされた１つまたは複数のアプリケーション２２４を含んでよく、プログラム／アプリケーション・コード２２０は、参加者によって要求されてカスタマイズされた構成に従って作成することができ、それら自身の状態を維持し、それら自身のアセットを制御し、外部の情報を受信することができる。これは、トランザクションとしてデプロイし、分散型台帳に追加することによって、すべてのブロックチェーン・ノード２０４～２１０にインストールすることができる。

ブロックチェーン・ベースまたはプラットフォーム２１２は、ブロックチェーンのデータ、サービス（例えば、暗号信用サービス、仮想実行環境など）および基盤になる物理的コンピュータ・インフラストラクチャの種々の層を含み、これらは、新しいトランザクションを受信して格納し、データ・エントリにアクセスしようとしている監査人にアクセスを提供するために使用されて得る。ブロックチェーン層２１６は、プログラム・コードを処理し、物理的インフラストラクチャ２１４に参加させるために必要な仮想実行環境へのアクセスを提供するインターフェイスを公開してよい。暗号信用サービス２１８は、アセット交換トランザクションなどのトランザクションを検証し、情報をプライベートに保つために使用されてよい。

図３のブロックチェーン・アーキテクチャの構成は、ブロックチェーン・プラットフォーム２１２によって公開された１つまたは複数のインターフェイスおよび提供されたサービスを介して、プログラム／アプリケーション・コード２２０を処理および実行してよい。コード２２０は、ブロックチェーンのアセットを制御してよい。例えば、コード２２０は、データを格納および転送することができ、スマート・コントラクトおよび条件または実行の対象になるその他のコード要素に関連付けられたチェーンコードの形態で、ノード２０４～２１０によって実行されてよい。非限定的な例として、リマインダ、更新、または変更、更新の対象になるその他の通知、あるいはその組み合わせなどを実行するために、スマート・コントラクトが作成されてよい。スマート・コントラクト自体は、権限付与およびアクセスの要件ならびに台帳の使用に関連付けられたルールを識別するために使用され得る。例えば、レシート内容２２６は、異なるブロックチェーン・ノード２０２からドキュメント１３６を受信したブロックチェーン・ノード２０２から受信されてよく、ブロックチェーン層２１６に含まれている１つまたは複数の処理エンティティ（例えば、仮想マシン）によって処理されてよい。レシート２２８は、共有台帳１０８にそれぞれ記録され、図２に関してさらに詳細に説明されているレシートの内容２２６を含んでよい。物理的インフラストラクチャ２１４は、本明細書に記載されたデータまたは情報のいずれかを取り出すために利用されてよい。

チェーンコード内で、高水準のアプリケーションおよびプログラミング言語を使用して、スマート・コントラクトが作成され、その後、ブロックチェーン内のブロックに書き込まれてよい。スマート・コントラクトは、実行可能コードを含んでよく、実行可能コードは、ブロックチェーン（例えば、ブロックチェーン・ピアの分散ネットワーク）へ登録、格納、または複製、あるいはその組み合わせがなされる。トランザクションは、スマート・コントラクトに関連付けられた条件が満たされたことに応答して実行され得る、スマート・コントラクト・コードの実行である。スマート・コントラクトの実行は、デジタル・ブロックチェーン台帳の状態に対する信頼できる変更をトリガーしてよい。スマート・コントラクトの実行によって引き起こされるブロックチェーン台帳に対する変更は、１つまたは複数の合意プロトコルを介して、ブロックチェーン・ピアの分散ネットワーク全体に自動的に複製されてよい。

スマート・コントラクトは、データをキーと値のペアの形式でブロックチェーンに書き込んでよい。さらに、スマート・コントラクト・コードは、ブロックチェーンに格納された値を読み取り、それらをアプリケーションの動作において使用することができる。スマート・コントラクト・コードは、さまざまな論理演算の出力をブロックチェーンに書き込むことができる。このコードは、仮想マシンまたはその他のコンピューティング・プラットフォーム内の一時的データ構造を作成するために使用されてよい。ブロックチェーンに書き込まれたデータは、パブリックになること、またはプライベートとして暗号化されて維持されること、あるいはその両方が行われ得る。スマート・コントラクトによって使用／生成される一時的データは、提供された実行環境によってメモリ内に保持され、ブロックチェーンに必要なデータが識別された後に削除される。

チェーンコードは、追加の特徴と共に、スマート・コントラクトのコード解釈を含んでよい。本明細書に記載されているように、チェーンコードは、コンピューティング・ネットワーク上にデプロイされるプログラム・コードであってよく、ここで、合意プロセス中に、チェーン・バリデータによって一緒に実行されて検証される。チェーンコードは、ハッシュを受信し、以前に格納された特徴抽出器の使用によって作成されたデータ・テンプレートに関連付けられたハッシュをブロックチェーンから取り出す。ハッシュ識別子のハッシュと、格納された識別子テンプレート・データから作成されたハッシュが一致する場合、チェーンコードは、権限付与（authorization）キーを、要求されたサービスに送信する。チェーンコードは、暗号の詳細に関連付けられたデータをブロックチェーンに書き込んでよい。図３では、ブロックチェーン・ノード２０２が、ドキュメントのハッシュ１５０、ソルト１５４、および受信ノード識別子１５８を含んでいるレシート内容２２６を受信する。１つの機能は、ブロックチェーン・トランザクションとしてレシートを作成してサブミットすることであってよく、このレシートは、ノード２０４～２１０のうちの１つまたは複数に提供されてよい。

図４は、一実施形態例に従って、ブロックチェーンのノード間のトランザクション・フロー２５０の例を示している。図４を参照すると、トランザクション・フローは、アプリケーション・クライアント・ノード２６０によって署名ピア・ノード２８１に送信されるトランザクション提案２９１を含んでよい。承認ピア２８１は、クライアントの署名を検証し、チェーンコード関数を実行してトランザクションを開始してよい。出力は、チェーンコードの結果、チェーンコードに読み取られたキー／値のバージョンのセット（読み取られたセット）、およびチェーンコードに書き込まれたキー／値のセット（書き込まれたセット）を含んでよい。認可されている場合は、提案応答２９２が承認サイン（endorsement signature）と共にクライアント２６０に返送される。クライアント２６０は、承認をトランザクションのペイロード２９３にまとめて、順序付けサービス・ノード２８４にブロードキャストする。その後、順序付けサービス・ノード２８４は、順序付けられたトランザクションをチャネル上でブロックとしてすべてのピア２８１～２８３に配信する。ブロックチェーンへのコミットの前に、各ピア２８１～２８３がトランザクションを検証してよい。例えば、ピアは、承認ポリシーをチェックして、指定されたピアの正しい割り当てが結果に署名し、トランザクションのペイロード２９３に対する署名を認証したことを保証する。

再び図４を参照すると、クライアント・ノード２６０が、要求を構築してピア・ノード２８１（エンドーサ）に送信することによって、トランザクション２９１を開始する。クライアント・ノード２６０は、ＮＯＤＥ、ＪＡＶＡ（登録商標）、ＰＹＴＨＯＮなどのサポートされているソフトウェア開発キット（ＳＤＫ：software development kit）を利用するアプリケーションを含んでよく、このアプリケーションは、使用可能なＡＰＩを利用してトランザクション提案を生成する。提案は、データが台帳から読み取られること、または台帳に書き込まれること（すなわち、アセットの新しいキーと値のペアを書き込むこと）、あるいはその両方を実行できるように、チェーンコード関数を呼び出すことの要求である。ＳＤＫは、トランザクション提案を、適切に設計された形式（例えば、リモート・プロシージャ・コール（ＲＰＣ：remote procedure call）を経由するプロトコル・バッファ）にパッケージ化するためのシムとして機能し、クライアントの暗号認証情報を受け取って、トランザクション提案の一意の署名を生成してよい。

それに応じて、承認ピア・ノード２８１は、（ａ）トランザクション提案が適切に形成されていること、（ｂ）トランザクションが過去にすでにサブミットされていないこと（リプレイアタック保護）、（ｃ）署名が有効であること、および（ｄ）そのチャネルに対する提案された操作を実行するための適切な権限がサブミッタ（例では、クライアント２６０）に与えられていることを検証してよい。承認ピア・ノード２８１は、トランザクション提案の入力を、呼び出されるチェーンコード関数への引数として受け取ってよい。その後、チェーンコードが、現在の状態データベースに対して実行され、応答値、読み取りセット、および書き込みセットを含んでいるトランザクション結果を生成する。ただしこの時点では、台帳に対する更新は行われない。２９２で、値のセットが、承認ピア・ノード２８１の署名と共に、提案応答２９２としてクライアント２６０のＳＤＫに返され、このＳＤＫが、アプリケーションが使用するためのペイロードを構文解析する。

それに応じて、クライアント２６０のアプリケーションが、承認ピアの署名を検査／検証し、提案応答を比較して、提案応答が同じであるかどうかを判定する。チェーンコードが単に台帳に問い合わせた場合、アプリケーションは問い合わせ応答を検査し、通常は、トランザクションを順序付けノード・サービス２８４にサブミットしない。クライアント・アプリケーションが、台帳を更新するためにトランザクションを順序付けノード・サービス２８４にサブミットしようとしている場合、アプリケーションは、サブミットする前に、指定された承認ポリシーが満たされているかどうか（すなわち、トランザクションに必要なすべてのピア・ノードがトランザクションを承認したかどうか）を判定する。ここで、クライアントは、トランザクションの複数の関係者のうちの１つのみを含んでよい。この場合、各クライアントは、それ自身の承認ノードを含んでよく、各承認ノードがトランザクションを承認する必要がある。アーキテクチャは、アプリケーションが応答を検査しないことを選択するか、あるいは承認されていないトランザクションを転送する場合でも、承認ポリシーが、ピアによってまだ実施され、コミット検証フェーズで維持されるようにする。

検査に成功した後に、ステップ２９３で、クライアント２６０が、承認をトランザクションにまとめ、順序付けノード２８４へのトランザクション・メッセージ内でトランザクション提案およびトランザクション応答をブロードキャストする。トランザクションは、読み取り／書き込みセット、承認ピアの署名、およびチャネルＩＤを含んでよい。順序付けノード２８４は、その動作を実行するために、トランザクションの内容全体を検査する必要はなく、代わりに順序付けノード２８４は、単に、トランザクションをネットワーク内のすべてのチャネルから受信して、チャネル別に経時的に順序付けし、チャネルごとにトランザクションのブロックを作成してよい。

トランザクションのブロックは、順序付けノード２８４から、チャネル上のすべてのピア・ノード２８１～２８３に配信される。いずれかの承認ポリシーが満たされていることを保証するため、および、読み取りセットがトランザクションの実行によって生成されて以来、読み取りセットの変数に関して台帳の状態に対する変更がないことを保証するために、ブロック内のトランザクション２９４が検証される。ブロック内のトランザクションは、有効または無効であるとしてタグ付けされる。さらに、ステップ２９５で、各ピア・ノード２８１～２８３は、ブロックをチャネルのチェーンに追記し、有効なトランザクションごとに、書き込みセットが現在の状態データベースにコミットされる。トランザクション（呼び出し）が変更不可能なようにチェーンに追記されたことをクライアント・アプリケーションに通知するため、およびトランザクションが検証されたか、または無効にされたかを通知するために、イベントが発行される。

図５は、許可型ブロックチェーン・ネットワーク３００の例を示しており、許可型ブロックチェーン・ネットワーク３００は、分散型の非集中的ピアツーピア・アーキテクチャ、ならびにユーザの役割および権限を管理する認証局３１８を特徴とする。この例では、ブロックチェーン・ユーザ３０２は、トランザクションを許可型ブロックチェーン・ネットワーク３１０にサブミットしてよい。この例では、トランザクションは、デプロイ、呼び出し、または問い合わせであることができ、ＳＤＫを利用するクライアント側のアプリケーションを介して、ＲＥＳＴ ＡＰＩを介して直接的に、または同様の方法によって、発行されてよい。信頼できるビジネス・ネットワークは、監査人（例えば、米国の株式市場における証券取引委員会）などの規制者システム３１４にアクセスを提供してよい。一方、ノード３０８のブロックチェーン・ネットワーク運用者システムは、規制者システム３１０を「監査人」として登録し、ブロックチェーン・ユーザ３０２を「クライアント」として登録するなどの、メンバーの権限を管理する。監査人を、台帳への問い合わせのみに制限することができ、一方、クライアントに、特定の種類のチェーンコードのデプロイ、呼び出し、および問い合わせを行うための権限を与えることができる。

ブロックチェーン開発者システム３１６は、チェーンコードおよびクライアント側のアプリケーションを書く。ブロックチェーン開発者システム３１６は、ＲＥＳＴインターフェイスを介して、チェーンコードをネットワークに直接デプロイすることができる。従来のデータ・ソース３３０からの認証情報をチェーンコードに含めるために、開発者システム３１６は、アウトオブバンド接続を使用してデータにアクセスすることができる。この例では、ブロックチェーン・ユーザ３０２は、ピア・ノード３１２を介してネットワークに接続する。ピア・ノード３１２は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクション証明書を認証局３１８から取得する。場合によっては、ブロックチェーン・ユーザは、許可型ブロックチェーン・ネットワーク３１０上でトランザクションを実行するために、それらのデジタル証明書を有していなければならない。一方、チェーンコードを動作させようとしているユーザは、従来のデータ・ソース３３０上のそれらのユーザの認証情報を検証することが必要になることがある。ユーザの権限付与を確認するために、チェーンコードは、従来の処理プラットフォーム３２０を介して、このデータへのアウトオブバンド接続を使用することができる。

図６は、実施形態例に従ってブロックチェーン構成を実行するためのシステム・メッセージ図を示している。図６を参照すると、システム図４００は、発信ノード４０１、１つまたは複数の参加ノード４０２Ａ、４０２Ｂ、およびクラウド・ブローカ４０３を含んでいる。発信ノード４０１の各々および参加ノード４０２Ａ、４０２Ｂの各々は、安全なドキュメントの転送に参加することを望んでいる組織である。ブロックチェーン・ネットワーク構成の観点から見ると、発信ノード４０１は、参加ノード４０２Ａ、４０２Ｂのいずれかと同等である。

構成プロセス４００は、発信ノード４０１および参加ノード４０２Ａ、４０２Ｂの各々が定義されたとき（図示されていない）に開始する。ノード４０１、４０２の各々を定義できる多くの方法が存在しており、そのような定義は状況に応じて異なる。ノード４０１、４０２の各々が定義された後に、各ノード４０１、４０２が構成パラメータ４１０を定義する。構成パラメータ４１０は、クラウド・ブローカ４０３にログインするために使用される、ＵＲＬ、ユーザ名、およびパスワードなどの、登録パラメータおよびログイン・パラメータを含む。ノード４０１、４０２の各々は、構成パラメータ４１１をクラウド・ブローカ４０３に転送する。ブロックチェーン・ネットワーク１１２の作成を開始している発信ノード４０１は、契約要求４１２をクラウド・ブローカ４０３に送信する。クラウド・ブローカ４０３は、契約要求４１２を受信することに応答して、スマート・コントラクト４１５を作成する。ブロックチェーン・ネットワーク１１２に含まれるすべてのノード４０１、４０２は、スマート・コントラクト４１５に署名するよう要求される。

クラウド・ブローカ４０３は、スマート・コントラクト４１５を作成した後に、スマート・コントラクト４１６をブロックチェーン・ノード４０１、４０２の各々に送信する。ブロックチェーン・ノード４０１、４０２は、スマート・コントラクト４１５を受信し、各ノード４０１、４０２に関連付けられた秘密キーを使用してスマート・コントラクト４２０に署名する。スマート・コントラクト４１５の内容が、ゲートウェイ１１６の各々によって構文解析され、インポートされる。例えば、各ノードの異なるパートナーの表現として作成された、複数の仮想ゲートウェイが存在する。言い換えると、ノードＡが２つのパートナーを含んでいる場合、それらのパートナーの各々を表すために作成された２つの仮想ゲートウェイが存在する。このメカニズムが、すべてのパートナー（すなわち、パートナーＡ、パートナーＢ、パートナーＣなど）に適用される。

最後に、ノード４０１、４０２の各々が、署名されたスマート・コントラクト４２１をクラウド・ブローカ４０３に返す。この時点で、ブロックチェーン・ネットワーク１１２が構成されており、ドキュメントの転送が開始してよい。

図７は、実施形態例に従ってドキュメントの転送を実行するためのシステム・メッセージ図を示している。図７を参照すると、システム図４５０は、発信ノード４０１、１つまたは複数の参加ノード４０２、およびブロックチェーン・ネットワーク４５１を含んでいる。ブロックチェーン・ネットワーク４５１が確立された後に、任意のノード４０１、４０２が、ドキュメントを他のブロックチェーン・ノード４０１、４０２と共有してよい。システム４５０は、異なる参加ノード４０２とドキュメントを共有している発信ノード４０１を示している。

ドキュメント共有プロセス４５０は、発信ノード４０１が共有する１つまたは複数のドキュメントを識別したとき（４６０）に、開始する。ドキュメントは、ゲートウェイ１１６の背後の、ノード１０４のネットワーク・インフラストラクチャ内、おそらく、ノード１０４のネットワーク化された部分のデータベース内に格納される。次に、発信ノード４０１は、データ参照４６１を、発信ノード４０１がドキュメント４６０を共有することを望んでいる１つまたは複数の参加ノード４０２に提供する。データ参照４６１は、通常、１つまたは複数のドキュメントが格納されている発信ノード４０１内の位置を指し示すＵＲＬである。１つまたは複数の参加ノード４０２は、データ参照４６１を受信した後に、データ参照４６１を使用して、発信ノード４０１のデータベースから識別されたドキュメントを取得する（４６５）。ドキュメント４６６は、ブロックチェーン・トランザクション１３２として処理されず、図１を参照して説明されているように、ブロックチェーン・ネットワーク１１２、４５１の外部に転送される。ドキュメント４６６をデータベースから取得するために、逆トンネル接続が使用される。

参加ノード４０２がドキュメント４６６を受信した後に、各参加ノード４０２がレシート４７０を作成する。レシート４７０は、受信されたドキュメント４６６のハッシュ、ソルト、およびドキュメント４６６を受信した参加ノード４０２の識別子を含んでいる。次に、各参加ノード４０２は、レシート４７０を含んでいるブロックチェーン・トランザクション４７１を開始する。ブロックチェーン・ネットワーク４５１は、トランザクション４７１を検証し、各レシート４７０をブロックチェーン４７５に格納する。具体的には、レシート４７０は、ドキュメントの転送の変更不可能なレコードがブロックチェーン上で維持されるように、共有台帳１０８の一部になる。

図８は、実施形態例に従ってブロックチェーン内でドキュメントの転送を構成して処理する例示的な方法のフロー図５００を示している。図８を参照すると、方法５００は、ブロックチェーン・ネットワークを構成すること（５０４）を含んでよい。ブロックチェーン・ネットワークを構成する（５０４）ための構成ステップが示されており、図６に関してさらに詳細に説明されている。次に、ブロックチェーン・ノード１０４の各々によって、スマート・コントラクトが署名される（５０８）。次に、１つまたは複数のドキュメント１３６、４６６を共有することを望んでいるブロックチェーン・ノード１０４（すなわち、発信ノード４０１）が、データ参照５１２を他のブロックチェーン・ノード４０２に提供する。他のブロックチェーン・ノード４０２は、データ参照５１２を使用して、発信ノード４０１からの１つまたは複数のドキュメント５１６にアクセスする。最後に、ドキュメント５１６にアクセスするブロックチェーン・ノード４０２の各々が、レシート５２０の証明をブロックチェーン・トランザクション１３２、４７１として提供する。

図９は、実施形態例に従ってブロックチェーンを使用するドキュメント編集プロセスの例示的な方法のフロー図５５０を示している。この方法は、ドキュメントのリリースについてのジョブの詳細を示すユーザ入力を受信し、受信されたユーザ入力を格納する、サブミッタ・システムを含んでよい。このジョブの詳細は、リリース時間、意図される受信者、編集者、または是認者（approver）、あるいはその組み合わせなどを設定することを含んでよい。サブミッタ・システムは、ジョブの詳細をシステムに送信し（またはさもなくば提供し）、ドキュメントをシステム５５４に送信する（さもなくば提供する）。

一度システム５５４によってドキュメントが受信されたあとは、このドキュメントが、通常、暗号化される。ステップ５５８で、暗号化されたドキュメントまたはそのハッシュを含んでいるブロックチェーン・トランザクションが作成され、次に、このトランザクションがブロックチェーンにサブミットされる。

このトランザクションは、ブロックチェーンで受信された後に、ブロックチェーン５６２に格納される。一部の実施形態では、このトランザクションは、サブミッタ「から」１人または複数の編集者「へ」向けられるものである。特定の実施形態では、このトランザクションは、１人または複数の是認者「へ」向けられるものである。編集者が必要である場合、編集者が設定され、その後、この編集者に通知される。特定の例では、ドキュメントがレビューおよび編集される準備ができていることが、電子メールなどを介して編集者に通知される。

ステップ５６６で、編集者が、サブミットされたブロックチェーン・トランザクションに従って格納されたドキュメントにアクセスすることによってドキュメントを編集する。それに応じて、編集者システムによる各編集セッションは、編集されたドキュメントのブロックチェーン・トランザクションの作成を引き起こしてよい。

次に、この新しいブロックチェーン・トランザクションは、ブロックチェーンにサブミットされ、ここで、ブロックチェーン内に格納される（５７０）。ジョブの性質に応じて、作成されたトランザクションは、編集者から同じ編集者に戻るものであってよく（例えば、さらに編集が必要とされる場合）、編集者から別の編集者に向けられるものであってよく、または編集者から１人または複数の是認者に向けられるものであってよい。異なる編集者が、同じ編集者システムまたは異なる編集者システム（例えば、異なるコンピュータ・システム）を使用してよい。編集後に、システムが、ドキュメントが編集されなくなっていることを（例えば、設定されたジョブの詳細に従って）決定し、その後、ドキュメントを完成（finalizing）させてよい。ドキュメントを完成させることによって、システムによる別のブロックチェーン・トランザクションの作成およびブロックチェーンへのサブミットを引き起こしてよい。それに応じて、（例えば、暗号によって検証されることによって）完成されたドキュメントがブロックチェーンに組み込まれてよい。

ドキュメントを完成させた後に、システムは、ドキュメントを受信者に配布するために使用される形式に変換してもよい。変換されたドキュメントは、ブロックチェーンに保存されてもよい。ドキュメントの連続する各ブロックチェーン・トランザクションが、そのドキュメントの前のブロックチェーン・トランザクションを逆向きに参照してよいということが、理解されるであろう（例えば、あるブロックチェーン・トランザクションの使わない「出力」が、次のブロックチェーン・トランザクションの「入力」として使用される）。これによって、初期ドキュメントのサブミットから、受信者へのドキュメントの最終的な配布までの監査証跡の作成および安定性を促進することができる。

いずれにしても、一度ドキュメントが完成されており、配布される形式になると、是認者に通知される。特定の例では、この通知は、是認者システムに配信されるメッセージであってよく、他の例では、この通知は、例えば、是認者に関連付けられた電子メール・アドレスに送信される電子メールであってよい。是認者は、是認者システムを介して、是認するか、拒否して破棄するか、または拒否してさらなる変更を要求してよい。是認者がドキュメントを（例えば、是認者システムから提供される拒否コマンドを使用して）完全に拒否する場合、ブロックチェーン上にある特殊なごみ箱アドレス（trash address）「宛て」の別のブロックチェーン・トランザクションが生成されてよい。ドキュメントが公開キーによって署名されていて、関係者がドキュメントにアクセスできないようになっているため、外部の関係者が（または場合によっては、システムも）ドキュメント（またはドキュメントを含んでいるトランザクション）のロックを解除できないように、このアドレスのキーがシステムによって保持されてよい。その後、このプロセスが繰り返される。

最後に、是認者がドキュメントのリリースを（例えば、是認者システムから提供される是認コマンドを使用して）是認してもよい。是認者は、ドキュメントのリリースを是認するときに、最後のトランザクションに、事実上、（ブロックチェーンの観点から）署名していてもよい。署名後、このトランザクションに関連付けられたすべての他の条件（例えば、時間が決められたリリース）が、満たされるのを待つ。一方、システムは、「最後の」トランザクションに関連付けられたスクリプトがいつ遂行されるかについて、ブロックチェーンを監視する。スクリプトが遂行された場合、システムは、ドキュメントがブロックチェーン上で現在利用可能であるということを受信者に通知（５７４）してよく、または受信者システムは、ブロックチェーンが、最後のブロックチェーン・トランザクションに関連付けられたスクリプトの期限切れを受信者に、事実上、通知するように、ブロックチェーンを直接監視してよく、あるいはその両方であってよい。特定の実施形態例では、システムに、ドキュメントを含む電子メールまたはその他の通信を受信者に送信させることによって、ドキュメントが利用可能にされてよい。それに応じて、最初にアップロードされたドキュメントが保護され、意図される受信者にタイムリーに配信されてよい。

図１０は、実施形態例に記載されている動作の例示的な方法のうちの１つまたは複数に従って、ブロックチェーンに対してさまざまな動作を実行するように構成された例示的な物理的インフラストラクチャを示している。図１０を参照すると、例示的な構成６００は、ブロックチェーン６２０およびスマート・コントラクト６４０を含んでいる物理的インフラストラクチャ６１０を含んでおり、物理的インフラストラクチャ６１０は、実施形態例のいずれかに含まれている動作のステップ６１２のいずれかを実行してよい。ステップ／動作６１２は、１つまたは複数のフロー図または論理図あるいはその両方において説明されたか、または示されたステップのうちの１つまたは複数を含んでよい。これらのステップは、コンピュータ・システムの構成の物理的インフラストラクチャ６１０上に存在する、１つまたは複数のスマート・コントラクト６４０またはブロックチェーン６２０あるいはその両方に書き込まれるか、またはこれらから読み取られるかした、出力または書き込まれた情報を表してよい。実行されたスマート・コントラクト６４０またはブロックチェーン６２０あるいはその両方から、データが出力され得る。物理的インフラストラクチャ６１０は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組み合わせを含んでよい。

図１１は、実施形態例に従って、ブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された、契約当事者および仲介サーバの間での例示的なスマート・コントラクトの構成を示している。図１１を参照すると、構成６５０は、通信セッション、アセット転送セッションまたはプロセスあるいは手順を表してよく、これらは、１つまたは複数のユーザ・デバイス６５２または６５６あるいはその両方を明示的に識別するスマート・コントラクト６４０によって動作させられる。スマート・コントラクトの実行、動作、および実行結果は、サーバ６５４によって管理されてよい。スマート・コントラクト６４０の内容は、スマート・コントラクト・トランザクションの関係者であるエンティティ６５２および６５６のうちの１つまたは複数によるデジタル署名を要求してよい。スマート・コントラクトの実行結果は、ブロックチェーン・トランザクションとしてブロックチェーンに書き込まれてよい。

前述の実施形態は、ハードウェアにおいて、プロセッサによって実行されるコンピュータ・プログラムにおいて、ファームウェアにおいて、またはこれらの組み合わせにおいて実装されてよい。コンピュータ・プログラムは、ストレージ媒体などのコンピュータ可読媒体に具現化されてよい。例えば、コンピュータ・プログラムは、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、フラッシュ・メモリ、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memory）、電子的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：electrically erasable programmable read-only memory）、レジスタ、ハード・ディスク、取り外し可能なディスク、コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disk read-only memory）、または従来技術において知られた任意のその他の形態のストレージ媒体に存在してよい。

例示的なストレージ媒体は、プロセッサがストレージ媒体から情報を読み取り、ストレージ媒体に情報を書き込むことができるように、プロセッサに接続されてよい。代替方法では、ストレージ媒体はプロセッサと一体であってよい。プロセッサおよびストレージ媒体は、特定用途向け集積回路（ＡＳＩＣ：application specific integrated circuit）に存在してよい。代替方法では、プロセッサおよびストレージ媒体は、個別のコンポーネントとして存在してよい。例えば、図１２は、前述したコンポーネントのいずれかなどを表すか、またはそれらに統合されてよい、例示的なコンピュータ・システム・アーキテクチャ７００を示している。

図１２は、本明細書に記載された本出願の実施形態の使用または機能の範囲に関して、いかなる制限を示唆することも意図されていない。いずれにせよ、コンピューティング・ノード７００は、前述した機能のいずれかを実装すること、または実行すること、あるいはその両方を行うことができる。

コンピューティング・ノード７００内には、他の多数の汎用または専用のコンピューティング・システム環境または構成で運用できるコンピュータ・システム／サーバ７０２が存在する。コンピュータ・システム／サーバ７０２での使用に適した既知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などを含むが、これらに限定されない。

コンピュータ・システム／サーバ７０２は、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含んでよい。コンピュータ・システム／サーバ７０２は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実行されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。

図１２に示すように、クラウド・コンピューティング・ノード７００内のコンピュータ・システム／サーバ７０２は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ７０２のコンポーネントは、１つまたは複数のプロセッサまたはプロセッシング・ユニット７０４、システム・メモリ７０６、およびシステム・メモリ７０６を含むさまざまなシステム・コンポーネントをプロセッサ７０４に接続するバスを含んでよいが、これらに限定されない。

バスは、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィックス・ポート、および任意のさまざまなバス・アーキテクチャを使用するプロセッサまたはローカル・バスを含む、任意の複数の種類のバス構造のうちの１つまたは複数を表す。例として、そのようなアーキテクチャは、ＩＳＡ（Industry Standard Architecture）バス、MCA（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカル・バス、およびＰＣＩ（Peripheral Component Interconnects）バスを含むが、これらに限定されない。

コンピュータ・システム／サーバ７０２は、通常、さまざまなコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ７０２によってアクセスできる任意の使用可能な媒体であってよく、揮発性および不揮発性媒体、取り外し可能および取り外し不可の媒体を含む。システム・メモリ７０６は、一実施形態では、他の図のフロー図を実装する。システム・メモリ７０６は、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）７１０またはキャッシュ・メモリ７１２あるいはその両方などの、揮発性メモリの形態でのコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ７０２は、その他の取り外し可能／取り外し不可、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含んでよい。単に例として、取り外し不可、不揮発性の磁気媒体（図示されておらず、通常は「ハード・ドライブ」と呼ばれる）に対する読み取りと書き込みを行うために、ストレージ・システム７１４を提供することができる。図示されていないが、取り外し可能、不揮発性の磁気ディスク（例えば、「フロッピー（登録商標）ディスク」）に対する読み取りと書き込みを行うための磁気ディスク・ドライブ、およびＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、またはその他の光媒体などの取り外し可能、不揮発性の光ディスクに対する読み取りと書き込みを行うための光ディスク・ドライブを提供することができる。そのような例では、それぞれを、１つまたは複数のデータ媒体インターフェイスによってバスに接続することができる。下で詳細に示され、説明されるように、メモリ７０６は、本出願のさまざまな実施形態の機能を実行するように構成された一連の（例えば、少なくとも１つの）プログラム・モジュールを備える少なくとも１つのプログラム製品を含んでよい。

例えば、一連の（少なくとも１つの）プログラム・モジュール７１８を含んでいるプログラム／ユーティリティ７１６がメモリ７０６に格納されてよいが、これに限定されず、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データも格納されてよい。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データまたはこれらの組み合わせの各々は、ネットワーク環境の実装を含んでよい。プログラム・モジュール７１８は、通常、本明細書に記載された本出願のさまざまな実施形態の機能または方法あるいはその両方を実行する。

当業者によって理解されるように、本出願の態様は、システム、方法、またはコンピュータ・プログラム製品として具現化されてよい。したがって、本出願の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアの態様とハードウェアの態様を組み合わせる実施形態の形態を取ってよく、これらはすべて、本明細書では、一般に「回路」、「モジュール」、または「システム」と呼ばれてよい。さらに、本出願の態様は、コンピュータ可読プログラム・コードが具現化されている１つまたは複数のコンピュータ可読媒体において具現化されたコンピュータ・プログラム製品の形態を取ってよい。

また、コンピュータ・システム／サーバ７０２は、キーボード、ポインティング・デバイス、ディスプレイ７２２などの１つまたは複数の外部デバイス７２０、ユーザがコンピュータ・システム／サーバ７０２と情報をやりとりできるようにする１つまたは複数のデバイス、またはコンピュータ・システム／サーバ７０２が１つまたは複数の他のコンピューティング・デバイスと通信できるようにする任意のデバイス（例えば、ネットワーク・カード、モデムなど）、あるいはその組み合わせと通信することもできる。このような通信は、Ｉ／Ｏインターフェイス７２４を介して行うことができる。さらに、コンピュータ・システム／サーバ７０２は、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）、一般的な広域ネットワーク（ＷＡＮ：wide area network）、またはパブリック・ネットワーク（例えば、インターネット）、あるいはその組み合わせなどの１つまたは複数のネットワークと、ネットワーク・アダプタ７２６を介して通信することができる。図示されているように、ネットワーク・アダプタ７２６は、バスを介してコンピュータ・システム／サーバ７０２の他のコンポーネントと通信する。図示されていないが、その他のハードウェア・コンポーネントまたはソフトウェア・コンポーネントあるいはその両方を、コンピュータ・システム／サーバ７０２と併用できるということが理解されるべきである。その例として、マイクロコード、デバイス・ドライバ、冗長プロセッシング・ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これらに限定されない。

システム、方法、および非一過性コンピュータ可読媒体のうちの少なくとも１つの実施形態例が添付の図面において示され、前述の詳細な説明において説明されたが、本出願が、開示された実施形態に限定されず、以下の特許請求の範囲によって示され、定義されているように、多数の再配置、変更、および置き換えを行うことができるということが理解されるであろう。例えば、さまざまな図のシステムの機能は、本明細書に記載されたモジュールまたはコンポーネントのうちの１つまたは複数によって、あるいは分散アーキテクチャにおいて実行することができ、送信器、受信器、またはその両方のペアを含んでよい。例えば、個々のモジュールによって実行される機能の全部または一部は、それらのモジュールのうちの１つまたは複数によって実行されてよい。さらに、本明細書に記載された機能は、さまざまな時間に、さまざまなイベントに関して、モジュールまたはコンポーネントの内部または外部で、実行されてよい。また、さまざまなモジュールの間で送信される情報は、データ・ネットワーク、インターネット、音声ネットワーク、インターネット・プロトコル・ネットワーク、無線デバイス、有線デバイスのうちの少なくとも１つを介して、または複数のプロトコルを介して、あるいはその組み合わせを介して、モジュール間で送信され得る。また、モジュールのいずれかによって送信または受信されるメッセージは、直接的に、または他のモジュールのうちの１つまたは複数を介して、あるいはその両方によって、送信または受信されてよい。

当業者は、「システム」を、パーソナル・コンピュータ、サーバ、コンソール、ＰＤＡ（personal digital assistant）、携帯電話、タブレット・コンピューティング・デバイス、スマートフォン、または任意のその他の適切なコンピューティング・デバイス、あるいはデバイスの組み合わせとして具現化できるということを、理解するであろう。「システム」によって実行されている前述の機能を提示することは、本出願の範囲を限定するように全く意図されておらず、多くの実施形態のうちの１つの例を提供するよう意図されている。実際に、本明細書で開示された方法、システム、および装置は、計算技術に一致する局所的な分散された形態で実装されてよい。

本明細書において説明されたシステムの特徴の一部が、それらの実装の独立性を特に強調するために、モジュールとして提示されていることに、注意するべきである。例えば、モジュールは、カスタム超大規模集積（ＶＬＳＩ：very large-scale integration）回路またはゲート・アレイ、論理チップなどの市販の半導体、トランジスタ、またはその他の個別のコンポーネントを備えているハードウェア回路として実装されてよい。モジュールは、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ論理、プログラマブル論理デバイス、グラフィックス・プロセッシング・ユニットなどの、プログラム可能なハードウェア・デバイスにおいて実装されてもよい。

モジュールは、さまざまな種類のプロセッサによって実行するために、ソフトウェアにおいて少なくとも部分的に実装されてもよい。例えば、実行可能コードの識別されたユニットは、例えばオブジェクト、プロシージャ、または関数として編成されてよいコンピュータ命令の１つまたは複数の物理的または論理的ブロックを備えてよい。それにもかかわらず、識別されたモジュールの実行ファイルは、物理的に一緒に配置される必要はなく、異なる位置に格納された異種の命令を含んでよく、それらの命令は、論理的に一緒に結合された場合にモジュールを構成し、モジュールの規定された目的を達成する。さらに、モジュールはコンピュータ可読媒体に格納されてよく、このコンピュータ可読媒体は、例えば、ハード・ディスク・ドライブ、フラッシュ・デバイス、ランダム・アクセス・メモリ（ＲＡＭ）、テープ、またはデータの格納に使用される任意のその他のこのような媒体であってよい。

実際に、実行可能コードのモジュールは、単一の命令であるか、または多くの命令であることができ、複数の異なるコード・セグメントにわたって、異なるプログラム間および複数のメモリ・デバイスにまたがって、分散されてもよい。同様に、操作可能なデータが、識別され、本明細書ではモジュール内で示されてよく、任意の適切な形態で具現化され、任意の適切な種類のデータ構造内で編成されてよい。操作可能なデータは、単一のデータ・セットとして収集されてよく、または異なるストレージ・デバイスを含む、異なる位置にわたって分散されてよく、システムまたはネットワーク上の単なる電子信号として、少なくとも部分的に存在してよい。

本明細書の図において概略的に説明され、示されているように、本出願のコンポーネントが、多種多様な異なる構成で配置および設計されてよいということが、容易に理解されるであろう。したがって、実施形態の詳細な説明は、請求される本出願の範囲を限定するよう意図されておらず、単に、本出願の選択された実施形態を表している。

当業者は、開示された順序とは異なる順序でステップを使用して、または開示された構成とは異なる構成におけるハードウェア要素を使用して、あるいはその両方を使用して、前述の内容を実践できるということを、容易に理解するであろう。したがって、本出願は、これらの好ましい実施形態に基づいて説明されたが、特定の変更、変形、および代替の構造が明白であるということは、当業者にとって明らかであろう。

本出願の好ましい実施形態が説明されたが、説明された実施形態が単なる例であり、それらの実施形態と同等のものおよびそれらの実施形態に対する変更の完全な範囲（例えば、プロトコル、ハードウェア・デバイス、ソフトウェア・プラットフォームなど）で考えた場合、本出願の範囲が添付の特許請求の範囲のみによって定義されるべきであるということが、理解されるべきである。

Claims (20)

1. 第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードを含んでいるブロックチェーン・ネットワークを構成することと、
   前記第１のブロックチェーン・ノードによって、データ参照を前記第２のブロックチェーン・ノードに提供することと、
   前記第２のブロックチェーン・ノードによって、前記第１のブロックチェーン・ノードからの前記データ参照に対応するドキュメントにアクセスすることと、
   前記第２のブロックチェーン・ノードによって、前記ドキュメントの受信の証明を共有ブロックチェーン台帳に提供すること
   とを含んでいる、方法。
2. 前記受信の証明が、前記ドキュメントのハッシュと、ソルトおよび前記ドキュメントを受信したブロックチェーン・ノードの識別子のうちの１つまたは複数とを含んでいる、請求項１に記載の方法。
3. 前記ブロックチェーン・ネットワークを構成することが、
   前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々によって、第３のブロックチェーン・ノードに登録することと、
   前記第３のブロックチェーン・ノードによって、スマート・コントラクトを前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードに提供することと、
   前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々によって、前記スマート・コントラクトに署名することと
   を含んでいる、請求項１に記載の方法。
4. 前記データ参照がＵＲＬを含んでおり、前記ドキュメントが前記ブロックチェーンにも前記第３のブロックチェーン・ノードにも格納されない、請求項３に記載の方法。
5. 前記第３のブロックチェーン・ノードが、ルート・ノードを含むクラウド・ブローカを含んでおり、前記スマート・コントラクトが、前記ルート・ノードの通信パラメータおよび前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々についての認証情報を含んでいる、請求項３に記載の方法。
6. 前記クラウド・ブローカが、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々への逆接続を確立する、請求項５に記載の方法。
7. 前記ブロックチェーン・ネットワークを構成することが、
   前記通信パラメータを、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々に関連付けられたゲートウェイにインポートすることと、
   ドキュメントの転送に含まれるブロックチェーン・ノードごとに認証情報を格納することと
   をさらに含んでいる、請求項５に記載の方法。
8. ルート・ノードを含んでいるクラウド・ブローカと、
   データ参照を提供するように構成された第１のブロックチェーン・ノードと、
   前記第１のブロックチェーン・ノードから前記データ参照を受信し、それに応じて、
   前記第１のブロックチェーン・ノードからの前記データ参照と一致するドキュメントにアクセスし、
   前記ドキュメントの受信の証明を共有ブロックチェーン台帳に提供する
   ように構成された第２のブロックチェーン・ノードと
   を含んでいるブロックチェーン・ネットワークを備えている、システム。
9. 前記受信の証明が、前記ドキュメントのハッシュと、ソルトおよび前記第２のブロックチェーン・ノードの識別子のうちの１つまたは複数とを含んでいる、請求項８に記載のシステム。
10. 前記第１のブロックチェーン・ノードが前記データ参照を提供する前に、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々が第３のブロックチェーン・ノードに登録し、前記第３のブロックチェーン・ノードが、スマート・コントラクトを前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードに提供し、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々が前記スマート・コントラクトに署名する、請求項８に記載のシステム。
11. 前記データ参照がＵＲＬを含んでおり、前記ドキュメントが前記ブロックチェーンにも前記第３のブロックチェーン・ノードにも格納されない、請求項１０に記載のシステム。
12. 前記第３のブロックチェーン・ノードが前記クラウド・ブローカを含んでおり、前記スマート・コントラクトが、前記ルート・ノードの通信パラメータおよび前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々についての認証情報を含んでいる、請求項１０に記載のシステム。
13. 前記クラウド・ブローカが、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々への逆接続を確立する、請求項１２に記載のシステム。
14. 前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々が、前記通信パラメータをゲートウェイにインポートし、ドキュメントの転送に含まれるブロックチェーン・ノードごとに認証情報を格納する、請求項１２に記載のシステム。
15. 命令を含んでいる非一過性コンピュータ可読媒体であって、前記命令が、プロセッサによって読み取られたときに、前記プロセッサに、
    第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードを含んでいるブロックチェーン・ネットワークを構成することと、
    前記第１のブロックチェーン・ノードによって、データ参照を前記第２のブロックチェーン・ノードに提供することと、
    前記第２のブロックチェーン・ノードによって、前記第１のブロックチェーン・ノードからの前記データ参照に対応するドキュメントにアクセスすることと、
    前記第２のブロックチェーン・ノードによって、前記ドキュメントの受信の証明を共有ブロックチェーン台帳に提供することとを実行させる、
    非一過性コンピュータ可読媒体。
16. 前記受信の証明が、前記ドキュメントのハッシュと、ソルトおよび前記ドキュメントを受信したブロックチェーン・ノードの識別子のうちの１つまたは複数とを含んでいる、請求項１５に記載の非一過性コンピュータ可読媒体。
17. 前記ブロックチェーン・ネットワークを構成することが、
    前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々によって、第３のブロックチェーン・ノードに登録することと、
    前記第３のブロックチェーン・ノードによって、スマート・コントラクトを前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードに提供することと、
    前記第１および第２のブロックチェーン・ノードの各々によって、前記スマート・コントラクトに署名することとを含んでいる、請求項１５に記載の非一過性コンピュータ可読媒体。
18. 前記データ参照がＵＲＬを含んでおり、前記ドキュメントが前記ブロックチェーンにも前記第３のブロックチェーン・ノードにも格納されない、請求項１７に記載の非一過性コンピュータ可読媒体。
19. 前記第３のブロックチェーン・ノードが、ルート・ノードを含むクラウド・ブローカを含んでおり、前記スマート・コントラクトが、前記ルート・ノードの通信パラメータおよび前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々について認証情報を含んでいる、請求項１７に記載の非一過性コンピュータ可読媒体。
20. 前記クラウド・ブローカが、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々への逆接続を確立し、前記ブロックチェーン・ネットワークを構成することが、
    前記通信パラメータを、前記第１のブロックチェーン・ノードおよび第２のブロックチェーン・ノードの各々に関連付けられたゲートウェイにインポートすることと、
    ドキュメントの転送に含まれるブロックチェーン・ノードごとに認証情報を格納することとをさらに含んでいる、請求項１９に記載の非一過性コンピュータ可読媒体。

Images