JP4640374B2 - 情報処理装置および方法、プログラム格納媒体、並びにプログラム - Google Patents

情報処理装置および方法、プログラム格納媒体、並びにプログラム Download PDF

Info

Publication number
JP4640374B2
JP4640374B2 JP2007124123A JP2007124123A JP4640374B2 JP 4640374 B2 JP4640374 B2 JP 4640374B2 JP 2007124123 A JP2007124123 A JP 2007124123A JP 2007124123 A JP2007124123 A JP 2007124123A JP 4640374 B2 JP4640374 B2 JP 4640374B2
Authority
JP
Japan
Prior art keywords
usage
usage right
client
transmission request
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007124123A
Other languages
English (en)
Other versions
JP2007249999A (ja
Inventor
隆二 石黒
洋志 川本
裕一 江面
元彦 長野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2007124123A priority Critical patent/JP4640374B2/ja
Publication of JP2007249999A publication Critical patent/JP2007249999A/ja
Application granted granted Critical
Publication of JP4640374B2 publication Critical patent/JP4640374B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Description

本発明は、情報処理装置および方法、プログラム格納媒体、並びにプログラムに関し、特に、ユーザに負担をかけることなく、より細かく分割された内容の使用権をユーザに提供することができるようにした、情報処理装置および方法、プログラム格納媒体、並びにプログラムに関する。
最近、インターネットに代表されるネットワークが普及し、各種のネットワークを介して、オーディオ、あるいはビデオなどのコンテンツが配布されるようになってきた。ユーザ（クライアント）は、ネットワークを介してサーバにアクセスし、コンテンツをダウンロードする。
また、コンテンツとそのコンテンツを利用する利用権を独立のものとすることが提案されている。このような場合、ユーザは、コンテンツ以外に、その利用権を別途取得する必要がある。そして、通常、コンテンツは暗号化されて、ユーザに提供され、その暗号を解く鍵は、通常、その利用権に含まれている。あるいはコンテンツに復号鍵が含まれていて、コンテンツの復号処理がタンパーレジスタントソフトウェア等でそのアルゴリズムを知られることなく行われる構成とするものもある。
このようにすることで、コンテンツをより容易に配布することが可能となる。
ところで、利用権は、支払い状況に応じて、内容が変化するような場合がある。例えば、登録時、２００円を支払うと、１０曲まで１ヶ月間利用することができるが、追加で１曲毎に５０円を支払うと、その曲を所有することができ（期間の制限がなくなり）、さらに追加で１００円を支払うと、ポータブル機器にその曲をチェックアウトすることができるといった内容の場合がある。
利用権の内容がこのように複雑である場合、利用権を取得したクライアントは、その利用権の状態がいずれの状態にあるのかを、自分自身で管理する必要がある。すなわち、その利用権の現在の状態が２００円を支払っただけの状態であるのか、その後、さらに５０円を１曲毎に支払ったのであるのか、支払ったのであるとすると、どの曲に対して支払ったのであるのか、さらには、その後、追加で１００円を支払い、ポータブル機器にチェックアウトすることができる状態にあるのかといったことを、クライアント自身が管理している必要がある。クライアントにこのような管理を行なわせることは、クライアントにとって大きな負荷となる。
また、クライアントにこのような管理を行わせると、悪意のユーザが利用権を改竄する恐れがあり、安全性の面からも好ましくない。
本発明は、このような状況に鑑みてなされたものであり、クライアントに負担をかけることなく、利用権を安全に管理することができるようにするものである。
本発明の一側面の情報処理装置は、コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信手段とを含む。
前記制御手段には、前記サブスクリプションサービスの利用権要求であるとき、ＡＫＥ(Authentication Key Exchange)処理を前記クライアントに要求させ、前記ＡＫＥ処理により取得されるセッション鍵により、前記使用状態が付加された利用権を暗号化させるようにすることができる。
前記受信手段には、前記クライアントから前記クライアントで使用する利用権に対応する使用状態と前記クライアントの識別情報、コンテンツ情報を受信させるようにすることができ、前記制御手段には、受信した前記コンテンツ情報、前記クライアントの識別情報に基づいて利用権に対応する使用状態に基づいて前記使用状態記憶手段に記憶された使用状態を更新させるようにすることができ、前記使用状態記憶手段には、更新された使用状態を記憶させるようにすることができる。
前記受信手段には、前記クライアントから前記クライアントで前記コンテンツを使用する処理が実行されるごとに使用状態を受信させるようにすることができる。
前記送信手段には、前記制御手段で更新された使用状態を前記クライアントへ送信させるようにすることができる。
本発明の一側面の情報処理方法は、コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段とを含む情報処理装置の情報処理方法において、前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、前記送信手段における、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップとを含む。
本発明の一側面のプログラムは、コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段とを含む情報処理装置を制御するコンピュータに、前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、前記送信手段における、前記受信ステップの処理で受信した利用権送信要求がサブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求がサブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップとを含む処理を実行させる。
本発明の一側面のプログラム格納媒体のプログラムは、コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、前記受信手段が受信した利用権送信要求がサブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求がサブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段とを含む情報処理装置を制御するコンピュータに、前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、前記送信手段における、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップとを含む処理を実行させる。
本発明の一側面の情報処理装置および方法、プログラム格納媒体、並びにプログラムにおいては、コンテンツを利用するクライアントから利用権送信要求が受信され、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態が記憶され、受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは記憶された使用状態が要求された利用権に付加され、さらに暗号化され、受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、使用状態が付加され、さらに暗号化された利用権が前記クライアントに送信され、受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみが、そのまま前記クライアントに送信される。
本発明によれば、よりセキュアな状態での利用権の配布を望まないユーザに必要以上の負担をかけることなく、利用権を配布することが可能となる。また、セキュアな環境下での利用権の取得を希望するユーザに対しては、より安全に利用権を配布することが可能となる。その結果、利用権が第３者に盗用されるようなことが防止することが可能となる。
図１は、本発明を適用したコンテンツ提供システムの構成を示している。インターネット２には、クライアント１−１，１−２（以下、これらのクライアントを個々に区別する必要がない場合、単にクライアント１と称する）が接続されている。この例においては、クライアントが２台のみ示されているが、インターネット２には、任意の台数のクライアントが接続される。
また、インターネット２には、クライアント１に対してコンテンツを提供するコンテンツサーバ３、コンテンツサーバ３が提供するコンテンツを利用するのに必要な利用権をクライアント１に対して付与するライセンスサーバ４、およびクライアント１が利用権を受け取った場合に、そのクライアント１に対して課金処理を行う課金サーバ５が接続されている。
コンテンツサーバ３とライセンスサーバ４には、コンテンツホルダサーバ６がさらに接続されている。コンテンツホルダサーバ６は、コンテンツサーバ３に対してコンテンツを提供するとともに、ライセンスサーバ４に対してコンテンツに関するプロダクト情報を提供する。
これらのコンテンツサーバ３、ライセンスサーバ４、課金サーバ５、およびコンテンツホルダ６も、任意の台数設けられ、必要に応じてインターネット２に接続される。
図２はライセンスサーバ４の構成を表している。
図２において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。タイマ２０は、計時動作を行い、時刻情報をCPU２１に供給する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
暗号化復号部２４は、コンテンツデータを暗号化するとともに、既に暗号化されているコンテンツデータを復号する処理を行う。コーデック部２５は、例えば、ATRAC（Adaptive Transform Acoustic Coding）３方式などでコンテンツデータをエンコードし、入出力インタフェース３２を介してドライブ３０に接続されている半導体メモリ４４に供給し、記録させる。あるいはまた、コーデック部２５は、ドライブ３０を介して半導体メモリ４４より読み出した、エンコードされているデータをデコードする。
半導体メモリ４４は、例えば、メモリースティック（商標）などにより構成される。
CPU２１、ROM２２、RAM２３、暗号化復号部２４、およびコーデック部２５は、バス３１を介して相互に接続されている。このバス３１にはまた、入出力インタフェース３２も接続されている。
入出力インタフェース３２には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、インターネット２を介しての通信処理を行う。通信部２９はまた、他のクライアントとの間で、アナログ信号またはデジタル信号の通信処理を行う。
入出力インタフェース３２にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
なお、図示は省略するが、クライアント１、コンテンツサーバ３、課金サーバ５も、図２に示したライセンスサーバ４と基本的に同様の構成を有するコンピュータにより構成される。そこで、以下の説明においては、図２の構成は、クライアント１、コンテンツサーバ３、課金サーバ５などの構成としても引用される。
なお、図示は省略するが、PD（Portable Device）も、図２に示したライセンスサーバ４と基本的に同様の構成を有するコンピュータにより構成される。
次に、図３のフローチャートを参照して、クライアント１がコンテンツサーバ３からコンテンツの提供を受ける処理について説明する。
ユーザが、入力部２６を操作することでコンテンツサーバ３に対するアクセスを指令すると、CPU２１は、ステップＳ１において、通信部２９を制御し、インターネット２を介してコンテンツサーバ３にアクセスさせる。ステップＳ２において、ユーザが、入力部２６を操作して、提供を受けるコンテンツを指定すると、CPU２１は、この指定情報を受け取り、通信部２９から、インターネット２を介してコンテンツサーバ３に、指定されたコンテンツのコンテンツIDを通知する。図４のフローチャートを参照して後述するように、この通知を受けたコンテンツサーバ３は、暗号化されたコンテンツデータを含むコンテンツを送信してくるので、ステップＳ３において、CPU２１は、通信部２９を介して、このコンテンツデータを受信すると、ステップＳ４において、その暗号化されているコンテンツデータを記憶部２８を構成するハードディスクに供給し、記憶させる。
次に、図４のフローチャートを参照して、クライアント１の以上の処理に対応するコンテンツサーバ３のコンテンツ提供処理について説明する。なお、以下の説明において、図２のライセンスサーバ４の構成は、コンテンツサーバ３の構成としても引用される。
ステップＳ２１において、コンテンツサーバ３のCPU２１は、インターネット２から通信部２９を介してクライアント１よりアクセスを受けるまで待機し、アクセスを受けたと判定したとき、ステップＳ２２に進み、クライアント１から送信されてきたコンテンツIDを取り込む。このコンテンツIDは、クライアント１が、図３のステップＳ２において通知してきた情報である。
ステップＳ２３において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されているコンテンツの中から、ステップＳ２２の処理で取り込まれたコンテンツIDで指定されたコンテンツデータを読み出す。CPU２１は、ステップＳ２４において、記憶部２８から読み出されたコンテンツデータを、暗号化復号部２４に供給し、コンテンツキーKcを用いて暗号化させる。
記憶部２８に記憶されているコンテンツデータは、コーデック部２５により、既にATRAC３方式によりエンコードされているので、このエンコードされているコンテンツデータが暗号化されることになる。
なお、もちろん、記憶部２８に予め暗号化した状態でコンテンツデータを記憶させることができる。この場合には、ステップＳ２４の処理は省略することが可能である。
次に、ステップＳ２５において、コンテンツサーバ３のCPU２１は、暗号化したコンテンツデータを伝送するフォーマットを構成するヘッダに、暗号化されているコンテンツを復号するのに必要なキー情報（図５を参照して後述するEKBとKEKBC（Kc））を付加する。そして、ステップＳ２６において、コンテンツサーバ３のCPU２１は、ステップＳ２４の処理で暗号化したコンテンツと、ステップＳ２５の処理でキー情報を付加したヘッダとをフォーマット化したデータを、通信部２９から、インターネット２を介して、アクセスしてきたクライアント１に送信する。
図５は、このようにして、コンテンツサーバ３からクライアント１にコンテンツが供給される場合のフォーマットの構成を表している。同図に示されるように、このフォーマットは、ヘッダ（Header）とデータ（Data）とにより構成される。
ヘッダには、コンテンツ情報（Content information）、URL(Uniform Resource Locator)、イネーブリングキーブロック（有効化キーブロック）（EKB（Enabling Key Block））、EKBから生成されたキーKEKBCを用いて暗号化されたコンテンツキーKcとしてのデータKEKBC（Kc）、コンテンツの属性（Attributes）、および署名（Signatures）が配置されている。なお、EKBについては、図１３および図１４を参照して後述する。
コンテンツ情報には、データとしてフォーマット化されているコンテンツデータを識別するための識別情報としてのコンテンツID（CID）、そのコンテンツのコーデックの方式などの情報が含まれている。
URLは、そのコンテンツを利用するために必要な利用権を取得するときアクセスするアドレス情報であり、図１のシステムの場合、具体的には、利用権を受けるために必要なライセンスサーバ４のアドレスである。
コンテンツの属性は、コンテンツの関する情報であり、コンテンツの属性には、コンテンツID、コンテンツの提供者を識別するための識別情報としてのレコードカンパニーID、アーティストを識別するための識別情報としてのアーティストIDなどが含まれる。本実施の形態では、属性は利用権の対象となるコンテンツを特定するために用いられる。
署名は、コンテンツの属性に対応する電子署名である。
データは、任意の数の暗号化ブロック（Encryption Block）により構成される。各暗号化ブロックは、イニシャルベクトル（IV（Initial Vector））、シード（Seed）、およびコンテンツデータをキーK'cで暗号化したデータEK'c(data)により構成されている。
キーK'cは、次式により示されるように、コンテンツキーKcと、乱数で設定される値Seedをハッシュ関数に適用して演算された値により構成される。
K'c＝Hash(Kc, Seed)
イニシャルベクトルIVとシードSeedは、各暗号化ブロック毎に異なる値に設定される。
この暗号化は、コンテンツのデータを８バイト単位で区分して、８バイト毎に行われる。後段の８バイトの暗号化は、前段の８バイトの暗号化の結果を利用して行われるCBC（Cipher Block Chaining）モードで行われる。
CBCモードの場合、最初の８バイトのコンテンツデータを暗号化するとき、その前段の８バイトの暗号化結果が存在しないため、最初の８バイトのコンテンツデータを暗号化するときは、イニシャルベクトルIVを初期値として暗号化が行われる。
このCBCモードによる暗号化を行うことで、１つの暗号化ブロックが解読されたとしても、その影響が、他の暗号化ブロックにおよぶことが抑制される。
また、暗号方式についてはこれに限らない。
以上のようにして、クライアント１は、コンテンツサーバ３からコンテンツを無料で、自由に取得することができる。従って、コンテンツそのものは、大量に、配布することが可能となる。
しかしながら、各クライアント１は、取得したコンテンツを利用するとき、そのコンテンツの利用が許可されていることを示す利用権を保持している必要がある。そこで、図６を参照して、クライアント１がコンテンツを再生する場合の処理について説明する。
ステップＳ４１において、クライアント１のCPU２１は、ユーザが入力部２６を操作することで指示したコンテンツの識別情報（CID）を取得する。この識別情報は、例えば、コンテンツのタイトルや、記憶されている各コンテンツ毎に付与されている番号などにより構成される。
そして、CPU２１は、コンテンツが指示されると、そのコンテンツの属性（Attributes）を読み取る。この属性（Attributes）は、図５に示されるように、コンテンツのヘッダに記述されているものである。
次に、ステップＳ４２に進み、CPU２１は、ステップＳ４１で読み取られた属性（Attributes）が各利用権に含まれているコンテンツ条件を満たすような利用権が、クライアント１により既に取得され、記憶部２８に記憶されているか否かを判定する。まだ、利用権が取得されていない場合には、ステップＳ４３に進み、CPU２１は、利用権取得処理を実行する。この利用権取得処理の詳細は、図７のフローチャートを参照して後述する。
ステップＳ４２において、利用権が既に取得されていると判定された場合、または、ステップＳ４３において、利用権取得処理が実行された結果、利用権が取得された場合、ステップＳ４４に進み、CPU２１は、取得されている利用権は有効期限内のものであるか否かを判定する。利用権が有効期限内のものであるか否かは、利用権の内容として規定されている期限（後述する図８参照）と、タイマ２０により計時されている現在日時と比較することで判断される。利用権の有効期限が既に満了していると判定された場合、CPU２１は、ステップＳ４５に進み、利用権更新処理を実行する。
ステップＳ４４において、利用権はまだ有効期限内であると判定された場合、または、ステップＳ４５において、利用権が更新された場合、ステップＳ４６に進み、CPU２１は記憶部２８に記憶されている、利用権に含まれる使用条件及び使用状態（後述する）を読み出し、再生の条件を満たしているかどうかを判定する。
ステップＳ４６において、利用権に含まれる使用条件、及び使用状態に基づき、再生が許可されると判断された場合には、ステップＳ４７に進み、CPU２１は、暗号化されているコンテンツデータを記憶部２８から読み出し、RAM２３に格納させる。そして、ステップＳ４８において、CPU２１は、RAM２３に記憶された暗号化コンテンツデータを、図５のデータに配置されている暗号化ブロック単位で、暗号化復号部２４に供給し、コンテンツキーKcを用いて復号させる。
コンテンツキーKcを得る方法の具体例は、図１３および図１４を参照して後述するが、デバイスノードキー（DNK）を用いて、EKB（図５）に含まれるキーＫEKBCを得ることができ、そのキーＫEKBCを用いて、データＫEKBC（Kc）（図５）から、コンテンツキーKcを得ることができる。
CPU２１は、さらに、ステップＳ４９において、暗号化復号部２４により復号されたコンテンツデータをコーデック部２５に供給し、デコードさせる。そして、コーデック部２５によりデコードされたデータを、CPU２１は、入出力インタフェース３２から出力部２７に供給し、D/A変換させ、スピーカから出力させる。
ステップＳ４６において、利用権に含まれる使用条件、及び使用状態に基づき、再生が許可されないと判断された場合、コンテンツを出力しないで、処理は終了する。
次に、図７のフローチャートを参照して、図６のステップＳ４３で行われる利用権取得処理の詳細について説明する。
クライアント１は、事前にライセンスサーバに登録することにより、リーフID、DNK(Device Node Key)、クライアント１の秘密鍵・公開鍵のペア、ライセンスサーバの公開鍵、及び各公開鍵の証明書を含むサービスデータを取得しておく。
リーフIDは、クライアント毎に割り当てられた識別情報を表し、DNKは、コンテンツに含まれるEKB（有効化キーブロック）によって暗号化されているコンテンツキーKcを復号するのに必要なデバイスノードキーである（図１０を参照して後述する）。
最初にステップＳ６１において、CPU２１は、コンテンツのヘッダに記述されているURLを取得する。上述したように、このURLは、そのコンテンツを利用するために必要な利用権を取得するときアクセスすべきアドレスである。そこで、ステップＳ６２において、CPU２１は、ステップＳ６１で取得したURLにアクセスする。具体的には、通信部２９によりインターネット２を介してライセンスサーバ４にアクセスが行われる。このとき、ライセンスサーバ４は、クライアント１に対して、利用権のリストを送信するとともに、購入する利用権（コンテンツを使用するのに必要な利用権）を指定する利用権指定情報、並びにユーザIDとパスワードの入力を要求してくる（後述する図９のステップＳ１０２）。CPU２１は、この要求を出力部２７の表示部に表示させる。ユーザは、この表示に基づいて、入力部２６を操作して、利用権指定情報、ユーザID、およびパスワードを入力する。なお、このユーザIDとパスワードは、クライアント１のユーザが、インターネット２を介してライセンスサーバ４にアクセスし、事前に取得しておいたものである。
CPU２１は、ステップＳ６３，Ｓ６４において、入力部２６から入力された利用権指定情報を取り込むとともに、ユーザIDとパスワードを取り込む。CPU２１は、ステップＳ６５において、通信部２９を制御し、入力されたユーザIDとパスワードを、利用権指定情報及びサービスデータ（後述する）に含まれるリーフIDを含む利用権要求をインターネット２を介してライセンスサーバ４に送信させる。
ライセンスサーバ４は、図９を参照して後述するように、ユーザIDとパスワード、並びに利用権指定情報に基づいて利用権を送信してくる（ステップＳ１０９）か、または、条件が満たされない場合には、利用権を送信してこない（ステップＳ１１２）。
ステップＳ６６において、CPU２１は、ライセンスサーバ４から利用権が送信されてきたか否かを判定し、利用権が送信されてきた場合には、ステップＳ６７に進み、その利用権を記憶部２８に供給し、記憶させる。
ステップＳ６６において、利用権が送信されて来ないと判定した場合、CPU２１は、ステップＳ６８に進み、エラー処理を実行する。具体的には、CPU２１は、コンテンツを利用するための利用権が得られないので、コンテンツの再生処理を禁止する。
以上のようにして、各クライアント１は、コンテンツを利用するために必要な利用権を取得して、初めて、そのコンテンツを使用することが可能となる。
なお、図７の利用権取得処理は、各ユーザがコンテンツを取得する前に、予め行っておくようにすることも可能である。
クライアント１に提供される利用権は、例えば、図８に示されるように、使用条件、リーフIDおよび電子署名などを含んでいる。
バージョンは、メジャーバージョンおよびマイナーバージョンをドットで区切って、利用権のバージョンを記述する情報である。
プロファィルは、１０進の整数値から記述され、利用権の記述方法に対する制限を規定する情報である。
利用権IDは、１６進定数で記述される、利用権を識別するための識別情報である。
作成日時は、利用権が作成された日時を示す。
有効期限は、利用権の有効期限を示す。９９９９年２３時５９分５９秒である有効期限は、有効期限に制限がないことを示す。
使用条件には、その利用権に基づいて、コンテンツを使用することが可能な使用期限、その利用権に基づいて、コンテンツを再生することが可能な再生期限、コンテンツの最大再生回数、その利用権に基づいて、コンテンツをコピーすることが可能な回数（許されるコピー回数）、最大チェックアウト回数、その利用権に基づいて、コンテンツをCD-Rに記録することができるか否か、PD（Portable Device）にコピーすることが可能な回数、利用権の移動の可否、使用ログをとる義務の有無等を示す情報が含まれる。
使用条件の電子署名は、使用条件に対応する、電子署名である。
定数は、使用条件または使用状態で参照される定数である。
リーフIDは、クライアントを識別するための識別情報である。
電子署名は、利用権全体に対応する、電子署名である。
証明書は、ライセンスサーバの公開鍵を含む証明書である。
また、クライアント１の記憶部２８には、利用権の使用条件とあわせて、コンテンツや利用権の状態を表す情報である使用状態が記憶される。使用状態には、対応する利用権に基づいてコンテンツを再生した回数、コンテンツをコピーした回数、コンテンツをチェックアウトした回数、コンテンツを初めて再生した日時、コンテンツをCD-Rに記録した回数、その他コンテンツあるいは利用権に関する履歴情報等を示す情報が含まれる。
図６のステップＳ４６の再生の条件の判定は、利用権に含まれる使用条件と、記憶部２８に利用権と共に記憶されている使用状態とを基に行われる。例えば、使用状態に記憶されているコンテンツを再生した回数が、使用条件に含まれるコンテンツ最大再生回数より少ない場合には、再生の条件が満たされていると判定される。
次に、図９のフローチャートを参照して、図７のクライアント１の利用権取得処理に対応して実行されるライセンスサーバ４の利用権提供処理について説明する。
ステップＳ１０１において、ライセンスサーバ４のCPU２１は、クライアント１よりアクセスを受けるまで待機し、アクセスを受けたとき、ステップＳ１０２に進み、アクセスしてきたクライアント１に対して、各利用権に関する情報を含む利用権のリストを送信するとともに、ユーザIDとパスワード、並びに、利用権指定情報の送信を要求する。上述したようにして、クライアント１から、図７のステップＳ６５の処理で、ユーザIDとパスワード、リーフID並びに利用権指定情報（利用権IDであってもよい）が送信されてきたとき、ライセンスサーバ４のCPU２１は、通信部２９を介してこれを受信し、取り込む処理を実行する。
そして、ライセンスサーバ４のCPU２１は、ステップＳ１０３において、通信部２９から課金サーバ５にアクセスし、ユーザIDとパスワードに対応するユーザの与信処理を要求する。課金サーバ５は、インターネット２を介してライセンスサーバ４から与信処理の要求を受けると、そのユーザIDとパスワードに対応するユーザの過去の支払い履歴などを調査し、そのユーザが、過去に利用権の対価の不払いの実績があるか否かなどを調べ、そのような実績がない場合には、利用権の付与を許容する与信結果を送信し、不払いの実績などがある場合には、利用権付与の不許可の与信結果を送信する。
ステップＳ１０４において、ライセンスサーバ４のCPU２１は、課金サーバ５からの与信結果が、利用権を付与することを許容する与信結果であるか否かを判定し、利用権の付与が許容されている場合には、ステップＳ１０５に進み、ステップＳ１０２の処理で取り込まれた利用権指定情報に対応する利用権を、記憶部２８に記憶されている利用権の中から取り出す。記憶部２８に記憶されている利用権は、あらかじめ利用権ID、バージョン、作成日時、有効期限等の情報が記述されている。ステップＳ１０６において、CPU２１は、その利用権に受信したリーフIDを付加する。さらに、ステップＳ１０７において、CPU２１は、ステップＳ１０５で選択された利用権に対応づけられている使用条件を選択する。あるいはまた、ステップＳ１０２の処理で、ユーザから使用条件が指定された場合には、その使用条件が必要に応じて、予め用意されている使用条件に付加される。CPU２１は、選択された使用条件を利用権に付加する。使用条件は利用権にあらかじめ付加されていてもよい。
ステップＳ１０８において、ＣＰＵ２１はライセンスサーバの秘密鍵により利用権に署名し、ライセンスサーバの公開鍵を含む証明書を利用権に添付し、これにより、図８に示されるような構成の利用権が生成される。
次に、ステップＳ１０９に進み、ライセンスサーバ４のCPU２１は、その利用権（図８に示される構成を有する）を、通信部２９からインターネット２を介してクライアント１に送信させる。
ステップＳ１１０においてライセンスサーバ４のCPU２１は、ステップＳ１０９の処理で、いま送信した利用権（使用条件、リーフIDを含む）を、ステップＳ１０２の処理で取り込まれたユーザIDとパスワードに対応して、記憶部２８に記憶させる。さらに、ステップＳ１１１において、CPU２１は、課金処理を実行する。具体的には、CPU２１は、通信部２９から課金サーバ５に、そのユーザIDとパスワードに対応するユーザに対する課金処理を要求する。課金サーバ５は、この課金の要求に基づいて、そのユーザに対する課金処理を実行する。上述したように、この課金処理に対して、そのユーザが支払いを行わなかったような場合には、以後、そのユーザは、利用権の付与を要求したとしても、利用権を受けることができないことになる。
すなわち、この場合には、課金サーバ５から利用権の付与を不許可とする与信結果が送信されてくるので、ステップＳ１０４からステップＳ１１２に進み、CPU２１は、エラー処理を実行する。具体的には、ライセンスサーバ４のCPU２１は、通信部２９を制御してアクセスしてきたクライアント１に対して、利用権を付与することができない旨のメッセージを送信し、処理を終了させる。
この場合、上述したように、そのクライアント１は利用権を受けることができないので、そのコンテンツを利用すること（暗号化されたコンテンツデータを復号し、再生すること）ができないことになる。
本発明においては、図１０に示されるように、ブロードキャストインクリプション（Broadcast Encryption）方式の原理に基づいて、デバイスとキーが管理される。キーは、階層ツリー構造とされ、最下段のリーフ（leaf）が個々のデバイス固有のキーに対応する。本発明のシステムに用いられる階層ツリー構造鍵管理については特許公開2001-352321号公報に記載されている。図１０の例の場合、番号０から番号１５までの１６個のデバイスに対応するキーが生成される。
各キーは、図中丸印で示されるツリー構造の各ノードに対応して規定される。この例では、最上段のルートノードに対応してルートキーKRが、２段目のノードに対応してキーＫ０，Ｋ１が、３段目のノードに対応してキーＫ００乃至Ｋ１１が、第４段目のノードに対応してキーＫ０００乃至キーＫ１１１が、それぞれ対応されている。そして、最下段のノードとしてのリーフ（デバイスノード）に、キーＫ００００乃至Ｋ１１１１が、それぞれ対応されている。
階層構造とされているため、例えば、キーＫ００１０とキー００１１の上位のキーは、Ｋ００１とされ、キーＫ０００とキーＫ００１の上位のキーは、Ｋ００とされている。以下同様に、キーＫ００とキーＫ０１の上位のキーは、Ｋ０とされ、キーＫ０とキーＫ１の上位のキーは、KRとされている。
コンテンツを利用するキーは、最下段のデバイスノード（リーフ）から、最上段のルートノードまでの１つのパスの各ノードに対応するキーで管理される。例えば、番号３のリーフに対応するデバイスにおいて、コンテンツを利用するためのキーは、キーＫ００１１，Ｋ００１，Ｋ００，Ｋ０，KRを含むパスの各キーで管理される。
本発明のシステムにおいては、図１１に示されるように、図１０の原理に基づいて構成されるキーシステムで、デバイスのキーとコンテンツのキーの管理が行われる。図１１の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリースティックなどの半導体メモリを使用する機器のカテゴリ、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、ライセンスを管理するシステムとして本システム（Ｔシステムと称する）が対応する。
すなわち、このＴシステムのノードよりさらに下の階層の２４段のノードに対応するキーにより、サービスプロバイダ、あるいはサービスプロバイダが提供するサービスが対応される。この例の場合、これにより、２24（約１６メガ）のサービスプロバイダあるいはサービスを規定することができる。さらに、最も下側の３２段の階層により、２32（約４ギガ）のユーザ（あるいはクライアント１）を規定することができる。最下段の３２段のノードからＴシステムのノードまでのパス上の各ノードに対応するキーが、DNK（Device Node Key）を構成し、最下段のリーフに対応するIDがリーフIDとされる。
コンテンツを暗号化したコンテンツキーは更新されたルートキーKR'によって暗号化され、上位の階層の更新ノードキーは、その直近の下位の階層の更新ノードキーを用いて暗号化され、ＥＫＢ（図１３および図１４を参照して後述する）内に配置される。ＥＫＢにおける末端から１つ上の段の更新ノードキーはＥＫＢの末端のノードキーあるいはリーフキーによって暗号化され、ＥＫＢ内に配置される。クライアント１は、サービスデータに記述されているＤＮＫのいずれかのキーを用いて、コンテンツデータとともに配布されるＥＫＢ（図１３および図１４）内に記述されている直近の上位の階層の更新ノードキーを復号し、復号して得たキーを用いて、ＥＫＢ内に記述されているさらにその上の階層の更新ノードキーを復号する。以上の処理を順次行うことで、クライアント１は、更新ルートキーKR'を得ることができる。
図１２に階層ツリー構造のカテゴリの分類の具体的な例を示す。図１２において、階層ツリー構造の最上段には、ルートキーKR２３０１が設定され、以下の中間段にはノードキー２３０２が設定され、最下段には、リーフキー２３０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーからなるデバイスノードキー（ＤＮＫ）を保有する。
最上段から第Ｍ段目（図１１の例では、Ｍ＝８）の所定のノードがカテゴリノード２３０４として設定される。すなわち第Ｍ段目のノードの各々が特定カテゴリのデバイス設定ノードとされる。第Ｍ段の１つのノードを頂点としてＭ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとされる。
例えば図１２の第Ｍ段目の１つのノード２３０５にはカテゴリ［メモリースティック（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード２３０５以下が、メモリースティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義される。
さらに、Ｍ段から数段分下位の段をサブカテゴリノード２３０６として設定することができる。図１２の例では、カテゴリ［メモリースティック］ノード２３０５の２段下のノードに、メモリースティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノード２３０６が設定されている。さらに、サブカテゴリノードである再生専用器のノード２３０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード２３０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード２３０８と、［携帯電話］ノード２３０９が設定されている。
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺに、その頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
このように、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
また、ある時点ｔにおいて、デバイス３の所有する鍵Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,KRが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキーＫ００１,Ｋ００,Ｋ０,KRを、それぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Generation）ｔの更新キーであることを示す。
更新キーの配布処理ついて説明する。キーの更新は、例えば、図１３に示す有効化キーブロック（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデータによって構成されるテーブルを、ネットワークを介して、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図１０に示されるようなツリー構造を構成する各リーフ（最下段のノード）に対応するデバイスに、新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Key Renewal Block）と呼ばれることもある。
図１３に示す有効化キーブロック（ＥＫＢ）は、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図１３の例は、図１０に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図１０から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
図１３のＥＫＢに示されるように、ＥＫＢには複数の暗号化キーが含まれる。図１３の最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーＫ００１０によってこの暗号化キーを復号し、更新ノードキーＫ（ｔ）００１を得ることができる。また、復号により得た更新ノードキーＫ（ｔ）００１を用いて、図１３の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）が復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。
以下順次、図１３の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０が得られ、これを用いて、図１３の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒが得られる。
一方、ノードキーＫ０００は更新する対象に含まれておらず、ノード０，１が、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。ノード０，１は、デバイスキーＫ００００，Ｋ０００１を用いて、図１３の上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号することで更新ノードキーＫ（ｔ）００を取得し、以下順次、図１３の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０を得、図１３の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新したキーＫ（ｔ）Ｒを得ることができる。
なお、図１３のインデックスは、図の右側の暗号化キーを復号するための復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
図１０に示すツリー構造の上位段のノードキーＫ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図１４の有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
図１４に示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図１０に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）が、図１４に示されるＥＫＢとともに配布される。この配布により、デバイス４など、その他のグループの機器が復号することができないデータとしての配布が可能となる。
すなわち、デバイス０，１，２はＥＫＢを処理して得たキーＫ（ｔ）００を用いて暗号文を復号すれば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
図１５に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と、図１４に示すＥＫＢとを記録媒体を介して受領したデバイス０の処理を示す。すなわちこの例は、ＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
図１５に示すように、デバイス０は、記録媒体に格納されている世代t時点のＥＫＢと、自分があらかじめ格納しているノードキーＫ０００を用いて、上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、デバイス０は、復号した更新ノードキーＫ（ｔ）００を用いて、更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
図１６に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン６０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは、最新のＥＫＢを識別する機能と、コンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ６０３は、有効化キーブロック（ＥＫＢ）中のデータ部６０６の位置を示すポインタであり、タグポインタ６０４はタグ部６０７の位置、署名ポインタ６０５は署名６０８の位置を示すポインタである。
データ部６０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図１５に示すような更新されたノードキーに関する各暗号化キー等を格納する。
タグ部６０７は、データ部６０６に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図１８を用いて説明する。
図１７では、データとして先に図１３で説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図１７のＢで示す表に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この例の場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはKRとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図１７のＡで示す階層ツリーに示す位置Ｐ０に対応する。次の段のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置Ｐ００に対応する。ツリー構造の所定の位置から見て、その下に、データがある場合は、タグが０、ない場合はタグが１に設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。表Ｂの最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）に対応する位置POの左下の位置POOにはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図１７のＣで示すデータ列、およびタグ列が構成される。
タグは、対応するデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）が、ツリー構造のどこに位置しているのかを示すために設定されるものである。データ部６０６に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）・・・は、単純に暗号化されたキーの羅列データに過ぎないが、上述したタグによってデータとして格納された暗号化キーのツリー上の位置が判別可能となる。上述したタグを用いずに、先の図１５で説明した構成のように、暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（ｔ）００）
・・・のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると、冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
図１６に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Signature）６０８は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センタ（ライセンスサーバ４）、コンテンツロバイダ（コンテンツサーバ３）、決済機関（課金サーバ５）等が実行する電子署名である。ＥＫＢを受領したデバイスは、署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
以上のようにして、ライセンスサーバ４から供給された利用権に基づいて、コンテンツサーバ３から供給されたコンテンツを利用する処理をまとめると、図１８に示されるようになる。
すなわち、コンテンツサーバ３からクライアント１に対してコンテンツが提供されるとともに、ライセンスサーバ４からクライアント１にライセンスが与えられる。クライアント１をライセンスサーバ４に登録した際に供給されるサービスデータと、特定のコンテンツの利用を許可する情報である利用権との組み合わせをライセンスと呼ぶ。コンテンツは、コンテンツキーKcにより、暗号化されており（Enc（Kc，Content））、コンテンツキーKcは、更新ルートキーKR'(EKBから得られるキーであって、図５におけるキーＫEKBCに対応する)で暗号化され（Enc（KR'，Kc））、EKBとともに、暗号化されたコンテンツに付加されてクライアント１に提供される。
図１８の例におけるEKBには、例えば、図２１に示されるように、DNKで復号可能な更新ルートキーKR'が含まれている（Enc（DNK，KR'））。従って、クライアント１は、サービスデータに含まれるDNKを利用して、EKBから更新ルートキーKR'を得ることができる。さらに、更新ルートキーKR'を用いて、Enc（KR'，Kc）からコンテンツキーKcを復号することができ、コンテンツキーKcを用いて、Enc（Kc，Content）からコンテンツを復号することができる。
このように、クライアント１にDNKを各デバイスに割り当てることにより、図１０と図１５を参照して説明した原理に従って、個々のクライアント１のリボーク（revoke）が可能になる。
また、ライセンスリーフIDを付加して配布することにより、クライアント１において、サービスデータと利用権の対応付けが行われることになり、利用権の不正コピーを防止することが可能になる。
また、クライアント用の証明書と秘密鍵をサービスデータとして配信するようにすることで、エンドユーザも、これらを用いて不正コピーを防止可能なコンテンツを作成することが可能になる。
本発明においては、図１１を参照して説明したように、カテゴリノードにライセンスを管理するＴシステムと、各種のコンテンツを利用するデバイスのカテゴリが対応づけられるので、複数のDNKを同一のデバイスに持たせることができる。その結果、異なるカテゴリのコンテンツを１つのデバイスで管理することが可能となる。
図２２は、この関係の一例を表している。すなわち、デバイスＤ１には、Ｔシステムに基づいて、DNK１が割り当てられており、ＥＫＢを含むコンテンツ１を再生することができる。同様に、このデバイスＤ１には、例えば、DNK２が割り当てられており、メモリースティックにCDからリッピングしたコンテンツ２を記録することができる。この場合、デバイスＤ１は、コンテンツ１とコンテンツ２という、異なるシステム（Ｔシステムとデバイス管理システム）により配信されたコンテンツを同時に扱うことが可能となる。新たなDNKを割り当てるとき、既に割り当てられているDNKを削除するなどして、デバイスに１個のDNKだけを対応させるようにした場合、このようなことはできない。
このように、本発明においては、カテゴリ毎に独立したキー管理が可能になる。
また、DNKを、機器やメディアに予め埋め込むのではなく、ライセンスサーバ４により、登録処理を行う際に、各機器やメディアにダウンロードするようにすることで、ユーザによるキーの購入が可能なシステムを実現することができる。
コンテンツとその利用権を別々に配布するシステムにおいては、コンテンツは、それが作成された後、どのような使われ方をされようとも、その使われ方に関わりなく、全ての用途において、使用可能であるのが望ましい。例えば、異なるコンテンツ配信サービス、あるいは用途が異なる場合においても、同一のコンテンツが使えることが望ましい。本発明においては、このため、上述したように、各ユーザ（クライアント１）に、認証局としてのライセンスサーバ４から秘密鍵と、それに対応する公開鍵の証明書（certificates）が配布される。各ユーザは、その秘密鍵を用いて、署名（signature）を作成し、コンテンツに付加して、コンテンツの真正さ(integrity)を保証し、かつコンテンツの改竄防止を図ることができる。
クライアント１は、コンテンツを利用する前に、ライセンスサーバ４にアクセスし、利用権を取得する必要がある。ライセンスサーバ４は、クライアント１からアクセスを受けたとき、利用権を提供するのであるが、その前にコンテンツホルダサーバ６からコンテンツに関するプロダクト情報を取得する必要がある。次に、図２１と図２２のフローチャートを参照して、この場合の処理について説明する。
コンテンツホルダサーバ６のCPU２１は、ステップＳ２０１において、コンテンツのプロダクト情報を作成する。ステップＳ２０２において、CPU２１は、ステップＳ２０１で作成したプロダクト情報を、通信部２９を介してライセンスサーバ４に送信する。
以上のコンテンツホルダサーバ６の処理に対応して、ライセンスサーバ４は、図２２のフローチャートに示される処理を実行する。
すなわち、ステップＳ３０１において、ライセンスサーバ４のCPU２１は、コンテンツホルダサーバ６から送信されてきた（図２１のステップＳ２０２の処理で送信されてきた）プロダクト情報を受信する。ステップＳ３０２において、CPU２１は、ステップＳ３０１の処理で受信したプロダクト情報を記憶部２８に供給し、記憶させる。その後、ステップＳ３０３において、CPU２１は、ステップＳ３０２の処理で登録したプロダクト情報（使用条件）を分割する処理を実行する。
例えば、コンテンツホルダサーバ６から送信されてきたプロダクト情報が図２３に示されるような内容であったとする。図２３の例においては、ユーザが３５０円の対価を支払った場合には、対応するコンテンツを、回数と期間の制限なく、再生することが可能となる。
これに対して、ユーザが１００円の対価を支払った場合には、回数は制限ないが、期間は１ヶ月のみとされ、その間、ユーザはコンテンツを再生することが許容される。
ユーザは、さらに５０円を追加的に支払った場合には、３回だけチェックアウトが許容される。さらに５０円の対価が支払われた場合には、１回だけ、１０日間の間、コピーをすることが許容される。この場合におけるコピー先での再生は、対価の支払いは必要ないが（対価は０円であるが）、回数は１０回に限られ、期間は１日に限られている。
ライセンスサーバ４は、図２３に示されるようなプロダクト情報をコンテンツホルダサーバ６から受け取ったとき、このプロダクト情報を、例えば、図２４に示されるように分割する。
図２４の例においては、プロダクト情報は３つに分割されている。第１のプロダクト情報は、ユーザが３５０円の対価を支払った場合のものであり、その内容は、再生回数と再生期間が無限とされている。
第２のプロダクト情報は、ユーザが１５０円の対価を支払った場合のものであり、再生回数は無限であるが、再生期間は、YY年MM月DD日までとされ、チェックアウトの回数は３回まで許容される内容となっている。
第３番目のプロダクト情報は、対価は０円とされ、その内容はコピー先の使用条件を規定するものであり、再生回数は１０回とされ、再生期間は１日とされている。
この第３番目のプロダクト情報は０円であるので、第２番目のプロダクト情報に付随して配布される。
このように、ライセンスサーバ４は、コンテンツホルダサーバ６から許容されたプロダクト情報に記載されている使用条件の範囲内において、その使用条件を複数の使用条件に分割し、分割された使用条件を含む利用権として、クライアント１に対して提供することができる。
次に、図２５のフローチャートを参照して、図２２のステップＳ３０３のプロダクト情報（使用条件）分割処理の具体的な例について説明する。
なお、図２５の処理は、コンテンツホルダサーバ６から提供され、ライセンスサーバ４の記憶部２８に記憶されているプロダクト情報に含まれる使用条件が、例えば、図２６に示されるような内容である場合において、この使用条件から、再生だけを許容する使用条件として分割する処理の例を表している。
図２６の例においては、再生回数は３回とされ、チェックアウト回数も３回とされている。そして、再生開始日は２００１年１２月１日とされ、終了日は２００２年２月２８日とされている。
ステップＳ３２１において、CPU２１は、コンテンツホルダサーバ６から受信し、記憶部２８に記憶したプロダクト情報のXML（Extensible Markup Language）で記述されているRule部から、「playback」の要素を検索する。
次に、ステップＳ３２２において、CPU２１は、「playback」が存在したか否かを判定する。「playback」が存在した場合には、ステップＳ３２３に進み、CPU２１は、期間制限オプション(timespan_id)から期間を抽出する。図２６の例においては、２００１年１２月１日から２００２年２月２８日までの期間が抽出される。
次に、ステップＳ３２４において、CPU２１は、ステップＳ３２３の処理で抽出された期間のdate_start（開始日）とdate_end（終了日）を、それぞれ再生可能開始日を表す変数resp及び再生可能終了日を表すreepに代入する。
ステップＳ３２５において、CPU２１は、ステップＳ３２４の処理に基づいて生成されたデータに基づいて、分割された使用条件を作成する。これにより、例えば、図２７に示されるような使用条件が作成される。
図２７の例においては、２００１年１２月１日から２００２年２月２８日までの期間、コンテンツが使用可能とされている。
ステップＳ３２６において、CPU２１は、ステップＳ３２５の処理で作成した使用条件と、プロダクト情報に含まれるコンテンツ条件、利用権ID等を組み合わせ、バージョン、有効期限等を追加した利用権を生成し、生成された利用権を記憶部２８に登録する。
ステップＳ３２２において、「playback」のテキストが存在しないと判定された場合には、ステップＳ３２３乃至ステップＳ３２６の処理はスキップされる。
次に、図２８のフローチャートを参照して、図２２のステップＳ３０３の使用条件分割処理の他の例について説明する。
この例は、図２６に示されるような使用条件がコンテンツホルダサーバ６からライセンスサーバ４に提供された場合において、再生の使用条件と、チェックアウトの使用条件の、合計２つの使用条件を分割、生成する場合の処理例を表している。
ステップＳ３４１乃至Ｓ３４５において、図２５のステップＳ３２１乃至ステップＳ３２５における場合と同様の処理が実行される。これにより、上述したように、再生の使用条件を含む利用権が分割、生成される。
なお、ステップＳ３４２において、「PLAYBACK」の要素が検索されなかったと判定された場合、ステップＳ３４３乃至ステップＳ３４５の処理はスキップされ、処理はステップＳ３４６に進む。
次に、ステップＳ３４６において、CPU２１は、XMLで記述されたRule部（図２６）から「checkout」の要素を検索する。ステップＳ３４７において、CPU２１は、「checkout」が存在したか否かを判定し、存在した場合には、ステップＳ３４８に進み、XMLのRule部から回数を読み出す。図２６の例の場合、回数として３回が読み出される。
ステップＳ３４９において、CPU２１は、ステップＳ３４８で読み出された回数を、最大チェックアウト回数を表す変数reccに代入する。そして、ステップＳ３５０において、CPU２１は、ステップＳ３４９の処理で生成されたデータを元に、分割された使用条件を作成する。ステップＳ３５１において、CPU２１は、ステップＳ３４５またはステップＳ３５０で作成された使用条件を含む利用権を生成し、記憶部２８に登録する処理を実行する。
ステップＳ３４７において、「checkout」が存在しないと判定された場合、ステップＳ３４８乃至ステップＳ３５０の処理はスキップされる。
このようにして、図２９に示されるような再生の使用条件を含む利用権とチェックアウト回数が３回である使用条件を含む利用権が生成される。
以上のようにして、ライセンスサーバ４がコンテンツホルダサーバ６から提供を受けた使用条件を、分割、管理するようにすることで、クライアント１は、大きな使用条件を取り扱う負担を強いられることなく、利用権を容易に管理することが可能となる。
また、利用権に含まれている使用条件をアップグレードさせることができる。この場合の処理について、図３０を参照して説明する。
すなわち、図３０の例においては、コンテンツホルダサーバ６が生成したコンテンツに対する利用権として、そのコンテンツの再生、チェックアウト、および購入を規定する１つの利用権を生成し、これをライセンスサーバ４に提供する。
ライセンスサーバ４は、この１つの利用権を、再生だけができる利用権、並びに再生とチェックアウトができる利用権の２つの利用権に分割する。
クライアント１は、例えば、１０円を支払うことにより、再生だけの利用権を取得することができる。そして、その後、クライアント１は、さらに３０円を支払うことにより、再生だけでなく、さらにチェックアウトの権利が付加された利用権を取得することができる。すなわち、再生だけの利用権から、再生とチェックアウトを含む利用権に、クライアント１は利用権をアップグレードすることができる。
この場合において、クライアント１は、利用権の状態が、１０円を支払った状態と、さらに３０円を支払った状態とがあるということを管理している必要はない。クライアント１は、ただ単に、新たな利用権を購入するだけでよい。換言すれば、クライアント１から見れば、再生の利用権と、再生とチェックアウトの利用権とは、全く独立した別の利用権として取り扱えばよいことになる。
この場合の処理を、さらに図３１と図３２を参照して説明する。図３１は、ライセンスサーバ４がコンテンツホルダサーバ６から提供を受けたプロダクト情報の使用条件の概要を表している。この例では、Usage Rule IDが１とされ、１０円の支払いが行われた場合、再生が許容されるルールと、２０円の支払いがなされた場合には、再生とチェックアウトが許容されるルールが記述されている。
このような場合において、ライセンスサーバ４が図３１に示される１つの使用条件を、再生だけの使用条件と、再生とチェックアウトを許容する使用条件の２つに分割し、それぞれに対応する利用権を生成したとする。
この場合、図３２に示されるように、クライアント１がステップＳ３７１で、ライセンスサーバ４に対して１０円を支払った場合、（なお、詳細な説明は省略するが、具体的な課金処理は、課金サーバ５により行われる。以下同様）ステップＳ３７２において、ライセンスサーバ４は、クライアント１に対して再生の利用権（Usage Right）を付与する。この場合の処理は、購入処理と同様となる。
その後、ステップＳ３７３において、クライアント１がライセンスサーバ４に対して、さらに２０円の支払いを許諾する情報を送信し、ステップＳ３７４において、クライアント１のリーフIDと、ステップＳ３７２で取得した利用権のIDを、ライセンスサーバ４に対して送信すると、ステップＳ３７５において、ライセンスサーバ４は、再生とチェックアウトの内容を含む利用権を、クライアント１に配布する。この処理は、アップグレード処理である。
なお、ステップＳ３７２でクライアント１に付与される利用権IDと、ステップＳ３７５の処理でクライアント１に付与される利用権IDは、同一である。すなわち、この利用権IDは、図３１に示されるライセンスサーバ４がコンテンツホルダサーバ６から提供を受けた利用権のIDと対応している。
換言すれば、分割されてはいるが、２つの利用権は同一のプロダクト情報に含まれる使用条件から派生したものである。
図３３は、クライアント１がライセンスサーバ４から利用権を取得する場合における表示例を表している。ステップＳ３９１において、クライアント１がリーフIDをライセンスサーバ４に送信するとともに、既に利用権を取得している場合には、そのIDをライセンスサーバ４に送信する。
ライセンスサーバ４は、クライアント１に対して、購入可能な権利のリストと対応する値段が記述されたドキュメントを、クライアント１に送信する。クライアント１のCPU２１は、これを通信部２９を介してこれを受信すると、出力部２７のモニタに出力し、表示させる。
図３３の例においては、購入可能な権利として、３回のチェックアウトを可能にする１００円の利用権、既に取得されているコンテンツを自分のものにする１５０円の利用権、並びに既に取得している利用権を他人にコピーしてあげる１０円の利用権の、３種類の利用権が表示されている。
クライアント１が保持する利用権は、クライアント１が支払った対価に応じて、変化するのであるが、いま、ライセンスサーバ４にアクセスしてきたクライアント１が、いずれの状態の利用権を取得しているのかは、ライセンスサーバ４が管理している。従って、クライアント１のリーフIDとクライアント１が保持している利用権のIDに基づいて、ライセンスサーバ４のCPU２１は、アクセスしてきたクライアント１に対応するメニュー（購入可能な権利の内容）を表示させることができる。
なお、図３３の表示例においては、「佐藤さん、いらっしゃいませ。」のメッセージも同時に表示されている。アクセスしてきたクライアント１のユーザが誰であるのかは、ユーザを登録する処理を行った場合に、ユーザ名を登録しているので、リーフIDに対応するユーザの氏名をデータベースから検索することで、表示することが可能となる。
あるいは、また、cookieを利用して氏名を表示させるようにすることも可能である。
ステップＳ３９２で、クライアント１が、メニュー表示に従い利用権の購入手続を行い、利用権に対する対価の支払の処理を行うと、ステップＳ３９３において、ライセンスサーバ４からクライアント１に、対価に対応する利用権（Usage Right）が配布される。
次に、図３４を参照して、ライセンスサーバ４において行われる購入履歴の管理について説明する。
図３４の例においては、コンテンツホルダサーバ６が１つのプロダクト情報をライセンスサーバ４に供給する。このプロダクト情報は、２００円の対価によって取得することが可能なUsage Rules１、さらに１００円を支払って取得することが可能なUsage Rules２、さらに５０円を支払うことにより取得可能なUsage Rules３、並びにUsage Rules２を有するユーザがさらに３０円を支払うことにより取得することが可能なUsage Rules４、により構成されている。
ライセンスサーバ４は、コンテンツホルダサーバ６からこのプロダクト情報を取得すると、Usage Rules１乃至Usage Rules４を分割する。そして、ライセンスサーバ４は、状態テーブルとして、Usage Rules１乃至Usage Rules４に対応した利用権購入状態のレコードをLeafID、利用権ごとに生成、管理する。
すなわち、このテーブルでは、Usage Rules１乃至Usage Rules４をそれぞれ有する状態が、状態１乃至状態４とされ、これらのいずれをも有していない状態が状態０とされる。
このように、利用権所持の状態は、ライセンスサーバ４により管理されているので、クライアント１が管理する必要はない。従って、クライアント１の負荷が軽減される。
すなわち、クライアント１は、Usage Rules１乃至Usage Rules４のうちのいずれか１つを適宜購入するだけでよい。
例えば、クライアント１のユーザは、２００円を支払うことで、Usage Rules１を含む利用権を取得することができ、さらに１００円を追加的に支払うことで、Usage Rules２を含む利用権を取得することができる。
クライアント１がいずれの利用権を取得する場合においても、同一のプロトコルを使用することが可能であるが、利用権の内容に応じて、使用するプロトコルを変更することも可能である。次に、この使用権に応じて、プロトコルを変更する例について説明する。
この実施の形態では、図３５に示されるように、ライセンスサーバ４からクライアント１に対して、利用権を配布するプロトコルには、簡易購入プロトコルと権利更新プロトコルの２種類が用意される。簡易購入プロトコルは、特殊な認証が不要とされるプロトコルであり、権利更新プロトコルは、特殊な認証が必要とされるプロトコルである。すなわち、権利更新プロトコルは、簡易購入プロトコルに比べて、よりセキュアな環境化での通信が行われるものである。
簡易購入プロトコルにおいては、利用権は、ライセンスサーバ４からクライアント１に対して、単にダウンロードされる。これに対して、権利更新プロトコルにおいては、ライセンスサーバ４がクライアント１が有する利用権を更新する処理を実行するため認証処理が行われる。
次に、図３６のフローチャートを参照して、クライアント１がライセンスサーバ４から、利用権の内容に応じて、異なるプロトコルで利用権を取得する処理について説明する。
ステップＳ４６１において、クライアント１のCPU２１は、ライセンスサーバ４にアクセスする。ステップＳ４１２において、CPU２１は、ユーザからの指令に基づいて、ユーザが希望する利用権に関する情報を通信部２９を介してライセンスサーバ４に送信する。
図３７のフローチャートを参照して後述するように、クライアント１が希望するのが、サブスクリプションサービスの利用権である場合には、ライセンスサーバ４からAKE(Authentication Key Exchange)処理が要求されてくる（図３７のステップＳ４４８）。これに対して、取得する利用権がサブスクリプションサービスの利用権ではない場合（買い取り用、または試聴用である場合）には、AKE処理が要求されてこない。そこで、ステップＳ４１３において、CPU２１は、ライセンスサーバ４からAKE処理が要求されたか否かを判定し、AKE処理が要求されてこない場合には、ステップＳ４１４に進み、記憶部２８に記憶されているリーフIDを読み出し、通信部２９を介してライセンスサーバ４に送信させる。
このとき、ライセンスサーバ４は、クライアント１が希望した利用権に、それに対応するデジタル署名を付加してクライアント１に送信してくる（図３７のステップＳ４４７）。そこで、ステップＳ４１５において、クライアント１のCPU２１は、クライアントサーバ４から送信されてきた利用権とデジタル署名を受信する。ステップＳ４１６において、CPU２１は、ステップＳ４１５で受信したデジタル署名をライセンスサーバ４の公開鍵SPで復号する。このライセンスサーバの公開鍵SPは、リーフIDとともに、登録処理において、取得され、記憶部２８に記憶されているものである（図６のステップＳ５３）。
ステップＳ４１７において、CPU２１は、ステップＳ４１５の処理で受信した利用権は、ステップＳ４１６の処理でデジタル署名を復号して得られた利用権と一致するか否かを判定する。両者が一致する場合には、適正な（改竄されていない）利用権であるので、CPU２１は、ステップＳ４１８において、その利用権を記憶部２８に記憶させる。
それに対して、２つの利用権が一致しない場合には、正しい利用権ではないので、ステップＳ４２６に進み、CPU２１は、エラー処理を実行する。
一方、ステップＳ４１３において、AKE処理が要求されたと判定された場合、ステップＳ４１９に進み、CPU２１は、ライセンスサーバ４との間でAKE処理を実行する。すなわち、これにより、よりセキュアな通信路を確保する処理が実行され、セッション鍵が共有される。
ステップＳ４２０において、CPU２１は、AKE処理により、SAC(Secure Authentication Channel)が形成できたか否か（セキュアな通信路が確保できたか否か）を判定する。SACが形成できたと判定された場合には、ステップＳ４２１において、CPU２１は、記憶部２８に記憶されているリーフIDを、AKE処理により確保されたセッション鍵で暗号化して、通信部２９からインターネット２を介して、ライセンスサーバ４に送信する。
この場合、ライセンスサーバ４からセッション鍵で暗号化された使用鍵とデジタル署名が、クライアント１に送信されてくる（後述する図３７のステップＳ４５４）。そこで、ステップＳ４２２において、クライアント１のCPU２１は、セッション鍵で暗号化されている利用権とデジタル署名を受信し、ステップＳ４２３において、暗号化された利用権を、ステップＳ４１９のAKE処理で取得したセッション鍵で復号する。
ステップＳ４２４において、CPU２１は、ステップＳ４２２の処理で受信したデジタル署名を、ライセンスサーバ４の公開鍵SPで復号する。ステップＳ４２５において、CPU２１は、ステップＳ４２３の処理で復号して得られた利用権と、ステップＳ４２４の処理で復号して得られた利用権とが、一致するか否かを判定する。両者が一致する場合には、正しい利用権であることが確認できたので、ステップＳ４１８に進み、CPU２１は、得られた利用権を記憶部２８に記憶する。
ステップＳ４２５の処理において、２つの利用権が一致しないと判定された場合、得られた利用権が正しいものではない（例えば、改竄されたものである）恐れがあるので、ステップＳ４２０において、SACが形成できなかったと判定された場合と同様に、ステップＳ４２６に進み、エラー処理が実行される。
以上のクライアント１の利用権取得処理に対応して実行されるライセンスサーバ４の利用権配布処理について、図３７のフローチャートを参照して説明する。
ステップＳ４４１において、ライセンスサーバ４のCPU２１は、クライアント１からのアクセスを受け付ける。ステップＳ４４２において、CPU２１は、クライアント１からの利用権に関する情報を受信する。この利用権に関する情報は、図３６のステップＳ４１２の処理により、クライアント１から送信されてきたものである。
ステップＳ４３４において、ライセンスサーバ４のCPU２１は、クライアント１が希望するサービスに対応する利用権の情報を記憶部２８から取得する。
ステップＳ４４４において、CPU２１は、クライアント１が希望している利用権は、サブスクリプションサービスの利用権のものであるか否かを判定する。利用権がサブスクリプションサービスの利用権でない場合（買い取り用または試聴用のものである場合）には、特に、セキュアな環境化で通信を行う必要がない。このとき、クライアント１からリーフIDが送信されてくる（図３６のステップＳ４１４）。そこで、ステップＳ４４５において、ライセンスサーバ４のCPU２１は、クライアント１から送信されてきたリーフIDを受信し、そのリーフIDをクライアント１が希望する利用権に挿入する。
ステップＳ４４６において、CPU２１は、ライセンスサーバ４の秘密鍵を用いて、ステップＳ４４５の処理でリーフIDを挿入した利用権のデジタル署名を作成する。
次に、ステップＳ４４７において、CPU２１は、ステップＳ４４５の処理でリーフIDを挿入した利用権と、ステップＳ４４６の処理で作成したデジタル署名とを、クライアント１に送信する。
このようにして、送信した利用権とデジタル署名が、図３６のステップＳ４１５において、クライアント１により受信されることになる。
一方、ステップＳ４４４において、クライアント１が希望している利用権がサブスクリプションサービスの利用権である（買い取り用または試聴用ではない）と判定された場合、よりセキュアな環境化で通信を行う必要がある。そこで、ステップＳ４４８に進み、CPU２１は、クライアント１に対してAKE処理を要求し、AKE処理を実行する。
ステップＳ４４９において、CPU２１は、SACが形成できたか否かを判定する。SACが形成できた場合には、ステップＳ４５１に進み、CPU２１は、クライアント１が希望する利用権に使用状態（Usage Status）を付加する。ステップＳ４５２において、CPU２１は、クライアント１が希望する利用権にリーフIDを挿入し、ステップＳ４４８のAKE処理で得られたセッション鍵で暗号化する。
ステップＳ４５３において、CPU２１は、自分自身の秘密鍵を用いて、ステップＳ４５２の処理でリーフIDが挿入され、セッション鍵で暗号化された利用権のデジタル署名を作成する。
ステップＳ４５４において、CPU２１は、ステップＳ４５２の処理でセッション鍵で暗号化された利用権と、ステップＳ４５３の処理で作成されたデジタル署名とを、クライアント１に送付する。
このようにして、送付された利用権とデジタル署名は、上述したように、クライアント１により、ステップＳ４２２において受信される。
ステップＳ４４９において、SACが形成できなかったと判定された場合には、セキュアな通信路が確保できなかったので、ステップＳ４５０に進み、エラー処理が実行される。
すなわち、この場合には、利用権は、クライアント１に対して配布されないことになる。
よりセキュアな状態での利用権の配布を望まないユーザは、そのための機能を設ける必要がないので、ユーザに必要以上の負担をかけることなく、利用権を配布することが可能となる。また、セキュアな環境下での利用権の取得を希望するユーザに対しては、より安全に利用権を配布することが可能となる。その結果、利用権が第３者に盗用されるようなことが防止される。
以上のようにして、コンテンツと利用権を得たクライアント１は、利用権に基づいて、コンテンツを使用する（例えば、再生する）処理を実行する。
次に、この場合の処理について、図３８のフローチャートを参照して説明する。
ステップＳ４７１において、クライアント１のCPU２１は、ライセンスサーバ４にアクセスする。ステップＳ４７２において、CPU２１は、ライセンスサーバ４との間でAKE処理を実行する。
ステップＳ４７３において、CPU２１は、SACが形成できたか否かを判定する。SACが形成できた場合には、ライセンスサーバ４から使用状態、リーフID、およびコンテンツ情報の送信を要求してくる（後述する図３９のステップＳ４９５）。
そこで、ステップＳ４７５において、クライアント１のCPU２１は、ライセンスサーバ４からのこの要求を受信する。この要求は、ステップＳ４７２のAKE処理で得られたセッション鍵で暗号化されている。そこで、CPU２１は、ステップＳ４７２のAKE処理で得られたセッション鍵を用いて、この要求を復号する。
ステップＳ４７６において、CPU２１は、この要求に基づいて、これから使用する利用権に対応する使用状態、リーフID、およびコンテンツ情報を、セッション鍵で暗号化して、ライセンスサーバ４に送信する。
この送信に対応して、ライセンスサーバ４から更新した使用状態を、セッション鍵で暗号化して送信してくる（図３９のステップＳ４９８）。
そこで、ステップＳ４７７において、クライアント１のCPU２１は、ライセンスサーバ４から送信されてきた、更新された使用状態を受信し、セッション鍵で復号し、記憶部２８に記憶する。例えば、利用権に使用回数の条件が含まれているような場合、クライアント１がこれからコンテンツを再生するので、使用回数は１回インクリメントされた値に更新されていることになる。そして、ステップＳ４７８において、CPU２１は、コンテンツを再生する処理を実行する。
このように、使用状態がクライアント１ではなく、ライセンスサーバ４により管理されるので、利用権がクライアント１において改竄され、コンテンツが不正に利用されるようなことが防止される。
また、ライセンスサーバ４は、必要に応じて、使用状態を適宜書き換えることで、所定のユーザに対して、コンテンツの利用を適宜禁止させたり、柔軟なサービスの提供を行うことが可能となる。
また、ライセンスサーバ４からクライアント１が保持する利用権の使用状態を制御することができるため、使用を許可する回数の増減、コンテンツ毎の無効化、サービス自体の停止などを、ライセンスサーバ４が適宜行うことが可能となる。
ステップＳ４７３において、SACが形成できなかったと判定された場合、ステップＳ４７４に進み、エラー処理が実行される。
以上のクライアント１の利用権使用処理に対応して実行されるライセンスサーバ４の処理について、図３９のフローチャートを参照して説明する。
ステップＳ４９１において、ライセンスサーバ４のCPU２１は、クライアント１からのアクセスを受け付ける。ステップＳ４９２において、CPU２１は、クライアント１との間でAKE処理を実行する。ステップＳ４９３において、CPU２１は、AKE処理の結果、SACが形成できたか否かを判定する。
SACが形成できた場合には、ステップＳ４９５に進み、CPU２１は、クライアント１に対して、使用状態、リーフID、およびコンテンツ情報の送信を要求する。この要求は、ステップＳ４９２のAKE処理で得られたセッション鍵で暗号化して、クライアント１に送信される。上述したように、この要求は、クライアント１において、ステップＳ４７５の処理で受信され、ステップＳ４７６の処理でその要求に対応した情報がクライアント１から送信されてくる。
そこで、ステップＳ４９６において、ライセンスサーバ４のCPU２１は、クライアント１から送信されてきた使用状態、リーフID、およびコンテンツ情報を受信する。これらの情報は、セッション鍵で暗号化されているので、CPU２１は、ステップＳ４９２のAKE処理で得られたセッション鍵を用いて、これらの情報を復号する。
ステップＳ４９７において、CPU２１は、クライアント１から送信されてきた使用状態をコンテンツ情報に基づいて更新する。例えば、これからコンテンツが使用される場合には、その使用回数を１回だけインクリメントした値に変更させる。あるいは、そのコンテンツを以後使用禁止にする場合には、CPU２１は、使用回数をもはや使用できない回数に変更する。
ステップＳ４９８において、CPU２１は、ステップＳ４９７の処理で更新した使用状態をセッション鍵で暗号化して、クライアント１に送信する。
この使用状態が上述したように、クライアント１において、ステップＳ４７７において、受信される。
ステップＳ４９３の処理でSACが形成できなかったと判定された場合には、ステップＳ４９４に進み、エラー処理が実行される。
使用条件を記述する場合、フラグや値のみで記述すると、その値の意味をクライアント１が全て知っている必要がある。このため、条件項目をライセンスサーバ４が追加することが困難になる。
また、逆に、使用条件をフレキシブルに記述することを許容すると、クライアント１において、ユーザに対して、使用条件をどのように表現するか難しくなる。
そこで、コンテンツの使用条件を、関係式と論理式のみからなる条件式で記述することにより、クライアント１において、各項目のフォーマットをあらかじめ規定しておく必要がなく、様々な使用条件の記述に対応することができるようにすることができる。このため、クライアント１における実装によらずに、使用条件を記述することが可能となる。
また、クライアント１の処理能力等によって、Usage Rulesの記述に制限を設けるようにすることで、クライアント１において、容易にルールの意味を解釈できるようにすることができる。以下、この例について説明する。
Usage Rulesは、コンテンツの使用条件を規定するものであり、上述したように、ユーザ（クライアント１）が購入する利用権(Usage Right)に含まれる。Usage Rulesで規定できるものには、以下のようなものがある。
コンテンツの再生回数
コンテンツの使用期限
コンテンツのチェックアウト回数
その他
これらの条件は、専用の記述言語で記述し、バイトコードにコンパイルして、Usage Rightに格納される。
基本的な記述方法は、図４０に示されるような形式となる。すなわち、各ドメイン、つまりコンテンツの利用形態のカテゴリ、に対して、Usage Ruleが記述される。
１つのUsage Ruleは、図４１に示されるような形式で記述される。
１つのUsage Ruleは、先頭に記述するdomain_idで、それを適用するドメインを規定する。さらに、それに続く'｛'・・・'｝'内に、各種ルールが規定されるが、その中は、ルールセクション、invariablesセクション、およびoverhead partの３つのセクションに分かれる。
ルールセクションは、'｛'・・・'｝'の先頭で、複数のdomain_ruleを記述することができる。invariablesセクションは、ルールセクションに続き、キーワード'invariables:'によって始まる部分である。overhead partは、invariablesセクションに続く部分であり、'over_head_part:'によって始まる。
domain_idは、ドメインを示す名称であり、以下の文字列のうちのいずれかである。
drm
renderer
ripper
burner
lcm_1
lcm_2
lcm_3
rendererドメインはコンテンツの再生、表示等の利用形態のカテゴリ、ripperドメインはCDのコンテンツの読み出しの利用形態のカテゴリ、burnerドメインはコンテンツのCD-Rへの記録の利用形態のカテゴリ、drmドメインは全ての利用形態のカテゴリをそれぞれ表している。
domain_ruleは、
'｛'＜条件式＞'｝'の形式で記述される。
各ルールの前には、以下の形式でルール番号を指定することができる。
'［'＜ルール番号＞'］'｛'＜条件式＞'｝'
ルール番号を指定する場合には、次のように、複数の番号を指定することが可能である。
［１］'｛'＜条件式＃１＞'｝'
［２］'｛'＜条件式＃２＞'｝'
条件式は、各ドメインの状態変数や定数などを参照するためのChars Code（ＣＣ）に対して、比較演算を施したものである。その記述例は、例えば、次のようになる。
！'ee' and ！'pp'
！'ee' and （'cid ＞ 'pp'）
利用できる演算子には、図４２に示されるようなものあがる。
図４２における２項演算子の演算優先順位は、弱い順に、or, and,その他の演算子となる。どの演算子も左結合である。
invariablesセクションは、各種定数を記述する部分であり、次の形式でChars Codeに値を定義する。
＜Chars Code＞'＝' ＜値＞'；'
複数のinvariablesを定義する場合には、次に示されるように、'，'で区切って記述が行われる。
＜Chars Code＞'＝'＜値＞'，'＜Chars Code＞'＝'＜値＞・・・'；'
＜Chars Code＞は、その名称と意味があらかじめ規定されている。
overhead partは、各ドメイン毎の独自のルールを記述する部分である。
Char CodeはUsage Rulesのinvariablesセクション内で定義される以外に、利用権、コンテンツ、使用状態等の中で定義されていても良い。
以上のルール記述言語で記載された例が図４３に示されている。
なお、上述したコンテンツサーバ３、ライセンスサーバ４、課金サーバ５、並びにコンテンツホルダサーバ６のいずれか２つ以上は、必要に応じて実質的に１つのサーバに統合させることも可能である。
また、本実施の形態では、暗号化されたコンテンツを復号するための鍵情報はコンテンツに含まれているが、利用権に鍵情報を含む、あるいはコンテンツに含まれる鍵情報と利用権に含まれる鍵情報とを組み合わせることで復号可能となるようにしても良い。
本発明が適用されるクライアントは、いわゆるパーソナルコンピュータ以外に、PDA（Personal Digital Assistants）、携帯電話機、ゲーム端末機などとすることができる。
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
この記録媒体は、図２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フレキシブルディスクを含む）、光ディスク４２（CD-ROM(Compact Disk - Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）（商標）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、セキュリティに関連する処理を実行させるプログラムは、その処理を解析されるのを防ぐため、そのプログラム自体が暗号化されているのが望ましい。例えば、暗号処理などを行う処理については、そのプログラムをタンパーレジスタントモジュールとして構成することができる。
また、上記実施の形態では、コンテンツを利用するために必要な利用権を特定するためにコンテンツの属性と利用権のコンテンツ条件を用いたが、これに限らない。例えば、コンテンツに、該コンテンツを利用するために必要な利用権の利用権IDを含むようにしても良く、この場合、コンテンツを指定すればそれを利用するために必要な利用権は一意に決まるため、両者のマッチングを決定する処理を行う必要はない。
本発明を適用したコンテンツ提供システムの構成を示す図である。 図１のライセンスサーバの構成を示すブロック図である。 図１のクライアントのコンテンツのダウンロード処理を説明するフローチャートである。 図１のコンテンツサーバのコンテンツ提供処理を説明するフローチャートである。 図４のステップＳ２６におけるフォーマットの例を示す図である。 図１のクライアントのコンテンツ再生処理を説明するフローチャートである。 図６のステップＳ４３の利用権取得処理の詳細を説明するフローチャートである。 利用権の構成を示す図である。 図１のライセンスサーバの利用権提供の処理を説明するフローチャートである。 キーの構成を説明する図である。 カテゴリノードを説明する図である。 ノードとデバイスの対応の具体例を示す図である。 有効化キーブロックの構成を説明する図である。 有効化キーブロックの構成を説明する図である。 有効化キーブロックの利用を説明する図である。 有効化キーブロックのフォーマットの例を示す図である。 有効化キーブロックのタグの構成を説明する図である。 DNKを用いたコンテンツの復号処理を説明する図である。 有効化キーブロックの例を示す図である。 複数のコンテンツの１つのデバイスに対する割り当てを説明する図である。 ライセンスのカテゴリを説明する図である。 図１のコンテンツホルダサーバの利用権提供処理を説明するフローチャートである。 図１のライセンスサーバの利用権取得処理を説明するフローチャートである。 図１のコンテンツホルダサーバが提供する利用権の例を示す図である。 図２３の利用権を分割した例を示す図である。 図２２のステップＳ３０３の利用権分割処理の例を示すフローチャートである。 図２２のステップＳ３０２において登録される利用権の例を示す図である。 図２６の利用権から分割された利用権の例を示す図である。 図２２のステップＳ３０３の利用権分割処理の他の例を示すフローチャートである。 図２８のステップＳ３５１の処理で登録される利用権の例を示す図である。 利用権の分割を説明する図である。 図１のコンテンツホルダサーバからライセンスサーバに提供される利用権の例を示す図である。 利用権の購入とアップグレードの処理を説明するフローチャートである。 利用権分割の処理における表示例を示す図である。 図１のライセンスサーバにおける使用状態の管理を説明する図である。 複数のプロトコルを説明する図である。 図１のクライアントの利用権取得処理を説明するフローチャートである。 図１のライセンスサーバの利用権配布処理を説明するフローチャートである。 図１のクライアントの利用権使用処理を説明するフローチャートである。 図１のライセンスサーバの使用状態更新処理を説明するフローチャートである。 Usage Rulesの基本的な記述方法を説明する図である。 UsageRuleの記述形式の例を示す図である。 演算子の例を示す図である。 ルール記述言語で記載された使用条件の例を示す図である。
符号の説明
１−１，１−２ クライアント， ２ インターネット， ３ コンテンツサーバ， ４ ライセンスサーバ， ５ 課金サーバ，６ コンテンツホルダサーバ， ２０ タイマ， ２１ CPU， ２４ 暗号化復号部， ２５ コーデック部， ２６ 入力部， ２７ 出力部， ２８ 記憶部， ２９ 通信部

Claims (8)

  1. コンテンツの使用条件を規定する利用権を送信する情報処理装置において、
    前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、
    前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、
    前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、
    前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信手段と
    を含む情報処理装置。
  2. 前記制御手段は、前記サブスクリプションサービスの利用権要求であるとき、ＡＫＥ(Authentication Key Exchange)処理を前記クライアントに要求し、前記ＡＫＥ処理により取得されるセッション鍵により、前記使用状態が付加された利用権を暗号化する
    請求項１に記載の情報処理装置。
  3. 前記受信手段は、前記クライアントから前記クライアントで使用する利用権に対応する使用状態と前記クライアントの識別情報、コンテンツ情報を受信し、
    前記制御手段は、受信した前記コンテンツ情報、前記クライアントの識別情報に基づいて利用権に対応する使用状態に基づいて前記使用状態記憶手段に記憶された使用状態を更新し、
    前記使用状態記憶手段は、更新された使用状態を記憶する
    請求項１に記載の情報処理装置。
  4. 前記受信手段は、前記クライアントから前記クライアントで前記コンテンツを使用する処理が実行されるごとに使用状態を受信する
    請求項３に記載の情報処理装置。
  5. 前記送信手段は、前記制御手段で更新された使用状態を前記クライアントへ送信する
    請求項３に記載の情報処理装置。
  6. コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、
    前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、
    前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、
    前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、
    前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段と
    を含む情報処理装置の情報処理方法において、
    前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、
    前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、
    前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、
    前記送信手段における、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップと
    を含む情報処理方法。
  7. コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、
    前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、
    前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、
    前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、
    前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段と
    を含む情報処理装置を制御するコンピュータに、
    前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、
    前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、
    前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、
    前記送信手段における、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップと
    を含む処理を実行させるプログラム。
  8. コンテンツの使用条件を規定する利用権を送信する情報処理装置であって、
    前記コンテンツを利用するクライアントから利用権送信要求を受信する受信手段と、
    前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶手段と、
    前記受信手段が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶手段に記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御手段と、
    前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御手段により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信手段が受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは要求された利用権のみを、そのまま前記クライアントに送信する送信手段と
    を含む情報処理装置を制御するコンピュータに、
    前記受信手段における、前記コンテンツを利用するクライアントから利用権送信要求を受信する受信ステップと、
    前記使用状態記憶手段における、前記クライアント毎に、使用回数制限、または使用期限制限を含む使用制限が設けられたサブスクリプションサービスの利用権について、前記使用制限に対応する使用状態を記憶する使用状態記憶ステップと、
    前記制御手段における、前記受信ステップの処理が受信した利用権送信要求が、前記サブスクリプションサービスの利用権の送信要求であるときは前記使用状態記憶ステップの処理で記憶された使用状態を要求された利用権に付加し、さらに暗号化する制御ステップと、
    前記送信手段における、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスの利用権の送信要求であるときは、前記制御ステップの処理により使用状態が付加され、さらに暗号化された利用権を前記クライアントに送信し、前記受信ステップの処理で受信した利用権送信要求が前記サブスクリプションサービスではないサービスの利用権の送信要求であるときは、要求された利用権のみを、そのまま前記クライアントに送信する送信ステップと
    を含む処理を実行させるプログラムが格納されているプログラム格納媒体。
JP2007124123A 2007-05-09 2007-05-09 情報処理装置および方法、プログラム格納媒体、並びにプログラム Expired - Fee Related JP4640374B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007124123A JP4640374B2 (ja) 2007-05-09 2007-05-09 情報処理装置および方法、プログラム格納媒体、並びにプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007124123A JP4640374B2 (ja) 2007-05-09 2007-05-09 情報処理装置および方法、プログラム格納媒体、並びにプログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2002111927A Division JP4447821B2 (ja) 2002-04-15 2002-04-15 情報処理装置および方法

Publications (2)

Publication Number Publication Date
JP2007249999A JP2007249999A (ja) 2007-09-27
JP4640374B2 true JP4640374B2 (ja) 2011-03-02

Family

ID=38594132

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007124123A Expired - Fee Related JP4640374B2 (ja) 2007-05-09 2007-05-09 情報処理装置および方法、プログラム格納媒体、並びにプログラム

Country Status (1)

Country Link
JP (1) JP4640374B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5678633B2 (ja) * 2010-12-10 2015-03-04 トヨタ自動車株式会社 ライセンス情報管理システム及びライセンス情報管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07231309A (ja) * 1994-02-17 1995-08-29 Hitachi Ltd 情報配信システム
JP2001034558A (ja) * 1999-07-26 2001-02-09 Nippon Telegr & Teleph Corp <Ntt> コンテンツ利用条件変更方法およびコンテンツ流通システム
JP2002084523A (ja) * 2000-07-06 2002-03-22 Hitachi Ltd 受信方法
JP2003345451A (ja) * 2002-05-22 2003-12-05 Seiko Epson Corp モジュール管理システム、モジュール管理端末、端末用プログラム及び利用制限付モジュールのデータ構造、並びにモジュール管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07231309A (ja) * 1994-02-17 1995-08-29 Hitachi Ltd 情報配信システム
JP2001034558A (ja) * 1999-07-26 2001-02-09 Nippon Telegr & Teleph Corp <Ntt> コンテンツ利用条件変更方法およびコンテンツ流通システム
JP2002084523A (ja) * 2000-07-06 2002-03-22 Hitachi Ltd 受信方法
JP2003345451A (ja) * 2002-05-22 2003-12-05 Seiko Epson Corp モジュール管理システム、モジュール管理端末、端末用プログラム及び利用制限付モジュールのデータ構造、並びにモジュール管理方法

Also Published As

Publication number Publication date
JP2007249999A (ja) 2007-09-27

Similar Documents

Publication Publication Date Title
JP4447821B2 (ja) 情報処理装置および方法
JP3818505B2 (ja) 情報処理装置および方法、並びにプログラム
JP3818504B2 (ja) 情報処理装置および方法、並びにプログラム
US7765604B2 (en) Information processing method, information processing apparatus and recording medium
KR100983982B1 (ko) 정보 처리 장치 및 정보 처리 방법과 컴퓨터 판독 가능 기록 매체
JP4326186B2 (ja) 情報処理装置および方法
KR101028176B1 (ko) 정보 기록 매체, 정보 처리 장치, 정보 처리 방법, 및 컴퓨터 프로그램을 기록한 컴퓨터 판독가능 기록 매체
EP1453240A1 (en) Information processing apparatus and method
EP1538543A1 (en) License management device, license management method, and computer program
JP4391056B2 (ja) 情報管理装置および方法、記録媒体、並びにプログラム
JP2004227282A (ja) コンテンツ配信システム、情報処理装置又は情報処理方法、並びにコンピュータ・プログラム
KR20060026000A (ko) 정보 기기, 정보 서버, 정보 처리 시스템, 정보 처리 방법및 정보 처리 프로그램
JP4151274B2 (ja) 情報処理装置および方法、ライセンスサーバ、並びにプログラム
JP3818503B2 (ja) 情報処理装置および方法、並びにプログラム
JP4640374B2 (ja) 情報処理装置および方法、プログラム格納媒体、並びにプログラム
JP4479698B2 (ja) コンテンツ提供システム
KR100608849B1 (ko) 디지털 컨텐츠의 보안 방법
JP2006320018A (ja) 情報処理装置および方法、記録媒体、並びにプログラム
JP4697152B2 (ja) 情報管理装置、情報管理方法、記録媒体、およびプログラム
KR20050116786A (ko) 디지털 컨텐츠의 보안 방법
KR20050109417A (ko) 디지털 컨텐츠의 재생 제어 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100810

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101004

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101102

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101115

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131210

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees