メディアの再生を可能にするための方法および装置
コンテンツプロバイダ（３０６）から第２のデバイス（３０２）へのメディアコンテンツの転送を制御するために第１のデバイス（３００）を使用することを可能にするための方法および装置。第１のデバイスは、通信ネットワークとの間でセキュリティの関連付けを事前に確立している。第２のデバイスへのメディアコンテンツの配信を求める第１のデバイスによって行われる要求をネットワークが検出すると、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報が、確立される。ネットワークは、キー情報をコンテンツプロバイダおよび第１のデバイスへ送信する。次いでコンテンツプロバイダが、メディアキーによって暗号化されたメディアコンテンツを第２のデバイスへ配信する。さらに、第１のデバイスが、コンテンツプロバイダによって配信された場合にメディアキーによって暗号化されたメディアコンテンツを解読するためのメディアキーを、ローカル通信リンクを経由して第２のデバイスへ転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、レンダリングデバイス上でのメディアの再生を可能にするための方法および装置に関し、それらにセキュリティおよび制御を付加したものである。
【背景技術】
【０００２】
さまざまなアクセスネットワークに接続されたユーザ端末のためのマルチメディアサービスおよびマルチメディアセッションを可能にするために、「ＩＰマルチメディアサブシステム（ＩＭＳ）」と呼ばれるアーキテクチャが開発された。さまざまな当事者間のメディアセッションが、シグナリングプロトコルである「ＳＩＰ」（セッション開始プロトコル）およびＲＴＳＰ（リアルタイム・ストリーミングプロトコル）を用いて開始されてもよく、それらは、ＩＭＳサービスオペレータによって制御されるいわゆる「ＩＭＳコア」の中の特定のセッション制御ノードによって制御される。
【０００３】
また、住宅用または事務所用ネットワーク、ＬＡＮ（ローカルエリアネットワーク）、プライベートネットワークもしくはホームネットワークとも呼ばれる、内部的なアドレス指定およびトランスポート手段を用いる限定されたローカルネットワークの中のデバイス間のマルチメディア通信のための技術やプロトコルも確立されている。ローカルネットワークの中のデバイスには、例えば、固定電話、ワイヤレス電話、コンピュータ、メディアプレーヤ、サーバ、および、「ＳＴＢ」（セットトップボックス）とも呼ばれるテレビジョンボックスなどのように、ネットワーク内での通信が可能ないかなるタイプのエンティティが含まれていてもよい。
【０００４】
さまざまなオペレーティングシステム、プログラミング言語、フォーマット標準、通信プロトコルを用いうるさまざまなデバイスの間で、ＵＰｎＰ（ユニバーサル・プラグアンドプレイ）と呼ばれるアーキテクチャを用いてローカルネットワーク内での通信が行われてもよい。さらに、ローカルネットワーク内のデバイスからのメディアコンテンツを取得・記憶し、それにアクセスするために、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）という技術が最近開発された。
【０００５】
ＤＬＮＡでは、さまざまなシナリオに対してさまざまな通信スキームが定義されており、いわゆる「３−ボックス」スキームもそれらの中に含まれる。このシナリオを図１に示すが、それによると、ローカルネットワーク１００の範囲内で第１のデバイスを用いて、ネットワーク内の第２のデバイス上に記憶されたメディアの第３のデバイスへの転送を制御することができる。ここでは、再生能力が限定されている小型の手持ち式のワイヤレス電話１０２が制御デバイスとして用いられ、ラップトップコンピュータ１０４とメディアサーバ１０６とのうちいずれか一方に、手持ち式デバイスおよびラップトップコンピュータと比べてそれらのいずれよりも高い品質でコンテンツを再生することを目的として、メディアコンテンツをＴＶ受像機１０８へストリーミングするよう命令する。このようにして、ＴＶ受像機１０８は「レンダリングデバイス」として用いられる。
【０００６】
また、近年、ＩＰＴＶ（インターネットプロトコルＴＶ）という概念も普及してきており、この場合、ユーザはメディアをＩＰＴＶプロバイダからインターネット経由のストリーミングまたはダウンロードを使って入手することができる。さらに、ＩＰＴＶプロバイダにメディアを要求するのに、ＩＰＴＶプロバイダに対してユーザおよびユーザ端末を許可するための信用証明書としてＩＭＳサブスクリプションを用いることも可能である。また、ユーザは、端末内で従来のＳＩＭ（加入者ＩＤモジュール）カードまたはそれに類するものを用いて移動端末へのＩＰＴＶサービスを受けることもできる。
【０００７】
ＩＭＳサブスクリプションを利用する場合、通常は、ＩＰＴＶサービスにアクセスするには、対応するＩＳＩＭ（ＩＭＳ ＳＩＭ）が必要である。図２は、この状況を示しており、ここではＩＳＩＭがラップトップコンピュータ２００またはその他のＩＭＳ対応通信デバイスの中に設置されていて、それが次いで、ＩＭＳコア２０２を介してＩＰＴＶプロバイダ２０４にメディアを要求する。要求されたコンピュータ２００へのメディア転送をＩＭＳコア２０２が許可した後、ＩＰＴＶプロバイダ２０４は、例えばインターネットのような公衆トランスポートネットワークを経由してメディアがそこへストリーミングまたはダウンロードされうるようにしてもよい。それによって、ユーザは自分のＩＭＳサブスクリプションによって、そして、事前に確立されたＩＭＳオペレータとの間のセキュリティ関係を利用して、かつ、有効な信用証明書を提供するためにＩＳＩＭを用いて、ＩＭＳ対応デバイス２００上でＴＶコンテンツを消費することができる。
【０００８】
加えて、ＩＰＴＶプロバイダから、あるいは、その他のいずれかのコンテンツ、例えばＴＶ番組、映画、いずれかの視覚および／または聴覚コンテンツ、ゲーム関連コンテンツ等のプロバイダから入手されたコンテンツを、ユーザが、外部の訪問先のレンダリングデバイス上で再生できるようにすることが望ましいであろう。例えば、ユーザが、ホテルに滞在するかまたは友人を訪問し、自分のＩＭＳサブスクリプションを用いて、ホテルまたは友人宅のＴＶ受像機でメディアを入手して再生したいと望んだとしよう。しかし、ユーザが、移動可能なＩＳＩＭを訪問先のデバイスに挿入した上で、それを用いてＩＭＳコアにアクセスし、プロバイダからメディアを入手する許可を受けることができない限り、これは不可能であろう。もちろん、多くのユーザデバイス、例えばＴＶ受像機は、そのようなＩＳＩＭまたは対応する移動可能な信用証明書ツールを受信して処理するような備えは持っていない。
【０００９】
訪問先のレンダリングデバイスへのメディアを入手するための有効なＩＭＳ信用証明書またはそれに類するものを使えない場合に挙げられうるもう１つの問題は、ユーザもコンテンツプロバイダもどちらも、レンダリングデバイスに対するメディア転送のセキュアな制御ができないことである。例えば、コンテンツプロバイダは、コンテンツが許可された当事者によってのみアクセスされるのかどうかを知らないかもしれないし、逆に、ユーザは、コンテンツが適切な形で配信されるという確証は持てない。
【００１０】
外部のコンテンツプロバイダからのメディア配信に一般に関連するもう１つの問題は、何らかの理由でユーザが配信に満足していないかまたは配信を受け入れる準備ができていない場合に、メディア転送を中止できないことである。例えば、レンダリングされた品質が、期待される水準に達していない、あるいは、コンテンツが不完全な形で受信されるかまたは全く受信されないことがありうる。さらに、訪問先のレンダリングデバイスが、受信されたメディアフォーマットを適切な形で再生できないことがありうる。しかも、ユーザが、うっかり、間違ったメディアコンテンツまたはメディアタイプを要求していたこと等もありうる。他方、コンテンツプロバイダも、要求側ユーザがメディアの受信を中止したのは、例えば、意図的な電源断に因るものか、あるいは、意図的でない接続性喪失に因るものかを発見することができない。
【発明の概要】
【００１１】
本発明の目的は、基本的に、上記に概説した諸問題の少なくとも一部に取り組むことである。さらに、許可が不可能でありうる、および／またはＩＭＳサブスクリプションを用いることが不可能でありうる訪問先のデバイスへのメディアのセキュアな転送を可能にする解決策を提供することも、目的の１つである。これらの目的等は、以下に添付する独立請求項による方法および装置を提供することによって得られうる。
【００１２】
一態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するために第１のデバイスを使用することを可能にするための、通信ネットワークにおける方法が提供される。第１のデバイスは、通信ネットワークとの間でセキュリティの関連付けを事前に確立していると仮定する。コンテンツプロバイダに対する、第２のデバイスへのメディアコンテンツの配信を求めて第１のデバイスによって行われる要求が検出されると、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報が、確立される。キー情報は、第１のキー情報セット及び第２のキー情報セットを含んでいる。次いで、キー情報の第１のキー情報セットが、コンテンツプロバイダへ送信され、第２のキー情報セットが、第１のデバイスへ送信される。コンテンツプロバイダが、メディアキーによって暗号化された、要求されたメディアコンテンツを第２のデバイスへ配信すると、第１のデバイスは、メディアコンテンツを解読するためのメディアキーまたはそれについての情報を、ローカル通信リンクを経由して第２のデバイスへ転送することができる。
【００１３】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するために第１のデバイスを使用することを可能にするように構成された、通信ネットワークのノードにおける装置が提供され、第１のデバイスは、通信ネットワークとの間でセキュリティの関連付けを事前に確立している。この装置によれば、ネットワークノード内の検出ユニットが、第２のデバイスへのメディアコンテンツの配信を求めて第１のデバイスによって行われる要求を検出するように構成され、要求はコンテンツプロバイダに対して行われる。さらに、ネットワークノード内のキーユニットが、第１のキー情報セット及び第２のキー情報セットを含めて、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立するように構成される。
【００１４】
また、ネットワークノード内の装置は、第１のキー情報セットをコンテンツプロバイダへ送信するように構成された第１の通信ユニットを備えており、それによって、コンテンツプロバイダは、メディアキーによって暗号化された、要求されたコンテンツを第２のデバイスへ配信することができるようになる。また、ネットワークノード内の装置は、第２のキー情報セットを第１のデバイスへ送信するように構成された第２の通信ユニットを備えており、それによって、第１のデバイスは、コンテンツプロバイダによって配信された場合にメディアキーによって暗号化されたメディアコンテンツを解読するためのメディアキーまたはそれについての情報を、ローカル通信リンクを経由して第２のデバイスへ転送することができるようになる。
【００１５】
上記の通信ネットワークにおける方法および装置では、さまざまな実施形態が用いられうる。考えられる一実施形態では、確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定され、各メディアキーに関する情報が、連続的に第１のデバイスへ送信される。それによって、通信ネットワークは、キー情報の送信を中止することによって、メディアキーによって暗号化されたコンテンツの配信を中止することができる。
【００１６】
考えられるもう１つの実施形態では、各メディアキーに関連付けられたキー識別子が、第１のデバイスへ送信されて第２のデバイスへ転送され、コンテンツプロバイダが、関連付けられたメディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、第２のデバイスにおいて受信されたメディアとメディアキーとを同期させる。上記のいずれの実施形態においても、メディアキーは、事前に設定された時間間隔で、あるいは、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。
【００１７】
考えられるもう１つの実施形態では、連続的なメディアキーに関する情報を第１のデバイスへ送信するために、第１のデバイスからのキー情報を求める連続的要求が必要とされる。それによって、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができる。キー情報を求める要求は、第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信されてもよく、連続的なメディアキーに関する情報は、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応じて第１のデバイスへＳＩＰ Ｎｏｔｉｆｙメッセージの中で送信されてもよい。それゆえ、この手順は、既存のＳＩＰメッセージタイプを用いることによって円滑に行うことができる。
【００１８】
考えられる別の実施形態では、キー情報は、１つ以上の明示的なメディアキーまたは、そこからメディアキーが判定されうる、１つ以上の暗示的なメディアキー関連パラメータを含んでいる。事前に確立されたセキュリティの関連付けは、第１の基本キーを含んでいてもよく、１つ以上の暗示的なメディアキー関連パラメータは、少なくとも１つのナンスを含んでいてもよく、ここで、メディアキーは、第１の基本キーおよびナンスから導出されてもよい。さらに、コンテンツプロバイダへ送信される第１のキー情報セットは、第１の基本キーに依存する第２の基本キーを含んでいてもよく、次いで、コンテンツプロバイダは、第２の基本キーを用いて一連のメディアキーを導出し、メディアキーに関する情報を連続的に第１のデバイスへ送信する。
【００１９】
考えられる別の実施形態では、第１のデバイスからのコンテンツ要求は、メディアコンテンツを第２のデバイスへ配信するためにコンテンツプロバイダによって用いられる、第２のデバイスの接続パラメータを含んでいる。
【００２０】
要求は、第１のデバイスからネットワークで受信された時に検出されてもよい。あるいは、要求は、コンテンツプロバイダが第１のデバイスから要求を受信した時に検出されてもよく、そして、コンテンツプロバイダは、３ＧＰＰに規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報を第１のデバイスへ送信してもよく、ここで、第１のデバイスは、そこからメディアキーを生成することができる。
【００２１】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための、第１のデバイスにおける方法が提供される。この方法では、第１のデバイスが、第２のデバイスとの間でローカル通信リンクを確立する。また、第１のデバイスは、第２のデバイスへのメディアコンテンツの配信を求める要求を行い、そして、この要求はコンテンツプロバイダに対して行われる。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティの関連付けを事前に確立していると仮定する。次いで、第１のデバイスは、メディアコンテンツを解読するための１つ以上のメディアキーの判定を可能にするキー情報を受信する。また、第１のデバイスは、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送し、それによって、第２のデバイスは、コンテンツプロバイダから受信した際にメディアコンテンツを解読することができるようになる。
【００２２】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための、第１のデバイスにおける装置が提供される。この装置によって、第１のデバイスの中のローカル通信ユニットが、第２のデバイスとの間でローカル通信リンクを確立するように構成され、第１のデバイスの中の外部通信ユニットが、第２のデバイスへのメディアコンテンツの配信を求める要求を行うように構成される。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティの関連付けを事前に確立していると仮定し、そして、要求はコンテンツプロバイダに対して行われる。
【００２３】
また、第１のデバイスの中の外部通信ユニットは、メディアコンテンツを解読するための１つ以上のメディアキーの判定を可能にするキー情報を通信ネットワークから受信するように構成される。さらに、第１のデバイスの中のローカル通信ユニットは、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送するように構成され、それによって、第２のデバイスは、コンテンツプロバイダから受信した際にメディアコンテンツを解読することができるようになる。
【００２４】
上記の第１のデバイスにおける方法および装置では、さまざまな実施形態が用いられうる。考えられる一実施形態では、第２のデバイスの接続パラメータが、ローカル通信リンクを経由して取得され、そして、要求は、接続パラメータと共に通信ネットワークへ、またはコンテンツプロバイダへ送信される。考えられるもう１つの実施形態では、確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定される。その場合、第１のデバイスは、各メディアキーに関する情報を連続的に通信ネットワークから、または、コンテンツプロバイダから受信し、それによって、通信ネットワークまたはコンテンツプロバイダは、キー情報の送信を中止することによって、メディアキーによって暗号化されたコンテンツの配信を中止することができるようになる。
【００２５】
第１のデバイスは、さらに、各メディアキーに関連付けられたキー識別子を受信して、キー識別子を第２のデバイスへ転送してもよい。コンテンツプロバイダが、関連付けられたメディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、第２のデバイスにおいて受信されたメディアとメディアキーとの間を同期させる。
【００２６】
また、第１のデバイスは、連続的なメディアキーに関する情報を入手するために、キー情報を求める連続的な要求を送信してもよく、それによって、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができるようになる。その場合、第１のデバイスは、キー情報を求める要求を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で送信してもよく、連続的なメディアキーに関する情報を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応じてＳＩＰ Ｎｏｔｉｆｙメッセージの中で受信してもよい。
【００２７】
上記のキー情報は、１つ以上の明示的なメディアキーまたは、そこからメディアキーが判定されうる、１つ以上の暗示的なメディアキー関連パラメータを含んでいてもよい。事前に確立されたセキュリティの関連付けは基本キーを含んでいてもよく、１つ以上の暗示的なメディアキー関連パラメータは、少なくとも１つのナンスを含んでいてもよく、ここで、メディアキーは、基本キーおよびナンスから判定されてもよい。
【００２８】
考えられる別の実施形態では、第１のデバイスは、要求を通信ネットワークまたはコンテンツプロバイダへ送信する。後者の場合、第１のデバイスは、３ＧＰＰに規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報をコンテンツプロバイダから受信し、そこからメディアキーを生成してもよい。
【００２９】
本発明の考えられる別の機能および利点は、以下の詳細記述の中で説明しよう。
【００３０】
次に、本発明について、例示的な実施形態を使って、そして添付の図面を参照しながら、より詳細に説明しよう。
【図面の簡単な説明】
【００３１】
【図１】先行技術による、ローカルネットワークの中の３ボックスシナリオを示す図である。
【図２】先行技術による、ＩＰＴＶサービスにどのようにアクセスしうるかを略示する図である。
【図３】考えられる一部の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための例示的な手順を示す、通信の概要図である。
【図４】考えられる別の一部の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための別の例示的な手順を示す、通信の概要図である。
【図５】別の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための通信ネットワークにおける手順を示すフローチャートである。
【図６】別の実施形態による、第２のデバイス上でのメディアのセキュアな再生を可能にするための第１のデバイスにおける手順を示すフローチャートである。
【図７】別の実施形態による、本発明の解決策がどのように実際に実装されうるかを詳細に示すシグナリング図である。
【図８】別の実施形態による、第１のデバイスがどのようにメディアコンテンツの配信を制御しうるかを示すシグナリング図である。
【図９】別の実施形態による、通信ネットワークノードおよびユーザデバイスの中の装置をそれぞれ示す概略ブロック図である。
【発明を実施するための形態】
【００３２】
簡単に言うと、本発明を用いることによって、コンテンツプロバイダからメディアコンテンツをレンダリングするためのデバイスまでのメディアコンテンツのセキュアな転送が、ユーザによって操作される別のデバイスによって制御されることが、暗号化と場合によっては転送されるコンテンツの完全性の保護とを以下に述べる形で利用することによって可能になる。
【００３３】
基本的に、レンダリングデバイスへのメディア転送に関する本文脈では制御デバイスとして動作する第１のデバイスは、例えば、ＳＩＭ、ＩＳＩＭ等のような第１のデバイスの中の信用証明書、および、上記の信用証明書を用いて認証手順の一部として確立される共有基本キーを使って、通信ネットワークとのセキュリティの関連付け(security association)を事前に確立している。このようにして第１のデバイスへのセキュアな通信リンクを構築することができ、本解決策ではこれを利用してメディアキーに関する情報をネットワークから第１のデバイスまでセキュアな形で伝達し、それが、暗号化されたメディアコンテンツがコンテンツプロバイダから配信された場合に、第２のデバイスへ転送される。このようにして、第１のデバイスは、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、赤外線、ケーブル接続のような、妨害または盗聴から守られていると考えられるローカルリンクを経由して、ネットワークから受信したキー情報を第２のデバイスへ転送する。従って、第２のデバイスについては、ネットワークへのセキュリティの関連付けもセキュアなリンクも全く必要なく、そして、例えばホテルで、メディアコンテンツをレンダリングするために、いかなる「見知らぬ」訪問先のデバイスであろうと、それを用いることができる。
【００３４】
第１のデバイスがメディアコンテンツを求める要求を行う場合、通信ネットワークの中の適切なノードまたは機能が、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立し、キー情報を第１のデバイスおよびコンテンツプロバイダへ送信する。ネットワークは、第１のデバイスとコンテンツプロバイダとに対してそれぞれ、実装に応じて、同じキー情報を送ってもよいし、異なるキー情報を送ってもよく、それについては以下でもっと詳しく述べよう。
【００３５】
キー情報は、さらに、デバイスの最初の登録の間に、すなわち、コンテンツ要求が行われる前に、第１のデバイスとの間で確立された基本キーに関連していてもよい。第１のデバイスは、コンテンツ要求を、ネットワークかまたは直接コンテンツプロバイダに送信してもよく、それについては、以下で別の例示する手順について述べよう。ネットワークノードは、オペレータが制御するノードであってもよい。説明を簡単にするために、下記の例は、１つのネットワークノードについて述べるであろうが、実際には、２つ以上のノードまたは機能が含まれうるであろうし、従って、本発明は明確な１つのネットワークノードを用いることだけに限定されない。
【００３６】
次いでコンテンツプロバイダは、受信したキー情報からメディアキーを導出し、メディアキーを用いてメディアを暗号化し、そして、暗号化されたメディアをデータストリーミングとファイル転送とのうちいずれか一方を用いて第２のデバイスへ配信することができる。受信されたメディアを第２のデバイスで解読するために、オペレータが制御するネットワークノードまたはコンテンツプロバイダ自身が、メディアキーもしくはそれに関する情報を生成して、第１のデバイスへ送信してもよい。
【００３７】
第１のデバイスおよびコンテンツプロバイダへ送信されたキー情報は、１つ以上の明示的なメディアキーまたは、例えば「ナンス（ｎｏｎｃｅ）」のような、１つ以上の暗示的なメディアキー関連のパラメータを含んでいてもよく、「ナンス（ｎｏｎｃｅ）」とは、「ｎｕｍｂｅｒ ｕｓｅｄ ｏｎｃｅ（一度だけ使われる数）」を表す一般に用いられる用語であるが、本文脈では文字通りにそれに限定されない。次いでメディアキーが、基本キーとナンスとから、例えばナンスおよび前述の基本キーに適用される所定のキー判定機能を使って、導出される。上記のように、第１のデバイスへ送信されるキー情報は、一部の特定の実施形態では、コンテンツプロバイダへ送信されるキー情報とは異なっていてもよい。例えば、コンテンツプロバイダ自身が、暗号化されたキーを生成して、暗号化されたメディアと一緒にまたは別に、第２のデバイスへ送信してもよいし、暗号化されたメディアキーに関連するキー情報も、任意で通信ネットワークにおけるノードもしくは機能を介して第１のデバイスへ送信してもよい。
【００３８】
レンダリングデバイス上でのメディアの許可された取得と再生とを、ユーザによって操作される別のデバイスによって制御することを可能にするための例示的な手順を、図３の通信の概要図に示す。例えば移動電話のような第１のデバイス３００を操作しているユーザが、第２のデバイス３０２、この場合はＴＶ受像機、が利用可能なホテルまたはその他の住宅を訪れていると仮定する。また、第１のデバイスおよびそのユーザは、通信ネットワーク３０４、例えば、マルチメディアサービスを提供しているＩＭＳネットワークかまたは通信アクセスを提供しているアクセスネットワークでありうる、ユーザの「ホームネットワーク」との間でセキュリティの関連付けを事前に確立していると仮定する。この文脈では、ホームネットワークという用語は、基本的に、ユーザの電話加入ネットワークオペレータのことを言う。
【００３９】
また、第１のデバイス３００は、ネットワーク３０４に対する信用証明書として有効なＳＩＭ、ＩＳＩＭまたは同様のエンティティを備えており、ネットワーク３０４に対するサービスについてデバイス３００を、事実上、許可している。上記のように、ネットワーク３０４の中の１つ以上の適切なノードまたは機能が、実装またはネットワークのタイプに応じて、下記の手順のために用いられてよい。例えば、ネットワーク３０４がＩＭＳネットワークである場合、１つ以上のいわゆるＣＳＣＦ（呼セッション制御機能）ノードが、手順に対処する。
【００４０】
この例では、ユーザは、例えば、ＩＰＴＶサービスまたはそれに類するものを用いて、コンテンツプロバイダ３０６から得られうるメディアコンテンツを見たいと望む。しかし、自分自身のデバイス３００は、画面が小さくて音も良くないので、ユーザが満足する程度にコンテンツを再生するには能力不足である。また、コンテンツプロバイダ３０６からデバイス３００へのメディアの転送も、ワイヤレスリンクは通常は帯域幅が限られており、一般に送信コストが高いため、不適切でありうる。しかし、訪問先にあるＴＶ受像機３０２は、より大きく高画質かつ高音質でメディアを提示することが可能であり、しかも、より帯域幅が広くて、かつ、送信コストが安い。従ってユーザは、以下のように、外部レンダリングデバイスとしてＴＶ受像機を利用して、メディアコンテンツを視聴することを望む。
【００４１】
図示する手順では、第１のデバイス３００が、ある時点で第１の操作３：１において、例えばデバイス３００が電源投入された時またはユーザが適切な形で登録を積極的にトリガした時に、用いられるネットワークおよび／またはプロトコルのタイプに応じて、ネットワーク３０４に登録する。登録の間に、デバイス３００は、例えばＳＩＭ／ＩＳＩＭまたはデバイス内のその他の有効な信用証明書ツールを使って、上記の事前に確立されたセキュリティの関連付けに基づいて、ネットワーク３０４との間で認証される。
【００４２】
ネットワーク３０４は、例えばネットワーク内のＩＭＳ ＨＳＳ（ホーム加入者サーバ）に関する、登録手順の間に用いられうる、従来のいわゆる「ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｕｔｈｏｒｉｓａｔｉｏｎ、Ａｃｃｏｕｎｔｉｎｇ）」機能３０４ａを備えていてもよい。認証は、さらに、ＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）に従って行われてもよい。しかし、実装に従って用いられる信用証明書のタイプに応じて、いずれかの適切かつ利用可能な認証手順が用いられてもよく、本発明は、例えば、ＩＳＩＭ信用証明書を用いてＡＫＡによって、あるいは例えばＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ、Ｋｅｒｂｅｒｏｓあるいは証明書に基づく手順を用いる何らかのその他の適切なキー確立手順によって確立された基本キーの形で、ネットワーク３０４および第１のデバイス３００がセキュリティの関連付けを共有する限り、この点で限定されない。
【００４３】
また、通常は、一旦デバイス３００がネットワーク３０４の中で無事に認証されたならば、通信リンクがデバイス３００とネットワーク３０４との間にも確立され、そして、このリンクは、セキュアであるとみなされ、本解決策において秘密の暗号化情報を伝達するために利用される。このリンクのセキュリティは、前述の基本キーまたはそれに関連する何らかのキーから得られてもよい。
【００４４】
また、次の操作３：２において、デバイス３００は、例えばＮＦＣ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＵＳＢケーブル等のような「近距離」通信用の適切な技法を用いてＴＶ受像機３０２との間でローカル通信リンクを確立する。さらに、ローカルリンクが、ＵＰｎＰおよびＤＬＮＡについての上記のメカニズムを用いて確立されてもよいが、本発明は、いかなる個別のタイプのローカルリンクにも限定されない。ローカルリンクは、わずかな距離、空間または場所に限定され、従って、基本的に妨害または盗聴から守られており、それゆえ、同様にセキュアであるとみなすことができると仮定される。
【００４５】
さらに、デバイス３００は、確立されたローカルリンク経由でＴＶ受像機３０２から、例えば、（「ペアリング」手順と呼ばれることもある）ローカルリンクの確立の間に接続パラメータを入手してもよく、それを、ＴＶ受像機３０２との外部通信に用いてもよい。あるいは、ユーザがデバイス３００において手動で読み取って入力できるように、接続パラメータが、単純に、ＴＶ受像機３０２の画面に提示されてもよい。これらの接続パラメータは、ＴＶ受像機３０２に関連付けられたＩＰアドレスまたはその他のネットワークアドレスを含んでいてもよく、それを用いて、公衆ネットワーク経由でメディアがそこへと送信されてもよい。また、ＩＰマルチキャスティングが採用されていて、デバイス３０２がマルチキャストグループのメンバである場合、ＴＶマルチキャストグループに関連付けられたアドレスを用いることも可能である。
【００４６】
次の操作３：３では、ユーザは、コンテンツプロバイダ３０６から入手可能な何らかの所望のメディアコンテンツをすでに選択しており、デバイス３００をトリガして、メディアコンテンツを求める要求を行い、それが、この場合、ネットワーク３０４へ送信される。要求は、コンテンツプロバイダ３０６に対するものであり、そして、ＴＶ受像機３０２の接続パラメータが前もってローカルリンク経由で入手されている場合にはそれらを含むことにより、メディアコンテンツのＴＶ受像機３０２への来たるべき配信のために、ネットワーク３０４がこれらのパラメータをコンテンツプロバイダ３０６へ伝達できてもよい。メディアコンテンツを選択する前に、ユーザは、第１のデバイス３００かＴＶ受像機３０２かいずれか一方からの、コンテンツプロバイダから入手可能ないずれかのコンテンツを求めて、いずれかの適切かつ入手可能な閲覧メカニズムを用いて、閲覧してもよいが、それは、若干、本解決策の範囲外である。
【００４７】
要求を受信する場合、ネットワーク３０４は、デバイス３００が要求されたコンテンツを受信する許可を受けているかどうかをチェックしてもよい。実装によっては、デバイス３００は、以前に操作３：１においてネットワーク３０４との間で認証され許可されていてもよいし、あるいは、要求の後でコンテンツプロバイダ３０６との間でそれが行われてもよい。デバイス３００が適切に許可されていると分かった場合、次の操作３：４において、ネットワーク３０４は、コンテンツ要求をコンテンツプロバイダ３０６へ送信する。操作３：３においてデバイス３００からの要求の中で受信した場合、ネットワーク３０４は、ＴＶ受像機３０２の接続パラメータを要求の中に含める。
【００４８】
次に、ネットワーク３０４は、要求されたメディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立する。ネットワーク３０４は、操作３：５ａにおいて、キー情報の第１の集合をコンテンツプロバイダ３０６へ送信し、操作３：５ｂにおいて、キー情報の第２の集合を第１のデバイス３００へ送信するが、それらの操作は、いかなる適切な順序で行われてもよいし、ほぼ並行して行われてもよい。上記のように、コンテンツプロバイダおよびデバイスへそれぞれ送信されるキー情報の第１および第２の集合は、同じ情報であっても、異なる情報であってもよい。
【００４９】
さらに、デバイス３００は、操作３：６において、受信した自分のキー情報をローカルリンク経由でＴＶ受像機３０２へ転送するであろうし、それによって、ＴＶ受像機３０２は、コンテンツプロバイダ３０６から受信した場合にメディアコンテンツを解読できるようになる。最後の操作３：７に示すように、コンテンツプロバイダ３０６は、操作３：５ｂで受信したキー情報を用いてメディアキーを判定し、要求されたコンテンツをメディアキーを用いて暗号化し、そして、暗号化されたコンテンツをストリーミングまたはファイル転送によってＴＶ受像機３０２へ配信することができる。ファイル転送の場合、ファイルは、デバイスおよび／またはコンテンツプロバイダが、コンテンツ配信が完了する前に転送を中止できるようにするため、連続するチャンクとして配信されてもよいが、それについては以下でより詳細に述べよう。
【００５０】
考えられる別の一部の代替的実施形態では、操作３：５ａ、ｂで送信されるキー情報は、ネットワークによって生成された１つ以上の明示的なメディアキー「ＭＫｊ」または、そこからメディアキーが所定のＫｅｙ Ｄｅｔｅｒｍｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ「ＫＤＦ」（キー判定機能）を用いて導出されうる、１つ以上の暗示的なメディアキー関連のパラメータを含んでいてもよい。
【００５１】
前者の場合、各メディアキーＭＫｊは、第１のデバイスへ送信される場合、「ｋｅｙ ｐｒｏｔｅｃｔｉｎｇ ｋｅｙ、ＫＰＫｊ（キーを保護するキー）」によって暗号化されることが望ましい。また、メディアキーＭＫｊは、コンテンツプロバイダへ送信される時にも暗号化されてもよいが、ただし、このリンク自体は他の手段によって保護されることも可能であろうし、従って、明示的な暗号化は必要ないかもしれない。それゆえ、コンテンツプロバイダへ送信される明示的なキー情報は、第１のデバイスへ送信されるものと必ずしも同じではないが、ただし、最終結果は、第１のデバイスというよりむしろ第２のデバイス、およびコンテンツプロバイダが、場合によっては別の受信されたキー情報に基づくとはいえ、同じメディアキーＭＫｊを入手することができるということである。
【００５２】
後者の場合、暗示的なメディアキー関連のパラメータは、少なくとも１つの自由に選択されたパラメータを含んでいるか、または「ＮＯＮＣＥ（ナンス）」と表されうる値に変更してもよいだろう。ナンスは、任意の数であっても一連の数であってもよい。次いで、メディアキーＭＫｊが、キー判定機能ＫＤＦを用いて、「キーを生成するキー」ＫＧＫｊおよびナンスパラメータから、基本的に以下のように導出されてもよい。
ＭＫｊ＝ＫＤＦ（ＫＧＫｊ、ＮＯＮＣＥ） （１）
【００５３】
上記の前者の場合も後者の場合も、キーを保護するキーＫＰＫｊおよびキーを生成するキーＫＧＫｊは、それぞれ、前述の基本キーまたはそれから導出されたキーであることが望ましい。それゆえ、第１のデバイスへ送信されたキー情報の第２の集合は、第１のデバイスがメディアキーを確立することが可能になるようにそれがキー情報と組み合されているという意味で、この基本キーに関連している。しかし、通常、上記の登録プロセスから第１のデバイスにはすでに知られているため、基本キーをキー情報の中に含めることは必要ではないであろう。
【００５４】
考えられる別の代替的実施形態によれば、キー情報の第１および／または第２の集合は、要求されたメディアコンテンツを暗号化するために所定の順序で用いられる一連のメディアキーに関係していてもよい。その場合、ｊ＝０，１，２，・・・の場合に各メディアキーＭＫｊに関する情報が、ネットワーク３０４から連続的にデバイス３００およびコンテンツプロバイダ３０６へ送信される。考えられる一実施形態では、メディアキーのシーケンスは、各々が前述の基本キーと組み合わされた一連のナンスによって定義される。それゆえ、第１のデバイスへ送信されるキー情報は、１つ以上のナンスを含んでいる。事実上、メディアキーは時間と共に変化する。
【００５５】
データストリーミングとファイル転送とのうちいずれか一方を用いてコンテンツ配信を行う場合、メディアキーは、事前に設定された時間間隔で、または、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。それによって、デバイス３００とコンテンツプロバイダ３０６とのうちいずれかが、通信ネットワークがキー情報を送信するのを中止させることによって、コンテンツの配信を中止させることができる。
【００５６】
例えば、ユーザは、配信されたコンテンツに不満であるか、あるいは、いかなる理由であれ、ＴＶ受像機３０２で適切に受信および／またはレンダリングされないことがありうる。この場合、その後のキーに関する情報は、コンテンツプロバイダ３０６に供給されるべきでなく、コンテンツプロバイダが次のコンテンツを暗号化できないようにすべきである。他方、コンテンツプロバイダ３０６は、誤って許可が行われたか、あるいは、もしあれば、ユーザの支払いもしくはクレジットがコンテンツ配信には不足しているのか等を疑うことがありうる。この場合、デバイス３００は、その後のキーに関する情報を受信すべきでなく、それによって、第２のデバイスは次のコンテンツを解読できないようになる。
【００５７】
図４は、第１のデバイス４００が、通信ネットワーク４０４との間で事前に確立されたセキュリティの関連付けに基づいて、レンダリングデバイス４０２上でのメディアコンテンツの許可された取得および再生を制御できるようにするための、別の例示的な手順を示す図であり、コンテンツは、コンテンツプロバイダ４０６によって配信される。同様に、第２のデバイス４０２を、この例ではＴＶ受像機として示す。この場合、メディアコンテンツを求めるデバイス４００からの最初の要求が、直接、コンテンツプロバイダ４０６へ送信され、それが、次いで、下記のように、キー情報を連続的に第１のデバイス４００へ送信する。前提条件は、その他の点では基本的に図３の場合と同じであり、従って、ここで再び繰り返さない。
【００５８】
以前の例の場合と同様、第１の操作４：１で、第１のデバイス４００がネットワーク４０４に登録し、コンテンツプロバイダ４０６からの来たるべきメディア配信のために、事実上、デバイスを許可し、そして、次の操作４：２で、基本的にそれぞれ上記の操作３：１および３：２のように、デバイス４０２との間でローカルリンクを確立する。また、以前の例の場合と同様、ネットワーク４０４とデバイス４０２との間で共有される基本キーが、通常、この操作で作成される。次に、第２のデバイス４０２へのメディアコンテンツの配信のために、次の操作４：３で、ユーザがデバイス４００をトリガして、今度は要求を直接、コンテンツプロバイダ４０６へ送信する。
【００５９】
次いでコンテンツプロバイダ４０６は、デバイス４００がそのようなメディア配信の許可を受けているかどうかを、次の操作４：４でネットワークに適切な許可クエリを送信することによって、判定する。この場合、デバイス４００が許可を受けていることをネットワーク４０４が確認できると仮定すると、ネットワーク４０４は、要求されたメディアコンテンツを暗号化するための１つ以上のメディアキーの判定のためのキー情報も確立し、操作４：５ａで、キー情報をコンテンツプロバイダ４０６へ送信する。コンテンツプロバイダへ送信されたキー情報は、基本キーすなわちＢＫ、または、一般にそこから導出されたキーすなわちＢＫ’を含んでいてもよい。本実施形態の目的は、第１のデバイスとコンテンツプロバイダとの間で共有される共通キーを作成することである。それゆえ、基本キーＢＫから共通キーＢＫ’が導出される場合、場合によっては、ネットワークは、対応するキー情報ＢＫ’を第１のデバイスが確立できることを、任意の操作４：５ｂで第１のデバイスに対してキー情報を送信することによって、保証する必要もある。
【００６０】
メディアキーのシーケンスＭＫｊ、ｊ＝０，１，２，・・・がメディアの暗号化用に採用される場合、コンテンツプロバイダ４０６は、操作４：５ａで受信したキー情報から、例えばＢＫ’に依存してキーを生成するキーＫＧＫｊと、上記のアルゴリズム（１）の中の一連のナンスとから、メディアキーを生成してもよい。次いで、コンテンツプロバイダ４０６は、操作４：６に示すように、各ナンスを１つずつ、キー情報として第１のデバイス４００へ送信してもよく、それによって第１のデバイス４００は各々の対応するメディアキーを導出して判定し、それを操作４：７で第２のデバイス４０２へ送信できるようになる。あるいは、以前の実施形態と同様に、コンテンツプロバイダは、キーＢＫ’をキーを保護するキーＫＰＫｊとして用いてもよい。
【００６１】
コンテンツプロバイダ４０６は、要求されたメディアコンテンツをメディアキーによって暗号化し、そして、最後の操作４：８に示すように、暗号化されたメディアをデバイス４０２へ配信するであろう。次いで、デバイス４０２は、受信したメディアキーを用いて、コンテンツプロバイダ４０６から受信したメディアコンテンツを解読することができる。あるいは、第１のデバイス４００は、ローカルリンク経由でキーＢＫ’を第２のデバイス４０２へ転送してもよい。次いでコンテンツプロバイダ４０６は、キー情報を直接第２のデバイスへ送信してもよく、次いで、第２のデバイスは、基本キーと受信したキー情報とに基づいてメディアキーをローカルに導出することができる。
【００６２】
基本キーと一連の生成されたランダム値Ｒ１、Ｒ２、・・・とに基づくメディアキーの生成は、３ＧＰＰ ＴＳ ３３．２２０に規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）と呼ばれる既存のメカニズムと同様であり、かつ、それと両立できる。この場合、コンテンツプロバイダは、いわゆるＮＡＦ（Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）として動作するであろうし、デバイスとコンテンツプロバイダとは、多くの場合「ＫＳ＿ＮＡＦ」と表され、「キーを生成するキー」ＫＧＫｊとして用いられる、基本キーを共有する。図４の例では、コンテンツプロバイダ４０６は、操作４：６で、実際のメディアキーを判定するのに用いられる各ナンスおよびランダム値を、キー情報として第１のデバイス４００へ送信するであろうが、ここで、デバイス４００は、メディアキーをそこから、かつ、（１）に従って、事前設定されたＫｅｙ Ｄｅｔｅｒｍｉｎａｔｉｏｎ ＦｕｎｃｔｉｏｎすなわちＫＤＦを用いて、ローカルに生成してもよい。
【００６３】
明らかに、１つ以上の暗号化キーを生成する可能性、および／または、各種のキー情報を第１のデバイスおよび／またはコンテンツプロバイダに伝達する可能性はいくつかあり、本発明は、この点で限定されない。第１のデバイスが、コンテンツプロバイダから第２のデバイスへのコンテンツ配信を制御するためにネットワークによって許可を受けることができ、かつ、第１のデバイスが受信したキー情報を第２のデバイスへローカルリンク経由で転送することができる限り、コンテンツプロバイダと第２のデバイスとの間にメディアキーを転送するためのセキュアな接続は必要ではなく、受信側の第２のデバイスを許可する必要はない。
【００６４】
次に、通信ネットワークにおいてメディアコンテンツプロバイダから第２のデバイス上での再生のためのメディアコンテンツの転送を第１のデバイスを用いて制御することを可能にするための例示的な手順について、図５のフローチャートに関して記述しよう。上記の例と同様に、第１のデバイスは、通信ネットワークとの間でセキュリティ関連付けを事前に確立している。制限なく、図示した手順が、通信ネットワークの中の適切なノードまたは機能によって実行されてよい。
【００６５】
第１のステップ５００で、コンテンツプロバイダに対する、第２のデバイスへのメディアコンテンツの配信を求める第１のデバイスからの要求が、検出される。このコンテンツ要求は、例えば、図３の操作３：３と同様に、ネットワーク自体が第１のデバイスから要求を受信する場合、あるいは、図４の操作４：４と同様に、第１のデバイスが要求をコンテンツプロバイダに直接送信した場合に、ネットワークがコンテンツプロバイダから許可クエリを受信する場合のように、ネットワークによってさまざまな形で検出されてよい。
【００６６】
次のステップ５０２は、第１のデバイスは要求されたメディアコンテンツの配信の許可を受けているかどうかをネットワークが基本的に判定することを示しており、それは、図３および図４の操作３：１および４：１にそれぞれ示すように、先に行われた第１のデバイスの登録に基づいてもよい。第１のデバイスが許可を受けていない場合、実装に応じて、ステップ５０４で、コンテンツ要求は拒否されるかまたはその他の要領で拒絶される。
【００６７】
他方、ステップ５０２で第１のデバイスが許可を受けていることが分かった場合、図４の操作４：３と同様にコンテンツプロバイダによってまだ受信されていないのならば、任意のステップ５０６に示すように、要求は、コンテンツプロバイダへ送信されてもよい。何らかの形でコンテンツ要求を検出した場合、ネットワークは、次のステップ５０８で、キー情報を確立し、それによって、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定が可能になる。上記のように、キー情報は、本発明を限定することなく、複数の異なるやり方で考え出されてよい。確立されたキー情報は、基本的に、第１のデバイスとコンテンツプロバイダとにそれぞれ提供されることになる、キー情報の第１および第２の集合を含んでいる。上記のように、キー情報の第１および第２の集合は、実装に応じて、異なる情報であっても同じ情報であってもよい。
【００６８】
次いで、このようにしてキー情報の第１の集合が、ステップ５１０で、コンテンツプロバイダへ送信され、キー情報の第２の集合が、ステップ５１２で、第１のデバイスへ送信される。それによって、コンテンツプロバイダは、図３および図４の操作３：７および４：８にそれぞれ示すように、メディアキーによって暗号化された要求されたメディアコンテンツを第２のデバイスへ配信することができる。さらに、第１のデバイスは、図３および図４の操作３：６および４：７にそれぞれ示すように、受信したメディアコンテンツを解読するためのメディアキーもしくはそれについての情報をローカル通信リンク経由で第２のデバイスへ転送することができる。
【００６９】
次に、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための第１のデバイスにおける例示的な手順について、図６のフローチャートに関して記述しよう。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティ関連付けを事前に確立していると仮定する。それゆえ、図示するステップは、第１のデバイスによって実行される。
【００７０】
第１のステップ６００で、第１のデバイスは、図３および図４の操作３：１および４：１とそれぞれ同様に、上記の事前に確立されたセキュリティの関連付けに基づくネットワークとの間のデバイスの認証を含めて、例えば、ＳＩＭ／ＩＳＩＭまたはデバイスの中の同様の信用証明書ツールを用いて、ネットワークに登録する。また、通常、ネットワークと共有される基本キーも、登録の際に作成される。次のステップ６０２で、第１のデバイスは、例えば、図３および図４の操作３：２および４：２とそれぞれ同様にＮＦＣ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＵＳＢケーブル等を用いて、第２のデバイスとの間でローカル通信リンクを確立する。ローカルリンクは、他の当事者による盗聴または検出からセキュアであるとみなすことができる。
【００７１】
適切な形でユーザによってトリガされた場合、第１のデバイスは、次のステップ６０４で、第２のデバイスへのメディアコンテンツの配信を求める要求を行うが、要求はコンテンツプロバイダに対するものである。上記のように、第１のデバイスは、図３の操作３：３と同様にコンテンツ要求をネットワークへ送信するかまたは、図４の操作４：３と同様に直接コンテンツプロバイダへ送信してもよい。
【００７２】
次いで、第１のデバイスは、次のステップ６０６で、すなわち、図５の手順の中のキー情報の第２の集合に対応するキー情報を、通信ネットワークから受信し、それによって、メディアコンテンツを解読するための１つの以上のメディアキーの判定が可能になる。この場合もやはり、上記のように、例えば基本キーのような有益なキー情報が通信ネットワークとの間でステップ６００の登録の間に確立されてもよく、そして、例えば、メディアキーがそこから導出されうる、一連のメディアキーまたはナンスのような連続的なキー情報が、要求されたコンテンツの第２のデバイスへの配信の間にコンテンツプロバイダから受信されてもよい。
【００７３】
次いで、第１のデバイスは、図示された最後のステップ６０８で、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送する。それによって、第２のデバイスは、コンテンツプロバイダから受信した場合にメディアコンテンツを、第１のデバイスによって転送されたキー情報を用いて解読することができる。あるいは、基本キーおよび１つ以上のナンスを用いる実施形態では、第１のデバイスは、基本キーとナンスとをキー情報として第２のデバイスへ転送し、第２のデバイスがそこからメディアキーを導出できるようにしてもよい。
【００７４】
通信ネットワークおよび第１のデバイスにおける上記の手順はそれぞれ、一部の例示的実施形態に従って実装されてもよい。例えば、第１のデバイスは、第２のデバイスの接続パラメータをローカル通信リンク経由で入手して、接続パラメータと共にコンテンツ要求を通信ネットワークまたはコンテンツプロバイダへ送信してもよい。このようにして、コンテンツプロバイダは、第２のデバイスの接続パラメータを用いて、メディアをそこへ転送することができるであろう。
【００７５】
さらに、ネットワークによって確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定されることにより、各メディアキーに関する情報が連続的に第１のデバイスへ送信されてもよい。また、各メディアキーに関連付けられたキー識別子が第１のデバイスへ送信されて第２のデバイスへ転送されてもよく、次いで、コンテンツプロバイダが、関連付けられた各メディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、受信されたメディアと第２のデバイスの中のメディアキーとを同期させる。メディアキーは、事前に設定された時間間隔で、あるいは、または、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。
【００７６】
また、その場合、ネットワークは、連続的なメディアキーに関する情報を第１のデバイスへ送信するには、第１のデバイスからのキー情報を求める連続的要求を必要としてもよい。その結果、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができ、従って、ネットワークは、例えば、適切な制御メッセージをコンテンツプロバイダへ送信することによって、あるいは、単純にそれ以上のキー情報をコンテンツプロバイダに送信しないことによって、コンテンツプロバイダが暗号化されたメディアを第２のデバイスへ送信することを止めさせる。
【００７７】
考えられる一実施形態では、メディア配信を中止することは、第２のデバイスによって開始されてもよい。例えば、第２のデバイスが、メディア送信／解読／品質に何らかの誤りを検出し、ローカルリンク経由で障害を第１のデバイスに報告してもよく、今度は第１のデバイスが、キー情報を求める要求を停止するか、または、さらなるメディア配信を中止させるための適切な制御メッセージをネットワークに送信する。制御メッセージは、第１のデバイスとネットワークとだけが知っているキー、例えば、前述の基本キーに関連するキーを用いて認証されることが望ましい。
【００７８】
ＳＩＰが、第１のデバイスとネットワークとの間の通信プロトコルとして用いられる場合、既存のｓｕｂｓｃｒｉｂｅ／ｎｏｔｉｆｙメカニズムが用いられてもよい。それゆえ、第１のデバイスは、キー情報を求める要求をＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージの形で送信してもよく、ネットワークは、ＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージに応じて、連続的なメディアキーに関する情報をＳＩＰ Ｎｏｔｉｆｙメッセージの形で第１のデバイスへ送信してもよい。その場合、第１のデバイスは、加入(subscription)を取り消すことによって、あるいは、ＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージ等の送信を控えることによって、コンテンツ配信を中止することができる。
【００７９】
次に、本発明の解決策が実際にどのようにして実装されうるかの一例を、図７のシグナリング図に関して記述するが、図には、訪問先でのレンダリングデバイスとしてＴＶ受像機７００と、ユーザによって操作される携帯用デバイス７０２と、上記の通信ネットワークを表すＩＭＳコア７０４と、ＩＭＳコア７０４に接続しているコンテンツプロバイダ７０６とが含まれている。上記の例と同様、ユーザデバイス７０２は、ＩＭＳコア７０４との間でセキュリティの関連付けを事前に確立しており、それが以下のように利用される。
【００８０】
第１のステップ７：１は、ユーザデバイス７０２が、ＩＭＳコア７０４に対するユーザデバイス７０２の認証と許可とを含めて、ＩＭＳコア７０４に登録されることを示している。また、このステップは、標準的な表記を用いて（ＣＫ、ＩＫ）と表される基本キーも作成するであろう。詳細には、２つのキーが作成されるが、２つのキーのいずれかの適切な組み合わせまたは相関関係(function)が、基本キーとして識別されうる。次のステップ７：２は、ユーザデバイス７０２が、例えばＢｌｕｅｔｏｏｔｈ、ＵＳＢケーブル等のような、盗聴からセキュアであるとみなされる適切な近距離通信技法を用いて、ＴＶ受像機７００との間でローカルリンクを確立することを示す。次のステップ７：３は、ユーザがＴＶ受像機７００を用いて、コンテンツプロバイダ７０６から入手可能なメディアを閲覧して、ＴＶ受像機７００へ配信するためのメディアコンテンツを選択することを示す。
【００８１】
次のステップ７：４は、ユーザデバイス７０２が、ＴＶ受像機７００からローカルリンク経由で接続パラメータを取得することを示しており、それをコンテンツプロバイダが用いて、要求されたメディアを配信することができる。次いで、次のステップ７：５で、選択されたメディアコンテンツが、ローカルリンク経由でＴＶ受像機７００に転送される。あるいは、ユーザが、ＴＶ受像機７００上で選択されたコンテンツの適切な識別を読み取り、次いで、コンテンツＩＤを手動でユーザデバイス７０２に入力してもよい。
【００８２】
次のステップ７：６で、例えば、ＴＶ受像機７００からローカルリンク経由で、または上記のようにユーザから手動で、コンテンツＩＤが受信された時、デバイス７０２は、選択されたメディアコンテンツを求める要求を行うためにユーザによってトリガされる。この例では、ＴＶ受像機７００の接続パラメータを含むコンテンツ要求が、最初にＩＭＳコア７０４によって受信され、ＩＭＳコア７０４が、要求をコンテンツプロバイダ７０６へさらに転送する。それによって、次のステップ７：７で示すように、メディア暗号化キーＭＫｊの判定を開始するために、ＩＭＳコアもトリガされる。一連のメディアキーとして、ＭＫｊが、連続的な暗号化のために、例えば、図に示すように第１のメディアキーについてｊ＝０が、用いられるであろう。
【００８３】
次いで、ステップ７：８ａで、ＩＭＳコア７０４が、判定されたメディアキーＭＫｊを、この例ではＳＩＰを用いて、１つずつユーザデバイス７０２へ、そして、ステップ７：８ｂでコンテンツプロバイダ７０６へ、それぞれ送信する。この場合、ユーザデバイス７０２とコンテンツプロバイダ７０６とへ送信されるキー情報は同じであり、すなわち、明示的なメディアキーである。
【００８４】
次のステップ７：９は、コンテンツプロバイダ７０６が各キーＭＫｊを用いてメディアを暗号化することを示し、そして、暗号化されたメディアは、次のステップ７：１０で、要求されたコンテンツとしてＴＶ受像機７００へ配信される。また、ユーザデバイス７０２は、次のステップ７：１１で、受信したメディアキーＭＫｊをＴＶ受像機７００へ転送し、次いでステップ７：１２で、ＴＶ受像機７００は受信したメディアを解読し、最後に示すステップ７：１３でそれをレンダリングすることができる。暗号化のために一連のメディアキーＭＫ０、ＭＫ１、ＭＫ２、・・・を用いる場合、配信が完了するか中止されるまで、要求されたコンテンツの連続的な配信の間、ステップ７：７乃至７：１３が繰り返されるのだが、それについては、以下で詳述しよう。次のメディアキーについてステップ７：７が実行される度、ｊ＝ｊ＋１になるようにｊが増加する。
【００８５】
また、上記のように、ステップ７：８ａおよび７：８ｂにおいて、キー識別子が、各メディアキーと共に送信されてもよく、次いで、コンテンツプロバイダが、キー識別子を、関連付けられた各メディアキーによって暗号化されたメディアコンテンツに追加して、受信されたメディアとメディアキーとを第２のデバイスの中で同期させる。ＳＲＴＰ（ＲＦＣ３７１１）プロトコルがメディア配信用に用いられる場合、パケットのいわゆる「ＭＫＩフィールド」を用いて、これらのキー識別子を伝達してもよい。ＩＰｓｅｃが用いられる場合、このやり方で「ＳＰＩフィールド」を用いてもよく、以下同様である。例えば、メディアキーＭＫｊが用いられることになることをシグナリングするために、ＭＫＩフィールドまたはＳＰＩフィールドが「ｊ」の値に設定されてもよく、以下同様である。メディアキーは、事前に設定された時間間隔で変更されてもよく、それはデータストリーミングを用いる場合に適している可能性があり、また、配信されるコンテンツに関する事前に設定されたチャンク数ごとに変更されてもよく、それはファイル転送を用いる場合に適している可能性がある。
【００８６】
また、上記のように、第１のデバイスが、連続的なメディアキーに関する情報を求める連続的な要求を送信することが必要とされてもよく、それによって、これらの要求を使ってコンテンツの配信を制御することができる。図８は、別の実施形態によって、第１のデバイス８０２がどのようにしてメディアコンテンツの第２のデバイス８００への配信を制御できるかをより詳細に示すシグナリング図である。この例では、第１のデバイス８０２は、キー情報を求める連続的な要求を、上記の実施形態によってどちらが連続的なキー情報を第１のデバイスに供給するのかに依存して、合わせて８０４と表す通信ネットワークとコンテンツプロバイダとのうちいずれか一方に送信することが必要とされる。それゆえ、各チャンクの配信またはメディアの間隔は、キー情報要求が第１のデバイスから受信されたか否かに依存する。例えば、第１のデバイスが、以前のメディアキーによって解読されたメディアのレンダリングは正確に進行したと基本的に述べている確認応答を、ローカルリンク経由で第２のデバイスから受信するのに応じて、次のキー要求を生成してもよい。
【００８７】
図示した第１のステップ８：１で、第１のデバイスが、メディアコンテンツの配信を求める要求を行い、その要求は、ネットワークまたはコンテンツプロバイダに送信することができるのだが、これ以降、簡単に「ネットワーク／ＣＰ」８０４と呼ぶ。次いで、ネットワーク／ＣＰ８０４は、ステップ８：２で、キーを生成するキーＫＧＫをデバイス８０２に送信するかまたはその他の形で確立することによって、応答するのだが、それは、上記の基本キーであってもよいだろう。コンテンツ配信を開始するため、デバイス８０２は、次のステップ８：３で、例えばＳＩＰ ｓｕｂｓｃｒｉｂｅメッセージの形で、キー情報要求をネットワーク／ＣＰ８０４へ送信する。それに応じて、ネットワーク／ＣＰ８０４は、次のステップ８：４で、例えばＳＩＰ ｎｏｔｉｆｙメッセージの形で、第１のメディアキーＭＫ（１）に関する情報をデバイス８０２へ送信し、そしてデバイス８０２は、次のステップ８：５で、受信したキー情報および以前に受信したキーを生成するキーＫＧＫから第１のメディアキーＭＫ（１）を導出することができる。キー情報は、ナンスまたは、連続的なメディアキーの各々について変更されるその他の可変パラメータであってもよい。また、上記のように、同期のためにキー識別子がキー情報と共に送信されてもよい。
【００８８】
次いで、ステップ８：６で、デバイス８０２が、図示しない受信されたメディアを解読するため、メディアキーＭＫ（１）を第２のデバイス８００へ転送する。次いでユーザは、デバイス８００によってレンダリングされた場合にコンテンツを視聴またはその他の形で体験することができる。次いで、何らかの適切な時点で、デバイス８０２は、ステップ８：７で、第２のキー情報要求をネットワーク／ＣＰ８０４へ送信し、次いでそれが、次のステップ８：８で、第２のメディアキーＭＫ（２）に関する情報も正しくデバイス８０２に提供する。次のステップ８：９で、受信したキー情報から新たなメディアキーＭＫ（２）を導出した後、デバイス８０２は、ステップ８：１０で、次に受信したメディアを解読するため、キーＭＫ（２）をデバイス８００へ転送し、以下同様である。
【００８９】
連続的なメディアキーを入手するこのプロセスは、例えば、用いられるキーの精度に応じて、および、ユーザがデバイス８００でのレンダリングを続けることを望む場合、何度繰り返されてもよい。また、新たなキー情報の要求のそれぞれの送信が、いかなる適切な形で、例えば、事前に設定された時間間隔での自動要求で、または手動の入力で、制御されてもよい。しかし、ユーザが、何らかの理由で、例えば、レンダリングの結果に満足しなかった場合、または、他の事をしようとする場合、メディア配信を中止することを決定することがある。それゆえ、必要に応じて配信をいつ中止するのかは、完全にユーザ次第である。
【００９０】
ステップ８：１１に示す次のステップは、このようにしてユーザが次のキー情報要求の送信を中止したことを略示しており、要求が行われないので、ネットワーク／ＣＰ８０４は、最後のステップ８：１２で次のメディアの配信を中止する。ネットワークがキー情報要求を受信した場合、配信中止メッセージが、ネットワークから適切な制御チャネル等を経由してコンテンツプロバイダへ伝達される。また、他方、連続的メディアキーを使うこのスキームでは、コンテンツプロバイダまたはネットワークが、相互に依存せず、単純に配信を中止して、新たなメディアキーをデバイス８０２に送信することを停止することによって、それぞれ、コンテンツ配信を中止することも可能である。留意されるべきだが、コンテンツプロバイダは、暗号化されたコンテンツを作成して配信することを、いつでも、単純に、中止してよい。他方、ネットワークは、キー情報を送信しないことによって、事実上、メディア配信を中止することができる。
【００９１】
次に、通信ネットワークの或るノードにおける装置および第１のユーザデバイスにおける装置について、図９のブロック図を参照しながら、より詳細に記述しよう。ネットワークノード９０４は、コンテンツプロバイダ９０６から第２のデバイス９００へのメディアコンテンツの転送を第１のデバイス９０２を用いて制御することを可能にするように構成され、他方、第１のユーザデバイスは、別の実施形態によって、コンテンツプロバイダ９０６からデバイス９００へのメディアコンテンツの転送を制御するように構成される。ネットワークノード９０４および第１のデバイス９０２を用いて、上記の手順および実施形態のいずれかが達成されてもよい。その中のさまざまな機能が、本明細書では「ユニット」と呼ばれているが、それらは、モジュール、ブロック、要素、コンポーネントと考えられてもよいだろう。この場合もやはり、第１のデバイスは、通信ネットワークとの間で事前にセキュリティの関連付けを確立していると仮定する。
【００９２】
図９の装置によれば、ネットワークノード９０４は、メディアコンテンツを第２のデバイスへ配信することを求める第１のデバイスからの要求Ｒを検出するように構成された検出ユニット９０４ａを備えており、要求はコンテンツプロバイダに対するものである。要求は、図３の例のようにデバイス９０２から受信された時に、あるいは、点線の矢印で示すように、図９のコンテンツプロバイダ９０６が、要求を受信して、図４の例のように許可クエリを行う時に、検出されてもよい。
【００９３】
また、ネットワークノード９０４は、メディアコンテンツを暗号化するための１つ以上のメディアキーＭＫｊの判定を可能にするキー情報を確立するように構成されたキーユニット９０４ｂと、ＭＫｊに関するキー情報の第１の集合をコンテンツプロバイダへ送信するように構成された第１の通信ユニット９０４ｃとを備えている。それによって、コンテンツプロバイダは、受信されたキー情報からメディアキーを判定し、メディアキーによって暗号化された要求されたコンテンツを第２のデバイスへ配信することができる。ネットワークノード９０４は、ＭＫｊに関するキー情報の第２の集合を通信リンクを経由して第１のデバイスへ送信するように構成された第２の通信ユニット９０４ｄを備えている。それによって、第１のデバイスは、受信されたメディアコンテンツを解読するためのメディアキーまたはそれについての情報をローカル通信リンク経由で第２のデバイスへ転送することができる。以前の例の場合と同様、キー情報の第１および第２の集合は、同じであってもよいし、互いに異なっていてもよい。
【００９４】
第１のデバイス９０２は、第２のデバイスとの間でローカル通信リンクを確立するように構成されたローカル通信ユニット９０２ａと、メディアコンテンツを第２のデバイス９００へ配信するために、コンテンツプロバイダ９０６に対して要求Ｒを行うように構成された通信ユニット９０２ｂとを備えている。また、コンテンツ要求Ｒは、デバイス９００の接続パラメータＣＰと共に送信されてもよい。外部通信ユニット９０２ｂは、さらに、通信ネットワークからキー情報を、すなわち、上記のキー情報の第２の集合を受信するように構成され、それが、通信ネットワークからのメディアコンテンツを解読するための１つ以上のメディアキーＭＫｊの判定を可能にする。
【００９５】
また、ローカル通信ユニット９０２ａは、さらに、メディアキーまたはＭＫｊについての受信したキー情報をローカル通信リンク経由で第２のデバイスへ転送し、それによって、第２のデバイスは、コンテンツプロバイダから受信した場合にメディアコンテンツを解読することができるようになる。第１のデバイス９０２は、さらに、必要なら、ネットワークから受信したキー情報からメディアキーを判定するためのキーユニット９０２ｃを備えていてもよい。
【００９６】
留意されるべきだが、図９は単に、ネットワークノード９０４およびユーザデバイス９０２の中のさまざまな機能的ユニットまたはモジュールを論理的な意味で示しており、当業者であれば、適切なソフトウェアおよびハードウェア手段を用いて実際にはこれらの機能を自由に実装するであろう。それゆえ、本発明は、一般に、エンティティ９０４および９０２のそれぞれ図示する構造に限定されず、他方、その機能性ユニット９０４ａ乃至ｄおよび９０２ａ乃至ｂは、適切な場合は、図３乃至８について上記で述べた方法および手順に従って動作するように構成されてもよい。
【００９７】
上記の態様および実施形態のいずれかに従って本発明を用いることによって、第１のデバイスのユーザは、いずれかの見知らぬ第２のデバイスに対するメディアコンテンツの許可・制御された転送を、第２のデバイスの許可あるいはそれに対するメディア転送についてのセキュアなリンクを必要とすることなく、開始することができる（もっとも、例えば第２のデバイスがコンテンツプロバイダに対して許可されることを除外する訳ではない）。この解決策は、それゆえ、ユーザフレンドリーであり、柔軟性があり、セキュアにされうる。さらに、連続的な暗号化および複数のメディアキーが用いられる場合、ユーザもコンテンツプロバイダもどちらも、メディアの転送を中止して、プロセスの高度な制御を提供することができる。
【００９８】
本発明について、特定の例示的な実施形態に関して記述してきたが、本記述は、本発明が一部の状況でどのように実装され、用いられうるかを示すことだけを意図しているのであって、本発明を限定すると考えられるべきではない。上記の実施形態を記述する際にＩＰＴＶ、ＩＭＳ、ＳＩＰ、ＩＳＩＭ、ＡＫＡ、ＧＢＡ、ＵＰｎＰ、ＤＬＮＡという概念が用いられているが、基本的に、いずれかのその他の適切な標準、プロトコル、ネットワーク要素が、本書で記述されたコンテンツの暗号化および転送を可能にする目的で用いられてもよい。本発明は、一般に、以下の独立請求項によって定義される。
【技術分野】
【０００１】
本発明は一般に、レンダリングデバイス上でのメディアの再生を可能にするための方法および装置に関し、それらにセキュリティおよび制御を付加したものである。
【背景技術】
【０００２】
さまざまなアクセスネットワークに接続されたユーザ端末のためのマルチメディアサービスおよびマルチメディアセッションを可能にするために、「ＩＰマルチメディアサブシステム（ＩＭＳ）」と呼ばれるアーキテクチャが開発された。さまざまな当事者間のメディアセッションが、シグナリングプロトコルである「ＳＩＰ」（セッション開始プロトコル）およびＲＴＳＰ（リアルタイム・ストリーミングプロトコル）を用いて開始されてもよく、それらは、ＩＭＳサービスオペレータによって制御されるいわゆる「ＩＭＳコア」の中の特定のセッション制御ノードによって制御される。
【０００３】
また、住宅用または事務所用ネットワーク、ＬＡＮ（ローカルエリアネットワーク）、プライベートネットワークもしくはホームネットワークとも呼ばれる、内部的なアドレス指定およびトランスポート手段を用いる限定されたローカルネットワークの中のデバイス間のマルチメディア通信のための技術やプロトコルも確立されている。ローカルネットワークの中のデバイスには、例えば、固定電話、ワイヤレス電話、コンピュータ、メディアプレーヤ、サーバ、および、「ＳＴＢ」（セットトップボックス）とも呼ばれるテレビジョンボックスなどのように、ネットワーク内での通信が可能ないかなるタイプのエンティティが含まれていてもよい。
【０００４】
さまざまなオペレーティングシステム、プログラミング言語、フォーマット標準、通信プロトコルを用いうるさまざまなデバイスの間で、ＵＰｎＰ（ユニバーサル・プラグアンドプレイ）と呼ばれるアーキテクチャを用いてローカルネットワーク内での通信が行われてもよい。さらに、ローカルネットワーク内のデバイスからのメディアコンテンツを取得・記憶し、それにアクセスするために、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）という技術が最近開発された。
【０００５】
ＤＬＮＡでは、さまざまなシナリオに対してさまざまな通信スキームが定義されており、いわゆる「３−ボックス」スキームもそれらの中に含まれる。このシナリオを図１に示すが、それによると、ローカルネットワーク１００の範囲内で第１のデバイスを用いて、ネットワーク内の第２のデバイス上に記憶されたメディアの第３のデバイスへの転送を制御することができる。ここでは、再生能力が限定されている小型の手持ち式のワイヤレス電話１０２が制御デバイスとして用いられ、ラップトップコンピュータ１０４とメディアサーバ１０６とのうちいずれか一方に、手持ち式デバイスおよびラップトップコンピュータと比べてそれらのいずれよりも高い品質でコンテンツを再生することを目的として、メディアコンテンツをＴＶ受像機１０８へストリーミングするよう命令する。このようにして、ＴＶ受像機１０８は「レンダリングデバイス」として用いられる。
【０００６】
また、近年、ＩＰＴＶ（インターネットプロトコルＴＶ）という概念も普及してきており、この場合、ユーザはメディアをＩＰＴＶプロバイダからインターネット経由のストリーミングまたはダウンロードを使って入手することができる。さらに、ＩＰＴＶプロバイダにメディアを要求するのに、ＩＰＴＶプロバイダに対してユーザおよびユーザ端末を許可するための信用証明書としてＩＭＳサブスクリプションを用いることも可能である。また、ユーザは、端末内で従来のＳＩＭ（加入者ＩＤモジュール）カードまたはそれに類するものを用いて移動端末へのＩＰＴＶサービスを受けることもできる。
【０００７】
ＩＭＳサブスクリプションを利用する場合、通常は、ＩＰＴＶサービスにアクセスするには、対応するＩＳＩＭ（ＩＭＳ ＳＩＭ）が必要である。図２は、この状況を示しており、ここではＩＳＩＭがラップトップコンピュータ２００またはその他のＩＭＳ対応通信デバイスの中に設置されていて、それが次いで、ＩＭＳコア２０２を介してＩＰＴＶプロバイダ２０４にメディアを要求する。要求されたコンピュータ２００へのメディア転送をＩＭＳコア２０２が許可した後、ＩＰＴＶプロバイダ２０４は、例えばインターネットのような公衆トランスポートネットワークを経由してメディアがそこへストリーミングまたはダウンロードされうるようにしてもよい。それによって、ユーザは自分のＩＭＳサブスクリプションによって、そして、事前に確立されたＩＭＳオペレータとの間のセキュリティ関係を利用して、かつ、有効な信用証明書を提供するためにＩＳＩＭを用いて、ＩＭＳ対応デバイス２００上でＴＶコンテンツを消費することができる。
【０００８】
加えて、ＩＰＴＶプロバイダから、あるいは、その他のいずれかのコンテンツ、例えばＴＶ番組、映画、いずれかの視覚および／または聴覚コンテンツ、ゲーム関連コンテンツ等のプロバイダから入手されたコンテンツを、ユーザが、外部の訪問先のレンダリングデバイス上で再生できるようにすることが望ましいであろう。例えば、ユーザが、ホテルに滞在するかまたは友人を訪問し、自分のＩＭＳサブスクリプションを用いて、ホテルまたは友人宅のＴＶ受像機でメディアを入手して再生したいと望んだとしよう。しかし、ユーザが、移動可能なＩＳＩＭを訪問先のデバイスに挿入した上で、それを用いてＩＭＳコアにアクセスし、プロバイダからメディアを入手する許可を受けることができない限り、これは不可能であろう。もちろん、多くのユーザデバイス、例えばＴＶ受像機は、そのようなＩＳＩＭまたは対応する移動可能な信用証明書ツールを受信して処理するような備えは持っていない。
【０００９】
訪問先のレンダリングデバイスへのメディアを入手するための有効なＩＭＳ信用証明書またはそれに類するものを使えない場合に挙げられうるもう１つの問題は、ユーザもコンテンツプロバイダもどちらも、レンダリングデバイスに対するメディア転送のセキュアな制御ができないことである。例えば、コンテンツプロバイダは、コンテンツが許可された当事者によってのみアクセスされるのかどうかを知らないかもしれないし、逆に、ユーザは、コンテンツが適切な形で配信されるという確証は持てない。
【００１０】
外部のコンテンツプロバイダからのメディア配信に一般に関連するもう１つの問題は、何らかの理由でユーザが配信に満足していないかまたは配信を受け入れる準備ができていない場合に、メディア転送を中止できないことである。例えば、レンダリングされた品質が、期待される水準に達していない、あるいは、コンテンツが不完全な形で受信されるかまたは全く受信されないことがありうる。さらに、訪問先のレンダリングデバイスが、受信されたメディアフォーマットを適切な形で再生できないことがありうる。しかも、ユーザが、うっかり、間違ったメディアコンテンツまたはメディアタイプを要求していたこと等もありうる。他方、コンテンツプロバイダも、要求側ユーザがメディアの受信を中止したのは、例えば、意図的な電源断に因るものか、あるいは、意図的でない接続性喪失に因るものかを発見することができない。
【発明の概要】
【００１１】
本発明の目的は、基本的に、上記に概説した諸問題の少なくとも一部に取り組むことである。さらに、許可が不可能でありうる、および／またはＩＭＳサブスクリプションを用いることが不可能でありうる訪問先のデバイスへのメディアのセキュアな転送を可能にする解決策を提供することも、目的の１つである。これらの目的等は、以下に添付する独立請求項による方法および装置を提供することによって得られうる。
【００１２】
一態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するために第１のデバイスを使用することを可能にするための、通信ネットワークにおける方法が提供される。第１のデバイスは、通信ネットワークとの間でセキュリティの関連付けを事前に確立していると仮定する。コンテンツプロバイダに対する、第２のデバイスへのメディアコンテンツの配信を求めて第１のデバイスによって行われる要求が検出されると、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報が、確立される。キー情報は、第１のキー情報セット及び第２のキー情報セットを含んでいる。次いで、キー情報の第１のキー情報セットが、コンテンツプロバイダへ送信され、第２のキー情報セットが、第１のデバイスへ送信される。コンテンツプロバイダが、メディアキーによって暗号化された、要求されたメディアコンテンツを第２のデバイスへ配信すると、第１のデバイスは、メディアコンテンツを解読するためのメディアキーまたはそれについての情報を、ローカル通信リンクを経由して第２のデバイスへ転送することができる。
【００１３】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するために第１のデバイスを使用することを可能にするように構成された、通信ネットワークのノードにおける装置が提供され、第１のデバイスは、通信ネットワークとの間でセキュリティの関連付けを事前に確立している。この装置によれば、ネットワークノード内の検出ユニットが、第２のデバイスへのメディアコンテンツの配信を求めて第１のデバイスによって行われる要求を検出するように構成され、要求はコンテンツプロバイダに対して行われる。さらに、ネットワークノード内のキーユニットが、第１のキー情報セット及び第２のキー情報セットを含めて、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立するように構成される。
【００１４】
また、ネットワークノード内の装置は、第１のキー情報セットをコンテンツプロバイダへ送信するように構成された第１の通信ユニットを備えており、それによって、コンテンツプロバイダは、メディアキーによって暗号化された、要求されたコンテンツを第２のデバイスへ配信することができるようになる。また、ネットワークノード内の装置は、第２のキー情報セットを第１のデバイスへ送信するように構成された第２の通信ユニットを備えており、それによって、第１のデバイスは、コンテンツプロバイダによって配信された場合にメディアキーによって暗号化されたメディアコンテンツを解読するためのメディアキーまたはそれについての情報を、ローカル通信リンクを経由して第２のデバイスへ転送することができるようになる。
【００１５】
上記の通信ネットワークにおける方法および装置では、さまざまな実施形態が用いられうる。考えられる一実施形態では、確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定され、各メディアキーに関する情報が、連続的に第１のデバイスへ送信される。それによって、通信ネットワークは、キー情報の送信を中止することによって、メディアキーによって暗号化されたコンテンツの配信を中止することができる。
【００１６】
考えられるもう１つの実施形態では、各メディアキーに関連付けられたキー識別子が、第１のデバイスへ送信されて第２のデバイスへ転送され、コンテンツプロバイダが、関連付けられたメディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、第２のデバイスにおいて受信されたメディアとメディアキーとを同期させる。上記のいずれの実施形態においても、メディアキーは、事前に設定された時間間隔で、あるいは、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。
【００１７】
考えられるもう１つの実施形態では、連続的なメディアキーに関する情報を第１のデバイスへ送信するために、第１のデバイスからのキー情報を求める連続的要求が必要とされる。それによって、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができる。キー情報を求める要求は、第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信されてもよく、連続的なメディアキーに関する情報は、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応じて第１のデバイスへＳＩＰ Ｎｏｔｉｆｙメッセージの中で送信されてもよい。それゆえ、この手順は、既存のＳＩＰメッセージタイプを用いることによって円滑に行うことができる。
【００１８】
考えられる別の実施形態では、キー情報は、１つ以上の明示的なメディアキーまたは、そこからメディアキーが判定されうる、１つ以上の暗示的なメディアキー関連パラメータを含んでいる。事前に確立されたセキュリティの関連付けは、第１の基本キーを含んでいてもよく、１つ以上の暗示的なメディアキー関連パラメータは、少なくとも１つのナンスを含んでいてもよく、ここで、メディアキーは、第１の基本キーおよびナンスから導出されてもよい。さらに、コンテンツプロバイダへ送信される第１のキー情報セットは、第１の基本キーに依存する第２の基本キーを含んでいてもよく、次いで、コンテンツプロバイダは、第２の基本キーを用いて一連のメディアキーを導出し、メディアキーに関する情報を連続的に第１のデバイスへ送信する。
【００１９】
考えられる別の実施形態では、第１のデバイスからのコンテンツ要求は、メディアコンテンツを第２のデバイスへ配信するためにコンテンツプロバイダによって用いられる、第２のデバイスの接続パラメータを含んでいる。
【００２０】
要求は、第１のデバイスからネットワークで受信された時に検出されてもよい。あるいは、要求は、コンテンツプロバイダが第１のデバイスから要求を受信した時に検出されてもよく、そして、コンテンツプロバイダは、３ＧＰＰに規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報を第１のデバイスへ送信してもよく、ここで、第１のデバイスは、そこからメディアキーを生成することができる。
【００２１】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための、第１のデバイスにおける方法が提供される。この方法では、第１のデバイスが、第２のデバイスとの間でローカル通信リンクを確立する。また、第１のデバイスは、第２のデバイスへのメディアコンテンツの配信を求める要求を行い、そして、この要求はコンテンツプロバイダに対して行われる。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティの関連付けを事前に確立していると仮定する。次いで、第１のデバイスは、メディアコンテンツを解読するための１つ以上のメディアキーの判定を可能にするキー情報を受信する。また、第１のデバイスは、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送し、それによって、第２のデバイスは、コンテンツプロバイダから受信した際にメディアコンテンツを解読することができるようになる。
【００２２】
別の態様によって、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための、第１のデバイスにおける装置が提供される。この装置によって、第１のデバイスの中のローカル通信ユニットが、第２のデバイスとの間でローカル通信リンクを確立するように構成され、第１のデバイスの中の外部通信ユニットが、第２のデバイスへのメディアコンテンツの配信を求める要求を行うように構成される。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティの関連付けを事前に確立していると仮定し、そして、要求はコンテンツプロバイダに対して行われる。
【００２３】
また、第１のデバイスの中の外部通信ユニットは、メディアコンテンツを解読するための１つ以上のメディアキーの判定を可能にするキー情報を通信ネットワークから受信するように構成される。さらに、第１のデバイスの中のローカル通信ユニットは、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送するように構成され、それによって、第２のデバイスは、コンテンツプロバイダから受信した際にメディアコンテンツを解読することができるようになる。
【００２４】
上記の第１のデバイスにおける方法および装置では、さまざまな実施形態が用いられうる。考えられる一実施形態では、第２のデバイスの接続パラメータが、ローカル通信リンクを経由して取得され、そして、要求は、接続パラメータと共に通信ネットワークへ、またはコンテンツプロバイダへ送信される。考えられるもう１つの実施形態では、確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定される。その場合、第１のデバイスは、各メディアキーに関する情報を連続的に通信ネットワークから、または、コンテンツプロバイダから受信し、それによって、通信ネットワークまたはコンテンツプロバイダは、キー情報の送信を中止することによって、メディアキーによって暗号化されたコンテンツの配信を中止することができるようになる。
【００２５】
第１のデバイスは、さらに、各メディアキーに関連付けられたキー識別子を受信して、キー識別子を第２のデバイスへ転送してもよい。コンテンツプロバイダが、関連付けられたメディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、第２のデバイスにおいて受信されたメディアとメディアキーとの間を同期させる。
【００２６】
また、第１のデバイスは、連続的なメディアキーに関する情報を入手するために、キー情報を求める連続的な要求を送信してもよく、それによって、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができるようになる。その場合、第１のデバイスは、キー情報を求める要求を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で送信してもよく、連続的なメディアキーに関する情報を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応じてＳＩＰ Ｎｏｔｉｆｙメッセージの中で受信してもよい。
【００２７】
上記のキー情報は、１つ以上の明示的なメディアキーまたは、そこからメディアキーが判定されうる、１つ以上の暗示的なメディアキー関連パラメータを含んでいてもよい。事前に確立されたセキュリティの関連付けは基本キーを含んでいてもよく、１つ以上の暗示的なメディアキー関連パラメータは、少なくとも１つのナンスを含んでいてもよく、ここで、メディアキーは、基本キーおよびナンスから判定されてもよい。
【００２８】
考えられる別の実施形態では、第１のデバイスは、要求を通信ネットワークまたはコンテンツプロバイダへ送信する。後者の場合、第１のデバイスは、３ＧＰＰに規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報をコンテンツプロバイダから受信し、そこからメディアキーを生成してもよい。
【００２９】
本発明の考えられる別の機能および利点は、以下の詳細記述の中で説明しよう。
【００３０】
次に、本発明について、例示的な実施形態を使って、そして添付の図面を参照しながら、より詳細に説明しよう。
【図面の簡単な説明】
【００３１】
【図１】先行技術による、ローカルネットワークの中の３ボックスシナリオを示す図である。
【図２】先行技術による、ＩＰＴＶサービスにどのようにアクセスしうるかを略示する図である。
【図３】考えられる一部の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための例示的な手順を示す、通信の概要図である。
【図４】考えられる別の一部の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための別の例示的な手順を示す、通信の概要図である。
【図５】別の実施形態による、レンダリングデバイス上でのメディアのセキュアな再生を可能にするための通信ネットワークにおける手順を示すフローチャートである。
【図６】別の実施形態による、第２のデバイス上でのメディアのセキュアな再生を可能にするための第１のデバイスにおける手順を示すフローチャートである。
【図７】別の実施形態による、本発明の解決策がどのように実際に実装されうるかを詳細に示すシグナリング図である。
【図８】別の実施形態による、第１のデバイスがどのようにメディアコンテンツの配信を制御しうるかを示すシグナリング図である。
【図９】別の実施形態による、通信ネットワークノードおよびユーザデバイスの中の装置をそれぞれ示す概略ブロック図である。
【発明を実施するための形態】
【００３２】
簡単に言うと、本発明を用いることによって、コンテンツプロバイダからメディアコンテンツをレンダリングするためのデバイスまでのメディアコンテンツのセキュアな転送が、ユーザによって操作される別のデバイスによって制御されることが、暗号化と場合によっては転送されるコンテンツの完全性の保護とを以下に述べる形で利用することによって可能になる。
【００３３】
基本的に、レンダリングデバイスへのメディア転送に関する本文脈では制御デバイスとして動作する第１のデバイスは、例えば、ＳＩＭ、ＩＳＩＭ等のような第１のデバイスの中の信用証明書、および、上記の信用証明書を用いて認証手順の一部として確立される共有基本キーを使って、通信ネットワークとのセキュリティの関連付け(security association)を事前に確立している。このようにして第１のデバイスへのセキュアな通信リンクを構築することができ、本解決策ではこれを利用してメディアキーに関する情報をネットワークから第１のデバイスまでセキュアな形で伝達し、それが、暗号化されたメディアコンテンツがコンテンツプロバイダから配信された場合に、第２のデバイスへ転送される。このようにして、第１のデバイスは、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、赤外線、ケーブル接続のような、妨害または盗聴から守られていると考えられるローカルリンクを経由して、ネットワークから受信したキー情報を第２のデバイスへ転送する。従って、第２のデバイスについては、ネットワークへのセキュリティの関連付けもセキュアなリンクも全く必要なく、そして、例えばホテルで、メディアコンテンツをレンダリングするために、いかなる「見知らぬ」訪問先のデバイスであろうと、それを用いることができる。
【００３４】
第１のデバイスがメディアコンテンツを求める要求を行う場合、通信ネットワークの中の適切なノードまたは機能が、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立し、キー情報を第１のデバイスおよびコンテンツプロバイダへ送信する。ネットワークは、第１のデバイスとコンテンツプロバイダとに対してそれぞれ、実装に応じて、同じキー情報を送ってもよいし、異なるキー情報を送ってもよく、それについては以下でもっと詳しく述べよう。
【００３５】
キー情報は、さらに、デバイスの最初の登録の間に、すなわち、コンテンツ要求が行われる前に、第１のデバイスとの間で確立された基本キーに関連していてもよい。第１のデバイスは、コンテンツ要求を、ネットワークかまたは直接コンテンツプロバイダに送信してもよく、それについては、以下で別の例示する手順について述べよう。ネットワークノードは、オペレータが制御するノードであってもよい。説明を簡単にするために、下記の例は、１つのネットワークノードについて述べるであろうが、実際には、２つ以上のノードまたは機能が含まれうるであろうし、従って、本発明は明確な１つのネットワークノードを用いることだけに限定されない。
【００３６】
次いでコンテンツプロバイダは、受信したキー情報からメディアキーを導出し、メディアキーを用いてメディアを暗号化し、そして、暗号化されたメディアをデータストリーミングとファイル転送とのうちいずれか一方を用いて第２のデバイスへ配信することができる。受信されたメディアを第２のデバイスで解読するために、オペレータが制御するネットワークノードまたはコンテンツプロバイダ自身が、メディアキーもしくはそれに関する情報を生成して、第１のデバイスへ送信してもよい。
【００３７】
第１のデバイスおよびコンテンツプロバイダへ送信されたキー情報は、１つ以上の明示的なメディアキーまたは、例えば「ナンス（ｎｏｎｃｅ）」のような、１つ以上の暗示的なメディアキー関連のパラメータを含んでいてもよく、「ナンス（ｎｏｎｃｅ）」とは、「ｎｕｍｂｅｒ ｕｓｅｄ ｏｎｃｅ（一度だけ使われる数）」を表す一般に用いられる用語であるが、本文脈では文字通りにそれに限定されない。次いでメディアキーが、基本キーとナンスとから、例えばナンスおよび前述の基本キーに適用される所定のキー判定機能を使って、導出される。上記のように、第１のデバイスへ送信されるキー情報は、一部の特定の実施形態では、コンテンツプロバイダへ送信されるキー情報とは異なっていてもよい。例えば、コンテンツプロバイダ自身が、暗号化されたキーを生成して、暗号化されたメディアと一緒にまたは別に、第２のデバイスへ送信してもよいし、暗号化されたメディアキーに関連するキー情報も、任意で通信ネットワークにおけるノードもしくは機能を介して第１のデバイスへ送信してもよい。
【００３８】
レンダリングデバイス上でのメディアの許可された取得と再生とを、ユーザによって操作される別のデバイスによって制御することを可能にするための例示的な手順を、図３の通信の概要図に示す。例えば移動電話のような第１のデバイス３００を操作しているユーザが、第２のデバイス３０２、この場合はＴＶ受像機、が利用可能なホテルまたはその他の住宅を訪れていると仮定する。また、第１のデバイスおよびそのユーザは、通信ネットワーク３０４、例えば、マルチメディアサービスを提供しているＩＭＳネットワークかまたは通信アクセスを提供しているアクセスネットワークでありうる、ユーザの「ホームネットワーク」との間でセキュリティの関連付けを事前に確立していると仮定する。この文脈では、ホームネットワークという用語は、基本的に、ユーザの電話加入ネットワークオペレータのことを言う。
【００３９】
また、第１のデバイス３００は、ネットワーク３０４に対する信用証明書として有効なＳＩＭ、ＩＳＩＭまたは同様のエンティティを備えており、ネットワーク３０４に対するサービスについてデバイス３００を、事実上、許可している。上記のように、ネットワーク３０４の中の１つ以上の適切なノードまたは機能が、実装またはネットワークのタイプに応じて、下記の手順のために用いられてよい。例えば、ネットワーク３０４がＩＭＳネットワークである場合、１つ以上のいわゆるＣＳＣＦ（呼セッション制御機能）ノードが、手順に対処する。
【００４０】
この例では、ユーザは、例えば、ＩＰＴＶサービスまたはそれに類するものを用いて、コンテンツプロバイダ３０６から得られうるメディアコンテンツを見たいと望む。しかし、自分自身のデバイス３００は、画面が小さくて音も良くないので、ユーザが満足する程度にコンテンツを再生するには能力不足である。また、コンテンツプロバイダ３０６からデバイス３００へのメディアの転送も、ワイヤレスリンクは通常は帯域幅が限られており、一般に送信コストが高いため、不適切でありうる。しかし、訪問先にあるＴＶ受像機３０２は、より大きく高画質かつ高音質でメディアを提示することが可能であり、しかも、より帯域幅が広くて、かつ、送信コストが安い。従ってユーザは、以下のように、外部レンダリングデバイスとしてＴＶ受像機を利用して、メディアコンテンツを視聴することを望む。
【００４１】
図示する手順では、第１のデバイス３００が、ある時点で第１の操作３：１において、例えばデバイス３００が電源投入された時またはユーザが適切な形で登録を積極的にトリガした時に、用いられるネットワークおよび／またはプロトコルのタイプに応じて、ネットワーク３０４に登録する。登録の間に、デバイス３００は、例えばＳＩＭ／ＩＳＩＭまたはデバイス内のその他の有効な信用証明書ツールを使って、上記の事前に確立されたセキュリティの関連付けに基づいて、ネットワーク３０４との間で認証される。
【００４２】
ネットワーク３０４は、例えばネットワーク内のＩＭＳ ＨＳＳ（ホーム加入者サーバ）に関する、登録手順の間に用いられうる、従来のいわゆる「ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｕｔｈｏｒｉｓａｔｉｏｎ、Ａｃｃｏｕｎｔｉｎｇ）」機能３０４ａを備えていてもよい。認証は、さらに、ＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）に従って行われてもよい。しかし、実装に従って用いられる信用証明書のタイプに応じて、いずれかの適切かつ利用可能な認証手順が用いられてもよく、本発明は、例えば、ＩＳＩＭ信用証明書を用いてＡＫＡによって、あるいは例えばＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ、Ｋｅｒｂｅｒｏｓあるいは証明書に基づく手順を用いる何らかのその他の適切なキー確立手順によって確立された基本キーの形で、ネットワーク３０４および第１のデバイス３００がセキュリティの関連付けを共有する限り、この点で限定されない。
【００４３】
また、通常は、一旦デバイス３００がネットワーク３０４の中で無事に認証されたならば、通信リンクがデバイス３００とネットワーク３０４との間にも確立され、そして、このリンクは、セキュアであるとみなされ、本解決策において秘密の暗号化情報を伝達するために利用される。このリンクのセキュリティは、前述の基本キーまたはそれに関連する何らかのキーから得られてもよい。
【００４４】
また、次の操作３：２において、デバイス３００は、例えばＮＦＣ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＵＳＢケーブル等のような「近距離」通信用の適切な技法を用いてＴＶ受像機３０２との間でローカル通信リンクを確立する。さらに、ローカルリンクが、ＵＰｎＰおよびＤＬＮＡについての上記のメカニズムを用いて確立されてもよいが、本発明は、いかなる個別のタイプのローカルリンクにも限定されない。ローカルリンクは、わずかな距離、空間または場所に限定され、従って、基本的に妨害または盗聴から守られており、それゆえ、同様にセキュアであるとみなすことができると仮定される。
【００４５】
さらに、デバイス３００は、確立されたローカルリンク経由でＴＶ受像機３０２から、例えば、（「ペアリング」手順と呼ばれることもある）ローカルリンクの確立の間に接続パラメータを入手してもよく、それを、ＴＶ受像機３０２との外部通信に用いてもよい。あるいは、ユーザがデバイス３００において手動で読み取って入力できるように、接続パラメータが、単純に、ＴＶ受像機３０２の画面に提示されてもよい。これらの接続パラメータは、ＴＶ受像機３０２に関連付けられたＩＰアドレスまたはその他のネットワークアドレスを含んでいてもよく、それを用いて、公衆ネットワーク経由でメディアがそこへと送信されてもよい。また、ＩＰマルチキャスティングが採用されていて、デバイス３０２がマルチキャストグループのメンバである場合、ＴＶマルチキャストグループに関連付けられたアドレスを用いることも可能である。
【００４６】
次の操作３：３では、ユーザは、コンテンツプロバイダ３０６から入手可能な何らかの所望のメディアコンテンツをすでに選択しており、デバイス３００をトリガして、メディアコンテンツを求める要求を行い、それが、この場合、ネットワーク３０４へ送信される。要求は、コンテンツプロバイダ３０６に対するものであり、そして、ＴＶ受像機３０２の接続パラメータが前もってローカルリンク経由で入手されている場合にはそれらを含むことにより、メディアコンテンツのＴＶ受像機３０２への来たるべき配信のために、ネットワーク３０４がこれらのパラメータをコンテンツプロバイダ３０６へ伝達できてもよい。メディアコンテンツを選択する前に、ユーザは、第１のデバイス３００かＴＶ受像機３０２かいずれか一方からの、コンテンツプロバイダから入手可能ないずれかのコンテンツを求めて、いずれかの適切かつ入手可能な閲覧メカニズムを用いて、閲覧してもよいが、それは、若干、本解決策の範囲外である。
【００４７】
要求を受信する場合、ネットワーク３０４は、デバイス３００が要求されたコンテンツを受信する許可を受けているかどうかをチェックしてもよい。実装によっては、デバイス３００は、以前に操作３：１においてネットワーク３０４との間で認証され許可されていてもよいし、あるいは、要求の後でコンテンツプロバイダ３０６との間でそれが行われてもよい。デバイス３００が適切に許可されていると分かった場合、次の操作３：４において、ネットワーク３０４は、コンテンツ要求をコンテンツプロバイダ３０６へ送信する。操作３：３においてデバイス３００からの要求の中で受信した場合、ネットワーク３０４は、ＴＶ受像機３０２の接続パラメータを要求の中に含める。
【００４８】
次に、ネットワーク３０４は、要求されたメディアコンテンツを暗号化するための１つ以上のメディアキーの判定を可能にするキー情報を確立する。ネットワーク３０４は、操作３：５ａにおいて、キー情報の第１の集合をコンテンツプロバイダ３０６へ送信し、操作３：５ｂにおいて、キー情報の第２の集合を第１のデバイス３００へ送信するが、それらの操作は、いかなる適切な順序で行われてもよいし、ほぼ並行して行われてもよい。上記のように、コンテンツプロバイダおよびデバイスへそれぞれ送信されるキー情報の第１および第２の集合は、同じ情報であっても、異なる情報であってもよい。
【００４９】
さらに、デバイス３００は、操作３：６において、受信した自分のキー情報をローカルリンク経由でＴＶ受像機３０２へ転送するであろうし、それによって、ＴＶ受像機３０２は、コンテンツプロバイダ３０６から受信した場合にメディアコンテンツを解読できるようになる。最後の操作３：７に示すように、コンテンツプロバイダ３０６は、操作３：５ｂで受信したキー情報を用いてメディアキーを判定し、要求されたコンテンツをメディアキーを用いて暗号化し、そして、暗号化されたコンテンツをストリーミングまたはファイル転送によってＴＶ受像機３０２へ配信することができる。ファイル転送の場合、ファイルは、デバイスおよび／またはコンテンツプロバイダが、コンテンツ配信が完了する前に転送を中止できるようにするため、連続するチャンクとして配信されてもよいが、それについては以下でより詳細に述べよう。
【００５０】
考えられる別の一部の代替的実施形態では、操作３：５ａ、ｂで送信されるキー情報は、ネットワークによって生成された１つ以上の明示的なメディアキー「ＭＫｊ」または、そこからメディアキーが所定のＫｅｙ Ｄｅｔｅｒｍｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ「ＫＤＦ」（キー判定機能）を用いて導出されうる、１つ以上の暗示的なメディアキー関連のパラメータを含んでいてもよい。
【００５１】
前者の場合、各メディアキーＭＫｊは、第１のデバイスへ送信される場合、「ｋｅｙ ｐｒｏｔｅｃｔｉｎｇ ｋｅｙ、ＫＰＫｊ（キーを保護するキー）」によって暗号化されることが望ましい。また、メディアキーＭＫｊは、コンテンツプロバイダへ送信される時にも暗号化されてもよいが、ただし、このリンク自体は他の手段によって保護されることも可能であろうし、従って、明示的な暗号化は必要ないかもしれない。それゆえ、コンテンツプロバイダへ送信される明示的なキー情報は、第１のデバイスへ送信されるものと必ずしも同じではないが、ただし、最終結果は、第１のデバイスというよりむしろ第２のデバイス、およびコンテンツプロバイダが、場合によっては別の受信されたキー情報に基づくとはいえ、同じメディアキーＭＫｊを入手することができるということである。
【００５２】
後者の場合、暗示的なメディアキー関連のパラメータは、少なくとも１つの自由に選択されたパラメータを含んでいるか、または「ＮＯＮＣＥ（ナンス）」と表されうる値に変更してもよいだろう。ナンスは、任意の数であっても一連の数であってもよい。次いで、メディアキーＭＫｊが、キー判定機能ＫＤＦを用いて、「キーを生成するキー」ＫＧＫｊおよびナンスパラメータから、基本的に以下のように導出されてもよい。
ＭＫｊ＝ＫＤＦ（ＫＧＫｊ、ＮＯＮＣＥ） （１）
【００５３】
上記の前者の場合も後者の場合も、キーを保護するキーＫＰＫｊおよびキーを生成するキーＫＧＫｊは、それぞれ、前述の基本キーまたはそれから導出されたキーであることが望ましい。それゆえ、第１のデバイスへ送信されたキー情報の第２の集合は、第１のデバイスがメディアキーを確立することが可能になるようにそれがキー情報と組み合されているという意味で、この基本キーに関連している。しかし、通常、上記の登録プロセスから第１のデバイスにはすでに知られているため、基本キーをキー情報の中に含めることは必要ではないであろう。
【００５４】
考えられる別の代替的実施形態によれば、キー情報の第１および／または第２の集合は、要求されたメディアコンテンツを暗号化するために所定の順序で用いられる一連のメディアキーに関係していてもよい。その場合、ｊ＝０，１，２，・・・の場合に各メディアキーＭＫｊに関する情報が、ネットワーク３０４から連続的にデバイス３００およびコンテンツプロバイダ３０６へ送信される。考えられる一実施形態では、メディアキーのシーケンスは、各々が前述の基本キーと組み合わされた一連のナンスによって定義される。それゆえ、第１のデバイスへ送信されるキー情報は、１つ以上のナンスを含んでいる。事実上、メディアキーは時間と共に変化する。
【００５５】
データストリーミングとファイル転送とのうちいずれか一方を用いてコンテンツ配信を行う場合、メディアキーは、事前に設定された時間間隔で、または、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。それによって、デバイス３００とコンテンツプロバイダ３０６とのうちいずれかが、通信ネットワークがキー情報を送信するのを中止させることによって、コンテンツの配信を中止させることができる。
【００５６】
例えば、ユーザは、配信されたコンテンツに不満であるか、あるいは、いかなる理由であれ、ＴＶ受像機３０２で適切に受信および／またはレンダリングされないことがありうる。この場合、その後のキーに関する情報は、コンテンツプロバイダ３０６に供給されるべきでなく、コンテンツプロバイダが次のコンテンツを暗号化できないようにすべきである。他方、コンテンツプロバイダ３０６は、誤って許可が行われたか、あるいは、もしあれば、ユーザの支払いもしくはクレジットがコンテンツ配信には不足しているのか等を疑うことがありうる。この場合、デバイス３００は、その後のキーに関する情報を受信すべきでなく、それによって、第２のデバイスは次のコンテンツを解読できないようになる。
【００５７】
図４は、第１のデバイス４００が、通信ネットワーク４０４との間で事前に確立されたセキュリティの関連付けに基づいて、レンダリングデバイス４０２上でのメディアコンテンツの許可された取得および再生を制御できるようにするための、別の例示的な手順を示す図であり、コンテンツは、コンテンツプロバイダ４０６によって配信される。同様に、第２のデバイス４０２を、この例ではＴＶ受像機として示す。この場合、メディアコンテンツを求めるデバイス４００からの最初の要求が、直接、コンテンツプロバイダ４０６へ送信され、それが、次いで、下記のように、キー情報を連続的に第１のデバイス４００へ送信する。前提条件は、その他の点では基本的に図３の場合と同じであり、従って、ここで再び繰り返さない。
【００５８】
以前の例の場合と同様、第１の操作４：１で、第１のデバイス４００がネットワーク４０４に登録し、コンテンツプロバイダ４０６からの来たるべきメディア配信のために、事実上、デバイスを許可し、そして、次の操作４：２で、基本的にそれぞれ上記の操作３：１および３：２のように、デバイス４０２との間でローカルリンクを確立する。また、以前の例の場合と同様、ネットワーク４０４とデバイス４０２との間で共有される基本キーが、通常、この操作で作成される。次に、第２のデバイス４０２へのメディアコンテンツの配信のために、次の操作４：３で、ユーザがデバイス４００をトリガして、今度は要求を直接、コンテンツプロバイダ４０６へ送信する。
【００５９】
次いでコンテンツプロバイダ４０６は、デバイス４００がそのようなメディア配信の許可を受けているかどうかを、次の操作４：４でネットワークに適切な許可クエリを送信することによって、判定する。この場合、デバイス４００が許可を受けていることをネットワーク４０４が確認できると仮定すると、ネットワーク４０４は、要求されたメディアコンテンツを暗号化するための１つ以上のメディアキーの判定のためのキー情報も確立し、操作４：５ａで、キー情報をコンテンツプロバイダ４０６へ送信する。コンテンツプロバイダへ送信されたキー情報は、基本キーすなわちＢＫ、または、一般にそこから導出されたキーすなわちＢＫ’を含んでいてもよい。本実施形態の目的は、第１のデバイスとコンテンツプロバイダとの間で共有される共通キーを作成することである。それゆえ、基本キーＢＫから共通キーＢＫ’が導出される場合、場合によっては、ネットワークは、対応するキー情報ＢＫ’を第１のデバイスが確立できることを、任意の操作４：５ｂで第１のデバイスに対してキー情報を送信することによって、保証する必要もある。
【００６０】
メディアキーのシーケンスＭＫｊ、ｊ＝０，１，２，・・・がメディアの暗号化用に採用される場合、コンテンツプロバイダ４０６は、操作４：５ａで受信したキー情報から、例えばＢＫ’に依存してキーを生成するキーＫＧＫｊと、上記のアルゴリズム（１）の中の一連のナンスとから、メディアキーを生成してもよい。次いで、コンテンツプロバイダ４０６は、操作４：６に示すように、各ナンスを１つずつ、キー情報として第１のデバイス４００へ送信してもよく、それによって第１のデバイス４００は各々の対応するメディアキーを導出して判定し、それを操作４：７で第２のデバイス４０２へ送信できるようになる。あるいは、以前の実施形態と同様に、コンテンツプロバイダは、キーＢＫ’をキーを保護するキーＫＰＫｊとして用いてもよい。
【００６１】
コンテンツプロバイダ４０６は、要求されたメディアコンテンツをメディアキーによって暗号化し、そして、最後の操作４：８に示すように、暗号化されたメディアをデバイス４０２へ配信するであろう。次いで、デバイス４０２は、受信したメディアキーを用いて、コンテンツプロバイダ４０６から受信したメディアコンテンツを解読することができる。あるいは、第１のデバイス４００は、ローカルリンク経由でキーＢＫ’を第２のデバイス４０２へ転送してもよい。次いでコンテンツプロバイダ４０６は、キー情報を直接第２のデバイスへ送信してもよく、次いで、第２のデバイスは、基本キーと受信したキー情報とに基づいてメディアキーをローカルに導出することができる。
【００６２】
基本キーと一連の生成されたランダム値Ｒ１、Ｒ２、・・・とに基づくメディアキーの生成は、３ＧＰＰ ＴＳ ３３．２２０に規定されたＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）と呼ばれる既存のメカニズムと同様であり、かつ、それと両立できる。この場合、コンテンツプロバイダは、いわゆるＮＡＦ（Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）として動作するであろうし、デバイスとコンテンツプロバイダとは、多くの場合「ＫＳ＿ＮＡＦ」と表され、「キーを生成するキー」ＫＧＫｊとして用いられる、基本キーを共有する。図４の例では、コンテンツプロバイダ４０６は、操作４：６で、実際のメディアキーを判定するのに用いられる各ナンスおよびランダム値を、キー情報として第１のデバイス４００へ送信するであろうが、ここで、デバイス４００は、メディアキーをそこから、かつ、（１）に従って、事前設定されたＫｅｙ Ｄｅｔｅｒｍｉｎａｔｉｏｎ ＦｕｎｃｔｉｏｎすなわちＫＤＦを用いて、ローカルに生成してもよい。
【００６３】
明らかに、１つ以上の暗号化キーを生成する可能性、および／または、各種のキー情報を第１のデバイスおよび／またはコンテンツプロバイダに伝達する可能性はいくつかあり、本発明は、この点で限定されない。第１のデバイスが、コンテンツプロバイダから第２のデバイスへのコンテンツ配信を制御するためにネットワークによって許可を受けることができ、かつ、第１のデバイスが受信したキー情報を第２のデバイスへローカルリンク経由で転送することができる限り、コンテンツプロバイダと第２のデバイスとの間にメディアキーを転送するためのセキュアな接続は必要ではなく、受信側の第２のデバイスを許可する必要はない。
【００６４】
次に、通信ネットワークにおいてメディアコンテンツプロバイダから第２のデバイス上での再生のためのメディアコンテンツの転送を第１のデバイスを用いて制御することを可能にするための例示的な手順について、図５のフローチャートに関して記述しよう。上記の例と同様に、第１のデバイスは、通信ネットワークとの間でセキュリティ関連付けを事前に確立している。制限なく、図示した手順が、通信ネットワークの中の適切なノードまたは機能によって実行されてよい。
【００６５】
第１のステップ５００で、コンテンツプロバイダに対する、第２のデバイスへのメディアコンテンツの配信を求める第１のデバイスからの要求が、検出される。このコンテンツ要求は、例えば、図３の操作３：３と同様に、ネットワーク自体が第１のデバイスから要求を受信する場合、あるいは、図４の操作４：４と同様に、第１のデバイスが要求をコンテンツプロバイダに直接送信した場合に、ネットワークがコンテンツプロバイダから許可クエリを受信する場合のように、ネットワークによってさまざまな形で検出されてよい。
【００６６】
次のステップ５０２は、第１のデバイスは要求されたメディアコンテンツの配信の許可を受けているかどうかをネットワークが基本的に判定することを示しており、それは、図３および図４の操作３：１および４：１にそれぞれ示すように、先に行われた第１のデバイスの登録に基づいてもよい。第１のデバイスが許可を受けていない場合、実装に応じて、ステップ５０４で、コンテンツ要求は拒否されるかまたはその他の要領で拒絶される。
【００６７】
他方、ステップ５０２で第１のデバイスが許可を受けていることが分かった場合、図４の操作４：３と同様にコンテンツプロバイダによってまだ受信されていないのならば、任意のステップ５０６に示すように、要求は、コンテンツプロバイダへ送信されてもよい。何らかの形でコンテンツ要求を検出した場合、ネットワークは、次のステップ５０８で、キー情報を確立し、それによって、メディアコンテンツを暗号化するための１つ以上のメディアキーの判定が可能になる。上記のように、キー情報は、本発明を限定することなく、複数の異なるやり方で考え出されてよい。確立されたキー情報は、基本的に、第１のデバイスとコンテンツプロバイダとにそれぞれ提供されることになる、キー情報の第１および第２の集合を含んでいる。上記のように、キー情報の第１および第２の集合は、実装に応じて、異なる情報であっても同じ情報であってもよい。
【００６８】
次いで、このようにしてキー情報の第１の集合が、ステップ５１０で、コンテンツプロバイダへ送信され、キー情報の第２の集合が、ステップ５１２で、第１のデバイスへ送信される。それによって、コンテンツプロバイダは、図３および図４の操作３：７および４：８にそれぞれ示すように、メディアキーによって暗号化された要求されたメディアコンテンツを第２のデバイスへ配信することができる。さらに、第１のデバイスは、図３および図４の操作３：６および４：７にそれぞれ示すように、受信したメディアコンテンツを解読するためのメディアキーもしくはそれについての情報をローカル通信リンク経由で第２のデバイスへ転送することができる。
【００６９】
次に、コンテンツプロバイダから第２のデバイスへのメディアコンテンツの転送を制御するための第１のデバイスにおける例示的な手順について、図６のフローチャートに関して記述しよう。この場合もやはり、第１のデバイスは、通信ネットワークとのセキュリティ関連付けを事前に確立していると仮定する。それゆえ、図示するステップは、第１のデバイスによって実行される。
【００７０】
第１のステップ６００で、第１のデバイスは、図３および図４の操作３：１および４：１とそれぞれ同様に、上記の事前に確立されたセキュリティの関連付けに基づくネットワークとの間のデバイスの認証を含めて、例えば、ＳＩＭ／ＩＳＩＭまたはデバイスの中の同様の信用証明書ツールを用いて、ネットワークに登録する。また、通常、ネットワークと共有される基本キーも、登録の際に作成される。次のステップ６０２で、第１のデバイスは、例えば、図３および図４の操作３：２および４：２とそれぞれ同様にＮＦＣ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＵＳＢケーブル等を用いて、第２のデバイスとの間でローカル通信リンクを確立する。ローカルリンクは、他の当事者による盗聴または検出からセキュアであるとみなすことができる。
【００７１】
適切な形でユーザによってトリガされた場合、第１のデバイスは、次のステップ６０４で、第２のデバイスへのメディアコンテンツの配信を求める要求を行うが、要求はコンテンツプロバイダに対するものである。上記のように、第１のデバイスは、図３の操作３：３と同様にコンテンツ要求をネットワークへ送信するかまたは、図４の操作４：３と同様に直接コンテンツプロバイダへ送信してもよい。
【００７２】
次いで、第１のデバイスは、次のステップ６０６で、すなわち、図５の手順の中のキー情報の第２の集合に対応するキー情報を、通信ネットワークから受信し、それによって、メディアコンテンツを解読するための１つの以上のメディアキーの判定が可能になる。この場合もやはり、上記のように、例えば基本キーのような有益なキー情報が通信ネットワークとの間でステップ６００の登録の間に確立されてもよく、そして、例えば、メディアキーがそこから導出されうる、一連のメディアキーまたはナンスのような連続的なキー情報が、要求されたコンテンツの第２のデバイスへの配信の間にコンテンツプロバイダから受信されてもよい。
【００７３】
次いで、第１のデバイスは、図示された最後のステップ６０８で、メディアキーまたはキー情報をローカル通信リンクを経由して第２のデバイスへ転送する。それによって、第２のデバイスは、コンテンツプロバイダから受信した場合にメディアコンテンツを、第１のデバイスによって転送されたキー情報を用いて解読することができる。あるいは、基本キーおよび１つ以上のナンスを用いる実施形態では、第１のデバイスは、基本キーとナンスとをキー情報として第２のデバイスへ転送し、第２のデバイスがそこからメディアキーを導出できるようにしてもよい。
【００７４】
通信ネットワークおよび第１のデバイスにおける上記の手順はそれぞれ、一部の例示的実施形態に従って実装されてもよい。例えば、第１のデバイスは、第２のデバイスの接続パラメータをローカル通信リンク経由で入手して、接続パラメータと共にコンテンツ要求を通信ネットワークまたはコンテンツプロバイダへ送信してもよい。このようにして、コンテンツプロバイダは、第２のデバイスの接続パラメータを用いて、メディアをそこへ転送することができるであろう。
【００７５】
さらに、ネットワークによって確立されたキー情報を用いて、要求されたメディアコンテンツを暗号化するために所定の順序で用いられることになる一連のメディアキーが判定されることにより、各メディアキーに関する情報が連続的に第１のデバイスへ送信されてもよい。また、各メディアキーに関連付けられたキー識別子が第１のデバイスへ送信されて第２のデバイスへ転送されてもよく、次いで、コンテンツプロバイダが、関連付けられた各メディアキーによって暗号化されたメディアコンテンツにキー識別子を追加して、受信されたメディアと第２のデバイスの中のメディアキーとを同期させる。メディアキーは、事前に設定された時間間隔で、あるいは、または、配信されるコンテンツに関する事前に設定されたチャンク数ごとに、変更されてもよい。
【００７６】
また、その場合、ネットワークは、連続的なメディアキーに関する情報を第１のデバイスへ送信するには、第１のデバイスからのキー情報を求める連続的要求を必要としてもよい。その結果、第１のデバイスは、キー情報を求める要求を停止することによって、コンテンツの配信を中止することができ、従って、ネットワークは、例えば、適切な制御メッセージをコンテンツプロバイダへ送信することによって、あるいは、単純にそれ以上のキー情報をコンテンツプロバイダに送信しないことによって、コンテンツプロバイダが暗号化されたメディアを第２のデバイスへ送信することを止めさせる。
【００７７】
考えられる一実施形態では、メディア配信を中止することは、第２のデバイスによって開始されてもよい。例えば、第２のデバイスが、メディア送信／解読／品質に何らかの誤りを検出し、ローカルリンク経由で障害を第１のデバイスに報告してもよく、今度は第１のデバイスが、キー情報を求める要求を停止するか、または、さらなるメディア配信を中止させるための適切な制御メッセージをネットワークに送信する。制御メッセージは、第１のデバイスとネットワークとだけが知っているキー、例えば、前述の基本キーに関連するキーを用いて認証されることが望ましい。
【００７８】
ＳＩＰが、第１のデバイスとネットワークとの間の通信プロトコルとして用いられる場合、既存のｓｕｂｓｃｒｉｂｅ／ｎｏｔｉｆｙメカニズムが用いられてもよい。それゆえ、第１のデバイスは、キー情報を求める要求をＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージの形で送信してもよく、ネットワークは、ＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージに応じて、連続的なメディアキーに関する情報をＳＩＰ Ｎｏｔｉｆｙメッセージの形で第１のデバイスへ送信してもよい。その場合、第１のデバイスは、加入(subscription)を取り消すことによって、あるいは、ＳＩＰ ＳｕｂｓｃｒｉｂｅメッセージまたはＳＩＰ ＯＫメッセージ等の送信を控えることによって、コンテンツ配信を中止することができる。
【００７９】
次に、本発明の解決策が実際にどのようにして実装されうるかの一例を、図７のシグナリング図に関して記述するが、図には、訪問先でのレンダリングデバイスとしてＴＶ受像機７００と、ユーザによって操作される携帯用デバイス７０２と、上記の通信ネットワークを表すＩＭＳコア７０４と、ＩＭＳコア７０４に接続しているコンテンツプロバイダ７０６とが含まれている。上記の例と同様、ユーザデバイス７０２は、ＩＭＳコア７０４との間でセキュリティの関連付けを事前に確立しており、それが以下のように利用される。
【００８０】
第１のステップ７：１は、ユーザデバイス７０２が、ＩＭＳコア７０４に対するユーザデバイス７０２の認証と許可とを含めて、ＩＭＳコア７０４に登録されることを示している。また、このステップは、標準的な表記を用いて（ＣＫ、ＩＫ）と表される基本キーも作成するであろう。詳細には、２つのキーが作成されるが、２つのキーのいずれかの適切な組み合わせまたは相関関係(function)が、基本キーとして識別されうる。次のステップ７：２は、ユーザデバイス７０２が、例えばＢｌｕｅｔｏｏｔｈ、ＵＳＢケーブル等のような、盗聴からセキュアであるとみなされる適切な近距離通信技法を用いて、ＴＶ受像機７００との間でローカルリンクを確立することを示す。次のステップ７：３は、ユーザがＴＶ受像機７００を用いて、コンテンツプロバイダ７０６から入手可能なメディアを閲覧して、ＴＶ受像機７００へ配信するためのメディアコンテンツを選択することを示す。
【００８１】
次のステップ７：４は、ユーザデバイス７０２が、ＴＶ受像機７００からローカルリンク経由で接続パラメータを取得することを示しており、それをコンテンツプロバイダが用いて、要求されたメディアを配信することができる。次いで、次のステップ７：５で、選択されたメディアコンテンツが、ローカルリンク経由でＴＶ受像機７００に転送される。あるいは、ユーザが、ＴＶ受像機７００上で選択されたコンテンツの適切な識別を読み取り、次いで、コンテンツＩＤを手動でユーザデバイス７０２に入力してもよい。
【００８２】
次のステップ７：６で、例えば、ＴＶ受像機７００からローカルリンク経由で、または上記のようにユーザから手動で、コンテンツＩＤが受信された時、デバイス７０２は、選択されたメディアコンテンツを求める要求を行うためにユーザによってトリガされる。この例では、ＴＶ受像機７００の接続パラメータを含むコンテンツ要求が、最初にＩＭＳコア７０４によって受信され、ＩＭＳコア７０４が、要求をコンテンツプロバイダ７０６へさらに転送する。それによって、次のステップ７：７で示すように、メディア暗号化キーＭＫｊの判定を開始するために、ＩＭＳコアもトリガされる。一連のメディアキーとして、ＭＫｊが、連続的な暗号化のために、例えば、図に示すように第１のメディアキーについてｊ＝０が、用いられるであろう。
【００８３】
次いで、ステップ７：８ａで、ＩＭＳコア７０４が、判定されたメディアキーＭＫｊを、この例ではＳＩＰを用いて、１つずつユーザデバイス７０２へ、そして、ステップ７：８ｂでコンテンツプロバイダ７０６へ、それぞれ送信する。この場合、ユーザデバイス７０２とコンテンツプロバイダ７０６とへ送信されるキー情報は同じであり、すなわち、明示的なメディアキーである。
【００８４】
次のステップ７：９は、コンテンツプロバイダ７０６が各キーＭＫｊを用いてメディアを暗号化することを示し、そして、暗号化されたメディアは、次のステップ７：１０で、要求されたコンテンツとしてＴＶ受像機７００へ配信される。また、ユーザデバイス７０２は、次のステップ７：１１で、受信したメディアキーＭＫｊをＴＶ受像機７００へ転送し、次いでステップ７：１２で、ＴＶ受像機７００は受信したメディアを解読し、最後に示すステップ７：１３でそれをレンダリングすることができる。暗号化のために一連のメディアキーＭＫ０、ＭＫ１、ＭＫ２、・・・を用いる場合、配信が完了するか中止されるまで、要求されたコンテンツの連続的な配信の間、ステップ７：７乃至７：１３が繰り返されるのだが、それについては、以下で詳述しよう。次のメディアキーについてステップ７：７が実行される度、ｊ＝ｊ＋１になるようにｊが増加する。
【００８５】
また、上記のように、ステップ７：８ａおよび７：８ｂにおいて、キー識別子が、各メディアキーと共に送信されてもよく、次いで、コンテンツプロバイダが、キー識別子を、関連付けられた各メディアキーによって暗号化されたメディアコンテンツに追加して、受信されたメディアとメディアキーとを第２のデバイスの中で同期させる。ＳＲＴＰ（ＲＦＣ３７１１）プロトコルがメディア配信用に用いられる場合、パケットのいわゆる「ＭＫＩフィールド」を用いて、これらのキー識別子を伝達してもよい。ＩＰｓｅｃが用いられる場合、このやり方で「ＳＰＩフィールド」を用いてもよく、以下同様である。例えば、メディアキーＭＫｊが用いられることになることをシグナリングするために、ＭＫＩフィールドまたはＳＰＩフィールドが「ｊ」の値に設定されてもよく、以下同様である。メディアキーは、事前に設定された時間間隔で変更されてもよく、それはデータストリーミングを用いる場合に適している可能性があり、また、配信されるコンテンツに関する事前に設定されたチャンク数ごとに変更されてもよく、それはファイル転送を用いる場合に適している可能性がある。
【００８６】
また、上記のように、第１のデバイスが、連続的なメディアキーに関する情報を求める連続的な要求を送信することが必要とされてもよく、それによって、これらの要求を使ってコンテンツの配信を制御することができる。図８は、別の実施形態によって、第１のデバイス８０２がどのようにしてメディアコンテンツの第２のデバイス８００への配信を制御できるかをより詳細に示すシグナリング図である。この例では、第１のデバイス８０２は、キー情報を求める連続的な要求を、上記の実施形態によってどちらが連続的なキー情報を第１のデバイスに供給するのかに依存して、合わせて８０４と表す通信ネットワークとコンテンツプロバイダとのうちいずれか一方に送信することが必要とされる。それゆえ、各チャンクの配信またはメディアの間隔は、キー情報要求が第１のデバイスから受信されたか否かに依存する。例えば、第１のデバイスが、以前のメディアキーによって解読されたメディアのレンダリングは正確に進行したと基本的に述べている確認応答を、ローカルリンク経由で第２のデバイスから受信するのに応じて、次のキー要求を生成してもよい。
【００８７】
図示した第１のステップ８：１で、第１のデバイスが、メディアコンテンツの配信を求める要求を行い、その要求は、ネットワークまたはコンテンツプロバイダに送信することができるのだが、これ以降、簡単に「ネットワーク／ＣＰ」８０４と呼ぶ。次いで、ネットワーク／ＣＰ８０４は、ステップ８：２で、キーを生成するキーＫＧＫをデバイス８０２に送信するかまたはその他の形で確立することによって、応答するのだが、それは、上記の基本キーであってもよいだろう。コンテンツ配信を開始するため、デバイス８０２は、次のステップ８：３で、例えばＳＩＰ ｓｕｂｓｃｒｉｂｅメッセージの形で、キー情報要求をネットワーク／ＣＰ８０４へ送信する。それに応じて、ネットワーク／ＣＰ８０４は、次のステップ８：４で、例えばＳＩＰ ｎｏｔｉｆｙメッセージの形で、第１のメディアキーＭＫ（１）に関する情報をデバイス８０２へ送信し、そしてデバイス８０２は、次のステップ８：５で、受信したキー情報および以前に受信したキーを生成するキーＫＧＫから第１のメディアキーＭＫ（１）を導出することができる。キー情報は、ナンスまたは、連続的なメディアキーの各々について変更されるその他の可変パラメータであってもよい。また、上記のように、同期のためにキー識別子がキー情報と共に送信されてもよい。
【００８８】
次いで、ステップ８：６で、デバイス８０２が、図示しない受信されたメディアを解読するため、メディアキーＭＫ（１）を第２のデバイス８００へ転送する。次いでユーザは、デバイス８００によってレンダリングされた場合にコンテンツを視聴またはその他の形で体験することができる。次いで、何らかの適切な時点で、デバイス８０２は、ステップ８：７で、第２のキー情報要求をネットワーク／ＣＰ８０４へ送信し、次いでそれが、次のステップ８：８で、第２のメディアキーＭＫ（２）に関する情報も正しくデバイス８０２に提供する。次のステップ８：９で、受信したキー情報から新たなメディアキーＭＫ（２）を導出した後、デバイス８０２は、ステップ８：１０で、次に受信したメディアを解読するため、キーＭＫ（２）をデバイス８００へ転送し、以下同様である。
【００８９】
連続的なメディアキーを入手するこのプロセスは、例えば、用いられるキーの精度に応じて、および、ユーザがデバイス８００でのレンダリングを続けることを望む場合、何度繰り返されてもよい。また、新たなキー情報の要求のそれぞれの送信が、いかなる適切な形で、例えば、事前に設定された時間間隔での自動要求で、または手動の入力で、制御されてもよい。しかし、ユーザが、何らかの理由で、例えば、レンダリングの結果に満足しなかった場合、または、他の事をしようとする場合、メディア配信を中止することを決定することがある。それゆえ、必要に応じて配信をいつ中止するのかは、完全にユーザ次第である。
【００９０】
ステップ８：１１に示す次のステップは、このようにしてユーザが次のキー情報要求の送信を中止したことを略示しており、要求が行われないので、ネットワーク／ＣＰ８０４は、最後のステップ８：１２で次のメディアの配信を中止する。ネットワークがキー情報要求を受信した場合、配信中止メッセージが、ネットワークから適切な制御チャネル等を経由してコンテンツプロバイダへ伝達される。また、他方、連続的メディアキーを使うこのスキームでは、コンテンツプロバイダまたはネットワークが、相互に依存せず、単純に配信を中止して、新たなメディアキーをデバイス８０２に送信することを停止することによって、それぞれ、コンテンツ配信を中止することも可能である。留意されるべきだが、コンテンツプロバイダは、暗号化されたコンテンツを作成して配信することを、いつでも、単純に、中止してよい。他方、ネットワークは、キー情報を送信しないことによって、事実上、メディア配信を中止することができる。
【００９１】
次に、通信ネットワークの或るノードにおける装置および第１のユーザデバイスにおける装置について、図９のブロック図を参照しながら、より詳細に記述しよう。ネットワークノード９０４は、コンテンツプロバイダ９０６から第２のデバイス９００へのメディアコンテンツの転送を第１のデバイス９０２を用いて制御することを可能にするように構成され、他方、第１のユーザデバイスは、別の実施形態によって、コンテンツプロバイダ９０６からデバイス９００へのメディアコンテンツの転送を制御するように構成される。ネットワークノード９０４および第１のデバイス９０２を用いて、上記の手順および実施形態のいずれかが達成されてもよい。その中のさまざまな機能が、本明細書では「ユニット」と呼ばれているが、それらは、モジュール、ブロック、要素、コンポーネントと考えられてもよいだろう。この場合もやはり、第１のデバイスは、通信ネットワークとの間で事前にセキュリティの関連付けを確立していると仮定する。
【００９２】
図９の装置によれば、ネットワークノード９０４は、メディアコンテンツを第２のデバイスへ配信することを求める第１のデバイスからの要求Ｒを検出するように構成された検出ユニット９０４ａを備えており、要求はコンテンツプロバイダに対するものである。要求は、図３の例のようにデバイス９０２から受信された時に、あるいは、点線の矢印で示すように、図９のコンテンツプロバイダ９０６が、要求を受信して、図４の例のように許可クエリを行う時に、検出されてもよい。
【００９３】
また、ネットワークノード９０４は、メディアコンテンツを暗号化するための１つ以上のメディアキーＭＫｊの判定を可能にするキー情報を確立するように構成されたキーユニット９０４ｂと、ＭＫｊに関するキー情報の第１の集合をコンテンツプロバイダへ送信するように構成された第１の通信ユニット９０４ｃとを備えている。それによって、コンテンツプロバイダは、受信されたキー情報からメディアキーを判定し、メディアキーによって暗号化された要求されたコンテンツを第２のデバイスへ配信することができる。ネットワークノード９０４は、ＭＫｊに関するキー情報の第２の集合を通信リンクを経由して第１のデバイスへ送信するように構成された第２の通信ユニット９０４ｄを備えている。それによって、第１のデバイスは、受信されたメディアコンテンツを解読するためのメディアキーまたはそれについての情報をローカル通信リンク経由で第２のデバイスへ転送することができる。以前の例の場合と同様、キー情報の第１および第２の集合は、同じであってもよいし、互いに異なっていてもよい。
【００９４】
第１のデバイス９０２は、第２のデバイスとの間でローカル通信リンクを確立するように構成されたローカル通信ユニット９０２ａと、メディアコンテンツを第２のデバイス９００へ配信するために、コンテンツプロバイダ９０６に対して要求Ｒを行うように構成された通信ユニット９０２ｂとを備えている。また、コンテンツ要求Ｒは、デバイス９００の接続パラメータＣＰと共に送信されてもよい。外部通信ユニット９０２ｂは、さらに、通信ネットワークからキー情報を、すなわち、上記のキー情報の第２の集合を受信するように構成され、それが、通信ネットワークからのメディアコンテンツを解読するための１つ以上のメディアキーＭＫｊの判定を可能にする。
【００９５】
また、ローカル通信ユニット９０２ａは、さらに、メディアキーまたはＭＫｊについての受信したキー情報をローカル通信リンク経由で第２のデバイスへ転送し、それによって、第２のデバイスは、コンテンツプロバイダから受信した場合にメディアコンテンツを解読することができるようになる。第１のデバイス９０２は、さらに、必要なら、ネットワークから受信したキー情報からメディアキーを判定するためのキーユニット９０２ｃを備えていてもよい。
【００９６】
留意されるべきだが、図９は単に、ネットワークノード９０４およびユーザデバイス９０２の中のさまざまな機能的ユニットまたはモジュールを論理的な意味で示しており、当業者であれば、適切なソフトウェアおよびハードウェア手段を用いて実際にはこれらの機能を自由に実装するであろう。それゆえ、本発明は、一般に、エンティティ９０４および９０２のそれぞれ図示する構造に限定されず、他方、その機能性ユニット９０４ａ乃至ｄおよび９０２ａ乃至ｂは、適切な場合は、図３乃至８について上記で述べた方法および手順に従って動作するように構成されてもよい。
【００９７】
上記の態様および実施形態のいずれかに従って本発明を用いることによって、第１のデバイスのユーザは、いずれかの見知らぬ第２のデバイスに対するメディアコンテンツの許可・制御された転送を、第２のデバイスの許可あるいはそれに対するメディア転送についてのセキュアなリンクを必要とすることなく、開始することができる（もっとも、例えば第２のデバイスがコンテンツプロバイダに対して許可されることを除外する訳ではない）。この解決策は、それゆえ、ユーザフレンドリーであり、柔軟性があり、セキュアにされうる。さらに、連続的な暗号化および複数のメディアキーが用いられる場合、ユーザもコンテンツプロバイダもどちらも、メディアの転送を中止して、プロセスの高度な制御を提供することができる。
【００９８】
本発明について、特定の例示的な実施形態に関して記述してきたが、本記述は、本発明が一部の状況でどのように実装され、用いられうるかを示すことだけを意図しているのであって、本発明を限定すると考えられるべきではない。上記の実施形態を記述する際にＩＰＴＶ、ＩＭＳ、ＳＩＰ、ＩＳＩＭ、ＡＫＡ、ＧＢＡ、ＵＰｎＰ、ＤＬＮＡという概念が用いられているが、基本的に、いずれかのその他の適切な標準、プロトコル、ネットワーク要素が、本書で記述されたコンテンツの暗号化および転送を可能にする目的で用いられてもよい。本発明は、一般に、以下の独立請求項によって定義される。
【特許請求の範囲】
【請求項１】
コンテンツプロバイダ（３０６，４０６，７０６，９０６）から第２のデバイス（３０２，４０２，７００，９００）へのメディアコンテンツの転送を制御するために第１のデバイス（３００，４００，７０２，９０２）を使用することを可能にするための、通信ネットワーク（３０４，４０４，７０４，９０４）における方法であって、
前記第１のデバイスは、前記通信ネットワークとの事前確立されたセキュリティの関連付けを有し、
前記方法は、
前記第２のデバイスに対するメディアコンテンツの配信を求める、前記第１のデバイスが行った前記コンテンツプロバイダに向けた要求を検出するステップ（５００）と、
前記メディアコンテンツを暗号化するための１以上のメディアキーの判定を可能にする、第１のキー情報セット及び第２のキー情報セットを含むキー情報を確立するステップ（５０８）と、
前記第１のキー情報セットを前記コンテンツプロバイダへ送信し、前記第２のキー情報セットを前記第１のデバイスへ送信するステップ（５１０）と、
を備え、
前記コンテンツプロバイダは、前記メディアキーにより暗号化された前記要求されたメディアコンテンツを前記第２のデバイスへ配信し、
前記第１のデバイスは、前記メディアキーにより暗号化されたメディアコンテンツが前記コンテンツプロバイダによって配信された際に当該メディアコンテンツを解読できるようにするために、前記メディアキー又は前記メディアキーの情報をローカル通信リンクを介して前記第２の通信デバイスへ転送可能である
ことを特徴とする方法。
【請求項２】
前記確立されたキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
各メディアキーに関する情報が連続的に前記第１のデバイスへ送信されることで、前記通信ネットワークはキー情報の当該送信を停止することにより前記メディアキーで暗号化されたコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項１に記載の方法。
【請求項３】
各メディアキーに関連するキー識別子が前記第１のデバイスへ送信されて前記第２のデバイスへ転送され、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記メディアキーは、事前設定された時間間隔で、又は、配信されるコンテンツに関する事前設定されたチャンク数ごとに、変更される
ことを特徴とする請求項２又は３に記載の方法。
【請求項５】
連続するメディアキーに関する情報を前記第１のデバイスへ送信するために、前記第１のデバイスからキー情報を求める連続的な要求が必要とされることで、前記第１のデバイスはキー情報の当該要求を停止することによりコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項２乃至４のいずれか１項に記載の方法。
【請求項６】
キー情報の前記要求は、前記第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信され、
連続するメディアキーに関する前記情報は、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で前記第１のデバイスへ送信される
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記事前確立されたセキュリティの関連付けは、第１の基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記第１の基本キー及び前記ナンスから導出可能である
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記コンテンツプロバイダへ送信される前記第１のキー情報セットは、前記第１の基本キーから独立した第２の基本キーを含み、
前記コンテンツプロバイダは、前記第２の基本キーを使用して一連のメディアキーを導出し、当該メディアキーに関する情報を前記第１のデバイスへ連続的に送信する
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１のデバイスからの前記コンテンツの要求は、前記第２のデバイスの接続パラメータを含み、当該接続パラメータは、前記メディアコンテンツを前記第２のデバイスへ配信するために前記コンテンツプロバイダによって使用される
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記要求は、前記ネットワークにおいて前記第１のデバイスから受信された際に検出される
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記要求は、前記コンテンツプロバイダが前記第１のデバイスから前記要求を受信した際に検出され、
前記コンテンツプロバイダは、３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報を前記第１のデバイスへ送信し、
前記第１のデバイスは、当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１３】
コンテンツプロバイダ（９０６）から第２のデバイス（９００）へのメディアコンテンツの転送を制御するために第１のデバイス（９０２）を使用することを可能にするように構成された通信ネットワークのノード（９０４）における装置であって、
前記第１のデバイスは、前記通信ネットワークとの事前確立されたセキュリティの関連付けを有し、
前記装置は、
前記第２のデバイスに対するメディアコンテンツの配信を求める、前記第１のデバイスが行った前記コンテンツプロバイダに向けた要求（Ｒ）を検出するように構成された検出ユニット（９０４ａ）と、
前記メディアコンテンツを暗号化するための１以上のメディアキー（ＭＫｊ）の判定を可能にする、第１のキー情報セット及び第２のキー情報セットを含むキー情報を確立するように構成されたキーユニット（９０４ｂ）と、
前記第１のキー情報セットを前記コンテンツプロバイダへ送信することで、前記コンテンツプロバイダが前記メディアキーにより暗号化された前記要求されたコンテンツを前記第２のデバイスへ配信できるようにするように構成された第１の通信ユニット（９０４ｃ）と、
前記第２のキー情報セットを前記第１のデバイスへ送信することで、前記メディアキーにより暗号化されたメディアコンテンツが前記コンテンツプロバイダによって配信された際に当該メディアコンテンツを解読できるようにするために、前記第１のデバイスが前記メディアキー又は前記メディアキーの情報をローカル通信リンクを介して前記第２の通信デバイスへ転送できるようにするように構成された第２の通信ユニット（９０４ｄ）と、
を備えることを特徴とする装置。
【請求項１４】
前記確立されたキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
前記第２の通信ユニットは更に、各メディアキーに関する情報を連続的に前記第１のデバイスへ送信することで、前記通信ネットワークがキー情報の当該送信を停止することにより前記メディアキーで暗号化されたコンテンツの前記配信を停止することを可能にするように構成される
ことを特徴とする請求項１３に記載の装置。
【請求項１５】
前記第２の通信ユニットは更に、各メディアキーに関連するキー識別子を前記第１のデバイスへ送信するように構成され、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項１４に記載の装置。
【請求項１６】
前記メディアキーは、事前設定された時間間隔で、又は、配信されるコンテンツに関する事前設定されたチャンク数ごとに、変更される
ことを特徴とする請求項１４又は１５に記載の装置。
【請求項１７】
連続するメディアキーに関する情報を前記第１のデバイスへ送信するために、前記第１のデバイスからキー情報を求める連続的な要求が必要とされることで、前記第１のデバイスはキー情報の当該要求を停止することによりコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項１４乃至１６のいずれか１項に記載の装置。
【請求項１８】
前記第２の通信ユニットは更に、キー情報の前記要求を、前記第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信し、連続するメディアキーに関する前記情報を、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で前記第１のデバイスへ送信するように構成される
ことを特徴とする請求項１７に記載の装置。
【請求項１９】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項１３乃至１８のいずれか１項に記載の装置。
【請求項２０】
前記事前確立されたセキュリティの関連付けは、第１の基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記第１の基本キー及び前記ナンスから導出可能である
ことを特徴とする請求項１９に記載の装置。
【請求項２１】
前記コンテンツプロバイダへ送信される前記第１のキー情報セットは、前記第１の基本キーから独立した第２の基本キーを含み、
前記コンテンツプロバイダは、前記第２の基本キーを使用して一連のメディアキーを導出し、当該メディアキーに関する情報を前記第１のデバイスへ連続的に送信する
ことを特徴とする請求項２０に記載の装置。
【請求項２２】
前記第１のデバイスによる前記コンテンツの要求は、前記第２のデバイスの接続パラメータを含み、当該接続パラメータは、前記メディアコンテンツを前記第２のデバイスへ配信するために前記コンテンツプロバイダによって使用される
ことを特徴とする請求項１３乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記検出ユニットは更に、前記要求を、前記ネットワークにおいて前記第１のデバイスから受信した際に検出するように構成される
ことを特徴とする請求項１３乃至２２のいずれか１項に記載の装置。
【請求項２４】
前記検出ユニットは更に、前記要求を、前記コンテンツプロバイダが前記第１のデバイスから前記要求を受信した際に検出するように構成され、
３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従って、前記コンテンツプロバイダはキー情報を前記第１のデバイスへ送信し、前記第１のデバイスは当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項１３乃至２２のいずれか１項に記載の装置。
【請求項２５】
コンテンツプロバイダ（３０６，４０６，７０６，９０６）から第２のデバイス（３０２，４０２，７００，９００）へのメディアコンテンツの転送を制御するための、第１のデバイス（３００，４００，７０２，９０２）における方法であって、
前記第２のデバイスとのローカル通信リンクを確立するステップ（６０２）と、
前記第２のデバイスへのメディアコンテンツの配信を求める要求を行うステップ（６０４）であって、前記第１のデバイスは通信ネットワーク（３０４，４０４，７０４，９０４）との事前確立されたセキュリティの関連付けを有し、前記要求は前記コンテンツプロバイダに向けたものである、ステップ（６０４）と、
前記メディアコンテンツを解読するための１以上のメディアキーの判定を可能にするキー情報を受信するステップ（６０６）と、
前記メディアキー又は前記メディアキーの情報を前記ローカル通信リンクを介して前記第２のデバイスへ転送することで、前記第２のデバイスが前記コンテンツプロバイダからメディアコンテンツを受信した際に当該メディアコンテンツを解読できるようにするステップ（６０８）と、
を備えることを特徴とする方法。
【請求項２６】
前記第２のデバイスの接続パラメータが前記ローカル通信リンクを介して取得され、
前記要求は、前記接続パラメータと共に前記通信ネットワーク又は前記コンテンツプロバイダへ送信される
ことを特徴とする請求項２５に記載の方法。
【請求項２７】
前記確立したキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
前記第１のデバイスは、前記通信ネットワーク又は前記コンテンツプロバイダから、各メディアキーに関する情報を連続的に受信することで、前記通信ネットワーク又は前記コンテンツプロバイダがキー情報の送信を停止することにより前記メディアキーで暗号化されたコンテンツの配信を停止することを可能にする
ことを特徴とする請求項２５又は２６に記載の方法。
【請求項２８】
前記第１のデバイスは、各メディアキーに関連するキー識別子を受信し、当該キー識別子を前記第２のデバイスへ転送し、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項２７に記載の方法。
【請求項２９】
前記第１のデバイスは、キー情報を求める連続的な要求を送信して連続するメディアキーに関する情報を取得することで、前記第１のデバイスがキー情報の当該要求を停止することによりコンテンツの前記配信を停止することを可能にする
ことを特徴とする請求項２７又は２８に記載の方法。
【請求項３０】
前記第１のデバイスは、キー情報の前記要求を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で送信し、連続するメディアキーに関する前記情報を、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で受信する
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項２５乃至３０のいずれか１項に記載の方法。
【請求項３２】
前記事前確立されたセキュリティの関連付けは、基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記基本キー及び前記ナンスから判定可能である
ことを特徴とする請求項３１に記載の方法。
【請求項３３】
前記第１のデバイスは、前記要求を前記通信ネットワークへ送信する
ことを特徴とする請求項２５乃至３２のいずれか１項に記載の方法。
【請求項３４】
前記第１のデバイスは、３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従って、前記要求を前記コンテンツプロバイダへ送信してキー情報を前記コンテンツプロバイダから受信し、当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項２５乃至３２のいずれか１項に記載の方法。
【請求項３５】
コンテンツプロバイダ（９０６）から第２のデバイス（９００）へのメディアコンテンツの転送を制御するための、第１のデバイス（９０２）における装置であって、
前記第２のデバイスとのローカル通信リンクを確立するように構成されたローカル通信ユニット（９０２ａ）と、
前記第２のデバイスへのメディアコンテンツの配信を求める要求（Ｒ，ＣＰ）を行うように構成された外部通信ユニット（９０２ｂ）であって、前記第１のデバイスは通信ネットワーク（９０４）との事前確立されたセキュリティの関連付けを有し、前記要求は前記コンテンツプロバイダに向けたものである、外部通信ユニット（９０２ｂ）と、
を備え、
外部通信ユニット（９０２ｂ）は更に、前記通信ネットワークからの前記メディアコンテンツを解読するための１以上のメディアキー（ＭＫｊ）の判定を可能にするキー情報を受信するように構成され、
前記ローカル通信ユニット（９０２ａ）は更に、前記メディアキー（ＭＫｊ）又は前記メディアキーの情報を前記ローカル通信リンクを介して前記第２のデバイスへ転送することで、前記第２のデバイスが前記コンテンツプロバイダからメディアコンテンツを受信した際に当該メディアコンテンツを解読できるようにするように構成される、
ことを特徴とする装置。
【請求項１】
コンテンツプロバイダ（３０６，４０６，７０６，９０６）から第２のデバイス（３０２，４０２，７００，９００）へのメディアコンテンツの転送を制御するために第１のデバイス（３００，４００，７０２，９０２）を使用することを可能にするための、通信ネットワーク（３０４，４０４，７０４，９０４）における方法であって、
前記第１のデバイスは、前記通信ネットワークとの事前確立されたセキュリティの関連付けを有し、
前記方法は、
前記第２のデバイスに対するメディアコンテンツの配信を求める、前記第１のデバイスが行った前記コンテンツプロバイダに向けた要求を検出するステップ（５００）と、
前記メディアコンテンツを暗号化するための１以上のメディアキーの判定を可能にする、第１のキー情報セット及び第２のキー情報セットを含むキー情報を確立するステップ（５０８）と、
前記第１のキー情報セットを前記コンテンツプロバイダへ送信し、前記第２のキー情報セットを前記第１のデバイスへ送信するステップ（５１０）と、
を備え、
前記コンテンツプロバイダは、前記メディアキーにより暗号化された前記要求されたメディアコンテンツを前記第２のデバイスへ配信し、
前記第１のデバイスは、前記メディアキーにより暗号化されたメディアコンテンツが前記コンテンツプロバイダによって配信された際に当該メディアコンテンツを解読できるようにするために、前記メディアキー又は前記メディアキーの情報をローカル通信リンクを介して前記第２の通信デバイスへ転送可能である
ことを特徴とする方法。
【請求項２】
前記確立されたキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
各メディアキーに関する情報が連続的に前記第１のデバイスへ送信されることで、前記通信ネットワークはキー情報の当該送信を停止することにより前記メディアキーで暗号化されたコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項１に記載の方法。
【請求項３】
各メディアキーに関連するキー識別子が前記第１のデバイスへ送信されて前記第２のデバイスへ転送され、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記メディアキーは、事前設定された時間間隔で、又は、配信されるコンテンツに関する事前設定されたチャンク数ごとに、変更される
ことを特徴とする請求項２又は３に記載の方法。
【請求項５】
連続するメディアキーに関する情報を前記第１のデバイスへ送信するために、前記第１のデバイスからキー情報を求める連続的な要求が必要とされることで、前記第１のデバイスはキー情報の当該要求を停止することによりコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項２乃至４のいずれか１項に記載の方法。
【請求項６】
キー情報の前記要求は、前記第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信され、
連続するメディアキーに関する前記情報は、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で前記第１のデバイスへ送信される
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記事前確立されたセキュリティの関連付けは、第１の基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記第１の基本キー及び前記ナンスから導出可能である
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記コンテンツプロバイダへ送信される前記第１のキー情報セットは、前記第１の基本キーから独立した第２の基本キーを含み、
前記コンテンツプロバイダは、前記第２の基本キーを使用して一連のメディアキーを導出し、当該メディアキーに関する情報を前記第１のデバイスへ連続的に送信する
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１のデバイスからの前記コンテンツの要求は、前記第２のデバイスの接続パラメータを含み、当該接続パラメータは、前記メディアコンテンツを前記第２のデバイスへ配信するために前記コンテンツプロバイダによって使用される
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記要求は、前記ネットワークにおいて前記第１のデバイスから受信された際に検出される
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記要求は、前記コンテンツプロバイダが前記第１のデバイスから前記要求を受信した際に検出され、
前記コンテンツプロバイダは、３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従ってキー情報を前記第１のデバイスへ送信し、
前記第１のデバイスは、当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１３】
コンテンツプロバイダ（９０６）から第２のデバイス（９００）へのメディアコンテンツの転送を制御するために第１のデバイス（９０２）を使用することを可能にするように構成された通信ネットワークのノード（９０４）における装置であって、
前記第１のデバイスは、前記通信ネットワークとの事前確立されたセキュリティの関連付けを有し、
前記装置は、
前記第２のデバイスに対するメディアコンテンツの配信を求める、前記第１のデバイスが行った前記コンテンツプロバイダに向けた要求（Ｒ）を検出するように構成された検出ユニット（９０４ａ）と、
前記メディアコンテンツを暗号化するための１以上のメディアキー（ＭＫｊ）の判定を可能にする、第１のキー情報セット及び第２のキー情報セットを含むキー情報を確立するように構成されたキーユニット（９０４ｂ）と、
前記第１のキー情報セットを前記コンテンツプロバイダへ送信することで、前記コンテンツプロバイダが前記メディアキーにより暗号化された前記要求されたコンテンツを前記第２のデバイスへ配信できるようにするように構成された第１の通信ユニット（９０４ｃ）と、
前記第２のキー情報セットを前記第１のデバイスへ送信することで、前記メディアキーにより暗号化されたメディアコンテンツが前記コンテンツプロバイダによって配信された際に当該メディアコンテンツを解読できるようにするために、前記第１のデバイスが前記メディアキー又は前記メディアキーの情報をローカル通信リンクを介して前記第２の通信デバイスへ転送できるようにするように構成された第２の通信ユニット（９０４ｄ）と、
を備えることを特徴とする装置。
【請求項１４】
前記確立されたキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
前記第２の通信ユニットは更に、各メディアキーに関する情報を連続的に前記第１のデバイスへ送信することで、前記通信ネットワークがキー情報の当該送信を停止することにより前記メディアキーで暗号化されたコンテンツの前記配信を停止することを可能にするように構成される
ことを特徴とする請求項１３に記載の装置。
【請求項１５】
前記第２の通信ユニットは更に、各メディアキーに関連するキー識別子を前記第１のデバイスへ送信するように構成され、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項１４に記載の装置。
【請求項１６】
前記メディアキーは、事前設定された時間間隔で、又は、配信されるコンテンツに関する事前設定されたチャンク数ごとに、変更される
ことを特徴とする請求項１４又は１５に記載の装置。
【請求項１７】
連続するメディアキーに関する情報を前記第１のデバイスへ送信するために、前記第１のデバイスからキー情報を求める連続的な要求が必要とされることで、前記第１のデバイスはキー情報の当該要求を停止することによりコンテンツの前記配信を停止することが可能になる
ことを特徴とする請求項１４乃至１６のいずれか１項に記載の装置。
【請求項１８】
前記第２の通信ユニットは更に、キー情報の前記要求を、前記第１のデバイスからのＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で受信し、連続するメディアキーに関する前記情報を、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で前記第１のデバイスへ送信するように構成される
ことを特徴とする請求項１７に記載の装置。
【請求項１９】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項１３乃至１８のいずれか１項に記載の装置。
【請求項２０】
前記事前確立されたセキュリティの関連付けは、第１の基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記第１の基本キー及び前記ナンスから導出可能である
ことを特徴とする請求項１９に記載の装置。
【請求項２１】
前記コンテンツプロバイダへ送信される前記第１のキー情報セットは、前記第１の基本キーから独立した第２の基本キーを含み、
前記コンテンツプロバイダは、前記第２の基本キーを使用して一連のメディアキーを導出し、当該メディアキーに関する情報を前記第１のデバイスへ連続的に送信する
ことを特徴とする請求項２０に記載の装置。
【請求項２２】
前記第１のデバイスによる前記コンテンツの要求は、前記第２のデバイスの接続パラメータを含み、当該接続パラメータは、前記メディアコンテンツを前記第２のデバイスへ配信するために前記コンテンツプロバイダによって使用される
ことを特徴とする請求項１３乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記検出ユニットは更に、前記要求を、前記ネットワークにおいて前記第１のデバイスから受信した際に検出するように構成される
ことを特徴とする請求項１３乃至２２のいずれか１項に記載の装置。
【請求項２４】
前記検出ユニットは更に、前記要求を、前記コンテンツプロバイダが前記第１のデバイスから前記要求を受信した際に検出するように構成され、
３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従って、前記コンテンツプロバイダはキー情報を前記第１のデバイスへ送信し、前記第１のデバイスは当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項１３乃至２２のいずれか１項に記載の装置。
【請求項２５】
コンテンツプロバイダ（３０６，４０６，７０６，９０６）から第２のデバイス（３０２，４０２，７００，９００）へのメディアコンテンツの転送を制御するための、第１のデバイス（３００，４００，７０２，９０２）における方法であって、
前記第２のデバイスとのローカル通信リンクを確立するステップ（６０２）と、
前記第２のデバイスへのメディアコンテンツの配信を求める要求を行うステップ（６０４）であって、前記第１のデバイスは通信ネットワーク（３０４，４０４，７０４，９０４）との事前確立されたセキュリティの関連付けを有し、前記要求は前記コンテンツプロバイダに向けたものである、ステップ（６０４）と、
前記メディアコンテンツを解読するための１以上のメディアキーの判定を可能にするキー情報を受信するステップ（６０６）と、
前記メディアキー又は前記メディアキーの情報を前記ローカル通信リンクを介して前記第２のデバイスへ転送することで、前記第２のデバイスが前記コンテンツプロバイダからメディアコンテンツを受信した際に当該メディアコンテンツを解読できるようにするステップ（６０８）と、
を備えることを特徴とする方法。
【請求項２６】
前記第２のデバイスの接続パラメータが前記ローカル通信リンクを介して取得され、
前記要求は、前記接続パラメータと共に前記通信ネットワーク又は前記コンテンツプロバイダへ送信される
ことを特徴とする請求項２５に記載の方法。
【請求項２７】
前記確立したキー情報は、前記要求されたメディアコンテンツを暗号化するために事前決定された順序で使用される一連のメディアキーを判定するために使用され、
前記第１のデバイスは、前記通信ネットワーク又は前記コンテンツプロバイダから、各メディアキーに関する情報を連続的に受信することで、前記通信ネットワーク又は前記コンテンツプロバイダがキー情報の送信を停止することにより前記メディアキーで暗号化されたコンテンツの配信を停止することを可能にする
ことを特徴とする請求項２５又は２６に記載の方法。
【請求項２８】
前記第１のデバイスは、各メディアキーに関連するキー識別子を受信し、当該キー識別子を前記第２のデバイスへ転送し、
前記コンテンツプロバイダは、前記第２のデバイスにおいて受信されたメディアとメディアキーとを同期させるために、対応するメディアキーにより暗号化されたメディアコンテンツに対して前記キー識別子を追加する
ことを特徴とする請求項２７に記載の方法。
【請求項２９】
前記第１のデバイスは、キー情報を求める連続的な要求を送信して連続するメディアキーに関する情報を取得することで、前記第１のデバイスがキー情報の当該要求を停止することによりコンテンツの前記配信を停止することを可能にする
ことを特徴とする請求項２７又は２８に記載の方法。
【請求項３０】
前記第１のデバイスは、キー情報の前記要求を、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージの中で送信し、連続するメディアキーに関する前記情報を、当該ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージに応えてＳＩＰ Ｎｏｔｉｆｙメッセージの中で受信する
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記キー情報は、１以上の明示的なメディアキー、又は、前記メディアキーをそこから判定可能な１以上の暗示的なメディアキー関連パラメータを含む
ことを特徴とする請求項２５乃至３０のいずれか１項に記載の方法。
【請求項３２】
前記事前確立されたセキュリティの関連付けは、基本キーと、少なくとも１つのナンスを含む前記１以上の暗示的なメディアキー関連パラメータとを伴い、
前記メディアキーは、前記基本キー及び前記ナンスから判定可能である
ことを特徴とする請求項３１に記載の方法。
【請求項３３】
前記第１のデバイスは、前記要求を前記通信ネットワークへ送信する
ことを特徴とする請求項２５乃至３２のいずれか１項に記載の方法。
【請求項３４】
前記第１のデバイスは、３ＧＰＰに規定されるＧＢＡ（Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）に従って、前記要求を前記コンテンツプロバイダへ送信してキー情報を前記コンテンツプロバイダから受信し、当該キー情報から前記メディアキーを生成する
ことを特徴とする請求項２５乃至３２のいずれか１項に記載の方法。
【請求項３５】
コンテンツプロバイダ（９０６）から第２のデバイス（９００）へのメディアコンテンツの転送を制御するための、第１のデバイス（９０２）における装置であって、
前記第２のデバイスとのローカル通信リンクを確立するように構成されたローカル通信ユニット（９０２ａ）と、
前記第２のデバイスへのメディアコンテンツの配信を求める要求（Ｒ，ＣＰ）を行うように構成された外部通信ユニット（９０２ｂ）であって、前記第１のデバイスは通信ネットワーク（９０４）との事前確立されたセキュリティの関連付けを有し、前記要求は前記コンテンツプロバイダに向けたものである、外部通信ユニット（９０２ｂ）と、
を備え、
外部通信ユニット（９０２ｂ）は更に、前記通信ネットワークからの前記メディアコンテンツを解読するための１以上のメディアキー（ＭＫｊ）の判定を可能にするキー情報を受信するように構成され、
前記ローカル通信ユニット（９０２ａ）は更に、前記メディアキー（ＭＫｊ）又は前記メディアキーの情報を前記ローカル通信リンクを介して前記第２のデバイスへ転送することで、前記第２のデバイスが前記コンテンツプロバイダからメディアコンテンツを受信した際に当該メディアコンテンツを解読できるようにするように構成される、
ことを特徴とする装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２０１３−５１３２８６（Ｐ２０１３−５１３２８６Ａ）
【公表日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１２−５４１９７１（Ｐ２０１２−５４１９７１）
【出願日】平成２１年１２月７日（２００９．１２．７）
【国際出願番号】ＰＣＴ／ＳＥ２００９／０５１３８１
【国際公開番号】ＷＯ２０１１／０７１４２３
【国際公開日】平成２３年６月１６日（２０１１．６．１６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２１年１２月７日（２００９．１２．７）
【国際出願番号】ＰＣＴ／ＳＥ２００９／０５１３８１
【国際公開番号】ＷＯ２０１１／０７１４２３
【国際公開日】平成２３年６月１６日（２０１１．６．１６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]