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

Abstract

(57)【要約】 【課題】 クライアントに大きな負荷をかけることな
く、細かい内容毎に使用権を配布できるようにする。 【解決手段】 コンテンツホルダサーバ６が有する使用
権をライセンスサーバ４に提供する。ライセンスサーバ
４は、コンテンツホルダサーバ６から提供をうけた使用
権を、例えば、再生だけの使用権と、再生とチェックア
ウトを含む使用権とに分割する。クライアント１は、１
０円を支払うことで、再生の使用権を取得する。クライ
アント１は、さらに３０円を支払うことで、再生とチェ
ックアウトを含む使用権を取得する。すなわち、再生だ
けの使用権が、再生とチェックアウトを含む使用権にア
ップグレードされる。本発明は、ネットワークを介して
コンテンツを提供するサーバに適用することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置およ
び方法、プログラム格納媒体、並びにプログラムに関
し、特に、ユーザに負担をかけることなく、より細かく
分割された内容の使用権をユーザに提供することができ
るようにした、情報処理装置および方法、プログラム格
納媒体、並びにプログラムに関する。

【０００２】

【従来の技術】最近、インターネットに代表されるネッ
トワークが普及し、各種のネットワークを介して、オー
ディオ、あるいはビデオなどのコンテンツが配布される
ようになってきた。ユーザ（クライアント）は、ネット
ワークを介してサーバにアクセスし、コンテンツをダウ
ンロードする。

【０００３】また、コンテンツとそのコンテンツを利用
する利用権を独立のものとすることが提案されている。
このような場合、ユーザは、コンテンツ以外に、その利
用権を別途取得する必要がある。そして、通常、コンテ
ンツは暗号化されて、ユーザに提供され、その暗号を解
く鍵は、通常、その利用権に含まれている。あるいはコ
ンテンツに復号鍵が含まれていて、コンテンツの復号処
理がタンパーレジスタントソフトウェア等でそのアルゴ
リズムを知られることなく行われる構成とするものもあ
る。

【０００４】このようにすることで、コンテンツをより
容易に配布することが可能となる。

【０００５】

【発明が解決しようとする課題】ところで、利用権は、
支払い状況に応じて、内容が変化するような場合があ
る。例えば、登録時、２００円を支払うと、１０曲まで
１ヶ月間利用することができるが、追加で１曲毎に５０
円を支払うと、その曲を所有することができ（期間の制
限がなくなり）、さらに追加で１００円を支払うと、ポ
ータブル機器にその曲をチェックアウトすることができ
るといった内容の場合がある。

【０００６】利用権の内容がこのように複雑である場
合、利用権を取得したクライアントは、その利用権の状
態がいずれの状態にあるのかを、自分自身で管理する必
要がある。すなわち、その利用権の現在の状態が２００
円を支払っただけの状態であるのか、その後、さらに５
０円を１曲毎に支払ったのであるのか、支払ったのであ
るとすると、どの曲に対して支払ったのであるのか、さ
らには、その後、追加で１００円を支払い、ポータブル
機器にチェックアウトすることができる状態にあるのか
といったことを、クライアント自身が管理している必要
がある。クライアントにこのような管理を行なわせるこ
とは、クライアントにとって大きな負荷となる。

【０００７】また、クライアントにこのような管理を行
わせると、悪意のユーザが利用権を改竄する恐れがあ
り、安全性の面からも好ましくない。

【０００８】本発明は、このような状況に鑑みてなされ
たものであり、クライアントに負担をかけることなく、
利用権を安全に管理することができるようにするもので
ある。

【０００９】

【課題を解決するための手段】本発明の情報処理装置
は、使用条件を含む情報を受信する受信手段と、受信手
段により受信された使用条件から一部を抽出し、部分使
用条件を生成する抽出手段と、抽出手段により生成され
た部分使用条件をユーザに配布する配布手段とを備える
ことを特徴とする。

【００１０】前記部分使用条件から前記利用権を生成す
る生成手段をさらに備えることができる。

【００１１】前記受信手段が受信する前記使用条件は、
対応するコンテンツの利用形態毎に定義されており、前
記抽出手段は少なくとも１つ以上の前記利用形態に関す
る使用条件を含む部分使用条件を生成するようにするこ
とができる。

【００１２】前記受信手段によって受信される前記第１
の情報は、前記使用条件に対応する課金情報を含むよう
にすることができる。

【００１３】本発明の情報処理方法は、使用条件を含む
情報を受信する受信ステップと、受信ステップの処理に
より受信された使用条件から一部を抽出し、部分使用条
件を生成する抽出ステップと、抽出ステップの処理によ
り生成された部分使用条件をユーザに配布する配布ステ
ップとを含むことを特徴とする。

【００１４】本発明のプログラム格納媒体のプログラム
は、使用条件を含む情報を受信する受信ステップと、受
信ステップの処理により受信された使用条件から一部を
抽出し、部分使用条件を生成する抽出ステップと、抽出
ステップの処理により生成された部分使用条件をユーザ
に配布する配布ステップとを含むことを特徴とする。

【００１５】本発明のプログラムは、使用条件を含む情
報を受信する受信ステップと、受信ステップの処理によ
り受信された使用条件から一部を抽出し、部分使用条件
を生成する抽出ステップと、抽出ステップの処理により
生成された部分使用条件をユーザに配布する配布ステッ
プとをコンピュータに実行させることを特徴とする。

【００１６】本発明においては、受信された情報に含ま
れる使用条件から一部が抽出され、部分使用条件が生成
され、生成された部分使用条件がユーザに配布される。

【００１７】

【発明の実施の形態】図１は、本発明を適用したコンテ
ンツ提供システムの構成を示している。インターネット
２には、クライアント１−１，１−２（以下、これらの
クライアントを個々に区別する必要がない場合、単にク
ライアント１と称する）が接続されている。この例にお
いては、クライアントが２台のみ示されているが、イン
ターネット２には、任意の台数のクライアントが接続さ
れる。

【００１８】また、インターネット２には、クライアン
ト１に対してコンテンツを提供するコンテンツサーバ
３、コンテンツサーバ３が提供するコンテンツを利用す
るのに必要な利用権をクライアント１に対して付与する
ライセンスサーバ４、およびクライアント１が利用権を
受け取った場合に、そのクライアント１に対して課金処
理を行う課金サーバ５が接続されている。

【００１９】コンテンツサーバ３とライセンスサーバ４
には、コンテンツホルダサーバ６がさらに接続されてい
る。コンテンツホルダサーバ６は、コンテンツサーバ３
に対してコンテンツを提供するとともに、ライセンスサ
ーバ４に対してコンテンツに関するプロダクト情報を提
供する。

【００２０】これらのコンテンツサーバ３、ライセンス
サーバ４、課金サーバ５、およびコンテンツホルダ６
も、任意の台数設けられ、必要に応じてインターネット
２に接続される。

【００２１】図２はライセンスサーバ４の構成を表して
いる。

【００２２】図２において、CPU（Central Processing
Unit）２１は、ROM（Read Only Memory）２２に記憶さ
れているプログラム、または記憶部２８からRAM（Rando
m Access Memory）２３にロードされたプログラムに従
って各種の処理を実行する。タイマ２０は、計時動作を
行い、時刻情報をCPU２１に供給する。RAM２３にはま
た、CPU２１が各種の処理を実行する上において必要な
データなども適宜記憶される。

【００２３】暗号化復号部２４は、コンテンツデータを
暗号化するとともに、既に暗号化されているコンテンツ
データを復号する処理を行う。コーデック部２５は、例
えば、ATRAC（Adaptive Transform Acoustic Coding）
３方式などでコンテンツデータをエンコードし、入出力
インタフェース３２を介してドライブ３０に接続されて
いる半導体メモリ４４に供給し、記録させる。あるいは
また、コーデック部２５は、ドライブ３０を介して半導
体メモリ４４より読み出した、エンコードされているデ
ータをデコードする。

【００２４】半導体メモリ４４は、例えば、メモリース
ティック（商標）などにより構成される。

【００２５】CPU２１、ROM２２、RAM２３、暗号化復号
部２４、およびコーデック部２５は、バス３１を介して
相互に接続されている。このバス３１にはまた、入出力
インタフェース３２も接続されている。

【００２６】入出力インタフェース３２には、キーボー
ド、マウスなどよりなる入力部２６、CRT、LCDなどより
なるディスプレイ、並びにスピーカなどよりなる出力部
２７、ハードディスクなどより構成される記憶部２８、
モデム、ターミナルアダプタなどより構成される通信部
２９が接続されている。通信部２９は、インターネット
２を介しての通信処理を行う。通信部２９はまた、他の
クライアントとの間で、アナログ信号またはデジタル信
号の通信処理を行う。

【００２７】入出力インタフェース３２にはまた、必要
に応じてドライブ３０が接続され、磁気ディスク４１、
光ディスク４２、光磁気ディスク４３、或いは半導体メ
モリ４４などが適宜装着され、それらから読み出された
コンピュータプログラムが、必要に応じて記憶部２８に
インストールされる。

【００２８】なお、図示は省略するが、クライアント
１、コンテンツサーバ３、課金サーバ５も、図２に示し
たライセンスサーバ４と基本的に同様の構成を有するコ
ンピュータにより構成される。そこで、以下の説明にお
いては、図２の構成は、クライアント１、コンテンツサ
ーバ３、課金サーバ５などの構成としても引用される。

【００２９】なお、図示は省略するが、PD（Portable D
evice）も、図２に示したライセンスサーバ４と基本的
に同様の構成を有するコンピュータにより構成される。

【００３０】次に、図３のフローチャートを参照して、
クライアント１がコンテンツサーバ３からコンテンツの
提供を受ける処理について説明する。

【００３１】ユーザが、入力部２６を操作することでコ
ンテンツサーバ３に対するアクセスを指令すると、CPU
２１は、ステップＳ１において、通信部２９を制御し、
インターネット２を介してコンテンツサーバ３にアクセ
スさせる。ステップＳ２において、ユーザが、入力部２
６を操作して、提供を受けるコンテンツを指定すると、
CPU２１は、この指定情報を受け取り、通信部２９か
ら、インターネット２を介してコンテンツサーバ３に、
指定されたコンテンツのコンテンツIDを通知する。図４
のフローチャートを参照して後述するように、この通知
を受けたコンテンツサーバ３は、暗号化されたコンテン
ツデータを含むコンテンツを送信してくるので、ステッ
プＳ３において、CPU２１は、通信部２９を介して、こ
のコンテンツデータを受信すると、ステップＳ４におい
て、その暗号化されているコンテンツデータを記憶部２
８を構成するハードディスクに供給し、記憶させる。

【００３２】次に、図４のフローチャートを参照して、
クライアント１の以上の処理に対応するコンテンツサー
バ３のコンテンツ提供処理について説明する。なお、以
下の説明において、図２のライセンスサーバ４の構成
は、コンテンツサーバ３の構成としても引用される。

【００３３】ステップＳ２１において、コンテンツサー
バ３のCPU２１は、インターネット２から通信部２９を
介してクライアント１よりアクセスを受けるまで待機
し、アクセスを受けたと判定したとき、ステップＳ２２
に進み、クライアント１から送信されてきたコンテンツ
IDを取り込む。このコンテンツIDは、クライアント１
が、図３のステップＳ２において通知してきた情報であ
る。

【００３４】ステップＳ２３において、コンテンツサー
バ３のCPU２１は、記憶部２８に記憶されているコンテ
ンツの中から、ステップＳ２２の処理で取り込まれたコ
ンテンツIDで指定されたコンテンツデータを読み出す。
CPU２１は、ステップＳ２４において、記憶部２８から
読み出されたコンテンツデータを、暗号化復号部２４に
供給し、コンテンツキーKcを用いて暗号化させる。

【００３５】記憶部２８に記憶されているコンテンツデ
ータは、コーデック部２５により、既にATRAC３方式に
よりエンコードされているので、このエンコードされて
いるコンテンツデータが暗号化されることになる。

【００３６】なお、もちろん、記憶部２８に予め暗号化
した状態でコンテンツデータを記憶させることができ
る。この場合には、ステップＳ２４の処理は省略するこ
とが可能である。

【００３７】次に、ステップＳ２５において、コンテン
ツサーバ３のCPU２１は、暗号化したコンテンツデータ
を伝送するフォーマットを構成するヘッダに、暗号化さ
れているコンテンツを復号するのに必要なキー情報（図
５を参照して後述するEKBとK _EKBC（Kc））を付加する。
そして、ステップＳ２６において、コンテンツサーバ３
のCPU２１は、ステップＳ２４の処理で暗号化したコン
テンツと、ステップＳ２５の処理でキー情報を付加した
ヘッダとをフォーマット化したデータを、通信部２９か
ら、インターネット２を介して、アクセスしてきたクラ
イアント１に送信する。

【００３８】図５は、このようにして、コンテンツサー
バ３からクライアント１にコンテンツが供給される場合
のフォーマットの構成を表している。同図に示されるよ
うに、このフォーマットは、ヘッダ（Header）とデータ
（Data）とにより構成される。

【００３９】ヘッダには、コンテンツ情報（Content in
formation）、URL(Uniform Resource Locator)、イネー
ブリングキーブロック（有効化キーブロック）（EKB（E
nabling Key Block））、EKBから生成されたキーK_EKBC
を用いて暗号化されたコンテンツキーKcとしてのデータ
K_EKBC（Kc）、コンテンツの属性（Attributes）、およ
び署名（Signatures）が配置されている。なお、EKBに
ついては、図１３および図１４を参照して後述する。

【００４０】コンテンツ情報には、データとしてフォー
マット化されているコンテンツデータを識別するための
識別情報としてのコンテンツID（CID）、そのコンテン
ツのコーデックの方式などの情報が含まれている。

【００４１】URLは、そのコンテンツを利用するために
必要な利用権を取得するときアクセスするアドレス情報
であり、図１のシステムの場合、具体的には、利用権を
受けるために必要なライセンスサーバ４のアドレスであ
る。

【００４２】コンテンツの属性は、コンテンツの関する
情報であり、コンテンツの属性には、コンテンツID、コ
ンテンツの提供者を識別するための識別情報としてのレ
コードカンパニーID、アーティストを識別するための識
別情報としてのアーティストIDなどが含まれる。本実施
の形態では、属性は利用権の対象となるコンテンツを特
定するために用いられる。

【００４３】署名は、コンテンツの属性に対応する電子
署名である。

【００４４】データは、任意の数の暗号化ブロック（En
cryption Block）により構成される。各暗号化ブロック
は、イニシャルベクトル（IV（Initial Vector））、シ
ード（Seed）、およびコンテンツデータをキーK'cで暗
号化したデータE_K'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（図５）に含まれるキー
Ｋ_{EK BC}を得ることができ、そのキーＫ_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 En
cryption）方式の原理に基づいて、デバイスとキーが管
理される。キーは、階層ツリー構造とされ、最下段のリ
ーフ（leaf）が個々のデバイス固有のキーに対応する。
本発明のシステムに用いられる階層ツリー構造鍵管理に
ついては特許公開2001-352321号公報に記載されてい
る。図１０の例の場合、番号０から番号１５までの１６
個のデバイスに対応するキーが生成される。

【００９７】各キーは、図中丸印で示されるツリー構造
の各ノードに対応して規定される。この例では、最上段
のルートノードに対応してルートキーKRが、２段目のノ
ードに対応してキーＫ０，Ｋ１が、３段目のノードに対
応してキーＫ００乃至Ｋ１１が、第４段目のノードに対
応してキーＫ０００乃至キーＫ１１１が、それぞれ対応
されている。そして、最下段のノードとしてのリーフ
（デバイスノード）に、キーＫ００００乃至Ｋ１１１１
が、それぞれ対応されている。

【００９８】階層構造とされているため、例えば、キー
Ｋ００１０とキー００１１の上位のキーは、Ｋ００１と
され、キーＫ０００とキーＫ００１の上位のキーは、Ｋ
００とされている。以下同様に、キーＫ００とキーＫ０
１の上位のキーは、Ｋ０とされ、キーＫ０とキーＫ１の
上位のキーは、KRとされている。

【００９９】コンテンツを利用するキーは、最下段のデ
バイスノード（リーフ）から、最上段のルートノードま
での１つのパスの各ノードに対応するキーで管理され
る。例えば、番号３のリーフに対応するデバイスにおい
て、コンテンツを利用するためのキーは、キーＫ００１
１，Ｋ００１，Ｋ００，Ｋ０，KRを含むパスの各キーで
管理される。

【０１００】本発明のシステムにおいては、図１１に示
されるように、図１０の原理に基づいて構成されるキー
システムで、デバイスのキーとコンテンツのキーの管理
が行われる。図１１の例では、８＋２４＋３２段のノー
ドがツリー構造とされ、ルートノードから下位の８段ま
での各ノードにカテゴリが対応される。ここにおけるカ
テゴリとは、例えばメモリースティックなどの半導体メ
モリを使用する機器のカテゴリ、デジタル放送を受信す
る機器のカテゴリといったカテゴリを意味する。そし
て、このカテゴリノードのうちの１つのノードに、ライ
センスを管理するシステムとして本システム（Ｔシステ
ムと称する）が対応する。

【０１０１】すなわち、このＴシステムのノードよりさ
らに下の階層の２４段のノードに対応するキーにより、
サービスプロバイダ、あるいはサービスプロバイダが提
供するサービスが対応される。この例の場合、これによ
り、２²⁴（約１６メガ）のサービスプロバイダあるいは
サービスを規定することができる。さらに、最も下側の
３２段の階層により、２³²（約４ギガ）のユーザ（ある
いはクライアント１）を規定することができる。最下段
の３２段のノードからＴシステムのノードまでのパス上
の各ノードに対応するキーが、DNK（Device Node Key）
を構成し、最下段のリーフに対応するIDがリーフIDとさ
れる。

【０１０２】コンテンツを暗号化したコンテンツキーは
更新されたルートキーKR'によって暗号化され、上位の
階層の更新ノードキーは、その直近の下位の階層の更新
ノードキーを用いて暗号化され、ＥＫＢ（図１３および
図１４を参照して後述する）内に配置される。ＥＫＢに
おける末端から１つ上の段の更新ノードキーはＥＫＢの
末端のノードキーあるいはリーフキーによって暗号化さ
れ、ＥＫＢ内に配置される。クライアント１は、サービ
スデータに記述されているＤＮＫのいずれかのキーを用
いて、コンテンツデータとともに配布されるＥＫＢ（図
１３および図１４）内に記述されている直近の上位の階
層の更新ノードキーを復号し、復号して得たキーを用い
て、ＥＫＢ内に記述されているさらにその上の階層の更
新ノードキーを復号する。以上の処理を順次行うこと
で、クライアント１は、更新ルートキーKR'を得ること
ができる。

【０１０３】図１２に階層ツリー構造のカテゴリの分類
の具体的な例を示す。図１２において、階層ツリー構造
の最上段には、ルートキーKR２３０１が設定され、以下
の中間段にはノードキー２３０２が設定され、最下段に
は、リーフキー２３０３が設定される。各デバイスは個
々のリーフキーと、リーフキーからルートキーに至る一
連のノードキー、ルートキーからなるデバイスノードキ
ー（ＤＮＫ）を保有する。

【０１０４】最上段から第Ｍ段目（図１１の例では、Ｍ
＝８）の所定のノードがカテゴリノード２３０４として
設定される。すなわち第Ｍ段目のノードの各々が特定カ
テゴリのデバイス設定ノードとされる。第Ｍ段の１つの
ノードを頂点としてＭ＋１段以下のノード、リーフは、
そのカテゴリに含まれるデバイスに関するノードおよび
リーフとされる。

【０１０５】例えば図１２の第Ｍ段目の１つのノード２
３０５にはカテゴリ［メモリースティック（商標）］が
設定され、このノード以下に連なるノード、リーフはメ
モリステッイクを使用した様々なデバイスを含むカテゴ
リ専用のノードまたはリーフとして設定される。すなわ
ち、ノード２３０５以下が、メモリースティックのカテ
ゴリに定義されるデバイスの関連ノード、およびリーフ
の集合として定義される。

【０１０６】さらに、Ｍ段から数段分下位の段をサブカ
テゴリノード２３０６として設定することができる。図
１２の例では、カテゴリ［メモリースティック］ノード
２３０５の２段下のノードに、メモリースティックを使
用したデバイスのカテゴリに含まれるサブカテゴリノー
ドとして、［再生専用器］のノード２３０６が設定され
ている。さらに、サブカテゴリノードである再生専用器
のノード２３０６以下に、再生専用器のカテゴリに含ま
れる音楽再生機能付き電話のノード２３０７が設定さ
れ、さらにその下位に、音楽再生機能付き電話のカテゴ
リに含まれる［ＰＨＳ］ノード２３０８と、［携帯電
話］ノード２３０９が設定されている。

【０１０７】さらに、カテゴリ、サブカテゴリは、デバ
イスの種類のみならず、例えばあるメーカー、コンテン
ツプロバイダ、決済機関等が独自に管理するノード、す
なわち処理単位、管轄単位、あるいは提供サービス単位
等、任意の単位（これらを総称して以下、エンティティ
と呼ぶ）で設定することが可能である。例えば１つのカ
テゴリノードをゲーム機器メーカーの販売するゲーム機
器ＸＹＺ専用の頂点ノードとして設定すれば、メーカー
の販売するゲーム機器ＸＹＺに、その頂点ノード以下の
下段のノードキー、リーフキーを格納して販売すること
が可能となり、その後、暗号化コンテンツの配信、ある
いは各種キーの配信、更新処理を、その頂点ノードキー
以下のノードキー、リーフキーによって構成される有効
化キーブロック（ＥＫＢ）を生成して配信し、頂点ノー
ド以下のデバイスに対してのみ利用可能なデータが配信
可能となる。

【０１０８】このように、１つのノードを頂点として、
以下のノードをその頂点ノードに定義されたカテゴリ、
あるいはサブカテゴリの関連ノードとして設定する構成
とすることにより、カテゴリ段、あるいはサブカテゴリ
段の１つの頂点ノードを管理するメーカー、コンテンツ
プロバイダ等がそのノードを頂点とする有効化キーブロ
ック（ＥＫＢ）を独自に生成して、頂点ノード以下に属
するデバイスに配信する構成が可能となり、頂点ノード
に属さない他のカテゴリのノードに属するデバイスには
全く影響を及ぼさずにキー更新を実行することができ
る。

【０１０９】また、ある時点ｔにおいて、デバイス３の
所有する鍵Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,KRが攻撃
者（ハッカー）により解析されて露呈したことが発覚し
た場合、それ以降、システム（デバイス０，１，２，３
のグループ）で送受信されるデータを守るために、デバ
イス３をシステムから切り離す必要がある。そのために
は、ノードキーＫ００１,Ｋ００,Ｋ０,KRを、それぞれ
新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ
（ｔ）Ｒに更新し、デバイス０，１，２にその更新キー
を伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋ
ａａａの世代（Generation）ｔの更新キーであることを
示す。

【０１１０】更新キーの配布処理ついて説明する。キー
の更新は、例えば、図１３に示す有効化キーブロック
（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデ
ータによって構成されるテーブルを、ネットワークを介
して、あるいは記録媒体に格納してデバイス０，１，２
に供給することによって実行される。なお、有効化キー
ブロック（ＥＫＢ）は、図１０に示されるようなツリー
構造を構成する各リーフ（最下段のノード）に対応する
デバイスに、新たに更新されたキーを配布するための暗
号化キーによって構成される。有効化キーブロック（Ｅ
ＫＢ）は、キー更新ブロック（ＫＲＢ：Key Renewal Bl
ock）と呼ばれることもある。

【０１１１】図１３に示す有効化キーブロック（ＥＫ
Ｂ）は、ノードキーの更新の必要なデバイスのみが更新
可能なデータ構成を持つブロックデータとして構成され
る。図１３の例は、図１０に示すツリー構造中のデバイ
ス０，１，２において、世代ｔの更新ノードキーを配布
することを目的として形成されたブロックデータであ
る。図１０から明らかなように、デバイス０，デバイス
１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）
０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノー
ドキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）
０、Ｋ（ｔ）Ｒが必要である。

【０１１２】図１３のＥＫＢに示されるように、ＥＫＢ
には複数の暗号化キーが含まれる。図１３の最下段の暗
号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）で
ある。これはデバイス２の持つリーフキーＫ００１０に
よって暗号化された更新ノードキーＫ（ｔ）００１であ
り、デバイス２は、自身の持つリーフキーＫ００１０に
よってこの暗号化キーを復号し、更新ノードキーＫ
（ｔ）００１を得ることができる。また、復号により得
た更新ノードキーＫ（ｔ）００１を用いて、図１３の下
から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ
（ｔ）００）が復号可能となり、更新ノードキーＫ
（ｔ）００を得ることができる。

【０１１３】以下順次、図１３の上から２段目の暗号化
キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号するこ
とで、更新ノードキーＫ（ｔ）０が得られ、これを用い
て、図１３の上から１段目の暗号化キーＥｎｃ（Ｋ
（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルート
キーＫ（ｔ）Ｒが得られる。

【０１１４】一方、ノードキーＫ０００は更新する対象
に含まれておらず、ノード０，１が、更新ノードキーと
して必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）
Ｒである。ノード０，１は、デバイスキーＫ００００，
Ｋ０００１を用いて、図１３の上から３段目の暗号化キ
ーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号することで
更新ノードキーＫ（ｔ）００を取得し、以下順次、図１
３の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，
Ｋ（ｔ）０）を復号することで、更新ノードキーＫ
（ｔ）０を得、図１３の上から１段目の暗号化キーＥｎ
ｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新
ルートキーＫ（ｔ）Ｒを得る。このようにして、デバイ
ス０，１，２は更新したキーＫ（ｔ）Ｒを得ることがで
きる。

【０１１５】なお、図１３のインデックスは、図の右側
の暗号化キーを復号するための復号キーとして使用する
ノードキー、リーフキーの絶対番地を示す。

【０１１６】図１０に示すツリー構造の上位段のノード
キーＫ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノー
ドキーＫ００のみの更新処理が必要である場合には、図
１４の有効化キーブロック（ＥＫＢ）を用いることで、
更新ノードキーＫ（ｔ）００をデバイス０，１，２に配
布することができる。

【０１１７】図１４に示すＥＫＢは、例えば特定のグル
ープにおいて共有する新たなコンテンツキーを配布する
場合に利用可能である。具体例として、図１０に点線で
示すグループ内のデバイス０，１，２，３がある記録媒
体を用いており、新たな共通のコンテンツキーＫ（ｔ）
ｃｏｎが必要であるとする。このとき、デバイス０，
１，２，３の共通のノードキーＫ００を更新したＫ
（ｔ）００を用いて新たな共通の更新コンテンツキーＫ
（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）０
０，Ｋ（ｔ）ｃｏｎ）が、図１４に示されるＥＫＢとと
もに配布される。この配布により、デバイス４など、そ
の他のグループの機器が復号することができないデータ
としての配布が可能となる。

【０１１８】すなわち、デバイス０，１，２はＥＫＢを
処理して得たキーＫ（ｔ）００を用いて暗号文を復号す
れば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る
ことが可能になる。

【０１１９】図１５に、ｔ時点でのコンテンツキーＫ
（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用い
て新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化
したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）
と、図１４に示すＥＫＢとを記録媒体を介して受領した
デバイス０の処理を示す。すなわちこの例は、ＥＫＢに
よる暗号化メッセージデータをコンテンツキーＫ（ｔ）
ｃｏｎとした例である。

【０１２０】図１５に示すように、デバイス０は、記録
媒体に格納されている世代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）が配布され
る。各ユーザは、その秘密鍵を用いて、署名（signatur
e）を作成し、コンテンツに付加して、コンテンツの真
正さ(integrity)を保証し、かつコンテンツの改竄防止
を図ることができる。

【０１３８】クライアント１は、コンテンツを利用する
前に、ライセンスサーバ４にアクセスし、利用権を取得
する必要がある。ライセンスサーバ４は、クライアント
１からアクセスを受けたとき、利用権を提供するのであ
るが、その前にコンテンツホルダサーバ６からコンテン
ツに関するプロダクト情報を取得する必要がある。次
に、図２１と図２２のフローチャートを参照して、この
場合の処理について説明する。

【０１３９】コンテンツホルダサーバ６のCPU２１は、
ステップＳ２０１において、コンテンツのプロダクト情
報を作成する。ステップＳ２０２において、CPU２１
は、ステップＳ２０１で作成したプロダクト情報を、通
信部２９を介してライセンスサーバ４に送信する。

【０１４０】以上のコンテンツホルダサーバ６の処理に
対応して、ライセンスサーバ４は、図２２のフローチャ
ートに示される処理を実行する。

【０１４１】すなわち、ステップＳ３０１において、ラ
イセンスサーバ４のCPU２１は、コンテンツホルダサー
バ６から送信されてきた（図２１のステップＳ２０２の
処理で送信されてきた）プロダクト情報を受信する。ス
テップＳ３０２において、CPU２１は、ステップＳ３０
１の処理で受信したプロダクト情報を記憶部２８に供給
し、記憶させる。その後、ステップＳ３０３において、
CPU２１は、ステップＳ３０２の処理で登録したプロダ
クト情報（使用条件）を分割する処理を実行する。

【０１４２】例えば、コンテンツホルダサーバ６から送
信されてきたプロダクト情報が図２３に示されるような
内容であったとする。図２３の例においては、ユーザが
３５０円の対価を支払った場合には、対応するコンテン
ツを、回数と期間の制限なく、再生することが可能とな
る。

【０１４３】これに対して、ユーザが１００円の対価を
支払った場合には、回数は制限ないが、期間は１ヶ月の
みとされ、その間、ユーザはコンテンツを再生すること
が許容される。

【０１４４】ユーザは、さらに５０円を追加的に支払っ
た場合には、３回だけチェックアウトが許容される。さ
らに５０円の対価が支払われた場合には、１回だけ、１
０日間の間、コピーをすることが許容される。この場合
におけるコピー先での再生は、対価の支払いは必要ない
が（対価は０円であるが）、回数は１０回に限られ、期
間は１日に限られている。

【０１４５】ライセンスサーバ４は、図２３に示される
ようなプロダクト情報をコンテンツホルダサーバ６から
受け取ったとき、このプロダクト情報を、例えば、図２
４に示されるように分割する。

【０１４６】図２４の例においては、プロダクト情報は
３つに分割されている。第１のプロダクト情報は、ユー
ザが３５０円の対価を支払った場合のものであり、その
内容は、再生回数と再生期間が無限とされている。

【０１４７】第２のプロダクト情報は、ユーザが１５０
円の対価を支払った場合のものであり、再生回数は無限
であるが、再生期間は、YY年MM月DD日までとされ、チェ
ックアウトの回数は３回まで許容される内容となってい
る。

【０１４８】第３番目のプロダクト情報は、対価は０円
とされ、その内容はコピー先の使用条件を規定するもの
であり、再生回数は１０回とされ、再生期間は１日とさ
れている。

【０１４９】この第３番目のプロダクト情報は０円であ
るので、第２番目のプロダクト情報に付随して配布され
る。

【０１５０】このように、ライセンスサーバ４は、コン
テンツホルダサーバ６から許容されたプロダクト情報に
記載されている使用条件の範囲内において、その使用条
件を複数の使用条件に分割し、分割された使用条件を含
む利用権として、クライアント１に対して提供すること
ができる。

【０１５１】次に、図２５のフローチャートを参照し
て、図２２のステップＳ３０３のプロダクト情報（使用
条件）分割処理の具体的な例について説明する。

【０１５２】なお、図２５の処理は、コンテンツホルダ
サーバ６から提供され、ライセンスサーバ４の記憶部２
８に記憶されているプロダクト情報に含まれる使用条件
が、例えば、図２６に示されるような内容である場合に
おいて、この使用条件から、再生だけを許容する使用条
件として分割する処理の例を表している。

【０１５３】図２６の例においては、再生回数は３回と
され、チェックアウト回数も３回とされている。そし
て、再生開始日は２００１年１２月１日とされ、終了日
は２００２年２月２８日とされている。

【０１５４】ステップＳ３２１において、CPU２１は、
コンテンツホルダサーバ６から受信し、記憶部２８に記
憶したプロダクト情報のXML（Extensible Markup Langu
age）で記述されているRule部から、「playback」の要
素を検索する。

【０１５５】次に、ステップＳ３２２において、CPU２
１は、「playback」が存在したか否かを判定する。「pl
ayback」が存在した場合には、ステップＳ３２３に進
み、CPU２１は、期間制限オプション(timespan_id)から
期間を抽出する。図２６の例においては、２００１年１
２月１日から２００２年２月２８日までの期間が抽出さ
れる。

【０１５６】次に、ステップＳ３２４において、CPU２
１は、ステップＳ３２３の処理で抽出された期間のdate
_start（開始日）とdate_end（終了日）を、それぞれ再
生可能開始日を表す変数resp及び再生可能終了日を表す
reepに代入する。

【０１５７】ステップＳ３２５において、CPU２１は、
ステップＳ３２４の処理に基づいて生成されたデータに
基づいて、分割された使用条件を作成する。これによ
り、例えば、図２７に示されるような使用条件が作成さ
れる。

【０１５８】図２７の例においては、２００１年１２月
１日から２００２年２月２８日までの期間、コンテンツ
が使用可能とされている。

【０１５９】ステップＳ３２６において、CPU２１は、
ステップＳ３２５の処理で作成した使用条件と、プロダ
クト情報に含まれるコンテンツ条件、利用権ID等を組み
合わせ、バージョン、有効期限等を追加した利用権を生
成し、生成された利用権を記憶部２８に登録する。

【０１６０】ステップＳ３２２において、「playback」
のテキストが存在しないと判定された場合には、ステッ
プＳ３２３乃至ステップＳ３２６の処理はスキップされ
る。

【０１６１】次に、図２８のフローチャートを参照し
て、図２２のステップＳ３０３の使用条件分割処理の他
の例について説明する。

【０１６２】この例は、図２６に示されるような使用条
件がコンテンツホルダサーバ６からライセンスサーバ４
に提供された場合において、再生の使用条件と、チェッ
クアウトの使用条件の、合計２つの使用条件を分割、生
成する場合の処理例を表している。

【０１６３】ステップＳ３４１乃至Ｓ３４５において、
図２５のステップＳ３２１乃至ステップＳ３２５におけ
る場合と同様の処理が実行される。これにより、上述し
たように、再生の使用条件を含む利用権が分割、生成さ
れる。

【０１６４】なお、ステップＳ３４２において、「PLAY
BACK」の要素が検索されなかったと判定された場合、ス
テップＳ３４３乃至ステップＳ３４５の処理はスキップ
され、処理はステップＳ３４６に進む。

【０１６５】次に、ステップＳ３４６において、CPU２
１は、XMLで記述されたRule部（図２６）から「checkou
t」の要素を検索する。ステップＳ３４７において、CPU
２１は、「checkout」が存在したか否かを判定し、存在
した場合には、ステップＳ３４８に進み、XMLのRule部
から回数を読み出す。図２６の例の場合、回数として３
回が読み出される。

【０１６６】ステップＳ３４９において、CPU２１は、
ステップＳ３４８で読み出された回数を、最大チェック
アウト回数を表す変数reccに代入する。そして、ステッ
プＳ３５０において、CPU２１は、ステップＳ３４９の
処理で生成されたデータを元に、分割された使用条件を
作成する。ステップＳ３５１において、CPU２１は、ス
テップＳ３４５またはステップＳ３５０で作成された使
用条件を含む利用権を生成し、記憶部２８に登録する処
理を実行する。

【０１６７】ステップＳ３４７において、「checkout」
が存在しないと判定された場合、ステップＳ３４８乃至
ステップＳ３５０の処理はスキップされる。

【０１６８】このようにして、図２９に示されるような
再生の使用条件を含む利用権とチェックアウト回数が３
回である使用条件を含む利用権が生成される。

【０１６９】以上のようにして、ライセンスサーバ４が
コンテンツホルダサーバ６から提供を受けた使用条件
を、分割、管理するようにすることで、クライアント１
は、大きな使用条件を取り扱う負担を強いられることな
く、利用権を容易に管理することが可能となる。

【０１７０】また、利用権に含まれている使用条件をア
ップグレードさせることができる。この場合の処理につ
いて、図３０を参照して説明する。

【０１７１】すなわち、図３０の例においては、コンテ
ンツホルダサーバ６が生成したコンテンツに対する利用
権として、そのコンテンツの再生、チェックアウト、お
よび購入を規定する１つの利用権を生成し、これをライ
センスサーバ４に提供する。

【０１７２】ライセンスサーバ４は、この１つの利用権
を、再生だけができる利用権、並びに再生とチェックア
ウトができる利用権の２つの利用権に分割する。

【０１７３】クライアント１は、例えば、１０円を支払
うことにより、再生だけの利用権を取得することができ
る。そして、その後、クライアント１は、さらに３０円
を支払うことにより、再生だけでなく、さらにチェック
アウトの権利が付加された利用権を取得することができ
る。すなわち、再生だけの利用権から、再生とチェック
アウトを含む利用権に、クライアント１は利用権をアッ
プグレードすることができる。

【０１７４】この場合において、クライアント１は、利
用権の状態が、１０円を支払った状態と、さらに３０円
を支払った状態とがあるということを管理している必要
はない。クライアント１は、ただ単に、新たな利用権を
購入するだけでよい。換言すれば、クライアント１から
見れば、再生の利用権と、再生とチェックアウトの利用
権とは、全く独立した別の利用権として取り扱えばよい
ことになる。

【０１７５】この場合の処理を、さらに図３１と図３２
を参照して説明する。図３１は、ライセンスサーバ４が
コンテンツホルダサーバ６から提供を受けたプロダクト
情報の使用条件の概要を表している。この例では、Usag
e Rule IDが１とされ、１０円の支払いが行われた場
合、再生が許容されるルールと、２０円の支払いがなさ
れた場合には、再生とチェックアウトが許容されるルー
ルが記述されている。

【０１７６】このような場合において、ライセンスサー
バ４が図３１に示される１つの使用条件を、再生だけの
使用条件と、再生とチェックアウトを許容する使用条件
の２つに分割し、それぞれに対応する利用権を生成した
とする。

【０１７７】この場合、図３２に示されるように、クラ
イアント１がステップＳ３７１で、ライセンスサーバ４
に対して１０円を支払った場合、（なお、詳細な説明は
省略するが、具体的な課金処理は、課金サーバ５により
行われる。以下同様）ステップＳ３７２において、ライ
センスサーバ４は、クライアント１に対して再生の利用
権（Usage Right）を付与する。この場合の処理は、購
入処理と同様となる。

【０１７８】その後、ステップＳ３７３において、クラ
イアント１がライセンスサーバ４に対して、さらに２０
円の支払いを許諾する情報を送信し、ステップＳ３７４
において、クライアント１のリーフIDと、ステップＳ３
７２で取得した利用権のIDを、ライセンスサーバ４に対
して送信すると、ステップＳ３７５において、ライセン
スサーバ４は、再生とチェックアウトの内容を含む利用
権を、クライアント１に配布する。この処理は、アップ
グレード処理である。

【０１７９】なお、ステップＳ３７２でクライアント１
に付与される利用権IDと、ステップＳ３７５の処理でク
ライアント１に付与される利用権IDは、同一である。す
なわち、この利用権IDは、図３１に示されるライセンス
サーバ４がコンテンツホルダサーバ６から提供を受けた
利用権のIDと対応している。

【０１８０】換言すれば、分割されてはいるが、２つの
利用権は同一のプロダクト情報に含まれる使用条件から
派生したものである。

【０１８１】図３３は、クライアント１がライセンスサ
ーバ４から利用権を取得する場合における表示例を表し
ている。ステップＳ３９１において、クライアント１が
リーフIDをライセンスサーバ４に送信するとともに、既
に利用権を取得している場合には、そのIDをライセンス
サーバ４に送信する。

【０１８２】ライセンスサーバ４は、クライアント１に
対して、購入可能な権利のリストと対応する値段が記述
されたドキュメントを、クライアント１に送信する。ク
ライアント１のCPU２１は、これを通信部２９を介して
これを受信すると、出力部２７のモニタに出力し、表示
させる。

【０１８３】図３３の例においては、購入可能な権利と
して、３回のチェックアウトを可能にする１００円の利
用権、既に取得されているコンテンツを自分のものにす
る１５０円の利用権、並びに既に取得している利用権を
他人にコピーしてあげる１０円の利用権の、３種類の利
用権が表示されている。

【０１８４】クライアント１が保持する利用権は、クラ
イアント１が支払った対価に応じて、変化するのである
が、いま、ライセンスサーバ４にアクセスしてきたクラ
イアント１が、いずれの状態の利用権を取得しているの
かは、ライセンスサーバ４が管理している。従って、ク
ライアント１のリーフIDとクライアント１が保持してい
る利用権のIDに基づいて、ライセンスサーバ４のCPU２
１は、アクセスしてきたクライアント１に対応するメニ
ュー（購入可能な権利の内容）を表示させることができ
る。

【０１８５】なお、図３３の表示例においては、「佐藤
さん、いらっしゃいませ。」のメッセージも同時に表示
されている。アクセスしてきたクライアント１のユーザ
が誰であるのかは、ユーザを登録する処理を行った場合
に、ユーザ名を登録しているので、リーフIDに対応する
ユーザの氏名をデータベースから検索することで、表示
することが可能となる。

【０１８６】あるいは、また、cookieを利用して氏名を
表示させるようにすることも可能である。

【０１８７】ステップＳ３９２で、クライアント１が、
メニュー表示に従い利用権の購入手続を行い、利用権に
対する対価の支払の処理を行うと、ステップＳ３９３に
おいて、ライセンスサーバ４からクライアント１に、対
価に対応する利用権（UsageRight）が配布される。

【０１８８】次に、図３４を参照して、ライセンスサー
バ４において行われる購入履歴の管理について説明す
る。

【０１８９】図３４の例においては、コンテンツホルダ
サーバ６が１つのプロダクト情報をライセンスサーバ４
に供給する。このプロダクト情報は、２００円の対価に
よって取得することが可能なUsage Rules１、さらに１
００円を支払って取得することが可能なUsage Rules
２、さらに５０円を支払うことにより取得可能なUsage
Rules３、並びにUsage Rules２を有するユーザがさらに
３０円を支払うことにより取得することが可能なUsage
Rules４、により構成されている。

【０１９０】ライセンスサーバ４は、コンテンツホルダ
サーバ６からこのプロダクト情報を取得すると、Usage
Rules１乃至Usage Rules４を分割する。そして、ライセ
ンスサーバ４は、状態テーブルとして、Usage Rules１
乃至Usage Rules４に対応した利用権購入状態のレコー
ドをLeafID、利用権ごとに生成、管理する。

【０１９１】すなわち、このテーブルでは、Usage Rule
s１乃至Usage Rules４をそれぞれ有する状態が、状態１
乃至状態４とされ、これらのいずれをも有していない状
態が状態０とされる。

【０１９２】このように、利用権所持の状態は、ライセ
ンスサーバ４により管理されているので、クライアント
１が管理する必要はない。従って、クライアント１の負
荷が軽減される。

【０１９３】すなわち、クライアント１は、Usage Rule
s１乃至Usage Rules４のうちのいずれか１つを適宜購入
するだけでよい。

【０１９４】例えば、クライアント１のユーザは、２０
０円を支払うことで、Usage Rules１を含む利用権を取
得することができ、さらに１００円を追加的に支払うこ
とで、Usage Rules２を含む利用権を取得することがで
きる。

【０１９５】クライアント１がいずれの利用権を取得す
る場合においても、同一のプロトコルを使用することが
可能であるが、利用権の内容に応じて、使用するプロト
コルを変更することも可能である。次に、この使用権に
応じて、プロトコルを変更する例について説明する。

【０１９６】この実施の形態では、図３５に示されるよ
うに、ライセンスサーバ４からクライアント１に対し
て、利用権を配布するプロトコルには、簡易購入プロト
コルと権利更新プロトコルの２種類が用意される。簡易
購入プロトコルは、特殊な認証が不要とされるプロトコ
ルであり、権利更新プロトコルは、特殊な認証が必要と
されるプロトコルである。すなわち、権利更新プロトコ
ルは、簡易購入プロトコルに比べて、よりセキュアな環
境化での通信が行われるものである。

【０１９７】簡易購入プロトコルにおいては、利用権
は、ライセンスサーバ４からクライアント１に対して、
単にダウンロードされる。これに対して、権利更新プロ
トコルにおいては、ライセンスサーバ４がクライアント
１が有する利用権を更新する処理を実行するため認証処
理が行われる。

【０１９８】次に、図３６のフローチャートを参照し
て、クライアント１がライセンスサーバ４から、利用権
の内容に応じて、異なるプロトコルで利用権を取得する
処理について説明する。

【０１９９】ステップＳ４６１において、クライアント
１のCPU２１は、ライセンスサーバ４にアクセスする。
ステップＳ４１２において、CPU２１は、ユーザからの
指令に基づいて、ユーザが希望する利用権に関する情報
を通信部２９を介してライセンスサーバ４に送信する。

【０２００】図３７のフローチャートを参照して後述す
るように、クライアント１が希望するのが、サブスクリ
プションサービスの利用権である場合には、ライセンス
サーバ４からAKE(Authentication Key Exchange)処理が
要求されてくる（図３７のステップＳ４４８）。これに
対して、取得する利用権がサブスクリプションサービス
の利用権ではない場合（買い取り用、または試聴用であ
る場合）には、AKE処理が要求されてこない。そこで、
ステップＳ４１３において、CPU２１は、ライセンスサ
ーバ４からAKE処理が要求されたか否かを判定し、AKE処
理が要求されてこない場合には、ステップＳ４１４に進
み、記憶部２８に記憶されているリーフIDを読み出し、
通信部２９を介してライセンスサーバ４に送信させる。

【０２０１】このとき、ライセンスサーバ４は、クライ
アント１が希望した利用権に、それに対応するデジタル
署名を付加してクライアント１に送信してくる（図３７
のステップＳ４４７）。そこで、ステップＳ４１５にお
いて、クライアント１のCPU２１は、クライアントサー
バ４から送信されてきた利用権とデジタル署名を受信す
る。ステップＳ４１６において、CPU２１は、ステップ
Ｓ４１５で受信したデジタル署名をライセンスサーバ４
の公開鍵SPで復号する。このライセンスサーバの公開鍵
SPは、リーフIDとともに、登録処理において、取得さ
れ、記憶部２８に記憶されているものである（図６のス
テップＳ５３）。

【０２０２】ステップＳ４１７において、CPU２１は、
ステップＳ４１５の処理で受信した利用権は、ステップ
Ｓ４１６の処理でデジタル署名を復号して得られた利用
権と一致するか否かを判定する。両者が一致する場合に
は、適正な（改竄されていない）利用権であるので、CP
U２１は、ステップＳ４１８において、その利用権を記
憶部２８に記憶させる。

【０２０３】それに対して、２つの利用権が一致しない
場合には、正しい利用権ではないので、ステップＳ４２
６に進み、CPU２１は、エラー処理を実行する。

【０２０４】一方、ステップＳ４１３において、AKE処
理が要求されたと判定された場合、ステップＳ４１９に
進み、CPU２１は、ライセンスサーバ４との間でAKE処理
を実行する。すなわち、これにより、よりセキュアな通
信路を確保する処理が実行され、セッション鍵が共有さ
れる。

【０２０５】ステップＳ４２０において、CPU２１は、A
KE処理により、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を挿入した利
用権と、ステップＳ４４６の処理で作成したデジタル署
名とを、クライアント１に送信する。

【０２１５】このようにして、送信した利用権とデジタ
ル署名が、図３６のステップＳ４１５において、クライ
アント１により受信されることになる。

【０２１６】一方、ステップＳ４４４において、クライ
アント１が希望している利用権がサブスクリプションサ
ービスの利用権である（買い取り用または試聴用ではな
い）と判定された場合、よりセキュアな環境化で通信を
行う必要がある。そこで、ステップＳ４４８に進み、CP
U２１は、クライアント１に対してAKE処理を要求し、AK
E処理を実行する。

【０２１７】ステップＳ４４９において、CPU２１は、S
ACが形成できたか否かを判定する。SACが形成できた場
合には、ステップＳ４５１に進み、CPU２１は、クライ
アント１が希望する利用権に使用状態（Usage Status）
を付加する。ステップＳ４５２において、CPU２１は、
クライアント１が希望する利用権にリーフIDを挿入し、
ステップＳ４４８のAKE処理で得られたセッション鍵で
暗号化する。

【０２１８】ステップＳ４５３において、CPU２１は、
自分自身の秘密鍵を用いて、ステップＳ４５２の処理で
リーフIDが挿入され、セッション鍵で暗号化された利用
権のデジタル署名を作成する。

【０２１９】ステップＳ４５４において、CPU２１は、
ステップＳ４５２の処理でセッション鍵で暗号化された
利用権と、ステップＳ４５３の処理で作成されたデジタ
ル署名とを、クライアント１に送付する。

【０２２０】このようにして、送付された利用権とデジ
タル署名は、上述したように、クライアント１により、
ステップＳ４２２において受信される。

【０２２１】ステップＳ４４９において、SACが形成で
きなかったと判定された場合には、セキュアな通信路が
確保できなかったので、ステップＳ４５０に進み、エラ
ー処理が実行される。

【０２２２】すなわち、この場合には、利用権は、クラ
イアント１に対して配布されないことになる。

【０２２３】よりセキュアな状態での利用権の配布を望
まないユーザは、そのための機能を設ける必要がないの
で、ユーザに必要以上の負担をかけることなく、利用権
を配布することが可能となる。また、セキュアな環境下
での利用権の取得を希望するユーザに対しては、より安
全に利用権を配布することが可能となる。その結果、利
用権が第３者に盗用されるようなことが防止される。

【０２２４】以上のようにして、コンテンツと利用権を
得たクライアント１は、利用権に基づいて、コンテンツ
を使用する（例えば、再生する）処理を実行する。

【０２２５】次に、この場合の処理について、図３８の
フローチャートを参照して説明する。

【０２２６】ステップＳ４７１において、クライアント
１のCPU２１は、ライセンスサーバ４にアクセスする。
ステップＳ４７２において、CPU２１は、ライセンスサ
ーバ４との間でAKE処理を実行する。

【０２２７】ステップＳ４７３において、CPU２１は、S
ACが形成できたか否かを判定する。SACが形成できた場
合には、ライセンスサーバ４から使用状態、リーフID、
およびコンテンツ情報の送信を要求してくる（後述する
図３９のステップＳ４９５）。

【０２２８】そこで、ステップＳ４７５において、クラ
イアント１のCPU２１は、ライセンスサーバ４からのこ
の要求を受信する。この要求は、ステップＳ４７２のAK
E処理で得られたセッション鍵で暗号化されている。そ
こで、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は、先頭に記述するdoma
in_idで、それを適用するドメインを規定する。さら
に、それに続く'｛'・・・'｝'内に、各種ルールが規定
されるが、その中は、ルールセクション、invariables
セクション、およびoverhead partの３つのセクション
に分かれる。

【０２５４】ルールセクションは、'｛'・・・'｝'の先
頭で、複数のdomain_ruleを記述することができる。inv
ariablesセクションは、ルールセクションに続き、キー
ワード'invariables:'によって始まる部分である。over
head 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セクションは、各種定数を記
述する部分であり、次の形式でCharsCodeに値を定義す
る。

【０２６８】＜Chars Code＞'＝' ＜値＞'；'

【０２６９】複数のinvariablesを定義する場合には、
次に示されるように、'，'で区切って記述が行われる。

【０２７０】＜Chars Code＞'＝'＜値＞'，'＜Chars Co
de＞'＝'＜値＞・・・'；'

【０２７１】＜Chars Code＞は、その名称と意味があら
かじめ規定されている。

【０２７２】overhead partは、各ドメイン毎の独自の
ルールを記述する部分である。

【０２７３】Char CodeはUsage Rulesのinvariablesセ
クション内で定義される以外に、利用権、コンテンツ、
使用状態等の中で定義されていても良い。

【０２７４】以上のルール記述言語で記載された例が図
４３に示されている。

【０２７５】なお、上述したコンテンツサーバ３、ライ
センスサーバ４、課金サーバ５、並びにコンテンツホル
ダサーバ６のいずれか２つ以上は、必要に応じて実質的
に１つのサーバに統合させることも可能である。

【０２７６】また、本実施の形態では、暗号化されたコ
ンテンツを復号するための鍵情報はコンテンツに含まれ
ているが、利用権に鍵情報を含む、あるいはコンテンツ
に含まれる鍵情報と利用権に含まれる鍵情報とを組み合
わせることで復号可能となるようにしても良い。

【０２７７】本発明が適用されるクライアントは、いわ
ゆるパーソナルコンピュータ以外に、PDA（Personal Di
gital Assistants）、携帯電話機、ゲーム端末機などと
することができる。

【０２７８】一連の処理をソフトウエアにより実行させ
る場合には、そのソフトウエアを構成するプログラム
が、専用のハードウエアに組み込まれているコンピュー
タ、または、各種のプログラムをインストールすること
で、各種の機能を実行することが可能な、例えば汎用の
パーソナルコンピュータなどに、ネットワークや記録媒
体からインストールされる。

【０２７９】この記録媒体は、図２に示されるように、
装置本体とは別に、ユーザにプログラムを提供するため
に配布される、プログラムが記録されている磁気ディス
ク４１（フレキシブルディスクを含む）、光ディスク４
２（CD-ROM(Compact Disk -Read Only Memory),DVD(Dig
ital Versatile Disk)を含む）、光磁気ディスク４３
（ＭＤ（Mini-Disk）（商標）を含む）、もしくは半導
体メモリ４４などよりなるパッケージメディアにより構
成されるだけでなく、装置本体に予め組み込まれた状態
でユーザに提供される、プログラムが記録されているRO
M２２や、記憶部２８に含まれるハードディスクなどで
構成される。

【０２８０】なお、本明細書において、記録媒体に記録
されるプログラムを記述するステップは、記載された順
序に沿って時系列的に行われる処理はもちろん、必ずし
も時系列的に処理されなくとも、並列的あるいは個別に
実行される処理をも含むものである。

【０２８１】また、セキュリティに関連する処理を実行
させるプログラムは、その処理を解析されるのを防ぐた
め、そのプログラム自体が暗号化されているのが望まし
い。例えば、暗号処理などを行う処理については、その
プログラムをタンパーレジスタントモジュールとして構
成することができる。

【０２８２】また、上記実施の形態では、コンテンツを
利用するために必要な利用権を特定するためにコンテン
ツの属性と利用権のコンテンツ条件を用いたが、これに
限らない。例えば、コンテンツに、該コンテンツを利用
するために必要な利用権の利用権IDを含むようにしても
良く、この場合、コンテンツを指定すればそれを利用す
るために必要な利用権は一意に決まるため、両者のマッ
チングを決定する処理を行う必要はない。

【０２８３】

【発明の効果】以上の如く、本発明によれば、利用権を
ユーザに配布することができる。特に、その場合におい
て、内容を細かく分割した利用権をユーザに配布するこ
とができる。さらに、ユーザに対して重い負荷をかける
ことなく、利用権を配布することが可能となる。

【図面の簡単な説明】

【図１】本発明を適用したコンテンツ提供システムの構
成を示す図である。

【図２】図１のライセンスサーバの構成を示すブロック
図である。

【図３】図１のクライアントのコンテンツのダウンロー
ド処理を説明するフローチャートである。

【図４】図１のコンテンツサーバのコンテンツ提供処理
を説明するフローチャートである。

【図５】図４のステップＳ２６におけるフォーマットの
例を示す図である。

【図６】図１のクライアントのコンテンツ再生処理を説
明するフローチャートである。

【図７】図６のステップＳ４３の利用権取得処理の詳細
を説明するフローチャートである。

【図８】利用権の構成を示す図である。

【図９】図１のライセンスサーバの利用権提供の処理を
説明するフローチャートである。

【図１０】キーの構成を説明する図である。

【図１１】カテゴリノードを説明する図である。

【図１２】ノードとデバイスの対応の具体例を示す図で
ある。

【図１３】有効化キーブロックの構成を説明する図であ
る。

【図１４】有効化キーブロックの構成を説明する図であ
る。

【図１５】有効化キーブロックの利用を説明する図であ
る。

【図１６】有効化キーブロックのフォーマットの例を示
す図である。

【図１７】有効化キーブロックのタグの構成を説明する
図である。

【図１８】DNKを用いたコンテンツの復号処理を説明す
る図である。

【図１９】有効化キーブロックの例を示す図である。

【図２０】複数のコンテンツの１つのデバイスに対する
割り当てを説明する図である。ライセンスのカテゴリを
説明する図である。

【図２１】図１のコンテンツホルダサーバの利用権提供
処理を説明するフローチャートである。

【図２２】図１のライセンスサーバの利用権取得処理を
説明するフローチャートである。

【図２３】図１のコンテンツホルダサーバが提供する利
用権の例を示す図である。

【図２４】図２３の利用権を分割した例を示す図であ
る。

【図２５】図２２のステップＳ３０３の利用権分割処理
の例を示すフローチャートである。

【図２６】図２２のステップＳ３０２において登録され
る利用権の例を示す図である。

【図２７】図２６の利用権から分割された利用権の例を
示す図である。

【図２８】図２２のステップＳ３０３の利用権分割処理
の他の例を示すフローチャートである。

【図２９】図２８のステップＳ３５１の処理で登録され
る利用権の例を示す図である。

【図３０】利用権の分割を説明する図である。

【図３１】図１のコンテンツホルダサーバからライセン
スサーバに提供される利用権の例を示す図である。

【図３２】利用権の購入とアップグレードの処理を説明
するフローチャートである。

【図３３】利用権分割の処理における表示例を示す図で
ある。

【図３４】図１のライセンスサーバにおける使用状態の
管理を説明する図である。

【図３５】複数のプロトコルを説明する図である。

【図３６】図１のクライアントの利用権取得処理を説明
するフローチャートである。

【図３７】図１のライセンスサーバの利用権配布処理を
説明するフローチャートである。

【図３８】図１のクライアントの利用権使用処理を説明
するフローチャートである。

【図３９】図１のライセンスサーバの使用状態更新処理
を説明するフローチャートである。

【図４０】Usage Rulesの基本的な記述方法を説明する
図である。

【図４１】UsageRuleの記述形式の例を示す図である。

【図４２】演算子の例を示す図である。

【図４３】ルール記述言語で記載された使用条件の例を
示す図である。

【符号の説明】

１−１，１−２ クライアント， ２ インターネッ
ト， ３ コンテンツサーバ， ４ ライセンスサー
バ， ５ 課金サーバ，６ コンテンツホルダサーバ，
２０ タイマ， ２１ CPU， ２４ 暗号化復号
部， ２５ コーデック部， ２６ 入力部， ２７
出力部， ２８ 記憶部， ２９ 通信部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 江面 裕一 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 長野 元彦 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内

Claims (7)

【特許請求の範囲】
1. 【請求項１】 コンテンツの使用条件を規定する利用権
   を配布する情報処理装置において、 前記使用条件を含む情報を受信する受信手段と、 前記受信手段により受信された前記使用条件から一部を
   抽出し、部分使用条件を生成する抽出手段と、 前記抽出手段により生成された前記部分使用条件をユー
   ザに配布する配布手段とを備えることを特徴とする情報
   処理装置。
2. 【請求項２】 前記部分使用条件から前記利用権を生成
   する生成手段をさらに備えることを特徴とする請求項１
   記載の情報処理装置。
3. 【請求項３】 前記受信手段が受信する前記使用条件
   は、対応するコンテンツの利用形態毎に定義されてお
   り、 前記抽出手段は少なくとも１つ以上の前記利用形態に関
   する使用条件を含む部分使用条件を生成することを特徴
   とする請求項１記載の情報処理装置。
4. 【請求項４】 前記受信手段によって受信される前記情
   報は、前記使用条件に対応する課金情報を含むことを特
   徴とする請求項１記載の情報処理装置。
5. 【請求項５】 コンテンツの使用条件を規定する利用権
   を配布する情報処理装置の情報処理方法において、 前記使用条件を含む情報を受信する受信ステップと、 前記受信ステップの処理により受信された前記使用条件
   から一部を抽出し、部分使用条件を生成する抽出ステッ
   プと、 前記抽出ステップの処理により生成された前記部分使用
   条件をユーザに配布する配布ステップとを含むことを特
   徴とする情報処理方法。
6. 【請求項６】 コンテンツの使用条件を規定する利用権
   を配布する情報処理装置のプログラムであって、 前記使用条件を含む情報を受信する受信ステップと、 前記受信ステップの処理により受信された前記使用条件
   から一部を抽出し、部分使用条件を生成する抽出ステッ
   プと、 前記抽出ステップの処理により生成された前記部分使用
   条件をユーザに配布する配布ステップとを含むことを特
   徴とするコンピュータが読み取り可能なプログラムが格
   納されているプログラム格納媒体。
7. 【請求項７】 コンテンツの使用条件を規定する利用権
   を配布する情報処理装置を制御するコンピュータに、 前記使用条件を含む情報を受信する受信ステップと、 前記受信ステップの処理により受信された前記使用条件
   から一部を抽出し、部分使用条件を生成する抽出ステッ
   プと、 前記抽出ステップの処理により生成された前記部分使用
   条件をユーザに配布する配布ステップとを実行させるこ
   とを特徴とするプログラム。