以下、本発明の実施の形態のデジタルコンテンツ配信システムについて、説明する。
(実施の形態1)
本発明の実施の形態1におけるデジタルコンテンツ配信システムは、図1に示すように、配信サーバ410とユーザ端末430とからなり、配信サーバ410は、会員登録したユーザのID情報などを蓄積するユーザ管理データベース411と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース413と、コンテンツの関連情報(コンテンツ鍵など)を蓄積するコンテンツ情報データベース416と、コンテンツを蓄積するコンテンツデータベース419と、ユーザ認証を行うユーザ認証部412と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部414と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部415と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部417と、コンテンツ情報を暗号化するコンテンツ情報暗号化部418と、コンテンツデータベース419から指定されたコンテンツを取得するコンテンツ取得部420と、コンテンツを暗号化するコンテンツ暗号化部421と、ユーザ端末430との通信を行う通信部422とを備えている。
一方、ユーザ端末430は、配信サーバ410との間で通信を行う通信部431と、ID情報を蓄積するID情報蓄積部432と、ユーザ端末の能力を示す端末能力情報を蓄積する端末能力情報蓄積部439と、暗号化されたコンテンツを蓄積する蓄積部433と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース438と、コンテンツ情報データベース438からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部437と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部436と、ライセンス情報処理部436から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部435と、半導体メモリカードなどの外部メディア450にコンテンツを出力する外部メディアアクセス部434とを備えている。
このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ410で管理される。ユーザが購入(あるいは事前契約)したコンテンツは、暗号化された状態でユーザ端末430の蓄積部433に蓄積され、このコンテンツを利用する場合には、ユーザ端末430から配信サーバ410にリクエストが出される。配信サーバ410は、ユーザがリクエストしたコンテンツに対する利用条件(あるいは契約条件、以下「UR−Us」とも記す。)を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報(ライセンス情報(以下、「UR−Uc」とも記す。)とコンテンツ鍵とを含む情報(以下、「LT」とも記す。))を配信する。
ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末430は、このライセンス情報に基づいてコンテンツの利用を制御する。
図2は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末430が配信サーバ410からコンテンツを購入するときの処理フローを示している。
ユーザからのコンテンツ購入要求があると、配信サーバ410及びユーザ端末430は以下の処理を行う。
S501:ユーザ端末430の通信部431は、ID情報蓄積部432に蓄積されたユーザ端末430のIDを取得し、このID情報とコンテンツの購入要求とを配信サーバ410に送信する。
S502:この情報を配信サーバ410の通信部422を通じて受信したユーザ認証部412は、受信したID情報をユーザ管理データベース411に蓄積されているID情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部414に渡す。
S503:ユーザ権利処理部414は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース413に、購入コンテンツに対するユーザの権利情報(UR−Us)を登録する。
S504:コンテンツ情報生成部417は、コンテンツ情報データベース416から該当コンテンツの関連情報(コンテンツ鍵など)を取得してコンテンツ取得部420に渡す。
S505:コンテンツ取得部420は、コンテンツデータベース419から該当コンテンツを取得し、コンテンツ暗号化部421は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ410の通信部422は、暗号化されたコンテンツをユーザ端末430に送信する。
S506:ユーザ端末430の通信部431は、暗号化されたコンテンツを受信すると、
S507:コンテンツを蓄積部433に送って蓄積する。
次に、図3を用いて本実施の形態のデジタルコンテンツ配信システムにおけるユーザ端末430が、コンテンツを再生するためにコンテンツ情報を取得する場合の処理(コンテンツ情報取得プロセス)について説明する。
ユーザからコンテンツ再生のためのコンテンツ情報の取得要求があると、配信サーバ410及びユーザ端末430は以下の処理を行う。
S601:ユーザ端末430の通信部431は、ID情報蓄積部432に蓄積されたユーザ端末430のID情報と、端末能力情報蓄積部439に蓄積された端末能力情報とを取得し、これらの情報とコンテンツ情報取得要求(以下、「LT発行要求」とも記す。)とを配信サーバ410に送信する。
なお、本実施の形態において、端末能力情報とは、ユーザ端末430が、どのようなライセンス情報を処理可能かということを表すものであり、より具体的には、ライセンス情報に記述される再生可能回数の値について、どのような値ならば処理可能かを示す情報であるとする。例えば、『再生可能回数が1回と記述されたライセンス情報のみ処理可能』という情報である。
S602:ID情報を配信サーバ410の通信部422を通じて受信したユーザ認証部412は、受信した情報をユーザ管理データベース411に蓄積されているID情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求とをユーザ権利処理部414に渡す。また、配信サーバ410の通信部422は、受信した端末能力情報をライセンス情報生成部415に渡す。
S603:ユーザ権利処理部414は、S602で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース413を参照して確認する。
S604:S603で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部414は、その再生権利の内容をライセンス情報生成部415に伝える。ここで、再生権利の内容は、再生可能回数が何回かを表す情報であり、例えば、『N回再生可能である』といった情報である。その後、
S605:後述するライセンス情報生成プロセスが実行される。
S606:コンテンツ情報生成部417は、コンテンツ情報データベース416から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報(LT)を生成する。コンテンツ情報暗号化部418は、このコンテンツ情報を暗号化する。
S607:配信サーバ410の通信部422は、暗号化されたコンテンツ情報をユーザ端末430に送信する。
なお、S604において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ410からユーザ端末430に送信される(S608)。
一方、ユーザ端末430では、
S609:ユーザ端末430の通信部431は、コンテンツ情報を受信すると、
S610:コンテンツ情報をコンテンツ情報データベース438に送って蓄積する。
図4は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ410がライセンス情報(UR−Uc/LT)を生成する際(ライセンス情報生成プロセス)の処理フローを示している。
ライセンス情報の生成要求があると、配信サーバ410は以下の処理を行う。
S701:ライセンス情報生成部415は、S602で受信した端末能力情報とS604で受信した再生権利の内容をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール(図5にその一例を示す。)に従って、ライセンス情報を生成し、コンテンツ情報生成部417に渡す。
図5に示すルールは、再生権利の内容と端末能力情報の内容とから、生成するライセンス情報の内容を決定するものである。
S702:ユーザ権利処理部414は、ユーザ権利情報データベース413に格納されている権利情報内の再生権利の内容を更新(S701で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント)する。
なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。
ここで、図5のライセンス情報生成ルールについて詳しく説明する。
図5に示す通り、端末能力情報として、『再生可能回数1回と記述されたライセンス情報のみ処理可能』、『再生可能回数1回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』、『再生可能回数N回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報』の3つが定義されているものとする。
例えば、S604で受信した再生権利の内容が、『∞回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数1回と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数1回と記述されたライセンス情報が生成されることを意味する。また、S604で受信した再生権利の内容が、『∞回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数1回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数∞と記述されたライセンス情報が生成されることを意味する。さらに、S604で受信した再生権利の内容が、『∞回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数N回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数∞と記述されたライセンス情報が生成されることを意味する。なお、Nは2以上の有限な整数値とする。
次に、例えば、S604で受信した再生権利の内容が、『複数回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数1回と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数1回と記述されたライセンス情報が生成されることを意味する。また、S604で受信した再生権利の内容が、『複数回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数1回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数1回と記述されたライセンス情報が生成されることを意味する。さらに、S604で受信した再生権利の内容が、『複数回再生可能』という内容で、S602で受信した端末能力情報が、『再生可能回数N回と記述されたライセンス情報及び再生可能回数∞と記述されたライセンス情報のみ処理可能』という情報である場合、再生可能回数N回と記述されたライセンス情報が生成されることを意味する。なお、Nは2以上の有限な整数値とする。
また、例えば、S604で受信した再生権利の内容が、『1回再生可能』という内容に対しては、図5に示す例では、再生可能回数1回と記述されたライセンス情報が生成されることを表している。
図6は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末430がコンテンツを再生するときの処理フローを示している。
ユーザからのコンテンツ要求があると、ユーザ端末430は以下の処理を行う。
S901:コンテンツ情報復号部437は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース438に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、S902、S903の処理は行わず、S904に進む。
S902:S901でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。
S903:コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
S904:コンテンツ情報復号部437は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部436に渡す。
S905:ライセンス情報処理部436は、ライセンス情報に記述された再生条件をチェックし、
S906:再生可能回数が1以上の場合には、
S907:蓄積部433からコンテンツを取得して、
S908:コンテンツ鍵でコンテンツを復号して再生を行う。
S909〜S911:コンテンツの再生後、コンテンツ情報データベース438に蓄積されているコンテンツ情報の更新を行う。
ここで、再生前の再生可能回数が2以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を1デクリメントする。また、再生前の再生可能回数が1であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。
再生前の再生可能回数が無限大であった場合には、更新は行われない。
また、S903で配信サーバ410からコンテンツ情報を取得できなかった場合、及び、S906で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。
なお、本実施の形態では、コンテンツの『利用』の一形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば外部メディア450への複製や、印刷など、その他いかなる動作であってもよいものとする。
また、本実施の形態において、端末能力情報は、ライセンス情報に記述される再生可能回数の値について、どのような値ならば処理可能かを示す情報であるとして説明を行ったが、それに限るものではなく、例えば、再生有効期限などの時間的な管理が行えるかどうか、配信サーバへの接続頻度はどれくらいか、配信サーバへの接続コストはどれくらいかといった情報であってもよいものとする。
また、ライセンス情報生成ルールも、端末能力情報の内容に応じて変化するものとし、例えば、端末能力情報が配信サーバへの接続頻度を示す情報である場合には、図7に示すようなルール(例)となり、また、端末能力情報が配信サーバへの接続コストを示す情報である場合には、図8に示すようなルール(例)となる。
ここで、図7に示す接続頻度に関するライセンス情報生成ルールについて説明する。
図7に示す通り、接続頻度として、『常時接続』、『1回/Day』、『1回/Week』の3つが定義されているものとする。図7において、再生権利の内容が『∞再生可能』であり、接続頻度が『常時接続』であるときには、『再生可能回数1回』と記述されたライセンス情報を生成する。即ち、再生の度にライセンス情報を発行することを意味する。また、再生権利の内容が『∞再生可能』であり、接続頻度が『1回/Day』、つまり1日に1回程度接続するときには、『再生可能回数N回』と記述されたライセンス情報を発行することを意味する。なお、Nは2以上の有限な整数とする。さらに、再生権利の内容が『∞再生可能』であり、接続頻度が『1回/Week』、つまり1週間に1回程度接続するときには、『再生可能回数∞』と記述されたライセンス情報を発行することを意味する。
また、図7において、再生権利の内容が『複数回再生可能』であり、接続頻度が『常時接続』であるときには、『再生可能回数1回』と記述されたライセンス情報を生成する。即ち、再生の度にライセンス情報を発行することを意味する。また、再生権利の内容が『複数回再生可能』であり、接続頻度が『1回/Day』、つまり1日に1回程度接続するときには、『再生可能回数1回』と記述されたライセンス情報を発行することを意味する。さらに、再生権利の内容が『複数回再生可能』であり、接続頻度が『1回/Week』、つまり1週間に1回程度接続するときには、『再生可能回数N回』と記述されたライセンス情報を発行することを意味する。なお、Nは2以上の有限な整数とする。
さらに、図7において、再生権利の内容が『複数回再生可能』であるときには、いずれの接続頻度に対しても、『再生可能回数1回』と記述されたライセンス情報を発行することを意味する。このようにして、ユーザ端末430の接続頻度に応じて、ライセンス情報を柔軟に変更し、発行することが可能となる。
ここで、図8に示す接続コストに関するライセンス情報生成ルールについて説明する。
図8において、再生権利の内容が『∞再生可能』であり、接続コストが『〜xxx円』、即ちxxx円以下の場合、『再生可能回数1回』と記述されたライセンス情報を生成することを意味する。一方、再生権利の内容が『∞再生可能』であり、接続コストが『xxx円〜』即ちxxx円より大きい場合、『再生可能回数∞』と記述されたライセンス情報を生成することを意味する。なお、xxxは0以上の整数とする。
また、図8において、再生権利の内容が『複数回再生可能』であり、接続コストが『〜xxx円』、即ちxxx円以下の場合、『再生可能回数1回』と記述されたライセンス情報を生成することを意味する。一方、再生権利の内容が『複数回再生可能』であり、接続コストが『xxx円〜』即ちxxx円より大きい場合、『再生可能回数N回』と記述されたライセンス情報を生成することを意味する。なお、xxxは0以上の整数とし、Nは2以上の有限な整数とする。
さらに、図8において、再生権利の内容が『1回再生可能』である場合は、接続コストによらず、『再生可能回数1回』と記述されたライセンス情報を生成することを意味する。
このようにして、ユーザ端末430の接続コストに応じて、ライセンス情報を柔軟に変更し、発行することが可能となる。
以上のように、本実施の形態1のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、ユーザ端末の能力に応じた最適なライセンス情報を配信することが可能となる。
例えば、N回再生可能と記述された利用条件』からライセンス情報を生成し配信する場合、携帯電話のように、配信サーバに頻繁に接続することが可能で、且つ、端末内での処理を軽くしたいといった機器には、1回再生可と記述したライセンス情報を配信し、逆に、PCのように、配信サーバに頻繁に接続することは難しいが、端末内で複雑な処理が可能といった機器には、N回分の再生権利を記述したライセンス情報を配信するといったことが可能となる。
(実施の形態2)
本発明の実施の形態2におけるデジタルコンテンツ配信システムは、図9に示すように、配信サーバ1210とユーザ端末1230とからなり、配信サーバ1210は、会員登録したユーザのID情報などを蓄積するユーザ管理データベース1211と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース1213と、コンテンツの関連情報(コンテンツ鍵、コンテンツが属するサービス内容など)を蓄積するコンテンツ情報データベース1216と、コンテンツを蓄積するコンテンツデータベース1219と、ユーザ認証を行うユーザ認証部1212と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部1214と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部1215と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部1217と、コンテンツ情報を暗号化するコンテンツ情報暗号化部1218と、コンテンツデータベース1219から指定されたコンテンツを取得するコンテンツ取得部1220と、コンテンツを暗号化するコンテンツ暗号化部1221と、ユーザ端末1230との通信を行う通信部1222とを備えている。
一方、ユーザ端末1230は、配信サーバ1210との間で通信を行う通信部1231と、ID情報を蓄積するID情報蓄積部1232と、暗号化されたコンテンツを蓄積する蓄積部1233と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース1238と、コンテンツ情報データベース1238からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部1237と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部1236と、ライセンス情報処理部1236から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部1235と、外部メディア1250にコンテンツを出力する外部メディアアクセス部1234とを備えている。
このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ1210で管理される。ユーザが購入(あるいは事前契約)したコンテンツは、暗号化された状態でユーザ端末1230の蓄積部1233に蓄積され、このコンテンツを利用する場合には、ユーザ端末1230から配信サーバ1210にリクエストが出される。配信サーバ1210は、ユーザがリクエストしたコンテンツに対する利用条件』(あるいは契約条件)を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報(ライセンス情報とコンテンツ鍵とを含む情報)を配信する。ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末1230は、このライセンス情報に基づいてコンテンツの利用を制御する。
図10は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末1230が配信サーバ1210からコンテンツを購入するときの処理フローを示している。ユーザからのコンテンツ要求があると、配信サーバ1210及びユーザ端末1230は以下の処理を行う。
S1301:ユーザ端末1230の通信部1231は、ID情報蓄積部1232に蓄積されたユーザ端末1230のIDを取得し、このID情報とコンテンツの購入要求とを配信サーバ1210に送信する。
S1302:この情報を配信サーバ1210の通信部1222を通じて受信したユーザ認証部1212は、受信したID情報をユーザ管理データベース1211に蓄積されているID情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部1214に渡す。
S1303:ユーザ権利処理部1214は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース1213に、購入コンテンツに対するユーザの権利情報を登録する。
S1304:コンテンツ情報生成部1217は、コンテンツ情報データベース1216から該当コンテンツの関連情報(コンテンツ鍵など)を取得してコンテンツ取得部1220に渡す。
S1305:コンテンツ取得部1220は、コンテンツデータベース1219から該当コンテンツを取得し、コンテンツ暗号化部1221は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ1210の通信部1222は、暗号化されたコンテンツをユーザ端末1230に送信する。
S1306:ユーザ端末1230の通信部1231は、暗号化されたコンテンツを受信すると、
S1307:コンテンツを蓄積部1233に送って蓄積する。
次に、図11を用いて本実施の形態のデジタルコンテンツ配信システムにおいて、ユーザ端末1230が、コンテンツを再生するためにコンテンツ情報を取得する場合の処理(コンテンツ情報取得プロセス)について説明する。
ユーザからコンテンツ再生のためのコンテンツ情報の取得要求があると、
S1401:ユーザ端末1230の通信部1231は、ID情報蓄積部1232に蓄積されたユーザ端末1230のID情報を取得し、これらの情報とコンテンツ情報取得要求とを配信サーバ1210に送信する。
S1402:ID情報を配信サーバ1210の通信部1222を通じて受信したユーザ認証部1212は、受信した情報をユーザ管理データベース1211に蓄積されているID情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求とをユーザ権利処理部1214に渡す。
S1403:ユーザ権利処理部1214は、S1402で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース1213を参照して確認する。
S1404:S1403で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部1214は、その再生権利の内容をライセンス情報生成部1215に伝える。ここで、再生権利の内容は、再生可能回数が何回かを表す情報であり、例えば、『N回再生可能である』といった情報である。その後、
S1405:後述するライセンス情報生成プロセスが実行される。
S1406:コンテンツ情報生成部1217は、コンテンツ情報データベース1216から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報を生成する。コンテンツ情報暗号化部1218は、このコンテンツ情報を暗号化する。
S1407:配信サーバ1210の通信部1222は、暗号化されたコンテンツ情報をユーザ端末1230に送信する。
なお、S1404において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ1210からユーザ端末1230に送信される(S1408)。
一方、ユーザ端末1230では、
S1409:ユーザ端末1230の通信部1231は、コンテンツ情報(LT)を受信すると、
S1410:コンテンツ情報(LT)をコンテンツ情報データベース1238に送って蓄積する。
図12は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ1210がライセンス情報を生成する際(ライセンス情報生成プロセス)の処理フローを示している。ライセンス情報の生成要求があると、
S1501:ライセンス情報生成部1215は、コンテンツ情報取得要求のあったコンテンツが属するサービス内容に関する情報を、コンテンツ情報データベース1216から入手する。
本実施の形態では、サービス内容とは、例えば、音楽配信、映画配信などといったコンテンツの種類に関する情報であるとする。
S1502:ライセンス情報生成部1215は、S1404で受信した再生権利の内容とS1501で入手したサービス内容に関する情報をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール(図13にその一例を示す。)に従って、ライセンス情報を生成し、コンテンツ情報生成部1217に渡す。
S1503:ユーザ権利処理部1214は、ユーザ権利情報データベース1213に格納されている権利情報内の再生権利の内容を更新(S1502で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント)する。
なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。
ここで、図13に示すライセンス情報生成ルールについて説明する。
図13に示すルールは、再生権利の内容とサービスの内容に関する情報とから、生成するライセンス情報の内容を決定するものである。サービスの内容としては、『映画配信サービス』、『音楽配信サービス』の2つが定義されているものとする。
図13のライセンス情報生成ルールに従った場合、例えば、S1404で受信した再生権利の内容が、『∞回再生可能』という内容で、S1501で入手したサービスの内容に関する情報が、『映画配信サービス』という情報である場合、『再生可能回数1回』と記述されたライセンス情報が生成されることになる。
一方、S1404で受信した再生権利の内容が、『∞回再生可能』という内容で、S1501で入手したサービスの内容に関する情報が、『音楽配信サービス』という情報である場合、『再生可能回数∞』と記述されたライセンス情報が生成されることになる。
また、S1404で受信した再生権利の内容が、『複数回再生可能』という内容で、S1501で入手したサービスの内容に関する情報が、『映画配信サービス』という情報である場合、『再生可能回数1回』と記述されたライセンス情報が生成されることになる。
一方、S1404で受信した再生権利の内容が、『複数回再生可能』という内容で、S1501で入手したサービスの内容に関する情報が、『音楽配信サービス』という情報である場合、『再生可能回数N回』と記述されたライセンス情報が生成されることになる。なお、Nは2以上の有限な整数とする。
さらに、S1404で受信した再生権利の内容が、『1回再生可能』という内容の場合は、サービスの内容に関する情報がいずれの場合でも『再生可能回数1回』と記述されたライセンス情報が生成されることになる。
このように、サービス内容、即ちコンテンツの種類毎に柔軟にライセンス情報を生成することが可能となる。
図14は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末1230がコンテンツを再生するときの処理フローを示している。
ユーザからのコンテンツ要求があると、
S1701:コンテンツ情報復号部1237は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース1238に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、S1702、S1703の処理は行わず、S1704に進む。
S1702:S1701でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。
S1703:コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
S1704:コンテンツ情報復号部1237は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部1236に渡す。
S1705:ライセンス情報処理部1236は、ライセンス情報に記述された再生条件をチェックし、
S1706:再生可能回数が1以上の場合には、
S1707:蓄積部1233からコンテンツを取得して、
S1708:コンテンツ鍵でコンテンツを復号して再生を行う。
S1709〜S1711:コンテンツの再生後、コンテンツ情報データベース1238に蓄積されているコンテンツ情報の更新を行う。
ここで、再生前の再生可能回数が2以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を1デクリメントする。また、再生前の再生可能回数が1であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。再生前の再生可能回数が無限大であった場合には、更新は行われない。
また、S1703で配信サーバ1210からコンテンツ情報を取得できなかった場合、及び、S1706で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。
なお、本実施の形態では、コンテンツの『利用』の1形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば、外部メディア1250への複製や、印刷など、その他いかなる動作であってもよいものとする。
また、本実施の形態において、サービスの内容として、コンテンツの種類を例にして説明を行ったが、それに限るものではなく、例えば、新作や旧作などといったコンテンツのプレミア度などの情報であってもよいものとする。
また、ライセンス情報生成ルールも、上記サービスの内容が表す情報に応じて変化するものとし、例えば、サービスの内容がコンテンツのプレミア度を示す情報である場合には、図15に示すようなルール(例)となる。
図15において、コンテンツのプレミア度として、『新作』、『準新作』、『旧作』の3つが定義されている。再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『新作』である場合は、『再生可能回数1回』と記述されたライセンス情報を生成することを意味する。また、再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『準新作』である場合は、『再生可能回数N回』と記述されたライセンス情報を生成することを意味する。さらに、再生権利が『∞回再生可能』であり、コンテンツのプレミア度が『旧作』である場合は、『再生可能回数∞』と記述されたライセンス情報を生成することを意味する。なお、ここでNは2以上で有限の整数とする。
また、図15において、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『新作』である場合は、『再生可能回数1回』と記述されたライセンス情報を生成することを意味する。
また、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『準新作』である場合は、『再生可能回数N回』と記述されたライセンス情報を生成することを意味する。
さらに、再生権利が『複数回再生可能』であり、コンテンツのプレミア度が『旧作』である場合は、『再生可能回数N回』と記述されたライセンス情報を生成することを意味する。
さらに、図15において、再生権利が『1回再生可能』であるときは、コンテンツのプレミア度にかかわらず、『再生可能回数1回』と記述されたライセンス情報を生成することを意味している。
このように、本実施の形態2のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、サービス内容に応じた最適なライセンス情報を配信することが可能となる。例えば、N回再生可能と記述された利用条件からライセンス情報を生成し配信する場合、新作映画のように、コンテンツ価値の高いものに関しては、再生時には毎回、ユーザ端末が配信サーバと通信を行うように、1回再生可と記述したライセンス情報を配信し、逆に、旧作映画のように、コンテンツ価値が低いコンテンツに関しては、N回分(Nは2以上の有限な整数)の再生権利を記述したライセンス情報を配信するといったことが可能となる。
(実施の形態3)
本発明の実施の形態3におけるデジタルコンテンツ配信システムは、図16に示すように、配信サーバ1910とユーザ端末1930とからなり、配信サーバ1910は、会員登録したユーザのID情報や、ユーザがコンテンツ対価を支払う場合の支払い方法に関する情報などを蓄積するユーザ管理データベース1911と、コンテンツに対するユーザの権利情報を蓄積するユーザ権利情報データベース1913と、コンテンツの関連情報(コンテンツ鍵など)を蓄積するコンテンツ情報データベース1916と、コンテンツを蓄積するコンテンツデータベース1919と、ユーザ認証を行うユーザ認証部1912と、コンテンツに対するユーザの権利情報の登録や更新を行うユーザ権利処理部1914と、リクエストされたコンテンツのライセンス情報を生成するライセンス情報生成部1915と、ライセンス情報やコンテンツ鍵の情報を含むコンテンツ情報を生成するコンテンツ情報生成部1917と、コンテンツ情報を暗号化するコンテンツ情報暗号化部1918と、コンテンツデータベース1919から指定されたコンテンツを取得するコンテンツ取得部1920と、コンテンツを暗号化するコンテンツ暗号化部1921と、ユーザ端末1930との通信を行う通信部1922とを備えている。
一方、ユーザ端末1930は、配信サーバ1910との間で通信を行う通信部1931と、ID情報を蓄積するID情報蓄積部1932と、暗号化されたコンテンツを蓄積する蓄積部1933と、暗号化されたコンテンツ情報を蓄積するコンテンツ情報データベース1938と、コンテンツ情報データベース1938からコンテンツ情報を取得し、コンテンツ鍵とライセンス情報とを復号するコンテンツ情報復号部1937と、ライセンス情報に基づいてコンテンツ鍵の使用の可否を判定するライセンス情報処理部1936と、ライセンス情報処理部1936から取得したコンテンツ鍵でコンテンツを復号するコンテンツ復号部1935と、外部メディア1950にコンテンツを出力する外部メディアアクセス部1934とを備えている。
このシステムでは、各ユーザのコンテンツに対する権利情報が、基本的には配信サーバ1910で管理される。ユーザが購入(あるいは事前契約)したコンテンツは、暗号化された状態でユーザ端末1930の蓄積部1933に蓄積され、このコンテンツを利用する場合には、ユーザ端末1930から配信サーバ1910にリクエストが出される。
配信サーバ1910は、ユーザがリクエストしたコンテンツに対する利用条件(あるいは契約条件)を確認し、ユーザの利用権が存在するときは、ユーザに対してコンテンツ情報(ライセンス情報とコンテンツ鍵とを含む情報)(LT)を配信する。
ライセンス情報は、コンテンツの再生や、移動、複製などの利用に対する条件情報によって構成され、ユーザ端末1930は、このライセンス情報に基づいてコンテンツの利用を制御する。
図17は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末1930が配信サーバ1910からコンテンツを購入するときの処理フローを示している。
ユーザからのコンテンツ要求があると、
S2001:ユーザ端末1930の通信部1931は、ID情報蓄積部1932に蓄積されたユーザ端末1930のIDを取得し、このID情報とコンテンツの購入要求とを配信サーバ1910に送信する。
S2002:この情報を配信サーバ1910の通信部1922を通じて受信したユーザ認証部1912は、受信したID情報をユーザ管理データベース1911に蓄積されているID情報と照合してユーザ認証を行った後、コンテンツ購入要求をユーザ権利処理部1914に渡す。
S2003:ユーザ権利処理部1914は、コンテンツ購入の課金処理を行い、ユーザ権利情報データベース1913に、購入コンテンツに対するユーザの権利情報を登録する。
S2004:コンテンツ情報生成部1917は、コンテンツ情報データベース1916から該当コンテンツの関連情報(コンテンツ鍵など)を取得してコンテンツ取得部1920に渡す。
S2005:コンテンツ取得部1920は、コンテンツデータベース1919から該当コンテンツを取得し、コンテンツ暗号化部1921は、このコンテンツをコンテンツ鍵で暗号化する。配信サーバ1910の通信部1922は、暗号化されたコンテンツをユーザ端末1930に送信する。
S2006:ユーザ端末1930の通信部1931は、暗号化されたコンテンツを受信すると、
S2007:コンテンツを蓄積部1933に送って蓄積する。
次に、図18を用いて本実施の形態のデジタルコンテンツ配信システムにおいて、ユーザ端末1930が、コンテンツを再生するためにコンテンツ情報(LT)を取得する場合の処理(コンテンツ情報取得プロセス)について説明する。
ユーザからコンテンツ再生のためのコンテンツ情報の取得要求(LT発行要求/ELI)があると、
S2101:ユーザ端末1930の通信部1931は、ID情報蓄積部1932に蓄積されたユーザ端末1930のID情報を取得し、これらの情報とコンテンツ情報取得要求(LT発行要求/ELI)とを配信サーバ1910に送信する。
S2102:ID情報を配信サーバ1910の通信部1922を通じて受信したユーザ認証部1912は、受信した情報をユーザ管理データベース1911に蓄積されているID情報と照合してユーザ認証を行った後、ユーザ情報とコンテンツ情報取得要求(LT発行要求/ELI)とをユーザ権利処理部1914に渡す。
S2103:ユーザ権利処理部1914は、S2102で渡されたユーザ情報によって特定されるユーザの権利情報であって、且つ、コンテンツ情報取得要求のあったコンテンツに対する権利情報を、ユーザ権利情報データベース1913を参照して確認する。
S2104:S2103で確認した権利情報の中に、再生権利が含まれている場合、ユーザ権利処理部1914は、その再生権利の内容をライセンス情報生成部1915に伝える。
ここで、再生権利の内容は、例えば、『N回再生可能である』といった情報である。その後、
S2105:後述するライセンス情報生成プロセスが実行される。
S2106:コンテンツ情報生成部1917は、コンテンツ情報データベース1916から該当コンテンツのコンテンツ鍵を読み出し、このコンテンツ鍵とライセンス情報生成プロセスによって生成されたライセンス情報とを含むコンテンツ情報を生成する。コンテンツ情報暗号化部1918は、このコンテンツ情報を暗号化する。
S2107:配信サーバ1910の通信部1922は、暗号化されたコンテンツ情報をユーザ端末1930に送信する。
なお、S2104において、ユーザの権利情報の中に、該当コンテンツの再生権利が含まれていないときには、再生不可の通知が配信サーバ1910からユーザ端末1930に送信される(S2108)。
一方、ユーザ端末1930では、
S2109:ユーザ端末1930の通信部1931は、コンテンツ情報(LT)を受信すると、
S2110:コンテンツ情報(LT)をコンテンツ情報データベース1938に送って蓄積する。
図19は、本実施の形態のデジタルコンテンツ配信システムにおいて、配信サーバ1910がライセンス情報を生成する際(ライセンス情報生成プロセス)の処理フローを示している。ライセンス情報の生成要求があると、
S2201:ライセンス情報生成部1915は、コンテンツ情報をリクエストしているユーザの信頼度に関する情報を、ユーザ管理データベース1911から入手する。
本実施の形態では、信頼度に関する情報とは、例えば、クレジットカード、請求書現金払いなどといったコンテンツ対価に対する支払い方法に関する情報であるとする。
S2202:ライセンス情報生成部1915は、S2104で受信した再生権利の内容とS2201で入手したユーザの信頼度に関する情報をもとに、ライセンス情報の生成規則を記したライセンス情報生成ルール(図20にその一例を示す。)に従って、ライセンス情報を生成し、コンテンツ情報生成部1917に渡す。
S2203:ユーザ権利処理部1914は、ユーザ権利情報データベース1913に格納されている権利情報内の再生権利の内容を更新(S2202で生成されたライセンス情報に記述された再生可能回数の値分、再生権利に記述されている再生可能回数の値をデクリメント)する。
なお、再生権利中、再生可能回数が無限大となっている場合には、この更新は行われないものとする。
ここで、図20に示すライセンス情報生成ルールについて詳しく説明する。
図20に示すルールは、再生権利の内容とユーザの信頼度に関する情報とから、生成するライセンス情報の内容を決定するものであり、ユーザの信頼度として、『支払い方法:請求書現金払い』と、『支払い方法:クレジットカード』の2つを定義している。
図20のライセンス情報生成ルールに従った場合、例えば、S2104で受信した再生権利の内容が、『∞回再生可能』という内容で、S2201で入手したユーザの信頼度に関する情報が、『支払い方法:請求書現金払い』という情報である場合、『再生可能回数1回』と記述されたライセンス情報が生成されることになる。また、S2104で受信した再生権利の内容が、『∞回再生可能』という内容で、S2201で入手したユーザの信頼度に関する情報が、『支払い方法:クレジットカード』という情報である場合、『再生可能回数∞』と記述されたライセンス情報が生成されることになる。
また、図20のライセンス情報生成ルールに従った場合、例えば、S2104で受信した再生権利の内容が、『複数回再生可能』という内容で、S2201で入手したユーザの信頼度に関する情報が、『支払い方法:請求書現金払い』という情報である場合、『再生可能回数1回』と記述されたライセンス情報が生成されることになる。また、S2104で受信した再生権利の内容が、『複数回再生可能』という内容で、S2201で入手したユーザの信頼度に関する情報が、『支払い方法:クレジットカード』という情報である場合、『再生可能回数N回』と記述されたライセンス情報が生成されることになる。ここで、Nは2以上の有限な整数とする。
また、図20のライセンス情報生成ルールに従った場合、例えば、S2104で受信した再生権利の内容が、『1回再生可能』という内容に対しては、いずれのユーザ信頼度に対しても『再生可能回数1回』と記述されたライセンス情報が生成されることになる。このようにして、ライセンス情報生成ルールは、ユーザの信頼度に応じて柔軟に設定することも可能となる。
図21は、本実施の形態におけるデジタルコンテンツ配信システムにおいて、ユーザ端末1930がコンテンツを再生するときの処理フローを示している。
ユーザからのコンテンツ要求があると、
S2401:コンテンツ情報復号部1937は、再生を要求されているコンテンツに対応するコンテンツ情報が、コンテンツ情報データベース1938に存在するかどうかを調べる。コンテンツ情報が、存在する場合は、S2402、S2403の処理は行わず、S2404に進む。
S2402:S2401でコンテンツ情報が存在しない場合、前述のコンテンツ情報取得プロセスが実行される。
S2403:コンテンツ情報取得プロセスを実行した結果、コンテンツ情報を取得することができると、
S2404:コンテンツ情報復号部1937は、コンテンツ情報を復号して、ライセンス情報とコンテンツ鍵とを取り出し、これらをライセンス情報処理部1936に渡す。
S2405:ライセンス情報処理部1936は、ライセンス情報に記述された再生条件をチェックし、
S2406:再生可能回数が1以上の場合には、
S2407:蓄積部1933からコンテンツを取得して、
S2408:コンテンツ鍵でコンテンツを復号して再生を行う。
S2409〜S2411:コンテンツの再生後、コンテンツ情報データベース1938に蓄積されているコンテンツ情報の更新を行う。ここで、再生前の再生可能回数が2以上で有限であった場合には、コンテンツ情報内のライセンス情報に記述されている再生可能回数を1デクリメントする。また、再生前の再生可能回数が1であった場合には、コンテンツ情報を削除、もしくは無効化する処理を行う。再生前の再生可能回数が無限大であった場合には、更新は行われない。
また、S2403で配信サーバ1910からコンテンツ情報を取得できなかった場合、及び、S2406で再生不可と判定された場合には、コンテンツを再生することなく処理を終了する。
なお、本実施の形態では、コンテンツの『利用』の1形態として『再生』を例に説明を行ったが、利用とは、再生に限るものでなく、例えば、外部メディアへの複製や、印刷など、その他いかなる動作であってもよいものとする。
また、本実施の形態において、ユーザの信頼度に関する情報として、支払い方法を例にして説明を行ったが、それに限るものではなく、例えば、プラチナ会員、一般会員などといったユーザのステータスに関する情報などであってもよいものとする。ここで、ユーザのステータスとは、過去に購入したコンテンツの総計、支払い実績などによって決定されるものであるとする。
また、ライセンス情報生成ルールも、ユーザの信頼度に関する情報に応じて変化するものとし、例えば、ユーザの信頼度に関する情報がユーザのステータスを表す情報である場合には、図22に示すようなルール(例)となる。
図22に示す例では、ユーザのステータスをプラチナ、シルバー、一般の3つに分類しており、プラチナが最もステータスが高く、次いでシルバー、一般の順でステータスを定義している。
再生権利が『∞回再生可能』であるとき、『プラチナ会員』に対しては、『再生可能回数∞』と記述されたライセンス情報が発行されることを意味している。また、再生権利が『∞回再生可能』であるとき、『シルバー会員』に対しては、『再生可能回数N回』と記述されたライセンス情報が発行されることを意味している。さらに、再生権利が『∞回再生可能』であるとき、『一般会員』に対しては、『再生可能回数1回』と記述されたライセンス情報が発行されることを意味している。ここで、Nは2以上の有限な整数とする。
また、再生権利が『複数回再生可能』であるとき、『プラチナ会員』に対しては、『再生可能回数N回』と記述されたライセンス情報が発行されることを意味している。また、再生権利が『複数回再生可能』であるとき、『シルバー会員』に対しては、『再生可能回数1回』と記述されたライセンス情報が発行されることを意味している。さらに、再生権利が『複数回再生可能』であるとき、『一般会員』に対しては、『再生可能回数1回』と記述されたライセンス情報が発行されることを意味している。ここで、Nは2以上の有限な整数とする。
さらに、再生権利が『1回再生可能』であるときは、いずれのステータスのユーザに対しても、『再生可能回数1回』と記述されたライセンス情報が発行されることを意味している。このように、ユーザのステータスに応じて、ライセンス情報を柔軟に設定し、発行することが可能となる。
以上のように、本実施の形態3のデジタルコンテンツ配信システムにおいては、配信サーバは、ユーザ端末に対し、ユーザの信頼度に応じた最適なライセンス情報を配信することが可能となる。例えば、N回再生可能と記述された利用条件からライセンス情報を生成し配信する場合、信頼度の高いユーザには、N回分の再生権利を記述したライセンス情報を配信し、信頼度の低いユーザには、1回再生可と記述したライセンス情報を配信するといったことが可能となる。
(実施の形態4)
以下、本発明の実施の形態4について、図面を用いて詳細に説明する。
図23は、本実施の形態4に係るコンテンツ利用管理システム(NetDRMシステムとも記す。)1の全体の構成を示す図である。
このNetDRMシステム1は、音楽や、映画、書籍など、デジタル化されたコンテンツを配信したり、コンテンツを購入したユーザに対して付与されるコンテンツ毎の利用権利(ライセンス)を事業者側が主体となって動的に管理し、コンテンツを利用するためのライセンスチケット(以下、「LT」とも記す。)をユーザの要求(LT発行要求)に基づいて配信し、LTに含まれる利用条件(UR−Uc)の範囲内でコンテンツを利用できるようにすることで、コンテンツの著作権を保護するシステムであり、コンテンツ利用を管理したりする事業者が所有するコンテンツ配信サーバ2及び利用条件管理サーバ3と、このNetDRMシステム1に加入したユーザが所有するユーザ端末4a、…、4nと、これらを接続する通信ネットワーク5とから構成される。なお、ユーザ端末4a、…、4nなどの不特定なNetDRM端末の1台を指す場合には、ユーザ端末4と記す。
コンテンツ配信サーバ2は、ワークステーション等のコンピュータであり、コンテンツ配信サーバとして機能する。具体的には、コンテンツ配信の要求を受け付けるWebページを持ち、ユーザ端末4からのコンテンツ配信要求に応じて、暗号化されたコンテンツをユーザ端末4に配信したりする。
利用条件管理サーバ3は、ワークステーション等のコンピュータであり、ユーザ管理サーバ、課金サーバ、ライセンス管理サーバとして機能する。具体的には、利用条件管理サーバ3は、本システム1に加入したユーザや、そのユーザが所有する端末を管理したり、ユーザ端末4などからコンテンツの利用権購入を受け付けたり、ユーザ端末4a等からのライセンスチケット発行要求(以下、「LT発行要求」とも記す。)を受け付けるWebページを持ち、ユーザ端末4からのコンテンツの利用権購入要求に応じて課金したり、LT発行要求に応じて暗号化されたコンテンツをユーザ端末4で利用するためのLTを配信したりする。
このLTは、暗号化されたコンテンツを復号化するためのコンテンツ鍵と、コンテンツについてユーザに付与された利用権利(ライセンス)の中からその一部を切り出した切り出し利用条件(UR−Uc)とを含む。
ユーザ端末4は、パーソナルコンピュータ、携帯情報端末、デジタルテレビ等のコンピュータ装置であり、利用条件管理サーバ3に対するクライアントとして機能する。具体的には、ユーザ端末4は、ユーザの操作に応じて、インターネットブラウザソフト等のツールを用いて利用条件管理サーバ3のWebページにアクセスし、コンテンツ購入要求を送信してコンテンツの配信を受けたり、コンテンツの利用に当たってLT発行要求を送信してLTを受け取り、LTの切り出し利用条件の範囲でコンテンツを再生したりする。
なお、ユーザ端末4には、他のユーザ端末用の外部メディア44(例えば、SDカード等)を装着することができ、ユーザ端末4が保持するコンテンツやLTを外部メディア44に複写したり、移動したりし、他のユーザ端末でコンテンツを再生することができるように構成されている。
通信ネットワーク5は、インターネット、CATV等の有線や、デジタル放送等の無線による通信媒体である。
図24は、図23に示されるコンテンツ配信サーバ2及び利用条件管理サーバ3の構成を示す機能ブロック図である。なお、本図には通信ネットワーク5も併せて示されている。
コンテンツ配信サーバ2は、コンテンツデータベース21と、通信部22とを備える。コンテンツデータベース21は、暗号化されたコンテンツと、このコンテンツに対して付与されるユニークな識別子であるコンテンツIDなどとを関連付けて保持する。なお、通信部22は、ユーザ端末4からのコンテンツ配信要求を受け付けて、要求されたコンテンツを配信する。
利用条件管理サーバ3は、大きく分けて、ハードディスク等に格納されたデータファイル等によって実現されるデータ部(ユーザ情報データベース31、利用権利データベース32、コンテンツ鍵データベース33)と、CPU、RAM、ROM等のハードウェア及びCPUにより実行されるプログラム等によって実現される処理部(ユーザ特定部34、LT生成部35、LT解析部36、利用権利更新部37、通信部38)とからなる。
ユーザ情報データベース31は、ユーザ端末4の端末IDを用いてそのユーザ端末を購入し、このコンテンツ利用管理システム1に会員登録したユーザのユーザID、ユーザ名等を記憶する。利用権利データベース32は、コンテンツブロバイダが決定したコンテンツ毎の利用権(UR−C)と、コンテンツに対するユーザの権利情報(ライセンス)を蓄積する。具体的には、利用権利データベース32は、ユーザが購入したコンテンツや、そのコンテンツに対してユーザが有する利用権(ライセンス)の残存情報を利用の態様(例えば、再生、印刷等)毎に複数記憶する記憶部である。コンテンツ鍵データベース33は、コンテンツの関連情報(コンテンツ鍵など)を蓄積する。具体的には、コンテンツを暗号化するための複数のコンテンツ鍵と、コンテンツIDとを対応付けて記憶する。
ユーザ特定部34は、ユーザ端末4の端末IDを用いてこの端末IDに対応したユーザID等を特定する。LT生成部35は、ユーザ端末4から送られてきたLT発行要求に含まれるELIに基づいて対応したLTを生成したりする。LT解析部36は、ユーザ端末4から送られてきたLTを解析し、解析結果に応じてUR−Usの内容を更新したりする。利用権利更新部37は、LT生成部35がLTをユーザ端末4に送信した場合に、利用権利データベース32に格納されたUR−Usの内容を更新する。
通信部38は、ユーザ端末4と通信する。具体的には、通信部38は、通信ネットワーク5を介してユーザ端末4と通信するWebページに記述されるスクリプトやプログラム等によって実現される通信インタフェースであって、ユーザ端末4から送信されてきたコマンドやメッセージを解析したり、その結果に応じてユーザ特定部34及びLT解析部36に処理を依頼したり、LT生成部35から渡されたLTをユーザ端末4に配信したり、端末との間でSACを形成したりする。なお、通信部38は、ユーザ端末4からの要求に応じて利用権利データベース32のUR−Usに関する情報や、コンテンツデータベース21のコンテンツに関する情報をバスを介して取得し、要求を発したユーザ端末4にこれらの情報を送信し、LTの購入や、LT発行要求のためのGUI(Graphical User Interface)を提供する。
図25は、図23に示されるユーザ端末4の構成を示す機能ブロック図である。なお、本図には通信ネットワーク5も併せて示されている。
ユーザ端末4は、大きく分けて、LTの発行を要求したり、取得したLTを統括的に管理するクライアント41と、音楽、映画等のコンテンツを再生するレンダリングプラグイン42と、取得したコンテンツやLTを外部へ書き出すストレージプラグイン43と、書き出されたコンテンツやLTを格納するSDカード等の外部メディア44とから構成される。
クライアント41は、通信部410Aと、モニタ411aと、操作部411bと、コンテンツデータベース412Aと、LTデータベース413Aと、端末ID蓄積部414Aと、LT取得部415Aと、LT返却部416Aと、LT管理・更新部417Aと、コンテンツ利用可否判定部418Aと、プラグイン制御部419Aとからなる。レンダリングプラグイン42は、再生条件判定部421Aと、コンテンツ復号部422Aと、コンテンツ再生部423Aとからなる。また、ストレージプラグイン43は、書き出し条件判定部431Aと、書き込み用データ生成部432Aと、メディアアクセス部433Aとからなる。
クライアント41の通信部410Aは、コンテンツ配信サーバ2及び利用条件管理サーバ3との間で通信を行う。具体的には、通信部410Aは、ブラウザソフト等に従って通信ネットワーク5を介してコンテンツ配信サーバ2及び利用条件管理サーバ3と通信する通信インタフェースであり、操作部411bからの依頼に応じてコンテンツ配信サーバ2から送信されてきたコンテンツをコンテンツデータベース412Aに格納したり、利用条件管理サーバ3の通信部38との間でSAC(Secure Authenticated Channel:認証付き安全な通信路)を形成し、コンテンツの利用権利購入要求や、LT発行要求のメッセージを利用条件管理サーバ3に送信したり、利用条件管理サーバ3から送信されてきたLTをLTデータベース413Aに格納したりする。
モニタ411aは、利用条件管理サーバ3が提供するWebページを表示したり、LTの購入や、LT発行要求のためのGUIを表示する。操作部411bは、ユーザの操作を受け付けるユーザインタフェースである。コンテンツデータベース412Aは、例えば、HDD等で構成され、暗号化されたコンテンツを蓄積する。LTデータベース413Aは、通信部410Aから送られてきたLTをセキュアに蓄積する。端末ID蓄積部414Aは、その端末の端末ID等を蓄積する。
LT取得部415Aは、LT発行要求を生成し、通信部410Aを介して利用条件管理サーバ3に送信したり、利用条件管理サーバ3から送信されてきたLTを取得してLTデータベース413Aに格納したりする。LT返却部416Aは、所定の場合にLTを通信部410Aを介して利用条件管理サーバ3に返却する。LT管理・更新部417Aは、LTデータベース413Aに格納されているLTを管理したり、LTに含まれる利用条件を更新したりする。コンテンツ利用可否判定部418Aは、LTの利用条件に基づいてそのLTが利用できるか否かの可否を判定する。プラグイン制御部419Aは、セキュアなクロック機構を備え、レンダリングプラグイン42におけるコンテンツ再生の時間を計測し、計測時間に基づいて再生回数を制御したりする。
レンダリングプラグイン42の再生条件判定部421Aは、クライアント41から送られてきたレンダリングプラグイン42における条件(P条件)に基づく再生条件を判定する。コンテンツ復号部422Aは、クライアント41から送られてきたコンテンツ鍵でコンテンツデータベース412Aから取得したコンテンツを復号化する。コンテンツ再生部423Aは、復号化されたコンテンツを再生する。
ストレージプラグイン43の書き出し条件判定部431Aは、クライアント41から送られてきたストレージプラグイン43における条件(P条件)に基づく書き出し条件を判定する。書き込み用データ生成部432Aは、受信したLTや、コンテンツデータベース412Aから取得したコンテンツを外部メディア44用のフォーマットのデータに変換する。メディアアクセス部433Aは、フォーマット変換されたデータを外部メディア44に書き出す。
なお、このNetDRMシステム1においては、利用条件(UR)は、コンテンツブロバイダが指定し、ユーザの購入対象となる利用条件UR−Cと、利用条件管理サーバで管理され、ユーザが購入し、現在所持している利用条件UR−Usと、UR−Usから一部を切り出され、ユーザ端末において管理される利用条件UR−Ucとに分けて構成される。UR−Usは、LT発行要求に含まれるELIに対応したLTの発行により、UR−Cから回数などが減少する。なお、UR−Usはあるユーザが購入した複数のコンテンツをまとめて対象とすることができる一方、UR−Ucは1つのコンテンツだけを対象とする。ELIは、どのコンテンツをどういう条件で使いたいかというLT発行要求に埋め込まれる情報である。また、LTは、指定されたコンテンツのコンテンツ鍵とUR−Ucが一緒になった情報である。また、LT発行要求があった場合などには、NetDRMサーバで管理している情報(S条件、例えば同時に利用できる端末数)に基づいてLTを発行してよいか否か判定される。NetDRMクライアントでは、クライアント条件(C条件、例えば、有効期間、利用回数、累積利用時間)に基づいてアクションを開始してもよいか否かを判定する。また、プラグインでは、プラグイン条件(P条件、例えば2ch再生等)に基づいて再生を制御する。
図26は、図24に示されるコンテンツデータベース21が保持するコンテンツのデータフォーマットの構成例を示す図である。
コンテンツ10は、そのコンテンツに付与されたユニークな識別子であるコンテンツID11と、単一又は複数のキャラクタコード12#1,…,#Nと、このキャラクタコード12#1〜#Nで表される内容を示すメタデータ13#1,…,#Nと、暗号化コンテンツデータ14とからなる。
例えば、そのコンテンツが、音楽「波乗りジョージ」である場合、コンテンツID11には「riderjogi」が記述される。また、キャラクタコード12#1,…,#Nには、例えば、EUC(Extended Unix(登録商標) Code)や、junetコード(iso−2022−jpコード)等である旨が記述される。また、メタデータ13#1,…,#Nには、例えば、「曲」名、「歌手」名、「バックバンド」名、「作詞家」名、「作曲家」名等が記述される。さらに、暗号化コンテンツデータ14には、コンテンツ自体(この例では、音楽「波乗りジョージ」)が所定の鍵で暗号化された上で格納される。
なお、このコンテンツ10の暗号化コンテンツデータ14は、コンテンツID11で対応付けられたコンテンツ鍵を手に入れて復号化しないと、視聴することができない。このため、このシステムに加入していない一般ユーザの端末からもコンテンツ10を自由にダウンロードできるようになっている。
図27は、図24に示されるユーザ情報データベース31が保持するユーザ情報テーブルの構成例を示す図である。
ユーザ情報テーブル50は、ユーザが購入し、利用条件管理サーバ3に登録したユーザ端末の端末IDでユーザを特定するためのテーブルであって、このシステムにおけるユーザ端末に特有のユニークな識別子「端末ID」51、このユーザ端末を購入したこのシステムにおけるユーザに特有のユニークな識別子「ユーザID」52と、ユーザ名等、住所、電話番号(不図示)等とのフィールドが設けられている。
例えば、2台のユーザ端末を購入し、このユーザ端末をシステムに登録したユーザ、岡本の場合、この2台のユーザ端末にそれぞれ付与された端末ID「×××111」及び「×××222」と、岡本に付与されたユーザID「×××AAA」と、そのユーザ名等、住所、電話番号等とが2つのレコードを用いて格納される。1台のユーザ端末を購入し、このユーザ端末をシステムに登録したユーザ、東の場合、このユーザ端末に付与された端末ID「×××333」と、東に付与されたユーザID「×××BBB」と、そのユーザ名等、住所、電話番号等とが1つのレコードに格納される。
図28は、図24に示される利用権利データベース32が保持する利用権利管理テーブルの構成例を示す図である。
利用権利管理テーブル60は、ユーザIDでこのユーザが購入した各コンテンツに対する利用権(UR−Us)を管理するためのテーブルであって、「ユーザID」60Aと、この利用条件管理サーバ3で管理される利用権の内容「UR−Us」60Bのフィールドから構成される。
例えば、ユーザ岡本(ユーザID「×××AAA」)の場合、曲「波乗りジョージ」と、電子書籍「狭辞苑」との2つのコンテンツに対する利用権を購入しているときには、UR−Us60Bにはこの波乗りジョージの利用権と、狭辞苑の利用権とがレコードを変えて格納される。
またユーザ東(ユーザID「×××BBB」)の場合、映画「蜘蛛娘」の1つのコンテンツに対する利用権を購入しているときには、UR−Us60Bにはこの蜘蛛娘の利用権が1つのレコードに格納される。
図29は、図28に示されるUR−Us60Bの詳細な構成例を示す図である。
UR−Us60Bは、大きく分けて、利用の基本内容を管理するためのUR−Usヘッダ61と、利用権の具体的内容(再生、プリント、移動等のアクション)を管理するための単一又は複数のアクション情報62#1〜62#nとから構成される。この、利用権の内容は、コンテンツ提供者やサーバの管理者がコンテンツの属性に応じてコンテンツ毎に初期値(UR−C)が予め定められており、コンテンツ購入時にUR−Cと同内容の利用権がユーザに付与される。
UR−Usヘッダ61は、UR−Usヘッダ61のサイズを示すUR−Usヘッダサイズ611と、このユーザが購入したコンテンツ毎の利用権に対して付与されたこのシステムにおける特有のユニークな識別子UR−UsID612と、有効期間の開始時刻613と、有効期間の終了時刻614と、移動許可フラグ615と、同時利用可能数616と、発行状態LT数617と、アクション情報62#1〜62#nの数を表すアクション情報数618とからなる。
有効期間の開始時刻613及び有効期間の終了時刻614は、利用条件管理サーバ3が管理するユーザの利用権の有効期間の始期及び終期をそれぞれ示する。但し、例えば、UR−Usは1月有効だが、LTは常に1日だけ有効とする場合のように、LTにUR−Usより短い有効期間を指定することができる。また、有効期限を設けない場合には、両時刻613,614に制限なし(unlimited)を格納することができる。このLTに指定される有効期間は、NetDRMシステム1のクライアントでアクションを開始してもよいか否かを判定する条件(以下、「C条件」とも記す。)として用いられる。
移動許可フラグ615は、このUR−Us60Bに基づいて発行されたLTを発行先の端末から他の端末及び外部メディアに移動(Move−out、Export)できるか否かを表す。
同時利用可能数616及び発行状態LT数617は、複数のユーザ端末を所持しているユーザ(例えば、岡本)が、電子書籍のようなコンテンツをこれらのユーザ端末で台数制限付きで共同利用するような場合に対処するために設けられたものである。同時利用可能数616には、同時に、何枚のLTを発行できるかを示す枚数が格納される。また、発行状態LT数617には、その時点で何枚のLTを発行されているかを表す枚数が格納される。なお、この発行状態LT数617の枚数は、LTを発行する毎にインクリメントされ、同時利用可能数に達するとLTの発行が停止される。これに対して、発行したLTがユーザ端末から戻されると発行状態LT数617の枚数がデクリメントされる。これにより、同時にコンテンツを利用できる端末数を制限することができる。なお、この同時利用可能数616及び発行状態LT数617は、NetDRMシステム1のサーバで判定される条件(以下、「S条件」とも記す。)として用いられる。
また、各アクション情報62#1〜62#nは、アクション情報62#1〜62#nのサイズを表すアクション情報サイズ621と、アクションID622と、最長利用時間623と、1回判定しきい値・回数カウンタ/累積利用時間624と、P条件625#1〜625#nとからなる。
アクションID622には、再生(PlayBack)、印刷(Print)等、コンテンツの利用の態様(アクション)を表す識別子が格納される。このアクションID622は、例えば、再生(PlayBack)の場合には「2」が、印刷(Print)の場合には「5」が格納される。
最長利用時間623には、再生処理などにおいてコンテンツを連続して利用できる最大時間が格納される。
1回判定しきい値・回数カウンタ/累積利用時間624に格納される、1回判定しきい値はコンテンツの利用を1回と判断する時間を示し、回数カウンタはコンテンツを利用することができる残りの回数を示し、累積利用時間はコンテンツを利用できる累積時間を示している。なお、1回判定しきい値・回数カウンタと累積利用時間とは排他的な関係にあり、両方が同時に指定されることはない。
ここで、回数カウンタの値は、ユーザのLT発行要求に応じて切り出される利用条件、ライセンス情報の分ずつ、初期値から順次デクリメントされたり、コンテンツ提供者のサービス提供要求に応じてインクリメントされたりする。
P条件625#1〜625#nには、ユーザ端末のプラグインにおいてコンテンツ毎にそのコンテンツのアクションを実行するため制御条件が格納される。例えばプリント用のコンテンツの場合にあっては白黒で印刷しなければならないであり、音楽再生用のコンテンツの場合、2チャンネルステレオで再生しなければならない等が該当する。
なお、コンテンツが複数のコンテンツからなるアルバムや全集である場合には、このアルバムや全集に含まれるコンテンツの数、コンテンツ数631と、このアルバムや全集に含まれるコンテンツの識別子、コンテンツID632#1〜632#nとをこのUR−Us60Bに付加することで対応される。
図30は、図23〜図25に示されるLT発行要求70のデータフォーマット構成例を示す図である。
LT発行要求70は、大きく分けて、この要求がLT発行要求であることを示すユニークな識別子であるLT発行要求識別子71と、LT発行要求70を発するユーザ端末の端末ID72と、どのコンテンツをどういう条件で使いたいかを示す期待LT情報(Expected LT Information、以下「ELI」とも記す。)73とからなる。
ELI73は、発行要求の基本内容を示すELIヘッダ730と、発行要求の具体的内容を示す単一又は複数の期待アクションタグブロック740#1〜740#nとからなる。
ELIヘッダ730は、このELI73がELIであることを示すELI識別子731と、このNetDRMシステム1で定められる仕様において定められるユーザ端末のバージョンを示す NetDRMバージョン番号732と、ELI73のサイズを示すELIサイズ733と、発行要求を希望するLTの対象となるコンテンツのコンテンツID734と、利用権の切り出し対象となる利用条件管理サーバ3が管理する利用権の識別子、UR−UsID735と、ユーザ端末のクライアントが、LT格納用のセキュアなDBを持つか、時間管理用のセキュアなクロックを持つか否か表す、クライアント能力フラグ736と、ELIで希望する条件(例えば、回数)のLTを発行できない場合、サーバがLTを発行しないことを望むか、条件が縮小された回数のLTでも発行することを望むかを表すフラグ、LT発行拒否フラグ737とからなる。なお、LT発行拒否フラグ737には、発行拒否の場合には「ON」が、縮小を許容する場合には「OFF」が格納される。
期待アクションタグブロック740#1〜740#nは、LTに格納して欲しいアクションの識別子、アクションID741と、発行するLTに設定を望む回数を示す回数カウンタ、又はLTに設定を望む累積利用時間を示す期待回数/期待累積利用時間742とからなる。
図31は、図23〜図25に示されるLTのデータフォーマット構成例を示す図である。
LT80は、大きく分けて、利用の基本内容を管理するためのLTヘッダ81と、利用権の具体的内容(再生、プリント等のアクション)を管理するための単一又は複数のアクションタグブロック82と、コンテンツ鍵83と、オプションで付加可能なLTフッタ84とからなり、コンテンツIDと、アクションIDによるC条件及びP条件の束とコンテンツ鍵等とで示される。
LTヘッダ81は、LT識別子810と、NetDRMバージョン番号811と、LTサイズ812と、コンテンツID813と、UR−UsID814と、LT状態フラグ(LT即時消費フラグ/LT自動返却フラグ)815と、LT有効期間の開始時刻816と、LT有効期間の終了時刻817と、LT移動許可フラグ818と、LT暗号化法819とが格納される。
LT識別子810は、このデータがこのコンテンツ利用管理システム1で扱われるライセンスチケットであることを表す。NetDRMバージョン番号811は、このシステムで定められるサーバが提供する仕様のバージョンを示す。LTサイズ812は、LT全体のデータサイズを示す。コンテンツID813は、このLTの対象であるコンテンツのIDを示す。UR−UsID814は、このLTの発行の元であるUR−UsのIDを示す。
LT状態フラグ(LT即時消費フラグ/LT自動返却フラグ)815は、このLTは記録媒体に書き込めず、即座に消費しなければならないかを表すフラグ、LT即時消費フラグと、このLTに含まれる権利が消失した時、サーバに自動的に返却しなければならないかを表すフラグ、LT自動返却フラグとを示す。なお、LT自動返却フラグは、UR−Usの同時利用可能数が有限の場合に「ON」に設定され、UR−Usの同時利用可能数が無限の場合に「OFF」に設定される。LT即時消費フラグは、クライアントにセキュアなLTデータベースがない場合と、UR−Usに有効期限が設定されており、且つクライアントにセキュアな時計機能がない場合に「ON」に設定され、これ以外の場合に「OFF」に設定される。
LT有効期間の開始時刻816は、このLTが有効になる日時を示す。LT有効期間の終了時刻817は、LTが無効になる日時を示す。LT移動許可フラグ818は、このLTを移動できるか、Move−outできるか、Exportできるかを表す。LT暗号化法819は、コンテンツ鍵83及びオプションで付加されうるLTフッタ84に適用される暗号方式(DES,AES等)を示す。
アクションタグブロック82#1〜82#nは、アクションID821と、最長利用時間822と、1回判定しきい値・回数カウンタ/累積利用時間823と、P条件824#1〜824#nとからなる。
アクションID821は、コンテンツに対するアクション内容を特定するIDを示す。最長利用時間822は、コンテンツを連続して操作できる最大時間を示す。1回判定しきい値・回数カウンタ/累積利用時間823の1回判定しきい値は、コンテンツの操作を1回と判断する時間を示す。回数カウンタは、このLTでコンテンツを操作できる回数を示す。累積利用時間は、コンテンツを操作できる累積の操作時間を示す。なお、最長利用時間822ではポーズ等の間も時間のカウントが継続され、これに対して累積利用時間ではポーズ等の間、時間のカウントが停止される。
ここで、図32を用いて回数カウンタの1回と、最長利用時間、1回判定しきい値、累積利用時間との関係を説明する。
累積利用時間は、最長利用時間よりも厳密な利用制御を行う場合に用いられ、通常のコンテンツ再生に必要な時間(例えば、10日、最大約5年222日まで)が設定される。LT有効期間の開始日が7月1日でLT有効期間の終了日が8月31日の場合、この間であれば、5日、2日、3日のような細切れの日時のコンテンツ利用をすることができ、この累積時間が累積利用時間に達するとそのLTでのコンテンツ利用ができなくなる。
回数カウンタには任意の回数(例えば5回、最大で16383回まで)を設定することができる。また、最長利用時間には任意の時間(例えば3分、最大で約18時間まで)を設定することができる。また、1回判定しきい値には任意の値(例えば30秒、最大で18時間まで)が設定される。ここで、ユーザ端末4においてコンテンツ操作(利用)を開始すると開始から20秒経過した時点で再生を停止すると、この再生は1回とみなされない。これに対して開始から1回判定しきい値30秒経過すると1回と判定され、最長利用時間が経過するまで、その間のポーズ等を含めてコンテンツを再生することができる。なお、回数カウンタの値は、1回判定しきい値を超えた時点で1デクリメントされる。
図31に戻り、コンテンツ鍵83は、このLTに関連付けられたコンテンツの暗号を解く復号鍵、コンテンツ鍵が暗号化されたまま格納される。なお、オプションとしてコンテンツ鍵83の次にLTフッタ84を付加することができる。このLTフッタ84には、LTヘッダ81からコンテンツ鍵83のSHA−1アルゴリズムによるハッシュ値が暗号化されて格納され、LTが信頼できない経路で配信された場合、この値で改ざんチェックを行うことができるようになっている。
次いで、LT取得動作及びコンテンツ再生動作を説明する。
このようなLT取得動作及びコンテンツ再生動作を行うユーザ端末においては、その端末のモニタに図33に示される画面が表示される。
本図に示されるように、画面中には、ユーザ端末やサーバに保持されるコンテンツや、LT、UR−Us、P条件等をリスト表示するリストボックス901、リストボックス901でカーソルが合わせられたコンテンツの概要等の説明を表示するコンテンツ説明ボックス902、リストボックス901でカーソルが合わせられたコンテンツの再生画像等を表示するためのコンテンツ再生ボックス903のほか、コンテンツの利用権利を購入の際にクリックされる利用権利購入ボタン904、LT取得の際に押下されるLT取得ボタン905、この画面の表示データを更新する場合に押下される更新ボタン907、再生スタート、停止、ストップ、早戻し、早送り等の再生操作をするための再生操作ボタン908、再生時間等を表示する時間表示ボックス909等が設けられる。
リストボックス901には、コンテンツのタイトル(図示例では、「波乗りジョージ」、「狭辞苑」、「突入せよ!!赤城山荘」)や、そのコンテンツの再生可能回数(図示例では、「再生9回」、「制限なし」)、有効期限(図示例では、「制限なし」、「2002/10/31」)、P条件(図示例では、「2ch再生」、「白黒印刷」)等が表示される。なお、コンテンツ「突入せよ!!赤城山荘」は、このコンテンツの販売促進のためにコンテンツ配信サーバ2から送られてきたプレビュー版であり、このコンテンツにカーソルが合わせられている状態が示されている。
このリストボックス901の左端には、アイコン901a〜901e等が表示される。アイコン901aは、この端末にコンテンツに対応したLTを保持しており、且つサーバにUR−Usがあることを示している。アイコン901bは、この端末にはコンテンツに対応したLTがないが、サーバにはUR−Usがあることを示している。アイコン901cは、この端末にLTがなく、且つサーバにもUR−Usがないことを示している。アイコン901dは、この端末にコンテンツを保持していることを示している。アイコン901eは、この端末にコンテンツを保持していないことを示している。これらのアイコン901a〜901eでUR−Us、LT及びコンテンツのありなしの状態を全て表すことができる。
コンテンツ再生ボックス903には、リストボックス901でカーソルが合わせられたコンテンツの再生画面が表示される。
コンテンツ再生ボックス903の上部には、音楽、ビデオ、移動、電子書籍の再生等の各種アクションを選択するためのタブが設けられており、図示例ではリストボックス901でカーソルが合わせられたコンテンツを再生するためのビデオ用のタブが選択された状態が示されている。この状態で再生用の再生操作ボタン908がクリックされると、コンテンツ配信サーバ2から送られてきたコンテンツ、突入せよ!!赤城山荘事件のプレビュー画面が表示される。
なお、ビデオ再生用のタブなどに設けられたアイコン903aは、そのコンテンツ再生用のプラグインを保持していることを示す。コンテンツ移動用のタブに設けられたアイコン903bは、コンテンツ再生(ここでは移動)用のプラグインがないことを示す。このようにプラグインがない場合には、例えば外部メディア44を装着する装置がない等のハード的な不備がない限り、プラグインがないことを示すタブが選択された際に、不足するプラグイン(ここでは、移動用のプラグイン)を提供するサーバにアクセスし、不足のプラグインをダウンロードし、アイコン903aが表示されるようになっている。
ここで、リストボックス901の表示内容やコンテンツ説明ボックス902の表示内容は、この画面の表示の際にコンテンツデータベース412Aに格納されたコンテンツのメタデータを取得したり、LTデータベース413Aに格納されたLTの権利内容を取得したり、利用条件管理サーバ3に対してGetUR−Us,GetP条件テキスト,Getメタデータなどコマンドを送り、サーバ内にある権利UR−Usの内容(P条件も含む)を取得したり、端末にはないが、利用権利を保持するコンテンツのメタデータを取得し、取得した情報に基づいて作成される。
図34は、サーバにある権利内容を取得する場合に、クライアント41から利用条件管理サーバ3に送信されるGetUR−Usの構成を示す図である。
このGetUR−Us91は、GetUR−Usであることを示す識別子GetUR−Us識別子911と、このGetUR−Us91を送信したユーザ端末を識別する端末ID912と、取得するデータをどのような文字コードで表示する記を指定するためのキャラクタコード913とからなる。このキャラクタコード913には、通常、EUCや、junetコード、シフトJISコード等が格納される。このようなGetUR−Us91を送ることにより、端末ID912に対応したユーザIDで管理されるサーバにあるUR−Usの一覧を取得することができる。なお、その際、キャラクタコードで指定した文字コードでUR−UsName(利用権利管理テーブル60の図示しないフィールドに格納されるコンテンツのジャンルや、60年代のロック等、権利の内容名)も同時に取得する。また、GetUR−Us91を送る際に、GetP条件テキストをクライアント41から利用条件管理サーバ3に送信する。
図35は、GetP条件テキストの構成例を示す図である。
GetP条件テキスト92は、P条件の表示内容を、キャラクタコードで指定した文字コードで取得するためのものであって、送信した情報がGetP条件テキストであることを示す識別子、GetP条件テキスト識別子921と、GetP条件テキスト92を送信したユーザ端末を識別するための端末ID922と、P条件を表示する文字コードを指定するためのキャラクタコード923と、単一又は複数のP条件ID924#1〜924#Nとからなる。このように構成されたGetP条件テキスト92を送信することにより、GetUR−Us91で得られた各UR−Usに含まれるP条件の表示用情報(例えば、再生条件の指定(2ch再生、白黒印刷など)や、再生する際の出力インタフェースの指定(例えば、アナログ、Protectedデジタル、Non−Protectedデジタルなど))を取得することができる。
図36は、上記GetP条件テキスト92により利用条件管理サーバ3から取得されるP条件の表示用情報の構成例である。P条件の表示用情報93は、複数のP条件931#1〜931#Nからなる。
P条件931#1は、図示例ではレンダリング用のP条件であり、モノラル再生でしかもアナログ出力の場合だけが許可(図中に示される「○」)されており、Protectedデジタル出力(例えば、暗号化されたデジタル出力)も、Non−Protectedデジタル出力(例えば、暗号化されていない状態でのデジタル出力)も禁止(図中に示される「×」)されている。P条件931#2は、図示例ではストレージ用のP条件であり、SDカードへのコンテンツ転送について、Protectedデジタル出力は許可されているが、アナログ出力及びNon−Protectedデジタル出力は禁止されていることが示されている。P条件931#Nは、図示例ではストレージ用のP条件であり、メモリスティックへのコンテンツ転送について、Protectedデジタル出力は許可されているが、アナログ出力及びNon−Protectedデジタル出力は禁止されていることが示されている。
図37は、Getメタデータの構成例を示す図である。
Getメタデータ94は、この情報がGetメタデータであることを示す識別子、Getメタデータ識別子941と、このGetメタデータ94を送信したユーザ端末を識別する端末ID942と、コンテンツのメタデータを、指定した文字コードで取得するためのキャラクタコード943と、メタデータを得る対象のコンテンツを識別するコンテンツID944#1〜944#Nとから構成される。このGetメタデータ94を受信した利用条件管理サーバ3の通信部38は、コンテンツ配信サーバ2のコンテンツデータベース21にアクセスし、コンテンツID944#1〜944#Nで指定されたコンテンツのメタデータ(図26参照)を取り出して、ユーザ端末4に送信する。これにより、ユーザ端末4は、端末内にないコンテンツのメタデータを取得することができる。
このようなGetUR−Us91、GetP条件テキスト92、Getメタデータ94等を送信し、必要な情報を取得して画面用のデータに再構成することにより図33に示される画面が作成される。
そして、リストボックス901に表示されたコンテンツ(例えば、狭辞苑)のLTを取得する場合、狭辞苑の欄にカーソルを合わせ、LT取得ボタン905をクリックする。これにより、LT取得プロセスが開始される。なお、コンテンツ「波乗りジョージ」についてさらにLTを取得するような場合には、このコンテンツにカーソルを合わせ、取得したい再生回数を入力し、LT取得ボタン905をクリックすればよい。
このようなLT取得ボタン905がクリックされると、ユーザ端末4のクライアント41及び利用条件管理サーバ3においてLT取得プロセスが行われる。
図38は、ユーザ端末4のクライアント41及び利用条件管理サーバ3によって行われるLT取得プロセスの動作を示すフローチャートである。
LT取得ボタン905がクリックされると、クライアント41のLT取得部415Aは、LT発行要求の本体、即ちELIを生成するELI生成プロセスを実行する(S11)。そして、LT取得部415Aは、生成したELIに、LT発行要求識別子71と、端末ID蓄積部414Aから読み出した端末ID72とを付加することより図30に示されるフォーマット構成に従うLT発行要求を生成し、生成したLT発行要求を利用条件管理サーバ3に送信する(S12)。
一方、利用条件管理サーバ3のユーザ特定部34は、通信部38を介してユーザ端末4からLT発行要求を受信すると、ユーザ情報データベース31を参照し、LT発行要求70に含まれる端末ID72からユーザ(ユーザID)を特定する(S21)。
ユーザ特定部34がユーザを特定できた場合(S22でYES)、LT生成部35は、利用権利データベース32に保持され、ユーザ特定部34によって特定されたユーザIDに対応するUR−Usに基づいて、LTを発行できるか否かを判定するLT発行可否判定プロセスを実行する(S23)。
実行の結果、LT生成することが可能であれば(S24でYES)、LT生成部35は、LTを生成するLT生成プロセスを実行し(S25)、生成したLTをユーザ端末4に送信する(S26)。
なお、ステップS22においてユーザを特定できなかった場合(S22でNO)、あるいはステップS24においてLTを生成できなかった場合(S24でNO)、LT生成部35は、LT発行不可通知を生成し、送信する(S27)。このLT発行不可通知は、例えば、LT発行不可通知であることを特定するためのユニークな識別子の他、拒否の対象となったコンテンツのコンテンツID、未購入等の拒否理由を示すエラーコードなどからなる。
クライアント41のLT取得部415Aは、通信部410Aを介してLTを取得すると(S13)、取得したLTに含まれるLT状態フラグ(LT即時消費フラグ/LT自動返却フラグ)815を参照し、即時消費フラグが「OFF」(蓄積)であるか否かを判断する(S14)。判断の結果、即時消費フラグが「ON」(即時消費)である場合(S14でNO)、LT取得部415Aは、LTをLTデータベース413Aに格納(登録)せずにLT取得プロセスを終了する。この場合には、LTを即時消費するため、このLTを用いたコンテンツ再生が直ちに実行される。これに対して、即時消費フラグが「OFF」である場合(S14でYES)、LT取得部415Aは、取得したLTをLTデータベース413Aへ登録(格納)し(S15)、LT取得プロセスを終了する。
また、LT取得部415Aは、通信部410Aを介してLT発行不可通知を受信すると(S16)、通信部410Aを介してモニタ411aに拒否理由等を表示させ、LT取得プロセスを終了する。
図39は、図38に示されるELI生成プロセス(S11)のサブルーチンを示すフローチャートである。
このELI生成プロセスのサブルーチンでは、LT取得部415Aは、先ず、これから作成するELIヘッダのELI識別子、NetDRMバージョン番号に規定の値を設定する(S111)。次いで、LT取得部415Aは、ELIサイズを計算し、得られたELIサイズをELIヘッダに設定する(S112)。そして、LT取得部415Aは、要求するLTの対象となるコンテンツのコンテンツIDをELIヘッダに設定し(S113)、LTの元となるUR−UsのUR−UsIDをELIヘッダに設定し(S114)、このユーザ端末でサポートするクライアントの能力に合ったクライアント能力フラグをELIヘッダ730に設定し(S115)、ユーザから指定された値(発行拒否の場合には「ON」、縮小を許容する場合には「OFF」)をLT発行拒否フラグ737に設定する(S116)。
ELIヘッダへの設定が終わると、LT取得部415Aは、ユーザから指定されたアクションの値(例えば、再生の場合、「2」)を期待アクションタグブロック740のアクションID741に設定する(S117)。次いで、通信部410A(LT取得部415A)は、ユーザから指定された回数を期待回数/期待累積利用時間742に設定し(S118)、図38に示されるメインルーチンにリターンする。これにより、ユーザが期待するELIが生成される。
なお、アクションが複数である場合には、このアクションの数だけステップS117,S118が繰り返される。また、ステップS116〜S118で設定される値は、予め定められたデフォルト値であってもよい。
図40は、図38に示されるLT発行可否判定プロセス(S22)のサブルーチンを示すフローチャートである。
このLT発行可否判定プロセスのサブルーチンにおいては、LT生成部35は、先ず、LT発行要求のELIで指定された利用条件UR−Usが利用権利DBに存在するか否か判断する(S221)。利用条件UR−Usが存在する場合(S221でYES)、LT生成部35は、UR−Usヘッダ61の有効期間の終了時刻614を参照し、そのUR−Usの有効期間は過ぎているか否か判断する(S222)。有効期間内である場合(S222でNO)、LT生成部35は、同時利用可能数616と、発行状態LT数617とに基づいてUR−Usの発行状態LT数が同時利用可能数未満か否か判断する(S223)。同時利用可能数未満である場合(S223でYES)、LT生成部35は、1回判定しきい値・回数カウンタ/累積利用時間624を参照し、UR−Usの回数カウンタは「0」であるか否か判断する(S224)。回数カウンタが「0」でない、即ち回数カウンタが1以上である場合(S224でNO)、LT生成部35は、UR−Usの回数カウンタがELIの期待回数以上持っているか否か判断する(S225)。
期待回数以上持っていない場合(S225でNO)、LT生成部35は、ELIのLT発行拒否フラグが「OFF」か否か判断する(S226)。期待回数以上持っている場合(S225でYES)、LT生成部35は、LT発行可と判定し(S227)、このサブルーチンを終了し、図38に示されるメインルーチンにリターンする。また、期待回数以上持っていないけれども(S225でNO)、ELIのLT発行拒否フラグが「OFF」である場合、即ち期待回数よりも少なくてもよい場合には(S226でYES)、LT生成部35は、LT発行可と判定し(S227)、このサブルーチンを終了し、図38に示されるメインルーチンにリターンする。
これに対して、利用権利データベースに利用条件UR−Usが存在しない場合(S221でNO)、有効期間が過ぎている場合(S222でYES)、同時利用可能数以上である場合(S223でNO)、回数カウンタが「0」である場合(S224でYES)、回数カウンタが「1」以上で(S225でNO)且つLT発行拒否フラグが「OFF」(S226でNO)である場合のいずれかの場合には、LT生成部35は、LT発行不可と判定し(S228)、このサブルーチンを終了し、図38に示されるメインルーチンにリターンする。これにより、利用条件管理サーバ3が管理するUR−Usの範囲内で適切なLT発行の可否を判定することができる。
図41は、図38に示されるLT生成プロセス(S25)のサブルーチンを示すフローチャートである。
このLT生成プロセスのサブルーチンはLT生成可(S24でYES)の場合に行われ、このルーチンにおいては、LT生成部35は、先ず、LTのLT識別子、NetDRMバージョン番号及びLT暗号化法に規定の値をLTヘッダ81に設定する(S251)。次いで、LT生成部35は、生成するLTのサイズを計算し、計算により求められたLTサイズをLTヘッダ81に設定する(S252)。そして、LT生成部35は、UR−UsID、LT有効期間、LT移動許可フラグにUR−Usの値と同一のものを設定し、コンテンツIDにELIに記述されているものと同一のものを設定する(S253)。
そして、LT生成部35は、生成するLTを即時に消費するか否かを表すLT即時消費フラグを設定するLT即時消費フラグ設定プロセス(S254)、このLTでコンテンツ利用後サーバに自動的に返却するか否かを表すLT自動返却フラグを設定するLT自動返却フラグ設定プロセス(S255)を実行し、LTヘッダ81の生成を終える。
LTヘッダ81の生成が終わると、LT生成部35は、利用要求に合致したアクション毎のタグブロックを設定するアクションタグブロック設定プロセス(S256)を実行し、コンテンツに対応するコンテンツ鍵をコンテンツ鍵データベースから読み出して設定する(S257)。LT生成部35によるLTの生成が終わると、利用権利更新部37は、LTに切り出した分の利用条件を元の利用条件から減算し、UR−Usを減算結果に更新する(S258)。UR−Usの更新が終わると、このサブルーチンを終了し、図38に示されるメインルーチンにリターンする。これにより、利用条件管理サーバ3が管理するUR−Usから利用権を一部切り出したユーザのLT発行要求に合致したLTを送信することができる。
図42は、図41に示されるLT即時消費フラグ設定プロセス(S254)のサブルーチンを示すフローチャートである。
このLT即時消費フラグ設定プロセスのサブルーチンにおいては、LT生成部35は、先ずLT発行要求のELIヘッダ730に含まれるクライアント能力フラグ736を参照し、クライアントがセキュアなLTDBを持つか否か判断する(S2541)。セキュアなLTDBを持っている場合(S2541でYES)、LT生成部35は、UR−Usの有効期限が設定されているか否かを判断する(S2542)。有効期限が設定されている場合(S2542でYES)、LT生成部35はクライアントがセキュアな時計機能を持つか否か判断する(S2543)。
有効期限が設定されていない場合、即ち、期間限定がない場合(S2542でNO)と、有効期限が設定されている、即ち、期間限定があり(S2542でYES)、且つクライアントがセキュアな時計機構を持っている場合(S2543でYES)とのいずれかの場合、LT生成部35は、LT即時消費フラグをOFFに設定、即ちLTを即時に消費しなくてもよい旨を設定し(S2544)、このサブルーチンが終了し、図41に示されるサブルーチンにリターンする。
これに対して、クライアントがセキュアなLTデータベースを持っていない場合(S2541でNO)や、期間限定があり(S2542でYES)、且つクライアントがセキュアな時計機構を持っていない場合(S2543でNO)のいずれかの場合には、LT生成部35は、LT即時消費フラグをON、即ちLTを即時に消費すべき旨を設定し(S2545)、このサブルーチンが終了し、図41に示されるサブルーチンにリターンする。これにより、クライアントがセキュアなLTDBを持っているか否か、セキュアなクロック機構を持っているか否かのクライアント能力に応じてユーザ端末4においてLTを即時に消費させたり、保管させたりするといった制御をすることができる。
図43は、図41に示されるLT自動返却フラグ設定プロセス(S255)のサブルーチンを示すフローチャートである。
このLT自動返却フラグ設定プロセスのサブルーチンにおいては、LT生成部35は、UR−Usの同時利用可能数が有限か否か判断する(S2551)。判断の結果、同時利用可能数が有限である場合(S2551でYES)、LT生成部35は、LT自動返却フラグを「ON」に設定し(S2552)、このサブルーチンを終了し、図41に示されるサブルーチンにリターンする。これにより、ユーザ端末4がこのLTを用いてコンテンツを再生後、消費したLTをユーザ端末4から利用条件管理サーバ3に戻させてコンテンツの共同利用数の空きを作るといった制御を行うことができる。
これに対して、同時利用可能数が有限でない場合(S2551でNO)、具体的には同時利用可能数が「∞」である場合、LT生成部35は、LT自動返却フラグを「OFF」に設定し(S2553)、このサブルーチンを終了し、図41に示されるサブルーチンにリターンする。
図44は、図41に示されるアクションタグブロック設定プロセス(S256)のサブルーチンを示すフローチャートである。
このアクションタグブロック設定プロセスのサブルーチンにおいては、LT生成部35は、先ず最長利用時間、P条件にUR−Usと同一のものを設定し(S2561)、UR−Usの回数カウンタがLT発行要求のELIに含まれる期待値回数以上か否か判断する(S2562)。判断の結果、期待回数以上であれば(S2562でYES)、LT生成部35は、アクションタグブロックの回数カウンタにELIの期待値回数の値を設定し(S2563)、このサブルーチンを終了し、図41に示されるサブルーチンにリターンする。これにより、ユーザの要求通りの回数をLTに設定することができる。
これに対して、期待回数未満であれば(S2562でNO)、回数カウンタにUR−Usの回数カウンタの値、即ちUR−Usに残っている期待回数よりも少ない全回数を設定し(S2564)、このサブルーチンを終了し、図41に示されるサブルーチンにリターンする。これにより、ユーザの要求には足りないが、LT発行拒否フラグによる指示(OFF)通りの回数をLTに設定することができる。
このような図38〜図44に示される処理により適切なLT取得処理が実行される。
次いで、ユーザ端末4においてコンテンツを利用する場合、このユーザ端末4のクライアント41とレンダリングプラグイン42とで行われる処理(コンテンツ再生プロセス)及びクライアント41とストレージプラグイン43とで行われる処理(メディアへの書き出しプロセス)をこの順序で説明する。
図45は、クライアント41とレンダリングプラグイン42とで行われるコンテンツ再生プロセスを示すフローチャートである。
この再生プロセスは、図33に示される画面において、再生を希望するコンテンツ(例えば、コンテンツ波乗りジョージ)にカーソルを合わせPlayの再生操作ボタン908をクリックすることにより開始される。
このような再生操作ボタン908のクリックによるコンテンツ再生の指示があると、プラグイン制御部419Aは、ユーザが再生希望したコンテンツを対象としたLTがLTデータベース413Aにあるか否か判断する(S31)。なお、ここではセキュアなLTDB、即ちLTデータベース413Aを持ち、コンテンツ利用可否判定部418Aがセキュアなクロック機構を有する場合について説明する。
判断の結果、LTデータベース413Aに対象のLTが格納されている場合(S31でYES)、コンテンツ利用可否判定部418Aは、対象のLTでコンテンツを再生できるか否かを判定する再生可否判断プロセス(S34)を実行する。
これに対して、LTデータベース413Aに対象のLTがない場合には(S31でNO)、LT取得部415Aに指示し、上記と同じLT取得プロセス(S32)を実行させ、LTを取得できたか否か判断する(S33)。なお、この場合には、連続複数回再生の指定がされない限り、通常再生に必要な最小単位、1回のLT発行要求がなされる。そして、LTを取得できた場合(S33でYES)、コンテンツ利用可否判定部418Aは、再生可否判断プロセス(S34)を実行する。
再生可否判断プロセス(S34)の実行が終わると、プラグイン制御部419Aは、コンテンツ利用可否判定部418Aによる可否判断結果に基づいてそのLTで再生可か否か判断する(S35)。判断の結果、再生可の場合(S35でYES)、プラグイン制御部419Aは、LTに含まれるコンテンツ鍵とP条件(2ch再生等)をレンダリングプラグイン42へ渡す(S36)。
これに対して、LTを取得できなかった場合(S33でNO)や、再生不可と判断した場合(S35でNO)には、プラグイン制御部419Aは、コンテンツ再生処理を終了する。
一方、レンダリングプラグイン42の再生条件判定部421Aは、コンテンツ復号鍵とP条件を受信すると(S41)、P条件判断プロセス(レンダリング)を実行し(S42)、実行の結果に基づいて再生可か否か判断する(S43)。
判断の結果、再生可能であれば(S43でYES)、コンテンツ復号部422Aは、コンテンツデータベース412Aからコンテンツを取得し、取得したコンテンツをコンテンツ鍵で復号化する(S44)。そして、コンテンツ再生部423Aは、P条件で指定された条件で再生する(S45)。これに対して、再生可でなければ(S43でNO)、その旨をプラグイン制御部419Aに通知する。
レンダリングプラグイン42で再生が行われると、プラグイン制御部419Aはタイマを起動し、最長利用時間や、1回判定しきい値、累積利用時間による1回の管理を行い、プラグイン制御部419Aが1回とカウントすると、LT管理・更新部417Aは、LTの内容(回数)を更新し(S37)、コンテンツ再生処理を終了する。なお、再生時間の計測は、クライアントではなく、プラグイン側で行ってもよい。また、レンダリングプラグイン42で再生可でない場合(S43でNO)、LT管理・更新部417Aは、コンテンツ再生プロセスを終了する。
なお、コンテンツ再生プロセス終了の際、LT返却部416AはLTのLT状態フラグ(LT自動返却フラグ)815を参照し、LT自動返却フラグがONで、LTの権利が全て消費されていると、そのLTを通信部410Aを介して利用条件管理サーバ3に返却する。
図46は、LTを返却するためのLT返却要求95の構成例を示す図である。
このLT返却要求95は、この要求がLT返却要求であることを表すユニークな識別子、LT返却要求識別子951と、LTを返却するユーザ端末の端末ID952と、返却されるLT953とからなる。この要求を受け取った利用条件管理サーバ3のLT解析部36は、端末ID952に対応するUR−Usに戻し、そのUR−Usの回数や同時利用可能数を更新する。これによりLTを利用条件管理サーバ3にバックアップさせたり、発行状態LT数617を減らすことができる。発行状態LT数617を減らした場合には、他の端末でのコンテンツ共同利用が可能となる。
図47は、図45に示される再生可否判定プロセス((S34)のサブルーチンを示すフローチャートである。
この再生可否判定プロセスのサブルーチンにおいては、コンテンツ利用可否判定部418Aは、先ず、LTが有効期間内か否か判断する(S341)。有効期間内である場合(S341でYES)、コンテンツ利用可否判定部418Aは、ユーザが指定したアクションIDのアクションタグブロックがあるか否か判断する(S342)。判断の結果、アクションタグブロックがある場合(S342でYES)、コンテンツ利用可否判定部418Aは、そのアクションタグブロックの回数カウンタは「0」であるか否か判断する(S343)。回数カウンタが「0」でない場合(S343でNO)、コンテンツ利用可否判定部418Aは、再生可と判定し(S344)、この再生可否判定プロセスを終了し、図45に示されるメインルーチンにリターンする。
これに対して、有効期間外である場合(S341でNO)、ユーザが指定したアクションIDのアクションタグブロックがない場合(S342でNO)、回数カウンタが「0」である場合(S343でYES)の内のいずれかの場合、コンテンツ利用可否判定部418Aは、再生不可と判定し(S345)、この再生可否判定プロセスを終了し、図45に示されるメインルーチンにリターンする。
これにより、適切な再生可否を判定することができる。
図48は、図45に示されるP条件判定プロセス(レンダリング)(S42)のサブルーチンを示すフローチャートである。
このP条件判定プロセスのサブルーチンでは、再生条件判定部421Aは、P条件(例えば、モノラルで、アナログ出力で再生する。)を参照し、再生条件を判定する(S421)。判定の結果、P条件で指定された条件で再生できる場合(S422でYES)、再生条件判定部421Aは、再生可と判定し(S423)、このP条件判定プロセスを終了し、図45に示されるメインルーチンにリターンする。これにより、P条件に従う再生条件で、コンテンツの再生が行われる。
これに対して、P条件で指定された条件で再生できない場合(S422でNO)、再生条件判定部421Aは、再生不可と判定し(S424)、このP条件判定プロセスを終了し、図45に示されるメインルーチンにリターンする。
このような図45〜図48の処理により、適切なコンテンツ再生プロセスが実行される。
次いで、クライアント41とストレージプラグイン43とで行われる処理(メディアへの書き出しプロセス)を説明する。
図49は、クライアント41とストレージプラグイン43とで行われるコンテンツ書き出し処理を示すフローチャートである。
このコンテンツ書き出し処理は、図33に示される画面の移動タブを選択し、この移動タブを選択した場合にコンテンツ再生ボックス903中に表示される移動元と移動先とを表す画面(図示せず)において、移動元については書き出し処理が許容され、書き出し処理(移動)を希望するコンテンツ(図示せず)を選択し、移動先については所望の外部メディアを選択し、書き出しボタン(図示せず)をクリックすることにより開始される。
このような書き出しボタンのクリックによるコンテンツ書き出し指示があると、プラグイン制御部419Aは、ユーザが書き出し希望したコンテンツを対象としたLTがLTデータベース413Aにあるか否か判断する(S51)。なお、ここでは、上記再生処理の場合と同様に、セキュアなLTDB、即ちLTデータベース413Aを持ち、コンテンツ利用可否判定部418Aがセキュアなクロック機構を有する場合について説明する。
判断の結果、LTデータベース413Aに対象のLTが格納されている場合(S51でYES)、コンテンツ利用可否判定部418Aは、対象のLTを書き出しできるか否かを判定する書き出し可否判断プロセス(S54)を実行する。
これに対して、LTデータベース413Aに対象のLTがない場合には(S51でNO)、プラグイン制御部419Aは、LT取得部415Aに指示し、上記と同じ内容のLT取得プロセス(S52)を実行させ、LTを取得できたか否か判断する(S53)。そして、LTデータベース413AにLTがあった場合(S51でYES)、あるいはLTを取得できた場合(S53でYES)、コンテンツ利用可否判定部418Aは、書き出し可否判断プロセス(S54)を実行する。
書き出し可否判断プロセス(S54)の実行が終わると、プラグイン制御部419Aは、コンテンツ利用可否判定部418Aによる可否判断プロセスの結果の基づいて、そのLTで書き出し可か否か判断する(S55)。判断の結果、書き出し可の場合(S55でYES)、プラグイン制御部419Aは、対象のLTをストレージプラグイン43へ渡す(S56)。
これに対して、LTを取得できなかった場合(S53でNO)や、書き出し不可と判断した場合(S55でNO)、プラグイン制御部419Aは、コンテンツ書き出し処理を終了する。
一方、ストレージプラグイン43の書き出し条件判定部431Aは、LTを受信すると(S61)、P条件判断プロセス(ストレージ)を実行し(S62)、実行の結果に基づいて書き出し可か否か判断する(S63)。判断の結果、書き出し可能であれば(S63でYES)、書き込み用データ生成部432Aは、コンテンツデータベース412Aからコンテンツを取得し(S64)、取得したコンテンツをメディア用コンテンツフォーマットに変換する(S65)。次いで、書き込み用データ生成部432Aは、LTに含まれる利用権利をメディア用利用権利フォーマットに変換する(S66)。そして、フォーマット変換が終わると、書き込み用データ生成部432Aは、フォーマット変換されたコンテンツと利用権利とをP条件で指定された条件で外部メディアに書き込む(S67)。これに対して、書き出し可でなければ(S63でNO)、その旨をプラグイン制御部419Aに通知する。
ストレージプラグイン43による書き込み処理が終わると、LT管理・更新部418は、LTを削除し(S57)、書き出し処理を終了する。また、ストレージプラグイン43で書き出し不可である場合(S63でNO)、プラグイン制御部419Aは、コンテンツ書き出し処理を終了する。
図50は、図49に示される書き出し可否判定プロセス(S54)のサブルーチンを示すフローチャートである。
この再生可否判定プロセスのサブルーチンにおいては、コンテンツ利用可否判定部418Aは、先ず、LTが有効期間内か否か判断する(S541)。有効期間内である場合(S541でYES)、コンテンツ利用可否判定部418Aは、ユーザが指定したLTのLT移動許可フラグがONか否か判断する(S542)。判断の結果、LT移動許可フラグがONである場合(S542でYES)、コンテンツ利用可否判定部418Aは、書き出し可と判定し(S543)、この再生可否判定プロセスを終了し、図49に示されるメインルーチンにリターンする。
これに対して、有効期間内でない場合(S541でNO)や、LT移動許可フラグがONでない場合(S542でNO)、コンテンツ利用可否判定部418Aは、書き出し不可と判定し(S544)、この再生可否判定プロセスを終了し、図49に示されるメインルーチンにリターンする。
これにより、適切な書き出し可否を判定することができる。
図51は、図49に示されるP条件判定プロセス(ストレージ)(S62)のサブルーチンを示すフローチャートである。
このP条件判定プロセスのサブルーチンでは、書き出し条件判定部431Aは、先ず、P条件(例えば、SDカードに書き出そうとしている場合、SDカード用のP条件がある。)を参照し、書き出そうとしているメディアに対するP条件があるかを判定する(S621)。P条件がある場合(S622でYES)、書き出し条件判定部431Aは、P条件(例えば、プロテクトされたデジタル出力)で指定された出力インタフェースあるか否か判断する(S623)。判断の結果、指定された出力インタフェースがある場合(S623でYES)、書き出し条件判定部431Aは、LTに含まれる利用権利がメディア用の利用権利に変換できるか否か判断する(S624)。例えば、外部メディアでは∞しかサポートしていないような場合に、LT内の権利が有限回である場合、それは書き出し不可と判断される。利用権を変換できる場合(S624でYES)、書き出し条件判定部431Aは、コンテンツを、メディア用のコンテンツフォーマットに変換できるか否か判断する(S625)。
コンテンツをフォーマット変換できる場合(S625でYES)、書き出し条件判定部431Aは、書き出し可と判定し(S626)、このP条件判定プロセスを終了し、図49に示されるメインルーチンにリターンする。これに対して、P条件がない場合(S622でNO)や、P条件で指定された出力インタフェースがない場合(S623でNO)、利用条件をメディア用の利用権利に変換できない場合(S624でNO)、コンテンツをメディア用のコンテンツフォーマットに変換できない場合(S625でNO)、書き出し条件判定部431Aは、書き出し不可と判定し(S627)、このP条件判定プロセスを終了し、図49に示されるメインルーチンにリターンする。
このような図49〜図51の処理により、適切なコンテンツ書き出し処理を行うことができる。
なお、この実施の形態4では、LT発行要求70において、クライアント能力を知らせるようにしたが、この変形例として、ユーザ端末の購入時などの際にユーザ情報データベースにクライアント能力を予め登録しておいて、LT発行要求があった場合にユーザ情報データベースに予め登録されたクライアント能力を用いてLT即時消費フラグを設定してもよい。
また、サーバとのアクセス時にSACを形成し、このSAC形成の際にユーザ端末の端末IDとクライアント能力等とを記載した証明書をサーバに送信し、LT発行要求があった場合に証明書に記載されたクライアント能力を用いてLT即時消費フラグを設定してもよい。
さらに、この実施の形態4では、コンテンツはコンテンツ配信サーバから配信を行ったが、利用条件管理サーバから行ってもよい。つまり、コンテンツ配信サーバと利用条件管理サーバは同一であってもよい。