情報記録媒体およびその再生装置、再生方法。
【課題】 映像データ用ＢＤ−ＲＯＭで新たにＸＭＬおよびスクリプトで記述したアプリケーションによる再生制御環境を導入するにあたって、タイトル等の管理単位内で動作するアプリケーションが悪意のある第三者により偽造・改竄されたものではないことを検証する仕組みが必要となる。
【解決手段】 アプリケーションを構成するファイル名とそれぞれのファイルのハッシュ値を記載したファイルリストに対して署名することで、アプリケーション実行時の妥当性を容易にかつ短期間で検証することが可能である。
【解決手段】 アプリケーションを構成するファイル名とそれぞれのファイルのハッシュ値を記載したファイルリストに対して署名することで、アプリケーション実行時の妥当性を容易にかつ短期間で検証することが可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、宣言型言語で記述された再生制御環境のリソース管理を考慮した、ＢＤ−ＲＯＭ等、映像データを記録した情報記録媒体、その再生装置及び再生方法に関し、特に、映像データとプログラムとを含むコンテンツの開発にプログラミング環境を導入する場合の改良に関する。
【背景技術】
【０００２】
映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、ＳＤ−ＤＶＤまたは単にＤＶＤと称する）である。以降、従来のＤＶＤについて説明する。
【０００３】
図１は、ＳＤ−ＤＶＤの構造を示した図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられ、論理アドレス空間の先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
【０００４】
ファイルシステムとは、ＩＳＯ９６６０やＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ）のことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。日常使っているＰＣ（パーソナルコンピュータ）の場合でも、ＦＡＴまたはＮＴＦＳと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。 ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０両方を使用しており（両方を合わせて「ＵＤＦブリッジ」と呼ぶ事がある）、ＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出し（ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である）ができるようになっている。
【０００５】
ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図中「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下のものがある。
【０００６】
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
．．．．．
拡張子として２つの種類が存在する。「ＩＦＯ」は再生制御情報が記録されたファイルであって、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルである。再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
【０００７】
再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット（ＤＶＤでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を１枚のディスクに記録することが可能である。）毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。
【０００８】
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＭＧＩ（ＶＩＤＥＯ Ｍａｎａｇｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶＴＳＩ（Ｖｉｄｅｏ Ｔｉｔｌｅ Ｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ）としてＤＶＤナビゲーション空間に展開される。
【０００９】
ＶＴＳＩの中にはＰＧＣ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ）と呼ばれる再生シーケンスの情報であるＰＧＣＩ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ Ｉｎｆｏｒｍａｔｉｏｎ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間の集合であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。
【００１０】
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、ブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。しかしながらＪａｖａ（登録商標）スクリプトが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプタの指定などを実行するだけのものである点で異なっている。
【００１１】
Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
【００１２】
図１はＡＶストリーム中に埋め込まれているナビゲーション情報を説明する概略図である。ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫと称する）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。
【００１３】
ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には、幾つかのボタンが現れ、夫々のボタンには当該ボタンが選択実行された時の処理が定義されている。また、メニュー上では一つのボタンが選択されており（ハイライトによって選択ボタン上に半透明色がオーバーレイされている）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることができる。リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプタの再生がコマンドによって実行されている。
【００１４】
図２の左上部はＮＶ＿ＰＣＫ内の概要を示している。
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作夫々に対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）が記述されている。
【００１５】
メニュー上のハイライトは、図２の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色をつけた物である。このオーバーレイ画像は右部に示す背景画像と合成されて画面上に表示される。
【００１６】
上述のようにして、ＤＶＤではメニューを実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのは、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニューが表示されるなど、同期タイミングが問題となりやすいアプリケーションの場合でも、問題なく実現できるようにしたためである。
【００１７】
図３は、ＤＶＤのＶＯＢのイメージである。図に示すように、映像、音声、字幕などのデータ（Ａ段）は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（Ｂ段）、夫々を多重化して１本のＭＰＥＧプログラムストリームにしている（Ｃ段）。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。
【００１８】
ＭＰＥＧシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。これはＭＰＥＧシステムストリームのデコーダモデル（一般にＳｙｓｔｅｍ Ｔａｒｇｅｔ Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる（図３のＤ段））が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。このデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢを夫々有している。このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。
【００１９】
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
【００２０】
かかるＤＶＤの構成は、以下の特許文献１に記載されている。
【特許文献１】特許第２８１３２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
ところで次世代の情報記録媒体であるＢＤ−ＲＯＭは、上述したようなプログラム（ナビゲーションコマンド）ではなく、ＸＭＬのような宣言型言語で記述されたデータとスクリプトによるプログラムを含むアプリケーションの記録が予定されている。
【００２２】
映像データと前記アプリケーションからなるコンテンツを情報記録媒体に記録し販売する場合、悪意のある第三者により偽造または改竄された情報記録媒体が流通する可能性がある。また前記アプリケーションをインターネット上のコンテンツサーバから更新または追加することを可能とした場合、ネットワーク上を流れるアプリケーションが改竄されたりコンテンツサーバが詐称されユーザが悪意のあるアプリケーションをダウンロードしてしまう可能性がある。このような悪意のある第三者によって偽造または改竄されたプログラムをプレーヤで実行した場合、プレーヤのシステムが破壊されたり、正規の情報記録媒体に記録された保護すべき映像データが盗まれたり改竄されたりするなどの深刻な問題が発生する。
【課題を解決するための手段】
【００２３】
上記課題を解決するため本発明にかかる情報記録媒体には、アプリケーションを構成するファイル名とそれぞれのファイルのハッシュ値が記載されるファイルリストとそのファイルリストに対する署名と記録される。アプリケーション実行時には前記署名の妥当性を検証し、前記ファイルリストに名前が記載されたファイルのハッシュ値を計算し、その値が前記ファイルリストに記載された値と同一であることを確認する。
【００２４】
上述した構成により、実行するアプリケーションが、正規のスタジオが作成したアプリケーションであるのか、それ以外のアプリケーション、例えば悪意のある第三者がアプリケーションを偽造または改竄したアプリケーションであるのかを判別可能である。
【００２５】
これにより正規のＳｔｕｄｉｏで作成され改竄されていないアプリケーション以外は、深刻な問題を起こしかねないとして実行を拒否したり、利用できる機能やアクセスできるリソースを制限することが可能となる。
【００２６】
本発明は、デジタルストリームを含む１つ以上のタイトルと宣言型言語で記述され１つ以上のファイルから構成される１つ以上のアプリケーションとが記録された情報記録媒体であって、前記情報記録媒体には、アプリケーションを構成するファイル名一覧を記述したファイルリストと前記ファイルリストへの署名データとがアプリケーション毎に記録され、前記ファイルリストはアプリケーションを構成する各ファイルのハッシュ値と前記の署名データのファイル名とを含むことを特徴とする情報記録媒体を提供する。
【００２７】
本発明の一実施態様において、前記ファイルリストは対応する前記タイトル毎に関連付けて記録される。
【００２８】
本発明の一実施態様において、前記ファイルリストには、前記アプリケーションが実行できる機能を記述した実行権限情報のファイル名とそのハッシュ値がさらに記録される。
【００２９】
本発明の一実施態様において、前記情報記録媒体には、前記ファイルリストにファイル名を記載されたファイル本体をそれぞれ格納したアーカイブファイルが記録されており、前記ファイルリストには前記アーカイブファイルへのリンクがさらに記載されている。
【００３０】
本発明はまた、デジタルストリームを含むタイトルの再生と宣言型言語で記述され１つ以上のファイルから構成されるアプリケーションの実行とを同時に行う再生装置であって、複数タイトル間の分岐を制御するタイトル制御部と、１つのタイトルに帰属するデジタルストリームを再生する再生制御部と、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認部と、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込部と、を備えることを特徴とする再生装置を提供する。
【００３１】
本発明の一実施態様において、前述の再生装置は、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理部をさらに備える。
【００３２】
本発明はまた、デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させるプログラムであって、複数タイトル間の分岐を制御するタイトル制御ステップと、１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、をコンピュータに実行させることを特徴とするプログラムを提供する。
【００３３】
本発明の一実施態様において、前述のプログラムは、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む。
【００３４】
本発明はまた、デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させる再生方法であって、複数タイトル間の分岐を制御するタイトル制御ステップと、１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、を含むことを特徴とする再生方法を提供する。
【００３５】
本発明の一実施態様において、上述の再生方法は、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む。
【発明の効果】
【００３６】
上述した構成により、実行するアプリケーションが、正規のスタジオが作成したアプリケーションであるのか、それ以外のアプリケーション、例えば悪意のある第三者がアプリケーションを偽造または改竄したアプリケーションであるのかを判別可能である。
【００３７】
これにより正規のＳｔｕｄｉｏで作成され改竄されていないアプリケーション以外は、深刻な問題を起こしかねないとして実行を拒否したり、利用できる機能やアクセスできるリソースを制限することが可能となる。
【発明を実施するための最良の形態】
【００３８】
（実施の形態１）
まず最初に本発明の第１の実施の形態について説明する。
【００３９】
（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭ（以降、「ＢＤ」と称する場合もある）の構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、ＢＤディスクをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体としてしようすることも当然のことながら可能である。
【００４０】
図５は、上述したＢＤディスクに記録されている論理データを示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
【００４１】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００４２】
本実施の形態の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータ（図４で説明した１０１、１０２、１０３）が記録されているディレクトリである。
【００４３】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００４４】
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わるプログラムを記録したファイルである。
【００４５】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
【００４６】
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００４７】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
【００４８】
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００４９】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。
【００５０】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図６及び図７を用いて説明する。
【００５１】
図６は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに記録される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々記録される。
【００５２】
プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。
【００５３】
プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
【００５４】
管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリスト及びプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。
【００５５】
プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）及びイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。
【００５６】
図６で示すように、ＢＤプレーヤは図４で示したＢＤディスクに記録されているデータ構成に基づいた構成をとっている。
【００５７】
図７は前述したプレーヤ構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。
【００５８】
ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）及びサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。
【００５９】
イメージメモリ（３０８）に記録されたＰＮＧは、次の２つの処理方法がある。イメージデータが字幕用の場合は、プレゼンテーションコントローラ（３０６）によってデコードタイミングが指示される。クロック（３０７）からの時刻情報をシナリオプロセッサ（３０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ（３０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（３０６）からデコード／表示の指示を受けたイメージプロセッサ（３１１）は対応するＰＮＧデータをイメージメモリ（３０８）から抜き出し、デコードし、イメージプレーン（３１４）に描画する。
【００６０】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（３０２）によってデコードタイミングが指示される。プログラムプロセッサ（３０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（３０２）が処理しているＢＤプログラムに因るものであって一概には決まらない。
【００６１】
イメージデータ及び映像データは、図６で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に記録され、合成処理部（３１６）によって合成出力される。
【００６２】
ＢＤディスク（２０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（３０４）に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（３０５）によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（３０６）によって読み出され処理される。
【００６３】
シナリオプロセッサ（３０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（３０６）に指示し、プレゼンテーションコントローラ（３０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（３１７）に指示を出す。
【００６４】
ドライブコントローラ（３１７）はプレゼンテーションコントローラ（３０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（３０８）またはトラックバッファ（３０９）に記録される。
【００６５】
また、シナリオプロセッサ（３０５）は、クロック（３０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（３０２）に投げる。
【００６６】
プログラム記録メモリ（３０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ（３０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（３０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（３０３）からイベントが送られてきた場合である。ＵＯＰマネージャ（３０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（３０２）にイベントを生成する。
【００６７】
（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。
【００６８】
ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択することである。
【００６９】
ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【００７０】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【００７１】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【００７２】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する）を実装することができる。
【００７３】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００７４】
（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。図９に示すように、ＶＯＢは複数のＶＯＢＵ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは０．４秒から１．０秒の時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）によって導かれるものである。
【００７５】
ＶＯＢＵは、その内部にビデオパック（Ｖ＿ＰＣＫ）とオーディオパック（Ａ＿ＰＣＫ）を有している。各パックは１セクタ、本実施の形態の場合は２ｋＢ単位で構成されている。
【００７６】
図１０は、パックの構成を示した図である。
図１０に示すように、ビデオデータ及びオーディオデータといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。パケットヘッダには、ペイロードに格納してあるデータがどのストリームなのか、ビデオなのかオーディオなのか、また、ビデオまたはオーディオが夫々複数ストリームある場合は、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）と、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプＤＴＳ及びＰＴＳが夫々記録されている。ＰＴＳ／ＤＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。
【００７７】
パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプＳＣＲ（Ｓｙｓｔｅｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が記録されている。
【００７８】
（ＶＯＢのインターリーブ記録）
次に図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００７９】
図１１上段は、前述したプレーヤ構成図の一部である。図の通り、ＢＤディスク上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファへ入力され、ＰＮＧ即ちイメージデータであればイメージメモリへと入力される。
【００８０】
トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
【００８１】
図１１下段は、ＢＤディスク上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。
【００８２】
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、非現実的である。
【００８３】
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図１１下段はそのインターリーブ記録を説明した図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
【００８４】
図１２は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。
【００８５】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レートとトラックバッファからのデータ出力レートの間に差を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。ここでトラックバッファへの入力レートをＶａ、トラックバッファからの出力レートをＶｂとする。図１２の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
【００８６】
図１２の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。
【００８７】
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
この後、ＢＤディスク上のアドレス”ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである”−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”ａ３”まで、時刻でいう”ｔ３”までになる。
【００８８】
ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。
【００８９】
この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）
即ち、式２を満たすようにイメージデータの配置を決めればよい事になる。
【００９０】
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。図１３は、ＶＯＢ管理情報情報ファイル（”ＹＹＹ．ＶＯＢＩ”）の内部構造を示した図である。
【００９１】
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）を有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、データフィールドの有無を示している。
【００９２】
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）
６０
５９．９４
５０
３０
２９．９７
２５
２４
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）を夫々有している。
【００９３】
図１４はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つを有している。例えば、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一般式の形で表現することは不可能である。
【００９４】
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータとを一般式の形で表現することは不可能である。これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、各ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数を夫々エントリーとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
【００９５】
図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。
図１５に示すように時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索する。これは、タイム亜マップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が当該時刻を（フレーム数に換算して）超えるまたは一致するＶＯＢＵが当該ＶＯＢＵになる。次にタイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレスになっている。
【００９６】
次に図１６を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【００９７】
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
【００９８】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
【００９９】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）最初の情報も言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）から構成されている。
【０１００】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇｕａｇｅ）と、個々に表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）から構成され、字幕情報（Ｓｐｅｅｃｈ＃）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）から構成されている。
【０１０１】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内であげられるイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）から構成され、個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。
【０１０２】
図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（”ＸＸＸ．ＰＲＯＧ”）である。
【０１０３】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。
【０１０４】
次に図１８を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。
【０１０５】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＴａｂｌｅ）から構成されている。
【０１０６】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【０１０７】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、チャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【０１０８】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
【０１０９】
図１９は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容である。
【０１１０】
（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。
【０１１１】
図２０はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うなどを行うことができる。
【０１１２】
図２１はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。
【０１１３】
図２１に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、プレイリスト＃２の再生を開始する。
【０１１４】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
【０１１５】
図２２はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
【０１１６】
ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合ではプレイリスト＃３の再生を開始している。
【０１１７】
本実施の形態では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。
【０１１８】
（仮想プレーヤマシン）
図２３を用いてプログラムプロセッサの機能構成を説明する。
【０１１９】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行するできることを保証している。
【０１２０】
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ−ＲＯＭ固有関数として定義している。
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅 。
【０１２１】
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１２２】
図２４はシステムパラメータ（ＳＰＲＭ）の一覧である。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備 。
【０１２３】
なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標） Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はＪａｖａ（登録商標） Ｓｃｒｉｐｔに限定されるものでは無い。
【０１２４】
（プログラムの例）
図２５及び図２６は、イベントハンドラでのプログラムの例である。
【０１２５】
図２５は、２つの選択ボタンを持ったメニューの例である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に”１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている事を初期値として持たされている。
【０１２６】
次に、ＰＮＧの描画を描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行っている。ボタン１は、座標（１０、２００）を起点（左端）としてＰＮＧイメージ”１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左端）としてＰＮＧイメージ”２ｗｈｉｔｅ．ｐｎｇ”を描画している。
【０１２７】
また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
【０１２８】
図２６は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２１で説明したとおり、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。
【０１２９】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右ボタン２に変更する。
【０１３０】
ボタン１、ボタン２のイメージを夫々書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合、プレ
イリスト＃２の再生を開始する
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合、プレイリスト＃３の再生を開始する
上記のようにして実行処理が行われる。
【０１３１】
（プレーヤ処理フロー）
次に図２７から図３０を用いてプレーヤでの処理フローを説明する。
【０１３２】
図２７は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯ及びＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１３３】
続いて、シナリオプロセッサは、ＢＤ．ＩＮＦＯファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
【０１３４】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。この場合、ユーザイベントを受け付けるのを待ち続けることになる（Ｓ２０１）。ＢＤ−ＲＯＭプレーヤはがユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。
【０１３５】
プログラムマネージャは、ＵＯＰイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合は、シナリオプロセッサにＵＯＰイベントを流し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
【０１３６】
図２８は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。
【０１３７】
ＡＶ再生の開始（Ｓ４０１）を開始すると、プレゼンテーションコントローラは再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）を読み込み及び解析をする（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出し（Ｓ４０３）、ＶＯＢデータがデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。
【０１３８】
図２９は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
【０１３９】
Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。
【０１４０】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１４１】
Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。
【０１４２】
ステップＳ６０５でＵＯＰイベントがメニューコールで無いと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し（Ｓ６０６）、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行処理する（Ｓ６０８）。
【０１４３】
ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１４４】
図３０は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１４５】
字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
【０１４６】
（実施の形態２）
次に本発明の第２の実施の形態について説明する。
【０１４７】
第２の実施の形態は、ＢＤ−ＲＯＭにおいてより豊かなインタラクティブ性を実現するため、ＸＭＬ・ＸＨＴＭＬベースの画面構成環境と、イベントおよびスクリプトを用いたプログラミング環境を導入することに関する内容である。基本的には第１の実施の形態に基づく内容であり、拡張または異なる部分を中心に説明する。
【０１４８】
（ＸＨＴＭＬファイルを利用したコンテンツ制御）
図３１は、ＸＨＴＭＬおよびスクリプトを利用したシナリオ制御に関わるモジュール構成、制御の流れ、イベントなどの伝わり方を示している。
【０１４９】
ユーザーイベント処理部は、リモコン信号などを受信し、次のモジュールにイベントを割り振るモジュールである。再生制御に関わる、再生／停止／早送り／巻き戻し／スキップ／アングル変更／音声切替／字幕切替などのイベントはＡＶ再生制御部に送られる。ボタンフォーカスの移動（上下左右キー）や決定などのイベントは、ＸＨＴＭＬ処理部に送られる。タイトル切替に関わる、タイトル選択やメニュー呼び出しのイベントは、タイトル制御部に送られる。なお、Ｉｎｄｅｘ Ｔａｂｌｅとは、ディスク中のタイトルを列挙したファイルであり、図１８のＴｉｔｌｅ Ｌｉｓｔ部分を切り出して１つにしたものである。
【０１５０】
タイトル制御部は、タイトル切替を要求されるとＩｎｄｅｘ Ｔａｂｌｅにしたがってタイトル切替を行うモジュールである。タイトルがＸＨＴＭＬで定義される場合、ＸＨＴＭＬ処理部にタイトルに関連付けられたＸＨＴＭＬファイルを読み込むように制御を行う。
【０１５１】
ＸＨＴＭＬ処理部はＸＨＴＭＬファイルを読み込み、スタイル定義情報などにしたがって、画面を構成し、イベントに応じて関連するスクリプトを実行するモジュールである。スクリプトを実行した結果、ＡＶの再生が必要であればＡＶ再生制御部に対して、再生開始などの制御を行い、タイトル切替が必要であれば、タイトル制御部に対して制御を行う。
【０１５２】
ＡＶ再生制御部は、イベントや指示に従ってＡＶストリームの再生を行い、ＡＶ再生制御部の状態が変化したときやＡＶストリームの再生位置が特定の位置に達した際にイベントを生成してＸＨＴＭＬ処理部に通知する。
【０１５３】
プレーヤの状態が変化したことを通知するイベントとは、ユーザーから再生指示があり、ユーザーイベント処理部が再生開始要求のイベントをＡＶ再生制御部に通知すると、ＡＶ再生制御部は再生を開始する。この時に、ＡＶ再生制御部が停止状態から再生状態に変化したことを通知するようなイベントである。
【０１５４】
また、再生位置を通知するイベントとは、ＡＶストリームの終端に達したときや、セルの境界に達したとき、あるいはマークと呼ばれるＡＶストリームの一時点を示すデータが存在する場合その地点に達したことを通知するイベントである。
【０１５５】
図３２はあるタイトルが選択されたときの動作の様子を示している。
Ｉｎｄｅｘ Ｔａｂｌｅで定義されるあるタイトルを選択した場合、タイトルに関連付けられたＸＨＴＭＬファイルが呼び出される。ＸＨＴＭＬファイルには、再生制御などを行うスクリプトなども記述しされている。 図中の例では、スクリプトファイルを間接的に参照しているが、直接ＸＨＴＭＬファイル内に記述することも可能である。また、説明のため、ＸＨＴＭＬと表記しているが、ＸＭＬ形式にのっとっていれば独自のタグなどを利用した形式でもよい。
【０１５６】
図中のＸＨＴＭＬファイル内に記述されている“ｏｎＬｏａｄ”属性において、ファイ
ルが読み込まれたときに実行されるスクリプトを規定している。この例では、ＸＨＴＭＬファイルが読み込まれたときに、“ｐｌａｙＴｉｔｌｅ１”というスクリプトが呼び出さ
れ、スクリプト自体はスクリプトファイル内に記述されている。
【０１５７】
また、＜ｅｖｅｎｔ＞タグを用いることにより、ユーザーイベント処理部やＡＶ再生制御部から通知されたイベントに対応してスクリプトを実行する仕組みも提供する。この例では、“ＥｎｄＯｆＳｔｒｅａｍ”イベントが発生した際、“ｊｕｍｐＴｉｔｌｅ２”と
いうスクリプトを呼び出す例である。なお、“ＥｎｄＯｆＳｔｒｅａｍ”イベントとは、
たとえばＡＶ再生がファイルの終端に達した場合にＡＶ再生制御部が生成するイベントである。
【０１５８】
図３３は先ほどの例に、画面生成を加えた例である。たとえば、先ほどと同様にＩｎｄｅｘ ＴａｂｌｅからＸＨＴＭＬが呼び出され、そのＸＨＴＭＬはメニュー画面などを生成するための情報が書かれていた場合である。画面構成のスタイルなどはＣＳＳなどのスタイルシートを利用してもよい。
【０１５９】
この例では、画面上に２つのボタンを配置している。それぞれのボタンが押されると対応スクリプトが実行される。あるボタンを選択すると、“ｏｎＣｌｉｃｋ”属性に定義さ
れているスクリプトが実行される。ＴｉｔｌｅＡと書かれたＰＮＧイメージファイルと関連付けられている左側のボタンを選択すると、“ｐｌａｙＡ”スクリプトが実行され、タ
イトル１にジャンプする。同様に、ＴｉｔｌｅＢボタンを選択すると、あるＡＶストリームが再生された後に、タイトル２にジャンプする。
【０１６０】
これまで説明した仕組みを用いることのより、ＸＨＴＭＬファイルを用いて、メニュー画面を表示し、何らかのボタンを選択を選択するとコンテンツの再生を開始するような仕組みを提供することが可能となる。
【０１６１】
また、スクリプト部分と、スクリプトが実行するＡＰＩを追加することにより、より複雑な機能、たとえばインターネット接続やダウンロードサービスといったアプリケーションも実行可能である。
【０１６２】
（リソース管理）
ＸＨＴＭＬファイルがメニュー画面のような画面を構成する際には、ＰＮＧイメージファイルなどのデータファイルを参照する。メニューが凝ったものになればなるほど、表示するグラフィクスは複雑なものになり、それを表示するためのイメージデータのサイズは大きくなる。
【０１６３】
また、ＸＨＴＭＬファイルはユーザー操作によって画面を切り替えるように作ることも可能である。メニュー画面の中である項目を選ぶと、さらにサブメニューが出てくるような場合である。このような場合、メニュー画面が表示された最初の瞬間には表示されていなかったイメージデータが、あとから必要になることがある。
【０１６４】
ところが、さらにそのメニュー画面の背景では動画が表示されている、つまりＡＶストリームが再生されている場合、必要になってからイメージデータを読み込みに行こうとすると、ディスク上でファイルがある位置にシークを行ってから読み込んで元の位置に戻ってこなければならず、ＡＶストリームの再生が一時的に中断してしまう可能性がある。十分な量のバッファを積んでおり、ＡＶストリームを事前にバッファ一杯に先読みすればこのようなことも回避できるが、画像が高解像度・高画質になり、高ビットレートが必要になってきているので、かなり大容量のバッファを用意しなければならず、コストアップなどにつながり、現実的ではない。
【０１６５】
また、ハードディスクのようにシーク時間が短く、読み取り速度が速いメディアでは、少量のバッファでもその早さを利用して、ＡＶを中断させずに他のデータを読み込むことも可能であるが、光ディスクメディアのドライブでは、シークには時間がかかり、読み込み速度もそれほど速くないため、実現にはさらなる技術の進歩が必要となる。
【０１６６】
そのため、一旦ＡＶ再生が開始されるとＡＶ以外のデータを読み込みに行かないモデルにすることが望ましい。
【０１６７】
図３４はその様な場合のデータのライフサイクルを示している。
ＡＶの再生が開始される前に、画面を表示するために必要なデータである、ＸＨＴＭＬファイルやスクリプトファイル、それらのファイルから参照されるＰＮＧイメージファイルなどのデータファイルをバッファ上にプリロードしておく。
【０１６８】
一旦ＡＶの再生が開始されると、それらのデータをディスクに読みに行くことはない。
なお、ＡＶの再生が止まってもよい場合は、これらを考慮する必要はない。
【０１６９】
また、コンテンツにより、ＡＶの再生が止まって欲しくない場合と、止まってもよい場合を区別する必要があるならば、管理情報にこの２つのパターンを区別する識別子を用意しておけばよい。
【０１７０】
ＸＨＴＭＬ処理部がデータを必要とするときは、バッファからＸＨＴＭＬ処理部のワークメモリ上に読み込んでおき、画面の表示などに利用する。その画面が表示されなくなったときには、必要なくなったデータをワークメモリから解放し、次に必要になるデータをバッファから読み込んでくる。
【０１７１】
なお、このワークメモリは、バッファと共有してもよい。
バッファにあるメモリーは、そこに読み込まれているデータが必要なくなるまで保存しておき、必要なくなれば解放する。
【０１７２】
（データのライフサイクル）
上で述べたように、バッファにデータを読み込んでくるタイミングと、バッファからデータを解放するタイミングを明確に決めることができれば、データのライフサイクルの管理が明確になり、管理がしやすくなる。
【０１７３】
データの管理がしやすくなれば、コンテンツ作成者がどのプレーヤでも必ず動作させることができるコンテンツ構成を判定しやすくなり、コンテンツ作成が容易になる。
【０１７４】
データのライフサイクルの開始タイミングと終了タイミングは、ＡＶの再生が停止しているタイミング、あるいは一時的に停止する、連続して再生する場合でもシームレスに再生する必要がないタイミングが望ましい。
【０１７５】
このようなタイミングとしては、ＡＶストリームの切替点、ＸＨＴＭＬファイルで構成される画面の切替点や、タイトル切替のタイミングなどがあり、その他上記の条件を満たすのであればその他の点でもよい。
【０１７６】
これまで説明した構造を用いると、タイトルの切替のタイミングは、Ｉｎｄｅｘ Ｔａｂｌｅで明示的に、かつ静的データとして参照することができ、プレーヤから制御しやすい。そのため、データのライフサイクルとは、あるタイトルが開始するときに開始し、あるタイトルが終了するときにライフサイクルも終了する。
【０１７７】
つまり、あるタイトルが開始するときに、そのタイトルを再生するために必要な全てのデータをバッファにプリロードしておき、そのタイトルが終了するとき、たとえば他のタイトルにジャンプするときに、バッファから解放する。
【０１７８】
図３５は書くモジュール間の制御の流れとデータの流れ、それに合わせたデータのライフサイクルを示したタイミングチャートである。
【０１７９】
このようなライフサイクルと、バッファのサイズを規定すれば、タイトルを作成するときに、どのくらいのサイズまでイメージデータを使うことができ、どのようなアプリケーションを実行できるか定量的に判断でき、タイトルが非常に作りやすくなる。
【０１８０】
なお、バッファの解放はタイトル制御部や、より上位のモジュールから強制的に行ってもよいし、ＸＨＴＭＬ処理部が行ってもよい。
【０１８１】
ユーザー操作によりアプリケーション実行中にタイトルを切り替えられた場合、タイトル制御部は、ＸＨＴＭＬ処理部に現在実行中のスクリプトを中止し、バッファの解放を指示ずる。また、タイトルが切り替わると、次のタイトルに関連するファイルをバッファに読み込むよう指示する。
【０１８２】
（データ読み込みの保証）
ＡＶストリームの再生開始より前に、ＡＶストリーム以外のファイルをバッファにプリロードしておく必要は上で述べたとおりである。その際、ＸＨＴＭＬファイルを解析して必要なファイルをリストアップしていては、時間がかかってしまう。
【０１８３】
そこで、図３６（ａ）のように、各タイトルで必要なファイルをリストアップしたファイルリストをタイトル毎に作成し、タイトルが選択されたときに、そのタイトルリストに列挙されているファイルを全てバッファに読み込めばよい。
【０１８４】
また、ファイル数が多い場合、ファイル毎にシークが発生すると読み込みの時間がかかってしまうため、リストアップされたファイルをディスク上の１カ所にまとめて配置することのより、無駄なシークを発生させることなく必要なファイルを全て読み込むことも可能である。
【０１８５】
あるいは、図３６（ｂ）のように、ファイルをディレクトリ構造ごとＺＩＰファイルなどで１つにまとめてしまい、バッファに読み込んだあとでバッファ内でファイルを展開し、ディレクトリ構造などを構成してもよい。ファイルを１まとめにでき、ディレクトリ構造を保持できるようなフォーマットであれば、ＺＩＰファイルでなくてもよい。また、圧縮ファイルである必要もない。
【０１８６】
このような仕組みを用いることにより、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することにより、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【０１８７】
以下、図３６を用いて説明したファイルリストおよびＺｉｐファイルなどのアーカイブファイルを応用した仕組みに関して、より詳細な実装を説明する。
【０１８８】
図３７にＸＭＬを用いてファイルリストを記述した例を図示している。以下図３７に図示したファイルリストをＲｅｓｏｕｒｃｅ Ｆｉｌｅと呼ぶ。Ｒｅｓｏｕｒｃｅ Ｆｉｌｅは各タイトル毎に記述され、各タイトル再生時に実行されるアプリケーションに関する記述がなされる。
【０１８９】
図３２を用いて前述した例では、ＩｎｄｅｘＴａｂｌｅで定義されるタイトルからはＸＨＴＭＬファイルが関連づけられていたが、本仕組みではＩｎｄｅｘＴａｂｌｅで定義された各タイトルからはＲｅｓｏｕｒｃｅ Ｆｉｌｅが関連づけられており、ＩｎｄｅｘＴａｂｌｅで定義されるあるタイトルを選択した場合、そのタイトルに関連づけられたＲｅｓｏｕｒｃｅ Ｆｉｌｅが最初に呼び出される。
【０１９０】
図３７に示すようにＲｅｓｏｕｒｃｅ Ｆｉｌｅはｘｍｌ宣言と、＜ａｐｐｌｉｃａｔｉｏｎ＞＜ｅｎｔｒｙ＞＜ｔｏｐｐａｇｅ＞＜Ｌｉｎｋｆｉｌｅ＞の四つの要素からなる。
＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にアプリケーション名が記述される。
アプリケーションを実行する上で一番最初に読み込んで解析する必要があるＸＭＬデータ（以降Ｔｏｐｐａｇｅと呼ぶ）に関しては、そのファイル名が＜ｔｏｐｐａｇｅ＞要素のｓｒｃ属性として記述されている。
【０１９１】
Ｔｏｐｐａｇｅを除いた、アプリケーションを構成する各ファイルのファイル名がＵＲＩ形式で＜ｌｉｎｋｆｉｌｅ＞要素のｓｒｃ属性としてリストアップされている。
【０１９２】
また、これらのアプリケーションを構成するファイル群（Ｔｏｐｐａｇｅを含む）は、アーカイブファイルとして一纏めにＢＤ−ＲＯＭ上に記録されるものとし、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅには当該アーカイブファイルのファイル名がＵＲＩ形式で＜ｅｎｔｒｙ＞要素のｓｒｃ属性として記述されている。
【０１９３】
このようにＢＤプレーヤはタイトル再生時にそのタイトルに対応するＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込むことで、ＢＤ−ＲＯＭ上にアーカイブファイルとして一纏めに配置されたアプリケーションを構成するファイルを無駄なシークを発生させることなく一括して読み込むことができ、また当該アプリケーションで使用する全てのファイル名を知ることができる。また、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ中の＜Ｔｏｐｐａｇｅ＞要素を参照することで、ＸＨＴＭＬ及びスクリプトで記述されたアプリケーションを実行する際、どのファイルを一番はじめに解析するのかを知ることができる。
【０１９４】
現在再生しているタイトルとは違うタイトルが選択された場合、再生していたタイトルのＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されていたファイルを解放してもよいし、選択されたタイトルに関連づけられたＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されていないファイルのみ解放してもよい。このようにＲｅｓｏｕｒｃｅ Ｆｉｌｅを用いることで、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することが可能であり、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【０１９５】
なお、本実施の形態のＲｅｓｏｕｒｃｅ Ｆｉｌｅでは＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にアプリケーションの名前が記述されており、プレーヤは挿入されたＢＤ−ＲＯＭ Ｄｉｓｃのタイトル名とこのアプリケーション名を用いてプレーヤにて実行されたアプリケーションを識別可能である。したがって、プレーヤのローカルストレージにそれぞれのアプリケーション用の領域を設定してもよい。また、前記アプリケーション用の領域には当該アプリケーションのみがアクセス可能であり、そのほかのアプリケーションのアクセスを禁止しても良い。
【０１９６】
（実施の形態３）
次に本発明の第３の実施の形態について説明する。
【０１９７】
第３の実施の形態は、ＢＤ−ＲＯＭにおいて、ＢＤ−ＲＯＭに記録されたアプリケーションの妥当性を検証し、最適な実行権限をもって実行されることを保証するための環境を導入することに関する内容である。基本的には第１の実施の形態と第２の実施の形態に基づく内容であり、拡張または異なる部分を中心に説明する。
【０１９８】
（アプリケーション認証）
前述したＸＨＴＭＬおよびスクリプトにより、スタジオはＢＤ−ＲＯＭに記録されたコンテンツやＢＤプレーヤの資源を用いて、表現力に富んだアプリケーションをユーザに提供できる。一方で、このようなアプリケーションの実行環境を悪用または誤用されると、ユーザまたはスタジオに様々な被害が及ぶ可能性がある。例えば悪意のある第三者により作成されたＢＤ−ＲＯＭを再生することでプレイヤーのシステムが破壊されたり、プレーヤーの資源が盗まれるといった深刻な問題が発生する可能性がある。また、正規のＢＤ−ＲＯＭを改竄された場合でもプレイヤーのシステムが破壊されたり、プレーヤーの資源が盗まれたり、ＢＤ−ＲＯＭ上のコンテンツが盗まれるといった深刻な問題が発生する可能性がある。
【０１９９】
また、ＸＨＴＭＬおよびスクリプトによるアプリケーションをインターネット上のコンテンツサーバから更新または追加することを可能とした場合、ネットワーク上を流れるアプリケーションが改竄されたりコンテンツサーバが詐称されユーザが悪意のあるアプリケーションをダウンロードしてしまう可能性がある。このような悪意のある第三者によって偽造または改竄されたプログラムをプレーヤで実行した場合、プレーヤのシステムが破壊されたり、正規の情報記録媒体に記録された映像データが盗まれたり改竄されるといった深刻な問題が発生する可能性がある。
【０２００】
このように、ＢＤプレーヤによってＸＨＴＭＬおよびスクリプトによるアプリケーションを実行する際、図３８に示すように正規のスタジオ以外で作成されたアプリケーションや、改竄されたアプリケーションを検出し、深刻な問題を生じさせかねないアプリケーションは実行を拒否したり、利用できる機能やアクセスできるリソースを制限する仕組みが必要である。
【０２０１】
そこで本実施の形態では、ＸＨＴＭＬおよびスクリプトによるアプリケーションが正規のスタジオで作成されたものか否かを検証するアプリケーション認証機構を提供する。以下、本実施の形態のアプリケーション認証機構の概要を図３９を用いて説明する。
【０２０２】
まず、正規のスタジオはＸＨＴＭＬおよびスクリプトによるアプリケーションを作成する（（１）オーサリング）。ＸＨＴＭＬおよびスクリプトによるアプリケーションは１つ以上のファイルから構成される。次にアプリケーションを構成するファイル群全体に対して、公開鍵証明書により署名を行う（（２）署名）。公開鍵証明書はＢＤのライセンス団体に属するスタジオのものでも良いし、ＢＤのライセンス団体が発行したものでもよい。以下、本実施の形態ではアプリケーションに対して署名を行う公開鍵証明書はＢＤのライセンス団体が承認したスタジオの公開鍵証明書とする。また、署名の方法に関しては後述する。以上により作成されたＢＤ−ＲＯＭが販売され、購入したユーザがＢＤプレーヤに挿入すると（（３）販売）、ＢＤプレーヤが前記アプリケーションを実行する際、前記ファイル軍全体に対する署名の妥当性を検証する（（４）署名照合）。これによりアプリケーションが前記スタジオにて作成された正規のものであることが確認され、ＢＤプレーヤはアプリケーションを実行する（（５）実行）。
【０２０３】
以下、本実施の形態における署名の方法について説明する。
ＸＨＴＭＬおよびスクリプトによるアプリケーションは１つ以上のファイルから構成されるが、各ファイル毎に署名を作成する方法ではアプリケーション実行時にアプリケーションを構成する複数のファイル用の複数の署名の妥当性を検証していく必要がありＢＤプレーヤの性能によってはアプリケーション実行時のパフォーマンスが落ちてしまう可能性がある。したがって、本実施の形態における署名には第２の実施の形態で図３７を用いて説明したＲｅｓｏｕｒｃｅ Ｆｉｌｅを応用する。具体的には、アプリケーションを構成するファイルのファイル名一覧を記述しているＲｅｓｏｕｒｃｅ Ｆｉｌｅに各ファイルのハッシュ値をあわせて記述し、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに対してのみ署名することで署名の対象をＲｅｓｏｕｒｃｅ Ｆｉｌｅ１つに限定する。ここで、ハッシュ値とは任意の長さのデータを一方向関数に入力して得られた固定長のデータのことであり、もとのファイルからハッシュ値を計算することは容易であるがハッシュ値から元のファイルを類することは困難であるという特徴と、入力されるデータが少し異なるだけでも得られるハッシュ値が変化するという特徴とをもつ。一方向関数としてはＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）やＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）などがある。
【０２０４】
図４０に本実施の形態よるアプリケーション認証機構を導入した場合のＲｅｓｏｕｒｃｅＦｉｌｅの例を示す。図４０に示すように、アプリケーションを構成するファイル名をリストアップした＜ｔｏｐｐａｇｅ＞要素＜ｌｉｎｋｆｉｌｅ＞要素に、各々のファイルのハッシュ値を記述するための属性値として、ＳＨＡ−１の計算結果を記述する“ｓｈａ
−ｄｉｇｅｓｔ”とＭＤ５の計算結果を記述する“ｍｄ５−ｄｉｇｅｓｔ”を追加してい
る。各要素は“ｓｈａ−ｄｉｇｅｓｔ”“ｍｄ５−ｄｉｇｅｓｔ”のどちらか一方、また
は両方を持つものとする。
【０２０５】
また、図４０に示すＲｅｓｏｕｒｃｅ Ｆｉｌｅは新たに＜Ｓｉｇｎｉｔｕｒｅ＞要素が追加されており、当該Ｒｅｓｒｏｕｒｃｅ Ｆｉｌｅへの署名データのファイル名がＵＲＩ形式で＜ｓｉｇｎｉｔｕｒｅ＞要素のｓｒｃ属性として記述されている。また、署名データの形式が＜ｓｉｇｎｉｔｕｒｅ＞要素のｓｉｇ−ｔｙｐｅ属性として記述されている。ここでＲｅｓｏｕｒｃｅ Ｆｉｌｅに署名後にＲｅｓｏｕｒｃｅ Ｆｉｌｅに署名データのファイル名を記述してしまうとＲｅｓｏｕｒｃｅ Ｆｉｌｅのデータが変更されることになり作成済みの署名データ自体も無効になってしまうため、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記述する署名データのデータ名は署名データ作成前に決定しておく必要がある。署名データのファイル名は、各アプリケーション毎に明示的に一意に決められるようにしてもよい。例えばＴｏｐｐａｇｅと同一ディレクトリにＴｏｐｐａｇｅの同一のファイルボディを持ち、拡張子として“．ｒｓａ”を持つものとして定義してもよい。これによりアプリケーションを作成完了しｔｏｐｐａｇｅの名前が決まった時点で署名データの名前は一意に決まっているため、署名データを作成する前であってもＲｅｓｏｕｒｃｅ Ｆｉｌｅを作成可能であり署名データ作成後でもＲｅｓｏｕｒｃｅ Ｆｉｌｅのデータは変化しない。
【０２０６】
また、署名データの形式としては、ＲＳＡ社が定義したＰＫＣＳ＃７（Ｐｕｂｌｉｃ−Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄｓ ＃７）などがある。ＰＫＣＳ＃７形式によるＲｅｓｏｕｒｃｅ Ｆｉｌｅへの署名データの例を図４１に示す。図４１に示すように、ＰＫＣＳ＃７によるＲｅｓｏｕｒｃｅ Ｆｉｌｅの署名は、Ｖｅｒｓｉｏｎ情報とアルゴリズム情報に加え、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値と、スタジオの公開鍵証明書、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値に対して、前記スタジオの公開鍵証明書を用いて署名した結果とが含まれる。
【０２０７】
以下、図４２を用いて、本実施の形態によるアプリケーションの妥当性検証方法について述べる。
【０２０８】
まず、プレーヤにＢＤ−ＲＯＭ Ｄｉｓｃが挿入されて、ＩｎｄｅｘＴａｂｌｅの先頭が自動選択されたりユーザが選択するなどして、ＩｎｄｅｘＴａｂｌｅで定義された任意タイトルが開始されると（ステップＳ８０１）、プレーヤは当該タイトルが定義されたＩｎｄｅｘＴａｂｌｅを参照し、当該タイトルのＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込んで当該タイトル用のアプリケーション情報を取得する（ステップＳ８０２）。Ｒｅｓｏｕｒｃｅ Ｆｉｌｅは例として図４０を用いて前述した形式をとるものとする。次にＲｅｓｏｕｒｃｅ Ｆｉｌｅ中の＜ｓｉｇｎｉｔｕｒｅ＞要素を参照して署名データを読み込む（ステップＳ８０３）。署名データは例として図４１を用いて前述した形式をとるものとし、署名の対象となるＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値と、その署名、署名に用いたスタジオの公開鍵証明書を含む。次にプレーヤは署名データに含まれるスタジオの公開鍵証明書を取り出す。この公開鍵証明書は一般的な公開鍵証明書であり、スタジオの公開鍵と、その公開鍵に対する認証局による署名、認証局による署名を照合するために用いる認証局の公開鍵証明書のチェーンが含まれる。プレーヤは取り出したスタジオの公開鍵証明書からスタジオの公開鍵を取り出し（ステップＳ８０４）、署名データから取り出したＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値に対する署名をステップＳ８０４で取り出した公開鍵を用いて復号化する（ステップＳ８０５）。次に、署名データからＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を取り出して一方向関数に入力してハッシュ値を計算する（ステップＳ８０６）。次に、ステップＳ８０５で復号化して得た復号化データと、ステップＳ８０６で計算して得たハッシュ値とを比較する（ステップＳ８０７）。復号化データとハッシュ値が等しい場合は、署名データが正しく、またＲｅｓｏｕｒｃｅ Ｆｉｌｅが偽造または改竄されていないことが確認されたこととなり、ステップＳ８０８に進む。復号化データとハッシュ値が等しくない場合は、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅか署名データが改竄または偽造されたことが考えられ、ステップＳ８１１に進む。次にステップＳ８０８において、署名データに含まれるスタジオの公開鍵証明書の妥当性を検証していく。スタジオの公開鍵証明書にはスタジオの公開鍵と公開鍵に対する認証局による署名と署名した認証局の公開鍵証明書が含まれており、スタジオの公開鍵証明書の中に含まれる公開鍵の署名の妥当性をスタジオの公開鍵証明書の中に含まれる認証局の公開鍵証明書を用いて確認（図４２のステップＳ８０４からステップＳ８０７までと同様の手順）する。署名した認証局の公開鍵証明書にもさらに当該認証局の公開鍵を署名した親となる認証局の公開鍵証明書が含まれており、チェーン上になっている。これらの認証局の公開鍵証明書のチェーンを先ほどと同様の手順で妥当性を確認していくと最終的にはルートとなる認証局の公開鍵証明書が得られる。ルート認証局の公開鍵証明書が正規のものであるかどうかの確認方法としては、プレーヤにルート認証局の公開鍵証明書を持たせそれと比較する方法でもよいし、ＢＤ−ＲＯＭに記録しておいてそれと比較する方法でも良い。
【０２０９】
最終的に得られたルート認証局の公開鍵証明書が正規のものであれば最終的にスタジオの公開鍵証明書が妥当であることが確認され（ステップＳ８０９）、ステップＳ８１０に進み、最終的に当該タイトル用のアプリケーションの妥当性が検証される（ステップＳ８１０）。スタジオの公開鍵証明書が妥当でなければステップＳ８１１に進み、アプリケーションが偽造または改竄されている可能性があることを検出する（ステップＳ８１０）。
【０２１０】
アプリケーションが偽造または改竄されている可能性がある場合、当該アプリケーションの実行を拒否しても良いし、プレーヤや保護すべきコンテンツへの影響がない最小限の機能のみ実行できるように制限してアプリケーションを実行しても良い。また、アプリケーション構成ファイル以外のＢＤ−ＲＯＭへのアクセスを拒否したり制限したりしても良いし、プレーヤが備えるＨＤＤやフラッシュメモリなどのローカルストレージへのアクセスを拒否したり制限したりしてもよい。また、妥当性が検証されたアプリケーションに関しても、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅの＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にてアプリケーションの名前が定義されているが、そのアプリケーションに割り当てられたローカルストレージ領域にのみアクセスを許可し、それ以外の名前を持つアプリケーションのローカルストレージ領域へのアクセスは拒否する仕組みを取っても良い。
【０２１１】
なお、本実施の形態ではＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を直接署名データに含ませて署名しているがあくまでも例であり、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅからリンクを張った別の署名用ファイルを用意し、そのファイルにＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値とその他安全性を高めるためのデータ（例えばＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述したアプリケーションを構成する各ファイルのハッシュ値をさらに一方向関数に通して得られたハッシュ値の一覧など）を用意し、それに署名する仕組みをとってもよい。
【０２１２】
以上、アプリケーションの妥当性検証方法について図４２を用いて述べたが、実際にアプリケーションを実行する際はさらにアプリケーションを構成する各ファイルについて図４３に示すようにアプリケーションファイルの妥当性を検証する必要がある。
【０２１３】
以下、図４３を用いて本実施の形態におけるアプリケーションファイルの妥当性検証方法について述べる。
【０２１４】
まずアプリケーションの妥当性検証が完了すると（ステップＳ９０１）、アプリケーションに必要なファイルを読み込む（ステップＳ９０２）。ここでアプリケーションを構成するファイルは前述したように、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ中に＜ｔｏｐｐａｇｅ＞要素や＜ｌｉｎｋｆｉｌｅ＞要素にて記述されている。次にステップＳ９０２で読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているかどうかを確認する（ステップＳ９０３）。これは、例えばＴｏｐｐａｇｅからリンクを張られて読み込まれたファイルが、スタジオの想定したものであるかどうかを確認するためのものであり、Ｔｏｐｐａｇｅの改竄がなければ読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているはずである。読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されている場合（ステップＳ９０４のｙｅｓ）はステップＳ９０５に進み、記載されていなければ（ステップＳ９０４のｎｏ）当該ファイルへのリンクを張ったファイルが改竄されている可能性がありステップＳ９０９に進む。次にステップＳ９０５において、ステップＳ９０２にて読み込んだファイルのハッシュ値を計算する。このとき、＜ｔｏｐｐａｇｅ＞＜ｌｉｎｋｆｉｌｅ＞要素においてｓｈａ−ｄｉｇｅｓｔ属性が指定されている場合はＳＨＡ−１にてハッシュ値を計算し、ｍｄ５−ｄｉｇｅｓｔ属性が指定されている場合はＭＤ５にてハッシュ値を計算し、二つとも指定されている場合はＳＨＡ−１とＭＤ５の二つのハッシュ値を計算するものとする。次に、ステップＳ９０５において計算したハッシュ値と、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値とを比較する（ステップＳ９０６）。ここでステップＳ９０５で計算したハッシュ値が、ＳＨＡ−１にて計算したハッシュ値である場合は、ｓｈａ−ｄｉｇｅｓｔ属性にて指定された値と比較し、ＭＤ５にて計算したハッシュ値である場合はｍｄ５−ｄｉｇｅｓｔ属性にて指定された値と比較する。ＳＨＡ−１とＭＤ５の双方のハッシュ値を計算した場合はその両方をそれぞれ比較する。ステップＳ９０５で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値が等しければ（ステップＳ９０７のｙｅｓ）、読み込まれたファイルは改竄または偽造されていないファイルであることが確認されたことになる（ステップＳ９０８）。一方、ステップＳ９０５で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値が等しくなければ（ステップＳ９０７のｎｏ）、読み込まれたファイルは偽造、または改竄された可能性があることになる（ステップＳ９０９）。
【０２１５】
なお、アプリケーションファイルの妥当性検証は、プレーヤがＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込んでアプリケーションの妥当性検証が完了した直後に、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているアプリケーションを構成する全てのファイルに対して行っても良いし、アプリケーションを実行するにあたって必要になったファイルをその都度検証していく方法でも良い。この場合、前記アプリケーションの妥当性検証が完了した後は、Ｒｅｓｒｏｕｃｅ Ｆｉｌｅ中の＜ｔｏｐｐａｇｅ＞要素で記述されたＴｏｐｐａｇｅのみに対してアプリケーションファイルの妥当性検証が行われ、以降、Ｔｏｐｐａｇｅからリンクを張られるなどしてアプリケーションを実行する上で必要となったファイルに対して逐次妥当性の検証が行われる。
【０２１６】
また、アプリケーション及びその構成ファイルの妥当性を検証出来なかった場合、単にアプリケーションの実行を禁止するだけでなく、当該アプリケーションが記録されたＢＤ−ＲＯＭ Ｄｉｓｃ自体の実行を禁止しても良い。そのほかにも、アプリケーション及びその構成ファイルの妥当性を検証出来なかった場合に、システムに悪影響を及ぼしかねない機能の実行や保護すべきコンテンツへのアクセスを禁止し、実行させるという対策をとっても良い。
【０２１７】
（アプリケーションの実行権限制御）
以上、アプリケーションの妥当性検証方法と、アプリケーションを構成するファイルの妥当性検証方法について本実施の形態を述べたが、さらに妥当性を検証したアプリケーションに対して実行できる権限を必要な範囲に限定することで、プレーヤのシステムやコンテンツをより安全に保つことができる。
【０２１８】
例えば前述したようにアプリケーションの妥当性を検証出来なかったアプリケーションには最小限の機能実行権限のみを割り当て、妥当性を検証したアプリケーションに関しても、あらかじめ規定された必要な機能のみ実行でき、かつ規定された必要なデータ領域にのみデータを読み書きできるようにすることで、例えば想定外の動作による不具合などを防止でき、プレーヤやコンテンツをより安全に保つことができる。
【０２１９】
そこで、本実施の形態ではアプリケーションの実行権限を制御する仕組みをさらに提供する。アプリケーション作成時にアプリケーションが実行できる機能やアクセスできるデータ領域を記述したＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを用意してアプリケーションに添付する。プレーヤはアプリケーションの妥当性検証を実施した後、このＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅに基づいてアプリケーションの実行権限を設定した上でアプリケーションを実行するものとする。
【０２２０】
以下、本実施の形態におけるアプリケーションの実行権限制御の具体例について説明する。
【０２２１】
まず図４４に示すように、プレーヤがアプリケーションの実行する際に当該アプリケーションのＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを一意に読み出せるようＲｅｓｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｒｍｉｓｓｉｏｎ＞要素を設けＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名を記述するものとする。また、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの偽造、改竄を防ぐため、アプリケーションの構成ファイルと同じくそのハッシュ値をＲｅｓｒｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｒｍｉｓｓｉｏｎ＞要素のｓｈａ−ｄｉｇｅｓｔ属性またはｍｄ５−ｄｉｇｅｓｔ属性（または双方）として記述するものとする。このようにＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値をＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述することで前述したアプリケーション構成ファイルの妥当性検証と同様の手順で、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証を行うことができる。
【０２２２】
ここでＰｅｒｍｉｓｓｉｏｎ ｆｉｌｅはテキスト形式やＸＭＬなど任意のフォーマットで記述されるものとし、プレーヤが備える機能や関数に対して当該アプリケーションが実行できるか否かや、実行するために必要な条件などが記載されるものとする。また必要に応じて、当該アプリケーションがアクセスできるＤｉｓｃ領域やローカルストレージ領域に関して例えばＵＲＩ形式で記述され、それぞれの領域に対して、データを読み込めるか否か、書き込めるのか否か、実行できるか否かといった条件が記述されるものとする。またプレーヤがネットワーク通信機能を持つ場合、必要に応じて、当該アプリケーションがネットワークアクセス可能なＵＲＩを記述しアプリケーションが接続可能なサーバを限定するものとする。
【０２２３】
なお、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名は各アプリケーション毎に明示的に決められるようにしてもよい。例えばアプリケーションのＴｏｐｐａｇｅと同一ディレクトリにＴｏｐｐａｇｅの同一のファイルボディを持ち、拡張子として“．ｐｅｒｍ”を
持つものとして定義してもよい。
【０２２４】
以下、図４５を用いてＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証とアプリケーションの権限設定のフローチャートを説明する。
【０２２５】
まずアプリケーションの妥当性検証が完了すると（ステップＳ１００１）、プレーヤはＲｅｓｏｕｒｃｅ Ｆｉｌｅの＜ｐｅｒｍｉｓｓｉｏｎ＞要素を参照してＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを読み込む（ステップＳ１００２）。次にステップＳ１００２で読み込んだＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを一方向関数に通し、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１００３）。このとき、＜ｐｅｒｍｉｓｓｉｏｎ＞要素にｓｈａ−ｄｉｇｅｓｔ属性が指定されている場合はＳＨＡ−１を用いてハッシュ値を計算し、ｍｄ５−ｄｉｇｅｓｔ属性が指定されている場合はＭＤ５を用いてハッシュ値を計算し、二つとも指定されている場合はＳＨＡ−１とＭＤ５の二つのハッシュ値を計算する。次に、ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｍｉｓｓｉｏｎ＞要素のｓｈａ−ｄｉｇｅｓｔ属性・ｍｄ５−ｄｉｇｅｓｔ属性で記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値とを比較する（ステップＳ１００４）。ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値が等しければ（ステップＳ１００５のｙｅｓ）、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅは改竄または偽造されていないことが確認されたことになり、ステップＳ１００６に進む。一方、ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値が等しくなければ（ステップＳ１００５のｎｏ）、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅは偽造、または改竄された可能性があることになり、アプリケーションの実行を禁止したり、最小限の権限を与えてアプリケーションを実行する（ステップＳ１００８）。ステップＳ１００６では、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの記述を解釈し、プレーヤに当該アプリケーションの権限を設定する（ステップＳ１００６）。以上の処理により当該アプリケーションが実行できる権限を設定するとプレーヤはアプリケーションを実行する（ステップＳ１００７）。
【０２２６】
なお、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを用いたアプリケーションの権限設定を行う場合、図４２を用いて述べたアプリケーションの妥当性検証の完了後に、図４５で述べたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証とアプリケーションの権限設定を行ってアプリケーションの実行に移ると、図４３を用いて述べたように、アプリケーションが使用するファイルの妥当性検証を行うこととなる。
【０２２７】
（アプリケーションの作成手順）
次に、スタジオにおいてアプリケーションをオーサリングしたあと、アプリケーションの認証および権限制御に必要な情報を付加してＢＤ−ＲＯＭに記録するまでの手順について図４６を用いて説明する。
【０２２８】
まずスタジオにてＸＨＴＭＬおよびスクリプトによるアプリケーションのオーサリングが完了すると（ステップＳ１１０１）、この時点で、アプリケーションのＴｏｐｐａｇｅとそれ以外のアプリケーションを構成するファイルの名前が決定され、また各ファイルのディレクトリ構成も決定する。次に当該アプリケーションに最適かつ必要な実行権限を記述したＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを作成する（ステップＳ１１０２）。次にアプリケーションを構成する各ファイルとＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１１０３）。次にＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名とアーカイブファイルのファイル名、署名データのファイル名と配置位置を決定する（ステップＳ１１０４）。この際、それぞれ任意にファイル名を決定しても良いし、アプリケーション毎に一意に決定される固有の値としても良い。例えばそれぞれのファイルの配置位置を当該アプリケーションのＴｏｐｐａｇｅと同一ディレクトリとし、さらにファイルボディをＴｏｐｐａｇｅのファイルボディと同一としてそれぞれの拡張子をＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅであれば“．ｐｅｒｍ”、アーカイブファイルであれば“．ｂｄｉ”、署名
データであれば“．ｒｓａ”としてもよい。以上までの処理で得た情報を元に当該アプリ
ケーションのＲｅｓｏｕｒｃｅ Ｆｉｌｅを作成する（ステップＳ１１０５）。次に、ステップＳ１１０５にて作成したＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１１０６）。次に以上までの処理で得た情報を元に署名データを作成する（ステップＳ１１０７）。次に各ファイルの構成ファイルとＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ、署名データを各ファイルのディレクトリ構成を保ったままファイルを一纏めにするアーカイブファイルにする（ステップＳ１１０８）。アーカイブファイルの例としてはＭＩＭＥ形式やＴａｒ形式や圧縮ファイル形式であるＺｉｐ形式やＬＺＨ形式、ＣＡＢ形式がある。圧縮形式を採用することでＢＤ−ＲＯＭに記録するデータ量が減り、また読込にかかる時間を短縮できる利点があるが、ＭＩＭＥ形式やＴａｒ形式に比べてファイルを展開する時間がかかるという欠点がある。最後に、ステップＳ１１０５で作成したＲｅｓｏｕｒｃｅ ＦｉｌｅとステップＳ１１０８で作成したアーカイブファイルとをＢＤ−ＲＯＭの所定の位置に記録する（ステップＳ１１０９）。
【０２２９】
なお、本実施の形態にて述べたアプリケーションの実行権限制御の仕組みを利用しない場合はステップＳ１１０２におけるＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの作成などＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅに関する処理は実施しない。
【産業上の利用可能性】
【０２３０】
本発明を利用することにより、映像データとＸＭＬおよびスクリプトによるＡＶ再生制御を導入することが可能となる。特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用される可能性をもつ。
【図面の簡単な説明】
【０２３１】
【図１】ＤＶＤの構成図
【図２】ハイライトの構成図
【図３】ＤＶＤでの多重化の例を示す図
【図４】ＢＤ−ＲＯＭのデータ階層図
【図５】ＢＤ−ＲＯＭ上の論理空間の構成図
【図６】ＢＤ−ＲＯＭプレーヤの概要ブロック図
【図７】ＢＤ−ＲＯＭプレーヤの構成ブロック図
【図８】ＢＤ−ＲＯＭのアプリケーション空間の説明図
【図９】ＭＰＥＧストリーム（ＶＯＢ）の構成図
【図１０】パックの構成図
【図１１】ＡＶストリームとプレーヤ構成の関係を説明する図
【図１２】トラックバッファへのＡＶデータ連続供給モデル図
【図１３】ＶＯＢ情報ファイル構成図
【図１４】タイムマップの説明図
【図１５】タイムマップを使ったアドレス情報取得方法説明図
【図１６】プレイリストファイルの構成図
【図１７】プレイリストに対応するプログラムファイルの構成図
【図１８】ＢＤディスク全体管理情報ファイルの構成図
【図１９】グローバルイベントハンドラを記録するファイルの構成図
【図２０】タイムイベントの例を説明する図
【図２１】ユーザイベントの例を説明する図
【図２２】グローバルイベントハンドラの例を説明する図
【図２３】仮想マシンの構成図
【図２４】プレーヤ変数テーブルの図
【図２５】イベントハンドラ（タイムイベント）の例を示す図
【図２６】イベントハンドラ（ユーザイベント）の例を示す図
【図２７】プレーヤの基本処理のフローチャート
【図２８】プレイリスト再生処理のフローチャート
【図２９】イベント処理のフローチャート
【図３０】字幕処理のフローチャート
【図３１】モジュール構成や制御の流れを説明する図
【図３２】Ｉｎｄｅｘ ＴａｂｌｅとＸＨＴＭＬファイルの関係を説明する図
【図３３】ボタンが表示されるＸＨＴＭＬファイルの例
【図３４】データのライフサイクルを説明する説明図
【図３５】データのライフサイクルを説明するタイミングチャート
【図３６】データを１つにまとめる方法を説明する図
【図３７】Ｒｅｓｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図３８】偽造・改竄されたアプリケーションについて説明する図
【図３９】アプリケーション認証の概要を説明する図
【図４０】アプリケーション認証機能を備えたＲｅｓｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図４１】署名データの構成図
【図４２】アプリケーションの妥当性検証処理のフローチャート
【図４３】アプリケーション構成ファイルの妥当性検証処理のフローチャート
【図４４】実行権限制御機能を備えたＲｅｓｒｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図４５】アプリケーションの実行権限制御処理のフローチャート
【図４６】作成したアプリケーションをＤｉｓｃに記録するまでのフローチャート
【符号の説明】
【０２３２】
２０１ ＢＤディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０１ プログラム記録メモリ
３０２ プログラムプロセッサ
３０３ ＵＯＰマネージャ
３０４ 管理情報記録メモリ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１４ イメージプレーン
３１５ ビデオプレーン
３１６ 合成処理部
３１７ ドライブコントローラ
Ｓ１０１ ディスク挿入ステップ
Ｓ１０２ ＢＤ．ＩＮＦＯ読み込みステップ
Ｓ１０３ ＢＤ．ＰＲＯＧ読み込みステップ
Ｓ１０４ ファーストイベント生成ステップ
Ｓ１０５ イベントハンドラ実行ステップ
Ｓ２０１ ＵＯＰ受付ステップ
Ｓ２０２ ＵＯＰイベント生成ステップ
Ｓ２０３ メニューコール判定ステップ
Ｓ２０４ イベント生成ステップ
Ｓ２０５ イベントハンドラ実行ステップ
Ｓ３０１ プレイリスト再生開始ステップ
Ｓ３０２ プレイリスト情報（ＸＸＸ．ＰＬ）読み込みステップ
Ｓ３０３ プレイリストプログラム（ＸＸＸ．ＰＲＯＧ）読み込みステップ
Ｓ３０４ セル再生開始ステップ
Ｓ３０５ ＡＶ再生開始ステップ
Ｓ４０１ ＡＶ再生開始ステップ
Ｓ４０２ ＶＯＢ情報（ＹＹＹ．ＶＯＢＩ）読み込みステップ
Ｓ４０３ ＶＯＢ（ＹＹＹ．ＶＯＢ）読み込みステップ
Ｓ４０４ ＶＯＢ再生開始ステップ
Ｓ４０５ ＶＯＢ再生終了ステップ
Ｓ４０６ 次セル存在判定ステップ
Ｓ５０１ プレイリスト再生開始ステップ
Ｓ５０２ プレイリスト再生終了判定ステップ
Ｓ５０３ タイムイベント時刻判定ステップ
Ｓ５０４ イベント生成ステップ
Ｓ５０５ イベントハンドラ実行ステップ
Ｓ６０１ プレイリスト再生開始ステップ
Ｓ６０２ プレイリスト再生終了判定ステップ
Ｓ６０３ ＵＯＰ受付判定ステップ
Ｓ６０４ ＵＯＰイベント生成ステップ
Ｓ６０５ メニューコール判定ステップ
Ｓ６０６ ユーザーイベント有効期間判定ステップ
Ｓ６０７ イベント生成ステップ
Ｓ６０８ イベントハンドラ実行ステップ
Ｓ７０１ プレイリスト再生開始ステップ
Ｓ７０２ プレイリスト再生終了判定ステップ
Ｓ７０３ 字幕描画開始判定ステップ
Ｓ７０４ 字幕描画ステップ
Ｓ７０５ 字幕表示終了判定ステップ
Ｓ７０６ 字幕消去ステップ
Ｓ８０１ タイトル開始ステップ
Ｓ８０２ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ読込ステップ
Ｓ８０３ 署名データ読込ステップ
Ｓ８０４ 公開鍵抽出ステップ
Ｓ８０５ 署名復号化ステップ
Ｓ８０６ 署名検証用ハッシュ値計算ステップ
Ｓ８０７ 署名判定ステップ
Ｓ８０８ 公開鍵証明書照合ステップ
Ｓ８０９ 公開鍵証明書判定ステップ
Ｓ８１０ アプリケーション妥当性検証完了ステップ
Ｓ８１１ アプリケーションの偽造改竄検出ステップ
Ｓ９０１ アプリケーション妥当性検証完了ステップ
Ｓ９０２ アプリケーション構成ファイル読込ステップ
Ｓ９０３ 構成ファイルの存在確認ステップ
Ｓ９０４ 存在判定ステップ
Ｓ９０５ 構成Ｆｉｌｅハッシュ値計算ステップ
Ｓ９０６ ハッシュ値比較ステップ
Ｓ９０７ ハッシュ値判定ステップ
Ｓ９０８ アプリケーション構成ファイル妥当性検証完了ステップ
Ｓ９０９ アプリケーションデータの偽造改竄検出ステップ
Ｓ１００１ アプリケーション妥当性検証完了ステップ
Ｓ１００２ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ読込ステップ
Ｓ１００３ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値計算ステップ
Ｓ１００４ ハッシュ値比較ステップ
Ｓ１００５ ハッシュ値判定ステップ
Ｓ１００６ アプリケーション権限設定ステップ
Ｓ１００７ アプリケーション実行ステップ
Ｓ１００８ アプリケーション不正検出ステップ
Ｓ１１０１ アプリケーションオーサリング完了ステップ
Ｓ１１０２ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ作成ステップ
Ｓ１１０３ ハッシュ値計算ステップ
Ｓ１１０４ ファイル名決定ステップ
Ｓ１１０５ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ作成ステップ
Ｓ１１０６ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値計算ステップ
Ｓ１１０７ 署名データ作成ステップ
Ｓ１１０８ アーカイブファイル作成ステップ
Ｓ１１０９ ＢＤ−ＲＯＭ作成ステップ
【技術分野】
【０００１】
本発明は、宣言型言語で記述された再生制御環境のリソース管理を考慮した、ＢＤ−ＲＯＭ等、映像データを記録した情報記録媒体、その再生装置及び再生方法に関し、特に、映像データとプログラムとを含むコンテンツの開発にプログラミング環境を導入する場合の改良に関する。
【背景技術】
【０００２】
映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、ＳＤ−ＤＶＤまたは単にＤＶＤと称する）である。以降、従来のＤＶＤについて説明する。
【０００３】
図１は、ＳＤ−ＤＶＤの構造を示した図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられ、論理アドレス空間の先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
【０００４】
ファイルシステムとは、ＩＳＯ９６６０やＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ）のことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。日常使っているＰＣ（パーソナルコンピュータ）の場合でも、ＦＡＴまたはＮＴＦＳと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。 ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０両方を使用しており（両方を合わせて「ＵＤＦブリッジ」と呼ぶ事がある）、ＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出し（ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である）ができるようになっている。
【０００５】
ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図中「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下のものがある。
【０００６】
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
．．．．．
拡張子として２つの種類が存在する。「ＩＦＯ」は再生制御情報が記録されたファイルであって、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルである。再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
【０００７】
再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット（ＤＶＤでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を１枚のディスクに記録することが可能である。）毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。
【０００８】
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＭＧＩ（ＶＩＤＥＯ Ｍａｎａｇｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶＴＳＩ（Ｖｉｄｅｏ Ｔｉｔｌｅ Ｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ）としてＤＶＤナビゲーション空間に展開される。
【０００９】
ＶＴＳＩの中にはＰＧＣ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ）と呼ばれる再生シーケンスの情報であるＰＧＣＩ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ Ｉｎｆｏｒｍａｔｉｏｎ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間の集合であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。
【００１０】
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、ブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。しかしながらＪａｖａ（登録商標）スクリプトが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプタの指定などを実行するだけのものである点で異なっている。
【００１１】
Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
【００１２】
図１はＡＶストリーム中に埋め込まれているナビゲーション情報を説明する概略図である。ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫと称する）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。
【００１３】
ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には、幾つかのボタンが現れ、夫々のボタンには当該ボタンが選択実行された時の処理が定義されている。また、メニュー上では一つのボタンが選択されており（ハイライトによって選択ボタン上に半透明色がオーバーレイされている）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることができる。リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプタの再生がコマンドによって実行されている。
【００１４】
図２の左上部はＮＶ＿ＰＣＫ内の概要を示している。
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作夫々に対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）が記述されている。
【００１５】
メニュー上のハイライトは、図２の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色をつけた物である。このオーバーレイ画像は右部に示す背景画像と合成されて画面上に表示される。
【００１６】
上述のようにして、ＤＶＤではメニューを実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのは、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニューが表示されるなど、同期タイミングが問題となりやすいアプリケーションの場合でも、問題なく実現できるようにしたためである。
【００１７】
図３は、ＤＶＤのＶＯＢのイメージである。図に示すように、映像、音声、字幕などのデータ（Ａ段）は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（Ｂ段）、夫々を多重化して１本のＭＰＥＧプログラムストリームにしている（Ｃ段）。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。
【００１８】
ＭＰＥＧシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。これはＭＰＥＧシステムストリームのデコーダモデル（一般にＳｙｓｔｅｍ Ｔａｒｇｅｔ Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる（図３のＤ段））が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。このデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢを夫々有している。このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。
【００１９】
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
【００２０】
かかるＤＶＤの構成は、以下の特許文献１に記載されている。
【特許文献１】特許第２８１３２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
ところで次世代の情報記録媒体であるＢＤ−ＲＯＭは、上述したようなプログラム（ナビゲーションコマンド）ではなく、ＸＭＬのような宣言型言語で記述されたデータとスクリプトによるプログラムを含むアプリケーションの記録が予定されている。
【００２２】
映像データと前記アプリケーションからなるコンテンツを情報記録媒体に記録し販売する場合、悪意のある第三者により偽造または改竄された情報記録媒体が流通する可能性がある。また前記アプリケーションをインターネット上のコンテンツサーバから更新または追加することを可能とした場合、ネットワーク上を流れるアプリケーションが改竄されたりコンテンツサーバが詐称されユーザが悪意のあるアプリケーションをダウンロードしてしまう可能性がある。このような悪意のある第三者によって偽造または改竄されたプログラムをプレーヤで実行した場合、プレーヤのシステムが破壊されたり、正規の情報記録媒体に記録された保護すべき映像データが盗まれたり改竄されたりするなどの深刻な問題が発生する。
【課題を解決するための手段】
【００２３】
上記課題を解決するため本発明にかかる情報記録媒体には、アプリケーションを構成するファイル名とそれぞれのファイルのハッシュ値が記載されるファイルリストとそのファイルリストに対する署名と記録される。アプリケーション実行時には前記署名の妥当性を検証し、前記ファイルリストに名前が記載されたファイルのハッシュ値を計算し、その値が前記ファイルリストに記載された値と同一であることを確認する。
【００２４】
上述した構成により、実行するアプリケーションが、正規のスタジオが作成したアプリケーションであるのか、それ以外のアプリケーション、例えば悪意のある第三者がアプリケーションを偽造または改竄したアプリケーションであるのかを判別可能である。
【００２５】
これにより正規のＳｔｕｄｉｏで作成され改竄されていないアプリケーション以外は、深刻な問題を起こしかねないとして実行を拒否したり、利用できる機能やアクセスできるリソースを制限することが可能となる。
【００２６】
本発明は、デジタルストリームを含む１つ以上のタイトルと宣言型言語で記述され１つ以上のファイルから構成される１つ以上のアプリケーションとが記録された情報記録媒体であって、前記情報記録媒体には、アプリケーションを構成するファイル名一覧を記述したファイルリストと前記ファイルリストへの署名データとがアプリケーション毎に記録され、前記ファイルリストはアプリケーションを構成する各ファイルのハッシュ値と前記の署名データのファイル名とを含むことを特徴とする情報記録媒体を提供する。
【００２７】
本発明の一実施態様において、前記ファイルリストは対応する前記タイトル毎に関連付けて記録される。
【００２８】
本発明の一実施態様において、前記ファイルリストには、前記アプリケーションが実行できる機能を記述した実行権限情報のファイル名とそのハッシュ値がさらに記録される。
【００２９】
本発明の一実施態様において、前記情報記録媒体には、前記ファイルリストにファイル名を記載されたファイル本体をそれぞれ格納したアーカイブファイルが記録されており、前記ファイルリストには前記アーカイブファイルへのリンクがさらに記載されている。
【００３０】
本発明はまた、デジタルストリームを含むタイトルの再生と宣言型言語で記述され１つ以上のファイルから構成されるアプリケーションの実行とを同時に行う再生装置であって、複数タイトル間の分岐を制御するタイトル制御部と、１つのタイトルに帰属するデジタルストリームを再生する再生制御部と、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認部と、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込部と、を備えることを特徴とする再生装置を提供する。
【００３１】
本発明の一実施態様において、前述の再生装置は、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理部をさらに備える。
【００３２】
本発明はまた、デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させるプログラムであって、複数タイトル間の分岐を制御するタイトル制御ステップと、１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、をコンピュータに実行させることを特徴とするプログラムを提供する。
【００３３】
本発明の一実施態様において、前述のプログラムは、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む。
【００３４】
本発明はまた、デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させる再生方法であって、複数タイトル間の分岐を制御するタイトル制御ステップと、１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、を含むことを特徴とする再生方法を提供する。
【００３５】
本発明の一実施態様において、上述の再生方法は、前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む。
【発明の効果】
【００３６】
上述した構成により、実行するアプリケーションが、正規のスタジオが作成したアプリケーションであるのか、それ以外のアプリケーション、例えば悪意のある第三者がアプリケーションを偽造または改竄したアプリケーションであるのかを判別可能である。
【００３７】
これにより正規のＳｔｕｄｉｏで作成され改竄されていないアプリケーション以外は、深刻な問題を起こしかねないとして実行を拒否したり、利用できる機能やアクセスできるリソースを制限することが可能となる。
【発明を実施するための最良の形態】
【００３８】
（実施の形態１）
まず最初に本発明の第１の実施の形態について説明する。
【００３９】
（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭ（以降、「ＢＤ」と称する場合もある）の構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、ＢＤディスクをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体としてしようすることも当然のことながら可能である。
【００４０】
図５は、上述したＢＤディスクに記録されている論理データを示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
【００４１】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００４２】
本実施の形態の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータ（図４で説明した１０１、１０２、１０３）が記録されているディレクトリである。
【００４３】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００４４】
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わるプログラムを記録したファイルである。
【００４５】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
【００４６】
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００４７】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
【００４８】
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００４９】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。
【００５０】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図６及び図７を用いて説明する。
【００５１】
図６は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに記録される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々記録される。
【００５２】
プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。
【００５３】
プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
【００５４】
管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリスト及びプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。
【００５５】
プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）及びイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。
【００５６】
図６で示すように、ＢＤプレーヤは図４で示したＢＤディスクに記録されているデータ構成に基づいた構成をとっている。
【００５７】
図７は前述したプレーヤ構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。
【００５８】
ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）及びサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。
【００５９】
イメージメモリ（３０８）に記録されたＰＮＧは、次の２つの処理方法がある。イメージデータが字幕用の場合は、プレゼンテーションコントローラ（３０６）によってデコードタイミングが指示される。クロック（３０７）からの時刻情報をシナリオプロセッサ（３０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ（３０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（３０６）からデコード／表示の指示を受けたイメージプロセッサ（３１１）は対応するＰＮＧデータをイメージメモリ（３０８）から抜き出し、デコードし、イメージプレーン（３１４）に描画する。
【００６０】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（３０２）によってデコードタイミングが指示される。プログラムプロセッサ（３０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（３０２）が処理しているＢＤプログラムに因るものであって一概には決まらない。
【００６１】
イメージデータ及び映像データは、図６で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に記録され、合成処理部（３１６）によって合成出力される。
【００６２】
ＢＤディスク（２０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（３０４）に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（３０５）によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（３０６）によって読み出され処理される。
【００６３】
シナリオプロセッサ（３０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（３０６）に指示し、プレゼンテーションコントローラ（３０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（３１７）に指示を出す。
【００６４】
ドライブコントローラ（３１７）はプレゼンテーションコントローラ（３０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（３０８）またはトラックバッファ（３０９）に記録される。
【００６５】
また、シナリオプロセッサ（３０５）は、クロック（３０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（３０２）に投げる。
【００６６】
プログラム記録メモリ（３０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ（３０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（３０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（３０３）からイベントが送られてきた場合である。ＵＯＰマネージャ（３０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（３０２）にイベントを生成する。
【００６７】
（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。
【００６８】
ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択することである。
【００６９】
ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【００７０】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【００７１】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【００７２】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する）を実装することができる。
【００７３】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００７４】
（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。図９に示すように、ＶＯＢは複数のＶＯＢＵ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは０．４秒から１．０秒の時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）によって導かれるものである。
【００７５】
ＶＯＢＵは、その内部にビデオパック（Ｖ＿ＰＣＫ）とオーディオパック（Ａ＿ＰＣＫ）を有している。各パックは１セクタ、本実施の形態の場合は２ｋＢ単位で構成されている。
【００７６】
図１０は、パックの構成を示した図である。
図１０に示すように、ビデオデータ及びオーディオデータといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。パケットヘッダには、ペイロードに格納してあるデータがどのストリームなのか、ビデオなのかオーディオなのか、また、ビデオまたはオーディオが夫々複数ストリームある場合は、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）と、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプＤＴＳ及びＰＴＳが夫々記録されている。ＰＴＳ／ＤＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。
【００７７】
パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプＳＣＲ（Ｓｙｓｔｅｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が記録されている。
【００７８】
（ＶＯＢのインターリーブ記録）
次に図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００７９】
図１１上段は、前述したプレーヤ構成図の一部である。図の通り、ＢＤディスク上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファへ入力され、ＰＮＧ即ちイメージデータであればイメージメモリへと入力される。
【００８０】
トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
【００８１】
図１１下段は、ＢＤディスク上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。
【００８２】
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、非現実的である。
【００８３】
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図１１下段はそのインターリーブ記録を説明した図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
【００８４】
図１２は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。
【００８５】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レートとトラックバッファからのデータ出力レートの間に差を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。ここでトラックバッファへの入力レートをＶａ、トラックバッファからの出力レートをＶｂとする。図１２の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
【００８６】
図１２の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。
【００８７】
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
この後、ＢＤディスク上のアドレス”ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである”−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”ａ３”まで、時刻でいう”ｔ３”までになる。
【００８８】
ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。
【００８９】
この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）
即ち、式２を満たすようにイメージデータの配置を決めればよい事になる。
【００９０】
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。図１３は、ＶＯＢ管理情報情報ファイル（”ＹＹＹ．ＶＯＢＩ”）の内部構造を示した図である。
【００９１】
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）を有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、データフィールドの有無を示している。
【００９２】
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）
６０
５９．９４
５０
３０
２９．９７
２５
２４
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）を夫々有している。
【００９３】
図１４はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つを有している。例えば、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一般式の形で表現することは不可能である。
【００９４】
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータとを一般式の形で表現することは不可能である。これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、各ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数を夫々エントリーとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
【００９５】
図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。
図１５に示すように時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索する。これは、タイム亜マップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が当該時刻を（フレーム数に換算して）超えるまたは一致するＶＯＢＵが当該ＶＯＢＵになる。次にタイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレスになっている。
【００９６】
次に図１６を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【００９７】
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
【００９８】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
【００９９】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）最初の情報も言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）から構成されている。
【０１００】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇｕａｇｅ）と、個々に表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）から構成され、字幕情報（Ｓｐｅｅｃｈ＃）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）から構成されている。
【０１０１】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内であげられるイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）から構成され、個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。
【０１０２】
図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（”ＸＸＸ．ＰＲＯＧ”）である。
【０１０３】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。
【０１０４】
次に図１８を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。
【０１０５】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＴａｂｌｅ）から構成されている。
【０１０６】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【０１０７】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、チャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【０１０８】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
【０１０９】
図１９は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容である。
【０１１０】
（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。
【０１１１】
図２０はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うなどを行うことができる。
【０１１２】
図２１はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。
【０１１３】
図２１に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、プレイリスト＃２の再生を開始する。
【０１１４】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
【０１１５】
図２２はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
【０１１６】
ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合ではプレイリスト＃３の再生を開始している。
【０１１７】
本実施の形態では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。
【０１１８】
（仮想プレーヤマシン）
図２３を用いてプログラムプロセッサの機能構成を説明する。
【０１１９】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行するできることを保証している。
【０１２０】
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ−ＲＯＭ固有関数として定義している。
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅 。
【０１２１】
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１２２】
図２４はシステムパラメータ（ＳＰＲＭ）の一覧である。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備 。
【０１２３】
なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標） Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はＪａｖａ（登録商標） Ｓｃｒｉｐｔに限定されるものでは無い。
【０１２４】
（プログラムの例）
図２５及び図２６は、イベントハンドラでのプログラムの例である。
【０１２５】
図２５は、２つの選択ボタンを持ったメニューの例である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に”１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている事を初期値として持たされている。
【０１２６】
次に、ＰＮＧの描画を描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行っている。ボタン１は、座標（１０、２００）を起点（左端）としてＰＮＧイメージ”１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左端）としてＰＮＧイメージ”２ｗｈｉｔｅ．ｐｎｇ”を描画している。
【０１２７】
また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
【０１２８】
図２６は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２１で説明したとおり、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。
【０１２９】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右ボタン２に変更する。
【０１３０】
ボタン１、ボタン２のイメージを夫々書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合、プレ
イリスト＃２の再生を開始する
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合、プレイリスト＃３の再生を開始する
上記のようにして実行処理が行われる。
【０１３１】
（プレーヤ処理フロー）
次に図２７から図３０を用いてプレーヤでの処理フローを説明する。
【０１３２】
図２７は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯ及びＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１３３】
続いて、シナリオプロセッサは、ＢＤ．ＩＮＦＯファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
【０１３４】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。この場合、ユーザイベントを受け付けるのを待ち続けることになる（Ｓ２０１）。ＢＤ−ＲＯＭプレーヤはがユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。
【０１３５】
プログラムマネージャは、ＵＯＰイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合は、シナリオプロセッサにＵＯＰイベントを流し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
【０１３６】
図２８は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。
【０１３７】
ＡＶ再生の開始（Ｓ４０１）を開始すると、プレゼンテーションコントローラは再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）を読み込み及び解析をする（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出し（Ｓ４０３）、ＶＯＢデータがデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。
【０１３８】
図２９は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
【０１３９】
Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。
【０１４０】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１４１】
Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。
【０１４２】
ステップＳ６０５でＵＯＰイベントがメニューコールで無いと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し（Ｓ６０６）、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行処理する（Ｓ６０８）。
【０１４３】
ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１４４】
図３０は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１４５】
字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
【０１４６】
（実施の形態２）
次に本発明の第２の実施の形態について説明する。
【０１４７】
第２の実施の形態は、ＢＤ−ＲＯＭにおいてより豊かなインタラクティブ性を実現するため、ＸＭＬ・ＸＨＴＭＬベースの画面構成環境と、イベントおよびスクリプトを用いたプログラミング環境を導入することに関する内容である。基本的には第１の実施の形態に基づく内容であり、拡張または異なる部分を中心に説明する。
【０１４８】
（ＸＨＴＭＬファイルを利用したコンテンツ制御）
図３１は、ＸＨＴＭＬおよびスクリプトを利用したシナリオ制御に関わるモジュール構成、制御の流れ、イベントなどの伝わり方を示している。
【０１４９】
ユーザーイベント処理部は、リモコン信号などを受信し、次のモジュールにイベントを割り振るモジュールである。再生制御に関わる、再生／停止／早送り／巻き戻し／スキップ／アングル変更／音声切替／字幕切替などのイベントはＡＶ再生制御部に送られる。ボタンフォーカスの移動（上下左右キー）や決定などのイベントは、ＸＨＴＭＬ処理部に送られる。タイトル切替に関わる、タイトル選択やメニュー呼び出しのイベントは、タイトル制御部に送られる。なお、Ｉｎｄｅｘ Ｔａｂｌｅとは、ディスク中のタイトルを列挙したファイルであり、図１８のＴｉｔｌｅ Ｌｉｓｔ部分を切り出して１つにしたものである。
【０１５０】
タイトル制御部は、タイトル切替を要求されるとＩｎｄｅｘ Ｔａｂｌｅにしたがってタイトル切替を行うモジュールである。タイトルがＸＨＴＭＬで定義される場合、ＸＨＴＭＬ処理部にタイトルに関連付けられたＸＨＴＭＬファイルを読み込むように制御を行う。
【０１５１】
ＸＨＴＭＬ処理部はＸＨＴＭＬファイルを読み込み、スタイル定義情報などにしたがって、画面を構成し、イベントに応じて関連するスクリプトを実行するモジュールである。スクリプトを実行した結果、ＡＶの再生が必要であればＡＶ再生制御部に対して、再生開始などの制御を行い、タイトル切替が必要であれば、タイトル制御部に対して制御を行う。
【０１５２】
ＡＶ再生制御部は、イベントや指示に従ってＡＶストリームの再生を行い、ＡＶ再生制御部の状態が変化したときやＡＶストリームの再生位置が特定の位置に達した際にイベントを生成してＸＨＴＭＬ処理部に通知する。
【０１５３】
プレーヤの状態が変化したことを通知するイベントとは、ユーザーから再生指示があり、ユーザーイベント処理部が再生開始要求のイベントをＡＶ再生制御部に通知すると、ＡＶ再生制御部は再生を開始する。この時に、ＡＶ再生制御部が停止状態から再生状態に変化したことを通知するようなイベントである。
【０１５４】
また、再生位置を通知するイベントとは、ＡＶストリームの終端に達したときや、セルの境界に達したとき、あるいはマークと呼ばれるＡＶストリームの一時点を示すデータが存在する場合その地点に達したことを通知するイベントである。
【０１５５】
図３２はあるタイトルが選択されたときの動作の様子を示している。
Ｉｎｄｅｘ Ｔａｂｌｅで定義されるあるタイトルを選択した場合、タイトルに関連付けられたＸＨＴＭＬファイルが呼び出される。ＸＨＴＭＬファイルには、再生制御などを行うスクリプトなども記述しされている。 図中の例では、スクリプトファイルを間接的に参照しているが、直接ＸＨＴＭＬファイル内に記述することも可能である。また、説明のため、ＸＨＴＭＬと表記しているが、ＸＭＬ形式にのっとっていれば独自のタグなどを利用した形式でもよい。
【０１５６】
図中のＸＨＴＭＬファイル内に記述されている“ｏｎＬｏａｄ”属性において、ファイ
ルが読み込まれたときに実行されるスクリプトを規定している。この例では、ＸＨＴＭＬファイルが読み込まれたときに、“ｐｌａｙＴｉｔｌｅ１”というスクリプトが呼び出さ
れ、スクリプト自体はスクリプトファイル内に記述されている。
【０１５７】
また、＜ｅｖｅｎｔ＞タグを用いることにより、ユーザーイベント処理部やＡＶ再生制御部から通知されたイベントに対応してスクリプトを実行する仕組みも提供する。この例では、“ＥｎｄＯｆＳｔｒｅａｍ”イベントが発生した際、“ｊｕｍｐＴｉｔｌｅ２”と
いうスクリプトを呼び出す例である。なお、“ＥｎｄＯｆＳｔｒｅａｍ”イベントとは、
たとえばＡＶ再生がファイルの終端に達した場合にＡＶ再生制御部が生成するイベントである。
【０１５８】
図３３は先ほどの例に、画面生成を加えた例である。たとえば、先ほどと同様にＩｎｄｅｘ ＴａｂｌｅからＸＨＴＭＬが呼び出され、そのＸＨＴＭＬはメニュー画面などを生成するための情報が書かれていた場合である。画面構成のスタイルなどはＣＳＳなどのスタイルシートを利用してもよい。
【０１５９】
この例では、画面上に２つのボタンを配置している。それぞれのボタンが押されると対応スクリプトが実行される。あるボタンを選択すると、“ｏｎＣｌｉｃｋ”属性に定義さ
れているスクリプトが実行される。ＴｉｔｌｅＡと書かれたＰＮＧイメージファイルと関連付けられている左側のボタンを選択すると、“ｐｌａｙＡ”スクリプトが実行され、タ
イトル１にジャンプする。同様に、ＴｉｔｌｅＢボタンを選択すると、あるＡＶストリームが再生された後に、タイトル２にジャンプする。
【０１６０】
これまで説明した仕組みを用いることのより、ＸＨＴＭＬファイルを用いて、メニュー画面を表示し、何らかのボタンを選択を選択するとコンテンツの再生を開始するような仕組みを提供することが可能となる。
【０１６１】
また、スクリプト部分と、スクリプトが実行するＡＰＩを追加することにより、より複雑な機能、たとえばインターネット接続やダウンロードサービスといったアプリケーションも実行可能である。
【０１６２】
（リソース管理）
ＸＨＴＭＬファイルがメニュー画面のような画面を構成する際には、ＰＮＧイメージファイルなどのデータファイルを参照する。メニューが凝ったものになればなるほど、表示するグラフィクスは複雑なものになり、それを表示するためのイメージデータのサイズは大きくなる。
【０１６３】
また、ＸＨＴＭＬファイルはユーザー操作によって画面を切り替えるように作ることも可能である。メニュー画面の中である項目を選ぶと、さらにサブメニューが出てくるような場合である。このような場合、メニュー画面が表示された最初の瞬間には表示されていなかったイメージデータが、あとから必要になることがある。
【０１６４】
ところが、さらにそのメニュー画面の背景では動画が表示されている、つまりＡＶストリームが再生されている場合、必要になってからイメージデータを読み込みに行こうとすると、ディスク上でファイルがある位置にシークを行ってから読み込んで元の位置に戻ってこなければならず、ＡＶストリームの再生が一時的に中断してしまう可能性がある。十分な量のバッファを積んでおり、ＡＶストリームを事前にバッファ一杯に先読みすればこのようなことも回避できるが、画像が高解像度・高画質になり、高ビットレートが必要になってきているので、かなり大容量のバッファを用意しなければならず、コストアップなどにつながり、現実的ではない。
【０１６５】
また、ハードディスクのようにシーク時間が短く、読み取り速度が速いメディアでは、少量のバッファでもその早さを利用して、ＡＶを中断させずに他のデータを読み込むことも可能であるが、光ディスクメディアのドライブでは、シークには時間がかかり、読み込み速度もそれほど速くないため、実現にはさらなる技術の進歩が必要となる。
【０１６６】
そのため、一旦ＡＶ再生が開始されるとＡＶ以外のデータを読み込みに行かないモデルにすることが望ましい。
【０１６７】
図３４はその様な場合のデータのライフサイクルを示している。
ＡＶの再生が開始される前に、画面を表示するために必要なデータである、ＸＨＴＭＬファイルやスクリプトファイル、それらのファイルから参照されるＰＮＧイメージファイルなどのデータファイルをバッファ上にプリロードしておく。
【０１６８】
一旦ＡＶの再生が開始されると、それらのデータをディスクに読みに行くことはない。
なお、ＡＶの再生が止まってもよい場合は、これらを考慮する必要はない。
【０１６９】
また、コンテンツにより、ＡＶの再生が止まって欲しくない場合と、止まってもよい場合を区別する必要があるならば、管理情報にこの２つのパターンを区別する識別子を用意しておけばよい。
【０１７０】
ＸＨＴＭＬ処理部がデータを必要とするときは、バッファからＸＨＴＭＬ処理部のワークメモリ上に読み込んでおき、画面の表示などに利用する。その画面が表示されなくなったときには、必要なくなったデータをワークメモリから解放し、次に必要になるデータをバッファから読み込んでくる。
【０１７１】
なお、このワークメモリは、バッファと共有してもよい。
バッファにあるメモリーは、そこに読み込まれているデータが必要なくなるまで保存しておき、必要なくなれば解放する。
【０１７２】
（データのライフサイクル）
上で述べたように、バッファにデータを読み込んでくるタイミングと、バッファからデータを解放するタイミングを明確に決めることができれば、データのライフサイクルの管理が明確になり、管理がしやすくなる。
【０１７３】
データの管理がしやすくなれば、コンテンツ作成者がどのプレーヤでも必ず動作させることができるコンテンツ構成を判定しやすくなり、コンテンツ作成が容易になる。
【０１７４】
データのライフサイクルの開始タイミングと終了タイミングは、ＡＶの再生が停止しているタイミング、あるいは一時的に停止する、連続して再生する場合でもシームレスに再生する必要がないタイミングが望ましい。
【０１７５】
このようなタイミングとしては、ＡＶストリームの切替点、ＸＨＴＭＬファイルで構成される画面の切替点や、タイトル切替のタイミングなどがあり、その他上記の条件を満たすのであればその他の点でもよい。
【０１７６】
これまで説明した構造を用いると、タイトルの切替のタイミングは、Ｉｎｄｅｘ Ｔａｂｌｅで明示的に、かつ静的データとして参照することができ、プレーヤから制御しやすい。そのため、データのライフサイクルとは、あるタイトルが開始するときに開始し、あるタイトルが終了するときにライフサイクルも終了する。
【０１７７】
つまり、あるタイトルが開始するときに、そのタイトルを再生するために必要な全てのデータをバッファにプリロードしておき、そのタイトルが終了するとき、たとえば他のタイトルにジャンプするときに、バッファから解放する。
【０１７８】
図３５は書くモジュール間の制御の流れとデータの流れ、それに合わせたデータのライフサイクルを示したタイミングチャートである。
【０１７９】
このようなライフサイクルと、バッファのサイズを規定すれば、タイトルを作成するときに、どのくらいのサイズまでイメージデータを使うことができ、どのようなアプリケーションを実行できるか定量的に判断でき、タイトルが非常に作りやすくなる。
【０１８０】
なお、バッファの解放はタイトル制御部や、より上位のモジュールから強制的に行ってもよいし、ＸＨＴＭＬ処理部が行ってもよい。
【０１８１】
ユーザー操作によりアプリケーション実行中にタイトルを切り替えられた場合、タイトル制御部は、ＸＨＴＭＬ処理部に現在実行中のスクリプトを中止し、バッファの解放を指示ずる。また、タイトルが切り替わると、次のタイトルに関連するファイルをバッファに読み込むよう指示する。
【０１８２】
（データ読み込みの保証）
ＡＶストリームの再生開始より前に、ＡＶストリーム以外のファイルをバッファにプリロードしておく必要は上で述べたとおりである。その際、ＸＨＴＭＬファイルを解析して必要なファイルをリストアップしていては、時間がかかってしまう。
【０１８３】
そこで、図３６（ａ）のように、各タイトルで必要なファイルをリストアップしたファイルリストをタイトル毎に作成し、タイトルが選択されたときに、そのタイトルリストに列挙されているファイルを全てバッファに読み込めばよい。
【０１８４】
また、ファイル数が多い場合、ファイル毎にシークが発生すると読み込みの時間がかかってしまうため、リストアップされたファイルをディスク上の１カ所にまとめて配置することのより、無駄なシークを発生させることなく必要なファイルを全て読み込むことも可能である。
【０１８５】
あるいは、図３６（ｂ）のように、ファイルをディレクトリ構造ごとＺＩＰファイルなどで１つにまとめてしまい、バッファに読み込んだあとでバッファ内でファイルを展開し、ディレクトリ構造などを構成してもよい。ファイルを１まとめにでき、ディレクトリ構造を保持できるようなフォーマットであれば、ＺＩＰファイルでなくてもよい。また、圧縮ファイルである必要もない。
【０１８６】
このような仕組みを用いることにより、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することにより、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【０１８７】
以下、図３６を用いて説明したファイルリストおよびＺｉｐファイルなどのアーカイブファイルを応用した仕組みに関して、より詳細な実装を説明する。
【０１８８】
図３７にＸＭＬを用いてファイルリストを記述した例を図示している。以下図３７に図示したファイルリストをＲｅｓｏｕｒｃｅ Ｆｉｌｅと呼ぶ。Ｒｅｓｏｕｒｃｅ Ｆｉｌｅは各タイトル毎に記述され、各タイトル再生時に実行されるアプリケーションに関する記述がなされる。
【０１８９】
図３２を用いて前述した例では、ＩｎｄｅｘＴａｂｌｅで定義されるタイトルからはＸＨＴＭＬファイルが関連づけられていたが、本仕組みではＩｎｄｅｘＴａｂｌｅで定義された各タイトルからはＲｅｓｏｕｒｃｅ Ｆｉｌｅが関連づけられており、ＩｎｄｅｘＴａｂｌｅで定義されるあるタイトルを選択した場合、そのタイトルに関連づけられたＲｅｓｏｕｒｃｅ Ｆｉｌｅが最初に呼び出される。
【０１９０】
図３７に示すようにＲｅｓｏｕｒｃｅ Ｆｉｌｅはｘｍｌ宣言と、＜ａｐｐｌｉｃａｔｉｏｎ＞＜ｅｎｔｒｙ＞＜ｔｏｐｐａｇｅ＞＜Ｌｉｎｋｆｉｌｅ＞の四つの要素からなる。
＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にアプリケーション名が記述される。
アプリケーションを実行する上で一番最初に読み込んで解析する必要があるＸＭＬデータ（以降Ｔｏｐｐａｇｅと呼ぶ）に関しては、そのファイル名が＜ｔｏｐｐａｇｅ＞要素のｓｒｃ属性として記述されている。
【０１９１】
Ｔｏｐｐａｇｅを除いた、アプリケーションを構成する各ファイルのファイル名がＵＲＩ形式で＜ｌｉｎｋｆｉｌｅ＞要素のｓｒｃ属性としてリストアップされている。
【０１９２】
また、これらのアプリケーションを構成するファイル群（Ｔｏｐｐａｇｅを含む）は、アーカイブファイルとして一纏めにＢＤ−ＲＯＭ上に記録されるものとし、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅには当該アーカイブファイルのファイル名がＵＲＩ形式で＜ｅｎｔｒｙ＞要素のｓｒｃ属性として記述されている。
【０１９３】
このようにＢＤプレーヤはタイトル再生時にそのタイトルに対応するＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込むことで、ＢＤ−ＲＯＭ上にアーカイブファイルとして一纏めに配置されたアプリケーションを構成するファイルを無駄なシークを発生させることなく一括して読み込むことができ、また当該アプリケーションで使用する全てのファイル名を知ることができる。また、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ中の＜Ｔｏｐｐａｇｅ＞要素を参照することで、ＸＨＴＭＬ及びスクリプトで記述されたアプリケーションを実行する際、どのファイルを一番はじめに解析するのかを知ることができる。
【０１９４】
現在再生しているタイトルとは違うタイトルが選択された場合、再生していたタイトルのＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されていたファイルを解放してもよいし、選択されたタイトルに関連づけられたＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されていないファイルのみ解放してもよい。このようにＲｅｓｏｕｒｃｅ Ｆｉｌｅを用いることで、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することが可能であり、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【０１９５】
なお、本実施の形態のＲｅｓｏｕｒｃｅ Ｆｉｌｅでは＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にアプリケーションの名前が記述されており、プレーヤは挿入されたＢＤ−ＲＯＭ Ｄｉｓｃのタイトル名とこのアプリケーション名を用いてプレーヤにて実行されたアプリケーションを識別可能である。したがって、プレーヤのローカルストレージにそれぞれのアプリケーション用の領域を設定してもよい。また、前記アプリケーション用の領域には当該アプリケーションのみがアクセス可能であり、そのほかのアプリケーションのアクセスを禁止しても良い。
【０１９６】
（実施の形態３）
次に本発明の第３の実施の形態について説明する。
【０１９７】
第３の実施の形態は、ＢＤ−ＲＯＭにおいて、ＢＤ−ＲＯＭに記録されたアプリケーションの妥当性を検証し、最適な実行権限をもって実行されることを保証するための環境を導入することに関する内容である。基本的には第１の実施の形態と第２の実施の形態に基づく内容であり、拡張または異なる部分を中心に説明する。
【０１９８】
（アプリケーション認証）
前述したＸＨＴＭＬおよびスクリプトにより、スタジオはＢＤ−ＲＯＭに記録されたコンテンツやＢＤプレーヤの資源を用いて、表現力に富んだアプリケーションをユーザに提供できる。一方で、このようなアプリケーションの実行環境を悪用または誤用されると、ユーザまたはスタジオに様々な被害が及ぶ可能性がある。例えば悪意のある第三者により作成されたＢＤ−ＲＯＭを再生することでプレイヤーのシステムが破壊されたり、プレーヤーの資源が盗まれるといった深刻な問題が発生する可能性がある。また、正規のＢＤ−ＲＯＭを改竄された場合でもプレイヤーのシステムが破壊されたり、プレーヤーの資源が盗まれたり、ＢＤ−ＲＯＭ上のコンテンツが盗まれるといった深刻な問題が発生する可能性がある。
【０１９９】
また、ＸＨＴＭＬおよびスクリプトによるアプリケーションをインターネット上のコンテンツサーバから更新または追加することを可能とした場合、ネットワーク上を流れるアプリケーションが改竄されたりコンテンツサーバが詐称されユーザが悪意のあるアプリケーションをダウンロードしてしまう可能性がある。このような悪意のある第三者によって偽造または改竄されたプログラムをプレーヤで実行した場合、プレーヤのシステムが破壊されたり、正規の情報記録媒体に記録された映像データが盗まれたり改竄されるといった深刻な問題が発生する可能性がある。
【０２００】
このように、ＢＤプレーヤによってＸＨＴＭＬおよびスクリプトによるアプリケーションを実行する際、図３８に示すように正規のスタジオ以外で作成されたアプリケーションや、改竄されたアプリケーションを検出し、深刻な問題を生じさせかねないアプリケーションは実行を拒否したり、利用できる機能やアクセスできるリソースを制限する仕組みが必要である。
【０２０１】
そこで本実施の形態では、ＸＨＴＭＬおよびスクリプトによるアプリケーションが正規のスタジオで作成されたものか否かを検証するアプリケーション認証機構を提供する。以下、本実施の形態のアプリケーション認証機構の概要を図３９を用いて説明する。
【０２０２】
まず、正規のスタジオはＸＨＴＭＬおよびスクリプトによるアプリケーションを作成する（（１）オーサリング）。ＸＨＴＭＬおよびスクリプトによるアプリケーションは１つ以上のファイルから構成される。次にアプリケーションを構成するファイル群全体に対して、公開鍵証明書により署名を行う（（２）署名）。公開鍵証明書はＢＤのライセンス団体に属するスタジオのものでも良いし、ＢＤのライセンス団体が発行したものでもよい。以下、本実施の形態ではアプリケーションに対して署名を行う公開鍵証明書はＢＤのライセンス団体が承認したスタジオの公開鍵証明書とする。また、署名の方法に関しては後述する。以上により作成されたＢＤ−ＲＯＭが販売され、購入したユーザがＢＤプレーヤに挿入すると（（３）販売）、ＢＤプレーヤが前記アプリケーションを実行する際、前記ファイル軍全体に対する署名の妥当性を検証する（（４）署名照合）。これによりアプリケーションが前記スタジオにて作成された正規のものであることが確認され、ＢＤプレーヤはアプリケーションを実行する（（５）実行）。
【０２０３】
以下、本実施の形態における署名の方法について説明する。
ＸＨＴＭＬおよびスクリプトによるアプリケーションは１つ以上のファイルから構成されるが、各ファイル毎に署名を作成する方法ではアプリケーション実行時にアプリケーションを構成する複数のファイル用の複数の署名の妥当性を検証していく必要がありＢＤプレーヤの性能によってはアプリケーション実行時のパフォーマンスが落ちてしまう可能性がある。したがって、本実施の形態における署名には第２の実施の形態で図３７を用いて説明したＲｅｓｏｕｒｃｅ Ｆｉｌｅを応用する。具体的には、アプリケーションを構成するファイルのファイル名一覧を記述しているＲｅｓｏｕｒｃｅ Ｆｉｌｅに各ファイルのハッシュ値をあわせて記述し、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに対してのみ署名することで署名の対象をＲｅｓｏｕｒｃｅ Ｆｉｌｅ１つに限定する。ここで、ハッシュ値とは任意の長さのデータを一方向関数に入力して得られた固定長のデータのことであり、もとのファイルからハッシュ値を計算することは容易であるがハッシュ値から元のファイルを類することは困難であるという特徴と、入力されるデータが少し異なるだけでも得られるハッシュ値が変化するという特徴とをもつ。一方向関数としてはＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）やＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）などがある。
【０２０４】
図４０に本実施の形態よるアプリケーション認証機構を導入した場合のＲｅｓｏｕｒｃｅＦｉｌｅの例を示す。図４０に示すように、アプリケーションを構成するファイル名をリストアップした＜ｔｏｐｐａｇｅ＞要素＜ｌｉｎｋｆｉｌｅ＞要素に、各々のファイルのハッシュ値を記述するための属性値として、ＳＨＡ−１の計算結果を記述する“ｓｈａ
−ｄｉｇｅｓｔ”とＭＤ５の計算結果を記述する“ｍｄ５−ｄｉｇｅｓｔ”を追加してい
る。各要素は“ｓｈａ−ｄｉｇｅｓｔ”“ｍｄ５−ｄｉｇｅｓｔ”のどちらか一方、また
は両方を持つものとする。
【０２０５】
また、図４０に示すＲｅｓｏｕｒｃｅ Ｆｉｌｅは新たに＜Ｓｉｇｎｉｔｕｒｅ＞要素が追加されており、当該Ｒｅｓｒｏｕｒｃｅ Ｆｉｌｅへの署名データのファイル名がＵＲＩ形式で＜ｓｉｇｎｉｔｕｒｅ＞要素のｓｒｃ属性として記述されている。また、署名データの形式が＜ｓｉｇｎｉｔｕｒｅ＞要素のｓｉｇ−ｔｙｐｅ属性として記述されている。ここでＲｅｓｏｕｒｃｅ Ｆｉｌｅに署名後にＲｅｓｏｕｒｃｅ Ｆｉｌｅに署名データのファイル名を記述してしまうとＲｅｓｏｕｒｃｅ Ｆｉｌｅのデータが変更されることになり作成済みの署名データ自体も無効になってしまうため、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記述する署名データのデータ名は署名データ作成前に決定しておく必要がある。署名データのファイル名は、各アプリケーション毎に明示的に一意に決められるようにしてもよい。例えばＴｏｐｐａｇｅと同一ディレクトリにＴｏｐｐａｇｅの同一のファイルボディを持ち、拡張子として“．ｒｓａ”を持つものとして定義してもよい。これによりアプリケーションを作成完了しｔｏｐｐａｇｅの名前が決まった時点で署名データの名前は一意に決まっているため、署名データを作成する前であってもＲｅｓｏｕｒｃｅ Ｆｉｌｅを作成可能であり署名データ作成後でもＲｅｓｏｕｒｃｅ Ｆｉｌｅのデータは変化しない。
【０２０６】
また、署名データの形式としては、ＲＳＡ社が定義したＰＫＣＳ＃７（Ｐｕｂｌｉｃ−Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄｓ ＃７）などがある。ＰＫＣＳ＃７形式によるＲｅｓｏｕｒｃｅ Ｆｉｌｅへの署名データの例を図４１に示す。図４１に示すように、ＰＫＣＳ＃７によるＲｅｓｏｕｒｃｅ Ｆｉｌｅの署名は、Ｖｅｒｓｉｏｎ情報とアルゴリズム情報に加え、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値と、スタジオの公開鍵証明書、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値に対して、前記スタジオの公開鍵証明書を用いて署名した結果とが含まれる。
【０２０７】
以下、図４２を用いて、本実施の形態によるアプリケーションの妥当性検証方法について述べる。
【０２０８】
まず、プレーヤにＢＤ−ＲＯＭ Ｄｉｓｃが挿入されて、ＩｎｄｅｘＴａｂｌｅの先頭が自動選択されたりユーザが選択するなどして、ＩｎｄｅｘＴａｂｌｅで定義された任意タイトルが開始されると（ステップＳ８０１）、プレーヤは当該タイトルが定義されたＩｎｄｅｘＴａｂｌｅを参照し、当該タイトルのＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込んで当該タイトル用のアプリケーション情報を取得する（ステップＳ８０２）。Ｒｅｓｏｕｒｃｅ Ｆｉｌｅは例として図４０を用いて前述した形式をとるものとする。次にＲｅｓｏｕｒｃｅ Ｆｉｌｅ中の＜ｓｉｇｎｉｔｕｒｅ＞要素を参照して署名データを読み込む（ステップＳ８０３）。署名データは例として図４１を用いて前述した形式をとるものとし、署名の対象となるＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値と、その署名、署名に用いたスタジオの公開鍵証明書を含む。次にプレーヤは署名データに含まれるスタジオの公開鍵証明書を取り出す。この公開鍵証明書は一般的な公開鍵証明書であり、スタジオの公開鍵と、その公開鍵に対する認証局による署名、認証局による署名を照合するために用いる認証局の公開鍵証明書のチェーンが含まれる。プレーヤは取り出したスタジオの公開鍵証明書からスタジオの公開鍵を取り出し（ステップＳ８０４）、署名データから取り出したＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値に対する署名をステップＳ８０４で取り出した公開鍵を用いて復号化する（ステップＳ８０５）。次に、署名データからＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を取り出して一方向関数に入力してハッシュ値を計算する（ステップＳ８０６）。次に、ステップＳ８０５で復号化して得た復号化データと、ステップＳ８０６で計算して得たハッシュ値とを比較する（ステップＳ８０７）。復号化データとハッシュ値が等しい場合は、署名データが正しく、またＲｅｓｏｕｒｃｅ Ｆｉｌｅが偽造または改竄されていないことが確認されたこととなり、ステップＳ８０８に進む。復号化データとハッシュ値が等しくない場合は、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅか署名データが改竄または偽造されたことが考えられ、ステップＳ８１１に進む。次にステップＳ８０８において、署名データに含まれるスタジオの公開鍵証明書の妥当性を検証していく。スタジオの公開鍵証明書にはスタジオの公開鍵と公開鍵に対する認証局による署名と署名した認証局の公開鍵証明書が含まれており、スタジオの公開鍵証明書の中に含まれる公開鍵の署名の妥当性をスタジオの公開鍵証明書の中に含まれる認証局の公開鍵証明書を用いて確認（図４２のステップＳ８０４からステップＳ８０７までと同様の手順）する。署名した認証局の公開鍵証明書にもさらに当該認証局の公開鍵を署名した親となる認証局の公開鍵証明書が含まれており、チェーン上になっている。これらの認証局の公開鍵証明書のチェーンを先ほどと同様の手順で妥当性を確認していくと最終的にはルートとなる認証局の公開鍵証明書が得られる。ルート認証局の公開鍵証明書が正規のものであるかどうかの確認方法としては、プレーヤにルート認証局の公開鍵証明書を持たせそれと比較する方法でもよいし、ＢＤ−ＲＯＭに記録しておいてそれと比較する方法でも良い。
【０２０９】
最終的に得られたルート認証局の公開鍵証明書が正規のものであれば最終的にスタジオの公開鍵証明書が妥当であることが確認され（ステップＳ８０９）、ステップＳ８１０に進み、最終的に当該タイトル用のアプリケーションの妥当性が検証される（ステップＳ８１０）。スタジオの公開鍵証明書が妥当でなければステップＳ８１１に進み、アプリケーションが偽造または改竄されている可能性があることを検出する（ステップＳ８１０）。
【０２１０】
アプリケーションが偽造または改竄されている可能性がある場合、当該アプリケーションの実行を拒否しても良いし、プレーヤや保護すべきコンテンツへの影響がない最小限の機能のみ実行できるように制限してアプリケーションを実行しても良い。また、アプリケーション構成ファイル以外のＢＤ−ＲＯＭへのアクセスを拒否したり制限したりしても良いし、プレーヤが備えるＨＤＤやフラッシュメモリなどのローカルストレージへのアクセスを拒否したり制限したりしてもよい。また、妥当性が検証されたアプリケーションに関しても、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅの＜ａｐｐｌｉｃａｔｉｏｎ＞要素のｎａｍｅ属性にてアプリケーションの名前が定義されているが、そのアプリケーションに割り当てられたローカルストレージ領域にのみアクセスを許可し、それ以外の名前を持つアプリケーションのローカルストレージ領域へのアクセスは拒否する仕組みを取っても良い。
【０２１１】
なお、本実施の形態ではＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を直接署名データに含ませて署名しているがあくまでも例であり、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅからリンクを張った別の署名用ファイルを用意し、そのファイルにＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値とその他安全性を高めるためのデータ（例えばＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述したアプリケーションを構成する各ファイルのハッシュ値をさらに一方向関数に通して得られたハッシュ値の一覧など）を用意し、それに署名する仕組みをとってもよい。
【０２１２】
以上、アプリケーションの妥当性検証方法について図４２を用いて述べたが、実際にアプリケーションを実行する際はさらにアプリケーションを構成する各ファイルについて図４３に示すようにアプリケーションファイルの妥当性を検証する必要がある。
【０２１３】
以下、図４３を用いて本実施の形態におけるアプリケーションファイルの妥当性検証方法について述べる。
【０２１４】
まずアプリケーションの妥当性検証が完了すると（ステップＳ９０１）、アプリケーションに必要なファイルを読み込む（ステップＳ９０２）。ここでアプリケーションを構成するファイルは前述したように、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ中に＜ｔｏｐｐａｇｅ＞要素や＜ｌｉｎｋｆｉｌｅ＞要素にて記述されている。次にステップＳ９０２で読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているかどうかを確認する（ステップＳ９０３）。これは、例えばＴｏｐｐａｇｅからリンクを張られて読み込まれたファイルが、スタジオの想定したものであるかどうかを確認するためのものであり、Ｔｏｐｐａｇｅの改竄がなければ読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているはずである。読み込んだファイルのファイル名がＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載されている場合（ステップＳ９０４のｙｅｓ）はステップＳ９０５に進み、記載されていなければ（ステップＳ９０４のｎｏ）当該ファイルへのリンクを張ったファイルが改竄されている可能性がありステップＳ９０９に進む。次にステップＳ９０５において、ステップＳ９０２にて読み込んだファイルのハッシュ値を計算する。このとき、＜ｔｏｐｐａｇｅ＞＜ｌｉｎｋｆｉｌｅ＞要素においてｓｈａ−ｄｉｇｅｓｔ属性が指定されている場合はＳＨＡ−１にてハッシュ値を計算し、ｍｄ５−ｄｉｇｅｓｔ属性が指定されている場合はＭＤ５にてハッシュ値を計算し、二つとも指定されている場合はＳＨＡ−１とＭＤ５の二つのハッシュ値を計算するものとする。次に、ステップＳ９０５において計算したハッシュ値と、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値とを比較する（ステップＳ９０６）。ここでステップＳ９０５で計算したハッシュ値が、ＳＨＡ−１にて計算したハッシュ値である場合は、ｓｈａ−ｄｉｇｅｓｔ属性にて指定された値と比較し、ＭＤ５にて計算したハッシュ値である場合はｍｄ５−ｄｉｇｅｓｔ属性にて指定された値と比較する。ＳＨＡ−１とＭＤ５の双方のハッシュ値を計算した場合はその両方をそれぞれ比較する。ステップＳ９０５で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値が等しければ（ステップＳ９０７のｙｅｓ）、読み込まれたファイルは改竄または偽造されていないファイルであることが確認されたことになる（ステップＳ９０８）。一方、ステップＳ９０５で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記載された当該ファイルのハッシュ値が等しくなければ（ステップＳ９０７のｎｏ）、読み込まれたファイルは偽造、または改竄された可能性があることになる（ステップＳ９０９）。
【０２１５】
なお、アプリケーションファイルの妥当性検証は、プレーヤがＲｅｓｏｕｒｃｅ Ｆｉｌｅを読み込んでアプリケーションの妥当性検証が完了した直後に、Ｒｅｓｏｕｒｃｅ Ｆｉｌｅに記載されているアプリケーションを構成する全てのファイルに対して行っても良いし、アプリケーションを実行するにあたって必要になったファイルをその都度検証していく方法でも良い。この場合、前記アプリケーションの妥当性検証が完了した後は、Ｒｅｓｒｏｕｃｅ Ｆｉｌｅ中の＜ｔｏｐｐａｇｅ＞要素で記述されたＴｏｐｐａｇｅのみに対してアプリケーションファイルの妥当性検証が行われ、以降、Ｔｏｐｐａｇｅからリンクを張られるなどしてアプリケーションを実行する上で必要となったファイルに対して逐次妥当性の検証が行われる。
【０２１６】
また、アプリケーション及びその構成ファイルの妥当性を検証出来なかった場合、単にアプリケーションの実行を禁止するだけでなく、当該アプリケーションが記録されたＢＤ−ＲＯＭ Ｄｉｓｃ自体の実行を禁止しても良い。そのほかにも、アプリケーション及びその構成ファイルの妥当性を検証出来なかった場合に、システムに悪影響を及ぼしかねない機能の実行や保護すべきコンテンツへのアクセスを禁止し、実行させるという対策をとっても良い。
【０２１７】
（アプリケーションの実行権限制御）
以上、アプリケーションの妥当性検証方法と、アプリケーションを構成するファイルの妥当性検証方法について本実施の形態を述べたが、さらに妥当性を検証したアプリケーションに対して実行できる権限を必要な範囲に限定することで、プレーヤのシステムやコンテンツをより安全に保つことができる。
【０２１８】
例えば前述したようにアプリケーションの妥当性を検証出来なかったアプリケーションには最小限の機能実行権限のみを割り当て、妥当性を検証したアプリケーションに関しても、あらかじめ規定された必要な機能のみ実行でき、かつ規定された必要なデータ領域にのみデータを読み書きできるようにすることで、例えば想定外の動作による不具合などを防止でき、プレーヤやコンテンツをより安全に保つことができる。
【０２１９】
そこで、本実施の形態ではアプリケーションの実行権限を制御する仕組みをさらに提供する。アプリケーション作成時にアプリケーションが実行できる機能やアクセスできるデータ領域を記述したＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを用意してアプリケーションに添付する。プレーヤはアプリケーションの妥当性検証を実施した後、このＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅに基づいてアプリケーションの実行権限を設定した上でアプリケーションを実行するものとする。
【０２２０】
以下、本実施の形態におけるアプリケーションの実行権限制御の具体例について説明する。
【０２２１】
まず図４４に示すように、プレーヤがアプリケーションの実行する際に当該アプリケーションのＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを一意に読み出せるようＲｅｓｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｒｍｉｓｓｉｏｎ＞要素を設けＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名を記述するものとする。また、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの偽造、改竄を防ぐため、アプリケーションの構成ファイルと同じくそのハッシュ値をＲｅｓｒｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｒｍｉｓｓｉｏｎ＞要素のｓｈａ−ｄｉｇｅｓｔ属性またはｍｄ５−ｄｉｇｅｓｔ属性（または双方）として記述するものとする。このようにＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値をＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述することで前述したアプリケーション構成ファイルの妥当性検証と同様の手順で、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証を行うことができる。
【０２２２】
ここでＰｅｒｍｉｓｓｉｏｎ ｆｉｌｅはテキスト形式やＸＭＬなど任意のフォーマットで記述されるものとし、プレーヤが備える機能や関数に対して当該アプリケーションが実行できるか否かや、実行するために必要な条件などが記載されるものとする。また必要に応じて、当該アプリケーションがアクセスできるＤｉｓｃ領域やローカルストレージ領域に関して例えばＵＲＩ形式で記述され、それぞれの領域に対して、データを読み込めるか否か、書き込めるのか否か、実行できるか否かといった条件が記述されるものとする。またプレーヤがネットワーク通信機能を持つ場合、必要に応じて、当該アプリケーションがネットワークアクセス可能なＵＲＩを記述しアプリケーションが接続可能なサーバを限定するものとする。
【０２２３】
なお、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名は各アプリケーション毎に明示的に決められるようにしてもよい。例えばアプリケーションのＴｏｐｐａｇｅと同一ディレクトリにＴｏｐｐａｇｅの同一のファイルボディを持ち、拡張子として“．ｐｅｒｍ”を
持つものとして定義してもよい。
【０２２４】
以下、図４５を用いてＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証とアプリケーションの権限設定のフローチャートを説明する。
【０２２５】
まずアプリケーションの妥当性検証が完了すると（ステップＳ１００１）、プレーヤはＲｅｓｏｕｒｃｅ Ｆｉｌｅの＜ｐｅｒｍｉｓｓｉｏｎ＞要素を参照してＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを読み込む（ステップＳ１００２）。次にステップＳ１００２で読み込んだＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを一方向関数に通し、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１００３）。このとき、＜ｐｅｒｍｉｓｓｉｏｎ＞要素にｓｈａ−ｄｉｇｅｓｔ属性が指定されている場合はＳＨＡ−１を用いてハッシュ値を計算し、ｍｄ５−ｄｉｇｅｓｔ属性が指定されている場合はＭＤ５を用いてハッシュ値を計算し、二つとも指定されている場合はＳＨＡ−１とＭＤ５の二つのハッシュ値を計算する。次に、ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに＜ｐｅｍｉｓｓｉｏｎ＞要素のｓｈａ−ｄｉｇｅｓｔ属性・ｍｄ５−ｄｉｇｅｓｔ属性で記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値とを比較する（ステップＳ１００４）。ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値が等しければ（ステップＳ１００５のｙｅｓ）、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅは改竄または偽造されていないことが確認されたことになり、ステップＳ１００６に進む。一方、ステップＳ１００３で計算したハッシュ値とＲｅｓｏｕｒｃｅ Ｆｉｌｅに記述されたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値が等しくなければ（ステップＳ１００５のｎｏ）、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅは偽造、または改竄された可能性があることになり、アプリケーションの実行を禁止したり、最小限の権限を与えてアプリケーションを実行する（ステップＳ１００８）。ステップＳ１００６では、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの記述を解釈し、プレーヤに当該アプリケーションの権限を設定する（ステップＳ１００６）。以上の処理により当該アプリケーションが実行できる権限を設定するとプレーヤはアプリケーションを実行する（ステップＳ１００７）。
【０２２６】
なお、Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを用いたアプリケーションの権限設定を行う場合、図４２を用いて述べたアプリケーションの妥当性検証の完了後に、図４５で述べたＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの妥当性検証とアプリケーションの権限設定を行ってアプリケーションの実行に移ると、図４３を用いて述べたように、アプリケーションが使用するファイルの妥当性検証を行うこととなる。
【０２２７】
（アプリケーションの作成手順）
次に、スタジオにおいてアプリケーションをオーサリングしたあと、アプリケーションの認証および権限制御に必要な情報を付加してＢＤ−ＲＯＭに記録するまでの手順について図４６を用いて説明する。
【０２２８】
まずスタジオにてＸＨＴＭＬおよびスクリプトによるアプリケーションのオーサリングが完了すると（ステップＳ１１０１）、この時点で、アプリケーションのＴｏｐｐａｇｅとそれ以外のアプリケーションを構成するファイルの名前が決定され、また各ファイルのディレクトリ構成も決定する。次に当該アプリケーションに最適かつ必要な実行権限を記述したＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅを作成する（ステップＳ１１０２）。次にアプリケーションを構成する各ファイルとＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１１０３）。次にＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのファイル名とアーカイブファイルのファイル名、署名データのファイル名と配置位置を決定する（ステップＳ１１０４）。この際、それぞれ任意にファイル名を決定しても良いし、アプリケーション毎に一意に決定される固有の値としても良い。例えばそれぞれのファイルの配置位置を当該アプリケーションのＴｏｐｐａｇｅと同一ディレクトリとし、さらにファイルボディをＴｏｐｐａｇｅのファイルボディと同一としてそれぞれの拡張子をＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅであれば“．ｐｅｒｍ”、アーカイブファイルであれば“．ｂｄｉ”、署名
データであれば“．ｒｓａ”としてもよい。以上までの処理で得た情報を元に当該アプリ
ケーションのＲｅｓｏｕｒｃｅ Ｆｉｌｅを作成する（ステップＳ１１０５）。次に、ステップＳ１１０５にて作成したＲｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値を計算する（ステップＳ１１０６）。次に以上までの処理で得た情報を元に署名データを作成する（ステップＳ１１０７）。次に各ファイルの構成ファイルとＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ、署名データを各ファイルのディレクトリ構成を保ったままファイルを一纏めにするアーカイブファイルにする（ステップＳ１１０８）。アーカイブファイルの例としてはＭＩＭＥ形式やＴａｒ形式や圧縮ファイル形式であるＺｉｐ形式やＬＺＨ形式、ＣＡＢ形式がある。圧縮形式を採用することでＢＤ−ＲＯＭに記録するデータ量が減り、また読込にかかる時間を短縮できる利点があるが、ＭＩＭＥ形式やＴａｒ形式に比べてファイルを展開する時間がかかるという欠点がある。最後に、ステップＳ１１０５で作成したＲｅｓｏｕｒｃｅ ＦｉｌｅとステップＳ１１０８で作成したアーカイブファイルとをＢＤ−ＲＯＭの所定の位置に記録する（ステップＳ１１０９）。
【０２２９】
なお、本実施の形態にて述べたアプリケーションの実行権限制御の仕組みを利用しない場合はステップＳ１１０２におけるＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅの作成などＰｅｒｍｉｓｓｉｏｎ Ｆｉｌｅに関する処理は実施しない。
【産業上の利用可能性】
【０２３０】
本発明を利用することにより、映像データとＸＭＬおよびスクリプトによるＡＶ再生制御を導入することが可能となる。特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用される可能性をもつ。
【図面の簡単な説明】
【０２３１】
【図１】ＤＶＤの構成図
【図２】ハイライトの構成図
【図３】ＤＶＤでの多重化の例を示す図
【図４】ＢＤ−ＲＯＭのデータ階層図
【図５】ＢＤ−ＲＯＭ上の論理空間の構成図
【図６】ＢＤ−ＲＯＭプレーヤの概要ブロック図
【図７】ＢＤ−ＲＯＭプレーヤの構成ブロック図
【図８】ＢＤ−ＲＯＭのアプリケーション空間の説明図
【図９】ＭＰＥＧストリーム（ＶＯＢ）の構成図
【図１０】パックの構成図
【図１１】ＡＶストリームとプレーヤ構成の関係を説明する図
【図１２】トラックバッファへのＡＶデータ連続供給モデル図
【図１３】ＶＯＢ情報ファイル構成図
【図１４】タイムマップの説明図
【図１５】タイムマップを使ったアドレス情報取得方法説明図
【図１６】プレイリストファイルの構成図
【図１７】プレイリストに対応するプログラムファイルの構成図
【図１８】ＢＤディスク全体管理情報ファイルの構成図
【図１９】グローバルイベントハンドラを記録するファイルの構成図
【図２０】タイムイベントの例を説明する図
【図２１】ユーザイベントの例を説明する図
【図２２】グローバルイベントハンドラの例を説明する図
【図２３】仮想マシンの構成図
【図２４】プレーヤ変数テーブルの図
【図２５】イベントハンドラ（タイムイベント）の例を示す図
【図２６】イベントハンドラ（ユーザイベント）の例を示す図
【図２７】プレーヤの基本処理のフローチャート
【図２８】プレイリスト再生処理のフローチャート
【図２９】イベント処理のフローチャート
【図３０】字幕処理のフローチャート
【図３１】モジュール構成や制御の流れを説明する図
【図３２】Ｉｎｄｅｘ ＴａｂｌｅとＸＨＴＭＬファイルの関係を説明する図
【図３３】ボタンが表示されるＸＨＴＭＬファイルの例
【図３４】データのライフサイクルを説明する説明図
【図３５】データのライフサイクルを説明するタイミングチャート
【図３６】データを１つにまとめる方法を説明する図
【図３７】Ｒｅｓｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図３８】偽造・改竄されたアプリケーションについて説明する図
【図３９】アプリケーション認証の概要を説明する図
【図４０】アプリケーション認証機能を備えたＲｅｓｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図４１】署名データの構成図
【図４２】アプリケーションの妥当性検証処理のフローチャート
【図４３】アプリケーション構成ファイルの妥当性検証処理のフローチャート
【図４４】実行権限制御機能を備えたＲｅｓｒｏｕｒｃｅ Ｆｉｌｅの例を示す図
【図４５】アプリケーションの実行権限制御処理のフローチャート
【図４６】作成したアプリケーションをＤｉｓｃに記録するまでのフローチャート
【符号の説明】
【０２３２】
２０１ ＢＤディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０１ プログラム記録メモリ
３０２ プログラムプロセッサ
３０３ ＵＯＰマネージャ
３０４ 管理情報記録メモリ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１４ イメージプレーン
３１５ ビデオプレーン
３１６ 合成処理部
３１７ ドライブコントローラ
Ｓ１０１ ディスク挿入ステップ
Ｓ１０２ ＢＤ．ＩＮＦＯ読み込みステップ
Ｓ１０３ ＢＤ．ＰＲＯＧ読み込みステップ
Ｓ１０４ ファーストイベント生成ステップ
Ｓ１０５ イベントハンドラ実行ステップ
Ｓ２０１ ＵＯＰ受付ステップ
Ｓ２０２ ＵＯＰイベント生成ステップ
Ｓ２０３ メニューコール判定ステップ
Ｓ２０４ イベント生成ステップ
Ｓ２０５ イベントハンドラ実行ステップ
Ｓ３０１ プレイリスト再生開始ステップ
Ｓ３０２ プレイリスト情報（ＸＸＸ．ＰＬ）読み込みステップ
Ｓ３０３ プレイリストプログラム（ＸＸＸ．ＰＲＯＧ）読み込みステップ
Ｓ３０４ セル再生開始ステップ
Ｓ３０５ ＡＶ再生開始ステップ
Ｓ４０１ ＡＶ再生開始ステップ
Ｓ４０２ ＶＯＢ情報（ＹＹＹ．ＶＯＢＩ）読み込みステップ
Ｓ４０３ ＶＯＢ（ＹＹＹ．ＶＯＢ）読み込みステップ
Ｓ４０４ ＶＯＢ再生開始ステップ
Ｓ４０５ ＶＯＢ再生終了ステップ
Ｓ４０６ 次セル存在判定ステップ
Ｓ５０１ プレイリスト再生開始ステップ
Ｓ５０２ プレイリスト再生終了判定ステップ
Ｓ５０３ タイムイベント時刻判定ステップ
Ｓ５０４ イベント生成ステップ
Ｓ５０５ イベントハンドラ実行ステップ
Ｓ６０１ プレイリスト再生開始ステップ
Ｓ６０２ プレイリスト再生終了判定ステップ
Ｓ６０３ ＵＯＰ受付判定ステップ
Ｓ６０４ ＵＯＰイベント生成ステップ
Ｓ６０５ メニューコール判定ステップ
Ｓ６０６ ユーザーイベント有効期間判定ステップ
Ｓ６０７ イベント生成ステップ
Ｓ６０８ イベントハンドラ実行ステップ
Ｓ７０１ プレイリスト再生開始ステップ
Ｓ７０２ プレイリスト再生終了判定ステップ
Ｓ７０３ 字幕描画開始判定ステップ
Ｓ７０４ 字幕描画ステップ
Ｓ７０５ 字幕表示終了判定ステップ
Ｓ７０６ 字幕消去ステップ
Ｓ８０１ タイトル開始ステップ
Ｓ８０２ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ読込ステップ
Ｓ８０３ 署名データ読込ステップ
Ｓ８０４ 公開鍵抽出ステップ
Ｓ８０５ 署名復号化ステップ
Ｓ８０６ 署名検証用ハッシュ値計算ステップ
Ｓ８０７ 署名判定ステップ
Ｓ８０８ 公開鍵証明書照合ステップ
Ｓ８０９ 公開鍵証明書判定ステップ
Ｓ８１０ アプリケーション妥当性検証完了ステップ
Ｓ８１１ アプリケーションの偽造改竄検出ステップ
Ｓ９０１ アプリケーション妥当性検証完了ステップ
Ｓ９０２ アプリケーション構成ファイル読込ステップ
Ｓ９０３ 構成ファイルの存在確認ステップ
Ｓ９０４ 存在判定ステップ
Ｓ９０５ 構成Ｆｉｌｅハッシュ値計算ステップ
Ｓ９０６ ハッシュ値比較ステップ
Ｓ９０７ ハッシュ値判定ステップ
Ｓ９０８ アプリケーション構成ファイル妥当性検証完了ステップ
Ｓ９０９ アプリケーションデータの偽造改竄検出ステップ
Ｓ１００１ アプリケーション妥当性検証完了ステップ
Ｓ１００２ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ読込ステップ
Ｓ１００３ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅのハッシュ値計算ステップ
Ｓ１００４ ハッシュ値比較ステップ
Ｓ１００５ ハッシュ値判定ステップ
Ｓ１００６ アプリケーション権限設定ステップ
Ｓ１００７ アプリケーション実行ステップ
Ｓ１００８ アプリケーション不正検出ステップ
Ｓ１１０１ アプリケーションオーサリング完了ステップ
Ｓ１１０２ Ｐｅｒｍｉｓｓｉｏｎ Ｆｉｌｅ作成ステップ
Ｓ１１０３ ハッシュ値計算ステップ
Ｓ１１０４ ファイル名決定ステップ
Ｓ１１０５ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ作成ステップ
Ｓ１１０６ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅのハッシュ値計算ステップ
Ｓ１１０７ 署名データ作成ステップ
Ｓ１１０８ アーカイブファイル作成ステップ
Ｓ１１０９ ＢＤ−ＲＯＭ作成ステップ
【特許請求の範囲】
【請求項１】
デジタルストリームを含む１つ以上のタイトルと宣言型言語で記述され１つ以上のファイルから構成される１つ以上のアプリケーションとが記録された情報記録媒体であって、
前記情報記録媒体には、アプリケーションを構成するファイル名一覧を記述したファイルリストと前記ファイルリストへの署名データとがアプリケーション毎に記録され、
前記ファイルリストはアプリケーションを構成する各ファイルのハッシュ値と前記の署名データのファイル名とを含む
ことを特徴とする情報記録媒体。
【請求項２】
前記ファイルリストは対応する前記タイトル毎に関連付けて記録される
ことを特徴とする請求項１記載の情報記録媒体。
【請求項３】
前記ファイルリストには、前記アプリケーションが実行できる機能を記述した実行権限情報のファイル名とそのハッシュ値がさらに記録される
ことを特徴とする請求項１記載の情報記録媒体。
【請求項４】
前記情報記録媒体には、前記ファイルリストにファイル名を記載されたファイル本体をそれぞれ格納したアーカイブファイルが記録されており、
前記ファイルリストには前記アーカイブファイルへのリンクがさらに記載されている
ことを特徴とする請求項１記載の情報記録媒体。
【請求項５】
デジタルストリームを含むタイトルの再生と宣言型言語で記述され１つ以上のファイルから構成されるアプリケーションの実行とを同時に行う再生装置であって、
複数タイトル間の分岐を制御するタイトル制御部と、
１つのタイトルに帰属するデジタルストリームを再生する再生制御部と、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認部と、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込部と、
を備えることを特徴とする再生装置。
【請求項６】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理部をさらに備える請求項５記載の再生装置。
【請求項７】
デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させるプログラムであって、
複数タイトル間の分岐を制御するタイトル制御ステップと、
１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと、
前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、
をコンピュータに実行させることを特徴とするプログラム。
【請求項８】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む請求項７記載のプログラム。
【請求項９】
デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させる再生方法であって、
複数タイトル間の分岐を制御するタイトル制御ステップと、
１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと
前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、
を含むことを特徴とする再生方法。
【請求項１０】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む請求項９記載の再生方法。
【請求項１】
デジタルストリームを含む１つ以上のタイトルと宣言型言語で記述され１つ以上のファイルから構成される１つ以上のアプリケーションとが記録された情報記録媒体であって、
前記情報記録媒体には、アプリケーションを構成するファイル名一覧を記述したファイルリストと前記ファイルリストへの署名データとがアプリケーション毎に記録され、
前記ファイルリストはアプリケーションを構成する各ファイルのハッシュ値と前記の署名データのファイル名とを含む
ことを特徴とする情報記録媒体。
【請求項２】
前記ファイルリストは対応する前記タイトル毎に関連付けて記録される
ことを特徴とする請求項１記載の情報記録媒体。
【請求項３】
前記ファイルリストには、前記アプリケーションが実行できる機能を記述した実行権限情報のファイル名とそのハッシュ値がさらに記録される
ことを特徴とする請求項１記載の情報記録媒体。
【請求項４】
前記情報記録媒体には、前記ファイルリストにファイル名を記載されたファイル本体をそれぞれ格納したアーカイブファイルが記録されており、
前記ファイルリストには前記アーカイブファイルへのリンクがさらに記載されている
ことを特徴とする請求項１記載の情報記録媒体。
【請求項５】
デジタルストリームを含むタイトルの再生と宣言型言語で記述され１つ以上のファイルから構成されるアプリケーションの実行とを同時に行う再生装置であって、
複数タイトル間の分岐を制御するタイトル制御部と、
１つのタイトルに帰属するデジタルストリームを再生する再生制御部と、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認部と、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込部と、
を備えることを特徴とする再生装置。
【請求項６】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理部をさらに備える請求項５記載の再生装置。
【請求項７】
デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させるプログラムであって、
複数タイトル間の分岐を制御するタイトル制御ステップと、
１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと、
前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、
をコンピュータに実行させることを特徴とするプログラム。
【請求項８】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む請求項７記載のプログラム。
【請求項９】
デジタルストリームを含むタイトルの再生とアプリケーションの実行とを同時に実行させる再生方法であって、
複数タイトル間の分岐を制御するタイトル制御ステップと、
１つのタイトルに帰属するデジタルストリームを再生する再生制御ステップと、
タイトルの分岐が発生する度に、分岐先タイトルを生存区間としたアプリケーションを構成するファイルリストと
前記ファイルリストに記載されたファイルリストへの署名とを読み込み前記署名の妥当性を確認する署名確認ステップと、
前記アプリケーションを構成するファイルを読み込む際にファイルのハッシュ値を計算し前記ファイルリストに記載された当該ファイルのハッシュ値と一致するときのみファイルを読み込むファイル読込ステップと、
を含むことを特徴とする再生方法。
【請求項１０】
前記アプリケーションを実行する際に、前記ファイルリストに記載された実行権限情報のハッシュ値を計算し前記ファイルリストに記載された実行権限情報のハッシュ値と一致するときのみ前記実行権限情報に記載された実行権限でアプリケーションを実行する実行権限管理ステップをさらに含む請求項９記載の再生方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【公開番号】特開２００６−２７７３８９（Ｐ２００６−２７７３８９Ａ）
【公開日】平成１８年１０月１２日（２００６．１０．１２）
【国際特許分類】
【出願番号】特願２００５−９６１４８（Ｐ２００５−９６１４８）
【出願日】平成１７年３月２９日（２００５．３．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１８年１０月１２日（２００６．１０．１２）
【国際特許分類】
【出願日】平成１７年３月２９日（２００５．３．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]