(第1実施形態)
 以降、本発明に係るデータ管理装置の実施� ��態について説明する。先ず始めに、本発明� ��係るデータ管理装置の実施行為のうち、使� ��行為についての形態を説明する。図3は、本 発明に係るデータ管理装置の、使用行為につ いての形態を示す図である。図3において、� �発明に係るデータ管理装置は、再生装置200� �ある。この再生装置200は、リモコン300、テ� �ビ400により形成されるホームシアターシス� �ムに、映画作品を供給するという用途に供� �れる。

 以上が本発明に係るデータ管理装置の使� ��形態についての説明である。続いて再生装� ��200が再生の対象としている、記録媒体につ� ��て説明する。再生装置200により、再生され� ��のは、BD-ROM100である。図4は、BD-ROM100の内部 構成を示す図である。

 本図の第4段目にBD-ROMを示し、第3段目にBD -ROM上のトラックを示す。本図のトラックは� �BD-ROMの内周から外周にかけて螺旋状に形成� �れているトラックを、横方向に引き伸ばし� �描画している。このトラックは、リードイ� �領域と、ボリューム領域と、リードアウト� �域とからなる。また、リード・インの内側� �はBCA(Burst Cutting Area)と呼ばれるドライブで� ��か読み出せない特別な領域がある。この領� ��はアプリケーションから読み出せないため� ��例えば著作権保護技術などに利用されるこ� ��がよくある。

 本図のボリューム領域は、物理層、ファ� ��ルシステム層、応用層というレイヤモデル� ��もち、ボリューム領域には、ファイルシス� ��ム情報(ボリューム)を先頭に映像データな� �のアプリケーションデータが記録されてい� �。ファイルシステムとは、UDFやISO9660などの� ��とであり、通常のPCと同じように記録され� �いる論理データをディレクトリ、ファイル� �造を使って読み出しする事が可能になって� �り、255文字のファイル名、ディレクトリ名� �読み出すことが可能である。ディレクトリ� �造を用いてBD-ROMの応用層フォーマット(アプ� ��ケーションフォーマット)を表現すると、図 中の第1段目のようになる。この第1段目にお� ��てBD-ROMには、Rootディレクトリの下に、CERTIF ICAEディレクトリ、及びBDMVディレクトリがあ� ��。

 CERTIFICAEディレクトリの配下には、ディス クのルート証明書のファイル(app.discroot.cert)� �存在する。app.discroot.certはJava(登録商標)仮想 マシンを用いて動的なシナリオ制御を行うJav aアプリケーションのプログラムを実行する� �に、アプリケーションが改竄されていない� �、及びアプリケーションの身元確認を行な� �プロセス(以下、署名検証という)に用いられ るデジタル証明書である。

 BDMVディレクトリはBD-ROMで扱うAVコンテン� ��や管理情報などのデータが記録されている� ��ィレクトリであり、BDMVディレクトリの配下 には、PLAYLISTディレクトリ、CLIPINFディレクト リ、STREAMディレクトリ、BDJOディレクトリ、JA Rディレクトリ、METAディレクトリと呼ばれる6 つのサブディレクトリが存在し、INDEX.BDMVとMo vieObject.bdmvの2種類のファイルが配置されてい る。

 STREAMディレクトリには、いわばデジタル� ��トリーム本体となるファイルを格納してい� ��ディレクトリであり、拡張子M2TSが付与され たファイル(000001.M2TS)が存在する。

 PLAYLISTディレクトリには、拡張子MPLSが付� ��されたファイル(000001.MPLS)が存在する。

 CLIPINFディレクトリには、拡張子CLPIが付� �されたファイル(000001.CLPI)が存在する。

 BDJOディレクトリには、拡張子BDJOが付与� �れたファイル(XXXXX.BDJO)が存在する。

 JARディレクトリには、拡張子JARが付与さ� ��たファイル(YYYYY.JAR)が存在する。

 METAディレクトリには、XMLファイル(ZZZZZ.xm l)が存在する。

 以下、これらのファイルについて説明す� ��。

 <AVClip>
 先ず初めに、拡張子.M2TSが付与されたファ� �ルについて説明する。拡張子"m2ts"が付与さ� �たファイルは、M P E G - T S( T r a n s p  o r t S t r ea m )形式のデジタルAVストリ ームであり、ビデオストリーム、1つ以上の� �ーディオストリーム、グラフィクスストリ� �ム、テキスト字幕ストリーム等を多重化す� �ことで得られる。ビデオストリームは映画� �動画部分を、オーディオストリームは映画� �音声部分をそれぞれ示している。

 <PlayList情報>
 拡張子“MPLS"が付与されたファイルは、PlayL ist(PL)情報を格納したファイルである。PL情報 は、AVClipを参照してプレイリストを定義する 情報である。

 <Clip情報>
 拡張子“CLPI"が付与されたファイルは、AVCli pのそれぞれに1対1に対応するClip情報である� �管理情報故に、Clip情報は、AVClipにおけるス� ��リームの符号化形式、フレームレート、ビ� ��トレート、解像度等の情報や、GOPの先頭位� ��を示すEP#mapをもっている。以上のClip情報及 びPL情報は、"静的シナリオ"に分類される。

 <BD-Jオブジェクト>
 続いて、拡張子BDJOを付したファイルについ て説明する。拡張子BDJOを付したファイルは� �BD-Jオブジェクトを格納したファイルである� ��BD-Jオブジェクトは、PlayList情報により定義� ��れるAVClip列と、アプリケーションとの関連� ��けにより、タイトルを定義する情報である� ��図5は、BD-Jオブジェクトの内部構成を示す� �である。本図に示すように、BD-Jオブジェク� ��は、"アプリケーション管理テーブル"と、"P layList情報に対する参照値"とを示す。"PlayList� ��報に対する参照値"は、このタイトルの開始 時に、同時に再生すべきPlayList情報を示す。� ��プリケーション管理テーブルは、破線の矢� ��ai1に示すように、このタイトルを生存区間� ��するアプリケーションを指定する情報を羅� ��したものである。アプリケーション管理テ� ��ブルにおけるアプリケーションの指定には� ��破線の矢印ai2に示すようにアプリケーショ� ��特定情報とアプリケーション詳細情報とが� ��まれる。アプリケーション特定情報として� ��、アプリケーションの作成者のID(OrganizationI D)とアプリケーションの識別子(アプリケーシ ョンID)とそのアプリケーションを構成するJav aアーカイブファイルのIDとが用いられる。つ まり、一つのアプリケーションは一つ以上の Javaアーカイブファイルで構成される。

 また、アプリケーション管理テーブルに� ��、破線の矢印ai4に示すように、アプリケー� ��ョン詳細情報として、アプリケーションの� ��称を示す文字列と、アプリケーションに対� ��づけるアイコンの所在を指し示すアイコン� ��ケータとを、アプリケーション毎にさせて� ��納している。アイコンロケータは、Javaアー カイブファイル内に含まれるアイコンをアド レスにより指し示す。

 以上が拡張子BOBJを付したファイルについ ての説明である。

 続いて“動的なシナリオ”について説明� ��る。“動的に”というのは、再生装置200に� ��ける状態変化やユーザからのキーイベント� ��より再生制御の中身がかわることをいう。B D-ROMでは、Javaアプリケーションと同様の記述 により、この再生制御を記述することができ る。つまりBD-ROMでは、Javaアプリケーション� �、動的シナリオとしての役割を担うことに� �る。

 Javaアプリケーションについて説明する。 Javaアプリケーションは、仮想マシンのヒー� �領域(ワークメモリとも呼ばれる)にロードさ れた1つ以上のxletプログラムからなる。この� ��ークメモリにロードされたxletプログラム、 及び、データから、アプリケーションは構成 されることになる。以上がJavaアプリケーシ� �ンの構成である。

 このJavaアプリケーションの実体にあたる のが、図4におけるBDMVディレクトリ配下のJAR� ��ィレクトリに格納されたJavaアーカイブファ イル(YYYYY.jar)である。以降、Javaアーカイブフ ァイルについて、図6を参照しながら説明す� �。

 <Javaアーカイブファイル>
 Javaアーカイブファイル(図4のYYYYY.JAR)は、1� �以上のクラスファイル、1つ以上のデータフ� ��イル等を1つにまとめることで得られるファ イルである。図6は、アーカイブファイルに� �り収められているプログラム、データを示� �図である。本図におけるデータは、枠内に� �すディレクトリ構造が配置された複数ファ� �ルを、Javaアーカイバでまとめたものである� ��枠内に示すディレクトリ構造は、Rootディレ クトリ、javaディレクトリ、imageディレクトリ 、META-INFディレクトリ、appiconディレクトリと からなり、Javaアーカイブファイルは、これ� �をJavaアーカイバでまとめることで得られる� ��

 Rootディレクトリにcommon.pkgが、javaディレ� ��トリにクラスファイル(aaa.class,bbb.class)が、i mageディレクトリに、menu.jpg、YYYYY.ICO等のファ イルが配置されている。かかるクラスファイ ル及びデータは、BD-ROMからキャッシュに読み 出されるにあたって展開され、キャッシュ上 で、ディレクトリに配置された複数ファイル として取り扱われる。Javaアーカイブファイ� �のファイル名における"YYYYY"という5桁の数値 は、JavaアーカイブファイルのIDを示し、BD-J� �ブジェクトは、この値を用いてJavaアーカイ� ��ファイルを参照する。本Javaアーカイブファ イルがキャッシュに読み出された際、このフ ァイル名における数値を参照することにより 、任意のJavaアプリケーションを構成するプ� �グラム,データを取り出すことができる。

 本図におけるYYYYY.ICOはアイコンファイル� ��あり、BD-Jオブジェクトのアイコンロケータ において、Javaアーカイブファイルのファイ� �名からの相対アドレスにより、“YYYYY/image/YY YYY.ICO”のように指定される。

 本図におけるクラスファイル(図中のaaa.cl ass,bbb.class)は、上述したxletプログラムに対応 するクラスファイルである。Java動作環境に� �る動作モード(BD-Jモード)における再生手順� �、このクラスファイルのインスタンスにあ� �るxletプログラムにより規定される。xletプロ グラムとは、JMF(Java Media FrameWork)方式のイン ターフェイスを利用することができるJavaプ� �グラムであり、JMF等の方式に従って、キー� �ベントに基づきプレイリスト再生処理を行� �。

 更にxletプログラムは、WWWサイトをアクセ スしてコンテンツをダウンロードするという 手順を実行することもできる。これによりダ ウンロードコンテンツと、プレイリスト再生 とを交えた斬新な作品を再生させることがで きる。

 またJavaアーカイブファイルのMETA-INFディ� ��クトリには、アプリケーションプログラム� ��構成及び個々のファイルに対するダイジェ� ��ト値を示すマニフェストファイル(YYYY.MF)、� ��名ファイル(YYYY.SF)、署名ブロックファイル( YYYY.RSA)が含まれている。

 マニフェストファイル(YYYY.MF)は、Javaアー カイブファイルに含まれる各ファイルのダイ ジェスト値を収めたものであり、署名ブロッ クファイル(YYYY.RSA)は、デジタル証明書と、� �名ファイル自体から得られたダイジェスト� �をリーフ証明書により示される公開鍵に対� �する秘密鍵で暗号化した情報とを収めたも� �である。署名ファイル、署名ブロックファ� �ルは、アプリケーションの署名検証に用い� �れる。

 図7はアプリケーションの署名ブロックフ ァイルに含まれるデジタル証明書の構成内容 を示した構成図である。図7で示すように、� �ジタル証明書は複数の証明書のチェーンか� �構成されている。証明書チェーンは、X.509の 規格に準拠した証明書から構成され、X.509で� ��成された証明書チェーンの一般的な構成を� ��現している。証明書チェーンは、アプリル� ��ト証明書、中間証明書1・・・n、リーフ証� �書を内包する。これらは、アプリルート証� �書の所有者が中間証明書を発行し、中間証� �書の所有者がリーフ証明書を発行するとい� �た、連鎖関係にある。また、中間証明書が� �数存在する場合、中間証明書間で相互に関� �した連鎖状態にある。X.509証明書は、証明書 の表現形式のデファクト標準として情報通信 の各分野で広く普及している。

 アプリルート証明書は、映画スタジオに� ��って発行される。また、中間証明書、及び� ��ーフ証明書はスタジオ内のソフトウェアベ� ��ダによって発行され、スタジオのアプリル� ��ト証明書と対象の秘密鍵によって署名され� ��。

 各証明書は、破線の矢印cr1に示すように� ��X.509の証明書である。ここでは、本発明の� �明上で必要な属性のみを列挙している。シ� �アル番号は証明書を識別するための番号、� �名アルゴリズムは署名値を計算するために� �用されたアルゴリズム、有効期限は本X.509証 明書が有効な期限、発行者名は本X.509証明書� ��発行する機関名、主体者名は本X.509証明書� �発行を受けた所有者、公開鍵は主体者名に� �されるものの公開鍵、署名値は本X.509証明書 発行者の秘密鍵によって署名(暗号化)された� ��を表す。

 公開鍵と秘密鍵を使ったものとして、公� ��鍵暗号方式が電子商取引等で幅広く利用さ� ��ている。公開鍵暗号方式では、平分を暗号� ��るときに使用した鍵と異なる鍵を使用して� ��号文を復号する。暗号の鍵と復号用の鍵が� ��なり、復号用の鍵を一般公開しても復号用� ��鍵から暗号用の鍵を推測することは不可能� ��ある。この暗号用の鍵が秘密鍵、復号用の� ��が公開鍵に該当する。公開鍵暗号方式の代� ��例としては、RSA(Rivest-Shamir-Adleman)、DSA(Digital  Signature Standard)等が挙げられる。

 図8は図7に示される主体者名の詳細を示� �図である。主体者名はX.500識別名 (Distinguishe d Name) において記述されている。国名は証� �書保有者の国が記載される。組織名は証明� �の所有者の組織名が記載される。例えば、� �プリルート証明書であれば、スタジオ名で� �り、リーフ証明書であればスタジオベンダ� �である。組織ユニットは社内のユニットを� �す。共通名はここのオブジェクトを示す。� �通名は基本的に自由な記述が可能だが、証� �書の内容がわかるような記述になっている� �とが一般的である。主体者名には上記以外� �も要素は存在するが、ここでは、本発明の� �明上で必要な要素のみを列挙している。

 なお、リーフ証明書の場合は、組織名の� ��端に、アプリケーションを作成した組織を� ��定する32bitの識別子(OrganizationID)を16進表記� �表した8文字の名前を含む。この値は、BD-Jオ ブジェクトで使用されているOrganizationIDと同� ��ものである。以上がJavaアーカイブファイル についての説明である。

 続いてINDEX.BDMVについて説明する。

 INDEX.BDMVは、BD-ROM全体に関する管理情報で あり、映画作品のプロバイダを特定する識別 子であるorganizationIDや、プロバイダが提供す� ��BD-ROMのそれぞれに割り当てられた識別子で� ��るdiscID等の情報を持ち、再生装置へのディ� ��ク挿入後に、INDEX.BDMVが最初に読み出される ことで、再生装置においてディスクが一意に 認識される。加えて、BD-ROMにおいて再生可能 となる複数のタイトルと、個々のタイトルを 規定するBD-Jオブジェクトとを対応付けて示� �テーブルが含まれる。

 MovieObject.bdmvは、HDMVモードでの各タイト� �再生で、再生進行を動的に変化させるため� �シナリオが記述されたシナリオプログラム� �含まれる。

 <メタファイル>
 METAディレクトリに格納されたメタファイル (ZZZZZ.xml)には、ディスクに入っている映像作� ��に関する様々な情報が格納されている。メ� ��ファイルに格納されている情報としては、� ��ィスクのディスク名及び画像、ディスクが� ��によって作成されたかの情報、各タイトル� ��関わるタイトル名等がある。メタファイル� ��、必須のファイルではなく、このファイル� ��格納されていないBD-ROMもある。

 以上がBD-ROM100についての説明である。

 以上説明した各ファイルに基づいて、BD-R OMの映画作品は再生装置において再生制御が� ��される。図9は再生制御のレイヤモデルを示 した図である。図9の第1層は、物理層であり� ��処理対象たるストリーム本体の供給制御で� ��る。この第1層に示すように、処理対象たる ストリームは、BD-ROMだけではなく、HDD(ハー� �ディスクドライブ)などの再生装置に予め組� ��込まれた記録媒体であるローカルストレー� ��やリムーバブルメディア、ネットワークと� ��ったあらゆる記録媒体、通信媒体を供給源� ��している。これらローカルストレージ、リ� ��ーバブルメディア、ネットワークといった� ��給源に対する制御(ディスクアクセス、カー ドアクセス、ネットワーク通信)が第1層の制� ��である。

 第2層は、AVデータのレイアである。第1層 で供給されたストリームを、どのような復号 化方式を用いて復号するのかを規定している のがこの第2層である。

 第3層(BD管理データ)は、ストリームの静� �なシナリオを規定するレイアである。静的� �シナリオとは、ディスク制作者によって予� �規定された再生経路情報、ストリーム管理� �報であり、これらに基づく再生制御を規定� �ているのがこの第3層である。

 第4層(BD再生プログラム)は、ストリーム� �おける動的なシナリオを実現するレイヤで� �る。動的なシナリオは、AVストリームの再生 手順、及び、その再生に関する制御手順のう ち少なくとも一方を実行するプログラムであ る。動的なシナリオによる再生制御は、装置 に対するユーザ操作に応じて変化するもので あり、プログラム的な性質をもつ。ここでの 動的な再生制御には、2つのモードがある。2� ��のモードのうち1つは、AV機器特有の再生環� ��で、BD-ROMに記録された動画データを再生す� ��モード(HDMVモード)であり、もう1つはBD-ROMに 記録された動画データの付加価値を高めるモ ード(BD-Jモード)である。図9において第4層に� ��、HDMVモードとBD-Jモードの2つのモードが記� ��されている。HDMVモードは、DVDライクな再生 環境での再生モードであり、再生進行を動的 に変化させるためのシナリオが記述されたシ ナリオプログラムが動作する。もう一つのBD- Jモードは、Java仮想マシンを主体とした再生� ��ードであり、Javaアプリケーションから再生 制御を行う。

 図10は、2つのモードの動的な再生制御に� ��作成される映画作品を示す図である。図10(a )は、HDMVモードで動的な再生制御を定義する� ��とにより、作成される映画作品の一場面を� ��す図である。HDMVモードはDVD再生装置が解釈 可能なコマンドと良く似たコマンドで再生制 御を記述することができるので、DVDと同じよ うな再生制御、つまり、メニューに対する選 択により再生が進行するような再生制御を定 義することができる。

 図10(b)は、BD-Jモードで動的な再生制御を� ��義することにより、作成される映画作品で� ��る。BD-JモードはJava仮想マシンが解釈可能� �Java言語で制御手順を記述することができる� ��この再生制御がコンピュ-タ・グラフィック ス(CG)の動作を制御するものなら、BD-Jモード� ��あっては、動画を表示した画面の横でCG(図� ��のフクロウの絵)が動きまわっているような 再生制御を定義することができる。

 次に本実施形態に係る再生装置200の詳細� ��ついて説明する。

 図11は、再生装置の内部構成を示すブロ� �ク図である。図11に示すように、再生装置は 、BD-ROMドライブ1、トラックバッファ2、デマ� ��チプレクサ3、ビデオデコーダ4、ビデオプ� �ーン5、オーディオデコーダ6、イメージメモ リ7、グラフィックプレーン9、グラフィック� ��コーダ8、加算器10、静的シナリオメモリ11� �動的シナリオメモリ12、HDMVモジュール14、BD- Jモジュール15、UO探知モジュール21、モード� �理モジュール16、ディスパッチャ17、レンダ� ��ングエンジン22、AV再生ライブラリ18、ネッ� ��ワークインターフェース23、ローカルスト� �ージ24、BDファイルシステム25から構成され� �。

 BD-ROMドライブ1は、BD-ROMのローディング/� �ジェクトを行い、BD-ROMに対するアクセスを� �行する。

 トラックバッファ2は、FIFOメモリであり� �BD-ROMから読み出されたACCESS UNITが先入れ先� �し式に格納される。

 デマルチプレクサ3は、BD-ROMドライブ1に� �ーディングされているBD-ROM、またはローカ� �ストレージ24上に保存されているトランスポ ートストリームの多重分離を行い、GOPを構成 するビデオフレームと、オーディオフレーム とを得てビデオフレームをビデオデコーダ4� �出力し、オーディオフレームをオーディオ� �コーダ6に出力する。グラフィックストリー� ��はイメージメモリ7に格納し、Navigation Button 情報は動的シナリオメモリ12に格納する。デ� ��ルチプレクサ3による多重分離は、TSパケッ� ��をPESパケットに変換するという変換処理を� ��む。

 ビデオデコーダ4は、デマルチプレクサ3� �ら出力されたビデオフレームを復号して非� �縮形式のピクチャをビデオプレーン5に書き� ��む。

 ビデオプレーン5は、非圧縮形式のピクチ ャを格納しておくためのメモリである。

 オーディオデコーダ6は、デマルチプレク サ3から出力されたオーディオフレームを復� �して、非圧縮形式のオーディオデータを出� �する。

 イメージメモリ7は、デマルチプレクサ3� �ら読み出されたグラフィックストリーム、Na vigation Button情報内のPNGデータ、あるいは、BD ファイルシステム25を介してBD-ROMまたはロー� ��ルストレージ24から読み出された画像ファ� �ルを格納しておくバッファである。

 グラフィックデコーダ8は、イメージメモ リ7に格納されたグラフィックストリーム等� �デコードしてグラフィックプレーン9に書き� ��む。グラフィックストリームのデコードに� ��り、字幕が画面上に現れることになる。

 グラフィックプレーン9は、デコードされ たグラフィックストリーム、レンダリングエ ンジン22により描画された画像等が配置され� ��。

 加算器10は、ビデオプレーン5に格納され� ��非圧縮形式のピクチャデータに、グラフィ� ��クプレーン9に展開されたイメージを合成し て出力する。図10(b)に示した画面(動画を表示 した画面の横でCG(図中のフクロウの絵)が動� �まわっているような画面)は、この加算器10� �、グラフィックプレーン9内のイメージと、� ��デオプレーン5内のピクチャとを合成するこ とで出力される。

 静的シナリオメモリ11は、カレントのPLや カレントのストリーム管理情報を格納してお くためのメモリである。カレントPLとは、BD-R OMまたはローカルストレージ24に記録されて� �る複数PLのうち、現在処理対象になっている ものをいう。カレントストリーム管理情報と は、BD-ROMまたはローカルストレージ24に記録� ��れている複数ストリーム管理情報のうち、� ��在処理対象になっているものをいう。

 動的シナリオメモリ12は、カレント動的� �ナリオを格納しておき、HDMVモジュール14、BD -Jモジュール15による処理に供されるメモリ� �ある。カレント動的シナリオとは、BD-ROMま� �はローカルストレージ24に記録されている複 数シナリオのうち、現在実行対象になってい るものをいう。

 制御部13は、ROM、RAM、CPUからなるマイコ� �システムであり、ROMには再生装置を制御す� �プログラムが記録されており、ROM内のプロ� �ラムがCPUに読み込まれ、プログラムとハー� �ウェア資源とが協動することにより、HDMVモ� ��ュール14、BD-Jモジュール15、モード管理モ� �ュール16、ディスパッチャ17、AV再生ライブ� �リ18、マッピングモジュール19、ローカルス� ��レージ表示モジュール20の機能を実現する� �

 HDMVモジュール14は、HDMVモードの実行主体 となるDVD仮想プレーヤであり、動的シナリオ メモリ12に読み出されたカレントのシナリオ� ��ログラムを実行する。

 BD-Jモジュール15は、Javaプラットフォーム であり、Java仮想マシン、コンフィグレーシ� �ン、プロファイルからなる。BD-Jモジュール1 5は、動的シナリオメモリ12に読み出されたJav aクラスファイルからカレントのJavaオブジェ� ��トを生成し、実行する。Java仮想マシンは、 Java言語で記述されたJavaオブジェクトを、再� ��装置におけるCPUのネィティブコードに変換� ��て、CPUに実行させる。

 モード管理モジュール16は、BD-ROMまたは� �ーカルストレージ24から読み出されたモード 管理テーブルを保持して、モード管理及び分 岐制御を行う。モード管理モジュール16によ� ��モード管理とは、動的シナリオをどのHDMVモ ジュール14、BD-Jモジュール15に実行させるか� ��いう、モジュールの割り当てである。

 ディスパッチャ17は、UOから、現在の再生 装置におけるモードに適切なUOのみを選んで� ��そのモードを実行するモジュールに受け渡� ��。例えばHDMVモードの実行中に、上下左右、 アクティベートといったUOを受け付けた場合� ��HDMVモードのモジュールにこれらのUOを出力� ��るというのがディスパッチャ17の処理であ� �。

 AV再生ライブラリ18はHDMVモジュール14、BD- Jモジュール15からの関数呼び出しに応じて、 AV再生機能、プレイリストの再生機能を実行� ��る。AV再生機能とは、DVDプレーヤ、CDプレー ヤから踏襲した機能群であり、再生開始、再 生停止、一時停止、一時停止の解除、静止画 機能の解除、再生速度を即値で指定した早送 り、再生速度を即値で指定した巻戻し、音声 切り替え、副映像切り替え、アングル切り替 えといった処理である。プレイリスト再生機 能とは、このAV再生機能のうち、再生開始や� ��生停止をプレイリスト情報に従って行うこ� ��をいう。

 マッピングモジュール19は、ローカルス� �レージ24のディレクトリ構成とユーザによる 認識が容易な文字情報とを関連付けたマッピ ング情報を、アプリケーションの署名検証で 利用した情報を基に署名検証処理の実行過程 で生成するマッピング手段としての機能を実 現する。

 ローカルストレージ表示モジュール20は� �マッピング情報を利用して、ローカルスト� �ージのデータ保存状態を提示する提示処理� �制御する。具体的には、マッピング情報を� �に画面に出力するイメージをレンダリング� �ンジンに描画させる。

 UO探知モジュール21は、リモコンや再生装 置のフロントパネルに対してなされたユーザ 操作を検出して、ユーザ操作を示す情報(以� �UO(User Operation)という)をモード管理モジュー ル16に出力する。

 レンダリングエンジン22は、Java2D,OPEN-GLと いった基盤ソフトウェアを備え、BD-Jモジュ� �ル15からの指示に従ってコンピュ-タ・グラ� �ィックスの描画を行い、描画されたコンピ� �-タ・グラフィックスをグラフィックプレー� ��9に出力する。

 ネットワークインターフェース23は、イ� �ターネット上に公開されたBD-ROM追加コンテ� �ツのダウンロードに用いられる。BD-ROM追加� �ンテンツとは、オリジナルのBD-ROMにないコ� �テンツで、例えば追加の副音声、字幕、特� �映像、アプリケーションなどである。BD-Jモ� ��ュール15からネットワークインターフェー� �23を制御することができ、インターネット上 に公開された追加コンテンツをローカルスト レージ24にダウンロードすることができる。

 ローカルストレージ24は、再生装置に内� �されているハードディスク等の磁気記録装� �である。図12は、ローカルストレージ24にお� ��るディレクトリ構造を示す図である。Rootデ ィレクトリの下に、ADAディレクトリ、SYSディ レクトリ及びBUDAディレクトリがある。ADAデ� �レクトリは、アプリケーションが使うデー� �などの保存に用いられ、配下ディレクトリ� �アプリケーション毎にアクセスできるディ� �クトリが存在する。SYSディレクトリには、� �ッピングモジュール19により生成されたマッ ピング情報が保存され、BUDAディレクトリに� �、BDファイルシステム25によるバーチャルパ� ��ケージの生成に用いられるファイルが保存� ��れる。

 本図のディレクトリ構造においてADAディ� ��クトリは、正当性が証明されたSignedアプリ� ��ーション以外によるアクセスが制限される� ��限領域であり、ADAディレクトリ配下には、� ��CertIDディレクトリ」というサブディレクト� ��があり、その配下に、「OganizationIDディレク トリ」、さらにその配下に「AppIDディレクト� ��」というサブディレクトリがある。

  CertIDディレクトリはBD-ROM上のディスク� �ート証明書(app.discroot.cert)から導き出されるI Dを名前に持つディレクトリで、ディスクル� �ト証明書のSHA-1ダイジェスト値からディレク トリ名前が導かれる。

 OrganizationIDディレクトリは、BD-ROM上のBD-J� ��ブジェクトに記載されている、アプリケー� ��ョンを作成した組織を特定する32bitの識別� �(OrganizationID)を16進表記で表した8文字の名前� ��ディレクトリである。

 AppIDディレクトリは、BD-ROM上のBD-Jオブジ� ��クトに記載されている、アプリケーション� ��識別する16bitの識別子(アプリケーションID)� ��16進表記で表した4文字の名前のディレクト� ��である。アプリケーション識別子の値が0x3F FFまでであればアプリケーションは署名のな� ��アプリケーションである。

 OrganizationIDディレクトリ、及びAppIDディレ クトリの配下には、BD-Jオブジェクトに記載� �れているアプリケーションが属するIDのディ レクトリ以下のみアクセスできるようになっ ている。つまり、"56789abc"のOrganizationID、"4003" のアプリケーションIDを持つアプリケーショ� ��は、"56789abc"OrganizationIDディレクトリのサブ� ��ィレクトリである"4003"AppIDディレクトリの� �下のデータファイルにアクセスできるが、"5 6789abd"OrganizationIDディレクトリのサブディレ� �トリである"4003"AppIDディレクトリの配下のデ ータファイルにはアクセスできない。また、 "56789abc"以下のファイルであっても、"4001"のAp pIDディレクトリ以下をアクセスすることはで きない。

 また、ローカルストレージ24に保存され� �データファイルには、どのようなアプリケ� �ションでもアクセスできるわけではなく、� �ーカルストレージ24は信用された特殊なアプ リケーションのみアクセスできる。具体的に は、コンテンツ提供者の秘密鍵により署名さ れたアプリケーションである。(以下、Signed� �プリケーションという)。

 Signedアプリケーションによりアクセスす� ��ローカルストレージは秘密鍵と対応する公� ��鍵を用いて有効性の確認(署名検証)が成功� �た場合のみ、利用可能になる。公開鍵は、X. 509の規格に準拠した証明書という形式で、ア プリケーションに含まれる。X.509の詳細な仕� ��は、国際電信電話諮問委員会より発行され� ��いる、CCITT Recommendation X.509(1988), "The Direct ory - Authentication Framework"に記載されている� �また、アプリケーションの署名検証時にお� �ては、リーフ証明書の組織名の末尾に示さ� �るOrganizationIDがBD-ROM上のBD-Jオブジェクトに� �載されているOrganizationIDと同一でないと、署 名検証は失敗となる。

 BDファイルシステム25は、BD-ROMから読み出 されたデータと、ローカルストレージ24のBUDA ディレクトリ以下に格納されたデータとをマ ージしててバーチャルパッケージを生成し、 再生装置の他の機能ブロックに提供する。

 以上が再生装置の内部構成である。

 本実施の形態では、図8に示された主体者 名と、図8に示されるローカルストレージ24上 のディレクトリ構成とを関連付けて表示させ ることにより、ユーザに操作対象の内容がわ かりやすくなるよう表示させる。このような 表示を実現するには大きく2つの工程で再現� �きる。マッピング情報を生成しローカルス� �レージ24へ保存する工程と、マッピング情報 を用いてユーザに操作対象を画面表示させる 工程である。以下にこれらの工程を制御する BD-Jモジュールの詳細につてい説明する。

 図13は図11に示すBD-Jモジュールのより具� �的な構成を示す図である。BD-Jモジュール15� �メディア再生モジュール31、アプリケーショ ンマネージャ32、アプリケーション認証モジ� ��ール33、ファイルI/Oモジュール34から構成さ れる。

 メディア再生モジュール31はJavaアプリケ� ��ション30に対し、メディア再生制御のため� �APIを提供している。Javaアプリケーション30� �メディア再生制御APIを呼び出すと、メディ� �再生モジュールは対応するAV再生ライブラリ 18の関数を呼び出し、AV再生制御を行う。

 アプリケーションマネージャ32は、BD-ROM� �に記録された図5のBD-Jオブジェクトのアプリ ケーション管理テーブルを基づいてJavaアプ� �ケーションの起動・終了を管理する。また� �アプリケーションマネージャがディスパッ� �ャ17から受け取ったUOイベントを、現在動作� ��のJavaアプリケーション30に渡すといった処� ��も行う。

 アプリケーション認証モジュール33は、� �証手段としてアプリケーションプログラム� �署名検証処理を実行する。

 具体的には、アプリケーションマネージャ3 2により起動されたアプリケーションがSigned� �プリケーションか否かを判定し、Signedアプ� �ケーションであった場合は、アプリケーシ� �ン内に含まれた
デジタル証明書、署名ファイル、署名ブロッ クファイルを用いてアプリケーション認証を 行なう。

 ファイルI/Oモジュール34はJavaアプリケー� ��ョン30からのローカルストレージへのアク� �ス要求の処理を行う。Javaアプリケーション3 0はファイルI/Oモジュールを用いて、コンテ� �ツデータをローカルストレージ上の適切な� �置に配置することが出来る。また、不要と� �ったデータの削除や、直接編集を行なうこ� �も可能である。

 以下にマッピング情報を生成しローカル� ��トレージ24へ保存するマッピング処理の詳� �について説明する。本実施形態では、マッ� �ング処理は、アプリケーション起動時の署� �検証の際に実行される。

 図14は、本実施形態1に係るマッピング処� ��を伴うアプリケーション起動の流れを示す� ��ローチャートである。BD-Jモード用のタイト ルが再生され、アプリケーションマネージャ によってJavaアプリケーション起動要求がア� �リケーション認証モジュールに対して発行� �れる(S101)。アプリケーション起動要求には� �プリケーション管理情報から取得した、起� �するアプリケーションのアプリケーションID とOrganizationIDが含まれる。アプリケーション� ��動要求を受け取ったアプリケーション認証� ��ジュール33は受け取ったアプリケーションID を基にSignedか否かを判定する(S102)。Signedか否 かの判定は、例えば、アプリケーションIDの� ��が、0x000から0x3fffの範囲であれば、Signedア� �リケーションでなく、0x4000から0x7fffであれ� �Signedアプリケーションである。

 アプリケーション認証モジュール33がS102� ��Signedアプリケーションと判定しなかった場� ��はアプリケーション認証を行わず、アプリ� ��ーションはそのまま起動される。しかし、� ��プリケーション認証を通さないアプリケー� ��ョはローカルストレージへのアクセスは不� ��能となる。

 アプリケーション認証モジュール33がS102� ��Signedアプリケーションと判定した場合は、� ��プリケーション認証処理を実行する。アプ� ��ケーション認証処理を施すことによって、� ��プリケーションが改竄されていないことと� ��アプリケーションの身元確認が行なえる。S ignedアプリケーションは例えば、Sun Microsystem s, Incが規定した"Signed Jar"形式であり、アプ� ��ケーションに各ファイルに対するダイジェ� ��トを記載したManifestファイル、及びSignature� �ァイル(署名ファイル)を含む。また、Signed J arファイルはこれらの2つのファイルに加え、 Signatureファイルの署名と、署名を検証する証 明書チェーン等の情報をPKCS #7の形式記述さ� ��たSignature Blockファイル(署名ブロックファ� �ル)も含む。

 上記アプリケーション認証処理は、アプ� ��ケーション認証モジュール33によりアプリ� �ーションのSignature Blockファイルに含まれた� ��明書チェーンのリーフ証明書から公開鍵を� ��出し(S103)、Signature Blockファイルに含まれる アプリケーション自体から得られた署名値を 検証する(S104)。検証が失敗した場合は、アプ リケーションは不正であるとみなされ、起動 されない(S113)。署名の検証が成功した場合は 、アプリケーションは改竄されていないこと が保証されていることを意味する。

 次にアプリケーションの身元確認のため� ��証明書チェーンの検証を行なう。アプリケ� ��ション認証モジュール33はSignature Blockファ� ��ルの証明書チェーンからアプリルート証明� ��を抽出し、検証を行なう(S105)。具体的には� ��プリルート証明書の検証は、アプリルート� ��明書に記載されている有効期限が有効であ� ��ことを確認するプロセスと、アプリルート� ��明書がディスク上のCERTIFICATEディレクトリ� �下に配置されているディスクルート証明書� �同一であることを確認するプロセスを含む� �アプリルート証明書の検証が失敗であった� �合(S105:No)は、アプリケーションは不正であ� �とみなされ、起動されない(S103)。

 ここでアプリルート証明書の検証が成功� ��あった場合(S105:Yes)は、マッピングモジュー ル19にこのことが通知され、マッピングモジ� ��ール19が、アプリルート証明書の主体者名� �情報とディスクルート証明書から算出でき� �CertIDディレクトリの名前とを関連付けてマ� �ピング情報に登録する(S106)。

 尚、ディスクルートから算出できるCertID� ��ィレクトリがマッピング情報が既に登録さ� ��ていれば、S106を行なわなくてもよい。また 、アプリケーションデータの保存にCertIDディ レクトリを利用しない再生装置においては、 本ステップを省略することができる。

 図15はS106が完了した時点のマッピング情� ��の一例を示す図である。図15で示されると� �り、左にCertIDと右に主体者名から抽出した� �織名が連携づけて登録されている。なお、� �15では組織名が利用されているが、組織名の 代わりに図8に示すその他の情報を利用して� �よい。

 次に、同一証明書チェーンに含まれる、� ��つ子の証明書を抽出し、リーフ証明書か否� ��を判定する(S107)。リーフ証明書が否かの判� ��は、Signature BlockファイルのPKCS #7情報であ� ��発行者名とシリアル番号が、抽出した証明� ��の主体者名とシリアル番号と一致している� ��否かで判定できる。

 S107で抽出した証明書がリーフ証明書でな い場合は、中間証明書の検証(S108)を行なう。 具体的には中間証明書の検証は、中間証明書 に記載されている有効期限が有効であること を確認するプロセスと、中間証明書の親の証 明書に含まれる公開鍵を用いて中間証明書内 の署名値が正しいかを検証するプロセスを含 む。S108の中間証明書の検証が失敗であった� �合(S108:No)は、アプリケーションは不正であ� �とみなされ、起動されない(S113)。S108中間証� ��書の検証が成功であった場合は、S107に戻り 、さらに下位の証明書についてリーフ証明書 であるか否かを判定する。

 S107で抽出した証明書がリーフ証明書であ った場合(S107:Yes)は、リーフ証明書の検証(S109 )を行なう。具体的にはリーフ証明書の検証� �、リーフ証明書に記載されている有効期限� �有効か否かを確認するプロセスと、リーフ� �明書に存在する署名値を発行者名と同一の� �体者名を持っている証明書の公開鍵を用い� �リーフ証明書内の署名値が正しいか検証す� �プロセスと、リーフ証明書の主体者名の中� �組織名のOrganization識別子が、S101でアプリケ� ��ションマネージャによって渡されたOrganizati onIDと同一であることを検証するプロセスと� �含む。S109のリーフ証明書の検証が失敗であ� ��た場合は(S109:No)、アプリケーションは不正� ��あるとみなされ、起動されない(S113)。

 S109リーフ証明書の検証が成功であった場合 は(S109:Yes)、
マッピングモジュール19にこのことが通知さ� ��、マッピングモジュール19が、リーフ証明� �の主体者名の情報とS101でアプリケーション� ��ネージャによって渡されたOrganizationIDとを� �連付けてマッピング情報に登録する(S110)。� �こでマッピング情報は、S106で登録したCertID� ��情報と連携して保存される。すなわち、同� ��のOrganizationIDがマッピング情報が既に登録� �れていても、CertIDが異なれば、別のOrganizatio nIDとしてマッピング情報に登録する。

 図16はS110が完了した時点のマッピング情� ��の一例を示す図である。図16で示されると� �り、CertIDとアプリルート証明書の主体者名� �、OrganizationIDと、リーフ証明書の主体者名が 連携付けられている。なお、図16のリーフ証� ��書の主体者名として組織名が利用されてい� ��が、組織名の代わりに図8に示す他の情報を 利用してもよい。図16で示されるとおり、Cert ID、アプリルート証明書の主体者名ペアに対� ��て、複数のOrganizationID、リーフ証明書の主� �者名ペアを関連付けても良い。また、図16で 示されるとおり、同じOrganizationIDが存在して� ��(図16の場合は56789abc)CertIDが異なれば、別個� ��マッピング情報へ登録する。

 S110が完了した時点でアプリケーション認 証処理は完了である。アプリケーション認証 処理の完了後はアプリケーション認証モジュ ール33がアプリケーションマネージャ32にア� �リケーション認証成功の旨を通達し、アプ� �ケーションマネージャはS101で発行した起動� ��求のあったアプリケーションを起動する(S11 1)。

 起動したアプリケーションはローカルス� ��レージ24のADA領域のBD-Jオブジェクトに記載� ��れているアプリケーションが属するIDのデ� �レクトリ以下の領域に、データの読み書き� �可能となる(S112)。以上が、マッピング処理� �詳細である。

 尚、本実施の形態では、アプリケーショ� ��認証をアプリルート証明書、中間証明書、� ��ーフ証明書の順番で検証を行なったが、そ� ��らの順番は入れ替えてもよい。

 次に、マッピング情報を用いてユーザに� ��作対象を画面表示する提示画面表示処理に� ��いて説明する。本実施形態では、提示画面� ��示処理は、ADA領域の保存データを管理する� ��連の処理において実行される。図17は、ADA� �域に保存されたデータを管理する処理の流� �を示すフローチャートである。

 ファイルI/Oモジュール34は、リモコンな� �の入力デバイスからデータ管理の開始を要� �するUOが通知されると(S121)、ローカルストレ ージ表示モジュール20に対して提示画面表示� ��理の実行を指示する(S122)。提示画面表示処� ��によりテレビ400に図19に示すような提示画� �が表示されると、ユーザはこの画像を見な� �ら操作することができる。

 ファイルI/Oモジュール34は、このようなUO を受け付けると、S123からS128の処理でUOの内� �を判定し、判定結果にしたがって、S129からS 134において、画面上のフォーカス移動、ADA領 域にある全てのデータファイルの削除、フォ ーカス中のデータファイルの削除、フォーカ ス中のデータファイルのコピー、及び、フォ ーカス中のデータファイルの詳細表示などの 処理を実行する。

 尚、データファイルの詳細表示としては� ��ファイルシステムにおいて管理されている� ��ァイルのサイズ、ファイル作成日時、ファ� ��ルの更新日時等の情報を表示する。

 図18は、マッピング情報を用いてADAの保� �データを提示する提示画面表示処理の詳細� �示すフローチャートである。

 ローカルストレージ表示モジュール20は� �ファイルI/Oモジュール34から、提示画面表示 処理の実行を指示されると、ADA領域にユーザ の操作対象のデータがADA領域に保存されてい るか否かを確認する(S141)。

 ユーザの操作対象のデータがADAに存在し� ��かった場合は(S141:No)、ローカルストレージ� ��示モジュール20はユーザの操作対象のデー� �がADAに存在しない旨を示すの画面出力用の� �メージを、レンダリングエンジン22に描画さ せる(S147)。

 ユーザの操作対象のデータがADAに存在し� ��場合は(S141:Yes)、ローカルストレージ表示モ ジュール20は、データが配置されているCertID� ��ィレクトリを抽出し(S142)、抽出したCertIDデ� ��レクトリ配下のファイル数、その合計サイ� ��、及び、マッピング情報においてこのCertID� ��関連づけられているアプリルート証明書の� ��体者名を一組のエントリとして、RAMの作業� ��域にリストを作成する(S143)。

 次に、ローカルストレージ表示モジュー� ��20はデータが配置されているOrganizationIDディ レクトリを抽出し(S144)、抽出したOrganizationID� ��ィレクトリ配下のファイル数、その合計サ� ��ズ、及び、マッピング情報においてこのCert IDと関連づけられているアプリリーフ証明書� ��主体者名を一組のエントリとして、S142でRAM の作業領域に作成したリストに追加する(S145) 。

 その後、RAMの作業領域に一時保存した情� ��を、リスト形式で表示する提示画像をレン� ��リングエンジン22に描画させる(S146)。

 以上の処理により、図19に示す提示画面� �画面表示されるので、操作対象のデータフ� �イルはどのような組織によって作られたか� �情報をベースに表示することが可能となり� �操作対象のデータファイルについてユーザ� �わかりやすい形で情報を提供ができるよう� �なる。

 このように本実施形態に係る再生装置で� ��ユーザにとって意味のないディレクトリ名� ��そのまま表示して操作を行なわせるのでは� ��く、組織名など、ユーザに理解できる表現� ��画面表示することにより、ユーザは操作対� ��のデータの判別が一段としやすくなる。

 尚、本実施の形態では、CertIDディレクト� ��とOrganizationIDディレクトリとに、デジタル� �明書の主体者名の情報を関連付けたが、ADA� �域のAppIDディレクトリについても、ユーザに 分かりやすい情報を関連付けることで、より 詳細な情報提示が可能となる。

 AppIDディレクトリに対するマッピング処� �は、再生装置200の起動後、何れのタイミン� �で行っても良いが、特に、図14に示すアプリ ケーション起動時の署名検証処理の過程で実 行することで、実行の実績がなくアプリケー ションについて不要な情報がマッピング情報 に登録されたり、関連するデータファイルが あるにもかかわらずマッピング情報に登録さ れていない等の不具合を避けることができる 。

 さらに、アプリケーション起動時の署名検� ��処理の過程でAppIDディレクトリに対するマ� �ピング処理を実行することで、アプリケー� �ョンマネージャ32からのアプリケーション起 動要求に含まれるアプリケーションIDを参照� ��ることができるので、BD-Jオブジェクトのア プリケーション管理テーブル内にある情報を 、容易に取得することができる。
BD-Jオブジェクトのアプリケーション管理テ� �ブル内にある情報のうち、図5において破線� ��矢印ai4で示すアプリケーション名や、アイ� ��ンロケータは、AppIDディレクトリと関連付� �る情報として有用である。図20はAppIDが関連� ��けられた場合のマッピング情報の一例を示� ��図である。図20に示すマッピング情報では� �CertID及びOrganizationID の関連付けに加え、AppI Dと関連する情報として、アプリケーション� �理テーブルから取得したアプリケーション� �と、アプリケーション管理テーブルのアイ� �ンロケータが指定するアイコン画像が利用� �れている。

 また、ローカルストレージ表示モジュー� ��20は、提示画面表示処理において、マッピ� �グ情報にAppIDディレクトリが登録されている 際に、図17のステップS145の処理の後に、デー タが配置されているAppIDディレクトリを抽出� ��、抽出したAppIDディレクトリ配下のファイ� �数、その合計サイズ、及び、マッピング情� �においてこのCertIDと関連づけられている情� �を一組のエントリとして、表示リストに追� �するよう構成してもよい。図21は、図20に示� ��マッピング情報を用いて生成した提示画面� ��一例である。AppIDの情報が関連付けられた� �とにより、ユーザは操作対象のデータの判� �が一段としやすくなる。

 なお、本実施の形態ではCertIDディレクト� ��及びOrganizationIDディレクトリに対して、Signe dアプリケーションを含むJavaアーカイブファ� ��ル内にあるデジタル証明書の主体者名の情� ��を用いてるが、デジタル証明書において主� ��者名の情報は図8に示すように、いくつかの 文字情報を含んでいる。そこで、本発明は、 CertIDディレクトリ及びOrganizationIDディレクト� ��に関連付ける情報として、主体者名に含ま� ��る文字情報からユーザが所望のものを選択� ��るよう提示する構成で実施することも可能� ��ある。

 例えば、図14のステップS106、S110の処理に おいて、図22に示すように、デフォルトで選� ��した組織名の登録可否をユーザに確認する� ��認画像をレンダリングエンジン22に描画さ� �、これに対して否定的なUOがあれば、図23に� ��すように、主体者名に含まれる情報から選� ��するか文字列を直接入力するかを問うユー� ��選択画面をレンダリングエンジン22に描画� �せる。ユーザ選択画面でのUOに応じて、図24� ��示す候補選択画面や、図25に示す名称入力� �面をレンダリングエンジン22に描画させて、 これらの画面に対するUOにより、マッピング� ��用いる文字列を取得することができる。図2 4は、主体者名に含まれる情報のリストから� �ッピング処理に用いる情報を選択させる画� �表示の一例であり、主体者名の情報うち、� �実施の形態で関連付けに用いた組織名以外� �ものを表示している。図25は、ユーザに代わ りとなる文字列を、テキスト入力ボックス401 に直接入力させる場合の画面表示の一例であ る。図24で候補から選択された文字列、又は� ��25でユーザが直接入力した文字列は、図14の ステップS106、S110の処理において、デジタル� ��明書の組織名に変えて、マッピング情報へ� ��登録に用いられる。尚、図25に示すように� �名称入力画面は、デジタル証明書の主体者� �の何れかの文字列を、テキスト入力ボック� �401にデフォルトで入力した状態で描画する� �してもよい。

 (第2実施形態)
 BD-ROMディスク上のMETAディレクトリ配下には 、ディスクに関する様々な情報を記録したメ タファイルを格納することができる。メタフ ァイルに記載されている情報の例として、デ ィスクのディスク名及び代表画像、ディスク が誰によって作成されたかを示す作成者情報 、各タイトルに関わるタイトルの作成者情報 等がある。

 第1実施形態ではCertIDディレクトリ及びOrg anizationIDディレクトリに対する関連付けに、S ignedアプリケーションを含むJavaアーカイブフ ァイル内にあるデジタル証明書の主体者名の 情報を用いたが、BD-ROMディスクに記録されて いるメタファイルの情報を、関連付けに用い ることも有用である。そこで第2実施形態で� �、マッピング処理にメタファイルの情報を� �用する構成について説明する。

 図26はメタファイルの情報を用いたマッ� �ング処理の手順を示すフローチャートであ� �。

 図26は図14に示す関連付けの処理手順に、 S151~S152の処理と、S153~S154の処理とを加えたも のである。S151~S152の処理は、メタファイルが BD-ROMディスク上に存在するか否かを確認し(S1 51)、S151でメタファイルが存在することが確� �できた場合に、メタファイルのディスク作� �者情報をCertIDディレクトリと関連づけてマ� �ピング情報に登録する(S152)処理である。153~S 154の処理は、メタファイルがBD-ROMディスク上 に存在するか否かを確認し(S153)、S153でメタ� �ァイルの存在が確認できた場合に、メタフ� �イルのタイトル作成者情報をOrganizationIDディ レクトリと関連づけてマッピング情報に登録 する処理である。これらの手順を加えたマッ ピング処理により、図27に示すマッピング情� ��が生成される。図27で示すように、CertIDデ� �レクトリにはアプリルート証明書の主体者� �に加えて、メタファイルのディスク作成者� �報が関連付けられている。また、OrganizationID ディレクトリには、リーフ証明書の主体者名 に加えて、メタファイルのタイトル作成者情 報が関連付けられている。

 ここで、メタファイルに含まれるディス� ��作成者情報とは、ディスクの作成者を判断� ��きる情報である。メタファイルはxml形式で� ��り、具体的にはディスク作成者情報は、disc info属性のcreator、publisher、contributor、あるい� �titleinfo属性のOrganizationエレメントのname、alte rnativeを用いることができる。

 また、メタファイルのタイトル作成者情� ��とは、OrganizationIDに対応する組織を判断で� �る情報である。具体的にはディスク作成者� �報同様、タイトル作成者情報はdiscinfo属性の creator、publisher、contributor、あるいはtitleinfo属 性のOrganizationエレメントのname、alternativeのい ずれを用いてもよい。

 このようなマッピング情報を用いて提示� ��面を描画することにより、デジタル証明書� ��含まれる情報だけでなく、メタファイルに� ��る情報をADA領域の状態を表示することが可� ��となり、操作対象のデータファイルがどの� ��うなものか類推しやすい形でユーザに提示� ��きるようになる。

 <第2実施形態の変形例>
 (1)メタファイルに含まれる情報のマッピン� ��情報への追加は、アプリケーション起動時� ��署名検証処理を行うタイミングではなく、� ��えばディスク挿入時など事前のタイミング� ��行っておいてもよい。ただし、事前のタイ� ��ングで行った場合はADA領域に情報を書き込� ��アプリ自体が立ち上がっていないため、使� ��されない無駄な情報をマッピング情報に登� ��してしまう可能性がある。

 (2)マッピング処理において、ディレクト� ��へメタファイルのファイル名を関連づける� ��してもよい。図28はメタファイルのファイ� �名をディレクトリに関連付けるマッピング� �理の手順を示すフローチャートである。

 図28は図14に示す関連付けの処理手順に、 S161~S162の処理を加えたものである。S161~S162の 処理は、メタファイルがBD-ROMディスク上に存 在するか否かを確認し(S161)、S161でメタファ� �ルが存在することが確認できた場合に、メ� �ファイルのファイル名をCertID 及びOrganization IDディレクトリと関連づけてマッピング情報� ��登録する(S162)処理である。これらの手順を� ��えたマッピング処理により、図29に示すマ� �ピング情報が生成される。図29で示すように 、OrganizationIDディレクトリには、リーフ証明� ��の主体者名に加えて、メタファイルのファ� ��ル名が関連付けられている。

 図29に示すマッピング情報を用いる場合� �提示画面表示処理では、マッピング情報に� �録されたファイル名に基づいてメタファイ� �を読み出し、CertIDディレクトリ、及びOrganiza tionIDディレクトリに関連するディスク作成者 情報とタイトル作成者情報を取得し、取得し たデータを用いて提示画面を描画させる。

 (3)マッピング情報において、メタファイ� ��の情報とデジタル証明書の情報との両方が� ��ィレクトリに関連付けられている場合は、� ��ちらを優先して表示させるかを示すフラグ� ��マッピング情報に追加してもよい。

 (4)メタファイルは必ずしもBD-ROMディスク� ��に存在するとは限らない。メタファイルが� ��在すればメタファイルの情報を関連付け利� ��し、そうでなければデジタル証明書の情報� ��関連付けに利用するよう再生装置を構成し� ��もよい。

 例えば、図25に示す処理手順ではメタフ� �イルの情報とデジタル証明書の情報の両方� �ローカルストレージに登録したが、メタフ� �イルの情報がある場合はデジタル証明書の� �報を登録する処理(ステップS106、ステップS11 0)を行わないようにし、メタファイルの情報� ��み提示に用いてもよい。

 具体的には、図25のステップS105でアプリ� ��ート証明書で検証が成功と判定すれば、ス� ��ップS151でメタファイルがBD-ROMディスク上に 存在するか否かを確認する。もし、メタファ イルが存在しなかった場合は(S151:No)、アプリ ルート証明書の主体者名を関連付けに用いる S106の処理を実行し、メタファイルが存在し� �場合(S151:Yes)には、S152の処理でメタファイル のディスク作成者情報をCertIDディレクトリと 関連づけた後、S107に処理を進めるよう再生� �置を構成する。

 また、同様にステップS109でリーフ証明書で の検証が成功と判定すれば、ステップS153で� �タファイルがBD-ROMディスク上に存在するか� �かを確認する。もし、メタファイルが存在� �なかった場合は(S153:No)、リーフ証明書の主� �者名を関連付けに用いるS110の処理を実行し� ��メタファイルが存在した場合(S153:Yes)には、 S154の処理でメタファイルのタイトル作成者� �報をOrganizationIDディレクトリと関連づけてた 後、S111へ処理を進める再生装置を構成する� �
(その他の変形例)
 尚、本発明を上記の実施形態に基づいて説� ��してきたが、本発明は、上記の実施形態に� ��定されないのはもちろんである。以下のよ� ��な場合も本発明に含まれる。

 (1)本発明は、各実施形態で説明したフロ� ��チャートの処理手順が開示するデータ管理� ��法であるとしてもよい。また、前記処理手� ��でコンピュータを動作させるプログラムコ� ��ドを含むコンピュータプログラムであると� ��てもよいし、前記コンピュータプログラム� ��らなるデジタル信号であるとしてもよい。

 また、本発明は、前記コンピュータプロ� ��ラム又は前記デジタル信号をコンピュータ� ��み取り可能な記録媒体、例えば、フレキシ� ��ルディスク、ハードディスク、CD-ROM、MO、DV D、DVD-ROM、DVD-RAM、BD(Blu-ray Disc)、半導体メモ� ��など、に記録したものとしてもよい。

 また、本発明は、前記コンピュータプロ� ��ラム又は前記デジタル信号を、電気通信回� ��、無線又は有線通信回線、インターネット� ��代表とするネットワーク等を経由して伝送� ��るものとしてもよい。

 また、前記コンピュータプログラム又は� ��記デジタル信号を前記記録媒体に記録して� ��送することにより、又は前記コンピュータ� ��ログラム又は前記デジタル信号を前記ネッ� ��ワーク等を経由して移送することにより、� ��立した他のコンピュータシステムにより実� ��するとしてもよい。

 (2)本発明は、上記実施の形態に記載のデ� ��タ管理装置を制御するLSIとしても実施可能� ��ある。このようなLSIは、図11に示す制御部13 により実現される機能ブロックを集積化する ことで実現できる。これらの機能ブロックは 、個別に1チップ化されても良いし、一部ま� �は全てを含むように1チップ化されてもよい� ��

 ここでは、LSIとしたが、集積度の違いに� ��り、IC、システムLSI、スーパーLSI、ウルト� �LSIと呼称されることもある。

 また、集積回路化の手法はLSIに限るもの� ��はなく、専用回路または、汎用プロセッサ� ��実現してもよい。LSI製造後にプログラムす� ��ことが可能なFPGA(Field  Programmable  Gate  Ar ray)や、LSI内部の回路セルの接続や設定を再� �成可能なリコンフィギュラブル・プロセッ� �を利用してもよい。

 さらには、半導体技術の進歩または派生� ��る別技術によりLSIに置き換わる集積回路化� ��技術が登場すれば、当然、その技術を用い� ��機能ブロック及び部材の集積化を行っても� ��い。このような技術には、バイオ技術の適� ��等が可能性としてありえる。

 (3)保存データの管理対象たる読み書き可� ��な記録媒体として、第1、第2実施形態では� �再生装置が内蔵するローカルストレージを� �いたが、本発明の特徴は、内蔵ローカルス� �レージの物理的特性に依存するものではな� �、本発明は、他の読み書き可能な記録媒体� �も適用できる。例えば、アプリケーション� �よるデータの保存先として、外付けハード� �ィスクや、再生装置に取り付けられた可搬� �がある記録媒体(例えばSDカードやコンパク� �フラッシュ(登録商標)などの半導体メモリ)� �、データが記録された場合においても上述� �同様の効果を奏することはもちろんのこと� �ある。

 (4)第1、第2実施形態では、ローカルスト� �ージ上にデータファイルを保存するディレ� �トリとして、BD-ROM規格に定められたADAディ� �クトリのディレクトリ構造を用いて説明し� �が、本発明は、データファイルが保存され� �ディレクトリに対応して、データファイル� �保存したアプリケーションに関連する情報� �デジタル証明書等から得られれば、他のデ� �レクトリ構造に対しても適用可能である。

 例えば、MHP(Multimedia Home Platform)/OCAP(OpenCa ble Application Platform)等のインタラクティブテ レビ向けミドルウエア規格に対応したテレビ は、テレビ放送に重畳されたアプリケーショ ンプログラムを、映像コンテンツの再生と共 に実行することにより、データファイルを読 み書き可能な記録媒体に記録する。このよう なMHP/OCAP規格に対応したインタラクティブテ� ��ビにおいても、データファイルの管理に本� ��明を適用することができる。

 具体的には、MHP/OCAP規格に準拠したイン� �ラクティブテレビでは、アプリケーション� �ログラムの作成者を示すOrganizationID、及びア プリケーション自体のIDが放送データから取� ��され、アプリケーションプログラムによる� ��ーカルストレージへのデータ保存は、取得� ��たIDにより特定される「OrganizationIDディレク トリ」、及び「AppIDディレクトリ」の配下へ� ��み許可される。またMHP/OCAP規格では、BD-ROM� �格と同様にSignedアプリケーションにX.509の規 格に準拠したデジタル証明書が付されており 、このデジタル証明書が署名検証に用いられ る。そこで、MHP/OCAP規格に準拠したインタラ� ��ティブテレビへの本発明の適用としては、� ��ーカルストレージに記録されれたデータフ� ��イルについて、保存先の「OrganizationIDディ� �クトリ」、及び「AppIDディレクトリ」の名称 に、デジタル証明書に含まれている主体者名 を関連付けて利用する形態が考えられる。

 (5)第1、第2実施形態では、BD-ROMを再生す� �再生機能を有する再生装置について説明し� �が、本発明は、再生機能のみを有するもの� �はなく記録機能をも有する再生装置にも適� �できることはもちろんのことである。

 (6)上記実施形態、及び上記変形例をそれ� ��れ組み合わせるとしてもよい。