JP4151274B2 - 情報処理装置および方法、ライセンスサーバ、並びにプログラム - Google Patents
情報処理装置および方法、ライセンスサーバ、並びにプログラム Download PDFInfo
- Publication number
- JP4151274B2 JP4151274B2 JP2002028915A JP2002028915A JP4151274B2 JP 4151274 B2 JP4151274 B2 JP 4151274B2 JP 2002028915 A JP2002028915 A JP 2002028915A JP 2002028915 A JP2002028915 A JP 2002028915A JP 4151274 B2 JP4151274 B2 JP 4151274B2
- Authority
- JP
- Japan
- Prior art keywords
- license
- content
- key
- encrypted
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、ライセンスサーバ、並びにプログラムに関し、特に、著作権者からライセンスを受けていないコンテンツが不正にコピーされ、利用されるのを防止することができるようにした、情報処理装置および方法、ライセンスサーバ、並びにプログラムに関する。
【０００２】
【従来の技術】
最近、インターネットを介して、ユーザが、自分自身が保持している音楽データを他のユーザに提供し、自分自身が保持していない音楽データを他のユーザから提供を受けるようにして、複数のユーザが無料で音楽データを交換しあうシステムが実現されている。
【０００３】
このようなシステムでは、理論的には、１つの音楽、その他のコンテンツが存在すれば、他の全てのユーザが、それを利用することが可能となり、多くのユーザがコンテンツを購入しなくなるため、コンテンツに関する著作権者は、著作物としてのコンテンツが売れないため、著作物の販売に伴い、本来受け取ることが可能な著作物の利用に関するロイヤリティを受け取る機会を失うことになる。
【０００４】
【発明が解決しようとする課題】
そこで、コンテンツの流通を妨げることなく、不正に利用されることを防止することが、社会的に要請されている。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、コンテンツが不正に利用されるのを確実に防止することができるようにするものである。
【０００６】
【課題を解決するための手段】
本発明の情報処理装置は、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可するライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含むコンテンツを記憶するコンテンツ記憶手段と、利用許可されるコンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、コンテンツを利用許可することができるライセンスがライセンス記憶手段に記憶されているか否かを判定する判定手段と、判定手段によりライセンスが記憶されていると判断されたことを条件としてコンテンツのコンテンツデータを復号する復号手段とを備え、暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定されることを特徴とする。
【０００７】
情報処理装置は更に、ライセンスサーバにライセンスを識別するためのライセンス識別情報を含むライセンス要求を送信する送信手段と、ライセンスサーバによって送信されたライセンスを受信する受信手段とを備え、受信手段により受信されたライセンスはライセンス記憶手段に記憶されるようにすることができる。
【０００８】
コンテンツデータはテキストデータ、画像データ、音声データ、動画データあるいはそれらを組み合わせたデータであり、復号手段により復号されたコンテンツデータを再生する再生手段を更に備えるようにすることができる。
【００１０】
前記鍵情報は EKB （ Enabling Key Block ）とEKB（Enabling Key Block）のルートキーによって暗号化されたコンテンツキーを含み、情報処理装置は更にデバイスノードキーを記憶するデバイスノードキー記憶手段を備え、復号手段はデバイスノードキー記憶手段に記憶されているデバイスノードキーを用いてEKB（Enabling Key Block）を復号処理し得られたルートキーを用いて復号されたコンテンツキーを用いて暗号化されたコンテンツデータを復号するようにすることができる。
【００１１】
ライセンスは更に、そのライセンスによって利用可能となるコンテンツの使用条件を示す使用条件情報を含むようにすることができる。
【００１２】
ライセンスは更に、ライセンスサーバの秘密鍵によりなされた電子署名を含むようにすることができる。
【００１３】
情報処理装置は、更に情報処理装置を識別する端末識別情報を記憶する端末識別情報記憶手段を備え、ライセンス要求は更に、端末識別情報記憶手段に記憶されている端末識別情報を含み、受信手段により受信されたライセンスは更に、端末識別情報を含み、判定手段は、ライセンスに含まれる端末識別情報と端末識別情報記憶手段に記憶されている端末識別情報とを比較し、両者が一致している場合に限り、そのライセンスをコンテンツの利用を許可できるライセンスであると判定するようにすることができる。
【００１４】
本発明の情報処理方法は、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含む前記コンテンツを記憶するコンテンツ記憶手段と、利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定する判定手段と、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置の情報処理方法であって、前記コンテンツ記憶手段が、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報と、を含むコンテンツを記憶するステップと、前記ライセンス記憶手段が、当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するステップと、前記判定手段が、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定するステップと、前記復号手段が、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号するステップとを含み、前記暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、前記ブロック鍵は、前記鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定されることを特徴とする。
【００１５】
本発明のプログラムは、コンピュータを、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可するライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含むコンテンツを記憶するコンテンツ記憶手段と、利用許可されるコンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、コンテンツを利用許可することができるライセンスがライセンス記憶手段に記憶されているか否かを判定する判定手段と、判定手段によりライセンスが記憶されていると判断されたことを条件としてコンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置であって、暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定される情報処理装置として機能させる。
【００１６】
プログラムあるいはその一部が暗号化されているようにすることができる。
【００１７】
本発明のライセンスサーバは、コンテンツの利用を許可するライセンスを発行するライセンスサーバにおいて、当該ライセンスによって利用許可されるコンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含むライセンスを記憶するライセンス記憶手段と、情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信する受信手段と、ライセンス要求に含まれるライセンス識別情報に対応するライセンスをライセンス記憶手段から抽出する抽出手段と、抽出手段により抽出されたライセンスに端末識別情報を付加する処理手段と、ライセンスサーバの秘密鍵を用いて、処理手段により端末識別情報を付加されたライセンスに電子署名を付加する署名手段と、署名手段により署名されたライセンスをライセンス要求を送信した情報処理装置に送信する送信手段とを備え、ライセンスによって利用許可されるコンテンツは、暗号化されて情報処理装置に記憶され、暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定され、コンテンツキーは、端末識別情報に対応するデバイスノードキー基づいて特定されることを特徴とする。
【００１８】
本発明の情報処理方法は、当該ライセンスによって利用許可されるコンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含むライセンスを記憶するステップと、情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信するステップと、ライセンス要求に含まれるライセンス識別情報に対応するライセンスをライセンス記憶手段から抽出するステップと、抽出手段により抽出されたライセンスに端末識別情報を付加するステップと、ライセンスサーバの秘密鍵を用いて、処理手段により端末識別情報を付加されたライセンスに電子署名を付加するステップと、署名手段により署名されたライセンスをライセンス要求を送信した情報処理装置に送信するステップとを含み、ライセンスによって利用許可されるコンテンツは、暗号化されて情報処理装置に記憶され、暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定され、コンテンツキーは、端末識別情報に対応するデバイスノードキー基づいて特定されることを特徴とする。
【００１９】
本発明の情報処理装置、情報処理方法、並びにプログラムでは、ライセンスを保持していることを条件としてコンテンツを復号し、利用可能にする。
【００２０】
本発明のライセンスサーバ、並びに情報処理方法では、特定の情報処理装置でのみ有効なライセンスを発行する。
【００２１】
【発明の実施の形態】
図１は、本発明を適用したコンテンツ提供システムの構成を示している。インターネット２には、クライアント１−１，１−２（以下、これらのクライアントを個々に区別する必要がない場合、単にクライアント１と称する）が接続されている。この例においては、クライアントが２台のみ示されているが、インターネット２には、任意の台数のクライアントが接続される。
【００２２】
また、インターネット２には、クライアント１に対してコンテンツを提供するコンテンツサーバ３、コンテンツサーバ３が提供するコンテンツを利用するのに必要なライセンスをクライアント１に対して付与するライセンスサーバ４、およびクライアント１がライセンスを受け取った場合に、そのクライアント１に対して課金処理を行う課金サーバ５が接続されている。
【００２３】
これらのコンテンツサーバ３、ライセンスサーバ４、および課金サーバ５も、任意の台数、インターネット２に接続される。
【００２４】
図２はクライアント１の構成を表している。
【００２５】
図２において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。タイマ２０は、計時動作を行い、時刻情報をCPU２１に供給する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００２６】
暗号化復号部２４は、コンテンツデータを暗号化するとともに、既に暗号化されているコンテンツデータを復号する処理を行う。コーデック部２５は、例えば、ATRAC（Adaptive Transform Acoustic Coding）３方式などでコンテンツデータをエンコードし、入出力インタフェース３２を介してドライブ３０に接続されている半導体メモリ４４に供給し、記録させる。あるいはまた、コーデック部２５は、ドライブ３０を介して半導体メモリ４４より読み出した、エンコードされているデータをデコードする。
【００２７】
半導体メモリ４４は、例えば、メモリスティック（商標）などにより構成される。
【００２８】
CPU２１、ROM２２、RAM２３、暗号化復号部２４、およびコーデック部２５は、バス３１を介して相互に接続されている。このバス３１にはまた、入出力インタフェース３２も接続されている。
【００２９】
入出力インタフェース３２には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、インターネット２を介しての通信処理を行う。通信部２９はまた、他のクライアントとの間で、アナログ信号またはデジタル信号の通信処理を行う。
【００３０】
入出力インタフェース３２にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
【００３１】
なお、図示は省略するが、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５も、図２に示したクライアント１と基本的に同様の構成を有するコンピュータにより構成される。そこで、以下の説明においては、図２の構成は、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５などの構成としても引用される。
【００３２】
次に、図３のフローチャートを参照して、クライアント１がコンテンツサーバ３からコンテンツの提供を受ける処理について説明する。
【００３３】
ユーザが、入力部２６を操作することでコンテンツサーバ３に対するアクセスを指令すると、CPU２１は、ステップＳ１において、通信部２９を制御し、インターネット２を介してコンテンツサーバ３にアクセスさせる。ステップＳ２において、ユーザが、入力部２６を操作して、提供を受けるコンテンツを指定すると、CPU２１は、この指定情報を受け取り、通信部２９から、インターネット２を介してコンテンツサーバ３に、指定されたコンテンツを通知する。図４のフローチャートを参照して後述するように、この通知を受けたコンテンツサーバ３は、暗号化されたコンテンツデータを送信してくるので、ステップＳ３において、CPU２１は、通信部２９を介して、このコンテンツデータを受信すると、ステップＳ４において、その暗号化されているコンテンツデータを記憶部２８を構成するハードディスクに供給し、記憶させる。
【００３４】
次に、図４のフローチャートを参照して、クライアント１の以上の処理に対応するコンテンツサーバ３のコンテンツ提供処理について説明する。なお、以下の説明において、図２のクライアント１の構成は、コンテンツサーバ３の構成としても引用される。
【００３５】
ステップＳ２１において、コンテンツサーバ３のCPU２１は、インターネット２から通信部２９を介してクライアント１よりアクセスを受けるまで待機し、アクセスを受けたと判定したとき、ステップＳ２２に進み、クライアント１から送信されてきたコンテンツを指定する情報を取り込む。このコンテンツを指定する情報は、クライアント１が、図３のステップＳ２において通知してきた情報である。
【００３６】
ステップＳ２３において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されているコンテンツデータの中から、ステップＳ２２の処理で取り込まれた情報で指定されたコンテンツを読み出す。CPU２１は、ステップＳ２４において、記憶部２８から読み出されたコンテンツデータを、暗号化復号部２４に供給し、コンテンツキーKcを用いて暗号化させる。
【００３７】
記憶部２８に記憶されているコンテンツデータは、コーデック部２５により、既にATRAC３方式によりエンコードされているので、このエンコードされているコンテンツデータが暗号化されることになる。
【００３８】
なお、もちろん、記憶部２８に予め暗号化した状態でコンテンツデータを記憶させることができる。この場合には、ステップＳ２４の処理は省略することが可能である。
【００３９】
次に、ステップＳ２５において、コンテンツサーバ３のCPU２１は、暗号化したコンテンツデータを伝送するフォーマットを構成するヘッダに、暗号化されているコンテンツを復号するのに必要なキー情報（図５を参照して後述するEKBとKEKBC（Kc））と、コンテンツを利用するのに必要なライセンスを識別するためのライセンスIDを付加する。そして、ステップＳ２６において、コンテンツサーバ３のCPU２１は、ステップＳ２４の処理で暗号化したコンテンツと、ステップＳ２５の処理でキーとライセンスIDを付加したヘッダとをフォーマット化したデータを、通信部２９から、インターネット２を介して、アクセスしてきたクライアント１に送信する。
【００４０】
図５は、このようにして、コンテンツサーバ３からクライアント１にコンテンツが供給される場合のフォーマットの構成を表している。同図に示されるように、このフォーマットは、ヘッダ（Header）とデータ（Data）とにより構成される。
【００４１】
ヘッダには、コンテンツ情報（Content information）、デジタル権利管理情報（DRM（Digital Right Management） information ）、ライセンスID（License ID）、イネーブリングキーブロック（有効化キーブロック）（EKB（Enabling Key Block））および、EKBから生成されたキーKEKBCを用いて暗号化されたコンテンツキーKcとしてのデータKEKBC（Kc）が配置されている。なお、EKBについては、図１５を参照して後述する。
【００４２】
コンテンツ情報には、データとしてフォーマット化されているコンテンツデータを識別するための識別情報としてのコンテンツID（CID）、そのコンテンツのコーデックの方式などの情報が含まれている。
【００４３】
デジタル権利管理情報には、コンテンツを使用する規則および状態（Usage rules/status）と、URL（Uniform Resource Locator）が配置されている。使用規則および状態には、例えば、コンテンツの再生回数、コピー回数などが記述される。
【００４４】
URLは、ライセンスIDで規定されるライセンスを取得するときアクセスするアドレス情報であり、図１のシステムの場合、具体的には、ライセンスを受けるために必要なライセンスサーバ４のアドレスである。ライセンスIDは、データとして記録されているコンテンツを利用するとき必要とされるライセンスを識別するものである。
【００４５】
データは、任意の数の暗号化ブロック（Encryption Block）により構成される。各暗号化ブロックは、イニシャルベクトル（IV（Initial Vector））、シード（Seed）、およびコンテンツデータをキーK'cで暗号化したデータEK'c(data)により構成されている。
【００４６】
キーK'cは、次式により示されるように、コンテンツキーKcと、乱数で設定される値Seedをハッシュ関数に適用して演算された値により構成される。
【００４７】
K'c＝Hash(Kc, Seed)
【００４８】
イニシャルベクトルIVとシードSeedは、各暗号化ブロック毎に異なる値に設定される。
【００４９】
この暗号化は、コンテンツのデータを８バイト単位で区分して、８バイト毎に行われる。後段の８バイトの暗号化は、前段の８バイトの暗号化の結果を利用して行われるCBC（Cipher Block Chaining）モードで行われる。
【００５０】
CBCモードの場合、最初の８バイトのコンテンツデータを暗号化するとき、その前段の８バイトの暗号化結果が存在しないため、最初の８バイトのコンテンツデータを暗号化するときは、イニシャルベクトルIVを初期値として暗号化が行われる。
【００５１】
このCBCモードによる暗号化を行うことで、１つの暗号化ブロックが解読されたとしても、その影響が、他の暗号化ブロックにおよぶことが抑制される。
【００５２】
なお、この暗号化については、図４６を参照にして、後に詳述する。
【００５３】
また、暗号方式についてはこれに限らない。
【００５４】
以上のようにして、クライアント１は、コンテンツサーバ３からコンテンツを無料で、自由に取得することができる。従って、コンテンツそのものは、大量に、配布することが可能となる。
【００５５】
しかしながら、各クライアント１は、取得したコンテンツを利用するとき、ライセンスを保持している必要がある。そこで、図６を参照して、クライアント１がコンテンツを再生する場合の処理について説明する。
【００５６】
ステップＳ４１において、クライアント１のCPU２１は、ユーザが入力部２６を操作することで指示したコンテンツの識別情報（CID）を取得する。この識別情報は、例えば、コンテンツのタイトルや、記憶されている各コンテンツ毎に付与されている番号などにより構成される。
【００５７】
そして、CPU２１は、コンテンツが指示されると、そのコンテンツに対応するライセンスID（そのコンテンツを使用するのに必要なライセンスのID）を読み取る。このライセンスIDは、図５に示されるように、暗号化されているコンテンツデータのヘッダに記述されているものである。
【００５８】
次に、ステップＳ４２に進み、CPU２１は、ステップＳ４１で読み取られたライセンスIDに対応するライセンスが、クライアント１により既に取得され、記憶部２８に記憶されているか否かを判定する。まだ、ライセンスが取得されていない場合には、ステップＳ４３に進み、CPU２１は、ライセンス取得処理を実行する。このライセンス取得処理の詳細は、図７のフローチャートを参照して後述する。
【００５９】
ステップＳ４２において、ライセンスが既に取得されていると判定された場合、または、ステップＳ４３において、ライセンス取得処理が実行された結果、ライセンスが取得された場合、ステップＳ４４に進み、CPU２１は、取得されているライセンスは有効期限内のものであるか否かを判定する。ライセンスが有効期限内のものであるか否かは、ライセンスの内容として規定されている期限（後述する図８参照）と、タイマ２０により計時されている現在日時と比較することで判断される。ライセンスの有効期限が既に満了していると判定された場合、CPU２１は、ステップＳ４５に進み、ライセンス更新処理を実行する。このライセンス更新処理の詳細は、図１０のフローチャートを参照して後述する。
【００６０】
ステップＳ４４において、ライセンスはまだ有効期限内であると判定された場合、または、ステップＳ４５において、ライセンスが更新された場合、ステップＳ４６に進み、CPU２１は、暗号化されているコンテンツデータを記憶部２８から読み出し、RAM２３に格納させる。そして、ステップＳ４７において、CPU２１は、RAM２３に記憶された暗号化ブロックのデータを、図５のデータに配置されている暗号化ブロック単位で、暗号化復号部２４に供給し、コンテンツキーKcを用いて復号させる。
【００６１】
コンテンツキーKcを得る方法の具体例は、図１５を参照して後述するが、デバイスノードキー（DNK）（図８）を用いて、EKB（図５）に含まれるキーＫEKBCを得ることができ、そのキーＫEKBCを用いて、データＫEKBC（Kc）（図５）から、コンテンツキーKcを得ることができる。
【００６２】
CPU２１は、さらに、ステップＳ４８において、暗号化復号部２４により復号されたコンテンツデータをコーデック部２５に供給し、デコードさせる。そして、コーデック部２５によりデコードされたデータを、CPU２１は、入出力インタフェース３２から出力部２７に供給し、D/A変換させ、スピーカから出力させる。
【００６３】
次に、図７のフローチャートを参照して、図６のステップＳ４３で行われるライセンス取得処理の詳細について説明する。
【００６４】
クライアント１は、事前にライセンスサーバに登録することにより、リーフID、DNK(Device Node Key)、クライアント１の秘密鍵・公開鍵のペア、ライセンスサーバの公開鍵、及び各公開鍵の証明書を含むサービスデータを取得しておく。
【００６５】
リーフIDは、クライアント毎に割り当てられた識別情報を表し、DNKは、そのライセンスに対応するEKB（有効化キーブロック）に含まれる暗号化されているコンテンツキーKcを復号するのに必要なデバイスノードキーである（図１２を参照して後述する）。
【００６６】
最初にステップＳ６１において、CPU２１は、いま処理対象とされているライセンスIDに対応するURLを、図５に示すヘッダから取得する。上述したように、このURLは、やはりヘッダに記述されているライセンスIDに対応するライセンスを取得するときアクセスすべきアドレスである。そこで、ステップＳ６２において、CPU２１は、ステップＳ６１で取得したURLにアクセスする。具体的には、通信部２９によりインターネット２を介してライセンスサーバ４にアクセスが行われる。このとき、ライセンスサーバ４は、クライアント１に対して、購入するライセンス（コンテンツを使用するのに必要なライセンス）を指定するライセンス指定情報、並びにユーザIDとパスワードの入力を要求してくる（後述する図９のステップＳ１０２）。CPU２１は、この要求を出力部２７の表示部に表示させる。ユーザは、この表示に基づいて、入力部２６を操作して、ライセンス指定情報、ユーザID、およびパスワードを入力する。なお、このユーザIDとパスワードは、クライアント１のユーザが、インターネット２を介してライセンスサーバ４にアクセスし、事前に取得しておいたものである。
【００６７】
CPU２１は、ステップＳ６３，Ｓ６４において、入力部２６から入力されたライセンス識別情報を取り込むとともに、ユーザIDとパスワードを取り込む。CPU２１は、ステップＳ６５において、通信部２９を制御し、入力されたユーザIDとパスワードを、ライセンス指定情報及びサービスデータ（後述する）に含まれるリーフIDを含むライセンス要求をインターネット２を介してライセンスサーバ４に送信させる。
【００６８】
ライセンスサーバ４は、図９を参照して後述するように、ユーザIDとパスワード、並びにライセンス指定情報に基づいてライセンスを送信してくる（ステップＳ１０９）か、または、条件が満たされない場合には、ライセンスを送信してこない（ステップＳ１１２）。
【００６９】
ステップＳ６６において、CPU２１は、ライセンスサーバ４からライセンスが送信されてきたか否かを判定し、ライセンスが送信されてきた場合には、ステップＳ６７に進み、そのライセンスを記憶部２８に供給し、記憶させる。
【００７０】
ステップＳ６６において、ライセンスが送信されて来ないと判定した場合、CPU２１は、ステップＳ６８に進み、エラー処理を実行する。具体的には、CPU２１は、コンテンツを利用するためのライセンスが得られないので、コンテンツの再生処理を禁止する。
【００７１】
以上のようにして、各クライアント１は、コンテンツデータに付随しているライセンスIDに対応するライセンスを取得して、初めて、そのコンテンツを使用することが可能となる。
【００７２】
なお、図７のライセンス取得処理は、各ユーザがコンテンツを取得する前に、予め行っておくようにすることも可能である。
【００７３】
クライアント１に提供されるライセンスは、例えば、図８に示されるように、使用条件、リーフIDおよびを含んでいる。
【００７４】
使用条件には、そのライセンスに基づいて、コンテンツを使用することが可能な使用期限、そのライセンスに基づいて、コンテンツをダウンロードすることが可能なダウンロード期限、そのライセンスに基づいて、コンテンツをコピーすることが可能な回数（許されるコピー回数）、チェックアウト回数、最大チェックアウト回数、そのライセンスに基づいて、コンテンツをCD-Rに記録することができる権利、PD（Portable Device）にコピーすることが可能な回数、ライセンスを所有権（買い取り状態）に移行できる権利、使用ログをとる義務等を示す情報が含まれる。
【００７５】
次に、図９のフローチャートを参照して、図７のクライアント１のライセンス取得処理に対応して実行されるライセンスサーバ４のライセンス提供処理について説明する。なお、この場合においても、図２のクライアント１の構成は、ライセンスサーバ４の構成として引用される。
【００７６】
ステップＳ１０１において、ライセンスサーバ４のCPU２１は、クライアント１よりアクセスを受けるまで待機し、アクセスを受けたとき、ステップＳ１０２に進み、アクセスしてきたクライアント１に対して、ユーザIDとパスワード、並びに、ライセンス指定情報の送信を要求する。上述したようにして、クライアント１から、図７のステップＳ６５の処理で、ユーザIDとパスワード、リーフID並びにライセンス指定情報（ライセンスID）が送信されてきたとき、ライセンスサーバ４のCPU２１は、通信部２９を介してこれを受信し、取り込む処理を実行する。
【００７７】
そして、ライセンスサーバ４のCPU２１は、ステップＳ１０３において、通信部２９から課金サーバ５にアクセスし、ユーザIDとパスワードに対応するユーザの与信処理を要求する。課金サーバ５は、インターネット２を介してライセンスサーバ４から与信処理の要求を受けると、そのユーザIDとパスワードに対応するユーザの過去の支払い履歴などを調査し、そのユーザが、過去にライセンスの対価の不払いの実績があるか否かなどを調べ、そのような実績がない場合には、ライセンスの付与を許容する与信結果を送信し、不払いの実績などがある場合には、ライセンス付与の不許可の与信結果を送信する。
【００７８】
ステップＳ１０４において、ライセンスサーバ４のCPU２１は、課金サーバ５からの与信結果が、ライセンスを付与することを許容する与信結果であるか否かを判定し、ライセンスの付与が許容されている場合には、ステップＳ１０５に進み、ステップＳ１０２の処理で取り込まれたライセンス指定情報に対応するライセンスを、記憶部２８に記憶されているライセンスの中から取り出す。記憶部２８に記憶されているライセンスは、あらかじめライセンスID、バージョン、作成日時、有効期限等の情報が記述されている。ステップＳ１０６において、CPU２１は、そのライセンスに受信したリーフIDを付加する。さらに、ステップＳ１０７において、CPU２１は、ステップＳ１０５で選択されたライセンスに対応づけられている使用条件を選択する。あるいはまた、ステップＳ１０２の処理で、ユーザから使用条件が指定された場合には、その使用条件が必要に応じて、予め用意されている使用条件に付加される。CPU２１は、選択された使用条件をライセンスに付加する。
【００７９】
ステップＳ１０８において、ＣＰＵ２１はライセンスサーバの秘密鍵によりライセンスに署名し、これにより、図８に示されるような構成のライセンスが生成される。
【００８０】
次に、ステップＳ１０９に進み、ライセンスサーバ４のCPU２１は、そのライセンス（図８に示される構成を有する）を、通信部２９からインターネット２を介してクライアント１に送信させる。
【００８１】
ステップＳ１１０においてライセンスサーバ４のCPU２１は、ステップＳ１０９の処理で、いま送信したライセンス（使用条件、リーフIDを含む）を、ステップＳ１０２の処理で取り込まれたユーザIDとパスワードに対応して、記憶部２８に記憶させる。さらに、ステップＳ１１１において、CPU２１は、課金処理を実行する。具体的には、CPU２１は、通信部２９から課金サーバ５に、そのユーザIDとパスワードに対応するユーザに対する課金処理を要求する。課金サーバ５は、この課金の要求に基づいて、そのユーザに対する課金処理を実行する。上述したように、この課金処理に対して、そのユーザが支払いを行わなかったような場合には、以後、そのユーザは、ライセンスの付与を要求したとしても、ライセンスを受けることができないことになる。
【００８２】
すなわち、この場合には、課金サーバ５からライセンスの付与を不許可とする与信結果が送信されてくるので、ステップＳ１０４からステップＳ１１２に進み、CPU２１は、エラー処理を実行する。具体的には、ライセンスサーバ４のCPU２１は、通信部２９を制御してアクセスしてきたクライアント１に対して、ライセンスを付与することができない旨のメッセージを出力し、処理を終了させる。
【００８３】
この場合、上述したように、そのクライアント１はライセンスを受けることができないので、そのコンテンツを利用すること（暗号を復号すること）ができないことになる。
【００８４】
図１０は、図６のステップＳ４５におけるライセンス更新処理の詳細を表している。図１０のステップＳ１３１乃至ステップＳ１３５の処理は、図７のステップＳ６１乃至ステップＳ６５の処理と基本的に同様の処理である。ただし、ステップＳ１３３において、CPU２１は、購入するライセンスではなく、更新するライセンスのライセンスIDを取り込む。そして、ステップＳ１３５において、CPU２１は、ユーザIDとパスワードとともに、更新するライセンスのライセンスIDを、ライセンスサーバ４に送信する。
【００８５】
ステップＳ１３５の送信処理に対応して、ライセンスサーバ４は、後述するように、使用条件を提示してくる（図１１のステップＳ１５３）。そこで、クライアント１のCPU２１は、ステップＳ１３６において、ライセンスサーバ４からの使用条件の提示を受信し、これを出力部２７に出力し、表示させる。ユーザは、入力部２６を操作して、この使用条件の中から所定の使用条件を選択したり、所定の使用条件を新たに追加したりする。ステップＳ１３７でCPU２１は、以上のようにして選択された使用条件（ライセンスを更新する条件）を購入するための申し込みをライセンスサーバ４に送信する。この申し込みに対応して、後述するようにライセンスサーバ４は、最終的な使用条件を送信してくる（図１１のステップＳ１５４）。そこで、ステップＳ１３８において、クライアント１のCPU２１は、ライセンスサーバ４からの使用条件を取得し、ステップＳ１３９において、その使用条件を記憶部２８にすでに記憶されている対応するライセンスの使用条件として更新する。
【００８６】
図１１は、以上のクライアント１のライセンス更新処理に対応して、ライセンスサーバ４が実行するライセンス更新処理を表している。
【００８７】
最初に、ステップＳ１５１において、ライセンスサーバ４のCPU２１は、クライアント１からのアクセスを受けると、ステップＳ１５２において、クライアント１がステップＳ１３５で送信したライセンス指定情報をライセンス更新要求情報とともに受信する。
【００８８】
ステップＳ１５３において、CPU２１は、ライセンスの更新要求を受信すると、そのライセンスに対応する使用条件（更新する使用条件）を、記憶部２８から読み出し、クライアント１に送信する。
【００８９】
この提示に対して、上述したように、クライアント１から使用条件の購入が図１０のステップＳ１３７の処理で申し込まれると、ステップＳ１５４において、ライセンスサーバ４のCPU２１は、申し込まれた使用条件に対応するデータを生成し、ステップＳ１５４において、クライアントと１に送信する。クライアント１は、上述したように、ステップＳ１３９の処理で受信した使用条件を用いて、すでに登録されているライセンスの使用条件を更新する。
【００９０】
本発明においては、図１２に示されるように、ブロードキャストインクリプション（Broadcast Encryption）方式の原理に基づいて、デバイスとライセンスのキーが管理される。キーは、階層ツリー構造とされ、最下段のリーフ（leaf）が個々のデバイスのキーに対応する。図１２の例の場合、番号０から番号１５までの１６個のデバイスまたはライセンスに対応するキーが生成される。
【００９１】
各キーは、図中丸印で示されるツリー構造の各ノードに対応して規定される。この例では、最上段のルートノードに対応してルートキーKRが、２段目のノードに対応してキーＫ０，Ｋ１が、３段目のノードに対応してキーＫ００乃至Ｋ１１が、第４段目のノードに対応してキーＫ０００乃至キーＫ１１１が、それぞれ対応されている。そして、最下段のノードとしてのリーフ（デバイスノード）に、キーＫ００００乃至Ｋ１１１１が、それぞれ対応されている。
【００９２】
階層構造とされているため、例えば、キーＫ００１０とキー００１１の上位のキーは、Ｋ００１とされ、キーＫ０００とキーＫ００１の上位のキーは、Ｋ００とされている。以下同様に、キーＫ００とキーＫ０１の上位のキーは、Ｋ０とされ、キーＫ０とキーＫ１の上位のキーは、KRとされている。
【００９３】
コンテンツを利用するキーは、最下段のデバイスノード（リーフ）から、最上段のルートノードまでの１つのパスの各ノードに対応するキーで管理される。例えば、番号３のノード（リーフID）に対応するライセンスに基づき、コンテンツを利用するキーは、キーＫ００１１，Ｋ００１，Ｋ００，Ｋ０，KRを含むパスの各キーで管理される。
【００９４】
本発明のシステムにおいては、図１３に示されるように、図１２の原理に基づいて構成されるキーシステムで、デバイスのキーとライセンスのキーの管理が行われる。図１３の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリスティックなどの半導体メモリを使用する機器のカテゴリ、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、ライセンスを管理するシステムとして本システム（Ｔシステムと称する）が対応する。
【００９５】
すなわち、このＴシステムのノードよりさらに下の階層の２４段のノードに対応するキーにより、ライセンスが対応される。この例の場合、これにより、２24（約１６メガ）のライセンスを規定することができる。さらに、最も下側の３２段の階層により、２32（約４ギガ）のユーザ（あるいはクライアント１）を規定することができる。最下段の３２段のノードに対応するキーが、DNK（Device Node Key）を構成し、最下段のリーフに対応するIDがリーフIDとされる。
【００９６】
各デバイスやライセンスのキーは、６４（＝８＋２４＋３２）段の各ノードで構成されるパスの内の１つに対応される。例えば、コンテンツを暗号化したコンテンツキーは、対応するライセンスに割り当てられたパスを構成するノードに対応するキーを用いて暗号化される。上位の階層のキーは、その直近の下位の階層のキーを用いて暗号化され、ＥＫＢ（図１５を参照して後述する）内に配置される。最下段のＤＮＫは、ＥＫＢ内には配置されず、サービスデータに記述され、ユーザのクライアント１に与えられる。クライアント１は、ライセンスに記述されているＤＮＫを用いて、コンテンツデータとともに配布されるＥＫＢ（図１５）内に記述されている直近の上位の階層のキーを復号し、復号して得たキーを用いて、ＥＫＢ内に記述されているさらにその上の階層のキーを復号する。以上の処理を順次行うことで、クライアント１は、そのライセンスのパスに属するすべてのキーを得ることができる。
【００９７】
図１４に階層ツリー構造のカテゴリの分類の具体的な例を示す。図１４において、階層ツリー構造の最上段には、ルートキーKR２３０１が設定され、以下の中間段にはノードキー２３０２が設定され、最下段には、リーフキー２３０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーを保有する。
【００９８】
最上段から第Ｍ段目（図１３の例では、Ｍ＝８）の所定のノードがカテゴリノード２３０４として設定される。すなわち第Ｍ段目のノードの各々が特定カテゴリのデバイス設定ノードとされる。第Ｍ段の１つのノードを頂点としてＭ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとされる。
【００９９】
例えば図１４の第Ｍ段目の１つのノード２３０５にはカテゴリ［メモリスティック（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード２３０５以下が、メモリスティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義される。
【０１００】
さらに、Ｍ段から数段分下位の段をサブカテゴリノード２３０６として設定することができる。図１４の例では、カテゴリ［メモリスティック］ノード２３０５の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノード２３０６が設定されている。さらに、サブカテゴリノードである再生専用器のノード２３０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード２３０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード２３０８と、［携帯電話］ノード２３０９が設定されている。
【０１０１】
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺに、その頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
【０１０２】
このように、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
【０１０３】
例えば、図１２に示されるツリー構造において、１つのグループに含まれる４つのデバイス０，１，２，３はノードキーとして共通のキーＫ００、Ｋ０、KRを保有する。このノードキー共有構成を利用することにより、共通のコンテンツキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００自体をコンテンツキーとして設定すれば、新たな鍵送付を実行することなくデバイス０，１，２，３のみが共通のコンテンツキーの設定が可能である。また、新たなコンテンツキーＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキーＫｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【０１０４】
また、ある時点ｔにおいて、デバイス３の所有する鍵Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,KRが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキーＫ００１,Ｋ００,Ｋ０,KRを、それぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Generation）ｔの更新キーであることを示す。
【０１０５】
更新キーの配布処理ついて説明する。キーの更新は、例えば、図１５Ａに示す有効化キーブロック（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデータによって構成されるテーブルを、ネットワークを介して、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図１２に示されるようなツリー構造を構成する各リーフ（最下段のノード）に対応するデバイスに、新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Key Renewal Block）と呼ばれることもある。
【０１０６】
図１５Ａに示す有効化キーブロック（ＥＫＢ）は、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図１５Ａの例は、図１２に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図１２から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
【０１０７】
図１５ＡのＥＫＢに示されるように、ＥＫＢには複数の暗号化キーが含まれる。図１５Ａの最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーＫ００１０によってこの暗号化キーを復号し、更新ノードキーＫ（ｔ）００１を得ることができる。また、復号により得た更新ノードキーＫ（ｔ）００１を用いて、図１５Ａの下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）が復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。
【０１０８】
以下順次、図１５Ａの上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０が得られ、これを用いて、図１５Ａの上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒが得られる。
【０１０９】
一方、ノードキーＫ０００は更新する対象に含まれておらず、ノード０，１が、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。ノード０，１は、デバイスキーＫ００００，Ｋ０００１を用いて、図１５Ａの上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号することで更新ノードキーＫ（ｔ）００を取得し、以下順次、図１５Ａの上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０を得、図１５Ａの上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新したキーＫ（ｔ）Ｒを得ることができる。
【０１１０】
なお、図１５Ａのインデックスは、図の右側の暗号化キーを復号するための復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
【０１１１】
図１２に示すツリー構造の上位段のノードキーＫ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図１５Ｂの有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
【０１１２】
図１５Ｂに示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図１２に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）が、図１５Ｂに示されるＥＫＢとともに配布される。この配布により、デバイス４など、その他のグループの機器が復号することができないデータとしての配布が可能となる。
【０１１３】
すなわち、デバイス０，１，２はＥＫＢを処理して得たキーＫ（ｔ）００を用いて暗号文を復号すれば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
【０１１４】
図１６に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と、図１５Ｂに示すＥＫＢとを記録媒体を介して受領したデバイス０の処理を示す。すなわちこの例は、ＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【０１１５】
図１６に示すように、デバイス０は、記録媒体に格納されている世代t時点のＥＫＢと、自分があらかじめ格納しているノードキーＫ０００を用いて、上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、デバイス０は、復号した更新ノードキーＫ（ｔ）００を用いて、更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
【０１１６】
図１７に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン６０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは、最新のＥＫＢを識別する機能と、コンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ６０３は、有効化キーブロック（ＥＫＢ）中のデータ部６０６の位置を示すポインタであり、タグポインタ６０４はタグ部６０７の位置、署名ポインタ６０５は署名６０８の位置を示すポインタである。
【０１１７】
データ部６０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図１６に示すような更新されたノードキーに関する各暗号化キー等を格納する。
【０１１８】
タグ部６０７は、データ部６０６に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図１８を用いて説明する。
【０１１９】
図１８では、データとして先に図１５Ａで説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図１８Ｂの表に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この例の場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはKRとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図１８Ａに示す階層ツリーに示す位置Ｐ０に対応する。次の段のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置Ｐ００に対応する。ツリー構造の所定の位置から見て、その下に、データがある場合は、タグが０、ない場合はタグが１に設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。図１８Ｂの最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）に対応する位置POの左下の位置POOにはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図１８Ｃに示すデータ列、およびタグ列が構成される。
【０１２０】
タグは、対応するデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）が、ツリー構造のどこに位置しているのかを示すために設定されるものである。データ部６０６に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）・・・は、単純に暗号化されたキーの羅列データに過ぎないが、上述したタグによってデータとして格納された暗号化キーのツリー上の位置が判別可能となる。上述したタグを用いずに、先の図１５で説明した構成のように、暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（ｔ）００）
・・・のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると、冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
【０１２１】
図１７に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Signature）６０８は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センタ（ライセンスサーバ４）、コンテンツロバイダ（コンテンツサーバ３）、決済機関（課金サーバ５）等が実行する電子署名である。ＥＫＢを受領したデバイスは、署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
【０１２２】
以上のようにして、ライセンスサーバ４から供給されたライセンスに基づいて、コンテンツサーバ３から供給されたコンテンツを利用する処理をまとめると、図１９に示されるようになる。
【０１２３】
すなわち、コンテンツサーバ３からクライアント１に対してコンテンツが提供されるとともに、ライセンスサーバ４からクライアント１にライセンスが供給される。コンテンツは、コンテンツキーKcにより、暗号化されており（Enc（Kc，Content））、コンテンツキーKcは、ルートキーKR(EKBから得られるキーであって、図５におけるキーＫEKBCに対応する)で暗号化され（Enc（KR，Kc））、EKBとともに、暗号化されたコンテンツに付加されてクライアント１に提供される。
【０１２４】
図１９の例におけるEKBには、例えば、図２０に示されるように、DNKで暗号化したルートキーKRが含まれている（Enc（DNK，KR））。従って、クライアント１は、サービスデータに含まれるDNKを利用して、EKBからルートキーKRを得ることができる。さらに、ルートキーKRを用いて、Enc（KR，Kc）からコンテンツキーKcを復号することができ、コンテンツキーKcを用いて、Enc（Kc，Content）からコンテンツを復号することができる。
【０１２５】
このように、クライアント１にDNKを個別に割り当てることにより、図１２と図１５を参照して説明した原理に従って、個々のクライアント１のリボーク（revoke）が可能になる。
【０１２６】
また、ライセンスリーフIDを付加して配布することにより、クライアント１において、サービスデータとライセンスの対応付けが行われることになり、ライセンスの不正コピーを防止することが可能になる。
【０１２７】
また、クライアント用の証明書と秘密鍵をサービスデータとして配信するようにすることで、エンドユーザも、これらを用いて不正コピーを防止可能なコンテンツを作成することが可能になる。
【０１２８】
証明書と秘密鍵の利用については、図２８のフローチャートを参照して後述する。
【０１２９】
本発明においては、図１３を参照して説明したように、カテゴリノードにライセンスを管理するＴシステムと、各種のコンテンツを利用するデバイスのカテゴリが対応づけられるので、複数のDNKを同一のデバイスに持たせることができる。その結果、異なるカテゴリのコンテンツを１つのデバイスで管理することが可能となる。
【０１３０】
図２１は、この関係を表している。すなわち、デバイスＤ１には、Ｔシステムに基づいて、DNK１が割り当てられている、コンテンツ１を利用するライセンスが記録される。同様に、このデバイスＤ１には、例えば、DNK２が割り当てられた、メモリスティックにCDからリッピングしたコンテンツ２を記録することができる。この場合、デバイスＤ１は、コンテンツ１とコンテンツ２という、異なるシステム（Ｔシステムとデバイス管理システム）により配信されたコンテンツを同時に扱うことが可能となる。新たなDNKを割り当てるとき、既に割り当てられているDNKを削除するなどして、デバイスに１個のDNKだけを対応させるようにした場合、このようなことはできない。
【０１３１】
また、図１３における、例えば、下側の３２階層の各三角形の１つ１つに、図２２に示されるライセンスカテゴリ１とライセンスカテゴリ２を割り当てることにより、同一のカテゴリ内を、サブカテゴリを利用して、コンテンツのジャンル、レーベル、販売店、配信サービス等の小さな集まりに分類して、管理することが可能となる。
【０１３２】
図２２の例においては、例えば、ライセンスカテゴリ１は、ジャズのジャンルに属し、ライセンスカテゴリ２は、ロックのジャンルに属する。ライセンスカテゴリ１には、ライセンスIDが１であるコンテンツ１とコンテンツ２を対応させ、それぞれユーザ１乃至ユーザ３に配布されている。ライセンスカテゴリ２は、ライセンスID２のコンテンツ３、コンテンツ４、およびコンテンツ５が含まれ、それぞれユーザ１とユーザ３に提供されている。
【０１３３】
このように、本発明においては、カテゴリ毎に独立したキー管理が可能になる。
【０１３４】
また、DNKを、機器やメディアに予め埋め込むのではなく、ライセンスサーバ４により、登録処理を行う際に、各機器やメディアにダウンロードするようにすることで、ユーザによるキーの購入が可能なシステムを実現することができる。
【０１３５】
コンテンツは、それが作成された後、どのような使われ方をされようとも、その使われ方に関わりなく、全ての用途において、使用可能であるのが望ましい。例えば、異なるコンテンツ配信サービス、あるいは使用条件が異なるドメインにおいても、同一のコンテンツが使えることが望ましい。本発明においては、このため、上述したように、各ユーザ（クライアント１）に、認証局としてのライセンスサーバ４から秘密鍵と、それに対応する公開鍵の証明書（certificates）が配布される。各ユーザは、その秘密鍵を用いて、署名（signature）を作成し、コンテンツに付加して、コンテンツの真正さ(integrity)を保証し、かつコンテンツの改竄防止を図ることができる。
【０１３６】
この場合の処理の例について、図２３のフローチャートを参照して説明する。図２３の処理は、ユーザがCDから再生したデータを記憶部２８に記憶させるリッピング処理を説明するものである。
【０１３７】
最初に、ステップＳ１７１において、クライアント１のCPU２１は、通信部２９を介して入力されるCDの再生データを記録データとして取り込む。ステップＳ１７２において、CPU２１は、ステップＳ１７１の処理で取り込まれた記録データにウォーターマークが含まれているか否かを判定する。このウォーターマークは、３ビットのコピー管理情報（CCI）と、１ビットのトリガ（Trigger）とにより構成され、コンテンツのデータの中に埋め込まれている。CPU２１は、ウォーターマークが検出された場合には、ステップＳ１７３に進み、そのウォーターマークを抽出する処理を実行する。ウォーターマークが存在しない場合には、ステップＳ１７３の処理はスキップされる。
【０１３８】
次に、ステップＳ１７４において、CPU２１は、コンテンツに対応して記録するヘッダのデータを作成する。このヘッダのデータは、コンテンツID、ライセンスID、ライセンスを取得するためのアクセス先を表すURL、およびウォーターマークにより構成される。
【０１３９】
次に、ステップＳ１７５に進み、CPU２１は、ステップＳ１７４の処理で作成したヘッダのデータに基づいたデジタル署名を、自分自身の秘密鍵を用いて作成する。この秘密鍵は、ライセンスサーバ４から取得したものである（図７のステップＳ６７）。
【０１４０】
ステップＳ１７６で、CPU２１は、暗号化復号部２４を制御し、コンテンツキーでコンテンツを暗号化させる。コンテンツキーは、コンテンツを取得したとき、同時に取得されたものである（図５または図１９）。
【０１４１】
次に、ステップＳ１７７において、CPU２１は、ファイルフォーマットに基づき、データを、例えば、ミニディスク等により構成される光磁気ディスク４３に記録させる。
【０１４２】
なお、記録媒体がミニディスクである場合、ステップＳ１７６において、CPU２１は、コンテンツをコーデック部２５に供給し、例えば、ATRAC３方式によりコンテンツを符号化させる。そして、符号化されたデータが暗号化復号部２４によりさらに暗号化される。
【０１４３】
図２４は、以上のようにして、記録媒体にコンテンツが記録された状態を模式的に表している。暗号化されているコンテンツ（Ｅ（At３））から抽出されたウォーターマーク（WM）が、コンテンツの外（ヘッダ）に記録されている。
【０１４４】
図２５は、コンテンツを記録媒体に記録する場合のファイルフォーマットのより詳細な構成を表している。この例においては、コンテンツID（CID）、ライセンスID（LID）、URL、およびウォーターマーク（WM）を含むヘッダが記録されている他、EKB、コンテンツキーKcをルートキーKRで暗号化したデータ（Enc（KR，Kc））、証明書（Cert）、ヘッダに基づき生成されたデジタル署名（Sig（Header））、コンテンツをコンテンツキーKcで暗号化したデータ（Enc（Kc，Content））、メタデータ（Meta Data）およびマーク(Mark)が記録されている。
【０１４５】
ウォーターマークは、コンテンツの内部に埋め込まれているものであるが、図２４と図２５に示されるように、コンテンツの内部とは別に、ヘッダ内に配置するようにすることで、ウォーターマークとしてコンテンツに埋め込まれている情報を迅速に、かつ簡単に検出することが可能となる。従って、そのコンテンツを、コピーすることができるか否かを、迅速に判定することができる。
【０１４６】
なお、メタデータは、例えば、ジャケット、写真、歌詞等のデータを表す。マークについては、図３１を参照して後述する。
【０１４７】
図２６は、証明書としての公開鍵証明書の例を表している。公開鍵証明書は、通常、公開鍵暗号方式における認証局（CA：Certificate Authority）が発行する証明書であり、ユーザが、認証局に提出した自己のIDや公開鍵などに、認証局が有効期限等の情報を付加し、さらに、認証局によるデジタル署名を付加して作成される。この発明においては、ライセンスサーバ４（またはコンテンツサーバ３）が、証明書と秘密鍵、従って公開鍵も発行するので、ユーザは、ユーザID、パスワード等をライセンスサーバ４に提供し登録処理を行うことによって、この公開鍵証明書を得ることができる。
【０１４８】
図２６における公開鍵証明書は、証明書のバージョン番号、ライセンスサーバ４が証明書の利用者（ユーザ）に対して割りつける証明書の通し番号、デジタル署名に用いたアルゴリズム、およびパラメータ、認証局（ライセンスサーバ４）の名前、証明書の有効期限、証明書利用者のID（ノードIDまたはリーフID）、並びに証明書利用者の公開鍵が、メッセージとして含まれている。さらに、このメッセージには、認証局としてのライセンスサーバ４により作成されたデジタル署名が付加されている。このデジタル署名は、メッセージに対してハッシュ関数を適用して生成されたハッシュ値に基づいて、ライセンスサーバ４の秘密鍵を用いて生成されたデータである。
【０１４９】
ノードIDまたはリーフIDは、例えば、図１２の例の場合、デバイス０であれば「００００」とされ、デバイス１でれば「０００１」とされ、デバイス１５であれば「１１１１」とされる。このようなIDに基づいて、そのデバイス（エンティティ）がツリー構成のどの位置（リーフまたはノード）に位置するエンティティであるのかが識別される。
【０１５０】
このように、コンテンツを利用するのに必要なライセンスを、コンテンツとは分離して配布するようにすることにより、コンテンツの配布が自由に行われることになる。任意の方法、あるいは経路で入手されたコンテンツは、一元的に取り扱うことが可能である。
【０１５１】
また、ファイルフォーマットを図２５に示されるように構成することで、そのフォーマットのコンテンツを、インターネットを介して配信する場合は勿論、SDMI（Secure Digital Music Initiative）機器に提供する場合においても、コンテンツの著作権を管理することが可能となる。
【０１５２】
さらに、例えば、図２７に示されるように、コンテンツが記録媒体を介して提供されたとしても、インターネット２を介して提供されたとしても、同様の処理により、SDMI（Secure Digital Music Initiative）機器としての所定のPD（Portable Device）等に、チェックアウトしたりすることが可能となる。
【０１５３】
次に、図２８のフローチャートを参照して、クライアント１が他のクライアント（例えば、PD）に対してコンテンツをチェックアウトする場合の処理について説明する。
【０１５４】
最初に、ステップＳ１９１において、CPU２１は、コンテンツにデジタル署名が付加されているか否かを判定する。デジタル署名が付加されていると判定された場合、ステップＳ１９２に進み、CPU２１は、証明書を抽出し、認証局（ライセンスサーバ４）の公開鍵で検証する処理を実行する。すなわち、クライアント１は、ライセンスサーバ４からライセンスサーバ４の秘密鍵に対応する公開鍵を取得し、その公開鍵で公開鍵証明書に付加されているデジタル署名を復号する。図２６を参照して説明したように、デジタル署名は、認証局（ライセンスサーバ４）の秘密鍵に基づいて生成されており、ライセンスサーバ４の公開鍵を用いて復号することができる。さらに、CPU２１は、証明書のメッセージ全体に対してハッシュ関数を適用してハッシュ値を演算する。そしてCPU２１は、演算されたハッシュ値と、デジタル署名を復号して得られたハッシュ値とを比較し、両者が一致すれば、メッセージは改竄されたものではないと判定する。両者が一致しない場合には、この証明書は、改竄されたものであるということになる。
【０１５５】
そこで、ステップＳ１９３において、CPU２１は、証明書が改竄されていないか否かを判定し、改竄されていないと判定された場合、ステップＳ１９４に進み、証明書をEKBで検証する処理を実行する。この検証処理は、証明書に含まれるリーフID（図２６）に基づいて、EKBをたどることができるか否かを調べることにより行われる。この検証について、図２９と図３０を参照して説明する。
【０１５６】
いま、図２９に示されるように、例えば、リーフキーＫ１００１を有するデバイスがリボークされたデバイスであるとする。このとき、図３０に示されるようなデータ（暗号化キー）とタグを有するEKBが、各デバイス（リーフ）に配布される。このEKBは、図２９におけるデバイス「１００１」をリボークするために、キーKR,Ｋ１,Ｋ１０,Ｋ１００を更新するEKBとなっている。
【０１５７】
リボークデバイス「１００１」以外の全てのリーフは、更新されたルートキーＫ（ｔ）Ｒを取得することができる。すなわち、ノードキーＫ０の下位に連なるリーフは、更新されていないノードキーＫ０を、デバイス内に保持しているので、暗号化キーEnc（Ｋ０，Ｋ（ｔ）Ｒ）を、キーＫ０によって復号することで、更新ルートキーＫ（ｔ）Ｒを取得することができる。
【０１５８】
また、ノードキーＫ１１以下のリーフは、更新されていないノードキーＫ１１を用いて、Enc（Ｋ１１，Ｋ（ｔ）１）をノードキーＫ１１によって復号することで、更新ノードキーＫ（ｔ）１を取得することができる。さらに、Enc（Ｋ（ｔ）１，Ｋ（ｔ）Ｒ）をノードキーＫ（ｔ）１によって復号することで、更新ルートキーＫ（ｔ）Ｒを取得することが可能となる。ノードキーＫ１０１の下位リーフについても、同様に更新ルートキーＫ（ｔ）Ｒを取得することが可能である。
【０１５９】
さらに、リボークされていないリーフキーＫ１０００を有するデバイス「１０００」は、自己のリーフキーＫ１０００でEnc（Ｋ１０００，Ｋ（ｔ）１００）を復号して、ノードキーＫ（ｔ）１００を取得することができ、これを用いてさらに、上位のノードキーを順次復号し、更新ルートキーＫ（ｔ）Ｒを取得することができる。
【０１６０】
これに対して、リボークされたデバイス「１００１」は、自己のリーフの１段上の更新ノードキーＫ（ｔ）１００を、EKB処理により取得できないので、結局、更新ルートキーＫ（ｔ）Ｒを取得することができない。
【０１６１】
リボークされていない正当なデバイス（クライアント１）には、図３０に示されるデータとタグを有するEKBが、ライセンスサーバ４から配信され、格納されている。
【０１６２】
そこで、各クライアントは、そのタグを利用して、EKB追跡処理を行うことができる。このEKB追跡処理は、上位のルートキーからキー配信ツリーをたどれるか否かを判定する処理である。
【０１６３】
例えば、図２９のリーフ「１００１」のID（リーフID）である「１００１」を、「１」「０」「０」「１」の４ビットとして把握し、最上位ビットから順次、下位ビットに従って、ツリーをたどることができるか否かが判定される。この判定では、ビットが１であれば、右側に進み、０であれば、左側に進む処理が行われる。
【０１６４】
ID「１００１」の最上位ビットが１であるから、図２９のルートキーKRから右側に進む。EKBの最初のタグ（番号０のタグ）は、０：｛０，０｝であり、両枝にデータを有するものであると判定される。この場合、右側に進むことができるので、ノードキーＫ１にたどり着くことができる。
【０１６５】
次に、ノードキーＫ１の下位のノードに進む。ID「１００１」の２番目のビットは０であるから左側に進む。番号１のタグは、左側のノードキーＫ０の下位のデータの有無を表すものであり、ノードキーＫ１の下位のデータの有無を示すタグは、番号２のタグである。このタグは、図３０に示されるように、２：｛０，０｝であり、両枝にデータを有するものとされる。従って、左側に進み、ノードキーＫ１０にたどり着くことができる。
【０１６６】
さらに、ID「１００１」の３番目のビットは０であり、左側に進む。このとき、Ｋ１０の下位のデータの有無を示すタグ（番号３のタグ）は、３：｛０，０｝であり、両枝にデータを有するものと判定される。そこで、左側に進み、ノードキーＫ１００にたどり着くことができる。
【０１６７】
さらに、ID「１００１」の最下位ビットは１であり、右側に進む。番号４のタグは、ノードキーＫ１１に対応するものであり、Ｋ１００の下位のデータの符号を表すタグは、番号５のタグである。このタグは、５：｛０，１｝である。従って、右側には、データが存在しないことになる。その結果、ノード「１００１」にはたどり着けないことになり、ID「１００１」のデバイスは、EKBによる更新ルートキーを取得できないデバイス、すなわちリボークデバイスであると判定される。
【０１６８】
これに対して、例えば、リーフキーＫ１０００を有するデバイスIDは、「１０００」であり、上述した場合と同様に、EKB内のタグに基づくEKB追跡処理を行うと、ノード「１０００」にたどり着くことができる。従って、ID「Ｉ０００」のデバイスは、正当なデバイスであると判定される。
【０１６９】
図２８に戻って、CPU２１は、ステップＳ１９４の検証処理に基づき、証明書がリボークされていないか否かをステップＳ１９５で判定し、証明書がリボークされていない場合には、ステップＳ１９６に進み、デジタル署名を証明書に含まれる公開鍵で検証する処理を実行する。
【０１７０】
すなわち、図２６に示されるように、証明書には、証明書利用者（コンテンツ作成者）の公開鍵が含まれており、この公開鍵を用いて、図２５に示される署名（Sig（Header））が検証される。すなわち、この公開鍵を用いて、デジタル署名Sig（Header）を復号して得られたデータ（ハッシュ値）と、図２５に示されるHeaderにハッシュ関数を適用して演算されたハッシュ値とを比較することで、両者が一致していれば、Headerが改竄されていないことを確認することができる。これに対して、両者が一致しなければ、Headerは改竄されているということになる。
【０１７１】
ステップＳ１９７において、CPU２１は、Headerが改竄されているか否かを判定し、改竄されていなければ、ステップＳ１９８に進み、ウォーターマークを検証する。ステップＳ１９９において、CPU２１は、ウォーターマークの検証の結果、チェックアウトが可能であるか否かを判定する。チェックアウトが可能である場合には、ステップＳ２００に進み、CPU２１は、チェックアウトを実行する。すなわち、チェックアウト先のクライアント１に対してコンテンツを転送し、コピーさせる。
【０１７２】
ステップＳ１９１において、デジタル署名が存在しないと判定された場合、ステップＳ１９３において、証明書が改竄されていると判定された場合、ステップＳ１９５において、証明書をEKBで検証することができなかったと判定された場合、ステップＳ１９７において、デジタル署名の検証の結果、ヘッダが改竄されていると判定された場合、または、ステップＳ１９９において、ウォーターマークにチェックアウトの禁止が記述されていると判定された場合、ステップＳ２０１に進み、エラー処理が実行される。すなわち、この場合には、チェックアウトが禁止される。
【０１７３】
このように、証明書と秘密鍵をライセンスサーバ４からユーザに配布し、コンテンツ作成時に、デジタル署名を付加することにより、コンテンツの作成者の真正を保証することが可能となる。これにより、不正なコンテンツの流通を抑制することができる。
【０１７４】
さらに、ウォーターマークをコンテンツ作成時に検出し、その情報をデジタル署名に付することで、ウォーターマーク情報の改竄を防止し、コンテンツの真正を保証することができる。
【０１７５】
その結果、一度作成されたコンテンツは、どのような形態で配信されたとしても、元のコンテンツの真正を保証することが可能となる。
【０１７６】
さらに、コンテンツは、使用条件を有さず、使用条件は、ライセンスに付加されているので、ライセンス内の使用条件を変更することで、それに関係するコンテンツの使用条件を一斉に変更することが可能となる。
【０１７７】
次に、マークの利用方法について説明する。本発明においては、上述したように、使用条件は、コンテンツではなく、ライセンスに付加される。しかしながら、コンテンツによって、使用状況が異なる場合がある。そこで、本発明においては、図２５に示されるように、コンテンツにマークが付加される。
【０１７８】
ライセンスとコンテンツは、１対多の関係にあるため、コンテンツの個々の使用状況をライセンスの使用条件にのみ記述するのは困難となる。そこで、このように、コンテンツに使用状況を付加することにより、ライセンスでの管理をしながらも、個々のコンテンツを管理することが可能となる。
【０１７９】
このマークには、例えば、図３１に示されるように、ユーザのID（リーフID）、所有権フラグ、使用開始時刻、およびコピー回数等が記述される。
【０１８０】
さらに、マークには、リーフID、所有権フラグ、使用開始時刻、およびコピー回数等のメッセージに基づいて生成されたデジタル署名が付加される。
【０１８１】
所有権フラグは、例えば、所定の期間だけコンテンツを使用可能とするライセンスを、そのまま買い取ったような場合（使用期間を永久に変更したような場合）に付加される。使用開始時刻は、コンテンツの使用を所定の期間内に開始した場合に記述される。例えば、コンテンツをダウンロードする時期が制限されているような場合において、その期限内にダウンロードが行われたようなとき、その実際にコンテンツをダウンロードした日時がここに記述される。これにより、期間内での有効な使用であることが、証明される。
【０１８２】
コピー回数には、それまでにそのコンテンツをコピーした回数が履歴（ログ）として記述される。
【０１８３】
次に、図３２のフローチャートを参照して、ユーザがライセンスを買い取った場合に、マークを付加する処理について、マークをコンテンツに付加する例として説明する。
【０１８４】
最初に、ステップＳ２２１において、CPU２１は、入力部２６からのユーザの指令に基づいて、インターネット２を介して、ライセンスサーバ４にアクセスする。
【０１８５】
ステップＳ２２２において、CPU２１は、ユーザからの入力部２６を介しての入力を取り込み、その入力に対応してライセンスサーバ４に対してライセンスの買い取りを要求する。
【０１８６】
この要求に対応して、図３３のフローチャートを参照して後述するように、ライセンスサーバ４は、ライセンスを買い取るために必要な対価を提示してくる（図３３のステップＳ２４２）。そこで、ステップＳ２２３において、クライアント１のCPU２１は、ライセンスサーバ４からの対価の提示を受け取ると、これを出力部２７に出力し、表示させる。
【０１８７】
ユーザは、この表示に基づいて、提示された対価を了承するか否かを判断し、その判断結果に基づいて、入力部２６からその判断結果を入力する。
【０１８８】
CPU２１は、ステップＳ２２４において、入力部２６からの入力に基づいて、ユーザが提示された対価を了承したか否かを判定し、了承したと判定した場合には、ステップＳ２２５に進み、ライセンスサーバ４に了承を通知する処理を実行する。
【０１８９】
この了承通知を受信すると、ライセンスサーバ４は、対価の買い取りを表す情報、すなわち所有権フラグを記述したマークを送信してくる（図３３のステップＳ２４４）。そこで、ステップＳ２２６において、クライアント１のCPU２１は、ライセンスサーバ４からのマークを受け取ると、ステップＳ２２７において、受け取ったマークをコンテンツに埋め込む処理を実行する。すなわち、これにより、買い取られたライセンスに対応するコンテンツのマークとして、図３１に示されるような所有権フラグが記述されたマークがコンテンツに対応して記録されることになる。また、このとき、CPU２１は、メッセージが更新されたことになるので、デジタル署名（図２５）も更新し、記録媒体に記録する。
【０１９０】
ステップＳ２２４において、ライセンスサーバ４から提示された対価が了承されていないと判定された場合、ステップＳ２２８に進み、CPU２１は、提示された対価を了承しないことをライセンスサーバ４に通知する。
【０１９１】
このようなクライアント１の処理に対応して、ライセンスサーバ４は、図３３のフローチャートに示す処理を実行する。
【０１９２】
すなわち、最初に、ステップＳ２４１において、ライセンスサーバ４のCPU２１は、クライアント１からライセンス買い取りの要求が送信されてくると（図３２のステップＳ２２２）、 これを受け取り、ステップＳ２４２において、対象とされているライセンスの買い取りに必要な対価を記憶部２８から読み出し、これをクライアント１に送信する。
【０１９３】
上述したように、このようにして提示された対価に対して、クライアント１から提示された対価を了承するか否かの通知が送信されてくる。
【０１９４】
そこで、ステップＳ２４３において、ライセンスサーバ４のCPU２１は、クライアント１から了承通知を受信したか否かを判定し、了承通知を受信したと判定した場合、ステップＳ２４４に進み、対象とされるライセンスの買い取りを表すメッセージを含むマークを生成し、自分自身の秘密鍵で、デジタル署名を付加して、クライアント１に送信する。このようにして送信されたマークは、上述したように、クライアント１の記憶部２８において、対応するコンテンツに記録される（図３２のステップＳ２２７）。
【０１９５】
ステップＳ２４３において、クライアント１から了承通知が受信されていないと判定された場合、ステップＳ２４４の処理はスキップされる。すなわち、この場合には、ライセンスの買い取り処理が最終的に行われなかったことになるので、マークは送信されない。
【０１９６】
図３４は、ステップＳ２４４において、ライセンスサーバ４からクライアント１に対して送信されるマークの構成例を表している。この例においては、そのユーザのリーフID、所有権フラグ（Own）、並びにリーフIDと所有権フラグを、ライセンスサーバ４の秘密鍵Ｓに基づいて生成されたデジタル署名Sigs（LeafID, Own）により、マークが構成されている。
【０１９７】
なお、このマークは、特定のユーザの特定のコンテンツに対してのみ有効なものであるので、対象とされるコンテンツがコピーされた場合には、そのコピーされたコンテンツに付随するマークは無効とされる。
【０１９８】
このようにして、コンテンツとライセンスを分離し、使用条件をライセンスに対応させる場合においても、個々のコンテンツの使用状況に応じたサービスを実現することが可能となる。
【０１９９】
次に、グルーピングについて説明する。複数の機器やメディアを適当に集め、その１つの集合内においては、コンテンツを自由に授受することができるようにすることは、グルーピングと称される。通常、このグルーピングは、個人の所有する機器やメディアにおいて行われる。このグルーピングは、従来、グループ毎にグループキーを設定する等して行われていたが、グループ化する複数の機器やメディアに、同一のライセンスを対応づけることにより、容易にグルーピングすることが可能となる。
【０２００】
また、各機器を予め登録しておくことで、グルーピングすることも可能である。この場合のグルーピングについて、以下に説明する。
【０２０１】
この場合、ユーザは、グルーピング対象とされる機器の証明書を予めサーバに登録しておく必要がある。この証明書の登録処理について、図３５と図３６のフローチャートを参照して説明する。
【０２０２】
最初に、図３５のフローチャートを参照して、クライアント（グルーピング対象となる機器）の証明書の登録処理について説明する。ステップＳ２６１において、クライアント１のCPU２１は、グルーピングの対象とされる機器としての自分自身の証明書を作成する。この証明書には、自分自身の公開鍵が含まれる。
【０２０３】
次に、ステップＳ２６２に進み、CPU２１は、ユーザの入力部２６からの入力に基づいて、コンテンツサーバ３にアクセスし、ステップＳ２６３において、ステップＳ２６１の処理で作成された証明書をコンテンツサーバ３に送信する処理を実行する。
【０２０４】
なお、証明書としては、ライセンスサーバ４から受信したものを、そのまま使用することもできる。
【０２０５】
以上の処理は、グルーピング対象とされる全ての機器が行う。
【０２０６】
次に、図３６のフローチャートを参照して、図３５のクライアント１の証明書の登録処理に対応して行われるコンテンツサーバ３の証明書の登録処理について説明する。
【０２０７】
最初に、ステップＳ２７１において、コンテンツサーバ３のCPU２１は、クライアント１から送信されてきた証明書を受信すると、ステップＳ２７２において、その証明書を記憶部２８に登録する。
【０２０８】
以上の処理が、グループ対象とされる機器毎に行われる。その結果、コンテンツサーバ３の記憶部２８には、例えば、図３７に示されるように、グループ毎に、そのグループを構成するデバイスの証明書が登録される。
【０２０９】
図３７に示される例では、グループ１の証明書として、証明書Ｃ１１乃至Ｃ１４が登録されている。これらの証明書Ｃ１１乃至Ｃ１４には、対応する公開鍵ＫP11乃至ＫP14が含まれている。
【０２１０】
同様に、グループ２の証明書として、証明書Ｃ２１乃至Ｃ２３が登録されており、これらは対応する公開鍵ＫP21乃至ＫP23が含まれている。
【０２１１】
以上のようなグループを構成する各機器毎に、その証明書が登録された状態において、ユーザからそのグループに属する機器にコンテンツの提供が要求されると、コンテンツサーバ３は、図３８のフローチャートに示す処理を実行する。
【０２１２】
最初に、ステップＳ２８１において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されている証明書のうち、そのグループに属する証明書を検証する処理を実行する。
【０２１３】
この検証処理は、図２９と図３０を参照して説明されたように、各機器の証明書に含まれるリーフIDに基づいて、タグを利用してEKBをたどることで行われる。EKBは、コンテンツサーバ３にも、ライセンスサーバ４から配布されている。この検証処理により、リボークされている証明書は除外される。
【０２１４】
ステップＳ２８２において、コンテンツサーバ３のCPU２１は、ステップＳ２８１の検証処理の結果、有効とされた証明書を選択する。そして、ステップＳ２８３において、CPU２１は、ステップＳ２８２の処理で選択された各機器の証明書の各公開鍵でコンテンツ鍵を暗号化する。ステップＳ２８４において、CPU２１は、対象とされるグループの各機器に、ステップＳ２８３の処理で暗号化されたコンテンツ鍵をコンテンツとともに送信する。
【０２１５】
図３７に示されるグループ１のうち、例えば、証明書Ｃ１４がリボークされているとすると、ステップＳ２８３の処理で、例えば、図３９に示されるような暗号化データが生成される。
【０２１６】
すなわち、図３９の例においては、コンテンツ鍵Kcが、証明書Ｃ１１の公開鍵ＫP11、証明書Ｃ１２の公開鍵ＫP12、または証明書Ｃ１３の公開鍵ＫP13により、暗号化されている。
【０２１７】
コンテンツサーバ３の図３８に示されるような処理に対応して、コンテンツの提供を受ける各グループの機器（クライアント）は、図４０のフローチャートに示す処理を実行する。
【０２１８】
最初に、ステップＳ２９１において、クライアント１のCPU２１は、コンテンツサーバ３が図３８のステップＳ２８４の処理で送信してきたコンテンツを、コンテンツ鍵とともに受信する。コンテンツは、コンテンツ鍵Kcにより、暗号化されており、コンテンツ鍵は上述したように、各機器が保持する公開鍵により暗号化されている（図３９）。
【０２１９】
そこで、ステップＳ２９２において、CPU２１は、ステップＳ２９１の処理で受信した自分宛のコンテンツ鍵を、自分自身の秘密鍵で復号し、取得する。そして、取得したコンテンツ鍵を用いてコンテンツの復号処理が行われる。
【０２２０】
例えば、図３９の例に示される証明書Ｃ１１に対応する機器は、公開鍵ＫP11に対応する自分自身の秘密鍵を用いて、コンテンツ鍵Kcの暗号を復号し、コンテンツ鍵Kcを取得する。そして、コンテンツ鍵Kcを用いて、コンテンツがさらに復号される。
【０２２１】
同様の処理は、証明書Ｃ１２，Ｃ１３に対応する機器においても行われる。リボークされている証明書Ｃ１４の機器は、自分自身の公開鍵を用いて暗号化されたコンテンツ鍵Kcがコンテンツに付随して送られてこないので、コンテンツ鍵Kcを復号することができず、従って、コンテンツ鍵Kcを用いてコンテンツを復号することができない。
【０２２２】
以上においては、コンテンツキー（すなわちコンテンツ）に対してグルーピングを行うようにしたが、ライセンスキー（ライセンス）に対してグルーピングを行うことも可能である。
【０２２３】
以上のようにして、特別なグループキーや、後述するICV（Integrity Check Value）を用いずにグループ化が可能となる。このグループ化は、小規模のグループに適用するのに向いている。
【０２２４】
本発明においては、ライセンスもチェックアウト、あるいはチェックインしたり、ムーブしたり、コピーしたりすることが可能とされる。但し、これらの処理はSDMIで定められたルールに基づいて行われる。
【０２２５】
次に、図４１と図４２のフローチャートを参照して、このようなクライアントによるライセンスのチェックアウト処理について説明する。
【０２２６】
最初に、図４１のフローチャートを参照して他のクライアントにライセンスをチェックアウトするクライアントの処理について説明する。最初に、ステップＳ３０１において、クライアント１のCPU２１は、チェックアウト対象のライセンスのチェックアウト回数Ｎ１を読み取る。このチェックアウト回数は、図８に示される使用条件に書き込まれているので、この使用条件から読み取られる。
【０２２７】
次に、ステップＳ３０２において、CPU２１は、チェックアウト対象のライセンスの最大チェックアウト回数Ｎ２を、やはりライセンスの使用条件から読み取る。
【０２２８】
そして、ステップＳ３０３において、CPU２１は、ステップＳ３０１の処理で読み取られたチェックアウト回数Ｎ１と、ステップＳ３０２の処理で読み取られた最大チェックアウト回数Ｎ２とを比較し、チェックアウト回数Ｎ１が最大チェックアウト回数Ｎ２より大きいか否かを判定する。
【０２２９】
チェックアウト回数Ｎ１が、最大チェックアウト回数Ｎ２より小さいと判定された場合、ステップＳ３０４に進み、CPU２１は、相手側の装置（チェックアウト先のクライアント）のリーフキーを相手個々の装置から取得し、そのリーフキーを、いまチェックアウト対象とされているライセンスIDに対応して記憶部２８のチェックアウトリストに記憶させる。
【０２３０】
次に、ステップＳ３０５において、CPU２１は、ステップＳ３０１の処理で読み取られたライセンスのチェックアウト回数Ｎ１の値を１だけインクリメントする。ステップＳ３０６において、CPU２１は、ライセンスのメッセージに基づいて、ICVを演算する。このICVについては、図４６乃至図５０を参照して後述する。ICVを用いてライセンスの改竄を防止することが可能となる。
【０２３１】
次に、ステップＳ３０７において、CPU２１は、チェックアウト対象のライセンスと、ステップＳ３０６の処理で演算されたICVを、自分自身の公開鍵を用いて暗号化して、EKBおよび証明書とともに、相手側の装置に出力し、コピーさせる。さらに、ステップＳ３０８において、CPU２１は、ステップＳ３０６の処理で演算されたICVを、相手側装置のリーフキーと、ライセンスIDに対応して記憶部２８のチェックリスト中に記憶させる。
【０２３２】
ステップＳ３０３において、チェックアウト回数Ｎ１が最大チェックアウト回数Ｎ２より小さくない（例えば、等しい）と判定された場合、もはや許容される回数だけチェックアウトが行われているので、これ以上チェックアウトを行うことができない。そこで、ステップＳ３０９に進み、CPU２１は、エラー処理を実行する。すなわち、この場合、チェックアウト処理は実行されないことになる。
【０２３３】
次に、図４２のフローチャートを参照して、図４１のチェックアウト処理により、ライセンスのチェックアウトを受けるクライアントの処理について説明する。
【０２３４】
最初に、ステップＳ３２１において、相手側装置（ライセンスをチェックアウトするクライアント１）に、自分自身のリーフキーを送信する。このリーフキーは、ステップＳ３０４において、相手側のクライアントにより、ライセンスIDに対応して記憶される。
【０２３５】
次に、ステップＳ３２２において、CPU２１は、相手側のクライアント１から暗号化されたライセンスとICVが、EKBおよび証明書とともに送信されてきた場合、これを受信する。すなわち、このライセンス、ICV、EKBおよび証明書は、図４１のステップＳ３０７の処理で相手側の装置から送信されたものである。
【０２３６】
ステップＳ３２３において、CPU２１は、ステップＳ３２２の処理で受信したライセンス、ICV、EKBおよび証明書を、記憶部２８に記憶させる。
【０２３７】
以上のようにして、ライセンスのチェックアウトを受けたクライアント１は、チェックアウトを受けたそのライセンスを使用して、所定のコンテンツを再生する場合、図４３のフローチャートに示される処理を実行する。
【０２３８】
すなわち、最初に、ステップＳ３４１において、クライアント１の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 Authentication Code））となる。
【０２５６】
このようなライセンスのＭＡＣ値とＩＣＶ生成キーにハッシュ関数を適用してライセンスのインテグリティ・チェック値（ＩＣＶ）が生成される。例えばライセンス生成時に生成したＩＣＶと、新たにライセンスに基づいて生成したＩＣＶとを比較して同一のＩＣＶが得られればライセンスに改竄のないことが保証され、ＩＣＶが異なれば、改竄があったと判定される。
【０２５７】
次に、ライセンスのインテグリティ・チェック値（ＩＣＶ）生成キーであるＫｉｃｖを上述の有効化キーブロックによって送付する構成について説明する。すなわちＥＫＢによる暗号化メッセージデータをライセンスのインテグリティ・チェック値（ＩＣＶ）生成キーとした例である。
【０２５８】
図４７および図４８に複数のデバイスに共通のライセンスを送付した場合、それらのライセンスの改竄の有無を検証するためのインテグリティ・チェック値生成キーＫｉｃｖを有効化キーブロック（ＥＫＢ）によって配信する構成例を示す。図４７はデバイス０，１，２，３に対して復号可能なチェック値生成キーＫｉｃｖを配信する例を示し、図４８はデバイス０，１，２，３中のデバイス３をリボーク（排除）してデバイス０，１，２に対してのみ復号可能なチェック値生成キーＫｉｃｖを配信する例を示す。
【０２５９】
図４７の例では、更新ノードキーＫ（ｔ）００によって、チェック値生成キーＫｉｃｖを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）とともに、デバイス０，１，２，３においてそれぞれの有するノードキー、リーフキーを用いて更新されたノードキーＫ（ｔ）００を復号可能な有効化キーブロック（ＥＫＢ）を生成して配信する。それぞれのデバイスは、図４７の右側に示すように、まず、ＥＫＢを処理（復号）することにより、更新されたノードキーＫ（ｔ）００を取得し、次に、取得したノードキーＫ（ｔ）００を用いて、暗号化されたチェック値生成キーＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）を復号して、チェック値生成キーＫｉｃｖを得ることが可能となる。
【０２６０】
その他のデバイス４，５，６，７・・・は同一の有効化キーブロック（ＥＫＢ）を受信しても自身の保有するノードキー、リーフキーでは、ＥＫＢを処理して更新されたノードキーＫ（ｔ）００を取得することができないので、安全に正当なデバイスに対してのみチェック値生成キーを送付することができる。
【０２６１】
一方、図４８の例は、図１２の点線枠で囲んだグループにおいてデバイス３が、例えば鍵の漏洩によりリボーク（排除）されているとして、他のグループのメンバ、すなわち、デバイス０，１，２，に対してのみ復号可能な有効化キーブロック（ＥＫＢ）を生成して配信した例である。図４８に示す有効化キーブロック（ＥＫＢ）と、チェック値生成キー（Ｋｉｃｖ）をノードキー（Ｋ（ｔ）００）で暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）を配信する。
【０２６２】
図４８の右側には、復号手順を示してある。デバイス０，１，２は、まず、受領した有効化キーブロックから自身の保有するリーフキーまたはノードキーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００による復号によりチェック値生成キーＫｉｃｖを取得する。
【０２６３】
図１２に示す他のグループのデバイス４，５，６・・・は、この同様のデータ（ＥＫＢ）を受信したとしても、自身の保有するリーフキー、ノードキーを用いて更新ノードキー（Ｋ（ｔ）００）を取得することができない。同様にリボークされたデバイス３においても、自身の保有するリーフキー、ノードキーでは、更新ノードキー（Ｋ（ｔ）００）を取得することができず、正当な権利を有するデバイスのみがチェック値生成キーを復号して利用することが可能となる。
【０２６４】
このように、ＥＫＢを利用したチェック値生成キーの配送を用いれば、データ量を少なくして、かつ安全に正当権利者のみが復号可能としたチェック値生成キーを配信することが可能となる。
【０２６５】
このようなライセンスのインテグリティ・チェック値（ＩＣＶ）を用いることにより、ＥＫＢと暗号化ライセンスの不正コピーを排除することができる。例えば図４９Ａに示すように、ライセンスＬ１とライセンスＬ２とをそれぞれのライセンスキーを取得可能な有効化キーブロック（ＥＫＢ）とともに格納したメディア１があり、これをそのままメディア２にコピーした場合を想定する。ＥＫＢと暗号化ライセンスのコピーは可能であり、これをＥＫＢを復号可能なデバイスでは利用できることになる。
【０２６６】
図４９Ｂに示す例では、各メディアに正当に格納されたライセンスに対応付けてインテグリティ・チェック値（ＩＣＶ（Ｌ１，Ｌ２））を格納する構成とする。なお、（ＩＣＶ（Ｌ１，Ｌ２））は、ライセンスＬ１とライセンスＬ２にハッシュ関数を用いて計算されるライセンスのインテグリティ・チェック値であるＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｌ１，Ｌ２）を示している。図４９Ｂの構成において、メディア１には正当にライセンス１とライセンス２が格納され、ライセンスＬ１とライセンスＬ２に基づいて生成されたインテグリティ・チェック値（ＩＣＶ（Ｌ１，Ｌ２））が格納される。また、メディア２には正当にライセンス１が格納され、ライセンスＬ１に基づいて生成されたインテグリティ・チェック値（ＩＣＶ（Ｌ１））が格納される。
【０２６７】
この構成において、メディア１に格納された｛ＥＫＢ，ライセンス２｝をメディア２にコピーしたとすると、メディア２で、ライセンスチェック値を新たに生成すると、ＩＣＶ（Ｌ１，Ｌ２）が生成されることになり、メディア２に格納されているＫｉｃｖ（Ｌ１）と異なり、ライセンスの改竄あるいは不正なコピーによる新たなライセンスの格納が実行されたことが明らかになる。メディアを再生するデバイスにおいて、再生ステップの前ステップにＩＣＶチェックを実行して、生成ＩＣＶと格納ＩＣＶの一致を判別し、一致しない場合は、再生を実行しない構成とすることにより、不正コピーのライセンスの再生を防止することが可能となる。
【０２６８】
また、さらに、安全性を高めるため、ライセンスのインテグリティ・チェック値（ＩＣＶ）を書き換えカウンタを含めたデータに基づいて生成する構成としてもよい。すなわちＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，ｃｏｕｎｔｅｒ＋１，Ｌ１，Ｌ２，・・・）によって計算する構成とする。ここで、カウンタ（ｃｏｕｎｔｅｒ＋１）は、ＩＣＶの書き換えごとに１つインクリメントされる値として設定する。なお、カウンタ値はセキュアなメモリに格納する構成とすることが必要である。
【０２６９】
さらに、ライセンスのインテグリティ・チェック値（ＩＣＶ）をライセンスと同一メディアに格納することができない構成においては、ライセンスのインテグリティ・チェック値（ＩＣＶ）をライセンスとは別のメディア上に格納する構成としてもよい。
【０２７０】
例えば、読み込み専用メディアや通常のＭＯ等のコピー防止策のとられていないメディアにライセンスを格納する場合、同一メディアにインテグリティ・チェック値（ＩＣＶ）を格納するとＩＣＶの書き換えが不正なユーザによりなされる可能性があり、ＩＣＶの安全性が保てないおそれがある。この様な場合、ホストマシン上の安全なメディアにＩＣＶを格納して、ライセンスのコピーコントロール（例えばcheck-in/check-out、move）にＩＣＶを使用する構成とすることにより、ＩＣＶの安全な管理およびライセンスの改竄チェックが可能となる。
【０２７１】
この構成例を図５０に示す。図５０では読み込み専用メディアや通常のＭＯ等のコピー防止策のとられていないメディア２２０１にライセンス１乃至ライセンス３が格納され、これらのライセンスに関するインテグリティ・チェック値（ＩＣＶ）を、ユーザが自由にアクセスすることの許可されないホストマシン上の安全なメディア２２０２に格納し、ユーザによる不正なインテグリティ・チェック値（ＩＣＶ）の書き換えを防止した例である。このような構成として、例えばメディア２２０１を装着したデバイスが、メディア２２０１の再生を実行する際にホストマシンであるＰＣ、サーバにおいてＩＣＶのチェックを実行して再生の可否を判定する構成とすれば、不正なコピーライセンスあるいは改竄ライセンスの再生を防止できる。
【０２７２】
本発明が適用されるクライアントは、いわゆるパーソナルコンピュータ以外に、PDA（Personal Digital Assistants）、携帯電話機、ゲーム端末機などとすることができる。
【０２７３】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０２７４】
この記録媒体は、図２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk - Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０２７５】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２７６】
また、セキュリティに関連する処理を実行させるプログラムは、その処理を解析されるのを防ぐため、そのプログラム自体が暗号化されているのが望ましい。例えば、暗号処理などを行う処理については、そのプログラムをタンパーレジスタントモジュールとして構成することができる。
【０２７７】
また、コンテンツを利用許可するライセンスを特定するためにコンテンツのヘッダに記載されている情報はライセンスを一意に識別するライセンスIDでなくてもよい。上記の実施例では、ライセンスＩＤが、コンテンツの利用に必要なライセンスを特定する情報であり、あるライセンスが利用を許可するコンテンツを特定する情報であり、クライアント１からライセンス要求によって要求されるライセンスを識別する情報である。コンテンツにコンテンツのそのコンテンツに関する各種属性情報のリストが記載され、ライセンスに、そのライセンスによって利用許可されるコンテンツの条件式を記載するようにしても良い。この場合では、コンテンツに含まれる属性情報がそのコンテンツの利用を許可するライセンスを特定する情報であり、ライセンスに含まれる条件式がそのライセンスが利用を許可するコンテンツを特定する情報であり、ライセンスＩＤはライセンスを一意に識別する情報となる。このようにした場合には、一つのコンテンツに複数のライセンスを対応付けることが可能になり、ライセンスの発行を柔軟に行うことができる。
【０２７８】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０２７９】
【発明の効果】
以上の如く、本発明の情報処理装置および方法、ライセンスサーバ、並びにプログラムによれば、暗号化されたデータを自由に配布できるようにし、別途ライセンスを取得することでコンテンツを利用できるようにしたことで、コンテンツの流通を妨げることなく、著作権を保護し、適切な使用料の徴収をすることができる。
【図面の簡単な説明】
【図１】本発明を適用したコンテンツ提供システムの構成を示すブロック図である。
【図２】図１のクライアントの構成を示すブロック図である。
【図３】図１のクライアントのコンテンツのダウンロード処理を説明するフローチャートである。
【図４】図１のコンテンツサーバのコンテンツ提供処理を説明するフローチャートである。
【図５】図４のステップＳ２６におけるフォーマットの例を示す図である。
【図６】図１のクライアントのコンテンツ再生処理を説明するフローチャートである。
【図７】図６のステップＳ４３のライセンス取得処理の詳細を説明するフローチャートである。
【図８】ライセンスの構成を示す図である。
【図９】図１のライセンスサーバのライセンス提供の処理を説明するフローチャートである。
【図１０】図６のステップＳ４５におけるライセンス更新処理の詳細を説明するフローチャートである。
【図１１】図１のライセンスサーバのライセンス更新処理を説明するフローチャートである。
【図１２】キーの構成を説明する図である。
【図１３】カテゴリノードを説明する図である。
【図１４】ノードとデバイスの対応の具体例を示す図である。
【図１５】有効化キーブロックの構成を説明する図である。
【図１６】有効化キーブロックの利用を説明する図である。
【図１７】有効化キーブロックのフォーマットの例を示す図である。
【図１８】有効化キーブロックのタグの構成を説明する図である。
【図１９】 DNKを用いたコンテンツの復号処理を説明する図である。
【図２０】有効化キーブロックの例を示す図である。
【図２１】複数のコンテンツの１つのデバイスに対する割り当てを説明する図である。
【図２２】ライセンスのカテゴリを説明する図である。
【図２３】クライアントのリッピング処理を説明するフローチャートである。
【図２４】ウォーターマークの構成を説明する図である。
【図２５】コンテンツのフォーマットの例を示す図である。
【図２６】公開鍵証明書の例を示す図である。
【図２７】コンテンツの配布を説明する図である。
【図２８】クライアントのコンテンツのチェックアウト処理を説明するフローチャートである。
【図２９】タグによる有効化キーブロックをたどる例を説明する図である。
【図３０】有効化キーブロックの構成例を示す図である。
【図３１】マークの構成を説明する図である。
【図３２】クライアントのライセンス買い取り処理を説明するフローチャートである。
【図３３】ライセンスサーバのライセンス買い取り処理を説明するフローチャートである。
【図３４】マークの構成例を示す図である。
【図３５】クライアントの証明書の登録処理を説明するフローチャートである。
【図３６】コンテンツサーバの証明書登録処理を説明するフローチャートである。
【図３７】グループの証明書の例を示す図である。
【図３８】グルーピングが行われている場合におけるコンテンツサーバの処理を説明するフローチャートである。
【図３９】コンテンツキーの暗号化の例を示す図である。
【図４０】グループに属するクライアントの処理を説明するフローチャートである。
【図４１】他のクライアントにライセンスをチェックアウトするクライアントの処理を説明するフローチャートである。
【図４２】他のクライアントからライセンスのチェックアウトを受けるクライアントの処理を説明するフローチャートである。
【図４３】ライセンスのチェックアウトを受けたクライアントの再生処理を説明するフローチャートである。
【図４４】他のクライアントからライセンスのチェックインを受けるクライアントの処理を説明するフローチャートである。
【図４５】他のクライアントにライセンスをチェックインするクライアントの処理を説明するフローチャートである。
【図４６】 MACの生成を説明する図である。
【図４７】 ICV生成キーの復号処理を説明するフローチャートである。
【図４８】 ICV生成キーの他の復号処理を説明する図である。
【図４９】 ICVによるライセンスのコピーの管理を説明する図である。
【図５０】ライセンスの管理を説明する図である。
【符号の説明】
１−１，１−２ クライアント， ２ インターネット， ３ コンテンツサーバ， ４ ライセンスサーバ， ５ 課金サーバ， ２０ タイマ， ２１ CPU， ２４ 暗号化復号部， ２５ コーデック部， ２６ 入力部， ２７出力部， ２８ 記憶部， ２９ 通信部
【発明の属する技術分野】
本発明は、情報処理装置および方法、ライセンスサーバ、並びにプログラムに関し、特に、著作権者からライセンスを受けていないコンテンツが不正にコピーされ、利用されるのを防止することができるようにした、情報処理装置および方法、ライセンスサーバ、並びにプログラムに関する。
【０００２】
【従来の技術】
最近、インターネットを介して、ユーザが、自分自身が保持している音楽データを他のユーザに提供し、自分自身が保持していない音楽データを他のユーザから提供を受けるようにして、複数のユーザが無料で音楽データを交換しあうシステムが実現されている。
【０００３】
このようなシステムでは、理論的には、１つの音楽、その他のコンテンツが存在すれば、他の全てのユーザが、それを利用することが可能となり、多くのユーザがコンテンツを購入しなくなるため、コンテンツに関する著作権者は、著作物としてのコンテンツが売れないため、著作物の販売に伴い、本来受け取ることが可能な著作物の利用に関するロイヤリティを受け取る機会を失うことになる。
【０００４】
【発明が解決しようとする課題】
そこで、コンテンツの流通を妨げることなく、不正に利用されることを防止することが、社会的に要請されている。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、コンテンツが不正に利用されるのを確実に防止することができるようにするものである。
【０００６】
【課題を解決するための手段】
本発明の情報処理装置は、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可するライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含むコンテンツを記憶するコンテンツ記憶手段と、利用許可されるコンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、コンテンツを利用許可することができるライセンスがライセンス記憶手段に記憶されているか否かを判定する判定手段と、判定手段によりライセンスが記憶されていると判断されたことを条件としてコンテンツのコンテンツデータを復号する復号手段とを備え、暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定されることを特徴とする。
【０００７】
情報処理装置は更に、ライセンスサーバにライセンスを識別するためのライセンス識別情報を含むライセンス要求を送信する送信手段と、ライセンスサーバによって送信されたライセンスを受信する受信手段とを備え、受信手段により受信されたライセンスはライセンス記憶手段に記憶されるようにすることができる。
【０００８】
コンテンツデータはテキストデータ、画像データ、音声データ、動画データあるいはそれらを組み合わせたデータであり、復号手段により復号されたコンテンツデータを再生する再生手段を更に備えるようにすることができる。
【００１０】
前記鍵情報は EKB （ Enabling Key Block ）とEKB（Enabling Key Block）のルートキーによって暗号化されたコンテンツキーを含み、情報処理装置は更にデバイスノードキーを記憶するデバイスノードキー記憶手段を備え、復号手段はデバイスノードキー記憶手段に記憶されているデバイスノードキーを用いてEKB（Enabling Key Block）を復号処理し得られたルートキーを用いて復号されたコンテンツキーを用いて暗号化されたコンテンツデータを復号するようにすることができる。
【００１１】
ライセンスは更に、そのライセンスによって利用可能となるコンテンツの使用条件を示す使用条件情報を含むようにすることができる。
【００１２】
ライセンスは更に、ライセンスサーバの秘密鍵によりなされた電子署名を含むようにすることができる。
【００１３】
情報処理装置は、更に情報処理装置を識別する端末識別情報を記憶する端末識別情報記憶手段を備え、ライセンス要求は更に、端末識別情報記憶手段に記憶されている端末識別情報を含み、受信手段により受信されたライセンスは更に、端末識別情報を含み、判定手段は、ライセンスに含まれる端末識別情報と端末識別情報記憶手段に記憶されている端末識別情報とを比較し、両者が一致している場合に限り、そのライセンスをコンテンツの利用を許可できるライセンスであると判定するようにすることができる。
【００１４】
本発明の情報処理方法は、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含む前記コンテンツを記憶するコンテンツ記憶手段と、利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定する判定手段と、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置の情報処理方法であって、前記コンテンツ記憶手段が、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報と、を含むコンテンツを記憶するステップと、前記ライセンス記憶手段が、当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するステップと、前記判定手段が、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定するステップと、前記復号手段が、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号するステップとを含み、前記暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、前記ブロック鍵は、前記鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定されることを特徴とする。
【００１５】
本発明のプログラムは、コンピュータを、ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可するライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含むコンテンツを記憶するコンテンツ記憶手段と、利用許可されるコンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、コンテンツを利用許可することができるライセンスがライセンス記憶手段に記憶されているか否かを判定する判定手段と、判定手段によりライセンスが記憶されていると判断されたことを条件としてコンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置であって、暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定される情報処理装置として機能させる。
【００１６】
プログラムあるいはその一部が暗号化されているようにすることができる。
【００１７】
本発明のライセンスサーバは、コンテンツの利用を許可するライセンスを発行するライセンスサーバにおいて、当該ライセンスによって利用許可されるコンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含むライセンスを記憶するライセンス記憶手段と、情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信する受信手段と、ライセンス要求に含まれるライセンス識別情報に対応するライセンスをライセンス記憶手段から抽出する抽出手段と、抽出手段により抽出されたライセンスに端末識別情報を付加する処理手段と、ライセンスサーバの秘密鍵を用いて、処理手段により端末識別情報を付加されたライセンスに電子署名を付加する署名手段と、署名手段により署名されたライセンスをライセンス要求を送信した情報処理装置に送信する送信手段とを備え、ライセンスによって利用許可されるコンテンツは、暗号化されて情報処理装置に記憶され、暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定され、コンテンツキーは、端末識別情報に対応するデバイスノードキー基づいて特定されることを特徴とする。
【００１８】
本発明の情報処理方法は、当該ライセンスによって利用許可されるコンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含むライセンスを記憶するステップと、情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信するステップと、ライセンス要求に含まれるライセンス識別情報に対応するライセンスをライセンス記憶手段から抽出するステップと、抽出手段により抽出されたライセンスに端末識別情報を付加するステップと、ライセンスサーバの秘密鍵を用いて、処理手段により端末識別情報を付加されたライセンスに電子署名を付加するステップと、署名手段により署名されたライセンスをライセンス要求を送信した情報処理装置に送信するステップとを含み、ライセンスによって利用許可されるコンテンツは、暗号化されて情報処理装置に記憶され、暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、ブロック鍵は、暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、シードとをハッシュ関数を用いて演算することにより生成され、前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックのイニシャルベクトルとして設定され、コンテンツキーは、端末識別情報に対応するデバイスノードキー基づいて特定されることを特徴とする。
【００１９】
本発明の情報処理装置、情報処理方法、並びにプログラムでは、ライセンスを保持していることを条件としてコンテンツを復号し、利用可能にする。
【００２０】
本発明のライセンスサーバ、並びに情報処理方法では、特定の情報処理装置でのみ有効なライセンスを発行する。
【００２１】
【発明の実施の形態】
図１は、本発明を適用したコンテンツ提供システムの構成を示している。インターネット２には、クライアント１−１，１−２（以下、これらのクライアントを個々に区別する必要がない場合、単にクライアント１と称する）が接続されている。この例においては、クライアントが２台のみ示されているが、インターネット２には、任意の台数のクライアントが接続される。
【００２２】
また、インターネット２には、クライアント１に対してコンテンツを提供するコンテンツサーバ３、コンテンツサーバ３が提供するコンテンツを利用するのに必要なライセンスをクライアント１に対して付与するライセンスサーバ４、およびクライアント１がライセンスを受け取った場合に、そのクライアント１に対して課金処理を行う課金サーバ５が接続されている。
【００２３】
これらのコンテンツサーバ３、ライセンスサーバ４、および課金サーバ５も、任意の台数、インターネット２に接続される。
【００２４】
図２はクライアント１の構成を表している。
【００２５】
図２において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。タイマ２０は、計時動作を行い、時刻情報をCPU２１に供給する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００２６】
暗号化復号部２４は、コンテンツデータを暗号化するとともに、既に暗号化されているコンテンツデータを復号する処理を行う。コーデック部２５は、例えば、ATRAC（Adaptive Transform Acoustic Coding）３方式などでコンテンツデータをエンコードし、入出力インタフェース３２を介してドライブ３０に接続されている半導体メモリ４４に供給し、記録させる。あるいはまた、コーデック部２５は、ドライブ３０を介して半導体メモリ４４より読み出した、エンコードされているデータをデコードする。
【００２７】
半導体メモリ４４は、例えば、メモリスティック（商標）などにより構成される。
【００２８】
CPU２１、ROM２２、RAM２３、暗号化復号部２４、およびコーデック部２５は、バス３１を介して相互に接続されている。このバス３１にはまた、入出力インタフェース３２も接続されている。
【００２９】
入出力インタフェース３２には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、インターネット２を介しての通信処理を行う。通信部２９はまた、他のクライアントとの間で、アナログ信号またはデジタル信号の通信処理を行う。
【００３０】
入出力インタフェース３２にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
【００３１】
なお、図示は省略するが、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５も、図２に示したクライアント１と基本的に同様の構成を有するコンピュータにより構成される。そこで、以下の説明においては、図２の構成は、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５などの構成としても引用される。
【００３２】
次に、図３のフローチャートを参照して、クライアント１がコンテンツサーバ３からコンテンツの提供を受ける処理について説明する。
【００３３】
ユーザが、入力部２６を操作することでコンテンツサーバ３に対するアクセスを指令すると、CPU２１は、ステップＳ１において、通信部２９を制御し、インターネット２を介してコンテンツサーバ３にアクセスさせる。ステップＳ２において、ユーザが、入力部２６を操作して、提供を受けるコンテンツを指定すると、CPU２１は、この指定情報を受け取り、通信部２９から、インターネット２を介してコンテンツサーバ３に、指定されたコンテンツを通知する。図４のフローチャートを参照して後述するように、この通知を受けたコンテンツサーバ３は、暗号化されたコンテンツデータを送信してくるので、ステップＳ３において、CPU２１は、通信部２９を介して、このコンテンツデータを受信すると、ステップＳ４において、その暗号化されているコンテンツデータを記憶部２８を構成するハードディスクに供給し、記憶させる。
【００３４】
次に、図４のフローチャートを参照して、クライアント１の以上の処理に対応するコンテンツサーバ３のコンテンツ提供処理について説明する。なお、以下の説明において、図２のクライアント１の構成は、コンテンツサーバ３の構成としても引用される。
【００３５】
ステップＳ２１において、コンテンツサーバ３のCPU２１は、インターネット２から通信部２９を介してクライアント１よりアクセスを受けるまで待機し、アクセスを受けたと判定したとき、ステップＳ２２に進み、クライアント１から送信されてきたコンテンツを指定する情報を取り込む。このコンテンツを指定する情報は、クライアント１が、図３のステップＳ２において通知してきた情報である。
【００３６】
ステップＳ２３において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されているコンテンツデータの中から、ステップＳ２２の処理で取り込まれた情報で指定されたコンテンツを読み出す。CPU２１は、ステップＳ２４において、記憶部２８から読み出されたコンテンツデータを、暗号化復号部２４に供給し、コンテンツキーKcを用いて暗号化させる。
【００３７】
記憶部２８に記憶されているコンテンツデータは、コーデック部２５により、既にATRAC３方式によりエンコードされているので、このエンコードされているコンテンツデータが暗号化されることになる。
【００３８】
なお、もちろん、記憶部２８に予め暗号化した状態でコンテンツデータを記憶させることができる。この場合には、ステップＳ２４の処理は省略することが可能である。
【００３９】
次に、ステップＳ２５において、コンテンツサーバ３のCPU２１は、暗号化したコンテンツデータを伝送するフォーマットを構成するヘッダに、暗号化されているコンテンツを復号するのに必要なキー情報（図５を参照して後述するEKBとKEKBC（Kc））と、コンテンツを利用するのに必要なライセンスを識別するためのライセンスIDを付加する。そして、ステップＳ２６において、コンテンツサーバ３のCPU２１は、ステップＳ２４の処理で暗号化したコンテンツと、ステップＳ２５の処理でキーとライセンスIDを付加したヘッダとをフォーマット化したデータを、通信部２９から、インターネット２を介して、アクセスしてきたクライアント１に送信する。
【００４０】
図５は、このようにして、コンテンツサーバ３からクライアント１にコンテンツが供給される場合のフォーマットの構成を表している。同図に示されるように、このフォーマットは、ヘッダ（Header）とデータ（Data）とにより構成される。
【００４１】
ヘッダには、コンテンツ情報（Content information）、デジタル権利管理情報（DRM（Digital Right Management） information ）、ライセンスID（License ID）、イネーブリングキーブロック（有効化キーブロック）（EKB（Enabling Key Block））および、EKBから生成されたキーKEKBCを用いて暗号化されたコンテンツキーKcとしてのデータKEKBC（Kc）が配置されている。なお、EKBについては、図１５を参照して後述する。
【００４２】
コンテンツ情報には、データとしてフォーマット化されているコンテンツデータを識別するための識別情報としてのコンテンツID（CID）、そのコンテンツのコーデックの方式などの情報が含まれている。
【００４３】
デジタル権利管理情報には、コンテンツを使用する規則および状態（Usage rules/status）と、URL（Uniform Resource Locator）が配置されている。使用規則および状態には、例えば、コンテンツの再生回数、コピー回数などが記述される。
【００４４】
URLは、ライセンスIDで規定されるライセンスを取得するときアクセスするアドレス情報であり、図１のシステムの場合、具体的には、ライセンスを受けるために必要なライセンスサーバ４のアドレスである。ライセンスIDは、データとして記録されているコンテンツを利用するとき必要とされるライセンスを識別するものである。
【００４５】
データは、任意の数の暗号化ブロック（Encryption Block）により構成される。各暗号化ブロックは、イニシャルベクトル（IV（Initial Vector））、シード（Seed）、およびコンテンツデータをキーK'cで暗号化したデータEK'c(data)により構成されている。
【００４６】
キーK'cは、次式により示されるように、コンテンツキーKcと、乱数で設定される値Seedをハッシュ関数に適用して演算された値により構成される。
【００４７】
K'c＝Hash(Kc, Seed)
【００４８】
イニシャルベクトルIVとシードSeedは、各暗号化ブロック毎に異なる値に設定される。
【００４９】
この暗号化は、コンテンツのデータを８バイト単位で区分して、８バイト毎に行われる。後段の８バイトの暗号化は、前段の８バイトの暗号化の結果を利用して行われるCBC（Cipher Block Chaining）モードで行われる。
【００５０】
CBCモードの場合、最初の８バイトのコンテンツデータを暗号化するとき、その前段の８バイトの暗号化結果が存在しないため、最初の８バイトのコンテンツデータを暗号化するときは、イニシャルベクトルIVを初期値として暗号化が行われる。
【００５１】
このCBCモードによる暗号化を行うことで、１つの暗号化ブロックが解読されたとしても、その影響が、他の暗号化ブロックにおよぶことが抑制される。
【００５２】
なお、この暗号化については、図４６を参照にして、後に詳述する。
【００５３】
また、暗号方式についてはこれに限らない。
【００５４】
以上のようにして、クライアント１は、コンテンツサーバ３からコンテンツを無料で、自由に取得することができる。従って、コンテンツそのものは、大量に、配布することが可能となる。
【００５５】
しかしながら、各クライアント１は、取得したコンテンツを利用するとき、ライセンスを保持している必要がある。そこで、図６を参照して、クライアント１がコンテンツを再生する場合の処理について説明する。
【００５６】
ステップＳ４１において、クライアント１のCPU２１は、ユーザが入力部２６を操作することで指示したコンテンツの識別情報（CID）を取得する。この識別情報は、例えば、コンテンツのタイトルや、記憶されている各コンテンツ毎に付与されている番号などにより構成される。
【００５７】
そして、CPU２１は、コンテンツが指示されると、そのコンテンツに対応するライセンスID（そのコンテンツを使用するのに必要なライセンスのID）を読み取る。このライセンスIDは、図５に示されるように、暗号化されているコンテンツデータのヘッダに記述されているものである。
【００５８】
次に、ステップＳ４２に進み、CPU２１は、ステップＳ４１で読み取られたライセンスIDに対応するライセンスが、クライアント１により既に取得され、記憶部２８に記憶されているか否かを判定する。まだ、ライセンスが取得されていない場合には、ステップＳ４３に進み、CPU２１は、ライセンス取得処理を実行する。このライセンス取得処理の詳細は、図７のフローチャートを参照して後述する。
【００５９】
ステップＳ４２において、ライセンスが既に取得されていると判定された場合、または、ステップＳ４３において、ライセンス取得処理が実行された結果、ライセンスが取得された場合、ステップＳ４４に進み、CPU２１は、取得されているライセンスは有効期限内のものであるか否かを判定する。ライセンスが有効期限内のものであるか否かは、ライセンスの内容として規定されている期限（後述する図８参照）と、タイマ２０により計時されている現在日時と比較することで判断される。ライセンスの有効期限が既に満了していると判定された場合、CPU２１は、ステップＳ４５に進み、ライセンス更新処理を実行する。このライセンス更新処理の詳細は、図１０のフローチャートを参照して後述する。
【００６０】
ステップＳ４４において、ライセンスはまだ有効期限内であると判定された場合、または、ステップＳ４５において、ライセンスが更新された場合、ステップＳ４６に進み、CPU２１は、暗号化されているコンテンツデータを記憶部２８から読み出し、RAM２３に格納させる。そして、ステップＳ４７において、CPU２１は、RAM２３に記憶された暗号化ブロックのデータを、図５のデータに配置されている暗号化ブロック単位で、暗号化復号部２４に供給し、コンテンツキーKcを用いて復号させる。
【００６１】
コンテンツキーKcを得る方法の具体例は、図１５を参照して後述するが、デバイスノードキー（DNK）（図８）を用いて、EKB（図５）に含まれるキーＫEKBCを得ることができ、そのキーＫEKBCを用いて、データＫEKBC（Kc）（図５）から、コンテンツキーKcを得ることができる。
【００６２】
CPU２１は、さらに、ステップＳ４８において、暗号化復号部２４により復号されたコンテンツデータをコーデック部２５に供給し、デコードさせる。そして、コーデック部２５によりデコードされたデータを、CPU２１は、入出力インタフェース３２から出力部２７に供給し、D/A変換させ、スピーカから出力させる。
【００６３】
次に、図７のフローチャートを参照して、図６のステップＳ４３で行われるライセンス取得処理の詳細について説明する。
【００６４】
クライアント１は、事前にライセンスサーバに登録することにより、リーフID、DNK(Device Node Key)、クライアント１の秘密鍵・公開鍵のペア、ライセンスサーバの公開鍵、及び各公開鍵の証明書を含むサービスデータを取得しておく。
【００６５】
リーフIDは、クライアント毎に割り当てられた識別情報を表し、DNKは、そのライセンスに対応するEKB（有効化キーブロック）に含まれる暗号化されているコンテンツキーKcを復号するのに必要なデバイスノードキーである（図１２を参照して後述する）。
【００６６】
最初にステップＳ６１において、CPU２１は、いま処理対象とされているライセンスIDに対応するURLを、図５に示すヘッダから取得する。上述したように、このURLは、やはりヘッダに記述されているライセンスIDに対応するライセンスを取得するときアクセスすべきアドレスである。そこで、ステップＳ６２において、CPU２１は、ステップＳ６１で取得したURLにアクセスする。具体的には、通信部２９によりインターネット２を介してライセンスサーバ４にアクセスが行われる。このとき、ライセンスサーバ４は、クライアント１に対して、購入するライセンス（コンテンツを使用するのに必要なライセンス）を指定するライセンス指定情報、並びにユーザIDとパスワードの入力を要求してくる（後述する図９のステップＳ１０２）。CPU２１は、この要求を出力部２７の表示部に表示させる。ユーザは、この表示に基づいて、入力部２６を操作して、ライセンス指定情報、ユーザID、およびパスワードを入力する。なお、このユーザIDとパスワードは、クライアント１のユーザが、インターネット２を介してライセンスサーバ４にアクセスし、事前に取得しておいたものである。
【００６７】
CPU２１は、ステップＳ６３，Ｓ６４において、入力部２６から入力されたライセンス識別情報を取り込むとともに、ユーザIDとパスワードを取り込む。CPU２１は、ステップＳ６５において、通信部２９を制御し、入力されたユーザIDとパスワードを、ライセンス指定情報及びサービスデータ（後述する）に含まれるリーフIDを含むライセンス要求をインターネット２を介してライセンスサーバ４に送信させる。
【００６８】
ライセンスサーバ４は、図９を参照して後述するように、ユーザIDとパスワード、並びにライセンス指定情報に基づいてライセンスを送信してくる（ステップＳ１０９）か、または、条件が満たされない場合には、ライセンスを送信してこない（ステップＳ１１２）。
【００６９】
ステップＳ６６において、CPU２１は、ライセンスサーバ４からライセンスが送信されてきたか否かを判定し、ライセンスが送信されてきた場合には、ステップＳ６７に進み、そのライセンスを記憶部２８に供給し、記憶させる。
【００７０】
ステップＳ６６において、ライセンスが送信されて来ないと判定した場合、CPU２１は、ステップＳ６８に進み、エラー処理を実行する。具体的には、CPU２１は、コンテンツを利用するためのライセンスが得られないので、コンテンツの再生処理を禁止する。
【００７１】
以上のようにして、各クライアント１は、コンテンツデータに付随しているライセンスIDに対応するライセンスを取得して、初めて、そのコンテンツを使用することが可能となる。
【００７２】
なお、図７のライセンス取得処理は、各ユーザがコンテンツを取得する前に、予め行っておくようにすることも可能である。
【００７３】
クライアント１に提供されるライセンスは、例えば、図８に示されるように、使用条件、リーフIDおよびを含んでいる。
【００７４】
使用条件には、そのライセンスに基づいて、コンテンツを使用することが可能な使用期限、そのライセンスに基づいて、コンテンツをダウンロードすることが可能なダウンロード期限、そのライセンスに基づいて、コンテンツをコピーすることが可能な回数（許されるコピー回数）、チェックアウト回数、最大チェックアウト回数、そのライセンスに基づいて、コンテンツをCD-Rに記録することができる権利、PD（Portable Device）にコピーすることが可能な回数、ライセンスを所有権（買い取り状態）に移行できる権利、使用ログをとる義務等を示す情報が含まれる。
【００７５】
次に、図９のフローチャートを参照して、図７のクライアント１のライセンス取得処理に対応して実行されるライセンスサーバ４のライセンス提供処理について説明する。なお、この場合においても、図２のクライアント１の構成は、ライセンスサーバ４の構成として引用される。
【００７６】
ステップＳ１０１において、ライセンスサーバ４のCPU２１は、クライアント１よりアクセスを受けるまで待機し、アクセスを受けたとき、ステップＳ１０２に進み、アクセスしてきたクライアント１に対して、ユーザIDとパスワード、並びに、ライセンス指定情報の送信を要求する。上述したようにして、クライアント１から、図７のステップＳ６５の処理で、ユーザIDとパスワード、リーフID並びにライセンス指定情報（ライセンスID）が送信されてきたとき、ライセンスサーバ４のCPU２１は、通信部２９を介してこれを受信し、取り込む処理を実行する。
【００７７】
そして、ライセンスサーバ４のCPU２１は、ステップＳ１０３において、通信部２９から課金サーバ５にアクセスし、ユーザIDとパスワードに対応するユーザの与信処理を要求する。課金サーバ５は、インターネット２を介してライセンスサーバ４から与信処理の要求を受けると、そのユーザIDとパスワードに対応するユーザの過去の支払い履歴などを調査し、そのユーザが、過去にライセンスの対価の不払いの実績があるか否かなどを調べ、そのような実績がない場合には、ライセンスの付与を許容する与信結果を送信し、不払いの実績などがある場合には、ライセンス付与の不許可の与信結果を送信する。
【００７８】
ステップＳ１０４において、ライセンスサーバ４のCPU２１は、課金サーバ５からの与信結果が、ライセンスを付与することを許容する与信結果であるか否かを判定し、ライセンスの付与が許容されている場合には、ステップＳ１０５に進み、ステップＳ１０２の処理で取り込まれたライセンス指定情報に対応するライセンスを、記憶部２８に記憶されているライセンスの中から取り出す。記憶部２８に記憶されているライセンスは、あらかじめライセンスID、バージョン、作成日時、有効期限等の情報が記述されている。ステップＳ１０６において、CPU２１は、そのライセンスに受信したリーフIDを付加する。さらに、ステップＳ１０７において、CPU２１は、ステップＳ１０５で選択されたライセンスに対応づけられている使用条件を選択する。あるいはまた、ステップＳ１０２の処理で、ユーザから使用条件が指定された場合には、その使用条件が必要に応じて、予め用意されている使用条件に付加される。CPU２１は、選択された使用条件をライセンスに付加する。
【００７９】
ステップＳ１０８において、ＣＰＵ２１はライセンスサーバの秘密鍵によりライセンスに署名し、これにより、図８に示されるような構成のライセンスが生成される。
【００８０】
次に、ステップＳ１０９に進み、ライセンスサーバ４のCPU２１は、そのライセンス（図８に示される構成を有する）を、通信部２９からインターネット２を介してクライアント１に送信させる。
【００８１】
ステップＳ１１０においてライセンスサーバ４のCPU２１は、ステップＳ１０９の処理で、いま送信したライセンス（使用条件、リーフIDを含む）を、ステップＳ１０２の処理で取り込まれたユーザIDとパスワードに対応して、記憶部２８に記憶させる。さらに、ステップＳ１１１において、CPU２１は、課金処理を実行する。具体的には、CPU２１は、通信部２９から課金サーバ５に、そのユーザIDとパスワードに対応するユーザに対する課金処理を要求する。課金サーバ５は、この課金の要求に基づいて、そのユーザに対する課金処理を実行する。上述したように、この課金処理に対して、そのユーザが支払いを行わなかったような場合には、以後、そのユーザは、ライセンスの付与を要求したとしても、ライセンスを受けることができないことになる。
【００８２】
すなわち、この場合には、課金サーバ５からライセンスの付与を不許可とする与信結果が送信されてくるので、ステップＳ１０４からステップＳ１１２に進み、CPU２１は、エラー処理を実行する。具体的には、ライセンスサーバ４のCPU２１は、通信部２９を制御してアクセスしてきたクライアント１に対して、ライセンスを付与することができない旨のメッセージを出力し、処理を終了させる。
【００８３】
この場合、上述したように、そのクライアント１はライセンスを受けることができないので、そのコンテンツを利用すること（暗号を復号すること）ができないことになる。
【００８４】
図１０は、図６のステップＳ４５におけるライセンス更新処理の詳細を表している。図１０のステップＳ１３１乃至ステップＳ１３５の処理は、図７のステップＳ６１乃至ステップＳ６５の処理と基本的に同様の処理である。ただし、ステップＳ１３３において、CPU２１は、購入するライセンスではなく、更新するライセンスのライセンスIDを取り込む。そして、ステップＳ１３５において、CPU２１は、ユーザIDとパスワードとともに、更新するライセンスのライセンスIDを、ライセンスサーバ４に送信する。
【００８５】
ステップＳ１３５の送信処理に対応して、ライセンスサーバ４は、後述するように、使用条件を提示してくる（図１１のステップＳ１５３）。そこで、クライアント１のCPU２１は、ステップＳ１３６において、ライセンスサーバ４からの使用条件の提示を受信し、これを出力部２７に出力し、表示させる。ユーザは、入力部２６を操作して、この使用条件の中から所定の使用条件を選択したり、所定の使用条件を新たに追加したりする。ステップＳ１３７でCPU２１は、以上のようにして選択された使用条件（ライセンスを更新する条件）を購入するための申し込みをライセンスサーバ４に送信する。この申し込みに対応して、後述するようにライセンスサーバ４は、最終的な使用条件を送信してくる（図１１のステップＳ１５４）。そこで、ステップＳ１３８において、クライアント１のCPU２１は、ライセンスサーバ４からの使用条件を取得し、ステップＳ１３９において、その使用条件を記憶部２８にすでに記憶されている対応するライセンスの使用条件として更新する。
【００８６】
図１１は、以上のクライアント１のライセンス更新処理に対応して、ライセンスサーバ４が実行するライセンス更新処理を表している。
【００８７】
最初に、ステップＳ１５１において、ライセンスサーバ４のCPU２１は、クライアント１からのアクセスを受けると、ステップＳ１５２において、クライアント１がステップＳ１３５で送信したライセンス指定情報をライセンス更新要求情報とともに受信する。
【００８８】
ステップＳ１５３において、CPU２１は、ライセンスの更新要求を受信すると、そのライセンスに対応する使用条件（更新する使用条件）を、記憶部２８から読み出し、クライアント１に送信する。
【００８９】
この提示に対して、上述したように、クライアント１から使用条件の購入が図１０のステップＳ１３７の処理で申し込まれると、ステップＳ１５４において、ライセンスサーバ４のCPU２１は、申し込まれた使用条件に対応するデータを生成し、ステップＳ１５４において、クライアントと１に送信する。クライアント１は、上述したように、ステップＳ１３９の処理で受信した使用条件を用いて、すでに登録されているライセンスの使用条件を更新する。
【００９０】
本発明においては、図１２に示されるように、ブロードキャストインクリプション（Broadcast Encryption）方式の原理に基づいて、デバイスとライセンスのキーが管理される。キーは、階層ツリー構造とされ、最下段のリーフ（leaf）が個々のデバイスのキーに対応する。図１２の例の場合、番号０から番号１５までの１６個のデバイスまたはライセンスに対応するキーが生成される。
【００９１】
各キーは、図中丸印で示されるツリー構造の各ノードに対応して規定される。この例では、最上段のルートノードに対応してルートキーKRが、２段目のノードに対応してキーＫ０，Ｋ１が、３段目のノードに対応してキーＫ００乃至Ｋ１１が、第４段目のノードに対応してキーＫ０００乃至キーＫ１１１が、それぞれ対応されている。そして、最下段のノードとしてのリーフ（デバイスノード）に、キーＫ００００乃至Ｋ１１１１が、それぞれ対応されている。
【００９２】
階層構造とされているため、例えば、キーＫ００１０とキー００１１の上位のキーは、Ｋ００１とされ、キーＫ０００とキーＫ００１の上位のキーは、Ｋ００とされている。以下同様に、キーＫ００とキーＫ０１の上位のキーは、Ｋ０とされ、キーＫ０とキーＫ１の上位のキーは、KRとされている。
【００９３】
コンテンツを利用するキーは、最下段のデバイスノード（リーフ）から、最上段のルートノードまでの１つのパスの各ノードに対応するキーで管理される。例えば、番号３のノード（リーフID）に対応するライセンスに基づき、コンテンツを利用するキーは、キーＫ００１１，Ｋ００１，Ｋ００，Ｋ０，KRを含むパスの各キーで管理される。
【００９４】
本発明のシステムにおいては、図１３に示されるように、図１２の原理に基づいて構成されるキーシステムで、デバイスのキーとライセンスのキーの管理が行われる。図１３の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリスティックなどの半導体メモリを使用する機器のカテゴリ、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、ライセンスを管理するシステムとして本システム（Ｔシステムと称する）が対応する。
【００９５】
すなわち、このＴシステムのノードよりさらに下の階層の２４段のノードに対応するキーにより、ライセンスが対応される。この例の場合、これにより、２24（約１６メガ）のライセンスを規定することができる。さらに、最も下側の３２段の階層により、２32（約４ギガ）のユーザ（あるいはクライアント１）を規定することができる。最下段の３２段のノードに対応するキーが、DNK（Device Node Key）を構成し、最下段のリーフに対応するIDがリーフIDとされる。
【００９６】
各デバイスやライセンスのキーは、６４（＝８＋２４＋３２）段の各ノードで構成されるパスの内の１つに対応される。例えば、コンテンツを暗号化したコンテンツキーは、対応するライセンスに割り当てられたパスを構成するノードに対応するキーを用いて暗号化される。上位の階層のキーは、その直近の下位の階層のキーを用いて暗号化され、ＥＫＢ（図１５を参照して後述する）内に配置される。最下段のＤＮＫは、ＥＫＢ内には配置されず、サービスデータに記述され、ユーザのクライアント１に与えられる。クライアント１は、ライセンスに記述されているＤＮＫを用いて、コンテンツデータとともに配布されるＥＫＢ（図１５）内に記述されている直近の上位の階層のキーを復号し、復号して得たキーを用いて、ＥＫＢ内に記述されているさらにその上の階層のキーを復号する。以上の処理を順次行うことで、クライアント１は、そのライセンスのパスに属するすべてのキーを得ることができる。
【００９７】
図１４に階層ツリー構造のカテゴリの分類の具体的な例を示す。図１４において、階層ツリー構造の最上段には、ルートキーKR２３０１が設定され、以下の中間段にはノードキー２３０２が設定され、最下段には、リーフキー２３０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーを保有する。
【００９８】
最上段から第Ｍ段目（図１３の例では、Ｍ＝８）の所定のノードがカテゴリノード２３０４として設定される。すなわち第Ｍ段目のノードの各々が特定カテゴリのデバイス設定ノードとされる。第Ｍ段の１つのノードを頂点としてＭ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとされる。
【００９９】
例えば図１４の第Ｍ段目の１つのノード２３０５にはカテゴリ［メモリスティック（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード２３０５以下が、メモリスティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義される。
【０１００】
さらに、Ｍ段から数段分下位の段をサブカテゴリノード２３０６として設定することができる。図１４の例では、カテゴリ［メモリスティック］ノード２３０５の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノード２３０６が設定されている。さらに、サブカテゴリノードである再生専用器のノード２３０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード２３０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード２３０８と、［携帯電話］ノード２３０９が設定されている。
【０１０１】
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺに、その頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
【０１０２】
このように、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
【０１０３】
例えば、図１２に示されるツリー構造において、１つのグループに含まれる４つのデバイス０，１，２，３はノードキーとして共通のキーＫ００、Ｋ０、KRを保有する。このノードキー共有構成を利用することにより、共通のコンテンツキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００自体をコンテンツキーとして設定すれば、新たな鍵送付を実行することなくデバイス０，１，２，３のみが共通のコンテンツキーの設定が可能である。また、新たなコンテンツキーＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキーＫｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【０１０４】
また、ある時点ｔにおいて、デバイス３の所有する鍵Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,KRが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキーＫ００１,Ｋ００,Ｋ０,KRを、それぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Generation）ｔの更新キーであることを示す。
【０１０５】
更新キーの配布処理ついて説明する。キーの更新は、例えば、図１５Ａに示す有効化キーブロック（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデータによって構成されるテーブルを、ネットワークを介して、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図１２に示されるようなツリー構造を構成する各リーフ（最下段のノード）に対応するデバイスに、新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Key Renewal Block）と呼ばれることもある。
【０１０６】
図１５Ａに示す有効化キーブロック（ＥＫＢ）は、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図１５Ａの例は、図１２に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図１２から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
【０１０７】
図１５ＡのＥＫＢに示されるように、ＥＫＢには複数の暗号化キーが含まれる。図１５Ａの最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーＫ００１０によってこの暗号化キーを復号し、更新ノードキーＫ（ｔ）００１を得ることができる。また、復号により得た更新ノードキーＫ（ｔ）００１を用いて、図１５Ａの下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）が復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。
【０１０８】
以下順次、図１５Ａの上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０が得られ、これを用いて、図１５Ａの上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒが得られる。
【０１０９】
一方、ノードキーＫ０００は更新する対象に含まれておらず、ノード０，１が、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。ノード０，１は、デバイスキーＫ００００，Ｋ０００１を用いて、図１５Ａの上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号することで更新ノードキーＫ（ｔ）００を取得し、以下順次、図１５Ａの上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号することで、更新ノードキーＫ（ｔ）０を得、図１５Ａの上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号することで、更新ルートキーＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新したキーＫ（ｔ）Ｒを得ることができる。
【０１１０】
なお、図１５Ａのインデックスは、図の右側の暗号化キーを復号するための復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
【０１１１】
図１２に示すツリー構造の上位段のノードキーＫ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図１５Ｂの有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
【０１１２】
図１５Ｂに示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図１２に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）が、図１５Ｂに示されるＥＫＢとともに配布される。この配布により、デバイス４など、その他のグループの機器が復号することができないデータとしての配布が可能となる。
【０１１３】
すなわち、デバイス０，１，２はＥＫＢを処理して得たキーＫ（ｔ）００を用いて暗号文を復号すれば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
【０１１４】
図１６に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と、図１５Ｂに示すＥＫＢとを記録媒体を介して受領したデバイス０の処理を示す。すなわちこの例は、ＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【０１１５】
図１６に示すように、デバイス０は、記録媒体に格納されている世代t時点のＥＫＢと、自分があらかじめ格納しているノードキーＫ０００を用いて、上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、デバイス０は、復号した更新ノードキーＫ（ｔ）００を用いて、更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
【０１１６】
図１７に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン６０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは、最新のＥＫＢを識別する機能と、コンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ６０３は、有効化キーブロック（ＥＫＢ）中のデータ部６０６の位置を示すポインタであり、タグポインタ６０４はタグ部６０７の位置、署名ポインタ６０５は署名６０８の位置を示すポインタである。
【０１１７】
データ部６０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図１６に示すような更新されたノードキーに関する各暗号化キー等を格納する。
【０１１８】
タグ部６０７は、データ部６０６に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図１８を用いて説明する。
【０１１９】
図１８では、データとして先に図１５Ａで説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図１８Ｂの表に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この例の場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはKRとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図１８Ａに示す階層ツリーに示す位置Ｐ０に対応する。次の段のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置Ｐ００に対応する。ツリー構造の所定の位置から見て、その下に、データがある場合は、タグが０、ない場合はタグが１に設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。図１８Ｂの最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）に対応する位置POの左下の位置POOにはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図１８Ｃに示すデータ列、およびタグ列が構成される。
【０１２０】
タグは、対応するデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）が、ツリー構造のどこに位置しているのかを示すために設定されるものである。データ部６０６に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）・・・は、単純に暗号化されたキーの羅列データに過ぎないが、上述したタグによってデータとして格納された暗号化キーのツリー上の位置が判別可能となる。上述したタグを用いずに、先の図１５で説明した構成のように、暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（ｔ）００）
・・・のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると、冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
【０１２１】
図１７に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Signature）６０８は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センタ（ライセンスサーバ４）、コンテンツロバイダ（コンテンツサーバ３）、決済機関（課金サーバ５）等が実行する電子署名である。ＥＫＢを受領したデバイスは、署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
【０１２２】
以上のようにして、ライセンスサーバ４から供給されたライセンスに基づいて、コンテンツサーバ３から供給されたコンテンツを利用する処理をまとめると、図１９に示されるようになる。
【０１２３】
すなわち、コンテンツサーバ３からクライアント１に対してコンテンツが提供されるとともに、ライセンスサーバ４からクライアント１にライセンスが供給される。コンテンツは、コンテンツキーKcにより、暗号化されており（Enc（Kc，Content））、コンテンツキーKcは、ルートキーKR(EKBから得られるキーであって、図５におけるキーＫEKBCに対応する)で暗号化され（Enc（KR，Kc））、EKBとともに、暗号化されたコンテンツに付加されてクライアント１に提供される。
【０１２４】
図１９の例におけるEKBには、例えば、図２０に示されるように、DNKで暗号化したルートキーKRが含まれている（Enc（DNK，KR））。従って、クライアント１は、サービスデータに含まれるDNKを利用して、EKBからルートキーKRを得ることができる。さらに、ルートキーKRを用いて、Enc（KR，Kc）からコンテンツキーKcを復号することができ、コンテンツキーKcを用いて、Enc（Kc，Content）からコンテンツを復号することができる。
【０１２５】
このように、クライアント１にDNKを個別に割り当てることにより、図１２と図１５を参照して説明した原理に従って、個々のクライアント１のリボーク（revoke）が可能になる。
【０１２６】
また、ライセンスリーフIDを付加して配布することにより、クライアント１において、サービスデータとライセンスの対応付けが行われることになり、ライセンスの不正コピーを防止することが可能になる。
【０１２７】
また、クライアント用の証明書と秘密鍵をサービスデータとして配信するようにすることで、エンドユーザも、これらを用いて不正コピーを防止可能なコンテンツを作成することが可能になる。
【０１２８】
証明書と秘密鍵の利用については、図２８のフローチャートを参照して後述する。
【０１２９】
本発明においては、図１３を参照して説明したように、カテゴリノードにライセンスを管理するＴシステムと、各種のコンテンツを利用するデバイスのカテゴリが対応づけられるので、複数のDNKを同一のデバイスに持たせることができる。その結果、異なるカテゴリのコンテンツを１つのデバイスで管理することが可能となる。
【０１３０】
図２１は、この関係を表している。すなわち、デバイスＤ１には、Ｔシステムに基づいて、DNK１が割り当てられている、コンテンツ１を利用するライセンスが記録される。同様に、このデバイスＤ１には、例えば、DNK２が割り当てられた、メモリスティックにCDからリッピングしたコンテンツ２を記録することができる。この場合、デバイスＤ１は、コンテンツ１とコンテンツ２という、異なるシステム（Ｔシステムとデバイス管理システム）により配信されたコンテンツを同時に扱うことが可能となる。新たなDNKを割り当てるとき、既に割り当てられているDNKを削除するなどして、デバイスに１個のDNKだけを対応させるようにした場合、このようなことはできない。
【０１３１】
また、図１３における、例えば、下側の３２階層の各三角形の１つ１つに、図２２に示されるライセンスカテゴリ１とライセンスカテゴリ２を割り当てることにより、同一のカテゴリ内を、サブカテゴリを利用して、コンテンツのジャンル、レーベル、販売店、配信サービス等の小さな集まりに分類して、管理することが可能となる。
【０１３２】
図２２の例においては、例えば、ライセンスカテゴリ１は、ジャズのジャンルに属し、ライセンスカテゴリ２は、ロックのジャンルに属する。ライセンスカテゴリ１には、ライセンスIDが１であるコンテンツ１とコンテンツ２を対応させ、それぞれユーザ１乃至ユーザ３に配布されている。ライセンスカテゴリ２は、ライセンスID２のコンテンツ３、コンテンツ４、およびコンテンツ５が含まれ、それぞれユーザ１とユーザ３に提供されている。
【０１３３】
このように、本発明においては、カテゴリ毎に独立したキー管理が可能になる。
【０１３４】
また、DNKを、機器やメディアに予め埋め込むのではなく、ライセンスサーバ４により、登録処理を行う際に、各機器やメディアにダウンロードするようにすることで、ユーザによるキーの購入が可能なシステムを実現することができる。
【０１３５】
コンテンツは、それが作成された後、どのような使われ方をされようとも、その使われ方に関わりなく、全ての用途において、使用可能であるのが望ましい。例えば、異なるコンテンツ配信サービス、あるいは使用条件が異なるドメインにおいても、同一のコンテンツが使えることが望ましい。本発明においては、このため、上述したように、各ユーザ（クライアント１）に、認証局としてのライセンスサーバ４から秘密鍵と、それに対応する公開鍵の証明書（certificates）が配布される。各ユーザは、その秘密鍵を用いて、署名（signature）を作成し、コンテンツに付加して、コンテンツの真正さ(integrity)を保証し、かつコンテンツの改竄防止を図ることができる。
【０１３６】
この場合の処理の例について、図２３のフローチャートを参照して説明する。図２３の処理は、ユーザがCDから再生したデータを記憶部２８に記憶させるリッピング処理を説明するものである。
【０１３７】
最初に、ステップＳ１７１において、クライアント１のCPU２１は、通信部２９を介して入力されるCDの再生データを記録データとして取り込む。ステップＳ１７２において、CPU２１は、ステップＳ１７１の処理で取り込まれた記録データにウォーターマークが含まれているか否かを判定する。このウォーターマークは、３ビットのコピー管理情報（CCI）と、１ビットのトリガ（Trigger）とにより構成され、コンテンツのデータの中に埋め込まれている。CPU２１は、ウォーターマークが検出された場合には、ステップＳ１７３に進み、そのウォーターマークを抽出する処理を実行する。ウォーターマークが存在しない場合には、ステップＳ１７３の処理はスキップされる。
【０１３８】
次に、ステップＳ１７４において、CPU２１は、コンテンツに対応して記録するヘッダのデータを作成する。このヘッダのデータは、コンテンツID、ライセンスID、ライセンスを取得するためのアクセス先を表すURL、およびウォーターマークにより構成される。
【０１３９】
次に、ステップＳ１７５に進み、CPU２１は、ステップＳ１７４の処理で作成したヘッダのデータに基づいたデジタル署名を、自分自身の秘密鍵を用いて作成する。この秘密鍵は、ライセンスサーバ４から取得したものである（図７のステップＳ６７）。
【０１４０】
ステップＳ１７６で、CPU２１は、暗号化復号部２４を制御し、コンテンツキーでコンテンツを暗号化させる。コンテンツキーは、コンテンツを取得したとき、同時に取得されたものである（図５または図１９）。
【０１４１】
次に、ステップＳ１７７において、CPU２１は、ファイルフォーマットに基づき、データを、例えば、ミニディスク等により構成される光磁気ディスク４３に記録させる。
【０１４２】
なお、記録媒体がミニディスクである場合、ステップＳ１７６において、CPU２１は、コンテンツをコーデック部２５に供給し、例えば、ATRAC３方式によりコンテンツを符号化させる。そして、符号化されたデータが暗号化復号部２４によりさらに暗号化される。
【０１４３】
図２４は、以上のようにして、記録媒体にコンテンツが記録された状態を模式的に表している。暗号化されているコンテンツ（Ｅ（At３））から抽出されたウォーターマーク（WM）が、コンテンツの外（ヘッダ）に記録されている。
【０１４４】
図２５は、コンテンツを記録媒体に記録する場合のファイルフォーマットのより詳細な構成を表している。この例においては、コンテンツID（CID）、ライセンスID（LID）、URL、およびウォーターマーク（WM）を含むヘッダが記録されている他、EKB、コンテンツキーKcをルートキーKRで暗号化したデータ（Enc（KR，Kc））、証明書（Cert）、ヘッダに基づき生成されたデジタル署名（Sig（Header））、コンテンツをコンテンツキーKcで暗号化したデータ（Enc（Kc，Content））、メタデータ（Meta Data）およびマーク(Mark)が記録されている。
【０１４５】
ウォーターマークは、コンテンツの内部に埋め込まれているものであるが、図２４と図２５に示されるように、コンテンツの内部とは別に、ヘッダ内に配置するようにすることで、ウォーターマークとしてコンテンツに埋め込まれている情報を迅速に、かつ簡単に検出することが可能となる。従って、そのコンテンツを、コピーすることができるか否かを、迅速に判定することができる。
【０１４６】
なお、メタデータは、例えば、ジャケット、写真、歌詞等のデータを表す。マークについては、図３１を参照して後述する。
【０１４７】
図２６は、証明書としての公開鍵証明書の例を表している。公開鍵証明書は、通常、公開鍵暗号方式における認証局（CA：Certificate Authority）が発行する証明書であり、ユーザが、認証局に提出した自己のIDや公開鍵などに、認証局が有効期限等の情報を付加し、さらに、認証局によるデジタル署名を付加して作成される。この発明においては、ライセンスサーバ４（またはコンテンツサーバ３）が、証明書と秘密鍵、従って公開鍵も発行するので、ユーザは、ユーザID、パスワード等をライセンスサーバ４に提供し登録処理を行うことによって、この公開鍵証明書を得ることができる。
【０１４８】
図２６における公開鍵証明書は、証明書のバージョン番号、ライセンスサーバ４が証明書の利用者（ユーザ）に対して割りつける証明書の通し番号、デジタル署名に用いたアルゴリズム、およびパラメータ、認証局（ライセンスサーバ４）の名前、証明書の有効期限、証明書利用者のID（ノードIDまたはリーフID）、並びに証明書利用者の公開鍵が、メッセージとして含まれている。さらに、このメッセージには、認証局としてのライセンスサーバ４により作成されたデジタル署名が付加されている。このデジタル署名は、メッセージに対してハッシュ関数を適用して生成されたハッシュ値に基づいて、ライセンスサーバ４の秘密鍵を用いて生成されたデータである。
【０１４９】
ノードIDまたはリーフIDは、例えば、図１２の例の場合、デバイス０であれば「００００」とされ、デバイス１でれば「０００１」とされ、デバイス１５であれば「１１１１」とされる。このようなIDに基づいて、そのデバイス（エンティティ）がツリー構成のどの位置（リーフまたはノード）に位置するエンティティであるのかが識別される。
【０１５０】
このように、コンテンツを利用するのに必要なライセンスを、コンテンツとは分離して配布するようにすることにより、コンテンツの配布が自由に行われることになる。任意の方法、あるいは経路で入手されたコンテンツは、一元的に取り扱うことが可能である。
【０１５１】
また、ファイルフォーマットを図２５に示されるように構成することで、そのフォーマットのコンテンツを、インターネットを介して配信する場合は勿論、SDMI（Secure Digital Music Initiative）機器に提供する場合においても、コンテンツの著作権を管理することが可能となる。
【０１５２】
さらに、例えば、図２７に示されるように、コンテンツが記録媒体を介して提供されたとしても、インターネット２を介して提供されたとしても、同様の処理により、SDMI（Secure Digital Music Initiative）機器としての所定のPD（Portable Device）等に、チェックアウトしたりすることが可能となる。
【０１５３】
次に、図２８のフローチャートを参照して、クライアント１が他のクライアント（例えば、PD）に対してコンテンツをチェックアウトする場合の処理について説明する。
【０１５４】
最初に、ステップＳ１９１において、CPU２１は、コンテンツにデジタル署名が付加されているか否かを判定する。デジタル署名が付加されていると判定された場合、ステップＳ１９２に進み、CPU２１は、証明書を抽出し、認証局（ライセンスサーバ４）の公開鍵で検証する処理を実行する。すなわち、クライアント１は、ライセンスサーバ４からライセンスサーバ４の秘密鍵に対応する公開鍵を取得し、その公開鍵で公開鍵証明書に付加されているデジタル署名を復号する。図２６を参照して説明したように、デジタル署名は、認証局（ライセンスサーバ４）の秘密鍵に基づいて生成されており、ライセンスサーバ４の公開鍵を用いて復号することができる。さらに、CPU２１は、証明書のメッセージ全体に対してハッシュ関数を適用してハッシュ値を演算する。そしてCPU２１は、演算されたハッシュ値と、デジタル署名を復号して得られたハッシュ値とを比較し、両者が一致すれば、メッセージは改竄されたものではないと判定する。両者が一致しない場合には、この証明書は、改竄されたものであるということになる。
【０１５５】
そこで、ステップＳ１９３において、CPU２１は、証明書が改竄されていないか否かを判定し、改竄されていないと判定された場合、ステップＳ１９４に進み、証明書をEKBで検証する処理を実行する。この検証処理は、証明書に含まれるリーフID（図２６）に基づいて、EKBをたどることができるか否かを調べることにより行われる。この検証について、図２９と図３０を参照して説明する。
【０１５６】
いま、図２９に示されるように、例えば、リーフキーＫ１００１を有するデバイスがリボークされたデバイスであるとする。このとき、図３０に示されるようなデータ（暗号化キー）とタグを有するEKBが、各デバイス（リーフ）に配布される。このEKBは、図２９におけるデバイス「１００１」をリボークするために、キーKR,Ｋ１,Ｋ１０,Ｋ１００を更新するEKBとなっている。
【０１５７】
リボークデバイス「１００１」以外の全てのリーフは、更新されたルートキーＫ（ｔ）Ｒを取得することができる。すなわち、ノードキーＫ０の下位に連なるリーフは、更新されていないノードキーＫ０を、デバイス内に保持しているので、暗号化キーEnc（Ｋ０，Ｋ（ｔ）Ｒ）を、キーＫ０によって復号することで、更新ルートキーＫ（ｔ）Ｒを取得することができる。
【０１５８】
また、ノードキーＫ１１以下のリーフは、更新されていないノードキーＫ１１を用いて、Enc（Ｋ１１，Ｋ（ｔ）１）をノードキーＫ１１によって復号することで、更新ノードキーＫ（ｔ）１を取得することができる。さらに、Enc（Ｋ（ｔ）１，Ｋ（ｔ）Ｒ）をノードキーＫ（ｔ）１によって復号することで、更新ルートキーＫ（ｔ）Ｒを取得することが可能となる。ノードキーＫ１０１の下位リーフについても、同様に更新ルートキーＫ（ｔ）Ｒを取得することが可能である。
【０１５９】
さらに、リボークされていないリーフキーＫ１０００を有するデバイス「１０００」は、自己のリーフキーＫ１０００でEnc（Ｋ１０００，Ｋ（ｔ）１００）を復号して、ノードキーＫ（ｔ）１００を取得することができ、これを用いてさらに、上位のノードキーを順次復号し、更新ルートキーＫ（ｔ）Ｒを取得することができる。
【０１６０】
これに対して、リボークされたデバイス「１００１」は、自己のリーフの１段上の更新ノードキーＫ（ｔ）１００を、EKB処理により取得できないので、結局、更新ルートキーＫ（ｔ）Ｒを取得することができない。
【０１６１】
リボークされていない正当なデバイス（クライアント１）には、図３０に示されるデータとタグを有するEKBが、ライセンスサーバ４から配信され、格納されている。
【０１６２】
そこで、各クライアントは、そのタグを利用して、EKB追跡処理を行うことができる。このEKB追跡処理は、上位のルートキーからキー配信ツリーをたどれるか否かを判定する処理である。
【０１６３】
例えば、図２９のリーフ「１００１」のID（リーフID）である「１００１」を、「１」「０」「０」「１」の４ビットとして把握し、最上位ビットから順次、下位ビットに従って、ツリーをたどることができるか否かが判定される。この判定では、ビットが１であれば、右側に進み、０であれば、左側に進む処理が行われる。
【０１６４】
ID「１００１」の最上位ビットが１であるから、図２９のルートキーKRから右側に進む。EKBの最初のタグ（番号０のタグ）は、０：｛０，０｝であり、両枝にデータを有するものであると判定される。この場合、右側に進むことができるので、ノードキーＫ１にたどり着くことができる。
【０１６５】
次に、ノードキーＫ１の下位のノードに進む。ID「１００１」の２番目のビットは０であるから左側に進む。番号１のタグは、左側のノードキーＫ０の下位のデータの有無を表すものであり、ノードキーＫ１の下位のデータの有無を示すタグは、番号２のタグである。このタグは、図３０に示されるように、２：｛０，０｝であり、両枝にデータを有するものとされる。従って、左側に進み、ノードキーＫ１０にたどり着くことができる。
【０１６６】
さらに、ID「１００１」の３番目のビットは０であり、左側に進む。このとき、Ｋ１０の下位のデータの有無を示すタグ（番号３のタグ）は、３：｛０，０｝であり、両枝にデータを有するものと判定される。そこで、左側に進み、ノードキーＫ１００にたどり着くことができる。
【０１６７】
さらに、ID「１００１」の最下位ビットは１であり、右側に進む。番号４のタグは、ノードキーＫ１１に対応するものであり、Ｋ１００の下位のデータの符号を表すタグは、番号５のタグである。このタグは、５：｛０，１｝である。従って、右側には、データが存在しないことになる。その結果、ノード「１００１」にはたどり着けないことになり、ID「１００１」のデバイスは、EKBによる更新ルートキーを取得できないデバイス、すなわちリボークデバイスであると判定される。
【０１６８】
これに対して、例えば、リーフキーＫ１０００を有するデバイスIDは、「１０００」であり、上述した場合と同様に、EKB内のタグに基づくEKB追跡処理を行うと、ノード「１０００」にたどり着くことができる。従って、ID「Ｉ０００」のデバイスは、正当なデバイスであると判定される。
【０１６９】
図２８に戻って、CPU２１は、ステップＳ１９４の検証処理に基づき、証明書がリボークされていないか否かをステップＳ１９５で判定し、証明書がリボークされていない場合には、ステップＳ１９６に進み、デジタル署名を証明書に含まれる公開鍵で検証する処理を実行する。
【０１７０】
すなわち、図２６に示されるように、証明書には、証明書利用者（コンテンツ作成者）の公開鍵が含まれており、この公開鍵を用いて、図２５に示される署名（Sig（Header））が検証される。すなわち、この公開鍵を用いて、デジタル署名Sig（Header）を復号して得られたデータ（ハッシュ値）と、図２５に示されるHeaderにハッシュ関数を適用して演算されたハッシュ値とを比較することで、両者が一致していれば、Headerが改竄されていないことを確認することができる。これに対して、両者が一致しなければ、Headerは改竄されているということになる。
【０１７１】
ステップＳ１９７において、CPU２１は、Headerが改竄されているか否かを判定し、改竄されていなければ、ステップＳ１９８に進み、ウォーターマークを検証する。ステップＳ１９９において、CPU２１は、ウォーターマークの検証の結果、チェックアウトが可能であるか否かを判定する。チェックアウトが可能である場合には、ステップＳ２００に進み、CPU２１は、チェックアウトを実行する。すなわち、チェックアウト先のクライアント１に対してコンテンツを転送し、コピーさせる。
【０１７２】
ステップＳ１９１において、デジタル署名が存在しないと判定された場合、ステップＳ１９３において、証明書が改竄されていると判定された場合、ステップＳ１９５において、証明書をEKBで検証することができなかったと判定された場合、ステップＳ１９７において、デジタル署名の検証の結果、ヘッダが改竄されていると判定された場合、または、ステップＳ１９９において、ウォーターマークにチェックアウトの禁止が記述されていると判定された場合、ステップＳ２０１に進み、エラー処理が実行される。すなわち、この場合には、チェックアウトが禁止される。
【０１７３】
このように、証明書と秘密鍵をライセンスサーバ４からユーザに配布し、コンテンツ作成時に、デジタル署名を付加することにより、コンテンツの作成者の真正を保証することが可能となる。これにより、不正なコンテンツの流通を抑制することができる。
【０１７４】
さらに、ウォーターマークをコンテンツ作成時に検出し、その情報をデジタル署名に付することで、ウォーターマーク情報の改竄を防止し、コンテンツの真正を保証することができる。
【０１７５】
その結果、一度作成されたコンテンツは、どのような形態で配信されたとしても、元のコンテンツの真正を保証することが可能となる。
【０１７６】
さらに、コンテンツは、使用条件を有さず、使用条件は、ライセンスに付加されているので、ライセンス内の使用条件を変更することで、それに関係するコンテンツの使用条件を一斉に変更することが可能となる。
【０１７７】
次に、マークの利用方法について説明する。本発明においては、上述したように、使用条件は、コンテンツではなく、ライセンスに付加される。しかしながら、コンテンツによって、使用状況が異なる場合がある。そこで、本発明においては、図２５に示されるように、コンテンツにマークが付加される。
【０１７８】
ライセンスとコンテンツは、１対多の関係にあるため、コンテンツの個々の使用状況をライセンスの使用条件にのみ記述するのは困難となる。そこで、このように、コンテンツに使用状況を付加することにより、ライセンスでの管理をしながらも、個々のコンテンツを管理することが可能となる。
【０１７９】
このマークには、例えば、図３１に示されるように、ユーザのID（リーフID）、所有権フラグ、使用開始時刻、およびコピー回数等が記述される。
【０１８０】
さらに、マークには、リーフID、所有権フラグ、使用開始時刻、およびコピー回数等のメッセージに基づいて生成されたデジタル署名が付加される。
【０１８１】
所有権フラグは、例えば、所定の期間だけコンテンツを使用可能とするライセンスを、そのまま買い取ったような場合（使用期間を永久に変更したような場合）に付加される。使用開始時刻は、コンテンツの使用を所定の期間内に開始した場合に記述される。例えば、コンテンツをダウンロードする時期が制限されているような場合において、その期限内にダウンロードが行われたようなとき、その実際にコンテンツをダウンロードした日時がここに記述される。これにより、期間内での有効な使用であることが、証明される。
【０１８２】
コピー回数には、それまでにそのコンテンツをコピーした回数が履歴（ログ）として記述される。
【０１８３】
次に、図３２のフローチャートを参照して、ユーザがライセンスを買い取った場合に、マークを付加する処理について、マークをコンテンツに付加する例として説明する。
【０１８４】
最初に、ステップＳ２２１において、CPU２１は、入力部２６からのユーザの指令に基づいて、インターネット２を介して、ライセンスサーバ４にアクセスする。
【０１８５】
ステップＳ２２２において、CPU２１は、ユーザからの入力部２６を介しての入力を取り込み、その入力に対応してライセンスサーバ４に対してライセンスの買い取りを要求する。
【０１８６】
この要求に対応して、図３３のフローチャートを参照して後述するように、ライセンスサーバ４は、ライセンスを買い取るために必要な対価を提示してくる（図３３のステップＳ２４２）。そこで、ステップＳ２２３において、クライアント１のCPU２１は、ライセンスサーバ４からの対価の提示を受け取ると、これを出力部２７に出力し、表示させる。
【０１８７】
ユーザは、この表示に基づいて、提示された対価を了承するか否かを判断し、その判断結果に基づいて、入力部２６からその判断結果を入力する。
【０１８８】
CPU２１は、ステップＳ２２４において、入力部２６からの入力に基づいて、ユーザが提示された対価を了承したか否かを判定し、了承したと判定した場合には、ステップＳ２２５に進み、ライセンスサーバ４に了承を通知する処理を実行する。
【０１８９】
この了承通知を受信すると、ライセンスサーバ４は、対価の買い取りを表す情報、すなわち所有権フラグを記述したマークを送信してくる（図３３のステップＳ２４４）。そこで、ステップＳ２２６において、クライアント１のCPU２１は、ライセンスサーバ４からのマークを受け取ると、ステップＳ２２７において、受け取ったマークをコンテンツに埋め込む処理を実行する。すなわち、これにより、買い取られたライセンスに対応するコンテンツのマークとして、図３１に示されるような所有権フラグが記述されたマークがコンテンツに対応して記録されることになる。また、このとき、CPU２１は、メッセージが更新されたことになるので、デジタル署名（図２５）も更新し、記録媒体に記録する。
【０１９０】
ステップＳ２２４において、ライセンスサーバ４から提示された対価が了承されていないと判定された場合、ステップＳ２２８に進み、CPU２１は、提示された対価を了承しないことをライセンスサーバ４に通知する。
【０１９１】
このようなクライアント１の処理に対応して、ライセンスサーバ４は、図３３のフローチャートに示す処理を実行する。
【０１９２】
すなわち、最初に、ステップＳ２４１において、ライセンスサーバ４のCPU２１は、クライアント１からライセンス買い取りの要求が送信されてくると（図３２のステップＳ２２２）、 これを受け取り、ステップＳ２４２において、対象とされているライセンスの買い取りに必要な対価を記憶部２８から読み出し、これをクライアント１に送信する。
【０１９３】
上述したように、このようにして提示された対価に対して、クライアント１から提示された対価を了承するか否かの通知が送信されてくる。
【０１９４】
そこで、ステップＳ２４３において、ライセンスサーバ４のCPU２１は、クライアント１から了承通知を受信したか否かを判定し、了承通知を受信したと判定した場合、ステップＳ２４４に進み、対象とされるライセンスの買い取りを表すメッセージを含むマークを生成し、自分自身の秘密鍵で、デジタル署名を付加して、クライアント１に送信する。このようにして送信されたマークは、上述したように、クライアント１の記憶部２８において、対応するコンテンツに記録される（図３２のステップＳ２２７）。
【０１９５】
ステップＳ２４３において、クライアント１から了承通知が受信されていないと判定された場合、ステップＳ２４４の処理はスキップされる。すなわち、この場合には、ライセンスの買い取り処理が最終的に行われなかったことになるので、マークは送信されない。
【０１９６】
図３４は、ステップＳ２４４において、ライセンスサーバ４からクライアント１に対して送信されるマークの構成例を表している。この例においては、そのユーザのリーフID、所有権フラグ（Own）、並びにリーフIDと所有権フラグを、ライセンスサーバ４の秘密鍵Ｓに基づいて生成されたデジタル署名Sigs（LeafID, Own）により、マークが構成されている。
【０１９７】
なお、このマークは、特定のユーザの特定のコンテンツに対してのみ有効なものであるので、対象とされるコンテンツがコピーされた場合には、そのコピーされたコンテンツに付随するマークは無効とされる。
【０１９８】
このようにして、コンテンツとライセンスを分離し、使用条件をライセンスに対応させる場合においても、個々のコンテンツの使用状況に応じたサービスを実現することが可能となる。
【０１９９】
次に、グルーピングについて説明する。複数の機器やメディアを適当に集め、その１つの集合内においては、コンテンツを自由に授受することができるようにすることは、グルーピングと称される。通常、このグルーピングは、個人の所有する機器やメディアにおいて行われる。このグルーピングは、従来、グループ毎にグループキーを設定する等して行われていたが、グループ化する複数の機器やメディアに、同一のライセンスを対応づけることにより、容易にグルーピングすることが可能となる。
【０２００】
また、各機器を予め登録しておくことで、グルーピングすることも可能である。この場合のグルーピングについて、以下に説明する。
【０２０１】
この場合、ユーザは、グルーピング対象とされる機器の証明書を予めサーバに登録しておく必要がある。この証明書の登録処理について、図３５と図３６のフローチャートを参照して説明する。
【０２０２】
最初に、図３５のフローチャートを参照して、クライアント（グルーピング対象となる機器）の証明書の登録処理について説明する。ステップＳ２６１において、クライアント１のCPU２１は、グルーピングの対象とされる機器としての自分自身の証明書を作成する。この証明書には、自分自身の公開鍵が含まれる。
【０２０３】
次に、ステップＳ２６２に進み、CPU２１は、ユーザの入力部２６からの入力に基づいて、コンテンツサーバ３にアクセスし、ステップＳ２６３において、ステップＳ２６１の処理で作成された証明書をコンテンツサーバ３に送信する処理を実行する。
【０２０４】
なお、証明書としては、ライセンスサーバ４から受信したものを、そのまま使用することもできる。
【０２０５】
以上の処理は、グルーピング対象とされる全ての機器が行う。
【０２０６】
次に、図３６のフローチャートを参照して、図３５のクライアント１の証明書の登録処理に対応して行われるコンテンツサーバ３の証明書の登録処理について説明する。
【０２０７】
最初に、ステップＳ２７１において、コンテンツサーバ３のCPU２１は、クライアント１から送信されてきた証明書を受信すると、ステップＳ２７２において、その証明書を記憶部２８に登録する。
【０２０８】
以上の処理が、グループ対象とされる機器毎に行われる。その結果、コンテンツサーバ３の記憶部２８には、例えば、図３７に示されるように、グループ毎に、そのグループを構成するデバイスの証明書が登録される。
【０２０９】
図３７に示される例では、グループ１の証明書として、証明書Ｃ１１乃至Ｃ１４が登録されている。これらの証明書Ｃ１１乃至Ｃ１４には、対応する公開鍵ＫP11乃至ＫP14が含まれている。
【０２１０】
同様に、グループ２の証明書として、証明書Ｃ２１乃至Ｃ２３が登録されており、これらは対応する公開鍵ＫP21乃至ＫP23が含まれている。
【０２１１】
以上のようなグループを構成する各機器毎に、その証明書が登録された状態において、ユーザからそのグループに属する機器にコンテンツの提供が要求されると、コンテンツサーバ３は、図３８のフローチャートに示す処理を実行する。
【０２１２】
最初に、ステップＳ２８１において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されている証明書のうち、そのグループに属する証明書を検証する処理を実行する。
【０２１３】
この検証処理は、図２９と図３０を参照して説明されたように、各機器の証明書に含まれるリーフIDに基づいて、タグを利用してEKBをたどることで行われる。EKBは、コンテンツサーバ３にも、ライセンスサーバ４から配布されている。この検証処理により、リボークされている証明書は除外される。
【０２１４】
ステップＳ２８２において、コンテンツサーバ３のCPU２１は、ステップＳ２８１の検証処理の結果、有効とされた証明書を選択する。そして、ステップＳ２８３において、CPU２１は、ステップＳ２８２の処理で選択された各機器の証明書の各公開鍵でコンテンツ鍵を暗号化する。ステップＳ２８４において、CPU２１は、対象とされるグループの各機器に、ステップＳ２８３の処理で暗号化されたコンテンツ鍵をコンテンツとともに送信する。
【０２１５】
図３７に示されるグループ１のうち、例えば、証明書Ｃ１４がリボークされているとすると、ステップＳ２８３の処理で、例えば、図３９に示されるような暗号化データが生成される。
【０２１６】
すなわち、図３９の例においては、コンテンツ鍵Kcが、証明書Ｃ１１の公開鍵ＫP11、証明書Ｃ１２の公開鍵ＫP12、または証明書Ｃ１３の公開鍵ＫP13により、暗号化されている。
【０２１７】
コンテンツサーバ３の図３８に示されるような処理に対応して、コンテンツの提供を受ける各グループの機器（クライアント）は、図４０のフローチャートに示す処理を実行する。
【０２１８】
最初に、ステップＳ２９１において、クライアント１のCPU２１は、コンテンツサーバ３が図３８のステップＳ２８４の処理で送信してきたコンテンツを、コンテンツ鍵とともに受信する。コンテンツは、コンテンツ鍵Kcにより、暗号化されており、コンテンツ鍵は上述したように、各機器が保持する公開鍵により暗号化されている（図３９）。
【０２１９】
そこで、ステップＳ２９２において、CPU２１は、ステップＳ２９１の処理で受信した自分宛のコンテンツ鍵を、自分自身の秘密鍵で復号し、取得する。そして、取得したコンテンツ鍵を用いてコンテンツの復号処理が行われる。
【０２２０】
例えば、図３９の例に示される証明書Ｃ１１に対応する機器は、公開鍵ＫP11に対応する自分自身の秘密鍵を用いて、コンテンツ鍵Kcの暗号を復号し、コンテンツ鍵Kcを取得する。そして、コンテンツ鍵Kcを用いて、コンテンツがさらに復号される。
【０２２１】
同様の処理は、証明書Ｃ１２，Ｃ１３に対応する機器においても行われる。リボークされている証明書Ｃ１４の機器は、自分自身の公開鍵を用いて暗号化されたコンテンツ鍵Kcがコンテンツに付随して送られてこないので、コンテンツ鍵Kcを復号することができず、従って、コンテンツ鍵Kcを用いてコンテンツを復号することができない。
【０２２２】
以上においては、コンテンツキー（すなわちコンテンツ）に対してグルーピングを行うようにしたが、ライセンスキー（ライセンス）に対してグルーピングを行うことも可能である。
【０２２３】
以上のようにして、特別なグループキーや、後述するICV（Integrity Check Value）を用いずにグループ化が可能となる。このグループ化は、小規模のグループに適用するのに向いている。
【０２２４】
本発明においては、ライセンスもチェックアウト、あるいはチェックインしたり、ムーブしたり、コピーしたりすることが可能とされる。但し、これらの処理はSDMIで定められたルールに基づいて行われる。
【０２２５】
次に、図４１と図４２のフローチャートを参照して、このようなクライアントによるライセンスのチェックアウト処理について説明する。
【０２２６】
最初に、図４１のフローチャートを参照して他のクライアントにライセンスをチェックアウトするクライアントの処理について説明する。最初に、ステップＳ３０１において、クライアント１のCPU２１は、チェックアウト対象のライセンスのチェックアウト回数Ｎ１を読み取る。このチェックアウト回数は、図８に示される使用条件に書き込まれているので、この使用条件から読み取られる。
【０２２７】
次に、ステップＳ３０２において、CPU２１は、チェックアウト対象のライセンスの最大チェックアウト回数Ｎ２を、やはりライセンスの使用条件から読み取る。
【０２２８】
そして、ステップＳ３０３において、CPU２１は、ステップＳ３０１の処理で読み取られたチェックアウト回数Ｎ１と、ステップＳ３０２の処理で読み取られた最大チェックアウト回数Ｎ２とを比較し、チェックアウト回数Ｎ１が最大チェックアウト回数Ｎ２より大きいか否かを判定する。
【０２２９】
チェックアウト回数Ｎ１が、最大チェックアウト回数Ｎ２より小さいと判定された場合、ステップＳ３０４に進み、CPU２１は、相手側の装置（チェックアウト先のクライアント）のリーフキーを相手個々の装置から取得し、そのリーフキーを、いまチェックアウト対象とされているライセンスIDに対応して記憶部２８のチェックアウトリストに記憶させる。
【０２３０】
次に、ステップＳ３０５において、CPU２１は、ステップＳ３０１の処理で読み取られたライセンスのチェックアウト回数Ｎ１の値を１だけインクリメントする。ステップＳ３０６において、CPU２１は、ライセンスのメッセージに基づいて、ICVを演算する。このICVについては、図４６乃至図５０を参照して後述する。ICVを用いてライセンスの改竄を防止することが可能となる。
【０２３１】
次に、ステップＳ３０７において、CPU２１は、チェックアウト対象のライセンスと、ステップＳ３０６の処理で演算されたICVを、自分自身の公開鍵を用いて暗号化して、EKBおよび証明書とともに、相手側の装置に出力し、コピーさせる。さらに、ステップＳ３０８において、CPU２１は、ステップＳ３０６の処理で演算されたICVを、相手側装置のリーフキーと、ライセンスIDに対応して記憶部２８のチェックリスト中に記憶させる。
【０２３２】
ステップＳ３０３において、チェックアウト回数Ｎ１が最大チェックアウト回数Ｎ２より小さくない（例えば、等しい）と判定された場合、もはや許容される回数だけチェックアウトが行われているので、これ以上チェックアウトを行うことができない。そこで、ステップＳ３０９に進み、CPU２１は、エラー処理を実行する。すなわち、この場合、チェックアウト処理は実行されないことになる。
【０２３３】
次に、図４２のフローチャートを参照して、図４１のチェックアウト処理により、ライセンスのチェックアウトを受けるクライアントの処理について説明する。
【０２３４】
最初に、ステップＳ３２１において、相手側装置（ライセンスをチェックアウトするクライアント１）に、自分自身のリーフキーを送信する。このリーフキーは、ステップＳ３０４において、相手側のクライアントにより、ライセンスIDに対応して記憶される。
【０２３５】
次に、ステップＳ３２２において、CPU２１は、相手側のクライアント１から暗号化されたライセンスとICVが、EKBおよび証明書とともに送信されてきた場合、これを受信する。すなわち、このライセンス、ICV、EKBおよび証明書は、図４１のステップＳ３０７の処理で相手側の装置から送信されたものである。
【０２３６】
ステップＳ３２３において、CPU２１は、ステップＳ３２２の処理で受信したライセンス、ICV、EKBおよび証明書を、記憶部２８に記憶させる。
【０２３７】
以上のようにして、ライセンスのチェックアウトを受けたクライアント１は、チェックアウトを受けたそのライセンスを使用して、所定のコンテンツを再生する場合、図４３のフローチャートに示される処理を実行する。
【０２３８】
すなわち、最初に、ステップＳ３４１において、クライアント１の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 Authentication Code））となる。
【０２５６】
このようなライセンスのＭＡＣ値とＩＣＶ生成キーにハッシュ関数を適用してライセンスのインテグリティ・チェック値（ＩＣＶ）が生成される。例えばライセンス生成時に生成したＩＣＶと、新たにライセンスに基づいて生成したＩＣＶとを比較して同一のＩＣＶが得られればライセンスに改竄のないことが保証され、ＩＣＶが異なれば、改竄があったと判定される。
【０２５７】
次に、ライセンスのインテグリティ・チェック値（ＩＣＶ）生成キーであるＫｉｃｖを上述の有効化キーブロックによって送付する構成について説明する。すなわちＥＫＢによる暗号化メッセージデータをライセンスのインテグリティ・チェック値（ＩＣＶ）生成キーとした例である。
【０２５８】
図４７および図４８に複数のデバイスに共通のライセンスを送付した場合、それらのライセンスの改竄の有無を検証するためのインテグリティ・チェック値生成キーＫｉｃｖを有効化キーブロック（ＥＫＢ）によって配信する構成例を示す。図４７はデバイス０，１，２，３に対して復号可能なチェック値生成キーＫｉｃｖを配信する例を示し、図４８はデバイス０，１，２，３中のデバイス３をリボーク（排除）してデバイス０，１，２に対してのみ復号可能なチェック値生成キーＫｉｃｖを配信する例を示す。
【０２５９】
図４７の例では、更新ノードキーＫ（ｔ）００によって、チェック値生成キーＫｉｃｖを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）とともに、デバイス０，１，２，３においてそれぞれの有するノードキー、リーフキーを用いて更新されたノードキーＫ（ｔ）００を復号可能な有効化キーブロック（ＥＫＢ）を生成して配信する。それぞれのデバイスは、図４７の右側に示すように、まず、ＥＫＢを処理（復号）することにより、更新されたノードキーＫ（ｔ）００を取得し、次に、取得したノードキーＫ（ｔ）００を用いて、暗号化されたチェック値生成キーＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）を復号して、チェック値生成キーＫｉｃｖを得ることが可能となる。
【０２６０】
その他のデバイス４，５，６，７・・・は同一の有効化キーブロック（ＥＫＢ）を受信しても自身の保有するノードキー、リーフキーでは、ＥＫＢを処理して更新されたノードキーＫ（ｔ）００を取得することができないので、安全に正当なデバイスに対してのみチェック値生成キーを送付することができる。
【０２６１】
一方、図４８の例は、図１２の点線枠で囲んだグループにおいてデバイス３が、例えば鍵の漏洩によりリボーク（排除）されているとして、他のグループのメンバ、すなわち、デバイス０，１，２，に対してのみ復号可能な有効化キーブロック（ＥＫＢ）を生成して配信した例である。図４８に示す有効化キーブロック（ＥＫＢ）と、チェック値生成キー（Ｋｉｃｖ）をノードキー（Ｋ（ｔ）００）で暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）を配信する。
【０２６２】
図４８の右側には、復号手順を示してある。デバイス０，１，２は、まず、受領した有効化キーブロックから自身の保有するリーフキーまたはノードキーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００による復号によりチェック値生成キーＫｉｃｖを取得する。
【０２６３】
図１２に示す他のグループのデバイス４，５，６・・・は、この同様のデータ（ＥＫＢ）を受信したとしても、自身の保有するリーフキー、ノードキーを用いて更新ノードキー（Ｋ（ｔ）００）を取得することができない。同様にリボークされたデバイス３においても、自身の保有するリーフキー、ノードキーでは、更新ノードキー（Ｋ（ｔ）００）を取得することができず、正当な権利を有するデバイスのみがチェック値生成キーを復号して利用することが可能となる。
【０２６４】
このように、ＥＫＢを利用したチェック値生成キーの配送を用いれば、データ量を少なくして、かつ安全に正当権利者のみが復号可能としたチェック値生成キーを配信することが可能となる。
【０２６５】
このようなライセンスのインテグリティ・チェック値（ＩＣＶ）を用いることにより、ＥＫＢと暗号化ライセンスの不正コピーを排除することができる。例えば図４９Ａに示すように、ライセンスＬ１とライセンスＬ２とをそれぞれのライセンスキーを取得可能な有効化キーブロック（ＥＫＢ）とともに格納したメディア１があり、これをそのままメディア２にコピーした場合を想定する。ＥＫＢと暗号化ライセンスのコピーは可能であり、これをＥＫＢを復号可能なデバイスでは利用できることになる。
【０２６６】
図４９Ｂに示す例では、各メディアに正当に格納されたライセンスに対応付けてインテグリティ・チェック値（ＩＣＶ（Ｌ１，Ｌ２））を格納する構成とする。なお、（ＩＣＶ（Ｌ１，Ｌ２））は、ライセンスＬ１とライセンスＬ２にハッシュ関数を用いて計算されるライセンスのインテグリティ・チェック値であるＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｌ１，Ｌ２）を示している。図４９Ｂの構成において、メディア１には正当にライセンス１とライセンス２が格納され、ライセンスＬ１とライセンスＬ２に基づいて生成されたインテグリティ・チェック値（ＩＣＶ（Ｌ１，Ｌ２））が格納される。また、メディア２には正当にライセンス１が格納され、ライセンスＬ１に基づいて生成されたインテグリティ・チェック値（ＩＣＶ（Ｌ１））が格納される。
【０２６７】
この構成において、メディア１に格納された｛ＥＫＢ，ライセンス２｝をメディア２にコピーしたとすると、メディア２で、ライセンスチェック値を新たに生成すると、ＩＣＶ（Ｌ１，Ｌ２）が生成されることになり、メディア２に格納されているＫｉｃｖ（Ｌ１）と異なり、ライセンスの改竄あるいは不正なコピーによる新たなライセンスの格納が実行されたことが明らかになる。メディアを再生するデバイスにおいて、再生ステップの前ステップにＩＣＶチェックを実行して、生成ＩＣＶと格納ＩＣＶの一致を判別し、一致しない場合は、再生を実行しない構成とすることにより、不正コピーのライセンスの再生を防止することが可能となる。
【０２６８】
また、さらに、安全性を高めるため、ライセンスのインテグリティ・チェック値（ＩＣＶ）を書き換えカウンタを含めたデータに基づいて生成する構成としてもよい。すなわちＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，ｃｏｕｎｔｅｒ＋１，Ｌ１，Ｌ２，・・・）によって計算する構成とする。ここで、カウンタ（ｃｏｕｎｔｅｒ＋１）は、ＩＣＶの書き換えごとに１つインクリメントされる値として設定する。なお、カウンタ値はセキュアなメモリに格納する構成とすることが必要である。
【０２６９】
さらに、ライセンスのインテグリティ・チェック値（ＩＣＶ）をライセンスと同一メディアに格納することができない構成においては、ライセンスのインテグリティ・チェック値（ＩＣＶ）をライセンスとは別のメディア上に格納する構成としてもよい。
【０２７０】
例えば、読み込み専用メディアや通常のＭＯ等のコピー防止策のとられていないメディアにライセンスを格納する場合、同一メディアにインテグリティ・チェック値（ＩＣＶ）を格納するとＩＣＶの書き換えが不正なユーザによりなされる可能性があり、ＩＣＶの安全性が保てないおそれがある。この様な場合、ホストマシン上の安全なメディアにＩＣＶを格納して、ライセンスのコピーコントロール（例えばcheck-in/check-out、move）にＩＣＶを使用する構成とすることにより、ＩＣＶの安全な管理およびライセンスの改竄チェックが可能となる。
【０２７１】
この構成例を図５０に示す。図５０では読み込み専用メディアや通常のＭＯ等のコピー防止策のとられていないメディア２２０１にライセンス１乃至ライセンス３が格納され、これらのライセンスに関するインテグリティ・チェック値（ＩＣＶ）を、ユーザが自由にアクセスすることの許可されないホストマシン上の安全なメディア２２０２に格納し、ユーザによる不正なインテグリティ・チェック値（ＩＣＶ）の書き換えを防止した例である。このような構成として、例えばメディア２２０１を装着したデバイスが、メディア２２０１の再生を実行する際にホストマシンであるＰＣ、サーバにおいてＩＣＶのチェックを実行して再生の可否を判定する構成とすれば、不正なコピーライセンスあるいは改竄ライセンスの再生を防止できる。
【０２７２】
本発明が適用されるクライアントは、いわゆるパーソナルコンピュータ以外に、PDA（Personal Digital Assistants）、携帯電話機、ゲーム端末機などとすることができる。
【０２７３】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０２７４】
この記録媒体は、図２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk - Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０２７５】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２７６】
また、セキュリティに関連する処理を実行させるプログラムは、その処理を解析されるのを防ぐため、そのプログラム自体が暗号化されているのが望ましい。例えば、暗号処理などを行う処理については、そのプログラムをタンパーレジスタントモジュールとして構成することができる。
【０２７７】
また、コンテンツを利用許可するライセンスを特定するためにコンテンツのヘッダに記載されている情報はライセンスを一意に識別するライセンスIDでなくてもよい。上記の実施例では、ライセンスＩＤが、コンテンツの利用に必要なライセンスを特定する情報であり、あるライセンスが利用を許可するコンテンツを特定する情報であり、クライアント１からライセンス要求によって要求されるライセンスを識別する情報である。コンテンツにコンテンツのそのコンテンツに関する各種属性情報のリストが記載され、ライセンスに、そのライセンスによって利用許可されるコンテンツの条件式を記載するようにしても良い。この場合では、コンテンツに含まれる属性情報がそのコンテンツの利用を許可するライセンスを特定する情報であり、ライセンスに含まれる条件式がそのライセンスが利用を許可するコンテンツを特定する情報であり、ライセンスＩＤはライセンスを一意に識別する情報となる。このようにした場合には、一つのコンテンツに複数のライセンスを対応付けることが可能になり、ライセンスの発行を柔軟に行うことができる。
【０２７８】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０２７９】
【発明の効果】
以上の如く、本発明の情報処理装置および方法、ライセンスサーバ、並びにプログラムによれば、暗号化されたデータを自由に配布できるようにし、別途ライセンスを取得することでコンテンツを利用できるようにしたことで、コンテンツの流通を妨げることなく、著作権を保護し、適切な使用料の徴収をすることができる。
【図面の簡単な説明】
【図１】本発明を適用したコンテンツ提供システムの構成を示すブロック図である。
【図２】図１のクライアントの構成を示すブロック図である。
【図３】図１のクライアントのコンテンツのダウンロード処理を説明するフローチャートである。
【図４】図１のコンテンツサーバのコンテンツ提供処理を説明するフローチャートである。
【図５】図４のステップＳ２６におけるフォーマットの例を示す図である。
【図６】図１のクライアントのコンテンツ再生処理を説明するフローチャートである。
【図７】図６のステップＳ４３のライセンス取得処理の詳細を説明するフローチャートである。
【図８】ライセンスの構成を示す図である。
【図９】図１のライセンスサーバのライセンス提供の処理を説明するフローチャートである。
【図１０】図６のステップＳ４５におけるライセンス更新処理の詳細を説明するフローチャートである。
【図１１】図１のライセンスサーバのライセンス更新処理を説明するフローチャートである。
【図１２】キーの構成を説明する図である。
【図１３】カテゴリノードを説明する図である。
【図１４】ノードとデバイスの対応の具体例を示す図である。
【図１５】有効化キーブロックの構成を説明する図である。
【図１６】有効化キーブロックの利用を説明する図である。
【図１７】有効化キーブロックのフォーマットの例を示す図である。
【図１８】有効化キーブロックのタグの構成を説明する図である。
【図１９】 DNKを用いたコンテンツの復号処理を説明する図である。
【図２０】有効化キーブロックの例を示す図である。
【図２１】複数のコンテンツの１つのデバイスに対する割り当てを説明する図である。
【図２２】ライセンスのカテゴリを説明する図である。
【図２３】クライアントのリッピング処理を説明するフローチャートである。
【図２４】ウォーターマークの構成を説明する図である。
【図２５】コンテンツのフォーマットの例を示す図である。
【図２６】公開鍵証明書の例を示す図である。
【図２７】コンテンツの配布を説明する図である。
【図２８】クライアントのコンテンツのチェックアウト処理を説明するフローチャートである。
【図２９】タグによる有効化キーブロックをたどる例を説明する図である。
【図３０】有効化キーブロックの構成例を示す図である。
【図３１】マークの構成を説明する図である。
【図３２】クライアントのライセンス買い取り処理を説明するフローチャートである。
【図３３】ライセンスサーバのライセンス買い取り処理を説明するフローチャートである。
【図３４】マークの構成例を示す図である。
【図３５】クライアントの証明書の登録処理を説明するフローチャートである。
【図３６】コンテンツサーバの証明書登録処理を説明するフローチャートである。
【図３７】グループの証明書の例を示す図である。
【図３８】グルーピングが行われている場合におけるコンテンツサーバの処理を説明するフローチャートである。
【図３９】コンテンツキーの暗号化の例を示す図である。
【図４０】グループに属するクライアントの処理を説明するフローチャートである。
【図４１】他のクライアントにライセンスをチェックアウトするクライアントの処理を説明するフローチャートである。
【図４２】他のクライアントからライセンスのチェックアウトを受けるクライアントの処理を説明するフローチャートである。
【図４３】ライセンスのチェックアウトを受けたクライアントの再生処理を説明するフローチャートである。
【図４４】他のクライアントからライセンスのチェックインを受けるクライアントの処理を説明するフローチャートである。
【図４５】他のクライアントにライセンスをチェックインするクライアントの処理を説明するフローチャートである。
【図４６】 MACの生成を説明する図である。
【図４７】 ICV生成キーの復号処理を説明するフローチャートである。
【図４８】 ICV生成キーの他の復号処理を説明する図である。
【図４９】 ICVによるライセンスのコピーの管理を説明する図である。
【図５０】ライセンスの管理を説明する図である。
【符号の説明】
１−１，１−２ クライアント， ２ インターネット， ３ コンテンツサーバ， ４ ライセンスサーバ， ５ 課金サーバ， ２０ タイマ， ２１ CPU， ２４ 暗号化復号部， ２５ コーデック部， ２６ 入力部， ２７出力部， ２８ 記憶部， ２９ 通信部
Claims (13)
- ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、
当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含む前記コンテンツを記憶するコンテンツ記憶手段と、
利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、
前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号する復号手段とを備え、
前記暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定される
ことを特徴とする情報処理装置。 - 前記情報処理装置は更に、
ライセンスサーバにライセンスを識別するためのライセンス識別情報を含むライセンス要求を送信する送信手段と、
ライセンスサーバによって送信されたライセンスを受信する受信手段とを備え、
前記受信手段により受信されたライセンスは前記ライセンス記憶手段に記憶される
ことを特徴とする請求項１記載の情報処理装置。 - 前記コンテンツデータはテキストデータ、画像データ、音声データ、動画データあるいはそれらを組み合わせたデータであり、
前記復号手段により復号されたコンテンツデータを再生する再生手段を更に備える
ことを特徴とする請求項１記載の情報処理装置。 - 前記鍵情報はEKB（Enabling Key Block）と前記EKB（Enabling Key Block）のルートキーによって暗号化されたコンテンツキーを含み、
前記情報処理装置は更にデバイスノードキーを記憶するデバイスノードキー記憶手段を備え、
前記復号手段は前記デバイスノードキー記憶手段に記憶されている前記デバイスノードキーを用いて前記EKB（Enabling Key Block）を復号処理し得られたルートキーを用いて復号された前記コンテンツキーを用いて前記暗号化されたコンテンツデータを復号する
ことを特徴とする請求項１記載の情報処理装置。 - 前記ライセンスは更に、当該ライセンスによって利用可能となるコンテンツの使用条件を示す使用条件情報を含む
ことを特徴とする請求項１記載の情報処理装置。 - 前記ライセンスは更に、ライセンスサーバの秘密鍵によりなされた電子署名を含む
ことを特徴とする請求項１記載の情報処理装置。 - 前記情報処理装置は、更に情報処理装置を識別する端末識別情報を記憶する端末識別情報記憶手段を備え、
前記ライセンス要求は更に、端末識別情報記憶手段に記憶されている前記端末識別情報を含み、
前記受信手段により受信された前記ライセンスは更に、前記端末識別情報を含み、
前記判定手段は、前記ライセンスに含まれる前記端末識別情報と前記端末識別情報記憶手段に記憶されている前記端末識別情報とを比較し、両者が一致している場合に限り、当該ライセンスを前記コンテンツの利用を許可できるライセンスであると判定する
ことを特徴とする請求項２記載の情報処理装置。 - ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含む前記コンテンツを記憶するコンテンツ記憶手段と、利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定する判定手段と、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置の情報処理方法であって、
前記コンテンツ記憶手段が、当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報と、を含むコンテンツを記憶するステップと、
前記ライセンス記憶手段が、当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するステップと、
前記判定手段が、前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定するステップと、
前記復号手段が、前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号するステップとを含み、
前記暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定される
ことを特徴とする情報処理方法。 - コンピュータを、
ライセンスを保持していることを条件としてコンテンツの利用を許可する情報処理装置において、
当該コンテンツを利用許可する前記ライセンスを特定するためのライセンス特定情報と、暗号化されたコンテンツデータと、コンテンツデータを復号するために必要な鍵情報とを含む前記コンテンツを記憶するコンテンツ記憶手段と、
利用許可される前記コンテンツを特定するためのコンテンツ特定情報を含むライセンスを記憶するライセンス記憶手段と、
前記コンテンツを利用許可することができるライセンスが前記ライセンス記憶手段に記憶されているか否かを判定する判定手段と、
前記判定手段によりライセンスが記憶されていると判断されたことを条件として前記コンテンツのコンテンツデータを復号する復号手段とを備える情報処理装置であって、
前記暗号化されたコンテンツデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定される情報処理装置として機能させる
プログラム。 - 前記プログラムあるいはその一部が暗号化されている
ことを特徴とする請求項９に記載のプログラム。 - コンテンツの利用を許可するライセンスを発行するライセンスサーバにおいて、
当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含む前記ライセンスを記憶するライセンス記憶手段と
情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信する受信手段と、
前記ライセンス要求に含まれる前記ライセンス識別情報に対応する前記ライセンスを前記ライセンス記憶手段から抽出する抽出手段と、
前記抽出手段により抽出された前記ライセンスに前記端末識別情報を付加する処理手段と、
ライセンスサーバの秘密鍵を用いて、前記処理手段により端末識別情報を付加されたライセンスに電子署名を付加する署名手段と、
前記署名手段により署名されたライセンスを前記ライセンス要求を送信した情報処理装置に送信する送信手段とを備え、
前記ライセンスによって利用許可される前記コンテンツは、暗号化されて前記情報処理装置に記憶され、
前記暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定され、
前記コンテンツキーは、前記端末識別情報に対応するデバイスノードキー基づいて特定される
ことを特徴とするライセンスサーバ。 - コンテンツの利用を許可するライセンスを発行するライセンスサーバの情報処理方法であって、
当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含む前記ライセンスを記憶するステップと、
情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信するステップと、
前記ライセンス要求に含まれる前記ライセンス識別情報に対応する前記ライセンスを前記ライセンス記憶手段から抽出するステップと、
前記抽出手段により抽出された前記ライセンスに前記端末識別情報を付加するステップと、
ライセンスサーバの秘密鍵を用いて、前記処理手段により端末識別情報を付加されたライセンスに電子署名を付加するステップと、
前記署名手段により署名されたライセンスを前記ライセンス要求を送信した情報処理装置に送信するステップとを含み、
前記ライセンスによって利用許可される前記コンテンツは、暗号化されて前記情報処理装置に記憶され、
前記暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定され、
前記コンテンツキーは、前記端末識別情報に対応するデバイスノードキー基づいて特定される
ことを特徴とする情報処理方法。 - コンピュータを、
コンテンツの利用を許可するライセンスを発行するライセンスサーバにおいて、
当該ライセンスによって利用許可される前記コンテンツを特定するためのコンテンツ特定情報と、情報処理装置を識別する端末識別情報を含む前記ライセンスを記憶するライセンス記憶手段と、
情報処理装置から送信された、ライセンスを識別するライセンス識別情報を含むライセンス要求を受信する受信手段と、
前記ライセンス要求に含まれる前記ライセンス識別情報に対応する前記ライセンスを前記ライセンス記憶手段から抽出する抽出手段と、
前記抽出手段により抽出された前記ライセンスに前記端末識別情報を付加する処理手段と、
ライセンスサーバの秘密鍵を用いて、前記処理手段により端末識別情報を付加されたライセンスに電子署名を付加する署名手段と、
前記署名手段により署名されたライセンスを前記ライセンス要求を送信した情報処理装置に送信する送信手段とを備えるライセンスサーバであって、
前記ライセンスによって利用許可される前記コンテンツは、暗号化されて前記情報処理装置に記憶され、
前記暗号化されたコンテンツのデータは、任意の数の暗号化ブロックにより構成され、それぞれの暗号化ブロックが、前記暗号化ブロック毎に異なるイニシャルベクトル、およびシード、並びにブロック鍵で暗号化されたブロックデータにより構成され、
前記ブロック鍵は、前記暗号化されたコンテンツのデータとともに記憶されている鍵情報に含まれるコンテンツキーと、前記シードとをハッシュ関数を用いて演算することにより生成され、
前段の暗号化ブロックのブロックデータが、後段の暗号化ブロックの前記イニシャルベクトルとして設定され、
前記コンテンツキーは、前記端末識別情報に対応するデバイスノードキー基づいて特定されるライセンスサーバとして機能させる
プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002028915A JP4151274B2 (ja) | 2001-02-09 | 2002-02-06 | 情報処理装置および方法、ライセンスサーバ、並びにプログラム |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001033114 | 2001-02-09 | ||
| JP2001094803 | 2001-03-29 | ||
| JP2001-33114 | 2001-03-29 | ||
| JP2001-94803 | 2001-03-29 | ||
| JP2002028915A JP4151274B2 (ja) | 2001-02-09 | 2002-02-06 | 情報処理装置および方法、ライセンスサーバ、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002359616A JP2002359616A (ja) | 2002-12-13 |
| JP4151274B2 true JP4151274B2 (ja) | 2008-09-17 |
Family
ID=27345945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002028915A Expired - Fee Related JP4151274B2 (ja) | 2001-02-09 | 2002-02-06 | 情報処理装置および方法、ライセンスサーバ、並びにプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4151274B2 (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10528704B2 (en) | 2002-12-30 | 2020-01-07 | Koninklijke Philips N.V. | Divided rights in authorized domain |
| KR20050100596A (ko) * | 2003-01-14 | 2005-10-19 | 마쯔시다덴기산교 가부시키가이샤 | 컨텐츠 재생 장치, 라이센스 발행 서버 및 컨텐츠 재생시스템 |
| US7370212B2 (en) | 2003-02-25 | 2008-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
| JP4424465B2 (ja) | 2003-06-09 | 2010-03-03 | ソニー株式会社 | 情報機器、情報サーバおよび情報処理プログラム |
| JP2005018277A (ja) * | 2003-06-24 | 2005-01-20 | Ntt Docomo Inc | 受信装置、プログラムおよび記録媒体 |
| JP2005027220A (ja) * | 2003-07-02 | 2005-01-27 | Sony Corp | 通信方法、その装置、並びにデータ処理方法およびその装置 |
| US20050021556A1 (en) * | 2003-07-25 | 2005-01-27 | Matsushita Electric Industrial Co., Ltd. | Data processing apparatus |
| CN100421095C (zh) * | 2003-09-30 | 2008-09-24 | 索尼株式会社 | 内容获取方法 |
| US8205266B2 (en) * | 2004-02-03 | 2012-06-19 | International Business Machines Corporation | Digital rights management |
| JP4631291B2 (ja) * | 2004-02-25 | 2011-02-16 | ソニー株式会社 | 情報処理装置および方法、記録媒体、並びにプログラム |
| JP4478871B2 (ja) | 2004-05-19 | 2010-06-09 | ソニー株式会社 | コンテンツデータ再生装置、コンテンツデータ提供装置、コンテンツデータ再生方法、コンテンツデータ提供方法、コンテンツデータ再生プログラム及びコンテンツデータ提供プログラム |
| JP2006004473A (ja) | 2004-06-15 | 2006-01-05 | Sony Corp | コンテンツ記録媒体、再生許可情報取得方法、コンテンツ再生方法およびコンテンツ再生装置 |
| JP4740574B2 (ja) * | 2004-10-21 | 2011-08-03 | 日本放送協会 | ライセンス情報生成装置及びそのプログラム、配信コンテンツ生成装置及びそのプログラム、コンテンツ復号装置及びそのプログラム、並びに、コンテンツ復号方法 |
| JP4760101B2 (ja) | 2005-04-07 | 2011-08-31 | ソニー株式会社 | コンテンツ提供システム，コンテンツ再生装置，プログラム，およびコンテンツ再生方法 |
| US20060265758A1 (en) | 2005-05-20 | 2006-11-23 | Microsoft Corporation | Extensible media rights |
| JP2007129413A (ja) * | 2005-11-02 | 2007-05-24 | Ntt Data Corp | 情報処理システム及びコンピュータプログラム |
| KR100782847B1 (ko) | 2006-02-15 | 2007-12-06 | 삼성전자주식회사 | 복수의 컨텐트 부분들을 포함하는 컨텐트를 임포트하는방법 및 장치 |
| US8978154B2 (en) | 2006-02-15 | 2015-03-10 | Samsung Electronics Co., Ltd. | Method and apparatus for importing content having plurality of parts |
| JP2008015622A (ja) | 2006-07-03 | 2008-01-24 | Sony Corp | 著作権保護記憶媒体、情報記録装置及び情報記録方法、並びに情報再生装置及び情報再生方法 |
| JP4766262B2 (ja) * | 2006-10-06 | 2011-09-07 | オンキヨー株式会社 | コンテンツ転送システム、コンテンツ記録装置及び携帯型コンテンツ記録システム |
| TWI394459B (zh) * | 2007-05-16 | 2013-04-21 | Sony Corp | Content download system and content download method, content provision device, and content supply method and content supply program, content receiving apparatus, and content receiving method and content receiving program |
| US9148478B2 (en) * | 2011-10-25 | 2015-09-29 | Alcatel Lucent | Verification of integrity of peer-received content in a peer-to-peer content distribution system |
| WO2016043571A1 (ko) * | 2014-09-19 | 2016-03-24 | 삼성전자주식회사 | 컨텐츠 제공 장치 및 방법 |
-
2002
- 2002-02-06 JP JP2002028915A patent/JP4151274B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002359616A (ja) | 2002-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4072761B2 (ja) | 情報処理装置および方法、記録媒体、並びに、プログラム | |
| KR100911282B1 (ko) | 정보 처리 장치 | |
| KR100904572B1 (ko) | 정보 처리 장치 | |
| KR100929744B1 (ko) | 정보 처리 방법/장치 및 프로그램 | |
| JP4151274B2 (ja) | 情報処理装置および方法、ライセンスサーバ、並びにプログラム | |
| TW561753B (en) | Information processing device | |
| JP3818504B2 (ja) | 情報処理装置および方法、並びにプログラム | |
| JP3818505B2 (ja) | 情報処理装置および方法、並びにプログラム | |
| JPWO2002080067A1 (ja) | 情報処理装置 | |
| JP2002297816A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| JP3818503B2 (ja) | 情報処理装置および方法、並びにプログラム | |
| JP2002297034A (ja) | 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体のフォーマット | |
| JP2002297032A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| JP2006320018A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| JP2001067795A (ja) | 情報受信システム及び情報受信装置 | |
| JP2001076425A (ja) | 記録再生システム、記録再生装置、再生装置、データ格納装置 | |
| JP2001069134A (ja) | 情報送信システム及び情報受信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050120 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071116 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080108 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080130 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080318 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080409 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080610 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080623 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110711 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120711 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |