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

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

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

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

【００２５】ユーザが、入力部２６を操作することでコ
ンテンツサーバ３に対するアクセスを指令すると、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 Blook）により構成される。各暗号化ブロック
は、イニシャルベクトル（IV（Initial Vector））、シ
ード（Seed）、およびコンテンツデータをキーK'cで暗
号化したデータE_{K ' c}(data)により構成されている。

【００３８】キーK'cは、次式により示されるように、
コンテンツキーKcと、乱数で設定される値Seedをハッシ
ュ関数に適用して演算された値により構成される。

【００３９】K'c＝Hash(Kc,Seed)

【００４０】イニシャルベクトルIVとシードSeedは、各
暗号化ブロック毎に異なる値に設定される。

【００４１】この暗号化は、コンテンツのデータを８バ
イト単位で区分して、８バイト毎に行われる。後段の８
バイトの暗号化は、前段の８バイトの暗号化の結果を利
用して行われるCBC（Cypher Block Chaning）モードで
行われる。

【００４２】CBCモードの場合、最初の８バイトのコン
テンツデータを暗号化するとき、その前段の８バイトの
暗号化結果が存在しないため、最初の８バイトのコンテ
ンツデータを暗号化するときは、イニシャルベクトルIV
を初期値として暗号化が行われる。

【００４３】このCBCモードによる暗号化を行うこと
で、１つの暗号化ブロックが解読されたとしても、その
影響が、他の暗号化ブロックにおよぶことが抑制され
る。

【００４４】なお、この暗号化については、図４６を参
照にして、後に詳述する。

【００４５】以上のようにして、クライアント１は、コ
ンテンツサーバ３からコンテンツを無料で、自由に取得
することができる。従って、コンテンツそのものは、大
量に、配布することが可能となる。

【００４６】しかしながら、各クライアント１は、取得
したコンテンツを利用するとき、ライセンスを保持して
いる必要がある。そこで、図６を参照して、クライアン
ト１がコンテンツを再生する場合の処理について説明す
る。

【００４７】ステップＳ４１において、クライアント１
のCPU２１は、ユーザが入力部２６を操作することで指
示したコンテンツの識別情報（CID）を取得する。この
識別情報は、例えば、コンテンツのタイトルや、記憶さ
れている各コンテンツ毎に付与されている番号などによ
り構成される。

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

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

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

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

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

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

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

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

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

【００５７】ライセンスサーバ４は、図９を参照して後
述するように、ユーザIDとパスワード、並びにライセン
ス指定情報に基づいてライセンスを、そのユーザの秘密
鍵（Private Key）、並びにその秘密鍵に対応する公開
鍵（Public Key）の証明書とともに送信してくる（ステ
ップＳ１０９）か、または、条件が満たされない場合に
は、ライセンスを送信してこない（ステップＳ１１
２）。

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

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

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

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

【００６２】クライアント１に提供されるライセンス
は、例えば、図８に示されるように、使用条件、リーフ
IDおよびデバイスノードキー（Device Naode Key（DN
K））を含んでいる。

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

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

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

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

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

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

【００６９】ステップＳ１０８において、CPU２１は、
ステップＳ１０７で選択した使用条件を、ステップＳ１
０６で割り当てたDNKとリーフIDに対応付けて付加す
る。これにより、図８に示されるような構成のライセン
スが生成される。

【００７０】次に、ステップＳ１０９に進み、ライセン
スサーバ４のCPU２１は、そのライセンス（図８に示さ
れる構成を有する）を、そのクライアント１のユーザに
割り当てる秘密鍵、並びに、その秘密鍵に対応する公開
鍵の証明書とともに、通信部２９からインターネット２
を介してクライアント１に送信させる。但し、秘密鍵と
証明書は、そのユーザに１つ割り当てられるのもであ
り、ライセンス毎に異なるものではないので、既に、送
付されている場合には、省略することができる。

【００７１】ステップＳ１１０においてライセンスサー
バ４のCPU２１は、ステップＳ１０９の処理で、いま送
信したライセンス（使用条件、リーフID、およびDNKを
含む）を、証明書および秘密鍵とともに、ステップＳ１
０２の処理で取り込まれたユーザ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を含むパスの
各キーで管理される。

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

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

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

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

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

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

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

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

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

【００９３】例えば、図１２に示されるツリー構造にお
いて、１つのグループに含まれる３つのデバイス０，
１，２，３はノードキーとして共通のキーＫ００、Ｋ
０、KRを保有する。このノードキー共有構成を利用する
ことにより、共通のコンテンツキーをデバイス０，１，
２，３のみに提供することが可能となる。たとえば、共
通に保有するノードキーＫ００自体をコンテンツキーと
して設定すれば、新たな鍵送付を実行することなくデバ
イス０，１，２，３のみが共通のコンテンツキーの設定
が可能である。また、新たなコンテンツキーＫｃｏｎを
ノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｃ
ｏｎ）を、ネットワークを介してあるいは記録媒体に格
納してデバイス０，１，２，３に配布すれば、デバイス
０，１，２，３のみが、それぞれのデバイスにおいて保
有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ０
０，Ｋｃｏｎ）を解いてコンテンツキーＫｃｏｎを得る
ことが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂ
をＫａによって暗号化したデータであることを示す。

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

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

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

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

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

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

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

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

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

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

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

【０１０５】図１６に示すように、デバイス０は、記録
媒体に格納されている世代t時点のＥＫＢと、自分があ
らかじめ格納しているノードキーＫ０００を用いて、上
述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）
００を生成する。さらに、デバイス０は、復号した更新
ノードキーＫ（ｔ）００を用いて、更新コンテンツキー
Ｋ（ｔ）ｃｏｎを復号して、後にそれを使用するために
自分だけが持つリーフキーＫ００００で暗号化して格納
する。

【０１０６】図１７に有効化キーブロック（ＥＫＢ）の
フォーマット例を示す。バージョン６０１は、有効化キ
ーブロック（ＥＫＢ）のバージョンを示す識別子であ
る。なお、バージョンは、最新のＥＫＢを識別する機能
と、コンテンツとの対応関係を示す機能を持つ。デプス
は、有効化キーブロック（ＥＫＢ）の配布先のデバイス
に対する階層ツリーの階層数を示す。データポインタ６
０３は、有効化キーブロック（ＥＫＢ）中のデータ部６
０６の位置を示すポインタであり、タグポインタ６０４
はタグ部６０７の位置、署名ポインタ６０５は署名６０
８の位置を示すポインタである。

【０１０７】データ部６０６は、例えば更新するノード
キーを暗号化したデータを格納する。例えば図１６に示
すような更新されたノードキーに関する各暗号化キー等
を格納する。

【０１０８】タグ部６０７は、データ部６０６に格納さ
れた暗号化されたノードキー、リーフキーの位置関係を
示すタグである。このタグの付与ルールを図１８を用い
て説明する。

【０１０９】図１８では、データとして先に図１５Ａで
説明した有効化キーブロック（ＥＫＢ）を送付する例を
示している。この時のデータは、図１８Ｂの表に示すよ
うになる。このときの暗号化キーに含まれるトップノー
ドのアドレスをトップノードアドレスとする。この例の
場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれてい
るので、トップノードアドレスはKRとなる。このとき、
例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）
Ｒ）は、図１８Ａに示す階層ツリーに示す位置Ｐ０に対
応する。次の段のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ
（ｔ）０）であり、ツリー上では前のデータの左下の位
置Ｐ００に対応する。ツリー構造の所定の位置から見
て、その下に、データがある場合は、タグが０、ない場
合はタグが１に設定される。タグは｛左（Ｌ）タグ，右
（Ｒ）タグ｝として設定される。図１８Ｂの最上段のデ
ータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）に対応する位置
POの左下の位置POOにはデータがあるので、Ｌタグ＝
０、右にはデータがないので、Ｒタグ＝１となる。以
下、すべてのデータにタグが設定され、図１８Ｃに示す
データ列、およびタグ列が構成される。

【０１１０】タグは、対応するデータＥｎｃ（Ｋｘｘ
ｘ，Ｋｙｙｙ）が、ツリー構造のどこに位置しているの
かを示すために設定されるものである。データ部６０６
に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）
・・・は、単純に暗号化されたキーの羅列データに過ぎ
ないが、上述したタグによってデータとして格納された
暗号化キーのツリー上の位置が判別可能となる。上述し
たタグを用いずに、先の図１５で説明した構成のよう
に、暗号化データに対応させたノード・インデックスを
用いて、例えば、 ０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ） ００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０） ０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（ｔ）００） ・・・のようなデータ構成とすることも可能であるが、
このようなインデックスを用いた構成とすると、冗長な
データとなりデータ量が増大し、ネットワークを介する
配信等においては好ましくない。これに対し、上述した
タグをキー位置を示す索引データとして用いることによ
り、少ないデータ量でキー位置の判別が可能となる。

【０１１１】図１７に戻って、ＥＫＢフォーマットにつ
いてさらに説明する。署名（Signature）６０８は、有
効化キーブロック（ＥＫＢ）を発行した例えば鍵管理セ
ンタ（ライセンスサーバ４）、コンテンツロバイダ（コ
ンテンツサーバ３）、決済機関（課金サーバ５）等が実
行する電子署名である。ＥＫＢを受領したデバイスは、
署名検証によって正当な有効化キーブロック（ＥＫＢ）
発行者が発行した有効化キーブロック（ＥＫＢ）である
ことを確認する。

【０１１２】以上のようにして、ライセンスサーバ４か
ら供給されたライセンスに基づいて、コンテンツサーバ
３から供給されたコンテンツを利用する処理をまとめる
と、図１９に示されるようになる。

【０１１３】すなわち、コンテンツサーバ３からクライ
アント１に対してコンテンツが提供されるとともに、ラ
イセンスサーバ４からクライアント１にライセンスが供
給される。ライセンスには、DNKが含まれている（図
８）。コンテンツは、コンテンツキーKcにより、暗号化
されており（Enc（Kc，Content））、コンテンツキーKc
は、ルートキーKR(EKBから得られるキーであって、図５
におけるキーＫ_EKBCに対応する)で暗号化され（Enc（K
R，Kc））、EKBとともに、暗号化されたコンテンツに付
加されてクライアント１に提供される。

【０１１４】図１９の例におけるEKBには、例えば、図
２０に示されるように、DNKで暗号化したルートキーKR
が含まれている（Enc（DNK，KR））。従って、クライア
ント１は、ライセンスに含まれるDNKを利用して、EKBか
らルートキーKRを得ることができる。さらに、ルートキ
ーKRを用いて、Enc（KR，Kc）からコンテンツキーKcを
復号することができ、コンテンツキーKcを用いて、Enc
（Kc，Content）からコンテンツを復号することができ
る。

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

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

【０１１７】また、ライセンスをキー（DNKとリーフI
D）と使用条件の２つから構成することにより（図
８）、再暗号化等をすることなく、使用条件を変更する
ことが可能になる。また、証明書と秘密鍵をライセンス
とともに配信するようにすることで、エンドユーザも、
これらを用いて不正コピーを防止可能なコンテンツを作
成することが可能になる。

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

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

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

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

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

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

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

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

【０１２６】この場合の処理の例について、図２３のフ
ローチャートを参照して説明する。図２３の処理は、ユ
ーザが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））、コンテンツをコンテン
ツキーK_cで暗号化したデータ（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（Portabal 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（Integerity CheckValue）を用いずに
グループ化が可能となる。このグループ化は、小規模の
グループに適用するのに向いている。

【０２１４】本発明においては、ライセンスもチェック
アウト、あるいはチェックインしたり、ムーブしたり、
コピーしたりすることが可能とされる。但し、これらの
処理は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 DisKRead Only Memory),DVD(Digital
Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ
（Mini-Disk）を含む）、もしくは半導体メモリ４４な
どよりなるパッケージメディアにより構成されるだけで
なく、装置本体に予め組み込まれた状態でユーザに提供
される、プログラムが記録されているROM２２や、記憶
部２８に含まれるハードディスクなどで構成される。

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

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

【０２６７】

【発明の効果】本発明の情報処理装置および方法、記録
媒体、並びにプログラムによれば、ヘッダのデータに基
づいてデジタル署名を作成し、ヘッダとともにフォーマ
ット化するようにしたので、コンテンツの作成者を検証
することが可能となり、不正にコピーされたコンテンツ
が流通してしまうことを抑制することが可能となる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/08 Ｈ０４Ｌ 9/00 ６０１Ｂ 9/32 ６７３Ａ Ｆターム(参考） 5B017 AA06 CA15 CA16 5B085 AE13 BG07 5J104 AA01 AA09 AA13 AA14 AA16 EA05 EA06 EA16 EA19 JA13 LA03 LA06 NA02 NA04 NA12 PA07 PA11

Claims (5)

【特許請求の範囲】
1. 【請求項１】 コンテンツを出力する情報処理装置にお
   いて、 出力する前記コンテンツを取得する取得手段と、 前記取得手段により取得された前記コンテンツのヘッダ
   を作成するヘッダ作成手段と、 前記ヘッダ作成手段により作成された前記ヘッダのデー
   タに基づいたデジタル署名を作成する署名作成手段と、 前記取得手段により取得された前記コンテンツを暗号化
   する暗号化手段と、 前記ヘッダ作成手段により作成された前記ヘッダと、前
   記暗号化手段により暗号化された前記コンテンツをファ
   イルフォーマットにフォーマット化し、出力するフォー
   マット化手段とを備えることを特徴とする情報処理装
   置。
2. 【請求項２】 前記取得手段は、前記デジタル署名に使
   用する秘密鍵を、前記コンテンツのライセンスとともに
   さらに取得することを特徴とする請求項１に記載の情報
   処理装置。
3. 【請求項３】 コンテンツを出力する情報処理装置の情
   報処理方法において、 出力する前記コンテンツを取得する取得ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツのヘッダを作成するヘッダ作成ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダのデータに基づいたデジタル署名を作成する署名作
   成ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツを暗号化する暗号化ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダと、前記暗号化ステップの処理により暗号化された
   前記コンテンツをファイルフォーマットにフォーマット
   化し、出力するフォーマット化ステップとを含むことを
   特徴とする情報処理方法。
4. 【請求項４】 コンテンツを出力する情報処理装置のプ
   ログラムにおいて、 出力する前記コンテンツを取得する取得ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツのヘッダを作成するヘッダ作成ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダのデータに基づいたデジタル署名を作成する署名作
   成ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツを暗号化する暗号化ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダと、前記暗号化ステップの処理により暗号化された
   前記コンテンツをファイルフォーマットにフォーマット
   化し、出力するフォーマット化ステップとを含むことを
   特徴とするコンピュータが読み取り可能なプログラムが
   記録されている記録媒体。
5. 【請求項５】 コンテンツを出力する情報処理装置を制
   御するコンピュータに、 出力する前記コンテンツを取得する取得ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツのヘッダを作成するヘッダ作成ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダのデータに基づいたデジタル署名を作成する署名作
   成ステップと、 前記取得ステップの処理により取得された前記コンテン
   ツを暗号化する暗号化ステップと、 前記ヘッダ作成ステップの処理により作成された前記ヘ
   ッダと、前記暗号化ステップの処理により暗号化された
   前記コンテンツをファイルフォーマットにフォーマット
   化し、出力するフォーマット化ステップとを実行させる
   プログラム。