JP2013509123A

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

Info

Publication number: JP2013509123A
Application number: JP2012535731A
Authority: JP
Inventors: フランケン，バルト; テーテン，バルト
Original assignee: アルカテル−ルーセント
Priority date: 2009-10-26
Filing date: 2010-10-15
Publication date: 2013-03-07
Also published as: EP2315149B1; CN102598010A; KR20120089484A; US9071593B2; KR101412318B1; WO2011051110A1; CN102598010B; US20120210448A1; EP2315149A1

Abstract

所有者によって所有され、コンテンツサーバ上にインストールされたプライベートデジタルコンテンツに対するアクセスを、前記デジタルコンテンツを表示できる第１のクライアントに提供するための方法であって、前記コンテンツサーバに対する許可されたアクセスを得るために前記第１のクライアントによって必要とされる事前に決定された情報を第２のクライアントによって生成するステップと、前記事前に決定された情報を前記第２のクライアントから前記第１のクライアントに転送するステップと、前記プライベートデジタルコンテンツに対するアクセスを得るために、前記事前に決定された情報を前記第１のクライアントによって使用するステップとを含む方法が開示される。対応するシステムも説明される。

Description

本発明は、プライベートデジタルコンテンツにアクセスするためのシステムおよび方法に関する。

ウェブ上で複数の当事者間のユーザ資格証明（ｕｓｅｒｃｒｅｄｅｎｔｉａｌｓ）を処理するためのオープン認証（ＯＡｕｔｈ）プロトコル（ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｌｉｃｅｎｓｅ／ｃｏｒｅ／１．０で利用可能なＯＡｕｔｈ仕様書１．０を参照されたい）が存在する。さらに、先に言及したＯＡｕｔｈシステムに類似した、ウェブエンティティ間のコンテンツ共有を可能にするいくつかのトークンベースの共有解決策が存在する。例えば、Ｆａｃｅｂｏｏｋ、Ｆｌｉｃｋｒ、Ｇｏｏｇｌｅ、Ｓｍｕｇｍｕｇ、およびＰｈｏｔｏｂｕｃｋｅｔは、すべて認証に関してトークンを使用する。

ＰｅＣＭａｎは、ユーザのコンテンツを編成するウェブツールである（ｈｔｔｐ：／／ｗｗｗ．ｐｅｃｍａｎ．ｎｅｔ／を参照されたい）。ＰｅＣＭａｎアーキテクチャの概略図が図１に示される。ユーザは、例えば、ＰｅＣＭａｎ内でＵＲＬをアップロードして、フリーフォーマットタグ（ｆｒｅｅ−ｆｏｒｍａｔｔａｇｓ）を用いてその情報に意味的にタグ付けして、後に、同じタグを用いてＰｅＣＭａｎに問い合わせることによって、その情報を再び発見することが可能である。同じタグを用いて、複数のＵＲＬにタグ付けできるため、ＰｅＣＭａｎは、ユーザが、「仮想ドライブ」相当の１つの論理位置を介して、大量のストレージプロバイダ（例えば、ウェブサーバ、ホームストア、または電子メールサーバ）上に保持されたすべてのオブジェクトを編成することを可能にする。

ＰｅＣＭａｎは、３種類の参照を認識する：すなわち、パブリックコンテンツ、プライベート非共有コンテンツ、およびプライベート共有コンテンツである。パブリックコンテンツは、公に利用可能なウェブソースを示すＵＲＬである。そのようなコンテンツにアクセスすることは、ユーザ資格証明を必要とせず、これは、人がそのコンテンツに関心を持つ誰とでもそのようなコンテンツを容易に共有できることを意味する。パブリック情報がユーザ間で共有されるとき、ＰｅＣＭａｎは、要求しているＰｅＣＭａｎクライアント、すなわち二次的ＰｅＣＭａｎクライアントに要求されたＵＲＬを単純に直接的に送り、その二次的ＰｅＣＭａｎは、例えば、ＷｅｂＤＡＶまたはＨＴＴＰを介してそのコンテンツを取り出す。

プライベートコンテンツは、通常、安全な位置、一般に、安全なウェブサイト（すなわち、ストレージプロバイダ）を介してだけアクセス可能なコンテンツである。安全なストレージプロバイダ７にアクセスするために、ウェブクライアント３は、まず、例えば、ＳＳＬ／ＴＬＳを介して安全な接続を確立し、次いで、そのユーザを認証するために、ユーザ資格証明（一般に、ユーザＩＤおよびパスワード）を提供する。ユーザが認証された後で、ウェブクライアント３は、プライベートに記憶されたコンテンツにアクセスすることが可能である。一般的に、通信チャネルに関連する状態がアドレス指定されたウェブサーバ７内に割り当てられる。この状態は、要求しているウェブクライアント３が自らを認証したことをウェブサーバ７に示す。

ＯＡｕｔｈ仕様書１．０：ｈｔｔｐ：／／ｏａｕｔｈ．ｎｅｔ／ｌｉｃｅｎｓｅ／ｃｏｒｅ／１．０

このプライベートに記憶されたコンテンツを表示または再生するために使用可能ないくつかのデバイスは、ユーザに資格証明を要求して、メディアサーバとの安全なセッションをセットアップするための機能を有さない。

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

本発明の文脈で、トークンは、そのトークンの要求側のいくつかの資格証明の検証時に生成される値である。この値は、通常、コンテンツサーバによって任意に生成された、いくつかの文字の列である。

本発明の一実施形態によれば、所有者によって所有され、コンテンツサーバ上にインストールされたプライベートデジタルコンテンツに対するアクセスを、デジタルコンテンツを表示できる第１のクライアントに提供するための方法であって、
− コンテンツサーバに対する許可されたアクセスを得るために第１のクライアントによって必要とされる事前に決定された情報を第２のクライアントによって生成するステップと、
− 事前に決定された情報を第２のクライアントから第１のクライアントに転送するステップと、
− プライベートデジタルコンテンツに対するアクセスを得るために、事前に決定された情報を第１のクライアントによって使用するステップとを含む方法が提供される。

本発明の文脈で、コンテンツサーバは、通常、安全なコンテンツサーバを指し、例えば、安全なウェブサーバであってよい。その他の例は、ファイル共有機能を備えたローカルディスク、そのコンピュータがコンテンツサーバとして機能するように、サーバプログラムをインストールした任意のコンピュータなどであってよい。

好ましい実施形態によれば、事前に決定された情報は、第１のクライアント固有情報に依存する。

好ましい実施形態によれば、事前に決定された情報は、第２のクライアント固有情報に依存する。

好ましい実施形態によれば、この方法は、第１のクライアント固有情報を第１のクライアントデバイスから第２のクライアントデバイスに転送するステップをさらに含む。その他の実施形態では、この情報は、既に、第２のクライアントに利用可能な場合があるため、第１のクライアント固有情報を転送するステップは必要でない。

好ましい実施形態によれば、事前に決定された情報は、コンテンツサーバに対して第１のクライアントを認証するための情報を含む。

好ましい実施形態によれば、事前に決定された情報は、所有者固有情報を含む。

好ましい実施形態によれば、事前に決定された情報を第２のクライアントによって生成するステップは、１つまたは複数の標準オープン認証コールを含む。

好ましい実施形態によれば、事前に決定された情報を第２のクライアントによって生成するステップは、コンテンツ管理サーバ、例えば、ＰｅＣＭａｎサーバと相互に作用するステップを含む。

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

そのようなコンテンツ管理サーバの好ましい実施形態は、コンテンツのタグ付けを可能にするように構成されることになる。

本発明の第２の態様によれば、所有者によって所有されたプライベートデジタルコンテンツにアクセスするためのシステムであって、プライベートデジタルコンテンツを備えたコンテンツサーバと、デジタルコンテンツを表示できる第１のクライアントと、コンテンツサーバ上に記憶されたデジタルプライベートコンテンツを所有している第２のクライアントとを備え、第２のクライアントが、コンテンツサーバに対する許可されたアクセスを得るために第１のクライアントによって必要とされる事前に決定された情報を生成するように構成され、第２のクライアントが、事前に決定された情報を第１のクライアントに転送するように構成され、第１のクライアントが、プライベートデジタルコンテンツに対するアクセスを得るために、第２のクライアントから事前に決定された情報を受信することを使用するように構成されるシステムが開示される。

プログラムがコンピュータ上で実行されるとき、第１の態様の方法のうちのいずれかに記載の方法を実行するためのコンピュータ実行可能命令を備えたコンピュータプログラム製品も開示される。

本発明の現在好ましい非限定的な例示的な実施形態を示すために、添付の図面が使用される。添付の図面と共に読まれたとき、以下の詳細な説明から、本発明の上記の有利な特徴および目的、ならびに本発明のその他の有利な特徴および目的はより明瞭になり、本発明はより良好に理解されよう。

ＰｅＣＭａｎアーキテクチャの概略図である。本発明の実施形態による、拡張されているＰｅＣＭａｎアーキテクチャの概略図である。ＰｅＣＭａｎサーバをデリゲートする（ｄｅｌｅｇａｔｉｎｇ）ための最新の方法によるコールフローを例示する図である。（例えば、ＰｅＣＭａｎ）認証機能を備えていないクライアントによってプライベートコンテンツを取り出すための、本発明の方法の実施形態による例示的なコールフローを示す図である。（例えば、ＰｅＣＭａｎ）認証機能を備えていないクライアントによってプライベートコンテンツを取り出すための、本発明の方法の実施形態による例示的なコールフローを示す図である。

本発明は、コンテンツ管理サーバとしてのパーソナルコンテンツ管理（ＰＥｒｓｏｎａｌＣｏｎｔｅｎｔＭＡＮａｇｅｍｅｎｔ）（ＰｅＣＭａｎ）サーバを参照して下で例示されるが、当業者は、本発明は、上で定義されるような（所有者のプロキシを含む）任意のタイプのコンテンツ管理サーバに適用可能である点を理解されよう。

第１のタイプの先行技術によれば、プライベート非共有コンテンツおよびプライベート共有コンテンツをサポートするために、ＰｅＣＭａｎは、一般に、示されているＵＲＬに対するユーザ資格証明を記憶する。プライベートコンテンツがアドレス指定されている場合、二次的ＰｅＣＭａｎクライアント３は、次いで、二次的ＰｅＣＭａｎクライアントの代わりにストレージプロバイダ７に対する接続を確立するＰｅＣＭａｎ１に対して通信チャネルをセットアップし、すなわち、ＰｅＣＭａｎサーバ４は、二次的ＰｅＣＭａｎクライアント３に関するプロキシとして機能する。このプロキシは、ウェブサーバ７に対して安全な接続を保持し、ストレージプロバイダ７にユーザ資格証明を提供するプロキシでもある。ＰｅＣＭａｎは、共有プライベートコンテンツと非共有プライベートコンテンツの両方の参照に関してこれを行う。

第２のタイプの先行技術によれば、ＯＡｕｔｈは、第３のエンティティが、図３に例示されるトークンベースの認証機構を介して、ユーザ資格証明を知る必要なく、ユーザプライベートデータにアクセスできるように、プライベートコンテンツプロバイダと第３のエンティティとの間でプライベートデータを共有するために使用される。

第２のタイプの先行技術の第１段階で、デリゲートトークン（ｄｅｌｅｇａｔｅｔｏｋｅｎ）は、コンテンツ所有者Ｏに代わってＰｅＣＭａｎサーバを許可するための１つの例示的なデリゲーション手順を示す図３のコールフローによって例示されるＰｅＣＭａｎサーバなど、コンテンツ管理サーバによって取得される。ＰｅＣＭａｎサーバは、プライベートコンテンツサーバ、ここでは、安全なウェブサーバＷＳのクライアントとして機能することになる。開始段階「Ｉ」で、ＰｅＣＭａｎサーバは、ウェブサーバＷＳとの安全な接続を確立し、ＰｅＣＭａｎサーバとウェブサーバＷＳとの間に消費者鍵Ｃｋと秘密鍵Ｃｓとが確立される（矢印２００を参照されたい）。また、所有者Ｏは、プライベートコンテンツｘｙｚをウェブサーバＷＳ上に直接インストールする（矢印２０１を参照されたい）。一般的に、所有者は、ユーザ名とパスワードとを使用して、安全なウェブサーバにログインすることになり、ログインするとすぐ、その所有者はプライベートコンテンツｘｙｚをインストールできる。次に、所有者Ｏは、所有者Ｏが保護されたサーバ上にプライベートコンテンツｘｙｚをインストールしたことをＰｅＣＭａｎサーバに知らせる（矢印２０２を参照されたい）。

インストールされたプライベートコンテンツについて知らされると、ＰｅＣＭａｎサーバは、コールフローの段階Ａにおいて、トークンを要求して、その所有者によってこのトークンを認可させることになる。まず、ＰｅＣＭａｎサーバは、ウェブサーバＷＳからトークンを要求する（矢印２０６を参照されたい）。これは、以下のパラメータを含む標準ＯＡｕｔｈ要求コールであり得る：すなわち、消費者鍵Ｃｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、署名方法Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ１（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびナンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）である。署名Ｓ１は、例えば、Ｃｓを使用して作成できる。一般には、クライアントは、まず、タイムスタンプを生成することになり、次いで、それぞれの要求に一意のナンス値が生成される。ウェブサーバＷＳは、次いで、トークンＴ１（ｏａｕｔｈ＿ｔｏｋｅｎ）とトークン秘密Ｔｓ１（ｏａｕｔｈ＿ｔｏｋｅｎ＿ｓｅｃｒｅｔ）とを生成して、それらをＰｅＣＭａｎサーバに送る（矢印２０４を参照されたい）。次いで、ＰｅＣＭａｎサーバは、所有者をウェブサーバＷＳに導くことによって、所有者から許可を取得するために、宛て先変更メッセージを所有者に送る（矢印２０５）。これは、トークンＴ１と、所有者をＰｅＣＭａｎサーバに宛て先変更させるためにウェブサーバが使用することになるＵＲＬであるコールバックＵＲＬＣとを含む、ウェブサーバのユーザ許可ＵＲＬ「ＷＳ：／／ａｕｔｈ？」に対する標準ＯＡｕｔｈ要求であり得る。この許可要求は、次いで、ウェブサーバに渡されて（矢印２０６）、ウェブサーバは、一般に、ＰｅＣＭａｎサーバの識別を検証して、所有者に同意を求めることによって、トークンＴ１を認可することになる（矢印２０７）。例えば、プライベートコンテンツプロバイダ（ウェブサーバＷＳ）に対する安全な接続は、ＰｅＣＭａｎの資格証明を提供して、そのトークンを安全な接続と関連付けることによってログインして確立される。次いで、ＰｅＣＭａｎサーバは、例えば、標準ＯＡｕｔｈコールを使用して、トークンＴ１がコールバックＵＲＬを使用して許可されていることを所有者Ｏによって通知される（矢印２０８）。ＰｅＣＭａｎサーバは、次いで、その第１のトークンＴ１を使用して、第２のトークンを要求する（矢印２０９）（段階Ｂを参照されたい）。これは、例えば、以下のパラメータを用いて、要求トークンをアクセストークンと交換するための標準ＯＡｕｔｈ要求を使用して行うことができる：すなわち、所費者鍵Ｃｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、先に取得されたトークンＴ１（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方法Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ２（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびナンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）である。署名Ｓ２は、例えば、ＣｓとＴｓ１とに基づいて計算できる。応答して、第２のトークンＴ２とトークン秘密Ｔｓ２とがウェブサーバＷＳによって付与される（矢印２１０）。この第２のトークンＴ２は、所有者のプライベートコンテンツに対するアクセスを得るためのデリゲートトークンとして機能し得る（２１１、２１２）。

これは、例えば、以下のパラメータを含む標準アクセス要求を使用して行うことができる：すなわち、消費者鍵Ｃｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、トークンＴ２（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方法Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ３（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびナンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）である。署名Ｓ３は、例えば、ＣｓとＴｓ２とを使用して計算できる。

これらの最新解決策は、デバイス／クライアントが、そのコンテンツサーバに対する、またはコンテンツ管理サーバ（例えば、ＰｅＣＭａｎサーバ）に対する認証機能（例えば、ＰｅＣＭａｎ）を備えていない場合、デバイス／クライアントがプライベートコンテンツを取り出すことを可能にしない。

本発明による第１のタイプの実施形態では、好ましくは、上述のフローまたは類似のフローを使用できるが、前記コンテンツサーバに対するアクセスを得るために第１のクライアントによって必要な事前に決定された情報を生成するために、第２のクライアント、例えば、ＤＭＣが消費者（ＰｅＣＭａｎサーバ）の役割を担うという点で修正される。

この事前に決定された情報は、次いで、例えば、ＤＬＮＡによって、第１のクライアントデバイス、例えば、ＤＭＰ（または、ＤＭＲ）に転送され（２１４）、次いで、第１のクライアントデバイスは、コンテンツサーバ上でプライベートコンテンツに直接アクセスできる（２１１’、２１２’）。これは、図２および４に例示される。

この第１のタイプの実施形態によれば、第２のクライアントは、これにより、その資格証明自体を信頼されていないデバイスに転送せずに、そのようなデバイス上に表示されたプライベートコンテンツに対するアクセスを得るために、その一意の資格証明を使用することが可能である。しかし、第２のタイプのその他の好ましい実施形態によれば、第２のクライアントは、プライベートコンテンツに対するアクセスを得るために、第１のクライアントからの資格証明を使用することも可能であり、第１のクライアントの資格証明は、
ａ）第２のクライアントに利用可能であった、
ｂ）第２のクライアントに提供される。

本発明の第２のタイプの実施形態は、図２および５で例示される。プライベートコンテンツを表示または再生することを望む第１のクライアント１０は、例えば、（ＤＬＮＡ仕様書で使用される専門用語であるデジタルメディアレンダラ（ｄｉｇｉｔａｌｍｅｄｉａｒｅｎｄｅｒｅｒ）（ＤＭＲ）またはデジタルメディアプレイヤ（ＤＭＰ）と見なすことが可能な）テレビデバイスである。テレビデバイスは、異なる認証（例えば、ＯＡｕｔｈ）パラメータを計算できず、それらの機能を有するデバイス、例えば、デジタルメディアコントローラ（ＤＬＮＡ仕様書で使用される専門用語であるＤＭＣ）９の機能性を備えたｉＰｈｏｎｅ（ＴＭ）にその資格証明をハンドオーバする。そのＴＶの資格証明に基づいて、ｉＰｈｏｎｅ（ＴＭ）は、必要とされる認証情報、例えば、ＯＡｕｔｈパラメータを備えた有効なＵＲＬを構築することができる。この情報は、次いで、テレビデバイスに転送されて、そのテレビデバイスは、そのＵＲＬを経由して、所望されるコンテンツを、ある見解では「仮想ＰｅＣＭａｎクライアント」１２である、サービスプロバイダ１３から直接得ることができる。テレビデバイス（ＤＭＲまたはＤＭＰ）とｉＰｈｏｎｅ（ＴＭ）との間の情報の交換は、ＤＬＮＡ仕様書に基づく技術および方法に基づくことが好ましい。

このフローは、本発明による第１のタイプの実施形態のフローに類似してよく、以下のようであってよい。

第２のタイプの実施形態の第１の段階で、プライベートコンテンツを得るコンテンツ所有者Ｏに代わってテレビデバイスを許可するための１つの例示的なデリゲーション手順を示す図５のコールフローによって例示されるテレビデバイスなど、デジタルメディアレンダラによって、デリゲートトークンが取得される。ｉＰｈｏｎｅ（ＴＭ）は、認証パラメータを計算できるデバイスとして機能することになる。開始段階「Ｉ」において、テレビデバイスは、ウェブサーバＷＳと安全な接続を確立し、テレビデバイスとウェブサーバＷＳとの間で消費者鍵Ｃｋと消費者秘密鍵Ｃｓとが確立される（矢印２００を参照されたい）。また、所有者Ｏは、プライベートコンテンツｘｙｚをウェブサーバＷＳ上に直接インストールする（矢印２０１を参照されたい）。一般に、所有者は、ユーザ名とパスワードとを使用して安全なウェブサーバにログインすることになり、ログインするとすぐ、その所有者はプライベートコンテンツｘｙｚをインストールすることができる。次に、所有者Ｏは、所有者Ｏが保護されたウェブサーバ上にプライベートコンテンツｘｙｚをインストールしたことをＰｅＣＭａｎサーバに知らせる（矢印２０２を参照されたい）。

インストールされたプライベートコンテンツについて知らされると、テレビデバイスは、コールフローの段階Ａにおいて、トークンを要求することを望み、その所有者によってこのトークンを認証させる。まず、テレビデバイスは、その資格証明、すなわち、消費者鍵Ｃｋと消費者秘密ＣｓとをｉＰｈｏｎｅ（ＴＭ）に送る（矢印２１５を参照されたい）。この資格証明に基づいて、ｉＰｈｏｎｅ（ＴＭ）は、認証要求に関して必要なパラメータを計算できる。これは、以下のパラメータを含む標準ＯＡｕｔｈ要求コールであり得る：すなわち、消費者鍵Ｃｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、署名方法Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ１（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびナンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）である。署名Ｓ１は、例えば、Ｃｓを使用して作成できる。一般に、クライアントは、まず、タイムスタンプを生成することになり、次いで、それぞれの要求に関して一意のナンス値が生成される。ｉＰｈｏｎｅ（ＴＭ）は、これらのパラメータをテレビデバイスに送る（矢印２１６を参照されたい）。テレビデバイスは、それらのパラメータを用いてウェブサーバからトークンを要求する（矢印２０３を参照されたい）。次いで、ウェブサーバＷＳは、トークンＴ１（ｏａｕｔｈ＿ｔｏｋｅｎ）とトークン秘密Ｔｓ１（ｏａｕｔｈ＿ｔｏｋｅｎ＿ｓｅｃｒｅｔ）とを生成して、それらをテレビデバイスに送る（矢印２０４を参照されたい）。ＰｅＣＭａｎテレビデバイスは、次いで、所有者をウェブサーバＷＳに導くことによって、所有者から承認を取得するために、宛て先変更メッセージを所有者に送る（矢印２０５）。これは、トークンＴ１と、所有者をＰｅＣＭａｎサーバに宛て先変更させるためにウェブサーバが使用することになるＵＲＬであるコールバックＵＲＬＣとを含む、ウェブサーバのユーザ許可ＵＲＬ「ＷＳ：／／ａｕｔｈ？」に対する標準ＯＡｕｔｈ要求であり得る。この許可要求は、次いで、ウェブサーバに渡されて（矢印２０６）、ウェブサーバは、一般に、ＰｅＣＭａｎサーバの識別を検証して、所有者に同意を求めることによって、トークンＴ１を認可することになる（矢印２０７）。例えば、プライベートコンテンツプロバイダ（ウェブサーバＷＳ）に対する安全な接続は、そのプライベート資格証明をそのウェブサーバに提供して、そのトークンを安全な接続と関連付けることによってログインして確立される。次いで、テレビデバイスは、例えば、標準ＯＡｕｔｈコールを使用して、トークンＴ１がコールバックＵＲＬを使用して許可されていることを所有者Ｏによって通知される（矢印２０８）。

テレビデバイスは、その資格証明と、消費者鍵（Ｃｋ）と、消費者秘密（Ｃｓ）と、トークン（Ｔ１）と、トークン秘密（ＴＳ１）とをｉＰｈｏｎｅ（ＴＭ）に送る（矢印２１７を参照されたい）。この資格証明に基づいて、ｉＰｈｏｎｅ（ＴＭ）は、認証要求に関して必要なパラメータを計算できる。これは、例えば、以下のパラメータを用いて、要求トークンをアクセストークンと交換するための標準ＯＡｕｔｈ要求を使用して行うことが可能である：すなわち、消費者鍵Ｃｋ（ｏａｕｔｈ＿ｃｏｎｓｕｍｅｒ＿ｋｅｙ）、先に取得されたトークンＴ１（ｏａｕｔｈ＿ｔｏｋｅｎ）、署名方法Ｓｍ（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ＿ｍｅｔｈｏｄ）、署名Ｓ２（ｏａｕｔｈ＿ｓｉｇｎａｔｕｒｅ）、タイムスタンプＯｔ（ｏａｕｔｈ＿ｔｉｍｅｓｔａｍｐ）、およびナンスＮ（ｏａｕｔｈ＿ｎｏｎｃｅ）である。署名Ｓ２は、例えば、ＣｓとＴｓ１とに基づいて計算できる。ｉＰｈｏｎｅ（ＴＭ）は、これらのパラメータをテレビデバイスに送る（矢印２１８を参照されたい）。次いで、テレビデバイスは、それらのパラメータを使用して、第２のトークンを要求する（矢印２０９）（段階Ｂを参照されたい）。応答して、第２のトークンＴ２とトークン秘密Ｔｓ２とがウェブサーバＷＳによって付与される（矢印２１０）。この第２のトークンＴ２は、メッセージを計算するために、正しい資格証明をｉＰｈｏｎｅ（ＴＭ）に送ることによって、所有者のプライベートコンテンツに対するアクセスを得るためのデリゲートトークンとして機能し得る（２１９、２２０、２１１’、２１２’）。

さらなる代替の実施形態によれば、第２のクライアントデバイスは、ＤＭＣデバイスと異なってよく、事前に決定された情報の通信、および第２のクライアントデバイスと第１のクライアントデバイスとの間の情報交換は、他の機構に基づいてよい。例えば、事前に決定された情報を計算できないデバイスの資格証明（例えば、正しいＵＲＬ）を維持するプロキシサーバを使用することが可能である。第１のクライアントデバイスは、正しいパラメータを計算することをそのプロキシに要求できる。次いで、プロキシは、結果として生じるＵＲＬをデバイスに転送して、そのデバイスがコンテンツサーバ上でプライベートコンテンツ（例えば、ＯＡｕｔｈ保護されたリソース）にアクセスするのを可能にする。

本発明の実施形態による方法は、自らがコンテンツサーバ上のプライベートコンテンツにアクセスするために事前に決定された情報を生成できない第１のクライアントデバイスに限定されない点に留意されたい。第１のクライアントデバイスは、例えば、これらの機能を本質的に備えるが、例えば、セキュリティ問題のために、それに関して必要な資格証明がそのデバイス上に記憶されていないモバイルフォンデバイスまたはＰＤＡであってよい。その場合、これらの資格証明は、プロキシ上に記憶可能であり、第１のクライアントデバイスからの要求時に、そのプロキシは、前記コンテンツサーバにアクセスするために第１のクライアントに必要とされる事前に決定された情報を生成して、それを第１のクライアントに転送することが可能であり、その後、第１のクライアントは、コンテンツサーバ上のプライベートコンテンツにアクセスする。これらのシナリオは、したがって、セキュリティの利点を提供する。

当業者は、様々な上述の方法のステップは、プログラムされたコンピュータによって実行可能である点を容易に理解されよう。本明細書において、いくつかの実施形態は、機械可読またはコンピュータ可読であり、命令の機械実行可能プログラムまたはコンピュータ実行可能プログラムを符号化するプログラム記憶装置、例えば、デジタルデータ記憶媒体を網羅することも意図され、前記命令は、前記上述の方法のステップのうちのいくつかまたはすべてを実行する。これらのプログラム記憶装置は、例えば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光可読デジタルデータ記憶媒体であってよい。これらの実施形態は、上述の方法の前記ステップを実行するようにプログラムされたコンピュータを網羅することも意図される。

本発明の原理が特定の実施形態に関して上で提示されているが、この説明は、特許請求の範囲によって決定される保護の範囲の限定としてではなく、単なる例として行われている点を明瞭に理解されたい。

Claims

所有者によって所有され、コンテンツサーバ上にインストールされたプライベートデジタルコンテンツに対するアクセスを、前記デジタルコンテンツを表示できる第１のクライアントに提供するための方法であって、
− 前記コンテンツサーバに対する許可されたアクセスを得るために前記第１のクライアントによって必要とされる事前に決定された情報を第２のクライアントによって生成するステップと、
− 前記事前に決定された情報を前記第２のクライアントから前記第１のクライアントに転送するステップと、
− 前記プライベートデジタルコンテンツに対するアクセスを得るために、前記事前に決定された情報を前記第１のクライアントによって使用するステップとを含む、方法。
前記事前に決定された情報が第１のクライアント固有情報に依存する、請求項１に記載の方法。
前記事前に決定された情報が第２のクライアント固有情報に依存する、請求項１に記載の方法。
前記第１のクライアント固有情報を前記第１のクライアントデバイスから前記第２のクライアントデバイスに転送するステップをさらに含む、請求項２から３に記載の方法。
前記事前に決定された情報が、コンテンツサーバに対して第１のクライアントを認証するための情報を含む、請求項１から４のいずれかに記載の方法。
前記事前に決定された情報が所有者固有情報を含む、請求項１から５のいずれかに記載の方法。
事前に決定された情報を第２のクライアントによって生成する前記ステップが、１つまたは複数の標準オープン認証コールを含む、請求項１から６のいずれかに記載の方法。
事前に決定された情報を第２のクライアントによって生成する前記ステップが、ＰｅＣＭａｎサーバなど、コンテンツ管理サーバと相互に作用するステップを含む、請求項１から７のいずれかに記載の方法。
所有者によって所有されたプライベートデジタルコンテンツにアクセスするためのシステムであって、
前記プライベートデジタルコンテンツを備えたコンテンツサーバと、
前記デジタルコンテンツを表示できる第１のクライアントと、
前記コンテンツサーバ上に記憶された前記デジタルプライベートコンテンツを所有する第２のクライアントとを備え、
前記第２のクライアントが、前記コンテンツサーバに対する許可されたアクセスを得るために前記第１のクライアントによって必要とされる事前に決定された情報を生成するように構成され、
前記第２のクライアントが、前記事前に決定された情報を前記第１のクライアントに転送するように構成され、前記第１のクライアントが、前記プライベートデジタルコンテンツに対するアクセスを得るために、前記第２のクライアントから前記事前に決定された情報を受信することを使用するように構成される、システム。
プログラムがコンピュータ上で実行されるとき、請求項１から８のいずれかに記載の方法を実行するためのコンピュータ実行可能命令を備えた、コンピュータプログラム製品。