JP2004030326A - コンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】コンテンツの利用者にライセンスを与えてコンテンツの利用を制御しコンテンツの保護を図る。
【解決手段】ライセンス・トークンは、再生装置で生成されたノンスとコンテンツの識別番号、利用条件に、コンテンツ利用許可の権限者が電子署名やメッセージ認証コードを付加したものとする。再生装置は、自分が生成したノンスが含まれることで、ライセンス・トークンが自分宛てであることを知り、なお且つコンテンツ提供者又はシステム管理者が電子署名やメッセージ認証コードが付加されていることで、ライセンス・トークンとして有効であることを判断する。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、広帯域通信網（ｘＤＳＬ：ｘ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ、ＣＡＴＶ（Ｃａｂｌｅ　ＴＶ）、無線ネットワーク）などによって配信される音楽データや画像データ、電子出版物などのデジタル・データや動画像などリッチ・コンテンツの利用を管理するコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムに係り、特に、使用許諾など何らかの契約や利用条件に基づいてコンテンツの利用を管理するコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、コンテンツの利用者にライセンスを与えることによりコンテンツの利用を制御しコンテンツの保護を図るコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムに係り、特に、コンテンツ鍵の不正利用を防止しながらコンテンツの利用者にライセンスを与えるコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムに関する。
【０００３】
【従来の技術】
近年の広帯域通信網（ｘＤＳＬ：ｘ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ、ＣＡＴＶ（Ｃａｂｌｅ　ＴＶ）、無線ネットワークなど）の普及により、音楽データや画像データ、電子出版物などのデジタル・データや動画像などリッチ・コンテンツの配信もユーザにストレスなく伝送できるような仕組みが整いつつある。
【０００４】
一方、配信されるコンテンツはデジタル・データであり、コピーや改ざんなどの操作を比較的容易に行うことができる。また、現在これらのコンテンツのコピーや改竄などの不正行為は頻繁に行われており、これがデジタル・コンテンツ・ベンダの利益を阻害する主要な要因となっている。この結果、コンテンツの値段も高くしなければならなくなり、普及の障壁となるという悪循環が起こっている。
【０００５】
暗号技術を用いることによって、通信路上に流れるコンテンツを悪意のある第三者から保護することが可能となっている。しかしながら、コンテンツの配信過程だけでなく、コンテンツが正規のユーザに提供された後に行なわれる不正コピーや不正利用も大きな問題となっている。
【０００６】
デジタル・コンテンツに関するこの種の問題への対策として、最近では権利管理方式（ＤＲＭ：Ｄｉｇｉｔａｌ　Ｒｉｇｈｔｓ　Ｍａｎａｇｅｍｅｎｔ）と呼ばれる方式が採用されている。以下では、このＤＲＭの概要とその問題点について説明する。
【０００７】
ＤＲＭ（ Ｄｉｇｉｔａｌ　Ｒｉｇｈｔ　Ｍａｎａｇｅｍｅｎｔ ）：
権利情報管理方式（ＤＲＭ）によって、ユーザはコンテンツの利用許可（ライセンス）を得なければ，コンテンツを利用できない仕組みが実現される。このようなシステムとしては米マイクロソフト社の”Ｗｉｎｄｏｗｓ　Ｍｅｄｉａ　Ｒｉｇｈｔ　Ｍａｎａｇｅｒ”や、米ＩＢＭ社の”Ｅｌｅｃｔｒｏｎｉｃ　Ｍｅｄｉａ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ（ＥＭＭＳ）”と呼ばれるシステムが挙げられる。
【０００８】
ＤＲＭのシステムは、典型的にはコンテンツ提供者とライセンス管理者とユーザという参加者で構成される。ユーザは、コンテンツの再生装置を所持し、それを使ってコンテンツを利用する。また、ライセンス管理者はのユーザにライセンスの発行を行なう。また、コンテンツ提供者は、ユーザにコンテンツの提供を行なう。
【０００９】
コンテンツ（Ｃｏｎｔ）は、コンテンツ提供者によって、コンテンツ毎に異なる鍵（コンテンツ鍵Ｋ_ｃ）で暗号化された形式Ｅ（Ｋ_ｃ，Ｃｏｎｔ）で配布される。本明細書中では、これを暗号化コンテンツと呼ぶことにする。
【００１０】
ユーザは、あるコンテンツＣｏｎｔを使用する場合、ライセンス管理者に対してライセンス発行を要求する。これに対し、ライセンス発行者は、ユーザへの課金処理などを行なった上でライセンスを発行する。
【００１１】
ここで言うライセンスの発行は、実際には、ユーザの再生装置にコンテンツ鍵Ｋ_ｃを与えることである。このために、ライセンス管理者は再生装置との間で、再生装置毎に異なる暗号鍵Ｋ_ｕを共有しており（暗号鍵Ｋ_ｕの共有は、ライセンス発行時に行われるか、又はあらかじめ共有したものが再生装置に組み込まれている）、コンテンツ鍵Ｋ_ｃを暗号鍵Ｋ_ｕで暗号化したデータＥ（Ｋ_ｕ，Ｋ_ｃ）として再生装置に送付する。このデータのことを「ライセンス・トークン」と呼ぶ。
【００１２】
ライセンスを受けたユーザの再生装置は、暗号鍵Ｋｕと受け取ったライセンス・トークンＥ（Ｋ_ｕ，Ｋ_ｃ）と暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）を使って、コンテンツを再生することができる。まず、ライセンス・トークンＥ（Ｋ_ｕ，Ｋ_ｃ）からコンテンツ鍵Ｋ_ｃを復号し、次いでコンテンツ鍵Ｋ_ｃを使って暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）からコンテンツＣｏｎｔを復号して再生する。したがって、再生装置とライセンス・トークンと暗号化コンテンツの組み合わせが正しいときだけ、つまりライセンスを得たユーザだけがコンテンツを利用できることになる。
【００１３】
ここで、コンテンツの利用権を保護するためには、再生装置側では、復号されたコンテンツが外部に漏洩することを防がなければならない。このためには、再生装置は、暗号鍵Ｋ_ｕやコンテンツ鍵Ｋ_ｃや復号されたコンテンツＣｏｎｔを外部に漏らさないように処理しなければならない。何故なら、復号されたコンテンツが一旦外部に漏洩すれば、それを複製し利用することが制約なしに可能になるからである。言い換えれば、再生装置には、暗号鍵Ｋ_ｕやコンテンツ鍵Ｋ_ｃ、並びに復号されたコンテンツＣｏｎｔを外部に漏らさないで処理できるという条件が必要である。本明細書中では、このような条件を備えた再生装置のことを「正当」であると呼ぶことにする。
【００１４】
ＤＲＭでは、コンテンツのライセンス（利用許可）をユーザに与えることは、コンテンツ鍵Ｋ_ｃをそのユーザの再生装置に与えることで実現される。このライセンス供与の際に、コンテンツ鍵Ｋ_ｃを受け取る再生装置は正当であるという条件が必須である。したがって、ライセンスの発行を行なうライセンス発行者は、発行相手の再生装置を特定し、正当な再生装置だけにコンテンツ鍵を与えるようにしなければならない。このため、ライセンス発行者は正当な再生装置に関するデータベースを持ち、ライセンス発行はそれに基づいて行なう必要がある。
【００１５】
しかしながら、多数の再生装置が存在する場合を考えると、このようなデータベースの検索は時間あるいはコストを要する処理となる。特に、コンテンツの毎回ダウンロードなどの仕組みにより、ライセンス発行が頻繁に行なわれる場合、データベースの置かれるサーバの負荷が過剰になる。つまり、ＤＲＭでのライセンス発行は、再生装置の個数の増加に対してスケーラビリティのない処理となる。
【００１６】
例えば，特定のユーザに対してコンテンツを提供する場合を考えると、コンテンツ提供の前にユーザ認証を行うことになる。
【００１７】
ＤＲＭの方法を使うのであれば、さらにユーザ認証に加えてそのユーザが持つコンテンツの再生装置を特定し、再生装置に専用のライセンスを生成するという処理が必要になる。このことはコンテンツ提供の処理速度を低下させてしまう。
【００１８】
【発明が解決しようとする課題】
本発明の目的は、使用許諾など何らかの契約や利用条件に基づいてコンテンツの利用を好適に管理することができる、優れたコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００１９】
本発明のさらなる目的は、コンテンツの利用者にライセンスを与えることによりコンテンツの利用を制御しコンテンツの保護を図ることができる、優れたコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００２０】
本発明のさらなる目的は、コンテンツ鍵の不正利用を防止しながらコンテンツの利用者にライセンスを与えることができる、優れたコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムを提供することにある。
【００２１】
【課題を解決するための手段及び作用】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、ライセンスの配布によりコンテンツの利用を管理するコンテンツ利用管理システムであって、
コンテンツを利用する正当な装置で生成された一回限りの乱数からなるノンスとコンテンツの利用許可の権限者に関する認証情報を少なくとも含むデータをライセンス・トークンとして用い、
コンテンツを利用する正当な装置側では、ライセンス・トークンに自分が生成したノンスが含まれていること及びコンテンツ利用許可の権限者に関する認証情報の認証処理によりライセンス・トークンの有効性を検証し、ライセンス・トークンが有効である場合に該当するコンテンツをユーザに利用させる、
ことを特徴とするコンテンツ利用管理システムである。
【００２２】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【００２３】
また、本発明の第２の側面は、ライセンスの配布によりコンテンツの利用を管理する情報処理装置又は情報処理方法であって、
コンテンツの利用者から一回限りの乱数であるノンスを受信するノンス受信手段又はステップと、
受信したノンスと自身の認証情報を少なくとも含むライセンス・トークンをコンテンツの利用者に配布するライセンス・トークン発行手段又はステップと、
を具備することを特徴とする情報処理装置又は情報処理方法である。
【００２４】
また、本発明の第３の側面は、コンテンツを安全に提供する情報処理装置又は情報処理方法であって、
コンテンツを正当に利用する装置にイネーブル鍵を発行するイネーブル鍵発行手段又はステップと、
コンテンツ毎に固有のコンテンツ鍵でコンテンツを暗号化するコンテンツ暗号化手段又はステップと、
コンテンツ鍵を含むデータをイネーブル鍵で暗号化してなるコンテンツ・トークンを生成するコンテンツ・トークン生成手段又はステップと、
暗号化コンテンツをコンテンツ・トークンとともに配布するコンテンツ提供手段又はステップと、
を具備することを特徴とする情報処理装置又は情報処理方法である。
【００２５】
また、本発明の第４の側面は、ライセンスの取得によりコンテンツの正当な利用を行なう情報処理装置又は情報処理方法であって、
コンテンツを取得するコンテンツ取得手段又はステップと、
一回限りの乱数であるノンスを発行するノンス発行手段又はステップと、
コンテンツに関するライセンス・トークンを受信して、前記ノンス発行手段又はステップが発行したノンスが含まれているか、及び所定のコンテンツ利用許可の権限者から得られたものであるかどうかを認証することにより該ライセンス・トークンの有効性を検証するライセンス・トークン検証手段又はステップと、
ライセンス・トークンが有効であることに応答して、該当するコンテンツの利用を行なうコンテンツ利用手段又はステップと、
を具備することを特徴とする情報処理装置又は情報処理方法である。
【００２６】
本発明では、再生装置で生成されたノンス（１回限りの乱数）とコンテンツの識別番号、利用条件（例えば利用許可の回数や期間など）に、コンテンツの提供者あるいはシステム管理者などのコンテンツ利用許可の権限者が、電子署名やメッセージ認証コードを付加したものをランセンス・トークンとして用いる。
【００２７】
ライセンス・トークンを受け取った再生装置は、自分が生成したノンスが含まれることで、ライセンス・トークンが自分宛てであることを知り、なお且つコンテンツの提供者又はシステム管理者が電子署名やメッセージ認証コードが付加されていることで、ライセンス・トークンとして有効であることを判断することができる。
【００２８】
また本発明では、コンテンツ鍵をライセンスとして配布する代わりに、コンテンツ配布と同時にコンテンツ・トークンとして配布するようになっている。このコンテンツ・トークンは、コンテンツ鍵をイネーブル鍵で暗号化したデータである。また、イネーブル鍵はライセンスの有無とは独立に、正当な再生装置だけが利用可能な鍵である。
【００２９】
コンテンツの識別情報は、暗号化コンテンツ又はコンテンツ・トークンの一部として、コンテンツ鍵又はイネーブル鍵で暗号化して含まれるので、正当な再生装置が判断可能な形式で配布され、コンテンツ利用許可の権限者以外から意図的な改変ができない。したがって、暗号化コンテンツを復号するコンテンツ鍵を再生装置に与えるのではなく、再生装置から判断できる形式で、コンテンツの利用許可の権限者が利用を許可するコンテンツの識別情報を指定することにより、再生装置に対してコンテンツの利用を許可することができる。
【００３０】
そして、再生装置は、ライセンスを取得できたと判断した場合だけ、ライセンスで指定されたコンテンツの識別番号を含むコンテンツ・トークンを自身が保持するイネーブル鍵で復号してコンテンツ鍵を取り出し、次いで、コンテンツ鍵で暗号化コンテンツを復号して得られるコンテンツをユーザに利用させる。したがって、正当な再生装置は、復号したコンテンツそのものを装置外に漏らすことなく、コンテンツを利用に供することができる。
【００３１】
また、イネーブル鍵は、システム管理者が生成するとして、正当な再生装置にイネーブル鍵を利用可能にする方法としては２種類が考えられる。１つの方法は、正当な再生装置にあらかじめイネーブル鍵を配布しておく方法である。
【００３２】
このような方法としては、例えばＲＦＣ（Ｒｅｑｕｅｓｔ　ｆｏｒ　Ｃｏｍｍｅｎｔ）２６２７に記載のユーザ・グループに暗号鍵を共有させる方法のいずれかを用いればよい。最も単純にシステム管理者が再生装置毎にイネーブル鍵を配布する場合には、イネーブル鍵の配布に再生装置の個数Ｎに比例する手間が必要になる。しかし、ＲＦＣ２６２７には、各再生装置に再生装置の個数Ｎの対数に比例するサイズのデータを持たせる階層鍵構造（ｈｉｅｒａｒｃｈｉｃａｌ　ｋｅｙ　ｔｒｅｅ）による管理方式が示されており、これを適用することにより、個数Ｎの対数に比例するサイズのデータのブロードキャストでイネーブル鍵の配布を行なうことができる。
【００３３】
イネーブル鍵を配布するもう１つの方法は、イネーブル鍵を正当な再生装置だけに取得可能な形式で暗号化コンテンツとともに配布する方法である。本出願人に既に譲渡されている特開２００１−３５２３２１号公報（発明の名称：情報システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体）に開示されているように、各再生装置に再生装置に個数Ｎの対数に比例するサイズのデータを持たせることで、イネーブル鍵の配布を再生装置の個数Ｎの対数に比例するサイズのデータを暗号化コンテンツとともに配布することで行なうことができる。
【００３４】
また、耐タンパ性が破壊された再生装置が発生した場合には、イネーブル鍵を更新するようにしてもよい。イネーブル鍵を更新して、新しいコンテンツ鍵でコンテンツを暗号化したものと、新しいイネーブル鍵でコンテンツ鍵を暗号化したものとしてコンテンツの配布を行なうことで、耐タンパ性が破壊された再生装置に含まれる情報を使っても、暗号化コンテンツを２度と復号できなくすることができる。
【００３５】
本発明で重要な点は、ライセンスがコンテンツ鍵でないため、任意の装置にライセンスを与えても、実際にコンテンツを復号できるのは、あらかじめイネーブル鍵を共有している正当な再生装置に限定される、ということである。したがって、本発明によって、ライセンス発行時に発行対象の再生装置を特定して各再生装置に専用のライセンスを発行することが不要になる。これによって、ライセンス発行を高速に処理することが可能になり、再生装置の個数の増加に関してスケーラビリティのよいライセンス発行処理を実現することができる。
【００３６】
また、本発明の第５の側面は、ライセンスの配布によりコンテンツの利用を管理するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
コンテンツの利用者から一回限りの乱数であるノンスを受信するノンス受信ステップと、
受信したノンスと自身の認証情報を少なくとも含むライセンス・トークンをコンテンツの利用者に配布するライセンス・トークン発行ステップと、
を具備することを特徴とするコンピュータ・プログラムである。
【００３７】
また、本発明の第６の側面は、コンテンツを安全に提供するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
コンテンツを正当に利用する装置にイネーブル鍵を発行するイネーブル鍵発行ステップと、
コンテンツ毎に固有のコンテンツ鍵でコンテンツを暗号化するコンテンツ暗号化ステップと、
コンテンツ鍵を含むデータをイネーブル鍵で暗号化してなるコンテンツ・トークンを生成するコンテンツ・トークン生成ステップと、
暗号化コンテンツをコンテンツ・トークンとともに配布するコンテンツ提供ステップと、
を具備することを特徴とするコンピュータ・プログラムである。
【００３８】
また、本発明の第７の側面は、ライセンスの取得によりコンテンツの正当な利用を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
コンテンツを取得するコンテンツ取得ステップと、
１回限りの乱数であるノンスを発行するノンス発行ステップと、
コンテンツに関するライセンス・トークンを受信して、前記ノンス発行ステップにおいて発行したノンスが含まれているか、及び所定のコンテンツ利用許可の権限者から得られたものであるかどうかを認証することにより該ライセンス・トークンの有効性を検証するライセンス・トークン検証ステップと、
ライセンス・トークンが有効であることに応答して、該当するコンテンツの利用を行なうコンテンツ利用ステップと、
を具備することを特徴とするコンピュータ・プログラムである。
【００３９】
本発明の第５乃至第７の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第５乃至第７の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第２乃至第４の各側面に係る情報処理装置又は情報処理方法と同様の作用効果を得ることができる。
【００４０】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【００４１】
【発明の実施の形態】
以下では、本発明の実施形態として、正当な再生装置であらかじめイネーブル鍵が共有されている場合（実施形態１）と、正当な再生装置にのみ取得可能な形式でイネーブル鍵が暗号化コンテンツとともに配布される場合（実施形態２）について、図面を参照しながら詳解する。その前に、まず本発明で用いられる暗号技術について簡単に説明しておく。
【００４２】
Ａ．暗号技術
本明細書では、Ｅ（Ｋ，Ｍ）は、暗号鍵ＫによるデータＭの暗号化を意味する。また、ＭＡＣ（Ｋ，Ｍ）はデータＭに対して鍵Ｋを使って生成したメッセージ認証コードを表す。
【００４３】
メッセージ認証コード（ＭＡＣ：Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）は、共通鍵暗号を利用してデータの改竄の発見とメッセージ生成者の特定を可能にする方法である。データＭの作成者とＭの送付先だけが共通鍵暗号の鍵Ｋを共有していると仮定し、このときデータＭのメッセージ認証コードは鍵Ｋを用いてＭＡＣ（Ｋ，Ｍ）＝Ｅ（Ｋ，ｈ（Ｍ））（鍵Ｋによるｈ（Ｍ）の暗号化データ）とすればよい。ここで、ｈ（）はデータの送り側と受け側が共通に持つ一方向性関数である。一方向性関数としては、例えばＭＤ５やＳＨＡ−１と呼ばれるものが挙げられる（詳しくは、例えばＩＳＯ／ＩＥＣ１０１１８やＦＩＰＳ１８０−１などを参照のこと）。
【００４４】
データＭを送る際に、メッセージ認証コードと組み合わせて、（Ｍ，ＭＡＣ（Ｋ，Ｍ））という形式で送ると、データの受け取り側では、データＭに一方向性関数を適用して、ｈ（Ｍ）＝Ｅ（Ｋ，ｈ（Ｍ））が満たされるかどうかを確認することによって、データＭが改竄されていないことと、メッセージ認証コードＭＡＣ（Ｋ，Ｍ）が鍵Ｋの所有者によって付加されたものであることを確認することができる。
【００４５】
また、以下の説明においてメッセージ認証コードを使う箇所では、メッセージ認証コードの変わりに電子署名を使うこともできる。その場合には、以下の説明でメッセージ認証コードを確認する側が、共通鍵暗号の暗号鍵の代わりに署名検証のための公開鍵を保持すればよい。
【００４６】
電子署名は公開鍵暗号の応用の一種である。ここで、公開鍵暗号方式は、データを暗号化する際に用いる鍵（公開鍵）Ｐ_ｋと、復号化する際に用いる鍵（秘密鍵）Ｓ_ｋが異なり、且つ一方の鍵から他方を算出することが非常に困難であるという性質を持った暗号アルゴリズムである。すなわち、ｒのＰ_ｋによる暗号化をＲ＝Ｅ（Ｐ_ｋ，ｒ）とすれば、暗号データＲの秘密鍵Ｓ_ｋによる復号Ｄ（Ｓ_ｋ，Ｒ）はｒに一致する）。公開鍵暗号については、例えばＩＥＥＥ−Ｐ１３６３で標準的手法がまとめられている。
【００４７】
電子署名は、データＭが存在するとき、Ｍの作成者が自分の秘密鍵Ｓ_ｋを用いて計算したデータＳＧ（Ｍ）＝Ｄ（Ｓ_ｋ，ｈ（Ｍ））である。データＭを送る際に、電子署名と組み合わせて（Ｍ，ＳＧ（Ｍ））という形式で送ると、受け取り側では、受信したデータＭに一方向性関数を適用して、ｈ（Ｍ）＝Ｅ（Ｐ_ｋ，ＳＧ（Ｍ））が満たされるかどうかを確認することによって、Ｍが改竄されていないこと、及びＳＧ（Ｍ）が秘密鍵Ｓ_ｋの所有者によって付加されたことを確認することができる。このような手続のことを電子署名の検証と呼ぶ。電子署名についても、例えばＩＥＥＥ−Ｐ１３６３に標準的手法がまとめられている。
【００４８】
Ｂ．第１の実施形態
Ｂ−１．全体構成
図１には、本発明の第１の実施形態に係るシステムの参加者を示している。同図に示すように、参加者は、コンテンツ提供者３０、システム管理者２０、及び再生装置４０からなる。なお、コンテンツ提供者と再生装置は複数存在してもよい。
【００４９】
再生装置４０は、システム管理者２０から、当該システムを利用するユーザに配布されているものとする。
【００５０】
コンテンツ提供者３０は、コンテンツ（例えば、音楽又は画像データや電子文書、ソフトウェアなど）をユーザへ提供するために、システム管理者２０と契約を結び、各ユーザの再生装置４０にコンテンツを提供する。
【００５１】
Ｂ−２．システム管理者
図２には、システム管理者２０の機能構成を模式的に示している。同図に示すように、システム管理者２０は、暗号処理部２１と、データ記憶部２２と、乱数発生器２３と、時計２４と、通信処理部２５とを備えている。システム管理者２０は、実際には、広域ネットワークに接続されたコンピュータ・システム上で所定のサーバ・アプリケーションを動作させることによって構成される。
【００５２】
システム管理者２０は、通信処理部２５によってコンテンツ提供者や再生装置との間で通信が可能であるとする。以下で説明するシステム管理者２０の保持するデータは、すべてデータ記憶部２２に保持される。
【００５３】
図３〜図５には、システム管理者２０において保持されているデータ構成を模式的に示している。
【００５４】
システム管理者２０は、システムに参加しているすべての再生装置４０についての再生装置固有番号、再生装置固有鍵ａ、並びに再生装置固有鍵ｂを管理する再生装置表２１１を備えている（図３を参照のこと）。この再生装置表２１１は、正当な再生装置毎の再生装置固有番号、再生装置固有鍵ａ、並びに再生装置固有鍵ｂを、表の１列（以下では１「レコード」と呼ぶ）とし、各レコードを再生装置固有番号で検索できるデータベースとして実装すればよい。
【００５５】
また、システム管理者２０は、システムに参加しているすべてのコンテンツ提供者３０のコンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂ、並びにコンテンツ提供者アドレスを管理するコンテンツ提供者表２１２を備えている（図４を参照のこと）。このコンテンツ提供者表２１２は、コンテンツ毎のコンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂ、コンテンツ提供者アドレスを１レコードで表し、各レコードをコンテンツ提供者固有番号で検索できるデータベースとして実装すればよい。
【００５６】
また、イネーブル鍵情報２１３は、現在のイネーブル鍵のバージョン番号ＩＶＥＲとイネーブル鍵Ｋ_ｒを保持する（図５を参照のこと）。
【００５７】
Ｂ−３．コンテンツ提供者
図６には、コンテンツ提供者３０の機能構成を模式的に示している。同図に示すように、コンテンツ提供者３０は、耐タンパ性暗号処理部３１と、耐タンパ性データ記憶部３２と、データ記憶部３３と、乱数発生器３４と、通信処理部３５と、時計３６とを備えている。通信処理部３５によってシステム管理者や再生装置との間で通信が可能であるとする。コンテンツ提供者３０は、実際には、広域ネットワークに接続されたコンピュータ・システム上で所定のサーバ・アプリケーションを動作させることによって構成される。
【００５８】
ここで言う「耐タンパ性」とは、外部からの観察や解析によって内部の処理やデータが取得、改竄できない性質のことである。また、耐タンパ性暗号処理部３１と耐タンパ性データ記憶部３２の間では、耐タンパ性を持った通信が可能である。
【００５９】
以下で説明するコンテンツ提供者３０の保持データのうちで、コンテンツ表はデータ記憶部３３に保持され、また、コンテンツ提供者固有情報とイネーブル鍵情報は耐タンパ性データ記憶部３２に保持される。また、イネーブル鍵を使う処理（後述のイネーブル鍵取得、及びコンテンツ・トークン生成）は、耐タンパ性暗号処理部３１で行なわれる。
【００６０】
図７〜図９には、コンテンツ提供者３０において保持されるデータ構成を模式的に示している。
【００６１】
コンテンツ提供者３０は、提供するコンテンツＣｏｎｔを管理するコンテンツ表３１１を備えている（図７を参照のこと）。コンテンツ識別番号ＣＩＤでコンテンツ鍵Ｋ_ｃであるコンテンツＣｏｎｔに対して、コンテンツ表３１１はコンテンツ識別番号ＣＩＤ、コンテンツ鍵Ｋｃ、暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）、コンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）からなるレコードを用意する。コンテンツ表３１１は、各レコードをコンテンツ識別番号ＣＩＤで検索できるデータベースとして実装すればよい。
【００６２】
上述の例では、コンテンツ識別番号ＣＩＤでコンテンツ鍵Ｋ_ｃであるコンテンツＣｏｎｔに対して、暗号化コンテンツとコンテンツ・トークンはそれぞれ、Ｅ（Ｋ_ｃ，Ｃｏｎｔ）とＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）とした。但し、コンテンツ識別番号は暗号化コンテンツ又はコンテンツ・トークンから再生装置４０で取得できる形式であればよいので、例えば暗号化コンテンツとコンテンツ・トークンがＥ（Ｋ_ｃ，Ｃｏｎｔ｜｜ＣＩＤ）とＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ）という形式であっても構わない。後者の形式を扱う場合、以下で説明する実施例に必要な変更は自明であるので、その説明は省略する。また、コンテンツを暗号化するだけでなく、改変を防ぐためにメッセージ認証コード（前述）を付加することも考えられるが、その場合も必要な変更は自明であるので説明は省略する。
【００６３】
コンテンツ提供者固有情報３１２は、コンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂで構成される（図８を参照のこと）。これらは、コンテンツ提供者３０がシステムの使用の契約を結ぶときにシステム管理者２０が決めたもので、同じデータにコンテンツ提供者３０のアドレスを追加したレコードがシステム管理者２０のコンテンツ提供者表２１２にも登録される。
【００６４】
イネーブル鍵情報３１３は、現在のイネーブル鍵のバージョン番号ＩＶＥＲとイネーブル鍵Ｋ_ｒを保持し（図９を参照のこと）、これらは、イネーブル鍵取得の手続きでシステム管理者から取得する（後述）。
【００６５】
Ｂ−４．再生装置
図１０には、再生装置４０の機能構成を模式的に示している。同図に示すように、再生装置４０は、暗号処理部４１と、データ記憶部４２と、乱数発生器４３と、通信処理部４４と、時計４５とを備えている。再生装置４０は、全体が耐タンパ性を持つ。通信処理部４４によってシステム管理者やコンテンツ提供者との間で通信が可能であるとする。再生装置４０は、実際には、広域ネットワークに接続されたコンピュータ・システム上でコンテンツ再生・アプリケーションを動作させることによって構成される。以下で説明する再生装置の保持するデータはすべてデータ記憶部４２に保持される。
【００６６】
なお、時計４５は、再生装置４０に与えられる後述のライセンス情報に、（コンテンツの）利用条件として有効期限が含まれる場合のみ必要である。したがって、利用条件として有効期限を用いない場合には、再生装置４０に時計４５が含まれることは必須ではない。また、利用条件として有効期限を使う場合であっても、有効期限を時刻として指定するのではなく、ライセンスを受けとってからの経過時間（期間）として指定する場合には、時計４５の絶対的な時刻を保持するものを使う必要はない（この場合、再生装置４０の時計４５には時刻合わせが不要である）。
【００６７】
図１１〜図１３には、再生装置４０において保持されるデータ構成を模式的に示している。再生装置４０は、再生装置固有情報４１１と、イネーブル鍵情報４１２と、ライセンス情報４１３を備えている。
【００６８】
再生装置固有情報４１１は再生装置固有番号、再生装置固有鍵ａ、再生装置固有鍵ｂを保持する（図１１を参照のこと）。これらは再生装置４０が出荷される際に入力され、システム管理者２０の再生装置表２１１にも登録される。
【００６９】
イネーブル鍵情報４１２は、現在のイネーブル鍵のバージョン番号ＩＶＥＲとイネーブル鍵Ｋ_ｒを保持し（図１２を参照のこと）、これらは、イネーブル鍵取得の手続きでシステム管理者４０から取得する（後述）。
【００７０】
ライセンス情報４１３は、コンテンツ識別番号とライセンス条件からなり（図１３を参照のこと）、コンテンツ利用の際に取得したライセンスの情報が記録される。
【００７１】
Ｂ−５．動作の概要
コンテンツ提供者３０、システム管理者２０、並びに再生装置４０からなる本発明のシステムの動作について以下で説明する。
【００７２】
システムの動作は、初期化、コンテンツ利用、イネーブル鍵更新からなる。各参加者では最初に初期化が行われてから、コンテンツ追加・削除、コンテンツ利用、イネーブル鍵更新が行われる。
【００７３】
初期化は、最初にシステム管理者２０で行われる。コンテンツ提供者３０、再生装置４０については、システムに新たに参加した際に初期化が行われる。
【００７４】
コンテンツ追加・削除は、コンテンツ提供者３０が提供するコンテンツを追加あるいは削除する際に行なう処理である。
【００７５】
コンテンツ利用は、ユーザが自分の再生装置４０にコンテンツ提供者３０からコンテンツの提供を受けて、コンテンツを利用する際の処理である。以下の説明では、コンテンツ利用の際に暗号化コンテンツ、コンテンツ・トークン、ライセンスの取得が同時に行なわれる場合について説明するが、ライセンスの取得が暗号化コンテンツ、コンテンツ・トークンの取得とは別のタイミングで行われても勿論よい。
【００７６】
また、ライセンス取得の際には、ユーザへの課金処理や、ユーザがコンテンツを利用する権利を得ていることの確認のために、ユーザの認証が行われることが一般的である。このようなユーザ認証の方法としては，例えばＫｅｒｂｅｒｏｓやＰＫＩと呼ばれる方法を使えばよい。但し、これらは本発明の要旨には直接関係しないので、ここでは説明を省略して、以降は利用権利の確認が終わったユーザの持つ再生装置４０に対して１回又は複数回のコンテンツ利用のラインセンス（＝利用許可）を与える場合について説明する。
【００７７】
イネーブル鍵更新は、システムに参加しているいずれかの再生装置４０の耐タンパ性が破られ、再生装置４０のデータ記憶部４２に保持されているデータが漏洩したときに、それらの情報を使って暗号化コンテンツを復号できなくするための処理である。すなわち、イネーブル鍵を更新して、耐タンパ性の破られていない正当な再生装置４０だけに新たなイネーブル鍵を共有させる。コンテンツ提供者３０には新たなイネーブル鍵を提供して、コンテンツを新たなコンテンツ鍵で再暗号化させ、コンテンツ・トークンも新たなコンテンツ鍵を新たなイネーブル鍵で暗号化したものに置き換えることで、耐タンパ性の破られた再生装置４０に含まれていたイネーブル鍵を使っても暗号化コンテンツを復号できなくする。
【００７８】
イネーブル鍵更新はシステム管理者と再生装置、コンテンツ提供者で行なう処理になる。
【００７９】
以下では、再生装置４０、コンテンツ提供者３０、システム管理者２０についての初期化、コンテンツ追加・削除、コンテンツ利用、イネーブル鍵更新を順に説明する。
【００８０】
Ｂ−６．初期化
システム管理者２０の初期化では、乱数発生器２３を使って新たなイネーブル鍵を生成し、イネーブル鍵バージョン番号０とイネーブル鍵をイネーブル鍵情報２１３として保持する。また、再生装置表２１１とコンテンツ提供者表２１２にレコードがない状態にする。
【００８１】
コンテンツ提供者３０は、初期化の前に、コンテンツ利用権管理システムの利用契約を結ぶ。その際、システム管理者２０との間で一意なコンテンツ提供者固有番号ＰＩＤとコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂを取り決め、これをコンテンツ提供者固有情報３１２として保持する。このときに、システム管理者２０のコンテンツ提供者表２１２にもコンテンツ提供者固有番号ＰＩＤ、コンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂ、並びにコンテンツ提供者アドレスからなる新たなレコードが追加される。以上の登録手続きが終わってから、コンテンツ提供者３０の初期化として、コンテンツ表３１１にレコードがない状態にすることと、イネーブル鍵の取得を行なう。
【００８２】
ここで、コンテンツ提供者３０がシステム管理者２０からイネーブル鍵を取得するための処理手順について、図１４を参照しながら説明する。
【００８３】
まず、コンテンツ提供者３０からシステム管理者にイネーブル鍵取得要求が送付される（ステップＳ１）。イネーブル鍵取得要求は、コンテンツ提供者固有番号ＰＩＤとコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂとした場合に、ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ｎｏｎｃｅ｜｜ＰＩＤ）で構成される。ここで、ｎｏｎｃｅはコンテンツ提供者が生成したノンス（１回限り使用される乱数）である。
【００８４】
これに対し、システム管理者２０側では、受け取ったイネーブル鍵取得要求からコンテンツ提供者固有番号ＰＩＤを使ってコンテンツ提供者表２１２を検索する。検索に成功した場合には対応するコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂを使ってイネーブル鍵取得要求が正しいこと（イネーブル鍵取得要求に含まれるメッセージ認証コードが正しいこと）を確認する。
【００８５】
イネーブル鍵取得要求の確認に成功した場合には、イネーブル・トークンＰＩＤ｜｜ｎｏｎｃｅ｜｜ＩＶＥＲ｜｜Ｅ（Ｋ_ｐａ，Ｋ_ｒ）｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＩＶＥＲ｜｜Ｅ（Ｋ_ｐａ，Ｋ_ｒ））を生成する（ステップＳ３）。
【００８６】
図１５には、この場合のイネーブル・トークンのデータ構成を示している。同図において、Ｋ_ｒはイネーブル鍵、Ｋ_ｐａ，Ｋ_ｐｂはコンテンツ提供者固有鍵、ｎｏｎｃｅはステップＳ２においてコンテンツ提供者３０から受け取ったノンスである。
【００８７】
システム管理者２０は、イネーブル・トークンをコンテンツ提供者に送付する（ステップＳ４）。これに対し、コンテンツ提供者３０側では、イネーブル・トークンが正しいこと（イネーブル・トークンに含まれるメッセージ認証コードが正しいことと、ノンスがステップＳ１で自ら送ったものと一致すること）を確認する。コンテンツ提供者３０は確認に成功した場合には、受け取ったイネーブル・トークンからイネーブル鍵Ｋ_ｒを取り出し（ステップＳ６）、イネーブル鍵情報３１３として保持する。
【００８８】
再生装置４０は出荷される際に、その再生装置固有番号ＵＩＤと再生装置固有鍵Ｋ_ｕａ，Ｋ_ｕｂが決定され、システム管理者２０に登録される。これによって、システム管理者２０の再生装置表２１１に再生装置固有番号ＵＩＤと再生装置固有鍵Ｋ_ｕａ，Ｋ_ｕｂからなる新たなレコードが追加される。再生装置４０の初期化はイネーブル鍵の取得である。再生装置４０がイネーブル鍵を取得するための処理手順について、図１４を参照しながら説明する。
【００８９】
まず、再生装置４０からシステム管理者２０にイネーブル鍵取得要求が送付される（ステップＳ１）。イネーブル鍵取得要求は、再生装置４０が再生装置固有番号ＵＩＤと再生装置固有鍵Ｋ_ｕａ，Ｋ_ｕｂを持つ場合に対して、ＵＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｕｂ，ｎｏｎｃｅ｜｜ＵＩＤ）である。ｎｏｎｃｅは、再生装置４０が生成したノンスである。
【００９０】
次いで、システム管理者２０側では、受け取ったイネーブル鍵取得要求から再生装置固有番号ＵＩＤを使って再生装置表２１１を検索する。検索に成功した場合には対応する再生装置固有鍵Ｋ_ｕａ，Ｋ_ｕｂを使ってイネーブル鍵取得要求が正しいことを確認する（ステップＳ２）。これは、イネーブル鍵取得要求に含まれるメッセージ認証コードが正しいことを確認することである。
【００９１】
イネーブル鍵取得要求の確認に成功した場合には、まずイネーブル・トークンＵＩＤ｜｜ｎｏｎｃｅ｜｜ＩＶＥＲ｜｜Ｅ（Ｋ_ｕａ，Ｋｒ）｜｜ＭＡＣ（Ｋ_ｕｂ，ＵＩＤ｜｜ｎｏｎｃｅ｜｜ＩＶＥＲ｜｜Ｅ（Ｋ_ｕａ，Ｋｒ））を生成する（ステップＳ３）。
【００９２】
図１６には、この場合のイネーブル・トークンのデータ構成を示している。ここでＩＶＥＲはイネーブル鍵のバージョン番号、Ｋ_ｒはイネーブル鍵、Ｋ_ｕａ，Ｋ_ｕｂは再生装置固有鍵、ｎｏｎｃｅはステップＳ２において再生装置４０から受け取ったノンスである。
【００９３】
次いで、システム管理者２０は、生成したイネーブル・トークンを再生装置４０に送付する（ステップＳ４）。
【００９４】
再生装置４０側では、イネーブル・トークンが正しいこと（すなわち、イネーブル・トークンに含まれるメッセージ認証コードが正しいことと、ノンスがステップＳ１で送ったものと一致すること）を確認する（ステップＳ５）。
【００９５】
確認に成功した場合、再生装置４０は受け取ったイネーブル・トークンからイネーブル鍵のバージョン番号ＩＶＥＲとイネーブル鍵Ｋ_ｒを取り出して、これらをイネーブル鍵情報４１２として保持する。
【００９６】
Ｂ−７．コンテンツ追加・削除
コンテンツ提供者３０は、提供するコンテンツの追加又は削除の際の処理を行なう。図１７には、コンテンツ提供者３０におけるコンテンツの追加又は削除時の処理動作をフローチャートの形式で示している。
【００９７】
まず、コンテンツ提供者３０は、コンテンツの追加か削除かを判断する（ステップＳ１１）。
【００９８】
コンテンツＣｏｎｔを追加する場合ならば、追加するコンテンツに対するコンテンツ鍵Ｋ_ｃを乱数発生器３４で新たに生成するとともに、コンテンツ識別番号ＣＩＤをコンテンツ提供者３０が扱うコンテンツ毎の一意な番号とコンテンツ提供者固有番号を連結したものなどとして生成する（ステップＳ１２）。
【００９９】
次いで、ステップＳ１２で生成したコンテンツ鍵Ｋ_ｃで追加コンテンツＣｏｎｔを暗号化して、暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）を得る（ステップＳ１３）。次いで、コンテンツ鍵Ｋ_ｃとイネーブル鍵情報を使ってコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）を生成する（ステップＳ１４）。
【０１００】
そして、コンテンツの識別番号ＣＩＤとコンテンツ鍵Ｋ_ｃと暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）とコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）をコンテンツ表３１１の新たなレコードとして追加して（ステップＳ１５）、本処理ルーチン全体を終了する。
【０１０１】
一方、ステップＳ１１においてコンテンツを削除すると判断した場合には、削除されるコンテンツのレコードをコンテンツ表３１１から検索し（ステップＳ１６）、そのレコードを削除して（ステップＳ１７）、本処理ルーチン全体を終了する。
【０１０２】
Ｂ−８．コンテンツ利用
コンテンツ利用は、コンテンツ提供者３０からユーザの再生装置４０にコンテンツが送られて、ユーザ側でコンテンツを利用する際の処理である。図１８には、ユーザの再生装置４０がコンテンツ提供者３０から取得したコンテンツを利用するための処理手順をフローチャートの形式で示している。
【０１０３】
まず、ユーザが自分の再生装置４０上で利用するコンテンツを選択すると（ステップＳ２１）、これに応答して、選択したコンテンツの識別番号ＣＩＤがコンテンツ提供者３０に通知される。
【０１０４】
このコンテンツ選択操作には、例えば一般的なＷｅｂブラウザなどでユーザに対してコンテンツの内容（例えばコンテンツが音楽であれば曲名など）とその利用を希望するボタンを表示させ、ユーザがボタンをマウスなどでクリックするなどのＧＵＩ操作で実装することができる。但し、こうしたユーザ・インターフェースの構成は一般的なものであり、且つ本発明の要旨には直接関連しないので、ここではこれ以上説明しない。
【０１０５】
また、このときに、選択したコンテンツの利用権利をユーザが購入する、あるいは既にユーザが権利を持つことを確認する目的で、ユーザ認証が行われることが一般的である。しかし、これについても前述の通り、本発明の要旨とは直接関連しないのでここでは説明を省略する。そこで、以降では、ユーザが利用するコンテンツを選択して、そのコンテンツに対する利用権利の確認が済んでいるものとして、本実施形態に関する説明を進める。
【０１０６】
コンテンツ提供者３０は、ユーザから利用を希望するコンテンツの識別番号の通知を受け付けると、この識別番号に対応するレコードをコンテンツ表３１１から検索する（ステップＳ２２）。そして、該当するレコードに含まれる暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）とコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）を要求元ユーザの再生装置４０に送付する（ステップＳ２３）。図１９には、コンテンツ提供装置３０から再生装置４０に送付されるコンテンツ配布形式のデータ構成を示している。
【０１０７】
再生装置４０側では、暗号化コンテンツＥ（Ｋ_ｃ１，Ｃｏｎｔ）とコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）を受け取ると、続いて、コンテンツ・トークンに含まれるイネーブル鍵のバージョン番号と自分のイネーブル鍵のバージョン番号を比較する（ステップＳ２４）。そして、コンテンツ・トークンに含まれるイネーブル鍵のバージョン番号のほうが新しい場合には、イネーブル鍵の取得を行なう（ステップＳ３１）。イネーブル鍵の取得は、再生装置４０の初期化時においてシステム管理者２０からイネーブル鍵を取得する処理として図１４を参照しながら既に説明した通りなので、ここでは説明を省略する。
【０１０８】
続いて、再生装置４０は、コンテンツ提供者３０にｎｏｎｃｅ（１回限りの乱数）を送る（ステップＳ２５）。これに対し、コンテンツ提供者３０は、ライセンス・トークンを生成する（ステップＳ２６）。ラインセンス・トークンはＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｃ，ＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ）で構成される。
【０１０９】
図２０には、ライセンス・トークンのデータ構成を示している。ここで、ＣＩＤは利用許可の対象となるコンテンツの識別番号、ＣＮＤは利用許可の条件、ｎｏｎｃｅはステップＳ２５で再生装置４０から送られたノンスである。
【０１１０】
ライセンス・トークンは、コンテンツの利用許可を与える権限者（一般的にはコンテンツ提供者３０）が生成したことを再生装置４０で確認できるデータであればよいので、メッセージ認証コードを使う代わりにＫ_ｃによる暗号化データＥ（Ｋ_ｃ，ＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ）を使うことも可能である。また、コンテンツの利用許可を与える権限者をコンテンツ提供者３０以外の第３者やシステム管理者２０とすれば、コンテンツ鍵Ｋ_ｃの代わりに、これらと再生装置４０の間であらかじめ共有している暗号鍵（例えばイネーブル鍵Ｋｒ）を使うことも可能である。
【０１１１】
ステップＳ２７では、コンテンツ提供者３０は、ライセンス・トークンを再生装置４０に送る。これに対し、再生装置４０側では、受け取ったライセンス・トークンの確認を行なう（ステップＳ２８）。すなわち、ライセンス・トークンに含まれるｎｏｎｃｅがステップＳ２５において自分が送ったものと同じであり、なお且つメッセージ認証コードが正しいかどうかを確認する。
【０１１２】
ステップＳ２８において、ライセンス・トークンが正しいことが確認できた場合には、再生装置４０はライセンス・トークンに含まれているコンテンツの識別番号ＣＩＤと利用許可の条件ＣＮＤを再生装置４０内のライセンス情報４１３として保持する。
【０１１３】
次いで、再生装置４０は、ライセンス情報４１３のコンテンツ識別番号ＣＩＤがライセンス情報記憶領域に保持されているコンテンツの識別番号ＣＩＤと一致することを確認し、さらに利用許可条件ＣＮＤが満足されることを確認する（ステップＳ２９）。
【０１１４】
ここで、利用条件ＣＮＤは、例えば利用可能回数や有効期限である。利用可能回数であれば確認の度に１ずつ減算して０より大きい限りは条件が満たされるとする。また有効期限であれば再生装置４０内の時計４５が計時する実時刻と比較して条件が満たされることを判断する。但し、前述したように、利用条件ＣＮＤとして有効期限を使わない場合には、再生装置４０に時計４５は不要である。また、有効期限を使う場合であっても、有効期限を時刻で指定するのではなく、ライセンスを受け取ってからの経過時間（期間）で指定する場合には、時計４５として絶対的な時刻を保持するものを使う必要はない。
【０１１５】
ステップＳ２９において利用条件が満たされると判断した場合には、再生装置４０は、コンテンツ鍵Ｋ_ｃを使って暗号化コンテンツを復号して得たコンテンツをユーザの利用に供する（ステップＳ３０）。そして、コンテンツの利用が終わったらステップＳ２９の条件判断に戻り、条件が満足される限りコンテンツ利用を繰り返すことができる。
【０１１６】
Ｂ−９．イネーブル鍵更新
イネーブル鍵更新は、システムに参加しているいずれかの再生装置４０においてその耐タンパ性が破られたときに、イネーブル鍵を更新する処理のことである。イネーブル鍵を更新した後、コンテンツ提供者３０の保持するコンテンツの暗号化を新たなコンテンツ鍵で行ない、新たなコンテンツ鍵を含むコンテンツ・トークンの暗号化も新たなイネーブル鍵で行なう。この結果、耐タンパ性の破られた再生装置４０に含まれる情報を使ってコンテンツを再生することを不可能にすることができる。
【０１１７】
このようなイネーブル鍵の更新に伴うコンテンツの利用制限を実現するために、耐タンパ性の破られていない正当な再生装置４０には新たなイネーブル鍵を共有させる必要がある。このため、イネーブル鍵更新の処理は大きく２つの部分に分かれる。第１は、耐タンパ性が破られた以外の正当な再生装置４０に新たなイネーブル鍵を共有させることである。第２は、コンテンツ提供者３０がコンテンツ表３１１中のすべてのレコードについてコンテンツ鍵を更新して、暗号化コンテンツを新たなコンテンツ鍵で暗号化しなおしたものに置き換え、さらにコンテンツ・トークンを新たなイネーブル鍵を使って新たなコンテンツ鍵を含むように生成し直したものに置き換えることである。
【０１１８】
上述の第２の処理を行ない、イネーブル鍵のバージョンが更新されれば、再生装置４０でコンテンツを利用する際に、イネーブル鍵のバージョンの検査（ステップＳ３１：上述）で再生装置４０の保持するイネーブル鍵が古いことが分かるので、システム管理者２０から新規のイネーブル鍵の取得が行われる。したがって、本実施形態においては、イネーブル鍵更新としては第２の処理だけを行なえばよい。
【０１１９】
図２１には、システム管理者２０においてイネーブル鍵を更新する処理手順をフローチャートの形式で示している。
【０１２０】
耐タンパ性の破られた装置を発見したとき、システム管理者２０は、まず乱数発生器２３を使って新たなイネーブル鍵Ｋ_ｒ’を生成し（ステップＳ４１）、システム管理者２０のイネーブル鍵情報２１３のイネーブル鍵を更新し、イネーブル鍵バージョン番号を１つ増加させる。
【０１２１】
次いで、コンテンツ提供者表２１２の最初のレコードを選択して（ステップＳ４２）、該選択されたレコードのコンテンツ提供者アドレスにイネーブル鍵更新通知を送る（ステップＳ４３）。
【０１２２】
イネーブル鍵更新通知は、新規のイネーブル鍵をＫ_ｒ’としてＰＩＤ｜｜ｔｉｍｅ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，ＩＶＥＲ’｜｜Ｋ_ｒ’）｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｔｉｍｅ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，ＩＶＥＲ’｜｜Ｋ_ｒ’））で構成される。ここで、ＰＩＤはこのイネーブル鍵更新通知を受け取るべきコンテンツ提供者のコンテンツ提供者固有番号、ｔｉｍｅはイネーブル鍵更新通知の生成時刻、ｎｏｎｃｅはシステム管理者の生成したノンス、Ｋ_ｐａとＫ_ｐｂはコンテンツ提供者固有鍵、ＩＶＥＲ’とＫ_ｒ’は新たなイネーブル鍵のバージョン番号とイネーブル鍵である。
【０１２３】
コンテンツ提供者３０側では、イネーブル鍵更新通知を受け取ると、それが正しいことを確認する（ステップＳ４４）。ここでは、イネーブル鍵更新通知に含まれるコンテンツ提供者固有番号が自分のものであること、時刻ｔｉｍｅが現時刻から適当な基準の範囲内（例えば１分など）であること、並びにメッセージ認証コードが正しいことが確認される。
【０１２４】
イネーブル鍵更新通知の正しいことが確認できた場合には、コンテンツ提供者３０は、イネーブル鍵情報３１３を新たなイネーブル鍵のバージョン番号ＩＶＥＲ’とイネーブル鍵Ｋ_ｒ’に置き換える。また、イネーブル鍵更新通知ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ）を生成して、システム管理者２０に送信する（ステップＳ４５）。ここで、ＰＩＤはコンテンツ提供者のコンテンツ提供者固有番号、ｎｏｎｃｅはステップＳ４４で受け取ったノンスである。
【０１２５】
次いで、コンテンツ提供者３０は、コンテンツ表３１１の更新を行なう（ステップＳ４６）。図２２には、コンテンツ表３１１を更新するための処理手順をフローチャートの形式で示している。
【０１２６】
コンテンツ提供者３０は、まず、コンテンツ表３１１の最初のレコードを選択する（ステップＳ５１）。
【０１２７】
次いで、選択したレコード向けに乱数発生器３４でコンテンツ鍵Ｋ_ｃ’を再生成する（ステップＳ５２）。そして、選択したレコードの暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）をレコードに含まれるコンテンツ鍵Ｋｃで復号してから、新しいコンテンツ鍵Ｋ_ｃ’で再暗号化してＥ（Ｋ_ｃ’，Ｃｏｎｔ）を得る（ステップＳ５３）。
【０１２８】
次いで、新しいコンテンツ鍵Ｋ_ｃ’に対するコンテンツ・トークンＩＶＥＲ’｜｜Ｅ（Ｋ_ｒ’，Ｋ_ｃ’）を生成して（ステップＳ５４）、新たなコンテンツ鍵Ｋ_ｃ’、暗号化コンテンツＥ（Ｋ_ｃ’，Ｃｏｎｔ）、コンテンツ・トークンＩＶＥＲ’｜｜Ｅ（Ｋ_ｒ’，Ｋ_ｃ’）で現レコードを更新する（ステップＳ５５）。
【０１２９】
次いで、現レコードがコンテンツ表３１１の最後のレコードかどうかを確かめ（ステップＳ５６）、そうであれば本処理全体を終了し、そうでなければコンテンツ表３１１の次のレコードを現レコードとして選択してから（ステップＳ５７）、ステップＳ５２に戻り、次のレコードについて更新処理を繰り返し行なう。
【０１３０】
再び図２１に戻って、イネーブル鍵の更新処理について説明する。システム管理者２０は、イネーブル鍵更新通知ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ）を受け取ると（ステップＳ４７）、ＰＩＤ並びにｎｏｎｃｅがステップＳ４３において自分で送ったものであり、且つメッセージ認証コードが正しいかどうかを判断する。
【０１３１】
判断結果が肯定的である場合には、現レコードがコンテンツ提供者表２１２の最後のレコードであるかどうかを確認する（ステップＳ４８）。最後のレコードであれば本処理ルーチン全体を終了し、そうでなければコンテンツ提供者表２１２の次のレコードを現レコードとして選択してから（ステップＳ４９）、ステップＳ４３に戻り、次のレコードについてイネーブル鍵の更新処理を繰り返し行なう。
【０１３２】
また、ステップＳ４７で、適当な時間だけ待つなどの基準で、イネーブル鍵更新通知を受け取ることができない場合には、ステップＳ４３に戻って、イネーブル更新通知を再送付する。
【０１３３】
Ｃ．第２の実施形態
Ｃ−１．全体構成
本発明の第２の実施形態においても、図１に示すように、参加者は、コンテンツ提供者３０と、システム管理者２０と、再生装置４０で構成される。なお、コンテンツ提供者３０と再生装置２０は複数存在していてもよい。再生装置４０はシステム管理者２０から、本発明のシステムを利用するユーザに配布されているとする。また、コンテンツ提供者３０は、コンテンツ（例えば、音楽又は画像データや電子文書、ソフトウェアなど）をユーザへ提供するために、システム管理者２０と契約を結び、ユーザの再生装置４０にコンテンツを提供する。
【０１３４】
Ｃ−２．システム管理者
システム管理者２０の構成は、上述した第１の実施形態のそれと略同一なので、ここでは説明を省略する。なお、システム管理者２０の保持するデータはすべてデータ記憶部２２に保持されている。
【０１３５】
図２３〜図２５には、システム管理者２０において保持されるデータ構成を模式的に示している。
【０１３６】
システム管理者２０は、システムに参加しているすべての再生装置の再生装置固有番号、排除フラグ、再生装置固有鍵セットを管理する再生装置表２２１（図２３を参照のこと）を備えている。この再生装置表２２１は、正当な再生装置４０についての再生装置固有番号、排除フラグ、再生装置固有鍵セット（後述）を、表のレコードとして各レコードを再生装置固有番号で検索できるデータベースとして実装すればよい。
【０１３７】
また、システム管理者２０はシステムに参加しているすべてのコンテンツ提供者３０のコンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂ、コンテンツ提供者アドレスを管理するコンテンツ提供者表２２２（図２４を参照のこと）を備えている。コンテンツ提供者表２２１は、コンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂ、コンテンツ提供者アドレスを１レコードで表し、各レコードをコンテンツ提供者固有番号で検索できるデータベースとして実装すればよい。
【０１３８】
イネーブル鍵情報２２３は、現在のコンテンツ提供者３０とイネーブル鍵ブロックを保持する（図２５を参照のこと）。
【０１３９】
Ｃ−３．コンテンツ提供者
コンテンツ提供者３０の構成は、上述した第１の実施形態のそれと略同一なので、ここでは説明を省略する。なお、コンテンツ提供者３０が保持するデータのうちで、コンテンツ表はデータ記憶部３３に保持され、コンテンツ提供者固有情報とイネーブル鍵情報は耐タンパ性データ記憶部３２に保持される。また、イネーブル鍵を使う処理（後述のイネーブル鍵取得、及びコンテンツ・トークン生成）は、耐タンパ性暗号処理部３１で行なわれる。
【０１４０】
図２６〜図２８には、コンテンツ提供者３０において保持されるデータ構成を模式的に示している。
【０１４１】
コンテンツ提供者３０は、提供するコンテンツを管理するコンテンツ表３２１（図２６を参照のこと）を備えている。コンテンツ表３２１は、コンテンツ毎の一つのレコードが設けられ、各レコードは、コンテンツ識別番号ＣＩＤ、コンテンツ鍵Ｋ_ｃ、コンテンツ鍵Ｋ_ｃでコンテンツＣｏｎｔを暗号化してなる暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）、コンテンツ・トークンＥ（Ｋ_ｒ（ｔ），Ｋ_ｃ｜｜ＣＩＤ）で構成される。コンテンツ表３２１は、各レコードをコンテンツ識別番号ＣＩＤで検索できるデータベースとして実装すればよい。なお、コンテンツ識別番号ＣＩＤは暗号化コンテンツあるいはコンテンツ・トークンから再生装置で取得できる形式であればよく、他の形式で実現してもよい（同上）。
【０１４２】
コンテンツ提供者固有情報３２２は、コンテンツ提供者固有番号、コンテンツ提供者固有鍵ａ、コンテンツ提供者固有鍵ｂで構成され（図２７を参照のこと）、これらはコンテンツ提供者３０がシステムの使用の契約を結ぶときにシステム管理者が決めたものであり、同じデータにコンテンツ提供者のアドレスを追加したレコードがシステム管理者２０のコンテンツ提供者表２２２にも登録される。
【０１４３】
イネーブル鍵情報３２３は、現在のイネーブル鍵とイネーブル鍵ブロックを保持し（図２８を参照のこと）、これらは、イネーブル鍵取得の手続きでシステム管理者２０から取得する（後述）。
【０１４４】
Ｃ−４．再生装置
再生装置４０の構成は、上述した第１の実施形態のそれと略同一なので、ここでは説明を省略する。再生装置４０は耐タンパ性を持ち、以下のデータはすべてデータ記憶部４２に保持される。
【０１４５】
図２９〜図３０には、再生装置４０において保持されるデータ構成を模式的に示している。
【０１４６】
再生装置４０は、再生装置固有情報４２１とライセンス情報４２３を備えている。再生装置固有情報４２１は、再生装置固有番号、再生装置固有鍵セット（後述）を保持する（図２９を参照のこと）。これらは再生装置４０が出荷される際に入力され、同時にシステム管理者の再生装置表２２１にも登録される。
【０１４７】
ライセンス情報４２３は、コンテンツ識別番号とライセンス条件からなり（図３０を参照のこと）、コンテンツ利用の際に取得したライセンスの情報が記録される。
【０１４８】
Ｃ−５．再生装置固有鍵セット、イネーブル鍵ブロック
本実施形態では、すべての再生装置４０は仮想的なツリー構造に属する。図３１にはこの仮想的なツリー構造の例を示している。ツリー構造の最下段を「リーフ」と呼ぶ。各再生装置は１つのリーフに対応する。また、ツリー構造の途中の分岐点を「ノード」と呼ぶ。最上層の唯一のノードを「ルート」と呼ぶ。リーフとノードには暗号鍵が割り振られる。この暗号鍵は乱数を基に生成される。
【０１４９】
なお、図３１には対称な４段のツリー構造でリーフが１６個の場合を示したが、より多くのリーフを持ち段数の大きい場合や、対称でないツリー構造の場合、あるいは分岐の数が２個以上の場合を考えることもできる。こうした一般化については、例えばＲＦＣ２６２７を参照されたい。
【０１５０】
各再生装置４０の再生装置固有鍵セットは、対応するリーフの鍵、及び対応するリーフからルートまでのノードに割り振られている鍵であるとする。例えば、図３１中でリーフ１に対応する再生装置の再生装置固有鍵セットは｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝である。したがって、再生装置の耐タンパ性が完全であれば、Ｋ_ｒｏｏｔがすべての再生装置で共有されていることになる。そこで、イネーブル鍵Ｋ_ｒに対して、イネーブル鍵ブロックは｛（”ｒｏｏｔ”，Ｅ（Ｋ_ｒｏｏｔ，Ｋ_ｒ））｝という集合とすればよい。但し、｛ａ，（ｂ，ｃ）｝は要素ａと（ｃ，ｄ）からなる集合を表し、（ｃ，ｄ）は要素ｃとｄの順序付きの集合を表す。また、”ｒｏｏｔ”は、ｒｏｏｔという文字列、あるいはｒｏｏｔを識別できる記号であるとし、（”ｒｏｏｔ”，Ｅ（Ｋ_ｒｏｏｔ，Ｋ_ｒ））は、”ｒｏｏｔ”に続く要素がルートのノードの鍵Ｋ_ｒｏｏｔで暗号化されていることを示す。
【０１５１】
次に、あるリーフに対応する再生装置の耐タンパ性が破られた場合を考えると、その再生装置の持つ再生装置固有鍵セットが漏洩しているので、Ｋ_ｒｏｏｔはもはや正当な再生装置だけに共有されているとは言えない。しかしながら、耐タンパ性の破られた再生装置を特定することができれば、その再生装置固有鍵セットは分かるので、適当なイネーブル鍵ブロックを使って、耐タンパ性の破られていない再生装置だけに新たに共通のイネーブル鍵を取得させることができる。
【０１５２】
例として、図３１中のリーフ１に対応する再生装置の耐タンパ性が破られたと仮定する。この場合、｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝の鍵が漏洩していることになる。したがって、新しいイネーブル鍵Ｋ_ｒ’を｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝に含まれない鍵を使って暗号化して各再生装置に配布すればよい。
【０１５３】
また、図３１中のリーフ８からリーフ１５に対応する再生装置は、｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝に含まれない鍵Ｋ_１を共有しているので、Ｅ（Ｋ_１，Ｋ_ｒ’）として配布すればよい。
【０１５４】
同様に、リーフ４からリーフ７に対応する再生装置は｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝に含まれない鍵Ｋ_０１を共有しているので、Ｅ（Ｋ_０１，Ｋ_ｒ’）として配布すればよい。
【０１５５】
リーフ２とリーフ３に対応する再生装置は｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝に含まれない鍵Ｋ_００１を共有しているので、Ｅ（Ｋ_００１，Ｋ_ｒ’）として配布すればよい。
【０１５６】
最後に、リーフ０は｛Ｋ_０００１，Ｋ_０００，Ｋ_００，Ｋ_０，Ｋ_ｒｏｏｔ｝に含まれない鍵Ｋ_００００を持つので、Ｅ（Ｋ_００００，Ｋ_ｒ’）として配布すればよい。
【０１５７】
このことから、イネーブル鍵ブロックは｛（”１”，Ｅ（Ｋ_１，Ｋ_ｒ’）），（”０１”，Ｅ（Ｋ_０１，Ｋ_ｒ’）），（”００１”，Ｅ（Ｋ_００１，Ｋ_ｒ’）），（”００００”，Ｅ（Ｋ_００００，Ｋ_ｒ’））｝とすればよい。図３２にはイネーブル鍵ブロック（ＥＢＬＫ）のデータ構成を模式的に示している。
【０１５８】
排除すべき再生装置が複数になった場合にも、上述と同様にイネーブル鍵ブロックを生成することができる。一般に、深さがｄで各ノードでの分岐がｋ本のツリー構造を使った場合、ｍ個の再生装置を排除したイネーブル鍵の共有に必要なイネーブル鍵ブロックの要素数は、高々（ｋ−１）×ｄ×ｍである（ＲＦＣ２６２７を参照のこと）。ツリー構造をできるだけ対称性よく構成することにより、深さｄは再生装置の個数Ｎのｋを底とする対数程度なので、Ｎに比べて非常に小さく、イネーブル鍵ブロックのデータサイズも小さくすることが可能である。イネーブル鍵ブロックを効率的に生成するデータ構造については、本出願人に既に譲渡されている特開２００１−３５２３２１号公報（発明の名称：情報システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体）に開示されている。
【０１５９】
Ｃ−６．動作の概要
コンテンツ提供者３０、システム管理者２０、並びに再生装置４０からなる本実施形態に係るシステムの動作について以下で説明する。システムの動作は、初期化、コンテンツ利用、イネーブル鍵更新で構成される。システムの各参加者では、最初に初期化が行なわれてから、コンテンツ追加・削除、コンテンツ利用、イネーブル鍵更新が行なわれる。
【０１６０】
初期化は、最初にシステム管理者２０で行なわれる。コンテンツ提供者３０、再生装置４０については、システムに新たに参加した際に初期化が行なわれる。
【０１６１】
コンテンツ追加・削除は、コンテンツ提供者３０が提供するコンテンツを追加あるいは削除する際に行なう処理である。
【０１６２】
コンテンツ利用は、ユーザが自分の再生装置４０にコンテンツ提供者側からコンテンツの提供を受けて、コンテンツを利用する際に行なう処理である。以下では、コンテンツの利用を求めてきた再生装置４０に対して１回又は複数回のコンテンツ利用のライセンス（＝利用許可）を与える場合について説明する。但し、コンテンツ利用の際に暗号化コンテンツ、コンテンツ・トークン、ライセンスの取得が同時に行なわれる場合を想定するが、ライセンスの取得が暗号化コンテンツ、コンテンツ・トークンの取得とは別のタイミングで行われてもよい。また、ライセンス取得の際には、課金処理あるいはコンテンツ利用権利の確認のためにユーザの認証が行われることが一般的であるが、本発明の要旨には直接関連しないので、ここでは説明を省略する。
【０１６３】
イネーブル鍵更新は、システムに参加しているいずれかの再生装置４０の耐タンパ性が破られ、再生装置４０内のデータ記憶部４２に保持されているデータ（再生装置固有鍵セット）が漏洩したときに、それらの情報を使っても暗号化コンテンツを復号できなくするための処理である。この場合、システム管理者２０はイネーブル鍵を更新するとともに、新たなイネーブル鍵ブロックを生成して、耐タンパ性の破られていない正当な再生装置だけが更新されたイネーブル鍵を取得できるようにする。また、コンテンツ提供者３０にはシステム管理者２０から新たなイネーブル鍵とイネーブル鍵ブロックが提供され、コンテンツを新たなコンテンツ鍵で再暗号化し、コンテンツ・トークンも新たなイネーブル鍵で生成し直すことで、耐タンパ性の破られた再生装置に含まれていたデータを使っても暗号化コンテンツを復号できなくする。イネーブル鍵更新はシステム管理者２０、及びコンテンツ提供者３０で行なう処理となる。
【０１６４】
以下では、再生装置４０、コンテンツ提供者３０、システム管理者２０の初期化、コンテンツ追加・削除、コンテンツ利用、イネーブル鍵更新という順で説明する。
【０１６５】
Ｃ−７．初期化
システム管理者２０の初期化では、乱数発生器２３を使ってイネーブル鍵Ｋ_ｒを生成する。この時点では不正者排除は必要ないので、イネーブル鍵ブロックは｛（”ｒｏｏｔ”，Ｅ（Ｋ_ｒｏｏｔ，Ｋ_ｒ））｝とし、イネーブル鍵とイネーブル鍵ブロックをイネーブル鍵情報２１３として保持する。また、再生装置表２２１並びにコンテンツ提供者表２２２をレコードがない状態にする。
【０１６６】
コンテンツ提供者３０は、初期化の前に、コンテンツ利用権管理システムの利用契約を結ぶ。その際、システム管理者２０との間で一意なコンテンツ提供者固有番号ＰＩＤとコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂを取り決め、これをコンテンツ提供者固有情報３１２にとして保持する。このとき、システム管理者２０のコンテンツ提供者表２２２にもコンテンツ提供者固有番号ＰＩＤ、コンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂ、コンテンツ提供者アドレスからなる新たなレコードが追加される。この手続きはオフラインで行なわれることが好ましい。以上の登録手続きが終わってから、コンテンツ提供者３０の初期化では、コンテンツ表３２１にレコードがない状態にし、イネーブル鍵とイネーブル鍵ブロックの取得を行なう。
【０１６７】
本実施形態に係るシステムにおいて、コンテンツ提供者３０がイネーブル鍵とイネーブル鍵ブロックを取得する処理は、図１４でフローチャートの形式で示した処理手続きに従う。
【０１６８】
まず、コンテンツ提供者３０からシステム管理者２０にイネーブル鍵取得要求が送付される（ステップＳ１）。イネーブル鍵取得要求は、コンテンツ提供者固有番号ＰＩＤとコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂに対して、ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ｎｏｎｃｅ｜｜ＰＩＤ）で構成される。ｎｏｎｃｅはコンテンツ提供者３０が生成したノンス（１回限り使用される乱数）である。
【０１６９】
システム管理者２０側では、受け取ったイネーブル鍵取得要求からコンテンツ提供者固有番号ＰＩＤを使ってコンテンツ提供者表２２２を検索する。そして、検索に成功した場合には対応するコンテンツ提供者固有鍵Ｋ_ｐａ，Ｋ_ｐｂを使ってイネーブル鍵取得要求が正しいこと（イネーブル鍵取得要求に含まれるメッセージ認証コードが正しいこと）を確認する（ステップＳ２）。
【０１７０】
イネーブル鍵取得要求の確認に成功した場合には、システム管理者２０はイネーブル・トークンＰＩＤ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，Ｋ_ｒ）｜｜ＥＢＬＫ｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，Ｋ_ｒ）｜｜ＥＢＬＫ）を生成する。図３３にはイネーブル・トークンのデータ構成を模式的に示している。ここでＫ_ｒはイネーブル鍵、Ｋ_ｐａ，Ｋ_ｐｂはコンテンツ提供者固有鍵、ｎｏｎｃｅはステップＳ２においてコンテンツ提供者から受け取ったノンス、ＥＢＬＫはイネーブル鍵ブロックである。
【０１７１】
システム管理者２０は、生成したイネーブル・トークンをコンテンツ提供者４０に送付する。これに対し、コンテンツ提供者３０は、イネーブル・トークンが正しいこと、すなわちイネーブル・トークンに含まれるメッセージ認証コードが正しいことと、ノンスがステップＳ１で送ったものと一致することを確認する（ステップＳ５）。
【０１７２】
そして、コンテンツ提供者は確認に成功した場合には、イネーブル・トークンからイネーブル鍵Ｋ_ｒとイネーブル鍵ブロックＥＢＬＫを取り出して（ステップＳ６）、イネーブル鍵情報３２３として保持する。
【０１７３】
再生装置４０は、出荷される際に、再生装置固有番号ＵＩＤと再生装置固有鍵セット｛Ｋ_ｒｏｏｔ，Ｋ_ｘ，Ｋ_ｘｘ，Ｋ_ｘｘｘ，．．．｝が決定されシステム管理者２０に登録される。これによってシステム管理者２０の再生装置表２２１には再生装置固有番号ＵＩＤと排除フラグの値ＯＦＦ、再生装置固有鍵セット｛Ｋ_ｒｏｏｔ，Ｋ_ｘ，Ｋ_ｘｘ，Ｋ_ｘｘｘ，．．．｝からなる新たなレコードが追加される。
【０１７４】
Ｃ−８．コンテンツ追加・削除
コンテンツ提供者が提供するコンテンツの追加あるいは削除の際の処理について説明する。図１７には、コンテンツ提供者３０におけるコンテンツの追加又は削除時の処理動作をフローチャートの形式で示している。
【０１７５】
まず、コンテンツ提供者３０は、コンテンツの追加か削除かを判断する（ステップＳ１１）。
【０１７６】
コンテンツＣｏｎｔを追加する場合ならば、追加するコンテンツに対するコンテンツ鍵Ｋ_ｃを乱数発生器３４で新たに生成するとともに、コンテンツ識別番号ＣＩＤをコンテンツ提供者３０が扱うコンテンツ毎の一意な番号とコンテンツ提供者固有番号を連結したものなどとして生成する（ステップＳ１２）。
【０１７７】
次いで、ステップＳ１２で生成したコンテンツ鍵Ｋ_ｃで追加コンテンツＣｏｎｔを暗号化して、暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）を得る（ステップＳ１３）。次いで、コンテンツ鍵Ｋ_ｃとイネーブル鍵情報を使ってコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）を生成する（ステップＳ１４）。
【０１７８】
そして、コンテンツの識別番号ＣＩＤとコンテンツ鍵Ｋ_ｃと暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）とコンテンツ・トークンＩＶＥＲ｜｜Ｅ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）をコンテンツ表３２１の新たなレコードとして追加して（ステップＳ１５）、本処理ルーチン全体を終了する。
【０１７９】
一方、ステップＳ１１においてコンテンツを削除する場合と判断した場合には、削除されるコンテンツのレコードをコンテンツ表３２１から検索し（ステップＳ１６）、そのレコードを削除して（ステップＳ１７）、本処理ルーチン全体を終了する。
【０１８０】
Ｃ−９．コンテンツ利用
コンテンツ利用は、コンテンツ提供者３０からユーザの再生装置４０にコンテンツが送られて、ユーザ側でコンテンツを利用する際の処理である。図３４には、ユーザの再生装置４０がコンテンツ提供者３０から取得したコンテンツを利用するための処理手順をフローチャートの形式で示している。
【０１８１】
まず、ユーザが自分の再生装置４０上で利用するコンテンツを選択すると（ステップＳ６１）、これに応答して、選択したコンテンツの識別番号ＣＩＤがコンテンツ提供者３０に通知される。
【０１８２】
このコンテンツ選択操作には、例えば一般的なＷｅｂブラウザなどでユーザに対してコンテンツの内容（例えばコンテンツが音楽であれば曲名など）とその利用を希望するボタンを表示させ、ユーザがボタンをマウスなどでクリックするなどのＧＵＩ操作で実装することができる。但し、こうしたユーザ・インターフェースの構成は一般的なものであり、且つ本発明の要旨には直接関連しないので、ここではこれ以上説明しない。
【０１８３】
また、このときに、選択したコンテンツの利用権利をユーザが購入する、あるいは既にユーザが権利を持つことを確認する目的で、ユーザ認証が行われることが一般的である。しかし、これについても前述したように、本発明の要旨とは直接関係しないので、ここでは説明を省略する。そこで、以降では、ユーザが利用するこんてんつを選択して、そのコンテンツに対する利用権利の確認が済んでいるものとして本実施形態の説明を進める。
【０１８４】
コンテンツ提供者３０は、でユーザから利用を希望するコンテンツの識別番号の通知を受け付けると、この識別番号に対応するレコードをコンテンツ表３２１から検索する（ステップＳ６２）。そして、レコードに含まれる暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）とコンテンツ・トークンＥ（Ｋ_ｒ，Ｋ_ｃ｜｜ＣＩＤ）、及びイネーブル鍵情報３２３のイネーブル鍵ブロックＥＢＬＫを要求元ユーザの再生装置４０に送付する（ステップＳ６３）。図３５には、このとき送付されるコンテンツ配布形式のデータ構成を模式的に示す。
【０１８５】
再生装置４０は、暗号化コンテンツＥ（Ｋ_ｃ１，Ｃｏｎｔ）、コンテンツ・トークンＥ（Ｋ_ｒ，　Ｋ_ｃ｜｜ＣＩＤ）、並びにイネーブル鍵ブロックＥＢＬＫの組を受け取ると、続いて、イネーブル鍵ブロックＥＢＬＫからイネーブル鍵を取得する（ステップＳ６４）。
【０１８６】
一方、イネーブル鍵の取得に失敗した（すなわち、イネーブル鍵を暗号化している鍵が自分の持つ再生装置固有鍵セットに含まれない）場合には、コンテンツ利用は失敗して、本処理ルーチン全体を終了する。
【０１８７】
再生装置４０は、イネーブル鍵を取得すると、コンテンツ提供者３０にｎｏｎｃｅ（１回限りの乱数）を送付する（ステップＳ６５）。これに対し、コンテンツ提供者３０は、ライセンス・トークンを生成する（ステップＳ６６）。そして、コンテンツ提供者３０は、生成したライセンス・トークンを再生装置４０に送付する（ステップＳ６７）。
【０１８８】
図３６には、ライセンス・トークンのデータ構成を模式的に示している。ラインセンス・トークンはＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｃ，ＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ）で構成される。ＣＩＤは利用許可の対象となるコンテンツの識別番号、ＣＮＤは利用許可の条件、ｎｏｎｃｅはステップＳ６５において再生装置４０から送られたノンスである。
【０１８９】
ライセンス・トークンは、コンテンツの利用許可を与える権限者（一般的には、コンテンツ提供者３０）が生成したことを再生装置４０で確認できるデータであればよい。したがって、上述のようにメッセージ認証コードを使う代わりに、コンテンツ鍵Ｋ_ｃによる暗号化データＥ（Ｋ_ｃ，ＣＩＤ｜｜ＣＮＤ｜｜ｎｏｎｃｅ）を使うことも可能である。また、コンテンツの利用許可を与える権限者をコンテンツ提供者３０以外の第３者やシステム管理者２０とすれば、コンテンツ鍵Ｋ_ｃの代わりに、これらと再生装置４０の間で共通に利用できる暗号鍵（例えばイネーブル鍵Ｋ_ｒ）を使うことも可能である。
【０１９０】
次いで、再生装置４０側では、コンテンツ提供者３０から受け取ったライセンス・トークンの確認を行なう（ステップＳ６８）。すなわち、ライセンス・トークンに含まれるｎｏｎｃｅがステップＳ６５で送ったものと同じであり、なお且つメッセージ認証コードが正しいことを確認する。そして、ライセンス・トークンが正しいことが確認できた場合には、再生装置４０は、ライセンス・トークンに含まれているコンテンツの識別番号ＣＩＤと利用許可の条件ＣＮＤを再生装置４０のライセンス情報４２３として保持する。
【０１９１】
次いで、再生装置４０は、ライセンス情報４２３のコンテンツ識別番号ＣＩＤがライセンス情報記憶領域に保持されているコンテンツの識別番号ＣＩＤと一致することを確認し（ステップＳ６８）、さらに、ライセンスの確認すなわち利用許可条件ＣＮＤが満足されることを確認する（ステップＳ６９）。ＣＮＤは例えば利用可能回数や有効期限である。ＣＮＤが利用可能回数であれば、確認の度に１ずつ減算して０より大きい限りは条件が満たされるとする。また、ＣＮＤが有効期限であれば、再生装置４０の時計４５が計時する実時刻と比較して条件が満たされることを判断する。前述した通り、利用条件ＣＮＤとして有効期限を使わない場合には、再生装置４０に時計４５は不要である。また、有効期限を使う場合であっても、有効期限を時刻で指定するのではなく、ライセンスを受け取ってからの経過時間（期間）で指定する場合には、時計４５として絶対的な時刻を保持するものを使う必要はない。
【０１９２】
ステップＳ６９においてコンテンツの利用条件が満たされると判断された場合には、再生装置４０は、コンテンツ鍵Ｋ_ｃを使って暗号化コンテンツを復号して得たコンテンツを利用する。また、コンテンツの利用が終わったら、ステップＳ６９の条件判断に戻り、コンテンツの利用条件が満足される限り、コンテンツ利用を繰り返すことができる。
【０１９３】
Ｃ−１０．イネーブル鍵更新
イネーブル鍵更新は、耐タンパ性の破られた再生装置４０に含まれる情報を使ってコンテンツを再生することを不可能にする処理である。具体的には、システムに参加しているいずれかの再生装置４０の耐タンパ性が破られたときに、イネーブル鍵を更新して、コンテンツ提供者３０の保持するコンテンツの暗号化を新たなコンテンツ鍵で行ない、新たなコンテンツ鍵を含むコンテンツ・トークンの暗号化を新たなイネーブル鍵で行なう。
【０１９４】
また、正当な再生装置４０には新たなイネーブル鍵を利用できるようにするために、耐タンパ性が破られた再生装置を除く再生装置から新たなイネーブル鍵が取得可能なイネーブル鍵ブロックを、システム管理者２０がコンテンツ提供者３０に提供し、それをコンテンツ提供者３０がコンテンツ利用時に再生装置４０に配布する。
【０１９５】
図２１には、システム管理者２０においてイネーブル鍵を更新する処理手順をフローチャートの形式で示している。
【０１９６】
システム管理者２０は、耐タンパ性の破られた再生装置を発見したとき、再生装置表２２１の該当する再生装置のレコードの排除フラグをＯＮにするとともに、乱数発生器２３を使って新たなイネーブル鍵Ｋ_ｒ’を生成し、新たなイネーブル鍵と耐タンパ性の破られた再生装置の情報（再生装置表２２１の排除フラグがＯＮであるレコードの再生装置固有鍵セット）から新たなイネーブル鍵ブロックＥＢＬＫ’を生成する（ステップＳ４１）。そして、システム管理者２０は、イネーブル鍵情報２２３のイネーブル鍵とイネーブル鍵ブロックを更新する。
【０１９７】
次いで、コンテンツ提供者表２２２の最初のレコードを選択し（ステップＳ４２）、該選択されたレコードのコンテンツ提供者アドレスにイネーブル鍵更新通知を送る（ステップＳ４３）。
【０１９８】
イネーブル鍵更新通知は新規のイネーブル鍵をＫ_ｒ’としてＰＩＤ｜｜ｔｉｍｅ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，Ｋ_ｒ’）｜｜ＥＢＬＫ’｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｔｉｍｅ｜｜ｎｏｎｃｅ｜｜Ｅ（Ｋ_ｐａ，Ｋｒ’）｜｜ＥＢＬＫ’）で構成される。ここで、ＰＩＤはこのイネーブル鍵更新通知を受け取るべきコンテンツ提供者３０のコンテンツ提供者固有番号、ｔｉｍｅはイネーブル鍵更新通知の生成時刻、ｎｏｎｃｅはシステム管理者２０の生成したノンス、Ｋ_ｐａとＫ_ｐｂはコンテンツ提供者固有鍵、Ｋ_ｒ’は新たなイネーブル鍵、ＥＢＬＫ’は新たなイネーブル鍵ブロックである。
【０１９９】
コンテンツ提供者３０は、イネーブル鍵更新通知を受け取ると、それが正しいことを確認する（ステップＳ４４）。具体的には、イネーブル鍵更新通知に含まれるコンテンツ提供者固有番号が自分のものであること、時刻ｔｉｍｅが現時刻から適当な基準の範囲内（例えば１分など）であること、並びにメッセージ認証コードが正しいことを確認する。
【０２００】
イネーブル鍵更新通知の正しいことが確認できた場合、コンテンツ提供者３０は、新たなイネーブル鍵Ｋ_ｒ’とイネーブル鍵ブロックＥＢＬＫ’を取り出して、イネーブル鍵情報３２３を更新する。また、イネーブル鍵更新通知ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ）を生成して、これをシステム管理者２０に送信する（ステップＳ４５）。ここで、ＰＩＤはコンテンツ提供者のコンテンツ提供者固有番号、ｎｏｎｃｅはステップＳ４４で受け取ったノンスである。
【０２０１】
次いで、コンテンツ提供者３０は、コンテンツ表３２１の更新を行なう（ステップＳ４６）。図２２には、コンテンツ表３２１を更新するための処理手順をフローチャートの形式で示している。
【０２０２】
コンテンツ提供者３０は、まず、コンテンツ表３１１の最初のレコードを選択する（ステップＳ５１）。
【０２０３】
次いで、選択したレコード向けに乱数発生器３４でコンテンツ鍵Ｋ_ｃ’を再生成する（ステップＳ５２）。そして、選択したレコードの暗号化コンテンツＥ（Ｋ_ｃ，Ｃｏｎｔ）をレコードに含まれるコンテンツ鍵Ｋ_ｃで復号してから、新しいコンテンツ鍵Ｋ_ｃ’で再暗号化してＥ（Ｋ_ｃ’，Ｃｏｎｔ）を得る（ステップＳ５３）。
【０２０４】
次いで、新しいコンテンツ鍵Ｋｃ’に対するコンテンツ・トークンＥ（Ｋ_ｒ’，Ｋ_ｃ’）を生成して（ステップＳ５４）、新たなコンテンツ鍵Ｋ_ｃ’、暗号化コンテンツＥ（Ｋ_ｃ’，Ｃｏｎｔ）、コンテンツ・トークンＥ（Ｋ_ｒ’，Ｋ_ｃ’）で現レコードを更新する（ステップＳ５５）。
【０２０５】
次いで、現レコードがコンテンツ表３１１の最後のレコードかどうかを確かめ（ステップＳ５６）、そうであれば本処理全体を終了し、そうでなければコンテンツ表３１１の次のレコードを現レコードとして選択してから（ステップＳ５７）、ステップＳ５２に戻り、次のレコードについて更新処理を繰り返し行なう。
【０２０６】
再び図２１に戻って、イネーブル鍵の更新処理について説明する。システム管理者２０は、イネーブル鍵更新通知ＰＩＤ｜｜ｎｏｎｃｅ｜｜ＭＡＣ（Ｋ_ｐｂ，ＰＩＤ｜｜ｎｏｎｃｅ）を受け取ると（ステップＳ４７）、ＰＩＤ並びにｎｏｎｃｅがステップＳ４３において自分で送ったものであり、且つメッセージ認証コードが正しいかどうかを判断する。
【０２０７】
判断結果が肯定的である場合には、現レコードがコンテンツ提供者表２１２の最後のレコードであるかどうかを確認する（ステップＳ４８）。最後のレコードであれば本処理ルーチン全体を終了し、そうでなければコンテンツ提供者表２１２の次のレコードを現レコードとして選択してから（ステップＳ４９）、ステップＳ４３に戻り、次のレコードについてイネーブル鍵の更新処理を繰り返し行なう。
【０２０８】
また、ステップＳ４７で、適当な時間だけ待つなどの基準で、イネーブル鍵更新通知を受け取ることができない場合には、ステップＳ４３に戻って、イネーブル更新通知を再送付する。
【０２０９】
［追補］
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２１０】
【発明の効果】
以上詳記したように、本発明によれば、コンテンツの利用者にライセンスを与えることによりコンテンツの利用を制御しコンテンツの保護を図ることができる、優れたコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【０２１１】
また、本発明によれば、コンテンツ鍵の不正利用を防止しながらコンテンツの利用者にライセンスを与えることができる、優れたコンテンツ利用管理システム、コンテンツを利用し又は提供する情報処理装置又は情報処理方法、並びにコンピュータ・プログラムを提供することができる。
【０２１２】
本発明によれば、コンテンツの利用許可が暗号化コンテンツを復号する鍵（コンテンツ鍵）ではなく、利用を許可するコンテンツの識別番号（ライセンス・トークン）を再生装置が判断できる形式でコンテンツの利用許可の権限者が指定することによりライセンスの付与を行なう。したがって、利用許可を与える先が権利保護を行なうかどうかを確認することなしに、利用許可を与えることが可能になり、利用許可を与える際の処理を高速化することができる。
【０２１３】
また、本発明によれば、正当な再生装置以外はイネーブル鍵を持たないので、コンテンツの利用許可の権限者が正当でない再生装置に利用許可を与えたとしても、その装置ではコンテンツを復号することができないので、コンテンツの利用権は保護される。
【０２１４】
また、本発明によれば、コンテンツ鍵を正当な再生装置だけが利用可能な暗号鍵（イネーブル鍵）で暗号化してコンテンツとともに配布するので、コンテンツ鍵を変更したとしても再生装置側で特別の処理を必要としない。
【０２１５】
また、本発明によれば、耐タンパ性が破られた再生装置が発生したときには、イネーブル鍵を変更し、新たなイネーブル鍵を耐タンパ性が破られていない正当な再生装置とコンテンツ提供者に配布することによって、耐タンパ性が破られた再生装置に含まれる情報を使っても、以降に配布されるコンテンツを利用することをできなくすることができる。
【０２１６】
本発明で重要な点は、ライセンスがコンテンツ鍵でないため、任意の装置にライセンスを与えても、実際にコンテンツを復号できるのは、あらかじめイネーブル鍵を共有している正当な再生装置に限定される、ということである。したがって、本発明によって、ライセンス発行時に発行対象の再生装置を特定して各再生装置に専用のライセンスを発行することが不要になる。これによって、ライセンス発行を高速に処理することが可能になり、再生装置の個数の増加に関してスケーラビリティのよいライセンス発行処理を実現することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るシステムの参加者を示した図である。
【図２】システム管理者２０の構成を模式的に示した図である。
【図３】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図４】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図５】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図６】コンテンツ提供者３０の機能構成を模式的に示した図である。
【図７】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図８】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図９】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図１０】再生装置４０の機能構成を模式的に示した図である。
【図１１】再生装置４０において保持されるデータ構成を模式的に示した図である。
【図１２】再生装置４０において保持されるデータ構成を模式的に示した図である。
【図１３】再生装置４０において保持されるデータ構成を模式的に示した図である。
【図１４】コンテンツ提供者３０又は再生装置がシステム管理者２０からイネーブル鍵を取得するための処理手順を示したフローチャートである。
【図１５】イネーブル・トークンのデータ構成を示した図である。
【図１６】イネーブル・トークンのデータ構成を示した図である。
【図１７】コンテンツ提供者３０における動作特性を示したフローチャートである。
【図１８】ユーザの再生装置４０がコンテンツ提供者３０から取得したコンテンツを利用するための処理手順を示したフローチャートである。
【図１９】コンテンツ提供装置３０から再生装置４０に送付されるコンテンツ配布形式のデータ構成を示した図である。
【図２０】ライセンス・トークンのデータ構成を示した図である。
【図２１】システム管理者２０においてイネーブル鍵を更新する処理手順をフローチャートである。
【図２２】コンテンツ表３１１を更新するための処理手順を示したフローチャートである。
【図２３】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図２４】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図２５】システム管理者２０において保持されるデータ構成を模式的に示した図である。
【図２６】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図２７】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図２８】コンテンツ提供者３０において保持されるデータ構成を模式的に示した図である。
【図２９】再生装置４０において保持されるデータ構成を模式的に示した図である。
【図３０】再生装置４０において保持されるデータ構成を模式的に示した図である。
【図３１】３１すべての再生装置が属する仮想的なツリー構造の例を示した図である。
【図３２】イネーブル鍵ブロックのデータ構成を模式的に示した図である。
【図３３】イネーブル・トークンのデータ構成を模式的に示した図である。
【図３４】ユーザの再生装置４０がコンテンツ提供者３０から取得したコンテンツを利用するための処理手順を示したフローチャートである。
【図３５】再生装置４０に送付されるコンテンツ配布形式のデータ構成を模式的に示した図である。
【図３６】ライセンス・トークンのデータ構成を模式的に示した図である。
【符号の説明】
２０…システム管理者
２１…暗号処理部，２２…データ記憶部
２３…乱数発生部，２４…時計
２５…通信処理部
３０…コンテンツ提供者
３１…耐タンパ性暗号処理部，３２…耐タンパ性データ記憶部
３３…データ記憶部，３４…乱数発生器
３５…通信処理部，３６…時計
４０…再生装置
４１…暗号処理部，４２…データ記憶部
４３…乱数発生器，４４…通信処理部
４５…時計

Claims (19)

1. ライセンスの配布によりコンテンツの利用を管理するコンテンツ利用管理システムであって、
   コンテンツを利用する正当な装置で生成された一回限りの乱数からなるノンスとコンテンツの利用許可の権限者に関する認証情報を少なくとも含むデータをライセンス・トークンとして用い、
   コンテンツを利用する正当な装置側では、ライセンス・トークンに自分が生成したノンスが含まれていること及びコンテンツ利用許可の権限者に関する認証情報の認証処理によりライセンス・トークンの有効性を検証し、ライセンス・トークンが有効である場合に該当するコンテンツをユーザに利用させる、
   ことを特徴とするコンテンツ利用管理システム。
2. ライセンスの配布によりコンテンツの利用を管理する情報処理装置であって、コンテンツの利用者から一回限りの乱数であるノンスを受信するノンス受信手段と、
   受信したノンスと自身の認証情報を少なくとも含むライセンス・トークンをコンテンツの利用者に配布するライセンス・トークン発行手段と、
   を具備することを特徴とする情報処理装置。
3. 前記ライセンス・トークン発行手段は、コンテンツ利用を許可する回数や期間などの利用条件をライセンス・トークンに含めて発行する、
   ことを特徴とする請求項２に記載の情報処理装置。
4. ライセンスの配布によりコンテンツの利用を管理する情報処理方法であって、コンテンツの利用者から一回限りの乱数であるノンスを受信するノンス受信ステップと、
   受信したノンスと自身の認証情報を少なくとも含むライセンス・トークンをコンテンツの利用者に配布するライセンス・トークン発行ステップと、
   を具備することを特徴とする情報処理方法。
5. コンテンツを安全に提供する情報処理装置であって、
   コンテンツを正当に利用する装置にイネーブル鍵を発行するイネーブル鍵発行手段と、
   コンテンツ毎に固有のコンテンツ鍵でコンテンツを暗号化するコンテンツ暗号化手段と、
   コンテンツ鍵を含むデータをイネーブル鍵で暗号化してなるコンテンツ・トークンを生成するコンテンツ・トークン生成手段と、
   暗号化コンテンツをコンテンツ・トークンとともに配布するコンテンツ提供手段と、
   を具備することを特徴とする情報処理装置。
6. 前記コンテンツ暗号化手段はコンテンツの一部としてその識別情報を含めてコンテンツ鍵で暗号化し、あるいは前記コンテンツ・トークン生成手段はコンテンツ鍵の一部としてコンテンツの識別情報を含めてイネーブル鍵で暗号化する、
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記イネーブル鍵発行手段は、コンテンツを利用する正当な装置にあらかじめイネーブル鍵を配布する、
   ことを特徴とする請求項５に記載の情報処理装置。
8. 前記イネーブル鍵発行手段は、コンテンツを利用する正当な装置毎に固有のイネーブル鍵を発行する、
   ことを特徴とする請求項５に記載の情報処理装置。
9. 前記イネーブル鍵発行手段は、コンテンツを利用する正当な各装置に該装置の個数の対数に比例するサイズのデータからなる階層構造のイネーブル鍵を発行する、
   ことを特徴とする請求項５に記載の情報処理装置。
10. 前記イネーブル鍵発行手段は、コンテンツを利用する正当な装置だけに取得可能な形式でイネーブル鍵を発行する、
    ことを特徴とする請求項５に記載の情報処理装置。
11. イネーブル鍵はコンテンツを利用する正当な各装置内の耐タンパ性のある記憶手段に保持されており、
    前記イネーブル鍵発行手段は、耐タンパ性が破壊された装置が発生したことに応答して、イネーブル鍵を更新する、
    ことを特徴とする請求項５に記載の情報処理装置。
12. コンテンツを安全に提供する情報処理方法であって、
    コンテンツを正当に利用する装置にイネーブル鍵を発行するイネーブル鍵発行ステップと、
    コンテンツ毎に固有のコンテンツ鍵でコンテンツを暗号化するコンテンツ暗号化ステップと、
    コンテンツ鍵を含むデータをイネーブル鍵で暗号化してなるコンテンツ・トークンを生成するコンテンツ・トークン生成ステップと、
    暗号化コンテンツをコンテンツ・トークンとともに配布するコンテンツ提供ステップと、
    を具備することを特徴とする情報処理方法。
13. ライセンスの取得によりコンテンツの正当な利用を行なう情報処理装置であって、
    コンテンツを取得するコンテンツ取得手段と、
    一回限りの乱数であるノンスを発行するノンス発行手段と、
    コンテンツに関するライセンス・トークンを受信して、前記ノンス発行手段が発行したノンスが含まれているか、及び所定のコンテンツ利用許可の権限者から得られたものであるかどうかを認証することにより該ライセンス・トークンの有効性を検証するライセンス・トークン検証手段と、
    ライセンス・トークンが有効であることに応答して、該当するコンテンツの利用を行なうコンテンツ利用手段と、
    を具備することを特徴とする情報処理装置。
14. コンテンツの利用を可能にするイネーブル鍵を保持するイネーブル鍵保持手段をさらに備え、
    前記コンテンツ取得手段は、コンテンツ鍵で暗号化された暗号化コンテンツを、コンテンツ鍵を含むデータがイネーブル鍵で暗号化されたコンテンツ・トークンとともに取得し、
    前記コンテンツ利用手段は、ライセンス・トークンに該当するコンテンツのコンテンツ・トークンをイネーブル鍵で復号してコンテンツ鍵を取り出すとともに、該コンテンツ鍵で暗号化コンテンツを復号して得られるコンテンツをユーザに利用させる、
    ことを特徴とする請求項１３に記載の情報処理装置。
15. ライセンス・トークンは該当するコンテンツの識別情報並びにコンテンツの利用条件を含み、
    前記コンテンツ利用手段は、ライセンス・トークンが有効であっても、利用が許可されたコンテンツの識別情報と一致しない場合、又は、利用条件が満たされない場合には、コンテンツの利用を中断する、
    ことを特徴とする請求項１３に記載の情報処理装置。
16. ライセンスの取得によりコンテンツの正当な利用を行なう情報処理方法であって、
    コンテンツを取得するコンテンツ取得ステップと、
    一回限りの乱数であるノンスを発行するノンス発行ステップと、
    コンテンツに関するライセンス・トークンを受信して、前記ノンス発行ステップにおいて発行したノンスが含まれているか、及び所定のコンテンツ利用許可の権限者から得られたものであるかどうかを認証することにより該ライセンス・トークンの有効性を検証するライセンス・トークン検証ステップと、
    ライセンス・トークンが有効であることに応答して、該当するコンテンツの利用を行なうコンテンツ利用ステップと、
    を具備することを特徴とする情報処理方法。
17. ライセンスの配布によりコンテンツの利用を管理するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    コンテンツの利用者から一回限りの乱数であるノンスを受信するノンス受信ステップと、
    受信したノンスと自身の認証情報を少なくとも含むライセンス・トークンをコンテンツの利用者に配布するライセンス・トークン発行ステップと、
    を具備することを特徴とするコンピュータ・プログラム。
18. コンテンツを安全に提供するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    コンテンツを正当に利用する装置にイネーブル鍵を発行するイネーブル鍵発行ステップと、
    コンテンツ毎に固有のコンテンツ鍵でコンテンツを暗号化するコンテンツ暗号化ステップと、
    コンテンツ鍵を含むデータをイネーブル鍵で暗号化してなるコンテンツ・トークンを生成するコンテンツ・トークン生成ステップと、
    暗号化コンテンツをコンテンツ・トークンとともに配布するコンテンツ提供ステップと、
    を具備することを特徴とするコンピュータ・プログラム。
19. ライセンスの取得によりコンテンツの正当な利用を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    コンテンツを取得するコンテンツ取得ステップと、
    一回限りの乱数であるノンスを発行するノンス発行ステップと、
    コンテンツに関するライセンス・トークンを受信して、前記ノンス発行ステップにおいて発行したノンスが含まれているか、及び所定のコンテンツ利用許可の権限者から得られたものであるかどうかを認証することにより該ライセンス・トークンの有効性を検証するライセンス・トークン検証ステップと、
    ライセンス・トークンが有効であることに応答して、該当するコンテンツの利用を行なうコンテンツ利用ステップと、
    を具備することを特徴とするコンピュータ・プログラム。

Images