JP2023524659A - 低信頼の特権アクセス管理 - Google Patents

Abstract

アクセス管理プロセス調整方法、アクセス管理制御オーケストレータ、およびコンピュータ・プログラム製品。１つの実施形態は、情報システムの管理されたリソースにアクセスするための要求を受信することと、アクセス・マネージャからのリソースにアクセスするための許可を問い合わせることと、許可の問い合わせに応答して、管理されたリソースに対するアクセス権限を付与するように、アクセス制御ポリシーの更新を要求することとを含んでよい。要求を受信すること、許可を問い合わせること、およびアクセス制御ポリシーの更新を要求することは、トランザクション・レコードを生成すること、およびトランザクション・レコードを分散型台帳に追加することを含んでよく、分散型台帳は、ネットワーク全体にわたる複数のノードで、トランザクション・レコードを同時に維持する。

Description

本開示は、コンピュータ・セキュリティに関し、より詳細には、機密データを格納／処理する重要なＩＴシステム上の特権機能および管理機能へのアクセスを調整することに関する。

コンピュータ時代の始まりとして、１９４８年のエドバック（ＥＤＶＡＣ：Electronic Discrete Variable Automatic Computer）システムの開発が引用されることが多い。そのとき以来、コンピュータ・システムは極めて複雑なデバイスに進化した。現在のコンピュータ・システムは、通常、洗練されたハードウェア・コンポーネントおよびソフトウェア・コンポーネント、アプリケーション・プログラム、オペレーティング・システム、プロセッサ、バス、メモリ、入出力デバイスなどの組合せを含む。半導体処理およびコンピュータ・アーキテクチャにおける進歩がコンピュータの性能をますます向上させるにつれて、より高性能なハードウェアを利用するために、さらにいっそう高度なコンピュータ・ソフトウェアが発達し、ほんの数年前のコンピュータ・システムよりはるかに強力な現在のコンピュータ・システムをもたらした。

現在のコンピュータ・システムは、技術的進歩にとって不可欠であり、日常生活の重要な部分になった。その結果、これらのコンピューティング・システムのセキュリティの技術的問題の重要性が増した。コンピュータ・セキュリティの重要な一面は、特権アクセス管理および特権アカウント管理である。特権ユーザは、コンピューティング・システム内でより高いレベルのアクセス権限を持っているユーザ（例えば、システムの管理者または「ルート」スーパーユーザ）、または特殊なレベルのアクセス権限（例えば、機密情報を含むファイルを読み取り、書き込む能力）を持っているユーザ、あるいはその両方である。さらに、特権アクセス管理および特権アカウント管理は、一般に、システムおよびデータのアクセス権限をそれらの特権ユーザに提供するアカウントを管理し、監査することを含む。

本開示の実施形態による、アクセス管理プロセス調整方法（access management process orchestration method）。１つの実施形態は、情報システムの管理されたリソースにアクセスするための要求を受信することと、アクセス・マネージャからのリソースにアクセスするための許可を問い合わせることと、許可の問い合わせに応答して、管理されたリソースに対するアクセス権限を付与するように、アクセス制御ポリシーの更新を要求することとを含んでよい。要求を受信すること、許可を問い合わせること、およびアクセス制御ポリシーの更新を要求することは、トランザクション・レコードを生成すること、およびトランザクション・レコードを分散型台帳に追加することを含んでよく、分散型台帳は、ネットワーク全体にわたる複数のノードで、トランザクション・レコードを同時に維持する。

本開示の実施形態によれば、アクセス管理制御オーケストレータが、ブロックチェーン・ネットワークに関連付けられたピア・ノードを含み、ブロックチェーン・ネットワークが、アセット所有者機能、管理者機能、および監査人機能のうちの少なくとも１つに関連付けられた複数のノードを含む。ピア・ノードは、情報システムのユーザからのアクセス権限要求レコードを分散型台帳に記録することと、アセット所有者機能からの所有者承認レコードを記録することであって、所有者承認レコードが、分散型台帳内のアクセス権限要求レコードに応答する、記録することと、アクセス権限要求レコードおよび所有者承認レコードに応答してスマート・コントラクトを実行し、情報システムに対するアクセス権限を付与することであって、スマート・コントラクトが、情報システムに対するユーザのアクセス権限を許可するように許可ポリシーを変更する、付与することと、スマート・コントラクトの実行レコードを分散型台帳に記録することとを実行するように適応されてよい。

本開示の実施形態によれば、コンピュータ・プログラム製品が、複数の命令が格納されている非一過性コンピュータ可読ストレージ媒体を備える。命令は、プロセッサによって実行された場合に、プロセッサに、情報システムの管理されたリソースにアクセスするための要求を受信することと、アクセス・マネージャからのリソースにアクセスするための許可を問い合わせることと、許可の問い合わせに応答して、管理されたリソースに対するアクセス権限を付与するように、アクセス制御ポリシーの更新を要求することとを実行させてよい。要求を受信すること、許可を問い合わせること、およびアクセス制御ポリシーの更新を要求することは、トランザクション・レコードを生成すること、およびトランザクション・レコードを分散型台帳に追加することを含んでよい。

上記の概要は、本開示の各実施形態例もすべての実装も説明するよう意図されていない。

本出願に含まれている図面は、本明細書に組み込まれ、本明細書の一部を形成する。図面は、説明と共に本開示の実施形態を示し、本開示の原理を説明するのに役立つ。図面は、特定の実施形態の単なる例であり、本開示を限定していない。

一部の実施形態と一致する、クラウド・コンピューティング環境を示す図である。 一部の実施形態と一致する、抽象モデル・レイヤを示す図である。 一部の実施形態と一致する、データ処理システムを示す図である。 一部の実施形態と一致する、特権オーケストレータの概略図である。 一部の実施形態と一致する、例示的なブロックチェーン・アーキテクチャ構成を示す図である。 一部の実施形態と一致する、ブロックチェーン・トランザクション・フローを示す図である。 一部の実施形態と一致する、フロー図を示す図である。 一部の実施形態と一致する、さらなるフロー図を示す図である。 一部の実施形態と一致する、本明細書に記載された１つまたは複数の動作を実行するように構成された例示的なシステムを示す図である。 一部の実施形態と一致する、本明細書に記載された１つまたは複数の動作を実行するように構成された別の例示的なシステムを示す図である。 一部の実施形態と一致する、スマート・コントラクトを利用するように構成された、さらなる例示的なシステムを示す図である。 一部の実施形態と一致する、ブロックチェーンを含むシステムを示す図である。 実施形態例に従って、分散型台帳に追加されている新しいブロックに関するプロセスを示す図である。 実施形態例に従って、新しいデータ・ブロックの内容を示す図である。 実施形態例に従って、デジタル・コンテンツのためのブロックチェーンを示す図である。 実施形態例に従って、ブロックチェーン内のブロックの構造を表し得るブロックを示す図である。

本発明は、さまざまな変更および代替の形態を受け入れるが、その詳細が、図面において例として示されており、詳細に説明される。しかし、本発明を説明されている特定の実施形態に限定することが意図されていないということが、理解されるべきである。反対に、本発明の思想および範囲に含まれるすべての変更、均等物、および代替手段を対象にすることが意図されている。

本開示の態様は、コンピュータ・セキュリティに関し、より詳細な態様は、機密データを格納／処理する重要なＩＴシステム上の特権機能および管理機能へのアクセスを調整することに関する。本開示はそのような適用に必ずしも限定されないが、この文脈を使用するさまざまな実施例の説明を通じて、本開示のさまざまな態様が理解されてよい。

ＩＴセキュリティの１つの重要な側面は、機密データを格納／処理する重要なＩＴシステムに対して管理動作を実行できるユーザなどの、特権ユーザのアクセスを管理することである。ＩＴシステムに対する特権ユーザのアクセス権限は、認証ポリシーおよび許可ポリシーに基づいて、アクセス制御システムによって許可または拒否され得る。これらのポリシーは、一般に、ＩＴシステムの最高レベルの管理者によって設定される。

効果的なアクセス制御システムは、承認された変更のみが行われることを保証しようとして、セキュリティ・ポリシーに対する変更を制御しようと試みることがある（例えば、新しいオペレータが雇われた場合、オペレータの仕事を実行するためにＩＴシステムに対するアクセス権限が必要になる）。そして、セキュリティ・ポリシーに対するこれらの変更は、アクセス管理制御オーケストレータを介して、アクセス管理制御プロセスによって管理され得る。

さらに、ＩＴシステムに対するアクセス権限を管理するための一部のアクセス管理制御プロセスは、（ｉ）アクセス権限を要求すること、（ｉｉ）アクセス権限を承認すること、（ｉｉｉ）アクセス権限を付与すること、（ｉｖ）アクセス権限を再検討すること、（ｖ）アクセス権限を取り消すこと、および（ｖｉ）アクセス権限を許可することという動作のうちの１つまたは複数から成ってよい。一部のアクセス管理制御プロセスは、（ｉ）ＩＴシステムの所有者、（ｉｉ）ＩＴシステムに対するアクセス権限を必要とする特権ユーザ、（ｉｉｉ）特権ユーザに対してアクセス権限を許可または拒否する、ＩＴシステムに対するアクセス・ポリシーを制御するＩＴシステムのセキュリティの管理者、（ｉｖ）第三者監査機関、および（ｖ）アクセス管理プロセス・オーケストレータという実体のうちの１つまたは複数を含んでよい。一部の実施形態では、このプロセスは、次のワークフローを含んでよい。
１．ＩＴシステム内の管理されたアセットに対する許可を要求しているユーザが、通常は正当性を提供するアクセス権限の要求を、アクセス管理プロセス・オーケストレータに提出する。
２．プロセス・オーケストレータが、管理されたアセットまたはＩＴシステムあるいはその両方の所有者が誰であるかを決定し、要求をその所有者に転送する。
３．アセットまたはＩＴシステムあるいはその両方の所有者が、アクセス権限要求を受信し、正当性を再検討し、要求を承認または拒否することを決定し、承認／拒否された要求をプロセス・オーケストレータに返す。
４．要求が承認された場合、プロセス・オーケストレータが、アクセス権限付与要求を、管理されたアセットまたはＩＴシステムあるいはその両方に関連付けられた管理者またはローカル制御システムあるいはその両方に提出する。
５．管理者またはローカル制御システムあるいはその両方が要求を受信し、特権ユーザがシステムにログインしてアクセスできるようにする変更をシステムの許可ポリシーに適用することによって、アクセス権限を要求元のユーザに付与する。
６．要求動作、承認／拒否動作、アクセス権限付与動作が、プロセス・オーケストレータによって監査ログに記録される。
７．第三者監査機関が、（企業、政府、産業などの）規制に従ってアクセス権限が付与されたこと、およびすべてのポリシーが正しく適用されたことを再検討するために、プロセス・オーケストレータに対して監査ログを要求する。
特権ユーザが作業を完了し、アクセス権限をもはや必要としない場合、プロセス・オーケストレータは、アクセス権限取り消しを管理者またはローカル制御システムあるいはその両方に提出してよく、管理者またはローカル制御システムあるいはその両方は、変更をシステムのセキュリティに適用することによってアクセス権限を削除する。プロセス・オーケストレータは、アクセス権限を削除する要求を特権ユーザから受信する場合、アクセス権限に割り当てられた最大時間の期限が切れる場合、ＩＴシステムに対するアクセス権限を現在持っている特権ユーザがＩＴシステムにアクセスし続けるための有効な正当性をまだ有しているかどうかについて、特権ユーザのＩＴシステム所有者によって実行される定期的再検討の後、第三者監査機関の再検討の後（第三者監査機関は、セキュリティ・ポリシーの違反を識別していることがあり、アクセス権限の取り消しを要求するセキュリティ・インシデントを引き起こす）などに、取り消し要求をトリガーしてよい。

一部の実施形態では、アクセス管理制御オーケストレータは、これらの要求を受信して処理するシステムであってよい。これらの実施形態では、アクセス管理制御オーケストレータが要求を適切な所有者、管理者などに転送する。対象のシステムを管理する人または組織は、対象のシステムを所有している人または組織とは異なることができる：例えば、データベース・システムを所有し、外部セキュリティ組織を使用してプロセスを管理する銀行。ＩＴシステムの管理者は、プロセス・オーケストレータ組織によって管理者に転送されたアクセス権限付与要求についての判断もさらなる検証も伴わずに実行される、自動化されたシステムであってもよい。

一部の実施形態では、アクセス管理制御オーケストレータは、ネットワーク全体にわたる複数の位置でトランザクション・レコードを同時に維持することによって、権限を分散させ、すべての関与する関係者による操作に関する完全な透明性を保証する、分散型台帳（例えば、ブロックチェーン）を有利に含んでよい。特に、一部の実施形態は、許可ポリシーに対する変更を要求するために、アクセス管理制御オーケストレータがローカルＩＴシステムのアクセス制御システムの各々とインターフェイスをとることを含む、許可ポリシーに対する変更を要求する、承認する、許可する、取り消す、検証するなどの方法を調整するためのアクセス管理制御プロセスを提供してよい。このようにして、一部の実施形態は、各参加者が、他の関係者がアクセス管理プロセスを回避することができず、データ所有者によって承認が発行されなかったなどの場合でも、アクセス権限を付与／取り消すように従業員を強制する／だますこともできないということを知っているため、参加者間の完全な信用の代替手段を提供してよい。

ブロックチェーンを使用する一部のアクセス管理制御オーケストレータの実施形態の１つの利点は、アクセス管理システムの内部から来る攻撃（例えば、従業員の不正行為）に対する脆弱性を減らし得ることである。例えば、この特徴がなければ、組織内の従業員またはＩＴアセットを管理する外部組織にいる従業員あるいはその両方は、プロセスを改ざんし、セキュリティ・ポリシーに違反することができる十分な力を持ち得る。そのような環境下にある不正従業員は、（すなわち、システム所有者からの承認なしで）「アクセス権限付与」要求をＩＴシステムに送信し、そのアクセス権限の承認を隠蔽するか、または変更するように、監査ログを改ざんすることができる。ログの署名およびその他の改ざん防止技術でさえ、理論的には、十分な権限を持つ不正従業員によって、例えば、集中型システムが完全に所有している集中型システムのコード／構成をハッキングすること、不正ユーザのアクセス権限の取り消しを停止すること、セキュリティ・ポリシー違反を示さない改ざんされた監査ログを第三者監査人に提供することなどによって、回避されることができる。これに対して、ブロックチェーンを使用するアクセス管理制御オーケストレータは、所有者が明示的かつ透過的にアクセス権限を承認することなく、システムまたはデータあるいはその両方に対するアクセス権限が付与されることができないという信頼性を、ＩＴシステムの所有者、それらのＩＴシステムの管理者、またはデータ管理者、あるいはその組合せに提供し得る。ブロックチェーンを使用する実施形態は、文書化されたプロセスが回避されることができないと監査人およびレギュレータを安心させることに、さらに役立ち得る。これらの特徴および利点は、機密扱いの個人情報、規制の対象になるデータ、秘密情報、営業秘密情報などを伴う状況における特定の使用に関するものであってよい。

さらに、一部の実施形態は、誰も「ＡｃｃｅｓｓＡｐｐｒｏｖｅｄ」トランザクションおよび「ＧｒａｎｔＡｃｃｅｓｓ」トランザクションを偽造し、それらのトランザクションをブロックチェーン台帳に追加することができないということを保証してよい。誰かがノードをハッキングしてトランザクションを偽造し、それらのトランザクションを台帳に挿入した場合、これらの実施形態は、トランザクションを受け入れる合意に達しなくてよい。そしてこれは、一部の実施形態では、「アクセス・マネージャ」がもはや特権的役割である必要がなく、信頼される必要さえないため、望ましいことがある。すなわち、ＩＴ所有者は、異なる関係者によって制御された複数のノードによって、分散型台帳に受け入れたトランザクションの妥当性が確認されたということ、およびしたがって、どの承認も偽造されていないということを確信することができる。偽造されたトランザクションを提示できるコード・ハッキングからさらに保護するために、一部の実施形態は、所有者およびＩＴ管理者が、自分自身のプライベート・ノード（すなわち、コードの実装および構成を完全に制御するノード）を任意選択的にデプロイし、ブロックチェーン・ネットワークに追加することを可能にしてよい。このようにして、一部の実施形態は、各参加者が、個人または実体がアクセス管理プロセスを回避することができず、データ所有者によって承認が発行されなかった場合でも、アクセス権限を付与／取り消すように誰かを強制する／だますこともできないということを知っているため、参加者間の改善された信用を提供してよい。

一部の実施形態は、ＩＴ管理者が、対象のシステムの所有者によるＧｒａｎｔＡｃｃｅｓｓトランザクションおよび関連するＡｃｃｅｓｓＡｐｐｒｏｖｅｄトランザクションなどのトランザクションの妥当性を確認することを可能にしてよい。トランザクションが、ＩＴ管理者が持っている情報と矛盾している場合、ＩＴ管理者は許可を阻止することができる。このようにして、ＩＴ管理者が、台帳の一貫性を壊そうとするハッキング活動を疑った場合、ＩＴ管理者は、ネットワークから犯罪の源を単に切り離すことができ、または関連するアクセス・マネージャを禁止するようにネットワークに要求することができる（ブロックチェーン・ネットワークが合意に達した場合、このアクセス・マネージャはブロックチェーン・ネットワークから除去されることさえあり得る）。

一部の実施形態は、一連のトランザクションの監査が暗号によって保証され得るため、ブロックチェーン・システムによって、より良い監査可能性を提供してもよい。これらの実施形態では、分散型台帳は、変更不可能であってよく、したがって、受け入れられたトランザクションは、変更されること、ハッキングされることなどができない。さらに、ネットワークが、トランザクションが有効であるという合意に達した場合、かつその場合に限り、それらのトランザクションが分散型台帳に受け入れられるということが、保証されてよい。コードの変更、プロトコルのなりすまし／偽造などさえ伴って偽のトランザクションを台帳に侵入させようとしている攻撃者は、偽造されたトランザクションに関する合意を強制するために十分なネットワークのノードをハッキングすることが必要になる。この可能性の成功の確率は非常に低く、複数の（独立した）監査人がネットワークに参加しており、それらの監査人の大部分が同意することなく、合意が達せられないということを保証して、さらに減らされることができる。これらの実施形態では、トランザクションの妥当性を確認するためにネットワークに参加している監査組織は、偽造されたトランザクションを監査組織に提示できるコード・ハッキングからさらに保護するために、プライベート・ノード（コードの実装および構成を完全に制御するノード）をデプロイし、ブロックチェーン・ネットワークに追加することもできる。

一部の実施形態は、セキュリティ・プロセスを監視する分散システムの高可用性をさらに提供してよい。これらの実施形態では、１つまたは複数のノードの故障は、グローバル・ブロックチェーンの可用性に影響を与えず、クライアントは他のノードに接続することができる。

クラウド・コンピューティング
図１は、一部の実施形態と一致する、クラウド環境を示している。本開示にはクラウド・コンピューティングに関する詳細な説明が含まれているが、本明細書において示された教示の実装は、クラウド・コンピューティング環境に限定されないと理解されるべきである。むしろ、本発明の実施形態は、現在既知であるか、または今後開発される任意のその他の種類のコンピューティング環境と組み合わせて実装できる。

クラウド・コンピューティングは、構成可能な計算リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス提供モデルであり、管理上の手間またはサービス・プロバイダとのやりとりを最小限に抑えて、これらのリソースを迅速にプロビジョニングおよび解放することができる。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、および少なくとも４つのデプロイメント・モデルを含んでよい。

特徴は、次のとおりである。
・オンデマンドのセルフ・サービス：クラウドの利用者は、サーバの時間、ネットワーク・ストレージなどの計算能力を一方的に、サービス・プロバイダとの人間的なやりとりを必要とせず、必要に応じて自動的にプロビジョニングすることができる。
・幅広いネットワーク・アクセス：クラウドの能力は、ネットワークを経由して利用可能であり、標準的なメカニズムを使用してアクセスできるため、異種のシン・クライアントまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する。
・リソース・プール：プロバイダの計算リソースは、プールされ、マルチテナント・モデルを使用して複数の利用者に提供される。さまざまな物理的および仮想的リソースが、要求に従って動的に割り当ておよび再割り当てされる。場所に依存しないという感覚があり、利用者は通常、提供されるリソースの正確な場所に関して管理することも知ることもないが、さらに高い抽象レベルでは、場所（例えば、国、州、またはデータセンター）を指定できる場合がある。
・迅速な順応性：クラウドの能力は、迅速かつ柔軟に、場合によっては自動的にプロビジョニングされ、素早くスケールアウトし、迅速に解放されて素早くスケールインすることができる。プロビジョニングに使用できる能力は、利用者には、多くの場合、無制限に見え、任意の量をいつでも購入できる。
・測定されるサービス：クラウド・システムは、計測機能を活用することによって、サービスの種類（例えば、ストレージ、処理、帯域幅、およびアクティブな顧客のアカウント）に適した抽象レベルで、リソースの使用を自動的に制御および最適化する。リソースの使用状況は、監視、制御、および報告されることができ、利用されるサービスのプロバイダと利用者の両方に透明性を提供する。

サービス・モデルは、次のとおりである。
・ＳａａＳ（Software as a Service）：利用者に提供される能力は、クラウド・インフラストラクチャ上で稼働しているプロバイダのアプリケーションの利用である。それらのアプリケーションは、Ｗｅｂブラウザ（例えば、Ｗｅｂベースの電子メール）などのシン・クライアント・インターフェイスを介して、さまざまなクライアント・デバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能を含む基盤になるクラウド・インフラストラクチャを、限定的な顧客固有のアプリケーション構成設定を行う可能性を除き、管理することも制御することもない。
・ＰａａＳ（Platform as a Service）：利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成または取得したアプリケーションをクラウド・インフラストラクチャにデプロイすることである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、デプロイされたアプリケーション、および場合によってはアプリケーション・ホスティング環境の構成を制御することができる。
・ＩａａＳ（Infrastructure as a Service）：利用者に提供される能力は、処理、ストレージ、ネットワーク、およびその他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、およびデプロイされたアプリケーションを制御することができ、場合によっては、選択されたネットワーク・コンポーネント（例えば、ホスト・ファイアウォール）を限定的に制御できる。

デプロイメント・モデルは、次のとおりである。
・プライベート・クラウド：このクラウド・インフラストラクチャは、ある組織のためにのみ運用される。この組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
・コミュニティ・クラウド：このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項）を共有している特定のコミュニティをサポートする。これらの組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。
・パブリック・クラウド：このクラウド・インフラストラクチャは、一般大衆または大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。
・ハイブリッド・クラウド：このクラウド・インフラストラクチャは、データとアプリケーションの移植を可能にする標準化された技術または独自の技術（例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト）によって固有の実体を残したまま互いに結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合である。

クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで図１を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示されているように、クラウド・コンピューティング環境５０は、クラウドの利用者によって使用されるローカル・コンピューティング・デバイス（例えば、パーソナル・デジタル・アシスタント（ＰＤＡ：personal digital assistant）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはその組合せなど）が通信できる１つまたは複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信してよい。ノード１０は、１つまたは複数のネットワーク内で、本明細書において前述されたプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、またはハイブリッド・クラウド、あるいはこれらの組合せなどに、物理的または仮想的にグループ化されてよい（図示されていない）。これによって、クラウド・コンピューティング環境５０は、クラウドの利用者がローカル・コンピューティング・デバイス上でリソースを維持する必要のないインフラストラクチャ、プラットフォーム、またはＳａａＳ、あるいはその組合せを提供できる。図１に示されたコンピューティング・デバイス５４Ａ～Ｎの種類は、例示のみが意図されており、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意の種類のネットワークまたはネットワーク・アドレス可能な接続（例えば、Ｗｅｂブラウザを使用した接続）あるいはその両方を経由して任意の種類のコンピュータ制御デバイスと通信することができると理解される。

ここで図２を参照すると、クラウド・コンピューティング環境５０（図１）によって提供される機能的抽象レイヤのセットが示されている。図２に示されたコンポーネント、レイヤ、および機能は、例示のみが意図されており、本発明の実施形態がこれらに限定されないということが、あらかじめ理解されるべきである。図示されているように、次のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例としては、メインフレーム６１、ＲＩＳＣ（Reduced Instruction Set Computer）アーキテクチャベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーク・コンポーネント６６が挙げられる。一部の実施形態では、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化レイヤ７０は、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５などの仮想的実体を提供できる抽象レイヤを備える。

一例を挙げると、管理レイヤ８０は、以下で説明される機能を提供することができる。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用される計算リソースおよびその他のリソースの動的調達を行う。計測および価格設定８２は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡、およびそれらのリソースの利用に対する請求書またはインボイスの送付を行う。一例を挙げると、それらのリソースは、アプリケーション・ソフトウェア・ライセンスを含んでよい。セキュリティは、クラウドの利用者およびタスクのＩＤ検証を行うとともに、データおよびその他のリソースの保護を行う。顧客ポータル８３は、クラウド・コンピューティング環境へのアクセスを利用者およびシステム管理者に提供する。サービス・レベル管理８４は、必要なサービス・レベルを満たすように、クラウドの計算リソースの割り当てと管理を行う。サービス水準合意（ＳＬＡ：Service Level Agreement）計画および実行８５は、今後の要求が予想されるクラウドの計算リソースの事前準備および調達を、ＳＬＡに従って行う。

ワークロード・レイヤ９０は、クラウド・コンピューティング環境で利用できる機能の例を示している。このレイヤから提供されてよいワークロードおよび機能の例としては、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム教育の配信９３、データ解析処理９４、トランザクション処理９５、ならびにアクセス管理制御オーケストレータ９６が挙げられる。

データ処理システム
図３は、一部の実施形態と一致する、クラウド・コンピューティング環境５０内のクラウド・コンピューティング・ノード１０としての使用に適しているデータ処理システム（ＤＰＳ：data processing system）３００の実施形態を示している。一部の実施形態では、ＤＰＳ３００は、パーソナル・コンピュータ、サーバ・コンピュータ、ラップトップ・コンピュータもしくはノートブック・コンピュータ、ＰＤＡ（パーソナル・デジタル・アシスタント）、タブレット・コンピュータ、またはスマートフォンなどのポータブル・コンピュータ、自動車、航空機、テレビ会議システム、アプライアンスなどのより大きいデバイスに組み込まれたプロセッサ、スマート・デバイス、あるいは任意のその他の適切な種類の電子デバイスとして実装される。さらに、図３に示されたコンポーネント以外のコンポーネント、または図３に示されたコンポーネントに加えたコンポーネントが提示されてよく、そのようなコンポーネントの数、種類、および構成は変化してよい。さらに、図３は、ＤＰＳ３００の代表的な主要コンポーネントのみを示しており、個別のコンポーネントは、図３で表された複雑さより大きい複雑さを有してよい。

図３のデータ処理システム３００は、システム・バス３２２によってメモリ３１２、マス・ストレージ・インターフェイス３１４、端末／ディスプレイ・インターフェイス３１６、ネットワーク・インターフェイス３１８、および入出力（Ｉ／Ｏ：input/output）インターフェイス３２０に接続された、複数の中央処理装置３１０ａ～３１０ｄ（本明細書では、総称的にプロセッサ３１０またはＣＰＵ３１０と呼ばれる）を備える。この実施形態では、マス・ストレージ・インターフェイス３１４は、システム・バス３２２を、直接アクセス・ストレージ・デバイス３４０、ユニバーサル・シリアル・バス（ＵＳＢ：universal serial bus）ストレージ・デバイス３４１、または読み取り可能／書き込み可能な光ディスク・ドライブ３４２などの１つまたは複数のマス・ストレージ・デバイスに接続する。ネットワーク・インターフェイス３１８は、通信媒体３０６を経由してＤＰＳ３００が他のＤＰＳ３００と通信できるようにする。メモリ３１２は、オペレーティング・システム３２４、複数のアプリケーション・プログラム３２６、およびプログラム・データ３２８も含む。

図３のデータ処理システム３００の実施形態は、汎用コンピューティング・デバイスである。したがって、プロセッサ３１０は、メモリ３１２に格納されたプログラム命令を実行できる任意のデバイスであってよく、プロセッサ３１０自体は、１つまたは複数のマイクロプロセッサまたは集積回路あるいはその両方から構築されてよい。この実施形態では、ＤＰＳ３００は、より大きく能力が高いコンピュータ・システムでは標準的であるように、複数のプロセッサまたはプロセッシング・コアあるいはその両方を含むが、他の実施形態では、コンピューティング・システム３００は、マルチプロセッサ・システムをエミュレートするように設計された単一のプロセッサ・システムまたは単一のプロセッサあるいはその両方を備えてよい。さらに、プロセッサ３１０は、単一チップ上にメイン・プロセッサが二次プロセッサと共に存在する複数の異種データ処理システム３００を使用して実装されてよい。別の例として、プロセッサ３１０は、同じ種類の複数のプロセッサを含む対称型マルチプロセッサ・システムであってよい。

データ処理システム３００が起動するときに、関連するプロセッサ３１０が、オペレーティング・システム３２４を構成するプログラム命令を最初に実行し、オペレーティング・システム３２４は、ＤＰＳ３００の物理リソースおよび論理リソースを管理する。これらのリソースは、メモリ３１２、マス・ストレージ・インターフェイス３１４、端末／ディスプレイ・インターフェイス３１６、ネットワーク・インターフェイス３１８、およびシステム・バス３２２を含む。プロセッサ３１０と同様に、一部のＤＰＳ３００の実施形態は、複数のシステム・インターフェイス３１４、３１６、３１８、３２０、およびバス３２２を利用してよく、これらのシステム・インターフェイスおよびバスは、それぞれ、自分自身の個別の完全にプログラムされたマイクロプロセッサを含んでよい。

オペレーティング・システム、アプリケーション、またはプログラム、あるいはその組合せ（総称的に「プログラム・コード」、「コンピュータ使用可能プログラム・コード」、または「コンピュータ可読プログラム・コード」と呼ばれる）の命令は、最初はマス・ストレージ・デバイス３４０、３４１、３４２内にあってよく、これらのマス・ストレージ・デバイスは、システム・バス３２２を介してプロセッサ３１０と通信する。さまざまな実施形態におけるプログラム・コードは、システム・メモリ３１２またはマス・ストレージ・デバイス３４０、３４１、３４２などの、異なる物理的な、または有形のコンピュータ可読媒体上で具現化されてよい。図３の例では、命令が、直接アクセス・ストレージ・デバイス３４０上の永続的ストレージの機能的形態で格納される。これらの命令は、その後、プロセッサ３１０によって実行するために、メモリ３１２に読み込まれる。しかし、プログラム・コードは、選択的に取り外すことができるコンピュータ可読媒体３４２上に機能的形態で配置されてもよく、プロセッサ３１０によって実行するために、ＤＰＳ３００に読み込まれるか、または転送されてよい。

システム・バス３２２は、プロセッサ３１０、メモリ３１２、およびインターフェイス３１４、３１６、３１８、３２０の間の通信を容易にする任意のデバイスであってよい。さらに、この実施形態でのシステム・バス３２２は、システム・バス３２２内で直接通信経路を提供する比較的単純な単一のバス構造であるが、階層的構成、星形構成、またはＷｅｂ構成でのポイントツーポイント・リンク、複数の階層的バス、冗長な並列経路などを含むが、これらに限定されないその他のバス構造が、本開示と一致する。

メモリ３１２およびマス・ストレージ・デバイス３４０、３４１、３４２は、共同して機能し、オペレーティング・システム３２４、アプリケーション・プログラム３２６、およびプログラム・データ３２８を格納する。この実施形態では、メモリ３１２は、データおよびプログラムを格納できるランダムアクセス半導体デバイスである。図３はこのデバイスを単一のモノリシックな実体として概念的に示しているが、一部の実施形態では、メモリ３１２は、キャッシュおよびその他のメモリ・デバイスの階層などの、より複雑な構成であってよい。例えば、メモリ３１２は、キャッシュの複数のレベルに存在してよく、これらのキャッシュは、あるキャッシュが命令を保持している間に、別のキャッシュが、１つまたは複数のプロセッサによって使用される、命令以外のデータを保持するように、機能別にさらに分割されてよい。メモリ３１２は、さまざまな、いわゆる不均等メモリ・アクセス（ＮＵＭＡ：non-uniform memory access）コンピュータ・アーキテクチャのいずれかにおいて知られているように、異なるプロセッサ３１０またはプロセッサ３１０のセットにさらに分散され、関連付けられてよい。さらに、一部の実施形態は、仮想アドレス指定メカニズムを利用してよく、仮想アドレス指定メカニズムは、ＤＰＳ３００が、メモリ３１２およびマス・ストレージ・デバイス３４０、３４１、３４２などの複数のより小さいストレージ実体へのアクセスの代わりに、大きい単一のストレージ実体にアクセスできるかのように振る舞うことができるようにする。

オペレーティング・システム３２４、アプリケーション・プログラム３２６、およびプログラム・データ３２８は、メモリ３１２内に含まれているように示されているが、一部の実施形態では、これらのうちの一部または全部が、異なるコンピュータ・システム上に物理的に位置してよく、例えば通信媒体３０６を介して、リモートでアクセスされてよい。したがって、オペレーティング・システム３２４、アプリケーション・プログラム３２６、およびプログラム・データ３２８は、メモリ３１２内に含まれているように示されているが、これらの要素は、必ずしもすべてが同じ物理デバイスに同時に、完全には含まれず、他のＤＰＳ３００の仮想メモリに存在してもよい。

システム・インターフェイス３１４、３１６、３１８、３２０は、さまざまなストレージ・デバイスおよびＩ／Ｏデバイスとの通信をサポートする。マス・ストレージ・インターフェイス３１４は、１つまたは複数のマス・ストレージ・デバイス３４０、３４１、３４２の接続をサポートし、これらのマス・ストレージ・デバイスは、通常、回転する磁気ディスク・ドライブ・ストレージ・デバイス、データを永続的に格納するためのメモリとして集積回路アセンブリを使用する（通常はフラッシュ・メモリを使用する）ソリッドステート・ストレージ・デバイス（ＳＳＤ：solid-state storage device）、またはこれら２つの組合せである。しかし、マス・ストレージ・デバイス３４０、３４１、３４２は、ホストには単一の大きいストレージ・デバイスのように見えるように構成されたディスク・ドライブのアレイ（一般に、ＲＡＩＤアレイと呼ばれる）、またはハード・ディスク・ドライブ、テープ（例えば、ミニＤＶ）、書き込み可能コンパクト・ディスク（例えば、ＣＤ－ＲおよびＣＤ－ＲＷ）、デジタル・バーサタイル・ディスク（例えば、ＤＶＤ、ＤＶＤ－Ｒ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ、ＤＶＤ－ＲＡＭ）、ホログラフィ・ストレージ・システム、青色レーザー・ディスク、ＩＢＭ（Ｒ） Ｍｉｌｌｉｐｅｄｅデバイスなどのアーカイブ・ストレージ媒体、あるいはその両方を含む、その他のデバイスを備えてもよい。

端末／ディスプレイ・インターフェイス３１６は、モニタ３８０などの１つまたは複数のディスプレイ・ユニットをデータ処理システム３００に直接接続するために使用される。これらのディスプレイ・ユニット３８０は、ＬＥＤモニタなどのインテリジェントでない（すなわち、データ処理能力のない）端末であるか、またはＩＴ管理者および顧客がＤＰＳ３００と通信できるようにするために使用される、それ自体が完全にプログラム可能なワークステーションであってよい。ただし、１つまたは複数のディスプレイ・ユニット３８０との通信をサポートするために、ディスプレイ・インターフェイス３１６が提供されているが、顧客との必要なすべての対話およびその他のプロセスがネットワーク・インターフェイス３１８を介して発生してよいため、コンピュータ・システム３００が必ずしもディスプレイ・ユニット３８０を必要としないということに注意する。

通信媒体３０６は、任意の適切なネットワークまたはネットワークの組合せであってよく、複数のＤＰＳ３００との間でのデータまたはコードあるいはその両方の通信に適した任意の適切なプロトコルをサポートしてよい。したがって、ネットワーク接続が、現在のアナログ技術もしくはデジタル技術またはその両方を使用して行われるのか、あるいは将来の何らかのネットワーク・メカニズムを介して行われるのかに関わらず、ネットワーク・インターフェイス３１８は、そのような通信を容易にする任意のデバイスであることができる。適切な通信媒体３０６は、「インフィニバンド」またはＩＥＥＥ（Institute of Electrical and Electronics Engineers：電気電子技術者協会）８０２．３ｘ「イーサネット（Ｒ）」仕様のうちの１つまたは複数を使用して実装されたネットワーク、セルラー伝送ネットワーク（cellular transmission networks）、ＩＥＥＥ ８０２．１１ｘ、ＩＥＥＥ ８０２．１６、ジェネラル・パケット・ラジオ・サービス（ＧＰＲＳ：General Packet Radio Service）、ＦＲＳ（Family Radio Service）、またはＢｌｕｅｔｏｏｔｈ（Ｒ）仕様のうちの１つを使用して実装された無線ネットワーク、ＦＣＣ ０２－４８に記載されているような超広帯域（ＵＷＢ：Ultra-Wide Band）技術などを含むが、これらに限定されない。当業者は、通信媒体３０６を実装するために、多くの異なるネットワークおよびトランスポート・プロトコルが使用されることができるということを理解するであろう。一連の伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ：Transmission Control Protocol/Internet Protocol）は、適切なネットワークおよびトランスポート・プロトコルを含む。

アクセス管理制御オーケストレータ
図４は、一部の実施形態と一致する、アクセス管理制御オーケストレータ４００の概略図である。このアクセス管理制御オーケストレータ４００の実施形態は、ブロックチェーン４７０を介して通信する、システム所有者機能４５０、監査人機能４５５、システム特権要求元ユーザ機能４６０、およびシステム管理者機能４６５を参照して説明される。例示的なトランザクションでは、ユーザがアクセス管理制御オーケストレータ４００に対して追加の特権４０５を要求し、所有者機能４５０が、その要求４１５を承認または拒否してよい。所有者機能４５０が要求を承認した後に、システム管理者機能４６５が、物理的ＩＴシステムに対する対応するアクセス権限４２５、４３０を付与してよい。監査人４５５は、所有者がそれらの新しい特権を承認したということを確認することができる（４１０）。一部の実施形態では、システム所有者機能４５０、監査人機能４５５、システム特権要求元ユーザ４６０、およびシステム管理者機能４６５はすべて、異なる法的実体の一部であってよく、したがって、異なる内部の技術システムを使用してアクセス権限を管理してよい。これらの使用事例では、異なる機能が、標準アプリケーション・プログラミング・インターフェイス（ＡＰＩ：application programming interfaces）などを介してアクセス管理制御オーケストレータ４００とインターフェイスをとってよい。

この実施形態では、ブロックチェーン４７０は、異なる論理的位置、物理的位置、および実体の位置（地理的位置、組織の位置、ホストしている位置など）にあるノード４７１Ａ、４７１Ｂ、４７１Ｃ、４７１Ｄ（集合的に、ノード４７１）のネットワークであってよい。ノード４７１は、暗号化されたネットワーク通信チャネル４７２を介して互いに接続されてよい。一部の実施形態では、合意プロトコルに従って、ノード４７１を追加することがブロックチェーン４７０内の既存の他のノード４７１によって承認された場合、かつその場合に限り、ノード４７１がこのブロックチェーン４７０に追加されてよい。

この実施形態では、各ノード４７１が、ブロックチェーン４７０にサブミットされて受け入れられたすべてのトランザクションをリストする分散型台帳４７３のコピー（明確にするために、図４に示された１つのコピーのみ）を維持してよい。この実施形態では、合意プロトコルに従って、ブロックチェーン４７０内のノード４７１間に合意が存在する場合、かつその場合に限り、トランザクションが受け入れられてよい。この実施形態では、トランザクションは、分散型台帳４７３内の過去のすべてのトランザクションが変更不可能であり、変更されることができないときにのみ、分散型台帳４７３に追加されることができる。さらに、分散型台帳４７３は、レコードを改ざんすることが事実上不可能であることを保証するために、暗号によって署名されてよい。

一部の実施形態では、ノード４７１は、スマート・コントラクト（すなわち、トランザクションの実行をデジタル的に容易にする、検証する、または実施するなどのために、台帳４７３内のトランザクションを処理する、クライアントによってサブミットされたコンピュータ・プログラム）を実行してよい。スマート・コントラクトの役目は、（ｉ）トランザクションの妥当性を確認すること（すなわち、新しいトランザクションを台帳に受け入れる合意プロトコルに参加すること）、（ｉｉ）受け入れられることもあれば、受け入れられないこともある、台帳への新しいトランザクションを提案すること、および（ｉｉｉ）外部クライアントと共に、１つまたは複数のトランザクションを処理するための動作を実行することを含んでよいが、これらに限定されない。スマート・コントラクトは、ブロックチェーン４７０のすべてのノード４７１上で並列に実行されてよく、スマート・コントラクトの結果は、合意プロトコルに従って、ネットワーク内のノード４７１間に合意が存在する場合、かつその場合に限り、ブロックチェーン４７０によって受け入れられてよい。

一部の実施形態では、ブロックチェーン４７０は、許可型ブロックチェーンであってよい。これらの実施形態では、クライアント（例えば、ユーザ、ソフトウェア・アプリケーション）は、クライアントを認証して許可するノード４７１Ａ、４７１Ｂ、４７１Ｃ、４７１Ｄのみを介して、ブロックチェーン４７０に接続してよい。これらの実施形態では、クライアントは、トランザクションをサブミットすること、トランザクション状態および属性を問い合わせることなどのために、ブロックチェーン・ネットワークＡＰＩを呼び出してよい。これらのトランザクションは、（ｉ）クライアントが、台帳に追加され、その後、合意プロトコルを経て、分散型台帳に受け入れられる、新しいトランザクションを提案すること、（ｉｉ）クライアントが、分散型台帳によって受け入れられる新しいトランザクションについて、処理することを許可されているということをチェックすること、および（ｉｉｉ）クライアントがスマート・コントラクトをブロックチェーン４７０にサブミットすることを含んでよいが、これらに限定されない。

一部の実施形態では、ブロックチェーン４７０によって提供されたサービスを接続する／呼び出すためのアクセス権限を付与した実体に識別情報を関連付けることを可能にするために、ブロックチェーン４７０を使用することによって、アクセス管理システムが実装されてよい。これらの実体は、既存のノード４７１Ａ、４７１Ｂ、４７１Ｃ、４７１Ｄに接続するため、またはこれらの実体が接続できる追加のノード（図示されていない）を追加するための権限を持っていてよい。これらの実体は、これらの実体が接続されるノード４７１Ａ、４７１Ｂ、４７１Ｃ、４７１Ｄからのスマート・コントラクトをサブミットし、これらのスマート・コントラクトと情報をやりとりするための権限を持っていてもよい。これらの実体、およびこれらの実体がサブミットするスマート・コントラクトは、アクセス・ポリシー基準に一致する属性を含むトランザクションを取得／サブミットするための権限を持っていてよい。

ブロックチェーン・ネットワークＡＰＩ
一部の実施形態は、以下の属性と共に、以下の種類のトランザクションをサポートしてよい。
ＲｅｑｕｅｓｔＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，理由）
ＡｃｃｅｓｓＡｐｐｒｏｖｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，承認の説明，ＲｅｑｕｅｓｔＴＩＤ）
ＡｃｃｅｓｓＤｅｎｉｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，拒否の説明，ＲｅｑｕｅｓｔＴＩＤ）
ＧｒａｎｔＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＡｄｍｉｎ，理由，承認の説明，ＡｐｐｒｏｖａｌＴＩＤ）
ＡｃｃｅｓｓＧｒａｎｔｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＡｄｍｉｎ，理由，承認の説明，ＡｐｐｒｏｖａｌＴＩＤ）
ＲｅｖｏｋｅＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，ＵＩＤＡＭ／ＵＩＤＡｕｄｉｔｏｒ，理由）
ＡｃｃｅｓｓＲｅｖｏｋｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，ＵＩＤＡＭ／ＵＩＤＡｕｄｉｔｏｒ，理由）
ＲｅｑｕｅｓｔＶａｌｉｄａｔｉｏｎＰ（）
１．新しいＲｅｑｕｅｓｔＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，理由）トランザクションで
２．システムＩＴＳｙｓｔｅｍＩＤのＵＩＤＯｗｎｅｒを見つけ
３．トランザクションＲｅｑｕｅｓｔＡｐｐｒｏｖｅＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，理由．ＲｅｑｕｅｓｔＴＩＤ）をサブミットする
ＯｗｎｅｒＡｐｐｒｏｖａｌＰ（ＩＴＳｙｓｔｅｍＩＤ）
１．ＩＴＳｙｓｔｅｍＩＤ＝＝ＩＴＳｙｓｔｅｍＩＤとして、新しいＲｅｑｕｅｓｔＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ）トランザクションで
２．特権を伴うＩＴＳｙｓｔｅｍＩＤに対するアクセス権限を要求するためにＵＩＤによって提供された理由が有効であることを検証する
３．理由が有効である場合
１．トランザクションＡｐｐｒｏｖａｌＴＩＤ＝ＡｃｃｅｓｓＡｐｐｒｏｖｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，承認の説明，ＲｅｑｕｅｓｔＴＩＤ）をサブミットする
２．トランザクションＧｒａｎｔＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，承認の説明，ＡｐｐｒｏｖａｌＴＩＤ）をサブミットする
４．そうでない場合、トランザクションＡｃｃｅｓｓＤｅｎｉｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，拒否の説明，ＲｅｑｕｅｓｔＴＩＤ）をサブミットする
ＧｒａｎｔＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ）
１．ＩＴＳｙｓｔｅｍＩＤ＝＝ＩＴＳｙｓｔｅｍＩＤとして、新しいＡｃｃｅｓｓＧｒａｎｔｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＯｗｎｅｒ，承認の説明，ＲｅｑｕｅｓｔＴＩＤ）トランザクションで
２．ＵＩＤＯｗｎｅｒがＩＴＳｙｓｔｅｍＩＤの所有者であるということを二重にチェックしてから、メッセージをＩＴＳｙｓｔｅｍＩＤアクセス制御（許可）システムに送信し、パラメータＵＩＤ、ＩＴＳｙｓｔｅｍＩＤ、特権、ＵＩＤＯｗｎｅｒ、承認の説明、ＲｅｑｕｅｓｔＴＩＤを使用して許可動作を実行する。
許可動作が、システムＩＴＳｙｓｔｅｍＩＤに対するユーザＵＩＤのアクセス権限を許可するように、許可ポリシーを変更する。
ＬｏｇＡｃｃｅｓｓ（ＩＴＳｙｓｔｅｍＩＤ）
１．パラメータＵＩＤ、ＩＴＳｙｓｔｅｍＩＤ、ＵＩＤＡｄｍｉｎ、説明、ＲｅｑｕｅｓｔＴＩＤを渡して許可動作または取り消し動作を実行するためのＢｏｂからの要求を待機する
２．動作が許可である場合、ＵＩＤのアクセス権限を更新し、トランザクションＡｃｃｅｓｓＧｒａｎｔｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，特権，ＵＩＤＡｄｍｉｎ，説明，ＡｐｐｒｏｖａｌＴＩＤ）をサブミットする
３．動作が取り消しである場合、ＵＩＤのアクセス権限を取り消し、トランザクションＡｃｃｅｓｓＲｅｖｏｋｅｄ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，ＵＩＤＯｗｎｅｒ，説明，ＡｐｐｒｏｖａｌＴＩＤ）をサブミットする
ＲｅｖｏｋｅＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ）
１．ＩＴＳｙｓｔｅｍＩＤ＝＝ＩＴＳｙｓｔｅｍＩＤとして、新しいＲｅｖｏｋｅＡｃｃｅｓｓ（ＵＩＤ，ＩＴＳｙｓｔｅｍＩＤ，ＵＩＤＯｗｎｅｒ，理由，ＲｅｑｕｅｓｔＴＩＤ）トランザクションで
２．ＵＩＤＯｗｎｅｒが有効であることを二重にチェックしてから、メッセージをＩＴＳｙｓｔｅｍＩＤアクセス制御（許可）システムに送信し、パラメータＵＩＤ、ＩＴＳｙｓｔｅｍＩＤ、ＵＩＤＯｗｎｅｒ、取り消しの説明、ＲｅｑｕｅｓｔＴＩＤを使用して取り消し動作を実行する
取り消し動作が、システムＩＴＳｙｓｔｅｍＩＤに対するユーザＵＩＤのアクセス権限を拒否するように、許可ポリシーを変更する。
ＡｕｄｉｔＡｃｔｉｏｎｓＰ（ＩＴＳｙｓｔｅｍＩＤのリスト）
１．ＩＴＳｙｓｔｅｍＩＤのリストにＩＴＳｙｓｔｅｍＩＤを含む新しいトランザクションで
２．トランザクション、およびセキュリティ・ポリシーが順守されているということの妥当性を確認する。例えば、
・ＲｅｑｕｅｓｔＡｐｐｒｏｖｅｄ：ＲｅｑｕｅｓｔＴＩＤがＵＩＤのＲｅｑｕｅｓｔＡｃｃｅｓｓであり、ＵＩＤＯｗｎｅｒがＩＴＳｙｓｔｅｍＩＤの所有者であり、理由が有効である
・ＧｒａｎｔＡｃｃｅｓｓ：ＡｐｐｒｏｖａｌＴＩＤがＵＩＤ／ＳｙｓｔｅｍＩＤのＡｃｃｅｓｓＡｐｐｒｏｖｅｄトランザクションであり、ＵＩＤＯｗｎｅｒがＩＴＳｙｓｔｅｍＩＤの所有者であり、承認の理由が有効である
・ＡｃｃｅｓｓＧｒａｎｔｅｄ：ＡｐｐｒｏｖａｌＴＩＤがＵＩＤ／ＳｙｓｔｅｍＩＤのＡｃｃｅｓｓＡｐｐｒｏｖｅｄトランザクションであり、ＵＩＤＯｗｎｅｒがＩＴＳｙｓｔｅｍＩＤの所有者であり、ＵＩＤＡｄｍｉｎがＳｙｓｔｅｍＩＤの管理者であり、承認の理由が有効である
・ポリシー順守されていない場合、セキュリティ・インシデントを開始する

例
例では、以下の指定された識別情報を有する以下の実体が、特定の特権調整システム内に存在する場合
Ｅｖｅ：システムＩＴＳｙｓｔｅｍＩＤ１の所有者組織
Ｅｖｅ：システムＩＴＳｙｓｔｅｍＩＤ２の所有者組織
Ｂｏｂ（実際の人または自動化）：システムＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２の管理者
監査人：ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２の監査組織
Ａｌｉｃｅ：特権ユーザ
以下のアクセス権限ポリシーが定義される：
Ｅｖｅ：属性ＩＴＳｙｓｔｅｍＩＤ＝ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２として、ＲｅｑｕｅｓｔＡｃｃｅｓｓトランザクションを読み取る
Ｅｖｅ：属性ＩＴＳｙｓｔｅｍＩＤ＝ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２として、ＡｃｃｅｓｓＡｐｐｒｏｖｅｄ、ＡｃｃｅｓｓＤｅｎｉｅｄ、ＧｒａｎｔＡｃｃｅｓｓ、ＲｅｖｏｋｅＡｃｃｅｓｓトランザクションをサブミットする
Ｂｏｂ：属性ＩＴＳｙｓｔｅｍＩＤ＝ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２として、ＧｒａｎｔＡｃｃｅｓｓ、ＲｅｖｏｋｅＡｃｃｅｓｓ、Ｒｅｑｕｅｓｔトランザクションを読み取る
Ｂｏｂ：ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２：属性ＩＴＳｙｓｔｅｍＩＤ＝ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２として、ＡｃｃｅｓｓＧｒａｎｔｅｄ、ＡｃｃｅｓｓＲｅｖｏｋｅｄトランザクションをサブミットする
監査人：任意の属性を使用してすべての種類のトランザクションを読み取る
次のノードがブロックチェーン４７０に追加されている：
Ｎｏｄｅ１：アクセス権限管理組織によってホストされる
Ｎｏｄｅ２：システムＩＴＳｙｓｔｅｍＩＤ１、システムＩＴＳｙｓｔｅｍＩＤ２の所有者組織によってホストされる
Ｎｏｄｅ３：システムＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２の管理者によってホストされる
Ｎｏｄｅ４：ＩＴＳｙｓｔｅｍＩＤ１、ＩＴＳｙｓｔｅｍＩＤ２の監査組織によってホストされる
次に、この例では、クライアントが動作中にブロックチェーン・ネットワークＡＰＩを呼び出すことによって、以下の処理が実行されてよい：
ＡｌｉｃｅがＮｏｄｅ１に接続し、ＩＴＳｙｓｔｅｍＩＤ１に対するアクセス権限要求をサブミットする
ＥｖｅがＮｏｄｅ２に接続し、ＯｗｎｅｒＡｐｐｒｏｖａｌＰ（ＩＴＳｙｓｔｅｍＩＤ１）プログラムを実行する
ＥｖｅがＮｏｄｅ２に接続し、ＯｗｎｅｒＡｐｐｒｏｖａｌＳＰ（ＩＴＳｙｓｔｅｍＩＤ２）プログラムを実行する
ＢｏｂがＮｏｄｅ３に接続し、ＧｒａｎｔＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ１）プログラムを実行する
ＢｏｂがＮｏｄｅ３に接続し、ＧｒａｎｔＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ２）プログラムを実行する
ＢｏｂがＮｏｄｅ３に接続し、ＲｅｖｏｋｅＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ１）プログラムを実行する
ＢｏｂがＮｏｄｅ３に接続し、ＲｅｖｏｋｅＡｃｃｅｓｓＰ（ＩＴＳｙｓｔｅｍＩＤ２）プログラムを実行する
ＩＴＳｙｓｔｅｍＩＤ１およびＩＴＳｙｓｔｅｍＩＤ２がＮｏｄｅ３に接続し、ＬｏｇＡｃｃｅｓｓＰ（）プログラムを実行する
監査人がＮｏｄｅ４に接続し、実行に関してＡｕｄｉｔＡｃｔｉｏｎｓＰ（ＩＴＳｙｓｔｅｍＩＤ１，ＩＴＳｙｓｔｅｍＩＤ２）を実行する

ブロックチェーン・アーキテクチャ
図５Ａは、一部の実施形態と一致する、ブロックチェーン・アーキテクチャの構成５００を示している。これらの実施形態では、ブロックチェーン・アーキテクチャ５００は、特定のブロックチェーン要素（例えば、ブロックチェーン・ノード５０２のグループ）を含んでよい。次に、ブロックチェーン・ノード５０２のグループは、１つまたは複数のメンバー・ノード５０４～５１０を含んでよい（単に例として、これらの４つのノードが示されている）。これらのメンバー・ノード５０４～５１０は、ブロックチェーン・トランザクションの追加および妥当性確認プロセス（合意）などの、複数の活動に参加してよい。メンバー・ノード５０４～５１０のうちの１つまたは複数は、署名ポリシーに基づいてトランザクションに署名してよく、アーキテクチャ５００内のすべてのブロックチェーン・ノードに順序付けサービスを提供してよい。メンバー・ノード５０４～５１０は、ブロックチェーン認証を開始し、ブロックチェーン層５１６に格納されたブロックチェーンの変更不可能な台帳に書き込もうとしてよく、この台帳のコピーが、基盤になる物理的インフラストラクチャ５１４にも格納されてよい。

一部の実施形態では、ブロックチェーン・アーキテクチャ５００は、格納されたプログラム／アプリケーション・コード５２０（例えば、チェーンコード、スマート・コントラクトなど）にアクセスして実行するために、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）５２２にリンクされた１つまたは複数のアプリケーション５２４を含んでよい。次に、参加者によって要求されてカスタマイズされた構成に従って、格納されたプログラム／アプリケーション・コード５２０が作成されることができ、それ自身の状態を維持し、参加者のアセットを制御し、外部の情報を受信することができる。格納されたプログラム／アプリケーション・コード５２０は、トランザクションとしてデプロイされ、分散型台帳に追加することによって、すべてのブロックチェーン・ノード５０４～５１０にインストールされることができる。

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

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

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

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

一部の実施形態では、チェーンコードは、追加機能と共に、スマート・コントラクトのコード解釈を含んでよい。一部の実施形態では、チェーンコードは、コンピューティング・ネットワーク上にデプロイされるプログラム・コードとして実装されてよく、合意プロセス中に、チェーン・バリデータによって一緒に実行されて妥当性を確認される。チェーンコードは、ハッシュを受信してよく、以前に格納された特徴抽出機能の使用によって作成されたデータ・テンプレートに関連付けられたハッシュをブロックチェーンから取り出してよい。ハッシュ識別子のハッシュと、格納された識別子テンプレート・データから作成されたハッシュが一致する場合、チェーンコードは、許可キーを、要求されたサービスに送信してよい。チェーンコードは、暗号の詳細に関連付けられたデータをブロックチェーンに書き込んでよい。

図５Ｂは、一部の実施形態に従って、ブロックチェーンのノード間のブロックチェーン・トランザクション・フロー５５０の例を示している。これらの実施形態のトランザクション・フローは、アプリケーション・クライアント・ノード５６０によって署名ピア・ノード５８１に送信されるトランザクション提案５９１を含んでよい。署名ピア５８１は、クライアントの署名を検証し、チェーンコード関数を実行してトランザクションを開始してよい。出力は、チェーンコードの結果、チェーンコードに読み取られたキー／値のバージョンのセット（読み取りセット）、およびチェーンコードに書き込まれたキー／値のセット（書き込みセット）を含んでよい。次に、提案応答５９２が、承認されている場合は署名と共に、クライアント５６０に返送されてよい。

それに応じて、クライアント５６０は、署名をトランザクションのペイロード５９３にまとめてよく、順序付けサービス・ノード５８４にブロードキャストする。その後、順序付けサービス・ノード５８４は、順序付けられたトランザクションをチャネル上でブロックとしてすべてのピア５８１～５８３に配信してよい。ブロックチェーンへのコミットの前に、各ピア５８１～５８３がトランザクションの妥当性を確認してよい。例えばピアは、一部の実施形態では、指定されたピアの正しい割り当てが結果に署名し、トランザクションのペイロード５９３に対する署名を認証したことを確認するために、署名ポリシーをチェックしてよい。

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

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

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

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

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

許可型ブロックチェーン
図６Ａは、一部の実施形態と一致する許可型ブロックチェーン・ネットワークの例を示しており、許可型ブロックチェーン・ネットワークは、分散型の非集中的ピアツーピア・アーキテクチャを特徴とする。この例では、ブロックチェーン・ユーザ６０２は、許可型ブロックチェーン６０４に対するトランザクションを開始してよい。この例では、トランザクションは、デプロイ、呼び出し、または問い合わせであってよく、ＳＤＫを利用するクライアント側のアプリケーションを介して、ＡＰＩを介して直接的に、などによって、発行されてよい。ネットワークは、監査人などのレギュレータ６０６へのアクセスを提供してよい。ブロックチェーン・ネットワーク・オペレータ６０８は、レギュレータ６０６を「監査人」として登録し、ブロックチェーン・ユーザ６０２を「クライアント」として登録するなど、メンバーの許可を管理する。監査人は、台帳への問い合わせのみに制限されてよく、一方、クライアントは、特定の種類のチェーンコードのデプロイ、呼び出し、および問い合わせを行うことを許可されてよい。

ブロックチェーン開発者６１０は、一部の実施形態では、チェーンコードおよびクライアント側のアプリケーションを書き込むことができる。ブロックチェーン開発者６１０は、これらの実施形態では、インターフェイスを介して、チェーンコードをネットワークに直接デプロイしてよい。従来のデータ・ソース６１２からの認証情報をチェーンコードに含めるために、開発者６１０は、帯域外接続を使用してデータにアクセスしてよい。この例では、ブロックチェーン・ユーザ６０２は、ピア・ノード６１４を介して許可型ブロックチェーン６０４に接続してよい。ピア・ノード６１４は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクションの証明書を、ユーザの役割および許可を管理する認証機関６１６から取得してよい。一部の実施形態では、ブロックチェーン・ユーザは、許可型ブロックチェーン６０４上でトランザクションを実行するために、それらのデジタル証明書を所有しなければならない。他の実施形態では、ブロックチェーン・ユーザは、分散された信用のチェーンによることなどの、その他の技術を使用して認証されてよい。一方、チェーンコードを利用しようとしているユーザは、従来のデータ・ソース６１２上のそれらのユーザの認証情報を検証することが必要になることがある。ユーザの許可を確認するために、チェーンコードは、従来の処理プラットフォーム６１８を介して、このデータへの帯域外接続を使用してよい。

図６Ｂは、一部の実施形態と一致する許可型ブロックチェーン・ネットワークの別の例を示しており、許可型ブロックチェーン・ネットワークは、分散型の非集中的ピアツーピア・アーキテクチャを特徴とする。この例では、ブロックチェーン・ユーザ６２２は、トランザクションを許可型ブロックチェーン６２４にサブミットしてよい。この例では、トランザクションは、デプロイ、呼び出し、または問い合わせであることができ、ＳＤＫを利用するクライアント側のアプリケーションを介して、ＡＰＩを介して直接的に、などによって、発行されてよい。ネットワークは、監査人などのレギュレータ６２６へのアクセスを提供してよい。ブロックチェーン・ネットワーク・オペレータ６２８は、レギュレータ６２６を「監査人」として登録し、ブロックチェーン・ユーザ６２２を「クライアント」として登録するなど、メンバーの許可を管理する。監査人は、台帳への問い合わせのみに制限されることができ、一方、クライアントは、特定の種類のチェーンコードのデプロイ、呼び出し、および問い合わせを行うことを許可されることができる。

ブロックチェーン開発者６３１は、これらの実施形態では、チェーンコードおよびクライアント側のアプリケーションを書き込んでよい。ブロックチェーン開発者６３１は、インターフェイスを介して、チェーンコードをネットワークに直接デプロイしてよい。従来のデータ・ソース６３２からの認証情報をチェーンコードに含めるために、開発者６３１は、帯域外接続を使用してデータにアクセスしてよい。この例では、ブロックチェーン・ユーザ６２２は、ピア・ノード６３４を介してネットワークに接続する。ピア・ノード６３４は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクションの証明書を認証機関６３６から取得する。一部の実施形態では、ブロックチェーン・ユーザは、許可型ブロックチェーン６２４上でトランザクションを実行するために、それらのデジタル証明書を所有しなければならない。他の実施形態では、ブロックチェーン・ユーザは、分散された信用のチェーンによることなどの、その他の技術を使用して認証されてよい。一方、チェーンコードを利用しようとしているユーザは、従来のデータ・ソース６３２上のそれらのユーザの認証情報を検証することが必要になることがある。ユーザの許可を確認するために、チェーンコードは、従来の処理プラットフォーム６３８を介して、このデータへの帯域外接続を使用することができる。

図６Ｃは、一部の実施形態と一致する、さまざまな動作を実行するように構成された物理的インフラストラクチャ６１１を含む例示的なシステムを示している。図６Ｃを参照すると、物理的インフラストラクチャ６１１は、モジュール６８８およびモジュール６８９を含む。モジュール６１９は、実施形態例のいずれかに含まれる（モジュール６１２内の）動作ステップ６７８のいずれかを実行してよい、ブロックチェーン６２０およびスマート・コントラクト６３０（ブロックチェーン６２０に存在してよい）を含む。ステップ／動作６７８は、説明されたか、または図に示された実施形態のうちの１つまたは複数を含んでよく、１つまたは複数のスマート・コントラクト６３０またはブロックチェーン６２０あるいはその両方から書き込まれるか、または読み取られる、出力されたか、または書き込まれた情報を表してよい。物理的インフラストラクチャ６１１、モジュール６８８、およびモジュール６８９は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組合せを含んでよい。さらに、モジュール６８８およびモジュール６８９は同じモジュールであってよい。

図６Ｄは、一部の実施形態と一致する、さまざまな動作を実行するように構成された別の例示的なシステムを示している。図６Ｄを参照すると、システムはモジュール６１２および６１４を含む。モジュール６１４は、実施形態例のいずれかに含まれる（モジュール６１２内の）動作ステップ６７８のいずれかを実行してよい、ブロックチェーン６２０およびスマート・コントラクト６３０（ブロックチェーン６２０に存在してよい）を含む。ステップ／動作６７８は、説明されたか、または図に示された実施形態のうちの１つまたは複数を含んでよく、１つまたは複数のスマート・コントラクト６３０またはブロックチェーン６２０あるいはその両方から書き込まれるか、または読み取られる、出力されたか、または書き込まれた情報を表してよい。物理的モジュール６１２およびモジュール６１４は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはその組合せを含んでよい。さらに、モジュール６１２およびモジュール６１４は同じモジュールであってよい。

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

図６Ｆは、一部の実施形態と一致する、ブロックチェーンを含むシステム６６０を示している。図６Ｄの例を参照すると、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）ゲートウェイ６６２が、ブロックチェーンの論理（例えば、スマート・コントラクト６３０またはその他のチェーンコード）およびデータ（例えば、分散型台帳など）にアクセスするための共通インターフェイスを提供する。この例では、ＡＰＩゲートウェイ６６２は、１つまたは複数の実体６５２および６５６をブロックチェーン・ピア（すなわち、サーバ６５４）に接続することによってブロックチェーンに対してトランザクション（呼び出し、問い合わせなど）を実行するための共通インターフェイスである。ここで、サーバ６５４は、世界状態および分散型台帳のコピーを保持するブロックチェーン・ネットワークのピア・コンポーネントであり、これらのコピーは、クライアント６５２および６５６が世界状態に関するデータを問い合わせること、およびトランザクションをブロックチェーン・ネットワークにサブミットすることを可能にし、スマート・コントラクト６３０および署名ポリシーに応じて、署名ピアがスマート・コントラクト６３０を実行する。

ブロックの処理
図７Ａは、一部の実施形態と一致する、分散型台帳７２０に追加されている新しいブロックのプロセス７００を示しており、図７Ｂは、一部の実施形態と一致する、ブロックチェーンの新しいデータ・ブロック構造７３０の内容を示している。新しいデータ・ブロック７３０は、データをリンクする文書を含んでよい。

図７Ａを参照すると、クライアント（図示されていない）は、トランザクションをブロックチェーン・ノード７１１、７１２、または７１３、あるいはその組合せにサブミットしてよい。クライアントは、ブロックチェーン７２２に対する活動を規定するための、いずれかのソースから受信された命令であってよい。一例として、クライアントは、ブロックチェーンのトランザクションを提案するデバイス、人、または実体などの要求者の代わりに動作するアプリケーションであってよい。複数のブロックチェーン・ピア（例えば、ブロックチェーン・ノード７１１、７１２、および７１３）が、ブロックチェーン・ネットワークの状態および分散型台帳７２０のコピーを維持してよい。クライアントによって提案されたトランザクションをシミュレートして署名する署名ピア、および署名を検証し、トランザクションの妥当性を確認し、トランザクションを分散型台帳７２０にコミットするコミット・ピアを含む、さまざまな種類のブロックチェーン・ノード／ピアが、ブロックチェーン・ネットワーク内に存在してよい。一部の実施形態では、ブロックチェーン・ノード７１１、７１２、および７１３は、署名者ノード、コミッタ・ノード、またはその両方の役割を実行してよい。

分散型台帳７２０は、ブロック内の変更不可能な順序付けられたレコードを格納するブロックチェーン、およびブロックチェーン７２２の現在の状態を維持する状態データベース７２４（現在の世界状態）を含んでよい。１つのチャネルにつき１つの分散型台帳７２０が存在してよく、各ピアが、そのピアがメンバーであるチャネルごとに、分散型台帳７２０のそれ自身のコピーを維持する。ブロックチェーン７２２は、ハッシュリンクされたブロックとして構造化されたトランザクション・ログであってよく、各ブロックがＮ個のトランザクションのシーケンスを含む。ブロックは、図７Ｂに示されているコンポーネントなどの、さまざまなコンポーネントを含んでよい。ブロックのリンク（図７Ａの矢印によって示されている）は、前のブロックのヘッダーのハッシュを、現在のブロックのブロック・ヘッダー内に追加することによって生成されてよい。このようにして、ブロックチェーン７２２上のすべてのトランザクションが、順序付けられ、暗号によって一緒にリンクされてよく、ハッシュ・リンクを壊さずにブロックチェーン・データを改ざんすることを防ぐ。さらに、これらのリンクのため、ブロックチェーン７２２内の最新のブロックが、その前に来たすべてのトランザクションを表す。ブロックチェーン７２２は、追加専用のブロックチェーンのワークロードをサポートするピアのファイル・システム（ローカルまたは取り付けられたストレージ）に格納されてよい。

ブロックチェーン７２２および分散型台帳７２０の現在の状態が、状態データベース７２４に格納されてよい。ここで、現在の状態データは、ブロックチェーン７２２のチェーン・トランザクション・ログにこれまで含まれたすべてのキーの最新の値を表す。チェーンコード呼び出しは、状態データベース７２４内の現在の状態に対してトランザクションを実行する。それらのチェーンコードの相互作用をより効率的にするために、すべてのキーの最新の値が状態データベース７２４に格納されてよい。状態データベース７２４は、ブロックチェーン７２２のトランザクション・ログへのインデックス付きビューを含んでよく、したがって、いつでもチェーンから再生成されることができる。状態データベース７２４は、ピアの起動時に、トランザクションが受け取られる前に、自動的に回復されてよい（または必要な場合に生成されてよい）。

署名ノードは、トランザクションをクライアントから受信し、シミュレーション結果に基づいてトランザクションに署名する。署名ノードは、トランザクション提案をシミュレートするスマート・コントラクトを保持する。署名ノードがトランザクションに署名するときに、署名ノードは、シミュレートされたトランザクションの署名を示す署名ノードからクライアント・アプリケーションへの署名された応答である、トランザクションの署名を作成する。トランザクションに署名する方法は、チェーンコード内で指定されることがある署名ポリシーによって決まる。署名ポリシーの例は、「署名ピアの大部分がトランザクションに署名しなければならない」である。異なるチャネルは、異なる署名ポリシーを有してよい。署名されたトランザクションは、クライアント・アプリケーションによって順序付けサービス７１０に転送される。

順序付けサービス７１０は、署名されたトランザクションを受け取り、それらをブロック内に順序付けし、ブロックをコミット・ピアに配信する。例えば、順序付けサービス７１０は、トランザクションのしきい値に達したか、タイマーがタイムアウトするか、または別の条件の場合に、新しいブロックを開始してよい。図７Ａの例では、ブロックチェーン・ノード７１２は、ブロックチェーン７２２に格納するための新しいデータの新しいデータ・ブロック７３０を受信したコミット・ピアである。ブロックチェーン内の第１のブロックは、ブロックチェーン、ブロックチェーンのメンバー、格納されたデータなどに関する情報を含むジェネシス・ブロックと呼ばれてよい。

順序付けサービス７１０は、順序付けノードのクラスタで構成されてよい。一部の実施形態では、順序付けサービス７１０は、トランザクション、スマート・コントラクトを処理しなくてもよく、共有台帳を維持しなくてもよい。むしろ、これらの実施形態では、順序付けサービス７１０は、署名されたトランザクションを受け取り、それらのトランザクションが分散型台帳７２０にコミットされる順序を指定してよい。ブロックチェーン・ネットワークのアーキテクチャは、「順序付け」の特定の実装（例えば、Ｓｏｌｏ、Ｋａｆｋａ、ＢＦＴなど）が着脱可能なコンポーネントになるように設計されてよい。

一部の実施形態では、トランザクションは、一貫性のある順序で分散型台帳７２０に書き込まれてよい。これらの実施形態では、トランザクションの順序は、トランザクションがネットワークにコミットされるときに、状態データベース７２４に対する更新が有効であることを保証するように、確立されてよい。暗号パズルを解くことまたはマイニングによって順序付けが発生する暗号通貨ブロックチェーン・システム（例えば、ビットコインなど）とは異なり、この例では、分散型台帳７２０の関係者が、そのネットワークに最も適した順序付けメカニズムを選択してよい。

一部の実施形態では、順序付けサービス７１０は、新しいデータ・ブロック７３０を初期化し、新しいデータ・ブロック７３０がコミット・ピア（例えば、ブロックチェーン・ノード７１１、７１２、および７１３）にブロードキャストされてよい。それに応じて、各コミット・ピアは、読み取りセットおよび書き込みセットが状態データベース７２４内の現在の世界状態にまだ一致することをチェックして確認することによって、新しいデータ・ブロック７３０内のトランザクションの妥当性を確認してよい。特に、コミット・ピアは、署名者がトランザクションをシミュレートしたときに存在していた読み取られたデータが、状態データベース７２４内の現在の世界状態と同一であるかどうかを判定してよい。コミット・ピアがトランザクションの妥当性を確認した場合、トランザクションが分散型台帳７２０のブロックチェーン７２２に書き込まれてよく、状態データベース７２４が、読み取り／書き込みセットからの書き込みデータに更新されてよい。一部の実施形態では、トランザクションが失敗した場合（例えば、コミット・ピアが、読み取り／書き込みセットが状態データベース７２４内の現在の世界状態に一致しないということを検出した場合）、ブロック内に順序付けられたトランザクションは、そのブロックにまだ含まれるが、無効としてマーク付けされてよく、状態データベース７２４が更新されない。

図７Ｂを参照すると、一部の実施形態では、分散型台帳７２０のブロックチェーン７２２に格納された新しいデータ・ブロック７３０（データ・ブロックとも呼ばれる）が、ブロック・ヘッダー７４０、ブロック・データ７５０、およびブロック・メタデータ７６０などの、複数のデータ・セグメントを含んでよい。図７Ｂに示された新しいデータ・ブロック７３０およびその内容などの、さまざまな示されたブロックおよびそれらの内容が、例にすぎず、実施形態例の範囲を制限するよう意図されていないということが、理解されるべきである。新しいデータ・ブロック７３０は、ブロック・データ７５０内のＮ個（例えば、１、１０、１００、２００、１０００、２０００、３０００など）のトランザクションのトランザクション情報を格納してよい。新しいデータ・ブロック７３０は、（例えば、図７Ａのブロックチェーン７２２上の）前のブロックへのリンクをブロック・ヘッダー７４０内に含んでもよい。特に、ブロック・ヘッダー７４０は、前のブロックのヘッダーのハッシュを含んでよい。ブロック・ヘッダー７４０は、新しいデータ・ブロック７３０の一意のブロック番号、ブロック・データ７５０のハッシュなどを含んでもよい。新しいデータ・ブロック７３０のブロック番号は、一意であり、０から開始する漸進的／連続的順序などのさまざまな順序で割り当てられてよい。

ブロック・データ７５０は、新しいデータ・ブロック７３０内に記録された各トランザクションのトランザクション情報を格納してよい。例えば、トランザクション・データは、トランザクションの種類、バージョン、タイムスタンプ、分散型台帳７２０のチャネルＩＤ、トランザクションＩＤ、エポック、ペイロードの可視性、チェーンコード・パス（トランザクションのデプロイ）、チェーンコード名、チェーンコードのバージョン、入力（チェーンコードおよび関数）、公開鍵および証明書などのクライアント（作成者）の識別、クライアントの署名、署名者の識別情報、署名者の署名、提案のハッシュ、チェーンコード・イベント、応答の状態、名前空間、読み取りセット（トランザクションによって読み取られたキーおよびバージョンのリストなど）、書き込みセット（キーと値のリストなど）、開始キー、終了キー、キーのリスト、マークル・ツリー・クエリ・サマリー（Merkel tree query summary）などのうちの１つまたは複数を含んでよい。トランザクション・データは、Ｎ個のトランザクションの各々に格納されてよい。

一部の実施形態では、ブロック・データ７５０は、追加情報をブロックチェーン７２２内のブロックのハッシュリンクされたチェーンに追加する新しいデータ７６２を格納してもよい。追加情報は、本明細書で説明されたか、または示された、ステップ、特徴、プロセス、または動作、あるいはその組合せのうちの１つまたは複数を含んでよい。それに応じて、新しいデータ７６２が、分散型台帳７２０上のブロックの変更不可能なログに格納されてよい。そのような新しいデータ７６２を格納することの利点の一部が、本明細書において開示されて示されたさまざまな実施形態に反映されている。図７Ｂでは、新しいデータ７６２がブロック・データ７５０内で示されているが、一部の実施形態では、新しいデータ７６２は、ブロック・ヘッダー７４０またはブロック・メタデータ７６０内にあることもできる。新しいデータ７６２は、組織内の文書をリンクするために使用される文書複合キー（document composite key）を含んでもよい。

ブロック・メタデータ７６０は、メタデータの複数のフィールドを（例えば、バイト配列などとして）格納してよい。メタデータ・フィールドは、ブロック作成時の署名、最後の構成ブロックへの参照、ブロック内の有効なトランザクションと無効なトランザクションを識別するトランザクション・フィルタ、ブロックを順序付けた順序付けサービスの永続的な最後のオフセットなどを含んでよい。順序付けサービス７１０によって署名、最後の構成ブロック、および順序付けノードのメタデータが追加されてよい。一方、ブロックのコミッタ（ブロックチェーン・ノード７１２など）は、署名ポリシー、読み取り／書き込みセットの検証などに基づいて、有効／無効情報を追加してよい。トランザクション・フィルタは、ブロック・データ７５０内のトランザクションの数に等しいサイズのバイト配列、およびトランザクションが有効／無効だったかどうかを識別する妥当性確認コードを含んでよい。

図７Ｃは、一部の実施形態と一致する、デジタル・コンテンツのためのブロックチェーン７７０の実施形態を示している。デジタル・コンテンツは、１つまたは複数のファイルおよび関連する情報を含んでよい。これらのファイルは、トランザクション・データ、媒体、画像、ビデオ、音声、テキスト、リンク、グラフィックス、アニメーション、Ｗｅｂページ、文書、またはデジタル・コンテンツのその他の形態を含んでよい。一部のブロックチェーンの実施形態の変更不可能な追加専用の特徴は、デジタル・コンテンツの完全性、有効性、および信頼性を保護するための予防手段として機能することにおいて望ましいことがあり、認容性ルールが適用される法的手続きにおいて、あるいは証拠が考慮されるか、またはデジタル情報の提示および使用がその他の方法で対象になる、その他の状況において、デジタル・コンテンツの使用を適切にする。この場合、デジタル・コンテンツはデジタル証拠と呼ばれることがある。

これらの実施形態では、ブロックチェーンは、さまざまな方法で形成されてよい。１つの実施形態では、デジタル・コンテンツは、ブロックチェーン自体に含まれ、ブロックチェーンからアクセスされてよい。例えば、ブロックチェーンの各ブロックは、参照情報（例えば、ヘッダー、値など）のハッシュ値を、関連するデジタル・コンテンツと共に格納してよい。その後、ハッシュ値および関連するデジタル・コンテンツは、一緒に暗号化されてよい。したがって、各ブロックのデジタル・コンテンツは、ブロックチェーン内の各ブロックを復号することによってアクセスされてよく、各ブロックのハッシュ値は、前のブロックを参照するための基礎として使用されてよい。これは、次のように示されてよい。
ブロック１ ブロック２ ・・・・・・・ ブロックＮ
ハッシュ値１ ハッシュ値２ ハッシュ値Ｎ
デジタル・コンテンツ１ デジタル・コンテンツ２ デジタル・コンテンツＮ

１つの実施形態では、デジタル・コンテンツがブロックチェーンに含まれなくてよい。例えば、ブロックチェーンは、デジタル・コンテンツを含んでいない各ブロックの内容の暗号化されたハッシュを格納してよい。デジタル・コンテンツは、元のファイルのハッシュ値に関連して、別のストレージ領域またはメモリ・アドレスに格納されてよい。他のストレージ領域は、ブロックチェーンを格納するために使用されるストレージ・デバイスと同じストレージ・デバイスであってよく、または異なるストレージ領域もしくは分離したリレーショナル・データベースであってもよい。各ブロックのデジタル・コンテンツは、対象のブロックのハッシュ値を取得するか、または問い合わせ、次に、実際のデジタル・コンテンツに対応して格納されているハッシュ値をストレージ領域内で検索することによって、参照またはアクセスされてよい。この動作は、例えば、データベース・ゲートキーパーによって実行されてよい。これは、次のように示されてよい。
ブロックチェーン ストレージ領域
ブロック１のハッシュ値 ブロック１のハッシュ値・・・内容
・ ・
・ ・
・ ・
ブロックＮのハッシュ値 ブロックＮのハッシュ値・・・内容

図７Ｃの実施形態例では、ブロックチェーン７７０は、順序付けられた順序で暗号によってリンクされた複数のブロック７７８_１、７７８_２、．．．７７８_Ｎを含み、Ｎ≧１である。ブロック７７８_１、７７８_２、．．．７７８_Ｎをリンクするための使用される暗号化は、複数の鍵つきハッシュ関数または鍵なしハッシュ関数のいずれかであってよい。１つの実施形態では、ブロック７７８_１、７７８_２、．．．７７８_Ｎは、ブロック内の情報に基づいている入力からｎビットの英数字出力を生成するハッシュ関数の対象になる（ｎは２５６または別の数である）。そのようなハッシュ関数の例としては、ＳＨＡ型（ＳＨＡは、セキュア・ハッシュ・アルゴリズム（Secured Hash Algorithm）を表す）アルゴリズム、マークル・ダンガード・アルゴリズム、ＨＡＩＦＡアルゴリズム、マークルツリー・アルゴリズム、ノンスに基づくアルゴリズム、および非衝突耐性ＰＲＦアルゴリズムが挙げられるが、これらに限定されない。別の実施形態では、ブロック７７８_１、７７８_２、．．．、７７８_Ｎは、ハッシュ関数とは異なる関数によって、暗号によってリンクされてよい。例示の目的で、以下では、ハッシュ関数（例えば、ＳＨＡ－２）を参照して説明が行われる。

ブロックチェーン内のブロック７７８_１、７７８_２、．．．、７７８_Ｎの各々は、ヘッダー、ファイルのバージョン、および値を含んでよい。ヘッダーおよび値は、ブロックチェーン内のハッシュ処理の結果として、ブロックごとに異なってよい。１つの実施形態では、値がヘッダーに含まれてよい。下でさらに詳細に説明されるように、ファイルのバージョンは、元のファイルであってよく、または元のファイルの異なるバージョンであってよい。

ブロックチェーン内の最初のブロック７７８_１は、ジェネシス・ブロックと呼ばれ、ヘッダー７７２_１、元のファイル７７４_１、および初期値７７６_１を含んでよい。ジェネシス・ブロックに使用される（実際には、その後のすべてのブロックにおいて使用される）ハッシュ処理方式は、変化してよい。例えば、最初のブロック７７８_１内のすべての情報が一緒に同時にハッシュされてよく、または最初のブロック７７８_１内の情報の各々または一部が別々にハッシュされ、その後、別々にハッシュされ部分のハッシュが実行されてよい。

ヘッダー７７２_１は、１つまたは複数の初期パラメータを含んでよく、初期パラメータは、例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、合意プロトコル、期間、媒体形式、ソース、記述的キーワード、あるいは元のファイル７７４_１もしくはブロックチェーンまたはその両方に関連付けられたその他の情報、あるいはその組合せを含んでよい。ヘッダー７７２_１は、自動的に（例えば、ブロックチェーン・ネットワーク管理ソフトウェアによって）生成されるか、またはブロックチェーンの参加者によって手動で生成されてよい。ブロックチェーン内の他のブロック７７８_２～７７８_Ｎ内のヘッダーとは異なり、ジェネシス・ブロック内のヘッダー７７２_１は、単に前のブロックが存在しないため、前のブロックを参照しなくてよい。

ジェネシス・ブロック内の元のファイル７７４_１は、例えば、ブロックチェーンに含まれる前の処理を伴うか、または伴わずに、デバイスによって捕捉されたデータであってよい。元のファイル７７４_１は、システムのインターフェイスを介して、デバイス、媒体ソース、またはノードから受信されてよい。元のファイル７７４_１はメタデータに関連付けられてよく、メタデータは、例えば、ユーザ、デバイス、またはシステム・プロセッサ、あるいはその組合せによって、手動または自動のいずれかで、生成されてよい。メタデータは、元のファイル７７４_１に関連して、最初のブロック７７８_１に含まれてよい。

ジェネシス・ブロック内の値７７６_１は、元のファイル７７４_１の１つまたは複数の一意の属性に基づいて生成された初期値であってよい。１つの実施形態では、１つまたは複数の一意の属性は、元のファイル７７４_１のハッシュ値、元のファイル７７４_１のメタデータ、およびファイルに関連付けられたその他の情報を含んでよい。１つの実装では、初期値７７６_１は、以下の一意の属性に基づいてよい。
（１）ＳＨＡ－２によって元のファイルに対して計算されたハッシュ値
（２）発信デバイスＩＤ
（３）元のファイルの開始タイムスタンプ
（４）元のファイルの初期ストレージ位置
（５）元のファイルおよび関連するメタデータを現在制御するためのソフトウェアのブロックチェーン・ネットワーク・メンバーＩＤ

ブロックチェーン内の他のブロック７７８_２～７７８_Ｎも、ヘッダー、ファイル、および値を含む。しかし、最初のブロックのヘッダー７７２_１とは異なり、他のブロック内のヘッダー７７２_２～７７２_Ｎの各々は、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、単に前のブロックのヘッダーのハッシュであってよく、または前のブロック全体のハッシュ値であってよい。先行するブロックのハッシュ値を残りのブロックの各々に含めることによって、矢印７８０によって示されているように、Ｎ番目のブロックからジェネシス・ブロック（および関連する元のファイル）までのブロックごとのトレースを実行することができ、監査可能かつ変更不可能な証拠保全を確立する。

他のブロック内のヘッダー７７２_２～７７２_Ｎの各々は、一般に、他の情報（例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、合意プロトコル）、あるいは対応するファイルもしくはブロックチェーンまたはその両方に関連付けられたその他のパラメータまたは情報、あるいはその組合せを含んでもよい。

他のブロック内のファイル７７４_２～７７４_Ｎは、例えば実行される処理の種類に応じて、ジェネシス・ブロック内の元のファイルと同じであってよく、または元のファイルの変更されたバージョンであってよい。実行される処理の種類は、ブロックごとに変化してよい。処理は、例えば、情報を編集するか、またはその他の方法で情報の内容を変更するか、情報をファイルから取り除くか、または情報をファイルに追加するなどの、先行するブロック内のファイルの任意の変更を含んでよい。

追加的または代替的に、処理は、先行するブロックからファイルを単にコピーすること、ファイルのストレージ位置を変更すること、１つまたは複数の先行するブロックからのファイルを分析すること、ファイルをあるストレージまたはメモリ位置から別のストレージまたはメモリ位置に移動すること、あるいはブロックチェーンのファイルもしくは関連するメタデータまたはその両方に対して動作を実行することを含んでよい。ファイルを分析することを含む処理は、例えば、さまざまな分析、統計値、またはファイルに関連付けられたその他の情報を追加すること、含めること、またはその他の方法で関連付けることを含んでよい。

他のブロック内の他のブロック７７６_２～７７６_Ｎの各々に含まれる値は、実行された処理の結果として、一意の値であり、すべて異なっている。例えば、いずれか１つのブロック内の値は、前のブロック内の値の更新されたバージョンに対応する。この更新は、値が割り当てられたブロックのハッシュに反映される。したがって、ブロックの値は、ブロック内で何の処理が実行されたかの指示を提供し、ブロックチェーンを元のファイルまでトレースすることも可能にする。この追跡は、ブロックチェーン全体を通じて、ファイルの証拠保全を確認する。

例えば、ファイル内で示されている人の識別情報を保護するために、前のブロック内のファイルの一部が編集されるか、遮断されるか、または画素化される場合について考える。この場合、編集されたファイルを含むブロックは、例えば、編集がどのように実行されたか、誰が編集を実行したか、編集が発生したときのタイムスタンプなどの、編集されたファイルに関連付けられたメタデータを含むであろう。このメタデータがハッシュされ、値を形成してよい。ブロックのメタデータが、前のブロック内の値を形成するためにハッシュされた情報と異なっているため、値は、互いに異なっており、復号されたときに回復されてよい。

１つの実施形態では、次のうちのいずれか１つまたは複数が発生した場合に、現在のブロックの値を形成するように、前のブロックの値が更新されてよい（例えば、新しいハッシュ値が計算されてよい）。新しいハッシュ値は、この実施形態例では、以下に示された情報のすべてまたは一部をハッシュすることによって計算されてよい。
（ａ）ファイルがいずれかの方法で処理された場合（例えば、ファイルが編集されたか、コピーされたか、変更されたか、アクセスされたか、またはその他の動作が実行された場合）に、新しいＳＨＡ－２によって計算されたハッシュ値
（ｂ）ファイルの新しいストレージ位置
（ｃ）ファイルに関連付けられている識別された新しいメタデータ
（ｄ）あるブロックチェーンの参加者から別のブロックチェーンの参加者へのファイルのアクセスまたは制御の移動

図７Ｄは、一部の実施形態と一致する、ブロックチェーン７９０内のブロックの構造を表し得るブロックの実施形態を示している。ブロック（ブロック_ｉ）は、ヘッダー７７２_ｉ、ファイル７７４_ｉ、および値７７６_ｉを含んでよい。

ヘッダー７７２_ｉは、本明細書において説明された、前のブロック（ブロック_ｉ－１）のハッシュ値、および例えば情報の種類のいずれかであってよい、追加の参照情報（例えば、参照、特性、パラメータなどを含むヘッダー情報）を含んでよい。一部の実施形態では、すべてのブロックが前のブロックのハッシュを参照してよいが、一部の実施形態ではジェネシス・ブロックを除く。前のブロックのハッシュ値は、単に前のブロック内のヘッダーのハッシュであるか、またはファイルおよびメタデータを含む、前のブロック内の情報のすべてもしくは一部のハッシュであってよい。

ファイル７７４_ｉは、データ１、データ２、．．．、データＮなどの複数のデータを順に含んでよい。データは、データに関連付けられた内容または特性あるいはその両方を記述するメタデータ１、メタデータ２、．．．、メタデータＮでタグ付けされる。例えば、データごとのメタデータは、データのタイムスタンプ、データのプロセス、データに示された人もしくはその他の内容を示しているキーワード、またはファイルの有効性および内容を全体として確立し、特に、例えば下で説明される実施形態に関連して説明されるように、デジタル証拠を使用するのに役立ち得るその他の特徴、あるいはその組合せを示すための情報を含んでよい。メタデータに加えて、各データは、改ざん、ファイル内のギャップ、およびファイル全体の連続的な参照を防ぐために、前のデータへの参照（参照_１、参照_２、．．．、参照_Ｎ）でタグ付けされてよい。

一部の実施形態では、メタデータが（例えば、スマート・コントラクトを介して）データに割り当てられた後に、ハッシュを変更せずにメタデータを変更することはできず、ハッシュの変更は、無効であると容易に識別されることができる。したがって、これらの実施形態では、メタデータは、ブロックチェーン内の参加者による使用のためにアクセスされてよい、情報のデータ・ログを作成する。

一部の実施形態では、値７７６_ｉは、前に説明された情報の種類のいずれかに基づいて計算されたハッシュ値またはその他の値であってよい。例えば、いずれかの特定のブロック（ブロック_ｉ）の場合、そのブロックの値は、そのブロックに対して実行された処理（例えば、新しいハッシュ値、新しいストレージ位置、関連するファイルの新しいメタデータ、制御もしくはアクセスの移動、識別子、またはその他の動作もしくは追加される情報）を反映するように更新されてよい。各ブロック内の値が、ファイルおよびヘッダーのデータのメタデータから分離しているように示されているが、別の実施形態では、値は、このメタデータに部分的または全体的に基づいてよい。

一部の実施形態では、ブロックチェーン７７０が形成された後に、いずれかの時点で、ブロック全体にわたる値のトランザクション履歴に関してブロックチェーンに問い合わせることによって、ファイルの変更不可能な証拠保全が取得されてよい。この問い合わせ手順または追跡手順は、最後に含まれたブロック（例えば、最後の（Ｎ番目の）ブロック）の値を復号することから開始してよく、その後、ジェネシス・ブロックに達し、元のファイルが回復されるまで、他のブロックの値を復号し続ける。復号は、各ブロックでヘッダーおよびファイルならびに関連するメタデータを復号することを含んでもよい。

復号は、各ブロックで行われた暗号化の種類に基づいて実行されてよい。この復号は、秘密鍵、公開鍵、または公開鍵と秘密鍵のペアの使用を含んでよい。例えば、非対称暗号化が使用される場合、ブロックチェーンの参加者またはネットワーク内のプロセッサが、既定のアルゴリズムを使用して公開鍵および秘密鍵のペアを生成してよい。公開鍵および秘密鍵は、何らかの数学的関係によって互いに関連付けられてよい。公開鍵は、他のユーザからメッセージを受信するためのアドレス（例えば、ＩＰアドレスまたは自宅住所）として機能するように、パブリックに配布されてよい。秘密鍵は、秘密に保たれてよく、他のブロックチェーンの参加者に送信されるメッセージにデジタル署名するために使用されてよい。署名は、次に、受信者が送信者の公開鍵を使用して検証することができるように、メッセージに含まれてよい。このようにして、受信者は、送信者のみがこのメッセージを送信できたということを確信することができる。

一部の実施形態では、鍵のペアを生成することは、ブロックチェーンにアカウントを作成することに類似してよいが、実際は、どこにも登録する必要はない。これらの実施形態では、ブロックチェーンに対して実行されたすべてのトランザクションが、秘密鍵を使用して送信者によってデジタル署名されてよい。この署名は、アカウントの所有者のみが（スマート・コントラクトによって決定された許可の範囲内である場合に）ブロックチェーンのファイルを追跡して処理することができるということを保証するのに役立つことがある。

コンピュータ・プログラム製品
本発明は、本発明の特定の例を参照して詳細に説明されたが、本発明の本質的思想または属性から逸脱することなく、他の特定の形態で具現化されてもよい。例えば、本発明は、任意の可能な統合の技術的詳細レベルで、システム、方法、またはコンピュータ・プログラム製品、あるいはその組合せであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含むコンピュータ可読ストレージ媒体を含んでよい。コンピュータ可読プログラム命令は、単一のコンピュータ上で格納または実行されるか、あるいは格納および実行のために、同じ位置または異なる位置で、異なるコンピュータ間で分割されることができる。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組合せであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disc read-only memory）、デジタル・バーサタイル・ディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー（Ｒ）・ディスク、命令が記録されているパンチカードまたは溝の中の***構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組合せを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組合せ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組合せを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組合せで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、顧客のコンピュータ上で全体的に実行するか、顧客のコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行するか、顧客のコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行するか、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行してよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域ネットワーク（ＷＡＮ：wide area network）を含む任意の種類のネットワークを介して顧客のコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：field-programmable gate arrays）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路を個人向けにするためのコンピュータ可読プログラム命令を実行してよい。

これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施する手段を作り出すべく、コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実施する命令を含む製品を含むように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組合せに特定の方式で機能するように指示できるものであってもよい。

コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施するように、コンピュータ実装プロセスを生成するべく、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスにロードされ、一連の動作ステップを、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行させるものであってもよい。

一般
図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、１つのステップとして実現され得、同時に、実質的に同時に、時間的に部分的または完全に重複する方法で実行され得るか、あるいは場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組合せは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組合せを実行する専用ハードウェアベースのシステムによって実装されることができるということにも注意する。

本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明された。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組合せが、コンピュータ可読プログラム命令によって実装されることができるということが理解されるであろう。さらに、図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組合せは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組合せを実行する専用ハードウェアベースのシステムによって実装され得るということにも注意する。

本説明において使用された特定のプログラムの名前は単に便宜のためであり、したがって、本発明は、そのような名前によって識別されたか、または暗示されたか、あるいはその両方である特定のアプリケーションのみで使用するように限定されるべきではない。したがって、例えば、本発明の実施形態を実施するために実行されるルーチンは、オペレーティング・システムまたは特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、あるいは命令のシーケンスのいずれの一部として実施されようと、「プログラム」、「アプリケーション」、「サーバ」、またはその他の意味のある名前で呼ばれることができた。実際、他の代替的ハードウェア環境またはソフトウェア環境あるいはその両方が、本発明の範囲から逸脱することなく使用されてよい。

したがって、本明細書に記載された実施形態が、あらゆる点で制限ではなく例示であると見なされ、本発明の範囲を決定するために添付の特許請求の範囲に対する参照が行われるのが望ましい。

Claims (20)

1. アクセス管理プロセス調整方法であって、
   情報システムの管理されたリソースにアクセスするための要求を受信することと、
   アクセス・マネージャからの前記リソースにアクセスするための許可を問い合わせることと、
   前記許可の前記問い合わせに応答して、前記管理されたリソースに対するアクセス権限を付与するように、アクセス制御ポリシーの更新を要求することとを含み、
   前記要求を受信すること、前記許可を問い合わせること、および前記アクセス制御ポリシーの更新を要求することが、
   トランザクション・レコードを生成すること、および
   前記トランザクション・レコードを分散型台帳に追加することを含み、前記分散型台帳が、ネットワーク全体にわたる複数のノードで、前記トランザクション・レコードを同時に維持する、アクセス管理プロセス調整方法。
2. 前記方法が、前記トランザクション・レコードを前記分散型台帳の前記複数のノード間で交換することをさらに含む、請求項１に記載の方法。
3. 前記複数のノードが、暗号によって保護されたチャネルを介して相互接続される、請求項１または２に記載の方法。
4. 前記トランザクション・レコードが、アクセス権限要求動作、アクセス権限承認済み動作、アクセス権限拒否済み動作、アクセス権限付与済み動作、アクセス権限取り消し動作、およびアクセス権限取り消し済み動作から成る群から選択された少なくとも１つの管理動作を含む、請求項１ないし３のいずれか一項に記載の方法。
5. 前記アクセス権限付与済み動作に関連付けられた前記管理動作が、前記情報システムに対するユーザのアクセス権限を許可するように許可ポリシーを変更する、請求項４に記載の方法。
6. 前記アクセス権限取り消し動作に関連付けられた前記管理動作が、前記情報システムに対するユーザのアクセス権限を拒否するように許可ポリシーを変更する、請求項４または５に記載の方法。
7. 前記トランザクション・レコードを前記情報システムに送信することと、
   前記情報システムに対して前記管理動作を自動的に実行することとをさらに含む、請求項４ないし６のいずれか一項に記載の方法。
8. 前記アクセス制御ポリシーの更新を要求することが、前記分散型台帳内のトランザクションを処理するスマート・コントラクトを実行することを含む、請求項１ないし７のいずれか一項に記載の方法。
9. 前記情報システムの前記管理されたリソースが、複数の情報システムの複数の管理されたリソースのうちの１つであり、
   前記複数の情報システムの各々がローカル・アクセス制御システムを含み、
   前記方法が、ローカル許可ポリシーに対する変更を要求するために前記ローカル・アクセス制御システムのうちの１つを呼び出すことをさらに含む、請求項１ないし８のいずれか一項に記載の方法。
10. 前記受信された要求を前記情報システムの所有者に送信することと、
    前記要求に応答する承認を前記情報システムの前記所有者から受信することと、
    前記承認を前記分散型台帳に記録することと、
    前記要求を前記情報システムの管理者に送信することと、
    前記情報システムに対して、前記要求に応答する動作を実行することと、
    前記動作を前記分散型台帳に記録することと
    をさらに含む、請求項１ないし９のいずれか一項に記載の方法。
11. ブロックチェーン・ネットワークに関連付けられたピア・ノードを含むアクセス管理制御オーケストレータであって、前記ブロックチェーン・ネットワークが、アセット所有者機能、管理者機能、および監査人機能のうちの少なくとも１つに関連付けられた複数のノードを含み、前記ピア・ノードが、
    情報システムのユーザからのアクセス権限要求レコードを分散型台帳に記録することと、
    前記アセット所有者機能からの所有者承認レコードを記録することであって、前記所有者承認レコードが、前記分散型台帳内の前記アクセス権限要求レコードに応答する、前記記録することと、
    前記アクセス権限要求レコードおよび前記所有者承認レコードに応答してスマート・コントラクトを実行し、前記情報システムに対するアクセス権限を付与することであって、前記スマート・コントラクトが、前記情報システムに対する前記ユーザのアクセス権限を許可するように許可ポリシーを変更する、前記付与することと、
    前記スマート・コントラクトの実行レコードを前記分散型台帳に記録することと
    を実行するように適応される、アクセス管理制御オーケストレータ。
12. 前記ピア・ノードが、
    前記アクセス権限要求レコード、前記所有者承認レコード、および前記実行レコードのうちの１つまたは複数をトランザクション・ブロックに格納することと、
    前記複数のノードのうちの１つを、合意プロトコルに従って前記トランザクション・ブロックに署名するための署名ノードとして選択することと、
    前記選択された署名ノードによって、前記トランザクション・ブロックに署名することと
    を実行するようにさらに適応される、請求項１１に記載のアクセス管理制御オーケストレータ。
13. 前記ピア・ノードが、
    新しいノードを前記ブロックチェーン・ネットワークに追加するための新規ピア要求を受信することと、
    前記新規ピア要求を、合意プロトコルに従って承認するために、前記ブロックチェーン・ネットワーク内の前記複数のノードに送信することと
    を実行するようにさらに適応される、請求項１１または１２に記載のアクセス管理制御オーケストレータ。
14. 前記許可ポリシーを変更することが、前記情報システムに関連付けられたローカル・アクセス制御システムを呼び出し、ローカル許可ポリシーに対する変更を要求することを含む、請求項１１ないし１３のいずれか一項に記載のアクセス管理制御オーケストレータ。
15. 前記ピア・ノードが、所有者承認レコードに関連付けられていない実行レコードに関して前記分散型台帳を再検討するようにさらに適応される、請求項１１ないし１４のいずれか一項に記載のアクセス管理制御オーケストレータ。
16. 複数の命令が格納されている非一過性コンピュータ可読ストレージ媒体を備えるコンピュータ・プログラム製品であって、前記命令が、プロセッサによって実行された場合に、前記プロセッサに、
    情報システムの管理されたリソースにアクセスするための要求を受信することと、
    アクセス・マネージャからの前記リソースにアクセスするための許可を問い合わせることと、
    前記許可の前記問い合わせに応答して、前記管理されたリソースに対するアクセス権限を付与するように、アクセス制御ポリシーの更新を要求することと
    を実行させ、
    前記要求を受信すること、前記許可を問い合わせること、および前記アクセス制御ポリシーの更新を要求することが、
    トランザクション・レコードを生成すること、および
    前記トランザクション・レコードを分散型台帳に追加することを含む、コンピュータ・プログラム製品。
17. 前記トランザクション・レコードが、アクセス権限要求レコード、アクセス権限承認済みレコード、アクセス権限拒否済みレコード、アクセス権限付与済みレコード、アクセス権限取り消しレコード、およびアクセス権限取り消し済みレコードから成る群から選択された少なくとも１つの管理動作を含む、請求項１６に記載のコンピュータ・プログラム製品。
18. 前記情報システムの前記管理されたリソースが、複数の情報システムの複数の管理されたリソースのうちの１つであり、
    前記情報システムの各々がローカル・アクセス制御システムを含み、
    プロセッサによって実行された場合に、前記プロセッサに、前記ローカル・アクセス制御システムのうちの１つを呼び出して、ローカル許可ポリシーに対する変更を要求させる命令をさらに含む、請求項１６または１７に記載のコンピュータ・プログラム製品。
19. プロセッサによって実行された場合に、前記プロセッサに、
    前記受信された要求を前記情報システムの所有者に送信することと、
    前記要求に応答する承認を前記情報システムの前記所有者から受信することと、
    前記承認を前記分散型台帳に記録することと、
    前記要求を前記情報システムの管理者に送信することと、
    前記情報システムに対して、前記要求に応答する動作を実行することと、
    前記動作を前記分散型台帳に記録することと
    を実行させる命令をさらに含む、請求項１６ないし１８のいずれか一項に記載のコンピュータ・プログラム製品。
20. 前記アクセス制御ポリシーの更新を要求することが、前記分散型台帳内のトランザクションを処理するスマート・コントラクトを実行することを含む、請求項１６ないし１９のいずれか一項に記載のコンピュータ・プログラム製品。

Images