(57)【要約】  プライバシー管理のための方法、システム、および装置は、加入者データおよび加入者データに関連する加入者同意ルールのデータベースを維持するステップと、選択された加入者データの同意要求を受信するステップと、ユーザ・タイプ基準に基づいて、選択された加入者データに関連する同意ルールを決定するステップと、同意ルールが満たされる場合、選択された加入者データに関連するパラメータを送信するステップとを含む。
2015503145.tif 000002
【特許請求の範囲】
【請求項１】
デジタル・データ記憶装置に通信できるように結合されたプロセッサで、加入者データおよび前記加入者データに関連する加入者同意ルールのデータベースを維持するステップと
前記プロセッサに通信できるように結合されたアプリケーション・プログラミング・インターフェースを介して、選択された加入者データの同意要求を受信するステップと、
前記デジタル・データ記憶装置と協力する前記プロセッサによって、ユーザ・タイプ基準、前記同意要求に関連する１つまたは複数の現在の状況、および前記選択された加入者データの１つまたは複数の以前の同意要求に基づいて、前記選択された加入者データに関連する同意ルールを決定するステップと、
前記同意ルールが満たされる場合、前記デジタル・データ記憶装置と協力する前記プロセッサによって、前記選択された加入者データに関連するパラメータを送信するステップと
を含む方法。
【請求項２】
前記選択された加入者データに関連する複数の同意ルールを決定するステップと、
前記複数の同意ルールのそれぞれが満たされる場合、前記選択された加入者データに関連するパラメータを送信するステップと
をさらに含む請求項１に記載の方法。
【請求項３】
前記ユーザ・タイプ基準は、要求するエンティティまたは対象となるエンティティの属性情報または場所に基づく請求項１に記載の方法。
【請求項４】
要求するエンティティまたは対象となるエンティティの属性情報に基づいて、前記同意要求に関連する階層レベルを決定するステップをさらに含む請求項１に記載の方法。
【請求項５】
前記階層レベルに基づいて同意ルールの加入者管理アクセスを許容するステップをさらに含む請求項４に記載の方法。
【請求項６】
前記階層レベルに基づいて前記選択された加入者データのアクセス・レベルを決定するステップをさらに含む請求項４に記載の方法。
【請求項７】
前記同意ルールは、アプリケーション、グループ、時間、または頻度ベースの基準のうちの少なくとも１つに基づく請求項１に記載の方法。
【請求項８】
前記同意ルールは、加入者オプトイン応答によって満たされる請求項１に記載の方法。
【請求項９】
選択された加入者データの同意要求を受信するように構成されたアプリケーション・プログラミング・インターフェースと、
加入者データおよび前記加入者データに関連する加入者同意ルールのデータベースを維持し、
ユーザ・タイプ基準、前記同意要求に関連する１つまたは複数の現在の状況、および前記選択された加入者データの１つまたは複数の以前の同意要求に基づき、前記選択された加入者データに関連する同意ルールを決定し、
前記同意ルールが満たされる場合、前記選択された加入者データに関連するパラメータを送信する
ように構成されたプロセッサと
を備えるプライバシー管理装置。
【請求項１０】
命令を格納した非一時的コンピュータ可読媒体を含む製品であって、前記命令が、コンピューティング・デバイスによる実行に応じて、前記コンピューティング・デバイスに、
デジタル・データ記憶装置に通信できるように結合されたプロセッサで、加入者データおよび前記加入者データに関連する加入者同意ルールのデータベースを維持するステップと、
前記プロセッサに通信できるように結合されたアプリケーション・プログラミング・インターフェースを介して、選択された加入者データの同意要求を受信するステップと、
前記デジタル・データ記憶装置と協力する前記プロセッサによって、ユーザ・タイプ基準、前記同意要求に関連する１つまたは複数の現在の状況、および前記選択された加入者データの１つまたは複数の以前の同意要求に基づいて、前記選択された加入者データに関連する同意ルールを決定するステップと、
前記同意ルールが満たされる場合、前記デジタル・データ記憶装置と協力する前記プロセッサによって、前記選択された加入者データに関連するパラメータを送信するステップと
を含む動作を実行させる、製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、電気通信サービス・プロバイダによって維持される加入者データのプライバシー管理に関する。
【背景技術】
【０００２】
電気通信サービス・プロバイダは、現在、長距離および通話料無料の通話サービスなど、従来のモデルを越えたそのネットワーク資産の収益化を可能にするソリューションを探している。たとえば、サービス・プロバイダは、加入者について保有している莫大な量のデータをサードパーティーにとって価値のある「文脈」情報へと変えることができる。しかし、この加入者データは、多くの場合、サードパーティーにとって容易にアクセス可能ではなく、また、通常、効率的かつ安全な方式で公開されていない。しばしば、プライバシー管理は、セキュリティ確保が希望されるデータの手動による遮断を含む複数ステップのプロセスを必要とする。プライバシー管理は、また、通常、サービス・プロバイダからではなく、様々な企業アプリケーションから発生するデータを保護することに合わせて調整されている。したがって、多くの場合、プライバシー管理の異なる方法間には相関性はなく、サービス・プロバイダと企業との間で交換されるデータに対する監査追跡能力はない。
【発明の概要】
【課題を解決するための手段】
【０００３】
本開示は、加入者データのプライバシー管理に関する。一実施形態では、加入者データおよび加入者データに関連する加入者同意ルールのデータベースが維持される。選択された加入者データの同意要求が受信される。選択された加入者データに関連する同意ルールが決定され、同意ルールは、ユーザ・タイプ基準に基づいて決定される。同意ルールが満たされる場合、選択された加入者データに関連するパラメータが送信される。同意要求は、企業アプリケーション、ウェブベースのアプリケーション、またはモバイル・アプリケーションのうちの１つから受信することができる。
【０００４】
一実施形態によると、ユーザ・タイプ基準は、要求するエンティティもしくは対象となるエンティティの属性情報、または要求するエンティティもしくは対象となるエンティティの場所に基づいてもよい。
【０００５】
一実施形態によると、同意ルールは、アプリケーション、グループ、時間、または頻度ベースの基準のうちの少なくとも１つに基づいてもよく、同意要求に対して概して施行可能でもよく、または同意要求の特定の動作に対して施行可能でもよい。同意ルールは、また、加入者オプトイン応答によって満たすことができる。
【０００６】
上記の方法、装置、およびコンピュータ可読命令のいずれかの一部の実施形態は、選択された加入者データに関連する複数の同意ルールを決定するステップと、複数の同意ルールのそれぞれが満たされる場合、選択された加入者データを送信するステップとをさらに含む。
【０００７】
上記の方法、装置、およびコンピュータ可読命令のいずれかの一部の実施形態は、同意要求に関連する階層レベルを決定するステップをさらに含む。階層レベルは、要求するエンティティまたは対象となるエンティティの属性情報に基づいてもよい。同意ルールに対する加入者管理アクセスは、階層レベルに基づいてもよく、選択された加入者データに対するアクセス・レベルを決定することは、階層レベルに基づいてもよい。
【０００８】
これらおよび他の利点は、以下の詳細な説明および添付図面を参照することによって、当業者に明白になろう。
【図面の簡単な説明】
【０００９】
【図１】一実施形態によるプライバシー管理システムの機能概要を示す図である。
【図２】一実施形態によるプライバシー・マネージャを示す機能図である。
【図３】一実施形態によるプライバシー・マネージャによって実行される階層化プライバシー同意評価を示す図である。
【図４】一実施形態によるプライバシー・ルールに対する競合解消図である。
【図５】一実施形態によるハイレベルの同意要求を示す流れ図である。
【図６Ａ−１】一実施形態によるプライバシー・マネージャによって実施される同意要求を示す流れ図である。
【図６Ａ−２】一実施形態によるプライバシー・マネージャによって実施される同意要求を示す流れ図である。
【図６Ｂ−１】図６Ａの同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図６Ｂ−２】図６Ａの同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図６Ｂ−３】図６Ａの同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図６Ｂ−４】図６Ａの同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図６Ｂ−５】図６Ａの同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図７Ａ−１】一実施形態によるプライバシー・マネージャによって実施されたコールバックを用いる同意要求を示す流れ図である。
【図７Ａ−２】一実施形態によるプライバシー・マネージャによって実施されたコールバックを用いる同意要求を示す流れ図である。
【図７Ｂ−１】図７Ａのコールバックを用いる同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図７Ｂ−２】図７Ａのコールバックを用いる同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図７Ｂ−３】図７Ａのコールバックを用いる同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図８Ａ】一実施形態によるプライバシー・マネージャによって実施されるキャンセル同意要求を示す流れ図である。
【図８Ｂ】図８Ａのキャンセル同意要求を示す流れ図の各パラメータのステータスを示す表である。
【図９】加入者文脈一式を実施するために使用できる例示的なコンピュータのハイレベル・ブロック図である。
【発明を実施するための形態】
【００１０】
様々な実施形態において、プライバシー・マネージャは、電気通信サービス・プロバイダがサードパーティーに安全に加入者データを公開することを可能にする。プライバシー・マネージャは、使用されているアプリケーション、要求するエンティティの属性情報（たとえばアプリケーションを使用する加入者、アプリケーション自体など）、および要求するエンティティが他のユーザ、企業、およびアプリケーションと持っている関係など、基準に基づいて様々なプライバシー・ポリシーを管理および適用するためにサービス・プロバイダにフレームワークを提供する。
【００１１】
図１は、一実施形態によるプライバシー管理システムの機能概要を示す図である。システム１００は、プライバシー同意、プライバシー同意管理、およびプライバシー・イベント通知の機能を提供するために、サービス・プロバイダ・データベース１０４に格納された加入者データ１０３を取得および更新するように構成されたプライバシー・マネージャ１０２を含む。たとえば、プライバシー・マネージャ１０２は、サービス・プロバイダ・データベース１０４に通信できるように結合されたプロセッサによって実施することができ、サービス・プロバイダ・データベース１０４は、デジタル・データ記憶装置である。プライバシー・マネージャ１０２が加入者データ１０３を取得するために、サードパーティー・プラットフォーム１０６（たとえば企業、モバイル、またはウェブベースのアプリケーション）から同意要求／クエリ１０５を受信すると、プライバシー・マネージャ１０２は、加入者同意ルールおよび同意管理応答１０７に従って（たとえば加入者オプトイン応答）、サードパーティーに公開するためにサービス・プロバイダ・データベース１０４から要求された加入者データ１０３を取得することができる。加入者同意ルールおよび同意管理応答１０７は、ユーザ機器（ＵＥ）デバイスまたは他の入力端末など、加入者ポータル１０８を介して、加入者（すなわち、ユーザ）からプライバシー・マネージャ１０２で受信することができる。下にさらに詳細に説明するように、次に、プライバシー・マネージャ１０２は、加入者同意ルールおよび同意管理応答１０７を同意要求／クエリ１０５に適用するために、オンボーディング（アプリケーション／開発者管理）ポータル１１０を介して供給されるものなど、様々なアプリケーション１０９を実行することができる。一部の例では、プライバシー・マネージャ１０２は、キャッシュ・メモリ１１２を介してリアルタイム承認１１１に対して、持続的な同意要求１０５に関係するものなど、受信された加入者同意ルールおよび管理応答１０７を格納することができる。プライバシー・マネージャ１０２は、また、ネットワーク・ポータル１１４を介してアクセス可能なネットワーク管理システムで、同意要求／クエリ・メッセージ・イベント他レコード１１３（たとえば測定基準または監査追跡レコード）を記録することができる。
【００１２】
図２は、一実施形態によるプライバシー・マネージャを示す機能図である。一実施形態では、プライバシー・マネージャ１０２は、様々なインターフェース（たとえばアプリケーション・プログラミング・インターフェースすなわちＡＰＩ）の間でプライバシー・マネージャ１０２へのアクセスを制御する、アクセス管理要素２０２、および電気通信サービス・プロバイダによって典型的に維持される加入者データなど、加入者データへのアクセスを取得および制御するために使用される、プライバシー同意コールフロー２０６（すなわち通信、また本明細書において「同意フロー」とも呼ぶ）を実行、生成、受信、および管理するための処理フレームワークを提供する同意ルール・エンジン２０４を含む。したがって、プライバシー・マネージャ１０２の処理フレームワークは、同意フローの経過の間に１つまたは複数のＡＰＩおよびデジタル・データ記憶装置と協力して、プライバシー・マネージャ１０２によって実行できる機能を通じて理解することができる。
【００１３】
プライバシー・マネージャ１０２は、同意フローの間に使用するために、加入者同意データベース２１０（またはキャッシュ・メモリ１１２）に、１つまたは複数の加入者ポータル１０８または他の外部加入者文脈データ・ソース２０８から受信された加入者同意データを格納する。具体的には、同意ルール・エンジン２０４は、要求するエンティティが選択された加入者データにアクセスすることを可能にするためにルールを決定するために加入者同意データベース２１０にアクセスする。
【００１４】
図１に示すサービス・プロバイダ・データベースを含むことができる、共有されたプライバシー文脈データベース１０４は、同意フローに対するアプリケーション文脈データ、同意フロー実行に関係する同意ルール文脈データ、および同意フローの測定の持続的な格納のために構成される。一実施形態では、アプリケーション文脈データ管理要素２１２は、適切なオンボーディング・ポータル１１０へのインターフェース・リンクを介して、同意要求に関係するアプリケーション文脈データを収集し、プライバシー・ルールおよびポリシーを決定および施行する際に使用するため、ならびに一般的なアプリケーション公開プラットフォーム２２０を通じて持続的なデータ記憶をサポートするために使用できる集中型のデータ・レポジトリを作成するために、共有されたプライバシー文脈データベース１０４に文脈データを格納する。図２は、スタンド・アロンのプラットフォームとして実施されたプライバシー・マネージャ１０２を示しているが、他の実施形態では、プライバシー・マネージャ１０２の機能の１つまたは複数は、一般的なアプリケーション公開プラットフォーム２２０に統合したり、またはプラットフォーム内に実装したりできることは当業者なら気付くであろう。
【００１５】
同意フロー２０６は、展開およびリアルタイムの管理要件に依存して、プライバシー・マネージャ１０２によって個々に、またはまとめて管理することができる。たとえば、特定の同意フロー２０６は、まとめるのに有利な可能性がある共通のプロセスを含むことができる。これらのプロセスはＡＰＩを使用して公開し、タスクをまとめてエンド・ユーザ対話を管理するために適切なコンポーネントとインターフェースをとるために、アクセス管理要素２０２を介して管理することができる。たとえば、アクセス管理要素２０２は、フローの実際の展開およびプライバシー・マネージャ１０２の他のサービスおよびＡＰＩへの接続を制御することができる。
【００１６】
概して、プライバシー・マネージャ１０２は、様々な既知のプロトコルを使用して、外部および内部のインターフェースをサポートするように構成することができる。たとえば、プライバシー・マネージャ１０２は、リアルタイム同意要求、アプリケーション提供、加入者同意管理、加入者データ取得、およびＳＭＳ通知を含む、本明細書に記述した機能のいずれかを実行するために、ＡＰＩとインターフェースをとることができる。アクセス管理要素２０２は、同意フロー・インターフェースを含む、プライバシー・マネージャ１０２によってサポートされたインターフェースに認証および認可の制御を提供することができる。一実施形態では、アクセス管理要素２０２は、同意フローによって公開されるＡＰＩに対してセキュリティおよびアクセス制御を提供する。たとえば、プライバシー・マネージャ１０２は、ＡＰＩ（場所）およびリクエスタ（ソーシャル・ネットワーク・アプリケーション）に基づいて、対象となる加入者に対してどのようなレベルの情報を取得できるか（たとえば場所データ）を決定することができる。たとえば、ソーシャル・ネットワーク・アプリケーションは、低レベルの精度データ（たとえば郵便番号レベル）に対してのみ認可することができる一方、緊急応答アプリケーションは、高レベルの精度データを受信することができる（たとえばアドレスまたはグローバル測位による場所）。一実施形態では、所与のユーザがアクセス管理要素２０２にアクセスするか、または構成する権限を持っているかどうかを決定するために、様々なルールおよび権限を使用することができる。
【００１７】
プライバシー・マネージャ１０２は、ＳＭＳ２１４（ＳＭＳメッセージを送信および受信する許容フロー）、加入者データ（加入者のプライバシー同意データを問い合わせる許容フロー）、場所（加入者の場所を取得する許容フロー）、アプリケーション文脈データ（関連するアプリケーションの文脈データにアクセスする許容フロー）、および他の機能２１６について、同意フローの間に動作可能な様々な許可機能をさらに含む。たとえば、同意ルール・エンジン２０４は、リアルタイム同意フローの間になど、加入者（または他のエンティティ）に、オプトイン要求または確認メッセージを送信するためにＳＭＳ許可機能２１４をアクティブ化することができる。たとえば、オプトイン要求が正しく処理されたことを確認するＳＭＳメッセージを加入者に送信することも、または新しいアプリケーションが、それらのデータにアクセスを試みていることを加入者に通知するために、加入通知メッセージ送信することもできる。別の実施例では、同意ルール・エンジン２０４は、加入者同意データベース２１０、または別の外部ソース２０８で適切な加入者同意データをルックアップするために、加入者承認ルックアップ・フローの加入者データ許可機能２１８をアクティブ化することができる。
【００１８】
一実施形態では、加入者ポータル１０８は、加入者および／または管理者が加入者同意データを管理することを可能にする加入者レベル同意管理要素２２２を含む。たとえば、加入者ポータル同意管理要素２２２は、加入者同意データを追加、更新、閲覧、および削除するために構成することができる。管理要素２２２は、また、ローカル加入者ポリシー・データベース２２４に加入者同意データを格納することができる。一実施形態では、データベース２２４は、異なるレベルの加入者管理および同意データ制御をサポートすることができる。たとえば、親加入者は、子加入者の同意データを制御することができる。他の管理レベルは、サービス・プロバイダ、企業、または他のエンティティに対して構成することができる。さらに、これらのレベルは、加入者同意データの管理だけでなく、ＡＰＩで適用される同意ポリシーに使用することができる。
【００１９】
加えて、同意フロー管理要素２２６は、サービス・プロバイダ（または信頼されたサービス・プロバイダのパートナー）が同意フロー２０６を管理することを可能にすることができる。一実施形態では、同意フロー管理要素２２６は、同意フローのライフサイクル、同意フローのロードおよびアンロード、同意フローのアクティブ化および非アクティブ化、同意フローのステータスの閲覧、フローの提供、新しいフローのアップロード、およびフローのインストール解除を管理および制御する。
【００２０】
同意ルールは、アプリケーション、リクエスタ、グループベース、日付／時間ベース、および頻度ベースの基準の任意の組合せに基づいてもよい。同意ルールは、また、同意フローの間にプライバシー・マネージャ１０２によって受信された場所ベースのアプリケーションによって提供される情報など、場所情報（たとえば分解能および精度）に基づいて調整可能でもよい。
【００２１】
フロー・ポリシーは、同意フロー２０６の制御および最適化を可能にするルールである。一実施形態では、これらのポリシーは、加入者同意（たとえば、同意リスト）、アプリケーション・アクセス、ＳＬＡおよび割り当て（アプリケーションまたは加入者が所与の加入者情報にアクセスしようとしている回数）、特定のアプリケーションまたは加入者によるアクセスの試みの日付および時刻、ならびに加入者情報にアクセスしようとするアプリケーションまたは加入者の場所を含むことができる。
【００２２】
ポリシー／ルールの施行は、同意フローの実行の間に、同意ルール・エンジン２０４によって実行されたプライバシー・ルール／ポリシーのランタイム評価および処理を示す。一実施形態では、ポリシーの変更に対処する際の複雑さを減らすために、ポリシーの施行は、実際のルール／ポリシーの定義および展開プロセスから切り離される。ルール・エンジン２０４は、現在の状況に関して同意フローの実行に関連するルール／ポリシーを評価および施行する（たとえば、同意フローを実行するアプリケーション、アプリケーションを実行する加入者、要求を実行するために使用されるリソースなど）。たとえば、加入者ポータル１０８は、ルール・エンジン２０４に同意ルールをプッシュする一方、加入者ポータル１０８は、フローのポリシー・テンプレートおよびアプリケーション属性情報の関連を構成／管理する。
【００２３】
様々なルール・タイプを構成し、次いでランタイムに施行することができる。一実施形態では、ルール・タイプは、概して、同意フローまたは同意フロー内の選択された（または単一の）動作に対して適用することができる。たとえば、カスタムの同意フロー・ルールは、同意フローの開発者がロジック内でルールを使用することを可能にするために使用することができ、ロジックを変更する必要なく、フローの振る舞いを動的に変更することが可能になる。
【００２４】
一実施形態では、同意ルール・エンジン２０４は、アカウントまたはアプリケーション・レベルの階層など、ユーザ・タイプ基準によりプライバシー・ポリシーおよびルールを（たとえば識別子を通じて）割り当てて適用する。たとえば、アカウント階層レベルは、サービス・プロバイダ（すなわちキャリア）、企業（たとえば複数のアカウントを持つ企業エンティティ）、アカウント保持者（たとえば一家族において複数のアカウントを持つ親）、および個々の加入者レベルを含むことができる。１つの階層レベル（たとえばサービス・プロバイダ・レベル）に適用されるルールは、別の階層レベルに、異なるように適用することも、または適用しないこともできる。たとえば、サービス・プロバイダ・レベル・ポリシーは、他のすべてのポリシーを無効にするように構成することができ、アカウント保持者ポリシーは、加入者レベル・ポリシーを無効することができ、サードパーティー・ポリシーは、アグリゲータ・ポリシーを無効にすることができるなどである。さらに、より高いアカウント・レベル（たとえばサービス・プロバイダ・レベル）は、より低いアカウント・レベル（たとえば個々の加入者レベル）に対して公開または管理のアクセス制御を持つことができる。同様に、アプリケーション・レベルは、アプリケーション、サードパーティー、およびアグリゲータの階層を含むことができる。
【００２５】
一実施形態では、ルールは、２組のレベルで評価することができる。リクエスタ・レベルでは、ルールは、対象についての情報を要求しているエンティティに基づいて評価される。たとえば、リクエスタ・レベル階層は、アプリケーション、リクエスタ（加入者）、およびグループ（たとえばアプリケーションまたはリクエスタが関連する企業またはアグリゲータ）のレベルを含むことができる。対象レベルでは、ルールは、その情報が要求されている加入者に基づいて評価される。たとえば、対象レベルは、サービス・プロバイダ、企業、およびアカウントのレベルを含むことができる。
【００２６】
図３は、一実施形態によるプライバシー・マネージャによって実行された階層化プライバシー同意評価を示す図である。同意要求／クエリ２０６が受信されると、ルール・エンジン２０４は、格納された同意ルール２１０および文脈（構成）データ１０４を層形式で同意要求に適用することができる。たとえば、評価の層は、グローバル・ポリシー３００（たとえばすべての同意要求に適用するルール／文脈データ）、サービス・プロバイダ・ポリシー３０２、パートナー・ポリシー３０４（安全な企業アプリケーションなど信頼されたパートナーによって適用されるルール／文脈データ）、アプリケーション・ポリシー３０６（特定のアプリケーションに適用可能）、キャンペーン・ポリシー３０８（選択期間または加入者に適用可能）、アカウント・ポリシー３１０（特定のアカウントに適用可能）、および加入者ポリシー３１２（加入者データおよびオプトインに基づく）を含むことができる。一実施形態では、属性値「ALLOWED」、「NOTALLOWED」、「BLOCKED」、「REQUIRED」および「GETCONSENT」は、同意ルールの競合解消状態を規定することができる。たとえば、属性の１つが「NOT ALLOWED」または「BLOCKED」であると決定された場合など、関係する層で評価が中断された場合、ルール・エンジン２０４は、たとえば「GlobalPolicyFailure」３１４などエラー・コードを返すことができる。
【００２７】
図４は、一実施形態による階層化プライバシー・ルールに対する競合解消図である。上記のように、属性値「ALLOWED」４０２、「NOTALLOWED」４０４、「BLOCKED」４０６、「REQUIRED」４０８および「GETCONSENT」４１０は、同意ルールの競合解消状態を規定することができる。一実施形態では、「NOTALLOWED」４０４または「BLOCKED」４０６の値を持つ属性がない場合のみ、次の層ルールを評価することができる。「ALLOWED」４０２の属性値は、次の層プライバシー・ルールによって、「NOT ALLOWED」４０４、「BLOCKED」４０６または「GETCONSENT」４１０に変更することができる。各層は複数のルールを持つことができ、様々なインスタンスにおいて、層ルールによって割り当てられた値が一貫しない可能性がある場合がある（たとえば、第１のルールが値「ALLOWED」４０２、第２が「NOTALLOWED」４０４、第３が「ALLOWED」４０２に再び設定されているなど）。したがって、競合は、許容された値の移行、または値の優先度を規定することによって解決することができる。たとえば、「ALLOWED」４０２から「NOTALLOWED」４０４の移行に対する新しい値は、「NOTALLOWED」４０４として規定することができる一方、「NOTALLOWED」４０４から「ALLOWED」４０２への移行は、新しい値を無視することができる（すなわち、属性は「NOTALLOWED」４０４のままである）。一実施形態では、ルールが実行されず、設定された値がない場合、値を持たないすべての属性は、「NOTALLOWED」４０４に設定することができる。
【００２８】
図５は、一実施形態によるハイレベルの同意要求フローを示している。一実施形態では、外部同意要求は、５０１で外部プライバシー同意サービスによって受信される。５０２で、同意要求２０６は、プライバシー・マネージャ１０２によって生成および受信される。５０３で、特定の加入者に関連するルールを含む加入者プロファイルは、加入者データベース許可機能２１８を介してデータベース１０４からフェッチされる。加入者プロファイルが存在する場合、ルールは、５０４ａで、ルール・エンジン２０４によって処理することができる。あるいは、５０４ｂでルールが加入者オプトインを必要とする場合、オプトイン要求は、加入者プライバシー管理フロー・マネージャ２２６に送信することができる。５０５で、プライバシー・マネージャ１０２は、オプトイン同意が認められたかどうかを示す応答パラメータを要求するエンティティに返信する。
【００２９】
図６Ａ（図６Ａ−１及び図６Ａ−２）は、一実施形態によるプライバシー・マネージャによって実施されたプライバシー同意要求を示している。同意要求２０６に含まれるパラメータ（たとえば、グローバル、サービス・プロバイダ、パートナー、キャンペーン、アカウント、および加入者レベルのパラメータ）は、各ポリシーに対して評価される。パラメータは、文脈データベース１０４に格納された各ポリシーに基づいて評価されるため、プライバシー・マネージャ１０２は、たとえば、「ALLOWED」、「NOTALLOWED」、「BLOCKED」または「REQUIRED」など、それらのステータス６００を考慮する。図６Ｂ（図６Ｂ−１乃至図６Ｂ−５）は、図６Ａの同意要求の各パラメータのステータスを示す表である。たとえば、すべてのポリシー（ステップ２〜１８）が合格した場合、加入者データからの要求された値を含む属性リストは、ステップ１９などでリクエスタに送信される、
【００３０】
図７Ａ（図７Ａ−１及び図７Ａ−２）は、一実施形態によるプライバシー・マネージャによって実施されたコールバックを用いるプライバシー同意要求を示している。同意要求２０６に含まれるパラメータは、各ポリシーに対して評価される。パラメータは各ポリシーに基づいて評価されるため、プライバシー・マネージャ１０２は、それらの「ALLOWED」、「NOTALLOWED」、「BLOCKED」、「REQUIRED」ステータス７００を考慮する。一実施形態では、同意要求２０６は、加入者オプトイン・プロセス７０２を必要とする１つまたは複数のパラメータを含むことができる。図７Ｂ（図７Ｂ−１乃至図７Ｂ−３）は、図７Ａの同意要求の各パラメータのステータスを示す表である。プロセス（ステップ２〜１８）の終わりに、パラメータがステップ１９でＮＯＲＵＬＥの値を持っている場合、それらのパラメータは、オプトイン・プロセス７０２が始まる「getPrivacyConsent」関数に渡される。オプトイン・プロセス７０２が完了したら、プロセスの最終結果を含む通知パラメータが要求するエンティティに送信される。オプトインが成功すると（たとえば、プライバシー・マネージャ１０２が加入者ポータル１０８を介して加入者オプトイン権限を受信する）、要求するエンティティは、ステップ２０でのように、それらの値を取得するために加入者パラメータへのアクセスの同意要求を再提出することができる。
【００３１】
図８Ａは、一実施形態によりプライバシー・マネージャによって実施されたキャンセル・プライバシー同意要求を示している。図８Ｂは、図８Ａのキャンセル同意要求の各パラメータのステータスを示す表である。障害（たとえば、加入者がオプトイン指示を返さない）は、単にエラー応答を持つ同意フローを終了するだけなので、メッセージング障害は、表に含まれていない。
【００３２】
上記の方法は、よく知られているコンピュータ・プロセッサ、メモリ・ユニット、記憶装置、コンピュータ・ソフトウェア、および他のコンポーネントを使用して、コンピュータにおいて実施することができる。そのようなコンピュータのハイレベル・ブロック図が図９に示されている。コンピュータ９００は、そのような動作を規定するコンピュータ・プログラム命令を実行することによってコンピュータ９００の全体的な動作を制御する、プロセッサ９１０を含む。コンピュータ・プログラム命令は、記憶デバイス９２０（たとえば磁気ディスク）に格納し、コンピュータ・プログラム命令の実行が望まれるときにメモリ９３０にロードすることができる。プロセッサで実行可能なコンピュータ・プログラム命令がプロセッサ９１０によって実施される場合、特定の論理回路に同様に動作する一意のデバイスを提供するために、コンピュータ・プログラム命令の１つまたは複数のプログラム・コード・セグメントは、プロセッサ９１０と組み合わせることができる。したがって、図５の方法のステップは、メモリ９３０および／または記憶装置９２０に格納され、コンピュータ・プログラム命令を実行するプロセッサ９１０によって制御されるコンピュータ・プログラム命令によって規定することができる。コンピュータ９００は、図５の方法のステップを実施するためにネットワークを介して他のデバイスと通信するために１つまたは複数のネットワーク・インターフェース９４０を含むことができる。コンピュータ９００は、また、コンピュータ９００とのユーザ対話を可能にする他の入力／出力デバイス９５０を含むことができる（たとえば、ディスプレイ、キーボード、マウス、スピーカ、ボタンなど）。実際のコンピュータの実装形態は、他のコンポーネントも同様に含むことができること、および図９は、説明を目的とする、そのようなコンピュータのコンポーネントの一部のハイレベル表現であることを当業者は認識するであろう。
【００３３】
前述の「発明を実施するための形態」は、あらゆる点において、制限するものではなく、説明し例示するものとして理解するべきであり、本明細書に開示された発明の範囲は、「発明を実施するための形態」からではなく、むしろ、特許法によって認められた全範囲により解釈されるように特許請求の範囲から決定されるべきである。本明細書に図示し記述した実施形態は、単に本発明の原理を説明するものにすぎず、当業者は、本発明の範囲および趣旨から逸脱することなく、様々な変更形態が実装可能であることを理解するであろう。当業者は、本発明の範囲および趣旨から逸脱することなく、様々な他の特徴の組合せを実装することができる。
【図１】
2015503145.tif 000003
【図２】
2015503145.tif 000004
【図３】
2015503145.tif 000005
【図４】
2015503145.tif 000006
【図５】
2015503145.tif 000007
【図６Ａ−１】
2015503145.tif 000008
【図６Ａ−２】
2015503145.tif 000009
【図６Ｂ−１】
2015503145.tif 000010
【図６Ｂ−２】
2015503145.tif 000011
【図６Ｂ−３】
2015503145.tif 000012
【図６Ｂ−４】
2015503145.tif 000013
【図６Ｂ−５】
2015503145.tif 000014
【図７Ａ−１】
2015503145.tif 000015
【図７Ａ−２】
2015503145.tif 000016
【図７Ｂ−１】
2015503145.tif 000017
【図７Ｂ−２】
2015503145.tif 000018
【図７Ｂ−３】
2015503145.tif 000019
【図８Ａ】
2015503145.tif 000020
【図８Ｂ】
2015503145.tif 000021
【図９】
2015503145.tif 000022
【国際調査報告】
2015503145.tif 000023
2015503145.tif 000024