JP2021512416A - クラウドベースのコンピューティング環境において分散台帳技術のためのインテリジェントな合意、スマートな合意、及び重み付き合意のモデルを実現するシステム、方法、及び装置 - Google Patents

Abstract

開示される実施形態は、クラウドベースのコンピューティング環境における分散台帳技術のためのインテリジェントな合意、スマートな合意、及び重み付き合意のモデルを実現するシステム、方法、及び装置に関する。他の実施形態が、Ｑｕｉｐｃｈａｉｎを使用して文書インターフェース及びコラボレーションを実現する手段と、分散台帳技術のための同意管理を有するスーパーコミュニティ及びコミュニティサイドチェーンを実現する手段と、分散台帳技術のための仮想チェーンモデルを実現する手段と、分断台帳技術を使用してスマートフローコントラクトを実現する手段に関する。このような実施形態は、マルチテナントデータベース技術、クライアント‐サーバ技術、従来のデータベース技術を利用するオンデマンド若しくはクラウドコンピューティング環境などの、ホストされたコンピューティング環境のコンピューティングアーキテクチャ、又はホストされたコンピューティング環境のサポートにおける他のコンピューティングアーキテクチャ内で実現され得る。

Description

［優先権の主張］
本出願は、2018年1月31日に出願され「Systems, Methods, and Apparatuses for Implementing Super Community and Community Sidechains with Consent Management for Distributed Ledger Technologies in a Cloud Based Computing Environment」と題された米国特許出願第15/932,100号の優先権を主張し、その全内容は参照により本明細書に組み込まれる。

［著作権表示］
本特許文献の開示の一部は、著作権保護の対象となる資料を含む。著作権者は、特許文献又は特許開示が特許商標庁の特許ファイル又は記録に現れるとき、何人によるそのファクシミリ複製にも異論はないが、そうでない場合はいかなる全ての著作権も留保する。

本明細書に開示される実施形態は、一般に、分散台帳技術の分野に関する。より詳細には、開示される実施形態は、クラウドベースのコンピューティング環境において分散台帳技術のためのインテリジェントな合意、スマートな合意、及び重み付き合意のモデルを実現するシステム、方法、及び装置に関する。他の実施形態は、クラウドベースのコンピューティング環境においてＱｕｉｐｃｈａｉｎを使用して文書インターフェース及びコラボレーションを実現するシステム、方法、及び装置に関する。さらに他の実施形態は、クラウドベースのコンピューティング環境において分散台帳技術のための同意管理を伴うスーパーコミュニティ及びコミュニティサイドチェーンを実現するシステム、方法、及び装置に関する。さらなる実施形態は、クラウドベースのコンピューティング環境において分散台帳技術のための仮想チェーンモデルを実現するシステム、方法、及び装置に関する。さらなる実施形態は、クラウドベースのコンピューティング環境において分散台帳技術を使用してスマートフローコントラクトを実現するシステム、方法、及び装置に関する。このような実施形態は、マルチテナントデータベース技術、クライアント‐サーバ技術、従来のデータベース技術を利用するオンデマンド若しくはクラウドコンピューティング環境などの、ホストされたコンピューティング環境のコンピューティングアーキテクチャ、又はホストされたコンピューティング環境のサポートにおける他のコンピューティングアーキテクチャ内で実現され得る。

背景技術セクションで論じられる対象事項は、単に背景技術セクションで言及されていることを理由として従来技術とみなされるべきではない。同様に、背景技術セクションで言及され、又は背景技術セクションの対象事項に関連する問題は、従来技術において前に認識されているとみなされるべきではない。背景技術セクションにおける対象事項は異なるアプローチを表すに過ぎず、それ自体、請求される実施形態にも対応し得る。

現代の金融システムにおいて、通貨や証券などの資産は通常、電子的に保有され、取引される。資産の移転は、複数の仲介業者間のポイントツーポイントの相互作用と、複製された台帳の調整をしばしば必要とする。このシステムは、資産の移転又は支払の決済に要する時間、これがしばしば数日を要する、移転が複数の仲介業者への手数料支払を伴う、調整が高額のオーバヘッドを伴う可能性がある、保留中の移転の状態又は資産の現在の所有者を見つけ出すことが困難な可能性がある、移転が完了しない可能性がある、１つの移転を別の移転に対する条件とすることが困難な可能性がある、などのいくつかの欠点を有し、このようなシステムの複雑さは、詐欺又は窃盗を防止することを困難にし、取引が可逆的であるかどうかは、取引当事者のビジネス要件よりも移転メカニズムに依存する。

これらの問題の多くは、資産所有権が単一の共有台帳に記録されていれば解決することができる。しかしながら、実用的な制約と技術的な制約の組み合わせが、そのような台帳を採用することを困難にしている。このような共有台帳は、単一の当事者の信頼を必要とする傾向がある。その当事者は、全てのトランザクションをリアルタイムで処理する技術的なキャパシティを有する必要がある。さらに、上記で論じられた欠点に対処するために、台帳は、簡素な所有権変更より精巧なロジックをサポートする必要がある。２００９年に、偽名「サトシ ナカモト」下で活動する人や人のグループが、ブロックチェーンとして知られる電子台帳複製システムを使用して、信頼された第三者のないデジタル無記名証券の発行を可能にするプロトコルの最初の実装、「ビットコイン」（登録商標）（Bitcoin）を導入した。ビットコインは、非中央集権的なデジタルキャッシュを実現するという問題を解決するが、そのセキュリティモデルはその効率とスループットを制限し、その設計は単一の資産のみサポートし、その仮想マシンは、時にスマートコントラクトと呼ばれる資産移動を決定するカスタムプログラムに対して限られたサポートのみ有する。

２０１５年に導入されたイーサリアム（登録商標）（Ethereum）は、ブロックチェーンの概念を完全にプログラム可能なステート複製メカニズムに一般化している。それは、より一層強力なプログラミング言語を含むが、スケーラビリティと効率についてさらなる課題を提示している。

パブリックインターネット上で動作するように設計されているビットコインやイーサリアムと対照的に、大抵の金融活動はすでに金融機関の制限されたネットワーク内で生じている。このネットワーク内で運用される共有台帳は、金融機関により必要とされる効率、セキュリティ、プライバシー、柔軟性を犠牲にすることなく、ブロックチェーン技術を利用することができる。

したがって、現在の技術水準は、分散台帳技術を改善、修正、及び拡張し、本明細書に記載されるオンデマンドのクラウドベースのコンピューティング環境を介してそのような能力を提供するシステム、方法、及び装置から利益を得る可能性がある。

実施形態は、限定としてではなく例として示されており、図面と関連して考慮されたとき以下の詳細な説明を参照してより十分に理解される。
説明される実施形態による例示的なアーキテクチャを示す。 説明される実施形態による、ブロックチェーンプロトコルブロック１６０のさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、ブロックチェーン及びフォークしたブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、サイドチェーンについてのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、分散台帳技術の方法を実現する方法を示すフロー図を示す。 説明される実施形態による、クラウドベースのコンピューティング環境において分散台帳技術のためのインテリジェントな合意、スマートな合意、及び重み付き合意のモデルを実現する方法を示すフロー図を示す。 説明される実施形態による、分散台帳技術の方法を実現する方法を示すフロー図を示す。 説明される実施形態による、クラウドベースのコンピューティング環境においてｑｕｉｐｃｈａｉｎを使用して文書インターフェース及びコラボレーションを実現する方法を示すフロー図を示す。 説明される実施形態による、分散台帳技術の方法を実現する方法を示すフロー図を示す。 説明される実施形態による、分散台帳技術の方法を実現する方法を示すフロー図を示す。 説明される実施形態による、同意管理を有するコミュニティサイドチェーンを実現するブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、同意管理を有するコミュニティサイドチェーンのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、同意管理を有するスーパーコミュニティサイドチェーンを実現するブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、スーパーコミュニティ機能と相互作用するユーザデバイスにおけるＧＵＩのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、スーパーコミュニティ機能と相互作用するユーザデバイスにおけるＧＵＩのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、クラウドベースのコンピューティング環境において分散台帳技術のための同意管理を有するスーパーコミュニティ及びコミュニティサイドチェーンを実現する方法を示すフロー図を示す。 説明される実施形態による、実施形態が動作し、設置され、統合され、又は構成され得るシステムの概略表現を示す。 説明される実施形態による、スマートフローコントラクトエンジンを利用して作成されたブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、Ａｐｅｘ翻訳エンジンを利用して作成されたブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、クラウドベースのコンピューティング環境において分散台帳技術を使用してスマートフローコントラクトを実現する方法を示すフロー図を示す。 説明される実施形態による、実施形態が動作し、設置され、統合され、又は構成され得るシステムの概略表現を示す。 説明される実施形態による、クラウドベースのコンピューティング環境を介して分散台帳技術に関してインターフェースするために利用される仮想チェーンモデルのさらなる詳細を有する別の例示的なアーキテクチャを示す。 説明される実施形態による、クラウドベースのコンピューティング環境において分散台帳技術のための仮想チェーンモデルを実現する方法を示すフロー図を示す。 オンデマンドデータベースサービスが動作し得る環境のブロック図を示す。 説明される実施形態による、図１６Ａの要素とそのような要素間の様々な可能な相互接続との実施形態の別のブロック図を示す。 一実施形態による、コンピュータシステムの例示的な形態のマシンの概略表現を示す。

本明細書では、クラウドベースのコンピューティング環境において分散台帳技術を実現するシステム、方法、装置について説明する。

例えば、特定の実施形態によれば、分散台帳技術は、ピアツーピアネットワークにおける分散台帳技術ホスト又はブロックチェーンプラットフォームホストを企図し、ホストは、その中に少なくともプロセッサ及びメモリを有し、ブロックチェーンに新しいブロックを追加する要求を受信し、該新しいブロックは複数のトランザクションを含み、該要求は複数のトランザクションタイプのうちの１つを指定する。ホストは、指定されたトランザクションタイプに応答して、ブロックチェーンに新しいブロックを追加する要求を検証する（validating）ための複数の合意プロトコルの１つを選択する。ホストは、次いで、選択された合意プロトコルに従って合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証する。最後、ホストは、ブロックチェーンに新しいブロックを追加する要求の検証に応答して、ブロックチェーンの新しいブロックを追加する。

別の実施形態によれば、その中に少なくともプロセッサ及びメモリを有する分散台帳技術プラットフォームホストがあり、プラットフォームホストは、協働文書処理アプリケーションから協働文書又はその一部を受信し、協働文書又はその一部を含むブロックチェーン資産を作成し、ブロックチェーン資産と協働文書に署名した第１のコラボレータに関連づけられたブロックチェーン資産識別子とを含むブロックチェーントランザクションを作成し、ブロックチェーン上の循環にブロックチェーントランザクションをブロードキャストし、ブロックチェーントランザクションの検証を受信し、ブロックチェーンにおけるブロックチェーントランザクションのブロードキャストに応答して、ブロックチェーンに対してブロック内の検証されたブロックチェーントランザクションをコミットする。

以下の説明では、様々な実施形態の完全な理解を提供するために、特定のシステム、言語、コンポーネント等の例などの、多数の特定の詳細が記載される。しかしながら、当業者には、これらの特定の詳細が本明細書に開示される実施形態を実施するために採用される必要はないことが明らかであろう。他の例では、開示される実施形態を不必要に分かりにくくすることを避けるために、良く知られた材料又は方法は詳細に説明されていない。

図に示され本明細書で説明される様々なハードウェアコンポーネントに追加で、実施形態は、以下で説明される様々な動作をさらに含む。このような実施形態により説明される動作は、ハードウェアコンポーネントにより実行されてもよく、あるいはマシン実行可能命令で具現化されてもよく、これは、命令でプログラムされた汎用又は専用プロセッサに動作を実行させるために使用されてもよい。あるいは、動作は、ハードウェアとソフトウェアの組み合わせにより実行されてもよい。

実施形態は、さらに、本明細書に開示される動作を実行する装置に関する。この装置は、必要な目的のために特別に構築されてもよく、あるいはコンピュータに記憶されたコンピュータプログラムにより選択的にアクティブ化又は再構成される汎用コンピュータでもよい。そのようなコンピュータプログラムは、これらに限られないが、光ディスク、ＣＤ‐ＲＯＭ、及び磁気光ディスクを含む任意のタイプのディスク、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光学カード、又はコンピュータシステムバスに各々結合された電子命令を記憶するのに適した任意のタイプの媒体などのコンピュータ読取可能記憶媒体に記憶されてもよい。

本明細書で提示されるアルゴリズム及び表示は本来的に、いずれかの特定のコンピュータ又は他の装置に関連しない。様々な汎用システムが本明細書における教示に従うプログラムと共に使用されてもよく、あるいは、必要な方法ステップを実行するためにより特化した装置を構築することが便利であることが判明し得る。種々のこれらシステムに必要な構造は、以下の説明に記載されているとおり明らかになる。さらに、実施形態は、いずれかの特定のプログラミング言語を参照して記載されていない。種々のプログラミング言語が、本明細書に記載される実施形態の教示を実現するために使用され得ることが理解されるであろう。

実施形態は、命令を記憶したマシン読取可能媒体を含み得るコンピュータプログラムプロダクト又はソフトウェアとして提供されてもよく、命令を使用して、開示の実施形態に従う処理を実行するようにコンピュータシステム（又は他の電子デバイス）をプログラムしてもよい。マシン読取可能媒体は、マシン（例えば、コンピュータ）により読取可能な形式で情報を記憶又は伝送するための任意の機構を含む。例えば、マシン読取可能（例えば、コンピュータ読取可能）媒体は、マシン（例えば、コンピュータ）読取可能記憶媒体（例えば、読取専用メモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス等）、マシン（例えば、コンピュータ）読取可能伝送媒体（電気、光学、音響）等を含む。

開示される実施形態のいずれも、単独で、又は互いに組み合わせて一緒に使用することができる。様々な実施形態が従来の技術及びアプローチでの欠陥により部分的に動機づけられている可能性があり、これらのいくつかが本明細書内で記載又は言及されているが、実施形態は、必ずしもこれらの欠陥のいずれかを対処又は解決する必要はなく、むしろ、欠陥のいくつかのみに対処し、欠陥のいずれにも対処せず、あるいは直接論じられていない異なる欠陥及び問題に向けられている場合がある。

図１Ａは、説明される実施形態による一例示的なアーキテクチャ１００を示す。

一実施形態において、ホストされた（hosted）コンピューティング環境１１１は、ホスト組織１１０を介して複数のユーザクライアントデバイス１０６Ａ〜Ｃ（例えば、モバイルデバイス、スマートフォン、タブレット、ＰＣなど）と通信可能にインターフェースされる。一実施形態において、データベースシステム１３０は、データベース１５５Ａ及び１５５Ｂを含み、例えば、顧客組織１０５Ａ〜Ｃ（例えば、そのようなデータベースシステム１３０のユーザ、又はマルチテナントデータベースタイプのデータベースシステムのテナント、又はそのようなデータベースシステムの加入ユーザ）のために、アプリケーションコード、オブジェクトデータ、テーブル、データセット、及びユーザデータを含む基礎をなすデータベースレコードを記憶する。そのようなデータベースは、例えば、特定の実施形態による関係データベースシステム１５５Ａ及び非関係データベースシステム１５５Ｂを含む様々なデータベースシステムタイプを含む。

特定の実施形態において、クライアント‐サーバコンピューティングアーキテクチャが、データベースシステム１３０の特徴、機能性、又はコンピューティングリソースを補足するために利用されてもよく、あるいは代わりに、コンピューティンググリッド、又はワークサーバのプール、又はホストされたコンピューティングアーキテクチャの何らかの組み合わせが、データベースシステム１３０に関連してホスト組織１１０の要求される計算ワークロード及び処理の一部又は全部を提供してもよい。

図示の実施形態に示されるデータベースシステム１３０は、ホスト組織１１０内のデータベース機能性とコード実行環境を実現する、複数の基礎をなすハードウェア、ソフトウェア、及び論理要素１５０を含む。

一実施形態によれば、データベースシステム１３０は、基礎をなすデータベースシステム実装１５５Ａ及び１５５Ｂを利用して、クエリインターフェースを介してデータベースシステム１３０と通信するデータベースクエリ及び他のデータベースシステム１３０とのデータ相互作用をサービスする。データベースシステム１３０のハードウェア、ソフトウェア、及び論理要素１５０は、顧客組織（１０５Ａ、１０５Ｂ、及び１０５Ｃ）とは別個及び区別可能であり、顧客組織は、ネットワーク１５５を介してホスト組織１１０に通信可能にインターフェースすることにより、ホスト組織１１０により提供されるウェブサービス及び他のサービス提供を利用する。このような方法で、ホスト組織１１０は、サブスクライブしている（subscribing）顧客組織１０５Ａ〜１０５Ｃに対するオンデマンドサービス、オンデマンドデータベースサービス、又はクラウドコンピューティングサービスを実現し得る。

さらに、ホスト組織１１０は、ネットワーク１５５（パブリックインターネットなど）を介して顧客組織１０５Ａ〜Ｃからの入力及び他の要求１１５を受信することが示されている。例えば、入ってくる検索クエリ、データベースクエリ、ＡＰＩ要求、ユーザクライアントデバイス１０６Ａ〜Ｃで表示されたグラフィカルユーザインターフェース及び表示との相互作用、又は他の入力が、顧客組織１０５Ａ〜Ｃから受信されてデータベースシステム１３０に対して処理されてもよく、あるいは、そのようなクエリが、データベース１５５又はクエリインターフェース１８０に対する実行のために入力及び他の要求１１５から構築されてもよく、それに応じて、結果１１６が、次いで、顧客組織１０５Ａ〜Ｃのユーザクライアントデバイス１０６Ａ〜Ｃのうち１つのユーザなどの発信者又は要求者に返される。

一実施形態において、各顧客組織１０５Ａ〜Ｃは、別個及び区別可能なリモート組織、ホスト組織１１０内の組織グループ、ホスト組織１１０のビジネスパートナー、又はホスト組織１１０により提供されるクラウドコンピューティングサービスをサブスクライブする顧客組織１０５Ａ〜Ｃからなる群から選択されるエンティティである。

一実施形態において、要求１１５は、ホスト組織１１０内のウェブサーバ１７５で受信され、あるいは該ウェブサーバ１７５にサブミットされる。ホスト組織１１０は、ホスト組織１１０及びそのデータベースシステム１３０による処理に対する様々な要求を受け取ることができる。ウェブサーバ１７５で受信される、入ってくる要求１１５は、ホスト組織１１０からどのサービスが提供されるべきかを指定することができ、例えば、クエリ要求、検索要求、ステータス要求、データベーストランザクション、グラフィカルユーザインターフェース要求及び相互作用、顧客組織１０５Ａ〜Ｃの１つのためにデータを取り出し、更新し、又は記憶する処理要求、コード実行要求などのである。ウェブサーバ１７５は、クエリインターフェース１８０のためにネットワーク１５５を介して様々な顧客組織１０５Ａ〜Ｃからの要求１１５を受信し、ウェブベースのインターフェース又は他のグラフィカル表示を、エンドユーザクライアントデバイス１０６Ａ〜Ｃ又はそのようなデータ要求１１５を発するマシンに提供することを担うことができる。

クエリインターフェース１８０は、データベースシステム１３０のデータベース及び記憶コンポーネントに対して要求されたクエリを受信及び実行し、説明される方法論を促進するために結果セット、応答、又は他の要求されたデータを返すことができる。さらに、クエリインターフェース１８０は、クエリをウェブサーバ１７５から、検索クエリを処理するデータベース１５５に対する実行のためにデータベースシステム１３０に、又はホスト組織のコンピューティング環境１１１の他の利用可能なデータストアに渡す機能を提供する。一実施形態において、クエリインターフェース１８０は、データベース１５５又は他のデータストアに対してクエリが実行され得るアプリケーションプログラミングインターフェース（ＡＰＩ）を実装する。

ホスト組織１１０は、ウェブサーバ１７５を介してか又はスタンドアロンインターフェースとして要求インターフェース１７６を実現して、ユーザクライアントデバイス１０６Ａ〜Ｃから要求パケット又は他の要求１１５を受信することができる。さらに、要求インターフェース１７６は、ホスト組織１１０からユーザクライアントデバイス１０６Ａ〜Ｃへの出て行く方向の応答パケット又は他のリプライ及び応答１１６の返信をサポートする。認証器（Authenticator）１４０は、ホスト組織のために動作し、ホスト組織へのアクセスの獲得を試みるユーザを検証し、認証し、その他の方法で認定（credential）する。

さらに、ホスト組織１１０内には、ブロックチェーン合意マネージャ１９１とブロックバリデータ（validator）１９２の双方をその中に含むブロックチェーンサービスインターフェース１９０が示されている。ブロックチェーンサービスインターフェース１９０は、ホスト組織１１０を他の参加ノード１３３と（例えば、ネットワーク１５５を介して）通信上インターフェースして、ホスト組織１１０がブロックチェーンプロトコル準拠ノードとして作用することにより利用可能なブロックチェーンプロトコルに参加することを可能にし、ホスト組織１１０がそのようなブロックチェーン内の情報にアクセスすることを可能にすると共に、ホスト組織１１０が他の参加ノード１３３に、ホスト組織１１０によりサポートされ、ホスト組織１１０により顧客及びサブスクライバ（subscribers）に提供される任意数のブロックチェーンプロトコルについてブロックチェーンサービスを提供することを可能にする。

ブロックチェーンは、ブロック単位でグループ化されたレコードの連続的に成長するリストであり、該ブロックは、一緒にリンクされ、暗号法を用いて安全化されている。各ブロックは、前のブロックへのリンクとしてのハッシュポインタ、タイムスタンプ、及びトランザクションデータを典型的に含む。設計により、ブロックチェーンは本来的に、データの修正に対して耐性がある。ブロックチェーンシステムは本質的に、２者間のトランザクションを効率的かつ立証可能な方法で記録するオープンな分散された台帳であり、これもまた不変（immutable）かつ永続的である。分散台帳（共有又は共通台帳とも呼ばれ、あるいは分散台帳技術（distributed ledger technology、ＤＬＴ）と呼ばれる）は、複数のノードにわたり地理的に分散された複製、共有、及び同期されたデジタルデータの合意である。ノードは、異なるサイト、国、機関、ユーザコミュニティ、顧客組織、ホスト組織、ホストされたコンピューティング環境、又はアプリケーションサーバに位置してもよい。中央管理者や中央集権的なデータストレージは存在しない。

ブロックチェーンシステムは、ノードのピアツーピア（Ｐ２Ｐ）ネットワークを使用し、合意アルゴリズムは、ノードにわたるデジタルデータの複製を保証する。ブロックチェーンシステムは、パブリック又はプライベートのいずれでもよい。必ずしも全ての分散台帳が、分散された合意の安全かつ有効な達成を成功裏に提供するためにブロックのチェーンを使用するわけではなく、ブロックチェーンは、分散台帳と考えられるデータ構造の１つのタイプに過ぎない。

Ｐ２Ｐコンピューティング又はネットワーキングは、ピア間でタスク又はワークロードを分ける分散アプリケーションアーキテクチャである。ピアは、ノードのピアツーピアネットワークを形成するアプリケーションにおいて、同等に特権を与えられ、同等に能力を有する参加者である。ピアは、そのリソースの一部、例えば処理パワー、ディスクストレージ、又はネットワーク帯域幅などを、サーバ又はホストによる中央の協調の必要なく、他のネットワーク参加者が直接利用できるようにする。リソースの消費と供給が分けられている従来のクライアント‐サーバモデルと対照的に、ピアは、リソースの供給者と消費者の双方である。ゆえに、ピアツーピアネットワークは、クライアントとサーバの双方としてネットワーク上の他のノードに同時に機能する等しいピアノードの概念を中心に設計されている。

分散台帳として使用するために、ブロックチェーンは、新しいブロックを検証するプロトコルに集合的に従うピアツーピアネットワークにより典型的に管理される。ひとたび記録されると、任意の所与のブロック内のデータは、全ての後続ブロックの改変なしに遡及的に改変することはできず、これには、ネットワークの過半数の共謀を必要とする。このようにして、ブロックチェーンは、設計上安全であり、高いビザンチンフォールトトレラント性（Byzantine fault tolerance）を有する分散コンピューティングシステムの一例である。したがって、非中央集権的な合意がブロックチェーンにより達成されている。これにより、ブロックチェーンは、イベント、医療記録、保険記録、及び他の記録管理アクティビティ、例えばアイデンティティ管理、トランザクション処理、文書化の出所、又は投票などの記録に潜在的に適している。

ブロックチェーンデータベースは、ピアツーピアネットワークと分散タイムスタンプ付け（timestamping）サーバを使用して自律的に管理される。ブロック形式のレコードは、集合的な自己利益により動機づけられるノード間の協働により、ブロックチェーン内で認証される。結果として、データセキュリティに関する参加者の不確実性が最小化される。ブロックチェーンの使用は、デジタル資産の再現性という特性を取り除く。それは、資産などの各価値単位が１回だけ移転されたことを裏付け、二重支出（double spending）の問題を解決する。

ブロックチェーン内のブロックは各々、ハッシュされてマークル木に符号化される有効なトランザクションのバッチ（「ブロック」）を保持する。各ブロックは、ブロックチェーン内の先行ブロックのハッシュを含み、この２つをリンクする。リンクされたブロックはチェーンを形成する。この反復プロセスが、時にジェネシスブロック又はルートブロックと呼ばれるチェーン内の最初のブロックまで遡って、前のブロックの完全性を裏付ける。

ブロックチェーンは、そのネットワークにわたりデータを記憶することにより、データが中央に保持され、単一のオーソリティにより制御されることに伴うリスクを排除する。ホスト組織１１０は、ホスト組織１１０などの単一の責任を負うエージェントに大量のデータを提供する能力を含む広範なデータ処理及び記憶サービスを提供するが、ブロックチェーンサービスは異なり、それにより、ホスト組織１１０は、そのようなサービスの単一のオーソリティではなく、むしろ、ブロックチェーンサービスインターフェース１９０を介し、利用可能なブロックチェーンプロトコルのための多くのノードのうちの１つに過ぎず、あるいはブロックチェーンプロトコルマネージャ及びプロバイダとして動作し、一方、ブロックチェーンサービスインターフェース１９０を介してホスト組織１１０と通信する他の参加ノード１３３は、ホスト組織１１０により提供される利用可能なブロックチェーンプロトコルに従って準拠した分散台帳技術（ＤＬＴ）を実現することにより、ブロックチェーン内に記憶された情報のリポジトリとして集合的に動作する。

非中央集権的なブロックチェーンは、アドホックメッセージパッシング及び分散ネットワーキングを使用することができる。ブロックチェーンネットワークは、コンピュータハッカーが活用できる脆弱性の中央集権的なポイントがない。同様に、中央の障害点もない。ブロックチェーンセキュリティメソッドは、公開鍵暗号の使用を含む。公開鍵は、ブロックチェーン上のアドレスである。ネットワークにわたり送信される値トークンは、そのアドレスに属するものとして記録される。秘密鍵は、その所有者にデジタル資産へのアクセスを与えるパスワードのようなもの、又は、その他の方法でブロックチェーンがサポートする様々な機能と相互作用する手段である。ブロックチェーンに記憶されたデータは、一般に破損しないと考えられる。これは、ブロックチェーンがその利点を有するところである。中央集権的なデータはより制御可能であるが、情報及びデータ操作が共通する。ブロックチェーンは、それを非中央集権化することにより、関与する誰に対してもデータを透過的にする。

非中央集権的なシステム内の特定のブロックチェーンプロトコルのためのあらゆる参加ノード１３３は、その特定のブロックチェーンプロトコルのためのブロックチェーンのコピーを有する。データ品質は、大規模なデータベース複製及び計算的信頼により維持される。データベースの中央集権的なオフィシャルのコピーは存在せず、デフォルトでは、どのユーザも参加ノード１３３のいずれも、他より信頼されているわけではないが、このデフォルトは、以下でより詳細に説明されるように、特定の特化されたブロックチェーンプロトコルを介して改変されてもよい。ブロックチェーントランザクションは、ソフトウェアを使用してネットワークにブロードキャストされ、該ソフトウェアを介して、ノードとして動作しているときのホスト組織１１０を含む任意の参加ノード１３３が、このようなトランザクションブロードキャストを受信する。ブロードキャストメッセージは、ベストエフォート方式で配信される。ノードは、トランザクションを検証し、該トランザクションをそれらが構築しているブロックに追加し、次いで、完成したブロックを他のノードにブロードキャストする。ブロックチェーンは、プルーフオブワーク（proof-of-work）などの様々なタイムスタンプ付けスキームを使用して、変更をシリアライズする。代わりの合意が、ホスト組織により提供されかつサポートされる様々なブロックチェーンプロトコルと関連して利用されてもよく、そのような合意メカニズムには、例えば、いくつか例を挙げると、プルーフオブステーク（proof-of-stake）、プルーフオブオーソリティ（proof-of-authority）、及びプルーフオブバーン（proof-of-burn）が含まれる。

オープンブロックチェーンは、一般に公開されているが閲覧するために物理的なアクセスを必要とする従来の伝統的な所有権記録よりユーザフレンドリである。早期のブロックチェーンのほとんどが許可なし（permissionless）であったため、いわゆる「ブロックチェーン」の特定の受け入れられる定義についていくらかの議論があり、例えば、中央オーソリティによりタスクを課され承認された立証者（verifiers）を有するプライベートシステムはブロックチェーンと考えられるべきかどうかなどである。許可あり又はプライベートのチェーンの支持者は、用語ブロックチェーンが、データをタイムスタンプ付きブロックにグループ化する任意のデータ構造に適用され得ると主張している。これらのブロックチェーンは、データベースにおけるマルチバージョン同時実行制御（multiversion concurrency control、ＭＶＣＣ）の分散バージョンとして機能する。ＭＶＣＣが、２つのトランザクションがデータベース内の単一のオブジェクトを同時に修正することを防止するのと同様に、ブロックチェーンは、２つのトランザクションが一ブロックチェーン内で同じ単一のアウトプットを消費することを防止する。その意味論にもかかわらず、「ブロックチェーン」に関して本明細書に記載される方法論は、従来のブロックチェーンプロトコル実装を拡張してさらなる柔軟性を提供し、記載のブロックチェーン実装に対する新しいサービス及びユースケースを切り開き、ホスト組織１１０のブロックチェーンサービスインターフェース１９０により提供又はサポートされる特定のブロックチェーンプロトコルに依存して、プライベート及びパブリック双方のメカニズムが本明細書で説明され、ホスト組織１１０によりサポートされる異なる実装のために必要に応じて利用される。

オープンで、許可なしの、又はパブリックのブロックチェーンネットワークの利点は、悪い行為者に対する防護が必要なく、アクセス制御が必要ないことである。これは、ブロックチェーンをトランスポート層として使用して、他者の承認や信頼なくアプリケーションをネットワークに追加できることを意味する。逆に、許可ありの（permissioned）（例えば、プライベートの）ブロックチェーンは、アクセス制御層を使用して、ネットワークに対して誰がアクセスを有するかを管理する。パブリックブロックチェーンネットワークと対照的に、プライベートブロックチェーンネットワーク上のバリデータは、例えば、ネットワーク所有者、又はコンソーシアムの１以上のメンバにより調べられる。これらは、既知のノードに依存してトランザクションを検証する。許可ありのブロックチェーンは、「コンソーシアム」又は「ハイブリッド」ブロックチェーンとも呼ばれている。今日、多くの企業は、パブリックブロックチェーンシステムから独立した、プライベートブロックチェーンを有するブロックチェーンネットワーク、又はブロックチェーンベースの分散台帳を使用している。

図１Ｂは、説明される実施形態による、ブロックチェーンプロトコルブロック１６０のさらなる詳細を有する別の例示的なアーキテクチャ１０１を示す。

詳細には、ブロックチェーンプロトコルブロック１６０は、ホスト組織１１０のブロックバリデータ１９２により検証されるようにここでは示されており、ブロックチェーンプロトコルブロックは、その様々なサブコンポーネントと特定の任意の要素のさらなる詳細を含み、該任意の要素は、ブロックチェーンサービスインターフェース１９０を介して利用される特定のブロックチェーンプロトコルに依存してブロックチェーンプロトコルブロック１６０と関連して利用され得る。

特定の実施形態によれば、ここに示されるブロックチェーンプロトコルブロック１６０は、ホスト組織１１０によりサポートされる任意の所与のブロックチェーンプロトコルの基本ブロックがどのように編成されるかについての特定の構造を定義する。

先行ハッシュ１６１は、先行ブロック１５９からのデータを入力として使用する不可逆的数学計算の結果である。先行ブロック１５９は、同様に、ｎ個の前のブロック１５８からのデータを利用して、これらのそれぞれのブロックの先行ハッシュを形成する不可逆的数学計算を形成した。例えば、一実施形態によれば、利用される不可逆的数学計算はＳＨＡ２５６ハッシュ関数であるが、他のハッシュ関数が利用されてもよい。そのような実施形態によれば、ハッシュ関数は、チェーン内の先行ブロック１５９又はｎ個の前のブロック１５８のいずれかにおけるデータに対する任意の変更を結果としてもたらし、これらの先行ブロックのハッシュに予測不可能な変更を引き起こし、結果的に、目下又は現在のブロックチェーンプロトコルブロック１６０を無効にする。先行ハッシュ１６１はブロック間のリンクを作成し、それらを一緒にチェーン化して、現在のブロックチェーンプロトコルブロック１６０を形成する。

ブロックバリデータ１９２が、先行ブロック１５９の先行ハッシュ１６１を算出するとき、ハッシュは、プルーフ基準（standard of proof）１６５として記憶されたデータにより定義された特定の基準を満たさなければならない。例えば、一実施形態において、このプルーフ基準１６５は、算出されたハッシュがこれ未満でなければならないという数である。ハッシュ関数の出力は予測不可能であるため、ハッシュが計算される前に、どの入力がプルーフ基準１６５未満の出力を結果としてもたらすかを知ることはできない。ノンス１６２は、ブロックのデータ内容を変化させるために使用され、プルーフ基準１６５を満たす出力の追求においてハッシュ関数により多数の異なる出力が生成されることを可能にし、ゆえに、プルーフ基準１６５の基準を満たすハッシュ値を結果としてもたらすノンス１６２を有する有効なブロックの生成を極めて計算上高価に（したがって、統計的に可能性を低く）する。

ペイロードハッシュ１６２は、ブロックチェーンプロトコルブロック１６０のブロックペイロード１６９部分内に記憶されたデータのハッシュを提供し、いずれの特定のプルーフ基準１６５も満たす必要はない。しかしながら、ペイロードハッシュは、ハッシュが次の又は後続のブロックの先行ハッシュ１６１として記憶する目的で算出されるとき、入力の一部として含まれる。タイムスタンプ１６４は、特定のエラー範囲内でブロックチェーンプロトコルブロック１６０がいつ作成されたかを示す。ブロックチェーンサービスインターフェース１９０を介して提供される特定のブロックチェーンプロトコル実装によれば、ユーザ（例えば、ブロックチェーンプロトコルノード）の分散ネットワークは、その自身の既知の時間に対してタイムスタンプ１６４をチェックし、エラー閾値を超えるタイムスタンプ１６４を有するいかなるブロックも拒否するが、このような機能性は任意であり、特定のブロックチェーンプロトコルにより必要とされ、他者には利用されなくてもよい。

ブロックチェーンプロトコル証明書（certification）１６６は、ブロックペイロード１６９の必要なサイズ及び／又はデータ構造を定義し、特定のブロックチェーンプロトコル実装への準拠を証明し、ゆえに、ブロックチェーンプロトコルブロックが、示されたブロックチェーンプロトコルの特定の要件及び構成選択肢をサブスクライブし、実現し、守ることを証明する。ブロックチェーンプロトコル証明書１６６は、所与のブロックチェーンプロトコルのバージョンをさらに示してもよく、ブロックチェーンプロトコルは、ノードが新しいブロックチェーンプロトコルブロックを非準拠のため拒否し始める前に、ブロックに対する限られた後方及び前方互換性を許可してもよい。

ブロックタイプ１６７は、利用される特定のブロックチェーンプロトコルに依存して任意である。ブロックチェーンサービスインターフェース１９０を介して公開される特定のブロックチェーンプロトコルに必要とされる場合、ブロックタイプ１６７は、以下でより詳細に説明されるように、許容可能なブロックタイプ１６７の列挙されたリストの１つとして示されなければならない。特定のブロックチェーンプロトコルは複数の異なるブロックタイプ１６７を使用し、これらの全てが可変のペイロードを有し得るが、利用されるブロックチェーンプロトコル、宣言されたブロックタイプ１６７、及びそのような要件への準拠を証明するブロックチェーンプロトコル証明書１６６に従って先験的に分かる構造を有する。非準拠若しくは無効なブロックタイプ、又は所与の宣言されたブロックタイプ１６７に対して予期されていない構造若しくはペイロードは、ネットワークノードによるそのブロックの拒否を結果としてもたらす。

可変サイズのブロックペイロード１６９が利用される場合、ブロックタイプ１６７は、そのような可変サイズのブロックペイロード１６９の許容性を示すと共に、ブロックペイロード１６９内の最初のバイトのインデックスとブロックペイロード１６９の合計サイズを示すことができる。ブロックタイプ１６７は、ブロックペイロード１６９の読み出し、アクセス、並びに正しい処理及び解釈に関連する他の情報を記憶するために利用されてもよい。

ブロック内に記憶されたブロックペイロード１６９のデータは、例えば、金融トランザクション、所有権情報、データアクセス記録、文書バージョニング、医療記録、投票記録、準拠及び証明書、教育上のトランスクリプト、購入レシート、デジタル権利管理記録、又は本質的にデジタル化可能な任意のデータであるブロックチェーンプロトコルブロック１６０のペイロードを介して記憶可能な文字どおり任意の種類のデータに関連するペイロード情報を含む、利用される特定の実装及びブロックチェーンプロトコルに依存した、任意の数の広範なトランザクションデータに関連し得る。選ばれた特定のブロックチェーンプロトコルに依存して、ペイロードサイズは固定サイズでも可変サイズでもよく、いずれの場合も、ペイロードハッシュ１６３を生成するハッシュのための入力の少なくとも一部として利用される。

様々なプルーフ基準１６５が、選ばれた特定のブロックチェーンプロトコルに応じて利用されてもよく、例えば、プルーフオブワーク、ハッシュ値要件、プルーフオブステーク、鍵、又は、合意若しくはプルーフオブコンセンサス（proof of consensus）のような他の何らかのインジケータなどである。合意に基づく手法が利用される場合、ブロックチェーン合意マネージャ１９１は、ホスト組織１１０のために合意管理を提供するが、ホスト組織１１０は、ブロックチェーンサービスインターフェース１９０を介してホスト組織１１０によりアクセスされる所与のブロックチェーンプロトコルのための単に多くのノードのうちの１つとして動作してもよく、あるいは代わりに、ホスト組織１１０は、ブロックチェーンサービスインターフェース１９０を介して、顧客及びサブスクライバに対する（及び、潜在的には、認証されていないパブリックノード参加者に対する）クラウドベースのサービスとして特定のブロックチェーンプロトコルを定義し、提供してもよい。このようなプルーフ基準１６５は、ハッシュ値がプルーフ基準より小さい、プルーフ基準より大きいことを要求するルールとして適用されてもよく、あるいは、特定のビットシーケンス（例えば、１０個のゼロ、又は定義されたバイナリシーケンス）、又は必要な数の先頭若しくは後端のゼロ（例えば、２０個の先頭又は後端のゼロを結果としてもたらす入力のハッシュなどであり、これは、既知の有効な入力なしに提供することが計算上実行不可能である）を必要としてもよい。

先行ハッシュ１６１、ペイロードハッシュ１６３、又は承認されたハッシュ１６８に使用されるハッシュアルゴリズムは、特定のブロックチェーンプロトコル実装に依存して、全て同じタイプのものでも異なるタイプのものでもよい。例えば、許容可能なハッシュ関数は、ＭＤ５、ＳＨＡ‐１、ＳＨＡ‐２２４、ＳＨＡ‐２５６、ＳＨＡ‐３８４、ＳＨＡ‐５１５、ＳＨＡ‐５１５／２２４、ＳＨＡ‐５１５／２５６、ＳＨＡ‐３、又は原像攻撃に耐性のある任意の適切なハッシュ関数を含む。さらに、ハッシュが１回だけ計算されるという要件もない。ハッシュ関数の結果は、最終結果を生成するために、別の又は同じハッシュ関数への入力として再度、複数回再使用されてもよい。

図１Ｃは、説明される実施形態による、ブロックチェーン及びフォークしたブロックチェーン（forked blockchain）のさらなる詳細を有する別の例示的なアーキテクチャ１０２を示す。

より詳細には、次に、プライマリブロックチェーン（例えば、合意ブロックチェーン）が示され、これは、ジェネシスブロック１４１（時にルートブロックと呼ばれる）で始まり、各々がヘッダを有する一連の標準ブロック１４２が後に続き、該ヘッダは、それに先行するブロックのヘッダのハッシュに少なくとも部分的に基づいて形成される。さらに、最初のフォークルートブロック１４４と共に形成されたフォークしたブロックチェーンが示されており、次いで、一連の標準ブロック１４２が後に続いている。ブロックチェーン内の各ブロックは、前のハッシュに記憶された直前のブロックのハッシュを含むため、各ブロックからチェーンに戻るリンクは、ブロックチェーンを介して効果的に生成され、悪意を持ってチェーンを修正することを法外に困難又は計算上実行不可能にするキーコンポーネントである。

図示されるように、プライマリブロックチェーンは、フォークブロック１４３から始まる単一のフォークを含む。ここに示すように、ジェネシスブロック１４１は、プライマリブロックチェーンを開始する特殊ブロックであり、他のブロックとは異なり、なぜならば、それがプライマリブロックチェーンの最初のブロックであり、したがって、定義上、何らかの前のブロックのハッシュを含むことができないからである。ジェネシスブロック１４１は、利用される特定のブロックチェーンプロトコルに対するプライマリブロックチェーンの開始を示す。ブロックチェーンプロトコルは、プライマリブロックチェーンが成長する方法、どのデータが記憶され得るか、及びフォークしたブロックチェーンが作成されるかを管理し、また、任意のブロック及び任意のチェーンの有効性は、ブロックチェーンプロトコル証明書１６６により定められたルール及び要件に応じて、ホスト組織のブロックバリデータ１９２又はブロックチェーンの任意の他の参加ネットワークノードを介して立証されてもよく、該ブロックチェーンプロトコル証明書は、ジェネシスブロック１４１に埋め込まれ、次いで、プライマリブロックチェーン又は任意のフォークしたブロックチェーン内のあらゆる後続ブロックにより証明され（certified）、準拠されなければならない。

ジェネシスチェーン内の各ブロック内のブロックチェーンプロトコル証明書１６６は、フォークの作成と、もしあればそれらのフォークにおけるルール及び構成パラメータの修正を可能にする、ルール及び構成パラメータのデフォルトセットを定義する。いくつかのブロックチェーンプロトコル実装は、ブロックチェーンプロトコル証明書１６６を介して確立されたルールのデフォルトセットへのいかなるバリエーション又は非準拠も許可せず、したがって、いかなるフォークも、複数の競合する潜在的に有効なプライマリブロックチェーンについての合意の保留の結果である。ひとたび合意が達せられると（典型的には、１又は２サイクルと新しいブロック形成の後）、合意を有する分岐が採用され、フォークは切り捨てられ、ゆえに、単一のプライマリ合意ブロックチェーンに戻る。反対に、他の実装において、フォークしたブロックチェーンが、ブロックチェーンプロトコル証明書１６６と、そのブロックチェーンプロトコル内のフォークしたブロックチェーンに対するルール及び構成パラメータの許容可能なバリエーションに準拠する限り、フォークしたブロックチェーンは、許容される方法で（permissibly）作成され、プライマリブロックチェーンと共に無限に存在し続けてもよい。

フォークブロック１４３は、フォークしたブロックチェーンをプライマリブロックチェーンに固定し（anchors）、それにより、プライマリブロックチェーンとフォークチェーンの双方が、ブロックチェーンプロトコル証明書１６６に応じて許可される場合に有効かつ許容可能なチェーンと考えられる。通常、ブロックチェーンでは、全ての非合意フォークは最終的に無視され、あるいは切り捨てられ、ゆえに、合意を有する最も長いチェーンを表す１つのチェーンを除いて無効と考えられる。それにもかかわらず、フォークブロック１４３は、それが標準ブロック１４２であるかのように動作し、出現する一方で、許容可能なフォークしたブロックチェーンの最初のブロックを識別するフォークハッシュ１４９への参照をさらに含むことにより、先行のブロックチェーンプロトコルの従来の水準を超えて拡張し、ここで、該最初のブロックは、有効なフォークしたブロックチェーンのフォークルートブロック１４４として表されている。次いで、フォークしたブロックチェーンのフォークルートブロック１４４は、各々が先行の有効ブロックのハッシュに基づくヘッダを有する標準ブロックが後に続き、無限に続くことになる。

特定の実施形態によれば、フォークしたブロックチェーンは、プライマリ合意ブロックチェーン内でデフォルトで利用されるルール及び構成パラメータからのいくらかのバリエーションを利用し、結果として、有効なフォークしたブロックチェーンの必要をもたらす。したがって、ルール及び構成パラメータのバリエーションは、フォークルートブロック１４４の新しいブロックチェーンプロトコル証明書１６６内で符号化され、これは、上述のように、プライマリブロックチェーンのオリジナルのジェネシスブロック１４１のブロックチェーンプロトコル証明書１６６により定められているオリジナルのルール及び構成パラメータの有効範囲に準拠したままでなければならない。フォークルートブロック１４４はオリジナルのブロックチェーンプロトコル証明書１６６を運び続けなければならないため、フォークしたブロックチェーンプロトコル証明書は、フォークルートブロック１４４のブロックペイロード１６９セグメント内に記憶され、ゆえに、フォークしたブロックチェーン内の後続の標準ブロック１４２のルール及び許容可能な構成パラメータを確立する。

新しいブロックチェーンプロトコル証明書１６６が有効なフォークに適用されるとき、そのルール及び構成は、該フォークと、さらなるフォークが許可される場合には全ての後続のサブフォークの、全ての後続の標準ブロックに適用され、参加ノードにより、フォークしたブロックチェーンがオリジナルのプライマリブロックチェーンであるかのように強制される。このようなフォークは、ワーキンググループなどの特定のグループ、トランザクションの特定のサブタイプ、又は、完全に別個の「サイドチェーン」が必要されず又は望ましくない場合のプライマリブロックチェーンからの何らかの他のバリエーションのために、ルール又は構成の特化されたセットを適用することを求める特定の顧客に対して望ましい場合がある。フォークしたブロックチェーンは、それが同じブロックチェーンプロトコルの一部のままであり、フォークブロック１４３においてプライマリブロックチェーンと永続的に接続され、戻りフォークハッシュ１４９がプライマリ合意ブロックチェーンに戻され、不変的に書き込まれるとき、サイドチェーンから区別でき、それは、プライマリブロックチェーンの全ての後続の標準ブロックに対してチェーンハッシュスキームを介して残ることになる。かなり簡単に述べると、フォークしたブロックチェーンは、フォークブロック１４３を介してプライマリブロックチェーンに明示的に結び付けられる。反対に、サイドチェーンは、プライマリブロックチェーン内に埋め込まれたいかなる明示的な参照又はフォークハッシュ１４９もなくプライマリブロックチェーンと任意のサイドチェーンとの間で渡される全ての情報又は値に対して、合意されたレートの交換又は変換ファクタが適用される完全に区別可能なブロックチェーンプロトコルであり得る。

したがって、サイドチェーン化は、１つのブロックチェーンからのトークン、値、又はペイロードエントリが、予め定義された交換又は変換スキームを介して完全に別個のブロックチェーン内で安全に使用され、さらに、必要な場合には許容される方法でオリジナルのチェーンに戻され得るメカニズムである。慣例により、オリジナルのブロックチェーンは、メインチェーン又はプライマリブロックチェーンと呼ばれ、一方、ユーザがメインチェーンのトークン、値、又はペイロードを利用してそれらの中で取り引きすることを可能にする任意のさらなるブロックチェーンは、サイドチェーンと呼ばれる。例えば、パブリックブロックチェーンへの定義されたリンクを有するプライベートブロックチェーンがあり得、ゆえに、トークン、値、ペイロードデータをパブリックブロックチェーンとプライベートブロックチェーンの間で安全に移動することができる。

説明される実施形態によれば、フォークしたチェーンのプロトコルルールを定義するブロックチェーンプロトコル証明書１６６は、Ｐｙｔｈｏｎ、Ｒｕｂｙ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＰＨＰ、Ｓｃｈｅｍｅ、ＶＢＳｃｒｉｐｔ、Ｊａｖａ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴ、Ｃ＋＋、Ｃ＃、Ｃ、又はプロトコルルールを定義するためのカスタム作成言語などの、任意の関連プログラミング言語又はスクリプティング言語で開発されてもよい。

通常の作動条件下では、従来のブロックチェーンでさえ、時折自然にフォークするが、既知のブロックチェーンでは、最終的に１つの分岐のみがプライマリ合意チェーンを形成し得、全ての他のフォークは無視され又は切り捨てられなければならず、プライマリ合意ブロックチェーンのみが有効とみなされる。どのチェーンが有効であるかの合意は、最も長いチェーンを選択することにより達成されてもよく、ゆえに、これは、それを完成させることに最も多くのワークを投入されたブロックチェーンを表す。したがって、本明細書で説明されるフォークブロック１４３を利用して、許容される方法でフォークしたチェーンが作成され、フォークハッシュ１４９を介して承認されたフォークとして証明されることを可能にし、参加ノードがフォークを無視し又は切り捨てることを防止する必要がある。各ノードが、フォークしたブロックチェーンを独立して検証し得るため、それはちょうど、検証されたプライマリブロックチェーンが合意を有すると無視されないように、無視されないことになる。

図１Ｄは、説明される実施形態による、サイドチェーンについてさらなる詳細を有する別の例示的なアーキテクチャ１０３を示す。

より詳細には、親ブロックチェーン１８８（例えば、プライマリチェーン）からサイドチェーン１８９への対称的な双方向ペグの移転（two-way pegged transfer）を行うためのメカニズムがここに示されており、該サイドチェーン１８９は、ホスト組織１１０によりサポート及び提供される異なるブロックチェーンプロトコルでもよく、あるいはサイドチェーンは、ホスト組織１１０のサイドチェーン交換マネージャ１９３がノードとして参加し、サイドチェーンとのアクセス及びトランザクション能力を可能にするための、パブリック又はプライベートの、外部のブロックチェーンでもよい。それにもかかわらず、説明される実施形態によれば、親ブロックチェーン１８８とサイドチェーン１８９との間のチェーン間（inter-chain）移転は、各それぞれのブロックチェーンのルール及び条件に準拠して許容される方法で実行され得る。注目すべきことに、ここで記載されるように、各ブロックチェーンの視点は、ここで示されるサイドチェーン１８９がそれ自体をプライマリ又は親ブロックチェーンとみなし、示される親ブロックチェーン１８８を子ブロックチェーン又はサイドチェーンとみなし得るように交換不能である。それにもかかわらず、各ブロックチェーンは独立して動作し、さらに、それらの間でトークン、値、又はペイロード情報を交換するための定義された交換メカニズムを有する。

ここに示されるように、ホスト組織のサイドチェーン交換マネージャ１９３は、動作１５１において親ブロックチェーン１８８の出力として親チェーン資産を送信し得る。

親ブロックチェーン１８８資産に関連づけられた簡易支払立証（Simplified Payment Verification、ＳＰＶ）プルーフ１８１が出力として生成され、サイドチェーン１８９に通信される。ＳＰＶプルーフはワークの閾値レベルを含んでもよく、生成は所定の期間にわたり実施されてもよく、これは確認期間（confirmation period）１５２とも呼ばれることがある。チェーン間の移転の確認期間は、コイン、トークン、又は他の交換される値がサイドチェーン１８９に成功裏に移転され得る前に親ブロックチェーン１８８上でロックされる継続時間でもよい。この確認期間は、十分なワークが作成されることを可能にし得、それにより、次の待機期間におけるサービス拒否攻撃は、より計算的に困難になる。

例えば、１〜２日のオーダであり得る一例示的な確認期間を考える。確認期間は、そのような例では、より高いセキュリティと引き換えにクロスチェーン移転速度をトレードオフするサイドチェーンごとのセキュリティパラメータとして実現されてもよい。十分に困難なプルーフオブワーク条件が果たされ、適切なセキュリティを保証して双方のブロックチェーンの完全性を保護し、不正なトランザクションの可能性を否定する場合、一層短い他の確認期間が利用されてもよい。

親ブロックチェーン１８８上で作成される出力は、（例えば、親ブロックチェーン１８８の各ブロックのブロックチェーンプロトコル証明書部分に記憶される）ルール及び構成パラメータを介して、将来に出力により受信される資産の任意の支出、移転、又は消費が、親チェーン内の移転を管理するルールに追加でさらなる条件を負うという要件を指定してもよい。例えば、出力により受信された資産の任意の解放（release）は、宛先チェーンからのプルーフを立証するためのさらなる条件を必要としてもよく、例えば、宛先チェーンプルーフのルールが、宛先チェーンが資産を解放したことを示し、かつどこに対して資産が解放されたかを示すことを検証することなどである。親ブロックチェーン１８８上で出力を作成した後、ユーザは確認期間の終わりを待ち、一方、チェーン内（intra-chain）移転１５３は引き続き発生する。確認期間の終わりを待った後、次いで、トランザクションがサイドチェーン１８９上に作成され、親ブロックチェーン１８８からの出力を参照する。

次いで、サイドチェーンは、ホスト組織のブロックバリデータ１９２などのサイドチェーンバリデータサービスを使用し、親チェーン資産が作成され、かつ親チェーン内の十分なワークにより担保された（encumbered）ことを示すＳＰＶプルーフを提供される。次いで、サイドチェーンバリデータサービス（例えば、ホスト組織の利用可能なサービスにより実行される場合、ブロックバリデータ１９２）は、親ブロックチェーン１８８資産に関連づけられたＳＰＶプルーフが動作１５４においてＳＰＶプルーフにより示されるワークの必要な閾値レベルを満たし、親ブロックチェーン１８８資産に対応するサイドチェーン１８９資産が次いで生成されることを検証する。

生成されたサイドチェーン１８９の資産もまた、動作１５４において所定のコンテスト期間（contest period）の間保持されてもよく、その時間の間、親ブロックチェーン１８８の資産に関連づけられた再編成（reorganization）プルーフ１８３が親ブロックチェーンにおいて検出された場合、移転は無効にされる。

動作１５４におけるコンテスト期間は、新たに移転されたトークン、コイン、値、又はペイロードデータがサイドチェーン１８９で支出され、アクセスされ、又は消費されることがない継続時間であり得る。所定のコンテスト期間は、再編成の間、前にロックされたコイン、トークン、値、又はペイロードデータを移転することによる親ブロックチェーン１８８での二重支出のいかなる可能性も防止するために実現される。この遅延の間のいずれかの時点で、ロック出力が作成されたブロックを含まないより集約的なワークを有するチェーンを含む、新しいＳＰＶプルーフ１８４（「再編成プルーフ」として知られる）が公開された場合、変換は、遡及的に無効にされる。再編成プルーフが検出されない場合、サイドチェーン資産は解放されてもよい。サイドチェーン上の全ての参加ノードは、可能であれば、再編成プルーフを作成するインセンティブを有し、なぜならば、悪いプルーフが認められた結果、全てのサイドチェーントークン、コイン、値、又はサイドチェーン１８９により記憶されたペイロードデータの真正性における信頼の価値を低下させるためである。

上記と同様に、動作１５６における一例示的なコンテスト期間も、１〜２日のオーダであり得る。これらの遅延を回避するために、ユーザは代わりに、流動性のある市場が利用可能である限り、代替可能な移転のためにアトミックスワップを採用し、使用してもよい。交換された資産が、ユニーク又はあまり一般的でないトークン、値、ペイロードデータである場合、潜在的に長い１〜２日の待機期間の必要にもかかわらず、アトミックスワップは実行不可能であり、代わりにサイドチェーン移転が生じなければならない。

サイドチェーン資産の最終的な解放に対して、親チェーン資産に対応するサイドチェーン資産は、次いで、サイドチェーン内で、１回以上、サイドチェーン１８９のチェーン内移転１５３を移転され、あるいは消費され得る。親ブロックチェーン１８８上でロックされている間、資産は、サイドチェーン内で、親ブロックチェーン１８８とのいかなるさらなる相互作用も必要なく自由に移転可能であり、ゆえに、サイドチェーン１８９が再度、完全に独立して動作することを可能にする。上記にもかかわらず、サイドチェーン資産は、そのアイデンティティを親チェーントークン、コイン、値、又はペイロードデータとして保有し、したがって、必要が生じた場合、サイドチェーン資産が発生した元の発生ブロックチェーン１８８に戻されてもよい。特定の実施形態において、移転は単一のホップのみに委託され、それにより資産は、サイドチェーン１８９に移転され、次いで再度別のサイドチェーンに移転されることはできず、その場合、ソースの不明瞭化を防止することが必要である。このような制限は、選択された特定のブロックチェーンプロトコルと、親ブロックチェーン１８８及びサイドチェーン１８９の間に確立された定義交換合意（例えば、ペグ条件（pegging conditions））に依存する。

親ブロックチェーン１８８内のサイドチェーン資産を引き換える（redeem）ことが必要になった場合、サイドチェーン資産は、動作１５７に示されるように、サイドチェーンの出力に送られ得る。ゆえに、サイドチェーン資産に関連づけられたＳＰＶプルーフ１８２が生成され、親ブロックチェーン１８８に通信される。ホスト組織１１０のブロックバリデータ１９３などの親チェーンバリデータサービスは、動作１５６においてサイドチェーン資産に関連づけられたＳＰＶプルーフ１８２を検証し得る。サイドチェーン１８９資産に関連づけられた検証されたＳＰＶプルーフ１８２は、例えば、サイドチェーン資産に関連づけられたＳＰＶプルーフ１８２が、サイドチェーン資産に関連づけられたＳＰＶプルーフ１８２により示されるワークの閾値レベルを満たすという検証を含んでもよい。

前述のように、サイドチェーン資産に関連づけられた親チェーン資産は、ステップ１５６において第２の所定のコンテスト期間の間保持され得、その間、親チェーン資産の解放は、サイドチェーン資産に関連づけられた再編成プルーフ１８３がサイドチェーンにおいて検出された場合、動作１５８において拒否される。親チェーン資産は、サイドチェーン資産に関連づけられた再編成プルーフ１８３が検出されない場合、解放されてもよい。

再編成プルーフ１８３が受信された後、第２のＳＰＶプルーフ１８４に関して検証の失敗が発生した場合、サイドチェーン資産に関連づけられた第２のＳＰＶプルーフ１８４は、動作１５９において第３の所定のコンテスト期間中に親ブロックチェーン１８８により受信され、検証され得る。親ブロックチェーン１８８資産は、サイドチェーン資産に関連づけられた再編成プルーフが第３の所定のコンテスト期間中に検出されない場合、解放されてもよく、その後、親チェーン資産は、親ブロックチェーン１８８フローの最右端に示される図示のチェーン内移転１５３を介して親チェーン内で自由に移転できる。

ペグのサイドチェーンは多くの異なるブロックチェーンからの資産を運ぶことがあるため、他の外部のブロックチェーンのセキュリティについて仮定を行うことは問題がある可能性がある。したがって、特定の実施形態によれば、異なる資産はサイドチェーン内で（明示的な取引によるものを除き）交換可能でないことが要求される。さもなければ、悪意のあるユーザが潜在的に、価値のない資産を有する価値のないチェーンを作成することにより不正な取引を実行し、次いで、価値のないチェーンからの価値のない資産をプライマリブロックチェーン１８８に、又はプライマリブロックチェーン１８８が相互作用して交換を行うサイドチェーン１８９に続けて移動する可能性がある。これは、価値のないチェーンがサイドチェーンとのペグ交換合意を保証することを前提とする。しかしながら、サイドチェーン１８９のルール、構成選択肢、及びセキュリティスキームは、（サイドチェーンが外部のサイドチェーンであり、ホスト組織１１０により提供される別のブロックチェーンプロトコルでないと仮定すると）親ブロックチェーン１８８により制御されないため、相互作用されるサイドチェーン１８９がそのような脆弱性を含まないことを、単純に、確信を持って知ることができない。この潜在的なセキュリティ脆弱性を否定するために、サイドチェーン１８９は、ペグ交換合意により、図１Ｂ、要素１６７で示されるブロックチェーンプロトコルブロックのブロックタイプ部分により示されるように、完全に別個の親ブロックチェーンからの資産を完全に別個の資産タイプとして取り扱うように要求されてもよい。

対称的な双方向ペグのサイドチェーン移転では、特に、親ブロックチェーン１８８がホスト組織で提供される場合、及び、サイドチェーンが、ホスト組織がサイドチェーン交換マネージャノード１９３を介した参加ノードに過ぎない外部のサイドチェーンである場合、親ブロックチェーン１８８とサイドチェーン１８９の双方が、互いにおいてデータのＳＰＶ検証サービスを実行してもよい。親ブロックチェーン１８８クライアント（例えば、参加ノード）は、あらゆるサイドチェーンを観察するわけではないため、ユーザは、サイドチェーンからのプルーフオブワークを親チェーンにインポートして所有を証明する。対称的な双方向ペグでは、その逆もまた当てはまる。例えば、親ブロックチェーン１８８としてビットコインを使用するために、このようなＳＰＶプルーフを認識及び検証する拡張スクリプトが利用されてもよい。このようなトランザクションを容易にするために、ＳＰＶプルーフは、ビットコイントランザクションペイロード内に適合するようにサイズが十分小さくなければならない。しかしながら、このような変更は、前述のように、ペグのサイドチェーントランザクションに関与しないトランザクションに影響を与えることなく、フォークトランザクションとして実現されてもよい。言い換えると、上述のように対称的な双方向ペグのサイドチェーンを使用すると、ビットコイン内で有効とみなされる任意のトランザクションに対して、必ずしもさらなる制限は課されないことになる。

このようなペグのサイドチェーントランザクションの使用により、独立したブロックチェーンは、チェーンが最初に作成されたときには存在しなかった資産を含む多くの資産をサポートするのに十分な柔軟性を有するようにされる。これらの資産の各々は、それが移転された元のブロックチェーンでラベル付けされて、移転が正しく解消される（unwound）（例えば、戻される）ことを保証してもよい。

特定の実施形態によれば、コンテスト期間の継続時間は、親チェーンとサイドチェーンとの相対的なハッシュ能力に応じて作られてもよく、それにより、受信サイドチェーン（又は、入ってくる移転を有する親ブロックチェーン）は、その自身のプルーフオブワークの１日分のＳＰＶプルーフを前提としてのみトークン、コイン、値、又はデータペイロードをアンロックしてもよく、該プルーフオブワークは、例えば、送信ブロックチェーンのプルーフオブワークの数日に対応し得る。ゆえに、特定のサイドチェーンのブロックチェーンプロトコル実装のセキュリティパラメータは、各特定のサイドチェーンの実装に合わせられてもよい。

図２〜図４は、本発明の実施形態における分散台帳技術を実現する方法を示すフロー図を示す。実施形態では、ブロックチェーンビジネスネットワーク及びブロックチェーンベースのアプリケーションを構築するツールを含む１つ以上のブロックチェーンフレームワーク実装に基づいて、ホストされたブロックチェーンプラットフォームが提供される。ホストされたブロックチェーンプラットフォームは、本特許出願の譲受人のようなクラウドベースのコンピューティング環境サービスプロバイダの顧客にブロックチェーンアズアサービス（Blockchain as a Service、ＢａａＳ）を提供することができ、それにより、顧客は、付随するハードウェア及びソフトウェアを含むワーキングブロックチェーン及び合意モデルを構成及びセットアップする必要がない。説明される方法は、ハードウェア（例えば、回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば、処理デバイス上で実行される命令）を含み得る処理論理により実行されて、本明細書に記載のシステム及び方法に従って設計、定義、取り出し、パース、持続、公開、ロード、実行、動作、受信、生成、記憶、維持、作成、返信、提示、インターフェース、通信、伝送、クエリ、処理、提供、決定、トリガ、表示、更新、送信などの様々な動作を実行し得る。例えば、図１Ａ以下に示されるホストされたコンピューティング環境１１１、そのデータベースシステム１３０、及び本明細書に記載する他のシステム及びコンポーネントは、説明される方法論を実現することができる。以下で列挙される論理ブロック及び／又は動作のいくつかは、特定の実施形態に従って任意である。提示される論理ブロックの番号付けは明りょうさのためであり、様々な論理ブロックが発生しなければならない動作の順序を規定することは意図されない。

本発明のいくつかの実施形態は、許可ありの、又はプライベートの、ブロックチェーンベースの分散台帳技術に関連して動作し得る。一実施形態において、ノードのコンソーシアムが許可ありのブロックチェーンに参加し、各ノードは、コンソーシアム内の異なる当事者（party）において、又は該当事者により運用される。例えば、コンソーシアムは、いくらかの数の銀行若しくは金融機関、又は保険会社を含んでもよい。いずれにしても、コンソーシアムのメンバは各々、そのそれぞれノードを介してコンソーシアムの他のメンバと通信し、許可ありのブロックチェーンに対する資産及び／又は資産を伴うトランザクションを追加し、かつ／あるいは検証する。

一実施形態において、ノードは、許可ありのブロックチェーンにコミットされ得る資産及び／又はトランザクションのタイプに関する情報を維持するデータベース、オンデマンドデータベースサービス、又は分散データベースシステムなどのデータストアへのアクセスを有し、これは、本明細書において以下で時にトランザクションタイプデータベースと呼ばれる。さらに、データストアは、合意プロトコル又は合意プロトコルタイプを各トランザクションタイプに関連づける。一実施形態において、１つ以上のノードがデータベースを維持し、一方、他のノードは単にデータベースへの読み出しアクセスを有する。他の実施形態において、例えば、クラウドコンピューティングサービスプロバイダのクラウドコンピューティングシステム内のアプリケーションサーバ又はアプリケーションサーバのクラスタ上で実行するブロックチェーンベースの分散台帳プラットフォームホストが、例えば、クラウドコンピューティングサービスプロバイダによりサポートされるブロックチェーンアズアサービス（ＢａａＳ）アプリケーションの一部として、データベースをセットアップし、維持してもよい。このような実施形態において、データベースはアプリケーションサーバにアクセス可能であり、コンソーシアム内のノードは、ブロックチェーンプラットフォームホストに要求を送信し、ブロックチェーンプラットフォームホストから応答を受信することによりデータベースにアクセスする。一実施形態において、各々がクラウドコンピューティングサービスの顧客組織又はコミュニティ内で、又はそれとして表されるコンソーシアム内の１つ以上のノードが、クラウドコンピューティングサービスのサブスクライバとしてデータベースにアクセスしてもよい。いくつかの実施形態において、データベース内の情報は、クラウドコンピューティング環境内のノードによる、又は該ノードのための迅速な読み出しアクセスのために、クラウドコンピューティングサービスプロバイダのクラウドコンピューティングシステム内のブロックチェーンプラットフォームホスト、アプリケーションサーバ、又はアプリケーションサーバのクラスタによりキャッシュされてもよい。

特定の資産又はトランザクションを含むブロックがブロックチェーンに追加されるべきとき、トランザクションタイプデータベースは、ブロックチェーンに追加されるべき特定の資産又はトランザクションのタイプを使用してクエリされ、特定の資産若しくはトランザクション、又は特定の資産若しくはトランザクションを含むブロックをブロックチェーンにコミットするために使用されるべき対応する合意プロトコルタイプを決定する。例えば、データベースにおいて、「ローン」のトランザクションタイプが「プルーフオブステーク」（ＰｏＳ）の合意プロトコルタイプに関連づけられてもよく、「文書」の資産タイプが「ビザンチンフォールトトレラント」（Byzantine Fault Tolerant、ＢＦＴ）の合意プロトコルタイプに関連づけられてもよく、「通貨」の資産又はトランザクションタイプが「プルーフオブワーク」（ＰｏＷ）の合意プロトコルタイプに関連づけられてもよく、データベース内の他の列挙されていないトランザクションタイプの場合に使用されるデフォルトトランザクションタイプが、デフォルト合意プロトコルタイプ、例えばＰｏＳに関連づけられてもよい。

ゆえに、上述の例で続けると、タイプ「ローン」を有する特定のトランザクションを有するブロック又はその中のトランザクションがブロックチェーンに追加されるべきとき、ブロック又はその中のトランザクションをブロックチェーンに対してコミットするために使用される合意プロトコルタイプはＰｏＳであり、「文書」タイプを有する特定の資産を有するブロック又はその中のトランザクションがブロックチェーンに追加されるべきとき、ブロック又はその中のトランザクションをブロックチェーンに対してコミットするために使用される合意プロトコルタイプはＢＦＴであり、データベース内で規定されていないトランザクションタイプを有する特定のトランザクションを有するブロック又はその中のトランザクションがブロックチェーンに追加されるべきとき、デフォルト合意プロトコルタイプのＰｏＳが使用されて、ブロック又はその中のトランザクションをブロックチェーンに対してコミットする。

図２は、説明される実施形態による、分散台帳技術の方法を実現する方法２００を示すフロー図を示す。

図２を参照し、ブロック２０５において、分散台帳技術（ＤＬＴ）プラットフォームホスト、例えばブロックチェーンベースのＤＬＴプラットフォームホスト、又は単にブロックチェーンプラットフォームホストの処理論理が、ブロックチェーンに新しいブロックを追加する要求を受信する。新しいブロックは、複数のトランザクションを典型的に含む。要求はトランザクションタイプを指定し、あるいはトランザクションタイプが指定されていない場合、デフォルトトランザクションタイプが仮定又は適用される。

一実施形態において、要求は、コンソーシアムを構成するピアツーピアネットワーク内のノードのうち１つから受信される。一実施形態において、トランザクションタイプは、ノードにより送信されるブロックチェーンプロトコルパケットで指定される。一実施形態において、トランザクションタイプは、ブロックチェーンプロトコルデータパケットのペイロード部分内のアプリケーション固有のデータフィールドで指定され、その場合、ブロックチェーンプロトコル自体は、指定されているトランザクションタイプを認識せず、パケットのペイロード部分内のトランザクションタイプの検出及び復号は、ブロックチェーンプラットフォームホスト上で実行される論理次第である。別の実施形態において、トランザクションタイプは、ブロックチェーンプロトコルデータパケットのヘッダ部内のフィールドで指定され、その場合、ブロックチェーンプロトコル自体が、指定されているトランザクションタイプを認識する。

論理ブロック２１０において、ホストは、要求からトランザクションタイプを取得し、トランザクションタイプデータベースにクエリし（queries）、ブロック又はその中のトランザクションをブロックチェーンに対してコミットする際に使用すべき対応する合意プロトコルタイプを返す。詳細には、ホストは、指定されたトランザクションタイプについてデータベースを検索し、指定されたトランザクションタイプをデータベース内のレコード中に見つけた後、該レコードから指定されたトランザクションタイプに関連づけられた選択された合意プロトコルを取得する。次いで、この選択された合意プロトコルタイプは、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求の検証に使用するために、コンソーシアムのノードに通信される。論理ブロック２１５において、コンソーシアム内のノードが、選択された合意プロトコルに従ってブロックチェーンにブロック又はその中のトランザクションを追加するための合意に達し、そのことをホストに通信したとき、ホストは、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を検証し、又は該要求の検証を受信する。最後、論理ブロック２２０において、ホストは、検証された新しいブロック又はその中のトランザクションをブロックチェーンに追加する。

図３は、本明細書に記載される他のフロー図の動作と関連して動作し得る、クラウドベースのコンピューティング環境において分散台帳技術のためのインテリジェントな合意、スマートな合意、及び重み付き合意のモデルを実現する方法３００を示すフロー図を示す。

図３の３００に示される本発明の別の実施形態によれば、ブロック３０５において、分散台帳技術（ＤＬＴ）プラットフォームホストの処理論理が、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を受信する。新しいブロックは、複数のトランザクションを典型的に含む。要求はトランザクションタイプを指定し、あるいはトランザクションタイプが指定されていない場合、デフォルトトランザクションタイプが仮定又は適用される。

一実施形態において、要求は、コンソーシアムを構成するピアツーピアネットワーク内のノードのうち１つから受信される。一実施形態において、トランザクションタイプは、ノードにより送信されるブロックチェーンプロトコルパケットで指定される。この実施形態において、トランザクションタイプは、ブロックチェーンプロトコルデータパケットのペイロード部分内のアプリケーション固有のデータフィールドで、又はブロックチェーンプロトコルデータパケットのヘッダ部内のフィールドで指定されてもよい。いずれの場合も、論理ブロック３１０において、ホストは、要求からトランザクションタイプを取得し、機械学習ベースのソフトウェアエージェントを連動させて、指定されたトランザクションタイプに基づいてブロック又はその中のトランザクションをブロックチェーンに対してコミットする際に使用すべき複数の合意プロトコルタイプのうちの１つを選択する。この機械学習ベースのソフトウェアエージェントは、ブロックチェーンプラットフォーム、ブロックチェーンプラットフォームホスト、クラウドコンピューティング環境プラットフォーム、クラウドコンピューティングサービスプラットフォーム内のアプリケーションサーバ又はサーバクラスタに、例えば、ビジネスプロセス及びコンソーシアムデータなどの様々な選択されたファクタに基づいて予測及び推奨を配信する人工知能のレイヤとして構築されてもよい。この人工知能レイヤは、指定されたトランザクションタイプに基づいてブロック又はその中のトランザクションをブロックチェーンに対してコミットする際に使用すべき複数の合意プロトコルタイプのうち１つの選択を自動化するためのインサイト（insights）を使用してもよい。一実施形態において、この人工知能レイヤは、セールスフォースドットコム（登録商標）（salesforce.com）のアインシュタイン（Einstein）、セールスフォースのクラウドコンピューティングサービスアーキテクチャに組み込まれた人工知能（ＡＩ）レイヤにより提供されてもよい。

一実施形態において、機械学習ベースのソフトウェアエージェントは強化学習ベースのソフトウェアエージェントであり、それは、指定されたトランザクションタイプなどの１つ以上のファクタに基づいて、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を検証するために使用すべき複数の合意プロトコルのうち１つを、あるいは同じトランザクションタイプを指定する、新しいブロック又はその中のトランザクションをブロックチェーンに追加する１つ以上の前の要求を検証するために選択された合意プロトコルを選択する。

選択された合意プロトコルタイプは、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求の検証に使用するために、コンソーシアム内のノードに通信される。詳細には、一実施形態において、分散台帳技術プラットフォームホストは、この情報を提供するブロックチェーンプロトコルデータパケットのペイロード部分内にアプリケーション固有データフィールドを含むブロックチェーンプロトコルパケットを送信する。別の実施形態において、ブロックチェーンプロトコルデータパケットのヘッダ部分内のフィールドが、選択された合意プロトコルを指定してもよい。論理ブロック３１５において、コンソーシアム内の参加ノードが、選択された合意プロトコルに従ってブロックチェーンにブロック又はその中のトランザクションを追加するための合意に達し、そのことをホストに通信したとき、ホストは、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を検証し、又は該要求の検証を受信する。換言すれば、コンソーシアム内の全てのノードが必ずしも合意プロトコルに参加するわけではない。この目的のために、論理ブロック３１５において、ホストが、コンソーシアム内の参加ノードが選択された合意プロトコルに従ってブロックチェーンにブロック又はその中のトランザクションを追加するための合意に達したことの学習に基づいて、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を検証する前に、論理ブロック３１１は任意で、ピアツーピアネットワーク内のどのノードが選択された合意プロトコルに参加すべきかを選択する。最後、論理ブロック３２０において、ホストは、検証された新しいブロック又はその中のトランザクションをブロックチェーンに追加する。

一実施形態において、選択された合意プロトコルに参加すべきピアツーピアネットワーク内のノードを選択することは、例えばブロックチェーンプラットフォーム管理者により予め定義及び構成されたファクタのルールベースのセットに従って論理ブロック３１１により、及び／又は、オンザフライである時間にわたり動作する機械学習ベースのソフトウェアエージェント、例えば、どのノードが選択された合意プロトコルに参加すべきかを決定する際に同じルールベースのファクタのうち一部又は全部の考慮を自動化する強化学習ベースのソフトウェアエージェントを連動させることにより、達成されてもよい。任意の関連ファクタが、どのノードが合意プロトコルに参加するかを決定する際に使用されてもよく、例えば、選択された合意プロトコル自体、特定のノードのコンピューティングリソース、特定のノードがコンソーシアム又は選択された合意プロトコルにおいて有する利害関係（stake）、特定のノードが有する関連（ドメイン）知識、その知識がブロックチェーン又はコンソーシアムに関して内部（オンチェーン）であるか外部（オフチェーン）であるか、選択された合意プロトコルに参加する際の、速度の点か正確さの点か、又はこれらが欠如しているかどうかの、特定のノードの以前又は過去のパフォーマンス、ブロックチェーンに追加される新しいブロックのブロック番号、新しいブロック内のトランザクションの数、ブロックのサイズ、及びブロックチェーンに追加されるブロック内の資産又はトランザクションの信用又は非信用性（fiduciary or nonfiduciary nature）が含まれる。上述したファクタの多くは、どのノードが選択された合意プロトコルに参加するかを選択する際に、同時に、順次、階層的に、又は反復的に考慮されてもよい。

これらの要因に関する情報は、ブロックチェーンプロトコル自体の中で、例えば、オンチェーンメッセージングプロトコルに従って、あるいはブロックチェーンプロトコルの外で、人間若しくは従来の（オフチェーン）通信プロトコル、サイドチェーンを用いて、又はブロックチェーンプロトコルデータの、制御の、又はメッセージのパケットのペイロード部分で通信されるアプリケーション固有のデータ若しくはメッセージとしてのいずれかで、ノード及びブロックチェーンプラットフォームホストにより、及びこれらの間で通信されてもよい。さらに又は代わりに、ノードは、ランダム選択スキーム、ラウンドロビンスキーム、重み付きラウンドロビンスキーム等に基づいて参加するように選択されてもよい。

図４は、説明される実施形態による、分散台帳技術の方法を実現する方法４００を示すフロー図を示す。

図４の４００に示される別の実施形態によれば、ブロック４０５において、ブロックチェーンプラットフォームホストの処理論理が、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を受信する。新しいブロックは、複数のトランザクションを典型的に含む。一実施形態において、要求は、コンソーシアムを構成するノードのピアツーピアネットワーク内のノードのうち１つから受信される。

論理ブロック４１０において、ホストは、ピアツーピアネットワーク内のノードのうち１つ以上の各々から、要求に応答して、又はブロックチェーンプラットフォームホストにより発行された投票の要求に応答して、ブロックチェーンに新しいブロック又はその中のトランザクションを追加するための重み付き投票（weighted vote）を受信する。これらのノードは、要求を生成したノードによりブロードキャストされたブロックチェーンプロトコルパケットを介して、あるいは、コンソーシアムの他のノード、又はブロックチェーンプラットフォームホストにより送信された投票の要求と関連して又は組み合わせて要求の通知を提供するブロックチェーンプラットフォームホストと通信することにより、要求を学習する。論理ブロック４１５において、ホストは、受信した重み付き投票の合計が閾値を超えているとき、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求を検証し、あるいは該要求の検証を受信する。最後、論理ブロック４２０において、ホストは、検証された新しいブロック又はその中のトランザクションをブロックチェーンに追加する。

図４の４００に示されるプロセスの一実施形態によれば、ノードのコンソーシアムは、プライベートの、又は許可ありのブロックチェーンに参加する。各ノードは、例えば、ノードがブロックチェーンにおいて新しいブロックに追加することができるトランザクション又はトランザクションのタイプに関するドメイン（一般）知識に基づいて、その投票に与えられる重みを割り当てられる。ノードがブロックチェーンの新しいブロックにトランザクションを追加できる前、あるいはブロックチェーンにトランザクションを含む新しいブロックを追加できる前に、コンソーシアム内の他のノードは、ブロックチェーンの新しいブロックにトランザクションを追加すること、及び／又はブロックチェーンに新しいブロックを追加することについて投票する。ノードの過半数がトランザクションに合意し、かつ／あるいは新しいブロックが追加されるべきとき、トランザクション及び／又は新しいブロックが追加される。ノードは、プライベートブロックチェーンに参加しているノードのうち１つ以上の投票に基づいて「過半数（majority）」が取得され又は否定され得るように、すなわち、ブロックチェーンに参加しているノードの全部より少数から過半数が取得され得るように重み付けされる。

この実施形態によれば、コンソーシアム内の当事者は、例えば、当事者のドメイン知識、及び／又は、例えば、当事者の別のブロックチェーン又はサイドチェーンへの参加を含む他の基準に基づいて、コンソーシアム内の各ノードを割り当てる重みｗに合意する。コンソーシアム内のノードの合計重みＷは、個々のノード重みの和、ｗ_１＋ｗ_２＋．．．ｗ_ｎに等しく、ｎは、コンソーシアム内のノード数である。一実施形態において、いずれか１つのメンバの重みｗ、又はｗ／Ｗの比は、特定の閾値を超えても超えなくてもよい。各ノードの重みは、それぞれのノードの投票に起因する。投票したノードの重みの合計が特定の閾値を超えている場合、トランザクション／新しいブロックが検証され、ブロックチェーンに追加される。詳細には、投票に起因する合計重みＷが、ブロックチェーンの合意に達するための閾値（例えば、コンソーシアムにより合意された、ｗ／Ｗのパーセンテージの観点での相対多数、過半数、圧倒的多数、又はｗの絶対値）を満たし又は超えている場合、トランザクション／新しいブロックが追加される。この実施形態において、ブロックチェーン内のノードは、ブロックチェーンにトランザクション及び／又は新しいブロックを追加することについて全員一致の合意に達する必要はなく、実際、閾値が満たされた後、ノードは、投票プロセスへの参加を開始又は継続する必要はない。

一実施形態において、少なくとも最小数のノードｋが、ブロックチェーン内の新しいブロックにトランザクションを追加すること、又はブロックチェーンにトランザクションを含む新しいブロックを追加することについて投票して、詐欺又は二重支出のリスクを軽減し、あるいは大きい重みｗを有する１つのノード又は集合的に大きい重みを有するノードのスモールグループが投票の結果を制御することを防止する。一実施形態において、投票に参加するノード数ｋ、又はｋ／ｎの比率は、最小閾値を満たさなければならない。

方法２００、３００、及び４００の別の実施形態によれば、ブロックチェーンに新しいブロックを追加する要求を受信することは、ピアツーピアネットワーク内の複数のノードのうち１つから、ブロックチェーン内の新しいブロックにトランザクションを追加する要求を受信することを含む。

方法２００、３００、及び４００の別の実施形態によれば、選択された合意プロトコルに従って合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証することは、選択された合意プロトコルに従ってピアツーピアネットワーク内の複数のノード間で合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証することを含む。

方法２００、３００、及び４００の別の実施形態によれば、複数のトランザクションタイプのうち１つを指定する要求を受信することは、ブロックチェーンプロトコルデータパケットのペイロード部分内のアプリケーション固有のデータフィールドと、トランザクションタイプを指定するブロックチェーンプロトコルデータパケットのヘッダ部分内のフィールドと、のうち１つを含むブロックチェーンプロトコルパケットを受信することを含む。

方法２００、３００、及び４００の別の実施形態によれば、指定されたトランザクションタイプに応答して、ブロックチェーンに新しいブロックを追加する要求を検証するための複数の合意プロトコルのうち１つを選択することは、複数のトランザクションタイプの各々を複数の合意プロトコルのうち１つに関連づけるデータストアにおいて指定されたトランザクションタイプについて検索することと、検索に応答して、指定されたトランザクションタイプに関連づけられた選択された合意プロトコルを取得することを含む。

方法２００、３００、及び４００の別の実施形態によれば、指定されたトランザクションタイプに応答して、ブロックチェーンに新しいブロックを追加する要求を検証するための複数の合意プロトコルのうち１つを選択することは、強化学習ベースのソフトウェアエージェントが、ブロックチェーンに新しいブロックを追加する要求を検証するための複数の合意プロトコルのうち１つを選択することと、分散台帳技術プラットフォームホストが、ブロックチェーンプロトコルデータパケットのペイロード部分内のアプリケーション固有のデータフィールドと、複数の合意プロトコルのうち選択された１つを指定するブロックチェーンプロトコルデータパケットのヘッダ部分内のフィールドと、のうち１つを含むブロックチェーンプロトコルパケットを送信することを含む。

方法２００、３００、及び４００の別の実施形態によれば、強化学習ベースのソフトウェアエージェントは、指定されたトランザクションタイプと、同じトランザクションタイプを指定する、ブロックチェーンに新しいブロックを追加する１つ以上の前の要求を検証するために選択された合意プロトコルと、のうち１つ以上に基づいて、ブロックチェーンに新しいブロックを追加する要求を検証するための複数の合意プロトコルのうち１つを選択する。

方法２００、３００、及び４００の別の実施形態によれば、選択された合意プロトコルに従って合意が達成られたとき、ブロックチェーンに新しいブロックを追加する要求を検証することは、選択された合意プロトコルに従ってピアツーピアネットワーク内の複数のノードのうち参加ノード間で合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証することを含む。

方法２００、３００、及び４００の別の実施形態によれば、選択された合意プロトコルに従ってピアツーピアネットワーク内の複数のノードのうち参加ノード間で合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証することは、複数のルールと強化学習ベースのソフトウェアエージェントとのうち１つに従って、選択された合意プロトコルに参加すべきピアツーピアネットワーク内のノードを選択することを含む。

方法２００、３００、及び４００の別の実施形態によれば、選択された合意プロトコルのうち１つは、ピアツーピアネットワーク内の複数のノードのうち１つ以上の各々から、要求に応答して、ブロックチェーンに新しいブロックを追加するための重み付き投票を受信することと、受信した重み付き投票の和が閾値を超えているとき、ブロックチェーンに新しいブロックを追加する要求を検証することを含む。

方法２００、３００、及び４００に関連する特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令は、少なくともプロセッサ及びメモリをその中に有する分散台帳技術プラットフォームホストにより実行されたときにシステムに、以下の動作：ブロックチェーンに新しいブロックを追加する要求を受信することであって、新しいブロックは複数のトランザクションを含み、要求は複数のトランザクションタイプのうち１つを指定する、ことと、指定されたトランザクションタイプに応答して、ブロックチェーンに新しいブロックを追加する要求を検証するための複数の合意プロトコルのうち１つを選択することと、選択された合意プロトコルに従って合意が達せられたとき、ブロックチェーンに新しいブロックを追加する要求を検証することと、ブロックチェーンに新しいブロックを追加する要求の検証に応答して、ブロックチェーンに新しいブロックを追加することと、を実行させる。

図５は、説明される実施形態による、クラウドベースのコンピューティング環境においてｑｕｉｐｃｈａｉｎを使用して文書インターフェース及びコラボレーションを実現する方法５００を示すフロー図を示す。

図５のフロー図を参照し、ブロックチェーンベースの分散台帳を使用して、共有された文書又はコンテンツの非中央集権的な複製されたストレージを提供し、それにより文書の監査性と不変性を向上させる文書コラボレーションシステムについて説明する。論理ブロック５０５において、分散台帳技術（ＤＬＴ）プラットフォームホスト、例えばブロックチェーンベースのピアツーピアネットワーク内のノードが、協働文書（collaborative document）処理アプリケーションから協働文書又はその一部を受信する。一実施形態において、論理ブロック５０５は、協働文書処理アプリケーションのユーザインターフェースを介して第１のコラボレータ（collaborator）から協働文書又はその一部を受信する。ユーザインターフェースは、ユーザクライアントデバイス１０６上で実行されるデスクトップ協働文書処理アプリケーションにより、クライアントユーザデバイス１０６上で提供されてもよく、これは、次いで、ホスト組織１１０において実行されるＤＬＴプラットフォームホストと通信する。別の実施形態において、ユーザインターフェースは、ホストされたコンピューティング環境１１１上で実行されるウェブサービスベースの協働文書処理アプリケーションにより、クライアントユーザデバイス１０６上で提供されてもよく、これは、次いで、ホスト組織１１０において、ホストされたコンピューティング環境１１１内、又はホスト組織１１０内の別個のホストされたコンピューティング環境内のいずれかで実行されるＤＬＴプラットフォームホストと通信する。

一実施形態において、第１のコラボレータから受信される協働文書に関する入力は、これらに限られないが以下を含む：第１のコラボレータの識別子（例えば、電子メールアドレス又はユーザログイン識別子）；第１のコラボレータが協働すべき又は協働しようとしている１以上のさらなるコラボレータの識別；第１のコラボレータとさらなるコラボレータとの間で交換されるメッセージ（例えば、文書に関するコメント若しくは質問、又は文書と共に存在するコラボレーションメモ、又は文書のバージョン情報）；文書自体、又はその一部（例えば、章、ページ、段落、節、セクション、セグメント等）；協働文書の、第１のコラボレータの署名；又は、文書又はその一部に関するトランザクション（例えば、第１のコラボレータが、文書の作成、修正、若しくは削除、又は文書内のその一部の作成、修正、若しくは削除を要求する）、のうち１つ以上に関する情報。

論理ブロック５１０において、ホストは、協働文書又はその一部を含むブロックチェーン資産を作成する。さらに、論理ブロック５１５において、ホストは、ブロックチェーン資産及びブロックチェーン資産識別子を含むブロックチェーントランザクションを作成する。一実施形態において、ブロックチェーン資産識別子は、協働文書に実際に署名したユーザ、コラボレータに関連づけられる。一実施形態において、ホストは、ブロックチェーン資産識別子を、ユーザが相互作用する協働文書システム又はクラウドコンピューティング環境から取得されたユーザに関する情報に関連づける。例えば、ユーザは、クラウドコンピューティング環境及び／又は協働文書処理システムにおいてユーザを識別するログイン、又は特定の暗号鍵若しくはセキュリティ情報を有してもよい。

論理ブロック５２０において、ホストは、ブロックチェーン上の循環（circulation）にブロックチェーントランザクションをブロードキャストし、ブロックチェーンにおけるブロックチェーントランザクションのブロードキャストに応答してブロックチェーントランザクションの検証についてリッスンする（listens）。論理ブロック５２５において、ホストは、検証を受信する。一実施形態において、ブロックチェーン上の循環へのブロックチェーントランザクションのブロードキャストに応答した、ブロックチェーントランザクションの検証の受信は、以下でさらに説明されるように、協働文書の第１のコラボレータの署名を立証した協働文書の第２のコラボレータからブロックチェーントランザクションの検証を受信することを含む。その後、論理ブロック５３０において、ＤＬＴホストは、ブロック内の検証されたブロックチェーントランザクションをブロックチェーンに対してコミットする。

さらに別の実施形態によれば、方法５００は、協働文書処理アプリケーションのユーザインターフェースを介して第１のコラボレータから協働文書に関する入力を受信することをさらに含み、協働文書処理アプリケーションからの協働文書の受信は、ＤＬＴホストにより、協働文書処理アプリケーションから協働文書に関する入力を受信することを含む。

方法５００の別の実施形態によれば、第１のコラボレータからの協働文書に関する入力の受信は、第１のコラボレータの識別子、１以上のさらなるコラボレータの識別、第１のコラボレータとさらなるコラボレータとの間で交換されるメッセージ、協働文書の全部又は一部、協働文書の第１のコラボレータの署名、及び協働文書の全部又は一部に関するトランザクション｛例えば、挿入、修正、削除｝のうち、１つ以上に関する入力を受信することを含む。

方法５００の別の実施形態によれば、ブロックチェーン上の循環へのブロックチェーントランザクションのブロードキャストに応答して、ブロックチェーントランザクションの検証を受信することは、協働文書の第１のコラボレータの署名を立証した協働文書の第２のコラボレータからブロックチェーントランザクションの検証を受信することを含む。

別の実施形態によれば、方法５００はさらに、第２の分散台帳技術（ＤＬＴ）ホストにより実行され、第２のホストはその中に少なくともプロセッサ及びメモリを有し、当該方法は、ブロックチェーン上で循環へブロードキャストされたブロックチェーントランザクションを受信することと、受信したブロードキャストされたブロックチェーントランザクションからの協働文書又はその一部を協働文書処理アプリケーションに提供することと、協働文書の第１のコラボレータの署名を立証した協働文書の第２のコラボレータから協働文書に関する検証を受信することと、検証されたブロックチェーントランザクションをブロックチェーン上の循環にブロードキャストすることを含む。

方法５００の別の実施形態によれば、ブロックチェーンにおけるブロックチェーントランザクションのブロードキャストに応答して、ブロックチェーントランザクションの検証を受信することは、ブロックチェーン上の循環にブロードキャストされた検証されたブロックチェーントランザクションの受信に応答して、ブロックチェーントランザクションの検証を受信することを含む。

方法５００の別の実施形態によれば、協働文書の第１のコラボレータの署名を立証した協働文書の第２のコラボレータから協働文書に関する検証を受信することは、協働文書処理アプリケーションのユーザインターフェースを介して第２のコラボレータから協働文書に関する検証を受信することを含む。

別の実施形態によれば、方法５００はさらに、第２のＤＬＴプラットフォームホストにより実行され、当該方法はさらに、協働文書処理アプリケーションから第２の協働文書又はその一部を受信することと、第２の協働文書又はその一部を含む第２のブロックチェーン資産を作成することと、第２の協働文書に副署した（countersigned）第２のコラボレータに関連づけられた第２のブロックチェーン資産及び第２のブロックチェーン資産識別子を含む第２のブロックチェーントランザクションを作成することと、ブロックチェーン上の循環に第２のブロックチェーントランザクションをブロードキャストすることと、ブロックチェーンにおける第２のブロックチェーントランザクションのブロードキャストに応答して、第２のブロックチェーントランザクションの検証を受信することと、第２のブロック内の検証された第２のブロックチェーントランザクションをブロックチェーンに対してコミットすることを含む。

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令は、少なくともプロセッサ及びメモリをその中に有する分散台帳技術プラットフォームホストにより実行されたときにシステムに、以下の動作：協働文書処理アプリケーションから協働文書又はその一部を受信することと、協働文書又はその一部を含むブロックチェーン資産を作成することと、協働文書に署名した第１のコラボレータに関連づけられたブロックチェーン資産及びブロックチェーン資産識別子を含むブロックチェーントランザクションを作成することと、ブロックチェーン上の循環にブロックチェーントランザクションをブロードキャストすることと、ブロックチェーンにおけるブロックチェーントランザクションのブロードキャストに応答して、ブロックチェーントランザクションの検証を受信することと、ブロック内の検証されたブロックチェーントランザクションをブロックチェーンに対してコミットすることと、を実行させる。

図６Ａは、説明される実施形態による、分散台帳技術の方法を実現する方法６００を示すフロー図を示す。

本明細書に記載されるさらなる実施形態に従い、図６Ａのフロー図を参照し、論理ブロック６０５において、第２の分散台帳技術（ＤＬＴ）プラットフォームホスト、例えばブロックチェーンベースのピアツーピアネットワーク内の第２のノードが、論理ブロック５２０によりブロックチェーン上の循環にブロードキャストされた上述のブロックチェーントランザクションを受信する。ＤＬＴプラットフォームホストは、ブロードキャストされたトランザクションを処理し、そのペイロード部分から協働文書又はその一部を抽出することが含まれ、論理ブロック６１０において、文書又はその一部のコピーを協働文書処理アプリケーションに提供する。

論理ブロック６１５において、協働文書処理アプリケーションは、協働文書処理アプリケーションのユーザインターフェースを介して第２のコラボレータから協働文書に関する検証を受信する。協働文書に対する検証は、協働文書の第１のコラボレータの署名を立証する。協働文書処理アプリケーションは、そのことをＤＬＴプラットフォームに通信し、ＤＬＴプラットフォームは、次いで、論理ブロック６２０において、対応するブロックチェーントランザクションを検証し、検証されたブロックチェーントランザクションをブロックチェーン上の循環にブロードキャストする。

図６Ｂは、説明される実施形態による、分散台帳技術の方法を実現する方法６６０を示すフロー図を示す。

本明細書に記載されるさらなる実施形態に従い、図６Ｂのフロー図を参照し、論理ブロック６２５において、第２のＤＬＴプラットフォームホストが、次いで、協働文書処理アプリケーションから第２の協働文書又はその一部を受信することができる。例えば、第２のコラボレータが、第１のコラボレータにより送付された第１の文書を改訂し（例えば、内容を挿入、修正、又は削除し）、あるいは第１の文書に関連するが独立した新しい文書を作成する場合、協働文書処理アプリケーションは、そのコピーを第２のＤＬＴプラットフォームホストに提供する。例えば、第２のコラボレータは、第１の文書に単に副署してもよく、それにより第２の副署された文書を作成する。論理ブロック６２０において、第２のホストは、第２の協働文書又はその一部を含む第２のブロックチェーン資産を作成し、論理ブロック６３５において、例えば第２の協働文書に副署した、第２のコラボレータに関連づけられた第２のブロックチェーン資産及び第２のブロックチェーン資産識別子を含む第２のブロックチェーントランザクションを作成する。

論理ブロック６４０において、第２のＤＬＴホストは、ブロックチェーン上の循環に第２のブロックチェーントランザクションをブロードキャストし、ブロックチェーンにおける第２のブロックチェーントランザクションのブロードキャストに応答して、第２のブロックチェーントランザクションの検証についてリッスンする。論理ブロック６４５において、第２のホストは検証を受信する。一実施形態において、ブロックチェーン上の循環への第２のブロックチェーントランザクションのブロードキャストに応答した、第２のブロックチェーントランザクションの検証の受信は、論理ブロック６０５〜６２０に関して上述したのと同様に、協働文書の第２のコラボレータの署名を立証した協働文書の第１のコラボレータから第２のブロックチェーントランザクションの検証を受信することを含む。その後、論理ブロック６５０において、第２のＤＬＴホストは、ブロック内の検証された第２のブロックチェーントランザクションをブロックチェーンに対してコミットする。

図７Ａは、説明される実施形態による、同意管理を有するコミュニティサイドチェーンを実現するブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャ７００を示す。

ここに示すように、再度、ホスト組織１１０は、その中にウェブサーバ１７５、要求インターフェース１７６、認証器１４０、クエリインターフェース１８０、及びデータベースシステム１３０と共に動作するホストされたコンピューティング環境１１１を有する。前述のように、ホスト組織１１０が様々なブロックチェーン関連サービスを、ホスト組織１１０により提供されるクラウドコンピューティングサービスを利用する顧客、サブスクライバ、並びに他の組織及びテナントに提供するための、ブロックチェーンサービスインターフェース１９０もある。

より詳細には、次に、ブロックチェーンサービスインターフェース１９０内に、ブロックチェーン内に記憶されたペイロードデータのアクセス権、可読性、交換許可、及び開示能力を制御するための同意管理（consent management）を有するコミュニティサイドチェーン機能を実現するブロックチェーン同意マネージャ（consent manager）７０５が示される。

従来、ブロックチェーンブロックは、ブロックチェーンプロトコル実装に関する任意の参加ノードに対してフルにオープンであり、読取可能である。このようなオープン性は、任意のノードが、いかなるオーソリティからも許可を必要とせずトランザクションが独立して有効であることを認証及び検証することを可能にするとき、設計によるものである。しかしながら、そのようなオープン性は、常に望ましいわけではない。したがって、ブロックチェーン同意マネージャ７０５及びブロックチェーンサービスインターフェース１９０は、ホスト組織によりサポートされる特定のブロックチェーンプロトコル実装のためのさらなる機能を公開し、それは、特定のデータがさらなるアクセス制限を受けることを可能にする一方で、それにもかかわらず、ブロックチェーン機能内に具現化された分散台帳技術を利用し、その恩恵を受ける。

特定の実施形態によれば、ブロックチェーン同意マネージャ７０５は、プライベートブロックチェーン上の同意管理を有するコミュニティサイドチェーンを提供する。ここに示されるように、ブロックチェーン同意マネージャ７０５は、プライベートブロックチェーン７４０（例えば、コミュニティサイドチェーン）を提供し、これは、プライベートブロックチェーン７４０としてサイドチェーンを開始する最初のジェネシスブロック７４１を含み、プライベートブロックチェーンが成長し続けるとき、標準ブロック７４３のシーケンスが後に続く。プライベートブロックチェーン７４０は、参加ノード７５０Ａ、７５０Ｂ、及び７５０Ｃの各々がアクセス可能である。実際には、プライベートブロックチェーン７４０に関して多くのさらなる参加ノードが存在する可能性がある。

コミュニティサイドチェーンは、ブロックチェーンの２つのノード間でデータを共有すること、例えば、病院と保険提供者との間で患者の医療情報を共有する能力などが望ましい場合、有用である。

従来のメカニズムでは、あらゆる参加ノード７５０Ａ〜Ｃは、ひとたびそのデータがブロックチェーンに書き込まれると、全てのデータに対するフルアクセスを有する。多くの状況で有用であるが、医療情報は、プライバシーの懸念及びＨＩＰＡＡ（１９９６年の医療保険の携行性と責任に関する法律（Health Insurance Portability and Accountability Act of 1996））の要件に起因して、閲覧するため自由にアクセスできるべきではないことは容易に明らかである。フルの可視性を可能にする従来のブロックチェーンプロトコル実装の欠点又は設計上の特徴にもかかわらず、ホスト組織１１０のブロックチェーン同意マネージャｊ７０５は、特定の顧客、組織、ユーザ（例えば、患者の医療記録の例の文脈の中で、病院、診療所、保険提供者等）に、不変性及び非中央集権的な記録保持などのブロックチェーン機能の使用から利益を得る一方で、さらに患者のプライバシーを尊重し、連邦のＨＩＰＡＡ要件に準拠することを提供する。金融組織は、プライベート（private）情報を保護するために同様の法的要件を有するが、同様に、ブロックチェーン同意マネージャ７０５を介してコミュニティサイドチェーンに同意管理機能を提供するよう本明細書に記載されたブロックチェーン機能から利益を得ることができる。

一実施形態によれば、ブロックチェーン同意マネージャ７０５は、参加ノード７５０Ａ〜Ｃがプライベートブロックチェーン７４０内に記憶された特定の情報を閲覧、読み出し、又はアクセスすることを望む場合には、それらが通過しなければならない同意管理レイヤ７１０を実現する。このような実施形態によれば、プライベートブロックチェーン７４０内のデータの一部は全ての参加ノード７５０Ａ〜Ｃに見えるが、他のデータは制限される。

誰でもパブリックブロックチェーンにアクセスしてその中の任意の情報を閲覧することができ、プライベートブロックチェーンへのアクセスを有する誰でもその中の任意の情報にアクセスすることができる、プライベートブロックチェーンとパブリックブロックチェーンとの区別とは違って、同意管理を有するプライベートブロックチェーン７４０は異なり、なぜならば、参加ノードがプライベートブロックチェーン７４０にアクセスする権限を有していても、そのようなアクセスが必ずしもプライベートブロックチェーン７４０内に記憶された保護又は制限された情報にアクセスするための「同意」を与えるわけではないためである。

ここで示されるように、参加ノード７５０Ａは、プライベートブロックチェーン７４０に書き込まれる同意７５１を提供している。したがって、新しいサイドチェーンコミュニティ７６１が、ブロックチェーン同意マネージャ７０５により形成される。具体的には、ブロックチェーン同意マネージャ７０５は、サイドチェーンブロック７４２から形成される新しいコミュニティサイドチェーン７６０を作成する。コミュニティサイドチェーン７６０は、プライベートブロックチェーン７４０により標準ブロックとして見なされるが新たに形成されたコミュニティサイドチェーン７６０をプライベートブロックチェーン７４０とリンクする参照を含むフォークブロック７４２のポイントから形成される。次いで、メインプライベートブロックチェーン７４０は、コミュニティサイドチェーン７６０の作成の後、フォークブロック７４２に続くさらなる標準ブロック７４３を介して継続する。

同意７５１が参加ノード７５０Ａから受け取られ、プライベートブロックチェーン７４０に書き込まれると、ブロックチェーン同意マネージャ７０５は、同意を有する新しいコミュニティサイドチェーン７５２をシードし（seeds）、ゆえに、新しいコミュニティサイドチェーン７６０を形成する。特定の実施形態によれば、何らのペイロードデータも、コミュニティサイドチェーンのサイドチェーンブロック７４２に書き込まれない。例えば、保護されたデータ７５３は、コミュニティサイドチェーン７６０に書き込まれるのではなく、保護された形式でプライベートブロックチェーン７４０内に留まるが、同意管理レイヤを介して保護されたデータ７５３の取り出しを可能にするサイドチェーンコミュニティの参加ノード７５０Ａ及び７５０Ｂのみがアクセス可能なサイドチェーンブロック７４２間の参照を介して、サイドチェーンコミュニティ７６１の参加ノードがアクセス可能である。他の実施形態において、保護されたデータ７５３は、サイドチェーンブロック７４２のペイロードに書き込まれてもよく、参加ノード７５０Ａ及び７５０Ｂがサイドチェーンコミュニティ７６１内に存在する利点により、これらの参加ノード７５０Ａ及び７５０Ｂは、メインチェーン（例えば、プライマリブロックチェーン７４０）にアクセスする必要なく、保護されたデータ７５３へのアクセスを有する。ここで示されるように、コミュニティサイドチェーン７６０はプライベートブロックチェーン７４０にリンクされ、したがってフォークしたブロックチェーンと考えられてもよく、一方、他の実装において、コミュニティサイドチェーンは、ブロックチェーン同意マネージャ７０５が、どの参加ノードが新たに作成されたサイドチェーンコミュニティ７６１を形成するために許可されるか、したがって、どの参加ノードが保護されたデータ７５３へのアクセスを有し、どの参加ノードが保護されたデータ７５３へのアクセスを有さないかを管理するための制御をし続ける限り、プライベートブロックチェーンから独立して動作するように形成され、許可されてもよい。

ここで示されるように、参加ノード７５０Ａ及び７５０Ｂがサイドチェーンコミュニティ７６１の全体を形成するとき、これらはサイドチェーンへのアクセスを有し、ゆえに、データはサイドチェーンコミュニティのノード間で共有可能であり、一方、参加ノード７５０Ｃはサイドチェーンコミュニティ７６１のメンバノードではなく、したがって、保護されたデータにアクセスできず、参加ノード７５０Ａ及び７５０Ｂとデータを共有できない。

図７Ｂは、説明される実施形態による、同意管理を有するコミュニティサイドチェーンのさらなる詳細を有する別の例示的なアーキテクチャ７０１を示す。

ここでは、新しい参加ノードのプライベートブロックチェーンへの導入に関するさらなる詳細を示す。図示のように、目下、ブロックチェーンサービスインターフェース１９０により管理される２つの区別可能なプライベートブロックチェーン、具体的には、ヘルスケアブロックチェーン７４４及び建設ブロックチェーン７４３が存在する。説明される実施形態によれば、多くの異なるプライベートブロックチェーンが存在でき、それらは様々な方法で編成されてもよい。例えば、ヘルスケア産業の異なる当事者が互いの間でデータを共有したい場合があり、したがって、それらが同じプライベートヘルスケアブロックチェーン７４４に参加してもよく、データ共有が必要とされる場合、同意が付与され得ることが考えられ、上述したように、サイドチェーンは、共有されるデータへのアクセスを必要とする参加ノードで形成され、ゆえに、サイドチェーンコミュニティを形成し、次いで、データは、新たに作成されたサイドチェーンコミュニティの参加者間で共有される。

しかしながら、医療データへのアクセスを必要としない他の参加者が存在する可能性があり、したがって、これらの参加ノードは、区別可能なプライベートブロックチェーンに形成される。例えば、ここでは、ハードウェアストア、建設材料製造業者、建築請負業者等の参加者を有する建設ブロックチェーン７４３が示される。このような関係者は、医療情報にアクセスする必要はない可能性があるが、購入注文、建築計画、建設契約などの建設業に関連するデータを安全に共有する機能から恩恵を受ける可能性がある。これらの関係者は、特定のタイプの情報を保護したい場合があるが、それにもかかわらず、ブロックチェーン機能の使用から恩恵を受ける場合がある。

特定の実施形態によれば、メイン建設ブロックチェーン７４３内の新しいユーザ登録（例えば、例として、ウェブサイトによるユーザプロファイルの作成など）は、新しいユーザ特有の（user specific）コミュニティサイドチェーン７５６の作成を結果としてもたらす。最初、新しいユーザ登録は、ユーザ特有のコミュニティサイドチェーン７５６に対する唯一の参加ノードであり、なぜならば、デフォルトでその特定のユーザのみが、プライベートかつ保護されたデータへのアクセスを有するためである。しかしながら、新しいユーザ登録ノード７５５は別のノードに同意してもよく、その同意は建設ブロックチェーン７４３に書き込まれ（例えば、例として、フォークブロック７４２に書き込まれ）、その結果、コミュニティサイドチェーン７５６は、新しいユーザ登録７５５とさらに同意が付与された別の参加ノードとの双方を有する方法を有することになる。図示のように、参加ノード７５０Ｂは以前、サイドチェーンへのアクセスを有さない建設ブロックチェーン７４３の一部であったが、新しいユーザ登録ノードに関する同意の付与で、参加ノード７５０Ｂは次いで、ユーザ特有のコミュニティサイドチェーン７５６に加えられ、これを介して、新しいユーザ登録ノード７５５に関連づけられたプライベート又は保護されたデータへのアクセスが共有され得る。ユーザ特有のコミュニティサイドチェーン７５６に入るための同意を有する全てのノードは、新しいユーザ登録ノード７５５のプライベートかつ保護された情報へのアクセスを与えられる。同じユーザが、異なるアクセスを異なる参加ノードに与える必要がある場合、ユーザは、別個の新しいユーザ登録ノードを作成する必要がある。例えば、ユーザが、建設ブロックチェーン７４３内のホームデポ（Home Depot）又はロウズ（Lowe’s）などのウェブサイトでプロファイルを作成し、例えばカーペット設置業者と情報を共有することを選択する場合、ユーザ特有のコミュニティサイドチェーン７５６に加わり、関連情報にアクセスするために、同意がカーペット設置業者に付与されてもよい。ユーザが次いで、同じ情報を例えば窓設置業者と共有したい場合、窓設置業者もまた同意７５１を与えられ、新しい参加ノードとしてユーザ特有のコミュニティサイドチェーン７５６に加わってもよいが、ユーザが各プロバイダとの間で異なる情報を共有したい場合、２つのプロファイルが必要とされる。しかしながら、実用的には、ユーザに関する同じ情報が各設置業者に関連し、したがって、ユーザがそのような問題に遭遇する可能性は低い。

したがって、特定の実施形態によれば、ユーザは、参加ウェブサイトでユーザプロファイルを作成することにより、（例えば、建設ブロックチェーン７４３又はヘルスケアブロックチェーン７４４などの）プライマリブロックチェーンにおけるユーザ特有のコミュニティサイドチェーンを作成してもよく、そのようなユーザは、次いで、他のノードに（例えば、同じウェブサイトを介して）同意を付与して、プライマリブロックチェーンに参加しているが同意を付与される前にはユーザ特有のサイドチェーンへのアクセスを有さない指定されたターゲットノードとの、プライベート又は保護された情報の共有を可能にしてもよい。

本明細書で詳細に論じられる概念に特有ではないが、ホームデポなどのウェブサイトは、建設ブロックチェーン７４３内のノードとして、さらにホスト組織の顧客として動作し得る。顧客のホームデポのウェブサイトを介して、新規ユーザは、ユーザプロファイルを作成することができ、ホスト組織のブロックチェーンサービスインターフェース１９０は、次いで、新規ユーザ登録７５５に対応する建設ブロックチェーン７４３又は他の関連するプライマリブロックチェーン内の新しいノードを生成する。ブロックチェーンサービスインターフェース１９０は、ユーザ特有のコミュニティサイドチェーン７５６をさらに生成し、これを介して、ユーザは、この例における建設ブロックチェーンなどの特定のブロックチェーンに関して他の参加ノードと情報を共有するための同意を付与することができる。例えば、一実施形態によれば、ユーザが、ホームデポなどのウェブサイトでログインし、あるいはプロファイルを作成するとき、ユーザは、ウェブサイトが動作し存在するホスト組織１１０との間で認証している。次いで、ユーザはホスト組織１１０で認証されるため、同じホスト組織１１０は、ブロックチェーンサービスインターフェース１９０を介してホスト組織１１０がアクセス可能な任意のブロックチェーン上に新しいユーザ登録に対する新しいノードを作成することができる。

明確化のために言うと、情報は、２つの異なるプライベートブロックチェーン間で共有されない。したがって、技術的に実行可能であるが、情報がヘルスケアブロックチェーン７４４と建設ブロックチェーン７４３との間で共有されることは企図されない。むしろ、各々が別個のプライベートブロックチェーンとして動作し、各々はその独自の参加ノード、ユーザ、及びサイドチェーンを有する。しかしながら、同じ人間のユーザが異なるウェブサイトでプロファイルを作成することができ、その結果、人間のユーザは、ヘルスケアプライベートブロックチェーン内のノードと、さらに建設プライベートブロックチェーン内のノードを有することになる。双方のプライベートブロックチェーンが同じホスト組織により管理されるという事実は無関係であり、当の特定のユーザには分からない可能性がある。

さらに、プライベートブロックチェーンのサイドチェーンはノードではなく、むしろ、メインプライベートブロックチェーンからの許容可能な分岐又はフォークであることに留意されたい。ここで示されたサイドチェーンは、プライマリブロックチェーンに不変的にアタッチされ、関連づけられたままであり、独立して動作しない。しかしながら、情報が、ホスト組織１１０により管理されるヘルスケアブロックチェーン７４４とは別個の別のヘルスケアプライベートブロックチェーンなどの、別の独立して動作するブロックチェーンと共有されるべき場合、ユーザは、定義された交換合意が２つのプライマリブロックチェーンの間に存在すると仮定し、前述の（例えば、図１Ｄの）方法で、保護されたデータを他の独立して動作するブロックチェーンと交換するための同意を付与することができ、その場合、ホスト組織により管理されるヘルスケアブロックチェーン７４４は、親ブロックチェーン（例えば、図１Ｄの要素１８８）とみなされ、別個の独立して動作するブロックチェーンは、独立して動作するサイドチェーン（例えば、図１Ｄの要素１８９）として取り扱われる。

特定の実施形態によれば、ユーザ特有のサイドチェーン内の特定のノードに関してユーザ同意が捕捉されるとき、その同意はサイドチェーンにおいて捕捉され、次いで、それが永続的に保持されるプライマリブロックチェーンに書き込まれる。このような実施形態において、同意が付与されたという事実は保護情報ではないが、制限データは保護され、同意は、同意が２される時間まで、プライマリブロックチェーンの指定された参加ノードにのみ適用可能である。特定の実施形態によれば、付与される同意は時間制限されてもよく、したがって、指定された期間の後に満了する。このような場合、保護された情報へのアクセスは、ブロックチェーンサービスインターフェース１９０により提供されるブロックチェーンプロトコルの一部として、ブロックチェーン同意マネージャ７０５を介して時間満了に対してチェックされる。

図８Ａは、説明される実施形態による、同意管理を有するスーパーコミュニティサイドチェーンを実現するブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャ８００を示す。

ここに示すように、再度、ホスト組織１１０は、その中にウェブサーバ１７５、要求インターフェース１７６、認証器１４０、クエリインターフェース１８０、及びデータベースシステム１３０と共に動作するホストされたコンピューティング環境１１１を有する。前述のように、ホスト組織１１０が様々なブロックチェーン関連サービスを、ホスト組織１１０により提供されるクラウドコンピューティングサービスを利用する顧客、サブスクライバ、並びに他の組織及びテナントに提供するための、ブロックチェーンサービスインターフェース１９０もある。

本明細書に記載される従来のブロックチェーン技術に対する重要な一改善は、ホスト組織１１０の異なるテナント間で情報を共有する能力である。しかしながら、注目すべきことに、情報の共有は、ユーザの情報が共有されるべきときにそのユーザからの適切な同意を必要とするため、その独自のデメリットを有する。

同じホスト組織１１０の２つ以上のテナントが同じプライベートブロックチェーンに参加する例、例えば、第１のテナントのホームデポと第２のテナントのＡＡＡカーペット設置業者がプライベート建設ブロックチェーンに参加することを考える。テナントの各々は、ホスト組織のブロックチェーンサービスインターフェース１９０により提供されるプライベート建設ブロックチェーン内のノードとして動作する。ユーザが、ホスト組織１１０のテナントであるホームデポのウェブサイトでアカウントを作成するとき、そのユーザのデータ及びクレデンシャルはホスト組織１１０により記憶され、ホスト組織は、上述のように、ユーザのためにプライベート建設ブロックチェーン内にノードを作成する。しかしながら、同じ人間のユーザがホスト組織の別のテナントでのログイン及びプロファイルを作成する場合、ユーザは再度、ユーザのためにプライベート建設ブロックチェーン内にノードを作成させるが、各々は異なる一意識別子を有し、各々は異なるノードであり、同じ人間のユーザに対するログインクレデンシャル及びプロファイルは区別可能である。

これは、例えば、カイザーヘルスケアにおいてユーザプロファイルを作成する個人が、例えば、プルデンシャルヘルスケアにおいてユーザプロファイルをさらに作成することがあるため、一般的な体験である。このような個人は、同じログインクレデンシャルが双方の区別可能な組織で機能することを期待せず、実際、個人のユーザプロファイルは区別可能であり、全く別個に維持される。

しかしながら、２つの別個の組織が双方、同じホスト組織のテナントであるとき、スーパーコミュニティテナントブリッジ（super community tenant bridge）８０５が、同じ人間のユーザが２つの区別可能なユーザプロファイル間で情報を共有することを可能にされるメカニズムを提供する。

例えば、銀行、例えばウェルズファーゴに足を踏み入れ、口座を開設する個人を考える。ユーザは、個人の名前だけでなく、重要な情報を銀行に提供する必要がある。例えば、ユーザは、住所、雇用者、収入、婚姻状態、金融資産、社会保障番号等を提供することを要求されることがある。次いで、同じ個人が、チェイスなどの別の銀行に行ってクレジットカードを開設し、予測できるように、第２の銀行は、第１の銀行がしたように多くの同じ情報を同じ個人から要求するだろう。これは、個人にとって苛立たしく、時間がかかる。同様に、患者が医師の治療を求める場合、訪問すると、診療所は長々しい個人的な医療情報を要求する。その同じ医師が治療のために患者を病院に送る場合、病院は、同じ患者からの同一の情報を、そのような情報がすでに医師に提供されているにもかかわらず、要求する。

スーパーコミュニティテナントブリッジ８０５は、情報を要求する双方の組織が同じホスト組織１１０内のテナントである場合、個人に対するこの問題を克服する。個人が、１つのテナント組織で第１のユーザプロファイル８１０Ａを、第２のテナント組織で異なるユーザプロファイル８５２を有するという事実にもかかわらず、ホスト組織１１０は、双方のテナントに関する情報をそれにもかかわらず所有し、双方のユーザプロファイル８５１及び８５２が実際に関連づけられている個人による適切な同意を条件として、ホスト組織のブロックチェーンサービスインターフェース１９０により提供されるブロックチェーンプロトコルを使用してデータ共有プロセスを容易にすることができる。

ここで示されるように、個人は、ユーザプロファイル８５１により表される、顧客組織８１０Ａでのユーザプロファイルをすでに有する。ユーザプロファイルの中には、個人が提供又は入力した情報、例えば、診療所に提供された個人的な医療データがある。（顧客組織８１０Ａとしての）診療所と病院などの第２の顧客組織８１０Ｂとの双方が、双方ともホスト組織１１０のテナントであり、双方ともホスト組織１１０により提供されるブロックチェーンサービスを利用しており、したがって、各々が適用可能なブロックチェーン（例えば、ホスト組織により管理されるヘルスケアプライベートブロックチェーンなど）上の参加ノードであると仮定し、個人は、２つの顧客組織８１０Ａ及び８１０Ｂのいずれかで既知のユーザとしてログイン及び認証し、ユーザ同意８９１を付与して２つの顧客組織間で情報を共有することができ、その結果、ユーザの保護情報は、要素８９２により示されるように共有され、ユーザの保護情報は、スーパーコミュニティテナントブリッジ８０５により顧客組織８１０Ｂに提供され、顧客組織８１０Ｂ内で複製される。

あなたの顧客を知る（Know your customer）又は「ＫＹＣ」は、そのクライアントのアイデンティティを識別及び立証するビジネスのプロセスである。この用語は、これらの活動を管理する銀行及び反マネーロンダリング規制を指すことにも用いられている。ＫＹＣガイドラインの目的は、意図的又は非意図的に、銀行がマネーロンダリング活動のために犯罪的要素により利用されるのを防止することである。関連する手続きもまた、銀行がその顧客や金融取引をより良く理解できるようにしている。これは、彼らが慎重にリスクを管理するのに役立つ。

ＫＹＣポリシーのいくつかは連邦法により事実上義務付けられており、銀行が取引を行ういかなる個人についても広範な立証を要求している。

同様の要件がヘルスケア組織に関して存在し、ヘルスケア組織は、該組織が会話し、治療し、又は保険でカバーされるサービスを提供している人物が本当に正しい個人であることを保証しなければならない。

銀行やヘルスケア組織は、そのようなデータを収集し、彼らが相互作用するいかなる個人に対しても必要な検証を行う際に、かなり高いコストを負担しており、結果的に、同じ情報を複数の異なる組織に何度も提供しなければならない個人にとって不便なだけでなく、情報を要求する組織もまた不便である。

スーパーコミュニティテナントブリッジ８０５は、ホスト組織１１０により定義されるブロックチェーンプロトコルを利用して関連情報を記憶し、次いで、ブロックチェーンサービスインターフェース１９０及びスーパーコミュニティテナントブリッジ８０５を使用して２つの銀行又は２つのヘルスケア組織などの同意する当事者間で反復的だがプライベートかつ保護された情報の共有を可能にすることにより、この必要に対処する。これは、個人に利益をもたらし、個人は、同一の情報を何度も複数のプロバイダに提供する必要から解放され、また、これは、プロバイダ又は顧客組織に利益をもたらし、プロバイダ又は顧客組織は、ユーザ同意８９１を条件として正確な情報をより迅速に受け取るが、情報がブロックチェーン内に記憶されるという事実からも利益を受け、したがって、ブロックチェーンを悪意をもって又は不正に操作するための、計算上の負担が大きく一般的に実行不可能な手段を仮定すると、有意により低リスクである。

特定の個人の情報がブロックチェーン内に蓄積され、より年季が入る（例えば、ブロックチェーン内でより古く）なると、情報はますます信頼でき、真正とみなされ、したがって、銀行、ヘルスケア組織、又はそのような情報に依存する他のエンティティにとって、より信頼できる。

例えば、ある個人がその運転免許証と保険証を診療所などの第１の組織に提供し、そのような情報が次いでブロックチェーン内に記憶される場合、病院などの第２の組織は、第２の組織がブロックチェーンブロック自体を検証することができることを仮定し、さらに、情報がブロックチェーン内にあるため別のプロバイダ、診療所が情報の真実性をすでに証明しているという事実を仮定し、ブロックチェーン内の情報を疑う理由がほとんどない。

図８Ｂは、説明される実施形態による、スーパーコミュニティ機能と相互作用するユーザデバイス８９９におけるＧＵＩ８０３のさらなる詳細を有する別の例示的なアーキテクチャ８０１を示す。

ここでわかるように、個人は、図示のものなどのユーザコンピューティングデバイス８９９を利用して、ホスト組織１１０内でその個人に対し一意（unique）であるユニバーサルＩＤに関連づけられた全てのプロファイルについてブロックチェーンを検索することができる。

ここで示されるように、スーパーコミュニティテナントブリッジ８０５は、ＧＵＩをユーザデバイスに送信し、それは次いで表示され、ゆえに、ユーザはそれらのユニバーサルＩＤを入力して、関連づけられたプロファイルについて検索することができる。他の実施形態において、ユーザは、不確かな場合にそれらのユニバーサルＩＤについて検索し、あるいは検索機能をナビゲートしてそれらのユニバーサルＩＤを突き止めてもよく、次いで、それは、個人に対する全ての関連づけられたユーザプロファイルについて検索するために使用される。

通常、言語、認証、及びユーザインターフェースが各それぞれの顧客組織に固有であると、双方の顧客組織が同じホスト組織１１０のテナントであるとしても、２つの別個及び区別可能なユーザアカウント又はユーザプロファイルに起因して、ユーザは各システムに別個にログインすることを要求される。しかしながら、スーパーコミュニティテナントブリッジ８０５は、ユーザが、個人がブロックチェーン内にデータ又はユーザプロファイルを記憶させたホスト組織１１０内の複数のテナント組織にわたり全てのアカウントを識別し、次いで、簡素なＧＵＩインターフェースから、個人が２つの区別可能な顧客組織間でどの要素又はどの種類のデータを共有したいかを識別することを可能にする。

図８Ｃは、説明される実施形態による、スーパーコミュニティ機能と相互作用するユーザデバイス８９９におけるＧＵＩ８０４のさらなる詳細を有する別の例示的なアーキテクチャ８０２を示す。

ここで示されるように、ユーザは、ＧＵＩ８０４において、文書及び情報を共有する要求をプロンプト表示され（prompted）、ユーザは、動作８１９に示されるように、どの文書及び情報を共有すべきかを選択することができる。ここでの情報は、ユーザがすでにプロファイルを作成し、情報を入力又は提供した第１の顧客組織に由来し、第２の顧客組織と共有される。特定の実施形態において、情報は第２の顧客組織に複製され、一方、他では、第２の顧客組織は、情報を共有するための同意を付与され、次いで、第２の顧客組織は、ユーザのノードを有するコミュニティサイドチェーンに配置され、それを介し、情報は、データを複製する必要なくプライマリブロックチェーン内の必要な情報へのアクセスを得るための同意管理レイヤ（例えば、図７Ｃの要素７１０）を通過し得る。一般に、同じ情報がすでに検証されており、ブロックチェーン上の全ての参加ノードの合意を有する検証されたブロック内に存在するとき、非複製が望ましい。しかしながら、特定の実装が、ブロックチェーン内の元々記憶された情報へのデータアクセスに対する同意よりも、データ複製を必要としてもよい。

ユーザが、共有されるよう選択したデータ要素をアンロックし（unlocks）、サブミットをクリックすると、上述の方法で、第２の顧客組織に対して同意が付与される。

説明される実施形態によれば、個人は、第１の又は第２の顧客組織のいずれかで認証し、ここで、一方の顧客組織は個人の保護されたデータへのアクセスを有し、他方の顧客組織は有さず、次いで、ユーザは、データへのアクセスをすでに有する顧客組織内で同意を付与するか、又はデータへのアクセスを有さない顧客組織内で共有データを受け取るための同意を付与することにより、データの共有を承認する。言い換えると、個人がどのユーザプロファイルで認証するかは、双方がその特定の個人に対する同じユニバーサルＩＤに関連づけられている限り、問題ではない。

ひとたびユーザにより同意が付与されると、双方の顧客組織がブロックチェーンの参加ノードであるため、それらはブロックチェーンからデータを読み出し、ブロックチェーン同意マネージャ（例えば、図７Ｂの要素７０５）により実装された同意管理レイヤ（例えば、図７Ｂの要素７１０）を通過することができる。

一実施形態によれば、ヘルスケアブロックチェーンのユニバーサルＩＤは、個人の社会保障番号（social security number、ＳＳＮ）であるが、他の実施形態において、それは、ホスト組織により生成される値である。金融機関のためのＦｉｎＴｅｃｈを実現する他の実施形態では、ユニバーサルＩＤは、事業者のタックスＩＤ番号（Tax ID Number）又は（ＴＩＮ）でもよい。異なる産業のための他のブロックチェーンは、異なる番号を利用してもよく、あるいはホスト組織のテナントで１つ以上のプロファイルを有する各一意の個人に対してホスト組織により生成されたユニバーサルＩＤを利用してもよい。ユニバーサルＩＤは、時に「ブロックチェーン識別子」と呼ばれる。あらゆるテナントでのあらゆるユーザプロファイルが区別可能であり得、そのユーザプロファイルに対して区別可能なユーザＩＤを有することさえあるが、ユニバーサルＩＤは、特定の個人に対する全てのユーザプロファイル間で共通である。

特定の実施形態によれば、個人が任意のテナントのウェブサイトで認証するとき、個人のユニバーサルＩＤは、個人がそれらのユニバーサルＩＤを入力又はそれらのユニバーサルＩＤについて検索する必要なく、同意を付与又は同意の付与を拒絶するだけでよいように、自動的に埋められ（populated）、あるいは取り出される。例えば、ブロックチェーンに基づくユーザのプロファイルデータに対して完全な一致がある場合、一致したデータが利用されてユニバーサルＩＤを自動的に埋めてもよく、ユーザがそれを提供又はそれについて検索する必要はない。例えば、完全な一致は、ブロックチェーンに基づいて一致するＳＳＮ／ＴＩＮ、名、姓、及び生年月日（ＤＯＢ）を必要としてもよい。

他の実施形態において、ブロックチェーン内に記憶された保護データのセキュリティ及び不注意な共有のリスクを向上させるために、個人のユニバーサルＩＤに基づいて任意の同意が付与され得る前に、２ファクタ認証が必要とされる。

他の実施形態によれば、共通のユニバーサルＩＤに関連づけられていない２つのユーザプロファイルが、同じ個人が双方のアカウントを制御していることと、携帯電話番号又は電子メールアカウントなどの別の既知の情報とを立証するための２ファクタ認証を利用して、共通のユニバーサルＩＤにリンクされてもよい、２ファクタ認証により、個人は、次いで、それらが実際に同じ個人であることを証明することができる。

特定の実施形態によれば、ユーザのユニバーサルＩＤは、個人のＳＳＮ又はＴＩＮ、生年月日、個人は知っているが他者は見つけるのが困難な他の情報などの個人的な立証情報を使用して検索され、突き止められてもよい。

個人のためのアイデンティティ管理をホスト組織の様々なテナントの間の多くのユーザプロファイルに提供することにより、ブロックチェーンから保護された情報にアクセスするために通過されなければならない一層厳格な同意管理レイヤを追加することが可能であり、一方、従来のブロックチェーン実装は、ブロックチェーン内の全てのデータを任意の参加ノードにより自由にアクセスできるようにする。特定の実施形態において、同意を付与するのは個人ではなく、むしろノード自体（例えば、ノードが属する会社代表など）である。このような方法で、ノードもまた、データを他のノードと共有することに同意でき、これは、必ずしも個人の人間のユーザに対応しなくてもよい。

個人が、２つの顧客組織のウェブサイトのうちの１つにログインし、情報を共有するための同意についてプロンプト表示され、肯定的に同意を付与すると、ブロックチェーン同意マネージャ７０５は、スーパーコミュニティテナントブリッジ８０５と関連して、今や同意を有する顧客組織のノードを、ユーザのノードとユーザの保護データへの先行アクセスを有する顧客組織のノードとを有するコミュニティサイドチェーンに加え、それにより、コミュニティサイドチェーン内の全てのノードが、ブロックチェーン内の保護されたデータにアクセス可能にされる。

このようにして、同じ個人が２つの別個のコミュニティ（例えば、各々区別可能なユーザプロファイルに対応するコミュニティサイドチェーン）にログインする必要なく、それらは全て、ホスト組織１１０の複数の区別可能なテナントにわたる個人の複数のユーザプロファイルにまたがる１つのコミュニティサイドチェーンに加えられる。

一実施形態によれば、ユーザの保護データは、第１の顧客組織に対応するノードにより所有されるが、第１の顧客組織がデータを共有するための同意を付与する権利は、個人により保有される。したがって、情報を共有するための個人の同意は、ブロックチェーンに参加する２つのノードが共通のコミュニティサイドチェーンに配置されることにより情報を共有することを可能にする。しかしながら、この例では、ユーザのノードはデータを所有しないため、ユーザのノードが同じコミュニティサイドチェーンに配置される必要はなく、データ共有に参加すべき２つの顧客組織が、ユーザのノードが存在するコミュニティサイドチェーンに加わる必要もない。

ＧＵＩ８０４に示されるように、様々なタイプのデータが、別個のカテゴリ又は異なるタイプとして取り出されてもよく、したがって、ユーザは、病院ノードにより所有される血液検査文書を個人の診療所を表すノードと共有するための同意を付与するが、金融資産を共有するための同意を否定することができ、ゆえに、病院は、金融情報が要求され、ユーザがその情報を共有するための同意についてプロンプト表示された場合でも、そのような情報を診療所と共有することを禁止される。

別の実施形態によれば、ユーザは、各カテゴリをクリックし、どの文書、オブジェクト、又はフィールドを共有し又は共有しないかを具体的に選択してもよく、ゆえに、共有するための同意が付与される情報にわたり、より大きい粒度の制御をユーザに提供する。

説明される実施形態によれば、付与された同意は、ブロックチェーンプロトコルブロックのペイロードに書き込まれ、ここで、ブロックチェーン内の全てのノードは、同意を別個のブロックチェーン資産として閲覧及び検証することができ、ノードは、同意管理レイヤを貫通してユーザの保護情報にアクセスするためのリンクを有する同意を与えられ、ユーザの保護情報は、ブロックチェーンにすでに書き込まれているが、ユーザからの明示的な同意がない全てのノードがアクセスできない。一実施形態によれば、リンクはブロックチェーン内の資産ＩＤである。

このような実施形態によれば、ノードが同意を付与されることは、ブロックチェーン内に記憶された保護情報にアクセスするために資産ＩＤのみを必要とする。

特定の実施形態によれば、小さいコミュニティの合併であるスーパーコミュニティが確立され、各々のより小さいコミュニティは、ブロックチェーンに参加している顧客組織の各々から構成される。ブロックチェーンからデータが要求されるときはいつでも、通知がスーパーコミュニティ全体に送信され、次いで、ブロックチェーン同意マネージャ７０５により同意モデルが強制される。このような実施形態において、同意は、少なくとも（ｉ）ブロックチェーンから要求されるブロックチェーン資産、（ｉｉ）アクセスを要求する顧客組織（例えば、テナント）、（ｉｉｉ）そのデータを所有し、あるいは許可を得なければならない消費者、及び（ｉｖ）アクセスが要求されているレコードを識別し、あるいは含む。コミュニティＧＵＩ内では、ＵＩコンポーネントが、コミュニティユーザに、スーパーコミュニティ内のその特定のユーザに関する全ての要求された承認を表示する。ユーザアクセスは、ホスト組織のアイデンティティ管理により、例えば認証器１４０を介して、事前に提供される（pre-provisioned）。次いで、スーパーコミュニティのコミュニティユーザは、同意を付与するかどうかを判断し、より粒度の細かい制御のために、どの資産を共有すべきか、それらの資産をどんな他の顧客組織（例えば、テナント）と共有すべきかに関してドリルダウンすることができ、ゆえに、誰がどんなデータへのアクセスを有するかを制御する。

図９は、ユーザ、顧客、及びサブスクライバにクラウドベースのオンデマンド機能を提供するために、このような機能を実行するプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境において、分散台帳技術のための同意管理を有するスーパーコミュニティ及びコミュニティサイドチェーンを実現する方法９００を示すフロー図を示す。

方法９００は、ハードウェア（例えば、回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば、処理デバイス上で実行される命令）を含み得る処理論理により実行されて、本明細書に記載のシステム及び方法に従って実行、送信、受信、解析、トリガ、プッシュ、推奨、定義、取り出し、パース、持続、公開、ロード、動作、生成、記憶、維持、作成、返信、提示、インターフェース、通信、クエリ、処理、提供、決定、表示、更新、送出などの様々な動作を実行し得る。例えば、図１以下に示されるホストされたコンピューティング環境１１１、ブロックチェーンサービスインターフェース１９０、及びそのデータベースシステム１３０、並びに本明細書に記載する他のシステム及びコンポーネントは、説明される方法論を実現することができる。以下で列挙されるブロック及び／又は動作のいくつかは、特定の実施形態に従って任意である。提示されるブロックの番号付けは明りょうさのためであり、様々なブロックが発生しなければならない動作の順序を規定することは意図されない。

図９に示す方法９００を参照し、ブロック９０５において、処理論理は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させ、複数のテナントの各々は、ブロックチェーンでの参加ノードである。

ブロック９１０において、処理論理は、ユーザデバイスからログイン要求を受信し、ログイン要求は、複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する。

ブロック９１５において、処理論理は、ユーザデバイスを認証し、ユーザデバイスの認証に基づいてブロックチェーンからユーザプロファイルを取り出す。ユーザプロファイルは、ブロックチェーン内にブロックチェーン資産として記憶され、ユーザプロファイルの第１の部分は、ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、ユーザプロファイルの第２の部分は、ユーザ同意を有する参加ノードのみがアクセス可能な保護データを含む。

ブロック９２０において、処理論理は、保護データを複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するようにユーザデバイスにプロンプト表示する。

ブロック９２０において、処理論理は、第２のテナントの参加ノードによるブロックチェーン資産内の保護データへのアクセスを許可することにより、保護データを複数のテナントのうち第２のテナントと共有する。

方法９００の別の実施形態によれば、ホスト組織のブロックチェーン同意マネージャは、ブロックチェーンからの保護データにアクセスするために資産ＩＤを必要とする。

別の実施形態によれば、方法９００はさらに、第２のテナントから第２のユーザプロファイルを作成する要求を受信することと、第２のユーザプロファイルの非保護情報を含むブロックチェーン資産を作成することと、ブロックチェーンサービスインターフェースを介して、ブロックチェーン資産を含むブロックチェーントランザクションを生成することと、ブロックチェーン上の循環にブロックチェーントランザクションをブロードキャストすることと、ブロック内の検証されたブロックチェーントランザクションをブロックチェーンに対してコミットすることを含む。

方法９００の別の実施形態によれば、保護データを複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するようにユーザデバイスにプロンプト表示することは、第２のユーザプロファイルを埋めるために保護データを第２のテナントと共有するようにユーザデバイスにプロンプト表示することを含み、第１のユーザプロファイルと第２のユーザプロファイルの双方が、共通のユニバーサルＩＤに関連づけられ、保護データを複数のテナントのうち第２のテナントと共有することは、第２のテナントの参加ノードによりブロックチェーン資産から取り出された保護データで第２のユーザプロファイルを埋めることを含む。

方法９００の別の実施形態によれば、ブロックチェーン資産内の保護データへのアクセスを許可することにより、保護データを複数のテナントのうち第２のテナントと共有することは、ブロックチェーン資産の資産ＩＤを第２のテナントに送信することを含み、本方法は、第２のテナントが資産ＩＤをブロックチェーン同意マネージャに提示してブロックチェーン資産内の保護データにアクセスすることをさらに含む。

方法９００の別の実施形態によれば、第１及び第２のテナントの各々は、ホスト組織により管理されるヘルスケアブロックチェーンでの参加ノードとして動作するヘルスケア顧客組織であり、非保護データは、第１のユーザプロファイルに関連づけられたユーザの名前を少なくとも含み、保護データは、ユーザのために第１のユーザプロファイルをその中に具現化させたブロックチェーン資産を介してヘルスケアブロックチェーン内に記憶されたＨＩＰＡＡ（医療保険の携行性と責任に関する法律）により保護された医療データを少なくとも含み、保護されたデータを複数のテナントのうち第２のテナントと共有することは、ユーザが第２のテナントに関連づけられた第２のユーザプロファイルを介して、ＨＩＰＡＡにより保護された医療データを第２のテナントと共有するための同意を付与することを含む。

方法９００の別の実施形態によれば、第１及び第２のテナントの各々は、ホスト組織により管理される金融ブロックチェーンでの参加ノードとして動作する金融顧客組織であり、非保護データは、第１のユーザプロファイルに関連づけられたユーザの名前を少なくとも含み、保護データは、ユーザのために第１のユーザプロファイルをその中に具現化させたブロックチェーン資産を介して、金融ブロックチェーン内に記憶されたプライベート（private）金融データを少なくとも含み、保護データを複数のテナントのうち第２のテナントと共有することは、ユーザが第２のテナントに関連づけられた第２のユーザプロファイルを介してプライベート金融データを第２のテナントと共有するための同意を付与することを含む。

別の実施形態によれば、方法９００はさらに、（ｉ）第１のテナントに関連づけられた同じ個人として立証された、第２のテナントの認証されたユーザから、ユーザ同意を受信すること、又は（ｉｉ）第２のテナントに関連づけられた同じ個人として立証された、第１のテナントで認証されたユーザデバイスから、ユーザ同意を受信すること、のうち１つにより、保護データを共有するためのユーザ同意を受信することを含む。

方法９００の別の実施形態によれば、保護データを複数のテナントのうち第２のテナントと共有することは、ホスト組織がブロックチェーン同意マネージャを介して、第１のテナントと第２のテナントの双方が１の個人に関連づけられたユーザプロファイルを有することを検証することを含み、検証は、第１及び第２のテナントのユーザプロファイルの双方がホスト組織内で１の個人に対し一意である共通のユニバーサルＩＤに関連づけられるという１の個人からの証明を受信することに基づく。

方法９００の別の実施形態によれば、ブロックチェーン資産は、ブロックチェーン資産識別子、又はブロックチェーン内で一意のユニバーサルＩＤを介して識別され、保護データに関連づけられた１の個人は、ブロックチェーン資産識別子又はユニバーサルＩＤに基づいて、ホスト組織の第１のテナント及び第２のテナントの双方に対して一意に（uniquely）識別可能である。

別の実施形態によれば、方法９００はさらに、ユーザプロファイルに関連づけられたユーザのためにブロックチェーンでの参加ノードを作成することと、ユーザプロファイルに関連づけられたユーザのためにユーザ特有のコミュニティサイドチェーンを生成することと、第１のテナントのノードと第２のテナントのノードの双方をユーザ特有のコミュニティサイドチェーンに追加することと、を含み、保護データを共有することは、ユーザ特有のコミュニティサイドチェーン内の全てのノードに保護データへのアクセスを付与することを含む。

方法９００の別の実施形態によれば、ブロックチェーンでの参加ノードによる、ユーザプロファイルの保護データにアクセスする任意の試みは、保護データをアクセスを試みた参加ノードと共有するために同意を付与するためのユーザデバイスのプロンプト表示をトリガする。特定カテゴリの保護情報をアンロックし、又は特定の文書をアンロックし、あるいは双方を行う要求を有するＧＵＩが、ユーザデバイスに送信される。ユーザは、ＧＵＩを介してどのカテゴリ及び／又は文書をアンロックすべきかを選択する。ＧＵＩを介した任意のカテゴリ又は文書へのアクセスをアンロックするユーザ指示は、保護データへのアクセスを試みた参加ノードにリンクを送信し、これを介して、保護された情報は、ホスト組織の同意管理レイヤを通してブロックチェーンからアクセス可能にされる。

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するホスト組織のシステムに実行されたときに、命令はシステムに、以下の動作：ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、複数のテナントの各々は、ブロックチェーンでの参加ノードである、ことと、ユーザデバイスからログイン要求を受信することであり、ログイン要求は、複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する、ことと、ユーザデバイスを認証し、ユーザデバイスの認証に基づいてブロックチェーンからユーザプロファイルを取り出すことであり、ユーザプロファイルは、ブロックチェーン内のブロックチェーン資産として記憶され、ユーザプロファイルの第１の部分は、ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、ユーザプロファイルの第２の部分は、ユーザ同意を有する参加ノードのみがアクセス可能な保護データを含む、ことと、保護データを複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するようにユーザデバイスにプロンプト表示することと、第２のテナントの参加ノードによるブロックチェーン資産内の保護データへのアクセスを許可することにより、保護データを複数のテナントのうち第２のテナントと共有することと、を実行させる。

図１０は、実施形態が動作し、設置され、統合され、又は構成され得るシステム１００１の概略表現を示す。一実施形態によれば、本明細書に記載される方法論のための実装アプリケーションコード１０９６を実行するための少なくともプロセッサ１０９０及びメモリ１０９５をその中に有するシステム１００１が存在する。このようなシステム１００１は、ホスト組織、マルチテナント環境、オンデマンドサービスプロバイダ、クラウドベースのサービスプロバイダ、クライアント‐サーバ環境などのホストされたコンピューティング環境と通信上インターフェースし、該コンピューティング環境の恩恵を受けて協同的に実行することができる。

図示の実施形態によれば、ホスト組織内で動作し得るシステム１００１は、システム１００１で命令を実行するためのプロセッサ１０９０及びメモリ１０９５を含む。このような実施形態によれば、プロセッサ１０９０は、ホスト組織の複数のテナントのためにブロックチェーンとインターフェースするブロックチェーンサービスインターフェース１０６５であり、複数のテナントの各々は、ブロックチェーンでの参加ノード１０９９である、ブロックチェーンサービスインターフェースと、ユーザデバイス１０９８からログイン要求を受信する受信インターフェース１０２６であり、ログイン要求は、複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する、受信インターフェースと、ユーザデバイス１０９８を認証し、ユーザデバイスの認証に基づいてブロックチェーンからユーザプロファイルを取り出す認証器１０５０であり、ユーザプロファイルは、ブロックチェーン内のブロックチェーン資産として記憶され、ユーザプロファイルの第１の部分は、ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、ユーザプロファイルの第２の部分は、ユーザ同意を有するノードのみがアクセス可能な保護データ１０４０を含む、認証器と、（例えば、ＧＵＩマネージャ１０８５により送信及び管理されるＧＵＩ１０８６を介して）保護データを複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように（例えば、要素１０４１は付与された同意を示す）ユーザデバイスにプロンプト表示するブロックチェーン同意マネージャ１０４２と、第２のテナントの参加ノードによるブロックチェーン資産内の保護データへのアクセスを許可することにより、保護データを複数のテナントのうち第２のテナントと共有するスーパーコミュニティテナントブリッジ１０４３と、を実行する。

システム１００１の別の実施形態によれば、受信インターフェース１０２６は、システムから遠隔のユーザクライアントデバイス１０９８と通信し、パブリックインターネットを介してユーザデバイスをシステムと通信上リンクする。このような実施形態によれば、システムは、ユーザデバイス１０９９に対するクラウドベースのサービスプロバイダとしてホスト組織で動作し、クラウドベースのサービスプロバイダは、パブリックインターネットを介してユーザクライアントデバイスに公開された受信インターフェース１０２６をホストし、さらに、受信インターフェースは、クラウドベースのサービスプロバイダからのサービスの要求として、ユーザデバイスからの入力を受信する。

バス１０１６は、システム１００１の様々なコンポーネントを互いに、システム１００１の任意の他の周辺機器と、及び外部ネットワーク要素、他のマシン、クライアントデバイス、クラウドコンピューティングサービスなどの外部コンポーネントとインターフェースさせる。通信は、ネットワークインターフェースを介してＬＡＮ、ＷＡＮ、又はパブリックインターネットを通じて外部デバイスと通信することをさらに含んでもよい。

このような実施形態によれば、システムはさらに、第２のテナントから第２のユーザプロファイルを作成する要求を受信する上記受信インターフェースと、第２のユーザプロファイルの非保護情報を含むブロックチェーン資産を作成するブロックチェーンサービスインターフェースと、ブロックチェーン資産を含むブロックチェーントランザクションを生成する上記ブロックチェーンサービスインターフェースと、ブロックチェーン上の循環にブロックチェーントランザクションをブロードキャストする上記ブロックチェーンサービスインターフェースと、ブロック内の検証されたブロックチェーントランザクションをブロックチェーンに対してコミットする上記ブロックチェーンサービスインターフェースを含んでもよい。

図１１Ａは、説明される実施形態による、スマートフローコントラクトエンジン１１０５を利用して作成されるブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャ１１００を示す。

詳細には、ここで、スマートフローコントラクトエンジン１１０５を今や含み、ＧＵＩマネージャ１１１０をさらに含むブロックチェーンサービスインターフェース１９０がホスト組織内に示される。

ブロックチェーンは分散台帳を利用するため、スマートコントラクトの作成と実行は、特に初心者ユーザには、技術的に複雑な可能性がある。その結果、スマートフロービジュアルデザイナは、スマートコントラクトの実装をより容易に可能にする。結果として生じるスマートフローコントラクトは、顧客及びユーザが任意の所与のブロックチェーンプロトコルで使用されるプログラミング言語について心配する必要をなくすブロックチェーントランスレータ（blockchain translator）１１３０により作成される、数学的に立証可能な自動生成コードを有する。さらに、スマートフローコントラクトエンジンは、ブロックチェーントランスレータ１１３０と協調してブロックチェーンの参加ノードの各々で実行可能な必須のネイティブコードを生成するビジュアルデザイナを実現し、ゆえに、スマートコントラクトの容易な処理及び立証をさらに可能にする。特定の実施形態によれば、各スマートフローコントラクトは、数学コードに基づく立証可能な暗号化スキームを利用する。

フローデザイナは、ＧＵＩベースのガイド付きフロー設計体験を通してアプリケーション及びカスタマイズされたプロセスフローを設計するための簡素な、直感的な、ウェブベースのインターフェースをユーザに提供する。フローデザイナは、必ずしもコーディング技能を有さず又はブロックチェーンに精通していない初心者ユーザでも、さもなければ複雑な機能を作成することを可能にする。

ＧＵＩマネージャ１１１０は、フローデザイナＧＵＩ１１１１インターフェースをユーザデバイスに提示し、これを介し、ユーザは、ホスト組織と相互作用することができる。スマートフローコントラクトエンジン１１０５は、ＧＵＩマネージャと協調して、ユーザにより提供される様々なルール、条件、及び動作を解釈してスマートフローコントラクトを生成し、これは次いで、ターゲットブロックチェーンプロトコルに翻訳され（translated）、あるいは書き込まれる。

フローデザイナＧＵＩ１１１１を介して、ユーザは、ビジュアルフロー要素を利用して、特定のプロセス、イベント、合意、コントラクト、購入、又は何らかの他のトランザクションがどのように発生する必要があるかを、依存関係、チェック、必要なプロセス入力及び出力、トリガ等を含み、完全に定義することができる。

フローデザイナＧＵＩ１１１１を使用し、ユーザは、動作ブロックを単にドラッグアンドドロップし、様々な条件と「ｉｆ ｔｈｅｎ ｅｌｓｅ」イベント、例えば、このイベントが発生した場合にこのアクションをとる、などを定義する。ここで示されるように、ユーザ定義条件１１５１、モニタリングすべきイベント１１５２、「ｉｆ」ｔｈｅｎ「ｅｌｓｅ」トリガ１１５３、及び資産識別子１１５４を含む様々なユーザ定義のスマートコントラクトブロックが存在する。

ユーザが、その動作ブロック、条件、トリガ、及びイベントの全てを含むフローの定義を完了すると、スマートフローコントラクトエンジンは、個々のブロックの各々を取得し、それらをブロックチェーントランスレータ１１３０を介してネイティブターゲットブロックチェーンプロトコルに翻訳し、次いで、ブロックチェーンサービスインターフェース１９０を介して、翻訳されたスマートフローコントラクト１１４５をブロックチェーン１１４０に書き込むためのトランザクションを生成する。

ブロックチェーンへ処理される（transacted）と、ブロックチェーンでのあらゆる参加ノードはスマートコントラクトのコピーを有することになり、したがって、任意の所与のイベントが発生した場合、対応するトリガ又はルール又は条件が全ての参加ノードに閲覧可能になり、そのうちのいくつかは、次いで、スマートコントラクトにより定義されるイベントに基づいてアクションをとることができる。

ホスト組織のブロックチェーンサービスインターフェース１９０は、顧客、ユーザ、及びサブスクライバに、異なるブロックチェーンへのアクセスを提供し、そのうちいくつかはホスト組織１１０により管理され、例えばプライベートブロックチェーンであり、他はパブリックブロックチェーンであり、このようなパブリックブロックチェーン上のノードとして参加するホスト組織１１０を介してアクセス可能である。いずれにせよ、各ブロックチェーンは、異なるブロックチェーンプロトコルを利用し、様々なルール、構成、及び、可能性として異なる言語を有し、これらを介し、インターフェースは、それぞれのブロックチェーンと通信するために使用しなければならない。結果的に、ここに示されるブロックチェーントランスレータ１１３０は、ユーザ定義のスマートコントラクトブロックを、結果として生じるスマートコントラクトが書き込まれ又は処理されるべきターゲットブロックチェーン１１４０のネイティブの又は必要な言語及び構造に翻訳する。

スマートコントラクトがブロックチェーン１１４５へ処理され、ブロードキャストされると、それはブロックチェーン内で実行され、次いで、ユーザ定義のスマートコントラクトブロックにより定められるその規定が実行され、強制される。

一実施形態によれば、ユーザ定義のスマートコントラクトブロックを生成するために、セールスフォースドットコムのビジュアルフローデザイナが利用され、それらは、次いで、ブロックチェーンスマートコントラクトに翻訳される。他の実施形態によれば、異なるビジュアルフローデザイナが利用され、ブロックチェーントランスレータ１１３０が、ユーザ定義のスマートコントラクトブロックをブロックチェーンスマートコントラクトに翻訳する。

結果として生じるネイティブブロックチェーンプロトコルスマートコントラクト要素１１３５は、スマートコントラクトが書き込まれるべきブロックチェーン１１４０により指示されたコード、構造、又は言語内に具現化されてもよい。例えば、スマートコントラクトがイーサリアムに書き込まれるべき場合、ブロックチェーントランスレータ１１３は、ユーザ定義のスマートコントラクトブロックをイーサリアム準拠の「ソリディティ（Solidity）」プログラミング言語に翻訳しなければならない。ソリディティは、具体的にイーサリアムでスマートコントラクトを実現するためのコントラクト指向の高水準言語である。この言語は、Ｃ＋＋、Ｐｙｔｈｏｎ、及びＪａｖａＳｃｒｉｐｔの影響を受け、イーサリアム仮想マシン（Ethereum Virtual Machine、ＥＶＭ）をターゲットにするように設計されている。スマートコントラクト要素は、投票、クラウドファンディング、ブラインドオークション、マルチシグネチャウォレット、及びその他多くの機能のためのサポートを含む。

逆に、スマートコントラクトがハイパーレジャー（Hyperledger）に書き込まれるべき場合、言語は異なり、他の機能の中でも、スマートコントラクトのための分散台帳ブロックチェーンの使用を可能にするＧｏプログラミング言語を利用する。

スマートコントラクトは有益であり、多くのブロックチェーンプロトコルによりサポートされるが、それらは、ターゲットにされる特定のブロックチェーンに依存して異なる言語でプログラムされるという要件に起因して、実現するのに煩雑な可能性がある。したがって、ユーザは、プログラミング構造だけでなく、問題のブロックチェーンプロトコルに必要なプログラミング言語の特定の構文的ニュアンスも理解しなければならない。

スマートフローコントラクトエンジン１１０５を利用することにより、初心者ユーザでも、フローデザイナでスマートコントラクト要素を生成し、次いでブロックチェーントランスレータ１１３０を利用して、ユーザにより定義されたスマートコントラクト要素を具現化するネイティブブロックチェーンプログラミング言語コードを実際にレンダリングすることにより、準拠したスマートコントラクトを作成することができ、その後、ブロックチェーンサービスインターフェース１９０は、ブロックチェーンへのスマートコントラクトの処理を取り扱う。

例えば、ホームデポに販売し、ホームデポとのイーサリアムを使用するスマートコントラクトを実行したいベンダを考える。ベンダはホスト組織でログインし、ベンダは認証されたユーザであり、クラウドサブスクリプションサービスへのアクセスを有すると仮定し、次いで、スマートフローコントラクトエンジン１１０５にアクセスし、これを介して、ユーザは、自身が望むどんなフローでも生成することができる。完了すると、ユーザは、フローデザイナＧＵＩ１１１１を介して、ブロックチェーンサービスインターフェース１９０にスマートコントラクトを実行するように指示し、ゆえに、スマートフローコントラクトエンジンに、ユーザのカスタム設計のスマートフローコントラクトをイーサリアム準拠の「ソリディティ」コードに翻訳させ、その後、スマートコントラクトは、次いで、実行のためにブロックチェーンに書き込まれる。ベンダは、ブロックチェーンとの処理の詳細をプログラムする方法を知る必要がなく、あるいは理解さえする必要がない。むしろ、ホスト組織１１０を介してアクセス可能なクラウドベースのサービスは、プロセスから複雑さを除去し、ユーザに簡素なフローデザイナＧＵＩ１１１１を提示し、ゆえに、これを介して、全ての必要な動作が実施され得る。

そのような実施形態によれば、スマートコントラクトをブロックチェーンに書き込むことは、特定のブロックチェーンプロトコルによりサポートされるようにブロックチェーンにスマートコントラクトを定義するメタデータを記憶することを要する。一実施形態によれば、トランザクションがブロックチェーン上で発生し、スマートコントラクトのメタデータをその中に有するとき、スマートコントラクトが実行され、次いで、様々なユーザ定義のスマートコントラクトイベント、条件、及び動作が果たされる。

特定の実施形態によれば、ユーザ定義のスマートコントラクトは、翻訳され、ブロックチェーンへ処理され、ホスト組織においてイベントをトリガする。

例えば、ウォルマートとネスレが、貨物は気候制御されたトレーラー内で常時華氏３５〜３９度の範囲内で輸送されなければならないという合意を有することを考える。さらに、温度がいつでも３９度を超えた場合、支払いは取り消される。

ホスト組織内では、顧客関係管理（Customer Relationship Management、ＣＲＭ）プラットフォームが、顧客、ベンダ、潜在顧客、サプライヤ等の間の様々な関係及び相互作用を定義し、管理する。用語ＣＲＭは、ＣＲＭシステムを通常指し、これは、コンタクト管理、販売管理、ワークフロープロセス、生産性などでビジネスに役立つツールである。

上記のウォルマートとネスレの例では、ＣＲＭシステムは、貨物の要件を所持する。ホスト組織がＣＲＭシステムを介して貨物を監視し、温度データなどの貨物イベントをサブスクライブするため、ＣＲＭシステムは、特定の貨物に関する温度関連イベントについて監視し、それを認識し、そのとき次いで、自動的にスマートコントラクトに向けてリンクできる。より詳細には、ホスト組織が、スマートコントラクトが実行されているブロックチェーンの参加ノードとして動作するため、ホスト組織は、ブロックチェーンを介してアクセス可能なスマートコントラクトの取り決め及び条件（terms and conditions）と、さらに要求される温度範囲などの貨物に関するＣＲＭ要件との双方に対して可視性を有する。

したがって、スマートコントラクト条件違反が発生すると、ホスト組織は、その違反をＣＲＭシステム（ブロックチェーンの一部ではない）と同期させて、実行中のスマートコントラクトの条件に従い、その特定の貨物に関連づけられた支払いを停止する。

一実施形態によれば、ブロックチェーンは、ホスト組織のＣＲＭシステムがリッスンするイベントを送出し、次いで、ユーザ定義のスマートコントラクトフローにより指定されるものに従って、イベントに基づいて何らかの実質的なアクションを実行する。上記の例では、実質的なアクションは、ブロックチェーン上のスマートコントラクトに従って貨物に対する支払いを停止することである。

実行中のスマートコントラクトに対する参加当事者の各々は、そのそれぞれのＣＲＭシステムに、実行中のスマートコントラクトに関連づけられたブロックチェーンのイベントをサブスクライブさせている可能性があり、したがって、双方の当事者が、イベントを認識している可能性がある。

一実施形態によれば、ブロックチェーンイベントに応答した特定のアクションを容易にするために、論理がＣＲＭシステムに書き込まれる。言い換えると、非ブロックチェーンアクションが、実行中のブロックチェーンスマートコントラクトに従って実行されてもよい。

図１１Ｂは、説明される実施形態による、Ａｐｅｘ翻訳エンジン（Apex translation engine）１１５５を利用して作成されたブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャ１１０１を示す。

ここで示されるように、ブロックチェーンサービスインターフェース１９０内にＡｐｅｘ翻訳エンジン１１５５が存在する。

Ａｐｅｘは、開発者向けにフォースドットコム（登録商標）（Force.com）プラットフォームにより提供されるプログラミング言語である。Ａｐｅｘは、強く型付けされたオブジェクト指向ベースの言語であり、ドット表記及び波括弧の構文を利用するため、Ｊａｖａ及びＣ＃と類似している。Ａｐｅｘは、スケジューリングを介して、又はビジュアルフォース（Visualforce）ページのカスタムコントローラを介して、カスタムボタンとリンク、レコードの挿入、更新、又は削除におけるイベントハンドラを含むフォースドットコムプラットフォーム上の大抵のプロセスの間のプログラムされた機能を実行するために使用できる。

セールスフォースドットコムのホスト組織の開発者は、Ａｐｅｘを頻繁に利用して、ＳＱＬプログラミング、データベース相互作用、ＧＵＩインターフェースのカスタムイベント、レポート生成、及び多数の他の機能を実現する。結果として、Ａｐｅｘにかなり精通し、あまり精通していないプログラミング言語を利用する必要があるよりもＡｐｅｘ言語でプログラムすることを好む、ホスト組織１１０に関連づけられた開発者の大きいコミュニティが存在する。

問題として、スマートコントラクトは、それぞれのブロックチェーン上の任意のスマートコントラクトの実行に対してターゲットにされているブロックチェーンプロトコルのネイティブ言語で書かれなければならない。

例えば、上述のように、スマートコントラクトがイーサリアムに書き込まれるべき場合、スマートコントラクトは、イーサリアム準拠の「ソリディティ」プログラミング言語で書かれなければならない。

スマートコントラクトと同様に、Ａｐｅｘはメタデータの一種である。したがって、Ａｐｅｘ翻訳エンジン１１５５は、Ａｐｅｘに精通した開発者が、ブロックチェーンに対するそれらのスマートコントラクトを、ネイティブスマートコントラクトプロトコルプログラミング言語を利用するのでなくＡｐｅｘプログラミング言語を利用してプログラムすることを可能にする。

ここに示されるように、開発者は、そのスマートコントラクトをＡｐｅｘプログラミング言語を利用して書き、次いで、図示のＡｐｅｘコードインターフェースを介して、例えば、開発者のＡｐｅｘコードを中に埋め込ませたテキストファイルをアップロードすることにより、Ａｐｅｘ翻訳エンジン１１５５にＡｐｅｘ入力１１５６を提供する。

Ａｐｅｘ翻訳エンジン１１５５は、Ａｐｅｘ入力１１５６をパースして（parses）Ａｐｅｘ定義のスマートコントラクトブロックを識別し、翻訳の準備のためにそれらを取り出す。ここで示されるように、Ａｐｅｘ定義条件１１７１と、監視すべきＡｐｅｘイベント１１７２と、「ｉｆ」ｔｈｅｎ「ｅｌｓｅ」Ａｐｅｘトリガ１１７３と、前述のように、Ａｐｅｘ特有ではない資産識別子１１５４がある。

次いで、Ａｐｅｘ定義のスマートコントラクトブロックは、Ａｐｅｘブロックトランスレータ１１８０に提供され、Ａｐｅｘブロックトランスレータ１１８０は、それらを、ターゲットにされたブロックチェーンプロトコルのネイティブブロックチェーンプロトコルスマートコントラクト要素１１３５に変換する。ひとたび翻訳されると、プロセスは上述のとおりであり、翻訳されたスマートコントラクトは、実行１１４５のためにブロックチェーン１１４０へ処理され、ブロードキャストされる。

ビジュアルフローＧＵＩとは異なり、Ａｐｅｘはプログラム的であるため、Ａｐｅｘコードを書くユーザは、スマートコントラクトで実行するプログラムを書くことができ、ビジュアルフローＧＵＩ内で利用可能な機能により制限されない。

特定の実施形態によれば、Ａｐｅｘ入力１１５６は、ＪａｖａＳｃｒｉｐｔに最初翻訳され、次いでその後、スマートコントラクトが実行されるべきターゲットにされたブロックチェーンプロトコルに適した特定のブロックチェーンＡＰＩに翻訳される。

別の実施形態によれば、リッスンイベント（listening events）がＡｐｅｘ言語を使用して書かれ、Ａｐｅｘ入力１１５６で提供されてもよく、しかしながら、このようなリッスンイベントは、ホスト組織により実行されるべきである。したがって、Ａｐｅｘブロックトランスレータ１１８０は、任意の識別されたＡｐｅｘリスナ１１７８を分離し、これらをホスト組織１１０に返し、そこで、これらは適切なＣＲＭシステム又は他のイベント監視システム内で実現されてもよい。このような方法で、開発者は、Ａｐｅｘ入力１１５６を単一のプログラムとして書くことができ、スマートコントラクトとさらに関連するリッスンイベントを別個のシステムで別個に作成する必要はない。

図１２は、ユーザ、顧客、及びサブスクライバにクラウドベースのオンデマンド機能を提供するために、このような機能を実行するプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境において、分散台帳技術を使用してスマートフローコントラクトを実現する方法１２００を示すフロー図を示す。

方法１２００は、ハードウェア（例えば、回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば、処理デバイス上で実行される命令）を含み得る処理論理により実行されて、本明細書に記載のシステム及び方法に従って実行、送信、受信、解析、トリガ、プッシュ、推奨、定義、取り出し、パース、持続、公開、ロード、動作、生成、記憶、維持、作成、返信、提示、インターフェース、通信、クエリ、処理、提供、決定、表示、更新、送出などの様々な動作を実行し得る。例えば、図１以下に示されるホストされたコンピューティング環境１１１、ブロックチェーンサービスインターフェース１１２０、及びそのデータベースシステム１３０、並びに本明細書に記載する他のシステム及びコンポーネントは、説明される方法論を実現することができる。以下で列挙されるブロック及び／又は動作のいくつかは、特定の実施形態に従って任意である。提示されるブロックの番号付けは明りょうさのためであり、様々なブロックが発生しなければならない動作の順序を規定することは意図されない。

図１２に示す方法１２００を参照し、ブロック１２０５において、処理論理は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させ、複数のテナントの各々は、ブロックチェーンでの参加ノードである。

ブロック１２１０において、処理論理は、ユーザデバイスからログイン要求を受信する。

ブロック１２１５において、処理論理は、ホスト組織でユーザデバイスを認証する。

ブロック１２２０において、処理論理は、複数のスマートコントラクトブロックを示すユーザデバイスからの入力を受信する。

ブロック１２２５において、処理論理は、スマートコントラクトブロックの各々をネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクトを形成する。

ブロック１２３０において、処理論理は、ブロックチェーンへのスマートコントラクトを処理する（transacts）。

別の実施形態によれば、方法１２００はさらに、フローデザイナＧＵＩをユーザデバイスに送信することを含み、ユーザデバイスからの入力を受信することは、フローデザイナＧＵＩを介して、複数のフローシーケンス、フロー条件、フロートリガ、及び／又はフローイベント動作を有する複数のスマートコントラクトブロックのユーザ選択を示す入力を受信することを含む。

方法１２００の別の実施形態によれば、複数のスマートコントラクトブロックを示すユーザデバイスからの入力を受信することは、Ａｐｅｘプログラミング言語でプログラムされたＡｐｅｘ入力ファイルを受信することを含み、本方法は、Ａｐｅｘ入力ファイルからの複数のＡｐｅｘ定義のスマートコントラクトブロックをパースすることをさらに含み、スマートコントラクトブロックの各々を翻訳することは、複数のパースされたＡｐｅｘ定義のスマートコントラクトブロックをネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクトを形成することを含む。

方法１２００の別の実施形態によれば、スマートコントラクトブロックの各々をネイティブプログラミング言語に翻訳して、スマートコントラクトを形成することは、複数のスマートコントラクトブロックの各々を、スマートコントラクトのためのプロセス動作の定義されたシーケンス、定義されたスマートコントラクト条件、定義されたスマートコントラクトトリガ、及び／又は定義されたスマートコントラクトイベントに翻訳することを含む。

方法１２００の別の実施形態によれば、ブロックチェーンへのスマートコントラクトを処理することは、スマートコントラクトをホスト組織のブロックチェーンサービスインターフェースを介してメタデータとしてブロックチェーンに書き込むことを含み、スマートコントラクトは、ブロックチェーンを介して、ブロックチェーン上で発生する１つ以上のトランザクションに対して実行される。

別の実施形態によれば、方法１２００はさらに、ユーザから受信した入力からイベントリスナ（event listener）を抽出することであり、イベントリスナは、ブロックチェーンへ処理されたスマートコントラクト内の対応するスマートコントラクト条件又はスマートコントラクトトリガを有する定義されたイベントについてブロックチェーントランザクションを監視する、ことと、ブロックチェーンと別個のイベントリスナを実行することであり、イベントリスナはホスト組織内で実行され、ブロックチェーン上のトランザクション内のイベントの発生においてホスト組織内で予めプログラムされたアクションをトリガする、ことを含む。

方法１２００の別の実施形態によれば、イベントリスナは、ブロックチェーン上で実行されるスマートコントラクトへの参加当事者であるホスト組織のテナントのためにホスト組織のＣＲＭプラットフォーム内で実行され、イベントの実行は、ブロックチェーン内で実行されるスマートコントラクトにより定義される取り決め又は条件の違反に従ってＣＲＭシステムを介して支払いを停止すること、又はブロックチェーン内で実行されるスマートコントラクトにより定義される全ての取り決め及び条件の履行に従ってＣＲＭシステムを介して支払いを承認すること、のうち１つを含む。

方法１２００の別の実施形態によれば、スマートコントラクトブロックの各々をネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクトを形成することは、スマートコントラクトブロックの各々を、イーサリアム準拠のソリディティプログラミング言語に翻訳することを含み、ホスト組織は、ホスト組織のブロックチェーンサービスインターフェースを介してイーサリアムブロックチェーン上の参加ノードを動作させ、ブロックチェーンへのスマートコントラクトを処理することは、イーサリアムブロックチェーンを介した実行のために参加ノードを介してイーサリアムブロックチェーンへのスマートコントラクトを処理することを含む。

方法１２００の別の実施態様によれば、スマートコントラクトブロックの各々をネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクトを形成することは、スマートコントラクトブロックの各々をハイパーレジャー準拠のＧｏプログラミング言語に翻訳することを含み、ホスト組織は、ホスト組織のブロックチェーンサービスインターフェースを介してハイパーレジャーブロックチェーン上の参加ノードを動作させ、ブロックチェーンへのスマートコントラクトを処理することは、ハイパーレジャーブロックチェーンを介した実行のために参加ノードを介してハイパーレジャーブロックチェーンへのスマートコントラクトを処理することを含む。

方法１２００の別の実施形態によれば、複数のスマートコントラクトブロックを示すユーザデバイスからの入力を受信することは、フローデザイナＧＵＩをユーザデバイスにおける表示のためにホスト組織のＧＵＩマネージャからユーザデバイスに送信することと、ユーザデバイスに表示されたフローデザイナＧＵＩにおいて、利用可能なスマートコントラクト条件、トリガ、及びフローデザイナＧＵＩを介して利用可能なイベントの、ドラッグアンドドロップ選択及び順序付けを示すマウス移動イベントを受信することを含む。

図１３は、実施形態が動作し、設置され、統合され、又は構成され得るシステム１３０１の概略表現を示す。一実施形態によれば、本明細書に記載される方法論のための実装アプリケーションコード１３９６を実行するための少なくともプロセッサ１３９０及びメモリ１３９５をその中に有するシステム１３０１が存在する。このようなシステム１３０１は、ホスト組織、マルチテナント環境、オンデマンドサービスプロバイダ、クラウドベースのサービスプロバイダ、クライアント‐サーバ環境などのホストされたコンピューティング環境と通信上インターフェースし、該コンピューティング環境の恩恵を受けて協同的に実行することができる。

図示の実施形態によれば、ホスト組織内で動作し得るシステム１３０１は、システム１３０１で命令を実行するためのプロセッサ１３９０及びメモリ１３９５を含む。このような実施形態によれば、プロセッサ１３９０は、ホスト組織の複数のテナントのためにブロックチェーンとインターフェースするブロックチェーンサービスインターフェース１３６５であり、複数のテナントの各々は、ブロックチェーンでの参加ノード１３９９である、ブロックチェーンサービスインターフェースと、ユーザデバイス１３９８からログイン要求を受信する受信インターフェース１３２６と、を実行する。このような実施形態によれば、ホスト組織でユーザデバイス１３９８を認証する認証器１３５０が存在する。受信インターフェース１３２６は、複数のスマートコントラクトブロックを示すユーザデバイス１３９８からの入力１３２７をさらに受信し、トランスレータ（及びパーサ（parser））１３４３は、スマートコントラクトブロックの各々をスマートフローコントラクトエンジンのためにネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクト１３４０を形成する。次いで、ブロックチェーンサービスインターフェース１３６５は、ブロックチェーンへのスマートコントラクト１３４０を処理する。

システム１３０１の別の実施形態によれば、システムは、フローデザイナＧＵＩ１３４１をユーザデバイスに送信するＧＵＩマネージャ１３８５をさらに含み、受信インターフェースは、フローデザイナＧＵＩを介して、複数のフローシーケンス、フロー条件、フロートリガ、及び／又はフローイベント動作を有する複数のスマートコントラクトブロック１３８６のユーザ選択を示す入力１３２７を受信する。

システム１３０１の別の実施形態によれば、受信インターフェース１３２６は、システムから遠隔のユーザクライアントデバイス１３９８と通信し、パブリックインターネットを介してユーザデバイスをシステムと通信上リンクする。このような実施形態によれば、システムは、ユーザデバイス１３９９に対するクラウドベースのサービスプロバイダとしてホスト組織で動作し、クラウドベースのサービスプロバイダは、パブリックインターネットを介してユーザクライアントデバイスに公開された受信インターフェース１３２６をホストし、さらに、受信インターフェースは、クラウドベースのサービスプロバイダからのサービスの要求として、ユーザデバイスからの入力を受信する。

バス１３１６は、システム１３０１の様々なコンポーネントを互いに、システム１３０１の任意の他の周辺機器と、及び外部ネットワーク要素、他のマシン、クライアントデバイス、クラウドコンピューティングサービスなどの外部コンポーネントとインターフェースさせる。通信は、ネットワークインターフェースを介してＬＡＮ、ＷＡＮ、又はパブリックインターネットを通じて外部デバイスと通信することをさらに含んでもよい。

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するホスト組織のシステムにより実行されたときに、命令はシステムに、以下の動作：ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、複数のテナントの各々は、ブロックチェーンでの参加ノードである、ことと、ユーザデバイスからログイン要求を受信することと、ホスト組織でユーザデバイスを認証することと、複数のスマートコントラクトブロックを示すユーザデバイスからの入力を受信することと、スマートコントラクトブロックの各々をネイティブプログラミング言語に翻訳して、ブロックチェーンを介して実行すべきスマートコントラクトを形成することと、ブロックチェーンへのスマートコントラクトを処理することと、を実行させる。

図１４は、説明される実施形態による、クラウドベースのコンピューティング環境を介して分散台帳技術に関してインターフェースするために利用される仮想チェーンモデルのさらなる詳細を有する別の例示的なアーキテクチャ１４００を示す。

ここでは、前述したようなホスト組織とその様々な要素が示されるが、ブロックチェーンサービスインターフェース１９０内に仮想チェーンインターフェース１４０５がさらに示されており、これは、それらがホスト組織が参加ノードとして動作するパブリックブロックチェーンである場合のブロックチェーンプロトコル実装、又はホスト組織１１０により提供されるパブリックブロックチェーンプロトコル実装、若しくはホスト組織１１０により提供されるプライベートブロックチェーンをサポートする代わりのプログラム的インターフェースを提供する。

分散台帳技術を利用してプライベート及びパブリックのブロックチェーンとインターフェースする開発者は、従来、彼ら自身の選択のプログラミング言語を利用する能力を有するよりも、それらのブロックチェーンのネイティブプログラミング言語を利用する必要があった。この要件は、自分達がほとんと精通していない言語を使用してプログラムすることを要求され得る開発者にいくらかの困難もたらし、ゆえに、ブロックチェーン技術の使用を妨げる。

ホスト組織１１０内では、開発者が、ＳＱＬ又はＰＬ／ＳＯＱＬなどの構造化問い合わせ言語（structured query language）を利用してクエリインターフェース１８０を介してデータベースシステム１３０と相互作用することはかなり一般的である。

したがって、上述した実施形態によれば、ホスト組織１１０は、関係データベースにクエリするために通常利用される通常のＳＱＬクエリと同様の構文を利用して仮想チェーンインターフェース１４０５を介してブロックチェーンと相互作用する能力を提供する。

ここで示されるように、仮想チェーンインターフェース１４０５は、ブロックチェーンをターゲットにしているユーザから構造化クエリ１４０６を受信し、次いで、構造化クエリ１４０６をクエリパーサ１４２５を介してルーティングすることができ、クエリパーサ１４２５は、構造化クエリ１４０６の要素を分解する。例えば、ここで示されるクエリパーサ１４２５は、構造化クエリ１４０６をブロックチェーン更新論理１４２１、ブロックチェーン読み出し論理１４２２、ブロックチェーン削除論理１４２３（例えば、データベースから行を除去することと同等）、及びブロックチェーン検索論理１４２４に分解し、識別されるクエリ要素が、ユーザから仮想チェーンインターフェース１４０５で受信した構造化クエリからパースされる結果をもたらす。

次いで、識別されたクエリ要素は、クエリ論理トランスレータ１４３０によって対応するネイティブブロックチェーン機能、コード、又は論理にマッピングされ、結果として、ネイティブブロックチェーンプロトコルコード１４３５が構造化クエリ１４０６の同等機能を構成し、ゆえに、次いでブロックチェーン１４４０へ処理されるネイティブブロックチェーントランザクション１４４５が仮想チェーンインターフェースへのトランザクション結果のリターンをトリガする結果をもたらす。

一実施形態によれば、仮想チェーンインターフェース１４０５は、ブロックチェーンを模倣するエントリ及び変換の仮想テーブル又はリストを提供し、ゆえに、仮想テーブルに基づいて、ネイティブブロックチェーンコード又は機能に置き換えられるべき構造化クエリ１４０６内の動作要素のマッピング、変換、又は翻訳を可能にする。

機能要素が、入ってくる構造化クエリからネイティブのブロックチェーン機能に変換されると、結果として生じるネイティブブロックチェーントランザクションは、例えば、トランザクションをブロードキャストし、トランザクションをブロックチェーンのブロックに書き込み、ブロックを検証し、次いで検証されたブロックをブロックチェーンに対してコミットすることにより、ブロックチェーンを介して単に実行される。

一実施形態によれば、仮想チェーンインターフェースで受信された構造化クエリ１４０６は、標準ＳＱＬ構文を使用して書き込まれるが、舞台裏でユーザに見えず、仮想チェーンインターフェース１４０５は、ユーザと、ブロックチェーンに対して適切に形成されたトランザクションを生成するために利用される構造化クエリ要素に基づいて、文脈的に関連する情報を識別する。

例えば、ＳＱＬ ＩＮＳＥＲＴ文を提供する受信した構造化クエリ１４０６を考える。通常、構文は、ＩＮＳＥＲＴ ＩＮＴＯ ｔａｂｌｅ＿ｎａｍｅ（ｃｏｌｕｍｎ１， ｃｏｌｕｍｎ２， ｃｏｌｕｍｎ３， ．．．）であるが、仮想チェーンインターフェースは、ＩＮＳＥＲＴコマンドを適切なネイティブブロックチェーンコマンドに翻訳する。コマンドは、利用されるブロックチェーンプロトコル及びインターフェーススクリプトに依存して異なるが、ブロックチェーンへデータを挿入する１つのそのようなコマンドは、ＯＰ＿ＲＥＴＵＲＮ ＜あなたが追加したいデータ＞である。したがって、ＩＮＳＥＲＴは、ＯＰ＿ＲＥＴＵＲＮに変換され、ＩＮＴＯは、メタデータ、コントラクト、ブロックチェーン資産などのターゲット位置に変換され、これは、サブミッタが特定のブロックチェーン要素に関連づけられるとき、ユーザが構造化クエリをサブミットした文脈を仮想チェーンインターフェースが理解することにより、自動的に識別されてもよい。

同様に、ユーザがＵＰＤＡＴＥコマンドを指定する構造化クエリ１４０６を提示した場合、ＵＰＤＡＴＥコマンドをブロックチェーンの関連コマンドに変換することが必要であり、なぜならば、ブロックチェーンの不変性は、チェーンに受け入れられたブロックは決して修正できないことを意味するためである。結果的に、構造化クエリ１４０６のＵＰＤＡＴＥコマンドは、追加に変換されなければならない。したがって、ユーザが例えば、ＵＰＤＡＴＥ ｔａｂｌｅ＿ｎａｍｅ，ＳＥＴ ｃｏｌｕｍｎ１＝ｖａｌｕｅ１，ｃｏｌｕｍｎ２＝ｖａｌｕｅ２，．．．，ＷＨＥＲＥ条件を指定した場合、仮想チェーンインターフェースは、入ってくる構造化クエリ要素を挿入ブロックコマンドに翻訳し、例えば、必要なユーザ鍵及びブロックチェーンで処理するために必要な任意の他の形式的手続きを追加することを含む、必要なユーザ管理を埋める。

例えば、ホスト組織はブロックチェーン上のノードとして動作し、したがってブロックチェーン内のデータへのアクセスを有するが、ブロックチェーントランザクションは、データが（例えば、古いデータに取って代わる新しい追加を介して）追加又は修正される場合、適切な参加ノードから実行される必要がある。したがって、仮想チェーンインターフェースはさらに、構造化クエリ１４０６のユーザＩＤ又は要求者を参加ノードにマッピングし、入ってくる構造化クエリ１４０６のユーザＩＤ又は要求者に対応する参加ノードからのネイティブブロックチェーントランザクションを処理する。

同様に、ユーザが、例えば、ＳＥＬＥＣＴ ｃｏｌｕｍｎ１， ｃｏｌｕｍｎ２， ．．． ＦＲＯＭ ｔａｂｌｅ＿ｎａｍｅを指定するなど、構造化クエリＳＥＬＥＣＴ ＦＲＯＭコマンドを介して指定する場合、仮想チェーンインターフェースは、クエリ要素を、ｔａｂｌｅ＿ｎａｍｅフィールドを適切なブロックチェーン資産、メタデータ、又は他の読み出し可能な記憶位置に翻訳又はマッピングすることを含む、ブロックチェーンからデータを取り出すのに必要な適切なブロックチェーンネイティブプロトコルコードに到達し、翻訳する。例えば、構造化クエリがオブジェクトを指定する場合、仮想チェーンインターフェースは、ターゲットオブジェクト名を対応するブロックチェーン資産に翻訳し、次いで、該ブロックチェーン資産から、ブロックチェーンのペイロードデータが読み出され、構造化クエリへのリプライで返される。

したがって、ユーザ又は顧客の観点から、構造化クエリは、ユーザ又は顧客が参加ノードを有する指定されたブロックチェーン分散台帳をターゲットにしたアプリケーション、レポート、及びアドホック内でプログラムされてもよく、仮想チェーンインターフェースは、ユーザからのさらなる関与又は技術的ノウハウを必要とすることなく、構造化クエリの、必須のネイティブブロックチェーンプロトコルコード１４３５への変換を透過的に取り扱う。

記載される実施形態によれば、指定されたブロックチェーン内にデータを記憶させたホスト組織の各テナントは、ブロックチェーンでの少なくとも１つの参加ノードを有するが、ホスト組織の特定のテナントは、単一のブロックチェーン上に複数の参加ノードを有してもよい。

例えば、複数の異なるプロダクト又はプロダクトラインを有するホスト組織のテナントが、各プロダクト又はプロダクトラインについてブロックチェーンでの区別可能な参加ノードを有することを選択してもよく、したがって、構造化クエリにより参照される「ｔａｂｌｅ＿ｎａｍｅ」は、複数が存在する場合、テナントの適切な参加ノード及びブロックチェーン資産にマッピングされる。別の実施形態において、ホスト組織の単一のテナントが、複数の顧客組織を有してもよく、したがって、そのようなテナントは、各顧客組織を、ブロックチェーンでのその独自の参加ノードに編成してもよく、その場合、仮想チェーンインターフェースは、構造化クエリ１４０６内の指定されたテーブル名又はオブジェクトを、構造化クエリをサブミットするために使用されるテナントのＯｒｇＩＤに基づいて、ブロックチェーンでの参加ノードにマッピングする。

他の実施形態において、単一のテナントが、複数の異なるブロックチェーンを利用してもよく、したがって、仮想チェーンインターフェースは、指定されたテーブル名又はオブジェクトをターゲットブロックチェーンに、及びターゲットブロックチェーンでの参加ノード及びブロックチェーン資産にマッピングする必要がある。例えば、金融プライベートブロックチェーンを利用して金融関連情報を記憶し、プライベート出荷ブロックチェーンなどの異なるブロックチェーンを利用してサプライチェーンデータを記憶するホスト組織のテナントとして、ウォルマートを考える。このような場合、ウォルマートは、金融プライベートブロックチェーンとプライベート出荷ブロックチェーンの各々に参加することになり、ゆえに、ウォルマートは、少なくともこれら２つの参加ノードを有することになる。結果的に、仮想チェーンインターフェースは、ＳＱＬコマンドで指定された任意の指定されたテーブル名又は記憶位置を、適切なブロックチェーンと、ターゲットブロックチェーンでの参加ノード及びブロックチェーン資産にマッピングしなければならない。

このようにして、ユーザ、顧客組織、及びテナントは、翻訳がユーザのために仮想チェーンインターフェース１４０５により取り扱われるとき、ネイティブブロックチェーンプロトコルコードを理解する必要なく、「ＳＥＬＥＣＴ ＦＲＯＭ」この「オブジェクト」、又は「ＩＮＳＥＲＴ ＢＬＯＣＫ」、又は「ＵＰＤＡＴＥ ＢＬＯＣＫ」などのコマンドを発行することができる。さらに、ユーザがホスト組織で認証されるため、仮想チェーンインターフェースは、必須の資産ＩＤを提供し、自動的に埋めるなど、ブロックチェーンで処理するのに必要な全てのバックエンド管理も取り扱う。

かなり最初のトランザクションでは、仮想チェーンインターフェースは、ブロックチェーンに挿入コマンドを実行して新しい参加ノードを作成する必要があるが、ひとたび作成されると、ブロックチェーン内のエントリは決して除去されないため、それ以降には既存の参加者が使用されてもよい。例えば、ユーザがターゲットブロックチェーン上でトランザクションを一度も実行したことがない場合、仮想チェーンインターフェースは管理タスクを扱って、そのユーザのクレデンシャルに基づいてブロックチェーンに参加者を作成し、次いで、全てのトランザクションが鍵に基づくとき、そのユーザの鍵をブロックチェーンでの使用のために生成する。ひとたび完了すると、仮想チェーンインターフェースは、構造化クエリをマッピングに基づいてブロックチェーンの資産ペイロードとして参照されるステートメントに翻訳する。

特定の実施形態によれば、仮想チェーンインターフェースはさらに、ブロックチェーンとの同期を取り扱い、したがって、例えば、合意がまだ達せられていないブロックチェーン上の保留中の（pending）トランザクションと、合意を有する検証されたトランザクションとの間の差を認識することは、ブロックチェーンに対してコミットされたトランザクションとみなされてもよい。例えば、保留中のトランザクションがサブミットされても決して合意に達しない場合、仮想チェーンインターフェースは、ロールバックトランザクションの同等物を取り扱う。ＳＱＬでは、「ＲＯＬＬＢＡＣＫ」は、最後のＢＥＧＩＮ ＷＯＲＫ又はＳＴＡＲＴ ＴＲＡＮＳＡＣＴＩＯＮからの全てのデータ変更を関係データベース管理システム（relational database management systems、ＲＤＢＭＳ）により破棄させるコマンドであり、それにより、データの状態は、それら変更が行われる前の状態に「ロールバックされる」。同様に、ブロックチェーン参加ノードにブロードキャストされる、ブロックに書き込まれたトランザクションであり、該ブロックがその後、（例えば、合意、プルーフオブワーク等に基づいて）異なるブロックの方を選んで無効にされ、切り捨てられ、又は無視される、トランザクションは、ブロードキャストされたトランザクションが事実上取り消される結果をもたらし、ゆえに、仮想チェーンインターフェース１４０５は、ステータスを追跡し、そのような失敗状態を反映して、ブロックチェーンと構造化クエリ要求者との間の同期を維持する。

例えば、構造化クエリが保留中のトランザクションから読み出し、該トランザクションを更新し、又は何らかの方法で該トランザクションに影響を与える、該クエリをサブミットしたユーザに、情報が返される。そのようなクエリをサブミットすると、ユーザは、トランザクションが投稿されたが保留中のコミット上にあることを示す情報を提示される。

ひとたびトランザクションがブロックチェーンにコミットされると、ユーザは、そのとき初めて、保留中の／コミットされていないトランザクションとしてのみ取り出し可能であるのと対比して、それがコミットされたトランザクションとして取り出し可能であることがわかる。

仮想チェーンインターフェース１４０５はさらに、ブロックチェーンでのスマートコントラクト締結をサポートし、それにより、定義されたイベントがブロックチェーン上のトランザクション内で発生した場合、スマートコントラクト全体がブロックチェーンを介して実行される。仮想チェーンインターフェース１４０５は、指定されたイベントを自動的にリッスンし、次いで、これらのイベントがブロックチェーン上で発生していることを観察されたとき、予め定義されたアクションを実行する。

例えば、利用可能なブロックチェーンプロトコルと互換性がないＳＱＬ ＳＥＬＥＣＴ ＦＲＯＭ文を考える。例えば、構造化クエリがＳＥＬＥＣＴ ａ， ｂ， ｃ ＦＲＯＭ， ｆｉｎａｎｃｉａｌ ａｃｃｏｕｎｔ＿Ｂを指定した場合、「Ｂ」はブロックチェーン内の識別子として解釈される。同様に、修正されたドット表記が利用されてもよく、ＳＥＬＥＣＴ「ＩＤ」ＦＲＯＭ ｂｌｏｃｋｃｈａｉｎ＿ｆｉｎａｎｃｉａｌ ａｃｃｏｕｎｔ＿Ｂのそのような指定は、ゆえに、先導する「ブロックチェーン」を利用されるべきターゲットブロックチェーンとして解釈し、仮想チェーンインターフェースは適切な参加ノードを識別し、「Ｂ」は指定されたブロックチェーンでの識別子として解釈され、識別子は、データを取り出すべきブロックチェーン内の特定のペイロードを表す。

仮想チェーンインターフェース１４０５はさらに、ブロックチェーン内の全ての資産にわたり、その特定の顧客のためにブロックチェーンから最新のトランザクションを、又はブロックチェーンから最新のブロックを引き出すことにより、そのマッピングを維持する。

別の実施形態によれば、仮想チェーンインターフェース１４０５は、ブロックチェーンからの履歴データの取り出しをサポートする。例えば、ｆｉｎａｎｃｉａｌ＿ａｃｃｏｕｎｔ＿ｈｉｓｔｏｒｙ＿ｂを指定するエンティティについて、仮想チェーンインターフェース１４０５は、ネイティブブロックチェーンプロトコルコードを生成して、指定されたブロックチェーン内でその指定された資産に対してこれまで発生した全てのトランザクションを引き出し、ゆえに、ある時間にわたり生じた一連のトランザクションを返す。コミットされた更新の後にデータを上書きし得るデータベースとは異なり、ブロックチェーンは決して情報を破棄せず、したがって、最新の現在の情報を取り出すことができ、あるいは完全な履歴情報を取り出すこともできる。

例えば、顧客を追加するトランザクションを考える。第１のトランザクションは、顧客の姓名を指定しているがＳＳＮが欠けている。次いで、第２のトランザクションは、ブロックチェーンに追加されるＳＳＮを指定している。次いで、第３のトランザクションは、顧客のコンタクト情報を更新する。次いで、第４のトランザクションは、顧客の電話番号を変更する。これらのトランザクションの全てが同じ顧客資産に適用されるが、４つ全てがブロックチェーンで区別可能なトランザクションである。結果的に、構造化クエリは、ＳＥＬＥＣＴ ａ，ｂ，ｃ ｆｒｏｍ ｃｕｓｔｏｍｅｒ＿ｂを指定することができ、結果として、最後の最新の情報がその顧客に返されることになる。しかしながら、構造化クエリが代わりに、ＳＥＬＥＣＴ ａ，ｂ，ｃ ｆｒｏｍ ｃｕｓｔｏｍｅｒ＿ｈｉｓｔｏｒｙ＿ｂを指定した場合、仮想チェーンインターフェース１４０５は、ｃｕｓｔｏｍｅｒ＿ｂに対する全ての変更の履歴レコード全体を取り出し、それにより、第１のトランザクションに従った初期エントリはＳＳＮが欠けていたこと、第４のトランザクションは顧客の電話番号の変更を結果としてもたらしたこと、最終的にはそのブロックチェーン資産についての最後の最新の情報で終わっていることを閲覧でき得る。

特定の実施形態によれば、仮想チェーンインターフェース１４０５は、パースされた構造化クエリ要素とネイティブブロックチェーンプロトコルコードとの間の全てのマッピングを自動的に取り扱うが、代替的な実施形態において、顧客が、顧客の情報、テーブル名、変数、参加者ＩＤ、及びクエリ要素から対応するネイティブブロックチェーンプロトコルコード１４３５要素へのマッピングを提供してもよい。例えば、顧客提供マッピングを介して、顧客は、マッピングの一部としてエンティティ、テーブル、又はデータベースオブジェクトなどのオブジェクトを定義してもよい。しかしながら、顧客定義オブジェクトはマッピングの一部として存在し、データベース又はブロックチェーン内に存在しないため、それは仮想エンティティと見なされ得る。例えば、管理者が、仮想チェーンインターフェース１４０５を介してエンティティを定義し、ユーザ及び任意の必要な構成フィールド又はカスタム定義マッピングを定義してもよい。

例えば、顧客は、ホスト組織内のテーブル「Ｘ」にデータを記憶することができるが、それは、ブロックチェーンに入るときＸ＋Ｙにマッピングされ、これは、ユーザ指定されてもよい。したがって、仮想チェーンインターフェースは、ＳＱＬタイプのコマンドを顧客提供マッピングに基づいてＸ＋Ｙと呼ばれるブロックチェーンデータにマッピングする。このようなマッピングは、顧客のためにメタデータとして、例えば、仮想チェーンインターフェースにより読み出される構成ファイル内に記憶されてもよい。

顧客は、ＡＢＣと呼ばれるブロックチェーンのデータを有し、次いで、何らかの理由で、データをＡ１Ｂ１Ｃ１に変更したい場合がある。顧客は、そのようなマッピングを指定することができ、仮想チェーンインターフェースは、次いで、ブロックチェーンにおける資産追加トランザクションを自動的に生成し、ユーザのためにトランザクションを保留にする。それにより、ユーザは、トランザクションが保留状態であることと、合意が達せられ、トランザクションがブロックチェーンに対してコミットされるように十分なマイニングが生じるまでコミットされないことがわかる。

ひとたびコミットされると、ホスト組織のブロックチェーンサービスインターフェース１９０がリッスンするブロックチェーンからイベントがトリガされ、その時点で、ホスト組織もまたデータをコミットされたものとしてマークし、データステータスの同期を保つ。

さらに、合意が達せられず、したがってトランザクションが失敗することもあり得る。再度、ホスト組織のブロックチェーンサービスインターフェース１９０は、トランザクションの失敗を示すイベントをリッスンし、その時点で、ホスト組織は、トランザクションを失敗したものとしてマークし、仮想チェーンインターフェースは、任意の必要なロールバック動作を実行して同期を維持する。

さらに、何らかの他の参加ノードが、資産の古いデータに取って代わる更新情報をブロックチェーンに追加することも実現可能である。データが、取り出されるべきデータを要求する構造化クエリに従って仮想チェーンインターフェースにより読み出されることを含み、任意の参加ノードによりリフレッシュされるとき、どのエンティティが値を更新したかにかかわらず、最新の値が取り出される。データは分散台帳内に記憶されるため、正しい鍵を指定する任意の参加ノードが、そのような実施形態に従ってブロックチェーン資産を更新するトランザクションをサブミットすることができる。

別の実施形態によれば、ホスト組織のブロックチェーンサービスインターフェース１９０は、指定されたブロックチェーン資産に対する任意のイベント又は変更をリッスンし、そこでイベントがトリガされることになり、したがって、指定された資産への変更に従う通知を要求したユーザは、データを取り出しに行き、変更が行われたかをチェックして判定する必要なく、ホスト組織により通知される。

例えば、仮想チェーンインターフェースにより実行されるトランザクション管理の一部として、資産がブロックチェーン内に作成されるときはいつでも、ブロックチェーンサービスインターフェース１９０は、ブロックチェーン資産ＩＤをセールスフォースＩＤと一緒に保持し、それにより、コミット及び非コミットステータスを追跡することができる。したがって、その特定の資産のためのセールスフォースＩＤを有するブロックチェーン資産ＩＤは、別のエンティティによる任意の変更のために監視することもできる。

特定の実施形態によれば、ブロックチェーン資産内のデータは、ホスト組織の参加ノードを介してホスト組織内で利用可能であり、したがって、最新のコピーは、データがコミットされたと仮定して、分散台帳からホスト組織が常時利用可能である。

一実施形態によれば、ホスト組織で認証するユーザは、仮想チェーンインターフェースがそのユーザのホスト組織識別子をブロックチェーンにより利用される暗号ＩＤに文脈的にマッピングする結果をもたらす。このような方法では、暗号ＩＤが仮想チェーンインターフェース１４０５により全てのトランザクションに対して供給されるので、ユーザはそれを知り又は提供する必要がない。

図１５は、ユーザ、顧客、及びサブスクライバにクラウドベースのオンデマンド機能を提供するために、このような機能を実行するプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境において、分散台帳技術のための仮想チェーンモデルを実現する方法１５００を示すフロー図を示す。

方法１５００は、ハードウェア（例えば、回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば、処理デバイス上で実行される命令）を含み得る処理論理により実行されて、本明細書に記載のシステム及び方法に従って実行、送信、受信、解析、トリガ、プッシュ、推奨、定義、取り出し、パース、持続、公開、ロード、動作、生成、記憶、維持、作成、返信、提示、インターフェース、通信、クエリ、処理、提供、決定、表示、更新、送出などの様々な動作を実行し得る。例えば、図１以下に示されるホストされたコンピューティング環境１１１、ブロックチェーンサービスインターフェース１１５０、及びそのデータベースシステム１３０、並びに本明細書に記載する他のシステム及びコンポーネントは、説明される方法論を実現することができる。以下で列挙されるブロック及び／又は動作のいくつかは、特定の実施形態に従って任意である。提示されるブロックの番号付けは明りょうさのためであり、様々なブロックが発生しなければならない動作の順序を規定することは意図されない。

図１５に示す方法１５００を参照し、ブロック１５０５において、処理論理は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させ、複数のテナントの各々は、ブロックチェーンでの参加ノードである。

ブロック１５１０において、処理論理は、ユーザデバイスからログイン要求を受信する。

ブロック１５１５において、処理論理は、ホスト組織でユーザデバイスを認証する。

ブロック１５２０において、処理論理は、認証されたユーザデバイスを、認証されたユーザデバイスに対応するブロックチェーンの暗号ＩＤと相関させる。

ブロック１５２５において、処理論理は、ブロックチェーンに対して実行されるべきユーザデバイスからの構造化クエリを受信し、構造化クエリは、トランザクションコマンドと、トランザクションコマンドが実行されるべきデータオブジェクトを指定する。

ブロック１５３０において、処理論理は、構造化クエリのトランザクションコマンドをネイティブブロックチェーンプロトコルコードに翻訳し、データオブジェクトをブロックチェーン内に記憶されたブロックチェーン資産ＩＤに翻訳して、ネイティブブロックチェーントランザクションを形成する。

ブロック１５３５において、処理論理は、ブロックチェーンでネイティブブロックチェーントランザクションを実行する。

方法１５００の別の実施形態によれば、構造化クエリを介して指定されるデータオブジェクトは、ホスト組織オブジェクトＩＤを介して指定され、データオブジェクトをブロックチェーン資産ＩＤに翻訳することは、ホスト組織の仮想チェーンインターフェースにより維持される１：１マッピングに基づいて、ホスト組織オブジェクトＩＤをブロックチェーン資産ＩＤに翻訳することを含む。

方法１５００の別の実施形態によれば、認証されたユーザデバイスを、認証されたユーザデバイスに対応するブロックチェーンの暗号ＩＤと相関させることは、ホスト組織でユーザデバイスを認証するために利用されるｕｓｅｒＩＤに基づいて、又は認証されたユーザデバイスに文脈的に関連づけられた顧客組織ＩＤ（ＯｒｇＩＤ）に基づいてブロックチェーンの暗号ＩＤを識別することを含み、ユーザデバイスは、ＯｒｇＩＤに関連づけられた顧客組織の認証されたメンバである。

別の実施形態によれば、方法１５００はさらに、構造化クエリからの複数のクエリ要素をクエリパーサを介してパースしてクエリ要素を識別することと、パースされたクエリ要素をクエリ論理トランスレータを介してネイティブブロックチェーンプロトコルコードに翻訳してネイティブブロックチェーントランザクションを形成することを含む。

方法１５００の別の実施形態によれば、ネイティブブロックチェーントランザクションは、ユーザデバイスから受信された構造化クエリに基づいて暗号ＩＤ、ブロックチェーン内に記憶されたブロックチェーン資産ＩＤ、及び資産ＩＤのペイロードから追加され又は取り出されるべきデータを指定する。

方法１５００の別の実施形態によれば、ブロックチェーンでネイティブブロックチェーントランザクションを実行することは、ブロックチェーンを介して非同期トランザクションを実行することと、ネイティブブロックチェーントランザクションのステータスを追跡して、ネイティブブロックチェーントランザクションが保留中か、コミットされているか、又は失敗しているかを判定する。

別の実施形態によれば、方法１５００はさらに、構造化クエリを介して指定されたデータオブジェクトに対応するホスト組織オブジェクトＩＤと共にブロックチェーン資産ＩＤを双方維持し、ブロックチェーン資産ＩＤに関連づけられたブロックチェーン内の任意のイベントをサブスクライブすることによりブロックチェーン資産ＩＤに基づいてネイティブブロックチェーントランザクションのステータスを追跡することと、ブロックチェーン資産ＩＤに関連づけられたブロックチェーンからイベントを受信することと、ブロックチェーン資産ＩＤをホスト組織オブジェクトＩＤに相関させることと、イベントをユーザデバイスに通知することであり、イベントは、（ｉ）ネイティブブロックチェーントランザクションが保留中のままである、（ｉｉ）ネイティブブロックチェーントランザクションがブロックチェーンに対してコミットされている、又は（ｉｉｉ）ネイティブブロックチェーントランザクションが失敗した、のうち１つを指定する、ことを含む。

別の実施形態によれば、方法１５００はさらに、ネイティブブロックチェーントランザクションが失敗したと判定することと、ネイティブブロックチェーントランザクションが失敗したことをユーザデバイスに通知することを含むネイティブブロックチェーントランザクションのロールバック手順を実行することを含む。

方法１５００の別の実施形態によれば、ユーザデバイスからの構造化クエリは、先行トランザクションが保留中及び非コミット状態のままであるブロックチェーン資産に対応し、構造化クエリによりアドレス指定されたブロックチェーン資産が保留中及び非コミット状態のままである先行トランザクションを条件とすることをユーザデバイスに対して示す。

方法１５００の別の実施形態によれば、構造化クエリは、ＳＥＬＥＣＴコマンドターム、ＵＰＤＡＴＥコマンドターム、又はＩＮＳＥＲＴコマンドタームのうちの１つを指定し、構造化クエリのトランザクションコマンドを翻訳することは、ＳＥＬＥＣＴコマンドターム、ＵＰＤＡＴＥコマンドターム、又はＩＮＳＥＲＴコマンドタームをブロックチェーンに準拠したネイティブのコマンドタームに翻訳することを含む。

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するホスト組織のシステムにより実行されたときに、命令はシステムに、以下の動作：ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、複数のテナントの各々は、ブロックチェーンでの参加ノードである、ことと、ユーザデバイスからログイン要求を受信することと、ホスト組織でユーザデバイスを認証することと、認証されたユーザデバイスを、認証されたユーザデバイスに対応するブロックチェーンの暗号ＩＤと相関させることと、ブロックチェーンに対して実行されるべきユーザデバイスからの構造化クエリを受信することであり、構造化クエリは、トランザクションコマンドと、トランザクションコマンドが実行されるべきデータオブジェクトを指定する、ことと、構造化クエリのトランザクションコマンドをネイティブブロックチェーンプロトコルコードに翻訳し、データオブジェクトをブロックチェーン内に記憶されたブロックチェーン資産ＩＤに翻訳してネイティブブロックトランザクションを形成することと、ブロックチェーンでネイティブブロックチェーントランザクションを実行することと、を実行させる。

別の実施形態によれば、ホスト組織において実行するシステムがあり、当該システムは、命令を記憶するメモリと、命令を実行するプロセッサを含み、プロセッサは、ホスト組織の複数のテナントのためのブロックチェーンに対するブロックチェーンインターフェースであり、複数のテナントの各々は、ブロックチェーンでの参加ノードである、ブロックチェーンインターフェースと、ユーザデバイスからのログイン要求を受信する受信インターフェースと、ホスト組織でユーザデバイスを認証する認証器と、認証されたユーザデバイスを、認証されたユーザデバイスに対応するブロックチェーンの暗号ＩＤと相関させる仮想チェーンインターフェースと、ブロックチェーンに対して実行されるべきユーザデバイスからの構造化クエリを受信する上記受信インターフェースであり、構造化クエリは、トランザクションコマンドと、トランザクションコマンドが実行されるべきデータオブジェクトを指定する、上記受信インターフェースと、構造化クエリのトランザクションコマンドをネイティブチェーンブロックプロトコルコードに翻訳し、データオブジェクトをブロックチェーン内に記憶されたブロックチェーン資産ＩＤに翻訳してネイティブブロックチェーントランザクションを形成するクエリ論理トランスレータと、ブロックチェーンでネイティブブロックチェーントランザクションを実行するブロックチェーンサービスインターフェースと、を実行する。

図１６Ａは、説明される実施形態による、オンデマンドデータベースサービスが動作し得る環境１６９８のブロック図を示す。環境１６９８は、ユーザシステム１６１２、ネットワーク１６１４、システム１６１６、プロセッサシステム１６１７、アプリケーションプラットフォーム１６１８、ネットワークインターフェース１６２０、テナントデータストレージ１６２２、システムデータストレージ１６２４、プログラムコード１６２６、及びプロセス空間１６２８を含んでもよい。他の実施形態において、環境１６９８は、列挙されたコンポーネントの全てを有するわけではない場合があり、かつ／あるいは上に列挙されたコンポーネントに代わって又は追加で他のコンポーネントを有してもよい。

環境１６９８は、オンデマンドデータベースサービスが存在する環境である。ユーザシステム１６１２は、データベースユーザシステムにアクセスするためにユーザにより使用される任意のマシン又はシステムでもよい。例えば、ユーザシステム１６１２のいずれかは、ハンドヘルドコンピューティングデバイス、モバイルフォン、ラップトップコンピュータ、ワークステーション、及び／又はコンピューティングデバイスのネットワークでもよい。図１６Ａに（及び、図１６Ｂでより詳細に）示されるように、ユーザシステム１６１２は、ネットワーク１６１４を介してオンデマンドデータベースサービスと相互作用してもよく、それがシステム１６１６である。

システム１６１６などのオンデマンドデータベースサービスは、必ずしもデータベースシステムの構築及び／又は維持に関係する必要はない外部ユーザに利用可能であるが、代わりに、ユーザがデータベースシステムを必要とするときに（例えば、ユーザの要求に応じて）それらの使用に利用可能であり得るデータベースシステムである。いくつかのオンデマンドデータベースサービスは、共通データベースイメージのテーブルに記憶された１つ以上のテナントからの情報を記憶してマルチテナントデータベースシステム（multi-tenant database system、ＭＴＳ）を形成し得る。したがって、「オンデマンドデータベースサービス１６１６」と「システム１６１６」は、本明細書において交換可能に用いられる。データベースイメージは、１つ以上のデータベースオブジェクトを含んでもよい。関係データベース管理システム（ＲＤＭＳ）又は同等物が、データベースオブジェクトに対して情報の記憶及び取り出しを実行してもよい。アプリケーションプラットフォーム１６１８は、ハードウェア及び／又はソフトウェア、例えばオペレーティングシステムなどの、システム１６１６のアプリケーションを実行可能にするフレームワークでもよい。一実施形態において、オンデマンドデータベースサービス１６１６は、オンデマンドデータベースサービスのプロバイダにより開発された１つ以上のアプリケーションを作成、管理、及び実行すること、ユーザがユーザシステム１６１２を介してオンデマンドデータベースサービスにアクセスすること、又はサードパーティアプリケーション開発者がユーザシステム１６１２を介してオンデマンドデータベースサービスにアクセスすることを可能にするアプリケーションプラットフォーム１６１８を含んでもよい。

ユーザシステム１６１２のユーザは、そのそれぞれのキャパシティが異なってもよく、特定のユーザシステム１６１２のキャパシティは専ら、現在のユーザに対する許可（許可レベル）により決定されてもよい。例えば、販売員が、特定のユーザシステム１６１２を使用してシステム１６１６と相互作用している場合、そのユーザシステムは、その販売員に割り振られたキャパシティを有する。しかしながら、管理者が、そのユーザシステムを使用してシステム１６１６と相互作用している間、そのユーザシステムは、その管理者に割り振られたキャパシティを有する。階層的役割モデルを有するシステムでは、１つの許可レベルのユーザは、より下位の許可レベルのユーザによりアクセス可能なアプリケーション、データ、及びデータベース情報へのアクセスを有し得るが、より上位の許可レベルのユーザによりアクセス可能な特定のアプリケーション、データベース情報、及びデータへのアクセスを有さない場合がある。したがって、異なるユーザは、ユーザのセキュリティ又は許可レベルに依存して、アプリケーション及びデータベース情報へのアクセス及び修正に関して異なる能力を有する。

ネットワーク１６１４は、互いに通信するデバイスの任意のネットワーク又はネットワークの組み合わせである。例えば、ネットワーク１６１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話ネットワーク、無線ネットワーク、ポイントツーポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク、又は他の適切な構成のうち任意の１つ又は任意の組み合わせであり得る。現在使用されているコンピュータネットワークの最も一般的なタイプは、ＴＣＰ／ＩＰ（トランスファーコントロールプロトコル及びインターネットプロトコル）ネットワークであるため、大文字「Ｉ」を用いて「インターネット（Internet）」としばしば呼ばれるネットワークのグローバルインターネットワークのようなネットワークが、本明細書の多くの例で用いられる。しかしながら、ＴＣＰ／ＩＰは頻繁に実装されるプロトコルであるが、請求される実施形態が利用し得るネットワークはそのように限定されないことが理解される。

ユーザシステム１６１２は、ＴＣＰ／ＩＰを使用してシステム１６１６と通信し、より上位のネットワークレベルでは、ＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの他の一般的なインターネットプロトコルを通信するのに使用してもよい。ＨＴＴＰが使用される例では、ユーザシステム１６１２は、システム１６１６におけるＨＴＴＰサーバとの間でＨＴＴＰメッセージを送受信するために、一般に「ブラウザ」と呼ばれるＨＴＴＰクライアントを含んでもよい。そのようなＨＴＴＰサーバは、システム１６１６とネットワーク１６１４との間の単独のネットワークインターフェースとして実装されてもよいが、他の手法が同様に又は代わりに使用されてもよい。いくつかの実装において、システム１６１６とネットワーク１６１４との間のインターフェースは、ラウンドロビンＨＴＴＰリクエスト分配器などの負荷共有機能を含み、負荷のバランスをとり、入ってくるＨＴＴＰリクエストを複数のサーバにわたり均等に分配する。少なくとも、そのサーバにアクセスしているユーザについて、複数のサーバの各々は、ＭＴＳのデータへのアクセスを有するが、代わりに、他の代替的な構成が使用されてもよい。

一実施形態において、図１６Ａに示すシステム１６１６は、ウェブベースの顧客関係管理（ＣＲＭ）システムを実現する。例えば、一実施形態において、システム１６１６は、ＣＲＭソフトウェアアプリケーションを実装及び実行し、ユーザシステム１６１２との間で関連データ、コード、フォーム、ウェブページ、及び他の情報を提供し、関連データ、オブジェクト、及びウェブページコンテンツをデータベースシステムに記憶し、データベースシステムから取り出すように構成されたアプリケーションサーバを含む。マルチテナントシステムでは、複数のテナントのデータが同じ物理データベースオブジェクト内に記憶され得るが、テナントデータは典型的には、当該データが明示的に共有されない限り、１つのテナントのデータが他のテナントのデータと論理的に別個に保持され、それにより、１つのテナントが他のテナントのデータへのアクセスを有さないように配置される。特定の実施形態において、システム１６１６は、ＣＲＭアプリケーション以外の、又は追加のアプリケーションを実現する。例えば、システム１６１６は、ＣＲＭアプリケーションを含む複数のホストされた（標準及びカスタム）アプリケーションへのテナントアクセスを提供してもよい。ユーザ（又はサードパーティ開発者）アプリケーションは、ＣＲＭを含んでも含まなくてもよいが、アプリケーションプラットフォーム１６１８によりサポートされてもよく、アプリケーションプラットフォーム１６１８は、アプリケーションの作成、１つ以上のデータベースオブジェクトへの記憶、及びシステム１６１６のプロセス空間内の仮想マシンにおけるアプリケーションの実行を管理する。

システム１６１６の要素の１つの配置が図１６Ａに示されており、ネットワークインターフェース１６２０、アプリケーションプラットフォーム１６１８、テナントデータ１６２３のためのテナントデータストレージ１６２２、システム１６１６と可能性として複数のテナントがアクセス可能なシステムデータ１６２５のためのシステムデータストレージ１６２４、システム１６１６の様々な機能を実現するプログラムコード１６２６、及びアプリケーションホスティングサービスの一部としてアプリケーションを実行するなど、ＭＴＳシステムプロセス及びテナント特有のプロセスを実行するプロセス空間１６２８が含まれる。システム１６１６上で実行され得るさらなるプロセスには、データベースインデクシングプロセスが含まれる。

図１６Ａに示されるシステムにおけるいくつかの要素は、ここではごく簡単に説明される従来の良く知られた要素を含む。例えば、各ユーザシステム１６１２は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話、若しくは任意のワイヤレスアクセスプロトコル（ＷＡＰ）対応デバイス、又はインターネット若しくは他のネットワーク接続に直接又は間接的にインターフェースすることが可能な任意の他のコンピュータデバイスを含んでもよい。ユーザシステム１６１２は典型的には、ＨＴＴＰクライアント、例えば、ＭｉｃｒｏｓｏｆｔのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ、Ｍｏｚｉｌｌａ又はＦｉｒｅｆｏｘブラウザ、Ｏｐｅｒａ、又はスマートフォン、タブレット、ＰＤＡ、若しくは他の無線デバイスの場合のＷＡＰ対応ブラウザなどのブラウジングプログラムを実行し、ユーザシステム１６１２のユーザ（例えば、マルチテナントデータベースシステムのサブスクライバ）が、ネットワーク１６１４を介してシステム１６１６からそれが利用可能な情報、ページ、及びアプリケーションにアクセスし、処理し、閲覧することを可能にする。各ユーザシステム１６１２はさらに典型的には、システム１６１６又は他のシステム若しくはサーバにより提供されるページ、フォーム、アプリケーション、及び他の情報と関連してディスプレイ（例えば、モニタ画面、ＬＣＤディスプレイ等）にブラウザにより提供されるグラフィカルユーザインターフェース（ＧＵＩ）と相互作用するための、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペンなどの１つ以上のユーザインターフェースデバイスを含む。例えば、ユーザインターフェースデバイスを使用して、システム１６１６によりホストされるデータ及びアプリケーションにアクセスし、記憶されたデータに対して検索を実行し、さもなければ、ユーザがユーザに提示され得る様々なＧＵＩページと相互作用することを可能にすることができる。上で論じられたように、実施形態は、ネットワークの特定のグローバルインターネットワークを参照するインターネットでの使用に適している。しかしながら、インターネットの代わりにイントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、任意のＬＡＮ又はＷＡＮなどの他のネットワークを使用できることが理解される。

一実施形態によれば、各ユーザシステム１６１２及びそのコンポーネントの全てが、インテル（登録商標）ペンティアム（登録商標）プロセッサなどの中央処理ユニットを使用して実行されるコンピュータコードを含むブラウザなどのアプリケーションを使用してオペレータ構成可能である。同様に、システム１６１６（及び、複数が存在する場合のＭＴＳのさらなるインスタンス）及びそれらのコンポーネントの全てが、インテルペンティアム（登録商標）プロセッサなど及び／又は複数のプロセッサユニットを含み得るプロセッサシステム１６１７などの中央処理ユニットを使用して実行するコンピュータコードを含むアプリケーションを使用してオペレータ構成可能でもよい。

一実施形態によれば、各システム１６１６は、ウェブページ、フォーム、アプリケーション、データ、及びメディアコンテンツをユーザ（クライアント）システム１６１２に提供してシステム１６１６のテナントとしてのユーザシステム１６１２によるアクセスをサポートするように構成される。したがって、システム１６１６は、各テナントのデータを、該データが共有されない限り別個に保持するセキュリティメカニズムを提供する。複数のＭＴＳが使用される場合、それらは互いに近接して（例えば、単一の建物又はキャンパス内に位置するサーバファームに）配置されてもよく、あるいは互いから遠隔の場所に分散されてもよい（例えば、１つ以上のサーバがＡ市に配置され、１つ以上のサーバがＢ市に配置される）。本明細書で用いられるとき、各ＭＴＳは、局所的に又は１つ以上の地理的位置にわたり分散された１つ以上の論理的及び／又は物理的に接続されたサーバを含んでもよい。さらに、用語「サーバ」は、処理ハードウェア及びプロセス空間と、当該分野で良く知られた関連するストレージシステム及びデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）とを含むコンピュータシステムを含むことが意図される。「サーバシステム」及び「サーバ」はしばしば、本明細書で交換可能に使用されることが理解される。同様に、本明細書に記載のデータベースオブジェクトは、単一のデータベース、分散データベース、分散データベースの集合、冗長のオンライン若しくはオフラインバックアップ又は他の冗長性を有するデータベース等として実現することができ、分散データベース又はストレージネットワーク及び関連する処理インテリジェンスを含んでもよい。

図１６Ｂは、説明される実施形態による、図１６Ａの要素とそのような要素間の様々な可能な相互接続との実施形態の別のブロック図を示す。図１６Ｂは、環境１６９９をさらに示す。しかしながら、図１６Ｂでは、一実施形態におけるシステム１６１６の要素及び様々な相互接続がさらに詳細に示される。より具体的には、図１６Ｂは、ユーザシステム１６１２が、プロセッサシステム１６１２Ａ、メモリシステム１６１２Ｂ、入力システム１６１２Ｃ、及び出力システム１６１２Ｄを含み得ることを示す。図１６Ｂは、ネットワーク１６１４及びシステム１６１６を示す。さらに、図１６Ｂは、システム１６１６がテナントデータストレージ１６２２を含み、テナントデータストレージ１６２２はその中にテナントデータ１６２３を有することを示し、テナントデータ１６２３は、例えば、テナントストレージ空間１６２７、テナントデータ１６２９、及びアプリケーションメタデータ１６３１を含む。システムデータストレージ１６２４は、その中にシステムデータ１６２５を有するものとして示されている。さらに、アプリケーションサーバ１６００_１〜Ｎの拡大された詳細の中に示されているのは、ユーザインターフェース（ＵＩ）１６３０、アプリケーションプログラムインターフェース（ＡＰＩ）１６３２、アプリケーションプラットフォーム１６１８が含むＰＬ／ＳＯＱＬ１６３４、保存ルーチン１６３６、アプリケーションセットアップメカニズム１６３８、プロセス空間１６２８が含むシステムプロセス空間１６０２、テナント１〜Ｎのプロセス空間１６０４、及びテナント管理プロセス空間１６１０である。他の実施形態において、環境１６９９は、上に列挙されたものと同じ要素を有さなくてもよく、かつ／あるいは上に列挙されたものに代わって又は追加で他の要素を有してもよい。

ユーザシステム１６１２、ネットワーク１６１４、システム１６１６、テナントデータストレージ１６２２、及びシステムデータストレージ１６２４は、図１６Ａにおいて上で論じた。図１６Ｂに示すように、システム１６１６は、ＨＴＴＰアプリケーションサーバ１６００、アプリケーションプラットフォーム１６１８、テナントデータストレージ１６２２、及びシステムデータストレージ１６２４のセットとして実現される（図１６Ａの）ネットワークインターフェース１６２０を含んでもよい。さらに、個々のテナントプロセス空間１６０４及びテナント管理プロセス空間１６１０を含むシステムプロセス空間１６０２が示されている。各アプリケーションサーバ１６００は、ユーザシステム１６１２の要求にサービスするために、テナントデータストレージ１６２２及びその中のテナントデータ１６２３、並びにシステムデータストレージ１６２４及びその中のシステムデータ１６２５に対して構成されてもよい。テナントデータ１６２３は、個々のテナントストレージエリア（例えば、テナントストレージ空間１６２７）に分割されてもよく、これは、データの物理的配置及び／又は論理的配置のいずれかでもよい。各テナントストレージ空間１６２７内で、テナントデータ１６２９、及びアプリケーションメタデータ１６３１が、各ユーザに対して同様に割り当てられてもよい。例えば、ユーザの最も最近使用した（most recently used、ＭＲＵ）アイテムのコピーが、テナントデータ１６２９に記憶されてもよい。同様に、テナントである組織全体のためのＭＲＵアイテムのコピーが、テナントストレージ空間１６２７に保管されてもよい。ＵＩ７３０はユーザインターフェースを提供し、ＡＰＩ１６３２は、システム１６１６常駐プロセスへのアプリケーションプログラマインターフェースを、ユーザシステム１６１２のユーザ及び／又は開発者に提供する。テナントデータ及びシステムデータは、１つ以上のＯｒａｃｌｅ（登録商標）データベースなどの様々なデータベースに格納されてもよい。

アプリケーションプラットフォーム１６１８は、アプリケーション開発者によるアプリケーションの作成及び管理をサポートするアプリケーションセットアップメカニズム１６３８を含み、これは、例えば、テナント管理プロセス空間１６１０により管理される１つ以上のテナントプロセス空間１６０４としてのサブスクライバによる実行のために、保存ルーチン１６３６によりテナントデータストレージ１６２２にメタデータとして保存されてもよい。このようなアプリケーションへの呼び出しは、ＡＰＩ１６３２へのプログラミング言語スタイルインターフェース拡張を提供するＰＬ／ＳＯＱＬ１６３４を使用してコード化されてもよい。アプリケーションへの呼び出しは、１つ以上のシステムプロセスにより検出されてもよく、該システムプロセスは、呼び出しを行うサブスクライバのためのアプリケーションメタデータ１６３１の取り出しと、仮想マシンにおけるアプリケーションとしてのメタデータの実行を管理する。

各アプリケーションサーバ１６００は、異なるネットワーク接続を介して、例えばシステムデータ１６２５及びテナントデータ１６２３へのアクセスを有するデータベースシステムに通信上結合されてもよい。例えば、１つのアプリケーションサーバ１６００_１が、ネットワーク１６１４（例えば、インターネット）を介して結合されてもよく、別のアプリケーションサーバ１６００_Ｎ‐１が、直接ネットワークリンクを介して結合されてもよく、別のアプリケーションサーバ１６００_Ｎが、さらに異なるネットワーク接続により結合されてもよい。トランスファーコントロールプロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ１６００とデータベースシステムとの間で通信するための典型的なプロトコルである。しかしながら、使用されるネットワーク相互接続に依存してシステムを最適化するために他のトランスポートプロトコルが使用されてもよいことが当業者に明らかであろう。

特定の実施形態において、各アプリケーションサーバ１６００は、テナントである任意の組織に関連づけられた任意のユーザの要求を取り扱うように構成される。任意の理由で任意の時点にサーバプールからアプリケーションサーバを追加及び除去できることが望ましいため、好ましくは、特定のアプリケーションサーバ１６００に対するユーザ及び／又は組織のサーバアフィニティは存在しない。したがって、一実施形態において、ロードバランシング機能（例えば、Ｆ５ Ｂｉｇ‐ＩＰロードバランサ）を実現するインターフェースシステムは、アプリケーションサーバ１６００とユーザシステム１６１２との間で通信上結合され、アプリケーションサーバ１６００への要求を分配する。一実施形態において、ロードバランサは、最小接続アルゴリズムを使用して、ユーザ要求をアプリケーションサーバ１６００にルーティングする。ラウンドロビン及び観測応答時間などのロードバランシングアルゴリズムの他の例がさらに使用されてもよい。例えば、特定の実施形態において、同じユーザからの３つの連続した要求が３つの異なるアプリケーションサーバ１６００に当たることがあり、異なるユーザからの３つの要求が同じアプリケーションサーバ１６００に当たることがある。このようにして、システム１６１６はマルチテナントであり、システム１６１６は、異なるユーザ及び組織にわたる異なるオブジェクト、データ、及びアプリケーションの記憶及びそれらへのアクセスを取り扱う。

ストレージの一例として、１つのテナントが、各販売員がシステム１６１６を使用してその販売プロセスを管理する販売陣（sales force）を採用する会社であり得る。ゆえに、ユーザは、全てがそのユーザの個人的販売プロセスに適用可能なコンタクトデータ、リードデータ、顧客フォローアップデータ、パフォーマンスデータ、目標及び進捗データ等を（例えば、テナントデータストレージ１６２２に）維持することができる。ＭＴＳ構成の一例において、アクセス、閲覧、修正、報告、送信、計算等すべきデータ及びアプリケーションの全てが、ネットワークアクセス以上のものを有さないユーザシステムにより維持及びアクセスできるため、ユーザは、多くの異なるユーザシステムのいずれかから販売努力及びサイクルを管理することができる。例えば、販売員が顧客を訪問し、顧客がそのロビーでインターネットアクセスを有する場合、販売員は、顧客がロビーに到着するのを待つ間、その顧客に関する重要なアップデートを得ることができる。

各ユーザのデータは、各ユーザの雇用者にかかわらず他のユーザのデータとは別個であり得るが、いくつかのデータは、テナントである所与の組織に対する複数のユーザ又は全ユーザにより共有され又はアクセス可能な組織全体のデータでもよい。ゆえに、システム１６１６により管理される、テナントレベルで割り振られるいくつかのデータ構造があり、一方、他のデータ構造はユーザレベルで管理され得る。ＭＴＳは、あり得る競合者を含む複数のテナントをサポートする可能性があるため、ＭＴＳは、データ、アプリケーション、及びアプリケーション使用を別個に保つセキュリティプロトコルを有してもよい。さらに、多くのテナントが、独自のシステムを維持するのでなくＭＴＳへのアクセスを選択する可能性があるため、冗長性、アップタイム、及びバックアップは、ＭＴＳで実装され得るさらなる機能である。ユーザ特有のデータ及びテナント特有のデータに追加で、システム１６１６は、複数のテナントにより使用可能なシステムレベルのデータ又は他のデータをさらに維持してもよい。このようなシステムレベルのデータには、テナント間で共有可能な産業レポート、ニュース、投稿などを含んでもよい。

特定の実施形態において、ユーザシステム１６１２（クライアントシステムでもよい）は、アプリケーションサーバ１６００と通信してシステム１６１６からのシステムレベル及びテナントレベルのデータを要求及び更新し、これは、テナントデータストレージ１６２２及び／又はシステムデータストレージ１６２４への１つ以上のクエリの送信を必要としてもよい。システム１６１６（例えば、システム１６１６内のアプリケーションサーバ１６００）は、所望の情報にアクセスするように設計された１つ以上のＳＱＬ文（例えば、１つ以上のＳＱＬクエリ）を自動的に生成する。システムデータストレージ１６２４は、データベースから要求されたデータにアクセスするためのクエリプランを生成してもよい。

各データベースは、一般に、予め定義されたカテゴリに適合されたデータを含む論理テーブルのセットなどのオブジェクトの集合として見ることができる。「テーブル」は、データオブジェクトの１つの表現であり、本明細書では、説明されるオブジェクト及びカスタムオブジェクトの概念的な説明を簡略化するために使用されることがある。「テーブル」及び「オブジェクト」は、本明細書では交換可能に用いられ得ることが理解される。各テーブルは通常、閲覧可能スキーマ内に列又はフィールドとして論理的に配置された１つ以上のデータカテゴリを含む。テーブルの各行又はレコードは、フィールドにより定義された各カテゴリのデータのインスタンスを含む。例えば、ＣＲＭデータベースは、名前、住所、電話番号、ファックス番号などの基本コンタクト情報のためのフィールドを有する顧客を記述するテーブルを含み得る。別のテーブルが、顧客、プロダクト、販売価格、日付などの情報のフィールドを含む購入注文を記述してもよい。いくつかのマルチテナントデータベースシステムにおいて、全てのテナントによる使用のために標準エンティティテーブルが提供されてもよい。ＣＲＭデータベースアプリケーションでは、このような標準エンティティには、各々が予め定義されたフィールドを含むアカウント、コンタクト、リード、及び機会データのテーブルを含んでもよい。ワード「エンティティ」は、本明細書において「オブジェクト」及び「テーブル」と交換可能に用いられ得ることが理解される。

いくつかのマルチテナントデータベースシステムにおいて、テナントは、カスタムオブジェクトを作成及び記憶することを可能にされてもよく、あるいは、例えば、カスタムインデックスフィールドを含む標準オブジェクトに対するカスタムフィールドを作成することにより、標準エンティティ又はオブジェクトをカスタマイズすることを可能にされてもよい。特定の実施形態において、例えば、全てのカスタムエンティティデータ行は、組織ごとの複数の論理テーブルを含み得る単一のマルチテナント物理テーブルに記憶される。それらの複数の「テーブル」が実際には１つの大きいテーブルに記憶されていること、又はそれらのデータが他の顧客のデータと同じテーブルに記憶され得ることは、顧客に対して透過的である。

図１７は、一実施形態による、コンピュータシステムの例示的な形態のマシン１７００の概略表現を示し、その中で、マシン／コンピュータシステム１７００に本明細書で論じられる方法のうちのいずれか１つ以上を実行させる命令セットが実行され得る。代替的な実施形態において、マシンは、ローカルエリアネットワーク（ＬＡＮ）、イントラネット、エクストラネット、又はパブリックインターネット内の他のマシンに接続され（例えば、ネットワーク化され）てもよい。マシンは、クライアント‐サーバネットワーク環境のサーバ又はクライアントマシンのキャパシティで、ピアツーピア（又は分散）ネットワーク環境のピアマシンとして、オンデマンドサービス環境内のサーバ又は一連のサーバとして動作してもよい。マシンの特定の実施形態は、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、パーソナルデジタルアシスタント（ＰＤＡ）、セルラー電話、ウェブ電化製品、サーバ、ネットワークルータ、スイッチ若しくはブリッジ、コンピューティングシステム、又はそのマシンが取るべきアクションを指定する（順次又はその他の）命令のセットを実行することができる任意のマシンの形態でもよい。さらに、単一のマシンのみが示されているが、用語「マシン」はさらに、本明細書で論じられる方法のいずれか１つ以上を実行するための命令のセット（又は、複数のセット）を個々又は連帯的に実行するマシン（例えば、コンピュータ）の任意の集合を含むとみなされるものとする。

例示的なコンピュータシステム１７００は、プロセッサ１７０２、メインメモリ１７０４（例えば、読取専用メモリ（ＲＯＭ）、フラッシュメモリ、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、例えば同期ＤＲＡＭ（ＳＤＲＡＭ）又はランバスＤＲＡＭ（ＲＤＲＡＭ）等、スタティックメモリ、例えばフラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ）、揮発性だが高データレートのＲＡＭ等）、及びセカンダリメモリ１７１８（例えば、ハードディスクドライブ及び永続的データベース及び／又はマルチテナントデータベース実装を含む永続的記憶デバイス）を含み、これらは、バス１７３０を介して互いに通信する。メインメモリ１７０４は、ホスト組織のテナント及びユーザをパブリック又はプライベートの利用可能なサポートされたブロックチェーンとインターフェースするためのブロックチェーンサービスインターフェース１７２４を含む。メインメモリ１７０４は、ブロックチェーン合意マネージャ１７２３及びブロックバリデータ１７２５をさらに含む。メインメモリ１７０４及びそのサブ要素は、本明細書で論じられる方法を実行するために、処理論理１７２６及びプロセッサ１７０２と関連して動作可能である。

プロセッサ１７０２は、マイクロプロセッサ、中央処理ユニット等の１つ以上の汎用処理デバイスを表す。より詳細には、プロセッサ１７０２は、複合命令セットコンピューティング（ＣＩＳＣ）マイクロプロセッサ、縮小命令セットコンピューティング（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＷ）マイクロプロセッサ、他の命令セットを実現するプロセッサ、又は命令セットの組み合わせを実現するプロセッサでもよい。プロセッサ１７０２はさらに、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサなどの１つ以上の専用処理デバイスでもよい。プロセッサ１７０２は、本明細書で論じられる動作及び機能を実行する処理論理１７２６を実行するように構成される。

コンピュータシステム１７００は、ネットワークインターフェースカード１７０８をさらに含んでもよい。コンピュータシステム１７００は、ユーザインターフェース１７１０（ビデオディスプレイユニット、液晶ディスプレイなど）、英数字入力装置１７１２（例えば、キーボード）、カーソル制御装置１７１４（例えば、マウス）、及び信号生成装置１７１６（例えば、統合型スピーカ）をさらに含んでもよい。コンピュータシステム１７００は、周辺装置１７３６（例えば、無線又は有線通信装置、メモリ装置、記憶装置、オーディオ処理装置、ビデオ処理装置等）をさらに含んでもよい。

セカンダリメモリ１７１８は、本明細書に記載される方法又は機能のいずれか１つ以上を具現化する命令の１つ以上のセット（例えば、ソフトウェア１７２２）が記憶される非一時的マシン読取可能記憶媒体又は非一時的コンピュータ読取可能記憶媒体又は非一時的マシンアクセス可能記憶媒体１７３１を含んでもよい。ソフトウェア１７２２はさらに、コンピュータシステム１７００によるその実行の間、メインメモリ１７０４内及び／又はプロセッサ１７０２内に完全に又は少なくとも部分的に存在することがあり、メインメモリ１７０４及びプロセッサ１７０２もまた、マシン読取可能記憶媒体を構成する。ソフトウェア１７２２はさらに、ネットワークインターフェースカード１７０８を介してネットワーク１７２０を通じて送信又は受信されてもよい。

請求項の何れも、正確なワード「means for」の後に分詞が続かない限り、３５ Ｕ．Ｓ．Ｃ．§１１５の段落６を援用することを意図していない。本明細書に開示された対象事項は、例として特定の実施形態に関して説明されたが、請求される実施形態は、開示の明示的に列挙された実施形態に限定されないことが理解されるべきである。反対に、本開示は、当業者に明らかなように、様々な修正及び同様の構成をカバーすることを意図している。したがって、別記の特許請求の範囲は、全てのそのような修正及び同様の構成を包含するように、最も広い解釈を与えられるべきである。上記の説明は、例示的であり限定的ではないことを意図していることを理解されたい。多くの他の実施形態が、上記の説明を読んで理解した当業者に明らかとなろう。したがって、開示された対象事項の範囲は、別記の特許請求の範囲を参照して、そのような請求項が権利を与えられる同等物の全範囲と共に決定されるべきである。

Claims (23)

1. ホスト組織のシステムにより実行される方法であって、前記システムはその中に少なくともプロセッサ及びメモリを有し、当該方法は、
   前記ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させるステップであり、前記複数のテナントの各々は、前記ブロックチェーンでの参加ノードである、ステップと、
   ユーザデバイスからログイン要求を受信するステップであり、前記ログイン要求は、前記複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する、ステップと、
   前記ユーザデバイスを認証し、前記ユーザデバイスの前記認証に基づいて前記ブロックチェーンからユーザプロファイルを取り出すステップであり、前記ユーザプロファイルは、前記ブロックチェーン内にブロックチェーン資産として記憶され、前記ユーザプロファイルの第１の部分は、前記ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、前記ユーザプロファイルの第２の部分は、ユーザ同意を有する参加ノードのみがアクセス可能な保護データを含む、ステップと、
   前記保護データを前記複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように前記ユーザデバイスにプロンプト表示するステップと、
   前記第２のテナントの参加ノードによる前記ブロックチェーン資産内の前記保護データへのアクセスを許可することにより、前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップと、
   を含む方法。
2. 前記ホスト組織のブロックチェーン同意マネージャは、前記ブロックチェーンからの前記保護データにアクセスするための資産ＩＤを必要とする、請求項１に記載の方法。
3. 前記第２のテナントから第２のユーザプロファイルを作成する要求を受信するステップと、
   前記第２のユーザプロファイルの非保護情報を含むブロックチェーン資産を作成するステップと、
   ブロックチェーンサービスインターフェースを介して、前記ブロックチェーン資産を含むブロックチェーントランザクションを生成するステップと、
   前記ブロックチェーン上の循環に前記ブロックチェーントランザクションをブロードキャストするステップと、
   ブロック内の検証されたブロックチェーントランザクションを前記ブロックチェーンに対してコミットするステップと、
   をさらに含む請求項１に記載の方法。
4. 前記保護データを前記複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように前記ユーザデバイスにプロンプト表示するステップは、
   前記第２のユーザプロファイルを埋めるために前記保護データを前記第２のテナントと共有するように前記ユーザデバイスでプロンプト表示するステップであり、前記第１のユーザプロファイル及び前記第２のユーザプロファイルの双方が、共通のユニバーサルＩＤに関連づけられる、ステップを含み、
   前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップは、前記第２のテナントの参加ノードにより前記ブロックチェーン資産から取り出された前記保護データで前記第２のユーザプロファイルを埋めるステップを含む、請求項３に記載の方法。
5. 前記ブロックチェーン資産内の前記保護データへのアクセスを許可することにより、前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップは、前記ブロックチェーン資産の資産ＩＤを前記第２のテナントに送信するステップを含み、
   当該方法は、前記第２のテナントが前記資産ＩＤをブロックチェーン同意マネージャに提示して前記ブロックチェーン資産内の前記保護データにアクセスするステップをさらに含む、請求項１に記載の方法。
6. 前記第１及び第２のテナントの各々は、前記ホスト組織により管理されるヘルスケアブロックチェーンでの参加ノードとして動作するヘルスケア顧客組織であり、
   前記非保護データは、前記第１のユーザプロファイルに関連づけられたユーザの少なくとも名前を含み、
   前記保護データは、前記ユーザのために前記第１のユーザプロファイルを中に具現化させた前記ブロックチェーン資産を介して前記ヘルスケアブロックチェーン内に記憶された少なくともＨＩＰＡＡ（医療保険の携行性と責任に関する法律）により保護された医療データを含み、
   前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップは、前記ユーザが同意を付与して、前記ＨＩＰＡＡにより保護された医療データを前記第２のテナントに関連づけられた第２のユーザプロファイルを介して前記第２のテナントと共有するステップを含む、請求項１に記載の方法。
7. 前記第１及び第２のテナントの各々は、前記ホスト組織により管理される金融ブロックチェーンでの参加ノードとして動作する金融顧客組織であり、
   前記非保護データは、前記第１のユーザプロファイルに関連づけられたユーザの少なくとも名前を含み、
   前記保護データは、前記ユーザのために前記第１のユーザプロファイルを中に具現化させた前記ブロックチェーン資産を介して前記金融ブロックチェーン内に記憶された少なくともプライベート金融データを含み、
   前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップは、前記ユーザが同意を付与して、前記プライベート金融データを前記第２のテナントに関連づけられた第２のユーザプロファイルを介して前記第２のテナントと共有するステップを含む、請求項１に記載の方法。
8. （ｉ）前記第１のテナントに関連づけられた同じ個人として立証された、前記第２のテナントの認証されたユーザから、前記ユーザ同意を受信すること、又は
   （ｉｉ）前記第２のテナントに関連づけられた同じ個人として立証された、前記第１のテナントで承認された前記ユーザデバイスから、前記ユーザ同意を受信すること
   のうち１つにより、前記保護データを共有するための前記ユーザ同意を受信するステップをさらに含む請求項１に記載の方法。
9. 前記保護データを前記複数のテナントのうち前記第２のテナントと共有するステップは、前記ホスト組織がブロックチェーン同意マネージャを介して、前記第１のテナント及び前記第２のテナントの双方が１の個人に関連づけられたユーザプロファイルを有することを検証するステップを含み、
   前記検証は、前記第１及び第２のテナントのユーザプロファイルの双方が前記ホスト組織内で前記１の個人に対し一意である共通のユニバーサルＩＤに関連づけられるという前記１の個人からの証明を受信することに基づく、請求項１に記載の方法。
10. 前記ブロックチェーン資産は、ブロックチェーン資産識別子、又は前記ブロックチェーン内で一意のユニバーサルＩＤを介して識別され、
    前記保護データに関連づけられた１の個人は、前記ブロックチェーン資産識別子又は前記ユニバーサルＩＤに基づいて前記ホスト組織の前記第１のテナント及び前記第２のテナントの双方が一意に識別可能である、請求項１に記載の方法。
11. 前記ユーザプロファイルに関連づけられたユーザのために前記ブロックチェーンでの参加ノードを作成するステップと、
    前記ユーザプロファイルに関連づけられた前記ユーザのためにユーザ特有のコミュニティサイドチェーンを生成するステップと、
    前記第１のテナントのノード及び前記第２のテナントのノードの双方を前記ユーザ特有のコミュニティサイドチェーンに追加するステップと、をさらに含み、
    前記保護データを共有するステップは、前記保護データへのアクセスを前記ユーザ特有のコミュニティサイドチェーン内の全てのノードに付与するステップを含む、請求項１に記載の方法。
12. 前記ブロックチェーンでの参加ノードによる、前記ユーザプロファイルの前記保護データにアクセスする任意の試みは、前記保護データをアクセスを試みた前記参加ノードと共有するためにユーザ同意を付与するための前記ユーザデバイスのプロンプト表示をトリガし、
    特定カテゴリの保護情報をアンロックし、又は特定文書をアンロックし、あるいは双方を行う要求と共に、ＧＵＩが前記ユーザデバイスに送信され、
    ユーザは、前記ＧＵＩを介してどのカテゴリ及び／又は文書をアンロックすべきかを選択し、
    前記ＧＵＩを介した任意のカテゴリ又は文書へのアクセスをアンロックするユーザ指示が、前記保護データへのアクセスを試みた前記参加ノードにリンクを送信し、これを介して、前記保護情報は、前記ホスト組織の同意管理レイヤを通して前記ブロックチェーンからアクセス可能にされる、請求項１に記載の方法。
13. 命令を記憶させた非一時的コンピュータ読取可能記憶媒体であって、前記命令が少なくともプロセッサ及びメモリを中に有するホスト組織のシステムにより実行されたときに、前記命令は前記システムに以下の動作：
    前記ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、前記複数のテナントの各々は、前記ブロックチェーンでの参加ノードである、ことと、
    ユーザデバイスからログイン要求を受信することであり、前記ログイン要求は、前記複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する、ことと、
    前記ユーザデバイスを認証し、前記ユーザデバイスの前記認証に基づいて前記ブロックチェーンからユーザプロファイルを取り出すことであり、前記ユーザプロファイルは、前記ブロックチェーン内にブロックチェーン資産として記憶され、前記ユーザプロファイルの第１の部分は、前記ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、前記ユーザプロファイルの第２の部分は、ユーザ同意を有する参加ノードのみがアクセス可能な保護データを含む、ことと、
    前記保護データを前記複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように前記ユーザデバイスにプロンプト表示することと、
    前記第２のテナントの参加ノードによる前記ブロックチェーン資産内の前記保護データへのアクセスを許可することにより、前記保護データを前記複数のテナントのうち前記第２のテナントと共有することと、
    を実行させる、非一時的コンピュータ読取可能記憶媒体。
14. 前記命令は前記システムに、
    前記第２のテナントから第２のユーザプロファイルを作成する要求を受信することと、
    前記第２のユーザプロファイルの非保護情報を含むブロックチェーン資産を作成することと、
    ブロックチェーンサービスインターフェースを介して、前記ブロックチェーン資産を含むブロックチェーントランザクションを生成することと、
    前記ブロックチェーン上の循環に前記ブロックチェーントランザクションをブロードキャストすることと、
    ブロック内の検証されたブロックチェーントランザクションを前記ブロックチェーンに対してコミットすることと、
    をさらに含む動作を実行させる、請求項１３に記載の非一時的コンピュータ読取可能記憶媒体。
15. 前記保護データを前記複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように前記ユーザデバイスにプロンプト表示することは、
    前記第２のユーザプロファイルを埋めるために前記保護データを前記第２のテナントと共有するように前記ユーザデバイスでプロンプト表示することであり、前記第１のユーザプロファイル及び前記第２のユーザプロファイルの双方が、共通のユニバーサルＩＤに関連づけられる、ことを含み、
    前記保護データを前記複数のテナントのうち前記第２のテナントと共有することは、前記第２のテナントの参加ノードにより前記ブロックチェーン資産から取り出された前記保護データで前記第２のユーザプロファイルを埋めることを含む、請求項１４に記載の非一時的コンピュータ読取可能記憶媒体。
16. 前記ブロックチェーン資産内の前記保護データへのアクセスを許可することにより、前記保護データを前記複数のテナントのうち前記第２のテナントと共有することは、前記ブロックチェーン資産の資産ＩＤを前記第２のテナントに送信することを含み、
    当該方法は、前記第２のテナントが前記資産ＩＤをブロックチェーン同意マネージャに提示して前記ブロックチェーン資産内の前記保護データにアクセスすることをさらに含む、請求項１３に記載の非一時的コンピュータ読取可能記憶媒体。
17. 前記命令は前記システムに、
    （ｉ）前記第１のテナントに関連づけられた同じ個人として立証された、前記第２のテナントの認証されたユーザから、前記ユーザ同意を受信すること、又は
    （ｉｉ）前記第２のテナントに関連づけられた同じ個人として立証された、前記第１のテナントで承認された前記ユーザデバイスから、前記ユーザ同意を受信すること
    のうち１つにより、前記保護データを共有するための前記ユーザ同意を受信することをさらに含む動作を実行させる、請求項１３に記載の非一時的コンピュータ読取可能記憶媒体。
18. 前記ブロックチェーンでの参加ノードによる、前記ユーザプロファイルの前記保護データにアクセスする任意の試みは、前記保護データをアクセスを試みた前記参加ノードと共有するためにユーザ同意を付与するための前記ユーザデバイスのプロンプト表示をトリガし、
    特定カテゴリの保護情報をアンロックし、又は特定文書をアンロックし、あるいは双方を行う要求と共に、ＧＵＩが前記ユーザデバイスに送信され、
    ユーザは、前記ＧＵＩを介してどのカテゴリ及び／又は文書をアンロックすべきかを選択し、
    前記ＧＵＩを介した任意のカテゴリ又は文書へのアクセスをアンロックするユーザ指示が、前記保護データへのアクセスを試みた前記参加ノードにリンクを送信し、これを介して、前記保護情報は、前記ホスト組織の同意管理レイヤを通して前記ブロックチェーンからアクセス可能にされる、請求項１３に記載の非一時的コンピュータ読取可能記憶媒体。
19. ホスト組織で実行するシステムであって、
    命令を記憶するメモリと、
    命令を実行するプロセッサと、を含み、
    前記プロセッサは、前記ホスト組織の複数のテナントのためのブロックチェーンに対するブロックチェーンインターフェースであり、前記複数のテナントの各々は、前記ブロックチェーンでの参加ノードである、ブロックチェーンインターフェースと、
    ユーザデバイスからログイン要求を受信する受信インターフェースであり、前記ログイン要求は、前記複数のテナントのうち第１のテナントに関連づけられたユーザプロファイルへのアクセスを要求する、受信インターフェースと、
    前記ユーザデバイスを認証し、前記ユーザデバイスの前記認証に基づいて前記ブロックチェーンからユーザプロファイルを取り出す認証器であり、前記ユーザプロファイルは、前記ブロックチェーン内にブロックチェーン資産として記憶され、前記ユーザプロファイルの第１の部分は、前記ブロックチェーン上の全ての参加ノードがアクセス可能な非保護データを含み、前記ユーザプロファイルの第２の部分は、ユーザ同意を有する参加ノードのみがアクセス可能な保護データを含む、認証器と、
    前記保護データを前記複数のテナントのうち第２のテナントと共有するためのユーザ同意を付与するように前記ユーザデバイスにプロンプト表示するブロックチェーン同意マネージャと、
    前記第２のテナントの参加ノードによる前記ブロックチェーン資産内の前記保護データへのアクセスを許可することにより、前記保護データを前記複数のテナントのうち前記第２のテナントと共有するスーパーコミュニティテナントブリッジと、
    を実行する、システム。
20. 前記第２のテナントから第２のユーザプロファイルを作成する要求を受信する前記受信インターフェースと、
    前記第２のユーザプロファイルの非保護情報を含むブロックチェーン資産を作成するブロックチェーンサービスインターフェースであり、
    前記ブロックチェーンサービスインターフェースは、前記ブロックチェーン資産を含むブロックチェーントランザクションを生成し、
    前記ブロックチェーンサービスインターフェースは、前記ブロックチェーン上の循環に前記ブロックチェーントランザクションをブロードキャストし、
    前記ブロックチェーンサービスインターフェースは、ブロック内の検証されたブロックチェーントランザクションを前記ブロックチェーンに対してコミットする、ブロックチェーンサービスインターフェースと、
    をさらに含む請求項１９に記載のシステム。
21. 前記ブロックチェーン同意マネージャは、前記第２のユーザプロファイルを埋めるために前記保護データを前記第２のテナントと共有するように前記ユーザデバイスでプロンプト表示し、前記第１のユーザプロファイル及び前記第２のユーザプロファイルの双方が、共通のユニバーサルＩＤに関連づけられ、
    前記スーパーコミュニティテナントブリッジは、前記第２のテナントの参加ノードにより前記ブロックチェーン資産から取り出された前記保護データで前記第２のユーザプロファイルを埋める、請求項１９に記載のシステム。
22. 前記スーパーコミュニティテナントブリッジは、前記ブロックチェーン資産の資産ＩＤを前記第２のテナントに送信し、
    前記ブロックチェーン同意マネージャは、前記第２のテナントから前記資産ＩＤを受信し、前記資産ＩＤの受信に従って前記第２のテナントによる前記ブロックチェーン資産内の前記保護データへのアクセスを許可する、請求項１９に記載のシステム。
23. 前記ブロックチェーンでの参加ノードによる、前記ユーザプロファイルの前記保護データにアクセスする任意の試みは、前記保護データをアクセスを試みた前記参加ノードと共有するためにユーザ同意を付与するための前記ユーザデバイスのプロンプト表示をトリガし、
    当該システムは、特定カテゴリの保護情報をアンロックし、又は特定文書をアンロックし、あるいは双方を行う要求と共に、ＧＵＩを前記ユーザデバイスに送信するウェブサーバをさらに含み、
    前記受信インターフェースは、前記ＧＵＩを介してどのカテゴリ及び／又は文書をアンロックすべきかを示すユーザ選択を受信し、
    前記ＧＵＩを介した任意のカテゴリ又は文書へのアクセスをアンロックする前記ユーザ選択が、前記保護データへのアクセスを試みた前記参加ノードにリンクを送信するように前記ブロックチェーン同意マネージャをトリガし、前記リンクは、前記ホスト組織の同意管理レイヤを通して前記ブロックチェーンから前記保護情報をアクセス可能にする、請求項１９に記載のシステム。

Images