JP2023546883A - コネクテッドｔｖアプリケーション及びオーバ・ザ・トップ・アプリケーションのためのプライバシ・マネージャ - Google Patents

Abstract

ベンダ・アプリケーションを利用する消費者のプライバシ承諾を処理するためのシステムは、データ・スキーマにおいて、データ主体であるユーザによって実施された同意トランザクションを記録、格納、及び取得することを可能にする。システムは、主体データを取得するよう求める要求が受信されたときに、ベンダ又はアプリケーションに関連付けられた組織ＩＤ、及び主体に関連付けられた識別値がハッシュ化されて主体ＩＤが作成されるような、いくつかのハッシュ生成されたＩＤを使用する。主体ＩＤ、組織ＩＤ、及び主体に関連付けられたスキーマのスキーマＩＤがハッシュ化されて主体データＩＤが作成され、次いで、主体データＩＤを使用して、主体に関連付けられた同意トランザクション及び承諾を取得する。

Description

本出願は、２０２１年１０月１６日に出願された米国仮特許出願第６３／０９２，９６１号の利益を主張するものである。当該出願は、その全体が参照により本明細書に組み込まれる。

本発明の分野は、コネクテッドｔｖ（ＣＴＶ：ｃｏｎｎｅｃｔｅｄ ｔｖ）アプリケーション及びオーバ・ザ・トップ（ＯＴＴ：ｏｖｅｒ－ｔｈｅ－ｔｏｐ）・アプリケーションのパブリッシャのための、プライバシ規制を遵守した消費者プライバシの保護である。カリフォルニア州消費者プライバシ法（ＣＣＰＡ：Ｃａｌｉｆｏｒｎｉａ Ｃｏｎｓｕｍｅｒ Ｐｒｉｖａｃｙ Ａｃｔ）及び一般データ保護規則（ＧＤＰＲ：Ｇｅｎｅｒａｌ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ Ｒｅｇｕｌａｔｉｏｎ）などのプライバシ法及びプライバシ規制の下において、ＣＴＶ及びＯＴＴのパブリッシャは、ウェブ・アプリケーション及びモバイル・アプリケーションと同じ情報（通知）要件並びに選択（オプトイン／オプトアウト）要件を遵守するよう求められている。しかしながら、モバイル・アプリケーション及びウェブ・アプリケーションにおいて消費者プライバシの保護のために使用されるメカニズムは、ＣＴＶアプリケーション及びＯＴＴアプリケーションでは機能しない。

世界中の規制当局は、より厳格なプライバシ規制に取り組んでおり、ＣＣＰＡ及びＧＤＰＲが実施され、今後さらに多くの規制が実施されると予想される。同時に、ブラウザ及び他のソフトウェアはサードパーティ・クッキーの仕組みを廃止しており、これにより、あらゆる形態及び形式の嗜好（ｐｒｅｆｅｒｅｎｃｅ）を管理することがより困難になっている。会社は、無数の技術及び分離されたデータ・フローを用いてエンド・ユーザに最高のデジタル・サービスを提供しようと試みているが、一方で、様々な規制及び技術的変化の継ぎはぎに対処するのに苦労している。消費者レベルでの嗜好及び同意の管理並びに個人データの正しい処理は、困難になりつつあり、今後もますます困難になるであろう。

技術的な制約が原因となり、ＣＴＶサービス及びＯＴＴサービスは、データ処理を利用してサービスの機能を改善すること及びサービスの機能をそのパートナーへ提供することをやめているか、又は、不遵守の同意ソリューションを実装している。ＣＣＰＡ（カリフォルニア州消費者プライバシ法）とＧＤＰＲ（一般データ保護規則）はどちらも、文脈において、データの収集前又は収集時に消費者又はデータ主体（ｄａｔａ ｓｕｂｊｅｃｔ）に情報を提供することを求めている。加えて、これらの法律は、消費者及びデータ主体に対して、データが処理及び／又は配布される前にオプトアウト又は同意する権利を与えている。ＣＴＶアプリケーション及びＯＴＴアプリケーションは、デバイス自体に情報を格納することができず（すなわち、クッキーがない）、したがって、デバイスＩＤ又はデバイスＩＤとつながりのあるユーザＩＤに基づいて、すべての情報をサーバ側に格納しなければならない。ウェブ・アプリケーション及びモバイル・アプリケーションの場合においては、サービス・プロバイダがプライバシ規制を遵守できるよう支援するために多くの技術が開発されているが、これらのタイプの技術は、ＣＴＶアプリケーション及びＯＴＴアプリケーションにおいて機能しない。したがって、ＣＴＶアプリケーション及びＯＴＴアプリケーションがプライバシ規制を遵守していることを証明するとともにこれらの能力を下流パートナーに提供するためには、ＣＴＶアプリケーション及びＯＴＴアプリケーションのための同意構成とオプトアウト又は同意の文字列の生成とを提供する新しい技術が必要である。

この背景セクションで言及された参考文献は、本発明に関する先行技術であるとは認められない。

本発明は、（ＣＴＶアプリケーション及びＯＴＴアプリケーションなどにおいて）消費者プライバシを管理するためのシステム及び方法を対象とし、システム及び方法は、プロバイダ・サーバ又はサーバにおいて、ユーザ（「データ主体」と呼ばれることがある）によって実施された同意トランザクション（ｃｏｎｓｅｎｔ ｔｒａｎｓａｃｔｉｏｎ）を記録することを可能にし、オンライン環境における消費者情報の収集及び使用を規定するプライバシ規制への遵守を示すために必要なすべての情報を格納する。概して、本発明のシステム及び方法によって容易化される同意トランザクションは、データ主体について保存された一連の値をもたらし、一連の値は、後で専用のエンドポイントを介して呼び戻され得る。これらの値は、各同意セクションが修正したデータ・スキーマ内のフィールドによって決定され、ユーザの嗜好（ニュースレター、プロファイリングなど）を含むことができる。この点に関して、本発明のシステム及び方法は、特にＣＴＶアプリケーション及びＯＴＴアプリケーションに好適な、プロバイダ・サーバから遠隔で動作される同意及び嗜好管理ソリューションとして機能する。特定の実施例において、本発明のシステム及び方法は、企業のデータ資産及びベンダ関係全体にわたる長期的な顧客嗜好記録の選択的なキュレーション、ロギング、及び配布のための中央リポジトリを提供する。本発明のこれらの実施例は、アプリケーションのプライバシ規制への遵守に焦点を当てた特徴によって、嗜好を容易に収集するための単一の使いやすい嗜好又はトラスト・センタ・ユーザ・インターフェースを消費者に提供する。実施例はさらに、消費者嗜好のデータ収集ポイント全体で単一のユーザレベルのビューを維持すること、下流でユーザ嗜好を永続化するためのデータ・スキーム又はベンダ・アカウントの統合、及び、所与のスキーマ内の所与の識別子に基づいた、プログラムによる又は手動によるユーザ嗜好の取得を可能にする。最後に、実施例は、どのベンダが特定のデータ・セクション内のどの特定の嗜好属性にアクセスできるかを制御することも可能にする。

プライバシ及びコンプライアンスの規制は急速に変化しており、範囲及び複雑さが増している。消費者は、自分のユーザ・データに対する高いレベルの透明性及び制御を期待するようになっており、会社が消費者プライバシに適切に対処できない場合、会社には、顧客離れ及び多額の罰金が生じるリスクがある。本発明の特定の実施例は、ＣＴＶアプリケーション及びＯＴＴアプリケーションにおいて消費者プライバシを維持するための技術的解決策を提供し、最終的に、ユーザ・データ及びプライバシに関する様々なタイプのユーザ・コンテンツのバージョンの作成並びに管理を可能にする。本発明のシステム及び方法は、企業に関連するデータ・セットのすべてについてシステム全体で顧客の同意及び嗜好をシームレスに且つ遵守して管理するのに有用な技術的解決策を提供する。

この技術的改善により、会社は、会社が提供する決定論的識別子に基づいて、データ主体に関する同意を生成及び格納することが可能になるので、この技術的改善は、このようなアプリケーションに特に好適である。同意は、サーバ側に格納され、厳密性、正確性、忠実性、及び適切性について確認され得、同意を示すデータ主体に準拠するために会社及びその下流パートナーによって取得され得る。本発明のシステム及び方法は、アプリケーションが、消費者又はデータ主体の選択を伝達し、サーバ側ＡＰＩと連携して、必要な同意情報の有効性を確認して（ｖａｌｉｄａｔｅ）必要な同意情報を生成し、その同意情報をアプリケーション内に引き戻すための、アプリケーション・プログラミング・インターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）・エンドポイントを提供する。

本発明のシステム及び方法は、組織がサーバ間統合によって同意及び嗜好を管理することを可能にする技術的解決策を提供する。この解決策は、アイデンティティ・プロバイダと統合し、例えば特定の実施例ではハッシュ化されたＩＤ ＭＩＤ又は電子メール・アドレスに関するデータ主体情報を格納することができる、データ主体アイデンティティを確立することを可能にする。さらに、これらの実施例は、ＩＤプロバイダ・ソリューションと統合され得るハッシュ化されたユーザＩＤに同意及び嗜好を接続すること、複数のタイプのデータ・カテゴリに対する同意を格納すること、並びに、組織を横断した嗜好の同期及び更新を可能にする。

本発明のこれらの特徴及び他の特徴、目的、並びに利点は、好ましい実施例の以下の詳細な説明を以下に説明する図面と併せて考察することにより、よりよく理解されるであろう。

本発明の一実施例による、主体データを保存するための方法の一実施例を示す模式図である。 本発明の一実施例による、主体データを取得するための方法の一実施例を示す概略図である。 本発明の別の実施例による、主体データを取得するための方法の一実施例を示す概略図である。 本発明の一実施例による、スキーマ構造及びアーキテクチャの一実施例を示す概略図である。 本発明の一実施例による、ベンダ・キーを使用して主体データを保存するアーキテクチャの一実施例を示す概略図である。 本発明の一実施例による、本発明のシステム及び方法をＣＴＶアプリケーションに統合するための１つの方法を示す概略図である。 本発明のシステム及び方法の一実施例による、スキーマ・テーブルの一実例を示す図である。 本発明のシステム及び方法の一実施例による、スキーマ・テーブルの一実例を示す図である。 本発明のシステム及び方法の一実施例による、主体テーブルの一実例を示す図である。 本発明のシステム及び方法の一実施例による、主体データ・テーブルの一実例を示す図である。 本発明のシステム及び方法の一実施例による、トランザクション・データベース・テーブルの一実例を示す図である。 本発明のシステム及び方法の一実施例による、スキーマ統合テーブルの一実例を示す図である。 本発明のシステムの一実施例を示す図である。

本発明をさらに詳細に説明する前に、本発明の範囲は後続の非仮特許出願の特許請求の範囲によってのみ限定されるため、本発明が本明細書の何らかのセクションに記載された特定の実施例に限定されないこと、及び特定の実施例を説明する際に使用される用語がそれらの特定の実施例を説明することのみを目的としており、限定することを意図していないことが理解されるべきである。

本発明は、会社又はサービス・プロバイダ（本明細書では「プロバイダ」と呼ばれる。本発明は、プロバイダがＣＴＶアプリケーション及びＯＴＴアプリケーションを提供する場合に特に好適であることがある）によって消費者プライバシを管理するためのシステム及び方法を対象とし、システム及び方法は、ユーザ（「データ主体」と呼ばれることがある）によって実施された同意トランザクションを記録することを可能にし、プロバイダの下流パートナー（本明細書では「ベンダ」と呼ばれることがある）にユーザ嗜好を提供するためにユーザ嗜好を永続的に利用可能にするとともに、技術環境における消費者情報の収集及び使用を規定するプライバシ規制への遵守を示すために必要なすべての情報を格納する。本発明のシステム及び方法は、プロバイダのデータ資産及びベンダ関係全体にわたるデータ主体の同意及び嗜好の長期的な記録の選択的なキュレーション、ロギング、並びに配布のための中央リポジトリを利用した技術的解決策を提供する。技術的解決策により、消費者嗜好に関するデータ収集点全体にわたる単一の顧客ビューの維持、下流でのユーザ嗜好の永続化、プログラムによるユーザ嗜好の取得、並びに制御同意及び嗜好のステータスへの下流ベンダによるアクセスが可能になる。

本発明のシステム及び方法によって提供される技術的解決策の構成要素及び機能性についてより具体的な情報を提供する前に、技術的トランザクションに関与するエンティティについて説明する必要がある。上述したように、本発明のシステム及び方法は、消費者とサービス・プロバイダとの対話の状況において特に好適であり、消費者は「データ主体」と呼ばれ、サービス・プロバイダは「プロバイダ」と呼ばれる場合がある。データ主体は、発行者によって提供された情報に基づいて個人情報の処理又は収集についてオプトアウト又は同意するための明瞭な方法を必要とする（これは「通知」要件と呼ばれることがある）。同様に、これらの技術環境におけるデータ主体は、データの収集前又は収集時に特定のブランド又はパートナーからの特定の嗜好を変更することも可能でなければならない。最後に、これらのデータ主体は、後の時点で自分の選択及び嗜好を調整することも可能でなければならない。要するに、データ主体とは、個人データが収集され得る人物であり、通常、プロバイダのプラットフォーム又はアプリケーションのユーザと一致する。データ主体に関して収集され得る個人情報には、例えば、データ主体の電子メール・アドレス、電話番号、顧客関係管理識別子（ＣＲＭ ＩＤ：ｃｕｓｔｏｍｅｒ ｒｅｌａｔｉｏｎｓｈｉｐ ｍａｎａｇｅｍｅｎｔ ｉｄｅｎｔｉｆｉｅｒ）、又は他の同様のデータが含まれる。データ主体は、最も一般的にはプロバイダのユーザに関係しているが、データ主体はデバイス、会社、又はアカウントである可能性もある。

一方、プロバイダは、プロバイダによって管理されている静的／決定論的な識別子に、データ主体の様々な形式の同意及び嗜好を登録することが可能である必要がある。プロバイダは、登録された情報に承認済みアクセス・キー管理を介してアクセスし、同意及び嗜好設定に基づいて、下流ベンダによってアクセスされ得るデータ主体情報を決定し、データ主体から直接受け取ったオプトアウト要求を尊重して従うことも可能である必要がある。さらに、プロバイダは、プロバイダ・プラットフォームでのメッセージングを可能にするために、有効な透明性同意文字列（ＴＣ文字列：ｔｒａｎｓｐａｒｅｎｃｙ ｃｏｎｓｅｎｔ ｓｔｒｉｎｇ）をプロバイダのパートナーに提供する必要がある。

前述のように、本発明のシステム及び方法の中核となるものは、データ主体が同意したときに記録された個々の同意イベントを表す同意トランザクションである。各同意トランザクションは、スキーマによって決定された特定の同意トランザクションを一意に識別するために必要なすべての情報を含む。例えば、同意トランザクションには、同意トランザクションを実施した人物の識別、その同意によって表明された嗜好、データ主体が受諾した法的通知、同意の証明（例えば、ユーザに提示されたフォーム）、及び同意トランザクションに関係する他の同様の情報のようなデータが含まれる。同意トランザクションを書き込むこと及び読み出すことはできるが、一旦同意トランザクションが存在すると、同意トランザクションを修正することはできない。代わりに、同意トランザクションは、データ主体が提供した同意の履歴を表しており、したがって、データ主体の既存の同意嗜好を修正するために新しい同意トランザクションを実行することができる一方で、元の嗜好を有する以前の同意トランザクションは、履歴上引き続き利用可能である。

上述したように、データ主体は、データがプロバイダによって収集及び処理されるエンティティ（個人、デバイス、会社、アカウントなど）を表す。データ主体と関係付けられたデータ構造は、好ましくはＪＳＯＮデータ・フォーマットを使用して、スキーマによって定義される。「Ｊｏｈｎ Ｄｏｅ」という名前のデータ主体のデータ構造の一実例を以下に示す。
プロパティ名は、スキーマからのデータ・フィールド名と一致しなければならず、データ・フィールド値は、スキーマによって定義されたデータ型に追従しなければならない。以下でより詳細に説明するように、識別フィールドの値はプロバイダ組織全体における一意の主体を決定するために使用されるので、識別フィールドは必須フィールドである。データ構造の他のすべてのプロパティは、（スキーマからの）データ・フィールドの有効性確認に応じて、値を有する場合もあれば値を有していない場合もある。識別フィールドは、スキーマ内の任意のフィールドとすることができ、主体データ格納要求によってそのフィールドを定義するかは送信元次第である。１つのデータ主体が、複数の識別フィールドに対応することができる。主体データを作成した後に、識別フィールドを追加することができる。例えば、ある主体は、識別フィールドとして設定された１２３という値を伴うプロパティ「ｕｓｅｒ＿ｉｄ」を有することができ、また、ｓｕｂｊｅｃｔ１２３＠ｅｍａｉｌ．ｃｏｍという値を伴う別の識別フィールド「ｅｍａｉｌ」に関連付けられることも可能である。各識別フィールドを追加した後、主体識別フィールドを交換可能に使用して、主体の主体データを読み書きすることができる。

図１に、ベンダ・アクセス・キーを使用して主体データを保存するための方法の一実施例が示されている。図示されているように、プロセスは、ステップ１０において、識別フィールド、主体データ・ペイロード、及びベンダ・キーの入力から開始する。スキーマの有効性確認を行い（１２）、次いで、組織ＩＤ及び識別値をハッシュ化して（１４）、入力データに関連付けられた主体ＩＤ１６を決定する。次いで、システムは、主体ＩＤが主体データベースに存在するかどうかを判定し（１８）、主体ＩＤが存在しない場合、新しい主体ＩＤが作成される（２０）。主体ＩＤが作成されると（又は決定された主体ＩＤが既存の主体ＩＤと一致すると）、主体ＩＤと関係付けられた主体データ２２を保存し、主体データをその主体の同意トランザクション２４に関連付けることができ、主体の嗜好及び同意トランザクションに従って、通知を送信することができる（２６）。

図２に、ベンダ・アクセス・キーを使用して主体データを取得するための方法の一実施例が提供されている。図示されているように、プロセスは、（識別値を有する）識別フィールド及び（組織ＩＤに関連付けられた）ベンダ・キーの入力（２８）から開始する。識別値及び組織ＩＤにハッシュ関数が適用されて（３０）、主体ＩＤ１６が決定される。主体ＩＤ１６が決定されると、主体ＩＤ１６のデータベース及び主体データ２２のデータベースにおいて主体ＩＤをその主体ＩＤに関連付けられた主体データと照合することによって、主体データを取得することができる（３２）。

トランザクション・データは、トランザクション・データベースから取得されることが可能であり、一実施例では、図３に示すプロセスを利用して行われる。プロセスは、（識別値を有する）識別フィールド及び組織キーの入力（３４）から開始する。一実施例では、任意選択としてスキーマＩＤの入力を提供することもできる。次いで、識別値がハッシュ化されて（３６）、主体ＩＤ１６が決定される。次いで、主体ＩＤ１６を使用して、関連付けられたデータ主体のデータを取得し（３２）、次いで、特定のデータ主体に関連付けられたトランザクション２４を取得することができる。

図５は、識別フィールド、ベンダ・キー、及びプライバシ・マネージャ・アプリケーションＩＤとしての入力を用いて、主体に対して保存／却下機能を適用する（９０）ためのプロセスを示す。最新のベンダ・リストが取得され（９２）、プライバシ・マネージャ構成が取得される（９４）。これらのデータから、トランザクション同意文字列（ＴＣ文字列）又はデータを作成することができ（９６）、ベンダ・キーを使用して主体データを保存することができる（９８）。

組織に関連付けられたデータへのアクセスは、コンソール・アクセス管理システムによって決定される。一実施例では、所与のコンソール・ユーザに単一の管理者権限が手動で割り当てられる。管理者権限を有する任意のコンソール・ユーザは、組織のアクセス・キーを管理することが可能である。アクセス・キーは、システムへ送られた要求が承認される方法であり、承認は、クライアントがシステム・リソースにアクセスできるかどうかを判定する。実施されるアクションに応じて、２種類の承認キーのうちの一方が提供されなければならない。最初に、トランスポート層セキュリティ（ＴＬＳ：ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ）（ＨＴＴＰセキュア又はＨＴＴＰＳ）を介したハイパーテキスト転送プロトコル（ＨＴＴＰ：ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）基本認証として、アプリケーション・プログラミング・インターフェース（ＡＰＩ）承認が実装される。ＡＰＩキーは、コンソール・ユーザ・インターフェース（ＵＩ）から得ることができ、ＡＰＩへの接続は、ＴＬＳ１．２（又はそれ以上）を使用して確立することができる。クライアントがＡＰＩを介して行う最も一般的な呼出しのうちの１つは、主体データを投稿又は取得することである。認証するための簡単な方法は、状況に応じて組織ＡＰＩキー又はベンダＡＰＩキーを使用することである。ベンダＡＰＩキーは、例えば、主体データを格納及び取得するために使用されてもよく、組織ＡＰＩキーは、組織リソースを管理するために使用されてもよい。

主体データを格納して読み出すための本発明のシステム及び方法の好ましい実施例では、ベンダ・キー１３０が提供されなければならない。管理者権限を有するコンソール・ユーザは、統合内でベンダ・キー１３０を生成し、次いで、要求を送信するときにヘッダ内でそのベンダ・キー１３０を使用することができる。毎回の書込み及び読出しの動作が計算コストに影響することに留意することが重要である。一方、組織ＡＰＩキーは、組織がコンソール・アプリケーションの外部にある組織のデータ及びリソースにアクセスして管理するために組織によって使用されるキーである。組織ＡＰＩキーを使用して、スキーマを作成及び一覧表示すること、データ・フィールドを管理すること、統合を追加及び修正すること、主体データ又はトランザクション・データを取得することなどが可能である。しかしながら、それらは、主体データを作成及び保存するための権限又は新しい組織キーを作成するための権限を付与していない。組織キーは、コンソール・アプリケーションを介して作成され、作成できる組織キーの数に制限はない。組織キーは、失効することはなく、組織キーが削除されるまで有効であり使用可能である。

図６を参照すると、エンド・ユーザ１００の同意及びアクセスが示されている。この実例では、システムはＣＴＶシステムである。パブリッシャＣＴＶアプリ１０２はエンド・ユーザ１００によってアクセスされ、パブリッシャＣＴＶアプリ１０２は、サインイン又はサインアップ・インターフェースを提示する（１０４）。登録せずに続行するための選択肢も提供されてもよい。システムは、パブリッシャ・サービス同意ストア１０８からのデータを使用して、ローカルの同意について確認する（１０６）。同意の存在についての決定ブロック１１０において、結果がいいえである場合、処理は、同意画面１１２に進み、同意が提供されなかったことを示す。同意が提供されている場合、決定ブロック１１４において、システムによって測定されたように同意が適切であるかどうかが判定される。適切性は、同意文字列を用いて以下に説明する方法を適用する適切性アダプタ１１６を使用してテストされてもよい。同意が適切でない場合、処理は、同意画面１１２に戻り、同意が適切ではなかったことを示す。同意が適切であると判明した場合、ＣＴＶアクセスが提供される（１１８）。

本発明のシステム及び方法の場合、データは、図４に示すようなデータ・スキーマを使用して構造化される。データ・スキーマは、ＡＰＩ又はユーザ・インターフェースを介して定義され、以下のプロパティ、すなわち（ａ）名前 － スキーマの名前、（ｂ）目的 － トランザクション・データが処理される目的のログをとるために使用される、（ｃ）法的根拠 － トランザクション・データが処理される法的根拠のログをとるために使用される、及び（ｄ）データ・フィールド － 構造及びデータの有効性確認に使用される、というプロパティを有する。特定の目的及び用途用にデータ・スキーマを事前に構成するために、データ・スキーマ・テンプレートが使用されてもよい。テンプレートは、例えば、データ・スキーマの目的、法的根拠、及びデータ・フィールドを含んでもよい。

データ・フィールドは、データを構造化してデータの有効性を確認するために使用され、ＡＰＩ又はユーザ・インターフェースを介して事前決定されるべきである。データ・フィールドは、以下のプロパティ、すなわち（ａ）名前 － データ・フィールドの名前、（ｂ）型 － データ・フィールドに格納されるデータの型、（ｃ）説明 － データ・フィールドに格納されるデータに関する説明、（ｄ）カテゴリ － データ・フィールドに格納されるデータのデータ・カテゴリ、及び（ｅ）バリデータ － データ・フィールドに格納されたデータの有効性を確認するために使用される、というプロパティを有する。パブリック・データ・フィールドは、データ・カテゴリ、型、及びバリデータをすでに有する、事前構成されたデータ・フィールドである。本発明のシステム及び方法は、データ・スキーマ及び（パブリック・データ・フィールドを含む）データ・フィールドを含めるためにスキーマ・データベースを利用する。

スキーマ・テーブル及び主体テーブルは、スキーマＡＰＩに接続される。図９に、例示的なスキーマ・テーブル３８が示されている。スキーマ・データベース（ＮｏＳＱＬデータベースなど）は、データ・スキーマ、データ・フィールド、及びパブリック・データ・フィールドを含む。主体テーブルは、主体ＩＤから主体データＩＤへのマッピングを含む。高速な応答時間が必要とされる状況（以下で詳細に説明する主体データ取得要求など）の場合、組織のための機能は、キャッシュ層又はクラスタに対してクエリを実行するが、クエリがキャッシュされていない場合、データベース（非リレーショナル・データベース又はＮｏＳＱＬデータベースなど）に対してクエリが実行される。主体ＩＤは、組織ＩＤ及び識別フィールドのハッシュであり、主体データＩＤは、主体ＩＤ、組織ＩＤ、及びスキーマＩＤのハッシュである。

図８に、例示的な主体テーブル４０が示されている。主体データ・テーブルは、主体データの最新の状態を含む。このデータには速い応答速度が必要とされるので、性能を最適化するために、主体テーブルの前にキャッシュ層が配置される。図１１に、例示的な主体データ・テーブル４２が示されている。主体データ・テーブルに含まれるフィールドには、例えば、（ａ）主体データを含む、データ・フィールド、（ｂ）主体データが削除される期限満了日を示す、有効期限日、（ｃ）主体データＩＤ（主体ＩＤ、組織ＩＤ、及びスキーマＩＤのハッシュ）を提供する、ｉｄフィールド、（ｄ）データ変更ウェブフックに関する通知の構成であり、ウェブフックにおいてどのデータ・フィールドを渡すかを識別する、通知構成フィールド、（ｅ）通知ウェブフックの宛先エンドポイントを識別する、通知ＵＲＬフィールド、（ｆ）顧客の組織の一意ＩＤである、組織ＩＤフィールド、（ｇ）データ・スキーマの一意ＩＤである、スキーマＩＤフィールド、（ｈ）組織ＩＤ及び識別フィールドのハッシュである、主体ＩＤフィールド、並びに（ｉ）タイムスタンプである、タイムスタンプ・フィールドが含まれてもよい。

上述したように、履歴トランザクションを取得できるように、トランザクションは、トランザクション・データベース２４に格納される。トランザクション・データベースは、以下のフィールド、すなわち（ａ）主体データを含む、データ・フィールド、（ｂ）主体データが削除される期限満了データを示す、有効期限日フィールド、（ｃ）主体データＩＤ（主体ＩＤ、組織ＩＤ、及びスキーマＩＤのハッシュ）を識別するＩＤフィールド、（ｄ）顧客の組織の一意ＩＤである、組織ＩＤフィールド、（ｅ）データ・スキーマの一意ＩＤである、スキーマＩＤフィールド、（ｆ）組織ＩＤ及び識別フィールドのハッシュである、主体ＩＤフィールド、並びに（ｇ）タイムスタンプである、タイムスタンプ・フィールド、というフィールドを有するデータ・テーブルを含んでもよい。図１０には、例示的なトランザクション・データベース・テーブル４４が示されている。

統合テーブル１２２（図４）を利用して、ベンダごとに、スキーマごとにアクセス・キー及びアクセス権を格納する。統合テーブル１２２は、他の項目の中でもとりわけ、以下のフィールド、すなわち（ａ）統合に割り当てられた一意ＩＤであり、ベンダＡＰＩキーとしても使用される、ＩＤフィールド、（ｂ）統合名である、名前フィールド、（ｃ）顧客の組織の一意ＩＤである、組織ＩＤフィールド１２６、（ｄ）読取りアクセス権を提供する、読取りアクセス・フィールド、（ｅ）データ・スキーマの一意ＩＤである、スキーマＩＤフィールド１２８、（ｆ）顧客のサブスクリプションに対して一意のＩＤである、サブスクリプションＩＤフィールド、（ｇ）統合に割り当てられたベンダに対して一意のＩＤである、ベンダＩＤフィールド１２４、及び（ｈ）書込みアクセス権を提供する、書込みアクセス・フィールドを含んでもよい。図７－１及び図７－２に、例示的な統合テーブル４６が示されている。各スキーマは、場合によっては複数のベンダ・キー１３０に関連付けられる。ＡＰＩ内で呼び出され得る機能は、データ・フィールド、パブリック・データ・フィールド、データ・スキーマ、スキーマ・テンプレートなどの管理を支援する組織機能を含む。他の機能を使用して、事前定義された値を使用してスキーマ・テンプレートからスキーマを作成すること、所与のスキーマのすべてのスキーマ・プロパティを取得することなどが可能である。統合ＡＰＩは、スキーマごとの組織キー管理及びキー管理を含む。各スキーマ統合はＡＰＩキー（ベンダ・キー）を表し、顧客はキーごとにアクセス権を制御することができる。統合ごとに、通知ウェブフックが構成され得る。同意トランザクションは、ＡＰＩを介してバッチで、又はアダプタを介して、直接送出される。システムへの呼出しはＡＰＩキー及び識別フィールドを含み、これにより、スキーマの有効性を確認すること、及びトランザクションを管理することが可能になる。統合ＡＰＩ内で動作する機能は、組織キーを管理するための機能（組織キーは、スキーマ間でデータを管理するために使用され、組織外で共有されるべきではない）、ベンダを管理するための機能（ベンダは、ＩＤ、名前、及び説明を有し、どのベンダがスキーマへのアクセス権を有するかを追跡するために統合レベルによって割り当てられる）、統合を管理するための機能（スキーマ統合は、所与のベンダのスキーマへのアクセスを表す）、並びにスキーマ統合キーを管理するための機能を含む。

主体データＡＰＩは、（ａ）識別フィールドをハッシュ化することによって主体ＩＤの生成を実行する、（ｂ）主体ＩＤを主体テーブルに格納し、主体データＩＤを主体データ・テーブルに格納する、（ｃ）主体データを取得するプロセスを実行する、（ｄ）主体データ・テーブル及びトランザクション・テーブルから主体データを削除する、（ｅ）主体ＩＤにマッピングされる追加の識別フィールドを追加する、（ｆ）請求イベントをメッセージ・キューに送信する、（ｇ）トランザクション・テーブルからすべての履歴トランザクション・データを取得する、（ｈ）ＡＰＩキーを処理してアクセス・ポリシ・メッセージを返すように動作可能な機能を含む。最後に、インフラストラクチャのエンドポイントを介して呼び出されるＡＰＩ機能は、主体データを取り出して主体データをトランザクション・データベースに格納するための機能、及び請求イベントを送信するための機能を含む。

一般的に、上記について、特定のハードウェア構成要素及びシステムを参照して説明することができる。好ましい実施例では、本発明のシステム及び方法は、クラウドに基づいており、マネージド・サービス（Ａｍａｚｏｎによって提供されるＡＷＳマネージド・サービスなど）に依存する。コア・インフラストラクチャでは、以下のサービス、すなわち、ＮｏＳＱＬデータベース、ＮｏＳＱＬデータベースのキャッシュ層、リレーショナル・データベース、メッセージ・キュー、ＡＰＩ、サーバレス計算サービス、認証、承認、ユーザ管理サービス、及びイベントベースの請求システム・サービスが利用されてもよい。

本発明のシステムの様々な構成要素を説明してきたが、主体を作成するための本発明の使用方法の一実施例を、図１２を参照して説明することができる。図示されているように、プロセスは、ベンダＡＰＩゲートウェイ５０においてベンダ４８からの要求を受信することから開始し、ベンダＡＰＩゲートウェイ５０は、オーソライザ機能５２を呼び出す。主体を作成するよう求める要求は、一実例において以下の形式をとることができる。

オーソライザ機能５２は、イベント・ヘッダからＡＰＩ値キー（「ａｐｉＫｅｙ」）を取得し、ＡＰＩキー値がｎｕｌｌ又は未定義である場合、拒否ポリシ・メッセージが返される。承認キャッシュ層５４において、スキーマ統合テーブル内でＡＰＩキーを検索するクエリが実行される。キャッシュされていない場合、ＮｏＳＱＬデータベースである承認キー・データベース５６においてクエリが実行される。ＡＰＩキーが見つからない場合、拒否ポリシ・メッセージが返される。それ以外の場合、システムは、クエリ結果からの要求のタイプ及び統合を、権限と照合する。要求が権限を有していない場合、拒否ポリシ・メッセージが返される。統合プロパティである組織ＩＤ、統合ＩＤ、サブスクリプションＩＤ、スキーマＩＤ、通知構成、及び通知ＵＲＬを使用して、コンテキスト・オブジェクトが作成される。コンテキスト・オブジェクトとともに許可ポリシ・メッセージが返される。

この段階で、ベンダＡＰＩゲートウェイ５０は、主体作成機能オブジェクト（前のオーソライザ・コンテキスト・オブジェクトからのプロパティを含む）を呼び出す。システムは、イベント・オブジェクトが組織ＩＤを含むかどうかを確認し、組織ＩＤを含まない場合、エラー・メッセージを返す。次いで、システムは、イベント・オブジェクトがサブスクリプションＩＤを含むかどうかを確認し、サブスクリプションＩＤを含まない場合、エラー・メッセージを返す。次いで、メッセージは、メッセージング・キュー６０に送信されて、請求イベント送信機能６２によって処理される。また、システムは、要求本文が有効なＪＳＯＮを含むかどうかを確認し、有効なＪＳＯＮを含まない場合、エラー・メッセージを返す。スキーマＩＤは、スキーマＡＰＩ６４においてイベント・コンテキスト・オブジェクトから取得される。スキーマＩＤ及び組織ＩＤを使用して、スキーマ・テーブルからスキーマが取得される。スキーマが見つからない場合、エラー・メッセージが表示される。次いで、要求本文は、識別フィールド・プロパティについて確認され、要求本文が識別フィールド・プロパティを含まない場合、ランダムな一意識別子（ＵＵＩＤ）が生成される。次いで、要求本文は、スキーマ定義と突き合わせて有効性を確認され、有効でない場合、エラー・メッセージが返される。有効である場合、識別値及び組織ＩＤをハッシュ化することによって主体ＩＤが作成され、主体ＩＤは、スキーマ・キャッシュ層６６を介して主体ＩＤマッピング・データベース６８に適用される。次いで、主体ＩＤを使用して、主体データＡＰＩ７０、主体キャッシュ層７２、及び主体データベース７４を介して主体テーブルから主体を取得することができる。主体が見つからない場合、主体は、主体データベース７４に新しい主体として保存される。次いで、期限満了日を算出することができ、主体ＩＤ、組織ＩＤ、及びスキーマＩＤをハッシュ化して、主体ＩＤマッピング・データベース６８の一意の主体データＩＤを取得する。主体データは保存され、任意の既存の主体データが上書きされる。主体作成機能がこの段階に到達すると、成功したと見なされ、主体データとともに成功ステータス応答が返される。それ以外の場合、エラー応答が返される。

同様のプロセスを使用して、主体データ取得機能を使用して主体データを取得することができる。ＡＰＩゲートウェイ５０は、要求を受信し、オーソライザ機能５２を呼び出してイベント・オブジェクトを渡す。主体データを取得するよう求める例示的な要求メッセージは、以下の形式をとることができる。
ＧＥＴ ｈｔｔｐｓ：／／ａｐｉ．ｐｒｅｆｅｒｅｎｃｅｌｉｎｋ．ｃｏｍ／ｄａｔａ－ａｐｉ／ｓｕｂｊｅｃｔｓ／ｉｄｅｎｔｉｆｙｉｎｇ－ｖａｌｕｅｓ／ｔｅｓｔ－ｓｕｂｊｅｃｔ＠ｅｍａｉｌ．ｃｏｍ
ａｐｉＫｅｙ：ｅ６ａ８ｆ３４５－２２５３－４７９６－ａ９ｆ８－ｅ８５４９０ｂ３４８１６

統合ＡＰＩ５８は、イベント・ヘッダからＡＰＩキーの値を取得し、値がｎｕｌｌ又は未定義である場合、拒否ポリシ・メッセージを返す。ＡＰＩキーの取得が成功した場合、スキーマ・データベース７６にあるスキーマ統合テーブル内でＡＰＩキーを検索するためのクエリが実行される。スキーマ統合テーブル内にＡＰＩキーが見つからない場合、拒否ポリシ・メッセージが返される。それ以外の場合、システムは、（クエリ結果からの）要求のタイプ及び統合を、権限と照合する。要求に対する権限がない場合、拒否ポリシ・メッセージが返される。それ以外の場合、システムは、統合プロパティ、すなわち組織ＩＤ、統合ＩＤ、サブスクリプションＩＤ、スキーマＩＤ、通知構成、及び通知ＵＲＬを使用して、コンテキスト・オブジェクトを作成する。コンテキスト・オブジェクトとともに許可ポリシ・メッセージがＡＰＩゲートウェイ５０に返される。

この段階で、ベンダＡＰＩゲートウェイ５０は、（前のオーソライザ・コンテキスト・オブジェクトからのプロパティを含む）イベント・オブジェクトを渡す主体データ取得機能を呼び出す。主体データ取得機能は、イベント・オブジェクトが組織ＩＤを含むかどうかを確認し、組織ＩＤを含まない場合、エラー・メッセージを返す。組織ＩＤを含む場合、システムは、イベント・オブジェクトが（例えば請求システムなどからの）サブスクリプションＩＤを含むかどうかを確認し、サブスクリプションＩＤを含まない場合、エラー・メッセージを返す。サブスクリプションＩＤを含む場合、メッセージが、メッセージング・キュー６０を介して送信されて、請求イベント送信機能６２によって処理される。次に、ヘッダから識別値が取得され、ＡＰＩゲートウェイ５０にこの識別値についての有効性確認が設定され、したがって、識別値は、ｎｕｌｌとすることはできない。識別値及び組織ＩＤにハッシュ関数が適用されて、主体ＩＤが取得される。主体ＩＤを使用して主体を取得するために、主体テーブルで項目取得動作が実行される。主体テーブル内に主体が見つからない場合、主体が存在しないことを示すメッセージが返される。主体が見つかった場合、イベント・コンテキスト・オブジェクトからスキーマＩＤが取得され、主体ＩＤ、組織ＩＤ、及びスキーマＩＤにハッシュが適用されて、一意の主体データＩＤが作成される。次いで、システムは、主体データＩＤを使用して、ＮｏＳＱＬデータベースで主体データ取得の取得動作を実行する。主体データが存在しない場合、主体データが見つからないことを示すメッセージが返される。それ以外の場合、主体データＤＴＯ（ｄａｔａ ｔｒａｎｓｆｅｒ ｏｕｔ：データ転送）オブジェクトが作成され、成功メッセージが返され、主体データが転送される。

現時点で、主体についての既知の識別フィールド（主体の電子メール、電話番号など）に基づいて、それらの識別フィールドに対応する主体の同意及び承諾レコードを作成することができ、後でそのようなレコードにアクセス（又は上書き）して、何らかの識別フィールドと関係付けられた主体が特定の組織又はベンダに承諾を与えているかどうかを判定することができる。この点に関して、ユーザが組織又はベンダのアプリケーション（ＣＴＶアプリケーションなど）にログインし、何らかの識別フィールドを提供すると、システムは、主体と関係付けられた承諾レコード及び同意トランザクションを取得して、承諾及び許可を決定することができる。

システムは、トランザクション・データ格納サービス７８を介して、トランザクション・データベース２４にデータを格納することを可能にし、ウェブフックは、ウェブフック送信サービス８０を介して送信されてもよい。これにより、リアルタイムのステータス及び更新がシステムを終了することが可能になる。顧客８２のシステムへのアクセスは、管理ＵＩ８４を介して実現される。前述したように、このＵＩは、管理ＡＰＩ認証８６と管理ＡＰＩゲートウェイ８８との２つのＡＰＩを介したシステムへのアクセスを可能にする。

本明細書に記載の実装形態及び様々な代替の実装形態において、本発明は、ハードウェアとソフトウェアとの任意の組合せによって実施されてもよい。例えば、一実施例では、システム及び方法は、コンピュータ・システム又はコンピュータ・システムの集合体によって実施されてもよく、コンピュータ・システムのそれぞれが、プロセッサに結合されたコンピュータ可読記憶媒体に記憶されたプログラム命令を実行する１つ又は複数のプロセッサを含む。プログラム命令は、本明細書に記載の機能を実施してもよい。図に示されている本明細書に記載の様々なシステム及びディスプレイは、例示的な実装形態を表している。いずれの方法の順序も、変更されてもよく、様々な要素が追加、修正、又は省略されてもよい。

本明細書に記載のコンピューティング・システム又はコンピューティング・デバイスは、本発明の様々な実装形態の一部を形成するものとして、クラウド・コンピューティング・システム又は非クラウド・コンピューティング・システムのハードウェア部分を実装してもよい。コンピュータ・システムは、汎用サーバ、パーソナル・コンピュータ・システム、デスクトップ・コンピュータ、ラップトップ又はノートブック・コンピュータ、メインフレーム・コンピュータ・システム、ハンドヘルド・コンピュータ、ワークステーション、ネットワーク・コンピュータ、消費者向けデバイス、アプリケーションサーバ、記憶デバイス、電話、携帯電話、又は一般に任意のタイプのコンピューティング・ノード、計算ノード、計算デバイス、及び／若しくはコンピューティング・デバイスを含むがこれらに限定されない、様々なタイプのデバイスのうちのいずれかであってもよい。コンピューティング・システムは、入力／出力（Ｉ／Ｏ）インターフェースを介してシステム・メモリに結合された１つ又は複数のプロセッサを含む（いずれのプロセッサも、シングルスレッド又はマルチスレッドであり得る複数の処理コアを含んでもよい）。コンピュータ・システムは、Ｉ／Ｏインターフェースに結合されたネットワーク・インターフェースをさらに含んでもよい。

様々な実施例において、コンピュータ・システムは、１つのプロセッサを含む単一プロセッサ・システム、又は複数のプロセッサを含むマルチプロセッサ・システムであってもよい。プロセッサは、計算命令を実行することが可能な任意の好適なプロセッサであってもよい。例えば、様々な実施例において、プロセッサは、様々な命令セット・アーキテクチャのいずれかを実装する、汎用プロセッサ又は組込み型プロセッサであってもよい。マルチプロセッサ・システムでは、一般に、プロセッサのそれぞれが同じ命令セットを実施してもよいが、必ずしもそうである必要はない。コンピュータ・システムは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク又はインターネットなどの通信ネットワークを介して他のシステム及び／又は構成要素と通信するための、１つ又は複数のネットワーク通信デバイス（例えば、ネットワーク・インターフェース）も含む。例えば、コンピューティング・デバイス上で実行されるクライアント・アプリケーションは、ネットワーク・インターフェースを使用して、クラウド・コンピューティング環境又は様々なサブ・システムに実装されるような非クラウド・コンピューティング環境において本明細書に記載のシステムの構成要素のうちの１つ又は複数を実装する単一のサーバ又はサーバのクラスタ上で実行されるサーバ・アプリケーションと通信してもよい。別の実例では、コンピュータ・システム上で実行されるサーバ・アプリケーションのインスタンスは、ネットワーク・インターフェースを使用して、他のコンピュータ・システム上で実施され得るアプリケーションの他のインスタンスと通信してもよい。

コンピューティング・デバイスは、１つ又は複数の永続性記憶デバイス及び／又は１つ又は複数のＩ／Ｏデバイスも含む。様々な実施例において、永続性記憶デバイスは、ディスク・ドライブ、テープ・ドライブ、ソリッド・ステート・メモリ、他の大容量記憶デバイス、又は任意の他の永続性記憶デバイスに対応してもよい。コンピュータ・システム（又はコンピュータ・システム上で動作する分散アプリケーション又はオペレーティング・システム）は、所望に応じて、命令及び／又はデータを永続性記憶デバイスに保存し、必要に応じて、保存された命令及び／又はデータを取得してもよい。例えば、いくつかの実施例において、コンピュータ・システムは、制御プレーン又は制御システムの１つ又は複数のノードを実装してもよく、永続性記憶装置は、そのサーバ・ノードに取り付けられたＳＳＤを含んでもよい。複数のコンピュータ・システムは、同じ永続性記憶デバイスを共有してもよく、又は永続性記憶デバイスのプールを共有してもよく、プール内のデバイスは、同じ又は異なる記憶技術を表す。

コンピュータ・システムは、プロセッサによってアクセス可能なコード／命令及びデータを記憶することができる１つ又は複数のシステム・メモリを含む。システム・メモリは、例えば、アクセス速度に基づいてメモリ内の情報をスワップするように設計された、システム内の複数レベルのメモリ及びメモリ・キャッシュを含んでもよい。インターリーブ及びスワッピングは、仮想メモリ実装の永続性記憶装置にまで拡張してもよい。メモリを実装するために使用される技術には、例として、スタティック・ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ダイナミックＲＡＭ、読取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、不揮発性メモリ、又はフラッシュ型メモリが含まれることがある。永続記憶装置と同様に、複数のコンピュータ・システムが同じシステム・メモリを共有してもよく、又はシステム・メモリのプールを共有してもよい。１つ又は複数のシステム・メモリは、本明細書に記載のルーチンを実施するためにプロセッサによって実行可能なプログラム命令を記憶してもよい。様々な実施例において、プログラム命令は、バイナリ、アセンブリ言語、Ｊａｖａ（登録商標）などの任意のインタプリタ型言語、Ｃ／Ｃ＋＋などのコンパイル型言語、又はこれらの任意の組合せで符号化されてもよいが、ここに示されている特定の言語は単なる例である。いくつかの実施例において、プログラム命令は、複数の別個のクライアント、サーバ・ノード、及び／又は他の構成要素を実装してもよい。

いくつかの実装形態において、プログラム命令は、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ、Ｓｏｌａｒｉｓ（商標）、ＭａｃＯＳ（商標）、又はＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）（商標）などの様々なオペレーティング・システムのいずれかであり得るオペレーティング・システム（図示せず）を実装するために実行可能な命令を含んでもよい。プログラム命令のいずれか又はすべてが、コンピュータ・プログラム製品又はソフトウェアとして提供されてもよく、コンピュータ・プログラム製品又はソフトウェアは、様々な実装形態に従ってプロセスを実施するようにコンピュータ・システム（又は他の電子デバイス）をプログラムするために使用され得る命令が記憶された、非一過性コンピュータ可読記憶媒体を含んでもよい。非一過性コンピュータ可読記憶媒体は、機械（例えば、コンピュータ）によって読取り可能な形式（例えば、ソフトウェア、処理アプリケーション）で情報を記憶するための任意のメカニズムを含んでもよい。一般的に言えば、非一過性コンピュータ・アクセス可能媒体には、磁気又は光学媒体、例えば、Ｉ／Ｏインターフェースを介してコンピュータ・システムに結合されたディスク又はＤＶＤ／ＣＤ－ＲＯＭなどのコンピュータ可読記憶媒体又はメモリ媒体が含まれてもよい。非一過性コンピュータ可読記憶媒体には、コンピュータ・システムのいくつかの実施例においてシステム・メモリ又は別のタイプのメモリとして含まれ得るＲＡＭ又はＲＯＭなどの任意の揮発性媒体又は不揮発性媒体も含まれてもよい。他の実装形態において、プログラム命令は、ネットワーク・インターフェースを介して実施され得るような、ネットワーク及び／又は有線リンク若しくは無線リンクなどの通信媒体を介して伝達される、光、音響、又は他の形式の伝搬信号（例えば、搬送波、赤外線信号、デジタル信号など）を使用して通信されてもよい。ネットワーク・インターフェースは、他のコンピュータ・システム又は任意のタイプの外部電子デバイスを含み得る他のデバイスとインターフェースするために使用されてもよい。一般に、システム・メモリ、永続性記憶装置、及び／又はネットワークを介してアクセス可能な他のデバイス上の遠隔記憶装置は、データ・ブロック、データ・ブロックの複製物、データ・ブロック及び／若しくはデータ・ブロックの状態に関連するメタデータ、データベース構成情報、並びに／又は本明細書に記載のルーチンを実施する際に使用可能な他の任意の情報を記憶することができる。

特定の実装形態において、Ｉ／Ｏインターフェースは、プロセッサと、システム・メモリと、ネットワーク・インターフェース又は他の周辺インターフェースを介するものを含むシステム内の任意の周辺デバイスとの間のＩ／Ｏトラフィックを調整してもよい。いくつかの実施例において、Ｉ／Ｏインターフェースは、１つの構成要素（例えば、システム・メモリ）からのデータ信号を別の構成要素（例えば、プロセッサ）による使用に好適なフォーマットにコンバートするために、任意の必要なプロトコル変換、タイミング変換、又は他のデータ変換を実施してもよい。いくつかの実施例において、Ｉ／Ｏインターフェースは、例えば、周辺構成要素相互接続（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス規格又はユニバーサル・シリアル・バス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）規格の変形など、様々なタイプの周辺バスを介して取り付けられたデバイスに対するサポートを含んでもよい。また、いくつかの実施例において、システム・メモリへのインターフェースなどのＩ／Ｏインターフェースの機能性の一部又はすべてが、プロセッサ内に直接組み込まれてもよい。

ネットワーク・インターフェースは例えば、コンピュータと、（１つ又は複数の記憶システムのサーバ・ノード、プライマリ・ノード、読取り専用ノード、及び／又は本明細書に記載のデータベース・システムのクライアントを実装し得る）他のコンピュータ・システムなどの、ネットワークに取り付けられた他のデバイスとの間でのデータ交換を可能にすることができる。加えて、Ｉ／Ｏインターフェースは、コンピュータ・システムと様々なＩ／Ｏデバイス及び／又は遠隔記憶装置との間の通信を可能にすることができる。いくつかの実施例において、入力／出力デバイスには、１つ又は複数の表示端末、キーボード、キーパッド、タッチパッド、走査デバイス、音声若しくは光認識デバイス、又は１つ若しくは複数のコンピュータ・システムによってデータを入力又は取得するのに好適な任意の他のデバイスが含まれてもよい。入力／出力デバイスは、特定のコンピュータ・システムに直接接続するか、又は一般に、クラウド・コンピューティング環境、グリッド・コンピューティング環境、又は複数のコンピュータ・システムを含む他のシステムにおける複数のコンピュータ・システムに接続してもよい。複数の入力／出力デバイスが、コンピュータ・システムと通信して存在してもよく、又は、コンピュータ・システムを含む分散システムの様々なノードに分散されてもよい。本明細書に記載のユーザ・インターフェースは、ＣＲＴディスプレイ、ＬＣＤディスプレイ、ＬＥＤディスプレイ、及び他のディスプレイ技術を含み得る様々なタイプの表示画面を使用して、ユーザに可視であってもよい。いくつかの実装形態では、入力は、タッチスクリーン技術を使用してディスプレイを介して受信されてもよく、他の実装形態では、入力は、キーボード、マウス、タッチパッド、若しくは他の入力技術、又はこれらの技術の任意の組合せを介して受信されてもよい。

いくつかの実施例において、同様の入力／出力デバイスは、コンピュータ・システムから分離されていてもよく、コンピュータ・システムを含む分散システムの１つ又は複数のノードと、ネットワーク・インターフェースなどの有線又は無線接続を介して対話してもよい。ネットワーク・インターフェースは、一般に、１つ又は複数の無線ネットワーキング・プロトコル（例えば、Ｗｉ－Ｆｉ／ＩＥＥＥ８０２．１１、又は別の無線ネットワーキング規格）をサポートしてもよい。ネットワーク・インターフェースは、例えば、他のタイプのイーサネット（登録商標）・ネットワークなどの任意の好適な有線又は無線の汎用データ・ネットワークを介した通信をサポートしてもよい。さらに、ネットワーク・インターフェースは、アナログ音声ネットワーク若しくはデジタル・ファイバ通信ネットワークなどの電気通信／電話通信ネットワークを介した通信、ファイバ・チャネルＳＡＮなどのストレージ・エリア・ネットワークを介した通信、又は任意の他の好適なタイプのネットワーク及び／若しくはプロトコルを介した通信をサポートしてもよい。

本明細書に記載の分散システムの実施例のいずれか、又は実施例の構成要素のいずれかは、クラウド・コンピューティング環境における１つ又は複数のネットワークベースのサービスとして実施されてもよい。例えば、データベース・システムのデータベース階層内の読込み書込みノード及び／又は読取り専用ノードは、データベースサービス及び／又は本明細書に記載の分散記憶システムを使用する他のタイプのデータ記憶サービスを、ネットワークベースのサービスとしてクライアントに提示してもよい。いくつかの実施例において、ネットワークベースのサービスは、ネットワークを介した相互動作可能な機械間の対話をサポートするように設計されたソフトウェア及び／又はハードウェア・システムによって実施されてもよい。ウェブ・サービスは、ウェブ・サービス記述言語（ＷＳＤＬ：Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などの機械処理可能なフォーマットで記述されたインターフェースを有してもよい。他のシステムは、ネットワークベースのサービスのインターフェースに関する説明によって規定された方法で、ネットワークベースのサービスと対話してもよい。例えば、ネットワークベースのサービスは、他のシステムが呼び出すことができる様々な動作を定義してもよく、様々な動作を要求するときに他のシステムが準拠することが期待され得る特定のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を定義してもよい。

様々な実施例において、ネットワークベースのサービスは、ネットワークベースのサービス要求に関連するパラメータ及び／又はデータを含むメッセージを使用することによって、要求されるか又は呼び出されてもよい。このようなメッセージは、拡張可能マークアップ言語（ＸＭＬ：Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの特定のマークアップ言語に従ってフォーマットされてもよく、且つ／又は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などのプロトコルを使用してカプセル化されてもよい。ネットワークベースのサービス要求を実施するために、ネットワークベースのサービスのクライアントは、要求を含むメッセージを組み立て、ハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などのインターネットベースのアプリケーション層転送プロトコルを使用して、ウェブ・サービスに対応するアドレス指定可能なエンドポイント（例えば、統一リソース位置指定子（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ））にメッセージを伝達してもよい。いくつかの実施例において、ネットワークベースのサービスは、メッセージベースの技法ではなく表現状態転送（ＲＥＳＴ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）技法を使用して実施されてもよい。例えば、ＲＥＳＴ技法に従って実施されるネットワークベースのサービスは、ＰＵＴ、ＧＥＴ、又はＤＥＬＥＴＥなどのＨＴＴＰメソッド内に含まれるパラメータによって呼び出されてもよい。

特に明記しない限り、本明細書で使用されるすべての技術用語及び科学用語は、本発明が属する技術分野の当業者によって一般的に理解されるものと同じ意味を有する。本明細書に記載のものと同様又は同等の任意の方法及び材料も、本発明の実践又はテストで使用することができるが、本明細書には、限られた数の例示的な方法及び材料が記載されている。本発明の概念から逸脱することなくさらに多くの修正形態が可能であることは、当業者には明らかであろう。

本明細書で使用されるすべての用語は、文脈に沿って可能な限り広く解釈されるべきである。本明細書でグループ化が使用される場合、グループのすべての個々の要素並びにグループの可能なすべての組合せ及び部分的組合せが個別に含まれることを意図している。本明細書に範囲が記載されている場合、その範囲は、範囲内のすべての部分的範囲及び個々の点を含むことを意図している。本明細書で引用されたすべての参考文献は、本明細書の開示と矛盾しない限り、参照により本明細書に組み込まれる。

Claims (15)

1. ローカル・データを格納する能力なしに、同意アクティブ化デバイス（ｃｏｎｓｅｎｔ－ａｃｔｉｖａｔｅｄ ｄｅｖｉｃｅ）上でアプリケーションにアクセスする主体のプライバシを管理するための方法であって、
   プロバイダ・サーバにおいて、組織ＩＤに関連付けられた組織サーバから、前記同意アクティブ化デバイスを使用している主体についての承諾を決定するよう求める要求メッセージを受信するステップであって、前記要求メッセージが、前記主体に関連付けられた少なくとも１つの識別値を含む、ステップと、
   前記組織ＩＤ及び前記識別値をハッシュ化して主体ＩＤを作成するステップと、
   いくつかの主体をそれぞれ主体ＩＤに関連付ける主体テーブルに格納された値に基づいて、作成された前記主体ＩＤの対応する主体を決定するステップと、
   前記主体ＩＤと関係付けられた前記主体について、前記主体に対応する１つ又は複数のデータ・スキーマを識別するステップであって、前記データ・スキーマがスキーマＩＤを含む、ステップと、
   前記主体ＩＤ、前記組織ＩＤ、及び前記スキーマＩＤをハッシュ化して主体データＩＤを作成するステップと、
   トランザクション・データベースから、前記主体データＩＤに関連付けられた１つ又は複数の同意レコードを取得するステップであって、前記１つ又は複数の同意レコードが前記主体についての承諾を含む、ステップと、
   前記１つ又は複数の同意レコード内の前記承諾に基づいて、前記同意アクティブ化デバイスにおいてアクセスを提供するステップと
   を含む、方法。
2. 前記同意アクティブ化デバイスがコネクテッドｔｖ（ＣＴＶ）デバイスである、請求項１に記載の方法。
3. 前記同意アクティブ化デバイスがオーバ・ザ・トップ（ＯＴＴ）デバイスである、請求項１に記載の方法。
4. アプリケーションにアクセスする主体についての承諾許可を決定するためのシステムであって、
   同意アクティブ化デバイスと、
   主体データベースに格納された主体テーブルと、
   スキーマ・データベースに格納されたスキーム・テーブルと、
   トランザクション・データベースと、
   前記トランザクション・データベース、前記主体データベース、前記スキーマ・データベース、及び前記同意アクティブ化デバイスと通信しているプロバイダ・サーバであって、前記プロバイダ・サーバが、プロセッサ及びメモリを含み、前記メモリが、前記プロセッサによって実行されたときに前記プロセッサに、
   組織サーバから、前記主体に関連付けられた少なくとも１つの識別値を含む要求メッセージを受信することと、
   組織ＩＤ及び前記識別値をハッシュ化して主体ＩＤを作成することと、
   いくつかの主体をそれぞれ主体ＩＤに関連付ける前記主体テーブルに格納された値に基づいて、作成された前記主体ＩＤの対応する主体を決定することと、
   前記主体ＩＤと関係付けられた前記主体について、前記スキーマ・テーブル内の前記主体に対応する１つ又は複数のデータ・スキーマを識別することであって、前記データ・スキーマがスキーマＩＤを含む、識別することと、
   前記主体ＩＤ、前記組織ＩＤ、及び前記スキーマＩＤをハッシュ化して主体データＩＤを作成することと、
   前記トランザクション・データベースから、前記主体データＩＤに関連付けられた１つ又は複数の同意レコードを取得することであって、前記１つ又は複数の同意レコードが前記主体についての承諾を含む、取得することと、
   前記１つ又は複数の同意レコード内の前記承諾に基づいて、前記同意アクティブ化デバイスにおいてアクセスを提供することと
   を実行させる命令を含む、プロバイダ・サーバと
   を含む、システム。
5. 前記同意アクティブ化デバイスがコネクテッド・テレビ（ＣＴＶ）デバイスである、請求項４に記載のシステム。
6. 前記同意アクティブ化デバイスがオーバ・ザ・トップ（ＯＴＴ）デバイスである、請求項４に記載のシステム。
7. 前記プロバイダ・サーバへの顧客アクセスを提供する管理ユーザ・インターフェース（ＵＩ）をさらに含む、請求項４に記載のシステム。
8. 前記管理ＵＩと前記プロバイダ・サーバとの間で通信する管理アプリケーション・プログラミング・インターフェース（ＡＰＩ）をさらに含む、請求項７に記載のシステム。
9. 前記管理ＵＩと前記プロバイダ・サーバとの間の管理アプリケーション・プログラミング・インターフェース（ＡＰＩ）認証をさらに含む、請求項８に記載のシステム。
10. 複数の同意アクティブ化デバイスに関連する同意を管理するためのシステムであって、前記同意アクティブ化デバイスが、同意データをローカルに格納することができず、前記システムが、
    主体を作成するよう求める要求を受信するように構成されたベンダＡＰＩゲートウェイであって、前記要求がＡＰＩキーを含む、ベンダＡＰＩゲートウェイと、
    承認済みＡＰＩキー・データベースと、
    前記ベンダＡＰＩゲートウェイと通信し、前記ＡＰＩキー・データベース内を検索し、前記承認済みＡＰＩキー・データベース内で前記要求内の前記ＡＰＩキーが見つかった場合、一致するコンテキスト・オブジェクトを返すように構成された、オーソライザと、
    前記ベンダＡＰＩゲートウェイと通信し、スキーマ識別子（ＩＤ）を取得し、スキーマ・データベース内で前記スキーマＩＤを検索し、統合識別子（ＩＤ）及び組織識別子（ＩＤ）を返すように構成された、統合ＡＰＩと、
    主体識別子（ＩＤ）データベースと、
    前記ベンダＡＰＩゲートウェイ及び前記主体ＩＤデータベースと通信しているスキーマ・アプリケーション・プログラミング・インターフェース（ＡＰＩ）であって、前記スキーマＡＰＩが、前記スキーマＩＤ及び組織ＩＤを使用して主体ＩＤを作成し、前記主体ｉｄを前記主体ＩＤデータベースに適用するように構成される、スキーマＡＰＩと、
    主体データ・データベースと、
    前記ベンダＡＰＩゲートウェイ及び前記主体データ・データベースと通信している主体データ・アプリケーション・プログラミング・インターフェース（ＡＰＩ）であって、前記主体データＡＰＩが、前記主体データ・データベース内を検索し、主体を返すように構成される、主体データＡＰＩと
    を含む、システム。
11. 前記同意アクティブ化デバイスがコネクテッド・テレビ（ＣＴＶ）デバイスである、請求項１０に記載のシステム。
12. 前記同意アクティブ化デバイスがオーバ・ザ・トップ（ＯＴＴ）デバイスである、請求項１０に記載のシステム。
13. 前記主体ＡＰＩと通信し、請求メッセージを生成するように構成された、メッセージング・キューと、前記請求メッセージを受信し、前記同意アクティブ化デバイスへの請求イベントを生成するように構成された請求イベント送信機能とをさらに含む、請求項１０に記載のシステム。
14. 前記主体データ・データベース及びトランザクション・データベースと通信するトランザクション・データ格納サービスをさらに含み、前記トランザクション・データ格納サービスが、前記システム内の各トランザクションの記録を前記トランザクション・データベースに格納するように構成される、請求項１０に記載のシステム。
15. 前記主体データ・データベースと通信してステータス又は更新を前記システムからリアルタイムで送信するウェブフック送信サービスをさらに含む、請求項１０に記載のシステム。