(57)【特許請求の範囲】
【請求項１】
コンテンツの本編部分からなる少なくとも一つのメインリソースと、前記本編部分に付随する関連情報からなる複数のサブリソースとから構成されるコンテンツデータを、前記コンテンツデータに対応するライセンスデータを用いて再生するためのコンテンツ再生装置であって、
前記ライセンスデータを管理するライセンス管理手段と、
前記メインリソースおよび前記サブリソースを再生する複数のリソース再生部と、
前記メインリソースの再生を開始する場合のみ、再生対象のコンテンツデータに対応するライセンスデータを前記ライセンス管理手段にロックさせるライセンスロック手段と、
前記サブリソースの再生を開始する場合には、前記サブリソースが利用可能であるかの確認を前記ライセンスデータに含まれるサブリソース利用条件情報内の参照情報を参照し、前記メインリソースの利用条件情報を参照すべきであると指定されている場合、前記メインリソースの利用条件情報と利用状況情報とを比較することによってライセンスの利用可否を判断し、前記メインリソースの利用条件情報を参照すべきであると指定されていない場合、前記メインリソースの利用条件情報や利用状況情報には依存せずにライセンスの利用が可能であるという判断を行うことにより、前記ライセンス管理手段に前記サブリソースの再生可否を確認させるライセンス確認手段と、
前記リソース再生部が前記メインリソースの再生を終了する場合のみ、前記ライセンス管理手段に、前記メインリソースの再生が終了した旨を通知して、前記再生対象のコンテンツデータに対応するライセンスデータのロックを解除させ、ライセンスデータ内の利用状況情報を更新させるライセンスロック解除手段とを備え、
前記複数のリソース再生部は、
前記メインリソースを再生するためのメインリソース再生部と、
前記サブリソースを再生するためのサブリソース再生部とを含む、コンテンツ再生装置。
【請求項２】
コンテンツの本編部分からなる少なくとも一つのメインリソースと、前記本編部分に付随する関連情報からなる複数のサブリソースとから構成されるコンテンツデータを、前記コンテンツデータに対応するライセンスデータを用いて再生するためのコンテンツ再生装置が実施する方法であって、
前記コンテンツ再生装置に格納された前記ライセンスデータを管理するライセンス管理ステップと、
前記メインリソースを再生するメインリソース再生ステップと、
前記サブリソースを再生するサブリソース再生ステップと、
前記メインリソースの再生を開始する場合のみ、再生対象のコンテンツデータに対応するライセンスデータを前記ライセンス管理ステップにロックさせるライセンスロックステップと、
前記サブリソースの再生を開始する場合には、前記サブリソースが利用可能であるかの確認を前記ライセンスデータに含まれるサブリソース利用条件情報内の参照情報を参照し、前記メインリソースの利用条件情報を参照すべきであると指定されている場合、前記メインリソースの利用条件情報と利用状況情報とを比較することによってライセンスの利用可否を判断し、前記メインリソースの利用条件情報を参照すべきであると指定されていない場合、前記メインリソースの利用条件情報や利用状況情報には依存せずにライセンスの利用が可能であるという判断を行うことにより、前記ライセンス管理ステップに前記サブリースの再生可否を確認させるライセンス確認ステップと、
前記メインリソース再生ステップが前記メインリソースの再生を終了する場合のみ、前記ライセンス管理ステップに、前記メインリソースの再生が終了した旨を通知して、前記再生対象のコンテンツデータに対応するライセンスデータのロックを解除させ、ライセンスデータ内の利用状況情報を更新させるライセンスロック解除ステップとを備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、著作権保護されているコンテンツの再生装置、再生方法、およびそれらに用いられるデータが格納された記録媒体に関し、より特定的には、著作権保護されているマルチメディア型のコンテンツの再生装置、再生方法、およびそれらに用いられるデータが格納された記録媒体に関する。
【背景技術】
【０００２】
デジタル著作権管理（ＤＲＭ：Ｄｉｇｉｔａｌ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ）システムを用いた従来のコンテンツ配信システムでは、音楽や映画などのストリーミング型のコンテンツが、配信の主たる対象となっていた。ストリーミング型のコンテンツに対しては、既に著作権の管理をするためのモデル（以下、権利管理モデルとう）が確立されつつある。以下に、従来の権利管理モデルにおけるコンテンツの再生手順について説明する。
【０００３】
まず、再生開始時における手順について説明する。まず、コンテンツの再生装置は、コンテンツに付随するライセンスを参照して、コンテンツの利用が可能であるか否かを判断する。ここで、ライセンスとは、コンテンツを利用するのに必要な情報およびコンテンツの利用条件を示す情報のことをいう。利用可能であると判断した場合、再生装置は、ライセンスをロックする。次に、再生装置は、ライセンスに含まれているコンテンツの復号鍵を抽出する。次に、再生装置は、抽出した復号鍵を用いて、コンテンツを復号し、再生する。
【０００４】
次に、再生終了時における手順について説明する。まず、再生装置は、再生終了時における利用状況に応じて、ライセンスの内容を更新する。たとえば、再生装置は、残りの利用時間を減らす等して、ライセンスの内容を更新する。次に、再生装置は、ライセンスのロックを解除する。
【０００５】
このように、従来の再生装置は、再生開始時にライセンスをロックし、再生終了時に利用状況に応じてライセンスを更新してロックを解除する。そのため、コンテンツの利用毎にライセンスが更新されることとなり、コンテンツの不正な利用を防止することができる。
【特許文献１】特開昭６０−７７２１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
近年、ストリーミング型のコンテンツに加えて、ＤＶＤで採用されているようなマルチメディア型のコンテンツも、ネットワークを介した配信の対象となってきている。しかし、従来の権利管理モデルにおける処理をそのままマルチメディア型のコンテンツに適用すると、様々な問題が発生する。
【０００７】
ここで、マルチメディア型のコンテンツとは、動画等の従来からのストリーミング型のコンテンツと、構造化テキストおよび静止画像などを含むメニュー型のコンテンツとが融合されたコンテンツのことをいう。マルチメディア型のコンテンツでは、メニュー画面から本編動画へ遷移することができたり、本編動画と関連情報とを同時に画面表示することができる。
【０００８】
マルチメディア型のコンテンツにおいて、メニュー画面等のメニュー型コンテンツは、ＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などの構造化テキストで実現されている。構造化テキストで実現されるメニュー型コンテンツでは、メニュー画面と複数の静止画とのリンクが定義されている。これにより、メニュー画面では、同時に、複数の静止画などの関連情報が表示される。
【０００９】
このようなマルチメディア型のコンテンツに、従来の権利管理モデルを適用した場合、再生開始時、本編動画や、メニュー画面、複数の静止画等、全てについてライセンスがロックされてしまう。したがって、本編画像と関連情報画面との同時表示が不可能であったり、メニュー画面において、二枚目以降の静止画が表示できなかったりするという問題が発生する。
【００１０】
また、再生終了時、本編動画や、メニュー画面、複数の静止画等、全てについてライセンスが更新されてしまうこととなるので、権利管理が不要な情報についてまで、利用条件が更新され、利用が制限されることとなってしまう。
【００１１】
これは、ストリーム型のコンテンツで用いられている権利管理用のデータ構造が、マルチメディア型のコンテンツには不適切であることに起因する。
【００１２】
それゆえ、本発明の目的は、マルチメディア型のコンテンツの権利管理を行うために適したデータ構造を提供し、さらに当該データ構造を有するデータを格納した記録媒体、ならびにそれを再生するための再生装置および再生方法を提供することである。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明は、以下のような特徴を有する。本発明は、複数のリソースから構成されるコンテンツデータの利用をコンピュータに許諾するためのライセンスデータが記録されたコンピュータ読み取り可能な記録媒体であって、リソース毎にコンピュータでの利用条件が設定されているリソース単位利用条件設定構造を有するライセンスデータが記録されている。
【００１４】
好ましくは、利用条件に対応するリソースを、当該利用条件に従ってコンピュータに利用させるライセンスデータが記録されているとよい。
【００１５】
好ましくは、少なくとも一つのリソースの利用状況をコンピュータに登録させるための更新可能な利用状況設定構造をさらに有するライセンスデータが記録されているとよい。
【００１６】
好ましくは、複数のリソースは、利用状況がコンピュータによって管理されるべき少なくとも一つのメインリソースと、利用状況がコンピュータによって管理されなくてもよい複数のサブリソースとからなっており、利用状況設定構造は、メインリソースの利用状況をコンピュータに設定させるためのデータ構造であるとよい。
【００１７】
好ましくは、複数のリソースは、コンピュータによる利用開始時に、ライセンスのロックが必要な少なくとも一つのメインリソースと、ライセンスのロックが不要な複数のサブリソースとからなっており、リソース単位利用条件設定構造は、メインリソースに関する利用条件であるか、それともサブリソースに関する利用条件であるかを示す種別情報を登録しており、種別情報は、ライセンスのロックが必要か否かをコンピュータが判断するために用いられるとよい。
【００１８】
また、本発明は、複数のリソースを含むコンテンツデータを、コンテンツデータに対応するライセンスデータを用いて再生するためのコンテンツ再生方法であって、複数のリソースは、コンテンツの本編部分からなる少なくとも一つのメインリソースと、本編部分に付随する関連情報からなる複数のサブリソースとからなっており、ライセンスデータを管理するライセンス管理装置に対して、メインリソースの再生を開始する場合のみ、再生対象のコンテンツデータに対応するライセンスデータをロックさせることを特徴とする。
【００１９】
好ましくは、メインリソースの再生を終了する場合のみ、ライセンス管理装置に対して、再生対象のコンテンツデータに対応するライセンスデータのロックを解除させ、ライセンスデータ内の利用状況情報を更新させるとよい。
【００２０】
また、本発明は、複数のリソースを含むコンテンツデータを、コンテンツデータに対応するライセンスデータを用いて再生するためのコンテンツ再生装置であって、複数のリソースは、コンテンツの本編部分からなる少なくとも一つのメインリソースと、本編部分に付随する関連情報からなる複数のサブリソースとからなっており、ライセンスデータを管理するライセンス管理手段と、メインリソースの再生を開始する場合のみ、再生対象のコンテンツデータに対応するライセンスデータをライセンス管理手段にロックさせるライセンスロック手段とを備える。
【００２１】
好ましくは、メインリソースの再生を終了する場合のみ、ライセンス管理手段に、メインリソースの再生が終了した旨を通知して、再生対象のコンテンツデータに対応するライセンスデータのロックを解除させ、ライセンスデータ内の利用状況情報を更新させるライセンスロック解除手段をさらに備えるとよい。
【００２２】
また、本発明は、複数のリソースを含むコンテンツデータを、コンテンツデータに対応するライセンスデータを用いて再生するためのコンテンツ再生装置であって、ライセンスデータを管理するライセンス管理部と、各リソースを再生するための複数のリソース再生部とを備える。
【００２３】
好ましくは、複数のリソースは、コンテンツの本編部分からなる少なくとも一つのメインリソースと、本編部分に付随する関連情報からなる複数のサブリソースとからなっており、複数のサブリソースは、暗号化されており、複数のリソース再生部は、メインリソースを再生するためのメインリソース再生部と、サブリソースを再生するためのサブリソース再生部とを含み、サブリソース再生部は、複数のサブリソースを一度にまとめて復号化するためのデクリプト部と、デクリプト部によって復号化されたサブリソースを一時格納するキャッシュ部と、キャッシュ部に格納された復号化後のサブリソースを用いて、サブリソースを再生するデコード部とを有するとよい。
【００２４】
好ましくは、少なくともデクリプト部は、耐タンパ化されているとよい。
【００２５】
好ましくは、複数のサブリソースは、さらに、まとめて圧縮化されており、デクリプト部は、複数のサブリソースを復号化すると共に、圧縮を解凍して、解凍および復号化後のサブリソースをキャッシュ部に一時格納するとよい。
【発明の効果】
【００２６】
本発明によれば、リソース毎に利用条件が設定されていることとなるので、複数のリソースからなるマルチメディア型のコンテンツにおいて、リソース単位での利用条件の設定が可能となる。したがって、マルチメディア型のコンテンツの権利管理を行うために適したデータ構造を有するデータを格納した記録媒体、ならびにそれを再生するための再生装置および再生方法が提供されることとなる。
【００２７】
また、本発明によれば、全てのリソースに対して利用状況が登録されていくのではなく、一部のリソースに対してのみ利用状況が登録されていくこととなるので、権利管理が不要なリソースについては、利用状況を管理しなくてもよくなる。特に、コンテンツの本編部分からなるメインリソースについてのみ、利用状況を登録して権利管理することができるようになる。
【００２８】
また、本発明によれば、メインリソースを再生するときのみライセンスがロックされることとなるので、サブリソースとメインリソースとを一緒に再生することが可能となる。
【００２９】
また、本発明によれば、メインリソースの再生が終了したときのみライセンスのロックが解除されることとなり、メインリソースの再生結果のみをライセンスデータの更新に反映させることが可能となる。
【００３０】
または、本発明によれば、複数のサブリソースが復号化されてキャッシュされ、キャッシュされているサブリソースを用いて、サブリソースを再生することとなるので、コンテンツ再生のための処理が軽減する。
【００３１】
また、デクリプト部を耐タンパ化することとによって、コンテンツ鍵の外部流出を防止することができる。
【発明を実施するための最良の形態】
【００３２】
図１は、本発明の一実施形態に係る権利管理システムの全体構成を示す図である。図１において、権利管理システムは、アプリケーション１と、レンダラ２と、ＤＲＭクライアント３とを備える。図１に示す権利管理システムは、一台のコンピュータ装置によって実現されてもよいし、複数台のコンピュータ装置によって実現されてもよい。
【００３３】
本実施形態において、コンテンツは、暗号化されている。暗号化されているコンテンツを再生するためには、ライセンスが必要である。ライセンスには、暗号化されているコンテンツを解読するためのコンテンツ鍵、およびコンテンツの利用が許可されている条件が含まれている。ライセンスに含まれているコンテンツ鍵を用いてコンテンツを解読することによって、コンテンツが再生可能となる。
【００３４】
本実施形態で用いるマルチメディア型のコンテンツには、少なくとも一つのメインリソースと、複数のサブリソースとが含まれている。メインリソースは、たとえば、本編部分の動画等が収録されているストリーム型のコンテンツである。サブリソースは、たとえば、ＨＴＭＬ等の構造化テキストで定義されているメニュー画面や、メニュー画面にリンクしている複数の静止画画像、関連情報として用いられる複数の静止画画像やテキスト、動画像等のコンテンツである。すなわち、サブリソースは、本編部分に付随する関連情報からなる。なお、本実施形態では、理解を容易にするために、メインリソースを本編画像とし、サブリソースを本編部分に付随する関連情報であるとして説明するが、マルチメディア型のコンテンツが、メインリソースとサブリソースとに分かれているのであれば、これに限られるものではない。
【００３５】
以下の説明において、単に、コンテンツといった場合、メインリソースによるコンテンツおよびサブリソースによるコンテンツの両方を含むものとする。コンテンツは、ハードディスク等の記録装置（図示せず）に格納されている。以下、コンテンツが格納されている部分をコンテンツ格納部という。コンテンツ格納部の図示は省略する。コンテンツ格納部は、アプリケーション１、レンダラ２、およびＤＲＭクライアント３を実現するコンピュータシステム内に存在する。なお、メインリソースとサブリソースとがカルーセル方式で多重化されてコンテンツが伝送されている場合、コンテンツは、コンテンツ格納部に格納されなくてもよい。
【００３６】
アプリケーション１は、コンテンツ格納部に格納されているコンテンツをレンダラ２に再生させることによって、所望の処理を実行する。アプリケーション１は、当該所望の処理を実現するためのプログラム等を実行しているコンピュータ装置によって実現される。
【００３７】
アプリケーション１は、コンテンツ格納部に格納されているコンテンツを再生したい場合、レンダラ２に対して、コンテンツの再生の開始を要求するメッセージ（以下、アプリ再生要求メッセージという：後述の図３参照）を送信する。また、アプリケーション１は、一時停止、早送り、巻き戻し等、コンテンツの再生を制御した場合、レンダラ２に対して、コンテンツの再生の制御を要求するメッセージ（以下、再生制御メッセージという）を送信する。さらに、アプリケーション１は、コンテンツの再生を終了したい場合、レンダラ２に対して、コンテンツの再生の終了を要求するメッセージ（以下、アプリ終了要求メッセージという：後述の図４参照）を送信する。
【００３８】
レンダラ２は、アプリケーション１からの要求に応じて、コンテンツを再生するための装置である。レンダラ２は、コンテンツを再生するためのプログラム等を実行しているコンピュータ装置によって実現される。レンダラ２で用いられるコンピュータ装置は、アプリケーション１が用いるコンピュータ装置と同一であってもよいし、異なっていてもよい。
【００３９】
レンダラ２は、アプリケーション１からのアプリ再生要求メッセージを受信した場合、ＤＲＭクライアント３に対して、コンテンツを再生するために必要なコンテンツ鍵の送信を要求するためのメッセージ（以下、レンダラ再生要求メッセージという：後述の図６参照）を送信する。レンダラ２は、レンダラ再生要求メッセージに応じてＤＲＭクライアント３から送られてくるコンテンツ鍵を受信する。レンダラ２は、当該コンテンツ鍵を用いて、コンテンツを解読して再生する。コンテンツの再生を開始したら、レンダラ２は、再生の結果を示すメッセージ（以下、レンダラ再生応答メッセージという）をアプリケーション１に送信する。
【００４０】
レンダラ２は、アプリケーション１から制御要求メッセージが送られてきた場合、コンテンツの再生を制御し、制御結果を示すメッセージ（以下、制御応答メッセージという）をアプリケーション１に送信する。
【００４１】
レンダラ２は、アプリケーション１からアプリ終了要求メッセージが送られてきた場合、コンテンツの再生を終了し、ライセンスに関する情報を更新するように要求するためのメッセージ（以下、レンダラ終了要求メッセージという：後述の図７参照）をＤＲＭクライアントに送信し、終了処理の結果を示すメッセージ（レンダラ終了応答メッセージ）をアプリケーション１に送信する。
【００４２】
ＤＲＭクライアント３は、ライセンスを格納してライセンスを管理するための装置である。ＤＲＭクライアント３は、コンテンツの再生を許可するか否かを判断し、ライセンスの更新を行う。ＤＲＭクライアント３は、コンテンツの再生を許可するか否かを判断し、ライセンスの更新を行うためのプログラム等を実行しているコンピュータ装置によって実現される。ＤＲＭクライアント３で用いられるコンピュータ装置は、アプリケーション１および／またはレンダラ２が用いるコンピュータ装置と同一であってもよいし、異なっていてもよい。
【００４３】
ＤＲＭクライアント３は、レンダラ２からレンダラ再生要求メッセージが送られてきた場合、再生要求がなされている対象がメインリソースであるかサブリソースであるかを判断して、メインリソースであればライセンスをロックし、サブリソースであればライセンスをロックしない。ライセンスがロックされている場合、レンダラ２やその他のレンダラは、ロックされているライセンスを用いて、コンテンツを再生することができない。また、ライセンスがロックされている場合、コンピュータ装置は、ロックされているライセンスを他の端末や記録媒体に移動することができない。ＤＲＭクライアント３は、ライセンスと共に、当該ライセンスがロックされているか否かのフラグを保持する。フラグは、「０」または「１」の値をとる。「０」は、ロックされていない状態を示す。「１」は、ロックされている状態を示す。最初、フラグは、「０」にセットされている。ＤＲＭクライアント３は、ライセンスをロックする際には、フラグが「０」であることを確認した上で、フラグを「１」にセットする。なお、フラグが既に「１」にセットされている場合、ライセンスはロックされているため、このライセンスを用いてのコンテンツ再生や、ライセンス移動は許されない。ライセンスの利用が終了すれば、レンダラ２は、ＤＲＭクライアント３に利用終了を通知する。これに応じて、ＤＲＭクライアント３は、フラグを「０」にセットする。なお、上記に説明したライセンスのロックについては、あくまでも一例であって、ライセンスのロック方法は、上記の処理に限られるものではなく、あらゆる周知のロック方法を用いることができる。
【００４４】
ＤＲＭクライアント３は、再生要求に対応するコンテンツ鍵を取得して、レンダラ２に送信する。以下、コンテンツ鍵を送信するためのメッセージをクライアント再生応答メッセージという（後述の図１３参照）。
【００４５】
ＤＲＭクライアント３は、レンダラ２からレンダラ終了要求メッセージが送られてきた場合、ライセンスの利用状況を更新して、ロックを解除し、終了した旨のメッセージ（以下、クライアント終了応答メッセージという）をレンダラ２に送信する。
【００４６】
以下、説明を簡単にするため、アプリケーション１、レンダラ２、およびＤＲＭクライアント３が別々のコンピュータ装置で実現されているかのように説明する。しかし、それぞれは、それぞれの動作を実現するプログラムを汎用の一つのＣＰＵに実行させることによってソフトウエア的に実現されてもよいし、ハードウエア的に実現されてもよい。すなわち、以下に説明するような機能を有するように実現されるのであれば、ソフトウエアによって実現されてもよいし、ハードウエアによって実現されてもよい。
【００４７】
図２は、アプリケーション１の機能的構成を示すブロック図である。図２において、アプリケーション１は、再生開始要求部１１と、再生制御要求部１２と、再生終了要求部１３と、制御部１４とを含む。
【００４８】
制御部１４は、アプリケーション１全体の動作を制御する。制御部１４は、コンテンツの再生を開始するか、コンテンツの再生を制御するか、コンテンツの再生を終了するかを判断し、判断結果に応じて、メッセージを送信するよう、それぞれ、再生開始要求部１１、再生制御要求部１２、再生終了要求部１３に指示する。
【００４９】
再生開始要求部１１は、コンテンツの再生が所望された場合、アプリ再生要求メッセージを作成して、レンダラ２に送信する。
【００５０】
図３は、アプリ再生要求メッセージのデータ構造を示す図である。アプリ再生要求メッセージは、コンテンツＵＲＩと、ライセンスＩＤと、リソースＩＤとからなる。ここで、コンテンツＵＲＩは、再生対象のコンテンツが格納されている位置を示すＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を示す。ライセンスＩＤは、再生対象のコンテンツのライセンスを識別するための識別子を示す。リソースＩＤは、再生対象のリソースを識別するための識別子を示す。
【００５１】
再生開始要求部１１は、アプリ再生要求メッセージを送信した後、レンダラ２から返信されてくるレンダラ再生応答メッセージを受信して、その内容を解析し、解析結果を制御部１４に伝える。
【００５２】
再生制御要求部１２は、コンテンツの再生の制御が所望された場合、制御要求メッセージを作成して、レンダラ２に送信する。制御要求メッセージは、ライセンスＩＤと、制御情報とからなる。ここで、ライセンスＩＤは、再生中のリソースのライセンスＩＤである。制御情報は、どのように再生するかを示した制御内容である。再生開始要求部１１は、制御要求メッセージを送信した後、レンダラ２から返信されてくる制御応答メッセージを受信して、その内容を解析し、解析結果を制御部１４に伝える。
【００５３】
再生終了要求部１３は、コンテンツの再生の終了が所望された場合、アプリ終了要求メッセージを作成して、レンダラ２に送信する。
【００５４】
図４は、アプリ終了要求メッセージのデータ構造を示す図である。アプリ終了要求メッセージは、再生中のリソースのライセンスＩＤからなる。再生終了要求部１３は、アプリ終了要求メッセージを送信した後、レンダラ２から返信されてくるレンダラ終了応答メッセージを受信して、その内容を解析し、解析結果を制御部１４に伝える。
【００５５】
図５は、レンダラ２の機能的構成を示すブロック図である。図５において、レンダラ２は、制御部２１と、動画用レンダラ２２と、ＨＴＭＬ・静止画用レンダラ２３とを含む。制御部２１は、再生開始制御部２４と、再生制御部２５と、再生終了制御部２６とを有する。なお、ここでは、動画用レンダラ２２およびＨＴＭＬ・静止画用レンダラ２３が、レンダラ２の内部に構成されていることとしたが、これらはレンダラ２の外部にそれぞれ構成されていてもよいし、どちらか一方のみがレンダラ２の内部に構成されていてもよい。
【００５６】
再生開始制御部２４は、アプリケーション１からアプリ再生要求メッセージが送られてきた場合、その内容を解析して、レンダラ再生要求メッセージを作成し、ＤＲＭクライアント３に送信する。
【００５７】
図６は、レンダラ再生要求メッセージのデータ構造を示す図である。レンダラ再生要求メッセージは、ライセンスＩＤと、リソースＩＤとからなる。レンダラ再生要求メッセージに含まれているライセンスＩＤおよびリソースＩＤは、アプリ再生要求メッセージに含まれていたライセンスＩＤおよびリソースＩＤと同一のものである。
【００５８】
再生開始制御部２４は、レンダラ再生要求メッセージを送信した後、ＤＲＭクライアント３から返信されてくるクライアント再生応答メッセージを受信し、リソースの種別、コンテンツ鍵およびレンダラの利用条件を取得する。再生開始制御部２４は、リソースが動画であるか、それともＨＴＭＬまたは静止画であるかを判断し、動画であれば、コンテンツ鍵およびレンダラの利用条件を動画用レンダラ２２に与え、ＨＴＭＬまたは静止画であれば、コンテンツ鍵およびレンダラの利用条件をＨＴＭＬ・静止画用レンダラ２３に与え、当該リソースを復号化させて再生させる。そして、再生開始制御部２４は、レンダラ再生応答メッセージを作成し、アプリケーション１に送信する。なお、ここで注意すべきは、たとえ、リソースが動画であっても、サブリソースである場合、ライセンスのロックや再生終了後のライセンスの更新は行われない点である。
【００５９】
再生制御部２５は、アプリケーション１から制御要求メッセージが送られてきた場合、その内容を解析して、コンテンツの再生を制御し、制御応答メッセージを作成して、アプリケーション１に送信する。
【００６０】
再生終了制御部２６は、アプリケーション１からアプリ終了要求メッセージが送られてきた場合、その内容を解析して、動画用レンダラ２２またはＨＴＭＬ・静止画用レンダラ２３にコンテンツの再生を終了させる。終了対象のコンテンツがメインリソースである場合、再生終了制御部２６は、動画用レンダラ２２が管理するコンテンツの利用状況を取得して、レンダラ終了要求メッセージを作成して、ＤＲＭクライアント３に送信し、ライセンスの更新を要求する。
【００６１】
図７は、レンダラ終了要求メッセージのデータ構造を示す図である。レンダラ終了要求メッセージは、ライセンスＩＤと、利用結果情報とからなる。ここで、ライセンスＩＤは、アプリ終了要求メッセージで指定されていたライセンスＩＤと同一である。利用結果情報は、再生されたコンテンツがどのように利用されたかを示す情報である。
【００６２】
図８は、利用結果情報のデータ構造を示す図である。利用結果情報は、コンテンツの利用の有無を示すフラグと、コンテンツを利用した時間とからなる。
【００６３】
終了対象のコンテンツがサブリソースである場合、再生終了制御部２６は、レンダラ終了要求メッセージを作成せずに、ＨＴＭＬ・静止画用レンダラ２３に再生を終了させる。
【００６４】
動画用レンダラ２２は、メインリソースを復号化して再生する。図９は、動画用レンダラ２２の機能的構成を示すブロック図である。図９において、動画用レンダラ２２は、デクリプト部２２１と、デコード部２２２と、利用状況管理部２２３とを有する。動画用レンダラ２２は、メインリソースを復号化して再生する必要があるので、高速に動作する必要がある。そのため、動画用レンダラ２２は、専用のハードウエアによって実現されていてもよい。
【００６５】
デクリプト部２２１は、再生開始制御部２４から与えられるコンテンツ鍵を用いて、メインリソースを復号化し、デコード部２２２に与える。デコード部２２２は、デクリプト部２２１によって復号化されたメインリソースを再生する。なお、図面上、デクリプト部２２１がコンテンツ格納部からコンテンツを取得する経路については、図示を省略している（その他についても、同様に、コンテンツ格納部からコンテンツを取得する経路については、図示を省略している）。
【００６６】
また、デクリプト部２２１は、コンテンツの利用状況に関する情報を利用状況管理部２２３に登録する。ここで、登録されるコンテンツの利用状況に関する情報は、コンテンツを利用（復号化）したか否か、およびコンテンツを利用した時間に関する情報である。利用状況管理部２２３は、デクリプト部２２１からの指示に応じて、メインリソースの利用状況を格納する。
【００６７】
ＨＴＭＬ・静止画用レンダラ２３は、サブリソースを復号化して再生する。図１０は、ＨＴＭＬ・静止画用レンダラ２３の機能的構成を示すブロック図である。図１０において、ＨＴＭＬ・静止画用レンダラ２３は、デクリプト部２３１と、デコード部２３２と、キャッシュ部２３３とを有する。
【００６８】
デクリプト部２３１は、再生開始制御部２４から与えられるコンテンツ鍵を用いて、サブリソースを復号化し、復号化されたサブリソースをキャッシュ部２３３に格納する。メニュー画面等のサブリソースは、ＨＴＭＬ等の構造化データであるので、ボタンなどの数十〜数百個のＰＮＧ（Ｐｏｒｔａｂｌｅ  Ｎｅｔｗｏｒｋ  Ｇｒａｐｈｉｃｓ）ファイル等と関連付けられているのが通常である。このような状況下で、関連付けられているファイル毎に、ＤＲＭ処理および復号化処理を行うのは、アプリケーション、レンダラおよびＤＲＭクライアント、それぞれに処理負担増となる。また、ダウンロードファイルおよびＤＲＭ情報ファイルのリソースリストが長大化してしまい、リソースへのアクセスロスも発生する。そのため、本実施形態では、マルチメディアコンテンツを構成する全てのサブリソースは、Ｚｉｐ等で圧縮した上で暗号化されているものとする。つまり、本実施形態では、マルチメディアコンテンツには、メインリソースと、Ｚｉｐ圧縮された全てのサブリソース（以下、ＥＺＰファイルという）とが含まれており、これらが共に暗号化されている。そのため、デクリプト部２３１は、マルチメディアコンテンツに含まれるＥＺＰファイルを復号化して解凍し、解凍された全てのサブリソースをキャッシュ部２３３に一時格納しておく。
【００６９】
デコード部２３２は、キャッシュ部２３３に格納されている復号化されたサブリソースを取得して、再生する。サブリソースはＨＴＭＬ等の構造化データであるので、デコード部２３２は、典型的には、ブラウザ等のソフトウエアによって実現される。
【００７０】
図１１は、ＤＲＭクライアント３の機能的構成を示すブロック図である。図１１において、ＤＲＭクライアント３は、ライセンス格納部３１と、制御部３２と、再生要求受付部３３と、終了要求受付部３４と、利用条件判断部３５と、利用状況更新部３６とを含む。
【００７１】
ライセンス格納部３１は、ライセンスを格納するための記録媒体である。図１２は、ライセンスのデータ構造を示す図である。図１２に示すように、ライセンスは、ライセンス情報と、利用状況情報とからなる。
【００７２】
ライセンス情報には、リソース毎の利用条件がリソース単位で設定されている。ライセンス情報は、ライセンスＩＤと、有効期間と、許可対象ユーザＩＤと、利用条件情報とからなる。ライセンスＩＤとは、当該ライセンスの識別子を示す。有効期間は、当該ライセンスが有効な期間を示す。許可対象ユーザＩＤは、当該ライセンスが付与されたユーザの識別子を示す。利用条件情報は、当該ライセンスを利用するための条件を示す。
【００７３】
利用条件情報は、共通条件情報と、メインリソース利用条件情報と、一以上のサブリソース利用条件情報を含むサブリソース利用条件情報集合とからなる。
【００７４】
共通条件情報とは、メインリソースとサブリソースとに共通する条件を示す。共通条件として、たとえば、コンテンツ利用が許可されている国に関する情報、レンダラ利用条件としてのアナログ出力制限に関する情報や、再生時の品質変換可否に関する情報等がある。メインリソース利用条件情報は、メインリソースを利用する際の条件を示す。
【００７５】
メインリソース利用条件情報は、コンテンツＩＤと、リソースＩＤと、コンテンツ鍵と、利用可能期間と、利用可能相対期間と、利用可能回数と、利用可能時間とからなる。ここで、コンテンツＵＲＩは、ライセンスに対応するコンテンツのＵＲＩを示す。リソースＩＤは、当該メインリソースの識別子を示す。本実施形態において、メインリソース利用条件情報とサブリソース利用条件情報とでは、別の配列を用いる。したがって、リソースＩＤが格納されている配列を参照することによって、メインリソースであるかサブリソースであるかを区別することができる。コンテンツ鍵は、メインリソースを復号化するための鍵である。利用可能期間は、メインリソースを利用することができる期間の末日を示す。利用可能相対期間は、初回利用日から何日間利用可能かといった条件を示す。後述の利用状況情報に含まれている利用日時を参照することによって、現在の利用日時が利用可能相対期間を超えているか否かを判断できる。利用可能回数は、メインリソースを利用することができる最大回数を示す。利用可能時間は、メインリソースを利用することができる最大時間を示す。
【００７６】
サブリソース利用条件情報は、コンテンツＩＤと、リソースＩＤと、コンテンツ鍵と、参照情報とからなる。ここで、コンテンツＵＲＩは、ライセンスに対応するコンテンツのＵＲＩを示す。リソースＩＤは、サブリソースの識別子を示す。コンテンツ鍵は、サブリソースを復号化するための鍵である。参照情報には、メインリソースの利用条件情報を参照すべきか否かを示す情報が格納されている。参照情報において、メインリソースの利用条件情報を参照すべきと指定されている場合、サブリソースは、メインリソースの利用条件を満たしている場合にのみ、コンテンツを利用することができる。このような参照情報を設けたのは、メインリソースが利用不可能となった場合に、サブリソースも同時に利用不可能とするためである。メインリソースが利用不可能となった後も利用可能としたいサブリソースに対しては、参照情報は、メインリソースの利用条件を参照すべきでないと指定される。
【００７７】
利用状況情報は、更新可能な領域である。利用状況情報には、今までのコンテンツの利用状況（コンテンツがどの程度利用されたかを示す情報）が格納されている。具体的には、利用条件情報は、利用日時と、利用回数と、利用時間とからなる。利用日時は、コンテンツを利用した最初の日時を示す。利用回数は、今までコンテンツを利用した合計回数を示す。利用時間は、今までコンテンツを利用した合計時間を示す。
【００７８】
再生要求受付部３３は、レンダラ２からのレンダラ再生要求メッセージを受信し、当該メッセージで指定されているライセンスＩＤおよびリソースＩＤを制御部３２に通知する。これに応じて、制御部３２は、リソースＩＤが格納されている配列に基づいて、当該リソースＩＤに対応するリソースがメインリソースであるかサブリソースであるか判断する。メインリソースである場合、制御部３２は、ライセンスをロックして対応するコンテンツ鍵をライセンス格納部３１から取得し、利用条件判断部３５にレンダラ利用条件を作成させ、クライアント再生応答メッセージを作成して、再生要求受付部３３にレンダラ２宛に送信させる。一方、サブリソースである場合、制御部３２は、ライセンスをロックすることなく、ライセンス格納部３１からコンテンツ鍵を取得して、利用条件判断部３５にレンダラ利用条件を作成させ、ライアント再生応答メッセージを作成して、再生要求受付部３３にレンダラ２宛に送信させる。
【００７９】
図１３は、クライアント再生応答メッセージのデータ構成を示す図である。クライアント再生応答メッセージは、リソース種別と、コンテンツ鍵と、レンダラ利用条件情報とからなる。リソース種別は、メインリソースであるか、サブリソースであるかを示す情報である。コンテンツ鍵は、メインリソースまたはサブリソースを復号化するための鍵である。レンダラ利用条件情報は、レンダラ２が復号化する際にあたっての条件を示す。
【００８０】
図１４は、レンダラ利用条件情報のデータ構成を示す図である。レンダラ利用条件情報には、有効期間の終了時間までの時間と、再生時の品質変換の可否を示す情報と、アナログ出力を制限するか否かを示す情報と、コンテンツを利用できる時間の合計と、利用回数に制限が設けられているか否かを示す情報とが指定されている。
【００８１】
終了要求受付部３４は、レンダラからのレンダラ終了要求メッセージを受信し、当該メッセージで指定されているライセンスＩＤおよび利用結果情報を制御部３２に通知する。これに応じて、制御部３２は、利用結果情報を利用状況更新部３６に与え、ライセンス格納部３１に格納されているライセンスの利用状況情報をどのように更新するか算出させ、その判断結果に基づいて、ライセンス格納部３１に格納されているライセンスの利用状況情報を更新する。そして、制御部３２は、クライアント終了応答メッセージを作成して、終了要求受付部３４にレンダラ２宛に送信させる。
【００８２】
図１５は、アプリケーション１がレンダラ２に対してコンテンツの再生を要求するときのアプリケーション１の動作を示すフローチャートである。以下、図１５を参照しながら、コンテンツの再生を要求するときのアプリケーション１の動作について説明する。
【００８３】
まず、アプリケーション１の再生開始要求部１１は、再生対象となるコンテンツのＵＲＩをコンテンツが格納されているコンテンツ格納部から取得する（ステップＳ１０１）。次に、再生開始要求部１１は、当該コンテンツに対するライセンスＩＤおよびリソースＩＤをコンテンツ格納部から取得する（ステップＳ１０２）。次に、再生開始要求部１１は、上記ステップで取得したコンテンツＵＲＩ、ライセンスＩＤ、およびリソースＩＤを用いて、アプリ再生要求メッセージを作成し（ステップＳ１０３）、レンダラ２に送信して（ステップＳ１０４）、処理を終了する。
【００８４】
図１６は、アプリケーション１から再生要求があったときのレンダラ２の動作を示すフローチャートである。以下、図１６を参照しながら、アプリケーション１から再生要求があったときのレンダラ２の動作について説明する。
【００８５】
まず、レンダラ２の再生開始制御部２４は、アプリケーション１から送られてきたアプリ再生要求メッセージを解析して、ライセンスＩＤおよびリソースＩＤを取得する（ステップＳ２０１）。次に、再生開始制御部２４は、取得したライセンスＩＤおよびリソースＩＤを用いて、レンダラ再生要求メッセージを作成し（ステップＳ２０２）、ＤＲＭクライアント３に送信する（ステップＳ２０３）。
【００８６】
次に、再生開始制御部２４は、ＤＲＭクライアント３から送られてくるクライアント再生応答メッセージを受信し（ステップＳ２０４）、コンテンツ鍵を取得する（ステップＳ２０５）。次に、再生開始制御部２４は、クライアント再生応答メッセージに含まれるリソース種別を参照して、取得したコンテンツ鍵が、メインリソースであるかそれともサブリソースであるか判断する（ステップＳ２０６）。
【００８７】
メインリソースである場合、再生開始制御部２４は、動画用レンダラ２２に、取得したコンテンツ鍵を渡す。コンテンツ鍵を受け取った動画用レンダラ２２は、コンテンツ格納部からコンテンツを取得し、コンテンツ鍵を用いて復号化して再生を開始し（ステップＳ２０６）、ステップＳ２０８の動作に進む。
【００８８】
一方、サブリソースである場合、ＨＴＭＬ・静止画用レンダラ２３のデコード部２３２は、デクリプト部２３１に対して、ＥＺＰファイルの復号化を要求する（ステップＳ２０９）。これに応じて、デクリプト部２３１は、コンテンツ格納部からＥＺＰファイルを取得して、ステップＳ２０５で取得したコンテンツ鍵を用いて、ＥＺＰファイルを復号化する（ステップＳ２１０）。次に、デクリプト部２３１は、復号化されたＥＺＰファイルを解凍する（ステップＳ２１１）。これによって、ＥＺＰファイルに含まれていたＨＴＭＬファイルやＰＮＧファイル等の全てのサブリソースが展開されることとなる。次に、デクリプト部２３１は、展開された各ファイルをキャッシュ部２３３に格納する（ステップＳ２１２）。その後、デコード部２３２は、キャッシュ部２３３に格納されている各ファイルを取得して、サブリソースを表示し（ステップＳ２１３）、ステップＳ２０８の動作に進む。なお、キャッシュ部２３３に格納されている展開後の各ファイルは、所定時間が経過した後に、デコード部２３２によって削除されることとする。キャッシュ部２３３に格納されているサブリソースが削除された後、アプリケーション１から再生要求があれば、デクリプト部２３１は、再び、ステップＳ２０９〜Ｓ２１３の動作を実行する。一方、サブリソースがデコード部２３２に格納されている場合、デクリプト部２３１は、ステップＳ２０９〜Ｓ２１３の動作を省略する。
【００８９】
ステップＳ２０８において、再生開始制御部２４は、再生開始に関する結果を含むレンダラ再生応答メッセージを作成する。その際、再生開始制御部２４は、コンテンツ鍵を取得して、正常にコンテンツの再生が開始された場合、再生が成功した旨のレンダラ再生応答メッセージを作成する。一方、コンテンツ鍵を取得することができなかったため、コンテンツの再生が開始されなかった場合、再生が失敗した旨のレンダラ再生応答メッセージを作成する。
【００９０】
その後、再生開始制御部２４は、作成したレンダラ再生応答メッセージをアプリケーション１に送信して（ステップＳ２１４）、処理を終了する。これに応じて、アプリケーション１は、再生が行われたか否かを認識する。
【００９１】
図１７は、レンダラ２からＤＲＭクライアント３に対して再生要求があったときのＤＲＭクライアントの動作を示すフローチャートである。以下、図１７を参照しながら、レンダラ２から再生要求があったときのＤＲＭクライアント３の動作について説明する。
【００９２】
まず、ＤＲＭクライアント３の再生要求受付部３３は、レンダラ再生要求メッセージを受信する（ステップＳ３０１）。次に、再生要求受付部３３は、受信したレンダラ再生要求メッセージを解析して、当該メッセージに含まれているライセンスＩＤおよびリソースＩＤを制御部３２に通知する（ステップＳ３０２）。
【００９３】
次に、制御部３２は、通知されたリソースＩＤに対応するリソースがメインリソースであるか、それともサブリソースであるか否かを判断する（ステップＳ３０３）。サブリソースである場合、制御部３２は、ライセンスをロックすることなく、ステップＳ３０６の動作に進む。一方、メインリソースである場合、制御部３２は、ライセンスがロックされているか否かを判断する（ステップＳ３０４）。
【００９４】
ステップＳ３０４において、ライセンスがロックされていると判断した場合、制御部３２は、コンテンツ鍵を取得することなく、ステップＳ３１１の動作に進み、ライセンスがロックされている旨のクライアント再生応答メッセージを作成してステップＳ３１０の動作に進む。一方、ライセンスがロックされていないと判断した場合、制御部３２は、ライセンスをロックし（ステップＳ３０５）、当該ライセンスが利用可能であるか否かを判断する（ステップＳ３０６）。
【００９５】
ライセンスが利用可能であるか否かは、ライセンスに格納されている利用状況情報内の利用日時、利用回数および利用時間とメインリソース利用条件情報に格納されている利用可能期間、利用可能回数および利用可能時間とを比較することによって行われる。たとえば、メインリソースが利用可能であるか否かについて、利用日時が利用可能期間を超えている場合、制御部３２は、ライセンスの利用が不可能であると判断する。また、利用回数が利用可能回数を超えている場合、制御部３２は、ライセンスの利用が不可能であると判断する。利用時間が利用可能時間を超えている場合、制御部３２は、ライセンスの利用が不可能であると判断する。サブリソースが利用可能であるかについて、参照情報にメインリソースの利用条件情報を参照すべきであると指定されている場合、制御部３２は、指定されているメインリソースの利用条件情報と利用状況情報とを比較することによって、ライセンスの利用可否を判断する。一方、参照情報にメインリソースの利用条件情報を参照すべきであると指定されていない場合、制御部３２は、ライセンスの利用が可能であると判断する。
【００９６】
ステップＳ３０６において、ライセンスが利用可能でないと判断した場合、制御部３２は、コンテンツ鍵を取得することなく、ステップＳ３０９の動作に進む。一方、ライセンスが利用可能であると判断した場合、制御部３２は、ステップＳ３０７の動作に進む。
【００９７】
ステップＳ３０７において、制御部３２は、ライセンス格納部３１から、当該リソースＩＤに対応するコンテンツ鍵を取得する。次に、制御部３２は、レンダラ利用条件を作成し（ステップＳ３０８）、ステップＳ３０９の動作に進む。制御部３２は、ライセンスに格納されている利用状況情報とメインリソース利用条件情報とを比較して、有効期間の終了時間までの時間、コンテンツを利用できる時間合計（残り時間）、残りの利用回数を算出して、利用回数に制限が設けられているか否かを求め、さらに、共通情報を参照して、再生時の品質変換の可否やアナログ出力の制限を求め、レンダラ利用条件を作成する。
【００９８】
ステップＳ３０９において、制御部３２は、取得したコンテンツ鍵および作成したレンダラ利用条件を含むクライアント再生応答メッセージを作成する。これに応じて、再生開始制御部２４は、作成されたクライアント再生応答メッセージをレンダラ２へ送信し（ステップＳ３１０）、処理を終了する。
【００９９】
図１８は、コンテンツの再生の制御をレンダラ２に要求するときのアプリケーション１の動作を示すフローチャートである。以下、図１８を参照しながら、コンテンツの再生の制御を要求するときのアプリケーション１の動作について説明する。
【０１００】
まず、アプリケーション１の再生制御要求部１２は、再生対象のコンテンツに対応するライセンスＩＤを取得する（ステップＳ４０１）。次に、再生制御要求部１２は、取得したライセンスＩＤおよび制御内容を示す情報を含む制御要求メッセージを作成して（ステップＳ４０２）、レンダラ２へ送信し（ステップＳ４０３）、処理を終了する。
【０１０１】
図１９は、アプリケーション１から再生制御要求があったときのレンダラ２の動作を示すフローチャートである。以下、図１９を参照しながら、再生制御要求があったときのレンダラ２の動作について説明する。
【０１０２】
まず、レンダラ２の再生制御部２５は、受信した制御要求メッセージの内容を解析して、制御対象のリソースおよび制御内容（一時停止や早送り、巻き戻し等）を認識する（ステップＳ５０１）。次に、認識した制御対象のリソースを再生中の動画用レンダラ２２またはＨＴＭＬ・静止画用レンダラ２３に対して、認識した制御内容に基づいて、再生を制御するよう指示する（ステップＳ５０２）。これに応じて、動画用レンダラ２２またはＨＴＭＬ・静止画用レンダラ２３は、コンテンツの再生を制御する。
【０１０３】
次に、再生制御部２５は、再生制御に関する結果を示す制御応答メッセージを作成して（ステップＳ５０３）、アプリケーション１に送信し（ステップＳ５０４）、処理を終了する。
【０１０４】
図２０は、コンテンツの再生終了をレンダラ２へ要求するときのアプリケーション１の動作を示すフローチャートである。以下、図２０を参照しながら、コンテンツの再生終了を要求するときのアプリケーション１の動作について説明する。
【０１０５】
まず、アプリケーション１の再生終了要求部１３は、コンテンツ格納部を参照して、再生終了の対象となるコンテンツに対応するライセンスＩＤを取得する（ステップＳ６０１）。次に、再生終了要求部１３は、取得したライセンスＩＤを含むアプリ終了要求メッセージを作成し（ステップＳ６０２）、レンダラ２へ送信し（ステップＳ６０３）、処理を終了する。
【０１０６】
図２１は、アプリケーション１から再生終了要求があったとき、またはコンテンツを最後まで再生したときのレンダラ２の動作を示すフローチャートである。以下、図２１を参照しながら、再生終了要求があったとき、またはコンテンツを最後まで再生したときのレンダラ２の動作について説明する。
【０１０７】
まず、レンダラ２の再生終了制御部２６は、アプリケーション１からアプリ終了要求メッセージを受信して内容を解析し（ステップＳ７０１）、指定されているライセンスＩＤに対応するコンテンツの再生を終了する（ステップＳ７０２）。このとき、再生終了制御部２６は、動画用レンダラ２２またはＨＴＭＬ・静止画用レンダラ２３に対して、再生を終了するよう指示する。なお、コンテンツを最後まで再生した場合、ステップＳ７０１とＳ７０２の動作は省略される。
【０１０８】
次に、再生終了制御部２６は、再生を終了したコンテンツがメインリソースであるか、それとも、サブリソースであるか否かを判断する（ステップＳ７０３）。サブリソースである場合、再生終了制御部２６は、ステップＳ７０７の動作に進む。一方、メインリソースである場合、再生終了制御部２６は、ステップＳ７０４の動作に進む。
【０１０９】
ステップＳ７０４において、再生終了制御部２６は、終了したコンテンツのコンテンツ鍵を削除する。次に、再生終了制御部２６は、利用状況管理部２２３に格納されている情報からコンテンツの利用がなされたか否かを判断し、さらにコンテンツが利用された時間を求めて、利用結果情報を作成する（ステップＳ７０５）。次に、再生終了制御部２６は、ライセンスＩＤおよび利用結果情報に基づいて、レンダラ終了要求メッセージを作成し、ＤＲＭクライアントに送信する（ステップＳ７０６）。
【０１１０】
次に、再生終了制御部２６は、レンダラ終了要求メッセージに応じてＤＲＭクライアントから送られてくるクライアント終了応答メッセージを受信して解析し（ステップＳ７０７）、ステップＳ７０８の動作に進む。
【０１１１】
ステップＳ７０８において、再生終了制御部２６は、再生終了に関する結果を含むレンダラ終了応答メッセージを作成して、アプリケーション１に送信し（ステップＳ７０９）、処理を終了する。
【０１１２】
図２２は、レンダラ２から終了要求があったときのＤＲＭクライアント３の動作を示すフローチャートである。以下、図２２を参照しながら、レンダラ２から終了要求があったときのＤＲＭクライアント３の動作について説明する。
【０１１３】
まず、ＤＲＭクライアント３の終了要求受付部３４は、レンダラ２からのレンダラ終了要求メッセージを受信する（ステップＳ８０１）。次に、終了要求受付部３４は、受信したレンダラ終了要求メッセージを解析して、ライセンスＩＤおよび利用結果情報を抽出して、制御部３２に与える（ステップＳ８０２）。
【０１１４】
次に、制御部３２は、通知されたライセンスＩＤに基づいて、更新対象のライセンスを認識し、通知された利用結果情報に基づいて、ライセンスの利用状況情報を利用状況更新部３６に更新させる（ステップＳ８０３）。このとき、具体的には、利用状況更新部３６は、利用結果情報で示されているコンテンツの利用の有無を示すフラグに基づいて、利用状況情報の利用回数を増やし、コンテンツを利用した時間に基づいて、利用状況情報の利用時間を増やし、初回利用時であった場合には、利用日時を現在の日時に変更する。制御部３２は、利用状況更新部３６によって利用状況情報が更新されたライセンスをライセンス格納部３１に上書き保存する。
【０１１５】
次に、制御部３２は、当該ライセンスＩＤに対応するライセンスのロックを解除する（ステップＳ８０４）。次に、制御部３２は、クライアント終了応答メッセージを作成して（ステップＳ８０５）、レンダラ２に送信し（ステップＳ８０６）、処理を終了する。
【０１１６】
このように、上記実施形態では、マルチメディア型のコンテンツをメインリソースとサブリソースとに分けて、メインリソースのみについてライセンスの利用を管理するので、メニュー画面等が利用されたことによってライセンスが更新され、本編動画等が再生できなくなるといった不都合を解消することができる。したがって、上記実施形態によって、マルチメディア型のコンテンツの権利管理を行うために適したデータ構造、さらに当該データ構造を有するデータを格納した記録媒体、ならびにそれを再生するための再生装置および再生方法が提供されることとなる。
【０１１７】
また、上記実施形態では、全てのサブリソースは、ＥＺＰファイルとして圧縮されている。コンテンツを再生する場合、レンダラは、ＥＺＰファイルをコンテンツ鍵を用いて復号化した後、解凍し、展開されたファイルを一時格納しておく。ブラウザ等のデコード部は、一時格納されている各ファイルを読み出してサブリソースを再生する。したがって、レンダラの処理負担が軽減されることとなる。デクリプト部およびキャッシュ部で構成されるＥＺＰ処理モジュールは規模が小さいので、ＥＺＰ処理モジュールは、ハードウエアで構成することができる。したがって、ＥＺＰ処理モジュール（すくなくともデクリプト部）は、容易に耐タンパ化することができる。ブラウザ等のデコード部を耐タンパ化するのは困難であるが、ＥＺＰ処理モジュール（すくなくともデクリプト部）を耐タンパ化することによって、コンテンツ鍵が外部に暴露されるのを防止することができる。また、デクリプト部をソフトウエア的に構成する場合であっても、容易に耐タンパ化することができる。また、展開されたサブリソースは、一定時間後には、削除されるので、静的攻撃に耐えうることができる。さらに、展開されたサブリソースが一時格納されるので、ブラウザ等のデコード部は、再生終了時に利用完了通知を行わなくてもよくなる。
【０１１８】
なお、上記実施形態では、サブリソースが圧縮化されていることとしたが、サブリソースは圧縮化されていなくてもよい。圧縮化されていない場合、レンダラは、図１６に示すステップＳ２１１の解凍処理を省くこととなる。また、上記実施形態では、全てのサブリソースがまとめて復号化されていることとしたが、サブリソースが個別に復号化されていてもよい。この場合、図１６に示すステップＳ２０９〜Ｓ２１３において、レンダラは、個別にサブリソースを復号化し解凍して、キャッシュすることとなる。また、レンダラは、サブリソースをキャッシュせずに、再生の度に、復号化および／または解凍してもよい。
【産業上の利用可能性】
【０１１９】
本発明にかかるマルチメディア型コンテンツの再生装置および再生方法、ならびにそれに用いられるデータが格納された記録媒体は、マルチメディア型のコンテンツの権利管理を行うのに適しており、コンテンツ配信等の分野において有用である。
【図面の簡単な説明】
【０１２０】
【図１】本発明の一実施形態に係る権利管理システムの全体構成を示す図
【図２】アプリケーション１の機能的構成を示すブロック図
【図３】アプリ再生要求メッセージのデータ構造を示す図
【図４】アプリ終了要求メッセージのデータ構造を示す図
【図５】レンダラ２の機能的構成を示すブロック図
【図６】レンダラ再生要求メッセージのデータ構造を示す図
【図７】レンダラ終了要求メッセージのデータ構造を示す図
【図８】利用結果情報のデータ構造を示す図
【図９】動画用レンダラ２２の機能的構成を示すブロック図
【図１０】ＨＴＭＬ・静止画用レンダラ２３の機能的構成を示すブロック図
【図１１】ＤＲＭクライアント３の機能的構成を示すブロック図
【図１２】ライセンスのデータ構造を示す図
【図１３】クライアント再生応答メッセージのデータ構成を示す図
【図１４】レンダラ利用条件情報のデータ構成を示す図
【図１５】アプリケーション１がレンダラ２に対してコンテンツの再生を要求するときのアプリケーション１の動作を示すフローチャート
【図１６】アプリケーション１から再生要求があったときのレンダラ２の動作を示すフローチャート
【図１７】レンダラ２からＤＲＭクライアント３に対して再生要求があったときのＤＲＭクライアントの動作を示すフローチャート
【図１８】コンテンツの再生の制御をレンダラ２に要求するときのアプリケーション１の動作を示すフローチャート
【図１９】アプリケーション１から再生制御要求があったときのレンダラ２の動作を示すフローチャート
【図２０】コンテンツの再生終了をレンダラ２へ要求するときのアプリケーション１の動作を示すフローチャート
【図２１】アプリケーション１から再生終了要求があったとき、またはコンテンツを最後まで再生したときのレンダラ２の動作を示すフローチャート
【図２２】レンダラ２から終了要求があったときのＤＲＭクライアント３の動作を示すフローチャート
【符号の説明】
【０１２１】
１  アプリケーション
２  レンダラ
３  ＤＲＭクライアント
１１  再生開始要求部
１２  再生制御要求部
１３  再生終了要求部
１４，２１，３２  制御部
２２  動画用レンダラ
２３  ＨＴＭＬ・静止画用レンダラ
２４  再生開始制御部
２５  再生制御部
２６  再生終了制御部
２２１，２３１  デクリプト部
２２２，２３２  デコード部
２２３  利用状況管理部
２３３  キャッシュ部
３１  ライセンス格納部
３３  再生要求受付部
３４  終了要求受付部
３５  利用条件判断部
３６  利用状況更新部
【図１】
0004731111.tif 000002
【図２】
0004731111.tif 000003
【図３】
0004731111.tif 000004
【図４】
0004731111.tif 000005
【図５】
0004731111.tif 000006
【図６】
0004731111.tif 000007
【図７】
0004731111.tif 000008
【図８】
0004731111.tif 000009
【図９】
0004731111.tif 000010
【図１０】
0004731111.tif 000011
【図１１】
0004731111.tif 000012
【図１２】
0004731111.tif 000013
【図１３】
0004731111.tif 000014
【図１４】
0004731111.tif 000015
【図１５】
0004731111.tif 000016
【図１６】
0004731111.tif 000017
【図１７】
0004731111.tif 000018
【図１８】
0004731111.tif 000019
【図１９】
0004731111.tif 000020
【図２０】
0004731111.tif 000021
【図２１】
0004731111.tif 000022
【図２２】
0004731111.tif 000023