JP2012528365A - プライベートデジタルコンテンツにアクセスするためのシステムおよび方法 - Google Patents

Abstract

所有者によって所有され、コンテンツサーバにインストールされたプライベートデジタルコンテンツにアクセスできるようにするための方法であり、コンテンツ管理サーバは、プライベートコンテンツに興味を持つ可能性があるいくつかのクライアントを有し、この方法は、所有者がコンテンツサーバにプライベートコンテンツをインストールしたことを知らされたコンテンツ管理サーバにおいて行われる次のステップ、すなわち、コンテンツサーバからデリゲートトークンを取得するステップ、コンテンツ管理サーバのいくつかのクライアントのうちの１つのクライアントからプライベートデジタルコンテンツのクエリを受信するステップ、デリゲートトークンを使用して上記クライアントにトークンを提供し、クライアントがプライベートコンテンツにアクセスできるようにするステップを含む。

Description

本発明は、プライベートデジタルコンテンツにアクセスするためのシステムおよび方法、コンテンツ管理サーバ、セキュリティ保護されたコンテンツサーバ、およびセキュリティ保護された通信のための方法に関する。

ウェブ上の複数の当事者の間でユーザのクレデンシャルを扱うためのオープン認証（ＯＡｕｔｈ）プロトコル（ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｌｉｃｅｎｓｅ／ｃｏｒｅ／１．０で入手できるＯＡｕｔｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ １．０参照）がある。さらに、前述のＯＡｕｔｈシステムと同様に、ウェブエンティティ間のコンテンツ共有を可能にするいくつかのトークンベースの共有ソリューションがある。例えば、Ｆａｃｅｂｏｏｋ、Ｆｌｉｃｋｒ、Ｇｏｏｇｌｅ、ＳｍｕｇｍｕｇおよびＰｈｏｔｏｂｕｃｋｅｔは、すべて認証にトークンを使用する。

ＯＡｕｔｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ １．０、ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｌｉｃｅｎｓｅ／ｃｏｒｅ／１．０ 「Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ）Ｐｒｏｔｏｃｏｌ」、ＲＦＣ４３４６

本発明の諸実施形態によれば、プライベートコンテンツの所有者にとって便利であり、しかも十分なセキュリティを確保する、プライベートコンテンツを共有するための改善された方法およびシステムが提供される。

本発明の一実施形態によれば、所有者によって所有され、コンテンツサーバ上にインストールされたプライベートデジタルコンテンツにアクセスできるようにするための方法が提供され、コンテンツ管理サーバが、プライベートコンテンツに興味を持つ可能性のあるいくつかのクライアントを有し、この方法は、コンテンツ管理サーバで行われる次のステップ：
− 所有者がコンテンツサーバにプライベートコンテンツをインストールしたことを知らされるステップ
− コンテンツサーバからデリゲートトークンを取得するステップ
− コンテンツ管理サーバのいくつかのクライアントのうちの１人のクライアントから、プライベートデジタルコンテンツを求めるクエリを受信するステップ
− デリゲートトークンを使用して上記クライアントにトークンを提供し、クライアントがプライベートコンテンツにアクセスできるようにするステップ、を含む。

本発明との関連におけるコンテンツ管理サーバは、広義では例えば写真、ビデオなどのような、複数のユーザのパブリックデジタルコンテンツ、および／またはプライベート共有デジタルコンテンツ、および／またはプライベート非共有デジタルコンテンツを管理することができるいかなるサーバも指すと解釈されなければならない。コンテンツ自体は、ローカルに、またはリモート位置に格納されることが可能である。このようなコンテンツ管理サーバの例は、Ｆｌｉｃｋｒ、ＹｏｕｔＴｕｂｅなどのようなコンテンツプロバイダ、ＰｅＣＭａｎ、ＳｅｃｏｎｄＢｒａｉｎ、ｉＧｏｏｇｌｅのようなコンテンツアグリゲータ、任意タイプの所有者のプロキシ、選択的プロキシ機能を備えたプロキシなどによって使用されるような、単純なコンテンツ管理サーバである。このようなコンテンツ管理サーバの好ましい実施形態は、コンテンツのタグ付けを可能にするように構成される。

本発明との関連におけるコンテンツサーバは、一般に、セキュリティ保護されたコンテンツサーバを指し、例えばセキュリティ保護されたウェブサーバであることが可能である。他の例は、ファイル共有機能を有するローカルディスク、コンテンツサーバとして機能するようにサーバプログラムをインストールしたコンピュータなどである。

本発明との関連におけるトークンは、トークンの要求者のいくつかのクレデンシャルを確認する際に生成される値である。この値は、一般には、コンテンツサーバによってランダムに生成されるいくつかの文字の列である。

本発明の好ましい実施形態によれば、デリゲートトークンは、プライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するために使用される。コンテンツ管理サーバによるデリゲートトークンの取得は、例えば：
− コンテンツサーバから第１のトークンＴ１を取得する
− 所有者が第１のトークンを認可するように要求する
− 認可された第１のトークンを受信する
− コンテンツサーバを介して、認可された第１のトークンを第２のトークンＴ２と取り換えるよう要求し、上記第２のトークンＴ２がデリゲートトークンを形成すること、を含む。第１のトークンは、一般にはいわゆるリクエストトークンであり、所有者からの認可を得るためにクライアント（ここではコンテンツ管理サーバ）によって使用される値であって、所有者のコンテンツサーバのクレデンシャルを使用する代わりに、所有者に代わって保護されたコンテンツへのアクセス権を獲得するためにクライアント（コンテンツ管理サーバ）によって使用される、一般にアクセストークンと呼ばれる第２のトークンと交換されることが可能である。

考えられる実施形態によれば、デリゲートトークンを使用して上記クライアントにトークンを提供することは、コンテンツ管理サーバによって行われる次のステップ：
− デリゲートトークンをクライアントのアクセストークンＴ３と交換するための要求をコンテンツサーバに送信するステップ
− アクセストークンＴ３を受信するステップ
− アクセストークンＴ３をクライアントに転送するステップ、を含む。新しく作成されたアクセストークンＴ３は、一般にはデリゲートトークンによって許可されるものと同等以下の権利を有することができる。この方法の利点は、クライアントがコンテンツサーバに登録される必要がないことである。

代替的実施形態によれば、デリゲートトークンを使用して上記クライアントにトークンを提供することは、コンテンツ管理サーバによって行われる次のステップ：
− クライアントからリクエストトークンＴ４を受信するステップ
− デリゲートトークンを使用して上記トークンを認可するステップ
− 上記の認可されたリクエストトークンＴ４をクライアントに送信し、コンテンツサーバを介してクライアントがこの認可されたリクエストトークンをアクセストークンＴ５と変えられるようにするステップ、を含む。

本発明の別の態様によれば、コンテンツ管理サーバのクライアントによってプライベートデジタルコンテンツを取得するための方法が提供され、このプライベートコンテンツは、所有者によって所有され、コンテンツサーバにインストールされ、クライアントによって行われる次のステップ：
− デジタルプライベートコンテンツと関連するデリゲートトークンを有するコンテンツ管理サーバにプライベートデジタルコンテンツを取得するための要求を送信するステップ
− デリゲートトークンを使用して生成されたコンテンツ管理サーバからのトークンを取得し、クライアントがプライベートデジタルコンテンツにアクセスできるようにするステップ
− プライベートデジタルコンテンツにアクセスするステップ、を含む。

第１の例によれば、コンテンツ管理サーバからトークンを取得することは、コンテンツサーバを介してデリゲートトークンに基づいてコンテンツ管理サーバによってあらかじめ取得されたアクセストークンＴ３を取得することにあることが可能である。

第２の例によれば、コンテンツ管理サーバからトークンを取得することは、クライアントによって行われる次のステップ：
− コンテンツサーバにトークンの要求を送信するステップ
− コンテンツサーバからリクエストトークンＴ４を受信するステップ
− 認可されるように、受信したリクエストトークンをコンテンツ管理サーバに送信するステップ
− デリゲートトークンを使用してコンテンツ管理サーバによって認可されたリクエストトークンを受信するステップ
− この認可されたリクエストトークンをコンテンツサーバに送信するステップ
− コンテンツサーバからアクセストークンＴ５を受信し、クライアントがプライベートコンテンツにアクセスできるようにするステップ、を含む。

本発明のさらに別の態様によれば、所有者によって所有され、コンテンツサーバにインストールされたプライベートデジタルコンテンツへアクセスできるようにするための方法が提供され、コンテンツサーバで行われる次のステップ：
− ユーザによって認可される、コンテンツ管理サーバに対するデリゲートトークンを生成するステップ
− 上記デリゲートトークンをコンテンツ管理サーバに送信するステップ、を含む。

好ましい実施形態によれば、この方法の諸ステップを行うために、１つまたは複数の標準的なオープン認証コールが使用される。

本発明のシステムの一実施形態によれば、システムは、コンテンツサーバに格納されたデジタルプライベートコンテンツを所有している第１のクライアント、およびいくつかの第２のクライアントを有するコンテンツ管理サーバを含み、コンテンツ管理サーバは、デジタルプライベートコンテンツと関連するデリゲートトークンをコンテンツサーバから取得し、デリゲートトークンを使用して第２のクライアントにトークンを配布し、第２のクライアントがデジタルプライベートコンテンツにアクセスできるように構成され、
第２のクライアントは、デジタルプライベートコンテンツへのアクセス権を取得するために、配布されたトークンをコンテンツサーバに提示するように構成される。

好ましい実施形態によれば、第１のクライアントはさらに、コンテンツサーバを介してコンテンツ管理サーバから受信したリクエストトークンを認可するように構成される。コンテンツ管理サーバは、次に認可されたリクエストトークンを受信し、上記の認可されたリクエストトークンを使用してデリゲートトークンを取得するように構成されることが可能である。

本発明の別の態様によれば、複数のクライアントのプライベートデジタルコンテンツをまとめるためのコンテンツ管理サーバが提供され、第１のクライアントがコンテンツサーバに格納されたデジタルプライベートコンテンツを所有し、上記コンテンツ管理サーバが、所有者クライアントのデジタルプライベートコンテンツと関連するデリゲートトークンをコンテンツサーバから取得して、このデリゲートトークンを使用して第２のクライアントにトークンを配布し、第２のクライアントが所有者クライアントのプライベートコンテンツにアクセスできるように構成される。例示的な実施形態によれば、コンテンツ管理サーバは、ＰｅＣＭａｎサーバのようなコンテンツアグリゲータである。

さらに発展した実施形態によれば、コンテンツ管理サーバはさらに、デリゲートトークンと比較されるとき同等以下のアクセス権を有するプライベートコンテンツに関連するトークンを、クライアントに提供するように構成される。

本発明のさらに別の態様によれば、
− 所有者によって認可されたリクエストトークンをコンテンツ管理サーバから受信する、
− この認可されたリクエストトークンをデリゲートトークンと交換する、
− デリゲートトークンをコンテンツ管理サーバに送信する、
ように構成された、所有者のプライベートデジタルコンテンツを格納するセキュリティ保護されたウェブサーバのようなコンテンツサーバが提供される。

最後に本発明は、プログラムがコンピュータ上で実行されるとき、本発明の方法のいずれかを実行するためのコンピュータ実行可能命令を含むコンピュータプログラム製品に関する。

本発明の一実施形態によれば、ＰｅＣＭａｎサーバ、ユーザプロキシまたは他の任意の適切なエンティティのような、管理サーバにデリゲーショントークンを配布するための支援によって拡張されるオープン認証プロトコル方法が提供される。こうしたデリゲーショントークンは、プライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するために使用される。このように、第２のクライアントがプライベートコンテンツへのアクセスを要求するたびに、所有者がプライベートコンテンツのウェブサーバに所有者のクレデンシャルを提示しなければならないのではなく、所有者が介入することなく、管理サーバによってデリゲーショントークンが提供されることが可能である。所有者は、管理サーバがデリゲートトークンを取得するとき、１度介入するだけでよい。利点は、第２のクライアントが、所有者のユーザクレデンシャルを保有せずにプライベートコンテンツにアクセスできることである。ＰｅＣＭａｎでこの方法が適用されるとき、ＰｅＣＭａｎサーバは、従来技術の方法のようにプライベートコンテンツを共有するためのプロキシ機能を必要としない。

本発明の一実施形態によれば、ＯＡｕｔｈプロトコル方式は、ＰｅＣＭａｎのようなコンテンツマネージャまたはユーザプロキシがコンテンツ所有者を代表することができるように、認証デリゲーション動作を用いて拡張された。したがって、クライアントがストレージプロバイダにプライベートコンテンツを格納するとき、クライアントは、ＵＲＬと共に格納される長期デリゲーショントークンの生成を計画する。プライベートデータがコンテンツマネージャを介して共有されることになる場合、このデリゲーショントークンがＯＡｕｔｈプロトコルで使用されて、リクエストトークンを認証することが可能である。

本発明の別の実施形態によれば、ＰｅＣＭａｎサーバまたはユーザプロキシのような、プライベートコンテンツ用のデリゲーショントークンを保有するコンテンツ管理サーバが提供される。考えられる実施形態によれば、コンテンツ管理サーバは、第２のクライアントからのリクエストトークンを認可するように構成され、リクエストトークンを用いてこの第２のクライアントは、プライベートコンテンツの位置、例えばセキュリティ保護されたウェブサイトなどにあるデータに、所有者のさらなる介入なしに、アクセスすることができる。

本発明の一実施形態によれば、コンテンツの所有者から、ＰｅＣＭａｎサーバまたは所有者のプロキシなどコンテンツ管理サーバへ認証権限を委任するための支援を有する拡張されたＯＡｕｔｈプロトコルを使用するシステムが提供される。より詳細には、コンテンツの所有者は、ウェブサーバの認証の責任をコンテンツ管理サーバに委譲することができ、したがって、コンテンツ所有者は、自身を認証させる必要がなく、コンテンツが友人、仲間、もしくはその他興味を持つ仲間と共有されるとき、居合わせている必要もない。

本発明の一実施形態によれば、認証権限を委譲するためのプロシージャで拡張されたＯＡｕｔｈプロトコルを使用する方法が提供され、コンテンツ所有者、プライベートコンテンツサーバ、およびコンテンツ管理サーバとの間で共有されることになるデリゲーショントークンの概念を含む。第２のクライアントがプライベートコンテンツにアクセスする必要があるとき、コンテンツ管理サーバは、コンテンツの所有者がコンテンツ管理サーバにその代表をする権限を与えたことの証明としてそのデリゲーショントークンを提示することができる。一般には、コンテンツ管理サーバは、もとのコンテンツ所有者のプロキシとして機能することになる。

さらなる実施形態によれば、新しいＯＡｕｔｈデリゲーションメカニズムは、コンテンツ管理サーバが、コンテンツ管理サーバを介して共有されるコンテンツにその独自のアクセス制御ポリシーを実施することができることを意味する。デリゲーショントークンは、一定のアクセス権を有するプライベート共有コンテンツへのアクセスを可能にする。考えられる実施形態によれば、コンテンツ管理サーバは、こうしたアクセス権を制限するように構成される。

添付の図面を使用して、本発明の現在の好ましい限定ではない例示的諸実施形態を例示する。添付の図面と併せて読まれるとき、次の詳細な説明から、本発明の上記のおよび他の有利な特徴および目的はより明らかになり、本発明はよりよく理解されるであろう。

ＰｅＣＭａｎアーキテクチャの概略図である。 ＰｅＣＭａｎサーバを委任するための本発明の方法の第１の実施形態によるコールフローを示す図である。 第２のＰｅＣＭａｎクライアントによりプライベートコンテンツを取り出すための本発明の方法の第１の実施形態によるコールフローを示す図である。 第２のＰｅＣＭａｎクライアントによりプライベートコンテンツを取り出すための本発明の方法の第２の実施形態によるコールフローを示す図である。 プライベートコンテンツを取り出すための本発明の方法の第３の実施形態によるコールフローを示す図である。 ＰｅＣＭａｎサーバを委任するための本発明の方法の第２の実施形態によるコールフローを示す図である。 第２のＰｅＣＭａｎクライアントによりプライベートコンテンツを取り出すための本発明の方法の第４の実施形態によるコールフローを示す図である。 ＰｅＣＭａｎサーバを委任するための本発明の方法の第３の実施形態によるコールフローを示す図である。 プライベートコンテンツを取り出すための本発明の方法の第５の実施形態によるコールフローを示す図である。

本発明について、コンテンツ管理サーバとしてＰＥｒｓｏｎａｌ Ｃｏｎｔｅｎｔ ＭＡＮａｇｅｍｅｎｔ （ＰｅＣＭａｎ）サーバを参照して以下に説明するが、本発明は、上に定義するように、いかなるタイプのコンテンツ管理サーバ（所有者のプロキシを含む）にも適用できることを当業者には理解されるであろう。ＰｅＣＭａｎは、文書、画像、映像などユーザのデジタルコンテンツをまとめるウェブツールである。図１は、ＰｅＣＭａｎアーキテクチャの概略図を示す。ユーザは、クライアントコンポーネント３（例えば、ウェブクライアント、デスクトップクライアント、またはＰＤＡ上のクライアントなど）を使用してシステム１と対話し、これによってユーザは、例えば文書を追加する、削除する、またはタグ付けすることができる。クライアント２からの受信要求は、サーバコンポーネント４によって受信されて、システム１によって処理される。システムは、文書から抜き出された、またはタグの形式でユーザが生成したメタデータを格納するためのメタデータセクション５をさらに含む。サーバコンポーネント４は、さらにいくつかの第三者サーバ７の第三者サービス８と通信することができる。

ユーザは、例えばＰｅＣＭａｎにＵＲＬをアップロードし、フリー形式のタグで情報を意味的にタグ付けし、その後同じタグでＰｅＣＭａｎに問い合わせることによってその情報を再び見つけることができる。複数のＵＲＬが同じタグでタグ付けされることが可能であるので、ＰｅＣＭａｎによりユーザは、「仮想ドライブ」と同類の１つの論理的場所を通して、大量のストレージプロバイダ（例えば、ウェブサーバ、ホームストア、またはメールサーバ）に保存されているすべてのオブジェクトをまとめることができるようになる。

ＰｅＣＭａｎは、パブリックコンテンツ、プライベート非共有コンテンツ、およびプライベート共有コンテンツという３種類の基準を認識する。パブリックコンテンツは、公に利用できるウェブソースを指すＵＲＬである。このようなコンテンツにアクセスするには、ユーザのクレデンシャルを必要とせず、このようなコンテンツをこのコンテンツに興味がある誰とでも容易に共有できることを意味する。ユーザ間でパブリック情報が共有されるとき、ＰｅＣＭａｎは単に要求されたＵＲＬを直接送信する、すなわち第２のＰｅＣＭａｎクライアントに直接送信し、第２のＰｅＣＭａｎクライアントは、例えばＷｅｂＤＡＶまたはＨＴＴＰを通してコンテンツを取り出す。

プライベートコンテンツは、一般的に、保護された場所、典型的にはセキュリティ保護されたウェブサイト（すなわちストレージプロバイダ）を介してアクセスされることのみが可能であるコンテンツである。セキュリティ保護されたストレージプロバイダ７にアクセスするために、ウェブクライアント３は、例えばＳＳＬ／ＴＬＳを介してセキュリティ保護された通信を確立し、その後ユーザを認証するためにユーザクレデンシャル（典型的にはユーザＩＤおよびパスワード）を提供する。ユーザが認証された後、ウェブクライアント３は、プライベートに格納されたコンテンツにアクセスすることができる。一般には、アドレス指定されたウェブサーバ７内に、通信チャネルと関連するステート（ｓｔａｔｅ）が割り当てられる。このステートは、要求中のウェブクライアント３が認証したことをウェブサーバ７に示す。

従来の技術によれば、プライベート非共有および共有コンテンツに対応するために、一般にＰｅＣＭａｎは、指示されるＵＬＲと共にユーザクレデンシャルを格納する。プライベートコンテンツがアドレス指定されている場合、第２のＰｅＣＭａｎクライアント３は、ＰｅＣＭａｎ１への通信チャネルをセットアップし、その後、第２のＰｅＣＭａｎクライアントのためにストレージプロバイダ７への通信を確立する、すなわちＰｅＣＭａｎサーバ４は、第２のＰｅＣＭａｎクライアント３のプロキシとして働く。このプロキシは、ウェブサーバ７へのセキュリティ保護された通信を維持し、また、ストレージプロバイダ７にユーザクレデンシャルを提供するものである。ＰｅＣＭａｎは、共有プライベートコンテンツ基準と非共有プライベートコンテンツ基準の両方に対してこれを行う。

プライベートコンテンツについてＰｅＣＭａｎでデータ共有を行うこの方法の好ましくない面は、指示されるオブジェクトと関連するすべてのデータがＰｅＣＭａｎプロキシを介して送信されることである。これは、プライベートコンテンツにアクセスすることに関して、ＰｅＣＭａｎがボトルネックとなる可能性があること、またＰｅＣＭａｎを介するデータ伝送と料金が関連する場合、ＰｅＣＭａｎ事業者は、プライベートコンテンツを提供するために高額の料金を負担する可能性があることを意味する。さらに、ウェブクライアントの領域においてプロキシを実行することは、ユーザのユーザクレデンシャルが第２のＰｅＣＭａｎクライアントと共有される必要があることを意味するので、一般的にオプションではない。

オープン認証（ＯＡｕｔｈ）は、ウェブ上の複数の当事者の間でユーザクレデンシャルを扱うためのオープンプロトコル（ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｌｉｃｅｎｓｅ／ｃｏｒｅ／１．０で入手できるＯＡｕｔｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ １．０参照）である。

本発明の一実施形態によれば、ＯＡｕｔｈは、プライベートコンテンツのプロバイダと第三のエンティティとの間でプライベートデータを共有するために使用され、したがって第３のエンティティは、図２および３に示すトークンベースの認証機構によってユーザクレデンシャルを知る必要がなく、ユーザのプライベートデータにアクセスすることができる。

本発明の方法の一実施形態の第１のステージでは、ＰｅＣＭａｎサーバがコンテンツ所有者を代表することを認可するための例示的デリゲーションプロシージャを示す、図２のコールフローで示すように、ＰｅＣＭａｎサーバのようなコンテンツ管理サーバによってデリゲートトークンが取得される。ＰｅＣＭａｎサーバは、プライベートコンテンツサーバ、ここではセキュリティ保護されたウェブサーバＷＳのクライアントとして機能することになる。

開始段階Ｉでは、ＰｅＣＭａｎサーバは、ウェブサーバＷＳとセキュリティ保護された接続を確立し、これらの間でコンシューマキーＣｋおよびシークレットキーＣｓが確立される、矢印２００参照。また、所有者Ｏは、ウェブサーバＷＳ上に直接プライベートコンテンツｘｙｚをインストールする、矢印２００参照。一般には、所有者は、ユーザ名およびパスワードを使用してセキュリティ保護されたウェブサーバにログインすることになり、その結果、プライベートコンテンツｘｙｚをインストールできる。次に所有者Ｏは、保護されたウェブサーバ上にプライベートコンテンツｘｙｚをインストールしたことをＰｅＣＭａｎサーバに通知する、矢印２０２参照。インストールされたプライベートコンテンツに関して通知されると、ＰｅＣＭａｎサーバはトークンを要求し、コールフローのステージＡにおいてこのトークンを所有者に認証させる。まずＰｅＣＭａｎサーバは、ウェブサーバＷＳからトークンを要求する、矢印２０６参照。これは、次のパラメータを含む標準的なＯＡｕｔｈリクエストコールとすることが可能である：コンシューマキーＣｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ１（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）およびノンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）。署名Ｓ１は、例えばＣｓを使用して作成されることが可能である。一般的にはクライアントは、まずタイムスタンプを生成し、次いで各要求に一意であるノンス値が生成される。ウェブサーバＷＳは、次いでトークンＴ１（ｏａｕｔｈ＿ｔｏｋｅ）およびトークンシークレットＴｓ１（ｏａｕｔｈ＿ｔｏｋｅｎ＿ｓｅｃｒｅｔ）を生成し、これらをＰｅＣＭａｎサーバに送信する、ステップ２０４参照。次にＰｅＣＭａｎサーバは、所有者をウェブサーバＷＳに向けることによって所有者からの同意を得るために所有者にリダイレクトメッセージを送信する（ステップ２０５）。これは、トークンＴ１とウェブサーバが所有者をＰｅＣＭａｎサーバにリダイレクトするために使用するＵＲＬであるコールバックＵＲＬ Ｃとを含む、ウェブサーバのユーザ認証ＵＲＬへの標準的なＯＡｕｔｈリクエスト「ＷＳ：／／ａｕｔｈ？」とすることができる。認証要求は、次にウェブサーバに通され（ステップ２０６）、ウェブサーバはトークンＴ１を認証し、一般にはＰｅＣＭａｎサーバのＩＤを確認し、所有者に承諾を求める（ステップ２０７）。例えば、プライベートコンテンツプロバイダ（ウェブサーバＷＳ）へのセキュリティ保護された接続が確立され、ＰｅＣＭａｎのクレデンシャルを提供し、トークンをセキュリティ保護された接続と関連付けることによってログインする。ＰｅＣＭａｎサーバは、次いで所有者Ｏによって、コールバックＵＲＬを使用してトークンＴ１が認可されたことを、例えば標準的なＯＡｕｔｈコールを使用して知らされる（ステップ２０８）。

ＰｅｃＭａｎサーバは、次に第１のトークンＴ１を使用して第２のトークンを要求する（ステップ２１０）。これは、例えば、リクエストトークンを次のパラメータを有するアクセストークンと交換するために標準的なＯＡｕｔｈリクエストを使用して行われることが可能である：コンシューマキーＣｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、以前取得されたトークンＴ１（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ２（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびノンスＮ（ｏａｕｔｈ ｎｏｎｃｅ）。署名Ｓ２は、例えばＣｓおよびＴｓ１に基づいて計算されることが可能である。応答では、第２のトークンＴ２およびトークンシークレットＴｓ２がウェブサーバＷＳによって与えられる（ステップ２１０）。この第２のトークンＴ２は、図３および４で説明するように、第２のクライアント（訪問者）に所有者のプライベートコンテンツへのアクセス権を与えるためのデリゲートトークンとして機能することができる。

プライベートコンテンツｘｙｚは、トークンＴ２をＷｅｂサーバＷＳに提供することによって、ＰｅＣＭａｎサーバによって取得されることも可能である、図２のコールフローのステージＣ参照。これは、例えば次のパラメータを含む標準的なアクセス要求が行われることが可能である：コンシューマキーＣｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、トークンＴ２（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ３（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）およびノンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）。署名Ｓ３は、例えばＣｓおよびＴｓ２を使用して計算されることが可能である。Ｔ２は単に、所有者の妨げになることなく第２のクライアントに所有者のプライベートコンテンツへのアクセス権を与えるデリゲートトークンとして使用されることも可能であるので、ステージＣのステップは、ＰｅＣＭａｎサーバによって必ずしも行われる必要がないことに注意する。

訪問者によってアクセストークンを取り出すための方法の第１の実施形態が、図３に示されている。第１のステップ３０１では、ＰｅＣＭａｎクライアントは、あるプライベートコンテンツへのアクセス権を取得するためにＰｅＣＭａｎサーバにクエリを送信する。このクエリに応答して、ＰｅＣＭａｎサーバは、例えば次のパラメータを有する要求を使用してウェブサーバにトークンリクエストメッセージを送信する：コンシューマキーＣｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、トークンＴ２（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ３（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）およびノンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）、アクセスＵＲＬ Ａｕ（Ａｃｃｅｓｓ＿ｕｒｌ）、アクセス権Ａｒ（Ａｃｃｅｓｓ＿ｒｉｇｈｔｓ）、アクセス期間Ａｔ（Ａｃｃｅｓｓ＿ｔｉｍｅＰｅｒｉｏｄ）、ならびにアクセスＩＰ Ａｉ（Ａｃｃｅｓｓ＿ＩＰ）。署名Ｓ３は、例えばＣｓおよびＴｓ２を使用して計算されることが可能である。アクセスＵＲＬは、一般に、取得されるデータｘｙｚを含んでいるある特定のディレクトリのような、プライベートデータの集まりを指す。アクセス権は、コンテンツに関連する権利（読み取り、変更など）である。期間は、トークンが有効である期間である。アクセスＩＰは、一般にオプションであって、訪問者のアドレスを指す。次のステップ３０２では、ウェブサーバは第３のトークンＴ３および対応するトークンシークレットＴｓ３をＰｅＣＭａｎサーバに与え、要求されたプライベートコンテンツｘｙｚはトークンＴ３およびトークンシークレットＴｓ３と関連付けられていることを訪問者に通知する（ステップ３０３）。訪問者は次に、ステップ３０４および３０５に示すようにプライベートデータｘｙｚを取得することができる。これは、例えば次のパラメータを含むアクセスリクエストを使用して行われることが可能である：アクセスＩＰ Ａｉ、トークンＴ３（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ４（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）およびノンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）。署名Ｓ４は、例えばＴｓ３を使用して計算される。

新しく作成されたトークンＴ３は、もとのトークンＴ２と比較されるとき、同等以下の権利を有することができる。これらの導出されたアクセストークンＴ３を用いて、第２のＰｅＣＭａｎクライアントは、所有者と対話する必要がなく、ウェブサーバから直接コンテンツを取得することができる。

上記実施形態の利点の１つは、コンテンツが共有される第２のクライアントは、ウェブサーバに登録される必要がないことである。ＰｅＣＭａｎサーバがトークンＴ３を第２のクライアント（訪問者）にさらに委譲できるようにすることによって、コンテンツは、ウェブサーバＷＳに登録されていないユーザと共有されることが可能であるが、コンテンツを完全公開にはしない。ＰｅＣＭａｎサーバの別の利点は、ウェブサーバのポリシーに加えて、ＰｅＣＭａｎサーバ自体のポリシーを実施できることである。この実施形態を用いるとＰｅＣＭａｎサーバは、所有者によって定義される粒度に基づき第２のユーザにある特定のウェブサービスを介してコンテンツを配布および委譲することができる。別のクライアントが所有者からコンテンツへのアクセスを要求するとき、ＰｅＣＭａｎサーバは、例えばクライアントのデータベースをチェックして、所有者がこの第２のクライアントと情報を共有しているかどうかを確認した後、導出されたアクセストークンＴ３を発行する。

図４は、委譲されたトークンによってプライベートコンテンツにアクセスするために第２のＰｅＣＭａｎクライアントによって行われるプロシージャの別の実施形態を示す。第２のＰｅＣＭａｎクライアント（訪問者）は、ＰｅＣＭａｎサーバを介してコンテンツを要求し（ステップ４００）、ＰｅＣＭａｎサーバは、コンテンツｘｙｚが保護されたウェブサーバＷＳを介して取り出し可能であることを表示する（ステップ４０１）。クライアントは、一般にまずセキュリティ保護されたコンテンツにアクセスしようとすることによって進行する、コンシューマキーおよびシークレットキーが確立されるステップ４０２およびコンテンツが要求されるステップ４０３を参照。しかしながら、コンテンツはトークンによってのみアクセスできるプライベートコンテンツであるので、ウェブサーバＷＳは認証失敗で応答する（ステップ４０４）。したがって、その後クライアントは、例えば、パラメータ、すなわちコンシューマキーＣｋ２（ｏａｕｔｈ ｃｏｎｓｕｍｅｒ ｋｅｙ）、署名方式Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ５（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびノンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）を有する標準的なＯＡｕｔｈリクエストを使用して、ウェブサーバからトークンＴ４を要求して取得する、ステップ４０６および４０７参照。署名は、例えばＣｓ２を用いて計算される。コンテンツに対してデリゲーショントークンが存在すると仮定し、リクエストトークンＴ４は、認証のためにＰｅＣＭａｎサーバに提供される（ステップ４０７）。ＰｅＣＭａｎサーバがクライアントのリクエストトークンと共に認証要求を受信するとき、ＰｅＣＭａｎサーバは、誰がコンテンツへのアクセス権を要求しているかを判断する。ＰｅＣＭａｎサーバがクライアントにアクセス権を与えることができる場合、そのデリゲーショントークンＴ２、デリゲーションシークレットＴｓ２を使用してアクセス権を認可する、ステップ４０８参照。ウェブサーバがデリゲーショントークンに基づいて認証要求を受信するとき、ウェブサーバはクライアントのリクエストトークンＴ４を認証する、ステップ４０９参照。このリクエストトークンＴ４は、その後要求中の第２のクライアントにＰｅＣＭａｎを介して返送される、ステップ４１０参照。要求中のクライアントは、認証されたリクエストトークンＴ４を受け取ると、標準的なＯＡｕｔｈプロシージャコール（ステップ４１１−４１４）を使用してプロシージャを完了し、クライアントは、認証されたリクエストトークンＴ４をアクセストークンＴ５と交換し（ステップ４１１および４１２）、メッセージは、例えばＣｓ２およびＴｓ４に基づいて計算された署名Ｓ６を用いて署名されることが可能である。実際のデータｘｙｚは、その後アクセストークンＴ５をウェブサーバＷＳに提供することによって取得されることが可能であり、ステップ４１３参照、その結果データｘｙｚは、クライアントＣに送信される、ステップ４１４参照。例えばＧＥＴメッセージ４１３は、Ｃｓ２およびＴｓ５に基づいて計算された署名で署名されることが可能である。

図５は、本発明の方法のより一般的な実施形態を示しており、クライアントならびにそれぞれ認証されて、あるコンテンツについてなんらかの権利を有する第１のサーバＳ１および第２のサーバＳ２は、それぞれのアクセストークン所持者（Ｓ２はＣから見た所持者であり、Ｓ１はＳ２から見た所持者であり、ＷＳはＳ１から見た所持者である）に、それぞれの第１および第２のサーバのデリゲートトークンと同等以下の権利を有して、別のアクセストークンを取得するよう求めることができる。サーバＳ１およびＳ２は、一般に共にコンテンツ管理サーバであり、例えば共にＰｅＣＭａｎサーバであることが可能である。Ｓ１は、ローカルウェブサイト上のコンテンツ管理サーバであることも可能である。この例は、訪問者が、サーバＳ２のクライアントであるサーバＳ２に問い合わせを行うことができることを示す。サーバＳ２は、要求されたコンテンツのデリゲートトークンを有し、コンテンツサーバＷＳからそのコンテンツのアクセストークンを取得することができる（ステップ５０３および５０４参照）。サーバＳ１は、その後、同等以下の権限を有するアクセストークンをサーバＳ２に送信することができ（ステップ５０５）、同じくサーバＳ２は、同等以下の権限を有するアクセストークンを訪問者に送信する（ステップ５０６）。図４に示す取り出し方法を使用して、同様の移行的な共有の実施形態が可能であることを当業者は理解するであろう。

図６は、図２のコールフローの変形を示しており、図２のトークンＴ１は、図６のトークンＴｒに対応し、トークンＴ２はトークンＴｄに対応する。ステップ６０１−６０３は、ステップ３０１−３０３に対応し、ＧＥＴまたはＰＯＳＴコールが使用されて、ＰｅｃＭａｎサーバにウェブサーバ上にインストールされたプライベートコンテンツを間接的に取り出すべきことを知らせる。ステップ６０３および６０４では、ＰｅｃＭａｎサーバはトンネル（例えば、ＴＬＳまたはｈｔｔｐｓ）を介してトークンＴｒを取得する。これらのコールは共に、例えば「Ｔｈｅ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ）Ｐｒｏｔｏｃｏｌ」というタイトルを有するＲＦＣ４３４６で規定されるＳＳＬ／ＴＬＳなど、セキュリティ保護された通信チャネルを通じて送信される。次にＰｅＣＭａｎサーバは、標準的なＯＡｕｔｈの手法と同様に、セキュリティ保護されたウェブサーバＷＳを通じてコンテンツの所有者にリクエストトークンを認証するよう要求する、ステップ６０５−６０６参照。所有者Ｏは、ウェブサーバＷＳにクレデンシャルを提供し、ウェブサーバＷＳは、リクエストトークンは現在有効であって認証されると記録するステートを割り当てる、ステップ６０６および６０７参照。最後に、ウェブサーバは、ＰｅＣＭａｎサーバを再び呼び出し、リクエストトークンがここで認証されたことを知らせる、ステップ６０８参照。ＰｅＣＭａｎサーバは、その後、ウェブサーバＷＳを通じて認証されたリクエストトークンをデリゲーショントークンと取り換えるよう要求する、ステップ６０９参照。ウェブサーバＷＳは、トンネルを介してＰｅＣＭａｎサーバにデリゲートトークン（Ｔｄ）、関連するシークレットデリゲートトークン（Ｔｄ＿ｓ）、およびノンス（Ｎｄ）を返す、ステップ６１０参照。最後に、ＰｅＣＭａｎサーバは、ステップ６１１において最初のＨＴＴＰ ＰＯＳＴリクエストに応答し（ステップ６０２）、委譲プロシージャの成功または失敗を識別する。ウェブサーバは、デリゲーショントークンＴｄ、その存続期間、およびコンテンツのもともとの所有者を格納する。このデリゲーショントークンＴｄは、ユーザのクレデンシャルに取って代わり、すなわちデリゲーショントークンＴｄの所持者は、あたかもコンテンツの所有者であるかのようにリクエストトークンを認証することができる。デリゲーショントークンＴｄで署名された「アクセスの要求」メッセージは、このアクセスの要求が委譲された権限に基づいていることをウェブサーバＷＳに示す。

別の実施形態によれば、最初の認証されたリクエストトークンは、デリゲーショントークンとして使用されることが可能である。しかしながら、通常、機能の違いを区別するために、別個のトークンを有することが好ましい。今日ＯＡｕｔｈでは、認証されたリクエストトークンＴｒだけがアクセストークンＴａと交換されることが可能であり、アクセスポリシーは、ウェブサーバＷＳによって設定される。そのデリゲーショントークンＴｄを有する認可委譲プロシージャは、コンテンツへのアクセスをさらに制限するために使用されることが可能である。

図７は、委譲されたトークンＴｄを介してプライベートコンテンツにアクセスするための図４のプロシージャ実施形態の変形を示す。ステップ７００−７０４は、ステップ４００−４０４と同様である。クライアントは、その後、次のパラメータ、すなわち共通キーＣｋ、シークレットキーＫｓ、およびノンスＮｒを用いてＴＬＳトンネルを介してウェブサーバＷＳからリクエストトークンＴｒを要求して取得する、ステップ７０５および７０６参照。コンテンツにデリゲートトークンＴｄが存在すると仮定すると、リクエストトークンＴｒは、認証のためにＰｅＣＭａｎサーバに提供される（ステップ７０７）。ＰｅＣＭａｎサーバが、クライアントのリクエストトークンと共に認証要求を受け取ると、ＰｅＣＭａｎサーバは誰がコンテンツへのアクセスを要求しているかを判断する。ＰｅＣＭａｎサーバがクライアントにアクセス権を与えることができる場合、次のパラメータを使用して生成される署名を使用してアクセスを認可する（強制アクセス制御、ＭＡＣ）：そのデリゲーショントークンＴｄ、デリゲーションシークレットＴｄ、およびノンスＮｄ、ステップ７０８参照。ＷｅｂサーバＷＳがデリゲーショントークンに基づいて認証要求７０８を受信するとき、ＷｅｂサーバはクライアントのリクエストトークンＴｒを認証する、ステップ７０９参照。このリクエストトークンＴｒは、その後要求中の第２のクライアントにＰｅＣＭａｎを介して返送される、ステップ７１０参照。要求中のクライアントは、認証されたリクエストトークンＴｒを受け取ると、標準的なＯＡｕｔｈプロシージャコールを使用してプロシージャを完了し（ステップ７１１−７１４）、クライアントは、ＴＬＳトンネルを介して認証されたリクエストトークンＴｒ＿ｓをアクセストークンＴａと交換する（ステップ７１１および７１２）。実際のデータｘｙｚは、その後、アクセストークンＴａをウェブサーバに（シークレットキーＫｓ、Ｔａ、トークンシークレットＴａ＿ｓ、およびノンスＮａを使用する署名の形態で）提供することによって取得される、ステップ７１４参照。

図８は、アクセストークン所持者がさらにトークンを委譲できるようにするための、図２の方法の変形を示しており、図２のトークンＴ１およびＴ１ｓはＴｒおよびＴｒ＿ｓに対応し、トークンＴ２およびＴ２ｓはＴａおよびＴａ＿ｓに対応する。この実施形態では、ＰｅＣＭａｎサーバは、所有者によってウェブサーバ上にあらかじめインストールされ、ＰｅＣＭａｎサーバに登録された（ステップ８０１−８０３）ある特定のコンテンツのアクセストークンを要求して取得するために、標準的なプロシージャコールを行うＯＡｕｔｈコンシューマとしてみなされることが可能である（ステップ８０３−８１０）。ＰｅＣＭａｎサーバが所有するアクセストークンＴａを用いて、さらにＰｅＣＭａｎサーバは、新規の第２のクライアントにアクセストークンを作成し、委譲することができる。この実施形態では、パラメータとして共通キーＣｋ、シークレットキーＫｓ、およびノンスＮｒを使用してトークンを要求して交換するためにｈｔｔｐｓトンネルが使用される。

第２のクライアントによってアクセストークンを取り出すための方法のさらなる実施形態は、図９に示す。この実施形態は、図３の実施形態と同様であり、ステップ９００−９０５は、ステップ３００−３０５と同様であり、トークンＴ３はアクセストークンＡｔに対応する。図９の実施形態では、ｈｔｔｐｓトンネルは、パラメータとして共通キーＣｋ、シークレットキーＫｓ、およびノンスＮｒを使用してトークンを要求し、交換するために使用される。図２のトークンシークレットＴｓ３を用いて動作する代わりに、図９の実施形態は、必要なセキュリティを提供するために、次のパラメータセットに基づいた署名（ＭＡＣ）を使用する：Ａｔ、Ｃｋ、Ｋｓ、およびノンスＮａ。新規に作成されたアクセストークンＡｔは、ＰｅＣＭａｎによって取得された元のアクセストークンＴａと比べると、同等以下の権利を有することができる（図８参照）。これらの導出されたアクセストークンＡｔを用いて、第２のＰｅＣＭａｎクライアントは、所有者Ｏと対話する必要がなく、ＷｅｂサーバＷＳから直接コンテンツを取得することができる。

様々な上述の方法の諸ステップは、プログラムを組み込まれたコンピュータによって実行されることが可能であることを、当業者は容易に理解するであろう。本明細書では、いくつかの実施形態はまた、例えばデジタルデータ記憶媒体など、プログラム記憶装置を含むものとし、これはマシンまたはコンピュータ可読であって、命令のマシン実行可能もしくはコンピュータ実行可能プログラムをエンコードし、上記命令が上述の方法のステップの一部または全部を行う。プログラム記憶装置は、例えば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光学式可読デジタルデータ記憶媒体であることが可能である。諸実施形態はまた、上述の方法の上記諸ステップを実行するようにプログラムされたコンピュータを含むものとする。

本発明の原理を特定の実施形態に関して上述したが、この説明は単に一例として行われ、添付の特許請求の範囲で決定される保護の範囲を制限するものではないことは、明確に理解されるであろう。

Claims (15)

1. 所有者によって所有され、コンテンツサーバにインストールされたプライベートデジタルコンテンツへアクセスできるようにするための方法であって、コンテンツ管理サーバが、プライベートコンテンツに興味を持つ可能性のあるいくつかのクライアントを有し、コンテンツ管理サーバで行われる次のステップ、すなわち、
   所有者がコンテンツサーバにプライベートコンテンツをインストールしたことを知らされるステップ（２０２、６０２、８０２）と、
   プライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するために使用されるデリゲートトークンを、コンテンツサーバから取得するステップ（２０３−２１０）、（６０３−６１０）、（８０３−８１０）と、
   コンテンツ管理サーバのいくつかのクライアントのうちの１つのクライアントから、プライベートデジタルコンテンツを求めるクエリを受信するステップ（３００、４００、７００）と、
   デリゲートトークンを使用して前記クライアントにトークンを提供し、クライアントがプライベートコンテンツにアクセスできるようにするステップ（３０１−３０３）、（４０７−４１０）、（７０８−７１０）、（９０１−９０３）と
   を含む、方法。
2. コンテンツ管理サーバによってデリゲートトークンを取得することが、
   コンテンツサーバから第１のトークンを取得するステップ（２０３−２０４）、（６０３−６０４）、（８０３−８０４）と、
   所有者に第１のトークンを認可するよう要求するステップ（２０５）、（６０５）、（８０５）と、
   認可された第１のトークンを受信するステップ（２０８）、（６０８）、（８０８）と、
   コンテンツサーバを介して、認可された第１のトークンを第２のトークンと取り換えるよう要求し（２０９−２１０）、（６０９−６１０）、（８０９−８１０）、前記第２のトークンがデリゲートトークンを形成するステップと
   を含む、請求項１に記載の方法。
3. デリゲートトークンを使用して前記クライアントにトークンを提供することが、コンテンツ管理サーバによって行われる次のステップ、すなわち、
   デリゲートトークンをクライアントのアクセストークンと交換するための要求をコンテンツサーバに送信するステップ（３０１）、（９０１）と、
   アクセストークンを受信するステップ（３０２）、（９０２）と、
   アクセストークンをクライアントに転送するステップ（３０３）、（９０３）と
   を含む、請求項１または２に記載の方法。
4. デリゲートトークンを使用して前記クライアントにトークンを提供するステップが、コンテンツ管理サーバによって行われる次のステップ、すなわち、
   クライアントからリクエストトークンを受信するステップ（４０７）、（７０７）と、
   デリゲートトークンを使用して前記トークンを認可するステップ（４０８−４０９）、（７０８−７０９）と、
   前記認可されたリクエストトークンをクライアントに送信し（４１０）、（７１０）、コンテンツサーバを介してクライアントがこの認可されたリクエストトークンをアクセストークンと交換できるようにするステップ（４１１−４１２）、（７１１−７１２）と
   を含む、請求項１または２に記載の方法。
5. コンテンツ管理サーバのクライアントによってプライベートデジタルコンテンツを取得するための方法であって、プライベートコンテンツは所有者に所有され、コンテンツサーバにインストールされ、クライアントによって行われる次のステップ、すなわち、
   デジタルプライベートコンテンツと関連するデリゲートトークンを有するコンテンツ管理サーバにプライベートデジタルコンテンツを取得するための要求を送信するステップ（３００）、（４００）、（７００）であって、
   プライベートデジタルコンテンツの所有者の協力を得てデリゲートトークンが生成され、コンテンツの所有者を代表するように使用されるステップと、
   デリゲートトークンを使用して生成されたコンテンツ管理サーバからのトークンを取得し、クライアントがプライベートデジタルコンテンツにアクセスできるようにするステップ（３０３）、（４１０）、（７１０）と、
   プライベートデジタルコンテンツにアクセスするステップ（３０４−３０５）、（４１３−４１４）、（７１３−７１４）と
   を含む、方法。
6. コンテンツ管理サーバからトークンを取得するステップが、コンテンツサーバを介してデリゲートトークンに基づいてコンテンツ管理サーバによってあらかじめ取得されたアクセストークンを取得するステップにある、請求項５に記載の方法。
7. コンテンツ管理サーバからトークンを取得するステップが、クライアントによって行われる次のステップ、すなわち、
   コンテンツサーバにトークンの要求を送信するステップ（４０５）と、
   コンテンツサーバからリクエストトークンを受信するステップ（４０６）と、
   認可されるように、受信したリクエストトークンをコンテンツ管理サーバに送信するステップ（４０７）と、
   デリゲートトークンを使用してコンテンツ管理サーバによって認可されたリクエストトークンを受信するステップ（４０８−４１０）と、
   この認可されたリクエストトークンをコンテンツサーバに送信するステップ（４１１）と、
   クライアントがプライベートコンテンツにアクセスできるようにするコンテンツサーバからのアクセストークンを受信するステップ（４１２）と
   を含む、請求項５に記載の方法。
8. コンテンツ管理サーバのクライアントによってプライベートデジタルコンテンツへアクセスできるようにするための方法であって、プライベートコンテンツは、所有者によって所有され、コンテンツサーバにインストールされ、コンテンツサーバにおいて行われる次のステップ、すなわち、
   ユーザによって認可されるコンテンツ管理サーバ用のデリゲートトークンを生成するステップ（２０７）であって、デリゲートトークンが、プライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するために使用されるステップと、
   前記デリゲートトークンをコンテンツ管理サーバに送信するステップ（２０８）と
   を含む、方法。
9. 方法の諸ステップを実行するために、標準的なＯＡｕｔｈコールが使用される、請求項１から８のいずれかに記載の方法。
10. コンテンツ管理サーバ（１）と、
    コンテンツサーバに格納されたデジタルプライベートコンテンツを所有している第１のクライアント（７）と、
    いくつかの第２のクライアント（２）であって、コンテンツ管理サーバ（１）がコンテンツサーバからデジタルプライベートコンテンツと関連するデリゲートトークンを取得し、第２のクライアントがデジタルプライベートコンテンツにアクセスできるようにするデリゲートトークンを使用して第２のクライアント（２）にトークンを配布するように構成され、デリゲートトークンは、プライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するように使用された、第２のクライアント（２）とを含み、
    第２のクライアント（２）が、デジタルプライベートコンテンツへのアクセス権を取得するために、配布されたトークンをコンテンツサーバ（７）に提示するように構成された、プライベートデジタルコンテンツにアクセスするためのシステム。
11. 第１のクライアントが、コンテンツサーバを介してコンテンツ管理サーバから受信されたリクエストトークンを認証するように構成され、前記コンテンツ管理サーバが、認可されたリクエストトークンを受信して、前記認可されたリクエストトークンを使用してデリゲートトークンを取得するように構成された、請求項１０に記載のシステム。
12. 複数のクライアントのプライベートデジタルコンテンツをまとめるためのコンテンツ管理サーバ（１）であって、第１のクライアントが、コンテンツサーバに格納されたデジタルプライベートコンテンツを所有し、前記コンテンツ管理サーバがコンテンツサーバから所有者クライアントのデジタルプライベートコンテンツと関連するデリゲートトークンを取得し、デリゲートトークンを使用して第２のクライアント（１２）にトークンを配布し、第２のクライアントが所有者クライアントのプライベートコンテンツにアクセスできるように構成され、前記デリゲートトークンがプライベートデジタルコンテンツの所有者の協力を得て生成され、コンテンツの所有者を代表するように使用される、コンテンツ管理サーバ（１）。
13. コンテンツ管理サーバがＰｅＣＭａｎサーバのようなコンテンツアグリゲータである、請求項１２に記載のコンテンツ管理サーバ。
14. コンテンツ管理サーバがさらに、デリゲートトークンと比べると同等以下のアクセス権を有するプライベートコンテンツと関連するトークンをクライアントに提供するように構成された、請求項１２または１３に記載のコンテンツ管理サーバ。
15. プログラムがコンピュータで実行されるとき、請求項１から９のいずれかに記載の方法を実行するためのコンピュータで実行可能な命令を含む、コンピュータプログラム製品。

Images