JP2002359616A - 情報処理装置および方法、ライセンスサーバ、並びにプログラム - Google Patents

Abstract

(57)【要約】 【課題】 コンテンツの配布を自由に行うことができ、
許可されたユーザのみがコンテンツを利用できるように
する。 【解決手段】 クライアントは暗号化されたコンテンツ
をコンテンツサーバから受け取る。コンテンツのヘッダ
にはそのコンテンツを利用するとき必要とされるライセ
ンスを特定するためのライセンス特定情報が記述されて
おり、クライアントはライセンス特定情報を元にライセ
ンスサーバにライセンスを要求する。ライセンスサーバ
は、ライセンス要求を受け取ると、課金処理を行った
後、該当するライセンスをクライアントに送信する。ク
ライアントはライセンスを保持していることを条件とし
て、コンテンツを復号し再生する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置およ
び方法、ライセンスサーバ、並びにプログラムに関し、
特に、著作権者からライセンスを受けていないコンテン
ツが不正にコピーされ、利用されるのを防止することが
できるようにした、情報処理装置および方法、ライセン
スサーバ、並びにプログラムに関する。

【０００２】

【従来の技術】最近、インターネットを介して、ユーザ
が、自分自身が保持している音楽データを他のユーザに
提供し、自分自身が保持していない音楽データを他のユ
ーザから提供を受けるようにして、複数のユーザが無料
で音楽データを交換しあうシステムが実現されている。

【０００３】このようなシステムでは、理論的には、１
つの音楽、その他のコンテンツが存在すれば、他の全て
のユーザが、それを利用することが可能となり、多くの
ユーザがコンテンツを購入しなくなるため、コンテンツ
に関する著作権者は、著作物としてのコンテンツが売れ
ないため、著作物の販売に伴い、本来受け取ることが可
能な著作物の利用に関するロイヤリティを受け取る機会
を失うことになる。

【０００４】

【発明が解決しようとする課題】そこで、コンテンツの
流通を妨げることなく、不正に利用されることを防止す
ることが、社会的に要請されている。

【０００５】本発明はこのような状況に鑑みてなされた
ものであり、コンテンツが不正に利用されるのを確実に
防止することができるようにするものである。

【０００６】

【課題を解決するための手段】本発明の情報処理装置
は、コンテンツを利用許可するために必要なライセンス
を特定するためのライセンス特定情報と、暗号化された
コンテンツデータと、コンテンツデータを復号するため
に必要な鍵情報とを含むコンテンツを記憶するコンテン
ツ記憶手段と、利用許可されるコンテンツを特定するた
めのコンテンツ特定情報を含むライセンスを記憶するラ
イセンス記憶手段と、コンテンツを利用許可することが
できるライセンスがライセンス記憶手段に記憶されてい
るか否かを判定する判定手段と、判定手段によりライセ
ンスが記憶されていると判断されたことを条件としてコ
ンテンツのコンテンツデータを復号する復号手段とを備
えることを特徴とする。

【０００７】情報処理装置は更に、ライセンスサーバに
ライセンスを識別するためのライセンス識別情報を含む
ライセンス要求を送信する送信手段と、ライセンスサー
バによって送信されたライセンスを受信する受信手段と
を備え、受信手段により受信されたライセンスはライセ
ンス記憶手段に記憶されるようにすることができる。

【０００８】コンテンツデータはテキストデータ、画像
データ、音声データ、動画データあるいはそれらを組み
合わせたデータであり、復号手段により復号されたコン
テンツデータを再生する再生手段を更に備えるようにす
ることができる。

【０００９】鍵情報はEKB（Enabling Key Block）を含
み、情報処理装置は更にデバイスノードキーを記憶する
デバイスノードキー記憶手段を備え、復号手段はデバイ
スノードキー記憶手段に記憶されているデバイスノード
キーを用いてEKB（EnablingKey Block）を復号処理し得
られたルートキーを用いて暗号化されたコンテンツデー
タを復号するようにすることができる。

【００１０】鍵情報は更にEKB（Enabling Key Block）
のルートキーによって暗号化されたコンテンツキーを含
み、コンテンツデータはコンテンツキーにより暗号化さ
れており、復号手段はデバイスノードキー記憶手段に記
憶されているデバイスノードキーを用いてEKB（Enablin
g Key Block）を復号処理し得られたルートキーを用い
て復号されたコンテンツキーを用いて暗号化されたコン
テンツデータを復号するようにすることができる。

【００１１】ライセンスは更に、そのライセンスによっ
て利用可能となるコンテンツの使用条件を示す使用条件
情報を含むようにすることができる。

【００１２】ライセンスは更に、ライセンスサーバの秘
密鍵によりなされた電子署名を含むようにすることがで
きる。

【００１３】情報処理装置は、更に情報処理装置を識別
する端末識別情報を記憶する端末識別情報記憶手段を備
え、ライセンス要求は更に、端末識別情報記憶手段に記
憶されている端末識別情報を含み、受信手段により受信
されたライセンスは更に、端末識別情報を含み、判定手
段は、ライセンスに含まれる端末識別情報と端末識別情
報記憶手段に記憶されている端末識別情報とを比較し、
両者が一致している場合に限り、そのライセンスをコン
テンツの利用を許可できるライセンスであると判定する
ようにすることができる。

【００１４】本発明の情報処理方法は、コンテンツを利
用許可するライセンスを特定するためのライセンス特定
情報と、暗号化されたコンテンツデータと、コンテンツ
データを復号するために必要な鍵情報と、を含むコンテ
ンツを記憶するステップと、利用許可されるコンテンツ
を特定するためのコンテンツ特定情報を含むライセンス
を記憶するステップと、コンテンツを利用許可すること
ができるライセンスがライセンス記憶手段に記憶されて
いるか否かを判定するステップと、判定手段によりライ
センスが記憶されていると判断されたことを条件として
コンテンツのコンテンツデータを復号するステップとを
含むことを特徴とする。

【００１５】本発明のプログラムは、コンテンツを利用
許可するライセンスを特定するためのライセンス特定情
報と、暗号化されたコンテンツデータと、コンテンツデ
ータを復号するために必要な鍵情報と、を含むコンテン
ツを記憶するステップと、利用許可されるコンテンツを
特定するためのコンテンツ特定情報を含むライセンスを
記憶するステップと、コンテンツを利用許可することが
できるライセンスがライセンス記憶手段に記憶されてい
るか否かを判定するステップと、判定手段によりライセ
ンスが記憶されていると判断されたことを条件としてコ
ンテンツのコンテンツデータを復号するステップとをコ
ンピュータに実行させる。

【００１６】プログラムあるいはその一部が暗号化され
ているようにすることができる。

【００１７】本発明のライセンスサーバは、許可される
コンテンツを特定するためのコンテンツ特定情報と、情
報処理装置を識別する端末識別情報を含むライセンスを
記憶するライセンス記憶手段と、情報処理装置から送信
された、ライセンスを識別するライセンス識別情報を含
むライセンス要求を受信する受信手段と、ライセンス要
求に含まれるライセンス識別情報に対応するライセンス
をライセンス記憶手段から抽出する抽出手段と、抽出手
段により抽出されたライセンスに端末識別情報を付加す
る処理手段と、ライセンスサーバの秘密鍵を用いて、処
理手段により端末識別情報を付加されたライセンスに電
子署名を付加する署名手段と、署名手段により署名され
たライセンスをライセンス要求を送信した情報処理装置
に送信する送信手段とを備えることを特徴とする。

【００１８】本発明の情報処理方法は、利用許可される
コンテンツを特定するためのコンテンツ特定情報と、情
報処理装置を識別する端末識別情報を含むライセンスを
記憶するステップと、情報処理装置から送信された、ラ
イセンスを識別するライセンス識別情報を含むライセン
ス要求を受信するステップと、ライセンス要求に含まれ
るライセンス識別情報に対応するライセンスをライセン
ス記憶手段から抽出するステップと、抽出手段により抽
出されたライセンスに端末識別情報を付加するステップ
と、ライセンスサーバの秘密鍵を用いて、処理手段によ
り端末識別情報を付加されたライセンスに電子署名を付
加するステップと、署名手段により署名されたライセン
スをライセンス要求を送信した情報処理装置に送信する
ステップとを含むことを特徴とする。

【００１９】本発明の情報処理装置、情報処理方法、並
びにプログラムでは、ライセンスを保持していることを
条件としてコンテンツを復号し、利用可能にする。

【００２０】本発明のライセンスサーバ、並びに情報処
理方法では、特定の情報処理装置でのみ有効なライセン
スを発行する。

【００２１】

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

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

【００２３】これらのコンテンツサーバ３、ライセンス
サーバ４、および課金サーバ５も、任意の台数、インタ
ーネット２に接続される。

【００２４】図２はクライアント１の構成を表してい
る。

【００２５】図２において、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などより
なるディスプレイ、並びにスピーカなどよりなる出力部
２７、ハードディスクなどより構成される記憶部２８、
モデム、ターミナルアダプタなどより構成される通信部
２９が接続されている。通信部２９は、インターネット
２を介しての通信処理を行う。通信部２９はまた、他の
クライアントとの間で、アナログ信号またはデジタル信
号の通信処理を行う。

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

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

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

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

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

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

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

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

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

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

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

【００４１】ヘッダには、コンテンツ情報（Content in
formation）、デジタル権利管理情報（DRM（Digital Ri
ght Management） information ）、ライセンスID（Lic
ense ID）、イネーブリングキーブロック（有効化キー
ブロック）（EKB（EnablingKey Block））および、EKB
から生成されたキーK_EKBCを用いて暗号化されたコンテ
ンツキーKcとしてのデータK_EKBC（Kc）が配置されてい
る。なお、EKBについては、図１５を参照して後述す
る。

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

【００４３】デジタル権利管理情報には、コンテンツを
使用する規則および状態（Usage rules/status）と、UR
L（Uniform Resource Locator）が配置されている。使
用規則および状態には、例えば、コンテンツの再生回
数、コピー回数などが記述される。

【００４４】URLは、ライセンス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２１は、コンテンツが指示さ
れると、そのコンテンツに対応するライセンスID（その
コンテンツを使用するのに必要なライセンスのID）を読
み取る。このライセンスIDは、図５に示されるように、
暗号化されているコンテンツデータのヘッダに記述され
ているものである。

【００５８】次に、ステップＳ４２に進み、CPU２１
は、ステップＳ４１で読み取られたライセンスIDに対応
するライセンスが、クライアント１により既に取得さ
れ、記憶部２８に記憶されているか否かを判定する。ま
だ、ライセンスが取得されていない場合には、ステップ
Ｓ４３に進み、CPU２１は、ライセンス取得処理を実行
する。このライセンス取得処理の詳細は、図７のフロー
チャートを参照して後述する。

【００５９】ステップＳ４２において、ライセンスが既
に取得されていると判定された場合、または、ステップ
Ｓ４３において、ライセンス取得処理が実行された結
果、ライセンスが取得された場合、ステップＳ４４に進
み、CPU２１は、取得されているライセンスは有効期限
内のものであるか否かを判定する。ライセンスが有効期
限内のものであるか否かは、ライセンスの内容として規
定されている期限（後述する図８参照）と、タイマ２０
により計時されている現在日時と比較することで判断さ
れる。ライセンスの有効期限が既に満了していると判定
された場合、CPU２１は、ステップＳ４５に進み、ライ
センス更新処理を実行する。このライセンス更新処理の
詳細は、図１０のフローチャートを参照して後述する。

【００６０】ステップＳ４４において、ライセンスはま
だ有効期限内であると判定された場合、または、ステッ
プＳ４５において、ライセンスが更新された場合、ステ
ップＳ４６に進み、CPU２１は、暗号化されているコン
テンツデータを記憶部２８から読み出し、RAM２３に格
納させる。そして、ステップＳ４７において、CPU２１
は、RAM２３に記憶された暗号化ブロックのデータを、
図５のデータに配置されている暗号化ブロック単位で、
暗号化復号部２４に供給し、コンテンツキーKcを用いて
復号させる。

【００６１】コンテンツキーKcを得る方法の具体例は、
図１５を参照して後述するが、デバイスノードキー（DN
K）（図８）を用いて、EKB（図５）に含まれるキーＫ
_EKBCを得ることができ、そのキーＫ_EKBCを用いて、デー
タＫ_EKBC（Kc）（図５）から、コンテンツキーKcを得る
ことができる。

【００６２】CPU２１は、さらに、ステップＳ４８にお
いて、暗号化復号部２４により復号されたコンテンツデ
ータをコーデック部２５に供給し、デコードさせる。そ
して、コーデック部２５によりデコードされたデータ
を、CPU２１は、入出力インタフェース３２から出力部
２７に供給し、D/A変換させ、スピーカから出力させ
る。

【００６３】次に、図７のフローチャートを参照して、
図６のステップＳ４３で行われるライセンス取得処理の
詳細について説明する。

【００６４】クライアント１は、事前にライセンスサー
バに登録することにより、リーフID、DNK(Device Node
Key)、クライアント１の秘密鍵・公開鍵のペア、ライセ
ンスサーバの公開鍵、及び各公開鍵の証明書を含むサー
ビスデータを取得しておく。

【００６５】リーフIDは、クライアント毎に割り当てら
れた識別情報を表し、DNKは、そのライセンスに対応す
るEKB（有効化キーブロック）に含まれる暗号化されて
いるコンテンツキーKcを復号するのに必要なデバイスノ
ードキーである（図１２を参照して後述する）。

【００６６】最初にステップＳ６１において、CPU２１
は、いま処理対象とされているライセンスIDに対応する
URLを、図５に示すヘッダから取得する。上述したよう
に、このURLは、やはりヘッダに記述されているライセ
ンスIDに対応するライセンスを取得するときアクセスす
べきアドレスである。そこで、ステップＳ６２におい
て、CPU２１は、ステップＳ６１で取得したURLにアクセ
スする。具体的には、通信部２９によりインターネット
２を介してライセンスサーバ４にアクセスが行われる。
このとき、ライセンスサーバ４は、クライアント１に対
して、購入するライセンス（コンテンツを使用するのに
必要なライセンス）を指定するライセンス指定情報、並
びにユーザIDとパスワードの入力を要求してくる（後述
する図９のステップＳ１０２）。CPU２１は、この要求
を出力部２７の表示部に表示させる。ユーザは、この表
示に基づいて、入力部２６を操作して、ライセンス指定
情報、ユーザID、およびパスワードを入力する。なお、
このユーザIDとパスワードは、クライアント１のユーザ
が、インターネット２を介してライセンスサーバ４にア
クセスし、事前に取得しておいたものである。

【００６７】CPU２１は、ステップＳ６３，Ｓ６４にお
いて、入力部２６から入力されたライセンス識別情報を
取り込むとともに、ユーザIDとパスワードを取り込む。
CPU２１は、ステップＳ６５において、通信部２９を制
御し、入力されたユーザIDとパスワードを、ライセンス
指定情報及びサービスデータ（後述する）に含まれるリ
ーフIDを含むライセンス要求をインターネット２を介し
てライセンスサーバ４に送信させる。

【００６８】ライセンスサーバ４は、図９を参照して後
述するように、ユーザIDとパスワード、並びにライセン
ス指定情報に基づいてライセンスを送信してくる（ステ
ップＳ１０９）か、または、条件が満たされない場合に
は、ライセンスを送信してこない（ステップＳ１１
２）。

【００６９】ステップＳ６６において、CPU２１は、ラ
イセンスサーバ４からライセンスが送信されてきたか否
かを判定し、ライセンスが送信されてきた場合には、ス
テップＳ６７に進み、そのライセンスを記憶部２８に供
給し、記憶させる。

【００７０】ステップＳ６６において、ライセンスが送
信されて来ないと判定した場合、CPU２１は、ステップ
Ｓ６８に進み、エラー処理を実行する。具体的には、CP
U２１は、コンテンツを利用するためのライセンスが得
られないので、コンテンツの再生処理を禁止する。

【００７１】以上のようにして、各クライアント１は、
コンテンツデータに付随しているライセンスIDに対応す
るライセンスを取得して、初めて、そのコンテンツを使
用することが可能となる。

【００７２】なお、図７のライセンス取得処理は、各ユ
ーザがコンテンツを取得する前に、予め行っておくよう
にすることも可能である。

【００７３】クライアント１に提供されるライセンス
は、例えば、図８に示されるように、使用条件、リーフ
IDおよびを含んでいる。

【００７４】使用条件には、そのライセンスに基づい
て、コンテンツを使用することが可能な使用期限、その
ライセンスに基づいて、コンテンツをダウンロードする
ことが可能なダウンロード期限、そのライセンスに基づ
いて、コンテンツをコピーすることが可能な回数（許さ
れるコピー回数）、チェックアウト回数、最大チェック
アウト回数、そのライセンスに基づいて、コンテンツを
CD-Rに記録することができる権利、PD（Portable Devic
e）にコピーすることが可能な回数、ライセンスを所有
権（買い取り状態）に移行できる権利、使用ログをとる
義務等を示す情報が含まれる。

【００７５】次に、図９のフローチャートを参照して、
図７のクライアント１のライセンス取得処理に対応して
実行されるライセンスサーバ４のライセンス提供処理に
ついて説明する。なお、この場合においても、図２のク
ライアント１の構成は、ライセンスサーバ４の構成とし
て引用される。

【００７６】ステップＳ１０１において、ライセンスサ
ーバ４のCPU２１は、クライアント１よりアクセスを受
けるまで待機し、アクセスを受けたとき、ステップＳ１
０２に進み、アクセスしてきたクライアント１に対し
て、ユーザIDとパスワード、並びに、ライセンス指定情
報の送信を要求する。上述したようにして、クライアン
ト１から、図７のステップＳ６５の処理で、ユーザIDと
パスワード、リーフID並びにライセンス指定情報（ライ
センスID）が送信されてきたとき、ライセンスサーバ４
のCPU２１は、通信部２９を介してこれを受信し、取り
込む処理を実行する。

【００７７】そして、ライセンスサーバ４のCPU２１
は、ステップＳ１０３において、通信部２９から課金サ
ーバ５にアクセスし、ユーザIDとパスワードに対応する
ユーザの与信処理を要求する。課金サーバ５は、インタ
ーネット２を介してライセンスサーバ４から与信処理の
要求を受けると、そのユーザIDとパスワードに対応する
ユーザの過去の支払い履歴などを調査し、そのユーザ
が、過去にライセンスの対価の不払いの実績があるか否
かなどを調べ、そのような実績がない場合には、ライセ
ンスの付与を許容する与信結果を送信し、不払いの実績
などがある場合には、ライセンス付与の不許可の与信結
果を送信する。

【００７８】ステップＳ１０４において、ライセンスサ
ーバ４のCPU２１は、課金サーバ５からの与信結果が、
ライセンスを付与することを許容する与信結果であるか
否かを判定し、ライセンスの付与が許容されている場合
には、ステップＳ１０５に進み、ステップＳ１０２の処
理で取り込まれたライセンス指定情報に対応するライセ
ンスを、記憶部２８に記憶されているライセンスの中か
ら取り出す。記憶部２８に記憶されているライセンス
は、あらかじめライセンスID、バージョン、作成日時、
有効期限等の情報が記述されている。ステップＳ１０６
において、CPU２１は、そのライセンスに受信したリー
フIDを付加する。さらに、ステップＳ１０７において、
CPU２１は、ステップＳ１０５で選択されたライセンス
に対応づけられている使用条件を選択する。あるいはま
た、ステップＳ１０２の処理で、ユーザから使用条件が
指定された場合には、その使用条件が必要に応じて、予
め用意されている使用条件に付加される。CPU２１は、
選択された使用条件をライセンスに付加する。

【００７９】ステップＳ１０８において、ＣＰＵ２１は
ライセンスサーバの秘密鍵によりライセンスに署名し、
これにより、図８に示されるような構成のライセンスが
生成される。

【００８０】次に、ステップＳ１０９に進み、ライセン
スサーバ４のCPU２１は、そのライセンス（図８に示さ
れる構成を有する）を、通信部２９からインターネット
２を介してクライアント１に送信させる。

【００８１】ステップＳ１１０においてライセンスサー
バ４のCPU２１は、ステップＳ１０９の処理で、いま送
信したライセンス（使用条件、リーフIDを含む）を、ス
テップＳ１０２の処理で取り込まれたユーザIDとパスワ
ードに対応して、記憶部２８に記憶させる。さらに、ス
テップＳ１１１において、CPU２１は、課金処理を実行
する。具体的には、CPU２１は、通信部２９から課金サ
ーバ５に、そのユーザIDとパスワードに対応するユーザ
に対する課金処理を要求する。課金サーバ５は、この課
金の要求に基づいて、そのユーザに対する課金処理を実
行する。上述したように、この課金処理に対して、その
ユーザが支払いを行わなかったような場合には、以後、
そのユーザは、ライセンスの付与を要求したとしても、
ライセンスを受けることができないことになる。

【００８２】すなわち、この場合には、課金サーバ５か
らライセンスの付与を不許可とする与信結果が送信され
てくるので、ステップＳ１０４からステップＳ１１２に
進み、CPU２１は、エラー処理を実行する。具体的に
は、ライセンスサーバ４のCPU２１は、通信部２９を制
御してアクセスしてきたクライアント１に対して、ライ
センスを付与することができない旨のメッセージを出力
し、処理を終了させる。

【００８３】この場合、上述したように、そのクライア
ント１はライセンスを受けることができないので、その
コンテンツを利用すること（暗号を復号すること）がで
きないことになる。

【００８４】図１０は、図６のステップＳ４５における
ライセンス更新処理の詳細を表している。図１０のステ
ップＳ１３１乃至ステップＳ１３５の処理は、図７のス
テップＳ６１乃至ステップＳ６５の処理と基本的に同様
の処理である。ただし、ステップＳ１３３において、CP
U２１は、購入するライセンスではなく、更新するライ
センスのライセンスIDを取り込む。そして、ステップＳ
１３５において、CPU２１は、ユーザIDとパスワードと
ともに、更新するライセンスのライセンスIDを、ライセ
ンスサーバ４に送信する。

【００８５】ステップＳ１３５の送信処理に対応して、
ライセンスサーバ４は、後述するように、使用条件を提
示してくる（図１１のステップＳ１５３）。そこで、ク
ライアント１のCPU２１は、ステップＳ１３６におい
て、ライセンスサーバ４からの使用条件の提示を受信
し、これを出力部２７に出力し、表示させる。ユーザ
は、入力部２６を操作して、この使用条件の中から所定
の使用条件を選択したり、所定の使用条件を新たに追加
したりする。ステップＳ１３７でCPU２１は、以上のよ
うにして選択された使用条件（ライセンスを更新する条
件）を購入するための申し込みをライセンスサーバ４に
送信する。この申し込みに対応して、後述するようにラ
イセンスサーバ４は、最終的な使用条件を送信してくる
（図１１のステップＳ１５４）。そこで、ステップＳ１
３８において、クライアント１のCPU２１は、ライセン
スサーバ４からの使用条件を取得し、ステップＳ１３９
において、その使用条件を記憶部２８にすでに記憶され
ている対応するライセンスの使用条件として更新する。

【００８６】図１１は、以上のクライアント１のライセ
ンス更新処理に対応して、ライセンスサーバ４が実行す
るライセンス更新処理を表している。

【００８７】最初に、ステップＳ１５１において、ライ
センスサーバ４のCPU２１は、クライアント１からのア
クセスを受けると、ステップＳ１５２において、クライ
アント１がステップＳ１３５で送信したライセンス指定
情報をライセンス更新要求情報とともに受信する。

【００８８】ステップＳ１５３において、CPU２１は、
ライセンスの更新要求を受信すると、そのライセンスに
対応する使用条件（更新する使用条件）を、記憶部２８
から読み出し、クライアント１に送信する。

【００８９】この提示に対して、上述したように、クラ
イアント１から使用条件の購入が図１０のステップＳ１
３７の処理で申し込まれると、ステップＳ１５４におい
て、ライセンスサーバ４のCPU２１は、申し込まれた使
用条件に対応するデータを生成し、ステップＳ１５４に
おいて、クライアントと１に送信する。クライアント１
は、上述したように、ステップＳ１３９の処理で受信し
た使用条件を用いて、すでに登録されているライセンス
の使用条件を更新する。

【００９０】本発明においては、図１２に示されるよう
に、ブロードキャストインクリプション（Broadcast En
cryption）方式の原理に基づいて、デバイスとライセン
スのキーが管理される。キーは、階層ツリー構造とさ
れ、最下段のリーフ（leaf）が個々のデバイスのキーに
対応する。図１２の例の場合、番号０から番号１５まで
の１６個のデバイスまたはライセンスに対応するキーが
生成される。

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

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

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

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

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

【００９６】各デバイスやライセンスのキーは、６４
（＝８＋２４＋３２）段の各ノードで構成されるパスの
内の１つに対応される。例えば、コンテンツを暗号化し
たコンテンツキーは、対応するライセンスに割り当てら
れたパスを構成するノードに対応するキーを用いて暗号
化される。上位の階層のキーは、その直近の下位の階層
のキーを用いて暗号化され、ＥＫＢ（図１５を参照して
後述する）内に配置される。最下段のＤＮＫは、ＥＫＢ
内には配置されず、サービスデータに記述され、ユーザ
のクライアント１に与えられる。クライアント１は、ラ
イセンスに記述されているＤＮＫを用いて、コンテンツ
データとともに配布されるＥＫＢ（図１５）内に記述さ
れている直近の上位の階層のキーを復号し、復号して得
たキーを用いて、ＥＫＢ内に記述されているさらにその
上の階層のキーを復号する。以上の処理を順次行うこと
で、クライアント１は、そのライセンスのパスに属する
すべてのキーを得ることができる。

【００９７】図１４に階層ツリー構造のカテゴリの分類
の具体的な例を示す。図１４において、階層ツリー構造
の最上段には、ルートキー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を利用して、E
KBからルートキーKRを得ることができる。さらに、ルー
トキーKRを用いて、Enc（KR，Kc）からコンテンツキーK
cを復号することができ、コンテンツキーKcを用いて、E
nc（Kc，Content）からコンテンツを復号することがで
きる。

【０１２５】このように、クライアント１にDNKを個別
に割り当てることにより、図１２と図１５を参照して説
明した原理に従って、個々のクライアント１のリボーク
（revoke）が可能になる。

【０１２６】また、ライセンスリーフIDを付加して配布
することにより、クライアント１において、サービスデ
ータとライセンスの対応付けが行われることになり、ラ
イセンスの不正コピーを防止することが可能になる。

【０１２７】また、クライアント用の証明書と秘密鍵を
サービスデータとして配信するようにすることで、エン
ドユーザも、これらを用いて不正コピーを防止可能なコ
ンテンツを作成することが可能になる。

【０１２８】証明書と秘密鍵の利用については、図２８
のフローチャートを参照して後述する。

【０１２９】本発明においては、図１３を参照して説明
したように、カテゴリノードにライセンスを管理するＴ
システムと、各種のコンテンツを利用するデバイスのカ
テゴリが対応づけられるので、複数のDNKを同一のデバ
イスに持たせることができる。その結果、異なるカテゴ
リのコンテンツを１つのデバイスで管理することが可能
となる。

【０１３０】図２１は、この関係を表している。すなわ
ち、デバイスＤ１には、Ｔシステムに基づいて、DNK１
が割り当てられている、コンテンツ１を利用するライセ
ンスが記録される。同様に、このデバイスＤ１には、例
えば、DNK２が割り当てられた、メモリスティックにCD
からリッピングしたコンテンツ２を記録することができ
る。この場合、デバイスＤ１は、コンテンツ１とコンテ
ンツ２という、異なるシステム（Ｔシステムとデバイス
管理システム）により配信されたコンテンツを同時に扱
うことが可能となる。新たなDNKを割り当てるとき、既
に割り当てられているDNKを削除するなどして、デバイ
スに１個のDNKだけを対応させるようにした場合、この
ようなことはできない。

【０１３１】また、図１３における、例えば、下側の３
２階層の各三角形の１つ１つに、図２２に示されるライ
センスカテゴリ１とライセンスカテゴリ２を割り当てる
ことにより、同一のカテゴリ内を、サブカテゴリを利用
して、コンテンツのジャンル、レーベル、販売店、配信
サービス等の小さな集まりに分類して、管理することが
可能となる。

【０１３２】図２２の例においては、例えば、ライセン
スカテゴリ１は、ジャズのジャンルに属し、ライセンス
カテゴリ２は、ロックのジャンルに属する。ライセンス
カテゴリ１には、ライセンスIDが１であるコンテンツ１
とコンテンツ２を対応させ、それぞれユーザ１乃至ユー
ザ３に配布されている。ライセンスカテゴリ２は、ライ
センスID２のコンテンツ３、コンテンツ４、およびコン
テンツ５が含まれ、それぞれユーザ１とユーザ３に提供
されている。

【０１３３】このように、本発明においては、カテゴリ
毎に独立したキー管理が可能になる。

【０１３４】また、DNKを、機器やメディアに予め埋め
込むのではなく、ライセンスサーバ４により、登録処理
を行う際に、各機器やメディアにダウンロードするよう
にすることで、ユーザによるキーの購入が可能なシステ
ムを実現することができる。

【０１３５】コンテンツは、それが作成された後、どの
ような使われ方をされようとも、その使われ方に関わり
なく、全ての用途において、使用可能であるのが望まし
い。例えば、異なるコンテンツ配信サービス、あるいは
使用条件が異なるドメインにおいても、同一のコンテン
ツが使えることが望ましい。本発明においては、このた
め、上述したように、各ユーザ（クライアント１）に、
認証局としてのライセンスサーバ４から秘密鍵と、それ
に対応する公開鍵の証明書（certificates）が配布され
る。各ユーザは、その秘密鍵を用いて、署名（signatur
e）を作成し、コンテンツに付加して、コンテンツの真
正さ(integrity)を保証し、かつコンテンツの改竄防止
を図ることができる。

【０１３６】この場合の処理の例について、図２３のフ
ローチャートを参照して説明する。図２３の処理は、ユ
ーザがCDから再生したデータを記憶部２８に記憶させる
リッピング処理を説明するものである。

【０１３７】最初に、ステップＳ１７１において、クラ
イアント１のCPU２１は、通信部２９を介して入力され
るCDの再生データを記録データとして取り込む。ステッ
プＳ１７２において、CPU２１は、ステップＳ１７１の
処理で取り込まれた記録データにウォーターマークが含
まれているか否かを判定する。このウォーターマーク
は、３ビットのコピー管理情報（CCI）と、１ビットの
トリガ（Trigger）とにより構成され、コンテンツのデ
ータの中に埋め込まれている。CPU２１は、ウォーター
マークが検出された場合には、ステップＳ１７３に進
み、そのウォーターマークを抽出する処理を実行する。
ウォーターマークが存在しない場合には、ステップＳ１
７３の処理はスキップされる。

【０１３８】次に、ステップＳ１７４において、CPU２
１は、コンテンツに対応して記録するヘッダのデータを
作成する。このヘッダのデータは、コンテンツID、ライ
センスID、ライセンスを取得するためのアクセス先を表
すURL、およびウォーターマークにより構成される。

【０１３９】次に、ステップＳ１７５に進み、CPU２１
は、ステップＳ１７４の処理で作成したヘッダのデータ
に基づいたデジタル署名を、自分自身の秘密鍵を用いて
作成する。この秘密鍵は、ライセンスサーバ４から取得
したものである（図７のステップＳ６７）。

【０１４０】ステップＳ１７６で、CPU２１は、暗号化
復号部２４を制御し、コンテンツキーでコンテンツを暗
号化させる。コンテンツキーは、コンテンツを取得した
とき、同時に取得されたものである（図５または図１
９）。

【０１４１】次に、ステップＳ１７７において、CPU２
１は、ファイルフォーマットに基づき、データを、例え
ば、ミニディスク等により構成される光磁気ディスク４
３に記録させる。

【０１４２】なお、記録媒体がミニディスクである場
合、ステップＳ１７６において、CPU２１は、コンテン
ツをコーデック部２５に供給し、例えば、ATRAC３方式
によりコンテンツを符号化させる。そして、符号化され
たデータが暗号化復号部２４によりさらに暗号化され
る。

【０１４３】図２４は、以上のようにして、記録媒体に
コンテンツが記録された状態を模式的に表している。暗
号化されているコンテンツ（Ｅ（At３））から抽出され
たウォーターマーク（WM）が、コンテンツの外（ヘッ
ダ）に記録されている。

【０１４４】図２５は、コンテンツを記録媒体に記録す
る場合のファイルフォーマットのより詳細な構成を表し
ている。この例においては、コンテンツID（CID）、ラ
イセンスID（LID）、URL、およびウォーターマーク（W
M）を含むヘッダが記録されている他、EKB、コンテンツ
キーKcをルートキーKRで暗号化したデータ（Enc（KR，K
c））、証明書（Cert）、ヘッダに基づき生成されたデ
ジタル署名（Sig（Header））、コンテンツをコンテン
ツキーKcで暗号化したデータ（Enc（Kc，Content））、
メタデータ（Meta Data）およびマーク(Mark)が記録さ
れている。

【０１４５】ウォーターマークは、コンテンツの内部に
埋め込まれているものであるが、図２４と図２５に示さ
れるように、コンテンツの内部とは別に、ヘッダ内に配
置するようにすることで、ウォーターマークとしてコン
テンツに埋め込まれている情報を迅速に、かつ簡単に検
出することが可能となる。従って、そのコンテンツを、
コピーすることができるか否かを、迅速に判定すること
ができる。

【０１４６】なお、メタデータは、例えば、ジャケッ
ト、写真、歌詞等のデータを表す。マークについては、
図３１を参照して後述する。

【０１４７】図２６は、証明書としての公開鍵証明書の
例を表している。公開鍵証明書は、通常、公開鍵暗号方
式における認証局（CA：Certificate Authority）が発
行する証明書であり、ユーザが、認証局に提出した自己
のIDや公開鍵などに、認証局が有効期限等の情報を付加
し、さらに、認証局によるデジタル署名を付加して作成
される。この発明においては、ライセンスサーバ４（ま
たはコンテンツサーバ３）が、証明書と秘密鍵、従って
公開鍵も発行するので、ユーザは、ユーザID、パスワー
ド等をライセンスサーバ４に提供し登録処理を行うこと
によって、この公開鍵証明書を得ることができる。

【０１４８】図２６における公開鍵証明書は、証明書の
バージョン番号、ライセンスサーバ４が証明書の利用者
（ユーザ）に対して割りつける証明書の通し番号、デジ
タル署名に用いたアルゴリズム、およびパラメータ、認
証局（ライセンスサーバ４）の名前、証明書の有効期
限、証明書利用者のID（ノードIDまたはリーフID）、並
びに証明書利用者の公開鍵が、メッセージとして含まれ
ている。さらに、このメッセージには、認証局としての
ライセンスサーバ４により作成されたデジタル署名が付
加されている。このデジタル署名は、メッセージに対し
てハッシュ関数を適用して生成されたハッシュ値に基づ
いて、ライセンスサーバ４の秘密鍵を用いて生成された
データである。

【０１４９】ノードIDまたはリーフIDは、例えば、図１
２の例の場合、デバイス０であれば「００００」とさ
れ、デバイス１でれば「０００１」とされ、デバイス１
５であれば「１１１１」とされる。このようなIDに基づ
いて、そのデバイス（エンティティ）がツリー構成のど
の位置（リーフまたはノード）に位置するエンティティ
であるのかが識別される。

【０１５０】このように、コンテンツを利用するのに必
要なライセンスを、コンテンツとは分離して配布するよ
うにすることにより、コンテンツの配布が自由に行われ
ることになる。任意の方法、あるいは経路で入手された
コンテンツは、一元的に取り扱うことが可能である。

【０１５１】また、ファイルフォーマットを図２５に示
されるように構成することで、そのフォーマットのコン
テンツを、インターネットを介して配信する場合は勿
論、SDMI（Secure Digital Music Initiative）機器に
提供する場合においても、コンテンツの著作権を管理す
ることが可能となる。

【０１５２】さらに、例えば、図２７に示されるよう
に、コンテンツが記録媒体を介して提供されたとして
も、インターネット２を介して提供されたとしても、同
様の処理により、SDMI（Secure Digital Music Initiat
ive）機器としての所定のPD（Portable Device）等に、
チェックアウトしたりすることが可能となる。

【０１５３】次に、図２８のフローチャートを参照し
て、クライアント１が他のクライアント（例えば、PD）
に対してコンテンツをチェックアウトする場合の処理に
ついて説明する。

【０１５４】最初に、ステップＳ１９１において、CPU
２１は、コンテンツにデジタル署名が付加されているか
否かを判定する。デジタル署名が付加されていると判定
された場合、ステップＳ１９２に進み、CPU２１は、証
明書を抽出し、認証局（ライセンスサーバ４）の公開鍵
で検証する処理を実行する。すなわち、クライアント１
は、ライセンスサーバ４からライセンスサーバ４の秘密
鍵に対応する公開鍵を取得し、その公開鍵で公開鍵証明
書に付加されているデジタル署名を復号する。図２６を
参照して説明したように、デジタル署名は、認証局（ラ
イセンスサーバ４）の秘密鍵に基づいて生成されてお
り、ライセンスサーバ４の公開鍵を用いて復号すること
ができる。さらに、CPU２１は、証明書のメッセージ全
体に対してハッシュ関数を適用してハッシュ値を演算す
る。そしてCPU２１は、演算されたハッシュ値と、デジ
タル署名を復号して得られたハッシュ値とを比較し、両
者が一致すれば、メッセージは改竄されたものではない
と判定する。両者が一致しない場合には、この証明書
は、改竄されたものであるということになる。

【０１５５】そこで、ステップＳ１９３において、CPU
２１は、証明書が改竄されていないか否かを判定し、改
竄されていないと判定された場合、ステップＳ１９４に
進み、証明書をEKBで検証する処理を実行する。この検
証処理は、証明書に含まれるリーフID（図２６）に基づ
いて、EKBをたどることができるか否かを調べることに
より行われる。この検証について、図２９と図３０を参
照して説明する。

【０１５６】いま、図２９に示されるように、例えば、
リーフキーＫ１００１を有するデバイスがリボークされ
たデバイスであるとする。このとき、図３０に示される
ようなデータ（暗号化キー）とタグを有するEKBが、各
デバイス（リーフ）に配布される。このEKBは、図２９
におけるデバイス「１００１」をリボークするために、
キーKR,Ｋ１,Ｋ１０,Ｋ１００を更新するEKBとなってい
る。

【０１５７】リボークデバイス「１００１」以外の全て
のリーフは、更新されたルートキーＫ（ｔ）Ｒを取得す
ることができる。すなわち、ノードキーＫ０の下位に連
なるリーフは、更新されていないノードキーＫ０を、デ
バイス内に保持しているので、暗号化キーEnc（Ｋ０，
Ｋ（ｔ）Ｒ）を、キーＫ０によって復号することで、更
新ルートキーＫ（ｔ）Ｒを取得することができる。

【０１５８】また、ノードキーＫ１１以下のリーフは、
更新されていないノードキーＫ１１を用いて、Enc（Ｋ
１１，Ｋ（ｔ）１）をノードキーＫ１１によって復号す
ることで、更新ノードキーＫ（ｔ）１を取得することが
できる。さらに、Enc（Ｋ（ｔ）１，Ｋ（ｔ）Ｒ）をノ
ードキーＫ（ｔ）１によって復号することで、更新ルー
トキーＫ（ｔ）Ｒを取得することが可能となる。ノード
キーＫ１０１の下位リーフについても、同様に更新ルー
トキーＫ（ｔ）Ｒを取得することが可能である。

【０１５９】さらに、リボークされていないリーフキー
Ｋ１０００を有するデバイス「１０００」は、自己のリ
ーフキーＫ１０００でEnc（Ｋ１０００，Ｋ（ｔ）１０
０）を復号して、ノードキーＫ（ｔ）１００を取得する
ことができ、これを用いてさらに、上位のノードキーを
順次復号し、更新ルートキーＫ（ｔ）Ｒを取得すること
ができる。

【０１６０】これに対して、リボークされたデバイス
「１００１」は、自己のリーフの１段上の更新ノードキ
ーＫ（ｔ）１００を、EKB処理により取得できないの
で、結局、更新ルートキーＫ（ｔ）Ｒを取得することが
できない。

【０１６１】リボークされていない正当なデバイス（ク
ライアント１）には、図３０に示されるデータとタグを
有するEKBが、ライセンスサーバ４から配信され、格納
されている。

【０１６２】そこで、各クライアントは、そのタグを利
用して、EKB追跡処理を行うことができる。このEKB追跡
処理は、上位のルートキーからキー配信ツリーをたどれ
るか否かを判定する処理である。

【０１６３】例えば、図２９のリーフ「１００１」のID
（リーフID）である「１００１」を、「１」「０」
「０」「１」の４ビットとして把握し、最上位ビットか
ら順次、下位ビットに従って、ツリーをたどることがで
きるか否かが判定される。この判定では、ビットが１で
あれば、右側に進み、０であれば、左側に進む処理が行
われる。

【０１６４】ID「１００１」の最上位ビットが１である
から、図２９のルートキーKRから右側に進む。EKBの最
初のタグ（番号０のタグ）は、０：｛０，０｝であり、
両枝にデータを有するものであると判定される。この場
合、右側に進むことができるので、ノードキーＫ１にた
どり着くことができる。

【０１６５】次に、ノードキーＫ１の下位のノードに進
む。ID「１００１」の２番目のビットは０であるから左
側に進む。番号１のタグは、左側のノードキーＫ０の下
位のデータの有無を表すものであり、ノードキーＫ１の
下位のデータの有無を示すタグは、番号２のタグであ
る。このタグは、図３０に示されるように、２：｛０，
０｝であり、両枝にデータを有するものとされる。従っ
て、左側に進み、ノードキーＫ１０にたどり着くことが
できる。

【０１６６】さらに、ID「１００１」の３番目のビット
は０であり、左側に進む。このとき、Ｋ１０の下位のデ
ータの有無を示すタグ（番号３のタグ）は、３：｛０，
０｝であり、両枝にデータを有するものと判定される。
そこで、左側に進み、ノードキーＫ１００にたどり着く
ことができる。

【０１６７】さらに、ID「１００１」の最下位ビットは
１であり、右側に進む。番号４のタグは、ノードキーＫ
１１に対応するものであり、Ｋ１００の下位のデータの
符号を表すタグは、番号５のタグである。このタグは、
５：｛０，１｝である。従って、右側には、データが存
在しないことになる。その結果、ノード「１００１」に
はたどり着けないことになり、ID「１００１」のデバイ
スは、EKBによる更新ルートキーを取得できないデバイ
ス、すなわちリボークデバイスであると判定される。

【０１６８】これに対して、例えば、リーフキーＫ１０
００を有するデバイスIDは、「１０００」であり、上述
した場合と同様に、EKB内のタグに基づくEKB追跡処理を
行うと、ノード「１０００」にたどり着くことができ
る。従って、ID「Ｉ０００」のデバイスは、正当なデバ
イスであると判定される。

【０１６９】図２８に戻って、CPU２１は、ステップＳ
１９４の検証処理に基づき、証明書がリボークされてい
ないか否かをステップＳ１９５で判定し、証明書がリボ
ークされていない場合には、ステップＳ１９６に進み、
デジタル署名を証明書に含まれる公開鍵で検証する処理
を実行する。

【０１７０】すなわち、図２６に示されるように、証明
書には、証明書利用者（コンテンツ作成者）の公開鍵が
含まれており、この公開鍵を用いて、図２５に示される
署名（Sig（Header））が検証される。すなわち、この
公開鍵を用いて、デジタル署名Sig（Header）を復号し
て得られたデータ（ハッシュ値）と、図２５に示される
Headerにハッシュ関数を適用して演算されたハッシュ値
とを比較することで、両者が一致していれば、Headerが
改竄されていないことを確認することができる。これに
対して、両者が一致しなければ、Headerは改竄されてい
るということになる。

【０１７１】ステップＳ１９７において、CPU２１は、H
eaderが改竄されているか否かを判定し、改竄されてい
なければ、ステップＳ１９８に進み、ウォーターマーク
を検証する。ステップＳ１９９において、CPU２１は、
ウォーターマークの検証の結果、チェックアウトが可能
であるか否かを判定する。チェックアウトが可能である
場合には、ステップＳ２００に進み、CPU２１は、チェ
ックアウトを実行する。すなわち、チェックアウト先の
クライアント１に対してコンテンツを転送し、コピーさ
せる。

【０１７２】ステップＳ１９１において、デジタル署名
が存在しないと判定された場合、ステップＳ１９３にお
いて、証明書が改竄されていると判定された場合、ステ
ップＳ１９５において、証明書をEKBで検証することが
できなかったと判定された場合、ステップＳ１９７にお
いて、デジタル署名の検証の結果、ヘッダが改竄されて
いると判定された場合、または、ステップＳ１９９にお
いて、ウォーターマークにチェックアウトの禁止が記述
されていると判定された場合、ステップＳ２０１に進
み、エラー処理が実行される。すなわち、この場合に
は、チェックアウトが禁止される。

【０１７３】このように、証明書と秘密鍵をライセンス
サーバ４からユーザに配布し、コンテンツ作成時に、デ
ジタル署名を付加することにより、コンテンツの作成者
の真正を保証することが可能となる。これにより、不正
なコンテンツの流通を抑制することができる。

【０１７４】さらに、ウォーターマークをコンテンツ作
成時に検出し、その情報をデジタル署名に付すること
で、ウォーターマーク情報の改竄を防止し、コンテンツ
の真正を保証することができる。

【０１７５】その結果、一度作成されたコンテンツは、
どのような形態で配信されたとしても、元のコンテンツ
の真正を保証することが可能となる。

【０１７６】さらに、コンテンツは、使用条件を有さ
ず、使用条件は、ライセンスに付加されているので、ラ
イセンス内の使用条件を変更することで、それに関係す
るコンテンツの使用条件を一斉に変更することが可能と
なる。

【０１７７】次に、マークの利用方法について説明す
る。本発明においては、上述したように、使用条件は、
コンテンツではなく、ライセンスに付加される。しかし
ながら、コンテンツによって、使用状況が異なる場合が
ある。そこで、本発明においては、図２５に示されるよ
うに、コンテンツにマークが付加される。

【０１７８】ライセンスとコンテンツは、１対多の関係
にあるため、コンテンツの個々の使用状況をライセンス
の使用条件にのみ記述するのは困難となる。そこで、こ
のように、コンテンツに使用状況を付加することによ
り、ライセンスでの管理をしながらも、個々のコンテン
ツを管理することが可能となる。

【０１７９】このマークには、例えば、図３１に示され
るように、ユーザのID（リーフID）、所有権フラグ、使
用開始時刻、およびコピー回数等が記述される。

【０１８０】さらに、マークには、リーフID、所有権フ
ラグ、使用開始時刻、およびコピー回数等のメッセージ
に基づいて生成されたデジタル署名が付加される。

【０１８１】所有権フラグは、例えば、所定の期間だけ
コンテンツを使用可能とするライセンスを、そのまま買
い取ったような場合（使用期間を永久に変更したような
場合）に付加される。使用開始時刻は、コンテンツの使
用を所定の期間内に開始した場合に記述される。例え
ば、コンテンツをダウンロードする時期が制限されてい
るような場合において、その期限内にダウンロードが行
われたようなとき、その実際にコンテンツをダウンロー
ドした日時がここに記述される。これにより、期間内で
の有効な使用であることが、証明される。

【０１８２】コピー回数には、それまでにそのコンテン
ツをコピーした回数が履歴（ログ）として記述される。

【０１８３】次に、図３２のフローチャートを参照し
て、ユーザがライセンスを買い取った場合に、マークを
付加する処理について、マークをコンテンツに付加する
例として説明する。

【０１８４】最初に、ステップＳ２２１において、CPU
２１は、入力部２６からのユーザの指令に基づいて、イ
ンターネット２を介して、ライセンスサーバ４にアクセ
スする。

【０１８５】ステップＳ２２２において、CPU２１は、
ユーザからの入力部２６を介しての入力を取り込み、そ
の入力に対応してライセンスサーバ４に対してライセン
スの買い取りを要求する。

【０１８６】この要求に対応して、図３３のフローチャ
ートを参照して後述するように、ライセンスサーバ４
は、ライセンスを買い取るために必要な対価を提示して
くる（図３３のステップＳ２４２）。そこで、ステップ
Ｓ２２３において、クライアント１のCPU２１は、ライ
センスサーバ４からの対価の提示を受け取ると、これを
出力部２７に出力し、表示させる。

【０１８７】ユーザは、この表示に基づいて、提示され
た対価を了承するか否かを判断し、その判断結果に基づ
いて、入力部２６からその判断結果を入力する。

【０１８８】CPU２１は、ステップＳ２２４において、
入力部２６からの入力に基づいて、ユーザが提示された
対価を了承したか否かを判定し、了承したと判定した場
合には、ステップＳ２２５に進み、ライセンスサーバ４
に了承を通知する処理を実行する。

【０１８９】この了承通知を受信すると、ライセンスサ
ーバ４は、対価の買い取りを表す情報、すなわち所有権
フラグを記述したマークを送信してくる（図３３のステ
ップＳ２４４）。そこで、ステップＳ２２６において、
クライアント１のCPU２１は、ライセンスサーバ４から
のマークを受け取ると、ステップＳ２２７において、受
け取ったマークをコンテンツに埋め込む処理を実行す
る。すなわち、これにより、買い取られたライセンスに
対応するコンテンツのマークとして、図３１に示される
ような所有権フラグが記述されたマークがコンテンツに
対応して記録されることになる。また、このとき、CPU
２１は、メッセージが更新されたことになるので、デジ
タル署名（図２５）も更新し、記録媒体に記録する。

【０１９０】ステップＳ２２４において、ライセンスサ
ーバ４から提示された対価が了承されていないと判定さ
れた場合、ステップＳ２２８に進み、CPU２１は、提示
された対価を了承しないことをライセンスサーバ４に通
知する。

【０１９１】このようなクライアント１の処理に対応し
て、ライセンスサーバ４は、図３３のフローチャートに
示す処理を実行する。

【０１９２】すなわち、最初に、ステップＳ２４１にお
いて、ライセンスサーバ４のCPU２１は、クライアント
１からライセンス買い取りの要求が送信されてくると
（図３２のステップＳ２２２）、 これを受け取り、ス
テップＳ２４２において、対象とされているライセンス
の買い取りに必要な対価を記憶部２８から読み出し、こ
れをクライアント１に送信する。

【０１９３】上述したように、このようにして提示され
た対価に対して、クライアント１から提示された対価を
了承するか否かの通知が送信されてくる。

【０１９４】そこで、ステップＳ２４３において、ライ
センスサーバ４のCPU２１は、クライアント１から了承
通知を受信したか否かを判定し、了承通知を受信したと
判定した場合、ステップＳ２４４に進み、対象とされる
ライセンスの買い取りを表すメッセージを含むマークを
生成し、自分自身の秘密鍵で、デジタル署名を付加し
て、クライアント１に送信する。このようにして送信さ
れたマークは、上述したように、クライアント１の記憶
部２８において、対応するコンテンツに記録される（図
３２のステップＳ２２７）。

【０１９５】ステップＳ２４３において、クライアント
１から了承通知が受信されていないと判定された場合、
ステップＳ２４４の処理はスキップされる。すなわち、
この場合には、ライセンスの買い取り処理が最終的に行
われなかったことになるので、マークは送信されない。

【０１９６】図３４は、ステップＳ２４４において、ラ
イセンスサーバ４からクライアント１に対して送信され
るマークの構成例を表している。この例においては、そ
のユーザのリーフID、所有権フラグ（Own）、並びにリ
ーフIDと所有権フラグを、ライセンスサーバ４の秘密鍵
Ｓに基づいて生成されたデジタル署名Sig_s（LeafID,Ow
n）により、マークが構成されている。

【０１９７】なお、このマークは、特定のユーザの特定
のコンテンツに対してのみ有効なものであるので、対象
とされるコンテンツがコピーされた場合には、そのコピ
ーされたコンテンツに付随するマークは無効とされる。

【０１９８】このようにして、コンテンツとライセンス
を分離し、使用条件をライセンスに対応させる場合にお
いても、個々のコンテンツの使用状況に応じたサービス
を実現することが可能となる。

【０１９９】次に、グルーピングについて説明する。複
数の機器やメディアを適当に集め、その１つの集合内に
おいては、コンテンツを自由に授受することができるよ
うにすることは、グルーピングと称される。通常、この
グルーピングは、個人の所有する機器やメディアにおい
て行われる。このグルーピングは、従来、グループ毎に
グループキーを設定する等して行われていたが、グルー
プ化する複数の機器やメディアに、同一のライセンスを
対応づけることにより、容易にグルーピングすることが
可能となる。

【０２００】また、各機器を予め登録しておくことで、
グルーピングすることも可能である。この場合のグルー
ピングについて、以下に説明する。

【０２０１】この場合、ユーザは、グルーピング対象と
される機器の証明書を予めサーバに登録しておく必要が
ある。この証明書の登録処理について、図３５と図３６
のフローチャートを参照して説明する。

【０２０２】最初に、図３５のフローチャートを参照し
て、クライアント（グルーピング対象となる機器）の証
明書の登録処理について説明する。ステップＳ２６１に
おいて、クライアント１のCPU２１は、グルーピングの
対象とされる機器としての自分自身の証明書を作成す
る。この証明書には、自分自身の公開鍵が含まれる。

【０２０３】次に、ステップＳ２６２に進み、CPU２１
は、ユーザの入力部２６からの入力に基づいて、コンテ
ンツサーバ３にアクセスし、ステップＳ２６３におい
て、ステップＳ２６１の処理で作成された証明書をコン
テンツサーバ３に送信する処理を実行する。

【０２０４】なお、証明書としては、ライセンスサーバ
４から受信したものを、そのまま使用することもでき
る。

【０２０５】以上の処理は、グルーピング対象とされる
全ての機器が行う。

【０２０６】次に、図３６のフローチャートを参照し
て、図３５のクライアント１の証明書の登録処理に対応
して行われるコンテンツサーバ３の証明書の登録処理に
ついて説明する。

【０２０７】最初に、ステップＳ２７１において、コン
テンツサーバ３のCPU２１は、クライアント１から送信
されてきた証明書を受信すると、ステップＳ２７２にお
いて、その証明書を記憶部２８に登録する。

【０２０８】以上の処理が、グループ対象とされる機器
毎に行われる。その結果、コンテンツサーバ３の記憶部
２８には、例えば、図３７に示されるように、グループ
毎に、そのグループを構成するデバイスの証明書が登録
される。

【０２０９】図３７に示される例では、グループ１の証
明書として、証明書Ｃ１１乃至Ｃ１４が登録されてい
る。これらの証明書Ｃ１１乃至Ｃ１４には、対応する公
開鍵Ｋ _P11乃至Ｋ_P14が含まれている。

【０２１０】同様に、グループ２の証明書として、証明
書Ｃ２１乃至Ｃ２３が登録されており、これらは対応す
る公開鍵Ｋ_P21乃至Ｋ_P23が含まれている。

【０２１１】以上のようなグループを構成する各機器毎
に、その証明書が登録された状態において、ユーザから
そのグループに属する機器にコンテンツの提供が要求さ
れると、コンテンツサーバ３は、図３８のフローチャー
トに示す処理を実行する。

【０２１２】最初に、ステップＳ２８１において、コン
テンツサーバ３のCPU２１は、記憶部２８に記憶されて
いる証明書のうち、そのグループに属する証明書を検証
する処理を実行する。

【０２１３】この検証処理は、図２９と図３０を参照し
て説明されたように、各機器の証明書に含まれるリーフ
IDに基づいて、タグを利用してEKBをたどることで行わ
れる。EKBは、コンテンツサーバ３にも、ライセンスサ
ーバ４から配布されている。この検証処理により、リボ
ークされている証明書は除外される。

【０２１４】ステップＳ２８２において、コンテンツサ
ーバ３のCPU２１は、ステップＳ２８１の検証処理の結
果、有効とされた証明書を選択する。そして、ステップ
Ｓ２８３において、CPU２１は、ステップＳ２８２の処
理で選択された各機器の証明書の各公開鍵でコンテンツ
鍵を暗号化する。ステップＳ２８４において、CPU２１
は、対象とされるグループの各機器に、ステップＳ２８
３の処理で暗号化されたコンテンツ鍵をコンテンツとと
もに送信する。

【０２１５】図３７に示されるグループ１のうち、例え
ば、証明書Ｃ１４がリボークされているとすると、ステ
ップＳ２８３の処理で、例えば、図３９に示されるよう
な暗号化データが生成される。

【０２１６】すなわち、図３９の例においては、コンテ
ンツ鍵Kcが、証明書Ｃ１１の公開鍵Ｋ_P11、証明書Ｃ１
２の公開鍵Ｋ_P12、または証明書Ｃ１３の公開鍵Ｋ_P13に
より、暗号化されている。

【０２１７】コンテンツサーバ３の図３８に示されるよ
うな処理に対応して、コンテンツの提供を受ける各グル
ープの機器（クライアント）は、図４０のフローチャー
トに示す処理を実行する。

【０２１８】最初に、ステップＳ２９１において、クラ
イアント１のCPU２１は、コンテンツサーバ３が図３８
のステップＳ２８４の処理で送信してきたコンテンツ
を、コンテンツ鍵とともに受信する。コンテンツは、コ
ンテンツ鍵Kcにより、暗号化されており、コンテンツ鍵
は上述したように、各機器が保持する公開鍵により暗号
化されている（図３９）。

【０２１９】そこで、ステップＳ２９２において、CPU
２１は、ステップＳ２９１の処理で受信した自分宛のコ
ンテンツ鍵を、自分自身の秘密鍵で復号し、取得する。
そして、取得したコンテンツ鍵を用いてコンテンツの復
号処理が行われる。

【０２２０】例えば、図３９の例に示される証明書Ｃ１
１に対応する機器は、公開鍵Ｋ_P11に対応する自分自身
の秘密鍵を用いて、コンテンツ鍵Kcの暗号を復号し、コ
ンテンツ鍵Kcを取得する。そして、コンテンツ鍵Kcを用
いて、コンテンツがさらに復号される。

【０２２１】同様の処理は、証明書Ｃ１２，Ｃ１３に対
応する機器においても行われる。リボークされている証
明書Ｃ１４の機器は、自分自身の公開鍵を用いて暗号化
されたコンテンツ鍵Kcがコンテンツに付随して送られて
こないので、コンテンツ鍵Kcを復号することができず、
従って、コンテンツ鍵Kcを用いてコンテンツを復号する
ことができない。

【０２２２】以上においては、コンテンツキー（すなわ
ちコンテンツ）に対してグルーピングを行うようにした
が、ライセンスキー（ライセンス）に対してグルーピン
グを行うことも可能である。

【０２２３】以上のようにして、特別なグループキー
や、後述するICV（Integrity Check Value）を用いずに
グループ化が可能となる。このグループ化は、小規模の
グループに適用するのに向いている。

【０２２４】本発明においては、ライセンスもチェック
アウト、あるいはチェックインしたり、ムーブしたり、
コピーしたりすることが可能とされる。但し、これらの
処理はSDMIで定められたルールに基づいて行われる。

【０２２５】次に、図４１と図４２のフローチャートを
参照して、このようなクライアントによるライセンスの
チェックアウト処理について説明する。

【０２２６】最初に、図４１のフローチャートを参照し
て他のクライアントにライセンスをチェックアウトする
クライアントの処理について説明する。最初に、ステッ
プＳ３０１において、クライアント１のCPU２１は、チ
ェックアウト対象のライセンスのチェックアウト回数Ｎ
１を読み取る。このチェックアウト回数は、図８に示さ
れる使用条件に書き込まれているので、この使用条件か
ら読み取られる。

【０２２７】次に、ステップＳ３０２において、CPU２
１は、チェックアウト対象のライセンスの最大チェック
アウト回数Ｎ２を、やはりライセンスの使用条件から読
み取る。

【０２２８】そして、ステップＳ３０３において、CPU
２１は、ステップＳ３０１の処理で読み取られたチェッ
クアウト回数Ｎ１と、ステップＳ３０２の処理で読み取
られた最大チェックアウト回数Ｎ２とを比較し、チェッ
クアウト回数Ｎ１が最大チェックアウト回数Ｎ２より大
きいか否かを判定する。

【０２２９】チェックアウト回数Ｎ１が、最大チェック
アウト回数Ｎ２より小さいと判定された場合、ステップ
Ｓ３０４に進み、CPU２１は、相手側の装置（チェック
アウト先のクライアント）のリーフキーを相手個々の装
置から取得し、そのリーフキーを、いまチェックアウト
対象とされているライセンスIDに対応して記憶部２８の
チェックアウトリストに記憶させる。

【０２３０】次に、ステップＳ３０５において、CPU２
１は、ステップＳ３０１の処理で読み取られたライセン
スのチェックアウト回数Ｎ１の値を１だけインクリメン
トする。ステップＳ３０６において、CPU２１は、ライ
センスのメッセージに基づいて、ICVを演算する。このI
CVについては、図４６乃至図５０を参照して後述する。
ICVを用いてライセンスの改竄を防止することが可能と
なる。

【０２３１】次に、ステップＳ３０７において、CPU２
１は、チェックアウト対象のライセンスと、ステップＳ
３０６の処理で演算されたICVを、自分自身の公開鍵を
用いて暗号化して、EKBおよび証明書とともに、相手側
の装置に出力し、コピーさせる。さらに、ステップＳ３
０８において、CPU２１は、ステップＳ３０６の処理で
演算されたICVを、相手側装置のリーフキーと、ライセ
ンスIDに対応して記憶部２８のチェックリスト中に記憶
させる。

【０２３２】ステップＳ３０３において、チェックアウ
ト回数Ｎ１が最大チェックアウト回数Ｎ２より小さくな
い（例えば、等しい）と判定された場合、もはや許容さ
れる回数だけチェックアウトが行われているので、これ
以上チェックアウトを行うことができない。そこで、ス
テップＳ３０９に進み、CPU２１は、エラー処理を実行
する。すなわち、この場合、チェックアウト処理は実行
されないことになる。

【０２３３】次に、図４２のフローチャートを参照し
て、図４１のチェックアウト処理により、ライセンスの
チェックアウトを受けるクライアントの処理について説
明する。

【０２３４】最初に、ステップＳ３２１において、相手
側装置（ライセンスをチェックアウトするクライアント
１）に、自分自身のリーフキーを送信する。このリーフ
キーは、ステップＳ３０４において、相手側のクライア
ントにより、ライセンスIDに対応して記憶される。

【０２３５】次に、ステップＳ３２２において、CPU２
１は、相手側のクライアント１から暗号化されたライセ
ンスとICVが、EKBおよび証明書とともに送信されてきた
場合、これを受信する。すなわち、このライセンス、IC
V、EKBおよび証明書は、図４１のステップＳ３０７の処
理で相手側の装置から送信されたものである。

【０２３６】ステップＳ３２３において、CPU２１は、
ステップＳ３２２の処理で受信したライセンス、ICV、E
KBおよび証明書を、記憶部２８に記憶させる。

【０２３７】以上のようにして、ライセンスのチェック
アウトを受けたクライアント１は、チェックアウトを受
けたそのライセンスを使用して、所定のコンテンツを再
生する場合、図４３のフローチャートに示される処理を
実行する。

【０２３８】すなわち、最初に、ステップＳ３４１にお
いて、クライアント１のCPU２１は、ユーザより入力部
２６を介して再生が指定されたコンテンツのICVを演算
する。そして、ステップＳ３４２において、CPU２１
は、記憶部２８に記憶されている暗号化されているICV
を、証明書に含まれている公開鍵に基づいて、復号させ
る。

【０２３９】次に、ステップＳ３４３において、CPU２
１は、ステップＳ３４１の処理により、いま演算された
ICVと、ステップＳ３４２の処理により読み出され、復
号されたICVが一致するか否かを判定する。両者が一致
する場合には、ライセンスは改竄されていないことにな
る。そこで、ステップＳ３４４にすすみ、CPU２１は、
対応するコンテンツを再生する処理を実行する。

【０２４０】これに対して、ステップＳ３４３におい
て、２つのICVが一致しないと判定された場合、ライセ
ンスは改竄されている恐れがある。このため、ステップ
Ｓ３４５に進み、CPU２１は、エラー処理を実行する。
すなわち、このとき、そのライセンスを用いてコンテン
ツを再生することができないことになる。

【０２４１】次に、以上のようにして、他のクライアン
トに一旦チェックアウトしたライセンスのチェックイン
を受けるクライアントの処理について、図４４のフロー
チャートを参照して説明する。

【０２４２】最初に、ステップＳ３６１において、CPU
２１は、相手側の装置（ライセンスを返却（チェックイ
ン）してくるクライアント１）のリーフキーと、チェッ
クイン対象のライセンスのIDを取得する。次に、ステッ
プＳ３６２において、CPU２１は、ステップＳ３６１で
取得されたチェックイン対象のライセンスが、自分自身
が相手側装置にチェックアウトしたライセンスであるか
否かを判定する。この判定は、図４１のステップＳ３０
８の処理で記憶されたICV、リーフキー、およびライセ
ンスIDに基づいて行われる。すなわち、ステップＳ３６
１で取得されたリーフキー、ライセンスID、およびICV
が、チェックアウトリスト中に記憶されているか否かが
判定され、記憶されている場合には、自分自身がチェッ
クアウトしたライセンスであると判定される。

【０２４３】ライセンスが、自分自身がチェックアウト
したものであるとき、ステップＳ３６３において、CPU
２１は、相手側の装置のライセンス、EKBおよび証明書
の削除を要求する。後述するように、この要求に基づい
て、相手側の装置は、ライセンス、EKBおよび証明書の
削除を実行する（図４５のステップＳ３８３）。

【０２４４】ステップＳ３６４において、CPU２１は、
一旦チェックアウトしたライセンスが再びチェックイン
されてきたので、そのライセンスのチェックアウト回数
Ｎ１を１だけデクリメントする。

【０２４５】ステップＳ３６５において、CPU２１は、
相手側の装置に他のライセンスをチェックアウトしてい
るか否かを判定し、まだチェックアウトしている他のラ
イセンスが存在しない場合には、ステップＳ３６６に進
み、CPU２１は、相手側の装置のチェックイン対象機器
としてのチェックアウトリストにおける記憶を削除す
る。これに対して、ステップＳ３６５において、相手側
の装置にチェックアウトしている他のライセンスが存在
すると判定された場合には、他のライセンスのチェック
インを受ける可能性があるので、ステップＳ３６６の処
理はスキップされる。

【０２４６】ステップＳ３６２において、チェックイン
対象とされているライセンスが、自分自身が相手側装置
にチェックアウトしたライセンスではないと判定された
場合、CPU２１は、ステップＳ３６７に進み、エラー処
理を実行する。すなわち、この場合には、自分自身が管
轄するライセンスではないことになるので、チェックイ
ン処理は実行されない。

【０２４７】ユーザが、ライセンスを不正にコピーした
ような場合、記憶されているICVの値と、ステップＳ３
６１の処理で取得されたライセンスに基づいて演算され
たICVの値が異なるものとなるで、チェックインできな
いことになる。

【０２４８】図４５は、図４４のフローチャートに示さ
れるライセンスのチェックイン処理を実行するクライア
ントに対して、自分自身が有しているライセンスをチェ
ックインさせるクライアントの処理を表している。

【０２４９】ステップＳ３８１において、クライアント
１のCPU２１は、相手側の装置（図４４のフローチャー
トに示す処理を実行するクライアント１）にリーフキー
とチェックイン対象のライセンスのIDを送信する。上述
したように、相手側の装置は、ステップＳ３６１におい
て、このリーフキーとライセンスIDを取得し、ステップ
Ｓ３６２において、それに基づいて、チェックイン対象
のライセンスの認証処理を実行する。

【０２５０】ステップＳ３８２において、クライアント
１のCPU２１は、相手側の装置からライセンスの削除を
要求されたか否かを判定する。すなわち、ライセンスが
正当なチェックイン対象のライセンスである場合、上述
したように、相手側の装置は、ステップＳ３６３の処理
でライセンス、EKBおよび証明書の削除を要求してく
る。そこで、この要求を受信した場合、ステップＳ３８
３に進み、CPU２１は、ライセンス、EKBおよび証明書を
削除する。すなわち、これにより、このクライアント１
は、以後そのライセンスを使用できない状態となり、図
４４のステップＳ３６４の処理により、チェックアウト
回数Ｎ１が、１だけデクリメンドされるので、チェック
インが完了したことになる。

【０２５１】ステップＳ３８２において、相手側の装置
からライセンスの削除が要求されていないと判定された
場合、ステップＳ３８４に進み、エラー処理が実行され
る。すなわち、この場合には、ICVの値が異なっている
等の理由により、チェックインができないことになる。

【０２５２】以上においては、チェックインとチェック
アウトについて説明したが、同様に、ライセンスをコピ
ーあるいはムーブさせるようにすることも可能である。

【０２５３】次に、ライセンス（コンテンツも同様）の
改竄を防止するためにライセンスのインテグリティ・チ
ェック値（ＩＣＶ）を生成して、ライセンスに対応付け
て、ＩＣＶの計算により、ライセンス改竄の有無を判定
する処理構成について説明する。

【０２５４】ライセンスのインテグリティ・チェック値
（ＩＣＶ）は、例えばライセンスに対するハッシュ関数
を用いて計算され、ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｌ
１，Ｌ２，・・・）によって計算される。ＫｉｃｖはＩ
ＣＶ生成キーである。Ｌ１，Ｌ２はライセンスの情報で
あり、ライセンスの重要情報のメッセージ認証符号（Ｍ
ＡＣ：Message authentication Code）が使用される。

【０２５５】ＤＥＳ暗号処理構成を用いたＭＡＣ値生成
例を図４６に示す。図４６の構成に示すように対象とな
るメッセージを８バイト単位に分割し、（以下、分割さ
れたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、
まず、初期値（IV）とＭ１を、演算部２４−１Ａにより
排他的論理和する（その結果をＩ１とする）。次に、Ｉ
１をＤＥＳ暗号化部２４−１Ｂに入れ、鍵（以下、Ｋ１
とする）を用いて暗号化する（出力をＥ１とする）。続
けて、Ｅ１およびＭ２を演算部２４−２Ａにより排他的
論理和し、その出力Ｉ２をＤＥＳ暗号化部２４−２Ｂへ
入れ、鍵Ｋ１を用いて暗号化する（出力Ｅ２）。以下、
これを繰り返し、全てのメッセージに対して暗号化処理
を施す。ＤＥＳ暗号化部２４−NBから最後に出てきたＥ
Ｎがメッセージ認証符号（ＭＡＣ（Message Authentica
tion Code））となる。

【０２５６】このようなライセンスのＭＡＣ値とＩＣＶ
生成キーにハッシュ関数を適用してライセンスのインテ
グリティ・チェック値（ＩＣＶ）が生成される。例えば
ライセンス生成時に生成したＩＣＶと、新たにライセン
スに基づいて生成したＩＣＶとを比較して同一のＩＣＶ
が得られればライセンスに改竄のないことが保証され、
ＩＣＶが異なれば、改竄があったと判定される。

【０２５７】次に、ライセンスのインテグリティ・チェ
ック値（ＩＣＶ）生成キーであるＫｉｃｖを上述の有効
化キーブロックによって送付する構成について説明す
る。すなわちＥＫＢによる暗号化メッセージデータをラ
イセンスのインテグリティ・チェック値（ＩＣＶ）生成
キーとした例である。

【０２５８】図４７および図４８に複数のデバイスに共
通のライセンスを送付した場合、それらのライセンスの
改竄の有無を検証するためのインテグリティ・チェック
値生成キーＫｉｃｖを有効化キーブロック（ＥＫＢ）に
よって配信する構成例を示す。図４７はデバイス０，
１，２，３に対して復号可能なチェック値生成キーＫｉ
ｃｖを配信する例を示し、図４８はデバイス０，１，
２，３中のデバイス３をリボーク（排除）してデバイス
０，１，２に対してのみ復号可能なチェック値生成キー
Ｋｉｃｖを配信する例を示す。

【０２５９】図４７の例では、更新ノードキーＫ（ｔ）
００によって、チェック値生成キーＫｉｃｖを暗号化し
たデータＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）とともに、
デバイス０，１，２，３においてそれぞれの有するノー
ドキー、リーフキーを用いて更新されたノードキーＫ
（ｔ）００を復号可能な有効化キーブロック（ＥＫＢ）
を生成して配信する。それぞれのデバイスは、図４７の
右側に示すように、まず、ＥＫＢを処理（復号）するこ
とにより、更新されたノードキーＫ（ｔ）００を取得
し、次に、取得したノードキーＫ（ｔ）００を用いて、
暗号化されたチェック値生成キーＥｎｃ（Ｋ（ｔ）０
０，Ｋｉｃｖ）を復号して、チェック値生成キーＫｉｃ
ｖを得ることが可能となる。

【０２６０】その他のデバイス４，５，６，７・・・は
同一の有効化キーブロック（ＥＫＢ）を受信しても自身
の保有するノードキー、リーフキーでは、ＥＫＢを処理
して更新されたノードキーＫ（ｔ）００を取得すること
ができないので、安全に正当なデバイスに対してのみチ
ェック値生成キーを送付することができる。

【０２６１】一方、図４８の例は、図１２の点線枠で囲
んだグループにおいてデバイス３が、例えば鍵の漏洩に
よりリボーク（排除）されているとして、他のグループ
のメンバ、すなわち、デバイス０，１，２，に対しての
み復号可能な有効化キーブロック（ＥＫＢ）を生成して
配信した例である。図４８に示す有効化キーブロック
（ＥＫＢ）と、チェック値生成キー（Ｋｉｃｖ）をノー
ドキー（Ｋ（ｔ）００）で暗号化したデータＥｎｃ（Ｋ
（ｔ）００，Ｋｉｃｖ）を配信する。

【０２６２】図４８の右側には、復号手順を示してあ
る。デバイス０，１，２は、まず、受領した有効化キー
ブロックから自身の保有するリーフキーまたはノードキ
ーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）
００）を取得する。次に、Ｋ（ｔ）００による復号によ
りチェック値生成キーＫｉｃｖを取得する。

【０２６３】図１２に示す他のグループのデバイス４，
５，６・・・は、この同様のデータ（ＥＫＢ）を受信し
たとしても、自身の保有するリーフキー、ノードキーを
用いて更新ノードキー（Ｋ（ｔ）００）を取得すること
ができない。同様にリボークされたデバイス３において
も、自身の保有するリーフキー、ノードキーでは、更新
ノードキー（Ｋ（ｔ）００）を取得することができず、
正当な権利を有するデバイスのみがチェック値生成キー
を復号して利用することが可能となる。

【０２６４】このように、ＥＫＢを利用したチェック値
生成キーの配送を用いれば、データ量を少なくして、か
つ安全に正当権利者のみが復号可能としたチェック値生
成キーを配信することが可能となる。

【０２６５】このようなライセンスのインテグリティ・
チェック値（ＩＣＶ）を用いることにより、ＥＫＢと暗
号化ライセンスの不正コピーを排除することができる。
例えば図４９Ａに示すように、ライセンスＬ１とライセ
ンスＬ２とをそれぞれのライセンスキーを取得可能な有
効化キーブロック（ＥＫＢ）とともに格納したメディア
１があり、これをそのままメディア２にコピーした場合
を想定する。ＥＫＢと暗号化ライセンスのコピーは可能
であり、これをＥＫＢを復号可能なデバイスでは利用で
きることになる。

【０２６６】図４９Ｂに示す例では、各メディアに正当
に格納されたライセンスに対応付けてインテグリティ・
チェック値（ＩＣＶ（Ｌ１，Ｌ２））を格納する構成と
する。なお、（ＩＣＶ（Ｌ１，Ｌ２））は、ライセンス
Ｌ１とライセンスＬ２にハッシュ関数を用いて計算され
るライセンスのインテグリティ・チェック値であるＩＣ
Ｖ＝ｈａｓｈ（Ｋｉｃｖ，Ｌ１，Ｌ２）を示している。
図４９Ｂの構成において、メディア１には正当にライセ
ンス１とライセンス２が格納され、ライセンスＬ１とラ
イセンスＬ２に基づいて生成されたインテグリティ・チ
ェック値（ＩＣＶ（Ｌ１，Ｌ２））が格納される。ま
た、メディア２には正当にライセンス１が格納され、ラ
イセンスＬ１に基づいて生成されたインテグリティ・チ
ェック値（ＩＣＶ（Ｌ１））が格納される。

【０２６７】この構成において、メディア１に格納され
た｛ＥＫＢ，ライセンス２｝をメディア２にコピーした
とすると、メディア２で、ライセンスチェック値を新た
に生成すると、ＩＣＶ（Ｌ１，Ｌ２）が生成されること
になり、メディア２に格納されているＫｉｃｖ（Ｌ１）
と異なり、ライセンスの改竄あるいは不正なコピーによ
る新たなライセンスの格納が実行されたことが明らかに
なる。メディアを再生するデバイスにおいて、再生ステ
ップの前ステップにＩＣＶチェックを実行して、生成Ｉ
ＣＶと格納ＩＣＶの一致を判別し、一致しない場合は、
再生を実行しない構成とすることにより、不正コピーの
ライセンスの再生を防止することが可能となる。

【０２６８】また、さらに、安全性を高めるため、ライ
センスのインテグリティ・チェック値（ＩＣＶ）を書き
換えカウンタを含めたデータに基づいて生成する構成と
してもよい。すなわちＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，ｃ
ｏｕｎｔｅｒ＋１，Ｌ１，Ｌ２，・・・）によって計算
する構成とする。ここで、カウンタ（ｃｏｕｎｔｅｒ＋
１）は、ＩＣＶの書き換えごとに１つインクリメントさ
れる値として設定する。なお、カウンタ値はセキュアな
メモリに格納する構成とすることが必要である。

【０２６９】さらに、ライセンスのインテグリティ・チ
ェック値（ＩＣＶ）をライセンスと同一メディアに格納
することができない構成においては、ライセンスのイン
テグリティ・チェック値（ＩＣＶ）をライセンスとは別
のメディア上に格納する構成としてもよい。

【０２７０】例えば、読み込み専用メディアや通常のＭ
Ｏ等のコピー防止策のとられていないメディアにライセ
ンスを格納する場合、同一メディアにインテグリティ・
チェック値（ＩＣＶ）を格納するとＩＣＶの書き換えが
不正なユーザによりなされる可能性があり、ＩＣＶの安
全性が保てないおそれがある。この様な場合、ホストマ
シン上の安全なメディアにＩＣＶを格納して、ライセン
スのコピーコントロール（例えばcheck-in/check-out、
move）にＩＣＶを使用する構成とすることにより、ＩＣ
Ｖの安全な管理およびライセンスの改竄チェックが可能
となる。

【０２７１】この構成例を図５０に示す。図５０では読
み込み専用メディアや通常のＭＯ等のコピー防止策のと
られていないメディア２２０１にライセンス１乃至ライ
センス３が格納され、これらのライセンスに関するイン
テグリティ・チェック値（ＩＣＶ）を、ユーザが自由に
アクセスすることの許可されないホストマシン上の安全
なメディア２２０２に格納し、ユーザによる不正なイン
テグリティ・チェック値（ＩＣＶ）の書き換えを防止し
た例である。このような構成として、例えばメディア２
２０１を装着したデバイスが、メディア２２０１の再生
を実行する際にホストマシンであるＰＣ、サーバにおい
てＩＣＶのチェックを実行して再生の可否を判定する構
成とすれば、不正なコピーライセンスあるいは改竄ライ
センスの再生を防止できる。

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

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

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

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

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

【０２７７】また、コンテンツを利用許可するライセン
スを特定するためにコンテンツのヘッダに記載されてい
る情報はライセンスを一意に識別するライセンスIDでな
くてもよい。上記の実施例では、ライセンスＩＤが、コ
ンテンツの利用に必要なライセンスを特定する情報であ
り、あるライセンスが利用を許可するコンテンツを特定
する情報であり、クライアント１からライセンス要求に
よって要求されるライセンスを識別する情報である。コ
ンテンツにコンテンツのそのコンテンツに関する各種属
性情報のリストが記載され、ライセンスに、そのライセ
ンスによって利用許可されるコンテンツの条件式を記載
するようにしても良い。この場合では、コンテンツに含
まれる属性情報がそのコンテンツの利用を許可するライ
センスを特定する情報であり、ライセンスに含まれる条
件式がそのライセンスが利用を許可するコンテンツを特
定する情報であり、ライセンスＩＤはライセンスを一意
に識別する情報となる。このようにした場合には、一つ
のコンテンツに複数のライセンスを対応付けることが可
能になり、ライセンスの発行を柔軟に行うことができ
る。

【０２７８】また、本明細書において、システムとは、
複数の装置により構成される装置全体を表すものであ
る。

【０２７９】

【発明の効果】以上の如く、本発明の情報処理装置およ
び方法、ライセンスサーバ、並びにプログラムによれ
ば、暗号化されたデータを自由に配布できるようにし、
別途ライセンスを取得することでコンテンツを利用でき
るようにしたことで、コンテンツの流通を妨げることな
く、著作権を保護し、適切な使用料の徴収をすることが
できる。

【図面の簡単な説明】

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

【図２】図１のクライアントの構成を示すブロック図で
ある。

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

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

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

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

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

【図８】ライセンスの構成を示す図である。

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

【図１０】図６のステップＳ４５におけるライセンス更
新処理の詳細を説明するフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

【図２２】ライセンスのカテゴリを説明する図である。

【図２３】クライアントのリッピング処理を説明するフ
ローチャートである。

【図２４】ウォーターマークの構成を説明する図であ
る。

【図２５】コンテンツのフォーマットの例を示す図であ
る。

【図２６】公開鍵証明書の例を示す図である。

【図２７】コンテンツの配布を説明する図である。

【図２８】クライアントのコンテンツのチェックアウト
処理を説明するフローチャートである。

【図２９】タグによる有効化キーブロックをたどる例を
説明する図である。

【図３０】有効化キーブロックの構成例を示す図であ
る。

【図３１】マークの構成を説明する図である。

【図３２】クライアントのライセンス買い取り処理を説
明するフローチャートである。

【図３３】ライセンスサーバのライセンス買い取り処理
を説明するフローチャートである。

【図３４】マークの構成例を示す図である。

【図３５】クライアントの証明書の登録処理を説明する
フローチャートである。

【図３６】コンテンツサーバの証明書登録処理を説明す
るフローチャートである。

【図３７】グループの証明書の例を示す図である。

【図３８】グルーピングが行われている場合におけるコ
ンテンツサーバの処理を説明するフローチャートであ
る。

【図３９】コンテンツキーの暗号化の例を示す図であ
る。

【図４０】グループに属するクライアントの処理を説明
するフローチャートである。

【図４１】他のクライアントにライセンスをチェックア
ウトするクライアントの処理を説明するフローチャート
である。

【図４２】他のクライアントからライセンスのチェック
アウトを受けるクライアントの処理を説明するフローチ
ャートである。

【図４３】ライセンスのチェックアウトを受けたクライ
アントの再生処理を説明するフローチャートである。

【図４４】他のクライアントからライセンスのチェック
インを受けるクライアントの処理を説明するフローチャ
ートである。

【図４５】他のクライアントにライセンスをチェックイ
ンするクライアントの処理を説明するフローチャートで
ある。

【図４６】MACの生成を説明する図である。

【図４７】ICV生成キーの復号処理を説明するフローチ
ャートである。

【図４８】ICV生成キーの他の復号処理を説明する図で
ある。

【図４９】ICVによるライセンスのコピーの管理を説明
する図である。

【図５０】ライセンスの管理を説明する図である。

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 黒田 壽祐 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 石黒 隆二 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5J104 AA12 MA05 PA07 PA10

Claims (14)

【特許請求の範囲】
1. 【請求項１】 ライセンスを保持していることを条件と
   してコンテンツの利用を許可する情報処理装置におい
   て、 当該コンテンツを利用許可する前記ライセンスを特定す
   るためのライセンス特定情報と、暗号化されたコンテン
   ツデータと、コンテンツデータを復号するために必要な
   鍵情報とを含む前記コンテンツを記憶するコンテンツ記
   憶手段と、 利用許可される前記コンテンツを特定するためのコンテ
   ンツ特定情報を含むライセンスを記憶するライセンス記
   憶手段と、前記コンテンツを利用許可することができる
   ライセンスが前記ライセンス記憶手段に記憶されている
   か否かを判定する判定手段と、 前記判定手段によりライセンスが記憶されていると判断
   されたことを条件として前記コンテンツのコンテンツデ
   ータを復号する復号手段とを備えることを特徴とする情
   報処理装置。
2. 【請求項２】 前記情報処理装置は更に、 ライセンスサーバにライセンスを識別するためのライセ
   ンス識別情報を含むライセンス要求を送信する送信手段
   と、 ライセンスサーバによって送信されたライセンスを受信
   する受信手段とを備え、 前記受信手段により受信されたライセンスは前記ライセ
   ンス記憶手段に記憶されることを特徴とする請求項１記
   載の情報処理装置。
3. 【請求項３】 前記コンテンツデータはテキストデー
   タ、画像データ、音声データ、動画データあるいはそれ
   らを組み合わせたデータであり、 前記復号手段により復号されたコンテンツデータを再生
   する再生手段を更に備えることを特徴とする請求項１記
   載の情報処理装置。
4. 【請求項４】 前記鍵情報はEKB（Enabling Key Bloc
   k）を含み、 前記情報処理装置は更にデバイスノードキーを記憶する
   デバイスノードキー記憶手段を備え、 前記復号手段は前記デバイスノードキー記憶手段に記憶
   されている前記デバイスノードキーを用いて前記EKB（E
   nabling Key Block）を復号処理し得られたルートキー
   を用いて前記暗号化されたコンテンツデータを復号する
   ことを特徴とする請求項１記載の情報処理装置。
5. 【請求項５】 前記鍵情報は更に前記EKB（Enabling Ke
   y Block）のルートキーによって暗号化されたコンテン
   ツキーを含み、 前記コンテンツデータは前記コンテンツキーにより暗号
   化されており、 前記復号手段は前記デバイスノードキー記憶手段に記憶
   されている前記デバイスノードキーを用いて前記EKB（E
   nabling Key Block）を復号処理し得られたルートキー
   を用いて復号された前記コンテンツキーを用いて前記暗
   号化されたコンテンツデータを復号することを特徴とす
   る請求項４記載の情報処理装置。
6. 【請求項６】 前記ライセンスは更に、当該ライセンス
   によって利用可能となるコンテンツの使用条件を示す使
   用条件情報を含むことを特徴とする請求項１記載の情報
   処理装置。
7. 【請求項７】 前記ライセンスは更に、ライセンスサー
   バの秘密鍵によりなされた電子署名を含むことを特徴と
   する請求項１記載の情報処理装置。
8. 【請求項８】 前記情報処理装置は、更に情報処理装置
   を識別する端末識別情報を記憶する端末識別情報記憶手
   段を備え、前記ライセンス要求は更に、端末識別情報記
   憶手段に記憶されている前記端末識別情報を含み、 前記受信手段により受信された前記ライセンスは更に、
   前記端末識別情報を含み、 前記判定手段は、前記ライセンスに含まれる前記端末識
   別情報と前記端末識別情報記憶手段に記憶されている前
   記端末識別情報とを比較し、両者が一致している場合に
   限り、当該ライセンスを前記コンテンツの利用を許可で
   きるライセンスであると判定することを特徴とする請求
   項２記載の情報処理装置。
9. 【請求項９】 ライセンスを保持していることを条件と
   してコンテンツの利用を許可する情報処理方法であっ
   て、 当該コンテンツを利用許可する前記ライセンスを特定す
   るためのライセンス特定情報と、暗号化されたコンテン
   ツデータと、コンテンツデータを復号するために必要な
   鍵情報と、を含むコンテンツを記憶するステップと、 当該ライセンスによって利用許可される前記コンテンツ
   を特定するためのコンテンツ特定情報を含むライセンス
   を記憶するステップと、 前記コンテンツを利用許可することができるライセンス
   が前記ライセンス記憶手段に記憶されているか否かを判
   定するステップと、 前記判定手段によりライセンスが記憶されていると判断
   されたことを条件として前記コンテンツのコンテンツデ
   ータを復号するステップとを含むことを特徴とする情報
   処理方法。
10. 【請求項１０】 ライセンスを保持していることを条件
    としてコンテンツの利用を許可する処理をコンピュータ
    に実行させるプログラムであって、 当該コンテンツを利用許可する前記ライセンスを特定す
    るためのライセンス特定情報と、暗号化されたコンテン
    ツデータと、コンテンツデータを復号するために必要な
    鍵情報と、を含むコンテンツを記憶するステップと、 当該ライセンスによって利用許可される前記コンテンツ
    を特定するためのコンテンツ特定情報を含むライセンス
    を記憶するステップと、 前記コンテンツを利用許可することができるライセンス
    が前記ライセンス記憶手段に記憶されているか否かを判
    定するステップと、 前記判定手段によりライセンスが記憶されていると判断
    されたことを条件として前記コンテンツのコンテンツデ
    ータを復号するステップとをコンピュータに実行させる
    プログラム。
11. 【請求項１１】 前記プログラムあるいはその一部が暗
    号化されていることを特徴とする請求項１０記載のプロ
    グラム。
12. 【請求項１２】 コンテンツの利用を許可するライセン
    スを発行するライセンスサーバにおいて、 当該ライセンスによって利用許可される前記コンテンツ
    を特定するためのコンテンツ特定情報と、情報処理装置
    を識別する端末識別情報を含む前記ライセンスを記憶す
    るライセンス記憶手段と情報処理装置から送信された、
    ライセンスを識別するライセンス識別情報を含むライセ
    ンス要求を受信する受信手段と、 前記ライセンス要求に含まれる前記ライセンス識別情報
    に対応する前記ライセンスを前記ライセンス記憶手段か
    ら抽出する抽出手段と、 前記抽出手段により抽出された前記ライセンスに前記端
    末識別情報を付加する処理手段と、 ライセンスサーバの秘密鍵を用いて、前記処理手段によ
    り端末識別情報を付加されたライセンスに電子署名を付
    加する署名手段と、 前記署名手段により署名されたライセンスを前記ライセ
    ンス要求を送信した情報処理装置に送信する送信手段と
    を備えることを特徴とするライセンスサーバ。
13. 【請求項１３】 コンテンツの利用を許可するライセン
    スを発行する情報処理方法であって、 当該ライセンスによって利用許可される前記コンテンツ
    を特定するためのコンテンツ特定情報と、情報処理装置
    を識別する端末識別情報を含む前記ライセンスを記憶す
    るステップと、 情報処理装置から送信された、ライセンスを識別するラ
    イセンス識別情報を含むライセンス要求を受信するステ
    ップと、 前記ライセンス要求に含まれる前記ライセンス識別情報
    に対応する前記ライセンスを前記ライセンス記憶手段か
    ら抽出するステップと、 前記抽出手段により抽出された前記ライセンスに前記端
    末識別情報を付加するステップと、 ライセンスサーバの秘密鍵を用いて、前記処理手段によ
    り端末識別情報を付加されたライセンスに電子署名を付
    加するステップと、 前記署名手段により署名されたライセンスを前記ライセ
    ンス要求を送信した情報処理装置に送信するステップと
    を含むことを特徴とする情報処理方法。
14. 【請求項１４】 コンテンツの利用を許可するライセン
    スを発行する処理処理をコンピュータに実行させるプロ
    グラムであって、 当該ライセンスによって利用許可される前記コンテンツ
    を特定するためのコンテンツ特定情報と、情報処理装置
    を識別する端末識別情報を含む前記ライセンスを記憶す
    るステップと、 情報処理装置から送信された、ライセンスを識別するラ
    イセンス識別情報を含むライセンス要求を受信するステ
    ップと、 前記ライセンス要求に含まれる前記ライセンス識別情報
    に対応する前記ライセンスを前記ライセンス記憶手段か
    ら抽出するステップと、 前記抽出手段により抽出された前記ライセンスに前記端
    末識別情報を付加するステップと、 ライセンスサーバの秘密鍵を用いて、前記処理手段によ
    り端末識別情報を付加されたライセンスに電子署名を付
    加するステップと、 前記署名手段により署名されたライセンスを前記ライセ
    ンス要求を送信した情報処理装置に送信するステップと
    をコンピュータに実行させるプログラム。