JP4782165B2 - コンテンツ利用管理システム、これに用いられるサーバ装置、コンテンツ利用管理方法及びライセンス情報送信方法 - Google Patents

Description

本発明は、コンテンツの利用を要求したユーザの端末装置に対して、一定の利用条件下でコンテンツの利用を可能にするライセンス情報を、管理装置から通信ネットワークを介して配信するコンテンツ利用管理システム等に関する。

近年、音楽や映像、ゲームなどのデジタル著作物をインターネットやデジタル放送などで配信するシステムが開発され、その一部は、実用化の段階を迎えている。また、これらのコンテンツの配信に当り、著作権保護の観点から、配信したコンテンツの再生回数、コンテンツの移動、複製などを制限するコンテンツ利用制御の方式が併せて検討されている。従来のデジタルコンテンツ配信システムでは、特許文献１や特許文献２に開示されているように、各ユーザのコンテンツに対する利用条件を、コンテンツと共に受信側に配信して、全てユーザ端末で管理するようにモデル化されている。

例えば、あるユーザが、映画“Ｍａｔｒｉｘ”について３回視聴する権利を購入する場合には、ユーザ端末は、配信サーバから通信経由で、映画“Ｍａｔｒｉｘ”のコンテンツと共に、「Ｍａｔｒｉｘを３回視聴可能」であることを示す利用条件を受信し、コンテンツの再生を利用条件に従って管理する。配信サーバは、ユーザ端末に上記利用条件を配信した以降は、ユーザの利用条件に関与しない。

ユーザ端末が蓄積したコンテンツを再生して“Ｍａｔｒｉｘ”を視聴する場合には、１回視聴する毎にユーザ端末で管理している利用条件の視聴可能回数を１ずつ減じる処理が行われ、視聴可能回数が０になった時点で、視聴を不許可とする処理が行われる。

図５２は、従来のデジタルコンテンツ配信システムの構成を示している。
配信サーバ１１０は、会員登録したユーザのＩＤ情報などを蓄積するユーザ管理データベース１１１と、コンテンツの利用条件を蓄積するコンテンツ情報データベース１１６と、コンテンツを蓄積するコンテンツデータベース１１９と、ユーザ認証を行うユーザ認証部１１２と、コンテンツの利用条件や暗号鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部１１７と、コンテンツ情報を暗号化するコンテンツ情報暗号化部１１８と、コンテンツデータベース１１９から指定されたコンテンツを取得するコンテンツ取得部１２０と、コンテンツを暗号化するコンテンツ暗号化部１２１と、ユーザ端末１３０との通信を行う通信部１２２とを備えている。

一方、ユーザ端末１３０は、配信サーバ１１０との間で通信を行う通信部１３１と、ＩＤ情報を蓄積するＩＤ情報蓄積部１３２と、暗号化されたコンテンツを蓄積する蓄積部１３３と、受信したコンテンツ情報から暗号鍵と利用条件を復号するコンテンツ情報復号部１３７と、コンテンツの利用条件及び暗号鍵を管理する利用条件管理部１３８と、コンテンツ再生時に利用条件を満たすかどうかの判定処理を行う利用条件処理部１３９と、利用条件を満たすときに利用条件処理部１３９から取得した暗号鍵でコンテンツを復号するコンテンツ復号部１３５とを備えている。

図５３は、このデジタルコンテンツ配信システムにおいて、ユーザ端末１３０が配信サーバ１１０からコンテンツを購入するときの処理フローを示している。

ユーザのコンテンツ購入要求があると、配信サーバ１１０及びユーザ端末１３０は以下
の処理を行う。

Ｓ２０１：ユーザ端末１３０の通信部１３１は、ＩＤ情報蓄積部１３２に蓄積されたユーザ端末１３０のＩＤ情報を取得し、このＩＤ情報とコンテンツ購入要求とを配信サーバ１１０に送信する。

Ｓ２０２：この情報を配信サーバ１１０の通信部１２２を通じて受信したユーザ認証部１１２は、受信したＩＤ情報をユーザ管理データベース１１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、コンテンツ購入要求をコンテンツ情報生成部１１７に渡す。

Ｓ２０３：コンテンツ情報生成部１１７は、コンテンツ購入に対する課金処理を行い、コンテンツ情報データベース１１６から購入コンテンツの利用条件やコンテンツ鍵の情報を取得し、コンテンツ鍵を購入コンテンツの情報と共にコンテンツ取得部１２０に渡す。また、コンテンツ情報生成部１１７は、利用条件とコンテンツ鍵の情報とを含むコンテンツ情報を生成してコンテンツ情報暗号化部１１８に渡し、コンテンツ情報暗号化部１１８は、コンテンツ情報を暗号化する。

Ｓ２０４：コンテンツ取得部１２０は、コンテンツデータベース１１９から該当するコンテンツを取得し、コンテンツ暗号化部１２１は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ１１０の通信部１２２は、暗号化されたコンテンツと、暗号化されたコンテンツ情報とをユーザ端末１３０に送信する。

Ｓ２０５：ユーザ端末１３０の通信部１３１は、（１）暗号化されたコンテンツと、（２）コンテンツ鍵及び利用条件の情報を含む暗号化されたコンテンツ情報とを受信し、
Ｓ２０６：コンテンツを蓄積部１３３に送って蓄積する。

Ｓ２０７：また、コンテンツ情報をコンテンツ情報復号部１３７に送る。コンテンツ情報復号部１３７は、暗号化されているコンテンツ情報を復号し、利用条件とコンテンツ鍵とを取り出して利用条件管理部１３８に蓄積する。

図５４は、このデジタルコンテンツ配信システムにおいて、ユーザ端末１３０がコンテンツを再生するときの処理フローを示している。ユーザのコンテンツ再生要求があると、ユーザ端末１３０は以下の処理を行う。

Ｓ３０１：利用条件処理部１３９は、利用条件管理部１３８で管理されている該当するコンテンツの利用条件及びコンテンツ鍵を取得し、
Ｓ３０２：利用条件の再生回数（再生を許容する回数）をチェックする。

Ｓ３０３：再生回数が０より大きいと判断したときは、
Ｓ３０４：利用条件の再生回数をデクリメントして、
Ｓ３０５：利用条件を利用条件管理部１３８に蓄積する。

Ｓ３０６：コンテンツ復号部１３５は、蓄積部１３３から該当するコンテンツを取得し、
Ｓ３０７：利用条件処理部１３９から渡されたコンテンツ鍵を用いてコンテンツを復号し、コンテンツを再生する。

また、Ｓ３０３において、再生回数が０より大きくないときは、再生は行わず処理を終了する。

なお、秘密情報の漏洩を防止するため、秘密情報を扱うＩＤ情報蓄積部１３２、コンテンツ情報復号部１３７及び利用条件管理部１３８は、通常、例えばＩＣカード等、セキュリティモジュールに設置され、このセキュリティモジュールがユーザ端末１３０に装着される。この場合、利用条件管理部１３８から利用条件処理部１３９に利用条件やコンテンツ鍵の情報を送るとき、これらの情報は暗号化されてセキュリティモジュールから出力され、利用条件処理部１３９が更新した利用条件を利用条件管理部１３８に蓄積する際にも、再暗号化されてセキュリティモジュールに送出される。従来のデジタルコンテンツ配信システムでは、こうした方式で、各ユーザのコンテンツに対する利用条件がユーザ端末で管理されている。
特開２０００−４８０７６号公報 特開２０００−２９３４３９号公報

しかしながら、各ユーザの利用条件を全てユーザ端末で管理する場合には、ユーザ端末での複雑な利用条件管理が必須である。このような機能を実装することは、ＰＣのような複雑な処理を容易に行うことが可能なユーザ端末においては大きな負担とはならないが、携帯電話等のポータブル機器や、家電機器などにおいては大きな負担となり得る。

そこで、本発明は、こうした従来の技術の問題点を解決するものであり、配信サーバが、ユーザ端末でのコンテンツの利用を確実且つ最適に制御し、ユーザ端末の負担を軽減することが可能であるコンテンツ利用管理システム及びこれに用いられるサーバ等を提供することを目的としている。

上記課題を解決するために本発明に係るコンテンツ利用管理システムにおいては、サー
バ装置と、前記サーバ装置からライセンス情報を取得し、取得した前記ライセンス情報に従ってコンテンツの利用制御を行う端末装置とから構成されるコンテンツ利用管理システムであって、前記端末装置は、前記サーバ装置に対し前記ライセンス情報の送信を要求し、前記ライセンス情報を取得するライセンス情報取得手段と、前記ライセンス取得手段が取得した前記ライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御するコンテンツ利用制御手段を有し、前記サーバ装置は、コンテンツに対する利用権利を管理する利用権利管理手段と、前記端末装置からの前記ライセンス情報の送信要求に応じて、前記ライセンス情報を生成するライセンス情報生成手段と、前記ライセンス情報生成手段が生成したライセンス情報を、前記ライセンス情報の送信を要求している端末装置に送信するライセンス情報送信手段を有し、前記ライセンス情報取得手段は、前記サーバ装置に対し、前記ライセンス情報の送信を要求する以前、または、前記ライセンス情報の送信を要求する際、前記端末装置の利用環境および利用形態に応じて変化する端末能力情報を送信し、前記ライセンス情報生成手段は、前記利用権利管理手段が管理する利用権利と、前記端末装置から送信される前記端末能力情報とに基づいてライセンス情報を生成し、前記端末能力情報は、前記端末装置と前記サーバ装置との接続頻度を示す情報を含み、前記ライセンス情報生成手段は、前記端末能力情報に含まれる、前記サーバ装置と接続頻度に応じたライセンス情報を生成し、前記コンテンツ利用制御手段は、前記サーバ装置との接続頻度に応じて生成されたライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御することを特徴とする。

なお、本明細書において、コンテンツの「利用」は、コンテンツの「再生」、「移動」、「複製」や、電子書籍等のコンテンツの「印刷」等、コンテンツを使用する全ての操作を含むものとして使用する。

また、本発明に係るコンテンツ利用管理システムにおいては、前記ライセンス情報生成手段は、前記端末能力情報が、前記サーバ装置と常時接続でないことを示す場合、前記コンテンツの利用回数を指定するライセンス情報を生成し、前記コンテンツ利用制御手段は、前記ライセンス情報取得手段が取得したライセンス情報に含まれる利用回数に応じたコンテンツの利用を行うよう制御することを特徴とすることができる。

また、本発明に係るコンテンツ利用管理システムにおいては、前記ライセンス情報生成制御情報は、前記端末装置が処理可能な利用条件を示す情報を含むことを特徴とすることもできる。

また、本発明に係るコンテンツ利用管理システムにおいては、前記ライセンス情報生成制御情報は、前記端末装置のバージョンを示す情報を含むことを特徴とすることもできる。

なお、本発明は、上記コンテンツ利用管理システムを構成するサーバ装置及び端末装置として実現したり、それらサーバ装置及び端末装置を構成する特徴的な手段をステップとするコンテンツ利用管理方法、ライセンス情報送信方法及びコンテンツ利用制御方法として実現したり、それらステップをパーソナルコンピュータ等に実行させるプログラムとして実現したりすることもできる。そして、そのプログラムをＤＶＤ等の記録媒体やインターネット等の伝送媒体を介して広く流通させることができるのは言うまでもない。

以上の説明から明らかなように、本発明に係るコンテンツ利用管理システムにおいては、端末装置と端末装置におけるデジタルコンテンツの利用を管理するサーバ装置とから構成されるコンテンツ利用管理システムであって、前記サーバ装置は、ユーザの利用条件を管理し、前記利用条件の一部又は全部をライセンス情報として生成し、前記端末装置に配信し、前記端末装置は、受信した前記ライセンス情報に基づいて、コンテンツの利用を制御することを特徴とする。

この構成によると、配信サーバ装置からユーザ端末に対し送信するライセンス情報の内容を、ユーザ端末の能力やサービス内容、ユーザの信頼度などに応じ、配信サーバで最適化することが可能となる。

よって、本発明により、ユーザ端末でのコンテンツの利用を確実且つ最適に制御し、ユーザ端末の負担を軽減することが可能となり、コンテンツの配信が普及してきた今日における本願発明の実用的価値は極めて高い。

以下、本発明の実施の形態のデジタルコンテンツ配信システムについて、説明する。

（実施の形態１）
本発明の実施の形態１におけるデジタルコンテンツ配信システムは、図１に示すように、配信サーバ４１０とユーザ端末４３０とからなり、配信サーバ４１０は、会員登録したユーザのＩＤ情報などを蓄積するユーザ管理データベース４１１と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース４１３と、コンテンツの関連情報（コンテンツ鍵など）を蓄積するコンテンツ情報データベース４１６と、コンテンツを蓄積するコンテンツデータベース４１９と、ユーザ認証を行うユーザ認証部４１２と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部４１４と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部４１５と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部４１７と、コンテンツ情報を暗号化するコンテンツ情報暗号化部４１８と、コンテンツデータベース４１９から指定されたコンテンツを取得するコンテンツ取得部４２０と、コンテンツを暗号化するコンテンツ暗号化部４２１と、ユーザ端末４３０との通信を行う通信部４２２とを備えている。

一方、ユーザ端末４３０は、配信サーバ４１０との間で通信を行う通信部４３１と、ＩＤ情報を蓄積するＩＤ情報蓄積部４３２と、ユーザ端末の能力を示す端末能力情報を蓄積する端末能力情報蓄積部４３９と、暗号化されたコンテンツを蓄積する蓄積部４３３と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース４３８と、コンテンツ情報データベース４３８からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部４３７と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部４３６と、ライセンス情報処理部４３６から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部４３５と、半導体メモリカードなどの外部メディア４５０にコンテンツを出力する外部メディアアクセス部４３４とを備えている。

このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ４１０で管理される。ユーザが購入（あるいは事前契約）したコンテンツは、暗号化された状態でユーザ端末４３０の蓄積部４３３に蓄積され、このコンテンツを利用する場合には、ユーザ端末４３０から配信サーバ４１０にリクエストが出される。配信サーバ４１０は、ユーザがリクエストしたコンテンツに対する利用条件（あるいは契約条件、以下「ＵＲ−Ｕｓ」とも記す。）を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報（ライセンス情報（以下、「ＵＲ−Ｕｃ」とも記す。）とコンテンツ鍵とを含む情報（以下、「ＬＴ」とも記す。））を配信する。

ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末４３０は、このライセンス情報に基づいてコンテンツの利用を制御する。

図２は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末４３０が配信サーバ４１０からコンテンツを購入するときの処理フローを示している。

ユーザからのコンテンツ購入要求があると、配信サーバ４１０及びユーザ端末４３０は以下の処理を行う。

Ｓ５０１：ユーザ端末４３０の通信部４３１は、ＩＤ情報蓄積部４３２に蓄積されたユーザ端末４３０のＩＤを取得し、このＩＤ情報とコンテンツの購入要求とを配信サーバ４１０に送信する。

Ｓ５０２：この情報を配信サーバ４１０の通信部４２２を通じて受信したユーザ認証部４１２は、受信したＩＤ情報をユーザ管理データベース４１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部４１４に渡す。

Ｓ５０３：ユーザ権利処理部４１４は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース４１３に、購入コンテンツに対するユーザの権利情報（ＵＲ−Ｕｓ）を登録する。

Ｓ５０４：コンテンツ情報生成部４１７は、コンテンツ情報データベース４１６から該当コンテンツの関連情報（コンテンツ鍵など）を取得してコンテンツ取得部４２０に渡す。

Ｓ５０５：コンテンツ取得部４２０は、コンテンツデータベース４１９から該当コンテンツを取得し、コンテンツ暗号化部４２１は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ４１０の通信部４２２は、暗号化されたコンテンツをユーザ端末４３０に送信する。

Ｓ５０６：ユーザ端末４３０の通信部４３１は、暗号化されたコンテンツを受信すると、
Ｓ５０７：コンテンツを蓄積部４３３に送って蓄積する。

次に、図３を用いて本実施の形態のデジタルコンテンツ配信システムにおけるユーザ端末４３０が、コンテンツを再生するためにコンテンツ情報を取得する場合の処理（コンテンツ情報取得プロセス）について説明する。

ユーザからコンテンツ再生のためのコンテンツ情報の取得要求があると、配信サーバ４１０及びユーザ端末４３０は以下の処理を行う。

Ｓ６０１：ユーザ端末４３０の通信部４３１は、ＩＤ情報蓄積部４３２に蓄積されたユーザ端末４３０のＩＤ情報と、端末能力情報蓄積部４３９に蓄積された端末能力情報とを取得し、これらの情報とコンテンツ情報取得要求（以下、「ＬＴ発行要求」とも記す。）とを配信サーバ４１０に送信する。

なお、本実施の形態において、端末能力情報とは、ユーザ端末４３０が、どのようなライセンス情報を処理可能かということを表すものであり、より具体的には、ライセンス情
報に記述される再生可能回数の値について、どのような値ならば処理可能かを示す情報であるとする。例えば、『再生可能回数が１回と記述されたライセンス情報のみ処理可能』という情報である。

Ｓ６０２：ＩＤ情報を配信サーバ４１０の通信部４２２を通じて受信したユーザ認証部４１２は、受信した情報をユーザ管理データベース４１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求とをユーザ権利処理部４１４に渡す。また、配信サーバ４１０の通信部４２２は、受信した端末能力情報をライセンス情報生成部４１５に渡す。

Ｓ６０３：ユーザ権利処理部４１４は、Ｓ６０２で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース４１３を参照して確認する。

Ｓ６０４：Ｓ６０３で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部４１４は、その再生権利の内容をライセンス情報生成部４１５に伝える。ここで、再生権利の内容は、再生可能回数が何回かを表す情報であり、例えば、『Ｎ回再生可能である』といった情報である。その後、
Ｓ６０５：後述するライセンス情報生成プロセスが実行される。

Ｓ６０６：コンテンツ情報生成部４１７は、コンテンツ情報データベース４１６から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報（ＬＴ）を生成する。コンテンツ情報暗号化部４１８は、このコンテンツ情報を暗号化する。

Ｓ６０７：配信サーバ４１０の通信部４２２は、暗号化されたコンテンツ情報をユーザ端末４３０に送信する。

なお、Ｓ６０４において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ４１０からユーザ端末４３０に送信される（Ｓ６０８）。

一方、ユーザ端末４３０では、
Ｓ６０９：ユーザ端末４３０の通信部４３１は、コンテンツ情報を受信すると、
Ｓ６１０：コンテンツ情報をコンテンツ情報データベース４３８に送って蓄積する。

図４は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ４１０がライセンス情報（ＵＲ−Ｕｃ／ＬＴ）を生成する際（ライセンス情報生成プロセス）の処理フローを示している。

ライセンス情報の生成要求があると、配信サーバ４１０は以下の処理を行う。
Ｓ７０１：ライセンス情報生成部４１５は、Ｓ６０２で受信した端末能力情報とＳ６０４で受信した再生権利の内容をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール（図５にその一例を示す。）に従って、ライセンス情報を生成し、コンテンツ情報生成部４１７に渡す。

図５に示すルールは、再生権利の内容と端末能力情報の内容とから、生成するライセンス情報の内容を決定するものである。

Ｓ７０２：ユーザ権利処理部４１４は、ユーザ権利情報データベース４１３に格納されている権利情報内の再生権利の内容を更新（Ｓ７０１で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント）する。

なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。

ここで、図５のライセンス情報生成ルールについて詳しく説明する。
図５に示す通り、端末能力情報として、『再生可能回数１回と記述されたライセンス情報のみ処理可能』、『再生可能回数１回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』、『再生可能回数Ｎ回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報』の３つが定義されているものとする。

例えば、Ｓ６０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数１回と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数１回と記述されたライセンス情報が生成されることを意味する。また、Ｓ６０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数１回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数∞と記述されたライセンス情報が生成されることを意味する。さらに、Ｓ６０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数Ｎ回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数∞と記述されたライセンス情報が生成されることを意味する。なお、Ｎは２以上の有限な整数値とする。

次に、例えば、Ｓ６０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数１回と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数１回と記述されたライセンス情報が生成されることを意味する。また、Ｓ６０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数１回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数１回と記述されたライセンス情報が生成されることを意味する。さらに、Ｓ６０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ６０２で受信した端末能力情報が、『再生可能回数Ｎ回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数Ｎ回と記述されたライセンス情報が生成されることを意味する。なお、Ｎは２以上の有限な整数値とする。

また、例えば、Ｓ６０４で受信した再生権利の内容が、『１回再生可能』という内容に対しては、図５に示す例では、再生可能回数１回と記述されたライセンス情報が生成されることを表している。

図６は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末４３０がコンテンツを再生するときの処理フローを示している。

ユーザからのコンテンツ要求があると、ユーザ端末４３０は以下の処理を行う。
Ｓ９０１：コンテンツ情報復号部４３７は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース４３８に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、Ｓ９０２、Ｓ９０３の処理は行わず、Ｓ９０４に進む。

Ｓ９０２：Ｓ９０１でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。

Ｓ９０３：コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
Ｓ９０４：コンテンツ情報復号部４３７は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部４３６に渡す。

Ｓ９０５：ライセンス情報処理部４３６は、ライセンス情報に記述された再生条件をチェックし、
Ｓ９０６：再生可能回数が１以上の場合には、
Ｓ９０７：蓄積部４３３からコンテンツを取得して、
Ｓ９０８：コンテンツ鍵でコンテンツを復号して再生を行う。

Ｓ９０９〜Ｓ９１１：コンテンツの再生後、コンテンツ情報データベース４３８に蓄積されているコンテンツ情報の更新を行う。

ここで、再生前の再生可能回数が２以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を１デクリメントする。また、再生前の再生可能回数が１であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。

再生前の再生可能回数が無限大であった場合には、更新は行われない。
また、Ｓ９０３で配信サーバ４１０からコンテンツ情報を取得できなかった場合、及び、Ｓ９０６で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。

なお、本実施の形態では、コンテンツの『利用』の一形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば外部メディア４５０への複製や、印刷など、その他いかなる動作であってもよいものとする。

また、本実施の形態において、端末能力情報は、ライセンス情報に記述される再生可能回数の値について、どのような値ならば処理可能かを示す情報であるとして説明を行ったが、それに限るものではなく、例えば、再生有効期限などの時間的な管理が行えるかどうか、配信サーバへの接続頻度はどれくらいか、配信サーバへの接続コストはどれくらいかといった情報であってもよいものとする。

また、ライセンス情報生成ルールも、端末能力情報の内容に応じて変化するものとし、例えば、端末能力情報が配信サーバへの接続頻度を示す情報である場合には、図７に示すようなルール（例）となり、また、端末能力情報が配信サーバへの接続コストを示す情報である場合には、図８に示すようなルール（例）となる。

ここで、図７に示す接続頻度に関するライセンス情報生成ルールについて説明する。
図７に示す通り、接続頻度として、『常時接続』、『１回／Ｄａｙ』、『１回／Ｗｅｅｋ』の３つが定義されているものとする。図７において、再生権利の内容が『∞再生可能』であり、接続頻度が『常時接続』であるときには、『再生可能回数１回』と記述されたライセンス情報を生成する。即ち、再生の度にライセンス情報を発行することを意味する。また、再生権利の内容が『∞再生可能』であり、接続頻度が『１回／Ｄａｙ』、つまり１日に１回程度接続するときには、『再生可能回数Ｎ回』と記述されたライセンス情報を発行することを意味する。なお、Ｎは２以上の有限な整数とする。さらに、再生権利の内容が『∞再生可能』であり、接続頻度が『１回／Ｗｅｅｋ』、つまり１週間に１回程度接続するときには、『再生可能回数∞』と記述されたライセンス情報を発行することを意味する。

また、図７において、再生権利の内容が『複数回再生可能』であり、接続頻度が『常時接続』であるときには、『再生可能回数１回』と記述されたライセンス情報を生成する。即ち、再生の度にライセンス情報を発行することを意味する。また、再生権利の内容が『複数回再生可能』であり、接続頻度が『１回／Ｄａｙ』、つまり１日に１回程度接続するときには、『再生可能回数１回』と記述されたライセンス情報を発行することを意味する。さらに、再生権利の内容が『複数回再生可能』であり、接続頻度が『１回／Ｗｅｅｋ』、つまり１週間に１回程度接続するときには、『再生可能回数Ｎ回』と記述されたライセンス情報を発行することを意味する。なお、Ｎは２以上の有限な整数とする。

さらに、図７において、再生権利の内容が『複数回再生可能』であるときには、いずれの接続頻度に対しても、『再生可能回数１回』と記述されたライセンス情報を発行することを意味する。このようにして、ユーザ端末４３０の接続頻度に応じて、ライセンス情報を柔軟に変更し、発行することが可能となる。

ここで、図８に示す接続コストに関するライセンス情報生成ルールについて説明する。
図８において、再生権利の内容が『∞再生可能』であり、接続コストが『〜ｘｘｘ円』、即ちｘｘｘ円以下の場合、『再生可能回数１回』と記述されたライセンス情報を生成することを意味する。一方、再生権利の内容が『∞再生可能』であり、接続コストが『ｘｘｘ円〜』即ちｘｘｘ円より大きい場合、『再生可能回数∞』と記述されたライセンス情報を生成することを意味する。なお、ｘｘｘは０以上の整数とする。

また、図８において、再生権利の内容が『複数回再生可能』であり、接続コストが『〜ｘｘｘ円』、即ちｘｘｘ円以下の場合、『再生可能回数１回』と記述されたライセンス情報を生成することを意味する。一方、再生権利の内容が『複数回再生可能』であり、接続コストが『ｘｘｘ円〜』即ちｘｘｘ円より大きい場合、『再生可能回数Ｎ回』と記述されたライセンス情報を生成することを意味する。なお、ｘｘｘは０以上の整数とし、Ｎは２以上の有限な整数とする。

さらに、図８において、再生権利の内容が『１回再生可能』である場合は、接続コストによらず、『再生可能回数１回』と記述されたライセンス情報を生成することを意味する。

このようにして、ユーザ端末４３０の接続コストに応じて、ライセンス情報を柔軟に変更し、発行することが可能となる。

以上のように、本実施の形態１のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、ユーザ端末の能力に応じた最適なライセンス情報を配信することが可能となる。

例えば、Ｎ回再生可能と記述された利用条件からライセンス情報を生成し配信する場合、携帯電話のように、配信サーバに頻繁に接続することが可能で、且つ、端末内での処理を軽くしたいといった機器には、１回再生可と記述したライセンス情報を配信し、逆に、ＰＣのように、配信サーバに頻繁に接続することは難しいが、端末内で複雑な処理が可能といった機器には、Ｎ回分の再生権利を記述したライセンス情報を配信するといったことが可能となる。

（実施の形態２）
本発明の実施の形態２におけるデジタルコンテンツ配信システムは、図９に示すように、配信サーバ１２１０とユーザ端末１２３０とからなり、配信サーバ１２１０は、会員登録したユーザのＩＤ情報などを蓄積するユーザ管理データベース１２１１と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース１２１３と、コンテンツの関連情報（コンテンツ鍵、コンテンツが属するサービス内容など）を蓄積するコンテンツ情報データベース１２１６と、コンテンツを蓄積するコンテンツデータベース１２１９と、ユーザ認証を行うユーザ認証部１２１２と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部１２１４と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部１２１５と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部１２１７と、コンテンツ情報を暗号化するコンテンツ情報暗号化部１２１８と、コンテンツデータベース１２１９から指定されたコンテンツを取得するコンテンツ取得部１２２０と、コンテンツを暗号化するコンテンツ暗号化部１２２１と、ユーザ端末１２３０との通信を行う通信部１２２２とを備えている。

一方、ユーザ端末１２３０は、配信サーバ１２１０との間で通信を行う通信部１２３１と、ＩＤ情報を蓄積するＩＤ情報蓄積部１２３２と、暗号化されたコンテンツを蓄積する蓄積部１２３３と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース１２３８と、コンテンツ情報データベース１２３８からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部１２３７と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部１２３６と、ライセンス情報処理部１２３６から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部１２３５と、外部メディア１２５０にコンテンツを出力する外部メディアアクセス部１２３４とを備えている。

このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ１２１０で管理される。ユーザが購入（あるいは事前契約）したコンテンツは、暗号化された状態でユーザ端末１２３０の蓄積部１２３３に蓄積され、このコンテンツを利用する場合には、ユーザ端末１２３０から配信サーバ１２１０にリクエストが出される。配信サーバ１２１０は、ユーザがリクエストしたコンテンツに対する利用条件（あるいは契約条件）を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報（ライセンス情報とコンテンツ鍵とを含む情報）を配信する。ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末１２３０は、このライセンス情報に基づいてコンテンツの利用を制御する。

図１０は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末１２３０が配信サーバ１２１０からコンテンツを購入するときの処理フローを示している。ユーザからのコンテンツ要求があると、配信サーバ１２１０及びユーザ端末１２３０は以下の処理を行う。

Ｓ１３０１：ユーザ端末１２３０の通信部１２３１は、ＩＤ情報蓄積部１２３２に蓄積されたユーザ端末１２３０のＩＤを取得し、このＩＤ情報とコンテンツの購入要求とを配信サーバ１２１０に送信する。

Ｓ１３０２：この情報を配信サーバ１２１０の通信部１２２２を通じて受信したユーザ認証部１２１２は、受信したＩＤ情報をユーザ管理データベース１２１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部１２１４に渡す。

Ｓ１３０３：ユーザ権利処理部１２１４は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース１２１３に、購入コンテンツに対するユーザの権利情報を登録する。

Ｓ１３０４：コンテンツ情報生成部１２１７は、コンテンツ情報データベース１２１６から該当コンテンツの関連情報（コンテンツ鍵など）を取得してコンテンツ取得部１２２０に渡す。

Ｓ１３０５：コンテンツ取得部１２２０は、コンテンツデータベース１２１９から該当コンテンツを取得し、コンテンツ暗号化部１２２１は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ１２１０の通信部１２２２は、暗号化されたコンテンツをユーザ端末１２３０に送信する。

Ｓ１３０６：ユーザ端末１２３０の通信部１２３１は、暗号化されたコンテンツを受信すると、
Ｓ１３０７：コンテンツを蓄積部１２３３に送って蓄積する。

次に、図１１を用いて本実施の形態のデジタルコンテンツ配信システムにおいて、ユーザ端末１２３０が、コンテンツを再生するためにコンテンツ情報を取得する場合の処理（コンテンツ情報取得プロセス）について説明する。

ユーザからコンテンツ再生のためのコンテンツ情報の取得要求があると、
Ｓ１４０１：ユーザ端末１２３０の通信部１２３１は、ＩＤ情報蓄積部１２３２に蓄積されたユーザ端末１２３０のＩＤ情報を取得し、これらの情報とコンテンツ情報取得要求とを配信サーバ１２１０に送信する。

Ｓ１４０２：ＩＤ情報を配信サーバ１２１０の通信部１２２２を通じて受信したユーザ認証部１２１２は、受信した情報をユーザ管理データベース１２１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求とをユーザ権利処理部１２１４に渡す。

Ｓ１４０３：ユーザ権利処理部１２１４は、Ｓ１４０２で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース１２１３を参照して確認する。

Ｓ１４０４：Ｓ１４０３で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部１２１４は、その再生権利の内容をライセンス情報生成部１２１５に伝える。ここで、再生権利の内容は、再生可能回数が何回かを表す情報であり、例えば、『Ｎ回再生可能である』といった情報である。その後、
Ｓ１４０５：後述するライセンス情報生成プロセスが実行される。

Ｓ１４０６：コンテンツ情報生成部１２１７は、コンテンツ情報データベース１２１６から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報を生成する。コンテンツ情報暗号化部１２１８は、このコンテンツ情報を暗号化する。

Ｓ１４０７：配信サーバ１２１０の通信部１２２２は、暗号化されたコンテンツ情報をユーザ端末１２３０に送信する。

なお、Ｓ１４０４において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ１２１０からユーザ端末１２３０に送信される（Ｓ１４０８）。

一方、ユーザ端末１２３０では、
Ｓ１４０９：ユーザ端末１２３０の通信部１２３１は、コンテンツ情報（ＬＴ）を受信すると、
Ｓ１４１０：コンテンツ情報（ＬＴ）をコンテンツ情報データベース１２３８に送って蓄積する。

図１２は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ１２１０がライセンス情報を生成する際（ライセンス情報生成プロセス）の処理フローを示している。ライセンス情報の生成要求があると、
Ｓ１５０１：ライセンス情報生成部１２１５は、コンテンツ情報取得要求のあったコンテンツが属するサービス内容に関する情報を、コンテンツ情報データベース１２１６から入手する。

本実施の形態では、サービス内容とは、例えば、音楽配信、映画配信などといったコンテンツの種類に関する情報であるとする。

Ｓ１５０２：ライセンス情報生成部１２１５は、Ｓ１４０４で受信した再生権利の内容とＳ１５０１で入手したサービス内容に関する情報をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール（図１３にその一例を示す。）に従って、ライセンス情報を生成し、コンテンツ情報生成部１２１７に渡す。

Ｓ１５０３：ユーザ権利処理部１２１４は、ユーザ権利情報データベース１２１３に格納されている権利情報内の再生権利の内容を更新（Ｓ１５０２で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント）する。

なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。

ここで、図１３に示すライセンス情報生成ルールについて説明する。
図１３に示すルールは、再生権利の内容とサービスの内容に関する情報とから、生成するライセンス情報の内容を決定するものである。サービスの内容としては、『映画配信サービス』、『音楽配信サービス』の２つが定義されているものとする。

図１３のライセンス情報生成ルールに従った場合、例えば、Ｓ１４０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ１５０１で入手したサービスの内容に関する情報が、『映画配信サービス』という情報である場合、『再生可能回数１回』と記述されたライセンス情報が生成されることになる。

一方、Ｓ１４０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ１５０１で入手したサービスの内容に関する情報が、『音楽配信サービス』という情報である場合、『再生可能回数∞』と記述されたライセンス情報が生成されることになる。

また、Ｓ１４０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ１５０１で入手したサービスの内容に関する情報が、『映画配信サービス』という情報である場合、『再生可能回数１回』と記述されたライセンス情報が生成されることになる。

一方、Ｓ１４０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ１５０１で入手したサービスの内容に関する情報が、『音楽配信サービス』という情報である場合、『再生可能回数Ｎ回』と記述されたライセンス情報が生成されることになる。なお、Ｎは２以上の有限な整数とする。

さらに、Ｓ１４０４で受信した再生権利の内容が、『１回再生可能』という内容の場合は、サービスの内容に関する情報がいずれの場合でも『再生可能回数１回』と記述されたライセンス情報が生成されることになる。

このように、サービス内容、即ちコンテンツの種類毎に柔軟にライセンス情報を生成することが可能となる。

図１４は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末１２３０がコンテンツを再生するときの処理フローを示している。

ユーザからのコンテンツ要求があると、
Ｓ１７０１：コンテンツ情報復号部１２３７は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース１２３８に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、Ｓ１７０２、Ｓ１７０３の処理は行わず、Ｓ１７０４に進む。

Ｓ１７０２：Ｓ１７０１でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。

Ｓ１７０３：コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
Ｓ１７０４：コンテンツ情報復号部１２３７は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部１２３６に渡す。

Ｓ１７０５：ライセンス情報処理部１２３６は、ライセンス情報に記述された再生条件をチェックし、
Ｓ１７０６：再生可能回数が１以上の場合には、
Ｓ１７０７：蓄積部１２３３からコンテンツを取得して、
Ｓ１７０８：コンテンツ鍵でコンテンツを復号して再生を行う。

Ｓ１７０９〜Ｓ１７１１：コンテンツの再生後、コンテンツ情報データベース１２３８に蓄積されているコンテンツ情報の更新を行う。

ここで、再生前の再生可能回数が２以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を１デクリメントする。また、再生前の再生可能回数が１であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。再生前の再生可能回数が無限大であった場合には、更新は行われない。

また、Ｓ１７０３で配信サーバ１２１０からコンテンツ情報を取得できなかった場合、及び、Ｓ１７０６で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。

なお、本実施の形態では、コンテンツの『利用』の１形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば、外部メディア１２５０への複製や、印刷など、その他いかなる動作であってもよいものとする。

また、本実施の形態において、サービスの内容として、コンテンツの種類を例にして説明を行ったが、それに限るものではなく、例えば、新作や旧作などといったコンテンツのプレミア度などの情報であってもよいものとする。

また、ライセンス情報生成ルールも、上記サービスの内容が表す情報に応じて変化するものとし、例えば、サービスの内容がコンテンツのプレミア度を示す情報である場合には、図１５に示すようなルール（例）となる。

図１５において、コンテンツのプレミア度として、『新作』、『準新作』、『旧作』の３つが定義されている。再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『新作』である場合は、『再生可能回数１回』と記述されたライセンス情報を生成することを意味する。また、再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『準新作』である場合は、『再生可能回数Ｎ回』と記述されたライセンス情報を生成することを意味する。さらに、再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『旧作』である場合は、『再生可能回数∞』と記述されたライセンス情報を生成することを意味する。なお、ここでＮは２以上で有限の整数とする。

また、図１５において、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『新作』である場合は、『再生可能回数１回』と記述されたライセンス情報を生成することを意味する。

また、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『準新作』である場合は、『再生可能回数Ｎ回』と記述されたライセンス情報を生成することを意味する。

さらに、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『旧作』である場合は、『再生可能回数Ｎ回』と記述されたライセンス情報を生成することを意味する。

さらに、図１５において、再生権利が『１回再生可能』であるときは、コンテンツのプレミア度にかかわらず、『再生可能回数１回』と記述されたライセンス情報を生成することを意味している。

このように、本実施の形態２のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、サービス内容に応じた最適なライセンス情報を配信することが可能となる。例えば、Ｎ回再生可能と記述された利用条件からライセンス情報を生成し配信する場合、新作映画のように、コンテンツ価値の高いものに関しては、再生時には毎回、ユーザ端末が配信サーバと通信を行うように、１回再生可と記述したライセンス情報を配信し、逆に、旧作映画のように、コンテンツ価値が低いコンテンツに関しては、Ｎ回分（Ｎは２以上の有限な整数）の再生権利を記述したライセンス情報を配信するといったことが可能となる。

（実施の形態３）
本発明の実施の形態３におけるデジタルコンテンツ配信システムは、図１６に示すように、配信サーバ１９１０とユーザ端末１９３０とからなり、配信サーバ１９１０は、会員登録したユーザのＩＤ情報や、ユーザがコンテンツ対価を支払う場合の支払い方法に関する情報などを蓄積するユーザ管理データベース１９１１と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース１９１３と、コンテンツの関連情報（コンテンツ鍵など）を蓄積するコンテンツ情報データベース１９１６と、コンテンツを蓄積するコンテンツデータベース１９１９と、ユーザ認証を行うユーザ認証部１９１２と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部１９１４と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部１９１５と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部１９１７と、コンテンツ情報を暗号化するコンテンツ情報暗号化部１９１８と、コンテンツデータベース１９１９から指定されたコンテンツを取得するコンテンツ取得部１９２０と、コンテンツを暗号化するコンテンツ暗号化部１９２１と、ユーザ端末１９３０との通信を行う通信部１９２２とを備えている。

一方、ユーザ端末１９３０は、配信サーバ１９１０との間で通信を行う通信部１９３１と、ＩＤ情報を蓄積するＩＤ情報蓄積部１９３２と、暗号化されたコンテンツを蓄積する蓄積部１９３３と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース１９３８と、コンテンツ情報データベース１９３８からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部１９３７と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部１９３６と、ライセンス情報処理部１９３６から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部１９３５と、外部メディア１９５０にコンテンツを出力する外部メディアアクセス部１９３４とを備えている。

このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ１９１０で管理される。ユーザが購入（あるいは事前契約）したコンテンツは、暗号化された状態でユーザ端末１９３０の蓄積部１９３３に蓄積され、このコンテンツを利用する場合には、ユーザ端末１９３０から配信サーバ１９１０にリクエストが出される。

配信サーバ１９１０は、ユーザがリクエストしたコンテンツに対する利用条件（あるいは契約条件）を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報（ライセンス情報とコンテンツ鍵とを含む情報）（ＬＴ）を配信する。

ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末１９３０は、このライセンス情報に基づいてコンテンツの利用を制御する。

図１７は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末１９３０が配信サーバ１９１０からコンテンツを購入するときの処理フローを示している。

ユーザからのコンテンツ要求があると、
Ｓ２００１：ユーザ端末１９３０の通信部１９３１は、ＩＤ情報蓄積部１９３２に蓄積されたユーザ端末１９３０のＩＤを取得し、このＩＤ情報とコンテンツの購入要求とを配信サーバ１９１０に送信する。

Ｓ２００２：この情報を配信サーバ１９１０の通信部１９２２を通じて受信したユーザ認証部１９１２は、受信したＩＤ情報をユーザ管理データベース１９１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部１９１４に渡す。

Ｓ２００３：ユーザ権利処理部１９１４は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース１９１３に、購入コンテンツに対するユーザの権利情報を登録する。

Ｓ２００４：コンテンツ情報生成部１９１７は、コンテンツ情報データベース１９１６から該当コンテンツの関連情報（コンテンツ鍵など）を取得してコンテンツ取得部１９２０に渡す。

Ｓ２００５：コンテンツ取得部１９２０は、コンテンツデータベース１９１９から該当コンテンツを取得し、コンテンツ暗号化部１９２１は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ１９１０の通信部１９２２は、暗号化されたコンテンツをユーザ端末１９３０に送信する。

Ｓ２００６：ユーザ端末１９３０の通信部１９３１は、暗号化されたコンテンツを受信すると、
Ｓ２００７：コンテンツを蓄積部１９３３に送って蓄積する。

次に、図１８を用いて本実施の形態のデジタルコンテンツ配信システムにおいて、ユーザ端末１９３０が、コンテンツを再生するためにコンテンツ情報（ＬＴ）を取得する場合の処理（コンテンツ情報取得プロセス）について説明する。

ユーザからコンテンツ再生のためのコンテンツ情報の取得要求（ＬＴ発行要求／ＥＬＩ）があると、
Ｓ２１０１：ユーザ端末１９３０の通信部１９３１は、ＩＤ情報蓄積部１９３２に蓄積されたユーザ端末１９３０のＩＤ情報を取得し、これらの情報とコンテンツ情報取得要求（ＬＴ発行要求／ＥＬＩ）とを配信サーバ１９１０に送信する。

Ｓ２１０２：ＩＤ情報を配信サーバ１９１０の通信部１９２２を通じて受信したユーザ認証部１９１２は、受信した情報をユーザ管理データベース１９１１に蓄積されているＩＤ情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求（ＬＴ発行要求／ＥＬＩ）とをユーザ権利処理部１９１４に渡す。

Ｓ２１０３：ユーザ権利処理部１９１４は、Ｓ２１０２で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース１９１３を参照して確認する。

Ｓ２１０４：Ｓ２１０３で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部１９１４は、その再生権利の内容をライセンス情報生成部１９１５に伝える。

ここで、再生権利の内容は、例えば、『Ｎ回再生可能である』といった情報である。その後、
Ｓ２１０５：後述するライセンス情報生成プロセスが実行される。

Ｓ２１０６：コンテンツ情報生成部１９１７は、コンテンツ情報データベース１９１６から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報を生成する。コンテンツ情報暗号化部１９１８は、このコンテンツ情報を暗号化する。

Ｓ２１０７：配信サーバ１９１０の通信部１９２２は、暗号化されたコンテンツ情報をユーザ端末１９３０に送信する。

なお、Ｓ２１０４において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ１９１０からユーザ端末１９３０に送信される（Ｓ２１０８）。

一方、ユーザ端末１９３０では、
Ｓ２１０９：ユーザ端末１９３０の通信部１９３１は、コンテンツ情報（ＬＴ）を受信すると、
Ｓ２１１０：コンテンツ情報（ＬＴ）をコンテンツ情報データベース１９３８に送って蓄積する。

図１９は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ１９１０がライセンス情報を生成する際（ライセンス情報生成プロセス）の処理フローを示している。ライセンス情報の生成要求があると、
Ｓ２２０１：ライセンス情報生成部１９１５は、コンテンツ情報をリクエストしているユーザの信頼度に関する情報を、ユーザ管理データベース１９１１から入手する。

本実施の形態では、信頼度に関する情報とは、例えば、クレジットカード、請求書現金払いなどといったコンテンツ対価に対する支払い方法に関する情報であるとする。

Ｓ２２０２：ライセンス情報生成部１９１５は、Ｓ２１０４で受信した再生権利の内容とＳ２２０１で入手したユーザの信頼度に関する情報をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール（図２０にその一例を示す。）に従って、ライセンス情報を生成し、コンテンツ情報生成部１９１７に渡す。

Ｓ２２０３：ユーザ権利処理部１９１４は、ユーザ権利情報データベース１９１３に格納されている権利情報内の再生権利の内容を更新（Ｓ２２０２で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント）する。

なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。

ここで、図２０に示すライセンス情報生成ルールについて詳しく説明する。
図２０に示すルールは、再生権利の内容とユーザの信頼度に関する情報とから、生成するライセンス情報の内容を決定するものであり、ユーザの信頼度として、『支払い方法：請求書現金払い』と、『支払い方法：クレジットカード』の２つを定義している。

図２０のライセンス情報生成ルールに従った場合、例えば、Ｓ２１０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ２２０１で入手したユーザの信頼度に関する情報が、『支払い方法：請求書現金払い』という情報である場合、『再生可能回数１回』と記述されたライセンス情報が生成されることになる。また、Ｓ２１０４で受信した再生権利の内容が、『∞回再生可能』という内容で、Ｓ２２０１で入手したユーザの信頼度に関する情報が、『支払い方法：クレジットカード』という情報である場合、『再生可能回数∞』と記述されたライセンス情報が生成されることになる。

また、図２０のライセンス情報生成ルールに従った場合、例えば、Ｓ２１０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ２２０１で入手したユーザの信頼度に関する情報が、『支払い方法：請求書現金払い』という情報である場合、『再生可能回数１回』と記述されたライセンス情報が生成されることになる。また、Ｓ２１０４で受信した再生権利の内容が、『複数回再生可能』という内容で、Ｓ２２０１で入手したユーザの信頼度に関する情報が、『支払い方法：クレジットカード』という情報である場合、『再生可能回数Ｎ回』と記述されたライセンス情報が生成されることになる。ここで、Ｎは２以上の有限な整数とする。

また、図２０のライセンス情報生成ルールに従った場合、例えば、Ｓ２１０４で受信した再生権利の内容が、『１回再生可能』という内容に対しては、いずれのユーザ信頼度に対しても『再生可能回数１回』と記述されたライセンス情報が生成されることになる。このようにして、ライセンス情報生成ルールは、ユーザの信頼度に応じて柔軟に設定することも可能となる。

図２１は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末１９３０がコンテンツを再生するときの処理フローを示している。

ユーザからのコンテンツ要求があると、
Ｓ２４０１：コンテンツ情報復号部１９３７は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース１９３８に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、Ｓ２４０２、Ｓ２４０３の処理は行わず、Ｓ２４０４に進む。

Ｓ２４０２：Ｓ２４０１でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。

Ｓ２４０３：コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
Ｓ２４０４：コンテンツ情報復号部１９３７は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部１９３６に渡す。

Ｓ２４０５：ライセンス情報処理部１９３６は、ライセンス情報に記述された再生条件をチェックし、
Ｓ２４０６：再生可能回数が１以上の場合には、
Ｓ２４０７：蓄積部１９３３からコンテンツを取得して、
Ｓ２４０８：コンテンツ鍵でコンテンツを復号して再生を行う。

Ｓ２４０９〜Ｓ２４１１：コンテンツの再生後、コンテンツ情報データベース１９３８に蓄積されているコンテンツ情報の更新を行う。ここで、再生前の再生可能回数が２以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を１デクリメントする。また、再生前の再生可能回数が１であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。再生前の再生可能回数が無限大であった場合には、更新は行われない。

また、Ｓ２４０３で配信サーバ１９１０からコンテンツ情報を取得できなかった場合、及び、Ｓ２４０６で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。

なお、本実施の形態では、コンテンツの『利用』の１形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば、外部メディアへの複製や、印刷など、その他いかなる動作であってもよいものとする。

また、本実施の形態において、ユーザの信頼度に関する情報として、支払い方法を例にして説明を行ったが、それに限るものではなく、例えば、プラチナ会員、一般会員などといったユーザのステータスに関する情報などであってもよいものとする。ここで、ユーザのステータスとは、過去に購入したコンテンツの総計、支払い実績などによって決定されるものであるとする。

また、ライセンス情報生成ルールも、ユーザの信頼度に関する情報に応じて変化するものとし、例えば、ユーザの信頼度に関する情報がユーザのステータスを表す情報である場合には、図２２に示すようなルール（例）となる。

図２２に示す例では、ユーザのステータスをプラチナ、シルバー、一般の３つに分類しており、プラチナが最もステータスが高く、次いでシルバー、一般の順でステータスを定義している。

再生権利が『∞回再生可能』であるとき、『プラチナ会員』に対しては、『再生可能回数∞』と記述されたライセンス情報が発行されることを意味している。また、再生権利が『∞回再生可能』であるとき、『シルバー会員』に対しては、『再生可能回数Ｎ回』と記述されたライセンス情報が発行されることを意味している。さらに、再生権利が『∞回再生可能』であるとき、『一般会員』に対しては、『再生可能回数１回』と記述されたライセンス情報が発行されることを意味している。ここで、Ｎは２以上の有限な整数とする。

また、再生権利が『複数回再生可能』であるとき、『プラチナ会員』に対しては、『再生可能回数Ｎ回』と記述されたライセンス情報が発行されることを意味している。また、再生権利が『複数回再生可能』であるとき、『シルバー会員』に対しては、『再生可能回数１回』と記述されたライセンス情報が発行されることを意味している。さらに、再生権利が『複数回再生可能』であるとき、『一般会員』に対しては、『再生可能回数１回』と記述されたライセンス情報が発行されることを意味している。ここで、Ｎは２以上の有限な整数とする。

さらに、再生権利が『１回再生可能』であるときは、いずれのステータスのユーザに対しても、『再生可能回数１回』と記述されたライセンス情報が発行されることを意味している。このように、ユーザのステータスに応じて、ライセンス情報を柔軟に設定し、発行することが可能となる。

以上のように、本実施の形態３のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、ユーザの信頼度に応じた最適なライセンス情報を配信することが可能となる。例えば、Ｎ回再生可能と記述された利用条件からライセンス情報を生成し配信する場合、信頼度の高いユーザには、Ｎ回分の再生権利を記述したライセンス情報を配信し、信頼度の低いユーザには、１回再生可と記述したライセンス情報を配信するといったことが可能となる。

（実施の形態４）
以下、本発明の実施の形態４について、図面を用いて詳細に説明する。

図２３は、本実施の形態４に係るコンテンツ利用管理システム（ＮｅｔＤＲＭシステムとも記す。）１の全体の構成を示す図である。

このＮｅｔＤＲＭシステム１は、音楽や、映画、書籍など、デジタル化されたコンテンツを配信したり、コンテンツを購入したユーザに対して付与されるコンテンツ毎の利用権利（ライセンス）を事業者側が主体となって動的に管理し、コンテンツを利用するためのライセンスチケット（以下、「ＬＴ」とも記す。）をユーザの要求（ＬＴ発行要求）に基づいて配信し、ＬＴに含まれる利用条件（ＵＲ−Ｕｃ）の範囲内でコンテンツを利用できるようにすることで、コンテンツの著作権を保護するシステムであり、コンテンツ利用を管理したりする事業者が所有するコンテンツ配信サーバ２及び利用条件管理サーバ３と、このＮｅｔＤＲＭシステム１に加入したユーザが所有するユーザ端末４ａ、…、４ｎと、これらを接続する通信ネットワーク５とから構成される。なお、ユーザ端末４ａ、…、４ｎなどの不特定なＮｅｔＤＲＭ端末の１台を指す場合には、ユーザ端末４と記す。

コンテンツ配信サーバ２は、ワークステーション等のコンピュータであり、コンテンツ配信サーバとして機能する。具体的には、コンテンツ配信の要求を受け付けるＷｅｂページを持ち、ユーザ端末４からのコンテンツ配信要求に応じて、暗号化されたコンテンツをユーザ端末４に配信したりする。

利用条件管理サーバ３は、ワークステーション等のコンピュータであり、ユーザ管理サーバ、課金サーバ、ライセンス管理サーバとして機能する。具体的には、利用条件管理サーバ３は、本システム１に加入したユーザや、そのユーザが所有する端末を管理したり、ユーザ端末４などからコンテンツの利用権購入を受け付けたり、ユーザ端末４ａ等からのライセンスチケット発行要求（以下、「ＬＴ発行要求」とも記す。）を受け付けるＷｅｂページを持ち、ユーザ端末４からのコンテンツの利用権購入要求に応じて課金したり、ＬＴ発行要求に応じて暗号化されたコンテンツをユーザ端末４で利用するためのＬＴを配信したりする。

このＬＴは、暗号化されたコンテンツを復号化するためのコンテンツ鍵と、コンテンツについてユーザに付与された利用権利（ライセンス）の中からその一部を切り出した切り出し利用条件（ＵＲ−Ｕｃ）とを含む。

ユーザ端末４は、パーソナルコンピュータ、携帯情報端末、デジタルテレビ等のコンピュータ装置であり、利用条件管理サーバ３に対するクライアントとして機能する。具体的には、ユーザ端末４は、ユーザの操作に応じて、インターネットブラウザソフト等のツールを用いて利用条件管理サーバ３のＷｅｂページにアクセスし、コンテンツ購入要求を送信してコンテンツの配信を受けたり、コンテンツの利用に当たってＬＴ発行要求を送信してＬＴを受け取り、ＬＴの切り出し利用条件の範囲でコンテンツを再生したりする。

なお、ユーザ端末４には、他のユーザ端末用の外部メディア４４（例えば、ＳＤカード等）を装着することができ、ユーザ端末４が保持するコンテンツやＬＴを外部メディア４４に複写したり、移動したりし、他のユーザ端末でコンテンツを再生することができるように構成されている。

通信ネットワーク５は、インターネット、ＣＡＴＶ等の有線や、デジタル放送等の無線による通信媒体である。

図２４は、図２３に示されるコンテンツ配信サーバ２及び利用条件管理サーバ３の構成を示す機能ブロック図である。なお、本図には通信ネットワーク５も併せて示されている。

コンテンツ配信サーバ２は、コンテンツデータベース２１と、通信部２２とを備える。コンテンツデータベース２１は、暗号化されたコンテンツと、このコンテンツに対して付与されるユニークな識別子であるコンテンツＩＤなどとを関連付けて保持する。なお、通信部２２は、ユーザ端末４からのコンテンツ配信要求を受け付けて、要求されたコンテンツを配信する。

利用条件管理サーバ３は、大きく分けて、ハードディスク等に格納されたデータファイル等によって実現されるデータ部（ユーザ情報データベース３１、利用権利データベース３２、コンテンツ鍵データベース３３）と、ＣＰＵ、ＲＡＭ、ＲＯＭ等のハードウェア及びＣＰＵにより実行されるプログラム等によって実現される処理部（ユーザ特定部３４、ＬＴ生成部３５、ＬＴ解析部３６、利用権利更新部３７、通信部３８）とからなる。

ユーザ情報データベース３１は、ユーザ端末４の端末ＩＤを用いてそのユーザ端末を購入し、このコンテンツ利用管理システム１に会員登録したユーザのユーザＩＤ、ユーザ名等を記憶する。利用権利データベース３２は、コンテンツブロバイダが決定したコンテンツ毎の利用権（ＵＲ−Ｃ）と、コンテンツに対するユーザの権利情報（ライセンス）を蓄積する。具体的には、利用権利データベース３２は、ユーザが購入したコンテンツや、そのコンテンツに対してユーザが有する利用権（ライセンス）の残存情報を利用の態様（例えば、再生、印刷等）毎に複数記憶する記憶部である。コンテンツ鍵データベース３３は、コンテンツの関連情報（コンテンツ鍵など）を蓄積する。具体的には、コンテンツを暗号化するための複数のコンテンツ鍵と、コンテンツＩＤとを対応付けて記憶する。

ユーザ特定部３４は、ユーザ端末４の端末ＩＤを用いてこの端末ＩＤに対応したユーザＩＤ等を特定する。ＬＴ生成部３５は、ユーザ端末４から送られてきたＬＴ発行要求に含まれるＥＬＩに基づいて対応したＬＴを生成したりする。ＬＴ解析部３６は、ユーザ端末４から送られてきたＬＴを解析し、解析結果に応じてＵＲ−Ｕｓの内容を更新したりする。利用権利更新部３７は、ＬＴ生成部３５がＬＴをユーザ端末４に送信した場合に、利用権利データベース３２に格納されたＵＲ−Ｕｓの内容を更新する。

通信部３８は、ユーザ端末４と通信する。具体的には、通信部３８は、通信ネットワーク５を介してユーザ端末４と通信するＷｅｂページに記述されるスクリプトやプログラム等によって実現される通信インタフェースであって、ユーザ端末４から送信されてきたコマンドやメッセージを解析したり、その結果に応じてユーザ特定部３４及びＬＴ解析部３６に処理を依頼したり、ＬＴ生成部３５から渡されたＬＴをユーザ端末４に配信したり、端末との間でＳＡＣを形成したりする。なお、通信部３８は、ユーザ端末４からの要求に応じて利用権利データベース３２のＵＲ−Ｕｓに関する情報や、コンテンツデータベース２１のコンテンツに関する情報をバスを介して取得し、要求を発したユーザ端末４にこれらの情報を送信し、ＬＴの購入や、ＬＴ発行要求のためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提供する。

図２５は、図２３に示されるユーザ端末４の構成を示す機能ブロック図である。なお、本図には通信ネットワーク５も併せて示されている。

ユーザ端末４は、大きく分けて、ＬＴの発行を要求したり、取得したＬＴを統括的に管理するクライアント４１と、音楽、映画等のコンテンツを再生するレンダリングプラグイン４２と、取得したコンテンツやＬＴを外部へ書き出すストレージプラグイン４３と、書き出されたコンテンツやＬＴを格納するＳＤカード等の外部メディア４４とから構成される。

クライアント４１は、通信部４１０Ａと、モニタ４１１ａと、操作部４１１ｂと、コンテンツデータベース４１２Ａと、ＬＴデータベース４１３Ａと、端末ＩＤ蓄積部４１４Ａと、ＬＴ取得部４１５Ａと、ＬＴ返却部４１６Ａと、ＬＴ管理・更新部４１７Ａと、コンテンツ利用可否判定部４１８Ａと、プラグイン制御部４１９Ａとからなる。レンダリングプラグイン４２は、再生条件判定部４２１Ａと、コンテンツ復号部４２２Ａと、コンテンツ再生部４２３Ａとからなる。また、ストレージプラグイン４３は、書き出し条件判定部４３１Ａと、書き込み用データ生成部４３２Ａと、メディアアクセス部４３３Ａとからなる。

クライアント４１の通信部４１０Ａは、コンテンツ配信サーバ２及び利用条件管理サーバ３との間で通信を行う。具体的には、通信部４１０Ａは、ブラウザソフト等に従って通信ネットワーク５を介してコンテンツ配信サーバ２及び利用条件管理サーバ３と通信する通信インタフェースであり、操作部４１１ｂからの依頼に応じてコンテンツ配信サーバ２から送信されてきたコンテンツをコンテンツデータベース４１２Ａに格納したり、利用条件管理サーバ３の通信部３８との間でＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｃｈａｎｎｅｌ：認証付き安全な通信路）を形成し、コンテンツの利用権利購入要求や、ＬＴ発行要求のメッセージを利用条件管理サーバ３に送信したり、利用条件管理サーバ３から送信されてきたＬＴをＬＴデータベース４１３Ａに格納したりする。

モニタ４１１ａは、利用条件管理サーバ３が提供するＷｅｂページを表示したり、ＬＴの購入や、ＬＴ発行要求のためのＧＵＩを表示する。操作部４１１ｂは、ユーザの操作を受け付けるユーザインタフェースである。コンテンツデータベース４１２Ａは、例えば、ＨＤＤ等で構成され、暗号化されたコンテンツを蓄積する。ＬＴデータベース４１３Ａは、通信部４１０Ａから送られてきたＬＴをセキュアに蓄積する。端末ＩＤ蓄積部４１４Ａは、その端末の端末ＩＤ等を蓄積する。

ＬＴ取得部４１５Ａは、ＬＴ発行要求を生成し、通信部４１０Ａを介して利用条件管理サーバ３に送信したり、利用条件管理サーバ３から送信されてきたＬＴを取得してＬＴデータベース４１３Ａに格納したりする。ＬＴ返却部４１６Ａは、所定の場合にＬＴを通信部４１０Ａを介して利用条件管理サーバ３に返却する。ＬＴ管理・更新部４１７Ａは、ＬＴデータベース４１３Ａに格納されているＬＴを管理したり、ＬＴに含まれる利用条件を更新したりする。コンテンツ利用可否判定部４１８Ａは、ＬＴの利用条件に基づいてそのＬＴが利用できるか否かの可否を判定する。プラグイン制御部４１９Ａは、セキュアなクロック機構を備え、レンダリングプラグイン４２におけるコンテンツ再生の時間を計測し、計測時間に基づいて再生回数を制御したりする。

レンダリングプラグイン４２の再生条件判定部４２１Ａは、クライアント４１から送られてきたレンダリングプラグイン４２における条件（Ｐ条件）に基づく再生条件を判定する。コンテンツ復号部４２２Ａは、クライアント４１から送られてきたコンテンツ鍵でコンテンツデータベース４１２Ａから取得したコンテンツを復号化する。コンテンツ再生部４２３Ａは、復号化されたコンテンツを再生する。

ストレージプラグイン４３の書き出し条件判定部４３１Ａは、クライアント４１から送られてきたストレージプラグイン４３における条件（Ｐ条件）に基づく書き出し条件を判定する。書き込み用データ生成部４３２Ａは、受信したＬＴや、コンテンツデータベース４１２Ａから取得したコンテンツを外部メディア４４用のフォーマットのデータに変換する。メディアアクセス部４３３Ａは、フォーマット変換されたデータを外部メディア４４に書き出す。

なお、このＮｅｔＤＲＭシステム１においては、利用条件（ＵＲ）は、コンテンツブロバイダが指定し、ユーザの購入対象となる利用条件ＵＲ−Ｃと、利用条件管理サーバで管理され、ユーザが購入し、現在所持している利用条件ＵＲ−Ｕｓと、ＵＲ−Ｕｓから一部を切り出され、ユーザ端末において管理される利用条件ＵＲ−Ｕｃとに分けて構成される。ＵＲ−Ｕｓは、ＬＴ発行要求に含まれるＥＬＩに対応したＬＴの発行により、ＵＲ−Ｃから回数などが減少する。なお、ＵＲ−Ｕｓはあるユーザが購入した複数のコンテンツをまとめて対象とすることができる一方、ＵＲ−Ｕｃは１つのコンテンツだけを対象とする。ＥＬＩは、どのコンテンツをどういう条件で使いたいかというＬＴ発行要求に埋め込まれる情報である。また、ＬＴは、指定されたコンテンツのコンテンツ鍵とＵＲ−Ｕｃが一緒になった情報である。また、ＬＴ発行要求があった場合などには、ＮｅｔＤＲＭサーバで管理している情報（Ｓ条件、例えば同時に利用できる端末数）に基づいてＬＴを発行してよいか否か判定される。ＮｅｔＤＲＭクライアントでは、クライアント条件（Ｃ条件、例えば、有効期間、利用回数、累積利用時間）に基づいてアクションを開始してもよいか否かを判定する。また、プラグインでは、プラグイン条件（Ｐ条件、例えば２ｃｈ再生等）に基づいて再生を制御する。

図２６は、図２４に示されるコンテンツデータベース２１が保持するコンテンツのデータフォーマットの構成例を示す図である。

コンテンツ１０は、そのコンテンツに付与されたユニークな識別子であるコンテンツＩＤ１１と、単一又は複数のキャラクタコード１２＃１，…，＃Ｎと、このキャラクタコード１２＃１〜＃Ｎで表される内容を示すメタデータ１３＃１，…，＃Ｎと、暗号化コンテンツデータ１４とからなる。

例えば、そのコンテンツが、音楽「波乗りジョージ」である場合、コンテンツＩＤ１１には「ｒｉｄｅｒｊｏｇｉ」が記述される。また、キャラクタコード１２＃１，…，＃Ｎには、例えば、ＥＵＣ（Ｅｘｔｅｎｄｅｄ Ｕｎｉｘ（登録商標） Ｃｏｄｅ）や、ｊｕｎｅｔコード（ｉｓｏ−２０２２−ｊｐコード）等である旨が記述される。また、メタデータ１３＃１，…，＃Ｎには、例えば、「曲」名、「歌手」名、「バックバンド」名、「作詞家」名、「作曲家」名等が記述される。さらに、暗号化コンテンツデータ１４には、コンテンツ自体（この例では、音楽「波乗りジョージ」）が所定の鍵で暗号化された上で格納される。

なお、このコンテンツ１０の暗号化コンテンツデータ１４は、コンテンツＩＤ１１で対応付けられたコンテンツ鍵を手に入れて復号化しないと、視聴することができない。このため、このシステムに加入していない一般ユーザの端末からもコンテンツ１０を自由にダウンロードできるようになっている。

図２７は、図２４に示されるユーザ情報データベース３１が保持するユーザ情報テーブルの構成例を示す図である。

ユーザ情報テーブル５０は、ユーザが購入し、利用条件管理サーバ３に登録したユーザ端末の端末ＩＤでユーザを特定するためのテーブルであって、このシステムにおけるユーザ端末に特有のユニークな識別子「端末ＩＤ」５１、このユーザ端末を購入したこのシステムにおけるユーザに特有のユニークな識別子「ユーザＩＤ」５２と、ユーザ名等、住所、電話番号（不図示）等とのフィールドが設けられている。

例えば、２台のユーザ端末を購入し、このユーザ端末をシステムに登録したユーザ、岡本の場合、この２台のユーザ端末にそれぞれ付与された端末ＩＤ「×××１１１」及び「×××２２２」と、岡本に付与されたユーザＩＤ「×××ＡＡＡ」と、そのユーザ名等、住所、電話番号等とが２つのレコードを用いて格納される。１台のユーザ端末を購入し、このユーザ端末をシステムに登録したユーザ、東の場合、このユーザ端末に付与された端末ＩＤ「×××３３３」と、東に付与されたユーザＩＤ「×××ＢＢＢ」と、そのユーザ名等、住所、電話番号等とが１つのレコードに格納される。

図２８は、図２４に示される利用権利データベース３２が保持する利用権利管理テーブルの構成例を示す図である。

利用権利管理テーブル６０は、ユーザＩＤでこのユーザが購入した各コンテンツに対する利用権（ＵＲ−Ｕｓ）を管理するためのテーブルであって、「ユーザＩＤ」６０Ａと、この利用条件管理サーバ３で管理される利用権の内容「ＵＲ−Ｕｓ」６０Ｂのフィールドから構成される。

例えば、ユーザ岡本（ユーザＩＤ「×××ＡＡＡ」）の場合、曲「波乗りジョージ」と、電子書籍「狭辞苑」との２つのコンテンツに対する利用権を購入しているときには、ＵＲ−Ｕｓ６０Ｂにはこの波乗りジョージの利用権と、狭辞苑の利用権とがレコードを変えて格納される。

またユーザ東（ユーザＩＤ「×××ＢＢＢ」）の場合、映画「蜘蛛娘」の１つのコンテンツに対する利用権を購入しているときには、ＵＲ−Ｕｓ６０Ｂにはこの蜘蛛娘の利用権が１つのレコードに格納される。

図２９は、図２８に示されるＵＲ−Ｕｓ６０Ｂの詳細な構成例を示す図である。
ＵＲ−Ｕｓ６０Ｂは、大きく分けて、利用の基本内容を管理するためのＵＲ−Ｕｓヘッダ６１と、利用権の具体的内容（再生、プリント、移動等のアクション）を管理するための単一又は複数のアクション情報６２＃１〜６２＃ｎとから構成される。この、利用権の内容は、コンテンツ提供者やサーバの管理者がコンテンツの属性に応じてコンテンツ毎に初期値（ＵＲ−Ｃ）が予め定められており、コンテンツ購入時にＵＲ−Ｃと同内容の利用権がユーザに付与される。

ＵＲ−Ｕｓヘッダ６１は、ＵＲ−Ｕｓヘッダ６１のサイズを示すＵＲ−Ｕｓヘッダサイズ６１１と、このユーザが購入したコンテンツ毎の利用権に対して付与されたこのシステムにおける特有のユニークな識別子ＵＲ−ＵｓＩＤ６１２と、有効期間の開始時刻６１３と、有効期間の終了時刻６１４と、移動許可フラグ６１５と、同時利用可能数６１６と、発行状態ＬＴ数６１７と、アクション情報６２＃１〜６２＃ｎの数を表すアクション情報数６１８とからなる。

有効期間の開始時刻６１３及び有効期間の終了時刻６１４は、利用条件管理サーバ３が管理するユーザの利用権の有効期間の始期及び終期をそれぞれ示す。但し、例えば、ＵＲ−Ｕｓは１月有効だが、ＬＴは常に１日だけ有効とする場合のように、ＬＴにＵＲ−Ｕｓより短い有効期間を指定することができる。また、有効期限を設けない場合には、両時刻６１３，６１４に制限なし（ｕｎｌｉｍｉｔｅｄ）を格納することができる。このＬＴに指定される有効期間は、ＮｅｔＤＲＭシステム１のクライアントでアクションを開始してもよいか否かを判定する条件（以下、「Ｃ条件」とも記す。）として用いられる。

移動許可フラグ６１５は、このＵＲ−Ｕｓ６０Ｂに基づいて発行されたＬＴを発行先の端末から他の端末及び外部メディアに移動（Ｍｏｖｅ−ｏｕｔ、Ｅｘｐｏｒｔ）できるか否かを表す。

同時利用可能数６１６及び発行状態ＬＴ数６１７は、複数のユーザ端末を所持しているユーザ（例えば、岡本）が、電子書籍のようなコンテンツをこれらのユーザ端末で台数制限付きで共同利用するような場合に対処するために設けられたものである。同時利用可能数６１６には、同時に、何枚のＬＴを発行できるかを示す枚数が格納される。また、発行状態ＬＴ数６１７には、その時点で何枚のＬＴを発行されているかを表す枚数が格納される。なお、この発行状態ＬＴ数６１７の枚数は、ＬＴを発行する毎にインクリメントされ、同時利用可能数に達するとＬＴの発行が停止される。これに対して、発行したＬＴがユーザ端末から戻されると発行状態ＬＴ数６１７の枚数がデクリメントされる。これにより、同時にコンテンツを利用できる端末数を制限することができる。なお、この同時利用可能数６１６及び発行状態ＬＴ数６１７は、ＮｅｔＤＲＭシステム１のサーバで判定される条件（以下、「Ｓ条件」とも記す。）として用いられる。

また、各アクション情報６２＃１〜６２＃ｎは、アクション情報６２＃１〜６２＃ｎのサイズを表すアクション情報サイズ６２１と、アクションＩＤ６２２と、最長利用時間６２３と、１回判定しきい値・回数カウンタ／累積利用時間６２４と、Ｐ条件６２５＃１〜６２５＃ｎとからなる。

アクションＩＤ６２２には、再生（ＰｌａｙＢａｃｋ）、印刷（Ｐｒｉｎｔ）等、コンテンツの利用の態様（アクション）を表す識別子が格納される。このアクションＩＤ６２２は、例えば、再生（ＰｌａｙＢａｃｋ）の場合には「２」が、印刷（Ｐｒｉｎｔ）の場合には「５」が格納される。

最長利用時間６２３には、再生処理などにおいてコンテンツを連続して利用できる最大時間が格納される。

１回判定しきい値・回数カウンタ／累積利用時間６２４に格納される、１回判定しきい値はコンテンツの利用を１回と判断する時間を示し、回数カウンタはコンテンツを利用することができる残りの回数を示し、累積利用時間はコンテンツを利用できる累積時間を示している。なお、１回判定しきい値・回数カウンタと累積利用時間とは排他的な関係にあり、両方が同時に指定されることはない。

ここで、回数カウンタの値は、ユーザのＬＴ発行要求に応じて切り出される利用条件、ライセンス情報の分ずつ、初期値から順次デクリメントされたり、コンテンツ提供者のサービス提供要求に応じてインクリメントされたりする。

Ｐ条件６２５＃１〜６２５＃ｎには、ユーザ端末のプラグインにおいてコンテンツ毎にそのコンテンツのアクションを実行するため制御条件が格納される。例えばプリント用のコンテンツの場合にあっては白黒で印刷しなければならないであり、音楽再生用のコンテンツの場合、２チャンネルステレオで再生しなければならない等が該当する。

なお、コンテンツが複数のコンテンツからなるアルバムや全集である場合には、このアルバムや全集に含まれるコンテンツの数、コンテンツ数６３１と、このアルバムや全集に含まれるコンテンツの識別子、コンテンツＩＤ６３２＃１〜６３２＃ｎとをこのＵＲ−Ｕｓ６０Ｂに付加することで対応される。

図３０は、図２３〜図２５に示されるＬＴ発行要求７０のデータフォーマット構成例を示す図である。

ＬＴ発行要求７０は、大きく分けて、この要求がＬＴ発行要求であることを示すユニークな識別子であるＬＴ発行要求識別子７１と、ＬＴ発行要求７０を発するユーザ端末の端末ＩＤ７２と、どのコンテンツをどういう条件で使いたいかを示す期待ＬＴ情報（Ｅｘｐｅｃｔｅｄ ＬＴ Ｉｎｆｏｒｍａｔｉｏｎ、以下「ＥＬＩ」とも記す。）７３とからなる。

ＥＬＩ７３は、発行要求の基本内容を示すＥＬＩヘッダ７３０と、発行要求の具体的内容を示す単一又は複数の期待アクションタグブロック７４０＃１〜７４０＃ｎとからなる。

ＥＬＩヘッダ７３０は、このＥＬＩ７３がＥＬＩであることを示すＥＬＩ識別子７３１と、このＮｅｔＤＲＭシステム１で定められる仕様において定められるユーザ端末のバージョンを示す ＮｅｔＤＲＭバージョン番号７３２と、ＥＬＩ７３のサイズを示すＥＬＩサイズ７３３と、発行要求を希望するＬＴの対象となるコンテンツのコンテンツＩＤ７３４と、利用権の切り出し対象となる利用条件管理サーバ３が管理する利用権の識別子、ＵＲ−ＵｓＩＤ７３５と、ユーザ端末のクライアントが、ＬＴ格納用のセキュアなＤＢを持つか、時間管理用のセキュアなクロックを持つか否か表す、クライアント能力フラグ７３６と、ＥＬＩで希望する条件（例えば、回数）のＬＴを発行できない場合、サーバがＬＴを発行しないことを望むか、条件が縮小された回数のＬＴでも発行することを望むかを表すフラグ、ＬＴ発行拒否フラグ７３７とからなる。なお、ＬＴ発行拒否フラグ７３７には、発行拒否の場合には「ＯＮ」が、縮小を許容する場合には「ＯＦＦ」が格納される。

期待アクションタグブロック７４０＃１〜７４０＃ｎは、ＬＴに格納して欲しいアクションの識別子、アクションＩＤ７４１と、発行するＬＴに設定を望む回数を示す回数カウンタ、又はＬＴに設定を望む累積利用時間を示す期待回数／期待累積利用時間７４２とからなる。

図３１は、図２３〜図２５に示されるＬＴのデータフォーマット構成例を示す図である。

ＬＴ８０は、大きく分けて、利用の基本内容を管理するためのＬＴヘッダ８１と、利用権の具体的内容（再生、プリント等のアクション）を管理するための単一又は複数のアクションタグブロック８２と、コンテンツ鍵８３と、オプションで付加可能なＬＴフッタ８４とからなり、コンテンツＩＤと、アクションＩＤによるＣ条件及びＰ条件の束とコンテンツ鍵等とで示される。

ＬＴヘッダ８１は、ＬＴ識別子８１０と、ＮｅｔＤＲＭバージョン番号８１１と、ＬＴサイズ８１２と、コンテンツＩＤ８１３と、ＵＲ−ＵｓＩＤ８１４と、ＬＴ状態フラグ（ＬＴ即時消費フラグ／ＬＴ自動返却フラグ）８１５と、ＬＴ有効期間の開始時刻８１６と、ＬＴ有効期間の終了時刻８１７と、ＬＴ移動許可フラグ８１８と、ＬＴ暗号化法８１９とが格納される。

ＬＴ識別子８１０は、このデータがこのコンテンツ利用管理システム１で扱われるライセンスチケットであることを表す。ＮｅｔＤＲＭバージョン番号８１１は、このシステムで定められるサーバが提供する仕様のバージョンを示す。ＬＴサイズ８１２は、ＬＴ全体のデータサイズを示す。コンテンツＩＤ８１３は、このＬＴの対象であるコンテンツのＩＤを示す。ＵＲ−ＵｓＩＤ８１４は、このＬＴの発行の元であるＵＲ−ＵｓのＩＤを示す。

ＬＴ状態フラグ（ＬＴ即時消費フラグ／ＬＴ自動返却フラグ）８１５は、このＬＴは記録媒体に書き込めず、即座に消費しなければならないかを表すフラグ、ＬＴ即時消費フラグと、このＬＴに含まれる権利が消失した時、サーバに自動的に返却しなければならないかを表すフラグ、ＬＴ自動返却フラグとを示す。なお、ＬＴ自動返却フラグは、ＵＲ−Ｕｓの同時利用可能数が有限の場合に「ＯＮ」に設定され、ＵＲ−Ｕｓの同時利用可能数が無限の場合に「ＯＦＦ」に設定される。ＬＴ即時消費フラグは、クライアントにセキュアなＬＴデータベースがない場合と、ＵＲ−Ｕｓに有効期限が設定されており、且つクライアントにセキュアな時計機能がない場合に「ＯＮ」に設定され、これ以外の場合に「ＯＦＦ」に設定される。

ＬＴ有効期間の開始時刻８１６は、このＬＴが有効になる日時を示す。ＬＴ有効期間の終了時刻８１７は、ＬＴが無効になる日時を示す。ＬＴ移動許可フラグ８１８は、このＬ
Ｔを移動できるか、Ｍｏｖｅ−ｏｕｔできるか、Ｅｘｐｏｒｔできるかを表す。ＬＴ暗号化法８１９は、コンテンツ鍵８３及びオプションで付加されうるＬＴフッタ８４に適用される暗号方式（ＤＥＳ，ＡＥＳ等）を示す。

アクションタグブロック８２＃１〜８２＃ｎは、アクションＩＤ８２１と、最長利用時間８２２と、１回判定しきい値・回数カウンタ／累積利用時間８２３と、Ｐ条件８２４＃１〜８２４＃ｎとからなる。

アクションＩＤ８２１は、コンテンツに対するアクション内容を特定するＩＤを示す。最長利用時間８２２は、コンテンツを連続して操作できる最大時間を示す。１回判定しきい値・回数カウンタ／累積利用時間８２３の１回判定しきい値は、コンテンツの操作を１回と判断する時間を示す。回数カウンタは、このＬＴでコンテンツを操作できる回数を示す。累積利用時間は、コンテンツを操作できる累積の操作時間を示す。なお、最長利用時間８２２ではポーズ等の間も時間のカウントが継続され、これに対して累積利用時間ではポーズ等の間、時間のカウントが停止される。

ここで、図３２を用いて回数カウンタの１回と、最長利用時間、１回判定しきい値、累積利用時間との関係を説明する。

累積利用時間は、最長利用時間よりも厳密な利用制御を行う場合に用いられ、通常のコンテンツ再生に必要な時間（例えば、１０日、最大約５年２２２日まで）が設定される。ＬＴ有効期間の開始日が７月１日でＬＴ有効期間の終了日が８月３１日の場合、この間であれば、５日、２日、３日のような細切れの日時のコンテンツ利用をすることができ、この累積時間が累積利用時間に達するとそのＬＴでのコンテンツ利用ができなくなる。

回数カウンタには任意の回数（例えば５回、最大で１６３８３回まで）を設定することができる。また、最長利用時間には任意の時間（例えば３分、最大で約１８時間まで）を設定することができる。また、１回判定しきい値には任意の値（例えば３０秒、最大で１８時間まで）が設定される。ここで、ユーザ端末４においてコンテンツ操作（利用）を開始すると開始から２０秒経過した時点で再生を停止すると、この再生は１回とみなされない。これに対して開始から１回判定しきい値３０秒経過すると１回と判定され、最長利用時間が経過するまで、その間のポーズ等を含めてコンテンツを再生することができる。なお、回数カウンタの値は、１回判定しきい値を超えた時点で１デクリメントされる。

図３１に戻り、コンテンツ鍵８３は、このＬＴに関連付けられたコンテンツの暗号を解く復号鍵、コンテンツ鍵が暗号化されたまま格納される。なお、オプションとしてコンテンツ鍵８３の次にＬＴフッタ８４を付加することができる。このＬＴフッタ８４には、ＬＴヘッダ８１からコンテンツ鍵８３のＳＨＡ−１アルゴリズムによるハッシュ値が暗号化されて格納され、ＬＴが信頼できない経路で配信された場合、この値で改ざんチェックを行うことができるようになっている。

次いで、ＬＴ取得動作及びコンテンツ再生動作を説明する。
このようなＬＴ取得動作及びコンテンツ再生動作を行うユーザ端末においては、その端末のモニタに図３３に示される画面が表示される。

本図に示されるように、画面中には、ユーザ端末やサーバに保持されるコンテンツや、ＬＴ、ＵＲ−Ｕｓ、Ｐ条件等をリスト表示するリストボックス９０１、リストボックス９０１でカーソルが合わせられたコンテンツの概要等の説明を表示するコンテンツ説明ボックス９０２、リストボックス９０１でカーソルが合わせられたコンテンツの再生画像等を表示するためのコンテンツ再生ボックス９０３のほか、コンテンツの利用権利を購入の際にクリックされる利用権利購入ボタン９０４、ＬＴ取得の際に押下されるＬＴ取得ボタン９０５、この画面の表示データを更新する場合に押下される更新ボタン９０７、再生スタート、停止、ストップ、早戻し、早送り等の再生操作をするための再生操作ボタン９０８、再生時間等を表示する時間表示ボックス９０９等が設けられる。

リストボックス９０１には、コンテンツのタイトル（図示例では、「波乗りジョージ」、「狭辞苑」、「突入せよ！！赤城山荘」）や、そのコンテンツの再生可能回数（図示例では、「再生９回」、「制限なし」）、有効期限（図示例では、「制限なし」、「２００２／１０／３１」）、Ｐ条件（図示例では、「２ｃｈ再生」、「白黒印刷」）等が表示される。なお、コンテンツ「突入せよ！！赤城山荘」は、このコンテンツの販売促進のためにコンテンツ配信サーバ２から送られてきたプレビュー版であり、このコンテンツにカーソルが合わせられている状態が示されている。

このリストボックス９０１の左端には、アイコン９０１ａ〜９０１ｅ等が表示される。アイコン９０１ａは、この端末にコンテンツに対応したＬＴを保持しており、且つサーバにＵＲ−Ｕｓがあることを示している。アイコン９０１ｂは、この端末にはコンテンツに対応したＬＴがないが、サーバにはＵＲ−Ｕｓがあることを示している。アイコン９０１ｃは、この端末にＬＴがなく、且つサーバにもＵＲ−Ｕｓがないことを示している。アイコン９０１ｄは、この端末にコンテンツを保持していることを示している。アイコン９０１ｅは、この端末にコンテンツを保持していないことを示している。これらのアイコン９０１ａ〜９０１ｅでＵＲ−Ｕｓ、ＬＴ及びコンテンツのありなしの状態を全て表すことができる。

コンテンツ再生ボックス９０３には、リストボックス９０１でカーソルが合わせられたコンテンツの再生画面が表示される。

コンテンツ再生ボックス９０３の上部には、音楽、ビデオ、移動、電子書籍の再生等の各種アクションを選択するためのタブが設けられており、図示例ではリストボックス９０１でカーソルが合わせられたコンテンツを再生するためのビデオ用のタブが選択された状態が示されている。この状態で再生用の再生操作ボタン９０８がクリックされると、コンテンツ配信サーバ２から送られてきたコンテンツ「突入せよ！！赤城山荘事件」のプレビュー画面が表示される。

なお、ビデオ再生用のタブなどに設けられたアイコン９０３ａは、そのコンテンツ再生用のプラグインを保持していることを示す。コンテンツ移動用のタブに設けられたアイコン９０３ｂは、コンテンツ再生（ここでは移動）用のプラグインがないことを示す。このようにプラグインがない場合には、例えば外部メディア４４を装着する装置がない等のハード的な不備がない限り、プラグインがないことを示すタブが選択された際に、不足するプラグイン（ここでは、移動用のプラグイン）を提供するサーバにアクセスし、不足のプラグインをダウンロードし、アイコン９０３ａが表示されるようになっている。

ここで、リストボックス９０１の表示内容やコンテンツ説明ボックス９０２の表示内容は、この画面の表示の際にコンテンツデータベース４１２Ａに格納されたコンテンツのメタデータを取得したり、ＬＴデータベース４１３Ａに格納されたＬＴの権利内容を取得したり、利用条件管理サーバ３に対してＧｅｔＵＲ−Ｕｓ，ＧｅｔＰ条件テキスト，Ｇｅｔメタデータなどコマンドを送り、サーバ内にある権利ＵＲ−Ｕｓの内容（Ｐ条件も含む）を取得したり、端末にはないが、利用権利を保持するコンテンツのメタデータを取得し、取得した情報に基づいて作成される。

図３４は、サーバにある権利内容を取得する場合に、クライアント４１から利用条件管理サーバ３に送信されるＧｅｔＵＲ−Ｕｓの構成を示す図である。

このＧｅｔＵＲ−Ｕｓ９１は、ＧｅｔＵＲ−Ｕｓであることを示す識別子ＧｅｔＵＲ−Ｕｓ識別子９１１と、このＧｅｔＵＲ−Ｕｓ９１を送信したユーザ端末を識別する端末ＩＤ９１２と、取得するデータをどのような文字コードで表示する記を指定するためのキャラクタコード９１３とからなる。このキャラクタコード９１３には、通常、ＥＵＣや、ｊｕｎｅｔコード、シフトＪＩＳコード等が格納される。このようなＧｅｔＵＲ−Ｕｓ９１を送ることにより、端末ＩＤ９１２に対応したユーザＩＤで管理されるサーバにあるＵＲ−Ｕｓの一覧を取得することができる。なお、その際、キャラクタコードで指定した文字コードでＵＲ−ＵｓＮａｍｅ（利用権利管理テーブル６０の図示しないフィールドに格納されるコンテンツのジャンルや、６０年代のロック等、権利の内容名）も同時に取得する。また、ＧｅｔＵＲ−Ｕｓ９１を送る際に、ＧｅｔＰ条件テキストをクライアント４１から利用条件管理サーバ３に送信する。

図３５は、ＧｅｔＰ条件テキストの構成例を示す図である。
ＧｅｔＰ条件テキスト９２は、Ｐ条件の表示内容を、キャラクタコードで指定した文字コードで取得するためのものであって、送信した情報がＧｅｔＰ条件テキストであることを示す識別子、ＧｅｔＰ条件テキスト識別子９２１と、ＧｅｔＰ条件テキスト９２を送信したユーザ端末を識別するための端末ＩＤ９２２と、Ｐ条件を表示する文字コードを指定するためのキャラクタコード９２３と、単一又は複数のＰ条件ＩＤ９２４＃１〜９２４＃Ｎとからなる。このように構成されたＧｅｔＰ条件テキスト９２を送信することにより、ＧｅｔＵＲ−Ｕｓ９１で得られた各ＵＲ−Ｕｓに含まれるＰ条件の表示用情報（例えば、再生条件の指定（２ｃｈ再生、白黒印刷など）や、再生する際の出力インタフェースの指定（例えば、アナログ、Ｐｒｏｔｅｃｔｅｄデジタル、Ｎｏｎ−Ｐｒｏｔｅｃｔｅｄデジタルなど））を取得することができる。

図３６は、上記ＧｅｔＰ条件テキスト９２により利用条件管理サーバ３から取得されるＰ条件の表示用情報の構成例である。Ｐ条件の表示用情報９３は、複数のＰ条件９３１＃１〜９３１＃Ｎからなる。

Ｐ条件９３１＃１は、図示例ではレンダリング用のＰ条件であり、モノラル再生でしかもアナログ出力の場合だけが許可（図中に示される「○」）されており、Ｐｒｏｔｅｃｔｅｄデジタル出力（例えば、暗号化されたデジタル出力）も、Ｎｏｎ−Ｐｒｏｔｅｃｔｅｄデジタル出力（例えば、暗号化されていない状態でのデジタル出力）も禁止（図中に示される「×」）されている。Ｐ条件９３１＃２は、図示例ではストレージ用のＰ条件であり、ＳＤカードへのコンテンツ転送について、Ｐｒｏｔｅｃｔｅｄデジタル出力は許可されているが、アナログ出力及びＮｏｎ−Ｐｒｏｔｅｃｔｅｄデジタル出力は禁止されていることが示されている。Ｐ条件９３１＃Ｎは、図示例ではストレージ用のＰ条件であり、メモリスティックへのコンテンツ転送について、Ｐｒｏｔｅｃｔｅｄデジタル出力は許可されているが、アナログ出力及びＮｏｎ−Ｐｒｏｔｅｃｔｅｄデジタル出力は禁止されていることが示されている。

図３７は、Ｇｅｔメタデータの構成例を示す図である。
Ｇｅｔメタデータ９４は、この情報がＧｅｔメタデータであることを示す識別子、Ｇｅｔメタデータ識別子９４１と、このＧｅｔメタデータ９４を送信したユーザ端末を識別する端末ＩＤ９４２と、コンテンツのメタデータを、指定した文字コードで取得するためのキャラクタコード９４３と、メタデータを得る対象のコンテンツを識別するコンテンツＩＤ９４４＃１〜９４４＃Ｎとから構成される。このＧｅｔメタデータ９４を受信した利用条件管理サーバ３の通信部３８は、コンテンツ配信サーバ２のコンテンツデータベース２１にアクセスし、コンテンツＩＤ９４４＃１〜９４４＃Ｎで指定されたコンテンツのメタデータ（図２６参照）を取り出して、ユーザ端末４に送信する。これにより、ユーザ端末４は、端末内にないコンテンツのメタデータを取得することができる。

このようなＧｅｔＵＲ−Ｕｓ９１、ＧｅｔＰ条件テキスト９２、Ｇｅｔメタデータ９４等を送信し、必要な情報を取得して画面用のデータに再構成することにより図３３に示される画面が作成される。

そして、リストボックス９０１に表示されたコンテンツ（例えば、狭辞苑）のＬＴを取得する場合、狭辞苑の欄にカーソルを合わせ、ＬＴ取得ボタン９０５をクリックする。これにより、ＬＴ取得プロセスが開始される。なお、コンテンツ「波乗りジョージ」についてさらにＬＴを取得するような場合には、このコンテンツにカーソルを合わせ、取得したい再生回数を入力し、ＬＴ取得ボタン９０５をクリックすればよい。

このようなＬＴ取得ボタン９０５がクリックされると、ユーザ端末４のクライアント４１及び利用条件管理サーバ３においてＬＴ取得プロセスが行われる。

図３８は、ユーザ端末４のクライアント４１及び利用条件管理サーバ３によって行われるＬＴ取得プロセスの動作を示すフローチャートである。

ＬＴ取得ボタン９０５がクリックされると、クライアント４１のＬＴ取得部４１５Ａは、ＬＴ発行要求の本体、即ちＥＬＩを生成するＥＬＩ生成プロセスを実行する（Ｓ１１）。そして、ＬＴ取得部４１５Ａは、生成したＥＬＩに、ＬＴ発行要求識別子７１と、端末ＩＤ蓄積部４１４Ａから読み出した端末ＩＤ７２とを付加することより図３０に示されるフォーマット構成に従うＬＴ発行要求を生成し、生成したＬＴ発行要求を利用条件管理サーバ３に送信する（Ｓ１２）。

一方、利用条件管理サーバ３のユーザ特定部３４は、通信部３８を介してユーザ端末４からＬＴ発行要求を受信すると、ユーザ情報データベース３１を参照し、ＬＴ発行要求７０に含まれる端末ＩＤ７２からユーザ（ユーザＩＤ）を特定する（Ｓ２１）。

ユーザ特定部３４がユーザを特定できた場合（Ｓ２２でＹＥＳ）、ＬＴ生成部３５は、利用権利データベース３２に保持され、ユーザ特定部３４によって特定されたユーザＩＤに対応するＵＲ−Ｕｓに基づいて、ＬＴを発行できるか否かを判定するＬＴ発行可否判定プロセスを実行する（Ｓ２３）。

実行の結果、ＬＴ生成することが可能であれば（Ｓ２４でＹＥＳ）、ＬＴ生成部３５は、ＬＴを生成するＬＴ生成プロセスを実行し（Ｓ２５）、生成したＬＴをユーザ端末４に送信する（Ｓ２６）。

なお、ステップＳ２２においてユーザを特定できなかった場合（Ｓ２２でＮＯ）、あるいはステップＳ２４においてＬＴを生成できなかった場合（Ｓ２４でＮＯ）、ＬＴ生成部３５は、ＬＴ発行不可通知を生成し、送信する（Ｓ２７）。このＬＴ発行不可通知は、例えば、ＬＴ発行不可通知であることを特定するためのユニークな識別子の他、拒否の対象となったコンテンツのコンテンツＩＤ、未購入等の拒否理由を示すエラーコードなどからなる。

クライアント４１のＬＴ取得部４１５Ａは、通信部４１０Ａを介してＬＴを取得すると（Ｓ１３）、取得したＬＴに含まれるＬＴ状態フラグ（ＬＴ即時消費フラグ／ＬＴ自動返却フラグ）８１５を参照し、即時消費フラグが「ＯＦＦ」（蓄積）であるか否かを判断する（Ｓ１４）。判断の結果、即時消費フラグが「ＯＮ」（即時消費）である場合（Ｓ１４でＮＯ）、ＬＴ取得部４１５Ａは、ＬＴをＬＴデータベース４１３Ａに格納（登録）せずにＬＴ取得プロセスを終了する。この場合には、ＬＴを即時消費するため、このＬＴを用いたコンテンツ再生が直ちに実行される。これに対して、即時消費フラグが「ＯＦＦ」である場合（Ｓ１４でＹＥＳ）、ＬＴ取得部４１５Ａは、取得したＬＴをＬＴデータベース４１３Ａへ登録（格納）し（Ｓ１５）、ＬＴ取得プロセスを終了する。

また、ＬＴ取得部４１５Ａは、通信部４１０Ａを介してＬＴ発行不可通知を受信すると（Ｓ１６）、通信部４１０Ａを介してモニタ４１１ａに拒否理由等を表示させ、ＬＴ取得プロセスを終了する。

図３９は、図３８に示されるＥＬＩ生成プロセス（Ｓ１１）のサブルーチンを示すフローチャートである。

このＥＬＩ生成プロセスのサブルーチンでは、ＬＴ取得部４１５Ａは、先ず、これから作成するＥＬＩヘッダのＥＬＩ識別子、ＮｅｔＤＲＭバージョン番号に規定の値を設定する（Ｓ１１１）。次いで、ＬＴ取得部４１５Ａは、ＥＬＩサイズを計算し、得られたＥＬＩサイズをＥＬＩヘッダに設定する（Ｓ１１２）。そして、ＬＴ取得部４１５Ａは、要求するＬＴの対象となるコンテンツのコンテンツＩＤをＥＬＩヘッダに設定し（Ｓ１１３）、ＬＴの元となるＵＲ−ＵｓのＵＲ−ＵｓＩＤをＥＬＩヘッダに設定し（Ｓ１１４）、このユーザ端末でサポートするクライアントの能力に合ったクライアント能力フラグをＥＬＩヘッダ７３０に設定し（Ｓ１１５）、ユーザから指定された値（発行拒否の場合には「ＯＮ」、縮小を許容する場合には「ＯＦＦ」）をＬＴ発行拒否フラグ７３７に設定する（Ｓ１１６）。

ＥＬＩヘッダへの設定が終わると、ＬＴ取得部４１５Ａは、ユーザから指定されたアクションの値（例えば、再生の場合、「２」）を期待アクションタグブロック７４０のアクションＩＤ７４１に設定する（Ｓ１１７）。次いで、通信部４１０Ａ（ＬＴ取得部４１５Ａ）は、ユーザから指定された回数を期待回数／期待累積利用時間７４２に設定し（Ｓ１１８）、図３８に示されるメインルーチンにリターンする。これにより、ユーザが期待するＥＬＩが生成される。

なお、アクションが複数である場合には、このアクションの数だけステップＳ１１７，Ｓ１１８が繰り返される。また、ステップＳ１１６〜Ｓ１１８で設定される値は、予め定められたデフォルト値であってもよい。

図４０は、図３８に示されるＬＴ発行可否判定プロセス（Ｓ２２）のサブルーチンを示すフローチャートである。

このＬＴ発行可否判定プロセスのサブルーチンにおいては、ＬＴ生成部３５は、先ず、ＬＴ発行要求のＥＬＩで指定された利用条件ＵＲ−Ｕｓが利用権利ＤＢに存在するか否か判断する（Ｓ２２１）。利用条件ＵＲ−Ｕｓが存在する場合（Ｓ２２１でＹＥＳ）、ＬＴ生成部３５は、ＵＲ−Ｕｓヘッダ６１の有効期間の終了時刻６１４を参照し、そのＵＲ−Ｕｓの有効期間は過ぎているか否か判断する（Ｓ２２２）。有効期間内である場合（Ｓ２２２でＮＯ）、ＬＴ生成部３５は、同時利用可能数６１６と、発行状態ＬＴ数６１７とに基づいてＵＲ−Ｕｓの発行状態ＬＴ数が同時利用可能数未満か否か判断する（Ｓ２２３）。同時利用可能数未満である場合（Ｓ２２３でＹＥＳ）、ＬＴ生成部３５は、１回判定しきい値・回数カウンタ／累積利用時間６２４を参照し、ＵＲ−Ｕｓの回数カウンタは「０」であるか否か判断する（Ｓ２２４）。回数カウンタが「０」でない、即ち回数カウンタが１以上である場合（Ｓ２２４でＮＯ）、ＬＴ生成部３５は、ＵＲ−Ｕｓの回数カウンタがＥＬＩの期待回数以上持っているか否か判断する（Ｓ２２５）。

期待回数以上持っていない場合（Ｓ２２５でＮＯ）、ＬＴ生成部３５は、ＥＬＩのＬＴ発行拒否フラグが「ＯＦＦ」か否か判断する（Ｓ２２６）。期待回数以上持っている場合（Ｓ２２５でＹＥＳ）、ＬＴ生成部３５は、ＬＴ発行可と判定し（Ｓ２２７）、このサブルーチンを終了し、図３８に示されるメインルーチンにリターンする。また、期待回数以上持っていないけれども（Ｓ２２５でＮＯ）、ＥＬＩのＬＴ発行拒否フラグが「ＯＦＦ」である場合、即ち期待回数よりも少なくてもよい場合には（Ｓ２２６でＹＥＳ）、ＬＴ生成部３５は、ＬＴ発行可と判定し（Ｓ２２７）、このサブルーチンを終了し、図３８に示されるメインルーチンにリターンする。

これに対して、利用権利データベースに利用条件ＵＲ−Ｕｓが存在しない場合（Ｓ２２１でＮＯ）、有効期間が過ぎている場合（Ｓ２２２でＹＥＳ）、同時利用可能数以上である場合（Ｓ２２３でＮＯ）、回数カウンタが「０」である場合（Ｓ２２４でＹＥＳ）、回数カウンタが「１」以上で（Ｓ２２５でＮＯ）且つＬＴ発行拒否フラグが「ＯＦＦ」（Ｓ２２６でＮＯ）である場合のいずれかの場合には、ＬＴ生成部３５は、ＬＴ発行不可と判定し（Ｓ２２８）、このサブルーチンを終了し、図３８に示されるメインルーチンにリターンする。これにより、利用条件管理サーバ３が管理するＵＲ−Ｕｓの範囲内で適切なＬＴ発行の可否を判定することができる。

図４１は、図３８に示されるＬＴ生成プロセス（Ｓ２５）のサブルーチンを示すフローチャートである。

このＬＴ生成プロセスのサブルーチンはＬＴ生成可（Ｓ２４でＹＥＳ）の場合に行われ、このルーチンにおいては、ＬＴ生成部３５は、先ず、ＬＴのＬＴ識別子、ＮｅｔＤＲＭバージョン番号及びＬＴ暗号化法に規定の値をＬＴヘッダ８１に設定する（Ｓ２５１）。次いで、ＬＴ生成部３５は、生成するＬＴのサイズを計算し、計算により求められたＬＴサイズをＬＴヘッダ８１に設定する（Ｓ２５２）。そして、ＬＴ生成部３５は、ＵＲ−ＵｓＩＤ、ＬＴ有効期間、ＬＴ移動許可フラグにＵＲ−Ｕｓの値と同一のものを設定し、コンテンツＩＤにＥＬＩに記述されているものと同一のものを設定する（Ｓ２５３）。

そして、ＬＴ生成部３５は、生成するＬＴを即時に消費するか否かを表すＬＴ即時消費フラグを設定するＬＴ即時消費フラグ設定プロセス（Ｓ２５４）、このＬＴでコンテンツ利用後サーバに自動的に返却するか否かを表すＬＴ自動返却フラグを設定するＬＴ自動返却フラグ設定プロセス（Ｓ２５５）を実行し、ＬＴヘッダ８１の生成を終える。

ＬＴヘッダ８１の生成が終わると、ＬＴ生成部３５は、利用要求に合致したアクション毎のタグブロックを設定するアクションタグブロック設定プロセス（Ｓ２５６）を実行し、コンテンツに対応するコンテンツ鍵をコンテンツ鍵データベースから読み出して設定する（Ｓ２５７）。ＬＴ生成部３５によるＬＴの生成が終わると、利用権利更新部３７は、ＬＴに切り出した分の利用条件を元の利用条件から減算し、ＵＲ−Ｕｓを減算結果に更新する（Ｓ２５８）。ＵＲ−Ｕｓの更新が終わると、このサブルーチンを終了し、図３８に示されるメインルーチンにリターンする。これにより、利用条件管理サーバ３が管理するＵＲ−Ｕｓから利用権を一部切り出したユーザのＬＴ発行要求に合致したＬＴを送信することができる。

図４２は、図４１に示されるＬＴ即時消費フラグ設定プロセス（Ｓ２５４）のサブルーチンを示すフローチャートである。

このＬＴ即時消費フラグ設定プロセスのサブルーチンにおいては、ＬＴ生成部３５は、先ずＬＴ発行要求のＥＬＩヘッダ７３０に含まれるクライアント能力フラグ７３６を参照し、クライアントがセキュアなＬＴＤＢを持つか否か判断する（Ｓ２５４１）。セキュアなＬＴＤＢを持っている場合（Ｓ２５４１でＹＥＳ）、ＬＴ生成部３５は、ＵＲ−Ｕｓの有効期限が設定されているか否かを判断する（Ｓ２５４２）。有効期限が設定されている場合（Ｓ２５４２でＹＥＳ）、ＬＴ生成部３５はクライアントがセキュアな時計機能を持つか否か判断する（Ｓ２５４３）。

有効期限が設定されていない場合、即ち、期間限定がない場合（Ｓ２５４２でＮＯ）と、有効期限が設定されている、即ち、期間限定があり（Ｓ２５４２でＹＥＳ）、且つクライアントがセキュアな時計機構を持っている場合（Ｓ２５４３でＹＥＳ）とのいずれかの場合、ＬＴ生成部３５は、ＬＴ即時消費フラグをＯＦＦに設定、即ちＬＴを即時に消費しなくてもよい旨を設定し（Ｓ２５４４）、このサブルーチンが終了し、図４１に示されるサブルーチンにリターンする。

これに対して、クライアントがセキュアなＬＴデータベースを持っていない場合（Ｓ２５４１でＮＯ）や、期間限定があり（Ｓ２５４２でＹＥＳ）、且つクライアントがセキュアな時計機構を持っていない場合（Ｓ２５４３でＮＯ）のいずれかの場合には、ＬＴ生成部３５は、ＬＴ即時消費フラグをＯＮ、即ちＬＴを即時に消費すべき旨を設定し（Ｓ２５４５）、このサブルーチンが終了し、図４１に示されるサブルーチンにリターンする。これにより、クライアントがセキュアなＬＴＤＢを持っているか否か、セキュアなクロック機構を持っているか否かのクライアント能力に応じてユーザ端末４においてＬＴを即時に消費させたり、保管させたりするといった制御をすることができる。

図４３は、図４１に示されるＬＴ自動返却フラグ設定プロセス（Ｓ２５５）のサブルーチンを示すフローチャートである。

このＬＴ自動返却フラグ設定プロセスのサブルーチンにおいては、ＬＴ生成部３５は、ＵＲ−Ｕｓの同時利用可能数が有限か否か判断する（Ｓ２５５１）。判断の結果、同時利用可能数が有限である場合（Ｓ２５５１でＹＥＳ）、ＬＴ生成部３５は、ＬＴ自動返却フラグを「ＯＮ」に設定し（Ｓ２５５２）、このサブルーチンを終了し、図４１に示されるサブルーチンにリターンする。これにより、ユーザ端末４がこのＬＴを用いてコンテンツを再生後、消費したＬＴをユーザ端末４から利用条件管理サーバ３に戻させてコンテンツの共同利用数の空きを作るといった制御を行うことができる。

これに対して、同時利用可能数が有限でない場合（Ｓ２５５１でＮＯ）、具体的には同時利用可能数が「∞」である場合、ＬＴ生成部３５は、ＬＴ自動返却フラグを「ＯＦＦ」に設定し（Ｓ２５５３）、このサブルーチンを終了し、図４１に示されるサブルーチンにリターンする。

図４４は、図４１に示されるアクションタグブロック設定プロセス（Ｓ２５６）のサブルーチンを示すフローチャートである。

このアクションタグブロック設定プロセスのサブルーチンにおいては、ＬＴ生成部３５は、先ず最長利用時間、Ｐ条件にＵＲ−Ｕｓと同一のものを設定し（Ｓ２５６１）、ＵＲ−Ｕｓの回数カウンタがＬＴ発行要求のＥＬＩに含まれる期待値回数以上か否か判断する（Ｓ２５６２）。判断の結果、期待回数以上であれば（Ｓ２５６２でＹＥＳ）、ＬＴ生成部３５は、アクションタグブロックの回数カウンタにＥＬＩの期待値回数の値を設定し（Ｓ２５６３）、このサブルーチンを終了し、図４１に示されるサブルーチンにリターンする。これにより、ユーザの要求通りの回数をＬＴに設定することができる。

これに対して、期待回数未満であれば（Ｓ２５６２でＮＯ）、回数カウンタにＵＲ−Ｕｓの回数カウンタの値、即ちＵＲ−Ｕｓに残っている期待回数よりも少ない全回数を設定し（Ｓ２５６４）、このサブルーチンを終了し、図４１に示されるサブルーチンにリターンする。これにより、ユーザの要求には足りないが、ＬＴ発行拒否フラグによる指示（ＯＦＦ）通りの回数をＬＴに設定することができる。

このような図３８〜図４４に示される処理により適切なＬＴ取得処理が実行される。
次いで、ユーザ端末４においてコンテンツを利用する場合、このユーザ端末４のクライアント４１とレンダリングプラグイン４２とで行われる処理（コンテンツ再生プロセス）及びクライアント４１とストレージプラグイン４３とで行われる処理（メディアへの書き出しプロセス）をこの順序で説明する。

図４５は、クライアント４１とレンダリングプラグイン４２とで行われるコンテンツ再生プロセスを示すフローチャートである。

この再生プロセスは、図３３に示される画面において、再生を希望するコンテンツ（例えば、コンテンツ波乗りジョージ）にカーソルを合わせＰｌａｙの再生操作ボタン９０８をクリックすることにより開始される。

このような再生操作ボタン９０８のクリックによるコンテンツ再生の指示があると、プラグイン制御部４１９Ａは、ユーザが再生希望したコンテンツを対象としたＬＴがＬＴデータベース４１３Ａにあるか否か判断する（Ｓ３１）。なお、ここではセキュアなＬＴＤＢ、即ちＬＴデータベース４１３Ａを持ち、コンテンツ利用可否判定部４１８Ａがセキュアなクロック機構を有する場合について説明する。

判断の結果、ＬＴデータベース４１３Ａに対象のＬＴが格納されている場合（Ｓ３１でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、対象のＬＴでコンテンツを再生できるか否かを判定する再生可否判断プロセス（Ｓ３４）を実行する。

これに対して、ＬＴデータベース４１３Ａに対象のＬＴがない場合には（Ｓ３１でＮＯ）、ＬＴ取得部４１５Ａに指示し、上記と同じＬＴ取得プロセス（Ｓ３２）を実行させ、ＬＴを取得できたか否か判断する（Ｓ３３）。なお、この場合には、連続複数回再生の指定がされない限り、通常再生に必要な最小単位、１回のＬＴ発行要求がなされる。そして、ＬＴを取得できた場合（Ｓ３３でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、再生可否判断プロセス（Ｓ３４）を実行する。

再生可否判断プロセス（Ｓ３４）の実行が終わると、プラグイン制御部４１９Ａは、コンテンツ利用可否判定部４１８Ａによる可否判断結果に基づいてそのＬＴで再生可か否か判断する（Ｓ３５）。判断の結果、再生可の場合（Ｓ３５でＹＥＳ）、プラグイン制御部４１９Ａは、ＬＴに含まれるコンテンツ鍵とＰ条件（２ｃｈ再生等）をレンダリングプラグイン４２へ渡す（Ｓ３６）。

これに対して、ＬＴを取得できなかった場合（Ｓ３３でＮＯ）や、再生不可と判断した場合（Ｓ３５でＮＯ）には、プラグイン制御部４１９Ａは、コンテンツ再生処理を終了する。

一方、レンダリングプラグイン４２の再生条件判定部４２１Ａは、コンテンツ復号鍵とＰ条件を受信すると（Ｓ４１）、Ｐ条件判断プロセス（レンダリング）を実行し（Ｓ４２）、実行の結果に基づいて再生可か否か判断する（Ｓ４３）。

判断の結果、再生可能であれば（Ｓ４３でＹＥＳ）、コンテンツ復号部４２２Ａは、コンテンツデータベース４１２Ａからコンテンツを取得し、取得したコンテンツをコンテンツ鍵で復号化する（Ｓ４４）。そして、コンテンツ再生部４２３Ａは、Ｐ条件で指定された条件で再生する（Ｓ４５）。これに対して、再生可でなければ（Ｓ４３でＮＯ）、その旨をプラグイン制御部４１９Ａに通知する。

レンダリングプラグイン４２で再生が行われると、プラグイン制御部４１９Ａはタイマを起動し、最長利用時間や、１回判定しきい値、累積利用時間による１回の管理を行い、プラグイン制御部４１９Ａが１回とカウントすると、ＬＴ管理・更新部４１７Ａは、ＬＴの内容（回数）を更新し（Ｓ３７）、コンテンツ再生処理を終了する。なお、再生時間の計測は、クライアントではなく、プラグイン側で行ってもよい。また、レンダリングプラグイン４２で再生可でない場合（Ｓ４３でＮＯ）、ＬＴ管理・更新部４１７Ａは、コンテンツ再生プロセスを終了する。

なお、コンテンツ再生プロセス終了の際、ＬＴ返却部４１６ＡはＬＴのＬＴ状態フラグ（ＬＴ自動返却フラグ）８１５を参照し、ＬＴ自動返却フラグがＯＮで、ＬＴの権利が全て消費されていると、そのＬＴを通信部４１０Ａを介して利用条件管理サーバ３に返却する。

図４６は、ＬＴを返却するためのＬＴ返却要求９５の構成例を示す図である。
このＬＴ返却要求９５は、この要求がＬＴ返却要求であることを表すユニークな識別子、ＬＴ返却要求識別子９５１と、ＬＴを返却するユーザ端末の端末ＩＤ９５２と、返却されるＬＴ９５３とからなる。この要求を受け取った利用条件管理サーバ３のＬＴ解析部３６は、端末ＩＤ９５２に対応するＵＲ−Ｕｓに戻し、そのＵＲ−Ｕｓの回数や同時利用可能数を更新する。これによりＬＴを利用条件管理サーバ３にバックアップさせたり、発行状態ＬＴ数６１７を減らすことができる。発行状態ＬＴ数６１７を減らした場合には、他の端末でのコンテンツ共同利用が可能となる。

図４７は、図４５に示される再生可否判定プロセス（Ｓ３４）のサブルーチンを示すフローチャートである。

この再生可否判定プロセスのサブルーチンにおいては、コンテンツ利用可否判定部４１８Ａは、先ず、ＬＴが有効期間内か否か判断する（Ｓ３４１）。有効期間内である場合（Ｓ３４１でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、ユーザが指定したアクションＩＤのアクションタグブロックがあるか否か判断する（Ｓ３４２）。判断の結果、アクションタグブロックがある場合（Ｓ３４２でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、そのアクションタグブロックの回数カウンタは「０」であるか否か判断する（Ｓ３４３）。回数カウンタが「０」でない場合（Ｓ３４３でＮＯ）、コンテンツ利用可否判定部４１８Ａは、再生可と判定し（Ｓ３４４）、この再生可否判定プロセスを終了し、図４５に示されるメインルーチンにリターンする。

これに対して、有効期間外である場合（Ｓ３４１でＮＯ）、ユーザが指定したアクションＩＤのアクションタグブロックがない場合（Ｓ３４２でＮＯ）、回数カウンタが「０」である場合（Ｓ３４３でＹＥＳ）の内のいずれかの場合、コンテンツ利用可否判定部４１８Ａは、再生不可と判定し（Ｓ３４５）、この再生可否判定プロセスを終了し、図４５に示されるメインルーチンにリターンする。

これにより、適切な再生可否を判定することができる。
図４８は、図４５に示されるＰ条件判定プロセス（レンダリング）（Ｓ４２）のサブルーチンを示すフローチャートである。

このＰ条件判定プロセスのサブルーチンでは、再生条件判定部４２１Ａは、Ｐ条件（例えば、モノラルで、アナログ出力で再生する。）を参照し、再生条件を判定する（Ｓ４２１）。判定の結果、Ｐ条件で指定された条件で再生できる場合（Ｓ４２２でＹＥＳ）、再生条件判定部４２１Ａは、再生可と判定し（Ｓ４２３）、このＰ条件判定プロセスを終了し、図４５に示されるメインルーチンにリターンする。これにより、Ｐ条件に従う再生条件で、コンテンツの再生が行われる。

これに対して、Ｐ条件で指定された条件で再生できない場合（Ｓ４２２でＮＯ）、再生条件判定部４２１Ａは、再生不可と判定し（Ｓ４２４）、このＰ条件判定プロセスを終了し、図４５に示されるメインルーチンにリターンする。

このような図４５〜図４８の処理により、適切なコンテンツ再生プロセスが実行される。

次いで、クライアント４１とストレージプラグイン４３とで行われる処理（メディアへの書き出しプロセス）を説明する。

図４９は、クライアント４１とストレージプラグイン４３とで行われるコンテンツ書き出し処理を示すフローチャートである。

このコンテンツ書き出し処理は、図３３に示される画面の移動タブを選択し、この移動タブを選択した場合にコンテンツ再生ボックス９０３中に表示される移動元と移動先とを表す画面（図示せず）において、移動元については書き出し処理が許容され、書き出し処理（移動）を希望するコンテンツ（図示せず）を選択し、移動先については所望の外部メディアを選択し、書き出しボタン（図示せず）をクリックすることにより開始される。

このような書き出しボタンのクリックによるコンテンツ書き出し指示があると、プラグイン制御部４１９Ａは、ユーザが書き出し希望したコンテンツを対象としたＬＴがＬＴデータベース４１３Ａにあるか否か判断する（Ｓ５１）。なお、ここでは、上記再生処理の場合と同様に、セキュアなＬＴＤＢ、即ちＬＴデータベース４１３Ａを持ち、コンテンツ利用可否判定部４１８Ａがセキュアなクロック機構を有する場合について説明する。

判断の結果、ＬＴデータベース４１３Ａに対象のＬＴが格納されている場合（Ｓ５１でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、対象のＬＴを書き出しできるか否かを判定する書き出し可否判断プロセス（Ｓ５４）を実行する。

これに対して、ＬＴデータベース４１３Ａに対象のＬＴがない場合には（Ｓ５１でＮＯ）、プラグイン制御部４１９Ａは、ＬＴ取得部４１５Ａに指示し、上記と同じ内容のＬＴ取得プロセス（Ｓ５２）を実行させ、ＬＴを取得できたか否か判断する（Ｓ５３）。そして、ＬＴデータベース４１３ＡにＬＴがあった場合（Ｓ５１でＹＥＳ）、あるいはＬＴを取得できた場合（Ｓ５３でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、書き出し可否判断プロセス（Ｓ５４）を実行する。

書き出し可否判断プロセス（Ｓ５４）の実行が終わると、プラグイン制御部４１９Ａは、コンテンツ利用可否判定部４１８Ａによる可否判断プロセスの結果に基づいて、そのＬＴで書き出し可か否か判断する（Ｓ５５）。判断の結果、書き出し可の場合（Ｓ５５でＹＥＳ）、プラグイン制御部４１９Ａは、対象のＬＴをストレージプラグイン４３へ渡す（Ｓ５６）。

これに対して、ＬＴを取得できなかった場合（Ｓ５３でＮＯ）や、書き出し不可と判断した場合（Ｓ５５でＮＯ）、プラグイン制御部４１９Ａは、コンテンツ書き出し処理を終了する。

一方、ストレージプラグイン４３の書き出し条件判定部４３１Ａは、ＬＴを受信すると（Ｓ６１）、Ｐ条件判断プロセス（ストレージ）を実行し（Ｓ６２）、実行の結果に基づいて書き出し可か否か判断する（Ｓ６３）。判断の結果、書き出し可能であれば（Ｓ６３でＹＥＳ）、書き込み用データ生成部４３２Ａは、コンテンツデータベース４１２Ａからコンテンツを取得し（Ｓ６４）、取得したコンテンツをメディア用コンテンツフォーマットに変換する（Ｓ６５）。次いで、書き込み用データ生成部４３２Ａは、ＬＴに含まれる利用権利をメディア用利用権利フォーマットに変換する（Ｓ６６）。そして、フォーマット変換が終わると、書き込み用データ生成部４３２Ａは、フォーマット変換されたコンテンツと利用権利とをＰ条件で指定された条件で外部メディアに書き込む（Ｓ６７）。これに対して、書き出し可でなければ（Ｓ６３でＮＯ）、その旨をプラグイン制御部４１９Ａに通知する。

ストレージプラグイン４３による書き込み処理が終わると、ＬＴ管理・更新部４１７Ａは、ＬＴを削除し（Ｓ５７）、書き出し処理を終了する。また、ストレージプラグイン４３で書き出し不可である場合（Ｓ６３でＮＯ）、プラグイン制御部４１９Ａは、コンテンツ書き出し処理を終了する。

図５０は、図４９に示される書き出し可否判定プロセス（Ｓ５４）のサブルーチンを示すフローチャートである。

この再生可否判定プロセスのサブルーチンにおいては、コンテンツ利用可否判定部４１８Ａは、先ず、ＬＴが有効期間内か否か判断する（Ｓ５４１）。有効期間内である場合（Ｓ５４１でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、ユーザが指定したＬＴのＬＴ移動許可フラグがＯＮか否か判断する（Ｓ５４２）。判断の結果、ＬＴ移動許可フラグがＯＮである場合（Ｓ５４２でＹＥＳ）、コンテンツ利用可否判定部４１８Ａは、書き出し可と判定し（Ｓ５４３）、この再生可否判定プロセスを終了し、図４９に示されるメインルーチンにリターンする。

これに対して、有効期間内でない場合（Ｓ５４１でＮＯ）や、ＬＴ移動許可フラグがＯＮでない場合（Ｓ５４２でＮＯ）、コンテンツ利用可否判定部４１８Ａは、書き出し不可と判定し（Ｓ５４４）、この再生可否判定プロセスを終了し、図４９に示されるメインルーチンにリターンする。

これにより、適切な書き出し可否を判定することができる。
図５１は、図４９に示されるＰ条件判定プロセス（ストレージ）（Ｓ６２）のサブルーチンを示すフローチャートである。

このＰ条件判定プロセスのサブルーチンでは、書き出し条件判定部４３１Ａは、先ず、Ｐ条件（例えば、ＳＤカードに書き出そうとしている場合、ＳＤカード用のＰ条件がある。）を参照し、書き出そうとしているメディアに対するＰ条件があるかを判定する（Ｓ６２１）。Ｐ条件がある場合（Ｓ６２２でＹＥＳ）、書き出し条件判定部４３１Ａは、Ｐ条件（例えば、プロテクトされたデジタル出力）で指定された出力インタフェースあるか否か判断する（Ｓ６２３）。判断の結果、指定された出力インタフェースがある場合（Ｓ６２３でＹＥＳ）、書き出し条件判定部４３１Ａは、ＬＴに含まれる利用権利がメディア用の利用権利に変換できるか否か判断する（Ｓ６２４）。例えば、外部メディアでは∞しかサポートしていないような場合に、ＬＴ内の権利が有限回である場合、それは書き出し不可と判断される。利用権を変換できる場合（Ｓ６２４でＹＥＳ）、書き出し条件判定部４３１Ａは、コンテンツを、メディア用のコンテンツフォーマットに変換できるか否か判断する（Ｓ６２５）。

コンテンツをフォーマット変換できる場合（Ｓ６２５でＹＥＳ）、書き出し条件判定部４３１Ａは、書き出し可と判定し（Ｓ６２６）、このＰ条件判定プロセスを終了し、図４９に示されるメインルーチンにリターンする。これに対して、Ｐ条件がない場合（Ｓ６２２でＮＯ）や、Ｐ条件で指定された出力インタフェースがない場合（Ｓ６２３でＮＯ）、利用条件をメディア用の利用権利に変換できない場合（Ｓ６２４でＮＯ）、コンテンツをメディア用のコンテンツフォーマットに変換できない場合（Ｓ６２５でＮＯ）、書き出し条件判定部４３１Ａは、書き出し不可と判定し（Ｓ６２７）、このＰ条件判定プロセスを終了し、図４９に示されるメインルーチンにリターンする。

このような図４９〜図５１の処理により、適切なコンテンツ書き出し処理を行うことができる。

なお、この実施の形態４では、ＬＴ発行要求７０において、クライアント能力を知らせるようにしたが、この変形例として、ユーザ端末の購入時などの際にユーザ情報データベースにクライアント能力を予め登録しておいて、ＬＴ発行要求があった場合にユーザ情報データベースに予め登録されたクライアント能力を用いてＬＴ即時消費フラグを設定してもよい。

また、サーバとのアクセス時にＳＡＣを形成し、このＳＡＣ形成の際にユーザ端末の端末ＩＤとクライアント能力等とを記載した証明書をサーバに送信し、ＬＴ発行要求があった場合に証明書に記載されたクライアント能力を用いてＬＴ即時消費フラグを設定してもよい。

さらに、この実施の形態４では、コンテンツはコンテンツ配信サーバから配信を行ったが、利用条件管理サーバから行ってもよい。つまり、コンテンツ配信サーバと利用条件管理サーバは同一であってもよい。

実施の形態１のデジタルコンテンツ配信システムの構成を示すブロック図である。 図２（ａ）及び（ｂ）は実施の形態１のデジタルコンテンツ配信システムのコンテンツ購入時の処理を示すフローチャートである。 図３（ａ）及び（ｂ）は実施の形態１のデジタルコンテンツ配信システムのコンテンツ情報取得時の処理を示すフローチャートである。 図４（ａ）及び（ｂ）は実施の形態１のデジタルコンテンツ配信システムのライセンス情報生成時の処理を示すフローチャートである。 実施の形態１のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 図６（ａ）及び（ｂ）は実施の形態１のデジタルコンテンツ配信システムのコンテンツ再生時の処理を示すフローチャートである。 実施の形態１のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 実施の形態１のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 実施の形態２のデジタルコンテンツ配信システムの構成を示すブロック図である。 図１０（ａ）及び（ｂ）は実施の形態２のデジタルコンテンツ配信システムのコンテンツ購入時の処理を示すフローチャートである。 図１１（ａ）及び（ｂ）は実施の形態２のデジタルコンテンツ配信システムのコンテンツ情報取得時の処理を示すフローチャートである。 図１２（ａ）及び（ｂ）は実施の形態２のデジタルコンテンツ配信システムのライセンス情報生成時の処理を示すフローチャートである。 実施の形態２のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 図１４（ａ）及び（ｂ）は実施の形態２のデジタルコンテンツ配信システムのコンテンツ再生時の処理を示すフローチャートである。 実施の形態２のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 実施の形態３のデジタルコンテンツ配信システムの構成を示すブロック図である。 図１７（ａ）及び（ｂ）は実施の形態３のデジタルコンテンツ配信システムのコンテンツ購入時の処理を示すフローチャートである。 図１８（ａ）及び（ｂ）は実施の形態３のデジタルコンテンツ配信システムのコンテンツ情報取得時の処理を示すフローチャートである。 図１９（ａ）及び（ｂ）は実施の形態３のデジタルコンテンツ配信システムのライセンス情報生成時の処理を示すフローチャートである。 実施の形態３のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 図２１（ａ）及び（ｂ）は実施の形態３のデジタルコンテンツ配信システムのコンテンツ再生時の処理を示すフローチャートである。 実施の形態３のデジタルコンテンツ配信システムでの、ライセンス情報生成ルールの一例を示す図である。 本実施の形態４に係るコンテンツ利用管理システムの全体の構成を示す図である。 図２３に示されるコンテンツ配信サーバ２及び利用条件管理サーバ３の構成を示す機能ブロック図である。 図２３に示されるユーザ端末４の構成を示す機能ブロック図である。 図２４に示されるコンテンツのデータフォーマットの構成例を示す図である。 、図２４に示されるユーザ情報データベース３１が保持するユーザ情報テーブルの構成例を示す図である。 図２４に示される利用権利データベースが保持する利用権利管理テーブルの構成例を示す図である。 図２８に示されるＵＲ−Ｕｓ６０Ｂの詳細な構成例を示す図である。 ＬＴ発行要求のデータフォーマット構成例を示す図である。 ＬＴのデータフォーマット構成例を示す図である。 回数カウンタの１回と、最長利用時間、１回判定しきい値、累積利用時間との関係を示す図である。 図３に示されるモニタに表示される画面の構成例を示す図である。 サーバにある権利内容を取得する場合に、用いられるＧｅｔＵＲ−Ｕｓの構成を示す図である。 ＧｅｔＰ条件テキストの構成例を示す図である。 上記ＧｅｔＰ条件テキストにより取得されるＰ条件の表示用情報の構成例である。 Ｇｅｔメタデータの構成例を示す図である。 図３８（ａ）及び（ｂ）はＬＴ取得プロセスの動作を示すフローチャートである。 ＥＬＩ生成プロセスのサブルーチンを示すフローチャートである。 ＬＴ発行可否判定プロセスのサブルーチンを示すフローチャートである。 ＬＴ生成プロセスのサブルーチンを示すフローチャートである。 ＬＴ即時消費フラグ設定プロセスのサブルーチンを示すフローチャートである。 ＬＴ自動返却フラグ設定プロセスのサブルーチンを示すフローチャートである。 アクションタグブロック設定プロセスのサブルーチンを示すフローチャートである。 図４５（ａ）及び（ｂ）はコンテンツ再生プロセスを示すフローチャートである。 ＬＴを返却するためのＬＴ返却要求の構成例を示す図である。 再生可否判定プロセスのサブルーチンを示すフローチャートである。 Ｐ条件判定プロセス（レンダリング）のサブルーチンを示すフローチャートである。 図４９（ａ）及び（ｂ）はコンテンツ書き出し処理を示すフローチャートである。 書き出し可否判定プロセスのサブルーチンを示すフローチャートである。 Ｐ条件判定プロセス（ストレージ）のサブルーチンを示すフローチャートである。 従来のデジタルコンテンツ配信システムの構成を示すブロック図である。 図５３（ａ）及び（ｂ）は従来のデジタルコンテンツ配信システムのコンテンツ購入時の処理を示すフローチャートである。 図５４（ａ）及び（ｂ）は従来のデジタルコンテンツ配信システムのコンテンツ再生時の処理を示すフローチャートである。

符号の説明

１ コンテンツ利用管理システム
２ コンテンツ配信サーバ
３ 利用条件管理サーバ
４，４ａ、…、４ｎ ユーザ端末
５ 通信ネットワーク
２１，４１２Ａ，４１９，１２１９，１９１９ コンテンツデータベース
２２，３８，４１０Ａ，４２２，４３１，１２２２，１２３１，１９２２，１９３１ 通信部
３１ ユーザ情報データベース
３２ 利用権利データベース
３３ コンテンツ鍵データベース
３４ ユーザ特定部
３５ ＬＴ生成部
３６ ＬＴ解析部
３７ 利用権利更新部
４１ クライアント
４２ レンダリングプラグイン
４３ ストレージプラグイン
４４，４５０，１２５０，１９５０ 外部メディア
６０Ｂ ＵＲ−Ｕｓ
６１ ＵＲ−Ｕｓヘッダ
６２＃１〜６２＃ｎ アクション情報
７０ ＬＴ発行要求
７３ ＥＬＩ
８０ ＬＴ
４１０，１２１０，１９１０ 配信サーバ
４１１，１２１１，１９１１ ユーザ管理データベース
４１２，１２１２，１９１２ ユーザ認証部
４１３，１２１３，１９１３ ユーザ権利情報データベース
４１３Ａ ＬＴデータベース
４１４，１２１４，１９１４ ユーザ権利処理部
４１４Ａ 端末ＩＤ蓄積部
４１５，１２１５，１９１５ ライセンス情報生成部
４１５Ａ ＬＴ取得部
４１６Ａ ＬＴ返却部
４１７，１２１７，１９１７ コンテンツ情報生成部
４１７Ａ ＬＴ管理・更新部
４１８Ａ コンテンツ利用可否判定部
４１９Ａ プラグイン制御部
４２０，１２２０，１９２０ コンテンツ取得部
４２１，１２２１，１９２１ コンテンツ暗号化部
４２１Ａ 再生条件判定部
４２２Ａ，４３５，１２３５，１９３５ コンテンツ復号部
４２３Ａ コンテンツ再生部
４３０，１２３０，１９３０ ユーザ端末
４３１Ａ 書き出し条件判定部
４３２，１２３２，１９３２ ＩＤ情報蓄積部
４３２Ａ 書き込み用データ生成部
４３３，１２３３，１９３３ 蓄積部
４３３Ａ メディアアクセス部
４３４，１２３４，１９３４ 外部メディアアクセス部
４３６，１２３６，１９３６ ライセンス情報処理部
４３７，１２３７，１９３７ コンテンツ情報復号部
４３８，１２３８，１９３８ コンテンツ情報データベース
４３９ 端末能力情報蓄積部
６１５，８１８ 移動許可フラグ
６１６ 同時利用可能数
６１７ 発行状態ＬＴ数
６２２，７４１ アクションＩＤ
６２４，８２３ １回判定しきい値・回数カウンタ／累積利用時間
７３６ クライアント能力フラグ
７３７ ＬＴ発行拒否フラグ
７４２ 期待回数／期待累積利用時間
８１５ ＬＴ状態フラグ（ＬＴ即時消費フラグ／ＬＴ自動返却フラグ）
８２１ アクションＩＤ

Claims (6)

1. サーバ装置と、前記サーバ装置からライセンス情報を取得し、取得した前記ライセンス情報に従ってコンテンツの利用制御を行う端末装置とから構成されるコンテンツ利用管理システムであって、
   前記端末装置は、前記サーバ装置に対し前記ライセンス情報の送信を要求し、前記ライセンス情報を取得するライセンス情報取得手段と、
   前記ライセンス取得手段が取得した前記ライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御するコンテンツ利用制御手段を有し、
   前記サーバ装置は、コンテンツに対する利用権利を管理する利用権利管理手段と、
   前記端末装置からの前記ライセンス情報の送信要求に応じて、前記ライセンス情報を生成するライセンス情報生成手段と、
   前記ライセンス情報生成手段が生成したライセンス情報を、前記ライセンス情報の送信を要求している端末装置に送信するライセンス情報送信手段を有し、
   前記ライセンス情報取得手段は、前記サーバ装置に対し、前記ライセンス情報の送信を要求する以前、または、前記ライセンス情報の送信を要求する際、前記端末装置の利用環境および利用形態に応じて変化する端末能力情報を送信し、
   前記ライセンス情報生成手段は、前記利用権利管理手段が管理する利用権利と、前記端末装置から送信される前記端末能力情報とに基づいてライセンス情報を生成し、
   前記端末能力情報は、前記端末装置と前記サーバ装置との接続頻度を示す情報を含み、
   前記ライセンス情報生成手段は、前記端末能力情報に含まれる、前記サーバ装置と接続頻度に応じたライセンス情報を生成し、
   前記コンテンツ利用制御手段は、前記サーバ装置との接続頻度に応じて生成されたライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御する
   ことを特徴とするコンテンツ利用管理システム。
2. 前記ライセンス情報生成手段は、前記端末能力情報が、前記サーバ装置と常時接続でないことを示す場合、前記コンテンツの利用回数を指定するライセンス情報を生成し、
   前記コンテンツ利用制御手段は、前記ライセンス情報取得手段が取得したライセンス情報に含まれる利用回数に応じたコンテンツの利用を行うよう制御する
   ことを特徴とする請求項１記載のコンテンツ利用管理システム。
3. 端末装置からのライセンス情報送信要求に応じて、ライセンス情報を生成送信するサーバ装置であって、
   前記ライセンス情報送信要求は、前記端末装置の利用環境および利用形態に応じて変化する端末能力情報を含み、
   前記サーバ装置は、コンテンツに対する利用権利を管理する利用権利管理手段と、
   前記ライセンス情報を生成するライセンス情報生成手段と、
   前記ライセンス情報生成手段が生成したライセンス情報を、前記ライセンス情報の送信を要求している端末装置に送信するライセンス情報送信手段を有し、
   前記ライセンス情報生成手段は、前記利用権利管理手段が管理する利用権利と、前記端末装置から送信される前記端末能力情報とに基づいてライセンス情報を生成し、
   前記端末能力情報は、前記端末装置と前記サーバ装置との接続頻度を示す情報を含み、
   前記ライセンス情報生成手段は、前記端末能力情報に含まれる、前記サーバ装置と接続頻度に応じたライセンス情報を生成する
   ことを特徴とするサーバ装置。
4. 前記ライセンス情報生成手段は、前記端末能力情報が、前記サーバ装置と常時接続でないことを示す場合、前記コンテンツの利用回数を指定するライセンス情報を生成する
   ことを特徴とする請求項３記載のサーバ装置。
5. サーバ装置と、前記サーバ装置からライセンス情報を取得し、取得した前記ライセンス情報に従ってコンテンツの利用制御を行う端末装置とから構成されるシステムによるコンテンツ利用管理方法であって、
   前記端末装置が、前記サーバ装置に対し前記ライセンス情報の送信を要求し、前記ライセンス情報を取得するライセンス情報取得ステップと、
   前記端末装置が、前記ライセンス取得ステップで取得した前記ライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御するコンテンツ利用制御ステップと、
   前記サーバ装置が、コンテンツに対する利用権利を管理する利用権利管理ステップと、
   前記サーバ装置が、前記端末装置からの前記ライセンス情報の送信要求に応じて、前記ライセンス情報を生成するライセンス情報生成ステップと、
   前記サーバ装置が、前記ライセンス情報生成ステップで生成したライセンス情報を、前記ライセンス情報の送信を要求している端末装置に送信するライセンス情報送信ステップとを含み、
   前記ライセンス情報取得ステップでは、前記サーバ装置に対し、前記ライセンス情報の送信を要求する以前、または、前記ライセンス情報の送信を要求する際、前記端末装置の利用環境および利用形態に応じて変化する端末能力情報を送信し、
   前記ライセンス情報生成ステップでは、前記利用権利管理ステップが管理する利用権利と、前記端末装置から送信される前記端末能力情報とに基づいてライセンス情報を生成し、
   前記端末能力情報は、前記端末装置と前記サーバ装置との接続頻度を示す情報を含み、
   前記ライセンス情報生成ステップは、前記端末能力情報に含まれる、前記サーバ装置と接続頻度に応じたライセンス情報を生成し、
   前記コンテンツ利用制御ステップでは、前記サーバ装置との接続頻度に応じて生成されたライセンス情報に基づいて、コンテンツの利用可否判定および利用を制御する
   ことを特徴とするコンテンツ利用管理方法。
6. 端末装置からのライセンス情報送信要求に応じて、サーバ装置がライセンス情報を生成送信するライセンス情報送信方法であって、
   前記ライセンス情報送信要求は、前記端末装置の利用環境および利用形態に応じて変化する端末能力情報を含み、
   コンテンツに対する利用権利を管理する利用権利管理ステップと、
   前記ライセンス情報を生成するライセンス情報生成ステップと、
   前記ライセンス情報生成ステップで生成したライセンス情報を、前記ライセンス情報の送信を要求している端末装置に送信するライセンス情報送信ステップとを含み、
   前記ライセンス情報生成ステップでは、前記利用権利管理ステップで管理する利用権利と、前記端末装置から送信される前記端末能力情報とに基づいてライセンス情報を生成し、
   前記端末能力情報は、前記端末装置と前記サーバ装置との接続頻度を示す情報を含み、
   前記ライセンス情報生成ステップでは、前記端末能力情報に含まれる、前記サーバ装置と接続頻度に応じたライセンス情報を生成する
   ことを特徴とするライセンス情報送信方法。

Images