制御デバイス、再生デバイス、許可サーバ、制御デバイスの制御方法、再生デバイスの制御方法、及び許可サーバの制御方法
マルチメディアデータを再生するように再生デバイス（３０２）を制御する制御手段（６０６）を備える制御デバイス（３０１）が提供される。前記制御デバイス（３０１）は、許可サーバ（３０４）に含まれる許可データを獲得する要求を前記再生デバイス（３０２）から受信する受信手段（６１２）を備え、前記許可データは、前記マルチメディアデータの再生を可能にするものであり、前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイス（３０２）の認証情報とを含み、前記制御デバイス（３０１）は、前記位置情報によって指し示される位置から前記許可データを獲得する獲得手段（６１４）であって、前記認証情報を前記許可サーバ（３０４）へ送信する獲得手段（６１４）と、前記許可データを前記再生デバイス（３０２）へ送信する送信手段（６１６）と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、保護されたマルチメディアデータの再生を可能にするパーミッション（許可情報）を獲得するための技術に関する。
【背景技術】
【０００２】
ＯＭＡ ＤＲＭ ２．０：
Open Mobile Alliance（ＯＭＡ）は、２００６年３月３日に、Digital Rights Management Version 2 (OMA DRM 2.0)の承認されたイネーブラをリリースした［１］。ＯＭＡ ＤＲＭ ２．０のイネーブラのリリースは、移動体環境においてＤＲＭシステムを実装するために必要なプロトコル、メッセージ、及びメカニズムを規定する。
【０００３】
ＯＭＡ ＤＲＭ ２．０では、他の類似したＤＲＭシステムと同様に、保護されたコンテンツがユーザデバイスへと配信され、特定の権利オブジェクト（ＲＯ）と一緒にそのコンテンツを消費可能である。ＲＯは、ネットワークを介して安全なやり方で獲得可能であり、この獲得メカニズムは、ＯＭＡ ＤＲＭ ２．０仕様の不可欠な部分である。それは権利オブジェクト獲得プロトコル（ＲＯＡＰ）として規定されており、２つの重要なＯＭＡ ＤＲＭ ２．０エンティティである「デバイス」及び「権利発行装置」を伴う。
【０００４】
以下は、ＯＭＡ ＤＲＭ ２．０における、デバイス、権利発行装置、及びこれらに関連する規定に関する、公式の規定である。
【０００５】
− デバイス： ＤＲＭエージェントを実装するユーザ装置内のエンティティ（ハードウェア、ソフトウェア、又はそれらの組み合わせ）
− 権利発行装置： ＯＭＡ ＤＲＭ準拠のデバイスに対して権利オブジェクトを発行するエンティティ
− ＤＲＭエージェント： デバイス上のメディアオブジェクトのための許可情報を管理する、デバイスにおけるエンティティ
− 許可情報： 保護されたコンテンツに対して（権利発行装置によって）許可された実際の用途及び動作
− メディアオブジェクト： 例えば呼出音、スクリーンセーバ、Ｊａｖａ（登録商標）ゲームなどの、デジタル作品
− 保護されたコンテンツ： 権利オブジェクト内の許可情報のセットに従って消費されるメディアオブジェクト
− 権利オブジェクト（ＲＯ）： 保護されたコンテンツに結び付けられた、許可情報及びその他の属性の集合
【０００６】
ＲＯＡＰの詳細なメカニズム（例えば、デバイスが自身の登録先の権利発行装置とどのように対話しなければならないか、デバイスがどのようにＲＯを獲得しなければならないか、など）は、ＯＭＡ ＤＲＭ仕様書［１］に見ることができる。
【０００７】
課金システム：
ＯＭＡ ＤＲＭ ２．０は、メディアオブジェクトの消費を制御するために利用可能である。従って、メディアオブジェクトの提供者（以下、「コンテンツプロバイダ」と呼ぶ）は、ＯＭＡ ＤＲＭ ２．０を利用することにより、消費者に課金することができる。より具体的には、コンテンツプロバイダは、ＲＯの獲得について消費者に対して課金することができる。
【０００８】
ＯＭＡ ＤＲＭ ２．０標準は、実システムにおいてどのようにＲＯの獲得に対して課金されるかを明示してはいないが、既知のシステムの１つによれば、（デバイスＩＤによって特定される）「デバイス」が、コンテンツプロバイダにおいてユーザの（所有者の）課金情報（例えば、クレジットカード番号など）と事前に関連付けられる。「デバイス」がＳＩＭ（加入者ＩＤモジュール）を備えた移動体端末である場合、課金情報はＩＭＳＩ（国際移動加入者識別番号）であってもよい。そのデバイスによって実行されるＲＯの獲得は、事前に関連付けられた課金情報に従って自動的に課金される。以下は、このシステムの詳細な説明である。
【０００９】
ＯＭＡ ＤＲＭ ２．０では、「デバイス」は、ＲＯＡＰを介したＲＯの獲得の要求元として権利発行装置が認識可能な、唯一の標準エンティティである。対応するデバイスＩＤは、権利発行装置がそれによって各デバイスを一意に識別可能な、唯一の規定された識別情報である（現在規定されている唯一のデバイスＩＤは、デバイスの公開鍵のハッシュである）。このシステムにおいて、デバイスＩＤは、課金対象を特定する手段として使用される。
【００１０】
デバイスＩＤは、デバイスの所有者の課金情報に関連付けられる。所有者によっては２以上のデバイスを所有するということも大いにあり得ることである（図１参照）。図１において、所有者ＡはデバイスＸ及びデバイスＹを所有し、両デバイスのデバイスＩＤは、所有者Ａの課金情報に関連付けられる。従って、デバイスＸ及びデバイスＹによって実行されるＲＯの獲得は共に、所有者Ａに対して課金可能である。ＯＭＡ ＤＲＭ ２．０では標準化されていない課金機能が、所有者とデバイスＩＤとの間の関連付けを管理する。
【００１１】
認証：
デバイスに対してＲＯを発行する前に、権利発行装置がデバイスを認証することが望ましい。これは、デバイスがハッキングされたり、セキュリティ上のバグを含んでいたり、不正に設計されたりした場合に、デバイスがＲＯを悪用する可能性があるからである。例えば、デバイスは、復号されたメディアオブジェクトを「盗んで」、許可されていないユーザに対してＤＲＭ保護無しでこれを提供するかもしれない。このことはコンテンツプロバイダ（即ち、メディアオブジェクトの権利者）に損害を与える可能性がある。
【００１２】
ＲＯの発行を受けるデバイスが信用できるものであるか否かを権利発行装置が知るための１つのやり方は、例えばＯＣＳＰ(Online Certificate Status Protocol)［２］を介して、デバイスの証明書の無効状態をチェックすることである。例えば、デバイスが信用できないようになると、製造時にデバイスに証明書をインストールしたデバイスのベンダはＰＫＩシステムに対してその証明書を無効にするように要求するであろうから、デバイスの証明書はそれに関与するＰＫＩシステム内で無効にされそうである。
【００１３】
ＲＯのサブライセンス：
デバイスの「所有者」とデバイスの「ユーザ」とが異なる場合に、説明した課金システムは問題を引き起こす。この事例が発生するのは、例えば、ホテル、友人の家、訪問先オフィス、カフェ、駅といった多数の訪問先の場所で利用可能なデバイスを、ユーザがその場限りの（アドホックな）やり方で使用する場合である。この場合、メディアオブジェクトを実際に消費したユーザの代わりに、ＲＯを獲得したデバイスの所有者が、最終的に課金される。
【００１４】
この問題に対処するために、ＲＯをサブライセンスする技術（以下、「サブライセンス技術」と呼ぶ）が知られている［３］［４］。サブライセンス技術は、権利発行装置からＲＯを元々獲得したデバイスが他のデバイスに対してＲＯのサブライセンス（以下、「サブＲＯ」と呼ぶ）を更に発行することを可能にする。サブＲＯは、元々のＲＯ（オリジナルＲＯ）の許可情報の全部又は一部を含む。
【００１５】
図２は、サブライセンス技術の基本的な考えを示す。デバイス２２０は、メディアオブジェクトを実際に消費するユーザによって所有されている。デバイス１（２３１）からデバイスｍ（２３３）は全て、ユーザとは別の所有者によって所有されている。
【００１６】
デバイス１（２３１）は、インターネットを介して映画データを取り出すことが可能なパーソナルコンピュータ（ＰＣ）であり、ホテルの部屋に設置されていてホテルによって所有されているものとする。ＤＲＭによって保護されている映画を視聴することをユーザが望む場合、例えばユーザのセルラ電話であるデバイス２２０は最初に、その映画のためのＲＯ（オリジナルＲＯ）を獲得する。デバイス２２０は次に、デバイス１（２３１）に対して、オリジナルＲＯに基づいてサブＲＯを発行する。そして、デバイス１（２３１）は、発行されたサブＲＯに従って映画を再生する。
【００１７】
ユーザが所有するデバイス２２０が最初にＲＯを獲得するので、コンテンツプロバイダ（即ち、映画の権利者）は、デバイス１（２３１）を所有するホテルではなくて映画を実際に視聴するユーザに対して課金することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
サブライセンス技術における既存の問題：
サブライセンス技術が利用される場合、サブライセンスを受けるデバイスがサブＲＯの使用を許可された（信頼できる）デバイスであることを保証するために、サブＲＯを発行する前に、サブライセンスを与えるデバイス（例えば、デバイス２２０）がサブライセンスを受けるデバイス（例えば、デバイス１（２３１））を認証する必要がある。サブライセンスを与えるデバイスは、認証されるデバイスの信頼性を確認するために、デバイスを認証する度に、例えばＯＣＳＰを介してＰＫＩシステムと通信することによってサブライセンスを受けるデバイスの無効状態をチェックすることが好ましい。
【００１９】
しかしながら、これはサブライセンスを与えるデバイスにとって間違いなく損失の大きな動作である。なぜなら、サブライセンスを与えるデバイスの演算能力及び帯域は通常、権利発行装置と比べて限られているからである。サブライセンスを与えるデバイスが例えばセルラ電話であってデータ通信に対する料金請求が送受信されたトラヒック量に基づく状況においては、この問題は特に深刻である。
【課題を解決するための手段】
【００２０】
本発明の特徴は、既存の問題を解決することである。
【００２１】
本発明の一態様によれば、制御デバイスであって、マルチメディアデータを再生するように再生デバイスを制御する制御手段と、許可サーバに含まれる許可データを獲得する要求を前記再生デバイスから受信する受信手段と、を備え、前記許可データは、前記マルチメディアデータの再生を可能にするものであり、前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイスの認証情報とを含み、前記制御デバイスは、前記位置情報によって指し示される位置から前記許可データを獲得する獲得手段であって、前記認証情報を前記許可サーバへ送信する獲得手段と、前記許可データを前記再生デバイスへ送信する送信手段と、を備えることを特徴とする制御デバイスが提供される。
【００２２】
本発明の他の態様によれば、再生デバイスであって、マルチメディアデータを再生するコマンドを制御デバイスから受信するコマンド受信手段と、前記マルチメディアデータの再生を可能にする許可データであって、許可サーバに含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得手段と、前記許可データを獲得する要求であって、前記位置情報と前記再生デバイスの認証情報とを含む要求を、前記制御デバイスへ送信する送信手段と、前記要求に対する応答として前記許可データを前記制御デバイスから受信する許可受信手段と、前記許可データを使用して前記マルチメディアデータを再生する再生手段と、を備えることを特徴とする再生デバイスが提供される。
【００２３】
本発明の他の態様によれば、許可サーバであって、マルチメディアデータの再生を可能にする許可データであって、前記許可サーバに含まれる許可データの位置を指し示す位置情報を、再生デバイスへ送信する位置送信手段と、前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイスの認証情報を含む要求を、制御デバイスから受信する受信手段と、前記再生デバイスが認証されているか否かを前記認証情報に基づいて判定する判定手段と、前記再生デバイスが認証されていると前記判定手段が判定した場合に、前記要求に応えて前記制御デバイスへ前記許可データを送信する許可送信手段と、を備えることを特徴とする許可サーバが提供される。
【００２４】
本発明の他の態様によれば、制御デバイスの制御方法であって、マルチメディアデータを再生するように再生デバイスを制御する制御ステップと、許可サーバに含まれる許可データを獲得する要求を前記再生デバイスから受信する受信ステップと、を備え、前記許可データは、前記マルチメディアデータの再生を可能にするものであり、前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイスの認証情報とを含み、前記制御方法は、前記位置情報によって指し示される位置から前記許可データを獲得する獲得ステップを備え、当該獲得ステップにおいては、前記認証情報が前記許可サーバへ送信され、前記制御方法は、前記許可データを前記再生デバイスへ送信する送信ステップを備えることを特徴とする制御方法が提供される。
【００２５】
本発明の他の態様によれば、再生デバイスの制御方法であって、マルチメディアデータを再生するコマンドを制御デバイスから受信するコマンド受信ステップと、前記マルチメディアデータの再生を可能にする許可データであって、許可サーバに含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得ステップと、前記許可データを獲得する要求であって、前記位置情報と前記再生デバイスの認証情報とを含む要求を、前記制御デバイスへ送信する送信ステップと、前記要求に対する応答として前記許可データを前記制御デバイスから受信する許可受信ステップと、前記許可データを使用して前記マルチメディアデータを再生する再生ステップと、を備えることを特徴とする制御方法が提供される。
【００２６】
本発明の他の態様によれば、許可サーバの制御方法であって、マルチメディアデータの再生を可能にする許可データであって、前記許可サーバに含まれる許可データの位置を指し示す位置情報を、再生デバイスへ送信する位置送信ステップと、前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイスの認証情報を含む要求を、制御デバイスから受信する受信ステップと、前記再生デバイスが認証されているか否かを前記認証情報に基づいて判定する判定ステップと、前記再生デバイスが認証されていると前記判定ステップが判定した場合に、前記要求に応えて前記制御デバイスへ前記許可データを送信する許可送信ステップと、を備えることを特徴とする制御方法が提供される。
【００２７】
本発明の主な利点は、以下の通りである。制御デバイスの代わりに許可サーバが、許可サーバによって発行される許可情報を実際に消費する再生デバイスを認証する。従って、許可サーバに比べて比較的小さな帯域しか持たず比較的低い処理能力しか持たない制御デバイスにとっての処理負荷が低減される。
【００２８】
本発明の更なる特徴は、添付の図面に関連する典型的な実施形態に関する以下の説明から明らかになるであろう。添付の図面において、全図を通して、同一の参照符号は同一又は類似の部分を指し示す。
【図面の簡単な説明】
【００２９】
【図１】所有者とデバイスＩＤとの間の関連付けの例を示す。
【図２】サブライセンス技術の基本的な考えを示す。
【図３】実施形態に従う再生システムの概観を示す。
【図４】ＵＰｎＰ ＡＶ（オーディオビジュアル）デバイスの対話モデルを示す。
【図５】ＯＭＡ ＤＲＭデバイス（即ち、制御デバイス）を課金情報に関連付けるやり方の手順例を示す。
【図６】再生システムの制御デバイスのブロック図を示す。
【図７】再生システムの再生デバイスのブロック図を示す。
【図８】再生システム３００の権利発行装置のブロック図を示す。
【図９】再生システムにおいて実行される処理を示すフローチャートである。
【図１０】コンテンツサーバによって返されるＳＤＰの例を示す。
【図１１】再生デバイスによって制御デバイスへと送信される要求メッセージの例を示す。
【図１２】制御デバイスによって権利発行装置へと送信される、裏書された要求メッセージの例を示す。
【発明を実施するための形態】
【００３０】
再生システム：
図３は、実施形態に従う再生システム３００の概観を示す。
【００３１】
再生システム３００において、制御デバイス３０１は、マルチメディアデータ（メディアオブジェクト）を再生するように再生デバイス３０２を制御する。制御デバイス３０１の所有者は、これを制御してメディアオブジェクトを消費する（即ち、読み、視聴し、聴く、などする）ユーザである。制御デバイス３０１は、セルラ電話、携帯情報端末（ＰＤＡ）、ノートブックコンピュータなどの、任意の種類のデバイスであってよい。
【００３２】
再生デバイス３０２は、メディアオブジェクトを再生可能である限り、テレビ（ＴＶ）、ＰＣなどの、任意の種類のデバイスであってよい。再生デバイス３０２は、制御デバイスの所有者とは異なる人（又は組織）によって所有されている。再生デバイス３０２は、制御デバイス３０１による制御に応えて、メディアオブジェクトを再生する。
【００３３】
制御デバイス３０１及び再生デバイス３０２は、ユニバーサル・プラグアンドプレイ（ＵＰｎＰ）ネットワーク３１１（詳細は後述する）を介して相互に接続される。典型的な実施形態において、再生デバイス３０２は、ホテルの部屋に設置されたＴＶであり、制御デバイス３０１の所有者はホテルの宿泊客である。しかしながら、制御デバイス３０１及び再生デバイス３０２は、ＵＰｎＰ以外の任意の接続スキームを使用して接続されてもよい。
【００３４】
コンテンツサーバ３０３は、メディアオブジェクトを含み、インターネット３１２を介して再生デバイス３０２にメディアオブジェクトを提供する。以下の説明では、メディアオブジェクトはＯＭＡ ＤＲＭ ２．０に基づいて保護されて（復号される）ものとする。コンテンツサーバ３０３はまた、再生デバイス３０２で利用可能なメディアオブジェクトのリストを制御デバイス３０１に提供する。コンテンツサーバ３０３は例えば、コンテンツプロバイダによって管理されるサーバであってもよいし、制御デバイス３０１の所有者によって所有されているハードディスクドライブ（ＨＤＤ）レコーダであってもよい。いくつかの実施形態では、再生デバイス３０２は、メディアオブジェクトを含んだ記憶装置を有し、コンテンツサーバ３０３の代わりにその記憶装置からメディアオブジェクトを取り出してもよい。
【００３５】
権利発行装置３０４は、コンテンツサーバ３０３（又は再生デバイス３０２の記憶装置）に含まれるメディアオブジェクトの再生を可能にするＲＯを、制御デバイス３０１に対して発行する。権利発行装置３０４は許可情報（パーミッション）を含むＲＯを発行するので、本実施形態においては許可サーバとも呼ばれる。
【００３６】
ＯＣＳＰサーバ３０５は、証明書無効リスト（ＣＲＬ）を管理する。再生デバイス３０２がハッキングされたり、再生デバイス３０２が何らかのセキュリティ上のバグを含んでいたりすることが検知されると、再生デバイス３０２の証明書がＣＲＬに追加される。従って、権利発行装置３０４は、ＯＣＳＰを介してＯＣＳＰサーバ３０５にアクセスすることにより、ＲＯを発行する前に、再生デバイス３０２が認証されているか（即ち、信頼できるか）否かを判断可能である。
【００３７】
課金サーバ３０６は、権利発行装置３０４によって発行されたＲＯについて、制御デバイス３０１の所有者に課金する。課金サーバ３０６は、制御デバイス３０１の識別情報（例えば、デバイスＩＤ）に関連付けられている、所有者に関する課金情報を持つ。権利発行装置３０４がＲＯを発行する際に、権利発行装置３０４は制御デバイス３０１のデバイスＩＤを受信し、価格情報と共にデバイスＩＤを課金サーバ３０６へ転送する。従って、課金サーバ３０６は、発行されたＲＯについて所有者に課金することができる。
【００３８】
なお、図３に示されるいくつかのエンティティは、単一のエンティティの中に実装されてもよい。例えば、権利発行装置３０４及び課金サーバ３０６は、同一のサーバ内に実装されてもよい。
【００３９】
ＵＰｎＰ：
上述した通り、制御デバイス３０１及び再生デバイス３０２は、接続のためにＵＰｎＰを使用することができる。このセクションでは、ＵＰｎＰの詳細な説明を提供する。
【００４０】
ＵＰｎＰは、ＡＶデバイスなどの相互運用可能な家庭電化製品のための業界標準である。ＵＰｎＰデバイスアーキテクチャは、別々のＵＰｎＰデバイス説明書及びＵＰｎＰサービス説明書において規定される全てのＵＰｎＰ機能のための基礎である。本実施形態は、ＵＰｎＰ ＡＶアーキテクチャと、関連するＵＰｎＰデバイス仕様及びＵＰｎＰサービス仕様によって最も特徴付けられる。
【００４１】
ＵＰｎＰ ＡＶアーキテクチャは、ＵＰｎＰメディアサーバ［９］デバイス及びＵＰｎＰメディアレンダラ(MediaRenderer)［１０］デバイスを導入し、メディアサーバに格納されたメディアコンテンツ（例えば、ビデオ、オーディオ、画像、など）がＵＰｎＰコントロールポイント（ＣＰ）の制御下でメディアレンダラ上で再生されるやり方を示す。
【００４２】
なお、メディアサーバ、メディアレンダラ、及びＣＰは、論理エンティティに過ぎないので、メディアサーバ、メディアレンダラ、及びＣＰの任意の組（セット）を、単一の物理デバイス内に実装可能である。
【００４３】
図４は、ＵＰｎＰ ＡＶデバイスの対話モデルを示す。ＣＰは、メディアサーバ及びメディアレンダラの両方の動作を協調させ同期させる中心的役割を演じる。ＣＰは、所望のコンテンツがメディアサーバからメディアレンダラへ伝送されるように両デバイスを初期化して設定するためにＵＰｎＰプロトコルを使用するが、メディアサーバ及びメディアレンダラ自体は、ＨＴＴＰ−ＧＥＴ又はＲＴＳＰ−ＲＴＰのような非ＵＰｎＰの通信プロトコルを使用して相互に対話する。
【００４４】
図３に示す再生システム３００において、制御デバイス３０１はＣＰとしての役割を果たし、再生デバイス３０２はメディアレンダラとしての役割を果たす。コンテンツサーバ３０３はＵＰｎＰネットワーク３１１ではなくインターネット３１２を介して接続されているのでメディアサーバとしての役割を果たさないが、再生デバイス３０２は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）などの任意の種類のプロトコルを使用してコンテンツサーバ３０３からメディアオブジェクトを受信することができる。なお、コンテンツサーバ３０３がＵＰｎＰを使用して制御デバイス３０１及び再生デバイス３０２と接続可能な場合は、コンテンツサーバ３０３はメディアサーバとしての役割を果たすことができる。
【００４５】
デバイスＩＤと課金情報との間の関連付け：
上述の通り、課金サーバ３０６が発行されたＲＯについて所有者に課金することを可能にするために、制御デバイス３０１のデバイスＩＤは、制御デバイス３０１の所有者の課金情報に事前に関連付けられるべきである。
【００４６】
図５は、ＯＭＡ ＤＲＭデバイス（即ち、制御デバイス３０１）を課金情報に関連付けるやり方の手順例を示す。
【００４７】
ステップＳ５０１で、所有者は最初に、例えば権利発行装置３０４によって提供されるデバイス所有者登録ウェブページに対して、制御デバイス３０１の組み込みブラウザを用いてアクセスする。この対話型ウェブページにおいて、所有者は、制御デバイス３０１に関連付けられるべき必要な課金情報（例えば、クレジットカード番号）を提示する。ステップＳ５０２で、ステップＳ５０１において課金情報の追加が成功した後で、権利発行装置は制御デバイス３０１に対してＲＯＡＰトリガを送信する。ＲＯＡＰトリガのトリガタイプは、デバイスに対してＲＯＡＰ登録を開始するように促す登録要求トリガ(Registration Request Trigger)である。
【００４８】
これに続く４パスＲＯＡＰ登録プロトコル［１］（Ｓ５０３〜Ｓ５０６）によって、権利発行装置は、提示された課金情報を登録されたデバイスＩＤに関連付けることが可能である。
【００４９】
制御デバイス：
図６は、再生システム３００の制御デバイス３０１のブロック図を示す。プロセッサ６０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、制御デバイス３０１内に含まれるコンポーネントの各々を制御する。図６において、プロセッサ６０２に含まれるコンポーネントは、典型的にはプロセッサ６０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００５０】
送受信機６０４は、制御デバイス３０１と、例えば再生デバイス３０２、コンテンツサーバ３０３、及び権利発行装置３０４などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機６０４は、図６においては単純化のために単一のブロックとして記載されているが、送受信機６０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００５１】
制御ユニット６０６は、メディアオブジェクトを再生するように再生デバイス３０２を制御する。いくつかの実施形態においては、制御ユニット６０６はコンテンツサーバ３０３から、コンテンツサーバ３０３に含まれるメディアオブジェクトのリストを取得する。次いで制御ユニット６０６は、制御デバイスの所有者が再生を望むメディアデバイスを操作ユニット６１０（例えば、キーボード）を介して選択可能なように、リストをディスプレイ６０８に表示する。制御ユニット６０６は、操作ユニット６１０による操作に応えて、再生対象のメディアオブジェクトを選択し、選択されたメディアオブジェクトの指示情報を再生デバイス３０２へ送信する。指示情報はユニバーサル・リソース・アイデンティファイア（ＵＲＩ）を含み、再生デバイス３０２はそこから選択されたメディアオブジェクトを受信する。或いは、再生デバイス３０２がメディアオブジェクトを保有している場合は、制御ユニット６０６は再生デバイス３０２からリストを取得し、指示情報は選択されたメディアオブジェクトのファイルパスを含んでもよい。
【００５２】
受信ユニット６１２は、選択されたメディアオブジェクトの再生を可能にするＲＯを獲得する要求を受信する。その要求は、ＲＯの位置情報（典型的には、ＵＲＩ）、及び再生デバイス３０２の認証情報（典型的には、公開鍵基盤（ＰＫＩ）に基づく署名）を含む。
【００５３】
獲得ユニット６１４は、受信ユニット６１２によって受信された要求に「裏書き」を行う。即ち、獲得ユニット６１４は、受信した要求に基づいて、新しい要求（「裏書き付き要求」）を生成する。次いで獲得ユニット６１４は、受信した要求内のＵＲＩに対して裏書き付き要求を送信することにより、ＲＯを獲得する。いくつかの実施形態においては、裏書き付き要求は、制御デバイス３０１の認証情報（典型的には、ＰＫＩに基づく署名）を含んでもよい。認証情報は、メモリ６１６に格納可能な制御デバイス３０１の秘密鍵のような情報に基づいて生成される。メモリ６１６は、制御デバイス３０１がセルラ電話である場合はユニバーサルＩＣカード（ＵＩＣＣ）であってもよい。裏書き付き要求はまた、ＲＯの獲得について最終的に所有者が課金されるように、制御デバイス３０１の所有者に関連付けられた識別情報（例えば、デバイスＩＤ）も含んでもよい。
【００５４】
送信ユニット６１６は、再生デバイス３０２が選択されたメディアオブジェクトを復号して再生できるように、獲得ユニット６１４によって獲得されたＲＯを再生デバイス３０２へ送信する。
【００５５】
再生デバイス：
図７は、再生システム３００の再生デバイス３０２のブロック図を示す。プロセッサ７０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、再生デバイス３０２内に含まれるコンポーネントの各々を制御する。図７において、プロセッサ７０２に含まれるコンポーネントは、典型的にはプロセッサ７０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００５６】
送受信機７０４は、再生デバイス３０２と、例えば制御デバイス３０１、コンテンツサーバ３０３、及び権利発行装置３０４などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機７０４は、図７においては単純化のために単一のブロックとして記載されているが、送受信機７０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００５７】
コマンド受信ユニット７０６は、メディアオブジェクトを再生させるコマンドを制御デバイス３０１から受信する。コマンドは、再生対象のメディアオブジェクトの位置を指し示す位置情報（典型的には、ＵＲＩ）を含む。いくつかの実施形態においては、コマンド受信ユニット７０６は、制御デバイス３０１に関する位置情報も受信する。この位置情報は、ＲＯを獲得する要求を送信するために送信ユニット７１２によって使用される。
【００５８】
取得ユニット７０８は、コマンドに含まれるＵＲＩにアクセスし、メディアオブジェクトを取り出すことを試みる。メディアオブジェクトはＤＲＭを使用して保護されているので、メディアオブジェクトを含むコンテンツサーバ３０３は権利発行装置３０４のＵＲＩを返す。返されたＵＲＩにアクセスすることにより、取得ユニット７０８は、メディアオブジェクトの再生を可能にするＲＯのＵＲＩを取得する。或いは、メディアオブジェクトが記憶装置７１０に含まれる場合は、取得ユニット７０８はコマンドに含まれるファイルパスを受信し、権利発行装置３０４のＵＲＩをメディアオブジェクトのメタデータから取得する。
【００５９】
送信ユニット７１２は、ＲＯを獲得する要求を制御デバイス３０１へ送信する。換言すれば、送信ユニット７１２は、ＲＯの獲得を制御デバイス３０１に「委託」する。要求はＲＯのＵＲＩを含み、制御デバイス３０１はここからＲＯを獲得する。要求はまた、権利発行装置が最終的に再生デバイス３０２の信頼性を判断可能なように、再生デバイス３０２の認証情報（典型的には、ＰＫＩに基づく署名）も含む。送信ユニット７１２は、メモリ７１４に格納可能な再生デバイス３０２の秘密鍵のような情報に基づいて認証情報を生成する。メモリ７１４は、スタティック・ランダムアクセスメモリ（ＳＲＡＭ）であってもよい。
【００６０】
許可受信ユニット７１６は、要求に対する応答として、制御デバイス３０１からＲＯを受信する。
【００６１】
次に再生ユニット７１８は、許可受信ユニット７１６によって受信されたＲＯを使用して、メディアオブジェクトを復号して再生する。コマンドに含まれる位置情報に基づいて、再生ユニット７１８は、コンテンツサーバ３０３又は記憶装置７１０からメディアオブジェクトを取り出す。
【００６２】
権利発行装置：
図８は、再生システム３００の権利発行装置３０４のブロック図である。プロセッサ８０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、権利発行装置３０４内に含まれるコンポーネントの各々を制御する。図８において、プロセッサ８０２に含まれるコンポーネントは、典型的にはプロセッサ８０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００６３】
送受信機８０４は、権利発行装置３０４と、例えば制御デバイス３０１及び再生デバイス３０２などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機８０４は、図８においては単純化のために単一のブロックとして記載されているが、送受信機８０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００６４】
位置送信ユニット８０６は、どのメディアオブジェクトが再生対象であるかを再生デバイス３０２から通知されると、ＲＯの位置情報（典型的には、ＵＲＩ）を再生デバイス３０２へ送信する。位置送信ユニット８０６は、ＲＯを含む記憶装置８１４から位置情報を取得する。
【００６５】
受信ユニット８０８は、制御デバイス３０１から、位置送信ユニット８０６により送信された位置情報を使用してＲＯを獲得する要求を受信する。要求は再生デバイス３０２の認証情報（典型的には、ＰＫＩに基づく署名）を含む。
【００６６】
判定ユニット８１０は、例えばＯＣＳＰサーバ３０５によって管理されているＣＲＬをＯＣＳＰを介して参照することにより、再生デバイスが認証されているか否かを判定する。即ち、判定ユニット８１０は、認証情報が無効化されているか否かを判定する。
【００６７】
許可送信ユニット８１２は、再生デバイスが認証されていると判定ユニット８１０が判定した場合、記憶装置８１４からＲＯを取り出して制御デバイス３０１へ送信する。
【００６８】
いくつかの実施形態においては、受信ユニット８０８によって受信される要求は、制御デバイス３０１の認証情報も含み、判定ユニットは、制御デバイス３０１が認証されているか否かを判定する。許可送信ユニットは、再生デバイス３０２及び制御デバイス３０１の両方が認証されている場合に、制御デバイス３０１へＲＯを送信する。
【００６９】
いくつかの実施形態においては、受信ユニット８０８は、制御デバイス３０１の所有者に関連付けられた識別情報（例えば、デバイスＩＤ）も受信する。課金ユニット８１６は、ＲＯの獲得について所有者に課金する。より具体的には、課金ユニット８１６は、課金サーバ３０６が所有者に課金可能なように、課金サーバ３０６に対して価格情報と共に識別情報を送信する。
【００７０】
典型的な再生手順：
図９は、再生システム３００において実行される処理を示すフローチャートである。
【００７１】
ステップＳ９０１で、制御デバイス３０１は、例えば制御デバイス３０１上の組み込みブラウザを使用した所有者による操作に従って、コンテンツサーバ３０３にログオンする。ログインのためのＨＴＴＰ ＵＲＬは、所有者が事前に知っている。
【００７２】
ステップＳ９０２で、制御デバイス３０１は、コンテンツサーバ３０３に格納されているコンテンツ（メディアオブジェクト）のリストを受信する。リスト内の各項目は、対応するＲＴＳＰ ＵＲＩを含み、そこからコンテンツをストリーミング可能である。
【００７３】
ステップＳ９０３で、所有者はリストを閲覧して再生対象のメディアオブジェクトを選択する。制御デバイス３０１は、所有者の選択に応えてメディアオブジェクトを選択する。
【００７４】
ステップＳ９０４で、制御デバイス３０１は、ＵＰｎＰディスカバリプロセス［５］を使用して再生デバイス３０２（メディアレンダラ）を発見する。
【００７５】
ステップＳ９０５で、制御デバイス３０１は、［６］に規定されるＵＰｎＰ ＡＶＳｅｔＴｒａｎｓｐｏｒｔＵＲＩアクションを使用して、上のステップＳ９０２及びＳ９０３で取得した対象のＲＴＳＰ ＵＲＩを再生デバイス３０２に設定する。
【００７６】
ステップＳ９０６で、制御デバイス３０１は、プレーバック（再生）を開始するために、ＵＰｎＰ Ｐｌａｙアクションコマンド［６］を送信する。本実施形態においては、ＵＰｎＰ Ｐｌａｙアクションは、アクション要求が追加変数として「ＲＯ獲得委託ＵＲＩ」を搬送可能なように拡張される。委託ＵＲＩは、後のステップＳ９１２において制御デバイス３０１に対して委託要求を送信するために再生デバイス３０２によって使用されるＨＴＴＰ ＵＲＬである。このことは、制御デバイス３０１が、再生デバイス３０２からの委託要求をこの特定のＵＲＩで待ち受けなければならないということを意味する。
【００７７】
Ｐｌａｙアクションによって命令されると、ステップＳ９０７で、再生デバイス３０２は、ステップＳ９０５において事前に設定されているＲＴＳＰ ＵＲＩに対して、ＲＴＳＰ：：Ｄｅｓｃｒｉｂｅ要求を送信する。この要求は、コンテンツサーバ３０３によって受信される。
【００７８】
ステップＳ９０８で、コンテンツサーバ３０３は、２００ＯＫ応答内でコンテンツのＳＤＰ［１１］を返す。この実施形態では、コンテンツがＰＤＣＦ（Packetized DRM Content Format: ストリーミング可能なＯＭＡ ＤＲＭコンテンツフォーマット［７］）の形式で保護されており、且つ、３ＧＰＰにおけるパケット交換型ストリーミングサービス［８］（これはＲＴＳＰを使用してＰＤＣＦをストリーミングするやり方を規定する）において規定されるＳＤＰシグナリングが使用されることを想定しているので、返されるＳＤＰは、権利発行装置ＵＲＬ(RightsIssuerURL)を含む。図１０は、コンテンツサーバ３０３によって返されるＳＤＰの例を示す。
【００７９】
ＳＤＰを受信すると、ステップＳ９０９で、再生デバイス３０２は、コンテンツが保護されているということを知るようになる。それゆえ、再生デバイス３０２は、権利発行装置からＲＯＡＰトリガを取り出すために、ＳＤＰに含まれる権利発行装置ＵＲＬに対して、ＨＴＴＰ Ｇｅｔ要求を送信する。
【００８０】
ステップＳ９１０で、権利発行装置３０４は、ＲＯＡＰトリガを返す。ＲＯＡＰトリガの種類は、ROAcquisitionTriggerである。ＲＯＡＰトリガは、ステップＳ９０３で選択されたメディアオブジェクトの再生を可能にするＲＯのＵＲＩを含む。
【００８１】
ステップＳ９１１で、再生デバイス３０２は、再生デバイス３０２によって署名されたＲＯＡＰ−ＲＯＲｅｑｕｅｓｔメッセージを生成する。
【００８２】
ステップＳ９１２で、再生デバイス３０２は、ＲＯＲｅｑｕｅｓｔと権利発行装置から受信されたＲＯＡＰトリガとの両方を含む要求メッセージを、ＲＯ獲得委託ＵＲＩに対して送信する。この要求メッセージの例を図１１に示す。この例は、この要求が委託ＵＲＩに対してＨＴＴＰ ＰＯＳＴされており、ＲＯＲｅｑｕｅｓｔ及びＲＯＡＰトリガがＨＴＴＰ要求内に多重化されているということを示す。
【００８３】
ステップＳ９１３で、制御デバイス３０１は、例えばディスプレイ６０８に表示される何らかの形式のユーザインタフェースを介して、所有者の同意を得ようと試みる。
【００８４】
ステップＳ９１４で、制御デバイス３０１は、ＲＯＲｅｑｕｅｓｔに対して裏書きを行って裏書き付き要求を生成する。図１２に示すように、この例では、裏書き付きＲＯＲｅｑｕｅｓｔは、別のＸＭＬエレメントである＜endorsement＞にカプセル化されることにより、このＲＯＲｅｑｕｅｓｔは裏書きされているということを権利発行装置３０４に指し示す。この例では、＜endorsement＞エレメントのために新しいＸＭＬ名前空間が定義されている。＜endorserInfo＞エレメントは、デバイスＩＤのような、裏書きを行ったデバイスの情報を搬送する。＜signature＞エレメントは、＜endorsement＞をルートとするＸＭＬ文書全体をカバーする、制御デバイス３０１の署名を格納する。＜endorserInfo＞内の各エレメントの構文は、ＯＭＡ ＤＲＭ ２．０［１］に従う。
【００８５】
ステップＳ９１５で、制御デバイス３０１は、ステップＳ９１２において再生デバイス３０２から受信したＲＯＡＰトリガの中のＲＯＡＰ ＵＲＬによって位置確認可能な権利発行装置３０４に対して、裏書き付きＲＯＲｅｑｕｅｓｔ（図１１に示すメッセージ）を送信する。
【００８６】
ステップＳ９１６で、権利発行装置３０４がＲＯＲｅｑｕｅｓｔの中に＜endorsement＞エレメントを発見した場合、権利発行装置３０４はこの要求を裏書きされているものとして解釈する。この場合、権利発行装置３０４は裏書きを行った者の情報（制御デバイス３０１の情報）と、再生デバイス３０２によって生成されたＲＯＲｅｑｕｅｓｔとをカプセル化解除する。再生デバイス３０２の署名を使用して、権利発行装置３０４は、再生デバイス３０２が認証されているか否かを判定する。この判定は、例えばＯＣＳＰサーバ３０５によって管理されているＣＲＬをチェックすることにより、実行可能である。
【００８７】
ステップＳ９１７で、権利発行装置３０４は、課金サーバ３０６がＲＯについて制御デバイス３０１の所有者に課金可能なように、発行されるＲＯの価格情報と共に制御デバイスのデバイスＩＤを課金サーバ３０６へ送信する。
【００８８】
ステップＳ９１８で、（再生デバイス３０２が認証されていると判定された場合は、）権利発行装置３０４は、再生デバイス３０２に対して権利が与えられたＲＯ（即ち、再生デバイス３０２の公開鍵を用いて保護されているＲＯ）を含むＲＯＲｅｓｐｏｎｓｅを生成する。ＲＯＲｅｓｐｏｎｓｅは最終的に、制御デバイス３０１へと返送される。
【００８９】
ステップＳ９１９で、制御デバイス３０１は、ステップＳ９１２における委託要求への応答として、ＲＯＲｅｓｐｏｎｓｅを再生デバイス３０２に対して転送する。
【００９０】
再生デバイス３０２はＲＯを獲得したので、ステップＳ９２０で、再生デバイス３０２はコンテンツサーバ３０３から保護されたコンテンツを（この例ではストリーミングを利用して）受信する準備ができている。再生デバイス３０２は、ストリーミングの受信を開始するために、ＲＴＳＰ：：Ｓｅｔｕｐコマンド及びＲＴＳＰ：：Ｐｌａｙコマンドを送信する。
【００９１】
ステップＳ９２１で、再生デバイス３０２は、コンテンツサーバ３０３からの保護されたストリーミングを、ＲＯを使用することにより復号して再生する。
【００９２】
上述の通り、既存のソリューション（サブライセンス技術）ではエンドデバイス間の認証が発生することになっているが、一方で、本発明はこの認証を必要としない。即ち、既存のソリューションでは、サブライセンスを与えるデバイスは、サブライセンスを受けるデバイスが認証されたデバイス（即ち、信頼されるデバイス）であることを確認するために、サブライセンスを受けるデバイスを認証することになっている。また、サブライセンスを与えるデバイスは、サブライセンスを受けるデバイスが信用できなくなっていないということを確認するために、ＣＲＬを参照してサブライセンスを受けるデバイスの証明書の無効状態をチェックする機能を必要とした。
【００９３】
一方、本発明は、制御デバイスが再生デバイスを認証することを必要としない。なぜなら、再生デバイスは、（裏書き付き）ＲＯＲｅｑｕｅｓｔ内の再生デバイスの電子証明を検証する権利発行装置によって認証されるからである。それゆえ、本発明は、制御デバイスが証明書の無効をチェックするという上述した機能を必要としない。
【００９４】
従って、通常は小さな帯域と比較的低い処理能力しか持たない移動体デバイスである制御デバイスにとっての処理負荷が低減される。
【００９５】
加えて、制御デバイスはＲＯＲｅｑｕｅｓｔを裏書き付き要求の中にカプセル化するだけなので、権利発行装置は、再生デバイスによって生成されたＲＯＲｅｑｕｅｓｔに含まれる全ての情報を取得することができる。
【００９６】
略語：
UPnP ユニバーサル・プラグアンドプレイ
AV オーディオビジュアル
SIM 加入者ＩＤモジュール
IMSI 国際移動加入者識別番号
OMA オープン・モバイル・アライアンス
DRM デジタル著作権管理
CP ＵＰｎＰコントロールポイント
SDP セッション記述プロトコル
DCF ＤＲＭコンテンツフォーマット
PDCF パケット化ＤＣＦ
OCSP オンライン証明書状態プロトコル
PKI 公開鍵基盤
【００９７】
参考文献：
[1] OMA DRM Specification, Approved Version 2.0 - 03 Mar 2006
[2] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC2560
[3] SCE Requirements, Draft Version 2.0 - 22 May 2006, OMA-RD-SCE-V1_0-20060522-D
[4] “Content and License Delivery to Shared Devices,” Patent Application Publication, Pub. No.: US 2006/0036554 A1
[5] UPnP Device Architecture 1.0, http://www.upnp.org/resources/documents/CleanUPnPDA101-20031202s.pdf
[6] UpnP AVTransport:1 Service Template Version 1.01, http://www.upnp.org/standardizeddcps/documents/AVTransport1.0.pdf
[7] OMA DRM Content Format, Approved Version 2.0 - 03 Mar 2006
[8] 3GPP TS 26.234 Transport end-to-end Packet-switched Streaming Service (PSS); Protocol and codecs (Release 6)
[9] UPnP MediaServer 1.0, http://www.upnp.org/standardizeddcps/documents/MediaServer1.0.pdf
[10] UPnP MediaRenderer 1.0, http://www.upnp.org/standardizeddcps/documents/MediaRenderer1.0_000.pdf
[11] Session Description Protocol (SDP), RFC2327
【技術分野】
【０００１】
本発明は、概して、保護されたマルチメディアデータの再生を可能にするパーミッション（許可情報）を獲得するための技術に関する。
【背景技術】
【０００２】
ＯＭＡ ＤＲＭ ２．０：
Open Mobile Alliance（ＯＭＡ）は、２００６年３月３日に、Digital Rights Management Version 2 (OMA DRM 2.0)の承認されたイネーブラをリリースした［１］。ＯＭＡ ＤＲＭ ２．０のイネーブラのリリースは、移動体環境においてＤＲＭシステムを実装するために必要なプロトコル、メッセージ、及びメカニズムを規定する。
【０００３】
ＯＭＡ ＤＲＭ ２．０では、他の類似したＤＲＭシステムと同様に、保護されたコンテンツがユーザデバイスへと配信され、特定の権利オブジェクト（ＲＯ）と一緒にそのコンテンツを消費可能である。ＲＯは、ネットワークを介して安全なやり方で獲得可能であり、この獲得メカニズムは、ＯＭＡ ＤＲＭ ２．０仕様の不可欠な部分である。それは権利オブジェクト獲得プロトコル（ＲＯＡＰ）として規定されており、２つの重要なＯＭＡ ＤＲＭ ２．０エンティティである「デバイス」及び「権利発行装置」を伴う。
【０００４】
以下は、ＯＭＡ ＤＲＭ ２．０における、デバイス、権利発行装置、及びこれらに関連する規定に関する、公式の規定である。
【０００５】
− デバイス： ＤＲＭエージェントを実装するユーザ装置内のエンティティ（ハードウェア、ソフトウェア、又はそれらの組み合わせ）
− 権利発行装置： ＯＭＡ ＤＲＭ準拠のデバイスに対して権利オブジェクトを発行するエンティティ
− ＤＲＭエージェント： デバイス上のメディアオブジェクトのための許可情報を管理する、デバイスにおけるエンティティ
− 許可情報： 保護されたコンテンツに対して（権利発行装置によって）許可された実際の用途及び動作
− メディアオブジェクト： 例えば呼出音、スクリーンセーバ、Ｊａｖａ（登録商標）ゲームなどの、デジタル作品
− 保護されたコンテンツ： 権利オブジェクト内の許可情報のセットに従って消費されるメディアオブジェクト
− 権利オブジェクト（ＲＯ）： 保護されたコンテンツに結び付けられた、許可情報及びその他の属性の集合
【０００６】
ＲＯＡＰの詳細なメカニズム（例えば、デバイスが自身の登録先の権利発行装置とどのように対話しなければならないか、デバイスがどのようにＲＯを獲得しなければならないか、など）は、ＯＭＡ ＤＲＭ仕様書［１］に見ることができる。
【０００７】
課金システム：
ＯＭＡ ＤＲＭ ２．０は、メディアオブジェクトの消費を制御するために利用可能である。従って、メディアオブジェクトの提供者（以下、「コンテンツプロバイダ」と呼ぶ）は、ＯＭＡ ＤＲＭ ２．０を利用することにより、消費者に課金することができる。より具体的には、コンテンツプロバイダは、ＲＯの獲得について消費者に対して課金することができる。
【０００８】
ＯＭＡ ＤＲＭ ２．０標準は、実システムにおいてどのようにＲＯの獲得に対して課金されるかを明示してはいないが、既知のシステムの１つによれば、（デバイスＩＤによって特定される）「デバイス」が、コンテンツプロバイダにおいてユーザの（所有者の）課金情報（例えば、クレジットカード番号など）と事前に関連付けられる。「デバイス」がＳＩＭ（加入者ＩＤモジュール）を備えた移動体端末である場合、課金情報はＩＭＳＩ（国際移動加入者識別番号）であってもよい。そのデバイスによって実行されるＲＯの獲得は、事前に関連付けられた課金情報に従って自動的に課金される。以下は、このシステムの詳細な説明である。
【０００９】
ＯＭＡ ＤＲＭ ２．０では、「デバイス」は、ＲＯＡＰを介したＲＯの獲得の要求元として権利発行装置が認識可能な、唯一の標準エンティティである。対応するデバイスＩＤは、権利発行装置がそれによって各デバイスを一意に識別可能な、唯一の規定された識別情報である（現在規定されている唯一のデバイスＩＤは、デバイスの公開鍵のハッシュである）。このシステムにおいて、デバイスＩＤは、課金対象を特定する手段として使用される。
【００１０】
デバイスＩＤは、デバイスの所有者の課金情報に関連付けられる。所有者によっては２以上のデバイスを所有するということも大いにあり得ることである（図１参照）。図１において、所有者ＡはデバイスＸ及びデバイスＹを所有し、両デバイスのデバイスＩＤは、所有者Ａの課金情報に関連付けられる。従って、デバイスＸ及びデバイスＹによって実行されるＲＯの獲得は共に、所有者Ａに対して課金可能である。ＯＭＡ ＤＲＭ ２．０では標準化されていない課金機能が、所有者とデバイスＩＤとの間の関連付けを管理する。
【００１１】
認証：
デバイスに対してＲＯを発行する前に、権利発行装置がデバイスを認証することが望ましい。これは、デバイスがハッキングされたり、セキュリティ上のバグを含んでいたり、不正に設計されたりした場合に、デバイスがＲＯを悪用する可能性があるからである。例えば、デバイスは、復号されたメディアオブジェクトを「盗んで」、許可されていないユーザに対してＤＲＭ保護無しでこれを提供するかもしれない。このことはコンテンツプロバイダ（即ち、メディアオブジェクトの権利者）に損害を与える可能性がある。
【００１２】
ＲＯの発行を受けるデバイスが信用できるものであるか否かを権利発行装置が知るための１つのやり方は、例えばＯＣＳＰ(Online Certificate Status Protocol)［２］を介して、デバイスの証明書の無効状態をチェックすることである。例えば、デバイスが信用できないようになると、製造時にデバイスに証明書をインストールしたデバイスのベンダはＰＫＩシステムに対してその証明書を無効にするように要求するであろうから、デバイスの証明書はそれに関与するＰＫＩシステム内で無効にされそうである。
【００１３】
ＲＯのサブライセンス：
デバイスの「所有者」とデバイスの「ユーザ」とが異なる場合に、説明した課金システムは問題を引き起こす。この事例が発生するのは、例えば、ホテル、友人の家、訪問先オフィス、カフェ、駅といった多数の訪問先の場所で利用可能なデバイスを、ユーザがその場限りの（アドホックな）やり方で使用する場合である。この場合、メディアオブジェクトを実際に消費したユーザの代わりに、ＲＯを獲得したデバイスの所有者が、最終的に課金される。
【００１４】
この問題に対処するために、ＲＯをサブライセンスする技術（以下、「サブライセンス技術」と呼ぶ）が知られている［３］［４］。サブライセンス技術は、権利発行装置からＲＯを元々獲得したデバイスが他のデバイスに対してＲＯのサブライセンス（以下、「サブＲＯ」と呼ぶ）を更に発行することを可能にする。サブＲＯは、元々のＲＯ（オリジナルＲＯ）の許可情報の全部又は一部を含む。
【００１５】
図２は、サブライセンス技術の基本的な考えを示す。デバイス２２０は、メディアオブジェクトを実際に消費するユーザによって所有されている。デバイス１（２３１）からデバイスｍ（２３３）は全て、ユーザとは別の所有者によって所有されている。
【００１６】
デバイス１（２３１）は、インターネットを介して映画データを取り出すことが可能なパーソナルコンピュータ（ＰＣ）であり、ホテルの部屋に設置されていてホテルによって所有されているものとする。ＤＲＭによって保護されている映画を視聴することをユーザが望む場合、例えばユーザのセルラ電話であるデバイス２２０は最初に、その映画のためのＲＯ（オリジナルＲＯ）を獲得する。デバイス２２０は次に、デバイス１（２３１）に対して、オリジナルＲＯに基づいてサブＲＯを発行する。そして、デバイス１（２３１）は、発行されたサブＲＯに従って映画を再生する。
【００１７】
ユーザが所有するデバイス２２０が最初にＲＯを獲得するので、コンテンツプロバイダ（即ち、映画の権利者）は、デバイス１（２３１）を所有するホテルではなくて映画を実際に視聴するユーザに対して課金することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
サブライセンス技術における既存の問題：
サブライセンス技術が利用される場合、サブライセンスを受けるデバイスがサブＲＯの使用を許可された（信頼できる）デバイスであることを保証するために、サブＲＯを発行する前に、サブライセンスを与えるデバイス（例えば、デバイス２２０）がサブライセンスを受けるデバイス（例えば、デバイス１（２３１））を認証する必要がある。サブライセンスを与えるデバイスは、認証されるデバイスの信頼性を確認するために、デバイスを認証する度に、例えばＯＣＳＰを介してＰＫＩシステムと通信することによってサブライセンスを受けるデバイスの無効状態をチェックすることが好ましい。
【００１９】
しかしながら、これはサブライセンスを与えるデバイスにとって間違いなく損失の大きな動作である。なぜなら、サブライセンスを与えるデバイスの演算能力及び帯域は通常、権利発行装置と比べて限られているからである。サブライセンスを与えるデバイスが例えばセルラ電話であってデータ通信に対する料金請求が送受信されたトラヒック量に基づく状況においては、この問題は特に深刻である。
【課題を解決するための手段】
【００２０】
本発明の特徴は、既存の問題を解決することである。
【００２１】
本発明の一態様によれば、制御デバイスであって、マルチメディアデータを再生するように再生デバイスを制御する制御手段と、許可サーバに含まれる許可データを獲得する要求を前記再生デバイスから受信する受信手段と、を備え、前記許可データは、前記マルチメディアデータの再生を可能にするものであり、前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイスの認証情報とを含み、前記制御デバイスは、前記位置情報によって指し示される位置から前記許可データを獲得する獲得手段であって、前記認証情報を前記許可サーバへ送信する獲得手段と、前記許可データを前記再生デバイスへ送信する送信手段と、を備えることを特徴とする制御デバイスが提供される。
【００２２】
本発明の他の態様によれば、再生デバイスであって、マルチメディアデータを再生するコマンドを制御デバイスから受信するコマンド受信手段と、前記マルチメディアデータの再生を可能にする許可データであって、許可サーバに含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得手段と、前記許可データを獲得する要求であって、前記位置情報と前記再生デバイスの認証情報とを含む要求を、前記制御デバイスへ送信する送信手段と、前記要求に対する応答として前記許可データを前記制御デバイスから受信する許可受信手段と、前記許可データを使用して前記マルチメディアデータを再生する再生手段と、を備えることを特徴とする再生デバイスが提供される。
【００２３】
本発明の他の態様によれば、許可サーバであって、マルチメディアデータの再生を可能にする許可データであって、前記許可サーバに含まれる許可データの位置を指し示す位置情報を、再生デバイスへ送信する位置送信手段と、前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイスの認証情報を含む要求を、制御デバイスから受信する受信手段と、前記再生デバイスが認証されているか否かを前記認証情報に基づいて判定する判定手段と、前記再生デバイスが認証されていると前記判定手段が判定した場合に、前記要求に応えて前記制御デバイスへ前記許可データを送信する許可送信手段と、を備えることを特徴とする許可サーバが提供される。
【００２４】
本発明の他の態様によれば、制御デバイスの制御方法であって、マルチメディアデータを再生するように再生デバイスを制御する制御ステップと、許可サーバに含まれる許可データを獲得する要求を前記再生デバイスから受信する受信ステップと、を備え、前記許可データは、前記マルチメディアデータの再生を可能にするものであり、前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイスの認証情報とを含み、前記制御方法は、前記位置情報によって指し示される位置から前記許可データを獲得する獲得ステップを備え、当該獲得ステップにおいては、前記認証情報が前記許可サーバへ送信され、前記制御方法は、前記許可データを前記再生デバイスへ送信する送信ステップを備えることを特徴とする制御方法が提供される。
【００２５】
本発明の他の態様によれば、再生デバイスの制御方法であって、マルチメディアデータを再生するコマンドを制御デバイスから受信するコマンド受信ステップと、前記マルチメディアデータの再生を可能にする許可データであって、許可サーバに含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得ステップと、前記許可データを獲得する要求であって、前記位置情報と前記再生デバイスの認証情報とを含む要求を、前記制御デバイスへ送信する送信ステップと、前記要求に対する応答として前記許可データを前記制御デバイスから受信する許可受信ステップと、前記許可データを使用して前記マルチメディアデータを再生する再生ステップと、を備えることを特徴とする制御方法が提供される。
【００２６】
本発明の他の態様によれば、許可サーバの制御方法であって、マルチメディアデータの再生を可能にする許可データであって、前記許可サーバに含まれる許可データの位置を指し示す位置情報を、再生デバイスへ送信する位置送信ステップと、前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイスの認証情報を含む要求を、制御デバイスから受信する受信ステップと、前記再生デバイスが認証されているか否かを前記認証情報に基づいて判定する判定ステップと、前記再生デバイスが認証されていると前記判定ステップが判定した場合に、前記要求に応えて前記制御デバイスへ前記許可データを送信する許可送信ステップと、を備えることを特徴とする制御方法が提供される。
【００２７】
本発明の主な利点は、以下の通りである。制御デバイスの代わりに許可サーバが、許可サーバによって発行される許可情報を実際に消費する再生デバイスを認証する。従って、許可サーバに比べて比較的小さな帯域しか持たず比較的低い処理能力しか持たない制御デバイスにとっての処理負荷が低減される。
【００２８】
本発明の更なる特徴は、添付の図面に関連する典型的な実施形態に関する以下の説明から明らかになるであろう。添付の図面において、全図を通して、同一の参照符号は同一又は類似の部分を指し示す。
【図面の簡単な説明】
【００２９】
【図１】所有者とデバイスＩＤとの間の関連付けの例を示す。
【図２】サブライセンス技術の基本的な考えを示す。
【図３】実施形態に従う再生システムの概観を示す。
【図４】ＵＰｎＰ ＡＶ（オーディオビジュアル）デバイスの対話モデルを示す。
【図５】ＯＭＡ ＤＲＭデバイス（即ち、制御デバイス）を課金情報に関連付けるやり方の手順例を示す。
【図６】再生システムの制御デバイスのブロック図を示す。
【図７】再生システムの再生デバイスのブロック図を示す。
【図８】再生システム３００の権利発行装置のブロック図を示す。
【図９】再生システムにおいて実行される処理を示すフローチャートである。
【図１０】コンテンツサーバによって返されるＳＤＰの例を示す。
【図１１】再生デバイスによって制御デバイスへと送信される要求メッセージの例を示す。
【図１２】制御デバイスによって権利発行装置へと送信される、裏書された要求メッセージの例を示す。
【発明を実施するための形態】
【００３０】
再生システム：
図３は、実施形態に従う再生システム３００の概観を示す。
【００３１】
再生システム３００において、制御デバイス３０１は、マルチメディアデータ（メディアオブジェクト）を再生するように再生デバイス３０２を制御する。制御デバイス３０１の所有者は、これを制御してメディアオブジェクトを消費する（即ち、読み、視聴し、聴く、などする）ユーザである。制御デバイス３０１は、セルラ電話、携帯情報端末（ＰＤＡ）、ノートブックコンピュータなどの、任意の種類のデバイスであってよい。
【００３２】
再生デバイス３０２は、メディアオブジェクトを再生可能である限り、テレビ（ＴＶ）、ＰＣなどの、任意の種類のデバイスであってよい。再生デバイス３０２は、制御デバイスの所有者とは異なる人（又は組織）によって所有されている。再生デバイス３０２は、制御デバイス３０１による制御に応えて、メディアオブジェクトを再生する。
【００３３】
制御デバイス３０１及び再生デバイス３０２は、ユニバーサル・プラグアンドプレイ（ＵＰｎＰ）ネットワーク３１１（詳細は後述する）を介して相互に接続される。典型的な実施形態において、再生デバイス３０２は、ホテルの部屋に設置されたＴＶであり、制御デバイス３０１の所有者はホテルの宿泊客である。しかしながら、制御デバイス３０１及び再生デバイス３０２は、ＵＰｎＰ以外の任意の接続スキームを使用して接続されてもよい。
【００３４】
コンテンツサーバ３０３は、メディアオブジェクトを含み、インターネット３１２を介して再生デバイス３０２にメディアオブジェクトを提供する。以下の説明では、メディアオブジェクトはＯＭＡ ＤＲＭ ２．０に基づいて保護されて（復号される）ものとする。コンテンツサーバ３０３はまた、再生デバイス３０２で利用可能なメディアオブジェクトのリストを制御デバイス３０１に提供する。コンテンツサーバ３０３は例えば、コンテンツプロバイダによって管理されるサーバであってもよいし、制御デバイス３０１の所有者によって所有されているハードディスクドライブ（ＨＤＤ）レコーダであってもよい。いくつかの実施形態では、再生デバイス３０２は、メディアオブジェクトを含んだ記憶装置を有し、コンテンツサーバ３０３の代わりにその記憶装置からメディアオブジェクトを取り出してもよい。
【００３５】
権利発行装置３０４は、コンテンツサーバ３０３（又は再生デバイス３０２の記憶装置）に含まれるメディアオブジェクトの再生を可能にするＲＯを、制御デバイス３０１に対して発行する。権利発行装置３０４は許可情報（パーミッション）を含むＲＯを発行するので、本実施形態においては許可サーバとも呼ばれる。
【００３６】
ＯＣＳＰサーバ３０５は、証明書無効リスト（ＣＲＬ）を管理する。再生デバイス３０２がハッキングされたり、再生デバイス３０２が何らかのセキュリティ上のバグを含んでいたりすることが検知されると、再生デバイス３０２の証明書がＣＲＬに追加される。従って、権利発行装置３０４は、ＯＣＳＰを介してＯＣＳＰサーバ３０５にアクセスすることにより、ＲＯを発行する前に、再生デバイス３０２が認証されているか（即ち、信頼できるか）否かを判断可能である。
【００３７】
課金サーバ３０６は、権利発行装置３０４によって発行されたＲＯについて、制御デバイス３０１の所有者に課金する。課金サーバ３０６は、制御デバイス３０１の識別情報（例えば、デバイスＩＤ）に関連付けられている、所有者に関する課金情報を持つ。権利発行装置３０４がＲＯを発行する際に、権利発行装置３０４は制御デバイス３０１のデバイスＩＤを受信し、価格情報と共にデバイスＩＤを課金サーバ３０６へ転送する。従って、課金サーバ３０６は、発行されたＲＯについて所有者に課金することができる。
【００３８】
なお、図３に示されるいくつかのエンティティは、単一のエンティティの中に実装されてもよい。例えば、権利発行装置３０４及び課金サーバ３０６は、同一のサーバ内に実装されてもよい。
【００３９】
ＵＰｎＰ：
上述した通り、制御デバイス３０１及び再生デバイス３０２は、接続のためにＵＰｎＰを使用することができる。このセクションでは、ＵＰｎＰの詳細な説明を提供する。
【００４０】
ＵＰｎＰは、ＡＶデバイスなどの相互運用可能な家庭電化製品のための業界標準である。ＵＰｎＰデバイスアーキテクチャは、別々のＵＰｎＰデバイス説明書及びＵＰｎＰサービス説明書において規定される全てのＵＰｎＰ機能のための基礎である。本実施形態は、ＵＰｎＰ ＡＶアーキテクチャと、関連するＵＰｎＰデバイス仕様及びＵＰｎＰサービス仕様によって最も特徴付けられる。
【００４１】
ＵＰｎＰ ＡＶアーキテクチャは、ＵＰｎＰメディアサーバ［９］デバイス及びＵＰｎＰメディアレンダラ(MediaRenderer)［１０］デバイスを導入し、メディアサーバに格納されたメディアコンテンツ（例えば、ビデオ、オーディオ、画像、など）がＵＰｎＰコントロールポイント（ＣＰ）の制御下でメディアレンダラ上で再生されるやり方を示す。
【００４２】
なお、メディアサーバ、メディアレンダラ、及びＣＰは、論理エンティティに過ぎないので、メディアサーバ、メディアレンダラ、及びＣＰの任意の組（セット）を、単一の物理デバイス内に実装可能である。
【００４３】
図４は、ＵＰｎＰ ＡＶデバイスの対話モデルを示す。ＣＰは、メディアサーバ及びメディアレンダラの両方の動作を協調させ同期させる中心的役割を演じる。ＣＰは、所望のコンテンツがメディアサーバからメディアレンダラへ伝送されるように両デバイスを初期化して設定するためにＵＰｎＰプロトコルを使用するが、メディアサーバ及びメディアレンダラ自体は、ＨＴＴＰ−ＧＥＴ又はＲＴＳＰ−ＲＴＰのような非ＵＰｎＰの通信プロトコルを使用して相互に対話する。
【００４４】
図３に示す再生システム３００において、制御デバイス３０１はＣＰとしての役割を果たし、再生デバイス３０２はメディアレンダラとしての役割を果たす。コンテンツサーバ３０３はＵＰｎＰネットワーク３１１ではなくインターネット３１２を介して接続されているのでメディアサーバとしての役割を果たさないが、再生デバイス３０２は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）などの任意の種類のプロトコルを使用してコンテンツサーバ３０３からメディアオブジェクトを受信することができる。なお、コンテンツサーバ３０３がＵＰｎＰを使用して制御デバイス３０１及び再生デバイス３０２と接続可能な場合は、コンテンツサーバ３０３はメディアサーバとしての役割を果たすことができる。
【００４５】
デバイスＩＤと課金情報との間の関連付け：
上述の通り、課金サーバ３０６が発行されたＲＯについて所有者に課金することを可能にするために、制御デバイス３０１のデバイスＩＤは、制御デバイス３０１の所有者の課金情報に事前に関連付けられるべきである。
【００４６】
図５は、ＯＭＡ ＤＲＭデバイス（即ち、制御デバイス３０１）を課金情報に関連付けるやり方の手順例を示す。
【００４７】
ステップＳ５０１で、所有者は最初に、例えば権利発行装置３０４によって提供されるデバイス所有者登録ウェブページに対して、制御デバイス３０１の組み込みブラウザを用いてアクセスする。この対話型ウェブページにおいて、所有者は、制御デバイス３０１に関連付けられるべき必要な課金情報（例えば、クレジットカード番号）を提示する。ステップＳ５０２で、ステップＳ５０１において課金情報の追加が成功した後で、権利発行装置は制御デバイス３０１に対してＲＯＡＰトリガを送信する。ＲＯＡＰトリガのトリガタイプは、デバイスに対してＲＯＡＰ登録を開始するように促す登録要求トリガ(Registration Request Trigger)である。
【００４８】
これに続く４パスＲＯＡＰ登録プロトコル［１］（Ｓ５０３〜Ｓ５０６）によって、権利発行装置は、提示された課金情報を登録されたデバイスＩＤに関連付けることが可能である。
【００４９】
制御デバイス：
図６は、再生システム３００の制御デバイス３０１のブロック図を示す。プロセッサ６０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、制御デバイス３０１内に含まれるコンポーネントの各々を制御する。図６において、プロセッサ６０２に含まれるコンポーネントは、典型的にはプロセッサ６０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００５０】
送受信機６０４は、制御デバイス３０１と、例えば再生デバイス３０２、コンテンツサーバ３０３、及び権利発行装置３０４などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機６０４は、図６においては単純化のために単一のブロックとして記載されているが、送受信機６０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００５１】
制御ユニット６０６は、メディアオブジェクトを再生するように再生デバイス３０２を制御する。いくつかの実施形態においては、制御ユニット６０６はコンテンツサーバ３０３から、コンテンツサーバ３０３に含まれるメディアオブジェクトのリストを取得する。次いで制御ユニット６０６は、制御デバイスの所有者が再生を望むメディアデバイスを操作ユニット６１０（例えば、キーボード）を介して選択可能なように、リストをディスプレイ６０８に表示する。制御ユニット６０６は、操作ユニット６１０による操作に応えて、再生対象のメディアオブジェクトを選択し、選択されたメディアオブジェクトの指示情報を再生デバイス３０２へ送信する。指示情報はユニバーサル・リソース・アイデンティファイア（ＵＲＩ）を含み、再生デバイス３０２はそこから選択されたメディアオブジェクトを受信する。或いは、再生デバイス３０２がメディアオブジェクトを保有している場合は、制御ユニット６０６は再生デバイス３０２からリストを取得し、指示情報は選択されたメディアオブジェクトのファイルパスを含んでもよい。
【００５２】
受信ユニット６１２は、選択されたメディアオブジェクトの再生を可能にするＲＯを獲得する要求を受信する。その要求は、ＲＯの位置情報（典型的には、ＵＲＩ）、及び再生デバイス３０２の認証情報（典型的には、公開鍵基盤（ＰＫＩ）に基づく署名）を含む。
【００５３】
獲得ユニット６１４は、受信ユニット６１２によって受信された要求に「裏書き」を行う。即ち、獲得ユニット６１４は、受信した要求に基づいて、新しい要求（「裏書き付き要求」）を生成する。次いで獲得ユニット６１４は、受信した要求内のＵＲＩに対して裏書き付き要求を送信することにより、ＲＯを獲得する。いくつかの実施形態においては、裏書き付き要求は、制御デバイス３０１の認証情報（典型的には、ＰＫＩに基づく署名）を含んでもよい。認証情報は、メモリ６１６に格納可能な制御デバイス３０１の秘密鍵のような情報に基づいて生成される。メモリ６１６は、制御デバイス３０１がセルラ電話である場合はユニバーサルＩＣカード（ＵＩＣＣ）であってもよい。裏書き付き要求はまた、ＲＯの獲得について最終的に所有者が課金されるように、制御デバイス３０１の所有者に関連付けられた識別情報（例えば、デバイスＩＤ）も含んでもよい。
【００５４】
送信ユニット６１６は、再生デバイス３０２が選択されたメディアオブジェクトを復号して再生できるように、獲得ユニット６１４によって獲得されたＲＯを再生デバイス３０２へ送信する。
【００５５】
再生デバイス：
図７は、再生システム３００の再生デバイス３０２のブロック図を示す。プロセッサ７０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、再生デバイス３０２内に含まれるコンポーネントの各々を制御する。図７において、プロセッサ７０２に含まれるコンポーネントは、典型的にはプロセッサ７０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００５６】
送受信機７０４は、再生デバイス３０２と、例えば制御デバイス３０１、コンテンツサーバ３０３、及び権利発行装置３０４などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機７０４は、図７においては単純化のために単一のブロックとして記載されているが、送受信機７０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００５７】
コマンド受信ユニット７０６は、メディアオブジェクトを再生させるコマンドを制御デバイス３０１から受信する。コマンドは、再生対象のメディアオブジェクトの位置を指し示す位置情報（典型的には、ＵＲＩ）を含む。いくつかの実施形態においては、コマンド受信ユニット７０６は、制御デバイス３０１に関する位置情報も受信する。この位置情報は、ＲＯを獲得する要求を送信するために送信ユニット７１２によって使用される。
【００５８】
取得ユニット７０８は、コマンドに含まれるＵＲＩにアクセスし、メディアオブジェクトを取り出すことを試みる。メディアオブジェクトはＤＲＭを使用して保護されているので、メディアオブジェクトを含むコンテンツサーバ３０３は権利発行装置３０４のＵＲＩを返す。返されたＵＲＩにアクセスすることにより、取得ユニット７０８は、メディアオブジェクトの再生を可能にするＲＯのＵＲＩを取得する。或いは、メディアオブジェクトが記憶装置７１０に含まれる場合は、取得ユニット７０８はコマンドに含まれるファイルパスを受信し、権利発行装置３０４のＵＲＩをメディアオブジェクトのメタデータから取得する。
【００５９】
送信ユニット７１２は、ＲＯを獲得する要求を制御デバイス３０１へ送信する。換言すれば、送信ユニット７１２は、ＲＯの獲得を制御デバイス３０１に「委託」する。要求はＲＯのＵＲＩを含み、制御デバイス３０１はここからＲＯを獲得する。要求はまた、権利発行装置が最終的に再生デバイス３０２の信頼性を判断可能なように、再生デバイス３０２の認証情報（典型的には、ＰＫＩに基づく署名）も含む。送信ユニット７１２は、メモリ７１４に格納可能な再生デバイス３０２の秘密鍵のような情報に基づいて認証情報を生成する。メモリ７１４は、スタティック・ランダムアクセスメモリ（ＳＲＡＭ）であってもよい。
【００６０】
許可受信ユニット７１６は、要求に対する応答として、制御デバイス３０１からＲＯを受信する。
【００６１】
次に再生ユニット７１８は、許可受信ユニット７１６によって受信されたＲＯを使用して、メディアオブジェクトを復号して再生する。コマンドに含まれる位置情報に基づいて、再生ユニット７１８は、コンテンツサーバ３０３又は記憶装置７１０からメディアオブジェクトを取り出す。
【００６２】
権利発行装置：
図８は、再生システム３００の権利発行装置３０４のブロック図である。プロセッサ８０２は、ファームウェア及びオペレーティングシステムなどのコンピュータプログラムを実行することにより、権利発行装置３０４内に含まれるコンポーネントの各々を制御する。図８において、プロセッサ８０２に含まれるコンポーネントは、典型的にはプロセッサ８０２により実行されるコンピュータプログラムによって実装されるが、専用ハードウェアによって実装されてもよい。
【００６３】
送受信機８０４は、権利発行装置３０４と、例えば制御デバイス３０１及び再生デバイス３０２などのような外部ノードとの間でのデータの送信及び受信を制御する。送受信機８０４は、図８においては単純化のために単一のブロックとして記載されているが、送受信機８０４は、ブルートゥース（登録商標）送受信機及びイーサネット（登録商標）送受信機のような複数のコンポーネントを含んでもよい。
【００６４】
位置送信ユニット８０６は、どのメディアオブジェクトが再生対象であるかを再生デバイス３０２から通知されると、ＲＯの位置情報（典型的には、ＵＲＩ）を再生デバイス３０２へ送信する。位置送信ユニット８０６は、ＲＯを含む記憶装置８１４から位置情報を取得する。
【００６５】
受信ユニット８０８は、制御デバイス３０１から、位置送信ユニット８０６により送信された位置情報を使用してＲＯを獲得する要求を受信する。要求は再生デバイス３０２の認証情報（典型的には、ＰＫＩに基づく署名）を含む。
【００６６】
判定ユニット８１０は、例えばＯＣＳＰサーバ３０５によって管理されているＣＲＬをＯＣＳＰを介して参照することにより、再生デバイスが認証されているか否かを判定する。即ち、判定ユニット８１０は、認証情報が無効化されているか否かを判定する。
【００６７】
許可送信ユニット８１２は、再生デバイスが認証されていると判定ユニット８１０が判定した場合、記憶装置８１４からＲＯを取り出して制御デバイス３０１へ送信する。
【００６８】
いくつかの実施形態においては、受信ユニット８０８によって受信される要求は、制御デバイス３０１の認証情報も含み、判定ユニットは、制御デバイス３０１が認証されているか否かを判定する。許可送信ユニットは、再生デバイス３０２及び制御デバイス３０１の両方が認証されている場合に、制御デバイス３０１へＲＯを送信する。
【００６９】
いくつかの実施形態においては、受信ユニット８０８は、制御デバイス３０１の所有者に関連付けられた識別情報（例えば、デバイスＩＤ）も受信する。課金ユニット８１６は、ＲＯの獲得について所有者に課金する。より具体的には、課金ユニット８１６は、課金サーバ３０６が所有者に課金可能なように、課金サーバ３０６に対して価格情報と共に識別情報を送信する。
【００７０】
典型的な再生手順：
図９は、再生システム３００において実行される処理を示すフローチャートである。
【００７１】
ステップＳ９０１で、制御デバイス３０１は、例えば制御デバイス３０１上の組み込みブラウザを使用した所有者による操作に従って、コンテンツサーバ３０３にログオンする。ログインのためのＨＴＴＰ ＵＲＬは、所有者が事前に知っている。
【００７２】
ステップＳ９０２で、制御デバイス３０１は、コンテンツサーバ３０３に格納されているコンテンツ（メディアオブジェクト）のリストを受信する。リスト内の各項目は、対応するＲＴＳＰ ＵＲＩを含み、そこからコンテンツをストリーミング可能である。
【００７３】
ステップＳ９０３で、所有者はリストを閲覧して再生対象のメディアオブジェクトを選択する。制御デバイス３０１は、所有者の選択に応えてメディアオブジェクトを選択する。
【００７４】
ステップＳ９０４で、制御デバイス３０１は、ＵＰｎＰディスカバリプロセス［５］を使用して再生デバイス３０２（メディアレンダラ）を発見する。
【００７５】
ステップＳ９０５で、制御デバイス３０１は、［６］に規定されるＵＰｎＰ ＡＶＳｅｔＴｒａｎｓｐｏｒｔＵＲＩアクションを使用して、上のステップＳ９０２及びＳ９０３で取得した対象のＲＴＳＰ ＵＲＩを再生デバイス３０２に設定する。
【００７６】
ステップＳ９０６で、制御デバイス３０１は、プレーバック（再生）を開始するために、ＵＰｎＰ Ｐｌａｙアクションコマンド［６］を送信する。本実施形態においては、ＵＰｎＰ Ｐｌａｙアクションは、アクション要求が追加変数として「ＲＯ獲得委託ＵＲＩ」を搬送可能なように拡張される。委託ＵＲＩは、後のステップＳ９１２において制御デバイス３０１に対して委託要求を送信するために再生デバイス３０２によって使用されるＨＴＴＰ ＵＲＬである。このことは、制御デバイス３０１が、再生デバイス３０２からの委託要求をこの特定のＵＲＩで待ち受けなければならないということを意味する。
【００７７】
Ｐｌａｙアクションによって命令されると、ステップＳ９０７で、再生デバイス３０２は、ステップＳ９０５において事前に設定されているＲＴＳＰ ＵＲＩに対して、ＲＴＳＰ：：Ｄｅｓｃｒｉｂｅ要求を送信する。この要求は、コンテンツサーバ３０３によって受信される。
【００７８】
ステップＳ９０８で、コンテンツサーバ３０３は、２００ＯＫ応答内でコンテンツのＳＤＰ［１１］を返す。この実施形態では、コンテンツがＰＤＣＦ（Packetized DRM Content Format: ストリーミング可能なＯＭＡ ＤＲＭコンテンツフォーマット［７］）の形式で保護されており、且つ、３ＧＰＰにおけるパケット交換型ストリーミングサービス［８］（これはＲＴＳＰを使用してＰＤＣＦをストリーミングするやり方を規定する）において規定されるＳＤＰシグナリングが使用されることを想定しているので、返されるＳＤＰは、権利発行装置ＵＲＬ(RightsIssuerURL)を含む。図１０は、コンテンツサーバ３０３によって返されるＳＤＰの例を示す。
【００７９】
ＳＤＰを受信すると、ステップＳ９０９で、再生デバイス３０２は、コンテンツが保護されているということを知るようになる。それゆえ、再生デバイス３０２は、権利発行装置からＲＯＡＰトリガを取り出すために、ＳＤＰに含まれる権利発行装置ＵＲＬに対して、ＨＴＴＰ Ｇｅｔ要求を送信する。
【００８０】
ステップＳ９１０で、権利発行装置３０４は、ＲＯＡＰトリガを返す。ＲＯＡＰトリガの種類は、ROAcquisitionTriggerである。ＲＯＡＰトリガは、ステップＳ９０３で選択されたメディアオブジェクトの再生を可能にするＲＯのＵＲＩを含む。
【００８１】
ステップＳ９１１で、再生デバイス３０２は、再生デバイス３０２によって署名されたＲＯＡＰ−ＲＯＲｅｑｕｅｓｔメッセージを生成する。
【００８２】
ステップＳ９１２で、再生デバイス３０２は、ＲＯＲｅｑｕｅｓｔと権利発行装置から受信されたＲＯＡＰトリガとの両方を含む要求メッセージを、ＲＯ獲得委託ＵＲＩに対して送信する。この要求メッセージの例を図１１に示す。この例は、この要求が委託ＵＲＩに対してＨＴＴＰ ＰＯＳＴされており、ＲＯＲｅｑｕｅｓｔ及びＲＯＡＰトリガがＨＴＴＰ要求内に多重化されているということを示す。
【００８３】
ステップＳ９１３で、制御デバイス３０１は、例えばディスプレイ６０８に表示される何らかの形式のユーザインタフェースを介して、所有者の同意を得ようと試みる。
【００８４】
ステップＳ９１４で、制御デバイス３０１は、ＲＯＲｅｑｕｅｓｔに対して裏書きを行って裏書き付き要求を生成する。図１２に示すように、この例では、裏書き付きＲＯＲｅｑｕｅｓｔは、別のＸＭＬエレメントである＜endorsement＞にカプセル化されることにより、このＲＯＲｅｑｕｅｓｔは裏書きされているということを権利発行装置３０４に指し示す。この例では、＜endorsement＞エレメントのために新しいＸＭＬ名前空間が定義されている。＜endorserInfo＞エレメントは、デバイスＩＤのような、裏書きを行ったデバイスの情報を搬送する。＜signature＞エレメントは、＜endorsement＞をルートとするＸＭＬ文書全体をカバーする、制御デバイス３０１の署名を格納する。＜endorserInfo＞内の各エレメントの構文は、ＯＭＡ ＤＲＭ ２．０［１］に従う。
【００８５】
ステップＳ９１５で、制御デバイス３０１は、ステップＳ９１２において再生デバイス３０２から受信したＲＯＡＰトリガの中のＲＯＡＰ ＵＲＬによって位置確認可能な権利発行装置３０４に対して、裏書き付きＲＯＲｅｑｕｅｓｔ（図１１に示すメッセージ）を送信する。
【００８６】
ステップＳ９１６で、権利発行装置３０４がＲＯＲｅｑｕｅｓｔの中に＜endorsement＞エレメントを発見した場合、権利発行装置３０４はこの要求を裏書きされているものとして解釈する。この場合、権利発行装置３０４は裏書きを行った者の情報（制御デバイス３０１の情報）と、再生デバイス３０２によって生成されたＲＯＲｅｑｕｅｓｔとをカプセル化解除する。再生デバイス３０２の署名を使用して、権利発行装置３０４は、再生デバイス３０２が認証されているか否かを判定する。この判定は、例えばＯＣＳＰサーバ３０５によって管理されているＣＲＬをチェックすることにより、実行可能である。
【００８７】
ステップＳ９１７で、権利発行装置３０４は、課金サーバ３０６がＲＯについて制御デバイス３０１の所有者に課金可能なように、発行されるＲＯの価格情報と共に制御デバイスのデバイスＩＤを課金サーバ３０６へ送信する。
【００８８】
ステップＳ９１８で、（再生デバイス３０２が認証されていると判定された場合は、）権利発行装置３０４は、再生デバイス３０２に対して権利が与えられたＲＯ（即ち、再生デバイス３０２の公開鍵を用いて保護されているＲＯ）を含むＲＯＲｅｓｐｏｎｓｅを生成する。ＲＯＲｅｓｐｏｎｓｅは最終的に、制御デバイス３０１へと返送される。
【００８９】
ステップＳ９１９で、制御デバイス３０１は、ステップＳ９１２における委託要求への応答として、ＲＯＲｅｓｐｏｎｓｅを再生デバイス３０２に対して転送する。
【００９０】
再生デバイス３０２はＲＯを獲得したので、ステップＳ９２０で、再生デバイス３０２はコンテンツサーバ３０３から保護されたコンテンツを（この例ではストリーミングを利用して）受信する準備ができている。再生デバイス３０２は、ストリーミングの受信を開始するために、ＲＴＳＰ：：Ｓｅｔｕｐコマンド及びＲＴＳＰ：：Ｐｌａｙコマンドを送信する。
【００９１】
ステップＳ９２１で、再生デバイス３０２は、コンテンツサーバ３０３からの保護されたストリーミングを、ＲＯを使用することにより復号して再生する。
【００９２】
上述の通り、既存のソリューション（サブライセンス技術）ではエンドデバイス間の認証が発生することになっているが、一方で、本発明はこの認証を必要としない。即ち、既存のソリューションでは、サブライセンスを与えるデバイスは、サブライセンスを受けるデバイスが認証されたデバイス（即ち、信頼されるデバイス）であることを確認するために、サブライセンスを受けるデバイスを認証することになっている。また、サブライセンスを与えるデバイスは、サブライセンスを受けるデバイスが信用できなくなっていないということを確認するために、ＣＲＬを参照してサブライセンスを受けるデバイスの証明書の無効状態をチェックする機能を必要とした。
【００９３】
一方、本発明は、制御デバイスが再生デバイスを認証することを必要としない。なぜなら、再生デバイスは、（裏書き付き）ＲＯＲｅｑｕｅｓｔ内の再生デバイスの電子証明を検証する権利発行装置によって認証されるからである。それゆえ、本発明は、制御デバイスが証明書の無効をチェックするという上述した機能を必要としない。
【００９４】
従って、通常は小さな帯域と比較的低い処理能力しか持たない移動体デバイスである制御デバイスにとっての処理負荷が低減される。
【００９５】
加えて、制御デバイスはＲＯＲｅｑｕｅｓｔを裏書き付き要求の中にカプセル化するだけなので、権利発行装置は、再生デバイスによって生成されたＲＯＲｅｑｕｅｓｔに含まれる全ての情報を取得することができる。
【００９６】
略語：
UPnP ユニバーサル・プラグアンドプレイ
AV オーディオビジュアル
SIM 加入者ＩＤモジュール
IMSI 国際移動加入者識別番号
OMA オープン・モバイル・アライアンス
DRM デジタル著作権管理
CP ＵＰｎＰコントロールポイント
SDP セッション記述プロトコル
DCF ＤＲＭコンテンツフォーマット
PDCF パケット化ＤＣＦ
OCSP オンライン証明書状態プロトコル
PKI 公開鍵基盤
【００９７】
参考文献：
[1] OMA DRM Specification, Approved Version 2.0 - 03 Mar 2006
[2] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC2560
[3] SCE Requirements, Draft Version 2.0 - 22 May 2006, OMA-RD-SCE-V1_0-20060522-D
[4] “Content and License Delivery to Shared Devices,” Patent Application Publication, Pub. No.: US 2006/0036554 A1
[5] UPnP Device Architecture 1.0, http://www.upnp.org/resources/documents/CleanUPnPDA101-20031202s.pdf
[6] UpnP AVTransport:1 Service Template Version 1.01, http://www.upnp.org/standardizeddcps/documents/AVTransport1.0.pdf
[7] OMA DRM Content Format, Approved Version 2.0 - 03 Mar 2006
[8] 3GPP TS 26.234 Transport end-to-end Packet-switched Streaming Service (PSS); Protocol and codecs (Release 6)
[9] UPnP MediaServer 1.0, http://www.upnp.org/standardizeddcps/documents/MediaServer1.0.pdf
[10] UPnP MediaRenderer 1.0, http://www.upnp.org/standardizeddcps/documents/MediaRenderer1.0_000.pdf
[11] Session Description Protocol (SDP), RFC2327
【特許請求の範囲】
【請求項１】
制御デバイス（３０１）であって、
マルチメディアデータを再生するように再生デバイス（３０２）を制御する制御手段（６０６）と、
許可サーバ（３０４）に含まれる許可データを獲得する要求を前記再生デバイス（３０２）から受信する受信手段（６１２）と、
を備え、
前記許可データは、前記マルチメディアデータの再生を可能にするものであり、
前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイス（３０２）の認証情報とを含み、
前記制御デバイス（３０１）は、
前記位置情報によって指し示される位置から前記許可データを獲得する獲得手段（６１４）であって、前記認証情報を前記許可サーバ（３０４）へ送信する獲得手段（６１４）と、
前記許可データを前記再生デバイス（３０２）へ送信する送信手段（６１６）と、
を備えることを特徴とする制御デバイス（３０１）。
【請求項２】
前記獲得手段（６１４）は、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を前記許可サーバ（３０４）へ送信することを特徴とする請求項１に記載の制御デバイス（３０１）。
【請求項３】
前記制御手段（６０６）は、前記再生デバイス（３０２）による前記要求の送信先の位置を指し示す位置情報を送信することを特徴とする請求項１又は２に記載の制御デバイス（３０１）。
【請求項４】
前記獲得手段（６１４）は、前記制御デバイス（３０１）の認証情報を前記許可サーバ（３０４）へ送信することを特徴とする請求項１乃至３のいずれか１項に記載の制御デバイス（３０１）。
【請求項５】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項４に記載の制御デバイス（３０１）。
【請求項６】
前記制御デバイス（３０１）及び前記再生デバイス（３０２）は、ユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項１乃至５のいずれか１項に記載の制御デバイス（３０１）。
【請求項７】
再生デバイス（３０２）であって、
マルチメディアデータを再生するコマンドを制御デバイス（３０１）から受信するコマンド受信手段（７０６）と、
前記マルチメディアデータの再生を可能にする許可データであって、許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得手段（７０６）と、
前記許可データを獲得する要求であって、前記位置情報と前記再生デバイス（３０２）の認証情報とを含む要求を、前記制御デバイス（３０１）へ送信する送信手段（７１２）と、
前記要求に対する応答として前記許可データを前記制御デバイス（３０１）から受信する許可受信手段（７１６）と、
前記許可データを使用して前記マルチメディアデータを再生する再生手段（７１８）と、
を備えることを特徴とする再生デバイス（３０２）。
【請求項８】
前記コマンド受信手段（７０６）は、前記送信手段（７１２）による前記要求の送信先の位置を指し示す位置情報を受信することを特徴とする請求項７に記載の再生デバイス（３０２）。
【請求項９】
前記マルチメディアデータは、前記再生デバイス（３０２）の記憶装置（７１０）に含まれることを特徴とする請求項７又は８に記載の再生デバイス（３０２）。
【請求項１０】
前記認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項７乃至９のいずれか１項に記載の再生デバイス（３０２）。
【請求項１１】
前記再生デバイス（３０２）及び前記制御デバイス（３０１）はユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項７乃至１０のいずれか１項に記載の再生デバイス（３０２）。
【請求項１２】
許可サーバ（３０４）であって、
マルチメディアデータの再生を可能にする許可データであって、前記許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、再生デバイス（３０２）へ送信する位置送信手段（８０６）と、
前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイス（３０２）の認証情報を含む要求を、制御デバイス（３０１）から受信する受信手段（８０８）と、
前記再生デバイス（３０２）が認証されているか否かを前記認証情報に基づいて判定する判定手段（８１０）と、
前記再生デバイス（３０２）が認証されていると前記判定手段（８１０）が判定した場合に、前記要求に応えて前記制御デバイス（３０１）へ前記許可データを送信する許可送信手段（８１２）と、
を備えることを特徴とする許可サーバ（３０４）。
【請求項１３】
前記判定手段（８１０）は、オンライン証明書状態プロトコルを介して前記認証情報が無効化されているか否かをチェックし、前記認証情報が無効化されている場合は前記再生デバイス（３０２）が認証されていないと判定することを特徴とする請求項１２に記載の許可サーバ（３０４）。
【請求項１４】
前記要求は、前記前記許可サーバ（３０４）に対する、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を含み、
前記許可サーバ（３０４）は、前記許可送信手段（８１２）によって送信された前記許可データについて、前記識別情報に基づいて前記所有者に課金する課金手段（８１６）を更に備える
ことを特徴とする請求項１２又は１３に記載の許可サーバ（３０４）。
【請求項１５】
前記要求は、前記制御デバイス（３０１）の認証情報を含むことを特徴とする請求項１２乃至１４のいずれか１項に記載の許可サーバ（３０４）。
【請求項１６】
前記判定手段（８１０）は、前記制御デバイス（３０１）が認証されているか否かを判定し、
前記許可送信手段（８１２）は、前記再生デバイス（３０２）及び前記制御デバイス（３０１）の両方が認証されていると前記判定手段（８１０）が判定した場合に、前記許可データを送信する
ことを特徴とする請求項１５に記載の許可サーバ（３０４）。
【請求項１７】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項１５又は１６に記載の許可サーバ（３０４）。
【請求項１８】
制御デバイス（３０１）の制御方法であって、
マルチメディアデータを再生するように再生デバイス（３０２）を制御する制御ステップ（Ｓ９０１〜Ｓ９０６）と、
許可サーバ（３０４）に含まれる許可データを獲得する要求を前記再生デバイス（３０２）から受信する受信ステップ（Ｓ９１２）と、
を備え、
前記許可データは、前記マルチメディアデータの再生を可能にするものであり、
前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイス（３０２）の認証情報とを含み、
前記制御方法は、前記位置情報によって指し示される位置から前記許可データを獲得する獲得ステップ（Ｓ９１５，Ｓ９１８）を備え、当該獲得ステップ（Ｓ９１５，Ｓ９１８）においては、前記認証情報が前記許可サーバ（３０４）へ送信され、
前記制御方法は、前記許可データを前記再生デバイス（３０２）へ送信する送信ステップ（Ｓ９１９）
を備えることを特徴とする制御方法。
【請求項１９】
前記獲得ステップ（Ｓ９１５）において、前記制御デバイス（３０１）の所有者に関連付けられた識別情報が前記許可サーバ（３０４）へ送信されることを特徴とする請求項１８に記載の制御方法。
【請求項２０】
前記制御ステップ（Ｓ９０１〜Ｓ９０６）において、前記再生デバイス（３０２）による前記要求の送信先の位置を指し示す位置情報が前記再生デバイス（３０２）へ送信されることを特徴とする請求項１８又は１９に記載の制御方法。
【請求項２１】
前記獲得ステップ（Ｓ９１５，Ｓ９１８）において、前記制御デバイス（３０１）の認証情報が前記許可サーバ（３０４）へ送信されることを特徴とする請求項１８乃至２０のいずれか１項に記載の制御方法。
【請求項２２】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項２１に記載の制御方法。
【請求項２３】
前記制御デバイス（３０１）及び前記再生デバイス（３０２）は、ユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項１８乃至２２のいずれか１項に記載の制御方法。
【請求項２４】
再生デバイス（３０２）の制御方法であって、
マルチメディアデータを再生するコマンドを制御デバイス（３０１）から受信するコマンド受信ステップ（Ｓ９０５，Ｓ９０６）と、
前記マルチメディアデータの再生を可能にする許可データであって、許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得ステップ（Ｓ９０７〜Ｓ９１０）と、
前記許可データを獲得する要求であって、前記位置情報と前記再生デバイス（３０２）の認証情報とを含む要求を、前記制御デバイス（３０１）へ送信する送信ステップ（Ｓ９１２）と、
前記要求に対する応答として前記許可データを前記制御デバイス（３０１）から受信する許可受信ステップ（Ｓ９１９）と、
前記許可データを使用して前記マルチメディアデータを再生する再生ステップ（Ｓ９２０，Ｓ９２１）と、
を備えることを特徴とする制御方法。
【請求項２５】
前記コマンド受信ステップ（Ｓ９０５，Ｓ９０６）において、前記送信ステップ（Ｓ９１２）における前記要求の送信先の位置を指し示す位置情報が受信されることを特徴とする請求項２４に記載の制御方法。
【請求項２６】
前記マルチメディアデータは、前記再生デバイス（３０２）の記憶装置に含まれることを特徴とする請求項２４又は２５に記載の制御方法。
【請求項２７】
前記認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項２４乃至２６のいずれか１項に記載の制御方法。
【請求項２８】
前記再生デバイス（３０２）及び前記制御デバイス（３０１）はユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項２４乃至２７のいずれか１項に記載の制御方法。
【請求項２９】
許可サーバ（３０４）の制御方法であって、
マルチメディアデータの再生を可能にする許可データであって、前記許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、再生デバイス（３０２）へ送信する位置送信ステップ（Ｓ９１０）と、
前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイス（３０２）の認証情報を含む要求を、制御デバイス（３０１）から受信する受信ステップ（Ｓ９１５）と、
前記再生デバイス（３０２）が認証されているか否かを前記認証情報に基づいて判定する判定ステップ（Ｓ９１６）と、
前記再生デバイス（３０２）が認証されていると前記判定ステップ（Ｓ９１６）が判定した場合に、前記要求に応えて前記制御デバイス（３０１）へ前記許可データを送信する許可送信ステップ（Ｓ９１６）と、
を備えることを特徴とする制御方法。
【請求項３０】
前記判定ステップ（Ｓ９１６）において、オンライン証明書状態プロトコルを介して前記認証情報が無効化されているか否かがチェックされ、前記認証情報が無効化されている場合は前記再生デバイス（３０２）が認証されていないと判定されることを特徴とする請求項２９に記載の制御方法。
【請求項３１】
前記要求は、前記前記許可サーバ（３０４）に対する、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を含み、
前記制御方法は、前記許可送信ステップ（Ｓ９１７）において送信された前記許可データについて、前記識別情報に基づいて前記所有者に課金する課金ステップ（Ｓ９１７）を更に備える
ことを特徴とする請求項２９又は３０に記載の制御方法。
【請求項３２】
前記要求は、前記制御デバイス（３０１）の認証情報を含むことを特徴とする請求項２９乃至３１のいずれか１項に記載の制御方法。
【請求項３３】
前記判定ステップ（Ｓ９１６）において、前記制御デバイス（３０１）が認証されているか否かが判定され、
前記許可送信ステップ（Ｓ９１８）では、前記再生デバイス（３０２）及び前記制御デバイス（３０１）の両方が認証されていると前記判定ステップ（Ｓ９１６）で判定された場合に、前記許可データが送信される
ことを特徴とする請求項３２に記載の制御方法。
【請求項３４】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項３２又は３３に記載の制御方法。
【請求項１】
制御デバイス（３０１）であって、
マルチメディアデータを再生するように再生デバイス（３０２）を制御する制御手段（６０６）と、
許可サーバ（３０４）に含まれる許可データを獲得する要求を前記再生デバイス（３０２）から受信する受信手段（６１２）と、
を備え、
前記許可データは、前記マルチメディアデータの再生を可能にするものであり、
前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイス（３０２）の認証情報とを含み、
前記制御デバイス（３０１）は、
前記位置情報によって指し示される位置から前記許可データを獲得する獲得手段（６１４）であって、前記認証情報を前記許可サーバ（３０４）へ送信する獲得手段（６１４）と、
前記許可データを前記再生デバイス（３０２）へ送信する送信手段（６１６）と、
を備えることを特徴とする制御デバイス（３０１）。
【請求項２】
前記獲得手段（６１４）は、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を前記許可サーバ（３０４）へ送信することを特徴とする請求項１に記載の制御デバイス（３０１）。
【請求項３】
前記制御手段（６０６）は、前記再生デバイス（３０２）による前記要求の送信先の位置を指し示す位置情報を送信することを特徴とする請求項１又は２に記載の制御デバイス（３０１）。
【請求項４】
前記獲得手段（６１４）は、前記制御デバイス（３０１）の認証情報を前記許可サーバ（３０４）へ送信することを特徴とする請求項１乃至３のいずれか１項に記載の制御デバイス（３０１）。
【請求項５】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項４に記載の制御デバイス（３０１）。
【請求項６】
前記制御デバイス（３０１）及び前記再生デバイス（３０２）は、ユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項１乃至５のいずれか１項に記載の制御デバイス（３０１）。
【請求項７】
再生デバイス（３０２）であって、
マルチメディアデータを再生するコマンドを制御デバイス（３０１）から受信するコマンド受信手段（７０６）と、
前記マルチメディアデータの再生を可能にする許可データであって、許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得手段（７０６）と、
前記許可データを獲得する要求であって、前記位置情報と前記再生デバイス（３０２）の認証情報とを含む要求を、前記制御デバイス（３０１）へ送信する送信手段（７１２）と、
前記要求に対する応答として前記許可データを前記制御デバイス（３０１）から受信する許可受信手段（７１６）と、
前記許可データを使用して前記マルチメディアデータを再生する再生手段（７１８）と、
を備えることを特徴とする再生デバイス（３０２）。
【請求項８】
前記コマンド受信手段（７０６）は、前記送信手段（７１２）による前記要求の送信先の位置を指し示す位置情報を受信することを特徴とする請求項７に記載の再生デバイス（３０２）。
【請求項９】
前記マルチメディアデータは、前記再生デバイス（３０２）の記憶装置（７１０）に含まれることを特徴とする請求項７又は８に記載の再生デバイス（３０２）。
【請求項１０】
前記認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項７乃至９のいずれか１項に記載の再生デバイス（３０２）。
【請求項１１】
前記再生デバイス（３０２）及び前記制御デバイス（３０１）はユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項７乃至１０のいずれか１項に記載の再生デバイス（３０２）。
【請求項１２】
許可サーバ（３０４）であって、
マルチメディアデータの再生を可能にする許可データであって、前記許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、再生デバイス（３０２）へ送信する位置送信手段（８０６）と、
前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイス（３０２）の認証情報を含む要求を、制御デバイス（３０１）から受信する受信手段（８０８）と、
前記再生デバイス（３０２）が認証されているか否かを前記認証情報に基づいて判定する判定手段（８１０）と、
前記再生デバイス（３０２）が認証されていると前記判定手段（８１０）が判定した場合に、前記要求に応えて前記制御デバイス（３０１）へ前記許可データを送信する許可送信手段（８１２）と、
を備えることを特徴とする許可サーバ（３０４）。
【請求項１３】
前記判定手段（８１０）は、オンライン証明書状態プロトコルを介して前記認証情報が無効化されているか否かをチェックし、前記認証情報が無効化されている場合は前記再生デバイス（３０２）が認証されていないと判定することを特徴とする請求項１２に記載の許可サーバ（３０４）。
【請求項１４】
前記要求は、前記前記許可サーバ（３０４）に対する、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を含み、
前記許可サーバ（３０４）は、前記許可送信手段（８１２）によって送信された前記許可データについて、前記識別情報に基づいて前記所有者に課金する課金手段（８１６）を更に備える
ことを特徴とする請求項１２又は１３に記載の許可サーバ（３０４）。
【請求項１５】
前記要求は、前記制御デバイス（３０１）の認証情報を含むことを特徴とする請求項１２乃至１４のいずれか１項に記載の許可サーバ（３０４）。
【請求項１６】
前記判定手段（８１０）は、前記制御デバイス（３０１）が認証されているか否かを判定し、
前記許可送信手段（８１２）は、前記再生デバイス（３０２）及び前記制御デバイス（３０１）の両方が認証されていると前記判定手段（８１０）が判定した場合に、前記許可データを送信する
ことを特徴とする請求項１５に記載の許可サーバ（３０４）。
【請求項１７】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項１５又は１６に記載の許可サーバ（３０４）。
【請求項１８】
制御デバイス（３０１）の制御方法であって、
マルチメディアデータを再生するように再生デバイス（３０２）を制御する制御ステップ（Ｓ９０１〜Ｓ９０６）と、
許可サーバ（３０４）に含まれる許可データを獲得する要求を前記再生デバイス（３０２）から受信する受信ステップ（Ｓ９１２）と、
を備え、
前記許可データは、前記マルチメディアデータの再生を可能にするものであり、
前記要求は、前記許可データの位置を指し示す位置情報と、前記再生デバイス（３０２）の認証情報とを含み、
前記制御方法は、前記位置情報によって指し示される位置から前記許可データを獲得する獲得ステップ（Ｓ９１５，Ｓ９１８）を備え、当該獲得ステップ（Ｓ９１５，Ｓ９１８）においては、前記認証情報が前記許可サーバ（３０４）へ送信され、
前記制御方法は、前記許可データを前記再生デバイス（３０２）へ送信する送信ステップ（Ｓ９１９）
を備えることを特徴とする制御方法。
【請求項１９】
前記獲得ステップ（Ｓ９１５）において、前記制御デバイス（３０１）の所有者に関連付けられた識別情報が前記許可サーバ（３０４）へ送信されることを特徴とする請求項１８に記載の制御方法。
【請求項２０】
前記制御ステップ（Ｓ９０１〜Ｓ９０６）において、前記再生デバイス（３０２）による前記要求の送信先の位置を指し示す位置情報が前記再生デバイス（３０２）へ送信されることを特徴とする請求項１８又は１９に記載の制御方法。
【請求項２１】
前記獲得ステップ（Ｓ９１５，Ｓ９１８）において、前記制御デバイス（３０１）の認証情報が前記許可サーバ（３０４）へ送信されることを特徴とする請求項１８乃至２０のいずれか１項に記載の制御方法。
【請求項２２】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項２１に記載の制御方法。
【請求項２３】
前記制御デバイス（３０１）及び前記再生デバイス（３０２）は、ユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項１８乃至２２のいずれか１項に記載の制御方法。
【請求項２４】
再生デバイス（３０２）の制御方法であって、
マルチメディアデータを再生するコマンドを制御デバイス（３０１）から受信するコマンド受信ステップ（Ｓ９０５，Ｓ９０６）と、
前記マルチメディアデータの再生を可能にする許可データであって、許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、前記マルチメディアデータに基づいて取得する取得ステップ（Ｓ９０７〜Ｓ９１０）と、
前記許可データを獲得する要求であって、前記位置情報と前記再生デバイス（３０２）の認証情報とを含む要求を、前記制御デバイス（３０１）へ送信する送信ステップ（Ｓ９１２）と、
前記要求に対する応答として前記許可データを前記制御デバイス（３０１）から受信する許可受信ステップ（Ｓ９１９）と、
前記許可データを使用して前記マルチメディアデータを再生する再生ステップ（Ｓ９２０，Ｓ９２１）と、
を備えることを特徴とする制御方法。
【請求項２５】
前記コマンド受信ステップ（Ｓ９０５，Ｓ９０６）において、前記送信ステップ（Ｓ９１２）における前記要求の送信先の位置を指し示す位置情報が受信されることを特徴とする請求項２４に記載の制御方法。
【請求項２６】
前記マルチメディアデータは、前記再生デバイス（３０２）の記憶装置に含まれることを特徴とする請求項２４又は２５に記載の制御方法。
【請求項２７】
前記認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項２４乃至２６のいずれか１項に記載の制御方法。
【請求項２８】
前記再生デバイス（３０２）及び前記制御デバイス（３０１）はユニバーサル・プラグアンドプレイを使用して相互に接続されることを特徴とする請求項２４乃至２７のいずれか１項に記載の制御方法。
【請求項２９】
許可サーバ（３０４）の制御方法であって、
マルチメディアデータの再生を可能にする許可データであって、前記許可サーバ（３０４）に含まれる許可データの位置を指し示す位置情報を、再生デバイス（３０２）へ送信する位置送信ステップ（Ｓ９１０）と、
前記位置情報によって指し示される位置から前記許可データを獲得する要求であって、前記再生デバイス（３０２）の認証情報を含む要求を、制御デバイス（３０１）から受信する受信ステップ（Ｓ９１５）と、
前記再生デバイス（３０２）が認証されているか否かを前記認証情報に基づいて判定する判定ステップ（Ｓ９１６）と、
前記再生デバイス（３０２）が認証されていると前記判定ステップ（Ｓ９１６）が判定した場合に、前記要求に応えて前記制御デバイス（３０１）へ前記許可データを送信する許可送信ステップ（Ｓ９１６）と、
を備えることを特徴とする制御方法。
【請求項３０】
前記判定ステップ（Ｓ９１６）において、オンライン証明書状態プロトコルを介して前記認証情報が無効化されているか否かがチェックされ、前記認証情報が無効化されている場合は前記再生デバイス（３０２）が認証されていないと判定されることを特徴とする請求項２９に記載の制御方法。
【請求項３１】
前記要求は、前記前記許可サーバ（３０４）に対する、前記制御デバイス（３０１）の所有者に関連付けられた識別情報を含み、
前記制御方法は、前記許可送信ステップ（Ｓ９１７）において送信された前記許可データについて、前記識別情報に基づいて前記所有者に課金する課金ステップ（Ｓ９１７）を更に備える
ことを特徴とする請求項２９又は３０に記載の制御方法。
【請求項３２】
前記要求は、前記制御デバイス（３０１）の認証情報を含むことを特徴とする請求項２９乃至３１のいずれか１項に記載の制御方法。
【請求項３３】
前記判定ステップ（Ｓ９１６）において、前記制御デバイス（３０１）が認証されているか否かが判定され、
前記許可送信ステップ（Ｓ９１８）では、前記再生デバイス（３０２）及び前記制御デバイス（３０１）の両方が認証されていると前記判定ステップ（Ｓ９１６）で判定された場合に、前記許可データが送信される
ことを特徴とする請求項３２に記載の制御方法。
【請求項３４】
前記再生デバイス（３０２）の認証情報及び前記制御デバイス（３０１）の認証情報は、公開鍵基盤に基づく署名であることを特徴とする請求項３２又は３３に記載の制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１０−５１５９５４（Ｐ２０１０−５１５９５４Ａ）
【公表日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願番号】特願２００９−５２７６４０（Ｐ２００９−５２７６４０）
【出願日】平成１９年１月１６日（２００７．１．１６）
【国際出願番号】ＰＣＴ／ＪＰ２００７／０５０８７１
【国際公開番号】ＷＯ２００８／０８７７４３
【国際公開日】平成２０年７月２４日（２００８．７．２４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願日】平成１９年１月１６日（２００７．１．１６）
【国際出願番号】ＰＣＴ／ＪＰ２００７／０５０８７１
【国際公開番号】ＷＯ２００８／０８７７４３
【国際公開日】平成２０年７月２４日（２００８．７．２４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]