[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP2002198952A - 情報処理システム、および情報処理方法、並びにプログラム記録媒体 - Google Patents

情報処理システム、および情報処理方法、並びにプログラム記録媒体

Info

Publication number
JP2002198952A
JP2002198952A JP2000396098A JP2000396098A JP2002198952A JP 2002198952 A JP2002198952 A JP 2002198952A JP 2000396098 A JP2000396098 A JP 2000396098A JP 2000396098 A JP2000396098 A JP 2000396098A JP 2002198952 A JP2002198952 A JP 2002198952A
Authority
JP
Japan
Prior art keywords
key
ekb
category
tree
category tree
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.)
Granted
Application number
JP2000396098A
Other languages
English (en)
Other versions
JP4710132B2 (ja
Inventor
Tomoyuki Asano
智之 浅野
Yoshitomo Osawa
義知 大澤
Takeo Oishi
丈於 大石
Ryuji Ishiguro
隆二 石黒
Ryuta Taki
隆太 瀧
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to JP2000396098A priority Critical patent/JP4710132B2/ja
Application filed by Sony Corp filed Critical Sony Corp
Priority to AT01272281T priority patent/ATE356484T1/de
Priority to EP01272281A priority patent/EP1253739B1/en
Priority to AT06076195T priority patent/ATE419691T1/de
Priority to KR1020027011163A priority patent/KR100852305B1/ko
Priority to DE60137270T priority patent/DE60137270D1/de
Priority to DE60127096T priority patent/DE60127096T2/de
Priority to EP06076195A priority patent/EP1710947B1/en
Priority to PCT/JP2001/011237 priority patent/WO2002052781A1/ja
Priority to US10/204,775 priority patent/US7167564B2/en
Priority to CNB018086713A priority patent/CN1211975C/zh
Publication of JP2002198952A publication Critical patent/JP2002198952A/ja
Priority to HK03109357A priority patent/HK1058269A1/xx
Priority to US11/639,711 priority patent/US7738662B2/en
Application granted granted Critical
Publication of JP4710132B2 publication Critical patent/JP4710132B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/107—License processing; Key processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H04L9/0836—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00855—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a step of exchanging information with a remote server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Circuits Of Receivers In General (AREA)
  • Information Transfer Between Computers (AREA)
  • Communication Control (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)
  • Multi-Process Working Machines And Systems (AREA)

Abstract

(57)【要約】 【課題】 カテゴリ区分されたツリー構造を用いた有効
化キーブロック（ＥＫＢ）を用いた処理における効率的
処理を実現する情報処理システムおよび方法を実現す
る。 【解決手段】 カテゴリ区分され、カテゴリ・エンティ
テイによって管理されるサブツリーを複数有するキーツ
リーの選択パス上の下位キーによる上位キーの暗号化処
理データからなるＥＫＢを生成してデバイスに提供する
構成において、ＥＫＢタイプ定義リストに定義されたＥ
ＫＢの処理可能なカテゴリツリーにおけるリボーク等に
よる状態変化発生に関する通知をＥＫＢ利用エンティテ
イに対して実行する構成とし、ＥＫＢリクエスタは常に
最新のＥＫＢに基づく処理が可能となる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、情報処理システ
ム、および情報処理方法、並びにプログラム記録媒体に
関し、特に、コンテンツなど各種データを特定の正当な
ユーザに提供する暗号処理を伴う配信システムおよび方
法に関する。特に、木（ツリー）構造の階層的鍵配信方
式を用い、配信デバイスに応じて生成したキーブロック
を用いて、例えばコンテンツの暗号化キーとしてのコン
テンツキー配信、あるいはその他各種の安全性を保持す
ることを可能とする情報処理システム、および情報処理
方法、並びにプログラム記録媒体に関する。
【０００２】
【従来の技術】昨今、ゲームプログラム、音声データ、
画像データ等、様々なソフトウエアデータ（以下、これ
らをコンテンツ（Content）と呼ぶ）を、インターネッ
ト等のネットワーク、あるいはＤＶＤ、ＣＤ等の流通可
能な記憶媒体を介しての流通が盛んになってきている。
これらの流通コンテンツは、ユーザの所有するＰＣ（Pe
rsonal Computer）、ゲーム機器によってデータ受信、
あるいは記憶媒体の装着がなされて再生されたり、ある
いはＰＣ等に付属する記録再生機器内の記録デバイス、
例えばメモリカード、ハードディスク等に格納されて、
格納媒体からの新たな再生により利用される。
【０００３】ビデオゲーム機器、ＰＣ等の情報機器に
は、流通コンテンツをネットワークから受信するため、
あるいはＤＶＤ、ＣＤ等にアクセスするためのインタフ
ェースを有し、さらにコンテンツの再生に必要となる制
御手段、プログラム、データのメモリ領域として使用さ
れるＲＡＭ、ＲＯＭ等を有する。
【０００４】音楽データ、画像データ、あるいはプログ
ラム等の様々なコンテンツは、再生機器として利用され
るゲーム機器、ＰＣ等の情報機器本体からのユーザ指
示、あるいは接続された入力手段を介したユーザの指示
により記憶媒体から呼び出され、情報機器本体、あるい
は接続されたディスプレイ、スピーカ等を通じて再生さ
れる。
【０００５】ゲームプログラム、音楽データ、画像デー
タ等、多くのソフトウエア・コンテンツは、一般的にそ
の作成者、販売者に頒布権等が保有されている。従っ
て、これらのコンテンツの配布に際しては、一定の利用
制限、すなわち、正規なユーザに対してのみ、ソフトウ
エアの使用を許諾し、許可のない複製等が行われないよ
うにする、すなわちセキュリティを考慮した構成をとる
のが一般的となっている。
【０００６】ユーザに対する利用制限を実現する１つの
手法が、配布コンテンツの暗号化処理である。すなわ
ち、例えばインターネット等を介して暗号化された音声
データ、画像データ、ゲームプログラム等の各種コンテ
ンツを配布するとともに、正規ユーザであると確認され
た者に対してのみ、配布された暗号化コンテンツを復号
する手段、すなわち復号鍵を付与する構成である。
【０００７】暗号化データは、所定の手続きによる復号
化処理によって利用可能な復号データ（平文）に戻すこ
とができる。このような情報の暗号化処理に暗号化鍵を
用い、復号化処理に復号化鍵を用いるデータ暗号化、復
号化方法は従来からよく知られている。
【０００８】暗号化鍵と復号化鍵を用いるデータ暗号化
・復号化方法の態様には様々な種類あるが、その１つの
例としていわゆる共通鍵暗号化方式と呼ばれている方式
がある。共通鍵暗号化方式は、データの暗号化処理に用
いる暗号化鍵とデータの復号化に用いる復号化鍵を共通
のものとして、正規のユーザにこれら暗号化処理、復号
化に用いる共通鍵を付与して、鍵を持たない不正ユーザ
によるデータアクセスを排除するものである。この方式
の代表的な方式にＤＥＳ（データ暗号標準：Deta encry
ption standard）がある。
【０００９】上述の暗号化処理、復号化に用いられる暗
号化鍵、復号化鍵は、例えばあるパスワード等に基づい
てハッシュ関数等の一方向性関数を適用して得ることが
できる。一方向性関数とは、その出力から逆に入力を求
めるのは非常に困難となる関数である。例えばユーザが
決めたパスワードを入力として一方向性関数を適用し
て、その出力に基づいて暗号化鍵、復号化鍵を生成する
ものである。このようにして得られた暗号化鍵、復号化
鍵から、逆にそのオリジナルのデータであるパスワード
を求めることは実質上不可能となる。
【００１０】また、暗号化するときに使用する暗号化鍵
による処理と、復号するときに使用する復号化鍵の処理
とを異なるアルゴリズムとした方式がいわゆる公開鍵暗
号化方式と呼ばれる方式である。公開鍵暗号化方式は、
不特定のユーザが使用可能な公開鍵を使用する方法であ
り、特定個人に対する暗号化文書を、その特定個人が発
行した公開鍵を用いて暗号化処理を行なう。公開鍵によ
って暗号化された文書は、その暗号化処理に使用された
公開鍵に対応する秘密鍵によってのみ復号処理が可能と
なる。秘密鍵は、公開鍵を発行した個人のみが所有する
ので、その公開鍵によって暗号化された文書は秘密鍵を
持つ個人のみが復号することができる。公開鍵暗号化方
式の代表的なものにはＲＳＡ（Rivest-Shamir-Adlema
n）暗号がある。このような暗号化方式を利用すること
により、暗号化コンテンツを正規ユーザに対してのみ復
号可能とするシステムが可能となる。
【００１１】
【発明が解決しようとする課題】上記のようなコンテン
ツ配信システムでは、コンテンツを暗号化してユーザに
ネットワーク、あるいはＤＶＤ、ＣＤ等の記録媒体に格
納して提供し、暗号化コンテンツを復号するコンテンツ
キーを正当なユーザにのみ提供する構成が多く採用され
ている。コンテンツキー自体の不正なコピー等を防ぐた
め、コンテンツキーを暗号化して正当なユーザに提供
し、正当なユーザのみが有する復号キーを用いて暗号化
コンテンツキーを復号してコンテンツキーを使用可能と
する構成が提案されている。
【００１２】正当なユーザであるか否かの判定は、一般
には、例えばコンテンツの送信者であるコンテンツプロ
バイダとユーザデバイス間において、コンテンツ、ある
いはコンテンツキーの配信前に認証処理を実行すること
によって可能となる。一般的な認証処理においては、相
手の確認を行なうとともに、その通信でのみ有効なセッ
ションキーを生成して、認証が成立した場合に、生成し
たセッションキーを用いてデータ、例えばコンテンツあ
るいはコンテンツキーを暗号化して通信を行なう。認証
方式には、共通鍵暗号方式を用いた相互認証と、公開鍵
方式を使用した認証方式があるが、共通鍵を使った認証
においては、システムワイドで共通な鍵が必要になり、
更新処理等の際に不便である。また、公開鍵方式におい
ては、計算負荷が大きくまた必要なメモリ量も大きくな
り、各デバイスにこのような処理手段を設けることは望
ましい構成とはいえない。
【００１３】本発明では、上述のようなデータの送信
者、受信者間の相互認証処理に頼ることなく、正当なユ
ーザに対してのみ、安全にデータを送信することを可能
とするとともに、階層的鍵配信ツリーをカテゴリ単位と
したサブツリー、すなわちカテゴリツリーを形成し、複
数のカテゴリツリー内で適用（復号処理）可能な暗号化
キーブロックを使用する構成を提案する。
【００１４】さらに、１以上の選択されたカテゴリツリ
ーにおいて復号可能な暗号化鍵データブロックである有
効化キーブロック（ＥＫＢ）を生成して各カテゴリツリ
ーに属するデバイスにおいて共通に使用可能とするとと
もに、どのカテゴリツリーで処理可能、すなわち復号可
能であるかを示すＥＫＢタイプ定義リストを使用するこ
とにより、ＥＫＢ生成、管理処理の効率化を可能とした
情報処理システム、および情報処理方法、並びにプログ
ラム記録媒体を提供することを目的とする。
【００１５】さらに、ＥＫＢタイプ定義リストに定義さ
れたＥＫＢの処理可能なカテゴリツリーにおける状態変
化発生に関する通知処理を、ＥＫＢの利用エンティテイ
に対して実行することにより、最新のＥＫＢタイプ定義
情報に基づく処理を可能とした情報処理システム、およ
び情報処理方法、並びにプログラム記録媒体を提供する
ことを目的とする。
【００１６】
【課題を解決するための手段】本発明の第１の側面は、
複数のデバイスをリーフとして構成したツリーのルート
からリーフまでのパス上のルート、ノード、およびリー
フに各々キーを対応付けたキーツリーを構成し、該キー
ツリーを構成するパスを選択して選択パス上の下位キー
による上位キーの暗号化処理データを有し、前記選択パ
スに対応するノードキーセットを利用可能なデバイスに
おいてのみ復号可能とした有効化キーブロック（ＥＫ
Ｂ）をデバイスに提供する構成を持つ情報処理システム
であり、前記キーツリーは、カテゴリに基づいて区分さ
れ、カテゴリ・エンティテイによって管理されるサブツ
リーとしてのカテゴリツリーを複数有する構成であり、
カテゴリツリーにおいて共通に復号処理可能なＥＫＢを
生成して発行するキー発行センター（ＫＤＣ）は、ＥＫ
Ｂタイプ識別子と、ＥＫＢ処理可能なカテゴリツリーの
識別データとを対応付けたＥＫＢタイプ定義リストを有
し、前記ＥＫＢタイプ定義リストに定義されたＥＫＢの
処理可能なカテゴリツリーにおける状態変化発生に関す
る通知処理を、少なくとも前記状態変化発生カテゴリツ
リーを処理可能カテゴリツリーとして設定したＥＫＢの
利用エンティテイに対して実行する構成を有することを
特徴とする情報処理システムにある。
【００１７】さらに、本発明の情報処理システムの一実
施態様において、前記カテゴリツリーにおける状態変化
は、該カテゴリツリーにおけるリボーク（機器排除）発
生に伴う状態変化であることを特徴とする。
【００１８】さらに、本発明の情報処理システムの一実
施態様において、前記カテゴリツリーにおける状態変化
は、該カテゴリツリーに属するデバイスのデバイス格納
キーの変更に伴う状態変化であることを特徴とする。
【００１９】さらに、本発明の情報処理システムの一実
施態様において、前記ＥＫＢの利用エンティテイは、前
記キー発行センター（ＫＤＣ）に対するＥＫＢ生成要求
エンティテイとしてのＥＫＢリクエスタを含むことを特
徴とする。
【００２０】さらに、本発明の情報処理システムの一実
施態様において、前記ＥＫＢの利用エンティテイは、前
記ＥＫＢタイプ定義リスト中に定義されたＥＫＢ処理可
能なカテゴリツリーの管理エンティテイとしてのカテゴ
リ・エンティテイを含むことを特徴とする。
【００２１】さらに、本発明の情報処理システムの一実
施態様において、前記キー発行センター（ＫＤＣ）は、
前記状態変化発生に関する通知処理を、前記ＥＫＢタイ
プ定義リストの利用エンティテイである前記キー発行セ
ンター（ＫＤＣ）に対するＥＫＢ生成要求エンティテイ
としてのＥＫＢリクエスタ、およびカテゴリツリーの管
理エンティテイとしてのカテゴリ・エンティテイすべて
に対して実行することを特徴とする。
【００２２】さらに、本発明の情報処理システムの一実
施態様において、前記キー発行センター（ＫＤＣ）は、
カテゴリツリーにおける状態変化発生情報を、該カテゴ
リツリーの管理エンティテイであるカテゴリ・エンティ
テイから受信し、該カテゴリ・エンティテイからの状態
変化発生情報受信に基づいて、状態変化発生に関する通
知処理を実行する構成を有することを特徴とする。
【００２３】さらに、本発明の第２の側面は、カテゴリ
に基づいて区分され、カテゴリ・エンティテイによって
管理されるサブツリーとしてのカテゴリツリーを複数有
し、デバイスをリーフとして構成したツリーのルートか
らリーフまでのパス上のルート、ノード、およびリーフ
に各々キーを対応付けたキーツリーを構成し、該キーツ
リーを構成するパスを選択して選択パス上の下位キーに
よる上位キーの暗号化処理データを有し、前記選択パス
に対応するノードキーセットを利用可能なデバイスにお
いてのみ復号可能とした有効化キーブロック（ＥＫＢ）
をデバイスに提供する構成を持つシステムにおける情報
処理方法であり、カテゴリツリーにおいて共通に復号処
理可能なＥＫＢを生成して発行するキー発行センター
（ＫＤＣ）は、ＥＫＢタイプ識別子と、ＥＫＢ処理可能
なカテゴリツリーの識別データとを対応付けたＥＫＢタ
イプ定義リストに定義されたＥＫＢの処理可能なカテゴ
リツリーにおける状態変化発生に関する通知処理を、少
なくとも前記状態変化発生カテゴリツリーを処理可能カ
テゴリツリーとして設定したＥＫＢの利用エンティテイ
に対して実行することを特徴とする情報処理方法にあ
る。
【００２４】さらに、本発明の情報処理方法の一実施態
様において、前記カテゴリツリーにおける状態変化は、
該カテゴリツリーにおけるリボーク（機器排除）発生に
伴う状態変化であることを特徴とする。
【００２５】さらに、本発明の情報処理方法の一実施態
様において、前記カテゴリツリーにおける状態変化は、
該カテゴリツリーに属するデバイスのデバイス格納キー
の変更に伴う状態変化であることを特徴とする。
【００２６】さらに、本発明の情報処理方法の一実施態
様において、前記ＥＫＢの利用エンティテイは、前記キ
ー発行センター（ＫＤＣ）に対するＥＫＢ生成要求エン
ティテイとしてのＥＫＢリクエスタを含むことを特徴と
する。
【００２７】さらに、本発明の情報処理方法の一実施態
様において、前記ＥＫＢの利用エンティテイは、前記Ｅ
ＫＢタイプ定義リスト中に定義されたＥＫＢ処理可能な
カテゴリツリーの管理エンティテイとしてのカテゴリ・
エンティテイを含むことを特徴とする。
【００２８】さらに、本発明の情報処理方法の一実施態
様において、前記キー発行センター（ＫＤＣ）は、前記
状態変化発生に関する通知処理を、前記ＥＫＢタイプ定
義リストの利用エンティテイである前記キー発行センタ
ー（ＫＤＣ）に対するＥＫＢ生成要求エンティテイとし
てのＥＫＢリクエスタ、およびカテゴリツリーの管理エ
ンティテイとしてのカテゴリ・エンティテイすべてに対
して実行することを特徴とする。
【００２９】さらに、本発明の情報処理方法の一実施態
様において、前記キー発行センター（ＫＤＣ）は、カテ
ゴリツリーにおける状態変化発生情報を、該カテゴリツ
リーの管理エンティテイであるカテゴリ・エンティテイ
から受信し、該カテゴリ・エンティテイからの状態変化
発生情報受信に基づいて、状態変化発生に関する通知処
理を実行する構成を有することを特徴とする。
【００３０】さらに、本発明の第３の側面は、カテゴリ
に基づいて区分され、カテゴリ・エンティテイによって
管理されるサブツリーとしてのカテゴリツリーを複数有
し、デバイスをリーフとして構成したツリーのルートか
らリーフまでのパス上のルート、ノード、およびリーフ
に各々キーを対応付けたキーツリーを構成し、該キーツ
リーを構成するパスを選択して選択パス上の下位キーに
よる上位キーの暗号化処理データを有し、前記選択パス
に対応するノードキーセットを利用可能なデバイスにお
いてのみ復号可能とした有効化キーブロック（ＥＫＢ）
をデバイスに提供する構成を持つシステムにおける情報
処理をコンピュータ・システム上で実行せしめるコンピ
ュータ・プログラムを記録したプログラム記録媒体であ
って、前記コンピュータ・プログラムは、カテゴリツリ
ーにおける状態変化発生情報を、該カテゴリツリーの管
理エンティテイであるカテゴリ・エンティテイから受信
するステップと、該カテゴリ・エンティテイからの状態
変化発生情報受信に基づいて、状態変化発生に関する通
知処理を少なくとも前記状態変化発生カテゴリツリーを
処理可能カテゴリツリーとして設定したＥＫＢの利用エ
ンティテイに対して実行するステップと、を有すること
を特徴とするプログラム記録媒体にある。
【００３１】
【作用】本発明の構成においては、ツリー（木）構造の
階層的構造の暗号化鍵配信構成を用い、各機器をｎ分木
の各葉（リーフ）に配置した構成の鍵配信方法を用い、
記録媒体もしくは通信回線を介して、例えばコンテンツ
データの暗号鍵であるコンテンツキーもしくは認証処理
に用いる認証キー、あるいはプログラムコード等を有効
化キーブロックとともに配信する構成としている。
【００３２】さらに、有効化キーブロックを暗号化キー
データ部と、暗号化キーの位置を示すタグ部てによって
構成し、データ量を少なくし、デバイスにおける復号処
理を用意かつ迅速に実行することを可能としている。本
構成により、正当なデバイスのみが復号可能なデータを
安全に配信することが可能となる。
【００３３】さらに、１以上の選択されたカテゴリツリ
ーにおいて復号可能な暗号化鍵データブロックである有
効化キーブロック（ＥＫＢ）を生成して各カテゴリツリ
ーに属するデバイスに共通に使用可能とするとともに、
どのカテゴリツリーで処理可能、すなわち復号可能であ
るかを示すＥＫＢタイプ定義リストを使用することによ
り、ＥＫＢの生成管理処理の効率化を可能としている。
【００３４】なお、本発明のプログラム記録媒体は、例
えば、様々なプログラム・コードを実行可能な汎用コン
ピュータ・システムに対して、コンピュータ・プログラ
ムをコンピュータ可読な形式で提供する媒体である。媒
体は、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネ
ットワークなどの伝送媒体など、その形態は特に限定さ
れない。
【００３５】このようなプログラム記録媒体は、コンピ
ュータ・システム上で所定のコンピュータ・プログラム
の機能を実現するための、コンピュータ・プログラムと
記録媒体との構造上又は機能上の協働的関係を定義した
ものである。換言すれば、該記録媒体を介してコンピュ
ータ・プログラムをコンピュータ・システムにインスト
ールすることによって、コンピュータ・システム上では
協働的作用が発揮され、本発明の他の側面と同様の作用
効果を得ることができるのである。
【００３６】なお、本発明の説明中におけるシステムと
は、複数の装置の論理的集合構成であり、各構成の装置
が同一筐体内にあるものには限らない。
【００３７】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。
【００３８】
【発明の実施の形態】［システム概要］図１に本発明の
情報処理システムが適用可能なコンテンツ配信システム
例を示す。コンテンツの配信側１０は、コンテンツ受信
側２０の有する様々なコンテンツ再生可能な機器に対し
てコンテンツ、あるいはコンテンツキーを暗号化して送
信する。受信側２０における機器では、受信した暗号化
コンテンツ、あるいは暗号化コンテンツキー等を復号し
てコンテンツあるいはコンテンツキーを取得して、画像
データ、音声データの再生、あるいは各種プログラムの
実行等を行なう。コンテンツの配信側１０とコンテンツ
受信側２０との間のデータ交換は、インターネット等の
ネットワークを介して、あるいはＤＶＤ、ＣＤ等の流通
可能な記憶媒体を介して実行される。
【００３９】コンテンツ配信側１０のデータ配信手段と
しては、インターネット１１、衛星放送１２、電話回線
１３、ＤＶＤ、ＣＤ等のメディア１４等があり、一方、
コンテンツ受信側２０のデバイスとしては、パーソナル
コンピュータ（ＰＣ）２１、ポータブルデバイス（Ｐ
Ｄ）２２、携帯電話、ＰＤＡ（Personal Digital Assis
tants）等の携帯機器２３、ＤＶＤ、ＣＤプレーヤ等の
記録再生器２４、ゲーム端末等の再生専用器２５等があ
る。これらコンテンツ受信側２０の各デバイスは、コン
テンツ配信側１０から提供されたコンテンツをネットワ
ーク等の通信手段あるいは、あるいはメディア３０から
取得する。
【００４０】［デバイス構成］図２に、図１に示すコン
テンツ受信側２０のデバイスの一例として、記録再生装
置１００の構成ブロック図を示す。記録再生装置１００
は、入出力Ｉ／Ｆ(Interface)１２０、ＭＰＥＧ(Moving
Picture Experts Group)コーデック１３０、Ａ／Ｄ，
Ｄ／Ａコンバータ１４１を備えた入出力Ｉ／Ｆ(Interfa
ce)１４０、暗号処理手段１５０、ＲＯＭ（Read Only M
emory）１６０、ＣＰＵ(Central Processing Unit)１７
０、メモリ１８０、記録媒体１９５のドライブ１９０を
有し、これらはバス１１０によって相互に接続されてい
る。
【００４１】入出力Ｉ／Ｆ１２０は、外部から供給され
る画像、音声、プログラム等の各種コンテンツを構成す
るディジタル信号を受信し、バス１１０上に出力すると
ともに、バス１１０上のディジタル信号を受信し、外部
に出力する。ＭＰＥＧコーデック１３０は、バス１１０
を介して供給されるＭＰＥＧ符号化されたデータを、Ｍ
ＰＥＧデコードし、入出力Ｉ／Ｆ１４０に出力するとと
もに、入出力Ｉ／Ｆ１４０から供給されるディジタル信
号をＭＰＥＧエンコードしてバス１１０上に出力する。
入出力Ｉ／Ｆ１４０は、Ａ／Ｄ，Ｄ／Ａコンバータ１４
１を内蔵している。入出力Ｉ／Ｆ１４０は、外部から供
給されるコンテンツとしてのアナログ信号を受信し、Ａ
／Ｄ，Ｄ／Ａコンバータ１４１でＡ／Ｄ(Analog Digita
l)変換することで、ディジタル信号として、ＭＰＥＧコ
ーデック１３０に出力するとともに、ＭＰＥＧコーデッ
ク１３０からのディジタル信号を、Ａ／Ｄ，Ｄ／Ａコン
バータ１４１でＤ／Ａ(Digital Analog)変換すること
で、アナログ信号として、外部に出力する。
【００４２】暗号処理手段１５０は、例えば、１チップ
のＬＳＩ(Large Scale IntegratedCurcuit)で構成さ
れ、バス１１０を介して供給されるコンテンツとしての
ディジタル信号の暗号化、復号処理、あるいは認証処理
を実行し、暗号データ、復号データ等をバス１１０上に
出力する構成を持つ。なお、暗号処理手段１５０は１チ
ップＬＳＩに限らず、各種のソフトウェアまたはハード
ウェアを組み合わせた構成によって実現することも可能
である。ソフトウェア構成による処理手段としての構成
については後段で説明する。
【００４３】ＲＯＭ１６０は、記録再生装置によって処
理されるプログラムデータを格納する。ＣＰＵ１７０
は、ＲＯＭ１６０、メモリ１８０に記憶されたプログラ
ムを実行することで、ＭＰＥＧコーデック１３０や暗号
処理手段１５０等を制御する。メモリ１８０は、例え
ば、不揮発性メモリで、ＣＰＵ１７０が実行するプログ
ラムや、ＣＰＵ１７０の動作上必要なデータ、さらにデ
バイスによって実行される暗号処理に使用されるキーセ
ットを記憶する。キーセットについては後段で説明す
る。ドライブ１９０は、デジタルデータを記録再生可能
な記録媒体１９５を駆動することにより、記録媒体１９
５からディジタルデータを読み出し（再生し）、バス１
１０上に出力するとともに、バス１１０を介して供給さ
れるディジタルデータを、記録媒体１９５に供給して記
録させる。
【００４４】記録媒体１９５は、例えば、ＤＶＤ、ＣＤ
等の光ディスク、光磁気ディスク、磁気ディスク、磁気
テープ、あるいはＲＡＭ等の半導体メモリ等のディジタ
ルデータの記憶可能な媒体であり、本実施の形態では、
ドライブ１９０に対して着脱可能な構成であるとする。
但し、記録媒体１９５は、記録再生装置１００に内蔵す
る構成としてもよい。
【００４５】なお、図２に示す暗号処理手段１５０は、
１つのワンチップＬＳＩとして構成してもよく、また、
ソフトウェア、ハードウェアを組み合わせた構成によっ
て実現する構成としてもよい。
【００４６】［キー配信構成としてのツリー（木）構造
について］次に、図１に示すコンテンツ配信側１０から
コンテンツ受信側２０の各デバイスに暗号データを配信
する場合における各デバイスにおける暗号処理鍵の保有
構成およびデータ配信構成を図３を用いて説明する。
【００４７】図３の最下段に示すナンバ０〜１５がコン
テンツ受信側２０の個々のデバイスである。すなわち図
３に示す階層ツリー（木）構造の各葉(リーフ：leaf)が
それぞれのデバイスに相当する。
【００４８】各デバイス０〜１５は、製造時あるいは出
荷時、あるいはその後において、図３に示す階層ツリー
（木）構造における、自分のリーフからルートに至るま
でのノードに割り当てられた鍵（ノードキー）および各
リーフのリーフキーからなるキーセットをメモリに格納
する。図３の最下段に示すＫ００００〜Ｋ１１１１が各
デバイス０〜１５にそれぞれ割り当てられたリーフキー
であり、最上段のＫＲ（ルートキー）から、最下段から
２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１
１をノードキーとする。
【００４９】図３に示すツリー構成において、例えばデ
バイス０はリーフキーＫ００００と、ノードキー：Ｋ０
００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ
０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。
デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ
１、ＫＲを所有する。なお、図３のツリーにはデバイス
が０〜１５の１６個のみ記載され、ツリー構造も４段構
成の均衡のとれた左右対称構成として示しているが、さ
らに多くのデバイスがツリー中に構成され、また、ツリ
ーの各部において異なる段数構成を持つことが可能であ
る。
【００５０】また、図３のツリー構造に含まれる各デバ
イスには、様々な記録媒体、例えば、デバイス埋め込み
型あるいはデバイスに着脱自在に構成されたＤＶＤ、Ｃ
Ｄ、ＭＤ、フラッシュメモリ等を使用する様々なタイプ
のデバイスが含まれている。さらに、様々なアプリケー
ションサービスが共存可能である。このような異なるデ
バイス、異なるアプリケーションの共存構成の上に図３
に示すコンテンツあるいは鍵配布構成である階層ツリー
構造が適用される。
【００５１】これらの様々なデバイス、アプリケーショ
ンが共存するシステムにおいて、例えば図３の点線で囲
んだ部分、すなわちデバイス０，１，２，３を同一の記
録媒体を用いる１つのグループとして設定する。例え
ば、この点線で囲んだグループ内に含まれるデバイスに
対しては、まとめて、共通のコンテンツを暗号化してプ
ロバイダから送付したり、各デバイス共通に使用するコ
ンテンツキーを送付したり、あるいは各デバイスからプ
ロバイダあるいは決済機関等にコンテンツ料金の支払デ
ータをやはり暗号化して出力するといった処理が実行さ
れる。コンテンツプロバイダ、あるいは決済処理機関
等、各デバイスとのデータ送受信を行なう機関は、図３
の点線で囲んだ部分、すなわちデバイス０，１，２，３
を１つのグループとして一括してデータを送付する処理
を実行する。このようなグループは、図３のツリー中に
複数存在する。コンテンツプロバイダ、あるいは決済処
理機関等、各デバイスとのデータ送受信を行なう機関
は、メッセージデータ配信手段として機能する。
【００５２】なお、ノードキー、リーフキーは、ある１
つの鍵管理センタによって統括して管理してもよいし、
各グループに対する様々なデータ送受信を行なうプロバ
イダ、決済機関等のメッセージデータ配信手段によって
グループごとに管理する構成としてもよい。これらのノ
ードキー、リーフキーは例えばキーの漏洩等の場合に更
新処理が実行され、この更新処理は鍵管理センタ、プロ
バイダ、決済機関等が実行する。
【００５３】このツリー構造において、図３から明らか
なように、１つのグループに含まれる３つのデバイス
０，１，２，３はノードキーとして共通のキーＫ００、
Ｋ０、ＫＲを保有する。このノードキー共有構成を利用
することにより、例えば共通のコンテンツキーをデバイ
ス０，１，２，３のみに提供することが可能となる。た
とえば、共通に保有するノードキーＫ００自体をコンテ
ンツキーとして設定すれば、新たな鍵送付を実行するこ
となくデバイス０，１，２，３のみが共通のコンテンツ
キーの設定が可能である。また、新たなコンテンツキー
ＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ
００，Ｋｃｏｎ）を、ネットワークを介してあるいは記
録媒体に格納してデバイス０，１，２，３に配布すれ
ば、デバイス０，１，２，３のみが、それぞれのデバイ
スにおいて保有する共有ノードキーＫ００を用いて暗号
Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキー：
Ｋｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋ
ａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであ
ることを示す。
【００５４】また、ある時点ｔにおいて、デバイス３の
所有する鍵：Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,ＫＲが
攻撃者（ハッカー）により解析されて露呈したことが発
覚した場合、それ以降、システム（デバイス０，１，
２，３のグループ）で送受信されるデータを守るため
に、デバイス３をシステムから切り離す必要がある。そ
のためには、ノードキー：Ｋ００１,Ｋ００,Ｋ０,ＫＲ
をそれぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ
（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２に
その更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａ
ａａは、鍵Ｋａａａの世代（Generation）：ｔの更新キ
ーであることを示す。
【００５５】更新キーの配布処理ついて説明する。キー
の更新は、例えば、図４（Ａ）に示す有効化キーブロッ
ク（ＥＫＢ：Enabling Key Block）と呼ばれるブロック
データによって構成されるテーブルをたとえばネットワ
ーク、あるいは記録媒体に格納してデバイス０，１，２
に供給することによって実行される。なお、有効化キー
ブロック（ＥＫＢ）は、図３に示すようなツリー構造を
構成する各リーフに対応するデバイスに新たに更新され
たキーを配布するための暗号化キーによって構成され
る。有効化キーブロック（ＥＫＢ）は、キー更新ブロッ
ク（ＫＲＢ：KeyRenewal Block）と呼ばれることもあ
る。
【００５６】図４（Ａ）に示す有効化キーブロック（Ｅ
ＫＢ）には、ノードキーの更新の必要なデバイスのみが
更新可能なデータ構成を持つブロックデータとして構成
される。図４の例は、図３に示すツリー構造中のデバイ
ス０，１，２において、世代ｔの更新ノードキーを配布
することを目的として形成されたブロックデータであ
る。図３から明らかなように、デバイス０，デバイス１
は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、
Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキ
ーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、
Ｋ（ｔ）Ｒが必要である。
【００５７】図４（Ａ）のＥＫＢに示されるようにＥＫ
Ｂには複数の暗号化キーが含まれる。最下段の暗号化キ
ーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。
これはデバイス２の持つリーフキーＫ００１０によって
暗号化された更新ノードキーＫ（ｔ）００１であり、デ
バイス２は、自身の持つリーフキーによってこの暗号化
キーを復号し、Ｋ（ｔ）００１を得ることができる。ま
た、復号により得たＫ（ｔ）００１を用いて、図４
（Ａ）の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）０
０１，Ｋ（ｔ）００）を復号可能となり、更新ノードキ
ーＫ（ｔ）００を得ることができる。以下順次、図４
（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）０
０，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）
０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ
（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。一
方、デバイスＫ００００．Ｋ０００１は、ノードキーＫ
０００は更新する対象に含まれておらず、更新ノードキ
ーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ
（ｔ）Ｒである。デバイスＫ００００．Ｋ０００１は、
図４（Ａ）の上から３段目の暗号化キーＥｎｃ（Ｋ００
０，Ｋ（ｔ）００）を復号しＫ（ｔ）００、を取得し、
以下、図４（Ａ）の上から２段目の暗号化キーＥｎｃ
（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキ
ーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キー
Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒ
を得る。このようにして、デバイス０，１，２は更新し
た鍵Ｋ（ｔ）Ｒを得ることができる。なお、図４（Ａ）
のインデックスは、復号キーとして使用するノードキ
ー、リーフキーの絶対番地を示す。
【００５８】図３に示すツリー構造の上位段のノードキ
ー：Ｋ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノー
ドキーＫ００のみの更新処理が必要である場合には、図
４（Ｂ）の有効化キーブロック（ＥＫＢ）を用いること
で、更新ノードキーＫ（ｔ）００をデバイス０，１，２
に配布することができる。
【００５９】図４（Ｂ）に示すＥＫＢは、例えば特定の
グループにおいて共有する新たなコンテンツキーを配布
する場合に利用可能である。具体例として、図３に点線
で示すグループ内のデバイス０，１，２，３がある記録
媒体を用いており、新たな共通のコンテンツキーＫ
（ｔ）ｃｏｎが必要であるとする。このとき、デバイス
０，１，２，３の共通のノードキーＫ００を更新したＫ
（ｔ）００を用いて新たな共通の更新コンテンツキー：
Ｋ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ），
Ｋ（ｔ）ｃｏｎ）を図４（Ｂ）に示すＥＫＢとともに配
布する。この配布により、デバイス４など、その他のグ
ループの機器においては復号されないデータとしての配
布が可能となる。
【００６０】すなわち、デバイス０，１，２はＥＫＢを
処理して得たＫ（ｔ）００を用いて上記暗号文を復号す
れば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る
ことが可能になる。
【００６１】［ＥＫＢを使用したコンテンツキーの配
布］図５に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎ
を得る処理例として、Ｋ（ｔ）００を用いて新たな共通
のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥ
ｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と図４（Ｂ）に
示すＥＫＢとを記録媒体を介して受領したデバイス０の
処理を示す。すなわちＥＫＢによる暗号化メッセージデ
ータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【００６２】図５に示すように、デバイス０は、記録媒
体に格納されている世代：t時点のＥＫＢと自分があら
かじめ格納しているノードキーＫ０００を用いて上述し
たと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００
を生成する。さらに、復号した更新ノードキーＫ（ｔ）
００を用いて更新コンテンツキーＫ（ｔ）ｃｏｎを復号
して、後にそれを使用するために自分だけが持つリーフ
キーＫ００００で暗号化して格納する。
【００６３】［ＥＫＢのフォーマット］図６に有効化キ
ーブロック（ＥＫＢ）のフォーマット例を示す。バージ
ョン６０１は、有効化キーブロック（ＥＫＢ）のバージ
ョンを示す識別子である。なお、バージョンは最新のＥ
ＫＢを識別する機能とコンテンツとの対応関係を示す機
能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の
配布先のデバイスに対する階層ツリーの階層数を示す。
データポインタ６０３は、有効化キーブロック（ＥＫ
Ｂ）中のデータ部の位置を示すポインタであり、タグポ
インタ６０４はタグ部の位置、署名ポインタ６０５は署
名の位置を示すポインタである。
【００６４】データ部６０６は、例えば更新するノード
キーを暗号化したデータを格納する。例えば図５に示す
ような更新されたノードキーに関する各暗号化キー等を
格納する。
【００６５】タグ部６０７は、データ部に格納された暗
号化されたノードキー、リーフキーの位置関係を示すタ
グである。このタグの付与ルールを図７を用いて説明す
る。図７では、データとして先に図４（Ａ）で説明した
有効化キーブロック（ＥＫＢ）を送付する例を示してい
る。この時のデータは、図７の表（ｂ）に示すようにな
る。このときの暗号化キーに含まれるトップノードのア
ドレスをトップノードアドレスとする。この場合は、ル
ートキーの更新キーＫ（ｔ）Ｒが含まれているので、ト
ップノードアドレスはＫＲとなる。このとき、例えば最
上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図
７の（ａ）に示す階層ツリーに示す位置にある。ここ
で、次のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）
０）であり、ツリー上では前のデータの左下の位置にあ
る。データがある場合は、タグが０、ない場合は１が設
定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝とし
て設定される。最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ
（ｔ）Ｒ）の左にはデータがあるので、Ｌタグ＝０、右
にはデータがないので、Ｒタグ＝１となる。以下、すべ
てのデータにタグが設定され、図７（ｃ）に示すデータ
列、およびタグ列が構成される。
【００６６】タグは、データＥｎｃ（Ｋｘｘｘ，Ｋｙｙ
ｙ）がツリー構造のどこに位置しているのかを示すため
に設定されるものである。データ部に格納されるキーデ
ータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）．．．は、単純に暗
号化されたキーの羅列データに過ぎないので、上述した
タグによってデータとして格納された暗号化キーのツリ
ー上の位置を判別可能としたものである。上述したタグ
を用いずに、先の図４で説明した構成のように暗号化デ
ータに対応させたノード・インデックスを用いて、例え
ば、 ０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ） ００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０） ０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（Ｔ）００） ．．．のようなデータ構成とすることも可能であるが、
このようなインデックスを用いた構成とすると冗長なデ
ータとなりデータ量が増大し、ネットワークを介する配
信等においては好ましくない。これに対し、上述したタ
グをキー位置を示す索引データとして用いることによ
り、少ないデータ量でキー位置の判別が可能となる。
【００６７】図６に戻って、ＥＫＢフォーマットについ
てさらに説明する。署名（Signature）は、有効化キー
ブロック（ＥＫＢ）を発行した例えば鍵管理センタ、コ
ンテンツロバイダ、決済機関等が実行する電子署名であ
る。ＥＫＢを受領したデバイスは署名検証によって正当
な有効化キーブロック（ＥＫＢ）発行者が発行した有効
化キーブロック（ＥＫＢ）であることを確認する。
【００６８】［ＥＫＢを使用したコンテンツキーおよび
コンテンツの配信］上述の例では、コンテンツキーのみ
をＥＫＢとともに送付する例について説明したが、コン
テンツキーで暗号化したコンテンツと、コンテンツキー
暗号キーで暗号化したコンテンツキーと、ＥＫＢによっ
て暗号化したコンテンツキー暗号鍵を併せて送付する構
成について以下説明する。
【００６９】図８にこのデータ構成を示す。図８（ａ）
に示す構成において、Ｅｎｃ（Ｋｃｏｎ，ｃｏｎｔｅｎ
ｔ）８０１は、コンテンツ（Content）をコンテンツキ
ー（Ｋｃｏｎ）で暗号化したデータであり、Ｅｎｃ（Ｋ
ＥＫ，Ｋｃｏｎ）８０２は、コンテンツキー（Ｋｃｏ
ｎ）をコンテンツキー暗号キー（ＫＥＫ：Key Encrypti
on Key）で暗号化したデータであり、Ｅｎｃ（ＥＫＢ，
ＫＥＫ）８０３は、コンテンツキー暗号キーＫＥＫを有
効化キーブロック（ＥＫＢ）によって暗号化したデータ
であることを示す。
【００７０】ここで、コンテンツキー暗号キーＫＥＫ
は、図３で示すノードキー（Ｋ０００，Ｋ００…）、あ
るいはルートキー（ＫＲ）自体であってもよく、またノ
ードキー（Ｋ０００，Ｋ００…）、あるいはルートキー
（ＫＲ）によって暗号化されたキーであってもよい。
【００７１】図８（ｂ）は、複数のコンテンツがメディ
アに記録され、それぞれが同じＥｎｃ（ＥＫＢ，ＫＥ
Ｋ）８０５を利用している場合の構成例を示す、このよ
うな構成においては、各データに同じＥｎｃ（ＥＫＢ，
ＫＥＫ）を付加することなく、Ｅｎｃ（ＥＫＢ，ＫＥ
Ｋ）にリンクするリンク先を示すデータを各データに付
加する構成とすることができる。
【００７２】図９にコンテンツキー暗号キーＫＥＫを、
図３に示すノードキーＫ００を更新した更新ノードキー
Ｋ（ｔ）００として構成した場合の例を示す。この場
合、図３の点線枠で囲んだグループにおいてデバイス３
が、例えば鍵の漏洩によりリボーク（排除）されている
として、他のグループのメンバ、すなわち、デバイス
０，１，２に対して図９に示す（ａ）有効化キーブロッ
ク（ＥＫＢ）と、（ｂ）コンテンツキー（Ｋｃｏｎ）を
コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）で暗
号化したデータと、（ｃ）コンテンツ（content）をコ
ンテンツキー（Ｋｃｏｎ）で暗号化したデータとを配信
することにより、デバイス０，１，２はコンテンツを得
ることができる。
【００７３】図９の右側には、デバイス０における復号
手順を示してある。デバイス０は、まず、受領した有効
化キーブロックから自身の保有するリーフキーＫ０００
を用いた復号処理により、コンテンツキー暗号キー（Ｋ
ＥＫ＝Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００
による復号によりコンテンツキーＫｃｏｎを取得し、さ
らにコンテンツキーＫｃｏｎによりコンテンツの復号を
行なう。これらの処理により、デバイス０はコンテンツ
を利用可能となる。デバイス１，２においても各々異な
る処理手順でＥＫＢを処理することにより、コンテンツ
キー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得すること
が可能となり、同様にコンテンツを利用することが可能
となる。
【００７４】図３に示す他のグループのデバイス４，
５，６…は、この同様のデータ（ＥＫＢ）を受信したと
しても、自身の保有するリーフキー、ノードキーを用い
てコンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を
取得することができない。同様にリボークされたデバイ
ス３においても、自身の保有するリーフキー、ノードキ
ーでは、コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）０
０）を取得することができず、正当な権利を有するデバ
イスのみがコンテンツを復号して利用することが可能と
なる。
【００７５】このように、ＥＫＢを利用したコンテンツ
キーの配送を用いれば、データ量を少なくして、かつ安
全に正当権利者のみが復号可能とした暗号化コンテンツ
を配信することが可能となる。
【００７６】なお、有効化キーブロック（ＥＫＢ）、コ
ンテンツキー、暗号化コンテンツ等は、ネットワークを
介して安全に配信することが可能な構成であるが、有効
化キーブロック（ＥＫＢ）、コンテンツキー、暗号化コ
ンテンツをＤＶＤ、ＣＤ等の記録媒体に格納してユーザ
に提供することも可能である。この場合、記録媒体に格
納された暗号化コンテンツの復号には、同一の記録媒体
に格納された有効化キーブロック（ＥＫＢ）の復号によ
り得られるコンテンツキーを使用するように構成すれ
ば、予め正当権利者のみが保有するリーフキー、ノード
キーによってのみ利用可能な暗号化コンテンツの配布処
理、すなわち利用可能なユーザデバイスを限定したコン
テンツ配布が簡易な構成で実現可能となる。
【００７７】図１０に記録媒体に暗号化コンテンツとと
もに有効化キーブロック（ＥＫＢ）を格納した構成例を
示す。図１０に示す例においては、記録媒体にコンテン
ツＣ１〜Ｃ４が格納され、さらに各格納コンテンツに対
応するの有効化キーブロック（ＥＫＢ）を対応付けたデ
ータが格納され、さらにバージョンＭの有効化キーブロ
ック（ＥＫＢ＿Ｍ）が格納されている。例えばＥＫＢ＿
１はコンテンツＣ１を暗号化したコンテンツキーＫｃｏ
ｎ１を生成するのに使用され、例えばＥＫＢ＿２はコン
テンツＣ２を暗号化したコンテンツキーＫｃｏｎ２を生
成するのに使用される。この例では、バージョンＭの有
効化キーブロック（ＥＫＢ＿Ｍ）が記録媒体に格納され
ており、コンテンツＣ３，Ｃ４は有効化キーブロック
（ＥＫＢ＿Ｍ）に対応付けられているので、有効化キー
ブロック（ＥＫＢ＿Ｍ）の復号によりコンテンツＣ３，
Ｃ４のコンテンツキーを取得することができる。ＥＫＢ
＿１、ＥＫＢ＿２はディスクに格納されていないので、
新たな提供手段、例えばネットワーク配信、あるいは記
録媒体による配信によってそれぞれのコンテンツキーを
復号するために必要なＥＫＢ＿１，ＥＫＢ＿２を取得す
ることが必要となる。
【００７８】図１１に、複数のデバイス間でコンテンツ
キーが流通する場合のＥＫＢを利用したコンテンツキー
の配信と、従来のコンテンツキー配信処理の比較例を示
す。上段（ａ）が従来構成であり、下段（ｂ）が本発明
の有効化キーブロック（ＥＫＢ）を利用した例である。
なお、図１１においてＫａ（Ｋｂ）は、ＫｂをＫａで暗
号化したデータであることを示す。
【００７９】（ａ）に示すように、従来は、データ送受
信者の正当性を確認し、またデータ送信の暗号化処理に
使用するセッションキーＫｓｅｓを共有するために各デ
バイス間において、認証処理および鍵交換処理（ＡＫ
Ｅ：Authentication and Key Exchange）を実行し、認
証が成立したことを条件としてセッションキーＫｓｅｓ
でコンテンツキーＫｃｏｎを暗号化して送信する処理を
行なっていた。
【００８０】例えば図１１（ａ）のＰＣにおいては、受
信したセッションキーで暗号化したコンテンツキーＫｓ
ｅｓ（Ｋｃｏｎ）をセッションキーで復号してＫｃｏｎ
を得ることが可能であり、さらに取得したＫｃｏｎをＰ
Ｃ自体の保有する保存キーＫｓｔｒで暗号化して自身の
メモリに保存することが可能となる。
【００８１】図１１（ａ）において、コンテンツプロバ
イダは、図１１（ａ）の記録デバイス１１０１にのみデ
ータを利用可能な形で配信したい場合でも、間にＰＣ、
再生装置が存在する場合は、図１１（ａ）に示すように
認証処理を実行し、それぞれのセッションキーでコンテ
ンツキーを暗号化して配信するといった処理が必要とな
る。また、間に介在するＰＣ、再生装置においても認証
処理において生成し共有することになったセッションキ
ーを用いることで暗号化コンテンツキーを復号してコン
テンツキーを取得可能となる。
【００８２】一方、図１１（ｂ）の下段に示す有効化キ
ーブロック（ＥＫＢ）を利用した例においては、コンテ
ンツプロバイダから有効化キーブロック（ＥＫＢ）と、
有効化キーブロック（ＥＫＢ）の処理によって得られる
ノードキー、またはルートキーによってコンテンツキー
Ｋｃｏｎを暗号化したデータ（図の例ではＫｒｏｏｔ
（Ｋｃｏｎ））を配信することにより、配信したＥＫＢ
の処理が可能な機器においてのみコンテンツキーＫｃｏ
ｎを復号して取得することが可能になる。
【００８３】従って、例えば図１１（ｂ）の右端にのみ
利用可能な有効化キーブロック（ＥＫＢ）を生成して、
その有効化キーブロック（ＥＫＢ）と、そのＥＫＢ処理
によって得られるノードキー、またはルートキーによっ
てコンテンツキーＫｃｏｎを暗号化したデータを併せて
送ることにより、間に存在するＰＣ、再生機器等は、自
身の有するリーフキー、ノードキーによっては、ＥＫＢ
の処理を実行することができない。従って、データ送受
信デバイス間での認証処理、セッションキーの生成、セ
ッションキーによるコンテンツキーＫｃｏｎの暗号化処
理といった処理を実行することなく、安全に正当なデバ
イスに対してのみ利用可能なコンテンツキーを配信する
ことが可能となる。
【００８４】ＰＣ、記録再生器にも利用可能なコンテン
ツキーを配信したい場合は、それぞれにおいて処理可能
な有効化キーブロック（ＥＫＢ）を生成して、配信する
ことにより、共通のコンテンツキーを取得することが可
能となる。
【００８５】［有効化キーブロック（ＥＫＢ）を使用し
た認証キーの配信（共通鍵方式）］上述の有効化キーブ
ロック（ＥＫＢ）を使用したデータあるいはキーの配信
において、デバイス間で転送される有効化キーブロック
（ＥＫＢ）およびコンテンツあるいはコンテンツキーは
常に同じ暗号化形態を維持しているため、データ伝走路
を盗み出して記録し、再度、後で転送する、いわゆるリ
プレイアタックにより、不正コピーが生成される可能性
がある。これを防ぐ構成としては、データ転送デバイス
間において、従来と同様の認証処理および鍵交換処理を
実行することが有効な手段である。ここでは、この認証
処理および鍵交換処理を実行する際に使用する認証キー
Ｋａｋｅを上述の有効化キーブロック（ＥＫＢ）を使用
してデバイスに配信することにより、安全な秘密鍵とし
て共有する認証キーを持ち、共通鍵方式に従った認証処
理を実行する構成について説明する。すなわちＥＫＢに
よる暗号化メッセージデータを認証キーとした例であ
る。
【００８６】図１２に、共通鍵暗号方式を用いた相互認
証方法（ISO/IEC 9798-2）を示す。図１２においては、
共通鍵暗号方式としてＤＥＳを用いているが、共通鍵暗
号方式であれば他の方式も可能である。図１２におい
て、まず、Ｂが６４ビットの乱数Ｒｂを生成し、Ｒｂお
よび自己のＩＤであるＩＤ（ｂ）をＡに送信する。これ
を受信したＡは、新たに６４ビットの乱数Ｒａを生成
し、Ｒａ、Ｒｂ、ＩＤ（ｂ）の順に、ＤＥＳのＣＢＣモ
ードで鍵Ｋａｂを用いてデータを暗号化し、Ｂに返送す
る。なお、鍵Ｋａｂは、ＡおよびＢに共通の秘密鍵とし
てそれぞれの記録素子内に格納する鍵である。ＤＥＳの
ＣＢＣモードを用いた鍵Ｋａｂによる暗号化処理は、例
えばＤＥＳを用いた処理においては、初期値とＲａとを
排他的論理和し、ＤＥＳ暗号化部において、鍵Ｋａｂを
用いて暗号化し、暗号文Ｅ１を生成し、続けて暗号文Ｅ
１とＲｂとを排他的論理和し、ＤＥＳ暗号化部におい
て、鍵Ｋａｂを用いて暗号化し、暗号文Ｅ２を生成し、
さらに、暗号文Ｅ２とＩＤ（ｂ）とを排他的論理和し、
ＤＥＳ暗号化部において、鍵Ｋａｂを用いて暗号化して
生成した暗号文Ｅ３とによって送信データ（Token-AB）
を生成する。
【００８７】これを受信したＢは、受信データを、やは
り共通の秘密鍵としてそれぞれの記録素子内に格納する
鍵Ｋａｂ（認証キー）で復号化する。受信データの復号
化方法は、まず、暗号文Ｅ１を認証キーＫａｂで復号化
し、乱数Ｒａを得る。次に、暗号文Ｅ２を認証キーＫａ
ｂで復号化し、その結果とＥ１を排他的論理和し、Ｒｂ
を得る。最後に、暗号文Ｅ３を認証キーＫａｂで復号化
し、その結果とＥ２を排他的論理和し、ＩＤ(ｂ)を得
る。こうして得られたＲａ、Ｒｂ、ＩＤ(ｂ)のうち、Ｒ
ｂおよびＩＤ(ｂ)が、Ｂが送信したものと一致するか検
証する。この検証に通った場合、ＢはＡを正当なものと
して認証する。
【００８８】次にＢは、認証後に使用するセッションキ
ー（Ｋｓｅｓ）を生成する（生成方法は、乱数を用い
る）。そして、Ｒｂ、Ｒａ、Ｋｓｅｓの順に、ＤＥＳの
ＣＢＣモードで認証キーＫａｂを用いて暗号化し、Ａに
返送する。
【００８９】これを受信したＡは、受信データを認証キ
ーＫａｂで復号化する。受信データの復号化方法は、Ｂ
の復号化処理と同様であるので、ここでは詳細を省略す
る。こうして得られたＲｂ、Ｒａ、Ｋｓｅｓの内、Ｒｂ
およびＲａが、Ａが送信したものと一致するか検証す
る。この検証に通った場合、ＡはＢを正当なものとして
認証する。互いに相手を認証した後には、セッションキ
ーＫｓｅｓは、認証後の秘密通信のための共通鍵として
利用される。
【００９０】なお、受信データの検証の際に、不正、不
一致が見つかった場合には、相互認証が失敗したものと
して処理を中断する。
【００９１】上述の認証処理においては、Ａ，Ｂは共通
の認証キーＫａｂを共有する。この共通鍵Ｋａｂを上述
の有効化キーブロック（ＥＫＢ）を使用してデバイスに
配信する。
【００９２】例えば、図１２の例では、Ａ，またはＢの
いずれかが他方が復号可能な有効化キーブロック（ＥＫ
Ｂ）を生成して生成した有効化キーブロック（ＥＫＢ）
によって認証キーＫａｂを暗号化して、他方に送信する
構成としてもよいし、あるいは第３者がデバイスＡ，Ｂ
に対して双方が利用可能な有効化キーブロック（ＥＫ
Ｂ）を生成してデバイスＡ，Ｂに対して生成した有効化
キーブロック（ＥＫＢ）によって認証キーＫａｂを暗号
化して配信する構成としてもよい。
【００９３】図１３および図１４に複数のデバイスに共
通の認証キーＫａｋｅを有効化キーブロック（ＥＫＢ）
によって配信する構成例を示す。図１３はデバイス０，
１，２，３に対して復号可能な認証キーＫａｋｅを配信
する例、図１４はデバイス０，１，２，３中のデバイス
３をリボーク（排除）してデバイス０，１，２に対して
のみ復号可能な認証キーを配信する例を示す。
【００９４】図１３の例では、更新ノードキーＫ（ｔ）
００によって、認証キーＫａｋｅを暗号化したデータ
（ｂ）とともに、デバイス０，１，２，３においてそれ
ぞれの有するノードキー、リーフキーを用いて更新され
たノードキーＫ（ｔ）００を復号可能な有効化キーブロ
ック（ＥＫＢ）を生成して配信する。それぞれのデバイ
スは、図１３の右側に示すようにまず、ＥＫＢを処理
（復号）することにより、更新されたノードキーＫ
（ｔ）００を取得し、次に、取得したノードキーＫ
（ｔ）００を用いて暗号化された認証キー：Ｅｎｃ（Ｋ
（ｔ）００，Ｋａｋｅ）を復号して認証キーＫａｋｅを
得ることが可能となる。
【００９５】その他のデバイス４，５，６，７…は同一
の有効化キーブロック（ＥＫＢ）を受信しても自身の保
有するノードキー、リーフキーでは、ＥＫＢを処理して
更新されたノードキーＫ（ｔ）００を取得することがで
きないので、安全に正当なデバイスに対してのみ認証キ
ーを送付することができる。
【００９６】一方、図１４の例は、図３の点線枠で囲ん
だグループにおいてデバイス３が、例えば鍵の漏洩によ
りリボーク（排除）されているとして、他のグループの
メンバ、すなわち、デバイス０，１，２，に対してのみ
復号可能な有効化キーブロック（ＥＫＢ）を生成して配
信した例である。図１４に示す（ａ）有効化キーブロッ
ク（ＥＫＢ）と、（ｂ）認証キー（Ｋａｋｅ）をノード
キー（Ｋ（ｔ）００）で暗号化したデータを配信する。
【００９７】図１４の右側には、復号手順を示してあ
る。デバイス０，１，２は、まず、受領した有効化キー
ブロックから自身の保有するリーフキーまたはノードキ
ーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）
００）を取得する。次に、Ｋ（ｔ）００による復号によ
り認証キーＫａｋｅを取得する。
【００９８】図３に示す他のグループのデバイス４，
５，６…は、この同様のデータ（ＥＫＢ）を受信したと
しても、自身の保有するリーフキー、ノードキーを用い
て更新ノードキー（Ｋ（ｔ）００）を取得することがで
きない。同様にリボークされたデバイス３においても、
自身の保有するリーフキー、ノードキーでは、更新ノー
ドキー（Ｋ（ｔ）００）を取得することができず、正当
な権利を有するデバイスのみが認証キーを復号して利用
することが可能となる。
【００９９】このように、ＥＫＢを利用した認証キーの
配送を用いれば、データ量を少なくして、かつ安全に正
当権利者のみが復号可能とした認証キーを配信すること
が可能となる。
【０１００】［公開鍵認証と有効化キーブロック（ＥＫ
Ｂ）を使用したコンテンツキーの配信］次に、公開鍵認
証と有効化キーブロック（ＥＫＢ）を使用したコンテン
ツキーの配信処理について説明する。まず、公開鍵暗号
方式である１６０ビット長の楕円曲線暗号を用いた相互
認証方法を、図１５を用いて説明する。図１５におい
て、公開鍵暗号方式としてＥＣＣを用いているが、同様
な公開鍵暗号方式であればいずれでもよい。また、鍵サ
イズも１６０ビットでなくてもよい。図１５において、
まずＢが、６４ビットの乱数Ｒｂを生成し、Ａに送信す
る。これを受信したＡは、新たに６４ビットの乱数Ｒａ
および素数ｐより小さい乱数Ａｋを生成する。そして、
ベースポイントＧをＡｋ倍した点Ａｖ＝Ａｋ×Ｇを求
め、Ｒａ、Ｒｂ、Ａｖ（X座標とY座標）に対する電子署
名Ａ．Ｓｉｇを生成し、Ａの公開鍵証明書とともにＢに
返送する。ここで、ＲａおよびＲｂはそれぞれ６４ビッ
ト、ＡｖのＸ座標とＹ座標がそれぞれ１６０ビットであ
るので、合計４４８ビットに対する電子署名を生成す
る。
【０１０１】Ａの公開鍵証明書、Ｒａ、Ｒｂ、Ａｖ、電
子署名Ａ．Ｓｉｇを受信したＢは、Ａが送信してきたＲ
ｂが、Ｂが生成したものと一致するか検証する。その結
果、一致していた場合には、Ａの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ａの公開鍵を取り出
す。そして、取り出したＡの公開鍵を用い電子署名Ａ．
Ｓｉｇを検証する。
【０１０２】次に、Ｂは、素数ｐより小さい乱数Ｂｋを
生成する。そして、ベースポイントＧをＢｋ倍した点Ｂ
ｖ＝Ｂｋ×Ｇを求め、Ｒｂ、Ｒａ、Ｂｖ（Ｘ座標とＹ座
標）に対する電子署名Ｂ．Ｓｉｇを生成し、Ｂの公開鍵
証明書とともにＡに返送する。
【０１０３】Ｂの公開鍵証明書、Ｒｂ、Ｒａ、Ａｖ、電
子署名Ｂ．Ｓｉｇを受信したＡは、Ｂが送信してきたＲ
ａが、Ａが生成したものと一致するか検証する。その結
果、一致していた場合には、Ｂの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ｂの公開鍵を取り出
す。そして、取り出したＢの公開鍵を用い電子署名Ｂ．
Ｓｉｇを検証する。電子署名の検証に成功した後、Ａは
Ｂを正当なものとして認証する。
【０１０４】両者が認証に成功した場合には、ＢはＢｋ
×Ａｖ（Ｂｋは乱数だが、Ａｖは楕円曲線上の点である
ため、楕円曲線上の点のスカラー倍計算が必要）を計算
し、ＡはＡｋ×Ｂｖを計算し、これら点のＸ座標の下位
６４ビットをセッションキーとして以降の通信に使用す
る（共通鍵暗号を６４ビット鍵長の共通鍵暗号とした場
合）。もちろん、Ｙ座標からセッション鍵を生成しても
よいし、下位６４ビットでなくてもよい。なお、相互認
証後の秘密通信においては、送信データはセッションキ
ーで暗号化されるだけでなく、電子署名も付されること
がある。
【０１０５】電子署名の検証や受信データの検証の際
に、不正、不一致が見つかった場合には、相互認証が失
敗したものとして処理を中断する。
【０１０６】図１６に公開鍵認証と有効化キーブロック
（ＥＫＢ）を使用したコンテンツキーの配信処理例を示
す。まずコンテンツプロバイダとＰＣ間において図１５
で説明した公開鍵方式による認証処理が実行される。コ
ンテンツプロバイダは、コンテンツキー配信先である再
生装置、記録媒体の有するノードキー、リーフキーによ
って復号可能なＥＫＢを生成して、更新ノードキーによ
る暗号化を実行したコンテンツキーＥ（Ｋｃｏｎ）と、
有効化キーブロック（ＥＫＢ）とをＰＣ間の認証処理に
おいて生成したセッションキーＫｓｅｓで暗号化してＰ
Ｃに送信する。
【０１０７】ＰＣはセッションキーで暗号化された［更
新ノードキーによる暗号化を実行したコンテンツキーＥ
（Ｋｃｏｎ）と、有効化キーブロック（ＥＫＢ）］をセ
ッションキーで復号した後、再生装置、記録媒体に送信
する。
【０１０８】再生装置、記録媒体は、自身の保有するノ
ードキーまたはリーフキーによって［更新ノードキーに
よる暗号化を実行したコンテンツキーＥ（Ｋｃｏｎ）
と、有効化キーブロック（ＥＫＢ）］を復号することに
よってコンテンツキーＫｃｏｎを取得する。
【０１０９】この構成によれば、コンテンツプロバイダ
とＰＣ間での認証を条件として［更新ノードキーによる
暗号化を実行したコンテンツキーＥ（Ｋｃｏｎ）と、有
効化キーブロック（ＥＫＢ）］が送信されるので、例え
ば、ノードキーの漏洩があった場合でも、確実な相手に
対するデータ送信が可能となる。
【０１１０】［プログラムコードの有効化キーブロック
（ＥＫＢ）を使用した配信］上述した例では、コンテン
ツキー、認証キー等を有効化キーブロック（ＥＫＢ）を
用いて暗号化して配信する方法を説明したが、様々なプ
ログラムコードを有効化キーブロック（ＥＫＢ）を用い
て配信する構成も可能である。すなわちＥＫＢによる暗
号化メッセージデータをプログラムコードとした例であ
る。以下、この構成について説明する。
【０１１１】図１７にプログラムコードを有効化キーブ
ロック（ＥＫＢ）の例えば更新ノードキーによって暗号
化してデバイス間で送信する例を示す。デバイス１７０
１は、デバイス１７０２の有するノードキー、リーフキ
ーによって復号可能な有効化キーブロック（ＥＫＢ）
と、有効化キーブロック（ＥＫＢ）に含まれる更新ノー
ドキーで暗号処理したプログラムコードをデバイス１７
０２に送信する。デバイス１７０２は受信したＥＫＢを
処理して更新ノードキーを取得して、さらに取得した更
新ノードキーによってプログラムコードの復号を実行し
て、プログラムコードを得る。
【０１１２】図１７に示す例では、さらに、デバイス１
７０２において取得したプログラムコードによる処理を
実行して、その結果をデバイス１７０１に返して、デバ
イス１７０１がその結果に基づいて、さらに処理を続行
する例を示している。
【０１１３】このように有効化キーブロック（ＥＫＢ）
と、有効化キーブロック（ＥＫＢ）に含まれる更新ノー
ドキーで暗号処理したプログラムコードを配信すること
により、特定のデバイスにおいて解読可能なプログラム
コードを前述の図３で示した特定のデバイス、あるいは
グループに対して配信することが可能となる。
【０１１４】［送信コンテンツに対するチェック値（Ｉ
ＣＶ:Integrity Check Value）を対応させる構成］次
に、コンテンツの改竄を防止するためにコンテンツのイ
ンテグリティ・チェック値（ＩＣＶ）を生成して、コン
テンツに対応付けて、ＩＣＶの計算により、コンテンツ
改竄の有無を判定する処理構成について説明する。
【０１１５】コンテンツのインテグリティ・チェック値
（ＩＣＶ）は、例えばコンテンツに対するハッシュ関数
を用いて計算され、ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｃ
１，Ｃ２，…）によって計算される。ＫｉｃｖはＩＣＶ
生成キーである。Ｃ１，Ｃ２はコンテンツの情報であ
り、コンテンツの重要情報のメッセージ認証符号（ＭＡ
Ｃ：Message authentication Code）が使用される。
【０１１６】ＤＥＳ暗号処理構成を用いたＭＡＣ値生成
例を図１８に示す。図１８の構成に示すように対象とな
るメッセージを８バイト単位に分割し、（以下、分割さ
れたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、
まず、初期値（Initial Value（以下、ＩＶとする））
とＭ１を排他的論理和する（その結果をＩ１とする）。
次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１と
する）を用いて暗号化する（出力をＥ１とする）。続け
て、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２を
ＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出
力Ｅ２）。以下、これを繰り返し、全てのメッセージに
対して暗号化処理を施す。最後に出てきたＥＮがメッセ
ージ認証符号（ＭＡＣ（Message Authentication Cod
e））となる。
【０１１７】このようなコンテンツのＭＡＣ値とＩＣＶ
生成キーにハッシュ関数を適用して用いてコンテンツの
インテグリティ・チェック値（ＩＣＶ）が生成される。
改竄のないことが保証された例えばコンテンツ生成時に
生成したＩＣＶと、新たにコンテンツに基づいて生成し
たＩＣＶとを比較して同一のＩＣＶが得られればコンテ
ンツに改竄のないことが保証され、ＩＣＶが異なれば、
改竄があったと判定される。
【０１１８】［チェック値（ＩＣＶ）の生成キーＫｉｃ
ｖをＥＫＢによって配布する構成］次に、コンテンツの
インテグリティ・チェック値（ＩＣＶ）生成キーである
Ｋｉｃｖを上述の有効化キーブロックによって送付する
構成について説明する。すなわちＥＫＢによる暗号化メ
ッセージデータをコンテンツのインテグリティ・チェッ
ク値（ＩＣＶ）生成キーとした例である。
【０１１９】図１９および図２０に複数のデバイスに共
通のコンテンツを送付した場合、それらのコンテンツの
改竄の有無を検証するためのインテグリティ・チェック
値生成キーＫｉｃｖを有効化キーブロック（ＥＫＢ）に
よって配信する構成例を示す。図１９はデバイス０，
１，２，３に対して復号可能なチェック値生成キーＫｉ
ｃｖを配信する例、図２０はデバイス０，１，２，３中
のデバイス３をリボーク（排除）してデバイス０，１，
２に対してのみ復号可能なチェック値生成キーＫｉｃｖ
を配信する例を示す。
【０１２０】図１９の例では、更新ノードキーＫ（ｔ）
００によって、チェック値生成キーＫｉｃｖを暗号化し
たデータ（ｂ）とともに、デバイス０，１，２，３にお
いてそれぞれの有するノードキー、リーフキーを用いて
更新されたノードキーＫ（ｔ）００を復号可能な有効化
キーブロック（ＥＫＢ）を生成して配信する。それぞれ
のデバイスは、図１９の右側に示すようにまず、ＥＫＢ
を処理（復号）することにより、更新されたノードキー
Ｋ（ｔ）００を取得し、次に、取得したノードキーＫ
（ｔ）００を用いて暗号化されたチェック値生成キー：
Ｅｎｃ（Ｋ（ｔ）００，Ｋｉｃｖ）を復号してチェック
値生成キーＫｉｃｖを得ることが可能となる。
【０１２１】その他のデバイス４，５，６，７…は同一
の有効化キーブロック（ＥＫＢ）を受信しても自身の保
有するノードキー、リーフキーでは、ＥＫＢを処理して
更新されたノードキーＫ（ｔ）００を取得することがで
きないので、安全に正当なデバイスに対してのみチェッ
ク値生成キーを送付することができる。
【０１２２】一方、図２０の例は、図３の点線枠で囲ん
だグループにおいてデバイス３が、例えば鍵の漏洩によ
りリボーク（排除）されているとして、他のグループの
メンバ、すなわち、デバイス０，１，２，に対してのみ
復号可能な有効化キーブロック（ＥＫＢ）を生成して配
信した例である。図２０に示す（ａ）有効化キーブロッ
ク（ＥＫＢ）と、（ｂ）チェック値生成キー（Ｋｉｃ
ｖ）をノードキー（Ｋ（ｔ）００）で暗号化したデータ
を配信する。
【０１２３】図２０の右側には、復号手順を示してあ
る。デバイス０，１，２は、まず、受領した有効化キー
ブロックから自身の保有するリーフキーまたはノードキ
ーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）
００）を取得する。次に、Ｋ（ｔ）００による復号によ
りチェック値生成キーＫｉｃｖを取得する。
【０１２４】図３に示す他のグループのデバイス４，
５，６…は、この同様のデータ（ＥＫＢ）を受信したと
しても、自身の保有するリーフキー、ノードキーを用い
て更新ノードキー（Ｋ（ｔ）００）を取得することがで
きない。同様にリボークされたデバイス３においても、
自身の保有するリーフキー、ノードキーでは、更新ノー
ドキー（Ｋ（ｔ）００）を取得することができず、正当
な権利を有するデバイスのみがチェック値生成キーを復
号して利用することが可能となる。
【０１２５】このように、ＥＫＢを利用したチェック値
生成キーの配送を用いれば、データ量を少なくして、か
つ安全に正当権利者のみが復号可能としたチェック値生
成キーを配信することが可能となる。
【０１２６】このようなコンテンツのインテグリティ・
チェック値（ＩＣＶ）を用いることにより、ＥＫＢと暗
号化コンテンツの不正コピーを排除することができる。
例えば図２１に示すように、コンテンツＣ１とコンテン
ツＣ２とをそれぞれのコンテンツキーを取得可能な有効
化キーブロック（ＥＫＢ）とともに格納したメディア１
があり、これをそのままメディア２にコピーした場合を
想定する。ＥＫＢと暗号化コンテンツのコピーは可能で
あり、これをＥＫＢを復号可能なデバイスでは利用でき
ることになる。
【０１２７】図２１の（ｂ）に示すように各メディアに
正当に格納されたコンテンツに対応付けてインテグリテ
ィ・チェック値（ＩＣＶ（Ｃ１，Ｃ２））を格納する構
成とする。なお、（ＩＣＶ（Ｃ１，Ｃ２））は、コンテ
ンツＣ１とコンテンツＣ２にハッシュ関数を用いて計算
されるコンテンツのインテグリティ・チェック値である
ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｃ１，Ｃ２）を示してい
る。図２１の（ｂ）の構成において、メディア１には正
当にコンテンツ１とコンテンツ２が格納され、コンテン
ツＣ１とコンテンツＣ２に基づいて生成されたインテグ
リティ・チェック値（ＩＣＶ（Ｃ１，Ｃ２））が格納さ
れる。また、メディア２には正当にコンテンツ１が格納
され、コンテンツＣ１に基づいて生成されたインテグリ
ティ・チェック値（ＩＣＶ（Ｃ１））が格納される。こ
の構成において、メディア１に格納された｛ＥＫＢ，コ
ンテンツ２｝をメディア２にコピーしたとすると、メデ
ィア２で、コンテンツチェック値を新たに生成するとＩ
ＣＶ（Ｃ１，Ｃ２）が生成されることになり、メディア
に格納されているＫｉｃｖ（Ｃ１）と異なり、コンテン
ツの改竄あるいは不正なコピーによる新たなコンテンツ
の格納が実行されたことが明らかになる。メディアを再
生するデバイスにおいて、再生ステップの前ステップに
ＩＣＶチェックを実行して、生成ＩＣＶと格納ＩＣＶの
一致を判別し、一致しない場合は、再生を実行しない構
成とすることにより、不正コピーのコンテンツの再生を
防止することが可能となる。
【０１２８】また、さらに、安全性を高めるため、コン
テンツのインテグリティ・チェック値（ＩＣＶ）を書き
換えカウンタを含めたデータに基づいて生成する構成と
してもよい。すなわちＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，ｃ
ｏｕｎｔｅｒ＋１，Ｃ１，Ｃ２，…）によって計算する
構成とする。ここで、カウンタ（ｃｏｕｎｔｅｒ＋１）
は、ＩＣＶの書き換えごとに１つインクリメントされる
値として設定する。なお、カウンタ値はセキュアなメモ
リに格納する構成とすることが必要である。
【０１２９】さらに、コンテンツのインテグリティ・チ
ェック値（ＩＣＶ）をコンテンツと同一メディアに格納
することができない構成においては、コンテンツのイン
テグリティ・チェック値（ＩＣＶ）をコンテンツとは別
のメディア上に格納する構成としてもよい。
【０１３０】例えば、読み込み専用メディアや通常のＭ
Ｏ等のコピー防止策のとられていないメディアにコンテ
ンツを格納する場合、同一メディアにインテグリティ・
チェック値（ＩＣＶ）を格納するとＩＣＶの書き換えが
不正なユーザによりなされる可能性があり、ＩＣＶの安
全性が保てないおそれがある。この様な場合、ホストマ
シン上の安全なメディアにＩＣＶを格納して、コンテン
ツのコピーコントロール（例えばcheck-in/check-out、
move）にＩＣＶを使用する構成とすることにより、ＩＣ
Ｖの安全な管理およびコンテンツの改竄チェックが可能
となる。
【０１３１】この構成例を図２２に示す。図２２では読
み込み専用メディアや通常のＭＯ等のコピー防止策のと
られていないメディア２２０１にコンテンツが格納さ
れ、これらのコンテンツに関するインテグリティ・チェ
ック値（ＩＣＶ）を、ユーザが自由にアクセスすること
の許可されないホストマシン上の安全なメディア２２０
２に格納し、ユーザによる不正なインテグリティ・チェ
ック値（ＩＣＶ）の書き換えを防止した例である。この
ような構成として、例えばメディア２２０１を装着した
デバイスがメディア２２０１の再生を実行する際にホス
トマシンであるＰＣ、サーバにおいてＩＣＶのチェック
を実行して再生の可否を判定する構成とすれば、不正な
コピーコンテンツあるいは改竄コンテンツの再生を防止
できる。
【０１３２】［階層ツリー構造のカテゴリ分類］暗号鍵
をルートキー、ノードキー、リーフキー等、図３の階層
ツリー構造として構成し、コンテンツキー、認証キー、
ＩＣＶ生成キー、あるいはプログラムコード、データ等
を有効化キーブロック（ＥＫＢ）とともに暗号化して配
信する構成について説明してきたが、ノードキー等を定
義している階層ツリー構造を各デバイスのカテゴリ毎に
分類して効率的なキー更新処理、暗号化キー配信、デー
タ配信を実行する構成について、以下説明する。
【０１３３】図２３に階層ツリー構造のカテゴリの分類
の一例を示す。図２３において、階層ツリー構造の最上
段には、ルートキーＫｒｏｏｔ２３０１が設定され、以
下の中間段にはノードキー２３０２が設定され、最下段
には、リーフキー２３０３が設定される。各デバイスは
個々のリーフキーと、リーフキーからルートキーに至る
一連のノードキー、ルートキーを保有する。
【０１３４】ここで、一例として最上段から第Ｍ段目の
あるノードをカテゴリノード２３０４として設定する。
すなわち第Ｍ段目のノードの各々を特定カテゴリのデバ
イス設定ノードとする。第Ｍ段の１つのノードを頂点と
して以下、Ｍ＋１段以下のノード、リーフは、そのカテ
ゴリに含まれるデバイスに関するノードおよびリーフと
する。
【０１３５】例えば図２３の第Ｍ段目の１つのノード２
３０５にはカテゴリ［メモリステッイク（商標）］が設
定され、このノード以下に連なるノード、リーフはメモ
リステッイクを使用した様々なデバイスを含むカテゴリ
専用のノードまたはリーフとして設定される。すなわ
ち、ノード２３０５以下を、メモリスティックのカテゴ
リに定義されるデバイスの関連ノード、およびリーフの
集合として定義する。
【０１３６】さらに、Ｍ段から数段分下位の段をサブカ
テゴリノード２３０６として設定することができる。例
えば図に示すようにカテゴリ［メモリスティック］ノー
ド２３０５の２段下のノードに、メモリスティックを使
用したデバイスのカテゴリに含まれるサブカテゴリノー
ドとして、［再生専用器］のノードを設定する。さら
に、サブカテゴリノードである再生専用器のノード２３
０６以下に、再生専用器のカテゴリに含まれる音楽再生
機能付き電話のノード２３０７が設定され、さらにその
下位に、音楽再生機能付き電話のカテゴリに含まれる
［ＰＨＳ］ノード２３０８と［携帯電話］ノード２３０
９を設定することができる。
【０１３７】さらに、カテゴリ、サブカテゴリは、デバ
イスの種類のみならず、例えばあるメーカー、コンテン
ツプロバイダ、決済機関等が独自に管理するノード、す
なわち処理単位、管轄単位、あるいは提供サービス単位
等、任意の単位（これらを総称して以下、エンティティ
と呼ぶ）で設定することが可能である。例えば１つのカ
テゴリノードをゲーム機器メーカーの販売するゲーム機
器ＸＹＺ専用の頂点ノードとして設定すれば、メーカー
の販売するゲーム機器ＸＹＺにその頂点ノード以下の下
段のノードキー、リーフキーを格納して販売することが
可能となり、その後、暗号化コンテンツの配信、あるい
は各種キーの配信、更新処理を、その頂点ノードキー以
下のノードキー、リーフキーによって構成される有効化
キーブロック（ＥＫＢ）を生成して配信し、頂点ノード
以下のデバイスに対してのみ利用可能なデータが配信可
能となる。
【０１３８】このように、１つのノードを頂点としし
て、以下のノードをその頂点ノードに定義されたカテゴ
リ、あるいはサブカテゴリの関連ノードとして設定する
構成とすることにより、カテゴリ段、あるいはサブカテ
ゴリ段の１つの頂点ノードを管理するメーカー、コンテ
ンツプロバイダ等がそのノードを頂点とする有効化キー
ブロック（ＥＫＢ）を独自に生成して、頂点ノード以下
に属するデバイスに配信する構成が可能となり、頂点ノ
ードに属さない他のカテゴリのノードに属するデバイス
には全く影響を及ぼさずにキー更新を実行することがで
きる。
【０１３９】［簡略ＥＫＢによるキー配信構成（１）］
先に説明した例えば図３のツリー構成において、キー、
例えばコンテンツキーを所定デバイス（リーフ）宛に送
付する場合、キー配布先デバイスの所有しているリーフ
キー、ノードキーを用いて復号可能な有効化キーブロッ
ク（ＥＫＢ）を生成して提供する。例えば図２４（ａ）
に示すツリー構成において、リーフを構成するデバイス
ａ，ｇ，ｊに対してキー、例えばコンテンツキーを送信
する場合、ａ，ｇ，ｊの各ノードにおいて復号可能な有
効化キーブロック（ＥＫＢ）を生成して配信する。
【０１４０】例えば更新ルートキーＫ（ｔ）ｒｏｏｔで
コンテンツキーＫ（ｔ）ｃｏｎを暗号化処理し、ＥＫＢ
とともに配信する場合を考える。この場合、デバイス
ａ，ｇ，ｊは、それぞれが図２４（ｂ）に示すリーフお
よびノードキーを用いて、ＥＫＢの処理を実行してＫ
（ｔ）ｒｏｏｔを取得し、取得した更新ルートキーＫ
（ｔ）ｒｏｏｔによってコンテンツキーＫ（ｔ）ｃｏｎ
の復号処理を実行してコンテンツキーを得る。
【０１４１】この場合に提供される有効化キーブロック
（ＥＫＢ）の構成は、図２５に示すようになる。図２５
に示す有効化キーブロック（ＥＫＢ）は、先の図６で説
明した有効化キーブロック（ＥＫＢ）のフォーマットに
したがって構成されたものであり、データ（暗号化キ
ー）と対応するタグとを持つ。タグは、先に図７を用い
て説明したように左（Ｌ）、右（Ｒ）、それぞれの方向
にデータがあれば０、無ければ１を示している。
【０１４２】有効化キーブロック（ＥＫＢ）を受領した
デバイスは、有効化キーブロック（ＥＫＢ）の暗号化キ
ーとタグに基づいて、順次暗号化キーの復号処理を実行
して上位ノードの更新キーを取得していく。図２５に示
すように、有効化キーブロック（ＥＫＢ）は、ルートか
らリーフまでの段数（デプス）が多いほど、そのデータ
量は増加していく。段数（デプス）は、デバイス（リー
フ）数に応じて増大するものであり、キーの配信先とな
るデバイス数が多い場合は、ＥＫＢのデータ量がさらに
増大することになる。
【０１４３】このような有効化キーブロック（ＥＫＢ）
のデータ量の削減を可能とした構成について説明する。
図２６は、有効化キーブロック（ＥＫＢ）をキー配信デ
バイスに応じて簡略化して構成した例を示すものであ
る。
【０１４４】図２５と同様、リーフを構成するデバイス
ａ，ｇ，ｊに対してキー、例えばコンテンツキーを送信
する場合を想定する。図２６の（ａ）に示すように、キ
ー配信デバイスによってのみ構成されるツリーを構築す
る。この場合、図２４（ｂ）に示す構成に基づいて新た
なツリー構成として図２６（ｂ）のツリー構成が構築さ
れる。ＫｒｏｏｔからＫｊまでは全く分岐がなく１つの
枝のみが存在すればよく、ＫｒｏｏｔからＫａおよびＫ
ｇに至るためには、Ｋ０に分岐点を構成するのみで、２
分岐構成の図２６（ａ）のツリーが構築される。
【０１４５】図２６（ａ）に示すように、ノードとして
Ｋ０のみを持つ簡略化したツリーが生成される。更新キ
ー配信のための有効化キーブロック（ＥＫＢ）は、これ
らの簡略ツリーに基づいて生成する。図２６（ａ）に示
すツリーは、有効化キーブロック（ＥＫＢ）を復号可能
な末端ノードまたはリーフを最下段とした２分岐型ツリ
ーを構成するパスを選択して不要ノードを省略すること
により再構築される再構築階層ツリーである。更新キー
配信のための有効化キーブロック（ＥＫＢ）は、この再
構築階層ツリーのノードまたはリーフに対応するキーの
みに基づいて構成される。
【０１４６】先の図２５で説明した有効化キーブロック
（ＥＫＢ）は、各リーフａ，ｇ，ｊからＫｒｏｏｔに至
るまでのすべてのキーを暗号化したデータを格納してい
たが、簡略化ＥＫＢは、簡略化したツリーを構成するノ
ードについてのみの暗号化データを格納する。図２６
（ｂ）に示すようにタグは３ビット構成を有する。第２
および第３ビットは、図２５の例と、同様の意味を持
ち、左（Ｌ）、右（Ｒ）、それぞれの方向にデータがあ
れば０、無ければ１を示す。第１番目のビットは、ＥＫ
Ｂ内に暗号化キーが格納されているか否かを示すための
ビットであり、データが格納されている場合は１、デー
タが無い場合は、０として設定される。
【０１４７】データ通信網、あるいは記憶媒体に格納さ
れてデバイス（リーフ）に提供される有効化キーブロッ
ク（ＥＫＢ）は、図２６（ｂ）に示すように、図２５に
示す構成に比較すると、データ量が大幅に削減されたも
のとなる。図２６に示す有効化キーブロック（ＥＫＢ）
を受領した各デバイスは、タグの第１ビットに１が格納
された部分のデータのみを順次復号することにより、所
定の暗号化キーの復号を実現することができる。例えば
デバイスａは、暗号化データＥｎｃ（Ｋａ，Ｋ（ｔ）
０）をリーフキーＫａで復号して、ノードキーＫ（ｔ）
０を取得して、ノードキーＫ（ｔ）０によって暗号化デ
ータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）を復号し
てＫ（ｔ）ｒｏｏｔを取得する。デバイスｊは、暗号化
データＥｎｃ（Ｋｊ，Ｋ（ｔ）ｒｏｏｔ）をリーフキー
Ｋｊで復号して、Ｋ（ｔ）ｒｏｏｔを取得する。
【０１４８】このように、配信先のデバイスによっての
み構成される簡略化した新たなツリー構成を構築して、
構築されたツリーを構成するリーフおよびノードのキー
のみを用いて有効化キーブロック（ＥＫＢ）を生成する
ことにより、少ないデータ量の有効化キーブロック（Ｅ
ＫＢ）を生成することが可能となり、有効化キーブロッ
ク（ＥＫＢ）のデータ配信が効率的に実行可能となる。
【０１４９】［簡略ＥＫＢによるキー配信構成（２）］
図２６で示した簡略化したツリーに基づいて生成される
有効化キーブロック（ＥＫＢ）をさらに、簡略化してデ
ータ量を削減し、効率的な処理を可能とした構成につい
て説明する。
【０１５０】図２６を用いて説明した構成は、有効化キ
ーブロック（ＥＫＢ）を復号可能な末端ノードまたはリ
ーフを最下段とした２分岐型ツリーを構成するパスを選
択して不要ノードを省略することにより再構築される再
構築階層ツリーであった。更新キー配信のための有効化
キーブロック（ＥＫＢ）は、この再構築階層ツリーのノ
ードまたはリーフに対応するキーのみに基づいて構成さ
れる。
【０１５１】図２６（ａ）に示す再構築階層ツリーは、
リーフａ，ｇ，ｊにおいて更新ルートキーＫ（ｔ）ｒｏ
ｏｔを取得可能とするため、図２６（ｂ）に示す有効化
キーブロック（ＥＫＢ）を配信する。図２６（ｂ）の有
効化キーブロック（ＥＫＢ）の処理において、リーフｊ
は、Ｅｎｃ（Ｋｊ，Ｋ（ｔ）ｒｏｏｔ）の１回の復号処
理によりルートキー：Ｋ（ｔ）ｒｏｏｔを取得できる。
しかし、リーフａ，ｇは、Ｅｎｃ（Ｋａ，Ｋ（ｔ）０）
または、Ｅｎｃ（Ｋｇ，Ｋ（ｔ）０）の復号処理により
Ｋ（ｔ）０を得た後、さらに、Ｅｎｃ（Ｋ（ｔ）０，Ｋ
（ｔ）ｒｏｏｔ）の復号処理を実行してルートキー：Ｋ
（ｔ）ｒｏｏｔを取得する。すなわち、リーフａ，ｇ
は、２回の復号処理を実行することが必要となる。
【０１５２】図２６の簡略化した再構築階層ツリーは、
ノードＫ０がその下位リーフａ，ｇの管理ノードとして
独自の管理を実行している場合、例えば後述するサブル
ート・ノードとして、下位リーフの管理を実行している
場合には、リーフａ，ｇが更新キーを取得したことを確
認する意味で有効であるが、ノードＫ０が下位リーフの
管理を行なっていない場合、あるいは行なっていたとし
ても、上位ノードからの更新キー配信を許容している場
合には、図２６（ａ）に示す再構築階層ツリーをさらに
簡略化して、ノードＫ０のキーを省略して有効化キーブ
ロック（ＥＫＢ）を生成して配信してもよい。
【０１５３】図２７に、このような有効化キーブロック
（ＥＫＢ）の構成を示す。図２６と同様、リーフを構成
するデバイスａ，ｇ，ｊに対してキー、例えばコンテン
ツキーを送信する場合を想定する。図２７の（ａ）に示
すように、ルートＫｒｏｏｔと各リーフａ，ｇ，ｊを直
接接続したツリーを構築する。
【０１５４】図２７（ａ）に示すように、図２６（ａ）
に示す再構築階層ツリーからノードＫ０が省かれた簡略
化したツリーが生成される。更新キー配信のための有効
化キーブロック（ＥＫＢ）は、これらの簡略ツリーに基
づいて生成する。図２７（ａ）に示すツリーは、有効化
キーブロック（ＥＫＢ）を復号可能なリーフをとルート
とを直接結ぶパスのみによって再構築される再構築階層
ツリーである。更新キー配信のための有効化キーブロッ
ク（ＥＫＢ）は、この再構築階層ツリーのリーフに対応
するキーのみに基づいて構成される。
【０１５５】なお、図２７（ａ）の例は、末端をリーフ
とした構成例であるが、例えば最上位ノードか複数の中
位、下位ノードに対してキーを配信する場合も、最上位
ノードと中位、下位ノードとを直接接続した簡略化ツリ
ーに基づいて有効化キーブロック（ＥＫＢ）を生成して
キー配信を実行することが可能である。このように、再
構築階層ツリーは、簡略化したツリーを構成する頂点ノ
ードと、簡略化したツリーを構成する末端ノードまたは
リーフとを直接、接続した構成を持つ。この簡略化ツリ
ーでは、頂点ノードからの分岐は２に限らず、配信ノー
ドまたはリーフ数に応じて３以上の多分岐を持つツリー
として構成することが可能である。
【０１５６】先の図２５で説明した有効化キーブロック
（ＥＫＢ）は、各リーフａ，ｇ，ｊからＫｒｏｏｔに至
るまでのすべてのキーを暗号化したデータを格納し、図
２６で説明した有効化キーブロック（ＥＫＢ）は、リー
フａ，ｇ，ｊのリーフキー、ａ，ｇの共通ノードとして
のＫ０、さらに、ルートキーを格納した構成であった
が、図２７（ａ）に示す簡略化階層ツリーに基づく有効
化キーブロック（ＥＫＢ）は、ノードＫ０のキーを省略
したので、図２７（ｂ）に示すように、さらにデータ量
の少ない有効化キーブロック（ＥＫＢ）となる。
【０１５７】図２７（ｂ）の有効化キーブロック（ＥＫ
Ｂ）は、図２６（ｂ）の有効化キーブロック（ＥＫＢ）
と同様、３ビット構成のタグを有する。第２および第３
ビットは、図２６で説明したと同様、左（Ｌ）、右
（Ｒ）、それぞれの方向にデータがあれば０、無ければ
１を示す。第１番目のビットは、ＥＫＢ内に暗号化キー
が格納されているか否かを示すためのビットであり、デ
ータが格納されている場合は１、データが無い場合は、
０として設定される。
【０１５８】図２７（ｂ）の有効化キーブロック（ＥＫ
Ｂ）において、各リーフａ，ｇ，ｊは、Ｅｎｃ（Ｋａ，
Ｋ（ｔ）ｒｏｏｔ）、またはＥｎｃ（Ｋｇ，Ｋ（ｔ）ｒ
ｏｏｔ）Ｅｎｃ（Ｋｊ，Ｋ（ｔ）ｒｏｏｔ）の１回の復
号処理によりルートキー：Ｋ（ｔ）ｒｏｏｔを取得でき
る。
【０１５９】このように簡略化された再構築ツリーの最
上位ノードと、ツリーを構成する末端ノードまたはリー
フとを直接、接続した構成を持つツリーに基づいて生成
される有効化キーブロック（ＥＫＢ）は、図２７（ｂ）
に示すように、再構築階層ツリーの頂点ノードおよび末
端ノードまたはリーフに対応するキーのみに基づいて構
成される。
【０１６０】図２６または図２７で説明した有効化キー
ブロック（ＥＫＢ）のように、配信先のデバイスによっ
てのみ構成される簡略化した新たなツリー構成を構築し
て、構築されたツリーを構成するリーフのみ、あるいは
リーフと共通ノードのキーのみを用いて有効化キーブロ
ック（ＥＫＢ）を生成することにより、少ないデータ量
の有効化キーブロック（ＥＫＢ）を生成することが可能
となり、有効化キーブロック（ＥＫＢ）のデータ配信が
効率的に実行可能となる。
【０１６１】なお、簡略化した階層ツリー構成は、後段
で説明するサブツリーとして設定されるカテゴリツリー
単位のＥＫＢ管理構成において特に有効に活用可能であ
る。カテゴリツリーは、キー配信構成としてのツリー構
成を構成するノードあるいはリーフから選択した複数の
ノードあるいはリーフの集合体ブロックである。カテゴ
リツリーは、デバイスの種類に応じて設定される集合で
あったり、あるいはデバイス提供メーカー、コンテンツ
プロバイダ、決済機関等の管理単位等、ある共通点を持
った処理単位、管轄単位、あるいは提供サービス単位
等、様々な態様の集合として設定される。１つのカテゴ
リツリーには、ある共通のカテゴリに分類されるデバイ
スが集まっており、例えば複数のカテゴリツリーの頂点
ノード（サブルート）によって上述したと同様の簡略化
したツリーを再構築してＥＫＢを生成することにより、
選択されたカテゴリツリーに属するデバイスにおいて復
号可能な簡略化された有効化キーブロック（ＥＫＢ）の
生成、配信が可能となる。カテゴリツリー単位の管理構
成については後段で詳細に説明する。
【０１６２】なお、このような有効化キーブロック（Ｅ
ＫＢ）は、光ディスク、ＤＶＤ等の情報記録媒体に格納
した構成とすることが可能である。例えば、上述の暗号
化キーデータによって構成されるデータ部と、暗号化キ
ーデータの階層ツリー構造における位置識別データとし
てのタグ部とを含む有効化キーブロック（ＥＫＢ）にさ
らに、更新ノードキーによって暗号化したコンテンツ等
のメッセージデータとを格納した情報記録媒体を各デバ
イスに提供する構成が可能である。デバイスは有効化キ
ーブロック（ＥＫＢ）に含まれる暗号化キーデータをタ
グ部の識別データにしたがって順次抽出して復号し、コ
ンテンツの復号に必要なキーを取得してコンテンツの利
用を行なうことが可能となる。もちろん、有効化キーブ
ロック（ＥＫＢ）をインターネット等のネットワークを
介して配信する構成としてもよい。
【０１６３】［カテゴリツリー単位のＥＫＢ管理構成］
次に、キー配信構成としてのツリー構成を構成するノー
ドあるいはリーフを、複数のノードあるいはリーフの集
合としてのブロックで管理する構成について説明する。
なお、複数のノードあるいはリーフの集合としてのブロ
ックを以下カテゴリツリーと呼ぶ。カテゴリツリーは、
デバイスの種類に応じて設定される集合であったり、あ
るいはデバイス提供メーカー、コンテンツプロバイダ、
決済機関等の管理単位等、ある共通点を持った処理単
位、管轄単位、あるいは提供サービス単位等、様々な態
様の集合として設定される。
【０１６４】カテゴリツリーについて、図２８を用いて
説明する。図２８（ａ）はツリーのカテゴリツリー単位
での管理構成を説明する図である。１つのカテゴリツリ
ーは図では、三角形として示し、例えば１カテゴリツリ
ー２７０１内には、複数のノードが含まれる。１カテゴ
リツリー内のノード構成を示すのが（ｂ）である。１つ
のカテゴリツリーは、１つのノードを頂点とした複数段
の２分岐形ツリーによって構成される。以下、カテゴリ
ツリーの頂点ノード２７０２をサブルートと呼ぶ。
【０１６５】ツリーの末端は、（ｃ）に示すようにリー
フ、すなわちデバイスによって構成される。デバイス
は、複数デバイスをリーフとし、サブルートである頂点
ノード２７０２を持つツリーによって構成されるいずれ
かのカテゴリツリーに属する。
【０１６６】図２８（ａ）から理解されるように、カテ
ゴリツリーは、階層構造を持つ。この階層構造につい
て、図２９を用いて説明する。
【０１６７】図２９（ａ）は、階層構造を簡略化して説
明するための図であり、Ｋｒｏｏｔから数段下の段にカ
テゴリツリーＡ０１〜Ａｎｎが構成され、カテゴリツリ
ーＡ１〜Ａｎの下位には、さらに、カテゴリツリーＢ０
１〜Ｂｎｋ、さらに、その下位にカテゴリツリーＣ１〜
Ｃｎｑが設定されている。各カテゴリツリーは、図２９
（ｂ），（ｃ）に示す如く、複数段のノード、リーフに
よって構成されるツリー形状を持つ。
【０１６８】例えばカテゴリツリーＢｎｋの構成は、
（ｂ）に示すように、サブルート２８１１を頂点ノード
として、末端ノード２８１２に至るまでの複数ノードを
有する。このカテゴリツリーは識別子Ｂｎｋを持ち、カ
テゴリツリーＢｎｋ内のノードに対応するノードキー管
理をカテゴリツリーＢｎｋ独自に実行することにより、
末端ノード２８１２を頂点として設定される下位（子）
カテゴリツリーの管理を実行する。また、一方、カテゴ
リツリーＢｎｋは、サブルート２８１１を末端ノードと
して持つ上位（親）カテゴリツリーＡｎｎの管理下にあ
る。
【０１６９】カテゴリツリーＣｎ３の構成は、（ｃ）に
示すように、サブルート２８５１を頂点ノードとして、
各デバイスである末端ノード２８５２、この場合はリー
フに至るまで複数ノード、リーフを有する。このカテゴ
リツリーは識別子Ｃｎ３を持ち、カテゴリツリーＣｎ３
内のノード、リーフに対応するノードキー、リーフキー
管理をカテゴリツリーＣｎ３独自に実行することによ
り、末端ノード２８５２に対応するリーフ（デバイス）
の管理を実行する。また、一方、カテゴリツリーＣｎ３
は、サブルート２８５１を末端ノードとして持つ上位
（親）カテゴリツリーＢｎ２の管理下にある。各カテゴ
リツリーにおけるキー管理とは、例えばキー更新処理、
リボーク処理等であるが、これらは後段で詳細に説明す
る。
【０１７０】最下段カテゴリツリーのリーフであるデバ
イスには、デバイスの属するカテゴリツリーのリーフキ
ーから、自己の属するカテゴリツリーの頂点ノードであ
るサブルートノードに至るパスに位置する各ノードのノ
ードキーおよびリーフキーが格納される。例えば末端ノ
ード２８５２のデバイスは、末端ノード（リーフ）２８
５２から、サブルートノード２８５１までの各キーを格
納する。
【０１７１】図３０を用いて、さらにカテゴリツリーの
構成について説明する。カテゴリツリーは様々な段数に
よって構成されるツリー構造を持つことが可能である。
段数、すなわちデプス（depth）は、カテゴリツリーで
管理する末端ノードに対応する下位（子）カテゴリツリ
ーの数、あるいはリーフとしてのデバイス数に応じて設
定可能である。
【０１７２】図３０の（ａ）に示すような上下カテゴリ
ツリー構成を具体化すると、（ｂ）に示す態様となる。
ルートツリーは、ルートキーを持つ最上段のツリーであ
る。ルートツリーの末端ノードに複数の下位カテゴリツ
リーとしてカテゴリツリーＡ，Ｂ，Ｃが設定され、さら
に、カテゴリツリーＣの下位カテゴリツリーとしてカテ
ゴリツリーＤが設定される。カテゴリツリーＣ２９０１
は、その末端ノードの１つ以上のノードをリザーブノー
ド２９５０として保持し、自己の管理するカテゴリツリ
ーを増加させる場合、さらに複数段のツリー構成を持つ
カテゴリツリーＣ’２９０２をリザーブノード２９５０
を頂点ノードとして新設することにより、管理末端ノー
ド２９７０を増加させて、管理末端ノードに増加した下
位カテゴリツリーを追加することができる。
【０１７３】リザーブノードについて、さらに図３１を
用いて説明する。カテゴリツリーＡ，３０１１は、管理
する下位カテゴリツリーＢ，Ｃ，Ｄ…を持ち、１つのリ
ザーブノード３０２１を持つ。カテゴリツリーは管理対
象の下位カテゴリツリーをさらに増加させたい場合、リ
ザーブノード３０２１に、自己管理の下位カテゴリツリ
ーＡ’，３０１２を設定し、下位カテゴリツリーＡ’，
３０１２の末端ノードにさらに管理対象の下位カテゴリ
ツリーＦ，Ｇを設定することができる。自己管理の下位
カテゴリツリーＡ’，３０１２も、その末端ノードの少
なくとも１つをリザーブノード３０２２として設定する
ことにより、さらに下位カテゴリツリーＡ’’３０１３
を設定して、さらに管理カテゴリツリーを増加させるこ
とができる。下位カテゴリツリーＡ’’３０１３の末端
ノードにも１以上のリザーブノードを確保する。このよ
うなリザーブノード保有構成をとることにより、あるカ
テゴリツリーの管理する下位カテゴリツリーは、際限な
く増加させることが可能となる。なお、リザーブカテゴ
リツリーは、末端ノードの１つのみではなく、複数個設
定する構成としてもよい。
【０１７４】それぞれのカテゴリツリーでは、カテゴリ
ツリー単位で有効化キーブロック（ＥＫＢ）が構成さ
れ、カテゴリツリー単位でのキー更新、リボーク処理を
実行することになる。図３１のように複数のカテゴリツ
リーＡ，Ａ’，Ａ’’には各カテゴリツリー個々の有効
化キーブロック（ＥＫＢ）が設定されることになるが、
これらは、カテゴリツリーＡ，Ａ’，Ａ’’を共通に管
理する例えばあるデバイスメーカーが一括して管理する
ことが可能である。
【０１７５】［新規カテゴリツリーの登録処理］次に、
新規カテゴリツリーの登録処理について説明する。登録
処理シーケンスを図３２に示す。図３２のシーケンスに
したがって説明する。新たにツリー構成中に追加される
新規（子）カテゴリツリー（Ｎ−Ｅｎ）は、上位（親）
カテゴリツリー（Ｐ−Ｅｎ）に対して新規登録要求を実
行する。なお、各カテゴリツリーは、公開鍵暗号方式に
従った公開鍵を保有し、新規カテゴリツリーは自己の公
開鍵を登録要求に際して上位カテゴリツリー（Ｐ−Ｅ
ｎ）に送付する。
【０１７６】登録要求を受領した上位カテゴリツリー
（Ｐ−Ｅｎ）は、受領した新規（子）カテゴリツリー
（Ｎ−Ｅｎ）の公開鍵を証明書発行局（ＣＡ：Certific
ate Authority）に転送し、ＣＡの署名を付加した新規
（子）カテゴリツリー（Ｎ−Ｅｎ）の公開鍵を受領す
る。これらの手続きは、上位カテゴリツリー（Ｐ−Ｅ
ｎ）と新規（子）カテゴリツリー（Ｎ−Ｅｎ）との相互
認証の手続きとして行われる。
【０１７７】これらの処理により、新規登録要求カテゴ
リツリーの認証が終了すると、上位カテゴリツリー（Ｐ
−Ｅｎ）は、新規（子）カテゴリツリー（Ｎ−Ｅｎ）の
登録を許可し、新規（子）カテゴリツリー（Ｎ−Ｅｎ）
のノードキーを新規（子）カテゴリツリー（Ｎ−Ｅｎ）
に送信する。このノードキーは、上位カテゴリツリー
（Ｐ−Ｅｎ）の末端ノードの１つのノードキーであり、
かつ、新規（子）カテゴリツリー（Ｎ−Ｅｎ）の頂点ノ
ード、すなわちサブルートキーに対応する。
【０１７８】このノードキー送信が終了すると、新規
（子）カテゴリツリー（Ｎ−Ｅｎ）は、新規（子）カテ
ゴリツリー（Ｎ−Ｅｎ）のツリー構成を構築し、構築し
たツリーの頂点に受信した頂点ノードのサブルートキー
を設定し、各ノード、リーフのキーを設定して、カテゴ
リツリー内の有効化キーブロック（ＥＫＢ）を生成す
る。１つのカテゴリツリー内の有効化キーブロック（Ｅ
ＫＢ）をサブＥＫＢと呼ぶ。
【０１７９】一方、上位カテゴリツリー（Ｐ−Ｅｎ）
は、新規（子）カテゴリツリー（Ｎ−Ｅｎ）の追加によ
り、有効化する末端ノードを追加した上位カテゴリツリ
ー（Ｐ−Ｅｎ）内のサブＥＫＢを生成する。
【０１８０】新規（子）カテゴリツリー（Ｎ−Ｅｎ）
は、新規（子）カテゴリツリー（Ｎ−Ｅｎ）内のノード
キー、リーフキーによって構成されるサブＥＫＢを生成
すると、これを上位カテゴリツリー（Ｐ−Ｅｎ）に送信
する。
【０１８１】新規（子）カテゴリツリー（Ｎ−Ｅｎ）か
らサブＥＫＢを受信した上位カテゴリツリー（Ｐ−Ｅ
ｎ）は、受信したサブＥＫＢと、上位カテゴリツリー
（Ｐ−Ｅｎ）の更新したサブＥＫＢとをキー発行センタ
ー（ＫＤＣ：Key Distribute Center）に送信する。
【０１８２】キー発行センター（ＫＤＣ）は、すべての
カテゴリツリーのサブＥＫＢに基づいて、様々な態様の
ＥＫＢ、すなわち特定のカテゴリツリーあるいはデバイ
スのみが復号可能なＥＫＢを生成することが可能とな
る。このように復号可能なカテゴリツリーあるいはデバ
イスを設定したＥＫＢを例えばコンテンツプロバイダに
提供し、コンテンツプロバイダがＥＫＢに基づいてコン
テンツキーを暗号化して、ネットワークを介して、ある
いは記録媒体に格納して提供することにより、特定のデ
バイスでのみ利用可能なコンテンツを提供することが可
能となる。
【０１８３】なお、新規カテゴリツリーのサブＥＫＢの
キー発行センター（ＫＤＣ）に対する登録処理は、サブ
ＥＫＢを上位カテゴリツリーを介してを順次転送して実
行する方法に限るものではなく、上位カテゴリツリーを
介さずに、新規登録カテゴリツリーから直接、キー発行
センター（ＫＤＣ）に登録する処理を実行する構成とし
てもよい。
【０１８４】上位カテゴリツリーと、上位カテゴリツリ
ーに新規追加する下位カテゴリツリーとの対応について
図３３を用いて説明する。上位カテゴリツリーの末端ノ
ードの１つ３２０１を新規追加カテゴリツリーの頂点ノ
ードとして、下位カテゴリツリーに提供することによっ
て下位カテゴリツリーは、上位カテゴリツリーの管理下
のカテゴリツリーとして追加される。上位カテゴリツリ
ーの管理下のカテゴリツリーとは、後段で詳細に説明す
るが、下位カテゴリツリーのリボーク（排除）処理を上
位カテゴリツリーが実行できる構成であるという意味を
含むものである。
【０１８５】図３３に示すように、上位カテゴリツリー
に新規カテゴリツリーが設定されると、上位カテゴリツ
リーのリーフである末端ノードの１つのノード３２０１
と新規追加カテゴリツリーの頂点ノード３２０２とが等
しいノードとして設定される。すなわち上位ノードの１
つのリーフである１つの末端ノードが、新規追加カテゴ
リツリーのサブルートとして設定される。このように設
定されることにより、新規追加カテゴリツリーが全体ツ
リー構成の下で有効化される。
【０１８６】図３４に新規追加カテゴリツリーを設定し
た際に上位カテゴリツリーが生成する更新ＥＫＢの例を
示す。図３４は、（ａ）に示す構成、すなわち既に有効
に存在する末端ノード（ｎｏｄｅ０００）３３０１と末
端ノード（ｎｏｄｅ００１）３３０２があり、ここに新
規追加カテゴリツリーに新規カテゴリツリー追加末端ノ
ード（ｎｏｄｅ１００）３３０３を付与した際に上位カ
テゴリツリーが生成するサブＥＫＢの例を示したもので
ある。
【０１８７】サブＥＫＢは、図３４の（ｂ）に示すよう
にな構成を持つ。それぞれ有効に存在する末端ノードキ
ーにより暗号化された上位ノードキー、上位ノードキー
で暗号化されたさらなる上位ノードキー、…さらに上位
に進行してサブルートキーに至る構成となっている。こ
の構成によりサブＥＫＢが生成される。各カテゴリツリ
ーは図３４（ｂ）に示すと同様、有効な末端ノード、あ
るいはリーフキーにより暗号化された上位ノードキー、
上位ノードキーでさらに上位のノードキーを暗号化し、
順次上位に深厚してサブルートに至る暗号化データによ
って構成されるＥＫＢを有し、これを管理する。
【０１８８】［カテゴリツリー管理下におけるリボーク
処理］次に、キー配信ツリー構成をカテゴリツリー単位
として管理する構成におけるデバイスあるいはカテゴリ
ツリーのリボーク（排除）処理について説明する。先の
図３，４では、ツリー構成全体の中から特定のデバイス
のみ復号可能で、リボークされたデバイスは復号不可能
な有効化キーブロック（ＥＫＢ）を配信する処理につい
て説明した。図３，４で説明したリボーク処理は、ツリ
ー全体の中から特定のリーフであるデバイスをリボーク
する処理であったが、ツリーのカテゴリツリー管理によ
る構成では、カテゴリツリー毎にリボーク処理が実行可
能となる。
【０１８９】図３５以下の図を用いてカテゴリツリー管
理下のツリー構成におけるリボーク処理について説明す
る。図３５は、ツリーを構成するカテゴリツリーのう
ち、最下段のカテゴリツリー、すなわち個々のデバイス
を管理しているカテゴリツリーによるデバイスのリボー
ク処理を説明する図である。
【０１９０】図３５（ａ）は、カテゴリツリー管理によ
るキー配信ツリー構造を示している。ツリー最上位には
ルートノードが設定され、その数段下にカテゴリツリー
Ａ０１〜Ａｎｎ、さらにその下位段にＢ０１〜Ｂｎｋの
カテゴリツリー、さらにその下位段にＣ１〜ｃｎのカテ
ゴリツリーが構成されている。最も下のカテゴリツリー
は、末端ノード（リーフ）が個々のデバイス、例えば記
録再生器、再生専用器等であるとする。
【０１９１】ここで、リボーク処理は、各カテゴリツリ
ーにおいて独自に実行される。例えば、最下段のカテゴ
リツリーＣ１〜Ｃｎでは、リーフのデバイスのリボーク
処理が実行される。図３５（ｂ）には、最下段のカテゴ
リツリーの１つであるカテゴリツリーＣｎ，３４３０の
ツリー構成を示している。カテゴリツリーＣｎ，３４３
０は、頂点ノード３４３１を持ち、末端ノードであるリ
ーフに複数のデバイスを持つ構成である。
【０１９２】この末端ノードであるリーフ中に、リボー
ク対象となるデバイス、例えばデバイス３４３２があっ
たとすると、カテゴリツリーＣｎ，３４３０は、独自に
更新したカテゴリツリーＣｎ内のノードキー、リーフキ
ーによって構成される有効化キーブロック（サブＥＫ
Ｂ）を生成する。この有効化キーブロックは、リボーク
デバイス３４３２においては復号できず、他のリーフを
構成するデバイスにおいてのみ復号可能な暗号化キーに
より構成されるキーブロックである。カテゴリツリーＣ
ｎの管理者は、これを更新されたサブＥＫＢとして生成
する。具体的には、サブルートからリボークデバイス３
４３２に連なるパスを構成する各ノード３４３１，３４
３４，３４３５のノードキーを更新して、この更新ノー
ドキーをリボークデバイス３４３２以外のリーフデバイ
スにおいてのみ復号可能な暗号化キーとして構成したブ
ロックを更新サブＥＫＢとする。この処理は、先の図
３，４において説明したリボーク処理構成において、ル
ートキーを、カテゴリツリーの頂点キーであるサブルー
トキーに置き換えた処理に対応する。
【０１９３】このようにカテゴリツリーＣｎ，３４３０
がリボーク処理によって更新した有効化キーブロック
（サブＥＫＢ）は、上位カテゴリツリーに送信される。
この場合、上位カテゴリツリーはカテゴリツリーＢｎ
ｋ，３４２０であり、カテゴリツリーＣｎ，３４３０の
頂点ノード３４３１を末端ノードとして有するカテゴリ
ツリーである。
【０１９４】カテゴリツリーＢｎｋ，３４２０は、下位
カテゴリツリーＣｎ，３４３０から有効化キーブロック
（サブＥＫＢ）を受領すると、そのキーブロックに含ま
れるカテゴリツリーＣｎｋ，３４３０の頂点ノード３４
３１に対応するカテゴリツリーＢｎｋ，３４２０の末端
ノード３４３１を、下位カテゴリツリーＣｎ，３４３０
において更新されたキーに設定して、自身のカテゴリツ
リーＢｎｋ，３４２０のサブＥＫＢの更新処理を実行す
る。図３５（ｃ）にカテゴリツリーＢｎｋ，３４２０の
ツリー構成を示す。カテゴリツリーＢｎｋ，３４２０に
おいて、更新対象となるノードキーは、図３５（ｃ）の
サブルート３４２１からリボークデバイスを含むカテゴ
リツリーを構成する末端ノード３４３１に至るパス上の
ノードキーである。すなわち、更新サブＥＫＢを送信し
てきたカテゴリツリーのノード３４３１に連なるパスを
構成する各ノード３４２１，３４２４，３４２５のノー
ドキーが更新対象となる。これら各ノードのノードキー
を更新してカテゴリツリーＢｎｋ，３４２０の新たな更
新サブＥＫＢを生成する。
【０１９５】さらに、カテゴリツリーＢｎｋ，３４２０
が更新した有効化キーブロック（サブＥＫＢ）は、上位
カテゴリツリーに送信される。この場合、上位カテゴリ
ツリーはカテゴリツリーＡｎｎ，３４１０であり、カテ
ゴリツリーＢｎｋ，３４２０の頂点ノード３４２１を末
端ノードとして有するカテゴリツリーである。
【０１９６】カテゴリツリーＡｎｎ，３４１０は、下位
カテゴリツリーＢｎｋ，３４２０から有効化キーブロッ
ク（サブＥＫＢ）を受領すると、そのキーブロックに含
まれるカテゴリツリーＢｎｋ，３４２０の頂点ノード３
４２１に対応するカテゴリツリーＡｎｎ，３４１０の末
端ノード３４２１を、下位カテゴリツリーＢｎｋ，３４
２０において更新されたキーに設定して、自身のカテゴ
リツリーＡｎｎ，３４１０のサブＥＫＢの更新処理を実
行する。図３５（ｄ）にカテゴリツリーＡｎｎ，３４１
０のツリー構成を示す。カテゴリツリーＡｎｎ，３４１
０において、更新対象となるノードキーは、図３５
（ｄ）のサブルート３４１１から更新サブＥＫＢを送信
してきたカテゴリツリーのノード３４２１に連なるパス
を構成する各ノード３４１１，３４１４，３４１５のノ
ードキーである。これら各ノードのノードキーを更新し
てカテゴリツリーＡｎｎ，３４１０の新たな更新サブＥ
ＫＢを生成する。
【０１９７】これらの処理を順次、上位のカテゴリツリ
ーにおいて実行し、図３０（ｂ）で説明したルートカテ
ゴリツリーまで実行する。この一連の処理により、デバ
イスのリボーク処理が完結する。なお、それぞれのカテ
ゴリツリーにおいて更新されたサブＥＫＢは、最終的に
キー発行センター（ＫＤＣ）に送信され、保管される。
キー発行センター（ＫＤＣ）は、すべてのカテゴリツリ
ーの更新サブＥＫＢに基づいて、様々なＥＫＢを生成す
る。更新ＥＫＢは、リボークされたデバイスでの復号が
不可能な暗号化キーブロックとなる。
【０１９８】デバイスのリボーク処理のシーケンス図を
図３６に示す。処理手順を図３６のシーケンス図に従っ
て説明する。まず、ツリー構成の最下段にあるデバイス
管理カテゴリツリー（Ｄ−Ｅｎ）は、デバイス管理カテ
ゴリツリー（Ｄ−Ｅｎ）内のリボーク対象のリーフを排
除するために必要なキー更新を行ない、デバイス管理カ
テゴリツリー（Ｄ−Ｅｎ）の新たなサブＥＫＢ（Ｄ）を
生成する。更新サブＥＫＢ（Ｄ）は、上位カテゴリツリ
ーに送付される。更新サブＥＫＢ（Ｄ）を受領した上位
（親）カテゴリツリー（Ｐ１−Ｅｎ）は、更新サブＥＫ
Ｂ（Ｄ）の更新頂点ノードに対応した末端ノードキーの
更新および、その末端ノードからサブルートに至るパス
上のノードキーを更新した更新サブＥＫＢ（Ｐ１）を生
成する。これらの処理を順次、上位カテゴリツリーにお
いて実行して、最終的に更新されたすべてのサブＥＫＢ
がキー発行センター（ＫＤＣ）に格納され管理される。
【０１９９】図３７にデバイスのリボーク処理によって
上位カテゴリツリーが更新処理を行なって生成する有効
化キーブロック（ＥＫＢ）の例を示す。
【０２００】図３７は、（ａ）に示す構成において、リ
ボークデバイスを含む下位カテゴリツリーから更新サブ
ＥＫＢを受信した上位カテゴリツリーにおいて生成する
ＥＫＢの例を説明する図である。リボークデバイスを含
む下位カテゴリツリーの頂点ノードは、上位カテゴリツ
リーの末端ノード（ｎｏｄｅ１００）３６０１に対応す
る。
【０２０１】上位カテゴリツリーは、上位カテゴリツリ
ーのサブルートから末端ノード（ｎｏｄｅ１００）３６
０１までのパスに存在するノードキーを更新して新たな
更新サブＥＫＢを生成する。更新サブＥＫＢは、図３７
（ｂ）のようになる。更新されたキーは、下線およ
び［’］を付して示してある。このように更新された末
端ノードからサブルートまでのパス上のノードキーを更
新してそのカテゴリツリーにおける更新サブＥＫＢとす
る。
【０２０２】次に、リボークする対象をカテゴリツリー
とした場合の処理、すなわちカテゴリツリーのリボーク
処理について説明する。
【０２０３】図３８（ａ）は、カテゴリツリー管理によ
るキー配信ツリー構造を示している。ツリー最上位には
ルートノードが設定され、その数段下にカテゴリツリー
Ａ０１〜Ａｎｎ、さらにその下位段にＢ０１〜Ｂｎｋの
カテゴリツリー、さらにその下位段にＣ１〜ｃｎのカテ
ゴリツリーが構成されている。最も下のカテゴリツリー
は、末端ノード（リーフ）が個々のデバイス、例えば記
録再生器、再生専用器等であるとする。
【０２０４】ここで、リボーク処理を、カテゴリツリー
Ｃｎ，３７３０に対して実行する場合について説明す
る。最下段のカテゴリツリーＣｎ，３７３０は、図３８
（ｂ）に示すように頂点ノード３４３１を持ち、末端ノ
ードであるリーフに複数のデバイスを持つ構成である。
【０２０５】カテゴリツリーＣｎ，３７３０をリボーク
することにより、カテゴリツリーＣｎ，３７３０に属す
るすべてのデバイスのツリー構造からの一括排除が可能
となる。カテゴリツリーＣｎ，３７３０のリボーク処理
は、カテゴリツリーＣｎ，３７３０の上位カテゴリツリ
ーであるカテゴリツリーＢｎｋ，３７２０において実行
される。カテゴリツリーＢｎｋ，３７２０は、カテゴリ
ツリーＣｎ，３７３０の頂点ノード３７３１を末端ノー
ドとして有するカテゴリツリーである。
【０２０６】カテゴリツリーＢｎｋ，３７２０は、下位
カテゴリツリーＣｎ，３７３０のリボークを実行する場
合、カテゴリツリーＣｎｋ，３７３０の頂点ノード３７
３１に対応するカテゴリツリーＢｎｋ，３７２０の末端
ノード３７３１を更新し、さらに、そのリボークカテゴ
リツリー３７３０からカテゴリツリーＢｎｋ，３７２０
のサブルートまでのパス上のノードキーの更新を行ない
有効化キーブロックを生成して更新サブＥＫＢを生成す
る。更新対象となるノードキーは、図３８（ｃ）のサブ
ルート３７２１からリボークカテゴリツリーの頂点ノー
ドを構成する末端ノード３７３１に至るパス上のノード
キーである。すなわち、ノード３７２１，３７２４，３
７２５，３７３１のノードキーが更新対象となる。これ
ら各ノードのノードキーを更新してカテゴリツリーＢｎ
ｋ，３７２０の新たな更新サブＥＫＢを生成する。
【０２０７】あるいは、カテゴリツリーＢｎｋ，３７２
０は、下位カテゴリツリーＣｎ，３７３０のリボークを
実行する場合、カテゴリツリーＣｎｋ，３７３０の頂点
ノード３７３１に対応するカテゴリツリーＢｎｋ，３７
２０の末端ノード３７３１は更新せず、そのリボークカ
テゴリツリー３７３０からカテゴリツリーＢｎｋ，３７
２０のサブルートまでのパス上の末端ノード３７３１を
除くノードキーの更新を行ない有効化キーブロックを生
成して更新サブＥＫＢを生成してもよい。
【０２０８】さらに、カテゴリツリーＢｎｋ，３７２０
が更新した有効化キーブロック（サブＥＫＢ）は、上位
カテゴリツリーに送信される。この場合、上位カテゴリ
ツリーはカテゴリツリーＡｎｎ，３７１０であり、カテ
ゴリツリーＢｎｋ，３７２０の頂点ノード３７２１を末
端ノードとして有するカテゴリツリーである。
【０２０９】カテゴリツリーＡｎｎ，３７１０は、下位
カテゴリツリーＢｎｋ，３７２０から有効化キーブロッ
ク（サブＥＫＢ）を受領すると、そのキーブロックに含
まれるカテゴリツリーＢｎｋ，３７２０の頂点ノード３
７２１に対応するカテゴリツリーＡｎｎ，３７１０の末
端ノード３７２１を、下位カテゴリツリーＢｎｋ，３７
２０において更新されたキーに設定して、自身のカテゴ
リツリーＡｎｎ，３７１０のサブＥＫＢの更新処理を実
行する。図３８（ｄ）にカテゴリツリーＡｎｎ，３７１
０のツリー構成を示す。カテゴリツリーＡｎｎ，３７１
０において、更新対象となるノードキーは、図３８
（ｄ）のサブルート３７１１から更新サブＥＫＢを送信
してきたカテゴリツリーのノード３７２１に連なるパス
を構成する各ノード３７１１，３７１４，３７１５のノ
ードキーである。これら各ノードのノードキーを更新し
てカテゴリツリーＡｎｎ，３７１０の新たな更新サブＥ
ＫＢを生成する。
【０２１０】これらの処理を順次、上位のカテゴリツリ
ーにおいて実行し、図３０（ｂ）で説明したルートカテ
ゴリツリーまで実行する。この一連の処理により、カテ
ゴリツリーのリボーク処理が完結する。なお、それぞれ
のカテゴリツリーにおいて更新されたサブＥＫＢは、最
終的にキー発行センター（ＫＤＣ）に送信され、保管さ
れる。キー発行センター（ＫＤＣ）は、すべてのカテゴ
リツリーの更新サブＥＫＢに基づいて、様々なＥＫＢを
生成する。更新ＥＫＢは、リボークされたカテゴリツリ
ーに属するデバイスでの復号が不可能な暗号化キーブロ
ックとなる。
【０２１１】カテゴリツリーのリボーク処理のシーケン
ス図を図３９に示す。処理手順を図３９のシーケンス図
に従って説明する。まず、カテゴリツリーをリボークし
ようとするカテゴリツリー管理カテゴリツリー（Ｅ−Ｅ
ｎ）は、カテゴリツリー管理カテゴリツリー（Ｅ−Ｅ
ｎ）内のリボーク対象の末端ノードを排除するために必
要なキー更新を行ない、カテゴリツリー管理カテゴリツ
リー（Ｅ−Ｅｎ）の新たなサブＥＫＢ（Ｅ）を生成す
る。更新サブＥＫＢ（Ｅ）は、上位カテゴリツリーに送
付される。更新サブＥＫＢ（Ｅ）を受領した上位（親）
カテゴリツリー（Ｐ１−Ｅｎ）は、更新サブＥＫＢ
（Ｅ）の更新頂点ノードに対応した末端ノードキーの更
新および、その末端ノードからサブルートに至るパス上
のノードキーを更新した更新サブＥＫＢ（Ｐ１）を生成
する。これらの処理を順次、上位カテゴリツリーにおい
て実行して、最終的に更新されたすべてのサブＥＫＢが
キー発行センター（ＫＤＣ）に格納され管理される。キ
ー発行センター（ＫＤＣ）は、すべてのカテゴリツリー
の更新サブＥＫＢに基づいて、様々なＥＫＢを生成す
る。更新ＥＫＢは、リボークされたカテゴリツリーに属
するデバイスでの復号が不可能な暗号化キーブロックと
なる。
【０２１２】図４０にリボークされた下位カテゴリツリ
ーと、リボークを行なった上位カテゴリツリーの対応を
説明する図を示す。上位カテゴリツリーの末端ノード３
９０１は、カテゴリツリーのリボークにより更新され、
上位カテゴリツリーのツリーにおける末端ノード３９０
１からサブルートまでのパスに存在するノードキーの更
新により、新たなサブＥＫＢが生成される。その結果、
リボークされた下位カテゴリツリーの頂点ノード３９０
２のノードキーと、上位カテゴリツリーの末端ノード３
９０１のノードキーは不一致となる。カテゴリツリーの
リボーク後にキー発行センター（ＫＤＣ）によって生成
されるＥＫＢは、上位カテゴリツリーにおいて更新され
た末端ノード３９０１のキーに基づいて生成されること
になるので、その更新キーを保有しない下位カテゴリツ
リーのリーフに対応するデバイスは、キー発行センター
（ＫＤＣ）によって生成されるＥＫＢの復号ガ不可能に
なる。
【０２１３】なお、上述の説明では、デバイスを管理す
る最下段のカテゴリツリーのリボーク処理について説明
したが、ツリーの中段にあるカテゴリツリー管理カテゴ
リツリーをその上位カテゴリツリーがリボークする処理
も上記と同様のプロセスによって可能である。中段のエ
ンティティ管理カテゴリツリーをリボークすることによ
り、リボークされたカテゴリツリー管理カテゴリツリー
の下位に属するすべての複数カテゴリツリーおよびデバ
イスを一括してリボーク可能となる。
【０２１４】このように、カテゴリツリー単位でのリボ
ークを実行することにより、１つ１つのデバイス単位で
実行するリボーク処理に比較して簡易なプロセスでのリ
ボーク処理が可能となる。
【０２１５】［カテゴリツリーのケイパビリティ管理］
次に、カテゴリツリー単位でのキー配信ツリー構成にお
いて、各エンティティの許容するケイパビリティ(Capab
ility)を管理して、ケイパビリティに応じたコンテンツ
配信を行なう処理構成について説明する。ここでケイパ
ビリティとは、例えば特定の圧縮音声データの復号が可
能であるとか、特定の音声再生方式を許容するとか、あ
るいは特定の画像処理プログラムを処理できる等、デバ
イスがどのようなコンテンツ、あるいはプログラム等を
処理できるデバイスであるか、すなわちデバイスのデー
タ処理能力の定義情報である。
【０２１６】図４１にケイパビリティを定義したカテゴ
リツリー構成例を示す。キー配信ツリー構成の最頂点に
にルートノードが位置し、下層に複数のカテゴリツリー
が接続されて各ノードが２分岐を持つツリー構成であ
る。ここで、例えばカテゴリツリー４００１は、音声再
生方式Ａ，Ｂ，Ｃのいずれかを許容するケイパビリティ
を持つカテゴリツリーとして定義される。具体的には、
例えばある音声圧縮プログラム−Ａ、Ｂ、またはＣ方式
で圧縮した音楽データを配信した場合に、カテゴリツリ
ー４００１以下に構成されたカテゴリツリーに属するデ
バイスは圧縮データを伸長する処理が可能である。
【０２１７】同様にカテゴリツリー４００２は音声再生
方式ＢまたはＣ、カテゴリツリー４００３は音声再生方
式ＡまたはＢ、カテゴリツリー４００４は音声再生方式
Ｂ、カテゴリツリー４００５は音声再生方式Ｃを処理す
ることが可能なケイパビリティを持つカテゴリツリーと
して定義される。
【０２１８】一方、カテゴリツリー４０２１は、画像再
生方式ｐ，ｑ，ｒを許容するカテゴリツリーとして定義
され、カテゴリツリー４０２２は方式ｐ，ｑの画像再生
方式、カテゴリツリー４０２３は方式ｐの画像再生が可
能なケイパビリティを持つカテゴリツリーとして定義さ
れる。
【０２１９】このような各カテゴリツリーのケイパビリ
ティ情報は、キー発行センター（ＫＤＣ）において管理
される。キー発行センター（ＫＤＣ）は、例えばあるコ
ンテンツプロバイダが特定の圧縮プログラムで圧縮した
音楽データを様々なデバイスに配信したい場合、その特
定の圧縮プログラムを再生可能なデバイスに対してのみ
復号可能な有効化キーブロック（ＥＫＢ）を各カテゴリ
ツリーのケイパビリティ情報に基づいて生成することが
できる。コンテンツを提供するコンテンツプロバイダ
は、ケイパビリティ情報に基づいて生成した有効化キー
ブロック（ＥＫＢ）によって暗号化したコンテンツキー
を配信し、そのコンテンツキーで暗号化した圧縮音声デ
ータを各デバイスに提供する。この構成により、データ
の処理が可能なデバイスに対してのみ特定の処理プログ
ラムを確実に提供することが可能となる。
【０２２０】なお、図４１では全てのカテゴリツリーに
ついてケイパビリティ情報を定義している構成である
が、図４１の構成ようにすべてのカテゴリツリーにケイ
パビリティ情報を定義することは必ずしも必要ではな
く、例えば図４２に示すようにデバイスが属する最下段
のカテゴリツリーについてのみケイパビリティを定義し
て、最下段のカテゴリツリーに属するデバイスのケイパ
ビリティをキー発行センター（ＫＤＣ）において管理し
て、コンテンツプロバイダが望む処理の可能なデバイス
にのみ復号可能な有効化キーブロック（ＥＫＢ）を最下
段のカテゴリツリーに定義されたケイパビリティ情報に
基づいて生成する構成としてもよい。図４２では、末端
ノードにデバイスが定義されたカテゴリツリー４１０１
＝４１０５におけるケイパビリテイが定義され、これら
のカテゴリツリーについてのケイパビリティをキー発行
センター（ＫＤＣ）において管理する構成である。例え
ばカテゴリツリー４１０１には音声再生については方式
Ｂ、画像再生については方式ｒの処理が可能なデバイス
が属している。カテゴリツリー４１０２には音声再生に
ついては方式Ａ、画像再生については方式ｑの処理が可
能なデバイスが属している等である。
【０２２１】図４３にキー発行センター（ＫＤＣ）にお
いて管理するケイパビリティ管理テーブルの構成例を示
す。ケイパビリティ管理テーブルは、図４３（ａ）のよ
うなデータ構成を持つ。すなわち、各カテゴリツリーを
識別する識別子としてのカテゴリツリーＩＤ、そのカテ
ゴリツリーに定義されたケイパビリティを示すケイパビ
リティリスト、このケイパビリティリストは図４３
（ｂ）に示すように、例えば音声データ再生処理方式
（Ａ）が処理可能であれば［１］、処理不可能であれは
［０］、音声データ再生処理方式（Ｂ）が処理可能であ
れば［１］、処理不可能であれは［０］…等、様々な態
様のデータ処理についての可否を１ビットづつ［１］ま
たは［０］を設定して構成されている。なお、このケイ
パビリティ情報の設定方法はこのような形式に限らず、
カテゴリツリーの管理デバイスについてのケイパビリテ
ィを識別可能であれば他の構成でもよい。
【０２２２】ケイパビリティ管理テーブルには、さら
に、各カテゴリツリーのサブＥＫＢ、あるいはサブＥＫ
Ｂが別のデータベースに格納されている場合は、サブＥ
ＫＢの識別情報が格納され、さらに、各カテゴリツリー
のサブルートノード識別データが格納される。
【０２２３】キー発行センター（ＫＤＣ）は、ケイパビ
リティ管理テーブルに基づいて、例えば特定のコンテン
ツの再生可能なデバイスのみが復号可能な有効化キーブ
ロック（ＥＫＢ）を生成する。図４４を用いて、ケイパ
ビリティ情報に基づく有効化キーブロックの生成処理に
ついて説明する。
【０２２４】まず、ステップＳ４３０１において、キー
発行センター（ＫＤＣ）は、ケイパビリティ管理テーブ
ルから、指定されたケイパビリティを持つカテゴリツリ
ーを選択する。具体的には、例えばコンテンツプロバイ
ダが音声データ再生処理方式Ａに基づく再生可能なデー
タを配信したい場合は、図４３（ａ）のケイパビリティ
リストから、例えば音声データ再生処理（方式Ａ）の項
目が［１］に設定されたカテゴリツリーを選択する。
【０２２５】次に、ステップＳ４３０２において、選択
されたカテゴリツリーによって構成される選択カテゴリ
ツリーＩＤのリストを生成する。次に、ステップＳ４３
０３で、選択カテゴリツリーＩＤによって構成されるツ
リーに必要なパス（キー配信ツリー構成のパス）を選択
する。ステップＳ４３０４では、選択カテゴリツリーＩ
Ｄのリストに含まれる全てのパス選択が完了したか否か
を判定し、完了するまで、ステップＳ４３０３において
パスを生成する。これは、複数のカテゴリツリーが選択
された場合に、それぞれのパスを順次選択する処理を意
味している。
【０２２６】選択カテゴリツリーＩＤのリストに含まれ
る全てのパス選択が完了すると、ステップＳ４３０５に
進み、選択したパスと、選択カテゴリツリーによっての
み構成されるキー配信ツリー構造を構築する。
【０２２７】次に、ステップＳ４３０６において、ステ
ップＳ４３０５で生成したツリー構造のノードキーの更
新処理を行ない、更新ノードキーを生成する。さらに、
ツリーを構成する選択カテゴリツリーのサブＥＫＢをケ
イパビリティ管理テーブルから取り出し、サブＥＫＢ
と、ステップＳ４３０６で生成した更新ノードキーとに
基づいて選択カテゴリツリーのデバイスにおいてのみ復
号可能な有効化キーブロック（ＥＫＢ）を生成する。こ
のようにして生成した有効化キーブロック（ＥＫＢ）
は、特定のケイパビリティを持つデバイスにおいてのみ
利用、すなわち復号可能な有効化キーブロック（ＥＫ
Ｂ）となる。この有効化キーブロック（ＥＫＢ）で例え
ばコンテンツキーを暗号化して、そのコンテンツキーで
特定プログラムに基づいて圧縮したコンテンツを暗号化
してデバイスに提供することで、キー発行センター（Ｋ
ＤＣ）によって選択された特定の処理可能なデバイスに
おいてのみコンテンツが利用される。
【０２２８】このようにキー発行センター（ＫＤＣ）
は、ケイパビリティ管理テーブルに基づいて、例えば特
定のコンテンツの再生可能なデバイスのみが復号可能な
有効化キーブロック（ＥＫＢ）を生成する。従って、新
たなカテゴリツリーが登録される場合には、その新規登
録カテゴリツリーのケイパビリティを予め取得すること
が必要となる。このカテゴリツリー新規登録に伴うケイ
パビリティ通知処理について図４５を用いて説明する。
【０２２９】図４５は、新規カテゴリツリーがキー配信
ツリー構成に参加する場合のケイパビリティ通知処理シ
ーケンスを示した図である。
【０２３０】新たにツリー構成中に追加される新規
（子）カテゴリツリー（Ｎ−Ｅｎ）は、上位（親）カテ
ゴリツリー（Ｐ−Ｅｎ）に対して新規登録要求を実行す
る。なお、各カテゴリツリーは、公開鍵暗号方式に従っ
た公開鍵を保有し、新規カテゴリツリーは自己の公開鍵
を登録要求に際して上位カテゴリツリー（Ｐ−Ｅｎ）に
送付する。
【０２３１】登録要求を受領した上位カテゴリツリー
（Ｐ−Ｅｎ）は、受領した新規（子）カテゴリツリー
（Ｎ−Ｅｎ）の公開鍵を証明書発行局（ＣＡ：Certific
ate Authority）に転送し、ＣＡの署名を付加した新規
（子）カテゴリツリー（Ｎ−Ｅｎ）の公開鍵を受領す
る。これらの手続きは、上位カテゴリツリー（Ｐ−Ｅ
ｎ）と新規（子）カテゴリツリー（Ｎ−Ｅｎ）との相互
認証の手続きとして行われる。
【０２３２】これらの処理により、新規登録要求カテゴ
リツリーの認証が終了すると、上位カテゴリツリー（Ｐ
−Ｅｎ）は、新規（子）カテゴリツリー（Ｎ−Ｅｎ）の
登録を許可し、新規（子）カテゴリツリー（Ｎ−Ｅｎ）
のノードキーを新規（子）カテゴリツリー（Ｎ−Ｅｎ）
に送信する。このノードキーは、上位カテゴリツリー
（Ｐ−Ｅｎ）の末端ノードの１つのノードキーであり、
かつ、新規（子）カテゴリツリー（Ｎ−Ｅｎ）の頂点ノ
ード、すなわちサブルートキーに対応する。
【０２３３】このノードキー送信が終了すると、新規
（子）カテゴリツリー（Ｎ−Ｅｎ）は、新規（子）カテ
ゴリツリー（Ｎ−Ｅｎ）のツリー構成を構築し、構築し
たツリーの頂点に受信した頂点ノードのサブルートキー
を設定し、各ノード、リーフのキーを設定して、カテゴ
リツリー内の有効化キーブロック（サブＥＫＢ）を生成
する。一方、上位カテゴリツリー（Ｐ−Ｅｎ）も、新規
（子）カテゴリツリー（Ｎ−Ｅｎ）の追加により、有効
化する末端ノードを追加した上位カテゴリツリー（Ｐ−
Ｅｎ）内のサブＥＫＢを生成する。
【０２３４】新規（子）カテゴリツリー（Ｎ−Ｅｎ）
は、新規（子）カテゴリツリー（Ｎ−Ｅｎ）内のノード
キー、リーフキーによって構成されるサブＥＫＢを生成
すると、これを上位カテゴリツリー（Ｐ−Ｅｎ）に送信
し、さらに、自己のカテゴリツリーで管理するデバイス
についてのケイパビリティ情報を上位カテゴリツリーに
通知する。
【０２３５】新規（子）カテゴリツリー（Ｎ−Ｅｎ）か
らサブＥＫＢおよびケイパビリティ情報を受信した上位
カテゴリツリー（Ｐ−Ｅｎ）は、受信したサブＥＫＢと
ケイパビリティ情報と、上位カテゴリツリー（Ｐ−Ｅ
ｎ）の更新したサブＥＫＢとをキー発行センター（ＫＤ
Ｃ：Key Distribute Center）に送信する。
【０２３６】キー発行センター（ＫＤＣ）は、受領した
カテゴリツリーのサブＥＫＢおよびケイパビリティ情報
とを図４３で説明したケイパビリティ管理テーブルに登
録し、ケイパビリティ管理テーブルを更新する。キー発
行センター（ＫＤＣ）は、更新したケイパビリティ管理
テーブルに基づいて、様々な態様のＥＫＢ、すなわち特
定のケイパビリティを持つカテゴリツリーあるいはデバ
イスのみが復号可能なＥＫＢを生成することが可能とな
る。
【０２３７】［ＥＫＢタイプ定義リストを使用したＥＫ
Ｂ管理構成］次に、１以上の選択されたカテゴリツリー
において復号可能なＥＫＢを生成して各カテゴリツリー
に属するデバイスに共通に使用可能なＥＫＢを提供する
構成において、どのカテゴリツリーで処理可能、すなわ
ち復号可能であるかを示すＥＫＢタイプ定義リストを使
用した構成について説明する。
【０２３８】本構成においては、キー発行センター（Ｋ
ＤＣ）は、コンテンツプロバイダなどのＥＫＢの使用、
発行処理を望むＥＫＢリクエスタからＥＫＢ発行要求を
受領する。ＥＫＢ発行要求にはＥＫＢタイプ定義リスト
に定義されたＥＫＢタイプを示すＥＫＢタイプ識別ナン
バーが含まれ、キー発行センター（ＫＤＣ）は、ＥＫＢ
タイプ識別ナンバーに従って１または複数のカテゴリツ
リーにおいて処理（復号）可能なＥＫＢを生成する。
【０２３９】ＥＫＢの生成に際しては、キー発行センタ
ー（ＫＤＣ）は、ＥＫＢタイプ定義リストのＥＫＢタイ
プ識別ナンバーに対応して設定された各カテゴリツリー
のトップノード識別子に基づき、カテゴリツリー管理者
としてのトップレベル・カテゴリ・エンティテイ（ＴＬ
ＣＥ：Top Level Category Entity）にサブＥＫＢの生
成を要求し、各ＴＬＣＥの生成したサブＥＫＢを受領
し、複数のサブＥＫＢの合成処理を実行して複数のカテ
ゴリツリーにおいて処理可能なＥＫＢを生成する。
【０２４０】本構成においては、コンテンツプロバイダ
（ＣＰ）などのＥＫＢの発行要求者は、ＥＫＢタイプ定
義リストに基づいて特定のカテゴリツリーの選択を実行
することが可能となる。コンテンツプロバイダ（ＣＰ）
などのＥＫＢの発行要求者は、ＥＫＢタイプ定義リスト
を参照して特定カテゴリツリーにおいて処理可能なＥＫ
Ｂの発行をキー発行センター（ＫＤＣ）に依頼する。キ
ー発行センター（ＫＤＣ）は、ＥＫＢ発行要求に基づい
て、選択されたカテゴリツリーの管理エンティテイに対
してサブＥＫＢ発行要求を行ない、各選択されたカテゴ
リツリーの管理エンティテイは、管理エンティテイのリ
ボークされていない正当なデバイスにおいてのみ処理可
能なサブＥＫＢを生成してキー発行センター（ＫＤＣ）
に送信する。キー発行センター（ＫＤＣ）は、1以上の
サブＥＫＢを組み合わせてＥＫＢの発行要求者の要求し
た選択カテゴリツリーにのみ処理可能なＥＫＢを生成し
てＥＫＢ発行要求者に提供する。ＥＫＢ発行要求者は、
キー発行センター（ＫＤＣ）からＥＫＢを受領し、ＥＫ
Ｂの処理によって取得可能なキーでのみ復号可能な暗号
化キー、または暗号化コンテンツの配信を実行する。
【０２４１】まず、以下の説明における構成エンティテ
イについて簡単に説明する。 キー発行センター（ＫＤＣ：Key Distribution Cente
r） 有効化キーブロック（ＥＫＢ）を発行し、発行したＥＫ
Ｂに関するＥＫＢタイプ定義リストを管理する。
【０２４２】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ：Top Level Category Entity） あるカテゴリツリーを管理するエンティテイ。たとえば
記録デバイスのフォーマットホルダー。カテゴリツリー
を管理し、管理下のカテゴリツリー内のデバイスにおい
て処理（復号）可能なＥＫＢであるサブＥＫＢを生成
し、キー発行センター（ＫＤＣ）に提出する。
【０２４３】ＥＫＢ・リクエスタ（ＥＫＢ requester） たとえば、電子コンテンツ提供（ＥＣＤ：Electronic C
ontent Distribution）サービスを実行するコンテンツ
プロバイダ（ＣＰ）など、画像、音声、プログラムなど
様々のコンテンツをユーザデバイスに対して提供するエ
ンティテイ、あるいは記録メディアのフォーマットホル
ダーであり、提供コンテンツの暗号化キーなどにＥＫＢ
処理によって取得可能なキーを用いる設定としてコンテ
ンツ、メディアを提供する。この際に用いるＥＫＢの発
行要求をキー発行センター（ＫＤＣ）に対して要求す
る。
【０２４４】例えば、コンテンツプロバイダ（ＣＰ）
は、キー発行センター（ＫＤＣ）の生成したＥＫＢのル
ートキー（Root Key）を用いて自分のコンテンツを暗号
化して配信する。記録メディアのフォーマットホルダー
は、ＥＫＢを記録メディアの製造時に書きこんで配布
し、記録されるコンテンツがそのＥＫＢのルートキー
（Root Key）を用いて暗号化されるようにする。
【０２４５】（ＴＬＣＥとカテゴリベースのツリー管
理）カテゴリベースのツリー管理については、前述した
が、トップレベル・カテゴリ・エンティテイ（ＴＬＣ
Ｅ）とカテゴリツリーの関係について、図４６を用いて
説明する。
【０２４６】まず、カテゴリは、前述したように同じ性
質を持ったデバイスの集合であり、具体的には、同じメ
ーカー製のデバイス、あるいは同じエンコードフォーマ
ットを扱えるデバイス等である。図４６において、Ａ、
Ｂ、Ｃ、Ｄはそれぞれカテゴリツリーを示す。
【０２４７】図４６において、最上段のルートツリー
は、例えば８段構成（ノード段数）であり、ルートツリ
ーの最下段にカテゴリツリーのトップノードが設定され
る。カテゴリツリーは、複数が上位、下位の関係になる
ことが可能であり、図４６において、カテゴリツリーＣ
は、カテゴリツリーＤの上位に対応する。
【０２４８】最上段のルートツリーに直接連なるカテゴ
リツリーをトップレベルカテゴリツリーと呼び、トップ
レベルカテゴリツリーを管理するエンティテイをトップ
レベル・カテゴリ・エンティテイ（ＴＬＣＥ）と呼ぶ。
図４６では、Ａ、Ｂ、Ｃがトップレベルカテゴリであ
り、これらを管理するエンティテイがトップレベル・カ
テゴリ・エンティテイ（ＴＬＣＥ）である。トップレベ
ル・カテゴリ・エンティテイ（ＴＬＣＥ）は、基本的
に、自己のツリー以下全体を管理する責任がある。つま
り、図４６のツリーＣを管理するＴＬＣＥは、ツリーＣ
と同様ツリーＤについての管理も実行する。Ｄ以下にさ
らに下層のカテゴリツリーが存在すればその下層カテゴ
リツリー管理も行なう。ただし、例えば下層のカテゴリ
ツリーＤを管理するカテゴリエンティティ(Sub Categor
y Entity)を置いて、その責任と権利を委譲することも
可能である。
【０２４９】コンテンツの利用を行なう記録再生装置な
どの各デバイスは、トップレベル・カテゴリ・エンティ
テイ（ＴＬＣＥ）により、あるツリーのリーフにアサイ
ンされ、そのリーフからルートに至るパスの間のいくつ
かのノードの鍵を所有する。１つのデバイスが持つノー
ドキーの組をデバイス・ノード・キー（ＤＮＫ：Device
Node Key）と呼ぶ。各デバイスが、何個の鍵を持つか
（ＤＮＫに何個の鍵が含まれるか）はトップレベル・カ
テゴリ・エンティテイ（ＴＬＣＥ）が決定する。
【０２５０】図４７にキー発行センター（ＫＤＣ）、ト
ップレベル・カテゴリ・エンティテイ（ＴＬＣＥ）、Ｅ
ＫＢ・リクエスタ各エンティテイの対応、処理の概要を
説明する図を示す。
【０２５１】キー発行センター（ＫＤＣ）４５１１は、
ツリー構成を用いたＥＫＢ配信システムの管理エンティ
テイ４５１０として位置づけられる。管理エンティテイ
４５１０には、さらに、ＥＫＢに対する署名処理を実行
する認証局（ＣＡ）４５１２がある。
【０２５２】キー発行センター（ＫＤＣ）４５１１は、
トップレベルカテゴリツリーなどのサブツリーのキー管
理を行ない、後述するＥＫＢタイプ定義リストの管理、
ＥＫＢの生成を実行する。認証局（ＣＡ）４５１２は、
キー発行センター（ＫＤＣ）の生成したＥＫＢに署名を
実行するともに、署名を施した秘密鍵に対応する公開鍵
を署名検証用の鍵として発行する。
【０２５３】キー発行センター（ＫＤＣ）４５１１に対
してＥＫＢの発行要求を行なうのがＥＫＢリクエスタ４
５２０である。ＥＫＢリクエスタは、例えばコンテンツ
を格納したＣＤ、ＤＶＤなどのメディアを提供するコン
テンツ格納メディアに関するコンテンツプロバイダ（Ｃ
Ｐ）、電子コンテンツの配信を実行するコンテンツプロ
バイダ（ＣＰ）、フラッシュメモリなどのストレージシ
ステムのフオーマットについてのライセンスを提供する
ストレージシステムライセンサなどである。
【０２５４】これらのＥＫＢリクエスタ４５２０は、そ
れぞれの提供するメデイア、コンテンツ、ライセンスの
使用に際し、必要となるキーをＥＫＢ処理によって得ら
れるキーとして設定したＥＫＢをコンテンツ、メディ
ア、ライセンスフォーマットなどに対応付けて提供す
る。ＥＫＢは、ＥＫＢリクエスタ４５２０からキー発行
センター（ＫＤＣ）４５１１に対するＥＫＢ発行要求に
従ってキー発行センター（ＫＤＣ）４５１１が生成す
る。
【０２５５】ＥＫＢリクエスタ４５２０は、キー発行セ
ンター（ＫＤＣ）４５１１に対する発行要求の結果とし
て受領したＥＫＢをメディア製造者４５４０、デバイス
製造者４５５０に対して提供し、ＥＫＢを格納したメデ
ィア、またはデバイスをユーザに対して供給する処理が
可能である。これらのＥＫＢは、例えば１つまたは複数
のカテゴリツリーにおいて処理可能なＥＫＢとして生成
される。
【０２５６】本システムでは、複数、例えば２つあるい
は３以上のカテゴリツリーにおいて共通に処理可能なＥ
ＫＢや、唯一のカテゴリツリーにおいてのみ処理可能な
ＥＫＢなど、様々なタイプのＥＫＢが生成され、使用さ
れる状況になる。このような様々なタイプのＥＫＢにつ
いてリスト化したのがＥＫＢタイプ定義リストである。
ＥＫＢタイプ定義リストはキー発行センター（ＫＤＣ）
が管理する。ＥＫＢタイプ定義リストについては、後段
で詳細に説明する。ＥＫＢリクエスタ４５２０は、ＥＫ
Ｂタイプ定義リストの要求をキー発行センター（ＫＤ
Ｃ）４５１１に要求してリストを取得可能であり、ま
た、リストのデータ変更があった場合は、キー発行セン
ター（ＫＤＣ）４５１１からＥＫＢリクエスタ４５２０
に対して通知される。
【０２５７】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）４５３０は、前述したようにルートツリー
に連なるカテゴリツリーの管理エンティテイであり、サ
ブツリーのキー管理、管理デバイスＩＤと各デバイスに
格納されるＥＫＢ処理のためのノードキー・セットであ
るデバイス・ノード・キー（ＤＮＫ）との対応リストを
管理する。さらに管理下のデバイスに対応するデバイス
を製造するデバイス製造者４５５０に対して、デバイス
格納用のデバイス・ノード・キー（ＤＮＫ）の生成、提
供処理を実行する。
【０２５８】キー発行センター（ＫＤＣ）４５１１がＥ
ＫＢリクエスタ４５２０からＥＫＢ発行要求を受信する
と、キー発行センター（ＫＤＣ）４５１１は、発行要求
に従ったＥＫＢを生成する。生成するＥＫＢが例えば２
つのトップレベル・カテゴリツリーにおいて処理可能な
ＥＫＢであった場合は、その２つのトップレベル・カテ
ゴリ・エンティテイ（ＴＬＣＥ）４５３０に対してサブ
ＥＫＢの発行要求を送信し、サブＥＫＢの発行要求を受
信したトップレベル・カテゴリ・エンティテイ（ＴＬＣ
Ｅ）４５３０はそれぞれのカテゴリツリー内の正当デバ
イスがルートキー取得可能なサブＥＫＢを生成してキー
発行センター（ＫＤＣ）４５１１に送信する。キー発行
センター（ＫＤＣ）４５１１は、ＴＬＣＥから受信した
1つまたは複数のサブＥＫＢに基づいてＥＫＢを生成す
る。サブＥＫＢに基づくＥＫＢ生成処理については後段
でさらに説明する。
【０２５９】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）４５３０は、ＥＫＢリクエスタ４５２０と
同様、ＥＫＢタイプ定義リストの要求をキー発行センタ
ー（ＫＤＣ）４５１１に要求してリストを取得可能であ
る。
【０２６０】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）４５３０は、さらに、ＥＫＢタイプ定義リ
ストの自己のツリーに関して定義されたタイプの削除要
求をキー発行センター（ＫＤＣ）４５１１に要求するこ
とができる。例えば他のカテゴリツリーと共有のＥＫＢ
として定義されたＥＫＢタイプをリストから削除する要
求である。トップレベル・カテゴリ・エンティテイ（Ｔ
ＬＣＥ）４５３０は、さらに、自己の管理するツリーに
関する変更があった場合には、変更情報をキー発行セン
ター（ＫＤＣ）４５１１に通知する。これらの処理につ
いてはフローを用いて後段で説明する。
【０２６１】デバイス製造者４５５０は、２つの種類の
デバイス製造者に区分される。１つは、製造するデバイ
スにデバイスノードキー（ＤＮＫ）と、ＥＫＢの両デー
タを格納したデバイスを製造するＤＮＫＥデバイス製造
者４５５１であり、他方は、デバイスにデバイスノード
キー（ＤＮＫ）のみを格納したデバイスを製造するＤＮ
Ｋデバイス製造者４５５２である。
【０２６２】図４８に図４７に示すキー発行センター
（ＫＤＣ）、ＥＫＢリクエスタ、トップレベル・カテゴ
リ・エンティテイ（ＴＬＣＥ）それぞれの構成例をブロ
ック図として示す。キー発行センター（ＫＤＣ）はＥＫ
Ｂ発行情報処理装置、ＥＫＢリクエスタはＥＫＢ要求情
報処理装置、トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）はカテゴリツリー管理情報処理装置とし
て、基本的に暗号通信可能なデータ処理装置として構成
される。
【０２６３】各エンティテイを構成する情報処理装置
は、それぞれ他エンティテイとの相互認証、データ通信
時における暗号処理全般を司る暗号処理部を有する。暗
号処理部内の制御部は、認証処理、暗号化／復号化処理
等の暗号処理全般に関する制御を実行する制御部であ
る。内部メモリは、相互認証処理、暗号化、復号化処理
等、各種処理において必要となる鍵データ、識別データ
等を格納する。識別データは、例えば他エンティテイと
の相互認証処理等において用いられる。
【０２６４】暗号／復号化部は、内部メモリに格納され
た鍵データ等を使用したデータ転送時の認証処理、暗号
化処理、復号化処理、データの検証、乱数の発生などの
処理を実行する。
【０２６５】ただし、ＥＫＢリクエスタとしての情報処
理装置においては、鍵の生成処理を自装置内では実行し
ない構成も可能である。この場合には、鍵の生成に必要
な構成要素、例えば乱数発生装置などを省略可能とな
る。具体的には、ＥＫＢに含ませるルートキーを自ら生
成して生成したルートキーを含むＥＫＢの生成をキー発
行センターに要求するＥＫＢリクエスタとしての情報処
理装置はルートキーを生成するための手段が必要となる
が、ＥＫＢに含ませるルートキーを自ら生成せず、キー
発行センターにルートキーの生成処理を要求し、キー発
行センター（ＫＤＣ）において生成したルートキーを含
むＥＫＢ生成をキー発行センターに要求するＥＫＢリク
エスタとしての情報処理装置は乱数発生装置などの鍵生
成処理に伴う構成要素が省略可能である。
【０２６６】暗号処理部の内部メモリは、暗号鍵などの
重要な情報を保持しているため、外部から不正に読み出
しにくい構造にしておく必要がある。従って、暗号処理
部は、外部からアクセスしにくい構造を持った例えば半
導体チップで構成された耐タンパメモリとして構成され
る。
【０２６７】各エンティテイは、これらの暗号処理機能
の他に、中央演算処理装置（ＣＰＵ：Central Processi
ng Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ
(ReadOnly Memory)、入力部、表示部、データベースＩ
／Ｆ、データベースを備えている。
【０２６８】中央演算処理装置（ＣＰＵ：Central Proc
essing Unit）、ＲＡＭ（Random Access Memory）、Ｒ
ＯＭ(Read Only Memory)は、各エンティテイ本体の制御
系として機能する構成部である。ＲＡＭは、ＣＰＵにお
ける各種処理用の主記憶メモリとして使用され、ＣＰＵ
による処理のための作業領域として使用される。ＲＯＭ
は、ＣＰＵでの起動プログラム等が格納される。
【０２６９】各エンティテイを構成する情報処理装置の
データベースまたはその他の記憶手段には、それぞれ各
エンティテイの管理するデータ、例えばキー発行センタ
ー（ＫＤＣ）であれば、発行したＥＫＢに関する管理デ
ータ、さらにＥＫＢタイプ定義リストなどが格納され、
また、トップレベル・カテゴリ・エンティテイ（ＴＬＣ
Ｅ）のデータベースには、管理デバイスとデバイスノー
ドキー（ＤＮＫ）の対応など、カテゴリツリーに属する
デバイスの管理データが格納され、ＥＫＢリクエスタの
データベースには、提供コンテンツとコンテンツに対し
て使用されているＥＫＢとの関係を対応付けた管理デー
タ、コンテンツの提供先デバイスについての管理データ
などが格納される。なお、ＥＫＢタイプ定義リストは、
ＥＫＢリクエスタ、トップレベル・カテゴリ・エンティ
テイ（ＴＬＣＥ）を構成する情報処理装置中にも格納し
参照可能な状態とする構成が好ましい。あるいは、ＥＫ
Ｂリクエスタ、トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）のアクセス可能なキー発行センター（ＫＤ
Ｃ）の管理するウェブ（Web）サイトに置く構成として
もよい。
【０２７０】前述したように、デバイスは、ＥＫＢ処理
（復号）のためにデバイス・ノード・キー（ＤＮＫ：De
vice Node Key）を使用する。１つのデバイスが持つデ
バイス・ノード・キー（ＤＮＫ）について図４９を用い
て説明する。図４９に示すツリーは１つのカテゴリツリ
ーを示し、最下段がデバイスが対応付けられたリーフで
あり、例えばトップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）の管理ツリーに相当する。さらに上段には
ルートツリー（ｅｘ．8段構成）が連なっている。ここ
でデバイスは、図４９に示すようにデバイスから上段に
至るパス上のノードキーを有する。これらのキーセット
をデバイス・ノード・キー（ＤＮＫ）として保有し、デ
バイス・ノード・キー（ＤＮＫ）を用いてＥＫＢの復号
を行なう。
【０２７１】基本的に、１つのデバイスが１つのリーフ
に重ならないようにアサインされる。例外として、たと
えばＰＣソフトなどのソフトウェアをリーフに対応付け
る場合は、１つのバージョンのソフトウェア・パッケー
ジがすべて１つのリーフにアサインされる場合もある。
これもＴＬＣＥが決める。つまり、デバイスをどのよう
にリーフにアサインし、どのノードキーを持たせるかは
ＴＬＣＥが決める。
【０２７２】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）は、デバイス自体の提供業者（メーカー）
である場合もあり、製造デバイスに対して予めデバイス
・ノード・キー（ＤＮＫ）を格納してユーザに提供（販
売）することが可能である。すなわち、記録再生装置な
どのデバイスに対して予め、ある特定のカテゴリツリー
のノードキーのセットをデバイス・ノード・キー（ＤＮ
Ｋ）としてメモリに格納してユーザに提供（販売）する
ことが可能である。
【０２７３】（ＥＫＢタイプ定義リスト）カテゴリ単位
でのＥＫＢ配信については、すでに説明した通りである
が、複数のカテゴリに共通のＥＫＢ、すなわち異なるカ
テゴリツリーに属するデバイスにおいて処理可能なＥＫ
Ｂを生成して発行した場合には、いくつかの問題点が発
生する場合がある。
【０２７４】例えば、ある再書き込み可能なメディア
（記録媒体）例えば、携帯型フラッシュメモリのフォー
マットのライセンシー（ライセンス受領者）として、Ａ
社とＢ社の異なる２社が存在し、メディア（携帯型フラ
ッシュメモリ）のライセンサー（ライセンス許諾者）で
あるメーカーがトップレベルカテゴリとして存在し、そ
の下にＡ社の管理するカテゴリツリーとＢ社の管理する
カテゴリツリーがある構成において、Ａ社とＢ社は相互
のデバイスに互換性を持たせ、様々な配布コンテンツを
共通に利用することを可能とするため、Ａ社のカテゴリ
ツリーとＢ社のカテゴリツリーの２つのカテゴリツリー
の所属デバイスにおいて処理（復号）可能なＥＫＢをキ
ー発行センター（ＫＤＣ）において生成し発行する。
【０２７５】このような状況でＡ社の管理するカテゴリ
ツリーに属する１つのデバイスのデバイス・ノード・キ
ー（ＤＮＫ）が漏洩してしまうと、そのデバイスノード
キー（ＤＮＫ）を利用してＡ社、Ｂ社の相互のデバイス
において利用可能とした配布コンテンツがすべて不正に
利用されてしまう可能性が発生することになる。利用を
排除するためには、リボーク処理としてのＥＫＢ更新処
理が必要となるが、この場合、Ａ社のカテゴリツリーに
関するリボーク処理ではなく、Ａ社およびＢ社の２つの
カテゴリツリーに共通のＥＫＢが存在するため、ＥＫＢ
更新処理はＡ社およびＢ社の２つのカテゴリツリーに関
して実行することが必要となる。
【０２７６】このように、複数のカテゴリツリーに共通
のＥＫＢを生成して提供した場合、１つのカテゴリツリ
ー内でのリボーク処理、ＥＫＢ更新処理のみではなく、
共通するＥＫＢを使用するすべての他のカテゴリツリー
においてリボークに伴うＥＫＢ更新処理を実行すること
が必要となる。これはＢ社にとっては、自己の管理する
デバイスと異なる他の管理カテゴリツリーの影響を受け
ることになり、処理負荷が高まることになってしまう。
【０２７７】このような状況を解決するため、複数のカ
テゴリにおいて共通に使用可能なＥＫＢの発行の許可権
限を、それぞれのカテゴリを管理するカテゴリ・エンテ
ィテイが有する構成とする。つまり、互換性をとるため
に、相手のカテゴリに属するデバイスの不具合によって
引き起こされる自分のカテゴリ内デバイスへのリスクを
許容できる場合にのみ、互換性をとるＥＫＢの発行を認
め、リスクが許容できない場合は、共通に使用可能なＥ
ＫＢの発行、または使用を認めないものとする。
【０２７８】このような処理を行なおうとすると、複
数、例えば２つあるいは３以上のカテゴリツリーにおい
て共通に処理可能なＥＫＢや、唯一のカテゴリツリーに
おいてのみ処理可能なＥＫＢなど、様々なタイプのＥＫ
Ｂが生成され、使用される状況になる。このような様々
なタイプのＥＫＢについてリスト化したのがＥＫＢタイ
プ定義リストである。図５０にＥＫＢタイプ定義リスト
の例を示す。ＥＫＢタイプ定義リストはキー発行センタ
ー（ＫＤＣ）が記録媒体に記録して管理する。また、Ｅ
ＫＢリクエスタ、ＴＬＣＥに対しても必要に応じて提供
または閲覧可能な状態におかれる。
【０２７９】図５０に示すように、ＥＫＢタイプ定義リ
ストは、「ＥＫＢタイプ識別ナンバー」、「ノード」、
「説明」の各フィールドを有し、「ＥＫＢタイプ識別ナ
ンバー」は、ＥＫＢタイプ定義リストにリストアップさ
れた様々な態様のＥＫＢを識別するナンバーであり、識
別ナンバーが異なれば、そのＥＫＢを処理可能なカテゴ
リツリーまたはその組み合わせが異なる構成となってい
る。
【０２８０】「ノード」フィールドは、ＥＫＢを適用可
能なカテゴリツリーのトップノードＩＤを記録するフィ
ールドである。例えばＥＫＢタイプ識別ナンバー：１の
ＥＫＢは、ＭＳ（MemoryStick：メモリスティック）の
カテゴリツリーのトップノードＩＤが記録される。ま
た、ＥＫＢタイプ識別ナンバー：３のＥＫＢは、ＭＳ
（MemoryStick：メモリスティック）のカテゴリツリー
のトップノードＩＤとＰＨＳのカテゴリツリーのトップ
ノードＩＤが記録される。
【０２８１】「説明」フィールドは、ＥＫＢタイプ定義
リストにリストアップされた様々な態様のＥＫＢの説明
を記録するフィールドであり、例えばＥＫＢタイプ識別
ナンバー：１のＥＫＢは、ＭＳ（MemoryStick：メモリ
スティック）用のＥＫＢであることを示している。ま
た、ＥＫＢタイプ識別ナンバー：３のＥＫＢは、ＭＳ
（MemoryStick：メモリスティック）とＰＨＳのカテゴ
リツリーのデバイスに共通に使用可能なＥＫＢであるこ
とを示している。
【０２８２】図５０に示すＥＫＢタイプ定義リストはキ
ー発行センター（ＫＤＣ）が管理する。また、ＥＫＢの
処理により取得可能なキーによって暗号化した暗号化キ
ーまたは暗号化コンテンツ等の暗号化データ配信を行な
おうとするエンティテイ、例えばコンテンツプロバイダ
は、図５０に示すＥＫＢタイプ定義リストを参照して、
コンテンツの提供対象となるデバイスを含むカテゴリツ
リーによって処理可能なＥＫＢタイプを選択し、そのＥ
ＫＢタイプ識別ナンバーを指定して、キー発行センター
（ＫＤＣ）にＥＫＢ生成処理を依頼する。
【０２８３】ただし、ＥＫＢタイプ定義リストに対する
様々なタイプのＥＫＢ登録処理においては、登録対象と
なるカテゴリツリーのトップレベル・カテゴリ・エンテ
ィテイ（ＴＬＣＥ）の承認が必要となる。例えばカテゴ
リツリーＡのＴＬＣＥ−Ａが他のカテゴリと共有するＥ
ＫＢの発行を拒否すれば、カテゴリツリーＡと他のカテ
ゴリツリーの共有となるＥＫＢのタイプはＥＫＢタイプ
定義リストに登録されない。
【０２８４】例えばカテゴリツリーＡのＴＬＣＥ−Ａ、
カテゴリツリーＢのＴＬＣＥ−Ｂ、カテゴリツリーＣの
ＴＬＣＥ−Ｃの各々が共有のＥＫＢの発行を承認すれ
ば、これら３つのカテゴリツリーにおいて処理可能な共
通のＥＫＢのタイプがＥＫＢタイプ定義リストに登録さ
れ、例えばコンテンツプロバイダがその登録タイプを示
すＥＫＢタイプ識別ナンバーを指定してキー発行センタ
ー（ＫＤＣ）にＥＫＢ生成処理を依頼することが可能と
なる。
【０２８５】つまり、ＥＫＢタイプ定義リストに新たな
ＥＫＢタイプを登録し、そのＥＫＢタイプに対応するＥ
ＫＢタイプ識別ナンバーを定義するためには、下記の処
理が必要となる。 （１）定義しようとするＥＫＢタイプ識別ナンバーに対
応するＥＫＢの適用対象となるカテゴリを管理するすべ
てのＴＬＣＥがＥＫＢタイプ登録リクエストをキー発行
センター（ＫＤＣ）に送る。 （２）キー発行センター（ＫＤＣ）は要求にある登録対
象となるＥＫＢを処理可能な１以上のカテゴリツリーの
トップレベル・カテゴリ・エンティテイ（ＴＬＣＥ）の
すべてが上記のＥＫＢタイプ登録リクエストを送ってき
たことを確認した後に、新たなＥＫＢタイプ識別ナンバ
ーを定義し、ＥＫＢタイプ定義リストに加える。 （３）キー発行センター（ＫＤＣ）はＥＫＢタイプ定義
リストに変更があったことを知らせるため、ＥＫＢタイ
プ定義リスト変更通知を全ＴＬＣＥおよびＥＫＢリクエ
スタに送る。
【０２８６】なお、ＥＫＢタイプ定義リストは、全ＴＬ
ＣＥおよびＥＫＢリクエスタに送られ、またウェブ（We
b）サイトに置かれるなどして全ＴＬＣＥおよびＥＫＢ
リクエスタに公開される。従って、ＴＬＣＥおよびＥＫ
Ｂリクエスタは、常に最新のＥＫＢタイプ定義リストに
登録されたＥＫＢタイプ情報を取得することが可能とな
る。
【０２８７】（ＥＫＢタイプ登録処理）ＥＫＢタイプ定
義リストに新たなＥＫＢタイプを登録する際に、キー発
行センター（ＫＤＣ）の実行する処理を説明する処理フ
ローを図５１に示す。まず、キー発行センター（ＫＤ
Ｃ）は、新たなＥＫＢタイプの登録要求を行なうＴＬＣ
ＥからのＥＫＢタイプ登録リクエストを受信（Ｓ１０
１）する。ＴＬＣＥからのＥＫＢタイプ登録リクエスト
には、登録要求ＥＫＢが共通に使用可能とするカテゴリ
数が含まれる。キー発行センター（ＫＤＣ）は、要求内
のカテゴリ数に一致する数のカテゴリに対応するＴＬＣ
Ｅから同様のＥＫＢタイプ登録リクエストを受領したか
否かを判定（Ｓ１０２）し、要求内のカテゴリ数に一致
する数のカテゴリに対応するＴＬＣＥからの要求を受理
したことを条件として、ＥＫＢタイプ定義リストに対し
て要求に従った新たなＥＫＢタイプを登録し、リストの
更新処理、リストの更新通知処理（Ｓ１０３）を行な
う。更新通知処理は、ＴＬＣＥおよびＥＫＢリクエスタ
に対して行われる。
【０２８８】このように、キー発行センター（ＫＤＣ）
は、ＥＫＢタイプ定義リストに対するＥＫＢタイプ識別
子の新規登録処理において、登録予定のＥＫＢタイプの
処理可能なカテゴリツリーとして選択された１以上のカ
テゴリツリーを管理するすべてのカテゴリ・エンティテ
イの承認を条件として登録を行なう。
【０２８９】なお、これらの処理において、キー発行セ
ンター（ＫＤＣ）とＴＬＣＥ、ＥＫＢリクエスタ間の通
信においては必要に応じて相互認証処理、送信データの
暗号化処理が行われる。また、その他のメッセージ暗号
化処理、デジタル署名生成、検証処理を行なう構成とし
てもよい。なお、公開鍵暗号方式に基づく認証あるいは
暗号通信を実行する場合は、各エンティテイ間において
予め公開鍵を保有し合う手続きを行なっておく。
【０２９０】（ＥＫＢタイプ無効化処理）たとえば、あ
るカテゴリに属するすべての機器をリボークしなければ
ならないときには、トップレベル・カテゴリ・エンティ
テイ（ＴＬＣＥ）はそのカテゴリが要素となっているＥ
ＫＢタイプを無効化する要求をキー配信センター（ＫＤ
Ｃ）に出す必要がある。また、トップレベル・カテゴリ
・エンティテイ（ＴＬＣＥ）は、たとえばあるサービス
を停止するなどの理由で、現在登録されているＥＫＢタ
イプを無効化する要求をＫＤＣに出すことができる。
【０２９１】このＥＫＢタイプ無効化処理の流れを図５
２の処理フローに従って説明する。キー発行センター
（ＫＤＣ）は、ＥＫＢタイプの無効化要求を行なうＴＬ
ＣＥからのＥＫＢタイプ無効化リクエストを受信（Ｓ２
０１）する。ＴＬＣＥからのＥＫＢタイプ無効化リクエ
ストを受信すると、キー発行センター（ＫＤＣ）は、そ
のリクエストにより無効化されるＥＫＢタイプの要素と
なっているカテゴリを管理するＴＬＣＥがそのリクエス
トの発信者であることを確認した上で、ＥＫＢタイプ定
義リスト内の無効化リクエストにおいて指定されたタイ
プに対応するＥＫＢタイプ識別ナンバーを無効化してＥ
ＫＢタイプ定義リストを更新し、リストの更新通知処理
（Ｓ２０２）を行なう。更新通知処理は、ＴＬＣＥおよ
びＥＫＢリクエスタに対して行われる。
【０２９２】このように、キー発行センター（ＫＤＣ）
は、ＥＫＢタイプ定義リストに登録されたＥＫＢタイプ
識別子の無効化処理において、無効化予定のＥＫＢタイ
プの処理可能なカテゴリツリーとして選択された１以上
のカテゴリツリーを管理する少なくとも１つのカテゴリ
・エンティテイの無効化要求を条件として無効化処理を
行なう。この場合、他のカテゴリ・エンティテイの承認
は必要としない。
【０２９３】なお、これらの処理において、キー発行セ
ンター（ＫＤＣ）とＴＬＣＥ、ＥＫＢリクエスタ間の通
信においては必要に応じて相互認証処理、送信データの
暗号化処理が行われる。また、その他のメッセージ暗号
化処理、デジタル署名生成、検証処理を行なう構成とし
てもよい。なお、公開鍵暗号方式に基づく認証あるいは
暗号通信を実行する場合は、各エンティテイ間において
予め公開鍵を保有し合う手続きを行なっておく。
【０２９４】（ＥＫＢタイプ定義リスト変更通知処理）
たとえばあるカテゴリツリー内において、デバイスリボ
ケーション（デバイス排除）や、あるデバイスが格納し
たＤＮＫを新しいものに交換するデバイスノードキー
（ＤＮＫ）の更新などのツリー内の状態を変化させる処
理をそのカテゴリツリーを管理するＴＬＣＥが行った場
合、それらのデバイスを対象とするＥＫＢを使用してい
るＥＫＢリクエスタまたは関連ＴＬＣＥに対して、これ
らの処理が起こったことを知らせる必要がある。
【０２９５】なぜならば、デバイスリボケーションが起
こったのにそれを知らせず、コンテンツプロバイダ（Ｃ
Ｐ）が古いＥＫＢを使いつづけてコンテンツを暗号化し
て配信したとすると、古いＥＫＢでは、リボークされた
デバイスにおいてもＥＫＢ処理（復号）が可能であり、
コンテンツの不正利用が続けられる可能性があるからで
ある。また、デバイスノードキー（ＤＮＫ）の更新を行
なった場合、通常は置きかえられた古いＤＮＫは捨てら
れ、デバイスは新しいＤＮＫを持つことになるが、この
新しいＤＮＫに対応したＥＫＢをコンテンツプロバイダ
が使用しなければ、新しいＤＮＫを持つデバイスはＥＫ
Ｂを処理（復号）することができなくなり、コンテンツ
にアクセスできなくなってしまうからである。
【０２９６】このような弊害を避けるため、 *デバイスリボケーションなどの結果として、ＥＫＢの
タグパートに変更が生じた場合、 *デバイスノードキー（ＤＮＫ）の更新などの結果とし
て少なくともひとつの機器が持つＤＮＫの値に変更が生
じた場合、 これらの場合には、ＴＬＣＥは、ツリー変更通知（Tree
Change Notification）をキー発行センター（ＫＤＣ）
に送る必要がある。ツリー変更通知（Tree Change Noti
fication）には、変更を要するＥＫＢタイプ定義リスト
に登録済みのＥＫＢタイプ識別ナンバー、ＥＫＢタイプ
識別ナンバーに対応して登録されているどのカテゴリで
起こったかを示す情報と、リボケーション、ＤＮＫ更新
の何が起こったかという情報が含まれる。
【０２９７】ＥＫＢタイプ定義リスト変更通知処理の流
れを図５３の処理フローに従って説明する。キー発行セ
ンター（ＫＤＣ）は、ＴＬＣＥからツリー変更通知を受
信（Ｓ３０１）する。ＴＬＣＥからのツリー変更通知を
受信すると、キー発行センター（ＫＤＣ）は、ＥＫＢタ
イプ定義リストから、そのカテゴリを要素に持つＥＫＢ
タイプ識別ナンバーを抽出し、どのＥＫＢタイプ識別ナ
ンバーに、どのような変化（ｅｘ．リボケーションか、
ＤＮＫ更新（リプレイスメント）か）が起こったかの情
報を持つＥＫＢタイプ定義リスト変更通知をすべてのＴ
ＬＣＥおよびＥＫＢリクエスタに対して行なう。なお、
これらの処理において、キー発行センター（ＫＤＣ）と
ＴＬＣＥ、ＥＫＢリクエスタ間の通信においては必要に
応じて相互認証処理、送信データの暗号化処理が行われ
る。また、その他のメッセージ暗号化処理、デジタル署
名生成、検証処理を行なう構成としてもよい。なお、公
開鍵暗号方式に基づく認証あるいは暗号通信を実行する
場合は、各エンティテイ間において予め公開鍵を保有し
合う手続きを行なっておく。
【０２９８】（ＥＫＢタイプ定義リスト要求）トップレ
ベル・カテゴリ・エンティテイ（ＴＬＣＥ）やＴＬＣＥ
以外のサブカテゴリ・エンティテイ（ＳＣＥ）、あるい
はコンテンツプロバイダ等のＥＫＢリクエスタは、最新
版のＥＫＢタイプ定義リストを知るために、ＥＫＢタイ
プ定義リストの送付をキー発行センター（ＫＤＣ）に要
求することができる。キー発行センター（ＫＤＣ）はこ
の要求に対して、最新版のＥＫＢタイプ定義リストを要
求者に送り返す。
【０２９９】ＥＫＢタイプ定義リスト要求処理の流れを
図５４の処理フローに従って説明する。キー発行センタ
ー（ＫＤＣ）は、ＴＬＣＥ、サブカテゴリ・エンティテ
イ、またはＥＫＢリクエスタのいずれかからＥＫＢタイ
プ定義リスト要求を受信（Ｓ４０１）する。ＥＫＢタイ
プ定義リスト要求を受信すると、キー発行センター（Ｋ
ＤＣ）は、最新のＥＫＢタイプ定義リストを抽出し、要
求処理を行なったエンティテイに対して最新のＥＫＢタ
イプ定義リストを送信（Ｓ４０２）する。なお、これら
の処理において、キー発行センター（ＫＤＣ）とＴＬＣ
Ｅ、サブカテゴリ・エンティテイ、ＥＫＢリクエスタ間
の通信においては必要に応じて相互認証処理、送信デー
タの暗号化処理が行われる。また、その他のメッセージ
暗号化処理、デジタル署名生成、検証処理を行なう構成
としてもよい。なお、公開鍵暗号方式に基づく認証ある
いは暗号通信を実行する場合は、各エンティテイ間にお
いて予め公開鍵を保有し合う手続きを行なっておく。
【０３００】（ＥＫＢ発行処理）ＥＫＢの発行処理は、
ＥＫＢリクエスタによるＥＫＢ発行要求に基づいて行わ
れる。ＥＫＢリクエスタは、 ［ａ］ＣＤ、ＤＶＤなどの、コンテンツ格納メディアを
提供するコンテンツプロバイダ（ＣＰ）。 ［ｂ］電子情報配信（ＥＣＤ：Electronic Content Dis
tribution）サービスを提供するコンテンツプロバイ
ダ。 ［ｃ］記録システムのフォーマットホルダー。 など、ＥＫＢの復号によって取得されるキーを用いてコ
ンテンツの利用、フォーマットの使用を可能とするサー
ビス、メディア、デバイスを提供するエンティテイであ
る。
【０３０１】上記の［ｃ］記録システムのフォーマット
ホルダーには、 ［ｃ１]たとえば製造時に記録媒体にＥＫＢを格納する
ようなフォーマットにおいて、記録媒体の製造業社に取
得したＥＫＢを与えるフォーマットホルダー。 ［ｃ２］たとえば製造時に記録デバイスにＥＫＢを格納
するようなフォーマットにおいて、記録デバイスの製造
業社に取得したＥＫＢを与えるフォーマットホルダー。 の２種類のフォーマットホルダーがある。
【０３０２】ＥＫＢ発行処理の手順について、以下説明
する。
【０３０３】（１）コンテンツキーの作成 まず、コンテンツプロバイダなどのＥＫＢリクエスタ
は、自己の提供するコンテンツ、デバイス、メディアに
対応して使用されるコンテンツキーを生成する。例えば
ＥＫＢリクエスタが、 ［ａ］ＣＤ、ＤＶＤなどの、コンテンツ格納メディアを
提供するコンテンツプロバイダ（ＣＰ）。 ［ｂ］電子情報配信（ＥＣＤ：Electronic Content Dis
tribution）サービスを提供するコンテンツプロバイ
ダ。 である場合、生成するコンテンツキーは、メディア上や
電子情報配信（ＥＣＤ）サービスにおいて、コンテンツ
を守る（暗号化する）鍵として使用される。
【０３０４】また、ＥＫＢリクエスタが、［ｃ１]製造
時に記録媒体にＥＫＢを格納するようなフォーマットに
おいて、記録媒体の製造業社に取得したＥＫＢを与える
フォーマットホルダー。である場合、コンテンツキー
は、その記録媒体上に記録されるコンテンツを守る（暗
号化する）鍵として使用される。さらに、ＥＫＢリクエ
スタが、［ｃ２］製造時に記録デバイスにＥＫＢを格納
するようなフォーマットにおいて、記録デバイスの製造
業社に取得したＥＫＢを与えるフォーマットホルダー。
である場合、コンテンツキーは、その記録デバイスを用
いて記録されるコンテンツを守る（暗号化する）鍵とし
て使用される。
【０３０５】なお、コンテンツキーを用いてコンテンツ
を保護するための暗号アルゴリズムなどのメカニズム
は、各フォーマットごとに任意に決めることができる。
【０３０６】（２）ルートキーの生成 ＥＫＢリクエスタはＥＫＢの復号処理によって取得可能
としたルートキーを生成する。なお、ＥＫＢリクエスタ
は自らはルートキーを生成せず、キー発行センター（Ｋ
ＤＣ）に生成を依頼してもよい。ルートキーはコンテン
ツキーを保護する（暗号化する）ために使用される。な
おルートキーを用いてコンテンツキーを保護するための
暗号アルゴリズムなどのメカニズムは、各フォーマット
ごとに任意に決めることができる。
【０３０７】（３）ＥＫＢ発行要求 ＥＫＢリクエスタはＥＫＢの発行要求をキー発行センタ
ー（ＫＤＣ）に送る。このリクエストには上記のルート
キーおよび、ＥＫＢによりルートキーをどのカテゴリの
機器に送るかという、ＥＫＢタイプ定義リストに登録さ
れているＥＫＢタイプ識別ナンバーのひとつが含まれ
る。ＥＫＢリクエスタは、自装置の記憶手段に格納した
ＥＫＢタイプ定義リスト、あるいはネットワーク上の閲
覧可能サイトから取得したＥＫＢタイプ定義リストに基
づいてコンテンツ提供などのサービスを提供する対象と
なるデバイスを含むカテゴリからなるＥＫＢタイプを選
択して、選択したＥＫＢタイプを示すＥＫＢタイプ識別
ナンバーをＥＫＢ発行要求中に含ませてキー発行センタ
ー（ＫＤＣ）に送信する。
【０３０８】（４）ＥＫＢ発行処理 キー発行センター（ＫＤＣ）はＥＫＢリクエスタからの
ＥＫＢ発行要求に基づき、ＥＫＢ発行要求中にルートキ
ーが含まれてい場合は、そのルートキーを含むＥＫＢの
生成を行ない、ＥＫＢ発行要求中にルートキーが含まれ
ず、ルートキー生成処理依頼がなされた場合は、ＫＤＣ
がルートキーを生成し、生成ルートキーを含むＥＫＢを
生成してＥＫＢリクエスタに送信する。
【０３０９】キー発行センターの生成するＥＫＢは、単
一のカテゴリツリーにおいて処理可能なＥＫＢである場
合と、複数のカテゴリツリーにおいて共通に処理可能な
ＥＫＢである場合がある。キー発行センター（ＫＤＣ）
はＥＫＢ発行要求に含まれるＥＫＢタイプ識別ナンバー
に基づいて、そのＥＫＢタイプ識別ナンバーの構成要素
となっているカテゴリ、すなわちＥＫＢタイプ定義リス
トにおいて、指定されたＥＫＢタイプ識別ナンバーのノ
ードフィールドに記録されたノードを抽出する。ノード
フィールドにはカテゴリツリーのトップノードＩＤが記
録されている。これは、そのカテゴリツリーの管理エン
ティテイに対応するノードＩＤである。このノードＩＤ
に基づいて、カテゴリツリーの管理エンティテイである
トップレベル・カテゴリ・エンティテイ（ＴＬＣＥ）に
対し、サブＥＫＢの発行要求を出す。サブＥＫＢの発行
要求にはルートキーと、各カテゴリを表す情報が含まれ
る。
【０３１０】キー発行センター（ＫＤＣ）からサブＥＫ
Ｂ発行要求を受け取ったＴＬＣＥは、指定された１つ以
上のカテゴリ内の（リボークされていない）各機器か
ら、最終的にルートキーを得られる構成を持つサブＥＫ
Ｂを生成してキー発行センター（ＫＤＣ）に送信する。
【０３１１】トップレベル・カテゴリ・エンティテイ
（ＴＬＣＥ）の生成するサブＥＫＢは、バージョン番号
やその検証用の情報（Version Check Value）を持たな
いほかは、通常のＥＫＢ（図６参照）と同様の構造を持
つ情報の組である。ここで、サブＥＫＢにおけるリーフ
キーやノードキーを用いて上位のノードキーやルートキ
ーを暗号化するアルゴリズムや鍵長、モードは、サブＥ
ＫＢを生成する各ＴＬＣＥ（フォーマットホルダー）ご
とに任意に決めることができる。これにより、他のフォ
ーマットとは別個に独自のセキュリティ方式を用いるこ
とができる。また、デフォルトとしてたとえば 暗号ア
ルゴリズムを FIPS46-2 のトリプルＤＥＳ（Triple-DE
S）と決めておき、これに異存のないＴＬＣＥはトリプ
ルＤＥＳアルゴリズムを適用する構成としてもよい。Ｔ
ＬＣＥが任意に暗号アルゴリズムや鍵長を決める場合で
も、別のＴＬＣＥが作ったサブＥＫＢと合成されたＥＫ
Ｂを、他のＴＬＣＥの支配下にある機器でも処理できる
ように、ひとつひとつの（暗号化された）鍵は、所定
長、たとえば１６バイト（16Byte）のデータで表すと決
める。このように複数のカテゴリツリーで共通のＥＫＢ
を生成する場合に所定のルールに従って、データを設定
することにより、異なるカテゴリツリーの各機器は、Ｅ
ＫＢのタグを辿って、自分が何番目の鍵データが必要か
判断可能となる。すなわちＥＫＢ内に含まれる鍵データ
の各々が１６バイトであれば、自デバイスで処理可能な
鍵データを順次抽出して処理することが可能となり、最
終的にルートキーを取得することが可能となる。
【０３１２】すなわち、サブＥＫＢに基づいて生成され
る合成ＥＫＢは、複数のキー・データの各々が固定長の
データフィールド内に格納された構成を有する。従っ
て、各々独自のアルゴリズム、独自のキー・データ長を
持つサブ有効化キーブロック（サブＥＫＢ）に基づいて
生成される合成ＥＫＢは、サブＥＫＢ内の複数の暗号化
キーデータを、キーツリーにおけるノードまたはリーフ
位置に応じて再配列して生成されても、ＥＫＢのタグを
辿って必要なキー・データを順次取得可能となる。この
ような合成ＥＫＢは、ネットワークを介してあるいは様
々な記録媒体に格納して、ユーザ（デバイス）に対して
配信または提供される。
【０３１３】キー発行センター（ＫＤＣ）は、ＴＬＣＥ
から送られてきたサブＥＫＢを、必要に応じて組替え、
合成し、バージョン番号と、その検証用の情報を付加し
て合成した合成ＥＫＢを完成させてＥＫＢリクエスタに
送信する。ただし公開鍵暗号技術を用いたデジタル署名
は、キー発行センター（ＫＤＣ）とは別の認証局（Ｃ
Ａ：Certificate Authority）に依頼する場合もある。
【０３１４】サブＥＫＢの生成、サブＥＫＢから合成Ｅ
ＫＢの生成について、図を参照して説明する。図５５
は、カテゴリツリーＡ，５１００とカテゴリツリーＢ，
５２００に共通の合成ＥＫＢを生成する処理において、
カテゴリツリーＡ，５１００のＴＬＣＥの生成するサブ
ＥＫＢ−（Ａ）の構成を説明する図である。サブＥＫＢ
−（Ａ）は、カテゴリツリーＡ，５１００の各デバイス
がルートキーを取得可能なＥＫＢとして生成される。な
お、図においてルートツリー領域５３００は上述の説明
では８段構成として説明してきたが、ここでは説明を簡
略化するため２段構成としてある。
【０３１５】図５５において、ツリー構成内に記載され
たアンダーラインを付加した３桁の数値［ＸＸＸ］はＥ
ＫＢ内のタグ（ｅ，ｌ，ｒ）を示し、前述（図２６，図
２７参照）したように、ｅ＝１はデータあり、ｅ＝０は
データなしを示し、ｌ＝１は左に枝なし、ｌ＝０は左に
枝ありを示し、ｒ＝１は右に枝なし、ｒ＝０は右に枝あ
りを示している。
【０３１６】図５５のカテゴリツリーＡ，５１００の各
デバイス（リーフ）がルートキーを取得するためには、
各リーフが共通に格納しているノードキーによってルー
トキーを暗号化したデータを格納したＥＫＢを生成すれ
ばよい。各デバイスは、図５５のカテゴリツリーＡ，５
１００のデバイスノードキー（ＤＮＫ）領域５１２０の
ツリーの各パスのノードキーを保有しているので、ＤＮ
Ｋ領域５１２０の最上段のノードキーでルートキーを暗
号化したＥＫＢを生成すればよい。
【０３１７】従って、カテゴリツリーＡ，５１００のＴ
ＬＣＥの生成するサブＥＫＢ−（Ａ）は、タグパート：
１０１，０１０，０００，１１１，１１１、キーパー
ト：Ｅｎｃ（Ｋ０１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ０１
１，Ｋｒｏｏｔ）となるサブＥＫＢ−（Ａ）となる。カ
テゴリツリーＡ，５１００のＴＬＣＥは、このサブＥＫ
Ｂ−（Ａ）をキー発行センター（ＫＤＣ）に送信する。
【０３１８】次に、カテゴリツリーＢ，５２００の生成
するサブＥＫＢ−（Ｂ）について図５６を用いて説明す
る。カテゴリツリーＢ，５２００の各デバイス（リー
フ）がルートキーを取得するためには、各リーフが共通
に格納しているノードキーによってルートキーを暗号化
したデータを格納したＥＫＢを生成すればよい。各デバ
イスは、図５６のカテゴリツリーＢ５２００のデバイス
ノードキー（ＤＮＫ）領域５２２０のツリーの各パスの
ノードキーを保有しているので、ＤＮＫ領域５２２０の
最上段のノードキーでルートキーを暗号化したＥＫＢを
生成すればよい。
【０３１９】従って、カテゴリツリーＢ，５２００のＴ
ＬＣＥの生成するサブＥＫＢ−（Ｂ）は、タグパート：
１１０，０１０，０００，１１１，１１１、キーパー
ト：Ｅｎｃ（Ｋ１１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１１
１，Ｋｒｏｏｔ）となるサブＥＫＢ−（Ｂ）となる。カ
テゴリツリーＢ，５２００のＴＬＣＥは、このサブＥＫ
Ｂ−（Ｂ）をキー発行センター（ＫＤＣ）に送信する。
【０３２０】キー発行センターは、各ＴＬＣＥの生成し
たサブＥＫＢ−（Ａ）とサブＥＫＢ−（Ｂ）とから合成
ＥＫＢを生成する。合成ＥＫＢの生成について図５７を
用いて説明する。合成ＥＫＢは、カテゴリツリーＡ，５
１００、およびカテゴリツリーＢ，５２００の各ツリー
に属するデバイスがルートキーを取得可能としたＥＫＢ
として構成される。基本的には、受領した複数のサブＥ
ＫＢの鍵データ配列を混合してツリー上段から揃える作
業によって合成ＥＫＢが生成される。なお、同一段では
左側を先とするデータ配列を行なう。
【０３２１】この結果、合成ＥＫＢは、タグパート：１
００，０１０，０１０，０００，０００，１１１，１１
１，１１１，１１１、キーパート：Ｅｎｃ（Ｋ０１０，
Ｋｒｏｏｔ），Ｅｎｃ（Ｋ０１１，Ｋｒｏｏｔ），Ｅｎ
ｃ（Ｋ１１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１１１，Ｋｒ
ｏｏｔ）を持つＥＫＢとして生成される。各キーパート
の鍵データは前述したように各々例えば１６バイトとし
て設定することにより、各カテゴリツリー内のデバイス
は自デバイスで処理可能な鍵データ位置を検出可能であ
るので、合成ＥＫＢからルートキーを取得することが可
能となる。
【０３２２】以上は、いずれのカテゴリツリーにもリボ
ークされたデバイスがない場合のサブＥＫＢの生成およ
び合成ＥＫＢの生成処理構成であるが、次に、リボーク
デバイスがある場合のサブＥＫＢの生成および合成ＥＫ
Ｂの生成について説明する。
【０３２３】図５８は、カテゴリツリーＡ，５１００に
リボークデバイス（０１１０１）５１５０が存在する場
合のサブＥＫＢの生成について説明する図である。この
場合のサブＥＫＢは、リボークデバイス（０１１０１）
５１５０のみが処理できないサブＥＫＢ−（Ａ’）とし
て生成される。
【０３２４】この場合、図の太線で示すパスを接続した
鍵データ構成を持つサブＥＫＢを生成することになる。
従って、カテゴリツリーＡ，５１００のＴＬＣＥの生成
するサブＥＫＢ−（Ａ’）は、タグパート：１０１，０
１０，０００，１１１，０００，００１，１１１，１１
１、キーパート：Ｅｎｃ（Ｋ０１０，Ｋｒｏｏｔ），Ｅ
ｎｃ（Ｋ０１１１，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ０１１０
０，Ｋｒｏｏｔ）となるサブＥＫＢ−（Ａ’）となる。
カテゴリツリーＡ，５１００のＴＬＣＥは、このサブＥ
ＫＢ−（Ａ’）をキー発行センター（ＫＤＣ）に送信す
る。
【０３２５】キー発行センターは、各ＴＬＣＥの生成し
たサブＥＫＢ−（Ａ’）と、リボークデバイスのないカ
テゴリツリーＢ，５２００のＴＬＣＥから受領したサブ
ＥＫＢ−（Ｂ）（図５６参照）とから合成ＥＫＢを生成
する。合成ＥＫＢの生成について図５９を用いて説明す
る。合成ＥＫＢは、カテゴリツリーＡ，５１００のリボ
ークデバイス（０１１０１）５１５０を除くデバイス、
およびカテゴリツリーＢ，５２００のツリーに属するデ
バイスがルートキーを取得可能としたＥＫＢとして構成
される。基本的には、受領した複数のサブＥＫＢの鍵デ
ータ配列を混合してツリー上段から揃える作業によって
合成ＥＫＢが生成される。なお、同一段では左側を先と
するデータ配列を行なう。
【０３２６】この結果、合成ＥＫＢは、タグパート：１
００，０１０，０１０，０００，０００，１１１，００
０，１１１，１１１，００１，１１１，１１１、キーパ
ート：Ｅｎｃ（Ｋ０１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１
１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１１１，Ｋｒｏｏ
ｔ），Ｅｎｃ（Ｋ０１１１，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ
０１１００，Ｋｒｏｏｔ）を持つＥＫＢとして生成され
る。この合成ＥＫＢは、カテゴリツリーＡ，５１００の
リボークデバイス（０１１０１）５１５０を除くデバイ
ス、およびカテゴリツリーＢ，５２００のツリーに属す
るデバイスがルートキーを取得可能なＥＫＢである。
【０３２７】（５）ＥＫＢの利用 上述のような処理によってキー発行センター（ＫＤＣ）
の生成したＥＫＢは、ＥＫＢリクエスタに送信される。
例えばＥＫＢリクエスタが、 ［ａ］ＣＤ、ＤＶＤなどの、コンテンツ格納メディアを
提供するコンテンツプロバイダ（ＣＰ）。 ［ｂ］電子情報配信（ＥＣＤ：Electronic Content Dis
tribution）サービスを提供するコンテンツプロバイ
ダ。 である場合、ＥＫＢによって取得可能なルートキーでコ
ンテンツキーを暗号化し、コンテンツキーでユーザデバ
イスに提供するコンテンツを暗号化してコンテンツを流
通させることになる。この構成により、ＥＫＢの処理可
能な特定のカテゴリツリーに属するデバイスのみがコン
テンツの利用が可能となる。
【０３２８】また、ＥＫＢリクエスタが、［ｃ１]製造
時に記録媒体にＥＫＢを格納するようなフォーマットに
おいて、記録媒体の製造業社に取得したＥＫＢを与える
フォーマットホルダー。である場合、生成したＥＫＢ、
ルートキーで暗号化したコンテンツキーを記録媒体製造
業者に提供して、ＥＫＢおよびルートキーで暗号化した
コンテンツキーを格納した記録媒体を製造、あるいは自
ら記録媒体を製造して流通させる。この構成により、Ｅ
ＫＢの処理可能な特定のカテゴリツリーに属するデバイ
スのみが記録媒体のＥＫＢを利用したコンテンツ記録再
生時の暗号化処理、復号処理が可能となる。
【０３２９】さらに、ＥＫＢリクエスタが、［ｃ２］製
造時に記録デバイスにＥＫＢを格納するようなフォーマ
ットにおいて、記録デバイスの製造業社に取得したＥＫ
Ｂを与えるフォーマットホルダー。である場合、生成し
たＥＫＢ、ルートキーで暗号化したコンテンツキーを記
録デバイス製造業者に提供して、ＥＫＢおよびルートキ
ーで暗号化したコンテンツキーを格納した記録デバイス
を製造、あるいは自ら記録デバイスを製造して流通させ
る。この構成により、ＥＫＢの処理可能な特定のカテゴ
リツリーに属するデバイスのみがＥＫＢを利用したコン
テンツ記録再生時の暗号化処理、復号処理が可能とな
る。
【０３３０】以上のような処理によってＥＫＢが発行さ
れることになる。なお、ＥＫＢ発行処理プロセスにおけ
る各エンティテイ、ＥＫＢリクエスタ、キー発行センタ
ー（ＫＤＣ）、ＴＬＣＥ間の通信においては必要に応じ
て相互認証処理、送信データの暗号化処理が行われる。
また、その他のメッセージ暗号化処理、デジタル署名生
成、検証処理を行なう構成としてもよい。なお、公開鍵
暗号方式に基づく認証あるいは暗号通信を実行する場合
は、各エンティテイ間において予め公開鍵を保有し合う
手続きを行なっておく。
【０３３１】（サブＥＫＢの単純集合を合成ＥＫＢとす
る構成例）上述したサブＥＫＢから合成ＥＫＢを生成す
る処理においては、個々のサブＥＫＢに含まれる暗号化
鍵データの配列を全体ツリーの上段から下段に至るよう
に並び替える処理を行なっていた。次に、このような並
び替え処理を実行することなく、各カテゴリツリーのＴ
ＬＣＥの生成したサブＥＫＢをそのまま合成ＥＫＢに順
次格納して合成ＥＫＢを生成する構成について説明す
る。
【０３３２】図６０は、複数のカテゴリツリーのＴＬＣ
Ｅの生成したサブＥＫＢをそのままの形で複数格納した
合成ＥＫＢ６０００の例を示した図である。
【０３３３】ＥＫＢの発行処理において、キー発行セン
ター（ＫＤＣ）は、ＥＫＢリクエスタによって指定され
たＥＫＢタイプ識別ナンバーに対応してＥＫＢタイプ定
義リストに記録されたカテゴリツリーの管理エンティテ
イであるＴＬＣＥに対してサブＥＫＢの生成要求を発行
し、各ＴＬＣＥから提出されたサブＥＫＢ６１１０，６
１２０…を単に集めて合成ＥＫＢ内に格納する。ただし
各カテゴリに属する機器がその合成ＥＫＢ中からその機
器が処理可能な自デバイスの属するカテゴリに対応する
サブＥＫＢを選択できるように、各サブＥＫＢ部分の大
きさ（ｅｘ．データレングス）６１１１、そのサブＥＫ
Ｂがどのカテゴリ用のものかを表すデータ（ｅｘ．ノー
ドＩＤ）６１１２を付加する。
【０３３４】すなわち、格納対象として選択されたサブ
ＥＫＢの各々には、サブＥＫＢ格納領域のデータ長を示
すレングス、およびサブＥＫＢ識別データとしての各サ
ブＥＫＢの対応カテゴリツリーのノード識別子としての
ノードＩＤが対応付けられて格納される。また合成ＥＫ
Ｂに含まれるサブＥＫＢの数がヘッダ情報６２００とし
て付加される。合成ＥＫＢの全データに基づいて署名
（ｅｘ．認証局（ＣＡ）の署名）６３００が生成されて
付加される。
【０３３５】本方式に従って、前述の図５７を用いた説
明に対応する合成ＥＫＢを生成すると、図６１に示すよ
うな合成ＥＫＢが生成されることになる。サブＥＫＢ６
１１０の格納ＥＫＢは、図５５で説明したカテゴリツリ
ーＡのＴＬＣＥの生成したサブＥＫＢ−（Ａ）そのもの
であり、タグパート：１０１，０１０，０００，１１
１，１１１、キーパート：Ｅｎｃ（Ｋ０１０，Ｋｒｏｏ
ｔ），Ｅｎｃ（Ｋ０１１，Ｋｒｏｏｔ）となる。また、
サブＥＫＢ６１２０の格納ＥＫＢは、図５６で説明した
カテゴリツリーＢのＴＬＣＥの生成したサブＥＫＢ−
（Ｂ）そのものであり、タグパート：１１０，０１０，
０００，１１１，１１１、キーパート：Ｅｎｃ（Ｋ１１
０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１１１，Ｋｒｏｏｔ）と
なる。
【０３３６】また、前述の図５８、図５９を用いて説明
したリボークデバイスがある場合の合成ＥＫＢは、図６
２に示すデータ構成となる。サブＥＫＢ６１１０の格納
ＥＫＢは、図５８で説明したカテゴリツリーＡのＴＬＣ
Ｅの生成したサブＥＫＢ−（Ａ’）そのものであり、サ
ブＥＫＢ−（Ａ’）は、タグパート：１０１，０１０，
０００，１１１，０００，００１，１１１，１１１、キ
ーパート：Ｅｎｃ（Ｋ０１０，Ｋｒｏｏｔ），Ｅｎｃ
（Ｋ０１１１，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ０１１００，
Ｋｒｏｏｔ）となる。また、リボークデバイスの発生し
ていないサブＥＫＢ６１２０の格納ＥＫＢは、図５６で
説明したカテゴリツリーＢのＴＬＣＥの生成したサブＥ
ＫＢ−（Ｂ）そのものであり、タグパート：１１０，０
１０，０００，１１１，１１１、キーパート：Ｅｎｃ
（Ｋ１１０，Ｋｒｏｏｔ），Ｅｎｃ（Ｋ１１１，Ｋｒｏ
ｏｔ）となる。
【０３３７】このような構成をとることにより、各カテ
ゴリに属するデバイスは自己のデバイスが属するカテゴ
リに対応するサブＥＫＢを選択して処理（復号）するこ
とが可能となる。従って、各カテゴリ（ＴＬＣＥ）ごと
に、完全に任意の暗号アルゴリズムや鍵長を用いて、サ
ブＥＫＢを生成することができる。すなわち、他のカテ
ゴリに左右されず、ＴＬＣＥが暗号アルゴリズムや鍵長
を決めることができる。
【０３３８】キー発行センター（ＫＤＣ）にとっては、
各ＴＬＣＥから集めたサブＥＫＢのタグ、および鍵デー
タ部分を分解、組み直ししなくてよくなり、負荷が軽く
なる。
【０３３９】この方式に従ったＥＫＢを入手した機器
は、自分が属するカテゴリのサブＥＫＢを見つけ、それ
を、自デバイスを管理するＴＬＣＥが定める独自の方法
で処理することによりルートキーを得ることができる。
他のサブＥＫＢを処理するための、他のカテゴリのＴＬ
ＣＥが定めた方法は知る必要がなく、またサブＥＫＢに
おいて個々の鍵を固定長で表すなどの工夫が不要なた
め、理論的にはどの大きさの鍵でも用いることができる
ようになる。
【０３４０】（リボケーション処理−（１））複数カテ
ゴリにおいて共通に使用可能なＥＫＢを利用した処理に
おけるリボークの発生に際して実行される処理につい
て、以下説明する。暗号化コンテンツをネットワークま
たはメデイアによって外部から受領してＥＫＢによって
取得したキーを用いてコンテンツキーを取得してコンテ
ンツ利用を行なう場合のリボーク処理についてまず説明
する。
【０３４１】図６３を参照しながら説明する。カテゴリ
ツリーＡ，７１００とカテゴリツリーＢ，７２００にお
いて共通に使用されるＥＫＢ７０００が利用されている
状況を想定する。また、カテゴリツリーＡ，７１００と
カテゴリツリーＢ，７２００において共通に使用される
ＥＫＢ７０００はＥＫＢタイプ定義リストでは、ＥＫＢ
タイプ識別ナンバーが＃１に定義されているものとす
る。
【０３４２】このような状況において、コンテンツプロ
バイダは、ネットワークまたはメデイアによってコンテ
ンツキーで暗号化したコンテンツを提供し、カテゴリツ
リーＡ，７１００とカテゴリツリーＢ，７２００に属す
るデバイスは、ＥＫＢ７０００を用いてルートキーの取
得、ルートキーによる復号処理によるコンテンツキーの
取得、コンテンツキーによる暗号化コンテンツの取得を
実行してコンテンツを利用している。
【０３４３】この状況でカテゴリツリーＡ，７１００に
属するデバイスＡ１，７１２０の鍵データの漏洩など不
正処理可能な状況が発覚し、デバイスＡ１，７１２０の
リボークを行なうとする。
【０３４４】この場合、カテゴリツリーＡ，７１００の
ＴＬＣＥは、キー発行センター（ＫＤＣ）に対してツリ
ー変更通知（図５３参照）を実行し、キー発行センター
（ＫＤＣ）は、受信したツリー変更通知に基づいて管理
下の各ＴＬＣＥ、ＥＫＢリクエスタに対して通知する。
この時点の通知は、ツリー変更通知を受領したことを知
らせるのみであり、ＥＫＢタイプ定義リストの更新処理
は実行されない。
【０３４５】なお、リボーク発生に基づくツリー変更通
知は、リボークの発生したカテゴリツリーにおいて処理
可能なＥＫＢを利用しているエンティテイとしてのＥＫ
Ｂリクエスタに対してのみ、あるいはさらに、リボーク
の発生したカテゴリツリーと共有のＥＫＢが適用されて
いる他のカテゴリツリーを管理するカテゴリ・エンティ
テイに対してのみ実行する構成としてもよい。この処理
を行なうため、キー発行センター（ＫＤＣ）は、発行済
みＥＫＢの利用者リストとして、ＥＫＢタイプ識別ナン
バーとそのＥＫＢタイプを利用しているＥＫＢリクエス
タとを対応付けたリストを保有する。
【０３４６】リボーク処理を実行したカテゴリツリーの
デバイスを対象としてコンテンツの配信を実行している
ＥＫＢリクエスタとしてのコンテンツプロバイダは、リ
ボーク処理対象以外のデバイスにおいてのみ処理可能な
更新されたＥＫＢを生成するようにキー発行センター
（ＫＤＣ）に対してＥＫＢ発行要求を行なう。この場
合、ＥＫＢリクエスタとしてのコンテンツプロバイダ
は、カテゴリツリーＡ，７１００とカテゴリツリーＢ，
７２００において共通に使用されるＥＫＢのタイプとし
て定義されているＥＫＢタイプ識別ナンバー＃１を指定
する。また、新たなルートキーをＥＫＢリクエスタ自ら
生成してＫＤＣに送付するか、あるいは新たなルートキ
ーの生成をＫＤＣに依頼する。
【０３４７】キー発行センター（ＫＤＣ）は、指定され
たＥＫＢタイプ識別ナンバー＃１に基づいて、ＥＫＢタ
イプ定義リストを参照し、対応するカテゴリツリーのノ
ードに基づいてカテゴリツリーＡ，７１００とカテゴリ
ツリーＢ，７２００のＴＬＣＥに対して新たなルートキ
ーを正当なデバイスにおいて取得可能なサブＥＫＢの生
成を依頼する。
【０３４８】カテゴリツリーＡ，７１００とカテゴリツ
リーＢ，７２００のＴＬＣＥの各々は、依頼に基づいて
サブＥＫＢを生成する。この場合、カテゴリツリーＡ，
７１００においてはリボークされたデバイスＡ１，７１
２０を排除した他のデバイスにおいてのみ新規のルート
キーを取得可能なサブＥＫＢ−（Ａ）が生成される。カ
テゴリツリーＢ，７２００ではリボークされたデバイス
が存在しなければ、カテゴリに属するすべてのデバイス
において新規のルートキーを取得可能なサブＥＫＢ−
（Ｂ）を生成してキー発行センター（ＫＤＣ）に対して
送信する。
【０３４９】キー発行センター（ＫＤＣ）は各ＴＬＣＥ
から受信したサブＥＫＢに基づいて合成ＥＫＢを前述し
た方法に従って生成し、生成したＥＫＢをＥＫＢリクエ
スタ（ｅｘ．コンテンツプロバイダ）に送信する。
【０３５０】ＥＫＢリクエスタ（ｅｘ．コンテンツプロ
バイダ）はキー発行センター（ＫＤＣ）から受領した新
たなＥＫＢを適用してコンテンツ配信を行なう。具体的
にはコンテンツキーで暗号化したコンテンツを提供し、
ＥＫＢの復号によって得られるルートキーでコンテンツ
キーを暗号化して提供する。カテゴリツリーＡ，７１０
０とカテゴリツリーＢ，７２００に属するデバイスは、
ＥＫＢを用いてルートキーの取得、ルートキーによる復
号処理によるコンテンツキーの取得、コンテンツキーに
よる暗号化コンテンツの取得を実行してコンテンツが利
用可能である。ただし、カテゴリツリーＡ，７１００の
リボークデバイスＡ１，７１２０は更新されたＥＫＢを
処理できないのでコンテンツの利用ができなくなる。
【０３５１】なお、上述の説明においては、キー発行セ
ンター（ＫＤＣ）はＴＬＣＥからのツリー変更通知を受
領した場合、その時点では、ＥＫＢタイプ定義リストの
更新処理を実行しない例を説明したが、ＫＤＣがツリー
変更通知を受領した時点で、キー発行センター（ＫＤ
Ｃ）がツリー変更情報に基づいて、ＥＫＢタイプ定義リ
ストの更新処理、ＥＫＢ更新処理を実行し、各ＥＫＢリ
クエスタ、ＴＬＣＥに更新されたＥＫＢタイプ定義リス
トを送付する構成としてもよい。
【０３５２】（リボケーション処理−（２））次に、例
えば記録デバイスあるいは記録媒体にＥＫＢを格納した
構成で、記録媒体に対してユーザが様々なコンテンツを
暗号化して記録し暗号化処理、復号処理に必要となるキ
ーを記録デバイスあるいは記録媒体に格納したＥＫＢか
ら取得されるルートキーを用いたものとするいわゆる自
己記録型の形態におけるリボーク処理に伴う処理につい
て説明する。
【０３５３】図６４を参照しながら説明する。カテゴリ
ツリーＡ，８１００とカテゴリツリーＢ，８２００にお
いて共通に使用されるＥＫＢ８０００が利用されている
状況を想定する。すなわちカテゴリツリーＡ，８１００
とカテゴリツリーＢ，８２００において共通に使用され
る記録デバイスあるいは記録媒体には、共通のＥＫＢが
格納され、ユーザは、ＥＫＢを利用したコンテンツ暗号
化、復号処理によるコンテンツ記録再生を行なっている
ものとする。なお、カテゴリツリーＡ，８１００とカテ
ゴリツリーＢ，８２００において共通に使用されるＥＫ
Ｂ８０００はＥＫＢタイプ定義リストでは、ＥＫＢタイ
プ識別ナンバーが＃１に定義されているものとする。
【０３５４】この状況でカテゴリツリーＡ，８１００に
属するデバイスＡ１，８１２０の鍵データの漏洩など不
正処理可能な状況が発覚し、デバイスＡ１，８１２０の
リボークを行なうとする。
【０３５５】この場合、カテゴリツリーＡ，８１００の
ＴＬＣＥは、キー発行センター（ＫＤＣ）に対してツリ
ー変更通知（図５３参照）を実行し、キー発行センター
（ＫＤＣ）は、受信したツリー変更通知に基づいて管理
下の各ＴＬＣＥ、関連ＥＫＢリクエスタに対して通知す
る。この時点の通知は、ツリー変更通知を受領したこと
を知らせるのみであり、ＥＫＢタイプ定義リストの更新
処理は実行されない。
【０３５６】リボーク処理を実行したカテゴリツリーの
ＴＬＣＥは、リボークデバイスＡ１，８１２０における
将来におけるＥＫＢを利用した新たなコンテンツ処理を
停止させるため、自らＥＫＢリクエスタとして、リボー
ク処理対象以外のデバイスにおいてのみ処理可能な更新
されたＥＫＢを生成するようにキー発行センター（ＫＤ
Ｃ）に対してＥＫＢ発行要求を行なう。この場合、ＥＫ
ＢリクエスタとしてのＴＬＣＥは、カテゴリツリーＡ，
８１００とカテゴリツリーＢ，８２００において共通に
使用されるＥＫＢのタイプとして定義されているＥＫＢ
タイプ識別ナンバー＃１を指定する。また、新たなルー
トキーをＥＫＢリクエスタ自ら生成してＫＤＣに送付す
るか、あるいは新たなルートキーの生成をＫＤＣに依頼
する。
【０３５７】キー発行センター（ＫＤＣ）は、指定され
たＥＫＢタイプ識別ナンバー＃１に基づいて、ＥＫＢタ
イプ定義リストを参照し、対応するカテゴリツリーのノ
ードに基づいてカテゴリツリーＡ，８１００とカテゴリ
ツリーＢ，８２００のＴＬＣＥに対して新たなルートキ
ーを正当なデバイスにおいて取得可能なサブＥＫＢの生
成を依頼する。
【０３５８】カテゴリツリーＡ，８１００とカテゴリツ
リーＢ，８２００のＴＬＣＥの各々は、依頼に基づいて
サブＥＫＢを生成する。この場合、カテゴリツリーＡ，
８１００においてはリボークされたデバイスＡ１，８１
２０を排除した他のデバイスにおいてのみ新規のルート
キーを取得可能なサブＥＫＢ−（Ａ）が生成される。カ
テゴリツリーＢ，８２００ではリボークされたデバイス
が存在しなければ、カテゴリに属するすべてのデバイス
において新規のルートキーを取得可能なサブＥＫＢ−
（Ｂ）を生成してキー発行センター（ＫＤＣ）に対して
送信する。
【０３５９】キー発行センター（ＫＤＣ）は各ＴＬＣＥ
から受信したサブＥＫＢに基づいて合成ＥＫＢを前述し
た方法に従って生成し、生成したＥＫＢを各ＴＬＣＥ
（ｅｘ．フォーマットホルダー）に送信する。
【０３６０】各ＴＬＣＥ（ｅｘ．フォーマットホルダ
ー）はキー発行センター（ＫＤＣ）から受領した新たな
ＥＫＢを各デバイスに配信して、ＥＫＢの更新を実行さ
せる。カテゴリツリーＡ，８１００とカテゴリツリー
Ｂ，８２００に属するデバイスは、新たなコンテンツの
記録デバイスに対する記録を更新したＥＫＢを用いて取
得したルートキーを適用した暗号化処理として実行す
る。新たなＥＫＢを用いて暗号化記録されたコンテンツ
は対応するＥＫＢを適用した場合にのみ復号可能となる
ので、リボークされたデバイスにおいては利用不可能と
なる。
【０３６１】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。
【０３６２】
【発明の効果】以上、説明したように、本発明の情報処
理システムおよび方法によれば、カテゴリに基づいて区
分され、カテゴリ・エンティテイによって管理されるサ
ブツリーを複数有するキーツリーを構成し、キーツリー
を構成するパスを選択して選択パス上の下位キーによる
上位キーの暗号化処理データからなるＥＫＢを生成して
デバイスに提供する構成において、ＥＫＢタイプ識別子
と、ＥＫＢ処理可能な1以上のカテゴリツリーの識別デ
ータとを対応付けたＥＫＢタイプ定義リストに基づいて
ＥＫＢの発行管理を実行するように構成したので、ＥＫ
Ｂ生成要求者としてのＥＫＢリクエスタが容易に適用対
象となるカテゴリを選択できる。
【０３６３】また、本発明の情報処理システムおよび方
法によれば、ＥＫＢタイプ定義リストに定義されたＥＫ
Ｂの処理可能なカテゴリツリーにおけるリボーク等によ
る状態変化発生に関する通知処理を、ＥＫＢの利用エン
ティテイに対して実行する構成としたので、ＥＫＢリク
エスタ他のエンティテイは、常に最新のＥＫＢタイプ定
義情報に基づく処理が可能となる。
【図面の簡単な説明】
【図１】本発明の情報処理システムの構成例を説明する
図である。
【図２】本発明の情報処理システムにおいて適用可能な
記録再生装置の構成例を示すブロック図である。
【図３】本発明の情報処理システムにおける各種キー、
データの暗号化処理について説明するツリー構成図であ
る。
【図４】本発明の情報処理システムにおける各種キー、
データの配布に使用される有効化キーブロック（ＥＫ
Ｂ）の例を示す図である。
【図５】本発明の情報処理システムにおけるコンテンツ
キーの有効化キーブロック（ＥＫＢ）を使用した配布例
と復号処理例を示す図である。
【図６】本発明の情報処理システムにおける有効化キー
ブロック（ＥＫＢ）のフォーマット例を示す図である。
【図７】本発明の情報処理システムにおける有効化キー
ブロック（ＥＫＢ）のタグの構成を説明する図である。
【図８】本発明の情報処理システムにおける有効化キー
ブロック（ＥＫＢ）と、コンテンツキー、コンテンツを
併せて配信するデータ構成例を示す図である。
【図９】本発明の情報処理システムにおける有効化キー
ブロック（ＥＫＢ）と、コンテンツキー、コンテンツを
併せて配信した場合のデバイスでの処理例を示す図であ
る。
【図１０】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）とコンテンツを記録媒体に格納し
た場合の対応について説明する図である。
【図１１】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）と、コンテンツキーを送付する処
理を従来の送付処理と比較した図である。
【図１２】本発明の情報処理システムにおいて適用可能
な共通鍵暗号方式による認証処理シーケンスを示す図で
ある。
【図１３】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）と、認証キーを併せて配信するデ
ータ構成と、デバイスでの処理例を示す図（その１）で
ある。
【図１４】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）と、認証キーを併せて配信するデ
ータ構成と、デバイスでの処理例を示す図（その２）で
ある。
【図１５】本発明の情報処理システムにおいて適用可能
な公開鍵暗号方式による認証処理シーケンスを示す図で
ある。
【図１６】本発明の情報処理システムにおいて公開鍵暗
号方式による認証処理を用いて有効化キーブロック（Ｅ
ＫＢ）と、コンテンツキーを併せて配信する処理を示す
図である。
【図１７】本発明の情報処理システムにおいて有効化キ
ーブロック（ＥＫＢ）と、暗号化プログラムデータを併
せて配信する処理を示す図である。
【図１８】本発明の情報処理システムにおいて適用可能
なコンテンツ・インテグリティ・チェック値（ＩＣＶ）
の生成に使用するＭＡＣ値生成例を示す図である。
【図１９】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）と、ＩＣＶ生成キーを併せて配信
するデータ構成と、デバイスでの処理例を示す図（その
１）である。
【図２０】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）と、ＩＣＶ生成キーを併せて配信
するデータ構成と、デバイスでの処理例を示す図（その
２）である。
【図２１】本発明の情報処理システムにおいて適用可能
なコンテンツ・インテグリティ・チェック値（ＩＣＶ）
をメディアに格納した場合のコピー防止機能を説明する
図である。
【図２２】本発明の情報処理システムにおいて適用可能
なコンテンツ・インテグリティ・チェック値（ＩＣＶ）
をコンテンツ格納媒体と別に管理する構成を説明する図
である。
【図２３】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリ分類の例を説明する図である。
【図２４】本発明の情報処理システムにおける簡略化有
効化キーブロック（ＥＫＢ）の生成過程を説明する図で
ある。
【図２５】本発明の情報処理システムにおける有効化キ
ーブロック（ＥＫＢ）の生成過程を説明する図である。
【図２６】本発明の情報処理システムにおける簡略化有
効化キーブロック（ＥＫＢ）（例１）を説明する図であ
る。
【図２７】本発明の情報処理システムにおける簡略化有
効化キーブロック（ＥＫＢ）（例２）を説明する図であ
る。
【図２８】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成について説明する図で
ある。
【図２９】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成の詳細について説明す
る図である。
【図３０】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成について説明する図で
ある。
【図３１】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのリザーブノードに
ついて説明する図である。
【図３２】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成での新規カテゴリツリ
ー登録処理シーケンスについて説明する図である。
【図３３】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成での新規カテゴリツリ
ーと上位カテゴリツリーの関係について説明する図であ
る。
【図３４】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成で用いるサブＥＫＢに
ついて説明する図である。
【図３５】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのデバイスリボーク
処理について説明する図である。
【図３６】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのデバイスリボーク
処理シーケンスについて説明する図である。
【図３７】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのデバイスリボーク
時の更新サブＥＫＢについて説明する図である。
【図３８】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのカテゴリツリーリ
ボーク処理について説明する図である。
【図３９】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのカテゴリツリーリ
ボーク処理シーケンスについて説明する図である。
【図４０】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのリボークカテゴリ
ツリーと上位カテゴリツリーの関係について説明する図
である。
【図４１】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのケイパビリテイ設
定について説明する図である。
【図４２】本発明の情報処理システムにおける階層ツリ
ー構造のカテゴリツリー管理構成でのケイパビリテイ設
定について説明する図である。
【図４３】本発明の情報処理システムにおけるキー発行
センター（ＫＤＣ）の管理するケイパビリティ管理テー
ブル構成を説明する図である。
【図４４】本発明の情報処理システムにおけるキー発行
センター（ＫＤＣ）の管理するケイパビリティ管理テー
ブルに基づくＥＫＢ生成処理フロー図である。
【図４５】本発明の情報処理システムにおける新規カテ
ゴリツリー登録時のケイパビリティ通知処理を説明する
図である。
【図４６】本発明の情報処理システムにおけるカテゴリ
ツリーの構成を説明する図である。
【図４７】本発明の情報処理システムにおけるＥＫＢリ
クエスタ、キー発行センター、トップレベル・カテゴリ
・エンティテイ（ＴＬＣＥ）との関係、処理例を説明す
る図である。
【図４８】本発明の情報処理システムにおけるＥＫＢリ
クエスタ、キー発行センター、トップレベル・カテゴリ
・エンティテイ（ＴＬＣＥ）のハード構成例を説明する
図である。
【図４９】本発明の情報処理システムにおけるデバイス
の保有するデバイスノードキー（ＤＮＫ）について説明
する図である。
【図５０】本発明の情報処理システムにおけるＥＫＢタ
イプ定義リストのデータ構成を説明する図である。
【図５１】本発明の情報処理システムにおけるＥＫＢタ
イプ登録処理フローを示す図である。
【図５２】本発明の情報処理システムにおけるＥＫＢタ
イプ無効化処理フローを示す図である。
【図５３】本発明の情報処理システムにおけるツリー変
更通知処理フローを示す図である。
【図５４】本発明の情報処理システムにおけるＥＫＢタ
イプリスト要求処理フローを示す図である。
【図５５】本発明の情報処理システムにおけるサブＥＫ
Ｂの生成処理を説明する図である。
【図５６】本発明の情報処理システムにおけるサブＥＫ
Ｂの生成処理を説明する図である。
【図５７】本発明の情報処理システムにおけるサブＥＫ
Ｂから合成したＥＫＢを生成する処理を説明する図であ
る。
【図５８】本発明の情報処理システムにおけるリボーク
デバイスがある場合のサブＥＫＢの生成処理を説明する
図である。
【図５９】本発明の情報処理システムにおけるリボーク
デバイスがある場合のサブＥＫＢから合成したＥＫＢを
生成する処理を説明する図である。
【図６０】本発明の情報処理システムにおけるサブＥＫ
Ｂから合成したＥＫＢのデータ構成を説明する図であ
る。
【図６１】本発明の情報処理システムにおけるサブＥＫ
Ｂから合成したＥＫＢのデータ構成を説明する図であ
る。
【図６２】本発明の情報処理システムにおけるリボーク
デバイスがある場合のサブＥＫＢから合成したＥＫＢの
データ構成を説明する図である。
【図６３】本発明の情報処理システムにおけるデータ配
信型のシステムにおけるリボーク処理を説明する図であ
る。
【図６４】本発明の情報処理システムにおける自己記録
型のシステムにおけるリボーク処理を説明する図であ
る。
【符号の説明】
１０ コンテンツ配信側 １１ インターネット １２ 衛星放送 １３ 電話回線 １４ メディア ２０ コンテンツ受信側 ２１ パーソナルコンピュータ（ＰＣ） ２２ ポータブルデバイス（ＰＤ） ２３ 携帯電話、ＰＤＡ ２４ 記録再生器 ２５ 再生専用器 ３０ メディア １００ 記録再生装置 １１０ バス １２０ 入出力Ｉ／Ｆ １３０ ＭＰＥＧコーデック １４０ 入出力Ｉ／Ｆ １４１ Ａ／Ｄ，Ｄ／Ａコンバータ １５０ 暗号処理手段 １６０ ＲＯＭ １７０ ＣＰＵ １８０ メモリ １９０ ドライブ １９５ 記録媒体 ６０１ バージョン ６０２ デプス ６０３ データポインタ ６０４ タグポインタ ６０５ 署名ポインタ ６０６ データ部 ６０７ タグ部 ６０８ 署名 １１０１ 記録デバイス ２３０１ ルートキー ２３０２ ノードキー ２３０３ リーフキー ２３０４ カテゴリノード ２３０６ サブカテゴリノード ２７０１ カテゴリツリー ２７０２ サブルート ２８１１，２８５１ サブルート ２８１２，２８５２ カテゴリツリー末端ノード ２９０１，２９０２ カテゴリツリー ２９５０ リザーブノード ２９７０ 管理末端ノード ３０１１，３０１２，３０１３ カテゴリツリー ３０２１，３０２２，３０２３ リザーブノード ３２０１ 末端ノード ３２０２ 頂点ノード ３３０１，３３０２ 末端ノード ３３０３ 新規カテゴリツリー追加末端ノード ３４１０，３４２０，３４３０ カテゴリツリー ３４１１，３４２１，３４３１ サブルート ３４３２ リボークデバイスノード ３６０１ 末端ノード ３７１０，３７２０，３７３０ カテゴリツリー ３７１１，３７２１，３７３１ サブルート ３９０１ 末端ノード ３９０２ 頂点ノード（サブルートノード） ４００１〜４００５ カテゴリツリー ４０２１，４０２２，４０２３ カテゴリツリー ４１０１〜４１０５ カテゴリツリー ４５１０ 管理エンティテイ ４５１１ キー発行センター（ＫＤＣ） ４５２０ ＥＫＢリクエスタ ４５３０ トップレベル・カテゴリ・エンティテイ（Ｔ
ＬＣＥ） ４５４０ メディア製造者 ４５５０ デバイス製造者 ４５５１ ＤＮＫＥデバイス製造者 ４５５２ ＤＮＫデバイス製造者 ５１００ カテゴリツリーＡ ５１２０ デバイスノードキー領域 ５１５０ リボークデバイス ５２００ カテゴリツリーＢ ５２２０ デバイスノードキー領域 ５３００ ルートツリー ６０００ ＥＫＢ ６１１０，６１２０ サブＥＫＢ ６１１１，６１２１ レングスデータ ６１１２，６１２２ カテゴリ識別データ ６２００ ヘッダ情報 ６３００ 署名データ ７０００ ＥＫＢ ７１００ カテゴリツリーＡ ７１２０ リボークデバイス ７２００ カテゴリツリーＢ ８０００ ＥＫＢ ８１００ カテゴリツリーＡ ８１２０ リボークデバイス ８２００ カテゴリツリーＢ
───────────────────────────────────────────────────── フロントページの続き (72)発明者 大石 丈於 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 石黒 隆二 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 瀧 隆太 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5B017 AA03 BA07 CA09 CA15 CA16 5B085 AE09 AE13 AE29 5J104 AA16 EA04 EA15 EA26 NA02 PA07

Claims (15)

    【特許請求の範囲】
  1. 【請求項１】複数のデバイスをリーフとして構成したツ
    リーのルートからリーフまでのパス上のルート、ノー
    ド、およびリーフに各々キーを対応付けたキーツリーを
    構成し、該キーツリーを構成するパスを選択して選択パ
    ス上の下位キーによる上位キーの暗号化処理データを有
    し、前記選択パスに対応するノードキーセットを利用可
    能なデバイスにおいてのみ復号可能とした有効化キーブ
    ロック（ＥＫＢ）をデバイスに提供する構成を持つ情報
    処理システムであり、 前記キーツリーは、カテゴリに基づいて区分され、カテ
    ゴリ・エンティテイによって管理されるサブツリーとし
    てのカテゴリツリーを複数有する構成であり、 カテゴリツリーにおいて共通に復号処理可能なＥＫＢを
    生成して発行するキー発行センター（ＫＤＣ）は、 ＥＫＢタイプ識別子と、ＥＫＢ処理可能なカテゴリツリ
    ーの識別データとを対応付けたＥＫＢタイプ定義リスト
    を有し、 前記ＥＫＢタイプ定義リストに定義されたＥＫＢの処理
    可能なカテゴリツリーにおける状態変化発生に関する通
    知処理を、少なくとも前記状態変化発生カテゴリツリー
    を処理可能カテゴリツリーとして設定したＥＫＢの利用
    エンティテイに対して実行する構成を有することを特徴
    とする情報処理システム。
  2. 【請求項２】前記カテゴリツリーにおける状態変化は、
    該カテゴリツリーにおけるリボーク（機器排除）発生に
    伴う状態変化であることを特徴とする請求項１に記載の
    情報処理システム。
  3. 【請求項３】前記カテゴリツリーにおける状態変化は、
    該カテゴリツリーに属するデバイスのデバイス格納キー
    の変更に伴う状態変化であることを特徴とする請求項１
    に記載の情報処理システム。
  4. 【請求項４】前記ＥＫＢの利用エンティテイは、前記キ
    ー発行センター（ＫＤＣ）に対するＥＫＢ生成要求エン
    ティテイとしてのＥＫＢリクエスタを含むことを特徴と
    する請求項１に記載の情報処理システム。
  5. 【請求項５】前記ＥＫＢの利用エンティテイは、前記Ｅ
    ＫＢタイプ定義リスト中に定義されたＥＫＢ処理可能な
    カテゴリツリーの管理エンティテイとしてのカテゴリ・
    エンティテイを含むことを特徴とする請求項１に記載の
    情報処理システム。
  6. 【請求項６】前記キー発行センター（ＫＤＣ）は、 前記状態変化発生に関する通知処理を、前記ＥＫＢタイ
    プ定義リストの利用エンティテイである前記キー発行セ
    ンター（ＫＤＣ）に対するＥＫＢ生成要求エンティテイ
    としてのＥＫＢリクエスタ、およびカテゴリツリーの管
    理エンティテイとしてのカテゴリ・エンティテイすべて
    に対して実行することを特徴とする請求項１に記載の情
    報処理システム。
  7. 【請求項７】前記キー発行センター（ＫＤＣ）は、 カテゴリツリーにおける状態変化発生情報を、該カテゴ
    リツリーの管理エンティテイであるカテゴリ・エンティ
    テイから受信し、 該カテゴリ・エンティテイからの状態変化発生情報受信
    に基づいて、状態変化発生に関する通知処理を実行する
    構成を有することを特徴とする請求項１に記載の情報処
    理システム。
  8. 【請求項８】カテゴリに基づいて区分され、カテゴリ・
    エンティテイによって管理されるサブツリーとしてのカ
    テゴリツリーを複数有し、デバイスをリーフとして構成
    したツリーのルートからリーフまでのパス上のルート、
    ノード、およびリーフに各々キーを対応付けたキーツリ
    ーを構成し、該キーツリーを構成するパスを選択して選
    択パス上の下位キーによる上位キーの暗号化処理データ
    を有し、前記選択パスに対応するノードキーセットを利
    用可能なデバイスにおいてのみ復号可能とした有効化キ
    ーブロック（ＥＫＢ）をデバイスに提供する構成を持つ
    システムにおける情報処理方法であり、 カテゴリツリーにおいて共通に復号処理可能なＥＫＢを
    生成して発行するキー発行センター（ＫＤＣ）は、 ＥＫＢタイプ識別子と、ＥＫＢ処理可能なカテゴリツリ
    ーの識別データとを対応付けたＥＫＢタイプ定義リスト
    に定義されたＥＫＢの処理可能なカテゴリツリーにおけ
    る状態変化発生に関する通知処理を、少なくとも前記状
    態変化発生カテゴリツリーを処理可能カテゴリツリーと
    して設定したＥＫＢの利用エンティテイに対して実行す
    ることを特徴とする情報処理方法。
  9. 【請求項９】前記カテゴリツリーにおける状態変化は、
    該カテゴリツリーにおけるリボーク（機器排除）発生に
    伴う状態変化であることを特徴とする請求項８に記載の
    情報処理方法。
  10. 【請求項１０】前記カテゴリツリーにおける状態変化
    は、該カテゴリツリーに属するデバイスのデバイス格納
    キーの変更に伴う状態変化であることを特徴とする請求
    項８に記載の情報処理方法。
  11. 【請求項１１】前記ＥＫＢの利用エンティテイは、前記
    キー発行センター（ＫＤＣ）に対するＥＫＢ生成要求エ
    ンティテイとしてのＥＫＢリクエスタを含むことを特徴
    とする請求項８に記載の情報処理方法。
  12. 【請求項１２】前記ＥＫＢの利用エンティテイは、前記
    ＥＫＢタイプ定義リスト中に定義されたＥＫＢ処理可能
    なカテゴリツリーの管理エンティテイとしてのカテゴリ
    ・エンティテイを含むことを特徴とする請求項８に記載
    の情報処理方法。
  13. 【請求項１３】前記キー発行センター（ＫＤＣ）は、 前記状態変化発生に関する通知処理を、前記ＥＫＢタイ
    プ定義リストの利用エンティテイである前記キー発行セ
    ンター（ＫＤＣ）に対するＥＫＢ生成要求エンティテイ
    としてのＥＫＢリクエスタ、およびカテゴリツリーの管
    理エンティテイとしてのカテゴリ・エンティテイすべて
    に対して実行することを特徴とする請求項８に記載の情
    報処理方法。
  14. 【請求項１４】前記キー発行センター（ＫＤＣ）は、 カテゴリツリーにおける状態変化発生情報を、該カテゴ
    リツリーの管理エンティテイであるカテゴリ・エンティ
    テイから受信し、 該カテゴリ・エンティテイからの状態変化発生情報受信
    に基づいて、状態変化発生に関する通知処理を実行する
    構成を有することを特徴とする請求項８に記載の情報処
    理方法。
  15. 【請求項１５】カテゴリに基づいて区分され、カテゴリ
    ・エンティテイによって管理されるサブツリーとしての
    カテゴリツリーを複数有し、デバイスをリーフとして構
    成したツリーのルートからリーフまでのパス上のルー
    ト、ノード、およびリーフに各々キーを対応付けたキー
    ツリーを構成し、該キーツリーを構成するパスを選択し
    て選択パス上の下位キーによる上位キーの暗号化処理デ
    ータを有し、前記選択パスに対応するノードキーセット
    を利用可能なデバイスにおいてのみ復号可能とした有効
    化キーブロック（ＥＫＢ）をデバイスに提供する構成を
    持つシステムにおける情報処理をコンピュータ・システ
    ム上で実行せしめるコンピュータ・プログラムを記録し
    たプログラム記録媒体であって、前記コンピュータ・プ
    ログラムは、 カテゴリツリーにおける状態変化発生情報を、該カテゴ
    リツリーの管理エンティテイであるカテゴリ・エンティ
    テイから受信するステップと、 該カテゴリ・エンティテイからの状態変化発生情報受信
    に基づいて、状態変化発生に関する通知処理を少なくと
    も前記状態変化発生カテゴリツリーを処理可能カテゴリ
    ツリーとして設定したＥＫＢの利用エンティテイに対し
    て実行するステップと、 を有することを特徴とするプログラム記録媒体。
JP2000396098A 2000-12-26 2000-12-26 情報処理システム、および情報処理方法、並びにプログラム記録媒体 Expired - Fee Related JP4710132B2 (ja)

Priority Applications (13)

Application Number Priority Date Filing Date Title
JP2000396098A JP4710132B2 (ja) 2000-12-26 2000-12-26 情報処理システム、および情報処理方法、並びにプログラム記録媒体
CNB018086713A CN1211975C (zh) 2000-12-26 2001-12-21 信息管理系统和方法
AT06076195T ATE419691T1 (de) 2000-12-26 2001-12-21 Hierarchisches data content baumverteilung informationsystem und -verfahren
KR1020027011163A KR100852305B1 (ko) 2000-12-26 2001-12-21 정보 처리 시스템 및 방법
DE60137270T DE60137270D1 (de) 2000-12-26 2001-12-21 Hierarchisches Data Content Baumverteilung Informationsystem und -Verfahren
DE60127096T DE60127096T2 (de) 2000-12-26 2001-12-21 Vorrichtung und verfahren zur informationsverarbeitung
AT01272281T ATE356484T1 (de) 2000-12-26 2001-12-21 Vorrichtung und verfahren zur informationsverarbeitung
PCT/JP2001/011237 WO2002052781A1 (fr) 2000-12-26 2001-12-21 Systeme de traitement de l'information et procede
US10/204,775 US7167564B2 (en) 2000-12-26 2001-12-21 Information processing system and method
EP01272281A EP1253739B1 (en) 2000-12-26 2001-12-21 Information processing system and method
EP06076195A EP1710947B1 (en) 2000-12-26 2001-12-21 Hierarchical data content tree distribution information system and method
HK03109357A HK1058269A1 (en) 2000-12-26 2003-12-23 Information processing system and method
US11/639,711 US7738662B2 (en) 2000-12-26 2006-12-15 Information processing system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000396098A JP4710132B2 (ja) 2000-12-26 2000-12-26 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Publications (2)

Publication Number Publication Date
JP2002198952A true JP2002198952A (ja) 2002-07-12
JP4710132B2 JP4710132B2 (ja) 2011-06-29

Family

ID=18861456

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000396098A Expired - Fee Related JP4710132B2 (ja) 2000-12-26 2000-12-26 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Country Status (9)

Country Link
US (2) US7167564B2 (ja)
EP (2) EP1710947B1 (ja)
JP (1) JP4710132B2 (ja)
KR (1) KR100852305B1 (ja)
CN (1) CN1211975C (ja)
AT (2) ATE419691T1 (ja)
DE (2) DE60127096T2 (ja)
HK (1) HK1058269A1 (ja)
WO (1) WO2002052781A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008022122A (ja) * 2006-07-11 2008-01-31 Kddi Corp 鍵管理システム、鍵管理方法およびプログラム

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188176B1 (en) 2000-01-20 2007-03-06 Priceline.Com Incorporated Apparatus, system, and method for maintaining a persistent data state on a communications network
JP4581246B2 (ja) * 2000-12-26 2010-11-17 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体
JP4710132B2 (ja) * 2000-12-26 2011-06-29 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体
KR100929336B1 (ko) 2001-03-29 2009-12-03 파나소닉 주식회사 데이터를 암호화하여 데이터를 보호하는 데이터 보호 시스템
EP1278330B1 (en) * 2001-03-29 2008-06-25 Sony Corporation Information processing apparatus
GB0129065D0 (en) * 2001-12-05 2002-01-23 Philips Electronics Uk Ltd Method and apparatus for verifying the integrity of system data
US7340603B2 (en) 2002-01-30 2008-03-04 Sony Corporation Efficient revocation of receivers
JP2004054834A (ja) * 2002-07-24 2004-02-19 Matsushita Electric Ind Co Ltd プログラム開発方法、プログラム開発支援装置およびプログラム実装方法
KR100924773B1 (ko) * 2002-09-16 2009-11-03 삼성전자주식회사 메타데이터 암호화 및 복호화 방법과 암호화된 메타데이터관리 방법 및 그 시스템
JP3821086B2 (ja) * 2002-11-01 2006-09-13 ソニー株式会社 ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム
US7296158B2 (en) * 2002-11-08 2007-11-13 Palo Alto Research Center Incorporated Methods, apparatus, and program products for inferring service usage
JP4099039B2 (ja) * 2002-11-15 2008-06-11 松下電器産業株式会社 プログラム更新方法
WO2004064313A1 (en) * 2003-01-15 2004-07-29 Matsushita Electric Industrial Co., Ltd. Content protection system, key data generation apparatus, and terminal appparatus
JP4284497B2 (ja) * 2003-01-29 2009-06-24 日本電気株式会社 情報共有方法、装置、およびプログラム
US7835520B2 (en) * 2003-02-20 2010-11-16 Zoran Corporation Unique identifier per chip for digital audio/video data encryption/decryption in personal video recorders
US8132024B2 (en) * 2003-03-11 2012-03-06 Panasonic Corporation Digital work protection system, recording apparatus, reproduction apparatus, and recording medium
US7426637B2 (en) * 2003-05-21 2008-09-16 Music Public Broadcasting, Inc. Method and system for controlled media sharing in a network
US7165238B2 (en) * 2003-06-06 2007-01-16 Intentional Software Corporation Method and system for organizing and manipulating nodes by category in a program tree
CN1833400B (zh) * 2003-08-05 2011-12-28 松下电器产业株式会社 著作权保护系统
US20050049886A1 (en) * 2003-08-28 2005-03-03 Sbc Knowledge Ventures, L.P. System and method for managing digital rights and content assets
US8015301B2 (en) * 2003-09-30 2011-09-06 Novell, Inc. Policy and attribute based access to a resource
US7467415B2 (en) * 2003-09-30 2008-12-16 Novell, Inc. Distributed dynamic security for document collaboration
US7299493B1 (en) * 2003-09-30 2007-11-20 Novell, Inc. Techniques for dynamically establishing and managing authentication and trust relationships
US7412603B2 (en) * 2003-12-05 2008-08-12 Microsoft Corporation Methods and systems for enabling secure storage of sensitive data
US8037314B2 (en) * 2003-12-22 2011-10-11 Intel Corporation Replacing blinded authentication authority
US7802095B2 (en) * 2004-02-03 2010-09-21 Music Public Broadcasting, Inc. Method and system for preventing unauthorized recording of media content on a Macintosh operating system
JP4725070B2 (ja) * 2004-10-13 2011-07-13 パナソニック株式会社 正規コンテンツ確認方法、コンテンツ送受信システム、送信機、および受信機
JP3814620B2 (ja) * 2004-10-15 2006-08-30 株式会社東芝 情報処理装置および情報処理方法
US7386128B2 (en) * 2004-12-29 2008-06-10 General Instrument Corporation Conditional access system providing access to multiple programs or services
US7971070B2 (en) * 2005-01-11 2011-06-28 International Business Machines Corporation Read/write media key block
KR20060131536A (ko) 2005-06-16 2006-12-20 삼성전자주식회사 ＢＥ 시스템에서의 홈 디바이스의 통합적 키(ｋｅｙ) 관리방법 및 그 시스템
JP4596256B2 (ja) * 2005-08-02 2010-12-08 ソニー株式会社 送受信システムおよび方法、送信装置および方法、受信装置および方法、並びにプログラム
WO2007059807A1 (en) * 2005-11-22 2007-05-31 Nero Ag Apparatus and method for retrieving a decryption key, license server and media player
US20080025504A1 (en) * 2005-11-23 2008-01-31 Robert Rapp Computer or digital device data encryption/decryption performed by using a random analog source
WO2007093946A1 (en) * 2006-02-14 2007-08-23 Koninklijke Philips Electronics N.V. Improved method of content protection
WO2007093925A1 (en) * 2006-02-14 2007-08-23 Koninklijke Philips Electronics N.V. Improved method of content protection
US20100251381A1 (en) * 2007-08-17 2010-09-30 Seong-Oun Hwang System renewability message providing method and system renewability message using method and apparatus thereof
US8761402B2 (en) * 2007-09-28 2014-06-24 Sandisk Technologies Inc. System and methods for digital content distribution
US9083685B2 (en) * 2009-06-04 2015-07-14 Sandisk Technologies Inc. Method and system for content replication control
WO2011064883A1 (ja) * 2009-11-27 2011-06-03 株式会社東芝 メモリチップ
US8386800B2 (en) * 2009-12-04 2013-02-26 Cryptography Research, Inc. Verifiable, leak-resistant encryption and decryption
CN101882197B (zh) * 2010-05-31 2012-07-04 北京航空航天大学 一种基于分级密钥的rfid询问-应答安全认证方法
JP2012084071A (ja) * 2010-10-14 2012-04-26 Toshiba Corp デジタルコンテンツの保護方法、復号方法、再生装置、記憶媒体、暗号装置
JP5670272B2 (ja) 2011-07-19 2015-02-18 株式会社東芝 情報処理装置、サーバ装置およびプログラム
US8661527B2 (en) 2011-08-31 2014-02-25 Kabushiki Kaisha Toshiba Authenticator, authenticatee and authentication method
EP2767030B1 (en) * 2011-10-13 2017-09-27 Evolium Technologies, S.L. Multi-repository key storage and selection
EP2815345B1 (en) * 2012-02-17 2022-08-03 Irdeto B.V. Digital rights management
US9008316B2 (en) * 2012-03-29 2015-04-14 Microsoft Technology Licensing, Llc Role-based distributed key management
WO2014059047A2 (en) * 2012-10-10 2014-04-17 Red.Com, Inc. Video distribution and playback
JP5992295B2 (ja) * 2012-11-02 2016-09-14 株式会社東芝 通信制御装置、通信装置およびプログラム
WO2016118523A1 (en) 2015-01-19 2016-07-28 InAuth, Inc. Systems and methods for trusted path secure communication
US20160246582A1 (en) * 2015-02-25 2016-08-25 Red Hat, Inc. Generic Semantic Configuration Service
US9774610B2 (en) * 2015-07-28 2017-09-26 Futurewei Technologies, Inc. Certificateless data verification with revocable signatures
US11128452B2 (en) * 2017-03-25 2021-09-21 AVAST Software s.r.o. Encrypted data sharing with a hierarchical key structure
US11303632B1 (en) * 2018-06-08 2022-04-12 Wells Fargo Bank, N.A. Two-way authentication system and method
KR20200085143A (ko) 2019-01-04 2020-07-14 삼성전자주식회사 외부 장치를 등록하는 대화형 제어 시스템 및 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11187013A (ja) * 1997-12-24 1999-07-09 Ibm Japan Ltd 暗号鍵配信システム
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US5999947A (en) * 1997-05-27 1999-12-07 Arkona, Llc Distributing database differences corresponding to database change events made to a database table located on a server computer
DE19928848A1 (de) 1999-06-24 2000-12-28 Sator Laser Gmbh Vorrichtung zum Schneiden von Materialbahnen aus Papier oder Kunststoff
US6240188B1 (en) * 1999-07-06 2001-05-29 Matsushita Electric Industrial Co., Ltd. Distributed group key management scheme for secure many-to-many communication
US6263435B1 (en) * 1999-07-06 2001-07-17 Matsushita Electric Industrial Co., Ltd. Dual encryption protocol for scalable secure group communication
IL130963A (en) * 1999-07-15 2006-04-10 Nds Ltd Key management for content protection
JP4710132B2 (ja) * 2000-12-26 2011-06-29 ソニー株式会社 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11187013A (ja) * 1997-12-24 1999-07-09 Ibm Japan Ltd 暗号鍵配信システム
US6049878A (en) * 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6010065706, Ｗａｌｄｖｏｇｅｌ， Ｍ． ｅｔ ａｌ．, "Ｔｈｅ ＶｅｒｓａＫｅｙ Ｆｒａｍｅｗｏｒｋ：Ｖｅｒｓａｔｉｌｅ Ｇｒｏｕｐ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ", ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ, 199909, Ｖｏｌ．１７ Ｎｏ．９, ｐ．１６１４−１６３１ *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008022122A (ja) * 2006-07-11 2008-01-31 Kddi Corp 鍵管理システム、鍵管理方法およびプログラム

Also Published As

Publication number Publication date
EP1253739A1 (en) 2002-10-30
JP4710132B2 (ja) 2011-06-29
EP1710947B1 (en) 2008-12-31
DE60127096T2 (de) 2007-11-08
KR20030019315A (ko) 2003-03-06
HK1058269A1 (en) 2004-05-07
CN1426644A (zh) 2003-06-25
EP1710947A1 (en) 2006-10-11
WO2002052781A1 (fr) 2002-07-04
DE60127096D1 (de) 2007-04-19
CN1211975C (zh) 2005-07-20
EP1253739A4 (en) 2005-02-02
EP1253739B1 (en) 2007-03-07
ATE419691T1 (de) 2009-01-15
US20030142824A1 (en) 2003-07-31
US7738662B2 (en) 2010-06-15
KR100852305B1 (ko) 2008-08-18
ATE356484T1 (de) 2007-03-15
US7167564B2 (en) 2007-01-23
US20070098177A1 (en) 2007-05-03
DE60137270D1 (de) 2009-02-12

Similar Documents

Publication Publication Date Title
JP4710132B2 (ja) 情報処理システム、および情報処理方法、並びにプログラム記録媒体
JP4581246B2 (ja) 情報処理システム、および情報処理方法、並びにプログラム記録媒体
JP4078802B2 (ja) 情報処理システム、情報処理方法、情報処理装置、および情報記録媒体、並びにプログラム記録媒体
KR100840823B1 (ko) 암호 키 블록을 이용한 정보 처리 시스템 및 방법
JP2001358707A (ja) 暗号鍵ブロックを用いた情報処理システムおよび情報処理方法、並びにプログラム提供媒体
JP4023083B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体
WO2001078298A1 (fr) Systeme et procede de traitement d'informations
JP4120135B2 (ja) 暗号鍵ブロックを用いた情報処理システムおよび情報処理方法、並びにプログラム提供媒体
JP4806847B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム記録媒体
JP3988385B2 (ja) 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム記録媒体
JP2010288291A (ja) 情報処理システム、および情報処理方法、並びにプログラム記録媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110118

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110307

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140401

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees