(57)【特許請求の範囲】
【請求項１】
選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、
キャッシュ手段と、
ユーザからサービスの選択を受け付ける受付手段と、
放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段に書き込む受信手段と、
前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断手段と、
前記ファイルをキャッシュしていると判断すれば、前記キャッシュ手段にキャッシュされたアプリケーションプログラムを実行させる実行制御手段と、
を含むアプリケーションプログラム実行装置。
【請求項２】
前記実行制御手段は、アプリケーションプログラムの実行時において、ファイル読み込みが失敗しないことを保障する必要があるか否かを示すキャッシュ保障属性情報を取得する取得手段を含み、
前記実行制御手段は、前記取得手段により取得されたキャッシュ保障属性情報が保障する必要がある旨を示す場合に限り実行制御する、請求項１記載のアプリケーションプログラム実行装置。
【請求項３】
前記実行制御手段は、複数のアプリケーションプログラムが存在する場合に、どのアプリケーションプログラムにリソースを優先的に配分するかを示すプライオリティ属性情報を取得する取得手段を含み、
前記実行制御手段は、前記取得手段により取得されたプライオリティ属性情報が既定の閾値以上の場合に限り実行制御する、請求項１記載のアプリケーションプログラム実行装置。
【請求項４】
前記実行制御手段は、アプリケーションプログラムが前記サービスでのみ実行可能か否かを示すサービスバウンド属性情報を取得する取得手段を含み、
前記実行制御手段は、前記取得手段により取得されたサービスバウンド属性情報が前記サービスでのみ実行可能である旨を示す情報である場合に限り実行制御する、請求項１記載のアプリケーションプログラム実行装置。
【請求項５】
前記判断手段による判断は、アプリケーションプログラムを構成する全ファイルに関する情報に基づいて行われる、請求項１記載のアプリケーションプログラム実行装置。
【請求項６】
前記実行制御手段は、前記情報において、前記アプリケーションプログラムを構成するファイルを含んでいるディレクトリであるか否かを示すディレクトリ属性を抽出する抽出手段を含み、
前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルとは、前記抽出手段により抽出されたディレクトリ属性が、当該アプリケーションプログラムのファイルを含んでいる旨を示すディレクトリ内のファイルである
請求項５記載のアプリケーションプログラム実行装置。
【請求項７】
選択したサービス内でのみ実行可能なアプリケーションプログラムを実行する処理をコンピュータに行わせるコンピュータ読み取り可能なプログラムであって、
ユーザからサービスの選択を受け付ける受付手順と、
放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記コンピュータに書き込む受信手順と、
前記コンピュータが前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断手順と、
前記ファイルをキャッシュしていると判断すれば、前記コンピュータにキャッシュされたアプリケーションプログラムを実行させる実行制御手順と、
をコンピュータに行わせるコンピュータ読み取り可能なプログラム。
【請求項８】
選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行方法であって、
ユーザからのサービスの選択の受け付けと、
放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルの受信と、
受信したファイルのコンピュータのキャッシュメモリへの書き込みと、
前記キャッシュメモリが前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かの判断と、
前記ファイルをキャッシュしているという判断の場合、前記キャッシュメモリにキャッシュされたアプリケーションプログラムの実行制御と、
を含むアプリケーションプログラム実行方法。
【請求項９】
選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、
キャッシュ手段と、
ユーザからサービスの選択を受け付ける受付手段と、
放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段に書き込む受信手段と、
前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かをチェックするインターフェイス手段とを含み、
前記アプリケーションプログラムは、メインルーチンが起動されると前記インターフェイス手段を通じて、前記キャッシュ手段がアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かをチェックし、キャッシュされていなければキャッシュされるまで実行を待機し、キャッシュされると実行を継続する
アプリケーションプログラム実行装置。
【請求項１０】
所定のサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、
キャッシュ手段と、
前記所定のサービスに係るアプリケーションプログラムを構成するファイルを記録媒体から読み出し、前記キャッシュ手段に書き込む書き込み手段と、
前記キャッシュ手段が前記所定のサービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断手段と、
前記ファイルをキャッシュしていると判断すれば、前記キャッシュ手段にキャッシュされたアプリケーションプログラムを実行させる実行制御手段と、
を含むアプリケーションプログラム実行装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、欧州デジタル放送規格(DVB-MHP(Digital Video BroadcastingMultimedia Home Platform))に対応するアプリケーションプログラム実行装置に関する。
【背景技術】
【０００２】
DVB-MHPでは、放送装置は複数のアプリケーションプログラム（以下、「アプリ」という）を定義して放送することが可能であり、アプリケーションプログラム実行装置（以下、「アプリ実行装置」という）（デジタルTV、STB等）は、受信した複数のアプリを同時に実行できる。アプリは複数のクラスファイルと、複数のデータファイルとから構成され、アプリを構成するそれらのファイルはトランスポートストリーム（以下、「TS」という）に多重化され、放送される。
【０００３】
アプリの伝送方式には、オブジェクトカルーセルが用いられる。オブジェクトカルーセルとは、TS内で配送されるファイルシステムであり、DVB-MHPにおいて、アプリを構成するファイルを配送するための手段である。オブジェクトカルーセルでは、アプリを構成する各ディレクトリやファイルの階層構造を定期的に送信する。
具体的に説明すると、放送装置はまず、送信するサービスにおいて、Root直下に属するディレクトリ及びファイルのみをアプリ実行装置に送信する。続いて、それぞれのディレクトリに属するディレクトリ及びファイルを逐次送信する。アプリ実行装置は、それらを逐次キャッシュしていく。そして、そのアプリを構成する全ファイルがキャッシュされていなくても（例えば、mainルーチンにあたるクラスファイルを含むディレクトリの下位に属するディレクトリがまだキャッシュされていない状態）、アプリの起動に必要な最小限のファイルがあれば当該アプリは実行される。例えば、mainルーチンにいたるまでのファイルパスがキャッシュ上にそろっていると、mainルーチンにあたるクラスファイルはロードされ、そのインスタンスが実行されれば、アプリは実行される。
【０００４】
なお、先行技術としては特許文献１に記載されたものがある。
【特許文献１】
特開２０００−３５８２３３号公報
【非特許文献１】
規格書（ファイル名；Ts101812.V1.2.1.pdf  ドキュメント名；Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP)Specification 1.0.2）  第３９頁  ２００４年９月９日現在、http://www.mhp.org/からダウンロード可能
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、アプリの構成ファイルの一部だけがメモリ上にキャッシュされた状態でアプリが動作している場合に、ユーザ操作、またはアプリによる操作によりサービスの切り替えが生じる場合がある。そのサービスの切り替えが、当該アプリを送信しているTSから他のTSへのチューニングを伴い、かつ、当該アプリの起動が許可されないサービスへの切り替えである場合に問題となる。
【０００６】
前述のようなサービス切り替えが生じると、アプリの終了処理が実行されるが、MHP仕様では、アプリは終了処理を記述可能であり、アプリ実行装置はアプリを終了する際にはそのアプリの終了処理を実行する。かかる終了処理において、未キャッシュのクラスファイルが必要になる場合がある。例えば、終了処理が独立したクラスファイルで記述されている場合等である。このとき、終了処理に関するクラスファイルがキャッシュされていないので、終了処理においてエラーが発生する。
【０００７】
つまり、終了処理において、動作中の一部のアプリがmainルーチンである場合は、プログラムが使用しているローカル変数等をスタックに退避させ、動作再開に備えるための処理であるsuspend処理を行うが、クラスファイルが未キャッシュであると、正常にsuspend処理が行われない。mainルーチンが何らかの設定をユーザから受け付けていた場合、suspend処理の異常により、mainルーチンにおけるユーザ設定が消失する可能性がある。ユーザ設定が消失すると、サービス切り替え前の元のサービスが再び選択された場合に、ユーザは改めて設定を入力しなければならない。また、端末装置がフリーズ、またはダウンすることも考えられる。ここで、suspend処理を実行するにあたり、mainルーチンが、クラスファイルが未キャッシュであるか否かのチェックを行えば、かかるユーザ設定の消失、及びアプリがフリーズ、またはダウンすることは避けられる。しかし、この場合、mainルーチンのコードが増大し、mainルーチンのロードに多大な時間がかかるという別の問題が生じる。
【０００８】
本発明は上記問題に鑑みてなされたものであって、アプリの終了処理の安定をロード時間の長期化を避けつつ実現することができるアプリ実行装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明は、選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、キャッシュ手段と、ユーザからサービスの選択を受け付ける受付手段と、放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段に書き込む受信手段と、前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断手段と、前記ファイルをキャッシュしていると判断すれば、前記キャッシュ手段にキャッシュされたアプリケーションプログラムを実行させる実行制御手段と、を含むアプリケーションプログラム実行装置である。
【発明の効果】
【００１０】
本発明は、上記の構成を備えることにより、前記キャッシュ手段が前記サービスにおけるアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュするまでは、アプリケーションプログラムは実行されない。よって、アプリケーションプログラムの終了処理において、正常にsuspend処理を実行することができる。
【００１１】
ここで、前記実行制御手段は、アプリケーションプログラムの実行時において、ファイル読み込みが失敗しないことを保障する必要があるか否かを示すキャッシュ保障属性情報を取得する取得手段を含み、前記実行制御手段は、前記取得手段により取得されたキャッシュ保障属性情報が保障する必要がある旨を示す場合に限り実行制御する、としても良い。
【００１２】
これにより、前記実行制御手段は、キャッシュ保障属性情報がアプリケーションプログラムの実行時において、ファイル読み込みが失敗しないことを保障する必要の有る旨を示す場合に限り実行制御する。つまり、キャッシュ保障属性情報によりアプリケーションプログラムの特質に適した動作を選択することができる。
ここで、前記実行制御手段は、複数のアプリケーションプログラムが存在する場合に、どのアプリケーションプログラムにリソースを優先的に配分するかを示すプライオリティ属性情報を取得する取得手段を含み、前記実行制御手段は、前記取得手段により取得されたプライオリティ属性情報が既定の閾値以上の場合に限り実行制御する、としても良い。
【００１３】
これにより、前記実行制御手段は、プライオリティ属性情報が既定の閾値以上の場合に限り実行制御する。つまり、プライオリティ属性情報によりアプリケーションプログラムの特質に適した動作を選択することができる。
ここで、前記実行制御手段は、アプリケーションプログラムが前記サービスでのみ実行可能か否かを示すサービスバウンド属性情報を取得する取得手段を含み、前記実行制御手段は、前記取得手段により取得されたサービスバウンド属性情報が前記サービスでのみ実行可能である旨を示す情報である場合に限り実行制御する、としても良い。
【００１４】
これにより、前記実行制御手段は、サービスバウンド属性情報が、前記アプリケーションプログラムが前記サービスでのみ実行可能である旨を示す情報である場合に限り実行制御する。つまり、サービスバウンド属性情報によりアプリケーションプログラムの特質に適した動作を選択することができる。
ここで、前記判断手段による判断は、アプリケーションプログラムを構成する全ファイルに関する情報に基づいて行われる、としても良い。
【００１５】
これにより、サスペンド処理を実行するために必要なファイルがキャッシュされているか否かを判断することができる。
ここで、前記実行制御手段は、前記情報において、前記アプリケーションプログラムを構成するファイルを含んでいるディレクトリであるか否かを示すディレクトリ属性を抽出する抽出手段を含み、前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルとは、前記抽出手段により抽出されたディレクトリ属性が、当該アプリケーションプログラムのファイルを含んでいる旨を示すディレクトリ内のファイルであるとしても良い。
【００１６】
これにより、ディレクトリ属性に従い、当該アプリケーションプログラムを構成するファイルを含んでいる旨を示すディレクトリ内のサスペンド処理を実行するために必要なファイルがキャッシュされれば、前記実行制御手段は当該アプリケーションプログラムを実行させる。よって、例えば複数のアプリが存在する場合であっても、ディレクトリ属性に示されるディレクトリ内のサスペンド処理を実行するために必要なファイルをキャッシュすれば良いので、より早くアプリケーションプログラムを起動することができる。
【００１７】
ここで、選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、キャッシュ手段と、ユーザからサービスの選択を受け付ける受付手段と、放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段に書き込む受信手段と、前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かをチェックするインターフェイス手段とを含み、前記アプリケーションプログラムは、メインルーチンが起動されると前記インターフェイス手段を通じて、前記キャッシュ手段がアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かをチェックし、キャッシュされていなければキャッシュされるまで実行を待機し、キャッシュされると実行を継続するアプリケーションプログラム実行装置としても良い。
【００１８】
これにより、アプリケーションプログラムは前記インターフェイス手段を通じて、前記キャッシュ手段がサスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断することができる。キャッシュするまでは実行を待機することにより、終了処理において、正常にsuspend処理を実行することを保障することができる。
ここで、所定のサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、キャッシュ手段と、前記所定のサービスに係るアプリケーションプログラムを構成するファイルを記録媒体から読み出し、前記キャッシュ手段に書き込む書き込み手段と、前記キャッシュ手段が前記所定のサービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断手段と、前記ファイルをキャッシュしていると判断すれば、前記キャッシュ手段にキャッシュされたアプリケーションプログラムを実行させる実行制御手段と、を含むアプリケーションプログラム実行装置としても良い。
【００１９】
これにより、アプリケーションプログラムを構成するファイルを記録媒体から読み出した場合であっても、サスペンド処理を実行するために必要なファイルをキャッシュするまでは、アプリケーションプログラムは実行されない。よって、アプリケーションプログラムの終了処理において、正常にsuspend処理を実行することができる。
【発明を実施するための最良の形態】
以下、本発明の実施の形態について、図面を参照しながら説明する。
（第一実施形態）
本発明に係るアプリ実行装置の実施形態について説明する。先ず始めに、本発明に係るアプリ実行装置の実施行為のうち、使用行為についての形態を説明する。本実施形態に係るアプリ実行装置は、図１に示すようなデジタル放送システムでユーザの使用に供される。図１に示すデジタル放送システムは、DVB-MHPに代表されるデジタル放送規格に準拠した従来のデジタル放送システムをベースにしており、アプリ実行装置１０と、放送装置２０とから構成される。
【００２０】
放送装置２０は、MPEG2(Motion Picture Experts Group phase2)形式のTSを、放送チャネルを使って放送する。TSには放送番組の構成要素が多重化されている。放送番組は少なくとも、１つ以上のアプリを構成要素として含んでおり、一般的には、映像データ及び音声データも構成要素として含む。アプリは複数のクラスファイルと、複数のデータファイルとから構成される。アプリの伝送方式には、オブジェクトカルーセルが用いられる。
【００２１】
アプリ実行装置１０は、放送装置２０より受信したTSから分離した各アプリを実行する。一般的には、さらに映像データ及び音声データを再生し、出力する。
以上がアプリ実行装置１０の使用行為についての形態である。続いて、アプリ実行装置１０の生産行為の形態について説明する。
＜構成＞
図２は、アプリ実行装置１０の構成を示す機能ブロック図である。図２に示すようにアプリ実行装置１０は、サービス受付部１０１と、受信部１０２と、分離部１０３と、アプリ管理部１０４と、カルーセル記憶部１０７と、アプリ実行部１０８と、デコード部１０９と、出力部１１０とを含んで構成される。
【００２２】
サービス受付部１０１は、サービス選択を管理する。具体的には、リモコン信号からのユーザの指示やアプリからの指示によるサービスの変更要求を受け取り、受信部１０２に通知する。
受信部１０２は、選択されたサービスが配信されているTSの搬送波の周波数における信号をアンテナやケーブルから受信し、復調する。そして分離部１０３に復調したTSを送出する。ここで、信号をデジタル回線から取得するアプリ実行装置である場合には復調機能は省略される。
【００２３】
分離部１０３は、受信部１０２より送出されたTSを受け取ると、TSに多重化されているビデオ・オーディオデータと、オブジェクトカルーセルと、アプリの制御に関する情報であるAIT(Application Information Table)とに分離する。そして、ビデオ・オーディオデータをデコード部１０９に、オブジェクトカルーセルをカルーセル記憶部１０７に、アプリの制御に関する情報であるAITをアプリ制御部１０５にそれぞれ提供する。
【００２４】
アプリ管理部１０４は、アプリのライフサイクルの管理を行う。アプリ管理部１０４は、アプリ制御部１０５と、キャッシュ完了監視部１０６とを含んで構成される。
アプリ制御部１０５は、AITの中からサービス受付部１０１より通知されたサービスにおいて起動すべきアプリに関する情報を抽出する。また、キャッシュ完了監視部１０６からのキャッシュ完了通知を待ってから、アプリ実行部１０８にアプリの実行開始指示を行う。また、キャッシュ完了監視部１０６に抽出したアプリに関する情報を渡す。ここで具体的には、AITから抽出されるアプリに関する情報は、図３に示すようにbase_directory３０１と、initial_class３０２と、classpath_extension３０３とから構成される。
【００２５】
base_directoryは、アプリのmainルーチンが格納されているディレクトリである。base_directoryは、自動的にクラスパス上の最初のディレクトリを形成するものとみなされる。
initial_classは、base_directoryと組になる情報であり、最初に起動すべきクラスファイルの名称を示す。
【００２６】
classpath_extensionは、mainルーチン以外のクラスファイルを示す。
キャッシュ完了監視部１０６は、アプリの構成ファイルが全てキャッシュされているか否かを判断し、全てキャッシュされていればアプリ制御部１０５にキャッシュの完了を通知する。
カルーセル記憶部１０７は、選択されたサービスに対応するアプリに係るオブジェクトカルーセルをファイルシステムとして参照可能な状態でキャッシュする。そして、アプリ実行部１０８からのファイルの読み込み要求に応じてファイルを提供する。ここでキャッシュするとは、具体的には、メモリなどの記憶装置に記憶することをいう。
【００２７】
アプリ実行部１０８は、アプリ制御部１０５から指示されたアプリの構成ファイルをカルーセル記憶部１０７から読み込み、実行開始指示があると、それらを解釈し、実行する。アプリ実行部１０８は、具体的にはDVB-MHPにおけるJava(登録商標）仮想マシンである。
デコード部１０９は、分離部１０３からビデオ・オーディオデータを受け取り、復号する。
【００２８】
出力部１１０は、復号されたビデオ・オーディオデータ及びアプリ実行部１０８より送出されるグラフィックスを出力する。
続いて図４は、アプリ実行装置１０の機能ブロック図を実際に実装する際のハードウェアのレイヤ構成に置き換えて、詳細に描いた図の一例である。本図に示すようにアプリ実行装置１０は、Java(登録商標）プラットフォーム４０１と、Java(登録商標） I/O４０２と、DSM-CC（DigitalStorage Media Command and Control）４０３と、デコーダ４０４とを含んで構成される。
【００２９】
Java(登録商標）プラットフォーム４０１は、Java(登録商標）仮想マシン４０６と、アプリケーションマネージャ４０５とからなる。Java(登録商標）仮想マシン４０６は、Java(登録商標）言語で記述されたJava(登録商標）オブジェクトを、アプリ実行装置１０におけるCPUのネイティブコードに変換して、CPUに実行させる。より詳細には、アプリケーションを構成するxletプログラムをヒープ領域にロードして、xletプログラムを解読し、解読結果に従って、制御を行う。
【００３０】
Java(登録商標）仮想マシン４０６は、クラスローダ４０７と、ヒープ領域４０８と、スレッド部４０９とを含んで構成される。
クラスローダ４０７は、クラスファイルをDSM-CC４０３からヒープ領域４０８に読み出す。クラスローダ４０７によるクラスファイルの読み出しは、ファイルパスを用いることによりなされる。ファイルパスがDSM-CC４０３を示しているなら、クラスローダ４０７は、クラスファイルをDSM-CC４０３からヒープ領域４０８に読み出す。
【００３１】
ヒープ領域４０８は、様々なクラスファイルのインスタンスが格納される。このインスタンスが、アプリを構成するxletプログラムである。かかるxletプログラムがヒープ領域４０８に配置されることにより、アプリは実行可能な状態になる。
スレッド部４０９は、ヒープ領域４０８に格納されたインスタンスを実行する論理的な実行主体である。
【００３２】
アプリケーションマネージャ４０５は、クラスローダ４０７にクラスのロードを指示する。また、Java(登録商標） I/O４０２がアプリを構成する全てのファイルにおいてsuccessを返したか否かを判断する。全てのファイルについてsuccessの場合にスレッド部４０９に実行開始指示を行う。ここで、全てのファイルについてsuccessの場合とは、一度falseになった後に再度ロードを指示した結果、successになったファイルも含む。また、全てのファイルにおいてsuccessであるか否かは、AITから抽出されるアプリに関する情報に基づいて判断される。
【００３３】
Java(登録商標） I/O４０２は、クラスローダ４０７からのクラスファイルのロードに対し、successまたはfalseをアプリケーションマネージャ４０５に返す。具体的には、クラスローダ４０７よりファイルパスを指定したロード指示があると、DSM-CC４０３に指定されたクラスファイルがキャッシュされているか否かを判断する。指定されたファイルがキャッシュされていると、ヒープ領域４０８にクラスファイルをロードする。そして、successをアプリケーションマネージャ４０５に通知する。クラスファイルが未キャッシュの場合は、falseをアプリケーションマネージャ４０５に通知する。
【００３４】
DSM-CC４０３は、クラスファイルのキャッシュを管理する。
カルーセル受信部４１０は、オブジェクトカルーセルを受信し、キャッシュする。
デコーダ４０４は、ビデオ・オーディオデータをデコードする。
＜データ＞
続いて、図５（ａ）及び図５（ｂ）はオブジェクトカルーセルによるアプリの構成ファイルの送信方法を示す図である。図５（ａ）は、放送装置２０により送信されるファイルシステムを示す。図５（ｂ）は、放送装置２０からアプリ実行装置１０にファイルシステムの一部が送信されている様子を示す。図５（ｂ）に示すように、ファイルシステムは一度に送信されるわけではなく、階層毎に分けて、定期的に繰り返し送信される。つまり、アプリ実行装置１０は、任意の時刻から1周期分のファイルを獲得し、アプリ実行装置１０内のメモリに展開することで、ファイルを復元する。
【００３５】
図６はTSとその構成要素であるTSパケットのシンタックスの一例を示す模式図である。TSは多数のTSパケットで構成され、それぞれのTSパケットは188バイトで構成される。それぞれのTSパケットは各TSパケットに対する情報を提供するヘッダと、実際のデータが記録されるペイロードとからなる。
ヘッダは、シンクバイトと、ペイロード単位開始表示子と、伝送優先順位と、パケット識別子（PID）と、スクランブリング制御と、適応フィールド制御と、連続性カウンタと、適応フィールドとから構成されており、それぞれ所定のビットが割り当てられており、TSパケットに対する情報を提供する。
【００３６】
ペイロードは、パケット化されたオーディオ・ビデオデータ及びサービスデータを含む。それぞれのパケット化されたオーディオ・ビデオ及びサービスデータは、パケット識別子で識別される。オーディオ・ビデオ及びサービスデータは、パケット単位にTSにそれぞれ多重化され、放送装置２０よりアプリ実行装置１０に伝送される。
続いて、図７はサービスＡとサービスＢの２つの放送番組を含むTSの一例を示す模式図である。ここで、それぞれの放送番組は１つのオーディオデータ及びビデオデータと、アプリの制御に関する情報であるAITと、アプリの構成ファイルを含むオブジェクトカルーセルが多重化されて伝送されるとする。TSに含まれる放送番組は、PMT(Program Map Table)と呼ばれるテーブルを配送するTSパケットで表現される。そのTSパケットのPIDは、PIDが0であるPAT(Program Association Table)と呼ばれるテーブルを配送するTSパケットに示されている。ここでPMTとは、あるサービスに含まれる映像や音声、AITなどのPIDを格納したものである。このPIDによりTSパケットの種類が識別される。PMTを参照することにより、ストリームの中から目的のプログラムを構成するTSパケットだけを取り出すことができる。それらPIDのついたパケットを集めることによって元の動画を再生することが可能となる。
【００３７】
図７の例ではサービスＡのPIDは100、サービスＢのPIDは200である。さらに、PMTにはオーディオデータと、ビデオデータと、AITと、アプリの構成ファイルを含むファイルシステムを配送するオブジェクトカルーセルのそれぞれのPIDが含まれる。図７の例ではサービスＡのオーディオデータは101、ビデオデータは102、AITは103、オブジェクトカルーセルは104のPIDを持つTSパケットでそれぞれ配送される。また、オブジェクトカルーセルのコンポーネントタグは1104である。また、AITにはアプリの起動や停止などの制御指示や、そのアプリを配送するオブジェクトカルーセルのコンポーネントタグ（オブジェクトカルーセルのPIDを導くためのリンク情報）や、そのアプリを起動する際に最初に使用するファイルのパスなどアプリの制御に必要な情報が含まれており、アプリ実行装置１０は基本的に再生中の番組情報に含まれるAITにしたがって、アプリの制御を行う。
＜動作＞
次に、アプリ実行装置１０の処理動作について説明する。図８は、アプリ実行装置１０の処理手順を示すフローチャートである。まず、サービス受付部１０１は、ユーザによるリモコン操作や、アプリからの要求、または電源オン時の初期設定により指定されたサービスに対応する数値を受け付け、受信部１０２に通知する（Ｓ８０１）。受信部１０２は、受け付けた数値に対応するサービスの搬送波にチューニングし、TSを受信する。そして、受信したTSをデジタルデータに復調する（Ｓ８０２）。分離部１０３は、TSに多重化されているPMT、PATを取得し、PMTに格納されたPIDからビデオ・オーディオデータ、オブジェクトカルーセル、AITを特定し、分離する（Ｓ８０３）。デコード部１０９は、分離部１０３により分離されたビデオ・オーディオデータをデコードし、出力部１１０は、デコード部１０９によりデコードされたデータを出力する（Ｓ８０４）。カルーセル記憶部１０７は、選択されたサービスにおいて、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュする（Ｓ８０５）。アプリ管理部１０４は、アプリ実行制御処理を行う（Ｓ８０６）。
【００３８】
続いて図９は、アプリ管理部１０４によるアプリ実行制御処理に関するフローチャートを示す図である。アプリ管理部１０４は、AITから抽出されるアプリに関する情報であるinitial_class３０２に対応するクラスファイルのロードをアプリ実行部１０８に指示する（Ｓ９０１）。カルーセル記憶部１０７にロード対象のファイルがあるか否かが判断される（Ｓ９０２）。ある場合は、アプリ実行部１０８にinitial_class３０２に対応するクラスファイルが読み出され、アプリ管理部１０４は、Java(登録商標） I/Oよりsuccessを受け取る（Ｓ９０３）。ない場合は、アプリ管理部１０４はJava(登録商標） I/Oよりfalseを受け取る（Ｓ９０４）。アプリ管理部１０４は、他にアプリに関するクラスファイルが存在するか否かを判断する（Ｓ９０５）。具体的には、AITから抽出されるアプリに関する情報であるbase_directory３０１及びclasspath_extension３０３に基づいて判断する。存在する場合は、base_directory３０１またはclasspath_extension３０３に示されるアプリを構成するファイルのロードをアプリ実行部１０８に指示する（Ｓ９０６）。ステップＳ９０２に移行する。存在しない場合は、アプリ管理部１０４は、アプリに関する全てのクラスファイルについてsuccessを受信したか否かを判断する（Ｓ９０７）。判断結果が否定の場合は、falseになったクラスファイルのロードを再度指示する（Ｓ９０８）。判断結果が肯定の場合は、アプリ管理部１０４はアプリ実行部１０８に実行開始指示を行う。アプリ管理部１０４によりアプリの実行開始を指示されたアプリ実行部１０８は、ロードされたクラスファイルを解釈し、実行する（Ｓ９０９）。
【００３９】
続いて、図１０はオブジェクトカルーセルで配送されるファイルシステムＦＳ１の具体例である。ファイルシステムＦＳ１には２つのアプリが含まれる。１つはアプリ１であり、もう一方はアプリ２である。アプリ１は、ファイルＦ１とファイルＦＣとで構成され、一方のアプリ２は、ファイルＦ２とファイルＦＣとで構成される。ここで、起動対象のアプリがアプリ１であった場合、アプリ制御部１０５は、キャッシュ完了監視部１０６からのキャッシュ完了通知を待ってアプリ実行部１０８に対し実行開始指示を行う。したがって、カルーセル記憶部１０７は、ファイルシステムＦＳ１に示す全てのファイルをキャッシュしているので、ファイルのキャッシュ処理を行うことなくアプリ実行部１０８からのファイルの読み込み要求に応答可能となる。よって、受信部１０２からデータを受け取れない状態に陥ったとしてもファイルの読み込みを保障することが可能である。
【００４０】
以上のように本実施の形態によれば、アプリ制御部１０５は、キャッシュ完了監視部１０６からのキャッシュ完了通知を受け取った後に、アプリ実行部１０８に実行開始指示を行う。よって、アプリを構成するファイルが未キャッシュの状態でアプリが動作することはないので、アプリの終了処理において、動作の安定が保障される。
また、アプリの構成ファイルの一部がメモリ上にキャッシュされた状態でアプリが動作し、動作中に当該アプリ、またはその他のアプリがTuning  APIを実行する場合がある。そのような場合であっても、上記に示したように、キャッシュ完了監視部１０６からのキャッシュ完了通知を待ってからアプリを実行することにより、アプリの終了処理を保障することができる。
【００４１】
また、アプリの構成ファイルの一部がメモリ上にキャッシュされた状態で動作し、動作中に例えば、ケーブルを抜く行為等により受信状況が悪化し、TSが受信不可能になる場合がある。そのような場合であっても、上記に示したように、キャッシュ完了監視部１０６からのキャッシュ完了通知を待ってからアプリを実行することにより、アプリの終了処理を保障することができる。
（第二実施形態）
第一実施形態では、ファイルシステム上のアプリの構成要素である全てのファイルをアプリ実行装置１０にキャッシュした後に、アプリを起動することにより、その後TSの変更があったとしても、アプリの実行時においてファイル読み込みが失敗しないことを保障した。しかしながら、アプリによってはファイル読み込みの保障は不要であり、起動開始までの時間を速くした方が好適であるものも存在する。そこで本実施形態は、アプリの特徴に合わせてアプリ毎に処理を変更する実施の形態である。
【００４２】
本実施形態では、図１に示すデジタル放送システムにおいて、放送番組は、第一実施形態で示した構成要素に加え、アプリの実行時においてファイル読み込みが失敗しないことを保障する必要があるか否かを示す属性（以下、「キャッシュ保障属性」という）を構成要素として含む。
図１１に本実施形態におけるアプリ実行装置１０ａの機能ブロック図を示す。図１１に示すように、アプリ実行装置１０ａは、第一実施形態のアプリ実行装置１０の構成に加えて、キャッシュ保障属性抽出部１１０１を含む。
【００４３】
キャッシュ保障属性抽出部１１０１は、TS中のアプリの制御に関する情報であるAITから、キャッシュ保障属性を抽出し、アプリ制御部１０５ａに提供する。
また、本実施形態におけるアプリ制御部１０５ａは、サービス受付部１０１によって指定されたサービスのAITから起動すべきアプリの情報を抽出する。また、キャッシュ完了監視部１０６に抽出したアプリに関する情報を渡す。また、キャッシュ保障属性抽出部１１０１よりキャッシュ保障属性を受け取ると、アプリのキャッシュ保障属性が、ファイル読み込みが失敗しないことを保障する必要の有る旨を示す属性か否かを判断する。判断結果が肯定である場合には、キャッシュ完了監視部からのキャッシュ完了通知を待ってから、アプリ認証とアプリの実行開始指示を行う。判断結果が否定である場合には、キャッシュ完了監視部からのキャッシュ完了通知を待たずにアプリ実行部１０８にアプリの実行開始指示を行う。
【００４４】
図１２は、DVB-MHP規格に、キャッシュ保障属性ＣＧを追加した場合の具体例を示す図である。図１２において、DVB-MHPにおけるAITでは、キャッシュ保障属性ＣＧは、AIT内に定義されるapplication_descriptorのcache_guarantee_flagフィールドとして追加される。
＜動作＞
続いて、本実施形態におけるアプリ実行装置１０ａの動作について説明する。
【００４５】
図１３は、アプリ実行装置１０ａの処理手順を示すフローチャートである。まず、サービス受付部１０１は、ユーザによるリモコン操作や、アプリからの要求、または電源オン時の初期設定により指定されたサービスに対応する数値を受け付け、受信部１０２に通知する（Ｓ１３０１）。受信部１０２は、受け付けた数値に対応するサービスの搬送波にチューニングし、TSを受信する。そして、受信したTSをデジタルデータに復調する（Ｓ１３０２）。分離部１０３は、TSに多重化されているPMT、PATを取得し、PMTに格納されたPIDからビデオ・オーディオ、オブジェクトカルーセル、AITを特定し、分離する（Ｓ３０３）。デコード部１０９は、ビデオ・オーディオデータをデコードし、出力部１１０は、デコードされたデータを出力する（Ｓ１３０４）。カルーセル記憶部１０７は、選択されたサービスにおいて、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュする（Ｓ１３０５）。アプリ管理部１０４ａは、キャッシュ保障属性抽出部１１０１よりキャッシュ保障属性を受け取る。そして、キャッシュ保障属性が保障する必要がある旨を示す属性であるか否かを判断する（Ｓ１３０６）。判断が肯定の場合は、アプリ管理部１０４ａは、図９に示したアプリ実行制御処理を行う（Ｓ１３０７）。判断が否定の場合は、アプリ管理部１０４ａは、アプリ実行処理を行う（Ｓ１３０８）。
【００４６】
続いて図１４は、アプリ管理部１０４ａによるアプリ実行処理に関するフローチャートを示す図である。アプリ管理部１０４ａは、AITから抽出されるアプリに関する情報であるinitial_class３０２に対応するクラスファイルのロードをアプリ実行部１０８に指示する（Ｓ１４０１）。カルーセル記憶部１０７にロード対象のファイルがあるか否かが判断される（Ｓ１４０２）。ある場合は、アプリ実行部１０８にinitial_class３０２に対応するクラスファイルが読み出され、アプリ管理部１０４ａは、Java(登録商標） I/Oよりsuccessを受け取る（Ｓ１４０４）。そして、アプリ管理部１０４ａはアプリ実行部１０８に実行開始指示を行う。アプリ管理部１０４ａによりアプリの実行開始を指示されたアプリ実行部１０８は、ロードされたクラスファイルを解釈し、実行する（Ｓ１４０５）。ない場合は、アプリ管理部１０４ａはJava(登録商標） I/Oよりfalseを受け取る（Ｓ１４０３）。Ｓ１４０１に移行する。アプリ管理部１０４ａは、他にアプリに関するクラスファイルが存在するか否かを判断する（Ｓ１４０６）。具体的には、AITから抽出されるアプリに関する情報であるbase_directory３０１及びclasspath_extension３０３に基づいて判断する。存在しない場合は、処理を終了する。存在する場合は、他のファイルの読み込みが必要か否かを判断する（Ｓ１４０７）。他のファイルの読み込みが必要であれば、アプリ管理部１０４ａは必要なファイルのロードを指示する（Ｓ１４０８）。カルーセル記憶部１０７にロード対象のファイルがあるか否かが判断される（Ｓ１４０９）。ある場合は、アプリ実行部１０８にクラスファイルが読み出され、アプリ管理部１０４ａは、Java(登録商標） I/Oよりsuccessを受け取る（Ｓ１４１１）。そして、アプリ実行部１０８は読み出したクラスファイルを実行する（Ｓ１４０５）。ない場合は、アプリ管理部１０４ａはJava(登録商標） I/Oよりfalseを受け取る（Ｓ１４１０）。Ｓ１４０８に移行する。以上のように、アプリ実行処理では、キャッシュ完了通知を待たずに、アプリ管理部１０４ａはアプリ実行部１０８にアプリの実行開始指示を行う。そして、アプリ管理部１０４ａによりアプリの実行開始を指示されたアプリ実行部１０８は、最初に実行対象となるクラスファイルの読み込み処理を行い、そのクラスファイルを解釈・実行する。さらに、解釈・実行の過程で必要になったその他のアプリの構成ファイルについて、読み込み処理をその都度行い、読み込んだクラスファイルを解釈・実行する。
【００４７】
続いて図１０を用いて説明する。図１０におけるオブジェクトカルーセルで配送されるファイルシステムＦＳ１の具体例において、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性であった場合は、第一実施形態と同様の処理を行う。つまり、アプリ制御部１０５ａは、キャッシュ完了監視部１０６からのキャッシュ完了通知を待ってアプリ実行部１０８に実行開始指示を送る。したがって、カルーセル記憶部１０７は、ファイルのキャッシュ処理を行うことなくファイルの読み込み要求に応答可能となるため、受信部１０２からデータを受け取れない状態に陥ったとしてもファイルの読み込みを保障することが可能である。
【００４８】
一方、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性でない場合は、アプリ制御部１０５ａはキャッシュ完了監視部１０６からのキャッシュ完了通知を待たずに、アプリ実行部１０８にアプリの起動指示を行う。そのため、カルーセル記憶部１０７は、アプリ実行部１０８からのファイルの読み込み要求に対して、できるだけレスポンスよく応答し、ファイルの読み込み要求がない空き時間を利用して、キャッシュが完了していないファイルのキャッシュを行うという処理をする。したがって、全てのファイルがキャッシュされるのを待つ場合よりアプリの起動が早い。
【００４９】
以上のように本実施の形態によれば、キャッシュ保障属性によりファイルの読み込みを保障する必要があるアプリと、保障は不要で起動速度やメモリ効率を優先したいアプリとのそれぞれに適した起動方法を選択することができる。
なお、本実施形態では、キャッシュ保障属性を新たにAITに含まれる属性として追加し、用いたが、これに限らない。例えば、図１２に示されるAITの既存属性であるプライオリティ属性APを用いても良いし、サービスバウンド属性SBを用いても良い。プライオリティ属性APとは、複数のアプリが存在する場合に、どのアプリにリソースを優先的に配分するかを示す属性である。サービスバウンド属性SBは、アプリがサービスバウンドか否かを示す属性である。アプリがサービスバウンドの場合は、他のサービスに切り替わるとアプリは終了される。例えば、プライオリティ属性を用いる場合は、アプリ制御部１０５ａは、プライオリティ情報が既定の閾値以上か否かを判断する。そして、既定の閾値以上の場合には、アプリ制御部１０５ａはキャッシュ完了監視部１０６からのキャッシュ完了通知を待ってから、実行指示を行うとしても良い。
【００５０】
また、サービスバウンド属性を用いる場合には、アプリ制御部１０５ａは、サービスバウンド属性がサービスバウンドか否かを判断する。そして、サービスバウンドの場合には、アプリ制御部１０５ａはキャッシュ完了監視部１０６からのキャッシュ完了通知を待ってから、実行指示を行うとしても良い。これにより、アプリの構成ファイルの一部がメモリ上にキャッシュされた状態でサービスバウンドアプリが動作している最中に、チューニングを伴い、かつ、そのアプリの起動が許可されていないサービスへの切り替えがあった場合であっても、その後アプリを終了する際には、正常にアプリの終了処理を行うことができる。
（第三実施形態）
第一実施形態では、ファイルシステムに複数のアプリを構成するファイルが存在する場合に、それらの全てのファイルがキャッシュされてから開始指示をしていた。しかし、例えばファイルシステム上に存在する複数のアプリのうち、一つのアプリだけが起動対象である場合が考えられる。その場合においても、複数のアプリの全ての構成ファイルについてキャッシュするのを待っていたのでは効率が悪い。そこで、本実施形態のアプリ実行装置は、一のアプリを構成するファイルを他のファイルと区別できるように識別子を設け、複数のディレクトリに分割された状態で配信されるファイルにおいて、一のアプリの実行に必要なファイルがキャッシュされれば、実行開始指示を行う。
【００５１】
本実施形態では、図１に示すデジタル放送システムにおいて、アプリを構成するファイルは、１つ以上のディレクトリに分割した状態で配信される。放送番組は、第二実施形態で示した構成要素に加え、一のアプリを構成するファイルを含むディレクトリを示す属性（以下、「マルチディレクトリ属性」という）を構成要素として含む。
図１５において、アプリ実行装置１０ｂは、第二実施形態のアプリ実行装置１０ａの構成に加えて、マルチディレクトリ属性抽出部１５０１を含み、かつキャッシュ完了監視部１０６の代わりにディレクトリ別キャッシュ完了監視部１０６ｂを含んで構成される。
【００５２】
マルチディレクトリ属性抽出部１５０１は、TS中のアプリの制御に関する情報であるAITから、マルチディレクトリ属性を抽出し、アプリ制御部１０５ｂに提供する。
ディレクトリ別キャッシュ完了監視部１０６ｂは、マルチディレクトリ属性に示されるディレクトリにおいて、アプリの構成ファイルが全てキャッシュされたか否かを判断する。マルチディレクトリ属性に示される全てのディレクトリ内のファイルがキャッシュされると、アプリ制御部１０５ｂにキャッシュ完了を通知する。
【００５３】
また、本実施形態におけるアプリ制御部１０５ｂは、サービス受付部１０１によって指定されたサービスのAITから起動すべきアプリの情報を抽出する。また、キャッシュ保障属性をキャッシュ保障属性抽出部１１０１より受け取ると、アプリのキャッシュ保障属性が、ファイル読み込みが失敗しないことを保障する必要の有る旨を示す属性か否かを判断する。判断結果が肯定である場合には、ディレクトリ別キャッシュ完了監視部１０６ｂからのキャッシュ完了通知を待ってから、アプリ認証とアプリの実行開始指示を行う。判断結果が否定である場合には、ディレクトリ別キャッシュ完了監視部１０６ｂからのキャッシュ完了通知を待たずに、アプリ実行部１０８にアプリの実行開始指示を行う。また、ディレクトリ別キャッシュ完了監視部１０６ｂに抽出したアプリに関する情報を渡す。
【００５４】
続いて、図１６は、DVB-MHP規格に、本実施形態特有のマルチディレクトリ属性を適用した場合の具体例を示す図である。図１６において、DVB-MHPにおけるAITでは、マルチディレクトリ属性ＭＤ１はAIT内に定義されるapplication_descriptorにおける既存のbase_directoryフィールドの流用であり、マルチディレクトリ属性ＭＤ２はapplication_descriptorに新規にextension_directoryフィールドとして追加される。ここで、マルチディレクトリ属性ＭＤ１はアプリの構成ファイルの中でアプリ起動時に最初に使用するファイルを含むディレクトリ・ツリーのパスを示す。また、マルチディレクトリ属性ＭＤ２はマルチディレクトリ属性ＭＤ１で示されるディレクトリ・ツリーに含まれないその他のアプリの構成ファイルを含むディレクトリ・ツリーのパスを示す。
＜動作＞
次に、本実施形態におけるアプリ実行装置１０ｂの動作を説明する。
【００５５】
図１７は、アプリ実行装置１０ｂの処理手順を示すフローチャートである。まず、サービス受付部１０１は、ユーザによるリモコン操作や、アプリからの要求、または電源オン時の初期設定により指定されたサービスに対応する数値を受け付け、受信部１０２に通知する（Ｓ１７０１）。受信部１０２は、受け付けた数値に対応するサービスの搬送波にチューニングし、TSを受信する。そして、受信したTSをデジタルデータに復調する（Ｓ１７０２）。分離部１０３は、TSに多重化されているPMT、PATを取得し、PMTに格納されたPIDからビデオ・オーディオ、オブジェクトカルーセル、AITを特定し、分離する（Ｓ１７０３）。デコード部１０９は、ビデオ・オーディオデータをデコードし、出力部１１０は、デコードされたデータを出力する（Ｓ１７０４）。カルーセル記憶部１０７は、選択されたサービスにおいて、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュする（Ｓ１７０５）。アプリ管理部１０４ｂは、キャッシュ保障属性抽出部１１０１よりキャッシュ保障属性を、マルチディレクトリ属性抽出部１５０１よりマルチディレクトリ属性を受け取る。そして、キャッシュ保障属性情報が保障する必要がある旨を示す情報であるか否かを判断する（Ｓ１７０６）。判断が肯定の場合は、アプリ管理部１０４ｂは、アプリ実行制御処理２を行う（Ｓ１７０７）。判断が否定の場合は、アプリ管理部１０４ｂは、図１４に示したアプリ実行処理を行う（Ｓ１７０８）。つまり、ディレクトリ別キャッシュ完了監視部１０６ｂからのキャッシュ完了通知を待たずにアプリ実行部１０８にアプリの起動指示を行う。
【００５６】
続いて図１８は、アプリ管理部１０４ｂによるアプリ実行制御処理２に関するフローチャートを示す図である。アプリ管理部１０４ｂは、マルチディレクトリ属性よりアプリの構成ファイルの中でアプリ起動時に最初に使用するファイルを含むディレクトリを特定する（Ｓ１８０１）。特定されたディレクトリ内のinitial_classに対応するクラスファイルのロードをアプリ実行部１０８に指示する（Ｓ１８０２）。カルーセル記憶部１０７にロード対象のファイルがあるか否かが判断される（Ｓ１８０３）。アプリ実行部１０８は、initial_classに対応するクラスファイルをロードする。ある場合は、アプリ実行部１０８にinitial_class３０２に対応するクラスファイルが読み出され、アプリ管理部１０４ｂは、Java(登録商標） I/Oよりsuccessを受け取る（Ｓ１８０４）。ない場合は、アプリ管理部１０４ｂはJava(登録商標） I/Oよりfalseを受け取る（Ｓ１８０５）。アプリ管理部１０４ｂは、マルチディレクトリ属性により示されるディレクトリ内に、他にアプリに関するクラスファイルが存在するか否かを判断する（Ｓ１８０６）。具体的には、AITから抽出されるアプリに関する情報であるbase_directory３０１及びclasspath_extension３０３に基づいて判断する。存在する場合は、base_directory３０１またはclasspath_extension３０３に示されるアプリを構成するファイルのロードをアプリ実行部１０８に指示する（Ｓ１８０７）。ステップＳ１８０３に移行する。存在しない場合は、アプリ管理部１０４ｂは、マルチディレクトリ属性で示されるディレクトリが他に存在するか否かを判断する（Ｓ１８０８）。存在する場合は、ディレクトリ内のファイルのロードをアプリ実行部１０８に指示する（Ｓ１８０９）。ステップＳ１８０３に移行する。存在しない場合は、アプリ管理部１０４ｂは、マルチディレクトリ属性で示されるディレクトリ内における全てのファイルについてsuccessを受信したか否かを判断する（Ｓ１８１０）。判断結果が否定の場合は、falseになったクラスファイルのロードを再度指示する（Ｓ１８１１）。判断結果が肯定の場合は、アプリ管理部１０４ｂはアプリ実行部１０８に実行開始指示を行う。アプリ管理部１０４ｂによりアプリの実行開始を指示されたアプリ実行部１０８は、ロードされたクラスファイルを解釈し、実行する（Ｓ１８１２）。
【００５７】
続いて図１０を用いて具体的に説明する。オブジェクトカルーセルで配送されるファイルシステムＦＳ１の具体例において、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性であった場合は、アプリ制御部１０５ｂはディレクトリ別キャッシュ完了監視部１０６ｂからのキャッシュ完了通知を待ってから、アプリ実行部１０８にアプリの起動指示を行う。ここで、ディレクトリ別キャッシュ完了監視部１０６ｂが監視の対象とするファイルはファイルＦ１及びファイルＦＣに限定される。また、マルチディレクトリ属性ＭＤ１は"/app1"、マルチディレクトリ属性ＭＤ２は"/common"となる。したがって、ディレクトリ別キャッシュ完了監視部１０６ｂはファイルＦ２のキャッシュ完了を待たずにキャッシュ完了通知をアプリ制御部１０５ｂに通知する。よって、カルーセル記憶部１０５は、ファイルのキャッシュ処理を行うことなくファイルの読み込み要求に応答可能となるため、受信部１０２からデータを受け取れない状態に陥ったとしてもファイルの読み込みを保障することが可能である。さらにキャッシュするファイルを限定することにより、アプリの起動を早めることができる。
【００５８】
一方、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性でない場合は、アプリ制御部１０５ｂはディレクトリ別キャッシュ完了監視部１０６ｂからのキャッシュ完了通知を待たずに、アプリ実行部１０８にアプリの起動指示を行う。そのため、カルーセル記憶部１０５は、アプリ実行部１０８からのファイルの読み込み要求に対してできるだけレスポンスよく応答し、ファイルの読み込み要求がない空き時間を利用してキャッシュが完了していないファイルのキャッシュを行うという処理をする。したがって、マルチディレクトリ属性に示される全てのディレクトリ中のファイルのキャッシュ完了を待つ場合よりアプリの起動が早い。
【００５９】
以上のように本実施の形態によれば、マルチディレクトリ属性に基づいてアプリの実行に必要なファイルのみをキャッシュした後に、アプリを起動することが可能となり、より早くアプリを起動することができる。
（第四実施形態）
本実施形態のアプリ実行装置１０ｃは、アプリを構成するファイルにおいて、複数のオブジェクトカルーセルに分割した状態で配信されたファイルをキャッシュすることで、アプリの実行に必要なファイルだけを限定的にキャッシュする。
【００６０】
本実施形態では、図１に示すデジタル放送システムにおいて、アプリを構成するファイルは、複数のオブジェクトカルーセルに分割した状態で配信され、放送番組は、第二実施形態で示した構成要素に加え、一のアプリを構成するファイルを含むオブジェクトカルーセルを示す属性（以下、「マルチカルーセル属性」）も構成要素として含む。
なお、本実施形態では、アプリを構成するファイルは、二つのオブジェクトカルーセルに分割した状態で配信されるとする。
【００６１】
図１９において、アプリ実行装置１０ｃは、第二実施形態のアプリ実行装置１０ａの構成に加えて、マルチカルーセル属性抽出部１９０１を含み、かつ、カルーセル記憶部１９０２と、キャッシュ完了監視部１９０３とを含んで構成される。
マルチカルーセル属性抽出部１９０１は、TS中のアプリの制御に関する情報であるAITから、マルチカルーセル属性を抽出し、アプリ制御部１０５ｃに提供する。
【００６２】
カルーセル記憶部１９０２は、選択されたサービスに含まれる一のオブジェクトカルーセルを、ファイルシステムとして参照可能な状態で記憶する。そして、アプリ実行部１０８からのファイルの読み込み要求に応じて、要求されたファイルを提供する。この際、カルーセル記憶部１９０２及びカルーセル記憶部１０７のうち、アプリ実行部１０８より要求されたファイルをキャッシュしている一方のカルーセル記憶部がファイルを提供する。
【００６３】
キャッシュ完了監視部１９０３は、カルーセル記憶部１９０２において、オブジェクトカルーセルが全てキャッシュされているか否かを判断し、全てキャッシュされていればアプリ制御部１０５ｃに完了を通知する。
また、本実施形態におけるカルーセル記憶部１０７ｃは、選択されたサービスに含まれる他方のオブジェクトカルーセルを、ファイルシステムとして参照可能な状態で記憶する。
【００６４】
また、本実施形態におけるキャッシュ完了監視部１０６ｃは、カルーセル記憶部１０７ｃにおいて、オブジェクトカルーセルが全てキャッシュされているか否かを判断し、全てキャッシュされていればアプリ制御部１０５ｃに完了を通知する。
また、本実施形態におけるアプリ制御部１０５ｃは、サービス受付部１０１によって指定されたサービスのAITから起動すべきアプリの情報を抽出する。また、キャッシュ保障属性をキャッシュ保障属性抽出部１１０１より受け取ると、アプリのキャッシュ保障属性が、ファイル読み込みが失敗しないことを保障する必要の有る旨を示す属性か否かを判断する。判断結果が肯定である場合には、キャッシュ完了監視部１９０３及びキャッシュ完了監視部１０６ｃからのキャッシュ完了通知を待ってから、アプリ認証とアプリの実行開始指示を行う。判断結果が否定である場合には、キャッシュ完了監視部１９０３及びキャッシュ完了監視部１０６ｃからのキャッシュ完了通知を待たずに、アプリ実行部１０８にアプリの実行開始指示を行う。また、キャッシュ完了監視部１９０３及びキャッシュ完了監視部１０６ｃに抽出したアプリに関する情報を渡す。
【００６５】
ここで、図２０は、DVB-MHP規格に、キャッシュ保障属性ＣＧとマルチカルーセル属性ＭＣを加えた場合の具体例を示す図である。図２０において、DVB-MHPにおけるAITでは、マルチカルーセル属性ＭＣはAIT内に定義されるapplication_descriptorのtransport_protocol_lableフィールドの拡張として追加される。キャッシュ保障属性ＣＧは第二実施形態と同様である。さらに、図２１は、DVB-MHP規格におけるAIT内に定義されるオリジナルのapplication_descriptorの例である。マルチカルーセル属性ＭＣのために拡張された部分のオリジナルの属性であるトランスポート・プロトコル・ラベル属性ＴＰＬは、複数の配送経路を示すことができる。１つのtransport_protocol_lableフィールドの値はアプリの全ての構成ファイルを配信しているオブジェクトカルーセル、または、IP via DVB multiprotocol encapsulationを示す。forループにより複数のtransport_protocol_lableフィールドの値を示すことが可能であるため複数の配信経路を示すことが可能である。一方、図２０に示す拡張されたマルチカルーセル属性ＭＣでは、複数の配送経路を示すことができるforループ内にさらにforループを追加している。このforループは、１つの配信経路においてアプリを分割して配信している１つ以上のオブジェクトカルーセルを示す。ここで、IP via DVB multiprotocol encapsulationはオブジェクトカルーセルと同様にTS内で配送されるファイルシステムであり、DVB-MHP規格においてアプリを構成するファイルを配送するための手段として使用される。
＜動作＞
次に、本実施形態のアプリ実行装置１０ｃの動作を説明する。図２２は、アプリ実行装置１０ｃの処理手順を示すフローチャートである。まず、サービス受付部１０１は、ユーザによるリモコン操作や、アプリからの要求、または電源オン時の初期設定により指定されたサービスに対応する数値を受け付け、受信部１０２に通知する（Ｓ２２０１）。受信部１０２は、受け付けた数値に対応するサービスの搬送波にチューニングし、TSを受信する。そして、受信したTSをデジタルデータに復調する（Ｓ２２０２）。分離部１０３は、TSに多重化されているPMT、PATを取得し、PMTに格納されたPIDからビデオ・オーディオ、オブジェクトカルーセル、AITを特定し、分離する（Ｓ２２０３）。デコード部１０９は、ビデオ・オーディオデータをデコードし、出力部１１０は、デコードされたデータを出力する（Ｓ２２０４）。カルーセル記憶部１０７及びカルーセル記憶部１９０２は、選択されたサービスにおいて、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュする。二つのオブジェクトカルーセルをそれぞれ異なるカルーセル記憶部にキャッシュする（Ｓ２２０５）。アプリ管理部１０４ｃは、キャッシュ保障属性抽出部１１０１よりキャッシュ保障属性を、マルチカルーセル属性抽出部１９０１よりマルチカルーセル属性を受け取る。そして、キャッシュ保障属性情報が保障する必要がある旨を示す情報であるか否かを判断する（Ｓ２２０６）。判断が肯定の場合は、アプリ管理部１０４ｃは、アプリ実行制御処理３を行う（Ｓ２２０７）。判断が否定の場合は、アプリ管理部１０４ｃは、図１４に示したアプリ実行処理を行う（Ｓ２２０８）。つまり、キャッシュ完了監視部１９０３及びキャッシュ完了監視部１０６からのキャッシュ完了通知を待たずにアプリ実行部１０８にアプリの起動指示を行う。
【００６６】
続いて図２３は、アプリ管理部１０４ｃによるアプリ実行制御処理３に関するフローチャートを示す図である。アプリ管理部１０４ｃは、AITから抽出されるアプリに関する情報であるinitial_class３０２に対応するクラスファイルのロードをアプリ実行部１０８に指示する（Ｓ２３０１）。カルーセル記憶部１０７ｃまたはカルーセル記憶部１９０２にロード対象のファイルがあるか否かが判断される（Ｓ２３０２）。ある場合は、アプリ実行部１０８にinitial_class３０２に対応するクラスファイルが読み出され、アプリ管理部１０４ｃは、Java(登録商標） I/Oよりsuccessを受け取る（Ｓ２３０３）。ない場合は、アプリ管理部１０４ｃはJava(登録商標） I/Oよりfalseを受け取る（Ｓ２３０４）。アプリ管理部１０４ｃは、マルチカルーセル属性で示されるカルーセルに他のファイルが存在するか否かを判断する（Ｓ２３０５）。具体的には、AITから抽出されるアプリに関する情報であるbase_directory３０１及びclasspath_extension３０３に基づいて判断する。存在する場合は、base_directory３０１またはclasspath_extension３０３に示されるアプリを構成するファイルのロードをアプリ実行部１０８に指示する（Ｓ２３０６）。ステップＳ２３０２に移行する。存在しない場合は、アプリ管理部１０４ｃは、マルチカルーセル属性で示されるカルーセル内の全てのファイルについてsuccessを受信したか否かを判断する（Ｓ２３０７）。判断結果が否定の場合は、falseになったクラスファイルのロードを再度指示する（Ｓ２３０８）。判断結果が肯定の場合は、アプリ管理部１０４ｃはアプリ実行部１０８に実行開始指示を行う。アプリ管理部１０４によりアプリの実行開始を指示されたアプリ実行部１０８は、ロードされたクラスファイルを解釈し、実行する（Ｓ２３０９）。
【００６７】
図２４はファイルシステムＦＳ１が２つのオブジェクトカルーセルに分割して配信される場合の具体例である。図２４に示すようにファイルシステムＦＳ１は、ファイルシステムＦＳ２とファイルシステムＦＳ３に分割されて送信される。ファイルシステムＦＳ２とファイルシステムＦＳ３はそれぞれカルーセル記憶部１０７ｃ、及びカルーセル記憶部１９０２に記憶される。ここで、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性であった場合は、アプリ制御部１０５ｃは、キャッシュ完了監視部１０６ｃとキャッシュ完了監視部１９０３の双方のキャッシュ完了通知を待ってから、アプリ実行部１０８にアプリの起動指示を行う。したがって、アプリ実行装置１０ｃはファイルＦ２のキャッシュの完了を待つことはない。よって、カルーセル記憶部１０７ｃとカルーセル記憶部１９０２は、ファイルのキャッシュ処理を行うことなくファイルの読み込み要求に応答可能となるため、受信部１０２からデータを受け取れない状態に陥ったとしてもファイルの読み込みを保障することが可能である。さらにキャッシュするファイルを限定することにより、アプリの起動を早めることができる。
【００６８】
一方、起動対象のアプリがアプリ１であり、かつ、キャッシュ保障属性が保障する必要がある旨を示す属性でない場合は、アプリ管理部１０４ｃはキャッシュ完了監視部１０６ｃ及びキャッシュ完了監視部１９０３からのキャッシュ完了通知を待たずに、アプリ実行部１０８にアプリの起動指示を行う。そのため、カルーセル記憶部１０７ｃ及びカルーセル記憶部１９０２は、アプリ実行部１０８からのファイルの読み込み要求に対してできるだけレスポンスよく応答し、ファイルの読み込み要求がない空き時間を利用してキャッシュが完了していないファイルのキャッシュを行うという処理となる。したがって、マルチカルーセル属性に示されるカルーセル内の全てのファイルのキャッシュ完了を待つ場合よりアプリの起動が早い。
【００６９】
以上のように本実施の形態によれば、アプリの構成ファイルとその他のファイルとを異なるカルーセルに分割して配送することが可能であるために、アプリの実行に必要なファイルのみをキャッシュした後に、アプリを起動することが可能となり、より早くアプリを起動することができる。
なお、本実施形態では、アプリ実行装置１０ｃは、カルーセル記憶部、キャッシュ完了監視部を二組備えるとしたが、三組以上備えるとしても良い。
＜補足＞
以上、本発明に係るアプリ実行装置について、実施の形態に基づいて説明したが、本発明は上記の実施の形態に限られないことは勿論である。
【００７０】
上記実施の形態では、デジタル放送システムはアプリ実行装置及び放送装置がそれぞれ一つずつで構成されるとしたが、それぞれが複数であっても良い。
上記実施の形態では、アプリ実行装置はアプリを構成する全てのファイルをキャッシュした後に実行開始指示を行ったが、アプリを構成するファイルのうち、アプリの終了処理において、suspend処理を実行するために必要なファイルがキャッシュされれば、実行開始指示を行うとしても良い。この場合には、例えば図９のＳ９０５において、サスペンド処理を実行するために必要なファイルが他に存在するか否かを判断する。そして、Ｓ９０７において、アプリを構成するファイルのうち、サスペンド処理を実行するために必要な全てのファイルについてsuccessを受信したか否かを判断する。これらの判断は、AITに基づいて行われる。
【００７１】
上記実施の形態では、各属性をAIT内に定義される既存のdescriptorに追加する例としているが、新たなdescriptorをAIT内に追加しても良いし、AIT以外のテーブルを用いる構成としてもよい。
上記実施の形態では、オブジェクトカルーセルでファイルを送信するとしたが、オブジェクトカルーセルの代わりにIPvia DVB multiprotocol encapsulation、データカルーセル、あるいはTCP/IPによる配信方法を用いる構成としても良いし、DVD、BDなどの記録媒体に記録されたファイルを用いる構成としてもよい。例えば、BDではHD映像を再生するので、HD映像のシームレス再生を優先すると、キャッシュミスが発生する。また、BDがアプリ実行装置から取り出された場合に、キャッシュミスが発生する。そのような場合であっても、上記処理により適切に終了処理を行うことができる。
【００７２】
上記の実施形態では、アプリ実行装置を用いたが、本発明は上記フローチャートで示したステップを含む方法、及び上記フローチャートで示したステップをコンピュータに実行させるプログラムコードを含むプログラムであっても良い。
上記の実施形態では、キャッシュ完了監視部がアプリを構成する全てのファイルについてロードできたか否かを判断したが、同様の処理を実現するためのキャッシュ制御用のAPI（Application Program Interface）を追加しても良い。その場合には、アプリ管理部が実行制御するのではなく、アプリのmainルーチンが実行制御するとしても良い。図２５にmainルーチンが実行制御を行う場合のフローチャートを示す。まず、アプリ管理部は、mainルーチンのロードを指示する（Ｓ２５０１）。ファイルがキャッシュ済みか否かが判断され（Ｓ２５０２）、キャッシュ済みならロードされる。アプリのmainルーチンがロードできたら、アプリ管理部はmainルーチンを起動するようにアプリ実行部に指示する（Ｓ２５０３）。mainルーチンはAPIを通じてアプリを構成する全てのクラスがロードされたか否かをチェックする（Ｓ２５０４）。全てのファイルがキャッシュされるまで、実行を待機する（Ｓ２５０５）。全てのファイルがキャッシュされれば、mainルーチンの実行を継続し、さらに、アプリ全体を実行する（Ｓ２５０６）。そして、アプリを構成するファイルをキャッシュアウトしないようにAPIを通じてカルーセル記憶部に指示する（Ｓ２５０７）。
【産業上の利用可能性】
【００７３】
本発明を構成するアプリケーションプログラム実行装置は、製造産業において経営的に、また継続的及び反復的に製造し、販売することができる。特に、地上波、衛星、またはケーブルデジタル放送用のＳＴＢやデジタル放送受信機能内蔵テレビ等として有用である。
【図面の簡単な説明】
【００７４】
【図１】システム図である。
【図２】アプリ実行装置の機能ブロック図である。
【図３】AITから抽出されるアプリに関する情報を示す図である。
【図４】アプリ実行装置のレイヤ構成図である。
【図５】オブジェクトカルーセルの説明図である。
【図６】TSとその構成要素であるTSパケットのシンタックスの一例を示す模式図である。
【図７】２つの放送番組を含むTSの一例を示す模式図である。
【図８】アプリ実行装置の処理手順を示すフローチャートである。
【図９】アプリ管理部によるアプリ実行制御処理を示すフローチャートである。
【図１０】オブジェクトカルーセルで配送されるファイルシステムの具体例を示す図である。
【図１１】第二実施形態におけるアプリ実行装置の機能ブロック図である。
【図１２】DVB-MHP規格に、キャッシュ保障属性ＣＧを追加した場合の具体例を示す図である。
【図１３】第二実施形態におけるアプリ実行装置の処理手順を示すフローチャートである。
【図１４】アプリ管理部によるアプリ実行処理を示すフローチャートである。
【図１５】第三実施形態におけるアプリ実行装置の機能ブロック図である。
【図１６】DVB-MHP規格に、マルチディレクトリ属性を適用した場合の具体例を示す図である。
【図１７】第三実施形態におけるアプリ実行装置の処理手順を示すフローチャートである。
【図１８】アプリ管理部によるアプリ実行制御処理２を示すフローチャートである。
【図１９】第四実施形態におけるアプリ実行装置の機能ブロック図である。
【図２０】DVB-MHP規格に、キャッシュ保障属性とマルチカルーセル属性を加えた場合の具体例を示す図である。
【図２１】DVB-MHP規格におけるAIT内に定義されるオリジナルのapplication_descriptorの例を示す図である。
【図２２】第四実施形態におけるアプリ実行装置の処理手順を示すフローチャートである。
【図２３】アプリ管理部によるアプリ実行制御処理３を示すフローチャートである。
【図２４】ファイルシステムが２つのオブジェクトカルーセルに分割して配信される場合の具体例を示す図である。
【図２５】アプリのmainルーチンが実行制御を行う場合のフローチャートである。
【符号の説明】
【００７５】
１０      アプリ実行装置
１０ａ    アプリ実行装置
１０ｂ    アプリ実行装置
１０ｃ    アプリ実行装置
２０      放送装置
１０１    サービス受付部
１０２    受信部
１０３    分離部
１０４    アプリ管理部
１０４ａ  アプリ管理部
１０４ｂ  アプリ管理部
１０４ｃ  アプリ管理部
１０５    アプリ制御部
１０５ａ  アプリ制御部
１０５ｂ  アプリ制御部
１０５ｃ  アプリ制御部
１０６    キャッシュ完了監視部
１０６ｂ  ディレクトリ別キャッシュ完了監視部
１０６ｃ  キャッシュ完了監視部
１０７    カルーセル記憶部
１０７ｃ  カルーセル記憶部
１０８    アプリ実行部
１０９    デコード部
１１０    出力部
４０１    Java（登録商標）プラットフォーム
４０２    Java(登録商標） I/O
４０３    DSM-CC
４０４    デコーダ
４０５    アプリケーションマネージャ
４０６    Java(登録商標）仮想マシン
４０７    クラスローダ
４０８    ヒープ領域
４０９    スレッド部
４１０    カルーセル受信部
１１０１  キャッシュ保障属性抽出部
１５０１  マルチディレクトリ属性抽出部
１９０１  マルチカルーセル属性抽出部
１９０２  カルーセル記憶部
１９０３  キャッシュ完了監視部
【図１】
0004875987.tif 000002
【図２】
0004875987.tif 000003
【図３】
0004875987.tif 000004
【図４】
0004875987.tif 000005
【図５】
0004875987.tif 000006
【図６】
0004875987.tif 000007
【図７】
0004875987.tif 000008
【図８】
0004875987.tif 000009
【図９】
0004875987.tif 000010
【図１０】
0004875987.tif 000011
【図１１】
0004875987.tif 000012
【図１２】
0004875987.tif 000013
【図１３】
0004875987.tif 000014
【図１４】
0004875987.tif 000015
【図１５】
0004875987.tif 000016
【図１６】
0004875987.tif 000017
【図１７】
0004875987.tif 000018
【図１８】
0004875987.tif 000019
【図１９】
0004875987.tif 000020
【図２０】
0004875987.tif 000021
【図２１】
0004875987.tif 000022
【図２２】
0004875987.tif 000023
【図２３】
0004875987.tif 000024
【図２４】
0004875987.tif 000025
【図２５】
0004875987.tif 000026