JP2023529671A - コンフェデレーテッド権利及び階層キー管理のための方法、装置、及びコンピュータ可読媒体 - Google Patents

Abstract

コンピュータ・ネットワークを通したデータ権利の安全なピア・ツー・ピアノ転送のための方法及び装置であって、方法は、分散型台帳プラットフォームを含む分散コンピューティング・システムによって達成される。ルート権利が定義され、マルチレベルの方式でウォレットに委譲され、それにより、ルート権利と関連付けられたウォレットをサイバー・リスクから隔離する。

Description

本出願は、２０２０年６月１０日に出願された米国仮特許出願第６３／０３７，０３４号の優先権を主張し、その開示全体を参照により本明細書に組み込む。

本発明は、分散コンピュータ・ネットワークにおけるセキュリティ及びトランザクションの柔軟性を増大させて、価値の保護及びトランザクションの回復を可能にする、暗号キー管理のためのシステム、データ構造、及びプロセスに関する。

著作権表示
本特許文献の開示の一部分は、著作権保護の対象である資料を含む。著作権保有者は、特許商標局の包袋又は記録に見られるような、特許文献又は特許開示のいずれかの複製に対して異議を唱えるものではないが、それ以外はいかなる場合でも全ての著作権を保有する。

ブロックチェーン・プロトコルに基づいたネットワークなどの分散ネットワーク（分散型台帳技術（ＤＬＴ）としても知られる）は、当事者間のトラストレス・トランザクションに対する強力なベースラインとなる。一技術として、分散ネットワークは、１）コンセンサスの不変性、及び２）分散された権限という、金融エコシステムに対する２つの強力なイネーブラとなる。コンセンサスの不変性を通して、全ての当事者が、トランザクションが適切に記録されており後で変更できないことを確信することができる。分散された権限は、銀行及び政府機関などの仲介者を必要とせずに、行為者が自身の権利を実行できるようにする。

これらのイネーブラは強力であるが、それら自体で複雑な金融エコシステムの商行為に対する全ての要件を網羅するには不十分である。広く採用されるためには、トラストレス・トランザクションのコンピュータ・ネットワーキング・インフラストラクチャを拡張して、価値の開示及び表現に固有のトラスト及び権限の要素、グループのコンテキストにおける暗黙の許可、並びにエンティティ間の提携を組み込まなければならない。一例として、基本的課題について検討する。Ｂｉｔｃｏｉｎなどのトラストレス・ブロックチェーン証券は無記名式証券である。Ｂｉｔｃｏｉｎを包含する公開アドレスに対する秘密を所持する当事者のみが、この価値に対する所有権（この場合、送信する権利）を行使してもよい。このモデルの主要な利益は、仲介者なしに任意のサイズのトランザクションを遂行できることであり、それによって、これらのトランザクションが「検閲なし」であることが確保される。しかしながら、この利益には著しいリスクが伴う。保管の喪失又は流用が発生した場合の償還はない。「ウォレット」に対するキー（分散型台帳に対して状態変化を与えるのに使用される公開／秘密キーの組み合わせ）が喪失又は盗難された場合、価値回復のためのメカニズムがない。

無記名式証券が、「力こそ正義」の条件を作り出すこと、つまり「取ったもの勝ち（ｉｆ ｙｏｕ ｃａｎ ｔａｋｅ ｉｔ， ｙｏｕ ｏｗｎ ｉｔ）」であることは、歴史が示している。現金（紙幣）は、人々が現金を持ち歩かなければならない場所で窃盗が一般的であり得ることの一例である。ブロックチェーン・トランザクションは不可逆的であるため、権限者が盗難された価値を回復することは困難であり得、又は更には不可能であり得る。結果として、Ｂｉｔｃｏｉｎは、攻撃者が被害者のデータを暗号化し、攻撃者と関連付けられたウォレットに仮想通貨を転送する際にのみ復号キーを提供する、「ランサムウェア」などの特定の取立て方法に対して好ましい通貨である。当然ながら、流用に直面したときに償還がないことは、公正な金融エコシステムのコア・バリューの正反対である。結果として、ブロックチェーン価値の所有者は、自身の価値を保護する管理人となる場合が多い。所有者が仲介者となった場合、システムは、多くのブロックチェーン支持者が置換しようとしている集中システムと本質的に違わない。

米国特許出願第１６／１４３，０５８号

上述の制限により、コンセンサス、不変性、及び分散された権限といった分散ネットワークの技術的特質を保持したまま、キュレーション権利を定義し行使する手法（例えば、中でも特に、違法なトランザクションを無効にする、又は喪失した価値を回復するメカニズム）が必要とされる。トラストレス・システムを拡張してトラストを組み込むには、独立エンティティが、権利、ポリシー、及びコントラクトを介して定義し、共有し、取り引きするのを可能にする、層状の権利ガバナンス構造を要する。本明細書の本開示は、権利が力ずくで、窃盗によって、又は事故によって消去されないよう保護するように設計された、ネットワーク・アーキテクチャ及び窃盗データ・モデルを明確に表現する。開示する実現例によって、分散ネットワークの利益が保たれるとともに、サイバー脅威から保護され、流用に対する償還が提供されながら、参加者が仲介者なしでトランザクションを遂行することができるようになる。開示する実現例は、次の２つの基礎的な技術革新を活用する。１）コア権利の回復に対するサイバー脅威を軽減又は排除するメカニズム（「階層キー管理」）、並びに２）中央権限なしに権利を確立し、譲渡し、施行するフレームワーク（「コンフェデレーテッド権利管理（ｃｏｎｆｅｄｅｒａｔｅｄ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ）」）。これら２つの革新をリンクさせて、従来技術の制限を克服する分散コンピュータ・ネットワークを提供することができる。

「トークン」として知られるブロックチェーン・ベースのアセットに関する無記名式証券の問題は、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔを導入することによって、つまり、違法の若しくは誤ったトランザクションに対してトランザクションを無効にする、又は価値を「クローバック」する権利を有する当事者を導入することによって、解決することができる。特定のアセットに対してこの権利を決定するメカニズムが提供されなければならない。ステークホルダは、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ権利を与えられた当事者に信用及び資格がある（例えば、法的権利を有する、権利が誤用された場合に責任を課せられる、及び責任を十分に認識している）と知ることができなければならない。更に、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔが不正アクセスされたり、支払い不能になったり、又は無能力になったりする可能性に対処しなければならない。

トークン転送に関するこれらの問題それぞれに対する技術的解決策を追求する際、一般に、あらゆるコンテキストにわたって広く適用できる、権利に対するより進んだ方策を開発しなければならない。集中モデル又はフェデレーテッド・モデルを通してではなく、当事者が連合（権利を自発的に定義し適用することに同意する２つ以上の当事者のグループ）を形成することを可能にする技術的方策である、コンフェデレーテッド権利管理を本明細書に開示する。コンフェデレーテッド権利管理は、ブロックチェーンの分散された利益を保護するとともに、連合を自由に形成し解散することを可能にする。

「フェデレーテッド」管理モデルと「コンフェデレーテッド」管理モデルとの違いを理解することが重要である。フェデレーテッド権利モデルでは、当事者は、権利を定義し割り当てる能力である主権が新たに作成されたエンティティに委ねられる取り決めに加わる。他方で、コンフェデレーテッド・モデルは、権利の定義又は割当てに対して当事者が自由に同意又は反対することができる、連合による方策によって特徴付けられる。コンフェデレーテッド・モデルにおいて互いに効率的に取り引きするには、構成者は、権利が何であることを意味するか、及び権利がどのように譲渡されるかのみに同意すればよい。当事者は、権利の共通の定義及び制御に自由に加わることができ、いずれの制御モデルにも等しく自由に反対又は離脱することができる。

ブロックチェーン・ネットワークは、単純なコンフェデレーテッド権利モデルの実例である。これらのネットワークで符号化される基本権利は、トランザクションに署名する権利、つまりネットワークにおける状態変化を承認する権利である。参加することによって、構成者は、少なくとも暗示的に、権利が表現され譲渡されるのに用いられる基本構造（ネットワーク・ガバナンス）に合意する。しかしながら、提携にはトラストが必要であり、それにはトラストレス分散型台帳システムの上に構築されたフレームワークを要する。開示する実現例によるコンフェデレーテッド権利モデルは、フェデレーション、即ち影響なく離れることができない連合の当事者間で合意を結ぶことをサポートするが、これを義務付けない。しかし、継続的で大規模な権利の展開には、連合が連合合意を迅速に形成し解消して相互利益を達成できるようにするのに用いられるメカニズムを要する。

開示する実現例のコンフェデレーテッド権利のフレームワークでは、権利又は信用性のいずれの割当ても相対的であることができる。参加者は、特定の権利、ポリシー、コントラクト、又はオブジェクトが、参加者に利益をもたらす手法で管理されているか否かを決定することができる。これには、属性、ポリシー、コントラクト、エンティティ（個人又はグループ）、及びオブジェクトを連合が定義できるようにする、技術プロトコル及びデータ・モデルが必要である。

Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ権利の実現に戻ると、コンフェデレーテッド権利管理の方策は、開示する実現例を使用して適用することができる。暗号トークン又は他のデジタル・トークンのコンテキスト内で、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ権利は責任のある当事者によって適用されてもよい。トークンを作成する際、当事者は、トークンのコンテキスト内で権利を管理する権利を有する、デフォルトの発行者になる。認定された当事者のみが発行者権利を取得してもよい（発行者認定プロセスは、自身のコンフェデレーテッド・モデルで実現することができる）。発行者は、権利を管理する権利をトークン保持者に書き換えてもよく、トークン保持者は、コンセンサス投票又は自己主権型トークン・モデルを通して自身の権利を行使してもよい。マネージャ権利の保持者は、権利を保持する資格が（やはりコンフェデレーテッド・モデルを通して）与えられている候補者のリストから、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔを割り当ててもよい。不正アクセスされたか又は無効の場合、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔの役割を、マネージャ権利を保持する当事者によって再割当てすることができる。

Ｍａｎａｇｅｒ権利（トークンのコンテキストでは、これは「ルート」権利である）を保持する当事者が不正アクセスされた場合、ルート権利の課題を解決するには、ルート権利の不正アクセス又は喪失に対して保護する革新的な技術的メカニズムが必要である。解決策は、全てのネットワーク行為がサイバー・リスク及び運用リスクをもたらすが、低頻度のアクションは機能の有用性を制限するという、Ｃｕｓｔｏｄｙ Ｐａｒａｄｏｘを解決する必要がある。換言すれば、唯一の安全な権利は決して使用されない権利である。サイバー・リスクを評価するのがほぼ不可能なため、この償還のパラドックスはブロックチェーン業界が保証することを困難にしている。サイバー・リスクを軽減する主な解決策は、トランザクションを承認する際に安全な場所でともに参加する独立エンティティが関与する高保証プロセスである署名の儀式を通して、権限を行使することである。しかし、このプロセスは、サイバー・リスクを軽減するための設計により、低速で高価である。プロセスをより高速にすることはリスクをもたらす。この問題は、「ホット」（高速／高リスク）又は「コールド」（低速／高価）であるウォレット間に中間がないため、ブロックチェーンの有用性を制限している。

委譲を通してこのパラドックスを解決するため、「層状ウォレット」の概念が、開示する実現例で使用されている。かかる委譲を通して、ルート・ウォレットは、トランザクションに署名するのに必要なサイバー・リスクを許容することができるウォレットに、その権限を（必要な場合は繰り返し）委譲している間、不活性のままであることができる。権限は、委譲された権利が不正アクセス又は誤用された場合に取り戻すことができる。不正アクセスされた場合に、コールド・ウォレットを介して権限を行使することによって回復するか又は無効にすることができる、高速で可逆的なトランザクションに対してホット・ウォレットを介して権限を表現することができるので、層化は所望のモデルを生成する。コールド・ウォレットから権限を行使するための唯一の要件は、不正アクセスされた場合に委譲された権利を回復することであるが、これは恐らくほとんど起こらない。回復が頻繁である場合、委譲モデルは、ルートがこれまで使われた可能性が低いことを保証するため、必要な回数繰り返されてもよい。このモデルは、ルートが最高レベルの確実性で格納されるものと仮定する。構造がその使用を防ぐことができるので、サイバー・リスクが軽減されて、トランザクション参加者のリスク・エクスポージャが制限される。

本発明の１つの態様は、分散型台帳プラットフォームを含む分散型コンピューティング・ネットワークにおける状態変化として表される、データ・トランザクションの安全な承認のための方法であって、方法は、分散型コンピューティング・ネットワークで実行するスマート・コントラクト・コードで表現されるルート権利であって、指定された機能の実行を許可することによって不変の権利を作成するルート権利を作成することと、指定された機能の少なくとも１つを許可する権利を、分散ネットワーク上でルート権利からウォレットに委譲して、ウォレットが機能の少なくとも１つに対応するトランザクションに署名する権利を有することを可能にする、委譲された権利を作成することであって、委譲された権利をルート権利によって取消し又は再割当てすることができることと、権利を委譲することを表すデータ構造を委譲レジストリに記録することと、ウォレットとのトランザクションに署名することによってウォレット権利を行使することにより、分散型コンピューティング・ネットワークにおけるトランザクションを承認することと、を含む。

開示する実現例のＲｏｏｔ Ｒｉｇｈｔ及び委譲構造を示す、本明細書で使用されるシンボル体系の実例を示す図である。 開示する実現例による、層状の委譲のパターンを示す概略図である。 開示する実現例による、層状のウォレット管理に基づいた動作のシーケンスの実例を示す概略図である。 開示する実現例による、コンフェデレーテッド権利管理システムを完全実装するためのスマート・コントラクト・アーキテクチャを示す概略図である。 開示する実現例による、コンフェデレーテッド権利管理システムを完全実装するためのスマート・コントラクト・アーキテクチャを示す概略図である。 開示する実現例による、権利オブジェクト５００の実例を示す概略図である。 開示する実現例による、ポリシー・オブジェクトを示す概略図である。 開示する実現例による、スマート・コントラクト・オブジェクトを示す概略図である。 開示する実現例による、トークン・オブジェクトを示す概略図である。 開示する実現例による、アセット・オブジェクトを示す概略図である。

開示する実現例は、「仮想通貨ウォレット」及び「スマート・コントラクト」を活用する。仮想通貨ウォレット、又は単に「ウォレット」は、仮想通貨トランザクションのための公開キー及び／又は秘密キーを格納する、デバイス、物理的媒体、プログラム、又はサービスである。ウォレットは、アルゴリズム・サイズに応じた長さを有する理論上の数又は乱数を生成することによって、作成することができる。数は次に、仮想通貨暗号アルゴリズム要件の特定の要件を使用して、秘密キーに変換される。次に、必要とされるいずれかの暗号アルゴリズム要件を使用して、公開キーが秘密キーから生成される。秘密キーは、仮想通貨にアクセスし送信するのに所有者によって利用され、所有者個人のものであるが、公開キーは、仮想通貨を受信するのに任意の第三者に共有される。「スマート・コントラクト」は、ブロックチェーンなど、分散ネットワークに少なくとも部分的に格納され実行される実行可能コードである。Ｓｍａｒｔ Ｃｏｎｔｒａｃｔ内では、ウォレットの所有者（即ち、トランザクションに署名するのに必要な秘密を所持する当事者）が、機能を実施する（即ち、ネットワークの分散型台帳に対して状態変化をもたらす）権利は、コードによって決定することができる。コードは、分散型台帳に不変に書き込むことができるデータに基づいて、機能を実施する権利を評価することができる。例えば、当事者は、１つの分散型台帳アドレス（ウォレット）から別のアドレスにトークンを、例えば、ＥＲＣ－２０の「ＴｒａｎｓｆｅｒＦｒｏｍ」機能をＥｔｈｅｒｅｕｍ台帳で実行することによって影響を受ける状態変化を、送信したいことがある。署名されたトランザクションをＥｔｈｅｒｅｕｍ台帳にポストする際、署名者が機能を実行する権利は、単純な実例では、書換えを遂行することが承認されたアドレスのリスト（ホワイト・リスト）を参考にすることによって、スマート・コントラクト・コードによって決定することができる。このリストは、分散型台帳に格納され、トランザクションの承認側当事者によって管理されるデータであり、標準的技法は当該技術分野の実施者によって十分理解されている。トランザクションが署名されると、スマート・コントラクトは、署名者の公開アドレスと権利を定義するデータとの一致に基づいて、署名者が承認された当事者であることを検証することができる。

承認の別の実例は、トークン発行、即ちトークンの新しい単位を作成する権利に関する。この権利は、この権利を保持する当事者が、承認された条件下でのみ権利を行使して、トークン保持者の価値の望ましくない希釈化を防ぐように、全てのトークン保持者に対して責任を負うので、特に慎重に扱うべきである。Ｔｏｋｅｎ Ｃｒｅａｔｏｒ（即ち、Ｔｏｋｅｎのスマート・コントラクトを展開したトランザクションに署名した当事者）は、更なるトークンを発行する権利を得られてもよい。作成の際、Ｔｏｋｅｎスマート・コントラクトは、Ｔｏｋｅｎ Ｃｒｅａｔｏｒの公開アドレスを記録するデータを格納してもよい。Ｉｓｓｕｅ機能が呼び出されると、スマート・コントラクトは、署名者がＣｒｅａｔｏｒのアドレスであるか否かを評価してもよく、そのアドレスである場合、トランザクションを進めるのを可能にしてもよい。下記の表及び疑似コードはこの機能性を示している。

この基本の疑似コードは、Ｒｏｌｅ Ｂａｓｅｄ Ｓｙｓｔｅｍで共通である。分散ネットワークによって得られた不変性及び分散権限の力を利用して、この単純なシーケンスは、集中管理者なしに権利を管理する相当な柔軟性を提供する。しかしながら、この力は、権利と関連付けられたアドレスが喪失又は不正アクセスされた場合に、回復不能な喪失（この場合、価値の希釈化）をもたらす可能性がある。Ｃｒｅａｔｏｒ権利と関連付けられたウォレットに対する秘密が喪失又は盗難された場合、所望の機能を実施できる当事者はなく、場合によってはスマート・コントラクトと関連付けられた価値が無用になる。Ｃｒｅａｔｏｒがその権限を行使する（トランザクションに署名する）たびに、サイバー・アタックによるキー不正アクセスの可能性がある。これらの重要な「システム」権利は、本明細書では「Ｒｏｏｔ」権利と呼ばれる。署名権限の分散を損なうことなく制御の喪失の可能性を軽減することによって、Ｒｏｏｔ権利の回復不能な性質を保護する、革新的な技術メカニズムが求められている。

開示する実現例では、Ｒｏｏｔ権利は、スマート・コントラクトの作成時に、又は別の方式で設定することができる、不変データとして格納された価値に基づいて割り当てられる、名前付きの権利である。上述したように、スマート・コントラクトは、その作成者を格納し、この性質を参考にして、Ｃｒｅａｔｏｒ権利によって保護された機能を承認してもよい。Ｒｏｏｔ権利は変更することができないので、この権利と関連付けられたウォレットが不正アクセスされた場合、回復不能な価値の喪失に対する条件を作成する。ウォレットを不正アクセスから保護するため、スマート・コントラクトは、後述するＩＤｅｌｅｇａｂｌｅＲｉｇｈｔｓインターフェース及びスマート・コントラクトを実現してもよい。このインターフェースは、権限を行使するのに「捨て」ウォレットを使用することができ、不正アクセスされた場合、これらのウォレットを破棄及び／又は置換することができるように、Ｒｏｏｔ権利を委譲できるようにする。

別個のスマート・コントラクトを、Ｒｏｏｔ権利の保護専用にすることができる。表又は他のデータベースとして格納されたデータ構造のセットである、ＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙは、Ｒｏｏｔ権利を１回又は複数回委譲することを可能にして、リスク管理のための「層状」のウォレット構造を作成する。ＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙのための基本データ構造の実例を以下に示す。

このデータ構造では、Ｃｏｎｔｒａｃｔは、Ｒｏｏｔ権利が実行され、Ｒｏｏｔアドレスが記録されるスマート・コントラクトを表し、Ｒｉｇｈｔは、このコントラクトによって保護される権利であり、Ｐａｒｅｎｔは、権利を委譲するアドレスであり、Ｄｅｌｅｇａｔｅは、この権利が割り当てられているアドレスである。表示されたデータでは、Ｃｏｎｔｒａｃｔ ０ｘａａｂｂｃｃｄｄに対するＣｒｅａｔｏｒ権利は、ルート・ウォレット０ｘ１２３４によってデリゲート０ｘ５６７８に割り当てられている。

ＩＤｅｌｅｇａｂｌｅＲｉｇｈｔｓスマート・コントラクトのＩｓｓｕｅ機能が、Ｃｒｅａｔｏｒのみがこの機能を実行してもよいように保護される、実例を仮定する。Ｉｓｓｕｅ機能が呼び出された場合、スマート・コントラクトは最初に、署名者がＣｒｅａｔｏｒであるかをチェックする。違う場合、コントラクトはＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙをチェックして、ＩＤｅｌｅｇａｂｌｅＲｉｇｈｔｓコントラクトに対するＣｒｅａｔｏｒ権利が委譲されているかを確認し、署名者がデリゲートである場合、署名者は真を返すデリゲートである。

上記から明らかなように、ＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙは、委譲記録をデータ構造としてデータベースに格納する。このレジストリは、本明細書では「Ｅｘｅｃｕｔｉｏｎ」コントラクトと呼ばれる、ＩＤｅｌｅｇａｂｌｅＲｉｇｈｔインターフェースを実装するＳｍａｒｔ Ｃｏｎｔｒａｃｔによって操作される。全ての委譲記録は、スマート・コントラクトが他のスマート・コントラクトの権利委譲に影響を及ぼすのを防ぐため、記録を作成したＳｍａｒｔ Ｃｏｎｔｒａｃｔでマーキングされる。一例として、ＩＤｅｌｅｇａｂｌｅＲｉｇｈｔインターフェースは、Ｄｅｌｅｇａｔｅ（権利、ウォレット）、Ｒｅｐｌａｃｅ（権利、ウォレット、ｎｅｗＷａｌｌｅｔ）、及びＳｕｂｓｕｍｅ（権利、ウォレット）の３つのコールをサポートすることができる。

図１は、Ｒｏｏｔ Ｒｉｇｈｔ及び委譲構造を示す、本明細書の以下の図で使用されるシンボル体系を示している。Ｒｏｏｔ Ｗａｌｌｅｔの委譲可能な権利は１０２で表され、機能性ウォレットは１０４で表される。ＩＤｅｌｅｇａｂｌｅＲｉｇｈｔインターフェースを実装するＳｍａｒｔＣｏｎｔｒａｃｔｓは、ＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙデータベースを使用して、Ｒｏｏｔ権利を１回又は複数回委譲できるようにして、リスク管理のためのＬａｙｅｒｅｄＷａｌｌｅｔ構造を作成する。

権利を委譲するには、権利を保持する当事者がＩＤｅｌｅｇａｂｌｅＲｉｇｈｔに署名する。ＤｅｌｅｇａｔｅはＥｘｅｃｕｔｉｎｇ Ｃｏｎｔｒａｃｔを介して機能する（権利によって保護された特定の機能を実行する、特定のスマート・コントラクト）。Ｅｘｅｃｕｔｉｎｇ Ｃｏｎｔｒａｃｔは、発信者が委譲しようと試みている権利を有することを検証し、次にＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙを呼び出して、ＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙデータベースへの記録を通して権利を委譲する（Ｃｒｅａｔｏｒ権利を委譲するのに使用される上述のサンプル・データの場合、これは、０ｘ１２３４が０ｘａａｂｂｃｃｄｄ Ｅｘｅｃｕｔｉｏｎコントラクトを介してＣｒｅａｔｏｒとしてトランザクションに署名した、Ｄｅｌｅｇａｔｅ（‘Ｃｒｅａｔｏｒ’、０ｘ５６７８）に対応する）。この実例における権利委譲は、下記の表入力データ構造として記録することができる。
ＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙ Ｅｎｔｒｙ：Ｒｉｇｈｔ＝‘Ｃｒｅａｔｏｒ’；Ｐａｒｅｎｔ＝０ｘ１２３４［Ｗ］；Ｄｅｌｅｇａｔｅ＝０ｘ５６７８［Ｗ］；Ｃｏｎｔｒａｃｔ＝０ｘａａｂｂｃｃｄｄ［ＳＣ］

この割当てを通して、Ｄｅｌｅｇａｔｅ Ｗａｌｌｅｔはここで、Ｅｘｅｃｕｔｉｎｇ Ｃｏｎｔｒａｃｔのコンテキストにおいて親の権利を有する。委譲はＲｏｏｔ Ｗａｌｌｅｔを、機能を実行する機能性ウォレットと分離する。委譲はＲｏｏｔ Ｗａｌｌｅｔを、そのデリゲートが代理でトランザクションに署名しているので、使用と関連付けられたサイバー・リスクから保護する。なお、両方のウォレットに不正アクセスする攻撃が、開示するモデルの影響を弱体化させる可能性があるので、委譲モデルの強度はデリゲートのウォレットの秘密キーの独立した償還に応じて決まる。

Ｄｅｌｅｇａｔｅ Ｗａｌｌｅｔが不正アクセスされた場合、Ｒｏｏｔ Ｗａｌｌｅｔは、Ｄｅｌｅｇａｔｅ Ｗａｌｌｅｔを置換することによって制御を回復することができる。また、Ｒｏｏｔ Ｗａｌｌｅｔは、詳細に後述するようにＤｅｌｅｇａｔｅ Ｗａｌｌｅｔを組み込むことによって、この権利を取り戻してもよい。Ｄｅｌｅｇａｔｅ Ｗａｌｌｅｔの権利を取り除くため、Ｒｉｇｈｔを有する当事者は、Ｅｘｅｃｕｔｉｎｇ ＣｏｎｔｒａｃｔからＩＤｅｌｅｇａｂｌｅＲｉｇｈｔ．Ｓｕｂｓｕｍｅ機能を呼び出す。例えば、以前の実例で割り当てられた権利を取り除くには、機能Ｓｕｂｓｕｍｅ（‘Ｃｒｅａｔｏｒ’、０ｘ５６７８）を実行して、この行が表から除去され、Ｅｘｅｃｕｔｉｎｇ ＣｏｎｔｒａｃｔのＣｒｅａｔｏｒの代理で０ｘ５６７８がこの権利を実行するのを防ぐ。

例えば、デリゲートの置換が頻繁に行われる場合、Ｒｏｏｔ Ｗａｌｌｅｔの不正アクセスを防ぐのに、複数層の委譲を適用することができる。Ｒｏｏｔ Ｗａｌｌｅｔの不正アクセスのあらゆるサイバー・リスクを軽減する１つの戦略では、Ｒｏｏｔ権利は、１回はスマート・コントラクトの作成に、２回目は、権利を実行する、及び／又は更に権利を委譲するのに使用されるウォレットにこの権利を委譲するのに、２回だけ利用される。不正アクセスの有意のリスクが委譲された権利に対して存在する場合、デリゲートの回復には、スーパーバイザ・ウォレット（即ち、委譲チェーンの上位にあるウォレット）によってトランザクションに署名することを伴うので、権利を２回目、３回目などに委譲することができる。サイバー・リスクがＲｏｏｔ Ｗａｌｌｅｔによって受けないことを保証するため、委譲は、Ｒｏｏｔ Ｗａｌｌｅｔ権利が回復に利用されず、それによってＲｏｏｔ Ｗａｌｌｅｔがサイバー・リスクから保護されることを保証するのに必要なのと同数の層を用いて行われるべきである。

図２は、層状の委譲のパターンを示している。２０２で、Ｒｏｏｔ Ｗａｌｌｅｔは権利を機能性ウォレットに委譲している。Ｒｏｏｔは後で機能性ウォレットをＲｅｐｌａｃｅするか又は委譲をＳｕｂｓｕｍｅ（取消し）してもよい。２０４で、委譲を２０２で受け入れているウォレットは更に権利を委譲し、それによって、機能的権利を行使するのに使用される別のウォレットに対する「スーパーバイザ」として作用する。２０６で、監視ウォレットは、ルートを保護する追加の層を作成する役割を委譲する。ウォレットは、チェーン／層において下位にある任意のウォレットを置換することができる。当然ながら、全てのアクションはＤｅｌｅｇａｔｅｓＲｅｇｉｓｔｒｙに記録される。

図３は、層状のウォレット管理に基づいた動作のシーケンスの実例を示している。図３の各行は権利委譲の状態を表す。１で、Ｒｏｏｔは、Ｓｙｓｔｅｍ属性に対するＣｒｅａｔｏｒ権利をＰａｒｅｎｔ Ｓｕｐｅｒｖｉｓｏｒｙ Ｗａｌｌｅｔ（「Ｗａｒｍ Ｒｏｏｔ」）に委譲し、それによって以下のＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙへのエントリが得られる。
Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝Ｒｏｏｔ［Ｗ］；Ｄｅｌｅｇａｔｅ＝ＷａｒｍＲｏｏｔ［Ｗ］；
Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

２で、Ｗａｒｍ Ｒｏｏｔは、Ｃｒｅａｔｏｒ権利をＤｅｌｅｇａｔｅｄ Ｓｕｐｅｒｖｉｓｏｒｙ Ｗａｌｌｅｔ（「ＨｏｔＲｏｏｔ」）に委譲し、それによって以下のＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙへのエントリが得られる。
Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝ＷａｒｍＲｏｏｔ［Ｗ］；Ｄｅｌｅｇａｔｅ＝ＨｏｔＲｏｏｔ［Ｗ］；
Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

３で、Ｒｏｏｔの置換動作が呼び出されて、ＷａｒｍＲｏｏｔを０ｔｈＲｏｏｔと置換し、それによって以下のＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙへのエントリが得られる。
Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝Ｒｏｏｔ［Ｗ］；Ｄｅｌｅｇａｔｅ＝０ｔｈＲｏｏｔ［Ｗ］；
Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
ＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙ Ａｕｔｏ－Ｕｐｄａｔｅ；Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝０ｔｈＲｏｏｔ［Ｗ］；
Ｄｅｌｅｇａｔｅ＝ＷａｒｍｅｒＲｏｏｔ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

４で、権利は親監視ウォレットによって組み込まれる。
ＤｅｌｅｇａｔｅＲｅｇｉｓｔｒｙ Ｒｅｍｏｖｅ：Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝Ｒｏｏｔ［Ｗ］；
Ｄｅｌｅｇａｔｅ＝０ｔｈＲｏｏｔ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
Ｄｅｌｅｇａｔｅ Ｒｅｇｉｓｔｒｙ Ａｕｔｏ－Ｕｐｄａｔｅ：Ｒｉｇｈｔ＝Ｃｒｅａｔｏｒ；Ｐａｒｅｎｔ＝Ｒｏｏｔ［Ｗ］；
Ｄｅｌｅｇａｔｅ＝ＷａｒｍｅｒＲｏｏｔ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

開示する実現例では、階層Ｗａｌｌｅｔ Ｍａｎａｇｅｍｅｎｔを使用して、ルート権利のサイバー・リスクが管理される。このメカニズムは、後述する方式でＣｏｎｆｅｄｅｒａｔｅｄ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔに活用され、多くの当事者の関心を表す複雑な権利を、喪失又は不正アクセスから保護された基本権利から構築することができる。

金融エコシステムは、独立した法人、エンティティの連合、及び個人の間の多くの対話に応じて決まる。多くの独立した行為者及び規制制度を含む世界規模の金融エコシステムでは、権限は中央で制御されず、また制御することができない。当事者は結束して、会社、グループ、又は他の共有企業となってもよい。これらの当事者は、通常は自発的に更にリンクして、中央権限を有さない緩やかな連合であるコンフェデレーションとなって、商取引を行ってもよい。信頼される情報交換をコンフェデレーションの形に拡大するため、参加者は、多くの場合、通信方法、共通のデータ形式、及び参加者に対する権利について同意することになる。

効率的な商取引には、エンティティが許可を定義及び管理し、規模を拡大してこれらの権利を組み合わせ、共有し、又は施行することを可能にするフレームワークを要する。世界規模の商取引において直面するエンティティのタイプ及び様々なトランザクションの範囲をサポートするように設計されたシステムは、柔軟、表現豊か、安全（承認されない権利の拡大がない）、可逆的、及び分散型でなければならない。分散権限はブロックチェーンの主要な利益であるが、世界規模の商取引に対する分散型の許可フレームワークをその上に組み立てることができるベースラインを提供する。

開示する実現例は、自己記述型であるデータ・モデルを有する、コンフェデレーテッド権限フレームワークを提供し、そこでは、属性として表現することができる権利、及び他^＊を定義する権利は自己記述型であり、キュレートされた形で権限の最初の行使から出現することができる。このフレームワークを使用して、権利をポリシーの作成まで拡張してもよく、即ち、権利を含むアクションを支配して権利及びポリシーを作成し管理する、複数の権利の表現まで拡張してもよい。そこから、コントラクト（コード又は他の合意）を、所望の権利及び証明によって展開し管理して、様々なトランザクションを必須のセキュリティ・レベルで可能にし自動化することができる。最後に、アクションを、権利フレームワーク下で作成され管理される、トークンなどの価値の単位にリンクさせることができる。トークンでのトランザクションは、分散フレームワーク内で作成される権利、ポリシー、及びコントラクトによって支配することができる。コンフェデレーテッド権限を可能にする自己記述型の許可フレームワークを確立する方法、及び単一の権限から始まる複雑なエコシステムのガバナンスについて、いかに記載する。

開示する実現例による権利のコンフェデレーテッド管理のためのデータ・モデルは、ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ、ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ、及びＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙの３つの表／データベースを含むことができる。Ｃｏｎｔｅｘｔは、１つ又は複数のＡｔｔｒｉｂｕｔｅに対する制御の範囲を定義する。デフォルト設定で、Ｃｏｎｔｅｘｔが作成されるとき、ＣｒｅａｔｏｒはＣｏｎｔｅｘｔを更新する全ての権利を保持し、Ｃｏｎｔｅｘｔ内で属性及び認証を作成し管理する。これらの権利は、後述するように、属性（ポリシー及び／又はコントラクト）から導き出される認証又は他の方法を使用して、他の当事者に割り当てられてもよい。ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙを実現するコードの実例は、添付するＣｏｄｅ Ａｐｐｅｎｄｉｘに見出すことができる。ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ記録の実例のデータ構造を以下に示す。

ここで、
Ｉｄは、コンテキストに対する一意の識別子、
Ｎａｍｅは、コンテキストに対する記述名、
ＣｒｅａｔｏｒＩｄは、コンテキストを作成したウォレットのアドレス又は他のＩＤ、
ＳｅｌｆＳｏｖｅｒｅｉｇｎは、Ｓｙｓｔｅｍ権利が無効にすることができないコンテキストを示し、
ＰａｒｅｎｔＩｄは、コンテキストが別のコンテキストから継承する場合に使用される。

ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙを実現する実例のコードは、添付のＣｏｄｅ Ａｐｐｅｎｄｉｘに見出すことができる。ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙにおける記録のための実例のデータ構造を以下に記述する。

ここで、
Ｉｄは、属性に対する一意の識別子、
Ｎａｍｅは、属性に対する記述名、
ＣｏｎｔｅｘｔＩｄは、属性がアクセスされ管理されるコンテキスト、
ＤａｔａＴｙｐｅは、ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙ又は他のソースにおけるＡｔｔｒｉｂｕｔｅに割り当てられた値のデータ・タイプ（ＤａｔａＴｙｐｅ値の列挙はＣｏｄｅ Ａｐｐｅｎｄｉｘに見出すことができる）、
ＰａｒｅｎｔＩｄは、属性間の継承を定義するのに使用され、
ＳｏｕｒｃｅＩｄは、Ａｔｔｒｉｂｕｔｅに関与するＡｔｔｅｓｔａｔｉｏｎに関してどこでデータを見出すことができるかを定義する（ソースは、外部、第三者のオラクル及び／若しくはスマート・コントラクト、又は他のデータ・ソースであってもよいが、本明細書に開示する全ての実例は、ソースが内部データ・ストアであり、Ｃｏｎｔｅｘｔによって制御される読取り及び書込み規則を有するＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙであると仮定している）。

開示する実現例にしたがってＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙを実現するための実例のコードは、Ｃｏｄｅ ＡｐｐｅｎｄｉｘのＰｒｏｐｅｒｔｙＭｅｔａｄａｔａ部分に見出すことができる。ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙにおける記録の実例のデータ構造を以下に記述する。

ここで、
Ｉｄは、認証に対する一意の識別子、
ＡｔｔｒｉｂｕｔｅＩｄは、認証の形式及び目的を定義する属性、Ｋｅｙは、値が割り当てられるアイテム（キーは、１つを超えるアイテムを値にリンクさせる複合キーであってもよい）、
Ｖａｌｕｅは、認証に割り当てられた値、
Ｃｒｅａｔｏｒは、認証値を設定する当事者を識別し、
Ｅｘｐｉｒａｔｉｏｎは、認証が期限切れになる時間を示す。

これらのデータ構造を使用して、更に詳細に後述するように、コンテキスト作成者が役割を表す属性を作成することが可能である。役割は、認証を介してウォレットに割り当てることができる。作成者は、属性（役割）を、コンテキスト、属性、及び認証を管理するのに使用される特定の機能に割り当て、それにより、管理構造を管理する管理構造を、つまり、グループが提携して権利を形成し管理することを可能にするのに使用することができる、自己記述型の自己管理システムを作成することができる。

自己記述型の権利フレームワークを確立するため、システムのキー要素を作成し操作するように委託されたＲｏｏｔ権限は、ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ、ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ、及びＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙを含むスマート・コントラクト・インフラストラクチャを展開して、フレームワークのインスタンスを作成する。スマート・コントラクトの分散型台帳に対する展開は、当業者には良く知られている標準的技法であり、したがって本明細書には詳細に記載しない。Ｒｏｏｔ権限は単に、基本権利のリセットを要する例外的なイベントがない限り、システム開始時に制定されることが予期される。Ｃｏｎｔｅｘｔが、真に設定されたＳｅｌｆＳｏｖｅｒｅｉｇｎ値を用いて作成された場合、Ｒｏｏｔ（又は割り当てられたＳｙｓｔｅｍ権利）はＣｏｎｔｅｘｔを修正する権利を有さなくなるので、Ｒｏｏｔは作成側のコンフェデレーションによって信用される必要はない。

スマート・コントラクトを展開した後、Ｒｏｏｔの第１の作用は、トランザクションに署名してＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙに‘Ｃｏｒｅ’コンテキストを作成することである。レジストリ内に指定された形式でデータを設定するトランザクション構造は、当業者には知られている標準的技法であり、したがって本明細書では詳細に記載しない。特定の関数シグネチャは変動してもよい。Ｒｏｏｔは次に、Ｃｏｒｅコンテキストに‘Ｓｙｓｔｅｍ’属性（役割）を作成するトランザクションに署名する。Ｒｏｏｔは次に、キー（０ｘ５６７８）を有する値（「真」）をシステム属性に割り当て、それによってキーに対応するアドレスを有するウォレットをＳｙｓｔｅｍの役割に割り当てる、Ａｔｔｅｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒｙに記録を作成するトランザクションに署名する。

この同じシーケンスを使用して、システム・アカウントは次に、キュレータとして作用するコア承認者を割り当てて、知られており資格があるエンティティのみがシステムのアクションを実施することを確保する。コンテキスト内の指定された権利を包含するウォレットのみがコンテキストを修正することができるので、システムは、権利の拡大、又はクロス・エンティティ承認（加盟していないエンティティが別のエンティティに対する権利を割り当てる）を防ぐように設計される。

図４－１及び図４－２は、コンフェデレーテッド権利管理システムを完全に実装するためのスマート・コントラクト・アーキテクチャを示している。アーキテクチャは、フレームワークを展開する当事者に割り当てられたルート権利と、ルート権利から導き出された権利を作成し管理するのに使用される一連のレジストリとから成る。ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙは、インフラストラクチャを支配するのに使用することができる権利を含む、任意の役割又は権利を作成及び管理することを可能にする。以下は、コンフェデレーテッド権利管理を可能にするインフラストラクチャを構成するためのプロセスを記載する。セットアップ・プロセスの各ステップに対して、Ａｔｔｒｉｂｕｔｅは、上述したようなレジストリ及びＣｏｄｅ Ａｐｐｅｎｄｉｘに記録される。最初に、１で、Ｒｏｏｔ、Ｗａｒｍ Ｒｏｏｔ、及びＳｙｓｔｅｍ機能を行使するのに使用されるウォレットが、別個のキー管理を有して存在する。２で、Ｒｏｏｔは、インフラストラクチャ・スマート・コントラクト（付属書のコード）を展開し、Ｃｒｅａｔｏｒとして記録される。３で、ＲｏｏｔはＷａｒｍ Ｒｏｏｔに委譲し、それによって、上述の委譲のフローに記載されているように、エコシステムのＣｒｅａｔｏｒ権利及び責任（Ｒｏｏｔによって取り除くことができる）を割り当てる。４で、Ｒｏｏｔは、Ｓｙｓｔｅｍ Ａｔｔｒｉｂｕｔｅを作成し、Ｓｙｓｔｅｍの役割を実施するウォレットに対する認証を割り当てる。このステップに対するＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ、ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ、及びＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙのデータ・エントリは、上記の表及び実例に示されている。５で、システムは、ＣｏｒｅＥｌｉｇｉｂｉｌｉｔｙ Ａｔｔｒｉｂｕｔｅ（ＴｏｋｅｎＲｏｌｅＥｌｉｇｉｂｌｅ、ＡｓｓｅＲｏｌｅＥｌｉｇｉｂｌｅなど）を作成する。このステップに対するデータ・エントリは、以前のステップで確立された同じパターンに従い、これ以上示さない。その後、６で、システムは、ＣｏｒｅＡｕｔｈｏｒｉｚｅｒ Ａｔｔｒｉｂｕｔｅを作成し、各ウォレットに対するＡｔｔｅｓｔａｔｉｏｎに役割を実施させる。７で、（通常は後で）Ａｕｔｈｏｒｉｚｅｒが、それぞれのＣｏｒｅＥｌｉｇｉｂｉｌｉｔｙ Ａｔｔｒｉｂｕｔｅ Ａｇｅｎｔ権利を、各属性に対して所望のウォレットに割り当てる。８で、Ｅｌｉｇｉｂｌｅ ＡｔｔｒｉｂｕｔｅＣｒｅａｔｏｒは、所望に応じて他のＲｏｌｅを支配してもよい、新しいＡｔｔｒｉｂｕｔｅを作成してもよい。９で、Ｅｌｉｇｉｂｌｅ Ｃｒｅａｔｏｒは、自己主権型のトークン、アセット、コントラクト、及びポリシーを作成してもよく、更にこれらのエンティティに対する権利を割り当ててもよい。

基本アクションの１つは、属性（権利）を作成する能力である。承認された権利作成者は、権利を作成し管理することができる。これにより、任意の承認されたエンティティが自身のエコシステムを作成し管理することが可能になる。このフレームワークは、エンティティ間での対話、及び加盟していないエンティティ間での集合的アクションを可能にする。セットアップ・シーケンスの一部として作成されるデータ構造を示すのに、略記法が使用される。

図５は、開示する実現例による、権利オブジェクト５００の実例を示している。Ｃｒｅａｔｏｒ（Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎ）は、ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙのエントリを通してＣｏｎｔｅｘｔを作成してもよい。デフォルト設定で、ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙは、ＣｒｅａｔｏｒがＡｔｔｒｉｂｕｔｅＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｒｅａｔｏｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならないというＰｏｌｉｃｙを有する。Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎを検証するため、以下の記録をＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録することができる。
Ａｔｔｒｉｂｕｔｅ＝ＡｔｔｒｉｂｕｔｅＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｒｅａｔｏｒ；
Ｓｏｕｒｃｅ＝ＡｔｔｒｉｂｕｔｅＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ［ＳＣ］

コンテキストＣｒｅａｔｏｒは、Ｃｏｎｔｅｘｔエントリを用いてＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙに記録される。この役割は、後述するようにＤｅｌｅｇａｔｅｄであることができる。属性作成時、Ｍａｎａｇｅｒの役割はＣｒｅａｔｏｒによって自己割当てされる。この実現例では、Ａｔｔｒｉｂｕｔｅに対して１つのみのマネージャが存在し得る。以下の記録はＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録される。
Ａｔｔｒｉｂｕｔｅ＝ＡｔｔｒｉｂｕｔｅＲｐｌｅ；Ｋｅｙ＝Ａｔｔｒｉｂｕｔｅ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ

Ｃｏｎｔｅｘｔ作成時、Ｍａｎａｇｅｒの役割は以下のデータ構造を通してＣｒｅａｔｏｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｅｘｔＲｏｌｅ；Ｋｅｙ＝Ｃｏｎｔｅｘｔ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ

Ｃｏｎｔｅｘｔ Ｍａｎａｇｅｒは、コンテキスト内で１つ又は複数のＡｔｔｒｉｂｕｔｅｓを作成してもよい。

属性された作成時、Ｏｐｅｒａｔｏｒの用語は、そのＣｒｅａｔｏｒであるＣｏｎｔｅｘｔ Ｍａｎａｇｅｒによって自己割当てされ、以下の記録はＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録される。
Ａｔｔｒｉｂｕｔｅ＝Ａｔｔｒｉｂｕｔｅ；Ｋｅｙ＝Ｃｏｎｔｅｘｔ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ

ＣｏｎｔｅｘｔＲｅｇｉｓｔｒｙ Ｃｒｅａｔｏｒは、以下の規則を施行するＰｏｌｉｃｙを割り当ててもよい。
・Ｃｏｎｔｅｘｔに対して１つのみのＭａｎａｇｅｒがあり得る。Ｍａｎａｇｅｒの役割がＣｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）によって設定されている場合、Ｃｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）はＭａｎａｇｅｒを再割当てしてもよい。
・Ｃｏｎｔｅｘｔが自己主権型でない場合（これがデフォルトであり得る）、ＭａｎａｇｅｒはＳｙｓｔｅｍによって設定されてもよい。Ｍａｎａｇｅｒは、ＡｔｔｒｉｂｕｔｅＲｏｌｅｓ（Ｏｐｅｒａｔｏｒ、Ａｇｅｎｔ）を追加又は除去してもよい。

Ｍａｎａｇｅｒは、以下の記録をＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録することによって、Ａｔｔｒｉｂｕｔｅ（０～多）に対するＯｐｅｒａｔｏｒを追加又は除去してもよい。
Ａｔｔｒｉｂｕｔｅ＝ＡｔｔｒｉｂｕｔｅＲｏｌｅ；Ｋｅｙ＝Ａｔｔｒｉｂｕｔｅ［ＩＤ］、Ｏｐｅｒａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ

Ｍａｎａｇｅｒは、以下の記録をＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録することによって、Ａｔｔｒｉｂｕｔｅ（０～多）に対するＡｇｅｎｔを追加又は除去してもよい。
Ａｔｔｒｉｂｕｔｅ＝ＡｔｔｒｉｂｕｔｅＲｏｌｅ；Ｋｅｙ＝Ａｔｔｒｉｂｕｔｅ［ＩＤ］、Ａｇｅｎｔ［Ｗ］；Ｖａｌｕｅ＝Ａｇｅｎｔ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ

（Ａｔｔｅｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒｙの設定時に割り当てられた）デフォルト設定で、ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙは、Ａｔｔｒｉｂｕｔｅ Ｏｐｅｒａｔｏｒｓが属性に対する任意の認証を追加、更新、又は除去してもよいというＰｏｌｉｃｙを有する。Ａｔｔｒｉｂｕｔｅ Ａｇｅｎｔｓは、属性がＳｏｕｒｃｅである場合に属性を更新又は除去のみしてもよい。Ａｇｅｎｔｓ又はＯｐｅｒａｔｏｒｓは、Ａｔｔｒｉｂｕｔｅに対してＳｅｔ Ａｔｔｅｓｔａｔｉｏｎｓ（ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙにおける値）を行うことができる。一部の属性は、ＡｔｔｅｓｔａｔｉｏｎＲｅｇｉｓｔｒｙと呼ばれる値に対する内部ストアを使用する。他のＡｔｔｒｉｂｕｔｅｓは様々なソースからの外部データを指す。特別なタイプの属性は、自己認証を許可するもの、つまり、例えば以下に対して設定されるものとして指定される、関与する当事者によって値を設定することができる属性である。
^＊［Ｗ］＝Ｗａｌｌｅｔアドレス、［ＳＣ］＝Ｓｍａｒｔ Ｃｏｎｔｒａｃｔアドレス、［ＩＤ］＝Ａｔｔｒｉｂｕｔｅ Ｉｄｅｎｔｉｆｉｅｒ

同様の方式で、他のアクションは、参加者及び金融トランザクションの他の任意の態様を符号化するのに使用することができる、システムにおける基本オブジェクト（ポリシー、コントラクト、エンティティ、及び価値の単位）を作成する。ポリシーは規則の組み合わせであり、規則は、他のデータに対して１つ又は複数の属性を評価するステートメントであり、規則はスマート・コントラクト・トランザクションを支配するのに使用される。規則の構造及び機能は、２０１８年９月２６日付の米国特許出願第１６／１４３，０５８号に記載されており、その開示を参照により本明細書に組み込む。ポリシーは、属性から導き出され、属性を組み立てて、コンテキスト、属性、及び認証の作成及び管理に適用できる規則にするのに使用することができる。これは、開示するデータ構造を使用してそれ自体を支配することができる、更に別の手法であり、コンフェデレーションを配置するのに使用される任意の管理構造を作成することを可能にする。

図６は、Ｃｒｅａｔｏｒ（Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎ）によって作成されるポリシー・オブジェクト６００を示している。デフォルト設定で（例えば、セットアップ時に割り当てられる）、ＰｏｌｉｃｙＲｅｇｉｓｔｒｙは、Ｃｒｅａｔｏｒが、例えば以下の方式で表現される、ＰｏｌｉｃｙＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｒｅａｔｏｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならないというＰｏｌｉｃｙを有する。
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｒｅａｔｏｒ；
Ｓｏｕｒｃｅ＝ＰｏｌｉｃｙＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

Ｃｒｅａｔｏｒは、Ｐｏｌｉｃｙエントリを用いてＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙに記録される。この役割はＤｅｌｅｇａｔｅすることができる。Ｐｏｌｉｃｙオブジェクトの作成時、Ｍａｎａｇｅｒの役割は、以下の記録を通してＣｒｅａｔｏｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅ；Ｋｅｙ＝Ｐｏｌｉｃｙ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＰｏｌｉｃｙＲｅｇｉｓｔｒｙ［ＳＣ］

ＰｏｌｉｃｙＲｅｇｉｓｔｒｙは、以下の規則を施行するＰｏｌｉｃｙ（作成時又は作成後に割り当てられる）を有することができる。
・Ｐｏｌｉｃｙに対して１つのみのＭａｎａｇｅｒがあり得る。
・Ｍａｎａｇｅｒの役割がＣｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）によって設定されている場合、Ｃｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）はＭａｎａｇｅｒを再割当てしてもよい。
・Ｐｏｌｉｃｙが自己主権型でない場合（これがデフォルトである）、ＭａｎａｇｅｒはＳｙｓｔｅｍによって設定されてもよい。並びに、
・Ｍａｎａｇｅｒは、ＰｏｌｉｃｙＲｏｌｅｓ（Ｏｐｅｒａｔｏｒ、Ｃｅｒｔｉｆｉｅｒ）を追加又は除去してもよい。

Ｐｏｌｉｃｙオブジェクトの作成時、Ｏｐｅｒａｔｏｒ及びＣｅｒｔｉｆｉｅｒの役割は、以下の記録を通してＣｒｅａｔｏｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅ；Ｋｅｙ＝Ｐｏｌｉｃｙ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＰｏｌｉｃｙＲｅｇｉｓｔｒｙ［ＳＣ］；
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅ；Ｋｅｙ＝Ｐｏｌｉｃｙ［ＩＤ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＰｏｌｉｃｙＲｅｇｉｓｔｒｙ［ＳＣ］；

Ｍａｎａｇｅｒは、３で、以下を記録することによって、１つ又は複数の当事者をＯｐｅｒａｔｏｒとして割り当ててもよい。
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅ；Ｋｅｙ＝Ｐｏｌｉｃｙ［ＩＤ］、Ｏｐｅｒａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＰｏｌｉｃｙＲｅｇｉｓｔｒｙ［ＳＣ］；
Ｐｏｌｉｃｙに対して１つのみのＣｅｒｔｉｆｉｅｒがあってもよい。ＣｅｒｔｉｆｉｅｒがＣｒｅａｔｏｒ以外の任意の当事者である場合、ＣｅｒｔｉｆｉｅｒはＰｏｌｉｃｙＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｅｒｔｉｆｉｅｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならない。Ｃｅｒｔｉｆｉｅｒは、役割が適用される前に割当てを認識しなければならない。以下のデータ構造はこれを指定する。
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝ＰｏｌｉｃｙＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
Ａｔｔｒｉｂｕｔｅ＝ＰｏｌｉｃｙＲｏｌｅ；Ｋｅｙ＝Ｐｏｌｉｃｙ［ＩＤ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＰｏｌｉｃｙＲｅｇｉｓｔｒｙ［ＳＣ］；
^＊［Ｗ］＝Ｗａｌｌｅｔアドレス、［ＳＣ］＝Ｓｍａｒｔ Ｃｏｎｔｒａｃｔアドレス、［ＩＤ］＝Ｒｅｇｉｓｔｒｙ識別子

上述したように、スマート・コントラクトは分散型台帳でロジックを実行するのに使用される。新しいスマート・コントラクトは、本明細書に開示する権利管理システムを含む、構成されたシステムの挙動を変更するように展開させることができる。権利管理システムは、後述するように、権利管理システムに対してアップグレードを遂行する許可を支配するのに使用することができる。

図７に示されるように、Ｄｅｖｅｌｏｐｅｒ（Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎ）は、ＳｍａｒｔＣｏｎｔｒａｃｔオブジェクト７００を作成してもよい。デフォルト設定で（セットアップ時に割り当てられる）、ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙは、Ｄｅｖｅｌｏｐｅｒが、以下のデータ構造によって指定される、ＣｏｎｔｒａｃｔＲｏｌｅＥｌｉｇｉｂｌｅ Ｄｅｖｅｌｏｐｅｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならないというＰｏｌｉｃｙを有する。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｄｅｖｅｌｏｐｅｒ；
Ｓｏｕｒｃｅ＝ＣｏｎｔｒａｃｔＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

Ｄｅｖｅｌｏｐｅｒは、Ｃｏｎｔｒａｃｔエントリを用いてＲｅｇｉｓｔｒｙに記録される。この役割はＤｅｌｅｇａｔｅすることができる。Ｃｏｎｔｒａｃｔオブジェクトの作成時、Ｍａｎａｇｅｒの役割は、以下のデータ構造を通してＤｅｖｅｌｏｐｅｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙ［ＳＣ］

ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙは、以下の規則を施行するＰｏｌｉｃｙ（作成時又は作成後に割り当てられる）を有することができる。
・Ｃｏｎｔｒａｃｔに対して１つのみのＭａｎａｇｅｒがあり得る。
・Ｍａｎａｇｅｒの役割がＤｅｖｅｌｏｐｅｒ（又はＤｅｌｅｇａｔｅｓ）によって設定されている場合、Ｄｅｖｅｌｏｐｅｒ（又はＤｅｌｅｇａｔｅｓ）はＭａｎａｇｅｒを再割当てしてもよい。並びに、
・Ｃｏｎｔｒａｃｔが自己主権型でない場合（これがデフォルトである）、ＭａｎａｇｅｒはＳｙｓｔｅｍによって設定されてもよい。Ｍａｎａｇｅｒは、ＣｏｎｔｒａｃｔＲｏｌｅｓ（Ｏｐｅｒａｔｏｒ、Ｃｅｒｔｉｆｉｅｒ）を追加又は除去してもよい。

Ｃｏｎｔｒａｃｔオブジェクトの作成時、Ｏｐｅｒａｔｏｒ及びＣｅｒｔｉｆｉｅｒの役割は、以下のデータ構造を通してＤｅｖｅｌｏｐｅｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅ；Ｋｅｙ＝ＣｏｎｔｒａｃｔＩＤ［ＳＣ］、Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙ［ＳＣ］
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅ；Ｋｅｙ＝ＣｏｎｔｒａｃｔＩＤ［ＳＣ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝Ｄｅｖｅｌｏｐｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙ［ＳＣ］；

Ｍａｎａｇｅｒは、以下のデータ構造を通して、１つ又は複数の当事者をＯｐｅｒａｔｏｒとして割り当ててもよい。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅ；Ｋｅｙ＝ＣｏｎｔｒａｃｔＩＤ［ＳＣ］、Ｏｐｅｒａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙ［ＳＣ］；

所望の場合、作成者は、Ｃｏｎｔｒａｃｔに対して１つのみのＣｅｒｔｉｆｉｅｒであるように、属性管理システムを制限するポリシーを展開してもよい。ＣｅｒｔｉｆｉｅｒがＤｅｖｅｌｏｐｅｒ以外の任意の当事者である場合、ＣｅｒｔｉｆｉｅｒはＣｏｎｔｒａｃｔＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｅｒｔｉｆｉｅｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならない。Ｃｅｒｔｉｆｉｅｒは、役割が適用される前に割当てを認識しなければならない。
Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝ＣｏｎｔｒａｃｔＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
Ａｔｔｅｓｔａｔｉｏｎ＝＞Ａｔｔｒｉｂｕｔｅ＝ＣｏｎｔｒａｃｔＲｏｌｅ；Ｋｅｙ＝ＣｏｎｔｒａｃｔＩＤ［ＳＣ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；
Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＣｏｎｔｒａｃｔＲｅｇｉｓｔｒｙ［ＳＣ］；
＊［Ｗ］＝Ｗａｌｌｅｔアドレス、［ＳＣ］＝Ｓｍａｒｔ Ｃｏｎｔｒａｃｔアドレス
Ｔｏｋｅｎ Ｒｅｇｉｓｔｒｙ

図８に示されるように、Ｉｓｓｕｅｒ（Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎ）は、トークンにおける所有権及び／又は権利を定義するＳｍａｒｔ Ｃｏｎｔｒａｃｔ８００を通してＴｏｋｅｎを作成してもよい。デフォルト設定で（セットアップ時に割り当てられる）、Ｔｏｋｅｎ Ｒｅｇｉｓｔｒｙは、Ｉｓｓｕｅｒが、以下のデータ構造によって指定される、ＴｏｋｅｎＲｏｌｅＥｌｉｇｉｂｌｅ Ｉｓｓｕｅｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならないというＰｏｌｉｃｙを有する。
Ｖａｌｉｄａｔｅ Ａｔｔｅｓｔａｔｉｏｎ＝＞Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｉｓｓｕｅｒ［Ｗ］；
Ｖａｌｕｅ＝Ｉｓｓｕｅｒ；Ｓｏｕｒｃｅ＝ＴｏｋｅｎＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

Ｉｓｓｕｅｒは、Ｔｏｋｅｎエントリを用いてＲｅｇｉｓｔｒｙに記録される。この役割はＤｅｌｅｇａｔｅすることができる。Ｔｏｋｅｎ作成時、Ｍａｎａｇｅｒの役割は以下のデータ構造を通してＩｓｓｕｅｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ｉｓｓｕｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｉｓｓｕｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＴｏｋｅｎＲｅｇｉｓｔｒｙ［ＳＣ］

ＴｏｋｅｎＲｅｇｉｓｔｒｙは、以下の規則を施行するＰｏｌｉｃｙ（作成時に割り当てられる）を有する。
・Ｔｏｋｅｎに対して１つのみのＭａｎａｇｅｒがあり得る。
・Ｍａｎａｇｅｒの役割がＩｓｓｕｅｒによって設定されている場合、ＩｓｓｕｅｒはＭａｎａｇｅｒを再割当てしてもよい。Ｔｏｋｅｎが自己主権型でない場合（これがデフォルトである）、ＭａｎａｇｅｒはＳｙｓｔｅｍによって設定されてもよい。
・自己主権型Ｔｏｋｅｎの場合、Ｍａｎａｇｅｒは、トークン保持者からの選挙（別個に記載されるＥｌｅｃｔｉｏｎ）によって設定されてもよい。並びに、
・Ｍａｎａｇｅｒは、ＴｏｋｅｎＲｏｌｅｓ（Ｏｐｅｒａｔｏｒ、ＴｒａｎｓｆｅｒＡｇｅｎｔ）を追加又は除去してもよい。

Ｔｏｋｅｎ作成時、Ｏｐｅｒａｔｏｒ及びＡｇｅｎｔの役割は、以下のデータ構造を通してＩｓｓｕｅｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ｉｓｓｕｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｉｓｓｕｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＴｏｋｅｎＲｅｇｉｓｔｒｙ［ＳＣ］；
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ｉｓｓｕｅｒ［Ｗ］；Ｖａｌｕｅ＝Ａｇｅｎｔ；
Ｓｏｕｒｃｅ＝Ｉｓｓｕｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＴｏｋｅｎＲｅｇｉｓｔｒｙ［ＳＣ］；

Ｍａｎａｇｅｒは、以下のデータ構造を通して、１つ又は複数の当事者をＯｐｅｒａｔｏｒとして割り当ててもよい。
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ｏｐｅｒａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＴｏｋｅｎＲｅｇｉｓｔｒｙ［ＳＣ］；

この実現例では、Ｔｏｋｅｎに対して１つのみのＴｒａｎｓｆｅｒＡｇｅｎｔが存在してもよい。ＡｇｅｎｔがＩｓｓｕｅｒ以外の任意の当事者である場合、ＡｇｅｎｔはＴｏｋｅｎＲｏｌｅＥｌｉｇｉｂｌｅ Ａｇｅｎｔ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならない。Ａｇｅｎｔは、以下のデータ構造を通して役割が適用される前に、割当てを認識しなければならない。
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ａｇｅｎｔ［Ｗ］；Ｖａｌｕｅ＝Ａｇｅｎｔ；
Ｓｏｕｒｃｅ＝ＴｏｋｅｎＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
Ａｔｔｒｉｂｕｔｅ＝ＴｏｋｅｎＲｏｌｅ；Ｋｅｙ＝ＴｏｋｅｎＩＤ［ＳＣ］、Ａｇｅｎｔ［Ｗ］；Ｖａｌｕｅ＝Ａｇｅｎｔ；Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＴｏｋｅｎＲｅｇｉｓｔｒｙ［ＳＣ］；
^＊［Ｗ］＝Ｗａｌｌｅｔアドレス、［ＳＣ］＝Ｓｍａｒｔ Ｃｏｎｔｒａｃｔアドレス

図９に示されるように、アセットＣｒｅａｔｏｒ（Ｃｏｒｅ Ａｔｔｒｉｂｕｔｅ Ａｔｔｅｓｔａｔｉｏｎ）は、Ａｓｓｅｔオブジェクト９００を作成してもよい。デフォルト設定で（セットアップ時又はセットアップ後に割り当てられる）、ＡｓｓｅｔＲｅｇｉｓｔｒｙは、Ｃｒｅａｔｏｒが、以下に表現されるようなＡｓｓｅｔＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｒｅａｔｏｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならないというＰｏｌｉｃｙを有する。
Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｒｅａｔｏｒ；
Ｓｏｕｒｃｅ＝ＡｓｓｅｔＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］

Ｃｒｅａｔｏｒは、Ａｓｓｅｔエントリを用いてＡｓｓｅｔＲｅｇｉｓｔｒｙに記録される。この役割はＤｅｌｅｇａｔｅすることができる。Ａｓｓｅｔ作成時、Ｍａｎａｇｅｒの役割は、以下のデータ構造を通してＣｒｅａｔｏｒによって自己割当てされる。
Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅ；Ｋｅｙ＝Ａｓｓｅｔ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｍａｎａｇｅｒ；
Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｓｓｅｔＲｅｇｉｓｔｒｙ［ＳＣ］

ＡｓｓｅｔＲｅｇｉｓｔｒｙは、以下の規則を施行するＰｏｌｉｃｙ（作成時又は作成後に割り当てられる）を有する。
・Ａｓｓｅｔに対して１つのみのＭａｎａｇｅｒがあり得る。
・Ｍａｎａｇｅｒの役割がＣｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）によって設定されている場合、Ｃｒｅａｔｏｒ（又はＤｅｌｅｇａｔｅｓ）はＭａｎａｇｅｒを再割当てしてもよい。並びに、
・Ａｓｓｅｔが自己主権型でない場合（これがデフォルトである）、ＭａｎａｇｅｒはＳｙｓｔｅｍによって設定されてもよい。Ｍａｎａｇｅｒは、ＡｓｓｅｔＲｏｌｅｓ（Ｏｐｅｒａｔｏｒ、Ｃｅｒｔｉｆｉｅｒ）を追加又は除去してもよい。

Ａｓｓｅｔの作成時、Ｏｐｅｒａｔｏｒ及びＣｅｒｔｉｆｉｅｒの役割は、以下のようにＣｒｅａｔｏｒによって自己割当てされる。
Ａｔｔｅｓｔａｔｉｏｎ＝＞Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅ；Ｋｅｙ＝Ａｓｓｅｔ［ＩＤ］、Ｃｒｅａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ； Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｓｓｅｔＲｅｇｉｓｔｒｙ［ＳＣ］；
Ａｔｔｅｓｔａｔｉｏｎ＝＞Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅ；Ｋｅｙ＝Ａｓｓｅｔ［ＩＤ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ； Ｓｏｕｒｃｅ＝Ｃｒｅａｔｏｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｓｓｅｔＲｅｇｉｓｔｒｙ［ＳＣ］；

Ｍａｎａｇｅｒは、以下のデータ構造を通して、１つ又は複数の当事者をＯｐｅｒａｔｏとして割り当ててもよい。
Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅ；Ｋｅｙ＝Ａｓｓｅｔ［ＩＤ］、Ｏｐｅｒａｔｏｒ［Ｗ］；Ｖａｌｕｅ＝Ｏｐｅｒａｔｏｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｓｓｅｔＲｅｇｉｓｔｒｙ［ＳＣ］；

所望の場合、Ｃｒｅａｔｏｒは、Ｃｏｎｔｒａｃｔに対して１つのみのＣｅｒｔｉｆｉｅｒであってもよいように、属性管理システムを制限するポリシーを展開してもよい。ＣｅｒｔｉｆｉｅｒがＤｅｖｅｌｏｐｅｒ以外の任意の当事者である場合、ＣｅｒｔｉｆｉｅｒはＣｏｎｔｒａｃｔＲｏｌｅＥｌｉｇｉｂｌｅ Ｃｅｒｔｉｆｉｅｒ Ａｔｔｅｓｔａｔｉｏｎ（役割）を有さなければならない。Ｃｅｒｔｉｆｉｅｒは、役割が適用される前に割当てを認識しなければならない。
Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅＥｌｉｇｉｂｌｅ；Ｋｅｙ＝Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝ＡｓｓｅｔＲｏｌｅＡｕｔｈｏｒｉｚｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｔｔｒｉｂｕｔｅＲｅｇｉｓｔｒｙ［ＳＣ］
Ａｔｔｒｉｂｕｔｅ＝ＡｓｓｅｔＲｏｌｅ；Ｋｅｙ＝Ａｓｓｅｔ［ＩＤ］、Ｃｅｒｔｉｆｉｅｒ［Ｗ］；Ｖａｌｕｅ＝Ｃｅｒｔｉｆｉｅｒ；
Ｓｏｕｒｃｅ＝Ｍａｎａｇｅｒ［Ｗ］；Ｃｏｎｔｒａｃｔ＝ＡｓｓｅｔＲｅｇｉｓｔｒｙ［ＳＣ］；
^＊［Ｗ］＝Ｗａｌｌｅｔアドレス、［ＳＣ］＝Ｓｍａｒｔ Ｃｏｎｔｒａｃｔアドレス、［ＩＤ］＝Ｒｅｇｉｓｔｒｙ識別子

開示する実現例のフレームワークは、分散（自己形成）ポリシーが、特定のトークンに対する転送エージェント権利の決定を調整することを許可して、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ権利を与えられた当事者が、資格があって（法的権利を有し、責任を十分に認識している）信用性があることをステークホルダに対して確認する。属性をエコシステム・ステークホルダによって作成し管理して、Ｔｏｋｅｎ Ｉｓｓｕｅｒ又はＴｒａｎｓｆｅｒ Ａｇｅｎｔなど、主要機能を実施する当事者を証明するコア承認者を割り当てることができる。特定のトークンに対するステークホルダは、Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ権利を、この役割を保持することが証明されている当事者に割当て又は再割当てすることができる。

しかしながら、オープンエンドのフレームワークの力は、自身の権利、及び自身が所有する価値に影響を及ぼす当事者の権利を理解しようとする、平均的な参加者にとって圧倒的である場合がある。権利が透明及びアクセス可能でない場合、ユーザは不用意にトランザクションに参加することがあり、そこでユーザの権利が予期又は理解しなかった形で影響される。フレームワークは、Ｓｔｒａｔｅｇｉｅｓ、例えば、共通の投資パターンを提供するパッケージにまとめられた権利を含む。これは、参加者が好み、快適に感じる権利パッケージを見出す単純なモデルを参加者に提供する。例えば、権利パッケージは、自己主権型である、管理されるなどであることができる。

所与のコンピューティング・デバイスは、コンピュータ・プログラム・モジュールを実行するように構成された、１つ又は複数のプロセッサを含んでもよい。コンピュータ・プログラム・モジュールは、所与のコンピューティング・プラットフォームと関連付けられた専門家又はユーザが、システム及び／又は外部リソースとインターフェース接続できるように構成されてもよい。非現定例として、所与のコンピューティング・プラットフォームは、サーバ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、可搬型コンピュータ、タブレット・コンピューティング・プラットフォーム、スマートフォン、ゲーミング・コンソール、及び／又は他のコンピューティング・プラットフォームのうち１つ若しくは複数を含んでもよい。

様々なデータ及びコードを、情報を電子的に格納する非一時的記憶媒体を備えてもよい、電子記憶デバイスに格納することができる。電子記憶装置の電子記憶媒体は、コンピューティング・デバイスと一体的に（即ち、実質的に取外し不能で）提供されるシステム・ストレージ、並びに／或いは例えば、ポート（例えば、ＵＳＢポート、ファイヤワイヤ・ポートなど）若しくはドライブ（例えば、ディスク・ドライブなど）を介して、コンピューティング・デバイスに取外し可能に接続可能である、リムーバブル・ストレージを含んでもよい。電子記憶装置は、光学読取り可能記憶媒体（例えば、光学ディスクなど）、磁気読取り可能な記憶媒体（例えば、磁気テープ、磁気ハード・ドライブ、フロッピー・ドライブなど）、電荷ベースの記憶媒体（例えば、ＥＥＰＲＯＭ、ＲＡＭなど）、固体記憶媒体（例えば、フラッシュ・ドライブなど）、並びに／或いは他の電子的に読取り可能な記憶媒体のうち１つ若しくは複数を含んでもよい。

コンピューティング・デバイスのプロセッサは、情報処理能力を提供するように構成されてもよく、デジタル・プロセッサ、アナログ・プロセッサ、情報を処理するように設計されたデジタル回路、情報を処理するように設計されたアナログ回路、状態機械、及び／又は情報を電子的に処理するための他のメカニズムのうち１つ若しくは複数を含んでもよい。本明細書で使用するとき、「モジュール」という用語は、モジュールに属する機能性を実施する任意の構成要素又は構成要素のセットを指してもよい。これは、プロセッサ可読命令を実行する間の１つ若しくは複数の物理的プロセッサ、プロセッサ可読命令、回路、ハードウェア、記憶媒体、又は他の任意の構成要素を含んでもよい。

最も実用的で好ましい実現例であると現在みなされているものに基づいて、例示の目的で本発明の技術について詳細に記載してきたが、かかる詳細はその目的のみに対するものであり、技術は開示する実現例に限定されず、それとは対照的に、添付の特許請求の範囲の趣旨及び範囲内にある修正及び等価の構成を網羅することが意図されることが理解されるべきである。例えば、本発明の技術は、可能な範囲において、任意の実現例の１つ又は複数の特徴を他のいずれかの実現例の１つ又は複数の特徴と組み合わせることが可能であるものと想到されることが理解されるべきである。

実現例及び実例について例示し記載してきたが、本発明は、本明細書に開示する正確な構成及び構成要素に限定されないことが理解されるべきである。添付の特許請求の範囲で定義される本発明の趣旨及び範囲から逸脱することなく、本明細書に開示する方法及び装置の構成、動作、及び詳細に対して、様々な修正、変更、及び変形がなされてもよい。

コードアペンディクス

Claims (9)

1. 分散型台帳プラットフォームを含む分散型コンピューティング・ネットワークにおける状態変化として表される、データ・トランザクションの安全な承認のための方法であって、
   前記分散型コンピューティング・ネットワークで実行するスマート・コントラクト・コードで表現されるルート権利であって、指定された機能の実行を許可することによって不変の権利を作成するルート権利を作成することと、
   前記指定された機能の少なくとも１つを許可する権利を、前記分散ネットワーク上で前記ルート権利からウォレットに委譲して、前記ウォレットが前記機能の前記少なくとも１つに対応するトランザクションに署名する権利を有することを可能にする、委譲された権利を作成することであって、前記委譲された権利を前記ルート権利によって取消し又は再割当てすることができることと、
   権利を委譲することを表すデータ構造を委譲レジストリに記録することと、
   前記ウォレットとのトランザクションに署名することによって前記ウォレット権利を行使することにより、前記分散型コンピューティング・ネットワークにおける前記トランザクションを承認することとを含む、方法。
2. 前記スマート・コントラクト・コードが、前記ルート権利に割り当てられた割当てウォレットに対する署名権限を有する当事者に、委譲された権利を前記ウォレットに委譲する前記許可を提供し、^＊前記記録することが、前記委譲に応答して達成され、前記委譲された権利が適用される前記スマート・コントラクト、名前付きの前記権利、割り当てる前記ウォレット、及び前記権利が委譲された前記ウォレットを参照して前記委譲レジストリに記録をもたらす、請求項１に記載の方法。
3. スマート・コントラクト・インターフェース規格が、スマート・コントラクトと委譲レジストリとの間の通信に使用される、請求項２に記載の方法。
4. 委譲された権利を有する前記ウォレットが不正アクセスされた場合に前記委譲レジストリの対応する記録を変更することによって、ルート・ウォレットが、対応する記録を委譲レジストリから取り除くことによって、又は前記権利を別のウォレットに委譲することにより委譲を置換することによって、委譲された権利を取り消すことができる、請求項３に記載の方法。
5. 前記委譲された権利を別のウォレットに委譲することによって、ルート・ウォレットを、署名トランザクションと関連付けられたサイバー・リスクから更に隔離することを更に含む、請求項３に記載の方法。
6. 権利管理データ構造モデルが適用されることにより、権利を作成、管理、及び施行する前記権利を含む権利から権利を形成することができ、前記権利管理データ構造モデルが、権利管理構造を可能にするスマート・コントラクトを展開することによって、状態変化を承認する前記権利を表現し、前記権利管理データ構造モデルが前記ルート権利を所持する当事者によって定義される、請求項５に記載の方法。
7. 前記権利管理データ構造モデルが、前記権利によって管理される属性管理レジストリを含み、各属性が、名前、記憶場所及びデータ・タイプ、並びにどの当事者がデータを作成、読取り、更新、又は消去することができるかに関する権利を含むデータ構造であり、認証レジストリが、承認された当事者によって割り当てられるオブジェクトと関連付けられた認証属性値を格納し、前記認証属性値が、ウォレットに割り当てられる権利を獲得するのに使用することができる役割を表し、それによって、他の権利を支配するのに使用することができる権利の作成及び管理を容易にする、請求項６に記載の方法。
8. ポリシー管理データ構造が、提案される状態変化において関与するオブジェクトの属性を使用して、トランザクションに影響を及ぼす署名者の権利を決定する、ロジックから成る１つ又は複数の規則を評価する符号化された命令のセットを含む、請求項７に記載の方法。
9. 全ての権利が前記ルート権利から直接又は間接的に導き出されることにより、前記ルート権利までたどって戻ることができる権限のチェーンが提供される、請求項２に記載の方法。

Images