JP5556895B2 - コンテンツデータ再生装置、更新管理方法、及び更新管理プログラム - Google Patents

Description

本発明は、ファームウェアを継続的に更新するコンテンツデータ再生装置、更新管理方法、及び更新管理プログラムに関する。

従来、回線を介して音楽や映像等のコンテンツデータを受信し、再生する端末（以下、「コンテンツ再生端末」という。）が存在する。コンテンツ再生端末の一例としては、ＰＣ（Personal Computer）、ＩＰＴＶ（Internet Protocol Television）、ＳＴＢ（Set Top Box）、携帯音楽プレーヤを搭載した各種の携帯型端末等が挙げられる。

コンテンツ再生端末によるコンテンツデータの不正利用を防止するために、コンテンツ再生端末のファームウェアは定期的に更新されるのが望ましい。当該ファームウェアには、コンテンツの復号鍵を安全に取得するためにセキュアな通信を実現するための秘密鍵が含まれているからである。すなわち、長期間において同一の秘密鍵等に基づいてセキュアな通信が行われた場合、理論的には当該通信内容が盗聴される可能性があるからである。したがって、一般的に、コンテンツ再生端末のファームウェアは定期的に更新されるように運用されている。その結果、上記秘密鍵も更新され、セキュアな通信の安全性が継続的に確保される。

図１は、従来のコンテンツ再生端末におけるファームウェアの更新機能を説明するための図である。

同図において、コンテンツ再生端末５１０は、セキュリティチップ５１１を有する。セキュリティチップ５１１内には、ファームウェア更新部５１２と、更新対象となるファームウェア５１３等が含まれる。

また、コンテンツ再生端末５１０は、セキュリティチップ５１１外のＣＰＵが実行するアプリケーションプログラムとして、ファームウェア更新アプリ５１４及びコンテンツ再生プレーヤアプリ５１５等を有する。

ファームウェア更新アプリ５１４は、ファームウェア更新サービス５２０よりファームウェアをダウンロードし、ファームウェア更新部５１２にファームウェア５１３の更新を実行させるアプリケーションプログラムである。

コンテンツ再生プレーヤアプリ５１５は、コンテンツ配信サービス５３０よりダウンロードされるコンテンツデータを、ファームウェア５１３等を用いて再生するアプリケーションプログラムである。

ファーム更新サービス５２０は、ネットワークを介してファームウェアを提供するサービスである。ファーム更新サービス５２０は、コンテンツ再生端末５１０のメーカーによって運用されるのが一般的である。

コンテンツ配信サービス５３０は、ネットワークを介してコンテンツデータを配信するサービスである。

斯かるコンテンツ再生端末５１０のファームウェア５１３の更新は、例えば、次のような手順で実行される。

例えば、ユーザよりファームウェア５１３の更新指示が入力されると、ファーム更新アプリ５１４は、セキュリティチップ５１１のファーム更新部５１２を呼び出し、現時点のファームウェア５１３の版数（ファーム版数）を取得する（Ｓ１）。

続いて、ファーム更新アプリ５１４は、取得したファーム版数を指定して、ファーム更新サービス５２０にファーム更新依頼を送信する（Ｓ２）。

ファーム更新サービス５２０は、送られてきたファーム版数を最新のファーム版数と比較し、前者の方が古ければ最新のファームウェア５１３を含むデータ（ファームデータ）を返信する（Ｓ３）。また、最新のファームデータの返信の有無に拘わらず、次回ファーム更新日時が返信される。次回ファーム更新日時は、ファーム更新依頼を定期的に送信させるための管理情報であり、現時点より一定期間後の日時が指定される。

ファーム更新サービス５２０よりファームデータが返信されると、ファーム更新アプリ５１４は、セキュリティチップ５１１のファーム更新部５１２にそのファームデータを入力し、ファームウェア５１３の更新を要求する（Ｓ４）。また、ファーム更新アプリ５１４は、返信された次回ファーム更新日時を所定の不揮発領域に記録する。

ファーム更新部５１２は、入力されたファームデータに基づいて、セキュリティチップ５１１内のファームウェア５１３を更新する（Ｓ５）。

以上のように更新されるファームウェア５１３に関して、更新が必要であることは次のように検知され、ユーザに通知される。

コンテンツデータの再生指示がコンテンツ再生プレーヤアプリ５１５に対して入力されると、コンテンツ再生プレーヤアプリ５１５では、コンテンツ再生端末５１０の現在時刻（端末時刻）が次回ファーム更新日時に到達しているか否かを判定する。端末時刻が次回ファーム更新日時に到達している場合は、ファームウェア５１３の更新が必要であることを示すエラーを出力する。
当該エラーが出力された場合、コンテンツデータの再生は実行されない。したがって、コンテンツデータの再生をコンテンツ再生端末５１０に実行させるためには、ユーザは、ステップＳ５０１以降の処理をコンテンツ再生端末５１０に実行させなければならない。

特開２００８−１８１２２８号公報 特開２００５−１４８８４０号公報

しかしながら、上記の仕組みでは、ファームウェアの更新に対する強制力が非常に脆弱であるという問題があった。

すなわち、上記の仕組みでは、コンテンツ再生プレーヤアプリ５１５が、端末時刻と次回更新日時との比較に応じて、コンテンツデータの再生を拒否することにより、ファームウェア５１３の更新に対する強制力が確保されている。しかし、コンテンツ再生プレーヤアプリ５１５は、セキュリティチップに比べて、容易に改変可能な記憶媒体に記録されている。したがって、端末時刻が次回更新日時に到達していてもコンテンツデータの再生を実行可能なようにコンテンツ再生プレーヤアプリ５１５が改変される可能性があった。

また、次回ファーム更新日時と比較される端末時刻は、ユーザの操作により容易に変更できてしまう。したがって、例えば、コンテンツデータの再生時に端末時刻を過去に戻すことにより、次回ファーム更新日時との比較によるチェック機構が実施的に無効化されてしまう可能性があった。

なお、セキュリティチップ５１０内に時計が実装されていれば、時刻の変更は防止することができる。しかし、そのようなセキュリティチップ５１０は高価なものになってしまい、現実的はない。

本発明は、上記の点に鑑みてなされたものであって、ファームウェアの更新に関する強制力を向上させることのできるコンテンツデータ再生装置、更新管理方法、及び更新管理プログラムの提供を目的とする。

そこで上記課題を解決するため、セキュリティチップを有するコンテンツデータ再生装置であって、前記セキュリティチップは、ファームウェアプログラムを含むファームデータを記憶する記憶手段と、前記セキュリティチップに対する、コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記ファームデータに対して設定された期限情報と、ネットワークを介して受信される時間情報との比較に基づいて前記ファームデータの更新処理の実行の要否を判定し、前記更新処理の実行が必要な場合は、前記要求を拒否するファーム更新管理手段とを有し、前記ファームウェアプログラムは、前記セキュリティチップを、コンテンツデータを復号するためのコンテンツ鍵をネットワークを介して取得するコンテンツ鍵取得制御手段と、前記コンテンツ鍵を用いてコンテンツデータを復号する復号手段として機能させる。

ファームウェアの更新に関する強制力を向上させることができる。

従来のコンテンツ再生端末におけるファームウェアの更新機能を説明するための図である。 本発明の実施の形態におけるコンテンツ再生端末の機能構成例を示す図である。 ファーム管理情報の構成例を示す図である。 コンテンツ鍵配信サーバからのコンテンツ鍵の取得処理に関する機能構成例を示す図である。 コンテンツ鍵の取得処理の処理手順の一例を説明するためのフローチャートである。 コンテンツデータの再生処理に関する機能構成例を示す図である。 コンテンツデータの再生処理の処理手順を説明するためのフローチャートである。 ファームデータの更新処理に関する機能構成例を説明するための図である。 ファームデータ管理ＤＢの構成例を示す図である。 ファームデータの更新処理の処理手順の一例を説明するためのフローチャートである。 セキュアコネクション開設リクエストの構成例を示す図である。 セキュアコネクション開設レスポンスの構成例を示す図である。 ファーム更新リクエストの構成例を示す図である。 ファーム更新レスポンスの構成例を示す図である。 セキュアコネクション閉鎖リクエストの構成例を示す図である。 セキュアコネクション閉鎖レスポンスの構成例を示す図である。 本発明の実施の形態におけるコンテンツ再生端末のハードウェア構成等の一例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図２は、本発明の実施の形態におけるコンテンツ再生端末の機能構成例を示す図である。

コンテンツ再生端末１０は、ネットワークを介してコンテンツデータを受信し、当該コンテンツデータを再生する情報処理装置（コンテンツ再生装置の一例）である。コンテンツ再生端末１０の一例として、ＰＣ（Personal Computer）、ＩＰＴＶ（Internet Protocol Television）、ＳＴＢ（Set Top Box）や、携帯音楽プレーヤを搭載した各種の携帯型端末、電子書籍の再生装置等が挙げられる。

同図において、コンテンツ再生端末１０は、セキュリティチップ１１を有する。セキュリティチップ１１は、例えば、ＴＣＧ（Trusted Computing Group）が策定した仕様であるＴＰＭ（Trusted Platform Module）に準拠したＬＳＩである。したがって、セキュリティチップ１１内に記録された情報について、外部からの参照は非常に困難である。よって、セキュリティチップ１１内に記録された情報が改竄される可能性は非常に低い。

同図において、セキュリティチップ１１は、不揮発記憶部１２及びファーム更新部１３等を有する。不揮発記憶部１２は、セキュリティチップ１１内の不揮発性の記憶媒体における記憶領域である。不揮発記憶部１２は、記憶手段及び更新状態記憶手段の一例であり、ファーム管理情報１２１等を記憶する。ファーム管理情報１２１は、ファームデータを適切に更新させるための情報やファームデータ等を含む。ファームデータは、ファームウェアとしての各種プログラム及び各種データを格納したデータである。

図３は、ファーム管理情報の構成例を示す図である。同図において、ファーム管理情報１２１は、次回更新確認日時、最終確認サーバ日時、ファームＩＤ、ファーム版数、ファーム更新状態、ファーム更新用ルート公開鍵証明書のサイズ、ファーム更新用ルート公開鍵証明書、ファーム更新用クライアント公開鍵証明書のサイズ、ファーム更新用クライアント公開鍵証明書、ファーム更新用クライアント秘密鍵のサイズ、ファーム更新用クライアント秘密鍵、ファームデータ長、ファームデータ、ファームデータの電子署名のサイズ、ファームデータの電子署名、及びファーム更新サーバの公開鍵証明書等を含む。なお、同図に示されている各項目のデータサイズ（バイト数）は、例示である。

次回更新確認日時は、ファームデータに設定された期限情報の一例である。具体的には、次回更新確認日時は、ファーム更新サーバ２０に対してファームデータの更新要求（更新の要否の確認要求）が実行されなくても、コンテンツデータの利用等が許可される期限を示す日時（例えば、ＵＴＣ時刻）である。換言すれば、次回更新確認日時を経過した場合、ファームデータの更新要求が実行されなければ、コンテンツデータの再生は拒否される。次回更新確認日時は、ファームデータの更新要求に応じて更新される。すなわち、当該更新要求に応じて、新たな値（日時）がファーム更新サーバ２０より返信される。セキュリティチップ１１の初期状態（すなわち、コンテンツ再生端末１０の使用開始前の状態）において、次回更新確認日時の値は、例えば０（零）等の適当な初期値が設定されていればよい。次回更新確認日時の値が初期値の場合、ファームデータの更新要求が実行されないと、ファームデータをメモリにロードできないようにする。なお、ファームデータの更新要求に応じて、必ずしもファームデータが更新されるとは限らない。コンテンツ再生端末１０が有するファームデータが最新版であれば、更新は行われない。

最終確認サーバ日時は、ネットワークを介して受信される時間情報の一例である。具体的には、最終確認サーバ日時は、コンテンツ再生端末１０が、ファーム更新サーバ２０又はコンテンツ鍵配信サーバ３０に最後にアクセスした日時（例えば、ＵＴＣ時刻）である。すなわち、コンテンツ再生端末１０が、ファーム更新サーバ２０又はコンテンツ鍵配信サーバ３０にアクセスすると、最終確認サーバ日時はアクセス時の日時に更新される。なお、当該日時は、ファーム更新サーバ２０又はコンテンツ鍵配信サーバ３０より返信される値が用いられる。すなわち、当該日時は、コンテンツ再生端末１０の時計が示す値ではない。

ファームＩＤは、ファームウェア（ファームデータ）の種別を識別するための識別情報である。

ファーム版数は、コンテンツ再生端末１０に現在インストールされているファームデータの版数（バージョン番号）である。

ファーム更新状態は、ファームデータの更新処理の状態を示し、当該更新処理の過程において更新される。具体的には、当該更新処理の開始時に「更新中」に更新され、当該更新処理の終了時に「更新完了」に更新される。なお、本実施の形態では、０ｘ０１は「更新中」を示し、０ｘ００は「更新完了」を示す。

ファーム更新用ルート公開鍵証明書のサイズは、ファーム更新用のルート公開鍵のデータサイズ（バイト数）である。ファーム更新用ルート公開鍵証明書は、ファームデータの更新用（転送用）のセキュアな通信（暗号化通信）を確立するために用いられる、ルート認証局の公開鍵証明書である。

ファーム更新用クライアント公開鍵証明書のサイズは、ファーム更新用クライアント公開鍵証明書のデータサイズ（バイト数）である。ファーム更新用クライアント公開鍵証明書は、ファームデータの更新用（転送用）のセキュアな通信を確立するために用いられる、セキュリティチップ１１に対する公開鍵証明書である。

ファーム更新用クライアント秘密鍵のサイズは、ファーム更新用クライアント秘密鍵のデータサイズ（バイト数）である。ファーム更新用クライアント秘密鍵は、ファームデータの更新用（転送用）のセキュアな通信を確立するために用いられる、セキュリティチップ１１の秘密鍵である。

ファームデータ長は、ファームデータのデータサイズ（バイト数）である。ファームデータは、ファームデータの実体である。

ファームデータの電子署名のサイズは、ファームデータの電子署名のデータサイズ（バイト数）である。ファームデータの電子署名は、ファームデータに対する電子署名であり、ファーム更新サーバ２０によって生成される。ファーム更新サーバの公開鍵証明書は、ファームデータの電子署名を検査するための公開鍵証明書である。

なお、図３に示されるように、ファームデータは、コンテンツ鍵取得プログラム、暗号化コンテンツ復号プログラム、コンテンツ鍵取得用クライアントＤＲＭ秘密鍵、コンテンツ鍵取得用クライアントＤＲＭ公開鍵証明書、コンテンツ鍵取得用ルート公開鍵証明書等を含む。

コンテンツ鍵取得プログラムは、セキュリティチップ１１内のＲＡＭにロードされ、セキュリティチップ１１をコンテンツ鍵取得プロトコル制御部１４１として機能させるプログラムである。コンテンツ鍵取得プロトコル制御部１４１は、コンテンツ鍵取得制御手段の一例である。例えば、コンテンツ鍵取得プロトコル制御部１４１は、コンテンツ再生プレーヤアプリ１６によるコンテンツ鍵配信サーバ３０からのコンテンツデータの復号鍵（以下、「コンテンツ鍵」という。）の取得処理（ダウンロード）を制御する。

暗号化コンテンツ復号プログラムは、セキュリティチップ１１内のＲＡＭ１００２にロードされ、セキュリティチップ１１をコンテンツ再生部１４２として機能させるプログラムである。コンテンツ再生部１４２は、復号手段の一例である。例えば、コンテンツ再生部１４２は、コンテンツ再生プレーヤアプリ１６からの要求に応じ、コンテンツデータの復号及び再生等を実行する。

コンテンツ鍵取得用クライアントＤＲＭ秘密鍵は、コンテンツ鍵取得プロトコル制御部１４１がセキュアな通信を確立するために用いられる、セキュリティチップ１１の秘密鍵である。コンテンツ鍵取得用クライアントＤＲＭ公開鍵証明書は、コンテンツ鍵取得プロトコル制御部１４１がセキュアな通信を確立するために用いられる、セキュリティチップ１１に対する公開鍵証明書である。コンテンツ鍵取得用ルート公開鍵証明書は、コンテンツ鍵取得プロトコル制御部１４１がセキュアな通信を確立するために用いられる、ルート認証局の公開鍵証明書である。

図２に戻る。ファーム更新部１３は、ファームデータの更新処理を実行する。ファーム更新部１３は、ファーム更新プロトコル制御部１３１及びファーム更新管理部１３２等を含む。

ファーム更新プロトコル制御部１３１は、ファーム更新アプリ１５によるファーム更新サーバからのファームデータ等の取得処理（ダウンロード）に関する通信をセキュアなものとし、ダウンロードされたファームデータによって既存のファームデータを更新する。

ファーム更新管理部１３２は、ファーム管理情報１２１等に基づいてファームデータの更新の要否を判定する。なお、ファーム更新部１３は、ファームウェアとは別のプログラムが、セキュリティチップ１１のＣＰＵに実行させる処理により実現される仮想的な処理手段である。このように、本実施の形態のコンテンツ再生端末１０では、セキュリティチップ１１内において、ファームデータの更新をセキュアに実行するための機能が実装されている。

コンテンツ再生端末１０のセキュリティチップ１１外の記憶媒体には、ファーム更新アプリ１５及びコンテンツ再生プレーヤアプリ１６等のアプリケーションプログラムがインストールされている。ファーム更新アプリ１５は、ファームデータの更新指示の入力に応じ、ファーム更新プロトコル制御部１３１等を用いて、ファームデータの更新を実行する。コンテンツ再生プレーヤアプリ１６は、セキュリティチップ１１のコンテンツ鍵取得プロトコル制御部１４１又はコンテンツ再生部１４２等を利用してコンテンツデータ鍵のダウンロード又はコンテンツデータの再生を実行する。但し、コンテンツ再生プレーヤアプリ１６は、コンテンツデータの再生前に、ファーム更新管理部１３２にファームデータの更新の要否を問い合わせる。ファームウェアの更新が必要であることが応答された場合、コンテンツ再生プレーヤアプリ１６は、コンテンツデータの再生を拒否する。

ファーム更新サーバ２０は、ファームデータの更新処理を支援するコンピュータである。ファーム更新サーバ２０には、最新のファームデータが記憶されている。

コンテンツ鍵配信サーバ３０は、各種のコンテンツデータのコンテンツ鍵等を、コンテンツ鍵の識別子に関連付けて記憶するコンピュータである。コンテンツ鍵配信サーバ３０は、コンテンツ鍵の取得要求において指定された識別子に対応するコンテンツ鍵を返信する。

なお、ファーム更新サーバ２０とコンテンツ鍵配信サーバ３０とは、それぞれＮＴＰ（Network Time Protocol）等により適切に当該コンピュータの時計の時刻補正を行っていることとする。したがって、両者の時刻の差は十分に小さい（例えば５分未満）こととする。後述されるように、ファーム更新サーバ２０の時計が示す時刻と、コンテンツ鍵配信サーバ３０が示す時刻とは、同じパラメータ（最終確認サーバ日時）として利用されるからである。

以下、コンテンツ鍵配信サーバ３０からのコンテンツ鍵の取得処理、コンテンツデータの再生処理、及びファームデータの更新処理のそれぞれについて詳細に説明する。なお、暗号化されたコンテンツデータ及び当該コンテンツデータに対応するコンテンツ鍵の識別子については、既にコンテンツ再生端末１０にダウンロードされ、コンテンツ再生端末１０の所定の記憶媒体に保存されていることとする。当該所定の記憶媒体は、セキュリティチップ１１外に配置され、コンテンツ再生プレーヤアプリ１６が自由にアクセス可能な記憶媒体ある。

図４は、コンテンツ鍵配信サーバからのコンテンツ鍵の取得処理に関する機能構成例を示す図である。同図には、コンテンツ鍵の取得処理に関係する構成要素が図２より抽出されている。また、一部の構成要素について、その機能構成が詳細化されている。なお、図４中、図２と同一部分には同一符号を付し、その説明は省略する。

例えば、ファーム更新管理部１３２は、更新状態判定部１３２ａ及び更新要否判定部１３２ｂ等を含む。更新状態判定部１３２ａは、コンテンツ再生プレーヤアプリ１６からのセキュリティチップ１１に対する要求に応じ、ファーム管理情報１２１に含まれているファーム更新状態に基づいて、前回のファームデータの更新処理の状態を判定する。ファーム更新状態に問題が無い場合（すなわち、前回の更新処理が中断されていない場合）、更新状態判定部１３２ａは、更新要否判定部１３２ｂを呼び出す。

更新要否判定部１３２ｂは、ファーム管理情報１２１に含まれている最終確認サーバ日時と次回更新確認日時とを比較することにより、ファームデータの更新処理の要否を判定する。すなわち、本実施の形態では、コンテンツ再生端末１０が内蔵する時計が示す時刻は利用されない。したがって、現在時刻の代わりに最終確認サーバ日時が次回更新確認日時と比較される。最終確認サーバ日時は、必ずしも現在時刻ではない。但し、本実施の形態において、最終確認サーバ日時と現在時刻とのずれは許容される。更新処理が不要な場合、更新要否判定部１３２ｂは、コンテンツ鍵取得プロトコル制御部１４１を呼び出す。

コンテンツ鍵取得プロトコル制御部１４１は、コンテンツ鍵取得リクエスト生成部１４１ａ、及びコンテンツ鍵取得レスポンス受信部１４１ｂ、及びコンテンツ鍵更新部１４１ｃ等を有する。

コンテンツ鍵取得リクエスト生成部１４１ａは、コンテンツ鍵をセキュアに取得するためのリクエストデータ（以下、「コンテンツ鍵取得リクエスト」という。）を生成する。例えば、コンテンツ鍵取得リクエスト生成部１４１ａは、ＰＫＩ（Public Key Infrastructure）方式によりコンテンツ鍵配信サーバ３０との間で一時共用鍵を共用する。その際、コンテンツ鍵取得リクエスト生成部１４１ａは、ファームデータに含まれている、コンテンツ鍵取得用ルート公開鍵証明書、コンテンツ鍵取得用クライアント公開鍵証明書、及びコンテンツ鍵取得用クライアント秘密鍵等を使用する。なお、一時共用鍵の共用は例えば、ＥＣ−ＤＨ＋ＥＣ−ＤＳＡ＋ＳＨＡ、又はＲＳＡ−ＤＨ＋ＲＳＡ−ＤＳＡ＋ＳＨＡ等、公知の方式を用いて実現されればよい。コンテンツ鍵取得用プロトコルデータ処理部は、コンテンツ鍵取得リクエストの一部を、一時共用鍵によって暗号化する。

コンテンツ鍵取得レスポンス受信部１４１ｂは、コンテンツ鍵取得リクエストに応じてコンテンツ鍵配信サーバ３０より返信される応答（コンテンツ鍵取得レスポンス）を受信し、コンテンツ鍵取得レスポンスを一時共用鍵を用いて復号する。コンテンツ鍵取得レスポンスには、コンテンツ鍵及びコンテンツ鍵配信サーバ３０における時計が示す現在時刻（以下、「サーバ時刻」という。）が共に含まれている。更新要否判定部１３２ｂは、ファーム管理情報１２１の最終確認サーバ日時を当該サーバ時刻によって更新し、更新後の最終確認サーバ日時と次回更新確認日時とを比較することにより、改めて更新処理の要否を判定する。

コンテンツ鍵更新部１４１ｃは、更新要否判定部１３２ｂによって、更新後の最終確認サーバ日時に基づいて更新処理は不要であると判定された場合に、コンテンツ鍵取得レスポンスに含まれているコンテンツ鍵を不揮発記憶部のライセンスＤＢ１２２に記録する。ライセンスＤＢ１２２は、コンテンツ鍵をそれぞれの識別子と関連付けて記憶する。

図５は、コンテンツ鍵の取得処理の処理手順の一例を説明するためのフローチャートである。例えば、ユーザによるコンテンツ再生端末１０の操作により、コンテンツ再生プレーヤアプリ１６に対して、或るコンテンツデータに対するコンテンツ鍵の取得指示が入力されると、同図の処理が開始される。

ステップＳ１０１において、コンテンツ再生プレーヤアプリ１６は、セキュリティチップ１１に対して、コンテンツ鍵取得リクエストの生成要求を入力する（Ｓ１０１）。当該生成要求には、取得対象のコンテンツ鍵の識別子が指定される。

なお、アプリケーションからセキュリティチップ１１に対する要求の入力は、セキュリティチップ１１のドライバプログラムによって提供されるインタフェース（例えば、関数）を介して行われる。また、当該生成要求の入力は、セキュリティチップ１１に対する、コンテンツ鍵の取得要求の入力の一例に相当する。

コンテンツ鍵取得リクエストの生成要求に応じ、セキュリティチップ１１のファーム更新管理部１３２の更新状態判定部１３２ａは、ファーム管理情報１２１におけるファーム更新状態の値を確認する（Ｓ１０２）。ファーム更新状態が「更新中（０ｘ０１）」の場合（Ｓ１０２でＹｅｓ）、更新状態判定部１３２ａは、ファームデータの更新処理を実行し直す必要があることを示すエラーをコンテンツ再生プレーヤアプリ１６に返却する。後述されるように、ファーム更新状態が「更新中（０ｘ０１）」である状態は、例えば、電源断等により、ファームデータの更新処理が途中で終了してしまったままの状態であるからである。コンテンツ再生プレーヤアプリ１６は、当該エラーが返却されると、例えば、コンテンツ再生端末１０の液晶パネル等の表示部に、当該エラーを出力する（Ｓ１０３）。

一方、ファーム更新状態が「更新中（０ｘ０１）」でない場合（Ｓ１０２でＮｏ）、更新要否判定部１３２ｂは、ファーム管理情報１２１における、最終確認サーバ日時と次回更新確認日時とを比較する（Ｓ１０４）。最終確認サーバ日時が次回更新確認日時に到達又は経過している場合（すなわち、最終確認サーバ日時≧次回更新確認日時の場合）（Ｓ１０４でＹｅｓ）、更新要否判定部１３２ｂは、ファームデータの更新処理（厳密には、ファームデータの更新の要否の確認）の実行が必要であることを示すエラーをコンテンツ再生プレーヤアプリ１６に返却する。コンテンツ再生プレーヤアプリ１６は、当該エラーが返却されると、例えば、コンテンツ再生端末１０の表示部に、当該エラーを出力する（Ｓ１０５）。

一方、最終確認サーバ日時が次回更新確認日時に到達していない場合（Ｓ１０４でＮｏ）、ファーム更新管理部１３２は、コンテンツ鍵のコンテンツ鍵取得リクエストの生成をコンテンツ鍵取得プロトコル制御部１４１に要求する。当該要求には、取得対象のコンテンツ鍵の識別子が指定される。

続いて、コンテンツ鍵取得プロトコル制御部１４１のコンテンツ鍵取得リクエスト生成部１４１ａは、コンテンツ鍵取得リクエストを生成する（Ｓ１０６）。コンテンツ鍵取得リクエストは、取得対象のコンテンツ鍵の識別子を含み、ＰＫＩ方式に基づいてコンテンツ鍵取得プロトコル制御部１４１とコンテンツ鍵配信サーバ３０との間で共有されている一時共用鍵によって暗号化される。生成されたコンテンツ鍵取得リクエストは、コンテンツ再生プレーヤアプリ１６に出力される。

続いて、コンテンツ再生プレーヤアプリ１６は、生成されたコンテンツ鍵取得リクエストをコンテンツ鍵配信サーバ３０に送信する（Ｓ１０７）。

コンテンツ鍵配信サーバ３０は、コンテンツ鍵取得リクエストを受信すると、当該リクエストに指定されている識別子に対応するコンテンツ鍵を取得する。更に、コンテンツ鍵配信サーバ３０は、自機（コンテンツ鍵配信サーバ３０）における時計が示す現在時刻（以下、「サーバ時刻」という。）を取得する。続いて、コンテンツ鍵配信サーバ３０は、コンテンツ鍵及びサーバ時刻を共に含むコンテンツ鍵取得レスポンスを生成し、コンテンツ鍵取得レスポンスを一時共用鍵によって暗号化された状態で返信する（Ｓ１０８）。コンテンツ再生プレーヤアプリ１６は、コンテンツ鍵取得レスポンスを受信すると、当該レスポンスをセキュリティチップ１１に入力する（Ｓ１０９）。

セキュリティチップ１１のコンテンツ鍵取得レスポンス受信部１４１ｂは、コンテンツ鍵取得レスポンスを受け付けると（Ｓ１１０）、当該レスポンスに含まれているサーバ時刻を指定して、ファーム更新管理部１３２の更新要否判定部１３２ｂに、更新処理の要否を問い合わせる。なお、コンテンツ鍵取得レスポンス受信部１４１ｂは、一時共用鍵によってコンテンツ鍵取得レスポンスを復号する。

更新要否判定部１３２ｂは、指定されたサーバ時刻によってファーム管理情報１２１の最終確認サーバ日時を更新する（Ｓ１１１）。続いて、更新要否判定部１３２ｂは、更新後の最終確認サーバ日時と次回更新確認日時とを比較する（Ｓ１１２）。最終確認サーバ日時が次回更新確認日時に到達又は経過している場合（すなわち、最終確認サーバ日時≧次回更新確認日時の場合）（Ｓ１１２でＹｅｓ）、更新要否判定部１３２ｂは、ファームデータの更新処理（厳密には、ファームデータの更新の要否の確認）の実行が必要であることを示すエラーをコンテンツ鍵レスポンス受信部に返却する。

コンテンツ鍵取得レスポンス受信部１４１ｂは、当該エラーを受けて、上記レスポンス（すなわち、取得されたコンテンツ鍵）を破棄する（Ｓ１１３）。したがって、この場合、コンテンツ鍵はライセンスＤＢ１２２に保存されない。続いて、コンテンツ鍵取得レスポンス受信部１４１ｂは、当該エラーをコンテンツ再生プレーヤアプリ１６に出力する。コンテンツ再生プレーヤアプリ１６は、当該エラーが返却されると、例えば、コンテンツ再生端末１０の表示部に、当該エラーを出力する（Ｓ１１４）。

一方、最終確認サーバ日時が次回更新確認日時に到達していない場合（Ｓ１１２でＮｏ）、コンテンツ鍵更新部１４１ｃは、コンテンツ鍵取得レスポンスに含まれているコンテンツ鍵をライセンスＤＢ１２２に記録する（Ｓ１１５）。この際、当該コンテンツ鍵は、ステップＳ１０１において指定された識別子に関連付けられてライセンスＤＢ１２２に記録される。続いて、コンテンツ鍵更新部１４１ｃは、コンテンツ鍵の取得処理が正常終了したことをコンテンツ再生プレーヤアプリ１６に出力する。

正常終了したことを受けて、コンテンツ再生プレーヤアプリ１６は、コンテンツ鍵の取得処理を終了させる（Ｓ１１６）。

次に、コンテンツデータの再生処理について説明する。図６は、コンテンツデータの再生処理に関する機能構成例を示す図である。同図には、コンテンツデータの再生処理に関係する構成要素が図２より抽出されている。また、一部の構成要素について、その機能構成が詳細化されている。なお、図６中、図４又は図２と同一部分には同一符号を付し、その説明は省略する。

同図において、コンテンツ再生部１４２は、暗号化コンテンツ復号環境作成部１４２ａ及び再生制御部１４２ｂ等を含む。暗号化コンテンツ復号環境作成部１４２ａは、再生対象とされた、暗号化されているコンテンツデータ（暗号化コンテンツ１６１）を、復号するための環境（暗号化コンテンツ復号環境）をセキュリティチップ１１内に作成する。すなわち、暗号化コンテンツ復号環境作成部１４２ａは、セキュリティチップ１１を、暗号化コンテンツ１６１の復号を実行可能な状態とする。

再生制御部１４２ｂは、暗号化コンテンツ復号環境において、暗号化コンテンツ１６１を復号し、復号されたコンテンツデータの再生を制御する。

図７は、コンテンツデータの再生処理の処理手順を説明するためのフローチャートである。例えば、ユーザによるコンテンツ再生端末１０の操作により、コンテンツ再生端末１０に保存されている暗号化コンテンツ１６１が選択される。続いて、選択された暗号化コンテンツ１６１の再生指示がコンテンツ再生プレーヤアプリ１６に対して入力されると、同図の処理が開始される。

ステップＳ２０１において、コンテンツ再生プレーヤアプリ１６は、セキュリティチップ１１に対して、暗号化コンテンツ１６１の復号環境の作成要求を入力する（Ｓ１０１）。復号環境の作成とは、セキュリティチップ１１を、暗号化コンテンツ１６１を復号化できる状態にすることをいう。当該要求には、再生対象とされたコンテンツデータに対応するコンテンツ鍵の識別子が指定される。なお、当該復号環境の作成要求は、セキュリティチップ１１に対する、コンテンツデータの復号要求の一例に相当する。

続いて、ステップＳ２０２〜Ｓ２０５は、図５のＳ１０２〜Ｓ１０５と同様であるため、その説明は省略する。すなわち、前回のファームデータの更新状態が「更新中」であった場合、エラーが出力される。また、最終確認サーバ日時が次回更新確認日時に到達又は経過している場合（すなわち、最終確認サーバ日時≧次回更新確認日時の場合）、エラーが出力される。

最終確認サーバ日時が次回更新確認日時に到達していない場合（Ｓ２０４でＮｏ）、ファーム更新管理部１３２は、コンテンツ鍵の識別子を指定して暗号化コンテンツ復号環境の作成を暗号化コンテンツ復号環境作成部１４２ａに要求する。暗号化コンテンツ復号環境作成部１４２ａは、指定された識別子に対応するコンテンツ鍵はライセンスＤＢ１２２に記録されているか否かを判定する（Ｓ２０６）。すなわち、再生対象の暗号化コンテンツ１６１に対応するコンテンツ鍵は取得済みであるか否かが判定される。

該当するコンテンツ鍵がライセンスＤＢ１２２に記録されていない場合（Ｓ２０６でＮｏ）、暗号化コンテンツ復号環境作成部１４２ａは、コンテンツ鍵が無いことを示すエラーをコンテンツ再生プレーヤアプリ１６に返却する。コンテンツ再生プレーヤアプリ１６は、当該エラーが返却されると、例えば、コンテンツ再生端末１０の表示部に、当該エラーを出力する（Ｓ２０７）。この場合、ユーザは、図７によって説明した、コンテンツ鍵の取得処理をコンテンツ再生端末１０に実行させた後、改めて、図１０の処理を開始させればよい。又は、コンテンツ再生プレーヤアプリ１６が、図７のステップＳ１０７以降を自動的に開始してもよい。

一方、該当するコンテンツ鍵がライセンスＤＢ１２２に記録されている場合（Ｓ２０６でＹｅｓ）、暗号化コンテンツ復号環境作成部１４２ａは、暗号化コンテンツ復号環境を作成し、当該暗号化コンテンツ復号環境の識別子（復号環境ハンドラ）をコンテンツ再生プレーヤアプリ１６に返却する（Ｓ２０８）。なお、暗号化コンテンツ復号環境の作成に応じ、該当するコンテンツ鍵が、当該暗号化コンテンツ復号環境における復号用の鍵として、セキュリティチップ１１のメモリにロードされる。

復号環境ハンドラが返却されると、コンテンツ再生プレーヤアプリ１６は、再生対象の暗号化コンテンツ１６１と復号環境ハンドラとを指定して、セキュリティチップ１１に対して当該暗号化コンテンツ１６１の再生要求を入力する（Ｓ２０９）。

セキュリティチップ１１の再生制御部１４２ｂは、再生要求において指定された復号環境ハンドラに対応する暗号化コンテンツ復号環境において暗号化コンテンツ１６１を復号し、復号されたコンテンツデータを再生させる（Ｓ２１０）。復号環境ハンドラに対応する暗号化コンテンツ復号環境における暗号化コンテンツ１６１の復号とは、当該復暗号化コンテンツ復号環境おけるコンテンツ鍵による暗号化コンテンツ１６１の復号をいう。なお、ステップＳ２０９及びＳ２１０は、暗号化コンテンツ１６１を所定の単位に分割した分割単位ごとに繰り返し実行される。通常、セキュリティチップ１１は、暗号化コンテンツ１６１の全部を一度に復号するだけのメモリ容量を有していないからである。

次に、ファームデータの更新処理について説明する。図８は、ファームデータの更新処理に関する機能構成例を説明するための図である。同図には、ファームデータの更新処理に関係する構成要素が図２より抽出されている。また、一部の構成要素について、その機能構成が詳細化されている。なお、図８中、図６、図４、又は図２と同一部分には同一符号を付し、その説明は省略する。

同図において、ファーム更新プロトコル制御部１３１は、ファーム更新リクエスト生成部１３１ａ及びファーム更新レスポンス受信部１３１ｂ等を含む。

ファーム更新リクエスト生成部１３１ａは、コンテンツ鍵をセキュアに取得するためのリクエストデータ（例えば、ファームデータの更新のリクエストデータ（以下、「ファーム更新リクエスト」という。）を生成する。例えば、ファーム更新リクエスト生成部１３１ａは、ＰＫＩ（Public Key Infrastructure）方式によりファーム更新サーバ２０のファームデータ提供部２１との間で一時共用鍵を共用する。その際、ファーム更新リクエスト生成部１３１ａは、ファーム管理情報１２１に含まれている、ファーム更新用ルート公開鍵証明書、ファーム更新用クライアント公開鍵証明書、及びファーム更新用クライアント秘密鍵を使用する。なお、一時共用鍵の共用は例えば、ＥＣ−ＤＨ＋ＥＣ−ＤＳＡ＋ＳＨＡ、又はＲＳＡ−ＤＨ＋ＲＳＡ−ＤＳＡ＋ＳＨＡ等、公知の方式を用いて実現されればよい。また、ファームデータ提供部２１は、ファーム更新サーバ２０の秘密鍵によりファームデータの電子署名を生成し、ファームデータを上記一時共用鍵により暗号化したものに当該電子署名を付加して返信する。当該電子署名は、ファーム管理情報１２１の一部（「ファームデータの電子署名」）として管理される。当該電子署名は、例えば、ＥＣ−ＤＳＡ＋ＳＨＡ、又はＲＳＡ−ＤＳＡ＋ＳＨＡ等の方式により生成される。

ファーム更新レスポンス受信部１３１ｂは、ファーム更新リクエストに応じてファームデータ提供部２１より返信されるレスポンス（ファーム更新レスポンス）を受信する。ファーム更新レスポンスにファームデータが含まれている場合、当該ファームデータによって、既存のファームデータが更新される。

ファーム更新サーバ２０は、ファームデータ提供部２１及びファームデータ管理ＤＢ２２等を有する。

ファームデータ管理ＤＢ２２は、ファームデータの更新に関する管理情報を記憶するデータベースである。

図９は、ファームデータ管理ＤＢの構成例を示す図である。ファームデータ管理ＤＢ２２の各レコードは、チップＩＤ、ファームＩＤ、最新ファーム版数、次回更新確認日時、ファームデータ長、及びファームデータ等を含む。

チップＩＤは、セキュリティチップ１１を一意に識別するための識別情報である。ファームＩＤは、対象とするファームデータのファームＩＤである。同一のファームＩＤに係るファームデータに対して、複数の版（バージョン）が存在しうる。最新ファーム版数は、ファームＩＤで識別されるファームウェアの最新版の版数である。次回更新確認日時は、チップＩＤに対応するセキュリティチップ１１（コンテンツ再生端末１０）に最後に返信された次回更新確認日時である。ファームデータ長は、最新版のファームデータのデータサイズ（バイト数）である。ファームデータは、最新版のファームデータである。

図８に戻る。ファームデータ提供部２１は、ファーム更新リクエストに応じ、ファーム更新レスポンスを返信する。ファーム更新レスポンスには、必要に応じてファームデータ等が含められる。ファームデータを返信する必要が無い場合であっても、次回更新確認日時及びファーム更新サーバ２０のサーバ時刻は、ファーム更新レスポンスに含められる。

図１０は、ファームデータの更新処理の処理手順の一例を説明するためのフローチャートである。例えば、コンテンツ鍵取得処理時又はコンテンツ再生処理時等において、ファームデータの更新処理が必要であることを示すエラーが出力されると、ユーザは、ファーム更新アプリ１５に対して、ファームデータの更新指示を入力する。当該更新指示に応じて図１０の処理は開始される。

ステップＳ３０１において、ファーム更新アプリ１５は、ファーム更新リクエストの生成要求をセキュリティチップ１１に入力する。続いて、セキュリティチップ１１のファーム更新リクエスト生成部１３１ａは、当該セキュリティチップ１１のチップＩＤと、ファーム管理情報１２１に含まれているファームＩＤ及びファーム版数とを含むファーム更新リクエストを生成する（Ｓ３０２）。ファームＩＤ及びファーム版数は、ファーム更新管理部１３２を介してファーム管理情報１２１より取得される。当該ファーム更新リクエストは、一時共用鍵によって少なくとも一部が暗号化される。ファーム更新リクエスト生成部１３１ａは、生成されたファーム更新リクエストをファーム更新アプリ１５に返却する。

続いて、ファーム更新アプリ１５は、当該ファーム更新リクエストをファーム更新サーバ２０に送信する（Ｓ３０３）。ファーム更新サーバ２０のファームデータ提供部２１は、ファーム更新リクエストに指定されたチップＩＤ、ファームＩＤに対応するレコードをファームデータ管理ＤＢ２２より検索する（Ｓ３０４）。続いて、ファームデータ提供部２１は、検索されたレコード（以下、「カレントレコード」という。）の最新ファーム版数とファーム更新リクエストに含まれているファーム版数（以下、「現ファーム版数」という。）とを比較する（Ｓ３０５）。

現ファーム版数が最新ファーム版数と一致する場合（Ｓ３０５でＹｅｓ）、ファームデータ提供部２１は、ファームデータを含まないファーム更新レスポンス（以下、「更新不要レスポンス」という。）を返信する（Ｓ３０６）。但し、更新不要レスポンスには、ファーム更新サーバ２０のサーバ時刻（現在時刻）、及び次回更新確認日時等が含められる。

一方、現ファーム版数が最新ファーム版数より古い場合（Ｓ３０５でＮｏ）、ファームデータ提供部２１は、ファーム更新サーバ２０に対するファーム更新用サーバＤＲＭ秘密鍵を用いて、カレントレコードのファームデータの電子署名を生成する（Ｓ３０７）。続いて、ファームデータ提供部２１は、ファームデータを含むファームデータ更新レスポンスを生成し、当該ファーム更新レスポンスを返信する（Ｓ３０８）。ファーム更新レスポンスには、カレントレコードに含まれている、最新ファーム版数及びファームデータと、次回更新確認日時、ファーム更新サーバ２０のサーバ時刻、及び生成された電子署名当該が含められる。また、当該ファーム更新レスポンスの少なくとも一部は、一時共用鍵によって暗号化される。

なお、ステップＳ３０６又はＳ３０８のレスポンスに含められる次回更新日時の値については、運用に応じて適宜決定すればよい。例えば、現在時刻から所定期間後を次回更新日時としてもよい。レスポンスに含められた次回更新日時は、ファームデータ管理ＤＢ２２のカレントレコードに記録される。また、ファームデータの更新時期についても、運用に応じて適宜決定すればよい。

コンテンツ再生端末２０のファーム更新アプリ１５は、ステップＳ３０６又はＳ３０８において返信された更新不要レスポンス又はファーム更新レスポンスを受信すると（Ｓ３１１又はＳ３１２）、当該レスポンスをセキュリティチップ１１に入力する
セキュリティチップ１１のファーム更新レスポンス受信部１３１ｂは、当該レスポンスを受け付けると（Ｓ３１３）、当該レスポンスの内容に応じて処理を分岐させる（Ｓ３１４）。

すなわち、当該レスポンスが更新不要レスポンスであった場合（Ｓ３１４でＮｏ）、ファーム更新レスポンス受信部１３１ｂは、ファームデータの更新は不要であると判断し、ファーム更新レスポンスに含まれている次回更新確認日時及びサーバ時刻等を指定してファーム更新管理部１３２を呼び出す。ファーム更新管理部１３２は、当該情報によってファーム管理情報１２１を更新する（Ｓ３１５）。具体的には、指定された次回更新確認日時によって、ファーム管理情報１２１の次回更新確認日時が更新される。また、指定されたサーバ時刻によって、ファーム管理情報１２１の最終確認サーバ日時が更新される。

続いて、ファーム更新管理部１３２は、ファーム管理情報１２１のファーム更新状態が「更新中」であれば（Ｓ３１６でＹｅｓ）、当該ファーム更新状態を「更新完了」に変更し、不揮発記憶部１２内のファームデータをロードし直して、更新処理を終了させる（Ｓ３１７）。その結果、ファームウェアは実行可能な状態となる。

なお、ステップＳ３１６の段階で、ファーム管理情報１２１のファーム更新状態が「更新中」である場合とは、前回の更新処理が中断された場合である。

一方、受け付けられたレスポンスがファームデータを含むファーム更新レスポンスであった場合（Ｓ３１４でＹｅｓ）、ファーム更新レスポンス受信部１３１ｂは、当該ファーム更新レスポンスに含まれているファームデータについて、改竄の有無をチェックする（Ｓ３１８）。改竄の有無のチェックには、当該ファーム更新レスポンスに含まれている電子署名が使用される。

ファームデータに対する改竄が検知された場合（Ｓ３１８でＹｅｓ）、ファーム更新レスポンス受信部１３１ｂは、ファームデータが改竄されていることを示すエラーをファーム更新アプリ１５に出力する。コンテンツ更新アプリは、当該エラーに応じ、例えば、コンテンツ再生端末１０の表示部に、当該エラーを出力する（Ｓ３１９）。

アームデータに対する改竄が検知されなかった場合（Ｓ３１８でＮｏ）、ファーム更新レスポンス受信部１３１ｂは、ファーム更新管理部１３２に対してファームデータの更新を要求する。当該要求には、ファーム更新レスポンスに含まれているデータが指定される。

当該要求に応じ、ファーム更新管理部１３２は、以下の手順によってファームデータ等の更新を行う（Ｓ３２０）。
（１）ファーム管理情報１２１のファーム更新状態を「更新中」に変更する。
（２）ファーム管理情報１２１のファームデータ及び電子署名を、指定されたデータに含まれているファームデータ及び電子署名によって更新する。
（３）ファーム管理情報１２１のファーム版数を、指定されたデータに含まれているファーム版数によって更新する。
（４）ファーム管理情報１２１の次回更新確認日時の値を、指定されたデータに含まれている次回更新日時によって更新する。
（５）ファーム管理情報１２１の最終確認サーバ日時の値を、指定されたデータに含まれているサーバ時刻によって更新する。
（６）ファーム管理情報１２１のファーム更新状態を「更新完了」に変更する。

このように、ファーム管理情報１２１のファーム更新状態は、ファームデータの更新に伴って更新が必要となる情報が全て更新された場合に、「更新完了」に戻される。したがって、上記（１）以降（５）までの間に、電源断等によって処理が中断された場合、ファーム更新状態は「更新中」のままとなる。

続いて、ファーム更新管理部１３２は、更新されたファームデータをセキュリティチップ１１内のメモリロードし、ファームウェアを実行可能状態とする（Ｓ３２１）。なお、ファームデータのロードのタイミングとファームウェア実行とのシリアライズについては公知技術に従えばよい。

ところで、図１０では、ファーム更新リクエストと当該リクエストに対するレスポンスとが、一回の（一往復の）通信によって実現されているように示されているが、厳密には、複数回の通信によって実現される。

例えば、まず、セキュアな通信（コネクション）の開設要求（セキュアコネクション開設リクエスト）がファーム更新リクエスト生成部１３１ａによって生成され、ファーム更新アプリ１５からファーム更新サーバ２０に送信される。

図１１は、セキュアコネクション開設リクエストの構成例を示す図である。同図において、セキュアコネクション開設リクエストは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＣｈｉｐＩＤ、ＲａｎｄａｏｍＮｕｍｂｅｒ、ＣｅｒｔｉｆｉｃａｔｅＳｉｚｅ、及びＣｅｒｔｉｆｉｃａｔｅ等の項目を含む。

ＲｅｑｕｅｓｔＩＤは、リクエストの種別を示す。したがって、ＲｅｑｕｅｓｔＩＤには、セキュアコネクション開設リクエストを示す値が指定される。Ｖｅｒｓｉｏｎは、プロトコルのバージョンである。ＣｈｉｐＩＤは、セキュリティチップ１１のＩＤ（すなわち、上記におけるチップＩＤ）である。ＲａｎｄｏｍＮｕｍｂｅｒは、成りすましを防止（又は検知）するためにコネクションごとに生成されるクライアント側（セキュリティチップ１１側）の乱数値である。コネクションとは、開設要求に応じて開設され、閉鎖要求に応じて閉鎖されるまでの一連の通信単位をいう。ＣｅｒｔｉｆｉｃａｔｅＳｉｚｅは、Ｃｅｒｔｉｆｉｃａｔｅのデータサイズである。Ｃｅｒｔｉｆｉｃａｔｅは、ファーム更新用クライアント公開鍵であり、ファーム管理情報１２１より取得される。

セキュアコネクション開設リクエストに応じ、ファーム更新サーバ２０のファームデータ提供部２１は、セキュアコネクション開設レスポンスを生成し、返信する。

図１２は、セキュアコネクション開設レスポンスの構成例を示す図である。同図において、セキュアコネクション開設レスポンスは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＲａｎｄａｏｍＮｕｍｂｅｒ、ＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅ、Ｓｉｇｎａｔｕｒｅ、ＣｅｒｔｉｆｉｃａｔｅＳｉｚｅ、及びＣｅｒｔｉｆｉｃａｔｅ等の項目を含む。

ＲｅｑｕｅｓｔＩＤには、セキュアコネクション開設レスポンスを示す値が指定される。Ｖｅｒｓｉｏｎは、プロトコルのバージョンである。ＲａｎｄａｏｍＮｕｍｂｅｒは、サーバ側（ファーム更新サーバ２０側）の乱数値である。ＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅは、ファーム更新サーバ２０のファームデータ提供部２１が作成した一時公開鍵である。Ｓｉｇｎａｔｕｒｅは、セキュアコネクション開設レスポンスに含まれているＲａｎｄｏｍＮｕｍｂｅｒの値と、第４項目のＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅの値とを結合した値を、ファーム更新用サーバ秘密鍵で署名した値である。ＣｅｒｔｉｆｉｃａｔｅＳｉｚｅは、Ｃｅｒｔｉｆｉｃａｔｅのデータサイズである。Ｃｅｒｔｉｆｉｃａｔｅは、ファーム更新用サーバ公開鍵であり、ファーム更新サーバ２０に予め保存されている。

セキュアなコネクションが開設されると、ファーム更新リクエストが図７において説明された手順で生成及び送信される。

図１３は、ファーム更新リクエストの構成例を示す図である。同図において、ファーム更新リクエストは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＣｈｉｐＩＤ、ＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅ、Ｓｉｇｎａｔｕｒｅ、ＰａｒａｍｅｔｅｒＳｉｚｅ、ＣｈｉｐＩＤ、ＦｉｒｍＩＤ、及びＦｉｒｍＶｅｒｓｉｏｎ等の項目を含む。ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、及びＣｈｉｐＩＤの説明については上記より自明であるため省略する。

ＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅは、ファーム更新リクエスト生成部１３１ａが作成した一時公開鍵である。Ｓｉｇｎａｔｕｒｅは、セキュアコネクション開設レスポンスに含まれているＲａｎｄｏｍＮｕｍｂｅｒの値とＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅの値とを結合した値を、ファーム更新用クライアント秘密鍵で署名した値である。ＰａｒａｍｅｔｅｒＳｉｚｅは、ファーム更新リクエストのパラメータのデータサイズである。本実施の形態において、当該パラメータは、第７項目から第９項目の、ＣｈｉｐＩＤ、ＦｉｒｍＩＤ、及びＦｉｒｍＶｅｒｓｉｏｎである。ＣｈｉｐＩＤは、セキュリティチップ１１のチップＩＤである。ＦｉｒｍＩＤは、ファーム管理情報１２１に含まれているファームＩＤである。ＦｉｒｍＶｅｒｓｉｏｎは、ファーム管理情報１２１に含まれているファーム版数である。

なお、ファーム更新リクエスト生成部１３１ａは、自身が作成した一時秘密鍵と、セキュアコネクション開設レスポンスの第４項目に含まれていたＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅ（一時公開鍵）とを用いて、ＥＣ−ＤＨ（素体２２４ビット鍵）により一時共用鍵（ＡＥＳ １２８ビット）を作成する。ファーム更新リクエストのパラメータ（第７項目から第９項目）は、当該一時共用鍵によって暗号化される。

ファーム更新リクエストに応じ、ファーム更新サーバ２０のファームデータ提供部２１は、ファーム更新レスポンスを生成し、返信する。

図１４は、ファーム更新レスポンスの構成例を示す図である。同図において、ファーム更新レスポンスは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＰａｒａｍｅｔｅｒＳｉｚｅ、ＮｅｘｔＣｈｅｃｋＤａｔｅＴｉｍｅ、ＳｅｒｖｅｒＴｉｍｅ、ＦｉｒｍＶｅｒｓｉｏｎ、ＦｉｒｍＤａｔａＳｉｚｅ、ＦｒｉｍＤａｔａ、及びＤｉｇｅｓｔ等の項目を含む。ＲｅｑｕｅｓｔＩＤ及びＶｅｒｓｉｏｎの説明については上記より自明であるため省略する。

ＰａｒａｍｅｔｅｒＳｉｚｅは、ファーム更新レスポンスのパラメータ（第４項目から第９項目）のデータサイズである。ＮｅｘｔＣｈｅｃｋＤａｔｅＴｉｍｅは、次回更新確認日時である。ＳｅｒｖｅｒＴｉｍｅは、ファーム更新サーバ２０のサーバ時刻である。ＦｉｒｍＶｅｒｓｉｏｎは、第８項目に含まれるファームデータのファーム版数である。ファームデータの更新が不要な場合（すなわち、ファームデータが返信されない場合）、ＦｉｒｍＶｅｒｓｉｏｎの値は無効となる。ＦｉｒｍＤａｔａＳｉｚｅは、第８項目に含まれるファームデータのデータサイズである。ファームデータの更新が不要な場合、ＦｉｒｍＤａｔａＳｉｚｅの値は０となる。ＦｉｒｍＤａｔａは、最新のファームデータである。ファームデータの更新が不要な場合、当該項目はファーム更新レスポンスに含まれない。Ｄｉｇｅｓｔは、第１項目から第８項目までのＳＨＡ−２５６のメッセージダイジェストである。但し、ファームデータの更新が不要な場合、Ｄｉｇｅｓｔは、第１項から第７項目までのメッセージダイジェストである。

なお、ファームデータ提供部２１は、自身が作成した一時秘密鍵と、ファーム更新要リクエストの第４項目に含まれていたＥＣ−ＤＨＰｈａｖｅ１Ｖａｌｕｅ（一時公開鍵）とを用いて、ＥＣ−ＤＨ（素体２２４ビット鍵）により一時共用鍵（ＡＥＳ １２８ビット）を作成する。ファーム更新レスポンスのパラメータ（第４項目から第９項目）は、当該一時共用鍵によって暗号化される。

セキュアなコネクションを閉鎖する場合、当該コネクションの閉鎖要求（セキュアコネクション閉鎖リクエスト）がファーム更新リクエスト生成部１３１ａによって生成され、ファーム更新アプリ１５からファーム更新サーバ２０に送信される。

図１５は、セキュアコネクション閉鎖リクエストの構成例を示す図である。同図において、セキュアコネクション閉鎖リクエストは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＣｈｉｐＩＤ、ＰａｒａｍｅｔｅｒＳｉｚｅ、及びＤｉｇｅｓｔ等の項目を含む。ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、及びＣｈｉｐＩＤの説明については、上記より自明であるため省略する。

ＰａｒａｍｅｔｅｒＳｉｚｅは、第５項目のＤｉｇｅｓｔのデータサイズである。Ｄｉｇｅｓｔは、第一項目から第４項目までのＳＨＡ−２５６のメッセージダイジェストである。なお、Ｄｉｇｅｓｔは、ファーム更新リクエスト生成部１３１ａが作成した一時共用鍵によって暗号化される。

セキュアコネクション閉鎖リクエストに応じ、ファーム更新サーバ２０のファームデータ提供部２１は、セキュアコネクション閉鎖レスポンスを生成し、返信する。

図１６は、セキュアコネクション閉鎖レスポンスの構成例を示す図である。同図において、セキュアコネクション閉鎖レスポンスは、ＲｅｑｕｅｓｔＩＤ、Ｖｅｒｓｉｏｎ、ＰａｒａｍｅｔｅｒＳｉｚｅ、ＲｅｔｕｒｎＣｏｄｅ、及びＤｉｇｅｓｔ等の項目を含む。ＲｅｑｕｅｓｔＩＤ及びＶｅｒｓｉｏｎの説明については、上記より自明であるため省略する。

ＰａｒａｍｅｔｅｒＳｉｚｅは、第４項目及び第５項目のデータサイズである。ＲｅｔｕｒｎＣｏｄｅは、復帰コードである。Ｄｉｇｅｓｔは、第一項目から第４項目までのＳＨＡ−２５６のメッセージダイジェストである。なお、第４項目及び第５項目は、ファームデータ提供部２１が作成した一時共用鍵によって暗号化される。

続いて、コンテンツ再生端末１０のハードウェア構成の一例と、図２等に示される各部とハードウェアとの関係について説明する。

図１７は、本発明の実施の形態におけるコンテンツ再生端末のハードウェア構成等の一例を示す図である。図１７中、図２と同一部分には同一符号を付し、その説明は適宜省略する。同図には、セキュリティチップ１１に加え、メインＣＰＵ１００１、ＲＡＭ１００２、ＲＯＭ１００３、ＨＤＤ１００４、及び通信インタフェース１００５等が、コンテンツ再生端末を構成するハードウェアとして例示されている。

メインＣＰＵ１００１は、ファーム更新アプリ１５、コンテンツ再生プレーヤアプリ１６、及びドライバプログラム１７等に基づいて、それぞれの機能を実現する。なお、ドライバプログラム１７は、セキュリティチップ１１に対するソフト的なインタフェースを提供するドライバプログラムである。ＲＡＭ１００２は、ファーム更新アプリ１５、コンテンツ再生プレーヤアプリ１６、及びドライバプログラム１７等を実行時にロードする領域等として利用される。ＲＯＭ１００３は、ファーム更新アプリ１５、コンテンツ再生プレーヤアプリ１６、及びドライバプログラム１７等を記憶する。ＨＤＤ１００４は、暗号化コンテンツ１６１等の保存領域として用いられる。なお、コンテンツ再生端末１０の特性に応じて、ＨＤＤ１００４（Hard Disk Drive）の代わりに、他の不揮発性の記憶媒体が用いられてもよい。当該不揮発性の記憶媒体は、メモリカードのように取り外し可能であってもよい。通信インタフェース１００５は、例えば、ＬＡＮ（有線又は無線の別は問わない）等のネットワーク又は移動体通信網等を介した通信を実現するためのハードウェアである。ファーム更新アプリ１５及びコンテンツ再生プレーヤアプリ１６等は、通信インタフェース１００５を用いて、ファーム更新サーバ２０又はコンテンツ鍵配信サーバ３０等と通信を行う。

セキュリティチップ１１は、ＵＳＢ１１０１、ＲＯＭ１１０２、ＲＡＭ１１０３、ＣＰＵ１１０４、ＡＥＳ１２８ｂｉｔチップ１１０５、ＥＣ−ＤＨチップ１１０６、ＥＣ−ＤＳＡチップ１１０７、ＳＨＡ−２５６チップ１１０８、ＳＨＡ−１チップ１１０９、ＲＮＧチップ１１１０、不揮発性記憶媒体１１１１、Ｄｅｍｕｘｅｒ１１１２、Ｄ／ＡＣｏｎｖｅｒｔｅｒ１１１３、Ｈ．２６４Ｄｅｃｏｄｅｒ１１１４、ＡＡＣＤｅｃｏｄｅｒ１１１５、及びＨＤＭＩ１１１６等のハードウェアを含む。

ＵＳＢ１１０１は、メインＣＰＵ１００１等が接続されるバスとセキュリティチップ１１とをＵＳＢ接続するためのインタフェースである。ＲＯＭ１１０２は、ＣＰＵ１１０４をファーム更新部１３として機能させるためのプログラム（以下、「ファーム更新プログラム」という。）等を記憶する。ＲＡＭ１１０３は、ファーム更新プログラムやファームウェア等の実行時のロード領域として用いられる。ＣＰＵ１１０４は、ファーム更新プログラム又はファームウェア等に基づいて、ファーム更新部１３、コンテンツ鍵取得プロトコル制御部１４１、及びコンテンツ再生部１４２等として機能する。

ＡＥＳ１２８ｂｉｔチップ１１０５、ＥＣ−ＤＨチップ１１０６、及びＥＣ−ＤＳＡチップ１１０７は、暗号処理に用いられる。ＳＨＡ−２５６チップ１１０８及びＳＨＡ−１チップ１１０９は、メッセージダイジェストの生成に用いられる。ＲＮＧチップ１１１０は、乱数を発生させる。

不揮発性記憶媒体１１１１は、図２等における不揮発記憶部１２として機能する。したがって、ファーム管理情報１２１やファームデータ等は、不揮発性記憶媒体１１１１に記録される。

Ｄｅｍｕｘｅｒ１１１２、Ｄ／ＡＣｏｎｖｅｒｔｅｒ１１１３、Ｈ．２６４Ｄｅｃｏｄｅｒ１１１４、及びＡＡＣＤｅｃｏｄｅｒ１１１５等は、復号されたコンテンツデータの再生に用いられる。但し、これらは、セキュリティチップ１１外に配置されていてもよい。

ＨＤＭＩ１１１６は、いわゆるＨＤＭＩ１１１６（High-Definition Multimedia Interface）に従ったンタフェースである。

なお、図５、図７、及び図１０や、図１７に示されるように、アプリケーションが、ファームウェアであるコンテンツ鍵取得プロトコル制御部１４１やコンテンツ再生部１４２等を利用する場合、ファーム更新部１３を経由して呼び出しが行われる。ファーム更新管理部１３２は、コンテンツ鍵取得プロトコル制御部１４１、又はコンテンツ再生部１４２を呼び出す前に、ファームデータが更新途中でないか（すなわち、ファーム管理情報１２１のファーム更新状態が「更新中」でないか）否かを確認する。ファームデータが更新途中である場合、ファーム更新部１３は、アプリケーションに対してエラーを返却する。

上述したように、本実施の形態におけるコンテンツ再生端末１０によれば、ファームデータの更新処理（更新の要否の確認）のタイミングは、コンテンツ再生端末１０の外部（本実施の形態では、ファーム更新サーバ２０、コンテンツ鍵配信サーバ３０）より取得されるサーバ時刻に基づいて判断される。すなわち、コンテンツ再生端末１０が備える時計が示す時刻は利用されない。したがって、コンテンツ再生端末１０が備える時計を調整することによる、当該タイミングの無効化等を防止することができる。

また、サーバ時刻は、セキュアな通信によって暗号化されて取得される。したがって、サーバ時刻の流通経路における改竄についても、適切に防止される。

また、ファームデータの更新処理（更新確認）の実行の要否は、セキュリティチップ１１内において判定され、実際の更新の要否はファーム更新サーバ２０によって行われる。したがって、アプリケーションプログラムの改竄による、ファームデータの更新処理の回避を適切に防止することができる。

また、ファームデータの更新処理が実行されない状態が所定期間を超えて継続すると、コンテンツ鍵のダウンロードや、コンテンツデータの再生の実行は、セキュリティチップ１１によって拒否される。したがって、ファームデータの更新処理（更新の要否の確認）の実行をユーザに強制させることができる。なお、本実施の形態では、コンテンツ再生端末１０がファーム更新サーバ２０又はコンテンツ鍵配信サーバ３０と通信を行わなければ、最終確認サーバ日時は更新されない。但し、その場合であっても、再生が可能な範囲は、既にコンテンツ鍵が取得されたコンテンツデータに限定される。すなわち、新たなコンテンツデータを再生させたい場合は、そのコンテンツ鍵をダウンロードしなければならない。当該ダウンロードの開始によって最終確認サーバ日時は更新され、次回更新確認日時との比較に応じて、当該ダウンロードは拒否されうる。

また、最終確認サーバ日時を更新するためのサーバ時刻は、コンテンツ鍵と共に暗号化されてコンテンツ再生端末１０に転送される。すなわち、サーバ時刻は、コンテンツ鍵と同じコンテンツ鍵取得レスポンスに含まれてコンテンツ再生端末１０に転送される。したがって、サーバ時刻の転送が妨害された場合、コンテンツ鍵は、コンテンツ再生端末１０にダウンロードされない。換言すれば、コンテンツ再生端末１０が、コンテンツ鍵を受信するためには、当該コンテンツ鍵を含むレスポンスがセキュリティチップ１１に入力されなければならない。したがって、サーバ時刻の受信の妨害（すなわち、最終確認サーバ日時の更新の妨害）が適切に抑制すされる。

また、ファーム更新状態が管理されているため、セキュリティチップ１１は、ファームデータの更新が完了していない（中断された）ことを適切に検知することができる。そして、ファームデータの更新が完了していないことが検知された場合、セキュリティチップ１１は、コンテンツ鍵のダウンロードやコンテンツデータの再生等を拒否する。したがって、ファームデータの更新が適切に完了される可能性（更新中に不正な中断が行われない可能性）を高めることができる。

また、ファームデータの更新においては、ファームデータの実体の更新の後にファーム版数の更新が行われ、最後にファーム更新状態が更新される。すなわち、ファーム版数に基づいて更新の要否が判定されるところ、ファーム版数は、ファームデータが更新された後に更新される。したがって、ファームデータの更新の再実行において、ファームデータが最新のものに更新される可能性を高めることができる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ コンテンツ再生端末
１１ セキュリティチップ
１２ 不揮発記憶部
１３ ファーム更新部
１５ ファーム更新アプリ
１６ コンテンツ再生プレーヤアプリ
１７ ドライバプログラム
２０ ファーム更新サーバ
２１ ファームデータ提供部
２２ ファームデータ管理ＤＢ
３０ コンテンツ鍵配信サーバ
１２１ ファーム管理情報
１２２ ライセンスＤＢ
１３１ ファーム更新プロトコル制御部
１３２ ファーム更新管理部
１３１ａ ファーム更新リクエスト生成部
１３１ｂ ファーム更新レスポンス受信部
１３２ａ 更新状態判定部
１３２ｂ 更新要否判定部
１４１ コンテンツ鍵取得プロトコル制御部
１４１ａ コンテンツ鍵取得リクエスト生成部
１４１ｂ コンテンツ鍵取得レスポンス受信部
１４１ｃ コンテンツ鍵更新部
１４２ コンテンツ再生部
１４２ａ 暗号化コンテンツ復号環境作成部
１４２ｂ 再生制御部
１６１ 暗号化コンテンツ
１００１ メインＣＰＵ
１００２ ＲＡＭ
１００３ ＲＯＭ
１００４ ＨＤＤ
１００５ 通信インタフェース
１１０１ ＵＳＢ
１１０２ ＲＯＭ
１１０３ ＲＡＭ
１１０４ ＣＰＵ
１１０５ ＡＥＳ１２８ｂｉｔチップ
１１０６ ＥＣ−ＤＨチップ
１１０７ ＥＣ−ＤＳＡチップ
１１０８ ＳＨＡ−２５６チップ
１１０９ ＳＨＡ−１チップ
１１１０ ＲＮＧチップ
１１１１ 不揮発性記憶媒体
１１１２ Ｄｅｍｕｘｅｒ
１１１３ Ｄ／ＡＣｏｎｖｅｒｔｅｒ
１１１４ Ｈ．２６４Ｄｅｃｏｄｅｒ
１１１５ ＡＡＣＤｅｃｏｄｅｒ
１１１６ ＨＤＭＩ

Claims (12)

1. セキュリティチップを有するコンテンツデータ再生装置であって、
   前記セキュリティチップは、
   ファームウェアプログラムを含むファームデータを記憶する記憶手段と、
   前記セキュリティチップに対する、コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記ファームデータに対して設定された期限情報と、ネットワークを介して受信される時間情報との比較に基づいて前記ファームデータの更新処理の実行の要否を判定し、前記更新処理の実行が必要な場合は、前記要求を拒否するファーム更新管理手段とを有し、
   前記ファームウェアプログラムは、前記セキュリティチップを、
   コンテンツデータを復号するためのコンテンツ鍵をネットワークを介して取得するコンテンツ鍵取得制御手段と、
   前記コンテンツ鍵を用いてコンテンツデータを復号する復号手段として機能させる、
   コンテンツデータ再生装置。
2. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵と共に前記時間情報を取得する請求項１記載のコンテンツデータ再生装置。
3. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵及び前記時間情報を暗号化通信によって取得する請求項２記載のコンテンツデータ再生装置。
4. 前記ファーム更新管理手段は、
   前記ファームデータの更新処理において該更新処理の状態を示す更新状態情報を更新状態記憶手段に記録し、
   前記セキュリティチップに対する、前記コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記更新状態情報を参照し、該更新状態情報が、更新処理が完了したことを示していない場合は、該要求を拒否する請求項１乃至３いずれか一項記載のコンテンツデータ再生装置。
5. コンテンツデータ再生装置が有するセキュリティチップが実行する更新管理方法であって、
   前記セキュリティチップに対する、コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記セキュリティチップが有する記憶手段が記憶するファームデータに対して設定された期限情報と、ネットワークを介して受信される時間情報との比較に基づいて前記ファームデータの更新処理の実行の要否を判定し、前記更新処理の実行が必要な場合は、前記要求を拒否するファーム更新管理手順を有し、
   前記ファームデータに含まれるファームウェアプログラムは、前記セキュリティチップを、
   コンテンツデータを復号するためのコンテンツ鍵をネットワークを介して取得するコンテンツ鍵取得制御手段と、
   前記コンテンツ鍵を用いてコンテンツデータを復号する復号手段として機能させる、
   更新管理方法。
6. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵と共に前記時間情報を取得する請求項５記載の更新管理方法。
7. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵及び前記時間情報を暗号化通信によって取得する請求項６記載のコンテンツデータ更新管理方法。
8. 前記セキュリティチップが、
   前記ファームデータの更新処理において該更新処理の状態を示す更新状態情報を更新状態記憶手段に記録する更新状態記録手順を実行し、
   前記ファーム更新管理手順は、前記セキュリティチップに対する、前記コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記更新状態情報を参照し、該更新状態情報が、更新処理が完了したことを示していない場合は、該要求を拒否する請求項５乃至７いずれか一項記載の更新管理方法。
9. コンテンツデータ再生装置が有するセキュリティチップを、
   ファームウェアプログラムを含むファームデータを記憶する記憶手段と、
   前記セキュリティチップに対する、コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記ファームデータに対して設定された期限情報と、ネットワークを介して受信される時間情報との比較に基づいて前記ファームデータの更新処理の実行の要否を判定し、前記更新処理の実行が必要な場合は、前記要求を拒否するファーム更新管理手段として機能させ、
   前記ファームウェアプログラムは、前記セキュリティチップを、
   コンテンツデータを復号するためのコンテンツ鍵をネットワークを介して取得するコンテンツ鍵取得制御手段と、
   前記コンテンツ鍵を用いてコンテンツデータを復号する復号手段として機能させる、
   更新管理プログラム。
10. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵と共に前記時間情報を取得する請求項９記載の更新管理プログラム。
11. 前記コンテンツ鍵取得制御手段は、前記コンテンツ鍵及び前記時間情報を暗号化通信によって取得する請求項１０記載の更新管理プログラム。
12. 前記ファーム更新管理手段は、
    前記ファームデータの更新処理において該更新処理の状態を示す更新状態情報を更新状態記憶手段に記録し、
    前記セキュリティチップに対する、前記コンテンツ鍵の取得要求又はコンテンツデータの復号要求の入力に応じ、前記更新状態情報を参照し、該更新状態情報が、更新処理が完了したことを示していない場合は、該要求を拒否する請求項９乃至１１いずれか一項記載の更新管理プログラム。

Images