JP4906913B2 - 再生装置、システムｌｓｉ、初期化方法 - Google Patents

Description

本発明は、アプリケーション実行技術の技術分野に属する発明である。

アプリケーション実行技術とは、オブジェクト指向言語で記述されたクラス構造体から、そのインスタンスであるクラスオブジェクトを生成して、仮想マシンのプラットフォームに供することにより、オブジェクト指向言語で記述されたアプリケーションを仮想マシンに実行させる技術である。その応用物たる工業製品には、ＢＤ−ＲＯＭの再生機能をもつ再生装置等がある。こうした再生装置は、様々な製造企業（マニファクチャと呼ばれる）によって開発され、毎年のようにモデルチェンジがなされる。ＭＰＵやメモリ量、バスバンド幅、グラフィックアクセラレータなどのハードウェア部品が装置毎に違うので、アプリケーションの処理速度は、再生装置のハードウェア部品の差異によって大きく変化する。

ハードウェアの性能差が装置毎に異なるので、アプリケーションが処理を実行する場合、処理負荷を変化させる必要が生じる。こうした負荷変化の対象には、例えば、ＧＵＩにおけるアニメーション枚数の増減がある。ハードウェアの性能が高い再生装置では、ＧＵＩのためのグラフィクスデータのロードや伸長を高速に行えることができるのでアニメーションの枚数を多くする。逆に、ハードウェアの性能が低い再生装置では、アニメーションの枚数を間引く。そうした枚数の増減を行うことで、ユーザ操作があった場合のレスポンス速度は、ハードウェアの性能差に左右されず、ある一定の水準を保つことができる。かかる負荷変化の実現にあたってアプリケーションは、実行の主体となるハードウェアの性能が、どの程度のものであるか、知得せねばならない。そこで、アプリケーションが起動された際、最初に処理性能を計測するベンチマークテストを実行することが考えられる。

ベンチマークテストを利用した処理負荷の変更方式に関しては、特許文献１に記載された文献公知発明がある。

特開２００２−９９４３０号

ところで、ＢＤ−ＲＯＭの再生装置は、多彩な機能を有しているので、処理負荷の変更にあたっては、多くのハードウェア処理に対するベンチマークテストを実行せねばならない。ここで、アプリケーションの実行に先立ち、多くの機能に対するベンチマークテストを網羅しようとすると、ベンチマークテストの実行に多大な時間がかかり、ユーザがアプリケーションを起動してから、実際の処理を始めるまでの遅延時間、つまり、スターティングディレイが大きくなるという問題がある。

そこで浮かぶのは、ベンチマーク結果の再利用を実現するという考えである。具体的にいうと、再生装置の標準化推進団体によって公式に認定されたアプリケーションにベンチマークテストを実行させて、そうして計測させた値をストレージに書き込み、その結果を、他のアプリケーションに利用させるのである。公式のアプリケーションに、ベンチマークテストを実行させれば、他のアプリケーションは、毎回ベンチマークテストを実行することなく、その数値を再利用することができるので、個々のアプリケーションについてのスターティングディレイは小さくなる。公式のアプリケーションによるベンチマークテストが必要な機能を多く網羅したものならば、きめ細やかな負荷調整を実現することができる。

しかしながらハードウェアとアプリケーションとに介在するファームウェアは、不定期に更新されるものである。ファームウェアとは、ハードウェアの基本的な制御を行なうために機器に組み込まれたソフトウェアである。公式のアプリケーションにて、多くの機能を網羅したベンチマークテストが実行されたとしても、そのベンチマークの結果が、古いファームウェアを対象としたものなら、処理負荷決定の役に立たない。何故なら、機能を実行するにあたっての速度は、ファームウェアにおけるオーバーヘッドに大きく依拠するからである。また、演算アルゴリズムが変更された場合も、再生装置の性能が変化することがある。

このように、アプリケーションの実行に先立ち、多くの機能を網羅したベンチマークを実行しようとすると、本来の処理の実行までに、大きな遅延が生じ、また、公式のアプリケーションにベンチマークを実行させて、結果を再利用しようとすると、ファームウェアの不定期なアップデートが発生した場合、ベンチマークの有効性が損なわれるという問題がある。

本発明の目的は、アプリケーションの起動時における遅延をなくしつつも、多くの機能を網羅したベンチマークの結果を、アプリケーションに利用させることができる、再生装置を提供することである。

上記課題を解決するため、本発明の再生装置は、
記録媒体からデータを読み出すドライブ部、前記読み出したデータに含まれるＡＶデータを再生する再生部、プログラムを実行する処理部と、を具備したハードウェア部と、
前記ハードウェア部を制御するファームウェアプログラムと、
前記処理部が前記ファームウェアプログラムを実行する場合、所定の条件を満足すれば、初期化処理を行う初期化部と
所定の記録領域を有する記録部を備え、
前記ファームウェアプログラムには、ベンチマークスコアが組み込まれており、
前記ベンチマークスコアは、前記ドライブ部によって前記記録媒体から読み出されたベンチマークプログラムを前記処理部により実行したとき、前記実行されるベンチマークプログラムからの命令に従って、前記処理部によって実行されるファームウェアプログラムを介して前記ハードウェア部に所定の処理を行わせた結果であって、前記再生装置の処理能力を示す指標であり、
前記初期部は、前記処理部が前記ファームウェアプログラムを最初に実行する場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定の記録領域に書き込むことにより前記記録領域に書き込んだベンチマークスコアを前記処理部により実行されるアプリケーションプログラムがアクセスできるようにした、
ことを特徴とする。

本発明にかかる再生装置は上述したように構成されているので、アプリケーションのスターティングディレイ対策として、初期化部は、ファームウェアの最初の実行時に、ベンチマークスコアを記録部の所定の記録領域に書き込む。ベンチマークスコアを記録部の所定の記録領域に書き込むための時間遅延が、ファームウェアの最初の実行時に発生するものの、アプリケーションの起動時には発生しない。これによって、アプリケーションを起動するにあたってのスターティングディレイは、発生しえない。
このように、スターティングティレイに対する影響をなくすことで、ユーザ操作に対するレスポンスを高度に維持することができる。

アプリケーションは、自らベンチマークスコアを実行しなくても、再生装置のハードウェア部品に関する必要な情報を記録部の所定の記録領域へ書き込んだベンチマークスコアから取得することができるので、アプリケーションの動作は、ベンチマークスコアテストの実行分だけ短縮されることになる。
ここで、ファームウェアにベンチマークスコアが組み込まれている場合、アプリケーションが、ファームウェアに組み込んだベンチマークスコアへ直接アクセスすることに起因して、ファームウェアの破壊を招く恐れがある。ファームウェア破壊対策として初期化部は、アプリケーションの起動に先立ち、ファームウェアに組込まれたベンチマークスコアを、アプリケーションデータ領域に書き込む。

こうすることで、再生装置におけるファームウェアに組み込んだベンチマークスコアが、直接、アプリケーションによってアクセスされることはない。そのため、ファームウェアが不必要にアクセスされることによるファームウェア（またはファームウェアを格納するメモリなどの記録媒体）の破壊や、ファームウェアの内容が暴露されるという危惧も避けることができる。

また、ベンチマークスコアの書き込みは、ファームウェアが起動される度に行われるのではなく、ファームウェアの最初の実行時に行われることになり、ベンチマークスコア書き込みの頻度は、ファームウェアが起動される度に行なうのに比べかなり低くなる。
また、アプリケーションがこのベンチマークスコアを利用することにより、例えば再生装置上でアニメーションを描画するにあたっての負荷決定を、より緻密なものとすることができる。こうすることで、ハードウェアの性能に適した負荷で、再生装置上で必要な処理を実行することが可能となる。

また、前記ファームウェアプログラムが更新され、前記処理部が前記更新されたファームウェアプログラムを最初に実行する場合、
前記初期化部は前記更新されたファームウェアプログラムに組み込まれたベンチマークスコアを前記記録部における所定の記録領域に書き込むことを特徴とする。
前記再生装置において、ベンチマークスコアは、ファームウェアに組み込まれた態様で、再生装置内に存在するので、ファームウェアの更新にあたって、古いベンチマークスコアが組み込まれた旧バージョンのファームウェアを、新しいベンチマークスコアが組み込まれた新バージョンのファームウェアで上書きすれば、ファームウェアが新しいものに更新された際、ベンチマークスコアは、その更新に伴って、自動的に新旧の交替を果たすことになるばかりか、更新されたファームウェアプログラムを最初に実行するとき、前記記録部における所定の記録領域に書き込まれたベンチマークスコアは新しいものに更新される。

ベンチマークスコアは、ファームウェアが古いものから新しいものに更新された際、ファームウェアと共に、書き換えられる態様で再生装置内に存在するので、ファームウェアの更新が不定期になされたとしても、ファームウェアのバージョンと、ベンチマークスコアのバージョンとが一致しないというバージョンコンフリクションは発生しない。そのため、ベンチマークスコアは、ファームウェアの更新が不定期になされたとしても、その有効性を保つことができる。

また、ベンチマークスコアの書き込みは、ファームウェアが起動される度に行われるのではなく、ユーザがファームウェアを更新した後、更新したファームウェアの最初の実行時に行われることになり、ベンチマークスコア書き込みの頻度は、ファームウェアが起動される度に行なうのに比べかなり低くなる。ベンチマークスコアを記録部の所定の記録領域に書き込むための時間遅延が、更新したファームウェアの最初の実行時に発生するものの、アプリケーションの起動時には発生しない。これによって、アプリケーションを起動するにあたってのスターティングディレイは、発生しえない。このように、スターティングティレイに対する影響をなくすことで、ユーザ操作に対するレスポンスを高度に維持することができる。

また、前記記録領域に書き込んだベンチマークスコアに前記処理部により実行されるアプリケーションプログラムがアクセスする場合、前記アプリケーションプログラムに対応する信用証明書であって、前記アプリケーションプログラムが前記記録領域に書き込んだベンチマークスコアへのアクセス権限に対する情報を含んだ信用証明書の有効性を判断し、前記有効であると判断された信用証明書に含まれる前記ベンチマークスコアへのアクセス権限に対する情報に基づいて、前記アプリケーションプログラムが前記記録領域に書き込んだベンチマークスコアにアクセス可能か否かを判定する判定部を備えることを特徴とする。

このように構成することにより、ベンチマークスコアの読み出しをアプリケーションが要求した際、そのアプリケーションに正当なアクセス権限が付されているかどうかの判定が行なえるようになるばかりか、正当なアクセス権限が付されているかどうかの判定は、デジタル署名の仕組みを利用してなされるので、ＢＤ−Ｊアプリケーション端末の標準モデルに、大きな改変を加えることなく、正当権限が存在するかどうかの判定を実現することができる。

また、前記記録部における所定の記録領域は、前記ベンチマークプログラムを提供した組織を識別する識別子と、前記ベンチマークアプリケーションを識別する識別子とを含んだファイルパス用いて特定されることを特徴とする。
例えば、公式のアプリケーションによるベンチマークが標準化団体による統一基準にてなされる場合、ベンチマークスコアは、信頼性が高い、きわめて有意義な情報となる。しかし信頼性が高いものであればある程、かかるベンチマークスコアの利用が無秩序になされると、当該ベンチマークスコアがＷｅｂページ上で公表されて、その再生装置の信頼性を落としめるための活動、いわゆるネガティブキャンペーンに使用される恐れがある。そうしたネガティブキャンペーン対策にあたっては、上述したような構成を採用することにより、ベンチマークスコアの読み出しは、ベンチマークプログラムを提供した組織から正当なアクセス権限が付されたと認められたもののみに認められるので、例えば、記録媒体の規格化をとりまとめる団体に正式に認定されたものだけに、ベンチマークスコアの読み出しを認めることができる。こうすることでマニファクチャは、安心してベンチマークスコアをファームウェアに組み込み、アプリケーションに利用させることができる。

また、前記ファームウェアプログラムは前記アプリケーションプログラムから前記記録領域に書き込んだベンチマークスコアへのアクセス要求に対し、前記記録領域に書き込んだベンチメークスコアをアクセス要求したアプリケーションプログラムへ返すＩ／Ｏプログラムを含み、
前記アプリケーションプログラムが前記ベンチマークスコアへのファイルパスを指定して、前記ベンチマークスコアへのアクセスを要求したとき、
前記処理部は前記Ｉ／Ｏプログラムを実行し、前記Ｉ／Ｏプログラムは指定されたファイルパスに基づいて特定されるベンチマークスコアを、前記アプリケーションプログラムへ返すように構成したことを特徴とする。

このように構成することにより、アプリケーションがこのベンチマークスコアを利用することにより、例えば再生装置上でアニメーションを描画するにあたっての負荷決定を、より緻密なものとすることができる。こうすることで、ハードウェアの性能に適した負荷で、再生装置上で必要な処理を実行することが可能となるばかりか、アプリケーションがベンチマークスコアへの直接のアクセスを防止することができる。

また、前記第２の記録領域に前記ファームウェアプログラムに組み込んだベンチマークスコアを展開した場合、
前記ベンチマークスコアを本来書き込むべき位置を示す前記記録部におけるファイルパスに関する情報と前記ベンチマークスコアを書き込んだ前記第２の記録領域上の位置に関する情報とを含んだ位置情報を生成し、
前記Ｉ／Ｏプログラムは前記アプリケーションプログラムから指定されたファイルパスを受け取ると、前記位置情報を参照し、前記第２の記録領域に展開したベンチマークスコアを読み込んで前記アプリケーションプログラムへ返すように構成したことを特徴とする。

このように構成することにより、アプリケーションはベンチマークスコアの実際の格納位置を知らなくても、ベンチマークスコアを得ることが可能となる。
また、前記初期化部は、前記記録部における所定のパスによって定められる記録領域に前記ベンチマークスコアが書き込まれているか否かの判定を行い、前記ベンチマークスコアが書き込まれていないと判定した場合に、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定のパスによって定められる記録領域に書き込むことを特徴とする。

このように構成することにより、何等かのアクシデントにより、ベンチマークスコアが上書きされて前記記録部における所定のパスによって定められる記録領域から消失した場合であっても、ファームウェアが起動された際、ベンチマークスコアが消失したかどうかのチェックがなされ、消失時には、ファームウェアから再度、ベンチマークスコアを読み出して前記記録部における所定のパスによって定められる記録領域に書き込むので、ファームウェア起動を契機にして、ベンチマークスコアが消失していないかどうかの確認と、消失した場合の事後策を講じることができる。こうすることで、アプリケーションからベンチマークスコアの読み出しが要求された場合、その要求に即座に応えることができる。

また、前記初期化部は、前記ファームウェアプログラムが更新された場合に、前記更新されたファームウェアプログラムに組み込まれているベンチマークスコアのバージョンと前記アプリケーションデータ領域に存在するベンチマークスコアのバージョンとのバージョン比較を行って、前記更新されたファームウェアプログラムに組み込まれたベンチマークスコアの方が新しいと判定した場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、記記録部における所定のパスによって定められる記録領域に書き込むことを特徴とする。

このように構成することにより、ファームウェアの更新がなされたものの、更新されたファームウェアに組み込まれたベンチマークスコアに変化がない場合（つまりベンチマークスコアのバージョンが更新前と同じ場合）には、前記記録部における所定のパスによって定められる記録領域へベンチマークスコアを書き込むのが抑制されるため、前記記録部における所定のパスによって定められる記録領域が、例えば書き込み回数に上限値がある半導体メモリカード上のメモリ領域であるような場合、半導体メモリカードの長寿命化を図ることができる。

アプリケーションデータ領域に書き込む以外にも、ベンチマークスコアをアプリケーションに供給する手法がある。これは、初期部を以下のように構成することでなされる。
つまり、前記ベンチマークスコアをメモリに展開して、メモリ上のベンチマークスコアを、アプリケーションに利用させる。こうすることで、ローカルストレージにおけるアプリケーションデータ領域へとベンチマークスコアをコピーするために生じる、遅延時間を短縮することができる。また、アプリケーションデータ領域が半導体メモリカードで構成されている場合、半導体メモリカードに対する書き込み回数抑制することができる。

ユーザ宅に設置された再生装置１０２の、利用態様を示す図である。 ＢＤ−ＲＯＭの構成を示した図である。 ＢＤ−ＲＯＭにおける再生制御のレイヤモデルを示した図である。 ローカルストレージにおけるＰｅｒｓｉｓｔｅｎｔ領域の内部構成を示す図である。 （ａ）ＨＤＭＶモードで動的な再生制御を定義することにより、作成される映画作品の一場面を示す図である。 （ｂ）ＢＤ−Ｊモードで動的な再生制御を定義することにより、作成される映画作品である。 図５（ｂ）の合成映像を表示するにあたって、ＢＤ−ＲＯＭにより供給されるアプリケーショが、どのような処理を行うかを示す図である。 本発明にかかる再生装置のハードウェア構成を示す図である。 （ａ）ファームウェアを構成するファイル群を示す図である。 （ｂ）再生装置の制御内容を表したレイヤモデルを示す図である。 再生装置の開発環境を示す図である。 テキストファイルに格納されるベンチマークスコアが、どのようにして得られたものかを解説した図である。 （ａ）ブートローダ２１の内部構成を示す図である。 （ｂ）最初の実行かを示すフラグを示す図である。 （ｃ）システムアプリケーション２８の内部構成を示す図である。 ファームウェア起動部３１がどのような処理を行い、ファームウェア２２が、どのような経路を経てＭＰＵ１６に供されるかを模式的に示す図である。 フラッシュＲＯＭ１８中のベンチマークスコアが、どのような経路を経てベンチマークスコア設定部３４に供されるかを示す図である。 ＣｅｒｔＩＤが“０ｇ１ａ２４ｅｄ”、ＯｒｇａｎｉｚａｔｉｏｎＩＤが“４”、ＡｐｐｌｉｃａｔｉｏｎＩＤが“５”である場合の、ディレクトリ・ファイル構成の一例を示す図である。 アプリケーションデータ領域中のベンチマークスコアが、どのような経路を経てサービスアプリケーションに引き渡されかを示す図である。 （ａ）ファームウェア更新部３２の処理手順を示すフローチャートである。 （ｂ）ファームウェア起動部３１の処理手順を示すフローチャートである。 ベンチマークスコア設定部３４の処理手順を示すフローチャートである。 （ａ）Ｊａｖａ（登録商標）アーカイブファイル３０２の中の構造の一例を示す図である。 （ｂ）デジタル信用証明書のデータ構造の一例を示す。 （ｃ）デジタル信用証明書の具体的な一例を示す図である。 権限の提供がない場合のＳＩＧ−ＢＤ．ＳＦ、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥの相互関係を示す図である。 権限の提供がある場合のＳＩＧ−ＢＤ．ＳＦ、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ、ｂｄ．ＸＸＸＸ．ｐｅｒｍの相互関係を示す図である。 アプリケーションデータ領域に対するアクセス手順を示すフローチャートである。 デジタル信用証明書を用いた権限チェックの処理手順を示すフローチャートである。 第３実施形態におけるベンチマークスコアの行き来を模式的に描いた図である。 ベンチマークアプリケーション２９によるベンチマークテストの処理手順を示すフローチャートである。

（第１実施形態）
以下本発明の実施の形態について、図面を参照しながら説明する。
以降、再生装置の実施形態について説明する。先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図１は、ユーザ宅に設置された再生装置１０２の、利用態様を示す図である。本図に示すように、再生装置１０２は、ＢＤ−ＲＯＭ１００、ＷＷＷサーバ１０１（Ｗｅｂサーバとも言う）、テレビ１０３、リムーバブルメディア１０４と共にユーザによる使用に供される。

ＢＤ−ＲＯＭ１００は、映画作品が記録された記録媒体である。
ＷＷＷサーバ１０１は、映画配給者の公式サイトを運営するサーバ装置であり、ＢＤ−ＲＯＭ１００に記録された映画作品の部分的な置き換えや追加を実現するコンテンツを、インターネット等を介してユーザに供給する。
再生装置１０２は、テレビ１０３と共に、ホームシアターシステムを構築して、ＢＤ−ＲＯＭ１００を再生する。

テレビ１０３は、映画作品の再生映像を表示したり、メニュー等を表示したりすることで、対話的な操作環境をユーザに提供する。
リムーバブルメディア１０４は、再生装置１０２に装填され、映画配給者のＷＷＷサーバ１０１から配信されたコンテンツの受け皿として利用される。そのため、ネットを通じてダウンロードされ、リムーバブルメディア１０４に格納されたコンテンツと、ＢＤ−ＲＯＭ１００に記録されたコンテンツとを組み合わせて、ＢＤ−ＲＯＭ１００のコンテンツを拡張／更新をすることができる。かかるリムーバブルメディア１０４を装填するという目的のため、再生装置１０２には、ＳＤメモリーカード、メモリースティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等のリムーバブルメディア１０４を挿入する挿入口を備える。

以上が本発明に係る再生装置１０２の使用形態についての説明である。続いて本発明に係る再生装置１０２が再生の対象としている、記録媒体について説明する。本発明に係る再生装置１０２により、再生されるのは、光記録媒体であるＢＤ−ＲＯＭ１００である。
図２は、ＢＤ−ＲＯＭ（以降、「ＢＤ」と称する場合もある）の構成を示した図である。本図の第１段目に、ＢＤ−ＲＯＭ１００を示し、第２段目は、ＢＤ−ＲＯＭの内周から外周に向けて螺旋状に形成された記録領域を、横方向に引き伸ばして直線状に描いている。この第２段目に示すように、記録領域は、内周の「リード・イン」と、外周の「リード・アウト」と、「論理アドレス空間」とを有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。

「論理アドレス空間」は、ファイルシステムのための領域管理情報を先頭にして、各種映像データが記録されている。“ファイルシステム”とは、ＵＤＦやＩＳＯ９６６０などのことであり、本実施形態では、Ｅｘｔｅｎｔｉｏｎ２．３形式のファイルシステムを採用する。
本図の第３段目は、第２段目におけるファイルシステムを前提にして構築された、ディレクトリ・ファイル構成を示す。本図に示すように、ＢＤ−ＲＯＭのルートディレクトリ（ＲＯＯＴ）直下には、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥと、ＢＤＭＶディレクトリとが置かれている。

ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ（ディスクルート証明書）は、例えばＸ．５０９の形式で符号されている。Ｘ．５０９の仕様は国際電信電話諮問委員会より発行されており、ＣＣＩＴＴ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．５０９ （１９８８）， “Ｔｈｅ Ｄｉｒｅｃｔｏｒｙ − Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ”に記載されている。本図における引き出し線ｆ１は、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥの用途を示している。この引き出し線に示すように、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥは、証明書固有のＩＤ（ＣｅｒｔＩＤと呼ばれる）を導きだすという用途に用いられる。

ＢＤＭＶディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータが記録されているディレクトリである。ＢＤＭＶディレクトリの配下には、「ＰＬＡＹＬＩＳＴディレクトリ」、「ＣＬＩＰＩＮＦディレクトリ」、「ＳＴＲＥＡＭディレクトリ」、「ＢＤＪＯディレクトリ」、「ＪＡＲディレクトリ」と呼ばれる５つのサブディレクトリが存在し、ＢＤＭＶディレクトリには、ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖの２種類のファイルが配置されている。

ＳＴＲＥＡＭディレクトリは、いわばデジタルストリーム本体となるファイルを格納しているディレクトリであり、拡張子Ｍ２ＴＳが付与されたファイル（ｘｘｘ．ｍ２ｔｓ［“ｘｘｘ”は可変、拡張子”ｍ２ｔｓ”は固定］）が存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル（ｘｘｘ．ｍｐｌｓ［“ｘｘｘ”は可変、拡張子”ｍｐｌｓ”は固定］）が存在する。

ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル（ｘｘｘ．ｃｌｐｉ ［“ｘｘｘ”は可変、拡張子”ｃｌｐｉ”は固定］）が存在する。
ＪＡＲディレクトリには、拡張子ｊａｒが付与されたファイル（ｘｘｘ．ｊａｒ［“ｘｘｘ”は可変、拡張子”ｊａｒ”は固定］）が存在する。
ＢＤＪＯディレクトリには、拡張子ｂｄｊｏが付与されたファイル（ｘｘｘ．ｂｄｊｏ［“ｘｘｘ”は可変、拡張子”ｂｄｊｏ”は固定］）が存在する。

＜拡張子”ｍ２ｔｓ”が付与されたファイル＞
拡張子”ｍ２ｔｓ”が付与されたファイルは、Ｍ Ｐ Ｅ Ｇ − Ｔ Ｓ （ Ｔ ｒ ａ ｎ ｓ ｐ ｏ ｒ ｔ Ｓ ｔ ｒ ｅ ａ ｍ ）形式のデジタルＡＶストリームであり、ビデオストリーム、１つ以上のオーディオストリーム、１つ以上のグラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、グラフィクスストリームは、映画の字幕をそれぞれ示している。

拡張子”ｃｌｐｉ”が付与されたファイルは、デジタルＡＶストリームのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、デジタルＡＶストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐをもっている。
＜拡張子”ｍｐｌｓ”が付与されたファイル＞
拡張子”ｍｐｌｓ”が付与されたファイルは、プレイリスト情報を格納したファイルである。プレイリスト情報は、メインパス情報、サブパス情報、マーク情報を含む。

１）メインパス情報は、ＡＶストリームの再生時間軸のうち、Ｉｎ＿Ｔｉｍｅとなる時点と、Ｏｕｔ＿Ｔｉｍｅとなる時点の組みを１つ以上定義することにより、論理的な再生区間を定義する情報であり、ＡＶストリームに多重化されているエレメンタリストリームのうち、どれの再生を有効とするかを規定するストリーム番号テーブルを有している。このストリーム番号テーブルを有することにより、ＡＶストリーム内のエレメンタリストリームのうち、どれの再生を許可し、どれの再生を許可しないかを規定することができる。

２）マーク情報は、Ｉｎ＿Ｔｉｍｅ、及び、Ｏｕｔ＿Ｔｉｍｅの組みにて指定されたＡＶストリームの一部分のうち、チャプターとなる時点の指定を含む。
３）サブパス情報は、前記ＡＶストリームと同期して再生すべきエレメンタリストリームの指定と、そのエレメンタリストリームの再生時間軸におけるとＩｎ＿Ｔｉｍｅ、及び、Ｏｕｔ＿Ｔｉｍｅの組みを含む。Ｊａｖａ（登録商標）アプリケーションが、このプレイリスト情報を再生するＪＭＦプレーヤインスタンスの生成をＪａｖａ（登録商標）仮想マシンに命じることで、ＡＶ再生を開始させることができる。ＪＭＦプレーヤインスタンスとは、ＪＭＦプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。

ＡＶストリームと、プレイリスト情報との組みは、“タイトル”という再生単位を構成する。ＢＤ−ＲＯＭにおけるＡＶ再生は、このタイトルを一単位としてなされる。

＜拡張子”ｊａｒ”が付与されたファイル＞
拡張子”ｊａｒ”が付与されたファイルは、Ｊａｖａ（登録商標）アーカイブファイルであり、Ｊａｖａ（登録商標）仮想マシンを用いて動的なシナリオ制御を行うＪａｖａ（登録商標）アプリケーションのクラスファイルが存在する。このクラスファイルにて定義されるＪａｖａ（登録商標）アプリケーションは、Ｘｌｅｔインターフェイスを通じて制御されるＪａｖａ（登録商標） Ｘｌｅｔである。Ｘｌｅｔインターフェイスは、”ｌｏａｄｅｄ ｐａｕｓｅ
ｄ”、”ａｃｔｉｖｅ ｄｅｓｔｒｏｙｅｄ”といった４つの状態をもつ。本明細書でい
うアプリケーションとは、こうしてＢＤ−ＲＯＭ等の記録媒体に記録されているクラスファイルについてのインスタンスのことをいう。

＜拡張子“ｂｄｊｏ”が付与されたファイル＞
拡張子“ｂｄｊｏ”が付与されたファイルは、ＢＤ−Ｊオブジェクトを格納したファイルである。ＢＤ−Ｊオブジェクトは、プレイリスト情報により示されるＡＶストリームと、アプリケーションとの関連付けにより、タイトルを定義する情報である。ＢＤ−Ｊオブジェクトは、“アプリケーション管理テーブル”と、そのタイトルにおいて再生可能なプレイリストの一覧を示す。アプリケーション管理テーブル（ＡＭＴ）とは、“アプリケーションシグナリング”を実現するテーブルである。“アプリケーションシグナリング”とは、ＢＤ−ＲＯＭにおける“タイトル”をアプリケーションの生存区間として管理し、アプリケーションの起動及び終了を司る制御をいう。ここで生存区間とは、ＢＤ−ＲＯＭに記録されたコンテンツ全体の時間軸において、仮想マシンのヒープメモリ上でアプリケーションが生存し得る区間を示す。“生存”とは、そのアプリケーションが、ヒープメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。アプリケーション管理テーブルは、アプリケーションの識別子（アプリケーションＩＤ）とそのアプリケーションに属するＪａｖａ（登録商標） アーカイブファイルのＩＤを羅列することでこのタイトルを生存区間とするアプリケーションを示す。つまり、一つのアプリケーションは一つ以上の Ｊａｖａ（登録商標） アーカイブファイルで構成される。このように、ＢＤ−Ｊオブジェクト内のアプリケーション管理テーブルによって、制御が規定されるＪａｖａ（登録商標）アプリケーションを、“ＢＤ−Ｊアプリケーション”とよぶ。

＜ｉｎｄｅｘ．ｂｄｍｖ（ファイル名固定）＞
ｉｎｄｅｘ．ｂｄｍｖ（ファイル名固定）は、ＢＤ−ＲＯＭ全体に関する管理情報であり、再生装置１０２へのディスク挿入後に、ｉｎｄｅｘ．ｂｄｍｖが最初に読み出されることで、再生装置１０２においてディスクが一意に認識される。加えて、ｉｎｄｅｘ．ｂｄｍｖ は、ＢＤ−ＲＯＭにおいて再生可能となる複数のタイトルと、個々のタイトルを規定するＢＤ−Ｊオブジェクトとを対応付けて示すテーブルを含んでいる。引き出し線ｆ２は、ｉｎｄｅｘ．ｂｄｍｖの内部構成をクローズアップして示している。この引出線に示すように映画作品のプロバイダを特定する識別子であるｏｒｇａｎｉｚａｔｉｏｎＩＤ（３２ビット）を持つ。

ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ（ファイル名固定）は、ＨＤＭＶモード（後述）での各タイトル再生で、再生進行を動的に変化させるためのシナリオが記述されたシナリオプログラムが含まれる。
図３は、再生制御のレイヤモデルを示した図である。図３の第１層は、物理層であり、処理対象たるストリーム本体の供給制御である。この第１層に示すように、処理対象たるストリームは、ＢＤ−ＲＯＭだけではなく、Ｂｕｉｌｄ−Ｉｎメディアやリムーバブルメディア、ネットワークといったあらゆる記録媒体、通信媒体を供給源としている。ここでＢｕｉｌｄ−Ｉｎメディアとは、ＨＤＤ（ハードディスクドライブ）など、再生装置１０２に予め組み込まれた記録媒体である。一方、リムーバブルメディアは、ＳＤメモリーカード、メモリースティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等、可搬性がある記録媒体である。これらＢｕｉｌｄ−Ｉｎメディア、リムーバブルメディアは何れも、再生装置１０２がローカルに利用する記録媒体であり、“ローカルストレージ”との総称で呼ばれる。これらローカルストレージ、ネットワークといった供給源に対する制御（ディスクアクセス、カードアクセス、ネットワーク通信）が第１層の制御である。

第２層は、ＡＶストリームのレイアである。第１層で供給されたストリームを、どのような復号化方式を用いて復号するのかを規定しているのがこの第２層である。
第３層（ＢＤ管理データ）は、ストリームの静的なシナリオを規定するレイアである。静的なシナリオとは、ディスク制作者によって予め規定された再生経路情報、ストリーム管理情報であり、これらに基づく再生制御を規定しているのがこの第３層である。

第４層（ＢＤ再生プログラム）は、ストリームにおける動的なシナリオを実現するレイヤである。動的なシナリオは、ＡＶストリームの再生手順、及び、その再生に関する制御手順のうち少なくとも一方を実行するプログラムである。動的なシナリオによる再生制御は、装置に対するユーザ操作に応じて変化するものであり、プログラム的な性質をもつ。ここでの動的な再生制御には、２つのモードがある。２つのモードのうち１つは、ＡＶ機器特有の再生環境で、ＢＤ−ＲＯＭに記録された動画データを再生するモード（ＨＤＭＶモード）であり、もう１つはＢＤ−ＲＯＭに記録された動画データの付加価値を高めるモード（ＢＤ−Ｊモード）である。図３において第４層には、ＨＤＭＶモードとＢＤ−Ｊモードの２つのモードが記述されている。ＨＤＭＶモードは、ＤＶＤライクな再生環境での再生モードであり、再生進行を動的に変化させるためのシナリオが記述されたシナリオプログラムが動作する。もう一つのＢＤ−Ｊモードは、Ｊａｖａ（登録商標）仮想マシンを主体とした再生モードであり、Ｊａｖａ（登録商標）アプリケーションから再生制御を行う。

次に、ローカルストレージの内部構成について説明する。ローカルストレージには、図４に示すようなディレクトリ・ファイル構成を有する、Ｐｅｒｓｉｓｔｅｎｔ領域が存在する。図４は、ローカルストレージにおけるＰｅｒｓｉｓｔｅｎｔ領域の内部構成を示す図である。
かかるＰｅｒｓｉｓｔｅｎｔ領域には、「ディスク追加データ領域」と、「アプリケーションデータ領域」とが存在する。

「ディスク追加データ領域」は、過去に再生装置１０２に装填された各々のＢＤ−ＲＯＭに対応した領域であり、各々のＢＤ−ＲＯＭの格納内容の追加物となるデータが格納される。ディスク追加データ領域は、「ＢＵＤＡディレクトリ」、「ＣｅｒｔＩＤディレクトリ」、「ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ」、「ＤｉｓｃＩＤディレクトリ群」から構成される。

「ＢＵＤＡディレクトリ」は、例えばローカルストレージのルートディレクトリの直下に存在し、追加コンテンツ領域のルートを示すディレクトリで、ディレクトリ名は、８文字以内の固定値（ＢＤ＿ＢＵＤＡ）である。
「ＣｅｒｔＩＤディレクトリ」は例えばＢＤ−ＲＯＭ上のＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥから導き出されるＩＤを名前に持つディレクトリで、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥのＳＨＡ−１ダイジェスト値１６０ビットのうち、先頭３２ビットを１６進表記で表した８文字の名前のディレクトリである。

「ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ」は、例えばＢＤ−ＲＯＭ上のＢＤ管理情報（ｉｎｄｅｘ．ｂｄｍｖ）に記載されている、映画作品のプロバイダを特定する３２ビットの識別子（ＯｒｇａｎｉｚａｔｉｏｎＩＤ）を１６進表記で表した８文字の名前のディレクトリである。
「ＤｉｓｃＩＤディレクトリ群」は、例えば４つのディレクトリからなり、ＢＤ−ＲＯＭを特定する１２８ビットの識別子（ＤｉｓｃＩＤ）を先頭から３２ビットずつ４分割し、それぞれを１６進表記で表した８文字の名前が割り当てられている。

「アプリケーションデータ領域」は、例えばアプリケーションが動作を行うにあたって、必要なデータが格納される領域である。例えばアプリケーションが動作を行う場合のユーザコンフィグレーションやＣｏｏｋｉｅ、ゲームスコア、パスワード、等がこのアプリケーションデータ領域に格納されることになる。
アプリケーションデータ領域におけるディレクトリ構成は、ＡＤＡ（Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ Ａｒｅａ）ディレクトリ、ＣｅｒｔＩＤディレクトリ、ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ、ＡｐｐｌｉｃａｔｉｏｎＩＤディレクトリから構成される。

アプリケーションデータ領域ディレクトリ（ＡＤＡディレクトリ）は、ローカルストレージのルートディレクトリの直下に存在し、アプリケーションデータ領域のルートを示すディレクトリで、ディレクトリ名は、固定値（ＡＤＡ）である。
「ＣｅｒｔＩＤディレクトリ」はＢＤ−ＲＯＭ上のＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥから導き出されるＩＤを名前に持つディレクトリで、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥのＳＨＡ−１ダイジェスト値１６０ビットのうち、先頭３２ビットを１６進表記で表した８文字の名前のディレクトリである。

「ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ」は、ＢＤ−ＲＯＭ上のｉｎｄｅｘ．ｂｄｍｖに記載されている、映画作品のプロバイダを特定する３２ビットの識別子（ＯｒｇａｎｉｚａｔｉｏｎＩＤ）を１６進表記で表した８文字の名前のディレクトリである。
「ＡｐｐｌｉｃａｔｉｏｎＩＤディレクトリ」は、アーカイブファイルのファイル名として採用されている、アプリケーションの識別子（ＡｐｐｌｉｃａｔｉｏｎＩＤ）を１６進表記で表した名前としたディレクトリである。このＡｐｐｌｉｃａｔｉｏｎＩＤディレクトリには、ベンチマークスコアを格納したテキストファイルが存在する。

テキストファイルは、アプリケーションデータ領域上に存在し、このアプリケーションデータ領域は、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスで特定できるので、ＢＤ−Ｊアプリケーションは、ファイルＩ／ＯのためのＡＰＩ（ＪａｖａＩ／Ｏメソッド）を介してベンチマークスコアを読み出すことができる。

図５は、２つのモードの動的な再生制御にて作成される映画作品を示す図である。図５（ａ）は、ＨＤＭＶモードで動的な再生制御を定義することにより、作成される映画作品の一場面を示す図である。ＨＤＭＶモードはＤＶＤ再生装置が解釈可能なコマンドと良く似たコマンドで再生制御を記述することができるので、ＤＶＤと同じような再生制御、つまり、メニューに対する選択により再生が進行するような再生制御を定義することができる。

図５（ｂ）は、ＢＤ−Ｊモードで動的な再生制御を定義することにより、作成される映画作品である。ＢＤ−ＪモードはＪａｖａ（登録商標）仮想マシンが解釈可能なＪａｖａ（登録商標）言語で制御手順を記述することができる。この再生制御がアドベンチャーゲームのＧＵＩを構成するものであるなら、ＢＤ−Ｊモードにあっては、ゲームのスコア（図中のＳＣＯＲＥ：１００００）やインジゲータ（ＬＩＦＥ：３）、ボタン部材（質問する、退室する）と、キャラクタアニメーションと、動画とを組み合わせたような合成映像をユーザに提示することができる。

図６は、図５（ｂ）の合成映像を表示するにあたって、ＢＤ−ＲＯＭにより供給されるアプリケーションが、どのような処理を行うかを示す図である。本図の下段には、図２に示したアーカイブファイルである、ｘｘｘ．ＪＡＲが記述されている。上段は、かかるアーカイブファイルにて定義されるＢＤ−Ｊアプリケーション（以降、システムアプリケーション等を除く、一般のアプリケーションであり、以降、“サービスアプリケーション”と呼ぶ）を示す。このサービスアプリケーションの枠内は、図４におけるキャラクタアニメーションの描画にあたっての処理負荷の変化が、どのようなものであるか模式的に示す。

左枠は、処理負荷を重くする変化であり、猫のキャラクタが、１秒につき２４枚のフルアニメーションで表示されていることがわかる。
右枠は、処理負荷を軽くする変化であり、猫のキャラクタが、１秒につき１２枚のハーフアニメーションで表示されていることがわかる。かかる変化は、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという固定ファイルパスでアクセスできるアプリケーションデータ領域に格納されたベンチマークスコアが、どのような値であるかに応じてなされる。左枠における処理負荷の変化は、例えばベンチマークスコアが、所定の閾値以上であることを要件にしている。右枠における処理負荷の変化は、このベンチマークスコアが、例えば所定の閾値未満であることを要件にしている。このように、ＢＤ−ＲＯＭから供給されるサービスアプリケーションは、アプリケーションデータ領域に存在するベンチマークスコアの大小に応じて、処理負荷を変化させるように作られている。かかる処理負荷の変化によって、ＧＵＩを介してユーザがＢＤ−Ｊアプリケーションに処理を命じてから、その処理が完了するまでのレスポンス時間は、再生装置１０２における描画能力に左右されず、一定の水準を保つことになる。

以上が、ＢＤ−ＲＯＭ１００についての説明である。続いて、再生装置１０２の詳細について、説明する。
図７は、再生装置１０２のハードウェア構成を示す図である。本図に示すように、再生装置１０２は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、プレーンメモリ５、オーディオデコーダ６、エレメンタリバッファ７、プレーンメモリ８、グラフィクスデコーダ９、加算器１０、ネットワークＩ／Ｆ部１１、スイッチ１２、ＨＤドライブ１３、カードドライブ１４、ＲＡＭ１５、ＭＰＵ１６、ユーザインターフェイス１７、フラッシュＲＯＭ１８から構成される。再生装置１０２は、図７に示したハードウェア構成に、Ｊａｖａ（登録商標）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ） Ｐｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅ（ＰＢＰ １．０）と、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ１．０．２）ｆｏｒ ｐａｃｋａｇｅ ｍｅｄｉａ ｔａｒｇｅｔｓとをフル実装することで構成される。

ＢＤ−ＲＯＭドライブ１は、図２に示すような内部構成を有するＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。そして、ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭから読み出したＴＳパケットをリードバッファ２に格納する。
リードバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。このＴＳパケットは、ＭＰＥＧ２−ＴＳ形式のＡＶストリームを構成するものである。

デマルチプレクサ３は、ＢＤ−ＲＯＭ、リムーバブルメディア、Ｂｕｉｌｄ−Ｉｎメディアに記録されているＭＰＥＧ２−ＴＳ形式のＡＶストリームの多重分離を行い、ＧＯＰを構成するビデオフレームと、オーディオフレームとを得てビデオフレームをビデオデコーダ４に出力し、オーディオフレームをオーディオデコーダ６に出力する。グラフィクスストリームはグラフィクスメモリ７に格納する。デマルチプレクサ３による多重分離は、ＴＳパケットをＰＥＳパケットに変換するという変換処理を含む。

ビデオデコーダ４は、デマルチプレクサ３から出力されたビデオフレームを復号して非圧縮形式のピクチャをビデオ用のプレーンメモリ５に書き込む。
プレーンメモリ５は、非圧縮形式のピクチャを格納しておくためのメモリである。
オーディオデコーダ６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。

グラフィクスメモリ７は、ＢＤ−ＲＯＭ、リムーバブルメディア、Ｂｕｉｌｄ−Ｉｎメディアから読み出されたグラフィクスデータや画像ファイルを格納しておくバッファである。

プレーンメモリ８は、一画面分の領域をもったＳＤ−ＲＡＭ等であり、ＨＤＭＶモードとＢＤ−Ｊモードとでメモリアロケーションが変わる。ＨＤＭＶモードにおけるメモリアロケーションとは、横１９２０×縦１０８０の８ビット領域からなる。これは１９２０×１０８０の解像度で、１画素当たり８ビットのインデックス値を格納できるメモリアロケーションである。ＣＬＵＴ（Ｃｏｌｏｒ Ｌｏｏｋｕｐ Ｔａｂｌｅ）を用いてかかるインデックスカラーを変換することにより、プレーンメモリ８に格納されたラスタグラフィクスは、表示に供される。一方、ＢＤ−Ｊモードにおけるメモリアロケーションとは、１９２０×１０８０の３２ビット領域からなる。これは横１９２０画素×縦１０８０画素の解像度で、１画素当たり３２ビットのＲＧＢ値を格納できるメモリアロケーションである。こうした、３２ビットのＲＧＢ値をダイレクトに書き込むことにより、ＢＤ−Ｊアプリケーションは、ＧＵＩのためのグラフィクスを、直接、表示させることができる。

グラフィクスデコーダ９は、グラフィクスメモリ７に格納されたグラフィクスデータや画像ファイルを展開してプレーンメモリ８に書き込む。グラフィクスストリームのデコードにより、各種メニュー、グラフィクスが画面上に現れることになる。
加算器１０は、ビデオ用のプレーンメモリ５に格納された非圧縮形式のピクチャデータに、グラフィクス用のプレーンメモリ８に展開されたグラフィクスを合成して出力する。図５（ｂ）に示した合成画像は、この加算器１０が、プレーンメモリ８内のグラフィクスと、ビデオ用のプレーンメモリ５内のピクチャとを合成することで出力される。

ネットワークＩ／Ｆ部１１は、ネットワーク接続のためのプロトコルスタックを実行するものであり、ネットワーク上のコンピュータが具備しているドライブを、ネットワークドライブ４ａとして、再生装置１０２に認識させる。プロトコルスタックとしては、信頼性が要求されるＢＤ管理データの転送には、ＴＣＰ／ＩＰを使用し、高速性が要求されるＡＶストリームの転送には、ＵＤＰ／ＩＰを使用するのが望ましい。

スイッチ１２は、ＢＤ−ＲＯＭドライブ１、ＨＤドライブ１３、カードドライブ１４から読み出されたファイルを、選択的にＲＡＭ１５に格納する。
ＨＤドライブ１３は、ＢＤ−ＲＯＭにて供給されるクラスファイルと、同等のクラスファイルを格納しておくことができるハードディスクドライブである。
カードドライブ１４は、ＢＤ−ＲＯＭにて供給されるクラスファイルと、同等のクラスファイルが書き込まれたＳＤメモリカード等を、装填することができるドライブ装置である。

ＲＡＭ１５は、ＳｔａｔｉｃＲＡＭ等で構成され、ＭＰＵ１６がデータ処理を行うにあたって、必要なデータが格納される。ＲＡＭ１５には、ファームウェアを常駐しておくためのファームウェア常駐領域が存在する。ファームウェア常駐領域は、ＭＰＵ１６の特権モードでのみ、アクセスが可能であり、通常モードで動作するプログラムは、アクセスすることはできない。これは、ファームウェアの予期せぬ破壊を防ぐためである。

ファームウェア常駐領域以外のその他の領域は、メモリプール管理機能、ヒープエリア管理機能にて管理されている。
メモリプール管理機能とは、空きのメモリ領域を管理し、必要に応じて要求されたメモリサイズをＢＤ−Ｊアプリケーションに与え、使用が終了すると、メモリに蓄積された状態に戻す。ヒープエリア管理機能では、メモリの空き領域にメモリプールを設定し、ＢＤ−Ｊアプリケーションの要求に応じて、必要サイズのメモリを提供する。かかるヒープ管理によって、ＲＡＭ１５上の領域は、“ヒープメモリ”として、利用されることになる。

ＭＰＵ１６は、再生装置１０２の中核を担うものであり、命令メモリやキャッシュからネイティブコードをフェッチする「フェッチ回路」、命令コードをデコードする「デコーダ回路」、デコード結果に従って、レジスタに格納されている保持値に対し、演算を行う「算術演算回路」を必要最低限の構成要素として備える。またＭＰＵ１６は、動作モードとして特権モードを有している。この特権モードで動作することができるプログラムは、ＲＡＭ１５やフラッシュＲＯＭ１８に格納されたファームウェアをアクセスすることができる。

ユーザインターフェイス１７は、リモコンや再生装置１０２のフロントパネルといった入力機器に対してなされたユーザ操作を検知して、通知する。この通知は、これらの入力機器に対応するデバイスドライバ内の割込みハンドラが発生する割込みに従い、ＵＯＰを生成することでなされる。ＵＯＰとは、リモコンやフロントパネルに設けられたキーマトッリクスでキー押下を検知した際、発生するイベント（ＵＯＰイベント）であり、押下されたキーに対応した属性をもつ。具体的には、リモコンやフロントパネルに対応するデバイスドライバの割込みハンドルが、キーマトリックスに対するキーセンスでキー押下を検出した際、そのキー押下に基づき割込み信号を発生することで、ＵＯＰイベントは、生成される。

フラッシュＲＯＭ１８は、ＥＥＰＲＯＭであり、再生装置１０２に予め組み込まれている組み込みプログラムが格納される。こうした組込みプログラムには、例えばブートローダ２１、ファームウェア２２がある。フラッシュＲＯＭ１８はＭＰＵ１６の特権モードでのみ、アクセスが可能であり、通常モードで動作するプログラムは、アクセスすることはできない。これは、ブートローダ２１、ファームウェア２２の予期せぬ破壊を防ぐためである。

以上が、再生装置１０２のハードウェア構成である。続いて、以上のハードウェア構成を前提にしたソフトウェア構成について説明する。
図８（ａ）は、ファームウェア２２を構成するファイル群を示す図である。本図に示すように、ファームウェア２２は、例えば複数の「クラスファイル」、複数の「実行形式ファイル」、複数の「テキストファイル」を含む。

これらのうち、クラスファイル、実行形式ファイルは、ファームウェア２２の構成要素であり、再生装置１０２の制御内容を規定する。図８（ｂ）は、再生装置１０２の制御内容を表したレイヤモデルを示す図である。
本図に示すように、再生装置１０２の制御内容は、ハードウェアの上に、ファームウェア２２が存在するという一般的なものである。このファームウェア２２は、例えば仮想ファイルシステム２３、アクセス制御機構２４、再生エンジン２５、再生制御エンジン２６、クラスローダ７、システムアプリケーシ２８を階層化したものである。

またファームウェア２２は、Persistent領域をアクセスするための必須のソフトウェア要素として、例えばJavaI/Oメソッドを実現するファイルI/Oのプログラムを含む。このI/Oプログラムは、例えばBD-JアプリケーションからのPersistent領域に書き込んだベンチマークスコアへのアクセス要求に対し、Persistent領域に書き込んだベンチメークスコアをアクセス要求したBD-Jアプリケーションへ返す処理を行う。以降、これらの構成要素について説明する。尚、正確には、再生装置１０２のソフトウェア構成として、ＨＤＭＶモードのためのＨＤＭＶモジュールや、ＢＤ−Ｊモード、ＨＤＭＶモードの切り替えのためのモジュールマネージャが存在する。しかしこれらの構成要素は、本願の主眼ではないので説明を省略する。

（仮想ファイルシステム２３）
仮想ファイルシステム２３は、ローカルストレージに格納されたダウンロードコンテンツを、ＢＤ−ＲＯＭにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージに格納されたダウンロードコンテンツは、図２に示したＣｌｉｐ情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はＢＤ−ＲＯＭ及びローカルストレージのどちらに存在するＣｌｉｐ情報であっても、指定できる点で、ＢＤ−ＲＯＭ上のプレイリスト情報と異なる。この指定にあたって、仮想ファイルシステム２３上のプレイリスト情報は、ＢＤ−ＲＯＭやローカルストレージにおけるファイルをフルパスで指定する必要はない。ＢＤ−ＲＯＭ上のファイルシステムやローカルストレージ上のファイルシステムは、仮想的な１つのファイルシステム（仮想ファイルシステム２３）として、認識されるからである。故に、プレイリスト情報は、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる数値を指定することにより、仮想ファイルシステム２３、ＢＤ−ＲＯＭ上のＡＶストリームを指定することができる。仮想ファイルシステム２３を介してローカルストレージの記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージと、ＢＤ−ＲＯＭとを組合せてなるディスクコンテンツは、ＢＤ−ＲＯＭにおけるディスクコンテンツと対等に扱われるので、本願における”ＢＤ−ＲＯＭ”は、ローカルストレージ＋ＢＤ−ＲＯＭの組合せからなる仮想的な記録媒体をも含むことにする。

（アクセス制御機構２４）
アクセス制御機構２４は、正当権限をもったＢＤ−Ｊアプリケーション（Ｓｉｇｎｅｄアプリケーションと呼ばれる）のみがローカルストレージにおけるアプリケーションデータ領域をアクセスできるよう、強制的な制御を行う。そうした強制的な制御によって、有効なデジタル信用証明書をもったＢＤ−Ｊアプリケーションのみが、アプリケーションデータ領域におけるベンチマークスコアをアクセスすることができることになる。

具体的にいうと、ローカルストレージのアプリケーションデータ領域をアクセスするための、固定ファイルパスを用いた読み出しが要求された際、その読み出しを要求したＢＤ−Ｊアプリケーションのデジタル信用証明書に対してアクセス権限のチェックを行う。そして、アクセス権限があると認められれば、固定ファイルパスを用いたファイルアクセスを例えば仮想ファイルシステム２３におけるファイルＩ／ＯのためのＡＰＩ（ＪａｖａＩ／Ｏメソッド））を介して、アプリケーションデータ領域から所望のデータを読み出して、サービスアプリケーションに引き渡す。

（再生エンジン２５）
再生エンジン２５は、ＡＶ再生ファンクションを実行する。再生装置１０２のＡＶ再生ファンクションとは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ Ｃｈａｎｇｅ）といった機能である。ＡＶ再生ファンクションを実現するべく、再生エンジン２５は、バッファ上に読み出されたＡＶストリームのうち、所望に時刻にあたる部分のデコードを行うよう、デコーダを制御する。所望の時刻からのデコードを行わせることにより、ＡＶストリームにおいて、任意の時点での再生を可能することができる。

（再生制御エンジン２６）
再生制御エンジン２６は、プレイリスト情報に対する再生制御ファンクション（ｉ）、再生装置１０２における状態取得／設定ファンクション（ｉｉ）といった諸機能を実行する。プレイリスト情報に対する再生制御ファンクションとは、再生エンジン２５が行うＡＶ再生ファンクションのうち、再生開始や再生停止を、カレントプレイリスト情報及びＣｌｉｐ情報に従って行わせることをいう。これら機能（ｉ）〜（ｉｉ）は、上位層からのＡＰＩコールに応じて実行する。以上の再生エンジン２５と、再生制御エンジンとの組みは、“ＡＶ再生ライブラリ”と呼ばれ、ＡＶ再生専用のライブラリとして再生装置１０２に実装される。

（ＢＤ−Ｊモジュール２７）
ＢＤ−Ｊモジュール２７は、Ｊａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン、コンフィグレーション、プロファイルからなる。これらのうちＪａｖａ（登録商標）仮想マシンは、クラスファイルのインスタンスを構成するバイトコードの解釈実行を行うインタプリタであり、バイトコードをネイティブコードに翻訳してＭＰＵ１６に実行させる。このインタプリタは、ＢＤ−Ｊアプリケーションの実行速度に直接影響を与える重要な部分であり、具体的な実装としては、バイトコードをネイティブコードに変換するＪＩＴコンパイラを備えたインタプリタとして実装することができる。このようなＪＩＴコンパイラの具備により、解釈実行の高速化を図ることができる。また、インタプリタの一部についてはハードウェアを用いて実装することができる。

（システムアプリケーション２８）
システムアプリケーション２８は、クラスファイルにて定義されたシステムプログラムであり、ＲＡＭ１５におけるヒープメモリに配置される。システムアプリケーション２８の類型としては、クラスファイルに格納されたオブジェクト指向言語の構造体をバイトコードに変換し、ヒープメモリ上にロードする「クラスローダ」、「アプリケーションマネージャ」、アプリケーションに出力すべきイベント処理を行う「ユーザイベントマネージャ」、「ベンチマークスコア設定部」などがある。

以上がシステムアプリケーション２８についての説明である。続いて、ベンチマークスコアの詳細について説明する。
＜ベンチマークスコア＞
図８（ａ）におけるテキストファイルは、例えば再生装置１０２に組み込まれたハードウェア及びファームウェア２２に対するベンチマークスコアを格納している。ベンチマークスコアとは再生装置に組み込まれたハードウェア、ファームウェアの性能を示す指標であり、ベンチマークテストとは上述の指標を算出または計測するための試験である。ベンチマークプログラムとはベンチマークテストを行なうためのプログラムである。本実施形態に係る再生装置１０２に対するベンチマークテストは、再生装置１０２を出荷する前に、マニファクチャが再生装置１０２上でベンチマークアプリケーション２９を実行することでなされる。ファームウェア２２に組込まれたテキストファイルは、例えば公式のアプリケーションによるベンチマークテストの結果であり、この結果を“ベンチマークスコア”としてテキストファイルに書き込む。またこのとき、ベンチマークスコアに対するデジタル証明書、ベンチマークスコアを算出するために用いたベンチマークプログラムを発行した組織の組織ＩＤ、ベンチマークプログラムのアプリケーションＩＤを組み込む。

組み込まれたベンチマークスコアは、例えばかかるファームウェア２２を介して、ハードウェアに処理を要求してから、処理が完了して応答が返るまでのターンアラウンド時間であり、ファームウェア２２を最初に実行するとき、アプリケーションデータ領域における固定パスにて格納される。この固定パスは、例えば図１４に示すＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスである。ＣｅｒｔＩＤ、ＯｒｇａｎｉｚａｔｉｏｎＩＤ、ＡｐｐｌｉｃａｔｉｏｎＩＤはそれぞれ、ベンチマークスコアに対するデジタル信用証明書、ベンチマークスコアを算出するために用いたベンチマークプログラムを発行した組織の組織ＩＤ、ベンチマークプログラムのアプリケーションＩＤから特定できる情報である。ベンチマークスコアは、例えば改竄されているかどうかのチェック、上述のデジタル信用証明書の証明書の正当性のチェックを経た上で、固定ファイルパスで特定される。固定ファイルパスは例えば上述のデジタル信用証明書から特定される提供者ルート証明書に対応するルート証明書（例えば再生装置内に保持されている）のＣｅｒｔＩＤ、上述の組織の組織ＩＤ、ベンチマークプログラムのアプリケーションＩＤを組み合わせた固定ファイルパスで特定される。したがって、ファームウェア２２が更新された場合でも、固定ファイルパスは変化しない。また、ベンチマークスコアは、ファームウェア２２が更新されなければ、変化しない。ファームウェア２２が更新されれば、アプリケーションデータ領域には、新たなテスト結果となるベンチマークスコアが書き込まれることになる。

マニファクチャは、再生装置１０２の出荷前に、再生装置１０２にファームウェア２２を組み込んだ状態でベンチマークテストを実行する。その結果となるベンチマークスコアは、ファームウェア２２に組み込まれる。また、ファームウェア２２に組込まれたベンチマークスコアは、アプリケーションデータ領域に書き込まれる。更に、例えばユーザ宅で再生装置１０２がファームウェア２２を更新した場合、更新されたファームウェア２２の最初の実行時において、ファームウェア２２に組み込まれたベンチマークスコアは、アプリケーションデータ領域における意図したロケーションに格納される。この場合、ロケーションとは、図６に示したＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという固定ファイルパスで特定されるアプリケーションデータ領域である。

ベンチマークテストの対象となるファームウェア２２を介したハードウェア処理には、例えば
ａ）ＪＰＥＧ、ＰＮＧ等の圧縮イメージデータの展開、メモリへのロード、オーディオデータのメモリへのローディング、フォントデータのロード、
ｂ）ＡＶ再生、ＡＶストリームの切り替え、字幕、音声などの切り替え、
ｃ）浮動小数点や三角関数などの演算、矩形イメージ描画（α合成あり、なし）、イメージ拡大縮小、多角形描画、スプライト描画、文字列描画など
がある。それら個別の機能実施を同時に複合的に実施した場合の時間も、ベンチマークの対象となる。

これらの処理は、ベンチマークテストの対象として公式に認定されており、識別情報で一意に指示できるようになっている。ベンチマークテストの対象となる処理が、利用可能なＡＰＩメソッドに対応する場合、そのＡＰＩメソッドの関数名を識別情報として用いることができる。
こうした処理を対象としたベンチマークテストの結果、つまり、
１）ＪＰＥＧ、ＰＮＧ等の圧縮イメージデータの展開を要求してから、処理が完了するまでのターンアラウンド時間、
２）メモリへのロードを要求してから、処理が完了するまでのターンアラウンド時間、メモリへのローディング、ロードを要求してから、処理が完了するまでのターンアラウンド時間
３）ＡＶ再生呼び出しから実際の再生にかかるターンアラウンド時間、
４）ＡＶストリームの切り替えを要求してから、処理が完了するまでのターンアラウンド時間、
５）字幕、音声などの切り替えを要求してから、処理が完了するまでのターンアラウンド時間、
６）浮動小数点や三角関数などの演算を要求してから、演算が完了するまでのターンアラウンド時間、
７）矩形イメージ描画を要求してから、処理が完了するまでのターンアラウンド時間、
８）イメージ拡大縮小、多角形描画、スプライト描画、文字列描画などを要求してから、描画が完了するまでのターンアラウンド時間
といったものが、ベンチマークスコアとしてファームウェア２２に組込まれることになる。これら組み込まれたベンチマークテストの結果は、例えば再生装置１０２が図５（ｂ）に示すように、ＢＤ−Ｊモードにおいて、キャラクタアニメーションの表示と、動画再生とを組み合わせたような合成映像をユーザに提示する場合に再生装置１０２にかかる負荷がどの程度なのかを示す指標となり、この指標に応じて例えば図６に示すキャラクタアニメーションの処理負荷を動的に切り替えることが可能となる。

次に、ベンチマークスコアの構成について説明する。
ベンチマークスコアは、例えばベンチマークテストの対象となった処理を識別する識別情報と、ターンアラウンド時間の計測値とを対応付けて構成される。ファームウェアに組込まれたテキストファイルは、例えば処理の識別情報と、ターンアラウンド時間の計測値との組みを羅列したリスト形式になっており、識別情報を用いることで、任意の処理のターンアラウンド時間を得ることができる。

かかる識別情報を、公式に定めておけば、ベンチマークスコアを格納したテキストファイルの読出時において、サービスアプリケーションは、処理識別情報を引数として、テキストファイルの読み出しを要求することができる。こうすることで、テキストファイル内の複数のベンチマークスコアのうち、その引数に対応するものを、サービスアプリケーションに引き渡すことも可能になる。

ターンアラウンド時間としては、４５ＫＨｚの時間精度で表現することが望ましい。何故なら、ＡＶストリームを構成するＰＥＳパケットのそれぞれには、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ ），ＤＴＳ（Ｄｅｃｏｄｅ ＴＩｍｅ Ｓｔａｍｐ）が付与されており、再生装置１０２の内部には、１／４５，０００秒という時間精度で、動作を行うＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）が存在する。そうしたＳＴＣの時間精度で、ベンチマークスコアを作成しておけば、ＡＶストリームの再生処理との同期を緻密に実行することができるからである。尚、プレイリスト情報のＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、この４５ＫＨｚの時間精度で定められているので、サービスアプリケーションが、プレイリスト情報による再生と同期して処理負荷を変化させるのにも都合がよい。

かかるベンチマークスコアは、再生装置１０２の開発環境において、ファームウェア２２が完成した際、マニファクチャによってファームウェア２２に組込まれるものである。ベンチマークスコアが、どのようにして得られたものかを以降、解説してゆく。
図９は、再生装置１０２の開発環境を示す図である。この開発環境において、再生装置１０２は、開発用コンピュータ１０５と、ＬＡＮ接続されている。また、ファームウェア２２には、ベンチマークスコアを除くファームウェア２２、つまり、ファームウェア２２を構成する実行形式ファイル、クラスファイルが記録されている。これらのものが完備しているので、本図の再生装置１０２は、製品としてユーザに供給されるものと同等の性能をもつ。そして、かかる再生装置１０２には、ＬＡＮを介して開発用コンピュータ１０５からベンチマークアプリケーション２９が供給される。

開発用コンピュータ１０５は、ＩＤＥ、ＡＤＫのソフトウェアが実装されており、ＬＡＮを通じたファームウェアの開発環境をユーザに提供する。ＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｎｖｉｒｏｎｍｅｎｔ）とは、システムアプリケーションを構築するためのコンパイラ等から構成される。
ＡＤＫ（Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｌｏｐｍｅｎｔ Ｋｉｔ）とは、ＪＰＤＡ（Ｊａｖａ Ｐｌａｔｆｏｒｍ Ｄｅｂｕｇｇｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）の仕組みを利用することでシステムアプリケーションのデバッグを実現する開発環境である。

再生装置１０２とコンピュータ１０５との送受信は、再生装置１０２とＰＣとを結ぶシリアルポート、Ｓｏｃｋｅｔでなされる。Ｓｏｃｋｅｔは、ＩＥＥＥ８０２．３（Ｅｔｈｅｒｎｅｔ（登録商標）），ＩＰ，ＴＣＰ／ＵＤＰ上に位置するセッション層の通信路であり、システムアプリケーションは、ネットワークモデルとして、ＩＥＥＥ８０２．３（Ｅｔｈｅｒｎｅｔ（登録商標）），ＩＰ，ＴＣＰ／ＵＤＰを採用しているため、無論のこと、かかるＳｏｃｋｅｔをデバッグ時の伝送路に採用することができる。

図１０は、テキストファイルに格納されるベンチマークスコアが、どのようにして得られたものかを解説した図である。本図は、再生装置１０２が出荷される前の、ファームウェア２２作成過程の一例を模式的に示している。
本図は、図８（ｂ）をベースとして作図されており、このベースとなるレイヤモデルと比較して、ＢＤ−Ｊモジュール２７上でベンチマークアプリケーション２９が動作している点、再生装置１０２にコンピュータ１０５が接続されている点が異なる。ベンチマークアプリケーション２９は、例えばBD-ROMドライブ１、HDドライブ１３、カードドライブ１４の何れかから、読み出されて、BD-Jモジュール２７上で動作しているものである。さらに、コンピュータ１０５は、マニファクチャの作業担当者により操作されるものである。

本図におけるＵ字状の矢印は、かかるベンチマークアプリケーション２９がファームウェアを介してハードウェアに対して処理を要求してから、その処理が完了して応答が返るまでの過程を模式的に示している。ベンチマークアプリケーション２９は、ハードウェアが実行しうる様々な機能に対して再生装置１０２の出荷前にかかるターンアラウンド時間の計測を行って、ターンアラウンド時間の計測値を、外部に接続されたコンピュータ１０５にエクスポートする。コンピュータ１０５は、そうしてエクスポートされた計測値をハードディスク上のデータベースに蓄積し、複数の計測値から構成されるテキストファイルを形成してゆく。一通りの機能についてのベンチマークが完了し、計測値の蓄積が完了すれば、そうして得られたテキストファイルを、ファームウェア２２を構成する実行形式ファイル、クラスファイルと一体化してファームウェア２２を得る。

以上のように再生装置１０２のファームウェア２２は、ターンアラウンド時間の計測と、その計測結果であるベンチマークスコアの組込みとがなされた上で、完成する。
ベンチマークスコアを格納したテキストファイルは、ファームウェア２２を構成する実行形式ファイル及びクラスファイルと一体として扱われており、これらのテキストファイル、実行形式ファイル、クラスファイルは、例えば１つにまとめて、ＺＩＰファイル等に格納することができる。ブート時にあたってベンチマークスコアを格納したテキストファイルは、実行形式ファイル及びクラスファイルと共にファームウェア２２からＲＡＭ１５に読み出され、ＲＡＭ１５の常駐領域に配置されて、ＭＰＵ１６におけるメモリ空間にマッピングされることになる。ベンチマークスコアを格納したテキストファイルは、実行形式ファイル及びクラスファイルと一体的になっているので、このようなベンチマークスコアの状態を、“ファームウェア２２に組み込まれている”と呼ぶことにする。

以上が、マニファクチャによるベンチマークの実行についての説明である。
（ファームウェア２２の更新）
続いて、ユーザによるファームウェア２２の更新が、どのように行われるかについて説明する。
新たなファームウェア２２を格納するためのリムーバブルメディアには、例えばＳＤメモリカードやＣＤ−Ｒを利用することができる。

マニファクチャが運営するＷＷＷサーバのＷＷＷサイト、つまりマニファクチャにおける公式のＷＷＷサイトには、再生装置１０２のファームウェア２２について、バグの報告や最新のアップデート状況が告知されている。再生装置１０２が、ネットワーク接続されている場合、こうしたアップデート状況を常時監視しており、もしファームウェア２２アップデートの告知があれば、再生装置１０２は、ネットワークを介して、新たなファームウェア２２を格納したＺＩＰファイルをダウンロードしてリムーバブルメディアに書き込む。上述したように、ファームウェア２２を構成する実行形式ファイル、クラスファイル等は、テキストファイルと共にＺＩＰファイルに格納されるので、新たなファームウェア２２を格納したＺＩＰファイルをダウンロードしてリムーバブルメディアに書き込むことで、ファームウェア２２更新の準備が完了する。

再生装置１０２がネットワーク接続されておらず、スタンドアローンで使用されている場合、ユーザが所持するパソコンは、再生装置１０２の代わりに、再生装置１０２のファームウェア２２における最新のアップデート状況の監視を行う。かかる監視は、例えば再生装置１０２に付属しているソフトウェアキットをパソコンにインストールすれば、当該パソコンが自動的に行うことになる。もしファームウェア２２アップデートの告知があれば、そのソフトウェアキットがインストールされているパソコンは、ネットワークを介して、新たなファームウェア２２を格納したＺＩＰファイルのダウンロードを行い、自身のハードディスクに書き込む。

こうして新たなファームウェア２２を格納したＺＩＰファイルをリムーバブルメディアに書き込むことで、ファームウェア２２更新の準備が完了する。新たなファームウェア２２を格納したＺＩＰファイルは、特殊な文字・数字（マジックナンバー）がファイル名として与えられており、その他のファイルと区別できるようになっている。 こうしたマジックナンバーを有したファイルが記録されたリムーバブルメディアが、装填された場合、再生装置１０２は、ファームウェア２２の更新を行うことになる。以上がユーザによるファームウェア２２の更新についての説明である。

＜ブートローダ２１＞
続いて、再生装置１０２のソフトウェア的な構成要素であるブートローダ２１について説明する。
図１１は、ブートローダ２１、システムアプリケーション２８の内部構成を示す図である。

図１１（ａ）は、ブートローダ２１の内部構成を示す。本図に示すようにブートローダ２１は、ファームウェア起動部３１、ファームウェア更新部３２から構成される。また、これらの構成要素が、共通にあつかうシステム制御の変数として、フラッシュＲＯＭ１８には、図１１（ｂ）に示すような“最初の実行を示すフラグ”が存在する。このフラグは、“０”に設定されることで、ファームウェア２２が未実行である旨を示す。また、“１”に設定されることで、ファームウェア２２の最初の実行は、完了したが、アプリケーションデータ領域におけるベンチマークスコアの書き込みが未完であることを示す。

“２”に設定されることで、ファームウェア２２の最初の実行と、アプリケーションデータ領域におけるベンチマークスコアの書き込みとが完了したことを示す。
（ファームウェア起動部３１）
ファームウェア起動部３１は、ＭＰＵ１６の特権モードで動作することができるプログラムの１つであり、本装置の電源スィッチが押下されて、電源ユニットからＭＰＵ１６、デバイスに電源が供給され、これらのハードウェアが起動した際、フラッシュＲＯＭ１８に格納されたファームウェア２２をメモリ（例えば図７に示すＲＡＭ１５におけるファームウェアの常駐領域）にロードして、ＭＰＵ１６による実行に供する。このロードの際、フラグの値が“０”であるか否かを判定することでファームウェア２２の実行が、最初の実行であるかどうかの判定を行い、最初の実行であれば、フラグを“１”に設定する。このファームウェア２２の最初の実行は、マニファクチャがファームウェアを完成した後の、マニファクチャによるファームウェア２２の最初の実行と、ユーザによってファームウェアが更新された場合における、更新後のファームウェア２２の最初の実行とがある。

図１２は、ファームウェア起動部３１がどのような処理を行い、ファームウェア２２が、どのような経路を経てＭＰＵ１６に供されるかを模式的に示す図である。矢印（２−ａ）は、ファームウェア起動部３１による読出指示であり、矢印（２−ｂ）は、この読出指示に基づく、フラッシュＲＯＭ１８からＭＰＵ１６へのファームウェア２２の供給を示す。矢印（２−ｃ）は、ファームウェア起動部３１によるフラグの更新（０→１）を模式的に示す。

（ファームウェア更新部３２）
ファームウェア更新部３２は、ＭＰＵ１６の特権モードで動作することができるプログラムの１つであり、本装置の電源スィッチが押下されて、電源ユニットからＭＰＵ１６、デバイスに電源が供給され、これらのハードウェアが起動した際、新たなファームウェア２２が記録されたリムーバブルメディアが装填されているかどうかを判定する。そして、リムーバブルメディアが装填されている場合、かかるリムーバブルメディアに、マジックナンバーがファイル名として付与されたファイルが存在するかどうかをチェックする。このマジックナンバーは、当該リムーバブルメディアに、アップデート後のファームウェア２２が存在することを示す特殊な番号であり、かかるマジックナンバーをもったファイルがリムーバブルメディアに存在すれば、当該リムーバブルメディアから、新たなファームウェア２２を読み出して、ファームウェア２２上の古いファームウェア２２を上書きする。こうした上書きの後、フラグを“０”に更新する。

図１２では、ファームウェア更新部３２による指示やデータの行き来を、矢印で模式化して描いた図である。矢印（１−ａ）は、マジックナンバーが付された新しいファームウェア２２の読み出しであり、矢印（１−ｂ）は、新たなファームウェア２２を用いた上書きを模式的に示す。矢印（１−ｃ）は、ファームウェア更新部３２によるフラグの更新（１→０）を模式的に示す。

以上がブートローダ２１についての説明である。図１１（ｃ）に戻ってシステムアプリケーション２８の詳細について、説明する。図１１（ｃ）のシステムアプリケーション２８には、アプリケーションマネージャ３３、ベンチマークスコア設定部３４が記述されている。尚、システムアプリケーション２８の構成要素のうち、クラスローダ、ユーザイベントマネージャは、既に説明したので説明を省く。

（アプリケーションマネージャ３３）
アプリケーションマネージャ３３は、ＢＤ−Ｊオブジェクトにおけるアプリケーション管理テーブル（ＡＭＴ）に基づいて、“アプリケーションシグナリング”を実行する。具体的には、再生装置１０２において再生対象となるタイトルの切り替わりが発生した場合、新たなタイトルに対応するＢＤ−Ｊオブジェクトにおけるアプリケーション管理テーブルを参照して、この新たなタイトルを生存区間とするＢＤ−Ｊアプリケーションがどれであるかを判定する。そして、判定されたＢＤ−Ｊアプリケーションのロードをクラスローダに行わせる。本実施形態特有の処理として、再生装置１０２にＢＤ−ＲＯＭが装填され、再生装置１０２が起動された際、ベンチマークスコア設定部３４をＢＤ−Ｊモジュール２７による実行に供する。

（ベンチマークスコア設定部３４）
初期化部に対応するベンチマークスコア設定部３４は、ＭＰＵ１６の特権モードで動作することができるプログラムの１つであり、ファームウェアの最初の実行であるかを示すフラグが“０”か否かの判定を行い、もし“０”であれば、フラッシュＲＯＭ１８におけるファームウェア２２からベンチマークスコアを読み出して、アプリケーションデータ領域に書き込む。

図１３は、フラッシュＲＯＭ１８中のベンチマークスコアが、どのような経路を経てベンチマークスコア設定部３４に供されるかを模式的に示す図である。矢印（３−ａ）は、フラグの供給経路であり、当該フラグの設定値は、ベンチマークスコア設定部３４に供され、ファームウェア２２の実行が最初かどうか、アプリケーションデータ領域にベンチマークスコアが書き込まれたかどうかの判定に供される。

矢印（３−ｂ）は、フラッシュＲＯＭ１８からベンチマークスコア設定部３４へのベンチマークスコアの供給経路を象徴的に示す。当該ベンチマークスコアは、ＭＰＵの特権モードのみで実行可能な、特殊なＲｅａｄコマンド（Ｒｅａｄ要求）を発行することによって、フラッシュＲＯＭ１８から読み出され、ベンチマークスコア設定部３４に引き渡されることになる。

矢印（３−ｃ）は、ベンチマークスコア設定部３４からＰｅｒｓｉｓｔｅｎｔ領域（より具体的には、アプリケーションデータ領域）へのベンチマークスコアの供給経路を象徴的に示す。当該ベンチマークスコアは、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスを用いたＷｒｉｔｅ要求によって、アプリケーションデータ領域に書き込まることになる。サービスアプリケーションによるＷｒｉｔｅ要求の発行は、ファイル読出のためのＡＰＩメソッドをコールすることでなされる。Ｗｒｉｔｅ要求におけるアクセス先は、固定ファイルパスを用いて特定される。

以上のように、ベンチマークスコアは、ファームウェア２２に組込まれた形態で再生装置１０２に供給され、ファームウェア２２が最初に実行された際、アプリケーションデータ領域に格納されることになる。
ＣｅｒｔＩＤが“０ｇ１ａ２４ｅｄ”であり、ＯｒｇａｎｉｚａｔｉｏｎＩＤが“４”、ＡｐｐｌｉｃａｔｉｏｎＩＤが“５”である場合、図１４に示すようなディレクトリ・ファイル構成で、ベンチマークスコアは格納されることになる。図１４は、ＣｅｒｔＩＤが例えば“０ｇ１ａ２４ｅｄ”、ＯｒｇａｎｉｚａｔｉｏｎＩＤが例えば“４”、ＡｐｐｌｉｃａｔｉｏｎＩＤが例えば“５”である場合の、ディレクトリ・ファイル構成の一例を示す図である。

この“４”というＯｒｇａｎｉｚａｔｉｏｎＩＤが、ＢＤ再生装置１０２の標準化を推進する組織の一例を示す識別子であり、“５”というＡｐｐｌｉｃａｔｉｏｎＩＤが、ベンチマークアプリケーション２９の一例を示す識別子である場合、これら組織の識別子と、ベンチマークアプリケーション２９の識別子とを組合せたファイルパスにより、ベンチマークスコアは読み出されることになる。

以降、このアプリケーションデータ領域に対するアクセスについて説明する。
図１５は、アプリケーションデータ領域中のベンチマークスコアが、どのような経路を経てサービスアプリケーションに引き渡されかを示す図である。
矢印（５−ａ）は、サービスアプリケーションが放ったＲｅａｄ要求の供給経路である。サービスアプリケーションによるＲｅａｄ要求の発行は、ファイル読出のためのＡＰＩメソッドをコールすることでなされる。Ｒｅａｄ要求におけるアクセス先は、固定ファイルパスを用いて特定される。固定ファイルパスを用いたＲｅａｄ要求は、アクセス制御機構２４に引き渡され、アクセス制御機構２４による権限チェックに供されることがわかる。

矢印（５−ｂ）は、サービスアプリケーションからアクセス制御機構２４へのデジタル信用証明書の供給経路を象徴的に示す。当該デジタル信用証明書は、アクセス制御機構２４に引き渡される。
矢印（５−ｃ）は、アプリケーションデータ領域からサービスアプリケーションへのベンチマークスコアの供給経路を象徴的に示す。サービスアプリケーションが正当権限を具備していることが認められれば、ＲＥＡＤ要求に従ってシステムアプリケーシ２８は、ローカルストレージにおけるＰｅｒｓｉｓｔｅｎｔ領域のアクセスを行い、その結果、矢印（５−ｄ）に示すように、ベンチマークスコアはサービスアプリケーションに引き渡されることになる。

以上が、システムアプリケーション２８の構成要素についての説明である。続いて、ファームウェア更新部３２、ファームウェア起動部３１が行う処理手順の詳細について説明する。
図１６（ａ）は、ファームウェア更新部３２の処理手順を示すフローチャートである。ステップＳ１は、リムーバブルメディアが装填されたかどうかの監視であり、リムーバブルメディアが装填されればステップＳ２に移行する。ステップＳ２は、マジックナンバーを有したファイルが存在するかどうかの判定である。もし存在しなければ何の処理も行わず、本フローチャートの処理を終了する。もし存在すれば、ステップＳ３において、リムーバブルメディアからファームウェア２２を読み出して、フラッシュＲＯＭ１８における古いファームウェア２２を上書きする。その後、ステップＳ４において、フラッシュＲＯＭ１８におけるフラグを、“０”に設定する。

図１６（ｂ）は、ファームウェア起動部３１の処理手順を示すフローチャートである。電源が投入されれば、ＭＰＵ１６に対してリセット割込みが発生し、ＭＰＵ１６におけるプログラムカウンタは、リセットベクタに設定され、初期化プログラムが実行される。これにより、ＭＰＵ１６の動作モードが設定され、ＭＰＵ１６内の各種レジスタが初期化される。続いて、クロック、バス、メモリ等が初期化される。ＭＰＵ１６側の初期化が終了した後、今度はプログラムの初期化が開始され、ファームウェア起動部３１に処理が移る。ステップＳ５は、フラグが“０”であるか否かの判定であり、判定結果に応じて、ステップＳ６を実行するか、スキップするかの制御を行う。フラグが“０”であれば、ステップＳ６において、フラグを“１”に設定する。これによりフラグは、フラッシュＲＯＭ１８におけるファームウェア２２が最初に実行された状態を示すことになる。

その後、ＭＰＵ１６の初期化を行い（ステップＳ７）、基本デバイスの初期化を行って（ステップＳ８）、フラッシュＲＯＭ１８からＲＡＭ１５にファームウェア２２を転送する（ステップＳ９）。最後に、ファームウェア２２を初期化して、起動する（ステップＳ１０）。
図１７は、ベンチマークスコア設定部３４の処理手順を示すフローチャートである。本フローチャートでは、先ずファームウェア２２からフラグを読み出して（ステップＳ１１）、ステップＳ１２の判定ステップを実行する。ステップＳ１２は、フラグが“１”かどうかの判定であり、もし“１”であればステップＳ１３〜ステップＳ１５の処理を実行する。フラグが“１”でなければ、ステップＳ１６、ステップＳ１７を実行する。

ステップＳ１３〜ステップＳ１５の処理手順は、ファームウェア２２からベンチマークスコアを格納したテキストファイルを読み出し（ステップＳ１３）、そうして読み出されたテキストファイルを、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスを用いてアプリケーションデータ領域に書き込む（ステップＳ１４）。その後、フラグを“２”に設定する（ステップＳ１５）というものである。

ステップＳ１６、ステップＳ１７の処理手順は、ファイルパスを用いてベンチマークスコアが存在するかどうかをチェックし（ステップＳ１７）、存在すれば処理を終了するが、存在しなければ、ファームウェア２２からベンチマークスコアを読み出して、アプリケーションデータ領域に書き込む（ステップＳ１３〜ステップＳ１５）。
以上のように本実施形態によれば、ベンチマークスコアはファームウェア２２に組み込まれており、ファームウェア２２が最初に実行された際、ベンチマークスコアは、アプリケーションデータ領域に書き込まれるので、ＢＤ−Ｊアプリケーションは、アプリケーションデータ領域をアクセスするだけで、ハードウェアの性能に応じた処理負荷の変更を実行することができる。

ベンチマークスコアはファームウェア２２に組込まれているので、ファームウェア２２の不定期な更新があったとしても、最新のファームウェア２２に対応したベンチマークスコアが、再生装置１０２に供給されることになる。
（第２実施形態）
本実施形態では、アクセス制御機構２４によるアクセス権限のチェックがどのように行われるかを具体的に開示する。かかるアクセス権限のチェックは、デジタル信用証明書を対象にしてなされる。

デジタル信用証明書は、ベンチマークプログラム（またはベンチマークスコア）またはデジタル信用証明書の配給者（ディストリビュータ）によって、デジタル信用証明書の要求元となるコンテンツオーサー（アプリケーションの作り手のことである）に供給される。この供給にあたって、以下に示す配信操作が必要となる。
Ａ）ディストリビュータは、デジタル信用証明書を作成するために公開鍵を使用する。

Ｂ）コンテンツオーサーは、公開鍵がデジタル信用証明書に付けて供給されることを、ディストリビュータに要求する。この際、コンテンツオーサーは、証明されたハッシュ値をディストリビュータに供給する。
Ｃ）ディストリビュータは、供給されたハッシュ値を用いて、デジタル信用証明書を作成する。

このような過程を経ることで、ディストリビュータは、有効なデジタル信用証明書を獲得することができる。有効なデジタル信用証明書をもったＢＤ−Ｊアプリケーションは、アプリケーションデータ領域におけるベンチマークスコアをアクセスすることができる。しかしながら、有効なデジタル信用証明書をもたないＢＤ−Ｊアプリケーションは、アプリケーションデータ領域におけるベンチマークスコアをアクセスすることができない。

かかるデジタル信用証明書は、アーカイブファイルに組み込まれた上、ＢＤ−ＲＯＭに記録されて、再生装置１０２に供される。機能セグメントの検証には、上述したデジタル信用証明書の他、図２に示したＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ（ディスクルート証明書）と、アーカイブファイルに存在するその他のファイルとが必要になる。以降、アーカイブファイルの内部構成について説明する。

Ｊａｖａ（登録商標）アーカイブファイル（ＸＸＸ．ＪＡＲ）は、複数のファイルをディレクトリ構造の形で格納している。図１８（ａ）はＪａｖａ（登録商標）アーカイブファイルの内部構成の一例を示す図である。この構造は、ルートディレクトリ直下にＸＸＸＸ．ｃｌａｓｓが存在し、ＭＥＴＡ−ＩＮＦディレクトリにファイルＭＡＮＩＦＥＳＴ．ＭＦ、ファイルＳＩＧ−ＢＤ．ＳＦ、ファイルＳＩＧ−ＢＤ．ＲＳＡ、ファイルｂｄ．ＸＸＸＸ．ｐｅｒｍが存在するというものである。以下、これらのファイルについて個別に説明してゆく。

（ｉ）ＸＸＸＸ．ｃｌａｓｓ：クラスファイル
クラスファイルは、Ｊａｖａ言語等、オブジェクト指向言語を用いて記述されたクラス構造体を格納している。
（ｉｉ）ＭＡＮＩＦＥＳＴ．ＭＦ：マニフェストファイル
マニフェストファイルは、デジタル証明書に対応するものであり、Ｊａｖａ（登録商標）アーカイブファイルの属性、Ｊａｖａ（登録商標）アーカイブファイル内のクラスファイルやデータファイルのハッシュ値が記載されているファイルである。Ｊａｖａ（登録商標）アーカイブファイルの属性には、クラスファイルのインスタンスである、ＢＤ−Ｊアプリケーションに付与されるアプリＩＤ、Ｊａｖａ（登録商標）アーカイブファイルを実行するために最初に実行すべきクラスファイル名がある。上記の二つのＪａｖａ（登録商標）アーカイブファイルの属性が存在しない場合、Ｊａｖａ（登録商標）アーカイブファイル中のクラスファイルのインスタンスであるＢＤ−Ｊアプリケーションを実行しない。

（ｉｉｉ）ＳＩＧ−ＢＤ．ＳＦ：シグネチャファイル、
ＳＩＧ−ＢＤ．ＳＦは、マニフェストファイルのハッシュ値が記載されているファイルである。
（ｉｖ）ＳＩＧ−ＢＤ．ＲＳＡ：デジタルシグネチャファイル
ＳＩＧ−ＢＤ．ＲＳＡは、「デジタル証明書チェーン」、ＳＩＧ−ＢＤ．ＳＦの「署名情報」が記載されているファイルである。

ＳＩＧ−ＢＤ．ＳＦに対する「署名情報」は、署名処理をＳＩＧ−ＢＤ．ＳＦに施すことで得られる。これらの署名処理には、ＳＩＧ−ＢＤ．ＲＳＡ内のデジタル証明書チェーンにおける公開鍵に対応する秘密鍵が用いられる。
「デジタル証明書チェーン」とは、一つ目の証明書（ルート証明書）が二つ目の証明書を署名し、また同じようにｎ番目の証明書がｎ＋１番目の証明書を署名している形をもつ複数の証明書群である。デジタル証明書チェーンの最後の証明書を「リーフ証明書」と呼ぶ。この構成を利用することにより、ルート証明書から順番に次の証明書を保障していくことにより、デジタル証明書チェーンの最後の証明書までを保障することができる。

「ルート証明書」は、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥファイルに存在するディスクルート証明書３０１と同じ証明書を格納している。
「リーフ証明書」には、組織ＩＤが記載されている。ＳＩＧ−ＢＤ．ＳＦは、ＰＫＣＳ＃７という形式により格納されている。ＰＫＣＳ＃７は署名および一つ以上のデジタル証明書を格納するためのファイル形式であり、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）より発行されたＲＦＣ２３１５に記載されている。ＲＦＣ２３１５はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３１５．ｔｘｔより参照できる。

通常、このデジタル証明書チェーンは、１つであるが、後述する権限の提供がある場合、このデジタル証明書チェーンは２つ作られる。これら２つのデジタル証明書チェーンを、第１デジタル証明書チェーン、第２デジタル証明書チェーンと呼ぶ。第１デジタル証明書チェーンのルート証明書は、権限提供を受ける側の組織のディスクルート証明書を示し、リーフ証明書は、権限提供を受ける側の組織の組織ＩＤを示す。第２デジタル証明書チェーンのルート証明書は、権限を提供する側の組織のディスクルート証明書を示し、リーフ証明書は、権限を提供する側の組織の組織ＩＤを示す。一方、権限の提供がない場合、デジタル証明書チェーンは、１つ（第１デジタル証明書チェーン）のみになる。

マニフェストファイル、ＳＩＧ−ＢＤ．ＳＦ、ＳＩＧ−ＢＤ．ＲＳＡの詳細はＪａｖａ（登録商標）アーカイブファイルの仕様に記載されている。マニフェストファイル、ＳＩＧ−ＢＤ．ＳＦ、ＳＩＧ−ＢＤ．ＲＳＡは署名処理および署名検証処理を行うために利用される。最終的にＪａｖａ（登録商標）アーカイブファイル中のクラスファイルのインスタンスであるＢＤ−Ｊアプリケーションやパーミッションリクエストファイル４０５をデジタル証明書により署名することが可能になる。以降マニフェストファイル、ＳＩＧ−ＢＤ．ＳＦ、ＳＩＧ−ＢＤ．ＲＳＡをまとめて「デジタル証明書による署名」と称する。

（ｖ）ｂｄ．ＸＸＸＸ．ｐｅｒｍ：パーミッションリクエストファイル
ｂｄ．ＸＸＸＸ．ｐｅｒｍは、実行されるＢＤ−Ｊアプリケーションにどのパーミッションを与えるのかの情報を格納するファイルである。具体的に以下の情報を格納する。
（ア）デジタル信用証明書（Ｃｒｅｄｅｎｔｉａｌ）
以降、デジタル信用証明書について説明する。“デジタル信用証明書”とは、ある組織に帰属する組織ディレクトリ内のファイルを共有化するための情報である。この共有化は、ある組織に属するアプリケーション用ファイルを利用する権限を、他の組織に属するアプリケーションに提供することでなされる。そのためデジタル信用証明書は、権限を提供する側の組織を示す提供者組織ＩＤ、権限を受領する側の組織の識別を示す受領者組織ＩＤを含む。

図１８（ｂ）は、デジタル信用証明書のデータ構造の一例を示す。デジタル信用証明書には、ルート認証局から提供者組織に配布されたルート証明書のハッシュ値５１、提供者組織に割り当てられた提供者組織ＩＤ５２、ルート認証局から受領者に配布された受領者ルート証明書のハッシュ値５３、受領者組織に割り当てられた受領者組織ＩＤ５４、受領者アプリＩＤ５５、提供ファイルリスト５６からなる。提供ファイルリスト５６には、一つ以上の提供ファイル名５７とアクセス方法５８（読み取り可・書き込み可）の情報が格納されている。デジタル信用証明書が有効であるためには署名されなければならない。デジタル信用証明書の署名にはＳＩＧ−ＢＤ．ＲＳＡと同様にＰＫＣＳ＃７の方式を利用できる。

図１８（ｃ）は、デジタル信用証明書の具体的な一例を示す図である。本図におけるデジタル信用証明書は、ファイル「４／５／ｓｃｏｒｅｓ．ｔｘｔ」に対して読み取り許可、ファイル「４／５／ｓｃｏｒｅ２．ｔｘｔ」に対して読み書き許可をデジタル信用証明書により与えていることになる。
続いて（イ）アプリ間通信の許可情報について説明する。一つのＪａｖａ（登録商標）アーカイブファイルに含まれるＢＤ−Ｊアプリケーションは通常、他のＪａｖａ（登録商標）アーカイブファイルに含まれるＢＤ−Ｊアプリケーションとの通信（アプリ間通信）が許可されない。ｂｄ．ＸＸＸＸ．ｐｅｒｍにアプリ間通信の許可が与えられている場合だけアプリ間通信が可能である。

デジタル信用証明書が有効であるためには署名されなければならないが、デジタル信用証明書の署名にはＰＫＣＳ＃７の方式を利用できる。ＰＫＣＳ＃７は署名および一つ以上のデジタル証明書を格納するためのファイル形式であり、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）より発行されたＲＦＣ２３１５に記載されている。ＲＦＣ２３１５はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３１５．ｔｘｔより参照できる。こうした署名の結果は、提供者ルート証明書のハッシュ値として、ＳＩＧ−ＢＤ．ＳＦに格納される。

以上が、ｂｄ．ＸＸＸＸ．ｐｅｒｍについての説明である。続いて、ルート証明書についてのより詳しく説明する。
図１９は、権限の提供がない場合のＳＩＧ−ＢＤ．ＳＦ、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥの相互関係を示す図である。本図における矢印ｄ１は、これらのファイルの内部構成の情報要素のうち、同一性があるものを示している。権限の提供がない場合、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ内のルート証明書（ディスクルート証明書）は、ＳＩＧ−ＢＤ．ＲＳＡにおける第１のデジタル証明書チェーン内のルート証明書と同一性を有したものになる。

ＭＡＮＩＦＥＳＴ．ＭＦは、クラスファイルＸＸＸＸ．ｃｌａｓｓに署名処理を施すことで得られたハッシュ値を含み、ＳＩＧ−ＢＤ．ＳＦは、ＭＡＮＩＦＥＳＴ．ＭＦに署名処理を施すことで得られたハッシュ値を含み、ＳＩＧ−ＢＤ．ＲＳＡは、ＳＩＧ−ＢＤ．ＳＦに署名処理を施すことで得られたハッシュ値を含んでいるので（矢印ｈ１）、これらのハッシュ値が正しいかどうかを確認し、これらのハッシュ値の同一性を判定することで、再生装置１０２は、Ｊａｖａ（登録商標）アーカイブファイルが正当なものか、改竄が加えられたものかを判断することができる。また権限の提供がないとの想定なので、本図では、ｂｄ．ＸＸＸＸ．ｐｅｒｍを示していない。

図２０は、権限の提供がある場合のＳＩＧ−ＢＤ．ＳＦ、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ、ｂｄ．ＸＸＸＸ．ｐｅｒｍの相互関係を示す図である。本図における矢印ｄ１〜ｄ６は、これらのファイルの内部構成の情報要素のうち、同一性があるものを示している。権限の提供権限の提供があった場合も、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ内のルート証明書（ディスクルート証明書）は、ＳＩＧ−ＢＤ．ＲＳＡにおける第１のデジタル証明書チェーン内のルート証明書と同一性を有したものになる（矢印ｄ１）。一方、権限の提供があると、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ内のディスクルート証明書は、受領者のものになるので、ｂｄ．ＸＸＸＸ．ｐｅｒｍにおけるデジタル信用証明書の、受領者ルート証明書が、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ内のルート証明書と同一性をもつ（矢印ｄ２）。また、デジタル信用証明書における受領者組織ＩＤは、第１のデジタル証明書チェーンにおけるリーフの組織ＩＤと同一性をもつ（矢印ｄ３）。

ｂｄ．ＸＸＸＸ．ｐｅｒｍにおけるデジタル信用証明書の、提供者組織のルート証明書は、ＳＩＧ−ＢＤ．ＳＦ内の第２のデジタル証明書チェーンにおけるルート証明書と同一性をもつ（矢印ｄ４）。また、デジタル信用証明書における提供者組織ＩＤは、ＳＩＧ−ＢＤ．ＳＦの第２のデジタル証明書チェーンにおけるリーフの組織ＩＤと同一性をもつ（矢印ｄ５）。デジタル信用証明書における受領者アプリＩＤは、ｂｄ．ＸＸＸＸ．ｐｅｒｍにおいてデジタル信用証明書以外の部分に存在するアプリＩＤと同一性をもつ（矢印ｄ６）。

ＭＡＮＩＦＥＳＴ．ＭＦは、クラスファイルＸＸＸＸ．ｃｌａｓｓから算出したハッシュ値を含み、ＳＩＧ−ＢＤ．ＳＦは、ＭＡＮＩＦＥＳＴ．ＭＦから算出したハッシュ値を含み、ＳＩＧ−ＢＤ．ＲＳＡは、ＳＩＧ−ＢＤ．ＳＦから取得したハッシュ値を含むので（矢印ｈ１）、これらの署名が正しいかどうかを確認し、これらのハッシュ値の同一性を判定することで、再生装置１０２は、Ｊａｖａ（登録商標）アーカイブファイルが正当なものか、改竄が加えられたものかを判断することができる。あらかじめ断っておくが、本実施形態では、ルート証明書の同一性を、それぞれのルート証明書について算出されたハッシュ値を比較し、これらのハッシュ値が一致しているかどうかで判断するものとする。またハッシュ値の算出は一度行えばよく、算出したものをメモリ等に記憶して、利用することが一般的に行われる。ルート証明書からハッシュ値を算出することや、メモリに格納したハッシュ値を取出すことを、ハッシュ値の「取得」と呼ぶ。

図２１は、ＢＤ−Ｊアプリケーションが、アプリケーションデータ領域にアクセスする場合の処理手順を示すフローチャートである。
ステップＳ２１は、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスを用いたアクセス要求が存在したかどうかの判定であり、もしそうであるなら、ステップＳ２２〜ステップＳ２５を実行する。そうでないなら、そのアクセス要求に従った処理を行う。ステップＳ２２〜ステップＳ２５は、要求元のＢＤ−Ｊアプリケーションのアーカイブファイルから、デジタル信用証明書を取り出し（ステップＳ２２）、デジタル信用証明書を用いて要求元のサービスアプリケーションのアクセス権限をチェックして、検証が成功したかどうかを判定する（ステップＳ２４）。検証が成功すれば、仮想ファイルシステム２３におけるファイルＩ／Ｏを介して、要求対象となるテキストファイルを読み出し、要求元ＢＤ−Ｊアプリケーションに引き渡す（ステップＳ２５）。検証が失敗すれば、要求元ＢＤ−Ｊアプリケーションが、仮想ファイルシステム２３におけるファイルＩ／Ｏを介して、要求対象となるテキストファイルを読み出すことを許可せず、例外終了する。

上述の構成においては、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスを用いたアクセス要求したかどうかを判定するようにしたが、例えばＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスを用いたアクセス要求をしたかどうかを判定し、検証が成功した場合、仮想ファイルシステム２３におけるファイルＩ／Ｏは、デジタル信用証明書から特定された提供者ルート証明書の証明書ＩＤを用いてＣｅｒｔＩＤを特定し、特定したＣｅｒｔＩＤと上述のＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤを用いて、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスに対応するテキストファイルを要求元ＢＤ−Ｊアプリケーションに引き渡しても良い。

このように構成することにより、アプリケーションが要求対象となるテキストファイルへアクセスすることを抑制するとともに、証明書ＩＤ（および証明書ＩＤに対する提供者ルート証明書、またはリーフ証明書）の秘匿性を高くすることが可能となる。
図２２は、デジタル信用証明書を用いた権限チェックの処理手順を示すフローチャートである。本フローチャートは、アクセスしようとするサービスアプリケーションに対して、ステップＳ３１〜ステップＳ３７の判定を順次行い、どれかの判定ステップの判定結果がＮｏであれば、検証失敗であると、検証結果を下すものである。

以降、ステップＳ３１〜ステップＳ３７における検証の内容が、どのようなものであるかを説明する。
ステップＳ３１は、デジタル信用証明書における受領者ルート証明書のハッシュ値と、ＢＤ−ＲＯＭにおける、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥ内のディスクルート証明書とが一致するかどうかを確認である。

ステップＳ３２は、デジタル信用証明書における受領者組織ＩＤと、ディスクルート証明書をルートとしたチェーンのリーフ証明書に記述された組織ＩＤとが一致するかどうかの確認である。
ステップＳ３３は、デジタル信用証明書における受領者アプリＩＤと、サービスアプリケーションのアプリＩＤと一致するかどうかの確認である。

ステップＳ３４は、提供ファイルを特定するファイルパスの先頭に位置するディレクトリ名が、提供者組織ＩＤと一致するかどうかの確認である。
ステップＳ３５は、デジタル信用証明書に含まれる署名、つまり、提供者ルート証明書のハッシュ値が正しいかどうかの確認である。この確認は、デジタル信用証明書についてのハッシュ値を算出してみて、そうして算出されたハッシュ値が、デジタル信用証明書内の提供者ルート証明書のハッシュ値と一致しているかどうかの判定でなされる。

ステップＳ３６は、デジタル信用証明書の署名である、ＳＩＧ−ＢＤ．ＳＦにおけるルート証明書のハッシュ値と、デジタル信用証明書内に記述されている提供者ルート証明書のハッシュ値とが一致するかどうかの確認である。
ステップＳ３７は、デジタル信用証明書の署名である、ＳＩＧ−ＢＤ．ＳＦにおけるリーフ証明書の組織ＩＤが、デジタル信用証明書内に記述されている提供者組織ＩＤと一致するかどうかの判定である。

以上のステップＳ３１〜ステップＳ３７がすべてＹｅｓであるなら、検証が成功する。
以上の判定を経て、デジタル信用証明書の検証に成功した場合、アプリケーションデータ領域に記録されているベンチマークスコアに対して、デジタル信用証明書の提供アクセス方法に記述されたアクセスを、アクセス要求を行ったサービスアプリケーションに対して許す。

図１４のデジタル信用証明書においては、４／５／ｓｃｏｒｅｓ．ｔｘｔ、４／５／ｓｃｏｒｅｓ２．ｔｘｔという２種類のベンチマークスコアを保持するファイルに対するアクセスを許し、４／５／ｓｃｏｒｅｓ．ｔｘｔに対しては読み取りのみ、４／５／ｓｃｏｒｅｓ２．ｔｘｔに対しては読み書きを許している。
このように、デジタル信用証明書により検証されたサービスアプリケーションに対して、読み取りだけでなく、書き込みを許すことにより、サービスアプリケーションにより、ユーザ待ちを生じることのない程度のベンチマークを実行し、そのスコアを、デジタル信用証明書を持つサービスアプリケーション間で共有することが可能となる。

（第３実施形態）
第１実施形態では、ファームウェア２２に組込まれたベンチマークスコアを読み出して、アプリケーションデータ領域に書き込んだが、本実施形態では、ファームウェア２２に組み込まれたベンチマークスコアをローカルストレージにおけるアプリケーションデータ領域にコピーするのではなく、ベンチマークアプリケーション２９は、ファームウェア２２起動時にメモリ（例えば図７に示すＲＡＭ１５）に展開する。

この展開は、例えば以下のようにして行われる。即ち、ベンチマークアプリケーション２９はヒープエリア管理機能を用いて、メモリの空き領域にヒープメモリを確保して、そうして確保したヒープメモリに、ベンチマークスコアを書き込む。以降、アプリケーション間通信によって、ベンチマークスコアが書き込まれた旨を他のサービスアプリケーションに知らせ、ヒープメモリに存在するベンチマークスコアを、他のサービスアプリケーションに利用させる。

図２３は、第３実施形態におけるベンチマークスコアの行き来を模式的に描いた図である。（６−ａ）は、再生装置１０２起動時における、フラッシュＲＯＭ１８からＲＡＭ１５におけるヒープメモリへのベンチマークスコアの読み出しを模式的に示す。（６−ｂ）は、サービスアプリケーションからの要求時における、ＲＡＭ１５からサービスアプリケーションへのベンチマークスコアの読み出しを模式的に示す。

こうすることで、ローカルストレージにおけるアプリケーションデータ領域へとベンチマークスコアをコピーするために生じる、遅延時間を短縮することができる。また、アプリケーションデータ領域がＳＤメモリカード等で構成されている場合、ＳＤメモリカードに対する書き込み回数抑制することができる。
上述の例では、例えば図７に示すＲＡＭ１５のヒープメモリにベンチマークスコアを書き込む構成としたが、ファームウェア２２にベンチマークスコアは組み込まれているわけであるから、例えば本装置の電源スィッチが押下されて、電源ユニットからＭＰＵ１６、デバイスに電源が供給され、これらのハードウェアが起動した際、フラッシュＲＯＭ１８に格納されたファームウェア２２をＲＡＭ１５におけるファームウェアの常駐領域にロードするときにベンチマークスコアもロードするような構成としても良い。

また上述の例では、以降、アプリケーション間通信によって、ベンチマークスコアが書き込まれた旨を他のサービスアプリケーションに知らせ、ヒープメモリに存在するベンチマークスコアを、他のサービスアプリケーションに利用させる構成について説明をしたがこれに限定をされる必要はなく、ベンチマークスコアをＲＡＭへ書き込んだとき、ＲＡＭ１５における書き込んだ位置（例えばアドレス情報）に関する情報を保持する位置管理情報（図示せず）を作成しておき、アプリケーションプログラムからベンチマークスコアへのアクセスの要求があったとき位置管理情報に従って、ＲＡＭ１５におけるベンチマークスコアを読み出して、アプリケーションプログラムへ渡すように構成しても良い。

この場合、第１実施形態で述べたJavaTMI/Oメソッドを実現するファイルＩ/Ｏプログラムは、BD-Jアプリケーションプログラムから指定されたファイルパスを受け取ると、位置管理情報を参照し、RAM１５上に展開したベンチマークスコアを読み込んでBD-Jアプリケーションプログラムへ返すことになる。
また上述の位置管理情報（図示せず）はＲＡＭ１５におけるベンチマークスコアの格納位置に関する情報だけでなく、本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）との対応関係を併せて保持するようにしても良い。

このように構成すると、アプリケーションプログラムは本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）を指定して、ベンチマークスコアの読み出しを要求しても、ファームウェア２２における仮想ファイルシステム２３におけるファイルＩ／Ｏが位置管理情報（図示せず）を参照して、位置管理情報に従って、フラッシュＲＯＭ１８におけるベンチマークスコアを読み出して、読み出したベンチマークスコアを要求したアプリケーションプログラムへ引き渡すことができるようになる。

こうすることで、本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）であるアプリケーションデータ領域を含むローカルストレージが書き込み回数に上限があるメモリなどの場合、ローカルストレージへの書き込みを抑制できる。

また、ローカルストレージにおけるアプリケーションデータ領域へとベンチマークスコアをコピーするために生じる、遅延時間を短縮することができる。また、本来の格納場所であるアプリケーションデータ領域が半導体メモリカードで構成されている場合、半導体メモリカードに対する書き込み回数抑制することができる。

（第４実施形態）
第２実施形態では、リムーバブルメディアによって新たなファームウェア２２が供給された場合、自動的にアプリケーションデータ領域に存在するベンチマークスコアの上書きを行ったが、本実施形態では、ファームウェア２２の更新がなされた場合、既にアプリケーションデータ領域に存在するベンチマークスコアのバージョンと、新たなファームウェア２２に組込まれたベンチマークスコアとのバージョン比較を行い、新たなＦｅＲＡＭ１５組み込まれたベンチマークスコアが新しいと判定された場合にのみ、新たなファームウェア２２内のベンチマークスコアを、アプリケーションデータ領域に書き込む。ベンチマークスコアは、テキストファイルに格納された状態でファームウェア２２に組み込まれるので、テキストファイルの作成又は更新日時をベンチマークスコアのバージョンとして採用することができる。また、ベンチマークがなされた日時をテキストファイルに記録しておいて、この日時をベンチマークスコアのバージョンとして採用することもできる。

こうすることで、アプリケーションデータ領域がＳＤメモリカード等で構成されている場合、ＳＤメモリカードに対する書き込み回数抑制することができる。
（第５実施形態）
本実施形態は、ベンチマークアプリケーション２９によるベンチマークテストが、どのような処理手順で行われるかを具体的に開示する。図２４は、ベンチマークアプリケーション２９によるベンチマークテストの処理手順を示すフローチャートである。

本フローチャートは、ステップＳ４３〜ステップＳ４８の処理を、第１実施形態に示したハードウェアによる処理のそれぞれについて繰り返すというループ構造になっている。
ハードウェア処理としては、〜というものがあるので、これらのそれぞれを実行するためのＡＰＩメソッドの呼出が、ベンチマークアプリケーション２９に記述されていて、それらのＡＰＩメソッドの呼出のそれぞれについて、ステップＳ４３〜ステップＳ４８が繰り返されることになる。

これらの網羅すべき処理のうち、処理対象となるものを処理Ｘとし、この処理Ｘについての形式時間、つまり、ターンアラウンド時間を計測時間Ｘと呼ぶ。ステップＳ４３では、処理Ｘを定めて、計測時間Ｘを０に初期化する。ステップＳ４４では、処理Ｘを実行させるためのＡＰＩメソッドの呼出しを行う。具体的には、ベンチマークスコア評価用に定められたデータをＢＤ−ＲＯＭやローカルストレージからＲＡＭ１５に読み出すためのＡＰＩメソッドの呼出しや、かかるデータをデコードさせるためのＡＰＩメソッドの呼出し、ベンチマークスコア評価用に定められた演算式をＭＰＵ１６に演算させるためのＡＰＩメソッドの呼出しの呼び出しを行う。

その後、ステップＳ４５〜ステップＳ４７のループに移る。ステップＳ４５は、ＡＰＩメソッドの呼出しによって要求した処理が完了したかどうかの判定であり、未完であればステップＳ４６において、ターンアラウンド時間における単位時間Ｗの経過待ちを行う（ステップＳ４６）。
この単位時間Ｗは、例えば、ＭＰＵ１６が数百個以上の命令を実行するクロック時間であり、ベンチマークスコアにおけるターンアラウンド時間の時間精度を基準にして定められる。例えば、ターンアラウンド時間の時間精度に４７ＫＨｚを採用した場合、ＭＰＵ１６の動作クロック時間は、このターンアラウンド時間の時間精度の１／数百以下の値になるので、ステップＳ４６では、このターンアラウンド時間の単位時間の経過を待つ。

そして、この単位時間が経過すれば、計測時間Ｘに単位時間を加算することで計測時間Ｘを更新してステップＳ４５に戻る。かかるステップＳ４５〜ステップＳ４７を繰り返すことで、処理Ｘの完了を待つまでの間、計測時間Ｘは、単位時間Ｗずつ増えてゆくことになる。
そして、処理Ｘが完了して、ベンチマークアプリケーション２９に完了の通知イベントが返されれば、これまで単位時間Ｗが加算された計測時間Ｘを、処理Ｘの識別情報と対応付けて開発用コンピュータ１０５にエクスポートする。開発用コンピュータ１０５は、処理Ｘの識別情報と、計測時間Ｘとを羅列することで、処理Ｘについてのベンチマークスコアを得る。以降、同様の処理を繰り返すことで、処理Ｘの識別情報と、計測時間Ｘとが羅列されたベンチマークスコアのテキストファイルを得る。 このようなベンチマークテストでは、ベンチマークスコアの時間精度は、単位時間Ｗによって定められることになる。

ここで、ＢＤ−Ｊアプリケーションの実行主体であるＪａｖａプラットフォームはイベントドリブンの実行主体であり、Ｊａｖａプラットフォームは、ハードウェアの処理が未完了であったとしても、ＡＰＩメソッドの解読と、下位層への指示を発した直後に応答を返してしまうことがある。そうすると、ベンチマークアプリケーション２９がベンチマークテストを行うにあたって、正確な時間計測が不可能となる。そこで、ベンチマークテストのためのＡＰＩメソッドを設け、このＡＰＩメソッドの呼出し時には、処理が完了した正確な時点でイベントを返すようにするのが望ましい。こうすることで、ターンアラウンド時間の計測は、より正確なものとなる。

以上のように本実施形態によれば、ＡＰＩメソッドの呼出しを行ってから、要求した処理が完了するまでのクロック時間をベンチマークアプリケーション２９が、計測することで、一定の時間精度をもったベンチマークスコアを得ることができる。
（第６実施形態）
本実施形態は、リアルタイムオペレーティングシステム（リアルタイムＯＳ）を、ファームウェア２２の構成要素とした実施形態である。リアルタイムＯＳでは、最悪実行時間の予測が可能であり、ＡＶ再生のリアルタイム性の実現に好適である。

ファームウェア２２として組み込まれる、リアルタイムＯＳの構成要素について説明する。リアルタイムＯＳは、カーネル、ミドルウェア及びデバイスドライバから構成される。これらのカーネル、ミドルウェア及びデバイスドライバが、ファームウェア２２の構成要素となる。
１．カーネル
カーネルは、システムコール処理、割込信号により割込ハンドラを起動するハンドラ入口処理、割込ハンドラの出口処理を行い、タスクスケジューラを有する。各実施形態で述べたＢＤ−Ｊアプリケーションは、リアルタイムＯＳでは、このカーネルによって、“アプリケーションタスク”として扱われる。アプリケーションタスクによるＡＰＩメソッドの呼出しは、リアルタイムオペレーションシステムにおいては、上述したようなシステムコールで実現される。タスクスケジューラは、順次タスクを生成してＭＰＵによる実行に供する。この生成は、実行すべきプログラムについてタスクコントロールブロックを作成して、それらを待ち行列に供することでなされる。

カーネルは、デバイス入出力要求のシステムコールがタスクから発行されれば、メモリプールからメモリブロックを確保し、そのブロックに、呼び出しに使用されたパラメータブロックを作成する。そしてそのパラメータブロックの先頭アドレスと、デバイス情報を記載したデバイステーブルのアドレスを引数にして、デバイスドライバをコールする。
２．ミドルウェア
ミドルウェアは、システムコールを実現するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）群を具備しており、カーネルの存在を前提にして、ブラウザや、ファイルシステム、映像再生及び音声再生といった機能を実現する。アプリケーションは、デコーダといったデバイスを、このミドルウェアを介して、制御することができる。第１実施形態で述べた仮想ファイルシステム２３、アクセス制御機構２４、再生エンジン２５、再生制御エンジン２６、ＢＤ−Ｊモジュール２７は、リアルタイムＯＳでは、このミドルウェアとして位置付けられる。

３．デバイスドライバ
デバイスドライバは、「割込ハンドラ部」と、「割込タスク部」、「リクエスト処理部」から構成される。デバイスドライバは、メモリ空間のシステム用領域にマッピングされ、特権モードで動作することになる。
「リクエスト処理部」は、パラメータブロックを入出力キューに登録した後、割り込み許可を行って、カーネルに復帰する。

「割込ハンドラ部」は、ハードウェアから割込み信号を受け付けると、デバイスとの間で、要求された入出力を行う。予定されている入出力が完了すれば、割り込みを禁止し、割込みタスクを起動する。未完了ならば、デバイスドライバに復帰する。次の入出力要求がなされると、再び割り込みハンドルが起動され、残りの入出力を続ける。
「割込みタスク」は、入力完了状態を引数にして、システムコールにより、入出力完了を、カーネルに通知する。かかる通知を受け取れば、カーネルは、依頼元のタスクを起床する。

ＡＰＩメソッドの呼出しが、システムコールで実現される場合、ベンチマークアプリケーション２９は、アプリケーションタスクがシステムコールを要求してから、デバイスが処理を実行して応答が返るまでのターンアラウンド時間を計測するのが望ましい。そしてマニファクチャは、この計測値をベンチマークスコアとしてファームウェア２２に組み込むことになる。

以上のように本実施形態によれば、ドライブに対するアクセスやＡＶ再生が、リアルタイムＯＳのシステムコールで実現されるので、リアルタイム性の確保が可能である。かかるリアルタイムＯＳでベンチマークアプリケーション２９がベンチマークスコアの計測を行えば、ベンチマークスコアは、ＡＶ再生のリアルタイム性を保証した、正確な値となる。

（第７実施形態）
ファームウェア２２は、本装置の電源スィッチが押下されて、電源ユニットからＭＰＵ１６、デバイスに電源が供給され、これらのハードウェアが起動した際、フラッシュＲＯＭに格納されたファームウェア２２をメモリ（例えば図７に示すＲＡＭ１５におけるファームウェアの常駐領域）にロードして、ＭＰＵ１６による実行に供する構成について説明をしたが、これに限定される必要はなく、ＭＰＵ１６はフラッシュＲＯＭ１８に格納されたファームウェア２２を直接読み込んで実行するように構成をしても良い。

このとき、アプリケーション間通信によって、フラッシュＲＯＭ１８に格納されたファームウェア２２に組み込まれたベンチマークスコアを他のサービスアプリケーションに知らせ、フラッシュＲＯＭ１８に存在するベンチマークスコアを、他のサービスアプリケーションに利用させる構成としてもよい。
また、フラッシュＲＯＭ１８における格納位置（例えばアドレス情報）に関する情報を含む位置管理情報（図示せず）を作成しておき、アプリケーションプログラムからベンチマークスコアへのアクセスの要求があったとき位置管理情報に従って、フラッシュＲＯＭ１８におけるベンチマークスコアを読み出して、アプリケーションプログラムへ渡すように構成しても良い。

また上述の位置管理情報（図示せず）はフラッシュＲＯＭ１８におけるベンチマークスコアの格納位置に関する情報だけでなく、本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）との対応関係を併せて保持するようにしても良い。

このように構成すると、アプリケーションプログラムは本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）を指定して、ベンチマークスコアの読み出しを要求しても、ファームウェア２２における仮想ファイルシステム２３におけるファイルＩ／Ｏが位置管理情報（図示せず）を参照して、位置管理情報に従って、フラッシュＲＯＭ１８におけるベンチマークスコアを読み出して、読み出したベンチマークスコアを要求したアプリケーションプログラムへ引き渡すことができるようになる。

こうすることで、本来の格納場所（例えば、ＡＤＡ−ＣｅｒｔＩＤ−ＯｒｇａｎｉｚａｔｉｏｎＩＤ−ＡｐｐｌｉｃａｔｉｏｎＩＤという組合せの固定ファイルパスによって特定される格納位置）であるアプリケーションデータ領域を含むローカルストレージが書き込み回数に上限があるメモリなどの場合、ローカルストレージへの書き込みを抑制できる。

（備考）
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

（ベンチマークスコアのファイル形式）
第１実施形態において、ベンチマークスコアはテキストファイルに格納されたが、テキストファイルでは、中身の参照が容易であるので、ファームウェア２２への組み込みにあたっては、ベンチマークスコアをバイナリファイルに格納しておくが望ましい。
（再生装置１０２の任意的な構成要素）
任意的要素として、再生装置１０２にレンダリングエンジンを設けてもよい。レンダリングエンジンは、Ｊａｖａ（登録商標）２Ｄ，ＯＰＥＮ−ＧＬといった基盤ソフトウェアを備え、ＢＤ−Ｊアプリケーションからの指示に従ってコンピュ−タ・グラフィックスの描画を行い、描画されたコンピュ−タ・グラフィックスをプレーンメモリに出力する。この描画を高速に行うには、任意的なハードウェア要素として、再生装置１０２に、グラフィクスアクセレータを追加するのが望ましい。 他にも、浮動小数点演算を行うコプロセッサ（Ｆｌｏａｔｉｎｇ Ｐｏｉｎｔｅｄ ＣｏＰｒｏｃｅｓｓｏｒ）が実装されていてもよい。

（デジタル信用証明書を検証する時期）
上記実施形態では、ＢＤ−Ｊアプリケーションからのベンチマークスコアアクセスが要求された場合に、デジタル信用証明書を解析検証するとしたが、このデジタル信用証明書の検証は、ＢＤ−Ｊアプリケーションの起動時やファームウェア２２の起動時などのタイミングで予め行ってもよい。

（受領者組織の適用範囲）
受領者組織は、ＢＤ−ＲＯＭなどのサービスアプリケーションを含むコンテンツを製作した製作者であると仮定して説明を行ったが、コンテンツ製作者とは独立して、当該ベンチマークスコアアクセスを実施するＢＤ−Ｊアプリケーションに対する署名を実施する組織であれば、どのような組織でもよい。この場合の受領者組織ＩＤは、その組織を示すＩＤ番号となる。このように、実際にコンテンツ製作をする組織と独立した組織を受領者組織として運用できることは明らかである。

（機器の適用範囲）
これまでの説明は、ファームウェア起動部３１、ファームウェア更新部３２、ベンチマークスコア設定部３４を、ＢＤ−ＲＯＭの再生を行う再生装置１０２に適用した場合について説明したが、かかる技術的事項の適用範囲は、そのようなＢＤ−ＲＯＭ再生装置１０２に限らない。例えば、録画機能を持つ再生装置１０２であっても良い。そのときベンチマークスコア情報は再生機能とそのほかの機能と共有されてもよい。例えば、再生機能を具備したパソコンに、ファームウェア起動部３１、ファームウェア更新部３２、ベンチマークスコア設定部３４を適用する場合、ウェブブラウザやワードプロセッサが利用されている状態でのベンチマークスコア情報をファームウェア２２に組み込んでおいてもよい。

（ＢＤ−Ｊアプリケーション供給の仕方）
上述したようなベンチマークスコアの組込み及び書き込みは、映像再生と、ＢＤ−Ｊアプリケーションの実行を関連付けさせて視聴を行なわせる機器であれば、一般のどのような機器に対しても適用可能である。例えば、ＢＤ−Ｊアプリケーションが、放送波やネットワークストリームに組み込まれて、供給されるような再生装置１０２においても、適用が可能となる。 （プログラム記述言語の適用範囲）
上記実施形態では、オブジェクト指向プログラミング言語としてＪａｖａ（ＴＭ）言語を利用したが、Ｊａｖａ（ＴＭ）ではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔ、ＥＣＭＡ Ｓｃｒｉｐｔなど他のプログラミング言語であっても良い。

（ベンチマークスコアの置き場所）
ＢＤ−Ｊアプリケーションからのアクセスを考慮したため、上記実施形態では、ベンチマークスコアはアプリケーションデータ領域に配置されたが、ベンチマークスコアを保持するための記録装置の物理的な実施形態は任意のものであってよく、ハードディスクやフラッシュメモリのような不揮発性の記憶装置であっても、ＤＲＡＭ１５のような揮発性の記憶装置であってもよい。

（ベンチマークスコアの利用主体）
ベンチマークスコアを利用するベンチマークアプリケーション２９は、ＢＤ−ＲＯＭではなく、ＷＷＷサーバからダウンロードされて、再生装置１０２内のローカルストレージに書き込まれたものであってもよい。かかるダウンロードにおいて、ＢＤ．ＲＯＯＴ．ＣＥＲＴＩＦＩＣＡＴＥに収録され、ディスクルート証明書として書き込まれているルート証明書と同一性をもつルート証明書を、ＳＩＧ−ＢＤ．ＳＦに格納してＪａｖａ（登録商標）アーカイブファイルに包含させる。こうすることで、Ｊａｖａ（登録商標）アーカイブファイルを、ダウンロードにて再生装置１０２に供給する場合も、ＢＤ−ＲＯＭに割り当てたディスクルート証明書を用いることにより、Ｊａｖａ（登録商標）アーカイブファイルの正当性を再生装置１０２に確認させることができる。

（ＢＤ−ＲＯＭコンテンツ）
ＢＤ−ＲＯＭに記録されるＢＤ−Ｊアプリケーションは、映画作品を構成するものであるとしたが、ローカルストレージにインストールして利用されるアプリケーションではなく、ＢＤ−ＲＯＭに記録された状態で利用されるアプリケーションであるなら、これ以外のものを構成するものであってもよい。例えば、ゲームソフトを構成するアプリケーションであってもよい。また、本実施形態ではディスク媒体として、ＢＤ−ＲＯＭを題材に選んだが、可搬体であり、著作権保護がなされた記録媒体であるなら、他の記録媒体を採用してもよい。

またＡＶストリーム、プレイリスト情報は、プリレコーディング技術にて、ＢＤ−ＲＯＭに記録され、ユーザに供給されることを前提としたが、リアルタイムレコーディング技術にてＢＤ−ＲＥに記録され、ユーザに供給されるものであってもよい。
この場合ＡＶストリームは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。

リアルタイムレコーディングにあたって記録装置は、ＡＶストリームの記録と共に、メモリ上でＣｌｉｐ情報やプレイリスト情報を生成する処理を行うが、この際、上述した各実施形態に記載したＣｌｉｐ情報、プレイリスト情報をメモリ上で生成する。そしてＡＶストリームの記録を終えた後、生成されたＣｌｉｐ情報、プレイリスト情報を記録媒体に書き込む。こうすることで、オーサリングシステムを用いずとも、家庭用の記録装置や、記録装置としての機能を具備したパーソナルコンピュータにて、各実施形態に示したＣｌｉｐ情報、プレイリスト情報を作成することができる。そうして作成されたＡＶストリーム、Ｃｌｉｐ情報、プレイリスト情報を、ライトワンス型の記録媒体に書き込んでもよい。

（ベンチマークスコアとして示される時間）
サービスアプリケーションが、クライアントプログラムであり、ネットワーク上のサーバ装置に対して、処理を要求する場合、ベンチマークスコアは、処理を要求してから、処理が完了し、応答が返るまでのターンアラウンド時間を表現することが望ましい。上述したような、サーバ装置に対する処理は、クライアント側のプロトコルスタックにおけるオーバーヘッドと、サーバ装置側のプロトコルスタックにおけるオーバーヘッドとが発生し、これらによってターンアラウンド時間は変動を受ける。このように、クライアント側、サーバ側で、プロトコルスタックにおけるオーバーヘッドが発生する場合、このオーバーヘッドを加味したベンチマークスコアを、ファームウェア２２に組み込んでおき、アプリケーションデータ領域に書き込むことで、サービスアプリケーションは、ネットワークにおけるトラフィックの大小に応じた、処理負荷調整を実現することができる。

ここで、プロトコルスタックは、プロトコルにおけるそれぞれのレイヤで独自のバッファをもち、上位から渡されたパケットを自レイヤにコピーして、当該レイヤ固有のデータを付加する処理で実現される。かかるプロトコルスタックには、Ｓｏｃｋｅｔ，ＴＣＰ／ＵＤＰ，ＩＰ，Ｅｔｈｅｒｎｅｔ（登録商標）（ＩＥＥＥ８０２．３）からなるものやＳＰＸ／ＩＰＸ，トークンリング（ＩＥＥＥ８０２．５） からなるもの、ＮｅｔＢＥＵＩ，ＦＤＤＩ／ＴＰＤＤＩ（ＡＮＳＩ Ｘ３Ｔ９．５）からなるものがある。これらのプロトコルスタックを通じて、ネットワークファイルシステム情報を取得することで、サービスアプリケーションは、ネットワーク上のドライブを、自機のローカルなドライブと同様にアクセスすることができる。

（ベンチマークスコアのバリエーション）
ベンチマークスコアは、ベンチマークアプリケーション２９が計測するものに限らず、再生装置１０２の標準プレーヤモデルから、導きだすことができる値を、採用してもよい。再生装置１０２の標準プレーヤモデルでは、ＢＤ−ＲＯＭからバッファへとＴＳパケットを転送するための転送レートが詳細に記述されているため、ベンチマークスコアの中には、それら規定済みの転送レートが一意に導き出せるものも多いからである。

またベンチマークスコアに、マニファクチャ固有のもの、製品固有のもの、規格標準のものという複数のクラスを設け、これらのクラス毎に、ベンチマークスコアをサービスアプリケーションに利用させてもよい。
（ベンチマークスコアの書き込み時期）
再生装置１０２に電源が投入され、ファームウェア２２が起動した際、その起動毎に、ファームウェア２２に組み込まれたベンチマークスコアをアプリケーションデータ領域に書き込んでもよい。こうすることで、アプリケーションデータ領域には確実にベンチマークスコアが存在するという確実性を保証することができる。ベンチマークスコア書き込みの頻度は高いが、それでもアプリケーション起動の度にベンチマークを実行するよりは、サービスアプリケーションのスターティングディレイは短い。

（ハッシュ値）
各実施形態におけるハッシュ値とはＳＨＡ−１やＭＤ５などのセキュアハッシュ関数を利用した結果の値である。セキュアハッシュ関数は、同じハッシュ値を持つ異なるデータを見つけるのは実質不可能であるという特徴を持っている。
（ルート証明書のハッシュ値）
各実施形態におけるルート証明書のハッシュ値とは、必ずしもルート証明書全体のデータから算出する必要はなく、少なくともルート証明書の中に含まれる公開鍵のデータのみから算出することにしてもよい。ＭＡＮＩＦＥＳＴ．ＭＦ、ＳＩＧ−ＢＤ．ＳＦ、ＳＩＧ−ＢＤ．ＲＳＡの中に格納されるハッシュ値の計算に利用されるセキュアハッシュ関数はディスク作成者が明示的に選択できる。

各実施形態ではｂｄ．ＸＸＸＸ．ｐｅｒｍの中にあるデジタル信用証明書には提供者ルート証明書のハッシュ値５１および受領者ルート証明書のハッシュ値５３の計算に利用されるセキュアハッシュ関数が固定されていることを接続相手にしているが、ｂｄ．ＸＸＸＸ．ｐｅｒｍの中にあるデジタル信用証明書の中に、提供者ルート証明書のハッシュ値５１および受領者ルート証明書のハッシュ値５３の計算に利用されるセキュアハッシュ関数を明示するようにしても良い。

（ルート証明書の比較）
ルート証明書の比較は、ルート証明書が同じとあるかどうかの比較、ルート証明書の中に含まれる公開鍵が同じであるかどうかの比較を行うようにしても良い。また別の方式としては、ＳＩＧ−ＢＤ．ＲＳＡの中にある一つ目の証明書（ルート証明書）を無視し、ルート証明書に続く二つ目の証明書がディスクルート証明書により署名されているかどうかを確認するようにしてもよい。どの方式を使ってもディスクルート証明書がＳＩＧ−ＢＤ．ＲＳＡの中の二つ目の証明書を保障していることになるためセキュリティ観点での効果が同じである。

アプリケーション間通信を悪用した攻撃は以下のとおりに作られた攻撃用ＢＤ−ＲＯＭを利用し試みることが考えられる。
１．攻撃対象のディスク作成者により作成された正当なＢＤ−ＲＯＭから、デジタル証明書により署名されている攻撃対象のＪａｖａ（登録商標）アーカイブファイルを読み取る
２．攻撃するためのＪａｖａ（登録商標）アーカイブファイルを作成し、デジタル証明書により署名を行う
３．攻撃対象のＪａｖａ（登録商標）アーカイブファイルと攻撃するためのＪａｖａ（登録商標）アーカイブファイルを攻撃用ＢＤ−ＲＯＭに記録する。

攻撃するためのＪａｖａ（登録商標）アーカイブファイルと攻撃対象のＪａｖａ（登録商標）アーカイブファイルはともにデジタル証明書により署名されているが、どちらも異なるルート証明書を利用する。再生装置１０２において二つのＪａｖａ（登録商標）アーカイブファイルにあるＢＤ−Ｊアプリケーションに対してアプリ間通信のパーミッションが与えられれば、攻撃するためのＪａｖａ（登録商標）アーカイブファイルが攻撃対象のＪａｖａ（登録商標）アーカイブファイルに対して不正なアプリ間通信を行うことが可能になり、攻撃対象のＪａｖａ（登録商標）アーカイブファイルは自身で利用する記憶領域に対して攻撃対象のディスク作成者により予期しない動作がされる。

上記の攻撃を防止するためにルート証明書の比較が必要である。尚、異なるルート証明書を利用するＢＤ−Ｊアプリケーション同士のアプリ間通信を防止するようにしてもよい。そのとき、一つのＢＤ−ＲＯＭに複数のディスクルート証明書を持つようにしてもよい。
（ベンチマークスコアの時間精度）
またベンチマークスコアは、処理を要求してから、処理が完了し、応答が返るまでのターンアラウンド時間を２７ＭＨｚの時間精度で表現してもよい。何故なら、ＡＶストリームを構成するＴＳパケットのそれぞれには、２７ＭＨｚの時間ＡＴＣをもつＡＴＳ（Ａｒｒｉｖａｌ ＴＩｍｅ Ｓｔａｍｐ）が付与されており、再生装置１０２の内部は、１／２７，０００，０００秒という時間精度で、動作を行うＡＴＣ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋ）が存在する。そうしたＡＴＣの時間精度で、ベンチマークスコアを作成しておけば、サービスアプリケーションは、ＡＴＳに対する処理と同期するように、処理負荷の変化を実行することができるからである。

（バッファの実装）
各実施形態に示したバッファは、ＤＰＲＡＭで実現することが望ましい。ＤＰＲＡＭ（Ｄｕａｌ Ｐｏｒｔ ＲＡＭ）は、入出力インターフェイスを２系統もち、何れの側からもデータの読み書きをすることができるメモリである。ＤＰＲＡＭでは、データの矛盾を避けるよう、ハードウェアによって排他制御がなされる。ベンチマークスコアの測定にあたっては、かかるバッファの書き込み及び読み出しに要する時間を、緻密に評価する必要がある。

（デコーダの実装）
ビデオデコーダ、オーディオデコーダは、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）で構成するのが望ましい。ＤＳＰは、固定小数点型、浮動小数点型のものがあり、バレルシフタ、レジスタ、乗算器、加算器からなる積和演算器を具備している。この積和演算器により、平滑化処理等、デジタル信号処理を高速に行うことができる。圧縮符号化された映像、音声のデコーダには、ＤＣＴ係数を用いた浮動小数点演算が必要になるので、かかるＤＳＰをデコーダとして採用すれば、ＡＶ再生をリアルタイムに実現することができる。ベンチマークスコアの測定にあたっては、かかるデコーダが演算を行うのに要する時間を、緻密に評価する必要がある。

（システムＬＳＩ化）
図７に示した再生装置１０２を構成するハードウェアのうち、機構的な構成要素（ＢＤドライブ１、ＨＤドライブ１３、カードドライブ１４）、大容量のメモリによって実装される構成要素（ビデオ用のプレーンメモリ５、プレーンメモリ８）を除いた、論理素子を主要部とする部分を、１つのシステムＬＳＩとして構成することが望ましい。何故なら、論理素子を主要部とする部分は、高密度に集積化することができるからである。図７では、１つのシステムＬＳＩとして構成すべき部分を枠内に囲んでいる。但し、この図７のシステムＬＳＩ化は、一例であって、エレメンタバッファ７やビデオデコーダ４、オーディオデコーダ４、グラフィクスデコーダ６をも、一体のシステムＬＳＩにしてもよい。

システムＬＳＩとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも１つのＬＳＩのような外形構造を複数個のベアチップに持たせたものも、システムＬＳＩに含まれる（このようなシステムＬＳＩは、マルチチップモジュールと呼ばれる。）。

ここでパッケージの種別に着目するとシステムＬＳＩには、ＱＦＰ（クッド フラッド アレイ）、ＰＧＡ（ピン グリッド アレイ）という種別がある。ＱＦＰは、パッケージの四側面にピンが取り付けられたシステムＬＳＩである。ＰＧＡは、底面全体に、多くのピンが取り付けられたシステムＬＳＩである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムＬＳＩにおけるピンには、こうしたインターフェイスの役割が存在するので、システムＬＳＩにおけるこれらのピンに、他の回路を接続することにより、システムＬＳＩは、再生装置１０２の中核としての役割を果たす。

かかるシステムＬＳＩは、再生装置１０２は勿論のこと、ＴＶやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。

エレメンタバッファ７やビデオデコーダ４、オーディオデコーダ４、グラフィクスデコーダ６をも、一体のシステムＬＳＩにする場合、システムＬＳＩのアーキテクチャは、Ｕｎｉｐｈｉｅｒアーキテクチャに準拠させるのが望ましい。

Ｕｎｉｐｈｉｅｒアーキテクチャに準拠したシステムＬＳＩは、以下の回路ブロックから構成される。
・データ並列プロセッサＤＰＰ
これは、複数の要素プロセッサが同一動作するＳＩＭＤ型プロセッサであり、各要素プロセッサに内蔵されている演算器を、１つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。

・命令並列プロセッサＩＰＰ
これは、命令ＲＡＭ、命令キャッシュ、データＲＡＭ、データキャッシュからなる「Ｌｏｃａｌ Ｍｅｍｏｒｙ Ｃｏｎｔｏｒｏｌｌｅｒ」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ部」、複数アプリケーションの並列実行をＰｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ部に行わせる「Ｖｉｒｔｕａｌ Ｍｕｌｔｉ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ部」で構成される。

・ＭＰＵブロック
これは、ＡＲＭコア、外部バスインターフェイス（Ｂｕｓ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：ＢＣＵ）、ＤＭＡコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、ＵＡＲＴ、ＧＰＩＯ（Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ Ｏｕｔｐｕｔ）、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。各実施形態で述べたファームウェア２２は、このＭＰＵブロックとしてシステムＬＳＩに実装される。

・ストリームＩ／Ｏブロック
これは、ＵＳＢインターフェイスやＡＴＡ Ｐａｃｋｅｔインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードディスクドライブ装置、ＳＤメモリカードドライブ装置とのデータ入出力を行う。
・ＡＶＩ／Ｏブロック
これは、オーディオ入出力、ビデオ入出力、ＯＳＤコントローラで構成され、テレビ、ＡＶアンプとのデータ入出力を行う。

・メモリ制御ブロック
これは、外部バスを介して接続されたＳＤ−ＲＡＭの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムＬＳＩ外部に接続されたＳＤ−ＲＡＭとのデータ転送を行うアクセス制御部、各ブロックからのＳＤ−ＲＡＭ１５のアクセス要求を調整するアクセススケジュール部からなる。

具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムＬＳＩとすべき部分の回路図を作成し、回路素子やＩＣ，ＬＳＩを用いて、構成図における構成要素を具現化する。
そうして、各構成要素を具現化してゆけば、回路素子やＩＣ，ＬＳＩ間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、ＬＳＩのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。

回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品（回路素子やＩＣ，ＬＳＩ）を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をＣＡＭデータに変換して、ＮＣ工作機械等の設備に出力する。ＮＣ工作機械は、このＣＡＭデータを基に、ＳｏＣ実装やＳｉＰ実装を行う。ＳｏＣ（Ｓｙｓｔｅｍ ｏｎ ｃｈｉｐ）実装とは、１チップ上に複数の回路を焼き付ける技術である。ＳｉＰ（Ｓｙｓｔｅｍ ｉｎ Ｐａｃｋａｇｅ）実装とは、複数チップを樹脂等で１パッケージにする技術である。以上の過程を経て、本発明に係るシステムＬＳＩは、各実施形態に示した再生装置１０２の内部構成図を基に作ることができる。

尚、上述のようにして生成される集積回路は、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
ＦＰＧＡを用いてシステムＬＳＩを実現した場合は、多数のロジックエレメントが格子状に配置されており、ＬＵＴ（Ｌｏｏｋ Ｕｐ Ｔａｂｌｅ）に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。ＬＵＴは、ＳＲＡＭに記憶されており、かかるＳＲＡＭの内容は、電源断により消滅するので、かかるＦＰＧＡの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するＬＵＴを、ＳＲＡＭに書き込むませる必要がある。

（プレーンメモリの実装）
プレーンメモリは、多大なメモリ容量を必要とするので、システムＬＳＩに内蔵されているＳＲＡＭで実現するのは、望ましくない。外付けのＳＤＲＡＭで実現するのが望ましい。またプレーンメモリが複数存在する場合は、バンクメモリ方式を採用し、ＭＰＵにおけるメモリ空間の一部に、これらをマッピングすることの良策である。ベンチマークスコアの測定にあたっては、かかるプレーンメモリからの読み出しや、書き込みに要する時間を、緻密に評価する必要がある。

（ＡＶ再生の対象）
ＡＶ再生の対象は、デジタルストリーム、マップ情報、プレイリスト情報から構成されるコンテンツであるなら、ＢＤ−ＲＯＭに規定されたものに限らない。デジタルストリームは、ＭＰＥＧ２，ＭＰＥＧ４−ＡＶＣ等の符号化方式で符号化されたビデオストリーム、オーディオストリームを多重化することで、得られた多重化ストリームであり、ＤＶＤ Ｖｉｄｅｏ−Ｒｅｃｏｒｄｉｎｇ規格ではＶＯＢと呼ばれる。

マップ情報は、上述したビデオストリームにおけるアクセスユニット（独立復号可能な再生単位をいう）のアドレス情報と、ビデオストリームの再生時間軸における再生時刻との対応を示す情報であり、ＤＶＤ Ｖｉｄｅｏ−Ｒｅｃｏｒｄｉｎｇ規格ではＴｉｍｅ Ｍａｐと呼ばれる。
プレイリスト情報は、開始点たる時刻情報と、終了点たる時刻情報との組みにより、１つ以上の再生区間を定義する情報である。

再生装置１０２をマルチディスク対応機として開発する場合、ベンチマークスコアの測定にあたっては、かかるＶＯＢをＤＶＤ−Ｖｉｄｅｏから読み出して、デコードするのに要する時間を、緻密に評価してもよい。そして、ＤＶＤ−Ｖｉｄｅｏの再生におけるベンチマークスコアを、ファームウェアに組込んでおいてもよい。

本発明に係る再生装置は、各実施形態に示した内部構成を用いて工業的に生産することができるので、製造産業において利用される可能性がある。

１００ ＢＤ−ＲＯＭ
１０１ ＷＷＷサーバ
１０２ 再生装置
１０３ テレビ
１０４ リムーバブルメディア
１０５ 開発用コンピュータ
２１ ブートローダ
２２ ファームウェア
２３ 仮想ファイルシステム
２４ アクセス制御機構
２５ 再生エンジン
２６ 再生制御エンジン
２７ ＢＤ−Ｊモジュール
２８ システムアプリケーション
２９ ベンチマークアプリケーション
３１ ファームウェア起動部
３２ ファームウェア更新部
３３ アプリケーションマネージャ
３４ ベンチマークスコア設定部

Claims (15)

1. 再生装置であって、
   記録媒体からデータを読み出すドライブ部、前記読み出したデータに含まれるＡＶデータを再生する再生部、プログラムを実行する処理部と、を具備したハードウェア部と、
   前記ハードウェア部を制御するファームウェアプログラムと、
   前記処理部が前記ファームウェアプログラムを実行する場合、所定の条件を満足すれば、初期化処理を行う初期化部と
   所定の記録領域を有する記録部を備え、
   前記ファームウェアプログラムには、ベンチマークスコアが組み込まれており、
   前記ベンチマークスコアは、前記ドライブ部によって前記記録媒体から読み出されたベンチマークプログラムを前記処理部により実行したとき、前記実行されるベンチマークプログラムからの命令に従って、前記処理部によって実行されるファームウェアプログラムを介して前記ハードウェア部に所定の処理を行わせた結果であって、前記再生装置の処理能力を示す指標であり、
   前記初期部は、前記処理部が前記ファームウェアプログラムを最初に実行する場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定の記録領域に書き込むことにより前記記録領域に書き込んだベンチマークスコアを前記処理部により実行されるアプリケーションプログラムがアクセスできるようにした、
   ことを特徴とする再生装置。
2. 前記ファームウェアプログラムが更新され、前記処理部が前記更新されたファームウェアプログラムを最初に実行する場合、
   前記初期化部は前記更新されたファームウェアプログラムに組み込まれたベンチマークスコアを前記記録部における所定の記録領域に書き込むことを特徴とする請求項１記載の再生装置。
3. 前記記録領域に書き込んだベンチマークスコアに前記処理部により実行されるアプリケーションプログラムがアクセスする場合、前記アプリケーションプログラムに対応する信用証明書であって、前記アプリケーションプログラムが前記記録領域に書き込んだベンチマークスコアへのアクセス権限に対する情報を含んだ信用証明書の有効性を判断し、前記有効であると判断された信用証明書に含まれる前記ベンチマークスコアへのアクセス権限に対する情報に基づいて、前記アプリケーションプログラムが前記記録領域に書き込んだベンチマークスコアにアクセス可能か否かを判定する判定部を備えたことを特徴とする請求項２記載の再生装置。
4. 前記記録部における所定の記録領域は、前記ベンチマークプログラムを提供した組織を識別する識別子と、前記ベンチマークアプリケーションを識別する識別子とを含んだファイルパスを用いて特定されることを特徴とする請求項３記載の再生装置。
5. 前記ファームウェアプログラムは前記アプリケーションプログラムから前記記録領域に書き込んだベンチマークスコアへのアクセス要求に対し、前記記録領域に書き込んだベンチメークスコアをアクセス要求したアプリケーションプログラムへ返すＩ／Ｏプログラムを含み、
   前記アプリケーションプログラムが前記ベンチマークスコアへのファイルパスを指定して、前記ベンチマークスコアへのアクセスを要求したとき、
   前記処理部は前記Ｉ／Ｏプログラムを実行し、前記Ｉ／Ｏプログラムは指定されたファイルパスに基づいて特定されるベンチマークスコアを、前記アプリケーションプログラムへ返すように構成したことを特徴とする請求項４に記載の再生装置。
6. 前記処理部は前記ファームウェアプログラムを格納するための第１の記録領域を有する第１の記録部、前記第１の記録部に格納されたファームウェアプログラムおよび実行対象のアプリケーションプログラムをロードするための第２の記録領域を有する第２の記録部、前記第２の記録領域にロードされたファームウェアプログラムおよびアプリケーションプログラムを実行する処理部本体を備えたことを特徴とする請求項５に記載の再生装置。
7. 前記第２の記録領域に前記ファームウェアプログラムに組み込んだベンチマークスコアを展開した場合、
   前記ベンチマークスコアを本来書き込むべき位置を示す前記記録部におけるファイルパスに関する情報と前記ベンチマークスコアを展開した前記第２の記録領域上の位置に関する情報とを含んだ位置情報を生成し、
   前記Ｉ／Ｏプログラムは前記アプリケーションプログラムから指定されたファイルパスを受け取ると、前記位置情報を参照し、前記第２の記録領域に展開したベンチマークスコアを読み込んで前記アプリケーションプログラムへ返すように構成したことを特徴とする請求項６記載の再生装置。
8. 前記処理部は前記ファームウェアプログラムを格納するための第１の記録領域を有する第１の記録部、実行対象のアプリケーションプログラムをロードするための第２の記録領域を有する第２の記録部、前記第１の記録領域に格納されたファームウェアプログラムおよび前記第２の記録領域にアプリケーションプログラムを実行する処理部本体を備えたことを特徴とする請求項５に記載の再生装置。
9. 前記信用証明書は前記ベンチマークスコアへのファイルパスに関する情報を含む、請求項５に記載の再生装置。
10. 前記アプリケーションは、さらに、前記信用証明書に対して所定の処理を行うことによって得られた署名情報を保持し、
    前記判定手段は、前記アプリケーションが前記ベンチマークスコアにアクセスしようとする場合に、前記アプリケーションが保持している信用証明書と署名情報を用いて、前記アプリケーションが前記ベンチマークスコアにアクセス可能か否かを判定することを特徴とする請求項３記載の再生装置。
11. 前記初期化部は、前記記録部における所定のパスによって定められる記録領域に前記ベンチマークスコアが書き込まれているか否かの判定を行い、前記ベンチマークスコアが書き込まれていないと判定した場合に、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定のパスによって定められる記録領域に書き込むことを特徴とする請求項４記載の再生装置。
12. 前記初期化部は、前記ファームウェアプログラムが更新された場合に、前記更新されたファームウェアプログラムに組み込まれているベンチマークスコアのバージョンと前記アプリケーションデータ領域に存在するベンチマークスコアのバージョンとのバージョン比較を行って、前記更新されたファームウェアプログラムに組み込まれたベンチマークスコアの方が新しいと判定した場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、記記録部における所定のパスによって定められる記録領域に書き込むことを特徴とする請求項４記載の再生装置。
13. 前記ベンチマークスコアをメモリに展開して、メモリ上のベンチマークスコアを、アプリケーションに利用させることを特徴とする請求項３記載の再生装置。
14. 記録媒体からデータを読み出すドライブ部、前記読み出したデータに含まれるＡＶデータを再生する再生部、を具備したハードウェア部と、所定の記録領域を有する記録部を備えた再生装置に用いる集積回路であって、
    前記集積回路は、
    プログラムを実行する処理部と、
    前記ハードウェア部を制御するファームウェアプログラムと、
    前記処理部が前記ファームウェアプログラムを実行する場合、所定の条件を満足すれば、初期化処理を行う初期化部とを備え、
    前記ファームウェアプログラムには、ベンチマークスコアが組み込まれており、
    前記ベンチマークスコアは、前記ドライブ部によって前記記録媒体から読み出されたベンチマークプログラムを前記処理部により実行したとき、前記実行されるベンチマークプログラムからの命令に従って、前記処理部によって実行されるファームウェアプログラムを介して前記ハードウェア部に所定の処理を行わせた結果であって、前記再生装置の処理能力を示す指標であり、
    前記初期部は、前記処理部が前記ファームウェアプログラムを最初に実行する場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定の記録領域に書き込むことにより前記記録領域に書き込んだベンチマークスコアを前記処理部により実行されるアプリケーションプログラムがアクセスできるようにした、
    ことを特徴とする集積回路。
15. 記録媒体からデータを読み出すドライブ部、前記読み出したデータに含まれるＡＶデータを再生する再生部、プログラムを実行する処理部と、を具備したハードウェア部と、
    前記ハードウェア部を制御するファームウェアプログラムと、
    所定の記録領域を有する記録部を備え、
    前記ドライブ部によって前記記録媒体から読み出されたベンチマークプログラムを前記処理部により実行したとき、前記実行されるベンチマークプログラムからの命令に従って、前記処理部によって実行されるファームウェアプログラムを介して前記ハードウェア部に所定の処理を行わせた結果であって、前記再生装置の処理能力を示す指標であるベンチマークスコアが前記ファームウェアプログラムに組み込まれた再生装置における再生方法であって、
    前記処理部が前記ファームウェアプログラムを最初に実行する場合、前記ファームウェアプログラムに組み込まれているベンチマークスコアを、前記記録部における所定の記録領域に書き込むステップ、
    前記記録領域に書き込んだベンチマークスコアを前記処理部により実行されるアプリケーションプログラムにアクセスさせるステップを含む
    ことを特徴とする再生方法。

Images