JP2020535543A - コンプライアンス対応のトークン化及び資産価値の制御のための方法、装置、及びコンピュータ可読媒体 - Google Patents

Abstract

特にトークン化された証券の売買及び移転のための非中央集権型金融トランザクションのスケーラブルなコンプライアンス及び発行者のガバナンスを容易にするための装置、コンピュータ可読媒体、及びコンピュータ実施方法。結果として得られるＣｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎは、トランザクションを制限し、規制上の報告及び監督を容易にするためのルールセットを含む。具現化されたプロセスは、コンプライアンス・ワークフロー、属性検証ツール、スマート・コントラクト、及び他の台帳制御の新規な組合せを含み、非中央集権型の属性ベース・アクセス制御ＡＢＡＣ機能を提供する。ＡＢＡＣパターンは、能動的な仲介者を必要とせずにグローバルな金融トランザクションを統制するように拡張される。

Description

本出願は、その開示全体が参照により本明細書に組み込まれる、２０１７年９月２７日に出願された米国仮出願第６２／５６３，６８４号及び２０１８年９月１７日に出願された米国仮出願第６２／７３２，１８９号の優先権を主張する。

デジタル通貨（「デジタル・マネー」、「電子マネー」、又は「電子通貨」と呼ばれることもある）は、（紙幣及び硬貨などの物理通貨とは異なり）デジタル形式で利用可能な通貨の種類である。デジタル通貨は、マネー・サプライに対する制御の中心点が存在する中央集権型、又はマネー・サプライに対する制御が様々なソースからもたらされ得る非中央集権型のいずれかである場合がある。例えば、暗号通貨は、暗号法を用いて金融トランザクションを保護し、追加の口数の作成を制御し、資産の移転を検証する交換媒体として機能するように設計されたデジタル資産である。

暗号通貨は、中心的な銀行システム又は他の信頼できる中央集権者を必要とせずに非中央集権型の制御を使用することができる。非中央集権型の制御は、共有の金融トランザクション・データベースとして機能するブロックチェーンなどの分散型台帳技術（ＤＬＴ：ｄｉｓｔｒｉｂｕｔｅｄ ｌｅｄｇｅｒ ｔｅｃｈｎｏｌｏｇｙ）を通じて実現され得る。ブロックチェーンにおいて、トランザクションは、線形チェーンに格納されたデータの「ブロック」として記録され得る。チェーン内の各ブロックは、トランザクション・データを含み、暗号的にハッシュされる。ブロックは、チェーン内の以前のブロックのハッシュを含み得る。これにより、チェーン内のそれに続くすべてのブロックも変更する必要があるので、１つのブロック内のデータを変更することが計算上困難になり、事実上不可能になる。これは、ブロックチェーン全体のすべてのデータが改ざんされておらず、変更されていないことを保証する。

トランザクションを認証し、ブロックを記録するために、コンセンサス・メカニズムが使用される。当事者は、一意のアドレスを有し、暗号通貨を受け取るため又は消費するために使用され得る公開鍵及び秘密鍵を格納する「ウォレット」を介してトランザクションを行う。暗号通貨自体は、ウォレット内に存在しない。どの暗号通貨も、秘密鍵を有する。ウォレットは、秘密鍵を保持する。秘密鍵を用いると、トランザクションにデジタル署名し、それを公開台帳に書き込むことができ、関連する暗号通貨を効率的に消費することができる。チェーンは、ピアツーピア・ネットワーク内の複数のデバイス上に格納される。ブロック内に格納されるデータは、「スマート・コントラクト」として知られる自動的に実行可能なコードを含むことができる。スマート・コントラクトは、契約の履行を容易化、検証、又は施行するコンピュータ・プロトコルである。

暗号通貨は、供給が限られ、所有権が台帳上に記録されるトークンと考えられ得る。したがって、暗号通貨は、原資産における株式持分などの原証券を「トークン化」、すなわち表現するために使用され得る。例えば、不動産及び金融商品などの様々な資産をトークン化し、トークンを売買することが知られている。２０１４年以降、分散型台帳技術によって資産価値をトークン化する取り組みが注目を集めている。

しかしながら、多くの売買可能な金融資産、したがってそれを表現するトークンは、様々な国の規制のフレームワークの下で「証券」と見なされている。例えば、米国証券取引委員会（ＳＥＣ：Ｓｅｃｕｒｉｔｉｅｓ ａｎｄ Ｅｘｃｈａｎｇｅ Ｃｏｍｍｉｓｓｉｏｎ）は、どのように証券が販売され得るか、誰に証券が販売され得るか、保管されなければならない記録、及び実施されなければならない開示についての規制上の制限を公布及び施行する。他の様々な国は、証券の販売を統制する独自の法律及び規制を有し、証券の販売に関する規制要件の複雑なウェブを作成している。近年、暗号通貨トークンの販売に基づいてビジネスに資金提供するためのメカニズムとして、イニシャル・コイン・オファリング（ＩＣＯ：Ｉｎｉｔｉａｌ Ｃｏｉｎ Ｏｆｆｅｒｉｎｇｓ）を利用することがごく一般的になっている。このようなトークンは、しばしば米国の法律及び他の管轄区域の法律の下で「証券」と見なされ、したがって、関連する証券法の対象となる。

様々な管轄区域の法律及び規制に対する配慮の欠如、又はそれらに準拠できないことにより、デジタル通貨の広範な受け入れが妨げられている。例えば、多くのＩＣＯが規制準拠への配慮なしに実施されたことで、現在ＳＥＣ又は他の機関によって調査されている。多くの当事者は、トークン化された資産の販売を、そのような販売を可能にする規制フレームワークを有すると考えられる管轄区域に制限しようとしている。しかしながら、ＤＬＴの分散型という固有の性質により、トークン販売の管轄区域を制限することは事実上不可能である。また、トークンの管轄権を有する可能性がある行政機関には、最初のトークン発行者、トークン販売者、トークン購入者、トークン交換の場、及びトークンが通過する又は格納される任意の場所の管轄権を有する該当の行政機関が含まれる。その結果、多くの当事者は、規制準拠の費用及び複雑さを避けるために、トークン化された資産の販売を完全に避けている。

私募から公募までの証券募集には、幅広い報告要件及び配布制限があることがわかる。証券トランザクションに関連する税務上の取扱い及び譲渡制限の範囲もある。ブロックチェーン・ソリューションは、投資家間の頻繁なトランザクションを容易にすることによって流動性を約束するが、この約束は、規制準拠をリアルタイムで施行しなければ、実現することができない。トークンベースの証券トランザクションにおいて流動性を完全に実現するには、広範且つ柔軟なコンプライアンスのフレームワークが必要である。

本発明の実装は、コンピュータ・ネットワークを介して分散型台帳上でトークン化された金融トランザクションを統制するために少なくとも１つのコンピューティング・デバイスによって実行される方法を含み、方法は、トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得するステップと、少なくとも１人の参加者についての参加者属性値を受信するステップであって、参加者属性が、少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び少なくとも１人の参加者に適用される管轄区域、並びにトランザクションのコンプライアンスの評価に関連する他の参加者属性を示すウォレット・アドレスにマッピングされる、受信するステップと、少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信するステップであって、トークンが、原資産を表すトークン属性値を有し、要求が、トークン及び要求側の参加者の参加者属性の表示を含む、受信するステップと、トランザクションに対して施行されるべきポリシー及びポリシーに関連付けられた少なくとも１つのルールを識別するステップであって、少なくとも１つのルールが、参加者属性、比較演算子、及び参加者属性の所望の値を含み、少なくとも１つのルールが、トークン属性、比較演算子、及びトークン属性の所望の値を含む、識別するステップと、ルール、参加者属性値、及びトークン属性値に基づいて、要求されたトランザクションに関連付けられた権利を検索するステップであって、権利が動詞／目的語ペアを指定する、検索するステップと、要求側の参加者がトランザクションに関与することを権利が許可するかどうかを判定するステップと、権利がトランザクションを許可するときにトランザクションを可能にするステップと、トランザクションを示す情報を分散型台帳に記録するステップとを含む。

別の実装は、コンピュータ・ネットワークを介して分散型台帳上でトークン化された金融トランザクションを統制するためのシステムであり、システムは、少なくとも１つのコンピュータ・プロセッサと、命令が格納されている少なくとも１つのメモリとを含み、命令は、少なくとも１つのコンピュータ・プロセッサによって実行されると、少なくとも１つのコンピュータ・プロセッサに、トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得することと、少なくとも１人の参加者についての参加者属性値を受信することであって、参加者属性が、とりわけ、少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び少なくとも１人の参加者に適用される管轄区域を示すウォレット・アドレスにマッピングされる、受信することと、少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信することであって、トークンが、原資産を表すトークン属性値を有し、要求が、トークン及び要求側の参加者の参加者属性の表示を含む、受信することと、トランザクションに対して施行されるべきポリシー及びポリシーに関連付けられた少なくとも１つのルールを識別することであって、少なくとも１つのルールが、参加者属性、比較演算子、及び参加者属性の所望の値を含み、少なくとも１つのルールが、トークン属性、比較演算子、及びトークン属性の所望の値を含む、識別することと、ルール、参加者属性値、及びトークン属性値に基づいて、要求されたトランザクションに関連付けられた権利を検索することであって、権利が動詞／目的語ペアを指定する、検索することと、要求側の参加者がトランザクションに関与することを権利が許可するかどうかを判定することと、権利がトランザクションを許可するときにトランザクションを可能にすることと、トランザクションを実行するための権利を示す情報を分散型台帳に記録することとを実行させる。

別の実装は、命令を格納する非一時的コンピュータ可読媒体であり、命令は、少なくとも１つのコンピュータ・プロセッサによって実行されると、少なくとも１つのコンピュータ・プロセッサに、トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得することと、少なくとも１人の参加者についての参加者属性値を受信することであって、参加者属性が、とりわけ、少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び少なくとも１人の参加者に適用される管轄区域を示すウォレット・アドレスにマッピングされる、受信することと、少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信することであって、トークンが、原資産を表すトークン属性値を有し、要求が、トークン及び要求側の参加者の参加者属性の表示を含む、受信することと、トランザクションに対して施行されるべきポリシー及びポリシーに関連付けられた少なくとも１つのルールを識別することであって、少なくとも１つのルールが、参加者属性、比較演算子、及び参加者属性の所望の値を含み、少なくとも１つのルールが、トークン属性、比較演算子、及びトークン属性の所望の値を含む、識別することと、ルール、参加者属性値、及びトークン属性値に基づいて、要求されたトランザクションに関連付けられた権利を検索することであって、権利が動詞／目的語ペアを指定する、検索することと、要求側の参加者がトランザクションに関与することを権利が許可するかどうかを判定することと、権利がトランザクションを許可するときにトランザクションを可能にすることと、トランザクションを実行するための権利を示す情報を分散型台帳に記録することとを実行させる。

オブジェクト管理のための属性ベース・アクセス制御（ＡＢＡＣ：Ａｔｔｒｉｂｕｔｅ Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロセスを拡張する実装によるアーキテクチャ及びワークフローの概略図である。 トークン・ガバナンスに対するポリシー施行に使用するためのユーザ／ウォレット属性及びトークン属性の概略図である。 一実装によるウォレット間のトランザクションを統制するための鍵／ロック構造の概略図である。 一実装による規制上のレシピ作成ユーザ・インターフェースのスクリーンショットである。 ポリシー決定を容易にするための属性ソースからルール・エンジンへのデータの流れの実装を示す図である。 一実装によるトークン作成、配布制御、ポリシー施行、及び権利施行のためのアーキテクチャのブロック図である。 トランザクションを統制するためのプロセスの実装のデータ・フローを示す図である。 クロス台帳ポリシーの施行を提供する相互運用層及びデコレータ・パターンの実装を示す図である。

暗号通貨のリアルタイムの配布という性質に準拠した自己実施型の自己報告型金融サービス・インフラストラクチャを介した世界規模のコンプライアンスが必要とされている。出願人は、そのようなインフラストラクチャの基盤を提供するために、分散型台帳によって与えられる実行ロジックの透明性、不変性、及び非中央集権化が活用され得ることを発見した。これらの発展は、複雑な証券トランザクションのコスト及び待ち時間を削減するための手段を提供する。ブロックチェーン台帳ベースのポリシー施行の適切な実装を通じて、ルネサンスを加速させた流動性がもたらされた１５世紀のメディチ家による台帳の革新以降初めての、銀行業及び他の金融サービスを改革する機会が存在する。

出願人は、デジタル著作権管理（ＤＲＭ：Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）及び属性ベース・アクセス制御（ＡＢＡＣ）の既知の手法を、ブロックチェーン・スマート・コントラクト及びコンプライアンス・ワークフローを通じて活用及び拡張して、規制要件及び他のガバナンス要件を暗黙的に組み込むトークンを作成することを可能にするアーキテクチャ及びプロトコルを開発した。本明細書に開示される実装は、グローバルにあらゆる形態の価値の効率的で準拠した移転を容易にする。

上記のように、証券の動きを統制する法律は、管轄区域によって異なる。分散型台帳技術の主な利点は、価値をグローバルに効率的に移転することである。証券の場合においてこのメリットを最大化するには、参加者をグローバルに識別及び認定すること、グローバルな管轄区域から多種多様な証券法を体系化すること、及びすべての場合でトランザクションにこれらのルールを施行することによってトークン配布を制御するためのコンプライアンス・フレームワークが必要である。トークン・トランザクションを統制する技術的なメカニズムは、本明細書では「配布制御」と呼ばれる。証券が存在する間中、そのトランザクションは、規制上の監督を受ける。これらのトランザクションはしばしば、税務上の取扱いを有し、投資家を保護及び認定するための制限を必要とし、詐欺を減らすための分析及び報告を求め、マネー・ロンダリングを制限するように設計された要件を課す。トークン化された価値は非中央集権型ウォレットを介して移転又は売買され得るので、配布制御はトークンと「ともに移動」し、スマート・コントラクト又は他の台帳制御を介してＤＬＴに組み込まれるべきである。ＩＴ用語において、配布制御は「永続的」であるべきである。

トークンの所有権がトークンの本来の台帳で表されるとき、トークンの所有権は「台帳上」にあると言われる。多くの場合、トークン価値の所有権は本来の台帳価値から派生し、効率的な取扱い及び保管のために異なる台帳（しばしば、内部データベース）で表されることがある。多くの取引所及び保管ソリューションは、速度、効率、及び安全のためにこの技法を使用する。この場合、トークン価値の所有権の移転は「台帳外」にあると言われる。同じ配布制限の多く又はすべてが「台帳外」に適用されるので、配布制御もこれらのシナリオで機能すべきであり、「台帳上」での使用のみに限定されるべきではない。

特定のＤＬＴの体系的な弱点のリスクを軽減し、証券トークンがＤＬＴの革新を確実に活用できるようにするために、配布制御は、いずれかの特定の分散型台帳から独立しているべきであり、台帳の実装間で移植可能であるべきである。例えば、米国の不動産持分の処分に対する外国人への課税を米国に許可した１９８０年外国不動産投資税法（ＦＩＲＰＴＡ：Ｆｏｒｅｉｇｎ Ｉｎｖｅｓｔｍｅｎｔ ｉｎ Ｒｅａｌ Ｐｒｏｐｅｒｔｙ Ｔａｘ Ａｃｔ）により、外国人（譲渡人）による米国の不動産持分の処分は源泉所得税の対象である。さらに、米国の連邦法を含むいくつかの管轄区域では、証券のクラスの保有者数が重要である。例えば、１９３４年証券法のセクション１２（ｇ）の下では、株式のクラスが２０００人を超える保有者によって保有されている場合、証券の発行者は広範な報告義務を負うことになり、これは、口語では「公開会社」として知られている。適切な配布制御がない場合、このような状況が不用意に発生し、発行者にとって望ましくない結果をもたらす可能性がある。

多くの証券トランザクションは、参加者が「適格投資家」、「認定投資家」であることなどの特定の基準を満たしている場合、又は特定の地理的若しくは居住の基準を満たしている場合にのみ、連邦、州、又は非米国の法律又は規制の下で法的に許可される。多くの場合、投資家の認定ステータスなどのこれらの特性は、静的ではなく動的である。トランザクションの有効性は変化する条件に依存するので、ルール施行モデルは、リアルタイムでありスケーラブルでなければならない。

ブロックチェーン・ネットワークは、設計によってグローバル化され、世界中どこでも所有権の迅速な移転を容易にすることができる。しかしながら、上記のように、証券法は、管轄区域によって大きく異なる可能性がある。例えば、投資家の資格、報告要件、さらにはセキュリティ・トークン・オファリングの資本形成方法としての合法性さえも国際的な管轄区域によって変わる。したがって、証券のトークン化には、募集の管轄区域及びトランザクションに関与するすべての参加者を認識し、発行市場とその後の売買及び移転との両方における複雑で相反してさえいる規制要件を考慮し、パッチワーク規制を自動的且つ大規模に施行され得るルールセットに組み込み、トークンのライフサイクルを通じて規制上の制限の変化に適応することができる、コンプライアンス・フレームワークが必要である。

多くの証券では、（規制限度を超える）トランザクションに対してさらなる制限が必要になる場合がある。発行者によって定義される制限は、契約及び実務において共通である。例として、移転のために発行者の明示的な許可を要求する能力、参加者の最小所有数又は最大所有数に対する制御、売買価格の限度などが挙げられる。制限は、市場の状態、参加者の数、参加者の社内での役割、企業の発表又は活動への近さなどの状況に依存する場合がある。これらのルールの複雑さには、柔軟でありながら広範な権利管理モデルが必要である。

投資家を保護し、詐欺を制限し、適切な行政監督を可能にするために、証券トークンは、規制と整合する方法で取り扱われなければならず、許可された人によってのみ保持されなければならず、適切な報告要件に準拠しなければならない。本明細書における実装の配布制御は、トークン化された証券に、及び他のトークン化された資産の移転に適用され得る。多くの政府当局は、大口金融トランザクションに関する報告を求める。例えば、米国では現在、銀行秘密法により、金融機関は１日の総額が１０，０００ドル（ＵＳ）を超える現金取引、又は疑わしい現金取引について報告する必要がある。このような規制に準拠するために、サービス・プロバイダーは、価値の送り手と受け手の両方のアイデンティティを確実に知らなければならない。実装は、特にトークン化された証券に対する非中央集権型金融トランザクションのコンプライアンス及び適合性を統制するためのコンピュータ・アーキテクチャ、プラットフォーム、及びプロセスを含む。証券トランザクションは最も複雑な金融トランザクションのひとつであるが、実装は、ユーティリティ・トークンの移転及び法定通貨による支払いなどの他のトランザクションを統制するために適用されてもよい。

本明細書に記載の実装は、複雑な証券法及びトランザクション制御を、中央集権型又は非中央集権型の方式で評価され得る検証可能なルールセットにマッピングするルール・エンジンを含む。これらのルールセットは、コンプライアンス又は他のガバナンスの意思決定の再利用可能なデータ構造である「レシピ」として保存することができ、レシピは、容易に共有され、グラフィカルに編集され、拡張可能アクセス制御マークアップ言語又は他のコンピュータ解釈可能コードなどのオープン標準形式で非一時的な媒体に格納され得る。

実装は、コンプライアンスの決定の複雑さ及び反復的でないことに起因して移転が実用的ではない流動性の低い金融商品を、任意の規模の日常的なトランザクションで使用され得る流動性の高い金融商品に変換する。ＤＬＴの革命が多くのトランザクションの性質を変えつつあるが、多くのトランザクションは引き続き、トランザクションの記録を維持するために従来のデータベース、スプレッドシート、又は他の電子的手段などの他の技術を使用するシステム及び場所である「オフ・チェーン」で発生するであろう。これに対処するために、実装は、トランザクションを、オン・チェーンで統制する（ＤＬＴ内でトランザクションを統制する）、チェーンを越えて統制する（異なるＤＬＴに対する制御を提供する）、及びオフ・チェーンで統制する（従来の台帳で又は台帳間で発生するトランザクションを統制する）ための技法を採用する。

実装は、非中央集権型の属性ベース・アクセス制御（ＡＢＡＣ）フレームワークを提供して能動的な仲介者を必要とせずにグローバルな金融トークン化トランザクションを統制するための、コンプライアンス・ワークフロー、属性検証ツール、施行用のスケーラブルな鍵／ロック・モデル、スマート・コントラクト、及び他の台帳制御の新規な組合せを含む。実装は、ＡＢＡＣ、スマート・コントラクトの抽象化、及びレシピの共有を通じて、オン・チェーン・トランザクション及びオフ・チェーン・トランザクションを統制するための方法を提供する。

従来のＡＢＡＣモデルでは、企業内の文書及びデータなどのオブジェクトへのユーザのアクセスは、ポリシー施行点（ＰＥＰ：ｐｏｌｉｃｙ ｅｎｆｏｒｃｅｍｅｎｔ ｐｏｉｎｔ）によって統制される。ユーザは、オブジェクトへのアクセスを電子的に要求する。ＰＥＰは、ポリシー決定サービス（ＰＤＳ：ｐｏｌｉｃｙ ｄｅｃｉｓｉｏｎ ｓｅｒｖｉｃｅ）を参照し、ポリシー決定サービスは、適切なポリシー及び属性データを収集してアクセスに関する決定を提供する。許可された場合、ユーザは、オブジェクトへのアクセス権が付与される。

図１は、ＡＢＡＣコンポーネントを活用するコンプライアンス強化アーキテクチャ１００を示し、これは、企業又は他のドメインで、「参加者」と呼ばれることがあるユーザ間の価値資産のトランザクションを統制するために使用されるポリシー施行点（ＰＥＰ）１０と、アクセス権の決定に必要な適用可能なポリシー及びデータを収集するために使用されるルール・エンジン１２（ポリシー決定サービス（ＰＤＳ）を含む）と、企業アクションを実行するために必要なルールを定義するレシピ・ストレージ１４（ポリシー・ストアを含む）と、ユーザ（すなわちトランザクションの参加者）、影響を受けるトークン（デジタル・オブジェクトとして）、及びポリシー決定をサポートするための環境に関連するコンテキスト・データを提供する属性ソース１６とを含む。

図１の実装では、ＡＢＡＣアーキテクチャは、１）ネットワーク（例えば、分散型台帳）でユーザのアイデンティティと一意のアドレス（ウォレット２０で表される）との間のリンクを確立して、ユーザのプライバシーを保護すると同時にスケーラブルで決定的な意思決定を提供すること、２）動詞／目的語ペアを含む「トークンの権利」へのアクセス（単一の動詞）のガバナンスの概念を拡張すること、３）ルール及びコンテキスト属性の共有可能なレシピ、４）台帳制御及びスマート・コントラクトを通じてポリシー施行を実装すること、並びに、６）ポリシーを値トークンにマッピングすることによって強化されている。

実装は、いくつかのステップを含む非中央集権型金融トランザクションを統制する新規なプロセス（図１の太い矢印で識別される）を含む。ステップ１）では、金融トランザクションにおけるすべての参加者のデジタル・アイデンティティが明確に識別される。実装は、世界規模で動作するスケーラブルなアイデンティティ証明（ＩｄＰ：Ｉｄｅｎｔｉｔｙ Ｐｒｏｏｆｉｎｇ）モデルを利用する。このアイデンティティ（及びその関連する権利）へのアクセスは、生体情報を含む複数の要素を使用した安全なリスクベースの認証を提供する分散型アイデンティティ・サービスによって制御され得る。このサービスは、金融ネットワーク上でのユーザの権利への柔軟で高度な保証アクセスを提供する。参加者はウォレット・アドレスに関連付けられる。暗号ウォレットの所有者のアイデンティティ及び関連する属性の再検証は、アイデンティティの盗難及び／又は証券法を覆す権利の不正な共有を防ぐために、頻繁にいつでも実行され得る。参加しているアイデンティティに関する関連属性は、統制対象のトランザクションのすべての参加者に対して検証される。この検証は、トークン・トランザクションを統制する責任を負う当事者（通常、発行者及び／又はブローカ・ディーラ）のコンプライアンス・ポリシーによって統制されるリスク決定を含む。検証ステップの一部の態様は、出願人が実装した技法を使用して自動化される場合があるが、一部の決定は、より長く稼働するワークフロー又はプロセスを必要とするジャッジメント・コールである。

参加者のＩＤが検証されると、参加者の属性は、既知の「顧客の身元確認」（ＫＹＣ：ｋｎｏｗ ｙｏｕｒ ｃｕｓｔｏｍｅｒ）プロセスを通すなどの既知の方式で決定されてよく、非中央集権型のポリシー施行に使用されてよい。（しばしば低速で主観的な）属性検証プロセスを（ほぼ即時の客観的な）ポリシー施行から分離することによって、コンプライアンスの施行は、非中央集権型ネットワーク上でグローバルにリアルタイムで実行され得る。実装では、検証された属性はネットワーク上の一意のアドレス、例えば暗号ウォレットにリンクされる。分散型台帳では、各ウォレットはアドレスに対応する。ウォレットを動作させる権限は、ウォレット所有者の属性から導出された権利を使用して（以下で説明されるようなＰＥＰを介して）評価され得る。実装では、ユーザ属性セットは、アドレスのアクションを所有し責任を負うエンティティに１対１で直接リンクされ得る。アドレス（ウォレット）を介して実行されるすべてのトランザクションは、その所有者に帰属可能であり、その所有者の権利に関連付けられる。アドレス所有者の属性（及び派生する権利）は、アドレス所有者の個人識別可能な情報（ＰＩＩ：ｐｅｒｓｏｎａｌ ｉｄｅｎｔｉｆｉａｂｌｅ ｉｎｆｏｒｍａｔｉｏｎ）とは別に格納及び評価され得るので、トランザクションが帰属可能で、準拠していることを確保しながら、トランザクション参加者のプライバシーを保護することができる。

ステップ２において、アドレスに関連付けられたウォレット２０が、１つ又は複数のトークン（他のトークン化された価値ある資産を表し得る）を含むトランザクション（支払い、移転、購入、売買など）に関与することを要求すると、ＰＥＰ１０が参照される。ＰＥＰは、スマート・コントラクト若しくは台帳制御を通じて台帳上に存在して、非中央集権型ポリシー施行を提供してもよく、又は、台帳外に存在して、セキュリティ・アセスメント・マークアップ言語（ＳＡＭＬ：Ｓｅｃｕｒｉｔｙ Ａｓｓｅｓｓｍｅｎｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）アサーション若しくは他の構文を介して連携された権利評価を提供してもよい。

ステップ３において、ＰＥＰ１０は、ポリシーを施行するために、以下で説明するようにポリシーを解釈し、幅広いサービスからデータを収集して所与のトランザクション・コンテキスト（ユーザ・アイデンティティ、場所、トークン属性、及び他の変数を含む）の適時の意思決定を提供するためのスケーラブルで決定的な方法を提供するように設計されたルール・エンジン１２に問合せする。例えば、トークンは米国のレギュレーションＤの証券の株式所有権を表してもよい。その結果、その配布は適格投資家であることを証明した個人に限定される。所有者が適格投資家であると評価されたウォレットへの配布を制限するレシピが、トークンに付属され得る。この場合、ＰＥＰはトランザクションのすべての参加者についての属性（参加者が適格であるかどうかに関係なく）を取得し、トークン移転用のポリシーに照らして評価しなければならない。ステップ４において、ルール・エンジン１２は、トランザクション要求で指定された所望の権利に関連付けられた適切なポリシーを収集する。ポリシーは「レシピ」、すなわちコンプライアンス要件及び他の所望のガバナンスを表すルールセットとして格納される。レシピは、前例を活用し、複雑で多様なグローバル規制をマッピングし、規制の監督を簡素化するために、組み合わされ、再利用され、又は拡張されてもよい。ルール・エンジン１２は、頻繁に使用されるオブジェクトの迅速な決定を容易にするために、レシピをキャッシュしてもよい。ルール・エンジンのロジック及び機能は、台帳上で、台帳外で、又は最大限の柔軟性、非中央集権化、及びスケールのためのハイブリッド・ソリューションとして実装されてもよい。

ステップ５において、トランザクションの参加者、オブジェクト、及び環境に関する関連データを収集するために、属性ソース１６が参照される。ルール・エンジン１２は、関連するレシピに従ってポリシーの決定に必要なデータをどこでどのように取得するかの説明を含む属性を提供する。例えば、ルールがトークン保持者の数を制限している場合、ルール内の属性は、ルールが評価され得るように現在のトークン保持者の数を取得する方法についての指示を有するマップを含む。命令は、データが格納されるネットワーク・アドレス、データにアクセスするためのＡＰＩ、及びデータにアクセスするための認証情報を含む場合がある。柔軟性を確保するために、ルール・エンジン１２は、相互運用性のフレームワーク及びインターフェースを提供して、「オラクル」と呼ばれることもある外部の独立したデータ・ソースへの参照を可能にする。このフレームワークを通じて、ルール評価用のデータ・ソースはポリシーにマッピングされ得る。ステップ６において、施行のために、ポリシーの決定がルール・エンジン１２からＰＥＰに返される。繰り返し発生するトランザクションの効率的な施行を容易にするために、特定のトランザクションを実行するための権利は、しばしばＰＥＰ１０でキャッシュされる。ステップ７では、オブジェクトに対して所与のアクションを実行するための動詞／目的語ペアを含み得る権利は、適切なレシピ及びアイデンティティ並びに属性に基づいて付与され、要求されたトランザクションが実行される。

図２に示すように、トークンは、既知の方法で署名を導き出すための暗号鍵としてアドレスを使用してユーザのウォレットによって署名され、署名は、ユーザの関連する管轄区域及びユーザの投資家ステータス（例えば、適格投資家、機関投資家など）を示すウォレット属性を含む。さらに、トークンは、トークン属性、すなわちトランザクションの他のコンテキスト属性を示す関連メタデータを含む。トークン属性及び属性が付けられた参加者に基づくトランザクションのガバナンスについては、以下でさらに詳細に説明する。

図３に示すように、実装は、鍵／ロック構造を使用し、この構造は、トランザクション内の基礎となる値（ロック）に関連付けられた反復可能で検証可能なルールセットに、ウォレットの属性をマッピングすることによって発行者の判断を切り分ける。ウォレットＡ又はウォレットＢの所有者の検証された属性、並びにトランザクションのサイズ及び現在の参加者の数などの環境変数は、鍵へと構成され、トランザクション内の参加者がトランザクションを実行する権利を有しているかどうかを判定するために、トークン又はその他のオブジェクト（ロック）に対して定義されたルールセットと突き合わせて評価される。これらの権利は、スマート・コントラクト又はトランザクションを許可又はブロックするための他の台帳制御を使用して、非中央集権型の方法でリアルタイムに評価される。

実装は、アクションを試行する１つ又は複数のアクターが主語であり、試行されるアクションが動詞であり、アクションを実行されるべきアイテムが目的語である、主語、動詞、目的語（ＳＶＯ）構造を用いて、任意の金融トランザクションに関連するコンプライアンス・ルールを体系化するための柔軟で反復可能でスケーラブルなプロセスを提供する。例えば、ユーザ（主語）は特定のトークン（目的語）を移転（動詞）しようとしている。このように、すなわちアクセスの決定を権利の決定に変換することによってＡＢＡＣ手法を拡張すると、金融ネットワーク上での複雑なトランザクションを統制するためのより柔軟なフレームワークが可能になる。図４は、レシピを作成及び編集するためのユーザ・インターフェース４００を示す。レシピ内のルールについての属性、値、ロジックを選択するためのユーザ選択制御が提供される。

トークンの移転など、目的語に対してアクションを実行する権利は、主語（１人又は複数のトランザクションの参加者）、及び特定の動詞と目的語の組合せに割り当てられているルールセット（レシピ）に対するそのコンテキストに関連付けられた属性を取得することによって評価される。このようにして、発行者は、例えば適格投資家のステータスを示す属性を有していないユーザがアクセス制限付きセキュリティ・トークンを含むトランザクションに参加できるかどうかを統制することができる。トランザクションの参加者及び環境コンテキスト（主語）は「鍵」を提供し、所望のアクションとトークン（動詞／目的語）の組合せはトランザクションを統制するための「ロック」に関連付けられる。

金融サービスの権利評価に関連する複雑な決定ロジックを体系化するには、ルール・エンジン１２が、範囲、アイテム、アクション、属性、ルール、レシピ、及び権利という、いくつかのオブジェクト及び概念を実装するように構成されている必要がある。「範囲」は、複数の当事者がアイテム、アクション、及び権利を定義することができる共有のコンテキストである。これらの定義を読み取り、変更するためのアクセスは、権利管理の責任及び責任追跡性を保護するとともに共有手段を提供する範囲に割り当てられた資格情報を必要とする。トークンは、権利が評価されるときに突き合わされるオブジェクトである。範囲内では、システムは所望の数のアイテム（証券トークンの場合、これらは通常は一意のトークン・シンボルである）を自由に作成及び維持することができる。「アクション」は、システム内のアイテムに対して実行され得る動詞である（例えば、売買、移転など）。「属性」は、ルールセットの評価に使用されるアクター及びその環境の特性である。

範囲内では、属性は、ルールセットのリアルタイム評価のためのアクター、アイテム、及び環境に関連するデータを取得するための名前及びメカニズムを含む。例えば、ルールセットは、トランザクションの参加者が適格投資家であるという要件を含んでもよい。属性は、要求されたトランザクション・コンテキストでのこのデータを取得する場所の説明を含み、データをルール評価用に復元する。ルールは、属性、比較演算子、及び所望の値を含む。例えば、ルールは、ユーザの居住国を評価する場合がある。次のルールは、トランザクションの参加者が米国の居住者であってはならないことを要求する：Ｊｕｒｉｓｄｉｃｔｉｏｎ＿Ｃｏｕｎｔｒｙ（属性）ＩＳ ＮＯＴ（比較演算子）Ｕｎｉｔｅｄ Ｓｔａｔｅｓ（所望の値）。

ルールは、例えば図４のＧＵＩを使用してルール演算子（ＡＮＤ、ＯＲ、及びファジー論理演算子）によって、レシピとして格納され得るルールセット内に構成及び接続されてよい。レシピは、ネットワーク上でトランザクションを実行する権利を取得するために必要な属性を定義するために、目的語／動詞の組合せに付属される。

ルール・エンジン１２は、スケーラブル及び／又は非中央集権型のルール評価をサポートするために、オン・チェーン又はオフ・チェーンに配置され得る。実装は、ルール・エンジン１２の実装用のいくつかのモデルを含み、これには、スケール及び柔軟性を促進するためのオフ・チェーンのルール評価、非中央集権化を最大限にするためのオン・チェーンのルール評価、又は柔軟性、非中央集権化、及びＤＬＴと旧式の金融ネットワークとの互換性を最大限にするためのハイブリッド・モデルが含まれる。ハイブリッド・モデルの一実例は、オフ・チェーンに位置するルール・エンジンをホストするが、迅速に実行するために、オン・チェーンに格納された権利を評価する。

図５により詳細に示されるように、ルール・エンジン１２は、アクションのコンテキスト及び参加者に関連付けられたレシピに含まれる適切な属性によって定義される必要なデータを、ソース１６から収集する。収集されるデータには、文字列、数値データ、日付、リスト、及び評価に使用される他のフォーマットされたデータが含まれ得る。ソース１６は、キャッシュ・メモリ及び／又は内部／外部ソースである場合がある。

ルールは、ルール評価をサポートするデータ収集及びキャッシング用の自己記述型モデルを含む属性から構成され得る。属性は、そのデータ・タイプ及び形式、ソース、ソースにアクセスするための手段、追加のフィルタリング及びコンテキスト・データ、並びに特定の属性についての性能と待機時間のバランスを管理するためのキャッシング・ルールを記述することができる。属性ソース１６は、適切なものを介してルール・エンジン１２と通信することができる。例えば、レシピがトークン保持者の数を制限するルールを含む場合、ルール・エンジンは、要求されたトランザクションの正当性を評価するために、トークン保持者の現在の数を取得しなければならない。現在のトークン保持者数は、トークンが存在する分散型台帳に問合せすることによって取得される。属性は、台帳に問合せするために使用されるコードを提示するためにルール・エンジンによって使用される命令を含む。レシピは、多くの様々なソースからのデータを必要とする属性を含む多くのルールから構成されてもよい。以前にマッピングされていない追加のデータを必要とする新しいレシピが開発されてもよい。したがって、属性マッピングは、他のシステム動作に影響を与えることなく、新しいソースを効率的にエンジンに挿入することを可能にする柔軟なアーキテクチャを通じて実行される。

ルール・エンジン１２は、所望の目的語／動詞の組合せに関連するレシピを評価して、アクションを実行するための権利が付与され得るかどうかを判定する。特定のコンテキストにおけるユーザの権利は、リアルタイムでトランザクションを統制するためにインラインで利用される場合があり、オン・チェーンに格納されてもオフ・チェーンに格納されてもよく、又は、ＲＥＳＴｆｕｌ ＡＰＩコール、ＳＡＭＬアサーション、若しくはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔデータ形式を介して共有されてもよい。

権利は、ＰＥＰ１０に格納又はキャッシュされる場合、規制上の変更などのダイナミクスに対応するために有効期限を有することができる。格納された権利は、レシピのルール又はコンテキストの変更により、無効にされてもよい。システムは、変更がある場合に権利の再検証を強制してもよい。権利は、スマート・コントラクト（Ｅｔｈｅｒｅｕｍ、ＥＯＳなど）又は台帳制御（Ｒｉｐｐｌｅ、Ｓｔｅｌｌａｒ）を介してチェーンにキャッシュされてもよい。

金融トランザクションのガバナンスについて、ポリシー施行プロセスの非限定的な実例を以下に説明する。１）台帳制御の使用による配布制御（例えば、Ｒｉｐｐｌｅ、Ｓｔｅｌｌａｒなどに実装される）、２）スマート・コントラクトの使用による配布制御（例えば、Ｅｔｈｅｒｅｕｍ、ＥＯＳ、及び派生物に実装される）、３）相互運用性及びデコレータ・パターンの使用による配布制御（クロス台帳の施行）、並びに４）共有された権利及び権限の使用による配布制御（例えば、中央集権型の取引所及び第三者システムに実装される）。

台帳制御によるポリシー施行は、トランザクション・コールバック・メソッド及び「トラストライン」を利用する。トラストラインは、ウォレットがトークンとのトランザクションに参加するための権利を統制するために台帳上に格納された、ウォレット所有者とトークン発行者（又は他の指定された当事者）との間の双方向の合意である。台帳プラットフォームは、コールバック又はウェブ・フックを通じて、ルール・エンジン１２などの外部サービスを参照してネットワーク上の特定のトランザクションに対するより細かい制御を提供してもよい。

図６は、スマート・コントラクト、すなわち分散型ノードを介して実行する非中央集権型アプリケーション（ｄＡｐｐ：ｄｅｃｅｎｔｒａｌｉｚｅｄ ａｐｐｌｉｃａｔｉｏｎｓ）を実装するＤＬＴ用のＰＥＰ６１０のアーキテクチャを示す。ブロックチェーン拡張ＰＥＰ６１０は、最も一般的なＥｔｈｅｒｅｕｍトークン規格（ＥＲＣ２０、ＥＲＣ６２１、ＥＲＣ７２１など）をサポートし、任意のブロックチェーン上の任意のトークン・プロトコルをサポートするように拡張され得る。トークン発行者は、ＰＥＰ６１０によって実行されるスマート・コントラクトを通じて、コンプライアンス制御が組み込まれたトークン、及び配布制御を含まないトークンを即座に発行してもよい。スマート・コントラクトは、発行者が、シンボル・レジストリを用いてネットワーク上でシンボルの一意性を登録し、コンプライアンスのロールバック・トランザクション、バリュー・エスクロ、ウォレットの凍結などの追加のセキュリティ及びルールの施行を通じて、トークンの配布を統制することを可能にする拡張機能を提供することができる。

ＰＥＰ６１０のアーキテクチャは、配布制御を容易にするための以下のコンポーネントを含む。シンボル・レジストリ６２０は、トークン・シンボル用のリポジトリである。トークンの展開前に商標及びブランドの権利を保護するために、発行者はトークンの作成前にトークン・シンボルを登録してもよい。トークン・ファクトリ６３０は、新しいトークンを作成することを求める要求を受け入れ、関連するパラメータを確認し、トークン戦略、例えば、規格によって統制されたトークンのサポートされる動きを通じてトークンを展開するコンポーネントである。トークン・ファクトリ６３０は、トークンを作成する機能、及び展開戦略を削除又は更新する機能を実行する。戦略は、スマート・コントラクト、すなわちトークンを実装し、その動き及びインターフェースを定義するコンピュータ・コードである。典型的には、戦略はトークン規格にリンクされる。実行されると、規格によって要求される共通のインターフェースを提供するトークンが配信される。例えば、トークン・ファクトリは、ＥＲＣ−２０、ＥＲＣ−７２１、及び他の多くの規格の発行をサポートする。戦略の変更はまれであるが、これらのスマート・コントラクトは、経時的に更新又は削除され得る。トークンの動きにおけるより幅広いオプションを発行者に提供する多くの新しい戦略が出現し、追加されると予想される。

権限検証システム（ＰＶＳ）６４０は、展開されたスマート・コントラクトで処理される要求の検証のための中核として機能する。これは、レシピを評価し、権利をキャッシュし、ウォレット属性を格納し、外部データ・ソースに到達して他の属性を検索する機能を具現化する。ＰＶＳは、ネットワーク・コンポーネントにアクセスするために使用される権利及び役割を作成及び管理するための柔軟なメカニズムである権限モジュール６４２を含む。権限モジュール６４２は、トークン発行、シンボル登録、新しい検証サービスの登録、戦略の追加／削除などに対する制御を保持又は移転するための機能を付与する。ＰＶＳ６４０は、付与された権限に基づいてシンボルを登録し、トークンを作成し、利用可能なトークン戦略を追加又は修正し、検証サービスを移転することを求める要求の正当性を検証するネットワーク役割マネージャ６４４も含む。ＰＶＳ６４０は、特にトークンに関連する要求を検証するトークン役割マネージャ６４６も含む。例えば、要求は、トークンをホワイトリストに追加すること、ホワイトリストから削除すること、又はロールバック・トランザクションを実行することを求める要求を含み得る。

移転検証システム（ＴＶＳ）６５０は、トークンの割り当てられた戦略、すなわち、トークン・ファクトリによって割り当てられたスマート・コントラクトの選択に基づきトークンに対して定義された動きに基づいて、ポリシー及び施行ロジックを割り当てる。各規格は、特定の移転検証ロジックを実装することができ、ホワイトリスト、ルール・エンジンなどの１つ又は複数の施行サービスを含むことができる。ＴＶＳ６５０は、トークン移転検証に関する要求を受け入れる移転モジュール６５２を含む。移転モジュール６５２は、トークン・ファクトリ６３０にトークン規格を要求する。移転モジュール６５２は、適用可能なトークン規格に基づいて、移転検証ロジックを選択することができる。

移転検証システム６５０は、ＣＡＴ−２０、ＣＡＴ−７２１などの各トークン規格に対して指定された移転検証ロジック６５４を通じた移転検証ポリシーの施行を含む。ＣＡＴ−２０は、Ｃｏｍｐｌｉａｎｃｅ Ａｗａｒｅ Ｔｏｋｅｎの略であり、配布制御を含むようにＥＲＣ−２０規格の実装を拡張する。移転検証ロジック６５４は、ホワイトリスト、ルール・エンジン（図１のルール・エンジン１２など）、ステート・ロジック、又は他のサービスなどの異なる移転検証サービス６５６によって実装され得る。トークン規格ごとに異なる移転検証サービス６５６が存在する可能性がある。移転検証サービス６５６は、トークン、ウォレットに関連付けられた検証された権利及び属性を格納し、オン・チェーン及びオフ・チェーンのトランザクションからデータを収集する。権利ストアの一例は、トークンに関連する特定のトランザクションで検証されたウォレットのリストを格納するホワイトリストである。ホワイトリストは、要求を送信又は受信する前に、トランザクションに関与するすべてのウォレットの適格性を確認するために使用され得る。このような実装において、ホワイトリスト内にウォレットが見つからない場合、トランザクションは拒否される。トークンに対するトランザクション・ポリシーは、オン・チェーンのレシピとして格納されてもよい。同様に、ウォレットの所有者に関連付けられた属性もオン・チェーンに格納されてよい。これにより、非中央集権型のルール評価が可能になる。

図７は、トランザクションの権利決定及びガバナンスのためのプロセスの実装を示す。７０１では、ユーザ・デバイスは、ウォレットに検証された属性を付与し、例えば、上記の属性検証プロセスを使用して、ユーザの居住国、並びにユーザが適格投資家及び／又は機関投資家であるかどうかなどのユーザ属性を決定することができる。この実例では、ユーザの管轄国は米国であり、ユーザは適格投資家である。図２を参照すると、７０２では、ユーザ・ウォレットは、ユーザに代わって、オブジェクトに対するアクションをＰＥＰに要求する。例えば、ウォレットは、ウォレット所有者から別の当事者にトークンを移転するように要求してもよい。この実例では、トークンは、１９３３年証券法タイトル１７「商品及び証券取引」パート２３０−一般規則及び規制のレギュレーションＤの下で提供されている証券を表す図２のトークンである。したがって、トークンは、管轄区域：米国、及び適格認定＝ＴＲＵＥという属性を必要とするレシピを有する。当然ながら、要求する「ウォレット」は、ウォレット・アドレスへのアクセス権を有するパーソナル・コンピュータ又は携帯電話などの任意のユーザ・デバイスとすることができ、ユーザの命令は、ユーザ・デバイスのユーザ・インターフェースを介して受信されてもよい。トランザクションにおけるすべての参加者は、上記の必要な属性（管轄区域：米国、適格認定：ＴＲＵＥ）を有する。７０３では、ＰＥＰは、トランザクションに関与するトークン及び参加者の権利を、権利キャッシュに要求する。例えば、権利キャッシュは、トランザクションに関与する所望のトークン及び参加者の以前に評価された権利を含むことができる。７０４では、要求されたトランザクションに対する評価された権利がキャッシュで利用可能である場合、要求に対する評価された権利は、キャッシュから直接ＰＥＰに返されてもよく、プロセスは以下のステップ７１３に進むことができる。

権利が特定の属性、すなわちコンテキストに対して以前に評価されておらず、それにより７０４でＰＥＰに返されなかった場合、コンテキストに対して新しい権利が評価されなければならない。７０５において、ＰＥＰは、新しい権利を作成するために、トランザクション・コンテキストにおける権利をルール・エンジンに要求する。７０６では、ルール・エンジンは、要求されたコンテキストの権利に対応するレシピを要求し、７０７でレシピが返される。７０８では、ルール・エンジンは、関連するコンテキスト用の追加のデータを属性キャッシュに要求する。関連データが属性キャッシュにある場合、７０９においてデータはポリシー評価のために返される。関連データには、トランザクションの適合性の評価に必要とされる、信用格付け、管轄区域データ、投資家の資格、担保情報、トレード・マッチ情報、口座残高、提出された報告書類などが含まれ得る。関連データがキャッシュされていない場合、７１０において、ルール・エンジンは、属性ストアなどの別のソースにデータを要求し、７１１において属性が返される。次いで、７１２では、データは、後で使用するために属性キャッシュ内に格納され得る。７１３では、レシピ、ユーザ属性、トークン属性、及び関連する外部データに基づく評価決定のために、権利がＰＥＰに返される。例えば、トークンはレギュレーションＤの下で販売される証券を表すので、簡略化された実例では、レシピは以下のようになり得る。
（１）参加者は米国人でなければならない。
（２）参加者は適格な個人又は機関投資家でなければならない。
（３）参加者は募集に関連するリスク開示をすでに読んでいなければならない。

当然ながら、レギュレーションＤの実際の要件及びその他の要件は、上記の実例よりもはるかに複雑である。返された権利が、ＰＥＰによって許可されると決定される場合、７１４において、ウォレットは、要求されたトランザクションを行うことを許可される。７１５では、評価された権利は、後で使用するために権利キャッシュ内にキャッシュされ得る。

図８は、一実例における相互運用層及びデコレータ・パターンの図である。実装は、オン・チェーン及びオフ・チェーンのトランザクション・ガバナンスをサポートするポリシー施行メカニズムを使用することができる。これにより相互運用層及びデコレータ・パターンを使用することによって、従来の金融サービス・インフラストラクチャを含む異種の台帳８１０間で一貫したルールの施行が可能になる。デコレータ・パターンは、異種のネットワーク間で同様のアクションをインターセプトして共通のセキュリティ及びコンプライアンス機能を実行することができるパターンである。特定の実装では、この抽象化層は、組込み制御も有し得る特定のトランザクションの継承又はオーバーライドされたガバナンスである場合がある。

デコレータ・パターンでは、トランザクションは、ポリシー施行、セキュリティ機能、並びに自動化されたロギング、報告、及び監督を提供する連合サービス・バスである、パイプライン８２０を介してルーティングされる。デコレータ・パターンは、トランザクションを適切な金融システム、取引所、及び台帳技術にルーティングしてトランザクションを実行する抽象化層の一部である。この実装は、異種の金融システム間に、共通のポリシー施行を提供する。

別の実装では、内部ポリシー施行のために、取引所プラットフォームなどの第三者システムによって権利が取得される。権利は、ユーザのログイン時に、ルール・エンジン１２への直接的な要求を通じて（図１）、又はアイデンティティ及び属性サービスによって提供されるＳＡＭＬアサーションを介して間接的に取得されてもよい。第三者システムは、所与のコンテキスト及び範囲においてユーザに関連付けられた包括的な一連の権利（動詞／目的語の組合せ）を取得してもよい。これらの権利は、第三者システムによって使用されるネイティブ権限フレームワークを使用して取引所でのトランザクションを統制するために使用されてよい。

すべての実装において、トランザクション（トークンの売買又は移転など）に関与するためのユーザの権利は、トランザクションの前に評価されキャッシュに格納されるか、又はリアルタイムでのガバナンスのためにトランザクション時に評価されてもよい。トークンに対してアクションを実行するユーザの権利は、適切なポリシー施行点への要求を通じて決定される。付与された場合、ユーザの権利は、必要に応じて有効期限付きでキャッシュ内の台帳上、又は台帳外に格納されてもよい。

本明細書に開示される様々な機能は、１つ又は複数の有形のコンピュータ可読メモリに格納された命令を実行するプロセッサを有する１つ又は複数のコンピューティング・デバイスによって実現されてもよい。様々なデバイスは、既知のプロトコルを使用して既知の方式で互いに通信可能に結合されてもよい。例えば、デバイスは、ローカル・エリア・ネットワーク又はインターネットを介して結合され、集中型、プライベート非中央集権型、又は公開非中央集権型ネットワーク上に存在し得る台帳に影響を与える可能性がある。

非中央集権型金融トランザクションにコンプライアンス・ポリシーを施行するために、追加の代替の構造設計及び機能設計が実装されてもよい。したがって、実装及び実例が図示され説明されてきたが、本発明は、本明細書に開示された正確な構造及び構成要素に限定されないことを理解されたい。添付の特許請求の範囲で定義される本発明の趣旨及び範囲から逸脱することなく、本明細書に開示される方法及び装置の構成、動作及び詳細において、様々な修正、変更及び変形が実施されてもよい。

Claims (15)

1. コンピュータ・ネットワークを介して分散型台帳上でトークン化された金融トランザクションを統制するために少なくとも１つのコンピューティング・デバイスによって実行される方法であって、
   トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得するステップと、
   前記少なくとも１人の参加者についての参加者属性値を受信するステップであって、前記参加者属性が、とりわけ、前記少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び前記少なくとも１人の参加者に適用される管轄区域を示すウォレット・アドレスにマッピングされる、受信するステップと、
   前記少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信するステップであって、前記トークンが、原資産を表すトークン属性値を有し、前記要求が、前記トークン及び前記要求側の参加者の前記参加者属性の表示を含む、受信するステップと、
   前記トランザクションに対して施行されるべきポリシー及び前記ポリシーに関連付けられた少なくとも１つのルールを識別するステップであって、前記少なくとも１つのルールが、参加者属性、比較演算子、及び前記参加者属性の所望の値を含み、前記少なくとも１つのルールが、トークン属性、比較演算子、及び前記トークン属性の所望の値を含む、識別するステップと、
   前記ルール、前記参加者属性値、及び前記トークン属性値に基づいて、前記要求されたトランザクションに関連付けられた権利を検索するステップであって、前記権利が動詞／目的語ペアを指定する、検索するステップと、
   前記要求側の参加者が前記トランザクションに関与することを前記権利が許可するかどうかを判定するステップと、
   前記権利が前記トランザクションを許可するときに前記トランザクションを可能にするステップと、
   トランザクションを実行するための前記権利を示す情報を分散型台帳に記録するステップと
   を含む、方法。
2. 権利を検索する前記ステップが、前記ポリシー、前記参加者属性、及び前記トークン属性に基づいて前記権利を評価するステップと、前記要求されたトランザクションが許可されるかどうかを判定するステップとを含む、請求項１に記載の方法。
3. 権利を検索する前記ステップが、前記ポリシー、前記参加者属性、及び前記トークンに基づいて評価されたキャッシュ権利から検索することを含む、請求項１に記載の方法。
4. 前記ポリシーが、発行者のポリシー、国際的な証券法及び規制、並びに／又は他のトランザクション制御を疑似コードに体系化したものである、請求項１に記載の方法。
5. 前記検証されたアイデンティティが、他のネットワーク・アドレスから識別可能ではない、請求項１に記載の方法。
6. 前記ポリシーが、他のソースからポリシー評価に必要な関連データを取得する方法を説明する指示を含む、請求項４に記載の方法。
7. 複数の異種の従来型又は分散型台帳間での金融トランザクションを統制するために、相互運用層及びデコレータ・パターンを介して通信するステップをさらに含む、請求項１に記載の方法。
8. コンピュータ・ネットワークを介して分散型台帳上でトークン化された金融トランザクションを統制するためのシステムであって、
   少なくとも１つのコンピュータ・プロセッサと、
   命令が格納されている少なくとも１つのメモリと
   を含み、前記命令は前記少なくとも１つのコンピュータ・プロセッサによって実行されると、前記少なくとも１つのコンピュータ・プロセッサに、
   トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得することと、
   前記少なくとも１人の参加者についての参加者属性値を受信することであって、前記参加者属性が、とりわけ、前記少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び前記少なくとも１人の参加者に適用される管轄区域を示すウォレット・アドレスにマッピングされる、受信することと、
   前記少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信することであって、前記トークンが、原資産を表すトークン属性値を有し、前記要求が、前記トークン及び前記要求側の参加者の前記参加者属性の表示を含む、受信することと、
   前記トランザクションに対して施行されるべきポリシー及び前記ポリシーに関連付けられた少なくとも１つのルールを識別することであって、前記少なくとも１つのルールが、参加者属性、比較演算子、及び前記参加者属性の所望の値を含み、前記少なくとも１つのルールが、トークン属性、比較演算子、及び前記トークン属性の所望の値を含む、識別することと、
   前記ルール、前記参加者属性値、及び前記トークン属性値に基づいて、前記要求されたトランザクションに関連付けられた権利を検索することであって、前記権利が動詞／目的語ペアを指定する、検索することと、
   前記要求側の参加者が前記トランザクションに関与することを前記権利が許可するかどうかを判定することと、
   前記権利が前記トランザクションを許可するときに前記トランザクションを可能にすることと、
   トランザクションを実行するための前記権利を示す情報を分散型台帳に記録することと
   を実行させる、システム。
9. 権利を検索することが、前記ポリシー、前記参加者属性、及び前記トークン属性に基づいて前記権利を評価することと、前記要求されたトランザクションが許可されるかどうかを判定することとを含む、請求項８に記載のシステム。
10. 権利を検索することが、前記ポリシー、前記参加者属性、及び前記トークンに基づいて評価されたキャッシュ権利から検索することを含む、請求項８に記載のシステム。
11. 前記ポリシーが、発行者のポリシー、国際的な証券法及び規制、並びに／又は他のトランザクション制御を疑似コードに体系化したものである、請求項８に記載のシステム。
12. 前記検証されたアイデンティティが、他のネットワーク・アドレスから識別可能ではない、請求項８に記載のシステム。
13. 前記ポリシーが、他のソースからポリシー評価に必要な関連データを取得する方法を説明する指示を含む、請求項１１に記載のシステム。
14. 前記命令が、前記少なくとも１つのプロセッサに、複数の異種の従来型又は分散型台帳間での金融トランザクションを統制するために、相互運用層及びデコレータ・パターンを介して通信することをさらに実行させる、請求項８に記載のシステム。
15. 命令を格納する非一時的コンピュータ可読媒体であって、前記命令が前記少なくとも１つのコンピュータ・プロセッサによって実行されると、前記少なくとも１つのコンピュータ・プロセッサに、
    トランザクションの少なくとも１人の参加者の検証されたアイデンティティを示すデータを取得することと、
    前記少なくとも１人の参加者についての参加者属性値を受信することであって、前記参加者属性が、とりわけ、前記少なくとも１人の参加者のうちの少なくとも１人に関連付けられた投資家のカテゴリ及び前記少なくとも１人の参加者に適用される管轄区域を示すウォレット・アドレスにマッピングされる、受信することと、
    前記少なくとも１人の参加者のうちの１人である要求側の参加者からトークンのトランザクションに関与することを求める要求を受信することであって、前記トークンが、原資産を表すトークン属性値を有し、前記要求が、前記トークン及び前記要求側の参加者の前記参加者属性の表示を含む、受信することと、
    前記トランザクションに対して施行されるべきポリシー及び前記ポリシーに関連付けられた少なくとも１つのルールを識別することであって、前記少なくとも１つのルールが、参加者属性、比較演算子、及び前記参加者属性の所望の値を含み、前記少なくとも１つのルールが、トークン属性、比較演算子、及び前記トークン属性の所望の値を含む、識別することと、
    前記ルール、前記参加者属性値、及び前記トークン属性値に基づいて、前記要求されたトランザクションに関連付けられた権利を検索することであって、前記権利が動詞／目的語ペアを指定する、検索することと、
    前記要求側の参加者が前記トランザクションに関与することを前記権利が許可するかどうかを判定することと、
    前記権利が前記トランザクションを許可するときに前記トランザクションを可能にすることと、
    トランザクションを実行するための前記権利を示す情報を分散型台帳に記録することと
    を実行させる、非一時的コンピュータ可読媒体。