特表 2024-505006 コンプライアンス対応のデジタル的に表されたアセットのためのシステムおよび方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-02-02

(54)【発明の名称】コンプライアンス対応のデジタル的に表されたアセットのためのシステムおよび方法

(51)【国際特許分類】

   G06Q 20/08 20120101AFI20240126BHJP

【ＦＩ】

G06Q20/08

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023544657

(86)(22)【出願日】2022-01-25

(85)【翻訳文提出日】2023-09-01

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

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

(87)【国際公開日】2022-07-28

(31)【優先権主張番号】63/140,987

(32)【優先日】2021-01-25

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

(31)【優先権主張番号】63/152,655

(32)【優先日】2021-02-23

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

(31)【優先権主張番号】63/172,466

(32)【優先日】2021-04-08

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

(31)【優先権主張番号】63/184,952

(32)【優先日】2021-05-06

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】523279833

【氏名又は名称】シーランス コーポレイション

(74)【代理人】

【識別番号】100092783

【弁理士】

【氏名又は名称】小林 浩

(74)【代理人】

【識別番号】100120134

【弁理士】

【氏名又は名称】大森 規雄

(74)【代理人】

【識別番号】100141025

【弁理士】

【氏名又は名称】阿久津 勝久

(72)【発明者】

【氏名】アズガド－トロマー，シュロミット

(72)【発明者】

【氏名】グリーン，マシュー

(72)【発明者】

【氏名】トロマー，エラン

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055AA21

(57)【要約】

コンプライアンスポリシーに従ってデジタルアセットネットワーク上のトランザクションを管理するように構成されたコンプライアンスシステムが提供される。デジタルアセットネットワークは、パブリックな台帳へのトランザクションの記録を制御するルールを施行するように構成される。コンプライアンスシステムは、要求されたトランザクションがコンプライアンスポリシーに従っているということを決定することと、少なくとも部分的に暗号化されたコンプライアンス関連補助情報（ＣＲＡＩ）を生成することであって、ＣＲＡＩが、コンプライアンスの独立した検証を容易にするように構成された情報を含む、生成することと、ＣＲＡＩの少なくとも一部をパブリックな台帳に格納されたトランザクション情報に関連付け、関連付けられたＣＲＡＩをデジタルアセットネットワークを介してアクセスできるストレージ位置に格納することとを行うように構成される。

【特許請求の範囲】

【請求項1】

コンピュータで実行されるコンプライアンスシステムであって、前記コンプライアンスシステムは、コンプライアンスポリシーに従ってデジタルアセットネットワーク上のトランザクションを管理するように構成され、前記デジタルアセットネットワークが、パブリックな台帳へのトランザクションの記録を制御するルールを施行するように構成され、前記コンプライアンスシステムが、
要求されたトランザクションが前記コンプライアンスポリシーに従っているということを決定することと、
少なくとも部分的に暗号化されたコンプライアンス関連補助情報（ＣＲＡＩ）を生成することであって、前記ＣＲＡＩが、前記コンプライアンスの独立した検証を容易にするように構成された情報を含む、生成することと、
前記ＣＲＡＩの少なくとも一部を前記パブリックな台帳に格納されたトランザクション情報に関連付け、前記関連付けられたＣＲＡＩを前記デジタルアセットネットワークを介してアクセスできるストレージ位置に格納することと
を行うように構成される、コンプライアンスシステム。

【請求項2】

暗号化された規制情報をユーザのトランザクションのうちの１つまたは複数に関連付けることであって、前記規制情報が関連する規制エージェントによって復号可能である、関連付けることと、
前記１つまたは複数のトランザクションに関する情報を含んでいる報告を生成することと、
前記関連する規制情報を含む前記報告を暗号によって格納することとを行うようにさらに構成される、請求項１に記載のコンプライアンスシステム。

【請求項3】

前記コンプライアンスポリシーが、疑わしい活動を構成する１つまたは複数の条件を定義し、前記コンプライアンスシステムが、前記１つまたは複数のトランザクションが前記定義された疑わしい活動を構成するということを決定するように構成される、請求項２に記載のコンプライアンスシステム。

【請求項4】

前記報告の存在の知識が暗号化されるように、前記規制情報を含む前記報告を暗号によって格納するように構成される、請求項３に記載のコンプライアンスシステム。

【請求項5】

前記規制情報を復号するための情報を、少なくとも前記ユーザは使用することができない、請求項４に記載のコンプライアンスシステム。

【請求項6】

前記規制情報を関連付けること、および前記報告を生成することが、前記ユーザに関連付けられたウォレットによって実行される、請求項２に記載のコンプライアンスシステム。

【請求項7】

前記ストレージ位置が、前記デジタルアセットネットワークの前記パブリックな台帳である、請求項１に記載のコンプライアンスシステム。

【請求項8】

前記ＣＲＡＩを前記トランザクションに関連付けることが、前記ＣＲＡＩを前記トランザクションに添付することを含む、請求項７に記載のコンプライアンスシステム。

【請求項9】

前記ストレージ位置が、パブリックにアクセスできるサーバであり、前記デジタルアセットネットワークの前記パブリックな台帳に記録されたトランザクション情報が前記ストレージ位置を参照する、請求項１に記載のコンプライアンスシステム。

【請求項10】

前記コンプライアンスポリシーが、禁止されたトランザクションの１つまたは複数の属性を定義し、前記コンプライアンスシステムが、前記コンプライアンスポリシーによって禁止されていると見なされるトランザクションの実行を阻止するように構成される、請求項１に記載のコンプライアンスシステム。

【請求項11】

前記コンプライアンスポリシーが、推論を必要とするトランザクションの１つまたは複数の属性を定義し、前記コンプライアンスポリシーが、トランザクションが推論をいつ必要とするかを識別し、前記推論の量を計算し、トランザクションを開始して、前記必要とされる推論の要求を満たすように構成される、請求項１に記載のコンプライアンスシステム。

【請求項12】

前記デジタルアセットネットワークの機能を利用して、トランザクション情報に添付されたＣＲＡＩの妥当性をチェックし、それによって、前記コンプライアンスポリシーへのコンプライアンスを検証するように構成される、請求項１に記載のコンプライアンスシステム。

【請求項13】

前記コンプライアンスポリシーによって定義された複数のシールされたウォレットを備え、前記シールされたウォレットが、要求されたトランザクションが前記コンプライアンスポリシーに従っているかどうかを判定するために、前記ＣＲＡＩに対して推論するように構成される、請求項１に記載のコンプライアンスシステム。

【請求項14】

前記シールされたウォレットの少なくとも一部が、前記デジタルアセットネットワークに格納されたコードとして実装される、請求項１３に記載のコンプライアンスシステム。

【請求項15】

１つまたは複数のトランザクションに関連付けられたＣＲＡＩに対して推論するようにさらに構成される、請求項１に記載のコンプライアンスシステム。

【請求項16】

前記ＣＲＡＩが、前記トランザクションが前記コンプライアンスポリシーに従うということの証明を含む、請求項１に記載のコンプライアンスシステム。

【請求項17】

前記ＣＲＡＩが、前記コンプライアンスポリシーへの要求されたトランザクションのコンプライアンスの決定に関連するコンプライアンス情報を含む、請求項１から１６のいずれか一項に記載のコンプライアンスシステム。

【請求項18】

前記コンプライアンス情報が、１つまたは複数の関係者の識別情報を前記トランザクションに関連付ける、請求項１７に記載のコンプライアンスシステム。

【請求項19】

前記コンプライアンス情報が前記トランザクションの詳細に関連する、請求項１７および１８のいずれか一項に記載のコンプライアンスシステム。

【請求項20】

ユーザに対応する情報を検証することと、前記検証時に識別情報証明を前記ユーザに発行することとを行うように構成された識別情報プロバイダをさらに備える、請求項１に記載のコンプライアンスシステム。

【請求項21】

前記識別情報証明が、
前記ユーザの識別情報を含んでいるパブリックな構成要素、および／または
暗号鍵材料を含んでいるプライベートな構成要素を含む、請求項２０に記載のコンプライアンスシステム。

【請求項22】

前記識別情報証明が、前記ＣＲＡＩの少なくとも一部を構成する、請求項２１に記載のコンプライアンスシステム。

【請求項23】

前記コンプライアンスポリシーに従ってＣＲＡＩを添付することによって、前記デジタルアセットネットワークに関連付けられたネイティブなアセットを拡張し、それによって、シールされたアセットを生成するように構成される、請求項１に記載のコンプライアンスシステム。

【請求項24】

シールされたアセットからＣＲＡＩを分離し、それによって、前記シールされたアセットから前記ネイティブなアセットを抽出するように構成される、請求項２３に記載のコンプライアンスシステム。

【請求項25】

互換性のあるコンプライアンスポリシーによって定義されたシールされたウォレットおよびシールされたアセットを含んでいる適合するプールを定義するようにさらに構成される、請求項２３に記載のコンプライアンスシステム。

【請求項26】

前記コンプライアンスポリシーが、どのコンプライアンスポリシーが互換性があるかを定義する、請求項２５に記載のコンプライアンスシステム。

【請求項27】

前記コンプライアンスポリシーが、シールされたアセットが前記適合するプールから離れる条件を定義する、請求項２５に記載のコンプライアンスシステム。

【請求項28】

１つまたは複数の関係者を含んでいるトランザクションを防ぐようにさらに構成される、請求項２５から２７のいずれか一項に記載のコンプライアンスシステム。

【請求項29】

前記ＣＲＡＩが、各トランザクションの第三者の検証を容易にするように構成された規制エスクローアクセスフィールドを含む、請求項１に記載のコンプライアンスシステム。

【請求項30】

トランザクションに関連するエンコードされた数学関数を前記トランザクションに添付するようにさらに構成される、請求項１に記載のコンプライアンスシステム。

【請求項31】

疑わしい活動に関して１つまたは複数のトランザクションを分析するようにさらに構成される、請求項１に記載のコンプライアンスシステム。

【請求項32】

前記ＣＲＡＩの少なくとも一部の暗号化が、前記ＣＲＡＩの内容を公開せずに、前記ＣＲＡＩの検証を容易にする、請求項１に記載のコンプライアンスシステム。

【請求項33】

前記検証がゼロ知識証明を含む、請求項３２に記載のコンプライアンスシステム。

【請求項34】

前記ＣＲＡＩの少なくとも一部の暗号化が回復不可能である、請求項１に記載のコンプライアンスシステム。

【請求項35】

前記トランザクション情報が、前記トランザクションの送信者の暗号識別子、前記トランザクションの受信者の暗号識別子、およびトランザクションの詳細から成る群から選択された１つまたは複数を含む、請求項１に記載のコンプライアンスシステム。

【請求項36】

前記トランザクションが通貨を移動することを含む、請求項１に記載のコンプライアンスシステム。

【請求項37】

前記通貨が暗号通貨である、請求項３６に記載のコンプライアンスシステム。

【請求項38】

２つ以上のコンプライアンスポリシーから選択された少なくとも１つのコンプライアンスポリシーに従ってデジタルアセットネットワーク上のトランザクションを管理するように構成される、請求項１に記載のコンプライアンスシステム。

【請求項39】

１つまたは複数のコンピュータプロセッサと、構成されたとおりに動作するように前記システムに指示するための実行可能な命令を格納しているメモリとを備える、請求項１に記載のコンプライアンスシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書において開示されている主題は、デジタルアセットネットワーク上でトランザクションを管理するためのシステムに関し、詳細には、そのようなネットワークに対するコンプライアンス（法令尊守）ポリシーの施行のために構成されたシステムに関する。

【背景技術】

【0002】

パブリックな暗号通貨システムは、これらのシステムを非常に成功させた多くの利点を提供し、将来、既存の銀行インフラストラクチャの一部またはすべてを置き換えることを可能にすることができる。それと同時に、パブリックな暗号通貨システムは、それらの有用性を減らす複数の制限から悪い影響を受ける。

【0003】

ビットコインおよびイーサリアムなどのパブリックな台帳は、すべてのトランザクションがパブリックに可視であるため、トランザクションのプライバシーを完全には保護しない。代わりに、これらのネットワークの参加者は、限定的なプライバシーを提供する、「アドレス」として知られている（場合によっては、多くの）偽名の識別子を採用する。しかし、偽名の識別子が提供するプライバシーの保証は弱く、１つのアドレスをユーザの実際の識別情報にリンクできる任意の関係者が、ユーザのトランザクション履歴全体を回復できる可能性が高い。

【0004】

ビットコインなどのパブリックな台帳は、「許可なし」であり、すなわち、任意の関係者がシステム上でトランザクションを実行することができる。この設計の結果、ユーザは、通貨の流れに対して制限を施行するノーユアカスタマー（ＫＹＣ：Know Your Customer）ルールまたはアンチマネーロンダリング（ＡＭＬ：Anti-Money Laundering）ルール、あるいは任意の他の銀行規則を順守する必要がない。現在、暗号通貨エコシステム内の制限された位置のみで、つまり、暗号通貨と従来の銀行システムの間をインターフェイスで接続する交換および他の仮想アセットサービスプロバイダ（ＶＡＳＰ：Virtual Asset Service Providers）で、銀行規則へのコンプライアンスが施行される。これらのプロバイダは、次に、プロバイダが処理する暗号通貨のトランザクションパターンを分析するために、例えば、プロバイダの顧客がリスクを伴うか、または違法である可能性があるトランザクションに従事しているかどうかに関して判断を行うために、暗号通貨ネットワークのパブリックな性質を利用する。このプロセスは、不完全なデータからのかなりの量の当て推量および推定を伴う。それにもかかわらず、このトレースおよびリスク評価機能を実行するための複数の商用製品が開発された。

【0005】

「ゼロ知識証明」などの技術は、暗号通貨システムのプライバシー特性を改善することができる。そのような技術は、参加者の識別情報および各トランザクションの量を隠蔽する、一部の暗号通貨システムの一部として展開された。しかし、改善されたプライバシーは、規制コンプライアンスに影響がある。プライバシー技術が向上するにつれて、チェーン上のトランザクションデータの品質が低下する傾向があり、パブリックなトランザクションデータから収集されるトレースおよびリスク推定データの精度をさらに低下させる。プライバシーの改善は、将来展開される可能性が高く、最新の暗号通貨エコシステムに脅威をもたらすことがある。

【0006】

この問題に対するいくつかの提案された解決策が提供されている。１つの解決策は、既存の分散型暗号通貨システムおよび「ウォレット」ソフトウェアを破棄し、集中型の、例えば、従来の銀行パートナーまたはＶＡＳＰによって操作されるシステムに置き換えることである。これによって、場合によっては、暗号通貨技術の分散型の性質を根本的に取り除くという犠牲を払って、規制コンプライアンスを簡略化する。他の提案は、ユーザが、分離した集中型のレジストリ内の各トランザクションに関して自発的に報告することを必要とする。この手法は、新しい信頼できる関係者も必要とし、さらに、ネットワーク上のすべての関係者が参加している場合にのみ、効果的である。

【発明の概要】

【0007】

本明細書において開示されている主題は、コンプライアンス層を提供するように構成されたシールされたアセットプラットフォーム（ＳＡＰ：sealed asset platform）、およびユーザまたはトランザクションのプライバシーを犠牲にせずに規制コンプライアンスシステムが既存の暗号通貨ネットワークと相互運用するのを容易にするためのアーキテクチャを対象にする。

【0008】

ＳＡＰは、コンプライアンスを施行するのを容易にするためにコンプライアンス関連補助情報（compliance relevant auxiliary information）（以下では、「ＣＲＡＩ」）を使用して暗号通貨トランザクションおよびウォレットを拡張するように、およびＣＲＡＩを使用して各関連する情報のやりとりでのコンプライアンスポリシーの順守を暗号によって保証するように、構成されてよい。ＳＡＰは、ＣＲＡＩを明示的または暗黙的に使用して一部またはすべてのトランザクションおよび／またはウォレットを拡張することによって、シールされたアセットを生成する。

【0009】

ＣＲＡＩは、ユーザ識別情報（名前、国民識別子など）、口座番号および施設識別子、第三者によって発行され認証情報（信用リスクスコアおよび／または認定された投資家ステータスを含むが、これらに限定されない）、ユーザの挙動および／または支払いパターンに関連する情報（トランザクション履歴、資金の来歴、資金源、取引相手の識別情報、および／またはトランザクションに関連する情報を含むが、これらに限定されない、および／またはコンプライアンスに関連すると見なされる任意の他の情報を含んでよい。ＣＲＡＩは、機械的に記録されてよく、および／または台帳メカニズム（例えば、トランザクション履歴）によって推論されてよく、あるいは外部の関係者によって提供されてよい（例えば、ＫＹＣ情報、および下で説明されるアセット認識サービス（asset-aware services）からの情報）。

【0010】

ＣＲＡＩが暗号通貨台帳に記録されている間に、ＣＲＡＩは、プライバシーを損なうため、台帳に対するアクセス権限を持つ誰によっても読み取られ得る明示的な形態で提供されない。むしろこの情報は、暗号によって保護され、例えば、コンプライアンスポリシーによって決定されたトランザクションごとに許容される関係者のみが、許容される推論を見ることができる。

【0011】

任意の１つまたは複数の適切な方法によって、ＣＲＡＩの暗号保護が提供されてよい。そのような方法の非限定的な例は、以下を含んでよい。
（１）復号が、許可された関係者のみに可能であるように、ＣＲＡＩを暗号化された形態で添付する。これは、復号が可能であること、および基礎になるデータが正しく形成されて認証されることを、暗号によって、例えばゼロ知識証明によって、保証することを含んでよい。この方法は、他の関係者（例えば、分散型台帳のバリデータまたは「マイナー」）が、各ＣＲＡＩを復号する能力を欠いていながら、有効なトランザクションを認識することを可能にすることができる。
（２）ＣＲＡＩを（例えば、プライバシー上の懸念および／またはデータサイズ制約に起因して）回復できない形態で添付する。例えば、ＣＲＡＩは、推論および属性（例えば、トランザクション送信者の国籍、トランザクション送信者の毎月のトランザクションの総量など）のみを含んでよく、ＣＲＡＩの正しさが暗号によって、例えばゼロ知識証明によって、保証される。
（３）ＣＲＡＩを保持している関係者とＣＲＡＩの特性を検査したい関係者の間で実行される暗号秘匿マルチパーティ計算（cryptographic secure multiparty computation）を使用して、ＣＲＡＩを確認および／または公開する。

【0012】

前述したように、シールされたアセットは、例えば、情報の１つまたは複数のソースからのデータに基づいて、所与のトランザクションが許可されるべきであるかどうか、どの情報が誰に公開されなければならないかを決定するコンピュータプログラムとして実装された、管轄区域に固有のコンプライアンスポリシー（例えば、１つまたは複数のルール）の施行を容易にすることができる。そのような情報は、トランザクションの詳細（例えば、量、時間など）、ＣＲＡＩ内に含まれているユーザ（すなわち、送信者）識別情報、受信者情報（例えば、公開鍵などの暗号識別子）、暗号通貨台帳に格納された公開情報および／または個人情報などから選択された１つまたは複数を含んでよいが、これらに限定されない。

【0013】

コンプライアンスポリシーは、管轄区域の関係当局によって、それらの規制義務を実施する１つまたは複数のコンソーシアム（例えば、自治業界団体）によって、規制される実体によって、および／または任意の他の適切な関係者によって、確立されてよい。例えば、コンプライアンスポリシーは、ある速度を超える資金流出、送信先の指定された許可リスト以外の資金流出などを防ぐことなどの、固有の要件に適合するように、組織または個人によって決定されてよい。

【0014】

コンプライアンスポリシーは、例えば、どのＣＲＡＩ情報が各トランザクションに添付されなければならないか、誰がＣＲＡＩ情報を見ることができるべきであるか、ＣＲＡＩ情報が暗号によって保証された推論によって明示的または暗黙的のどちらで伝達されるか、などを指定してよい。例えば、ポリシーは、粒度の粗い情報がトランザクション受信者に公開され、認証されるということ、詳細なウォレット所有者識別情報が、特定の条件下で許可された法の執行によって復号され得る暗号化された形態で添付されるということ、および指定された関係当局が、既定の値を超えるトランザクションのみをリアルタイムに見ることができるということを指示してよい。コンプライアンスポリシーは、仮想アセットにおいて、どのトランザクションが発生することが許容されるかに関する制限をさらに課してよい。例えば、コンプライアンスポリシーは、ユーザが、単一のトランザクション内で、特定の期間の間に、指定された関係者または関係者のグループなどに送信できる通貨の量に対する制限を、１つまたは複数のそのような制限の組み合わせを含めて、指定してよい。

【0015】

ＳＡＰは、例えば、ユーザの保持しているシールされたアセットをユーザの識別認証情報に結び付けるのを容易にするように構成されたデータ構造を含む、ユーザの１つまたは複数のシールされたウォレットを定義するように構成されてよい。特に、ＳＡＰは、ウォレットが関連付けられる管轄区域（例えば、ウォレットの所有者が対象になる管轄区域）のポリシーに従って、シールされたウォレットを定義するように構成されてよい。これは、例えば、ポリシーによって規定されたリストからの規制される実体によるＫＹＣ、ＡＭＬ、および／またはＣＴＦチェック、ウォレットの所有者の関連する属性を証明する、他の許可された関係者による認証情報発行などを実施するのを容易にすることを伴ってよい。これらのチェックは、ウォレット識別情報プロバイダ（ＷＩＰ：wallet identity provider）、すなわち、新しいシールされたウォレットを発行する能力を維持する関係者によって、妥当性を確認されてよい。個別のアセットは、例えば、許可されていないＷＩＰによるトランザクションを拒否するポリシーを指定することによって、どの識別情報プロバイダが許容できるかを決定してよい。

【0016】

ＣＲＡＩは、ユーザのウォレットの実装によって生成され、または維持され、他のユーザによって直接信頼されず、ＳＡＰは、各トランザクションが、そのトランザクションが関連付けられたポリシーに従うことを保証するように、構成される。したがって、ＳＡＰは、不適合候補トランザクションが自動的に拒否されるように、そのようなコンプライアンスに関してすべてのトランザクションをチェックするための機械的方法を提供してよい。

【0017】

シールされたアセットは、完全に新しい仮想アセットであってよく、またはシールされたアセットは、適切なＣＲＡＩを使用して既存のネイティブな（すなわち、従来の）アセット（例えば、ビットコインなどの既存の暗号通貨）を拡張する（例えば、「シールされたビットコイン」を生み出す）ことによって取得されてよい。後者の場合、ＳＡＰは、ネイティブなアセットの単位がシールされたアセットの単位に変換されるシールプロセスを実行するように構成される。ポリシーによって必要条件が定義され、例えば、ポリシーによって規定されたリストからの規制される実体による手動のＫＹＣ／ＡＭＬ／ＣＴＦチェックで構成されてよい。

【0018】

すべてのシールされたアセットは、作成された後に、同じおよび／または互換性のあるコンプライアンスポリシーにそれぞれ関連付けられた複数のシールされたウォレットおよび複数のシールされたアセットを含んでいる適合するプール内で、トランザクションを実行されてよい。異なるウォレットは（例えば、操作しているウォレットの所有者が含まれる管轄区域に応じて）異なるポリシーの対象になることがあるため、単一のシールされたアセットは、複数の適合するプールに関連付けられてよい。適合するプール間でシールされたアセットを移動することは、元のプールおよび行き先のプールの両方のポリシーの対象になり、これらのポリシーは、無制限の移動を可能にすることができ、（例えば、量において、または必須の報告において）制約を課すことができ、または移動に、指定されたゲートウェイによる承認を受けさせることができる。

【0019】

ＳＡＰは、シールされたアセットの「シールを破る」こと、すなわち、例えば、前述したようにネイティブなアセットをシールすることによって作成されたシールされたアセットの場合、シールされたアセットに関連付けられたＣＲＡＩを除去することによって、シールされたアセットから基礎になるネイティブを抽出することを容易にするように、さらに構成されてよい。これは、例えばシールされたアセットの所有者によって、シールされたアセットの任意の単位に対して別々に実行され得る。そのような場合、抽出されたネイティブなアセットは、適合するプール内に存在しなくなり、他の関係者は、このアセットを、ＳＡＰによって保証されなくなったコンプライアンスを有するアセットとして認識し、したがって、このアセットが再びシールされるまで、このアセットのすべてのトランザクションを拒否してよい。この場合、前述のポリシーによって決定されるプロセスによって、シールが実行されてよい。一部の実施例によれば、ＳＡＰは、アセットが他のユーザにまだ転送されていない場合（したがって、除去されたＣＲＡＩにすでに関連付けられていると認識できる場合）、アセットを自動的に再シールするように構成されてよい。したがって、シールを破る能力は、例えば、システム故障の場合に、資金の喪失の回避に対する保護を容易にするための安全性の尺度を提供することができる。

【0020】

したがって、ＳＡＰは、（ポリシーによって定義されたとおりに）関連するウォレットおよび関連するトランザクションのＣＲＡＩを正しく伝達し、および伝搬する、適合するプール内のトランザクションを許可するように構成される。これは、トランザクションの取引相手、使用されている結果として得られた資金を含む上流のトランザクション、およびトランザクションに関連付けられたＣＲＡＩに関する情報を考慮することを含んでよい。

【0021】

一部の実施例によれば、ＳＡＰは、例えば、多くの顧客の役に立つ保管機関によって、分散型交換および／または他の分散型金融システムによって、あるいはミックスネットなどのプライバシー強化システムによって、複数の混合されたシステムを通ってＣＲＡＩを伝搬するための１つまたは複数の調整された手段を容易にしてよい。したがって、ＳＡＰは、混合されたシステムから資金が引き出されるときにＣＲＡＩを正確に伝達するように構成されてよい。

【0022】

ＳＡＰは、管轄区域のポリシーが、プライバシーおよび個人情報が公開されることを指示しない限り、および指示するまでは、デフォルトでのプライバシーの保証、およびすべての個人情報の保護を提供するように、構成されてよい。これは、ポリシーに固有の条件下で正式に許可された関係者を除いて公開することが許容できない、ＫＹＣ情報およびトランザクション履歴などの、ユーザの個人を特定できる情報のデフォルトでの保護を含んでよい。

【0023】

ＳＡＰは、シールされたアセットをサポートしてよく、ＣＲＡＩを搬送し、任意の種類の仮想アセットに関するポリシーを施行する。本文書では、「仮想アセット」、「デジタルアセット」、および「アセット」という用語は、コンピュータシステム上で所有権および移動がデジタル的に表され得る任意のアセットを参照するために、交換可能なように使用される。このアセットは、代替可能アセット（すべての単位が等しい値を有し、本質的に異なる識別情報を含まないアセット、例えば、ほとんどの暗号通貨、ステーブルコイン、代替可能トークン、および銀行が発行したデジタル通貨）、異なる（物理的または仮想的）アセットの所有権または制御を表す非代替可能トークン、アセットの来歴に対する追加の推論によって非代替可能にされたアセット（例えば、「色付きのコイン」またはチェーン分析に起因して来歴による影響を受ける値を有するコイン）などを含んでよいが、これらに限定されない。

【0024】

そのようなアセットは、ブロックチェーン台帳上に作成され、ブロックチェーン台帳によって主に定義されてよく（例えば、ステーブルコインを含むほとんどの暗号通貨）、かつ／または他のアセットの所有権を表してよい（例えば、証券、金融派生商品、商品、不動産、収集品などの金融商品またはアセットの所有権を表すデジタルトークン）。

【0025】

ＳＡＰは、パブリックブロックチェーンに基づく台帳に対して、プライベートまたは許可型ブロックチェーンに基づく台帳に対して、および／または十分に定義された意味論を使用してアセットの所有権およびアセットの移動イベントを表すことができる任意の他の適切なデジタルシステムに対して動作してよく、デジタルシステムは、そのような情報を表すように構成されたデータベースを含む。デジタルシステムは、通貨、証券、または他のアセットの移動をデジタル的に伝達する支払いおよび／または清算サービスを含んでよいが、これに限定されない。

【0026】

ＳＡＰは、ＣＲＡＩを維持するように、ならびに複数の種類のシールされたアセットを含んでいるトランザクションおよび／または複数のブロックチェーンに基づく合意システム（または仮想アセットを表すための他のシステム）にわたってコンプライアンスポリシーを施行し、統一された適合するプールを作成するように構成されてよい。例えば、ＳＡＰは、ＣＲＡＩを追跡し、ビットコインブロックチェーンによって追跡された１つのシールされたＢＴＣコインをイーサリアムブロックチェーンによって追跡された３５個のシールされたＥＴＨコインに交換するトランザクションにわたってコンプライアンスを施行してよい。

【0027】

本明細書において開示されている主題の態様によれば、コンプライアンスポリシーに従ってデジタルアセットネットワーク上のトランザクションを管理するように構成されたコンプライアンスシステムが提供されており、デジタルアセットネットワークは、パブリックな台帳へのトランザクションの記録を制御するルールを施行するように構成され、コンプライアンスシステムは、
要求されたトランザクションがコンプライアンスポリシーに従っているということを決定することと、
少なくとも部分的に暗号化されたコンプライアンス関連補助情報（ＣＲＡＩ）を生成することであって、ＣＲＡＩが、コンプライアンスの独立した検証を容易にするように構成された情報を含む、生成することと、
ＣＲＡＩの少なくとも一部をパブリックな台帳に格納されたトランザクション情報に関連付け、関連付けられたＣＲＡＩをデジタルアセットネットワークを介してアクセスできるストレージ位置に格納することとを実行するように構成される。

【0028】

本明細書および添付の特許請求の範囲では、特に文脈から明確でない限り、「コンプライアンス」、「コンプライアンスシステム」などの用語は、内部のポリシー（例えば、コンプライアンスポリシーによって定義されたポリシー）を参照して使用されており、必ずしも、関連する規制、法律などへのコンプライアンスを参照して使用されていないということが、理解されるであろう。これら２つのポリシー間に重複が存在してよく、すなわち、コンプライアンスポリシーは、関連する規制、法律などの順守を容易にするために定義されてよいが、本明細書において開示されている主題における意図は、特に文脈から明確でない限り、システムによって定義されたポリシーに関連している。

【0029】

コンプライアンスポリシーは、
暗号化された規制情報をユーザのトランザクションのうちの１つまたは複数に関連付けることであって、規制情報が関連する規制エージェントによって復号可能である、関連付けることと、
１つまたは複数のトランザクションに関する情報を含んでいる報告を生成することと、
関連する規制情報を含む報告を暗号によって格納することとを実行するように、さらに構成されてよい。

【0030】

コンプライアンスポリシーは、疑わしい活動を構成する１つまたは複数の条件を定義してよく、コンプライアンスシステムは、１つまたは複数のトランザクションが定義された疑わしい活動を構成するということを決定するように構成される。コンプライアンスシステムは、報告の存在の知識が暗号化されるように、規制情報を含む報告を暗号によって格納するように構成されてよい。少なくともユーザは、規制情報を復号するための情報を使用することができなくてよい。以下では、コンプライアンスポリシーの実施例５（疑わしい活動の報告）として、非限定的な実施例が説明される。

【0031】

規制情報を関連付けること、および報告を生成することは、ユーザに関連付けられたウォレットによって実行されてよい。以下では、コンプライアンスポリシーの実施例１３（外国口座報告）として、非限定的な実施例が説明される。

【0032】

ストレージ位置は、デジタルアセットネットワークのパブリックな台帳であってよい。ＣＲＡＩをトランザクションに関連付けることは、ＣＲＡＩをトランザクションに添付することを含んでよい。

【0033】

ストレージ位置は、パブリックにアクセスできるサーバであってよく、デジタルアセットネットワークのパブリックな台帳に記録されたトランザクション情報は、ストレージ位置を参照する。

【0034】

ポリシーは、禁止されたトランザクションの１つまたは複数の属性を定義してよく、コンプライアンスシステムは、コンプライアンスポリシーによって禁止されていると見なされるトランザクションの実行を阻止するように構成される。以下では、コンプライアンスポリシーの実施例１４（阻止および制裁の施行）として、非限定的な実施例が説明される。

【0035】

ポリシーは、推論を必要とするトランザクションの１つまたは複数の属性を定義してよく、コンプライアンスポリシーは、トランザクションが推論をいつ必要とするかを識別し、推論の量を計算し、トランザクションを開始して、必要とされる推論の要求を満たすように構成される。以下では、コンプライアンスポリシーの実施例１１（納税）として、非限定的な実施例が説明される。

【0036】

コンプライアンスシステムは、デジタルアセットネットワークの機能を利用して、トランザクション情報に添付されたＣＲＡＩの妥当性をチェックし、それによって、コンプライアンスポリシーへのコンプライアンスを検証するように構成されてよい。

【0037】

コンプライアンスシステムは、コンプライアンスポリシーによって定義された複数のシールされたウォレットを備えてよく、シールされたウォレットは、要求されたトランザクションがコンプライアンスポリシーに従っているかどうかを判定するために、ＣＲＡＩに対して推論するように構成される。

【0038】

シールされたウォレットの少なくとも一部が、デジタルアセットネットワークに格納されたコードとして実装されてよい。

【0039】

コンプライアンスシステムは、１つまたは複数のトランザクションに関連付けられたＣＲＡＩに対して推論するようにさらに構成されてよい。

【0040】

ＣＲＡＩは、トランザクションがコンプライアンスポリシーに従うということの証明を含んでよい。

【0041】

ＣＲＡＩは、コンプライアンスポリシーへの要求されたトランザクションのコンプライアンスの決定に関連するコンプライアンス情報を含んでよい。

【0042】

コンプライアンス情報は、１つまたは複数の関係者の識別情報をトランザクションに関連付けてよい。

【0043】

コンプライアンス情報は、トランザクションの詳細に関連してよい。

【0044】

コンプライアンスシステムは、ユーザに対応する情報を検証することと、検証時に識別情報証明をユーザに発行することとを実行するように構成された識別情報プロバイダをさらに備えてよい。

【0045】

識別情報証明は、
ユーザの識別情報を含んでいるパブリックな構成要素、および／または
暗号鍵材料を含んでいるプライベートな構成要素を含んでよい。

【0046】

識別情報証明は、ＣＲＡＩの少なくとも一部を構成してよい。

【0047】

コンプライアンスシステムは、コンプライアンスポリシーに従ってＣＲＡＩを添付することによって、デジタルアセットネットワークに関連付けられたネイティブなアセットを拡張し、それによって、シールされたアセットを生成するように構成されてよい。

【0048】

コンプライアンスシステムは、シールされたアセットからＣＲＡＩを分離し、それによって、シールされたアセットからネイティブなアセットを抽出するように構成されてよい。

【0049】

コンプライアンスシステムは、互換性のあるコンプライアンスポリシーによって定義されたシールされたウォレットおよびシールされたアセットを含んでいる適合するプールを定義するようにさらに構成されてよい。

【0050】

コンプライアンスポリシーは、どのコンプライアンスポリシーが互換性があるかを定義してよい。

【0051】

コンプライアンスポリシーは、シールされたアセットが適合するプールから離れる条件を定義してよい。

【0052】

コンプライアンスシステムは、１つまたは複数の関係者を含んでいるトランザクションを防ぐようにさらに構成されてよい。

【0053】

ＣＲＡＩは、各トランザクションの第三者の検証を容易にするように構成された規制エスクローアクセスフィールドを含んでよい。

【0054】

コンプライアンスシステムは、トランザクションに関連するエンコードされた数学関数をトランザクションに添付するようにさらに構成されてよい。

【0055】

コンプライアンスシステムは、疑わしい活動に関して１つまたは複数のトランザクションを分析するようにさらに構成されてよい。

【0056】

ＣＲＡＩの少なくとも一部の暗号化が、ＣＲＡＩの内容を公開せずに、ＣＲＡＩの検証を容易にしてよい。

【0057】

この検証は、ゼロ知識証明を含んでよい。

【0058】

ＣＲＡＩの少なくとも一部の暗号化は、回復不可能であってよい。

【0059】

トランザクション情報は、トランザクションの送信者の暗号識別子、トランザクションの受信者の暗号識別子、およびトランザクションの詳細から成る群から選択された１つまたは複数を含んでよい。

【0060】

トランザクションは、通貨を移動することを含んでよい。

【0061】

通貨は、暗号通貨であってよい。

【0062】

コンプライアンスシステムは、２つ以上のコンプライアンスポリシーから選択された少なくとも１つのコンプライアンスポリシーに従ってデジタルアセットネットワーク上のトランザクションを管理するように構成されてよい。

【0063】

コンプライアンスシステムは、１つまたは複数のコンピュータプロセッサと、構成されたとおりに動作するようにシステムに指示するための実行可能な命令を格納しているメモリとを備えてよい。

【0064】

本明細書において開示されている主題をよりよく理解するため、および本主題を実際に実行する方法を例示するために、非限定的な単なる例として添付の図面を参照して、ここで実施形態が説明される。

【図面の簡単な説明】

【0065】

【図1】コンプライアンスシステム、および本明細書において開示されている主題に従ってトランザクションを管理するようにコンプライアンスシステムが構成されるデジタルアセットネットワークを示す図である。

【図2】図１に示されたコンプライアンスシステムによって定義されたシールされたアセットを示す図である。

【図3】複数の適合するプールおよびネイティブなアセットと通信する、図１に示されたコンプライアンスシステムのゲートウェイを示す図である。

【図4】図１に示されたコンプライアンスシステムの交換アセット認識サービスを示す図である。

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

【0066】

図１に示されているように、デジタルアセットネットワーク上のトランザクションを管理するように構成されたコンプライアンスシステムが提供されている。デジタルアセットネットワークは、パブリックな台帳へのトランザクションの記録を制御するルール（必ずしもコンプライアンスシステムによって定義されない）を施行するように構成される。コンプライアンスシステムは、コンプライアンスシステムが管理するトランザクションにおいて１つまたは複数のコンプライアンスポリシーを施行するように構成される。図１が、コンプライアンスシステムが実装され得る方法の単に１つの例を示しており、示された構成要素においても、構成要素間の関係においても、制限するよう意図されていないということが、理解されるであろう。

【0067】

コンプライアンスシステムは、シールされたアセットプラットフォーム（ＳＡＰ）を備えてよい。ＳＡＰは、以下の一部またはすべてを備えてよく、および／または以下の一部またはすべてと共に動作するように構成されてよい。
（１）ユーザがＳＡＰと情報をやりとりするのを容易にするように構成されたウォレットの実装。実施形態によれば、ウォレットの実装は、１つまたは複数のトランザクションの状態を発行すること、受信すること、および伝達することを容易にするために、ＳＡＰと通信するように構成されたソフトウェアアプリケーションである。ウォレットの実装は、通貨の支出を制御する暗号識別子を管理すること、およびユーザに属する識別認証情報を記録することを実行するように構成されてもよい。ウォレットの実装は、ローカルにまたはリモートに実行されてよく、および／あるいはハードウェアによって拡張されてよい。
（２）暗号通貨台帳を更新し、どのトランザクションが許可されるかを制御するためのルールを施行するように構成された合意システム。合意システムは、単一の集中型の機械を備えてよく、または合意システムは、独立した分散型システムのネットワークを備えてよい。合意システム例としては、ビットコインおよびイーサリアムの技術的プラットフォームが挙げられるが、これに限定されず、これらの技術的プラットフォームは、同意済みの合意ルールのセットによってトランザクションが制限される台帳を構築するために、ブロックチェーン技術を使用する。
（３）（下記の）シールされたアセットにおいて、トランザクションごとに、トランザクションが適合していると見なされるかどうか、およびしたがって、許可されるかどうか、ならびにトランザクションがどの情報を誰に公開しなければならないかを定義するルールのセットをそれぞれ含んでいる、１つまたは複数のコンプライアンスポリシー。
（４）ＳＡＰを使用してコンプライアンスポリシーを施行することができる仮想アセットを含んでいる、シールされたアセット。図２に示されているように、シールされたアセットは、既存の仮想アセットを含んでいるネイティブなアセットを含んでよく、ネイティブなアセットが、コンプライアンス関連補助情報（ＣＲＡＩ）を使用して、ＳＡＰによって拡張されており、それによって、ネイティブなアセットに関連するコンプライアンスポリシーの施行を容易にする。
（５）関連するコンプライアンスポリシーを満たす、１つまたは複数の台帳および１つまたは複数のシールされたアセットにわたるすべてのトランザクションのセットを含んでいる適合するプール。
（６）識別認証情報をシステム上のユーザに発行するように構成された識別情報プロバイダ（ＩＰ：identity provider）。ＳＡＰは、複数のＩＰを備えてよく、ＩＰの各々は、ユーザの識別情報を検証するための異なる手法を個別に使用する。識別認証情報は、発行されると、ユーザの識別情報に加えて、ユーザおよびユーザの口座に関する必要な情報の正しさを主張するデジタル文書になる。ＩＰは、ユーザの識別認証情報が発行された後の任意の時点で、ユーザの識別情報を検証するようにさらに構成されてよい。
（７）適合するプールに適用するコンプライアンスポリシーを決定することによって、新しい適合するプールの作成を容易にするように構成されたポリシー発行者。次に、コンプライアンスポリシーは、このプール内のどのアセットのトランザクションが実行され得るか、およびこれらのトランザクションがどのように機能するべきかを決定する。
（８）適合するプールへの、および適合するプールからのアセットの移動を許可するように構成されたゲートウェイ。この移動は、異なるコンプライアンスポリシー（例えば、法律上の管轄区域間で異なるポリシー）を持っている異なる適合するプール間のアセットの移動を含んでよい。こゲートウェイは、従来の暗号通貨アセットなどの、外部のソースからアセットが適合するプールに入ることを許可するゲートウェイを含んでもよい。
（９）アセットのＣＲＡＩに関する意味のある情報を維持しながら、シールされたアセットと情報をやりとりするために構成された、１つまたは複数のアセット認識サービス（ＡＡＳ：asset-aware services）。アセット認識サービスは、合意システムの内部および／または外部に存在してよい。アセット認識サービスは、集中型または分散型の、交換、混合、ブロックチェーン間通信システム、および／または他の適切なアプリケーションを含んでよい。

【0068】

上記の構成要素のうちの複数が、単一の機械内の同一の場所に配置されてよく、および／または単一のソフトウェアプログラムの機能として実装されてよい（例えば、識別情報プロバイダが、アセットを発行してもよく、および／またはウォレットの実装をエンドユーザとして使用してよい）。代替として、構成要素の役割が複数の関係者によって一緒に実行されるように、単一の構成要素が分散された方法で実装されてよい。

【0069】

ウォレットの実装およびシールされたウォレット
ウォレットの実装は、ＳＡＰと通信し、ユーザの代わりにトランザクションの動作を実行し、ＳＡＰの状態をユーザに伝達する、ソフトウェアおよび／またはハードウェアを含んでよい。

【0070】

ウォレットの実装は、各ユーザに関連付けられ、そのユーザによって所有されているアセットの支出を制御する、暗号識別子（すなわち、鍵）を管理するように構成されてもよい。ウォレットの実装は、各ユーザおよびユーザが関与しているトランザクションに関連付けられたＣＲＡＩを格納し、処理し、伝達してもよい。例えば、ウォレットの実装は、ユーザに属する識別認証情報を記録するように構成されてよい。

【0071】

異なるウォレットの実装が、（例えば、互換性のあるプロトコルに従うことによって）ＳＡＰの単一のインスタンスと通信してよく、したがって、相互運用可能である。ウォレットの実装は、例えば、自分自身の暗号識別子および認証情報をそれぞれ有する多数のユーザの役に立つように構成されてよい。

【0072】

ウォレットの実装のインスタンスは、特定のユーザに関連付けられた暗号識別子および認証情報と共に、シールされたウォレットを構成してよい。

【0073】

ウォレットの実装は、セキュアなデータ格納のために、または性能の加速のために、専用ハードウェアを利用してよい。ウォレットは、電話またはパーソナルコンピュータなどのユーザのローカルデバイス上で実行されてよく、またはウォレットは、例えば、インターネットを介してアクセスされているリモートサーバ上で（例えば、ＳａａＳ（Software as a Service）またはＩａａＳ（Infrastructure as a Service）を介して、何らかの関連する第三者のサービスの一部として、などで）実行されてよい。ウォレットの機能は、ローカルコンピュータ、リモートサーバ、およびハードウェアの間で分割されてよい（例えば、セキュリティのために秘密鍵および認証情報がローカルコンピュータまたはハードウェアに格納されてよく、応答性のためにユーザとの情報のやりとりがローカルコンピュータによって処理されてよく、効率のためにブロックチェーンとの同期がリモートサーバによって処理されてよい）。これらの構成要素のすべてが、関連するポリシーによって要求されたとおりに、ＣＲＡＩを伝達し、ＣＲＡＩに作用するように、拡張される。

【0074】

シールされたウォレットは、アセットを所有しているユーザによって操作され、制御されてよい。シールされたウォレットは、ウォレットサービスプロバイダ（ＷＳＰ：wallet service provider）を構成する別々の関係者によって操作され、制御されてもよい。これら２つのさまざまな組み合わせが可能である。例えば、
・保管ウォレットでは、ウォレットの実装は、アセット所有者と異なるＷＳＰによって完全に操作され、制御される（従来の銀行預金口座に類似している）。ＷＳＰは、関連する暗号識別子および認証情報を保持し、したがって、アセットの完全な技術的制御を保持する。ユーザは、ＷＳＰによって提供された何らかのインターフェイス（例えば、Ｗｅｂサイト）を介して、自分の代わりにアクションを実行するようにＷＳＰに指示することによって、自分の所有権を行使する。単一のＷＳＰは、多くの異なるユーザの役に立ってよく、ＷＳＰ自身のシールされたウォレット内で、単一の暗号識別子の下で、異なるユーザによって所有されているアセットを混合してよく、ユーザの預金の全額を保管に保持しなくてよい（すなわち、部分準備）。
・自己保管ウォレット（自己ホストウォレットまたはホストされないウォレットとも呼ばれる）では、ウォレットの実装は、アセットを所有しているユーザによって完全に操作され、制御される（例えば、従来の現金のウォレットに類似している）。ブロックチェーン台帳システムとの情報のやりとりのため（更新情報を受信するため、および完全に形成されてブロードキャストされる準備ができた状態でトランザクションをサブミットするため）以外に、外部の関係者への依存はない。詳細には、ユーザに属するプライベートな暗号識別子および認証情報が、このユーザによって操作されるソフトウェアおよびハードウェアにおいて格納される（従来のウォレット内にＩＤカードを持っていることに類似している）。

【0075】

保管ウォレットおよび自己保管ウォレットが２つの極端な事例を表しており、本明細書において開示されている主題の範囲から逸脱することなく、必要な変更を加えて、これらの各ウォレットの態様を組み合わせるさまざまな組み合わせが可能であるということが、理解されるであろう。例えば、ウォレットの実装は、自己保管ウォレットから開始し、次の能力のうちの１つまたは複数がＷＳＰに委任されるように変更されてよい。
・支出権限。すなわち、必要条件計算手順の実施と共に、資金の支出を可能にする、プライベートな暗号識別子の格納。
・認証情報権限。すなわち、認証情報を公開するための手順の実施と共に、ユーザに関連付けられ、ユーザの個人情報を証明する認証情報の格納。
・監視権限。すなわち、プライベートな暗号識別子の格納、またはユーザの取引相手であるＷＳＰがトランザクション（部分的または全体的に、受信者または送信者あるいはその両方として、一部またはすべてのトランザクション）を見ることを可能にする通信プロトコルの実施。
・検閲権限。すなわち、ＷＳＰを、ユーザがトランザクションを発行するのを阻止することができる隘路にする。および／または
・加速および台帳の追跡。すなわち、ユーザ自身のデバイス上で実施するには遅すぎるか、または高価すぎることがある計算動作の加速または分散型台帳の状態との同期などの、技術的構成要素の委任。

【0076】

ユーザからＷＳＰにすべての能力が委任された場合、結果として、ウォレットの実装が保管ウォレットになる。

【0077】

ウォレットの実装およびＷＳＰは、ＣＲＡＩを処理することにおいて、すなわち、一部の種類のＣＲＡＩの記録（例えば、トランザクション履歴）を生成し、維持すること、ＣＲＡＩに基づいて推論を実行すること、他者によって検証される、ＣＲＡＩに関する暗号クレーム（cryptographic claims）を生成すること、他者によって生成されたＣＲＡＩおよびＣＲＡＩに関する暗号クレームの妥当性をチェックすること、ならびに／またはＣＲＡＩをユーザおよび統合サービスとの間で伝達することにおいて、極めて重要な役割を果たすことができる。

【0078】

シールされたウォレットは、スマートコントラクト、すなわち、分散型台帳によって実行される自律的または半自律的コンピュータプログラムを含んでよい。そのようなスマートコントラクトは、スマートコントラクトがこれらのアセットのすべての移動および支出を制御するという意味で、アセットを所有してよい。例えば、スマートコントラクトは、マルチシグウォレット、分散型交換、自動マーケットメーカー、および／または分散型ローン貸し出しサービス（decentralized loan-making services）を含んでよい。スマートコントラクトは、任意の他のシールされたウォレットの場合と同様に、ポリシーによって施行されたＣＲＡＩをウォレットに添付し、インバウンドトランザクションおよびアウトバウンドトランザクションに、ポリシーの施行を受けさせることによって、シールされたウォレットとして設計されてよい。ポリシーは、そのようなシールされたウォレットに固有のルール（例えば、ウォレットに関連付けられたＣＲＡＩがスマートコントラクトを開始した関係者を識別することを要求するルール）を含んでよい。

【0079】

識別情報プロバイダ（ＩＰ）
識別情報プロバイダは、識別情報証明をエンドユーザに発行するために構成される。最も一般的な形態では、ＩＰの役割は、（１）各ユーザに対応する識別情報を検証すること、および（２）識別情報証明と呼ばれる暗号証明をユーザに発行することである。次に、ユーザは、結果として得られた証明をＣＲＡＩとしてシールされたウォレットに組み込み、その後、適用可能なコンプライアンスポリシーによって指示されたとおりに、そのＣＲＡＩ（またはＣＲＡＩの内容の証明）をトランザクション内で提示してよい。

【0080】

識別情報プロバイダは、デジタル署名アルゴリズムの公開鍵などの、１つまたは複数のパブリックな暗号識別子によって識別されてよい。次に、これらの識別子は、暗号によって識別情報証明に結び付けられ、識別情報証明は、ユーザの識別情報に関する情報を機械可読の形態で閉じ込める認証された暗号データ構造である。識別情報証明は、一部のインスタンス化において、（１）ユーザの識別情報を埋め込むパブリックな構成要素（またはその圧縮された暗号表現）、および（２）暗号鍵材料を含む秘密の（すなわち、プライベートな）構成要素のうちの１つまたは両方で構成されてよい。識別情報証明は、識別情報プロバイダが他の識別情報プロバイダの識別情報を認証することができ、次に、エンドユーザの識別情報を認証することができるという点において、標準的な公開鍵基盤（ＰＫＩ：Public Key Infrastructure）証明と同様に機能する。各証明は、定義された妥当性期間を埋め込んでよく、ＩＰが、悪用されたか、または盗まれた証明を取り消すことができるようにする、メカニズムを含んでよい。

【0081】

シールされたアセットの発行者は、特定のアセットに対する識別情報サービスを提供するための１つまたは複数のＩＰを選択してよい。このリストは、アセットが発行される時点で明示的に指定されることが可能であり、またはこのリストは、時間と共に更新されてよい。適合するプール内のトランザクションを作成することに参加するには、少なくとも、許可されたＩＰのうちの１つまたは複数からの有効な識別情報証明を使用して、シールされたウォレットが準備されなければならない。例えば、下で説明されているように、どのＩＰが所与のアセットを含むトランザクションに必要とされるかを指定するために、所与のアセットのコンプライアンスポリシーが使用される。

【0082】

ＩＰによって発行された識別情報証明は、適用可能なコンプライアンスポリシーによって必要とされるか、または許可される属性を含む。例えば、これらの属性は、以下から選択された１つまたは複数を含んでよいが、これらに限定されない。
（１）所有者の名前、実体の種類（個人／企業）、国籍、自宅の住所、生年月日、国民識別子、旅券番号、納税者番号（tax identifies）、運転免許証番号、連絡先の詳細などの、基本的な「ノーユアカスタマー」情報。
（２）所有者の生体測定情報。
（３）これらのウォレットにおいてトランザクションを実行することが許可された関係者（所有者と異なってよい）に関する（例えば、上記のとおりの）情報。
（４）金融機関、仮想アセットサービスプロバイダ、保管サービスなどとしての、ウォレット所有者の識別情報。
（５）ソーシャルネットワークのユーザ名、民間企業（金融機関を含む）での顧客口座、従業員データベース、（ブロックチェーンに基づくか、または他の方法での）自己主権型識別情報ネットワーク（self-sovereign identity networks）、インターネットドメイン名の所有権などの、他のプラットフォーム上の口座またはデジタル識別情報とのウォレットの所有者の関係。この関連付けは、直接的に、またはＫｅｙｂａｓｅなどの識別情報リンクサービスを介して間接的に実行されてよい。および／または
（６）例えば、ウォレットのリスクスコアの、ＩＰ自身のＫＹＣ／ＡＭＬリスクベースポリシーに基づく、ＩＰによる評価。

【0083】

これらの属性の一部が極めて重要なプライバシーであることがあり、したがって無差別に公開されるべきではないということが、理解されるであろう。関連するコンプライアンスポリシーは、どの属性がどの条件の下で誰に公開されるかを指示してよい。ＳＡＰは、このポリシーの施行を容易にするように構成された暗号プロトコルを含んでよい。

【0084】

識別情報証明は、例えば、以下を含むが、これらに限定されない、顧客の適正評価プロセスおよび／または拡張された適正評価プロセスの過程で取得された情報をさらに含んでよい。
（１）第三者のプロバイダを介して、またはパブリックな検索を介して取得された顧客のトランザクションプロファイルと一致する、裏付けとなる活動情報。
（２）顧客のＩＰアドレス。
（３）ブロックチェーン分析の使用によって取得された情報。
（４）トランザクションが実行される商品の性質、最終使用、またはエンドユーザ、およびトランザクションの目的に関する詳細。
（５）資金の所有権および／または財産もしくは資金の源の証明。
（６）取引相手の識別情報および受益所有権。
（７）輸出管理情報ならびに／あるいは他の免許および／または証明。
（８）トランザクションの発信元または受益者に関連する他の識別情報。および／または
（９）顧客またはその取引相手のＶＡＳＰがその顧客から取得した、他の顧客情報、トランザクション履歴、および追加のトランザクションデータ。

【0085】

加えて、ＣＲＡＩの一部を構成する識別情報証明および他の情報は、例えば規制上の要件に従って、識別情報の検証および認証の目的で、および／または進行中の適正評価のために、既存の記録の再調査を受けること、および情報を使用可能になった新しいデータと照合することによって、ときどき修正および更新されてよい。

【0086】

識別情報証明は、ＶＡＳＰが以下を実行することを容易にしてよい。
（１）ＶＡＳＰが、仮想アセットの移動のために、取引相手のＶＡＳＰを特定することを可能にする。
（２）分散型プラットフォーム上の仮想アセットの移動が実施されるときに直ちに、必要とされる正確な発信元および必要とされる受益者の情報のサブミットを可能にする。
（３）ＶＡＳＰが、実質的に安定した方法で、かなり多くの量のトランザクションを複数の送信先にサブミットすることを可能にする。
（４）ＣＲＡＩを使用する記録維持を容易にするために、ＶＡＳＰが、データを安全に送信すること、すなわち、必要とされる情報の完全性および可用性を保護することを可能にする。
（５）受信側のＶＡＳＰまたは他の義務付けられた実体によって、そのようなＣＲＡＩの使用を保護することに加えて、国のプライバシー保護法およびデータ保護法と一致して、許可されていない開示からＣＲＡＩを保護する。
（６）取引相手のＶＡＳＰに対する適正評価の目的で、取引相手のＶＡＳＰとのフォローアップをさらにサポートするために、ＶＡＳＰに通信チャネルを提供する。および／または
（７）トランザクションが高リスクを伴っているか、または禁止されているどうかを判定するために、特定のトランザクションに関する情報を要求する選択肢を容易にする。

【0087】

下で説明されるように、コンプライアンスシステムは、ＩＰが上記の一部またはすべてを実現するのを容易にするように構成された識別情報伝達システムを備えてよい。

【0088】

アセット認識サービス（ＡＡＳ）
シールされたアセットは、通常、２つの状態のうちの１つで存在する。アセットの通常の状態では、アセットは、適合するプール内に存在する。アセットは、適合するプール内にある間、アセットのコンプライアンスポリシーによって許可されたとおりに、ウォレット間で送信され得る。しかし、一部のアプリケーションは、単純な全体的に施行されるポリシーによって完全にエンコードされ得ない、さらに複雑な金融取引を必要とする。

【0089】

そのようなアプリケーションの例は、複数ユーザからアセットを受信し、混合するサービスである。この特徴を持つサービスは、アセットの交換（集中型であるか分散型であるかにかかわらない）、多くの分散型金融アプリケーション、コイン混合ネットワーク、保管ソリューションなどを含む。例えば、アセットの交換では、複数のユーザがアセットを交換システムの制御に送信し、交換システムが複数のユーザのアセットを同じウォレット内で混合してよく、次にユーザは、取引を実施して、（同様に混合されたウォレット内に保持されている）異なるアセットを取得し、最終的に、さまざまなアセットを交換から引き出す。

【0090】

したがって、アセット認識サービス（ＡＡＳ）は、アセットの基本的なコンプライアンスポリシーによって可能にされる方法よりも複雑な方法で、１つまたは複数のシールされたアセットを処理する（例えば、送信する、受信する、および情報をやりとりする）ために構成される。ＡＡＳは、異なるエンドユーザからの通貨を送信すること、受信すること、または一緒に混合することも許可される。ＡＡＳは、ＣＲＡＩ情報が、サービスから出て適合するプールに入るすべてのアセットに正しく反映されることを保証する役割を担う。ＡＡＳは、ＡＡＳが利用できる追加情報を使用して、トランザクションのＣＲＡＩを拡張してもよく、この追加情報は、他の方法では、前のＣＲＡＩおよびトランザクション履歴から推論できないことがある。したがって、交換内のアセットがサービスのユーザに属している場合、それらのアセットがサービスに入り、サービスから離れるときに常に、およびそれらのアセットが交換内の他のアセットと交換されるときに常に、それらのアセットのＣＲＡＩは、この所有権状態を反映してよい。この反映は、サービスによってサポートされるアプリケーションに固有の論理を必要とすることがある。

【0091】

シールされたアセットコンプライアンスポリシーは、さまざまな方法でＡＡＳをサポートしてよく、それらの方法のすべては、一部のＡＡＳが、他の方法ではコンプライアンスポリシーによって許可されないことがあるトランザクションを実行すること、またはＣＲＡＩを伝達することを許可する。例えば、
（１）コンプライアンスポリシーは、ＡＡＳ関係者の「許可リスト」を含んでよい。これらの関係者は、内部で流れる資金に関してユーザのＣＲＡＩを追跡し、アウトバウンドトランザクションで伝達することが許可され、したがって信頼される。
（２）コンプライアンスポリシーは、ＣＲＡＩがプロトコル内を流れるときに、特定のプロトコル（すなわち、分散アルゴリズム）がＣＲＡＩを機械的に追跡することを許可してよい。例えば、ミックスネットシステムは、不正な盗聴者を含む一般人によって観察されるように、ミックスネットのプライバシーの目標を達成するが、許可された法執行機関によるフォレンジック調査を可能にする方法で、混合されたトランザクションと共に、暗号によってＣＲＡＩを伝達するように拡張され得る。具体的には、スマートコントラクトをサポートするブロックチェーンプラットフォームに適用された場合、この拡張は、スマートコントラクトを作成することによって実現されてよく、スマートコントラクトは、プロトコル（またはプロトコルの関連する一部）を実施し、スマートコントラクトを通るアセットに関してＣＲＡＩの追跡を実行し、ＣＲＡＩの追跡が正しく健全であることを保証するために再調査されている。次に、スマートコントラクトのアドレスがポリシー内のＡＡＳの許可リストに追加されてよい。同様に、ビットコインのＬｉｇｈｔｎｉｎｇ Ｎｅｔｗｏｒｋ、またはＢｏｌｔプロトコルに基づくＢｏｌｔ ＬａｂｓのｚｋＣｈａｎｎｅｌｓなどの、仮想アセットのための「レイヤー２」のアセット移動プロトコルも、基礎になる（「レイヤー１」の）分散型台帳を経由してアセットを移動するメカニズムではなく、アセットの真の所有権を反映するＣＲＡＩを伝達するように、プロトコルレベルで拡張され得る。同様に、ロールアップシステムは、例えば下で説明されるように、ＣＲＡＩを伝達するように拡張され得る。
（３）前述のＡＡＳの許可リストは、ポリシーに直接埋め込まれてよく、および／または暗号手段（例えば、デジタル署名）を使用して、規制機関などの外部の関係者に委任されてよい。例えば、ポリシーは、何らかの第三者のサービスの暗号識別子を含んでよく、第三者のサービス自体が、十分に定義された位置で、許可されたＡＡＳの公開鍵のリストを公開する。これによって、許可されたＡＡＳのリストが時間と共に変化できるようにする（これは、繰り返されてよい。例えば、ポリシーは、権限を関係者に暗号によって委任してよく、次にこの関係者は、ＡＡＳを指名するための権限を１つまたは複数の別の関係者に委任することが許可される。同様に、そのような権限は、マルチシグまたはしきい値暗号などの十分に理解された技術を使用して、複数の関係者のグループ内で分散され得る）。同じメカニズムは、例えば、特定のＡＡＳが不正アクセスされたか、またはＣＲＡＩを正しく生成できない場合に、ＡＡＳの権限が取り消されることを可能にしてよい。
（４）ＡＡＳは、特定の挙動境界内で動作することが許可されてよい。例えば、コンプライアンスポリシーは、ＡＡＳによってサポートされ得る活動の種類を定義するパラメータの特定のセットを埋め込んでよい。これらのパラメータは、ある種類の活動に対する制約（例えば、許可されたトランザクションのアドレス、交換される総資金、およびサポートされるアセットの種類に対する制約）を指定してよい。具体的な例として、ＡＡＳは、一部のプール（例えば、適合するプール）間のゲートウェイサービスの役割を果たすことが許可されてよいが、他のプール間では許可されなくてよい。

【0092】

コンプライアンスポリシーは、次のような方法で、アセットおよびウォレットに基づいて、ＡＡＳに、デフォルトのＣＲＡＩの伝搬を無効にするための柔軟性を与えてよい。
（１）ＡＡＳオペレータによって所有されている１つのウォレット内で混合されているアセットを、１つまたは複数の他のユーザのウォレットの代わりに保管されているとして識別する。それに応じて、実際の所有者に対応するＣＲＡＩ（実際の所有者の元のウォレットおよびトランザクション履歴など）を伝搬する。したがって、混合されたウォレットからアセットが引き出されるときに、それらのアセットは、単に、アセットを保管していたＡＡＳオペレータのＣＲＡＩではなく、実際のユーザのウォレットのＣＲＡＩを持っている。
（２）１つのシールされたアセットでの通貨建てのアセットを、前の異なるシールされたアセットの取引または交換から生じているとして識別する。それに応じて、前のアセットに対応するＣＲＡＩ（前のアセットの元のウォレットおよびトランザクション履歴など）を伝搬する。
（３）上記を部分準備の事例に拡大し、部分準備では、保管機関のウォレットが、ユーザによって保管機関を使用して保管に入れられた総資金より少ない資金を保持してよい。したがって、保管機関のＡＡＳは、１人または複数のユーザから保管機関自身のウォレットに預金を受け取り、これらのアセットの一部を保管機関自身の目的のために（例えば、有利子ローンを貸し出すために）引き出し、一部のアセットを保管機関のウォレットに再び預金し、最後に、ユーザがアセットを保管機関のウォレットから引き出すことを許可してよい。ＡＡＳは、中間ステップで無関係なアセットを除去し、経済的に関連するトランザクション（この場合、ユーザの預金および引き出し）のみをＣＲＡＩに含めるように構成されてよい。

【0093】

ＡＡＳは、例えば、コンプライアンスポリシーによって許可された場合に、関連するトランザクションおよびウォレットのＣＲＡＩに追加情報を追加するようにさらに、構成されてよい。例えば、交換ＡＡＳは、取引中の交換レートおよび市場状況に関する情報を使用してトランザクションに注釈を付けてよい。

【0094】

データプラットフォーム
多くの場合、コンプライアンス対応の暗号通貨システムは、システム上で発生するトランザクションに関する集計データまたは統計値の収集および配布を必要とすることがある。このデータは、例えば、１つまたは複数のシールされたアセットのトランザクションの量および流れに関する統計情報、アセットの交換価格情報（そのような情報が使用可能である場合）、およびＡＡＳによって生成され得る他のデータ（例えば、交換取引の量）を含んでよい。統計値は、特定のユーザのウォレットの活動に固有であってもよい（例えば、そのユーザの活動に基づく「リスクスコア」の計算）。これらの統計値は、ポリシーによって指示されたウォレットの属性によってさらに分類されてよく、「銀行によって所有されているとマーク付けされウォレット内に保持される総資金」または「自己保管されているとしてタグ付けされたウォレットから、交換によって所有されているとしてタグ付けされたウォレットへの、毎日の総流量」などの統計値を可能にする。

【0095】

この集計データの収集は、２つの目的の役に立つ。第一に、ＳＡＰが、個別の取引者のプライバシーを最大限に同時に保護しながら、システムの現在の状態に関する集計情報を顧客および／または規制機関に提供することを容易にすることができる。この情報は、顧客および／または規制機関が傾向を検出して対応することを可能にする。

【0096】

第二に、そのような集計データを必要とするコンプライアンスポリシーに情報を提供することを容易にすることができる。例えば、コンプライアンスポリシーは、（総量と比較してより大きいトランザクションが、市場操作の指標になることがあるため）そのアセットにおける全体的なトランザクション量などのコンテキスト情報に基づいて、疑わしい活動の報告（ＳＡＲ：Suspicious Activity Reports）を発行することを必要とすることがある。そのようなポリシーを可能にするために、データプラットフォームは、必要なデータを、認証された形態で、「データオラクル（data oracles）」を介して、ネットワーク上の参加者に公開することができる。これらは、そのようなデータの（台帳上または台帳以外での）公開を可能にする特殊なシステムである。これらのデータオラクルを介して公開されたデータ値は、特定のコンプライアンスポリシーへの入力として使用され得る。

【0097】

ＳＡＲという用語が、本明細書において使用されるとき、例えば、米国内で規制の対象になる報告（例えば、「現金取引報告（ＣＴＲ：Cash Transaction Reports）」義務など）を含む、さまざまな管轄区域および組織内の施行された報告のすべての形態を含んでよいということが、理解されるであろう。

【0098】

データプラットフォームは、次の構成要素を備えてよい。（１）ネットワーク上で発生するトランザクションに関する統計情報を収集して集計する役割を担う１つまたは複数のノード（分散型サーバであるか集中型サーバであるかにかかわらない）で構成されるプライバシー保護データ収集アーキテクチャ、（２）参加者が統計データを取得し、ネットワークの状態に関する照会を行うためのアプリケーションプログラミングインターフェイス（ＡＰＩ：Application Programming Interface）、（３）ネットワーク内の参加者によって使用するためにデータを公開するデータ「オラクル」のセット、および（４）人間が読める要約を許可された関係者に伝達するデータダッシュボード。

【0099】

データプラットフォームは、プライバシー保護技術を使用して個別の取引者から情報を収集するように設計される。

【0100】

データプラットフォームは、データの可視性を特定の関係者（例えば、組織、組織内の部署、または役割）に制限するデータアクセス制御メカニズムを備えてよい。コンプライアンスポリシーによって、および／または組織内のポリシーによって、アクセスポリシーが指定されてよい。例えば、コンプライアンスポリシーは、規制機関が特定のトランザクション内のウォレット所有者識別情報に対するアクセス権限を持つということを指定してよく、規制機関の内部のポリシーは、トランザクションの所有者の住所が特定の地区内にある場合にのみ、または調査員のマネージャからの承認が得られた場合にのみ、特定の調査員がこの情報にアクセスできるということを指定してよい。この複合ポリシーは、データプラットフォームによって施行される。

【0101】

ゲートウェイ
ゲートウェイは、１つの適合するプールから別の適合するプールへのアセットの移動を容易にするように、あるいはネイティブなアセットが適合するプールに入るか、または適合するプールから出ることを可能にするように、構成される。ゲートウェイは、プールに関連付けられたコンプライアンスポリシーによってアセットに課された制限に対する組み込みの「例外」を表すという意味で、ＡＡＳに類似している（実際に、ゲートウェイは特殊なＡＡＳと見なされ得る）。例えば、図３に示されているように、単一のゲートウェイが、アセットが複数の適合するプールとネイティブなアセットの間を移行することを可能にしてよい。

【0102】

各適合するプールに関連付けられたコンプライアンスポリシーによって、許可されたゲートウェイの識別情報が決定されてよい。この指定は、ポリシー内の各ゲートウェイプロバイダの正確な暗号識別情報（例えば、公開鍵）を識別することによって、またはコンプライアンスポリシーを変更せずに新しいゲートウェイを許可するために、コンプライアンスポリシーにおいてさらに複雑なメカニズムを指定することによって、実行され得る。

【0103】

コンプライアンスポリシー
各シールされたアセットは、１つまたは複数のコンプライアンスポリシーに関連付けられる。コンプライアンスポリシーは、どの条件の下で適合するプール内のトランザクションが許可されるかを決定する機械可読のルールのセットを含む。コンプライアンスポリシーは、適合するプール内でシールされたアセットのトランザクションが実行される方法の以下の態様から選択された１つまたは複数を施行してよい。
・どのアセットが、適合するプール内でトランザクションを実行することが許可されてよいか。
・どの識別情報プロバイダが、識別情報証明を、アセットを含むトランザクションを実行するユーザに発行しなければならないか、およびユーザの識別情報に対してどの条件が施行されなければならないか。
・アセットによってどのアセット認識サービスおよびゲートウェイがサポートされるか。
・すべてのウォレットおよびトランザクションに関連付けられたＣＲＡＩからのどの情報が、どの条件の下で、どの関係者に公開されるか。
・すべてのトランザクション、ウォレット、および各ＣＲＡＩに依存してよい、どの集計情報が、どの条件の下で、どの関係者に公開されるか。および／または
・十分に定義された位置で公開された、トランザクションデータ、識別情報データ、プライベートなデータ、およびパブリックなデータに対して施行され得る、任意の他の制限。

【0104】

コンプライアンスポリシーの性質
コンプライアンスポリシーは、トランザクションが許可されるべきかどうかを判定するために、コンピュータシステムによって評価され得るルールのセットを含む。コンプライアンスポリシーは、疑わしい活動の報告（ＳＡＲ）の公開、またはデータプラットフォームによって使用するための統計データの生成などの、トランザクションの試みによって引き起こされる「副作用」のセットを指定してもよい。標準的な実施形態では、これらのルールは、トランザクションに関連するさまざまなデータを取り込み、このデータに対して推論し、トランザクションを承認するか、または許可しない決定に加えて、台帳に対して送信され得る何らかの出力データを出力する、コンピュータプログラムまたは論理回路の形態で表される。

【0105】

ポリシー発行者は、各新しいシールされたアセット内でデフォルトで使用されるコンプライアンスポリシー（または複数のポリシー）を選択する（複数のポリシーの集合が、複数のポリシーを結合する単一のポリシーを指定することによって実装されてよく、したがって本開示では、「ポリシー」が、ポリシーの任意のそのような集合および／または単一のポリシーを明示的に含むということが、理解されるであろう）。複数のポリシーが使用される場合、アセット発行者は、異なるポリシーが相互作用する方法、例えば、すべてのポリシーが同時に満たされなければならないかどうか、または１つもしくはサブセットのみが満たされなければならないかどうかを指定しなければならない。

【0106】

ポリシー発行者の例は、自治業界団体、企業、非営利組織および／または非営利組織のコンソーシアム、中央銀行、規制機関、法執行機関、規制される実体、ならびに個人を含むが、これらに限定されない。ポリシーは、世界的規模、特定の管轄区域、特定の組織、特定の個人、および／またはこれらの任意のグループに適用できる要件を反映してよい。ＳＡＰは、特定の関係者によって、関係者の何らかの指定されたセットによって、または許可なしで、すなわち任意の関係者によって、ポリシーが発行されることを可能にするように構成されてよい。

【0107】

ＳＡＰは、上記のいずれかによって、何らかの指定された関係者によって、または関係者の何らかの指定されたグループによって、ポリシーが発行され、修正されることを可能にするように構成されてよい。

【0108】

複数のポリシーは、同じシールされたアセットに関して、実質的に同時であってよい。異なるシールされたアセットは、同じコンプライアンスポリシーまたは異なるシールされたアセットのコンプライアンスポリシーの一部を共有してよい。アセットは、他のアセットと異なる固有のポリシーを使用してもよい。

【0109】

ポリシーの入力
コンプライアンスポリシーは、トランザクションを許可するか、または許可しない決定に達するために、本システムによって使用可能にされたデータソースのセットの大きい多様なセットに対して推論してよい。これらの入力は、以下のデータソースから選択された１つまたは複数から派生してよい。
・トランザクションの入力。すなわち、トランザクションの目的、トランザクションが実行される量および通貨、送信者および受信者の住所、ならびにトランザクションの時間などの、トランザクション自体に関連する情報。
・トランザクションに隣接するデータ。すなわち、合意システムによって認識される形態で表されるときにトランザクションに埋め込まれる追加の補助データフィールド。これらのデータフィールドは、ネットワーク上の参加者が見ることができる非構造化データフィールド（既存の通貨にすでに存在するメモフィールドなど）に加えて、合意システムによって理解される意味を持つ構造化フィールドを含むことができる。
・識別情報プロバイダによって許可された、（送信者または受信者に属する）シールされたウォレットに提供された１つまたは複数の識別認証情報からのデータ。これらの識別認証情報からのさまざまな情報は、コンプライアンスポリシーへの入力として使用され得る。
・信頼できる関係者（「オラクル」として知られている）によってブロードキャストされたパブリックな「オラクル」データ。このデータは、合意システムまたは何らかの他のチャネルを介して公開されてよく、通常は、発行している関係者によって、暗号によって認証される。このパブリックなデータの例は、アセット価格データを含んでよい。および／または
・トランザクションが台帳に追加された時点での時間または台帳の長さ、あるいは台帳に存在する他の情報などの、合意システムのデータ。

【0110】

上記のリストは網羅的ではない。原理的には、コンプライアンスポリシーは、トランザクションが作成されたか、または合意システムの台帳に追加された時点で使用できる、任意のデータに対して推論してよい。

【0111】

ポリシーおよびデータの機密性
コンプライアンス対応のシールされたアセットの設計のための２つの重要な条件は、プライバシー（機密性）および健全性である。最初の条件は、コンプライアンスポリシーが満たされていることを検証するために機密情報が必要とされる場合でも、トランザクションが機密情報を許可されていない参加者に漏らすべきではないということを要求する。台帳上のトランザクションの正しさの妥当性を確認するタスクが、多くの場合、信頼できないボランティアの責任になるパブリックな合意システムでは、このプライバシー要件は特に重要である。健全性は、合意システムの参加者および第三者が、ポリシー評価への入力のすべてを見ることができない場合でも、トランザクションがコンプライアンスポリシーを実際に満たすということを確信しなければならないということを意味する。

【0112】

これらの要件における明らかな矛盾が、暗号の使用によって解決される。特に、これには、ゼロ知識証明およびマルチパーティ計算などのプライバシー保護技術を使用してコンプライアンスポリシーの正しい評価が施行されなければならないということが必要になる。

【0113】

入力／出力プライバシー
機密性を実現するために、各コンプライアンスポリシーは、どの入力および出力が機密であるかに関する情報を含んでよく、すなわち、トランザクションを実施するために必要とされる入力および必要とされる副作用出力を指定してよく、加えて、入力データおよび出力データの各々に関連付けられた機密性要件を指示する機密性ラベル付けスキーマ（confidentiality labeling schema）を採用する。このラベル付けは、「完全に機密」（その場合、他の関係者は、入力／出力に関するデータを使用できない）から、「完全にパブリック」（その場合、台帳上のトランザクションを観察する任意の関係者が、データを完全に使用できる）までの範囲にわたる、複数の分類をサポートする。多くの中間分類もサポートされる。例えば、ポリシーは、特定の関係者（例えば、規制機関または銀行）のみが特定のトランザクションの入力／出力を見ることができるということを指定してよい。ポリシーは、集計統計データ収集を実施するために特定のトランザクションの入力／出力が使用され得るということを指定してもよい。機密性ラベル付けスキーマのさらに完全な説明が、後のセクションで与えられる。

【0114】

トランザクションのポリシーへのほとんどの入力は、トランザクションを生成するウォレットによって知られているが、このルールには例外がある。例えば、ポリシーは、疑わしい活動の報告を生成するための警告されたアドレスまたは条件のリストを含んでよい。

【0115】

アセット認識サービス（ＡＡＳ）
前述したように、アセット認識サービスはコンプライアンスポリシーの例外を表し、アセット認識サービスでは、指定された外部の関係者または指定されたプロトコルおよびスマートコントラクトに、ＣＲＡＩを正確に伝達するか、または挙動を施行するための裁量が与えられる。

【実施例】

【0116】

コンプライアンスポリシー
以下では、コンプライアンスポリシーの実施例が提示される。これらの実施例が単に例示であり、ＳＡＰがこれらによって制限されないということが理解されるであろう。単一のコンプライアンスポリシーが、必要な変更を加えて、以下で与えられる１つまたは複数の実施例の要素を含んでよいということが、さらに理解されるであろう。

【0117】

[実施例１]
規制閉鎖
一部の実施例によれば、コンプライアンスポリシーは、適合するプール内のすべての資金が、ウォレット間を移行するときに、このプールに関連付けられたままであることを単に保証し、（特に、ポリシーによって許可される場合を除いて）資金が他のプールに移動できないということを保証する。規制閉鎖ポリシーは、複数の条件を保証するコンプライアンスポリシーを指定することによって施行されてよい。各トランザクションは、特定の適合するプールの識別子をトランザクションの内容に暗号によって結び付けなければならず、各シールされたウォレットも、プール識別子をウォレットに格納されたすべての資金に結び付けなければならない（プール識別子は、ポリシープログラムの暗号ハッシュまたはネットワークによって特定のポリシーに一意に結び付けられた識別子を含んでよい。そのような識別子は、平文フィールドとしてトランザクション内に含まれてよく、または後のセクションで説明されるさまざまな技術的手段を使用してトランザクションに暗号によって結び付けられてよい。どの資金が各識別子に属しているかを示すために、資金がウォレット内で分離されているということを条件として、シールされたウォレットが複数のプール識別子に結び付けられてよい）。

【0118】

ポリシー自体が、次の条件を施行する。（１）シールされたウォレットによって受信されたすべてのトランザクションが、ウォレット内にも含まれている特定のプール識別子に関連付けられなければならない、（２）ウォレットによって保持されているすべての資金が、それらの資金が受信されたトランザクション内に含まれているプール識別子に関連付けられなければならない、（３）ウォレットによって送信されたすべてのトランザクションが、ウォレット内でそれらのトランザクションが関連付けられたプール識別子を埋め込まなければならない。このアイデアのさらなる拡張は、特定のウォレットのみが特定のプール内でトランザクションを実行することを許可することであり、これは、例えば、１つまたは複数のプール識別子をウォレットの識別情報証明に結び付け、適切な証明が送信側ウォレットおよび／または受信側ウォレットに存在することを要求することによって、実現されてよい。

【0119】

ときには、例えば資金が異なる規制管轄区域間を移行するときに、１つの適合するプール内の資金が異なる適合するプールに移行することを許可することが、必要になることがある。この移行は、資金がプール間を移行することを許可するための特定の例外をコンプライアンスポリシーに作成することによって許可されてよい。しかし、そのような例外は、ポリシーが開発される時点で知られていないことがあり、コンテキストに依存する特定の制限を受けることがある。これらの問題は、ゲートウェイが資金の移動を許可することを許可することによって対処される。この場合、コンプライアンスポリシーは、次の２つの異なる方法でゲートウェイを許可することができる。（１）保管ソリューションでは、各ポリシーが、ポリシー制限を回避し、出ていく資金に関連付けられたプール識別子を変更することが許可された、特定の送信者の「許可リスト」を指定することができる。このモデルでは、最初に資金をゲートウェイに送信し、その後、ポリシーが資金を異なるプールに前方へ送信することを許可することによって、資金がプール間を移行され得る。代替として、（２）非保管ソリューションでは、ポリシープログラムが、回避証明（すなわち、ポリシーにおいて識別されたゲートウェイの鍵によって署名された暗号メッセージ）を含んでいる追加のポリシー入力を必要としてよい。回避証明は、特定の許可されたトランザクションがポリシー制限を回避してよいということを示すことができる。２番目のソリューションの利点は、ゲートウェイがいずれかの資金に対する保管制御を獲得しないということである。

【0120】

[実施例２]
規制エスクロー
規制エスクローシステムは、特定の関係者のみが読むことができる形態でエンコードされて、台帳に記録された各トランザクション内の追加情報を格納する。この情報は、（例えば、台帳がプライバシー機能を提供する場合に一般的であるように）台帳上で読み取り可能な形態で使用できないトランザクションに関する詳細、または通常はトランザクションに含まれない、ＫＹＣ識別情報などの他の情報を含んでよい。

【0121】

規制エスクローシステムをサポートすることは、各トランザクションが規制エスクローアクセスフィールド（ＲＥＡＦ：Regulatory Escrow Access Field）と呼ばれる特殊なデータフィールドを含むことを必要とする。実際には、ＲＥＡＦは、規制エスクロー機関と呼ばれる特定の受信者または受信者のセットのみによって復号できる暗号化されたコンテナである。適切なエスクロー機関の非限定的な例としては、政府規制機関、第三者のコンプライアンス会社（compliance firms）、または銀行が挙げられる。

【0122】

規制エスクローが意味あるように施行されるためには、シールされたプール内の各トランザクションが、正しい関連する情報を埋め込む添付されたか、または関連付けられたＲＥＡＦを含まなければならない。コンプライアンスポリシーによって、ＲＥＡＦの存在および正しさが施行される。さらに具体的には、コンプライアンスポリシーは、（１）各トランザクションが正しく書式設定されたＲＥＡＦを含まなければならないこと、（２）ＲＥＡＦが、ポリシーによって指定された規制エスクローエージェントの鍵に従って有効な暗号化を表さなければならないこと、および（３）ＲＥＡＦが、このトランザクションの情報の適切な集合を含まなければならないことを保証する。ＲＥＡＦ自体は、適切なエスクロー関係者の公開鍵に従って関連するトランザクションデータを暗号化する公開鍵暗号化方式を使用して構築され得る。コンプライアンスポリシーによって、ＲＥＡＦ暗号文内に埋め込まれた平文が指定されてよい。この指定は、上記の基準を満たす任意のコンプライアンスポリシーによってサポートされ、すなわちコンプライアンスポリシーは、トランザクションに隣接する情報（トランザクションに添付されたＲＥＡＦ暗号文など）および他のトランザクション入力に対して推論することができる。ＲＥＡＦの内容および受信者は、ポリシーによって固定されてよく、またはポリシーは、特定のトランザクションの性質に基づいて異なる情報および受信者を指示してよい。

【0123】

[実施例３]
送信者および受信者拒否リスト
場合によっては、規制機関および銀行は、一時的または永続的のいずれかで、トランザクションを送信することまたは受信することが防がれるべきである特定の口座を識別してよい。これらの口座は、特定の暗号通貨アドレスによって、または特定の取引者識別情報によって、識別されてよい。原理的には、このリストは、コンプライアンスポリシーの一部として固定されてよいが、さらに一般的には、ときどき変化する。

【0124】

この機能をサポートすることは、複数の前提条件を必要とする。最初に、許可された１つまたは複数の関係者が、許可されない口座のリストを定期的に決定しなければならない。次に、このリストは、暗号認証を含む形態で、すべての関係者がリストの信頼性を検証できるということ、およびリストが「新しい」ということ、すなわちリストの所与のバージョンが最新であるということを保証して、システム上の取引者に公開されなければならない。これらの特性は、パブリックな台帳上のリストを公開することによって、または台帳上のリストの暗号「ダイジェスト」（ハッシュ）を公開し、何らかの分離したチャネルを介してリスト自体を送信することによって、実現され得る。

【0125】

否定リストの施行は、否定リストの現在のバージョンおよび所与のトランザクションへの入力（例えば、送信者および受信者の口座識別情報）の両方に対して推論するコンプライアンスポリシーを指定することによって保証される。送信者または受信者のいずれかの口座がこのリスト内に含まれている場合、コンプライアンスポリシーはトランザクションを許可しない。

【0126】

上記では、送信者が拒否リストの完全な内容を使用できるということを仮定する。場合によっては、この情報を公開することは望ましくないことがある。後のセクションで、コンプライアンスポリシーへの一部の入力が、送信者にとって機密である形態で公開され得る方法に対処する。

【0127】

[実施例４]
統計データ収集
複数のアプリケーションが、適合するプール内で作成されたトランザクションに関する集計統計データの可用性を必要とする。そのために、個別のトランザクションに関する有用な情報が使用可能にされず、それにもかかわらず、多くのトランザクションに関する集計統計値が、データ集計を計算することを許可されたデータアグリゲータによって導出され得るように、トランザクションが、各トランザクションに関する一部のデータを公開することが必要になる。

【0128】

複数の基礎になる数学的技術を使用して、データ集計が可能にされることが可能であり、これについて、後のセクションで詳細に説明する。それらの数学的技術は、次のように簡単に要約され得る。（１）準同型暗号化（暗号化データに対して数学演算が実施されることを可能にする暗号化）の使用によって、トランザクションの統計データが収集され得る、（２）集計データが、多数のトランザクションを合計し、ノイズを除去することのみによって収集され得るように、統計データが統計的ノイズと結合される、ノイズ難読化総和技術（noise-obfuscated summation techniques）（ランダム化応答技術など）の使用によって、トランザクションの統計データが収集され得る、および（３）信頼できるハードウェアコンポーネント（例えば、個別のトランザクションデータを公開せずに統計的集計を実行するＩｎｔｅｌ ＳＧＸ ｅｎｃｌａｖｅ）によって制御される鍵に従って関連するデータを暗号化することによって、統計データが収集され得る。これらの技術は、後のセクションで説明されるように、さまざまな方法で組み合わせられ得る。

【0129】

集計統計値を計算するために必要とされるデータは、統計的集計フィールド（ＳＡＦ：Statistical Aggregation Field）と呼ばれる特殊なフィールドで、各トランザクションと並行して公開されてよい。コンプライアンスポリシーは、ポリシーがＲＥＡＦの存在を施行できる方法に類似する方法で、各許可されたトランザクションに対してＳＡＦの存在および正しい構造を施行する。ポリシーは、ＳＡＦが関連するトランザクションデータの何らかの特定の数学関数をエンコードすることを施行し、この関数の正確な性質は、統計的集計を実行するために使用される数学的技術に依存する。関数への入力および機能自体の性質は、すべてのトランザクションについて固定されてよく、またはコンプライアンスポリシーは、異なる特性を有するトランザクションに対して異なる構造（および異なる関数入力）を指定してよい。高度なポリシーは、集中型の関係者が定期的に新しいデータを取引者に公開することによって関数の構造を変更することを可能にする、プログラム論理を含むこともできる。このメカニズムによって、オペレータのデータプラットフォームは、収集されるデータの品質および種類を「調整する」ことができる。

【0130】

ＳＡＦが各トランザクションに添付された後に、データアグリゲータは、ある期間の間に発行された多くのＳＡＦからの情報を結合することによって、時間と共に実施されたトランザクションに関する集計統計値を計算してよい。この集計の性質は、各ＳＡＦを構築するために使用される数学的技術に依存し、統計的集計の精度は、使用される技術および収集されるトランザクションの数に依存してよい。次に、この結合されたデータは、データプラットフォームのＡＰＩを介してユーザに公開されてよく、および／またはデータオラクルを介して取引者に公開されてよい。

【0131】

[実施例５]
疑わしい活動の報告
複数の規制フレームワークは、銀行および金融機関が顧客のトランザクションを分析し、可能性のある犯罪行為を識別する報告を提出することを要求する。これらは、多くの場合、「疑わしい活動の報告」（ＳＡＲ）と呼ばれる。現在の銀行業務（例えば、米国における規制）では、ＳＡＲは、トランザクションの手動の分析に基づいて構築されることがあり、またはＳＡＲは、自動化されたシステムによってアルゴリズム的に生成されることがある。アルゴリズム的ＳＡＲの発行は、コンプライアンスポリシーによって施行され得る。

【0132】

コンプライアンスポリシーによってＳＡＲを施行することは、２つの前提条件を必要とする。第一に、コンプライアンスポリシーは、トランザクションの入力を評価するプログラム論理に加えて、（任意選択的に）周囲条件に関する情報（例えば、データオラクルによってネットワークに公開された集計統計値）を埋め込まなければならない。この論理は、所与のトランザクションがＳＡＲをもたらすべきであるかどうかを判定し、もたらすべきである場合、ＳＡＲのどの内容がもたらされるべきかを決定するために、これらの入力を評価しなければならない。第二に、コンプライアンスポリシーは、ＳＡＲを適切な機関に報告するための手段を施行しなければならない。

【0133】

ＳＡＲ報告は、１つまたは複数の規制エスクローエージェントにアドレス指定されたデータを含む規制施行アクセスフィールド（ＲＥＡＦ：Regulatory Enforcement Access Field）を介して可能にされる。ＳＡＲ報告がコンプライアンスポリシーによって可能にされる場合、ポリシーは、各トランザクションがＲＥＡＦフィールドを含むということ、およびＳＡＲ情報が、ＲＥＡＦ内に含まれているデータに組み込まれるべきであるということを指定する。ＲＥＡＦは、例えば、ウォレットのアドレス、ウォレットに関連付けられている関係者の識別情報、デバイス識別子、ＩＰアドレス、関連する前のトランザクションに関する情報などを含んでよい。

【0134】

（ＳＡＲデータを含んでいるＲＥＡＦフィールドの存在が、いずれかの他の規制エスクローデータがフィールド内で収集されることを必ずしも必要としないということが、理解されるであろう。ＳＡＲ報告は、任意選択的に、単一のＲＥＡＦを使用して他の規制エスクローの機能と組み合わせられてよく、またはＲＥＡＦフィールドは、ＳＡＲデータのみを含み、規制エスクローデータを含まなくてよい。他の組み合わせも可能であり、例えば、トランザクションは、異なる規制エスクローエージェントにアドレス指定された複数のＲＥＡＦフィールドを含んでよく、例えば、１つのＲＥＡＦフィールドはＳＡＲデータを含み、１つのＲＥＡＦフィールドは規制エスクローデータを含む。）

【0135】

ＲＥＡＦフィールドは、ＳＡＲ情報を適切な機関に伝達する役割を担う許可された規制エスクローエージェントによって復号され得る。ＳＡＲ報告ポリシーの使用は、ＲＥＡＦが、コンプライアンスポリシー内に埋め込まれたいずれかのＳＡＲ報告機能の出力を含んでいるデータフィールドを含むことを必要とする。トランザクションによってＳＡＲ報告がトリガーされない場合、このフィールド内のデータは省略されるか、または空のままにされ得る。ＳＡＲがトリガーされる場合、得られた報告が、ポリシー論理によって指定され、ＲＥＡＦに含められる。ＲＥＡＦが、特定の規制エスクローエージェントに向けて暗号化されるため、許可されていない関係者は、所与のトランザクションがＳＡＲ報告を埋め込むかどうかを判定することができないはずである。

【0136】

疑わしい活動の報告システムの開発における重要な設計上の選択は、特定のトランザクションによってＳＡＲがトリガーされるかどうかを、トランザクション送信者が認識するべきであるかどうかである。多くの従来の銀行取引の文脈では、ＳＡＲの回避を防ぐための手段として、ＳＡＲポリシーおよびＳＡＲが開始されたかどうかの知識の両方が顧客から秘密に保たれることがある。コンプライアンスポリシーは、トランザクションの作成者および／または受信者が使用できないコンプライアンスポリシーへの機密の入力としてパラメータを指定することによって、これに対処することができる。したがって、トランザクションの送信者および／または受信者は、ＳＡＲへの入力も、トランザクションに応答してＳＡＲが作成されたかどうかも認識しない。機密のポリシー入力を実装するための技術的手段が、以下のセクションでさらに説明される。

【0137】

ポリシーは、例えば以下を含む、ＳＡＲの自動化された発行のためのさまざまな条件を指定してよい。
（１）不十分な文書作成、矛盾、複数の口座などの、顧客識別情報（例えば、ＫＹＣデータ）の異常。
（２）ポリシーによって指定された固定されたしきい値、例えばポリシーによって許可された関係者によって決定された動的しきい値、または他のパラメータから数学的に決定された動的しきい値（例えば、所与のアセットにおける合計取引量）のいずれかと比較した、単一のトランザクション内か、複数のトランザクションにわたる（例えば、検出を回避しようとする試みにおける「構造化」）かにかかわらず、異常に高いトランザクションの値。
（３）（例えば、顧客のウォレットに関連付けられたＫＹＣプロセスの間に確認された）顧客の性格または収入にふさわしくないか、または顧客の過去の活動と比較して異常なトランザクション活動（例えば、すでに休止状態の口座における激しい活動）。
（４）ポリシーによって課された何らかのルールによって、識別情報プロバイダの裁量によって、あるいはポリシーによって規定された関係者によって課されたリスト、警告、または基準（例えば、「政治的に影響力のある人物」、地理的領域、または制裁リスト、あるいは事例に固有の裁判所命令）によって、口座が、疑わしいか、または高リスクとして警告される。
（５）ソーシャルネットワークのユーザ名、民間企業（金融機関を含む）での顧客口座、従業員データベース、（ブロックチェーンに基づくか、または他の方法での）自己主権型識別情報ネットワーク、インターネットドメイン名の所有権などの、ウォレットの所有者に関連する他のプラットフォーム上の口座またはデジタル識別情報に関連付けられた活動。この関連付けは、直接的に、またはＫｅｙｂａｓｅなどの識別情報リンクサービスを介して間接的に実行されてよい。
（６）疑わしい活動の報告および現金取引報告などの報告の発行に関して、国、州、金融活動作業部会などの国際組織、または民間組織によって規定された、任意の他の基準。

【0138】

[実施例６]
交換アセット認識サービス
ユーザに１つのアセットを別のアセットと交換させる交換サービスは、そのような取引が意味あるようにアセットの来歴を追跡するために、特殊な処理を必要とすることがある。例えば、図４に示されているように、ウォレットＡの所有者が、交換を使用してアセットＸをアセットＹと交換する事例について考える。

【0139】

技術的に、ウォレットＡによって送信されたアセットＸは、最後に他のユーザのウォレット（ウォレットＢ）に行くことになる。同様に、ウォレットＡによって受信されたアセットＹは、他のユーザのウォレット（ウォレットＣ）に由来する。ＣＲＡＩの追跡は、この来歴に焦点を合わせる。しかし、大量の交換の場合、ウォレットＢおよびウォレットＣは、同時に存在し、無関係である。むしろ、ＣＲＡＩは、識別情報および過去のトランザクション履歴を維持することによって、複数のアセットにわたって、ウォレットＡによるアセットＹとのアセットＸの交換を伝達するべきである。

【0140】

コンプライアンスポリシーは、上記を反映してよい。しかし、取引の仕組みが各交換の実施に固有であるため、コンプライアンスポリシーは、一般に、取引を正しく追跡する仕組みを直接指定することができない。したがって、コンプライアンスポリシーは、自分自身によってこの追跡を提供することができるアセット認識サービスとして、交換を許可する。

【0141】

集中型の交換の場合、この追跡は、例えば、交換ＡＡＳが、交換引き出しトランザクション（exchange withdrawal transactions）において、正しく追跡された取引を反映する関連するＣＲＡＩを決定することを可能にするコンプライアンスポリシーとして、実装されてよい。取引の正しい追跡は、技術的には交換の自由裁量により、ただし正確さに関して規制機関または契約上の義務によって裏付けられて、交換によって内部で実行される。

【0142】

一部の交換は、自動マーケットメーカー（ＡＡＭ：automated market markers）などの、取引注文控え帳または自律的取引アルゴリズムを実現する分散型メカニズムによって、実装されてよい。この場合、正しい挙動に関して拘束するために、法的関係者が存在しなくてよい。したがって、代わりにＡＡＳは、証明可能なように厳密な方法で取引を追跡する（スマートコントラクトおよびサポートソフトウェアとして実装された）特定のプロトコルとして、機械化され実現されてよい。スマートコントラクトは、暗号化されずに動作してよく、誰でも取引を観察し、ＣＲＡＩの正しさを検証することができる。代替として、スマートコントラクトは、ゼロ知識証明などのプライバシー保護暗号メカニズムを使用して、ユーザが取引を実行することを可能にし、ユーザ自身のＣＲＡＩが正しく更新されていることを、このＣＲＡＩを（コンプライアンスポリシーに従って許可された人を除く）誰にも明示的に公開せずに証明してよい。

【0143】

交換動作がＡＭＭの流動性資産プロバイダトークン（liquidity provider tokens）などの補助アセットを含む場合、これらの補助アセットも、ＡＡＳによって追跡され、これらの補助アセットに対する命令がポリシーによって指定されてよい。例えば、関係者がＡＭＭを使用してアセットを預金し、見返りとして流動性資産プロバイダトークンを取得する場合、ＡＡＳとして動作しているＡＭＭは、（預金されたアセットおよび預金者のシールされたウォレットによって伝達された）識別情報および／または資金の来歴などの預金者のＣＲＡＩを使用して流動性資産プロバイダトークンを拡張してよい。

【0144】

[実施例７]
リスク管理
ポリシーおよびＳＡＰは、規制される実体および他の金融機関によって、リスクに基づく手法の実施およびリスク許容度ポリシーの施行を容易にするために使用されてよい。一部の既存のシステムでは、金融機関などの実体は、ブロックチェーン上のユーザの活動に基づくスコア評価を必要とする。この「リスクスコア」または「リスクプロファイル」は、ユーザまたはユーザの資金が適合していない活動に関与している可能性の最良の推定値を表す。異なる実体が、さまざまな要因に応じて、より高いリスクスコアまたはより低いリスクスコアを同じトランザクションまたはユーザに割り当ててよい。リスクの負担を管理するためおよび／または軽減するために、ＶＡＳＰおよび規制される実体によって、そのようなリスクスコアまたはプロファイルが使用されてよく、さまざまな指標に基づいてときどき更新されてよい。そのようなリスク管理の実務は、上記の集計統計値の例に類似する方法で、または個別のユーザに制限されて計算される統計値のセットを使用して、実現され得る。リスクの計算は、例えば、リスク許容度ポリシー、収集された情報などに基づいていてよい。

【0145】

[実施例８]
組織の監査
組織（個人を含む）は、組織が所有するウォレット（例えば、企業のアセットおよび従業員の経費ウォレット）にポリシーを課すことができ、これによって監査機能を容易にする。この組織のポリシーは、組織が受ける、管轄区域によって課されるコンプライアンスポリシーを補完して拡張する。監査は、例えば、資金の流れに関する集計統計値を追跡し、指定された関係者によって見ることができるようにしてよい。監査は、例えば、上で開示された疑わしい活動の報告に類似するが、必要な変更を加えた組織のレベルでの何らかの基準による、異常であるか、または高リスクのトランザクションを、リアルタイムに、指定された関係者によって見ることができるようにしてよい。監査は、合計預金残高に対して推論し、合計預金残高がある基準を超える（例えば、引当金勘定または自由裁量資金勘定がしきい値を下回る）場合に、阻止するか、警告を発行するか、または手動の承認を要求してもよい。

【0146】

さらに、組織のシールされたアセットの監査される特性は、第三者への提示のために、第三者に主張の正しさを厳密に納得させる暗号証明を使用して、暗号によって認証されてよい。そのような証明は、例えば、残高があるしきい値を超えており、ある期間の間そうであったことの証明、純資産の流入の証明、または保持している預金額が何らかの負債に一致することの証明（それらの負債の金額を公開するかどうかにかかわらない）を含んでよい。

【0147】

[実施例９]
冗長なチェック
ポリシーは、複数の冗長なチェックを含んでよい。例えば、ポリシーは、必要な会計を実行するプライバシー保護プロトコルによって機械的に施行される、複雑な上限または報告基準を指定してよい。次にポリシーは、関連する情報も指定された監査人に公開されるということをさらに指定してよく、監査人は、計算を二重チェックし、機械的施行が失敗しなかったことを保証することができる。この監査人は、秘密を維持するように法的に拘束されてよく、誤りのある動作が疑われる場合にのみ（例えば、組織の経営者または裁判所の裁量で）呼び出されてよいが、監査人の存在は、追加の安全性をもたらし、技術的故障からの回復を可能にする。

【0148】

[実施例１０]
チャージバックおよび資金の回復
ポリシーは、ある時間の経過などの何らかの基準が満たされるまで、特定のトランザクションが取り消し不能に終了されないということを指示してよい。ポリシーは、基準をさらに指定してよく、この基準に従って、トランザクションは、能動的に逆転されることが可能であり、トランザクションの状況がチャージバックポリシー（すなわち、「チャージバック」）の要件を満たす場合に、仮想アセットが完全に、または部分的に送信者に返される。このポリシーは、所有者によるトランザクションの許可を検証すること、移行における紛争を処理すること、商品の返品を容易にすること、購買管理を施行し、可能性のあるトランザクションの取り消しを容易にすること、詐欺を軽減すること、窃盗、損失、損害、および誤りの金額を払い戻すこと、ならびにブロックチェーン上で容易にされるトランザクションに関する疑わしい業者の活動（ウォレットのセキュリティを技術的に侵害する「サイバー攻撃」によるもの、または悪意のある人間のアクションによるものを含む）を検出することに使用され得る。チャージバックを可能にすることによって、窃盗による損害のリスクが軽減されることが可能であり、それによって、最初の段階において犯罪を犯すことに対する潜在的な阻害要因を提供する。

【0149】

[実施例１１]
納税
ポリシーは、１つまたは複数の特定のウォレットに対して行われる支払いが他の相応の支払いを伴わなければならないということを指示してよい。例えば、小売店業者のウォレットへの任意の支払いが関連する税務当局へのＶＡＴの支払いを伴うということが、要求されてよい。ポリシーは、付随する支払いの計算、およびその支払先、ならびにポリシーがどのウォレットに適用されるかを指定する。ポリシーは、管轄区域によって課されてよく、またはポリシーは、関連する税法、規制などへの業者自身のコンプライアンスを保証するための手段として、業者によって自発的に業者自身に課されてよい。

【0150】

ポリシーは、税法へのコンプライアンスに関連するＣＲＡＩの追跡を含んでもよい。例えば、キャピタルゲイン税は、通常、売却された各アセットの課税基準（取得のコスト）を知ることを必要とする。現在、この基準の計算は、既存の分散型台帳によって実行されず、代わりに納税者は、自分自身によって、または第三者のサービスに頼ることによって、課税基準を追跡する必要がある。本システムは、課税基準を、トランザクションにもともと添付されたＣＲＡＩとして含める。これによって、より高い信頼性および相互運用性を可能にする。さらに、本システムは、より繊細な概念を処理することができる。例えば、米国連邦税法は、税ロットの特定の識別を考慮し、アセットを売却する関係者は、異なる課税基準を有する複数の類似するアセットのうちのどれが売却されているアセットであるかを、同時期に指定することができる。ポリシーは、この識別された税ロットおよび対応する基準をＣＲＡＩ内に追加してよい。次に、本システムは、トランザクションによって結果として生成された利益の量に関して証明を提供してよい。システムは、特定のロットの識別が売却トランザクションと同時期に実行されること、および税ロットの正しい会計（例えば、同じ税ロットが、２回以上売却されたとして報告され得ない）などの要件を施行することができる。ポリシーは、次に、例えば前述したように、税務当局へのこの税の支払いを施行してもよい。ポリシーは、例えば、関連付けられたＣＲＡＩ内のアセットの保持期間を追跡することによる、および長期または短期のどちらのキャピタルゲイン税率が適用可能であるかを推論することによる、適用可能な税率の計算を含んでもよい。

【0151】

[実施例１２]
分散型アプリケーションの管理
合意システムは、１つまたは複数の分散型金融（ＤｅＦｉ：decentralized finance）アプリケーションをホストしてよい。これらのアプリケーションは、通常、合意システム上で直接実行されて、支払いおよび他の機能を可能にする、スマートコントラクトプログラムを使用して実装されるが、一部のＤｅＦｉシステムは、価格設定オラクルおよび交換注文照合システム（exchange order matching systems）などの、より集中型の構成要素も組み込む。集中型システムとは異なり、ＤｅＦｉアプリケーションは、集中型の関係者によって実行されず、秘密鍵を格納することができなくてよい。したがって、ＤｅＦｉアプリケーションは、識別情報証明のどの秘密の構成要素も格納することができない。これらの分散型システムの動作が通常は透過的であるため、つまり、すべての関係者が分散型システムが処理する入力および出力を見ることができるため、ＤｅＦｉアプリケーションと情報をやりとりするユーザは、ＤｅＦｉサービスに送信される発信トランザクションのＣＲＡＩを生成すること、およびＤｅＦｉアプリケーションを通過する資金の完全な履歴を示すために、その後のトランザクションでの必要なＣＲＡＩを再構築することの責任を負う。この場合、ポリシーは、ユーザがＤｅＦｉアプリケーションとの情報のやりとりに関するトランザクション履歴を追跡することを要求し、システムは、このトランザクション履歴からの完全性および正しい推論を施行する。

【0152】

[実施例１３]
外国口座報告
ポリシーは、米国外国口座税務コンプライアンス法（ＦＡＴＣＡ：Foreign Account Tax Compliance Act）またはＯＥＣＤの共通報告基準（ＣＲＳ：Common Reporting Standard）などの、外国口座報告要件へのコンプライアンスを施行してよい。シールされたウォレットが、例えば管轄区域によって、必須の報告要件の対象になる外国口座を表すデジタルアセットを含んでいると見なされる場合、ポリシーは、そのようなウォレットの（例えば、識別情報証明をシールされたウォレットに提供するウォレット識別情報プロバイダによって提供されたとおりの）識別情報を含んでよい。ポリシーは、そのようなウォレットに関して、ウォレットの所有権、識別子（例えば、納税者番号）、残高、および／または任意の他の必要とされる情報に関連して、例えば管轄区域によって定義されたとおりに、１つまたは複数の報告の発行を施行してよい。報告は、例えば、ＳＡＲとの関連において上で説明されたように、ＲＥＡＦフィールドを使用して自動的に発行されてよい。報告は、シールされたウォレットによって定期的に発行されてもよい。年間最大残高などの計算された内容を含む、これらの報告の正確さは、報告された出力が基礎になるトランザクションおよびＣＲＡＩから正しく計算されたことを証明するゼロ知識証明などの暗号手段によって、施行されてよい。ポリシーは、ＡＡＳまたは外部の適正評価手順から取得された追加情報をこれらの報告に統合してもよい。

【0153】

[実施例１４]
阻止および制裁の施行
ポリシーは、一部のトランザクションが禁止され、阻止されることを指定してよい。この指定は、暫定的なトランザクションを検査し、トランザクションが許容されるかどうかを報告する、計算的決定手順によって実現されてよい。この決定手順は、トランザクションデータ内の平文で見ることができる情報に対して推論してよい。この決定手順は、トランザクションデータ内の平文で見ることができないが、暗号手段によって存在および完全性が保証されるＣＲＡＩに対して、さらに推論してよい。

【0154】

例えば、ポリシーは、国のセットから成る阻止リストまたは制裁リストを指定してよく、送信者または受信者の国籍がそのようなリスト内にある場合にトランザクションが禁止されるルールを指定してよい。国籍は、シールされたウォレットに添付された識別情報証明内で指定されてよい。したがって、リスト内の国籍を指定した関係者の識別情報証明を含むすべてのトランザクションが、決定手順によって、禁止されるとして検出される。

【0155】

この例では、国籍は、シールされたウォレットに添付されるが、パブリックに公開されない、プライベートなＣＲＡＩに含まれてよい。それにもかかわらず、ポリシーは、送信者によって生成されて、トランザクションに添付され、決定手順によって検証され得る（例えば、下で説明されるような）ゼロ知識証明などの暗号手段によって、依然として施行されてよい。

【0156】

ポリシーは、名前または国民識別番号などの識別情報属性に基づいて、トランザクション履歴に基づいて、関連する口座番号に基づいて、またはＣＲＡＩ、オラクル、もしくはシステム内で使用できる他の情報源における任意の他のデータに基づいて、阻止を指定してもよい。

【0157】

新しい記録を使用して台帳を拡張する関係者（例えば、マイナーまたはバリデータ）は、決定手順を呼び出し、禁止されたトランザクションを台帳内に含めることを拒否してよい。

【0158】

（例えば、バリデータのマイナーが決定手順を実行し、決定手順に従って行動することができなかったため）禁止されたトランザクションが台帳内に現れる場合でも、任意の他の関係者が、決定手順を実行して、禁止されたトランザクションを認識し、その後、禁止されたトランザクションを有効として認識することを拒否してよい。したがって、本明細書に記載されたシステムは、既存の合意システムの上への重ね合わせとして動作してよく、このシステムのマイナーまたはバリデータは、システムのトランザクションチェックルールを認識していない。

【0159】

決定手順は、ある時間が経過したか、または一部の関係者があるアクションを実行した後にのみ、決定結果を可視にする、遅延要素を含んでよい。この遅延要素は、トランザクション送信者が、トランザクションが制裁ルールに一致するかどうかを前もって知るのを防ぐことができ、このようにして、制裁を回避しようとするか、または送信者不透明ポリシー（sender-opaque policies）をリバースエンジニアリングしようとする試みの検出を、容易にすることができる（下記を参照）。

【0160】

[実施例１５]
融資アセット認識サービス
ユーザにアセットを貸させるか、または借りさせる（多くの場合、そのようなローンの利子を生むか、または支払う）融資サービスは、意味あるようにアセットの来歴を追跡するために、特殊な処理を必要とすることがある。実施例６（交換アセット認識サービス）を参照して上で説明されたように、アセットの流れに単純に従うことは、資金の来歴の正しくない追跡につながることがある。例えば、貸し手よってローンが融資サービスに貸し出され、その後、融資サービスから借り手へのローンが続く場合、ネイティブな追跡は、貸し手のアセットが借り手に移動されることを示すことがある。同様に、貸し手が回収するときに、単純な追跡は、資金を、最近ローンを融資サービスにたまたま貸し出した他の貸し手からの移動、または最近ローンを返した任意の借り手に起因させることがある。しかし、資金の来歴のより意味のある属性は、返されたローンのアセットを、元のローンのアセットのＣＲＡＩ（識別情報、来歴など）を持っているように表すことである。

【0161】

ポリシーは、融資サービスが、資金の来歴の後者の属性を提供するアセット認識サービスであることを許可してよい。これは、アセット認識サービスのオペレータへの依存によって、または例えば、ＡＡＳを参照して上で説明されたように、通信プロトコルおよび暗号を使用して分散方式で、実現されてよい。

【0162】

ＡＡＳは、さらに、例えば、実施例６を参照して上で説明されたように、１つのアセットの種類が貸し出されるが、別のアセットの種類がローンの清算において返される場合など、アセットの複数の種類にわたって来歴を追跡してよい。ＡＡＳは、ＣＲＡＩを伝搬し、ローンの担保、担保契約、および／または再担保の来歴を追跡してもよい。

【0163】

[実施例１６]
窃盗または強要からのアセットの保護
アセット所有者は、例えば、窃盗または強要によるこれらのアセットの損失から自らを保護するために、ポリシーを自分自身のウォレットおよびアセットに課すことを選択してよい。

【0164】

一部の実施例によれば、ポリシーは、追加の検証基準が満たされない限り、アウトバウンドの移動を阻止することによって、資金の移動を制限してよい。そのような基準は、追加の手段または関係者によって実行される承認、認証、または識別情報の検証、あるいは／およびトランザクションが保留中のままになり、送信者によって取り消され得る、時間ウィンドウを含んでよいが、これらに限定されない。

【0165】

他の実施例によれば、ポリシーは、例えば、実施例１４（阻止および制裁の施行）を参照して上で説明されたメカニズムに類似するが、アセット所有者によってリストが設定され得るという点が異なる、許可リストまたは阻止リストメカニズムを使用して、資金が送信され得る送信先を制限してよい。

【0166】

さらなる実施例によれば、ポリシーは、実施例５（疑わしい活動の報告）を参照して上で説明された警告に類似するが、警告の受信者が異なる、これらのウォレットおよびアセットにおけるトランザクションに関する、アセット所有者または他の許可された関係者が見ることができる警告を発行してよい。

【0167】

上記の実施例の一部またはすべてが組み合わせられてよいということが、理解されるであろう。例えば、ポリシーは、そのような制限または阻止を、特定の関係者または関係者のグループのすべてのアセットおよび／またはウォレットに適用可能であるとして指定してよく、あるいはポリシーは、トランザクションパターンおよびＣＲＡＩに対して評価され得るトランザクション量のしきい値または任意の他の基準などの、制限または報告を有効にするための基準を指定してよい。

【0168】

[実施例１７]
組織のポリシー
仮想アセットを扱う組織は、実施例１６（窃盗または強要からのアセットの保護）を参照して上で説明されたのと同様に、組織のウォレットおよびアセットを窃盗または強要から保護するために、ならびに／あるいは詐欺、横領、および他の違法行為を追跡するためにも、ポリシーを組織のウォレットおよびアセットに課してよい。実施例１６を参照して上で説明された例が、同様に、適用可能である。組織のポリシーは、組織の許可された財務担当者によって記述され、展開されてよい。組織のポリシーは、組織の担当者が制限されたトランザクションを承認することを許可されるということを、指定してよい。組織のポリシーは、組織の担当者を、ポリシーによって施行された報告の受信者として指定してよい。ポリシーは、組織内のトランザクションに適用されてよく、かつ／または組織と、顧客、供給者、投資家などの組織の取引相手との間のトランザクションに適用されてよい。

【0169】

データプラットフォーム
データプラットフォームは、台帳上およびＡＡＳ内で実施されるトランザクションから集計データを収集するためのシステムを備え、このデータを、顧客が表示するため、およびコンプライアンスポリシーへの入力として使用するために、提示する。データプラットフォームは、プライバシー保護技術を使用して、集計統計値の収集を依然として可能にしながら、個別のトランザクションに関する最小限の情報が許可されていない関係者に公開されることを保証する。

【0170】

データオラクル
データオラクルは、例えば、従来技術においてよく知られているような暗号によって認証される方法で、データを参加者に公開するように設計されたシステムである。そのようなデータは、新しいトランザクションを生成するときにコンプライアンスポリシーへの入力として、トランザクションイニシエータを含む分散型システムによって使用され得る。

【0171】

ポリシーの記述／展開
コンプライアンスポリシーは、計算および（暗黙的に）特定のトランザクションの入力と出力の間の数学的関係を定義するアルゴリズムまたは論理回路を表す（アルゴリズムと論理回路の間の等価性のため、これらの用語およびこれらの用語に関連する用語は、本明細書において交換可能なように使用される）。ポリシーは、人間が読めるポリシープログラミング言語でコード化されてよく、ポリシープログラミング言語は、ポリシー施行メカニズムによって直接消費される低レベルの形式にコンパイルされる。ポリシープログラムへの特定の入力変数および出力変数は、どの入力および出力を誰が見ることができるべきかを指定する機密性ラベル付けスキーマを使用してマーク付けされてよい。このようにして表されたポリシーごとに、機密性マークアップ情報が、ポリシープログラムの一部として含まれてよく、または分離したファイルに書き込まれてよい。ポリシープログラムは、複数の可能な言語（その一部は、すでに存在している）で記述されることが可能であり、またはポリシープログラムは、この目的のために設計された特殊な「領域固有の言語」を使用して記述されてよい。

【0172】

一部の入力変数および出力変数は、トランザクションのデータおよび／またはシールされたウォレット内に格納されたデータに関連しているとして、明示的に予約もされる。例えば、プログラムは、トランザクション内で送信される資金の量、トランザクションの受信者のアドレス、またはシールされたウォレット内にある識別情報証明からのフィールドを表す入力変数を含んでよい。同様に、入力変数は、対応するＣＲＡＩ内の、トランザクションまたは関連するウォレットに関連付けられた補助データ値を参照してよい。変数値は、プロセスまたは関係者によって直接与えられてよく（例えば、トランザクション量）、他の値からシステムによって計算されてよく（例えば、過去のトランザクション量の総和）、ポリシーまたはポリシーによって指定されデータソースによって提供されてよく、ランダムに取り出された数値であってよく、前述したように、「データオラクル」によって生成されてよく、または任意の他のプロセスによって生成されてよい。

【0173】

各プログラムは、少なくとも１つの必須の出力、すなわち、ポリシーの要件が満たされるかどうか、およびしたがって、トランザクションがネットワークによって許容されるべきかどうかを示すブール（真／偽）結果を含む。この結果は、明示的に出力され得るが、プログラミング言語によって暗黙的に定義されてよい。例えば、プログラムは、条件が満たされない場合にエラーメッセージを生成してよい。プログラムは、ゼロまたはさらに追加の明示的な出力値を指定してもよい。代替として、プログラムは、論理述語（例えば、すべての制約）が満たされる場合に出力が「真」になるという規則を使用して、論理述語（例えば、制約の連言）の形態で表されてよい。

【0174】

ポリシーは、プログラマによって記述された後に、通常、コンパイラツールチェーンによって、このシステムの構成要素によって評価されて推論され得る形態にコンパイルされる。したがって、開発者は、複数の異なる高レベルのプログラミング言語をポリシー開発に使用することができ、各言語のコンパイルされた出力は、本システムに適合する共有された表現になる。

【0175】

ポリシーは、発効するために、シールされたウォレット、ＡＡＳ、データプラットフォーム、マイナー、バリデータなどを含むことがある、ポリシーの知識を必要とする関係者に展開される。そのような展開は、ホスト名およびＵＲＬなどのリソースロケータによって指定されたインターネットサービスを介するか、またはデータストレージサービス（集中型であるか分散型であるかにかかわらない）を介する、パブリックな台帳上のポリシーの公開を含む、さまざまな手段によって実行されてよい。ポリシーは、ポリシーを使用するソフトウェアと一緒にまとめられてもよい。例えば、シールされたウォレットアプリケーションは、ポリシーのコピーを含むパッケージ（例えば、ＡＰＫまたはＺＩＰファイル）で配布されてよい。ポリシーは、ソースまたはコンパイルされた形態で配布されてよい。

【0176】

ポリシーは、意図された関係者（例えば、規制機関またはコンソーシアム）によってポリシーが発行されたということを確認するために、認証を必要としてよい。そのような認証は、ポリシー自体への暗号デジタル署名を用いて、デジタルチャネルによって署名が取り出されるデジタルチャネルの認証によって間接的に（例えば、ＨＴＴＰＳ ＵＲＬ、これを介して、サーバがデジタル証明およびデジタル署名を提示する）、または任意の他の信頼できるチャネルによって、実行されてよい。認証は、複数の関係者による承認を必要としてよく、これは、複数のデジタル署名によって、集合署名によって、またはしきい値署名よって実現され暗号によって実現されてよい。

【0177】

ポリシーは、例えば、実施例１６（窃盗または強要からのアセットの保護）および実施例１７（組織のポリシー）を参照して上で説明されたように、個人または組織によって、個人または組織自体（すなわち、個人または組織が制御または所有しているウォレットおよびアセットの一部またはすべて）に課されてよい。

【0178】

ポリシーは、全体的または部分的に（例えば、許可リストまたは阻止リストなどの構成要素）、更新されるか、または取り消されてよい。同様に、そのような更新または取り消しは、上記の手段のいずれかによって配布され、認証されてよい。

【0179】

ポリシーの展開、更新、および取り消しは、パブリックに可視であってよい。ポリシーの展開、更新、および取り消しは、送信者不透明ポリシーを実装する場合のように（例えば、下で説明されているように）、完全にまたは部分的に不透明であってもよい。

【0180】

ポリシーの展開、更新、および／または取り消しは、これらのポリシーの実現に必要とされる追加データと共に、ポリシーの変更内容の説明を含んでよい。例えば、共通参照文字列（構造化された参照文字列、パブリックパラメータ、または信頼できる設定パラメータとしても知られている）を利用するゼロ知識証明（下記を参照）によって実現されるポリシーの場合、必須の共通参照文字列が展開または更新に含まれてよい。代替として、このデータは、例えばインターネットリソースロケータを提供することによって、間接的に提供されてよい。

【0181】

ポリシーの施行
ポリシーは、記述されてコンパイルされた後に、複数の基礎になるメカニズムを使用して、システムによって施行される。これらのメカニズムは、ゼロ知識証明（対話式または非対話式）、秘匿マルチパーティ計算プロトコル（対話式であるか非対話式であるかにかかわらず、２つ以上の関係者場合）、暗号化および準同型暗号化メカニズム、ならびにプログラム難読化アルゴリズムなどの、暗号メカニズムを含んでよい。採用される実装メカニズムの選択は、ポリシーの内容に依存する。

【0182】

各シールされたウォレットは、トランザクションに関与する前に、トランザクションおよびＣＲＡＩを正しく形成するために、最初に、ウォレットの実装を使用して準備されなければならない（前述したように、ソフトウェアおよび場合によってはハードウェアにおいて具現化される）。

【0183】

合意システム自体は、ネットワークオペレータがトランザクションおよびＣＲＡＩの正しい形成の妥当性を確認できるようにする論理的システムを使用して準備されてもよい。場合によっては、合意システムは、イーサリアムブロックチェーンにおける「スマートコントラクト」メカニズムなどの、パブリックな台帳システムにおける既存の柔軟性を使用して、構築されてよい。この構築は、既存のプラットフォームまたは新しいプラットフォームに対する拡張を使用して実行されてもよく、例えば、特定のゼロ知識証明システムの検証を可能にする「プリコンパイル」（イーサリアムのスマートコントラクトのバイトコード言語における専用の命令）の使用によって実行されてもよい。代替として、妥当性確認をサポートするために、新しいシステムが合意システムに追加されてよい。代替として、基礎になる分散型台帳およびその合意ポリシーとは別に、妥当性確認が実行されてよく、すなわち、一部のトランザクションは、基礎になる台帳に含まれるが、本システムによってチェックされるときに妥当性確認に失敗し、したがって、適合していないと見なされ、適合するプールから除外される。

【0184】

トランザクションをシステムにサブミットする前に、シールされたウォレット構成要素が、機械可読の形態で必要とされるコンプライアンスポリシーを受信しなければならない。この形態は、高レベルのプログラミング言語および／または低レベルの「バイトコード」（例えば、仮想マシンと呼ばれるソフトウェア構成要素によって実行されるように設計された低レベルの命令言語）での表現またはポリシーアルゴリズムの回路表現で構成されてよい。これらのポリシーは、合意システムの台帳から、または何らかの帯域外の位置から、直接受信されてよい。次に、トランザクション送信者は、合意システムによって要求された書式設定ステップを使用して、トランザクションデータを構築する。その後、トランザクション送信者は、下で説明されているように、添付されたＣＲＡＩ構成要素を構築する。

【0185】

コンプライアンスポリシーは、次の２つのカテゴリに大まかに分類され得る。
・送信者透明ポリシー（Sender-transparent policies）は、トランザクション構築の時点ですべてのコンプライアンスポリシー入力値が送信者によって知られているというような、ポリシーを含む。
・送信者不透明ポリシーは（完全に、または部分的に）、一部のプログラム入力値が送信者に知られていないことがあるというような、ポリシーを含む。送信者不透明ポリシーは、必要な入力がトランザクション受信者によって選択されるため、または、必要な入力が、コンプライアンスポリシー作成者（またはコンプライアンスポリシー作成者がこの権限を委任した、指定された関係者）などのネットワークの他の構成要素によって選択されるために発生する。

【0186】

送信者透明ポリシーおよびブロックチェーンの統合
最初に、すべての必要なポリシー入力値が送信者に知られている事例について考える。この場合、ＣＲＡＩを構築するために、送信者のウォレット構成要素が、既知の入力に対してコンプライアンスポリシーを最初に評価する。ポリシーを評価することは、送信側ウォレット構成要素がポリシープログラムのアルゴリズムステップを計算すること、または回路がプログラムの出力を計算することを必要とする。この計算は、プログラムを実行するために設計された特殊なソフトウェア構成要素である仮想マシンの内部で行われてよい。一部の入力変数は、トランザクションに固有のデータ（例えば、量またはトランザクション受信者）、シールされたウォレットによって保持されるデータ、他の値から計算されたデータ、ポリシーまたはポリシーによって指定されたデータソースによって提供されたデータ、ランダムに取り出された数値などを表すように、ポリシーによって指定されてよく、仮想マシンを実行するシステムは、対応するデータ値が実際に使用されることを保証しなければならない。このプロセスの最後に、送信者のウォレット構成要素は、コンプライアンスプログラムを実行する過程で計算されたプログラム出力および／または任意の中間データを取得する。

【0187】

ポリシー評価が成功した結果を示す場合、トランザクションはコンプライアンスポリシーを満たしており、したがって、トランザクションおよびすべてのポリシープログラム出力は、一緒に結び付けられて、台帳に含めるために合意システムに送信され得る。

【0188】

しかし、合意システムシステムは、シールされたウォレットがポリシーを正しく評価したということを信用しないことがある。さらに、ポリシーへの一部の入力が機密である（したがって、送信者のウォレットがそれらの値をネットワークに公開しない）ため、合意システムは、ポリシープログラム自体の正しさを検証できないことがある。この行き詰まりを解決するために、送信者のウォレット構成要素は、送信者のウォレット構成要素がプログラムを正しく評価したということのゼロ知識証明を生成し、この証明をトランザクションに添付する。

【0189】

「非対話式ゼロ知識（ＺＫ：zero-knowledge）証明システム」は、２つの論理的構成要素（証明器および検証器）を含む周知の暗号技術である。証明器は、「証拠」として知られている何らかの秘密データを、所与のデータ内の何らかの数学的関係の記述である「ステートメント」と共に、入力として受け取る（多くの場合、ステートメントは、非秘密データである「インスタンス」と、証拠およびインスタンスを両方とも含む何らかの数学的関係の記述である「関係」とに、さらに分離される）。この数学的関係が有効である場合、証明器は「ＺＫ証明」を生成することができ、ＺＫ証明自体はデータオブジェクトである。検証器構成要素は、ＺＫ証明およびステートメントを入力として受け取り、証明が有効かどうかを判定する。検証器が、所与の証明が有効であるということを決定した場合、このことは、証明器がステートメントを満たす正しい秘密入力を実際に知っていたということを、非常に高い確率で示す。コンピュータプログラムの文脈では、コンピュータプログラムの入力および出力は、データと見なされてよく、プログラム自体は、ステートメントを定義する数学的関係として扱われてよい。前述したように、ポリシープログラムは、プログラムの入力データと出力データの間の数学的関係と同等に扱われることが可能であり、したがって、入力データの一部が検証器に与えられない場合でも、何らかの入力を前提として、コンピュータプログラムの出力が正しいということを証明するために、ＺＫ証明が使用され得る。

【0190】

特に、本システムは、効率およびセキュリティの特性を追加した非対話式ゼロ知識証明システムの形態であるゼロ知識の非対話的知識論証（ｚｋ－ＳＮＡＲＫ：zero-knowledge non-interactive arguments of knowledge）を利用することができる。本システムは、類似する特性を有するが、証明がデータオブジェクトでなく、証明器および検証器によって実行される対話式プロトコルであるという点が異なる、「対話式ゼロ知識証明システム」も利用することができる。

【0191】

トランザクションを作成するために、トランザクション送信者によって使用されるウォレット構成要素は、適切なゼロ知識証明システムのための証明器構成要素を組み込む。ポリシープログラムが評価された後に、証明器は、プログラムの出力が正しいということ、およびトランザクション自体が正しく形成されたということの証明を構築する。次に、ウォレットプログラムは、トランザクションを、非秘密プログラム入力および出力ならびにゼロ知識証明と結合する（場合によっては、非秘密入力および出力は、すでに知られているか、またはトランザクション検証器によって計算されることがある。その場合、トランザクション検証器がどこで必要なデータを取得するべきかを知っているということを条件として、それらの入力がトランザクションに明示的に添付される必要はない）。トランザクションに添付されたこの追加データは、ＣＲＡＩを含む。次に、ＣＲＡＩによって拡張されたトランザクションデータが、台帳ネットワークに送信され、１つまたは複数のトランザクションバリデータ構成要素が、ゼロ知識証明システムの検証器構成要素を組み込む。１つまたは複数のバリデータは、基礎になる合意システムによって指定されたルールに従って、トランザクションデータを検証し、ゼロ知識証明が有効であるということも検証する。両方の検証手順が成功を示す場合、トランザクションは、有効なシールされたトランザクションとして受け入れられる。台帳ネットワーク内のトランザクションの含有は、ゼロ知識証明の有効性を条件としてもしなくてもよい。

【0192】

場合によっては、合意システムのルールを使用してゼロ知識証明および／または他のＰＡＳトランザクション検証ルールの妥当性を確認するために、基礎になる合意システム（例えば、ビットコイン）を利用することも、または変更することもできないことがあるということが理解されるであろう。その場合、ＣＲＡＩがトランザクションに添付され、分離したバリデータ構成要素および／またはトランザクション受信者自身によって妥当性を確認され得る。したがって、ＰＡＳは、ＣＲＡＩによって拡張されたトランザクションデータが、オーバーレイバリデータ（overlay validator）と呼ばれる新しいバリデータによってチェックされることを可能にするように、構成されてよく、オーバーレイバリデータは、基礎になる合意システムのバリデータと異なってよい。ＰＡＳを使用する関係者は、オーバーレイバリデータに依存し、かつ／または関係者自身の妥当性確認を実行して、基礎になる合意システムの状態の一部であることに加えて、ＰＡＳに有効であり、したがって、トランザクションの適合するプール内にあるトランザクションを認識する。基礎になる合意システムの状態に現れるが、ＰＡＳルールの検証に合格しないすべてのトランザクションは、次のように処理されてよい。トランザクションがシールされたアセットを含まない場合、トランザクションはＰＡＳとは無関係である。トランザクションがシールされたアセットを含む場合、ポリシーによって決定されたアクションが実行される。例えば、このことは、（例えば、前述したように）送信者によってアセットの「シールを破ること」と見なされてよい。

【0193】

一部の合意システムは、基礎になる合意層のバリデータによってアクセスされ得る構造化された方法で、トランザクション内にＣＲＡＩを格納するように構成されることがある。他の合意システムは、ＣＲＡＩを、オーバーレイバリデータによって推論される不透明なデータ（例えば、ビットコインブロックチェーンにおけるＯＰ＿ＲＥＴＵＲＮデータ）としてのみ格納するように構成されることがある。他の合意システムは、ＣＲＡＩをトランザクションと共に格納することができないことがあり、またはそのように格納するために余分なコストを課すことがあり、したがって、トランザクションに関連付けられたＣＲＡＩが、実際のトランザクションを参照する代替の位置に格納されることがあり、またはこの逆も同様である。当業者は、これらの代替案の各々が、合意システムによってＣＲＡＩの妥当性が確認され、ＣＲＡＩが合意システムの台帳に直接組み込まれる、好ましい実施形態に類似する特性を提供するということを認識するであろう。

【0194】

一部の既存の合意システムが、合意システムのトランザクションルールの一部として、ゼロ知識証明を検証するための準備を含むということに、注意するべきである。例えば、イーサリアムは、イーサリアム仮想マシン（ＥＶＭ：Ethereum Virtual Machine）によって検証される「スマートコントラクト」機能を含む。ＥＶＭによって現在サポートされている１つの動作は、所与のゼロ知識証明が有効であることを保証する、特定のＺＫ証明システムのためのＺＫ検証動作である。好ましい実施形態では、合意システムにとってネイティブな機能を使用して、ゼロ知識証明の妥当性確認が発生する。必要に応じて、この機能が追加されるか、またはネットワークの外側で実行されてよい。

【0195】

送信者不透明ポリシー
場合によっては、ポリシープログラムは、トランザクションを生成する送信者のウォレットが使用できない選択された入力に対して、推論しなければならない。そのようなポリシープログラムの非限定的な例としては、疑わしい活動の報告（ＳＡＲ）を生成するポリシープログラムが挙げられ、ＳＡＲを生成するための正確な条件を関係当局が公開することが望ましくないことがあり、同様に、制裁措置を取られた関係者のリストまたは他の基準を公開することが望ましくないことがある。同様に、ポリシーは、送信者ではなくトランザクション受信者に知られている入力に対して推論することがある。この入力は、受信者の識別情報証明の機密の詳細を含むことがある。

【0196】

ポリシープログラムへの一部の入力が送信者に知られていない場合、これらのポリシーは、完全に、または部分的に「送信者不透明」と呼ばれる。そのようなポリシーの結果は、プログラムへの入力が送信者に知られていない場合に、送信者がポリシーを容易に評価してプログラム出力を計算することができないということである。したがって、送信者は、前の手法によって必要とされるように、そのような入力および出力に対してゼロ知識証明を計算することができない。

【0197】

そのようなポリシーを評価するために、本システムは、非対話式二者計算（ＮＩ－２ＰＣ：non-interactive two-party computation）システムとして知られている暗号システムを利用することができる。

【0198】

二者計算（２ＰＣ）は、機密性の保証を維持しながら、２つの構成要素（生成器および評価器）が何らかのプログラムまたは回路を評価できるようにする技術である。具体的には、２ＰＣでは、各関係者がプログラム入力の何らかの事前に合意されたサブセットを提供し、各関係者がプログラム出力の何らかの事前に合意されたサブセットを受信する。これらのシステムの極めて重要なセキュリティ特性は、関係者がプログラム出力の適切な部分のみをそれぞれ学習し、他の関係者の入力に関する情報も、プログラムを評価する過程で発生したどの中間値も学習しないということである。２ＰＣは、通常、二者が計算ごとに多くのデータメッセージを交換する、対話式プロセスとして実施される。しかし、特殊な変形である非対話式２ＰＣは、単一のメッセージをブロードキャストすることによって、評価器が入力変数のサブセットの特定のデータ値に関与することを可能にする。その後、生成器の関係者Ｂは、残りの入力変数について自分自身の値を選択し、第２のメッセージを評価器に返送することができる。最も重要なこととして、評価器によってブロードキャストされたメッセージは、評価器の入力を公開せず、生成器によって送信されたメッセージは、生成器の入力を公開しない。プロセスの最後に、評価器は、プログラムの適切な出力値のみを学習する。ＮＩ－２ＰＣシステムの重要な利点は、評価器が入力値を変更することを望む任意の時点で、評価器が、メッセージをブロードキャストすることのみを必要とするということである。しかし、生成器の関係者（または生成器の役割を果たす多くの異なる関係者も）は、異なる入力値を毎回指定しながら、第２のステップを繰り返し実行することができる。これによって、二者が１つまたは複数の生成器によって提供された異なる入力に対してコンピュータプログラムを何度も評価できるようにする。

【0199】

本明細書において開示されている主題によれば、ＮＩ－２ＰＣは、送信者不透明ポリシープログラムを実現するために利用されてよい。そのようなポリシーを実現するために、ある関係者、例えば、ＳＡＲを施行することを望むポリシー作成者は、評価器を操作する。この関係者は、ポリシープログラムへの一部の秘密入力を選択し、次に、評価器のメッセージを、ポリシーを使用することを望むすべての関係者にブロードキャストする（「ブロードキャスト」という用語が、メッセージをすべての関係者に配信すること指すということが、理解されるであろう。評価器の入力が変化する可能性が低い場合、このブロードキャストは、メッセージをポリシープログラムと共に配布することによって、例えば台帳に書き込むことによって、実現されてよい。しかし、配布のための他のメカニズムも使用され得る）。各送信者のウォレットは、ＮＩ－２ＰＣシステムの生成器構成要素を組み込む。送信者のウォレットは、評価器によって生成された第１のメッセージに加えて、ポリシープログラムを、送信者に知られているすべてのポリシープログラム入力と共に受信する。送信者のウォレットは、ＣＲＡＩの一部としてトランザクションに、および／または任意の他の適切な位置に添付される第２のメッセージを出力する。この第２のメッセージが正しく形成されることを保証するために、送信者は、前のセクションで説明された手法と同じ手法を使用して、正しい形成を示すゼロ知識証明を添付してよい。最後に、元の関係者は、評価器を使用してプログラム出力を計算するか、または元の関係者は、評価を実施するために必要な情報を第三者に与えることによって、この手順を第三者に委任することができる。

【0200】

一部の例では、ポリシープログラムは、部分的に送信者不透明であり、つまり、送信者にすべて完全に知られている入力を使用して一部のポリシー出力が計算され得るが、他のポリシー出力は計算され得ない。このような場合、ポリシープログラムを２つのサブプログラムに分割することが望ましいことがあり、それらのサブプログラムは、完全に送信者透明である、すなわち送信者に完全に知られている入力を使用する第１のサブプログラム、および送信者不透明である、すなわち送信者に知られていない一部の入力を使用する第２のサブプログラムである。その場合、各トランザクション送信者は、両方のポリシーを同時に満たす必要がある。そのためには、送信者は、そのようなトランザクションに関して上で説明されたシステムを両方とも使用する必要がある。元のポリシープログラムをサブプログラムに分割するプロセスは、標準的なプログラム分析技術を使用して自動的に実施され得る。

【0201】

検証可能な暗号化
場合によっては、ポリシープログラムが、一般人によって読まれ得ないが、選択された１つまたは複数の関係者によって読まれることが可能であってよい何らかの補助データを出力するのが望ましい。このような状況の例は、本文書において前に説明された「規制エスクロー」ポリシーの例に含まれている。

【0202】

この機能は、前述のシステムをさらに変更せずに、特定の動作をポリシープログラムに組み込むことによってサポートされ得る。具体的には、公開鍵暗号化を使用して、選択された関係者の鍵に従って暗号化された出力を生成する、ポリシープログラムが指定され得る。さらに具体的には、そのようなポリシーでは、ポリシーが、（１）暗号化される平文データを計算する方法、（２）受信者の公開鍵、および（３）任意選択的に、トランザクション生成器によって提供された何らかのランダムなビットを識別する。次に、ポリシープログラムは、暗号化手順を指定して暗号文を出力として生成する論理を組み込む（一部の実施例によれば、暗号文は入力として使用されてよい）。他の出力に関しては、その後、暗号文自体がＣＲＡＩとしてトランザクションに添付され、ゼロ知識証明が、その暗号文内に含まれるデータが正しく形成されたということを保証する。しかし、この暗号文を復号するための適切な秘密鍵を持っている関係者のみが、暗号化データを回復することができる。台帳を観察しているすべての他の関係者は、このデータにアクセスできない。

【0203】

ポリシープログラム開発者のためのこの機能をサポートするために、ポリシー開発システムは、公開鍵暗号化機能を「ライブラリモジュール」または「プリコンパイル」（すなわち、ポリシー開発者がポリシープログラムを記述するために使用できる事前に記述されたソフトウェア構成要素）として組み込むことができる。ポリシープログラムは、検証可能な暗号化の使用を暗黙的にサポートすることもできる。例えば、機密性マークアップスキーマ（confidentiality markup schema）は、開発者が、特定の関係者のみが所与の出力を使用できるということを指定することを可能にすることができ、システムは、前述の検証可能な暗号化システムを使用することによって、このポリシーを自動的に実現する。

【0204】

状態および過去のブロックチェーントランザクション
多くの場合、ポリシープログラムが過去のトランザクションから導出された情報、または場合によっては、過去のポリシーの集合から導出された情報に対して推論することが望ましいことがある。この問題は、ポリシープログラムの暗号化された出力または「コミットされた」出力として「状態」情報を記録し、このデータを各トランザクションに添付することによって実現され得る。その後のトランザクションは、台帳上の前のトランザクションを非秘密データとして参照し、この状態情報を入力として使用することができる。この参照は、イーサリアムなどのように、データに対するハッシュツリーを台帳にネイティブに組み込む台帳によって容易にされる。そのようなツリーは、トランザクションが台帳に存在するということの効率的な証明を構築するために使用され得る。ポリシープログラムは、そのような証明を入力として受け取り、証明が正しいということを検証し、その後、トランザクションデータに対して推論することができる。

【0205】

統計データ収集
上でリストされたコンプライアンスポリシーの例の一部は、個別のトランザクションの詳細を公開しない方法で、統計的集計が個別のトランザクションデータから計算されてよいということを指定する。プライバシーを保護する方法で、トランザクションに関するそのような集計統計データを収集するために、さまざまな技術が使用され得る。ここで、異なるポリシープログラムによって使用され得る複数の異なる技術、およびそれらの技術が本システムにおいてどのように使用されるかについて簡単に説明する。

【0206】

統計データを収集するための１つの手法は、統計的集計を、個別のトランザクションデータを見ることが許可され、その後、トランザクションデータから統計的集計を計算することができる、構成要素に委任することである。個別のトランザクションデータのプライバシーを保証するために、この関係者がプライバシーを公開しないということが信用されなければならない。そのような信用は、法的手段またはポリシーの手段によって、あるいは技術的手段によって、実現されてよい。この関係者は、アグリゲータと呼ばれる。

【0207】

そのような関係者が識別された後に、暗号化されたデータを含む統計的集計フィールド（ＳＡＦ）を計算するために、個別のトランザクションは、前述の検証可能な暗号化技術を使用することによって、関連するトランザクションデータをこの関係者にサブミットしてよい。その後、各トランザクションは、関連するデータを含み、アグリゲータの鍵に従って暗号化された暗号文を埋め込んでいる、そのようなＳＡＦを含む。アグリゲータは、対応する秘密鍵を所有し、トランザクションデータを受信する。次に、アグリゲータは、各トランザクションを復号して、未加工のトランザクションデータを取得することができ、この取得時に、ポリシー作成者によって許可されたとおりに、集計統計値を計算する。

【0208】

技術的観点から見て、アグリゲータは、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）またはＩｎｔｅｌのＳＧＸプロセッサなどの他の高信頼コンピューティングシステムを使用して、実現され得る。これらは、秘密データに対して計算を実行するように設計されたプログラム可能なシステムであり、内部データへのアクセスを防ぎ、実行されているプログラム論理の改ざんも防ぐ、論理的対抗手段および物理的対抗手段の両方をそれぞれ含む。Ｉｎｔｅｌ ＳＧＸなどの一部のシステムは、ソフトウェア証明署名（software attestation signature）を生成する能力も含む。これらの署名は、特定のプログラムを実行している有効なプロセッサによって出力が生成されたということを、リモートの関係者が保証され得るように、信頼できるシステムが出力を生成し、これらの出力に「署名する」ことを可能にする。統計的アグリゲータは、そのようなプログラムを指定し、公開鍵と共に証明を公開することをそのプログラムに要求することによって、実現され得る。

【0209】

上記の信頼できるアグリゲータの手法の制限は、ユーザが、アグリゲータシステムが正しく動作しており、セキュリティを侵害されていないということを、信用しなければならないことである。代替手法は、パブリックな差分プライバシー技術を使用することによって、信頼できるアグリゲータの必要性を完全になくす。

【0210】

差分プライバシー技術は、当技術分野においてよく知られている。これらの技術は、統計的「ノイズ」を個別のデータレコードに追加し、これらのデータレコードがそのレコード内のデータに関する解決の手掛かりとなる情報を公開しないようにすることによって機能する。しかし、それと同時に、完全な集合に対する有用な統計的集計を回復するために、多くのそのようなレコードの集合が結合され得る。このための１つの周知の技術は、ランダム化された応答である。関係者が２つの可能な値（例えば、はい／いいえ）を含む１つのデータを報告することを望む場合、関係者は、最初にコインを投げることができる。コインが「表」を見せた場合、関係者は実際の回答を報告する。しかし、コインが「裏」を見せた場合、関係者は、コインを再び投げ、実際の結果ではなく、第２のコインを投げた結果を報告する。このようにして、すべての個別の報告は、真の結果または意味のないランダムな回答のいずれかを表すことができる。したがって、単一の結果に関する有用な情報が決定され得ない。それと同時に、任意の関係者は、多くのそのような応答を集計し、ランダムな回答を補正することによって、近似的合計を計算することができる。この計算は、結果の大きい十分なセットに対して、実際のデータの合計に近い回答を提供する。差分プライバシー技術は、このアイデアを、数値データおよび他のテキストデータなどの他の形態のデータに一般化することができる（例えば、文字列などの任意のデータ要素のセットに対して計算されるヒストグラムであり、このヒストグラムは、ハッシュ関数を使用して必要な要素のダイジェストを計算し、次にこのダイジェストを使用して要素をブルームフィルタ内に配置することによって、実現されてよく、ブルームフィルタは、設定された帰属関係を記録するための特殊なデータ構造である。ノイズが、ブルームフィルタに追加され得る）。

【0211】

この手法を可能にするために、コンプライアンスポリシープログラムは、ポリシーによって計算され、適切な量のランダム化されたノイズを使用して拡張された１つまたは複数のトランザクションデータ要素を含んでいる統計的集計フィールド（ＳＡＦ）を指定することができる。さらに具体的には、ポリシープログラムは、これらの報告を計算するために、どのトランザクションデータが使用されるか、報告がどのように書式設定されるか、および真のトランザクションの値を曖昧にするためにノイズがどの程度正確にｂ４４ｅｒｉｆｙ４４ｄされるかを識別する役割を担う。ポリシープログラムは、ノイズによって拡張された値を計算するために、送信者のウォレットによって提供された乱数も使用する。最後に、ポリシープログラムは、各報告された値をＳＡＦ出力に結合する。前のセクションで説明された施行技術は、合意システムの参加者が、ＳＡＦがトランザクションデータに添付され、正しく計算されることを検証できるようにする。

【0212】

そのようなＳＡＦフィールドを含む複数のトランザクションを前提として、アグリゲータは、多くのトランザクションからのＳＡＦデータを結合するプロセスを実行することができる。その場合、アグリゲータは、どの秘密鍵も所有する必要がなく、したがって、信頼できない関係者として扱われ得るということに注意されたい。

【0213】

秘匿マルチパーティ計算（ＭＰＣ：Secure Multiparty Computation）、準同型暗号化（ＨＥ：Homomorphic Encryption）、および暗号化によるプログラム難読化（ＰＯ：Program Obfuscation）は、完全性制約およびプライバシー制約に従って、プライベートな入力および複数の関係者を伴う計算を実行するための強力な一般的技術である。上記のようなさらに特殊な技術が知られていないか、使用できないか、または比較的に非効率的である場合、本システムは、ＭＰＣ、ＨＥ、またはＰＯを使用して、ポリシーによって規定された挙動を実現してよい。

【0214】

ブロックチェーン間の動作
ＳＡＰは、ＣＲＡＩを維持するように、ならびに複数の種類のシールされたアセットを含んでいるトランザクションおよび／または複数のブロックチェーンに基づく合意システム（または仮想アセットを表すための他のシステム）にわたってコンプライアンスポリシーを施行し、統一された適合するプールを作成するように構成されてよい。そのような構成では、（「送信者透明ポリシーおよびブロックチェーンの統合」で前述したように）各ブロックチェーンが、ＣＲＡＩを統合し、トランザクションの妥当性を確認する異なる手段を有することがある。

【0215】

ＳＡＰは、例えば、実施例１２（分散型アプリケーションの管理）および／または実施例１５（融資アセット認識サービス）を参照して上で説明されたように、複数のブロックチェーンを伴うアセットの移動を実行するサービスとの統合によって、複数のブロックチェーンにわたってＣＲＡＩを伝達してよく、ＡＡＳを形成するように、そのようなサービスを変更または拡張してよい。この実施形態では、ＡＡＳは、１つのブロックチェーンから別のブロックチェーンにＣＲＡＩを伝搬する。

【0216】

ＳＡＰは、ブロックチェーン間の注釈を追加する機能をシールされたウォレットのソフトウェアに埋め込むことによって、複数のブロックチェーンにわたってＣＲＡＩを伝達してもよい。例えば、ＳＡＰは、ＳＡＰが１つのブロックチェーンに追加するＣＲＡＩ内に、別のブロックチェーン上の関連するトランザクションへの参照を含めることができる。

【0217】

仮想アセットのブロックチェーン間の表現を実装するプロトコルおよびサービスは、当技術分野においてよく知られている。例えば、ＷＢＴＣ（wrapped Bitcoin：ラップされたビットコイン）、ｔＢＴＣ、およびｒｅｎＢＴＣはすべて、イーサリアムブロックチェーン上のＢＴＣを表す既存の仮想アセットであり、そのようなアセットの作成および償還のためのさまざまなメカニズムを使用する。そのようなサービスおよびプロトコルは、複数のブロックチェーンにわたってＣＲＡＩを伝達するＡＡＳを形成するように、拡張されてよい。例えば、シールされたＢＴＣコインを預金することによってラップされたＢＴＣトークンが作成される場合、ラップされたＢＴＣのＡＡＳの実装は、ＣＲＡＩを新たに作成されたラップされたＢＴＣトークンに添付してよく、このラップされたＢＴＣトークンは、元のＢＴＣコインに添付されたＣＲＡＩを伝搬する。

【0218】

拡張性およびロールアップ
一部の合意システムは、所与の期間内に記録され得るトランザクションの数に対する制限を課す技術的特徴を有する。これらの制限は、通常、システムによって格納されて配布されなければならないトランザクションデータのサイズに加えて、各トランザクションを検証するために必要とされる計算時間に応じて変化する。この問題に対処するための周知の手法は、合意システムによって格納されて検証されることを必要とするデータの量を圧縮するために「ロールアップ」を利用することである。

【0219】

そのような「ロールアップ」構成では、１つまたは複数のサーバが関連するトランザクションのシーケンスを収集し、完全なシーケンスの代わりになるコンパクトな表現を計算する。したがって、基礎になる合意システムは、元のトランザクションを格納することも検証することも必要とせず、コンパクトな表現（ロールアップサマリー）を検証して格納することのみを必要とする。

【0220】

多くのそのような構成は、当技術分野においてよく知られている。例えば、「ＺＫロールアップ」は、暗号ゼロ知識証明（検証可能なコンピューティングとも呼ばれる）技術を使用して、ロールアップサマリーによって表されたすべてのトランザクションが正しく検証されたということ、およびロールアップサマリーがそれらのトランザクションの評価の最終結果を表すということの、短い数学的証明を生成する。この証明は、合意システムによって検証され得る。「楽観的ロールアップ」では、ロールアップサマリーは、サマリーが正しいということの数学的証明を伴わない。代わりに、システムは通常、個別のトランザクションを検証するための経済的誘因を第三者に提供し、第三者が支払いを回収できるようにする。これは、合意システムが検証できる「詐欺の証明」、およびサーバによって債券として納められたアセットの使用によって実行され、無効であることが判明したロールアップサマリーを所与のサーバが承認したということを示す詐欺の証明の提出者が、それによって、そのサーバの債券を回収する資格を与えられるようにし、それによって、サーバの不正行為にペナルティを科すようにもする。ロールアップは、サーバの委員会（committee of servers）を含むマルチパーティ計算プロトコルを使用して実現されることも可能であり、ロールアップサマリーが信頼できると見なされるために、サーバの大部分がロールアップサマリーを承認する必要があり、この承認は、不正を行っている委員会メンバーにペナルティを科す楽観的ロールアップと結合されてよい。

【0221】

合意システムでの高い性能を保証するために、シールされたトランザクションは、ロールアップシステムによって処理され得る。このロールアップシステムは、ユーザから受信されたトランザクションを処理し、任意選択的にＣＲＡＩの構造を検証し、これらのトランザクションからロールアップサマリーを計算する、１つまたは複数のサーバを含む。次に、ロールアップシステムは、例えば、ロールアップサマリーが正しく計算されたということの、検証可能な計算またはＺＫ証明を生成することができる。代替として、ロールアップシステムは、ロールアップサマリーおよび個別のトランザクションの検証を検証するための機会、ならびに合意システムが詐欺を検出できるようにする１つまたは複数の詐欺の証明を生成するための機会を、第三者に提供することができる。後者の事例では、ロールアップシステムは、不正を行っているサーバによってすでに納められている債券を、詐欺の証明を提示した関係者に放出してよい。

【0222】

シールされたアセットを含んでいるトランザクションの正しさを検証するために、検証しているサーバは、基礎になる合意システムのルールによって記述されている、トランザクション自体の正しさの妥当性を確認しなければならない。加えて、サーバは、暗号によってトランザクションに結び付けられている、関連付けられたＣＲＡＩの正しさの妥当性を確認しなければならない。一部の実施例によれば、基礎になる合意システムのトランザクション形式は、ＣＲＡＩをトランザクション内に含めるための手段を提供し、合意システムの検証ルールは、ＣＲＡＩを検証することができる。そのような場合、２つの検証動作が単一の動作に結合される。ロールアップを計算するために、サーバは、各トランザクションおよび関連付けられたＣＲＡＩを検証し、トランザクションのセットならびに各トランザクションの入力および出力に対して、ハッシュデータ構造（例えば、マークルツリーまたは「暗号累算器（cryptographic accumulator）」）の出力を含み得るサマリーの証明を計算しなければならない。便宜のために、本システムは、入力および出力ならびに他の中間トランザクションの詳細を別々に含むための複数のハッシュデータ構造を生成してよい。これらのデータ構造が結合されて、ロールアップサマリーを形成してよい。

【0223】

ロールアップサーバが検証を省略せず、正しくないロールアップサマリーを生成しないことを保証するために、ロールアップサーバは、任意選択的に、第三者がロールアップサマリーにおける不適切な構造を識別できる場合に第三者に放出され得る金融債券（ある量の仮想アセット）に関与してよい。これは、「詐欺の証明」の追加によって実行されてよく、詐欺の証明自体は、ロールアップサマリーの下位構成要素が適切に計算されなかったことを示すマークルツリーの一部を含む。詐欺の証明の他の形態がサポートされてよい。

【0224】

ロールアップシステムは、ロールアップサーバによって要約されたトランザクションの所与のシーケンスが、内部で一貫性があり、合意システムによって承認された他のトランザクションと競合しないということを保証する。この保証は、「二重支払い」および／または顧客によって送信された金額が顧客の残高を超える状況を防ぐために必要とされる。この保証は、トランザクションに添付されたＣＲＡＩ、証明の更新もしくは取り消し、および／またはポリシーの更新などの、ＳＡＰによって処理された補助情報に関連する矛盾を防ぐためにも必要とされる。したがって、ロールアップシステムは、一連のトランザクションがロールアップサーバによって処理されている最中に、競合するトランザクションまたは更新が発生しないことを保証することを、容易にすることができる。

【0225】

この保証は、特定の適合するプールに関連するすべてのトランザクションを処理する責任を１つまたは複数の指定されたロールアップサーバに委任することによって実現されてよい。この構成では、関連するプールに影響を与えるトランザクションは、合意システムによって直接承認され得ず、指定されたサーバを除いて、他のロールアップサーバによって承認され得ない。一方、指定されたサーバは、すべてのＣＲＡＩ、証明の更新もしくは取り消し、およびポリシーの更新を含めて、すべてのトランザクションが確定された順序付けを有し、内部で一貫性があるということを保証するように構成されてよい。特定の適合するプールに関連付けられた１つまたは複数のサーバの選択は、定期的に変化してよい。一部の実施例によれば、合意システムによって１つのロールアップのみが承認されるということを条件として、複数のサーバが、トランザクションを同時に収集し、競合するトランザクションまたは順序付けを含んでいるロールアップを生成してよい。

【0226】

ロールアップサーバは、アセットが送信元の適合するプールから送信先の適合するプールに送信されるトランザクションを認識するように構成されてよい。さらに、合意システムおよびロールアップサーバは、資金に関するすべての必要な情報（例えば、所与の適合するプールへの移動の知識）を各ロールアップサーバのロールアップサマリーから抽出し、この情報を、この情報の知識を必要とするロールアップサーバに配信するように構成された清算メカニズムを含んでよい。同様に、ＣＲＡＩ、証明の更新もしくは取り消し、およびポリシーの更新が、この情報の知識を必要とするロールアップサーバに配信される。

【0227】

１つの適合するプールから別の適合するプールへのそのような移動が発生する場合、所与のロールアップサーバが、次の２つの異なる方法のうちの１つで、これらのトランザクションを処理してよい。（１）移動元の適合するプールに関連付けられたロールアップサーバは、移動先の適合するプールに移動されている資金を支払うその後のトランザクションを処理することを拒否してよい、または（２）移動元の適合するプールに関連付けられたロールアップサーバは、トランザクションが他のロールアップサーバによって管理されているトランザクションと競合しないことが保証されるということを条件として、トランザクションが移動先の適合するプール内の資金を支払うことを可能にすることによって、例外を認めることができる。後者の条件は、例えば、その後のトランザクションが他のサーバによって処理されているトランザクションと競合することができない状況において発生することがある。

【0228】

上記の説明は、合意システムと異なるロールアップサーバを考慮するが、これは単に説明の便宜のためであり、ロールアップサーバの機能の一部またはすべてが、合意システムに統合されてよい。例えば、中央銀行デジタル通貨（ＣＢＤＣ：Central Bank Digital Currencies）は、合意システムを実装するために集中型システムを使用することがあり、同じ集中型システムが、トランザクションを承認し、ロールアップサマリーを生成する役割を担うこともある。これらのシステムは、同じ（信頼できる）関係者によってすべて操作されるため、ロールアップサマリーが正しく計算されたということの証明を必要としないことがあり、不適切なサマリーを検出するための詐欺の証明メカニズムも必要しないことがある。

【0229】

規制エスクロープロバイダのトレース
（例えば、前述したように）規制エスクローを提供するシステムは、例えば、エスクローされた情報を復号するための特定の許可および／またはそれらの許可に従って指定された条件に対応するように、任意の適切な方法で構成されてよい。

【0230】

一部の実施例によれば、ポリシーは、そのポリシーに従って台帳に記録されたすべてのエスクローＣＲＡＩ（escrow CRAI）を復号できる１つまたは複数の鍵を保持する単一のエスクロープロバイダを定義する。エスクロープロバイダは、（例えば、暗号しきい値署名を採用することによって）復号を承認するために大部分または全員の合意を必要とする委員会として実現されてよい。これは、エスクロープロバイダの役割を仮定する単一の規制機関において発生することがある。

【0231】

他の実施例によれば、ポリシーは、複数のプロバイダを定義し、各プロバイダは、ネットワーク上で作成された特定のトランザクションのみのための復号鍵を持っている。エスクロープロバイダは、例えば、顧客による目的のために選択されたＶＡＳＰまたは交換であってよく、認証情報をユーザに発行した識別情報プロバイダと同じ関係者であってもなくてもよい。

【0232】

複数の規制エスクロープロバイダが特定のトランザクション上のＣＲＡＩを復号できる実施例によれば、復号を実行するために適用できる規制エスクロープロバイダを見つけるためのプロセスが必要とされる。このプロセスを実現するための１つまたは複数のメカニズムが提供されてよい。

【0233】

一部の実施例によれば、このメカニズムは、各関連するトランザクションにおいてＣＲＡＩ内のラベルを提供することを含む。このラベルは、どのエスクロープロバイダがトランザクションを復号できるかを示す。

【0234】

他の実施例によれば、このメカニズムは、エスクロープロバイダによって暗号文を復号しようとする試みが、復号が成功したかどうかを示すように、エスクロープロバイダの鍵を使用して暗号化された暗号文を提供することを含む。その後、各プロバイダは、プロバイダの鍵を使用して暗号文を復号しようとすることができ、暗号文の対象となるプロバイダのみが成功する。

【0235】

さらなる実施例によれば、このメカニズムは、どのエスクロープロバイダが各トランザクションに対して責任を負うかを決定するためにトランザクションを調べる役割を持つ、第三者の「エスクロー識別子」を定義する。その後、この関係者は、規制機関、調査員などを、トランザクションごとに、関連するエスクロープロバイダに向けることができる。それに応じて、この第三者（または複数のそのような第三者）のみが、この情報を見ることができ、一般人は、この情報を使用することができない。したがって、各トランザクションは、エスクロー機関の暗号化された識別子に加えて、識別情報のエスクローに必要とされる任意の通常のＣＲＡＩを含んでよい。この暗号化は、「エスクロー識別子」の関係者に属する鍵を使用して実行され、この関係者が識別子を復号できる。次にこの関係者は、回復された情報を使用して、調査員を正しい位置に向ける。

【0236】

分散型アプリケーション（ＤｅＦｉ）
近年、複数の分散型金融アプリケーションが、デジタル通貨の金融サービスを提供するために展開されてきた。「ＤｅＦｉ」アプリケーションとして知られているこれらのシステムは、通常、「スマートコントラクト」を使用して実装され、スマートコントラクトは、合意システムによって評価され、デジタルアセットの流れをプログラムによって制御することができる、特殊なコンピュータプログラムである。ＤｅＦｉアプリケーションは、（交換の注文控え帳、価格オラクルなどの）集中型の構成要素を含んでよいが、ＤｅＦｉシステムは、通常、集中型の実体への依存を避けるように設計される。特定の管轄区域内に位置する集中型の実体の欠如は、より堅牢なシステムにつながることができるが、規制コンプライアンスをより困難にもする。

【0237】

アセット交換などの集中型アプリケーションの場合、コンプライアンスポリシーは、発信トランザクション上のＣＲＡＩを正しく更新することを可能にするアセット認識サービス（ＡＡＳ）の役割を果たす関係者を指定してよい。分散型アプリケーションでは、対応する役割を実行できる信頼できる関係者が存在しないことがある。そのため、信頼できる関係者を使用せずにコンプライアンス情報を正しく記録することができるシステムが必要になる。

【0238】

ＤｅＦｉアプリケーションと情報をやりとりするときにＣＲＡＩの正しい準備を施行することは、複数の異なる方法のうちの１つで実行され得る。どの方法を使用するべきかの選択は、例えば下で説明されるようなＤｅＦｉアプリケーションの性質に依存する。

【0239】

ＤｅＦｉアプリケーションとのユーザの情報のやりとりは、次のように特徴付けられ得る複数の相互作用段階を含む。
（ａ）預金：ＤｅＦｉと情報をやりとりするために、シールされたアセットの所有者は、仮想アセットを、シールされたウォレットからＤｅＦｉアプリケーションによって制御されているスマートコントラクトのアドレスに送信する。
（ｂ）ユーザのやりとり：この段階の間に、シールされたアセットの所有者は、アセットがどのように処理されるかを説明するコマンドを発行することによって、ＤｅＦｉアプリケーションと情報をやりとりしてよい。一部のＤｅＦｉアプリケーションでは、この相互作用段階が発生しない。
（ｃ）第三者の情報のやりとり：ＤｅＦｉアプリケーションは、アセット所有者からコマンドを受け取ることに加えて、追加の預金および追加のコマンドの両方を第三者から受け取ってよい。これらの第三者は、シールされたアセットの所有者であってよく、またはシールされたアセットのシステムへの参加者でなくてよい。
（ｄ）引き出し：アセット所有者は、アセットをＤｅＦｉアプリケーションからシールされたウォレットに引き出してよい。これらのアセットは、もともと預金されていたアセットと同じであってよく、または異なる種類および／または量のアセットであってよい。

【0240】

これらの相互作用段階は、必ずしも厳密なシーケンスで発生しない。例えば、ＤｅＦｉアプリケーションは、任意の順序で交互配置された複数の預金、引き出し、およびコマンドの情報のやりとりを受け取ってよい。これらの情報のやりとりは、例えば、１つの種類のアセットが預金され、同時に別の種類のアセットが引き出される取引トランザクションにおいて、同時に１つまたは複数を実行してもよい。段階の重複または混合が存在してもよく、例えば、自動マーケットメーカー（ＡＭＭ）サービスでは、１つのトランザクションでアセットが預金され、預金を表すトークン（「流動性資産プロバイダ」トークン）が引き出され、その後のトランザクションでトークンが預金され（すなわち、償還され）、アセットが引き出される。

【0241】

さらに、規制の重要性を有すると見なされるイベントを引き起こすことがある、預金および引き出し以外の情報のやりとりが存在してよい。例えば、ＤｅＦｉコマンドは、価値のあるアセットを第三者に送信するための契約を指示してよい。

【0242】

手法１：ホワイトリストＤｅＦｉアプリケーション
一部の実施例によれば、ＤｅＦｉアプリケーションは、ＤｅＦｉアプリケーション全体を、本明細書では分散型アセット認識サービス（ＤＡＡＳ：Decentralized Asset Aware Service）と呼ばれる信頼できるアプリケーションとして指定することによってサポートされてよい。集中型ＡＡＳと同様に、ＤＡＡＳは、サービスからの預金および引き出しに対してＣＲＡＩの存在を施行するように構成されてよい。ユーザがアセットを預金した後に、ユーザがアセットを引き出す前に行われるＤＡＡＳの内部動作は、必ずしもＣＲＡＩの施行に関連すると見なされない。したがって、アセットを預金し、後でアセットを引き出すユーザは、ＣＲＡＩをこれらの２つのトランザクションの各々に添付する必要がある。しかし、スマートコントラクトが混合されたアセットを伴う動作を実行する場合（それらの動作がユーザによって要求されたとしても）、これらの動作は、ＣＲＡＩの施行に関連するとして扱われない。

【0243】

ポリシーの作成者によってスマートコントラクトの内部動作が十分に理解されていて、スマートコントラクト自体が、規制の施行を回避するために使用され得ないということが分かっている場合に、この手法が適切であることがある。そのような場合、ポリシー作成者は、特定のＤｅＦｉアプリケーションのＣＲＡＩの処理の例外を進んで許可することがある。多くのＤｅＦｉシステムの利点は、ＤｅＦｉシステムが、通常、ポリシー作成者によって分析されて監査されることが可能なスマートコントラクトプログラムに基づくということである。したがって、ポリシー作成者は、特定のコントラクトが規制コンプライアンスに対する高いリスクのあるアクションを実行しないということを知ることになる。したがって、ポリシー作成者は、許可されたスマートコントラクトのアドレスの「許可リスト」をポリシープログラムに含めることができる。代替として、ポリシー作成者は、ポリシープログラム内で、許可されたＤＡＡＳプロバイダの署名されたリストが、外部の入力としてポリシーに提供されてよいということを指定することができる。

【0244】

この手法の利点は、引き出しおよび預金が通常はシールされたウォレットによって（シールされたウォレットとの間で）開始されるという事実のため、シールされたウォレットによってＣＲＡＩの構築が実行され得るということである。シールされたウォレットは、必ずしも、スマートコントラクト内の論理を認識または理解する必要がなく、シールされたウォレットの所有者または第三者によってアプリケーションに発行されたいずれかのコマンドに対して推論する必要もない。

【0245】

実際に、規制に適合するインフラストラクチャ内で安全に使用するにはリスクが高すぎると見なされるスマートコントラクト（例えば、スマートコントラクトのアドレスおよび／またはプログラムコード）は、「阻止リスト」に追加されてよく、阻止リストは、ポリシープログラムに含まれてよく、かつ／または何らかの信頼できるソースからの別の入力として、ポリシープログラムに提供されてよい。したがって、シールされたアセットのユーザは、アセットをこれらのシステムに決して送信することができない。

【0246】

手法２：ＤｅＦｉアプリケーションの活動に関する推論
他の実施例によれば、アプリケーションは、ポリシー作成者が「混合」と見なす方法で使用されることがあり、すなわちアプリケーションは、１つの方法で使用される場合には「適合する」と見なされるが、異なる方法で使用される場合に、規制の保証に違反し、かつ／またはアセットに関連付けられた規制のリスクを増やすと見なされる。例えば、ポリシー作成者が受動的投資を実行するＤｅＦｉアプリケーションは、「安全」と見なされることがあるが、ユーザが能動的に支払先およびローンを指定するＤｅＦｉアプリケーションは、「安全」と見なされないことがある。代替として、ユーザが実行した動作の特定のセットが、システムがより洗練された方法でそれらを評価できるように、ＣＲＡＩに格納されてよい。

【0247】

システムは、ＣＲＡＩの決定を、ユーザがアセットを預金するときと、ユーザがアセットを引き出すときとの間に、ＤｅＦｉスマートコントラクトで実施された動作の特定のセットに基づいて行ってよい。許可される動作のセットは、ポリシープログラムによって決定される。例えば、ポリシープログラムは、ユーザによってコマンドの特定のセットが発行され場合に、ユーザが（有効なＣＲＡＩを含む）契約を取り消すことを許可しないことがある。ユーザは、取り消しに関するポリシーを満たすために、適切なコマンド（および適切なコマンドのみ）が発行されたということを証明する何らかの方法を必要とする。この照明は、複数の方法のうちの１つで実行されてよい。

【0248】

１つの実施形態では、分離したサーバ構成要素が、ＤｅＦｉアプリケーションおよびブロックチェーン上のそのトランザクションを監視する。このサーバ構成要素は、このサービスからの離脱時に、どのコマンドが行われているか、およびそれらのコマンドが異なるシールされたウォレットのコンプライアンスおよびリスクにどのように影響を与えるかを判断する。ユーザがＤｅＦｉアプリから離脱することを望むときに、ユーザは、判断に関してこのサーバに連絡する。サーバは、必要な情報を含んでいるデジタル署名されたメッセージを提供し、この署名されたメッセージがポリシープログラムへの入力として提供され得るようにする。例えば、サーバは、シールされたウォレットのアセットがＤｅＦｉアプリに預金されていた間に、リスクが高くないアクションが行われたということを示す署名されたメッセージを発行してよく、またはサーバは、ユーザがリスクの高いアクションを実行したという警告を発行してよい、などである。ポリシープログラムは、それ自身のプログラムに従って、これらのメッセージを処理し、適切なＣＲＡＩを生成する。

【0249】

第２の実施形態では、集中型サーバが使用されない。むしろ、各シールされたウォレットの所有者が、ブロックチェーン上のＤｅＦｉアプリケーションを監視するタスクを実行し、ポリシーによって規定された基準に従うコマンドを検証して、ゼロ知識証明をＣＲＡＩの一部として生成する。この証明のステートメントは、ポリシープログラム内に含まれ得る。この実施形態は、前述の第１の実施形態と比較してあまり効率的ではないがことがあるが、例えば、複雑な監視タスクの場合に、サーバを確立して信用することの必要性を軽減することができる。

【0250】

識別情報伝達システム
前述したように、コンプライアンスシステムは、ＩＰがその機能のうちの１つまたは複数を実行するのを容易にするように構成された識別情報伝達システムを備えてよい。一部の実施例によれば、識別情報伝達システムは、ＩＰが顧客識別情報を受信すること、検証すること、および／または記録すること、ならびにサービスプロバイダが機密の顧客情報を格納する必要性を最小限に抑える方法で、この情報の一部をサービスプロバイダと共有することを容易にするように構成される。識別情報伝達システムは、顧客の識別情報および／または偽名の特定の部分の選択されたプロバイダへの配布の、顧客の許可および制御を、さらに容易にすることができる。識別情報伝達システムは、例えば、サービスプロバイダが識別情報プロバイダと直接通信せずに、サービスプロバイダが信頼性を検証することを可能にする方法で、識別情報プロバイダからのこの情報の配布を可能にするようにさらに構成されてよい。この構成は、顧客に暗号識別情報証明および／または識別情報アサーションを提供することによって可能にされてよい。

【0251】

一部の実施例によれば、識別情報伝達システムは、サービスプロバイダによって、必要とされる識別情報に関する要件を定義し、識別情報プロバイダがこれらの要件を満たすことと、識別情報プロバイダによる特定の顧客情報の保持を要求することとを容易にするように、さらに構成される。識別情報伝達システムは、サービスプロバイダが顧客識別子を比較することと、特定の顧客に関する情報を、この情報が顧客の識別情報に結び付けられるように、識別情報プロバイダおよび他のサービスプロバイダと共有することとをさらに可能にしてよい。

【0252】

一部の実施例によれば、識別情報伝達システムは、顧客の識別情報に関する情報が集中型識別情報プロバイダに格納される、集中型の構成で動作するように構成される。サービスプロバイダは、顧客識別情報に関するアサーションを取得するため、および顧客の挙動に関する更新された情報を返送するために、安全な認証されたネットワーク通信チャネルを使用して、集中型識別情報プロバイダと直接情報をやりとりする。

【0253】

一部の実施例によれば、識別情報伝達システムは、顧客の識別情報に関する情報が暗号によって認証され形態で顧客に提供され、サービスプロバイダが顧客からこの情報のサブセットを受信する、分散型の構成で動作するように構成される。サービスプロバイダからの更新情報は、（他のサービスプロバイダへの配布のための）顧客を含む、識別情報プロバイダでの位置、またはブロックチェーンなどの合意ネットワークの台帳上の位置を含むさまざまな位置に格納されてよい。

【0254】

一部の実施例によれば、識別情報伝達システムは、集中型の構成および分散型の構成の各々の特徴の組み合わせに従って動作するように構成される。

【0255】

識別情報伝達システムの構成要素
識別情報伝達システムは、顧客の識別情報に関するアサーションを作成するように構成されてよく、顧客は、１つまたは複数のデジタルアセットを所有および／または制御する。識別情報伝達システムは、例えば、コンピュータネットワークを経由して互いに通信するように構成された、識別情報プロバイダ、サービスプロバイダ、および顧客識別情報マネージャ（Customer Identity Manager）を備えてよい。

【0256】

識別情報プロバイダ（ＩＰ）は、政府発行の識別情報文書などの顧客識別認証情報を検証することと、各顧客に関する情報を安全に記録することとを実行するように構成される。ＩＰは、「識別情報アサーション」をサービスプロバイダに発行するようにさらに構成されてよい。そのような識別情報アサーションは、デジタル証明の形態であってよく、サービスプロバイダ自体が検証できるような方法で、顧客に関する識別情報、またはＩＰでの識別情報の存在についてサービスプロバイダに知らせるように構成される。

【0257】

サービスプロバイダ（ＳＰ）は、１つまたは複数の金融サービスを顧客に提供するように構成される。ＳＰの例は、仮想アセットサービスプロバイダ（ＶＡＳＰ）、銀行、支払い処理業者、クレジットカード発行者、および送金サービス（fund transmission services）を含んでよいが、これらに限定されない。ＳＰは、特定の顧客とのトランザクションを実行するために、識別情報の検証を必要とすることがあり、信頼できる識別情報プロバイダから識別情報アサーションを受信するように構成されてよい。ＳＰは、１つまたは複数のＳＰと情報をやりとりして顧客に関する情報を交換すること、および／または異なるＳＰが同じ顧客と情報をやりとりしていることを検証することを実行するように構成されてよい。

【0258】

顧客識別情報マネージャ（ＣＩＭ：Customer Identity Manager）は、顧客がサービスプロバイダおよび識別情報プロバイダとインターフェイスをとることを可能にするように構成される。ＣＩＭのインスタンスは、暗号通貨などのデジタルアセットを制御および格納するように構成された顧客の「ウォレット」の下位構成要素として統合されてよい。ＣＩＭは、コンピュータネットワークと通信し、それによって、ＩＰシステムおよびＳＰシステムにメッセージを送信することおよび／またはＩＰシステムおよびＳＰシステムからメッセージを受信することを可能にする。ＣＩＭソフトウェアまたはハードウェアは、顧客によって直接制御されてよく、かつ／または顧客の代わりにサービスプロバイダによって操作されてよい。一部の実施例によれば、ＣＩＭは、例えば、インターネットに接続された汎用コンピュータに接続することによって断続的にのみインターネットに接続される、専用デバイス上に実装されたウォレット（いわゆる「ハードウェアウォレット」）と統合される。一部の実施例によれば、ＣＩＭは、ソフトウェアに基づく、すなわち、インターネットに継続的に接続される汎用コンピュータにインストールされたソフトウェアに実装された、ウォレットと統合される。一部の実施例によれば、ＣＩＭは、ハードウェアウォレットと部分的に統合され、ソフトウェアに基づくウォレットと部分的に統合される。

【0259】

所与の識別情報伝達システムには、これらの構成要素の各々の複数のインスタンスが存在してよく、これらの構成要素は、互いの間で情報を交換するために、コンピュータネットワークを介して通信可能に結合される。ＩＰ、ＳＰ、およびＣＩＭという用語が、機能の所与のセットを説明しており、したがって関係者が、ＩＰ、ＳＰ、および／またはＣＩＭとして同時に機能してよいということが、理解されるであろう。

【0260】

識別情報伝達システムの動作
動作中に、識別情報伝達システムは、１つまたは複数の機能を実行し、それらの機能の非限定的リストは、次のとおりである。

【0261】

識別情報の検証：識別情報伝達システムにおいて識別情報を確立するために、顧客が識別情報プロバイダと通信し、ＩＰによって検証される識別情報文書を伝達する。この文書の検証は、例えば、物理的位置にいる人において、コンピュータネットワークを介して電子的に、かつ／または任意の他の適切な方法もしくはこれらの組み合わせで、実行されてよい。そのようなプロセスの１つの例は、政府発行の識別情報の写真、顧客にアドレス指定された１つまたは複数の請求書などをＷｅｂサイトにアップロードすることを含んでよいが、これに限定されない。識別情報の検証は、政府機関との直接的なデジタル通信、および／または「スマートカード」に含まれているデジタル識別情報文書の使用などの、デジタル式の手順を含んでよい。

【0262】

識別情報プロバイダが顧客の識別情報を検証した後に、識別情報プロバイダは、デジタル識別認証情報を生成して、顧客に発行してよい。デジタル識別認証情報は、ユーザの識別情報に関する構造化された情報に加えて、識別情報プロバイダによって生成された暗号鍵を使用してこの情報に対して計算されたデジタル署名などの暗号認証データを含む、デジタルファイルである。一部の実施例によれば、ＩＰは識別情報をローカルに格納してよい。

【0263】

サービスの登録：顧客が新しいサービスプロバイダに登録することを望む場合、顧客は、Ｗｅｂサイトに対して、またはモバイルアプリを介して行われるＨＴＴＰ（Ｓ）要求などのネットワーク接続を介して、サービスプロバイダに連絡する。次に、顧客は、顧客が以前にどの識別情報プロバイダに登録したかを示し、その識別情報に関する情報を指定する。この情報は、顧客によって保持されている識別情報証明内に格納された情報のサブセットに加えて、識別情報証明から導出された暗号情報を含んでよい。代替として、顧客は、場合によっては顧客のコンピュータによって仲介されて、識別情報プロバイダとサービスプロバイダの間の直接通信を開始してよい。

【0264】

このプロセスでは、顧客は、単一の特定の識別情報プロバイダを公開してよい。代替として、顧客は、特定の識別情報プロバイダを公開せずに、識別情報プロバイダが識別情報プロバイダの許可されたセットに属するということを公開してよい。後者は、例えば、管轄区域内の認証された識別情報プロバイダのリストを参照するか、または識別情報プロバイダを認証した管轄区域の関係当局によって発行されたデジタル署名証明を参照する、暗号ゼロ知識証明を使用して実行されてよい。さらに、顧客は、顧客に関して識別情報プロバイダが提供する別々の情報が補完になることができ、一貫性についてチェックされ得るように、複数の識別情報プロバイダを公開してよい。

【0265】

このプロセスの最後に、サービスプロバイダは、顧客に関する関連する情報を取得し、それによって、顧客が識別情報プロバイダに登録され、好ましい状況で識別情報を保持するということを検証する。この情報は、サービスプロバイダでの顧客のアカウントに関連付けられてよい。サービスプロバイダによって記録された情報は、ＳＰによって要求された情報と、ＩＰおよび顧客が公開することを選択する情報との組み合わせから、少なくとも部分的に派生してよい。一部の実施例によれば、この情報は、ユーザの名前などの完全な識別情報を公開してよい。他の実施例によれば、伝達される情報は、「偽名」、すなわち、顧客の実際の識別情報と異なる顧客の識別子を含む。偽名は、識別情報プロバイダに対して顧客を一意に識別するように選択される。偽名は、各顧客が、顧客が登録する複数のＳＰにわたって共有された単一の偽名、または単一のプロバイダに固有の個別の偽名を持つように、選択されてよい。

【0266】

したがって、サービスプロバイダによって学習された情報は、正確な詳細も補強証拠も公開せずに、顧客の識別情報の属性を粗い粒度でサマリーとして伝達してよい。例えば、この情報は、顧客の市民権または住居の国（ただし、特定の住所ではない）、顧客の年齢幅（ただし、正確な年齢でも生年月日でもない）、顧客の収入範囲、および／または顧客の純資産の範囲を公開してよい。識別情報は、否定的性質の情報（例えば、市民権の特定の国を開示することを避けながら、顧客の市民権が特定の拒否リスト内にないということ）であってもよい。

【0267】

送金者、仮想アセットサービスプロバイダ、セキュリティ、および／または銀行取引の規制へのコンプライアンスを含むが、これらに限定されない、さまざまな目的で、サービスプロバイダによって情報が要求されてよい。例えば、要求された情報は、ノーユアカスタマー（ＫＹＣ）、アンチマネーロンダリング、テロ対策金融制裁命令（counter-terrorism financing and sanctions mandates）に従うため、旅行規則命令（Travel Rule mandate）に従うため、適格投資家ステータス（例えば、証券取引委員会の規制Ｄに従う収入、純資産）を確認するため、外国口座税務コンプライアンス法（ＦＡＴＣＡ）に従うため、および／または公正および正確信用取引法（ＦＡＣＴＡ：Fair and Accurate Credit Transactions Act）に従うために使用されてよく、これらすべてが、顧客情報の収集および検証を必要とする。顧客の口座の制限または特徴（例えば、オプション取引、委託証拠金、または他の借入資本利用）を決定するため、および／または税関リスクに基づくポリシー用のデータとして使用されるために、サービスプロバイダによって情報が要求されてもよい。

【0268】

サービスプロバイダの報告：サービスプロバイダが顧客の識別情報をサービスプロバイダから受信した後に、サービスプロバイダは、顧客の代わりにサービスを実行することができる。これらのサービスの性質は、プロバイダの特定の性質に依存してよい。ＳＰは、ＳＰが顧客の識別情報に関連付けることを望む情報を記録してよい。例えば、ＳＰは、内部データベース内にローカルにのみ必要とする情報を格納してよい。さらに、ＳＰは、識別情報伝達システム内の他の関係者にとって興味のある情報を取得してよい。この情報の例は、規制当局または識別情報伝達システム内の他の関係者に伝達される必要があることがある、顧客による不正な挙動の報告（例えば、「疑わしい活動の報告」）、またはチェーン上の顧客の活動に関する有用な情報を伝達できる情報を含んでよいが、これらに限定されない。

【0269】

この記録を容易にするために、ＳＰは、識別情報プロバイダに、および／または役立つように識別情報と結合され得る他の関係者に、情報を送信してよい。この送信は、下でさらに説明される複数の方法で実現されてよい。

【0270】

識別情報の取り消しおよび更新：識別情報伝達システム内の関係者は、ＳＰによって保持されている識別情報に対する更新情報を提供してよく、かつ／または前に作成された識別情報アサーションを取り消してよい。前者は、ＩＰで顧客情報が変化するときに発生することがあり、新しい更新された情報がＳＰに送信されることを必要とする。代替として、ＩＰは、１つまたは複数のサービスプロバイダでのユーザの識別情報権限を取り消す必要があることがある。この取り消しは、例えば、ユーザの識別情報が、サービスプロバイダに登録するために不正にアクセスされていることが判明した場合に発生することがある。この取り消しを容易にするために、ＩＰはときどき、ブロードキャストメッセージを介して、またはＳＰに送信される専用メッセージを介して、１つまたは複数の取り消しメッセージをＳＰに送信してよい。これらの取り消しメッセージは、前にＳＰに対して作成された識別情報アサーションが有効として受け入れられなくなっていることをＳＰが確実に認識するように、構成される。このプロセスのメカニズムは、下でさらに詳細に説明される。

【0271】

技術的および実装の考慮事項
前述のメカニズムは、２つの異なる構成で実現されてよい。第１の（集中型の）構成では、識別情報プロバイダ（またはＩＰによって許可された、関連付けられたサーバ）が、１つまたは複数のサービスプロバイダとリアルタイムに通信して、識別情報アサーションを伝達する。この手法の利点は、ＨＴＴＰ、ＨＴＴＰＳ、ＲＥＳＴ ＡＰＩ、ＨＴＭＬ、およびＷｅｂクッキーなどの、多くの既存のＷｅｂに基づく技術を使用して実現され得るということである。第２の（分散型の）構成では、ＩＰは、暗号オブジェクトを顧客の顧客識別情報マネージャに送信し、顧客識別情報マネージャは、この値を格納し、ＳＰに対して直接、識別情報に関するアサーションを作成できる。これらの２つの構成は、異なっているが、いくつかの点で重複してよく、例えば分散型の構成は、ＳＰとＩＰの間のどの通信も除外しない。

【0272】

共通の要素：構成の各々では、識別情報プロバイダが、顧客に関する記録を含んでいるデータベースを維持する。このデータベースは、顧客の名前、住所、市民権、旅券の詳細、国民識別番号、デジタル通貨アドレス、証拠書類、および個人に対して実行される検証手順に加えて、任意の追加情報（例えば、顧客のトランザクション履歴および／または信用スコアに関する記録）などの情報を含む。識別情報プロバイダは、この情報の一部を代替の形態に要約する（例えば、トランザクション履歴データの集合を、サービスプロバイダに顧客の活動のスナップショット評価を提供する「リスクスコア」に変換する）ように構成されてもよい。

【0273】

ＩＰは、コンピュータネットワークと通信し、それによって、ブロックチェーンに基づくシステム（例えば、ビットコイン、イーサリアムなど）などの１つまたは複数の合意ネットワークにアクセスするように、さらに構成されてよい。ＩＰは、このアクセスを使用して、顧客に関する追加情報を収集することができる。ＩＰは、コンピュータネットワークを介して、顧客のマシン、顧客識別情報マネージャ、サービスプロバイダ、および／または接続された他の構成要素と情報をやりとりしてもよい（当業者は、識別情報プロバイダ自体が、複数のコンピュータまたは位置にわたってこれらの機能を分割してよいということを理解するであろう）。

【0274】

各識別情報プロバイダおよび１つまたは複数のサービスプロバイダは、信頼関係を確立してよい。この関係は、サービスプロバイダが、そのＩＰを本物の識別情報のソースとして決定することを必要とする。サービスプロバイダは、複数の識別情報プロバイダとの信頼関係を確立してよく、これらの信頼関係は、識別情報の特定の要素が条件とされてよく、例えば、サービスプロバイダは、識別情報プロバイダが特定の管轄区域の識別情報の妥当性を確認することを信用することができるが、他の管轄区域については信用することができない（例えば、識別情報プロバイダは、米国の識別情報の妥当性を確認することができるが、フランスの識別情報の妥当性を確認することはできない）。信頼関係は、逆方向にも当てはまることができ、例えば、ＩＰは、前もって識別された特定のＳＰに対するアサーションのみをサポートしてよく、またはＩＰは、任意のＳＰに対するアサーションをサポートしてよい。

【0275】

この信頼は、識別情報プロバイダおよびサービスプロバイダの個別の対の間で確立されてよく、あるいは例えば、管轄区域内の認証された識別情報プロバイダのリストを介して、または管轄区域の関係当局によって発行されたデジタル署名証明を介して、複数の識別情報プロバイダおよび／またはサービスプロバイダを信頼できるとしてマーク付けするシステムを採用してよい。

【0276】

集中型の構成：集中型の構成では、識別情報プロバイダは、通信ネットワークを介して直接、または仲介として顧客のコンピュータを使用して、ＳＰとリアルタイムに通信する（下のさらなる説明を参照）。

【0277】

顧客は、特定のサービスプロバイダとの新しい関係を確立してよく、かつ／または識別情報の検証を必要とするＳＰでアクションを実行してよい。そのような場合、ＳＰおよびＩＰは、互いに（直接的または間接的に）通信して特定の情報を交換してよい。この情報は、以下を含んでよいが、これらに限定されない。
１．ＳＰは、どの識別情報が必要とされるかをＩＰに具体的に示す。これは、すべての使用可能な情報が必要とされるということ、または識別情報のサブセットが必要とされるということを示す概要を含んでよい。以下では、この情報を指定するためのメカニズムが説明される。
２．次に、ＩＰは、ＳＰが識別情報に関する情報を受信することが許可されるかどうか、およびＳＰがどのデータを受信するべきかを決定する。この決定プロセスは、ＩＰとＳＰの間の信頼関係の存在を含む、ＩＰに対してローカルなポリシーを含んでよい。この決定プロセスは、情報の転送のために、顧客が、明示的な許可を提供することを要求されるステップを含んでもよい。どのデータをＳＰに配信するべきかに関する決定は、識別情報要約エンジンと呼ばれる構成要素によって行われ、後のセクションで、識別情報要約エンジンについて説明する。
３．次に、ＩＰは、顧客の識別情報に関する情報をＳＰに配信する。この配信は、識別情報をフィールドにエンコードするデータ構造を含んでいる送信を含んでよい。各フィールドは、顧客の識別情報の１つの側面を含んでよく、すべてのフィールドが、同じ顧客に属しているとして一緒に結び付けられる。このデータ構造は、顧客識別子の値も組み込むべきである。ＩＰは、配達を目的とする他のＳＰからの更新されたリスク情報などの、ＩＰが受信した補助記録を配信してもよい。
４．その後のある時点で、ＳＰは、顧客に関する情報（例えば、不正なトランザクションに関する情報、または更新されたリスクスコア付け情報）を開発してよい。この時点で、ＳＰは、情報をＩＰに報告してよく、この情報は、顧客に関するＩＰの知識を拡張するためにさらに使用され得る。この情報は、ＩＰでデータベースに格納されてよく、かつ／または顧客の識別情報に結び付けられた識別子を使用している第三者によって格納されてよい。

【0278】

ＩＰは、ＳＰへの配信のための顧客の識別情報のサブセットを少なくとも識別するように構成されてよい。この「サブセット」は、両方ともデータベース内の識別情報フィールドの文字どおりのサブセットのことを指す（すなわち、一部のフィールドが選択的に配信され、一部のフィールドが保留される）。このサブセットは、情報が、減らされた粒度を提供する形態に要約されるプロセスのことを指してもよい。例えば、ＩＰのデータベース内のフィールドは、顧客の正確な生年月日を指定してよいが、ＩＰは、代わりに、この正確なデータの近似的な日付または年齢（例えば、「顧客は２１歳を超えている」）を配信してよい。ＩＰは、顧客情報を明示的に識別する代わりに、「偽名」を生成するようにさらに構成されてよい。この偽名は、ＩＰとこのＳＰの間でこの顧客に関して一意である顧客識別子または番号であってよい。

【0279】

顧客に配信されてＳＰと交換される情報は、仲介による許可されていない改ざんおよび／または盗聴に対して安全な方法で配信されてよい。この配信は、トランスポート層セキュリティ（ＴＬＳ：Transport Layer Security）プロトコルを使用してＩＰとＳＰの間で安全なチャネルを確立することによって実現されてよく、トランスポート層セキュリティプロトコルは、インターネットプロトコル接続を経由して、２つのマシン間の暗号化されて暗号によって認証された通信を提供する。しかし、代替のメカニズムが使用されてもよく、例えば、識別情報プロバイダは、改ざんを防ぐために、この情報が暗号によって認証されるということを条件として、Ｗｅｂに基づくリダイレクトおよび他の標準的な技術を使用することによって、情報をＳＰに配信してよい。当業者は、ＪＳＯＮ ＷｅｂＴｏｋｅｎ規格を含む、そのような通信のために多くの一般的な技術が存在するということを認識するであろう。

【0280】

したがって、ＩＰは、機密性および信頼性が維持されること、ならびに必要な顧客識別情報のみがＳＰに公開されることを保証しながら、顧客識別情報を安全にＳＰに配信するように構成されてよい。ＩＰは、この顧客に関するさらなる通信がＩＰ／ＳＰ通信の一部として一意に参照され得るように、ＳＰと、顧客の一意の識別子も確立する。

【0281】

当業者によく知られた上記のメカニズムの変形は、ＩＰとＳＰの間でメッセージを直接送信する代わりに、ＩＰおよびＳＰが、二者間でメッセージを渡すために顧客のコンピュータ（例えば、Ｗｅｂブラウザ）を仲介として使用して、メッセージを交換できることである。そのような中間通信メカニズムの使用は、シングルサインオンシステムなどのＷｅｂに基づくシステムにおける一般的な手法である。

【0282】

分散型の構成：識別情報伝達システムの分離した構成は、各ユーザを認証するために、識別情報プロバイダとサービスプロバイダの間のリアルタイム通信を必要としない。代わりに顧客は、関連する識別情報を埋め込む暗号証明を提供される。この証明は、顧客によって顧客識別情報モジュール（ＣＩＭ：Customer Identity Module）に格納されてよい。さらに、証明の一部の機能（例えば、証明のパブリックな部分および／またはコミットメント／ハッシュ）は、ブロックチェーンなどのパブリックな台帳に格納されてよい。顧客識別情報モジュールは、コンピュータネットワークを介してサービスプロバイダおよび識別情報プロバイダと通信することができる。サービスプロバイダがユーザの識別情報の認証を必要とする場合、サービスプロバイダは、ＣＩＭと情報をやりとりして、識別情報アサーションを取得し、識別情報アサーションは、下で説明されるように、暗号によって認証される方法で顧客の識別情報に関する情報を指定する暗号オブジェクトである。

【0283】

顧客は、特定のサービスプロバイダとの新しい関係を確立してよく、または識別情報の検証を必要とするＳＰでアクションを実行してよい。これが発生する場合、ＳＰおよびＣＩＭは、（直接的に、または第２のコンピュータを介して間接的に）通信して特定の情報を交換する。この情報は、以下を含んでよいが、これらに限定されない。
１．ＳＰは、どの識別情報が必要とされるかをＣＩＭに具体的に示す。これは、すべての使用可能な情報が必要とされるということ、または識別情報のサブセットが必要とされるということを示す概要を含んでよい。この情報の要求は、ＳＰからの専用通信を介して実行されてよく、またはＳＰによって先験的に公表されてよい。具体的には、この情報の要求は、ＳＰの仮想ウォレットのアドレスに添付されてよく、それによって、見込み客に、この仮想ウォレットを含むすべての資金の移動が、特定の要求された情報を提供することの対象になるということを通知する。
２．次に、ＣＩＭは、ＳＰが識別情報に関する情報を受信することが許可されるかどうか、およびＳＰがどのデータを受信するべきかを決定する。この決定プロセスは、ＣＩＭに対してローカルなポリシーに加えて、ＩＰによって定義され、顧客の識別情報証明に格納された一部のポリシーを含んでよい。この決定プロセスは、情報の転送のために、顧客が、明示的な許可を提供することを要求されるステップを含んでもよい。どのデータをＳＰに配信するべきかに関する決定は、この構成ではＣＩＭ内に位置する識別情報要約エンジンの変更された変形によって行われる。
３．次に、ＣＩＭは、顧客の識別情報に関する情報をＳＰに配信する。この配信は、識別情報をフィールドにエンコードするデータ構造を含んでいる送信で構成されてよい。各フィールドは、顧客の識別情報の１つの側面を含んでよく、すべてのフィールドが、同じ顧客に属しているとして一緒に結び付けられる。このデータ構造は、顧客識別子の値も組み込むべきである。この情報が本物であることを保証するために、ＣＩＭは、識別情報証明に基づいて形成された暗号証明（および／または署名）を添付してもよい。この証明は、情報が本物であることを保証するために、ＳＰによって検証され得る。任意選択的に、この証明は、識別情報要約エンジンによって識別された選択的な開示が、あるＩＰのポリシーに関して正しく形成されたということを示してよい。
４．ＳＰは、ＣＩＭによって提供された情報を使用して、顧客のリスクスコアに関する更新された情報などの、顧客に関する他の情報を任意選択的に要求してよい。この情報は、パブリックな位置に格納されてよく（例えば、ブロックチェーンにポストされるか、またはパブリックにアクセスできるデータストレージシステムに格納されてよく）、またはこの情報は、元のＩＰなどのプライベートなサービスから取得されてよい。このサービスの識別情報および位置は、この情報を取得するために必要とされる任意の顧客識別子およびアクセスコードと共に、ステップ（３）で配信される情報の一部として、ＣＩＭによってＳＰに提供されてよい。
５．その後のある時点で、ＳＰは、顧客に関する新しい情報（例えば、不正なトランザクションに関する情報、または更新されたリスクスコア付け情報）を開発してよい。この時点で、ＳＰは、情報を報告してよく、この情報は、顧客に関するＩＰの既知の情報を拡張するためにさらに使用され得る。この情報は、前のステップで識別された位置（例えば、パブリックなストレージ位置またはＩＰなどのプライベートなストレージ位置）に送信される。この情報は、この位置で顧客識別子に結び付けられる。このデータを保護するさらなる要素として、このデータは、パブリックな位置に格納されるときに暗号化されてよい。このデータに必要な復号鍵は、識別情報証明に含まれてよく、ステップ（３）の一部としてＣＩＭからＳＰに配信され得る。

【0284】

集中型の構成を参照して上で説明されたように、ＣＩＭは、ＩＰからの入力を使用して、ＳＰへの配信のための顧客の識別情報のサブセットを識別するように構成されてよい。この「サブセット」は、データベース内の識別情報フィールドの文字どおりのサブセットのことを指してよい（すなわち、一部のフィールドが選択的に配信され、一部のフィールドが保留される）。サブセットの識別は、情報が、減らされた粒度を提供する形態に要約されるプロセスのことを指してもよい。ＣＩＭまたはＩＰは、顧客情報を明示的に識別する代わりに、「偽名」を生成してもよい。この偽名は、ＩＰとこのＳＰの間でこの顧客に関して一意である顧客識別子または番号であってよい。

【0285】

ＩＰが必ずしもすべての識別情報アサーションに関与しないため、ＣＩＭが完全に（ＳＰにとって信頼できないことがある）顧客の制御下にあるとしても、ＣＩＭがＳＰに対して識別情報に関する有用な情報を主張できるように、暗号技術が提供されてよい。これを実現するために、ＣＩＭは、例えば、匿名認証情報およびゼロ知識証明のフィールドから、各識別情報アサーションに対して「正しさの非対話式証明」を生成するために、１つまたは複数の暗号技術を実装するように構成されてよい。デジタルオブジェクトであるこの証明は、ＣＩＭによって、識別情報証明および他のローカルな鍵材料を入力として使用して生成され、ＳＰによって検証され得る。この証明が検証する場合、ＳＰは、識別情報アサーションに含まれる情報が本物であるということを保証され得る（すなわち、この証明は、識別情報証明内の認証されたデータの真の要約を表す）。この証明は、セキュリティを侵害されたＣＩＭであっても偽の識別情報アサーションをＳＰに発行することができないということを保証することができる（残りの懸念は、識別情報プロバイダが顧客の識別情報証明を「取り消す」状況、または更新された情報を使用して、そのような証明を修正することを望む状況を処理することである。これについては、下で説明される）。

【0286】

分散型の設定は、ＳＰによる情報の報告をさらにサポートしてよい。ＳＰによって提供される情報は、前のセクションで説明された報告に類似してよい。しかし、報告が発生するメカニズムは異なることができる。１つの実施形態では、ＳＰは、（集中型の設定におけるように）情報をＩＰに直接報告し、更新情報をＩＰから直接受信することができる。しかし、他の実施形態では、ＳＰは、情報を他のパブリックなストレージ実体およびプライベートなストレージ実体（例えば、ブロックチェーン、ファイル共有サービス、および／または他のユーザに配信するためにデータを単に保持する第三者）に報告してよい。これを可能にするために、識別情報証明は、認証トークンおよびデータを報告するための位置を含んでよく、そのためＳＰは、これらのサービスを介してデータを交換することができる。ＳＰによって報告されるデータは、ＣＩＭの識別情報アサーションによってＳＰに対して指定された暗号鍵に従って暗号化されてもよく、他のＳＰからＳＰによって受信された報告は、同じ暗号鍵（または関連する暗号鍵）を使用して復号されてよい。このメカニズムは、以下でさらに詳細に説明される。

【0287】

ＣＩＭが顧客のマシンに位置しているため、ＣＩＭは、ＩＰが使用できない、顧客のトランザクションに関する追加情報に対するアクセス権限を有してもよい。例えば、ＣＩＭが顧客のデジタル「ウォレット」に存在する場合、ＣＩＭは、受信者情報および量を含む、すべての過去のトランザクションの完全なリストに対するアクセス権限を有してよい。この情報は、ＣＩＭがＳＰに対して作成するアサーションに組み込まれることも可能である。例えば、ＣＩＭは、顧客がＳＰとの既存の関係を有するということの証明として、一部のトランザクションが特定のＳＰに発行されたということを主張するように、構成されてよい。この情報は、明示的に（例えば、デジタル通貨ネットワーク上の明示的なトランザクションを参照して）提供されてよく、またはプライバシー保護暗号技術を使用して要約されてよい。このための標準的な手法は、ブロックチェーンなどのパブリックな可視の暗号通貨台帳上の、特定の基準を満たす１つまたは複数のトランザクションの存在を示す、ゼロ知識証明を使用することである。そのような証明を計算するための技術は、研究文献において提案されている。

【0288】

技術的詳細
識別情報要約エンジンならびに識別情報の要求およびアサーションの構文
本明細書に記載された識別情報伝達システムの１つの利点は、サービスプロバイダに格納される顧客に関する顧客の個人を特定できる情報（ＰＩＩ：Personal Identifiable Information）の量を最小限に抑えることができる方法で、情報をサービスプロバイダに選択的に開示する能力である。どの情報が開示されるかに関する決定は、例えば、異なるプロバイダがデータを安全に格納するための異なる要件および異なる能力を有するため、サービスプロバイダ間で異なってよい（選択的な開示は、特定のフィールドを編集することに加えて、一部の識別情報をあまり具体的でない形態に変更すること、例えば正確なデータをカテゴリまたはサマリーに減らすことを含んでよい）。識別情報伝達システムが、多数のサービスプロバイダおよび顧客に合わせて拡大できることを保証するために、選択的な開示のプロセスが、かなりの程度まで自動化されてよい。

【0289】

自動化された選択的な開示のこのプロセスを可能にするために、識別情報要約エンジン（ＩＳＥ：Identity Summarization Engine）が提供されてよい。ＩＳＥは、１つまたは複数の顧客データレコードに加えて、どのデータが必要とされるかを詳述するサービスプロバイダからの要求、および（任意選択的に）識別情報ポリシーなどの何らかの補助情報を記録する識別情報伝達システムである。その後、ＩＳＥは、顧客データから特定のフィールドを選択することによって、またはデータを正確だがあまり具体的でない形態に要約することによって、どの顧客データがＳＰに選択的に開示されるべきかを決定する。ＩＳＥは、（例えば、集中型の設定では）識別情報プロバイダによって直接操作されてよく、または顧客識別情報モジュール（ＣＩＭ）の一部として展開されてよい。

【0290】

ＩＳＥの動作：基本的レベルでは、ＩＳＥは、ＳＰからの要求、顧客レコード、およびポリシーを取り込む（ただし、追加情報を取り込んでもよい）。ＩＳＥの役割は、（１）このフィールドがＳＰに配信されるべきかどうか、（２）このフィールドがＳＰに配信されるアサーションから除外されるべきかどうか、または（３）このフィールドが、あまり具体的でない情報を含んで要約される（または他のフィールド内の情報と結合される）べきかどうかを決定するために、顧客データの各フィールドを処理することである。各フィールドに対するＩＳＥの動作は、ポリシーに依存してよく、ポリシーは、例えば、ＳＰに固有の方法で、例えば、どの情報が配信されるべきか、要約されるべきか、または保留されるべきかを指示してよい。

【0291】

ＩＳＥによって使用される情報は、実装によって異なってよい。例えば、ＳＰの要求は、ＳＰがどのフィールドを要求しているかに関する詳細な情報を含んでよく、またはそのような詳細を含まなくてよい。ポリシーは、各フィールドを処理するためのルールをエンコードする、汎用コンピュータプログラミング言語またはスクリプト言語で表されてよく、チューリング完全であってよい。代替として、ポリシーは、単に、各フィールドを使用してどのアクションを実行するべきかを決定するためにデータ処理システムによって解釈され得るルールのより制限されたセットを記述してよい。

【0292】

識別情報の要求およびアサーション言語：ＩＳＥを実現するために、一部の実施例に従う識別情報伝達システムは、ＳＰからの識別情報要求を指定するための要求言語に加えて、ＳＰに対して作成された識別情報アサーションを指定してよい。要求言語は、（例えば、ＪＳＯＮのような）機械可読形式で、ＳＰがどの識別情報フィールドをどの粒度で必要とするかを指定する。例えばＳＰは、次のように、必要とされるフィールドのタプルを指定してよい。
ｒｅｑｕｉｒｅｄ＿ｆｉｅｌｄｓ ＝ ｛ｆｕｌｌ＿ｎａｍｅ， ａｇｅ， ｉｎｖｅｓｔｏｒ＿ｓｔａｔｕｓ， ｌｅｇａｌ＿ｊｕｒｉｓｄｉｃｔｉｏｎ｝
ここで、上記のトークン名の各々は、顧客レコード内に格納された標準的な情報を表す。さらに、ＳＰは、特定のフィールドが要約された形態で配信され得るということを識別してよい。例えば、ＳＰの要求は、ＳＰが「顧客が２１歳を超えているかどうか」を知ることのみを要求するということを示してよい。この要求は、複数の可能な形式で表され得る。ＳＰは、識別情報フィールドがいつ任意選択的として扱われ得るか、またはプレースホルダ（例えば、顧客の名前の代わりの偽名）に置き換えられ得るかを識別してもよい。例えば、
ｒｅｑｕｉｒｅｄ＿ｆｉｅｌｄｓ ＝ ｛ｆｕｌｌ＿ｎａｍｅ， ａｇｅ：｛＞＝２１｝， ｉｎｖｅｓｔｏｒ＿ｓｔａｔｕｓ， ｌｅｇａｌ＿ｊｕｒｉｓｄｉｃｔｉｏｎ＝｛！＝”ＥＵ”｝｝
は、ＳＰが、顧客が少なくとも２１歳であることを知ることのみを要求していること、および顧客が明示的に「ＥＵ」管轄区域内にいないということを示してよい。

【0293】

この情報がＳＰに配信され得るかどうかを判定するために、ＩＳＥによって任意の要求が処理されてよく、（許可される場合）各必要なフィールドが、顧客データレコードから抽出され、ＳＰに配信され得る。応答メッセージはアサーション言語で表され、アサーション言語は、要求されたデータを含み、さらに、顧客識別子および更新を容易にするためのフィールドを含んでよい、機械可読形式である。例えば、
｛
“Ｃｕｓｔｏｍｅｒ＿ｉｄ”， ９“３４８７２３４８３”
“ｆｕｌｌ＿ｎａｍｅ“：“Ａｒｔｈｕｒ Ｗａｌｌａｃｅ Ｐｅｔｅｒｓｏｎ”，
“ａｇｅ”：４３，
“ｉｎｖｅｓｔｏｒ＿ｓｔａｔｕｓ”：“ａｃｃｒｅｄｉｔｅｄ”，
“ｌｅｇａｌ＿ｊｕｒｉｓｄｉｃｔｉｏｎ”：“ＵＳ”，
“ｕｐｄａｔｅ＿ｌｏｃａｔｉｏｎ”：“ｈｔｔｐｓ：／／ｉｄｅｎｔｉｔｙ－ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｕｐｄａｔｅｓ”
“ｕｐｄａｔｅ＿ｔｏｋｅｎ”：“９３２ｈｂｃ０ｗｅｈｒａｅｈａｍｓｎｅｂｋａａｄｋ２ｅｆｓｖｄｓ２ｂｚｋｈｂｊＷｚ”
｝

【0294】

アサーション言語のメッセージは、（例えば、顧客データレコードを指定する）特定の要求に応じて構成要素を含んでよい。アサーション言語のメッセージは、情報フィールドがいつ編集または要約されたかを識別する能力などの、標準的な要素を含んでもよい。例えば、以下の応答は、前述の第２の照会に応答する要約を示すことができ、ポリシーの制限に起因してレコードのｉｎｖｅｓｔｏｒ＿ｓｔａｔｕｓ構成要素が編集されたことも示す。
｛
“Ｃｕｓｔｏｍｅｒ＿ｉｄ”， ９“３４８７２３４８３”
“ｆｕｌｌ＿ｎａｍｅ“：“Ａｒｔｈｕｒ Ｗａｌｌａｃｅ Ｐｅｔｅｒｓｏｎ”，
“ａｇｅ”［＞＝２１］：ＴＲＵＥ，
“ｉｎｖｅｓｔｏｒ＿ｓｔａｔｕｓ”：｛ｎｕｌｌ， ｎｏｔ＿ａｖａｉｌａｂｌｅ＿ｗｉｔｈ＿ｐｏｌｉｃｙ｝，
“ｌｅｇａｌ＿ｊｕｒｉｓｄｉｃｔｉｏｎ”［！＝ＥＵ］：ＴＲＵＥ，
“ｕｐｄａｔｅ＿ｌｏｃａｔｉｏｎ”：“ｈｔｔｐｓ：／／ｉｄｅｎｔｉｔｙ－ｐｒｏｖｉｄｅｒ．ｃｏｍ／ｕｐｄａｔｅｓ”
“ｕｐｄａｔｅ＿ｔｏｋｅｎ”：“９３２ｈｂｃ０ｗｅｈｒａｅｈａｍｓｎｅｂｋａａｄｋ２ｅｆｓｖｄｓ２ｂｚｋｈｂｊＷｚ”
｝

【0295】

上記の例は、要求および応答の言語がどのようなものであることができるかの一例である。完全な実装は、例えば、標準的な規則との相互運用性のため、または簡潔さのために、異なる表記を使用してよい。

【0296】

上に示されたように、識別情報アサーションは、更新された情報および顧客の取り消し情報が見つけられ得る位置を含んでもよい。この位置は、ＵＲＬによって識別されてよく、データにアクセスして取り出された情報を復号するために必要とされる、許可トークン（例えば、パスワード）および復号鍵などの識別子を含んでもよい。

【0297】

ポリシー：ＩＳＥは、ＳＰの要求および顧客データに加えて、識別情報プロバイダによって選択された１つまたは複数のポリシーを入力として受け取るように構成されてよい。これらのポリシーは、ＳＰの要求と一緒に、ＩＳＥが、どのフィールドが返されるべきか、およびどのフィールドが要約または編集されるべきかを決定することを可能にする。前述したように、ポリシーは、ＳＰの要求および顧客データの要素に対して動作すること、ならびに／あるいはデータを出力または要約する方法に関する決定を行うことができるコンピュータプログラムまたはスクリプトを含んでよい。代替として、ポリシーは、ＩＳＥが、決定を行うためにこのデータに対して評価することができる、基本的ルールを単に指定することができる。

【0298】

上記では、ポリシーが完全なＳＰの要求および顧客データに対して動作するように説明されているが、ポリシーが、部分的な顧客データに対して推論してもよいということが、理解されるであろう。例えば、顧客データは、顧客レコード内のフィールドの名前のみを含んでよく、ＩＳＥは、要約または除外されるべきであるフィールドに関する命令を出力することができる。

【0299】

暗号認証
ＳＰは、新しい識別情報アサーションを受け入れるために、アサーションが本物であるということを確認しなければならない。これは、（１）識別情報アサーションが、識別情報プロバイダによって保持されている情報と一致していること、および任意選択的に（２）どの情報を送信、除外、および要約するべきかに関する特定の決定が、識別情報プロバイダによって許可されていることという、２つのことを意味する。

【0300】

集中型の設定：集中型の設定では、ＩＰおよびＳＰは、直接、または任意選択的に、仲介として顧客のコンピュータを使用して、リアルタイムに通信する。この設定では、暗号認証が、次のようなさまざまな方法で処理される。
１．ＳＰとＩＰの間の直接通信の場合、二者は、トランスポート層セキュリティプロトコル（以前はＳＳＬとして知られていた）を使用することができる。このプロトコルは、デジタル証明を使用して二者の片側認証または相互認証を提供し、二者間の暗号化されて認証された接続を確立する。ＩＰと直接そのような接続を開始するＳＰは、暗号プロトコルが、接続が有効であること、および受信されたデータが本物であること、例えば、第三者による変更またはデータの挿入に対して保護されることを保証するため、識別情報アサーションを含む、この接続を経由して受信されたすべてのデータの信頼性を検証することができる。
２．ＳＰとＩＰの間の間接通信の場合、二者は、デジタル署名またはメッセージ認証コードを使用して、ＩＰからＳＰへの間で配信されメッセージを認証することができる。これらの値は、例えば、ＪＷＴトークンまたはＵＲＬを介して配信され得る。仲介のＷｅｂブラウザを介して２つのシステム間で暗号化されて認証された情報を配信するための複数の実用的な解決策が、文献において知られている。

【0301】

この設定では、識別情報アサーションが識別情報プロバイダから直接派生するため、ＳＰが、アサーションが本物であるということを検証できるときはいつでも、ＳＰが、ＩＰによって識別情報の要約も決定されたということを検証するように構成されてもよいということが、理解されるであろう。これによって、この決定されたということが真であるということをＳＰに対して証明するためにさらなる暗号メカニズムを提供する必要性を取り除くことができる。

【0302】

分散型の設定：この設定では、ＩＰは、顧客の識別情報に関する関連する詳細を含んでいる識別情報証明を顧客（具体的には、顧客識別情報マネージャ構成要素）に提供する。次に、ＣＩＭは、ＳＰが本物として検証することができる、ＳＰに対する識別情報アサーションを作成しなければならない。

【0303】

一部の実施例によれば、ＣＩＭからＳＩＰへの識別情報アサーションは、どのようなフィールドの選択的開示も要約も伴わずに、識別情報証明全体をＣＩＭからＳＰに送信することによって作成される。この設定では、識別情報証明は、識別情報プロバイダによって形成されたその内容に対するデジタル署名を含んでよい。ＳＰは、識別情報証明の受信時に、ＩＰの公開鍵に関して署名が有効であることを検証することによって、証明が有効である（すなわち、ＩＰによって生成された）ということを検証することができる（デジタル署名が、文書の信頼性を証明するという点において実際の署名に類似する暗号オブジェクトであるということが、理解されるであろう。デジタル署名に関しては、署名する関係者（この場合はＩＰ）は、ＩＰによってすべての関係者に発行された第２の関連する「公開鍵」を使用して、この署名が本物であるとして検証され得るように、任意のメッセージ（識別情報証明データ）に署名を行うことができる、秘密鍵を保持する）。

【0304】

一部の実施例によれば、識別情報伝達システムは、ＳＰが信頼性を検証することを可能にしながら、選択的な開示を可能にするように構成される。

【0305】

ＳＰが信頼性を検証することを可能にしながら選択的な開示が可能にされる一部の実施例によれば、ＩＰは、各データフィールドに対するデジタルコミットメント（digital commitment）を計算し、次に、コミットメント値のすべてを結合し、結合された結果に署名するように構成される。識別情報証明は、署名と共に、デジタルコミットメントの完全なリストを含み、ＣＩＭは、データフィールドおよびフィールドごとのコミットメントの「公開（opening）」値の平文のリストも与えられる。ＣＩＭが識別情報アサーションをＳＰに送信するときに、ＣＩＭは、ＣＩＭがＳＰに公開することを望むデータフィールドに対応するすべてのコミットメントの「公開」値に加えて、データフィールド自体と共に、コミットメントおよび署名を含んでいる完全な識別情報証明を送信する。次に、ＳＰは、署名が有効であること、ならびに各データフィールドおよび公開値が対応するコミットメントと一致していることを検証することができる（デジタルコミットメントは、エンベロープに似ている暗号オブジェクトである。コミットメントを作成するために、任意選択的なランダムなデータと共に、データフィールドが入力として提供され、その結果は、データフィールドの内容を公開しないコミットメントと呼ばれるオブジェクトに加えて、「公開」値である。コミットメント、公開値、および内容を前提として、任意の関係者は、コミットメントが矛盾していないことを検証することができる。コミットメントの重要な特性は、形成された後に、コミットメントが、コミットメントの形成に使用されたデータ値と異なるデータ値へ「公開する」ことが実現不可能になるはずであるということである）。

【0306】

これらの実施例によれば、ＣＩＭは、データフィールドをＳＰに選択的に公開するように構成されてよい。ＣＩＭが選択的に公開することを望むフィールドの場合、ＣＩＭは、（識別情報証明に含まれるコミットメントに加えて）データフィールドおよびコミットメントの公開を提供するように構成されてよい。ＣＩＭが公開することを望まないフィールドの場合、ＣＩＭは、データフィールドおよびコミットメントの公開を除外する。その後、ＳＰは、識別情報証明を使用して、すべての選択的に公開された値が矛盾しておらず、本物であるということを保証されるが、ＳＰは、ＣＩＭが公開することを選択しないどの値も学習しない。

【0307】

さらに効率的であることがあるこの構造の複数の変形が可能であるということが、理解されるであろう。例えば、ＩＰは、コミットメントのすべてに対して、ハッシュツリーの葉に含まれてよい、ツリー上のマークルハッシュツリーを計算することを選択し、すべての公開された値が正しいということをＳＰに納得させるために、ハッシュツリーの一部を公開してよい。ＣＩＭは、ＣＩＭが公開することを望む値のマークルハッシュツリーの一部を送信してよい。この手法によれば、ＳＰに送信されるデータ量は、識別情報証明内のフィールドの数において、劣線形であることができる。

【0308】

上記の手法は、識別情報証明内のフィールドの選択的開示を容易にすることができる。要約を提供するために、ＣＩＭが、証明内の元の値を公開せずに、識別情報証明内の１つまたは複数のフィールドの数学関数を公開することを可能にする暗号方法が、存在することができ、この関数が正しく計算されたということをＳＰに納得させるために、提供されてよい。例えば、数学関数は、顧客の年齢を入力として受け取り、顧客が２１歳を超えている場合に、「真」を出力することができる。他の関数は、例えば、情報を「バケット化」するか、または他の方法で要約することによって、顧客情報をあまり正確でない表現に変換することができる。

【0309】

分散型の設定の代替の実施形態は、「匿名認証情報」技術を使用して、ＣＩＭが識別情報アサーションを作成することを可能にする。構造化されて認証された文書に対して暗号アサーションを作成するための一連の暗号技術が知られている。この枠組みでは、中央の「関係当局」が、例えば、複数のフィールドを含んでいる情報を含む「認証情報」と呼ばれる文書に暗号によって署名する。この認証情報は、関係当局によって直接署名されてユーザに与えられてよく、またはこの認証情報は、関係当局が認証情報に関するどの（または一部の）情報も学習せずに、認証情報を所有している人が関係当局と情報をやりとりして、この認証情報に対する署名を取得できるような方法で、「ブラインド署名」を使用して署名されてよい。その後、署名された文書を保持しているユーザは、認証情報の特定の内容に対してアサーションを生成することができ、例えば、このユーザは、何らかの第三者（「検証器」と呼ばれる）に対して、ユーザがそのような認証情報を所有していること、または認証情報が特定の情報を含んでいることの証明を示す暗号メッセージを生成することによって、認証情報を「表示する」ことができる。この検証器の関係者は、元の関係当局と同じ関係者であってよく、または検証器は第三者であってよい。そのような「匿名認証情報」は、認証情報「表示」メッセージが、関係当局によって署名された元の認証情報に逆向きに容易にリンクされないということを保証することができる。したがって、関係当局が多くの認証情報に署名し、その後、認証情報の「表示」メッセージを見る場合、関係当局は、これらの認証情報のうちのどれが表示されているかを決定することができないはずである。同様に、検証器によって不正な活動が検出されずに、ユーザが関係当局によって発行されなかった認証情報を「表示する」ことは、実現不可能であるはずである。適切な匿名認証情報は、当技術分野においてよく知られている。

【0310】

匿名認証情報のさらに強力な変形は、「効率的なプロトコルを伴う署名」を使用し、この変形も、従来技術においてよく知られている。この変形は、複数フィールドの匿名認証情報に署名することができる署名方式を定義し、ユーザが、署名されたデータに対して任意の関数を証明できるようにする。例えば、署名された認証情報を保持しているユーザは、認証情報のフィールドを単に公開することができ、認証情報のフィールドを除外することができ、またはユーザが何らかの数学関数を満たす署名された認証情報からフィールドを入力したという知識のゼロ知識証明を公開することができる。この数学関数は、入力フィールドを要約された入力にマッピングする要約関数であることができる。このプロセスの性質は、「認証情報の表示」が、認証情報の１つまたは複数のフィールドの要約を公開し、表示を実行しているユーザが、この要約と一致する認証情報を持っていることを証明することができるということである。これらの署名は、強ＲＳＡ仮定、双線型写像、および他の暗号技術に基づいて、署名から実現され得る。

【0311】

一部の実施例によれば、分散型の設定は、そのような匿名認証情報を次のように使用する。識別情報証明を取得するため、ＣＩＭは、顧客の識別情報に対する匿名認証情報を取得する。この署名された情報は、複数フィールドの匿名認証情報に格納されてよく、ブラインド署名抽出プロトコルを使用するか、または単に、ＩＰに認証情報に署名させて、認証情報をＣＩＭに配信させることによって、ＣＩＭに配信されてよい。ＳＰが、ＣＩＭからの識別情報アサーションを必要とする場合、ＣＩＭ上のＩＳＥシステムは、ここで、ＣＩＭにも格納されているポリシーを評価し、証明のどのフィールドがＳＰに公開されるべきであり、どのフィールドが要約されるべきであるということを正確に決定する。要約されるべきであるフィールドの場合、ＣＩＭは、ここで、証明のフィールドに対する数学的要約関数を導出し、要約された値を出力する。最後に、ＣＩＭは、公開された要約が署名された証明と一致するということを証明する暗号メッセージである認証情報「表示」を計算する。

【0312】

要約の１つの例は、各交換に対して一意であるユーザの偽名を開発することである。識別情報証明は、識別情報プロバイダに固有の顧客識別子を含むべきである。しかし、ＩＰおよびＣＩＭは、この一意の識別情報をＳＰに公開することを望まず、代わりに、ＳＰごとに「疑似識別子」を生成することを望むことがある。この事例を処理するために、ＣＩＭは、顧客識別子をＳＰに固有の識別子に「絡ませる」要約関数を使用して、ＳＰに固有の疑似ＩＤを取得するように構成されてよい。この要約関数は、例えば、鍵が顧客識別子である、疑似ランダム関数などの関数であってよく、この関数への入力は、ＳＰの一意の識別子である。

【0313】

報告
前述したように、ＳＰは、識別情報プロバイダに格納され、かつ／または他のサービスプロバイダに配布されなければならない追加情報を生成するように、構成されてよい。そのような情報は、顧客によって生成された不正なトランザクションに関する情報、または顧客の活動に関する新しい情報を含んでよいが、これらに限定されない。この情報は、システム内のすべての参加者への配信を対象にしてよく、または特定の関係者に制限されてよい。

【0314】

前述したように、集中型の設定および分散型の設定の両方では、情報を識別情報プロバイダに直接送信することによって、情報が報告されてよい。この報告は、報告位置（例えば、ＵＲＬ）を、識別情報証明の一部としてＳＰに配信することによって、実現され得る。このＵＲＬは、アクセスを許可する１つまたは複数のＡＰＩ鍵または認証トークンに関連付けられてよい。新しい情報を報告するために、ＳＰは、ＩＰとの通信を確立し、例えばＨＴＴＰ（Ｓ）接続を介して、安全な方法で情報を送信する。次に、この情報は、識別情報プロバイダによってデータベースに記録され、後で他の顧客およびＳＰに配信するために処理されてよい。

【0315】

一部の実施例によれば、例えば、識別情報伝達システムが分散型の設定に従って動作する場合、この情報は、ブロードキャストチャネルまたはストレージシステムを介して他のＳＰに配信されてよい。１つのそのようなチャネルは、ブロックチェーンなどの合意ネットワークの使用である。

【0316】

複数の識別情報プロバイダ
一部の実施形態では、単一の識別情報プロバイダが、単独で、顧客の識別情報を持つ役割および／または報告された情報を格納する役割を担わなくてよい。例えば、顧客の識別情報は、識別情報アサーションを提供するために協力して働く複数の識別情報プロバイダにわたって分割されてよい。このメカニズムは、すべてのプロバイダにわたって一意の顧客識別子を確立し、各プロバイダに、その識別情報プロバイダによって保持されている関連する情報を含む部分的な識別情報アサーションまたは識別情報証明を生成させることによって、実現され得る。ＳＰでの完全なアサーション、またはＣＩＭで識別情報証明として使用するための情報の完全なセットを組み立てるために、顧客識別子に従って、これらの部分的な識別情報アサーションまたは識別情報証明が結合され得る。

【0317】

同様に、ＳＰによって報告された情報は、複数の異なる位置に格納されてよい。個別の報告値が一緒にリンクされることを可能にする何らかの識別子によってこの情報が識別されるということを条件として、この情報は、必要な報告された情報の完全な姿を取得するために、ＳＰおよび他の関心のある関係者によって取得されて結合され得る。

【0318】

証明の取り消しおよび新しさ
ときどき、発行された識別情報証明または識別情報アサーションは、無効になることがあり、または識別情報プロバイダによって使用可能な新しい情報に置き換えられた情報を含むことがある。この事例を処理するために、各識別情報証明および識別情報アサーションは、アサーション／証明の識別情報、アサーション／証明の有効期限、アサーション／証明に関する更新された情報を取得するために使用する命令（ＵＲＬなど）、および各証明が更新されるべき頻度に関する推奨という、４つのフィールドのいずれかを含んでよい。

【0319】

集中型の設定では、ＩＰからアサーションを受信するＳＰは、任意選択的に、アサーションの一部としてこれらのフィールドを受信してよい。ＳＰは、有効期限を現在時刻と比較するメカニズムによって、この情報を使用して、アサーションが有効期限に達したかどうかを判定することができる。同様に、分散型の設定では、ＣＩＭは、識別情報証明が、期限が切れて更新されなければならないかどうかを判定するために、有効期限を現在時刻と比較してよい。さらに、分散型の設定では、ＣＩＭは、ＳＰに、ＳＰによって本物として検証されたｆｏ７０ｅｒｉｆｙａｎで、（１）識別情報証明の有効期限、または（２）識別情報証明の有効期限の要約のいずれかを送信してよい。そのような要約の例は、識別情報証明の期限がいつ切れるかをおおよそ示すサマリー、または単に、現在時刻の時点で識別情報証明の期限がまだ切れていないということを示す指標を含んでよいが、これらに限定されない。そのような要約は、ＣＩＭによってＳＰに対して作成されたアサーションが証明の正確な有効期限を漏らさないということを保証するために必要とされることがあり、これは、この情報が隠蔽されるべきである場合に、この情報が、ＳＰがＣＩＭによる異なる識別情報アサーションを同じ識別情報証明にリンクすることを可能にする情報をＳＰに公開することがあるためである。

【0320】

ＩＰは、有効期限の前に、識別情報アサーションまたは識別情報証明内の情報を取り消すこと、および／または更新することを実行するように構成されてよい。この取り消しおよび／または更新は、例えば、顧客のステータスを変更する新しい情報（例えば、盗まれた識別情報証明または不正な意図の証拠）がＩＰに到着するときに発生することがある。この事例に対処するために、ＩＰは、「取り消し」メッセージを１つまたは複数のＳＰに公開するように構成されてよく、「取り消し」メッセージは、ＳＰが、１つまたは複数の顧客識別情報が更新されなければならないということを決定できるようにする。このメッセージは、アサーションまたは識別情報証明の識別子を含んでよい。

【0321】

ＳＰによって受信された識別情報アサーションに関連付けられた識別子は、前のセクションで説明されたように、顧客に関して一意であるが、すべてのＳＰにわたって共有されてよく、または単一の顧客を識別するためにＳＰ／ＩＰの組み合わせごとに使用される異なる識別子であってよい。

【0322】

Ｗｅｂサイトを保護するために使用されるプロトコルなどの、標準的なＰＫＩ証明の取り消しのための複数のプロトコルが存在する。これらのプロトコルは、所与の証明が取り消されたことを伝えるために使用される、証明取り消しリスト（ＣＲＬ：Certificate Revocation Lists）およびオンライン証明ステータスプロトコル（ＯＣＳＰ：Online Certificate Status Protocol）を含む。これらのプロトコルは、若干の変更を加えて、前述の識別情報証明およびアサーションに適用されることが可能であり、または類似する目的を有する特定のプロトコルが代わりに使用されてよい。証明取り消しリストを使用するために、識別情報プロバイダは、すべての取り消された識別情報証明および／またはアサーションの識別子を含んでいるリストを公開する。ＯＣＳＰの例では、各サービスプロバイダは、識別情報プロバイダに定期的に連絡し、所与の証明／アサーションの識別子が取り消されたかどうかを要求する。この手法の最後の変形は、「ＯＣＳＰステープリング」のプロセスに関連しており、このプロセスでは、ＣＩＭなどのクライアントがＩＰに連絡し、識別情報証明がまだ有効であり、取り消されていないことを示す、デジタル的に署名されたファイルを取得することができる。このファイルは、このファイルが有効と見なされるべき期間（例えば、このファイルが要求されたときから最大で３日まで）を示す「有効性の期間」を含む。次に、ＣＩＭは、このファイルを、ＳＰに対して作成された識別情報アサーションに添付するか、または「ステープルする」ことができる。代替として、ＣＩＭは、識別情報証明に関して説明された技術を使用して、このファイルの内容を要約することができる。これによって、ＳＰがＩＰと直接通信する必要性をなくし、証明がまだ有効であることをチェックすることにおける、ある程度のリソースコストをＳＰから取り除く。

【0323】

完全な取り消しに対する代替案として、ＩＰは、識別情報アサーションまたは識別情報証明の内容を単に更新することを望んでよい。このためのメカニズムは取り消しに類似しているが、ＩＰが、証明／アサーションが取り消されておらず、むしろ、関係者が更新された証明をＩＰから取得するべきであるということを、ＩＰが公開するメッセージ（例えば、ＣＲＬまたはＯＣＳＰメッセージ）の一部として示すべきであるという点が異なる。集中型の設定では、次に、ＳＰが、前のセクションで説明されたように、ＩＰに連絡し、新しい／更新されたアサーションを取得する。分散型の設定では、ＣＩＭがＩＰに連絡して更新された識別情報証明を取得し、ＳＰは、新しいアサーションをＣＩＭから取得することが必要になることがある。

【0324】

本発明が関連する当業者は、本明細書において開示されている主題の範囲から逸脱することなく、必要な変更を加えて、多数の変更、変形、および修正が行われ得るということを容易に理解するであろう。

【図1】

【図2】

【図3】

【図4】

【国際調査報告】