JP2013508831A - コンピュータネットワーク内の保護リソースへのアクセスを管理するための方法と、そのための物理エンティティおよびコンピュータプログラム - Google Patents

Abstract

コントローラによって行われる方法を開示する。方法は、要求トークンを含むメッセージを受信すること（ｓ１０）を含む。要求トークンは、サービスプロバイダ（４００）からの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマ（３００）によって用いられる値である。サービスプロバイダ（４００）は、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマ（３００）は、ユーザの代わりにサービスプロバイダ（４００）にアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。方法は、さらに、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定すること（ｓ２０）と、メッセージがポリシー設定に適合していないと判定された（ｓ３０）場合には、要求トークンが要求トークンに関連するサービスプロバイダ（４００）へ転送されるのを阻止すること（ｓ３４）とを含む。

Description

本発明は、コンピュータまたは通信ネットワーク内の保護リソースへのアクセスの管理と、そのようなリソースの利用とに関する。特に、本発明は、そのようなアクセス管理を行うために物理エンティティによって行われる方法と、そのために構成された物理エンティティとに関する。また、本発明は、コンピュータ上で実行される場合に、コンピュータに上記の方法を行わせるように構成された命令を含むコンピュータプログラムにも関する。本発明は、特に、コンピュータネットワーク内のユーザに関連するリソースを用いるウェブサービスの文脈で適用されうるものであり、ここで、リソースは、２つ以上のウェブアプリケーションまたはウェブサイト上に分散されている。

コンピュータまたは通信ネットワークにおいて、多様なウェブサイトまたはウェブアプリケーションが、ユーザの利益のために多様なサービスを提供することがある。例えば、１つのウェブサイトまたはウェブアプリケーションが、ユーザの電子メールアカウントを管理してもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザのソーシャルネットワークのメンバと写真を共有するための写真のストレージを可能にしてもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザの書店アカウントを管理する書店として動作してもよい。別のウェブサイトまたはウェブアプリケーションが、画像および写真の印刷を提供し、それらをユーザに配達してもよい。可能性は無限にある。

けれども、ウェブサイトおよびウェブアプリケーションが、「他のサイトからの機能性も一緒に結合する」新しいサービスを提供したいと望むこともある（Ｅｒａｎ Ｈａｍｍｅｒ−Ｌａｈａｖ、“Ｅｘｐｌａｉｎｉｎｇ ＯＡｕｔｈ”、２００７年９月５日、ｈｔｔｐ：／／ｈｕｅｎｉｖｅｒｓｅ．ｃｏｍ／２００７／０９／ｅｘｐｌａｉｎｉｎｇ−ｏａｕｔｈ／−２００９年９月１５日検索、本書では参考資料［１］と呼ぶ）。例えば、（例示的なウェブサイト「ｐｒｉｎｔｅｒ．ｃｏｎｓｕｍｅｒ．ｃｏｍ」のような）デジタルフォトラボ印刷ウェブアプリケーションが、ユーザがそこのアカウントを有する（例示的なサイト「ｐｈｏｔｏｓ．ｃｏｎｔａｉｎｅｒ．ｃｏｍ」のような）デジタル画像ホスティングウェブサイトの中に記憶されている写真を、これらの写真を印刷してユーザに配達することを目的として、ユーザの代わりに、検索したいと望むことがある。

多様なウェブサイトおよびウェブアプリケーションからの保護リソースを統合するウェブサービスを実装することを目的として、本書では「コンシューマ」と呼ぶ第１のウェブサイトまたはウェブアプリケーションが、本書では「サービスプロバイダ」と呼ぶ（コンシューマもサービスを提供するのだが）第２のウェブサイトまたはウェブアプリケーションにアクセスするために、ユーザの認証情報を提供するようユーザに求めることがある。上記の例では、コンシューマはデジタルフォトラボ印刷ウェブアプリケーションであり、サービスプロバイダはデジタル画像ホスティングウェブサイトであり、保護リソースはユーザの個人的写真であろう。言い換えると、コンシューマがサービスプロバイダにアクセスするために、ユーザのユーザ名とパスワードとを提供するようユーザに求めることがある。しかし、これによって、ユーザのパスワードが秘密でなくなり、誰か他の人が、サービスプロバイダの中で、ユーザのアカウントに関連する任意の動作のためにそのパスワードを使用することが可能になる（例えば「あなたのパスワードを変更してあなたを締め出すことすら」、参考文献［１］のセクション「ｗｈａｔ ｉｓ ｉｔ Ｆｏｒ（それは何のためか）」）。

この問題を解決するため、ＯＡｕｔｈプロトコルが開発された（Ａｔｗｏｏｄ，Ｍ．他“ＯＡｕｔｈ Ｃｏｒｅ １．０ Ｒｅｖｉｓｉｏｎ Ａ”、２００９年６月２４日、ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｃｏｒｅ／１．０ａ−２００９年９月１５日検索、本書では参考文献［２］と呼ぶ）。ＯＡｕｔｈプロトコルは、ウェブサイトまたはウェブアプリケーションすなわちコンシューマが、ユーザのサービスプロバイダ認証情報をユーザがコンシューマに開示することを必要とせず（参考文献［２］、Ａｂｓｔｒａｃｔ）、別のウェブサイトまたはウェブアプリケーションすなわちサービスプロバイダからの保護リソースにアクセスすることを可能にする。ＯＡｕｔｈプロトコルは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）のアクセス委譲プロトコルとみなされてもよい。参考文献［１］のセクション「ｗｈａｔ ｉｓ ｉｔ Ｆｏｒ（それは何のためか）」で説明された従者の鍵のたとえは、ＯＡｕｔｈプロトコルの目的を直感的に理解するのに役立ちうる。

ＯＡｕｔｈプロトコルでは、認証、すなわち「ユーザが、ユーザの認証情報をコンシューマと共有することなく、ユーザの保護リソースへのアクセスを認めるプロセス」（参考文献［２］、「６．Ａｕｔｈｅｎｔｉｃａｔｉｎｇ ｗｉｔｈ ＯＡｕｔｈ（ＯＡｕｔｈを使った認証）」）は、以下のように機能する。

コンシューマが、未許可の要求トークンをサービスプロバイダから入手する。コンシューマは、サービスプロバイダのユーザ許可ＵＲＬ（「ＵＲＬ」は「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」のこと）を用いてユーザのウェブブラウザを介してユーザをサービスプロバイダへと向ける。次いでユーザは、サービスプロバイダを使って自分自身を認証する。言い換えると、ユーザは、サービスプロバイダのウェブサイトにサイン・インする。ユーザは、決して自分のサービスプロバイダ認証情報をコンシューマに提供するのではない。

次いでサービスプロバイダは、コンシューマが保護リソースへのアクセスを認められるようになることについてユーザが同意するかどうかを、ユーザに尋ねる。そうするため、サービスプロバイダは、コンシューマがアクセスすることを望む保護リソースについての情報を、ユーザに提示する。情報は、要求されたアクセスの持続時間とアクセスのタイプとを含んでいる（例えば、保護リソースをコピーする、修正する、削除する）。情報は、例えば、「このウェブサイト＜ｃｏｎｓｕｍｅｒ−ｎａｍｅ＞は、これから１時間の間、あなたの個人的な写真へのアクセスを要求しています。そのようなアクセスを承認しますか？」というような例示的なメッセージと共に、サービスプロバイダのウェブサイトのウェブページ上に提示されてもよい。次いでユーザは、ユーザの代理としての想定されるアクセスをコンシューマに与えるための、サービスプロバイダについての許可を、認めるかまたは拒否する。

ユーザが同意した場合、要求トークンは許可され、ユーザはコンシューマへ戻るように導かれ、その結果、コンシューマは、要求トークンが許可されたことを通知される。次いで、許可された要求トークンはアクセストークンと交換され、コンシューマはユーザに代わって保護リソースにアクセスすることができる。ユーザが許可を拒否した場合、コンシューマは、要求トークンが無効化されたことを通知される。

ＯＡｕｔｈプロトコルを用いた認証プロセスの一例が、Ｅｒａｎ Ｈａｍｍｅｒ−Ｌａｈａｖ、“Ｂｅｇｉｎｎｅｒ’ｓ Ｇｕｉｄｅ ｔｏ ＯＡｕｔｈ−Ｐａｒｔ ＩＩ；Ｐｒｏｔｏｃｏｌ Ｗｏｒｋｆｌｏｗ”、２００７年１０月１５日、ｈｔｔｐ：／／ｈｕｅｎｉｖｅｒｓｅ．ｃｏｍ／２００７／１０／ｂｅｇｉｎｎｅｒｓ−ｇｕｉｄｅ−ｔｏ−ｏａｕｔｈ−ｐａｒｔ−ｉｉ−ｐｒｏｔｏｃｏｌ−ｗｏｒｋｆｌｏｗ／−２００９年９月１５日検索、に提示されている。

ユーザにかかる操作上の負荷を軽減する必要性を念頭に置けば、本書ではコンシューマと呼ぶウェブサイトまたはウェブアプリケーションが、本書ではサービスプロバイダと呼ぶ他のウェブサイトまたはウェブアプリケーション上にあるユーザに関連する保護リソースに対してユーザに代わって行うアクセスを管理するための方法、物理エンティティおよびコンピュータプログラムを改善することが望ましい。

これらの目的に合致または少なくとも部分的に合致するため、独立請求項において方法、コントローラ、およびコンピュータプログラムが定義される。有利な諸実施形態が、従属請求項において定義される。

一実施形態では、コントローラによって行われる方法を提供する。方法は、要求トークンを含むメッセージを受信するステップを含む。要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。方法は、さらに、メッセージが、保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップと、メッセージがポリシー設定に適合していないと判定された場合には、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するステップとを含む。

コントローラは物理エンティティであって、コントローラの機能を実行するためにコンピュータプログラムもしくはハードウェア回路部を含んでいてもよい。コントローラは、例えば、サーバコンピュータまたはユーザ端末と一体化されていてもよい。コントローラは、要求トークンを含むメッセージを受信し、次いで、メッセージがポリシー設定に適合しているかどうかチェックするように構成される。メッセージがポリシー設定に適合していない場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。結果として、ユーザは、サービスプロバイダの許可ページに、不必要に導かれることはない。この許可ページでは、ここへユーザが導かれた場合には、ユーザは、サービスプロバイダからアクセスできる保護リソースへのアクセスを認めるか拒否するかを決めるように求められることになる。

保護リソースへのアクセスを管理するポリシー設定すなわちポリシー規則は、メッセージがポリシー設定に適合していない場合に保護リソースへのアクセスを拒否するコントローラが行使するように、事前に確立されている。メッセージがポリシー設定に適合していない場合、メッセージが受信された時点でユーザが介入することを必要とせず、コントローラによってアクセス拒否が実施される。

言い換えると、コントローラが要求トークンも含めてメッセージをインターセプトし、メッセージに関連する許可要求およびその要求トークンのタイプに応じて、コントローラが、認証および許可プロセスを中断するかどうか決定する。コントローラは、要求トークンが転送されるのを阻止し、従って、要求トークンが許可されていた場合に発生する可能性があったことに関してメッセージから抽出または収集された情報に基づいて、認証および許可プロセスを中断する。

これによってユーザは、メッセージが受信された時点で、場合によっては、すなわち、メッセージがポリシー設定に適合していないとコントローラが判定した場合には、サービスプロバイダと対話しなければならないことから解放される。

ゆえに、方法は、特に、ユーザにかかる操作上の負荷を軽減することによって、コンピュータまたは通信ネットワークにおけるプライバシ管理を改善し、円滑化する。ユーザの観点から見たプライバシ管理とは、サービスプロバイダ上に記憶されるかサービスプロバイダによって提供されるかまたはサービスプロバイダからアクセスできてかつユーザに関連するどの保護リソースに、所与のコンシューマがアクセスできるのかできないのか、そしてそれはどのようにして行われるのかを、ユーザが、またはユーザの利益のために、制御することに存するタスクである。また、プライバシ管理には、例えば、ユーザの保護リソースに関連して行われうる操作に関して、ユーザの選好に合わせたかたちでの、ユーザの保護リソースの適切な処理が含まれる。

また、ユーザにかかる操作上の負荷を軽減すること以外にも、本実施形態は、一部の保護リソースへのアクセスをユーザがうっかり認めてしまうことを含みうる人為的なミスのリスクを削減する。

メッセージとは、情報の単位であって、通信チャネル経由またはネットワーク経由で送信されることができ、かつ、要求トークンと、もしあれば関連のパラメータとを搬送しうるものである。また、メッセージは、要求と呼ばれることもある。

ユーザとは、そのＩＤが認証されうる人間または人間のグループであるかまたは、そのＩＤが認証されうる物理エンティティ、例えばユーザ端末もしくはユーザ装置である。言い換えると、本書で「ユーザ」という用語が用いられる場合、それは、実際のエンドユーザ、すなわち人間または人間のグループと、ＩＤが与えられうるユーザ端末またはユーザ装置とのうちのいずれか一方あるいは両方を指してもよい。さらに、ユーザ端末が、（例えば異なるユーザプロフィールに関連して）複数のＩＤを用いて動作することができる場合、ユーザ端末がその下で動作しうる各ＩＤは、本発明の文脈では１人のユーザに対応してもよい。

それゆえ、本書では「ユーザ」という用語は、適切な場合には、ユーザ装置またはユーザ端末をも包含する。例えば、認証に関して、ユーザ装置は、人間の介在がなくても認証手順を行うように構成されてもよい。これは、特に、ユーザという用語が、一般に、人間または人間のグループとしてのユーザと、或る人間によって用いられるユーザ装置とのうちのいずれか一方または両方を指す理由である。

保護リソースとは、ユーザのユーザＩＤまたはユーザのグループに関連するＩＤグループに関するデータか、あるいは、ユーザのＩＤまたはユーザのグループに関連するＩＤグループに関連するサービスかのいずれか一方である。保護リソースの例には、個人的な写真、オンラインアドレス帳の中の連絡先、オンライン・ソーシャル・ネットワークにおける友人リスト、ブックマークのリスト、オンライン・ソーシャル・ネットワーク・アカウントの中に記憶された好きな曲のリスト、オンラインストアから最近購入した商品のリスト、サーバまたはブログ等にあるデータを保存するか公開するかの可能性等が含まれる。保護リソースには、保護ソーシャル情報が含まれてもよい。

保護リソースへのアクセスまたはその利用は、上記のように、サービスの利用に存していてもよい。その文脈において、サービスの提供とは、例えば販売を通じての物理的商品の所有や、コンピュータ構成の技術特性の変更などをもたらす結果となる、技術的および経済的活動である。サービスはウェブサービスであってもよい。

本発明は、ウェブベースのソーシャルネットワークサービスと共に用いられてもよいが、それらに限定されない。同様に、本発明は、ＯＡｕｔｈプロトコルまたはＯＡｕｔｈプロトコルから導出されたプロトコルを用いてもよいが、それに限定されない。本発明は、他の文脈において、また、他のプロトコルと共に用いられてもよい。

一実施形態では、方法はさらに、メッセージがポリシー設定に適合していると判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されることを許可するステップを含んでいる。すなわち、コントローラは、要求トークンの転送に反対する、他の障壁を維持しない。

本実施形態の或る下位実施形態では、その後、要求トークンは、コントローラによって直接サービスプロバイダへ転送される。

本実施形態の別の下位実施形態では、その後、要求トークンは中間的物理エンティティへ転送され、次いで、そこから要求トークンは、要求トークンに関連するサービスプロバイダへ転送される。そのような中間的物理エンティティまたはコンピュータプログラムは、ユーザ端末であってもよいし、ユーザ端末上で実行されるブラウザであってもよい。また、中間的物理エンティティまたはコンピュータプログラムは、それ自体がコントローラとして動作してもよい。これは、２つのコントローラまたは複数のコントローラの各々において異なるポリシー設定が行使されるような、２ステップまたは複数のステップの判定プロセスを提供する。

一実施形態では、コントローラは、要求トークンが転送されるのを阻止し、それゆえ、要求トークンが許可された場合、どのコンシューマが保護リソースにアクセスするかまたはそれを使用するだろうか、要求トークンが許可された場合、どの保護リソースがアクセスされるかまたは使用されるだろうか、および、要求トークンが許可された場合、保護リソースがどう使用されるだろうかのうちの少なくとも１つに関するメッセージから抽出または収集された情報に基づいて、認証および許可プロセスの中断をもたらす。

一実施形態では、メッセージがポリシー設定に適合しているかどうか判定するステップは、抽出するサブステップと判定するサブステップとを含んでいる。抽出するサブステップは、要求トークンの発信元であるコンシューマについての情報と、要求トークンを使ってそれに関する１つ以上の操作の許可が求められている保護リソースについての情報と、要求トークンを使って許可が求められている１つ以上の操作についての情報とのうち少なくとも１つをメッセージから抽出することを含んでいる。判定するサブステップは、抽出するサブステップにおいて抽出された情報がポリシー設定に適合しているかどうか判定することを含んでいる。

本実施形態は、要求トークンを含むメッセージから推定されうる程度まで、プライバシ管理に関して要求トークンの重要性をコントローラが効果的に制御することを可能にする。メッセージから抽出された情報がポリシー設定に適合していなかった場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。

要求トークンを含むメッセージをコントローラがインターセプトして検査することは、要求トークンの発信元であるコンシューマの特徴またはＩＤに関連してもよく、ここで一部のコンシューマまたはコンシューマのタイプもしくはグループは、信頼できないとみなされることがある。

要求トークンを使ってそれに関する１つ以上の操作の許可が求められている保護リソースについての情報が、（メッセージがそのような保護リソースを識別するパラメータを含んでいるからか、または、要求トークンに関連する保護リソースのＩＤまたは保護リソースのタイプを導出することがメッセージの１つ以上の特性から可能になるからかのいずれかの理由で）メッセージから入手または抽出されることを条件として、メッセージの中間のインターセプトおよび検査は、保護リソースについてのそのような情報を抽出することを含んでいてもよい。メッセージが、機密情報（例えば、銀行についての詳細記述など）のように、特定の保護リソースまたは保護リソースのタイプに関する許可要求に相当する場合、要求トークンは、例えば、サービスプロバイダへ転送されるのを阻止されてもよい。

一実施形態では、要求トークンを使ってそれに関する１つ以上の操作の許可が求められている保護リソースについての情報は、メッセージから入手または抽出することができる。

要求トークンを使って許可が求められている１つ以上の操作についての情報がメッセージから入手または抽出されることを条件として、メッセージをインターセプトして検査するステップは、許可が求められている操作のそのような特性がポリシー設定に適合しているかどうか判定することを含んでいてもよい。

一実施形態では、要求トークンを使って許可が求められている操作についての情報は、メッセージから入手または抽出することができる。

一実施形態では、方法は、さらに、少なくとも１つのサービスプロバイダから、少なくとも１つのサービスプロバイダにおけるユーザＩＤに関連する保護リソースに関する情報を入手するステップを含んでいる。これは、サービスプロバイダからアクセスできる保護リソースの一覧をユーザが入手することを可能にする。これは、適切なプライバシ管理が実行されることを可能にする。

本実施形態の或る下位実施形態では、少なくとも１つのサービスプロバイダにおけるユーザＩＤに関連する保護リソースに関してコントローラが入手できる情報は、少なくとも１つのサービスプロバイダにおけるユーザＩＤに関連する保護リソースの利用に関する情報を含んでいる。

本実施形態は、ユーザがコントローラを通じて、ユーザのＩＤに関連する保護リソースの動的一覧を入手することを可能にする。それゆえ、コントローラは、その点で制御の中心点として動作する。

入手可能な一覧は、ユーザが、どのようにして、および、いつ、すなわち、少なくとも或る期間内のいつ、保護リソースがどのコンシューマによって使われたかということに関する情報を入手できるという意味で、動的でありうる。このようにして、ユーザは、ユーザの保護リソースの利用についての情報を収集することができる。次いで、ユーザは、この知識に基づいて、コントローラの中のポリシー設定を修正するかどうか決定してもよい。ユーザからの明確な要求を受信した時点で、コントローラによって利用履歴の検索が行われてもよい。あるいは、コントローラが、ユーザとの最初の対話に基づいて、または、デフォルト設定に基づいて、ユーザＩＤに関連する保護リソースの利用履歴を検索するように構成されてもよい。

ＩＤ、あるいは具体的にはユーザＩＤは、ユーザの特性の１つであり、ユーザを識別するかまたはユーザを識別するために何らかのかたちでユーザにマッピングされている。

利用情報は、特に、保護リソースのタイプと、保護リソースへのアクセスのタイムスタンプと、ＩＤリソースにアクセスするかまたはした、またはＩＤリソースを利用するかまたはしたコンシューマの識別子とのうち、１つ以上についての情報を含んでいてもよい。

一実施形態では、方法は、さらに、受信されたメッセージおよびそれらの要求トークンが転送されるのを阻止されたかどうかと、受信された要求トークンおよびそれらが転送されるのを阻止されたかどうかと、受信されたメッセージおよびそれらの要求トークンが転送されるのを許可されたかどうかと、受信された要求トークンおよびそれらが転送されるのを許可されたかどうかとのうち少なくとも１つに関する情報を記録することを含んでおり、それを本書では履歴情報と呼ぶ。次いで、方法は、履歴情報をユーザ端末が利用できるようにするステップを含んでいる。

一実施形態では、方法は、さらに、コントローラと通信することが可能なユーザ端末によって行われ、方法は、さらに、ユーザ端末が、コントローラの中にポリシー設定を設定することを含んでいる。

また、本発明は、要求トークンを含むメッセージを受信するように構成された受信器を含むコントローラに関する。上記のように、要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。また、コントローラは、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器と、メッセージがポリシー設定に適合していないと判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するように構成された転送器とを含んでいる。

また、本発明は、コンピュータまたは上記のコントローラ上で実行された場合に、コンピュータまたはコントローラにそれぞれ、上記の方法を実行させるように構成された命令を含むコンピュータプログラムに関する。また、本発明は、そのようなコンピュータプログラムを含むコンピュータプログラムプロダクトまたはコンピュータ可読媒体に関する。

次に、添付の図面と併せて、本発明の実施形態について説明する。

本発明の一実施形態における方法のフローチャートである。 本発明の一実施形態における、コントローラと、その構成要素の一部とを略示する図である。 本発明の別の実施形態における方法のフローチャートである。 本発明の一実施形態における方法のフローチャートであって、ここで、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップは、メッセージから情報を抽出するサブステップと、抽出された情報がポリシー設定に適合しているかどうか判定するサブステップとを含んでいる。 ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。 ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。 ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。 ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。 ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。 本発明の背景、および、本発明の実施形態によって対処される一部の問題の理解を深めることだけを目的にしてネットワーク構成を略示する図である。 本発明の一実施形態における方法を示す図である。 本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダからアクセスできる保護リソースについての情報を入手するコンシューマとしてのコントローラの使用を示す図である。 本発明の一実施形態における方法を示す図であり、特に、保護リソースへのアクセスを管理するポリシー設定をコントローラにおいて設定する操作を示す図である。 本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダの保護リソースにアクセスするためにコンシューマによって開始される許可手順を行う操作を示す図である。 本発明の一実施形態における方法を示す図であり、特に、保護リソースの利用の履歴をコントローラから入手する操作を示す図である。

次に、本発明について、具体的な実施形態に関して記述しよう。留意されるであろうが、これらの具体的な実施形態は、当業者の理解を深めるのに役立つものであって、決して本発明の範囲を制限することは意図されておらず、本発明の範囲は、添付の請求項によって定義される。

図１は、本発明の一実施形態における方法のフローチャートである。図１に示す方法は、コントローラ１００によって行われる。

最初に、コントローラ１００が、ステップｓ１０で、要求トークンを含むメッセージを受信する。メッセージは、サービスプロバイダ４００からアクセスできる保護リソースにアクセスすることを求めるコンシューマ３００から発信される。その文脈において、要求トークンは、保護リソースにアクセスするための要求を識別する値である。メッセージは、要求トークンに加えて、要求トークンに伴う各種の追加情報またはパラメータ、例えば要求トークンが発信されるコンシューマ３００のＩＤ、コンシューマ３００によって開始される許可要求の対象である保護リソース、および／または、保護リソースに関連してコンシューマ３００によって許可が求められた操作などを含んでいてもよい。

要求トークンを含むメッセージは、要求トークンを生成したコンシューマ３００とは別の物理エンティティから来てもよい。すなわち、コンシューマ３００とコントローラ１００との間に、メッセージおよびその要求トークンがそこを通して転送される中間的物理エンティティが存在していてもよい。

メッセージは、パケットでも、ＨＴＴＰ要求でも、いずれかのそれ以外の、要求トークンを搬送するための適切な形式の信号であってもよい。

次いで、コントローラ１００は、ステップｓ２０で、受信されたメッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。

ポリシー設定は、コントローラ１００上に記憶されているかまたはコントローラ１００がアクセスできるようになっており、コントローラ１００が代理動作するユーザに関連する保護リソースに関係している。ポリシー設定は、図１０に示すように、ユーザによって設定されてもよい。あるいは、または、それに加えて、プライバシ設定が、コントローラ１００を起動する時にデフォルトで設定されてもよい。プライバシ設定の更新は、ユーザによって行われてもよいし、コントローラ１００を設定するようにリモートで許可された第三者によって行われても、あるいはその両方によって行われてもよい。

例えば、コントローラ１００によって用いられることになるポリシー設定をユーザが事前に設定し、第１の特定のコンシューマ３００、例えば「ｄｏｅｓｎｔｃａｒｅａｂｏｕｔｐｒｉｖａｃｙ．ｃｏｍ」や「ｓｅｌｌｓｙｏｕｒｐｒｉｖａｔｅｄａｔａｔｏ３ｒｄｐａｒｔｉｅｓ．ｃｏｍ」は、リソースが何であれ、また、リソースに関して行われることになる操作が何であれ、ユーザのいずれの保護リソースにもアクセスすることを許可されないということを示してもよい。また、ユーザは、別の特定のコンシューマ３００、例えば「ｃａｒｅｓａｂｏｕｔｐｒｉｖａｃｙ．ｃｏｍ」からのメッセージの中に見つかった要求トークンは、リソースに関して行われることになる操作が何であれ、保護リソースが例えば銀行の詳細情報であるかまたはソーシャルセキュリティ番号である場合、または、許可が求められた操作が一部の保護リソースの削除に存する場合に限って、転送されるのを阻止されるべきであることを示してもよい。

ステップｓ２０の結果として、メッセージがポリシー設定に適合していない場合（ステップｓ３０）、メッセージは、ステップｓ３４で、サービスプロバイダ４００へ転送されるのを阻止される。転送の阻止は、例えば、メッセージを削除し、後で評価するためにメッセージの詳細についてコントローラ１００の中にログを取り、そして、メッセージをインターセプトして転送しなかったことについてコンシューマ３００に通知することによって行われてもよい。コンシューマ３００へ送信された情報は、要求トークンを含むメッセージがなぜコントローラ１００によって転送されるのを阻止されたのかについての詳細を含んでいてもよい。

方法は、複数のネットワークエンティティに分散されたユーザの保護リソースのプライバシの側面を管理するためのユーザにやさしい効率的な解決策をエンドユーザに提供する。同時に、方法は、実装の影響を最小化する。ユーザは、ユーザが許可したい保護リソースの利用に制限を設定することを目的として、ユーザについての保護リソースを記憶している個々のサービスプロバイダをくまなく調べる必要はない。加えて、ユーザは、保護リソースにアクセスするためのコンシューマによる許可要求を認めたり拒否したりすることを求められてじゃまされる頻度が少なくなる。

ステップｓ３０で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定された場合、メッセージは、転送されるのを阻止されてもされなくてもよい。例えば、コントローラ１００がファイアウォールとしても動作する場合、コントローラ１００は、他の理由でメッセージをブロックすることを決めてもよい。これは、メッセージが、保護リソースへのアクセスを管理するいずれのポリシー設定にも関係しない、何らかの添付「．ｅｘｅ」ファイルを含んでいるからであってもよい。

メッセージがサービスプロバイダ４００へ転送されるのをコントローラ１００が阻止するその他の理由、すなわち、保護リソースへのアクセスを管理するポリシー設定に基づかないその他の理由があってもよい。別の例示的な理由は、コントローラ１００がウェブブラウザと一体化されており、ブラウザ上ではＨＴＴＰのリダイレクションは可能にされていない／許されていないため、ブラウザが、メッセージが転送されるのを許さないということもありうる（この可能性は、参考文献［２］、セクション６．２．１に記載されている）。

ステップｓ３０で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定され、その後メッセージが、サービスプロバイダ４００へ転送されるのを阻止されなかった場合、この結果として、メッセージは、サービスプロバイダ４００に直接転送されてもよい。あるいは、メッセージは、メッセージが最終的にサービスプロバイダ４００へ転送される前に、別の決定プロセスを行う権利を有する別の物理エンティティへ転送されてもよい。これが起こり得る状況は、図６ａに関して記述しよう。

一実施形態では、２つ以上の要求トークンを含むメッセージが、コンシューマ３００によって開始された許可プロセスに関与している。メッセージは、ポリシー設定をチェックされ、メッセージは、ポリシー設定に適合していない要求トークンだけがサービスプロバイダ４００へ転送されるのを阻止されるように、コントローラ１００によって修正されてもよい。

図２は、本発明の一実施形態における、コントローラ１００およびその一部の構成要素を略示する図である。コントローラ１００は、要求トークンを含むメッセージを受信するように構成された受信器１１０を含んでいる。コントローラ１００は、さらに、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器１２０を含んでいる。ポリシー設定は、コントローラ１００の中に記憶されてもよいし、コントローラ１００からアクセス可能なデータベースもしくはメモリユニットの中に記憶されてもよい。メッセージがポリシー設定に適合していないとコントローラ１００が判定した場合、転送器１３０は、メッセージがサービスプロバイダ４００へ転送されるのを阻止する責任を持つ。

図３は、本発明の一実施形態における方法のフローチャートである。図１のフローチャートに示すステップに加えて、図３に示す方法は、要求トークンがサービスプロバイダ４００へ転送されるのを許可するステップｓ３２を含んでいる。このステップｓ３２は、ステップｓ３０でメッセージがポリシー設定に適合していると判定された場合に起きる。言い換えると、図３に示す方法を行うコントローラ１００は、メッセージがポリシー設定に適合していないと判定された場合に限って、要求トークンに関連するサービスプロバイダ４００に要求トークンが転送されるのを阻止する。

図４は、本発明の一実施形態における方法のフローチャートである。図１のフローチャートで示すステップに加えて、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップｓ２０は、２つのサブステップを含んでいる。第１のサブステップｓ２２は、メッセージから、
（ｉ）要求トークンが許可された場合に保護リソースにアクセスしうるコンシューマ３００についての情報と、
（ｉｉ）要求トークンが許可された場合にアクセスされうる保護リソースについての情報と、そして、
（ｉｉｉ）要求トークンが許可された場合に保護リソースに関して行われうる操作についての情報と、
のうち、少なくとも１つを抽出することに存する。

メッセージから情報を抽出するサブステップｓ２２は、メッセージを構文解析することを含んでいてもよい。

第２のサブステップｓ２４は、抽出された情報がポリシー設定に適合しているかどうかに基づいて要求トークンがサービスプロバイダ４００へ転送されるのを阻止するかどうか判定することに存する。抽出された情報が、コントローラ１００の中に記憶されたかまたはコントローラ１００がアクセスできるポリシー設定に適合していなかった場合、コントローラ１００は、要求トークンがサービスプロバイダ４００へ転送されるのを阻止する。

図５ａ乃至６ｂは、本発明の実施形態が適用されうる一部のネットワーク構成を示す。図５ａ乃至６ｂの各図には１つのコンシューマ３００と１つのサービスプロバイダ４００とだけを示しているが、２つ以上のサービスプロバイダ４００と２つ以上のコンシューマ３００とが提供されてもよい。同様に、１つのユーザ端末（すなわちＵＥ）２００だけがネットワークの他の構成要素と対話するように示しているが、２つ以上のユーザ端末２００が関与してもよい。

ユーザ端末２００およびコントローラ１００は通信してもよく、従ってコントローラ１００はユーザ端末２００が情報を利用できるようにすることができる。それに応じて、ユーザ端末２００は、コンシューマ３００から到着するメッセージを制御するためにコントローラ１００によって用いられるポリシー設定を構成してもよい。ユーザがユーザ端末２００を通じてコントローラ１００の中にポリシー設定を設定することは、（例えばＵＥ２００上にある）コンピュータディスプレイ上に生成されたグラフィカルユーザインタフェースを用いて実施され、その結果、ユーザがポリシー設定を設定するためにユーザ端末と対話してもよい。コントローラ１００は、ユーザのためのプライバシ代理人として動作する。

図５ａ乃至６ｂに示すコンシューマ３００またはコンシューマのウェブアプリケーション、および、サービスプロバイダ４００またはサービスウェブアプリケーション（コンテナとも呼ばれることがある）は、一般に、少なくとも最初は、あるいはデフォルト動作としては、相互に信用していない。コンシューマ３００とサービスプロバイダ４００とは、連結による集中的手法をとらない。

図５ａは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここでコントローラ１００とユーザ端末２００とは、別個の物理エンティティである。ユーザ端末２００はコントローラ１００と通信することができる。コンシューマ３００から要求トークンを含むメッセージを受信した時点で、コントローラ１００は、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。ポリシー設定に適合していないメッセージは、サービスプロバイダ４００へ転送されるのを阻止される。一方、ポリシー設定に適合しているメッセージは、サービスプロバイダ４００へ転送されてもよい。そのようなかたちで、ポリシー設定が行使される。

図５ｂは、本発明の一実施形態におけるネットワーク構成を示しており、ここで、図５ａに関して記述したステップに加えて、コントローラ１００は、ユーザ装置２００すなわちユーザ端末２００上で作動する。

図５ｃは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここで、ユーザ端末２００は、ユーザ端末２００の上で作動するウェブブラウザ１４０を有している。ブラウザ１４０の動作は、少なくともある程度、コントローラ１００によって制御されている。図５ｃではコントローラ１００は、ブラウザ１４０を含むように描かれているが、コントローラ１００は、ブラウザ１４０に到達するメッセージおよび要求のフローを制御するため、ブラウザ１４０と同時に作動してもよい。一実施形態では、コントローラ１００は、ブラウザのアドオンを用いて実装される。

コンシューマ３００から発信されたメッセージが、コントローラ１００によって受信される。メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ４００のアドレスにリダイレクトする（向けなおす）ための（または、本書では同じ意味であるが、向けるための）要求を含んでいる。コントローラ１００が、リダイレクト要求は、保護リソースへのアクセスを管理するポリシー設定に基づいて、受け入れるのを阻止されるべきかどうか判定する。コンシューマ３００が、最初にメッセージをコントローラ１００へ送信し、次いで、コントローラ１００によって行われる判定に応じて、コントローラ１００が要求トークンをサービスプロバイダ４００へ転送してもよい。

その点において、図５ｃは、コントローラ１００と、コントローラ１００と通信できるユーザ端末２００とを含むシステムを略示する図であるが、ここで、ユーザ端末２００は、ウェブブラウザを作動するように構成され、メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ４００のアドレスへリダイレクトする（向けなおす）（または、向ける）ための要求を含んでいる。

図６ａは、本発明の一実施形態におけるネットワーク構成を示す図であり、ここで、コントローラ１００は、プロキシコントローラ１００である。メッセージをコンシューマ３００から受信した時点で、メッセージがポリシー設定に適合していると判定された場合、メッセージおよびその要求トークンはユーザ端末２００へ転送される。そうでない場合、メッセージはユーザ端末２００へ転送されず、従って、要求トークンは、その後、要求トークンに関連するサービスプロバイダ４００へユーザ端末２００によって転送されるのを阻止される。言い換えると、コントローラ１００は、ポリシー設定に従って必要であると判定された場合にメッセージをブロックすることによって、要求トークンがユーザ端末２００によってサービスプロバイダ４００へ転送されるのを阻止する。

図６ｂは、本発明の一実施形態におけるネットワーク構成を略示する図であり、２つのコントローラ、すなわち、プロキシコントローラ１００ａとユーザ端末２００上で作動するコントローラ１００ｂとを含んでいる。コンシューマ３００からのメッセージをプロキシコントローラ１００ａによって受信した時点で、プロキシコントローラ１００ａは、メッセージがポリシー設定に適合しているかどうか判定する。メッセージがポリシー設定に適合している場合、メッセージおよびその要求トークンは、コントローラ１００ｂをホストするユーザ端末２００へ転送される。そうでない場合、メッセージはユーザ端末２００およびコントローラ１００ｂへは転送されず、従って、要求トークンは、ユーザ端末２００およびコントローラ１００ｂによって要求トークンに関連するサービスプロバイダ４００へ転送されるのを阻止される。

メッセージおよびその要求トークンが、コントローラ１００ｂをホストするユーザ端末２００へ転送される場合、コントローラ１００ｂは、コントローラ１００ｂにとって適切であるポリシー設定に基づいて、メッセージの第２のインターセプトおよび検査を行う。

図６ｂのネットワーク構成において、プロキシコントローラ１００ａは、例えば、ローカルネットワークアドミニストレータによって管理されてもよく、そして、ユーザ端末２００上でホストされている他方のコントローラ１００ｂは、例えばユーザ自身によって管理されてもよい。ここで、コントローラを管理するとは、コントローラに適用可能なポリシー設定を少なくとも設定できることを意味する。

図７は、本発明の背景をさらに詳細に示すため、および、本発明によって解決される一部の問題の理解を深めるため、ＯＡｕｔｈプロトコルによる認証および許可プロセスを略示する図である。しかし、本発明は、ＯＡｕｔｈプロトコルへの適用に限定されない。

ＯＡｕｔｈプロトコルは、ユーザがユーザのサービスプロバイダ認証情報をコンシューマに開示することを必要とせず、（図７の「コンシューマ」と記されたボックスによって示す）コンシューマアプリケーションが（図７の「サービスプロバイダ」と記されたボックスで示す）サービスプロバイダの保護リソースにアクセスするのを可能にする。ＯＡｕｔｈプロトコルは、保護リソースを求める要求の中で、ユーザの認証情報の代わりに、サービスプロバイダによって生成されるトークンを用いる。プロセスは２つのトークンタイプ、すなわち、要求トークンとアクセストークンとを用いる。要求トークンは、保護リソースへのアクセスを許可するようにユーザに求めるためにコンシューマによって用いられる。許可された要求トークンは、次いで、アクセストークンと交換される。アクセストークンは、ユーザの代わりに保護リソースにアクセスするためにコンシューマによって用いられる。

やはり図７に関して、最初に、ユーザが何らかのかたちで、例えば、例示的なｐｒｉｎｔｅｒ．ｃｏｎｓｕｍｅｒ．ｃｏｍのウェブサイト（コンシューマ）を自分のユーザエージェントを使って閲覧することによって、許可プロセスをトリガする（ステップＡ）。許可プロセスは、次いで、３つの連続ステップを含んでいる。

（１）コンシューマが、未許可の要求トークンをサービスプロバイダから入手する（ステップＢ）。

（２）ユーザが自分のユーザエージェントを用いて要求トークンを許可する。そうするために、最初に、コンシューマは未許可の要求トークンをユーザエージェントに送信し、それをユーザエージェントが、サービスプロバイダへ転送する（ステップＣ）。次いで、サービスプロバイダが、ユーザエージェントを通してユーザとの認証手順を始める（ステップＤ）。認証手順が成功したら、サービスプロバイダは、要求トークンを許可し、ユーザエージェントに許可された要求トークンを与え（ステップＥ）、それをユーザエージェントは、元のコンシューマへ転送する。認証手順が失敗したら、サービスプロバイダは、ユーザエージェントを通じて応答を転送する際に、要求トークンが無効化されたことをコンシューマに通知してもよい。

（３）最後に、コンシューマは、その後でサービスプロバイダのユーザの保護リソースにアクセスすることを目的として、サービスプロバイダとの間で、許可された要求トークンをアクセストークンに交換（ステップＦ）する。

ＯＡｕｔｈプロトコルによれば、プライバシ管理はユーザ自身によって処理される。ユーザは、サービスプロバイダの保護リソースにアクセスするため、コンシューマを許可する。許可が与えられた後、コンシューマは、保護リソースにアクセスするためのアクセストークンを手に入れる。発明者らが特に認識していることだが、ＯＡｕｔｈプロトコルはアクセストークンの有効期間についていかなる制限をも規定していないが、トークンが短期間有効である場合には、許可は、コンシューマが保護リソースへのアクセスを必要とする度に与えられる必要があるであろう。このように許可を繰り返し要求する必要があることは、面倒でありうる。

また、発明者らがさらに特に認識していることだが、ＯＡｕｔｈプロトコルは、コンシューマに対して認められるアクセス権をきめ細かくユーザが制御できるようにする方法は何ら考慮していない。代わりに、ユーザは、サービスプロバイダの中のユーザの保護リソース全部へのアクセスを所与のコンシューマに対して認めるか拒否するかである。

また、発明者らがさらに特に認識していることだが、ユーザは、どの保護リソースをコンシューマが実際に要求しているのかが分からない。一旦コンシューマが許可されると、保護リソースにアクセスするための要求は、コンシューマとサービスプロバイダとの間の直接通信であり（図７のステップＦ）、ユーザは、どの保護リソースが現在使用されており、これまで使用されたのかを知る手段を持たない。

ユーザは、ユーザＩＤに関連する保護リソースを記憶している各サービスプロバイダにおいてユーザのプライバシ設定を設定することができたであろう。しかし、プライバシ設定は、そもそも可能であればだが、サービスプロバイダ毎に明示的に記述される必要があるであろう。

図８は、本発明の一実施形態におけるネットワーク構成と、この実施形態を行う際に含まれる通信フローとを略示する図である。

両矢印「１」は、サービスプロバイダ４００の中の保護リソースの存在についての情報をコントローラ１００が検索することを示す。これは、いわゆる静的一覧検索であり、これについては図９に関して詳細に説明しよう。一旦コントローラ１００がサービスプロバイダ４００によって認証されると、コントローラ１００は、所与のユーザに関連する保護リソースについての情報を入手するためにサービスプロバイダ４００にクエリを行う。

図９は、本発明の一実施形態を成す静的一覧検索を示す。本実施形態では、ＯＡｕｔｈプロトコルが用いられる場合、コントローラ１００は、ＯＡｕｔｈコンシューマ３００として動作または機能する。この目的で、コントローラ１００は、目標のサービスプロバイダ４００においてコンシューマ３００として事前に登録されていてもよい。登録プロセスの間、サービスプロバイダ４００は、コントローラ１００にコンシューマ鍵とコンシューマ秘密とを提供する。これらの要素は、コントローラ１００とサービスプロバイダ４００との間の将来の通信に役立つものであり、コントローラ１００がクエリを行うことを望んでいるサービスプロバイダ４００について（ユーザ毎ではなく）一度だけ生成されうる。

一旦コントローラ１００がサービスプロバイダ４００の中に登録されると、ユーザは、コントローラ１００を用いてサービスプロバイダ４００の中でユーザについて記憶された保護リソース（ユーザＩＤに関連する保護リソース）の静的な一覧を検索してもよい（ステップ０、「静的な一覧を示す」と記載された矢印）。コントローラ１００は、サービスプロバイダ４００から未許可の要求トークンを入手することによって動き始める（ステップ１、「未許可の要求トークンを入手する」）。次いで、許可プロセスが始まる（ステップ２、「要求トークンを許可する」）。この許可プロセスの間、サービスプロバイダ４００は、ユーザが認証されることを必要とする（ステップ３ａ、「認証が必要とされる」）。このために、コントローラ１００は、ユーザプロキシとして動作する。コントローラ１００は、第１に、認証情報をユーザに要求し（ステップ３ｂ、「認証プロセス」）、次いで、ユーザの認証情報を元のサービスプロバイダ４００へ転送する（ステップ３ｃ、「認証応答」）。この許可プロセスの最後に、コントローラ１００が、許可された要求トークンを受信し（ステップ４、「許可された要求トークン」）、それをコントローラ１００は、有効なアクセストークンと交換する（ステップ５、「アクセストークンを入手する」）。

コントローラ１００は、アクセストークンを用いて、サービスプロバイダ４００において、サービスプロバイダ４００でアクセス可能な保護リソースにアクセスする（ステップ６、「保護リソースを入手する」）。一旦サービスプロバイダ４００がこの情報を開示すると、コントローラ１００は、それをユーザに提示する（ステップ７、「利用可能な情報」）。

一実施形態では、ユーザは、例えば情報の追加、更新、削除といった、保護リソースに関するさらなる管理操作を行う機会を提供されてもよい。

図９で示す「静的一覧検索」の実施形態が、ＯｐｅｎＳｏｃｉａｌおよびＯＡｕｔｈプロトコルの文脈で用いられてもよい。ＯｐｅｎＳｏｃｉａｌは、ウェブベースのソーシャルネットワーキングアプリケーションがそれらのソーシャルデータを共有するのに役立てるため、アプリケーションプログラミングインタフェース（ＡＰＩ）のセットを提供しており、米国のサンフランシスコに拠点を置くＯｐｅｎＳｏｃｉａｌ Ｆｏｕｎｄａｔｉｏｎ（ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｓｏｃｉａｌ．ｏｒｇ／を参照のこと）によって維持されている。ＯｐｅｎＳｏｃｉａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ０．９は、２００９年１０月時点で、
ｈｔｔｐ：／／ｏｐｅｎｓｏｃｉａｌ．ｏｒｇ／Ｔｅｃｈｎｉｃａｌ−Ｒｅｓｏｕｃｅｓ／ｏｐｅｎｓｏｃｉａｌ−ｓｐｅｃ−ｖ０９／ＯｐｅｎＳｏｃｉａｌ−Ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｈｔｍｌで入手可能である。

ステップ１、２、３、４、５（図９に示す）は、ＯＡｕｔｈプロトコル（参考文献「２」）に従ってもよい。しかし、ユーザが各サービスプロバイダ４００を繰り返し認証する（ステップ３ｂ）必要性を回避するため、コントローラ１００は、ユーザの保護リソースをキープまたは維持する各サービスプロバイダ４００にユーザの認証情報を記憶してもよい。有利には、これはシングルサインオン手順を提供する。また、ステップ６は、ＯｐｅｎＳｏｃｉａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ０．９に記述されたプロトコルに従ってもよい。

図１０は、本発明の一実施形態における、ユーザ、またはユーザ端末による、コントローラ１００におけるプライバシ設定の管理を略示する図である。特に、プライバシ設定管理に含まれうる通信を示す。

ユーザが、自分の保護リソースの使用と開示とを管理するためにプライバシ選好を設定したいと望む。コントローラ１００は、多様な選択肢をユーザに示し、例えば保護リソースがアクセスされうる、すなわち使用または開示されうる条件のような、多様なパラメータを、ユーザが構成できるようにする。完了したならば、コントローラ１００は、結果としてのポリシー設定を記憶する。その後、コンシューマ３００が保護リソースにアクセスするための許可を必要とする度に、コントローラ１００は、ユーザの選好、すなわちポリシー設定を行使する。

ユーザは、自分の保護リソースへのアクセスに関する自分の選好を設定できることで、利益を得る。このために、ユーザは、コントローラ１００の中にプライバシ選好を設定し、その後、コントローラ１００は、これらのプライバシ選好を行使する。

ポリシー設定の定義に加わる変数には、要求者（リクエスタ）、リソース、操作、パーミッションなどが含まれうる。ユーザは、コントローラ１００のユーザなのだから、ポリシー設定の中にユーザが明示的に記述されなくてもよい。ただし、ユーザが記述されてもよい。

要求者は、ユーザの保護リソースにアクセスしようとするいずれかのコンシューマ３００であってもよい。

リソースは、ポリシー設定規則に関係している保護リソースの識別子であってもよい。例えば、ＯｐｅｎＳｏｃｉａｌは、例えば人物や行動といった、標準的な保護リソースについての具体的なフォーマットを定義している。サービスプロバイダ４００の静的な一覧が検索された場合、コントローラ１００は、この情報を用いて、リソースに関連する見込まれる値を減らし、一層きめ細かいポリシーを提供しうる。

操作の値は、いずれかのコンシューマ３００が要求することができる操作であってもよく、例えば、ＯｐｅｎＳｏｃｉａｌの例では、それらは「クエリを行う」、「作成する」および「削除する」であってもよい。しかし、本発明の一実施形態は、ポリシー設定規則に従いうるいずれかの数またはタイプの操作に限定されない。

パーミッションは、「認める」、「拒否する」または「アスク・ミー（ａｓｋＭｅ）」（ユーザが実施毎に決定することを望む場合；これはアドホック・インタラクション・サービス、すなわちブラウザにおけるポップアップ、ＳＭＳベースの許可などを使って実施されうる）に設定されてもよい。また、解決策の使い勝手を向上させるため、一部の選択肢（ワイルドカード）、すなわち、「すべての見込まれる値」、「全くなし」または「ユーザが選択した具体的な部分集合」、が導入されてもよい。

これらの値は、ユーザによって設定され、コントローラ１００に提出される（図１０、ステップ０、「プライバシ選好を設定する」）。結果として、ユーザおよびユーザの保護リソースに関する新たなポリシー設定規則が作成され、コントローラ１００の中に記憶される（ステップ１、「プライバシ選好を記憶する」）。ポリシー設定プロセスは、それに関して情報が開示されうるさらなる条件の明細を使って拡充されてもよい。

ユーザは多様な手段を通じて自分のプライバシ選好を表現する機会を与えられてもよい。第１に、ユーザは複数の定義済のプライバシポリシーの中から１つを選び、それを保護リソースに関連付けてもよい。これらの定義済プライバシポリシーは、技術的知識のないユーザも理解できるように、自然言語で記述されてもよい。この自然言語記述は、プライバシポリシー表現言語として記述される具体的なポリシー実装にマッピングされる。これらのポリシーはユーザがそれらを比較して自分のニーズにもっと合致するものをより容易に選べるよう、階層的になっている。ユーザはポリシーの詳細を扱う必要がないことから、この手法には、モデルの単純性と使い勝手という強みがある。

また、ユーザは、プライバシポリシーの詳細の各々を定義することができてもよい。この手法は、ユーザ選好の記述に与える柔軟性が大きくなるが、使い勝手については若干のリスクを生じさせることがある。上級ユーザだけがポリシーの意味を理解する（そして多分、知ることを望む）ことがありえる。これは、上級選択肢として提供されてもよい。

次に、本発明の一実施形態におけるプライバシポリシーの行使について、図１１に関して説明しよう。

コンシューマ３００が、保護リソースにアクセスすることを望む。保護リソースは、コントローラ１００の中にユーザによって設定されたポリシー設定によって管理される。コントローラ１００は、ポリシー設定を行使し、それゆえ、サービスプロバイダ４００の保護リソースにコンシューマ３００がアクセスすることを可能にするであろう許可されたトークンの返信をコンシューマ３００が受信できるかどうか間接的に決定する。

コンシューマ３００は、ユーザの代わりに働いてもよい。ゆえに、両者間にすでにＨＴＴＰ接続が確立されていてもよい。

コンシューマ３００は、保護リソースをホストするサービスプロバイダ４００から未許可の要求トークンを入手することによってプロセスを開始する（図８、「Ｂ」と記載された矢印）。このステップの一部の実装は、ＯｐｅｎＳｏｃｉａｌおよびＯＡｕｔｈ仕様によって定義されている。

次に図１１を参照するが、コンシューマ３００が、ＯＡｕｔｈ許可プロセスを開始する。第１に、コンシューマ３００が、許可のために（ステップ０、「要求トークンを許可する」）ユーザエージェントをサービスプロバイダ４００にリダイレクトするＨＴＴＰメッセージを、ユーザエージェント（ユーザエージェントは、例えば、コントローラ１００が実行されうる操作環境にあるブラウザであってもよい）に送信する。コントローラ１００は、このメッセージを捕捉し、あるいは言い換えればインターセプトして、ポリシー行使のための一部の関連情報を抽出する（ステップ１、「ポリシー行使」）。特に（以下は、網羅的でないリストである）、ＯＡｕｔｈプロトコルが用いられる場合、要求者、あるいはコンシューマ識別子が、ｏａｕｔｈ＿ｃａｌｌｂａｃｋと呼ばれるＯＡｕｔｈパラメータから抽出されてもよい。ＯＡｕｔｈプロトコルは、他の情報、すなわち、コンシューマ３００がそれに関して許可を望んでいる保護リソースおよび操作をどのように検索するかを定義していない。しかし、ＯＡｕｔｈプロトコルは、追加のパラメータがサービスプロバイダ４００によって定義されうることを述べている。

本発明の一実施形態は、この可能性を利用して、ＯＡｕｔｈ許可メッセージが含みうる２つの新たなパラメータ、ｏａｕｔｈ＿ｒｅｑｕｅｓｔｅｄ＿ｒｅｓｏｕｒｃｅおよびｏａｕｔｈ＿ｒｅｑｕｅｓｔｅｄ＿ｏｐｅｒａｔｉｏｎを定義する。これらのパラメータが許可要求の中に含まれていない場合、コントローラ１００は、コンシューマ３００が、サービスプロバイダ４００においてアクセス可能なすべての保護リソースにクエリを行い、修正し、削除しようとしていると想定してもよい。従って、コントローラ１００は、この想定に基づいて、適宜にポリシー設定を行使してもよい。

一旦ポリシー設定が行使され、行使の結果が「可能」（すなわち、「転送することが可能」）となったならば、コントローラ１００は、プロセスを続行する。すなわち、コントローラ１００は、最初の「許可」要求トークンメッセージをサービスプロバイダ４００へ転送する（ステップ２、「要求トークンを許可する」）。次いで、サービスプロバイダ４００は、ユーザの認証手順をユーザエージェントを通じて開始する（ステップ３ａ、「認証が必要とされる」）。この文脈では、認証は、アサートされたユーザのＩＤを、指定されたかまたは了承された信頼レベルで確認するプロセスである。

一実施形態では、その段階で、コントローラ１００は、メッセージを再び捕捉する。認証に必要な認証情報は、「静的一覧検索」のシナリオにおいて記憶されていてもよいため、ユーザが自分に同意を求めなければならないと明示的に記述していない限り、ステップ３ｂ（サービスプロバイダ４００においてユーザの認証情報を入手することを含めて、図９を参照のこと）は、必要ない。

コントローラ１００は、認証応答を送信する（ステップ３ｃ、「認証応答」）。その結果、サービスプロバイダ４００は、許可された要求トークンを返信し（ステップ４、「許可された要求トークン」）、コントローラ１００は、それをコンシューマ３００へ転送する（ステップ４ｂ、「許可された要求トークン」）。次いでコンシューマ３００は、サービスプロバイダ４００において、許可された要求トークンをアクセストークンと交換し、次いで、保護リソースおよび必要な操作にアクセスしてもよい（ステップ５，６，７）。

行使プロセス（ステップ１）の結果が「拒否する」である場合、コントローラ１００は、メッセージをコンシューマ３００へ返信し、拒否についてかまたは拒否の詳細についてコンシューマ３００に通知してもよい。

図１１に関して記述したプロセスは、以下のように、ＯＡｕｔｈプロトコル（参考文献［１］）に基づいていてもよい。

一実施形態では、コントローラ１００は、ユーザおよびユーザのユーザエージェントの代理となる。すなわち、ユーザおよびユーザのユーザエージェントは、コンシューマ３００からの要求が受信された場合、認証のいかなる通知も受信しない。許可プロセスは暗示的である。ユーザ定義のポリシー設定は、ユーザからの介在なしにコントローラ１００によって適用される。

一実施形態では、ＯＡｕｔｈプロトコルへの拡張が行われる。すなわち、２つの追加パラメータ、ｏａｕｔｈ＿ｒｅｑｕｅｓｔｅｄ＿ｒｅｓｏｕｒｃｅおよびｏａｕｔｈ＿ｒｅｑｕｅｓｔｅｄ＿ｏｐｅｒａｔｉｏｎ（当然、これらのパラメータに別の名前が付けられてもよい）が、許可を求めるすべての要求に、すなわち、要求トークンを含むすべてのメッセージに、含まれてもよい。ＯＡｕｔｈプロトコルは、これらの拡張を可能にする。

一旦ユーザまたはユーザの代わりにコントローラ１００が、要求トークンを許可したならば、要求トークンは、アクセストークンと交換することができる。アクセストークンは、ユーザに関連し、かつ、サービスプロバイダ４００からアクセス可能な保護リソースに関する操作を行う特権をコンシューマ３００に認める。

以前の実施形態において定義されたＯＡｕｔｈプロトコルへの拡張が実施された場合、従って、コンシューマ３００が要求トークンの中で（追加パラメータを用いて）どの情報および操作が要求されているかを宣言する場合、一実施形態では、コンシューマ３００がその当初の許可を求める要求の中で宣言したことだけに限ってサービスプロバイダ４００がコンシューマ３００に特権を認めるかたちで、ＯＡｕｔｈプロトコルが拡張されてもよい。これは、許可プロセスに一貫性と信用とを与える。

一実施形態では、サービスプロバイダ４００が保護リソースのコンシューマ３００に、コンシューマ３００はアクセスすることが許可されていることを通知する。サービスプロバイダ４００は、アクセストークンを開示している間に送信される追加パラメータを用いて、コンシューマ３００に通知する。

図１２に関して記述した一実施形態では、動的一覧検索機能が実装される。コントローラ１００が、サービスプロバイダ４００の中のユーザの保護リソースの静的一覧を検索していたと仮定しよう。

さらに、コンシューマ３００が、ユーザに関連する一部の保護リソースにアクセスしようとしたと仮定しよう。今、ユーザは自分に関連する一部の保護リソースの利用履歴を知りたいと望んでいる。この目的で、ユーザは、要求をコントローラ１００に送信する（ステップ０、「利用履歴を入手する」）。コントローラ１００は、要求されたデータを検索し（ステップ１、「利用履歴を検索する」）、次いで、それがユーザに提示される（ステップ２、「利用履歴の詳細」）。

動的一覧検索機能は、以下のように使用可能にされてもよい。コンシューマ３００が、ユーザに関連する保護リソースへのアクセスを要求する度に、このイベントがコントローラ１００によってログがとられる。コントローラ１００は、コントローラ１００がポリシー設定を行使した後に、この情報のログをとってもよい。ゆえに、ポリシー行使の結果に関する情報は、ログに追加されてもよい。この情報は、例えば、将来の監査のために用いられてもよい。

提示された情報には、要求された保護リソースと、アクセスのタイムスタンプと、情報を記憶したサービスプロバイダ４００と、情報にアクセスしたコンシューマ３００と、ポリシー行使の結果とについての詳細が含まれてもよい。情報は、コンシューマ３００によって送信されるメッセージの中に含まれる多様なパラメータから抽出されてもよい。入手可能であれば、さらなる条件、例えば、コンシューマ３００によって行われたプライバシの約束、あるいは、情報を開示した時点でサービスプロバイダ４００によって課される条件が提示されてもよい。

コントローラ、サービスプロバイダ、コンシューマおよびユーザ端末を含めて本発明による物理エンティティは、コンピュータプログラムが物理エンティティ上で実行される場合、本発明の実施形態によるステップおよび手順が行われるような命令を含むコンピュータプログラムを含んでいるかまたは記憶していてもよい。また、本発明は、本発明による方法を行うためのコンピュータプログラム、および、本発明による方法を行うためのコンピュータプログラムを記憶するいずれかのコンピュータ可読媒体に関する。

「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」という用語が本書で用いられている場合、これらの要素がどのようにして分散され、要素がどのようにして集結されるかに関して、制限はない。すなわち、これらの要素の構成部分は、意図された機能を実現するための異なるソフトウェアもしくはハードウェアコンポーネントもしくはデバイスとして分散されてもよい。また、複数の別個の要素が、意図された機能性を提供するために集結されてもよい。

コントローラの上記の要素のいずれか１つが、ハードウェア、ソフトウェア、フィールドプログラマブルゲートアレー（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、ファームウェア等の中に実装されてもよい。同じことは、ユーザ端末、コンシューマ、サービスプロバイダにも適用される。

本発明の別の実施形態において、上記の「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」のいずれか１つが、「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」の機能を行うための、受信手段、判定手段、転送手段、取得手段、記録手段、開示手段によってそれぞれ置換されるか、または、受信ユニット、判定ユニット、転送ユニット、取得ユニット、記録ユニット、開示ユニットによってそれぞれ置換されてもよい。

本発明の別の実施形態において、上記のステップのいずれか１つが、いずれかの種類のコンピュータ言語での、例えばコンピュータが理解可能な手順、方法等の形式の、および／または、ファームウェア、集積回路等の上の内蔵ソフトウェアの形式の、コンピュータ可読命令を用いて実装されてもよい。

本発明を詳細な例に基づいて記述してきたが、詳細な例は、当業者の理解を深める働きをするだけであって、本発明の範囲を限定することは意図されていない。そうではなく、本発明の範囲は、添付の請求項によって定義される。

Claims (15)

1. コントローラ（１００）によって実行される方法であって、
   要求トークンを含むメッセージを受信するステップ（ｓ１０）を備え、
   要求トークンは、サービスプロバイダ（４００）の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ（３００）によって使用される値であり、
   サービスプロバイダ（４００）は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
   コンシューマ（３００）は、ユーザの代わりにサービスプロバイダ（４００）にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
   前記方法は更に、
   前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するステップ（ｓ２０）と、
   前記メッセージが前記ポリシー設定に適合しないと判定された（ｓ３０）場合に、前記要求トークンに関連する前記サービスプロバイダ（４００）へ前記要求トークンが転送されることを阻止するステップ（ｓ３４）と、
   を備えることを特徴とする方法。
2. 前記メッセージが前記ポリシー設定に適合すると判定された（ｓ３０）場合に、前記要求トークンに関連する前記サービスプロバイダ（４００）へ前記要求トークンが転送されることを許可するステップ（ｓ３２）
   を更に備えることを特徴とする請求項１に記載の方法。
3. 前記メッセージが前記ポリシー設定に適合するか否かを判定する前記ステップ（ｓ２０）は、
   前記要求トークンの発信元である前記コンシューマ（３００）に関する情報と、
   １以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
   前記要求トークンを通じて許可を要求される前記１以上の操作に関する情報と、
   のうちの少なくとも１つを前記メッセージから抽出するステップ（ｓ２２）と、
   前記抽出された情報が前記ポリシー設定に適合するか否かを判定するステップ（ｓ２４）と、
   を含む
   ことを特徴とする請求項１又は２に記載の方法。
4. 少なくとも１つのサービスプロバイダ（４００）から、前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースに関する情報を取得するステップ
   を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースに関する前記情報は、前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースの利用に関する情報を含む
   ことを特徴とする請求項４に記載の方法。
6. 受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
   受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
   受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
   受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
   のうちの少なくとも１つに関する、履歴情報と呼ぶ情報を記録するステップと、
   前記履歴情報をユーザ端末（２００）が入手できるようにするステップと、
   を更に備えることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記コントローラ（１００）と通信可能なユーザ端末（２００）が追加的に実行する、請求項１乃至６のいずれか１項に記載の方法であって、
   前記ユーザ端末（２００）が、前記コントローラ（１００）の中の前記ポリシー設定を設定するステップ
   を更に備えることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. コントローラ（１００）であって、
   要求トークンを含むメッセージを受信するように構成された受信器（１１０）を備え、
   要求トークンは、サービスプロバイダ（４００）の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ（３００）によって使用される値であり、
   サービスプロバイダ（４００）は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
   コンシューマ（３００）は、ユーザの代わりにサービスプロバイダ（４００）にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
   前記コントローラは更に、
   前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するように構成された判定器（１２０）と、
   前記メッセージが前記ポリシー設定に適合しないと判定された場合に、前記要求トークンに関連する前記サービスプロバイダ（４００）へ前記要求トークンが転送されることを阻止するように構成された転送器（１３０）と、
   を備えることを特徴とするコントローラ（１００）。
9. 前記転送器（１３０）は更に、前記メッセージが前記ポリシー設定に適合すると判定された場合に、前記要求トークンに関連する前記サービスプロバイダ（４００）へ前記要求トークンが転送されることを許可するように構成される
   ことを特徴とする請求項８に記載のコントローラ（１００）。
10. 前記判定器（１２０）は更に、
    前記メッセージが前記ポリシー設定に適合するか否かを判定することが、
    前記要求トークンの発信元である前記コンシューマ（３００）に関する情報と、
    １以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
    前記要求トークンを通じて許可を要求される前記１以上の操作に関する情報と、
    のうちの少なくとも１つを前記メッセージから抽出することと、
    前記抽出された情報が前記ポリシー設定に適合するか否かを判定することと、
    を含むように構成される
    ことを特徴とする請求項８又は９に記載のコントローラ（１００）。
11. 少なくとも１つのサービスプロバイダ（４００）から、前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースに関する情報を取得するように構成された取得器
    を更に備えることを特徴とする請求項８乃至１０のいずれか１項に記載のコントローラ（１００）。
12. 前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースに関する前記情報は、前記少なくとも１つのサービスプロバイダ（４００）におけるユーザのＩＤに関連する前記保護リソースの利用に関する情報を含む
    ことを特徴とする請求項１１に記載のコントローラ（１００）。
13. 受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
    受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
    受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
    受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
    のうちの少なくとも１つに関する、履歴情報と呼ぶ情報を記録するように構成された記録器と、
    前記履歴情報をユーザ端末（２００）が入手できるようにする開示器と、
    を更に備えることを特徴とする請求項８乃至１２のいずれか１項に記載のコントローラ（１００）。
14. 請求項８乃至１３のいずれか１項に記載のコントローラ（１００）と、
    前記コントローラ（１００）と通信可能なユーザ端末（２００）と、
    を備え、
    前記ユーザ端末（２００）は、前記コントローラ（１００）の中の前記ポリシー設定を設定するように構成される
    ことを特徴とするシステム。
15. コントローラ（１００）において実行された場合に、前記コントローラ（１００）に、請求項１乃至７のいずれか１項に記載の方法を実行させるように構成された命令を含んだコンピュータプログラム。

Images