(57)【要約】【課題】サーバーにコンテンツのダウンロードのアクセスが集中する場合に、平準化を図り、できるだけ早い時期にユーザに効率よくダウンロードできる方法を提供する。【解決手段】人気のあるコンテンツを販売またはレンタルする場合は、販売開始日またはレンタル開始日より前に予約を受け付ける。予約の件数が所定の件数を上回れば、販売開始日またはレンタル開始日より前に、コンテンツ本体を暗号化して端末装置（記録機能付きテレビ）に送信する。そして、販売開始日またはレンタル開始日に、コンテンツを復号化する鍵を送信する。端末装置は、鍵が到着して初めてコンテンツを視聴できる。これにより、サーバーへの負荷を軽減しユーザの要求を満足させることができる。【選択図】図１３
2008134992.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
要求されたコンテンツをダウンロードするのに要する時間を予測し、
同一端末装置に対して複数のコンテンツを同時にダウンロードすることのないようにコンテンツ毎にダウンロードする日時を設定することを特徴とするコンテンツダウンロード方法。
【請求項２】
請求項１に記載のコンテンツダウンロード方法において、
コンテンツをダウンロードする際の送信速度について、前記端末装置毎に、また時間帯別に記憶しておき、
該記憶している送信速度のデータを参照して、各コンテンツ毎にダウンロードするのに要する時間を予測しダウンロードする日時を設定することを特徴とするコンテンツダウンロード方法。
【請求項３】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
要求されたコンテンツの販売日またはレンタル開始日よりも前に、上記コンテンツを所定の鍵で暗号化して上記端末装置に対し事前にダウンロードし、
上記コンテンツの販売日またはレンタル開始日に、上記暗号化されたコンテンツを復号化するための上記鍵を上記端末装置へ送信することを特徴とするコンテンツダウンロード方法。
【請求項４】
請求項３に記載のコンテンツダウンロード方法において、
前記送信装置は前記端末装置に対し、前記コンテンツをその販売日またはレンタル開始日よりも前に暗号化して事前にダウンロードすることがあることを通知し、
前記送信装置は、販売日前またはレンタル開始日前のコンテンツに対する要求件数が所定の件数以上に達した場合に、当該コンテンツに対して前記事前のダウンロードを行うことを特徴とするコンテンツダウンロード方法。
【請求項５】
請求項３に記載のコンテンツダウンロード方法において、
前記端末装置では、前記鍵を受信するまで前記事前にダウンロードしたコンテンツを視聴できず、
前記端末装置のユーザには、前記コンテンツを事前にダウンロードしたことも隠匿しておくことを特徴とするコンテンツダウンロード方法。
【請求項６】
請求項３に記載のコンテンツダウンロード方法において、
前記端末装置では、前記鍵を受信するまで前記事前にダウンロードしたコンテンツを視聴できず、
前記端末装置のユーザには、前記コンテンツを事前にダウンロードしたことは知らせるが鍵がないので視聴できないことを示すことを特徴とするコンテンツダウンロード方法。
【請求項７】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
上記送信装置に蓄積しているコンテンツを上記端末装置を介してユーザに一覧表示を行う際、
視聴制限のあるコンテンツに関しては、その条件に適合したユーザにだけ表示することを特徴とするコンテンツダウンロード方法。
【請求項８】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
上記コンテンツに視聴する有効期限が設定されている場合、上記端末装置は、あるいは上記送信装置は上記端末装置をして、該端末装置にダウンロードし有効期限が経過したコンテンツを消去することを特徴とするコンテンツダウンロード方法。
【請求項９】
請求項８に記載のコンテンツダウンロード方法において、
前記送信装置は前記端末装置に対し、有効期限が設定されたコンテンツについては有効期限が経過したら消去することを予告し、
ユーザがこれを承認した場合に、前記送信装置は上記コンテンツを前記端末装置にダウンロードすることを特徴とするコンテンツダウンロード方法。
【請求項１０】
請求項８に記載のコンテンツダウンロード方法において、
前記端末装置にダウンロードしていたコンテンツを消去した場合、該端末装置にて、当該コンテンツを消去したことをユーザに通知することを特徴とするコンテンツダウンロード方法。
【請求項１１】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
上記コンテンツに視聴する有効期限が設定されている場合、上記送信装置は、所定の時間が経過したら受信したコンテンツを消去する機能を有する端末装置にだけ上記コンテンツをダウンロードすることを特徴とするコンテンツダウンロード方法。
【請求項１２】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
上記端末装置にてダウンロードしたコンテンツは暗号化されており、それを復号化する鍵が存在する場合、
該コンテンツを視聴する有効期限が経過したら、上記コンテンツは消去せずに上記鍵だけを消去または無効にして、有効期限が経過した旨を上記端末装置に表示し、
ユーザが上記コンテンツの再視聴を要求した場合は、上記送信装置は上記端末装置に上記鍵だけを送信することを特徴とするコンテンツダウンロード方法。
【請求項１３】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
ダウンロード中のコンテンツを上記端末装置が録画しながら該コンテンツの先頭から再生する追っかけ再生を行う場合、
再生途中で録画中の画面に追いつく可能性がある場合には、上記端末装置にその旨を表示するかまたは、追っかけ再生のメニューを非表示にすることを特徴とするコンテンツダウンロード方法。
【請求項１４】
放送番組を受信する放送受信部と、
ネットワークを介して送信装置と通信しコンテンツを受信する通信送受信部と、
該通信送受信部を介して上記送信装置へコンテンツのダウンロードを要求するコンテンツ要求部と、
受信した放送番組およびコンテンツを記録媒体に蓄積する蓄積部と、
上記コンテンツを復号化処理する復号部と、
上記放送受信部と上記通信送受信部を制御する制御部とを備え、
上記コンテンツ要求部は上記送信装置に対し、コンテンツの視聴可能日時よりも前に当該コンテンツのダウンロードを要求し、
上記通信送受信部は上記送信装置から、上記視聴可能日時よりも前に暗号化された該コンテンツを受信して上記蓄積部に蓄積し、
上記通信送受信部は上記送信装置から、上記視聴可能日時以後に上記受信したコンテンツを復号化するための鍵を取得し、
上記復号部は取得した上記鍵を用いて上記蓄積部に蓄積したコンテンツを復号化し、該コンテンツを視聴することを特徴とする端末装置。
【請求項１５】
請求項１４記載の端末装置であって、
前記放送受信部および前記通信送受信部にて受信した放送番組およびコンテンツを表示する表示部を有し、
前記制御部は、前記放送受信部で受信した放送番組を上記表示部に表示しているとき、前記通信送受信部で前記送信装置から受信したコンテンツを前記蓄積部に蓄積させることを特徴とする端末装置。
【請求項１６】
放送番組を受信する放送受信部と、
ネットワークを介して送信装置と通信しコンテンツを受信する通信送受信部と、
該通信送受信部を介して上記送信装置へコンテンツのダウンロードを要求するコンテンツ要求部と、
受信した放送番組およびコンテンツを記録媒体に蓄積する蓄積部と、
放送番組の暗号化および復号化処理する放送用暗号復号部と、
コンテンツの暗号化および復号化処理する通信用暗号復号部と、
上記放送受信部と上記通信送受信部を制御する制御部とを備え、
上記放送受信部で受信した放送番組と上記通信送受信部で受信したコンテンツは、それぞれ上記放送用暗号復号部と上記通信用暗号復号部にて当該端末装置独自の暗号方式に変換して上記蓄積部に蓄積し、
該蓄積部に蓄積した放送番組とコンテンツを、それぞれ上記放送用暗号復号部と上記通信用暗号復号部にて復号化して、該放送番組と該コンテンツを視聴することを特徴とする端末装置。
【請求項１７】
放送番組を受信する放送受信部と、
ネットワークを介して送信装置と通信しコンテンツを受信する通信送受信部と、
該通信送受信部を介して上記送信装置へコンテンツのダウンロードを要求するコンテンツ要求部と、
受信した放送番組およびコンテンツを記録媒体に蓄積する蓄積部と、
放送番組の暗号化および復号化処理する放送用暗号復号部と
コンテンツを復号化処理する通信用復号部と、
上記放送受信部と上記通信送受信部を制御する制御部とを備え、
上記放送受信部で受信した放送番組は、上記放送用暗号復号部にて上記通信送受信部で受信したコンテンツと同一の暗号化方式に変換して上記蓄積部に蓄積し、
該蓄積部に蓄積した放送番組とコンテンツを、それぞれ上記放送用暗号復号部と上記通信用復号部にて復号化して、該放送番組と該コンテンツを視聴することを特徴とする端末装置。
【請求項１８】
コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、
上記コンテンツに視聴する有効期限が設定されている場合、上記端末装置は、あるいは上記送信装置は上記端末装置を制御して、該端末装置にダウンロードし有効期限が経過したコンテンツを消去することを特徴とするコンテンツダウンロード方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像、音楽等のコンテンツをサーバーから端末装置に効率良くダウンロードを実行するダウンロード方法及び端末装置に関する。
【背景技術】
【０００２】
映像、音楽等のコンテンツを、放送波やネットワークを使って端末装置へ配信するコンテンツ配信技術が進んでいる。現在はリアルタイムで表示するストリーミング（記憶装置に記録しない）が中心である。しかし、ネットワークが混みあっている場合、映像が乱れることがあり、記憶装置に一旦記録（以下、ダウンロード）した後に表示すれば品質は維持できる。その際、ダウンロードを効率的に行うために、次のような提案がなされている。
【０００３】
特許文献１では、テストファイルのダウンロード速度を計測し、完了するまでの時間を予測し、ユーザが所望する時刻にダウンロードが完了するための開始日時を設定し、ユーザの了解を得て、予約をする方法が述べられている。ユーザが了解しない場合は、代替案のダウンロード開始日時を提示する。また、ダウンロード状況を監視し、約束した完了時刻までに終わりそうにない場合は、他のサーバーに切替える、等の方法も述べられている。特許文献２では、ダウンロード予約時間帯を分割して、端末に割り当てて負荷を分散させる方法が述べられている。
【０００４】
【特許文献１】特開２００３−６７２８０号公報
【特許文献２】特開２００４−１８５１１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ユーザがコンテンツのダウンロードを要求する際、人気のあるコンテンツのレンタル開始直後にアクセスが集中し、サーバーが機能しない可能性が起こりうる。
【０００６】
上記特許文献１、２では、いずれの場合もすでに販売中のコンテンツを対象にしており、人気があるコンテンツの販売開始直後にアクセスが集中することは考慮されていない。もし、このような場合を想定すると、特許文献１では、ユーザの希望するダウンロード完了時刻に対して、予約不可の回答が続出すると考えられる。特許文献２では、端末に割り当てられる日時が、ユーザがダウンロードを希望してから何日も経過した日時が割り当てられると考えられる。
【０００７】
また、コンテンツの著作権保護のため、価値のあるコンテンツについてはコンテンツ提供者（以下、コンテンツプロバイダ）の権限でダウンロードを実施する際に制限をかける場合が多い。
【０００８】
本発明の目的は、サーバーにアクセスが集中することが予想される場合に、平準化を図り、できるだけ早い時期にユーザに効率よくダウンロードできる方法を提供することである。そして、コンテンツプロバイダが安心してコンテンツを供給できる方法を提供することである。
【課題を解決するための手段】
【０００９】
本発明では、コンテンツを蓄積する送信装置が、端末装置から要求されたコンテンツをネットワークを介してダウンロードするコンテンツダウンロード方法において、要求されたコンテンツをダウンロードするのに要する時間を予測し、同一端末装置に対して複数のコンテンツを同時にダウンロードすることのないようにコンテンツ毎にダウンロードする日時を設定する
本発明では、要求されたコンテンツの販売日またはレンタル開始日よりも前に、上記コンテンツを所定の鍵で暗号化して上記端末装置に対し事前にダウンロードし、上記コンテンツの販売日またはレンタル開始日に、上記暗号化されたコンテンツを復号化するための上記鍵を上記端末装置へ送信する。
【００１０】
本発明では、上記送信装置に蓄積しているコンテンツを上記端末装置を介してユーザに一覧表示を行う際、視聴制限のあるコンテンツに関しては、その条件に適合したユーザにだけ表示する。
【００１１】
本発明では、上記コンテンツに視聴する有効期限が設定されている場合、上記端末装置は、あるいは上記送信装置は上記端末装置をして、該端末装置にダウンロードし有効期限が経過したコンテンツを消去する。
【００１２】
本発明では、上記コンテンツに視聴する有効期限が設定されている場合、上記送信装置は、所定の時間が経過したら受信したコンテンツを消去する機能を有する端末装置にだけ上記コンテンツをダウンロードする。
【００１３】
本発明では、上記端末装置にてダウンロードしたコンテンツは暗号化されており、それを復号化する鍵が存在する場合、該コンテンツを視聴する有効期限が経過したら、上記コンテンツは消去せずに上記鍵だけを消去または無効にして、有効期限が経過した旨を上記端末装置に表示し、ユーザが上記コンテンツの再視聴を要求した場合は、上記送信装置は上記端末装置に上記鍵だけを送信する。
【００１４】
本発明では、ダウンロード中のコンテンツを上記端末装置が録画しながら該コンテンツの先頭から再生する追っかけ再生を行う場合、再生途中で録画中の画面に追いつく可能性がある場合には、上記端末装置にその旨を表示する。
【００１５】
本発明の端末装置は、放送番組を受信する放送受信部と、ネットワークを介して送信装置と通信しコンテンツを受信する通信送受信部と、該通信送受信部を介して上記送信装置へコンテンツのダウンロードを要求するコンテンツ要求部と、受信した放送番組およびコンテンツを記録媒体に蓄積する蓄積部と、コンテンツを復号化処理する復号部と、上記放送受信部と上記通信送受信部を制御する制御部とを備え、上記コンテンツ要求部は上記送信装置に対し、コンテンツの視聴可能日時よりも前に当該コンテンツのダウンロードを要求し、上記通信送受信部は上記送信装置から、上記視聴可能日時よりも前に暗号化された該コンテンツを受信して上記蓄積部に蓄積し、上記通信送受信部は上記送信装置から、上記視聴可能日時以後に上記受信したコンテンツを復号化するための鍵を取得し、上記復号部は取得した上記鍵を用いて上記蓄積部に蓄積したコンテンツを復号化し、該コンテンツを視聴する。
【発明の効果】
【００１６】
本発明によれば、ユーザの要求する視聴日時を満足させるとともに、ダウンロード時のサーバーへの負荷を軽減する効果がある。また、配信するコンテンツの著作権や視聴制限を遵守することができる。
【発明を実施するための最良の形態】
【００１７】
本発明の実施の形態について、図面を用いて説明する。
図１は、本発明が対象とするコンテンツダウンロードシステムの構成例を示す図である。
【００１８】
コンテンツプロバイダはユーザからの要求を受けると、送信装置（サーバー）１を用いて、ネットワーク３を介して各ユーザの端末装置２へコンテンツを配信する。ここで、コンテンツを受信して記録する端末装置は、記録機能付きテレビ（例えばハードディスク内蔵テレビ）や記録装置（ハードディスクレコーダ）等が相当する。記録装置の場合、表示装置（一般的にはテレビ）と接続されており、記録装置へのユーザの入力は、テレビを見ながら入力することが可能である。どちらの形態でも実施可能であるが、以下の実施例では端末装置として記録機能付きテレビ（単にテレビと称する）を前提とする。
【００１９】
サーバー１にはコンテンツ本体とダウンロードするテレビを管理するデータが存在する。家庭内等に設置されているテレビ２はイーサーネット（登録商標）等のネットワーク端子を有し、ＰＣと同様、ルータを介してインターネット３等の回線に接続し、プロバイダの所有するサーバーと接続される。家庭内に複数のテレビを所有している場合でも、各テレビを個別に識別してコンテンツを配信する。ここでテレビ２は、アンテナで放送波を受信して、放送番組を視聴できることは言うまでもない。
【００２０】
なお、本明細書では蓄積と格納を以下のように使い分ける。蓄積とは、実体のないもの、実体として目に見えないものを記録することを言う。または個々のデータとしては重要な意味はなく、データ全体として意味のあるものを記録する場合を蓄積と言う。格納とは、実体のあるもの、実体として目にすることができるものを記録することを言う。または個々のデータに重要な意味があるものを記録する場合を格納と言う。実体として目に見えない「コンテンツ」は蓄積し、目に見える「鍵」や「ファイル」、個々のデータに重要な意味がある「データ」は格納する、と表現する。
【００２１】
図２は、コンテンツを送信する送信装置（サーバー）のブロック構成例を示す図である。
【００２２】
コンテンツ蓄積部１１は、ユーザに提供する各種の映像・音声等のコンテンツを蓄積している。管理ファイル部１２は、ユーザの端末（テレビ）の情報を格納し、端末別にダウンロードの予約・実行の管理を行うためのデータを保存する。サーバーから端末に送信するコンテンツは、著作権保護のため暗号化処理を行い送信するものとする。通信用鍵作成部１３は、送信のための暗号化鍵を作成し、通信用鍵管理部１４は作成した鍵を格納する。機器認証部１５はコンテンツを要求した端末装置との間で認証処理を行う。認証が成功した場合、暗号処理部１６は通信用鍵管理部１４で格納している鍵を用いてコンテンツを暗号化する。制御部１７は、サーバー全体を制御するとともに、通信送受信部１８を介して端末からのダウンロード要求を受付け、端末毎にダウンロードの計画を立てる。特に、ユーザからのアクセスが集中した場合には、これを分散させるように調整する。そして、ユーザから要求されたコンテンツをコンテンツ蓄積部１１から読み出し、予約した時間になったら暗号化して通信送受信部１８から相手の端末装置に送信する。
【００２３】
図３は、コンテンツを受信して蓄積し、ユーザがこれを視聴する端末装置（テレビ一体型受信装置）のブロック構成例を示す図である。
【００２４】
本実施例の端末装置（テレビ）は、ネットワーク３を介してサーバー１と通信しコンテンツの受信を行う通信送受信部２１と、放送波で送られたコンテンツを受信する放送受信部２２の２系統とを備える。制御部２３は入力切替部３２により受信する信号を切り替え、受信したコンテンツを共通の蓄積部（ハードディスク、ＨＤＤ）３１に蓄積するとともに、蓄積したコンテンツを読み出し表示部３３にて表示（視聴）させる。
【００２５】
コンテンツ要求部２４は、サーバーに対してコンテンツのダウンロードを要求する。その際、サーバーからコンテンツリストを受信して表示部３３に表示し、ユーザは所望のコンテンツを選択しダウンロード希望日時等を入力する。通信送受信部２１で受信するコンテンツは暗号化されており、通信用復号部２５はサーバーから支給される鍵にて平文に復号化する。また、通信用暗号部２６は、復号化したコンテンツを再度別の方式で暗号化してハードディスク３１に蓄積する。通信用鍵管理部２７は、サーバーから支給された鍵を保存する。制御部２３はこれらの暗号化、復号化処理を制御するとともに、受信したコンテンツの視聴制限に基づき表示部３３での表示を制限し、また視聴有効期限を過ぎたコンテンツについては消去させる。
【００２６】
放送受信部２２で受信したコンテンツ（デジタル放送）は暗号化されており、放送用復号部２８はこれを平文に復号化する。また、放送用暗号部２９は、復号化したコンテンツを再度別の方式で暗号化してハードディスク３１に蓄積する。放送用鍵管理部３０は復号化用の鍵を保存する。
【００２７】
デジタル放送を受信、蓄積できるＰＣでは、放送波からのデータ（ファイル形式１）と通信からダウンロードやＰＣで作成したデータ（ファイル形式２）を有している。ファイル形式１では、著作権保護のためユーザにコピーされないようにファイルとしては見えない仕組みになっている。一方、ファイル形式２ではユーザがコピー、編集ができるようなファイルシステムを構築している。異なるファイルシステムを１つのハードディスク内で構築しなければならないため、パーティッションをきる、等の方法で２つの領域を区別する必要がある。その結果、ファイル形式１の領域が一杯になった場合、ファイル形式２の領域が空いていても、ファイル形式１のファイルはそのハードディスクに格納できない、という問題があった。
【００２８】
これに対して本発明では、放送波からのデータと通信からダウンロードしたデータの著作権を守りながら、ファイル形式によって、ハードディスク領域の格納場所を２つに分けることなく、効率的にハードディスクを利用できる方法を述べる。
【００２９】
放送波の視聴を制限する技術として、Ｂ−ＣＡＳ、通信を介してダウンロードされるデジタルデータの著作権保護技術として、ＤＲＭ（Ｄｉｇｉｔａｌ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ）がある。図４から図６、及び図２７〜図２９ではＢ−ＣＡＳ、ＤＲＭを用いた記録方法について述べる。図４と図２７は放送波とダウンロードしたデータを別々の暗号で蓄積する方法、図５と図２８は機器特有のローカル暗号で統一した蓄積方法、図６と図２９はダウンロードに適用されるＤＲＭ暗号で統一した蓄積方法である。なお、図４〜図６、図２７〜図２９で「１次格納媒体（ＨＤＤ）」とあるのは、「１次格納媒体（ＨＤＤ）を有する装置」を意味する。
【００３０】
図４では放送波で送られてきたデータを復号部でいったん平文にした後、暗号部で機器独自のローカル暗号にて機器内のハードディスクに蓄積する。一方、通信でダウンロードしたデータはそのままＤＲＭ暗号として機器内のハードディスクに蓄積する。表示するときは、放送波はローカル暗号で蓄積したデータを復号部で平文にし、通信からのＤＲＭ暗号を復号部で平文にして表示する。２次格納媒体に蓄積する場合は、いったん復号部で平文にした後、２次格納媒体に送り、その媒体に付随する暗号（ＣＰＲＭ、ＳＡＦＩＡ）で暗号化して蓄積する。
【００３１】
または図２７に示すように、２次格納媒体に送る前にその媒体に付随する暗号（ＣＰＲＭ、ＳＡＦＩＡ）で暗号化してから送る方法もある。
【００３２】
これを図３を使って説明する。暗号化された放送波は放送受信部２２で受信し、放送用復号部２８で平文にした後、放送用暗号部２９でローカル暗号化してハードディスク３１に蓄積する。通信送受信部２１で受信したデータは暗号がかかった状態でハードディスク３１に蓄積する。表示するときは、ローカル暗号化された放送波は放送用復号部２８で平文にして、通信からのデータは通信用復号部２６で平文にして表示する。
【００３３】
図５及び図２８では、放送波で送られてきたデータも通信でダウンロードしたデータも復号部でいったん平文にした後、暗号部で機器独自のローカル暗号に変換して、機器内のハードディスクに蓄積する。表示するときは、どちらも復号部でローカル暗号から平文にして表示する。２次格納媒体への格納する場合は、図４及び図２７と同じ処理を実施する。
【００３４】
これを図３を使って説明する。暗号化された放送波は放送受信部２２で受信し、放送用復号部２８で平文にした後、放送用暗号部２９でローカル暗号化してハードディスク３１に蓄積する。通信送受信部２１で受信したデータも、通信用復号部２５で平文にした後、通信用暗号部２６でローカル暗号化してハードディスク３１に蓄積する。表示するときは、放送用復号部２８、通信用復号部２５でローカル暗号から平文にして表示する。
【００３５】
図６及び図２９では、放送波で送られてきたデータも通信でダウンロードしたデータもダウンロードに適用されるＤＲＭ暗号に統一する。放送波のデータは復号部でいったん平文にした後、暗号部でＤＲＭ暗号にしてハードディスクに格納される。通信でダウンロードしたデータはそのままの形式で蓄積する。表示するときは、どちらも復号部で平文にして表示する。２次格納媒体への格納する場合は、図４及び図２７と同じ処理を実施する。
【００３６】
これを図３を使って説明する。暗号化された放送波は放送受信部２２で受信し、放送用復号部２８で平文にした後、放送用暗号部２９でＤＲＭ暗号にしてハードディスク３１に蓄積する。通信送受信部２１で受信したデータはＤＲＭ暗号のまま、ハードディスク３１に蓄積する。表示するときは、放送用復号部２８、通信用復号部２５でＤＲＭ暗号から平文にして表示する。
【００３７】
図４〜６、及び図２７〜２９で直接記録と示した。これは、通信からのデータを１次格納媒体に蓄積することなく直接２次格納媒体に蓄積することを意味する。図４〜６の場合は、復号したデータを直接２次格納媒体に送り、そこでその媒体に付随する暗号で暗号化して蓄積する。図２７〜２９の場合は、復号したデータを２次格納媒体に送る前にその媒体に付随する暗号で暗号化して２次格納媒体に送って蓄積する。
【００３８】
図７は上記３種の暗号方法毎に、蓄積、表示時に復号部、暗号部でどういう変換を行うかをまとめたテーブルである。ローカルとはローカル暗号のことである。
【００３９】
放送波からのデータ、通信からのダウンロードには著作権フリーなデータも存在する。個人のビデオカメラで撮影したデータの著作権はユーザ個人にある。図４から図７まではデータは暗号化されていることを前提に説明したが、実際には、暗号化されたデータと暗号化されていないデータが混在する。データを解読する際に、暗号化されているか否かを判断し、暗号化されていなければ復号部、暗号部を利用せず、暗号化されていれば、どの暗号かを解読し、それに適合した復号部を利用することは言うまでもない。暗号化する場合も、どの暗号にするのか制御部の指示によって、それに適合した暗号部で暗号化することは言うまでもない。ひとつの暗号方法だけに対応したテレビであれば、各復号部、暗号部は１とおりの機能でよいが、複数の暗号方法に対応するテレビでは、複数の復号部、暗号部を有することになる。本実施例によって、放送波からのデータ、通信からダウンロードした暗号化されたデータを著作権を守りながら、また著作権フリー等で暗号化されていないデータもファイル形式は違うものの同一のファイルシステムで構築し、ハードディスクの格納場所を分割することなく記録することが可能となる。したがって、同一のハードディスクの領域に混在して格納することができるので、ハードディスクの領域を効率的に利用することができる。
【実施例１】
【００４０】
実施例１では、サーバーとテレビが連携して、コンテンツをダウンロードする方法について述べる。
【００４１】
図８は、サーバーが所有する端末別ダウンロード管理テーブルの一例を示す図である。サーバーに接続してきた端末（テレビ）がいつどんなコンテンツをダウンロードしたか、等を管理するためのデータを格納している。機器ＩＤとはテレビを識別するＩＤである。コード体系として、「メーカーコード」＋「機種を示すコード」＋「連番」、等考えられる。この例では、２桁が「メーカーコード」、次の３桁が「機種コード」、次の５桁がその機種内での「連番」を示している。消去可能機器とは、「１」が消去する機能がある機器、「０」は消去する機能がない機器であることを示している。なおサーバーでは、「メーカーコード」＋「機種コード」を参照して、そのテレビはユーザが操作しなくてもコンテンツを自動的に消去する機能があるか否か、を示した機種別消去機能有無テーブル（図示せず）を有しており、それを参照して、上記消去可能機器に「１」か「０」を設定する。強制消去フラグ＝「１」は、そのコンテンツは有効期限が来れば、強制的に消去する必要があることを示している。消去済みフラグ＝「１」は、端末で消去したことを端末側から報告があったことを示している。
【００４２】
例えば、機器ＩＤが「００−１２３−１０１３１」の端末は、機種別消去機能有無テーブルからコンテンツを消去する機能を有していると判断し、強制消去フラグ＝「１」のコンテンツのダウンロード（ＤＬ）を許可し、「９月１日１時」からコンテンツＩＤ＝「０００３８」のコンテンツをダウンロード開始し、「同日３時」に終了した。その有効期限は「９月４日の３時」、そのコンテンツ容量は４ＧＢであることを示している。機器ＩＤ＝「０１−０３０−１０２５１」の端末は、機種別消去機能有無テーブルからコンテンツを自動的に消去する機能がないと判断し、消去可能機器＝「０」を設定した。コンテンツＩＤ＝「０３００１」は強制消去フラグ＝「０」であることから、強制的に消去する必要がないので、ダウンロードを許可し、「９月２日２時」から「同日４時」までダウンロードを実施した。また、このコンテンツには有効期限がないので、「９９．９９．９９：９９」と設定したことを示している。言い換えれば、機器ＩＤ＝「０１−０３０−１０２５１」の端末は「０１−０３０」から機種別消去機能有無テーブルを参照し、コンテンツを自動的に消去する機能がないことが分かるので、消去可能機器＝「０」を設定し、例えばコンテンツＩＤ＝「０００３８」は強制消去フラグ＝１であることから、この端末にはこのコンテンツのダウンロードを許可しない、ということである。
【００４３】
図９は、端末別時間帯別のダウンロード実績の一例を示す図である。ここでの数値は、端末別に１メガバイト（ＭＢ）をダウンロードするに要する時間（秒）、すなわち伝送能力を示す。伝送能力は時間帯で異なり、平日の昼間（例えば、９時から１８時）、平日夜間（１８時から翌日９時）、休日昼間、休日夜間別に記憶しておく。このデータは、次回ダウンロードの要請がテレビからあった場合に、ダウンロードが終了する時刻を予測するために用いる。初期値としては、種々の環境で実験し、その平均値を設定しておけばよい。なお、図９のテーブルはサーバー側でなく、テレビ側で所有してもよい。
【００４４】
図１０は、サーバーが所有するダウンロード予約管理テーブルの一例を示す図である。Ｎｏ．１〜３は、図中に示した日時にダウンロードを実施し、正常に終了したことを示している。Ｎｏ．４は、「９月６日の２時」からダウンロードを開始したが、エラーが起き異常終了したことを示している。終了時刻＝「４時」とあるのは、当初の終了予定時刻を示し途中で異常終了したことを表す。なお、終了時刻として、エラーが起きて終了した時刻を記述するようにしてもよい。Ｎｏ．５は、「９月９日の２時」にダウンロードを開始しようとしたが、ネットワークが未接続等の理由でダウンロードが未実行であることを示している。Ｎｏ．６〜８は、予約日時に未だ達していないことを示している。Ｎｏ．１〜３は、ダウンロードが実際に終了した時刻であるのに対して、Ｎｏ．６〜８の終了時刻は、図９で示したように過去の実績からの予測した時刻を設定してある。事前ダウンロードフラグは、そのコンテンツは販売開始前の事前ダウンロードであるか否かを示す。この例ではすべてフラグ＝「０」であり、事前ダウンロードではないことを示している。なお、事前ダウンロードについては実施例２で後述する。
【００４５】
ダウンロードが正常終了したコンテンツの情報は、端末の蓄積コンテンツテーブル（図１９）にコピーする。それらのコンテンツは一定時間経過後に図１０のダウンロード予約管理テーブルからは自動的に消去してもよいし、ユーザが消去するまでそのまま記憶しておいてもよい。
【００４６】
図１１は、本実施例におけるダウンロード開始時刻決定の処理フローを示す図である。以下ステップ毎に説明する。なお、図中、ダウンロードをＤＬと記す。
【００４７】
ステップ１０１：ユーザは端末（テレビ）を用いて所望するコンテンツを選択し、さらに「今すぐダウンロードする」または「後でダウンロードする」を選択する。
ステップ１０２：「今すぐダウンロードする」を選択した場合は、サーバー側（またはテレビ側）では図９に示した端末別時間帯別のダウンロード実績のデータを参照し、曜日、時間帯、当該コンテンツの容量から当該テレビへのダウンロード終了時刻を予測する。
ステップ１０３：予測したダウンロード時刻と、図１０に示したダウンロード予約管理テーブルに予約済みのダウンロード時刻とが重複するか否かを判断する。
ステップ１０４：ダウンロード時刻が重複していれば、その旨を警告メッセージとしてテレビ画面に表示する。その際、既に予約してある時刻をどれだけ変更すれば重複しないのかが分かるように、例えば「１時３０分から２時までダウンロード時刻が重なっています。２つのコンテンツを同時にダウンロードすると、時間が余計にかかります」等をユーザに知らせる。
ステップ１０５：ユーザは、再度、「それでも今すぐダウンロードする」、「後でダウンロードする」、あるいは「既に予約してある時刻を変更する」を選択する。重複しているのを承知で「それでも今すぐダウンロードする」のであればステップ１０６へ、「後でダウンロードする」のであればステップ１０７へ、「既に予約してある時刻を変更する」のであればステップ１０８へ進む。
ステップ１０６：選択されたダウンロードを今すぐにダウンロードを開始する。
【００４８】
ステップ１０７：「後でダウンロードする」場合には、ユーザはダウンロード開始日時を「ユーザが入力する」、「テレビに任せる」から選択する。
ステップ１０８：図１０のダウンロード予約管理テーブルにアクセスし、予約済みでダウンロード時間が重複しているコンテンツの予約日時を変更する。どの時間帯が重なっているのかステップ１０４の案内画面で分かるので、その時間帯を避けるようにダウンロード開始時刻を遅くすれば、今からダウンロードしようとしているコンテンツのダウンロード時間帯が重複しないように設定できる。その後、再度、ダウンロードを実行するメニューを選択し、本処理フローの先頭で「今すぐダウンロードする」を選択すればよい。
ステップ１０９：ダウンロード開始日時をユーザが入力する。
ステップ１１０：ダウンロード開始日時を「テレビに任せる」場合には、テレビは当該コンテンツをダウンロードするのに要する時間を予測し、図３を参照し、できるだけ早い日時でダウンロード時間帯が重複しない日時を決定する。
ステップ１１１：ステップ１０３と同様に、図１０に示したダウンロード予約管理テーブルで予約済みのダウンロード時刻と重複するか否かを判断する。
ステップ１１２：ダウンロード時間帯が重複していれば、テレビ画面にダウンロードが重複する警告メッセージを表示する。
ステップ１１３：さらに、「当該コンテンツのダウンロード開始日時を再度入力しますか？  それとも予約済みのダウンロード開始日時を変更しますか？」と表示し、ユーザはそのどちらかを選択する。当該コンテンツのダウンロード開始日時を再入力するのであれば、ステップ１０９へ進み、既に予約してあるダウンロードの開始日時を変更するのであれば、ステップ１０８へ進む。
ステップ１１４：テレビが決定したあるいはユーザが入力したダウンロード日時をダウンロード予約管理テーブルに追加する。
【００４９】
図１２は、本実施例におけるコンテンツダウンロードの処理フローを示す図である。
ステップ２０１：テレビはサーバーに対し、ユーザがダウンロードを希望するコンテンツＩＤを送信する。
ステップ２０２：サーバーはコンテンツ蓄積部からユーザに要求されたコンテンツを検索し、所定の鍵で暗号化処理する。
ステップ２０３：ダウンロード開始日時に達したら、サーバーは暗号化したコンテンツと暗号化に用いた鍵とをネットワークを介してテレビへ送信（ダウンロード）する。
ステップ２０４：テレビはコンテンツと鍵を受信し、ハードディスクに蓄積する。その際、必要に応じてコンテンツの暗号化方式を変換して蓄積する。
ステップ２０５：サーバーとテレビは、それぞれコンテンツダウンロードの管理テーブルを更新する。
その後ユーザは、ハードディスクに蓄積したコンテンツを読み出し、上記鍵を用いて復号化してこれを視聴する。
【００５０】
本実施例によれば、同一の端末（テレビ）で複数のコンテンツが同時にダウンロードすることがないようにダウンロード開始時刻を設定する。もちろん、１つの端末に複数のコンテンツを同時にダウンロードすることは可能であるが、伝送性能が低下するので、極力ダウンロード時間帯が重複しないようにダウンロード開始時刻を設定する。そのために、端末別にこれまでのダウンロード実績を曜日、時刻別に管理し、その伝送能力からダウンロード時間を予測する。ユーザはダウンロードを急がない場合は、比較的ネットワークが閑散な深夜にダウンロード予約をする等、自分で任意のダウンロード開始日時を設定することが可能である。また、自分でダウンロード日時を設定することが面倒な場合は、ダウンロード開始日時を端末に任せることもできる。端末は予約されているダウンロード時間帯を避けて、新たなコンテンツのダウンロード開始日時を決定する。
【実施例２】
【００５１】
実施例２では、サーバーへのアクセスが集中することが予想される場合の回避策について述べる。人気のあるコンテンツの販売（レンタルも含む、以下同様）開始日には、ユーザからのアクセスが集中することが予想される。レンタルビデオ店で人気のあるビデオのレンタル開始直後には、店舗にあるすべてのビデオがレンタル中になり、なかなか借りることができないのが実情である。ダウンロードの場合もコンテンツの買取形式とレンタル形式が考えられるが、どちらの場合でも人気のあるコンテンツにはダウンロード販売を開始した直後にはアクセスが集中し、サーバーの処理能力がオーバーフローすることが予想される。本実施例では、このようにアクセスが集中した場合にこれを回避するものである。
【００５２】
本実施例において、コンテンツ販売というのは、コンテンツの買取とレンタルのどちらも含んでいるものとする。ユーザは、ダウンロード対象のコンテンツをテレビ画面を通して知ることができる。販売中のコンテンツには「ダウンロードする」という項目があり、これを選択するとコンテンツのダウンロードを開始する。これに対して、販売開始前のコンテンツには「予約受付中」という項目があり、その際「予約された方を優先してダウンロードを開始します」と表示することで、ユーザの購入意欲を高めることができる。その結果、購入を考えているユーザは予約受付を選択し、販売直後のサーバーへのアクセス集中を軽減することが期待できる。
【００５３】
図１３は、販売開始前のコンテンツの事前ダウンロード計画処理フローを示す図である。以下、ステップ毎に説明する。
【００５４】
ステップ３０１：現在時刻から販売開始日時まで所定時間（例えば２４時間）以上あるかどうかを判定する。２４時間以上あればステップ３０２で予約受付を待ち、２４時間未満であれば処理を終了する。
ステップ３０２：コンテンツのダウンロード予約を受付け、予約申し込みがあればステップ３０３へ進む。なお、待ち続けている間に販売開始２４時間前に達したら、処理は終了する。
ステップ３０３：ユーザに対し、ダウンロードする日時は指定せずに、受け付けた旨を表示する。この時、「サーバーの負荷軽減のため、販売開始日よりも前にコンテンツ本体をダウンロードすることがあります。ただし、ご覧いただくことができるのは販売開始日になってからです。事前にダウンロードしてよろしいですか？」という確認メッセージを表示する。これは、事前にダウンロードする場合があることをユーザに了承してもらうことになるが、これにより、ユーザには事前ダウンロードのことを意識させる必要はない。
【００５５】
ステップ３０４：予約のあったコンテンツ毎に、予約件数が所定の数に達したか否かを判定する。所定数に達していればステップ３０５へ、達していなければステップ３０１へ戻る。ここでの判定法については後述する。
ステップ３０５：所定数に達していれば事前ダウンロード処理の計画を立案する。事前ダウンロードとは、販売開始日より以前に暗号のかかったコンテンツ本体をダウンロードし、販売開始日に暗号を復号する鍵だけを送る。端末側では、鍵が到着するまでそのコンテンツを視聴できず、鍵が到着する販売開始日以降に初めて視聴できることになる。
【００５６】
以下、事前ダウンロード計画について具体的に説明する。予約件数が所定数に達していれば、予約受付順に１日当たり所定の数だけ時刻をずらしてダウンロードする。ダウンロードする時間帯はできるだけ夜間、深夜の時間帯を設定する。その際、図１０のダウンロード予約管理テーブルを参照して、他のコンテンツのダウンロード予約と重複していないように調整する。重複している場合には、前記図１１の処理フローで述べた方法に従い、サーバーとテレビとで通信し、事前ダウンロードする日時を調整する。日時が決定したら、図１０のダウンロード予約管理テーブルにその日時を設定するとともに、事前ダウンロードであることを示すフラグ＝「１」を立てる。
【００５７】
図１４は、上記ステップ３０４における判定（予約件数が所定の数に達したか否か）において、事前ダウンロードする条件の一例を示す図である。図１４では、販売開始まで７日前の時点で１０００件以上の予約件数Ａがあれば、事前ダウンロードの計画を立案開始する。その場合、販売６日前から２日前までの期間のダウンロード件数を、１日当たり（Ａ／５＋α）件とする。また、販売開始７日前時点での予約件数が１０００件未満であっても、５日前の時点で７００件以上の件数Ｂに達すれば、その時点で事前ダウンロードの計画を立案開始する。その場合には、販売４日前から２日前までの期間のダウンロード件数を、１日当たり（Ｂ／３＋α）件とする。ここに件数としてαを加算するのは、事前ダウンロード開始後に事前予約の追加が予想されるので、それに対応するためである。また、一度、事前ダウンロード件数を立案してもＳ３０４で再び、新たな予約件数が所定以上の件数に達すれば、１日当たりの事前ダウンロード件数を増やして再計画を立案すればよい。もしもステップ３０４で一度も所定の件数を上回ることなく、販売開始２４時間前になれば、事前ダウンロードの計画を立案せず、販売開始直後からダウンロードすればよい。すなわち、販売開始２４時間前に、予約のあったテレビに対してその日時を設定し、テレビ側と通信して他のダウンロードと重複しない日時を図３のダウンロード予約管理テーブルに設定すればよい。この場合、事前ダウンロードのフラグは「０」にする。
【００５８】
図１５は、本実施例におけるコンテンツ事前ダウンロードの処理フローを示す図である。
ステップ４０１：ダウンロード予約テーブルに従い、テレビはダウンロードを要求するコンテンツＩＤをサーバーに送信する。サーバーは、ダウンロードの予約状況から事前ダウンロードを計画したとする。
ステップ４０２：サーバーは、コンテンツ蓄積部からユーザに要求されたコンテンツを検索し、所定の鍵で暗号化処理する。
ステップ４０３：事前ダウンロードの計画に従い、サーバーはコンテンツの販売日以前に、上記コンテンツをネットワークを介してテレビへ送信（ダウンロード）する。
ステップ４０４：テレビはコンテンツを受信し、ハードディスクに蓄積する。その際、必要に応じてコンテンツの暗号化方式を変換して蓄積する。
ステップ４０５：サーバーとテレビは、それぞれコンテンツダウンロードの管理テーブルを更新する。
ステップ４０６：コンテンツ販売日時に達したら、サーバーはテレビにコンテンツを復号するための鍵を送信する。または、テレビからサーバーに鍵を取りにいく。
ステップ４０７：テレビは鍵を受信し、通信用鍵管理部に格納する。
ステップ４０８：サーバーとテレビは、それぞれコンテンツダウンロードの管理テーブルを更新する。
【００５９】
このようにコンテンツの事前ダウンロードでは、対象とするコンテンツを所定の鍵を用いて暗号化処理し、暗号化された状態で販売日以前にテレビに送信する。そして、暗号化コンテンツを復号するための鍵を販売開始日にテレビに送信する。または、販売開始日になればテレビからサーバーに復号するための鍵を取りにいってもよい。この鍵には、どのコンテンツＩＤに対応した鍵であるかを示す情報も付随して送る。テレビは、図３の事前ダウンロードフラグが「１」であるコンテンツから該当するコンテンツを識別し、鍵が到着した後、該当する暗号化コンテンツを復号化する。そして、蓄積コンテンツテーブル（図１９）に追加する。これで、ユーザがコンテンツ一覧を表示した時に、このコンテンツ名称が表示され、ユーザはこれを選択し視聴することが可能になる。すなわち、鍵が到着するまではユーザは受信したコンテンツを視聴できないだけでなく、テレビがコンテンツ本体を受信していることさえもユーザに隠匿しておくことができる。なお、図１９に追加したコンテンツの情報は、図１０からはある一定期間後に消去してもよいし、ユーザが消去するまでそのまま残しておいても構わない。
【００６０】
本実施例によれば、販売開始直後のサーバーへのアクセス集中を回避することができる。すなわち、人気があるコンテンツのダウンロード開始日には、予約が殺到することが予想される。そのような場合においても、販売開始日よりも前に暗号化されたコンテンツのみダウンロードすることで、サーバーへの集中を平準化することができる。また、それを復号するための鍵を販売開始日に送付することで、ユーザは販売開始日から視聴することができるのでユーザに対し違和感を与えない。また、予約集中による視聴日の遅延を避けることができる。さらに鍵が端末に着くまではコンテンツを視聴できないので、コンテンツの著作権や視聴制限を遵守することができる。
【００６１】
また、コンテンツプロバイダが事前ダウンロードしたコンテンツの存在をユーザに知らせても構わない、等の理由があれば、鍵が未到着の状態でもコンテンツ一覧表示にコンテンツ名を表示し、ただし、鍵が未到着なので視聴できないことを表示すればよい。これを実現するためには、以下のように実施する。ユーザがコンテンツ一覧表示をした場合、図１９の蓄積コンテンツテーブルのコンテンツを表示し（これらは視聴可能）、さらに、図１０のダウンロード予約管理テーブルの事前ＤＬフラグが「１」で、状態＝正常終了のコンテンツを抽出し、コンテンツ名称を表示し、その近辺に「鍵が未到着のため視聴不可」も合わせて表示すればよい。
【００６２】
本実施例ではコンテンツのみを事前ダウンロードする方法を述べたが、すべてのテレビが事前ダウンロードに対応できるとは限らない。そこでサーバーでは、コンテンツを事前ダウンロードし、後から鍵だけを送付してコンテンツを復号できる（以下、事前ダウンロード可能）テレビの機器ＩＤ一覧を管理しておき、テレビから事前ダウンロード要請があった場合はその機器ＩＤを報告してもらい、事前ダウンロード可能機能があるテレビに限り事前ダウンロードを許可し、そうでないテレビには事前ダウンロードを許可しない、というダウンロード方法を実施すればよい。実際にはこのような運営が考えられる。
【実施例３】
【００６３】
実施例３では、端末側で視聴制限を設定してコンテンツを表示する方法を述べる。コンテンツの中には、視聴者（ユーザ）を制限するもの、例えば未成年には見せたくないものもあり、本実施例ではこのような場合の視聴制限を実行させるものである。
【００６４】
図１６は、視聴制限のもとに登録されたユーザ情報と権限の一例を示す図である。この例では、父親がダウンロード決済権限者兼スーパーバイザとして、全ユーザの権限を登録し、各ユーザは自分のパスワードを設定する。ダウンロードするコンテンツはデフォルトでは共有フォルダに蓄積されるが、他人に見せたくない場合は、自分のフォルダに蓄積することができる。その場合、パスワードで本人を特定する。ただし、親は子どもがどんなコンテンツを購入したのかが分かるように視聴権限を持つことができる。
【００６５】
図１６では、父親と母親に視聴権限を与えている例を示している。子ども１と子ども２は互いには秘密にできるが、視聴権限のある父親と母親は、子ども1と子ども２のフォルダの中身を見ることができる。ここでスーパーバイザは、視聴権限を誰に与えるかを決定することができる。また、スーパーバイザが子ども１と子ども２のプライバシーを尊重するのであれば、視聴権限は誰にも与えないことも可能である。この場合、子ども１と子ども２のフォルダの内容は誰も視聴することはできない。なお、図７において子ども２はパスワードを設定していないので、両親だけでなく、子ども１も子ども２のフォルダの内容を視聴することが可能である。
【００６６】
図１７は、ダウンロードするフォルダを決定する画面例を示す図である。デフォルトは共有フォルダに蓄積するが、父親が他の家族には見せたくないコンテンツは自分だけのフォルダに蓄積することが可能である。母親には視聴権限があるが、スーパーバイザである父親のフォルダだけは見ることができない。視聴権限のあるユーザは、スーパーバイザのフォルダの内容も見ることができるように実現することはもちろん可能であるが、本実施例ではスーパーバイザ権限を優先させる。父親が自分のフォルダに蓄積したい場合は、図１７で「いいえ」を選択する。
【００６７】
図１８は、図１７で「いいえ」を選択し、特定のフォルダへダウンロードする画面例を示す図である。父親は画面左下の「父親」を選択し、自分のパスワードをテレビのリモコンを使って入力する。こうすればこのコンテンツは、父親以外の家族はコンテンツ名称さえ見ることはできない。
【００６８】
図１９は、端末（テレビ）における蓄積コンテンツテーブルの一例を示す図であり、テレビが蓄積しているコンテンツのフォルダ別の情報である。視聴権限の欄で、「子１」、「子２」はそれぞれ子ども1、子ども２のことであり、フラグ「１」は視聴権限あり、「０」は視聴権限なしを示す。父親や母親が購入したコンテンツは、子ども１や子ども２は見ることができないことを示している。ユーザがコンテンツ一覧表示する場合は、図１９の情報を用いる。テレビで「コンテンツ一覧表示」のメニューを選択すると、テレビを操作しているのが誰か不明であるため、デフォルトで共有フォルダに蓄積されているコンテンツを表示する。
【００６９】
図２０は、共有フォルダ内のコンテンツ表示の一例を示す図である。図１９との関係を明確にするためにコンテンツＩＤを示したが、実際にはコンテンツ名称、あらすじ、出演者、サムネイル等を表示するのが分かりやすいインタフェースである。さらに、父親のフォルダを見ようとすると、画面左下の「父親」を選択する。テレビは画面中央に「パスワードを入力してください」というメッセージを出し、ユーザはパスワードを入力する。テレビはパスワードが正しいと認識すれば父親のフォルダ内のコンテンツを表示する。
【００７０】
図２１は、父親のフォルダ内のコンテンツ表示の一例を示す図である。父親のフォルダを表示している最中は、他のフォルダにアクセスするために画面の下には「母親」「子ども１」「子ども２」「共有」を表示する。ここで、子ども１が画面下部の「子ども１」を選択し、自分のパスワードを入力すれば自分のフォルダにアクセスできることは当然である。さらに、視聴権限のある父親や母親が、図２０または図２１の画面下の「子ども１」を選択し自分自身のパスワードを入力すれば、テレビは視聴権限のあるユーザであると判断し、子ども1のフォルダを表示する。
【００７１】
図２２は、本実施例におけるコンテンツ一覧表示の処理フローを示す図である。
ステップ５０１：ユーザがコンテンツ一覧表示メニューを選択すると、蓄積コンテンツテーブル（図１９）の共有フォルダのコンテンツを表示する。
ステップ５０２：特定フォルダ（共有フォルダ以外）の選択があったかを判定する。選択がなければそのまま共有フォルダの内容を表示しておく。選択があれば、ステップ５０３へ進む。
ステップ５０３：テレビは操作をしたユーザのパスワードの入力を要求する。
ステップ５０４：そのパスワードは視聴権限のあるユーザのパスワードと一致するか否かを調べる。
ステップ５０５：一致すればそのユーザは視聴権限を有しているので、選択されたフォルダの内容を表示する。
ステップ５０６：視聴権限者のパスワードでない場合、選択されたフォルダのユーザのパスワードと一致するか否かを調べる。例えば「子ども1」を選択された場合、子ども１のパスワードと一致すれば操作者は子ども１であると認識して、ステップ５０５へ進みそのフォルダ内のコンテンツを表示する。
ステップ５０７：いずれにも一致しない場合は、操作者は視聴権限者でもないし選択されたフォルダの本人でもないので、表示を拒否する。
【００７２】
図１６のユーザ情報は、テレビ内に格納するだけでなく、バックアップの意味でセンタ側のサーバーにも格納してもよい。そして、パスワードを連続して所定の回数だけ間違えたときなど、そのフォルダへのアクセスを拒否し、その旨をテレビに表示する。例えば、「本フォルダへのパスワードを３回続けて間違えられました。いったんアクセスを拒否しています。センタへご連絡ください」と表示し、本人確認をしてから、パスワードを郵送する、等の方法が可能になる。
【００７３】
本実施例によれば、端末側でコンテンツ一覧表示をした場合、パスワードがかかったフォルダの内容はパスワードを入力しなければ、表示しないようにできる。また、視聴する権限のある人がパスワ−ドを入力すればすべてのコンテンツの表示を可能にすることもできる。このようにして、視聴制限のあるコンテンツをその権限に従って表示させることができる。
【実施例４】
【００７４】
実施例４では、サーバー側で視聴制限を設定してコンテンツを表示する方法を述べる。前記実施例３は、端末（ユーザ）側でコンテンツに視聴制限を設定した場合の例を述べたが、コンテンツプロバイダがコンテンツ毎に視聴制限を設定することもできる。ユーザがダウンロードするコンテンツを検索し、視聴制限のあるコンテンツを含んだ特定の領域を表示する場合、サーバー側はテレビを介して、「このコーナーには１８歳未満の方はご覧になることはできないコンテンツが含まれています。パスワードを入力してください」とパスワードの入力を要求し、視聴者を制限するものである。このためサーバーには、蓄積しているコンテンツ毎に、コンテンツＩＤ、コンテンツ名称、コンテンツ容量、買取の場合の価格、レンタルの場合の価格、レンタルの場合強制的に消去するかを示すフラグの他に、視聴制限を示す情報として、例えば年齢１８歳以上に制限を示すフラグ、等の情報を有するコンテンツ管理テーブル（図示せず）が存在する。
【００７５】
図２３は、本実施例における視聴制限（１８歳以上）付きのコンテンツ一覧表示の処理フローを示す図である。なお、本来であればユーザＩＤとパスワードの両方を入力するのが通常であるが、テレビは家族数人で使用することが多いので、入力は極力少なくした方がユーザのためになるので、パスワードだけの入力で操作者を特定しようとしている。もちろん、ユーザ名を表示し、それを選択してからパスワードを入力するという方法でも構わない。以下、各ステップの説明を行う。
ステップ６０１：ユーザはサーバーに蓄積してあるコンテンツを検索し、条件にあったコンテンツを決定し、テレビにそれを表示しようとする。
ステップ６０２：表示しようとしているコンテンツに視聴制限（ここでは１８歳未満視聴禁止）はないかを調べる。そのような視聴制限があるコンテンツが含まれていればステップ６０３へ、含まれていなければステップ６０５へ進む。
ステップ６０３：１８歳未満視聴禁止のコンテンツが含まれているので、ユーザにパスワードの入力を要求する。
ステップ６０４：図１６に登録したパスワードと照合して、ユーザが１８歳以上であるか否かを判断する。１８歳以上であればステップ６０５へ、１８歳未満であればステップ６０６へ進む。
ステップ６０５：視聴制限のあるコンテンツが含まれていない、または視聴制限のあるコンテンツがあってもユーザが１８歳以上の場合には、すべてのコンテンツの表示はＯＫとテレビは判定し、検索条件を満たすコンテンツの一覧を表示する。
ステップ６０６：ユーザが１８歳未満の場合には、コンテンツ管理テーブルで「視聴条件は１８歳以上」というフラグが立っているコンテンツは表示せず、それ以外のコンテンツのみを表示する。
【００７６】
実施例４によれば、コンテンツに視聴制限がある場合、視聴禁止の対象となるユーザにはコンテンツの存在そのものを表示しない、つまりコンテンツ名称すら表示しないことにより視聴制限を遵守することができる。また、視聴制限のあるコンテンツをダウンロードできるのは、あらかじめユーザ登録で、生年月日を登録しておき、パスワードで本人を確認できた場合にしかダウンロードできないようにする。
【００７７】
以上述べたように、コンテンツ一覧表示では図１９の蓄積コンテンツテーブルを参照し、デフォルトでは共有フォルダに蓄積されているコンテンツを表示する。ユーザが特定のフォルダを選択すれば、パスワードで本人であるか視聴権限者であるかを確認してからそのフォルダに蓄積されているコンテンツを表示する。なお、事前ダウンロードが完了し、鍵が未到着の場合は、図１０のダウンロード予約管理テーブルには正常終了の情報があるが、鍵が到着した後で図１９の蓄積コンテンツテーブルに登録する。従って、ユーザは鍵到着前にコンテンツ一覧表示のメニューを選択しても、そのコンテンツが表示されることはない。
【００７８】
ただしコンテンツプロバイダが事前ダウンロードしたコンテンツの存在をユーザに知らせても構わない、等の理由があれば、鍵が未到着の状態でもコンテンツ一覧表示にコンテンツ名を表示し、ただし、鍵が未到着なので視聴できないことを表示すればよい。この実現方法は実施例２で述べた。
【実施例５】
【００７９】
実施例５は、テレビに蓄積しているコンテンツを消去する場合である。これまで販売にはレンタルも含めて説明してきた。現在のビデオ、ＤＶＤには買取とレンタルの両方の形態が存在することから、コンテンツのダウンロードでも買取とレンタルの２形態が存在すると予想される。コンテンツを買取る場合、その所有者はユーザとなるためそのコンテンツを無期限に所有してよいが、レンタルの場合、所定の日数が経過すればそれを消去する必要がある。以下、テレビに蓄積しているコンテンツを消去する方法を述べる。
【００８０】
コンテンツを消去する方法として、テレビが消去するコンテンツを認識して、テレビだけで消去する場合（以下、ローカル消去）とサーバーからテレビにアクセスして消去する場合（以下、リモート消去）がある。
【００８１】
まず、ローカル消去の処理について述べる。
ステップ１：コンテンツをテレビに記録する際、サーバー側に存在するコンテンツ管理テーブルにある強制消去フラグ（「１」＝強制消去する、「０」＝強制消去する必要なし）を参照し、レンタルする日数を選択し、強制フラグの内容（「０」か「１」か）と有効期限日時を図１９の蓄積コンテンツテーブルに書き込む。
ステップ２：タイマーで経過時間を監視しておき、有効期限が来たコンテンツがあれば、消去コマンドを発行し、そのコンテンツを消去する。
ステップ３：コンテンツを消去したことをサーバーに報告し、サーバーは図８の消去済みフラグを書き換える。なお、強制消去フラグ＝「１」であるコンテンツをレンタルする場合、テレビは次のメッセージを表示する。「このコンテンツは有効期限が来れば、自動的に消去されます。ダウンロードしますか？」さらにその下に「承認する」「承認しない」の選択肢を表示し、「承認する」が選択された後にダウンロードを開始する。「承認しない」が選択された場合はダウンロードを実行しない。
【００８２】
また、タイマーで監視する以外に下記方法も考えられる。１分１秒を争って消去する必要があるとは限らない。たとえコンテンツがハードディスク等の記憶装置には残っていても、再生することができなければ、レンタルモデルという当初の目的は達しているといえる。その後、有効期限の切れたコンテンツ一覧を表示し、ハードディスクの領域を確保するためにユーザに消去してもらう、という方法である。強制消去フラグが「１」、「０」のコンテンツが混在している場合の共有フォルダのコンテンツ一覧表示の処理フローを下記に示す。
【００８３】
ステップ１：図１９の蓄積コンテンツテーブルの中の共有フォルダのコンテンツを検索する。
ステップ２：有効期限内であればそのコンテンツ名称、等を表示する。
ステップ３：有効期限が経過しており、強制消去フラグ＝「１」であれば、その場で消去する。
ステップ４：有効期限が経過しており、強制消去フラグ＝「０」であれば、有効期限切れコンテンツテーブルにコンテンツＩＤを書き込む。
ステップ５：共有フォルダの全コンテンツを検索し、有効期限切れコンテンツテーブルにコンテンツＩＤが存在すれば、画面の一部に「有効期限切れコンテンツ」のアイコンを表示する。
【００８４】
有効期限切れコンテンツがない場合は、図２０のように表示する。有効期限切れコンテンツがある場合は、図３０のように表示する。ユーザはハードディスク容量を確保するために、有効期限切れコンテンツの一覧を表示し、該当コンテンツを消去する。また、ステップ３で強制消去フラグ＝「１」でもテレビ自らは消去せず、有効期限切れコンテンツテーブルに書き込むことも考えられる。もし、テレビのタイマーが故障した場合、多くのコンテンツを誤って消去してしまう誤動作を防御するため、有効期限が切れたコンテンツは再生可能なコンテンツとしては表示せず、有効期限切れコンテンツとして案内し、消去はユーザにやってもらう、という考えである。
【００８５】
次に、リモート消去の処理について述べる。
ステップ１：センタ側のサーバーはサーバーにある端末別ダウンロード管理テーブル（図８）を監視しておき、強制消去フラグ＝「１」のコンテンツで有効期限日時が来たコンテンツを抽出する。
ステップ２：図８からそのコンテンツが記録されている機器ＩＤを参照し、サーバーからその機器（テレビ）に通信ネットワークを介して、消去コマンドを発行する。
ステップ３：サーバーから消去コマンドを受信したテレビは、その命令に従い、該当するコンテンツを消去し、サーバーに報告する。
ステップ４：サーバーは、図８の消去済みフラグを書き換える。
【００８６】
さらに他の方法として、テレビ起動時消去法も可能である。有効期限が来たコンテンツがあれば、消去候補コンテンツとして別テーブル（消去候補コンテンツテーブル）に移動し、図１９の蓄積コンテンツテーブルから除く。次回、テレビに電源が入ったときに、消去候補コンテンツテーブルを参照し、該当コンテンツがあれば、テレビは「○○のコンテンツは有効期限が来たので消去しました」というメッセージを表示する。ローカル消去、リモート消去ではユーザが知らない間にコンテンツが消去されてしまうが、テレビ起動時消去によれば、ユーザに消去したコンテンツを知らせることができる。有効期限が来てから実際に消去されるまで時間差が発生するが、有効期限が来たときに、図１９の蓄積コンテンツテーブルから削除するので、ユーザがコンテンツ一覧を表示しても、そのコンテンツがテレビに表示されることはない。
【００８７】
本実施例では、コンテンツプロバイダがダウンロード後、所定の日数経過後、そのコンテンツを消去することを希望すれば、端末においてそのコンテンツを消去できる。サーバーでは、コンテンツを消去できる端末の機器ＩＤ一覧を管理しておき、端末からダウンロード要請があった場合はその機器ＩＤを報告させ、消去機能がある端末に限りダウンロードを許可する。端末では所定の日時になれば、そのコンテンツを強制的に消去し、その旨をサーバーに報告する。
【００８８】
本実施例によれば、所定のレンタル日数が経過すればテレビからコンテンツを消去することができるので、コンテンツプロバイダは安心してコンテンツを提供することが可能となる。また、ユーザはコンテンツを借りたり返却したりするために、レンタルビデオ店に行く必要がない。
【実施例６】
【００８９】
実施例６は、有効期限の切れたコンテンツを簡単に再度購入して視聴する方法である。有効期限が来たら、直ちにテレビの記録部（一般的にはハードディスク）からコンテンツを消去するのではなく、コンテンツ本体（暗号化）を一定期間消去せずに保存し、復号鍵だけを消去する。そして、「有効期限が来たので消去しました。鍵だけ再購入すれば今すぐご覧いただけます」というメッセージをテレビに表示し、ユーザが再レンタルを希望すれば、鍵だけを送ることでユーザは視聴できる。特に、ダウンロードしたにもかかわらず、ユーザの都合で一度も見なかった場合には有効である。コンテンツプロバイダにとっては、消去してしまうよりも、ユーザに再レンタルの機会を与えることによる収入の向上が期待できる。
【００９０】
コンテンツプロバイダがこの方法を実施する場合には、強制消去フラグ以外に、鍵再購入可能フラグ（「１」＝可能、「０」＝不可能）を設け、図８の端末別ダウンロード管理テーブルや、図１９の蓄積コンテンツテーブルにてこれを管理する。ただし、両方のフラグが「１」にならないようにする。コンテンツ一覧表示するメニューがテレビで選択されれば、図１９で鍵再購入可能フラグが「１」で有効期限が過ぎたコンテンツは、コンテンツ名称を表示するアイコンに「有効期限切れ、鍵購入可」や「有効期限切れ、再レンタル可能」という案内を表示し、ユーザに再購入を促す。
【００９１】
以下、本実施例の処理ステップを示す。ここではコンテンツに視聴制限がかかっていない場合とする。
ステップ１：ユーザは、あるフォルダのコンテンツ一覧を表示するためのメニューを選択する。
ステップ２：テレビは、図１９の蓄積コンテンツテーブルの中からユーザが選択したフォルダを参照し、有効期限が切れているか否かを確認する。
ステップ３：有効期限内のコンテンツはそのままとする。有効期限が切れたコンテンツは「有効期限が切れた」ことを表示し、「鍵のみ再購入すればすぐに見ることができます」との案内を表示する。
【００９２】
図２４は、有効期限が切れたコンテンツに対して鍵の再購入を選択する表示画面例を示す図である。コンテンツＩＤ＝「１０１０１」のコンテンツは有効期限が切れたものの、コンテンツ本体はまだ記憶装置に残っており、ユーザに鍵の再購入を勧めている場合を示している。また、コンテンツ一覧表示するか否かとは関係なく、強制消去フラグ＝「０」、鍵再購入可能フラグ＝「１」の場合には、有効期限の切れたコンテンツはある一定期間を経過した後に、図１９の蓄積コンテンツテーブルから消去し、コンテンツ本体も記憶装置（一般的にはハードディスク）から消去する。あるいは、ユーザが消去するまでそのままコンテンツを保存しても構わない。
【００９３】
本実施例によれば、ユーザは再度視聴したいが有効期限が切れてしまったコンテンツについては、コンテンツ本体をダウンロードすることなく、復号鍵だけを再購入して視聴することができる。よって、新たなダウンロードに要する時間が不要になり、ユーザは迅速に視聴できる。コンテンツホルダにとっても、再度コンテンツを購入してもらう機会を与えることで、売上の向上が期待できる。
【実施例７】
【００９４】
実施例７は、ユーザが端末装置にて、追っかけ再生する場合の画質改善法である。現在のハードディスクレコーダでは、放送波を録画中にその番組を最初から再生することが可能である。これを追っかけ再生と言う。例えば、９時から１１時まで録画予約をしておいて、３０分遅れで９時３０分から番組の最初から再生することが可能である。追っかけ再生では、途中で早送りをしなければ、録画している場面に追いつくことはない。これはハードディスクへの録画速度と再生速度がともに等しく、リアルタイムで実行しているからである。
【００９５】
一方、通信ネットワークによるダウンロードでは、通信環境が悪化すると、ハードディスクへの録画速度がコンテンツの視聴速度よりも遅くなる場合が生じる。そのような環境で追っかけ再生を行うと、再生はコンテンツ本来の視聴速度で実行されるため、再生速度が録画速度に追いついてしまうことになる。つまり、録画している映像をそのまま視聴する、いわゆるストリーミング再生状態になる。
【００９６】
ストリーミング再生では通信環境の影響を受けやすく、映像が乱れたり、録画速度が遅くなることがある。コンテンツをダウンロードして高画質で視聴したいユーザに対して、追っかけ再生の際にストリーミング再生状態に移行し、画質を劣化させることはできるだけ避けたい。そのため、通信ネットワークでダウンロード中のコンテンツを追っかけ再生する場合は、録画動作に追いつきストリーミング再生状態へ移行しないように配慮する。追いつく可能性がある場合は、ユーザに警告メッセージを表示する。以下、この実現方法について述べる。
【００９７】
今、ダウンロード中のコンテンツの容量をＡ（ＭＢ）、視聴するのに要する時間をＢ（分）とする。これまでに容量Ａ１（ＭＢ）だけダウンロード済みで、残りがＡ２（ＭＢ）であるとする（Ａ１＋Ａ２＝Ａ）。これまでダウンロードに要した時間をＴ１（分）であるとすると、ダウンロード速度はＡ１／Ｔ１（ＭＢ／分）であり、残りのコンテンツＡ２をダウンロード完了するまでに、あとＡ２＊Ｔ１／Ａ１（分）必要である。一方、今から追っかけ再生を完了するのに要する時間はＢ（分）であるから、これらを比較する。
Ａ２＊Ｔ１／Ａ１＜Ｂ・・・（１）
式（１）が成立すれば、再生は録画に追いつかない。追っかけ再生を実行してもユーザに不愉快な思いをさせることがないといえる。もし、式（１）が成立しない場合は、追っかけ再生をした場合、録画動作に追いつく可能性がある。
【００９８】
この場合には再生画像は乱れる恐れがあるので、ユーザが追っかけ再生を実行しようとした場合に、テレビは、「追っかけ再生を行い、録画部分をすべて見ると、乱れた映像を見ることになるかもしれません。追っかけ再生をしますか？」、等のメッセージをユーザに表示する。乱れた映像を見たくないユーザは「追っかけ再生しない」を選択し、もう少し先までダウンロードを実行してから追っかけ再生をすればよい。またはダウンロードを完了してから再生をすればよい。このメッセージを表示することによってユーザはストリーミング再生による乱れた映像を見ることがなくなる。
【００９９】
または、式（１）が成立するまでは「追っかけ再生」のメニューを選択させないようにすることも可能である。一般にテレビのリモコンには「画面表示」というボタンがついている。このボタンが押下されると、入力モード、表示しているチャンネル表示等を行う。入力モードには例えば、テレビ、ビデオ１、ビデオ２、通信、があり、通信モードが選択されるとネットワークからの入力情報が表示される。ダウンロード中にこの「画面表示」ボタンが押下されると、＜ダウンロード中＞を表示させる。さらに、式（１）が成立すれば、その横に＜追っかけ再生＞を表示させ、選択可能とする。式（１）が成立しない場合は、＜追っかけ再生＞を表示せず、追っかけ再生を実施することはない。
【０１００】
さらに別の例として、以下の方法も考えられる。式（１）が成立する場合は、通信モードで＜ダウンロード中＞＜追っかけ再生＞の両方を表示し、追っかけ再生を選択可能にする。逆に、式（１）が成立しない場合は通信モードで＜ダウンロード中＞（追っかけ再生は現在利用不可）と表示して、追っかけ再生が選択できないようにする。この方法であれば、追っかけ再生という機能はあるが、今は追っかけ再生が利用できない、もう少し待てば利用できる、という状況をユーザに伝えることができる。
【０１０１】
図２５は、＜追っかけ再生＞を表示しない例を示す。図２６は、＜追っかけ再生＞を表示する例を示す。図２６では初期状態ではカーソルを＜ダウンロード中＞に重畳し、リモコンの右方向への移動キーでカーソルを＜追っかけ再生＞に重畳し、リモコンの決定キーで追っかけ再生を開始する。式（１）が成立する場合は図２６を表示し、成立しない場合は、図２５または図３１を表示し、追っかけ再生が選択できないようにする。
【０１０２】
実施例７によれば、ユーザが追っかけ再生を実行しても画面が乱れることを回避できるので、ユーザに不愉快な思いを与えることがない。
【図面の簡単な説明】
【０１０３】
【図１】本発明が対象とするコンテンツダウンロードシステムの構成例を示す図。
【図２】コンテンツを送信する送信装置のブロック構成例を示す図。
【図３】コンテンツを受信して蓄積し視聴する端末装置のブロック構成例を示す図。
【図４】放送波とダウンロードしたデータを別々の暗号で蓄積する方法を説明する図。
【図５】機器特有のローカル暗号で統一して蓄積する方法を説明する図。
【図６】ダウンロードに適用されるＤＲＭ暗号で統一して蓄積する方法を示す図。
【図７】暗号方法毎に、蓄積、表示時に復号部、暗号部で行う変換をまとめたテーブル。
【図８】端末別ダウンロード管理テーブルの一例を示す図。
【図９】端末別時間帯別のダウンロード実績の一例を示す図。
【図１０】ダウンロード予約管理テーブルの一例を示す図。
【図１１】ダウンロード開始時刻決定の処理フローを示す図。
【図１２】コンテンツダウンロードの処理フローを示す図。
【図１３】販売開始前のコンテンツの事前ダウンロード計画処理フローを示す図。
【図１４】事前ダウンロードする条件の一例を示す図。
【図１５】コンテンツ事前ダウンロードの処理フローを示す図。
【図１６】視聴制限のもとに登録されたユーザ情報と権限の一例を示す図。
【図１７】ダウンロードするフォルダを決定する画面例を示す図。
【図１８】特定のフォルダへダウンロードする画面例を示す図。
【図１９】端末における蓄積コンテンツテーブルの一例を示す図。
【図２０】共有フォルダ内のコンテンツ表示の一例を示す図。
【図２１】父親のフォルダ内のコンテンツ表示の一例を示す図。
【図２２】コンテンツ一覧表示の処理フローを示す図。
【図２３】視聴制限付きのコンテンツ一覧表示の処理フローを示す図。
【図２４】有効期限が切れたコンテンツに対して鍵の再購入を選択する画面例を示す図。
【図２５】＜追っかけ再生＞を表示しない例を示す図。
【図２６】＜追っかけ再生＞を表示する例を示す図。
【図２７】放送波とダウンロードしたデータを別々の暗号で蓄積する方法を説明する図。
【図２８】機器特有のローカル暗号で統一して蓄積する方法を説明する図。
【図２９】ダウンロードに適用されるＤＲＭ暗号で統一して蓄積する方法を示す図。
【図３０】有効期限コンテンツがあり、ユーザに消去を促す図。
【図３１】追っかけ再生を現在抑止していることを示す図。
【符号の説明】
【０１０４】
１…送信装置（サーバー）、
２…端末装置（テレビ）、
３…ネットワーク、
１１…コンテンツ蓄積部、
１２…管理ファイル部、
１３…通信用鍵作成部、
１６…暗号処理部、
１７…制御部、
１８…通信送受信部、
２１…通信送受信部、
２２…放送受信部、
２３…制御部、
２４…コンテンツ要求部、
２５…通信用復号部、
２６…通信用暗号部、
２７…通信用鍵管理部、
３１…蓄積部（ハードディスク）、
３２…入力切替部、
３３…表示部。
【図１】
2008134992.tif 000003
【図２】
2008134992.tif 000004
【図３】
2008134992.tif 000005
【図４】
2008134992.tif 000006
【図５】
2008134992.tif 000007
【図６】
2008134992.tif 000008
【図７】
2008134992.tif 000009
【図８】
2008134992.tif 000010
【図９】
2008134992.tif 000011
【図１０】
2008134992.tif 000012
【図１１】
2008134992.tif 000013
【図１２】
2008134992.tif 000014
【図１３】
2008134992.tif 000015
【図１４】
2008134992.tif 000016
【図１５】
2008134992.tif 000017
【図１６】
2008134992.tif 000018
【図１７】
2008134992.tif 000019
【図１８】
2008134992.tif 000020
【図１９】
2008134992.tif 000021
【図２０】
2008134992.tif 000022
【図２１】
2008134992.tif 000023
【図２２】
2008134992.tif 000024
【図２３】
2008134992.tif 000025
【図２４】
2008134992.tif 000026
【図２５】
2008134992.tif 000027
【図２６】
2008134992.tif 000028
【図２７】
2008134992.tif 000029
【図２８】
2008134992.tif 000030
【図２９】
2008134992.tif 000031
【図３０】
2008134992.tif 000032
【図３１】
2008134992.tif 000033