特許 7451565 共有の秘密及び読み取りの合意を用いてメタデータ駆動型ブロックチェーン上で忘れられる権利を実施するシステム又は方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-08

(45)【発行日】2024-03-18

(54)【発明の名称】共有の秘密及び読み取りの合意を用いてメタデータ駆動型ブロックチェーン上で忘れられる権利を実施するシステム又は方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240311BHJP

   H04L 9/08 20060101ALI20240311BHJP

【ＦＩ】

H04L9/32 200Z

H04L9/08 A

【請求項の数】 9

(21)【出願番号】P 2021569434

(86)(22)【出願日】2020-05-21

(65)【公表番号】

(43)【公表日】2022-07-25

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

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

(87)【国際公開日】2020-11-26

【審査請求日】2022-01-24

(31)【優先権主張番号】62/851,589

(32)【優先日】2019-05-22

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

(31)【優先権主張番号】16/667,846

(32)【優先日】2019-10-29

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

(73)【特許権者】

【識別番号】506332063

【氏名又は名称】セールスフォース インコーポレイテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】パドマナブハン，プリトヴィ クリシュナン

【審査官】青木 重徳

(56)【参考文献】

【文献】米国特許出願公開第２０１９／００６５７６４（ＵＳ，Ａ１）

【文献】国際公開第２０１８／１０９０１０（ＷＯ，Ａ１）

【文献】国際公開第２０１８／１４９３８５（ＷＯ，Ａ１）

【文献】島 幸司 ほか，階層的秘密分散法の新しい構成法と評価，ＣＳＳ２０１７ コンピュータセキュリティシンポジウム２０１７ 論文集 ［ＣＤ－ＲＯＭ］ ，日本，一般社団法人情報処理学会，2017年10月16日，Vol.2017, No.2，ｐ．４５７－４６４

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｈ０４Ｌ ９／０８

ＪＳＴＰｌｕｓ／ＪＭＥＤＰｌｕｓ／ＪＳＴ７５８０（ＪＤｒｅａｍＩＩＩ）

(57)【特許請求の範囲】

【請求項1】

ブロックチェーン内のデータを忘れる要求を管理するためにホスト組織のシステムにより実行される方法であって、前記システムは、ブロックチェーンネットワーク内のノードとして機能する前記ホスト組織の複数のテナントのために前記ブロックチェーンに対するブロックチェーンインターフェースを提供し、当該方法は、
要求元の識別子を含む要求を受信するステップであり、前記要求はプライベートとして指定されたトランザクションデータにアクセスするためのものである、ステップと、
前記要求元の前記識別子又は前記トランザクションデータの識別子が、前記要求元に関連づけられたデータに対して又は前記トランザクションデータに対して忘れる要求が受信されたことを示すリストに含まれるかどうかを決定するステップと、
前記リストに含まれることが、前記トランザクションデータがアクセスするのに恒久的に利用できないことを示すときに、前記要求元の前記識別子又は前記トランザクションデータの前記識別子が前記リストに含まれるとき、前記トランザクションデータへのアクセスを拒否するステップと、
前記要求元の前記識別子又は前記トランザクションデータの前記識別子が前記リストに含まれないと決定することに応答して、
前記ブロックチェーンネットワーク内の前記ノードからの前記トランザクションデータへのアクセスを要求することであり、前記アクセスを要求することは前記要求元の前記識別子を含む、ことと、
前記ブロックチェーンネットワークによる合意を確立するのに不十分な数の共有秘密を前記ノードから受信することに応答して、前記トランザクションデータへのアクセスを拒否することと、
前記ブロックチェーンネットワークによる合意を確立するのに十分な数の共有秘密を前記ノードから受信することに応答して、前記トランザクションデータを復号することと、
を実行するステップと、
を含む方法。

【請求項2】

前記要求元の前記識別子が前記リスト上にあることを決定するステップ、
をさらに含む請求項１に記載の方法。

【請求項3】

一意ユーザ識別子に関連づけられたデータを忘れる要求を受信するステップと、
前記一意ユーザ識別子を前記リストに追加するステップと、
をさらに含む請求項１に記載の方法。

【請求項4】

前記トランザクションデータは、閾値数の共有秘密を受信することに応答して復号される、請求項１に記載の方法。

【請求項5】

復号鍵は、受信した共有秘密から復元される、請求項１に記載の方法。

【請求項6】

前記トランザクションデータへのアクセスを拒否することは、受信した共有秘密の数が暗号化の鍵を復元するための閾値を下回ることに応答したものである、請求項１に記載の方法。

【請求項7】

オブジェクト及びフィールドのプライベート情報の識別を含む、前記ブロックチェーンに記憶される前記トランザクションデータのオブジェクト及びメタデータを定義するステップ、
をさらに含む請求項１に記載の方法。

【請求項8】

ブロックチェーン内のデータを忘れる要求を管理する方法を実行するように構成されたホスト組織のコンピューティングシステムであって、当該コンピューティングシステムは、各々がブロックチェーンネットワーク内のノードとして機能する前記ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを提供し、
前記ブロックチェーンインターフェース及びパーミッションマネージャを内部に記憶させたコンピュータ読取可能媒体と、
前記ブロックチェーンインターフェース及び前記パーミッションマネージャを実行するプロセッサであり、前記パーミッションマネージャは、請求項１乃至７のうちいずれか１項に記載の方法を実行する、プロセッサと、
を含む、コンピューティングシステム。

【請求項9】

ホスト組織のコンピュータシステムにブロックチェーン内のデータの読み取りアクセスを管理する方法の動作のセットを実行させるコンピュータプログラムであって、前記コンピュータシステムは、ブロックチェーンネットワーク内のノードとして機能する前記ホスト組織の複数のテナントのために前記ブロックチェーンに対するブロックチェーンインターフェースを提供し、前記動作のセットは、請求項１乃至７のうちいずれか１項に記載の方法を実施する、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本出願は、2019年5月22日に出願された米国仮出願第62/851,589号の利益を主張する、2019年10月29日に出願された米国出願第16/667,846号に対する優先権を主張し、これらは参照により本明細書に組み込まれる。

【0002】

［技術分野］
本明細書に開示される実施形態は、概して、分散台帳技術及びブロックチェーンプラットフォームの分野に関する。より詳細には、開示される実施形態は、クラウドベースのコンピューティング環境と関連して分散台帳技術（ＤＬＴ）を使用するメタデータ駆動型ブロックチェーンプラットフォーム内のブロックチェーンからデータを読み取ることに関連するアクセス制限を実施するシステム、方法、及び装置に関する。

【背景技術】

【0003】

ブロックチェーンは、暗号法を用いてリンク及び安全化されるレコード／ブロックの継続的に拡張されるリストである。詳細には、ブロックチェーン内のあらゆるブロックは、直前のブロックの暗号ハッシュ、現在のブロックのタイムスタンプ、及びトランザクションデータ（例えば、ブロックチェーンネットワーク内のピアに関連づけられた情報の追加／修正）を含むことができる。さらに、ブロックチェーンは、チェーンに追加される新しいブロックを立証／検証するシステムを介してピアツーピアネットワークを通じて共有及び管理することができ、それにより、ブロックチェーン内のブロックは、全ての後続ブロックの改変なしに改変することはできず、これは、ネットワークの合意を必要とする。このアーキテクチャは、暗号法の使用を通じてブロック内に記憶された情報のセキュリティ、ピアツーピアネットワークの使用を通じた情報の共有／分散、ブロック追加の合意の使用を通じた信頼性、並びに暗号法の使用、ブロックのチェーン化／リンク、及びピア分散を通じてブロック内に記憶された情報の不変性（immutability）を可能にする（例えば、ブロックチェーンネットワークの各ピアは、ネットワーク内の全ての立証／検証されたトランザクションの台帳を維持することができる）。ブロックチェーンは、金融データを含む多くの異なるタイプのデータを記憶するために利用することができる。このような金融データは、分散された台帳として機能するブロックチェーンに記憶することができる。

【0004】

ブロックチェーン内の分散された台帳は、そのブロックチェーンの参加者全てにより共有される。分散台帳技術（Distributed Ledger Technology、ＤＬＴ）は、従来の金融システムの欠点の種類の多くに対処及び克服するのに役立つが、この技術は、それにもかかわらず、このようなＤＬＴ及び関連するブロックチェーンプラットフォームを利用する者にさらなる利益をもたらすように拡張することができる。現在利用可能なＤＬＴ及びこのようなＤＬＴ技術を利用するブロックチェーンは、固定された、不変の、及び静的な方法でデータを記憶する。したがって、ひとたびデータがブロックチェーンに書き込まれると、それはそこに固定され、記憶されたデータを記述し、データの形状を記述し、又はデータのタイプを記述するコンテキスト、メタデータ、又は任意の他の情報が全くない。結果的に、それは、ブロックチェーンから取り出されたデータをビジネス目的のために受け入れ可能なフォーマットに戻すことが、その記憶されたデータを記述する他のメタデータのコンテキストの欠如に起因して極めて困難であることを示し得る。

【0005】

またさらに、現在利用可能なＤＬＴ及びそのようなＤＬＴ技術を利用するブロックチェーンは、その全体をブロックチェーンに再書き込みされるために更新又は修正されるブロックチェーン上のいかなるレコードも必要とし、結果として、ブロックチェーン上における記憶データの合計ボリュームの激増をもたらし、これは、持続不可能であり最もリソース集約的でない可能性がある。他の考えられるアプローチは、ブロックチェーンにレコードの修正部分のみを書き込み、これは、非効率的なデータ取り出しを結果としてもたらし、なぜならば、完全なレコードが今やブロックチェーン上の複数のブロックの間で分割され、したがって、ブロックチェーン上の複数のブロックからデータを検索し、検査し、取り出すために、修正されたレコードの任意の取り出しを必要とするためである。

【0006】

さらに、現在利用可能なＤＬＴ及びブロックチェーンは、データを、それがネットワーク内の任意のノードにアクセス可能であるようにブロックチェーンに記憶する。ブロックチェーン内のデータは、決して除去されない。これらの特性に起因して、ＤＬＴ及びブロックチェーンは、データを恒久的に削除することが必要である場合、又はブロックチェーンに格納されたデータへのアクセス特権を制限することが望ましい場合に、アプリケーションでの使用に対して適合が不十分な可能性がある。

【図面の簡単な説明】

【0007】

以下の図は、同様の要素を参照するために同様の参照番号を使用している。以下の図は様々な例示的な実装を示すが、代替的な実装は別記の特許請求の範囲の主旨及び範囲内にある。

【図1A】説明される実施形態による一例示的なアーキテクチャを示す。

【図1B】説明される実施形態による、ブロックバリデータと関連して動作するブロックチェーンプロトコルブロックのさらなる詳細を有する別の例示的なアーキテクチャを示す。

【図1C】説明される実施形態による、さらに詳細に説明されるブロックチェーンメタデータ定義マネージャのさらなる詳細を有する別の例示的なアーキテクチャを示す。

【図1D】説明される実施形態による、ホスト組織サービスのブロックチェーンサービスインターフェースとの統合をより詳細に示す別の例示的なアーキテクチャを示す。

【図1E】説明される実施形態による、ブロックチェーンサービスインターフェースを利用する例示的なデータフローを示す別の例示的なアーキテクチャを示す。

【図2A】説明される実施形態による、ブロックチェーン及びフォークしたブロックチェーンのさらなる詳細を有する別の例示的なアーキテクチャを示す。

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

【図3A】説明される実施形態による一例示的なアーキテクチャを示す。

【図3B】説明される実施形態による別の例示的なアーキテクチャを示す。

【図3C】説明される実施形態による別の例示的なアーキテクチャを示す。

【図3D】説明される実施形態による別の例示的なアーキテクチャを示す。

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

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

【図4C】説明される実施形態による、ブロックチェーンに永続的に記憶されたレコードのためにＡｐｅｘ翻訳エンジンを利用するＳＱＬフィルタリング及びクエリトランスレータのさらなる詳細を有する別の例示的なアーキテクチャを示す。

【図5A】説明される実施形態による別の例示的なアーキテクチャを示す。

【図5B】説明される実施形態による、記憶されるデータの動的メタデータ検証を実行する別の例示的なアーキテクチャを示す。

【図5C】説明される実施形態による、関連エンティティを記憶する別の例示的なアーキテクチャを示す。

【図6A】説明される実施形態による、インデキシングスキームを使用してアドレス指定可能ブロックから記憶されたレコードを取り出す別の例示的なアーキテクチャを示す。

【図6B】説明される実施形態による、ブロックチェーン内のレコードからインデックスを構築してインデックスを維持する別の例示的なアーキテクチャを示す。

【図6C】説明される実施形態による、インデックスから情報を取り出すためのアドレスを形成するためにアドレス指定構造を利用する別の例示的なアーキテクチャを示す。

【図6D】説明される実施形態による、インデックスから情報を取り出すためにアドレスを利用する別の例示的なアーキテクチャを示す。

【図6E】説明される実施形態による、現在の更新を記憶するためにインデックスを使用して記憶レコードのためのブロックチェーン資産を増分的に更新する別の例示的なアーキテクチャを示す。

【図7A】説明される実施形態による別の例示的なアーキテクチャを示す。

【図7B】説明される実施形態による別の例示的なアーキテクチャを示す。

【図7C】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8A】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8B】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8C】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8D】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8E】説明される実施形態による別の例示的なアーキテクチャを示す。

【図8F】説明される実施形態による別の例示的なアーキテクチャを示す。

【図9A】説明される実施形態による別の例示的なアーキテクチャを示す。

【図9B】説明される実施形態による別の例示的なアーキテクチャを示す。

【図9C】説明される実施形態による別の例示的なアーキテクチャを示す。

【図10】読み取りに関する合意のためのプロセスの一実施形態のフローチャートである。

【図11A】ブロックチェーンサービスインターフェース内で忘れる権利機能を実施するプロセスのセットに関連するフローチャートである。

【図11B】ブロックチェーンサービスインターフェース内で忘れる権利機能を実施するプロセスのセットに関連するフローチャートである。

【図11C】ブロックチェーンサービスインターフェース内で忘れる権利機能を実施するプロセスのセットに関連するフローチャートである。

【図11D】一例示的な欧州連合一般データ保護規則（ＧＤＰＲ）実装の図である。

【図12A】ブロックチェーンサービスインターフェース内でアクセス制御機能を実施するプロセスのセットに関連するフローチャートである。

【図12B】ブロックチェーンサービスインターフェース内でアクセス制御機能を実施するプロセスのセットに関連するフローチャートである。

【図12C】ブロックチェーンサービスインターフェース内でアクセス制御機能を実施するプロセスのセットに関連するフローチャートである。

【図12D】一例示的なアクセス制御プロセスの実装の図である。

【図13】説明される実施形態による、分散台帳技術（ＤＬＴ）を使用するブロックチェーン内のデータ及びメタデータの効率的な記憶及び検証を実施する方法を示すフロー図を示す。

【図14】説明される実施形態による、実施形態が動作し、設置され、統合され、又は構成され得るシステムの概略表現を示す。

【図15A】説明される実施形態による別の例示的なアーキテクチャを示す。

【図15B】説明される実施形態による別の例示的なアーキテクチャを示す。

【図15C】説明される実施形態による別の例示的なアーキテクチャを示す。

【図16】説明される実施形態による、クラウドベースのコンピューティング環境と関連して分散台帳技術（ＤＬＴ）を使用して宣言型及びメタデータ駆動型ブロックチェーンプラットフォームを実施する方法を示すフロー図を示す。

【図17】説明される実施形態による、クラウドベースのコンピューティング環境と関連して、宣言型の、メタデータ駆動型の、暗号的に立証可能なマルチネットワーク（マルチテナント）共有台帳を実施する方法を示すフロー図を示す。

【図18A】説明される実施形態による、オンデマンドデータベースサービスが動作し得る一環境のブロック図を示す。

【図18B】説明される実施形態による、図１０Ａの要素及びこのような要素間の様々な可能な相互接続の一実施形態の別のブロック図を示す。

【図19】いくつかの実施形態による、コンピュータシステムの例示的な形態のマシンの概略表現を示す。

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

【0008】

本明細書では、メタデータ駆動型（metadata driven）ブロックチェーンプラットフォームにおける読み取りに関する合意プロセスに基づいてアクセス制御及び忘れる権利を実施するシステム、方法、及び装置について説明する。いくつかの実施形態において、メタデータ駆動型ブロックチェーンプラットフォームは、クラウドベースのコンピューティング環境と関連して分散台帳技術（Distributed Ledger Technology、ＤＬＴ）を使用する。

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

ホスト組織で受信される特定の要求１１５は、ホスト組織１１０のブロックチェーンサービスインターフェース１９０が仲介者として動作するブロックチェーンに向けることができる。

【0018】

クエリインターフェース１８０は、データベースシステム１３０のデータベース及び記憶コンポーネントに対して要求されたクエリを受信及び実行し、説明される方法論を促進するために結果セット、応答、又は他の要求されたデータを返すことができる。さらに、クエリインターフェース１８０は、クエリをウェブサーバ１７５から、検索クエリを処理するデータベース１５５に対する実行のためにデータベースシステム１３０に、又はホスト組織のコンピューティング環境１１１の他の利用可能なデータストアに渡す機能を提供する。一実施形態において、クエリインターフェース１８０は、データベース１５５又は他のデータストアに対してクエリが実行され得るアプリケーションプログラミングインターフェース（ＡＰＩ）を実装する。さらに、クエリインターフェース１８０は、ブロックチェーンサービスインターフェース１９０との相互運用性を提供し、したがって、ホスト組織１１０は、クエリインターフェース１８０を介してデータベースシステム１３０との間でトランザクションを実行し、又は、ホスト組織１１０が参加ノードであるか又は参加ノード１３３と通信している接続されたブロックチェーン上へブロックチェーントランザクションをトランザクション処理する（transact）ことができ、あるいは、ホスト組織１１０は、データベースシステム１３０により永続化される（persisted）（クエリインターフェース１８０を介してアクセス可能な）データを伴うトランザクション、及び接続されたブロックチェーンにより永続化される（例えば、参加ノード１３３から、又は、ホスト組織がそのようなブロックチェーン上の参加ノードを動作させている場合には接続されたブロックチェーンから直接、アクセス可能な）データを伴うトランザクションの双方のトランザクションを実行することができる。

【0019】

特定の実施形態において、クエリインターフェース１８０のアプリケーションプログラミングインターフェース（ＡＰＩ）は、プログラマ、開発者、及び管理者がＡＰＩコール元命令の必要及び特定の要件に応じてブロックチェーンサービスインターフェース１９０若しくはデータベースシステム１３０又は双方と相互作用することができるＡＰＩモデルを提供する。

【0020】

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

【0021】

さらに、ホスト組織１１０内には、ブロックチェーン合意マネージャ１９１の双方をその中に含むブロックチェーンサービスインターフェース１９０が示されており、ブロックチェーン合意マネージャ１９１は、テナント、顧客組織、又はホスト組織自体１１０がサポートされたブロックチェーン上の参加ノードとして動作するプライベート及びパブリックブロックチェーンの合意管理を容易にする。さらに、ブロックチェーンメタデータ定義マネージャ１９６が示されており、これは、ブロックチェーンサービスインターフェース１９０がメタデータを定義及び作成することを可能にし、それは次いで、ブロックチェーンインターフェースを介してインターフェースされるブロックチェーンへプッシュされ、トランザクション処理される。例えば、ブロックチェーンメタデータ定義マネージャ１９６を介して、ホスト組織の任意の顧客組織１０５Ａ～Ｃがメタデータを定義及び作成することが可能であり、それは次いで、ブロックチェーンへ記録又はトランザクション処理されてその顧客組織１０５Ａ～Ｃにより使用され、及びブロックチェーン上の他の参加ノードにより使用され、これは、それらの参加ノード１３３もホスト組織１１０との間で顧客組織１０５Ａ～Ｃであるか否かにかかわらない。例えば、ひとたびメタデータがブロックチェーンメタデータ定義マネージャ１９６を介して定義及び作成され、ブロックチェーン上へプッシュされると、そのメタデータ定義が存在するブロックチェーンへのアクセスを有する参加ノード１３３は、次いで、データレコードを作成し、ブロックチェーン上へ情報を格納することができ、これは、定義されたメタデータ定義を採用しており、したがって、新たに作成されたメタデータ定義に準拠する。このようにして、全ての参加ノードは、そのようなデータを記憶するための標準化されたカスタマイズ可能な方法があるため、新たに作成されたメタデータ定義に準拠して記憶された情報を利用することができる。

【0022】

一実施形態において、ブロックチェーン合意マネージャ１９１及びブロックチェーンメタデータ定義マネージャ１９６は、図１０～図１２を参照して本明細書で以下にさらに説明されるように、読み取りに関する合意機能を実施するために関連して動作する。読み取りに関する合意は、ブロックチェーンに記憶されたデータへの読み取りアクセスを制御するための特定のタイプの合意である。データは、暗号化されたフォーマットで記憶され、暗号化鍵は、ブロックチェーンプラットフォーム内の他のノードと共有された秘密として分散される。ネットワークのノード１３３は、データにアクセスする要求が行われたとき、読み取りに関する合意オペレーションを実行する。読み取りに関する合意プロセスは、クレデンシャル、又は必要とされると決定された任意の構成された基準を調べ、これは、アクセス要求内で提供される。読み取りアクセスを承認した各ノードは、共有秘密のうちのそれの部分で応答し、これは、要求ノードが共有秘密から鍵を生成してブロックチェーン上のデータを復号し、データにアクセスすることを可能にする。暗号化されたデータへのアクセスを可能にするためには、閾値数の秘密が返されなければならない。閾値数は、読み取りに関する合意プロセスで利用される共有秘密アルゴリズム（例えば、Ｓｈａｍｉｒの秘密共有アルゴリズム）により構成及び／又は決定することができる。

【0023】

さらなる実施形態において、パーミッションマネージャ（permissions manager）１８１は、ブロックチェーンに記憶されたデータのためのメタデータに定義されるようにアクセス制御及び特権を強制するように動作する。パーミッションマネージャ１８１は、読み取り及び書き込みアクセス制御を含むアクセス制御においてレコード、オブジェクト、フィールド、又は同様のレベルの粒度へのアクセスに関する制限を強制することができる。パーミッションマネージャ１８１は、アクセス特権を定義するメタデータに基づいてブロックチェーンデータの管理を強制することができる。アクセス特権は、一意ユーザ識別子（unique user identifier、ＵＵＩＤ）又は同様のエンティティ識別子を利用することができる。メタデータは、ブロックチェーン内のデータを読み取り又は書き込むパーミッションを有するエンティティのリストを定義することができる。メタデータは、アクセス制御された情報へのアクセスを管理するために利用される読み取りに関する合意プロセスを制御する所有者のセットを定義することもできる。いくつかの実施形態において、パーミッションマネージャ１８１は、忘れる権利プロセス（例えば、欧州連合一般データ保護規則（ＧＤＰＲ）に準拠する）又はブロックチェーンからデータを「消去」する同様のプロセスを実施することができる。忘れる権利及びアクセス特権を含む、パーミッションマネージャ１８１の動作及びブロックチェーン合意マネージャ１９１の読み取りに関する合意プロセスは、図１０～図１２に関連して本明細書でさらに論じられ、説明される。

【0024】

ここで示すように、ブロックチェーンサービスインターフェース１９０は、ホスト組織１１０を他の参加ノード１３３と（例えば、ネットワーク１２５を介して）通信上インターフェースして、ホスト組織１１０がブロックチェーンプロトコル準拠ノードとして作用することにより利用可能なブロックチェーンプロトコルに参加することを可能にし、これは次に、ホスト組織１１０がそのようなブロックチェーン内の情報にアクセスすることを可能にすると共に、ホスト組織１１０が他の参加ノード１３３に、ホスト組織１１０によりサポートされ、ホスト組織１１０により顧客及びサブスクライバ（subscribers）に提供される任意の数のブロックチェーンプロトコルについてブロックチェーンサービスを提供することを可能にする。特定の実施形態において、ホスト組織１１０は双方、ホスト組織が参加ノードとしても動作するブロックチェーンプロトコルを提供する。他の実施形態において、ホスト組織は、ホスト組織１１０が他者により提供されたブロックチェーンプロトコルと相互作用することができるように、単に参加ノードとして動作する。

【0025】

特定の実施形態によれば、ブロックチェーンメタデータ定義マネージャ１９６は、さらに、ホスト組織の非サブスクライバ（例えば、顧客組織１０５Ａ～Ｃでないエンティティ）がそれにもかかわらず、そのようなサブスクライブしていない顧客に対して公開されたＡＰＩインターフェースを介してブロックチェーンメタデータ定義マネージャ１９６及びブロックチェーンメタデータ定義マネージャ１９６に関連づけられたグラフィカルユーザインターフェース（ＧＵＩ）を利用することを可能にし、サブスクライブしていない顧客は次いで、メタデータ定義を作成及び定義することができ、これは次いで、ホスト組織のブロックチェーンサービスインターフェース１９０を介してブロックチェーン上へプッシュされる。

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

本明細書で論じられるように、実施形態は、許可あり又はパブリックのブロックチェーンに適用可能な特定の場合のためのブロックチェーンアクセス制御を提供するが、オープンで、許可なしの、又はパブリックのブロックチェーンネットワークの利点は、悪い行為者に対する防護が必要なく、アクセス制御が一般に必要ないことである。これは、ブロックチェーンをトランスポート層として使用して、他者の承認や信頼なくアプリケーションがネットワークに追加され得ることを意味する。反対に、許可ありの（例えば、プライベートの）ブロックチェーンは、アクセス制御層を使用して、ネットワークに対して誰がアクセスを有するかを管理する。実施形態は、さらに、プライベート又はパブリックのブロックチェーンの内部又は外部のエンティティのためのアクセス制御を提供する。パブリックブロックチェーンネットワークと対照的に、プライベートブロックチェーンネットワーク上のバリデータは、例えば、ネットワーク所有者、又はコンソーシアムの１以上のメンバにより調べられる。これらは、既知のノードに依存してトランザクションを検証する。許可ありのブロックチェーンは、「コンソーシアム」又は「ハイブリッド」ブロックチェーンとも呼ばれている。今日、多くの企業は、パブリックブロックチェーンシステムから独立した、プライベートブロックチェーンを有するブロックチェーンネットワーク、又はブロックチェーンベースの分散台帳を使用している。

【0037】

図１Ｂは、説明される実施形態による、ブロックバリデータ１９２と関連して動作するブロックチェーンプロトコルブロック１６０のさらなる詳細を有する別の例示的なアーキテクチャ１０１を示す。図１０～図１２に関連して本明細書で以下にさらに説明されるように、ブロックチェーン合意マネージャ１９１は読み取りに関する合意を実施し、パーミッションマネージャ１８１はアクセス制御及び同様の動作をサポートする。

【0038】

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

【0039】

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

【0040】

特定の実施形態によれば、ここに図示されるブロックチェーンメタデータ定義マネージャ１９６は、ホスト組織１１０により提供される、したがって適用可能なブロックチェーンプロトコルがホスト組織１１０により定義される特定のブロックチェーン実装を利用することができ、あるいは代わりに、ブロックチェーンメタデータ定義マネージャ１９６は、アクセスを確立するためにホスト組織が参加ノードとして動作する任意のパブリックにアクセス可能なブロックチェーンを利用してもよく、あるいは、ブロックチェーンメタデータ定義マネージャ１９６は、ホスト組織１１０により提供されないものを含むプライベートブロックチェーンを、ホスト組織がそのようなプライベートブロックチェーンで認証し、プライベートブロックチェーン上の参加ノードとして動作することによりブロックチェーンにアクセスすることができる限り、利用してもよい。

【0041】

以下により詳細に説明されるように、ブロックチェーンメタデータ定義マネージャ１９６は、特化されたメタデータ定義及び作成スキームを実施し、このスキームは、ウェブサーバ１７５などの、ＡＰＩを介してか又はホスト組織のインターフェースを介してかのいずれかでホスト組織により提供されるＧＵＩ及び他のユーザフレンドリなインターフェースの使用を含むことができ、上記を介し、ユーザ及び顧客組織は、ホスト組織と、より詳細にはホスト組織により提供されるサービス及びアプリケーションと相互作用することができ、これには、ブロックチェーンメタデータ定義マネージャ１９６により提供されるＧＵＩの使用が含まれ、これは、クラウドコンピューティングプラットフォームを介してホスト組織のテナントにアクセス可能にされ、特定の実施形態では、ホスト組織１１０の非テナント及び非サブスクライバに利用可能にされ、これらのいずれも、次いで、ブロックチェーンメタデータ定義マネージャ１９６により提供されるＧＵＩ及び機能を利用することができる。

【0042】

特定の実施形態によれば、ブロックチェーンメタデータ定義マネージャ１９６により実施される特化されたメタデータ定義及び作成スキームの使用をサポートするために、カスタマイズされたブロックチェーンプロトコルの実装がホスト組織により提供されることが必要であり得るが、メタデータがホスト組織１１０により許容される方法で（permissibly）定義され、ブロックチェーン上へ記憶され得る実施形態において、そのようなデータを記憶するために利用される任意のブロックチェーンは、その他の点で影響を受けず、なぜならば、どんなタイプのメタデータがホスト組織により定義又は作成され、ブロックチェーン上へトランザクション処理されるかについて、ブロックチェーンは不可知的であるためである。言い換えると、ホスト組織１１０がそのようなメタデータの定義及び作成を容易にし、その情報をブロックチェーン上へトランザクション処理する間、ブロックチェーンにとって、どんなアプリケーションがそのようなデータを利用することを選択するかは重要ではない。一方、ホスト組織は、アプリケーションが定義及び作成されたメタデータに準拠するデータのみを利用することを選択することができるプラットフォームを容易にし、したがって、そのようなデータの転送可能性（transferability）と、多くの他の利点を可能にする。

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

図１Ｃは、説明される実施形態による、さらに詳細に説明されるブロックチェーンメタデータ定義マネージャ１９６のさらなる詳細を有する別の例示的なアーキテクチャ１０２を示す。

【0053】

ここに見られるように、ブロックチェーンメタデータ定義マネージャ１９６を含むブロックチェーンサービスインターフェース１９０がある。さらに、ブロックチェーンメタデータ定義マネージャ１９６の様々な要素と相互作用するように示されているのは、メタデータ定義及び作成スキームに参加するネットワークメンバを確立することができる統合ビルダ１５３、並びにブロックチェーン合意マネージャ１９１及びブロックバリデータ１９２である。

【0054】

ブロックチェーンメタデータ定義マネージャ１９６の内部には、ホスト組織のテナント及び顧客組織の双方、並びにホスト組織のサービスの非サブスクライバと相互作用することができる信頼層１５４及び中央集権型信頼インターフェース１５２を含む、様々なさらなる要素がある。さらに、アクセス可能なブロックチェーンに対して作成及びプッシュされる全ての現在定義されているメタデータ定義の知識を有するメタデータ層１５６があり、その後に、様々にアクセス可能なブロックチェーンへのインターフェースとして機能するネットワーク組織（network organization）１５７層又は共有台帳が続く。状態台帳１５９は、アクセス可能なブロックチェーンのステータス及び任意の接続又は非接続状態を維持し、一方、履歴１６１のブロックは、プラットフォームのトランザクション履歴及びログを維持する。統合プラットフォーム層１５８は、ブロックチェーンメタデータ定義マネージャ１９６のコンポーネントとインターフェースするためにホスト組織１１０内の他のコンポーネントへのインターフェースを提供し、一方、アクセス制御層１６２は、以下により詳細に説明されるが、パブリックアクセスに対して完全にオープンではないプライベートの及び許可ありのブロックチェーンに対して特定のアクセス権及び制限を提供する。

【0055】

最後、様々なブロック台帳クライアントが示されており、ホスト組織のサブスクライブ顧客としてフルプラットフォームライセンスを享受するホスト組織の顧客１６４が含まれるが、ホスト組織のパートナー＃１を有するブロック１６６における次のブロック台帳クライアントは、ホスト組織により提供される限られたユーザ能力を有する基本ライセンス及びブロック台帳ライセンスのみを享受し、その後に、ホスト組織のパートナー＃２を有するブロック１６７における最後のブロック台帳クライアントが続いており、これは、ホスト組織により提供されるいかなるサブスクリプション必要ユーザサービスへのサブスクリプションもなく全ての当事者に利用可能なコミュニティライセンスに厳密に制限されている。

【0056】

高レベルからは、図示のアーキテクチャは同様のサービスをパブリックブロックチェーンに提供し、例外としては、この特定の実施形態によれば、共有台帳１５７がホスト組織の内部でブロックチェーンを動作させ、ホストされたネットワークｏｒｇ（network org）のブロックチェーンプロトコル、又はここで示されるいわゆる「共有台帳（shared ledger）１５７」を定義する点である。したがって、図示の共有台帳１５７は、顧客及び非顧客がｏｒｇ及びクライアント並びに非サブスクライブクライアントと相互作用することを可能にするが、必ずしも第三者インスタンスではなく、なぜならば、この特定の実施形態はホスト組織の内部で共有台帳１５７を動作させるためである。このようにして、パブリック及びプライベートのブロックチェーンにより提供される機能性は依然として実現及び利用され得るが、共有台帳１５７は完全にホスト組織１１０の内部であるため、修正された分散台帳技術（ＤＬＴ）を利用して共有台帳を動作させることが可能であり、これは、本文献により説明される他の関連する実施形態で典型的であるように、ブロックチェーン合意マネージャ１９１のより慣例的な使用よりもむしろ、中央集権的な信頼オーソリティとしての（及び、中央集権型信頼インターフェース１５２を介して信頼の検証を提供する）ホスト組織１１０の信頼層１５４に依存するように修正される。

【0057】

信頼オーソリティ（例えば、ホスト組織１１０、又はブロックチェーン合意マネージャ１９１により管理されるように合意に達する分散ノードである）にかかわらず、全てのデータは透過的であり、暗号的に立証可能であり、データ及びユーザは、ホスト組織の内部でホストされるにもかかわらず単一の当事者により所有されず、履歴１６１及び状態台帳１５９は、強化された監査証跡を提供する。統合ビルダ１５３は、共有データ上で実行され、及びネットワークｏｒｇ１５７自体により所有されるデータに対して実行されるスマートコントラクトの実行を可能にし、上記データは、例えば、全てのメンバにアクセス可能であるがそれにもかかわらずホスト組織により所有されたままであるメタデータ定義である。

【0058】

この特定の実施形態では、上述のように、信頼がホスト組織自体により信頼層１５４を介して確立されるため、合意の必要はないが、合意は、実装に応じて任意で利用されてもよい。

【0059】

特定の実施形態によれば、マルチテナント台帳プラットフォームがあり、これは、提供するネットワークレベルで機能し、ブロックチェーンを通して利用可能である同等量の透過性及び出所を提供するが、完全にホスト組織１１０の制御の範囲内にあり、したがって、ホスト組織１１０による中央集権的な信頼の確立などの特定の利益を提供する。

【0060】

このアーキテクチャは、中央集権型データベースと非中央集権型データベースとの間の折衷物を表し、注目すべきことに、分散台帳技術を利用したブロックチェーンの基本から逸脱しており、ゆえに分散データベースとして動作する。それにもかかわらず、ここに示されているのは、中央当事者として動作するホスト組織１１０であり、これは、ブロックチェーンサービスインターフェース１９０により、及びブロックチェーンサービスインターフェース１９０を通じて全てのテナントのために信頼を提供し、これは、信頼がネットワークにより、具体的には合意に達するネットワーク全体に分散されたノードにより提供されるブロックチェーンと対照的である。

【0061】

ホスト組織の共有台帳１５７を介して永続化されるデータ及び情報は、ネットワークにより、具体的には確立されたネットワークメンバにより完全に所有されるが、インフラストラクチャは中央当事者により所有され、この場合、ホスト組織１１０は、共有台帳１５７が動作するコンピューティングインフラストラクチャ及びリソースを所有、制御、及び管理する。したがって、任意の確立されたネットワークメンバがホスト組織を中央当事者として信頼する場合、システム及びアーキテクチャはその確立されたネットワークメンバのために動作する。しかしながら、注目すべきことに、確立されたネットワークメンバは、それらの信頼を第三者に、この場合はホスト組織１１０に置かなければならない。そうすることが、様々なデータセキュリティ要件、規制、又は他の懸念に基づいて可能でないか又は許容可能でない場合、ブロックチェーン合意マネージャ１９１により管理される分散ノードによる合意を必要とする分散台帳技術（ＤＬＴ）は、これらの当事者に対してより適切である。

【0062】

特定の実施形態によれば、テナント焦点ネットワークｏｒｇ又はテナント焦点共有台帳１５７が、再度、ホスト組織１１０（具体的には、ホスト組織のブロックチェーンサービスインターフェース１９０）の内部に設けられ、これにおいて、全てのユーザは、中央集権的な顧客により制御されるのではなく、各それぞれの顧客組織により制御される。言い換えると、テナント特有の顧客制御が存在し得、それにより、共有台帳１５７の所与のインスタンスに対する任意のユーザは、共有台帳１５７のそのインスタンスに対する権限を有するテナント又は顧客ｏｒｇにより制御される。このようにして、共有台帳１５７の複数のインスタンスが存在することができ、各々が特定の顧客ｏｒｇにより制御されるそのユーザセットを有し、ユーザを含めることを承認又は拒否するために任意の他の顧客ｏｒｇ、テナント、又は任意の他のエンティティに交渉し又は依存する必要がない。これは、共有台帳１５７のインスタンスがホスト組織により内部的にホストされているにもかかわらず、ホスト組織に承認される必要なく、共有台帳１５７のそれらのインスタンスにおいてどのユーザが許可されるかをそれ自身のために決定することができるテナントの顧客ｏｒｇを含む。これは、ホスト組織１１０が、共有台帳１５７の各それぞれのインスタンスに対してユーザを含めることに対する完全な制御を、その特定の共有台帳１５７が動作する顧客ｏｒｇに効果的に委譲するためである。

【0063】

特定の実施形態によれば、共有台帳１５７は、マークル有向非巡回グラフ（Merkle Directed Acyclic Graph）（ＤＡＧ）又は「マークルＤＡＧ」を具現化し、これは、ネイティブなマークルツリーと同様のデータ構造であり、例外としては、マークルＤＡＧ構造は平衡を保たれる必要がなく、その非リーフノードはデータを含むことを許容されることである。このような方法では、マークルＤＡＧは、ネイティブのマークルツリーと、それらが双方ともハッシュのツリーを具現化する点で同様である。マークルツリーはトランザクションをシーケンスで接続するが、マークルＤＡＧは、それがトランザクションをハッシュで接続する程度まで区別される。したがって、マークルＤＡＧ構造では、アドレスはマークルハッシュにより表現される。結果として生じるマークルハッシュのスパイダーウェブは、マークルグラフによりデータアドレスを一緒にリンクする。したがって、マークルＤＡＧの有向非巡回グラフ（ＤＡＧ）部分は、情報をモデル化するために利用されてもよく、例えば、どんな特定のアドレスが特定のデータを記憶するかをモデル化する。

【0064】

別の実施形態によれば、データは、共有台帳１５７の各インスタンス内で暗号化され、暗号的に立証可能である。例えば、ブロックチェーンサービスインターフェース１９０プラットフォームの拡張を利用し、共有台帳１５７のインスタンスを有する任意のテナントは、共有台帳１５７のそれらのインスタンス内の任意の記憶された暗号化データを暗号的に立証することができる。

【0065】

上述のように、多くの顧客にとって、クラウドベースのコンピューティングインフラストラクチャ及びソフトウェアをリース又はサブスクライブすることは、こうしたコンピューティングインフラストラクチャをそれら自身で所有、運用、保守、及び構成する必要があるよりもはるかに好ましい。特定の顧客とパートナーが、それらのデータと台帳の透過性のみを必要とする（例えば、分散ノード間の合意を必ずしも必要としない）場合、そのようなソリューションは、競合する代替策に対して実質的な改善を表す。ブロックチェーン技術は多くの利点を提示し、その多くは本文献で他の箇所でより詳細に説明されるが、現実には、特定の顧客は単にデータ及び台帳の非中央集権化に関心がなく、したがって、中央集権型信頼インターフェース１５２によりホスト組織１１０内で完全に運用される共有台帳１５７インスタンスを利用することから相当な利益を実現し、したがって、分散ブロックチェーン台帳に共通の他の合意レジームに参加する必要を否定することができる。

【0066】

一実施形態によれば、共有台帳１５７は、ホスト組織１１０によることを含むいかなる当事者によっても不変である監査証跡を提供し、したがって、競合するソリューションにより提供される標準的な監査証跡より優れたセキュリティ、透過性、及び保証を提供する。したがって、標準的な中央集権型システムと比較したとき、共有台帳１５７を利用するとき、テナント及び顧客組織に付加価値がもたらされる。

【0067】

またさらに、共有台帳１５７は、マルチテナント認識であり（例えば、各テナント又は顧客組織は、共有台帳１５７のそれ自身のインスタンスを利用することができる）、メタデータ駆動型であり、トリガを介して実行可能なスマートコントラクトを有するため、ホスト組織のテナントサブスクライバにとって、ホスト組織により提供されるプラットフォームの利益を上回る及び超える複数の利点がある。

【0068】

衣料品から生鮮品までに及ぶ製品のサプライチェーンを管理するためにブロックチェーンを利用して市場に進出したい大規模小売業者の例について考える。このような例は、衣料用の原材料としての綿と、包装された製品として店舗で販売される葉物野菜を用いて始めてもよい。最終的には、大規模小売業者は完全なブロックチェーンソリューションに進化し得るが、最初、多くの顧客は、ホスト組織により提供される共有台帳１５７などの完全に制御された単一の信頼点及びホストされたソリューションを利用することを好む可能性がある。ホストされた共有台帳ソリューションで最初始める理由は、それらにクラウドベースのサービスをすでに提供しているそれらの現在のホスト組織を介して単一のログイン又は単一の認証ポータルを可能にし得、これは次いで、大規模小売業者がそれらの検証された台帳情報をシングルサインオンポータルから閲覧することを可能にすると同時に、大規模小売業者が分散台帳技術（ＤＬＴ）を試すことを可能にする。

【0069】

したがって、このような構造は、大規模小売業者が、例として、ホスト組織１１０内であるにもかかわらず不変の共有台帳１５７内にデータが記憶されていることに起因してデータの不変性にそれらの信頼を置くことを可能にする。これは、ホスト組織でさえ共有台帳１５７の監査証跡を改変することができないため、可能である。これは、従前のクラウドベースのプラットフォームの使用と対照的であり、それは、標準化された監査証跡を提供するが、監査証跡が全ての当事者によって不変ではないため、それは理論的には、そのようなシナリオはかなり可能性が低いものの、悪意のある行為者により操作される可能性がある。それにもかかわらず、修正されたＤＬＴ技術を利用する共有台帳１５７は、設計上、その監査証跡の観点で全当事者により不変であり、したがって、ホスト組織でさえ共有台帳１５７内に記憶された履歴レコードを改変する能力がないと仮定し、ホスト組織などの中央集権的な信頼オーソリティにより高いレベルの信頼が適宜置かれ得る。

【0070】

同じ論理は、１つの会社内及びその子会社内で内部的にこのような台帳を利用することを望む企業に適用されてもよく、なぜならば、そうすることで、会社及びその子会社間のより良い統合及びデータ共有を可能にし、一方、共有台帳の不変性からの恩恵を受け、これは、ローカル及びリモートで運用されるデータベース又は厳密にオンデマンドのクラウドベースのソリューションなどの競合するソリューションにより提供され得るものを上回り、超える。

【0071】

例えば、販売リード情報を商業銀行部門や全国にわたり複数の部門を有するヘルスケア企業と共有したいモーゲージ部門について考える。これらは、様々な部門間で十分に統合されておらず、結果として、重複した業務センターをもたらしており、例えば、北カリフォルニアのクレーム処理グループと南カリフォルニアの別のクレーム処理グループなどであり、これらは、現在は完全な統合を欠いているが、ホストされた共有台帳１５７ソリューションにマイグレートして、より良い統合、プラットフォームに書かれたレコードの不変性を通じて信頼された監査証跡、ひいては、大規模ヘルスケアプロバイダの様々な部門により利用されるデータの改善された使いやすさと透過性を実現することができる。

【0072】

したがって、特定の実施形態によれば、ホスト組織のシステムによる動作があり、これには、共有台帳に対する複数の認可されたネットワーク参加者のために共有台帳へのインターフェースを動作させ、これにおいて、共有台帳は複数の分散共有台帳ノードを介してデータを永続化すること；共有台帳内にネットワークｏｒｇを生成して、複数の認可されたネットワーク参加者のうちの最初の認可されたネットワーク参加者としての創設者ｏｒｇ（founder org）のためにデータを記憶すること；創設者ｏｒｇから、ネットワークｏｒｇに対するさらなる認可されたネットワーク参加者としての複数のパートナーｏｒｇを定義する入力を受信し、これにおいて、認可されたネットワーク参加者の全てが、データを複製することなく共有台帳を介してネットワークｏｒｇにより記憶されたデータへの読み取りアクセスを有すること；創設者ｏｒｇから、パートナーｏｒｇの各々が共有台帳内でネットワークｏｒｇと相互作用するためのパーミッションを定義する入力を受信すること；共有台帳に、少なくともネットワークｏｒｇに対して認可されたネットワーク参加者とパートナーｏｒｇの各々に対して定義されたパーミッションとを定義するメタデータを書き込むこと；認可されたネットワーク参加者から、ネットワークｏｒｇと相互作用する要求を受信すること；及び、要求の履行（fulfillment）において共有台帳との間でトランザクション処理することが含まれる。

【0073】

別の実施形態の動作によれば、共有台帳は、ホスト組織の内部の関係データベースシステム上で動作する宣言型の、メタデータ駆動型の、暗号的に立証可能なマルチネットワーク（マルチテナント）共有台帳を含み、この方法はさらに、パートナーｏｒｇの各々に、及び創設者ｏｒｇに一意ネットワークＩＤを割り当てることと、ネットワークＩＤによりネットワークｏｒｇのデータを記憶させた関係データベースシステムのテーブルを区分することを含む。

【0074】

別の実施形態の動作によれば、関係データベースシステムは、複数の共有台帳ノードを介してネットワークｏｒｇ内に記憶されたデータに影響を及ぼす全ての挿入、削除、及び更新を記録する監査ログを不変に記憶する。

【0075】

別の実施形態の動作によれば、要求の履行において共有台帳との間でトランザクション処理することは、少なくとも、（ｉ）共有台帳からネットワークｏｒｇのためのメタデータを取り出すこと、（ｉｉ）各要求が、ネットワークｏｒｇに対して認可されたネットワーク参加者のうちの１つに由来することを検証すること、（ｉｉｉ）各要求が、ネットワークｏｒｇのための取り出されたメタデータにより定義されるパーミッションに準拠した創設者ｏｒｇによる相互作用又はパートナーｏｒｇのうちの１つによる相互作用を指定していることを検証すること、及び（ｉｖ）成功裏の検証に従って要求の履行において共有台帳を介してネットワークｏｒｇとの間でトランザクション処理することを含む。

【0076】

別の実施形態の動作によれば、パートナーｏｒｇの各々についてメタデータにより定義されるパーミッションは、パートナーｏｒｇのうちの１つの要求におけるメタデータへの書き込みアクセスであり、創設者ｏｒｇにより付与されるメタデータへの書き込みアクセス；及び、パートナーｏｒｇのうちの１つの要求におけるネットワークｏｒｇにより記憶されたデータへの書き込みアクセスであり、創設者ｏｒｇにより付与されるデータへの書き込みアクセス；のうちの１つ以上を含む。

【0077】

別の実施形態の動作によれば、パートナーｏｒｇの各々についてメタデータにより定義されるパーミッションは、パートナーｏｒｇの１つに関連づけられた新しいユーザを作成するパーミッションを含む。

【0078】

別の実施形態の動作によれば、パートナーｏｒｇの各々についてメタデータにより定義されるパーミッションは、ネットワークｏｒｇに対する認可されたネットワーク参加者として新しいパートナーｏｒｇを追加するパーミッションを含む。

【0079】

別の実施形態の動作によれば、メタデータにより定義されるパーミッションはさらに、メタデータを修正するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；ネットワークｏｒｇにより記憶されたデータを修正するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；ネットワークｏｒｇからパートナーｏｒｇの１つを除去し、ネットワークｏｒｇに対して認可されたネットワーク参加者の１つとしての除去されたパートナーｏｒｇを排除するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；ネットワークｏｒｇに対して認可されたネットワーク参加者として新しいパートナーｏｒｇを追加するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の新しいビジネスロジックを宣言するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；及び、ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の新しいビジネスルールを宣言するために創設者ｏｒｇにより付与される、創設者ｏｒｇに対するパーミッション；のうちの１つ以上を含む。

【0080】

別の実施形態の動作によれば、共有台帳内にネットワーク組織により記憶されるデータは、ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通のアプリケーションデータレコード；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通のビジネスデータレコード；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の宣言されたビジネスロジック；及び、ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の宣言されたビジネスルール；のうちの１つ以上を含む。

【0081】

別の実施形態によれば、そのような動作はさらに、認可されたネットワーク参加者のうちの１つからの、共有台帳を介してローカライズされたデータを記憶する要求を受信すること；共有台帳を介してローカライズされたデータを記憶すること；これにおいて、記憶されたローカライズされたデータは、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能であり、記憶されたローカライズされたデータは、他の認可されたネットワーク参加者に公開されないこと；を含んでもよい。

【0082】

別の実施形態の動作によれば、記憶されたローカライズされたデータは、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能な、ネットワークｏｒｇにより記憶されたデータへの修正；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通のアプリケーションデータレコードへの修正であり、これにおいて、この修正は、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能であること；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通のビジネスデータレコードへの修正であり、これにおいて、この修正は、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能であること；ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の宣言されたビジネスロジックへの修正であり、これにおいて、この修正は、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能であること；及び、ネットワークｏｒｇに対して認可されたネットワーク参加者の全てにわたり共通の宣言されたビジネスルールへの修正であり、これにおいて、この修正は、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のみがアクセス可能であること；のうち少なくとも１つを含む。

【0083】

別の実施形態の動作によれば、記憶されたローカライズされたデータは、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のための新しいユーザアカウントと、新しいユーザアカウントに対して定義されたユーザパーミッションを含み、これにおいて、各認可されたネットワーク参加者は、共有台帳内にネットワーク組織により記憶されたデータに影響を及ぼすことなく区別可能なユーザ制御を有する。

【0084】

別の実施形態の動作によれば、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者は、ホスト組織内に複数のユーザを有する顧客組織であり、これにおいて、記憶されたローカライズされたデータは、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者のための新しいユーザアカウントを含み、新しいユーザアカウントは、顧客組織の複数のユーザアカウントに関連づけられたいずれのユーザアカウントとも区別可能である。

【0085】

別の実施形態の動作によれば、ローカライズされたデータを記憶する要求を発信した認可されたネットワーク参加者は、ホスト組織内にテナンシーを有する顧客組織であり、これにおいて、記憶されたローカライズされたデータは、ネットワークｏｒｇにより記憶されたデータに影響を及ぼす変更に基づいて顧客組織のＣＲＭデータに対して実行するための顧客組織特有のワークフローを含む。

【0086】

別の実施形態の動作によれば、ネットワークｏｒｇにより記憶されたデータ及びメタデータに影響を及ぼす全ての変更は暗号的に立証可能であり、少なくとも、どんなデータが変更されたか、データがいつ変更されたか、及び誰がデータに変更を行ったかを含むフルの監査ログを提供する。

【0087】

別の実施形態の動作によれば、認可されたネットワーク参加者の各々は、ホスト組織のテナントである。

【0088】

別の実施形態の動作によれば、創設者ｏｒｇは、ネットワークｏｒｇの生成を要求したホスト組織の複数のテナントのうちの最初のテナントであり、これにおいて、パートナーｏｒｇの各々は、創設者ｏｒｇとは異なるホスト組織のテナントであり、創設者ｏｒｇにより共有台帳に対して認可されたネットワーク参加者として追加されている。

【0089】

別の実施形態の動作によれば、ホスト組織のシステムは、オンデマンドサービス、オンデマンドデータベースサービス、及びクラウドコンピューティングサービスをサブスクライブ顧客組織に提供するクラウドベースの機能性を実施するためのハードウェア、ソフトウェア、及び論理要素を具現化し、これにおいて、創設者のｏｒｇとパートナーのｏｒｇの各々は、サブスクライバ顧客組織の中から選択され、クラウドベースの機能性は、パブリックインターネットを通じてサブスクライブ顧客組織がアクセス可能である。

【0090】

別の実施形態の動作によれば、ネットワークｏｒｇは、ホスト組織の複数の顧客組織のうちの１つとしてホスト組織により表される。

【0091】

別の実施形態の動作によれば、共有台帳は、ホスト組織の内部の関係データベースシステムを含み、これにおいて、ネットワークｏｒｇにより記憶されたデータのコピーは、複数の共有台帳ノードのうちの１つ以上を介してホスト組織の複数のデータセンターの各々からアクセス可能であり、この方法はさらに、ホスト組織の複数のデータセンターのうちの１つにおける停止に基づいて、又は複数の共有台帳ノードのうちの第１のものからの無応答に従って、複数の共有台帳ノードのうちの１つがアクセス不可能であると決定することと、決定の後、複数の共有台帳ノードのうちの第２のものから、共有台帳により記憶されたネットワークｏｒｇとの間でトランザクション処理することを含む。

【0092】

別の実施形態の動作によれば、共有台帳は、ホスト組織の内部の分散台帳技術（ＤＬＴ）データストアを実施し、これにおいて、ネットワークｏｒｇにより記憶されたデータのコピーは、ホスト組織の複数の地理的に分散されたデータセンターに分散された複数の共有台帳ノードの各々からアクセス可能であり、ＤＬＴデータストアは、ＤＬＴデータストアに追加された資産内の全てのデータを不変に記憶する。

【0093】

別の実施形態の動作によれば、ネットワークｏｒｇにおけるデータ削除トランザクションは、ＤＬＴデータストアからいかなるデータも除去することなくネットワークｏｒｇから削除されるデータを指定する新しい資産により表され、これにおいて、ネットワークｏｒｇにおけるデータ更新トランザクションは、ＤＬＴデータストアからいかなるデータも除去することなくネットワークｏｒｇで更新されたデータの現在のバージョンを指定する新しい資産により表され、ネットワークｏｒｇにトランザクション処理されたデータの全ての先行バージョンは、ＤＬＴデータストアにより不変に永続化され、ＤＬＴデータストアの監査ログを介して利用可能であり、これには、削除されたと指定された任意のデータと、１つ以上の更新により影響を受けたネットワークｏｒｇへトランザクション処理されたデータの全ての先行バージョンが含まれる。

【0094】

別の実施形態の動作によれば、ホスト組織は、ネットワークｏｒｇに対して認可されたネットワーク参加者のためにＤＬＴデータストアに対する任意のトランザクションを検証するために、中央集権的な信頼オーソリティとして動作する。

【0095】

別の実施形態の動作によれば、ＤＬＴデータストアは、完全にホスト組織の排他的制御下で動作するハードウェア及びソフトウェアインフラストラクチャを介して実施される。

【0096】

別の実施形態の動作によれば、共有台帳へのインターフェースを動作させることは、共有台帳に対して認可されたネットワーク参加者のためにブロックチェーンへのブロックチェーンサービスインターフェースを動作させることを含み、これにおいて、認可されたネットワーク参加者の各々は、ブロックチェーン上の参加ノードとして動作し、ホスト組織により動作するブロックチェーンサービスインターフェースを介してブロックチェーンとの間でトランザクション処理する。

【0097】

別の実施形態の動作によれば、ネットワークｏｒｇにより記憶されたデータのコピーは、ブロックチェーン上の参加ノードとして動作する認可されたネットワーク参加者のいずれからもアクセス可能であり、さらに、ブロックチェーン上の任意の他の参加ノードからアクセス可能であり、これにおいて、ブロックチェーンは、ブロックチェーンに追加された全てのレコードを不変に記憶し、削除及び更新により影響を受けたネットワークｏｒｇにより記憶されたデータは、ブロックチェーンの監査ログを介してデータの非現在のバージョンとしてブロックチェーンからアクセス可能なままである。

【0098】

別の実施形態の動作によれば、ホスト組織は、ブロックチェーン上の参加ノードを動作させ、これにおいて、ブロックチェーンは、ホスト組織の外部で動作し、ホスト組織の排他的制御の範囲外で動作する。

【0099】

別の実施形態の動作によれば、ネットワークｏｒｇは、共有台帳を介して動作する複数の区別可能なネットワークｏｒｇのうちの１つを含み、又は代わりに、ネットワークｏｒｇは、ホスト組織の固有の共有台帳インスタンス上で動作し、異なるネットワークｏｒｇは、ネットワークｏｒｇが動作する固有の共有台帳インスタンスとは別個のホスト組織内の他の共有台帳インスタンス上で動作する。

【0100】

別の実施形態の動作によれば、ネットワークｏｒｇにより記憶されたデータは、第１の宣言されたアプリケーション及び第２の宣言されたアプリケーションに関連づけられ、第１の宣言されたアプリケーションと第２の宣言されたアプリケーションの双方が、創設者ｏｒｇ及び複数のパートナーｏｒｇにより利用され、これにおいて、メタデータにより定義されたパーミッションは、パートナー組織の各々がデータに第１の宣言されたアプリケーションを利用してアクセスするか又は第２の宣言されたアプリケーションを利用してアクセスするかに基づいて、ネットワークｏｒｇにより記憶されたデータに対する異なるアクセスパーミッションを規定する。

【0101】

別の実施形態の動作によれば、共有台帳に書き込まれるメタデータはさらに、複数のエンティティタイプと、複数のエンティティタイプの各々についての複数のフィールド定義とを定義し、この方法はさらに、ホスト組織のデータベースシステム内に仮想テーブルを生成することと、共有台帳に書き込まれたメタデータに基づいてホスト組織のデータベースシステム内で仮想テーブルを構造化することを含み、これにおいて、共有台帳に書き込まれたメタデータからのエンティティは仮想テーブル内のテーブルとして表され、さらに、複数のエンティティタイプの各々についての１つ以上の新しいフィールド定義が仮想テーブルにおけるテーブル内の列として表される。

【0102】

別の実施形態の動作によれば、仮想テーブルは、新しいアプリケーションに対して宣言されたメタデータに基づいて構造化されたホスト組織のデータベースシステムでホストされたマテリアライズドビュー（materialized view）を含み、これにおいて、ホスト組織のデータベースシステムにホストされたマテリアライズドビューは、新しいアプリケーションに関連づけられたいかなるデータも記憶せず、読取専用アクセスを要求するＳＱＬクエリは、この読取専用ＳＱＬクエリを共有台帳から要求されたデータを取り出すための共有台帳トランザクションに翻訳する（translating）ことにより、マテリアライズドビューに対して処理される。

【0103】

別の実施形態の動作によれば、共有台帳に書き込まれるメタデータはさらに、複数のエンティティタイプと、複数のエンティティタイプの各々についての複数のフィールド定義とを定義し、この方法はさらに、複数のエンティティタイプと複数のエンティティタイプの各々についての１つ以上の新しいフィールド定義と１つ以上のフィールド定義に適用される任意のフィールドタイプとを含む、共有台帳からのメタデータを取り出すことと、定義されたメタデータに基づいて仮想テーブルを構造化することにより、ホスト組織における仮想テーブル内に共有台帳を介して記憶されたデータのマテリアライズドビューを生成することを含み、これにおいて、マテリアライズドビューは、ホスト組織におけるマテリアライズドビュー内にデータを記憶することなく、共有台帳により記憶された、関連づけられたデータの構造を表す。

【0104】

別の実施形態によれば、そのような動作はさらに、ホスト組織において、ユーザデバイスからＳＱＬ文を受信することであり、これにおいて、ＳＱＬ文はマテリアライズドビューに向けられ、ブロックチェーンに永続化され及び新しいアプリケーションに関連づけられたデータのためのＳＱＬ ｕｐｄａｔｅ又はＳＱＬ ｉｎｓｅｒｔを要求することと、共有台帳において新しいアプリケーションに関連づけられたデータを更新又は追加するために、ＳＱＬ ｕｐｄａｔｅ又はＳＱＬ ｉｎｓｅｒｔを要求するＳＱＬ文を対応する共有台帳トランザクションに翻訳することにより、マテリアライズドビューに対してＳＱＬ文を処理することと、対応する共有台帳トランザクションが共有台帳により受け入れられ、共有台帳において新しいアプリケーションに関連づけられたデータを成功裏に更新又は追加することに従って、マテリアライズドビューに対するＳＱＬ文の成功裏の処理を確認する確認応答をユーザデバイスに発行することを含んでもよい。

【0105】

別の実施形態によれば、そのような動作はさらに、ホスト組織においてマテリアライズドビューに向けられたＳＱＬ文を受信することを含んでもよく、これにおいて、ＳＱＬ文は、（ｉ）ＳＥＬＥＣＴ ｆｒｏｍのＳＱＬ文（ｉｉ）ＩＮＳＥＲＴ ｉｎｔｏのＳＱＬ文、及び（ｉｉｉ）ＵＰＤＡＴＥ ｓｅｔのＳＱＬ文のうちの１つ以上を指定し、受信されたＳＱＬ文は、ＳＱＬ文を対応する共有台帳トランザクションに翻訳し、ホスト組織におけるマテリアライズドビューに向けられたＳＱＬ文の履行において共有台帳に対して対応する共有台帳トランザクションを実行することにより処理される。

【0106】

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するシステムのプロセッサにより実行されると、命令はシステムに動作を実行させ、該動作は、共有台帳に対する複数の認可されたネットワーク参加者のために共有台帳へのインターフェースを動作させ、これにおいて、共有台帳は複数の分散共有台帳ノードを介してデータを永続化すること；共有台帳内にネットワークｏｒｇを生成して、複数の認可されたネットワーク参加者のうちの最初の認可されたネットワーク参加者としての創設者ｏｒｇのためにデータを記憶すること；創設者ｏｒｇから、ネットワークｏｒｇに対するさらなる認可されたネットワーク参加者としての複数のパートナーｏｒｇを定義する入力を受信し、これにおいて、認可されたネットワーク参加者の全てが、データを複製することなく共有台帳を介してネットワークｏｒｇにより記憶されたデータへの読み取りアクセスを有すること；創設者ｏｒｇから、パートナーｏｒｇの各々が共有台帳内でネットワークｏｒｇと相互作用するためのパーミッションを定義する入力を受信すること；共有台帳に、少なくともネットワークｏｒｇに対して認可されたネットワーク参加者とパートナーｏｒｇの各々に対して定義されたパーミッションとを定義するメタデータを書き込むこと；認可されたネットワーク参加者から、ネットワークｏｒｇと相互作用する要求を受信すること；及び、要求の履行において共有台帳との間でトランザクション処理することを含む。

【0107】

別の実施形態によれば、ホスト組織において実行するシステムがあり、当該システムは、命令を記憶するメモリと、命令を実行するプロセッサであり、プロセッサは、共有台帳に対する複数の認可されたネットワーク参加者のために共有台帳への共有台帳インターフェースを実行し、これにおいて、共有台帳は複数の分散共有台帳ノードを介してデータを永続化し、プロセッサは、共有台帳内にネットワークｏｒｇを生成して、複数の認可されたネットワーク参加者のうちの最初の認可されたネットワーク参加者としての創設者ｏｒｇのためにデータを記憶する、プロセッサと、創設者ｏｒｇから、ネットワークｏｒｇに対するさらなる認可されたネットワーク参加者としての複数のパートナーｏｒｇを定義する入力を受信する受信インターフェースであり、これにおいて、認可されたネットワーク参加者の全てが、データを複製することなく共有台帳を介してネットワークｏｒｇにより記憶されたデータへの読み取りアクセスを有し、受信インターフェースはさらに、創設者ｏｒｇから、パートナーｏｒｇの各々が共有台帳内でネットワークｏｒｇと相互作用するためのパーミッションを定義する入力を受信し、これにおいて、共有台帳インターフェースは、少なくともネットワークｏｒｇに対して認可されたネットワーク参加者とパートナーｏｒｇの各々に対して定義されたパーミッションとを定義する、共有台帳に対するメタデータに対し、受信インターフェースはさらに、認可されたネットワーク参加者から、ネットワークｏｒｇと相互作用する要求を受信し、これにおいて、共有台帳インターフェースはさらに、要求の履行において共有台帳との間でトランザクション処理する、受信インターフェースと、を含む。

【0108】

注目すべきことに、共有台帳は、ブロックチェーンと同様の非中央集権化能力を提供するが、前述のように、共有台帳は、ホスト組織の内部の共有台帳インスタンス上で実行されてもよく、ホスト組織の外部のパブリックブロックチェーン上で実行されてもよく、ホスト組織の外部のプライベートブロックチェーン又はホスト組織により実施されるプライベートブロックチェーン上で実行されてもよく、あるいは、共有台帳は、分散関係データベースシステム上で実行されてもよい。

【0109】

従来の解決策での１つの問題は、２つ以上の組織がデータを共有することに同意するときはいつでも、最終的に、組織の少なくとも１つが、アクセスパーミッションを変更し又は共有データの構造に対して任意の変更を行う援助のために、データリポジトリの創設者組織に戻らなければならないことである。さらに悪いことに、データリポジトリの創設者組織は、支援のために、例えば特定の管理権限を委譲するために、別の第三者に行かなければならない状況がある。

【0110】

共有台帳により、創設者組織は、どんな他のエンティティがパートナー組織として動作し得るかを指定することができ、さらに、創設者組織は、強化された管理特権をそれら及び他のパートナー組織に委譲することができる。例えば、パートナー組織は、ユーザを作成すること、又は共有台帳により永続化又は保存されるネットワークｏｒｇデータの構造を定義するメタデータを修正することを可能にされ得る。さらに、共有台帳は、特定の実施形態に従って、宣言型の、メタデータ駆動型の、暗号的に立証可能なマルチネットワーク（マルチテナント）共有台帳を実施し、これは、共有能力の履行において任意のデータを何であれ複製する必要なく、又は共有台帳の分散ノードの分散された性質から恩恵を受ける必要なく、創設者ｏｒｇとパートナーｏｒｇとの間におけるデータの共有を可能にする。

【0111】

例えば、アメリカンエキスプレスなどのクレジットカード会社により実施されるロイヤルティリワードプログラムについて考える。Ａｍｅｘは、情報が創設者組織及びパートナー組織としてＡｍｅｘの利益のために中央集権的な場所に収集され得るように、複数の異なるパートナー組織とデータを共有したい場合があり得る。従来の解決策では、パートナー組織の各々は、データアクセスのためにシステムにユーザを追加し、又はシステムに記憶されたデータに任意の変更を何であれ行うなどの必要があるときはいつでも、援助のために絶えずアメックスに戻る必要があるであろう。

【0112】

しかしながら、共有台帳の使用により、Ａｍｅｘなどの創設者ｏｒｇは、特定の権利をパートナーｏｒｇに委譲することができる。例えば、Ａｍｅｘは、パートナーｏｒｇがそれら独自のユーザアカウントを作成し、あるいは創設者ｏｒｇとパートナーｏｒｇにより共有されるビジネスロジックを修正し、あるいは全てのパートナーｏｒｇ及び創設者ｏｒｇにより共有される共有台帳内のデータの共通プールに影響を及ぼすことなくパートナーｏｒｇのうちの１つのみに特有のローカライズされたデータ（例えば、パートナー組織のうちの１つに対して実行するＣＲＭフローなど）を作成し、あるいはパートナー組織の特定のアプリケーションが共有データへの書き込みアクセスを有することを許可するなどの特定のデータ修正動作を実行することなどを可能にしてもよい。

【0113】

特定の実施形態によれば、ホスト組織は、共有台帳のコンピューティングインフラストラクチャの全体を実施、管理、維持、及び制御するが、創設者ｏｒｇが特定の権利をそれらに、又はパートナーｏｒｇに委譲し又は割り当てることを可能にし（例えば、創設者ｏｒｇは、創設者ｏｒｇに特権を割り当てることができる）、例えば、記憶されたデータへの書き込みアクセス、又は所与のネットワークｏｒｇに対するパートナーｏｒｇ及び創設者ｏｒｇのために記憶されたデータの構造を定義する記憶されたメタデータへの書き込み及び更新アクセスなどである。

【0114】

特定の実施形態によれば、創設者ｏｒｇの各々とパートナーｏｒｇは、ホスト組織の既存の顧客組織又はテナントであり、したがって、認可されたネットワーク参加者としての共有台帳への参加を通じて、ホスト組織からの管理支援を求める必要なく、それら自体のため及びそれらのユーザのためにそれら独自のアクセス制御を定義することを可能にされる。

【0115】

さらに、共有台帳が全ての情報を暗号法による方法で提供するため、あるタイプの監査証跡又は完全に透過的な監査ログが作成され、創設者ｏｒｇ及び可能性としてパートナーｏｒｇは誰が何のデータをいつ変更したかを確認することができ、ゆえに、法律、会計原則、又は契約上の義務により必要とされる、データレコードに変更が行われたことの誰、何、どこ、いつ、及びなぜについて、完全なトレースバックが可能となる。

【0116】

注目すべきことに、共有台帳では、ホストｏｒｇのデータに対して１つのみの単一のリポジトリがあり、データは、パートナーノードの各々に対して複製されない（ただし、特定の分散技術は、複数のノード間で分散される単一のデータリポジトリを提供する）。しかしながら、注目すべきことに、提供される同期メカニズムはなく、なぜならば、データは共有台帳を介して常に永続化され、データ共有の問題に対する多くの従前の解決策のように他の場所にコピーされず、参照されないためである。

【0117】

特定の実施形態によれば、パートナーの一部又は全部は、それら独自のビジネスルール及びビジネスロジックを作成することができ、これは次いで、共有台帳内のネットワークｏｒｇにより記憶されるデータの共通プールに書き込まれる。他の実施形態において、パートナーは、それら独自のパートナーｏｒｇ特有のルール及びビジネスロジックを書いてもよく、これは、共有台帳を介して永続化されるがネットワークｏｒｇのためのデータの共通プールには置かれず、したがって他のパートナーｏｒｇ又は創設者ｏｒｇに公開されない。これは、パートナーｏｒｇが、共有台帳内のネットワークｏｒｇにより記憶されたデータに対する修正に基づいて実行すべきＣＲＭデータフローを作成したとき、生じ得る。その場合、データの共通プールは、パートナーｏｒｇのＣＲＭデータフローにより参照されるが、ＣＲＭデータフロー自体は、その特定のパートナーｏｒｇに対してのみ有用である。しかしながら、注目すべきことに、全ての認可されたネットワーク参加者のための共通のビジネスルール及びロジックが、実現可能であるだけでなく、複数の区別可能なエンティティにより共有されたデータを有する任意の所与のネットワークｏｒｇ上で発生する可能性がかなり高い。

【0118】

またさらに、データが共有台帳内に永続化されるにもかかわらず、特定の実施形態に従い、データなし仮想テーブルがホスト組織内に「マテリアライズドビュー」として作成されることが提供され、これにおいて、創設者ｏｒｇ及びパートナーｏｒｇは、共有台帳の特定の実施形態がホスト組織内のＤＬＴベースのデータストア又はブロックチェーン（プライベート又はパブリック）などの非関係データストアに永続化され得るという事実にもかかわらず、マテリアライズドビューに対してそれが従来の関係データベーステーブルであるかのようにＳＱＬベースのクエリを発行し、処理することができ、一方、他の状況において、共有台帳は、それが暗号的に立証可能である限り、許容される方法で関係データベースに永続化されてもよい。

【0119】

そのような実施形態では、マテリアライズドビューは、認可されたネットワーク参加者（例えば、創設者及びパートナー）のうちのあらゆるものに提供されてよく、これは次いで、ＳＱＬトランザクションがそのような参加者の観点からマテリアライズドビューに対して処理されることを可能にし、ホスト組織は次いで、受信したＳＱＬ文から必要な共有台帳トランザクションコマンドへの必要な翻訳を提供し、これはブロックチェーン、ＤＬＴデータストア、又はさらには別の関係データベースストアである。

【0120】

特定の実施形態によれば、共有台帳は、マルチテナント認識及びマルチネットワーク認識であり、あらゆる認可されたネットワーク参加者は、一意的なネットワークＩＤを割り当てられ、さらにこれにおいて、共有台帳を介してネットワークｏｒｇ内に記憶された全てのデータは次いで、ネットワークＩＤにより区分され、かつ／あるいはネットワークＩＤを介して参照可能であり、したがって、１つ以上の指定された認可されたネットワーク参加者のみに特有のデータが参照されることを可能にする。

【0121】

別の実施形態によれば、ネットワークｏｒｇのためのデータの同じ共通プールは、宣言されたアプリがそのようなデータにアクセスするために利用されることに基づいて、異なるアクセスパーミッションを受けてもよい。例えば、Ａｍｅｘが創設者ｏｒｇであり、Ｃｈｅｖｒｏｎがパートナーｏｒｇである場合、ネットワークｏｒｇにより使用される在庫管理のための第１のアプリケーションは、Ｃｈｅｖｒｏｎの、データの共通プールへの読み取りアクセスのみを許可するが、同じパートナー組織のＣｈｅｖｒｏｎは、顧客リワードポイントアプリなどの異なるアプリを利用してデータの同じ共通プールにアクセスするとき、Ｃｈｅｖｒｏｎがネットワークｏｒｇに記憶されたデータの一部への書き込みアクセスを有することを許可し、ゆえに、特定のパートナーｏｒｇに基づくだけでなく、宣言されたアプリに基づいて、異なるパーミッションが可能となる。

【0122】

図１Ｄは、説明される実施形態による、ホスト組織サービスのブロックチェーンサービスインターフェース１９０との統合をより詳細に示す別の例示的なアーキテクチャ１０３を示す。

【0123】

特に、ここで統合ビルダ１５３とアクセス可能クラウドプラットフォーム１８６の双方が示されており、これらの各々はブロックチェーンサービスインターフェースのブロックチェーンメタデータ定義マネージャ１９６にインターフェースされる。統合ビルダ１５３は、様々な機能性を提供し、これは集合的に、ホスト組織の内部にホストされた共有台帳１５７へのエンティティ及びメタデータ定義を可能にし、あるいは、ホスト組織を通じてアクセス可能にされるブロックチェーンへのエンティティ及びメタデータ定義を、そのようなブロックチェーンがホスト組織の最終的な制御下にないパブリックブロックチェーンであるときでも可能にする。

【0124】

統合ビルダ１５３に具体的に示されているのはワンクリックブロックチェーンコネクタ１３１であり、これにより、ユーザは、コンポーネントをクリック及びドラッグして、それらのアプリケーションをホスト組織の内部の、ホスト組織を介してアクセス可能な利用可能ブロックチェーンとリンクすることができ、したがって、ユーザがリンクを確立するために必ずしもコードを書く必要なく、アプリケーションとブロックチェーンとの間のリンクが指定される。

【0125】

ネットワーク形成マネージャ１３２により、ユーザは、どのエンティティ（例えば、アプリケーション等）、パートナー、テナント、ユーザ、顧客組織等がそれらのアプリケーションを介してブロックチェーンに書き込まれた情報へのアクセスを有するかを定義することができる。

【0126】

エンティティ定義セットアップＧＵＩ１３３により、ユーザは、コードを書くことなく、指定されたメタデータが適用されるアプリケーション又はエンティティを定義することができる。例えば、これは、エンティティ定義セットアップＧＵＩ１３３で指定された新しいエンティティでもよく、あるいは、これは既存のアプリケーションでもよく、既存のアプリケーションは、メタデータ定義ＧＵＩ１３４を介して指定及び確立されたメタデータ定義と互換性のあるものにされる。

【0127】

最後、ブロックチェーン資産又はコインデプロイメント（deployment）１３５により、ユーザは、それらの指定したエンティティを、定義されたメタデータ、及びネットワーク形成マネージャ１３２を介して指定された任意の関連するアプリケーション、パートナー、顧客ｏｒｇ、テナント、ユーザ等と共に、接続性と適切な場合には関連するアクセス権とを有するアプリケーション又は誰かによる使用のために、接続されたブロックチェーン上へデプロイする（deploy）ことができる。ＧＵＩを介して定義されたエンティティとメタデータがブロックチェーン上にデプロイされると、それらは、問題のブロックチェーンへのアクセスと関連するアクセス権とを有する任意のアプリケーションやエンティティにより利用することができる。言い換えると、ブロックチェーン資産又はコインデプロイメント１３５のコンポーネントは、定義されたエンティティ及びメタデータを「パブリッシュ」又は「稼働開始」するのに役立つ。

【0128】

さらに示されているは、アクセス可能クラウドプラットフォーム１８６であり、これを介して、リンクされたブロックチェーンの外側に記憶されているがホスト組織を介してアクセス可能な情報が、定義されたエンティティを通じてリンクされ得る。

【0129】

したがって、ユーザが新しいアプリケーションを作成し、そのアプリケーションのためのメタデータを定義し、定義されたエンティティとメタデータを選択されたブロックチェーン上へデプロイする場合、さらに、その特定のアプリケーションについて問題の選択されたブロックチェーン内で永続化されていない、ホスト組織を介してアクセス可能な様々にアクセス可能クラウドプラットフォーム１７１上に記憶されたデータを取り出し、参照し、読み取り、及び書き込むことが許容可能である。

【0130】

例えば、ホスト組織を介してアクセス可能な共有台帳１５７又は別のブロックチェーン上のアプリケーションは、ホスト組織により提供される商業クラウド１７１からデータを取り出し、あるいはホスト組織により提供されるマーケティングクラウド１７２からデータを取り出すことができ、あるいは、ここで１７３Ａ、１７３Ｂ、及び１７３Ｃとして示される外部にリンクされたクラウドなどの、第三者及び外部リンククラウド１７３から情報を参照することができ、これは、現実には、例えば、Ａｍａｚｏｎ（登録商標） ＡＷＳクラウドサービスインターフェース、又はＭｉｃｒｏｓｏｆｔ（登録商標） Ａｚｕｒｅクラウドサービスインターフェース、又はＯｒａｃｌｅ（登録商標）クラウドサービスインターフェースなどに対応し得る。このような第三者クラウドがホスト組織サービス１０７を介して外部リンクされている限り、該第三者クラウドは、ホスト組織を介してアクセス可能な、又はホスト組織の内部にホストされたブロックチェーン内にそれらのデータを永続化するエンティティ及びアプリケーションにより参照され得る。

【0131】

さらに示されているのは、ネットワークｏｒｇ共有台帳１５７のより詳細なブレイクアウトであり、これは、前述したように、パブリックブロックチェーンへの完全なデプロイメントを回避したい顧客ｏｒｇに特定の分散台帳技術（ＤＬＴ）の機能態様を提供し、さらに、合意を必要とするのでなく信頼層１５４を介して中央集権的な信頼オーソリティを実施する（ホスト組織内の）内部ホスト型台帳機能を提供することができる。任意で、共有台帳１５７は、顧客ｏｒｇがテスト又は検証の目的で同意管理プロトコル１５７Ａを参照することを許可してもよく、これにおいて、顧客組織は、任意のトランザクションに対してそれら独自の合意を単に提供することができ、なぜならば、それらは、顧客組織がその独自のインスタンスを有する内部でホストされた共有台帳１５７内で行うことを許可されているためであり、ゆえに、最終的なオーソリティである。これは、中央集権型信頼インターフェース１５２への依存と機能が類似しているが、顧客組織が合意管理決定における制御を保有しながら、パブリックブロックチェーン上で観測されるであろうようなＤＬＴベースの合意管理を利用することを可能にする。後に、顧客ｏｒｇがそれらのアプリケーションをパブリックブロックチェーンに移行する場合、それらのマイグレーションパスは、合意管理コンポーネントとの統合がすでにあるため簡素化される。

【0132】

同意管理１５７Ａ、１５７Ｂにより、共有台帳１５７を利用する顧客ｏｒｇは、どのエンティティ、ユーザ、パートナー、顧客ｏｒｇなどが定義されたアプリケーションに関連づけられたトランザクションを参照、読み取り、書き込み、更新、又は削除する権限を有するかを定義し、これらの同じエンティティ、ユーザ、パートナー、顧客ｏｒｇなどがそれらのデータを参照するための権限を付与することを可能にすることができる。メタデータ定義デプロイメント１５７Ｃモジュールは、定義されたメタデータが資産として又はコインとして問題のブロックチェーンに書き込まれ、又は共有台帳１５７に書き込まれることを可能にし、その後、メタデータが定義された対象の情報と相互作用するエンティティ、アプリケーション、及びいかなるコードも、定義されたメタデータに準拠しなければならず、メタデータ準拠検証を実行するスマートコントラクト実行を介して準拠へ強制され得る。

【0133】

図１Ｅは、説明される実施形態による、ブロックチェーンサービスインターフェース１９０を利用する例示的なデータフローを示す別の例示的なアーキテクチャ１０４を示す。

【0134】

特に、ここに示すように、パートナーユーザが存在し、パートナーユーザは、ブロックチェーンサービスインターフェース１９０と、具体的には、アクセス可能なブロックチェーンを発見及び参照することができるブロックチェーンエクスプローラと相互作用する。次いで、パートナーユーザは、パーミッションが適切である場合、要素１７８に示されているようにＲＥＳＴ ＡＰＩを介してブロックチェーンからのデータを更新し、読み取ることができる。ブロックチェーンは、前述したメタデータ定義に準拠して、定義されたエンティティアプリケーションの情報を永続化する。

【0135】

ＲＥＳＴ ＡＰＩ１７８又は「表現状態転送（Representational State Transfer）」ＡＰＩは、Ｗｅｂサービスを作成及び利用するために使用される制約のセットを定義するソフトウェアアーキテクチャスタイルである。ＲＥＳＴアーキテクチャスタイルに従うＷｅｂサービスは、ＲＥＳＴｆｕｌ Ｗｅｂサービス（ＲＷＳ）と称され、パブリックインターネット上のコンピュータシステム間の相互運用性を提供する。ＲＥＳＴｆｕｌ Ｗｅｂサービスにより、要求システムは、一様な予め定義されたステートレス動作のセットを使用することによりＷｅｂリソースのテキスト表現にアクセスし、操作することができ、一方、ＳＯＡＰ Ｗｅｂサービスなどの他のサポートされたＷｅｂサービスは、それら独自の任意の動作セットを公開する。

【0136】

このようなＷｅｂサービスは、パブリックインターネットを介して、アプリケーションにより許可される任意の方法で識別、命名、アドレス指定、又は処理され得る任意のアプリケーションエンティティを含むことができ、いわゆるＲＥＳＴｆｕｌ Ｗｅｂサービスは、リソースのＵＲＩに対して要求が行われることを可能にし、リソースのＵＲＩは、次いで今度は、ＨＴＭＬ、ＸＭＬ、ＪＳＯＮ、又は何らかの他の選択されたフォーマットでフォーマットされた応答ペイロードを引き出す。ステートレスプロトコル及び標準動作を利用し、ＲＥＳＴｆｕｌシステムは、それが稼動中であってもシステムに全体として影響を及ぼすことなく管理及び更新することができるコンポーネントを再利用することにより、高速なパフォーマンス、信頼性、及び成長能力を目指し、したがって、図示のブロックチェーンと、パートナーユーザ、ホストｏｒｇユーザ、及び統合ビルダ１５３などの接続された要素との間のより完全な相互運用性を可能にする。

【0137】

ここに示すように、プラットフォームイベントに翻訳され、アクセス可能クラウドプラットフォーム１８６に送信されるブロックチェーンイベントがある。

【0138】

ホスト組織のユーザは、このようなアクセス可能クラウドプラットフォーム１８６と相互作用してデータを作成し、記録することができ、適切な場合には、データ及びイベントは、構成された仮想オブジェクトを通じてブロックチェーンへプッシュバックすることができ、該仮想オブジェクトは、ＲＥＳＴ ＡＰＩと通信してブロックチェーンに情報を書き込み、あるいはブロックチェーン内の情報を参照し、あるいはブロックチェーン内の管理されたイベントの状態情報を更新する。

【0139】

さらにここに示されているのは、ブロックチェーン管理者であり、これは、例えば、前述のＧＵＩを利用して統合ビルダ１５３でメタデータを定義し、ゆえに、ブロックチェーン管理者は、グローバルアプリケーションレジスタに記録されるネットワーク参加者を定義し、あるいは、ブロックチェーンサービスインターフェースにおいてＲＥＳＴ ＡＰＩにより次いで参照されるアプリケーションをデプロイすることができると共に、デプロイされたエンティティアプリケーションのためのメタデータ及びパーミッションを定義し、ゆえに、そのデプロイされたアプリケーションのための情報がブロックチェーンに書き込まれるとき、アプリケーションに関連づけられたそのような情報のための定義されたメタデータに準拠しなければならないことを保証することができる。このような準拠は、ブロックチェーンサービスインターフェース１９０におけるブロックチェーン内にここで示されるスマートコントラクトにより強制することができる。

【0140】

前述のように、ブロックチェーンは、内部ホスト型ブロックチェーン、例えば、ホスト組織により内部にホストされ完全に制御される共有台帳１５７でもよく、あるいはブロックチェーンは、ホスト組織を介してアクセス可能な任意のパブリックブロックチェーンでもよい。

【0141】

図２Ａは、説明される実施形態による、ブロックチェーン及びフォークしたブロックチェーン（forked blockchain）のさらなる詳細を有する別の例示的なアーキテクチャ２００を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0142】

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

【0143】

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

【0144】

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

【0145】

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

【0146】

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

【0147】

例えば、フォークしたブロックチェーンは、ホスト組織により有効にされた宣言型スマートアクションをサポートするために利用されてもよく、この場合、パブリック又はプライベートブロックチェーンのフォークしたブロックチェーンは、新しいブロックチェーンプロトコル証明書１６６を介してカスタマイズされて、管理者により定義されるスマートアクションの宣言的な確立とそれらの必要な情報捕捉規定との双方、並びに、そのような宣言されたスマートアクションを利用してトランザクションで捕捉されたデータをホスト組織により提供されるクラウドプラットフォームエンティティに戻すようにマッピングする能力をサポートする。

【0148】

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

【0149】

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

【0150】

例えば、ブロックチェーンメタデータ定義マネージャ１９６により提供されるサービスの実装のために、ホスト組織が以前に存在していたブロックチェーンを使用することについて考える。既存のブロックチェーンを利用することは有利であり得るが、次いで、具体的にブロックチェーンメタデータ定義マネージャ１９６により提供されるサービスのために特化したサイドチェーン又はフォークしたブロックチェーンを作成することは、依然として、プライマリ（合意）ブロックチェーンにより必要とされるブロックチェーンプロトコル証明書１６６に準拠したままである。他の例では、図１Ｃの共有台帳１５７などの修正された分散台帳技術が利用されてもよく、これは、完全にホスト組織の制御下のホストされた台帳であり、したがって、プライマリチェーンからサイドチェーン化することが必要ない可能性がある。さらに他の例には、ホスト組織がパブリックブロックチェーンのためのブロックチェーンプロトコルを提供及び定義することを含むことができ、その場合、ホスト組織は、ブロックチェーンメタデータ定義マネージャ１９６（例えば、図１Ａ参照）の拡張された能力がプロトコルに対しネイティブであるような方法で、利用されるブロックチェーンプロトコルを定義してもよく、ゆえにサイドチェーン化を必要とせず、あるいは反対に、ホスト組織は、パブリックに利用可能な機能性の限定されたサブセットを有するパブリックブロックチェーンを定義し、動作させ、次いで、パブリックブロックチェーンからサイドチェーン化することによりブロックチェーンメタデータ定義マネージャ１９６の能力を拡張して強化された機能性を提供してもよい。

【0151】

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

【0152】

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

【0153】

図２Ｂは、説明される実施形態による、サイドチェーンについてのさらなる詳細を有する別の例示的なアーキテクチャ２０１を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0154】

より詳細には、親ブロックチェーン１８８（例えば、プライマリチェーン）からサイドチェーン１８９への対称的な双方向ペグの移転（two-way pegged transfer）を行うためのメカニズムがここに示されており、該サイドチェーン１８９は、ホスト組織１１０によりサポート及び提供される異なるブロックチェーンプロトコルでもよく、あるいはサイドチェーンは、ホスト組織１１０のサイドチェーン交換マネージャ１９３がノードとして参加し、サイドチェーンとのアクセス及びトランザクション能力を可能にするための、パブリック又はプライベートの、外部のブロックチェーンでもよい。

【0155】

それにもかかわらず、説明される実施形態によれば、親ブロックチェーン１８８とサイドチェーン１８９との間のチェーン間（inter-chain）移転は、各それぞれのブロックチェーンのルール及び条件に準拠して許容される方法で実行され得る。注目すべきことに、ここで記載されるように、各ブロックチェーンの視点は、ここで示されるサイドチェーン１８９がそれ自体をプライマリ又は親ブロックチェーンとみなし、示される親ブロックチェーン１８８を子ブロックチェーン又はサイドチェーンとみなし得るように交換可能である。それにもかかわらず、各ブロックチェーンは独立して動作し、さらに、宣言されたスマートアクションを利用してトランザクションにより作成されたそれらの間で資産、コイン、トークン、値、又は他のペイロード情報を交換するための定義された交換メカニズムを有する。

【0156】

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

【0157】

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

【0158】

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

【0159】

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

【0160】

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

【0161】

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

【0162】

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

【0163】

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

【0164】

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

【0165】

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

【0166】

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

【0167】

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

【0168】

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

【0169】

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

【0170】

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

【0171】

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

【0172】

説明される実施形態によれば、ブロックバリデータ１９２は、検証を必要とするブロックに対して様々なタイプの合意管理を必要とし、利用し、あるいは適用してもよい。

【0173】

特定の資産又はトランザクションを含むブロックがブロックチェーンに追加されるべきとき、トランザクションタイプデータベースは、ブロックチェーンに追加されるべき特定の資産又はトランザクションのタイプを使用してクエリされ、特定の資産若しくはトランザクション、又は特定の資産若しくはトランザクションを含むブロックをブロックチェーンにコミットするために使用されるべき対応する合意プロトコルタイプを決定する。例えば、データベースにおいて、「ローン」のトランザクションタイプが「プルーフオブステーク」（ＰｏＳ）の合意プロトコルタイプに関連づけられてもよく、「文書」の資産タイプが「ビザンチンフォールトトレラント」（Byzantine Fault Tolerant、ＢＦＴ）の合意プロトコルタイプに関連づけられてもよく、「通貨」の資産又はトランザクションタイプが「プルーフオブワーク」（ＰｏＷ）の合意プロトコルタイプに関連づけられてもよく、データベース内の他の列挙されていないトランザクションタイプの場合に使用されるデフォルトトランザクションタイプが、デフォルト合意プロトコルタイプ、例えばＰｏＳに関連づけられてもよい。別のトランザクションタイプが、メタデータをその中に記憶させた資産タイプに対応してもよく、可能性として「メタデータ」とタイプ付けられ（typed）、一方、密接関連トランザクションタイプが、ブロックチェーン内にメタデータとして「関連エンティティ」を記憶し、それが通常のメタデータと同じタイプを共有する場合には「メタデータ」のトランザクションタイプを有し、あるいは別個である場合には「関連エンティティ」のトランザクションタイプを有する。またさらに、「記憶レコード」トランザクションタイプが利用されて、複数の区別可能なデータ要素をその中に埋め込ませたレコードを記憶してもよく、これは典型的には、アプリケーション開発者により指定されたメタデータにより定義される。

【0174】

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

【0175】

この選択された合意プロトコルタイプは、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求の検証に使用するために、コンソーシアムのノードに通信され得る。特定の実施形態によれば、コンソーシアム内のノードが、選択された合意プロトコルに従ってブロックチェーンにブロック又はその中のトランザクションを追加するための合意に達し、そのことをホストに通信したとき、ホスト組織１１０は、ブロックチェーンに新しいブロック又はその中のトランザクションを追加する要求の検証を受信する。

【0176】

任意の関連ファクタが、どのノードが合意プロトコルに参加するかを決定する際に使用されてもよく、例えば、選択された合意プロトコル自体、特定のノードのコンピューティングリソース、特定のノードがコンソーシアム又は選択された合意プロトコルにおいて有する利害関係（stake）、特定のノードが有する関連（ドメイン）知識、その知識がブロックチェーン又はコンソーシアムに関して内部（オンチェーン）であるか外部（オフチェーン）であるか、選択された合意プロトコルに参加する際の、速度の点か正確さの点か、又はこれらが欠如しているかどうかの、特定のノードの以前又は過去のパフォーマンス、ブロックチェーンに追加される新しいブロックのブロック番号、新しいブロック内のトランザクションの数、ブロックのサイズ、及びブロックチェーンに追加されるブロック内の資産又はトランザクションの信用又は非信用性（fiduciary or nonfiduciary nature）が含まれる。

【0177】

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

【0178】

別の実施形態によれば、ノードのコンソーシアムは、プライベートの、又は許可ありのブロックチェーンに参加し、この中で、各ノードは、例えば、ノードがブロックチェーンにおいて新しいブロックに追加し得るトランザクション又はトランザクションのタイプに関するドメイン（一般）知識に基づいて、その投票に与えられる重みを割り当てられる。特定のノードは、そのような許可ありのブロックチェーン内でゼロの重みを与えられてもよいが、他のノードは、それらの投票が、特定の実装に依存して、制限された数の他の高度に重み付けされたノードと組み合わせられたときに、ほぼ支配又は支配さえしているような、有意な重みを与えられてもよい。

【0179】

ノードがブロックチェーンの新しいブロックにトランザクションを追加する前、あるいはトランザクションを含む新しいブロックがブロックチェーンに追加され得る前に、コンソーシアム内の他のノードは、ブロックチェーンの新しいブロックにトランザクションを追加すること、及び／又はブロックチェーンに新しいブロックを追加することについて投票する。ノードの過半数がトランザクションに合意し、かつ／あるいは新しいブロックが有効であり、したがって、プライマリブロックチェーン上の有効ブロックとして受け入れられ得るとき、トランザクション及び／又は新しいブロックは、時にメインチェーン又は合意チェーンと呼ばれるそのプライマリブロックチェーンに追加され、受け入れられる。例えば、無効なブロックがブロックチェーンに追加され得る間、そのような無効なブロックは事実上、合意を獲得することができないサイドチェーンを作成し、したがって、メイン又はプライマリブロックチェーン内で追加有効ブロックとして決して受け入れられない。ノードは、プライベートブロックチェーンに参加しているノードのうち１つ以上の投票に基づいて「過半数（majority）」が取得され又は拒否され得るように、すなわち、ブロックチェーンに参加しているノードの全部より少数から過半数が取得され得るように重み付けされる。

【0180】

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

【0181】

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

【0182】

図３Ａは、説明される実施形態による例示的なアーキテクチャ３００を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0183】

ここに示すように、ホスト組織１１０が再び存在し、これは、プロセッサ及びメモリを（例えば、データベースシステム１３０の実行ハードウェア、ソフトウェア、及び論理１２０内に）有するホストされたコンピューティング環境１１１を含み、これらは、ブロックチェーン合意マネージャ１９１及びブロックチェーンメタデータ定義マネージャ１９６を含むブロックチェーンサービスインターフェース１９０を動作させるのに役立つ。さらに、ブロックチェーンに書き込まれ又はブロックチェーン上へトランザクション処理されるデータ、メタデータ、及びレコードのアドレス指定（addressing）能力を提供するインデックス３１６が示されている。

【0184】

さらに示されているのは、複数のテナントｏｒｇ３０５Ａ、３０５Ｂ、及び３０５Ｃ（時に顧客ｏｒｇとも呼ばれる）であり、これらの各々は、テナントクライアントデバイス３０６Ａ、３０６Ｂ、及び３０６Ｃを有し、これらを介して、テナント及びテナントのユーザは、ホスト組織１１０及びそのサービスと相互作用することができる。例えば、テナントｏｒｇは、ホスト組織にクエリ又はデータ３１１をサブミットしてブロックチェーンからのデータ取り出しを要求し、あるいはブロックチェーンにデータを記憶することができ、これらのいずれも、図示のインデックス３１６を利用することができる。

【0185】

特定の実施形態によれば、インデックス３１６は、マークルツリーインデックス又はマークル有向非巡回グラフ（ＤＡＧ）又は「マークルＤＡＧ」木インデックスを実現する。暗号法及びコンピュータ科学において、ハッシュツリー又はマークルツリーは、あらゆるリーフノードがデータブロックのハッシュでラベル付けされ、あらゆる非リーフノードがその子ノードのラベルの暗号ハッシュでラベル付けされるツリーである。そのようなツリーは、大規模データ構造の内容の効率的で安全な立証を可能にし、したがって、大規模データ構造からのデータ取り出しの有意な効率を提供する。このような実施形態によれば、マークルツリー又はマークルＤＡＧツリーを介してインデックス３１６を実装することは、親ノードがその子のハッシュであり、リーフノードが元のデータブロックのハッシュであるハッシュリストの二分木として、インデックスを再帰的に定義する。マークルＤＡＧツリーは、不均衡なツリーを可能にし、リーフ（終端）ノード内のデータを可能にする。

【0186】

マークルツリーを介してインデックス３１６を実現することは、インデックス内に記憶されたデータの完全性及び妥当性を証明する手段を提供し、証明が計算的に容易かつ高速であるため比較的小さいメモリ又はディスクスペースを必要とし、さらに、マークルツリーインデックスのプルーフ及び管理は、かなり少量又はわずかな量の情報だけをネットワークにわたり送信することを要し、ゆえに、ネットワークリソースの消費に関してより動作上効率的である。多くのブロックチェーンがブロック立証の目的でマークルツリーの使用に大きく依存しているが、マークルツリーを用いて実装されたインデックス３１６はブロックチェーンのブロック立証機能とは無関係であり、本明細書では、インデックス３１６情報を記憶するためのロバストで効率的な手段として使用される。

【0187】

図３Ｂは、説明される実施形態による別の例示的なアーキテクチャ３０１を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0188】

ホスト組織１１０が再び存在し、これは、プロセッサ及びメモリを（例えば、データベースシステム１３０の実行ハードウェア、ソフトウェア、及び論理１２０内に）有するホストされたコンピューティング環境１１１を含み、これらは、ブロックチェーン合意マネージャ１９１及びブロックチェーンメタデータ定義マネージャ１９６を含むブロックチェーンサービスインターフェース１９０を動作させるのに役立つ。さらに、ブロックチェーン３９９に書き込まれ又はブロックチェーン上へトランザクション処理されるデータ、メタデータ、及びレコードのアドレス指定能力を提供するインデックス３１６が示されている。

【0189】

図示のように、インデックス３１６はホスト組織のデータベースシステム１３０内に記憶されるが、代替的に、マークルツリーインデックス３１６はブロックチェーン自体に書き込まれ、記憶されてもよく、したがって、ホスト組織のクエリインターフェース１８０へのアクセスを欠くブロックチェーンの参加ノードは、それにもかかわらずマークルツリーインデックス３１６を（ブロックチェーンに記憶されているとき）取り出し、次いで、マークルツリーインデックス３１６から取り出されたアドレスを使用してブロックチェーン上のアドレス指定可能ブロックを直接参照し、所望のレコード、データ又はメタデータを取り出すことができ、ブロックチェーン全体をトラバースし又は必要なレコードのためにブロックチェーンを検索する必要はない。

【0190】

図示のように、ブロックチェーン３９９の最後の標準ブロック１４２内に示されるように別のインデックス３１６が示されている。１つのインデックス３１６のみが必要とされるが、インデックス３１６は許容される方法でいずれかの場所に記憶されてよい。

【0191】

下部でより詳細に示されるマークルツリーインデックス３１６は、ＡＢＣＤＥのハッシュを有するレベル０のマークルルートを示しており、その後に、２つのハッシュノードを有するハッシュ層が続き、ハッシュＡＢＣを有する第１のハッシュノード及びハッシュＤＥを有する第２のハッシュノードであり、その後に、ハッシュＡ、Ｂ、Ｃ、Ｄ、及びＥにより識別されるデータリーフ内のデータブロックが続き、各々がブロックチェーン上のアドレス指定可能ブロックのアドレス指定情報を含む。

【0192】

マークルツリーインデックス３１６の使用と関連してブロックチェーンメタデータ定義マネージャ１９６を介してブロックチェーン３９９上にデータ及びメタデータを記憶することは、データレコードを取り出すためにブロックチェーンの複数のブロック１４１及び１４２を検索することが必要ないため、既知のデータ記憶スキームより一層効率的である。むしろ、インデックス３１６は、所望のブロックのアドレスを取り出すために最初検索され、これはかなり高速で効率的であり、次いで、インデックス３１６から取り出されたアドレスを用いて、ブロックチェーン３９９上のアドレス指定可能ブロックからレコードが直接取り出される。

【0193】

データが従来の手法を用いてブロックチェーン内に記憶されると、ブロックチェーン内のデータ量は記憶データの総ボリュームの点で激増し、スケーラビリティの問題を生じ、結果として問題のある非効率性をもたらす。ブロックチェーンに記憶されるデータの総ボリュームは、時間と共に持続不可能に激増又は増大する傾向があり、なぜならば、記憶されたレコードが更新又は修正されるたび、修正されたレコードの全体をブロックチェーンに再書き込みすることが必要だからであり、これは次いで、最も最近の、最新のレコードになるが、全ての前のバージョン及びコピーがブロックチェーン内に保有されており、ゆえに、相当な重複したデータエントリが記憶される結果をもたらす。このようなアプローチの利点は、レコード全体がブロックチェーン上の単一のブロックから取り出され得ることであり、同じレコードのためにブロックチェーン上の前のブロックを戻って参照する必要がない。しかし、このような記憶スキームは、記憶の観点からはかなり非効率的である。

【0194】

あるいは、従来のアプローチによれば、ブロックチェーン内に記憶されたレコードに対する修正のみが記憶されてもよく、ゆえに、結果として、修正されたデータはブロックチェーン上の新しいブロックに書き込まれ、修正不可能なデータはブロックチェーンの先行ブロックから取り出し可能である。このアプローチは、ブロックチェーンにより記憶されるデータの総量を減らす。残念ながら、修正されたレコードのいかなるデータ取り出しもブロックチェーン上の複数のブロックからの検査及び取り出しを必要とし、ゆえに、データの冗長性及び持続不可能な増大の問題を軽減するが、その問題を望ましくないデータ取り出しの非効率の問題と交換している。

【0195】

このようにして、ブロックチェーン３９９内に記憶されるレコード及び情報のデータ管理が改善される。さらに、メタデータがブロックチェーン内にさらに記憶されて、記憶されたレコードに関するさらなる情報及びコンテキストを提供してもよく、データレコードの各々とそのようなデータレコードを記述するメタデータは、インデックス３１６の使用を通じてより容易に取り出し可能である。このようなメタデータにより、ビジネス又は他のエンティティは、ブロックチェーンに書き込まれたレコードのそのようなコンテキスト及びメタデータを失う従来のアプローチを用いるより一層容易に、ブロックチェーンから取り出されたデータレコードを使用可能なフォーマットに戻すように変換することができる。

【0196】

図３Ｃは、説明される実施形態による別の例示的なアーキテクチャ３０２を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0197】

ホスト組織１１０が再び存在し、これは、プロセッサ及びメモリを（例えば、データベースシステム１３０の実行ハードウェア、ソフトウェア、及び論理１２０内に）有するホストされたコンピューティング環境１１１を含み、これらは、ブロックチェーン合意マネージャ１９１及びブロックチェーンメタデータ定義マネージャ１９６を含むブロックチェーンサービスインターフェース１９０を動作させるのに役立ち、ブロックチェーンメタデータ定義マネージャ１９６は、インデックス３１６を利用して、所望のレコードが記憶されたブロックチェーン３９９のアドレス指定可能ブロックを識別する。さらに、ブロックチェーン３９９の第２のブロックから最後のブロックに例示的な記憶されたレコード３９０が示されている。

【0198】

ここで、記憶レコード３９０は、学生ファーストネーム３１５Ａ、学生ラストネーム３１５Ｂ、学生電話番号３１５Ｃ、及び学生ＩＤ ３１５Ｄを含む学生情報を記憶する。

【0199】

ひとたび、例えば、記憶レコード３９０が具現化されている資産をブロックチェーンに追加することにより、記憶レコード３９０がブロックチェーン上へトランザクション処理されると、学生データはブロックチェーンにより永続的に記憶され、ブロックチェーン３９９へのアクセスを有する参加ノードにとってアクセス可能であるが、このようなデータが取り出されるとき、記憶レコードそれ自体は、そのようなデータを使用する方法、そのようなデータの特定のフォーマット、又はそのようなデータを検証する方法を記述しない。したがって、ブロックチェーン内にメタデータを記憶することがさらに許容可能であり、これは次いで、そのようなデータのためのフォーマット、検証手段、及び使用法を定義するために使用され得るが、メタデータの記憶は、ブロックチェーンからのデータを検索し、取り出す問題を悪化させるだけであり、なぜならば、今や、記憶レコード３９０と、さらにそのレコードに関連づけられた記憶メタデータ３９１が存在するためである。したがって、ブロックチェーンに記憶されたデータのより効率的な記憶、取り出し、及び検証を提供するインデックス３１６の使用と関連してブロックチェーンメタデータ定義マネージャ１９６により実施されるインデキシングスキームにより、組織方法論が提供される。

【0200】

一実施形態によれば、したがって、記憶レコード３９０は、ブロックチェーン内の記憶のためにより効率的なフォーマットにコンバートされる。学生情報が記憶されている記憶レコード３９０について考える。最初、記憶レコード３９０は、学生ファーストネーム３１５Ａ及び学生ラストネーム３１５Ｂのみを含んでもよく、次いで、記憶される。その後、学生レコードは、学生電話番号３１５Ｃを含むように更新され、したがって、記憶レコード３９０はその全体を更新され、ブロックチェーンに再書き込みされ、ゆえに、更新されるにもかかわらず記憶レコード３９０の第２のコピーが作り出されるか、あるいは代替的に、新しい部分のみ、学生電話番号３１５Ｃが、先行レコードへ戻る参照と共にブロックチェーンに書き込まれ、その場合、総記憶ボリュームは低減されるが、レコード全体の取り出しは、記憶レコード３９０全体を再構成するためにブロックチェーン上の複数のブロックを検索し、発見することを必要とする。さらに悪いことに、学生ＩＤ ３１５Ｄが後に割り当てられた場合、記憶レコード３９０は再度更新される必要があり、ゆえに、さらに別の記憶レコード３９０全体がブロックチェーンに書き込まれ、その結果、今やブロックチェーン上に３つの異なるバージョン及びコピーがもたらされ、あるいは前述のように、記憶レコードの新しい部分のみをブロックチェーン３９９に書き込み、その場合、記憶レコード３９０はブロックチェーンの少なくとも３つのブロックにわたってフラグメント化される。

【0201】

このフラグメント化は問題があり、なぜならば、学生情報を探している場合、第１のブロックが学生のファーストネーム及びラストネームを含み、第２のブロックが更新に起因して学生のラストネームの変更を含み、第３のブロックが学生電話番号のみを含むなどの結果をもたらし得るためである。結果的に、データを必要とするどんなアプリケーションに対してでも、それが使用され得る前に記憶レコード３９０全体を再構成するために、ブロックチェーンのブロックを移動して全てのフラグメント化されたピースをピックアップすることが必要である。

【0202】

図３Ｄは、説明される実施形態による別の例示的なアーキテクチャ３０３を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0203】

一実施形態によれば、ブロックチェーンメタデータ定義マネージャ１９６は、ブロックチェーンに対して資産をトランザクション処理すること、又はブロックチェーンとの新しいトランザクションを介してブロックチェーンに資産を追加することにより、ブロックチェーン上へデータ又はメタデータを書き込む。特定の実施形態によれば、トランザクションは、特定のトランザクションタイプを有し、例えば、ブロックチェーン記憶トランザクションタイプとして定義され、これは、スマートコントラクトの実行をトリガしてトランザクションの検証を実行し、具体的には、ブロックチェーンに追加され又はブロックチェーン上へトランザクション処理される資産内のデータ又はメタデータの検証を実行する。

【0204】

例えば、このようなスマートコントラクト３６３は、ホスト組織のブロックチェーンサービスインターフェース１９０を介して実行することができ、これは、検証を実行し、次いで、ブロックチェーン上に記憶されている資産内のデータ又はメタデータの成功裏の検証に従ってブロックチェーン上へ新しい資産をトランザクション処理する。ここで要素３６３に示すように、スマートコントラクトはブロックチェーンのトランザクションを実行し、検証する。その後、検証されたトランザクション３６４が次いでブロックチェーン３９９に追加され、あるいはブロックチェーン３９９上へトランザクション処理される。

【0205】

図４Ａは、説明される実施形態による、スマートフローコントラクトエンジン４０５を利用して作成されるブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャ４００を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ（図示せず）は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0206】

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

【0207】

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

【0208】

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

【0209】

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

【0210】

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

【0211】

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

【0212】

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

【0213】

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

【0214】

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

【0215】

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

【0216】

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

【0217】

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

【0218】

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

【0219】

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

【0220】

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

【0221】

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

【0222】

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

【0223】

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

【0224】

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

【0225】

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

【0226】

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

【0227】

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

【0228】

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

【0229】

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

【0230】

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

【0231】

図４Ｂは、説明される実施形態による、Ａｐｅｘ翻訳エンジン（Apex translation engine）４５５を利用して作成されたブロックチェーン実装型スマートコントラクトのさらなる詳細を有する別の例示的なアーキテクチャ４０１を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ（図示せず）は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0232】

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

【0233】

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

【0234】

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

【0235】

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

【0236】

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

【0237】

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

【0238】

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

【0239】

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

【0240】

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

【0241】

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

【0242】

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

【0243】

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

【0244】

図４Ｃは、説明される実施形態による、ブロックチェーンに永続的に記憶されたレコードのためにＡｐｅｘ翻訳エンジン４５５を利用するＳＱＬフィルタリング及びクエリトランスレータのさらなる詳細を有する別の例示的なアーキテクチャ４０２を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0245】

ここで見られるように、今、ＳＱＬフィルタ又はＳＱＬクエリを受信するＡｐｅｘ翻訳エンジン４５５が存在し、これは、ホスト組織１１０クエリインターフェース１８０に対してサブミットされるが、ブロックチェーン４４０により永続化されるレコードについて、クエリインターフェース１８０は、ワークの一部をブロックチェーンサービスインターフェース１９０に委譲することが必要である。

【0246】

問題として、ブロックチェーンは関係データベースシステムではないため、ブロックチェーンは、ＳＱＬベースのクエリ又はフィルタを受信、処理、又はトランザクション処理する能力を全く有さない。それにもかかわらず、ホスト組織１１０は、ホスト組織のユーザに技術的複雑性を負担させないように、ユーザが簡素化されたツールを用いながらもより大きい技術的能力（例えば、ブロックチェーン４４０の使用を許可すること）を提供されることを前提として、少なくとも部分的に、オンデマンド及びクラウドベースのサービスをそのユーザに提供する。

【0247】

したがって、ホスト組織は、ここに示されるようにＡｐｅｘ翻訳エンジン４５５を実施し、これは、ａｐｅｘコードインターフェース４５４と関連して動作して、ホスト組織１１０のクエリインターフェース１８０からＳＱＬフィルタ／クエリ４５７を受信する。

【0248】

ＳＱＬフィルタ／クエリ４５７は、Ａｐｅｘ翻訳エンジン４５５に通信され、これは、そのＡｐｅｘ定義のＳＱＬクエリ及びフィルタターム翻訳ブロックの一部として、入ってくるＳＱＬフィルタ／クエリ４５７を読み取り、その構成要素部分へパースし、分析することができるＳＱＬタームマッパ（mapper）４５８を含むように示されており、それにより、ブロックチェーンの資産内の様々なペイロードデータを実際に記憶する適切な資産識別子４２４を参照することができ、それにより、基礎をなすデータレコードをブロックチェーン４４０から取り出すことができる。

【0249】

次いで、パースされたターム及び適切な資産識別子４２４は、次いで、Ａｐｅｘブロックトランスレータ４８０を通じて送信され、次いで、要素４５９におけるペイロードデータ取り出しのためのネイティブブロックチェーンプロトコルにコンバートされる。

【0250】

次いで、要素４５９におけるペイロードデータ取り出しのためのネイティブブロックチェーンプロトコルは、ブロックチェーン４４０上へブロックチェーン読み取り要求４６１をトランザクション処理することにより、ブロックチェーン４４０に対して実行され得、結果として、要素４６２におけるブロックチェーンから取り出されたペイロードデータがブロックチェーン４４０から返される。

【0251】

ブロックチェーンから取り出されたペイロードデータ４６２により表されるこのレコードセットは、ＳＱＬフィルタ／クエリ４５７に対して適切なフォーマットではないが、それは、受信したＳＱＬフィルタ／クエリ４５７を最終的に履行するために必要なデータを含む。言い換えると、ブロックチェーンの資産から取り出されたペイロードデータは、クエリされるレコードを表すデータを含むが、完全に互換性のないフォーマットにおけるものであり、ブロックチェーンのフォーマットに対応し、しばしばデータはハッシュ又はシリアライズされており、ゆえに、記憶されたデータの構造を記述するブロックチェーンから取り出されたメタデータ４８９に基づく読取可能なフォーマットへの逆のコンバージョンを必要とする。

【0252】

ブロックチェーンから取り出されたペイロードデータ４６２は、次に、ａｐｅｘ翻訳エンジン４５５に戻され、これは、ブロックチェーンからのデータを読取可能なフォーマットにコンバートする。次に、翻訳されたレコードは、戻されたレコードセットの一時ビュー４６３においてデータベースシステム１３０に通信され、その時点で、次いで、ＳＱＬクエリ／フィルタ（例えば、要素４５７）は、元のＳＱＬフィルタ／クエリタームを利用し、又は翻訳及び最適化されたＳＱＬフィルタ／クエリタームを利用してデータベースシステム１３０において一時ビュー４６３に適用され、入ってくるＳＱＬフィルタ／クエリに応答した元々要求されたレコードセットを返す。

【0253】

このような方法で、ユーザがブロックチェーン４４０上に記憶されたデータに対してＳＱＬクエリ／フィルタを発行することがゆえに可能であり、ユーザは、ブロックチェーンと相互作用する方法又はブロックチェーンとの間でトランザクション処理する方法の理解を何ら必要とせず、実際、そのようなデータがブロックチェーン４４０上に記憶されているという知識をユーザが有することさえ必要としない。

【0254】

一実施形態によれば、ブロックチェーンに記憶されたデータは、ＳＱＬフィルタ／クエリ４５７要求を使用してクエリ又はフィルタリングされ、より詳細には、要求されたフィルタリングは、ブロックチェーン内に記憶されたデータ要素間の関係に基づいて行われる。

【0255】

しかしながら、注目すべきことに、ブロックチェーンは関係データベースシステムではないため、ブロックチェーン上の資産内に記憶されたペイロードデータのデータ要素間の「関係」のための構造は存在しない。

【0256】

それにもかかわらず、そのようなＳＱＬフィルタ／クエリ４５７要求は、例えば宣言されたアプリケーションによりブロックチェーンに書き込まれるデータの構造及び関係を記述するためにブロックチェーンに対してメタデータをトランザクション処理することにより、ブロックチェーンに対して宣言され、定義され、記憶される定義されたメタデータ４８９に基づいて、ホスト組織１１０を通じて可能にされる。そのようなメタデータは、以下により詳細に説明されるように関連する実施形態に従ってアプリケーションの作成及び宣言を通じて定義されてもよい。

【0257】

このような方法で、互いに関連づけられるエンティティを、エンティティが関係データベースシステムにおいて互いに関連づけられる方法と同様に、そのようなレコードがブロックチェーン４４０などのＤＬＴプラットフォームに書き込まれるという区別と共に、定義することが可能である。注目すべきことに、ブロックチェーン内のレコードは本質的には、関係データベースのように互いに関連づけられておらず、むしろ、データとさらにそのようなレコードを定義するメタデータとの双方を取り出すことが必要である。

【0258】

したがって、そのような実施形態によれば、Ａｐｅｘ翻訳エンジン４５５は、ブロックチェーンのために定義されたエンティティ間の関係を翻訳し、これにより、次いで今度は、ホスト組織のデータベースシステム１３０及び／又はクエリインターフェース１８０が、データに対する必要なＪＯＩＮ操作を実行して統合テーブル又はＪＯＩＮテーブルビューを形成することができ、これに対して、ＳＱＬフィルタ／クエリ４５７要求が次いで適用され得る。

【0259】

特定の実施形態によれば、ブロックチェーン上に書き込まれた任意のトランザクションは、後にＡｐｅｘ翻訳エンジン４５５によりＲＤＢＭＳフォーマットに相互関連づけされ得るオフチェーン記憶データベース表現としてデータを永続化するリーフノードを結果としてもたらす。

【0260】

そのような実施形態によれば、関係テーブルは、ブロックチェーンから取り出されたペイロードデータに基づいて、及び、ブロックチェーンへトランザクション処理され、取り出されたペイロードデータと同時に取り出されたメタデータ４８９に基づいて、Ａｐｅｘ翻訳エンジンにより後に作成される。

【0261】

説明される実施形態によれば、このようなデータの構造を定義するメタデータへの変更があるときはいつでも、ブロックチェーン上へ新しいメタデータ定義をトランザクション処理することによりメタデータの変更が更新され、その結果、メタデータへのいかなるこのような変更も、取り出されたデータ上で構築される任意のＲＤＢＭＳフォーマットのテーブルに自動的に翻訳され、なぜならば、Ａｐｅｘ翻訳エンジンは、更新されたメタデータ定義を取り出し、参照するためである。

【0262】

そのような実施形態によれば、ひとたびＲＤＢＭＳフォーマットのテーブルがＡｐｅｘ翻訳エンジンにより構築されると、ＳＱＬフィルタ／クエリ４５７要求は、次いで、ホスト組織の１１０のデータベースシステム１３０において構築されたＲＤＢＭＳテーブルに対してクエリされる。別の実施形態によれば、ＲＤＢＭＳテーブルは、最初、ブロックチェーンからメタデータ４８９を取り出すことにより、ペイロードデータを取り出すことなく構築される。その後、ＳＱＬフィルタ／クエリ４５７要求は、ＲＤＢＭＳフォーマットのテーブルに適用され、クエリに基づいて、Ａｐｅｘ翻訳エンジンは、ブロックチェーン４４０上でペイロードデータが記憶されている適切な資産識別子４２４を識別する。次いで、ブロックチェーンからペイロードデータを取り出し、取り出されたデータを、構造化されているが空である前にフォーマットされたＲＤＢＭＳテーブルに投入する前に、ブロックチェーン上のデータの対応するブロック番号を識別する。次いで、取り出されたペイロードデータは、空のＲＤＢＭＳテーブルに投入されて、ＳＱＬフィルタ／クエリ４５７要求が要求の履行において今や投入されたＲＤＢＭＳテーブルに対して適用されるのを容易にする。

【0263】

このような方法で、次いで、データの正式なソースが最終的に関係データベースシステムではなくブロックチェーン４４０上へトランザクション処理された資産に書き込まれたペイロードデータであるという事実にもかかわらず、ＳＱＬクエリを利用してブロックチェーン内のデータに対してクエリすることが可能であり、関係に基づいてＳＱＬを使用してフィルタリングすることが可能である。

【0264】

いかなる変更に対してもブロックチェーンに永続化されるブロック番号及びブロックＩＤを有する別個のテーブルビューを作成することにより、別個のビューを利用して一層高速なルックアップを実行すると同時に、ブロックチェーンにおけるデータをチェックするためにブロックＩＤを利用して参照データが現在のものであることを検証することが可能であり、問題のデータについてブロックチェーンの時間集中的な検索を実行する必要はなく、なぜならば、ブロックＩＤが直接、単一のブロックへの参照を可能にするためである。

【0265】

明確にするために、このような実施形態によれば、２つのクエリがある。ＲＤＢＭＳフォーマットのテーブルを通じたデータベースシステム内の一時ビューに対する最初のＳＱＬベースのクエリが実行され、次いでブロックＩＤ及びブロック番号の高速ルックアップが実行され、次いで、Ａｐｅｘ翻訳エンジンはブロックチェーンに戻って、Ａｐｅｘ翻訳エンジンにより資産識別子４２４として維持されるブロック番号及びブロックＩＤのテーブルルックアップに基づいて、クエリされたデータが現在のものであり正確であることを検証する。

【0266】

さらに、データはＲＤＢＭＳフォーマットで表現されるため、ブロックチェーン内に記憶されたデータに対してＪＯＩＮを実行することがさらに許容される。そのようなＪＯＩＮは、さもなければ不可能であろうブロックチェーンに記憶されたデータを利用した分析が実行されることをそれらが可能にするため、重要である。

【0267】

このような実施形態によれば、データベースシステム１３０内のＲＤＢＭＳフォーマットのテーブル表現は不変テーブルではないが、エンティティがＲＤＢＭＳフォーマットのテーブルに対する変更を行う権限を有さないように制限され、例外は、以下で論じられるＡｐｅｘ翻訳エンジンのトランザクション再生メカニズムである。

【0268】

したがって、ブロックチェーン監視／イベントリスナコンポーネントのみが、このテーブルを更新することを可能にされ、ブロックチェーンの正式なソースからＲＤＢＭＳフォーマットのテーブル及びホスト組織のデータベースシステム１３０内の一時ビューへの必要な同期を実行し、これは、メタデータへの変更又はブロックチェーンに記憶された永続化されたデータへの変更のいずれかがイベントリスナにより観測されるときいつでもである。

【0269】

さらなる実施形態によれば、さらに、ブロックチェーンがアクセス不可能なときＳＱＬフィルタ／クエリ４５７要求を処理するトランザクション再生メカニズムと、ブロックチェーンが恒久的にアクセス不可能になった場合、又はブロックチェーン上のデータが破損した可能性がかなり低い場合におけるブロックチェーンデータリストアのための復元メカニズムがある。

【0270】

そのような実施形態によれば、再生メカニズムは、データの一時的なホスト組織のビューが現在のものであることを検証するために、ブロックチェーン内に記憶されたデータを検証することなく、ホスト組織１１０によりＳＱＬフィルタ／クエリ４５７要求が処理されることを可能にする。

【0271】

ブロックチェーン４４０がアクセス不可能である間、ＳＱＬフィルタ／クエリ４５７要求が受信される可能性がある。したがって、Ａｐｅｘ翻訳エンジンはホスト組織のデータベースシステム１３０と関連して、一時ビューのデータを追加、更新、又は削除する全てのトランザクションを記録する。このような変更はブロックチェーン上へトランザクション処理されるが、これらの変更は一連の更新として記録され、ホスト組織で維持される。これらの変更は、非正式ソースを表すが、それにもかかわらず参照されてもよい。

【0272】

したがって、ブロックチェーン４４０がアクセス不可能である場合、記録されたデータへの変更はデータベースシステム１３０によりリプレイされて、リプレイされた追加、削除、及び更新トランザクションを利用してホスト組織におけるデータの一時ビューを更新することができ、ゆえに、一時ビューを、ブロックチェーンに記憶された同じデータの正式なソースと同期させる。ひとたびリプレイが完了すると、ＳＱＬフィルタ／クエリ４５７要求はデータの一時ビューに対して処理することができ、データが現在のものであることを検証及び立証するためにブロックチェーンに記憶されたデータの資産識別子４２４の位置を特定するＡｐｅｘ翻訳エンジンの中間動作を必要としない。

【0273】

したがって、ブロックチェーンが一時的にアクセスできないときでも、ＳＱＬベースの言語のクエリ及びフィルタを利用して、ブロックチェーンがクエリされ、ＳＱＬフィルタ／クエリ４５７要求が履行され得る。

【0274】

このようなトランザクション再生メカニズムは、ＲＤＢＭＳフォーマットのテーブル及び一時ビューがブロックチェーンを参照する必要なく自己修復し、ブロックチェーンレベルで完全にリストアされた状態に戻ることを可能にする。例えば、ホスト組織のシステムは、ブロックチェーンノードがダウンしたか又はアクセス不可能であることを認識し、ゆえに次いで、観測された全てのトランザクションをリプレイし、メタデータを再適用して適切な状態を決定し、これは、ブロックチェーン上の全ての参加ノードが自己更新する方法と同様であり、例外は、参照がブロックチェーンのノードに対して行われず、おそらくブロックチェーンから直接状態データと現在の情報を取り出すより一層遅いことである。速度のペナルティにもかかわらず、利点は、ブロックチェーンノードがダウンしているにもかかわらず、有効なデータがそれにもかかわらず取り出され得ることである。

【0275】

別の実施形態によれば、ブロックチェーン４４０が恒久的にアクセス不可能になった場合のブロックチェーンに記憶されたデータのための復元及びリストアメカニズムがある。このシナリオはかなり可能性が低いが、必要に応じてデータリストアを実行する機会を提示する。さらに、ホスト組織又はユーザがそれらのデータを再配置することを望む場合に、データが永続化されるブロックチェーン４４０から正式なソースとして新しいブロックチェーンにデータマイグレーションを実行する能力が許容される。

【0276】

そのような実施形態は、上述した全ての記録されたトランザクションの再生と同様に動作し、追加される追加は、ひとたび再生が完了すると、ホスト組織のデータベースシステム１３０における全てのメタデータ４８９及び一時ビューからのレコードがリストアされたブロックチェーン４４０に書き込まれ、あるいは新しいブロックチェーンリポジトリに書き込まれ、ゆえに、レコードがペイロードデータとして永続化されるブロックチェーン上に新しい資産を作成し、そのようなデータについてブロックＩＤ及び資産識別子４２４を更新して、破局的な故障の後、又は意図的なデータマイグレーションに従って、ブロックチェーン４４０上の全てのデータを完全に復元又はリストアすることである。

【0277】

特定の実施形態によれば、メタデータへの変更はホスト組織のイベントリスナにより認識され、このイベントリスナは、このようなメタデータが記憶される資産のいずれかに影響を及ぼすブロックチェーンでの変更を探す。したがって、ひとたび、トランザクション処理された資産についての合意に従ってメタデータがブロックチェーンにコミットされると、ブロックチェーンサービスインターフェースはメタデータの更新されたバージョンを取り出し、それにより、ホスト組織１１０内の一時ビューのためのＲＤＢＭＳフォーマットのテーブルは、メタデータの新しいバージョンに基づいて再構築され得る。例えば、メタデータはＳＱＬデータ定義言語に翻訳され、次いで、メタデータに基づいて、空であるＲＤＢＭＳデータテーブル、又は投入されたテーブルのＲＤＢＭＳデータ表現が、翻訳されたＳＱＬデータ定義言語を利用する新しいメタデータに従って再構築され、あるいは再構成される。

【0278】

説明される実施形態によれば、ブロックチェーンイベントが発生するときはいつでも、暗号データが返され、データは次いでメタデータフォーマットで永続化される。暗号データは、例えば、他のシステムが参照及び消費するためにＳＱＬデータ定義又はＲＥＳＴ標準又は他の標準化された復号フォーマットを使用して、他のシステムにより理解されるフォーマットに翻訳される。次いで、このデータは、今やアクセス不可能であるブロックチェーンに記憶されたデータに依存する他のシステムにプッシュアウトされ、それにより、これらのシステムは、データの一時ビューと任意の他のデータベースを同期させ、あるいはそのようなデータに影響を及ぼすブロックチェーンからのイベントについての任意のエンティティリストを同期させることができる。例えば、分析エンジンは、ブロックチェーンへの変更についてイベントリスナからのデータフィードを常にリッスンすることができ、それにより、それは分析エンジンにフィードすることができる。同様に、ＡＩエンジンがフィードをリッスンしてもよく、それにより、それがＡＩ等に訓練データを入力してもよい。

【0279】

図５Ａは、説明される実施形態による別の例示的なアーキテクチャ５０１を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0280】

従来の解決策は、ブロックチェーン上へトランザクション処理される資産内に自由形式のテキストを記憶することを可能にし、例えば、そのようなデータを資産のペイロード部分内に記憶するが、このようなデータは検証されていないため、破損した又は不正確なデータがブロックチェーンに書き込まれ、後に、そのようなデータが有効であるという仮定で取り出されるリスクがある。

【0281】

したがって、ブロックチェーン上へトランザクション処理されるエンティティ又は資産のトランザクション検証を実行するためにスマートコントラクトを実行することにより、そのようなデータがブロックチェーン３９９に書き込まれる前に様々なマスク、データ構造、データタイプ、データフォーマット、又は他の要件を強制することが可能である。

【0282】

そのような実施形態によれば、ブロックチェーンメタデータ定義マネージャ１９６はスマートコントラクト検証５６３を実行し、ブロックチェーンに書き込まれるデータが実行されたスマートコントラクトにより定められた要件に準拠しない場合、トランザクションは拒絶され（５６５）、例えば、トランザクションをクエリインターフェースに送り返してトランザクションの発信元に知らせる。そうでない場合、トランザクションがスマートコントラクト実行に従って準拠していると仮定し、トランザクションは検証され（５６４）、ブロックチェーンに書き込まれる。

【0283】

一実施形態によれば、スマートコントラクトは、データマスクを適用して、ブロックチェーンに書き込まれるデータ又はメタデータの準拠を検証する。他の実施形態において、スマートコントラクトは、検証手順の一部としてデータに適用されるルールを強制する。

【0284】

一実施形態によれば、スマートコントラクトは、スマートコントラクトの使用を許可する任意のブロックチェーンで実行される予め定義されたスマートコントラクトシステムの一部として実行され、スマートコントラクトは、必要なデータ検証を実行する。

【0285】

一実施形態によれば、ブロックチェーン３９９に書き込まれるデータ又はメタデータは、記憶効率を改善するためにＪＳＯＮフォーマットにコンバートされる。ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）は、属性‐値ペア及び配列データ型又は他のシリアライズ可能な値を含むデータオブジェクトを送信するために、人間が読めるテキストを使用するオープン標準のファイルフォーマットを提供する。これは、いくつかのＡＪＡＸスタイルのシステムにおけるＸＭＬの代替としてのものを含め、非同期のブラウザ‐サーバ通信に使用されるかなり一般的なデータフォーマットである。さらに、ＪＳＯＮが言語非依存のデータフォーマットであるため、それは、そのようなプラットフォームに利用される基礎をなすプログラミング言語にかかわらず、様々な異なるスマートコントラクト実行プラットフォーム及びブロックチェーンプラットフォーム上のスマートコントラクトにより検証され得る。

【0286】

したがって、ここに示されるように、ブロックチェーンに書き込まれるデータ又はメタデータは、ＪＳＯＮフォーマット５６６に（例えば、ホスト組織１１０のデータベースシステム１３０内で）コンバートされ得、次いで、検証及びコンバートされたＪＳＯＮデータは、ブロックチェーン上でトランザクション処理される。

【0287】

図５Ｂは、説明される実施形態による、記憶されるデータの動的メタデータ検証を実行する別の例示的なアーキテクチャ５０２を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0288】

特定の実施形態によれば、ブロックチェーン３９９に記憶されるデータの効率を改善することが望ましく、したがって、ブロックチェーンに書き込まれるべきデータを有する全ての新規トランザクションは、ブロックチェーンに新しいデータを書き込む前に、データマージ５６９プロセスを実行する。これは、ブロックチェーンから、前に書き込まれた記憶されたレコードなどの古いデータを最初取り出し、例えば、取り出されたデータ５６６をホスト組織のデータベースシステム１３０にプルし、次いで、取り出されたデータ５６６を、実行されたスマートコントラクトによりチェックされた新しい検証されたデータ５６７とマージすることにより実行され、結果として、マージされたデータ５６８をもたらす。次いで、マージされたデータ５６８は、例えば、マージされたデータ５６８をブロックチェーンに追加される新しい資産内に埋め込むことにより、又は既存の資産を更新し、既存の資産のペイロード部分をマージされたデータ５６８で置き換えることによりブロックチェーンに書き込まれ、したがって、より効率的な取り出しのために、更新及び検証されたレコード全体をブロックチェーンの１つのブロック上に記憶させる。

【0289】

一実施形態によれば、データマージ５６９プロセスはｐｒｏｔｏｂｕｆ生成器５９９により実行され、これは、取り出されたデータ５６６を新しい検証されたデータ５６７とマージすることに加えて、データの合計サイズを低減する。例えば、新しい検証されたデータ５６７を用いる取り出されたデータ５６６の動的ｐｒｏｔｏｂｕｆ生成の実行を介して、データは極めて小さく、効率的であるようにされる。

【0290】

プロトコルバッファ（ｐｒｏｔｏｂｕｆ又はｐｒｏｔｏｂｕｆｆと呼ばれる）は、構造化されたデータをシリアライズする（serializing）手段を提供し、したがって、取り出されたデータ５６６及び新しい検証されたデータ５６７を、ｐｒｏｔｏｂｕｆ生成器５９９においてマージされたシリアライズされたバイトストリームにコンバートする。これは、マージされたデータの暗号化を可能にし、記憶されたデータを後に取り出す任意の他のアプリケーションにより容易に使用可能なバイトストリームフォーマットでそのようなデータを提供するという追加的な利点を有する。ｐｒｏｔｏｂｕｆ生成器５９９は、取り出されたデータ５６６及び新しい検証されたデータ５６７により表される構造化されたデータを表すバイトストリームを生成又はパースするために、その記述からソースコードを生成するプログラムを用いて記憶されるデータの構造を記述するインターフェース記述言語を利用する。

【0291】

このようなアプローチは、全ての種類の構造化された情報を記憶し、交換することを可能にする。例えば、ソフトウェア開発者は、データ構造（取り出されたデータ５６６及び新しい検証されたデータ５６７など）を定義することができ、次いで、ｐｒｏｔｏｂｕｆ生成器５９９は、データを、コンパクトで前方及び後方互換性があるが自己記述しない（すなわち、外部指定なしにフィールドの名前、意味、又は完全なデータ型を伝える方法がない）バイナリフォーマットにシリアライズし、ゆえに、記憶されたデータのための暗号化及びデータセキュリティのレイヤを提供する。

【0292】

このような方法で、ｐｒｏｔｏｂｕｆ生成器５９９は、ネットワーク通信の効率を改善し、そのようなデータを後に参照する可能性のある他の言語又はシステムとの相互運用性を改善する。

【0293】

そこで、学生のファーストネーム、ラストネーム、電話番号、及び学生ＩＤを有する学生の記憶レコードの前述の例について考える。

【0294】

特定の実施形態によれば、処理は、ブロックチェーン上にデータを記憶しようとするアプリケーションにより提供及び定義される学生レコードを記述するメタデータのｐｒｏｔｏｂｕｆを生成することで始まり、したがって、プロトコルバッファリングされた（protobuffed）学生レコードメタデータ又はシリアライズされた（例えば、ＪＳＯＮ）準拠の学生レコードメタデータを結果としてもたらす。次に、処理は、記憶レコード内の学生データをメタデータに対して検証して準拠を保証し（例えば、スマートコントラクトを実行することにより）、次いで、処理は、記憶レコード内の学生データのｐｒｏｔｏｂｕｆを生成し、プロトコルバッファリングされた学生レコードデータを結果としてもたらす。次に、学生レコードを記述するプロトコルバッファリング又はシリアライズされたメタデータと、学生レコードのプロトコルバッファリング又はシリアライズされたデータの双方が、ブロックチェーンに書き込まれる。したがって、データのプロトコルバッファリング又はシリアライズされたバージョンを記憶することは、ブロックチェーン上のそのようなデータのより効率的な記憶を結果としてもたらす。そのような実施形態によれば、検証目的で使用されるアプリケーションにより定義されたメタデータは、そのプロトコルバッファリング又はシリアライズされたバージョンにも記憶され、したがって、ブロックチェーン上でのプロトコルバッファリング又はシリアライズされたメタデータの効率的な記憶を結果としてもたらす。

【0295】

そのような実施形態によれば、データマージ５６９プロセスは、新しいフィールド及び新しいデータを記憶レコードに追加することを含み、これは次いで、メタデータを使用して新しいフィールドを動的に検証した後、ブロックチェーン３９９に再書き込みされる。

【0296】

例えば、そのような実施形態によれば、処理は、取り出されたデータ５６６を取得し、新しいフィールドを追加し、例えば、前に記憶された学生のファーストネーム、ラストネーム、及び電話番号に対して学生の新たに割り当てられたユニバーサルＩＤ（例えば、ホスト組織内の情報を識別するために使用される１２８ビット番号としてのユニバーサル一意識別子（universally unique identifier、ＵＵＩＤ）又はグローバル一意識別子（globally unique identifier、ＧＵＩＤ）など）を追加して、マージされたデータ５６８を生成することを含み、その後、処理は、スマートコントラクトを実行することによりメタデータに基づいてマージされたデータ５６８を動的に検証する。メタデータが前にブロックチェーンに書き込まれている場合、メタデータを再度更新又は保存する必要はなく、これはおそらく、更新されたレコードを構成するマージされたデータ５６８の場合である。したがって、マージされたデータ５６８のみがブロックチェーンに書き込まれる。データが新しい（例えば、取り出されず、マージされない）場合、処理は、アプリケーションにより提供されたメタデータを使用して新しいデータを動的に検証し、次いで、新しいデータとメタデータの双方をブロックチェーン上へ記憶する。

【0297】

データをブロックチェーン上に記憶しようとするアプリケーションにより定義されるメタデータは、例えば、学生レコードが３つの必須フィールドと１つの任意のフィールド、例えば、必須のファーストネーム、ラストネーム、及び学生ＩＤと、任意で学生電話番号とを有することを指定することができ、したがって、ブロックチェーンに書き込まれるデータの検証を可能にする。メタデータはさらに、データフィールドのフォーマット、データマスク、又は制限を定義してもよく、例えば、名前は数字を有してはならない、電話番号は特定の桁数を有さなければならない等である。

【0298】

複数の異なるアプリケーションがブロックチェーン上へデータを記憶し、複数の異なるアプリケーションの各々がそれらそれぞれの記憶レコードに対して異なるメタデータを定義してもよく、したがって、スマートコントラクト実行は、それぞれのアプリケーションに対して様々に定義されたメタデータに基づいて異なる種類のデータの検証を実行することができる。例えば、学生名、電話番号、ＵＵＩＤを有する学生レコードは、クレジットカード番号、期限切れデータ、セキュリティコードなどを有するクレジットカードレコードの異なるデータ検証を必要とする異なるメタデータを有する。それにもかかわらず、動的に適用されるメタデータ検証プロセスが基礎をなすデータに依存しないとき、そのようなデータが記憶されるデータレコードのデータに対して定義されたメタデータに準拠している限り、同じ処理が適用される。

【0299】

図５Ｃは、説明される実施形態による、関連エンティティを記憶する別の例示的なアーキテクチャ５０３を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0300】

上述の保存された学生レコードの例では、例えば、学生ファーストネーム、学生ラストネーム、学生電話番号、及び学生ＩＤを有する学生レコードがブロックチェーンに保存された。さらに、学生レコードを記憶しようとするアプリケーションにより定義されたメタデータも記憶され、そのようなメタデータは学生レコードの動的な検証に利用された。

【0301】

さらなる実施形態によれば、関連エンティティはブロックチェーン上に記憶され、前に記憶されたレコードとリンクされる。例えば、新しい学生成績証明書が提供されるブロックチェーン上の記憶された学生レコードについて考える。

【0302】

ここに示されるように、リンク関連エンティティ５７９プロセスが実行され、これにおいて、取り出されたデータ５７２は、関連エンティティを識別するＵＵＩＤフィールド５７３を追加するように修正され、関連エンティティ５７１と、前にブロックチェーンに記憶され、修正のために取り出されたデータレコード５７２との間のリンクを提供する。これは次に、まだ記憶されていないＵＵＩＤフィールド５７４を有するデータを結果としてもたらす。次に、新しい関連エンティティ５７１をリンク及び識別するＵＵＩＤフィールド５７４を有するデータがブロックチェーンに書き込まれ、ブロックチェーン内に記憶され、記憶レコードが今や、記憶レコードの元のデータを有するが、新しい関連エンティティにリンクし識別するＵＵＩＤフィールド５７４も有する結果をもたらす。次に、関連エンティティ５７１は、同じＵＵＩＤデータフィールドを有するメタデータとしてブロックチェーンに書き込まれ、したがって、ブロックチェーンからの関連エンティティ５７１のその後の取り出しを、記憶されたレコード内のＵＵＩＤを最初参照し、次いでメタデータとしてブロックチェーン内に記憶されたリンクされた関連エンティティ５７１を取り出すことにより可能にする。

【0303】

したがって、学生レコードが学生の名前、電話番号、及び学生ＩＤを定義する場合、学生の成績証明書がブロックチェーン上にメタデータとして記憶され得る。新しいＵＵＩＤは、成績証明書が記憶されるために自動的に生成され、次いで、学生レコード内で、学生レコード内の関連エンティティフィールドが更新されて、成績証明書について生成された新しいＵＵＩＤを記憶し、したがって、成績証明書についてのＵＵＩＤを識別する関連エンティティフィールドで更新された学生レコードを、記憶されたメタデータとしてブロックチェーンに書き込まれる別個に記憶された成績証明書とリンクする。このようにして、任意の数の関連エンティティがブロックチェーンに追加され、各々がブロックチェーン内のメタデータとして記憶され、関連エンティティのためのデータフィールドを介して別の記憶レコードにリンクされ得る。複数の関連エンティティフィールドが任意のレコードに追加され、各々が問題の関連エンティティにリンクし識別するための異なるＵＵＩＤを使用してもよい。例えば、学生が成績証明書とさらに医療記録を有する場合、各々がメタデータとしてブロックチェーンに別個に保存され、各々が一意のＵＵＩＤにより別個に識別され、各ＵＵＩＤは学生の記憶レコード内で別個の関連エンティティフィールドとして更新される。前述のように、別個に記憶された関連エンティティのためのＵＵＩＤを識別する関連エンティティフィールドを有する更新されたレコードは、そのプロトコルバッファリング又はシリアライズされたバージョンに記憶されてもよい。

【0304】

図６Ａは、説明される実施形態による、インデキシングスキームを使用してアドレス指定可能（addressable）ブロックから記憶されたレコードを取り出す別の例示的なアーキテクチャ６０１を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ（図示せず）は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0305】

マークルツリーインデックス６１６又はマークルＤＡＧツリーインデックスの使用は、マークルツリーインデックスに基づいてブロックチェーンの特定のブロックに行くことにより、ブロックチェーンからの記憶されたレコードの取り出しを可能にし、したがって、より効率的な方法での記憶されたレコードの取り出しを可能にする。例えば、マークルツリーインデックスは、ブロックチェーン上の多くのアドレス指定可能ブロック６１８のうち１つのアドレスを識別し、次いで、記憶されたレコードの取り出しは、問題の記憶されたレコードを探してブロックチェーンをトラバースする必要を否定し、代わりに、マークルツリーインデックスにより識別されたブロックから直接、記憶されたレコードの取り出しを可能にする。

【0306】

したがって、ここに示されるように、処理は、インデックス６１６へのクエリ６５１を実行して所望のデータのアドレスを識別し、その後、アドレスに基づいてアドレス指定可能ブロック６１８に記憶されたデータを取り出すために特定のブロック６１７へのクエリが実行され、データを見つけるためにブロックチェーンをトラバースし、又はツリーをトラバースする必要はない。

【0307】

特定の実施形態によれば、インデックス６１６は、エンティティとしてブロックチェーン３９９内に記憶され、例えば、インデックスは、ブロックチェーン上の資産として記憶されてもよい。さらに、ブロックチェーン上にそれ自体が記憶されるマークルツリーインデックス６１６内に記憶されたレコードを記憶することにより、インデックスを有する特定のブロックに行くことによってインデックス６１６から任意のデータを取り出すことが可能である。したがって、インデックスが既知である場合、アドレスのためにインデックス６１６をクエリする（６５１）ことは不要であるが、代わりに、インデックス内の既知のアドレスに対するノードに直接行き、そのノードで何らかを受け取る。アドレスがインデックス６１６内のリーフを指し示す場合、リーフ内に記憶されたデータは、インデックス６１６内のそのアドレスへの直接クエリに基づいて返される。アドレスが、さらなるノード又は単に複数のリーフなどの、その下にサブツリーを有するノードを指し示す場合、サブツリー全体が返される。例えば、アドレスＡＢＣが使用される場合、ハッシュＡＢＣを有するノード全体が返され、ハッシュＡを有するリーフ、ハッシュＢを有するリーフ、及びハッシュＣを有するリーフを含む、そのノードの下の３つのリーフが含まれる。

【0308】

インデックス６１６がブロックチェーン内の特定のブロックのアドレス指定情報を記憶している場合、返されたアドレス指定情報に基づいて、取り出されるべき記憶レコードを取り出すために、ブロックチェーンの特定のブロックがチェックされ得る。あるいは、アドレス指定が、記憶されたレコードの最新情報と共にインデックス６１６内に記憶されている場合、アドレスを使用してインデックス６１６に行くと、記憶されたレコードが位置するブロックチェーン上のブロックのアドレス指定情報を返すと共に、その記憶されたレコードの最新情報を返すことの双方がなされ、ゆえに、ブロックチェーンをさらにクエリする必要を否定する。

【0309】

図６Ｂは、説明される実施形態による、ブロックチェーン内のレコードからインデックスを構築してインデックスを維持する別の例示的なアーキテクチャ６０２を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ（図示せず）は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0310】

特定の実施形態によれば、インデックス６１６の使用により、ブロックチェーン内に記憶されたデータレコードへの極めて高速なアクセスを可能にすることが望ましい。上述のように、インデックス６１６は、基礎をなす記憶されたレコードが保持されるブロックチェーン上のアドレス指定可能ブロックのアドレスのみを記憶することができ、したがって、インデックス６１６から取り出されたアドレスを使用するブロックチェーンからのレコードの取り出しを可能にする。あるいは、最新情報、すなわち、ブロックチェーンにより記憶された特定のレコードの最新かつ現在のバージョンの双方が、基礎をなす記憶されたレコードがブロックチェーンにより保持されている場合にブロックチェーンのアドレス指定可能ブロックと共にインデックス内に記憶されてもよい。明確さのために言うと、これは、重複レコードが永続化される結果をもたらす。レコードの最新かつ現在のバージョンはブロックチェーン内に保持され、正式なレコードとみなされるが、クエリ速度を改善するために、同じレコードの第２のコピーが、そのレコードの正式なバージョンが維持されるところのブロックチェーン上のアドレスと共にインデックス６１６内に保持される。

【0311】

そのような実施形態によれば、インデックス６１６は、したがって、ブロックチェーン内の基礎をなす記憶されたレコードを参照することによりホスト組織によって構築又は生成されてもよい。

【0312】

ここに示すように、ブロックチェーン６９９内には、ブロックチェーンの異なるアドレス指定可能ブロックに複数の記憶されたレコードが存在する。記憶レコード６９１はルートブロック６８４に位置する。記憶レコード６９２はブロック６８５Ａに位置し、記憶レコード６９３Ａはブロック６８５Ｂに位置し、最後、更新レコード６９３Ｂはブロック６８５Ｃに記憶され、更新レコードは、もはや現在のものでないとして前の記憶レコード６９３Ａの価値を下げる。

【0313】

これらの記憶されたレコードのいずれも、関連レコードを検索してブロックチェーンをウォーク（walking）又はトラバースし、関連レコードの位置を特定し、次いで位置を特定されたブロックから記憶されたレコードを取り出すことにより、ブロックチェーンから取り出すことができる。

【0314】

インデックス６１６を構築することは、記憶されたレコードが保持されるブロックチェーン内のブロックの少なくともアドレスを提供することにより、このプロセスの取り出し効率を改善する。上述のように、そのようなアドレス指定情報を有するインデックス６１６がチェックされ、記憶されたレコードについてのブロックチェーンのアドレス指定可能ブロックを返すことができ、次いで、記憶されたレコードは、ブロックチェーンの複数のブロックをトラバース又ウォークする必要なくブロックチェーンから取り出すことができる。例えば、インデックス６１６が更新レコード６９３Ｂの位置についてチェックされ、インデックスはアドレス指定可能ブロックチェーンブロック６８５Ｃの位置を返してもよく、次いで、ブロック６８５Ｃは、標準ブロック６８５Ｃにおける更新レコード６９３Ｂである正式な記憶されたレコードの最新かつ最も最近のバージョンを取り出すために、直接クエリされ得る。

【0315】

代替的に、更新レコード６９３Ｂの内容又はデータと、正式な記憶されたレコード６９３Ｂの最新のバージョンがどこに保持されているかを識別するアドレス指定可能ブロックチェーンブロック６８５Ｃの位置の双方が、インデックス６１６内に永続化されてもよく、したがって、ブロックチェーンから何らかのものを取り出す必要を完全に否定する。これは、更新レコード６９３Ｂのさらなるコピーがインデックス６１６内に記憶される結果をもたらすが、更新レコード６９３Ｂのデータが取り出され得る速度は大幅に改善される。これは、インデックス６１６自体がブロックチェーンに書き込まれるのでなくホスト組織内に記憶される場合に特に当てはまる。このような実施形態において、インデックス６１６はホスト組織１１０内でチェックされ、記憶レコードの内容又はデータと共に記憶レコードの位置の双方が返され、ブロックチェーン内の記憶レコードからのデータのコピーに対応するそのようなデータは、ホスト組織に記憶されたインデックス６１６から返される。したがって、このような情報を受信したアプリケーションは、その後、インデックス６１６により返されたブロックチェーン内の記憶レコードの位置を使用してブロックチェーンから記憶レコードを取り出すことにより、ブロックチェーン内に記憶された情報を検証するためにチェックされ、あるいは、アプリケーションは、その特定のアプリケーションのデータ一貫性要件及び懸念に依存して、インデックス６１６自体から返されたデータのコピーを単に利用してもよい。

【0316】

したがって、ここで観察されるように、インデックス６１６のデータリーフは今や、ブロックチェーン内の問題のブロックの位置を提供するアドレス指定情報を含むだけでなく、さらに、ブロックチェーン内の記憶されたレコードのコピーを永続化し、ゆえに、そのようなデータを取り出すための重複した位置を提供する。記憶されたレコードの１つのコピーは、ブロックチェーン自体から取り出し可能であるが、ブロックチェーン内の記憶されたレコードのコピーは、インデックス６１６からも取り出し可能である。

【0317】

ここに示されるように、リーフハッシュＡは今、位置６８４へのリンクを有し、したがって、記憶レコード６９１が永続化されるブロックチェーン６９９上のブロック６８４の位置又はアドレス指定情報を提供する。しかしながら、リーフハッシュＡはさらに今、インデックス６１６自体の中に永続化される記憶レコード６９１のコピーを有し、したがって、ブロックチェーンが記憶レコード６９１の正式なコピーを有するにもかかわらず、必ずしも記憶レコードをブロックチェーンから取り出す必要なく、ホスト組織上に記憶されたインデックス６１６から直接的に、記憶レコード６１８からのデータ又は内容の取り出しを可能にする。インデキシングされるべきレコード（例えば、全ての学生レコード）を識別し、次いでブロックチェーンからこれらのレコードを検索して取り出し、これらのレコードの位置をインデックス６１６内に、取り出された記憶レコードのコピーと共に記録することにより、このようなインデックス６１６を構築し、レコード内容のかなり高速な取り出しに利用することができる。さらに、ブロックチェーンブロック位置６８５Ａへのリンクを、インデックス６１６内に位置する記憶レコード６９２のコピーと共に有するリーフハッシュＢが示されており、また、記憶レコード６９３Ａは更新され、ゆえに記憶レコード６９３Ｂにより廃止された（deprecated）ため、リーフハッシュＣは、ブロックチェーンブロック位置６８５Ｃへのリンクを用いて、ホスト組織１１０に（例えば、ホスト組織１１０のデータベースシステム１３０内に）記憶されるインデックス６１６内に永続化されるブロックチェーンからの記憶レコード６９３Ｂのコピーと共に構築される。インデックス６１６がブロックチェーン内に保存される代替の実施形態では、インデックス６１６のみが取り出される必要があるため取り出し効率は依然として改善されており、これは、上述のようにその中に記憶レコードの重複コピーを有する。

【0318】

次いで、インデックス６１６は、ブロックチェーンを検索するより一層迅速に検索され得、あるいは、インデックス６１６内のリーフ又はノードについてハッシュ又はアドレスが既知である場合、アドレスは、インデックス６１６内のリーフ又はノードに直接行くために利用されてもよく、そこから、全ての内容がゆえに取り出され得る。例えば、アドレス又はハッシュがリーフを指し示す場合、ブロックチェーン内のアドレス指定可能ブロックの位置情報が、そのブロックチェーン位置における記憶レコードの永続化された重複コピーと共に返される。アドレス又はハッシュが、その下にサブノード又は複数のリーフを有するノードを指し示す場合、サブツリー全体が返され、ゆえに、返されたサブツリーのそれぞれのリーフ（エンドポイント）内の複数のレコードの内容が提供される。

【0319】

図６Ｃは、説明される実施形態による、インデックスから情報を取り出すためのアドレスを形成するためにアドレス指定構造を利用する別の例示的なアーキテクチャ６０３を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0320】

マークルツリーインデックス内のアドレスの構造化は、ブロックチェーン上のブロック内の記憶されたレコードのための位置情報が提供される特定のノード又はリーフと、特定の実施形態によれば、記憶されたレコードのコピーへの、かなり高速なアクセスを可能にする。構造化されたアドレスなしでは、マークルツリーインデックス６１６のルートで開始し、次いで、所望のノード又はリーフが見つかるまで各レベルを進むことが必要である。インデックス６１６のこのトラバースは、ブロックチェーンのブロックをウォーク又はトラバースするより高速であるが、ここに示されるアドレス指定構造６４０を介して示されるように、構造化されたアドレスを介して単一のリーフ又はノード（したがって、それはサブノード又はリーフである）を直接参照することにより、より高速なアクセスが実現される。

【0321】

ここで具体的に示されるのは、１６進数字列を構成する４つの主なコンポーネントに分けられるマークルツリーインデックス６１６を利用するインデキシングスキームのためのアドレス指定データ構造６４０である。第１の部分は、特定のアプリケーションがコード化され得る例示的な６～１０ビット（ただし、サイズは異なり得る）のアプリケーション名前空間を提供する。例えば、上記で論じられた学生レコードは、１６進数「５３４ｃ４４４２」にコンバートされる「ＳＬＤＢ」（例えば、学生ルックアップデータベース（Student Lookup DataBase））としてコード化された学生レコードルックアップＡＰＩ又はインターフェースにより定義され、関連して利用されてもよい。このアプリケーション名前空間フィールドの後に、次いで、記憶されたレコード又はメタデータエンティティ、又はメタデータとして記憶された関連エンティティなどの、記憶された情報のタイプ又は種類を識別するための例示的な３～４ビット（ただし、サイズは異なり得る）のエンティティタイプ識別子が続く。例えば、情報は、１６進数「５３５２」にコンバートされるＳＲとしてコード化され得る学生レコードの内容でもよく、あるいは、情報は、１６進数「４ｄ４４」にコンバートされるＭＤとしてコード化され得る学生レコードを定義するメタデータでもよく、あるいは、情報は、関連エンティティでもよい。特定の関連エンティティは、同じタイプ識別子（例えば、ＭＤ／４ｄ４４）を有するメタデータとして記憶され、あるいは代替的に、１６進数「５２４５」にコンバートされる関連エンティティに対してコード化されたＲＥであるなど、一意のエンティティタイプ識別子を有するメタデータとして記憶されてもよい。

【0322】

次に、アドレス指定構造６４０内には、何が記憶されているか（内容ではなく、記憶された情報の名前）を指定するための例示的な１０～２０ビット（ただし、サイズは異なり得る）のエンティティ又はデータレコードの名前がある。したがって、学生レコードを定義するメタデータは、１６進数「５３５２４１４ｄ４４２０」にコンバートされるＳＲＡＭＤ（例えば、学生レコードアプリケーションメタデータ（Student Record Application MetaData）の場合）としてコード化されてもよく、あるいは、記憶された情報は、学生レコード自体でもよく、したがって１６進数「５３５４５５４４５２４５４３２０」にコンバートされるＳＴＵＤＲＥＣ（例えば、学生レコード（Student Record）の場合）と命名され、あるいはおそらく、記憶された情報は、１６進数「５４５２４ｅ５３４３５２５０５４２０」にコンバートされるＴＲＮＳＣＲＰＴと命名された学生の成績証明書が記憶されている関連エンティティであり、あるいは、記憶された情報は、関連エンティティであり得る１６進数「４ｄ４５４４５２４５４３２０」情報にコンバートされるＭＥＤＲＥＣと命名された記憶された学生の医療記録でもよい。アドレス指定構造のそれぞれの部分の任意の余分なスペースが、アプリケーションの使用法及びそのようなデータをパースする手段に依存して、先行するゼロでパディングされてもよい。

【0323】

最後、記憶されたレコードの内容（例えば、学生のレコードを構成する値）、又はレコードを定義するメタデータ（例えば、実際の記憶された内容を定義、検証、構造化、マスク、又はタイプ付けするためのメタデータ）などの、記憶されるべき実際の情報をその中に有するアドレス指定構造の内容又はペイロード部分がある。同様に、アドレス指定構造６４０のペイロード又は内容部分内に、記憶されたレコード内のＵＵＩＤフィールドに対応するリンクされたＵＵＩＤを介して関連するエンティティを識別するメタデータが記憶されてもよい（例えば、学生レコードは、学生の成績証明書についてのＵＵＩＤを有する関連エンティティフィールドを含んでもよく、したがって、学生のレコードを、ブロックチェーン上の関連エンティティメタデータの記憶された資産内の学生の別個に記憶された成績証明書とリンクする）。

【0324】

アドレス指定構造６４０のペイロード又は内容部分内で、インデキシングスキームを利用するアプリケーション開発者は、極めて小さく効率的であるが制限的なアドレス指定構造６４０に対しての７０ビットの合計制限から、有意に多くの情報が記憶され得る最大でｎビット（例えば、使用事例に依存して数百又は数千）などの、記憶され得るもののほとんど制限されない柔軟性を有する。

【0325】

情報が１６進数字列として記憶されるため、情報は容易にプロトコルバッファリングされ、シリアライズされ、暗号化され、解読され得ると共に、ネットワークにわたり効率的に伝送され、いかなる特化されたフォーマットにも関係なく異種アプリケーションにより利用され得る。

【0326】

図６Ｄは、説明される実施形態による、インデックスから情報を取り出すためにアドレスを利用する別の例示的なアーキテクチャ６０４を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0327】

ここに示されるように、クエリインターフェース１８０はアドレス６５３を提供し、これを介して、アドレスを使用してインデックスに対してクエリ６５２を実行し、ゆえに、どんな取り出しデータがアドレスを介してクエリされるかに依存してインデックス６１６のリーフ又はサブツリーのいずれかのインデックス６１６からの直接取り出しを可能にする。

【0328】

上記の例からのインデキシングスキーム及びアドレス構造を使用して、インデックス６１６のアドレスに対するクエリ６５２について考える。

【0329】

例えば、学生レコードルックアップＡＰＩ又はインターフェースのアプリケーション名前空間は、１６進数「５３４ｃ４４４２」にコンバートされる「ＳＬＤＢ」（例えば、学生ルックアップデータベース）としてコード化され、その後に、１６進数「４ｄ４４」に変換されるＭＤ（メタデータの場合）としてコード化された情報のタイプ又は種類が続き、その後に、１６進数「５３５２４１４ｄ４４２０」に変換されるＳＲＡＭＤとしてコード化された学生レコードを定義するメタデータが続く。

【0330】

これは、５３４ｃ４４４２＋４ｄ４４＋５３５２４１４ｄ４４２０又は５３４ｃ４４４２４ｄ４４５３５２４１４ｄ４４２０のアドレスを結果としてもたらす。内容又はペイロードのアドレスを定義することは必要なく、なぜならば、これは取り出されるデータであるためだが、このようなデータは、内容又はペイロードの１６進表現と連結された上記アドレスを使用してインデックスに書き込まれてもよい。

【0331】

それにもかかわらず、アドレス５３４ｃ４４４２＋４ｄ４４＋５３５２４１４ｄ４４２０を使用してインデックス６１６に対してクエリすることは、取り出されるペイロード又は内容をその中に有するマークルツリーインデックス内のリーフまでの完全修飾アドレスを提供し、それは、この場合では「ＳＬＤＢ」（例えば、学生ルックアップデータベース）と呼ばれるアプリケーションのメタデータであり、これは、そのアプリケーションのための学生レコードのコード化を定義する。

【0332】

同様に、学生レコードが取り出されるべき場合、アドレス５３４ｃ４４４２（学生のルックアップデータベースの場合）＋５３５２（ＳＲ又は学生レコードの場合）＋５３５４５５４４５２４５４３２０を使用してインデックス６１６にクエリすることは、取り出される学生レコードペイロード又は内容をその中に有するマークルツリーインデックス内のリーフまでの完全修飾アドレスを提供し、それは、この場合では「ＳＬＤＢ」（例えば、学生ルックアップデータベース）と呼ばれるアプリケーションの学生レコード情報であり、これは、上記の取り出されたメタデータにより定義されている。学生のＵＵＩＤ又は学生ＩＤが、記憶された学生レコードペイロードの先頭部分として利用される場合、アドレスは、その特定の学生のためだけの特定レコードの内容を取り出すために、さらに修飾されてもよい。

【0333】

そのようなインデキシングスキームの別の利点は、非完全修飾アドレス又は部分的アドレスを使用して情報についてクエリする能力である。例えば、上記の例を続けると、開発者は、直接取り出しのために、それらのアドレスとそれらのメタデータのエンティティタイプ識別子を指定することにより、インデックス６１６に部分的アドレスをサブミットすることにより、それらの特定のアプリケーションの全てのメタデータを返すようにインデックスをトリガすることができる。したがって、このような部分的アドレスは、１６進数「５３４ｃ４４４２」にコンバートされる「ＳＬＤＢ」（例えば、学生ルックアップデータベース）に対応するアプリケーション名前空間部分の後に１６進数「４ｄ４４」にコンバートされるＭＤ（メタデータの場合）としてコード化された記憶された情報のタイプ又は種類が続く１６進数字列を形成し、ゆえに、５３４ｃ４４４２＋４ｄ４４又は単に５３４ｃ４４４２４ｄ４４を結果としてもたらす。

【0334】

この部分的アドレスを使用して直接取り出しのためにインデックス６１６にクエリすることは、「ＳＬＤＢ」（例えば、学生ルックアップデータベース）アプリケーションのための全てのメタデータを、そのようなメタデータが何と命名されているか又はそのようなデータを記憶するためにいくつのリーフ又はサブツリーが消費されているかにかかわらず、インデックスに返させることになる。より詳細には、部分的アドレスを使用してインデックス６１６にクエリすることは、１６進数字列５３４ｃ４４４２＋４ｄ４４でハッシュされたマークルツリーインデックスのノード下のサブツリー全体を返す。同様に、全ての学生レコードは、いずれの具体的に命名された学生レコードもなく、インデックス６１６のクエリにアドレス５３４ｃ４４４２（学生ルックアップデータベースの場合）＋５３５２（ＳＲ又は学生レコードの場合）を指定するなど、直接取り出しのための部分的アドレスを指定することにより（返されるサブツリー全体を介して）取り出すことができる。

【0335】

インデックス内の内容又はペイロード情報が、ブロックチェーン内の記憶されたレコードの位置情報と、ブロックチェーンからインデックス６１６へコピーされた記憶されたレコードの内容との双方を含む場合、ブロックチェーンからさらに何かを取り出すことは必要ない。ブロックチェーンの指定されたブロック内のコンテンツの位置情報のみが提供される（したがって、より小さいインデックスに起因して、一層小さい記憶ボリュームとより高速な取り出しを結果としてもたらす）場合、ブロックチェーンサービスインターフェース１９０は、その後、位置情報を利用して、ブロックチェーン上の指定されたブロックから直接、記憶されたレコードの内容を取得し、指定された記憶レコードの検索においてブロックチェーンの複数のブロックをトラバース又はウォークする必要はない。

【0336】

図６Ｅは、説明される実施形態による、現在の更新を記憶するためにインデックスを使用して記憶レコードのためのブロックチェーン資産を増分的に更新する別の例示的なアーキテクチャ６０５を示す。この例示的なアーキテクチャにおいて、ブロックチェーン合意マネージャ１９１及びパーミッションマネージャ１８１は、図１０～図１２に関連してさらに説明される読み取り及びアクセス制御プロセスに関する合意をサポートするように動作する。

【0337】

特定の状況では、情報をブロックチェーン内に記憶することが望ましいが、ブロックチェーンストレージが、高頻度での多くの更新を伴う情報ストレージへの適合がかなり不十分であると仮定すると、記憶レコードの情報更新のボリューム及び頻度は、ブロックチェーンの使用を非実用的にする。

【0338】

ここに示されるように、多くの更新を有する入ってくるデータストリーム６８１がホスト組織で受信され、更新がインデックス６１６に書き込まれ、結果として、データストリーム更新が要素６８２に示されるようにインデックスを介して記憶される。次いで、周期的に、増分更新が、例えば、記憶レコードをインデックス６１６から取得されブロックチェーンに記憶レコードとしてプッシュされる増分更新と共に有する新しい資産を追加するためにブロックチェーンとの間でトランザクション処理することにより、ブロックチェーンに書き込まれる。例えば、記憶レコード６８４Ａは、最初、データストリームからのデータの初期バッチによりブロックチェーン６９９上に記憶される。次に、さらなるデータストリーム更新がホスト組織におけるインデックス６１６に最初書き込まれ、ある期間の後、次いで、増分更新が再びブロックチェーンに書き込まれ、結果として、反復的な増分更新をもたらし、ここでは、増分更新６８４Ｂ、次いで増分更新６８４Ｃ、次いで増分更新６８４Ｄとして示され、以下同様である。

【0339】

例えば、ステータス、エラー、位置、イベント、構成変更などの様々なテレメトリデータを報告しているＩｏＴデバイス（モノのインターネット（Internet of Things））デバイスからの情報ストリームの記憶について考える。そのようなデータの収集が、数百のＩｏＴデバイスの大規模グループにスケーリングされる場合、ブロックチェーンは、データ記憶要求の頻度に起因して圧倒される可能性がある。

【0340】

しかしながら、インデックス６１６内に情報を記憶することは、特にインデックスがホスト組織内に記憶されるとき、この問題を克服し、なぜならば、ホスト組織のデータベースシステム１３０は、高頻度のデータベース更新及び相互作用を容易に収容するためである。

【0341】

したがって、それにもかかわらず、そのようなデータをブロックチェーン上で利用可能にし、ブロックチェーン上に記憶することが望ましい場合、頻度問題は、最初、多くの更新（例えば、ＩｏＴデバイス又は他のそのような更新からの）をホスト組織１１０内のインデックス６１６に直接書き込み、次いで、ブロックチェーン内のデータの永続的な記憶のためにブロックチェーンに増分更新を周期的に書き込むことにより克服され得る。例えば、ＩｏＴデバイスデータストリームは、ホスト組織１１０によりインデックスに収集されてもよく、次いで、２４時間（又は、何らかの他の期間）毎に１回、ＩｏＴデバイスデータストリームへの増分アップデート（ブロックチェーンへの最後の更新から現在利用可能なデータまで測定される）が、ブロックチェーン上へプッシュ、フラッシュ、追加、又はトランザクション処理される。したがって、ブロックチェーンの最新ブロックは、次いで、ＩｏＴデバイスデータストリームの最新部分を永続的に記憶し、したがって、ブロックチェーンから直接アクセス可能であり、あるいは代替的に、ホスト組織においてインデックス６１６から利用可能である。

【0342】

特定の実施形態において、インデックスは、ブロックチェーンに増分更新を記憶することにより増分データをパージ又はフラッシュし、次いで、インデックスは、記憶された内容又はペイロード部分をインデックス６１６から除去し、基礎をなす記憶されたレコードの位置を特定するためのブロックチェーン上のブロック位置情報のみを保有する。言い換えると、ひとたび増分情報がブロックチェーンに書き込まれると、インデックス６１６は、それがブロックチェーンの特定ブロック上の増分情報を有する記憶されたレコードの位置を特定する場所を保有するようにクリーンアップされ得るが、インデックス６１６自体は、そのような記憶されたレコードの内容を、これらがブロックチェーン内で利用可能であるためもはや保有せず、なぜならば、かなり急速に増大するそのようなデータは、望ましくない方法でインデックスを遅くする可能性があるためである。

【0343】

全体的な変更（例えば、これまでに収集されたＩｏＴデータストリームの全て）をその全体でブロックチェーンにプッシュすることは、増分更新の前の全てのデータがブロックチェーン内で何度も繰り返し複製されるため、問題がある。したがって、増分変更又は更新のみをブロックチェーンにプッシュすることは、記憶の目的のためのブロックチェーンの効率的な使用と、インデックス６１６の効率的な使用を提供し、これにより、入ってくるデータストリーム又は入ってくる高頻度更新をバッファリングすると共に、これを介し、インデックス６１６は、増分情報がブロックチェーン上でどこに（例えば、どのブロック内に）記憶されているかを示す位置情報の高速な識別を可能にする。

【0344】

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

【0345】

多くの顧客組織や企業は、それらが顧客の問題を解決するように市場により義務付けられているため、ネットワーク中心の方法で経営されている。したがって、無関係の企業組織を時に含む企業間で、顧客のために互いの間でデータを共有することが必要となる。

【0346】

しかしながら、理解できるように、異なる企業は互いの信頼を根本的に欠いている。ゆえに、多くの企業は、今日、それらの顧客を満足させるためにデータを共有する必要があるが、それらがデータを共有する他の企業が信頼できることを信頼することができない状況に置かれている。

【0347】

分散台帳技術とブロックチェーンプラットフォームは、上記のように、信頼の問題を具体的に解決する。これが真である理由は、ブロックチェーン上に書き込まれたデータは不変であり、その結果、更新が提供され得るが、履歴データは常にアクセス可能であり、さらに依然として、ブロックチェーンに対する全ての参加ノードは同意された合意モデルに基づいて合意に協調的に寄与するためである。これに対する例外は、上記で論じられた修正されたＤＬＴ技術であり、これについては、共有台帳（例えば、図１Ｃの要素１５７及びそれ以降参照）がホスト組織の内部でホストされ、ホスト組織が単一かつ中央集権的な信頼オーソリティとして動作し、あるいは代替的に、信頼決定が修正ＤＬＴ共有台帳インスタンス１５７を動作させる顧客組織に委譲され、それに従って、顧客組織は、次いで自力で、どのパートナー組織又はユーザ等が修正ＤＬＴ共有台帳のデータにアクセスするための顧客組織からの同意を有するかなどの、誰がアクセス権を有するかを決定する。

【0348】

したがって、ＤＬＴ技術とブロックチェーン技術の利用は具体的に、データを共有したい企業間の信頼の問題を解決すると考えられる。

【0349】

信頼の問題が大きく解決されたにもかかわらず、技術の採用を妨げる２つのさらなる障害が残っている。

【0350】

第１に、ブロックチェーンの採用は、ほとんどの企業が独自に実施するには技術的に複雑であり、極めて困難である。そのようなデータの技術的評価でさえ、しばしばテクニカルビジネスアナリストにより提供されるビジネスのニーズの理解と結び付けられたこの特定分野の専門知識と、次いで、さらなるコンピューティングインフラストラクチャの調達と、ブロックチェーンプラットフォーム及びプロトコル自体の開発か、又はビジネスのニーズを満たす既存のパブリック又はプライベートブロックチェーンの識別及びその後の参加かのいずれかとにおける適切なスキルを有する専門のコンピュータプログラマ及び開発者を必要とする。これらの開発者は、ブロックチェーン上への資産（時に「コイン」と呼ばれる）をパッケージ化及びトランザクション処理する方法と、関心のあるそれらの情報が埋め込まれている資産をノード間で転送する方法を理解し、そのようなデータをブロックチェーン上の他の参加ノードに利用可能にし、情報が共有され得るようにしなければならない。さらに依然として、企業にとって受け入れ可能な、そのようなブロックチェーンによる合意モデルがあることが必要である。これらの理由だけでも、ブロックチェーン技術の採用は、有望ではあるが多くの企業にとって乗り越えられない負担のままである。

【0351】

第２に、上述の障害が克服されたと仮定しても、ブロックチェーンに書き込まれ、ブロックチェーン内に記憶され、又はブロックチェーンにより永続化される情報についてのアプリケーションにわたるデータ標準化に重要な問題が残る。例えば、企業がブロックチェーンに対して情報をトランザクション処理することを成し遂げ、そのデータを他の企業にとってアクセス可能にしたと仮定しても、単純に、第１の企業によりブロックチェーンに書き込まれた情報が第２の企業により理解できるという保証は全くない。したがって、データを共有したい企業間のデータの輸送可能性（transportability）は、様々に利用可能なブロックチェーンプラットフォーム上に書き込まれるデータの標準化の欠如に起因して、別の重要な問題を提示する。

【0352】

ここで、図７に示される例示的な図について考える。２つのビジネス７０５Ａ及び７０５Ｂがあり、これらは、互いにデータを共有することに同意することを成し遂げており、ブロックチェーン６９９とトランザクション処理するのに必要な計算アーキテクチャを成功裏に実施している。

【0353】

全データ共有同意が実施されて、ビジネス７０５Ａは、ユーザクライアントデバイス７０６Ａで実行されるそのアプリケーション＃１を介して資産を作成し、図示のように、顧客レコードをその資産７１４に埋め込み、これは次いで、ブロックチェーン６９９へトランザクション処理される。ここに示すように、アプリケーション＃１は、以下の情報を有する資産を作成する。

【表1】

【0354】

注目すべきことに、このレコードでは、４つのフィールドが存在し、「Ｆｉｒｓｔ＿Ｎａｍｅ」及び「Ｌａｓｔ＿Ｎａｍｅ」、その後に続く、特定の桁の間にハイフン「‐」が必要とされる同様に使用される特定のフォーマットマスクを有する「Ｐｈｏｎｅ＿Ｎｕｍｂｅｒ」、並びに最後に、「Ｅ＿Ｍａｉｌ＿Ａｄｄｒｅｓｓ」のフィールド識別子を有する電子メールアドレスが含まれる。

【0355】

次いで、様々なフィールドの各々がデータを投入される。

【0356】

次いで、作成された資産は、ブロックチェーンへ書き込まれる資産７１５により示されるように、ブロックチェーン６９９上へトランザクション処理され、いくらか後の時間に、ビジネス７０５Ｂは、その独自のアプリケーション＃２を介して情報を取り出すことを選択する。

【0357】

ここに示すように、ビジネス７０５Ｂは、ブロックチェーンとの間でトランザクション処理し、取り出された資産７１６は、ユーザクライアントデバイス７０６Ｂで実行されているアプリケーション＃２に正常に送信される。

【0358】

アプリケーション＃２が、データのその独自の理解を利用してアプリケーション＃２で実行されるコードを介して資産７１７を解釈するまで、全てうまくいくように見え、これは、以下の情報を予期する。

【表2】

【0359】

予期され得るように、アプリケーション＃２は、取り出しエラーメッセージ「資産内にデータが見つかりません（No Data found in Asset）」に直面する。

【0360】

これは、アプリケーション＃２が「Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅ」と命名されたフィールドを探したがそのようなフィールドが存在しないときの結果である。アプリケーション＃２は、フィールド「Ｐｈｏｎｅ」をさらに探し、そのようなフィールドを見つけず、最後に「ｅｍａｉｌ」を検索し、再度、そのようなフィールドを見つけない。

【0361】

人間の読み手は、値「Ｊｏｈｎ」を有する「Ｆｉｒｓｔ＿Ｎａｍｅ」がフィールド「Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅ」のサブ部分を表すことを容易に理解し得るが、このようなロジックは、「Ｆｉｒｓｔ＿Ｎａｍｅ」と「Ｌａｓｔ＿Ｎａｍｅ」の組み合わせでなく「Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅ」である、それらが検索するように指示された（例えば、プログラムされた）フィールド名を単に検索するアプリケーション及び計算プログラム内では、単に利用できない。

【0362】

２つのフィールドタイプ間のこのようなコンバージョンはプログラマにとって些細であるが、それぞれのビジネスの各々による２つのアプリケーションは単に互換性がないという事実に変わりはなく、それらが互換的にされるべき場合、これらのフィールドのカスタム翻訳がプログラムされる必要がある。

【0363】

基本的に、このデータの転送不可能性（non-transferability）は、データ標準化の欠如に起因している。２つの区別可能なアプリケーションエンティティは各々、ブロックチェーンに書き込み、それから取り出すことを可能にされ、そのようなデータを共有するためにビジネス間で同意が実施されているが、２つのエンティティアプリケーションはデータを共有する能力を欠いており、なぜならば、何が顧客の名前を構成するかの定義がないためである。１つのアプリケーションは、これが「Ｆｉｒｓｔ＿Ｎａｍｅ」フィールドと「Ｌａｓｔ＿Ｎａｍｅ」フィールドの組み合わせであることを予期するが、別のアプリケーションは、顧客のフルネームに対する単一フィールドとしてフィールド「Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅ」が利用されることを予期している。

【0364】

図７Ｂは、説明される実施形態による別の例示的なアーキテクチャ７０２を示す。

【0365】

詳細には、次に、アプリケーションにより利用されるデータのためのメタデータを定義するブロックチェーン管理者が示され、これは次いで、２つのビジネス、ビジネス７０５Ａ及びビジネス７０５Ｂのためにブロックチェーンに書き込まれるデータを標準化する。

【0366】

ここに示されるように、ブロックチェーン管理者は、統合ビルダのＧＵＩを介して、又は統合ビルダのＡＰＩを介してメタデータを定義し、定義されたメタデータ７２１は、次いで、指定されたブロックチェーン７９９上へプッシュされる。

【0367】

次に、ブロックチェーン上へトランザクション処理される、明確に定義されたメタデータが存在し、これは、宣言されたアプリケーション「ＡｐｐｌｉｃａｔｉｏｎＸＹＺ」と、具体的に「Ｃｕｓｔｏｍｅｒ＿Ｒｅｃｏｒｄ」の要件を規定し、これは次に、定義されたメタデータにより以下のように構造化される。

【表3】

【0368】

定義されたメタデータ７２１はブロックチェーン上へトランザクション処理されるため、ブロックチェーン７９９上のデータレコードにアクセスするためのパーミッションを有するいかなるアプリケーションも、定義されたメタデータ７２１により規定された要件に準拠してデータを読み書きすることができる。これは、具体的に宣言されたアプリケーション「ＡｐｐｌｉｃａｔｉｏｎＸＹＺ」でもよく、あるいはこれは、宣言されたアプリケーションにより生成又は管理されたデータを利用する他のアプリケーションでもよい。任意のアプリケーションが、定義されたメタデータ７２１を読み出し、要件に準拠して動作することができる。

【0369】

図７Ｃは、説明される実施形態による別の例示的なアーキテクチャ７０３を示す。

【0370】

詳細には、次に、ビジネス７０５Ａ及び７０５Ｂが、ブロックチェーン７９９上へトランザクション処理されたデータを共有可能にされることが示される。定義されたメタデータ７２１がそのようなデータをフォーマットするための要件を規定しているため、ブロックチェーン７９９に書き込まれブロックチェーンから取り出されるデータは既知のフォーマットを具現化し、したがって、様々なビジネス間で転送可能になる。

【0371】

ここに示されるように、ブロックチェーン管理者はブロックチェーンサービスインターフェース１９０を介してメタデータを定義し、これはブロックチェーンにトランザクション処理され、次いでその後、ビジネス７０５Ａがアプリケーション＃１を介して資産７１４を作成し、それは顧客レコードの詳細を有するその資産をブロックチェーンに書き込む。その後、ビジネス７０５Ｂがブロックチェーンから資産を取り出し、資産がビジネス７０５Ｂで実行されているアプリケーション＃２を介して解釈されるとき（７１７）、そのデータはアプリケーションにより成功裏に解釈及び理解され、なぜならば、顧客レコードデータに対して既知の定義されたメタデータ構造が存在するためである。

【0372】

したがって、特定の実施形態によれば、新しいアプリケーションを宣言し、新しいアプリケーションのために定義されたメタデータをブロックチェーン上へトランザクション処理するホスト組織のシステムによる動作がある。例えば、そのような動作は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることを含んでもよく、複数のテナントの各テナントは、ブロックチェーンへのアクセスを有する参加ノードとして動作する。このような動作は、システムと通信上インターフェースされたユーザデバイスから、新しいアプリケーションを宣言する第１の入力を受信することをさらに含んでもよい。このような動作は、新しいアプリケーションのために複数のネットワーク参加者を追加するユーザデバイスからの第２の入力を受信することをさらに含んでもよく、ネットワーク参加者は、新しいアプリケーションへのアクセス権を付与される。このような動作は、新しいアプリケーションのための複数のエンティティタイプを宣言するユーザデバイスからの第３の入力を受信することをさらに含んでもよい。このような動作は、複数のエンティティタイプの各々について１つ以上の新しいフィールド定義を宣言するユーザデバイスからの第４の入力を受信することをさらに含んでもよい。このような動作は、新しいアプリケーションのために定義されたメタデータとして少なくとも（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義をその中に符号化されたブロックチェーン資産を生成することをさらに含んでもよい。このような動作は、ブロックチェーン上へ新しいアプリケーションのために定義されたメタデータをその中に符号化されたブロックチェーン資産をトランザクション処理することをさらに含んでもよい。

【0373】

別の実施形態の動作によれば、ブロックチェーン資産は定義されたトランザクションタイプを有し、これにおいて、定義されたメタデータをその中に符号化されたブロックチェーン資産の定義されたトランザクションタイプは、新しいアプリケーションのために定義されたメタデータを、新しいアプリケーションのためにブロックチェーン上へトランザクション処理された任意のデータのデータ検証を実行するためのスマートコントラクトに関連づけ、これにおいて、スマートコントラクトは、新しいアプリケーションのためにブロックチェーン上へトランザクション処理されたデータが、ブロックチェーン上へトランザクション処理された新しいアプリケーションのために定義されたメタデータに準拠していることを検証する。

【0374】

別の実施形態によれば、このような動作は、新しいアプリケーションのためのデータを指定するブロックチェーンにおけるトランザクションを受信することと、新しいアプリケーションのためのデータを指定する受信したトランザクションに基づいてスマートコントラクトをトリガすることと、スマートコントラクトを実行して、新しいアプリケーションのために指定されたデータが新しいアプリケーションのために定義されたメタデータに準拠していることを検証することをさらに含んでもよく、これにおいて、トランザクションは、指定されたデータが新しいアプリケーションのために定義されたメタデータに準拠していない場合、拒絶される。

【0375】

別の実施形態の動作によれば、ブロックチェーン上へブロックチェーン資産をトランザクション処理することは、トランザクションのペイロードデータとして新しいアプリケーションのために定義されたメタデータ指定する、ブロックチェーン上の新しいブロックへのトランザクションを追加することと、追加されたトランザクションにブロックチェーンの参加ノードによる合意を受けさせる（subjecting）ことであり、追加されたトランザクションは、追加されたトランザクションがブロックチェーンの参加ノードによりブロックチェーンのプライマリチェーンの一部として受け入れられる前にブロックチェーンの参加ノードによる合意プロトコルを受ける（subjected to）ことを含み、これにおいて、新しいアプリケーションのために定義されたメタデータは、追加されたトランザクションの成功裏の合意に従ってブロックチェーンの新しいブロック上の受け入れられたトランザクション内に永続化される。

【0376】

別の実施形態によれば、このような動作は、システムにおいて新しい入力を受信することであり、新しい入力は第２の新しいアプリケーションを宣言することと、第１の新しいアプリケーションのために宣言された複数のエンティティタイプのうちの１つを第２の新しいアプリケーションのために選択されたエンティティタイプとして選択する、システムにおけるさらなる入力を受信することであり、選択されたエンティティタイプは、第１の新しいアプリケーションに関連づけられたそれぞれの１つ以上のエンティティタイプのために定義されたメタデータを介して指定された１つ以上の新しいフィールド定義を継承する。

【0377】

別の実施形態の動作によれば、複数の異なる宣言されたアプリケーションは、第１の新しいアプリケーションのために宣言された複数のエンティティタイプのうちの少なくとも１つを、複数の異なる宣言されたアプリケーションのために選択されたエンティティタイプとして指定し、これにおいて、第１の新しいアプリケーションのために宣言された複数のエンティティタイプのそれぞれのエンティティタイプに対応する定義されたメタデータの単一のインスタンスと、第１の新しいアプリケーションのために宣言されたそれぞれのエンティティタイプに関連づけられた１つ以上の新しいフィールド定義の全てが、（ｉ）第１の新しいアプリケーションのために宣言された複数のエンティティタイプのそれぞれのエンティティタイプと、（ｉｉ）第１のアプリケーションのために宣言されたそれぞれのエンティティタイプを選択した、複数の異なる宣言されたアプリケーションの全てのための選択されたエンティティタイプとの双方を制御する。

【0378】

別の実施形態の動作によれば、複数のエンティティタイプの各々について１つ以上の新しいフィールド定義を宣言するユーザデバイスからの第４の入力を受信することは、１つ以上の新しいフィールド定義の各々についてフィールド定義タイプを定義する第４の入力を受信することをさらに含み、各フィールド定義タイプは、整数、ブーリアン、数字、英数字、日付、ハイパーリンク、計算されたもの、又はカスタムを含むグループから選択される。

【0379】

別の実施形態によれば、このような動作は、ユーザデバイスを複数のテナントのうちの１つに関連づけられるものとしてホスト組織を用いて認証することをさらに含み、複数のテナントのうちの１つは、パブリックインターネットを通じてホスト組織により提供されるクラウドベースのオンデマンドサービスのサブスクライバである。

【0380】

別の実施形態によれば、このような動作は、イベントリスナを実行して、新しいアプリケーションに関連づけられたブロックチェーンに対する変更を監視することと、新しいアプリケーションに関連づけられたブロックチェーンに対する変更がイベントリスナにより観測されたときイベントをトリガすることをさらに含んでもよい。

【0381】

別の実施形態によれば、このような動作は、宣言された新しいアプリケーションのためのイベント及び１つ以上の観測イベント条件を宣言するユーザデバイスからの第５の入力を受信することであり、宣言されたイベントは、（ｉ）ブロックチェーンにおけるイベントの発生に応答してホスト組織において実行されるプロセスフロー、又は（ｉｉ）ブロックチェーンにおけるイベントの発生に応答してホスト組織の内部のデータベースシステムに対して実行されるデータベーストランザクション、のうちの１つを指定することと、イベントリスナを介して、指定されたイベント及び１つ以上のイベント条件を満たすブロックチェーンに対する変更を監視することをさらに含んでもよい。

【0382】

別の実施形態の動作によれば、各ネットワーク参加者は、新しいアプリケーション及び新しいアプリケーションに関連づけられたブロックチェーン上のデータへのアクセス権を付与される。

【0383】

別の実施形態の動作によれば、複数のネットワーク参加者の各々は、ホスト組織の複数のテナントのうちの１つに関連づけられたホスト組織のユーザと、ホスト組織の複数のテナントのうちの１つに対応するパートナーユーザと、ホスト組織の複数のテナントのうちの１つに対応する顧客組織と、ホスト組織の非ユーザと、ホスト組織の複数のテナントのうちの１つではないパートナー組織と、ホスト組織のテナント又はホスト組織からのクラウドコンピューティングサービスをサブスクライブする顧客組織のいずれかに対応するブロックチェーン上の１つ以上の参加ノードと、ホスト組織からのクラウドコンピューティングサービスをサブスクライブしていないブロックチェーン上の１つ以上の参加ノードと、を含むグループの中から選択される。

【0384】

別の実施形態の動作によれば、アプリケーションを宣言するユーザデバイスからの第１の入力を受信することは、宣言された新しいアプリケーションのための第１の入力で、新しいアプリケーションのための指定された管理制御又は宣言された新しいアプリケーションの所有権のうちの一方又は双方を受信することをさらに含む。

【0385】

別の実施形態によれば、このような動作は、宣言された新しいアプリケーションと新しいアプリケーションのために定義されたメタデータをブロックチェーン上へデプロイする命令を受信することをさらに含んでもよく、ブロックチェーン上へ新しいアプリケーションのために定義されたメタデータをその中に符号化されたブロックチェーン資産をトランザクション処理することは、デプロイする命令を受信することに応答してブロックチェーンを介して新しいアプリケーションと定義されたメタデータをデプロイすることを含む。

【0386】

別の実施形態の動作によれば、（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義、の各々を定義する入力を受信することは、ホスト組織により公開されたブロックチェーンメタデータ定義マネージャにおけるＡＰＩを介してプログラミングコードとして入力を受け取ることを含む。

【0387】

別の実施形態によれば、このような動作は、ブロックチェーンメタデータ定義マネージャからユーザデバイスにＧＵＩを送信することをさらに含んでもよく、これにおいて、ＧＵＩは、（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義、の各々を定義する入力を促し（prompts）、入力は、１つ以上のインタラクティブなクリックイベント、ドラッグイベント、ドロップダウン選択イベント、テキスト入力イベント、及びタッチイベントを介してＧＵＩにおいて受け取られ、入力を受信することは、ユーザデバイスに送信されたＧＵＩから入力を受け取ることを含む。

【0388】

別の実施形態の動作によれば、ブロックチェーンのブロックチェーンプロトコルはホスト組織により定義され、さらに、ホスト組織は、ブロックチェーン上の参加ノードとして動作するホスト組織の複数のテナントに対してブロックチェーンへのアクセスを許可し、あるいは代替的に、ブロックチェーンのブロックチェーンプロトコルは、ホスト組織以外の第三者のブロックチェーンプロバイダにより定義され、さらに、ホスト組織も、ホスト組織がブロックチェーンへのアクセスを有するブロックチェーン上の参加ノードとして動作する。

【0389】

別の実施形態によれば、このような動作は、新しいアプリケーションに関連づけられたデータを要求するＳＱＬクエリを受信インターフェースにおいて受信することと、ホスト組織におけるＡｐｅｘトランスレータエンジンを介してＳＱＬクエリをネイティブブロックチェーン実行可能コードに翻訳することと、ブロックチェーンに対してネイティブブロックチェーン実行可能コードを実行して、要求されたデータを取り出すことと、ＳＱＬクエリの受信に応答して要求されたデータを返すことをさらに含んでもよい。

【0390】

別の実施形態によれば、このような動作は、ホスト組織のデータベースシステム内で仮想テーブルを生成することと、新しいアプリケーションのために宣言されたメタデータに基づいてホスト組織のデータベースシステムに仮想テーブルを構造化することをさらに含んでもよく、これにおいて、エンティティタイプは仮想テーブル内のテーブルとして表現され、さらに、新しいアプリケーションのための複数のさらなるエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義は、仮想テーブルにおいてテーブル内の列として表現される。

【0391】

別の実施形態の動作によれば、仮想テーブルは、新しいアプリケーションのために宣言されたメタデータに基づいて構造化された、ホスト組織のデータベースシステムにホストされたマテリアライズドビューを含み、ホスト組織のデータベースシステムにホストされたマテリアライズドビューは、新しいアプリケーションに関連づけられたデータを記憶せず、読取専用アクセスを要求するＳＱＬクエリは、ブロックチェーンから新しいアプリケーションに関連づけられた要求されたデータを取り出すために読取専用ＳＱＬクエリをブロックチェーントランザクションに変換することにより、マテリアライズドビューに対して処理される。

【0392】

別の実施形態によれば、このような動作は、新しいアプリケーションのために宣言された複数のエンティティタイプと、複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義と、１つ以上の新しいフィールド定義に適用される任意のフィールドタイプとを含む、新しいアプリケーションのために定義されたメタデータをブロックチェーンから取り出すことと、新しいアプリケーションのために定義されたメタデータに基づいて仮想テーブルを構造化することにより、ホスト組織における仮想テーブル内にブロックチェーンで永続化されるデータのマテリアライズドビューを生成することをさらに含んでもよく、マテリアライズドビューは、ホスト組織におけるマテリアライズドビュー内に新しいアプリケーションに関連づけられたデータを記憶することなく、ブロックチェーンに永続化される新しいアプリケーションに関連づけられたデータの構造を表す。

【0393】

別の実施形態によれば、このような動作は、ホスト組織において、ユーザデバイスからＳＱＬ文を受信することであり、ＳＱＬ文はマテリアライズドビューに向けられ、ブロックチェーンに永続化され及び新しいアプリケーションに関連づけられたデータのためのＳＱＬ ｕｐｄａｔｅ又はＳＱＬ ｉｎｓｅｒｔを要求することと、ブロックチェーンにおいて新しいアプリケーションに関連づけられたデータを更新又は追加するために、ＳＱＬ ｕｐｄａｔｅ又はＳＱＬ ｉｎｓｅｒｔを要求するＳＱＬ文を対応するブロックチェーントランザクションに翻訳することにより、マテリアライズドビューに対してＳＱＬ文を処理することと、対応するブロックチェーントランザクションがブロックチェーンに対する合意により受け入れられ、ブロックチェーンにおいて新しいアプリケーションに関連づけられたデータを成功裏に更新又は追加したことに従って、マテリアライズドビューに対するＳＱＬ文の成功裏の処理を確認する確認応答をユーザデバイスに発行することをさらに含んでもよい。

【0394】

別の実施形態によれば、このような動作は、ホスト組織におけるマテリアライズドビューに向けられたＳＱＬ文を受信することをさらに含んでもよく、これにおいて、ＳＱＬ文は、（ｉ）ＳＥＬＥＣＴ ｆｒｏｍ ＳＱＬ文、（ｉｉ）ＩＮＳＥＲＴ ｉｎｔｏ ＳＱＬ文、及び（ｉｉｉ）ＵＰＤＡＴＥ ｓｅｔ ＳＱＬ文のうちの１つ以上を指定し、受信したＳＱＬ文は、ＳＱＬ文を対応するブロックチェーントランザクションに翻訳し、ホスト組織におけるマテリアライズドビューに向けられたＳＱＬ文の履行においてブロックチェーンに対して対応するブロックチェーントランザクションを実行することにより処理される。

【0395】

別の実施形態によれば、このような動作は、新しいアプリケーションのために定義されたメタデータが、ブロックチェーンにおける資産を一緒にリンクすることにより複数のエンティティタイプのうちの２つ以上の間のユーザ指定の関係を表すことをさらに含んでもよい。

【0396】

別の実施形態によれば、このような動作は、ホスト組織において、新しいアプリケーションのための新しいビジネスロジックを、新しいビジネスロジックの要素と新しいアプリケーションの複数のエンティティタイプのうちの１つ以上との間の１つ以上の関係を有するテーブル構造内に宣言することと、ブロックチェーンに永続化されたメタデータ内の全ての関係を新しいビジネスロジックを定義することをさらに含んでもよい。

【0397】

別の実施形態によれば、このような動作は、イベントリスナを実行して、ブロックチェーンにおける新しいアプリケーションのために定義されたメタデータに対する変更を監視することと、ブロックチェーンにおける新しいアプリケーションのためのメタデータに対する変更がイベントリスナにより観測されたときイベントをトリガすることと、をさらに含んでもよく、トリガされたイベントは、イベントリスナによりトリガされたメタデータ更新に基づいてホスト組織におけるマテリアライズドビューを再構造化することにより、新しいアプリケーションに関連づけられたデータのマテリアライズドビューを更新するためにホスト組織へのメタデータ更新を自動的にプッシュする。

【0398】

別の実施形態の動作によれば、新しいアプリケーションのためのメタデータに対する変更に基づいてイベントリスナを介してイベントをトリガすることは、ブロックチェーンに永続化された定義されたメタデータに対する変更に応答して実行するビジネスユーザ定義のプロセスフロー、ブロックチェーンに永続化された定義されたメタデータに対する変更に応答して実行するビジネスユーザ定義のデータ取り出し動作、ブロックチェーンに永続化された定義されたメタデータに対する変更に応答して実行するビジネスユーザ定義のデータフィルタリング動作、ブロックチェーンに永続化された定義されたメタデータに対する変更に応答してデータ分析フィードを更新する管理者定義のプロセスフロー、及びブロックチェーンに永続化された定義されたメタデータに対する変更に応答して人工知能（ＡＩ）訓練データストリームを更新する管理者定義のプロセスフロー、のうちの１つ以上をトリガすることをさらに含む。

【0399】

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するシステムのプロセッサにより実行されると、命令はシステムに動作を実行させ、該動作は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、複数のテナントの各テナントは、ブロックチェーンへのアクセスを有する参加ノードとして動作することと、システムと通信上インターフェースされたユーザデバイスから、新しいアプリケーションを宣言する第１の入力を受信することと、新しいアプリケーションのために複数のネットワーク参加者を追加するユーザデバイスからの第２の入力を受信することであり、ネットワーク参加者は、新しいアプリケーションへのアクセス権を付与されることと、新しいアプリケーションのための複数のエンティティタイプを宣言するユーザデバイスからの第３の入力を受信することと、複数のエンティティタイプの各々について１つ以上の新しいフィールド定義を宣言するユーザデバイスからの第４の入力を受信することと、新しいアプリケーションのために定義されたメタデータとして少なくとも（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義をその中に符号化されたブロックチェーン資産を生成することと、ブロックチェーン上へ新しいアプリケーションのために定義されたメタデータをその中に符号化されたブロックチェーン資産をトランザクション処理することを含む。

【0400】

さらに別の実施形態によれば、ホスト組織において実行するシステムがあり、当該システムは、命令を記憶するメモリと、命令を実行するプロセッサであり、プロセッサは、ホスト組織の複数のテナントのためにブロックチェーンサービスインターフェースを実行し、複数のテナントの各々はブロックチェーンへのアクセスを有する参加ノードとして動作する、プロセッサと、システムと通信上インターフェースされたユーザデバイスから第１の入力を受信する受信インターフェースであり、受信インターフェースはさらに、新しいアプリケーションのために複数のネットワーク参加者を追加するユーザデバイスからの第２の入力を受信し、ネットワーク参加者は、新しいアプリケーションへのアクセス権を付与され、受信インターフェースはさらに、新しいアプリケーションのための複数のエンティティタイプを宣言するユーザデバイスからの第３の入力を受信し、受信インターフェースはさらに、複数のエンティティタイプの各々について１つ以上の新しいフィールド定義を宣言するユーザデバイスからの第４の入力を受信する、受信インターフェースと、新しいアプリケーションのために定義されたメタデータとして少なくとも（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々について宣言された１つ以上の新しいフィールド定義をその中に符号化されたブロックチェーン資産を生成するブロックチェーンサービスインターフェースであり、ブロックチェーンサービスインターフェースはさらに、ブロックチェーン上へ新しいアプリケーションのために定義されたメタデータをその中に符号化されたブロックチェーン資産をトランザクション処理する、ブロックチェーンサービスインターフェースと、を含む。

【0401】

システムの実施形態によれば、受信インターフェースはさらに、宣言された新しいアプリケーションのためのイベント及び１つ以上の観測イベント条件を宣言するユーザデバイスからの第５の入力を受信し、宣言されたイベントは、（ｉ）ブロックチェーンにおけるイベントの発生に応答してホスト組織において実行されるプロセスフロー、又は（ｉｉ）ブロックチェーンにおけるイベントの発生に応答してホスト組織の内部のデータベースシステムに対して実行されるデータベーストランザクション、のうちの１つを指定し、システムは、イベントリスナをさらに含み、イベントリスナは、指定されたイベント及び１つ以上のイベント条件を満たすブロックチェーンに対する変更を監視し、ブロックチェーンでの監視された変更に応答して宣言されたイベントをトリガする。

【0402】

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

【0403】

ここに示すように、ブロックチェーン管理者のユーザデバイスなどのコンピューティングデバイス８９９で実行されるＧＵＩ８１０があり、ＧＵＩ８１０は、ホスト組織のブロックチェーンメタデータ定義マネージャ１９６によりコンピューティングデバイス８００にプッシュされる。

【0404】

ここに示されるように、ブロックチェーン管理者は、ＧＵＩ８１０の上部に示されているようにデプロイされたアプリケーション（deployed applications）を見ることができ、ＧＵＩ８１０における「新規（new）」ボタンをクリックすることにより、宣言型機能が、ブロックチェーン管理者が新しいアプリケーションを宣言するために提供される。ここで示されるのは、ＧＵＩ８１０を介した新しいアプリケーションの宣言であるが、ブロックチェーン管理者は代替的に、ブロックチェーンメタデータ定義マネージャ１９６を介して提供されるＡＰＩを利用して新しいアプリケーションを作成してもよい。

【0405】

図８Ｂは、説明される実施形態による別の例示的なアーキテクチャ８０２を示す。

【0406】

新しいアプリケーションの宣言に追加で、又は新しいアプリケーションを宣言すると、さらに、ブロックチェーン管理者はどのような参加者がこの特定のアプリケーションに関連づけられたデータへのアクセスを有するかを定義する能力を有し、ゆえに、この新たに宣言されたアプリケーションに対するネットワーク参加者を定義する。

【0407】

図８Ｃは、説明される実施形態による別の例示的なアーキテクチャ８０３を示す。

【0408】

ＧＵＩ８１０が再び示されているが、次に示されるのは、ブロックチェーン管理者が「銀行レコードアプリケーション（bank record application）」のためのエンティティをそのアプリケーションをクリックすることにより閲覧及び編集することである。

【0409】

このように、ブロックチェーン管理者は最初、新しい「アプリケーション」を宣言又は作成し、次いで、ひとたび作成されると、ブロックチェーン管理者は、そのアプリケーションを編集又は閲覧することができ、アプリケーション内の新しい「エンティティ」を作成又は宣言することができ、各宣言型エンティティは、特定のカスタムフィールドのためのメタデータを定義し、その中で、アプリケーションは、定義されたメタデータに準拠する情報を最終的に記憶することができ、また、他のアプリケーションもそのようなデータと相互作用し、そのようなデータを参照し、可能性として、適切なパーミッションが存在する場合にそのようなデータを更新、追加、又は削除することができ、ただし再びになるが、定義されたメタデータに準拠してそのようにする。

【0410】

例えば、銀行レコードアプリケーションについてここでは、エンティティ名「Ａｕｔｏ＿Ｃｌａｉｍ」を有する「ｃｌａｉｍ」が定義されており、したがって、クレーム（claims）に属するブロックチェーンに対する情報を書き込むことを望むアプリケーションは、少なくともそのような情報が銀行レコードアプリケーションにより利用される範囲で、定義されたエンティティ「Ａｕｔｏ＿Ｃｌａｉｍ」の要件に準拠することが必要である。

【0411】

図８Ｄは、説明される実施形態による別の例示的なアーキテクチャ８０４を示す。

【0412】

ここに示されているのは、ブロックチェーン管理者が新たに作成されたアプリケーション内又は表示されたアプリケーション内で新しいエンティティを宣言及び作成するために前の画面で「新規（new）」ボタンをクリックしたことから生じるＧＵＩ８１０である。

【0413】

ここに示すように、「新規エンティティ定義（New Entity Definition）」ＧＵＩが提示されており、ブロックチェーン管理者はここで、エンティティ名、エンティティラベルを入力し、エンティティの所有者を選択することにより新しいエンティティを作成することができ、この所有者はデフォルトでは、エンティティを作成しているユーザである。次いで、「保存（save）」をクリックすることにより、この新しいエンティティを作成し、宣言する。ブロックチェーン管理者はさらに、ステータスを「デプロイ済み（deployed）」に変更することができ、ひとたび保存されると、エンティティはブロックチェーン上へトランザクション処理されるが、ドラフト（draft）ステータスでは、それはホスト組織のブロックチェーンメタデータ定義マネージャ１９６でのみ保有される。

【0414】

特定の実施形態によれば、あらゆるＧＵＩは、ブロックチェーンメタデータ定義マネージャ１９６と相互作用するための対応するＡＰＩを有する。

【0415】

図８Ｅは、説明される実施形態による別の例示的なアーキテクチャ８０５を示す。

【0416】

図８Ｄに示される先行ＧＵＩ８１０でちょうど作成されたエンティティを含む既存のエンティティをクリックすると、フィールド定義（Field Definition）ＧＵＩが提示される結果となり、これを介して、ブロックチェーン管理者はここで、その特定のエンティティ内に記憶される任意の数のフィールドを作成することができる。

【0417】

類推として、宣言されたアプリケーションを、クラウドを介して実行されるものではあるがコンピュータプログラムとして考え、宣言型エンティティを、関係データベース内のテーブルに相当するテーブルとして考え、最後に、宣言型フィールドを、テーブル内の列識別子又は投入可能な（populatable）フィールドとして考えることは役立つ可能性があり、最後、フィールドの集合は、レコードを形成することになる。比較は正確ではないが、様々な宣言型要素とそれらのために定義されたメタデータとの関係は、それらの使用を説明するのに役立つはずである。

【0418】

定義されたメタデータは、どんなデータが許容されるかと、そのデータのフォーマット及びタイプを正確に規定しているため、許可されたアプリケーションは、メタデータにより規定された予測可能かつ予め定義されたフォーマットでブロックチェーンに情報を成功裏に書き込むことができ、さらに、それらが共有しているアプリケーションも、ブロックチェーンから情報を成功裏に取り出すことができ、定義されたメタデータに基づいて、その情報がどのように見え、構造化されることになるか、したがってその情報がどのように解釈されるべきかが分かる。

【0419】

情報がメタデータを介してブロックチェーン内に定義されるため、全ての参加者は、定義されたメタデータに基づいてデータの各要素が何を意味するかが分かり、したがって、参加者のそのネットワークでは、全ての参加ノードがブロックチェーンを介して情報を共有することができる。

【0420】

さらに、参加者は、ブロックチェーン上へトランザクション処理された既存のメタデータに制限されず、さらなる要素を作成する、新しいメタデータ定義を作成する、メタデータ定義を改変する等を行ってもよい。

【0421】

例えば、銀行ウェルズファーゴは、それらが参加者として、フィールドＸ、Ｙ、及びＺを有する新しいエンティティを必要とすると決定し得る。したがって、参加者は、フィールドＸ、Ｙ、及びＺを有する新しいエンティティのためのそのメタデータを（ＡＰＩ又はＧＵＩを介して）定義し、次いで、ブロックチェーン上へその新しいエンティティをトランザクション処理することができる。

【0422】

その後、新しいエンティティは、他の参加ノードによる合意を受ける。他の参加ノードが同意しない場合、合意が達せられず、その変更は否定される。しかしながら、合意が達せられた場合、フィールドＸ、Ｙ、及びＺを有する新しいエンティティは、合意ブロック内にブロックチェーン上へのその新しいエンティティのために定義されたメタデータを書き込むことによりブロックチェーン上へトランザクション処理され、あるいは言い換えると、ブロックチェーン上へすでに書き込まれたエンティティは、ひとたび合意が獲得されると、ブロックチェーン上の「プライマリ」チェーンの一部になり、これは、全ての参加者によりメインチェーンとして受け入れられる。

【0423】

別の実施形態によれば、スマートコントラクトは、定義されたメタデータを有するエンティティのためにブロックチェーン上にデータを書き込もうとし又は更新しようとするブロックチェーン上のトランザクションに対して実行される。例えば、スマートコントラクトの実行を引き起こすトリガが存在し得、その場合、スマートコントラクトは、定義されたメタデータを取り出すか又は適用して、エンティティ内のあらゆるフィールドが定義されたメタデータの要件に準拠しているデータタイプ、データ命名準拠、及び日付マスクを有することを検証する。

【0424】

スマートコントラクトが定義されたメタデータを強制する場合、準拠に失敗したトランザクションは、ブロックチェーン上へトランザクション処理されることを禁止されるか、あるいはブロックチェーンに書き込まれた場合、トランザクションはメインチェーン上のブロックに決して受け入れられず、なぜならば、スマートコントラクト検証失敗は、トランザクションが受け入れの合意に達することを妨げるためである。

【0425】

したがって、説明されたＧＵＩの使用により、プログラミング及びプログラム開発の専門知識を欠くビジネスユーザがそれにもかかわらず新しいアプリケーションを宣言し、新しいエンティティ名を宣言すると共に、それらのエンティティ名のための新しいフィールド定義を宣言的に作成することが可能である。より多くの技術的な専門知識を有する人については、彼らがそのようにすることが望ましい場合、ＡＰＩを利用してブロックチェーンのメタデータ定義マネージャ１９６と相互作用することができる。

【0426】

選択された方法にかかわらず、ブロックチェーン管理者は、新しいアプリケーション、新しいエンティティ、及び新しいフィールド定義を、全てコードを全く書くことなく宣言的に作成することができ、次いで、ブロックチェーンメタデータ定義マネージャ１９６は、新しいアプリケーション、新しいエンティティ、及び／又は新しいフィールド定義のために定義されたメタデータを投票及び合意のためにブロックチェーン上へトランザクション処理する。

【0427】

合意が達せられるまで、定義されたメタデータは利用できない。しかしながら、ひとたびブロックチェーン上へトランザクション処理され、合意が達せられると、ブロックチェーン上の他の参加ノード又は参加者は、宣言されたアプリケーションの全てのデータと相互作用することができ、ブロックチェーンサービスインターフェース１９０によるスマートコントラクト実行は、これらの相互作用との準拠を強制し、あるいは義務付ける。

【0428】

図８Ｆは、説明される実施形態による別の例示的なアーキテクチャ８０６を示す。

【0429】

ここで示されるのは、アプリケーションを定義し、エンティティを宣言し、様々な定義されたフィールドを宣言するために、ブロックチェーン管理者の宣言型アクションのために作成された生成コードであり、結果として、ブロックチェーン管理者によりコードが書かれていないにもかかわらず、ＡＰＩ準拠コードが定義されたメタデータ内に表現される。他の実施形態において、プログラマ又は開発者は、このコードを生成するためにＡＰＩを利用することを選択してもよく、その場合、ＧＵＩは、コード化されたエンティティ及びコード化された定義されたフィールドを、それらが元々ＧＵＩを介して宣言されたかのように反映することになる。

【0430】

したがって、開示されたプラットフォームは、ブロックチェーンとの間でトランザクション処理し、ブロックチェーンと相互作用し、アプリケーション及びそのアプリケーションのためのエンティティを定義及び宣言し（これは、以下で論じられるようにマテリアライズドビューを介してデータベースシステム内のテーブルとして示され得る）、さらに、各エンティティのための新しいフィールド定義を定義及び宣言し、さらに、宣言されたアプリケーションを利用することができる許容可能なネットワーク参加者を定義するための必要なコードの作成を可能にする。

【0431】

このような方法で、宣言型メタデータプラットフォームは、ブロックチェーン管理者のために全ての重労働を実行し、非プログラマは、一連のＧＵＩを通じてのポイント及びクリック動作のみを用いることにより、新たに宣言されたアプリケーションのためにブロックチェーンと相互作用するための全ての必要なコードを作成することができる。

【0432】

さらに、アプリケーションの構成、及び許可されたネットワーク参加者、並びに新しい宣言型エンティティ及び新しい宣言型フィールド定義は、ブロックチェーン管理者になじみのある方法で提示され、なぜならば、様々な要素が、データベースエントリ及びデータベーステーブルが作成されていない事実にもかかわらず、データベーステーブル、列、フィールド、及びレコード等として考えられ得るためである。その代わりに、情報は、資産としてブロックチェーン上へトランザクション処理され、一方、ブロックチェーン管理者は、基礎をなすブロックチェーンに対してトランザクション処理する方法、又はブロックチェーン上の資産を追加及び更新又は移転する方法をブロックチェーン管理者が理解する知識又は要件なく、プロセス全体を通じてそれらの方法をポイント及びクリックすることができる。したがって、開示された実施形態の実施は、ブロックチェーン管理者として運用する非プログラマユーザの側の複雑さを大幅に低減する。

【0433】

それにもかかわらず、ブロックチェーンのプログラミング知識及び理解を有するより洗練されたユーザについては、同じコードが、ホスト組織により提供されるブロックチェーンサービスインターフェース１９０、具体的にはブロックチェーンメタデータ定義マネージャ１９６により公開されたＡＰＩを介して書き込まれ、生成されてもよい。

【0434】

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

【0435】

ここに示すように、ブロックチェーン管理者は、定義されたメタデータ９１０をブロックチェーン上へトランザクション処理し、これは推定上、ひとたび合意が達せられると受け入れられ、次に、パートナーユーザが、メタデータ準拠トランザクション９１５をブロックチェーン上へトランザクション処理する。

【0436】

さらにここで示されるのは、マテリアライズドビュー９２０であり、これは、ホスト組織ユーザ９２５が、ホスト組織１１０を介して利用可能なアクセス可能クラウドプラットフォーム１８６から、メタデータ準拠トランザクション９１５を介してブロックチェーン上へトランザクション処理されたデータと相互作用することを可能にする。

【0437】

コンピューティングにおいて、マテリアライズドビュー９２０は、クエリの結果を含むデータベースオブジェクトである。例えば、マテリアライズドビュー９２０は、リモートに位置するデータのローカルコピーでもよく、あるいはテーブル又はｊｏｉｎ結果の行及び／又は列のサブセットでもよく、あるいは集約関数を使用するサマリでもよい。

【0438】

マテリアライズドビューを設定するプロセスは、時にマテリアライゼーション（materialization）と呼ばれる。意味上、データマテリアライゼーションは、クエリの結果をキャッシュする形式であり、データベース管理者が最適化の目的のためにパフォーマンスの理由でマテリアライズドビューを活用する他の形式の事前計算と同様である。

【0439】

関係モデルに従うデータベース管理システムにおいて、ビューは、データベースクエリの結果を表す仮想テーブルである。クエリ又は更新が、通常のビューの仮想テーブルをアドレス指定するときはいつでも、ＤＢＭＳはこれらを、基礎をなすベーステーブルに対するクエリ又は更新にコンバートする。

【0440】

反対に、マテリアライズドビューは異なるアプローチをとり、その結果、クエリ結果は、元のベーステーブルとは別個に更新され得る具体的な（「マテリアライズド（materialized）」）テーブルとしてキャッシュされる。このようなアプローチは、付加的な記憶と、いくらかのデータが潜在的に古いことを犠牲にして、より効率的なアクセスを可能にする。マテリアライズドビューは、特にデータウェアハウスのシナリオで使用され、これにおいて、実際のベーステーブルの頻繁なクエリは高価になる可能性がある。

【0441】

ここに示す例では、アクセス可能クラウドプラットフォーム１８６は、一般に、ホスト組織１１０のデータベース１３０内に記憶された情報を利用するが、特定の情報がブロックチェーンに対してトランザクション処理され、したがってブロックチェーンに永続化される場合、マテリアライズドビューは、アクセス可能クラウドプラットフォーム１８６がマテリアライズドビュー９２０を介してブロックチェーンにより記憶されたデータと相互作用することを可能にする。このような方法で、ホスト組織ユーザ９２５及びアクセス可能クラウドプラットフォームの双方が、単にマテリアライズドビューを参照することにより、それがホスト組織のデータベース１３０内に記憶されたデータであるかのようにブロックチェーンデータと相互作用することができる。

【0442】

したがって、特定の実施形態によれば、情報がブロックチェーンに対してトランザクション処理されるときはいつでも、スマートコントラクトが、ブロックチェーン上へトランザクション処理されたデータの検証スキームをトリガ及び実行して、それが定義されたメタデータ９１０に準拠していることを保証し、スマートコントラクトはさらに、マテリアライズドビュー９２０を生成してホスト組織１１０のデータベース１３０内に参照可能なコピーを作成し、したがって、ホスト組織の標準クエリインターフェースはマテリアライズドビュー内の情報を参照することがき、これは次に、ブロックチェーン上へトランザクション処理された情報に対応する。

【0443】

したがって、ブロックチェーンのために宣言及び作成されるエンティティであって、それのためにデータがブロックチェーン上へ書き込まれ又はトランザクション処理される、エンティティは、マテリアライズドビュー内に、ホスト組織１１０のデータベース内に作成された同等のエンティティ（例えば、関係データベース内のテーブル）を自動的に有し、定義されたフィールドがブロックチェーン上へ作成され、受け入れられたとき、次いで、それらの対応する列がホスト組織データベースシステム１３０内に作成され、次いで、データがブロックチェーン上へトランザクション処理されると、ホスト組織のデータベースシステム１３０内のその対応するエンティティテーブルがマテリアライズドビュー内に投入され、それにより、ホスト組織の側からのデータと相互作用するユーザ及びプロセスは、マテリアライズドビューからの情報にアクセスすることができる。

【0444】

結果的に、開発者とユーザは、彼らが実際にはブロックチェーンを利用しているという知識なしに、また、そのようなユーザがブロックチェーンと相互作用する方法について何らかの知識を有しているという要件なしに、ブロックチェーンに永続化されたデータ及び定義されたメタデータを利用する宣言されたアプリケーションと相互作用することができる。

【0445】

特定の実施形態によれば、ホスト組織のデータベース１３０内に新しいテーブルは作成されず、したがって、ホスト組織のデータベース１３０とブロックチェーンとの間でデータを同期させることは必要ない。むしろ、ホストから外部のブロックチェーンにより永続化されたデータのチャネル、パイプライン、又はビューは、ホスト組織のデータベース１３０においてマテリアライズドビューを介して表現されるが、マテリアライズドビューは、参照可能であるが、ブロックチェーンに戻すように同期されるコピーではなく、更新又は修正を許可しない。マテリアライズドビューは、ホスト組織のデータベース１３０からの読取専用の参照に対してのみ許容される。全ての修正、更新、変更等は、ブロックチェーン上へトランザクション処理されなければならず、リフレッシュされたマテリアライズドビューは、次いで、それらの変更をブロックチェーンからプルし、それらの修正をデータベース１３０において反映する。そのような構成はさらなるオーバーヘッドを生じるが、この構成はマテリアライズドビュー内のデータを同期化する必要を明示的に否定し、なぜならば、そのようなデータは完全に非正式であるためである。

【0446】

結果的に、開発者、プログラム、プロセス、及びユーザは、マテリアライズドビュー９２０を参照することにより、ブロックチェーンデータと相互作用するために標準ＳＱＬクエリを利用することができる。例えば、ＳＥＬＥＣＴ ｆｒｏｍ ＄Ｔａｂｌｅ＿Ｎａｍｅ ＷＨＥＲＥ．．．を指定することは、エンティティ名をマテリアライズドビュー９２０のテーブル名として指定するとき、結果として、データの正式なコピーがブロックチェーン自体の中に存在するという事実にもかかわらず、データベースクエリ結果がホスト組織のデータベース１３０により返されることになる。この構造はいくつかの重複データを作成し、したがっておそらく無駄な記憶を結果としてもたらすが、この構造は、標準ＳＱＬを利用し得るアクセス可能クラウドプラットフォーム１８６のいずれかから発生するクエリを大幅に簡素化するという利点を有し、データを取り出すためにブロックチェーンを識別し、又はより複雑なブロックチェーントランザクションを構築する必要はなく、なぜならば、マテリアライズドビュー９２０へのデータの複製が、スマートコントラクトトリガにより自動的に実行されるためである。そのような実施形態によれば、レコードを更新、作成、又は削除するＳＱＬコマンドは、マテリアライズドビューに対する実行については許可されないが、レコードを更新、作成、又は削除するそのようなＳＱＬコマンドは、ａｐｅｘ翻訳エンジン及びＡｐｅｘコードインターフェース４５４（図４Ｂに示される）に受け入れられ、ＳＱＬ更新、作成、又は削除コマンドの同等のアクションを実行するためのネイティブブロックチェーン実行可能準拠コードに翻訳されるが、これは次いで、ブロックチェーントランザクションとして、ブロックチェーンに対してトランザクション処理され、同意のためにサブミットされ、次いで、投票又は合意が成功であると仮定するとブロックチェーン上に受け入れられる。さらに、スマートコントラクトは、ブロックチェーンで永続化される定義されたメタデータへのデータ準拠を強制するために、ブロックチェーンに対するトランザクションを検証するために実行されることに留意する。

【0447】

例えば、ホスト組織ユーザからサブミットされたＳＱＬクエリは、指定されたアプリケーションの顧客レコードＪｏｈｎ Ｄｏｅの更新を要求することができる。このような情報はブロックチェーンで永続化されるため、ＳＱＬはホスト組織のデータベースシステム１３０に対して実行することができない。さらに、ブロックチェーンは、「顧客レコードＪｏｈｎ Ｄｏｅの全てのデータを返してください」と要求するＳＱＬクエリを受け入れない。ブロックチェーン上の情報は人間が読めるものではなく、また、この種類のクエリを許可しない。

【0448】

結果的に、Ａｐｅｘコードインターフェース４５４は、指定されたアプリケーションの顧客レコードＪｏｈｎ Ｄｏｅについてブロックチェーン上へ更新されたペイロードデータをトランザクション処理するために、受信したＳＱＬコードをネイティブブロックチェーンコードに翻訳する。これが発生すると、顧客レコードＪｏｈｎ Ｄｏｅの最も新しいかつ最新の情報は、次に、最も最新の情報としてブロックチェーンに、また、同じデータのマテリアライズドビューにも反映されるが、顧客レコードＪｏｈｎ Ｄｏｅの古い情報は、ブロックチェーンレコードが不変であるためブロックチェーン内にとどまり、ゆえに、いつでも参照できる不変の監査証跡が作成される。したがって、このようなデータへのアクセス権を有する当事者は、ブロックチェーンの前のブロックを振り返って、顧客レコードＪｏｈｎ Ｄｏｅについてどんな情報が前に記録されたかを決定することができ、あるいは、顧客レコードＪｏｈｎ Ｄｏｅが削除されている場合、このような変更はブロックチェーンにより再び反映されるが、古いレコード自体はブロックチェーンの前のブロック内に不変にとどまる。ただし、アプリケーションは、このような情報が「削除された」として示されていることを理解し、したがって、削除されたレコードは、ライブカレントデータとして参照されないが、それは、ＤＬＴブロックチェーン技術の固有の設計により常に利用可能なままである。

【0449】

代替的な実施形態において、Ａｐｅｘコードインターフェース４５４（図４Ｂに示される）は、ＳＱＬデータベースクエリをネイティブブロックチェーンプロトコルに翻訳するために利用され、翻訳されたＳＱＬクエリが次いでブロックチェーンに対して実行され、結果セットを生成することを可能にし、それは次いで、ＳＱＬ準拠のフォーマットに戻すように翻訳され、ＳＱＬクエリに応答して返される。さらに他の実施形態において、スマートコントラクトエンジンは、ブロックチェーンに対してトランザクションを実行して、定義されたエンティティ及び定義されたフィールドを取り出し、それらをマテリアライズドビューに翻訳し、これは次いで、ホスト組織データベースシステム１３０内に記憶され、その後、翻訳されていないＳＱＬクエリを実行して、ブロックチェーンデータをマテリアライズドビューから直接取り出すことができる。

【0450】

アプリケーション自体は、宣言されたエンティティ及びそれらのエンティティのための宣言された定義されたフィールドと同様に宣言的であるため、全てのデータ構成は完全にカスタマイズ可能であり、ビジネスの特定のニーズに合わせることができ、ブロックチェーン上で、その特定のブロックチェーン上で動作するネットワーク参加者又は参加ノードによる合意を受けるのみである。

【0451】

図９Ｂは、説明される実施形態による別の例示的なアーキテクチャ９０２を示す。

【0452】

ここに示されるように、定義されたメタデータ９１０はここで、要素９１１で示されるようにブロックチェーンにデプロイされている。結果的に、宣言的に定義されたアプリケーション、そのエンティティ、及びフィールド定義は今や、任意の認可されたネットワーク参加者により利用することができる。多くの状況において、認可されたネットワーク参加者は、ホスト組織１１０の様々なクラウドサービスへのアクセス権を有するホスト組織ユーザ９２５であり、したがって、ホストされたアプリケーション９２０は、ひとたびブロックチェーンにデプロイされると使用のために顧客に公開される。

【0453】

しかしながら、特定の状況では、パートナーユーザが認可されたネットワーク参加者としてソフトウェアにアクセスする必要がある。問題として、ネットワーク参加者として認可され、したがって宣言されたアプリケーションと相互作用するためのパーミッションを付与されたこのようなパートナーユーザは、必ずしもホスト組織の顧客ではなく、それらにホスト組織のサブスクライブ顧客になるよう強制することは、望ましくない場合がある。

【0454】

宣言されたアプリケーションをホスト組織の非顧客による使用のためにデプロイするためには、特定の実施形態によれば２つの要件がある。第１に、ブロックチェーン管理者は、許容されるネットワーク参加者を定義しなければならず、これは、特定の実施形態によれば、それらのネットワーク参加者のインターネットプロトコル（ＩＰ）アドレスを定義することにより行われてもよい。ＩＰアドレスは、ＩＰにより識別されるホスト組織ユーザに対応することができ、あるいは、ネットワーク参加者が、再びＩＰにより識別されるホスト組織の非顧客でもよい。このような方法で、許容される方法でアプリケーションにアクセスし、アプリケーションを利用することができるブロックチェーン上の参加ノードは、それらがその特定のアプリケーションに対する追加されたネットワーク参加者としてブロックチェーン管理者により定義されたＩＰアドレスにより正しく識別可能であると仮定して、識別することができ、互いに通信し、互いとデータを共有することができる。

【0455】

特定の実施形態において、追加されたネットワーク参加者の一部又は全部は、ホスト組織の非ユーザ又は非サブスクライバであり、したがって、それらはホスト組織で認証することができず、したがって、認証クレデンシャルを介してホスト組織に対してそれら自身の身元を明らかにすることができない。したがって、そのような実施形態によれば、ホスト組織の非顧客であり、かつホスト組織の非顧客であるが許容されるネットワーク参加者（ブロックチェーン管理者により定義される）としてアプリケーションを利用することを望む識別されたネットワーク参加者は、２段階の認証プロセスを進む。第１に、それらは、追加されるネットワーク参加者に対応しなければならないそれらのＩＰを提供しなければならない。次いで、非顧客はチャレンジを提示され、これに応答して、それらは公開鍵を返す必要がある。非顧客は、事前にブロックチェーン管理者により公開鍵を与えられ、それにより、それらは認証チャレンジを成功裏に通過することができる。

【0456】

ひとたび非顧客がそれらのＩＰを提供し、公開鍵でチャレンジに応答すると、その公開鍵は、その非顧客がブロックチェーン上の参加ノード間の信頼をネゴシエートするために宣言されたアプリケーションを利用しようと試みるたび、利用される。

【0457】

したがって、特定の実施形態によれば、デプロイ可能インストールパッケージ９２５がパートナーユーザに送信され、これにおいて、デプロイ可能インストールパッケージ９２５は、非顧客のためのソフトウェアを実行し、それらが宣言されたアプリケーションにアクセスすることを可能にする。

【0458】

特定の実施形態によれば、デプロイ可能インストールパッケージ９２５は、宣言されたアプリケーションの機能を含まない汎用ソフトウェアパッケージであるが、むしろ、ホスト組織のブロックチェーンサービスインターフェースにアクセスするための非顧客パートナー組織を提供し、それにより、非顧客パートナーｏｒｇは次いで、その特定の非顧客パートナーｏｒｇが認可されたネットワーク参加者として追加された宣言されたアプリケーションの使用を通して、ホスト組織を通してブロックチェーンとの間でトランザクション処理することができる。

【0459】

そのような実施形態によれば、汎用的なデプロイ可能インストールパッケージ９２５は、ひとたびインストール及び実行されると、共有公開鍵について非顧客パートナー組織に促し（prompt）、これは、その特定の宣言されたアプリケーションのための認可されたネットワーク参加者として非顧客パートナーｏｒｇを追加したブロックチェーン管理者により、それらに対して別個に送信される。

【0460】

一実施形態によれば、デプロイ可能インストールパッケージ９２５は、非顧客パートナー組織を認可されたネットワーク参加者として追加するとき、宣言されたアプリケーションのためのメタデータの一部としてブロックチェーン管理者により構成されている、非顧客パートナー組織のＩＰアドレスに基づいてチャレンジを発行する。

【0461】

したがって、同一の汎用デプロイ可能インストールパッケージ９２５は、それがどこで実行されるかに基づいて別様に動作する。デプロイ可能インストールパッケージ９２５が、認可されたネットワーク参加者に対して構成されたＩＰに対する範囲内でないか又は対応しないＩＰアドレスを有するシステムから実行される場合、デプロイ可能インストールパッケージ９２５は実行されると、そのＩＰアドレスに関連づけられた場所が宣言されたアプリケーションに対して認可されたネットワーク参加者ではないことを単に示す。

【0462】

同一のデプロイ可能インストールパッケージ９２５が、異なる宣言されたアプリケーションに対して認可されたネットワーク参加者である、異なる人に送信される場合、デプロイ可能インストールパッケージ９２５は実行されると、ユーザにその異なる宣言されたアプリケーションのための共有公開鍵を入力するよう促し、したがって、正しい共有公開鍵が提供されることと、デプロイ可能インストールパッケージ９２５が認可されたネットワーク参加者に対応するものとしてすでに構成されているＩＰアドレスから実行されることの双方を必要とする。

【0463】

このような方法で、デプロイ可能インストールパッケージ９２５は、共有され、配布され、又はホスト組織のサポートページを介して公開さえされ得、いかなる非認可ユーザも、それらがＩＰをなりすますこと及びチャレンジに応答して正しい共有公開鍵を提供することの双方をなし得ないかぎり、問題の宣言されたアプリケーションに対して承諾されることはない。

【0464】

特定の実施形態において、ユーザベースの認証チャレンジが既知のユーザに対してさらに提供されてもよく、そのようなユーザ又はユーザに関連づけられた非顧客パートナー組織がホスト組織からのサービスをサブスクライブすることは必要ない。

【0465】

宣言されたアプリケーションのユーザは、ＡＰＩを利用して宣言されたアプリケーションと相互作用し、したがって宣言されたアプリケーションを通じて間接的にブロックチェーンと相互作用することができるが、ユーザがそのようにすることは必要ではない。

【0466】

むしろ、特定の実施形態によれば、デプロイ可能インストールパッケージ９２５は、デプロイ可能インストールパッケージ９２５の実行者が認可されたネットワーク参加者である宣言されたアプリケーションのためにブロックチェーンに永続化されたメタデータから動的に生成されるＵＩを提供する。

【0467】

したがって、デプロイ可能インストールパッケージ９２５がアプリケーション特有のＵＩを有することは必要ではない。むしろ、宣言されたアプリケーションに必要とされるＧＵＩ、ＡＰＩ、又はＵＩは、宣言されたアプリケーションのために関連づけられたメタデータに基づいてデプロイ可能インストールパッケージ９２５により動的に構築される。

【0468】

このようにして、ホスト組織からサービスを全くサブスクライブしない非顧客パートナー組織は、それにもかかわらず、ホスト組織のブロックチェーンサービスインターフェースを（宣言されたアプリケーションを通じて）利用し、ホスト組織のブロックチェーンサービスインターフェースを通じてアクセス可能にされているブロックチェーン上のデータを利用し、相互作用し、記憶することができる。

【0469】

特定の実施形態によれば、ひとたびデプロイ可能インストールパッケージ９２５が実行されると、ユーザは、初期チャレンジに応答してユーザにより提供された公開鍵を関連づける、動的に構築されたＵＩを通して宣言されたアプリケーションで認証し、次いで、任意の定義されたエンティティ及び任意の定義されたフィールド定義を含む宣言されたアプリケーションの定義されたメタデータに基づいて、ＧＵＩ表示画面を生成することに進み、これを介してホスト組織の非顧客は、ブロックチェーン上へトランザクション処理されるデータを入力し、そのようなデータをブロックチェーン上で更新し、ブロックチェーンからのデータを取り出すことができ、これには、別の組織によりブロックチェーンに書き込まれたデータであるが、宣言されたアプリケーションに関連づけられたデータがその別の組織と共有されている、データが含まれ、したがって、新しい宣言されたアプリケーションを利用する全ての認可されたネットワーク参加者に対して、ブロックチェーン上のデータの共通のコレクションを形成する。

【0470】

したがって、ＧＵＩは、ブロックチェーン管理者がアプリケーションを定義し、エンティティを定義し、それらのエンティティの各々についてのフィールドを定義し、許容可能なネットワーク参加者を定義することを可能にし、次いで、ホスト組織ユーザと非顧客ユーザの双方が、全ての宣言型メタデータがブロックチェーン内に存在するホストされたソフトウェアにアクセスすることを可能にする。そのようなブロックチェーンは、ブロックチェーンがホスト組織にとってアクセス可能である限り、完全にホスト組織の外部で、またホスト組織の制御外でさえも動作することができる。代替的な実施形態において、宣言型メタデータは修正ＤＬＴ内に存在し、これはホスト組織の内部で運用され、また、これについてホスト組織は単一の中央集権的信頼オーソリティである。

【0471】

宣言型メタデータが、ここに示されるブロックチェーン９９９などのホスト組織外のアクセス可能ブロックチェーン上にホストされる場合、宣言されたアプリケーションは、資産からペイロードデータを取り出す、資産を更新する、資産を作成する等を行うために、ブロックチェーンとの間でトランザクション処理することによりブロックチェーン上の情報と相互作用する。

【0472】

しかしながら、注目すべきことに、データの正式なコピーは、アクセス可能なブロックチェーン９９９上でホスト組織の外部にホストされ、ホスト組織のデータベース１３０内のいかなるテーブルによっても記憶されていない。上記で論じられたマテリアライズドビューは任意の機能であるが、使用されるとしても、マテリアライズドビュー内の情報は正式なコピーではない。アプリケーションに関連づけられたデータに修正を行うトランザクションは、定義されたメタデータに準拠しなければならないだけでなく、ブロックチェーン９９９で更新もされなければならない。修正されたＤＬＴが内部で運用される場合、アプリケーションに関連づけられたデータは、正式なソースとして修正されたＤＬＴ内で更新されなければならない。したがって、このようなアプリケーションデータは、データの最終的な正式コピーとしてアクセス可能なブロックチェーン９９９により永続化される。したがって、マテリアライズドビューが削除又は破壊され、あるいはアクセス可能ブロックチェーンと同期しなくなったとしても、宣言されたアプリケーションの動作に対する影響はなく、なぜならば、そのアプリケーションのためのデータ及び構造を定義するメタデータ並びにそのようなデータは、アクセス可能なブロックチェーン９９９により記憶されるためである。

【0473】

図９Ｃは、説明される実施形態による別の例示的なアーキテクチャ９０３を示す。

【0474】

ここに示されるように、ブロックチェーンサービスインターフェース１９０内にイベントリスナ９６０があり、これは、ブロックチェーン管理者から定義されたトリガ９６１を受け入れ、次いで、ブロックチェーン上で発生する指定されたイベントをリッスンするように動作し、これに応答して、イベントがトリガ又は始動され、ここではトリガされたイベント９６２として示され、ホスト組織にトランザクションをプッシュし、あるいはブロックチェーン管理者により指定されたフロー若しくはデータ処理フロー又は任意の定義された動作の実行を開始する。これは、定義されたメタデータへのデータ準拠を強制するためにスマートコントラクト実行を自動的にトリガするために利用されるものと同様のメカニズムであるが、イベントリスナ及び定義されたトリガ９６１は、スマートコントラクト実行により実行される動作にかかわらず、発生すべき実行可能動作をそれらの独自のカスタマイズされた基準に基づいてブロックチェーン管理者が定義することを可能にする。

【0475】

したがって、特定の実施形態によれば、何らかの変更がアクセス可能ブロックチェーン内で生じ、イベントリスナ９６０に所有されている定義されたトリガ９６１に一致するときはいつでも、イベントリスナは、アクセス可能クラウドプラットフォーム１８６内へ戻すように１つ又は複数のイベントを始動させ（トリガされたイベント９６２）、ブロックチェーン管理者は、任意の種類のフローを、ブロックチェーンサービスインターフェース１９０へのＡＰＩを介してサブミットされるコードを介して、又はＧＵＩを介して（例えば、統合ビルダ及び関連ＧＵＩを介して）書き込むことができ、これにより、ブロックチェーン管理者はフローを作成し、例えば、実行されるスマートコントラクト、又はブロックチェーン管理者により定義される何らかの他のフローを作成することができ、次いで、そのフローは、イベントリスナ９６０により監視されるブロックチェーン上で生じた変更に応答して、トリガされたイベント９６２により定義されたとおりアクセス可能クラウドプラットフォーム１８６内での更新を引き起こす。一実施形態によれば、データベーストランザクションが、トリガされたイベント９６２に応答してホスト組織のデータベース１３０内で、又はアクセス可能クラウドプラットフォーム内で実行される。別の実施形態において、ＧＵＩがトリガされ、ユーザクライアントデバイスにプッシュされて、イベントリスナ９６０により監視されるブロックチェーン内で発生した変更に基づく情報を提示する。

【0476】

図１０は、読み取りに関する合意（consensus on read）のためのプロセスの一実施形態のフローチャートである。このプロセスは、ブロックチェーンサービスインターフェース１９０のブロック合意マネージャ１９１又は同様のコンポーネントにより実現することができる。読み取りに関する合意プロセスは、ブロックチェーン内のデータにアクセスしてそのデータを読み取ろうとしているブロックチェーンネットワーク内のノード１３３によりトリガすることができ、これにおいて、データは、該データへのアクセスを制御するパーミッションスキーム又は同様のメカニズムにより保護されている。このプロセスは、ブロックチェーンサービスインターフェース１９０内のアクセス制御層１６２とは別個である。アクセスされるデータが、読み取りに関する合意プロセスにより管理されている場合、読み取りに関する合意プロセスは、要求ノードが暗号化により保護されているブロックチェーンからのデータにアクセスできるように満たされなければならない。ブロックチェーン内のデータを読み取る要求は、任意のレベルの粒度を有することができ、これにおいて、ブロックチェーン内のフィールド、レコード、メタデータ、又は同様のデータは、このプロセスにより別個に保護することができる。

【0477】

データが読み取りのアクセスを制限したブロックチェーンに最初記憶されるとき、トランザクションはブロックチェーンサービスインターフェース１９０により受信される（ブロック１００１）。ブロックチェーン合意マネージャ１９１は、ブロックチェーンネットワークの合意プロトコルに従って、トランザクションがブロックチェーンに確認されるかどうかを決定する。トランザクションがコミットされる場合、ブロックチェーン合意マネージャ１９１は、記憶されるデータを暗号化するための鍵を生成する（ブロック１００３）。鍵は、データを暗号化するために利用され、さらに、鍵は、データを復号してそれにアクセスするために復元され、利用される。暗号化のための鍵は、共有秘密（shared secrets）のセットに変換される（ブロック１００５）。鍵をブロックチェーンネットワークにおける合意に参加するノードの数に等しい数の共有秘密のセットに変換することができる、任意の秘密共有プロセス又はプロトコルを利用することができる（例えば、Ｓｈａｍｉｒの秘密共有アルゴリズム）。同様に、所望の閾値又は構成可能な閾値を有する任意の秘密共有アルゴリズムを選択して、共有秘密を生成することができる。このような共有秘密アルゴリズムを使用することにより、復号に必要とされる鍵を再構成するためにブロックチェーンネットワーク内の他のノードにより閾値数の共有秘密が提供されている場合にのみデータにアクセスできることを保証する。閾値は、固定又は構成可能とすることができる。閾値は、参加ノードの数の半分又は３分の２に等しい数などの、任意の値とすることができる。

【0478】

各共有秘密が、秘密共有アルゴリズムにより生成されるとき、ブロックチェーンネットワーク内の特定のノードに対して指定された共有秘密は、そのノードの公開鍵を使用して暗号化される（ブロック１００７）。したがって、関連するノードのみが、それに割り当てられた共有秘密を復号し、読み取りに関する合意プロセスの一部として承諾された読み取り要求の場合にそれを提供することができる。これらの暗号化された共有秘密は、ブロックチェーンにトランザクションをコミットするための合意に基づいて、関連するトランザクションデータのメタデータとして記憶される（ブロック１００９）。

【0479】

その後、保護されたデータがブロックチェーンに記憶された後、保護されたデータにアクセスする要求にサービス提供しようとする任意のノード（ブロック１０１１）は、ブロックチェーンネットワークの他のノードにブロードキャストされる読み取り要求を開始しなければならない。この読み取り要求は、アクセスされるデータを識別し、データにアクセスすることを要求しているノード又はエンティティに関する情報（例えば、エンティティのためのクレデンシャルのセット）を含んでもよい（ブロック１０１３）。次いで、ノードの各々は、その読み取りに関する合意プロセスを実行し、要求されたデータにアクセスするためのクレデンシャル又は他の基準が満たされているかどうかの決定を行う。データを読み取るための基準が満たされていると決定した各ノードは、その共有秘密を要求ノードに提供する（ブロック１０１５）。要求ノードは、共有秘密を収集し、定義された閾値数の共有秘密が提供されたかどうかを決定することができる（ブロック１０１７）。閾値数の共有秘密が返されない場合、読み取りに関する合意プロセスは読み取り要求を拒否し、それは完了できない（ブロック１０１９）。いくつかの実施形態において、読み取りに関する合意プロセスは、プロセスが閾値数の共有秘密を受信しなければならない時間制限又はウィンドウを有することができる。閾値数の共有秘密が他のノードにより提供された場合、要求ノードは、共有秘密アルゴリズムを利用して、共有秘密を、要求されたデータを暗号化するために使用された鍵に変換することができ、次いで、要求されたデータは復号され、アクセスされ得る（ブロック１０２１）。データがアクセスされた後、要求ノードは鍵を破棄することができ、それにより、それは後のアクセスで再度要求及び再形成される必要があることになる。

【0480】

最初のトランザクションからの暗号化されたデータがブロックチェーンに記憶されるとき、ブロックチェーンネットワーク内の各ノードの共有秘密を含む関連メタデータもブロックチェーンに記憶される。メタデータフォーマットは、他の開示される実施形態に関連して本明細書で詳述されるように定義され、構成され得る。メタデータは、共有秘密、トランザクションデータの所有者、トランザクションデータに関連づけられたアクセス制御のためのパーミッション又は特権、トランザクションデータに関連するプライバシー情報、トランザクションデータの所有者情報、及び同様の情報を識別することができる。メタデータは、トランザクションのこれらの属性を、トランザクションデータのフォーマットと一貫性のあるオブジェクト、レコード、フィールド、又は同様のコンポーネントレベルで定義することができる。トランザクションデータの所有者は、ブロックチェーンネットワーク上で動作し、ブロックチェーンネットワークを利用するユーザ、ノード、又は同様のエンティティとすることができる。アクセス制御プロセス及び忘れる権利プロセスについてのさらなる実施形態が本明細書で以下に定義され、これらは、読み取りに関する合意プロセスの原理と共にこのさらなる詳細なメタデータを利用する。

【0481】

図１１Ａ～図１１Ｃは、ブロックチェーンサービスインターフェース１９０内で忘れる権利（right to forget）機能を実施するためのプロセスのセットに関連するフローチャートである。忘れる権利機能は、読み取りに関する合意プロセスの態様を利用して、エンティティがデータをプライベートデータとして指定し、エンティティの要求に基づいてプライベートであるデータをブロックチェーンに「忘れ」させることを可能にする。この機能性は、忘れる権利機能を実現するブロックチェーンがＧＤＰＲに準拠できるようにするのに役立つことができる。図１１Ａ～図１１Ｃのフローチャートは、忘れる権利プロセスの３つの関連する態様、すなわち、プライベート情報又はＰＩ情報とも呼ばれるプライベートデータの初期記憶、データが「忘れられる」ことの要求、及びアクセス要求を説明している。これらの機能は一緒に、データに再度アクセスできないことを保証するために、制御エンティティの要求に基づいてプライベートデータを暗号化し、次いで暗号化鍵を削除することにより、ブロックチェーンがデータを「忘れる」能力を提供し、したがって、忘れる権利機能は、データをブロックチェーンにより「忘れられる」ものとして効果的に指定することができ、なぜならば、それはその後、データがブロックチェーン上に暗号化された形式で存在していても、アクセスすることはできないためである。

【0482】

図１１Ａにおいて、忘れる権利プロセスは、ブロックチェーンインターフェースでブロックチェーンに記憶されるべきトランザクションを受信するノードにより開始され、これにおいて、トランザクションは、このデータに関連づけられたエンティティに対する一意ユーザ識別子（ＵＵＩＤ）を含む（ブロック１１０１）。さらに、受信したトランザクションには、プライベートと指定されるべきデータの態様のインジケータが含まれる。データの全体、又は任意のレベルの粒度におけるデータの任意の態様をプライベートと指定することができ、例えば、データ及び／又はメタデータのオブジェクト、レコード、フィールドである。ブロックチェーン内のノードの合意に基づいて、トランザクションがブロックチェーンにコミットされたと決定されると、トランザクションデータのためのオブジェクト及びメタデータフォーマットが決定され、これは、ブロックチェーン上にデータを記憶するために利用され、これにおいて、オブジェクト及びメタデータは、所有エンティティＵＵＩＤ又は同様の識別子と、プライベートとして指定されるデータのオブジェクト、レコード、フィールド、又は同様のコンポーネントを識別するためのインジケータのセットを含むことになる（ブロック１１０３）。

【0483】

ブロックチェーン合意マネージャ１９１又はパーミッションマネージャは、記憶されるデータを暗号化するための鍵を生成する（ブロック１１０５）。データを暗号化するために利用される鍵は、データを復号してそれにアクセスするために利用されることになる。次いで、鍵は、共有秘密のセットに変換される（ブロック１１０７）。鍵をブロックチェーンネットワークにおける合意に参加するノードの数に等しい数の共有秘密のセットに変換することができる、任意の秘密共有プロセス又はプロトコルを利用することができる（例えば、Ｓｈａｍｉｒの秘密共有アルゴリズム）。同様に、所望の閾値又は構成可能な閾値を有する秘密共有アルゴリズムを選択して、共有秘密を生成することができる。このような共有秘密アルゴリズムを使用することにより、復号に必要とされる鍵を再構成するためにブロックチェーンネットワーク内の他のノードにより閾値数の共有秘密が提供されている場合にのみデータにアクセスできることを保証する。閾値は、固定又は構成可能とすることができる。閾値は、参加ノードの数の半分又は３分の２に等しい数などの、任意の値とすることができる。

【0484】

各共有秘密が、秘密共有アルゴリズムにより生成されるとき、ブロックチェーンネットワーク内の特定のノードに対して指定された共有秘密は、そのノードの公開鍵を使用して暗号化される（ブロック１１０９）。したがって、関連するノードのみが、それに割り当てられた共有秘密を復号し、読み取りに関する合意プロセスの一部として承諾された読み取り要求の場合にそれを提供することができる。これらの暗号化された共有秘密は、ブロックチェーンにトランザクションをコミットするための合意に基づいて、関連するトランザクションデータのメタデータとして記憶される（ブロック１１１１）。

【0485】

図１１Ｂは、ブロックチェーンネットワーク内のプライベートデータを「忘れる」要求にサービス提供するプロセスのフローチャートである。パーミッションマネージャ１８１は、エンティティから、ＵＵＩＤに関連づけられた指定されたデータを忘れる要求を受信する（ブロック１１２１）。パーミッションマネージャ１８１又は関連するコンポーネントは、要求を認証して、十分なクレデンシャルが提示されていることを立証して、要求元が識別されたデータを忘れるプロセスを開始することを認可されていることを保証できる。要求元は、認可を立証するために、セキュリティトークン、パスワード、暗号化鍵、及び／又は同様のクレデンシャルを提示することができる。認証された場合、要求は、ＵＵＩＤ及び／又は忘れられるデータの識別子を追加するように処理される（ブロック１１２３）。プロセスは、ＵＵＩＤに関連づけられた全てのデータ、又は要求により識別される特定のオブジェクト、レコード、フィールドを「忘れる」ように構成することができる。次いで、ＵＵＩＤと任意のデータ識別情報は、「忘れられた」項目のリストに記録することができる。ＵＵＩＤ又はＵＵＩＤに関連づけられた識別された情報に特有の鍵又は共有秘密がある場合、ノードは、このローカル情報を削除することができる（ブロック１１２５）。さらに、ノードは、忘れられたＵＵＩＤ及び／又は情報のリストをブロードキャストし、あるいはブロックチェーン内の他のノードと同様に同期させることもできる。

【0486】

図１１Ｃは、ブロックチェーンネットワーク内の「忘れられた」プライベートデータにアクセスする要求にサービス提供するプロセスのフローチャートである。後に、プライベートデータがブロックチェーンに記憶された後、保護されたデータにアクセスする要求にサービス提供しようとするノード（ブロック１１３１）は、忘れられたＵＵＩＤ／データリストに対する、要求元のＵＵＩＤ及び／又は要求されたデータの識別情報の初期チェックを行う（ブロック１１３３）。ＵＵＩＤ又は要求されたデータが「忘れられた」として列挙されている場合、このデータにアクセスする要求は拒否される（ブロック１１３５）。ＵＵＩＤ又は要求されたデータがリスト上に見つからない場合、パーミッションマネージャ１８１は読み取り要求を開始しなければならず、これは、ブロックチェーンネットワークの他のノードにブロードキャストされ、アクセスされるデータを識別し、データにアクセスすることを要求しているノード又はエンティティに関する情報（すなわち、ＵＵＩＤ、及び可能性として、エンティティのためのクレデンシャルのセット）を含む（ブロック１１３７）。次いで、ノードの各々は、その合意プロセスをプライベート情報のために実行し、要求されたデータにアクセスするためのクレデンシャル又は他の基準が満たされているかどうかの決定を行う。データを読み取るための基準が満たされていると決定した各ノードは、その共有秘密を要求ノードに提供する（ブロック１１３９）。次いで、要求ノードは、共有秘密を収集し、定義された閾値数の共有秘密が提供されたかどうかを決定することができる（ブロック１１４１）。閾値数の共有秘密が返されない場合、合意プロセスは読み取り要求を拒否し、それは完了できない（ブロック１１４３）。いくつかの実施形態において、合意プロセスは、プロセスが閾値数の共有秘密を受信しなければならない時間制限又はウィンドウを有することができる。閾値数の共有秘密が他のノードにより提供された場合、要求ノードは、共有秘密アルゴリズムを利用して共有秘密を鍵に変換することができ、次いで、要求されたデータは復号され、アクセスされ得る（ブロック１１４５）。データがアクセスされた後、要求ノードは鍵を破棄することができ、それにより、それは後のアクセスで再度要求及び再形成される必要があることになる。

【0487】

図１１Ｄは、ＧＤＰＲの一例示的な実装の図である。図１１Ｄの例において、プライベート情報（ＰＩ情報）は、ブロックチェーンに、又は分散ストレージに直接記憶することができる。ブロックチェーンにＰＩ情報を追加しようとするノードは、ＲＥＳＴ ＡＰＩと相互作用してＰＩ情報を作成／更新することができる。ＰＩ情報に関連づけられたメタデータ、すなわちＰＩメタデータは、ブロックチェーンプラットフォームのメタデータＡＰＩを介して定義される。次に、ＲＥＳＴ ＡＰＩは、ＰＩ情報を有するレコードのための鍵の作成と、（図示のような）ブロックチェーンにおける、又は分散ストレージにおけるＰＩＮ情報の記憶を管理する。非ＰＩデータ及びＰＩデータのハッシュは、ＲＥＳＴ ＡＰＩを介してブロックチェーンに記憶することができる。メタデータは、別個のメタデータとして、及び／又は同意及びＧＤＰＲモデルの一部として、メタデータＡＰＩを介してブロックチェーンに記憶することができる。

【0488】

分散ストレージの場合、ＰＩデータのハッシュはブロックチェーンに記憶され、一方、実際のＰＩデータはブロックチェーンから離れて記憶される。オフチェーンの記憶場所におけるＰＩ情報を削除することは、ブロックチェーン内にＰＩ情報のハッシュのみを残す。ハッシュは一方向関数であり、削除されるとＰＩ情報を取り出すために使用することはできない。いくつかの場合、ハッシュは、それをさらに保護するために暗号文と共に記憶することができる。

【0489】

図１２Ａ～図１２Ｃは、ブロックチェーンサービスインターフェース１９０内でアクセス制御機能を実施するプロセスのセットに関連するフローチャートである。アクセス制御機能は、合意上の読み取りプロセスの態様を利用して、エンティティがデータに対するアクセス制御を指定することを可能にし、ブロックチェーンに対する読み取り及び書き込みパーミッションを可能にする。図１２Ａ～図１２Ｃのフローチャートは、アクセス制御の３つの関連する態様、すなわち、パーミッションのセットを有するデータの初期記憶、データに書き込む要求、及びデータの読み取り要求を説明している。これらの機能は一緒に、データを暗号化し、次いでスマートコントラクトを使用してデータへの書き込みを制御しながら、読み取りに関する合意を使用してデータの読み取りを制御することにより、ブロックチェーンがデータに対するアクセス制御を実施する能力を提供する。これらのアクセス制御機能は、許可ありの（すなわち、プライベート）ブロックチェーンとパブリックブロックチェーンの双方に適用可能であり、許可ありのブロックチェーンに関連づけられたアクセス制御層とは別個である。

【0490】

図１２Ａにおいて、アクセス制御プロセスは、ブロックチェーンインターフェースでブロックチェーンに記憶されるべきトランザクションを受信するノードにより開始され、これにおいて、トランザクションは、データの所有権及びアクセス特権（すなわち、パーミッション）の指標と共に、このデータに関連づけられたエンティティのための一意ユーザ識別子（ＵＵＩＤ）を含む（ブロック１２０１）。さらに、受信したトランザクションには、定義されたパーミッションを有すべきデータの態様のインジケータが含まれる。データの全体、又は任意のレベルの粒度におけるデータの任意の態様が、定義されたパーミッションを有することができ、例えば、データ及び／又はメタデータのオブジェクト、レコード、フィールドである。ブロックチェーン内のノードの合意に基づいて、トランザクションがブロックチェーンにコミットされたと決定されると、トランザクションデータのためのオブジェクト及びメタデータフォーマットが決定され、これは、ブロックチェーン上にデータを記憶するために利用され、これにおいて、オブジェクト及びメタデータは、所有エンティティＵＵＩＤ又は同様の識別子と、プライベートとして指定されるデータのオブジェクト、レコード、フィールド、又は同様のコンポーネントを識別するためのパーミッションのセットを含むことになる（ブロック１２０３）。

【0491】

ブロックチェーン合意マネージャ１９１又はパーミッションマネージャ１８１は、記憶されるデータを暗号化するための鍵を生成する（ブロック１２０５）。データを暗号化するために利用され、かつデータを復号してそれにアクセスするために利用されることにもなる鍵は、次いで、共有秘密のセットに変換される（ブロック１２０７）。鍵をブロックチェーンネットワークにおける指定された所有者ノードの数に等しい数の共有秘密のセットに変換することができる、任意の秘密共有プロセス又はプロトコルを利用することができる（例えば、Ｓｈａｍｉｒの秘密共有アルゴリズム）。同様に、所望の閾値又は構成可能な閾値を有する秘密共有アルゴリズムを選択して、共有秘密を生成することができる。このような共有秘密アルゴリズムを使用することにより、復号に必要とされる鍵を再構成するためにブロックチェーンネットワーク内の所有者ノードにより閾値数の共有秘密が提供されている場合にのみデータにアクセスできることを保証する。

【0492】

各共有秘密が、秘密共有アルゴリズムにより生成されるとき、ブロックチェーンネットワーク内の特定の所有者ノードに対して指定された共有秘密は、そのノードの公開鍵を使用して暗号化される（ブロック１２０９）。したがって、関連するノードのみが、それに割り当てられた共有秘密を復号し、読み取りに関する合意の一部として承諾された読み取り要求の場合にそれを提供することができる。これらの暗号化された共有秘密は、データに対するアクセス特権と共に、ブロックチェーンにトランザクションをコミットするための合意に基づいて、関連するトランザクションデータのメタデータとして記憶される（ブロック１２１１）。

【0493】

図１２Ｂは、ブロックチェーンネットワークにデータを書き込む要求にサービス提供するプロセスのフローチャートである。パーミッションマネージャ１８１は、エンティティから、ＵＵＩＤ及びアクセス制御特権に関連づけられた指定されたデータを書き込む要求を受信する（ブロック１２２１）。パーミッションマネージャ１８１又は関連するコンポーネントは、要求を認証して、十分なクレデンシャルが提示されていることを立証して、要求元が識別されたデータを変更するための書き込みプロセスを開始することを認可されていることを保証できる。要求元は、認可を立証するために、セキュリティトークン、パスワード、暗号化鍵、及び／又は同様のクレデンシャルを提示することができる。認証された場合、要求は、ＵＵＩＤ及び／又は書き込むデータの識別子に結びつけられたスマートコントラクトを決定するために処理される（ブロック１２２３）。スマートコントラクトは、データの書き込みとして機能する、データがブロックチェーンに追加されるプロセスを定め、管理することができ、それにより、ブロックチェーンに追加されるデータは、ブロックチェーン内の前のデータを、そのデータ自体は修正できないが置き換えるように機能する。ＵＵＩＤ、又はＵＵＩＤに関連づけられたデータ、又は要求により識別される特定のオブジェクト、レコード、若しくはフィールドのためのスマートコントラクトが、ブロックチェーン内でルックアップされ、書き込まれるデータに関連づけられたメタデータが、特権が書き込みを許容するかを決定するために調べられる（ブロック１２２５）。メタデータ及び管理するスマートコントラクトが要求元によるデータの書き込みを許可しない場合、プロセスは書き込みを拒否し、関連するトランザクションはコミットされず、あるいは、アクセス制御により管理される特定のデータに関連する部分はコミットされない（ブロック１２２７）。識別されたデータ及び要求元のＵＵＩＤに関連づけられたスマートコントラクト及び特権が書き込みを許可する場合、トランザクション及び／又は書き込まれるように識別されたトランザクション中のデータの一部は、ブロックチェーンにコミットされ得、書き込まれるデータを参照することになり、それにより、それを置き換えるように機能することになる。

【0494】

図１２Ｃは、ブロックチェーンネットワーク内のアクセス制御特権を有するデータを読み取る要求にサービス提供するプロセスのフローチャートである。アクセス制御されたデータがブロックチェーンに記憶された後、データにアクセスする要求にサービス提供しようとするノード（ブロック１１３１）は、要求されたデータの要求元及び／又は識別情報のパーミッションの初期チェックを行って、関連するメタデータ内のパーミッションを調べる（ブロック１２３３）。パーミッションが、要求元がパーミッションを有さないことを示す場合、このデータにアクセスする要求は拒否される（ブロック１２３５）。要求されたデータのＵＵＩＤ及びメタデータがアクセスを禁止しない場合、パーミッションマネージャ１８１は読み取り要求を開始しなければならず、これは、ブロックチェーンネットワークにおけるデータの所有者として示される他のノードにブロードキャストされ、アクセスされるデータを識別し、データにアクセスすることを要求しているノード又はエンティティに関する情報（すなわち、ＵＵＩＤ、及び可能性として、エンティティのためのクレデンシャルのセット）を含む（ブロック１２３７）。次いで、ノードの各々は、その合意プロセスをアクセス制御されたデータのために実行し、要求されたデータにアクセスするためのクレデンシャル又は他の基準が満たされているかどうかの決定を行う。データを読み取るための基準が満たされていると決定した各ノードは、その共有秘密を要求ノードに提供する（ブロック１２３９）。次いで、要求ノードは、共有秘密を収集し、定義された閾値数の共有秘密が提供されたかどうかを決定することができる（ブロック１２４１）。閾値数の共有秘密が返されない場合、合意プロセスは読み取り要求を拒否し、それは完了できない（ブロック１２４３）。いくつかの実施形態において、合意プロセスは、プロセスが閾値数の共有秘密を受信しなければならない時間制限又はウィンドウを有することができる。閾値数の共有秘密が他のノードにより提供された場合、要求ノードは、共有秘密アルゴリズムを利用して共有秘密を鍵に変換することができ、次いで、要求されたデータは復号され、アクセスされ得る（ブロック１２４５）。閾値は、固定又は構成可能とすることができる。閾値は、参加ノードの数の半分又は３分の２に等しい数などの、任意の値とすることができる。データがアクセスされた後、要求ノードは鍵を破棄することができ、それにより、それは後のアクセスで再度要求及び再形成される必要があることになる。

【0495】

図１２Ｄは、アクセス制御の一例示的な使用事例の図である。例示的な使用事例は、本明細書に記載されるアクセス制御及び読み取りに関する合意プロセスと関連して実施することができる。使用事例は、ポリシーとも呼ばれるパーミッションルールの定義を可能にする。分散エンタープライズプラットフォームの文脈において、ロールベース及び属性ベース双方の制御を実施することができる。ロールベースの制御は、ユーザのアクセス権を定義し、属性ベースの制御は、アクセス権をリソース、エンティティ、及び実行環境のプロパティなどの属性に拡張する。アクセス制御は、ブロックチェーンと組み合わせて、エンティティレベル及びレコードレベルのアクセスに分割することができる。エンティティレベルのアクセスは、オブジェクト又はフィールドレベルの制御と同様であり、これは、定義されたユーザ又はパートナーのセットがブロックチェーン内のエンティティ及び関連するフィールドにアクセスできるようにする。レコードレベルのアクセスは、他のプラットフォームにおける共有設定と同様とすることができ、これは、レコード所有者により定義されたパーミッションに基づいてレコードへのアクセスを可能にする。

【0496】

この例示的な使用事例において、アクセス制御は、参加者、レコード、レコードポリシー、及びレコード認可に関連して定義することができる。この使用事例における参加者は、ブロックチェーン内の参加者メタデータで表され、これは、ブロックチェーン内の指定されたデータに対して所有権又はアクセス特権を有するユーザ又はエンティティの定義されたセットとすることができる。この文脈におけるレコードは、レコードを拡張するエンティティの識別子を含むメタデータエンティティとすることができる（例えば、顧客エンティティはレコードエンティティの識別子を含む）。参加者は、この例ではレコードエンティティに関連づけられる。アクセスは、エンティティアクセスを管理するためにレコードレベルで定義される。

【0497】

この使用事例において、レコードポリシーは、レコード及び参加者アクセスポリシーを保持するジャンクション（junction）オブジェクトとすることができる。アクセスレベルは、２つのタイプ、パーミッションレベル（例えば、読み取り、書き込み、読み取り／書き込み）と、１又は過半数などの合意レベル（例えば、複数の所有者が存在する場合）で定義することができる。レコード認可は、レコードポリシーに関連する各レコード所有者による個々の認可に関するトランザクションを追跡することができる。

【0498】

図１２Ｄに関し、アクセス制御の例示的な使用事例は、第三者（すなわち、非所有者）からのアクセス要求に関連して説明されている。例のために、第三者は、本明細書に記載されるようにブロックチェーンを使用して成績証明書を管理する別の機関（例えば、高校）からの学生（すなわち、所有者）の成績証明書をレビューすることを求める大学でもよい。このプロセスは、第三者（大学）が成績証明書にアクセスすることを求めることで始まる。アクセス要求ハンドラは、アクセスのパーミッションを決定するためにブロックチェーンにクエリする。アクセスがすでに承諾されている場合、立証（verification）を返すことができる。

【0499】

アクセスがまだ承諾されていない場合、アクセス要求ハンドラはアクセス要求を所有者に送信することができる。所有者の全て（又は、過半数）がアクセスを承認すると、成績証明書のポリシー／パーミッションがブロックチェーン内で更新される。次いで、第三者のアクセス要求を受け入れて、ブロックチェーン内の要求されたレコード（例えば、成績証明書）へのアクセスを付与することができる。アクセスが所有者により承認されない場合、アクセスはブロックされる。

【0500】

図１３は、クラウドベースのオンデマンドの機能性をユーザ、顧客、及びサブスクライバに提供するような機能性を実行するためにプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境と関連して分散台帳技術（ＤＬＴ）を使用してブロックチェーン内のデータ及びメタデータの効率的な記憶及び検証を実施する方法１２００を示すフロー図を示す。

【0501】

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

【0502】

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

【0503】

ブロック１３１０において、処理論理は、ブロックチェーン上に永続的に記憶されたデータレコードを更新するようにホスト組織に要求する、ブロックチェーンに対するトランザクションを受信し、該トランザクションは、データレコードの複数のデータ要素のうちの１つ以上のための更新値を指定する。

【0504】

ブロック１３１５において、処理論理は、ブロックチェーン上のデータレコードを更新値で更新するためにトランザクションがブロックチェーンに追加されることを許可する前に、トランザクションにより指定された更新値を検証するためにスマートコントラクトを実行する。

【0505】

ブロック１３２０において、処理論理は、スマートコントラクトによる更新データ値の成功裏の検証に従ってブロックチェーン上の新しいブロックにトランザクションを追加することにより、データレコードに対する更新値をブロックチェーンに書き込む。

【0506】

別の実施形態によれば、方法１３００は、ブロックチェーン上に永続的に記憶されたデータレコードのためのデータマージ操作を実行することを含み、データマージ操作は、ブロックチェーンからデータレコードをその全体として取り出して、データレコードの複数のデータ要素の全てを取り出すことと、ブロックチェーンに対するトランザクションにより指定された検証された更新値をデータレコードの複数のデータ要素にマージして、検証された更新値をその中に具現化させた完全なデータレコードを形成することを含み、ブロックチェーン上の新しいブロックにトランザクションを追加することにより、ブロックチェーンにデータレコードに対する更新値を書き込むことは、ブロックチェーンの新しいブロックに、検証された更新値をその中に具現化させた完全なデータレコードを書き込むことを含み、完全なデータレコードは、ブロックチェーン上に記憶されたデータレコードの全ての前のバージョンを廃止し、ブロックチェーン上に記憶されたデータレコードの前のバージョンを参照しない。

【0507】

例えば、データマージ操作は、データレコードが以前に何回の更新を受けたかにかかわらず、データレコードのデータがブロックチェーンの単一ブロックから取り出されることを可能にする。ゆえに、一方で、一部のデータは複製される（例えば、非更新値は今や、前のブロックと、マージされた完全なレコードが書き込まれた新しいブロックにも存在する）。データ冗長性にもかかわらず、データ取り出しは、より効率的かつ高速に行われる。

【0508】

方法１３００の別の実施形態によれば、ブロックチェーン上の新しいブロックにトランザクションを追加することにより、ブロックチェーンにデータレコードに対する更新値を書き込むことは、ブロックチェーン上の前のブロックへの参照を有するブロックチェーン上の新しいブロックに更新値を書き込むことを含み、データレコードの完全な現在のバージョンの取り出しは、更新値により修正されない記憶されたデータレコードのデータ要素が参照に基づいてブロックチェーン上の前のブロックから取り出されることと、ブロックチェーン上の新しいブロックからの更新値の取り出しを必要とする。

【0509】

例えば、取り出しを改善するが記憶されたデータの冗長性を結果としてもたらすデータマージ操作を実行するのでなく、記憶されたデータレコードは代わりにブロックチェーン上の複数のブロックにより表現され、より新しい更新された情報は、ブロックチェーンの新しいブロック内に、記憶されたデータレコードの非更新値が取り出され得るブロックチェーン上の前の位置への参照ポインタと共に記憶される。

【0510】

別の実施形態によれば、方法１３００はさらに、ブロックチェーン上に永続的に記憶されたデータレコードに対するデータマージ操作及びデータシリアライズを実行することを含み、データマージ操作は、（ｉ）ブロックチェーンからデータレコードをその全体として取り出すことと、（ｉｉ）取り出されたデータレコードに更新値をマージして、更新値をその中に具現化させた完全なデータレコードを形成することを含み、データシリアライズ操作は、データマージ操作により形成され、かつ更新値をその中に具現化させた完全なデータレコードを、シリアライズされたバイトストリームにコンバートすることを含み、ブロックチェーン上の新しいブロックにトランザクションを追加することにより、ブロックチェーンにデータレコードに対する更新値を書き込むことは、ブロックチェーン上の新しいブロックにシリアライズされたバイトストリームを書き込むことを含む。

【0511】

例えば、データマージ操作から結果として生じる更新レコードは、ブロックチェーンに記憶されるより小さくより効率的なレコードを形成するために（例えば、ｐｒｏｔｏｂｕｆ生成器又は他のシリアライズ手段を介して）シリアライズされ得、潜在的に、シリアライズの結果として生じる抽象化を通してデータセキュリティのレイヤを提供し、任意で、高度のデータセキュリティが保証されるシリアライズされた更新レコードの更なる暗号化を可能にする。

【0512】

別の実施形態によれば、方法１３００はさらに、ｐｒｏｔｏｂｕｆ生成器を実行して、データマージ操作により形成され、かつ更新値をその中に具現化された完全なデータレコードを、シリアライズされたバイトストリームにコンバートすることを含む。

【0513】

方法１３００の別の実施形態によれば、シリアライズされたバイトストリームは、バイナリフォーマットのシリアライズされたバイトストリーム、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔｉｆｉｃａｔｉｏｎ（ＪＳＯＮ）互換フォーマットのシリアライズされたバイトストリーム、平文又は情報交換用米国標準コード（American Standard Code for Information Interchange、ＡＳＣＩＩ）互換フォーマットのシリアライズされたバイトストリーム、暗号化されたシリアライズされたバイトストリーム、プロトコルバッファリングされたシリアライズされたバイトストリーム、及び１６進数フォーマットのシリアライズされたバイトストリーム、のうちの少なくとも１つを形成する。

【0514】

例えば、データシリアライズ操作は、シリアライズされたデータのセキュリティ及び相互運用性の容易さに関するアプリケーション開発者のニーズの必要に依存して、様々なフォーマットのいずれかを生成することができる。

【0515】

別の実施形態によれば、方法１３００はさらに、新しい記憶データレコードとしてブロックチェーン上にデータレコードを記憶するようにホスト組織に要求する、ブロックチェーンに対する第１のトランザクションを受信することを含み、新しい記憶データレコードは、第１のトランザクションにより指定されたその中に埋め込まれた複数のデータ要素を含み、ブロックチェーン上に永続的に記憶されたデータレコードを更新するようにホスト組織に要求する、ブロックチェーンに対するトランザクションを受信することは、ブロックチェーンに対する第２のトランザクションを受信することを含み、第２のトランザクションは、ブロックチェーン上へ前にトランザクション処理された新しい記憶データレコードに対する更新値を指定する。

【0516】

例えば、ブロックチェーンに記憶されるオリジナルかつ新規のレコードは依然としてデータ検証を受けるが、オリジナルかつ新規のレコードを更新する必要はない。その後、オリジナルのデータレコードへの更新は、データ検証を条件としてブロックチェーン上で適用され、記憶され得る。

【0517】

別の実施形態によれば、方法１３００はさらに、ブロックチェーン上にメタデータを記憶するようにホスト組織に要求する、ブロックチェーンに対する第１のトランザクションを受信することであり、メタデータは、データレコードとデータレコードにより記憶される複数のデータ要素との有効なフォーマットを定義することを含み、ブロックチェーン上に永続的に記憶されたデータレコードを更新するようにホスト組織に要求する、ブロックチェーンに対するトランザクションを受信することは、ブロックチェーンに対する第２のトランザクションを受信することを含み、第２のトランザクションは、ブロックチェーン上へ前にトランザクション処理された記憶データレコードに対する更新値を指定し、トランザクションにより指定された更新値を検証するためにスマートコントラクトを実行することは、第１のトランザクションに従って記憶されたブロックチェーンからメタデータを取り出し、取り出されたメタデータを使用して更新値を検証することを含む。

【0518】

例えば、レコードの適切なフォーマットを定義するメタデータは、許容される方法でブロックチェーン上に記憶され、次いで、データ検証を実行する際に実行されたスマートコントラクトによる使用のために取り出され得る。さらに、所望に応じて、ブロックチェーンに記憶されたメタデータをプロトコルバッファリング又はシリアライズすることが許容される。

【0519】

別の実施形態によれば、方法１３００はさらに、トランザクションにより指定された更新値の失敗した検証に基づいて、トランザクションを拒絶し、ブロックチェーンに永続的に記憶されたデータレコードに更新値が書き込まれるのを禁止することを含む。

【0520】

別の実施形態によれば、方法１３００はさらに、受信したトランザクションに基づいてトランザクションタイプを決定することと、決定されたトランザクションタイプに基づいて実行されるスマートコントラクトを識別することを含み、更新値を検証するためにスマートコントラクトを実行することは、トランザクションタイプに基づいて識別されたスマートコントラクトを実行することを含む。

【0521】

例えば、ブロックチェーンとのトランザクションは、異なるトランザクションが異なるトランザクションタイプに対応するように「タイプ付け」されてもよい。このような実施形態によれば、トランザクションタイプに基づいて、スマートコントラクトが、決定されたトランザクションタイプに従って識別又はルックアップされ得る。その後、スマートコントラクトの実行は、決定されたトランザクションタイプとスマートコントラクトの識別に基づく。特定の実施形態において、トランザクションタイプはトランザクションと共に明示的に指定されるが、他の実施形態において、トランザクションタイプは、トランザクションの内容に基づいて導出される。

【0522】

方法１３００の別の実施形態によれば、トランザクションにより指定された更新値を検証するためにスマートコントラクトを実行することは、ブロックチェーン上に永続的に記憶されたデータレコードの有効なフォーマットを定義するメタデータを取り出すことと、取り出されたメタデータを使用してトランザクションにより指定された更新値を検証することと、検証に基づいて成功裏の検証結果又は失敗した検証結果を発行することを含み、トランザクションは、失敗した検証結果に従ってブロックチェーンに追加されることを禁止され、トランザクションは、成功裏の検証結果に従ってブロックチェーンに追加されることを許可される。

【0523】

例えば、スマートコントラクトの実行は、品質コントロールの役割を果たし、破壊された、悪意のある、又は不正な形式のデータがブロックチェーン上へトランザクション処理されないことを保証するために利用され得る。

【0524】

方法１３００の別の実施形態によれば、データレコードは、ブロックチェーンに対するＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを介して資産のペイロード部分内でブロックチェーン上に記憶され、データレコードは、データレコードの前のバージョンを廃止するブロックチェーンの新しいブロック内の更新と共にその全体として記憶される記憶データレコードに対するトランザクションタイプに関連づけられる。

【0525】

方法１３００の別の実施形態によれば、データレコードは、ブロックチェーンに対するＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを介して資産のペイロード部分内でブロックチェーンに記憶され、データレコードは、増分的に記憶される記憶データレコードに対するトランザクションタイプに関連づけられ、記憶データレコードへの任意の更新は、記憶データレコードが前に記憶されたブロックチェーン上の前のブロックへの参照を有するブロックチェーン上の新しいブロックに、トランザクションにより指定された更新値を書き込み、ブロックチェーンからの記憶データレコードの取り出しは、ブロックチェーン上の新しいブロックからの更新値の取り出しと、ブロックチェーン上の前のブロックからの、更新値により修正されない残りの値の取り出しを必要とする。

【0526】

例えば、ブロックチェーン上にレコードを記憶することは、ＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを活用してブロックチェーン上へ新しい資産をトランザクション処理してもよく、その中で、記憶データレコードは、次いで、例えば、新しい資産のペイロード部分内で符号化又は具現化される。次いで、記憶データレコードへのその後の更新は、ＵＰＤＡＴＥ ａｓｓｅｔコマンド機能を使用して資産を更新し、あるいは、上記で論じられたデータマージ操作を介して生成された更新情報を有する完全なレコードのために完全に新しい資産を生成することができる。その場合、ブロックチェーンプロトコル及びアプリケーション開発者の考慮事項に依存して、ＵＰＤＡＴＥ ａｓｓｅｔコマンド機能が利用されてもよく、その場合、新しいバージョンはその全体として作成されるが記憶データレコードの前の廃止されたバージョンへの参照を有し、あるいは、ＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを利用して、前のバージョンへの全ての参照を単に除去し、新しい資産としてブロックチェーンに完全な更新レコードを書き込んでもよい。

【0527】

別の実施形態によれば、方法１３００はさらに、関連エンティティを記憶するようにホスト組織に要求する、ブロックチェーンに対する第２のトランザクションを受信することであり、関連エンティティは、記憶データレコードがブロックチェーン上に永続的に記憶された第１の資産とは別個かつ区別可能な第２の資産を介してブロックチェーンに永続的に記憶されることと、ＣＲＥＡＴＥ ａｓｓｅｔトランザクションを介してブロックチェーンとの間でトランザクション処理して第２の資産をブロックチェーンに追加し、第２の資産のペイロード部分内に関連エンティティを記憶することと、関連エンティティに割り当てられたユニバーサル一意識別子（ＵＵＩＤ）を介して、第２の資産内に記憶された関連エンティティを第１の資産内の記憶データレコードに関連させることを含む。

【0528】

別の実施形態によれば、方法１３００はさらに、ブロックチェーンから記憶データレコードを取り出すことと、関連するエンティティに割り当てられたＵＵＩＤを含むように記憶データレコードを更新することと、ＵＵＩＤをその中に含ませた更新された記憶データレコードをブロックチェーンに書き込むことを含む。

【0529】

方法１３００の別の実施形態によれば、記憶データレコードは、複数のデータ要素を介して少なくとも学生ファーストネーム、学生ラストネーム、及び学生ＩＤをその中に埋め込ませた学生レコードを含み、関連エンティティは学生成績証明書を含み、関連エンティティに割り当てられたユニバーサル一意識別子（ＵＵＩＤ）を介して、第２の資産内に記憶された関連エンティティを第１の資産内の記憶データレコードに関連させることは、学生成績証明書に割り当てられたＵＵＩＤを介して学生成績証明書を学生レコードとリンクすることを含み、ＵＵＩＤを含むように記憶データレコードを更新することは、学生レコードを学生成績証明書とリンクするＵＵＩＤを含むように学生レコードを更新することを含み、ＵＵＩＤをその中に含ませた更新された記憶データレコードをブロックチェーンに書き込むことは、学生ファーストネーム、学生ラストネーム、学生ＩＤ、及び別個かつ区別可能な第２の資産を介してブロックチェーン上に記憶された学生成績証明書に割り当てられたＵＵＩＤをその中に埋め込まれた学生レコードをブロックチェーンに書き込むことを含む。

【0530】

例えば、記憶データレコードのデータ要素のうちの１つの一部ではない他の情報の記憶は、それにもかかわらず、関連エンティティ機能を介してブロックチェーン上に記憶されてもよく、これにおいて、関連エンティティ（例えば、学生成績証明書又は学生医療記録など）は、記憶データレコードとは別個の資産内に記憶されたメタデータとしてブロックチェーンに書き込まれ、次いで、関連エンティティに自動的に割り当てられたＵＵＩＤを記憶データレコードの複数のデータ要素内に含むことにより記憶データレコードとリンクされ、したがって、リンクを果たすために記憶データレコードへの更新が必要である。

【0531】

方法１３００の別の実施形態によれば、データレコードのための有効なフォーマットを定義するメタデータは、ブロックチェーンに対するＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを介して資産のペイロード部分内でブロックチェーン上に記憶され、メタデータは、記憶されたメタデータのためのトランザクションタイプに関連づけられる。

【0532】

例えば、メタデータの記憶は、ＣＲＥＡＴＥ ａｓｓｅｔコマンドタームを活用してもよいが、それは、そのトランザクションタイプ及びさらに記憶される内容の観点で異なる。

【0533】

方法１３００の別の実施形態によれば、追加されるトランザクションは、追加されるトランザクションがブロックチェーンの参加ノードによりブロックチェーンのプライマリチェーンの一部として受け入れられる前に、ブロックチェーンの参加ノードによる合意プロトコルを受ける。

【0534】

例えば、ブロックチェーン上のトランザクション処理は、トランザクション有効性を保証するためにそのブロックチェーンに対して必要とされる合意スキームを保有する。

【0535】

方法１３００の別の実施形態によれば、メタデータは、ブロックチェーン上へメタデータを定義及びトランザクション処理したホスト組織の複数のテナントのうちの１つのみにアクセス可能であり、あるいは代替的に、メタデータは、複数のテナントのうちのどの１つがブロックチェーン上へメタデータを定義及びトランザクション処理したかにかかわらず、ブロックチェーンへのアクセスを有する参加ノードのうちの１つとして動作する複数のテナントの全てにアクセス可能である。

【0536】

例えば、ブロックチェーンに対するメタデータを、それが特定のアプリケーションのためにメタデータを作成した特定のテナント組織に対してドメイン特有なままであるという意図と共に定義し、記憶することが可能である。しかしながら、ホスト組織の管理者が、ブロックチェーン内の参加ノードとして動作しているいかなるテナント組織にもアクセス可能にされる非ドメイン特有のメタデータを作成することを望む場合があり得、あるいは、特定の場合に、テナント組織が、他のテナント組織に対してアクセス可能にされる特定の適用のためのそのようなメタデータを作成することを望む場合もある。

【0537】

方法１３００の別の実施形態によれば、ブロックチェーン上へトランザクション処理されたメタデータの修正は、ブロックチェーンを介した永続的な記憶のためにブロックチェーン上へメタデータをトランザクション処理した複数のテナントのうちの１つの排他的制御下にあり、これにおいて、メタデータが、ブロックチェーンへのアクセスを有する参加ノードのうちの１つとして動作する複数のテナントのいずれかにアクセス可能であるとき、ブロックチェーン上へメタデータへの変更を書き込むために、新しい合意が必要とされ、メタデータが、ブロックチェーン上へメタデータを元々トランザクション処理した複数のテナントのうちの１つのみにより排他的使用のためにアクセス可能であるとき、ブロックチェーン上へメタデータへの変更を書き込むために、合意は必要とされない。

【0538】

例えば、メタデータが他のテナント組織にアクセス可能である場合、修正は合意コントロールを受けるが、メタデータがドメイン特有のものであり、元々それを作成してブロックチェーン上に記憶したテナント組織による排他的使用に限定されている場合、そのような修正の合意を強制することは必要ないが、任意で、ブロックチェーンプロトコルは、それにもかかわらず合意オペレーションを必要としてもよい。

【0539】

方法１３００の別の実施形態によれば、ブロックチェーンのブロックチェーンプロトコルはホスト組織により定義され、さらに、ホスト組織は、ブロックチェーン上の参加ノードとして動作するホスト組織の複数のテナントのためのブロックチェーンへのアクセスを許可し、あるいは代替的に、ブロックチェーンのブロックチェーンプロトコルは、ホスト組織以外の第三者のブロックチェーンプロバイダにより定義され、さらに、ホスト組織は、ホスト組織がブロックチェーンへのアクセスを有するブロックチェーン上の参加ノードとしても動作する。

【0540】

例えば、特定のブロックチェーンは、ホスト組織自体により実施され、ホスト組織は、ブロックチェーンプロトコルを定義し、そのテナント組織のためにブロックチェーンへのアクセスを容易にし、これらは次いで、ホストｏｒｇ提供ブロックチェーン上の参加ノードとして動作し、任意で、非テナント組織もホスト組織の裁量で参加ノードとして許可される。しかしながら、ホスト組織により定義又は実施されておらず、したがってホスト組織の外部で動作する既存のブロックチェーン実装も存在し、そのようなブロックチェーンプロトコルは、第三者又は外部のコンソーシアム若しくは標準化団体により定義されている。このような場合に、ホスト組織は、それにもかかわらず、ブロックチェーン上でそれ自体参加ノードとして動作することによりブロックチェーンへのアクセスを容易にすることができ、これを介して、ホスト組織は次いで、ブロックチェーンの機能へのアクセスを有することができる。このような場合に、ホスト組織に対してテナントｏｒｇにより、それらのためにプロキシとして作用するために、パーミッション及びアクセス権を付与することができ、あるいは、ホスト組織は、各テナントｏｒｇが参加ノードとして動作し得るブロックチェーン上の仮想参加ノードを実施することができ、したがって、テナント組織と、ホスト組織により実施される仮想ノード又はホスト組織との間の１：１の対応を提供することにより、関連するスマートコントラクトを実行し、ブロックチェーンに対する記憶データレコード更新トランザクションの検証を実行するが、次いで、テナント組織の独自の参加ノードが、例えばホスト組織提供ＡＰＩを介して、ブロックチェーンとの間で自己認証し、次いでブロックチェーンとの間で実際にトランザクション処理することを可能にすることができる。このようにして、テナントｏｒｇは、どのブロックチェーンがホスト組織又は第三者により実施されているかにかかわらず、ブロックチェーンにトランザクションを（合意を条件として）追加することができる。

【0541】

別の実施形態によれば、方法１３００はさらに、ブロックチェーンに永続的に記憶された複数のデータレコードのインデックスを維持することを含み、インデックスは、ブロックチェーンに永続的に記憶された複数のデータレコードの各々についての少なくとも位置を定義し、この位置は、ブロックチェーンに永続的に記憶されたそれぞれのデータレコードを取り出すためのブロックチェーンの１つのアドレス指定可能ブロックを定義する。

【0542】

方法１３００の別の実施形態によれば、インデックスは、マークルツリー互換インデックスを含み、インデックスは、ホスト組織で永続的に記憶され、あるいはブロックチェーンに永続的に記憶され、あるいはホスト組織とブロックチェーンの双方で永続的に記憶される。

【0543】

例えば、そのようなインデックスを利用して、取り出し速度を改善することができ、インデックスは、ホスト組織及びブロックチェーンの一方又は双方の内部に維持される。重複データが永続的に記憶されるが、インデキシングされたレコードを取得する取り出し時間は、このようなデータがどのブロックに記憶されるかなどのブロックチェーン内のデータの特定の位置を定義するインデックスに起因して、大幅に短縮される。

【0544】

方法１３００の別の実施形態によれば、インデックスは、ブロックチェーンに永続的に記憶される複数のデータレコードの各々について、（ｉ）ブロックチェーンに永続的に記憶される複数のレコードの各々についての位置と、（ｉｉ）ブロックチェーンに永続的に記憶される複数のレコードレコードの内容のコピーとの双方を定義し、インデックスを維持することは、データレコードに対する更新値が更新値の成功裏の検証に従ってブロックチェーンに書き込まれるとき、データレコードに対する更新値をインデックスに書き込むことを含む。

【0545】

別の実施形態によれば、方法１３００はさらに、ブロックチェーンに前に書き込まれた更新されたデータレコードの、ブロックチェーンからの取り出しを要求する第２のトランザクションを受信することと、ブロックチェーンと相互作用することなく、インデックスから更新されたデータレコードを取り出すことと、取り出しを要求する第２のトランザクションに応答して、インデックスから取り出された更新されたデータレコードを返すことを含む。

【0546】

例えば、位置情報をインデキシングすることに加えて、レコードの内容も取り出されてもよく、これは、前にインデキシングされた読取専用の取り出し要求についてブロックチェーンとトランザクション処理する必要を完全に否定する。このような記憶レコードの内容がこのようにしてインデキシングされる場合、取り出し速度は、特にインデックスがホスト組織で永続化及び維持され、したがって読取専用の取り出しのためのブロックチェーンとの相互作用を何でも排除するとき、従来のブロックチェーン取り出しトランザクションに対して劇的に増加することになる。

【0547】

方法１３００の別の実施形態によれば、インデックスのノード及びリーフは、インデックスのアドレス指定構造により定義される完全又は部分アドレスを介して取り出し可能であり、この方法はさらに、インデックスのアドレス指定構造を維持することを含み、これにおいて、アドレス指定構造は、アプリケーション名前空間を定義するアドレス指定構造の第１の部分と、エンティティタイプ識別子を定義するアドレス指定構造の第２の部分と、ブロックチェーンにより記憶されインデックスによりインデキシングされるエンティティ又はデータレコードの名前を定義するアドレス指定構造の第３の部分と、を少なくとも含む。

【0548】

例えば、ノード又はリーフ又はノード下のサブツリー６５４は、アドレスが分かっているとき、インデックスをウォーク、トラバース、又は検索する必要なく直接参照され、インデックスから取り出され得、したがって、取り出し速度をさらに増加させる。

【0549】

方法１３００の別の実施形態によれば、完全修飾アドレスを有するインデックスを参照することは、インデックスからのリーフの内容、リーフの内容を返し、部分アドレスを有するインデックスを参照することは、部分アドレスに一致するインデックスのノード下のサブツリーを返し、サブツリーは、部分アドレスに一致するインデックスのノード下に構造化されたインデックスの複数のリーフを含む。

【0550】

例えば、任意のリーフの内容は、アプリケーション名前空間、エンティティタイプ識別子、及びエンティティ又はレコードの名前を指定する完全アドレスを有するインデックスへの呼び出しにより返され得るが、部分アドレスの使用は、それがノード下のサブツリー内の全ての一致するレコードの返しを可能にするとき、極めて有益であり得る。例えば、所望される場合、学生レコードを記憶するアプリケーションは、アプリケーション名前空間及びエンティティタイプ識別子を有するが特定のエンティティ名の指定を欠く部分アドレスを指定することにより、アプリケーションの全てのメタデータを返すことができる。同様に、全ての学生レコードは、アプリケーション名前空間コードを指定し、学生データレコードのエンティティタイプ識別子を指定するが特定のエンティティ名の指定を欠く部分アドレスを使用して、返され得る。

【0551】

別の実施形態によれば、方法１３００はさらに、ブロックチェーンに永続的に記憶されたデータレコードの複数のデータ要素のうちの１つ以上に対するさらなる更新値を指定する複数の後続トランザクションを受信することと、ブロックチェーンに対応する更新を書き込むことなく、受信に基づいて複数の後続トランザクションの各々を用いてインデックスを更新することにより、インデックスにさらなる更新値を指定する複数の後続トランザクションをバッファリングすることと、複数の後続トランザクションを介して受信したさらなる更新値の全てを表す単一の増分更新トランザクションをブロックチェーンに周期的に追加することにより、ブロックチェーンに永続的に記憶されたデータレコードを増分的に更新することを含む。

【0552】

例えば、ＩｏＴデバイス（モノの情報（Information of Things））のグループからのデータストリームなどの特定のアプリケーションは、ブロックチェーン内での記憶に関して実用的であるためには、あまりに高い頻度の変更を有する更新と、データの終わりのないストリームに起因する更新を結果としてもたらす。しかしながら、インデックスを介してそのような情報をバッファリングし、次いで、単一の増分更新トランザクションを介してそのようなデータをブロックチェーンに周期的にフラッシュすることは、この問題を克服し、したがって、このような高頻度のデータレコード更新がそれにもかかわらずブロックチェーン上でトランザクション処理され、記憶されることを可能にする。

【0553】

特定の実施形態によれば、命令を記憶させた非一時的コンピュータ読取可能記憶媒体があり、命令が少なくともプロセッサ及びメモリをその中に有するシステムのプロセッサにより実行されると、命令はシステムに以下の動作を実行させ、該動作は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させることであり、複数のテナントの各テナントは、ブロックチェーンへのアクセスを有する参加ノードとして動作する、ことと、ブロックチェーン上に永続的に記憶されたデータレコードを更新するようにホスト組織に要求する、ブロックチェーンに対するトランザクションを受信することであり、トランザクションは、データレコードの複数のデータ要素のうちの１つ以上に対する更新値を指定することと、ブロックチェーン上のデータレコードを更新値で更新するためにトランザクションがブロックチェーンに追加されることを許可する前に、トランザクションにより指定された更新値を検証するためにスマートコントラクトを実行することと、スマートコントラクトによる更新データ値の成功裏の検証に従ってブロックチェーン上の新しいブロックにトランザクションを追加することにより、データレコードに対する更新値をブロックチェーンに書き込むことを含む。

【0554】

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

【0555】

図示の実施形態によれば、ホスト組織内で動作し得るシステム１４０１は、システム１４０１で命令を実行するためにプロセッサ１４９０及びメモリ１４９５を含む。このような実施形態によれば、プロセッサ１４９０は、ホスト組織の複数のテナント１４９８のためにブロックチェーンサービスインターフェース１４６５を実行し、複数のテナント１４９８の各テナントは、ブロックチェーン１４９９へのアクセスを有する参加ノードとして動作する。ブロックチェーンサービスインターフェース１４６５の内部には、ブロックチェーンメタデータ定義マネージャ１４９２が示されており、ここでは、ブロックチェーンサービスインターフェース１４６５により提供されるブロックチェーン１４９９へのそのアクセスを介してブロックチェーン上へメタデータを書き込むものとして示されている。

【0556】

システム１４０１の受信インターフェース１４２６は、ブロックチェーン上に永続的に記憶されたデータレコードを更新するようにホスト組織に要求する、ブロックチェーンに対するトランザクション１４４１を受信し、これにおいて、トランザクションは、データレコードの複数のデータ要素のうちの１つ以上に対する更新値を指定する。このようなシステムはさらに、プロセッサ１４９０を介して実行可能なスマートコントラクト１４３９と、スマートコントラクト実行器及びバリデータ１４４３を含み、これを介し、トランザクション１４４１により指定された更新値は、ブロックチェーン上のデータレコードを更新値で更新するためにトランザクションがブロックチェーンに追加されることを許可する前に、検証される。ブロックチェーンサービスインターフェース１４６５がシステム１４０１にさらに提供され、これを介し、スマートコントラクト１４３９による更新データ値の成功裏の検証に従ってブロックチェーン上の新しいブロックにトランザクション１４４１を追加することにより、データレコードに対する更新値をブロックチェーンに書き込む。

【0557】

ブロックチェーンのためのブロックチェーンプロトコル１４８６は、ブロックチェーンのための機能のグループ（例えば、ブロックチェーン実施マネージャ１４８５により提供される）を定義し、これにおいて、基本機能のグループは、ブロックチェーンの任意の参加ノード１４９８にとってアクセス可能である。システム１４０１はさらに、メタデータ１４８９をブロックチェーン上に永続化することができ、これにおいて、受信インターフェース１４２６はさらに、そのようなメタデータ１４８９がブロックチェーンに記憶されることを要求するトランザクション１４４１を受信し、これは時に、受信したトランザクション１４４１の更新値の検証で使用される。このようなシステム１４０１によれば、ブロックチェーンサービスインターフェース１４６５はさらに、スマートコントラクト１４３９による成功裏の検証に従ってブロックチェーン上の新しいブロックにトランザクション１４４１を追加する。

【0558】

システム１４０１のこのような実施形態によれば、受信インターフェース１４２６は、データベースシステム１４４６により永続化されるインデックス内に記憶されるトランザクション１４４１のトランザクションデータ内容を渡すことができる。

【0559】

システム１４０１のこのような実施形態によれば、ユーザデバイス１４９７にＧＵＩ１４４０がプッシュされてもよく、これを介して、ユーザデバイス又は管理コンピューティングデバイスは、ブロックチェーンメタデータ定義マネージャ１４９２と相互作用することができる。

【0560】

システム１４０１の別の実施形態によれば、ブロックチェーンサービスインターフェース１４６５は、ブロックチェーン１４９９と相互作用し、ブロックチェーン１４９９へのアクセスを提供する。

【0561】

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

【0562】

バス１４１６は、システム１４０１の様々なコンポーネントを互いの間で、システム１４０１の任意の他の周辺機器と、及び外部ネットワーク要素、他のマシン、クライアントデバイス、クラウドコンピューティングサービスなどの外部コンポーネントとインターフェースする。通信はさらに、ＬＡＮ、ＷＡＮ、又はパブリックインターネットを通じてネットワークインターフェースを介して外部装置と通信することを含んでもよく、一方、認証器１４５０は、システム１４０１により公開されたホスト組織からのデータにアクセスしようとするユーザデバイス及びユーザを認証する。

【0563】

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

【0564】

詳細には、次に、メタデータルールユーザ１５５０がコンピューティングデバイス１５９９を利用し、具体的にグラフィカルユーザインターフェース（ＧＵＩ）１５１０を利用して、ブロックチェーン上で発生するトランザクションに適用されるメタデータルールを構成することが示されている。

【0565】

ここに示すように、アプリケーション選択ＧＵＩがあり、これを介して、メタデータルールユーザ１５５０は、新しいメタデータルールが適用されるべき１つ以上のアプリケーションを最初に選択することができ、次いで下部に、ルール作成ＧＵＩがあり、これを介して、メタデータルールユーザ１５５０は、ブロックチェーンにデプロイされる新しいルールを作成することができる。

【0566】

ここに示すように、ルール作成（Rule Creation）ＧＵＩは、メタデータルールユーザ１５５０に条件ビルダインターフェースを提供し、これを介して、ユーザはＧＵＩを通じて、存在しなければならない状態（states）と、演算子、例えば、「である（is）」又は「でない」又は「を含む」又は「を含まない」又は「に等しい」又は「より大きい」又は「より小さい」等と、次いで、記述子、例えば、「状態が保留中の変更である（State is pending change）」とき又は「状態が既知のエラーである（state is known error）」とき適用されるべきルールのための「保留中の変更」、又は追加されるべき何らかの他の新しい基準などを選択することができる。

【0567】

さらにＧＵＩにより、ユーザは、システムを介して既に宣言され、利用可能な既存のフィルタ又はルールをロードし、あるいは新たに作成されたルール又はフィルタを保存し、あるいはソートする等を行うことができる。またさらに、以下により詳細に論じられる「実行（Run）」機能により、メタデータルールユーザ１５５０は、実際にブロックチェーン上へ何もトランザクション処理することなく、また、合意及び受け入れのために新たに作成されたルールをブロックチェーンにプッシュすることなく、新たに定義されたルールの実行をシミュレートすることができる。

【0568】

注目すべきことに、アプリケーション選択ＧＵＩにより、メタデータルールユーザ１５５０は、「銀行レコードアプリケーション（bank record application）」などの特定のアプリケーションに関連づけられたトランザクションに適用されるべきルールを作成することができ、該アプリケーションはここで、アプリケーション選択ＧＵＩ内で選択されたものとして示されている。しかしながら、ブロックチェーン上の特定のトランザクションに、又はブロックチェーン上の全てのトランザクションに適用されるメタデータルールを有することも許容される。

【0569】

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

【0570】

再度、メタデータルールユーザ１５５０がコンピューティングデバイス１５９９を利用し、具体的にグラフィカルユーザインターフェース（ＧＵＩ）１５１０を利用して、ブロックチェーン上で発生するトランザクションに適用されるメタデータルールを構成することが示されている。

【0571】

前のＧＵＩは、メタデータルールユーザが新たに定義されたルールを適用し、又は、前に宣言された特定のアプリケーションに関連づけられたトランザクションに前に作成されたルールを適用することを可能にしたが、ここに示されるトランザクション選択ＧＵＩは、メタデータルールユーザ１５５０が、タイプにかかわらず、及びそのようなトランザクションが任意の宣言されたアプリケーションに期せずして関連づけられているかどうかにかかわらず、具体的に所与のタイプのトランザクションに、又はブロックチェーン上の全てのトランザクションにルールを適用することを可能にする。

【0572】

ここに示すように、新たに定義されたメタデータルールに対して、又は利用可能な前に定義されたメタデータルールに対して、様々な許容可能な構成がある。例えば、メタデータルールユーザ１５５０は、新規又は既存のルールを「全てのトランザクション‐事前実行（All transactions - Pre Execution）」に適用することができ、その場合、ルールは、説明されたように、トランザクション自体を実行する前にブロックチェーン上に到着するあらゆるトランザクションに対して実行される。このような事前実行ルールは、任意の定義された基準及び条件に利用されてよいが、理想的には検証手順に適し、例えば、英数字文字が数値フィールドに入力されていないこと、あるいは、日付フィールドに入力された日付が有効な日付フォーマットに対応し、又は許容可能な日数の範囲内などの特定の制限に準拠し、又は未来でない若しくは過去でない日付を表すことなどを検証することである。ブロックチェーンで受け取ったトランザクションの実行の前に生じるべきさらなる検証スキームには、例えば、アカウント保持者が要求された資金移転に利用可能な十分な資金を有することの検証を含んでもよい。例えば、ユーザが、１ビットコイン値又は何らかの他の単位の価値を別のユーザに移転したい場合、事前実行ルールは、ユーザ又はアカウント保持者が移転されるべき資金の額以上の資金を所有していることを検証するために、チェックすることができる。

【0573】

さらに、全てのトランザクションに対して事後実行メタデータルールが許容可能である。このようなルールは、ブロックチェーン上でトランザクションが発生した後に何らかのアクションをとるために利用することができ、例えば、通知をトリガすること、又はトランザクション要求元に確認を発行すること、又はトランザクションデータをログに、若しくは分析エンジンに、若しくはＡＩエンジン等にプッシュすることなどである。多くの可能性が存在するが、事後実行トランザクションに対するルール作成及び適用は、ルールが、トランザクションの実行後にブロックチェーン上のあらゆるトランザクションに、又は代替的に、ルールの条件及び基準に基づき、ブロックチェーン上のトランザクションの実行後に定義された基準及び条件に一致するブロックチェーン上のあらゆるトランザクションに適用されることを意味する。

【0574】

さらに、特定のトランザクションタイプ（事前又は事後のトランザクション実行のため）を有するトランザクションに対して、又は、特定のトランザクションタイプを有し、かつルール作成ＧＵＩで定められた定義ルールに従う特定の定義された基準及び条件を満たすトランザクションに対して、定義されたメタデータルールの適用が許容される。例えば、ここでは、メタデータルールユーザ１５５０が特定のルールの適用のために「ローン承認トランザクションタイプ（Loan Approval Transaction Type）」を選択していることが示されており、これは、ＧＵＩで示されているように、事前実行（pre-execution）についてブロックチェーンに期せずしてすでに定義及びデプロイされている。デプロイされた状態は、この既存のメタデータルールについて合意がすでに達せられていることを示し、一方、新たに定義されたルールは、ステータスが「デプロイ済み（deployed）」状態を示す前に合意が達せられる必要がある。

【0575】

最終的に、ＧＵＩは、メタデータルールユーザ１５５０により提供される入力されたデータを消費し、アプリケーションコードを自動生成する。例えば、ここに示される例示的なコードは、ＧＵＩにより出力され、合意とその後の合致するトランザクションに対する実行のためにブロックチェーン上へトランザクション処理され得る。

【表4】

【0576】

したがって、ここに示されるように、ＧＵＩは適切な構文を出力し、これは、この例によれば、「現在の在庫品」が５未満であるか、又は「当月」が１２月の状況で「現在の在庫品」が２０未満であるトランザクションに適用され、推定上、なぜならば、１２月の月には需要の急上昇があり、ゆえに、メタデータルール作成者が、在庫品が５未満に該当するときはいつでも、又は１２月の特別な状況では在庫品が２０未満に該当するときに、そのようなルールが適用されるべきと指示したためである。

【0577】

このような構文は、次いで、ブロックチェーンプラットフォーム非依存の構文をターゲットにされたブロックチェーンのネイティブブロックチェーン構文に変換するためにＡｐｅｘ翻訳エンジンを通して処理され得、上記ターゲットにされたブロックチェーンに対し、ルールが適用され、スマートコントラクトを介してそのそれぞれのブロックチェーン上で実行されることになり、これは、例えば、図４Ｃに示されているブロックチェーンへのメタデータの発行（デプロイメント）及びその取り出しと共に、図４Ａ及び４Ｂに関して前述したとおりである。

【0578】

構文に従うコードは、次いで、スマートコントラクト実行を介して必要なルールを実現する。注目すべきことに、このコードは、メタデータルールユーザ１５５０のためにＧＵＩインターフェースにより作成され、したがって、このようなルールの構成及び作成を大幅に簡素化する。

【0579】

ブロックチェーン技術の機能を活用しようとするビジネスユーザにとっての最大の問題の１つは、スマートコントラクト実行のためのビジネスルールの作成とプログラミングである。

【0580】

問題として、異なるブロックチェーンプラットフォームの各々は、そのようなビジネスルールを実行するための異なるスマートコントラクト要件を有しており、結果として、異なる構文、異なる許容可能な条件及び基準、並びに任意の作成されたルールをそれぞれのブロックチェーンにデプロイするための異なるメカニズムがもたらされる。

【0581】

結果的に、そのようなビジネスルールを実行するための検証スキーム及びワークフローはスマートコントラクトを介して書かれ、該スマートコントラクトは次いで、それぞれのブロックチェーンにデプロイされる。異なる構文のため、このようなルールは、具体的に、このようなルールが適用及び利用されるべき特定のブロックチェーンのために、プログラマ及び開発者により手動で書かれなければならない。

【0582】

したがって、説明される実施形態によれば、メタデータ駆動型ブロックチェーンプラットフォームを利用するメタデータルールユーザ、ブロックチェーン管理者、及びプログラマは、メタデータ駆動型ビジネスルールを作成することができ、該メタデータ駆動型ビジネスルールは次いで、同じスマートコントラクトを介してそれぞれのブロックチェーンプラットフォーム上で実行されるが、メタデータルールユーザ、ブロックチェーン管理者、及びプログラマがあらゆる異なるプラットフォームに対して異なるルール構文を作成する必要がない。

【0583】

したがって、ブロックチェーン管理者及びメタデータルールユーザは、それら独自のクラウド環境内のビジネスルールを、ホスト組織により提供されたＧＵＩを利用して定義することが許容され、これは次いで、そのようなルールを定義する必要な構文及びメタデータを生成し、これは次いで、メタデータとしてブロックチェーンに記憶されると共に、特定の実施形態によれば、ネイティブブロックチェーンスマートコントラクト実行フォーマットにコンバートされる。

【0584】

ブロックチェーンを利用するソフトウェアシステムが複雑さと使用法を増すとき、それは、システムのロジック及び／又は挙動に対するあらゆる変更が前に構成されたスマートコントラクト及びビジネスルールを破る場合に、ビジネスユーザにとって負担になる。したがって、ビジネスユーザは新しいコードを書き、デプロイする必要があり、これは、非中央集権的なネットワークでは、ビジネスユーザがしばしば、彼らが使用しているブロックチェーンプラットフォームがどのように及びいつ更新又は修正されるかを指示する立場にないことを考えると、重要な問題である。

【0585】

したがって、ブロックチェーンにおけるメタデータ駆動型ビジネスルールエンジンの使用は、このようなビジネスユーザに簡素なインターフェースを提供し、システムの挙動を定義する新しいルール及びロジックを誰でも捕捉できるようにし、これには、ＧＵＩの使用を通して非プログラマが含まれる。ブロックチェーンに書き込まれたメタデータにより表される、このようなルールは次いで、スマートコントラクト実行を介してブロックチェーンにより実行され得る。ブロックチェーンプラットフォームの挙動に対する変更が生じたとき、メタデータは再書き込み又は再コード化される必要はなく、むしろ、ブロックチェーンに記憶されたメタデータは、ブロックチェーンプラットフォームの新しい挙動に従って単に読み取られ、実行され、なぜならば、定義されたメタデータルールは、基礎をなすブロックチェーンプラットフォームに対するそのような変更に関して不可知的であるためである。しかしながら、特定の状況では、ホスト組織のブロックチェーンメタデータ定義マネージャ１９６は、定義されたメタデータルールの、問題のブロックチェーンのネイティブスマートコントラクト実行可能コードへの再コンバージョンをトリガする必要があり得るが、そのようなイベントは自動化され得、ビジネスユーザの側の特定のアクションを必要とせず、確かに、ビジネスユーザがそのようなルールを実現するためにそれらのビジネスルール又は関連コードを再び書く必要はない。他の実施形態において、ブロックチェーンに書き込まれたメタデータは、ビジネスルールが適用された特定のブロックチェーンプラットフォームの能力に依存して、ホスト組織又はビジネスユーザによるアクションなく、スマートコントラクト実行エンジンにより単に再び読み取られ、ブロックチェーンのバックエンドプロセッサで適切に解釈及び実行され得る。

【0586】

特定の実施形態によれば、ブロックチェーン管理者は、図１５Ａにおけるアプリケーション選択ＧＵＩを介して選択されたものなどの特定の宣言されたアプリケーション（ＤＡｐｐ）のためのマーケティングロジック及びビジネスルールを定義することができる。例えば、適切なパーミッションを有するブロックチェーン管理者又は他のメタデータルールユーザは、次いで、ブロックチェーン内のトランザクションに基づいて、特定の顧客又はアイテムがいつ割引きに適格であるかを指定する条件を定義することができる。条件は、特定の顧客、又は特定のアイテム、又は特定の基準について、例えば、在庫水準、日付範囲、又はビジネスの目標のニーズのビジネスロジックが適する何にでも指定することができる。

【0587】

通常、このようなビジネスルールの作成は、ブロックチェーンプラットフォームのスマートコントラクト実行エンジンを介した実行のために、特化された構文をプログラマにより開発する必要があり、そのような構文は、異なるブロックチェーンプラットフォームでは異なる。しかしながら、メタデータルールユーザ又はブロックチェーン管理者が、ホスト組織のブロックチェーンサービススイートにより提供されるブロックチェーンメタデータ定義マネージャ１９６を利用する場合、ブロックチェーン管理者は、ＧＵＩを介してルールを定義すればよく、これらを特定の宣言されたアプリケーション又は特定のタイプのトランザクション（又は、全てのトランザクション）に関連づけ、次いで、サブミットされたルールがひとたびブロックチェーンネットワークの合意メカニズムにより承認されると、定義されたルールは、ホスト組織のブロックチェーンサービスインターフェース並びに関連するスマートコントラクト実行及び管理エンジンにより自動的に実行される。

【0588】

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

【0589】

ここに示されるように、メタデータルールプログラマ１５５１又は開発者がルール構文を手動で作成したい場合、又は別のアプリケーションが適切な構文をメタデータルール作成エンジンにプッシュするために利用される場合に、メタデータルールユーザによる、アプリケーションプログラミングインターフェース（ＡＰＩ）１５１１を介した、メタデータルールの許容可能なエントリがさらにあり、これは、メタデータルールユーザがＧＵＩを介してそのようなルールを構成する場合と同じ効果で、メタデータルールＡＰＩを介して許容される方法で達成され得る。

【0590】

そのようなメタデータルールがどのように書かれるかにかかわらず、それが提供されるＧＵＩ又はＡＰＩインターフェースを介する場合、定義されたルールは、アプリケーションにサブミットされたデータエントリ及び入力に対する検証要件を強制するために、あるいは上述したような特定の顧客のための又は特定の在庫水準に基づく商品の割引きなどの様々な実行フローをトリガするために利用され得る。

【0591】

ひとたび定義されると、ブロックチェーンに書き込まれたメタデータルールは、利用可能な場合にはブロックチェーンのスマートコントラクト実行エンジンを使用してブロックチェーンネットワークレベルで実行され、あるいは、そのような能力がブロックチェーンプラットフォームを介して利用できないときにはホスト組織のスマートコントラクト実行エンジンを介して実行される。

【0592】

そのようなメタデータルール駆動型のスマートコントラクトを利用し、例示的な検証には、例えば、誤ったデータのエントリ（例えば、誤った桁数の電話番号、又は誤った電子メールアドレス等）、又は不適切な型のデータのエントリ、例えば数字のみのフィールドへの英字の入力などの禁止を含んでもよい。

【0593】

しかしながら、かなりしばしば、ルールは検証特有のものではなく、ブロックチェーンメタデータ定義マネージャ１９６を介して定義されるより複雑なビジネスルールを表す。例えば、在庫品の適用例で上述したように、在庫水準が高すぎること又は在庫水準が低下していること等に基づいて取られる様々なアクションがあり得る。したがって、このようなメタデータルールは、複数のパートナーにわたるストック水準の管理に利用することができ、パートナーの各々は、それら独自のローカルの在庫品を有し得るが、パートナーに対して、ルールは総計の在庫品等に基づいて適用される。

【0594】

従来のソリューションでは、プログラマ及び開発者がルールをスマートコントラクト実行のためのネイティブブロックチェーン実行可能フォーマットにコード化する必要があり、そのプロセスは複雑で、エラーを起こしやすく、まさにそのようなルールを作成及び定義する可能性が最も高い個人である初心者又は非プログラマのビジネスユーザにとって単純に利用できなかった。したがって、この構成は、ブロックチェーン技術を利用し、スマートコントラクト実行の能力を活用することを望む企業の側にコストと複雑さを加え、なぜならば、エラーの高い可能性の問題に対処せずに、エンジンへのルールをコード化するために高度に熟練した開発者に支払う必要があったためである。

【0595】

メタデータルールが、ブロックチェーン非依存のフォーマットを利用して定義され、ブロックチェーンに書き込まれるため、同じメタデータルールが１回作成され、次いで複数の異なるブロックチェーンプラットフォームに適用されることが可能である。さらに、ＵＩが、ユーザが完全な構文を（ＧＵＩ又はＡＰＩを介して）作成することを可能にするため、ＧＵＩ条件ビルダが、ビジネス開発者のニーズに特有の条件を指定し、又はＡＰＩを通じてそのような条件をプログラムすることがさらに可能である。

【0596】

またさらに、ＧＵＩ又はＡＰＩが利用されるかどうかにかかわらず、定義されたメタデータルールは、関連するアプリケーションに対して、又は関連するトランザクションに対して許容可能なエンティティ、フィールド定義、及びフィールドタイプの作成に制限され、なぜならば、メタデータ駆動型ブロックチェーンプラットフォームは、宣言されたアプリケーション、又は宣言されたエンティティ、又はその従属するフィールド定義及びフィールドタイプに対して定義されたメタデータに違反するルール又は条件の作成を許可しないためである。

【0597】

このようにして、メタデータルールの作成は、ブロックチェーン管理者又はメタデータルールユーザが相互作用するためのパーミッションを有する、及びそのような定義されたビジネスルールが関連する宣言されたアプリケーション（ＤＡｐｐ）、エンティティなどのメタデータに準拠している、条件、基準、トランザクション、及び宣言されたアプリケーションに制限される。

【0598】

したがって、メタデータルールの定義を、既存のアプリケーション、エンティティ、トランザクションタイプなどの前に定義されたメタデータ定義に準拠する許容可能なエントリのみに制限することにより、そのようなルールのコードが自由形式で書かれた場合に発生し得るセキュリティホール、論理エラー、又は他の不正な形式のビジネスルールの可能性を大幅に低減することがさらに可能であり、これは、そのようなメタデータ定義に、又は条件ビルダＧＵＩ上の許容可能な基準に制限されない。

【0599】

さらに別の実施形態によれば、ひとたびメタデータルールコードがＧＵＩから出力され、あるいはＡＰＩにより受け入れられると、それは次いで、メタデータルールコードがブロックチェーンにサブミットされる前に、メタデータ管理モデルを通じて処理され、トラバースされる。

【0600】

次いで、管理モデルを通じてコードを処理することにより、メタデータルールを作成したメタデータルールユーザ又はブロックチェーン管理者に、作成されたコードがブロックチェーントランザクション及び資産にどのように影響するかについての情報を提示し、したがって、ユーザは、シミュレートされた又はサンドボックスの環境内でオンザフライで（on the fly）、ルールがブロックチェーントランザクションに対して実行されたときどのように機能するかを確認することができる。例えば、管理モデル及びルールシミュレーションは、特定の値を模倣又はシミュレートして、ルールがブロックチェーン上で実行されたとき何を作成するか、及びデータ、資産、及びトランザクション実行がブロックチェーン上でどのように影響を受けるかを示すことができる。

【0601】

別の実施形態によれば、ひとたびコードが作成され、管理モデルを通じて処理されると、ユーザは、メタデータルール及びそのようなルールを定義するコードがブロックチェーン上に受け入れられる前に、評価及び合意のために、コードをブロックチェーンプラットフォーム上のパートナーにサブミットすることができる（例えば、コードを他のブロックチェーン参加ノードにサブミットする）。

【0602】

このような実施形態によれば、ブロックチェーン上のパートナー及び参加ノードは、ブロックチェーン上で何も実際に実行することなく、同じ管理モデルを適用し、また、作成されたメタデータルールの実行をシミュレートして、ルールがブロックチェーンのデータ、資産、及びトランザクションにどのように影響するかを観測することができる。

【0603】

シミュレートされた実行に基づいて、パートナー及び参加ノードは次いで、定義されたメタデータルールがブロックチェーン上で受け入れられるか否かを決定するために、合意のために投票し、あるいはルールなどを拒否するために投票することができる。

【0604】

特定の実施形態によれば、ルールのためのコード及び構文は、ＪＳＯＮ互換フォーマットで作成されるが、その後、合意の後にブロックチェーン上に書き込まれるときＷｅｂアセンブリ言語に翻訳され、したがって、ブロックチェーン上へひとたびデプロイされると誰にも変更できないコントラクトの暗号学的特性を有するより安全なバイナリフォーマットをとる。言い換えると、参加ノードの全ては、デプロイされ及び受け入れられたコードをＷｅｂアセンブリ言語フォーマットで見ることができるが、これらはそれを変更できず、ルールの作成／編集、メタデータ定義に対する検証、管理への従属、及び合意のための再度のサブミットとその後のブロックチェーン上での受け入れの全体を通じて再度進むことはない。

【0605】

ＷｅｂＡｓｓｅｍｂｌｙ（Ｗａｓｍ又はＷＡＳＭとしばしば短縮される）は、Ｗｅｂページにより使用される実行ファイルのためのバイナリフォーマット及び対応するアセンブリ様のテキストフォーマットを定義する標準である。Ｗａｓｍの目的は、ＷｅｂブラウザのＪａｖａＳｃｒｉｐｔエンジンがネイティブマシンコードとほぼ同じ速さでページスクリプトを実行できるようにすることである。ＪａｖａＳｃｒｉｐｔの完全な置き換えではないが、Ｗａｓｍは、ページスクリプトのパフォーマンスに不可欠な部分の実行の改善を提供し、通常のスクリプトコードと同じサンドボックス内で実行される。

【0606】

ＷｅｂＡｓｓｅｍｂｌｙコード又はＷａｓｍコードの表現は、ＪａｖａＳｃｒｉｐｔをパースするよりも速いように、並びに実行するのにより速く、極めてコンパクトなコード表現に従うように設計された、ポータブルな抽象構造化スタックマシン上で実行されることが意図されている。

【0607】

ひとたびブロックチェーンに受け入れられると、スマートコントラクトは、トランザクションタイプに基づいて、又は全てのトランザクションに基づいて、又は定義された基準及び条件が何であれ定義され受け入れられたことに基づいて、トリガされ、実行される。

【0608】

そのような実施形態によれば、スマートコントラクトの実行は、ブロックチェーン上の複数のノードにより、又はブロックチェーン上の全てのノードにより実行され、次いで、出力が複数のブロックチェーンノードにより比較されて、同時実行からの出力が同一であることを保証し、改ざん、又はなりすましの試み、又は悪意のある若しくは詐欺的なスマートコントラクト実行出力の真正としてのサブミットを防止する。

【0609】

スマートコントラクトを実行した複数の参加ノードについて出力が同一であると仮定すると、合意は満たされ、スマートコントラクト実行の結果又は出力はブロックチェーン上に受け入れられる。

【0610】

上述のように、事前及び事後双方のトランザクション実行構成が可能にされ、これにおいて、事前実行は、典型的には、ブロックチェーンで受け取ったトランザクションをちょうど実行しようとする前の、データの検証に対して好ましく、事後実行は、イベント又はトランザクションが特定の方法で発生し、次いでトランザクションの実行の後にスマートコントラクトを介して何らかのアクションをとるか否かを評価するために利用される。

【0611】

メタデータルールは、オンザフライでメタデータ駆動型及び宣言型であると考えられ、なぜならば、ルールは、条件ビルダを利用して作成され、トランザクション又はルール実行がサンドボックス環境内でどのように見えるかをテストするためにシミュレートされ得るためである。このようにして、ブロックチェーン上のパートナー及びその他の参加ノードは、彼らも、コストがかかり、時間がかかり、負担のかかるプロセスで数千行のコードをレビューするためにプログラマ又は開発者に支払う必要なくＧＵＩを介してルールをレビューすることができるため、安心し、したがって、これは次に、ＧＵＩ及びＡＰＩからスマートコントラクトにコード化できる条件及び値を、特定のトランザクションに対して宣言されたアプリケーション又はその関連するエンティティ又はエンティティ及びフィールド定義等に対する定義されたメタデータと互換性があるものに制限することにより、セキュリティを大幅に改善する。

【0612】

さらに、コードはＷｅｂＡｓｓｅｍｂｌｙ（ＷＡＳＭ）フォーマットにコンバートされ、バイナリとして表現されるため、それは改ざん及び悪意のある行為者から安全である。

【0613】

またさらなる実施形態によれば、メタデータルールを介して指定される条件はさらに、ブロックチェーン上のトランザクションが宣言されたアプリケーションの「所有者」によるものか、又は宣言されたアプリケーション（ＤＡｐｐ）の「当事者」によるものかによって制限される。例えば、アプリケーションの所有者は、例えば、ブロックチェーン上へトランザクション処理されたレコードを修正する強化された権利を有してもよく、一方、宣言されたアプリケーションに対して認可されたネットワーク参加者は、単にアプリケーションの「当事者」であってよく、ゆえに、レコードを読み取ると共に新規レコードを作成し、レコードのさらなる情報をサブミットするパーミッションを有し得るが、おそらくこれらは、特定のレコードを修正又は改変する権限を欠き、したがって、ブロックチェーン上のデータに対するパーミッション強制メカニズムを可能にし、これにおいて、メタデータルールは、例えば、既存のレコードを変更しようとするトランザクションが、事前トランザクション実行スマートコントラクトにおいて、トランザクションサブミット者がアプリケーションの単に「当事者」ではなくアプリケーションの「所有者」であることを最初に「検証」しなければならないことを要求するルールを定義する。パーミッション強制の多くの他のバリエーションが可能である。またさらに、そのようなルールは、「所有者」ではない「当事者」がレコード変更トランザクションをサブミットしたとき通知をトリガするために利用されてもよく、定義されたメタデータにより、ルールは次いで、そのトランザクションが処理されるか否か、又は拒絶されるか否かを定義する。

【0614】

図１６は、クラウドベースのオンデマンドの機能性をユーザ、顧客、及びサブスクライバに提供するような機能性を実行するためにプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境と関連して分散台帳技術（ＤＬＴ）を使用して宣言型及びメタデータ駆動型のブロックチェーンプラットフォームを実施する方法１６００を示すフロー図を示す。

【0615】

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

【0616】

図１６に示す方法１６００を参照し、ブロック１６０５で開始し、ホスト組織のシステムによる、新しいアプリケーションを宣言し、新しいアプリケーションに対して定義されたメタデータをブロックチェーン上へトランザクション処理するための動作が、以下の動作により説明される。

【0617】

ブロック１６１０において、処理論理は、ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを動作させ、複数のテナントの各テナントは、ブロックチェーンへのアクセスを有する参加ノードとして動作する。

【0618】

ブロック１６１５において、処理論理は、システムと通信上インターフェースされたユーザデバイスから、新しいアプリケーションを宣言する第１の入力を受信する。

【0619】

ブロック１６２０において、処理論理は、新しいアプリケーションのために複数のネットワーク参加者を追加する、ユーザデバイスからの第２の入力を受信し、ネットワーク参加者は、新しいアプリケーションへのアクセス権を付与される。

【0620】

ブロック１６２５において、処理論理は、新しいアプリケーションのための複数のエンティティタイプを宣言する、ユーザデバイスからの第３の入力を受信する。

【0621】

ブロック１６３０において、処理論理は、複数のエンティティタイプの各々についての１つ以上の新しいフィールド定義を宣言する、ユーザデバイスからの第４の入力を受信する。

【0622】

ブロック１６３５において、処理論理は、新しいアプリケーションに対して定義されたメタデータとして少なくとも（ｉ）宣言された複数のネットワーク参加者、（ｉｉ）宣言された複数のエンティティタイプ、及び（ｉｉｉ）複数のエンティティタイプの各々に対して宣言された１つ以上の新しいフィールド定義をその中に符号化されたブロックチェーン資産を生成する。

【0623】

ブロック１６４０において、処理論理は、新しいアプリケーションに対して定義されたメタデータをその中に符号化されたブロックチェーン資産をブロックチェーン上へトランザクション処理する。

【0624】

図１７は、クラウドベースのオンデマンドの機能性をユーザ、顧客、及びサブスクライバに提供するような機能性を実行するためにプロセッサ及びメモリによりサポートされるデータベースシステム実装などのクラウドベースのコンピューティング環境と関連して宣言型の、メタデータ駆動型の、暗号的に立証可能なマルチネットワーク（マルチテナント）共有台帳を実施する方法１７００を示すフロー図を示す。

【0625】

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

【0626】

図１７に示す方法１７００を参照し、ブロック１７０５で開始し、処理論理は、共有台帳に対する複数の認可されたネットワーク参加者のために共有台帳へのインターフェースを動作させ、共有台帳は、複数の分散された共有台帳ノードを介してデータを永続化する（persists）。

【0627】

ブロック１７１０において、処理論理は、複数の認可されたネットワーク参加者のうちの最初の認可されたネットワーク参加者としての創設者ｏｒｇのためにデータを記憶するために、共有台帳内にネットワークｏｒｇを生成する。

【0628】

ブロック１７１５において、処理論理は、ネットワークｏｒｇに対するさらなる認可されたネットワーク参加者としての複数のパートナーｏｒｇを定義する、創設者ｏｒｇからの入力を受信し、認可されたネットワーク参加者の全てが、データを複製することなく共有台帳を介してネットワークｏｒｇにより記憶されたデータへの読み取りアクセスを有する。

【0629】

ブロック１７２０において、処理論理は、パートナーｏｒｇの各々が共有台帳内のネットワークｏｒｇと相互作用するためのパーミッションを定義する、創設者ｏｒｇからの入力を受信する。

【0630】

ブロック１７２５において、処理論理は、共有台帳に、少なくともネットワークｏｒｇに対して認可されたネットワーク参加者と、パートナーｏｒｇの各々に対して定義されたパーミッションとを定義するメタデータを書き込む。

【0631】

ブロック１７３０において、処理論理は、認可されたネットワーク参加者からの、ネットワークｏｒｇと相互作用する要求を受信する。

【0632】

ブロック１７３５において、処理論理は、要求の遂行において共有台帳との間でトランザクション処理する。

【0633】

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

【0634】

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

【0635】

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

【0636】

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

【0637】

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

【0638】

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

【0639】

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

【0640】

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

【0641】

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

【0642】

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

【0643】

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

【0644】

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

【0645】

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

【0646】

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

【0647】

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

【0648】

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

【0649】

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

【0650】

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

【0651】

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

【0652】

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

【0653】

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

【0654】

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

【0655】

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

【0656】

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

【0657】

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

【0658】

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

【0659】

実施形態

【0660】

実施形態Ａ － ブロックチェーン内のデータを忘れる権利を提供するためにホスト組織のシステムにより実行される方法であって、前記システムは、各々がブロックチェーンネットワーク内のノードとして機能する前記ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを提供し、当該方法は、要求元の識別子を含む要求を受信するステップであり、前記要求はプライベートとして指定されたトランザクションデータにアクセスするためのものである、ステップと、前記要求元の前記識別子を含む、前記ブロックチェーンネットワーク内のノードからの前記トランザクションデータへのアクセスを要求するステップと、前記要求元により前記トランザクションデータにアクセスすることへの合意を示す、前記ブロックチェーンネットワーク内のノードからの少なくとも１つの共有秘密を受信するステップと、前記トランザクションデータがアクセスするのに恒久的に（permanently）利用できないことを示す、前記ノードからの不十分な共有秘密を受信することに応答して、前記トランザクションデータへのアクセスを拒否するステップと、を含む。

【0661】

実施形態Ａの方法であって、当該方法は、前記トランザクションデータへのアクセスを要求する前に、前記要求元の前記識別子が忘れられたリスト（forgotten list）上にあるかどうかを決定するステップをさらに含む。

【0662】

実施形態Ａの方法であって、当該方法は、一意ユーザ識別子に関連づけられたデータを忘れる要求を受信するステップと、前記一意ユーザ識別子を忘れられたリストに追加するステップと、をさらに含む。

【0663】

実施形態Ａの方法であって、前記トランザクションデータは、閾値数の共有秘密を受信することに応答して復号される。

【0664】

実施形態Ａの方法であって、復号鍵は、受信した共有秘密から復元される。

【0665】

実施形態Ａの方法であって、前記トランザクションデータへのアクセスを拒否することは、受信した共有秘密の数が暗号化の鍵を復元するための閾値を下回ることに応答したものである。

【0666】

実施形態Ａの方法であって、オブジェクト及びフィールドのプライベート情報の識別を含む、前記ブロックチェーンに記憶される前記トランザクションデータのオブジェクト及びメタデータを定義するステップをさらに含む。

【0667】

実施形態Ｂ － ブロックチェーン内のデータを忘れる権利を提供する方法を実行するように構成されたホスト組織のコンピューティングシステムであって、当該コンピュータシステムは、各々がブロックチェーンネットワーク内のノードとして機能するホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを提供し、前記ブロックチェーンインターフェース及びパーミッションマネージャを内部に記憶させたコンピュータ読取可能媒体手段と、前記ブロックチェーンインターフェースに結合されたプロセッサと、を含み、前記プロセッサは、前記ブロックチェーンインターフェース及び前記パーミッションマネージャを実行するように構成され、前記パーミッションマネージャは、要求元の識別子を含む要求を受信し、前記要求はプライベートとして指定されたトランザクションデータにアクセスするためのものであり、前記要求元の前記識別子を含む、前記ブロックチェーンネットワーク内のノードからの前記トランザクションデータへのアクセスを要求し、前記要求元により前記トランザクションデータにアクセスすることへの合意を示す、前記ブロックチェーンネットワーク内のノードからの少なくとも１つの共有秘密を受信し、前記トランザクションデータがアクセスするのに恒久的に利用できないことを示す、前記ノードからの不十分な共有秘密を受信することに応答して、前記トランザクションデータへのアクセスを拒否する。

【0668】

実施形態Ｂのコンピュータシステムであって、前記パーミッションマネージャはさらに、前記トランザクションデータへのアクセスを要求する前に、前記要求元の前記識別子が忘れられたリスト上にあるかどうかを決定する。

【0669】

実施形態Ｂのコンピュータシステムであって、前記パーミッションマネージャはさらに、一意ユーザ識別子に関連づけられたデータを忘れる要求を受信し、前記一意ユーザ識別子を忘れられたリストに追加する。

【0670】

実施形態Ｂのコンピュータシステムであって、前記トランザクションデータは、閾値数の共有秘密を受信することに応答して復号される。

【0671】

実施形態Ｂのコンピュータシステムであって、復号鍵は、受信した共有秘密から復元される。

【0672】

実施形態Ｂのコンピュータシステムであって、前記トランザクションデータへのアクセスを拒否することは、受信した共有秘密の数が暗号化の鍵を復元するための閾値を下回ることに応答したものである。

【0673】

実施形態Ｂのコンピュータシステムであって、前記パーミッションマネージャはさらに、オブジェクト及びフィールドのプライベート情報の識別を含む、前記ブロックチェーンに記憶される前記トランザクションデータのオブジェクト及びメタデータを定義する。

【0674】

実施形態Ｃ － 命令のセットを内部に記憶させたコンピュータ読取可能媒体であって、前記命令は実行されると、ホスト組織のコンピュータシステムにブロックチェーン内のデータの読み取りアクセスを管理する方法の動作のセットを実行させ、前記コンピュータシステムは、前記ホスト組織の複数のテナントのためにブロックチェーンに対するブロックチェーンインターフェースを提供し、前記動作のセットは、要求元の識別子を含む要求を受信することであり、前記要求はプライベートとして指定されたトランザクションデータにアクセスするためのものである、ことと、前記要求元の前記識別子を含む、前記ブロックチェーンネットワーク内のノードからの前記トランザクションデータへのアクセスを要求することと、前記要求元により前記トランザクションデータにアクセスすることへの合意を示す、前記ブロックチェーンネットワーク内のノードからの少なくとも１つの共有秘密を受信することと、前記トランザクションデータがアクセスするのに恒久的に利用できないことを示す、前記ノードからの不十分な共有秘密を受信することに応答して、前記トランザクションデータへのアクセスを拒否することと、を含む。

【0675】

実施形態Ｃのコンピュータ読取可能媒体であって、前記動作は、前記トランザクションデータへのアクセスを要求する前に、前記要求元の前記識別子が忘れられたリスト上にあるかどうかを決定することをさらに含む。

【0676】

実施形態Ｃのコンピュータ読取可能媒体であって、前記動作は、一意ユーザ識別子に関連づけられたデータを忘れる要求を受信することと、前記一意ユーザ識別子を忘れられたリストに追加することと、をさらに含む。

【0677】

実施形態Ｃのコンピュータ読取可能媒体であって、前記トランザクションデータは、閾値数の共有秘密を受信することに応答して復号される。

【0678】

実施形態Ｃのコンピュータ読取可能媒体であって、復号鍵は、受信した共有秘密から復元される。

【0679】

実施形態Ｃのコンピュータ読取可能媒体であって、前記トランザクションデータへのアクセスを拒否することは、受信した共有秘密の数が暗号化の鍵を復元するための閾値を下回ることに応答したものである。

【0680】

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

【0681】

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

【0682】

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

【0683】

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

【0684】

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

【0685】

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

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図3D】

【図4A】

【図4B】

【図4C】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図7A】

【図7B】

【図7C】

【図8A】

【図8B】

【図8C】

【図8D】

【図8E】

【図8F】

【図9A】

【図9B】

【図9C】

【図10】

【図11A】

【図11B】

【図11C】

【図11D】

【図12A】

【図12B】

【図12C】

【図12D】

【図13】

【図14】

【図15A】

【図15B】

【図15C】

【図16】

【図17】

【図18A】

【図18B】

【図19】