(57)【要約】フォーマットエンジンの追加や変更に容易に対応することができる情報処理装置を提供する。情報処理装置は、フォーマットエンジン管理手段と、動作制御手段とを備えている。フォーマットエンジン管理手段は、フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理する。動作制御手段は、各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する。
2004034698.tif 000002
【特許請求の範囲】
【請求項１】
異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを複数格納している情報処理装置であって、
各フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、
各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段とを備え、
前記フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信し、
前記動作制御手段は、前記フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する、情報処理装置。
【請求項２】
各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態と、当該個別状態に対応する共通状態との組によって構成されるテーブル格納するテーブル格納手段をさらに備え、
前記動作制御手段は、前記テーブルを参照することによって共通状態から個別状態を決定する、請求項１に記載の情報処理装置。
【請求項３】
各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態を取得し、取得した個別状態に対応する共通状態を示す共通状態情報を前記フォーマットエンジン管理手段へ送信する個別状態取得手段をさらに備え、
前記フォーマットエンジン管理手段は、前記個別状態取得手段から出力された共通状態情報により示される共通状態に基づいて、各フォーマットエンジンの動作を管理する、請求項１に記載の情報処理装置。
【請求項４】
フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースをさらに備え、
前記個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用している動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態を示す共通状態情報を前記フォーマットエンジン管理手段へ出力するとともに、フォーマットエンジンから取得した個別状態が極小リソースを利用していない動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、前記所定の状態以外の状態を示す共通状態情報を前記フォーマットエンジン管理手段へ出力し、
前記フォーマットエンジン管理手段は、共通状態情報が前記所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理する、請求項３に記載の情報処理装置。
【請求項５】
前記フォーマットエンジン管理手段は、
フォーマットエンジンを起動するための起動要求を受け付ける起動受付手段と、
前記起動受付手段が起動要求を受け付けたことに応じて、前記状態取得手段から各フォーマットエンジンの共通状態情報を取得する共通状態取得手段と、
前記共通状態取得手段によって取得された共通状態情報が実行中を示すフォーマットエンジンがある場合、当該フォーマットエンジンの動作を停止させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する動作停止手段と、
前記動作停止手段によってフォーマットエンジンの動作が停止された後、起動要求に対応するフォーマットエンジンを起動させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する起動手段とを含む、請求項４に記載の情報処理装置。
【請求項６】
フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースと、
フォーマットエンジンの要求に応じてフォーマットエンジンに対してリソースの利用を許可するリソース制御手段と、
極小リソースを利用する場合における各フォーマットエンジン間の優先度を示す優先度情報を格納する優先度情報格納手段と、
極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、前記優先度情報に基づいて、当該極小リソースの利用を許可すべきフォーマットエンジンを決定する許可決定手段とをさらに備え、
前記リソース制御手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、前記許可決定手段によって決定されたフォーマットエンジンのみに当該極小リソースの利用を許可し、極小リソースを利用する要求が複数のフォーマットエンジン間で重複しない場合、当該要求を行ったフォーマットエンジンに当該極小リソースの利用を許可する、請求項１に記載の情報処理装置。
【請求項７】
前記極小リソースは複数設けられ、
前記リソース制御手段は前記極小リソースに対応して複数設けられる、請求項６に記載の情報処理装置。
【請求項８】
異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置のコンピュータで実行可能なプログラムであって、
前記コンピュータを、
フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、
各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段として機能させ、
前記フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信し、
前記動作制御手段は、前記フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する、プログラム。
【発明の詳細な説明】
【技術分野】  本発明は、情報処理装置に関し、より特定的には、ＪａｖａやＨＴＭＬ等の特定のフォーマットで記述されたアプリケーションを実行するフォーマットエンジンの動作を管理する情報処理装置に関する。
【背景技術】  近年、デジタルテレビ、携帯情報端末、携帯電話といった情報処理装置において、ＪａｖａプログラムやＨＴＭＬコンテンツ等の特定のフォーマットで記述されたアプリケーションを実行することが盛んに行われている。ここで、このようなアプリケーションの実行やデータの再生を行うためのソフトウェアをフォーマットエンジンと呼ぶ。フォーマットエンジンとは、例えば、上記Ｊａｖａプログラムを実行するためのＪａｖａミドルウェアやＨＴＭＬコンテンツを表示するためのブラウザである。これらのフォーマットエンジンの他にも、現在パーソナルコンピュータ上で実行されているＰＤＦデータや音楽データ等を再生するためのフォーマットエンジンも、上記デジタルテレビ等において実行されるようになるであろう。
一般的に、上記デジタルテレビ等の情報処理装置に格納されているフォーマットエンジンは１つである。図９４は、従来のデジタル放送受信機の構成図の一例である。このデジタル放送受信機は、放送データに含まれるアプリケーション（Ｊａｖａプログラム）を実行し、管理するものである。図９４において、デジタル放送受信機９４０２は、テレビモニタ９４０１に接続されている。また、デジタル放送受信機９４０２は、ディスプレイマネージャ９４１１と、アプリケーションマネージャ９４１２と、ルール９４１４と、信号モニタ９４１３とを備えている。
図９４において、デジタル放送受信機９４０２の信号モニタ９４１３は、放送データストリームを受信する。信号モニタ９４１３は、放送データストリームに含まれるアプリケーションが含まれるか否かを判断し、アプリケーションの有無を示す信号データをアプリーケーションマネージャ９４１２へ出力する。アプリケーションマネージャ９４１２は、入力される信号データに基づいて、放送データストリームにアプリケーションが含まれるか否かを判断する。そして、放送データストリームにアプリケーションが含まれる場合、アプリケーションマネージャ９４１２は、当該アプリケーションをアプリケーションを読み込み実行する。アプリケーションが実行されると、テレビモニタに表示されるべきディスプレイ情報がディスプレイコンテキストとしてディスプレイマネージャ９４１１へ提供される。ディスプレイマネージャ９４１１は、適切なディスプレイ情報をテレビモニタ９４０１に提供する。ここで、アプリケーションマネージャ９４１２は、ルール９４１４に従って動作し、各アプリケーションの状態をロード状態、一時停止状態、アクティブ状態、および抹消状態のいずれかに遷移させる。ルールは、例えば、「１度に１つのアプリケーションのみをアクティブ状態にする」や、「１度に１つのアプリケーションのみを表示できる」等である。デジタル放送受信機９４０２は、このようなルールを用いることによって複数のアプリケーションを管理することができる。
一方、デジタルテレビ、携帯情報端末、携帯電話といった情報処理装置が複数のフォーマットエンジンを備える場合、それら複数のフォーマットエンジンを管理する技術も考えられている。このようなデジタルテレビ、携帯情報端末、携帯電話といった情報処理装置では、ＣＰＵに比べるとフォーマットエンジンを実行する際に用いられるリソースが限られているという側面がある。リソースとは、例えばメモリのように、フォーマットエンジンによって利用されるハードウェアをいう。例えば、デジタルテレビが有するリソースには、メモリの他、放送波を受信しデータを復号するためのチューナ、放送波に含まれる映像や音声をデコードするためのデコーダ、インターネットに接続するためのネットワークインターフェース等がある。フォーマットエンジンを実行する際には、実行されるフォーマットエンジンが利用するリソースを確保する必要があるので、上記のようなリソースが限られた情報処理装置においては、各フォーマットエンジンの実行を管理することが行われている。例えば、デジタルテレビでは、各フォーマットエンジンを切り替えて実行する処理を行うものがある。以下、従来のデジタルテレビにおいて複数のフォーマットエンジンを管理する技術を説明する。
図９５は、従来のデジタルテレビにおいて用いられるミドルウェア切替装置の構成図の一例である。このミドルウェア切替装置は、複数のミドルウェア（フォーマットエンジン）を切り替えて実行する。図９５において、ミドルウェア切替装置は、ミドルウェア決定部９５０１と、ミドルウェア読込部９５０２と、ミドルウェア実行部９５０３と、ミドルウェア格納部９５０４とを備えている。
図９５において、ミドルウェア格納部９５０４は、第１〜第ｎのミドルウェアを格納している。ミドルウェア決定部９５０１は、第１〜第ｎのミドルウェアの内、実行すべきミドルウェアを決定する。ミドルウェア読込部９５０２は、ミドルウェア決定部９５０１によって決定されたミドルウェアをミドルウェア格納部９５０４から読み込む。ミドルウェア実行部９５０３は、ミドルウェア読込部９５０２が読み込んだミドルウェアを実行する。以上の構成によって、第１〜第ｎのミドルウェアは切り替えて実行される。これによって、図９５に示す装置は、複数のミドルウェアを１つのデジタルテレビ上に共存させることを可能としている。
【発明の開示】
しかし、図９５に示した構成では、ミドルウェアの追加や変更への対応が困難であった。以下、詳細を説明する。
例えば、図９５に示す装置に新たなミドルウェアを追加する場合を考える。ここで、一般的に、個々のフォーマットエンジンには独自の状態が規定されている。従って、フォーマットエンジンを管理する側（ミドルウェア読込部９５０２やミドルウェア実行部９５０３）は、フォーマットエンジン毎に異なる状態を把握している必要がある。すなわち、新たなミドルウェアが追加される場合、そのミドルウェアにおいて規定されている状態を理解することができるように、ミドルウェア読込部９５０２やミドルウェア実行部９５０３を変更しなければならない。以上より、新たなミドルウェアを追加する場合には、新たなミドルウェアをミドルウェア格納部９５０４に追加することに加えて、新たなミドルウェアに対応するようにミドルウェア読込部９５０２やミドルウェア実行部９５０３を変更しなければならない。従って、図９５に示すミドルウェア管理装置の設計の際にミドルウェアの追加や変更があると、開発者はミドルウェア読込部９５０２やミドルウェア実行部９５０３についても変更作業を行わなければならない。この変更作業は開発者にとって大きな負担になっていた。
それ故、本発明は、フォーマットエンジンの追加や変更に容易に対応することができる情報処理装置を提供することを目的とする。
上記目的を達成するために、本発明は、以下の構成を採用した。すなわち、本発明は、異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置である。当該情報処理装置は、フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段とを備えている。フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。各動作制御手段は、フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する。
また、情報処理装置は、各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態と、当該個別状態に対応する共通状態との組によって構成されるテーブル格納するテーブル格納手段をさらに備えていてもよい。このとき、各動作制御手段は、テーブルを参照することによって共通状態から個別状態を決定する。
また、情報処理装置は、各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態を取得し、取得した個別状態に対応する共通状態を示す共通状態情報をフォーマットエンジン管理手段へ送信する個別状態取得手段をさらに備えていてもよい。このとき、フォーマットエンジン管理手段は、個別状態取得手段から出力された共通状態情報により示される共通状態に基づいて、各フォーマットエンジンの動作を管理する。
また、情報処理装置は、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースをさらに備えていてもよい。このとき、個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用している動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態を示す共通状態情報をフォーマットエンジン管理手段へ出力する。また、個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用していない動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態以外の状態を示す共通状態情報をフォーマットエンジン管理手段へ出力する。フォーマットエンジン管理手段は、共通状態情報が所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理する。
また、フォーマットエンジン管理手段は、起動受付手段と、共通状態取得手段と、動作停止手段と、起動手段とを含んでいてもよい。起動受付手段は、フォーマットエンジンを起動するための起動要求を受け付ける。共通状態取得手段は、起動受付手段が起動要求を受け付けたことに応じて、状態取得手段から各フォーマットエンジンの共通状態情報を取得する。動作停止手段は、共通状態取得手段によって取得された共通状態情報が所定の状態を示すフォーマットエンジンがある場合、当該フォーマットエンジンの動作を停止させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。起動手段は、動作停止手段によってフォーマットエンジンの動作が停止された後、起動要求に対応するフォーマットエンジンを起動させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。
また、情報処理装置は、極小リソースと、リソース制御手段と、優先度情報格納手段とをさらに備えていてもよい。極小リソースは、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである。リソース制御手段は、フォーマットエンジンの要求に応じてフォーマットエンジンに対してリソースの利用を許可する。優先度情報格納手段は、極小リソースを利用する場合における各フォーマットエンジン間の優先度を示す優先度情報を格納する。許可決定手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、優先度情報に基づいて、当該極小リソースの利用を許可すべきフォーマットエンジンを決定する。このとき、リソース制御手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、許可決定手段によって決定されたフォーマットエンジンのみに当該極小リソースの利用を許可し、極小リソースを利用する要求が複数のフォーマットエンジン間で重複しない場合、当該要求を行ったフォーマットエンジンに当該極小リソースの利用を許可する。
また、極小リソースは複数設けられてもよい。このとき、リソース制御手段は極小リソースに対応して複数設けられる。
また、本発明は、異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置のコンピュータで実行可能なプログラムの形態で提供されてもよい。
本発明によれば、フォーマットエンジン管理手段は各フォーマットエンジンの動作状態を共通状態で管理するので、フォーマットエンジンが追加または変更された場合であっても、フォーマットエンジン管理手段の構成を大幅に変更する必要がない。従って、フォーマットエンジンの追加や変更に容易に対応することができる。さらに、フォーマットエンジン管理部から動作制御部への通信は、共通状態情報を含むメッセージによって行われる。従って、フォーマットエンジン管理部は、フォーマットエンジンの違いを意識せずに各フォーマットエンジンの動作状態を管理できるので、複数のフォーマットエンジンの動作を同時に制御することが容易になる。
また、情報処理装置がテーブル格納手段をさらに備えることによって、個別状態と共通状態との相互の変換を容易に行うことができる。
また、さらに、情報処理装置が個別状態取得手段をさらに備えることによって、フォーマットエンジン管理手段は、各フォーマットエンジンの動作状態を容易に取得することができる。
また、さらに、フォーマットエンジン管理手段が、共通状態情報が所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理することによって、次の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、極小リソースの利用が競合しないように、フォーマットエンジンの動作を管理することができる。換言すれば、フォーマットエンジン管理手段は、極小リソースの利用が競合しない範囲で、複数のフォーマットエンジンを同時に実行することも可能である。
また、さらに、フォーマットエンジン管理手段が、起動受付手段と、共通状態取得手段と、動作停止手段と、起動手段とを含んでいる場合には、次の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、起動要求に対応するフォーマットエンジンを確実に起動させることができるとともに、極小リソースの利用が競合しない範囲で、起動中のフォーマットエンジンの実行を継続することができる。
また、さらに、情報処理装置が、極小リソースと、リソース制御手段と、優先度情報格納手段とをさらに備えている場合には、以下の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、極小リソースの利用が競合しないように、フォーマットエンジンの動作を管理することができる。換言すれば、フォーマットエンジン管理手段は、極小リソースの利用が競合しない範囲で、複数のフォーマットエンジンを同時に実行することも可能である。さらに、この場合、互いに異なる複数のフォーマットエンジンは、それぞれ、互いに異なる複数の極小リソースを同時に利用することも可能である。
また、極小リソースが複数設けられている場合には、各フォーマットエンジンは、それぞれ別個の極小リソースを同時に利用することができる。
【図面の簡単な説明】  図１は、本実施の形態に係る情報処理装置の一例であるデジタルテレビのハードウエア構成を表すブロック図である。
図２は、図１に示すデジタルテレビ１００の外観を示す図である。
図３は、入力部１１１を構成するフロントパネルの一例を示す図である。
図４は、第１の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。
図５は、テーブル格納部４４が格納するテーブルの一例を示す図である。
図６は、第２の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。
図７は、情報処理装置の機能的な構成をより具体的に示す図である。
図８は、ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図である。
図９は、ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図である。
図１０は、ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図である。
図１１は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図である。
図１２は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図である。
図１３は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図である。
図１４は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図である。
図１５は、ディスプレイ１０７に表示される、実行可能なＨＴＭＬデータの一覧の例を示す図である。
図１６は、ディスプレイ１０７に表示される、実行可能なＨＴＭＬデータの一覧の例を示す図である。
図１７は、メッセージフォーマットの一例を示す図である。
図１８は、サブプログラムＩＤの表の一例を示す図である。
図１９は、Ｍｅｓｓａｇｅ  ＩＤフィールド１７３に格納されるメッセージＩＤの表の一例を示す図である。
図２０は、フォーマットエンジン状態応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。
図２１は、フォーマットエンジンの動作状態と動作状態ＩＤとの対応を示す表の一例を示す図である。
図２２は、アプリケーション・データ一覧応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。
図２３は、「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」のメッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。
図２４は、「フォーマットエンジン状態要求」メッセージの具体例を示す図である。
図２５は、「フォーマットエンジン状態要求」メッセージの具体例を示す図である。
図２６は、「フォーマットエンジン状態要求」メッセージの具体例を示す図である。
図２７は、「フォーマットエンジン取得応答」メッセージの具体例を示す図である。
図２８は、「フォーマットエンジン取得応答」メッセージの具体例を示す図である。
図２９は、「フォーマットエンジン取得応答」メッセージの具体例を示す図である。
図３０は、アプリケーション・データ一覧要求」メッセージの具体例を示す図である。
図３１は、「アプリケーション・データ取得応答」メッセージの具体例を示す図である。
図３２は、状態管理部７３２が保持している情報の一例を示す図である。
図３３は、状態管理部７３２が保持している情報の一例を示す図である。
図３４は、状態管理部７３２が保持している情報の一例を示す図である。
図３５は、「フォーマットエンジン状態変化」メッセージの一例を示す図である。
図３６は、状態管理部７３２が送信するメッセージの一例を示す図である。
図３７は、メーラー７６０が送信するメッセージの一例を示す図である。
図３８は、図３２の変化後の状態を示す図である。
図３９は、リソース管理部７３３の内部構成を示すブロック図である。
図４０は、プロセス記憶部３９０１において記憶されている情報の一例を示す図である。
図４１は、優先度記憶部３９０２に記憶されている情報の一例を示す図である。
図４２は、最新起動記憶部３９０３が記憶している情報の一例を示す図である。
図４３は、リソースＩＤ記憶部３９０４が記憶している情報の一例を示す図である。
図４４は、リソースＩＤの定義をプログラミング言語であるＣ言語で記述した例を示す図である。
図４５は、Ｊａｖａミドルウェア７４０の構成を示すブロック図である。
図４６は、ＡＩＴの主要部を表した模式図である。
図４７は、Ｊａｖａアプリケーションの４つの動作状態および動作状態間の遷移を表す状態遷移図である。
図４８は、ＡＩＴの主要部を表した模式図である。
図４９は、、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態と、Ｊａｖａミドルウェア７４０の動作状態との対応を示す変換表の一例を示す図である。
図５０は、各Ｊａｖａアプリケーションの動作状態を共通状態に変換するための変換表の一例を示す図である。
図５１は、第１の変換部７４１が送信するメッセージの具体例を示す図である。
図５２は、ＨＴＭＬブラウザ７５０の構成を示すブロック図である。
図５３は、ＤＶＢ−ＨＴＭＬデータの一例を示す図である。
図５４は、ＶＢ−ＨＴＭＬデータのレイアウトを決めるスタイルシートの一例を示す図である。
図５５は、ＤＯＭツリーの例を示す図である。
図５６は、図５５に示すＤＯＭツリーを描画した際のディスプレイ１０７を示す図である。
図５７は、ＤＶＢ−ＨＴＭＬデータの例を示す図である。
図５８は、ＤＶＢ−ＨＴＭＬデータの例を示す図である。
図５９は、図５８に示すＤＶＢ−ＨＴＭＬデータに対してパーザー５２０１が構築したＤＯＭツリーの一部を示す図である。
図６０は、レイアウター５２０２および描画部５２０３によって表示されたディスプレイ表示の例を示す図である。
図６１は、ＤＯＭツリーの変更結果を示す図である。
図６２は、ディスプレイ表示の変更結果の例を示す図である。
図６３は、ＡＩＴの主要部を表した模式図である。
図６４は、ＤＶＢ−ＨＴＭＬデータの５つの状態および状態間の遷移を表す状態遷移図である。
図６５は、ＡＩＴの主要部を表した模式図である。
図６６は、ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている例を示す図である。
図６７は、図６６に示すＤＶＢ−ＨＴＭＬデータの表示例を示す図である。
図６８は、ＤＶＢ−ＨＴＭＬデータの表示例を示す図である。
図６９は、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態と、ＨＴＭＬブラウザ７５０の動作状態との対応を示す変換表の一例を示す図である。
図７０は、各ＨＴＭＬデータの状態を共通状態に変換するための変換表の一例を示す図である。
図７１は、第２の変換部７５１が送信するメッセージの具体例を示す図である。
図７２は、メーラー７６０の状態と、結合部７３０が規定している共通状態との対応を示す変換表の一例を示す図である。
図７３は、第３の変換部７６１が生成する「アプリケーション・データ一覧応答」メッセージの具体例を示す図である。
図７４は、第１の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。
図７５は、通信部７３１が行うメッセージ送信の処理の流れを示すフローチャートである。
図７６は、第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。
図７７は、第３の変換部７７１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。
図７８は、第１の変換部７４１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを表すフローチャートである。
図７９は、第２の変換部７５１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８０は、第３の変換部７６１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８１は、第１の変換部７４１が、「フォーマットエンジン実行」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８２は、第１の変換部７４１が、「フォーマットエンジン一時停止」メッセージを受け取った際の処理の流れを表すフローチャートである。
図８３は、第２の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。
図８４は、リソース剥奪通知を受け取った変換部における処理の流れを示すフローチャートである。
図８５は、第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化通知を受けた際の処理の流れを示すフローチャートである。
図８６は、第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８７は、第１の変換部７４１が、「アプリケーション・データ実行」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８８は、第１の変換部７４１が、「アプリケーション・データ停止」メッセージを受け取った際の処理の流れを示すフローチャートである。
図８９は、第１の変換部７４１が、「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れを示すフローチャートである。
図９０は、第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けた際の処理の流れを示すフローチャートである。
図９１は、結合部７３０が「フォーマットエンジン状態変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。
図９２は、結合部７３０が「アプリケーション・データ一覧変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。
図９３は、フォーマットエンジンを実行しても、他のフォーマットエンジンに大きな影響を与えない状況の組み合わせを示す図である。
図９４は、従来のデジタル放送受信機の構成図の一例である。
図９５は、従来のデジタルテレビにおいて用いられるミドルウェア切替装置の構成図である。
【発明を実施するための最良の形態】  以下、本発明に係る情報処理装置の実施の形態を、図面を参照しながら説明する。なお、以下の実施の形態では、情報処理装置の一例としてデジタルテレビを用いて説明するが、本発明は携帯電話や携帯情報端末等においても適用可能である。
（ハードウェア構成）
まず、図１〜図３を参照して、情報処理装置のハードウェア構成について説明する。図１は、本実施の形態に係る情報処理装置の一例であるデジタルテレビのハードウエア構成を表すブロック図である。図１において、デジタルテレビ１００は、チューナ１０１、デスクランブラ１０２、ＴＳデコーダ１０３、オーディオデコーダ１０４、スピーカ１０５、ビデオデコーダ１０６、ディスプレイ１０７、２次記憶部１０８、１次記憶部１０９、ＲＯＭ１１０、入力部１１１、ネットワークインターフェース１１２、およびＣＰＵ１１３を備えている。
図２は、図１に示すデジタルテレビ１００の外観を示す図である。図１に示すデジタルテレビ１００は、例えば図２に示すような薄型テレビとして実現される。図２に示すように、デジタルテレビ１００は、図１に示す構成に加え、筐体２０１および信号入力端子２０４をさらに備えている。なお、ディスプレイ２０２は、図１に示すディスプレイ１０７に相当する。また、フロントパネル部２０３は、図１に示す入力部１１１に相当する。フロントパネル部２０３は、複数のボタンで構成される。なお、フロントパネル部２０３の詳細な構成は後述する図３に示されている。信号入力端子２０４は、地上波放送の放送局、衛星のアンテナ、あるいはケーブルテレビの局システムからの放送信号をデジタルテレビ１００に入力するための端子である。信号入力端子２０４は、図１のチューナ１０１と接続されている。なお、デジタルテレビ１００は、インターネットに接続するためのネットワーク端子を有している。ネットワーク端子は、ネットワークインターフェース１１２と接続されている。
次に、デジタルテレビ１００の基本的な動作を説明する。チューナ１０１は、信号入力端子２０４を介して送信されてきた放送信号を入力する。チューナ１０１は、ＣＰＵ１１３によって指定された周波数を示すチューニング情報に従って、入力した放送信号を復調する。復調された放送信号は、デスクランブラ１０２に引き渡される。デスクランブラ１０２は、復調された放送信号を復号する。復号に必要な鍵はＣＰＵ１１３から与えられる。復号によって得られるＭＰＥＧ２トランスポートストリームは、ＴＳデコーダ１０３へ出力される。
ＴＳデコーダ１０３は、デスクランブラ１０２から受け取ったＭＰＥＧ２トランスポートストリームに対してフィルタリングを行い、必要なデータをオーディオデコーダ１０４、ビデオデコーダ１０６あるいはＣＰＵ１１３に引き渡す。ＭＰＥＧ２トランスポートストリームの詳細はＭＰＥＧ規格書“ＩＳＯ／ＩＥＣ１３８１８−１”に記載されているので詳細な記述は省略する。ＭＰＥＧ２トランスポートストリームは、複数の固定長パケットで構成され、各パケットには映像、音声、字幕データ、およびアプリケーション等が格納されている。また、各パケットにはパケットＩＤが与えられている。ＴＳデコーダ１０３は、ＣＰＵ１１３によってパケットＩＤとそのパケットＩＤを有するパケットの出力先の組を指示される。パケットの出力先は「オーディオデコーダ１０４」、「ビデオデコーダ１０６」、および「ＣＰＵ１１３」のいずれかである。例えば、ＣＰＵ１１３が、パケットＩＤが「１２３」であるパケットの出力先が「ビデオデコーダ１０６」である旨の指示をＴＳデコーダ１０３へ出力した場合、ＴＳデコーダ１０３は、ＭＰＥＧ２トランスポートストリームからパケットＩＤが「１２３」であるパケットを抽出し、そのパケットをビデオデコーダ１０６に引き渡す。なお、ＴＳデコーダは、複数のフィルタリング処理を変更して実行することができる。
オーディオデコーダ１０４は、ＴＳデコーダ１０３から引き渡された各パケットに埋め込まれているオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ１０５へ出力する。スピーカ１０５は、オーディオデコーダ１０４から出力された信号を音声出力する。ビデオデコーダ１０６は、ＴＳデコーダ１０３から引き渡された各パケットに埋め込まれているビデオデータを連結し、デジタル−アナログ変換を行うことによって得られるビデオ信号をディスプレイ１０７へ出力する。ディスプレイ１０７は、典型的にはブラウン管や液晶表示装置等で構成され、ビデオデコーダ１０６から出力されたビデオ信号を出力する。さらに、ディスプレイ１０７は、ＣＰＵ１１３から指示されたメッセージ等を表示することもある。
２次記憶部１０８は、典型的にはフラッシュメモリやハードディスク等で構成され、ＣＰＵ１１３から指示されたデータやプログラムを保存する。保存されているデータやプログラムはＣＰＵ１１３に参照される。保存されているデータやプログラムは、デジタルテレビ１００の電源が切断された状態でも保存しつづける。１次記憶部１０９は、典型的にはＲＡＭ等で構成され、ＣＰＵ１１３から指示されたデータやプログラムを一次的に保存する。保存されているデータやプログラムはＣＰＵ１１３に参照される。保存されているデータやプログラムは、デジタルテレビ１００の電源が切断された際に、抹消される。ＲＯＭ１１０は、書き換え不可能なメモリデバイスであり、典型的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤ等で構成される。ＲＯＭ１１０には、ＣＰＵ１１３によって実行されるプログラムが格納されている。
入力部１１１は、典型的にはフロントパネルやリモコンで構成され、ユーザからの入力を受け付ける。図３は、入力部１１１を構成するフロントパネルの一例を示す図である。図３において、フロントパネル３００は７つのボタン、すなわち、上カーソルボタン３０１、下カーソルボタン３０２、左カーソルボタン３０３、右カーソルボタン３０４、ＯＫボタン３０５、取消ボタン３０６、ＭＥＮＵボタン３０７、Ｃ＋ボタン３０８、およびＣ−ボタン３０９を備えている。ユーザが各ボタンを押下すると、押下されたボタンを示す識別子がＣＰＵ１１３に通知される。
ネットワークインターフェース１１２は、典型的にはモデムやイーサネットコネクター等で構成され、インターネットやイントラネット等のネットワークと接続する機能をデジタルテレビ１００に提供するものである。ネットワークインターフェース１１２は、ＣＰＵ１１３からの指示に従い、ネットワーク上に接続された他の情報機器とのデータの送受信を行う。例えばネットワークインターフェース１１２がモデムによって構成されている場合、ネットワークインターフェース１１２は、ＣＰＵ１１３から接続先の電話番号や通信パラメータ情報を受け取り、ネットワークとの通信経路を確立する。
ＣＰＵ１１３は、ＲＯＭ１１０が記憶するプログラムを実行する。ＣＰＵ１１３は、プログラムの指示に従い、チューナ１０１、デスクランブラ１０２、ＴＳデコーダ１０３、ディスプレイ１０７、２次記憶部１０８、１次記憶部１０９、およびＲＯＭ１１０の動作を制御する。ＣＰＵ１１３の詳細な動作については後述する。
（動作概要）
次に、情報処理装置の詳細な構成および動作を説明する前に、図４〜図６を参照して、本発明の目的を達成するための情報処理装置の動作の概要を説明する。ここでは、情報処理装置の動作例として、第１および第２の動作例という２つの動作例について説明する。
（第１の動作例）
まず、図４および図５を用いて第１の動作例の概要を説明する。図４は、第１の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。図４において、デジタルテレビは、フォーマットエンジン管理部４１と、第１の変換部４２と、第２の変換部４３と、第１のテーブル格納部４４と、第２のテーブル格納部４９と、第１のフォーマットエンジン４５と、第２のフォーマットエンジン４６と、リソース制御部４７と、リソース４８とを備えている。図４において、リソース４８以外の各構成要素は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。また、リソース４８は、フォーマットエンジンによって利用されるハードウェアである。リソース４８は、例えば、メモリ（１次記憶部１０９および２次記憶部１０８）や、チューナ１０１、ＴＳデコーダ１０３、ネットワークインターフェース１１２等である。なお、図４では、説明を容易にする目的で、デジタルテレビ１００が有するフォーマットエンジンの数を２つとして説明するが、フォーマットエンジンの数は２つ以上であってもよい。
ここで、各フォーマットエンジン４５および４６は、複数種類の動作状態を取り得る。すなわち、各フォーマットエンジン４５および４６は、「実行されている状態」や、「実行されていない状態」等の状態を取り得る。以下、情報処理装置の動作概要を説明する図４〜図６においては、第１のフォーマットエンジン４５は、「動作中」、「停止中」、および「一時停止中」と表現される３種類の動作状態を取り得るものとする。また、第２のフォーマットエンジン４６は、「起動中」および「起動中でない」という２種類の動作状態を取り得るものとする。ここで、各フォーマットエンジンにおいて個別に規定された動作状態を、個別状態と呼ぶ。つまり、第１のフォーマットエンジン４５においては、「動作中」、「停止中」、および「一時停止中」と表現される３種類の動作状態を含む個別状態が規定されている。また、第２のフォーマットエンジン４６においては、「起動中」および「起動中でない」という２種類の動作状態を含む個別状態が規定されている。なお、一般的に、各フォーマットエンジンが取り得る動作状態の種類は、フォーマットエンジンによって様々である。
フォーマットエンジン管理部４１は、各フォーマットエンジン４５および４６の動作を管理する。具体的には、各フォーマットエンジン４５および４６に対して、起動や停止等の指示を行う。ここで、フォーマットエンジン管理部４１においては、各フォーマットエンジンが取り得る動作状態は、共通状態として予め規定されている。共通状態とは、全てのフォーマットエンジンに共通の表現によってフォーマットエンジンの動作状態を規定した概念である。図４においては、フォーマットエンジン管理部４１においては、「実行中」および「終了」と表現される２種類の動作状態を含む共通状態が規定されるものとする。このように、共通状態は、各フォーマットエンジン４５および４６において規定されている動作状態（すなわち、個別状態）とは異なる表現であってもよい。また、共通状態に含まれる動作状態の種類は２種類に限らない。共通状態に含まれる動作状態の種類は、フォーマットエンジン管理部４１が各フォーマットエンジンを管理するために必要となる数の動作状態の種類を定義しておけばよい。
また、フォーマットエンジン管理部４１は、例えばユーザからの入力に従って、フォーマットエンジンに対して動作を指示する。このとき、フォーマットエンジン管理部４１は、共通状態情報を用いて指示を行う。共通状態情報とは、フォーマットエンジンの動作状態を共通状態によって表現した情報である。図４において、例えば、フォーマットエンジン管理部４１が第１のフォーマットエンジン４５の動作状態が所定の動作状態となるように指示を行う場合、フォーマットエンジン管理部４１は、当該所定の動作状態を示す共通状態情報を第１の変換部４２へ出力する。これと同様に、フォーマットエンジン管理部４１は、第２のフォーマットエンジン４６に対して動作の指示を行う場合、第２の変換部４３へ共通状態情報を出力する。
また、フォーマットエンジン管理部４１は、各変換部４２および４３から出力されてくる共通状態情報を受け取ることによって、各フォーマットエンジン４５および４６の動作状態を共通状態の表現によって把握する。このように把握された共通状態を用いて、フォーマットエンジン管理部４１は、各フォーマットエンジン４５および４６の動作を管理することができる。
第１の変換部４２は、フォーマットエンジン管理部４１から出力されてくる共通状態情報に基づいて第１のフォーマットエンジン４５の動作を制御する。すなわち、第１の変換部４２は、フォーマットエンジン管理部４１において規定される共通状態と、第１のフォーマットエンジン４５において規定される個別状態との対応を予め規定しておく。フォーマットエンジン管理部４１から共通状態情報が出力されてくると、第１の変換部４２は、当該対応に基づいて、共通状態情報により示される共通状態に対応する個別状態を特定する。さらに、第１の変換部４２は、特定した個別状態となるように第１のフォーマットエンジン４５の動作を制御する。
また、第１の変換部４２は、第１のフォーマットエンジン４５の動作状態（個別状態で表現されている）を取得し、取得した動作状態を共通状態によって表現される形でフォーマットエンジン管理部４１へ通知する。つまり、第１の変換部４２は、第１のフォーマットエンジン４５から取得した動作状態を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。共通状態情報をフォーマットエンジン管理部４１へ出力する場合も、上記共通状態と個別状態との対応が用いられる。すなわち、第１のフォーマットエンジン４５から個別状態を取得すると、第１の変換部４２は、上記対応に基づいて、取得した個別状態に対応する共通状態を特定する。さらに、第１の変換部４２は、特定した共通状態を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。
第２の変換部４３は、第１の変換部４２と同様の処理を行う。すなわち、第２の変換部４３は、フォーマットエンジン管理部４１から出力されてくる共通状態情報に基づいて第２のフォーマットエンジン４６の動作を制御する。また、第２の変換部４３は、第２のフォーマットエンジン４６の動作状態（個別状態で表現されている）を取得し、取得した動作状態を共通状態によって表現される形でフォーマットエンジン管理部４１へ通知する。これらの動作の詳細は、第１の変換部４２における動作と同様の方法で行われる。
第１のテーブル格納部４４は、フォーマットエンジン管理部４１において規定される共通状態と、第１のフォーマットエンジン４５において規定される個別状態とを対応付けたテーブルを格納する。また、第２のテーブル格納部４４は、フォーマットエンジン管理部４１において規定される共通状態と、第２のフォーマットエンジン４６において規定される個別状態とを対応付けたテーブルを格納する。図５は、各テーブル格納部４４および４９が格納するテーブルの一例を示す図である。図５（ａ）は、第１のテーブル格納部４４が格納するテーブルの一例を示す図であり、図５（ｂ）は、第２のテーブル格納部４９が格納するテーブルの一例を示す図である。図５（ａ）においては、「実行中」という共通状態に対して、「動作中」という個別状態が対応付けられる。また、「終了」という共通状態に対して、「停止中」および「一時停止中」という個別状態が対応付けられる。図５（ｂ）においては、「実行中」という共通状態に対して、「起動中」という個別状態が対応付けられている。また、「終了」という共通状態に対して、「起動中でない」という個別状態が対応付けられている。各変換部４２および４３は、図５に示すテーブルを参照して、フォーマットエンジン管理部４１から出力されてくる共通状態情報により示される共通状態に対応する個別状態を特定する。また、各変換部４２および４３は、図５に示すテーブルを参照して、各フォーマットエンジン４５および４６から取得した個別状態に対応する共通状態を特定する。
例えば、第１の変換部４５に「実行中」を示す共通状態情報が出力されてきた場合、第１の変換部４５は、図５（ａ）に示すテーブルを参照して、「動作中」という個別状態を特定する。そして、第１の変換部４５は、特定した「動作中」という動作状態となるように第１のフォーマットエンジン４５を制御する。また、例えば、第２の変換部４３が第２のフォーマットエンジン４６から「起動中でない」を示す個別状態を取得した場合、第２の変換部４３は、上記図５（ｂ）に示すテーブルを参照して、「終了」という共通状態を特定する。そして、第２の変換部４３は、特定した「終了」を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。
また、図４において、リソース制御部４７は、各フォーマットエンジン４５および４６の要求に応じて、各フォーマットエンジン４５および４６に対してリソース４８の利用を許可する。
なお、以上の動作は、後述する第２の動作例においても同様である。
ここで、リソース４８が極小リソースである場合を考える。極小リソースとは、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである。例えば、チューナ１０１や、ＴＳデコーダ１０３や、ネットワークインターフェース１１２は極小リソースである。極小リソースは、デジタルテレビ１００が有している数が限られたリソースで、かつ、複数のフォーマットエンジンが同時に使用を試み、競合する可能性のあるリソースのことである。例えば、チューナ１０１は１つの周波数帯にしかチューニングできない。複数のフォーマットエンジンが異なる周波数帯にチューニングしたい場合にリソースの競合が発生する。このような極小リソースは複数のフォーマットエンジンが同時に利用することができないので、リソース制御部４７は、複数のフォーマットエンジンに対して極小リソースの利用を同時に許可しないようにする必要がある。もしリソース制御部４７が複数のフォーマットエンジンに対して極小リソースの利用を同時に許可すれば、当該フォーマットエンジンの動作が正常に行われない可能性がある。そこで、図４においては、フォーマットエンジンの動作を正常に行うための方法として、以下の方法をとる。
図４においては、各テーブル格納部４４および４９に格納されているテーブルにおける共通状態と個別状態との対応付けは、次のように行われる。すなわち、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる。さらに、フォーマットエンジンが極小リソースを利用しない動作状態を表す個別状態に対して、「終了」という共通状態が対応付けられる。なお、図４においては、第１のフォーマットエンジン４５は、「動作中」という個別状態においてのみ極小リソースを利用し、他の個別状態においては極小リソースを利用しないものとする。また、第２のフォーマットエンジン４６は、「起動中」という個別状態においてのみ極小リソースを利用し、他の個別状態においては極小リソースを利用しないものとする。このとき、上記テーブルは図５に示すようになる。
上記テーブルの対応付けを以上のように行うとともに、さらに、フォーマットエンジン管理部４１は、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する。これによって、フォーマットエンジン管理部４１は、極小リソースを利用するフォーマットエンジンが１つになるように各フォーマットエンジン４５および４６の動作を管理することができる。フォーマットエンジン管理部４１による具体的な管理方法は種々考えられる。具体的な管理方法については、後述する処理例において述べる。
（第２の動作例）
次に、図６を用いて第２の動作例について説明する。図６は、第２の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。図６において、デジタルテレビは、図４に示す構成に加えて、許可決定部６１と、優先度情報格納部６２とを備えている。なお、図６において、図４に示す構成要素と同じ構成要素には同じ参照符号を付している。図６において、許可決定部６１および優先度情報格納部６２は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。
図４における動作と図６における動作との相違点は、リソース４８が極小リソースである場合における、フォーマットエンジンの動作を正常に行うための方法である。その他の動作、例えば、フォーマットエンジン管理部４１が共通状態によって各フォーマットエンジン４５および４６の動作を管理する動作や、各変換部４２および４３が共通状態と個別状態との相互の変換を行う動作については、図４と同様である。従って、以下では、第２の動作例においてフォーマットエンジンの動作を正常に行うための方法を説明する。
第２の動作例では、各テーブル格納部４４および４９において、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる必要はない。さらに、フォーマットエンジン管理部４１は、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する必要はない。第２の動作例では、リソース４８を利用する要求がリソース制御部４７において重複した場合、リソースを使用可能なフォーマットエンジンが優先度情報に基づいて選択される。以下、詳細を説明する。
優先度情報格納部６２は、優先度情報を格納する。優先度情報とは、極小リソースであるリソース４８を利用する場合における各フォーマットエンジン間の優先度を示す情報である。図６においては、優先度情報は、第１のフォーマットエンジン４５と第２のフォーマットエンジン４６とのいずれを優先するかを示す情報である。
リソース制御部４７は、リソース４８を利用する要求がリソース制御部４７において重複した場合、すなわち、リソース４８を利用する要求が複数のフォーマットエンジンから同時に行われた場合、要求が重複した旨の通知を許可決定部６１へ出力する。
許可決定部６１は、要求が重複した旨の通知をリソース制御部４７から受け取った場合、優先度情報格納部６２に格納されている優先度情報に基づいて、リソース４８の利用を許可すべきフォーマットエンジンを決定する。さらに、許可決定部６１は、決定したフォーマットエンジンを示す情報をリソース制御部４７へ出力する。リソース制御部４７は、当該情報により示されるフォーマットエンジンにリソース４８の利用を許可する。以上によって、極小リソースを利用するフォーマットエンジンが１つになるように各フォーマットエンジン４５および４６の動作を管理することができる。なお、利用が許可されなかったフォーマットエンジンに対して、利用を許可しない旨の通知がリソース制御部４７またはフォーマットエンジン管理部４１によって行われてもよい。
以上のように、上記第１および第２動作例によれば、フォーマットエンジン管理部４１は共通状態を用いて各フォーマットエンジン４５および４６の動作を管理する。共通状態は各フォーマットエンジンにおいて規定される個別状態とは別個であり、管理すべきフォーマットエンジンとは無関係である。従って、仮にフォーマットエンジンの追加や変更があった場合でも、共通状態として規定されている内容を変更する必要はない。つまり、フォーマットエンジン管理部４１を変更する必要はない。フォーマットエンジンの追加があった場合には、当該フォーマットエンジンを追加するとともに、それに対応する変換部を追加すればよいだけである。つまり、追加するフォーマットエンジンにおいて規定される個別状態と共通状態との対応を新たに追加すればよいだけである。以上のように、上記第１および第２動作例によれば、仮にフォーマットエンジンの追加や変更があった場合でも、当該追加や変更に容易に対応することができる。
さらに、リソース４８が極小リソースである場合、上記第１および第２動作例によれば、極小リソースを複数のフォーマットエンジンが同時に利用しないように各フォーマットエンジンの動作が管理される。従って、極小リソースを利用する複数のフォーマットエンジンが正常に動作しなくなることを防止することができる。
なお、上記第１および第２の動作例においては、リソース４８が１つである場合について説明したが、リソースは複数であってもよい。リソースが複数である場合、リソース制御部はリソースに対応して、リソースと同数設けられる必要がある。なお、第１の動作例においてリソースが複数である場合であっても、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる点は上記第１の動作例と同様である。また、第１の動作例においてリソースが複数である場合であっても、フォーマットエンジン管理部４１が、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する点は上記第１の動作例と同様である。
また、第２の動作例においてリソースが複数である場合、極小リソースに対応して設けられるリソース制御部は、上記第２の動作例と同様の動作を行う。これによって、極小リソースが複数である場合、各極小リソースが重複して利用されることを防止することができる。さらに、第２の動作例では、互いに異なる複数のフォーマットエンジンは、それぞれ、互いに異なる複数の極小リソースを同時に利用することが可能である。つまり、あるフォーマットエンジンＡが極小リソースＡを利用している場合に、別のフォーマットエンジンＢは極小リソースＢを利用することができる。なお、第１の動作例では、極小リソースが複数である場合、複数の極小リソースを同時に利用することは不可能であった。これに対して第２の動作例では、複数の極小リソースを同時に利用することができる点で、第１の動作例よりも効率よくフォーマットエンジンを実行することができると言える。
なお、上記第１および第２の動作例においては、各変換部４５および４６は、フォーマットエンジンと別個に構成されるものとしたが、フォーマットエンジンと一体的に構成されるものであってもよい。換言すれば、フォーマットエンジンは、変換部の機能を有するものであってもよい。以上で、第１および第２の動作例の概要の説明を終了する。
（具体的な構成例）
次に、図７〜図７３を用いて、本発明に係る情報処理装置の具体的な構成を説明する。なお、以下で説明する構成は、上述した第１および第２の動作例の双方を実現することが可能な構成である。従って、以下で説明する構成には、第１の動作例のみを実行する場合には不要である構成や、第２の動作例のみを実行する場合には不要である構成が含まれるが、そのような構成については説明中において適宜述べる。
図７は、情報処理装置の機能的な構成をより具体的に示す図である。図７に示す各構成要素は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。換言すれば、図７は、ＲＯＭ１１０に記憶され、ＣＰＵ１１３に実行されるプログラムの構成を示す図である。
図７において、情報処理装置は、ＯＳ７１０と、ナビゲータ７２０と、結合部７３０と、Ｊａｖａミドルウェア７４０と、ＨＴＭＬブラウザ４５０と、メーラー４６０と、第１の変換部７４１と、第２変換部４５１と、第３の変換部７６１とを備えている。これらは、ＲＯＭ１１０に格納されているプログラムのサブプログラムである。なお、図４に示すフォーマットエンジン管理部４１は、ナビゲータ７２０および結合部７３０の機能の一部として実現される。
図７に示すサブプログラムの内、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０は、所定のフォーマットで記述されたアプリケーションの実行や、所定のフォーマットで記述されたデータの表示等を行うフォーマットエンジンである。以下に説明する具体的な構成例では、これら３種類のフォーマットエンジンを例として取り上げたが、フォーマットエンジンは、ワードプロセッサプログラムやスプレッドシートプログラム等であってもよい。また、情報処理装置が備えるフォーマットエンジンの数は３つに限るものではなく、１つでも２つでもよく、４つ以上でもよい。ただし、フォーマットエンジンの数と同数の変換部を用意する必要がある。
ＯＳ７１０は、デジタルテレビ１００の電源が投入されると、ＣＰＵ１１３が起動するサブプログラムである。ＯＳ７１０は、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ７１０は、他のサブプログラムを平行して実行するカーネル７１１およびライブラリ７１２等で構成されるプログラム群の総称であり、詳細な説明は省略する。本構成例においては、ＯＳ７１０のカーネル７１１は、電源投入後にナビゲータ７２０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０をサブプログラムとして起動する。ＯＳ７１０がＬｉｎｕｘである場合、ＯＳ７１０は、これらサブプログラムに対してそれぞれ個別のプロセスを起動し、それぞれのプロセス内で個々のサブプログラムを実行する。
ＯＳ７１０のライブラリ７１２は、他のサブプログラムに対して、デジタルテレビ１００が有するハードウエア構成要素（リソース）を制御するための複数の機能を提供する。つまり、図４に示すリソース制御部４７は、ライブラリ７１２の機能の一部として実現される。本構成例では、複数の機能の一例として、チューナライブラリ（チューナＬｉｂ）７１２１、デスクランブラライブラリ（デスクランブラＬｉｂ）７１２２、およびＡＶ再生ライブラリ（ＡＶ再生Ｌｉｂ）７１２３を取り上げる。これらは、図４に示すリソース制御部４７の機能を実現するものである。
チューナＬｉｂ７１２１は、チューナ１０１を制御する機能をサブプログラムに提供する。すなわち、チューナＬｉｂ７１２１は、チューナに与える周波数を含むチューニング情報をサブプログラムから受け取る。そして、チューナＬｉｂ７１２１は、受け取った情報をチューナ１０１に与えるとともに、チューニングを行うようにチューナ１０１に指示する。
デスクランブラＬｉｂ７１２２は、デスクランブラ１０２を制御する機能をサブプログラムに提供する。すなわち、デスクランブラＬｉｂ７１２２は、鍵等を含む復号情報をサブプログラムから受け取る。そして、デスクランブラＬｉｂ７１２２は、受け取った情報をデスクランブラ１０２に与えるとともに、デスクランブラ１０２に復号を行うように指示する。
ＡＶ再生Ｌｉｂ７１２３は、ＴＳデコーダ１０３を制御し、映像・音声再生を行う機能をサブプログラムに提供する。すなわち、ＡＶ再生Ｌｉｂ７１２３は、再生すべき映像のパケットＩＤおよび音声のパケットＩＤをサブプログラムから受け取る。そして、ＡＶ再生Ｌｉｂ７１２３は、受け取った映像のパケットＩＤと出力先「ビデオデコーダ１０６」との組、および、受け取った音声のパケットＩＤと出力先「オーディオデコーダ１０４」との組をＴＳデコーダ１０３に与えると共に、ＴＳデコーダ１０３にフィルタリングを行うように指示する。これによって、音声データを含むパケットがオーディオデコーダ１０４に引き渡された後、音声データはスピーカ１０５を通して再生される。また、映像データを含むパケットがビデオデコーダ１０６に引き渡された後、映像データは、ディプレイ１０７を通して再生される。
ナビゲータ７２０は、例えばユーザの指示に従って、フォーマットエンジンの起動や停止をフォーマットエンジンに対して指示する。また、ナビゲータ７２０は、デジタルテレビのチャンネル切り替えや、フォーマットエンジンでのアプリケーションの実行・停止、データの再生・停止等を指示する。ナビゲータ７２０は、ＯＳ７１０のカーネル７１１によって起動されるサブプログラムである。
次に、ナビゲータ７２０によるチャンネルの切り替えの動作を説明する。なお、入力部１１１は、図３で示されるフロントパネルであるとする。ユーザがＣ＋ボタン３０８あるいはＣ−ボタン３０９を押下すると、ナビゲータ７２０は、押下されたボタンの識別子を受け取り、再生しているチャンネルを切り替える。ここで、Ｃ＋ボタン３０８はチャンネル番号を番号が大きくなる方へ変化させ、Ｃ−ボタン３０９はチャンネル番号を番号が小さくなる方へ変化させる。再生可能なチャンネルの番号が例えば「１」、「２」「４」「６」「８」で、現在チャンネル「６」を再生しているとする。ここで、ユーザがＣ＋ボタン３０８を押下するとナビゲータ７２０は、再生するチャンネルを「６」から「８」に変更する。また、ユーザがＣ−ボタン３０９を押下するとナビゲータ７２０は、再生するチャンネルを「６」から「４」に変更する。チャンネル変更は、チャンネルに対応する映像・音声を含むパケットＩＤをＯＳ７１０のライブラリ７１２に含まれるＡＶ再生Ｌｉｂ７１２３に与えることによって行われる。この動作は、現在市販されているテレビの基本的な機能であるので、詳細な説明は省略する。
次に、図８〜図１６を用いて、フォーマットエンジン等の起動指示がユーザによって行われる際のナビゲータの動作を説明する。ユーザが入力部１１１のＭＥＮＵボタン３０７を押下すると、ナビゲータ７２０は、実行可能なフォーマットエンジンの一覧をディスプレイ１０７に表示する。図８、図９および図１０は、ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図である。図８〜図１０では、フォーマットエンジンの一覧として、フォーマットエンジン名とその状態との組が表示される。さらに、フォーマットエンジンを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することに応じて移動する。図８に示す状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図９に示す状態になる。図９の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１０に示す状態になる。図９に示す状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図８に示す状態になる。なお、図８〜図１０において、表示される各フォーマットエンジン（Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０）の状態は、ナビゲータ７２０によって結合部７３０から取得される。
また、図８に示す状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションの一覧を表示する。図１１および図１２は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図である。図１１および図１２では、実行可能なアプリケーションの一覧として、アプリケーション名とその状態との組が表示される。さらに、アプリケーションを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することに応じて移動する。図１１の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１２の状態になる。図１２の状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図１１の状態になる。なお、図１１および図１２において、表示される各アプリケーションの状態は、ナビゲータ７２０によって結合部７３０から取得される。
また、図１１の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、アプリケーション「ＥＰＧ」を起動するように結合部７３０に対して指示する。図１２の状態でＯＫボタン３０５を押下すると、ナビゲータ７２０は、アプリケーション「トランプゲーム」を起動するように結合部７３０に対して指示する。
図１１および図１２では、全てのアプリケーションが停止中であったが、アプリケーションが「一時停止中」あるいは、「実行中」の場合もある。図１３および図１４は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図である。図１３および図１４では、「ＥＰＧ」の動作状態が「実行中」であり、「トランプゲーム」の動作状態が「一時停止中」である。図１３の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にアプリケーション「ＥＰＧ」を停止するように指示する。図１４の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にアプリケーション「トランプゲーム」を停止するように指示する。まとめると、「停止中」であるアプリケーションをカーソル１１０によって選択している状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該アプリケーションを起動するように結合部７３０に対して指示する。一方、「実行中」あるいは「一時停止中」であるアプリケーションをカーソル８１によって選択している状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にそのアプリケーションを停止するように指示する。
また、図９の状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、ＨＴＭＬブラウザ７５０が表示可能なデータの一覧を表示する。図１５および図１６では、実行可能なデータの一覧として、データ名とその状態との組が表示される。さらに、ユーザがデータを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することにより移動する。図１５の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１６の状態になる。図１６の状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図１５の状態になる。なお、表示される各データの状態は、ナビゲータ７２０によって結合部７３０から取得される。また、図１５の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にデータ「天気予報」を停止するように指示する。図１６の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にデータ「レジャー情報」を停止するように指示する。
また、図１０の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、メーラー７６０を起動するように結合部７３０に対して指示する。メーラー７６０は、取り扱う個々のデータに関する動作状態（例えば、停止中、実行中、一時停止中）を持っておらず、メーラー７６０自身の動作状態のみが規定されている。従って、図１０の状態でユーザが入力部１１１のＯＫボタン３０５を押下しても、Ｊａｖａミドルウェア７４０やＨＴＭＬブラウザ７５０のように個々のフォーマットエンジンが取り扱うアプリケーションやデータの一覧を表示することはない。ナビゲータ７２０は、メーラー７６０が取り扱うアプリケーションやデータの状態の一覧を結合部７３０から取得する際、メーラー７６０が個々のアプリケーションやデータの動作状態を保持していないことを知る。あるいは、ナビゲータ７２０は、メーラー７６０が個々のアプリケーションやデータの動作状態を保持していないことを予め知っていてもよい。
以上のように、ナビゲータ７２０は、個々のアプリケーションやデータの動作状態を保持していないフォーマットエンジンに対しては、ナビゲータ７２０は、次のように動作する。すなわち、フォーマットエンジンの動作状態が「停止中」であるフォーマットエンジンがカーソル８１によって選択されている状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該フォーマットエンジンを起動するように結合部７３０に対して指示する。一方「実行中」あるいは「一時停止中」であるフォーマットエンジンがカーソル８１によって選択されている状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該フォーマットエンジンを停止するように結合部７３０に対して指示する。
なお、フォーマットエンジンあるいはフォーマットエンジンが取り扱うアプリケーションやデータの一覧が表示されている場合（図８〜図１６）において、ユーザが入力部１１１のＭＥＮＵボタン３０７を押下すると、ナビゲータ７２０は、当該一覧の表示を取りやめる。
図４の説明に戻り、結合部７３０は、ナビゲータ７２０と複数のフォーマットエンジンとを結合するためのモジュールである。結合部７３０は、通信部７３１と、状態管理部７３２と、リソース管理部７３３とを備えている。
通信部７３１は、ナビゲータ７２０と各フォーマットエンジンとの間の通信を行う。ここで、通信とはメッセージデータの送受信を意味する。具体的には、ナビゲータ７２０がフォーマットエンジンに対して指示を行う場合、ナビゲータ７２０は当該指示を示すメッセージを通信部７３１を介して当該フォーマットエンジンへ送る。例えば、ナビゲータ７２０が、Ｊａｖａミドルウェア７４０が実行しているアプリケーションを停止する旨の指示を行う場合、ナビゲータ７２０は、当該停止の指示を意味するメッセージを通信部７３１を通してＪａｖａミドルウェア７４０に送る。
なお、ナビゲータ７２０や各フォーマットエンジンは、異なるプロセスあるいはスレッドで動作しているので、プロセス間通信あるいはスレッド間通信を行う必要がある。プロセス間通信あるいはスレッド間通信は、ＯＳがＬｉｎｕｘであれば、Ｓｏｃｋｅｔ、ＰＩＰＥ等のＯＳ７１０が備える機能を利用することによって実現することができる。
ここで、もし、ナビゲータ７２０と各フォーマットエンジンとの間で個別に通信方法を決定することとすると、ナビゲータ７２０および各フォーマットエンジンは、複数種類の通信方法を実装しなければならない。従って、全プログラムのコード量が増え、開発工数も大きくなる。そこで、通信部７３１は、ナビゲータ７２０および各フォーマットエンジンが使用する共通の通信方法を規定する。ここでは、ナビゲータ７２０はＳｏｃｋｅｔ通信を用いることとするが、ＦＩＦＯ等、他の方法を用いても実現可能である。通信部７３１は、さらにＳｏｃｋｅｔ通信のプロトコル上に、独自のメッセージフォーマットを規定する。
次に、図１７〜図３１を用いて、メッセージフォーマットについて詳細を説明する。図１７は、メッセージフォーマットの一例を示す図である。図１７において、メッセージは５つのフィールドで構成される。Ｓｏｕｒｃｅ  ＩＤフィールド１７１は、メッセージの送信元であるサブプログラムを示す情報を格納する。なお、サブプログラムには、サブプログラムを識別するためのサブプログラムＩＤが割り当てられる（後述する図１８参照。）。Ｓｏｕｒｃｅ
ＩＤフィールド１７１は、メッセージの送信元であるサブプログラムのサブプログラムＩＤを格納する。具体的には、Ｓｏｕｒｃｅ  ＩＤフィールド１７１は、メッセージを発信したナビゲータ７２０やフォーマットエンジンを示すサブプログラムＩＤを１バイトで格納する。サブプログラムＩＤの詳細な内容は後述する。
Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１７２は、メッセージを受け取るサブプログラムを示すサブプログラムＩＤ（ＳＩＤ）を１バイトで格納する。フォーマットエンジンＩＤの詳細な内容は後述する。Ｍｅｓｓａｇｅ  ＩＤフィールド１７３は、メッセージの内容を表すメッセージＩＤを１バイトで格納する。メッセージＩＤの詳細な内容は後述する。Ｄａｔａ  Ｌｅｎｇｈフィールド１７４は、Ｄａｔａフィールド１７５に格納されるデータの長さを２バイトで格納する。Ｄａｔａフィールド１７５は、メッセージＩＤに対応する詳細データを格納する。格納するデータのフォーマットはメッセージＩＤに対応して規定される。
図１８は、図１７に示すＳｏｕｒｃｅ  ＩＤフィールド１７１およびＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１７２に格納されるサブプログラムＩＤの表の一例を示す図である。図１８に示す表では、左側の列にサブプログラムが記載され、右側の列に対応するサブプログラムＩＤが記載されている。なお、左側の列にある「ＡＬＬ」は、全てのフォーマットエンジンを示す。ここでは、「ＡＬＬ」の他、ナビゲータ７２０、結合部７３０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０に対してサブプログラムＩＤが付されている。つまり、これらのサブプログラムがメッセージのやり取りを行うサブプログラムである。
図１９は、Ｍｅｓｓａｇｅ  ＩＤフィールド１７３に格納されるメッセージＩＤの表の一例を示す図である。図１９においては、左側の列にメッセージ内容が記載され、中央の列にメッセージＩＤ（ＭＩＤ）が記載され、右側の列にＤａｔａフィールド１７５に格納するデータのフォーマットＩＤが記載されている。以下、各メッセージの詳細について説明する。
図１９において、上から２番目の行は、フォーマットエンジンに対して、フォーマットエンジンの状態を通知するように要求するための「フォーマットエンジン状態要求」メッセージが記載されている。例えば、ナビゲータ７２０が各フォーマットエンジンの動作状態を知りたいときに使用する。このメッセージはデータフィールド１７５を使用しない。
図１９において、上から３番目の行は、「フォーマットエンジン状態要求」の応答を行うための「フォーマットエンジン状態応答」メッセージである。例えば、Ｊａｖａミドルウェア７４０がナビゲータ７２０から「フォーマットエンジン状態要求」を受け取ると、Ｊａｖａミドルウェア７４０は、この「フォーマットエンジン状態応答」メッセージを用いてフォーマットエンジンの状態を通知する。このメッセージは、データフィールド１７５にフォーマットエンジンの状態を格納する。図２０は、フォーマットエンジン状態応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。データフィールド１７５には、フォーマットエンジンの動作状態を示す動作状態ＩＤが１バイトで格納される。
図２１は、フォーマットエンジンの動作状態と動作状態ＩＤとの対応を示す表の一例を示す図である。図２１において、左側の列にフォーマットエンジンの動作状態が記載され、中央の列に動作状態の意味が記載され、右側の列に動作状態ＩＤが記載されている。ここでは、「実行中」、「一時停止中」、および「停止中」という３つの動作状態が規定されている。図２１において規定されいるこれらの動作状態は、全フォーマットエンジンに共通する共通状態である。つまり、メッセージに含まれる動作状態は、共通状態の表現で表されている。また、「実行中」という共通状態は、デジタルテレビ１００が有している極小リソースを使用していることを意味する。
図１９の説明に戻り、上から４番目の行は、フォーマットエンジンの状態が変化したことを、フォーマットエンジンがナビゲータ７２０や他のフォーマットエンジンに通知するための「フォーマットエンジン状態変化」メッセージである。このメッセージはデータフィールド１７５を使用しない。
また、上から５番目から７番目の行は、ナビゲータ７２０等が他のフォーマットエンジンに対して状態を「実行中」「停止中」「一時停止中」に変更するように指示を出すための「フォーマットエンジン実行」「フォーマットエンジン停止」「フォーマットエンジン一時停止」メッセージである。これらのメッセージはデータフィールド１７５を使用しない。
また、上から８番目の行は、フォーマットエンジンに対して、フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータの一覧を通知するように要求するための「アプリケーション・データ一覧要求」メッセージである。例えば、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションの一覧を、ナビゲータ７２０が知りたい場合に使用される。このメッセージはデータフィールド１７５を使用しない。
また、上から９番目の行は、「アプリケーション・データ一覧要求」の応答を行うための「アプリケーション・データ一覧応答」メッセージである。例えば、Ｊａｖａミドルウェア７４０がナビゲータ７２０から「アプリケーション・データ一覧要求」を受け取ると、Ｊａｖａミドルウェア７４０は、「アプリケーション・データ一覧応答」メッセージを用いて、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションとその状態との一覧を通知する。このメッセージはデータフィールド１７５にアプリケーション・データの一覧を格納する。
図２２は、アプリケーション・データ一覧応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。図２２においては、アプリケーション数（図２２では「アプリ数」と記載している）フィールド２２０１に、フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータの数が１バイトで格納される。
データフィールド１７５には、アプリケーション数フィールド２２０１に続いて、アプリケーション数フィールド２２０１に格納された数のアプリケーション情報フィールド２２０２が設けられる。
アプリケーション情報フィールド２２０２の先頭には、アプリケーションＩＤフィールド２２０３が設けられる。アプリケーションＩＤフィールド２２０３には、実行可能なアプリケーションあるいは表示可能なデータを識別するアプリケーションＩＤが１バイトで格納される。このアプリケーションＩＤは、フォーマットエンジンが割り当てる。
続いて、アプリケーション情報フィールド２２０２には、アプリケーション状態（図２２では「アプリ状態」と記載している）ＩＤフィールド２２０４が設けられる。アプリケーション状態ＩＤフィールド２２０４には、アプリケーションあるいはデータの状態を表すアプリケーション状態ＩＤを１バイトで格納する。なお、本構成例では、アプリケーションの状態とアプリケーション状態ＩＤとの対応は、図２１に示す対応、すなわち、フォーマットエンジンの動作状態と動作状態ＩＤとの対応と同じであるとする。
続いて、アプリケーション情報フィールド２２０２には、アプリケーション名長さ（図２２では「アプリ名の長さ」と記載している）フィールド２２０５が設けられる。アプリケーション名長さフィールド２２０５には、アプリケーションあるいはデータの名前の長さが格納される。
アプリケーション情報フィールド２２０２の末尾には、アプリケーション名（図２２では「アプリ名」と記載している）フィールド２２０６が設けられる。アプリケーション名フィールド２２０６には、アプリケーション名長さフィールド２２０５に格納されたデータにより指定される長さのアプリケーションの名前が格納される。
図１９の説明に戻り、上から１０番目の行は、フォーマットエンジンが実行中のアプリケーションあるいは表示中のデータの状態が変化したことを、フォーマットエンジンがナビゲータ７２０や他のフォーマットエンジンに通知するための「アプリケーション・データ一覧変化」メッセージである。このメッセージはデータフィールド１７５を使用しない。
また、上から１１番目から１３番目の行は、ナビゲータ７２０等が他のフォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータに対して状態を「実行中」「停止中」「一時停止中」に変更するように指示を出すための「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」メッセージである。これらのメッセージはデータフィールド１７５に状態を変化させる対象のアプリケーションあるいはデータを識別するためのアプリケーションＩＤを格納する。
図２３は、「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」のメッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。データフィールド１７５には、アプリケーションあるいはデータを識別するためのアプリケーションＩＤ（図２３では、「アプリＩＤ」と記載している）が１バイトで格納される。アプリケーションＩＤは、「アプリケーション・データ一覧応答」メッセージでフォーマットエンジンが返す値を用いる。
図１９の説明に戻り、上から１４番目の行は、ナビゲータ７２０や他のフォーマットエンジン間で、独自データの送受信時に使用する「プライベート」メッセージである。データフィールド１７５は、ナビゲータ７２０や他のフォーマットエンジン間で独自に規定したフォーマットに独自のデータを埋め込んで使用される。
なお、本構成例では、フォーマットエンジンの動作状態の規定と、アプリケーション・データの動作状態の規定とが同じであるが、異なっていても実施可能である。また、本構成例で規定しているメッセージおよびメッセージのフォーマットは一例であり、これ以外のメッセージを含む、他のフォーマットを使用する、あるいは本構成例で示したメッセージの一部・全部を使用しない等してもよい。重要なポイントは、結合部７３０あるいは同等の構成要素が、ナビゲータ７２０や複数のフォーマットエンジン間で使用される、フォーマットエンジンの共通状態およびアプリケーション・データの共通状態を規定し、共通の通信手段を提供することにある。
次に、ナビゲータ７２０の動作に対応するメッセージの具体例を説明する。まず、ナビゲータ７２０が図８に示すようなフォーマットエンジンの一覧を表示する際には、ナビゲータ７２０は、図２４〜図２６に示す３つの「フォーマットエンジン状態要求」メッセージを結合部７３０に渡す。図２４〜図２６は、「フォーマットエンジン状態要求」メッセージの具体例を示す図である。図２４に示すメッセージ２４００は、ナビゲータ７２０からＪａｖａミドルウェア７４０への「フォーマットエンジン状態要求」である。Ｓｏｕｒｃｅ  ＩＤフィールド２４０１にはナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド２４０２には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤとして「２」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド２４０３には、「フォーマットエンジン状態要求」を表す「１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド１５０４には、データの長さとして「０」が格納される。図２５に示すメッセージ２５００は、ナビゲータ７２０からＨＴＭＬブラウザ７５０への「フォーマットエンジン状態要求」である。メッセージ２４００とメッセージ２５００の違いは、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１５１２に、ＨＴＭＬブラウザ７５０を表すＩＤ「３」を格納している（図１８参照）部分だけであり、他は同じである。図２６に示すメッセージ２６００は、ナビゲータ７２０からメーラー７６０への「フォーマットエンジン状態要求」である。メッセージ２４００とメッセージ２６００の違いは、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤ１５２２に、メーラー７６０を表すＩＤ「４」を格納している（図１８参照）部分だけであり、他は同じである。
「フォーマットエンジン状態要求」メッセージが送信された後、ナビゲータ７２０は、結合部７３０から図２７〜図２９に示す３つの「フォーマットエンジン取得応答」メッセージを受け取る。図２７〜図２９は、「フォーマットエンジン取得応答」メッセージの具体例を示す図である。メッセージ２７００は、Ｊａｖａミドルウェア７４０からナビゲータ７２０への「フォーマットエンジン取得応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド２７０１には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤ「２」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ
ＩＤフィールド２７０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド２７０３には、「フォーマットエンジン取得応答」を表すメッセージＩＤとして「２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド２７０４にはデータの長さ「１」が格納される。データフィールド２７０５には、「停止中」を表す動作状態ＩＤとして「３」が格納される（図２１参照）。メッセージ２８００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「フォーマットエンジン取得応答」である。メッセージ２７００とメッセージ２８００の違いは、Ｓｏｕｒｃｅ  ＩＤフィールド２８０１に、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納されている部分だけであり、他は同じである。メッセージ２７２０は、メーラー７６０からナビゲータ７２０への「フォーマットエンジン取得応答」である。メッセージ２７００とメッセージ２９００の違いは、Ｓｏｕｒｃｅ  ＩＤフィールド２９０１に、図１８を参照してメーラー７６０を表すサブプログラムＩＤとして「４」が格納されている部分だけであり、他は同じである。このように３つの「フォーマットエンジン状態要求」メッセージを結合部７３０に送り、３つの「フォーマットエンジン取得応答」メッセージを結合部７３０から受け取ることによって、ナビゲータ７２０は、図８に示すフォーマットエンジン一覧を表示することができる。
次に、ナビゲータ７２０が図１５に示すようなＨＴＭＬブラウザ７５０が表示可能なデータの一覧を表示する場合について説明する。この場合、ナビゲータ７２０は、図３０に示す「アプリケーション・データ一覧要求」メッセージを結合部７３０に渡す。図３０は、「アプリケーション・データ一覧要求」メッセージの具体例を示す図である。図３０に示すメッセージ３０００は、ナビゲータ７２０からＨＴＭＬブラウザ７５０への「アプリケーション・データ一覧要求」である。Ｓｏｕｒｃｅ  ＩＤフィールド１７０１には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１７０２には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド１７０３には、「アプリケーション・データ一覧要求」を表すメッセージＩＤとして「１１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド１７０４にはデータの長さを示す「０」が格納される。
「アプリケーション・データ一覧要求」メッセージを送信した後、ナビゲータ７２０は、結合部７３０から図３１に示す「アプリケーション・データ取得応答」メッセージを受け取る。図３１は、「アプリケーション・データ取得応答」メッセージの具体例を示す図である。図３１に示すメッセージ３１００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「アプリケーション・データ取得応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド３１０１には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤ３フィールド１０３には、「アプリケーション・データ取得応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド１６０４には、データの長さを示す「２７」が格納される。アプリケーション数フィールド３１０５には、ＨＴＭＬブラウザ７５０が表示可能なデータの数を示す「２」が格納される。
また、図３１において、アプリケーション数フィールド３１０５には、１つ目のデータに対するアプリケーション情報（図３１には、「アプリ情報」と記載している）フィールド３１１１と、２つ目のデータに対するアプリケーション情報（図３１には、「アプリ情報」と記載している）フィールド３１１２とが含まれている。アプリケーションＩＤフィールド３１２１には、１つ目のデータを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション名フィールド３１２４には、データの名前を示す「天気予報」が格納されている。ここで「天気予報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、４文字×２バイト＝８バイトとなっている。アプリケーションＩＤフィールド３１２５には２つ目のデータを表すアプリケーションＩＤとして「２」が格納されている。状態ＩＤフィールド３１２７には、「実行中」を表すアプリケーション状態ＩＤとして「３」が格納されている。アプリケーション名長さフィールド３１２８には、アプリケーション名の長さを示す「１２」が格納される。アプリケーション名フィールド３１２４には、データの名前を示す「レジャー情報」が格納されている。ここで「レジャー情報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、６文字×２バイト＝１２バイトとなっている。
以上で、メッセージフォーマットについての説明を終了する。
再び図４の説明に戻り、通信部７３１は、ナビゲータ７２０またはフォーマットエンジンからメッセージを受け取ると、メッセージに含まれているＤｅｓｔｉｎａｔｉｏｎ
ＩＤフィールドを調べ、対応するフォーマットエンジンあるいはナビゲータ７２０に当該メッセージを配送する。例えば、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに「０」が格納されている場合、通信部７３１は、全てのフォーマットエンジンおよびナビゲータ７２０にメッセージを送信する（図１８参照）。従って、ナビゲータ７２０は、全てのフォーマットエンジンを終了させたい場合、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドが「０」であり、メッセージＩＤが「５」であるメッセージを通信部３１へ送ればよい。
状態管理部７３２は、フォーマットエンジンの動作状態、およびフォーマットエンジンが実行可能なアプリケーションおよび表示可能なデータの動作状態を保持する。具体的には、状態管理部７３２は、それらの情報を２次記憶部１０８あるいは１次記憶部１０９に記憶する。
図３２〜図３４は、状態管理部７３２が保持している情報の一例を示す図である。図３２は、フォーマットエンジンに関する情報を表形式で表した例である。図３２において、最も左側の列は、各フォーマットエンジンを識別するためのフォーマットエンジンＩＤである。ここでは、各フォーマットエンジンのフォーマットエンジンＩＤは、図１８で規定されたサブプログラムＩＤと同じであるとする。左から２番目の列は、各フォーマットエンジンの名前である。左から３番目の列は、各フォーマットエンジンの動作状態を表す動作状態ＩＤである。図３２に示す表において、動作状態ＩＤは、図２１において規定される値によって表される。最も右側の列は、各フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータに関する情報の格納位置を示すポインターである。実行可能なアプリケーションあるいは表示可能なデータを持たないフォーマットエンジンに関しては、当該列は「ＮＵＬＬ」と記述される。
また、図３２に示す表において上から２番目の行には、Ｊａｖａミドルウェア７４０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「２」、名前が「Ｊａｖａミミドルウェア」、動作状態ＩＤが、「停止中」を意味する「３」、実行可能なアプリケーションに関する情報に対するポインターが１６進数表記で「０ｘ５６７８」と記述されている。上から３番目の行には、ＨＴＭＬブラウザ７５０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「３」、名前が「ＨＴＭＬブラウザ」、動作状態ＩＤが、「停止中」を意味する「３」、表示可能なデータに関する情報に対するポインターが１６進数表記で「０ｘ７１６２」と記述されている。上から４番目の行には、メーラー７６０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「４」、名前が「メーラー」、動作状態ＩＤが、「停止中」を意味する「３」と記述されている。また、アプリケーション・データに関する情報はないので、ポインターが「ＮＵＬＬ」と記述されている。
図３３は、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションに関する情報を表形式で表した例を示す図である。この情報は、１次記憶部１０９中の格納位置０ｘ５６７８から格納されている。図３３において左側の列には、各アプリケーションに割り当てられたアプリケーションＩＤが記述される。中央の列には、アプリケーションの名前が記述される。右側の列には、アプリケーション状態ＩＤが記述される。上から２番目の行には、アプリケーションＩＤが「１」、名前が「ＥＰＧ」、アプリケーション状態ＩＤが、「停止中」を表す「３」と記述されている。上から３番目の行には、アプリケーションＩＤが「２」、名前が「トランプゲーム」、アプリケーション状態ＩＤが、「停止中」を表す「３」と記述されている。
図３４は、ＨＴＭＬブラウザ７５０が実行可能なデータに関する情報を表形式で表した例を示す図である。この情報は、１次記憶部１０９中の格納位置０ｘ７１６２から格納されている。図３４において左側の列には、各データに割り当てられたデータＩＤが記述されている。中央の列には、データの名前が記述されている。右側の列には、データの状態を表すアプリケーション状態ＩＤが記述されている。上から２番目の行には、アプリケーションＩＤが「１」、名前が「天気予報」、アプリケーション状態ＩＤが、「実行中」を表す「１」と記述されている。上から３番目の行には、アプリケーションＩＤが「２」、名前が「レジャー情報」、アプリケーション状態ＩＤが、「実行中」を表す「１」と記述されている。
再び図４の説明に戻る。上述したように、通信部７３１は、メッセージに含まれるＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに格納されたデータに従ってメッセージを配送する。ここで、「フォーマットエンジン状態要求」メッセージおよび「アプリケーション・データ一覧要求」メッセージに関しては、通信部７３１は、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドを無視して、状態管理部７３２に配送してもよい。状態管理部７３２は、各フォーマットエンジンの状態を保持しているので、各フォーマットエンジンに代わって「フォーマットエンジン状態要求」メッセージ、「フォーマットエンジン状態応答」メッセージ、あるいは「アプリケーション・データ一覧応答」メッセージを生成することができる。状態管理部７３２がこれらのメッセージを生成することによって、プロセス間通信やスレッド間通信を省略することができるので、短時間での応答を実現することができる。
状態管理部７３２は、常に最新のフォーマットエンジンの動作状態を保持する。従って、状態管理部７３２は、必要に応じて各フォーマットエンジンから情報を取得する。すなわち、まず、デジタルテレビ１００に電源が投入されると、状態管理部７３２は、各フォーマットエンジンに対して「フォーマットエンジン状態要求」メッセージを送る。そして、状態管理部７３２は、各フォーマットエンジンから「フォーマットエンジン状態応答」メッセージを受け取り、受け取ったメッセージに基づいて各フォーマットエンジンの動作状態を１次記憶部１０９に記憶する。また、状態管理部７３２は、各フォーマットエンジンに対して「アプリケーション・データ一覧要求」メッセージを送る。そして、状態管理部７３２は、各フォーマットエンジンから「アプリケーション・データ一覧応答」メッセージを受け取り、受け取ったメッセージに基づいて各アプリケーションおよび各データのアプリケーション状態を１次記憶部１０９に記憶する。
さらに、状態管理部７３２は、フォーマットエンジンから「フォーマットエンジン状態変化」メッセージを受け取ると、当該フォーマットエンジンに対して「フォーマットエンジン状態要求」メッセージを送る。そして、状態管理部７３２は、メッセージを送ったフォーマットエンジンから「フォーマットエンジン状態応答」メッセージを受け取り、受け取ったメッセージに基づいて各フォーマットエンジンの動作状態を１次記憶部１０９に記憶する。
次に、図３５〜図３８を用いて、メーラー７６０の動作状態が変化する場合におけるメッセージのやり取りを説明する。図３５は、メーラー７６０が送信する「フォーマットエンジン状態変化」メッセージの一例を示す図である。図３５に示すメッセージ３５００は、メーラー７６０から全フォーマットエンジンへの「フォーマットエンジン状態変化」メッセージの一例である。メッセージ３５００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３５０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３５０２には、全部を表すサブプログラムＩＤとして「０」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３５０３には、動作状態ＩＤとして「フォーマットエンジン状態変化」を表す「３」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３５０４には、データの長さを表す「０」が格納される。
状態管理部７３２は、図３５に示すメッセージ３５００を受け取ると、図３６に示されるメッセージ３６００をメーラー７６０に送る。図３６は、状態管理部７３２が送信するメッセージの一例を示す図である。図３６に示すメッセージ３６００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３６０１には、結合部７３０を表すサブプログラムＩＤとして「５」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３６０２には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３６０３には、メッセージＩＤとして「フォーマットエンジン状態取得」を表す「１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３６０４には、データの長さを表す「０」が格納される。
メーラー７６０は、図３６に示すメッセージ３６００を受け取ると、図３７で示されるメッセージ３７００を結合部７３０の状態管理部７３２に送る。図３７は、メーラー７６０が送信するメッセージの一例を示す図である。図３７に示すメッセージ３７００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３７０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３７０２には、結合部７３０を表すサブプログラムＩＤとして「５」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３７０３には、メッセージＩＤとして、「フォーマットエンジン取得応答」を表す「２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３７０４には、データの長さを表す「１」が格納される。データフィールド３７０５には、動作状態ＩＤとして「実行中」を表す「１」が格納される（図２１参照）。
図３７に示すメッセージ３７００が結合部７３０の状態管理部７３２へ送信された結果、状態管理部７３２は、メーラー７６０の状態が「実行中」に変化したことを知ることができる。このとき、メッセージ３７００の受信前の状態が図３２に示す状態であったとすると、状態管理部７３２は、図３８に示すように、１次記憶部１０９に記憶している情報を更新する。図３８は、図３２の変化後の状態を示す図である。図３８では、メーラー７６０の動作状態ＩＤが「１」になっている。
また、状態管理部７３２は、フォーマットエンジンから「アプリケーション・データ一覧変化」メッセージを受け取ると、「フォーマットエンジン状態変化」メッセージの場合と同様、最新の状態を取り直す。すなわち、状態管理部７３２は、メッセージを送ってきたフォーマットエンジンに対して、「アプリケーション・データ一覧要求」メッセージを送る。そして、状態管理部７３２は、当該フォーマットエンジンから「アプリケーション・データ一覧応答」メッセージを受け取り、受け取ったメッセージに基づいて各アプリケーションおよび各データのアプリケーション状態を１次記憶部１０９に記憶する。
以上のようにして、状態管理部７３２は、各フォーマットエンジン、フォーマットエンジンが実行するアプリケーション、およびフォーマットエンジンが表示するデータの最新の情報を保持することができる。
次に、図３９〜図４４を用いて、リソース管理部７３３について説明する。なお、リソース管理部７３３は、上述した第２の動作例の動作を行う際に必要となる構成であって、第１の動作例の動作を行う場合には不要である。
リソース管理部７３３は、複数のフォーマットエンジン間で発生したリソースの競合を解決するための情報を提供する。図３９は、リソース管理部７３３の内部構成を示すブロック図である。図３９において、リソース管理部７３３は、プロセス記憶部３９０１と、優先度記憶部３９０２と、最新起動記憶部３９０３と、リソースＩＤ記憶部３９０４と、フォーマットエンジン特定部３９０５と、優先度情報提供部３９０６と、リソース剥奪通知部３９０７とを備えている。
プロセス記憶部３９０１は、２次記憶部１０８あるいは１次記憶部１０９によって実現され、各フォーマットエンジンを実行しているプロセスあるいはスレッドの情報を保持する。ここで、各フォーマットエンジンはプロセス上で実行されているとする。
図４０は、プロセス記憶部３９０１において記憶されている情報の一例を示す図である。図４０においては、プロセス記憶部３９０１は、各フォーマットエンジンを実行しているプロセスＩＤを表形式で記憶している。図４０において、左側の列には、フォーマットエンジンＩＤ（ＦＩＤ）が記述されている。右側の列には、各フォーマットエンジンを実行しているプロセスを識別するためのプロセスＩＤが記述されている。プロセスＩＤは、ＯＳ７１０のカーネル７１１によって生成されるプロセスのＩＤである。リソース管理部７３３は、カーネル７１１からプロセスＩＤを受け取ってプロセス記憶部３９０１に記憶する。一方、上から２番目の行には、Ｊａｖａミドルウェア７４０のフォーマットエンジンＩＤである「２」（図１８参照）と、Ｊａｖａミドルウェア７４０を実行しているプロセスのプロセスＩＤである「１００」とが記述されている。上から３番目の行には、ＨＴＭＬブラウザ７５０のフォーマットエンジンＩＤである「３」（図１８参照）と、ＨＴＭＬブラウザ７５０を実行しているプロセスのプロセスＩＤである「１１０」とが記述されている。上から４番目の行には、メーラー７６０のフォーマットエンジンＩＤである「４」（図１８参照）と、メーラー７６０を実行しているプロセスのプロセスＩＤである「１２０」とが記述されている。
図３９の説明に戻り、優先度記憶部３９０２は、２次記憶部１０８、１次記憶部１０９あるいはＲＯＭ１１０によって実現される。優先度記憶部３９０２は、各フォーマットエンジンの優先度を記憶する。
図４１は、優先度記憶部３９０２に記憶されている情報の一例を示す図である。図４１において、優先度記憶部３９０２は、各フォーマットエンジンの優先度を表形式で記憶している。図４１において、左側の列には、フォーマットエンジンＩＤ（ＦＩＤ）が記述されている。右側の列には、各フォーマットエンジンの優先度が記述されている。ここで、優先度は値が大きいほど優先度が高いとする。また、上から２番目の行には、ＪａｖａミドルウェアのフォーマットエンジンＩＤである「２」と、それに対応する優先度である「２」とが記述されている。上から３番目の行には、ＨＴＭＬブラウザのフォーマットエンジンＩＤである「３」と、それに対応する優先度「１」とが記述されている。上から４番目の行には、メーラーのフォーマットエンジンＩＤである「４」と、それに対応する優先度「４」とが記述されている。
図３９の説明に戻り、最新起動記憶部３９０３は、２次記憶部１０８あるいは１次記憶部１０９によって実現される。最新起動記憶部３９０３は、ナビゲータ７２０から送られてきた「フォーマットエンジン実行」メッセージ、または「アプリケーション・データ実行」メッセージに含まれているＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに記述されたフォーマットエンジンＩＤを記憶する。つまり、最新起動記憶部３９０３は、最新起動情報を記憶する。最新起動情報とは、ユーザが最後に実行を要求したフォーマットエンジンを示す情報である。
図４２は、最新起動記憶部３９０３が記憶している情報の一例を示す図である。図４２では、最新起動記憶部３９０３は、メーラー７６０のフォーマットエンジンＩＤである「４」を格納している。図４２に示す状態において、ナビゲータ７２０が、結合部７３０を通してＨＴＭＬブラウザ７５０に「フォーマットエンジン実行」メッセージ、あるいはアプリケーション・データ実行」メッセージを送った場合を考える。この場合、リソース管理部７３３は、最新起動記憶部３９０３に記憶される情報を、ＨＴＭＬブラウザ７５０を表すフォーマットエンジンＩＤである「３」に更新する。
図３９の説明に戻り、リソースＩＤ記憶部３９０４は、２次記憶部１０８あるいはＲＯＭ１１０によって実現される。リソースＩＤ記憶部３９０４は、リソース管理部７３３が管理対象とするリソースを識別するためのリソースＩＤ（ＲＩＤ）を記憶する。
図４３は、リソースＩＤ記憶部３９０４が記憶している情報の一例を示す図である。図４３においては、リソースＩＤ記憶部３９０４は、リソースＩＤを表形式で記憶する。図４３において、左側の列にはリソースＩＤが記述されている。右側の列には、対応するリソースの名前が記述されている。図４３では、管理対象のリソースとして、チューナ１０１、ＴＳデコーダ１０３、オーディオデコーダ１０４、ビデオデコーダ１０６、ネットワークインターフェース１１２が規定されている。これらのリソースに対してリソースＩＤが割り当てられている。図４４は、リソースＩＤの定義をプログラミング言語であるＣ言語で記述した例を示す図である。
図３９の説明に戻り、フォーマットエンジン特定部３９０５は、リソースを要求しているフォーマットエンジンを特定する。各フォーマットエンジンは、ＯＳ７１０のライブラリ７１２が提供する機能を利用する。例えば、チューナ１０１を制御するチューナＬｉｂ７１２１を呼び出し、特定の周波数帯にチューニングを行う。これを実現するために、フォーマットエンジンは、チューナＬｉｂ７１２１が用意する関数を呼び出す。フォーマットエンジンから要求があると、すなわち、フォーマットエンジンが関数の呼び出しを行うと、チューナＬｉｂ７１２１は、どのフォーマットエンジンが当該関数を呼び出しているのかをフォーマットエンジン特定部３９０５に問い合わせる。この問い合わせに応じて、フォーマットエンジン特定部３９０５は、関数を呼び出しているプロセスを特定する。そして、フォーマットエンジン特定部３９０５は、特定したプロセスのプロセスＩＤ、およびプロセス記憶部３９０１が記憶しているフォーマットエンジンＩＤとプロセスＩＤとの組を参照することによって、関数を呼び出したフォーマットエンジンを特定する。
優先度情報提供部３９０６は、優先度記憶部３９０２が記憶しているフォーマットエンジンの優先度と、最新起動記憶部３９０３が記憶している、ユーザが最後に起動したフォーマットエンジンの情報とをライブラリ７１２に提供する。ライブラリ７１２は、フォーマットエンジン特定部３９０５および優先度情報提供部３９０６を利用することによって、どのフォーマットエンジンにリソースを提供するかを決定することができる。以下、具体的に説明する。
例えば、チューナＬｉｂ７１２１は、Ｊａｖａミドルウェア７４０から呼び出され、チューニングを行っているとする。なお、チューナＬｉｂ７１２１は、フォーマットエンジン特定部３９０５を利用することによって、Ｊａｖａミドルウェア７４０が現在チューナ１０１を利用していることを知っている。この状態において、メーラー７６０がチューナＬｉｂ７１２１を呼び出し、他の周波数帯にチューニングしようとする場合を考える。チューナＬｉｂ７１２１は、フォーマットエンジン特定部３９０５を利用することによって、メーラー７６０がチューナ１０１の機能を利用していることを知る。次に、チューナＬｉｂ７１２１は、優先度情報提供部３９０６から最後に起動したフォーマットエンジンの情報を取得する。そして、チューナＬｉｂ７１２１は、最後に起動したフォーマットエンジンがメーラー７６０であれば、メーラー７６０にチューナ１０１の利用を許可する。一方、最後に起動したフォーマットエンジンがＪａｖａミドルウェア７４０であれば、メーラー７６０に対してチューナ１０１の利用を拒否する。最後に起動したフォーマットエンジンがメーラー７６０でもＪａｖａミドルウェア７４０でもない場合は、優先度情報提供部３９０６からメーラー７６０およびＪａｖａミドルウェア７４０の優先度を取得する。メーラー７６０の優先度がＪａｖａミドルウェア７４０の優先度よりも高い場合、チューナＬｉｂ７１２１は、メーラー７６０にチューナ１０１の使用を許す。一方、メーラー７６０の優先度がＪａｖａミドルウェア７４０の優先度よりも低い場合、メーラー７６０に対して、チューナ１０１の使用を拒否する。以上のようにして、ライブラリ７１２は、どのフォーマットエンジンにリソースを提供するかを決定することができる。
なお、ライブラリ７１２が、最後に起動したフォーマットエンジンの情報や優先度情報をどのように用いるかは自由であり、ここに紹介したのはその一例である。どのフォーマットエンジンに対してリソースの利用を許可するかを決定するためのルールは、どのようなものであってもよい。例えば、ライブラリ７１２は、優先度情報のみを用いてリソースの利用を許可するフォーマットエンジンを決定してもよい。また、ライブラリ７１２は、先に使用しているフォーマットエンジンに対して利用を許可してもよい。逆に、ライブラリ７１２は、後から呼び出したフォーマットエンジンに対して利用を許可してもよい。
図３９において、リソース剥奪通知部３９０７は、リソースの利用が許可されなかったフォーマットエンジンに対して、リソースが剥奪されたことを通知する。例えば、Ｊａｖａミドルウェア７４０がチューナＬｉｂ７１２１を呼び出し、チューナ１０１を使用しているとき、メーラー７６０がチューナＬｉｂ７１２１を呼び出し、チューナ１０１の使用を試みた場合を考える。ここで、もし、チューナＬｉｂ７１２１がメーラー７６０にチューナ１０１の使用を許すと、Ｊａｖａミドルウェア７４０が希望している周波数帯とは異なる周波数帯にチューニングされる。従って、Ｊａｖａミドルウェア７４０上で実行されているアプリケーションは正しい動作を続けることができなくなるおそれがある。これを防ぐために、チューナＬｉｂ７１２１は、チューナリソースが剥奪されたことをＪａｖａミドルウェア７４０に通知するように、リソース剥奪通知部３９０７に依頼する。この依頼の際には、リソースが剥奪されたことを通知すべきフォーマットエンジンのフォーマットエンジンＩＤとリソースＩＤとがリソース剥奪通知部３９０７に渡される。なお、ライブラリ７１２は、フォーマットエンジンＩＤをフォーマットエンジン特定部３９０５から取得することによって知ることができる。また、ライブラリ７１２は、リソースＩＤ記憶部３９０４を参照することによってライブラリ７１２を予め知っている。リソース剥奪通知部３９０７は、フォーマットエンジンＩＤおよびリソースＩＤを受け取ると、フォーマットエンジンＩＤにより示されるフォーマットエンジンにリソースが剥奪されたことを通知する。なお、通知を受けたフォーマットエンジンの動作は、各フォーマットエンジンに依存する。動作続行が困難なフォーマットエンジンであれば、実行中から停止中あるいは一時停止中に動作状態を変化させるようにしてもよい。以上でリソース管理部７３３の説明を終了する。
次に、図４５〜図７１を用いて、各フォーマットエンジンの詳細を説明する。
まず、図４５〜図５１を用いて、Ｊａｖａミドルウェア７４０について説明する。Ｊａｖａミドルウェア７４０は、Ｊａｖａアプリケーションを実行するフォーマットエンジンである。本構成例においては具体的な例として、ＤＶＢ−ＭＨＰ１．０規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）を取り上げるが、例えばアプレットビューワ等、他の仕様に従って動作するものでも実施可能である。本構成例では、Ｊａｖａミドルウェア７４０の詳細な動作にはＤＶＢ−ＭＨＰ１．０規格の内容が含まれる。従って、ここでは、概略のみを記述する。
図４５は、Ｊａｖａミドルウェア７４０の構成を示すブロック図である。Ｊａｖａミドルウェア７４０は、Ｊａｖａバーチャルマシン（ＶＭ）４５０１と、クラスライブラリ４５０２と、アプリケーションマネージャ４５０３とを備えている。
ＪａｖａＶＭ４５０１は、Ｊａｖａ（ＴＭ）言語で記述されたアプリケーションを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウエアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵ１１３が理解可能な実行形式に翻訳してから、ＣＰＵ１１３に引き渡し、実行することも行う。クラスライブラリ４５０２およびアプリケーションマネージャ４５０３の一部または全部もＪａｖａ言語で記述されており、ＪａｖａＶＭ４５０１によって実行される。本構成例では、ＯＳ７１０のカーネル７１１は、最初に実行するＪａｖａアプリケーションとしてアプリケーションマネージャ４５０３を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。従って、ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
クラスライブラリ４５０２は、ＲＯＭ１１０に格納されている複数のＪａｖａクラスライブラリの集合である。その多くは、ＯＳ７１０のライブラリ７１２が提供する機能に対応するＪａｖａアプリケーションが呼び出し可能なＪａｖａ  ＡＰＩを提供する。この結果、Ｊａｖａアプリケーションはデジタルテレビ１００が有する機能を利用することができる。例えば、ＤＶＢ−ＭＨＰ１．０規格では、チューナ１０１を使用するためのＡＰＩとしてｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｔｕｎｉｎｇパッケージを規定し、Ｊａｖａアプリケーションがチューナ１０１を制御できるようにしている。
アプリケーションマネージャ４５０３は、放送波中に多重化されているＪａｖａアプリケーションをダウンロードし、実行する。ＭＨＰ１．０規格によれば、ＡＩＴと呼ばれるＪａｖａアプリケーションを定義する表が放送波中に多重化されて伝送される。アプリケーションマネージャ４５０３は、このＡＩＴを最初にダウンロードする。ＡＩＴにはアプリケーションをダウンロードするための情報やアプリケーションの名前、アプリケーションの制御情報などが含まれる。
図４６は、ＡＩＴの主要部を表した模式図である。図４６において最も左側の列には、ＪａｖａアプリケーションＩＤが記述されている。左から２番目の列には、Ｊａｖａアプリケーションの制御情報が記述されている。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」等がある。「ａｕｔｏｓｔａｒｔ」は、Ｊａｖａミドルウェア７４０がそのＪａｖａアプリケーションを即時にかつ自動的に実行することを意味する。「ｐｒｅｓｅｎｔ」は、自動実行しないことを意味する。「ｋｉｌｌ」は、Ｊａｖａアプリケーションを停止することを意味する。左から３番目の列は、Ｊａｖａアプリケーションのアプリケーション名が記述されている。最も右側の列には、Ｊａｖａアプリケーションの優先度が記述されている。Ｊａｖａアプリケーション間でリソースの競合が発生した場合、優先度の高いＪａｖａアプリケーションにリソースが優先的に割り当てられる。ここで、優先度の値が大きいほど優先度が高いこととする。
図４６において上から２番目および３番目の行には、Ｊａｖａアプリケーションの情報の組が記述される。上から２番目の行において定義されるＪａｖａアプリケーションについては、ＪａｖａアプリケーションＩＤが「１」であり、制御情報が「ａｕｔｏｓｔａｒｔ」であり、アプリケーション名が「ＥＰＧ」であり、優先度が「６４」である。上から３番目の行において定義されるＪａｖａアプリケーションについては、ＪａｖａアプリケーションＩＤが「２」であり、制御情報が「ｐｒｅｓｅｎｔ」であり、アプリケーション名が「トランプゲーム」であり、優先度「３２」である。
アプリケーションマネージャ４５０３は、ＡＩＴを受け取ると、アプリケーション名「ＥＰＧ」のＪａｖａアプリケーションをダウンロードし実行する。ここで、ＤＶＢ−ＭＨＰ１．０規格が規定するＪａｖａアプリケーションは、「Ｌｏａｄｅｄ」、「Ｐａｕｓｅｄ」、「Ａｃｔｉｖｅ」、および「Ｄｅｓｔｒｏｙｅｄ」という４つの動作状態を有している。
図４７は、Ｊａｖａアプリケーションの４つの動作状態および動作状態間の遷移を表す状態遷移図である。アプリケーションマネージャ４５０３がＪａｖａアプリケーションをダウンロードし、当該Ｊａｖａアプリケーションが１次記憶部１０９に格納されると、当該Ｊａｖａアプリケーションの動作状態は「Ｌｏａｄｅｄ」になる。この動作状態から他の動作状態への遷移は、ダウンロードしたＪａｖａアプリケーションが実装している「ｉｎｉｔＸｌｅｔ」、「ｓｔａｒｔＸｌｅｔ」、「ｐａｕｓｅＸｌｅｔ」、および「ｄｅｓｔｒｏｙＸｌｅｔ」というメソッドをアプリケーションマネージャ４５０３が呼び出すことにより実現する。
「Ｌｏａｄｅｄ」の動作状態でアプリケーションマネージャ４５０３が「ｉｎｉｔＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は、「Ｐａｕｓｅｄ」に遷移する。「Ｐａｕｓｅｄ」の動作状態でアプリケーションマネージャ４５０３が「ｓｔａｒｔＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は「Ａｃｔｉｖｅ」に遷移する。「Ａｃｔｉｖｅ」の動作状態でアプリケーションマネージャ４５０３が「ｐａｕｓｅＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は、「Ｐａｕｓｅｄ」に遷移する。どの動作状態の場合においても、アプリケーションマネージャ４５０３が「ｄｅｓｔｒｏｙＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は「Ｄｅｓｔｒｏｙｅｄ」に遷移する。
アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションの状態遷移を、（１）放送波中のＡＩＴの制御情報、（２）Ｊａｖａアプリケーションの指示、および（３）ナビゲータ７２０が結合部７３０を通して送る指示、の３通りの指示に従って行う。
ＡＩＴの制御情報が「ａｕｔｏｓｔａｒｔ」の場合、アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションをダウンロードした後、「ｉｎｉｔＸｌｅｔ」メソッド、「ｓｔａｒｔＸｌｅｔ」メソッドを呼び出し、「Ａｃｔｉｖｅ」状態に遷移させる。ＡＩＴは、時間と共に変化する。例えば、ＡＩＴが図４６から図４８に変化したとする。図４８では、「ＥＰＧ」という名前のアプリケーションの制御情報が「ａｕｔｏｓｔａｒｔ」から「ｋｉｌｌ」に変更されている。このとき、アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションの「ｄｅｓｔｒｏｙＸｌｅｔ」メソッドを呼び出し、「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させる。
一方、Ｊａｖａアプリケーションは、自分自身の状態や他のＪａｖａアプリケーションの状態を遷移させることができる。ＤＶＢ−ＭＨＰ１．０規格では、Ｊａｖａアプリケーションが自身の状態を遷移させたいときは、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＤｅｓｔｒｏｙｅｄ」、「ｎｏｔｉｆｙＰａｕｓｅｄ」、および「ｒｅｓｕｍｅＲｅｑｕｅｓｔ」メソッドのいずれかを呼び出す。「Ｄｅｓｔｒｏｙｅｄ」状態に遷移するには、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＤｅｓｔｒｏｙｅｄ」を呼び出す。「Ａｃｔｉｖｅ」状態に遷移させるには、Ｊａｖａアプリケーションは、「ｒｅｓｕｍｅＲｅｑｕｅｓｔ」メソッドを呼び出す。「Ｐａｕｓｅｄ」状態に遷移するには、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＰａｕｓｅｄ」を呼び出す。他のＪａｖａアプリケーションの状態を遷移させる場合、Ｊａｖａアプリケーションは、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｔｉｏｎパッケージが規定するメソッドを利用する。すなわち、まず、他のＪａｖａアプリケーションをアプリケーションＩＤによって指定した後、Ｊａｖａアプリケーションは、ｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｔｉｏｎパッケージが規定するメソッドを呼び出し、指定したＪａｖａアプリケーションの状態を遷移させる。ここでは詳細は省略する。
最後にナビゲータ７２０からの指示によってＪａｖａアプリケーションの状態を遷移する方法を説明する。ナビゲータ７２０は、共通状態、すなわち、結合部７３０が規定しているフォーマットエンジンの動作状態またはフォーマットエンジンが実行可能なアプリケーションの動作状態に基づいて指示を出す。この共通状態は、個別状態、すなわち、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３が実行するＪａｖａアプリケーションの動作状態とは異なっている。この共通状態と個別状態との間のギャップを第１の変換部７４１が埋めるのである。第１の変換部７４１は、ナビゲータ７２０からの指示を、Ｊａｖａミドルウェア７４０が取り扱う動作状態に変換する。その結果、アプリケーションマネージャ４５０３は、ＡＩＴの制御情報やＪａｖａアプリケーションからの指示と同等の指示を受け、Ｊａｖａアプリケーションの動作状態を遷移させることができる。
第１の変換部７４１は、結合部７３０からのメッセージを変換してＪａｖａミドルウェア７４０に伝え、また、Ｊａｖａミドルウェア７４０の情報を変換して結合部７３０に伝えることにより、Ｊａｖａミドルウェア７４０の動作を結合部７３０が規定する状態に適合させる。ここまで、様々なメッセージを、結合部７３０を通してＪａｖａミドルウェア７４０に配送すると記述してきたが、正確には、これらのメッセージは、Ｊａｖａミドルウェア７４０ではなく第１の変換部７４１に送信される。第１の変換部７４１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの状態に基づいてＪａｖａミドルウェア７４０の状態を決定する。そして、第１の変換部７４１は、「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０へ送る。
図４９は、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態と、Ｊａｖａミドルウェア７４０の動作状態との対応を示す変換表の一例を示す図である。図４９において左側の列には、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態が記述されている。右側の列には、対応するＪａｖａミドルウェア７４０の動作状態が記述されている。ここで、Ｊａｖａミドルウェア７４０の状態は、結合部７３０が規定した状態、すなわち共通状態である。具体的には、図２１で示した「実行中」、「一時停止中」、および「停止中」という３つの動作状態である。上から２番目から４番目の行には、これら３つの動作状態に対応する、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態が規定されている。
まず、上から２番目の行には、全てのＪａｖａアプリケーションの中に１つでも「Ａｃｔｉｖｅ」という動作状態のＪａｖａアプリケーションがあることに対しては、Ｊａｖａミドルウェア７４０の動作状態として「実行中」が対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションは極小リソースを使用している可能性が高いため、このような対応関係を規定したものである。
次に、上から３番目の行には、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがなく、かつ、全Ｊａｖａアプリケーションの中で１つでも「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがあることに対して、Ｊａｖａミドルウェア７４０の動作状態として「一時停止中」が対応付けられている。ＤＶＢ−ＭＨＰ１．０規格によれば、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションは、必要最小限のリソース以外は解放すべきと記述されている。よって、このような対応関係を規定した。
次に、上から４番目の行には、上から２番目および３番目の行に示す場合以外の場合に対して、「停止中」が対応付けられている。上から２番目および３番目の行に示す場合以外の場合とは、具体的には、全てのＪａｖａアプリケーションが、「Ｌｏａｄｅｄ」あるいは「Ｄｅｓｔｒｏｙｅｄ」という動作状態、あるいは読み込みも完了していない動作状態にある場合である。この場合、Ｊａｖａアプリケーションのコードは１つも実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
前述した通り、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３は、ＡＩＴの制御情報の変化やＪａｖａアプリケーションの指示により、Ｊａｖａアプリケーションの状態を遷移させる。第１の変換部７４１は、状態変化の通知をアプリケーションマネージャ４５０３から受ける。その結果としてＪａｖａミドルウェアの共通状態が変化する場合には、第１の変換部７４１は、図４９の変換表を参照して、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。この場合、第１の変換部７４１は、１次記憶部１０９にＪａｖａミドルウェアの共通状態を保存しておく。そして、第１の変換部７４１は、Ｊａｖａアプリケーションの状態が変化した後のＪａｖａミドルウェアの共通状態と比較する。なお、第１の変換部７４１は、Ｊａｖａアプリケーションの状態の変化をアプリケーションマネージャ４５０３から通知されたとき、常に「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知してもよい。
第１の変換部７４１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴで規定された所定のＪａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。ここで所定のＪａｖａアプリケーションとは、ＡＩＴに規定されている全てのＪａｖａアプリケーションであってもよいし、優先度が最も高いＪａｖａアプリケーションであってもよい。所定のＪａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるべきＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでに「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションが存在する場合、第１の変換部７４１は何もしないこととしてもよい。
第１の変換部７４１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴに規定された全てのＪａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。ただし、読み込んでいないＪａｖａアプリケーションに対しては何もしなくてもよい。全てのＪａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｄｅｓｔｒｏｙｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全Ｊａｖａアプリケーションに対して行えばよい。
第１の変換部７４１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴに規定されたＪａｖａアプリケーションの中で「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションを見つけ、そのＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、そのＪａｖａアプリケーションの状態を取得する。もし状態が「Ａｃｔｉｖｅ」であれば、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全てのＪａｖａアプリケーションに対して行えばよい。
第１の変換部７４１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴが定義している全てのＪａｖａアプリケーションおよびその状態に基づいて、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。「アプリケーション・データ一覧応答」メッセージに含めるアプリケーション名は、ＡＩＴが規定するアプリケーション名がそのまま使用される。「アプリケーション・データ一覧応答」メッセージに含める状態ＩＤは、各Ｊａｖａアプリケーションの状態を結合部７３０が規定する共通状態に変換表を用いて変換することによって作成される。
図５０は、各Ｊａｖａアプリケーションの動作状態を共通状態に変換するための変換表の一例を示す図である。図５０において左側の列には、個別状態、すなわち、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態が記述されている。右側の列には、対応する共通状態が記述されている。上から２番目の行に示されるように、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態「Ａｃｔｉｖｅ」は、「実行中」という共通状態に対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションは極小リソースを使用している可能性が高いので、このような対応関係を規定した。
また、図５０において上から３番目の行に示されるように、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態「Ｐａｕｓｅｄ」は、「一時停止中」という共通状態に対応付けられている。ＤＶＢ−ＭＨＰ１．０規格によれば、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションは、必要最小限のリソース以外は解放すべきと記述されている。よって、このような対応関係を規定した。
また、上から４番目の行に示されるように、上から２番目および３番目の行以外の場合のＪａｖａアプリケーションの動作状態に対しては、「停止中」という共通状態が対応付けられている。上から２番目および３番目の行以外の場合とは、具体的には、Ｊａｖａアプリケーションの動作状態が、Ｊａｖａアプリケーションが「Ｌｏａｄｅｄ」もしくは「Ｄｅｓｔｒｏｙｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、Ｊａｖａアプリケーションのコードは１つも実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
今、アプリケーション名が「ＥＰＧ」であるＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であり、アプリケーション名が「トランプゲーム」であるＪａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」であるように、ＡＩＴにおいて定義されている場合を考える。この場合、第１の変換部７４１は、「アプリケーション・データ一覧要求」メッセージを受け取ると、図５１に示す「アプリケーション・データ一覧応答」メッセージ５１００を生成し、結合部７３０に送信する。
図５１は、第１の変換部７４１が送信するメッセージの具体例を示す図である。図５１に示すメッセージ５１００は、Ｊａｖａミドルウェア７４０からナビゲータ７２０への「アプリケーション・データ取得応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド５１０１には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤとして「２」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド５１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド５１０３には、「アプリケーション・データ取得応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド５１０４には、データの長さを示す「２７」が格納される。アプリケーション数フィールド５１０５には、Ｊａｖａミドルウェア７４０が受け取ったＡＩＴに規定されているＪａｖａアプリケーション数である「２」が格納される。
また、図５１において、アプリケーション数フィールド５１０５には、１つ目のＪａｖａアプリケーションに対するアプリケーション情報フィールド５１１１と、２つ目のＪａｖａアプリケーションに対するアプリケーション情報フィールド５１１２とが含まれている。アプリケーションＩＤフィールド５１２１には、１つ目のＪａｖａアプリケーションを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション状態ＩＤフィールド５１２２には、「実行中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「実行中」は、Ｊａｖａアプリケーションの動作状態「Ａｃｔｉｖｅ」が変換された結果である。アプリケーション名長さフィールド５１２３には、アプリケーション名の長さを示す「６」が格納される。アプリケーション名フィールド５１２４には、ＡＩＴで定義されたアプリケーション名「ＥＰＧ」が格納されている。ここで「ＥＰＧ」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、３文字×２バイト＝６バイトとなっている。アプリケーションＩＤフィールド５１２５には２つ目のＪａｖａアプリケーションを表すアプリケーションＩＤとして「２」が格納されている。状態ＩＤフィールド５１２６には、「停止中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「停止中」は、Ｊａｖａアプリケーションの動作状態「Ｄｅｓｔｒｏｙｅｄ」が変換された結果である。アプリケーション名長さフィールド５１２７には、アプリケーション名の長さを示す「１４」が格納される。アプリケーション名フィールド５１２８には、ＡＩＴで定義されたアプリケーション名「トランプゲーム」が格納されている。ここで「トランプゲーム」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、７文字×２バイト＝１４バイトとなっている。
前述した通り、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３は、ＡＩＴの制御情報の変化やＪａｖａアプリケーションの指示によってＪａｖａアプリケーションの動作状態を遷移させる。第１の変換部７４１は、状態変化の通知をアプリケーションマネージャ４５０３より受ける。その時、第１の変換部７４１は、「アプリケーション・データ一覧変化」メッセージを生成して、結合部７３０に通知する。第１の変換部７４１が結合部７３０から「アプリケーション・データ実行」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。Ｊａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでにＪａｖａアプリケーションが「Ａｃｔｉｖｅ」状態の場合、第１の変換部７４１は、何もしないようにしてもよい。
第１の変換部７４１が結合部７３０から「アプリケーション・データ停止」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させるようにアプリケーションマネージャ４５０３に指示する。ただし、読み込んでいないＪａｖａアプリケーションに対しては何もしなくてもよい。Ｊａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｄｅｓｔｒｏｙｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させることができる。
第１の変換部７４１が結合部７３０から「アプリケーション・データ一時停止」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させるようにアプリケーションマネージャ４５０３に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。
さらに、第１の変換部７４１は、結合部７３０のリソース管理部７３３からリソース剥奪の通知を受けてもよい。第１の変換部７４１は、剥奪されたリソースに応じて、アプリケーションマネージャ４５０３にＪａｖａアプリケーションの状態を遷移させることとしてもよい。Ｊａｖａアプリケーションの実行に不可欠なリソースが剥奪された場合、第１の変換部７４１は、全てのＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる。それ以外のリソース、すなわち、Ｊａｖａアプリケーションの実行に必ずしも必要ではないリソースが剥奪された場合については、第１の変換部７４１は、何も行わなくともよい。
また、リソース剥奪通知は、Ｊａｖａミドルウェア７４０が直接受け取り、対応する処理を行ってもよい。以上で、Ｊａｖａミドルウェア７４０の説明を終了する。
次に、図５２〜図７１を用いて、ＨＴＭＬブラウザ７５０について説明する。ＨＴＭＬブラウザ７５０は、ＨＴＭＬデータを解釈し表示を行うフォーマットエンジンである。本構成例においては具体的な例として、ＤＶＢ−ＭＨＰ１．１規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２
ＤＶＢ−ＭＨＰ仕様Ｖ１．１）が規定するＤＶＢ−ＨＴＭＬを取り上げるが、例えば、ＸＨＴＭＬ１．０等の他の仕様に従って動作するものでも実施可能である。本構成例では、ＨＴＭＬブラウザ４５０の詳細な動作にはＤＶＢ−ＭＨＰ１．１規格の内容が含まれる。従って、ここでは、概略のみを記述する。
図５２は、ＨＴＭＬブラウザ７５０の構成を示すブロック図である。ＨＴＭＬブラウザ７５０は、パーザー５２０１と、レイアウター５２０２と、描画部５２０３と、インタラクション部５２０４と、ＨＴＭＬマネージャ５２０５とを備えている。
パーザー５２０１は、ＨＴＭＬマネージャ５２０５がダウンロードしたＤＶＢ−ＨＴＭＬデータの解析を行いＤＯＭ（ドキュメントオブジェクトモデル）ツリーを構築する。図５３は、ＤＶＢ−ＨＴＭＬデータの一例を示す図である。ＤＶＢ−ＨＴＭＬデータに対して、パーザー５２０１は図５５に示すようなＤＯＭツリーを構築する。
レイアウター５２０２は、パーザー５２０１が構築したＤＯＭツリーの各構成要素に対して、ディスプレイ１０７上の表示位置を計算して決定する。図５４は、ＤＶＢ−ＨＴＭＬデータのレイアウトを決めるスタイルシートの一例を示す図である。図５４に示す各行は各々、図５３に示すＤＶＢ−ＨＴＭＬデータ中の各要素５３１１，５３１２，５３１３，および５３１４の表示位置を指定している。ここでは、スタイルシートの例としてＤＶＢ−ＭＨＰが規定するＣＳＳ（Ｗ３Ｃが規定するＣＳＳ２の拡張仕様）を取り上げているが、レイアウトを決めようとするＨＴＭＬデータのスタイルシートとしてレイアウターが解析可能なものであれば、ＣＳＳ２等の他の仕様に従うスタイルシートであっても実施可能である。レイアウター５２０２は、スタイルシートに基づいて、ＤＯＭツリーの各構成要素に対してディスプレイ１０７上の表示位置を決定する。例えば、図５５に示す“Ｗｅａｔｈｅｒ  ｆｏｒｅｃａｓｔ”に対して（５０，５０）で示される表示位置が決定された場合、文字列“Ｗｅａｔｈｅｒ  ｆｏｒｅｃａｓｔ”は、その左上の座標がディスプレイの上から５０ｐｘ，左から５０ｐｘの位置となるように表示される。図５５に示す“Ｊａｐａｎ“に対して（２００，１００）で示される表示位置が決定された場合、文字列“Ｊａｐａｎ“は、その左上の座標が、ディスプレイの上から２００ｐｘ，左から１００ｐｘの位置となるように表示される。
なお、レイアウターがスタイルシートのパーザーを持ち、ＤＯＭツリー構築後においてそのパーザーがＨＴＭＬマネージャから指示を受けることによってスタイルシートを解析・計算し、計算した結果の表示位置をレイアウターに通知してもよい。また、ＨＴＭＬブラウザがデフォルトのスタイルシートを持ち、スタイルシートが存在しない場合は、レイアウターは、ＨＴＭＬブラウザが持つデフォルトのスタイルシートに従い、ＤＯＭツリーの各構成要素に対して、ディスプレイ１０７上の表示位置を計算して決定してもよい。
図５２の説明に戻り、描画部５２０３は、レイアウター５２０２が計算した表示位置に従って、ＤＯＭツリーの各構成要素を描画する。図５６は、図５５に示すＤＯＭツリーを描画した際のディスプレイ１０７を示す図である。
インタラクション部５２０４は、描画したＤＶＢ−ＨＴＭＬデータに含まれるリンクやボタン等に対してユーザが入力した指示に対応する処理を行う。例えば、ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されているとする。ここで、ユーザが、リンクのクリックを入力部１１１から入力すると、インタラクション部５２０４は、リンクに定義されたＤＶＢ−ＨＴＭＬデータの情報をＨＴＭＬマネージャ５２０５に引き渡す。
ＨＴＭＬマネージャ５２０５は、引き渡されたＤＶＢ−ＨＴＭＬデータの情報に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。図５３に示すＤＶＢ−ＨＴＭＬデータ内には、他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている。
図５６において、ディスプレイ上の文字列“Ｊａｐａｎ”として代表されるリンク先「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」のクリックをユーザが入力すると、インタラクション部５２０４は、ＤＶＢ−ＨＴＭＬデータの情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」をＨＴＭＬマネージャ５２０５に引き渡す。ここで、あるリンク先のクリックを入力するとは、そのリンク先をフォーカス５６０１が選択しているときにＯＫボタン３０５を押下することをいう。ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。図５７は、ユーザが文字列“Ｊａｐａｎ”と代表されるリンク先をクリックした後にディスプレイ表示されるＤＶＢ−ＨＴＭＬデータの例を示す図である。
また、例えば、ＤＶＢ−ＨＴＭＬデータ内に定義されたボタンに、ＤＯＭツリーの構成を変更するスクリプトが定義されているとする。ここで、ユーザがボタンのクリックを入力部１１１から入力すると、インタラクション部５２０４は、パーザー５２０１からＤＶＢ−ＨＴＭＬデータを受け取り、ボタンに定義されたスクリプトを実行し、ＤＯＭツリーの構成を変更する。この変更に伴い、レイアウター５２０２が表示位置を再計算し、描画部５２０３は描画をやり直す。また、ＤＯＭツリーを変更したことを、ＨＴＭＬマネージャ５２０５に通知する。
図５８に示すＤＶＢ−ＨＴＭＬデータ内には、ＤＯＭツリーの構成を変更するスクリプト５８０１として”ｃｈａｎｇｅＤＯＭＴｒｅｅ（）”（具体的には、例えば、ＤＯＭツリーにおいてテーブル要素を記述したもの）が定義され、ボタン５８０２のクリック時にそのスクリプト５８０１を実行するよう定義されている。スクリプト５８０１において、ＤＯＭツリーの構成を変更するソースコードは省略されている。。スクリプトは、例えば、ＤＶＢ−ＭＨＰが規定するＤＯＭ（Ｗ３Ｃが規定するＤＯＭ２の拡張仕様）仕様に従うものであっても、ＤＯＭ１、２等の他の仕様に従うスクリプトであっても実施可能である。
図５９は、図５８に示すＤＶＢ−ＨＴＭＬデータに対してパーザー５２０１が構築したＤＯＭツリーの一部を示す図である。また、図６０は、レイアウター５２０２および描画部５２０３によって表示されたディスプレイ表示の例を示す図である。図６０において、ラベル“詳細情報”６００１に代表されるボタン５８０２のクリックをユーザが入力すると、インタラクション部５２０４は、パーザー５２０１からＤＶＢ−ＨＴＭＬデータを受け取る。そして、インタラクション部５２０４は、ボタン５８０２に定義されたスクリプト５８０１を実行してＤＯＭツリーの構成を変更する。また、レイアウター５２０２は、表示位置を最計算する。描画部５２０３は、描画をやり直す。さらに、ＤＯＭツリーを変更したことがＨＴＭＬマネージャ５２０５に通知される。図６１は、ユーザによるボタンのクリックに伴うＤＯＭツリーの変更結果を示す図である。また、図６２は、ディスプレイ表示の変更結果の例を示す図である。
ＨＴＭＬマネージャ５２０５は、放送波中に多重化されているＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈し、表示する。ＭＨＰ１．１規格によれば、放送波中には、ＡＩＴと呼ばれるＤＶＢ−ＨＴＭＬデータを定義する表が多重化され伝送される。ＨＴＭＬマネージャ５２０５は、このＡＩＴを最初にダウンロードする。ＡＩＴには、ＤＶＢ−ＨＴＭＬデータをダウンロードするための情報や、ＤＶＢ−ＨＴＭＬデータの名前、ＤＶＢ−ＨＴＭＬデータの制御情報などが含まれる。
図６３は、ＡＩＴの主要部を表した模式図である。図６３において最も左側の列には、ＤＶＢ−ＨＴＭＬデータのＩＤが記述されている。左から２番目の列には、ＤＶＢ−ＨＴＭＬデータの制御情報が記述されている。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」等がある。「ａｕｔｏｓｔａｒｔ」は、ＨＴＭＬブラウザ７５０がＤＶＢ−ＨＴＭＬデータを即時に解釈・表示することを意味する。「ｐｒｅｓｅｎｔ」は、自動的に解釈・表示しないことを意味する。「ｋｉｌｌ」は、ＤＶＢ−ＨＴＭＬデータの表示を消すことを意味する。左から３番目の列には、ＤＶＢ−ＨＴＭＬデータのデータ名が記述されている。最も右側の列には、ＤＶＢ−ＨＴＭＬデータの優先度が記述されている。複数のＤＶＢ−ＨＴＭＬデータの表示時に、リソースの競合が発生した場合、優先度の高いＤＶＢ−ＨＴＭＬデータの表示にリソースが優先的に割り当てられる。ここで、優先度の値が大きいほど優先度が高いこととする。
図６３において、上から２番目および３番目の行には、ＤＶＢ−ＨＴＭＬデータの情報の組が記述される。上から２番目の行において定義されるＤＶＢ−ＨＴＭＬデータについては、ＩＤが「１」であり、制御情報が「ａｕｔｏｓｔａｒｔ」であり、データ名が「天気予報」であり、優先度が「５４」である。上から３番目の行において定義されるＤＶＢ−ＨＴＭＬデータについては、ＩＤが「２」であり、制御情報が「ｐｒｅｓｅｎｔ」であり、データ名が「レジャー情報」であり、優先度が「２２」である。
ＨＴＭＬマネージャ５２０５は、図６３に示すＡＩＴを受け取ると、データ名が「天気予報」であるＤＶＢ−ＨＴＭＬデータをダウンロードし、解釈・表示する。ここで、ＤＶＢ−ＭＨＰ１．１規格が規定するＤＶＢ−ＨＴＭＬデータは、「Ｌｏａｄｅｄ」、「Ｐａｕｓｅｄ」、「Ａｃｔｉｖｅ」、「Ｄｅｓｔｒｏｙｅｄ」、および「Ｋｉｌｌｅｄ」という５つの状態を有している。
図６４は、ＤＶＢ−ＨＴＭＬデータの５つの状態および状態間の遷移を表す状態遷移図である。ＨＴＭＬマネージャ５２０５がＤＶＢ−ＨＴＭＬデータをダウンロードし、１次記憶部１０９に格納されると、当該ＤＶＢ−ＨＴＭＬデータの状態は「Ｌｏａｄｅｄ」になる。各状態間を結ぶ矢印は、状態間で可能な遷移を表しており、矢印のない状態間の遷移は発生しない。例えば、「Ｄｅｓｔｒｏｙｅｄ」の状態から「Ａｃｔｉｖｅ」の状態に遷移することはない。
ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの状態遷移を、（１）放送波中のＡＩＴの制御情報、（２）ＤＶＢ−ＨＴＭＬデータの指示、および（３）ナビゲータ７２０が結合部７３０を通して送る指示、の３通りの指示に従って行う。
ＡＩＴの制御情報が「ａｕｔｏｓｔａｒｔ」の場合、ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータをダウンロードした後、パーザー３６０２、レイアウター３６０３、および描画部３６０４に指示することでＤＶＢ−ＨＴＭＬデータを解釈・表示し、「Ａｃｔｉｖｅ」状態に遷移させる。ＡＩＴは、時間と共に変化する。例えば、ＡＩＴが図６３に示す状態から図６５に示す状態へ変化したとする。図６５では、データ名が「天気予報」であるＤＶＢ−ＨＴＭＬデータの制御情報が「ａｕｔｏｓｔａｒｔ」から「ｋｉｌｌ」に変更されている。このとき、ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの表示状態を「Ｋｉｌｌｅｄ」という状態に遷移させる。
一方、ＤＶＢ−ＨＴＭＬデータに対するユーザの入力により、ＤＶＢ−ＨＴＭＬデータが状態遷移を発生させることができる。図６６は、ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている例を示す図である。図６７は、図６６に示すＤＶＢ−ＨＴＭＬデータの表示例を示す図である。図６７において、表示６７１１がリンク６６０１に対応する。ここで、ユーザがリンク６６０１に対してクリックを入力部１１１から入力すると、インタラクション部５２０４は、リンクに定義されたＤＶＢ−ＨＴＭＬデータの情報をＨＴＭＬマネージャ５２０５に引き渡す。ここで、ＤＶＢ−ＨＴＭＬデータの情報は図６６を参照して「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」である。ＨＴＭＬマネージャ５２０５は、引き渡されたＤＶＢ−ＨＴＭＬデータの情報に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。この処理によって、ＨＴＭＬマネージャは、元のＤＶＢ−ＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」から「Ｋｉｌｌｅｄ」へと遷移することになる。一方、「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」という情報に相当する新たなＤＶＢ−ＨＴＭＬデータの状態は、「Ｌｏａｄｉｎｇ」から「Ａｃｔｉｖｅ」へと遷移することになる。図６８は、情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」に相当する新たなＤＶＢ−ＨＴＭＬデータの表示例を示す図である。
最後に、ナビゲータ７２０からの指示によってＤＶＢ−ＨＴＭＬデータの表示の状態を遷移する方法を説明する。ナビゲータ７２０は、共通状態、すなわち、結合部７３０が規定しているフォーマットエンジンの状態およびフォーマットエンジンが表示可能なデータの状態に基づいて指示を出す。この共通状態は、個別状態、すなわち、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５が表示するＤＶＢ−ＨＴＭＬデータの表示の状態および状態遷移とは異なっている。この共通状態と個別状態との間のギャップを第２の変換部７５１が埋めるのである。第２の変換部７５１は、ナビゲータ７２０からの指示を、ＨＴＭＬブラウザ７５０が取り扱う状態および状態遷移に変換する。その結果、ＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報やＤＶＢ−ＨＴＭＬデータからの指示と同等の指示を受け、ＤＶＢ−ＨＴＭＬデータの表示の状態を遷移させることができる。
第２の変換部７５１は、結合部７３０からのメッセージを変換してＨＴＭＬブラウザ７５０に伝え、また、ＨＴＭＬブラウザ７５０の情報を変換して結合部７３０に伝えることにより、ＨＴＭＬブラウザ７５０の動作を結合部７３０が規定する状態に適合させる。ここまで、様々なメッセージを、結合部７３０を通してＨＴＭＬブラウザ７５０に配送すると記述してきたが、正確には、これらのメッセージはＨＴＭＬブラウザ７５０ではなく第２の変換部７５１に送信される。第２の変換部７５１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第２の変換部７５１は、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態に基づいてＨＴＭＬブラウザ７５０の状態を決定する。そして、第２の変換部７５１は、「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０へ送る。
図６９は、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態と、ＨＴＭＬブラウザ７５０の動作状態との対応を示す変換表の一例を示す図である。図６９において左側の列には、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態が記述されている。右側の列には、対応するＨＴＭＬブラウザ７５０の動作状態が記述されている。ここで、ＨＴＭＬブラウザ７５０の状態は、結合部７３０が規定した状態、すなわち共通状態である。具体的には、図２１で示した「実行中」、「一時停止中」、および「停止中」という３つの動作状態である。上から２番目から４番目の行には、これら３つの状態に対応する、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態が規定されている。
まず、上から２番目の行には、全てのＨＴＭＬデータの中で１つでも「Ａｃｔｉｖｅ」状態のＨＴＭＬデータがあることに対して、ＨＴＭＬブラウザ７５０の共通状態として「実行中」が対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータの表示およびユーザとのインタラクションには極小リソースを使用している可能性が高いため、このような対応関係を規定した。
次に、上から３番目の行には、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータがなく、かつ、全ＨＴＭＬデータの中で１つでも「Ｐａｕｓｅｄ」状態のＨＴＭＬデータがあることに対して、ＨＴＭＬブラウザ７５０の共通状態として「一時停止中」が対応付けられている。ＤＶＢ−ＭＨＰ１．１規格によれば、「Ｐａｕｓｅｄ」状態のＨＴＭＬデータの表示は、一部のリソースは使用できないと記述されている。よって、このような対応関係を規定した。
次に、上から４番目の行には、上から２番目および３番目の行に示す場合以外の場合に対して、「停止中」が対応付けられている。上から２番目および３番目の行に示す場合以外の場合とは、具体的には、全てのＨＴＭＬデータが「Ｌｏａｄｅｄ」、「Ｄｅｓｔｒｏｙｅｄ」、もしくは「Ｋｉｌｌｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、ＨＴＭＬデータに対するインタラクション処理は実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
前述した通り、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報の変化やＨＴＭＬデータの指示により、ＨＴＭＬデータの状態を遷移させる。第２の変換部７５１は、状態変化の通知をＨＴＭＬマネージャ５２０５より受ける。その結果としてＨＴＭＬブラウザ７５０の状態が変化する場合には、第２の変換部７５１は、図６９の変換表を参照して、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。この場合、第２の変換部７５１は、１次記憶部１０９にＨＴＭＬブラウザ７５０の共通状態を保存しておく。そして、ＨＴＭＬデータの状態が変化した後の共通状態と比較する。なお、第２の変換部７５１は、ＨＴＭＬデータの状態の変化をＨＴＭＬマネージャ５２０５から通知されたとき、常に「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知してもよい。
第２の変換部７５１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定された所定のＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。ここで所定のＨＴＭＬデータとは、ＡＩＴに規定されている全てのＨＴＭＬデータでもよいし、優先度が最も高いＨＴＭＬデータであってもよい。所定のＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるべきＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでに「Ａｃｔｉｖｅ」状態のＨＴＭＬデータが存在する場合は、第２の変換部７５１は何もしないということとしてもよい。
第２の変換部７５１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定された全てのＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。ただし、読み込んでいないＨＴＭＬデータに対しては何もしなくてもよい。全てのＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｋｉｌｌｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全ＨＴＭＬデータに対して行えばよい。
第２の変換部７５１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定されたＨＴＭＬデータの中で「Ａｃｔｉｖｅ」状態のＨＴＭＬデータを見つけ、そのＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、そのＨＴＭＬデータの状態を取得する。もし状態が「Ａｃｔｉｖｅ」であれば、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全てのＨＴＭＬデータに対して行えばよい。
第２の変換部７５１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴが定義している全てのＨＴＭＬデータおよびその状態に基づいて、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。「アプリケーション・データ一覧応答」メッセージに含めるアプリケーション名は、ＡＩＴが規定するアプリケーション名がそのまま使用される。「アプリケーション・データ一覧応答」メッセージに含める状態ＩＤは、各ＨＴＭＬデータの状態を結合部７３０が規定する共通状態に変換表を用いて変換することによって作成される。
図７０は、各ＨＴＭＬデータの状態を共通状態に変換するための変換表の一例を示す図である。図７０において左側の列には、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態が記述されている。右側の列には、対応する共通状態が記述されている。上から２番目の行に示されるように、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態「Ａｃｔｉｖｅ」は、「実行中」という共通状態に対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータの表示およびユーザとのインタラクションは極小リソースを使用する可能性が高いので、このような対応関係を規定した。
また、図７０において上から３番目の行に示されるように、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態「Ｐａｕｓｅｄ」は、「一時停止中」という共通状態に対応付けられている。ＤＶＢ−ＭＨＰ１．１規格によれば、「Ｐａｕｓｅｄ」状態のＨＴＭＬデータの表示およびユーザとのインタラクション処理は使用可能なリソースが制限されると記述されている。よって、このような対応関係を規定した。
また、上から４番目の行に示されるように、上から２番目および３番目の行以外の場合のＨＴＭＬデータの状態に対しては、「停止中」という共通状態が対応付けられている。上から２番目および３番目の行以外の場合とは、具体的には、ＨＴＭＬデータが「Ｌｏａｄｅｄ」、「Ｄｅｓｔｒｏｙｅｄ」、もしくは「Ｋｉｌｌｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、ＨＴＭＬデータの解釈・表示処理およびユーザとのインタラクション処理は実行されないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
今、データ名が「天気予報」であるＨＴＭＬデータの状態が「Ａｃｔｉｖｅ」であり、データ名が「レジャー情報」であるＨＴＭＬデータの状態が「Ｄｅｓｔｒｏｙｅｄ」であるように、ＡＩＴにおいて定義されている場合を考える。この場合、第２の変換部７５１は、「アプリケーション・データ一覧要求」メッセージを受け取ると、図７１に示す「アプリケーション・データ一覧応答」メッセージ４７００を生成し、結合部７３０に送信する。
図７１は、第２の変換部７５１が送信するメッセージの具体例を示す図である。図７１に示すメッセージ７１００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「アプリケーション・データ取得応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド７１０１には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド７１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド７１０３には、「アプリケーション・データ取得応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド７１０４には、データの長さを表す「２７」が格納される。アプリケーション数フィールド７１０５には、ＨＴＭＬブラウザ７５０が受け取ったＡＩＴに規定されているＨＴＭＬデータ数である「２」が格納される。
また、図７１において、アプリケーション数フィールド７１０５には、１つ目のＨＴＭＬデータに対するアプリケーション情報フィールド７１１１と、２つ目のＨＴＭＬデータに対するアプリケーション情報フィールド７１１２とが含まれている。アプリケーションＩＤフィールド７１２１には、１つ目のＨＴＭＬデータを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション状態ＩＤフィールド７１２２には、「実行中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「実行中」は、ＨＴＭＬデータの状態「Ａｃｔｉｖｅ」が変換された結果である。アプリケーション名長さフィールド７１２３には、アプリケーション名の長さを示す「８」が格納される。アプリケーション名フィールド７１２４には、ＡＩＴで定義されたデータ名「天気予報」が格納されている。ここで「天気予報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、４文字×２バイト＝８バイトとなっている。アプリケーションＩＤフィールド７１２５には２つ目のＨＴＭＬデータを表すアプリケーションＩＤとして「２」が格納されている。状態ＩＤフィールド７１２６には、「停止中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「停止中」は、Ｊａｖａアプリケーションの動作状態「Ｄｅｓｔｒｏｙｅｄ」が変換された結果である。アプリケーション名長さフィールド７１２７には、アプリケーション名の長さを示す「１２」が格納される。アプリケーション名フィールド７１２８には、ＡＩＴで定義されたデータ名「レジャー情報」が格納されている。ここで「レジャー情報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、６文字×２バイト＝１２バイトとなっている。
前述した通り、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報の変化やＨＴＭＬデータの指示によって、ＨＴＭＬデータの状態を遷移させる。第２の変換部７５１は、状態変化の通知をＨＴＭＬマネージャ５２０５より受ける。その時、第２の変換部７５１は、「アプリケーション・データ一覧変化」メッセージを生成して、結合部７３０に通知する。第２の変換部７５１が、結合部７３０から「アプリケーション・データ実行」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。ＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでにＨＴＭＬデータが「Ａｃｔｉｖｅ」状態の場合、第２の変換部７５１は何もしないとようにしてもよい。
第２の変換部７５１が結合部７３０から「アプリケーション・データ停止」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。ただし、読み込んでいないＨＴＭＬデータに対しては何もしなくてもよい。ＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｋｉｌｌｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」状態に遷移させることができる。
第２の変換部７５１が結合部７３０から「アプリケーション・データ一時停止」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｐａｕｓｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。
さらに、第２の変換部７５１は、結合部７３０のリソース管理部７３３よりリソース剥奪の通知を受けてもよい。第２の変換部７５１は、剥奪されたリソースに応じて、ＨＴＭＬマネージャ５２０５にＨＴＭＬデータの状態を遷移させることとしてもよい。ＨＴＭＬデータの表示に不可欠なリソースが剥奪された場合は、全てのＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」に遷移させる。それ以外のリースの剥奪に対しては、第２の変換部７５１は、何も行わないとしてもよい。
また、リソース剥奪通知は、ＨＴＭＬブラウザ７５０が直接受け取り、対応する処理を行ってもよい。以上で、ＨＴＭＬブラウザ７５０の説明を終了する。
次に、図７２および図７３を用いて、メーラー７６０について説明する。メーラー７６０は、電子メールの読み書きを行うためのフォーマットエンジンである。メーラー７６０は、Ｊａｖａミドルウェア７４０やＨＴＭＬブラウザ７５０のように、取り扱うアプリケーションやデータに関する状態を規定していない。メーラー７６０自身の状態も特に規定がない。ここでは、メーラー７６０は、実行中および停止中という２つの状態を有している考える。ここで、メーラー７６０は一般的な電子メールソフトウエアの機能を含む。メーラー７６０自体の機能は既知であるので説明を省略する。
第３の変換部７６１は、結合部７３０からのメッセージを変換してメーラー７６０に伝える。また、第３の変換部７６１は、メーラー７６０の動作状態を変換して結合部７３０に伝える。これによって、第３の変換部７６１は、メーラー７６０の動作状態を結合部７３０が規定する共通状態に適合させる。なお、ここまで、様々なメッセージを、結合部７３０を通してメーラー７６０に配送すると記述してきたが、正確には、これらのメッセージはメーラー７６０ではなく第３の変換部７６１に配送される。
第３の変換部７６１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０の動作状態に基づいて「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０に送る。
図７２は、メーラー７６０の状態と、結合部７３０が規定している共通状態との対応を示す変換表の一例を示す図である。図７２において左側の列には、メーラー７６０の個別状態が記述されている。右側の列には、対応するメーラー７６０の共通状態が記述されている。共通状態は、具体的には、図２１で示した「実行中」および「停止中」という２つの動作状態である。上から２番目および３番目の行には、これら２つの状態に対応する、メーラー７６０の個別状態が規定されている。
まず、上から２番目の行には、メーラー７６０が起動中であることに対して、メーラー７６０の共通状態として「実行中」が対応付けられている。一般に、起動中のメーラーはネットワークインターフェース等の極小リソースを使用している可能性が高いため、このような対応関係を規定した。
次に、上から３番目の行には、メーラー７６０が停止中であることに対して、メーラー７６０の共通状態として「停止中」が対応付けられている。メーラー７６０が停止しているときは、メーラー７６０はリソースを一切使用していない。よって、「停止中」に対応付けるのが妥当である。なお、メーラー７６０には、共通状態「一時停止中」に対応する個別状態はない。
メーラー７６０は、不測の事態などが発生すると、メーラー７６０自身を終了する可能性がある。第３の変換部７６１は、この変化をメーラー７６０より受ける。このとき、第３の変換部７６１は、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。第３の変換部７６１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を起動する。第３の変換部７６１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を終了させる。第３の変換部７６１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を終了させる。図７２で示すように、メーラー７６０には「一時停止中」に対応する状態がない。ここでは、「一時停止中」とは、極小リソースを使用しないという意味である（図２１参照）。これを実現するには、メーラー７６０を終了させるしかない。
第３の変換部７６１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。ここで、メーラー７６０は、取り扱うアプリケーションやデータがないため、アプリケーション数０のメッセージを生成する。
図７３は、第３の変換部７６１が生成する「アプリケーション・データ一覧応答」メッセージの具体例を示す図である。図７３に示すメッセージ７３００は、メーラー７６０からナビゲータ７２０への「アプリケーション・データ取得応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド７３０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド７３０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される。Ｍｅｓｓａｇｅ  ＩＤフィールド７３０３には、「アプリケーション・データ取得応答」を表すメッセージＩＤとして「１２」が格納される。Ｄａｔａ  Ｌｅｎｇｔｈフィールド７３０４には、データの長さを示す「１」が格納される。アプリケーション数フィールド７３０５には、「０」が格納される。
第３の変換部７６１が結合部７３０から「アプリケーション・データ実行」メッセージ、「アプリケーション・データ停止」メッセージあるいは「アプリケーション・データ一時停止」メッセージを受け取った場合、第３の変換部７６１は、何もしない。この理由は、メーラー７６０は、取り扱うアプリケーション・データの状態を持たないからである。また、第３の変換部７６１は、「アプリケーション・データ一覧変化」メッセージを生成することはない。
さらに第３の変換部７６１は、結合部７３０のリソース管理部７３３よりリソース剥奪の通知を受けてもよい。第３の変換部７６１は、剥奪されたリソースに応じて、メーラー７６０を終了させることとしてもよい。メーラーの実行に不可欠なリソース、例えばネットワークインターフェース等が剥奪された場合は、第３の変換部７６１は、メーラー７６０を終了させる。それ以外のリースの剥奪に対しては、第３の変換部７６１は、何も行わないとしてもよい。
また、リソース剥奪通知は、メーラー７６０が直接受け取り、対応する処理を行ってもよい。以上で、メーラー７６０の説明を終了する。また、以上で、情報処理装置の具体的な構成の説明を終了する。
（詳細な動作）
次に、図７４〜図８４を用いて、上記の構成例に示したデジタルテレビにおいて前述した第１および第２の動作例の動作を行う場合について説明する。
（第１の動作例の詳細な動作）
まず、図７４〜図８１を用いて、第１の動作例の詳細な動作を説明する。図７４は、第１の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。図７４において、まず、ナビゲータ７２０は、フォーマットエンジンの起動要求を受け付ける（ステップＳ１）。ここで、起動要求は、典型的にはユーザによって指示される。例えば図８に示す状態において、ユーザが入力部１１１のＯＫボタン３０５を押下することによって、Ｊａｖａミドルウェア７４０に関する起動要求が指示される。
次に、ナビゲータ７２０は、各フォーマットエンジンの内、１つを選択する（ステップＳ２）。ステップＳ２で選択したフォーマットエンジンについて、以降のステップＳ３〜Ｓ６の処理が行われる。続いて、ナビゲータ７２０は、ステップＳ２で選択したフォーマットエンジンに対する「フォーマットエンジン（図では、“ＦＭ”と記載する。）状態要求」メッセージを結合部７３０へ送信する（ステップＳ３）。このメッセージは、結合部７３０によって当該フォーマットエンジンに対応する変換部へ送信される。
ここで、結合部７３０の通信部７３１がメッセージを送信する処理について説明する。図７５は、通信部７３１が行うメッセージ送信の処理の流れを示すフローチャートである。通信部７３１は、メッセージを受け取ると（ステップＳ７５０１）、メッセージ中のＤｅｓｔｉｎａｔｉｏｎ
ＩＤフィールドの値を参照する。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「０」のとき（ステップＳ７５０２）、通信部７３１は、ナビゲータ７２０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７７５、メーラー７６０、および結合部７３０の状態管理部７３２にメッセージを送信する（ステップＳ７５０３）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「１」のとき（ステップＳ７５０４）、通信部７３１は、ナビゲータ７２０にメッセージを送信する（ステップＳ７５０５）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「２」のとき（ステップＳ７５０６）、通信部７３１は、Ｊａｖａミドルウェア７４０にメッセージを送信する（ステップＳ７５０７）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「３」のとき（ステップＳ７５０８）、通信部７３１は、ＨＴＭＬブラウザ７７５にメッセージを送信する（ステップＳ７５０９）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「４」のとき（ステップＳ７５１０）、通信部７３１は、メーラー７６０にメッセージを送信する（ステップＳ７５１１）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「５」のとき（ステップＳ７５１２）、通信部７３１は、結合部７３０の状態管理部７３２にメッセージを送信する（ステップＳ７５１３）。以上の処理によって、各サブプログラムからのメッセージは、適切なサブプログラムへ送信されることとなる。通信部７３１は、メッセージを受け取る度に、上記処理を行う。
次に、ステップＳ３の「フォーマットエンジン状態要求」メッセージを受信した際の各変換部の処理の流れについて説明する。
図７６は、第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ると（ステップＳ７６０１）、第１の変換部７４１は、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがあるかどうかを調べる（ステップＳ７６０２）。「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがある場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「実行中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０３）。一方、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがない場合、第１の変換部７４１は、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがあるかどうかを調べる（ステップＳ７６０４）。「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがある場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「一時停止中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０５）。一方、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがない場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「停止中」である「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０６）。ステップＳ７６０３、Ｓ７６０５、またはＳ７６０６の後、第１の変換部７４１は、作成した「フォーマットエンジン状態応答」メッセージを結合部７３０に送信する（ステップＳ７６０７）。
なお、「フォーマットエンジン状態要求」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図７６のフローチャートに準ずる。
図７７は、第３の変換部７７１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。第３の変換部７７１が「フォーマットエンジン状態要求」メッセージを受け取ると（ステップＳ７７０１）、第３の変換部７７１は、メーラー７７０が起動しているかどうかを調べる（ステップＳ７７０２）。メーラーが起動している場合、第３の変換部７７１は、メーラー７７０が「実行中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７７０３）。一方、メーラーが起動していない場合、第３の変換部７７１は、メーラー７７０が「停止中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７７０４）。ステップＳ７７０３またはＳ７７０４の後、第３の変換部７７１は、作成した「フォーマットエンジン状態応答」メッセージを結合部７３０に配送する（ステップＳ７７０５）。
以上、図７６および図７７に示した処理によって、ナビゲータ７２０に「フォーマットエンジン状態応答」メッセージが返ってくる。図７４の説明に戻り、ステップＳ３の次に、ナビゲータ７２０は、「フォーマットエンジン状態応答」メッセージを受信する（ステップＳ４）。続いて、ナビゲータ７２０は、受信したメッセージに基づいて、ステップＳ２で選択したフォーマットエンジンが実行中であるか否かを判定する（ステップＳ５）。
ステップＳ５において、フォーマットエンジンが実行中でないと判定された場合、ナビゲータ７２０は、ステップＳ６の処理をスキップし、ステップＳ７の処理を行う。一方、フォーマットエンジンが実行中であると判定された場合、ナビゲータ７２０は、当該フォーマットエンジンに対する「フォーマットエンジン停止」メッセージを結合部７３０へ送信する（ステップＳ６）。このメッセージは、当該フォーマットエンジンに対応する変換部へ結合部４０３によって送信される。
次に、ステップＳ６の「フォーマットエンジン停止」メッセージを受信した際の各変換部の処理の流れについて説明する。
図７８は、第１の変換部７４１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを表すフローチャートである。第１の変換部７４１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ７８０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションを１つ選択する（ステップＳ７８０２）。続いて、第１の変換部７４１は、選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前であるかを調べる（ステップＳ７８０３）。選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前のいずれかでもない場合、第１の変換部７４１は、選んだＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる（ステップＳ７８０４）。選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前のいずれかである場合、第１の変換部７４１は、ステップＳ７８０４の処理をスキップし、ステップＳ７８０５の処理を行う。すなわち、第１の変換部７４１は、ステップＳ７８０２において全てのＪａｖａアプリケーションを選択したか否かを判定する。１つでも選択していないＪａｖａアプリケーションがある場合、第１の変換部７４１は、ステップＳ７８０２の処理を行う。そして、第１の変換部７４１は、ステップＳ７８０２〜Ｓ７８０５の処理を繰り返す。一方、全てのＪａｖａアプリケーションを選択した場合、第１の変換部７４１は、図７８の処理を終了する。以上のように、第１の変換部７４１は、ステップＳ７８０２〜ステップＳ７８０４までの処理を全てのＪａｖａアプリケーションに対して実施する。
図７９は、第２の変換部７５１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第２の変換部７５１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ７９０１）、第２の変換部７５１は、ＡＩＴからＨＴＭＬデータを１つ選択する（ステップＳ７９０２）。続いて、第２の変換部７５１は、選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前であるかを調べる（ステップＳ７９０３）。選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前のいずれかでもない場合、第２の変換部７５１は、選んだＨＴＭＬデータの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる（ステップＳ７９０４）。選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前のいずれかである場合、第２の変換部７５１は、ステップＳ７９０４の処理をスキップし、ステップＳ７９０５の処理を行う。すなわち、第２の変換部７５１は、ステップＳ７９０２〜ステップＳ７９０４までの処理を全てのＨＴＭＬデータに対して実施する（ステップＳ７９０５）。
図８０は、第３の変換部７６１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第３の変換部７６１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ８００１）、第３の変換部７６１は、メーラー７６０が起動しているかどうかを調べる（ステップＳ８００２）。メーラー７６０が起動していれば、第３の変換部７６１は、メーラー７６０を終了して（ステップＳ８００３）、図８０に示す処理を終了する。一方、メーラー７６０が起動していなければ、第３の変換部７６１は、ステップＳ８００３の処理をスキップして図８０に示す処理を終了する。以上、図７８〜図８０に示した処理によって、「実行中」の動作状態であったフォーマットエンジンが終了される。図７４の説明に戻り、ステップＳ５またはステップＳ６の次に、ナビゲータ７２０は、ステップＳ２において、起動要求の対象となっているフォーマットエンジンを除く全てのフォーマットエンジンを選択したか否かを判定する（ステップＳ７）。１つでも選択していないフォーマットエンジンがある場合、ナビゲータ７２０は、ステップＳ２の処理を行う。そして、ナビゲータ７２０は、ステップＳ２〜Ｓ７の処理を繰り返す。一方、全てのフォーマットエンジンを選択した場合、ナビゲータ７２０は、起動要求の対象となっているフォーマットエンジンに対する「フォーマットエンジン実行」メッセージを結合部７３０へ送信する（ステップＳ８）。その後、ナビゲータ７２０は、図７４の処理を終了する。
次に、ステップＳ８の「フォーマットエンジン実行」メッセージを受信した際の各変換部の処理の流れについて説明する。
図８１は、第１の変換部７４１が、「フォーマットエンジン実行」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「フォーマットエンジン実行」メッセージを受け取ると（ステップＳ８１０１）、第１の変換部７４１は、実行すべきＪａｖａアプリケーションを決定する（ステップＳ８１０２）。この決定は、例えば、ＡＩＴから最も優先度の高いＪａｖａアプリケーションを選ぶことによって決定される。続いて、第１の変換部７４１は、ステップＳ８１０３において決定したＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８１０３）。当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でなければ、第１の変換部７４１は、当該Ｊａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」に遷移させ（ステップＳ８１０４）、図８１に示す処理を終了する。一方、当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」であれば、第１の変換部７４１は、ステップＳ８１０４の処理をスキップし、図８１に示す処理を終了する。
なお、「フォーマットエンジン実行」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図８１のフローチャートに準ずる。
また、「フォーマットエンジン実行」メッセージを受け取った場合の第３の変換部７６１における処理の流れは、図８０のフローチャートに準ずる。
以上のように、図７４に示すステップＳ８において送信される「フォーマットエンジン実行」メッセージによって、起動要求の対象であるフォーマットエンジンが起動される。また、その他のフォーマットエンジン（起動要求の対象でないフォーマットエンジン）は「実行中」の状態でなくなるので、極小リソースが競合することを回避することができる。
なお、図７４のステップＳ６では、ナビゲータ７２０は「フォーマットエンジン停止」メッセージを送信するものとしたが、ナビゲータ７２０は、「フォーマットエンジン一時停止」メッセージを送信してもよい。この場合も、上記その他のフォーマットエンジン（起動要求の対象でないフォーマットエンジン）は「実行中」の状態でなくなるので、極小リソースが競合することを回避することができる。
次に、「フォーマットエンジン一時停止」メッセージを受信した際の各変換部の処理の流れについて説明する。
図８２は、第１の変換部７４１が、「フォーマットエンジン一時停止」メッセージを受け取った際の処理の流れを表すフローチャートである。第１の変換部７４１が「フォーマットエンジン一時停止」メッセージを受け取ると（ステップＳ８２０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションを１つ選択する（ステップＳ８２０２）。続いて、第１の変換部７４１は、選択したＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８２０３）。選択したＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、選んだＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させる（ステップＳ８２０４）。選択したＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、ステップＳ８２０４の処理をスキップし、ステップＳ８２０５の処理を行う。すなわち、第１の変換部７４１は、ステップＳ８２０２〜ステップＳ８２０４までの処理を全てのＪａｖａアプリケーションに対して実施する（ステップＳ８２０５）。
なお、「フォーマットエンジン一時停止」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図８２のフローチャートに準ずる。
また、「フォーマットエンジン一時停止」メッセージを受け取った場合の第３の変換部７６１における処理の流れは、「フォーマットエンジン停止」メッセージを受け取った場合と同様である。
（第２の動作例の詳細な動作）
次に、第２の動作例の詳細な動作を説明する。図８３は、第２の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。図８３において、まず、ナビゲータ７２０は、フォーマットエンジンの起動要求を受け付ける（ステップＳ１１）。ステップＳ１１の処理は、第１の動作例におけるステップＳ１と同様である。
次に、ナビゲータ７２０は、起動要求の対象であるフォーマットエンジンに対する「フォーマットエンジン実行」メッセージを結合部７３３へ送信する（ステップＳ１２）。結合部７３３を介して当該メッセージを受け取った変換部における処理は、上述した第１の動作例と同様である。
ここで、各フォーマットエンジンは、「フォーマットエンジン実行」メッセージに応じて起動した後、必要に応じてリソースの利用をライブラリ７１１に対して要求する。リソースの利用要求を行うか否かは、各フォーマットエンジン毎に予め定められている。以下では、フォーマットエンジンが極小リソースの利用要求を行ったものとして説明する。なお、フォーマットエンジンが極小リソースの利用要求を行わない場合は、フォーマットエンジンはそのまま動作を続ける。
ステップＳ１２の次に、ライブラリ７１１は、起動したフォーマットエンジンから極小リソースの利用要求を受け付ける（ステップＳ１３）。なお、この段階では、当該フォーマットエンジンに対して当該極小リソースの利用が許可されたわけではない。続いて、ライブラリ７１１は、極小リソースの利用要求が重複しているか否かを判定する（ステップＳ１４）。ここで、「極小リソースの利用要求が重複する」とは、単一の極小リソースに対して複数の利用要求があったことを意味する。従って、異なる２つの極小リソースの各々に対して利用要求があっても、極小リソースの利用要求が重複したことにはならない。以下、ステップＳ１４における判定処理を詳細に説明する。
ステップＳ１４において、ライブラリ７１１は、起動要求を行っているフォーマットエンジンをフォーマットエンジン特定部３９０５に問い合わせる。この問い合わせに応じて、フォーマットエンジン特定部３９０５は、プロセス記憶部３９０１を参照することによって、起動要求を行っているフォーマットエンジンを特定する。そして、フォーマットエンジン特定部３９０５は、特定したフォーマットエンジンをライブラリ７１１に通知する。なお、極小リソースをすでに利用しているフォーマットエンジンはすでに特定されている。従って、ライブラリ７１１は、極小リソースをすでに利用しているフォーマットエンジン（これがない場合は重複しないと判定する。）と、フォーマットエンジン特定部３９０５から通知されたフォーマットエンジンとによって、極小リソースの利用要求が重複しているか否かを判定することができる。
ステップＳ１４において、利用要求が重複していない場合、ライブラリ７１１は、利用要求を行ったフォーマットエンジンに対して極小リソースの利用を許可し（ステップＳ１９）、図８３に示す処理を終了する。
一方、ステップＳ１４において、利用要求が重複している場合、ライブラリ７１１は、優先度情報を取得する（ステップＳ１５）。具体的には、リソース管理部７３３の優先度情報提供部３９０６に対して、優先度情報の取得を要求する。ここで、優先度情報とは、優先度格納部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを含む概念である。つまり、優先度情報提供部３９０６は、ライブラリ７１１からの要求に対して、優先度格納部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを送信する。
ライブラリ７１１は、優先度情報提供部３９０６から送信されてきた情報を用いて、利用を許可するフォーマットエンジンを決定する（ステップＳ１６）。このステップＳ１６によって、図６に示す許可決定部６１の機能が実現されることになる。なお、ここでは、ステップＳ１６の処理はライブラリが行うこととしたが、利用を許可するフォーマットエンジンを優先度情報提供部３９０６が決定し、決定したフォーマットエンジンをライブラリ７１１へ通知するようにしてもよい。
ステップＳ１６の処理は、例えば以下のように行われる。なお、ここでは、ステップＳ１３において起動要求を行ったフォーマットエンジンをフォーマットエンジンＡとし、極小リソースをすでに利用していたフォーマットエンジンをフォーマットエンジンＢと呼ぶ。
ライブラリ７１１は、まず、最新起動情報に基づいて、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡであるか否かを判定する。そして、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡであれば、ライブラリ７１１は、極小リソースの利用を許可するフォーマットエンジンをフォーマットエンジンＡに決定する。一方、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡでなければ、ライブラリ７１１は、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＢであるか否かを判定する。そして、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＢであれば、ライブラリ７１１は、極小リソースの利用を許可するフォーマットエンジンをフォーマットエンジンＢに決定する。すなわち、ライブラリ７１１は、極小リソースの利用を許可するフォーマットエンジンを、ユーザが最近起動したフォーマットエンジンに決定する。
さらに、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡでもフォーマットエンジンＢでもない場合、ライブラリ７１１は、優先度情報記憶部３６０２に記憶されている情報を用いて極小リソースの利用を許可するフォーマットエンジンを決定する。すなわち、ライブラリ７１１は、極小リソースの利用を許可するフォーマットエンジンを、優先度情報記憶部３６０２に記憶されている優先度が高い方のフォーマットエンジンに決定する。
ステップＳ１６の次に、ライブラリ７１１は、ステップＳ１６において決定したフォーマットエンジンに対して極小リソースの利用を許可する（ステップＳ１７）。続いて、ライブラリ７１１は、ステップＳ１６において決定したフォーマットエンジンでない方のフォーマットエンジンに対してリソースが剥奪された旨の通知を行う（ステップＳ１８）。具体的には、ライブラリ７１１は、リソース剥奪通知を当該フォーマットエンジンに送信するように、リソース管理部７３３のリソース剥奪通知部３９０７に要求する。これに応じてリソース剥奪通知部３９０７がリソース剥奪通知を当該フォーマットエンジンに送信する。ステップＳ１８の後、ライブラリ７１１は、図８３に示す処理を終了する。
以上の処理によって、極小リソースの利用が許可されなかったフォーマットエンジンに対応する変換部にリソース剥奪通知が送られる。変換部は、このリソース剥奪通知に応じて、以下の処理を行う。
図８４は、リソース剥奪通知を受け取った変換部における処理の流れを示すフローチャートである。なお、図８４に示す処理は、変換部が行うこととするが、フォーマットエンジンが同じ動作を行ってもよい。まず、変換部は、剥奪されたリソースのリソースＩＤをリソース剥奪通知部３９０７から受け取る（ステップＳ８４０１）。次に、変換部は、フォーマットエンジンが継続して実行可能か否かを判定する（ステップＳ８４０２）。ここで、「フォーマットエンジンが継続して実行可能」とは、「リソース（剥奪されたリソース）がなくても実行可能」という意味である。ステップＳ８４０２において、フォーマットエンジンが継続実行可能な場合、変換部は、そのまま図８４に示す処理を終了する。このとき、リソースが剥奪されたフォーマットエンジンは実行されたままである。
一方、ステップＳ８４０２において、フォーマットエンジンが継続実行不可能な場合、変換部は、一時停止状態にすれば実行可能か否かを判定する（ステップＳ８４０３）。ステップＳ８４０３において、フォーマットエンジンが継続実行不可能であれば、変換部は、フォーマットエンジンを停止する（ステップＳ８４０４）。一方、フォーマットエンジンが継続実行可能であれば、変換部は、フォーマットエンジンを一時停止する（ステップＳ８４０５）。
なお、図８４では、停止したり一時停止したりする対象をフォーマットエンジンとしている。ここで、フォーマットエンジンが実行するアプリケーションや表示するデータ（上記のＪａｖａアプリケーションやＨＴＭＬデータ）に状態が規定されている場合、フォーマットエンジンの動作状態を変更するだけでなく、これらのアプリケーションやデータの状態を変更するようにしてもよい。なお、図８４で記載した状態は、共通状態である。変換部は、共通状態の変更をフォーマットの動作状態に応じて適切に変換し、フォーマットエンジンの状態を遷移させる。
なお、図８３では、ライブラリ７１１は、優先度情報として、優先度格納部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを用いてステップＳ１６における決定を行った。ここで、ライブラリ７１１は、まず最新起動情報のみを取得し、ユーザが最近起動したフォーマットエンジンが上記フォーマットエンジンＡでもフォーマットエンジンＢでもないとわかった後で、優先度格納部３９０２に格納されている優先度を取得してもよい。また、ライブラリ７１１は、優先度格納部３９０２に格納されている優先度のみを用いてステップＳ１６における決定を行ってもよい。以上で、第２の動作例の詳細な動作の説明を終了する。
（その他の動作例）
なお、上記の構成例では、図７４〜図８４に示したメッセージの他にも、種々のメッセージのやり取りが行われる。以下、図７４〜図８４に示したメッセージ以外のメッセージをやり取りする場合の変換部の処理を説明する。
図８５は、第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化通知を受けた際の処理の流れを示すフローチャートである。第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化の通知を受けると（ステップＳ８５０１）、第１の変換部７４１は、Ｊａｖａアプリケーションの動作状態に基づいて、Ｊａｖａミドルウェア７４０の共通状態を決定する（ステップＳ８５０２）。さらに、第１の変換部７４１は、１次記憶部１０９に保存している変化前のＪａｖａミドルウェア７４０の共通状態と、ステップＳ８５０２で決定したＪａｖａミドルウェア７４０の共通状態とを比較し、変化前後で共通状態が変化したか否かを判定する（ステップＳ８５０３）。判定の結果、変化した場合、第１の変換部７４１は、「フォーマットエンジン状態変化」メッセージを作成し、結合部７３０に送信する（ステップＳ８５０４）。最後に、第１の変換部７４１は、状態が変化したＪａｖａアプリケーションに関して、「アプリケーション・データ一覧変化」メッセージを作成し、結合部７３０に送信する（ステップＳ８５０５）。
なお、第２の変換部７５１がＨＴＭＬマネージャ５２０５からＨＴＭＬデータの状態変化通知を受けた際の処理の流れは、図８５に示す処理に準ずる。
図８６は、第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取ると（ステップＳ８６０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションの一覧を取得する（ステップＳ８６０２）。次に、第１の変換部７４１は、各Ｊａｖａアプリケーションの状態をＪａｖａミドルウェア７４０から取得する（ステップＳ８６０３）。第１の変換部７４１は、取得した各Ｊａｖａアプリケーションの状態を、アプリケーション・データの共通状態に変換する（ステップＳ８６０４）。最後に、第１の変換部７４１は、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送信する（ステップＳ８６０５）。
なお、第２の変換部７５１が「アプリケーション・データ実行」メッセージを受け取った際の処理の流れは、図８６に示す処理に準ずる。
図８７は、第１の変換部７４１が、「アプリケーション・データ実行」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ実行」メッセージを受け取ると（ステップＳ８７０１）、第１の変換部７４１は、「アプリケーション・データ実行」メッセージで指定されたＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」か否かを判定する（ステップＳ８７０２）。判定の結果、当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの動作状態を「Ａｃｔｉｖｅ」に遷移させる（ステップＳ８７０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、図８７に示す処理を終了する。
なお、第２の変換部７５１が「アプリケーション・データ実行」メッセージを受け取った際の処理の流れは、図８７に示す処理に準ずる。
図８８は、第１の変換部７４１が、「アプリケーション・データ停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ停止」メッセージを受け取ると（ステップＳ８８０１）、第１の変換部７４１は、「アプリケーション・データ停止」メッセージで指定されたＪａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」であるか否かを判定する（ステップＳ８８０２）。判定の結果、当該Ｊａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」でない場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの動作状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる（ステップＳ８８０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」である場合、第１の変換部７４１は、図８８に示す処理を終了する。
なお、第２の変換部７５１が「アプリケーション・データ停止」メッセージを受け取った際の処理の流れは、図８８に示す処理に準ずる。
図８９は、第１の変換部７４１が、「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ一時停止」メッセージを受け取ると（ステップＳ８９０１）、第１の変換部７４１は、「アプリケーション・データ一時停止」メッセージで指定されたＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８９０２）。判定の結果、Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させる（ステップＳ８９０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、図８９に示す処理を終了する。
なお、第２の変換部７５１が「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れは、図８９に示す処理に準ずる。
図９０は、第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けた際の処理の流れを示すフローチャートである。第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けると（ステップＳ９００１）、第３の変換部７６１は、「フォーマットエンジン状態変化」メッセージを作成し、結合部７３０に送信する（ステップＳ９００２）。
図９１は、結合部７３０が「フォーマットエンジン状態変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。まず、結合部７３０は、「フォーマットエンジン状態変化」メッセージを受け取る（ステップＳ９１０１）。次に、結合部７３０は、受け取ったメッセージ内のＳｏｕｒｃｅ
ＩＤフィールドを参照することによって、状態が変化したフォーマットエンジンを特定し、特定したフォーマットエンジンに対する「フォーマットエンジン状態要求」メッセージを送信する（ステップＳ９１０２）。その結果、結合部７３０の状態管理部７３２は、「フォーマットエンジン状態応答」メッセージを受け取り（ステップＳ９１０３）、フォーマットエンジンの状態を１次記憶部１０９に記憶する（ステップＳ９１０４）。
図９２は、結合部７３０が「アプリケーション・データ一覧変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。まず、結合部７３０は、「アプリケーション・データ一覧変化」メッセージを受け取る（ステップＳ９２０１）。次に、結合部７３０は、受け取ったメッセージ内のＳｏｕｒｃｅ  ＩＤフィールドを参照することによって、状態が変化したアプリケーションを実行またはデータを表示しているフォーマットエンジンを特定し、特定したフォーマットエンジンに対する「アプリケーション・データ一覧要求」メッセージを送る（ステップＳ９２０２）。その結果、結合部７３０の状態管理部７３２は、「アプリケーション・データ一覧応答」メッセージを受け取り（ステップＳ９２０３）、アプリケーション・データの状態を１次記憶部１０９に記憶する。
なお、以上において、ナビゲータ７２０が状態管理部７３２の機能を有することによって、状態管理部７３２を結合部７３０から削除してもよい。このような構成にすると、ナビゲータ７２０が全てのフォーマットエンジンの状態を管理することになる。
また、本構成例にいて、各フォーマットエンジンは、送られてきたメッセージの発信元に対して、何ら制限をかけない。従って、フォーマットエンジンは、他のフォーマットエンジンの動作状態や、フォーマットエンジンが実行しているアプリケーションや、表示しているデータの状態を変化させることが可能である。例えば、Ｊａｖａミドルウェア７４０が、ＨＴＭＬブラウザ７５０に対して、「フォーマットエンジン実行」メッセージを送信することによって、ＨＴＭＬブラウザ７５０は停止させることができることは明らかである。
また、本構成例では、ＲＯＭ１１０が保存する内容を２次記憶部１０８が保存することで、ＲＯＭ１１０を用いない構成とすることも可能である。また、２次記憶部１０８は、複数のサブ２次記憶部で構成し、個々のサブ２次記憶部が異なる情報を保存する構成としてもよい。例えば、あるサブ２次記憶部は状態管理部７３２が記憶するフォーマットエンジンの状態を記憶し、別のサブ２次記憶部は第１の変換部７４１が記憶するＪａｖａミドルウェア７４０の状態を記憶し、さらに別のサブ２次記憶部は、第２の変換部７５１が記憶するＨＴＭＬブラウザ７５０の状態を記憶するようにしてもよい。このように、各記憶部を詳細に分割することが可能である。
以上のように、本実施形態によれば、複数のフォーマットエンジンを結合する際、結合部７３０とフォーマットエンジンとを繋ぐ変換部を用いることによって、個々のフォーマットエンジンの実装を大きく改造する必要がない。そのため、少ない工数で複数のフォーマットエンジンを結合できる。
また、結合部７３０が規定する共通状態を用いることによって、結合するフォーマットエンジンが増えた場合であっても、ナビゲータ７２０は、メッセージの送り先を増やすだけよく、追加されたフォーマットエンジンに容易に対応することができる。
また、共通状態を用いることによって、ナビゲータ７２０および結合部７３０は、複数のフォーマットエンジンの状態を容易に把握できる。従って、複数のフォーマットエンジンの管理を容易に行うことができる。具体的には、複数のフォーマットエンジンを同時に制御することが容易になる。
図９３は、フォーマットエンジンを実行しても、他のフォーマットエンジンに大きな影響を与えない状況の組み合わせを示す図である。図９３に示すように、全てのフォーマットエンジンが停止中あるいは一時停止中ということは、極小リソースを使用しているフォーマットエンジンがないことを意味する。従って、図９３に示す状況にある場合、任意のフォーマットエンジンを起動することができる。例えば図９３に示す状況においては、Ｊａｖａミドルウェア７４０およびＨＴＭＬブラウザ７５０を停止することなく、メーラー７６０を実行することができる。
なお、結合部７３０において共通状態が規定されていない場合、ナビゲータ７２０は、個々のフォーマットエンジンが規定する独自の状態の組み合わせを把握する必要があることになる。従って、この場合、ナビゲータ７２０は、同時実行が可能な状況を判断することが非常に困難となる。特に、本構成例ではＪａｖａミドルウェア７４０およびＨＴＭＬブラウザ４５０については、実行するアプリケーションおよび表示するデータの状態は規定されているが、フォーマットエンジンとしての状態は規定されていない。従って、上記の場合には、ナビゲータ７２０は、Ｊａｖａミドルウェア７４０が実行するＪａｖａアプリケーションおよびＨＴＭＬブラウザ４５０が表示するデータが取り得る全ての状態の組み合わせを把握する必要がある。また、本構成例で取り上げたＪａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０以外のフォーマットエンジンがさらに追加される場合には、追加するフォーマットエンジンが規定する状態の組み合わせをさらに考慮する必要があるので、ますます、複数のフォーマットエンジンの管理が困難となる。
【産業上の利用可能性】  以上においてはデジタルテレビを実施の形態の一例として記載したが、本発明は、デジタルテレビに限らずパーソナルコンピュータや携帯電話、情報形態端末等、複数のフォーマットエンジンを動作させる情報処理装置に利用することができる。
【図１】
2004034698.tif 000003
【図２】
2004034698.tif 000004
【図３】
2004034698.tif 000005
【図４】
2004034698.tif 000006
【図５】
2004034698.tif 000007
【図６】
2004034698.tif 000008
【図７】
2004034698.tif 000009
【図８】
2004034698.tif 000010
【図９】
2004034698.tif 000011
【図１０】
2004034698.tif 000012
【図１１】
2004034698.tif 000013
【図１２】
2004034698.tif 000014
【図１３】
2004034698.tif 000015
【図１４】
2004034698.tif 000016
【図１５】
2004034698.tif 000017
【図１６】
2004034698.tif 000018
【図１７】
2004034698.tif 000019
【図１８】
2004034698.tif 000020
【図１９】
2004034698.tif 000021
【図２０】
2004034698.tif 000022
【図２１】
2004034698.tif 000023
【図２２】
2004034698.tif 000024
【図２３】
2004034698.tif 000025
【図２４】
2004034698.tif 000026
【図２５】
2004034698.tif 000027
【図２６】
2004034698.tif 000028
【図２７】
2004034698.tif 000029
【図２８】
2004034698.tif 000030
【図２９】
2004034698.tif 000031
【図３０】
2004034698.tif 000032
【図３１】
2004034698.tif 000033
【図３２】
2004034698.tif 000034
【図３３】
2004034698.tif 000035
【図３４】
2004034698.tif 000036
【図３５】
2004034698.tif 000037
【図３６】
2004034698.tif 000038
【図３７】
2004034698.tif 000039
【図３８】
2004034698.tif 000040
【図３９】
2004034698.tif 000041
【図４０】
2004034698.tif 000042
【図４１】
2004034698.tif 000043
【図４２】
2004034698.tif 000044
【図４３】
2004034698.tif 000045
【図４４】
2004034698.tif 000046
【図４５】
2004034698.tif 000047
【図４６】
2004034698.tif 000048
【図４７】
2004034698.tif 000049
【図４８】
2004034698.tif 000050
【図４９】
2004034698.tif 000051
【図５０】
2004034698.tif 000052
【図５１】
2004034698.tif 000053
【図５２】
2004034698.tif 000054
【図５３】
2004034698.tif 000055
【図５４】
2004034698.tif 000056
【図５５】
2004034698.tif 000057
【図５６】
2004034698.tif 000058
【図５７】
2004034698.tif 000059
【図５８】
2004034698.tif 000060
【図５９】
2004034698.tif 000061
【図６０】
2004034698.tif 000062
【図６１】
2004034698.tif 000063
【図６２】
2004034698.tif 000064
【図６３】
2004034698.tif 000065
【図６４】
2004034698.tif 000066
【図６５】
2004034698.tif 000067
【図６６】
2004034698.tif 000068
【図６７】
2004034698.tif 000069
【図６８】
2004034698.tif 000070
【図６９】
2004034698.tif 000071
【図７０】
2004034698.tif 000072
【図７１】
2004034698.tif 000073
【図７２】
2004034698.tif 000074
【図７３】
2004034698.tif 000075
【図７４】
2004034698.tif 000076
【図７５】
2004034698.tif 000077
【図７６】
2004034698.tif 000078
【図７７】
2004034698.tif 000079
【図７８】
2004034698.tif 000080
【図７９】
2004034698.tif 000081
【図８０】
2004034698.tif 000082
【図８１】
2004034698.tif 000083
【図８２】
2004034698.tif 000084
【図８３】
2004034698.tif 000085
【図８４】
2004034698.tif 000086
【図８５】
2004034698.tif 000087
【図８６】
2004034698.tif 000088
【図８７】
2004034698.tif 000089
【図８８】
2004034698.tif 000090
【図８９】
2004034698.tif 000091
【図９０】
2004034698.tif 000092
【図９１】
2004034698.tif 000093
【図９２】
2004034698.tif 000094
【図９３】
2004034698.tif 000095
【図９４】
2004034698.tif 000096
【図９５】
2004034698.tif 000097
【手続補正書】
【提出日】平成17年4月8日(2005.4.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを複数格納している情報処理装置であって、
各フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、
各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段とを備え、
前記フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信し、
前記動作制御手段は、前記フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する、情報処理装置。
【請求項２】
各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態と、当該個別状態に対応する共通状態との組によって構成されるテーブル格納するテーブル格納手段をさらに備え、
前記動作制御手段は、前記テーブルを参照することによって共通状態から個別状態を決定する、請求項１に記載の情報処理装置。
【請求項３】
各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態を取得し、取得した個別状態に対応する共通状態を示す共通状態情報を前記フォーマットエンジン管理手段へ送信する個別状態取得手段をさらに備え、
前記フォーマットエンジン管理手段は、前記個別状態取得手段から出力された共通状態情報により示される共通状態に基づいて、各フォーマットエンジンの動作を管理する、請求項１に記載の情報処理装置。
【請求項４】
フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースをさらに備え、
前記個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用している動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態を示す共通状態情報を前記フォーマットエンジン管理手段へ出力するとともに、フォーマットエンジンから取得した個別状態が極小リソースを利用していない動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、前記所定の状態以外の状態を示す共通状態情報を前記フォーマットエンジン管理手段へ出力し、
前記フォーマットエンジン管理手段は、共通状態情報が前記所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理する、請求項３に記載の情報処理装置。
【請求項５】
前記フォーマットエンジン管理手段は、
フォーマットエンジンを起動するための起動要求を受け付ける起動受付手段と、
前記起動受付手段が起動要求を受け付けたことに応じて、前記個別状態取得手段から各フォーマットエンジンの共通状態情報を取得する共通状態取得手段と、
前記共通状態取得手段によって取得された共通状態情報が実行中を示すフォーマットエンジンがある場合、当該フォーマットエンジンの動作を停止させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する動作停止手段と、
前記動作停止手段によってフォーマットエンジンの動作が停止された後、起動要求に対応するフォーマットエンジンを起動させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する起動手段とを含む、請求項４に記載の情報処理装置。
【請求項６】
フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースと、
フォーマットエンジンの要求に応じてフォーマットエンジンに対してリソースの利用を許可するリソース制御手段と、
極小リソースを利用する場合における各フォーマットエンジン間の優先度を示す優先度情報を格納する優先度情報格納手段と、
極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、前記優先度情報に基づいて、当該極小リソースの利用を許可すべきフォーマットエンジンを決定する許可決定手段とをさらに備え、
前記リソース制御手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、前記許可決定手段によって決定されたフォーマットエンジンのみに当該極小リソースの利用を許可し、極小リソースを利用する要求が複数のフォーマットエンジン間で重複しない場合、当該要求を行ったフォーマットエンジンに当該極小リソースの利用を許可する、請求項１に記載の情報処理装置。
【請求項７】
前記極小リソースは複数設けられ、
前記リソース制御手段は前記極小リソースに対応して複数設けられる、請求項６に記載の情報処理装置。
【請求項８】
異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置のコンピュータで実行可能なプログラムであって、
前記コンピュータを、
フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、
各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段として機能させ、
前記フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信し、
前記動作制御手段は、前記フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する、プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関し、より特定的には、Ｊａｖａ（登録商標）やＨＴＭＬ等の特定のフォーマットで記述されたアプリケーションを実行するフォーマットエンジンの動作を管理する情報処理装置に関する。
【背景技術】
【０００２】
近年、デジタルテレビ、携帯情報端末、携帯電話といった情報処理装置において、Ｊａｖａ（登録商標）プログラムやＨＴＭＬコンテンツ等の特定のフォーマットで記述されたアプリケーションを実行することが盛んに行われている。ここで、このようなアプリケーションの実行やデータの再生を行うためのソフトウェアをフォーマットエンジンと呼ぶ。フォーマットエンジンとは、例えば、上記Ｊａｖａ（登録商標）プログラムを実行するためのＪａｖａ（登録商標）ミドルウェアやＨＴＭＬコンテンツを表示するためのブラウザである。これらのフォーマットエンジンの他にも、現在パーソナルコンピュータ上で実行されているＰＤＦデータや音楽データ等を再生するためのフォーマットエンジンも、上記デジタルテレビ等において実行されるようになるであろう。
【０００３】
一般的に、上記デジタルテレビ等の情報処理装置に格納されているフォーマットエンジンは１つである。図９４は、従来のデジタル放送受信機の構成図の一例である。このデジタル放送受信機は、放送データに含まれるアプリケーション（Ｊａｖａ（登録商標）プログラム）を実行し、管理するものである。図９４において、デジタル放送受信機９４０２は、テレビモニタ９４０１に接続されている。また、デジタル放送受信機９４０２は、ディスプレイマネージャ９４１１と、アプリケーションマネージャ９４１２と、ルール９４１４と、信号モニタ９４１３とを備えている。
【０００４】
図９４において、デジタル放送受信機９４０２の信号モニタ９４１３は、放送データストリームを受信する。信号モニタ９４１３は、放送データストリームに含まれるアプリケーションが含まれるか否かを判断し、アプリケーションの有無を示す信号データをアプリケーションマネージャ９４１２へ出力する。アプリケーションマネージャ９４１２は、入力される信号データに基づいて、放送データストリームにアプリケーションが含まれるか否かを判断する。そして、放送データストリームにアプリケーションが含まれる場合、アプリケーションマネージャ９４１２は、当該アプリケーションをアプリケーションを読み込み実行する。アプリケーションが実行されると、テレビモニタに表示されるべきディスプレイ情報がディスプレイコンテキストとしてディスプレイマネージャ９４１１へ提供される。ディスプレイマネージャ９４１１は、適切なディスプレイ情報をテレビモニタ９４０１に提供する。ここで、アプリケーションマネージャ９４１２は、ルール９４１４に従って動作し、各アプリケーションの状態をロード状態、一時停止状態、アクティブ状態、および抹消状態のいずれかに遷移させる。ルールは、例えば、「１度に１つのアプリケーションのみをアクティブ状態にする」や、「１度に１つのアプリケーションのみを表示できる」等である。デジタル放送受信機９４０２は、このようなルールを用いることによって複数のアプリケーションを管理することができる。
【０００５】
一方、デジタルテレビ、携帯情報端末、携帯電話といった情報処理装置が複数のフォーマットエンジンを備える場合、それら複数のフォーマットエンジンを管理する技術も考えられている。このようなデジタルテレビ、携帯情報端末、携帯電話といった情報処理装置では、ＣＰＵに比べるとフォーマットエンジンを実行する際に用いられるリソースが限られているという側面がある。リソースとは、例えばメモリのように、フォーマットエンジンによって利用されるハードウェアをいう。例えば、デジタルテレビが有するリソースには、メモリの他、放送波を受信しデータを復号するためのチューナ、放送波に含まれる映像や音声をデコードするためのデコーダ、インターネットに接続するためのネットワークインターフェース等がある。フォーマットエンジンを実行する際には、実行されるフォーマットエンジンが利用するリソースを確保する必要があるので、上記のようなリソースが限られた情報処理装置においては、各フォーマットエンジンの実行を管理することが行われている。例えば、デジタルテレビでは、各フォーマットエンジンを切り替えて実行する処理を行うものがある。以下、従来のデジタルテレビにおいて複数のフォーマットエンジンを管理する技術を説明する。
【０００６】
図９５は、従来のデジタルテレビにおいて用いられるミドルウェア切替装置の構成図の一例である。このミドルウェア切替装置は、複数のミドルウェア（フォーマットエンジン）を切り替えて実行する。図９５において、ミドルウェア切替装置は、ミドルウェア決定部９５０１と、ミドルウェア読込部９５０２と、ミドルウェア実行部９５０３と、ミドルウェア格納部９５０４とを備えている。
【０００７】
図９５において、ミドルウェア格納部９５０４は、第１〜第ｎのミドルウェアを格納している。ミドルウェア決定部９５０１は、第１〜第ｎのミドルウェアの内、実行すべきミドルウェアを決定する。ミドルウェア読込部９５０２は、ミドルウェア決定部９５０１によって決定されたミドルウェアをミドルウェア格納部９５０４から読み込む。ミドルウェア実行部９５０３は、ミドルウェア読込部９５０２が読み込んだミドルウェアを実行する。以上の構成によって、第１〜第ｎのミドルウェアは切り替えて実行される。これによって、図９５に示す装置は、複数のミドルウェアを１つのデジタルテレビ上に共存させることを可能としている。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、図９５に示した構成では、ミドルウェアの追加や変更への対応が困難であった。以下、詳細を説明する。
【０００９】
例えば、図９５に示す装置に新たなミドルウェアを追加する場合を考える。ここで、一般的に、個々のフォーマットエンジンには独自の状態が規定されている。従って、フォーマットエンジンを管理する側（ミドルウェア読込部９５０２やミドルウェア実行部９５０３）は、フォーマットエンジン毎に異なる状態を把握している必要がある。すなわち、新たなミドルウェアが追加される場合、そのミドルウェアにおいて規定されている状態を理解することができるように、ミドルウェア読込部９５０２やミドルウェア実行部９５０３を変更しなければならない。以上より、新たなミドルウェアを追加する場合には、新たなミドルウェアをミドルウェア格納部９５０４に追加することに加えて、新たなミドルウェアに対応するようにミドルウェア読込部９５０２やミドルウェア実行部９５０３を変更しなければならない。従って、図９５に示すミドルウェア管理装置の設計の際にミドルウェアの追加や変更があると、開発者はミドルウェア読込部９５０２やミドルウェア実行部９５０３についても変更作業を行わなければならない。この変更作業は開発者にとって大きな負担になっていた。
【００１０】
それ故、本発明は、フォーマットエンジンの追加や変更に容易に対応することができる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本発明は、以下の構成を採用した。すなわち、本発明は、異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置である。当該情報処理装置は、フォーマットエンジンの動作状態を全てのフォーマットエンジンに共通の表現によって規定した共通状態を予め定義しておき、各フォーマットエンジンの動作を管理するフォーマットエンジン管理手段と、各フォーマットエンジンに対応して設けられ、共通状態と、フォーマットエンジンの動作状態を各フォーマットエンジン毎に異なる表現によって規定した動作状態である個別状態との対応を予め定義しておき、任意の個別状態となるようにフォーマットエンジンの動作を制御する動作制御手段とを備えている。フォーマットエンジン管理手段は、あるフォーマットエンジンを所定の共通状態に変化させる場合、当該所定の共通状態を示す共通状態情報を含むメッセージを、当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。各動作制御手段は、フォーマットエンジン管理手段からメッセージが送信されてきた場合、当該メッセージに含まれる共通状態情報により示される共通状態に対応する個別状態となるように、当該フォーマットエンジンを制御する。
【００１２】
また、情報処理装置は、各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態と、当該個別状態に対応する共通状態との組によって構成されるテーブル格納するテーブル格納手段をさらに備えていてもよい。このとき、各動作制御手段は、テーブルを参照することによって共通状態から個別状態を決定する。
【００１３】
また、情報処理装置は、各フォーマットエンジンに対応して設けられ、フォーマットエンジンの個別状態を取得し、取得した個別状態に対応する共通状態を示す共通状態情報をフォーマットエンジン管理手段へ送信する個別状態取得手段をさらに備えていてもよい。このとき、フォーマットエンジン管理手段は、個別状態取得手段から出力された共通状態情報により示される共通状態に基づいて、各フォーマットエンジンの動作を管理する。
【００１４】
また、情報処理装置は、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである極小リソースをさらに備えていてもよい。このとき、個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用している動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態を示す共通状態情報をフォーマットエンジン管理手段へ出力する。また、個別状態取得手段は、フォーマットエンジンから取得した個別状態が極小リソースを利用していない動作状態を示す場合、当該フォーマットエンジンの共通状態情報として、所定の状態以外の状態を示す共通状態情報をフォーマットエンジン管理手段へ出力する。フォーマットエンジン管理手段は、共通状態情報が所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理する。
【００１５】
また、フォーマットエンジン管理手段は、起動受付手段と、共通状態取得手段と、動作停止手段と、起動手段とを含んでいてもよい。起動受付手段は、フォーマットエンジンを起動するための起動要求を受け付ける。共通状態取得手段は、起動受付手段が起動要求を受け付けたことに応じて、個別状態取得手段から各フォーマットエンジンの共通状態情報を取得する。動作停止手段は、共通状態取得手段によって取得された共通状態情報が所定の状態を示すフォーマットエンジンがある場合、当該フォーマットエンジンの動作を停止させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。起動手段は、動作停止手段によってフォーマットエンジンの動作が停止された後、起動要求に対応するフォーマットエンジンを起動させるメッセージを当該フォーマットエンジンに対応して設けられた動作制御手段へ送信する。
【００１６】
また、情報処理装置は、極小リソースと、リソース制御手段と、優先度情報格納手段とをさらに備えていてもよい。極小リソースは、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである。リソース制御手段は、フォーマットエンジンの要求に応じてフォーマットエンジンに対してリソースの利用を許可する。優先度情報格納手段は、極小リソースを利用する場合における各フォーマットエンジン間の優先度を示す優先度情報を格納する。許可決定手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、優先度情報に基づいて、当該極小リソースの利用を許可すべきフォーマットエンジンを決定する。このとき、リソース制御手段は、極小リソースを利用する要求が複数のフォーマットエンジン間で重複する場合、許可決定手段によって決定されたフォーマットエンジンのみに当該極小リソースの利用を許可し、極小リソースを利用する要求が複数のフォーマットエンジン間で重複しない場合、当該要求を行ったフォーマットエンジンに当該極小リソースの利用を許可する。
【００１７】
また、極小リソースは複数設けられてもよい。このとき、リソース制御手段は極小リソースに対応して複数設けられる。
【００１８】
また、本発明は、異なるフォーマットで記述されたデータをそれぞれ実行するためのフォーマットエンジンを格納している情報処理装置のコンピュータで実行可能なプログラムの形態で提供されてもよい。
【発明の効果】
【００１９】
本発明によれば、フォーマットエンジン管理手段は各フォーマットエンジンの動作状態を共通状態で管理するので、フォーマットエンジンが追加または変更された場合であっても、フォーマットエンジン管理手段の構成を大幅に変更する必要がない。従って、フォーマットエンジンの追加や変更に容易に対応することができる。さらに、フォーマットエンジン管理手段から動作制御手段への通信は、共通状態情報を含むメッセージによって行われる。従って、フォーマットエンジン管理手段は、フォーマットエンジンの違いを意識せずに各フォーマットエンジンの動作状態を管理できるので、複数のフォーマットエンジンの動作を同時に制御することが容易になる。
【００２０】
また、情報処理装置がテーブル格納手段をさらに備えることによって、個別状態と共通状態との相互の変換を容易に行うことができる。
【００２１】
また、さらに、情報処理装置が個別状態取得手段をさらに備えることによって、フォーマットエンジン管理手段は、各フォーマットエンジンの動作状態を容易に取得することができる。
【００２２】
また、さらに、フォーマットエンジン管理手段が、共通状態情報が所定の状態を示すフォーマットエンジンが１つのみになるように、各フォーマットエンジンの動作を管理することによって、次の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、極小リソースの利用が競合しないように、フォーマットエンジンの動作を管理することができる。換言すれば、フォーマットエンジン管理手段は、極小リソースの利用が競合しない範囲で、複数のフォーマットエンジンを同時に実行することも可能である。
【００２３】
また、さらに、フォーマットエンジン管理手段が、起動受付手段と、共通状態取得手段と、動作停止手段と、起動手段とを含んでいる場合には、次の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、起動要求に対応するフォーマットエンジンを確実に起動させることができるとともに、極小リソースの利用が競合しない範囲で、起動中のフォーマットエンジンの実行を継続することができる。
【００２４】
また、さらに、情報処理装置が、極小リソースと、リソース制御手段と、優先度情報格納手段とをさらに備えている場合には、以下の効果を得ることができる。すなわち、フォーマットエンジン管理手段は、極小リソースの利用が競合しないように、フォーマットエンジンの動作を管理することができる。換言すれば、フォーマットエンジン管理手段は、極小リソースの利用が競合しない範囲で、複数のフォーマットエンジンを同時に実行することも可能である。さらに、この場合、互いに異なる複数のフォーマットエンジンは、それぞれ、互いに異なる複数の極小リソースを同時に利用することも可能である。
【００２５】
また、極小リソースが複数設けられている場合には、各フォーマットエンジンは、それぞれ別個の極小リソースを同時に利用することができる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明に係る情報処理装置の実施の形態を、図面を参照しながら説明する。なお、以下の実施の形態では、情報処理装置の一例としてデジタルテレビを用いて説明するが、本発明は携帯電話や携帯情報端末等においても適用可能である。
【００２７】
（ハードウェア構成）
まず、図１〜図３を参照して、情報処理装置のハードウェア構成について説明する。図１は、本実施の形態に係る情報処理装置の一例であるデジタルテレビのハードウェア構成を表すブロック図である。図１において、デジタルテレビ１００は、チューナ１０１、デスクランブラ１０２、ＴＳデコーダ１０３、オーディオデコーダ１０４、スピーカ１０５、ビデオデコーダ１０６、ディスプレイ１０７、２次記憶部１０８、１次記憶部１０９、ＲＯＭ１１０、入力部１１１、ネットワークインターフェース１１２、およびＣＰＵ１１３を備えている。
【００２８】
図２は、図１に示すデジタルテレビ１００の外観を示す図である。図１に示すデジタルテレビ１００は、例えば図２に示すような薄型テレビとして実現される。図２に示すように、デジタルテレビ１００は、図１に示す構成に加え、筐体２０１および信号入力端子２０４をさらに備えている。なお、ディスプレイ２０２は、図１に示すディスプレイ１０７に相当する。また、フロントパネル部２０３は、図１に示す入力部１１１に相当する。フロントパネル部２０３は、複数のボタンで構成される。なお、フロントパネル部２０３の詳細な構成は後述する図３に示されている。信号入力端子２０４は、地上波放送の放送局、衛星のアンテナ、あるいはケーブルテレビの局システムからの放送信号をデジタルテレビ１００に入力するための端子である。信号入力端子２０４は、図１のチューナ１０１と接続されている。なお、デジタルテレビ１００は、インターネットに接続するためのネットワーク端子を有している。ネットワーク端子は、ネットワークインターフェース１１２と接続されている。
【００２９】
次に、デジタルテレビ１００の基本的な動作を説明する。チューナ１０１は、信号入力端子２０４を介して送信されてきた放送信号を入力する。チューナ１０１は、ＣＰＵ１１３によって指定された周波数を示すチューニング情報に従って、入力した放送信号を復調する。復調された放送信号は、デスクランブラ１０２に引き渡される。デスクランブラ１０２は、復調された放送信号を復号する。復号に必要な鍵はＣＰＵ１１３から与えられる。復号によって得られるＭＰＥＧ２トランスポートストリームは、ＴＳデコーダ１０３へ出力される。
【００３０】
ＴＳデコーダ１０３は、デスクランブラ１０２から受け取ったＭＰＥＧ２トランスポートストリームに対してフィルタリングを行い、必要なデータをオーディオデコーダ１０４、ビデオデコーダ１０６あるいはＣＰＵ１１３に引き渡す。ＭＰＥＧ２トランスポートストリームの詳細はＭＰＥＧ規格書“ＩＳＯ／ＩＥＣ１３８１８−１”に記載されているので詳細な記述は省略する。ＭＰＥＧ２トランスポートストリームは、複数の固定長パケットで構成され、各パケットには映像、音声、字幕データ、およびアプリケーション等が格納されている。また、各パケットにはパケットＩＤが与えられている。ＴＳデコーダ１０３は、ＣＰＵ１１３によってパケットＩＤとそのパケットＩＤを有するパケットの出力先の組を指示される。パケットの出力先は「オーディオデコーダ１０４」、「ビデオデコーダ１０６」、および「ＣＰＵ１１３」のいずれかである。例えば、ＣＰＵ１１３が、パケットＩＤが「１２３」であるパケットの出力先が「ビデオデコーダ１０６」である旨の指示をＴＳデコーダ１０３へ出力した場合、ＴＳデコーダ１０３は、ＭＰＥＧ２トランスポートストリームからパケットＩＤが「１２３」であるパケットを抽出し、そのパケットをビデオデコーダ１０６に引き渡す。なお、ＴＳデコーダ１０３は、複数のフィルタリング処理を平行して実行することができる。
【００３１】
オーディオデコーダ１０４は、ＴＳデコーダ１０３から引き渡された各パケットに埋め込まれているオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ１０５へ出力する。スピーカ１０５は、オーディオデコーダ１０４から出力された信号を音声出力する。ビデオデコーダ１０６は、ＴＳデコーダ１０３から引き渡された各パケットに埋め込まれているビデオデータを連結し、デジタル−アナログ変換を行うことによって得られるビデオ信号をディスプレイ１０７へ出力する。ディスプレイ１０７は、典型的にはブラウン管や液晶表示装置等で構成され、ビデオデコーダ１０６から出力されたビデオ信号を出力する。さらに、ディスプレイ１０７は、ＣＰＵ１１３から指示されたメッセージ等を表示することもある。
【００３２】
２次記憶部１０８は、典型的にはフラッシュメモリやハードディスク等で構成され、ＣＰＵ１１３から指示されたデータやプログラムを保存する。保存されているデータやプログラムはＣＰＵ１１３に参照される。保存されているデータやプログラムは、デジタルテレビ１００の電源が切断された状態でも保存しつづける。１次記憶部１０９は、典型的にはＲＡＭ等で構成され、ＣＰＵ１１３から指示されたデータやプログラムを一次的に保存する。保存されているデータやプログラムはＣＰＵ１１３に参照される。保存されているデータやプログラムは、デジタルテレビ１００の電源が切断された際に、抹消される。ＲＯＭ１１０は、書き換え不可能なメモリデバイスであり、典型的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤ等で構成される。ＲＯＭ１１０には、ＣＰＵ１１３によって実行されるプログラムが格納されている。
【００３３】
入力部１１１は、典型的にはフロントパネルやリモコンで構成され、ユーザからの入力を受け付ける。図３は、入力部１１１を構成するフロントパネルの一例を示す図である。図３において、フロントパネル３００は９つのボタン、すなわち、上カーソルボタン３０１、下カーソルボタン３０２、左カーソルボタン３０３、右カーソルボタン３０４、ＯＫボタン３０５、取消ボタン３０６、ＭＥＮＵボタン３０７、Ｃ＋ボタン３０８、およびＣ−ボタン３０９を備えている。ユーザが各ボタンを押下すると、押下されたボタンを示す識別子がＣＰＵ１１３に通知される。
【００３４】
ネットワークインターフェース１１２は、典型的にはモデムやイーサネット（登録商標）コネクター等で構成され、インターネットやイントラネット等のネットワークと接続する機能をデジタルテレビ１００に提供するものである。ネットワークインターフェース１１２は、ＣＰＵ１１３からの指示に従い、ネットワーク上に接続された他の情報機器とのデータの送受信を行う。例えばネットワークインターフェース１１２がモデムによって構成されている場合、ネットワークインターフェース１１２は、ＣＰＵ１１３から接続先の電話番号や通信パラメータ情報を受け取り、ネットワークとの通信経路を確立する。
【００３５】
ＣＰＵ１１３は、ＲＯＭ１１０が記憶するプログラムを実行する。ＣＰＵ１１３は、プログラムの指示に従い、チューナ１０１、デスクランブラ１０２、ＴＳデコーダ１０３、ディスプレイ１０７、２次記憶部１０８、１次記憶部１０９、およびＲＯＭ１１０の動作を制御する。ＣＰＵ１１３の詳細な動作については後述する。
【００３６】
（動作概要）
次に、情報処理装置の詳細な構成および動作を説明する前に、図４〜図６を参照して、本発明の目的を達成するための情報処理装置の動作の概要を説明する。ここでは、情報処理装置の動作例として、第１および第２の動作例という２つの動作例について説明する。
【００３７】
（第１の動作例）
まず、図４および図５を用いて第１の動作例の概要を説明する。図４は、第１の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。図４において、デジタルテレビは、フォーマットエンジン管理部４１と、第１の変換部４２と、第２の変換部４３と、第１のテーブル格納部４４と、第２のテーブル格納部４９と、第１のフォーマットエンジン４５と、第２のフォーマットエンジン４６と、リソース制御部４７と、リソース４８とを備えている。図４において、リソース４８以外の各構成要素は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。また、リソース４８は、フォーマットエンジンによって利用されるハードウェアである。リソース４８は、例えば、メモリ（１次記憶部１０９および２次記憶部１０８）や、チューナ１０１、ＴＳデコーダ１０３、ネットワークインターフェース１１２等である。なお、図４では、説明を容易にする目的で、デジタルテレビ１００が有するフォーマットエンジンの数を２つとして説明するが、フォーマットエンジンの数は２つ以上であってもよい。
【００３８】
ここで、各フォーマットエンジン４５および４６は、複数種類の動作状態を取り得る。すなわち、各フォーマットエンジン４５および４６は、「実行されている状態」や、「実行されていない状態」等の状態を取り得る。以下、情報処理装置の動作概要を説明する図４〜図６においては、第１のフォーマットエンジン４５は、「動作中」、「停止中」、および「一時停止中」と表現される３種類の動作状態を取り得るものとする。また、第２のフォーマットエンジン４６は、「起動中」および「起動中でない」という２種類の動作状態を取り得るものとする。ここで、各フォーマットエンジンにおいて個別に規定された動作状態を、個別状態と呼ぶ。つまり、第１のフォーマットエンジン４５においては、「動作中」、「停止中」、および「一時停止中」と表現される３種類の動作状態を含む個別状態が規定されている。また、第２のフォーマットエンジン４６においては、「起動中」および「起動中でない」という２種類の動作状態を含む個別状態が規定されている。なお、一般的に、各フォーマットエンジンが取り得る動作状態の種類は、フォーマットエンジンによって様々である。
【００３９】
フォーマットエンジン管理部４１は、各フォーマットエンジン４５および４６の動作を管理する。具体的には、各フォーマットエンジン４５および４６に対して、起動や停止等の指示を行う。ここで、フォーマットエンジン管理部４１においては、各フォーマットエンジンが取り得る動作状態は、共通状態として予め規定されている。共通状態とは、全てのフォーマットエンジンに共通の表現によってフォーマットエンジンの動作状態を規定した概念である。図４においては、フォーマットエンジン管理部４１においては、「実行中」および「終了」と表現される２種類の動作状態を含む共通状態が規定されるものとする。このように、共通状態は、各フォーマットエンジン４５および４６において規定されている動作状態（すなわち、個別状態）とは異なる表現であってもよい。また、共通状態に含まれる動作状態の種類は２種類に限らない。共通状態に含まれる動作状態の種類は、フォーマットエンジン管理部４１が各フォーマットエンジンを管理するために必要となる数の動作状態の種類を定義しておけばよい。
【００４０】
また、フォーマットエンジン管理部４１は、例えばユーザからの入力に従って、フォーマットエンジンに対して動作を指示する。このとき、フォーマットエンジン管理部４１は、共通状態情報を用いて指示を行う。共通状態情報とは、フォーマットエンジンの動作状態を共通状態によって表現した情報である。図４において、例えば、フォーマットエンジン管理部４１が第１のフォーマットエンジン４５の動作状態が所定の動作状態となるように指示を行う場合、フォーマットエンジン管理部４１は、当該所定の動作状態を示す共通状態情報を第１の変換部４２へ出力する。これと同様に、フォーマットエンジン管理部４１は、第２のフォーマットエンジン４６に対して動作の指示を行う場合、第２の変換部４３へ共通状態情報を出力する。
【００４１】
また、フォーマットエンジン管理部４１は、各変換部４２および４３から出力されてくる共通状態情報を受け取ることによって、各フォーマットエンジン４５および４６の動作状態を共通状態の表現によって把握する。このように把握された共通状態を用いて、フォーマットエンジン管理部４１は、各フォーマットエンジン４５および４６の動作を管理することができる。
【００４２】
第１の変換部４２は、フォーマットエンジン管理部４１から出力されてくる共通状態情報に基づいて第１のフォーマットエンジン４５の動作を制御する。すなわち、第１の変換部４２は、フォーマットエンジン管理部４１において規定される共通状態と、第１のフォーマットエンジン４５において規定される個別状態との対応を予め規定しておく。フォーマットエンジン管理部４１から共通状態情報が出力されてくると、第１の変換部４２は、当該対応に基づいて、共通状態情報により示される共通状態に対応する個別状態を特定する。さらに、第１の変換部４２は、特定した個別状態となるように第１のフォーマットエンジン４５の動作を制御する。
【００４３】
また、第１の変換部４２は、第１のフォーマットエンジン４５の動作状態（個別状態で表現されている）を取得し、取得した動作状態を共通状態によって表現される形でフォーマットエンジン管理部４１へ通知する。つまり、第１の変換部４２は、第１のフォーマットエンジン４５から取得した動作状態を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。共通状態情報をフォーマットエンジン管理部４１へ出力する場合も、上記共通状態と個別状態との対応が用いられる。すなわち、第１のフォーマットエンジン４５から個別状態を取得すると、第１の変換部４２は、上記対応に基づいて、取得した個別状態に対応する共通状態を特定する。さらに、第１の変換部４２は、特定した共通状態を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。
【００４４】
第２の変換部４３は、第１の変換部４２と同様の処理を行う。すなわち、第２の変換部４３は、フォーマットエンジン管理部４１から出力されてくる共通状態情報に基づいて第２のフォーマットエンジン４６の動作を制御する。また、第２の変換部４３は、第２のフォーマットエンジン４６の動作状態（個別状態で表現されている）を取得し、取得した動作状態を共通状態によって表現される形でフォーマットエンジン管理部４１へ通知する。これらの動作の詳細は、第１の変換部４２における動作と同様の方法で行われる。
【００４５】
第１のテーブル格納部４４は、フォーマットエンジン管理部４１において規定される共通状態と、第１のフォーマットエンジン４５において規定される個別状態とを対応付けたテーブルを格納する。また、第２のテーブル格納部４４は、フォーマットエンジン管理部４１において規定される共通状態と、第２のフォーマットエンジン４６において規定される個別状態とを対応付けたテーブルを格納する。図５は、各テーブル格納部４４および４９が格納するテーブルの一例を示す図である。図５（ａ）は、第１のテーブル格納部４４が格納するテーブルの一例を示す図であり、図５（ｂ）は、第２のテーブル格納部４９が格納するテーブルの一例を示す図である。図５（ａ）においては、「実行中」という共通状態に対して、「動作中」という個別状態が対応付けられる。また、「終了」という共通状態に対して、「停止中」および「一時停止中」という個別状態が対応付けられる。図５（ｂ）においては、「実行中」という共通状態に対して、「起動中」という個別状態が対応付けられている。また、「終了」という共通状態に対して、「起動中でない」という個別状態が対応付けられている。各変換部４２および４３は、図５に示すテーブルを参照して、フォーマットエンジン管理部４１から出力されてくる共通状態情報により示される共通状態に対応する個別状態を特定する。また、各変換部４２および４３は、図５に示すテーブルを参照して、各フォーマットエンジン４５および４６から取得した個別状態に対応する共通状態を特定する。
【００４６】
例えば、第１の変換部４２に「実行中」を示す共通状態情報が出力されてきた場合、第１の変換部４２は、図５（ａ）に示すテーブルを参照して、「動作中」という個別状態を特定する。そして、第１の変換部４２は、特定した「動作中」という動作状態となるように第１のフォーマットエンジン４５を制御する。また、例えば、第２の変換部４３が第２のフォーマットエンジン４６から「起動中でない」を示す個別状態を取得した場合、第２の変換部４３は、上記図５（ｂ）に示すテーブルを参照して、「終了」という共通状態を特定する。そして、第２の変換部４３は、特定した「終了」を示す共通状態情報をフォーマットエンジン管理部４１へ出力する。
【００４７】
また、図４において、リソース制御部４７は、各フォーマットエンジン４５および４６の要求に応じて、各フォーマットエンジン４５および４６に対してリソース４８の利用を許可する。
【００４８】
なお、以上の動作は、後述する第２の動作例においても同様である。
【００４９】
ここで、リソース４８が極小リソースである場合を考える。極小リソースとは、フォーマットエンジンが実行中に利用するリソースであって、複数のフォーマットエンジンが同時に利用することが不可能なリソースである。例えば、チューナ１０１や、ＴＳデコーダ１０３や、ネットワークインターフェース１１２は極小リソースである。極小リソースは、デジタルテレビ１００が有している数が限られたリソースで、かつ、複数のフォーマットエンジンが同時に使用を試み、競合する可能性のあるリソースのことである。例えば、チューナ１０１は１つの周波数帯にしかチューニングできない。複数のフォーマットエンジンが異なる周波数帯にチューニングしたい場合にリソースの競合が発生する。このような極小リソースは複数のフォーマットエンジンが同時に利用することができないので、リソース制御部４７は、複数のフォーマットエンジンに対して極小リソースの利用を同時に許可しないようにする必要がある。もしリソース制御部４７が複数のフォーマットエンジンに対して極小リソースの利用を同時に許可すれば、当該フォーマットエンジンの動作が正常に行われない可能性がある。そこで、図４においては、フォーマットエンジンの動作を正常に行うための方法として、以下の方法をとる。
【００５０】
図４においては、各テーブル格納部４４および４９に格納されているテーブルにおける共通状態と個別状態との対応付けは、次のように行われる。すなわち、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる。さらに、フォーマットエンジンが極小リソースを利用しない動作状態を表す個別状態に対して、「終了」という共通状態が対応付けられる。なお、図４においては、第１のフォーマットエンジン４５は、「動作中」という個別状態においてのみ極小リソースを利用し、他の個別状態においては極小リソースを利用しないものとする。また、第２のフォーマットエンジン４６は、「起動中」という個別状態においてのみ極小リソースを利用し、他の個別状態においては極小リソースを利用しないものとする。このとき、上記テーブルは図５に示すようになる。
【００５１】
上記テーブルの対応付けを以上のように行うとともに、さらに、フォーマットエンジン管理部４１は、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する。これによって、フォーマットエンジン管理部４１は、極小リソースを利用するフォーマットエンジンが１つになるように各フォーマットエンジン４５および４６の動作を管理することができる。フォーマットエンジン管理部４１による具体的な管理方法は種々考えられる。具体的な管理方法については、後述する処理例において述べる。
【００５２】
（第２の動作例）
次に、図６を用いて第２の動作例について説明する。図６は、第２の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図である。図６において、デジタルテレビは、図４に示す構成に加えて、許可決定部６１と、優先度情報格納部６２とを備えている。なお、図６において、図４に示す構成要素と同じ構成要素には同じ参照符号を付している。図６において、許可決定部６１および優先度情報格納部６２は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。
【００５３】
図４における動作と図６における動作との相違点は、リソース４８が極小リソースである場合における、フォーマットエンジンの動作を正常に行うための方法である。その他の動作、例えば、フォーマットエンジン管理部４１が共通状態によって各フォーマットエンジン４５および４６の動作を管理する動作や、各変換部４２および４３が共通状態と個別状態との相互の変換を行う動作については、図４と同様である。従って、以下では、第２の動作例においてフォーマットエンジンの動作を正常に行うための方法を説明する。
【００５４】
第２の動作例では、各テーブル格納部４４および４９において、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる必要はない。さらに、フォーマットエンジン管理部４１は、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する必要はない。第２の動作例では、リソース４８を利用する要求がリソース制御部４７において重複した場合、リソースを使用可能なフォーマットエンジンが優先度情報に基づいて選択される。以下、詳細を説明する。
【００５５】
優先度情報格納部６２は、優先度情報を格納する。優先度情報とは、極小リソースであるリソース４８を利用する場合における各フォーマットエンジン間の優先度を示す情報である。図６においては、優先度情報は、第１のフォーマットエンジン４５と第２のフォーマットエンジン４６とのいずれを優先するかを示す情報である。
【００５６】
リソース制御部４７は、リソース４８を利用する要求がリソース制御部４７において重複した場合、すなわち、リソース４８を利用する要求が複数のフォーマットエンジンから同時に行われた場合、要求が重複した旨の通知を許可決定部６１へ出力する。
【００５７】
許可決定部６１は、要求が重複した旨の通知をリソース制御部４７から受け取った場合、優先度情報格納部６２に格納されている優先度情報に基づいて、リソース４８の利用を許可すべきフォーマットエンジンを決定する。さらに、許可決定部６１は、決定したフォーマットエンジンを示す情報をリソース制御部４７へ出力する。リソース制御部４７は、当該情報により示されるフォーマットエンジンにリソース４８の利用を許可する。以上によって、極小リソースを利用するフォーマットエンジンが１つになるように各フォーマットエンジン４５および４６の動作を管理することができる。なお、利用が許可されなかったフォーマットエンジンに対して、利用を許可しない旨の通知がリソース制御部４７またはフォーマットエンジン管理部４１によって行われてもよい。
【００５８】
以上のように、上記第１および第２動作例によれば、フォーマットエンジン管理部４１は共通状態を用いて各フォーマットエンジン４５および４６の動作を管理する。共通状態は各フォーマットエンジンにおいて規定される個別状態とは別個であり、管理すべきフォーマットエンジンとは無関係である。従って、仮にフォーマットエンジンの追加や変更があった場合でも、共通状態として規定されている内容を変更する必要はない。つまり、フォーマットエンジン管理部４１を変更する必要はない。フォーマットエンジンの追加があった場合には、当該フォーマットエンジンを追加するとともに、それに対応する変換部を追加すればよいだけである。つまり、追加するフォーマットエンジンにおいて規定される個別状態と共通状態との対応を新たに追加すればよいだけである。以上のように、上記第１および第２動作例によれば、仮にフォーマットエンジンの追加や変更があった場合でも、当該追加や変更に容易に対応することができる。
【００５９】
さらに、リソース４８が極小リソースである場合、上記第１および第２動作例によれば、極小リソースを複数のフォーマットエンジンが同時に利用しないように各フォーマットエンジンの動作が管理される。従って、極小リソースを利用する複数のフォーマットエンジンが正常に動作しなくなることを防止することができる。
【００６０】
なお、上記第１および第２の動作例においては、リソース４８が１つである場合について説明したが、リソースは複数であってもよい。リソースが複数である場合、リソース制御部はリソースに対応して、リソースと同数設けられる必要がある。なお、第１の動作例においてリソースが複数である場合であっても、フォーマットエンジンが極小リソースを利用する動作状態を表す個別状態に対して、「実行中」という共通状態が対応付けられる点は上記第１の動作例と同様である。また、第１の動作例においてリソースが複数である場合であっても、フォーマットエンジン管理部４１が、共通状態が「実行中」であるフォーマットエンジンが１つになるように、各フォーマットエンジン４５および４６の動作を管理する点は上記第１の動作例と同様である。
【００６１】
また、第２の動作例においてリソースが複数である場合、極小リソースに対応して設けられるリソース制御部は、上記第２の動作例と同様の動作を行う。これによって、極小リソースが複数である場合、各極小リソースが重複して利用されることを防止することができる。さらに、第２の動作例では、互いに異なる複数のフォーマットエンジンは、それぞれ、互いに異なる複数の極小リソースを同時に利用することが可能である。つまり、あるフォーマットエンジンＡが極小リソースＡを利用している場合に、別のフォーマットエンジンＢは極小リソースＢを利用することができる。なお、第１の動作例では、極小リソースが複数である場合、複数の極小リソースを同時に利用することは不可能であった。これに対して第２の動作例では、複数の極小リソースを同時に利用することができる点で、第１の動作例よりも効率よくフォーマットエンジンを実行することができると言える。
【００６２】
なお、上記第１および第２の動作例においては、各変換部４２および４３は、フォーマットエンジンと別個に構成されるものとしたが、フォーマットエンジンと一体的に構成されるものであってもよい。換言すれば、フォーマットエンジンは、変換部の機能を有するものであってもよい。以上で、第１および第２の動作例の概要の説明を終了する。
【００６３】
（具体的な構成例）
次に、図７〜図７３を用いて、本発明に係る情報処理装置の具体的な構成を説明する。なお、以下で説明する構成は、上述した第１および第２の動作例の双方を実現することが可能な構成である。従って、以下で説明する構成には、第１の動作例のみを実行する場合には不要である構成や、第２の動作例のみを実行する場合には不要である構成が含まれるが、そのような構成については説明中において適宜述べる。
【００６４】
図７は、情報処理装置の機能的な構成をより具体的に示す図である。図７に示す各構成要素は、図１に示すＣＰＵ１１３がＲＯＭ１１０に格納されたプログラムを１次記憶部１０９および２次記憶部１０８を用いて実行することによって実現される。換言すれば、図７は、ＲＯＭ１１０に記憶され、ＣＰＵ１１３に実行されるプログラムの構成を示す図である。
【００６５】
図７において、情報処理装置は、ＯＳ７１０と、ナビゲータ７２０と、結合部７３０と、Ｊａｖａ（登録商標）ミドルウェア（以下、単に「Ｊａｖａミドルウェア」と記載する。）７４０と、ＨＴＭＬブラウザ７５０と、メーラー７６０と、第１の変換部７４１と、第２変換部７５１と、第３の変換部７６１とを備えている。これらは、ＲＯＭ１１０に格納されているプログラムのサブプログラムである。なお、図４に示すフォーマットエンジン管理部４１は、ナビゲータ７２０および結合部７３０の機能の一部として実現される。
【００６６】
図７に示すサブプログラムの内、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０は、所定のフォーマットで記述されたアプリケーションの実行や、所定のフォーマットで記述されたデータの表示等を行うフォーマットエンジンである。以下に説明する具体的な構成例では、これら３種類のフォーマットエンジンを例として取り上げたが、フォーマットエンジンは、ワードプロセッサプログラムやスプレッドシートプログラム等であってもよい。また、情報処理装置が備えるフォーマットエンジンの数は３つに限るものではなく、１つでも２つでもよく、４つ以上でもよい。ただし、フォーマットエンジンの数と同数の変換部を用意する必要がある。
【００６７】
ＯＳ７１０は、デジタルテレビ１００の電源が投入されると、ＣＰＵ１１３が起動するサブプログラムである。ＯＳ７１０は、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ７１０は、他のサブプログラムを平行して実行するカーネル７１１およびライブラリ７１２等で構成されるプログラム群の総称であり、詳細な説明は省略する。本構成例においては、ＯＳ７１０のカーネル７１１は、電源投入後にナビゲータ７２０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０をサブプログラムとして起動する。ＯＳ７１０がＬｉｎｕｘである場合、ＯＳ７１０は、これらサブプログラムに対してそれぞれ個別のプロセスを起動し、それぞれのプロセス内で個々のサブプログラムを実行する。
【００６８】
ＯＳ７１０のライブラリ７１２は、他のサブプログラムに対して、デジタルテレビ１００が有するハードウェア構成要素（リソース）を制御するための複数の機能を提供する。つまり、図４に示すリソース制御部４７は、ライブラリ７１２の機能の一部として実現される。本構成例では、複数の機能の一例として、チューナライブラリ（チューナＬｉｂ）７１２１、デスクランブラライブラリ（デスクランブラＬｉｂ）７１２２、およびＡＶ再生ライブラリ（ＡＶ再生Ｌｉｂ）７１２３を取り上げる。これらは、図４に示すリソース制御部４７の機能を実現するものである。
【００６９】
チューナＬｉｂ７１２１は、チューナ１０１を制御する機能をサブプログラムに提供する。すなわち、チューナＬｉｂ７１２１は、チューナ１０１に与える周波数を含むチューニング情報をサブプログラムから受け取る。そして、チューナＬｉｂ７１２１は、受け取った情報をチューナ１０１に与えるとともに、チューニングを行うようにチューナ１０１に指示する。
【００７０】
デスクランブラＬｉｂ７１２２は、デスクランブラ１０２を制御する機能をサブプログラムに提供する。すなわち、デスクランブラＬｉｂ７１２２は、鍵等を含む復号情報をサブプログラムから受け取る。そして、デスクランブラＬｉｂ７１２２は、受け取った情報をデスクランブラ１０２に与えるとともに、デスクランブラ１０２に復号を行うように指示する。
【００７１】
ＡＶ再生Ｌｉｂ７１２３は、ＴＳデコーダ１０３を制御し、映像・音声再生を行う機能をサブプログラムに提供する。すなわち、ＡＶ再生Ｌｉｂ７１２３は、再生すべき映像のパケットＩＤおよび音声のパケットＩＤをサブプログラムから受け取る。そして、ＡＶ再生Ｌｉｂ７１２３は、受け取った映像のパケットＩＤと出力先「ビデオデコーダ１０６」との組、および、受け取った音声のパケットＩＤと出力先「オーディオデコーダ１０４」との組をＴＳデコーダ１０３に与えると共に、ＴＳデコーダ１０３にフィルタリングを行うように指示する。これによって、音声データを含むパケットがオーディオデコーダ１０４に引き渡された後、音声データはスピーカ１０５を通して再生される。また、映像データを含むパケットがビデオデコーダ１０６に引き渡された後、映像データは、ディプレイ１０７を通して再生される。
【００７２】
ナビゲータ７２０は、例えばユーザの指示に従って、フォーマットエンジンの起動や停止をフォーマットエンジンに対して指示する。また、ナビゲータ７２０は、デジタルテレビのチャンネル切り替えや、フォーマットエンジンでのアプリケーションの実行・停止、データの再生・停止等を指示する。ナビゲータ７２０は、ＯＳ７１０のカーネル７１１によって起動されるサブプログラムである。
【００７３】
次に、ナビゲータ７２０によるチャンネルの切り替えの動作を説明する。なお、入力部１１１は、図３で示されるフロントパネルであるとする。ユーザがＣ＋ボタン３０８あるいはＣ−ボタン３０９を押下すると、ナビゲータ７２０は、押下されたボタンの識別子を受け取り、再生しているチャンネルを切り替える。ここで、Ｃ＋ボタン３０８はチャンネル番号を番号が大きくなる方へ変化させ、Ｃ−ボタン３０９はチャンネル番号を番号が小さくなる方へ変化させる。再生可能なチャンネルの番号が例えば「１」、「２」「４」「６」「８」で、現在チャンネル「６」を再生しているとする。ここで、ユーザがＣ＋ボタン３０８を押下するとナビゲータ７２０は、再生するチャンネルを「６」から「８」に変更する。また、ユーザがＣ―ボタン３０９を押下するとナビゲータ７２０は、再生するチャンネルを「６」から「４」に変更する。チャンネル変更は、チャンネルに対応する映像・音声を含むパケットＩＤをＯＳ７１０のライブラリ７１２に含まれるＡＶ再生Ｌｉｂ７１２３に与えることによって行われる。この動作は、現在市販されているテレビの基本的な機能であるので、詳細な説明は省略する。
【００７４】
次に、図８〜図１６を用いて、フォーマットエンジン等の起動指示がユーザによって行われる際のナビゲータ７２０の動作を説明する。ユーザが入力部１１１のＭＥＮＵボタン３０７を押下すると、ナビゲータ７２０は、実行可能なフォーマットエンジンの一覧をディスプレイ１０７に表示する。図８、図９および図１０は、ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図である。図８〜図１０では、フォーマットエンジンの一覧として、フォーマットエンジン名とその状態との組が表示される。さらに、フォーマットエンジンを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することに応じて移動する。図８に示す状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図９に示す状態になる。図９の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１０に示す状態になる。図９に示す状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図８に示す状態になる。なお、図８〜図１０において、表示される各フォーマットエンジン（Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０）の状態は、ナビゲータ７２０によって結合部７３０から取得される。
【００７５】
また、図８に示す状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションの一覧を表示する。図１１および図１２は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図である。図１１および図１２では、実行可能なアプリケーションの一覧として、アプリケーション名とその状態との組が表示される。さらに、アプリケーションを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することに応じて移動する。図１１の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１２の状態になる。図１２の状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図１１の状態になる。なお、図１１および図１２において、表示される各アプリケーションの状態は、ナビゲータ７２０によって結合部７３０から取得される。
【００７６】
また、図１１の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、アプリケーション「ＥＰＧ」を起動するように結合部７３０に対して指示する。図１２の状態でＯＫボタン３０５を押下すると、ナビゲータ７２０は、アプリケーション「トランプゲーム」を起動するように結合部７３０に対して指示する。
【００７７】
図１１および図１２では、全てのアプリケーションが停止中であったが、アプリケーションが「一時停止中」あるいは、「実行中」の場合もある。図１３および図１４は、ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図である。図１３および図１４では、「ＥＰＧ」の動作状態が「実行中」であり、「トランプゲーム」の動作状態が「一時停止中」である。図１３の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にアプリケーション「ＥＰＧ」を停止するように指示する。図１４の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にアプリケーション「トランプゲーム」を停止するように指示する。まとめると、「停止中」であるアプリケーションをカーソル８１によって選択している状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該アプリケーションを起動するように結合部７３０に対して指示する。一方、「実行中」あるいは「一時停止中」であるアプリケーションをカーソル８１によって選択している状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にそのアプリケーションを停止するように指示する。
【００７８】
また、図９の状態で、ユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、ＨＴＭＬブラウザ７５０が表示可能なデータの一覧を表示する。図１５および図１６では、実行可能なデータの一覧として、データ名とその状態との組が表示される。さらに、ユーザがデータを選択するためにカーソル８１が表示される。カーソル８１は、ユーザが入力部１１１の上カーソルボタン３０１または下カーソルボタン３０２を押下することにより移動する。図１５の状態で下カーソルボタン３０２が押下されると、カーソル８１は１つ下に移動して図１６の状態になる。図１６の状態で上カーソルボタン３０１が押下されると、カーソル８１は１つ上に移動して図１５の状態になる。なお、表示される各データの状態は、ナビゲータ７２０によって結合部７３０から取得される。また、図１５の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にデータ「天気予報」を停止するように指示する。図１６の状態でユーザがＯＫボタン３０５を押下すると、ナビゲータ７２０は、結合部７３０にデータ「レジャー情報」を停止するように指示する。
【００７９】
また、図１０の状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、メーラー７６０を起動するように結合部７３０に対して指示する。メーラー７６０は、取り扱う個々のデータに関する動作状態（例えば、停止中、実行中、一時停止中）を持っておらず、メーラー７６０自身の動作状態のみが規定されている。従って、図１０の状態でユーザが入力部１１１のＯＫボタン３０５を押下しても、Ｊａｖａミドルウェア７４０やＨＴＭＬブラウザ７５０のように個々のフォーマットエンジンが取り扱うアプリケーションやデータの一覧を表示することはない。ナビゲータ７２０は、メーラー７６０が取り扱うアプリケーションやデータの状態の一覧を結合部７３０から取得する際、メーラー７６０が個々のアプリケーションやデータの動作状態を保持していないことを知る。あるいは、ナビゲータ７２０は、メーラー７６０が個々のアプリケーションやデータの動作状態を保持していないことを予め知っていてもよい。
【００８０】
以上のように、ナビゲータ７２０は、個々のアプリケーションやデータの動作状態を保持していないフォーマットエンジンに対しては、ナビゲータ７２０は、次のように動作する。すなわち、フォーマットエンジンの動作状態が「停止中」であるフォーマットエンジンがカーソル８１によって選択されている状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該フォーマットエンジンを起動するように結合部７３０に対して指示する。一方、「実行中」あるいは「一時停止中」であるフォーマットエンジンがカーソル８１によって選択されている状態でユーザが入力部１１１のＯＫボタン３０５を押下すると、ナビゲータ７２０は、当該フォーマットエンジンを停止するように結合部７３０に対して指示する。
【００８１】
なお、フォーマットエンジンあるいはフォーマットエンジンが取り扱うアプリケーションやデータの一覧が表示されている場合（図８〜図１６）において、ユーザが入力部１１１のＭＥＮＵボタン３０７を押下すると、ナビゲータ７２０は、当該一覧の表示を取りやめる。
【００８２】
図７の説明に戻り、結合部７３０は、ナビゲータ７２０と複数のフォーマットエンジンとを結合するためのモジュールである。結合部７３０は、通信部７３１と、状態管理部７３２と、リソース管理部７３３とを備えている。
【００８３】
通信部７３１は、ナビゲータ７２０と各フォーマットエンジンとの間の通信を行う。ここで、通信とはメッセージデータの送受信を意味する。具体的には、ナビゲータ７２０がフォーマットエンジンに対して指示を行う場合、ナビゲータ７２０は当該指示を示すメッセージを通信部７３１を介して当該フォーマットエンジンへ送る。例えば、ナビゲータ７２０が、Ｊａｖａミドルウェア７４０が実行しているアプリケーションを停止する旨の指示を行う場合、ナビゲータ７２０は、当該停止の指示を意味するメッセージを通信部７３１を通してＪａｖａミドルウェア７４０に送る。
【００８４】
なお、ナビゲータ７２０や各フォーマットエンジンは、異なるプロセスあるいはスレッドで動作しているので、プロセス間通信あるいはスレッド間通信を行う必要がある。プロセス間通信あるいはスレッド間通信は、ＯＳがＬｉｎｕｘであれば、Ｓｏｃｋｅｔ、ＰＩＰＥ等のＯＳ７１０が備える機能を利用することによって実現することができる。
【００８５】
ここで、もし、ナビゲータ７２０と各フォーマットエンジンとの間で個別に通信方法を決定することとすると、ナビゲータ７２０および各フォーマットエンジンは、複数種類の通信方法を実装しなければならない。従って、全プログラムのコード量が増え、開発工数も大きくなる。そこで、通信部７３１は、ナビゲータ７２０および各フォーマットエンジンが使用する共通の通信方法を規定する。ここでは、ナビゲータ７２０はＳｏｃｋｅｔ通信を用いることとするが、ＦＩＦＯ等、他の方法を用いても実現可能である。通信部７３１は、さらにＳｏｃｋｅｔ通信のプロトコル上に、独自のメッセージフォーマットを規定する。
【００８６】
次に、図１７〜図３１を用いて、メッセージフォーマットについて詳細を説明する。図１７は、メッセージフォーマットの一例を示す図である。図１７において、メッセージは５つのフィールドで構成される。Ｓｏｕｒｃｅ  ＩＤフィールド１７１は、メッセージの送信元であるサブプログラムを示す情報を格納する。なお、サブプログラムには、サブプログラムを識別するためのサブプログラムＩＤが割り当てられる（後述する図１８参照。）。Ｓｏｕｒｃｅ  ＩＤフィールド１７１は、メッセージの送信元であるサブプログラムのサブプログラムＩＤを格納する。具体的には、Ｓｏｕｒｃｅ  ＩＤフィールド１７１は、メッセージを発信したナビゲータ７２０やフォーマットエンジンを示すサブプログラムＩＤを１バイトで格納する。サブプログラムＩＤの詳細な内容は後述する。
【００８７】
Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１７２は、メッセージを受け取るサブプログラムを示すサブプログラムＩＤ（ＳＩＤ）を１バイトで格納する。フォーマットエンジンＩＤの詳細な内容は後述する。Ｍｅｓｓａｇｅ  ＩＤフィールド１７３は、メッセージの内容を表すメッセージＩＤを１バイトで格納する。メッセージＩＤの詳細な内容は後述する。Ｄａｔａ  Ｌｅｎｇｈフィールド１７４は、Ｄａｔａフィールド１７５に格納されるデータの長さを２バイトで格納する。Ｄａｔａフィールド１７５は、メッセージＩＤに対応する詳細データを格納する。格納するデータのフォーマットはメッセージＩＤに対応して規定される。
【００８８】
図１８は、図１７に示すＳｏｕｒｃｅ  ＩＤフィールド１７１およびＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド１７２に格納されるサブプログラムＩＤの表の一例を示す図である。図１８に示す表では、左側の列にサブプログラムが記載され、右側の列に対応するサブプログラムＩＤが記載されている。なお、左側の列にある「ＡＬＬ」は、全てのフォーマットエンジンを示す。ここでは、「ＡＬＬ」の他、ナビゲータ７２０、結合部７３０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０に対してサブプログラムＩＤが付されている。つまり、これらのサブプログラムがメッセージのやり取りを行うサブプログラムである。
【００８９】
図１９は、Ｍｅｓｓａｇｅ  ＩＤフィールド１７３に格納されるメッセージＩＤの表の一例を示す図である。図１９においては、左側の列にメッセージ内容が記載され、中央の列にメッセージＩＤ（ＭＩＤ）が記載され、右側の列にＤａｔａフィールド１７５に格納するデータのフォーマットＩＤが記載されている。以下、各メッセージの詳細について説明する。
【００９０】
図１９において、上から２番目の行は、フォーマットエンジンに対して、フォーマットエンジンの状態を通知するように要求するための「フォーマットエンジン状態要求」メッセージが記載されている。例えば、ナビゲータ７２０が各フォーマットエンジンの動作状態を知りたいときに使用する。このメッセージはデータフィールド１７５を使用しない。
【００９１】
図１９において、上から３番目の行は、「フォーマットエンジン状態要求」の応答を行うための「フォーマットエンジン状態応答」メッセージである。例えば、Ｊａｖａミドルウェア７４０がナビゲータ７２０から「フォーマットエンジン状態要求」を受け取ると、Ｊａｖａミドルウェア７４０は、この「フォーマットエンジン状態応答」メッセージを用いてフォーマットエンジンの状態を通知する。このメッセージは、データフィールド１７５にフォーマットエンジンの状態を格納する。図２０は、フォーマットエンジン状態応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。データフィールド１７５には、フォーマットエンジンの動作状態を示す動作状態ＩＤが１バイトで格納される。
【００９２】
図２１は、フォーマットエンジンの動作状態と動作状態ＩＤとの対応を示す表の一例を示す図である。図２１において、左側の列にフォーマットエンジンの動作状態が記載され、中央の列に動作状態の意味が記載され、右側の列に動作状態ＩＤが記載されている。ここでは、「実行中」、「一時停止中」、および「停止中」という３つの動作状態が規定されている。図２１において規定されいるこれらの動作状態は、全フォーマットエンジンに共通する共通状態である。つまり、メッセージに含まれる動作状態は、共通状態の表現で表されている。また、「実行中」という共通状態は、デジタルテレビ１００が有している極小リソースを使用していることを意味する。
【００９３】
図１９の説明に戻り、上から４番目の行は、フォーマットエンジンの状態が変化したことを、フォーマットエンジンがナビゲータ７２０や他のフォーマットエンジンに通知するための「フォーマットエンジン状態変化」メッセージである。このメッセージはデータフィールド１７５を使用しない。
【００９４】
また、上から５番目から７番目の行は、ナビゲータ７２０等が他のフォーマットエンジンに対して状態を「実行中」「停止中」「一時停止中」に変更するように指示を出すための「フォーマットエンジン実行」「フォーマットエンジン停止」「フォーマットエンジン一時停止」メッセージである。これらのメッセージはデータフィールド１７５を使用しない。
【００９５】
また、上から８番目の行は、フォーマットエンジンに対して、フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータの一覧を通知するように要求するための「アプリケーション・データ一覧要求」メッセージである。例えば、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションの一覧を、ナビゲータ７２０が知りたい場合に使用される。このメッセージはデータフィールド１７５を使用しない。
【００９６】
また、上から９番目の行は、「アプリケーション・データ一覧要求」の応答を行うための「アプリケーション・データ一覧応答」メッセージである。例えば、Ｊａｖａミドルウェア７４０がナビゲータ７２０から「アプリケーション・データ一覧要求」を受け取ると、Ｊａｖａミドルウェア７４０は、「アプリケーション・データ一覧応答」メッセージを用いて、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションとその状態との一覧を通知する。このメッセージはデータフィールド１７５にアプリケーション・データの一覧を格納する。
【００９７】
図２２は、アプリケーション・データ一覧応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。図２２においては、アプリケーション数（図２２では「アプリ数」と記載している）フィールド２２０１に、フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータの数が１バイトで格納される。
【００９８】
データフィールド１７５には、アプリケーション数フィールド２２０１に続いて、アプリケーション数フィールド２２０１に格納された数のアプリケーション情報フィールド２２０２が設けられる。
【００９９】
アプリケーション情報フィールド２２０２の先頭には、アプリケーションＩＤフィールド２２０３が設けられる。アプリケーションＩＤフィールド２２０３には、実行可能なアプリケーションあるいは表示可能なデータを識別するアプリケーションＩＤが１バイトで格納される。このアプリケーションＩＤは、フォーマットエンジンが割り当てる。
【０１００】
続いて、アプリケーション情報フィールド２２０２には、アプリケーション状態（図２２では「アプリ状態」と記載している）ＩＤフィールド２２０４が設けられる。アプリケーション状態ＩＤフィールド２２０４には、アプリケーションあるいはデータの状態を表すアプリケーション状態ＩＤを１バイトで格納する。なお、本構成例では、アプリケーションの状態とアプリケーション状態ＩＤとの対応は、図２１に示す対応、すなわち、フォーマットエンジンの動作状態と動作状態ＩＤとの対応と同じであるとする。
【０１０１】
続いて、アプリケーション情報フィールド２２０２には、アプリケーション名長さ（図２２では「アプリ名の長さ」と記載している）フィールド２２０５が設けられる。アプリケーション名長さフィールド２２０５には、アプリケーションあるいはデータの名前の長さが格納される。
【０１０２】
アプリケーション情報フィールド２２０２の末尾には、アプリケーション名（図２２では「アプリ名」と記載している）フィールド２２０６が設けられる。アプリケーション名フィールド２２０６には、アプリケーション名長さフィールド２２０５に格納されたデータにより指定される長さのアプリケーションの名前が格納される。
【０１０３】
図１９の説明に戻り、上から１０番目の行は、フォーマットエンジンが実行中のアプリケーションあるいは表示中のデータの状態が変化したことを、フォーマットエンジンがナビゲータ７２０や他のフォーマットエンジンに通知するための「アプリケーション・データ一覧変化」メッセージである。このメッセージはデータフィールド１７５を使用しない。
【０１０４】
また、上から１１番目から１３番目の行は、ナビゲータ７２０等が他のフォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータに対して状態を「実行中」「停止中」「一時停止中」に変更するように指示を出すための「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」メッセージである。これらのメッセージはデータフィールド１７５に状態を変化させる対象のアプリケーションあるいはデータを識別するためのアプリケーションＩＤを格納する。
【０１０５】
図２３は、「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」のメッセージにおけるデータフィールド１７５のフォーマットの一例を示す図である。データフィールド１７５には、アプリケーションあるいはデータを識別するためのアプリケーションＩＤ（図２３では、「アプリＩＤ」と記載している）が１バイトで格納される。アプリケーションＩＤは、「アプリケーション・データ一覧応答」メッセージでフォーマットエンジンが返す値を用いる。
【０１０６】
図１９の説明に戻り、上から１４番目の行は、ナビゲータ７２０や他のフォーマットエンジン間で、独自データの送受信時に使用する「プライベート」メッセージである。データフィールド１７５は、ナビゲータ７２０や他のフォーマットエンジン間で独自に規定したフォーマットに独自のデータを埋め込んで使用される。
【０１０７】
なお、本構成例では、フォーマットエンジンの動作状態の規定と、アプリケーション・データの動作状態の規定とが同じであるが、異なっていても実施可能である。また、本構成例で規定しているメッセージおよびメッセージのフォーマットは一例であり、これ以外のメッセージを含む、他のフォーマットを使用する、あるいは本構成例で示したメッセージの一部・全部を使用しない等してもよい。重要なポイントは、結合部７３０あるいは同等の構成要素が、ナビゲータ７２０や複数のフォーマットエンジン間で使用される、フォーマットエンジンの共通状態およびアプリケーション・データの共通状態を規定し、共通の通信手段を提供することにある。
【０１０８】
次に、ナビゲータ７２０の動作に対応するメッセージの具体例を説明する。まず、ナビゲータ７２０が図８に示すようなフォーマットエンジンの一覧を表示する際には、ナビゲータ７２０は、図２４〜図２６に示す３つの「フォーマットエンジン状態要求」メッセージを結合部７３０に渡す。図２４〜図２６は、「フォーマットエンジン状態要求」メッセージの具体例を示す図である。図２４に示すメッセージ２４００は、ナビゲータ７２０からＪａｖａミドルウェア７４０への「フォーマットエンジン状態要求」である。Ｓｏｕｒｃｅ  ＩＤフィールド２４０１にはナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド２４０２には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤとして「２」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド２４０３には、「フォーマットエンジン状態要求」を表す「１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド２４０４には、データの長さとして「０」が格納される。図２５に示すメッセージ２５００は、ナビゲータ７２０からＨＴＭＬブラウザ７５０への「フォーマットエンジン状態要求」である。メッセージ２４００とメッセージ２５００の違いは、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド２５０２に、ＨＴＭＬブラウザ７５０を表すＩＤ「３」を格納している（図１８参照）部分だけであり、他は同じである。図２６に示すメッセージ２６００は、ナビゲータ７２０からメーラー７６０への「フォーマットエンジン状態要求」である。メッセージ２４００とメッセージ２６００の違いは、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤ２６０２に、メーラー７６０を表すＩＤ「４」を格納している（図１８参照）部分だけであり、他は同じである。
【０１０９】
「フォーマットエンジン状態要求」メッセージが送信された後、ナビゲータ７２０は、結合部７３０から図２７〜図２９に示す３つの「フォーマットエンジン状態応答」メッセージを受け取る。図２７〜図２９は、「フォーマットエンジン状態応答」メッセージの具体例を示す図である。メッセージ２７００は、Ｊａｖａミドルウェア７４０からナビゲータ７２０への「フォーマットエンジン状態応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド２７０１には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤ「２」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド２７０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド２７０３には、「フォーマットエンジン状態応答」を表すメッセージＩＤとして「２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド２７０４にはデータの長さ「１」が格納される。データフィールド２７０５には、「停止中」を表す動作状態ＩＤとして「３」が格納される（図２１参照）。メッセージ２８００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「フォーマットエンジン状態応答」である。メッセージ２７００とメッセージ２８００の違いは、Ｓｏｕｒｃｅ  ＩＤフィールド２８０１に、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納されている部分だけであり、他は同じである。メッセージ２９００は、メーラー７６０からナビゲータ７２０への「フォーマットエンジン状態応答」である。メッセージ２７００とメッセージ２９００の違いは、Ｓｏｕｒｃｅ  ＩＤフィールド２９０１に、図１８を参照してメーラー７６０を表すサブプログラムＩＤとして「４」が格納されている部分だけであり、他は同じである。このように３つの「フォーマットエンジン状態要求」メッセージを結合部７３０に送り、３つの「フォーマットエンジン状態応答」メッセージを結合部７３０から受け取ることによって、ナビゲータ７２０は、図８に示すフォーマットエンジン一覧を表示することができる。
【０１１０】
次に、ナビゲータ７２０が図１５に示すようなＨＴＭＬブラウザ７５０が表示可能なデータの一覧を表示する場合について説明する。この場合、ナビゲータ７２０は、図３０に示す「アプリケーション・データ一覧要求」メッセージを結合部７３０に渡す。図３０は、「アプリケーション・データ一覧要求」メッセージの具体例を示す図である。図３０に示すメッセージ３０００は、ナビゲータ７２０からＨＴＭＬブラウザ７５０への「アプリケーション・データ一覧要求」である。Ｓｏｕｒｃｅ  ＩＤフィールド３００１には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３００２には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３００３には、「アプリケーション・データ一覧要求」を表すメッセージＩＤとして「１１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３００４にはデータの長さを示す「０」が格納される。
【０１１１】
「アプリケーション・データ一覧要求」メッセージを送信した後、ナビゲータ７２０は、結合部７３０から図３１に示す「アプリケーション・データ一覧応答」メッセージを受け取る。図３１は、「アプリケーション・データ一覧応答」メッセージの具体例を示す図である。図３１に示すメッセージ３１００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「アプリケーション・データ一覧応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド３１０１には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３１０３には、「アプリケーション・データ取得応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３１０４には、データの長さを示す「２７」が格納される。アプリケーション数フィールド３１１０には、ＨＴＭＬブラウザ７５０が表示可能なデータの数を示す「２」が格納される。
【０１１２】
また、図３１において、アプリケーション数フィールド３１０５には、１つ目のデータに対するアプリケーション情報（図３１には、「アプリ情報」と記載している）フィールド３１１１と、２つ目のデータに対するアプリケーション情報（図３１には、「アプリ情報」と記載している）フィールド３１１２とが含まれている。アプリケーションＩＤフィールド３１２１には、１つ目のデータを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション名フィールド３１２４には、データの名前を示す「天気予報」が格納されている。ここで「天気予報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、４文字×２バイト＝８バイトとなっている。アプリケーションＩＤフィールド３１２５には２つ目のデータを表すアプリケーションＩＤとして「２」が格納されている。アプリケーション状態ＩＤフィールド３１２６には、「実行中」を表すアプリケーション状態ＩＤとして「１」が格納されている。アプリケーション名長さフィールド３１２７には、アプリケーション名の長さを示す「１２」が格納される。アプリケーション名フィールド３１２８には、データの名前を示す「レジャー情報」が格納されている。ここで「レジャー情報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、６文字×２バイト＝１２バイトとなっている。以上で、メッセージフォーマットについての説明を終了する。
【０１１３】
再び図７の説明に戻り、通信部７３１は、ナビゲータ７２０またはフォーマットエンジンからメッセージを受け取ると、メッセージに含まれているＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドを調べ、対応するフォーマットエンジンあるいはナビゲータ７２０に当該メッセージを配送する。例えば、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに「０」が格納されている場合、通信部７３１は、全てのフォーマットエンジンおよびナビゲータ７２０にメッセージを送信する（図１８参照）。従って、ナビゲータ７２０は、全てのフォーマットエンジンを終了させたい場合、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドが「０」であり、メッセージＩＤが「５」であるメッセージを通信部７３１へ送ればよい。
【０１１４】
状態管理部７３２は、フォーマットエンジンの動作状態、およびフォーマットエンジンが実行可能なアプリケーションおよび表示可能なデータの動作状態を保持する。具体的には、状態管理部７３２は、それらの情報を２次記憶部１０８あるいは１次記憶部１０９に記憶する。
【０１１５】
図３２〜図３４は、状態管理部７３２が保持している情報の一例を示す図である。図３２は、フォーマットエンジンに関する情報を表形式で表した例である。図３２において、最も左側の列は、各フォーマットエンジンを識別するためのフォーマットエンジンＩＤである。ここでは、各フォーマットエンジンのフォーマットエンジンＩＤは、図１８で規定されたサブプログラムＩＤと同じであるとする。左から２番目の列は、各フォーマットエンジンの名前である。左から３番目の列は、各フォーマットエンジンの動作状態を表す動作状態ＩＤである。図３２に示す表において、動作状態ＩＤは、図２１において規定される値によって表される。最も右側の列は、各フォーマットエンジンが実行可能なアプリケーションあるいは表示可能なデータに関する情報の格納位置を示すポインターである。実行可能なアプリケーションあるいは表示可能なデータを持たないフォーマットエンジンに関しては、当該列は「ＮＵＬＬ」と記述される。
【０１１６】
また、図３２に示す表において上から２番目の行には、Ｊａｖａミドルウェア７４０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「２」、名前が「Ｊａｖａミミドルウェア」、動作状態ＩＤが、「停止中」を意味する「３」、実行可能なアプリケーションに関する情報に対するポインターが１６進数表記で「０ｘ５６７８」と記述されている。上から３番目の行には、ＨＴＭＬブラウザ７５０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「３」、名前が「ＨＴＭＬブラウザ」、動作状態ＩＤが、「停止中」を意味する「３」、表示可能なデータに関する情報に対するポインターが１６進数表記で「０ｘ７１６２」と記述されている。上から４番目の行には、メーラー７６０の情報が記述されている。すなわち、フォーマットエンジンＩＤが「４」、名前が「メーラー」、動作状態ＩＤが、「停止中」を意味する「３」と記述されている。また、アプリケーション・データに関する情報はないので、ポインターが「ＮＵＬＬ」と記述されている。
【０１１７】
図３３は、Ｊａｖａミドルウェア７４０が実行可能なアプリケーションに関する情報を表形式で表した例を示す図である。この情報は、１次記憶部１０９中の格納位置０ｘ５６７８から格納されている。図３３において左側の列には、各アプリケーションに割り当てられたアプリケーションＩＤが記述される。中央の列には、アプリケーションの名前が記述される。右側の列には、アプリケーション状態ＩＤが記述される。上から２番目の行には、アプリケーションＩＤが「１」、名前が「ＥＰＧ」、アプリケーション状態ＩＤが、「停止中」を表す「３」と記述されている。上から３番目の行には、アプリケーションＩＤが「２」、名前が「トランプゲーム」、アプリケーション状態ＩＤが、「停止中」を表す「３」と記述されている。
【０１１８】
図３４は、ＨＴＭＬブラウザ７５０が実行可能なデータに関する情報を表形式で表した例を示す図である。この情報は、１次記憶部１０９中の格納位置０ｘ７１６２から格納されている。図３４において左側の列には、各データに割り当てられたデータＩＤが記述されている。中央の列には、データの名前が記述されている。右側の列には、データの状態を表すアプリケーション状態ＩＤが記述されている。上から２番目の行には、アプリケーションＩＤが「１」、名前が「天気予報」、アプリケーション状態ＩＤが、「実行中」を表す「１」と記述されている。上から３番目の行には、アプリケーションＩＤが「２」、名前が「レジャー情報」、アプリケーション状態ＩＤが、「実行中」を表す「１」と記述されている。
【０１１９】
再び図７の説明に戻る。上述したように、通信部７３１は、メッセージに含まれるＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに格納されたデータに従ってメッセージを配送する。ここで、「フォーマットエンジン状態要求」メッセージおよび「アプリケーション・データ一覧要求」メッセージに関しては、通信部７３１は、Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドを無視して、状態管理部７３２に配送してもよい。状態管理部７３２は、各フォーマットエンジンの状態を保持しているので、各フォーマットエンジンに代わって「フォーマットエンジン状態要求」メッセージ、「フォーマットエンジン状態応答」メッセージ、あるいは「アプリケーション・データ一覧応答」メッセージを生成することができる。状態管理部７３２がこれらのメッセージを生成することによって、プロセス間通信やスレッド間通信を省略することができるので、短時間での応答を実現することができる。
【０１２０】
状態管理部７３２は、常に最新のフォーマットエンジンの動作状態を保持する。従って、状態管理部７３２は、必要に応じて各フォーマットエンジンから情報を取得する。すなわち、まず、デジタルテレビ１００に電源が投入されると、状態管理部７３２は、各フォーマットエンジンに対して「フォーマットエンジン状態要求」メッセージを送る。そして、状態管理部７３２は、各フォーマットエンジンから「フォーマットエンジン状態応答」メッセージを受け取り、受け取ったメッセージに基づいて各フォーマットエンジンの動作状態を１次記憶部１０９に記憶する。また、状態管理部７３２は、各フォーマットエンジンに対して「アプリケーション・データ一覧要求」メッセージを送る。そして、状態管理部７３２は、各フォーマットエンジンから「アプリケーション・データ一覧応答」メッセージを受け取り、受け取ったメッセージに基づいて各アプリケーションおよび各データのアプリケーション状態を１次記憶部１０９に記憶する。
【０１２１】
さらに、状態管理部７３２は、フォーマットエンジンから「フォーマットエンジン状態変化」メッセージを受け取ると、当該フォーマットエンジンに対して「フォーマットエンジン状態要求」メッセージを送る。そして、状態管理部７３２は、メッセージを送ったフォーマットエンジンから「フォーマットエンジン状態応答」メッセージを受け取り、受け取ったメッセージに基づいて各フォーマットエンジンの動作状態を１次記憶部１０９に記憶する。
【０１２２】
次に、図３５〜図３８を用いて、メーラー７６０の動作状態が変化する場合におけるメッセージのやり取りを説明する。図３５は、メーラー７６０が送信する「フォーマットエンジン状態変化」メッセージの一例を示す図である。図３５に示すメッセージ３５００は、メーラー７６０から全フォーマットエンジンへの「フォーマットエンジン状態変化」メッセージの一例である。メッセージ３５００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３５０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３５０２には、全部を表すサブプログラムＩＤとして「０」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３５０３には、動作状態ＩＤとして「フォーマットエンジン状態変化」を表す「３」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３５０４には、データの長さを表す「０」が格納される。
【０１２３】
状態管理部７３２は、図３５に示すメッセージ３５００を受け取ると、図３６に示されるメッセージ３６００をメーラー７６０に送る。図３６は、状態管理部７３２が送信するメッセージの一例を示す図である。図３６に示すメッセージ３６００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３６０１には、結合部７３０を表すサブプログラムＩＤとして「５」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３６０２には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３６０３には、メッセージＩＤとして「フォーマットエンジン状態要求」を表す「１」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３６０４には、データの長さを表す「０」が格納される。
【０１２４】
メーラー７６０は、図３６に示すメッセージ３６００を受け取ると、図３７で示されるメッセージ３７００を結合部７３０の状態管理部７３２に送る。図３７は、メーラー７６０が送信するメッセージの一例を示す図である。図３７に示すメッセージ３７００においては、Ｓｏｕｒｃｅ  ＩＤフィールド３７０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド３７０２には、結合部７３０を表すサブプログラムＩＤとして「５」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド３７０３には、メッセージＩＤとして、「フォーマットエンジン状態応答」を表す「２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド３７０４には、データの長さを表す「１」が格納される。データフィールド３７０５には、動作状態ＩＤとして「実行中」を表す「１」が格納される（図２１参照）。
【０１２５】
図３７に示すメッセージ３７００が結合部７３０の状態管理部７３２へ送信された結果、状態管理部７３２は、メーラー７６０の状態が「実行中」に変化したことを知ることができる。このとき、メッセージ３７００の受信前の状態が図３２に示す状態であったとすると、状態管理部７３２は、図３８に示すように、１次記憶部１０９に記憶している情報を更新する。図３８は、図３２の変化後の状態を示す図である。図３８では、メーラー７６０の動作状態ＩＤが「１」になっている。
【０１２６】
また、状態管理部７３２は、フォーマットエンジンから「アプリケーション・データ一覧変化」メッセージを受け取ると、「フォーマットエンジン状態変化」メッセージの場合と同様、最新の状態を取り直す。すなわち、状態管理部７３２は、メッセージを送ってきたフォーマットエンジンに対して、「アプリケーション・データ一覧要求」メッセージを送る。そして、状態管理部７３２は、当該フォーマットエンジンから「アプリケーション・データ一覧応答」メッセージを受け取り、受け取ったメッセージに基づいて各アプリケーションおよび各データのアプリケーション状態を１次記憶部１０９に記憶する。
【０１２７】
以上のようにして、状態管理部７３２は、各フォーマットエンジン、フォーマットエンジンが実行するアプリケーション、およびフォーマットエンジンが表示するデータの最新の情報を保持することができる。
【０１２８】
次に、図３９〜図４４を用いて、リソース管理部７３３について説明する。なお、リソース管理部７３３は、上述した第２の動作例の動作を行う際に必要となる構成であって、第１の動作例の動作を行う場合には不要である。
【０１２９】
リソース管理部７３３は、複数のフォーマットエンジン間で発生したリソースの競合を解決するための情報を提供する。図３９は、リソース管理部７３３の内部構成を示すブロック図である。図３９において、リソース管理部７３３は、プロセス記憶部３９０１と、優先度記憶部３９０２と、最新起動記憶部３９０３と、リソースＩＤ記憶部３９０４と、フォーマットエンジン特定部３９０５と、優先度情報提供部３９０６と、リソース剥奪通知部３９０７とを備えている。
【０１３０】
プロセス記憶部３９０１は、２次記憶部１０８あるいは１次記憶部１０９によって実現され、各フォーマットエンジンを実行しているプロセスあるいはスレッドの情報を保持する。ここで、各フォーマットエンジンはプロセス上で実行されているとする。
【０１３１】
図４０は、プロセス記憶部３９０１において記憶されている情報の一例を示す図である。図４０においては、プロセス記憶部３９０１は、各フォーマットエンジンを実行しているプロセスＩＤを表形式で記憶している。図４０において、左側の列には、フォーマットエンジンＩＤ（ＦＩＤ）が記述されている。右側の列には、各フォーマットエンジンを実行しているプロセスを識別するためのプロセスＩＤが記述されている。プロセスＩＤは、ＯＳ７１０のカーネル７１１によって生成されるプロセスのＩＤである。リソース管理部７３３は、カーネル７１１からプロセスＩＤを受け取ってプロセス記憶部３９０１に記憶する。一方、上から２番目の行には、Ｊａｖａミドルウェア７４０のフォーマットエンジンＩＤである「２」（図１８参照）と、Ｊａｖａミドルウェア７４０を実行しているプロセスのプロセスＩＤである「１００」とが記述されている。上から３番目の行には、ＨＴＭＬブラウザ７５０のフォーマットエンジンＩＤである「３」（図１８参照）と、ＨＴＭＬブラウザ７５０を実行しているプロセスのプロセスＩＤである「１１０」とが記述されている。上から４番目の行には、メーラー７６０のフォーマットエンジンＩＤである「４」（図１８参照）と、メーラー７６０を実行しているプロセスのプロセスＩＤである「１２０」とが記述されている。
【０１３２】
図３９の説明に戻り、優先度記憶部３９０２は、２次記憶部１０８、１次記憶部１０９あるいはＲＯＭ１１０によって実現される。優先度記憶部３９０２は、各フォーマットエンジンの優先度を記憶する。
【０１３３】
図４１は、優先度記憶部３９０２に記憶されている情報の一例を示す図である。図４１において、優先度記憶部３９０２は、各フォーマットエンジンの優先度を表形式で記憶している。図４１において、左側の列には、フォーマットエンジンＩＤ（ＦＩＤ）が記述されている。右側の列には、各フォーマットエンジンの優先度が記述されている。ここで、優先度は値が大きいほど優先度が高いとする。また、上から２番目の行には、ＪａｖａミドルウェアのフォーマットエンジンＩＤである「２」と、それに対応する優先度である「２」とが記述されている。上から３番目の行には、ＨＴＭＬブラウザのフォーマットエンジンＩＤである「３」と、それに対応する優先度「１」とが記述されている。上から４番目の行には、メーラーのフォーマットエンジンＩＤである「４」と、それに対応する優先度「４」とが記述されている。
【０１３４】
図３９の説明に戻り、最新起動記憶部３９０３は、２次記憶部１０８あるいは１次記憶部１０９によって実現される。最新起動記憶部３９０３は、ナビゲータ７２０から送られてきた「フォーマットエンジン実行」メッセージ、または「アプリケーション・データ実行」メッセージに含まれているＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドに記述されたフォーマットエンジンＩＤを記憶する。つまり、最新起動記憶部３９０３は、最新起動情報を記憶する。最新起動情報とは、ユーザが最後に実行を要求したフォーマットエンジンを示す情報である。
【０１３５】
図４２は、最新起動記憶部３９０３が記憶している情報の一例を示す図である。図４２では、最新起動記憶部３９０３は、メーラー７６０のフォーマットエンジンＩＤである「４」を格納している。図４２に示す状態において、ナビゲータ７２０が、結合部７３０を通してＨＴＭＬブラウザ７５０に「フォーマットエンジン実行」メッセージ、あるいはアプリケーション・データ実行」メッセージを送った場合を考える。この場合、リソース管理部７３３は、最新起動記憶部３９０３に記憶される情報を、ＨＴＭＬブラウザ７５０を表すフォーマットエンジンＩＤである「３」に更新する。
【０１３６】
図３９の説明に戻り、リソースＩＤ記憶部３９０４は、２次記憶部１０８あるいはＲＯＭ１１０によって実現される。リソースＩＤ記憶部３９０４は、リソース管理部７３３が管理対象とするリソースを識別するためのリソースＩＤ（ＲＩＤ）を記憶する。
【０１３７】
図４３は、リソースＩＤ記憶部３９０４が記憶している情報の一例を示す図である。図４３においては、リソースＩＤ記憶部３９０４は、リソースＩＤを表形式で記憶する。図４３において、左側の列にはリソースＩＤが記述されている。右側の列には、対応するリソースの名前が記述されている。図４３では、管理対象のリソースとして、チューナ１０１、ＴＳデコーダ１０３、オーディオデコーダ１０４、ビデオデコーダ１０６、ネットワークインタ―フェース１１２が規定されている。これらのリソースに対してリソースＩＤが割り当てられている。図４４は、リソースＩＤの定義をプログラミング言語であるＣ言語で記述した例を示す図である。
【０１３８】
図３９の説明に戻り、フォーマットエンジン特定部３９０５は、リソースを要求しているフォーマットエンジンを特定する。各フォーマットエンジンは、ＯＳ７１０のライブラリ７１２が提供する機能を利用する。例えば、チューナ１０１を制御するチューナＬｉｂ７１２１を呼び出し、特定の周波数帯にチューニングを行う。これを実現するために、フォーマットエンジンは、チューナＬｉｂ７１２１が用意する関数を呼び出す。フォーマットエンジンから要求があると、すなわち、フォーマットエンジンが関数の呼び出しを行うと、チューナＬｉｂ７１２１は、どのフォーマットエンジンが当該関数を呼び出しているのかをフォーマットエンジン特定部３９０５に問い合わせる。この問い合わせに応じて、フォーマットエンジン特定部３９０５は、関数を呼び出しているプロセスを特定する。そして、フォーマットエンジン特定部３９０５は、特定したプロセスのプロセスＩＤ、およびプロセス記憶部３９０１が記憶しているフォーマットエンジンＩＤとプロセスＩＤとの組を参照することによって、関数を呼び出したフォーマットエンジンを特定する。
【０１３９】
優先度情報提供部３９０６は、優先度記憶部３９０２が記憶しているフォーマットエンジンの優先度と、最新起動記憶部３９０３が記憶している、ユーザが最後に起動したフォーマットエンジンの情報とをライブラリ７１２に提供する。ライブラリ７１２は、フォーマットエンジン特定部３９０５および優先度情報提供部３９０６を利用することによって、どのフォーマットエンジンにリソースを提供するかを決定することができる。以下、具体的に説明する。
【０１４０】
例えば、チューナＬｉｂ７１２１は、Ｊａｖａミドルウェア７４０から呼び出され、チューニングを行っているとする。なお、チューナＬｉｂ７１２１は、フォーマットエンジン特定部３９０５を利用することによって、Ｊａｖａミドルウェア７４０が現在チューナ１０１を利用していることを知っている。この状態において、メーラー７６０がチューナＬｉｂ７１２１を呼び出し、他の周波数帯にチューニングしようとする場合を考える。チューナＬｉｂ７１２１は、フォーマットエンジン特定部３９０５を利用することによって、メーラー７６０がチューナ１０１の機能を利用していることを知る。次に、チューナＬｉｂ７１２１は、優先度情報提供部３９０６から最後に起動したフォーマットエンジンの情報を取得する。そして、チューナＬｉｂ７１２１は、最後に起動したフォーマットエンジンがメーラー７６０であれば、メーラー７６０にチューナ１０１の利用を許可する。一方、最後に起動したフォーマットエンジンがＪａｖａミドルウェア７４０であれば、メーラー７６０に対してチューナ１０１の利用を拒否する。最後に起動したフォーマットエンジンがメーラー７６０でもＪａｖａミドルウェア７４０でもない場合は、優先度情報提供部３９０６からメーラー７６０およびＪａｖａミドルウェア７４０の優先度を取得する。メーラー７６０の優先度がＪａｖａミドルウェア７４０の優先度よりも高い場合、チューナＬｉｂ７１２１は、メーラー７６０にチューナ１０１の使用を許す。一方、メーラー７６０の優先度がＪａｖａミドルウェア７４０の優先度よりも低い場合、メーラー７６０に対して、チューナ１０１の使用を拒否する。以上のようにして、ライブラリ７１２は、どのフォーマットエンジンにリソースを提供するかを決定することができる。
【０１４１】
なお、ライブラリ７１２が、最後に起動したフォーマットエンジンの情報や優先度情報をどのように用いるかは自由であり、ここに紹介したのはその一例である。どのフォーマットエンジンに対してリソースの利用を許可するかを決定するためのルールは、どのようなものであってもよい。例えば、ライブラリ７１２は、優先度情報のみを用いてリソースの利用を許可するフォーマットエンジンを決定してもよい。また、ライブラリ７１２は、先に使用しているフォーマットエンジンに対して利用を許可してもよい。逆に、ライブラリ７１２は、後から呼び出したフォーマットエンジンに対して利用を許可してもよい。
【０１４２】
図３９において、リソース剥奪通知部３９０７は、リソースの利用が許可されなかったフォーマットエンジンに対して、リソースが剥奪されたことを通知する。例えば、Ｊａｖａミドルウェア７４０がチューナＬｉｂ７１２１を呼び出し、チューナ１０１を使用しているとき、メーラー７６０がチューナＬｉｂ７１２１を呼び出し、チューナ１０１の使用を試みた場合を考える。ここで、もし、チューナＬｉｂ７１２１がメーラー７６０にチューナ１０１の使用を許すと、Ｊａｖａミドルウェア７４０が希望している周波数帯とは異なる周波数帯にチューニングされる。従って、Ｊａｖａミドルウェア７４０上で実行されているアプリケーションは正しい動作を続けることができなくなるおそれがある。これを防ぐために、チューナＬｉｂ７１２１は、チューナリソースが剥奪されたことをＪａｖａミドルウェア７４０に通知するように、リソース剥奪通知部３９０７に依頼する。この依頼の際には、リソースが剥奪されたことを通知すべきフォーマットエンジンのフォーマットエンジンＩＤとリソースＩＤとがリソース剥奪通知部３９０７に渡される。なお、ライブラリ７１２は、フォーマットエンジンＩＤをフォーマットエンジン特定部３９０５から取得することによって知ることができる。また、ライブラリ７１２は、リソースＩＤ記憶部３９０４を参照することによってリソースＩＤを予め知っている。リソース剥奪通知部３９０７は、フォーマットエンジンＩＤおよびリソースＩＤを受け取ると、フォーマットエンジンＩＤにより示されるフォーマットエンジンにリソースが剥奪されたことを通知する。なお、通知を受けたフォーマットエンジンの動作は、各フォーマットエンジンに依存する。動作続行が困難なフォーマットエンジンであれば、実行中から停止中あるいは一時停止中に動作状態を変化させるようにしてもよい。以上でリソース管理部７３３の説明を終了する。
【０１４３】
次に、図４５〜図７１を用いて、各フォーマットエンジンの詳細を説明する。まず、図４５〜図５１を用いて、Ｊａｖａミドルウェア７４０について説明する。Ｊａｖａミドルウェア７４０は、Ｊａｖａアプリケーション（以下、単に「Ｊａｖａアプリケーション」と記載する。）を実行するフォーマットエンジンである。本構成例においては具体的な例として、ＤＶＢ−ＭＨＰ１．０規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）を取り上げるが、例えばアプレットビューワ等、他の仕様に従って動作するものでも実施可能である。本構成例では、Ｊａｖａミドルウェア７４０の詳細な動作にはＤＶＢ−ＭＨＰ１．０規格の内容が含まれる。従って、ここでは、概略のみを記述する。
【０１４４】
図４５は、Ｊａｖａミドルウェア７４０の構成を示すブロック図である。Ｊａｖａミドルウェア７４０は、Ｊａｖａ（登録商標）バーチャルマシン（ＶＭ）（以下、「ＪａｖａＶＭ」と記載する）４５０１と、クラスライブラリ４５０２と、アプリケーションマネージャ４５０３とを備えている。
【０１４５】
ＪａｖａＶＭ４５０１は、Ｊａｖａ（登録商標）（ＴＭ）言語（以下、単に「Ｊａｖａ言語」と記載する。）で記述されたアプリケーションを逐次解析し実行するＪａｖａ（登録商標）バーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウェアに依存しない中間コードにコンパイルされる。Ｊａｖａ（登録商標）バーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａ（登録商標）バーチャルマシンは、バイトコードをＣＰＵ１１３が理解可能な実行形式に翻訳してから、ＣＰＵ１１３に引き渡し、実行することも行う。クラスライブラリ４５０２およびアプリケーションマネージャ４５０３の一部または全部もＪａｖａ言語で記述されており、ＪａｖａＶＭ４５０１によって実行される。本構成例では、ＯＳ７１０のカーネル７１１は、最初に実行するＪａｖａアプリケーションとしてアプリケーションマネージャ４５０３を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。従って、ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１―Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【０１４６】
クラスライブラリ４５０２は、ＲＯＭ１１０に格納されている複数のＪａｖａ（登録商標）クラスライブラリの集合である。その多くは、ＯＳ７１０のライブラリ７１２が提供する機能に対応するＪａｖａアプリケーションが呼び出し可能なＪａｖａ（登録商標）  ＡＰＩを提供する。この結果、Ｊａｖａアプリケーションはデジタルテレビ１００が有する機能を利用することができる。例えば、ＤＶＢ−ＭＨＰ１．０規格では、チューナ１０１を使用するためのＡＰＩとしてｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｔｕｎｉｎｇパッケージを規定し、Ｊａｖａアプリケーションがチューナ１０１を制御できるようにしている。
【０１４７】
アプリケーションマネージャ４５０３は、放送波中に多重化されているＪａｖａアプリケーションをダウンロードし、実行する。ＭＨＰ１．０規格によれば、ＡＩＴと呼ばれるＪａｖａアプリケーションを定義する表が放送波中に多重化されて伝送される。アプリケーションマネージャ４５０３は、このＡＩＴを最初にダウンロードする。ＡＩＴにはアプリケーションをダウンロードするための情報やアプリケーションの名前、アプリケーションの制御情報などが含まれる。
【０１４８】
図４６は、ＡＩＴの主要部を表した模式図である。図４６において最も左側の列には、ＪａｖａアプリケーションＩＤが記述されている。左から２番目の列には、Ｊａｖａアプリケーションの制御情報が記述されている。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」等がある。「ａｕｔｏｓｔａｒｔ」は、Ｊａｖａミドルウェア７４０がそのＪａｖａアプリケーションを即時にかつ自動的に実行することを意味する。「ｐｒｅｓｅｎｔ」は、自動実行しないことを意味する。「ｋｉｌｌ」は、Ｊａｖａアプリケーションを停止することを意味する。左から３番目の列は、Ｊａｖａアプリケーションのアプリケーション名が記述されている。最も右側の列には、Ｊａｖａアプリケーションの優先度が記述されている。Ｊａｖａアプリケーション間でリソースの競合が発生した場合、優先度の高いＪａｖａアプリケーションにリソースが優先的に割り当てられる。ここで、優先度の値が大きいほど優先度が高いこととする。
【０１４９】
図４６において上から２番目および３番目の行には、Ｊａｖａアプリケーションの情報の組が記述される。上から２番目の行において定義されるＪａｖａアプリケーションについては、ＪａｖａアプリケーションＩＤが「１」であり、制御情報が「ａｕｔｏｓｔａｒｔ」であり、アプリケーション名が「ＥＰＧ」であり、優先度が「６４」である。上から３番目の行において定義されるＪａｖａアプリケーションについては、ＪａｖａアプリケーションＩＤが「２」であり、制御情報が「ｐｒｅｓｅｎｔ」であり、アプリケーション名が「トランプゲーム」であり、優先度「３２」である。
【０１５０】
アプリケーションマネージャ４５０３は、ＡＩＴを受け取ると、アプリケーション名「ＥＰＧ」のＪａｖａアプリケーションをダウンロードし実行する。ここで、ＤＶＢ−ＭＨＰ１．０規格が規定するＪａｖａアプリケーションは、「Ｌｏａｄｅｄ」、「Ｐａｕｓｅｄ」、「Ａｃｔｉｖｅ」、および「Ｄｅｓｔｒｏｙｅｄ」という４つの動作状態を有している。
【０１５１】
図４７は、Ｊａｖａアプリケーションの４つの動作状態および動作状態間の遷移を表す状態遷移図である。アプリケーションマネージャ４５０３がＪａｖａアプリケーションをダウンロードし、当該Ｊａｖａアプリケーションが１次記憶部１０９に格納されると、当該Ｊａｖａアプリケーションの動作状態は「Ｌｏａｄｅｄ」になる。この動作状態から他の動作状態への遷移は、ダウンロードしたＪａｖａアプリケーションが実装している「ｉｎｉｔＸｌｅｔ」、「ｓｔａｒｔＸｌｅｔ」、「ｐａｕｓｅＸｌｅｔ」、および「ｄｅｓｔｒｏｙＸｌｅｔ」というメソッドをアプリケーションマネージャ４５０３が呼び出すことにより実現する。
【０１５２】
「Ｌｏａｄｅｄ」の動作状態でアプリケーションマネージャ４５０３が「ｉｎｉｔＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は、「Ｐａｕｓｅｄ」に遷移する。「Ｐａｕｓｅｄ」の動作状態でアプリケーションマネージャ４５０３が「ｓｔａｒｔＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は「Ａｃｔｉｖｅ」に遷移する。「Ａｃｔｉｖｅ」の動作状態でアプリケーションマネージャ４５０３が「ｐａｕｓｅＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は、「Ｐａｕｓｅｄ」に遷移する。どの動作状態の場合においても、アプリケーションマネージャ４５０３が「ｄｅｓｔｒｏｙＸｌｅｔ」メソッドを呼び出すと、Ｊａｖａアプリケーションの動作状態は「Ｄｅｓｔｒｏｙｅｄ」に遷移する。
【０１５３】
アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションの状態遷移を、（１）放送波中のＡＩＴの制御情報、（２）Ｊａｖａアプリケーションの指示、および（３）ナビゲータ７２０が結合部７３０を通して送る指示、の３通りの指示に従って行う。
【０１５４】
ＡＩＴの制御情報が「ａｕｔｏｓｔａｒｔ」の場合、アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションをダウンロードした後、「ｉｎｉｔＸｌｅｔ」メソッド、「ｓｔａｒｔＸｌｅｔ」メソッドを呼び出し、「Ａｃｔｉｖｅ」状態に遷移させる。ＡＩＴは、時間と共に変化する。例えば、ＡＩＴが図４６から図４８に変化したとする。図４８では、「ＥＰＧ」という名前のアプリケーションの制御情報が「ａｕｔｏｓｔａｒｔ」から「ｋｉｌｌ」に変更されている。このとき、アプリケーションマネージャ４５０３は、Ｊａｖａアプリケーションの「ｄｅｓｔｒｏｙＸｌｅｔ」メソッドを呼び出し、「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させる。
【０１５５】
一方、Ｊａｖａアプリケーションは、自分自身の状態や他のＪａｖａアプリケーションの状態を遷移させることができる。ＤＶＢ−ＭＨＰ１．０規格では、Ｊａｖａアプリケーションが自身の状態を遷移させたいときは、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＤｅｓｔｒｏｙｅｄ」、「ｎｏｔｉｆｙＰａｕｓｅｄ」、および「ｒｅｓｕｍｅＲｅｑｕｅｓｔ」メソッドのいずれかを呼び出す。「Ｄｅｓｔｒｏｙｅｄ」状態に遷移するには、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＤｅｓｔｒｏｙｅｄ」を呼び出す。「Ａｃｔｉｖｅ」状態に遷移させるには、Ｊａｖａアプリケーションは、「ｒｅｓｕｍｅＲｅｑｕｅｓｔ」メソッドを呼び出す。「Ｐａｕｓｅｄ」状態に遷移するには、Ｊａｖａアプリケーションは、「ｎｏｔｉｆｙＰａｕｓｅｄ」を呼び出す。他のＪａｖａアプリケーションの状態を遷移させる場合、Ｊａｖａアプリケーションは、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｔｉｏｎパッケージが規定するメソッドを利用する。すなわち、まず、他のＪａｖａアプリケーションをアプリケーションＩＤによって指定した後、Ｊａｖａアプリケーションは、ｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｔｉｏｎパッケージが規定するメソッドを呼び出し、指定したＪａｖａアプリケーションの状態を遷移させる。ここでは詳細は省略する。
【０１５６】
最後にナビゲータ７２０からの指示によってＪａｖａアプリケーションの状態を遷移する方法を説明する。ナビゲータ７２０は、共通状態、すなわち、結合部７３０が規定しているフォーマットエンジンの動作状態またはフォーマットエンジンが実行可能なアプリケーションの動作状態に基づいて指示を出す。この共通状態は、個別状態、すなわち、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３が実行するＪａｖａアプリケーションの動作状態とは異なっている。この共通状態と個別状態との間のギャップを第１の変換部７４１が埋めるのである。第１の変換部７４１は、ナビゲータ７２０からの指示を、Ｊａｖａミドルウェア７４０が取り扱う動作状態に変換する。その結果、アプリケーションマネージャ４５０３は、ＡＩＴの制御情報やＪａｖａアプリケーションからの指示と同等の指示を受け、Ｊａｖａアプリケーションの動作状態を遷移させることができる。
【０１５７】
第１の変換部７４１は、結合部７３０からのメッセージを変換してＪａｖａミドルウェア７４０に伝え、また、Ｊａｖａミドルウェア７４０の情報を変換して結合部７３０に伝えることにより、Ｊａｖａミドルウェア７４０の動作を結合部７３０が規定する状態に適合させる。ここまで、様々なメッセージを、結合部７３０を通してＪａｖａミドルウェア７４０に配送すると記述してきたが、正確には、これらのメッセージは、Ｊａｖａミドルウェア７４０ではなく第１の変換部７４１に送信される。第１の変換部７４１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの状態に基づいてＪａｖａミドルウェア７４０の状態を決定する。そして、第１の変換部７４１は、「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０へ送る。
【０１５８】
図４９は、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態と、Ｊａｖａミドルウェア７４０の動作状態との対応を示す変換表の一例を示す図である。図４９において左側の列には、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態が記述されている。右側の列には、対応するＪａｖａミドルウェア７４０の動作状態が記述されている。ここで、Ｊａｖａミドルウェア７４０の状態は、結合部７３０が規定した状態、すなわち共通状態である。具体的には、図２１で示した「実行中」、「一時停止中」、および「停止中」という３つの動作状態である。上から２番目から４番目の行には、これら３つの動作状態に対応する、Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態が規定されている。
【０１５９】
まず、上から２番目の行には、全てのＪａｖａアプリケーションの中に１つでも「Ａｃｔｉｖｅ」という動作状態のＪａｖａアプリケーションがあることに対しては、Ｊａｖａミドルウェア７４０の動作状態として「実行中」が対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションは極小リソースを使用している可能性が高いため、このような対応関係を規定したものである。
【０１６０】
次に、上から３番目の行には、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがなく、かつ、全Ｊａｖａアプリケーションの中で１つでも「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがあることに対して、Ｊａｖａミドルウェア７４０の動作状態として「一時停止中」が対応付けられている。ＤＶＢ−ＭＨＰ１．０規格によれば、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションは、必要最小限のリソース以外は解放すべきと記述されている。よって、このような対応関係を規定した。
【０１６１】
次に、上から４番目の行には、上から２番目および３番目の行に示す場合以外の場合に対して、「停止中」が対応付けられている。上から２番目および３番目の行に示す場合以外の場合とは、具体的には、全てのＪａｖａアプリケーションが、「Ｌｏａｄｅｄ」あるいは「Ｄｅｓｔｒｏｙｅｄ」という動作状態、あるいは読み込みも完了していない動作状態にある場合である。この場合、Ｊａｖａアプリケーションのコードは１つも実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
【０１６２】
前述した通り、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３は、ＡＩＴの制御情報の変化やＪａｖａアプリケーションの指示により、Ｊａｖａアプリケーションの状態を遷移させる。第１の変換部７４１は、状態変化の通知をアプリケーションマネージャ４５０３から受ける。その結果としてＪａｖａミドルウェアの共通状態が変化する場合には、第１の変換部７４１は、図４９の変換表を参照して、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。この場合、第１の変換部７４１は、１次記憶部１０９にＪａｖａミドルウェアの共通状態を保存しておく。そして、第１の変換部７４１は、Ｊａｖａアプリケーションの状態が変化した後のＪａｖａミドルウェアの共通状態と比較する。なお、第１の変換部７４１は、Ｊａｖａアプリケーションの状態の変化をアプリケーションマネージャ４５０３から通知されたとき、常に「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知してもよい。
【０１６３】
第１の変換部７４１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴで規定された所定のＪａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。ここで所定のＪａｖａアプリケーションとは、ＡＩＴに規定されている全てのＪａｖａアプリケーションであってもよいし、優先度が最も高いＪａｖａアプリケーションであってもよい。所定のＪａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるべきＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでに「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションが存在する場合、第１の変換部７４１は何もしないこととしてもよい。
【０１６４】
第１の変換部７４１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴに規定された全てのＪａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。ただし、読み込んでいないＪａｖａアプリケーションに対しては何もしなくてもよい。全てのＪａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｄｅｓｔｒｏｙｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全Ｊａｖａアプリケーションに対して行えばよい。
【０１６５】
第１の変換部７４１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴに規定されたＪａｖａアプリケーションの中で「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションを見つけ、そのＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、そのＪａｖａアプリケーションの状態を取得する。もし状態が「Ａｃｔｉｖｅ」であれば、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全てのＪａｖａアプリケーションに対して行えばよい。
【０１６６】
第１の変換部７４１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、第１の変換部７４１は、ＡＩＴが定義している全てのＪａｖａアプリケーションおよびその状態に基づいて、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。「アプリケーション・データ一覧応答」メッセージに含めるアプリケーション名は、ＡＩＴが規定するアプリケーション名がそのまま使用される。「アプリケーション・データ一覧応答」メッセージに含める状態ＩＤは、各Ｊａｖａアプリケーションの状態を結合部７３０が規定する共通状態に変換表を用いて変換することによって作成される。
【０１６７】
図５０は、各Ｊａｖａアプリケーションの動作状態を共通状態に変換するための変換表の一例を示す図である。図５０において左側の列には、個別状態、すなわち、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態が記述されている。右側の列には、対応する共通状態が記述されている。上から２番目の行に示されるように、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態「Ａｃｔｉｖｅ」は、「実行中」という共通状態に対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションは極小リソースを使用している可能性が高いので、このような対応関係を規定した。
【０１６８】
また、図５０において上から３番目の行に示されるように、ＤＶＢ−ＭＨＰ１．０規格が規定しているＪａｖａアプリケーションの動作状態「Ｐａｕｓｅｄ」は、「一時停止中」という共通状態に対応付けられている。ＤＶＢ−ＭＨＰ１．０規格によれば、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションは、必要最小限のリソース以外は解放すべきと記述されている。よって、このような対応関係を規定した。
【０１６９】
また、上から４番目の行に示されるように、上から２番目および３番目の行以外の場合のＪａｖａアプリケーションの動作状態に対しては、「停止中」という共通状態が対応付けられている。上から２番目および３番目の行以外の場合とは、具体的には、Ｊａｖａアプリケーションの動作状態が、Ｊａｖａアプリケーションが「Ｌｏａｄｅｄ」もしくは「Ｄｅｓｔｒｏｙｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、Ｊａｖａアプリケーションのコードは１つも実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
【０１７０】
今、アプリケーション名が「ＥＰＧ」であるＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であり、アプリケーション名が「トランプゲーム」であるＪａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」であるように、ＡＩＴにおいて定義されている場合を考える。この場合、第１の変換部７４１は、「アプリケーション・データ一覧要求」メッセージを受け取ると、図５１に示す「アプリケーション・データ一覧応答」メッセージ５１００を生成し、結合部７３０に送信する。
【０１７１】
図５１は、第１の変換部７４１が送信するメッセージの具体例を示す図である。図５１に示すメッセージ５１００は、Ｊａｖａミドルウェア７４０からナビゲータ７２０への「アプリケーション・データ一覧応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド５１０１には、Ｊａｖａミドルウェア７４０を表すサブプログラムＩＤとして「２」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド５１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド５１０３には、「アプリケーション・データ一覧応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド５１０４には、データの長さを示す「２７」が格納される。アプリケーション数フィールド５１１０には、Ｊａｖａミドルウェア７４０が受け取ったＡＩＴに規定されているＪａｖａアプリケーション数である「２」が格納される。
【０１７２】
また、図５１において、アプリケーション数フィールド５１０５には、１つ目のＪａｖａアプリケーションに対するアプリケーション情報フィールド５１１１と、２つ目のＪａｖａアプリケーションに対するアプリケーション情報フィールド５１１２とが含まれている。アプリケーションＩＤフィールド５１２１には、１つ目のＪａｖａアプリケーションを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション状態ＩＤフィールド５１２２には、「実行中」を表すアプリケーション状態ＩＤとして「１」が格納されている。この「実行中」は、Ｊａｖａアプリケーションの動作状態「Ａｃｔｉｖｅ」が変換された結果である。アプリケーション名長さフィールド５１２３には、アプリケーション名の長さを示す「６」が格納される。アプリケーション名フィールド５１２４には、ＡＩＴで定義されたアプリケーション名「ＥＰＧ」が格納されている。ここで「ＥＰＧ」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、３文字×２バイト＝６バイトとなっている。アプリケーションＩＤフィールド５１２５には２つ目のＪａｖａアプリケーションを表すアプリケーションＩＤとして「２」が格納されている。アプリケーション状態ＩＤフィールド５１２６には、「停止中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「停止中」は、Ｊａｖａアプリケーションの動作状態「Ｄｅｓｔｒｏｙｅｄ」が変換された結果である。アプリケーション名長さフィールド５１２７には、アプリケーション名の長さを示す「１４」が格納される。アプリケーション名フィールド５１２８には、ＡＩＴで定義されたアプリケーション名「トランプゲーム」が格納されている。ここで「トランプゲーム」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、７文字×２バイト＝１４バイトとなっている。
【０１７３】
前述した通り、Ｊａｖａミドルウェア７４０のアプリケーションマネージャ４５０３は、ＡＩＴの制御情報の変化やＪａｖａアプリケーションの指示によってＪａｖａアプリケーションの動作状態を遷移させる。第１の変換部７４１は、状態変化の通知をアプリケーションマネージャ４５０３より受ける。その時、第１の変換部７４１は、「アプリケーション・データ一覧変化」メッセージを生成して、結合部７３０に通知する。第１の変換部７４１が結合部７３０から「アプリケーション・データ実行」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させるようにアプリケーションマネージャ４５０３に指示する。Ｊａｖａアプリケーションを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでにＪａｖａアプリケーションが「Ａｃｔｉｖｅ」状態の場合、第１の変換部７４１は、何もしないようにしてもよい。
【０１７４】
第１の変換部７４１が結合部７３０から「アプリケーション・データ停止」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させるようにアプリケーションマネージャ４５０３に指示する。ただし、読み込んでいないＪａｖａアプリケーションに対しては何もしなくてもよい。Ｊａｖａアプリケーションを「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｄｅｓｔｒｏｙｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」状態に遷移させることができる。
【０１７５】
第１の変換部７４１が結合部７３０から「アプリケーション・データ一時停止」メッセージを受け取った場合、第１の変換部７４１は、メッセージのデータフィールド１７５で指定されるＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させるようにアプリケーションマネージャ４５０３に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．０規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＪａｖａアプリケーションのＩＤを指定した後、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。
【０１７６】
さらに、第１の変換部７４１は、結合部７３０のリソース管理部７３３からリソース剥奪の通知を受けてもよい。第１の変換部７４１は、剥奪されたリソースに応じて、アプリケーションマネージャ４５０３にＪａｖａアプリケーションの状態を遷移させることとしてもよい。Ｊａｖａアプリケーションの実行に不可欠なリソースが剥奪された場合、第１の変換部７４１は、全てのＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる。それ以外のリソース、すなわち、Ｊａｖａアプリケーションの実行に必ずしも必要ではないリソースが剥奪された場合については、第１の変換部７４１は、何も行わなくともよい。また、リソース剥奪通知は、Ｊａｖａミドルウェア７４０が直接受け取り、対応する処理を行ってもよい。以上で、Ｊａｖａミドルウェア７４０の説明を終了する。
【０１７７】
次に、図５２〜図７１を用いて、ＨＴＭＬブラウザ７５０について説明する。ＨＴＭＬブラウザ７５０は、ＨＴＭＬデータを解釈し表示を行うフォーマットエンジンである。本構成例においては具体的な例として、ＤＶＢ−ＭＨＰ１．１規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．１）が規定するＤＶＢ−ＨＴＭＬを取り上げるが、例えば、ＸＨＴＭＬ１．０等の他の仕様に従って動作するものでも実施可能である。本構成例では、ＨＴＭＬブラウザ４５０の詳細な動作にはＤＶＢ−ＭＨＰ１．１規格の内容が含まれる。従って、ここでは、概略のみを記述する。
【０１７８】
図５２は、ＨＴＭＬブラウザ７５０の構成を示すブロック図である。ＨＴＭＬブラウザ７５０は、パーザー５２０１と、レイアウター５２０２と、描画部５２０３と、インタラクション部５２０４と、ＨＴＭＬマネージャ５２０５とを備えている。
【０１７９】
パーザー５２０１は、ＨＴＭＬマネージャ５２０５がダウンロードしたＤＶＢ−ＨＴＭＬデータの解析を行いＤＯＭ（ドキュメントオブジェクトモデル）ツリーを構築する。図５３は、ＤＶＢ−ＨＴＭＬデータの一例を示す図である。ＤＶＢ−ＨＴＭＬデータに対して、パーザー５２０１は図５５に示すようなＤＯＭツリーを構築する。
【０１８０】
レイアウター５２０２は、パーザー５２０１が構築したＤＯＭツリーの各構成要素に対して、ディスプレイ１０７上の表示位置を計算して決定する。図５４は、ＤＶＢ−ＨＴＭＬデータのレイアウトを決めるスタイルシートの一例を示す図である。図５４に示す各行は各々、図５３に示すＤＶＢ−ＨＴＭＬデータ中の各要素５３１１，５３１２，５３１３，および５３１４の表示位置を指定している。ここでは、スタイルシートの例としてＤＶＢ−ＭＨＰが規定するＣＳＳ（Ｗ３Ｃが規定するＣＳＳ２の拡張仕様）を取り上げているが、レイアウトを決めようとするＨＴＭＬデータのスタイルシートとしてレイアウターが解析可能なものであれば、ＣＳＳ２等の他の仕様に従うスタイルシートであっても実施可能である。レイアウター５２０２は、スタイルシートに基づいて、ＤＯＭツリーの各構成要素に対してディスプレイ１０７上の表示位置を決定する。例えば、図５５に示す“Ｗｅａｔｈｅｒ  ｆｏｒｅｃａｓｔ”に対して（５０，５０）で示される表示位置が決定された場合、文字列“Ｗｅａｔｈｅｒ  ｆｏｒｅｃａｓｔ”は、その左上の座標がディスプレイの上から５０ｐｘ，左から５０ｐｘの位置となるように表示される。図５５に示す“Ｊａｐａｎ“に対して（２００，１００）で示される表示位置が決定された場合、文字列“Ｊａｐａｎ“は、その左上の座標が、ディスプレイの上から２００ｐｘ，左から１００ｐｘの位置となるように表示される。
【０１８１】
なお、レイアウターがスタイルシートのパーザーを持ち、ＤＯＭツリー構築後においてそのパーザーがＨＴＭＬマネージャから指示を受けることによってスタイルシートを解析・計算し、計算した結果の表示位置をレイアウターに通知してもよい。また、ＨＴＭＬブラウザがデフォルトのスタイルシートを持ち、スタイルシートが存在しない場合は、レイアウターは、ＨＴＭＬブラウザが持つデフォルトのスタイルシートに従い、ＤＯＭツリーの各構成要素に対して、ディスプレイ１０７上の表示位置を計算して決定してもよい。
【０１８２】
図５２の説明に戻り、描画部５２０３は、レイアウター５２０２が計算した表示位置に従って、ＤＯＭツリーの各構成要素を描画する。図５６は、図５５に示すＤＯＭツリーを描画した際のディスプレイ１０７を示す図である。
【０１８３】
インタラクション部５２０４は、描画したＤＶＢ−ＨＴＭＬデータに含まれるリンクやボタン等に対してユーザが入力した指示に対応する処理を行う。例えば、ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されているとする。ここで、ユーザが、リンクのクリックを入力部１１１から入力すると、インタラクション部５２０４は、リンクに定義されたＤＶＢ−ＨＴＭＬデータの情報をＨＴＭＬマネージャ５２０５に引き渡す。
【０１８４】
ＨＴＭＬマネージャ５２０５は、引き渡されたＤＶＢ−ＨＴＭＬデータの情報に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。図５３に示すＤＶＢ−ＨＴＭＬデータ内には、他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている。
【０１８５】
図５６において、ディスプレイ上の文字列“Ｊａｐａｎ”として代表されるリンク先「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」のクリックをユーザが入力すると、インタラクション部５２０４は、ＤＶＢ−ＨＴＭＬデータの情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」をＨＴＭＬマネージャ５２０５に引き渡す。ここで、あるリンク先のクリックを入力するとは、そのリンク先をフォーカス５６０１が選択しているときにＯＫボタン３０５を押下することをいう。ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。図５７は、ユーザが文字列“Ｊａｐａｎ”と代表されるリンク先をクリックした後にディスプレイ表示されるＤＶＢ−ＨＴＭＬデータの例を示す図である。
【０１８６】
また、例えば、ＤＶＢ−ＨＴＭＬデータ内に定義されたボタンに、ＤＯＭツリーの構成を変更するスクリプトが定義されているとする。ここで、ユーザがボタンのクリックを入力部１１１から入力すると、インタラクション部５２０４は、パーザー５２０１からＤＶＢ−ＨＴＭＬデータを受け取り、ボタンに定義されたスクリプトを実行し、ＤＯＭツリーの構成を変更する。この変更に伴い、レイアウター５２０２が表示位置を再計算し、描画部５２０３は描画をやり直す。また、ＤＯＭツリーを変更したことを、ＨＴＭＬマネージャ５２０５に通知する。
【０１８７】
図５８に示すＤＶＢ−ＨＴＭＬデータ内には、ＤＯＭツリーの構成を変更するスクリプト５８０１として”ｃｈａｎｇｅＤＯＭＴｒｅｅ（）”（具体的には、例えば、ＤＯＭツリーにおいてテーブル要素を記述したもの）が定義され、ボタン５８０２のクリック時にそのスクリプト５８０１を実行するよう定義されている。スクリプト５８０１において、ＤＯＭツリーの構成を変更するソースコードは省略されている。スクリプトは、例えば、ＤＶＢ−ＭＨＰが規定するＤＯＭ（Ｗ３Ｃが規定するＤＯＭ２の拡張仕様）仕様に従うものであっても、ＤＯＭ１、２等の他の仕様に従うスクリプトであっても実施可能である。
【０１８８】
図５９は、図５８に示すＤＶＢ−ＨＴＭＬデータに対してパーザー５２０１が構築したＤＯＭツリーの一部を示す図である。また、図６０は、レイアウター５２０２および描画部５２０３によって表示されたディスプレイ表示の例を示す図である。図６０において、ラベル“詳細情報”６００１に代表されるボタン５８０２のクリックをユーザが入力すると、インタラクション部５２０４は、パーザー５２０１からＤＶＢ−ＨＴＭＬデータを受け取る。そして、インタラクション部５２０４は、ボタン５８０２に定義されたスクリプト５８０１を実行してＤＯＭツリーの構成を変更する。また、レイアウター５２０２は、表示位置を最計算する。描画部５２０３は、描画をやり直す。さらに、ＤＯＭツリーを変更したことがＨＴＭＬマネージャ５２０５に通知される。図６１は、ユーザによるボタンのクリックに伴うＤＯＭツリーの変更結果を示す図である。また、図６２は、ディスプレイ表示の変更結果の例を示す図である。
【０１８９】
ＨＴＭＬマネージャ５２０５は、放送波中に多重化されているＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈し、表示する。ＭＨＰ１．１規格によれば、放送波中には、ＡＩＴと呼ばれるＤＶＢ−ＨＴＭＬデータを定義する表が多重化され伝送される。ＨＴＭＬマネージャ５２０５は、このＡＩＴを最初にダウンロードする。ＡＩＴには、ＤＶＢ−ＨＴＭＬデータをダウンロードするための情報や、ＤＶＢ−ＨＴＭＬデータの名前、ＤＶＢ−ＨＴＭＬデータの制御情報などが含まれる。
【０１９０】
図６３は、ＡＩＴの主要部を表した模式図である。図６３において最も左側の列には、ＤＶＢ−ＨＴＭＬデータのＩＤが記述されている。左から２番目の列には、ＤＶＢ−ＨＴＭＬデータの制御情報が記述されている。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」等がある。「ａｕｔｏｓｔａｒｔ」は、ＨＴＭＬブラウザ７５０がＤＶＢ−ＨＴＭＬデータを即時に解釈・表示することを意味する。「ｐｒｅｓｅｎｔ」は、自動的に解釈・表示しないことを意味する。「ｋｉｌｌ」は、ＤＶＢ−ＨＴＭＬデータの表示を消すことを意味する。左から３番目の列には、ＤＶＢ−ＨＴＭＬデータのデータ名が記述されている。最も右側の列には、ＤＶＢ−ＨＴＭＬデータの優先度が記述されている。複数のＤＶＢ−ＨＴＭＬデータの表示時に、リソースの競合が発生した場合、優先度の高いＤＶＢ−ＨＴＭＬデータの表示にリソースが優先的に割り当てられる。ここで、優先度の値が大きいほど優先度が高いこととする。
【０１９１】
図６３において、上から２番目および３番目の行には、ＤＶＢ−ＨＴＭＬデータの情報の組が記述される。上から２番目の行において定義されるＤＶＢ−ＨＴＭＬデータについては、ＩＤが「１」であり、制御情報が「ａｕｔｏｓｔａｒｔ」であり、データ名が「天気予報」であり、優先度が「５４」である。上から３番目の行において定義されるＤＶＢ−ＨＴＭＬデータについては、ＩＤが「２」であり、制御情報が「ｐｒｅｓｅｎｔ」であり、データ名が「レジャー情報」であり、優先度が「２２」である。
【０１９２】
ＨＴＭＬマネージャ５２０５は、図６３に示すＡＩＴを受け取ると、データ名が「天気予報」であるＤＶＢ−ＨＴＭＬデータをダウンロードし、解釈・表示する。ここで、ＤＶＢ−ＭＨＰ１．１規格が規定するＤＶＢ−ＨＴＭＬデータは、「Ｌｏａｄｅｄ」、「Ｐａｕｓｅｄ」、「Ａｃｔｉｖｅ」、「Ｄｅｓｔｒｏｙｅｄ」、および「Ｋｉｌｌｅｄ」という５つの状態を有している。
【０１９３】
図６４は、ＤＶＢ−ＨＴＭＬデータの５つの状態および状態間の遷移を表す状態遷移図である。ＨＴＭＬマネージャ５２０５がＤＶＢ−ＨＴＭＬデータをダウンロードし、１次記憶部１０９に格納されると、当該ＤＶＢ−ＨＴＭＬデータの状態は「Ｌｏａｄｅｄ」になる。各状態間を結ぶ矢印は、状態間で可能な遷移を表しており、矢印のない状態間の遷移は発生しない。例えば、「Ｄｅｓｔｒｏｙｅｄ」の状態から「Ａｃｔｉｖｅ」の状態に遷移することはない。
【０１９４】
ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの状態遷移を、（１）放送波中のＡＩＴの制御情報、（２）ＤＶＢ−ＨＴＭＬデータの指示、および（３）ナビゲータ７２０が結合部７３０を通して送る指示、の３通りの指示に従って行う。
【０１９５】
ＡＩＴの制御情報が「ａｕｔｏｓｔａｒｔ」の場合、ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータをダウンロードした後、パーザー５２０１、レイアウター５２０２、および描画部５２０３に指示することでＤＶＢ−ＨＴＭＬデータを解釈・表示し、「Ａｃｔｉｖｅ」状態に遷移させる。ＡＩＴは、時間と共に変化する。例えば、ＡＩＴが図６３に示す状態から図６５に示す状態へ変化したとする。図６５では、データ名が「天気予報」であるＤＶＢ−ＨＴＭＬデータの制御情報が「ａｕｔｏｓｔａｒｔ」から「ｋｉｌｌ」に変更されている。このとき、ＨＴＭＬマネージャ５２０５は、ＤＶＢ−ＨＴＭＬデータの表示状態を「Ｋｉｌｌｅｄ」という状態に遷移させる。
【０１９６】
一方、ＤＶＢ−ＨＴＭＬデータに対するユーザの入力により、ＤＶＢ−ＨＴＭＬデータが状態遷移を発生させることができる。図６６は、ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている例を示す図である。図６７は、図６６に示すＤＶＢ―ＨＴＭＬデータの表示例を示す図である。図６７において、表示６７１１がリンク６６０１に対応する。ここで、ユーザがリンク６６０１に対してクリックを入力部１１１から入力すると、インタラクション部５２０４は、リンクに定義されたＤＶＢ−ＨＴＭＬデータの情報をＨＴＭＬマネージャ５２０５に引き渡す。ここで、ＤＶＢ−ＨＴＭＬデータの情報は図６６を参照して「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」である。ＨＴＭＬマネージャ５２０５は、引き渡されたＤＶＢ−ＨＴＭＬデータの情報に基づいて、ＤＶＢ−ＨＴＭＬデータをダウンロードする。そして、ＨＴＭＬマネージャ５２０５は、パーザー５２０１、レイアウター５２０２、および描画部５２０３を用いてＤＶＢ−ＨＴＭＬデータを解釈・表示する。この処理によって、ＨＴＭＬマネージャ５２０５は、元のＤＶＢ−ＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」から「Ｋｉｌｌｅｄ」へと遷移することになる。一方、「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」という情報に相当する新たなＤＶＢ−ＨＴＭＬデータの状態は、「Ｌｏａｄｅｄ」から「Ａｃｔｉｖｅ」へと遷移することになる。図６８は、情報「ｄｖｂ：／／１．２．１／Ｊａｐａｎ＿Ｗｅａｔｈｅｒ．ｈｔｍｌ」に相当する新たなＤＶＢ−ＨＴＭＬデータの表示例を示す図である。
【０１９７】
最後に、ナビゲータ７２０からの指示によってＤＶＢ−ＨＴＭＬデータの表示の状態を遷移する方法を説明する。ナビゲータ７２０は、共通状態、すなわち、結合部７３０が規定しているフォーマットエンジンの状態およびフォーマットエンジンが表示可能なデータの状態に基づいて指示を出す。この共通状態は、個別状態、すなわち、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５が表示するＤＶＢ−ＨＴＭＬデータの表示の状態および状態遷移とは異なっている。この共通状態と個別状態との間のギャップを第２の変換部７５１が埋めるのである。第２の変換部７５１は、ナビゲータ７２０からの指示を、ＨＴＭＬブラウザ７５０が取り扱う状態および状態遷移に変換する。その結果、ＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報やＤＶＢ−ＨＴＭＬデータからの指示と同等の指示を受け、ＤＶＢ−ＨＴＭＬデータの表示の状態を遷移させることができる。
【０１９８】
第２の変換部７５１は、結合部７３０からのメッセージを変換してＨＴＭＬブラウザ７５０に伝え、また、ＨＴＭＬブラウザ７５０の情報を変換して結合部７３０に伝えることにより、ＨＴＭＬブラウザ７５０の動作を結合部７３０が規定する状態に適合させる。ここまで、様々なメッセージを、結合部７３０を通してＨＴＭＬブラウザ７５０に配送すると記述してきたが、正確には、これらのメッセージはＨＴＭＬブラウザ７５０ではなく第２の変換部７５１に送信される。第２の変換部７５１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第２の変換部７５１は、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態に基づいてＨＴＭＬブラウザ７５０の状態を決定する。そして、第２の変換部７５１は、「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０へ送る。
【０１９９】
図６９は、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態と、ＨＴＭＬブラウザ７５０の動作状態との対応を示す変換表の一例を示す図である。図６９において左側の列には、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態が記述されている。右側の列には、対応するＨＴＭＬブラウザ７５０の動作状態が記述されている。ここで、ＨＴＭＬブラウザ７５０の状態は、結合部７３０が規定した状態、すなわち共通状態である。具体的には、図２１で示した「実行中」、「一時停止中」、および「停止中」という３つの動作状態である。上から２番目から４番目の行には、これら３つの状態に対応する、ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態が規定されている。
【０２００】
まず、上から２番目の行には、全てのＨＴＭＬデータの中で１つでも「Ａｃｔｉｖｅ」状態のＨＴＭＬデータがあることに対して、ＨＴＭＬブラウザ７５０の共通状態として「実行中」が対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータの表示およびユーザとのインタラクションには極小リソースを使用している可能性が高いため、このような対応関係を規定した。
【０２０１】
次に、上から３番目の行には、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータがなく、かつ、全ＨＴＭＬデータの中で１つでも「Ｐａｕｓｅｄ」状態のＨＴＭＬデータがあることに対して、ＨＴＭＬブラウザ７５０の共通状態として「一時停止中」が対応付けられている。ＤＶＢ−ＭＨＰ１．１規格によれば、「Ｐａｕｓｅｄ」状態のＨＴＭＬデータの表示は、一部のリソースは使用できないと記述されている。よって、このような対応関係を規定した。
【０２０２】
次に、上から４番目の行には、上から２番目および３番目の行に示す場合以外の場合に対して、「停止中」が対応付けられている。上から２番目および３番目の行に示す場合以外の場合とは、具体的には、全てのＨＴＭＬデータが「Ｌｏａｄｅｄ」、「Ｄｅｓｔｒｏｙｅｄ」、もしくは「Ｋｉｌｌｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、ＨＴＭＬデータに対するインタラクション処理は実行されていないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
【０２０３】
前述した通り、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報の変化やＨＴＭＬデータの指示により、ＨＴＭＬデータの状態を遷移させる。第２の変換部７５１は、状態変化の通知をＨＴＭＬマネージャ５２０５より受ける。その結果としてＨＴＭＬブラウザ７５０の状態が変化する場合には、第２の変換部７５１は、図６９の変換表を参照して、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。この場合、第２の変換部７５１は、１次記憶部１０９にＨＴＭＬブラウザ７５０の共通状態を保存しておく。そして、ＨＴＭＬデータの状態が変化した後の共通状態と比較する。なお、第２の変換部７５１は、ＨＴＭＬデータの状態の変化をＨＴＭＬマネージャ５２０５から通知されたとき、常に「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知してもよい。
【０２０４】
第２の変換部７５１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定された所定のＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。ここで所定のＨＴＭＬデータとは、ＡＩＴに規定されている全てのＨＴＭＬデータでもよいし、優先度が最も高いＨＴＭＬデータであってもよい。所定のＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるべきＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでに「Ａｃｔｉｖｅ」状態のＨＴＭＬデータが存在する場合は、第２の変換部７５１は何もしないということとしてもよい。
【０２０５】
第２の変換部７５１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定された全てのＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。ただし、読み込んでいないＨＴＭＬデータに対しては何もしなくてもよい。全てのＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｋｉｌｌｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全ＨＴＭＬデータに対して行えばよい。
【０２０６】
第２の変換部７５１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴに規定されたＨＴＭＬデータの中で「Ａｃｔｉｖｅ」状態のＨＴＭＬデータを見つけ、そのＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させるようにＨＴＭＬブラウザ７５０に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、そのＨＴＭＬデータの状態を取得する。もし状態が「Ａｃｔｉｖｅ」であれば、遷移させる状態「Ｐａｕｓｅｄ」を指定することによって、対象のＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。この操作をＡＩＴが定義する全てのＨＴＭＬデータに対して行えばよい。
【０２０７】
第２の変換部７５１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、第２の変換部７５１は、ＡＩＴが定義している全てのＨＴＭＬデータおよびその状態に基づいて、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。「アプリケーション・データ一覧応答」メッセージに含めるアプリケーション名は、ＡＩＴが規定するアプリケーション名がそのまま使用される。「アプリケーション・データ一覧応答」メッセージに含める状態ＩＤは、各ＨＴＭＬデータの状態を結合部７３０が規定する共通状態に変換表を用いて変換することによって作成される。
【０２０８】
図７０は、各ＨＴＭＬデータの状態を共通状態に変換するための変換表の一例を示す図である。図７０において左側の列には、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態が記述されている。右側の列には、対応する共通状態が記述されている。上から２番目の行に示されるように、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態「Ａｃｔｉｖｅ」は、「実行中」という共通状態に対応付けられている。一般に、「Ａｃｔｉｖｅ」状態のＨＴＭＬデータの表示およびユーザとのインタラクションは極小リソースを使用する可能性が高いので、このような対応関係を規定した。
【０２０９】
また、図７０において上から３番目の行に示されるように、ＤＶＢ−ＭＨＰ１．１規格が規定しているＨＴＭＬデータの状態「Ｐａｕｓｅｄ」は、「一時停止中」という共通状態に対応付けられている。ＤＶＢ−ＭＨＰ１．１規格によれば、「Ｐａｕｓｅｄ」状態のＨＴＭＬデータの表示およびユーザとのインタラクション処理は使用可能なリソースが制限されると記述されている。よって、このような対応関係を規定した。
【０２１０】
また、上から４番目の行に示されるように、上から２番目および３番目の行以外の場合のＨＴＭＬデータの状態に対しては、「停止中」という共通状態が対応付けられている。上から２番目および３番目の行以外の場合とは、具体的には、ＨＴＭＬデータが「Ｌｏａｄｅｄ」、「Ｄｅｓｔｒｏｙｅｄ」、もしくは「Ｋｉｌｌｅｄ」状態、または読み込みも完了していない状態にある場合である。この場合、ＨＴＭＬデータの解釈・表示処理およびユーザとのインタラクション処理は実行されないので、リソースを一切使用していない「停止中」に対応付けるのが妥当である。
【０２１１】
今、データ名が「天気予報」であるＨＴＭＬデータの状態が「Ａｃｔｉｖｅ」であり、データ名が「レジャー情報」であるＨＴＭＬデータの状態が「Ｄｅｓｔｒｏｙｅｄ」であるように、ＡＩＴにおいて定義されている場合を考える。この場合、第２の変換部７５１は、「アプリケーション・データ一覧要求」メッセージを受け取ると、図７１に示す「アプリケーション・データ一覧応答」メッセージ７１００を生成し、結合部７３０に送信する。
【０２１２】
図７１は、第２の変換部７５１が送信するメッセージの具体例を示す図である。図７１に示すメッセージ７１００は、ＨＴＭＬブラウザ７５０からナビゲータ７２０への「アプリケーション・データ一覧応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド７１０１には、ＨＴＭＬブラウザ７５０を表すサブプログラムＩＤとして「３」が格納される（図１８参照）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド７１０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される（図１８参照）。Ｍｅｓｓａｇｅ  ＩＤフィールド７１０３には、「アプリケーション・データ一覧応答」を表すメッセージＩＤとして「１２」が格納される（図１９参照）。Ｄａｔａ  Ｌｅｎｇｔｈフィールド７１０４には、データの長さを表す「２７」が格納される。アプリケーション数フィールド７１１０には、ＨＴＭＬブラウザ７５０が受け取ったＡＩＴに規定されているＨＴＭＬデータ数である「２」が格納される。
【０２１３】
また、図７１において、アプリケーション数フィールド７１０５には、１つ目のＨＴＭＬデータに対するアプリケーション情報フィールド７１１１と、２つ目のＨＴＭＬデータに対するアプリケーション情報フィールド７１１２とが含まれている。アプリケーションＩＤフィールド７１２１には、１つ目のＨＴＭＬデータを表すアプリケーションＩＤとして「１」が格納されている。アプリケーション状態ＩＤフィールド７１２２には、「実行中」を表すアプリケーション状態ＩＤとして「１」が格納されている。この「実行中」は、ＨＴＭＬデータの状態「Ａｃｔｉｖｅ」が変換された結果である。アプリケーション名長さフィールド７１２３には、アプリケーション名の長さを示す「８」が格納される。アプリケーション名フィールド７１２４には、ＡＩＴで定義されたデータ名「天気予報」が格納されている。ここで「天気予報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、４文字×２バイト＝８バイトとなっている。アプリケーションＩＤフィールド７１２５には２つ目のＨＴＭＬデータを表すアプリケーションＩＤとして「２」が格納されている。アプリケーション状態ＩＤフィールド７１２６には、「停止中」を表すアプリケーション状態ＩＤとして「３」が格納されている。この「停止中」は、ＨＴＭＬデータの動作状態「Ｄｅｓｔｒｏｙｅｄ」が変換された結果である。アプリケーション名長さフィールド７１２７には、アプリケーション名の長さを示す「１２」が格納される。アプリケーション名フィールド７１２８には、ＡＩＴで定義されたデータ名「レジャー情報」が格納されている。ここで「レジャー情報」の各文字は２バイトコードで表現されており、結果、アプリケーション名長さは、６文字×２バイト＝１２バイトとなっている。
【０２１４】
前述した通り、ＨＴＭＬブラウザ７５０のＨＴＭＬマネージャ５２０５は、ＡＩＴの制御情報の変化やＨＴＭＬデータの指示によって、ＨＴＭＬデータの状態を遷移させる。第２の変換部７５１は、状態変化の通知をＨＴＭＬマネージャ５２０５より受ける。その時、第２の変換部７５１は、「アプリケーション・データ一覧変化」メッセージを生成して、結合部７３０に通知する。第２の変換部７５１が、結合部７３０から「アプリケーション・データ実行」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。ＨＴＭＬデータを「Ａｃｔｉｖｅ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。状態を変化させるＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ａｃｔｉｖｅ」を指定することによって、対象のＨＴＭＬデータの状態を「Ａｃｔｉｖｅ」状態に遷移させることができる。なお、すでにＨＴＭＬデータが「Ａｃｔｉｖｅ」状態の場合、第２の変換部７５１は何もしないとようにしてもよい。
【０２１５】
第２の変換部７５１が結合部７３０から「アプリケーション・データ停止」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。ただし、読み込んでいないＨＴＭＬデータに対しては何もしなくてもよい。ＨＴＭＬデータを「Ｋｉｌｌｅｄ」状態に遷移させるには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｋｉｌｌｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」状態に遷移させることができる。
【０２１６】
第２の変換部７５１が結合部７３０から「アプリケーション・データ一時停止」メッセージを受け取った場合、第２の変換部７５１は、メッセージのデータフィールド１７５で指定されるＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」に遷移させるようにＨＴＭＬマネージャ５２０５に指示する。この処理を実現するには、ＤＶＢ−ＭＨＰ１．１規格が規定しているｏｒｇ．ｄｖｂ．ａｐｐｌｉｃａｉｔｏｎパッケージの機能を利用することができる。ＨＴＭＬデータのＩＤを指定した後、遷移させる状態「Ｐａｕｓｅｄ」を指定することで、対象のＨＴＭＬデータの状態を「Ｐａｕｓｅｄ」状態に遷移させることができる。
【０２１７】
さらに、第２の変換部７５１は、結合部７３０のリソース管理部７３３よりリソース剥奪の通知を受けてもよい。第２の変換部７５１は、剥奪されたリソースに応じて、ＨＴＭＬマネージャ５２０５にＨＴＭＬデータの状態を遷移させることとしてもよい。ＨＴＭＬデータの表示に不可欠なリソースが剥奪された場合は、全てのＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」に遷移させる。それ以外のリースの剥奪に対しては、第２の変換部７５１は、何も行わないとしてもよい。また、リソース剥奪通知は、ＨＴＭＬブラウザ７５０が直接受け取り、対応する処理を行ってもよい。以上で、ＨＴＭＬブラウザ７５０の説明を終了する。
【０２１８】
次に、図７２および図７３を用いて、メーラー７６０について説明する。メーラー７６０は、電子メールの読み書きを行うためのフォーマットエンジンである。メーラー７６０は、Ｊａｖａミドルウェア７４０やＨＴＭＬブラウザ７５０のように、取り扱うアプリケーションやデータに関する状態を規定していない。メーラー７６０自身の状態も特に規定がない。ここでは、メーラー７６０は、実行中および停止中という２つの状態を有している考える。ここで、メーラー７６０は一般的な電子メールソフトウエアの機能を含む。メーラー７６０自体の機能は既知であるので説明を省略する。
【０２１９】
第３の変換部７６１は、結合部７３０からのメッセージを変換してメーラー７６０に伝える。また、第３の変換部７６１は、メーラー７６０の動作状態を変換して結合部７３０に伝える。これによって、第３の変換部７６１は、メーラー７６０の動作状態を結合部７３０が規定する共通状態に適合させる。なお、ここまで、様々なメッセージを、結合部７３０を通してメーラー７６０に配送すると記述してきたが、正確には、これらのメッセージはメーラー７６０ではなく第３の変換部７６１に配送される。
【０２２０】
第３の変換部７６１が結合部７３０から「フォーマットエンジン状態要求」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０の動作状態に基づいて「フォーマットエンジン状態応答」メッセージを作成し、結合部７３０に送る。
【０２２１】
図７２は、メーラー７６０の状態と、結合部７３０が規定している共通状態との対応を示す変換表の一例を示す図である。図７２において左側の列には、メーラー７６０の個別状態が記述されている。右側の列には、対応するメーラー７６０の共通状態が記述されている。共通状態は、具体的には、図２１で示した「実行中」および「停止中」という２つの動作状態である。上から２番目および３番目の行には、これら２つの状態に対応する、メーラー７６０の個別状態が規定されている。
【０２２２】
まず、上から２番目の行には、メーラー７６０が起動中であることに対して、メーラー７６０の共通状態として「実行中」が対応付けられている。一般に、起動中のメーラーはネットワークインターフェース等の極小リソースを使用している可能性が高いため、このような対応関係を規定した。
【０２２３】
次に、上から３番目の行には、メーラー７６０が停止中であることに対して、メーラー７６０の共通状態として「停止中」が対応付けられている。メーラー７６０が停止しているときは、メーラー７６０はリソースを一切使用していない。よって、「停止中」に対応付けるのが妥当である。なお、メーラー７６０には、共通状態「一時停止中」に対応する個別状態はない。
【０２２４】
メーラー７６０は、不測の事態などが発生すると、メーラー７６０自身を終了する可能性がある。第３の変換部７６１は、この変化をメーラー７６０より受ける。このとき、第３の変換部７６１は、「フォーマットエンジン状態変化」メッセージを生成して、結合部７３０に通知する。第３の変換部７６１が結合部７３０から「フォーマットエンジン実行」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を起動する。第３の変換部７６１が結合部７３０から「フォーマットエンジン停止」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を終了させる。第３の変換部７６１が結合部７３０から「フォーマットエンジン一時停止」メッセージを受け取った場合、第３の変換部７６１は、メーラー７６０を終了させる。図７２で示すように、メーラー７６０には「一時停止中」に対応する状態がない。ここでは、「一時停止中」とは、極小リソースを使用しないという意味である（図２１参照）。これを実現するには、メーラー７６０を終了させるしかない。
【０２２５】
第３の変換部７６１が結合部７３０から「アプリケーション・データ一覧要求」メッセージを受け取った場合、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送る。ここで、メーラー７６０は、取り扱うアプリケーションやデータがないため、アプリケーション数０のメッセージを生成する。
【０２２６】
図７３は、第３の変換部７６１が生成する「アプリケーション・データ一覧応答」メッセージの具体例を示す図である。図７３に示すメッセージ７３００は、メーラー７６０からナビゲータ７２０への「アプリケーション・データ一覧応答」である。Ｓｏｕｒｃｅ  ＩＤフィールド７３０１には、メーラー７６０を表すサブプログラムＩＤとして「４」が格納される。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールド７３０２には、ナビゲータ７２０を表すサブプログラムＩＤとして「１」が格納される。Ｍｅｓｓａｇｅ  ＩＤフィールド７３０３には、「アプリケーション・データ一覧応答」を表すメッセージＩＤとして「１２」が格納される。Ｄａｔａ  Ｌｅｎｇｔｈフィールド７３０４には、データの長さを示す「１」が格納される。アプリケーション数フィールド７３０５には、「０」が格納される。
【０２２７】
第３の変換部７６１が結合部７３０から「アプリケーション・データ実行」メッセージ、「アプリケーション・データ停止」メッセージあるいは「アプリケーション・データ一時停止」メッセージを受け取った場合、第３の変換部７６１は、何もしない。この理由は、メーラー７６０は、取り扱うアプリケーション・データの状態を持たないからである。また、第３の変換部７６１は、「アプリケーション・データ一覧変化」メッセージを生成することはない。
【０２２８】
さらに第３の変換部７６１は、結合部７３０のリソース管理部７３３よりリソース剥奪の通知を受けてもよい。第３の変換部７６１は、剥奪されたリソースに応じて、メーラー７６０を終了させることとしてもよい。メーラーの実行に不可欠なリソース、例えばネットワークインターフェース等が剥奪された場合は、第３の変換部７６１は、メーラー７６０を終了させる。それ以外のリースの剥奪に対しては、第３の変換部７６１は、何も行わないとしてもよい。また、リソース剥奪通知は、メーラー７６０が直接受け取り、対応する処理を行ってもよい。以上で、メーラー７６０の説明を終了する。また、以上で、情報処理装置の具体的な構成の説明を終了する。
【０２２９】
（詳細な動作）
次に、図７４〜図８４を用いて、上記の構成例に示したデジタルテレビにおいて前述した第１および第２の動作例の動作を行う場合について説明する。
【０２３０】
（第１の動作例の詳細な動作）
まず、図７４〜図８１を用いて、第１の動作例の詳細な動作を説明する。図７４は、第１の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。図７４において、まず、ナビゲータ７２０は、フォーマットエンジンの起動要求を受け付ける（ステップＳ１）。ここで、起動要求は、典型的にはユーザによって指示される。例えば図８に示す状態において、ユーザが入力部１１１のＯＫボタン３０５を押下することによって、Ｊａｖａミドルウェア７４０に関する起動要求が指示される。
【０２３１】
次に、ナビゲータ７２０は、各フォーマットエンジンの内、１つを選択する（ステップＳ２）。ステップＳ２で選択したフォーマットエンジンについて、以降のステップＳ３〜Ｓ６の処理が行われる。続いて、ナビゲータ７２０は、ステップＳ２で選択したフォーマットエンジンに対する「フォーマットエンジン（図では、“ＦＭ”と記載する。）状態要求」メッセージを結合部７３０へ送信する（ステップＳ３）。このメッセージは、結合部７３０によって当該フォーマットエンジンに対応する変換部へ送信される。
【０２３２】
ここで、結合部７３０の通信部７３１がメッセージを送信する処理について説明する。図７５は、通信部７３１が行うメッセージ送信の処理の流れを示すフローチャートである。通信部７３１は、メッセージを受け取ると（ステップＳ７５０１）、メッセージ中のＤｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値を参照する。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「０」のとき（ステップＳ７５０２）、通信部７３１は、ナビゲータ７２０、Ｊａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、メーラー７６０、および結合部７３０の状態管理部７３２にメッセージを送信する（ステップＳ７５０３）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「１」のとき（ステップＳ７５０４）、通信部７３１は、ナビゲータ７２０にメッセージを送信する（ステップＳ７５０５）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「２」のとき（ステップＳ７５０６）、通信部７３１は、Ｊａｖａミドルウェア７４０にメッセージを送信する（ステップＳ７５０７）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「３」のとき（ステップＳ７５０８）、通信部７３１は、ＨＴＭＬブラウザ７５０にメッセージを送信する（ステップＳ７５０９）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「４」のとき（ステップＳ７５１０）、通信部７３１は、メーラー７６０にメッセージを送信する（ステップＳ７５１１）。Ｄｅｓｔｉｎａｔｉｏｎ  ＩＤフィールドの値が「５」のとき（ステップＳ７５１２）、通信部７３１は、結合部７３０の状態管理部７３２にメッセージを送信する（ステップＳ７５１３）。以上の処理によって、各サブプログラムからのメッセージは、適切なサブプログラムへ送信されることとなる。通信部７３１は、メッセージを受け取る度に、上記処理を行う。
【０２３３】
次に、ステップＳ３の「フォーマットエンジン状態要求」メッセージを受信した際の各変換部の処理の流れについて説明する。
【０２３４】
図７６は、第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ると（ステップＳ７６０１）、第１の変換部７４１は、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがあるかどうかを調べる（ステップＳ７６０２）。「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがある場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「実行中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０３）。一方、「Ａｃｔｉｖｅ」状態のＪａｖａアプリケーションがない場合、第１の変換部７４１は、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがあるかどうかを調べる（ステップＳ７６０４）。「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがある場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「一時停止中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０５）。一方、「Ｐａｕｓｅｄ」状態のＪａｖａアプリケーションがない場合、第１の変換部７４１は、Ｊａｖａミドルウェア７４０が「停止中」である「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７６０６）。ステップＳ７６０３、Ｓ７６０５、またはＳ７６０６の後、第１の変換部７４１は、作成した「フォーマットエンジン状態応答」メッセージを結合部７３０に送信する（ステップＳ７６０７）。
【０２３５】
なお、「フォーマットエンジン状態要求」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図７６のフローチャートに準ずる。
【０２３６】
図７７は、第３の変換部７６１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャートである。第３の変換部７６１が「フォーマットエンジン状態要求」メッセージを受け取ると（ステップＳ７７０１）、第３の変換部７６１は、メーラー７７０が起動しているかどうかを調べる（ステップＳ７７０２）。メーラーが起動している場合、第３の変換部７６１は、メーラー７６０が「実行中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７７０３）。一方、メーラーが起動していない場合、第３の変換部７６１は、メーラー７６０が「停止中」であることを示す「フォーマットエンジン状態応答」メッセージを作成する（ステップＳ７７０４）。ステップＳ７７０３またはＳ７７０４の後、第３の変換部７６１は、作成した「フォーマットエンジン状態応答」メッセージを結合部７３０に配送する（ステップＳ７７０５）。
【０２３７】
以上、図７６および図７７に示した処理によって、ナビゲータ７２０に「フォーマットエンジン状態応答」メッセージが返ってくる。図７４の説明に戻り、ステップＳ３の次に、ナビゲータ７２０は、「フォーマットエンジン状態応答」メッセージを受信する（ステップＳ４）。続いて、ナビゲータ７２０は、受信したメッセージに基づいて、ステップＳ２で選択したフォーマットエンジンが実行中であるか否かを判定する（ステップＳ５）。
【０２３８】
ステップＳ５において、フォーマットエンジンが実行中でないと判定された場合、ナビゲータ７２０は、ステップＳ６の処理をスキップし、ステップＳ７の処理を行う。一方、フォーマットエンジンが実行中であると判定された場合、ナビゲータ７２０は、当該フォーマットエンジンに対する「フォーマットエンジン停止」メッセージを結合部７３０へ送信する（ステップＳ６）。このメッセージは、当該フォーマットエンジンに対応する変換部へ結合部７３０によって送信される。
【０２３９】
次に、ステップＳ６の「フォーマットエンジン停止」メッセージを受信した際の各変換部の処理の流れについて説明する。図７８は、第１の変換部７４１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを表すフローチャートである。第１の変換部７４１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ７８０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションを１つ選択する（ステップＳ７８０２）。続いて、第１の変換部７４１は、選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前であるかを調べる（ステップＳ７８０３）。選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前のいずれかでもない場合、第１の変換部７４１は、選んだＪａｖａアプリケーションの状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる（ステップＳ７８０４）。選択したＪａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」であるか、あるいは読み込む前のいずれかである場合、第１の変換部７４１は、ステップＳ７８０４の処理をスキップし、ステップＳ７８０５の処理を行う。すなわち、第１の変換部７４１は、ステップＳ７８０５において全てのＪａｖａアプリケーションを選択したか否かを判定する。１つでも選択していないＪａｖａアプリケーションがある場合、第１の変換部７４１は、ステップＳ７８０２の処理を行う。そして、第１の変換部７４１は、ステップＳ７８０２〜Ｓ７８０５の処理を繰り返す。一方、全てのＪａｖａアプリケーションを選択した場合、第１の変換部７４１は、図７８の処理を終了する。以上のように、第１の変換部７４１は、ステップＳ７８０２〜ステップＳ７８０４までの処理を全てのＪａｖａアプリケーションに対して実施する。
【０２４０】
図７９は、第２の変換部７５１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第２の変換部７５１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ７９０１）、第２の変換部７５１は、ＡＩＴからＨＴＭＬデータを１つ選択する（ステップＳ７９０２）。続いて、第２の変換部７５１は、選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前であるかを調べる（ステップＳ７９０３）。選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前のいずれかでもない場合、第２の変換部７５１は、選んだＨＴＭＬデータの状態を「Ｋｉｌｌｅｄ」に遷移させる（ステップＳ７９０４）。選択したＨＴＭＬデータの状態が「Ｋｉｌｌｅｄ」であるか、あるいは読み込む前のいずれかである場合、第２の変換部７５１は、ステップＳ７９０４の処理をスキップし、ステップＳ７９０５の処理を行う。すなわち、第２の変換部７５１は、ステップＳ７９０２〜ステップＳ７９０４までの処理を全てのＨＴＭＬデータに対して実施する（ステップＳ７９０５）。
【０２４１】
図８０は、第３の変換部７６１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第３の変換部７６１が「フォーマットエンジン停止」メッセージを受け取ると（ステップＳ８００１）、第３の変換部７６１は、メーラー７６０が起動しているかどうかを調べる（ステップＳ８００２）。メーラー７６０が起動していれば、第３の変換部７６１は、メーラー７６０を終了して（ステップＳ８００３）、図８０に示す処理を終了する。一方、メーラー７６０が起動していなければ、第３の変換部７６１は、ステップＳ８００３の処理をスキップして図８０に示す処理を終了する。  以上、図７８〜図８０に示した処理によって、「実行中」の動作状態であったフォーマットエンジンが終了される。図７４の説明に戻り、ステップＳ５またはステップＳ６の次に、ナビゲータ７２０は、ステップＳ２において、起動要求の対象となっているフォーマットエンジンを除く全てのフォーマットエンジンを選択したか否かを判定する（ステップＳ７）。１つでも選択していないフォーマットエンジンがある場合、ナビゲータ７２０は、ステップＳ２の処理を行う。そして、ナビゲータ７２０は、ステップＳ２〜Ｓ７の処理を繰り返す。一方、全てのフォーマットエンジンを選択した場合、ナビゲータ７２０は、起動要求の対象となっているフォーマットエンジンに対する「フォーマットエンジン実行」メッセージを結合部７３０へ送信する（ステップＳ８）。その後、ナビゲータ７２０は、図７４の処理を終了する。
【０２４２】
次に、ステップＳ８の「フォーマットエンジン実行」メッセージを受信した際の各変換部の処理の流れについて説明する。図８１は、第１の変換部７４１が、「フォーマットエンジン実行」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「フォーマットエンジン実行」メッセージを受け取ると（ステップＳ８１０１）、第１の変換部７４１は、実行すべきＪａｖａアプリケーションを決定する（ステップＳ８１０２）。この決定は、例えば、ＡＩＴから最も優先度の高いＪａｖａアプリケーションを選ぶことによって決定される。続いて、第１の変換部７４１は、ステップＳ８１０２において決定したＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８１０３）。当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でなければ、第１の変換部７４１は、当該Ｊａｖａアプリケーションの状態を「Ａｃｔｉｖｅ」に遷移させ（ステップＳ８１０４）、図８１に示す処理を終了する。一方、当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」であれば、第１の変換部７４１は、ステップＳ８１０４の処理をスキップし、図８１に示す処理を終了する。
【０２４３】
なお、「フォーマットエンジン実行」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図８１のフローチャートに準ずる。また、「フォーマットエンジン実行」メッセージを受け取った場合の第３の変換部７６１における処理の流れは、図８０のフローチャートに準ずる。
【０２４４】
以上のように、図７４に示すステップＳ８において送信される「フォーマットエンジン実行」メッセージによって、起動要求の対象であるフォーマットエンジンが起動される。また、その他のフォーマットエンジン（起動要求の対象でないフォーマットエンジン）は「実行中」の状態でなくなるので、極小リソースが競合することを回避することができる。
【０２４５】
なお、図７４のステップＳ６では、ナビゲータ７２０は「フォーマットエンジン停止」メッセージを送信するものとしたが、ナビゲータ７２０は、「フォーマットエンジン一時停止」メッセージを送信してもよい。この場合も、上記その他のフォーマットエンジン（起動要求の対象でないフォーマットエンジン）は「実行中」の状態でなくなるので、極小リソースが競合することを回避することができる。
【０２４６】
次に、「フォーマットエンジン一時停止」メッセージを受信した際の各変換部の処理の流れについて説明する。図８２は、第１の変換部７４１が、「フォーマットエンジン一時停止」メッセージを受け取った際の処理の流れを表すフローチャートである。第１の変換部７４１が「フォーマットエンジン一時停止」メッセージを受け取ると（ステップＳ８２０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションを１つ選択する（ステップＳ８２０２）。続いて、第１の変換部７４１は、選択したＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８２０３）。選択したＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、選んだＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させる（ステップＳ８２０４）。選択したＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、ステップＳ８２０４の処理をスキップし、ステップＳ８２０５の処理を行う。すなわち、第１の変換部７４１は、ステップＳ８２０２〜ステップＳ８２０４までの処理を全てのＪａｖａアプリケーションに対して実施する（ステップＳ８２０５）。
【０２４７】
なお、「フォーマットエンジン一時停止」メッセージを受け取った場合の第２の変換部７５１における処理の流れは、図８２のフローチャートに準ずる。また、「フォーマットエンジン一時停止」メッセージを受け取った場合の第３の変換部７６１における処理の流れは、「フォーマットエンジン停止」メッセージを受け取った場合と同様である。
【０２４８】
（第２の動作例の詳細な動作）
次に、第２の動作例の詳細な動作を説明する。図８３は、第２の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャートである。図８３において、まず、ナビゲータ７２０は、フォーマットエンジンの起動要求を受け付ける（ステップＳ１１）。ステップＳ１１の処理は、第１の動作例におけるステップＳ１と同様である。
【０２４９】
次に、ナビゲータ７２０は、起動要求の対象であるフォーマットエンジンに対する「フォーマットエンジン実行」メッセージを結合部７３０へ送信する（ステップＳ１２）。結合部７３０を介して当該メッセージを受け取った変換部における処理は、上述した第１の動作例と同様である。
【０２５０】
ここで、各フォーマットエンジンは、「フォーマットエンジン実行」メッセージに応じて起動した後、必要に応じてリソースの利用をライブラリ７１２に対して要求する。リソースの利用要求を行うか否かは、各フォーマットエンジン毎に予め定められている。以下では、フォーマットエンジンが極小リソースの利用要求を行ったものとして説明する。なお、フォーマットエンジンが極小リソースの利用要求を行わない場合は、フォーマットエンジンはそのまま動作を続ける。
【０２５１】
ステップＳ１２の次に、ライブラリ７１２は、起動したフォーマットエンジンから極小リソースの利用要求を受け付ける（ステップＳ１３）。なお、この段階では、当該フォーマットエンジンに対して当該極小リソースの利用が許可されたわけではない。続いて、ライブラリ７１２は、極小リソースの利用要求が重複しているか否かを判定する（ステップＳ１４）。ここで、「極小リソースの利用要求が重複する」とは、単一の極小リソースに対して複数の利用要求があったことを意味する。従って、異なる２つの極小リソースの各々に対して利用要求があっても、極小リソースの利用要求が重複したことにはならない。以下、ステップＳ１４における判定処理を詳細に説明する。
【０２５２】
ステップＳ１４において、ライブラリ７１２は、起動要求を行っているフォーマットエンジンをフォーマットエンジン特定部３９０５に問い合わせる。この問い合わせに応じて、フォーマットエンジン特定部３９０５は、プロセス記憶部３９０１を参照することによって、起動要求を行っているフォーマットエンジンを特定する。そして、フォーマットエンジン特定部３９０５は、特定したフォーマットエンジンをライブラリ７１２に通知する。なお、極小リソースをすでに利用しているフォーマットエンジンはすでに特定されている。従って、ライブラリ７１２は、極小リソースをすでに利用しているフォーマットエンジン（これがない場合は重複しないと判定する。）と、フォーマットエンジン特定部３９０５から通知されたフォーマットエンジンとによって、極小リソースの利用要求が重複しているか否かを判定することができる。
【０２５３】
ステップＳ１４において、利用要求が重複していない場合、ライブラリ７１２は、利用要求を行ったフォーマットエンジンに対して極小リソースの利用を許可し（ステップＳ１９）、図８３に示す処理を終了する。
【０２５４】
一方、ステップＳ１４において、利用要求が重複している場合、ライブラリ７１２は、優先度情報を取得する（ステップＳ１５）。具体的には、リソース管理部７３３の優先度情報提供部３９０６に対して、優先度情報の取得を要求する。ここで、優先度情報とは、優先度記憶部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを含む概念である。つまり、優先度情報提供部３９０６は、ライブラリ７１２からの要求に対して、優先度記憶部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを送信する。
【０２５５】
ライブラリ７１２は、優先度情報提供部３９０６から送信されてきた情報を用いて、利用を許可するフォーマットエンジンを決定する（ステップＳ１６）。このステップＳ１６によって、図６に示す許可決定部６１の機能が実現されることになる。なお、ここでは、ステップＳ１６の処理はライブラリが行うこととしたが、利用を許可するフォーマットエンジンを優先度情報提供部３９０６が決定し、決定したフォーマットエンジンをライブラリ７１２へ通知するようにしてもよい。
【０２５６】
ステップＳ１６の処理は、例えば以下のように行われる。なお、ここでは、ステップＳ１１において起動要求を行ったフォーマットエンジンをフォーマットエンジンＡとし、極小リソースをすでに利用していたフォーマットエンジンをフォーマットエンジンＢと呼ぶ。
【０２５７】
ライブラリ７１２は、まず、最新起動情報に基づいて、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡであるか否かを判定する。そして、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡであれば、ライブラリ７１２は、極小リソースの利用を許可するフォーマットエンジンをフォーマットエンジンＡに決定する。一方、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡでなければ、ライブラリ７１２は、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＢであるか否かを判定する。そして、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＢであれば、ライブラリ７１２は、極小リソースの利用を許可するフォーマットエンジンをフォーマットエンジンＢに決定する。すなわち、ライブラリ７１２は、極小リソースの利用を許可するフォーマットエンジンを、ユーザが最近起動したフォーマットエンジンに決定する。
【０２５８】
さらに、ユーザが最近起動したフォーマットエンジンがフォーマットエンジンＡでもフォーマットエンジンＢでもない場合、ライブラリ７１２は、優先度情報記憶部３６０２に記憶されている情報を用いて極小リソースの利用を許可するフォーマットエンジンを決定する。すなわち、ライブラリ７１２は、極小リソースの利用を許可するフォーマットエンジンを、優先度情報記憶部３６０２に記憶されている優先度が高い方のフォーマットエンジンに決定する。
【０２５９】
ステップＳ１６の次に、ライブラリ７１２は、ステップＳ１６において決定したフォーマットエンジンに対して極小リソースの利用を許可する（ステップＳ１７）。続いて、ライブラリ７１２は、ステップＳ１６において決定したフォーマットエンジンでない方のフォーマットエンジンに対してリソースが剥奪された旨の通知を行う（ステップＳ１８）。具体的には、ライブラリ７１２は、リソース剥奪通知を当該フォーマットエンジンに送信するように、リソース管理部７３３のリソース剥奪通知部３９０７に要求する。これに応じてリソース剥奪通知部３９０７がリソース剥奪通知を当該フォーマットエンジンに送信する。ステップＳ１８の後、ライブラリ７１２は、図８３に示す処理を終了する。
【０２６０】
以上の処理によって、極小リソースの利用が許可されなかったフォーマットエンジンに対応する変換部にリソース剥奪通知が送られる。変換部は、このリソース剥奪通知に応じて、以下の処理を行う。
【０２６１】
図８４は、リソース剥奪通知を受け取った変換部における処理の流れを示すフローチャートである。なお、図８４に示す処理は、変換部が行うこととするが、フォーマットエンジンが同じ動作を行ってもよい。まず、変換部は、剥奪されたリソースのリソースＩＤをリソース剥奪通知部３９０７から受け取る（ステップＳ８４０１）。次に、変換部は、フォーマットエンジンが継続して実行可能か否かを判定する（ステップＳ８４０２）。ここで、「フォーマットエンジンが継続して実行可能」とは、「リソース（剥奪されたリソース）がなくても実行可能」という意味である。ステップＳ８４０２において、フォーマットエンジンが継続実行可能な場合、変換部は、そのまま図８４に示す処理を終了する。このとき、リソースが剥奪されたフォーマットエンジンは実行されたままである。
【０２６２】
一方、ステップＳ８４０２において、フォーマットエンジンが継続実行不可能な場合、変換部は、一時停止状態にすれば実行可能か否かを判定する（ステップＳ８４０３）。ステップＳ８４０３において、フォーマットエンジンが継続実行不可能であれば、変換部は、フォーマットエンジンを停止する（ステップＳ８４０４）。一方、フォーマットエンジンが継続実行可能であれば、変換部は、フォーマットエンジンを一時停止する（ステップＳ８４０５）。
【０２６３】
なお、図８４では、停止したり一時停止したりする対象をフォーマットエンジンとしている。ここで、フォーマットエンジンが実行するアプリケーションや表示するデータ（上記のＪａｖａアプリケーションやＨＴＭＬデータ）に状態が規定されている場合、フォーマットエンジンの動作状態を変更するだけでなく、これらのアプリケーションやデータの状態を変更するようにしてもよい。なお、図８４で記載した状態は、共通状態である。変換部は、共通状態の変更をフォーマットエンジンの動作状態に応じて適切に変換し、フォーマットエンジンの状態を遷移させる。
【０２６４】
なお、図８３では、ライブラリ７１２は、優先度情報として、優先度記憶部３９０２に格納されている優先度と、最新起動記憶部３９０３に記憶されている最新起動情報とを用いてステップＳ１６における決定を行った。ここで、ライブラリ７１２は、まず最新起動情報のみを取得し、ユーザが最近起動したフォーマットエンジンが上記フォーマットエンジンＡでもフォーマットエンジンＢでもないとわかった後で、優先度記憶部３９０２に格納されている優先度を取得してもよい。また、ライブラリ７１２は、優先度記憶部３９０２に格納されている優先度のみを用いてステップＳ１６における決定を行ってもよい。以上で、第２の動作例の詳細な動作の説明を終了する。
【０２６５】
（その他の動作例）
なお、上記の構成例では、図７４〜図８４に示したメッセージの他にも、種々のメッセージのやり取りが行われる。以下、図７４〜図８４に示したメッセージ以外のメッセージをやり取りする場合の変換部の処理を説明する。
【０２６６】
図８５は、第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化通知を受けた際の処理の流れを示すフローチャートである。第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化の通知を受けると（ステップＳ８５０１）、第１の変換部７４１は、Ｊａｖａアプリケーションの動作状態に基づいて、Ｊａｖａミドルウェア７４０の共通状態を決定する（ステップＳ８５０２）。さらに、第１の変換部７４１は、１次記憶部１０９に保存している変化前のＪａｖａミドルウェア７４０の共通状態と、ステップＳ８５０２で決定したＪａｖａミドルウェア７４０の共通状態とを比較し、変化前後で共通状態が変化したか否かを判定する（ステップＳ８５０３）。判定の結果、変化した場合、第１の変換部７４１は、「フォーマットエンジン状態変化」メッセージを作成し、結合部７３０に送信する（ステップＳ８５０４）。最後に、第１の変換部７４１は、状態が変化したＪａｖａアプリケーションに関して、「アプリケーション・データ一覧変化」メッセージを作成し、結合部７３０に送信する（ステップＳ８５０５）。
【０２６７】
なお、第２の変換部７５１がＨＴＭＬマネージャ５２０５からＨＴＭＬデータの状態変化通知を受けた際の処理の流れは、図８５に示す処理に準ずる。
【０２６８】
図８６は、第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取ると（ステップＳ８６０１）、第１の変換部７４１は、ＡＩＴからＪａｖａアプリケーションの一覧を取得する（ステップＳ８６０２）。次に、第１の変換部７４１は、各Ｊａｖａアプリケーションの状態をＪａｖａミドルウェア７４０から取得する（ステップＳ８６０３）。第１の変換部７４１は、取得した各Ｊａｖａアプリケーションの状態を、アプリケーション・データの共通状態に変換する（ステップＳ８６０４）。最後に、第１の変換部７４１は、「アプリケーション・データ一覧応答」メッセージを作成し、結合部７３０に送信する（ステップＳ８６０５）。
【０２６９】
なお、第２の変換部７５１が「アプリケーション・データ一覧要求」メッセージを受け取った際の処理の流れは、図８６に示す処理に準ずる。
【０２７０】
図８７は、第１の変換部７４１が、「アプリケーション・データ実行」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ実行」メッセージを受け取ると（ステップＳ８７０１）、第１の変換部７４１は、「アプリケーション・データ実行」メッセージで指定されたＪａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」か否かを判定する（ステップＳ８７０２）。判定の結果、当該Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの動作状態を「Ａｃｔｉｖｅ」に遷移させる（ステップＳ８７０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、図８７に示す処理を終了する。
【０２７１】
なお、第２の変換部７５１が「アプリケーション・データ実行」メッセージを受け取った際の処理の流れは、図８７に示す処理に準ずる。
【０２７２】
図８８は、第１の変換部７４１が、「アプリケーション・データ停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ停止」メッセージを受け取ると（ステップＳ８８０１）、第１の変換部７４１は、「アプリケーション・データ停止」メッセージで指定されたＪａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」であるか否かを判定する（ステップＳ８８０２）。判定の結果、当該Ｊａｖａアプリケーションの状態が「Ｄｅｓｔｒｏｙｅｄ」でない場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの動作状態を「Ｄｅｓｔｒｏｙｅｄ」に遷移させる（ステップＳ８８０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ｄｅｓｔｒｏｙｅｄ」である場合、第１の変換部７４１は、図８８に示す処理を終了する。
【０２７３】
なお、第２の変換部７５１が「アプリケーション・データ停止」メッセージを受け取った際の処理の流れは、図８８に示す処理に準ずる。
【０２７４】
図８９は、第１の変換部７４１が、「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れを示すフローチャートである。第１の変換部７４１が「アプリケーション・データ一時停止」メッセージを受け取ると（ステップＳ８９０１）、第１の変換部７４１は、「アプリケーション・データ一時停止」メッセージで指定されたＪａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」であるか否かを判定する（ステップＳ８９０２）。判定の結果、Ｊａｖａアプリケーションの状態が「Ａｃｔｉｖｅ」である場合、第１の変換部７４１は、指定されたＪａｖａアプリケーションの状態を「Ｐａｕｓｅｄ」に遷移させる（ステップＳ８９０３）。一方、当該Ｊａｖａアプリケーションの動作状態が「Ａｃｔｉｖｅ」でない場合、第１の変換部７４１は、図８９に示す処理を終了する。
【０２７５】
なお、第２の変換部７５１が「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れは、図８９に示す処理に準ずる。
【０２７６】
図９０は、第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けた際の処理の流れを示すフローチャートである。第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けると（ステップＳ９００１）、第３の変換部７６１は、「フォーマットエンジン状態変化」メッセージを作成し、結合部７３０に送信する（ステップＳ９００２）。
【０２７７】
図９１は、結合部７３０が「フォーマットエンジン状態変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。まず、結合部７３０は、「フォーマットエンジン状態変化」メッセージを受け取る（ステップＳ９１０１）。次に、結合部７３０は、受け取ったメッセージ内のＳｏｕｒｃｅ  ＩＤフィールドを参照することによって、状態が変化したフォーマットエンジンを特定し、特定したフォーマットエンジンに対する「フォーマットエンジン状態要求」メッセージを送信する（ステップＳ９１０２）。その結果、結合部７３０の状態管理部７３２は、「フォーマットエンジン状態応答」メッセージを受け取り（ステップＳ９１０３）、フォーマットエンジンの状態を１次記憶部１０９に記憶する（ステップＳ９１０４）。
【０２７８】
図９２は、結合部７３０が「アプリケーション・データ一覧変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャートである。まず、結合部７３０は、「アプリケーション・データ一覧変化」メッセージを受け取る（ステップＳ９２０１）。次に、結合部７３０は、受け取ったメッセージ内のＳｏｕｒｃｅ  ＩＤフィールドを参照することによって、状態が変化したアプリケーションを実行またはデータを表示しているフォーマットエンジンを特定し、特定したフォーマットエンジンに対する「アプリケーション・データ一覧要求」メッセージを送る（ステップＳ９２０２）。その結果、結合部７３０の状態管理部７３２は、「アプリケーション・データ一覧応答」メッセージを受け取り（ステップＳ９２０３）、アプリケーション・データの状態を１次記憶部１０９に記憶する。
【０２７９】
なお、以上において、ナビゲータ７２０が状態管理部７３２の機能を有することによって、状態管理部７３２を結合部７３０から削除してもよい。このような構成にすると、ナビゲータ７２０が全てのフォーマットエンジンの状態を管理することになる。
【０２８０】
また、本構成例にいて、各フォーマットエンジンは、送られてきたメッセージの発信元に対して、何ら制限をかけない。従って、フォーマットエンジンは、他のフォーマットエンジンの動作状態や、フォーマットエンジンが実行しているアプリケーションや、表示しているデータの状態を変化させることが可能である。例えば、Ｊａｖａミドルウェア７４０が、ＨＴＭＬブラウザ７５０に対して、「フォーマットエンジン実行」メッセージを送信することによって、ＨＴＭＬブラウザ７５０は停止させることができることは明らかである。
【０２８１】
また、本構成例では、ＲＯＭ１１０が保存する内容を２次記憶部１０８が保存することで、ＲＯＭ１１０を用いない構成とすることも可能である。また、２次記憶部１０８は、複数のサブ２次記憶部で構成し、個々のサブ２次記憶部が異なる情報を保存する構成としてもよい。例えば、あるサブ２次記憶部は状態管理部７３２が記憶するフォーマットエンジンの状態を記憶し、別のサブ２次記憶部は第１の変換部７４１が記憶するＪａｖａミドルウェア７４０の状態を記憶し、さらに別のサブ２次記憶部は、第２の変換部７５１が記憶するＨＴＭＬブラウザ７５０の状態を記憶するようにしてもよい。このように、各記憶部を詳細に分割することが可能である。
【０２８２】
以上のように、本実施形態によれば、複数のフォーマットエンジンを結合する際、結合部７３０とフォーマットエンジンとを繋ぐ変換部を用いることによって、個々のフォーマットエンジンの実装を大きく改造する必要がない。そのため、少ない工数で複数のフォーマットエンジンを結合できる。
【０２８３】
また、結合部７３０が規定する共通状態を用いることによって、結合するフォーマットエンジンが増えた場合であっても、ナビゲータ７２０は、メッセージの送り先を増やすだけよく、追加されたフォーマットエンジンに容易に対応することができる。
【０２８４】
また、共通状態を用いることによって、ナビゲータ７２０および結合部７３０は、複数のフォーマットエンジンの状態を容易に把握できる。従って、複数のフォーマットエンジンの管理を容易に行うことができる。具体的には、複数のフォーマットエンジンを同時に制御することが容易になる。
【０２８５】
図９３は、フォーマットエンジンを実行しても、他のフォーマットエンジンに大きな影響を与えない状況の組み合わせを示す図である。図９３に示すように、全てのフォーマットエンジンが停止中あるいは一時停止中ということは、極小リソースを使用しているフォーマットエンジンがないことを意味する。従って、図９３に示す状況にある場合、任意のフォーマットエンジンを起動することができる。例えば図９３に示す状況においては、Ｊａｖａミドルウェア７４０およびＨＴＭＬブラウザ７５０を停止することなく、メーラー７６０を実行することができる。
【０２８６】
なお、結合部７３０において共通状態が規定されていない場合、ナビゲータ７２０は、個々のフォーマットエンジンが規定する独自の状態の組み合わせを把握する必要があることになる。従って、この場合、ナビゲータ７２０は、同時実行が可能な状況を判断することが非常に困難となる。特に、本構成例ではＪａｖａミドルウェア７４０およびＨＴＭＬブラウザ４５０については、実行するアプリケーションおよび表示するデータの状態は規定されているが、フォーマットエンジンとしての状態は規定されていない。従って、上記の場合には、ナビゲータ７２０は、Ｊａｖａミドルウェア７４０が実行するＪａｖａアプリケーションおよびＨＴＭＬブラウザ４５０が表示するデータが取り得る全ての状態の組み合わせを把握する必要がある。また、本構成例で取り上げたＪａｖａミドルウェア７４０、ＨＴＭＬブラウザ７５０、およびメーラー７６０以外のフォーマットエンジンがさらに追加される場合には、追加するフォーマットエンジンが規定する状態の組み合わせをさらに考慮する必要があるので、ますます、複数のフォーマットエンジンの管理が困難となる。
【産業上の利用可能性】
【０２８７】
以上においてはデジタルテレビを実施の形態の一例として記載したが、本発明は、デジタルテレビに限らずパーソナルコンピュータや携帯電話、情報形態端末等、複数のフォーマットエンジンを動作させる情報処理装置に利用することができる。
【図面の簡単な説明】
【０２８８】
【図１】本実施の形態に係る情報処理装置の一例であるデジタルテレビのハードウェア構成を表すブロック図
【図２】図１に示すデジタルテレビ１００の外観を示す図
【図３】入力部１１１を構成するフロントパネルの一例を示す図
【図４】第１の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図
【図５】テーブル格納部４４が格納するテーブルの一例を示す図
【図６】第２の動作例を行う場合における、図１に示すデジタルテレビの機能的な構成を示すブロック図
【図７】情報処理装置の機能的な構成をより具体的に示す図
【図８】ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図
【図９】ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図
【図１０】ディスプレイ１０７に表示されるフォーマットエンジンの一覧の例を示す図
【図１１】ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図
【図１２】ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の例を示す図
【図１３】ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図
【図１４】ディスプレイ１０７に表示される、実行可能なアプリケーションの一覧の他の例を示す図
【図１５】ディスプレイ１０７に表示される、実行可能なＨＴＭＬデータの一覧の例を示す図
【図１６】ディスプレイ１０７に表示される、実行可能なＨＴＭＬデータの一覧の例を示す図
【図１７】メッセージフォーマットの一例を示す図
【図１８】サブプログラムＩＤの表の一例を示す図
【図１９】Ｍｅｓｓａｇｅ  ＩＤフィールド１７３に格納されるメッセージＩＤの表の一例を示す図
【図２０】フォーマットエンジン状態応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図
【図２１】フォーマットエンジンの動作状態と動作状態ＩＤとの対応を示す表の一例を示す図
【図２２】アプリケーション・データ一覧応答メッセージにおけるデータフィールド１７５のフォーマットの一例を示す図
【図２３】「アプリケーション・データ実行」「アプリケーション・データ停止」「アプリケーション・データ一時停止」のメッセージにおけるデータフィールド１７５のフォーマットの一例を示す図
【図２４】「フォーマットエンジン状態要求」メッセージの具体例を示す図
【図２５】「フォーマットエンジン状態要求」メッセージの具体例を示す図
【図２６】「フォーマットエンジン状態要求」メッセージの具体例を示す図
【図２７】「フォーマットエンジン状態応答」メッセージの具体例を示す図
【図２８】「フォーマットエンジン状態応答」メッセージの具体例を示す図
【図２９】「フォーマットエンジン状態応答」メッセージの具体例を示す図
【図３０】アプリケーション・データ一覧要求」メッセージの具体例を示す図
【図３１】「アプリケーション・データ一覧応答」メッセージの具体例を示す図
【図３２】状態管理部７３２が保持している情報の一例を示す図
【図３３】状態管理部７３２が保持している情報の一例を示す図
【図３４】状態管理部７３２が保持している情報の一例を示す図
【図３５】「フォーマットエンジン状態変化」メッセージの一例を示す図
【図３６】状態管理部７３２が送信するメッセージの一例を示す図
【図３７】メーラー７６０が送信するメッセージの一例を示す図
【図３８】図３２の変化後の状態を示す図
【図３９】リソース管理部７３３の内部構成を示すブロック図
【図４０】プロセス記憶部３９０１において記憶されている情報の一例を示す図
【図４１】優先度記憶部３９０２に記憶されている情報の一例を示す図
【図４２】最新起動記憶部３９０３が記憶している情報の一例を示す図
【図４３】リソースＩＤ記憶部３９０４が記憶している情報の一例を示す図
【図４４】リソースＩＤの定義をプログラミング言語であるＣ言語で記述した例を示す図
【図４５】Ｊａｖａミドルウェア７４０の構成を示すブロック図
【図４６】ＡＩＴの主要部を表した模式図
【図４７】Ｊａｖａアプリケーションの４つの動作状態および動作状態間の遷移を表す状態遷移図
【図４８】ＡＩＴの主要部を表した模式図
【図４９】Ｊａｖａミドルウェア７４０が実行可能な全てのＪａｖａアプリケーションの動作状態と、Ｊａｖａミドルウェア７４０の動作状態との対応を示す変換表の一例を示す図
【図５０】各Ｊａｖａアプリケーションの動作状態を共通状態に変換するための変換表の一例を示す図
【図５１】第１の変換部７４１が送信するメッセージの具体例を示す図
【図５２】ＨＴＭＬブラウザ７５０の構成を示すブロック図
【図５３】ＤＶＢ−ＨＴＭＬデータの一例を示す図
【図５４】ＤＶＢ−ＨＴＭＬデータのレイアウトを決めるスタイルシートの一例を示す図
【図５５】ＤＯＭツリーの例を示す図
【図５６】図５５に示すＤＯＭツリーを描画した際のディスプレイ１０７を示す図
【図５７】ＤＶＢ−ＨＴＭＬデータの例を示す図
【図５８】ＤＶＢ−ＨＴＭＬデータの例を示す図
【図５９】図５８に示すＤＶＢ−ＨＴＭＬデータに対してパーザー５２０１が構築したＤＯＭツリーの一部を示す図
【図６０】レイアウター５２０２および描画部５２０３によって表示されたディスプレイ表示の例を示す図
【図６１】ＤＯＭツリーの変更結果を示す図
【図６２】ディスプレイ表示の変更結果の例を示す図
【図６３】ＡＩＴの主要部を表した模式図
【図６４】ＤＶＢ−ＨＴＭＬデータの５つの状態および状態間の遷移を表す状態遷移図
【図６５】ＡＩＴの主要部を表した模式図
【図６６】ＤＶＢ−ＨＴＭＬデータ内に他のＤＶＢ−ＨＴＭＬデータへのリンクが定義されている例を示す図
【図６７】図６６に示すＤＶＢ―ＨＴＭＬデータの表示例を示す図
【図６８】ＤＶＢ−ＨＴＭＬデータの表示例を示す図
【図６９】ＨＴＭＬブラウザ７５０が表示可能な全てのＨＴＭＬデータの状態と、ＨＴＭＬブラウザ７５０の動作状態との対応を示す変換表の一例を示す図
【図７０】各ＨＴＭＬデータの状態を共通状態に変換するための変換表の一例を示す図
【図７１】第２の変換部７５１が送信するメッセージの具体例を示す図
【図７２】メーラー７６０の状態と、結合部７３０が規定している共通状態との対応を示す変換表の一例を示す図
【図７３】第３の変換部７６１が生成する「アプリケーション・データ一覧応答」メッセージの具体例を示す図
【図７４】第１の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャート
【図７５】通信部７３１が行うメッセージ送信の処理の流れを示すフローチャート
【図７６】第１の変換部７４１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャート
【図７７】第３の変換部７６１が「フォーマットエンジン状態要求」メッセージを受け取ったときの処理の流れを示すフローチャート
【図７８】第１の変換部７４１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを表すフローチャート
【図７９】第２の変換部７５１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャート
【図８０】第３の変換部７６１が、「フォーマットエンジン停止」メッセージを受け取った際の処理の流れを示すフローチャート
【図８１】第１の変換部７４１が、「フォーマットエンジン実行」メッセージを受け取った際の処理の流れを示すフローチャート
【図８２】第１の変換部７４１が、「フォーマットエンジン一時停止」メッセージを受け取った際の処理の流れを表すフローチャート
【図８３】第２の動作例の動作を行う場合におけるデジタルテレビにおける処理の流れを示すフローチャート
【図８４】リソース剥奪通知を受け取った変換部における処理の流れを示すフローチャート
【図８５】第１の変換部７４１がアプリケーションマネージャ４５０３からＪａｖａアプリケーションの状態変化通知を受けた際の処理の流れを示すフローチャート
【図８６】第１の変換部７４１が「アプリケーション・データ一覧要求」メッセージを受け取った際の処理の流れを示すフローチャート
【図８７】第１の変換部７４１が、「アプリケーション・データ実行」メッセージを受け取った際の処理の流れを示すフローチャート
【図８８】第１の変換部７４１が、「アプリケーション・データ停止」メッセージを受け取った際の処理の流れを示すフローチャート
【図８９】第１の変換部７４１が、「アプリケーション・データ一時停止」メッセージを受け取った際の処理の流れを示すフローチャート
【図９０】第３の変換部７６１がメーラー７６０が終了したことの通知をメーラー７６０から受けた際の処理の流れを示すフローチャート
【図９１】結合部７３０が「フォーマットエンジン状態変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャート
【図９２】結合部７３０が「アプリケーション・データ一覧変化」メッセージを受け取った場合の結合部７３０の状態管理部７３２の処理の流れを示すフローチャート
【図９３】フォーマットエンジンを実行しても、他のフォーマットエンジンに大きな影響を与えない状況の組み合わせを示す図
【図９４】従来のデジタル放送受信機の構成図の一例を示す図
【図９５】従来のデジタルテレビにおいて用いられるミドルウェア切替装置の構成図
【符号の説明】
【０２８９】
４１  フォーマットエンジン管理部
４２  第１の変換部
４３  第２の変換部
４４  第１のテーブル格納部
４５  第１のフォーマットエンジン
４６  第２のフォーマットエンジン
４７  リソース制御部
４８  リソース
４９  第２のテーブル格納部
１００  デジタルテレビ
１０１  チューナ
１０２  デスクランブラ
１０３  ＴＳデコーダ
１０４  オーディオデコーダ
１０５  スピーカ
１０６  ビデオデコーダ
１０７  ディスプレイ
１０８  ２次記憶部
１０９  １次記憶部
１１０  ＲＯＭ
１１１  入力部
１１２  ネットワークインターフェース
１１３  ＣＰＵ                                                                            
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2004034698.tif 000098
【図２】
2004034698.tif 000099
【図３】
2004034698.tif 000100
【図４】
2004034698.tif 000101
【図５】
2004034698.tif 000102
【図６】
2004034698.tif 000103
【図７】
2004034698.tif 000104
【図８】
2004034698.tif 000105
【図９】
2004034698.tif 000106
【図１０】
2004034698.tif 000107
【図１１】
2004034698.tif 000108
【図１２】
2004034698.tif 000109
【図１３】
2004034698.tif 000110
【図１４】
2004034698.tif 000111
【図１５】
2004034698.tif 000112
【図１６】
2004034698.tif 000113
【図１７】
2004034698.tif 000114
【図１８】
2004034698.tif 000115
【図１９】
2004034698.tif 000116
【図２０】
2004034698.tif 000117
【図２１】
2004034698.tif 000118
【図２２】
2004034698.tif 000119
【図２３】
2004034698.tif 000120
【図２４】
2004034698.tif 000121
【図２５】
2004034698.tif 000122
【図２６】
2004034698.tif 000123
【図２７】
2004034698.tif 000124
【図２８】
2004034698.tif 000125
【図２９】
2004034698.tif 000126
【図３０】
2004034698.tif 000127
【図３１】
2004034698.tif 000128
【図３２】
2004034698.tif 000129
【図３３】
2004034698.tif 000130
【図３４】
2004034698.tif 000131
【図３５】
2004034698.tif 000132
【図３６】
2004034698.tif 000133
【図３７】
2004034698.tif 000134
【図３８】
2004034698.tif 000135
【図３９】
2004034698.tif 000136
【図４０】
2004034698.tif 000137
【図４１】
2004034698.tif 000138
【図４２】
2004034698.tif 000139
【図４３】
2004034698.tif 000140
【図４４】
2004034698.tif 000141
【図４５】
2004034698.tif 000142
【図４６】
2004034698.tif 000143
【図４７】
2004034698.tif 000144
【図４８】
2004034698.tif 000145
【図４９】
2004034698.tif 000146
【図５０】
2004034698.tif 000147
【図５１】
2004034698.tif 000148
【図５２】
2004034698.tif 000149
【図５３】
2004034698.tif 000150
【図５４】
2004034698.tif 000151
【図５５】
2004034698.tif 000152
【図５６】
2004034698.tif 000153
【図５７】
2004034698.tif 000154
【図５８】
2004034698.tif 000155
【図５９】
2004034698.tif 000156
【図６０】
2004034698.tif 000157
【図６１】
2004034698.tif 000158
【図６２】
2004034698.tif 000159
【図６３】
2004034698.tif 000160
【図６４】
2004034698.tif 000161
【図６５】
2004034698.tif 000162
【図６６】
2004034698.tif 000163
【図６７】
2004034698.tif 000164
【図６８】
2004034698.tif 000165
【図６９】
2004034698.tif 000166
【図７０】
2004034698.tif 000167
【図７１】
2004034698.tif 000168
【図７２】
2004034698.tif 000169
【図７３】
2004034698.tif 000170
【図７４】
2004034698.tif 000171
【図７５】
2004034698.tif 000172
【図７６】
2004034698.tif 000173
【図７７】
2004034698.tif 000174
【図７８】
2004034698.tif 000175
【図７９】
2004034698.tif 000176
【図８０】
2004034698.tif 000177
【図８１】
2004034698.tif 000178
【図８２】
2004034698.tif 000179
【図８３】
2004034698.tif 000180
【図８４】
2004034698.tif 000181
【図８５】
2004034698.tif 000182
【図８６】
2004034698.tif 000183
【図８７】
2004034698.tif 000184
【図８８】
2004034698.tif 000185
【図８９】
2004034698.tif 000186
【図９０】
2004034698.tif 000187
【図９１】
2004034698.tif 000188
【図９２】
2004034698.tif 000189
【図９３】
2004034698.tif 000190
【図９４】
2004034698.tif 000191
【図９５】
2004034698.tif 000192
【国際調査報告】
2004034698.tif 000193
2004034698.tif 000194