JP2004054745A - 情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム - Google Patents
情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム Download PDFInfo
- Publication number
- JP2004054745A JP2004054745A JP2002213702A JP2002213702A JP2004054745A JP 2004054745 A JP2004054745 A JP 2004054745A JP 2002213702 A JP2002213702 A JP 2002213702A JP 2002213702 A JP2002213702 A JP 2002213702A JP 2004054745 A JP2004054745 A JP 2004054745A
- Authority
- JP
- Japan
- Prior art keywords
- content
- file
- key
- data
- information
- 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.)
- Pending
Links
Images
Abstract
【課題】コンテンツの二次流通をセキュアに実行し、利用権情報の取得のみによって正規なコンテンツ利用を実現する装置、方法を提供する。
【解決手段】すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、ショップサーバへの接続処理を容易としたリンクデータを持つ説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領する。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる。
【選択図】 図３４
【解決手段】すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、ショップサーバへの接続処理を容易としたリンクデータを持つ説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領する。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる。
【選択図】 図３４
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムに関する。さらに詳細には、クライアントが取得したコンテンツの二次流通を簡易にかつセキュアに実行させる構成を実現し、コンテンツサーバからのクライアントに対するコンテンツ配信を省略したコンテンツ取得、流通を実現する情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、音楽データ、ゲームプログラム、画像データ等、様々なソフトウエアデータ（以下、これらをコンテンツ（Ｃｏｎｔｅｎｔ）と呼ぶ）の、インターネット等のネットワーク、あるいは、メモリカード、ＨＤ、ＤＶＤ、ＣＤ等の流通可能な記憶媒体を介した流通が盛んになっている。これらの流通コンテンツは、ユーザの所有するＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、記録再生器、再生専用器、あるいはゲーム機器内の記憶手段、例えばＨＤ，フラッシュメモリを有するカード型記憶装置、ＣＤ、ＤＶＤ等に格納され、再生処理が実行される。
【０００３】
記録再生装置、ゲーム機器、ＰＣ等の情報機器には、コンテンツをネットワークから受信するためのインタフェース、あるいはメモリカード、ＨＤ、ＤＶＤ、ＣＤ等にアクセスするためのインタフェースを有し、コンテンツの再生に必要となる制御手段、プログラム、データのメモリ領域として使用されるＲＡＭ、ＲＯＭ等を有する。
【０００４】
音楽データ、画像データ、あるいはプログラム等の様々なコンテンツは、再生機器として利用される記録再生装置、ゲーム機器、ＰＣ等の情報機器本体からのユーザ指示、あるいは接続された入力手段を介したユーザの指示により、例えば内蔵、あるいは着脱自在の記憶媒体から呼び出され、情報機器本体、あるいは接続されたディスプレイ、スピーカ等を通じて再生される。
【０００５】
ゲームプログラム、音楽データ、画像データ等、多くのソフトウエア・コンテンツは、一般的にその作成者、販売者に頒布権等が保有されている。従って、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、ソフトウェアの使用を許諾し、許可のない複製等が行われないようにする、すなわちセキュリティを考慮した構成をとるのが一般的となっている。
【０００６】
また、コンテンツと、コンテンツを利用する利用権とを独立に管理し、ユーザに提供する構成が提案されている。この構成において、ユーザは、例えば暗号化されたコンテンツを取得し、さらに、利用権データを購入することにより、利用権データから取得可能な鍵データ等に基づいて、暗号化コンテンツの復号用の鍵（コンテンツ鍵）を取得して、コンテンツを利用する。
【０００７】
利用権データには、ユーザのコンテンツ利用許可態様の設定情報が格納され、その許可情報において許された範囲でのコンテンツの利用が可能となるといったシステムが提案されている。
【０００８】
【発明が解決しようとする課題】
このように、コンテンツとコンテンツ利用権とを独立に管理し、ユーザに提供するシステムにおいては、コンテンツの利用、例えば音楽データ、画像データの再生、または配信、あるいはダウンロード処理に際して、利用権データのチェックが実行される。
【０００９】
このようなコンテンツ提供システムにおいて、コンテンツのクライアントに対する提供処理は、例えばインターネット等の通信網を介して実行されることになる。しかしながら、音楽データ、画像データの配信処理、ダウンロード処理には、ネットワーク状況、各システムの能力により、多大な時間を要する場合がある。
【００１０】
今後、コンテンツ配信がさらに盛んになれば、ネットワークを介して送受信されるコンテンツは急激に増大し、コンテンツ配信によるネットワークトラフィックの混雑は避けられない。また、特定のコンテンツを要求する多数のクライアントが特定のコンテンツ配信サーバに一時期にアクセスを行なうと、コンテンツ配信サーバからのコンテンツのダウンロードが思うように実行できない事態も発生し得る。
【００１１】
本発明は、このような状況に鑑みてなされたものであり、正規に購入したコンテンツを有するクライアントから、他のクライアントにコンテンツを二次配信することを可能とし、比較的小容量の利用権情報のみを二次配信コンテンツを持つクライアントに提供する構成として、コンテンツサーバからのコンテンツ配信における負荷を減少させ、ネットワークトラフィックの軽減を実現可能とした情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムを提供することを目的とするものである。
【００１２】
【課題を解決するための手段】
本発明の第１の側面は、
暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの複製データを生成する制御手段を有し、
前記制御手段は、
暗号化コンテンツ複製データおよびコンテンツ購入処理可能なショップサーバＵＲＬを格納した二次配信用コンテンツファイルの生成処理を実行する構成を有することを特徴とする情報処理装置にある。
【００１３】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成し、前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルであることを特徴とする。
【００１４】
さらに、本発明の情報処理装置の一実施態様において、前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする。
【００１５】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行する構成であることを特徴とする。
【００１６】
さらに、本発明の情報処理装置の一実施態様において、前記暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする。
【００１７】
さらに、本発明の第２の側面は、
暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの取得処理を実行する制御手段を有し、
前記制御手段は、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理を実行し、格納済みの場合にはコンテンツダウンロード処理を実行せず、未格納の場合にのみコンテンツダウンロード処理を実行する構成を有することを特徴とする情報処理装置にある。
【００１８】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行ない、該設定ファイル名のコンテンツを記憶手段に格納するとともに、コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出し、算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行する構成であることを特徴とする。
【００１９】
さらに、本発明の情報処理装置の一実施態様において、前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、前記制御手段は、前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行する構成であることを特徴とする。
【００２０】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行する構成であることを特徴とする。
【００２１】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行する構成であることを特徴とする。
【００２２】
さらに、本発明の第３の側面は、
二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成方法であり、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とする二次配信コンテンツ生成方法にある。
【００２３】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法は、さらに、前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成するステップを有し、前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルとして生成することを特徴とする。
【００２４】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする。
【００２５】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法は、さらに、記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行するステップを含むことを特徴とする。
【００２６】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法において複製する暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする。
【００２７】
さらに、本発明の第４の側面は、
暗号化コンテンツの取得処理を実行する情報処理方法であり、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とする情報処理方法にある。
【００２８】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行なうファイル名設定ステップと、前記ファイル名設定ステップで設定したファイル名のコンテンツを記憶手段に格納するステップと、コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出するステップと、算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行するステップと、を有することを特徴とする。
【００２９】
さらに、本発明の情報処理方法の一実施態様において、前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、前記情報処理方法は、さらに、前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行するステップを含むことを特徴とする。
【００３０】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行するステップを含むことを特徴とする。
【００３１】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行するステップを含むことを特徴とする。
【００３２】
さらに、本発明の第５の側面は、
二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成処理実行プログラムを記述したコンピュータ・プログラムであって、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００３３】
さらに、本発明の第６の側面は、
暗号化コンテンツの取得処理を実行する情報処理実行プログラムを記述したコンピュータ・プログラムであって、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００３４】
【作用】
本発明の構成によれば、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【００３５】
また、本発明の構成によれば、コンテンツ説明用ファイルをコンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータを保持したファイル構成としたので、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【００３６】
また、本発明の構成によれば、リコメンドファイル中に格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであるので、不正なコンテンツ利用の防止が確実に実行される。
【００３７】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記憶媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００３８】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００３９】
【発明の実施の形態】
以下、本発明の構成について詳細に説明する。なお、説明は、以下に示す各項目に従って行なう。
１．コンテンツ提供システム概要
２．キー配信構成としてのツリー（木）構造について
３．ＥＫＢを使用したキーの配布
４．ＥＫＢのフォーマット
５．ツリーのカテゴリ分類
６．コンテンツ購入および試聴処理
７．バックアップ／リストア処理
８．リコメンドファイルによるコンテンツの二次配信
【００４０】
［１．コンテンツ提供システム概要］
図１は、本発明を適用したコンテンツ提供システムの概要を説明する図である。コンテンツの利用を行なうクライアント１０は、コンテンツを利用、すなわち再生可能な機器としての情報処理装置である。例えばＰＣ、ＰＤＡ等、各種の情報処理装置が含まれる。クライアント１０は、ソフトウェアとしてブラウザ１１、クライアントアプリケーション１２を有し、ＣＰＵ等の制御手段によりブラウザ１１、クライアントアプリケーション１２他のプログラムが実行される。
【００４１】
クライアントアプリケーション１２は、クライアントにおけるコンテンツの購入および試聴処理、後段において説明するサービスデータ、コンテンツ利用権情報を含むライセンス情報の取得処理、コンテンツおよびライセンス情報のバックアップ／リストア処理、コンテンツ利用権の確認処理、コンテンツ再生管理処理、あるいは、二次配信用のコンテンツファイルとしてのリコメンドファイルの生成処理等を実行するアプリケーションであり、以下、詳細に説明する処理プログラムとして、クライアントの情報処理装置に格納される。なお、本明細書においては、「試聴」は、音声データの試聴のみならず、画像データの試写を包含する意味として用いる。
【００４２】
クライアント１０は、例えばインターネット等の通信網を介してショップサーバ２１、ライセンスサーバ２２、およびコンテンツサーバ２３と接続される。コンテンツサーバ２３は、クライアント１０に対してコンテンツを提供する。ライセンスサーバ２２は、クライアントが利用するコンテンツの利用権情報をクライアント１０に対して提供する。また、ショップサーバ２１は、クライアント１０がコンテンツを購入する際の窓口として機能し、購入または試聴可能コンテンツをブラウザを介して提示し、クライアントからの購入あるいは試聴の要求を受け付ける。また、必要に応じて購入コンテンツに関する課金処理を行なう。
【００４３】
さらに、ショップサーバ２１、およびライセンスサーバ２２には、管理システム３１が接続される。管理システム３１は、ショップサーバ２１が受け付けたクライアント１０からのコンテンツ要求に対する許可情報として機能するトランザクションＩＤ（ＴＩＤ）の発行処理、コンテンツダウンロード許可情報の発行処理を行なう。また、管理システム３１は、ライセンスサーバ２２に対して、コンテンツの利用権情報としての利用権データＵｓａｇｅ Ｒｉｇｈｔ）の発行許可を行なう。これらの処理の詳細は、後段で説明する。
【００４４】
なお、クライアント１０は、ライセンスサーバ２２からの利用権の取得、コンテンツサーバ２３からのコンテンツ取得を、クライアントアプリケーション１２の制御の下に実行し、ショップサーバ２１の提供する情報の閲覧および決済処理は、クライアントアプリケーション１２の制御の下にブラウザ１１を起動して実行する。
【００４５】
図１には、クライアントおよび各サーバを１つづつ示してあるが、これらは例えばインターネット等の通信網上に多数接続され、クライアントは、様々なショップサーバに接続し、各ショップサーバで提供するコンテンツを自由に選択し、選択したコンテンツを格納したコンテンツサーバからコンテンツを取得し、取得したコンテンツの利用権を発行するライセンスサーバを選択して、その選択されたライセンスサーバから利用権を取得する。
【００４６】
コンテンツは、暗号化コンテンツとしてコンテンツサーバ２３からクライアント１０に提供される。さらに、ライセンスサーバ２２からクライアント１０に対しては、コンテンツに対応するコンテンツ利用権情報が提供され、クライアント１０のクライアントアプリケーション１２が、利用権情報を検証し、利用権があると判定された場合に暗号化コンテンツを復号して利用する。
【００４７】
クライアント１０は、コンテンツ利用権に基づくコンテンツ利用を可能とするための鍵情報として、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）、デバイス・ノード・キー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）等の鍵データを保持する。有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）、デバイス・ノード・キー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）は、コンテンツの利用を正当なコンテンツ利用権を有するユーザデバイスにおいてのみ暗号化コンテンツを復号して利用可能とするためのコンテンツ利用に必要となる暗号鍵を取得するための鍵データである。ＥＫＢ，ＤＮＫについては、後段で説明する。
【００４８】
コンテンツサーバ２３は、コンテンツを暗号化して、暗号化コンテンツをクライアント１０に提供する。さらに、ライセンスサーバ２２は、コンテンツ利用条件に基づいて利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成してユーザデバイス３０に提供する。さらに、管理システム３１の提供するデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）に基づいてサービスデータを生成してクライアント１０に提供する。サービスデータは、暗号化コンテンツの復号処理の際に必要となるサービス・デバイスノードキー（ＳＤＮＫ）を持つ有効化キーブロック（ＥＫＢ）を含む。
【００４９】
なお、コンテンツの利用条件には、利用期間の限定条件、コピーの回数制限、さらにコンテンツを同時に利用することができるポータブルメディア（ＰＭ：Ｐｏｒｔａｂｌｅ Ｍｅｄｉａ）の数（いわゆるチェックアウト（Ｃｈｅｃｋ−ｏｕｔ）数に対応）の制限等がある。ポータブルメディア（ＰＭ：Ｐｏｒｔａｂｌｅ Ｍｅｄｉａ）は例えばフラッシュメモリ、または小型ＨＤ、光ディスク、光磁気ディスク、ＭＤ（Ｍｉｎｉ Ｄｉｓｋ）等、ポータブルデバイスにおいて利用可能な記憶媒体である。
【００５０】
次に、図２を参照して、クライアント１０、ショップサーバ２１、ライセンスサーバ２２、コンテンツサーバ２３、管理システム３１として機能可能な情報処理装置の構成例を示す。これらの各システムはＣＰＵを持つ例えばＰＣ、サーバ等のシステムにそれぞれの処理に応じた処理プログラムを格納することで実現される。
【００５１】
まず、図２を用いて各システムの構成例について説明する。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２に記憶されている各種プログラム、あるいは、記憶部１０８に格納され、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３にロードされたプログラムに従って各種処理を実行する。タイマ１００は計時処理を行ない、クロック情報をＣＰＵ１０１に供給する。
【００５２】
ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２は、ＣＰＵ１０１が使用するプログラムや演算用のパラメータ、固定データ等を格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３は、ＣＰＵ１０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を格納する。これら各素子はＣＰＵバスなどから構成されるバス１１１により相互に接続されている。
【００５３】
暗号化復号部１０４は、コンテンツの暗号化、復号処理、デバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）の適用処理として、例えばＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）の暗号化アルゴリズムを適用した暗号処理、ＭＡＣ生成、検証処理等を実行する。さらに、他の接続装置との間で実行されるコンテンツあるいはライセンス情報の送受信時の認証およびセッションキー共有処理等、各種暗号処理を実行する。
【００５４】
コーデック部１０５は、例えばＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）３方式、ＭＰＥＧ、ＪＰＥＧ方式等、各種方式のデータエンコード処理、デコード処理を実行する。処理対象データは、バス１１１、入出力インタフェース１１２、ドライブ１１０を介してリムーバブル記憶媒体１２１からまたは通信部１０９を介して入力する。また処理後のデータは、必要に応じて、リムーバブル記憶媒体１２１に格納し、または通信部１０９を介して出力する。
【００５５】
入出力インタフェース１１２には、キーボード、マウス等の入力部１０６、ＣＲＴ、ＬＣＤ等のディスプレイ、スピーカ等からなる出力部１０７、ハードディスク等の記憶部１０８、モデム、ターミナルアダプタ等によって構成される通信部１０９が接続され、例えばインターネット等の通信網を介したデータ送受信を行なう。
【００５６】
［２．キー配信構成としてのツリー（木）構造について］
次に、正当なコンテンツ利用権を有するクライアントにおいてのみコンテンツを利用可能とするための、ブロードキャストエンクリプション（Ｂｒｏａｄｃａｓｔ Ｅｎｃｒｙｐｔｉｏｎ）方式の一態様であるツリー構成によるデバイスとキーの管理構成について説明する。
【００５７】
図３の最下段に示すナンバ０〜１５がコンテンツ利用を行なうクライアントとしてのユーザデバイスである。すなわち図３に示す階層ツリー（木）構造の各葉（リーフ：ｌｅａｆ）がそれぞれのデバイスに相当する。
【００５８】
各デバイス０〜１５は、製造時あるいは出荷時、あるいはその後において、図３に示す階層ツリー（木）構造における自分のリーフからルートに至るまでのノードに割り当てられた鍵（ノードキー）および各リーフのリーフキーからなるキーセット（デバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ））をメモリに格納する。図３の最下段に示すＫ００００〜Ｋ１１１１が各デバイス０〜１５にそれぞれ割り当てられたリーフキーであり、最上段のＫＲ（ルートキー）から、最下段から２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１１をノードキーとする。
【００５９】
図３に示すツリー構成において、例えばデバイス０はリーフキーＫ００００と、ノードキー：Ｋ０００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ１、ＫＲを所有する。なお、図３のツリーにはデバイスが０〜１５の１６個のみ記載され、ツリー構造も４段構成の均衡のとれた左右対称構成として示しているが、さらに多くのデバイスがツリー中に構成され、また、ツリーの各部において異なる段数構成を持つことが可能である。
【００６０】
また、図３のツリー構造に含まれる各デバイスには、様々な記録媒体、例えば、デバイス埋め込み型あるいはデバイスに着脱自在に構成されたＤＶＤ、ＣＤ、ＭＤ、フラッシュメモリ等を使用する様々なタイプのデバイスが含まれている。さらに、様々なアプリケーションサービスが共存可能である。このような異なるデバイス、異なるアプリケーションの共存構成の上に図３に示すコンテンツあるいは鍵配布構成である階層ツリー構造が適用される。
【００６１】
これらの様々なデバイス、アプリケーションが共存するシステムにおいて、例えば図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を同一の記録媒体を用いる１つのグループとして設定する。例えば、この点線で囲んだグループ内に含まれるデバイスに対しては、まとめて、共通のコンテンツを暗号化してプロバイダから送付したり、各デバイス共通に使用するコンテンツキーを送付したり、あるいは各デバイスからプロバイダあるいは決済機関等にコンテンツ料金の支払データをやはり暗号化して出力するといった処理が実行される。コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等、各デバイスとのデータ送受信を行なう機関は、図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を１つのグループとして一括してデータを送付する処理を実行する。このようなグループは、図３のツリー中に複数存在する。コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等、各デバイスとのデータ送受信を行なう機関は、メッセージデータ配信手段として機能する。
【００６２】
なお、ノードキー、リーフキーは、ある１つの鍵管理センター機能を持つ管理システムによって統括して管理してもよいし、各グループに対する様々なデータ送受信を行なうプロバイダ、決済機関等のメッセージデータ配信手段によってグループごとに管理する構成としてもよい。これらのノードキー、リーフキーは例えばキーの漏洩等の場合に更新処理が実行され、この更新処理は鍵管理センター機能を持つ管理システム、プロバイダ、決済機関等が実行する。
【００６３】
このツリー構造において、図３から明らかなように、１つのグループに含まれる３つのデバイス０，１，２，３はデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）として共通のキーＫ００、Ｋ０、ＫＲを含むデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）を保有する。このノードキー共有構成を利用することにより、例えば共通のキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００は、デバイス０，１，２，３に共通する保有キーとなる。また、新たなキーＫｎｅｗをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｎｅｗ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｎｅｗ）を解いて新たなキーＫｎｅｗを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【００６４】
また、ある時点ｔにおいて、デバイス３の所有する鍵：Ｋ００１１，Ｋ００１，Ｋ００，Ｋ０，ＫＲが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキー：Ｋ００１，Ｋ００，Ｋ０，ＫＲをそれぞれ新たな鍵Ｋ（ｔ）００１，Ｋ（ｔ）００，Ｋ（ｔ）０，Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Ｇｅｎｅｒａｔｉｏｎ）：ｔの更新キーであることを示す。
【００６５】
更新キーの配布処理ついて説明する。キーの更新は、例えば、図４（Ａ）に示す有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）と呼ばれるブロックデータによって構成されるテーブルをたとえばネットワーク、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図３に示すようなツリー構造を構成する各リーフに対応するデバイスに新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Ｋｅｙ Ｒｅｎｅｗａｌ Ｂｌｏｃｋ）と呼ばれることもある。
【００６６】
図４（Ａ）に示す有効化キーブロック（ＥＫＢ）には、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図４の例は、図３に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図３から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
【００６７】
図４（Ａ）のＥＫＢに示されるようにＥＫＢには複数の暗号化キーが含まれる。最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーによってこの暗号化キーを復号し、Ｋ（ｔ）００１を得ることができる。また、復号により得たＫ（ｔ）００１を用いて、図４（Ａ）の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）を復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。以下順次、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。一方、デバイスＫ００００．Ｋ０００１は、ノードキーＫ０００は更新する対象に含まれておらず、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。デバイスＫ００００．Ｋ０００１は、図４（Ａ）の上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号しＫ（ｔ）００、を取得し、以下、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新した鍵Ｋ（ｔ）Ｒを得ることができる。なお、図４（Ａ）のインデックスは、復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
【００６８】
図３に示すツリー構造の上位段のノードキー：Ｋ（ｔ）０，Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図４（Ｂ）の有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
【００６９】
図４（Ｂ）に示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図３に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキー：Ｋ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ），Ｋ（ｔ）ｃｏｎ）を図４（Ｂ）に示すＥＫＢとともに配布する。この配布により、デバイス４など、その他のグループの機器においては復号されないデータとしての配布が可能となる。
【００７０】
すなわち、デバイス０，１，２はＥＫＢを処理して得たＫ（ｔ）００を用いて上記暗号文を復号すれば、ｔ時点でのキー、例えばコンテンツの暗号化復号化に適用するコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
【００７１】
［３．ＥＫＢを使用したキーの配布］
図５に、ｔ時点でのキー、例えばコンテンツの暗号化復号化に適用するコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と図４（Ｂ）に示すＥＫＢとを記録媒体を介して受領したデバイス０の処理例を示す。すなわちＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【００７２】
図５に示すように、デバイス０は、記録媒体に格納されている世代：ｔ時点のＥＫＢと自分があらかじめ格納しているノードキーＫ０００を用いて上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、復号した更新ノードキーＫ（ｔ）００を用いて更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
【００７３】
［４．ＥＫＢのフォーマット］
図６に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン２０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは最新のＥＫＢを識別する機能とコンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ２０３は、有効化キーブロック（ＥＫＢ）中のデータ部の位置を示すポインタであり、タグポインタ２０４はタグ部の位置、署名ポインタ２０５は署名の位置を示すポインタである。
【００７４】
データ部２０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図５に示すような更新されたノードキーに関する各暗号化キー等を格納する。
【００７５】
タグ部２０７は、データ部に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図７を用いて説明する。図７では、データとして先に図４（Ａ）で説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図７の表（ｂ）に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはＫＲとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図７の（ａ）に示す階層ツリーに示す位置にある。ここで、次のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置にある。データがある場合は、タグが０、ない場合は１が設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）の左にはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図７（ｃ）に示すデータ列、およびタグ列が構成される。
【００７６】
タグは、データＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）がツリー構造のどこに位置しているのかを示すために設定されるものである。データ部に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）．．．は、単純に暗号化されたキーの羅列データに過ぎないので、上述したタグによってデータとして格納された暗号化キーのツリー上の位置を判別可能としたものである。上述したタグを用いずに、先の図４で説明した構成のように暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（Ｔ）００）
．．．のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
【００７７】
図６に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Ｓｉｇｎａｔｕｒｅ）２０８は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センター機能を持つ管理システム、コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等が実行する電子署名である。ＥＫＢを受領したデバイスは署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
【００７８】
［５．ツリーのカテゴリ分類］
ノードキー等を定義している階層ツリー構造を各デバイスのカテゴリ毎に分類して効率的なキー更新処理、暗号化キー配信、データ配信を実行する構成について、以下説明する。
【００７９】
図８に階層ツリー構造のカテゴリの分類の一例を示す。図８において、階層ツリー構造の最上段には、ルートキーＫｒｏｏｔ３０１が設定され、以下の中間段にはノードキー３０２が設定され、最下段には、リーフキー３０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーを保有する。
【００８０】
ここで、一例として最上段から第Ｍ段目のあるノードをカテゴリノード３０４として設定する。すなわち第Ｍ段目のノードの各々を特定カテゴリのデバイス設定ノードとする。第Ｍ段の１つのノードを頂点として以下、Ｍ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとする。
【００８１】
例えば図８の第Ｍ段目の１つのノード３０５にはカテゴリ［メモリステッイク（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード３０５以下を、メモリスティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義する。
【００８２】
さらに、Ｍ段から数段分下位の段をサブカテゴリノード３０６として設定することができる。例えば図に示すようにカテゴリ［メモリスティック］ノード３０５の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノードを設定する。さらに、サブカテゴリノードである再生専用器のノード３０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード３０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード３０８と［携帯電話］ノード３０９を設定することができる。
【００８３】
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺにその頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
【００８４】
このように、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
【００８５】
本発明のシステムにおいては、図９に示されるように、ツリー構成のシステムで、キーの管理が行われる。図９の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリスティックなどの半導体メモリを使用する機器のカテゴリ、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、ライセンスを管理するシステムとして本システム（Ｔシステムと称する）が対応する。
【００８６】
すなわち、このＴシステムのノードよりさらに下の階層の２４段のノードに対応するキーが、サービスプロバイダ、あるいはサービスプロバイダが提供するサービスに適用される。この例の場合、これにより、２２４（約１６メガ）のサービスプロバイダあるいはサービスを規定することができる。さらに、最も下側の３２段の階層により、２３２（約４ギガ）のユーザ（あるいはユーザデバイス）を規定することができる。最下段の３２段のノードからＴシステムのノードまでのパス上の各ノードに対応するキーが、ＤＮＫ（Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）を構成し、最下段のリーフに対応するＩＤがリーフＩＤとされる。
【００８７】
例えば、コンテンツを暗号化したコンテンツキーは更新されたルートキーＫＲ’によって暗号化され、上位の階層の更新ノードキーは、その直近の下位の階層の更新ノードキーを用いて暗号化され、ＥＫＢ内に配置される。ＥＫＢにおける末端から１つ上の段の更新ノードキーはＥＫＢの末端のノードキーあるいはリーフキーによって暗号化され、ＥＫＢ内に配置される。
【００８８】
ユーザデバイスは、サービスデータに記述されているＤＮＫのいずれかのキーを用いて、コンテンツデータとともに配布されるＥＫＢ内に記述されている直近の上位の階層の更新ノードキーを復号し、復号して得たキーを用いて、ＥＫＢ内に記述されているさらにその上の階層の更新ノードキーを復号する。以上の処理を順次行うことで、ユーザデバイスは、更新ルートキーＫＲ’を得ることができる。
【００８９】
上述したように、ツリーのカテゴリ分類により、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定した構成が可能となり、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、サービスプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が実現される。
【００９０】
さらに、上述のツリー構成のデバイス管理によるＥＫＢ配信システムを適用して、複数のカテゴリに基づくＥＫＢ配信構成を採用したコンテンツ配信および利用形態について説明する。
【００９１】
図１０を参照して２つのカテゴリについて説明する。図１０に示すように、ルートノード３５０の下段にＴシステムノード３５１を設定し、その下段にＴサービスノード３５２、およびＴハードノード３５３を設定する。Ｔハードノード３５３を頂点としたツリーは、ユーザデバイス機器自体をリーフ３５５として設定し、機器を対象として発行するハード対応ＥＫＢ［ＥＫＢ（Ｈ）］を配信するカテゴリツリーである。一方、Ｔサービスノード３５２を頂点としたツリーは、ユーザデバイス機器に提供するサービスに対応して発行するサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を配信するカテゴリツリーである。
【００９２】
ハード対応ＥＫＢ［ＥＫＢ（Ｈ）］、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］とも、それぞれ正当な権限を持つデバイスに対して与えられるＤＮＫ（Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）すなわち、リーフからＴシステムのノードまでのパス上の各ノードに対応するキーを有することで、各ＥＫＢの復号が可能となる。
【００９３】
［６．コンテンツ購入および試聴処理］
次に、クライアントがコンテンツを購入または試聴する際の処理の詳細について、図１１以下を参照して説明する。
【００９４】
図１１は、クライアントアプリケーション、ブラウザを有するＰＣ等のクライアントと、ショップサーバ、コンテンツサーバ、ライセンスサーバ、および管理システムとの間で実行されるコンテンツ購入処理における通信シーケンスの初期ステップを示している。以下、シーケンス図に示す処理について説明する。
【００９５】
まず、クライアント側において、コンテンツの購入を行なおうとするユーザは、自己のＰＣ等の通信可能な情報処理装置にＵＲＬを指定（ステップ（１））し、ブラウザが介してショップサーバの提示するコンテンツリスト画面（ショップページ）を読み出し（ステップ（２））て、ディスプレイに表示（ステップ（３））する。
【００９６】
クライアントは、ショップサーバの提示するコンテンツリストからコンテンツを選択して、さらに、購入または試聴どちらかの指定（ステップ（４））を行なって、ブラウザを介してショップサーバに要求データを送信（ステップ（５））する。要求データには、コンテンツＩＤ（ＣＩＤ）、ショップサーバ識別子（ＳｈｏｐＩＤ）、および購入または試聴どちらかの指定データが含まれる。
【００９７】
ショップサーバは、クライアントからのコンテンツ購入、または試聴要求を受信すると、管理システムに対して、コンテンツの提供の可否判定を要求（ステップ（６））する。この判定要求には、コンテンツＩＤ（ＣＩＤ）、ショップサーバ識別子（ＳｈｏｐＩＤ）が含まれる。
【００９８】
管理システムは、コンテンツの提供の可否判定要求を受信すると、トランザクションＩＤ（ＴＩＤ）の発行処理（ステップ（７））を実行する。トランザクションＩＤ（ＴＩＤ）の発行処理の詳細を図１２のフローを参照して説明する。
【００９９】
管理システムは、まず、ステップＳ１０１において、乱数を発生し、発生乱数に基づいて、トランザクションＩＤ（ＴＩＤ）を生成する。次に、ステップＳ１０２において、生成したトランザクションＩＤ（ＴＩＤ）と、ショップサーバから指定されたコンテンツＩＤ（ＣＩＤ）とを対応付けてトランザクションデータとして記憶部に格納する。次に、生成したトランザクションＩＤ（ＴＩＤ）をショップサーバに対して出力、発行する。
【０１００】
図１１のシーケンス図に戻る。管理システムは、トランザクションＩＤ（ＴＩＤ）の生成後、生成したトランザクションＩＤ（ＴＩＤ）と価格情報をＴＩＤ情報としてショップサーバに送信（ステップ（８））する。ただし、価格情報は、コンテンツ購入時においてのみ要求される情報であり、コンテンツ試聴処理に際しては、含まれない。ＴＩＤ情報を受信したショップサーバは、クライアントからの要求がコンテンツ購入である場合に、ＴＩＤ情報に含まれる価格に基づいて、課金処理（ステップ（９））を実行する。
【０１０１】
クライアントからの要求がコンテンツ購入ではなく、コンテンツ試聴要求である場合には、この課金処理（ステップ（９））は省略される。
【０１０２】
次に、図１３のシーケンス図を参照して継続する処理について説明する。ショップサーバは、コンテンツ購入処理においては、課金が実行されたことを条件として、またコンテンツ試聴処理においては、管理システムからのＴＩＤ情報の受信を条件として、購入または試聴要求対象のコンテンツのダウンロード許可要求を管理システムに対して送信（ステップ（１０））する。
【０１０３】
管理システムは、ダウンロード許可要求を受信すると、ダウンロード許可要求検証処理（ステップ（１１））を実行する。ダウンロード許可要求検証処理の詳細を図１４のフローを参照して説明する。
【０１０４】
管理システムは、まず、ステップＳ２０１において、受信したダウンロード許可要求に含まれるトランザクションＩＤ（ＴＩＤ）と、先に生成し、記憶部に格納したトランザクションＩＤ（ＴＩＤ）とを照合し、さらにステップＳ２０２において、照合の成立したトランザクションＩＤ（ＴＩＤ）に対応して記録されたコンテンツＩＤ（ＣＩＤ）を取得し、ステップＳ２０３において、ＣＩＤに対応するコンテンツのダウンロード許可を発行する。
【０１０５】
図１３のシーケンス図に戻り、説明を続ける。管理システムは、ダウンロード許可要求検証処理（ステップ（１１））の後、コンテンツのダウンロード許可をショップサーバに対して発行（ステップ（１２））する。ダウンロード許可には、トランザクションＩＤ（ＴＩＤ）、コンテンツサーバＵＲＬ（Ｃ−ＵＲＬ）、ライセンスサーバＵＲＬ（Ｌ−ＵＲＬ）、コンテンツＩＤ（ＣＩＤ）、利用権情報ＩＤ（ＵＩＤ）、商品（コンテンツ）ＵＲＬ（Ｓ−ＵＲＬ）、サービスＩＤが含まれる。
【０１０６】
ショップサーバは、管理システムからダウンロード許可を受信すると、クライアントアプリケーションにおけるコンテンツの利用（再生処理等）プログラムを起動させるための起動ファイルを生成してクライアントのブラウザを介してクライアントアプリケーションに対して送付する。
【０１０７】
起動ファイルの例を図１５を参照して説明する。起動ファイル３６０は、先に管理システムが生成したトランザクションＩＤ（ＴＩＤ）、クライアントが購入あるいは試聴するコンテンツＩＤ（ＣＩＤ）、管理システムが生成したダウンロード許可情報に含まれる利用権情報ＩＤ（ＵＩＤ）、管理システムが生成したダウンロード許可情報に含まれるサービスＩＤ、ライセンスサーバＵＲＬ、商品（コンテンツ）ＵＲＬ、さらに、処理が購入であるか試聴であるかの識別データが含まれる。
【０１０８】
なお、処理が購入であるか試聴であるかの識別データとしては、起動ファイルに設定される拡張子を購入であるか試聴であるかによって区別して設定し、これをクライアントアプリケーションが判別して、それぞれのアプリケーションを起動するようにしてもよい。
【０１０９】
クライアントアプリケーションは、起動ファイルに応じて、アプリケーションを起動（ステップ（１５））する。
【０１１０】
クライアントアプリケーションにおいて実行するアプリケーション起動処理について、図１６を参照して説明する。ステップＳ３０１において、まず、起動ファイルに設定されたサービスＩＤ対応のサービスデータをクライアントシステムとしての情報処理装置に格納されているか否かを判定する。
【０１１１】
サービスデータは、クライアントが各種のサービス、例えばコンテンツ利用サービスを受領したい場合、ライセンスサーバから受領するもので、例えば特定のサービスプロバイダの提供サービスの一括したサービス利用権を認めるデータである。図１７（ａ）にサービスデータのデータ構成例を示す。
【０１１２】
図１７（ａ）に示すように、サービスデータ３７０には、ＥＫＢ配信ツリーにおいて設定されるクライアントに固有のリーフＩＤ、サービス識別子としてのサービスＩＤ、さらにデバイスノードキー（ＤＮＫ）をルートキー（Ｋｒｏｏｔ）で暗号化したデータ、Ｅ（Ｋｒｏｏｔ，ＤＮＫ）が含まれる。サービスデータを受領するためには、クライアントは、ライセンスサーバに対する登録処理が必要とされる。登録処理は、図１３に示す処理ステップ（１５）、（１６）の処理に対応する。
【０１１３】
図１６に示すステップＳ３０１において、サービスＩＤ対応のサービスデータを保有していないと判定すると、ステップＳ３０２において登録処理を実行して、サービスデータを受領する。
【０１１４】
さらに、この登録処理時に、デフォルト利用権情報がライセンスサーバからクライアントに対して発行される。利用権情報は、通常は、購入コンテンツの利用条件を格納し、コンテンツの購入に対応して発行されるものであるが、デフォルト利用権情報は、コンテンツの購入を条件として発行するものではなく、クライアントの登録処理、あるいはサービスデータの発行処理を条件として発行する。このデフォルト利用権情報は、後段で説明するコンテンツの試聴処理の際の有効なコンテンツ利用権情報として適用される。
【０１１５】
図１７（ｂ）に利用権情報のデータ構成例を示す。図１７（ｂ）に示すように、利用権情報３７１には、利用権情報識別子としての利用権情報ＩＤ、発行日時情報としてのタイムスタンプ、クライアントに固有のリーフＩＤ、コンテンツ対応である場合は、コンテンツＩＤ、さらに、利用条件対象コンテンツ種別情報が格納される。
【０１１６】
デフォルト利用権情報の場合は、特定の購入コンテンツに対応して発行されるものではないため、コンテンツＩＤは省略、あるいは試聴可能なコンテンツに共通なＩＤが設定される。また、利用条件対象コンテンツ種別情報として、例えば試聴フラグがオン（ＯＮ）として設定されたコンテンツについての利用が許可される設定とする。コンテンツ３７２には図１７（ｃ）に示すように、試聴フラグ３７３が設定され、試聴フラグ３７３がオン（ＯＮ）の設定コンテンツであれば、試聴が許可されたコンテンツであることを示し、試聴フラグがオフ（ＯＦＦ）の設定コンテンツであれば、試聴が許可されていないコンテンツであることを示す。
【０１１７】
クライアントアプリケーションは、試聴コンテンツ再生時には、デフォルト利用権情報を参照して、再生許可の有無を判定するとともに、コンテンツのフラグの検証を実行して、コンテンツの再生を行なうことになる。この処理については、後段で説明する。
【０１１８】
図１６の処理フローに戻りアプリケーション起動処理の処理手順について説明する。ステップＳ３０２において、登録処理、すなわちライセンスサーバからのサービスデータ、デフォルト利用権情報の取得が終了すると、ステップＳ３０３において、ショップサーバから受信した起動ファイルが、購入用アプリケーションの起動ファイルであるか、試聴用アプリケーションの起動ファイルであるかを判別する。購入用アプリケーションの起動ファイルである場合は、ステップＳ３０４に進み購入用アプリケーションを実行し、試聴用アプリケーションの起動ファイルである場合は、ステップＳ３０５に進み試聴用アプリケーションを実行する。
【０１１９】
次に、購入用アプリケーションの実行シーケンスについて、図１８のシーケンス図を参照して説明する。
【０１２０】
購入処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（２１））する。これは、先にクライアントが購入要求を行なったコンテンツであり、利用権情報（図１７（ｂ）参照）に記録されたコンテンツＩＤ（ＣＩＤ）に対応するコンテンツである。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１２１】
コンテンツサーバは、コンテンツダウンロード要求を受信すると、ＣＩＤに対応するコンテンツ情報をクライアントに送信（ステップ（２２））する。このコンテンツ情報は、暗号化コンテンツを含み、図１７（ｃ）に示すように、コンテンツキー：Ｋｃで暗号化されたコンテンツデータ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキー：Ｋｃをルートキー：Ｋｒｏｏｔで暗号化したデータ：Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）、さらに：ルートキー：Ｋｒｏｏｔを取得するためのＥＫＢ、さらに試聴フラグデータ、サービスＩＤ等の情報が付加されたファイルである。
【０１２２】
コンテンツ情報を受領したクライアントは、受信コンテンツに対応する利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求をライセンスサーバに対して送信（ステップ（２３））する。この要求には、先にショップサーバから受領した起動ファイル（図１５参照）中に含まれる利用権情報ＩＤ（ＵＩＤ）、クライアント識別データとしてのリーフＩＤ、および先にショップサーバから受領した起動ファイル（図１５参照）中に含まれるトランザクションＩＤ（ＴＩＤ）が含まれる。
【０１２３】
ライセンスサーバは、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求を受信すると、管理システムに対して、注文照会処理（ステップ（２４））を行なう。この要求には、利用権情報ＩＤ（ＵＩＤ）、トランザクションＩＤ（ＴＩＤ）が含まれる。注文照会を受信した管理サーバは、注文照会応答として、利用権情報ＩＤ（ＵＩＤ）に対応する利用条件を設定した応答情報をライセンスサーバに送信（ステップ（２５））する。
【０１２４】
応答情報を受信したライセンスサーバは、コンテンツ利用条件を設定した利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成して、クライアントに対して発行（ステップ（２６））する。なお、コンテンツ利用条件とは、コンテンツの再生回数、期限、外部機器に対するコピー、チェツクアウト処理等の各種処理の許可情報によって構成される。
【０１２５】
利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を受信したクライアントは、先にコンテンツサーバから受信したコンテンツについて、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）に記録された利用条件に基づいてコンテンツの利用が可能となる。ユーザからコンテンツＩＤ（ＣＩＤ）、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）ＩＤを指定したコンテンツ再生要求（ステップ（２７））があると、クライアントアプリケーションは、利用条件に従ったコンテンツ再生を実行（ステップ（２８））する。
【０１２６】
基本的なコンテンツ再生処理の手順について、図１９を参照して説明する。前述の説明から理解されるように、コンテンツサーバ３８２からクライアント３８３に対してコンテンツが提供されるとともに、ライセンスサーバ３８１からクライアント３８３にライセンスとして、サービスデータ、利用権情報（ＵｓａｇｅＲｉｇｈｔ）が与えられる。
【０１２７】
コンテンツは、コンテンツキー：Ｋｃにより、暗号化されており（Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキーＫｃは、ＥＫＢから取得可能なルートキーＫｒｏｏｔから得られるキーである。
【０１２８】
クライアント３８３は、ライセンスサーバから受領したサービスデータからデバイスノードキー（ＤＮＫ）を取得し、取得したＤＮＫに基づいてコンテンツファイルのＥＫＢを復号して、ルートキー：Ｋｒｏｏｔを取得し、さらに、取得したルートキー：Ｋｒｏｏｔを用いて、Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）を復号してコンテンツキー：Ｋｃを取得し、取得したコンテンツキー：Ｋｃをにより暗号化コンテンツ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）の復号処理を実行してコンテンツを取得し、再生する。
【０１２９】
サービスデータ、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）と対応付けたコンテンツ再生処理の詳細について、図２０を参照して説明する。
【０１３０】
図２０は、ハード対応ＥＫＢ［ＥＫＢ（Ｈ）］、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を適用したコンテンツの復号処理に基づくコンテンツ利用処理シーケンスを説明した図である。
【０１３１】
図２０に示すサービスデータ４０１、および利用権情報４０３は、ライセンスサーバカラ受領するデータであり、暗号化コンテンツファイル４０２はコンテンツサーバから受領するデータである。サービスデータ４０１は、リーフ識別子としてのリーフＩＤ、適用するＥＫＢのバージョン、さらに、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の復号に必要なサービス対応デバイスノードキー（ＳＤＮＫ）を、ハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’によって暗号化したデータＥ（Ｋｒｏｏｔ’，ＳＤＮＫ）を格納している。
【０１３２】
暗号化コンテンツファイル４０２は、サービス対応のカテゴリツリーに対応して設定されるルートキーＫｒｏｏｔを格納したサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］、ルートキーＫｒｏｏｔでコンテンツＩＤ（ＣＩＤ）と、コンテンツ暗号処理および復号処理に適用するコンテンツキー（Ｋｃ）とを暗号化したデータＥ（Ｋｒｏｏｔ，ＣＩＤ＋Ｋｃ）、および、コンテンツ（Ｃｏｎｔｅｎｔ）をコンテンツキーＫｃで暗号化したデータＥ（Ｋｃ，Ｃｏｎｔｅｔ）を含むファイルである。
【０１３３】
また、利用権情報４０３は、リーフＩＤと、コンテンツの利用条件情報を格納したデータである。コンテンツの利用条件情報には、コンテンツに対応して設定される利用期間、利用回数、コピー制限等の様々な利用条件が含まれる。利用権情報４０３を受領したユーザデバイスは、利用権情報をコンテンツに対応するセキュリティ情報として格納するか、あるいは、コンテンツの索引データとしてのＡＶインデックスファイル内に格納する。
【０１３４】
例えば、ＰＣ等の大容量の記憶手段を有し、プロセッサ等の処理能力が高いユーザデバイスにおいては、利用権情報をコンテンツに対応するセキュリティ情報として格納することが可能であり、すべての利用権情報を格納して、コンテンツ利用の際にすべての利用権情報を参照した処理を行なうことが好ましい。一方、大容量の記憶手段を持たず、またプロセッサ等の処理能力が低いポータブルデバイス（ＰＤ）等のユーザデバイスにおいては、選択された情報からなる利用権情報４０３をコンテンツの索引データとしてのＡＶインデックスファイル内に格納して、コンテンツ利用の際にＡＶインデックスファイル内の利用条件情報を参照した処理を行なう等の処理が可能である。
【０１３５】
ユーザデバイスは、図２０に示すステップＳ５０１において、ハード対応のデバイスノードキー（ＨＤＮＫ）４１２を適用して、ハード対応のＥＫＢ（Ｈ）４１１の復号処理を実行し、ＥＫＢ（Ｈ）４１１から、ハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’を取得する。ＤＮＫを適用したＥＫＢの処理は、先に図５を参照して説明した手法に従った処理となる。
【０１３６】
次に、ステップＳ５０２において、ＥＫＢ（Ｈ）から取り出したルートキーＫｒｏｏｔ’を用いて、サービスデータ４０１内の暗号化データＥ（Ｋｒｏｏｔ’，ＳＤＮＫ）の復号処理を実行し、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の処理（復号）に適用するデバイスノードキー（ＳＤＮＫ）を取得する。
【０１３７】
次に、ステップＳ５０３において、サービスデータから取り出したデバイスノードキー（ＳＤＮＫ）を用いて、暗号化コンテンツファイル４０２内に格納されたサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の処理（復号）を実行し、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］内に格納されたサービス対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔを取得する。
【０１３８】
次に、ステップＳ５０４において、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］から取り出したルートキーＫｒｏｏｔを用いて、暗号化コンテンツファイル４０２内に格納された暗号化データＥ（Ｋｒｏｏｔ，ＣＩＤ＋Ｋｃ）の復号処理を実行し、コンテンツＩＤ（ＣＩＤ）と、コンテンツキー（Ｋｃ）を取得する。
【０１３９】
次に、ステップＳ５０５において、暗号化コンテンツファイル４０２から取り出したコンテンツＩＤ（ＣＩＤ）と、利用権情報内に格納されたコンテンツＩＤのマッチング（照合）処理を実行する。マッチング処理により、コンテンツの利用が可能であることが確認されると、ステップＳ５０６において、暗号化コンテンツファイル４０２から取り出したコンテンツキー（Ｋｃ）を適用して、暗号化コンテンツファイル４０２に格納された暗号化コンテンツＥ（Ｋｃ，Ｃｏｎｔｅｎｔ）を復号してコンテンツの再生を行なう。
【０１４０】
上述したように、コンテンツ利用機器としてのハードウェアに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのハード対応ＥＫＢ［ＥＫＢ（Ｈ）］と、コンテンツ利用サービスに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］をそれぞれ個別にユーザに対して提供し、それぞれのＥＫＢに対する正当なＤＮＫを有するユーザのみがサービスの利用を行なうことが可能となる。
【０１４１】
サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を復号するためのＤＮＫ、すなわちＳＤＮＫは、コンテンツに対応したサービスデータ４０１として提供可能であり、またＳＤＮＫを正当なハードウェア対応のＤＮＫ、すなわちＨＤＮＫを有する機器のみが取得可能なハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’を適用して暗号化した構成としたので、正当なＨＤＮＫを有するユーザデバイスのみが、ＳＤＮＫを取得でき、サービスが利用となる。
【０１４２】
また、コンテンツ利用において、暗号化コンテンツファイル４０２から取得されるコンテンツ識別子（ＣＩＤ）と、利用権情報から取得されるＣＩＤとのマッチング処理を実行する構成としたので、利用権情報４０３を取得してＣＩＤ情報を格納していることがコンテンツ再生プロセスの必須用件とすることが可能となり、利用条件に従ったコンテンツ利用が実現される。
【０１４３】
次に、クライアントアプリケーションの処理が試聴処理の実行アプリケーションである場合の処理について、図２１のシーケンス図を参照して説明する。
【０１４４】
試聴処理の場合、コンテンツ購入処理と同様、コンテンツ情報ファイル（図１９参照）を取得してクライアントシステムの記憶部に格納し、その後、購入コンテンツと同様の処理によって再生することも可能であるが、記憶部に格納することなく、ストリーミング再生処理を実行する例について、図２１を参照して説明する。
【０１４５】
ストリーミング試聴処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（３１））する。これは、先にクライアントが試聴要求を行なったコンテンツである。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１４６】
コンテンツサーバは、ストリーミング再生の場合には、コンテンツの部分データ（コンテンツパート）を次々にクライアントに対して送信（ステップ（３２））する。コテンツパートを受信したクライアントは、受信コンテンツに対する再生処理を実行（ステップ（３３））し、後続のコンテンツパートの要求をコンテンツサーバに送信する。この処理を連続して実行することによりストリーミング再生が行なわれる。
【０１４７】
試聴再生処理の手順について、図２２のフローを参照して説明する。ステップＳ７０１において、クライアントアプリケーションは、コンテンツサーバから受信した試聴コンテンツファイル中からサービスＩＤを取得する。
【０１４８】
次にステップＳ７０２において、抽出したサービスＩＤに対応するデフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）（図１７（ｂ）参照）の有無を判定する。デフォルト利用権情報は、クライアントの登録処理時に、サービスデータ（図１７（ａ）参照）とともに、ライセンスサーバから送信される利用権情報であり、購入コンテンツに対応して発行される利用権情報と異なり、試聴可能なコンテンツに対して利用される利用権情報である。
【０１４９】
コンテンツ試聴においては、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）を保有することが試聴実行許可条件であり、デフォルト利用権情報を保有していない場合は、ステップＳ７０５に進み、エラーとしてコンテンツ再生が実行されず処理を終了する。
【０１５０】
デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）が格納されている場合は、ステップＳ７０３において、デフォルト利用権情報を検証し、利用権情報の記録を確認する。デフォルト利用権情報には、例えば試聴フラグオンのコンテンツの試聴許可、あるいは試聴可能なコンテンツＩＤ情報が格納されており、これらの情報を取得する。
【０１５１】
次にステップＳ７０４において、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）の利用条件に基づいてコンテンツが再生される。なお、再生処理は、前述の図１９、図２０を参照して説明したように、コンテンツサーバから受信する暗号化コンテンツの復号処理を伴う再生処理となる。
【０１５２】
なお、コンテンツの購入処理を伴わない試聴処理においても、図２０を参照して説明した購入コンテンツの再生と同様、ＥＫＢ処理に基づくキー取得処理によってコンテンツ復号用のキーを取得することが必要となる。例えば、コンテンツ利用機器としてのハードウェアに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのハード対応ＥＫＢ［ＥＫＢ（Ｈ）］と、コンテンツ利用サービスに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］に対する正当なＤＮＫを有するユーザのみがコンテンツ再生を実行可能とする構成が適用でき、試聴においても再生権限を限定した範囲として設定可能となる。
【０１５３】
上述したように、クライアントは、ライセンスサーバに対する登録処理の際にデフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）を取得し、コンテンツの購入処理を伴わない、試聴処理の際にデフォルト利用権情報に基づいてコンテンツ再生を可能とした構成であるので、ユーザは、コンテンツの購入を実行することなく、コンテンツの試聴再生が可能となり、また、試聴が許可されるクライアントは、ライセンスサーバに対する登録処理を行ない、デフォルト利用権情報を有するクライアントに限定されることになるので、試聴データが無秩序に氾濫してしまうことが防止される。
【０１５４】
なお、図２１のシーケンス図では、ストリーミング再生の例を示したが、試聴データをクライアントの記憶媒体に格納し、再生時に、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）の有無を判定して、デフォルト利用権情報の記録に基づいて再生を行なう構成とすることも可能である。
【０１５５】
［７．バックアップ／リストア処理］
次にクライアントが購入したコンテンツまたはコンテンツ利用権情報についてのバックアップ処理、リストア処理について説明する。
【０１５６】
リストア処理は、クライアントのコンテンツ購入時、あるいは購入後の処理として実行されるコンテンツ対応のライセンス情報、すなわちサービスデータ、利用権情報の再取得、格納処理、あるいはコンテンツの再取得処理として実行される。
【０１５７】
処理態様としては、サービスデータ、利用権情報、コンテンツのいずれかの再取得、あるいはこれらの全データの再取得が可能である。以下に説明する実施例においては、サービスデータ、利用権情報、コンテンツ全データの再取得、格納処理シーケンス例を説明するが、必ずしもこれら全データを再取得する処理に限らず、いずれかのデータのみを選択的に再取得することも可能である。
【０１５８】
図２３以下を参照して、バックアップ／リストア処理の詳細について説明する。図２３は、クライアントアプリケーション、ブラウザを有するＰＣ等のクライアントと、ショップサーバ、コンテンツサーバ、ライセンスサーバ、および管理システムとの間で実行されるバックアップ／リストア処理における通信シーケンスの初期ステップを示している。以下、シーケンス図に示す処理について説明する。
【０１５９】
クライアントは、前述したコンテンツ購入処理に従って、正規にコンテンツ購入を行なったものとする。図２３に示すシーケンスは、コンテンツ購入に続いて実行されるシーケンスである。
【０１６０】
コンテンツ購入処理を実行したクライアントは、バックアップ／リストアデータの取得のためのデータファイルとしてのリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を生成（ステップ（５０））する。リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］の構成を図２４に示す。
【０１６１】
図２４に示すように、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］は、ＥＫＢ配信ツリーにおけるクライアント識別データとしてのリーフＩＤと、ハッシュ（ｈａｓｈ）値、例えばＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）からなる検証データによって構成される。クライアントアプリケーションは、管理システムと共有する秘密の鍵を適用してリーフＩＤに基づく検証用データとしてのハッシュ値あるいはＭＡＣを算出し、リーフＩＤと検証用データからなるリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を生成する。
【０１６２】
メッセージ認証符号（ＭＡＣ：Ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）は、データの改竄検証用のデータとして生成されるものである。ＤＥＳ暗号処理構成を用いたＭＡＣ値生成例を図２５に示す。図２５の構成に示すように対象となるメッセージを８バイト単位に分割し、（以下、分割されたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、まず、初期値（Ｉｎｉｔｉａｌ Ｖａｌｕｅ（以下、ＩＶとする））とＭ１を排他的論理和する（その結果をＩ１とする）。次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１とする）を用いて暗号化する（出力をＥ１とする）。続けて、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２をＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出力Ｅ２）。以下、これを繰り返し、全てのメッセージに対して暗号化処理を施す。最後に出てきたＥＮがメッセージ認証符号（ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ））となる。
【０１６３】
ＭＡＣ値は、その生成元データが変更されると、異なる値になり、検証対象のデータ（メッセージ）に基づいて生成したＭＡＣと、記録されているＭＡＣとの比較を行い、一致していれば、検証対象のデータ（メッセージ）は変更、改竄がなされていないことが証明される。
【０１６４】
図２３のシーケンスに戻り説明を続ける。クライアントは、ブラウザを介して管理システムの提供するリストアページにアクセス（ステップ（５１））し、管理システムは、リストアページをクライアントのブラウザに提示（ステップ（５２））する。管理システムの提示するリストアページは、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］のアップロード処理を実行する機能を持つページである。
【０１６５】
クライアントは、管理システムの提示するリストアページにおいて、クライアントアプリケーションの生成したリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］をアップロードする。リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］は、図２４を参照して説明したように、ＥＫＢ配信ツリーにおけるクライアント識別データとしてのリーフＩＤと、例えばＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）からなるハッシュ（ｈａｓｈ）値によって構成される。
【０１６６】
管理システムは、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を受信すると、クライアントと共有する秘密鍵を用いて、リーフＩＤに対するハッシュ値を算出し、算出ハッシュ値と、受信ハッシュ値の照合処理を行ない、受信データの検証（ステップ（５４））を行なう。算出ハッシュ値と、受信ハッシュ値が適合したことを条件として、バックアップ／リストア用の起動ファイルをクライアントに送信（ステップ（５５））する。起動ファイルの構成は、先に図１５を参照して説明したと同様のファイル構成を持つ。
【０１６７】
起動ファイルは、ブラウザからクライアントアプリケーションに渡され（ステップ（５６））、起動ファイルの記述、あるいは拡張子によって判別選択されるバックアップ／リストア実行プログラムを起動し、リストア処理を実行（ステップ（５７））する。
【０１６８】
バックアップ／リストア処理の処理対象としては、サービスデータ、コンテンツ、コンテンツ利用権情報がある。サービスデータは前述したようにライセンスサーバに対する登録処理によって取得可能であり、コンテンツはコンテンツサーバから取得可能である。また、利用権情報は、ライセンスサーバから取得される。バックアップ／リストア処理においても、これらの各データは、それぞれのサーバから取得することになる。
【０１６９】
まず、図２６を参照して、バックアップ／リストア用サービスデータの取得処理について説明する。基本的に、この処理は、先に説明したコンテンツ購入時のクライアント登録処理と同様の手続きに従ったものとなる。
【０１７０】
まず、クライアントアプリケーションは、登録要求をライセンスサーバに送信（ステップ（６１））する。この登録要求には、管理システムが生成した起動ファイル中に含まれるトランザクションＩＤ（ＴＩＤ）が含まれる。
【０１７１】
登録要求を受信したライセンスサーバは、トランザクションＩＤ（ＴＩＤ）に基づいて、バックアップ／リストア用サービスデータの取得であることを識別し、管理システムに対してサービス事前データ、すなわちサービスデータのバックアップ／リストア用データの割当要求（ステップ（６２））を行なう。管理システムは、同じトランザクションＩＤに基づいて処理を実行したクライアント端末があるか否かを管理データに基づいて検証し、ある場合には、これらを対応付けて記憶（ステップ（６３））する。これは、バックアップ／リストア処理の処理回数の上限（例えば３回）を設定し、上限を超える処理要求の場合には、処理を実行しないという設定を可能とするためである。
【０１７２】
管理データの更新処理を実行した管理システムは、サービス事前データ割当応答をライセンスサーバに送信（ステップ（６４））する。これは、バックアップ／リストア用サービスデータの発行許可情報として送信されるものである。
【０１７３】
サービス事前データ割当応答を受信したライセンスサーバは、バックアップ／リストア用サービスデータのクライアントに対する発行処理を実行（ステップ（６５））する。サービスデータは、先に図１７（ａ）を参照して説明したように、サービスデータ３７０には、ＥＫＢ配信ツリーにおいて設定されるクライアントに固有のリーフＩＤ、サービス識別子としてのサービスＩＤ、さらにデバイスノードキー（ＤＮＫ）をルートキー（Ｋｒｏｏｔ）で暗号化したデータ、Ｅ（Ｋｒｏｏｔ，ＤＮＫ）が含まれる。
【０１７４】
さらに、この処理時に、デフォルト利用権情報（図１７（ｂ）参照）もライセンスサーバからクライアントに対して発行される。先に説明したように、利用権情報は、通常は、購入コンテンツの利用条件を格納し、コンテンツの購入に対応して発行されるものであるが、デフォルト利用権情報は、コンテンツの購入を条件として発行するものではなく、クライアントの登録処理、あるいはサービスデータの発行処理を条件として発行する。このデフォルト利用権情報は、前述したようにコンテンツの試聴処理の際の有効な利用権情報として適用される。
【０１７５】
ライセンスサーバからサービスデータ、デフォルト利用権情報を受領したクライアントは、これらのデータをバックアップ用として、記憶手段に格納（ステップ（６６））する。
【０１７６】
次に、図２７を参照して、コンテンツのバックアップ／リストア処理について説明する。コンテンツのバックアップ／リストア処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（７１））する。これは、先にクライアントが購入したコンテンツと同一である。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１７７】
コンテンツサーバは、コンテンツダウンロード要求を受信すると、ＣＩＤに対応するコンテンツ情報をクライアントに送信（ステップ（７２））する。このコンテンツ情報は、暗号化コンテンツを含む情報である。先に図１７（ｃ）を参照して説明したように、コンテンツキー：Ｋｃで暗号化されたコンテンツデータ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキー：Ｋｃをルートキー：Ｋｒｏｏｔで暗号化したデータ：Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）、さらに：ルートキー：Ｋｒｏｏｔを取得するためのＥＫＢ、さらに試聴フラグデータ、サービスＩＤ等の情報が付加されたファイルである。
【０１７８】
コンテンツ情報を受領したクライアントは、受信コンテンツに対応する利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求をライセンスサーバに対して送信（ステップ（７３））する。この要求には、起動ファイル（図１５参照）中に含まれる利用権情報ＩＤ（ＵＩＤ）、クライアント識別データとしてのリーフＩＤ、トランザクションＩＤ（ＴＩＤ）が含まれる。
【０１７９】
ライセンスサーバは、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求を受信すると、管理システムに対して、注文照会処理（ステップ（７４））を行なう。この要求には、利用権情報ＩＤ（ＵＩＤ）、トランザクションＩＤ（ＴＩＤ）が含まれる。注文照会を受信した管理サーバは、注文照会応答として、利用権情報ＩＤ（ＵＩＤ）に対応する利用条件を設定した応答情報をライセンスサーバに送信（ステップ（７５））する。
【０１８０】
応答情報を受信したライセンスサーバは、コンテンツ利用条件を設定した利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成して、クライアントに対して再発行（ステップ（７６））する。なお、コンテンツ利用条件とは、コンテンツの再生回数、期限、外部機器に対するコピー、チェツクアウト処理等の各種処理の許可情報によって構成される。
【０１８１】
利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を受信したクライアントは、先に受信したコンテンツと利用権情報とを記憶手段にバックアップデータとして格納する。
【０１８２】
なお、バックアップ／リストア処理において、ライセンスサーバが発行する利用権情報は、正規なコンテンツ購入処理に際して発行する利用権情報とは異なる利用条件を設定したものとしてもよい。例えば、正規なコンテンツ購入時に発行する利用権情報に含まれる利用条件より厳しい条件、例えば利用期間の制限、コピー禁止、あるいはチェックアウト禁止といった条件を設定してバックアップ／リストア処理用の利用権情報を設定発行してもよい。
【０１８３】
［８．リコメンドファイルによるコンテンツの二次配信］
次に、正規にコンテンツを購入したクライアントが、購入コンテンツを他のクライアントに提供するいわゆるコンテンツ二次配信を実行し、コンテンツ利用権をライセンスサーバから新たに配布することで、二次配信コンテンツを受領したクライアントにおいても正当なコンテンツ利用権を有することを条件としてコンテンツ利用を可能とし、さらに、コンテンツサーバからのコンテンツ配信負荷の軽減を実現した構成について説明する。
【０１８４】
前述したように、コンテンツを再生利用するクライアントは、コンテンツを利用するためには、コンテンツサーバから暗号化されたコンテンツを受け取るとともに、ライセンスサーバから、ライセンス情報、すなわちサービスデータと、コンテンツに対応する利用権情報を受領することが必要となる。
【０１８５】
ライセンス情報、すなわちサービスデータおよび利用権情報は、データ容量の小さいデータであるため、インターネット等の通信網を介した送受信が頻繁に行われたとしてもトラフィックの上昇も少なく、多大な配信時間がかかるといった問題は発生しない。しかし、一方、コンテンツは、音楽データ、画像データ、プログラム等様々であり、そのデータ容量も大きなものとなる。このような大容量のコンテンツを特定のコンテンツサーバから多くのクライアントに送信する場合には、送信時間が長くなり、コンテンツサーバの負担、ネットワークトラッフィックの上昇等、様々な問題を発生させる。また、通信中の通信エラーによるコンテンツ配信エラーのトラブルも発生しかねない。
【０１８６】
以下では、すでに正規なコンテンツを購入したクライアントの保有するコンテンツを他のクライアントに提供、すなわち二次配信を実行し、二次配信によるコンテンツの提供を受けたクライアントが、そのコンテンツのライセンス情報をライセンスサーバから受領することで、コンテンツサーバのクライアントに対するコンテンツ送信の負荷を減少させたシステムについて説明する。
【０１８７】
図２８にコンテンツを正規に受領したクライアントが他のクライアントに提供するコンテンツファイルを生成する処理手順を説明したフローを示す。なお、他のクライアントに提供するコンテンツを含むデータファイルをリコメンドファイルと呼ぶ。リコメンドファイルには、暗号化されたコンテンツを含むコンテンツファイル、および必要に応じてそのコンテンツの説明ファイル（例えばＨＴＭＬファイル）が含まれる。
【０１８８】
図２８の処理フローについて説明する。図２８の処理を実行するクライアントは、前述したコンテンツ購入処理を実行し、正規にコンテンツを購入したクライアント、あるいは、リコメンドファイルを他のクライアントから受領し、その後の手続きにおいて正規なライセンスを取得したクライアントである。図２８の処理は、クライアントアプリケーション（図１のクライアントアプリケーション１２）の１つの実行プログラムとしてクライアントシステムとしての情報処理装置の制御手段（ＣＰＵ等）による制御の下に実行される。ステップＳ８０１において、クライアントは、自己のクライアント装置のディスプレイにリコメンドファイル作成画面を表示する。
【０１８９】
リコメンドファイル作成画面例を図２９に示す。クライアントが正規購入し、再生可能なコンテンツリスト６５１が中央に表示され、リコメンドファイルを生成する場合は、このコンテンツリスト６５１からコンテンツを選択（ステップＳ８０２）し、右側のリスト６５４にタイトル等を表示させる。コンテンツリスト６５１とリスト６５４間の移動処理は、移動スイッチ６５２、６５３の操作によって実行される。
【０１９０】
リコメンドファイル生成対象コンテンツが選択されると、ステップＳ８０３において、リコメンドファイル作成ボタン６５５が押下される。リコメンドファイル作成ボタン６５５が押下されると、ステップＳ８０４において、リコメンドファイル内にコンテンファイルに併せて説明ファイル、例えばＨＴＭＬによって記述された説明ファイルを生成格納するか否かを選択する。これはユーザが任意に選択可能である。
【０１９１】
リコメンドファイルには、図３０（ａ）に示すように、暗号化コンテンツを含むコンテンツファイル７２１とコンテンツ説明ファイル７２２とを組み合わせたリコメンドファイル７２０構成と、図３０（ｂ）に示すように、暗号化コンテンツを含むコンテンツファイル７２１のみからなるリコメンドファイル７３０構成との２つの態様があり、クライアントはその態様を自由に選択可能となる。
【０１９２】
ステップＳ８０４において、コンテンツ説明用ファイルの作成をしないと選択した場合は、図３０（ｂ）に示すコンテンツファイル７２１のみからなるリコメンドファイル７３０が生成される。
【０１９３】
コンテンツファイルの構成を図３１に示す。コンテンツファイル（ＭＱＴファイル）７２１には、暗号化コンテンツと、コンテンツ付加情報としてのメタ情報、さらにコンテンツ購入可能なショップを示すショップサーバＵＲＬ、コンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）が含まれる。
【０１９４】
なお、コンテンツファイルに格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーである。
【０１９５】
一方、ステップＳ８０４において、コンテンツ説明用ファイル作成を選択した場合は、ステップＳ８０６に進み、コンテンツ説明ファイル（ＨＴＭＬファイル）生成用の説明データ（メタデータ）をコンテンツ管理テーブルから取得する。コンテンツに対応するコンテンツ説明データは、上述したように暗号化コンテンツとともに、コンテンツファイル内にも格納されているが、正規にコンテンツ利用権を取得したクライアントは、コンテンツフィルから取り出したコンテンツ対応のメタデータをコンテンツ管理データとして、別ファイルに格納管理しており、リコメンドファイルにおいて生成される説明ファイル用のメタデータは、このコンテンツ管理データから抽出される。
【０１９６】
ステップＳ８０７において、コンテンツ管理データから抽出したメタデータを、クライアントアプリケーションに設定されたテンプレートＨＴＭＬファイルに貼り付ける処理を実行し、コンテンツ対応の説明用ＨＴＭＬファイルを生成し、ステップＳ８０８において、コンテンツファイルと説明用ＨＷＭＬファイルからなるリコメンドファイルを生成する。
【０１９７】
コンテンツ説明用データとしてのＨＴＭＬファイルの表示構成例を図３２に示す。図３２に示す例は、コンテンツが音楽データの場合の例である。説明用ファイルは、図３２に示すように、音楽コンテンツの楽曲タイトル、アーティスト、発売元等の情報リスト、さらに、各種の操作、処理に関する説明が記述されている。リコメンドファイルを他のクライアントから受理したクライアントは、まずこの説明ファイルをオープンすることになる。
【０１９８】
リコメンドファイルに格納されたコンテンツは暗号化されたコンテンツであり、正規なライセンス情報、すなわちサービスデータとコンテンツ対応の利用権情報を取得していない場合には再生することはできない。従って、リコメンドファイルを受領したクライアントがリコメンドファイルに格納されたコンテンツを利用する場合には、ライセンス情報を取得する手続きを実行することになる。
【０１９９】
このライセンス情報取得処理について、図３３、図３４の処理フローを参照して説明する。リコメンドファイルを受領したクライアントは、図３２に示す説明用ファイル（ＨＴＭＬファイル）をオープンし、試聴、購入コンテンツ配信サイトボタン７３１をクリック（ステップＳ８１１）する。このクリック処理により、クライアントアプリケーションが起動（ステップＳ８１２）し、同じリコメンドファイルに格納されたコンテンツファイル（ＭＱＴファイル）（図３１参照）を読み出して、コンテンツファイルからコンテンツＩＤ（ＣＩＤ）とショップＵＲＬを抽出（ステップＳ８１３）する。
【０２００】
このように、コンテンツ説明用ファイルの試聴、購入コンテンツ配信サイトボタン７３１は、コンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータとして構成されている。従って、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【０２０１】
ステップＳ８１４において、コンテンツファイルから抽出したコンテンツＩＤ（ＣＩＤ）に基づいて、コンテンツファイル名を設定する。これはクライアントアプリケーションにおいて予め設定されたファイル名設定処理として実行され、例えばコンテンツのタイトル、アーティスト名、あるいはその複合データ等が適用される。ステップＳ８１５では、ステップＳ８１４５で設定したファイル名のコンテンファイルがクライアントの記憶部に格納される。
【０２０２】
次に、ステップＳ８１６において、ステップＳ８１３でコンテンツファイルから抽出したショップＵＲＬがブラウザに渡され、ブラウザは受領ＵＲＬに対応するショップページをショップサーバから読み出す。
【０２０３】
図３４の処理フローのステップＳ８３１において、ショップ画面がクライアントのディスプレイに表示される。以下の処理は、基本的には、前述したコンテンツの購入処理、試聴処理のいずれかの処理と同様であり、先に図１１、図１３、図１８、図２１に従って説明した処理に従うことになる。ただし、コンテンツ自体はすでにコンクライアントが、リコメンドファイルから取得済みであるので、コンテンツサーバカらのコンテンツ受領処理は、省略される。
【０２０４】
一連の処理の概略は、図３４の処理フローのステップＳ８３２以下に示す処理となる。まず、クライアントがショップサーバの提示するショップ画面において購入を指定してショップサーバに購入要求を出力すると、ショップサーバから購入用起動ファイルが送信される。これは、先に、図１５を参照して説明した起動ファイルと同様の構成を持つ。
【０２０５】
次に、ステップＳ８３３において、起動ファイルからコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）を取得する。次に、ステップＳ８３４において、コンテンツＩＤ（ＣＩＤ）に基づいて、コンテンツファイル名を算出する。クライアント装置にコンテンツを格納する際のコンテンツファイル名は、先の図３３のフローの説明で述べたようにコンテンツＩＤ（ＣＩＤ）に基づいて設定されることがクライアントアプリケーションにおいて規定され、ＣＩＤとファイル名の対応付けがなされている。
【０２０６】
ステップＳ８３５において、コンテンツＩＤ（ＣＩＤ）から算出したファイル名と同一のファイル名のファイルが自己のクライアント装置の記憶部に格納されているか否かを判定する。コンテンツが格納されていない場合は、ステップＳ８３７に進み、コンテンツサーバに接続して、コンテンツダウンロードを行なうことになる。この処理は、先に説明したコンテンツ購入時の処理と同様である。
【０２０７】
しかし、リコメンドファイルを受領しているクライアントは、先の図３３のフロー忠のステップＳ８１４，Ｓ８１５において、所定のファイル名を設定したコンテンツファイルを記憶部に格納しており、コンテンツのダウンロード処理は省略され、ステップＳ８３６のコンテンツ利用権情報の取得処理を実行し処理を終了することが可能となる。
【０２０８】
クライアントがコンテンツ再生を実行する際は、前述したように、コンテンツ利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との照合を行ないＣＩＤの一致を条件としてコンテンツ再生を実行する。また、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行することにより、コンテンツを再生利用することが可能となる。
【０２０９】
このように、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【０２１０】
なお、図３４のフローにおいてはサービスデータの取得処理については省略してあるが、サービスデータを保有していないクライアントがリコメンドファイルを受領した場合には、ライセンスサーバに対するアクセスを実行して登録処理を行ない、サービスデータを取得することが必要となる。この登録処理手続きは、先に図１３、図１６を参照して説明した処理に対応する処理となる。
【０２１１】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２１２】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２１３】
例えば、プログラムは記憶媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０２１４】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記憶媒体にインストールすることができる。
【０２１５】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。
【０２１６】
【発明の効果】
以上、説明したように、本発明の構成によれば、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【０２１７】
また、本発明の構成によれば、コンテンツ説明用ファイルを、コンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータを保持したファイルとして構成したので、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【０２１８】
また、本発明の構成によれば、リコメンドファイル中に格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであるので、不正なコンテンツ利用の防止が確実に実行される。
【図面の簡単な説明】
【図１】本発明を適用したコンテンツ提供システムの概要を示す図である。
【図２】クライアント、および各サーバ、管理システムの構成例を示す図である。
【図３】各種キー、データの暗号化処理、配布処理について説明するツリー構成図である。
【図４】各種キー、データの配布に使用される有効化キーブロック（ＥＫＢ）の例を示す図である。
【図５】コンテンツキーの有効化キーブロック（ＥＫＢ）を使用した配布例と復号処理例を示す図である。
【図６】有効化キーブロック（ＥＫＢ）のフォーマット例を示す図である。
【図７】有効化キーブロック（ＥＫＢ）のタグの構成を説明する図である。
【図８】ツリー構成におけるカテゴリ分割を説明する図である。
【図９】ツリー構成におけるカテゴリ分割を説明する図である。
【図１０】ツリー構成におけるカテゴリ分割の具体例を説明する図である。
【図１１】コンテンツ購入、または試聴処理における各エンティテイ間の実行処理シーケンス（その１）を示す図である。
【図１２】管理システムにおいて実行するトランザクションＩＤ生成、発行処理手順を示すフロー図である。
【図１３】コンテンツ購入、または試聴処理における各エンティテイ間の実行処理シーケンス（その２）を示す図である。
【図１４】管理システムにおいて実行するダウンロード許可処理手順を示すフロー図である。
【図１５】起動ファイルのデータ構成例を示す図である。
【図１６】クライアントにおいて実行する起動ファイルに基づくアプリケーション実行手順を示すフロー図である。
【図１７】サービスデータ、利用権情報のデータ構成例を示す図である。
【図１８】コンテンツ購入処理における各エンティテイ間の実行処理シーケンスを示す図である。
【図１９】コンテンツ再生処理の概要を説明する図である。
【図２０】有効化キーブロック（ＥＫＢ）を適用したコンテンツ復号、利用処理例を説明する図である。
【図２１】コンテンツ試聴処理における各エンティテイ間の実行処理シーケンスを示す図である。
【図２２】試聴コンテンツ再生処理の概要を説明する図である。
【図２３】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その１）を示す図である。
【図２４】リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］の構成例を示す図である。
【図２５】ＭＡＣ生成処理構成を示す図である。
【図２６】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その２）を示す図である。
【図２７】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その３）を示す図である。
【図２８】リコメンドファイルの生成処理フローを示す図である。
【図２９】リコメンドファイル生成画面を示す図である。
【図３０】リコメンドファイル構成例を示す図である。
【図３１】リコメンドファイル中に格納されるコンテンツファイルの構成例を示す図である。
【図３２】リコメンドファイル中に格納されるコンテンツ説明ファイルの表示例を示す図である。
【図３３】リコメンドファイルを受領したクライアントにおけるライセンス情報取得処理フロー（その１）を示す図である。
【図３４】リコメンドファイルを受領したクライアントにおけるライセンス情報取得処理フロー（その２）を示す図である。
【符号の説明】
１０ クライアント
１１ ブラウザ
１２ クライアントアプリケーション
２１ ショップサーバ
２２ ライセンスサーバ
２３ コンテンツサーバ
３１ 管理システム
１００ タイマ
１０１ ＣＰＵ（Ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
１０２ ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
１０３ ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）
１０４ 暗号化復号部
１０５ コーデック部
１０６ 入力部
１０７ 出力部
１０８ 記憶部
１０９ 通信部
１１０ ドライブ
１１１ バス
１１２ 入出力インタフェース
１２１ リムーバブル記録媒体
２０１ バージョン
２０２ デプス
２０３ データポインタ
２０４ タグポインタ
２０５ 署名ポインタ
２０６ データ部
２０７ タグ部
２０８ 署名
３０１ ルートキー
３０２ ノードキー
３０３ リーフキー
３０４ カテゴリノード
３５０ ルートノード
３５１ Ｔシステムノード
３５２ Ｔサービスノード
３５３ Ｔハードノード
３５４ サービスプロバイダノード
３５５ リーフ
３６０ 起動ファイル
３７０ サービスデータ
３７１ 利用権情報
３７２ コンテンツ
３７３ 試聴フラグ
３８１ ライセンスサーバ
３８２ コンテンツサーバ
３８３ クライアント
３８４ コンテンツ
４０１ サービスデータ
４０２ 暗号化コンテンツファイル
４０３ 利用権情報
４１１ ＥＫＢ（Ｈ）
６０１ リストア処理要求ファイル
６５１ コンテンツリスト
６５２，６５３ スイッチ
６５３ リコメンドファイル作成ボタン
６５４ リスト
７２０，７３０ リコメンドファイル
７２１ コンテンツファイル
７２２ コンテンツ説明ファイル
７３１ 試聴、購入コンテンツ配信サイトボタン
【発明の属する技術分野】
本発明は、情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムに関する。さらに詳細には、クライアントが取得したコンテンツの二次流通を簡易にかつセキュアに実行させる構成を実現し、コンテンツサーバからのクライアントに対するコンテンツ配信を省略したコンテンツ取得、流通を実現する情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、音楽データ、ゲームプログラム、画像データ等、様々なソフトウエアデータ（以下、これらをコンテンツ（Ｃｏｎｔｅｎｔ）と呼ぶ）の、インターネット等のネットワーク、あるいは、メモリカード、ＨＤ、ＤＶＤ、ＣＤ等の流通可能な記憶媒体を介した流通が盛んになっている。これらの流通コンテンツは、ユーザの所有するＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、記録再生器、再生専用器、あるいはゲーム機器内の記憶手段、例えばＨＤ，フラッシュメモリを有するカード型記憶装置、ＣＤ、ＤＶＤ等に格納され、再生処理が実行される。
【０００３】
記録再生装置、ゲーム機器、ＰＣ等の情報機器には、コンテンツをネットワークから受信するためのインタフェース、あるいはメモリカード、ＨＤ、ＤＶＤ、ＣＤ等にアクセスするためのインタフェースを有し、コンテンツの再生に必要となる制御手段、プログラム、データのメモリ領域として使用されるＲＡＭ、ＲＯＭ等を有する。
【０００４】
音楽データ、画像データ、あるいはプログラム等の様々なコンテンツは、再生機器として利用される記録再生装置、ゲーム機器、ＰＣ等の情報機器本体からのユーザ指示、あるいは接続された入力手段を介したユーザの指示により、例えば内蔵、あるいは着脱自在の記憶媒体から呼び出され、情報機器本体、あるいは接続されたディスプレイ、スピーカ等を通じて再生される。
【０００５】
ゲームプログラム、音楽データ、画像データ等、多くのソフトウエア・コンテンツは、一般的にその作成者、販売者に頒布権等が保有されている。従って、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、ソフトウェアの使用を許諾し、許可のない複製等が行われないようにする、すなわちセキュリティを考慮した構成をとるのが一般的となっている。
【０００６】
また、コンテンツと、コンテンツを利用する利用権とを独立に管理し、ユーザに提供する構成が提案されている。この構成において、ユーザは、例えば暗号化されたコンテンツを取得し、さらに、利用権データを購入することにより、利用権データから取得可能な鍵データ等に基づいて、暗号化コンテンツの復号用の鍵（コンテンツ鍵）を取得して、コンテンツを利用する。
【０００７】
利用権データには、ユーザのコンテンツ利用許可態様の設定情報が格納され、その許可情報において許された範囲でのコンテンツの利用が可能となるといったシステムが提案されている。
【０００８】
【発明が解決しようとする課題】
このように、コンテンツとコンテンツ利用権とを独立に管理し、ユーザに提供するシステムにおいては、コンテンツの利用、例えば音楽データ、画像データの再生、または配信、あるいはダウンロード処理に際して、利用権データのチェックが実行される。
【０００９】
このようなコンテンツ提供システムにおいて、コンテンツのクライアントに対する提供処理は、例えばインターネット等の通信網を介して実行されることになる。しかしながら、音楽データ、画像データの配信処理、ダウンロード処理には、ネットワーク状況、各システムの能力により、多大な時間を要する場合がある。
【００１０】
今後、コンテンツ配信がさらに盛んになれば、ネットワークを介して送受信されるコンテンツは急激に増大し、コンテンツ配信によるネットワークトラフィックの混雑は避けられない。また、特定のコンテンツを要求する多数のクライアントが特定のコンテンツ配信サーバに一時期にアクセスを行なうと、コンテンツ配信サーバからのコンテンツのダウンロードが思うように実行できない事態も発生し得る。
【００１１】
本発明は、このような状況に鑑みてなされたものであり、正規に購入したコンテンツを有するクライアントから、他のクライアントにコンテンツを二次配信することを可能とし、比較的小容量の利用権情報のみを二次配信コンテンツを持つクライアントに提供する構成として、コンテンツサーバからのコンテンツ配信における負荷を減少させ、ネットワークトラフィックの軽減を実現可能とした情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラムを提供することを目的とするものである。
【００１２】
【課題を解決するための手段】
本発明の第１の側面は、
暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの複製データを生成する制御手段を有し、
前記制御手段は、
暗号化コンテンツ複製データおよびコンテンツ購入処理可能なショップサーバＵＲＬを格納した二次配信用コンテンツファイルの生成処理を実行する構成を有することを特徴とする情報処理装置にある。
【００１３】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成し、前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルであることを特徴とする。
【００１４】
さらに、本発明の情報処理装置の一実施態様において、前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする。
【００１５】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行する構成であることを特徴とする。
【００１６】
さらに、本発明の情報処理装置の一実施態様において、前記暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする。
【００１７】
さらに、本発明の第２の側面は、
暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの取得処理を実行する制御手段を有し、
前記制御手段は、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理を実行し、格納済みの場合にはコンテンツダウンロード処理を実行せず、未格納の場合にのみコンテンツダウンロード処理を実行する構成を有することを特徴とする情報処理装置にある。
【００１８】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行ない、該設定ファイル名のコンテンツを記憶手段に格納するとともに、コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出し、算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行する構成であることを特徴とする。
【００１９】
さらに、本発明の情報処理装置の一実施態様において、前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、前記制御手段は、前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行する構成であることを特徴とする。
【００２０】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行する構成であることを特徴とする。
【００２１】
さらに、本発明の情報処理装置の一実施態様において、前記制御手段は、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行する構成であることを特徴とする。
【００２２】
さらに、本発明の第３の側面は、
二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成方法であり、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とする二次配信コンテンツ生成方法にある。
【００２３】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法は、さらに、前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成するステップを有し、前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルとして生成することを特徴とする。
【００２４】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする。
【００２５】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法は、さらに、記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行するステップを含むことを特徴とする。
【００２６】
さらに、本発明の二次配信コンテンツ生成方法の一実施態様において、前記二次配信コンテンツ生成方法において複製する暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする。
【００２７】
さらに、本発明の第４の側面は、
暗号化コンテンツの取得処理を実行する情報処理方法であり、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とする情報処理方法にある。
【００２８】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行なうファイル名設定ステップと、前記ファイル名設定ステップで設定したファイル名のコンテンツを記憶手段に格納するステップと、コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出するステップと、算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行するステップと、を有することを特徴とする。
【００２９】
さらに、本発明の情報処理方法の一実施態様において、前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、前記情報処理方法は、さらに、前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行するステップを含むことを特徴とする。
【００３０】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行するステップを含むことを特徴とする。
【００３１】
さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法は、さらに、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行するステップを含むことを特徴とする。
【００３２】
さらに、本発明の第５の側面は、
二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成処理実行プログラムを記述したコンピュータ・プログラムであって、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００３３】
さらに、本発明の第６の側面は、
暗号化コンテンツの取得処理を実行する情報処理実行プログラムを記述したコンピュータ・プログラムであって、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００３４】
【作用】
本発明の構成によれば、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【００３５】
また、本発明の構成によれば、コンテンツ説明用ファイルをコンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータを保持したファイル構成としたので、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【００３６】
また、本発明の構成によれば、リコメンドファイル中に格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであるので、不正なコンテンツ利用の防止が確実に実行される。
【００３７】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記憶媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００３８】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００３９】
【発明の実施の形態】
以下、本発明の構成について詳細に説明する。なお、説明は、以下に示す各項目に従って行なう。
１．コンテンツ提供システム概要
２．キー配信構成としてのツリー（木）構造について
３．ＥＫＢを使用したキーの配布
４．ＥＫＢのフォーマット
５．ツリーのカテゴリ分類
６．コンテンツ購入および試聴処理
７．バックアップ／リストア処理
８．リコメンドファイルによるコンテンツの二次配信
【００４０】
［１．コンテンツ提供システム概要］
図１は、本発明を適用したコンテンツ提供システムの概要を説明する図である。コンテンツの利用を行なうクライアント１０は、コンテンツを利用、すなわち再生可能な機器としての情報処理装置である。例えばＰＣ、ＰＤＡ等、各種の情報処理装置が含まれる。クライアント１０は、ソフトウェアとしてブラウザ１１、クライアントアプリケーション１２を有し、ＣＰＵ等の制御手段によりブラウザ１１、クライアントアプリケーション１２他のプログラムが実行される。
【００４１】
クライアントアプリケーション１２は、クライアントにおけるコンテンツの購入および試聴処理、後段において説明するサービスデータ、コンテンツ利用権情報を含むライセンス情報の取得処理、コンテンツおよびライセンス情報のバックアップ／リストア処理、コンテンツ利用権の確認処理、コンテンツ再生管理処理、あるいは、二次配信用のコンテンツファイルとしてのリコメンドファイルの生成処理等を実行するアプリケーションであり、以下、詳細に説明する処理プログラムとして、クライアントの情報処理装置に格納される。なお、本明細書においては、「試聴」は、音声データの試聴のみならず、画像データの試写を包含する意味として用いる。
【００４２】
クライアント１０は、例えばインターネット等の通信網を介してショップサーバ２１、ライセンスサーバ２２、およびコンテンツサーバ２３と接続される。コンテンツサーバ２３は、クライアント１０に対してコンテンツを提供する。ライセンスサーバ２２は、クライアントが利用するコンテンツの利用権情報をクライアント１０に対して提供する。また、ショップサーバ２１は、クライアント１０がコンテンツを購入する際の窓口として機能し、購入または試聴可能コンテンツをブラウザを介して提示し、クライアントからの購入あるいは試聴の要求を受け付ける。また、必要に応じて購入コンテンツに関する課金処理を行なう。
【００４３】
さらに、ショップサーバ２１、およびライセンスサーバ２２には、管理システム３１が接続される。管理システム３１は、ショップサーバ２１が受け付けたクライアント１０からのコンテンツ要求に対する許可情報として機能するトランザクションＩＤ（ＴＩＤ）の発行処理、コンテンツダウンロード許可情報の発行処理を行なう。また、管理システム３１は、ライセンスサーバ２２に対して、コンテンツの利用権情報としての利用権データＵｓａｇｅ Ｒｉｇｈｔ）の発行許可を行なう。これらの処理の詳細は、後段で説明する。
【００４４】
なお、クライアント１０は、ライセンスサーバ２２からの利用権の取得、コンテンツサーバ２３からのコンテンツ取得を、クライアントアプリケーション１２の制御の下に実行し、ショップサーバ２１の提供する情報の閲覧および決済処理は、クライアントアプリケーション１２の制御の下にブラウザ１１を起動して実行する。
【００４５】
図１には、クライアントおよび各サーバを１つづつ示してあるが、これらは例えばインターネット等の通信網上に多数接続され、クライアントは、様々なショップサーバに接続し、各ショップサーバで提供するコンテンツを自由に選択し、選択したコンテンツを格納したコンテンツサーバからコンテンツを取得し、取得したコンテンツの利用権を発行するライセンスサーバを選択して、その選択されたライセンスサーバから利用権を取得する。
【００４６】
コンテンツは、暗号化コンテンツとしてコンテンツサーバ２３からクライアント１０に提供される。さらに、ライセンスサーバ２２からクライアント１０に対しては、コンテンツに対応するコンテンツ利用権情報が提供され、クライアント１０のクライアントアプリケーション１２が、利用権情報を検証し、利用権があると判定された場合に暗号化コンテンツを復号して利用する。
【００４７】
クライアント１０は、コンテンツ利用権に基づくコンテンツ利用を可能とするための鍵情報として、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）、デバイス・ノード・キー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）等の鍵データを保持する。有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）、デバイス・ノード・キー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）は、コンテンツの利用を正当なコンテンツ利用権を有するユーザデバイスにおいてのみ暗号化コンテンツを復号して利用可能とするためのコンテンツ利用に必要となる暗号鍵を取得するための鍵データである。ＥＫＢ，ＤＮＫについては、後段で説明する。
【００４８】
コンテンツサーバ２３は、コンテンツを暗号化して、暗号化コンテンツをクライアント１０に提供する。さらに、ライセンスサーバ２２は、コンテンツ利用条件に基づいて利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成してユーザデバイス３０に提供する。さらに、管理システム３１の提供するデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）に基づいてサービスデータを生成してクライアント１０に提供する。サービスデータは、暗号化コンテンツの復号処理の際に必要となるサービス・デバイスノードキー（ＳＤＮＫ）を持つ有効化キーブロック（ＥＫＢ）を含む。
【００４９】
なお、コンテンツの利用条件には、利用期間の限定条件、コピーの回数制限、さらにコンテンツを同時に利用することができるポータブルメディア（ＰＭ：Ｐｏｒｔａｂｌｅ Ｍｅｄｉａ）の数（いわゆるチェックアウト（Ｃｈｅｃｋ−ｏｕｔ）数に対応）の制限等がある。ポータブルメディア（ＰＭ：Ｐｏｒｔａｂｌｅ Ｍｅｄｉａ）は例えばフラッシュメモリ、または小型ＨＤ、光ディスク、光磁気ディスク、ＭＤ（Ｍｉｎｉ Ｄｉｓｋ）等、ポータブルデバイスにおいて利用可能な記憶媒体である。
【００５０】
次に、図２を参照して、クライアント１０、ショップサーバ２１、ライセンスサーバ２２、コンテンツサーバ２３、管理システム３１として機能可能な情報処理装置の構成例を示す。これらの各システムはＣＰＵを持つ例えばＰＣ、サーバ等のシステムにそれぞれの処理に応じた処理プログラムを格納することで実現される。
【００５１】
まず、図２を用いて各システムの構成例について説明する。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２に記憶されている各種プログラム、あるいは、記憶部１０８に格納され、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３にロードされたプログラムに従って各種処理を実行する。タイマ１００は計時処理を行ない、クロック情報をＣＰＵ１０１に供給する。
【００５２】
ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２は、ＣＰＵ１０１が使用するプログラムや演算用のパラメータ、固定データ等を格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３は、ＣＰＵ１０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を格納する。これら各素子はＣＰＵバスなどから構成されるバス１１１により相互に接続されている。
【００５３】
暗号化復号部１０４は、コンテンツの暗号化、復号処理、デバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）、有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）の適用処理として、例えばＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）の暗号化アルゴリズムを適用した暗号処理、ＭＡＣ生成、検証処理等を実行する。さらに、他の接続装置との間で実行されるコンテンツあるいはライセンス情報の送受信時の認証およびセッションキー共有処理等、各種暗号処理を実行する。
【００５４】
コーデック部１０５は、例えばＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）３方式、ＭＰＥＧ、ＪＰＥＧ方式等、各種方式のデータエンコード処理、デコード処理を実行する。処理対象データは、バス１１１、入出力インタフェース１１２、ドライブ１１０を介してリムーバブル記憶媒体１２１からまたは通信部１０９を介して入力する。また処理後のデータは、必要に応じて、リムーバブル記憶媒体１２１に格納し、または通信部１０９を介して出力する。
【００５５】
入出力インタフェース１１２には、キーボード、マウス等の入力部１０６、ＣＲＴ、ＬＣＤ等のディスプレイ、スピーカ等からなる出力部１０７、ハードディスク等の記憶部１０８、モデム、ターミナルアダプタ等によって構成される通信部１０９が接続され、例えばインターネット等の通信網を介したデータ送受信を行なう。
【００５６】
［２．キー配信構成としてのツリー（木）構造について］
次に、正当なコンテンツ利用権を有するクライアントにおいてのみコンテンツを利用可能とするための、ブロードキャストエンクリプション（Ｂｒｏａｄｃａｓｔ Ｅｎｃｒｙｐｔｉｏｎ）方式の一態様であるツリー構成によるデバイスとキーの管理構成について説明する。
【００５７】
図３の最下段に示すナンバ０〜１５がコンテンツ利用を行なうクライアントとしてのユーザデバイスである。すなわち図３に示す階層ツリー（木）構造の各葉（リーフ：ｌｅａｆ）がそれぞれのデバイスに相当する。
【００５８】
各デバイス０〜１５は、製造時あるいは出荷時、あるいはその後において、図３に示す階層ツリー（木）構造における自分のリーフからルートに至るまでのノードに割り当てられた鍵（ノードキー）および各リーフのリーフキーからなるキーセット（デバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ））をメモリに格納する。図３の最下段に示すＫ００００〜Ｋ１１１１が各デバイス０〜１５にそれぞれ割り当てられたリーフキーであり、最上段のＫＲ（ルートキー）から、最下段から２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１１をノードキーとする。
【００５９】
図３に示すツリー構成において、例えばデバイス０はリーフキーＫ００００と、ノードキー：Ｋ０００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ１、ＫＲを所有する。なお、図３のツリーにはデバイスが０〜１５の１６個のみ記載され、ツリー構造も４段構成の均衡のとれた左右対称構成として示しているが、さらに多くのデバイスがツリー中に構成され、また、ツリーの各部において異なる段数構成を持つことが可能である。
【００６０】
また、図３のツリー構造に含まれる各デバイスには、様々な記録媒体、例えば、デバイス埋め込み型あるいはデバイスに着脱自在に構成されたＤＶＤ、ＣＤ、ＭＤ、フラッシュメモリ等を使用する様々なタイプのデバイスが含まれている。さらに、様々なアプリケーションサービスが共存可能である。このような異なるデバイス、異なるアプリケーションの共存構成の上に図３に示すコンテンツあるいは鍵配布構成である階層ツリー構造が適用される。
【００６１】
これらの様々なデバイス、アプリケーションが共存するシステムにおいて、例えば図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を同一の記録媒体を用いる１つのグループとして設定する。例えば、この点線で囲んだグループ内に含まれるデバイスに対しては、まとめて、共通のコンテンツを暗号化してプロバイダから送付したり、各デバイス共通に使用するコンテンツキーを送付したり、あるいは各デバイスからプロバイダあるいは決済機関等にコンテンツ料金の支払データをやはり暗号化して出力するといった処理が実行される。コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等、各デバイスとのデータ送受信を行なう機関は、図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を１つのグループとして一括してデータを送付する処理を実行する。このようなグループは、図３のツリー中に複数存在する。コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等、各デバイスとのデータ送受信を行なう機関は、メッセージデータ配信手段として機能する。
【００６２】
なお、ノードキー、リーフキーは、ある１つの鍵管理センター機能を持つ管理システムによって統括して管理してもよいし、各グループに対する様々なデータ送受信を行なうプロバイダ、決済機関等のメッセージデータ配信手段によってグループごとに管理する構成としてもよい。これらのノードキー、リーフキーは例えばキーの漏洩等の場合に更新処理が実行され、この更新処理は鍵管理センター機能を持つ管理システム、プロバイダ、決済機関等が実行する。
【００６３】
このツリー構造において、図３から明らかなように、１つのグループに含まれる３つのデバイス０，１，２，３はデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）として共通のキーＫ００、Ｋ０、ＫＲを含むデバイスノードキー（ＤＮＫ：Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）を保有する。このノードキー共有構成を利用することにより、例えば共通のキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００は、デバイス０，１，２，３に共通する保有キーとなる。また、新たなキーＫｎｅｗをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｎｅｗ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｎｅｗ）を解いて新たなキーＫｎｅｗを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【００６４】
また、ある時点ｔにおいて、デバイス３の所有する鍵：Ｋ００１１，Ｋ００１，Ｋ００，Ｋ０，ＫＲが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキー：Ｋ００１，Ｋ００，Ｋ０，ＫＲをそれぞれ新たな鍵Ｋ（ｔ）００１，Ｋ（ｔ）００，Ｋ（ｔ）０，Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Ｇｅｎｅｒａｔｉｏｎ）：ｔの更新キーであることを示す。
【００６５】
更新キーの配布処理ついて説明する。キーの更新は、例えば、図４（Ａ）に示す有効化キーブロック（ＥＫＢ：Ｅｎａｂｌｉｎｇ Ｋｅｙ Ｂｌｏｃｋ）と呼ばれるブロックデータによって構成されるテーブルをたとえばネットワーク、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図３に示すようなツリー構造を構成する各リーフに対応するデバイスに新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Ｋｅｙ Ｒｅｎｅｗａｌ Ｂｌｏｃｋ）と呼ばれることもある。
【００６６】
図４（Ａ）に示す有効化キーブロック（ＥＫＢ）には、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図４の例は、図３に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図３から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
【００６７】
図４（Ａ）のＥＫＢに示されるようにＥＫＢには複数の暗号化キーが含まれる。最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーによってこの暗号化キーを復号し、Ｋ（ｔ）００１を得ることができる。また、復号により得たＫ（ｔ）００１を用いて、図４（Ａ）の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）を復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。以下順次、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。一方、デバイスＫ００００．Ｋ０００１は、ノードキーＫ０００は更新する対象に含まれておらず、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。デバイスＫ００００．Ｋ０００１は、図４（Ａ）の上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号しＫ（ｔ）００、を取得し、以下、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新した鍵Ｋ（ｔ）Ｒを得ることができる。なお、図４（Ａ）のインデックスは、復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
【００６８】
図３に示すツリー構造の上位段のノードキー：Ｋ（ｔ）０，Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図４（Ｂ）の有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
【００６９】
図４（Ｂ）に示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図３に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキー：Ｋ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ），Ｋ（ｔ）ｃｏｎ）を図４（Ｂ）に示すＥＫＢとともに配布する。この配布により、デバイス４など、その他のグループの機器においては復号されないデータとしての配布が可能となる。
【００７０】
すなわち、デバイス０，１，２はＥＫＢを処理して得たＫ（ｔ）００を用いて上記暗号文を復号すれば、ｔ時点でのキー、例えばコンテンツの暗号化復号化に適用するコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
【００７１】
［３．ＥＫＢを使用したキーの配布］
図５に、ｔ時点でのキー、例えばコンテンツの暗号化復号化に適用するコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と図４（Ｂ）に示すＥＫＢとを記録媒体を介して受領したデバイス０の処理例を示す。すなわちＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【００７２】
図５に示すように、デバイス０は、記録媒体に格納されている世代：ｔ時点のＥＫＢと自分があらかじめ格納しているノードキーＫ０００を用いて上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、復号した更新ノードキーＫ（ｔ）００を用いて更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
【００７３】
［４．ＥＫＢのフォーマット］
図６に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン２０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは最新のＥＫＢを識別する機能とコンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ２０３は、有効化キーブロック（ＥＫＢ）中のデータ部の位置を示すポインタであり、タグポインタ２０４はタグ部の位置、署名ポインタ２０５は署名の位置を示すポインタである。
【００７４】
データ部２０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図５に示すような更新されたノードキーに関する各暗号化キー等を格納する。
【００７５】
タグ部２０７は、データ部に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図７を用いて説明する。図７では、データとして先に図４（Ａ）で説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図７の表（ｂ）に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはＫＲとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図７の（ａ）に示す階層ツリーに示す位置にある。ここで、次のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置にある。データがある場合は、タグが０、ない場合は１が設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）の左にはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図７（ｃ）に示すデータ列、およびタグ列が構成される。
【００７６】
タグは、データＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）がツリー構造のどこに位置しているのかを示すために設定されるものである。データ部に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）．．．は、単純に暗号化されたキーの羅列データに過ぎないので、上述したタグによってデータとして格納された暗号化キーのツリー上の位置を判別可能としたものである。上述したタグを用いずに、先の図４で説明した構成のように暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（Ｔ）００）
．．．のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
【００７７】
図６に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Ｓｉｇｎａｔｕｒｅ）２０８は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センター機能を持つ管理システム、コンテンツサーバ、ライセンスサーバ、あるいはショップサーバ等が実行する電子署名である。ＥＫＢを受領したデバイスは署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
【００７８】
［５．ツリーのカテゴリ分類］
ノードキー等を定義している階層ツリー構造を各デバイスのカテゴリ毎に分類して効率的なキー更新処理、暗号化キー配信、データ配信を実行する構成について、以下説明する。
【００７９】
図８に階層ツリー構造のカテゴリの分類の一例を示す。図８において、階層ツリー構造の最上段には、ルートキーＫｒｏｏｔ３０１が設定され、以下の中間段にはノードキー３０２が設定され、最下段には、リーフキー３０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーを保有する。
【００８０】
ここで、一例として最上段から第Ｍ段目のあるノードをカテゴリノード３０４として設定する。すなわち第Ｍ段目のノードの各々を特定カテゴリのデバイス設定ノードとする。第Ｍ段の１つのノードを頂点として以下、Ｍ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとする。
【００８１】
例えば図８の第Ｍ段目の１つのノード３０５にはカテゴリ［メモリステッイク（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード３０５以下を、メモリスティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義する。
【００８２】
さらに、Ｍ段から数段分下位の段をサブカテゴリノード３０６として設定することができる。例えば図に示すようにカテゴリ［メモリスティック］ノード３０５の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノードを設定する。さらに、サブカテゴリノードである再生専用器のノード３０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード３０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード３０８と［携帯電話］ノード３０９を設定することができる。
【００８３】
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺにその頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
【００８４】
このように、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
【００８５】
本発明のシステムにおいては、図９に示されるように、ツリー構成のシステムで、キーの管理が行われる。図９の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリスティックなどの半導体メモリを使用する機器のカテゴリ、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、ライセンスを管理するシステムとして本システム（Ｔシステムと称する）が対応する。
【００８６】
すなわち、このＴシステムのノードよりさらに下の階層の２４段のノードに対応するキーが、サービスプロバイダ、あるいはサービスプロバイダが提供するサービスに適用される。この例の場合、これにより、２２４（約１６メガ）のサービスプロバイダあるいはサービスを規定することができる。さらに、最も下側の３２段の階層により、２３２（約４ギガ）のユーザ（あるいはユーザデバイス）を規定することができる。最下段の３２段のノードからＴシステムのノードまでのパス上の各ノードに対応するキーが、ＤＮＫ（Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）を構成し、最下段のリーフに対応するＩＤがリーフＩＤとされる。
【００８７】
例えば、コンテンツを暗号化したコンテンツキーは更新されたルートキーＫＲ’によって暗号化され、上位の階層の更新ノードキーは、その直近の下位の階層の更新ノードキーを用いて暗号化され、ＥＫＢ内に配置される。ＥＫＢにおける末端から１つ上の段の更新ノードキーはＥＫＢの末端のノードキーあるいはリーフキーによって暗号化され、ＥＫＢ内に配置される。
【００８８】
ユーザデバイスは、サービスデータに記述されているＤＮＫのいずれかのキーを用いて、コンテンツデータとともに配布されるＥＫＢ内に記述されている直近の上位の階層の更新ノードキーを復号し、復号して得たキーを用いて、ＥＫＢ内に記述されているさらにその上の階層の更新ノードキーを復号する。以上の処理を順次行うことで、ユーザデバイスは、更新ルートキーＫＲ’を得ることができる。
【００８９】
上述したように、ツリーのカテゴリ分類により、１つのノードを頂点として、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定した構成が可能となり、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、サービスプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が実現される。
【００９０】
さらに、上述のツリー構成のデバイス管理によるＥＫＢ配信システムを適用して、複数のカテゴリに基づくＥＫＢ配信構成を採用したコンテンツ配信および利用形態について説明する。
【００９１】
図１０を参照して２つのカテゴリについて説明する。図１０に示すように、ルートノード３５０の下段にＴシステムノード３５１を設定し、その下段にＴサービスノード３５２、およびＴハードノード３５３を設定する。Ｔハードノード３５３を頂点としたツリーは、ユーザデバイス機器自体をリーフ３５５として設定し、機器を対象として発行するハード対応ＥＫＢ［ＥＫＢ（Ｈ）］を配信するカテゴリツリーである。一方、Ｔサービスノード３５２を頂点としたツリーは、ユーザデバイス機器に提供するサービスに対応して発行するサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を配信するカテゴリツリーである。
【００９２】
ハード対応ＥＫＢ［ＥＫＢ（Ｈ）］、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］とも、それぞれ正当な権限を持つデバイスに対して与えられるＤＮＫ（Ｄｅｖｉｃｅ Ｎｏｄｅ Ｋｅｙ）すなわち、リーフからＴシステムのノードまでのパス上の各ノードに対応するキーを有することで、各ＥＫＢの復号が可能となる。
【００９３】
［６．コンテンツ購入および試聴処理］
次に、クライアントがコンテンツを購入または試聴する際の処理の詳細について、図１１以下を参照して説明する。
【００９４】
図１１は、クライアントアプリケーション、ブラウザを有するＰＣ等のクライアントと、ショップサーバ、コンテンツサーバ、ライセンスサーバ、および管理システムとの間で実行されるコンテンツ購入処理における通信シーケンスの初期ステップを示している。以下、シーケンス図に示す処理について説明する。
【００９５】
まず、クライアント側において、コンテンツの購入を行なおうとするユーザは、自己のＰＣ等の通信可能な情報処理装置にＵＲＬを指定（ステップ（１））し、ブラウザが介してショップサーバの提示するコンテンツリスト画面（ショップページ）を読み出し（ステップ（２））て、ディスプレイに表示（ステップ（３））する。
【００９６】
クライアントは、ショップサーバの提示するコンテンツリストからコンテンツを選択して、さらに、購入または試聴どちらかの指定（ステップ（４））を行なって、ブラウザを介してショップサーバに要求データを送信（ステップ（５））する。要求データには、コンテンツＩＤ（ＣＩＤ）、ショップサーバ識別子（ＳｈｏｐＩＤ）、および購入または試聴どちらかの指定データが含まれる。
【００９７】
ショップサーバは、クライアントからのコンテンツ購入、または試聴要求を受信すると、管理システムに対して、コンテンツの提供の可否判定を要求（ステップ（６））する。この判定要求には、コンテンツＩＤ（ＣＩＤ）、ショップサーバ識別子（ＳｈｏｐＩＤ）が含まれる。
【００９８】
管理システムは、コンテンツの提供の可否判定要求を受信すると、トランザクションＩＤ（ＴＩＤ）の発行処理（ステップ（７））を実行する。トランザクションＩＤ（ＴＩＤ）の発行処理の詳細を図１２のフローを参照して説明する。
【００９９】
管理システムは、まず、ステップＳ１０１において、乱数を発生し、発生乱数に基づいて、トランザクションＩＤ（ＴＩＤ）を生成する。次に、ステップＳ１０２において、生成したトランザクションＩＤ（ＴＩＤ）と、ショップサーバから指定されたコンテンツＩＤ（ＣＩＤ）とを対応付けてトランザクションデータとして記憶部に格納する。次に、生成したトランザクションＩＤ（ＴＩＤ）をショップサーバに対して出力、発行する。
【０１００】
図１１のシーケンス図に戻る。管理システムは、トランザクションＩＤ（ＴＩＤ）の生成後、生成したトランザクションＩＤ（ＴＩＤ）と価格情報をＴＩＤ情報としてショップサーバに送信（ステップ（８））する。ただし、価格情報は、コンテンツ購入時においてのみ要求される情報であり、コンテンツ試聴処理に際しては、含まれない。ＴＩＤ情報を受信したショップサーバは、クライアントからの要求がコンテンツ購入である場合に、ＴＩＤ情報に含まれる価格に基づいて、課金処理（ステップ（９））を実行する。
【０１０１】
クライアントからの要求がコンテンツ購入ではなく、コンテンツ試聴要求である場合には、この課金処理（ステップ（９））は省略される。
【０１０２】
次に、図１３のシーケンス図を参照して継続する処理について説明する。ショップサーバは、コンテンツ購入処理においては、課金が実行されたことを条件として、またコンテンツ試聴処理においては、管理システムからのＴＩＤ情報の受信を条件として、購入または試聴要求対象のコンテンツのダウンロード許可要求を管理システムに対して送信（ステップ（１０））する。
【０１０３】
管理システムは、ダウンロード許可要求を受信すると、ダウンロード許可要求検証処理（ステップ（１１））を実行する。ダウンロード許可要求検証処理の詳細を図１４のフローを参照して説明する。
【０１０４】
管理システムは、まず、ステップＳ２０１において、受信したダウンロード許可要求に含まれるトランザクションＩＤ（ＴＩＤ）と、先に生成し、記憶部に格納したトランザクションＩＤ（ＴＩＤ）とを照合し、さらにステップＳ２０２において、照合の成立したトランザクションＩＤ（ＴＩＤ）に対応して記録されたコンテンツＩＤ（ＣＩＤ）を取得し、ステップＳ２０３において、ＣＩＤに対応するコンテンツのダウンロード許可を発行する。
【０１０５】
図１３のシーケンス図に戻り、説明を続ける。管理システムは、ダウンロード許可要求検証処理（ステップ（１１））の後、コンテンツのダウンロード許可をショップサーバに対して発行（ステップ（１２））する。ダウンロード許可には、トランザクションＩＤ（ＴＩＤ）、コンテンツサーバＵＲＬ（Ｃ−ＵＲＬ）、ライセンスサーバＵＲＬ（Ｌ−ＵＲＬ）、コンテンツＩＤ（ＣＩＤ）、利用権情報ＩＤ（ＵＩＤ）、商品（コンテンツ）ＵＲＬ（Ｓ−ＵＲＬ）、サービスＩＤが含まれる。
【０１０６】
ショップサーバは、管理システムからダウンロード許可を受信すると、クライアントアプリケーションにおけるコンテンツの利用（再生処理等）プログラムを起動させるための起動ファイルを生成してクライアントのブラウザを介してクライアントアプリケーションに対して送付する。
【０１０７】
起動ファイルの例を図１５を参照して説明する。起動ファイル３６０は、先に管理システムが生成したトランザクションＩＤ（ＴＩＤ）、クライアントが購入あるいは試聴するコンテンツＩＤ（ＣＩＤ）、管理システムが生成したダウンロード許可情報に含まれる利用権情報ＩＤ（ＵＩＤ）、管理システムが生成したダウンロード許可情報に含まれるサービスＩＤ、ライセンスサーバＵＲＬ、商品（コンテンツ）ＵＲＬ、さらに、処理が購入であるか試聴であるかの識別データが含まれる。
【０１０８】
なお、処理が購入であるか試聴であるかの識別データとしては、起動ファイルに設定される拡張子を購入であるか試聴であるかによって区別して設定し、これをクライアントアプリケーションが判別して、それぞれのアプリケーションを起動するようにしてもよい。
【０１０９】
クライアントアプリケーションは、起動ファイルに応じて、アプリケーションを起動（ステップ（１５））する。
【０１１０】
クライアントアプリケーションにおいて実行するアプリケーション起動処理について、図１６を参照して説明する。ステップＳ３０１において、まず、起動ファイルに設定されたサービスＩＤ対応のサービスデータをクライアントシステムとしての情報処理装置に格納されているか否かを判定する。
【０１１１】
サービスデータは、クライアントが各種のサービス、例えばコンテンツ利用サービスを受領したい場合、ライセンスサーバから受領するもので、例えば特定のサービスプロバイダの提供サービスの一括したサービス利用権を認めるデータである。図１７（ａ）にサービスデータのデータ構成例を示す。
【０１１２】
図１７（ａ）に示すように、サービスデータ３７０には、ＥＫＢ配信ツリーにおいて設定されるクライアントに固有のリーフＩＤ、サービス識別子としてのサービスＩＤ、さらにデバイスノードキー（ＤＮＫ）をルートキー（Ｋｒｏｏｔ）で暗号化したデータ、Ｅ（Ｋｒｏｏｔ，ＤＮＫ）が含まれる。サービスデータを受領するためには、クライアントは、ライセンスサーバに対する登録処理が必要とされる。登録処理は、図１３に示す処理ステップ（１５）、（１６）の処理に対応する。
【０１１３】
図１６に示すステップＳ３０１において、サービスＩＤ対応のサービスデータを保有していないと判定すると、ステップＳ３０２において登録処理を実行して、サービスデータを受領する。
【０１１４】
さらに、この登録処理時に、デフォルト利用権情報がライセンスサーバからクライアントに対して発行される。利用権情報は、通常は、購入コンテンツの利用条件を格納し、コンテンツの購入に対応して発行されるものであるが、デフォルト利用権情報は、コンテンツの購入を条件として発行するものではなく、クライアントの登録処理、あるいはサービスデータの発行処理を条件として発行する。このデフォルト利用権情報は、後段で説明するコンテンツの試聴処理の際の有効なコンテンツ利用権情報として適用される。
【０１１５】
図１７（ｂ）に利用権情報のデータ構成例を示す。図１７（ｂ）に示すように、利用権情報３７１には、利用権情報識別子としての利用権情報ＩＤ、発行日時情報としてのタイムスタンプ、クライアントに固有のリーフＩＤ、コンテンツ対応である場合は、コンテンツＩＤ、さらに、利用条件対象コンテンツ種別情報が格納される。
【０１１６】
デフォルト利用権情報の場合は、特定の購入コンテンツに対応して発行されるものではないため、コンテンツＩＤは省略、あるいは試聴可能なコンテンツに共通なＩＤが設定される。また、利用条件対象コンテンツ種別情報として、例えば試聴フラグがオン（ＯＮ）として設定されたコンテンツについての利用が許可される設定とする。コンテンツ３７２には図１７（ｃ）に示すように、試聴フラグ３７３が設定され、試聴フラグ３７３がオン（ＯＮ）の設定コンテンツであれば、試聴が許可されたコンテンツであることを示し、試聴フラグがオフ（ＯＦＦ）の設定コンテンツであれば、試聴が許可されていないコンテンツであることを示す。
【０１１７】
クライアントアプリケーションは、試聴コンテンツ再生時には、デフォルト利用権情報を参照して、再生許可の有無を判定するとともに、コンテンツのフラグの検証を実行して、コンテンツの再生を行なうことになる。この処理については、後段で説明する。
【０１１８】
図１６の処理フローに戻りアプリケーション起動処理の処理手順について説明する。ステップＳ３０２において、登録処理、すなわちライセンスサーバからのサービスデータ、デフォルト利用権情報の取得が終了すると、ステップＳ３０３において、ショップサーバから受信した起動ファイルが、購入用アプリケーションの起動ファイルであるか、試聴用アプリケーションの起動ファイルであるかを判別する。購入用アプリケーションの起動ファイルである場合は、ステップＳ３０４に進み購入用アプリケーションを実行し、試聴用アプリケーションの起動ファイルである場合は、ステップＳ３０５に進み試聴用アプリケーションを実行する。
【０１１９】
次に、購入用アプリケーションの実行シーケンスについて、図１８のシーケンス図を参照して説明する。
【０１２０】
購入処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（２１））する。これは、先にクライアントが購入要求を行なったコンテンツであり、利用権情報（図１７（ｂ）参照）に記録されたコンテンツＩＤ（ＣＩＤ）に対応するコンテンツである。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１２１】
コンテンツサーバは、コンテンツダウンロード要求を受信すると、ＣＩＤに対応するコンテンツ情報をクライアントに送信（ステップ（２２））する。このコンテンツ情報は、暗号化コンテンツを含み、図１７（ｃ）に示すように、コンテンツキー：Ｋｃで暗号化されたコンテンツデータ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキー：Ｋｃをルートキー：Ｋｒｏｏｔで暗号化したデータ：Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）、さらに：ルートキー：Ｋｒｏｏｔを取得するためのＥＫＢ、さらに試聴フラグデータ、サービスＩＤ等の情報が付加されたファイルである。
【０１２２】
コンテンツ情報を受領したクライアントは、受信コンテンツに対応する利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求をライセンスサーバに対して送信（ステップ（２３））する。この要求には、先にショップサーバから受領した起動ファイル（図１５参照）中に含まれる利用権情報ＩＤ（ＵＩＤ）、クライアント識別データとしてのリーフＩＤ、および先にショップサーバから受領した起動ファイル（図１５参照）中に含まれるトランザクションＩＤ（ＴＩＤ）が含まれる。
【０１２３】
ライセンスサーバは、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求を受信すると、管理システムに対して、注文照会処理（ステップ（２４））を行なう。この要求には、利用権情報ＩＤ（ＵＩＤ）、トランザクションＩＤ（ＴＩＤ）が含まれる。注文照会を受信した管理サーバは、注文照会応答として、利用権情報ＩＤ（ＵＩＤ）に対応する利用条件を設定した応答情報をライセンスサーバに送信（ステップ（２５））する。
【０１２４】
応答情報を受信したライセンスサーバは、コンテンツ利用条件を設定した利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成して、クライアントに対して発行（ステップ（２６））する。なお、コンテンツ利用条件とは、コンテンツの再生回数、期限、外部機器に対するコピー、チェツクアウト処理等の各種処理の許可情報によって構成される。
【０１２５】
利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を受信したクライアントは、先にコンテンツサーバから受信したコンテンツについて、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）に記録された利用条件に基づいてコンテンツの利用が可能となる。ユーザからコンテンツＩＤ（ＣＩＤ）、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）ＩＤを指定したコンテンツ再生要求（ステップ（２７））があると、クライアントアプリケーションは、利用条件に従ったコンテンツ再生を実行（ステップ（２８））する。
【０１２６】
基本的なコンテンツ再生処理の手順について、図１９を参照して説明する。前述の説明から理解されるように、コンテンツサーバ３８２からクライアント３８３に対してコンテンツが提供されるとともに、ライセンスサーバ３８１からクライアント３８３にライセンスとして、サービスデータ、利用権情報（ＵｓａｇｅＲｉｇｈｔ）が与えられる。
【０１２７】
コンテンツは、コンテンツキー：Ｋｃにより、暗号化されており（Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキーＫｃは、ＥＫＢから取得可能なルートキーＫｒｏｏｔから得られるキーである。
【０１２８】
クライアント３８３は、ライセンスサーバから受領したサービスデータからデバイスノードキー（ＤＮＫ）を取得し、取得したＤＮＫに基づいてコンテンツファイルのＥＫＢを復号して、ルートキー：Ｋｒｏｏｔを取得し、さらに、取得したルートキー：Ｋｒｏｏｔを用いて、Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）を復号してコンテンツキー：Ｋｃを取得し、取得したコンテンツキー：Ｋｃをにより暗号化コンテンツ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）の復号処理を実行してコンテンツを取得し、再生する。
【０１２９】
サービスデータ、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）と対応付けたコンテンツ再生処理の詳細について、図２０を参照して説明する。
【０１３０】
図２０は、ハード対応ＥＫＢ［ＥＫＢ（Ｈ）］、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を適用したコンテンツの復号処理に基づくコンテンツ利用処理シーケンスを説明した図である。
【０１３１】
図２０に示すサービスデータ４０１、および利用権情報４０３は、ライセンスサーバカラ受領するデータであり、暗号化コンテンツファイル４０２はコンテンツサーバから受領するデータである。サービスデータ４０１は、リーフ識別子としてのリーフＩＤ、適用するＥＫＢのバージョン、さらに、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の復号に必要なサービス対応デバイスノードキー（ＳＤＮＫ）を、ハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’によって暗号化したデータＥ（Ｋｒｏｏｔ’，ＳＤＮＫ）を格納している。
【０１３２】
暗号化コンテンツファイル４０２は、サービス対応のカテゴリツリーに対応して設定されるルートキーＫｒｏｏｔを格納したサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］、ルートキーＫｒｏｏｔでコンテンツＩＤ（ＣＩＤ）と、コンテンツ暗号処理および復号処理に適用するコンテンツキー（Ｋｃ）とを暗号化したデータＥ（Ｋｒｏｏｔ，ＣＩＤ＋Ｋｃ）、および、コンテンツ（Ｃｏｎｔｅｎｔ）をコンテンツキーＫｃで暗号化したデータＥ（Ｋｃ，Ｃｏｎｔｅｔ）を含むファイルである。
【０１３３】
また、利用権情報４０３は、リーフＩＤと、コンテンツの利用条件情報を格納したデータである。コンテンツの利用条件情報には、コンテンツに対応して設定される利用期間、利用回数、コピー制限等の様々な利用条件が含まれる。利用権情報４０３を受領したユーザデバイスは、利用権情報をコンテンツに対応するセキュリティ情報として格納するか、あるいは、コンテンツの索引データとしてのＡＶインデックスファイル内に格納する。
【０１３４】
例えば、ＰＣ等の大容量の記憶手段を有し、プロセッサ等の処理能力が高いユーザデバイスにおいては、利用権情報をコンテンツに対応するセキュリティ情報として格納することが可能であり、すべての利用権情報を格納して、コンテンツ利用の際にすべての利用権情報を参照した処理を行なうことが好ましい。一方、大容量の記憶手段を持たず、またプロセッサ等の処理能力が低いポータブルデバイス（ＰＤ）等のユーザデバイスにおいては、選択された情報からなる利用権情報４０３をコンテンツの索引データとしてのＡＶインデックスファイル内に格納して、コンテンツ利用の際にＡＶインデックスファイル内の利用条件情報を参照した処理を行なう等の処理が可能である。
【０１３５】
ユーザデバイスは、図２０に示すステップＳ５０１において、ハード対応のデバイスノードキー（ＨＤＮＫ）４１２を適用して、ハード対応のＥＫＢ（Ｈ）４１１の復号処理を実行し、ＥＫＢ（Ｈ）４１１から、ハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’を取得する。ＤＮＫを適用したＥＫＢの処理は、先に図５を参照して説明した手法に従った処理となる。
【０１３６】
次に、ステップＳ５０２において、ＥＫＢ（Ｈ）から取り出したルートキーＫｒｏｏｔ’を用いて、サービスデータ４０１内の暗号化データＥ（Ｋｒｏｏｔ’，ＳＤＮＫ）の復号処理を実行し、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の処理（復号）に適用するデバイスノードキー（ＳＤＮＫ）を取得する。
【０１３７】
次に、ステップＳ５０３において、サービスデータから取り出したデバイスノードキー（ＳＤＮＫ）を用いて、暗号化コンテンツファイル４０２内に格納されたサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］の処理（復号）を実行し、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］内に格納されたサービス対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔを取得する。
【０１３８】
次に、ステップＳ５０４において、サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］から取り出したルートキーＫｒｏｏｔを用いて、暗号化コンテンツファイル４０２内に格納された暗号化データＥ（Ｋｒｏｏｔ，ＣＩＤ＋Ｋｃ）の復号処理を実行し、コンテンツＩＤ（ＣＩＤ）と、コンテンツキー（Ｋｃ）を取得する。
【０１３９】
次に、ステップＳ５０５において、暗号化コンテンツファイル４０２から取り出したコンテンツＩＤ（ＣＩＤ）と、利用権情報内に格納されたコンテンツＩＤのマッチング（照合）処理を実行する。マッチング処理により、コンテンツの利用が可能であることが確認されると、ステップＳ５０６において、暗号化コンテンツファイル４０２から取り出したコンテンツキー（Ｋｃ）を適用して、暗号化コンテンツファイル４０２に格納された暗号化コンテンツＥ（Ｋｃ，Ｃｏｎｔｅｎｔ）を復号してコンテンツの再生を行なう。
【０１４０】
上述したように、コンテンツ利用機器としてのハードウェアに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのハード対応ＥＫＢ［ＥＫＢ（Ｈ）］と、コンテンツ利用サービスに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］をそれぞれ個別にユーザに対して提供し、それぞれのＥＫＢに対する正当なＤＮＫを有するユーザのみがサービスの利用を行なうことが可能となる。
【０１４１】
サービス対応ＥＫＢ［ＥＫＢ（Ｓ）］を復号するためのＤＮＫ、すなわちＳＤＮＫは、コンテンツに対応したサービスデータ４０１として提供可能であり、またＳＤＮＫを正当なハードウェア対応のＤＮＫ、すなわちＨＤＮＫを有する機器のみが取得可能なハード対応カテゴリツリーに対応して設定されるルートキーＫｒｏｏｔ’を適用して暗号化した構成としたので、正当なＨＤＮＫを有するユーザデバイスのみが、ＳＤＮＫを取得でき、サービスが利用となる。
【０１４２】
また、コンテンツ利用において、暗号化コンテンツファイル４０２から取得されるコンテンツ識別子（ＣＩＤ）と、利用権情報から取得されるＣＩＤとのマッチング処理を実行する構成としたので、利用権情報４０３を取得してＣＩＤ情報を格納していることがコンテンツ再生プロセスの必須用件とすることが可能となり、利用条件に従ったコンテンツ利用が実現される。
【０１４３】
次に、クライアントアプリケーションの処理が試聴処理の実行アプリケーションである場合の処理について、図２１のシーケンス図を参照して説明する。
【０１４４】
試聴処理の場合、コンテンツ購入処理と同様、コンテンツ情報ファイル（図１９参照）を取得してクライアントシステムの記憶部に格納し、その後、購入コンテンツと同様の処理によって再生することも可能であるが、記憶部に格納することなく、ストリーミング再生処理を実行する例について、図２１を参照して説明する。
【０１４５】
ストリーミング試聴処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（３１））する。これは、先にクライアントが試聴要求を行なったコンテンツである。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１４６】
コンテンツサーバは、ストリーミング再生の場合には、コンテンツの部分データ（コンテンツパート）を次々にクライアントに対して送信（ステップ（３２））する。コテンツパートを受信したクライアントは、受信コンテンツに対する再生処理を実行（ステップ（３３））し、後続のコンテンツパートの要求をコンテンツサーバに送信する。この処理を連続して実行することによりストリーミング再生が行なわれる。
【０１４７】
試聴再生処理の手順について、図２２のフローを参照して説明する。ステップＳ７０１において、クライアントアプリケーションは、コンテンツサーバから受信した試聴コンテンツファイル中からサービスＩＤを取得する。
【０１４８】
次にステップＳ７０２において、抽出したサービスＩＤに対応するデフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）（図１７（ｂ）参照）の有無を判定する。デフォルト利用権情報は、クライアントの登録処理時に、サービスデータ（図１７（ａ）参照）とともに、ライセンスサーバから送信される利用権情報であり、購入コンテンツに対応して発行される利用権情報と異なり、試聴可能なコンテンツに対して利用される利用権情報である。
【０１４９】
コンテンツ試聴においては、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）を保有することが試聴実行許可条件であり、デフォルト利用権情報を保有していない場合は、ステップＳ７０５に進み、エラーとしてコンテンツ再生が実行されず処理を終了する。
【０１５０】
デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）が格納されている場合は、ステップＳ７０３において、デフォルト利用権情報を検証し、利用権情報の記録を確認する。デフォルト利用権情報には、例えば試聴フラグオンのコンテンツの試聴許可、あるいは試聴可能なコンテンツＩＤ情報が格納されており、これらの情報を取得する。
【０１５１】
次にステップＳ７０４において、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）の利用条件に基づいてコンテンツが再生される。なお、再生処理は、前述の図１９、図２０を参照して説明したように、コンテンツサーバから受信する暗号化コンテンツの復号処理を伴う再生処理となる。
【０１５２】
なお、コンテンツの購入処理を伴わない試聴処理においても、図２０を参照して説明した購入コンテンツの再生と同様、ＥＫＢ処理に基づくキー取得処理によってコンテンツ復号用のキーを取得することが必要となる。例えば、コンテンツ利用機器としてのハードウェアに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのハード対応ＥＫＢ［ＥＫＢ（Ｈ）］と、コンテンツ利用サービスに対応して設定されたカテゴリツリーに対応するＥＫＢとしてのサービス対応ＥＫＢ［ＥＫＢ（Ｓ）］に対する正当なＤＮＫを有するユーザのみがコンテンツ再生を実行可能とする構成が適用でき、試聴においても再生権限を限定した範囲として設定可能となる。
【０１５３】
上述したように、クライアントは、ライセンスサーバに対する登録処理の際にデフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）を取得し、コンテンツの購入処理を伴わない、試聴処理の際にデフォルト利用権情報に基づいてコンテンツ再生を可能とした構成であるので、ユーザは、コンテンツの購入を実行することなく、コンテンツの試聴再生が可能となり、また、試聴が許可されるクライアントは、ライセンスサーバに対する登録処理を行ない、デフォルト利用権情報を有するクライアントに限定されることになるので、試聴データが無秩序に氾濫してしまうことが防止される。
【０１５４】
なお、図２１のシーケンス図では、ストリーミング再生の例を示したが、試聴データをクライアントの記憶媒体に格納し、再生時に、デフォルト利用権情報（Ｄｅｆａｕｌｔ Ｕｓａｇｅ Ｒｉｇｈｔ）の有無を判定して、デフォルト利用権情報の記録に基づいて再生を行なう構成とすることも可能である。
【０１５５】
［７．バックアップ／リストア処理］
次にクライアントが購入したコンテンツまたはコンテンツ利用権情報についてのバックアップ処理、リストア処理について説明する。
【０１５６】
リストア処理は、クライアントのコンテンツ購入時、あるいは購入後の処理として実行されるコンテンツ対応のライセンス情報、すなわちサービスデータ、利用権情報の再取得、格納処理、あるいはコンテンツの再取得処理として実行される。
【０１５７】
処理態様としては、サービスデータ、利用権情報、コンテンツのいずれかの再取得、あるいはこれらの全データの再取得が可能である。以下に説明する実施例においては、サービスデータ、利用権情報、コンテンツ全データの再取得、格納処理シーケンス例を説明するが、必ずしもこれら全データを再取得する処理に限らず、いずれかのデータのみを選択的に再取得することも可能である。
【０１５８】
図２３以下を参照して、バックアップ／リストア処理の詳細について説明する。図２３は、クライアントアプリケーション、ブラウザを有するＰＣ等のクライアントと、ショップサーバ、コンテンツサーバ、ライセンスサーバ、および管理システムとの間で実行されるバックアップ／リストア処理における通信シーケンスの初期ステップを示している。以下、シーケンス図に示す処理について説明する。
【０１５９】
クライアントは、前述したコンテンツ購入処理に従って、正規にコンテンツ購入を行なったものとする。図２３に示すシーケンスは、コンテンツ購入に続いて実行されるシーケンスである。
【０１６０】
コンテンツ購入処理を実行したクライアントは、バックアップ／リストアデータの取得のためのデータファイルとしてのリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を生成（ステップ（５０））する。リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］の構成を図２４に示す。
【０１６１】
図２４に示すように、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］は、ＥＫＢ配信ツリーにおけるクライアント識別データとしてのリーフＩＤと、ハッシュ（ｈａｓｈ）値、例えばＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）からなる検証データによって構成される。クライアントアプリケーションは、管理システムと共有する秘密の鍵を適用してリーフＩＤに基づく検証用データとしてのハッシュ値あるいはＭＡＣを算出し、リーフＩＤと検証用データからなるリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を生成する。
【０１６２】
メッセージ認証符号（ＭＡＣ：Ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）は、データの改竄検証用のデータとして生成されるものである。ＤＥＳ暗号処理構成を用いたＭＡＣ値生成例を図２５に示す。図２５の構成に示すように対象となるメッセージを８バイト単位に分割し、（以下、分割されたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、まず、初期値（Ｉｎｉｔｉａｌ Ｖａｌｕｅ（以下、ＩＶとする））とＭ１を排他的論理和する（その結果をＩ１とする）。次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１とする）を用いて暗号化する（出力をＥ１とする）。続けて、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２をＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出力Ｅ２）。以下、これを繰り返し、全てのメッセージに対して暗号化処理を施す。最後に出てきたＥＮがメッセージ認証符号（ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ））となる。
【０１６３】
ＭＡＣ値は、その生成元データが変更されると、異なる値になり、検証対象のデータ（メッセージ）に基づいて生成したＭＡＣと、記録されているＭＡＣとの比較を行い、一致していれば、検証対象のデータ（メッセージ）は変更、改竄がなされていないことが証明される。
【０１６４】
図２３のシーケンスに戻り説明を続ける。クライアントは、ブラウザを介して管理システムの提供するリストアページにアクセス（ステップ（５１））し、管理システムは、リストアページをクライアントのブラウザに提示（ステップ（５２））する。管理システムの提示するリストアページは、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］のアップロード処理を実行する機能を持つページである。
【０１６５】
クライアントは、管理システムの提示するリストアページにおいて、クライアントアプリケーションの生成したリストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］をアップロードする。リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］は、図２４を参照して説明したように、ＥＫＢ配信ツリーにおけるクライアント識別データとしてのリーフＩＤと、例えばＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）からなるハッシュ（ｈａｓｈ）値によって構成される。
【０１６６】
管理システムは、リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］を受信すると、クライアントと共有する秘密鍵を用いて、リーフＩＤに対するハッシュ値を算出し、算出ハッシュ値と、受信ハッシュ値の照合処理を行ない、受信データの検証（ステップ（５４））を行なう。算出ハッシュ値と、受信ハッシュ値が適合したことを条件として、バックアップ／リストア用の起動ファイルをクライアントに送信（ステップ（５５））する。起動ファイルの構成は、先に図１５を参照して説明したと同様のファイル構成を持つ。
【０１６７】
起動ファイルは、ブラウザからクライアントアプリケーションに渡され（ステップ（５６））、起動ファイルの記述、あるいは拡張子によって判別選択されるバックアップ／リストア実行プログラムを起動し、リストア処理を実行（ステップ（５７））する。
【０１６８】
バックアップ／リストア処理の処理対象としては、サービスデータ、コンテンツ、コンテンツ利用権情報がある。サービスデータは前述したようにライセンスサーバに対する登録処理によって取得可能であり、コンテンツはコンテンツサーバから取得可能である。また、利用権情報は、ライセンスサーバから取得される。バックアップ／リストア処理においても、これらの各データは、それぞれのサーバから取得することになる。
【０１６９】
まず、図２６を参照して、バックアップ／リストア用サービスデータの取得処理について説明する。基本的に、この処理は、先に説明したコンテンツ購入時のクライアント登録処理と同様の手続きに従ったものとなる。
【０１７０】
まず、クライアントアプリケーションは、登録要求をライセンスサーバに送信（ステップ（６１））する。この登録要求には、管理システムが生成した起動ファイル中に含まれるトランザクションＩＤ（ＴＩＤ）が含まれる。
【０１７１】
登録要求を受信したライセンスサーバは、トランザクションＩＤ（ＴＩＤ）に基づいて、バックアップ／リストア用サービスデータの取得であることを識別し、管理システムに対してサービス事前データ、すなわちサービスデータのバックアップ／リストア用データの割当要求（ステップ（６２））を行なう。管理システムは、同じトランザクションＩＤに基づいて処理を実行したクライアント端末があるか否かを管理データに基づいて検証し、ある場合には、これらを対応付けて記憶（ステップ（６３））する。これは、バックアップ／リストア処理の処理回数の上限（例えば３回）を設定し、上限を超える処理要求の場合には、処理を実行しないという設定を可能とするためである。
【０１７２】
管理データの更新処理を実行した管理システムは、サービス事前データ割当応答をライセンスサーバに送信（ステップ（６４））する。これは、バックアップ／リストア用サービスデータの発行許可情報として送信されるものである。
【０１７３】
サービス事前データ割当応答を受信したライセンスサーバは、バックアップ／リストア用サービスデータのクライアントに対する発行処理を実行（ステップ（６５））する。サービスデータは、先に図１７（ａ）を参照して説明したように、サービスデータ３７０には、ＥＫＢ配信ツリーにおいて設定されるクライアントに固有のリーフＩＤ、サービス識別子としてのサービスＩＤ、さらにデバイスノードキー（ＤＮＫ）をルートキー（Ｋｒｏｏｔ）で暗号化したデータ、Ｅ（Ｋｒｏｏｔ，ＤＮＫ）が含まれる。
【０１７４】
さらに、この処理時に、デフォルト利用権情報（図１７（ｂ）参照）もライセンスサーバからクライアントに対して発行される。先に説明したように、利用権情報は、通常は、購入コンテンツの利用条件を格納し、コンテンツの購入に対応して発行されるものであるが、デフォルト利用権情報は、コンテンツの購入を条件として発行するものではなく、クライアントの登録処理、あるいはサービスデータの発行処理を条件として発行する。このデフォルト利用権情報は、前述したようにコンテンツの試聴処理の際の有効な利用権情報として適用される。
【０１７５】
ライセンスサーバからサービスデータ、デフォルト利用権情報を受領したクライアントは、これらのデータをバックアップ用として、記憶手段に格納（ステップ（６６））する。
【０１７６】
次に、図２７を参照して、コンテンツのバックアップ／リストア処理について説明する。コンテンツのバックアップ／リストア処理実行の場合、クライアントアプリケーションは、コンテンツダウンロード要求をコンテンツサーバに対して実行（ステップ（７１））する。これは、先にクライアントが購入したコンテンツと同一である。クライアントアプリケーションは、コンテンツＩＤ（ＣＩＤ）によりコンテンツを指定してコンテンツダウンロード要求をコンテンツサーバに対して実行する。
【０１７７】
コンテンツサーバは、コンテンツダウンロード要求を受信すると、ＣＩＤに対応するコンテンツ情報をクライアントに送信（ステップ（７２））する。このコンテンツ情報は、暗号化コンテンツを含む情報である。先に図１７（ｃ）を参照して説明したように、コンテンツキー：Ｋｃで暗号化されたコンテンツデータ：Ｅｎｃ（Ｋｃ，Ｃｏｎｔｅｎｔ）、コンテンツキー：Ｋｃをルートキー：Ｋｒｏｏｔで暗号化したデータ：Ｅｎｃ（Ｋｒｏｏｔ，Ｋｃ）、さらに：ルートキー：Ｋｒｏｏｔを取得するためのＥＫＢ、さらに試聴フラグデータ、サービスＩＤ等の情報が付加されたファイルである。
【０１７８】
コンテンツ情報を受領したクライアントは、受信コンテンツに対応する利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求をライセンスサーバに対して送信（ステップ（７３））する。この要求には、起動ファイル（図１５参照）中に含まれる利用権情報ＩＤ（ＵＩＤ）、クライアント識別データとしてのリーフＩＤ、トランザクションＩＤ（ＴＩＤ）が含まれる。
【０１７９】
ライセンスサーバは、利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）の取得要求を受信すると、管理システムに対して、注文照会処理（ステップ（７４））を行なう。この要求には、利用権情報ＩＤ（ＵＩＤ）、トランザクションＩＤ（ＴＩＤ）が含まれる。注文照会を受信した管理サーバは、注文照会応答として、利用権情報ＩＤ（ＵＩＤ）に対応する利用条件を設定した応答情報をライセンスサーバに送信（ステップ（７５））する。
【０１８０】
応答情報を受信したライセンスサーバは、コンテンツ利用条件を設定した利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を生成して、クライアントに対して再発行（ステップ（７６））する。なお、コンテンツ利用条件とは、コンテンツの再生回数、期限、外部機器に対するコピー、チェツクアウト処理等の各種処理の許可情報によって構成される。
【０１８１】
利用権情報（Ｕｓａｇｅ Ｒｉｇｈｔ）を受信したクライアントは、先に受信したコンテンツと利用権情報とを記憶手段にバックアップデータとして格納する。
【０１８２】
なお、バックアップ／リストア処理において、ライセンスサーバが発行する利用権情報は、正規なコンテンツ購入処理に際して発行する利用権情報とは異なる利用条件を設定したものとしてもよい。例えば、正規なコンテンツ購入時に発行する利用権情報に含まれる利用条件より厳しい条件、例えば利用期間の制限、コピー禁止、あるいはチェックアウト禁止といった条件を設定してバックアップ／リストア処理用の利用権情報を設定発行してもよい。
【０１８３】
［８．リコメンドファイルによるコンテンツの二次配信］
次に、正規にコンテンツを購入したクライアントが、購入コンテンツを他のクライアントに提供するいわゆるコンテンツ二次配信を実行し、コンテンツ利用権をライセンスサーバから新たに配布することで、二次配信コンテンツを受領したクライアントにおいても正当なコンテンツ利用権を有することを条件としてコンテンツ利用を可能とし、さらに、コンテンツサーバからのコンテンツ配信負荷の軽減を実現した構成について説明する。
【０１８４】
前述したように、コンテンツを再生利用するクライアントは、コンテンツを利用するためには、コンテンツサーバから暗号化されたコンテンツを受け取るとともに、ライセンスサーバから、ライセンス情報、すなわちサービスデータと、コンテンツに対応する利用権情報を受領することが必要となる。
【０１８５】
ライセンス情報、すなわちサービスデータおよび利用権情報は、データ容量の小さいデータであるため、インターネット等の通信網を介した送受信が頻繁に行われたとしてもトラフィックの上昇も少なく、多大な配信時間がかかるといった問題は発生しない。しかし、一方、コンテンツは、音楽データ、画像データ、プログラム等様々であり、そのデータ容量も大きなものとなる。このような大容量のコンテンツを特定のコンテンツサーバから多くのクライアントに送信する場合には、送信時間が長くなり、コンテンツサーバの負担、ネットワークトラッフィックの上昇等、様々な問題を発生させる。また、通信中の通信エラーによるコンテンツ配信エラーのトラブルも発生しかねない。
【０１８６】
以下では、すでに正規なコンテンツを購入したクライアントの保有するコンテンツを他のクライアントに提供、すなわち二次配信を実行し、二次配信によるコンテンツの提供を受けたクライアントが、そのコンテンツのライセンス情報をライセンスサーバから受領することで、コンテンツサーバのクライアントに対するコンテンツ送信の負荷を減少させたシステムについて説明する。
【０１８７】
図２８にコンテンツを正規に受領したクライアントが他のクライアントに提供するコンテンツファイルを生成する処理手順を説明したフローを示す。なお、他のクライアントに提供するコンテンツを含むデータファイルをリコメンドファイルと呼ぶ。リコメンドファイルには、暗号化されたコンテンツを含むコンテンツファイル、および必要に応じてそのコンテンツの説明ファイル（例えばＨＴＭＬファイル）が含まれる。
【０１８８】
図２８の処理フローについて説明する。図２８の処理を実行するクライアントは、前述したコンテンツ購入処理を実行し、正規にコンテンツを購入したクライアント、あるいは、リコメンドファイルを他のクライアントから受領し、その後の手続きにおいて正規なライセンスを取得したクライアントである。図２８の処理は、クライアントアプリケーション（図１のクライアントアプリケーション１２）の１つの実行プログラムとしてクライアントシステムとしての情報処理装置の制御手段（ＣＰＵ等）による制御の下に実行される。ステップＳ８０１において、クライアントは、自己のクライアント装置のディスプレイにリコメンドファイル作成画面を表示する。
【０１８９】
リコメンドファイル作成画面例を図２９に示す。クライアントが正規購入し、再生可能なコンテンツリスト６５１が中央に表示され、リコメンドファイルを生成する場合は、このコンテンツリスト６５１からコンテンツを選択（ステップＳ８０２）し、右側のリスト６５４にタイトル等を表示させる。コンテンツリスト６５１とリスト６５４間の移動処理は、移動スイッチ６５２、６５３の操作によって実行される。
【０１９０】
リコメンドファイル生成対象コンテンツが選択されると、ステップＳ８０３において、リコメンドファイル作成ボタン６５５が押下される。リコメンドファイル作成ボタン６５５が押下されると、ステップＳ８０４において、リコメンドファイル内にコンテンファイルに併せて説明ファイル、例えばＨＴＭＬによって記述された説明ファイルを生成格納するか否かを選択する。これはユーザが任意に選択可能である。
【０１９１】
リコメンドファイルには、図３０（ａ）に示すように、暗号化コンテンツを含むコンテンツファイル７２１とコンテンツ説明ファイル７２２とを組み合わせたリコメンドファイル７２０構成と、図３０（ｂ）に示すように、暗号化コンテンツを含むコンテンツファイル７２１のみからなるリコメンドファイル７３０構成との２つの態様があり、クライアントはその態様を自由に選択可能となる。
【０１９２】
ステップＳ８０４において、コンテンツ説明用ファイルの作成をしないと選択した場合は、図３０（ｂ）に示すコンテンツファイル７２１のみからなるリコメンドファイル７３０が生成される。
【０１９３】
コンテンツファイルの構成を図３１に示す。コンテンツファイル（ＭＱＴファイル）７２１には、暗号化コンテンツと、コンテンツ付加情報としてのメタ情報、さらにコンテンツ購入可能なショップを示すショップサーバＵＲＬ、コンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）が含まれる。
【０１９４】
なお、コンテンツファイルに格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーである。
【０１９５】
一方、ステップＳ８０４において、コンテンツ説明用ファイル作成を選択した場合は、ステップＳ８０６に進み、コンテンツ説明ファイル（ＨＴＭＬファイル）生成用の説明データ（メタデータ）をコンテンツ管理テーブルから取得する。コンテンツに対応するコンテンツ説明データは、上述したように暗号化コンテンツとともに、コンテンツファイル内にも格納されているが、正規にコンテンツ利用権を取得したクライアントは、コンテンツフィルから取り出したコンテンツ対応のメタデータをコンテンツ管理データとして、別ファイルに格納管理しており、リコメンドファイルにおいて生成される説明ファイル用のメタデータは、このコンテンツ管理データから抽出される。
【０１９６】
ステップＳ８０７において、コンテンツ管理データから抽出したメタデータを、クライアントアプリケーションに設定されたテンプレートＨＴＭＬファイルに貼り付ける処理を実行し、コンテンツ対応の説明用ＨＴＭＬファイルを生成し、ステップＳ８０８において、コンテンツファイルと説明用ＨＷＭＬファイルからなるリコメンドファイルを生成する。
【０１９７】
コンテンツ説明用データとしてのＨＴＭＬファイルの表示構成例を図３２に示す。図３２に示す例は、コンテンツが音楽データの場合の例である。説明用ファイルは、図３２に示すように、音楽コンテンツの楽曲タイトル、アーティスト、発売元等の情報リスト、さらに、各種の操作、処理に関する説明が記述されている。リコメンドファイルを他のクライアントから受理したクライアントは、まずこの説明ファイルをオープンすることになる。
【０１９８】
リコメンドファイルに格納されたコンテンツは暗号化されたコンテンツであり、正規なライセンス情報、すなわちサービスデータとコンテンツ対応の利用権情報を取得していない場合には再生することはできない。従って、リコメンドファイルを受領したクライアントがリコメンドファイルに格納されたコンテンツを利用する場合には、ライセンス情報を取得する手続きを実行することになる。
【０１９９】
このライセンス情報取得処理について、図３３、図３４の処理フローを参照して説明する。リコメンドファイルを受領したクライアントは、図３２に示す説明用ファイル（ＨＴＭＬファイル）をオープンし、試聴、購入コンテンツ配信サイトボタン７３１をクリック（ステップＳ８１１）する。このクリック処理により、クライアントアプリケーションが起動（ステップＳ８１２）し、同じリコメンドファイルに格納されたコンテンツファイル（ＭＱＴファイル）（図３１参照）を読み出して、コンテンツファイルからコンテンツＩＤ（ＣＩＤ）とショップＵＲＬを抽出（ステップＳ８１３）する。
【０２００】
このように、コンテンツ説明用ファイルの試聴、購入コンテンツ配信サイトボタン７３１は、コンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータとして構成されている。従って、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【０２０１】
ステップＳ８１４において、コンテンツファイルから抽出したコンテンツＩＤ（ＣＩＤ）に基づいて、コンテンツファイル名を設定する。これはクライアントアプリケーションにおいて予め設定されたファイル名設定処理として実行され、例えばコンテンツのタイトル、アーティスト名、あるいはその複合データ等が適用される。ステップＳ８１５では、ステップＳ８１４５で設定したファイル名のコンテンファイルがクライアントの記憶部に格納される。
【０２０２】
次に、ステップＳ８１６において、ステップＳ８１３でコンテンツファイルから抽出したショップＵＲＬがブラウザに渡され、ブラウザは受領ＵＲＬに対応するショップページをショップサーバから読み出す。
【０２０３】
図３４の処理フローのステップＳ８３１において、ショップ画面がクライアントのディスプレイに表示される。以下の処理は、基本的には、前述したコンテンツの購入処理、試聴処理のいずれかの処理と同様であり、先に図１１、図１３、図１８、図２１に従って説明した処理に従うことになる。ただし、コンテンツ自体はすでにコンクライアントが、リコメンドファイルから取得済みであるので、コンテンツサーバカらのコンテンツ受領処理は、省略される。
【０２０４】
一連の処理の概略は、図３４の処理フローのステップＳ８３２以下に示す処理となる。まず、クライアントがショップサーバの提示するショップ画面において購入を指定してショップサーバに購入要求を出力すると、ショップサーバから購入用起動ファイルが送信される。これは、先に、図１５を参照して説明した起動ファイルと同様の構成を持つ。
【０２０５】
次に、ステップＳ８３３において、起動ファイルからコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）を取得する。次に、ステップＳ８３４において、コンテンツＩＤ（ＣＩＤ）に基づいて、コンテンツファイル名を算出する。クライアント装置にコンテンツを格納する際のコンテンツファイル名は、先の図３３のフローの説明で述べたようにコンテンツＩＤ（ＣＩＤ）に基づいて設定されることがクライアントアプリケーションにおいて規定され、ＣＩＤとファイル名の対応付けがなされている。
【０２０６】
ステップＳ８３５において、コンテンツＩＤ（ＣＩＤ）から算出したファイル名と同一のファイル名のファイルが自己のクライアント装置の記憶部に格納されているか否かを判定する。コンテンツが格納されていない場合は、ステップＳ８３７に進み、コンテンツサーバに接続して、コンテンツダウンロードを行なうことになる。この処理は、先に説明したコンテンツ購入時の処理と同様である。
【０２０７】
しかし、リコメンドファイルを受領しているクライアントは、先の図３３のフロー忠のステップＳ８１４，Ｓ８１５において、所定のファイル名を設定したコンテンツファイルを記憶部に格納しており、コンテンツのダウンロード処理は省略され、ステップＳ８３６のコンテンツ利用権情報の取得処理を実行し処理を終了することが可能となる。
【０２０８】
クライアントがコンテンツ再生を実行する際は、前述したように、コンテンツ利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との照合を行ないＣＩＤの一致を条件としてコンテンツ再生を実行する。また、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行することにより、コンテンツを再生利用することが可能となる。
【０２０９】
このように、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【０２１０】
なお、図３４のフローにおいてはサービスデータの取得処理については省略してあるが、サービスデータを保有していないクライアントがリコメンドファイルを受領した場合には、ライセンスサーバに対するアクセスを実行して登録処理を行ない、サービスデータを取得することが必要となる。この登録処理手続きは、先に図１３、図１６を参照して説明した処理に対応する処理となる。
【０２１１】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２１２】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２１３】
例えば、プログラムは記憶媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０２１４】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記憶媒体にインストールすることができる。
【０２１５】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。
【０２１６】
【発明の効果】
以上、説明したように、本発明の構成によれば、すでにコンテンツを保有しているクライアントが暗号化コンテンツを含むコンテンツファイルと、説明用ファイルからなるリコメンドファイルを生成し、他のクライアントに提供することで、他のクライアントがコンテンツ配信サーバへのアクセスなしにコンテンツを受領することが可能となる。他のクライアントは、利用権情報を取得することを条件としてコンテンツの利用が可能となる構成であるので、不正なコンテンツの利用は防止される。
【０２１７】
また、本発明の構成によれば、コンテンツ説明用ファイルを、コンテンツファイルからショップサーバＵＲＬを抽出し、抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するリンクデータを保持したファイルとして構成したので、リコメンドファイルを受領したクライアントが容易にショップに接続して購入手続きを実行することが可能となる。
【０２１８】
また、本発明の構成によれば、リコメンドファイル中に格納される暗号化コンテンツは、コンテンツキーＫｃにより暗号化されたコンテンツであり、コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであるので、不正なコンテンツ利用の防止が確実に実行される。
【図面の簡単な説明】
【図１】本発明を適用したコンテンツ提供システムの概要を示す図である。
【図２】クライアント、および各サーバ、管理システムの構成例を示す図である。
【図３】各種キー、データの暗号化処理、配布処理について説明するツリー構成図である。
【図４】各種キー、データの配布に使用される有効化キーブロック（ＥＫＢ）の例を示す図である。
【図５】コンテンツキーの有効化キーブロック（ＥＫＢ）を使用した配布例と復号処理例を示す図である。
【図６】有効化キーブロック（ＥＫＢ）のフォーマット例を示す図である。
【図７】有効化キーブロック（ＥＫＢ）のタグの構成を説明する図である。
【図８】ツリー構成におけるカテゴリ分割を説明する図である。
【図９】ツリー構成におけるカテゴリ分割を説明する図である。
【図１０】ツリー構成におけるカテゴリ分割の具体例を説明する図である。
【図１１】コンテンツ購入、または試聴処理における各エンティテイ間の実行処理シーケンス（その１）を示す図である。
【図１２】管理システムにおいて実行するトランザクションＩＤ生成、発行処理手順を示すフロー図である。
【図１３】コンテンツ購入、または試聴処理における各エンティテイ間の実行処理シーケンス（その２）を示す図である。
【図１４】管理システムにおいて実行するダウンロード許可処理手順を示すフロー図である。
【図１５】起動ファイルのデータ構成例を示す図である。
【図１６】クライアントにおいて実行する起動ファイルに基づくアプリケーション実行手順を示すフロー図である。
【図１７】サービスデータ、利用権情報のデータ構成例を示す図である。
【図１８】コンテンツ購入処理における各エンティテイ間の実行処理シーケンスを示す図である。
【図１９】コンテンツ再生処理の概要を説明する図である。
【図２０】有効化キーブロック（ＥＫＢ）を適用したコンテンツ復号、利用処理例を説明する図である。
【図２１】コンテンツ試聴処理における各エンティテイ間の実行処理シーケンスを示す図である。
【図２２】試聴コンテンツ再生処理の概要を説明する図である。
【図２３】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その１）を示す図である。
【図２４】リストア処理要求ファイル［ｒｅｓｔｏｒｅ．ｄａｔ］の構成例を示す図である。
【図２５】ＭＡＣ生成処理構成を示す図である。
【図２６】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その２）を示す図である。
【図２７】ライセンスまたはコンテンツのバックアップ／リストア処理における各エンティテイ間の処理シーケンス（その３）を示す図である。
【図２８】リコメンドファイルの生成処理フローを示す図である。
【図２９】リコメンドファイル生成画面を示す図である。
【図３０】リコメンドファイル構成例を示す図である。
【図３１】リコメンドファイル中に格納されるコンテンツファイルの構成例を示す図である。
【図３２】リコメンドファイル中に格納されるコンテンツ説明ファイルの表示例を示す図である。
【図３３】リコメンドファイルを受領したクライアントにおけるライセンス情報取得処理フロー（その１）を示す図である。
【図３４】リコメンドファイルを受領したクライアントにおけるライセンス情報取得処理フロー（その２）を示す図である。
【符号の説明】
１０ クライアント
１１ ブラウザ
１２ クライアントアプリケーション
２１ ショップサーバ
２２ ライセンスサーバ
２３ コンテンツサーバ
３１ 管理システム
１００ タイマ
１０１ ＣＰＵ（Ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
１０２ ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ−Ｍｅｍｏｒｙ）
１０３ ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）
１０４ 暗号化復号部
１０５ コーデック部
１０６ 入力部
１０７ 出力部
１０８ 記憶部
１０９ 通信部
１１０ ドライブ
１１１ バス
１１２ 入出力インタフェース
１２１ リムーバブル記録媒体
２０１ バージョン
２０２ デプス
２０３ データポインタ
２０４ タグポインタ
２０５ 署名ポインタ
２０６ データ部
２０７ タグ部
２０８ 署名
３０１ ルートキー
３０２ ノードキー
３０３ リーフキー
３０４ カテゴリノード
３５０ ルートノード
３５１ Ｔシステムノード
３５２ Ｔサービスノード
３５３ Ｔハードノード
３５４ サービスプロバイダノード
３５５ リーフ
３６０ 起動ファイル
３７０ サービスデータ
３７１ 利用権情報
３７２ コンテンツ
３７３ 試聴フラグ
３８１ ライセンスサーバ
３８２ コンテンツサーバ
３８３ クライアント
３８４ コンテンツ
４０１ サービスデータ
４０２ 暗号化コンテンツファイル
４０３ 利用権情報
４１１ ＥＫＢ（Ｈ）
６０１ リストア処理要求ファイル
６５１ コンテンツリスト
６５２，６５３ スイッチ
６５３ リコメンドファイル作成ボタン
６５４ リスト
７２０，７３０ リコメンドファイル
７２１ コンテンツファイル
７２２ コンテンツ説明ファイル
７３１ 試聴、購入コンテンツ配信サイトボタン
Claims (22)
- 暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの複製データを生成する制御手段を有し、
前記制御手段は、
暗号化コンテンツ複製データおよびコンテンツ購入処理可能なショップサーバＵＲＬを格納した二次配信用コンテンツファイルの生成処理を実行する構成を有することを特徴とする情報処理装置。 - 前記制御手段は、
前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成し、
前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルであることを特徴とする請求項１に記載の情報処理装置。 - 前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする請求項２に記載の情報処理装置。
- 前記制御手段は、
記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行する構成であることを特徴とする請求項２に記載の情報処理装置。 - 前記暗号化コンテンツは、
コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする請求項１に記載の情報処理装置。 - 暗号化コンテンツの復号および再生処理を実行するクライアントとしての情報処理装置であり、
暗号化コンテンツの取得処理を実行する制御手段を有し、
前記制御手段は、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理を実行し、格納済みの場合にはコンテンツダウンロード処理を実行せず、未格納の場合にのみコンテンツダウンロード処理を実行する構成を有することを特徴とする情報処理装置。 - 前記制御手段は、
前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行ない、該設定ファイル名のコンテンツを記憶手段に格納するとともに、コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出し、算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行する構成であることを特徴とする請求項６に記載の情報処理装置。 - 前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、
前記制御手段は、
前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行する構成であることを特徴とする請求項６に記載の情報処理装置。 - 前記制御手段は、
前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行する構成であることを特徴とする請求項６に記載の情報処理装置。 - 前記制御手段は、
有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行する構成であることを特徴とする請求項６に記載の情報処理装置。 - 二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成方法であり、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とする二次配信コンテンツ生成方法。 - 前記二次配信コンテンツ生成方法は、さらに、
前記二次配信用コンテンツファイルに併せてコンテンツ説明用ファイルを生成するステップを有し、
前記コンテンツ説明用ファイルは、前記コンテンツファイルからショップサーバＵＲＬを抽出し、該抽出ＵＲＬをブラウザに出力する処理を実行するクライアントアプリケーションプログラムを起動するためのリンクデータを保持したデータファイルとして生成することを特徴とする請求項１１に記載の二次配信コンテンツ生成方法。 - 前記コンテンツ説明用ファイルはＨＴＭＬファイルであることを特徴とする請求項１２に記載の二次配信コンテンツ生成方法。
- 前記二次配信コンテンツ生成方法は、さらに、
記憶部に格納したコンテンツ管理テーブルから前記コンテンツファイルに対応するコンンテツのメタ情報を抽出し、該メタ情報に基づいて前記コンテンツ説明用ファイルの生成処理を実行するステップを含むことを特徴とする請求項１２に記載の二次配信コンテンツ生成方法。 - 前記二次配信コンテンツ生成方法において複製する暗号化コンテンツは、
コンテンツキーＫｃにより暗号化されたコンテンツであり、前記コンテンツキーＫｃは、有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号により取得可能なキーの適用によってのみ取得可能なキーであることを特徴とする請求項１２に記載の二次配信コンテンツ生成方法。 - 暗号化コンテンツの取得処理を実行する情報処理方法であり、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とする情報処理方法。 - 前記情報処理方法は、さらに、
前記コンテンツファイルに格納された暗号化コンテンツの複製データに対して、前記コンテンツファイルに格納されたコンテンツ識別子としてのコンテンツＩＤ（ＣＩＤ）に基づくファイル名設定を行なうファイル名設定ステップと、
前記ファイル名設定ステップで設定したファイル名のコンテンツを記憶手段に格納するステップと、
コンテンツ購入処理において受領するファイル中に含まれるコンテンツ識別子（ＣＩＤ）に基づいてコンテンツファイル名を算出するステップと、
算出ファイル名と格納コンテンツファイル名の照合によりコンテンツ有無判定処理を実行するステップと、
を有することを特徴とする請求項１６に記載の情報処理方法。 - 前記コンテンツファイルに格納された暗号化コンテンツは、ライセンス情報としてのコンテンツ利用権情報に従ったコンテンツ利用が可能なコンテンツであり、
前記情報処理方法は、さらに、
前記コンテンツファイルに格納されたコンテンツＩＤ（ＣＩＤ）に基づいて、暗号化コンテンツに対応するライセンス情報としての利用権情報取得処理を実行するステップを含むことを特徴とする請求項１６に記載の情報処理方法。 - 前記情報処理方法は、さらに、
前記利用権情報に格納されたコンテンツ識別子（ＣＩＤ）と再生対象コンテンツのコンテンツ識別子（ＣＩＤ）との一致を条件としてコンテンツ再生を実行するステップを含むことを特徴とする請求項１６に記載の情報処理方法。 - 前記情報処理方法は、さらに、
有効化キーブロック（ＥＫＢ）配信ツリー構成を適用して提供される有効化キーブロック（ＥＫＢ）の復号によりコンテンツキーＫｃを取得し、取得したコンテンツキーＫｃを適用して暗号化コンテンツの復号処理を実行するステップを含むことを特徴とする請求項１６に記載の情報処理方法。 - 二次配信用コンテンツを含むデータファイルの生成処理を実行する二次配信コンテンツ生成処理実行プログラムを記述したコンピュータ・プログラムであって、
暗号化コンテンツの複製データの生成ステップと、
前記暗号化コンテンツ複製データと、コンテンツ購入処理可能なショップサーバＵＲＬとを格納した二次配信用コンテンツファイルを生成するステップと、
を有することを特徴とするコンピュータ・プログラム。 - 暗号化コンテンツの取得処理を実行する情報処理実行プログラムを記述したコンピュータ・プログラムであって、
コンテンツ購入処理において、購入予定コンテンツが自己の記憶手段に格納されているか否かを判別するコンテンツ有無判定処理ステップと、
前記コンテンツ有無判定処理ステップの判定結果がコンテンツ未格納であることを条件として、コンテンツダウンロード処理を実行するステップと、
を有することを特徴とするコンピュータ・プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002213702A JP2004054745A (ja) | 2002-07-23 | 2002-07-23 | 情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002213702A JP2004054745A (ja) | 2002-07-23 | 2002-07-23 | 情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004054745A true JP2004054745A (ja) | 2004-02-19 |
Family
ID=31936228
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002213702A Pending JP2004054745A (ja) | 2002-07-23 | 2002-07-23 | 情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004054745A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014013977A (ja) * | 2012-07-03 | 2014-01-23 | Sharp Corp | コンテンツ配信システム、コンテンツ配信方法、プログラムおよび記録媒体 |
| JP2014013978A (ja) * | 2012-07-03 | 2014-01-23 | Sharp Corp | コンテンツ配信システム、コンテンツ配信方法、プログラムおよび記録媒体 |
| CN113542226A (zh) * | 2021-06-18 | 2021-10-22 | 深圳数字电视国家工程实验室股份有限公司 | 多媒体数据保护方法、装置及计算机可读存储介质 |
| CN115695051A (zh) * | 2022-12-21 | 2023-02-03 | 广东广宇科技发展有限公司 | 一种基于异地网络平台架构的数据中心传输管理系统 |
-
2002
- 2002-07-23 JP JP2002213702A patent/JP2004054745A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014013977A (ja) * | 2012-07-03 | 2014-01-23 | Sharp Corp | コンテンツ配信システム、コンテンツ配信方法、プログラムおよび記録媒体 |
| JP2014013978A (ja) * | 2012-07-03 | 2014-01-23 | Sharp Corp | コンテンツ配信システム、コンテンツ配信方法、プログラムおよび記録媒体 |
| CN113542226A (zh) * | 2021-06-18 | 2021-10-22 | 深圳数字电视国家工程实验室股份有限公司 | 多媒体数据保护方法、装置及计算机可读存储介质 |
| CN113542226B (zh) * | 2021-06-18 | 2023-09-26 | 深圳数字电视国家工程实验室股份有限公司 | 多媒体数据保护方法、装置及计算机可读存储介质 |
| CN115695051A (zh) * | 2022-12-21 | 2023-02-03 | 广东广宇科技发展有限公司 | 一种基于异地网络平台架构的数据中心传输管理系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3864867B2 (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP2004056620A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| KR101028176B1 (ko) | 정보 기록 매체, 정보 처리 장치, 정보 처리 방법, 및 컴퓨터 프로그램을 기록한 컴퓨터 판독가능 기록 매체 | |
| JP5113299B2 (ja) | Ｄｒｍ提供装置、システムおよびその方法 | |
| JP3788438B2 (ja) | 情報記録媒体、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP4884535B2 (ja) | 装置間でのデータオブジェクトの転送 | |
| JP2004102789A (ja) | ライセンス管理装置、ライセンス管理方法、並びにコンピュータ・プログラム | |
| JP2006285607A (ja) | コンテンツ情報提供システム，コンテンツ情報提供サーバ，コンテンツ再生装置，コンテンツ情報提供方法，コンテンツ再生方法，およびコンピュータプログラム | |
| JP5573489B2 (ja) | 情報処理装置、および情報処理方法、並びにプログラム | |
| JP2003317376A (ja) | 情報管理装置および方法、記録媒体、並びにプログラム | |
| JP2002319932A (ja) | 情報記録装置、情報再生装置、および情報記録方法、情報再生方法、並びにプログラム | |
| JP4449959B2 (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP2003308250A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| JP2004054745A (ja) | 情報処理装置、および二次配信コンテンツ生成方法、情報処理方法、並びにコンピュータ・プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050621 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080722 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080909 |