WO2006049185A1 - アプリケーションプログラム実行装置 - Google Patents

Abstract

　選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケーションプログラム実行装置であって、キャッシュ部と、ユーザからサービスの選択を受け付ける受付部と、放送装置から送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ部に書き込む受信部と、前記キャッシュ部が前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュしているか否かを判断する判断部と、前記ファイルをキャッシュしていると判断すれば、前記キャッシュ部にキャッシュされたアプリケーションプログラムを実行させる実行制御部とを含む。

Description

明 細 書

アプリケーションプログラム実行装置

技術分野

[0001] 本発明は、欧州デジタル放送規格 (DVB- MHP(Digital Video Broadcasting Multime dia Home Platform))に対応するアプリケーションプログラム実行装置に関する。

背景技術

[0002] DVB-MHPでは、放送装置は複数のアプリケーションプログラム（以下、「アプリ」 t\ヽ う）を定義して放送することが可能であり、アプリケーションプログラム実行装置 (以下 、「アプリ実行装置」という）（デジタル TV、 STB等）は、受信した複数のアプリを同時に 実行できる。アプリは複数のクラスファイルと、複数のデータファイルとから構成され、 アプリを構成するそれらのファイルはトランスポートストリーム（以下、「TS」という）に多 重化され、放送される。

[0003] アプリの伝送方式には、オブジェクトカルーセルが用いられる。オブジェクトカルー セルとは、 TS内で配送されるファイルシステムであり、 DVB- MHPにおいて、アプリを 構成するファイルを配送するための手段である。オブジェクトカルーセルでは、アプリ を構成する各ディレクトリやファイルの階層構造を定期的に送信する。

具体的に説明すると、放送装置はまず、送信するサービスにおいて、 Root直下に 属するディレクトリ及びファイルのみをアプリ実行装置に送信する。続いて、それぞれ のディレクトリに属するディレクトリ及びファイルを逐次送信する。アプリ実行装置は、 それらを逐次キャッシュしていく。そして、そのアプリを構成する全ファイルがキヤッシ ュされていなくても（例えば、 mainルーチンにあたるクラスファイルを含むディレクトリの 下位に属するディレクトリがまだキャッシュされていない状態）、アプリの起動に必要な 最小限のファイルがあれば当該アプリは実行される。例えば、 mainルーチンにいたる までのファイルパスがキャッシュ上にそろって!/、ると、 mainルーチンにあたるクラスファ イノレはロードされ、そのインスタンスが実行されれば、アプリは実行される。

[0004] なお、先行技術としては特許文献 1に記載されたものがある。

特許文献 1：特開 2000— 358233号公報 非特許文献 1：規格書（ファイル名； Tsl01812.V1.2.1.pdf ドキュメント名； Digital Vide o Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.2) 第 39 頁 2004年 9月 9日現在、 http：〃 www.mhp.org/力らダウンロード可能

発明の開示

発明が解決しょうとする課題

[0005] ところで、アプリの構成ファイルの一部だけ力メモリ上にキャッシュされた状態でアブ リが動作している場合に、ユーザ操作、またはアプリによる操作によりサービスの切り 替えが生じる場合がある。そのサービスの切り替え力 当該アプリを送信している TS 力も他の TSへのチューニングを伴い、かつ、当該アプリの起動が許可されないサー ビスへの切り替えである場合に問題となる。

[0006] 前述のようなサービス切り替えが生じると、アプリの終了処理が実行される力 MHP 仕様では、アプリは終了処理を記述可能であり、アプリ実行装置はアプリを終了する 際にはそのアプリの終了処理を実行する。力かる終了処理において、未キャッシュの クラスファイルが必要になる場合がある。例えば、終了処理が独立したクラスファイル で記述されている場合等である。このとき、終了処理に関するクラスファイルがキヤッ シュされて ヽな 、ので、終了処理にぉ 、てエラーが発生する。

[0007] つまり、終了処理において、動作中の一部のアプリが mainルーチンである場合は、 プログラムが使用しているローカル変数等をスタックに退避させ、動作再開に備える ための処理である suspend処理を行うが、クラスファイルが未キャッシュであると、正常 に suspend処理が行われな!/、。 mainルーチンが何らかの設定をユーザから受け付け ていた場合、 suspend処理の異常により、 mainルーチンにおけるユーザ設定が消失す る可能性がある。ユーザ設定が消失すると、サービス切り替え前の元のサービスが再 び選択された場合に、ユーザは改めて設定を入力しなければならない。また、端末 装置がフリーズ、またはダウンすることも考えられる。ここで、 suspend処理を実行する にあたり、 mainルーチン力 クラスファイルが未キャッシュであるか否かのチェックを行 えば、かかるユーザ設定の消失、及びアプリがフリーズ、またはダウンすることは避け られる。し力し、この場合、 mainルーチンのコードが増大し、 mainルーチンのロードに 多大な時間が力かるという別の問題が生じる。 [0008] 本発明は上記問題に鑑みてなされたものであって、アプリの終了処理の安定をロー ド時間の長期化を避けつつ実現することができるアプリ実行装置を提供することを目 的とする。

課題を解決するための手段

[0009] 上記課題を解決するために、本発明は、選択したサービス内でのみ実行可能なァ プリケーシヨンプログラムを実行するアプリケーションプログラム実行装置であって、キ ャッシュ手段と、ユーザ力 サービスの選択を受け付ける受付手段と、放送装置から 送信されるオブジェクトカルーセルから、ユーザが選択したサービスに係るアプリケー シヨンプログラムを構成するファイルを受信し、前記キャッシュ手段に書き込む受信手 段と、前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成す るファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして！/ヽ る力否かを判断する判断手段と、前記ファイルをキャッシュしていると判断すれば、前 記キャッシュ手段にキャッシュされたアプリケーションプログラムを実行させる実行制 御手段と、を含むアプリケーションプログラム実行装置である。

発明の効果

[0010] 本発明は、上記の構成を備えることにより、前記キャッシュ手段が前記サービスにお けるアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実行する ために必要なファイルをキャッシュするまでは、アプリケーションプログラムは実行され ない。よって、アプリケーションプログラムの終了処理において、正常に suspend処理 を実行することができる。

[0011] ここで、前記実行制御手段は、アプリケーションプログラムの実行時において、ファ ィル読み込みが失敗しないことを保障する必要がある力否かを示すキャッシュ保障属 性情報を取得する取得手段を含み、前記実行制御手段は、前記取得手段により取 得されたキャッシュ保障属性情報が保障する必要がある旨を示す場合に限り実行制 御する、としても良い。

[0012] これにより、前記実行制御手段は、キャッシュ保障属性情報がアプリケーションプロ グラムの実行時にぉ 、て、ファイル読み込みが失敗しな 、ことを保障する必要の有る 旨を示す場合に限り実行制御する。つまり、キャッシュ保障属性情報によりアプリケー シヨンプログラムの特質に適した動作を選択することができる。

ここで、前記実行制御手段は、複数のアプリケーションプログラムが存在する場合 に、どのアプリケーションプログラムにリソースを優先的に配分するかを示すプライオリ ティ属性情報を取得する取得手段を含み、前記実行制御手段は、前記取得手段に より取得されたプライオリティ属性情報が既定の閾値以上の場合に限り実行制御する 、としても良い。

[0013] これにより、前記実行制御手段は、プライオリティ属性情報が既定の閾値以上の場 合に限り実行制御する。つまり、プライオリティ属性情報によりアプリケーションプログ ラムの特質に適した動作を選択することができる。

ここで、前記実行制御手段は、アプリケーションプログラムが前記サービスでのみ実 行可能か否かを示すサービスバウンド属性情報を取得する取得手段を含み、前記実 行制御手段は、前記取得手段により取得されたサービスバウンド属性情報が前記サ 一ビスでのみ実行可能である旨を示す情報である場合に限り実行制御する、としても 良い。

[0014] これにより、前記実行制御手段は、サービスバウンド属性情報が、前記アプリケーシ ヨンプログラムが前記サービスでのみ実行可能である旨を示す情報である場合に限り 実行制御する。つまり、サービスバウンド属性情報によりアプリケーションプログラムの 特質に適した動作を選択することができる。

ここで、前記判断手段による判断は、アプリケーションプログラムを構成する全フアイ ルに関する情報に基づ 、て行われる、としても良 、。

[0015] これにより、サスペンド処理を実行するために必要なファイルがキャッシュされている か否かを判断することができる。

ここで、前記実行制御手段は、前記情報において、前記アプリケーションプログラム を構成するファイルを含んでいるディレクトリである力否かを示すディレクトリ属性を抽 出する抽出手段を含み、前記サービスに係るアプリケーションプログラムを構成する ファイルのうち、サスペンド処理を実行するために必要なファイルとは、前記抽出手段 により抽出されたディレクトリ属性力 当該アプリケーションプログラムのファイルを含 んで 、る旨を示すディレクトリ内のファイルであるとしても良 、。 [0016] これにより、ディレクトリ属性に従い、当該アプリケーションプログラムを構成するファ ィルを含んで 、る旨を示すディレクトリ内のサスペンド処理を実行するために必要な ファイルがキャッシュされれば、前記実行制御手段は当該アプリケーションプログラム を実行させる。よって、例えば複数のアプリが存在する場合であっても、ディレクトリ属 性に示されるディレクトリ内のサスペンド処理を実行するために必要なファイルをキヤ ッシュすれば良いので、より早くアプリケーションプログラムを起動することができる。

[0017] ここで、選択したサービス内でのみ実行可能なアプリケーションプログラムを実行す るアプリケーションプログラム実行装置であって、キャッシュ手段と、ユーザからサービ スの選択を受け付ける受付手段と、放送装置力 送信されるオブジェクトカルーセル から、ユーザが選択したサービスに係るアプリケーションプログラムを構成するフアイ ルを受信し、前記キャッシュ手段に書き込む受信手段と、前記キャッシュ手段が前記 サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理 を実行するために必要なファイルをキャッシュして 、るか否かをチェックするインター フェイス手段とを含み、前記アプリケーションプログラムは、メインルーチンが起動され ると前記インターフェイス手段を通じて、前記キャッシュ手段がアプリケーションプログ ラムを構成するファイルのうち、サスペンド処理を実行するために必要なファイルをキ ャッシュして!/、るか否かをチェックし、キャッシュされて!/、なければキャッシュされるま で実行を待機し、キャッシュされると実行を継続するアプリケーションプログラム実行 装置としても良い。

[0018] これにより、アプリケーションプログラムは前記インターフェイス手段を通じて、前記 キャッシュ手段がサスペンド処理を実行するために必要なファイルをキャッシュして ヽ る力否かを判断することができる。キャッシュするまでは実行を待機することにより、終 了処理にぉ 、て、正常に suspend処理を実行することを保障することができる。

ここで、所定のサービス内でのみ実行可能なアプリケーションプログラムを実行する アプリケーションプログラム実行装置であって、キャッシュ手段と、前記所定のサービ スに係るアプリケーションプログラムを構成するファイルを記録媒体力 読み出し、前 記キャッシュ手段に書き込む書き込み手段と、前記キャッシュ手段が前記所定のサー ビスに係るアプリケーションプログラムを構成するファイルのうち、サスペンド処理を実 行するために必要なファイルをキャッシュして 、る力否かを判断する判断手段と、前 記ファイルをキャッシュして 、ると判断すれば、前記キャッシュ手段にキャッシュされた アプリケーションプログラムを実行させる実行制御手段と、を含むアプリケーションプ ログラム実行装置としても良い。

[0019] これにより、アプリケーションプログラムを構成するファイルを記録媒体力 読み出し た場合であっても、サスペンド処理を実行するために必要なファイルをキャッシュする までは、アプリケーションプログラムは実行されない。よって、アプリケーションプロダラ ムの終了処理にぉ 、て、正常に suspend処理を実行することができる。

図面の簡単な説明

[0020] [図 1]システム図である。

[図 2]アプリ実行装置の機能ブロック図である。

[図 3]AITから抽出されるアプリに関する情報を示す図である。

[図 4]アプリ実行装置のレイヤ構成図である。

[図 5]オブジェクトカルーセルの説明図である。

[図 6]TSとその構成要素である TSパケットのシンタックスの一例を示す模式図である。

[図 7]2つの放送番組を含む TSの一例を示す模式図である。

[図 8]アプリ実行装置の処理手順を示すフローチャートである。

[図 9]アプリ管理部によるアプリ実行制御処理を示すフローチャートである。

[図 10]オブジェクトカルーセルで配送されるファイルシステムの具体例を示す図であ る。

[図 11]第二実施形態におけるアプリ実行装置の機能ブロック図である。

[図 12]DVB-MHP規格に、キャッシュ保障属性 CGを追加した場合の具体例を示す図 である。

[図 13]第二実施形態におけるアプリ実行装置の処理手順を示すフローチャートであ る。

[図 14]アプリ管理部によるアプリ実行処理を示すフローチャートである。

[図 15]第三実施形態におけるアプリ実行装置の機能ブロック図である。

[図 16]DVB-MHP規格に、マルチディレクトリ属性を適用した場合の具体例を示す図 である。

圆 17]第三実施形態におけるアプリ実行装置の処理手順を示すフローチャートであ る。

[図 18]アプリ管理部によるアプリ実行制御処理 2を示すフローチャートである。

圆 19]第四実施形態におけるアプリ実行装置の機能ブロック図である。

[図 20]DVB-MHP規格に、キャッシュ保障属性とマルチカルーセル属性をカ卩えた場合 の具体例を示す図である。

[図 21]DVB- MHP規格における AIT内に定義されるオリジナルの application_descripto rの例を示す図である。

圆 22]第四実施形態におけるアプリ実行装置の処理手順を示すフローチャートであ る。

[図 23]アプリ管理部によるアプリ実行制御処理 3を示すフローチャートである。

[図 24]ファイルシステムが 2つのオブジェクトカルーセルに分割して配信される場合の 具体例を示す図である。

[図 25]アプリの mainルーチンが実行制御を行う場合のフローチャートである。

符号の説明

10 アプリ実行装置

10a アプリ実行装置

10b アプリ実行装置

10c アプリ実行装置

20 放送装置

101 サービス受付部

102 受信部

103 分離部

104 アプリ管理部

104a アプリ管理部

104b アプリ管理部

104c アプリ管理部 105 アプリ制御部

105a アプリ制御部

105b アプリ制御部

105c アプリ制御部

106 キャッシュ完了監視部

106b ディレクトリ別キャッシュ完了監視部

106c キャッシュ完了監視部

107 カルーセル記憶部

107c カルーセル記憶部

108 アプリ実行部

109 デコード部

110 出力部

401 Java (登録商標）プラットフォーム

402 Java (登録商標） I/O

403 DSM-CC

404 デコーダ

405 アプリケーションマネージャ

406 Java (登録商標)仮想マシン

407 クラスローダ

408 ヒープ領域

409 スレッド杳 ^

410 カルーセル受信部

1101 キャッシュ保障属性抽出部

1501 マルチディレクトリ属性抽出部

1901 マルチカルーセル属性抽出部

1902 カルーセル記憶部

1903 キャッシュ完了監視部

発明を実施するための最良の形態 [0022] 以下、本発明の実施の形態について、図面を参照しながら説明する。

(第一実施形態）

本発明に係るアプリ実行装置の実施形態について説明する。先ず始めに、本発明 に係るアプリ実行装置の実施行為のうち、使用行為についての形態を説明する。本 実施形態に係るアプリ実行装置は、図 1に示すようなデジタル放送システムでユーザ の使用に供される。図 1に示すデジタル放送システムは、 DVB-MHPに代表されるデ ジタル放送規格に準拠した従来のデジタル放送システムをベースにしており、アプリ 実行装置 10と、放送装置 20とから構成される。

[0023] 放送装置 20は、 MPEG2(Motion Picture Experts Group phase2)形式の TSを、放送 チャネルを使って放送する。 TSには放送番組の構成要素が多重化されている。放送 番組は少なくとも、 1つ以上のアプリを構成要素として含んでおり、一般的には、映像 データ及び音声データも構成要素として含む。アプリは複数のクラスファイルと、複数 のデータファイルと力も構成される。アプリの伝送方式には、オブジェクトカルーセル が用いられる。

[0024] アプリ実行装置 10は、放送装置 20より受信した TSから分離した各アプリを実行する 。一般的には、さらに映像データ及び音声データを再生し、出力する。

以上がアプリ実行装置 10の使用行為についての形態である。続いて、アプリ実行 装置 10の生産行為の形態について説明する。

<構成>

図 2は、アプリ実行装置 10の構成を示す機能ブロック図である。図 2に示すようにァ プリ実行装置 10は、サービス受付部 101と、受信部 102と、分離部 103と、アプリ管 理部 104と、カルーセル記憶部 107と、アプリ実行部 108と、デコード部 109と、出力 部 110とを含んで構成される。

[0025] サービス受付部 101は、サービス選択を管理する。具体的には、リモコン信号から のユーザの指示やアプリからの指示によるサービスの変更要求を受け取り、受信部 1

02に通知する。

受信部 102は、選択されたサービスが配信されている TSの搬送波の周波数におけ る信号をアンテナやケーブル力 受信し、復調する。そして分離部 103に復調した TS を送出する。ここで、信号をデジタル回線力 取得するアプリ実行装置である場合に は復調機能は省略される。

[0026] 分離部 103は、受信部 102より送出された TSを受け取ると、 TSに多重化されている ビデオ'オーディオデータと、オブジェクトカルーセルと、アプリの制御に関する情報 である AIT(Application Information Table)とに分離する。そして、ビデオ'オーディオ データをデコード部 109に、オブジェクトカルーセルをカルーセル記憶部 107に、ァ プリの制御に関する情報である AITをアプリ制御部 105にそれぞれ提供する。

[0027] アプリ管理部 104は、アプリのライフサイクルの管理を行う。アプリ管理部 104は、ァ プリ制御部 105と、キャッシュ完了監視部 106とを含んで構成される。

アプリ制御部 105は、 AITの中からサービス受付部 101より通知されたサービスに おいて起動すべきアプリに関する情報を抽出する。また、キャッシュ完了監視部 106 力ものキャッシュ完了通知を待ってから、アプリ実行部 108にアプリの実行開始指示 を行う。また、キャッシュ完了監視部 106に抽出したアプリに関する情報を渡す。ここ で具体的には、 AIT力 抽出されるアプリに関する情報は、図 3に示すように base_dire ctory301と、 initial—class302と、 classpath— extension303と力ら構成される。

[0028] base_directoryは、アプリの mainルーチンが格納されているディレクトリである。 base_ directoryは、自動的にクラスパス上の最初のディレクトリを形成するものとみなされる。 initiaLclassは、 base_directoryと組になる情報であり、最初に起動すべきクラスフアイ ルの名称を示す。

[0029] classpath_extensionは、 mainルーチン以外のクラスファイルを示す。

キャッシュ完了監視部 106は、アプリの構成ファイルが全てキャッシュされているか 否かを判断し、全てキャッシュされていればアプリ制御部 105にキャッシュの完了を 通知する。

カルーセル記憶部 107は、選択されたサービスに対応するアプリに係るオブジェク トカル一セルをファイルシステムとして参照可能な状態でキャッシュする。そして、ァプ リ実行部 108からのファイルの読み込み要求に応じてファイルを提供する。ここでキヤ ッシュするとは、具体的には、メモリなどの記憶装置に記憶することをいう。

[0030] アプリ実行部 108は、アプリ制御部 105から指示されたアプリの構成ファイルをカル 一セル記憶部 107から読み込み、実行開始指示があると、それらを解釈し、実行する 。アプリ実行部 108は、具体的には DVB-MHPにおける Java (登録商標)仮想マシンで ある。

デコード部 109は、分離部 103からビデオ ·オーディオデータを受け取り、復号する

[0031] 出力部 110は、復号されたビデオ'オーディオデータ及びアプリ実行部 108より送 出されるグラフィックスを出力する。

続いて図 4は、アプリ実行装置 10の機能ブロック図を実際に実装する際のハードウ エアのレイヤ構成に置き換えて、詳細に描いた図の一例である。本図に示すようにァ プリ実行装置 10は、 Java (登録商標）プラットフォーム 401と、 Java (登録商標） 1/040 2と、 DSM—CC (Digital Storage Media Command and Control) 403と、デコーダ 404と を含んで構成される。

[0032] Java (登録商標）プラットフォーム 401は、 Java (登録商標）仮想マシン 406と、アプリ ケーシヨンマネージャ 405とからなる。 Java (登録商標）仮想マシン 406は、 Java (登録 商標）言語で記述された Java (登録商標)オブジェクトを、アプリ実行装置 10における CPUのネイティブコードに変換して、 CPUに実行させる。より詳細には、アプリケーショ ンを構成する xletプログラムをヒープ領域にロードして、 xletプログラムを解読し、解読 結果に従って、制御を行う。

[0033] Java (登録商標）仮想マシン 406は、クラスローダ 407と、ヒープ領域 408と、スレッド 部 409とを含んで構成される。

クラスローダ 407は、クラスファイルを DSM- CC403からヒープ領域 408に読み出す 。クラスローダ 407によるクラスファイルの読み出しは、ファイルパスを用いることにより なされる。ファイルパス力 ¾SM- CC403を示しているなら、クラスローダ 407は、クラス ファイルを DSM- CC403からヒープ領域 408に読み出す。

[0034] ヒープ領域 408は、様々なクラスファイルのインスタンスが格納される。このインスタ ンスが、アプリを構成する xletプログラムである。かかる xletプログラムがヒープ領域 40 8に配置されることにより、アプリは実行可能な状態になる。

スレッド部 409は、ヒープ領域 408に格納されたインスタンスを実行する論理的な実 行主体である。

[0035] アプリケーションマネージャ 405は、クラスローダ 407にクラスのロードを指示する。

また、 Java (登録商標） 1/0402がアプリを構成する全てのファイルにおいて successを 返したか否かを判断する。全てのファイルについて successの場合にスレッド部 409に 実行開始指示を行う。ここで、全てのファイルについて successの場合とは、一度 false になった後に再度ロードを指示した結果、 successになったファイルも含む。また、全 てのファイルにおいて successであるか否かは、 AIT力も抽出されるアプリに関する情 報に基づいて判断される。

[0036] Java (登録商標） 1/0402は、クラスローダ 407からのクラスファイルのロードに対し、 successまたは falseをアプリケーションマネージャ 405に返す。具体的には、クラスロー ダ 407よりファイルパスを指定したロード指示があると、 DSM- CC403に指定されたク ラスファイルがキャッシュされて 、るか否かを判断する。指定されたファイルがキヤッシ ュされていると、ヒープ領域 408にクラスファイルをロードする。そして、 successをァプ リケーシヨンマネージャ 405に通知する。クラスファイルが未キャッシュの場合は、 false をアプリケーションマネージャ 405に通知する。

[0037] DSM- CC403は、クラスファイルのキャッシュを管理する。

カルーセル受信部 410は、オブジェクトカルーセルを受信し、キャッシュする。

デコーダ 404は、ビデオ ·オーディオデータをデコードする。

くデータ >

続いて、図 5 (a)及び図 5 (b)はオブジェクトカルーセルによるアプリの構成ファイル の送信方法を示す図である。図 5 (a)は、放送装置 20により送信されるファイルシス テムを示す。図 5 (b)は、放送装置 20からアプリ実行装置 10にファイルシステムの一 部が送信されている様子を示す。図 5 (b)に示すように、ファイルシステムは一度に送 信されるわけではなぐ階層毎に分けて、定期的に繰り返し送信される。つまり、アブ リ実行装置 10は、任意の時刻から 1周期分のファイルを獲得し、アプリ実行装置 10内 のメモリに展開することで、ファイルを復元する。

[0038] 図 6は TSとその構成要素である TSパケットのシンタックスの一例を示す模式図であ る。 TSは多数の TSパケットで構成され、それぞれの TSパケットは 188バイトで構成され る。それぞれの TSパケットは各 TSパケットに対する情報を提供するヘッダと、実際の データが記録されるペイロードとからなる。

ヘッダは、シンクバイトと、ペイロード単位開始表示子と、伝送優先順位と、パケット 識別子 (PID)と、スクランプリング制御と、適応フィールド制御と、連続性カウンタと、 適応フィールドとから構成されており、それぞれ所定のビットが割り当てられており、 T Sパケットに対する情報を提供する。

[0039] ペイロードは、パケットィヒされたオーディオ 'ビデオデータ及びサービスデータを含 む。それぞれのパケットィ匕されたオーディオ 'ビデオ及びサービスデータは、パケット 識別子で識別される。オーディオ 'ビデオ及びサービスデータは、パケット単位に TS にそれぞれ多重化され、放送装置 20よりアプリ実行装置 10に伝送される。

続!、て、図 7はサービス Aとサービス Bの 2つの放送番組を含む TSの一例を示す模 式図である。ここで、それぞれの放送番組は 1つのオーディオデータ及びビデオデー タと、アプリの制御に関する情報である AITと、アプリの構成ファイルを含むオブジェク トカル一セルが多重化されて伝送されるとする。 TSに含まれる放送番組は、 PMT(Pro gram Map Table)と呼ばれるテーブルを配送する TSパケットで表現される。その TSパ ケットの PIDは、 PID力 である PAT(Program Association Table)と呼ばれるテーブルを 配送する TSパケットに示されている。ここで PMTとは、あるサービスに含まれる映像や 音声、 AITなどの PIDを格納したものである。この PIDにより TSパケットの種類が識別さ れる。 PMTを参照することにより、ストリームの中から目的のプログラムを構成する TS パケットだけを取り出すことができる。それら PIDのついたパケットを集めることによって 元の動画を再生することが可能となる。

[0040] 図 7の例ではサービス Aの PIDは 100、サービス Bの PIDは 200である。さらに、 PMTに はオーディオデータと、ビデオデータと、 AITと、アプリの構成ファイルを含むファイル システムを配送するオブジェクトカルーセルのそれぞれの PIDが含まれる。図 7の例で はサービス Aのオーディオデータは 101、ビデオデータは 102、 AITは 103、オブジェク トカル一セルは 104の PIDを持つ TSパケットでそれぞれ配送される。また、オブジェクト カルーセルのコンポーネントタグは 1104である。また、 AITにはアプリの起動や停止な どの制御指示や、そのアプリを配送するオブジェクトカルーセルのコンポーネントタグ (オブジェクトカルーセルの PIDを導くためのリンク情報)や、そのアプリを起動する際 に最初に使用するファイルのパスなどアプリの制御に必要な情報が含まれており、ァ プリ実行装置 10は基本的に再生中の番組情報に含まれる AITにしたがって、アプリ の制御を行う。

<動作 >

次に、アプリ実行装置 10の処理動作について説明する。図 8は、アプリ実行装置 1 0の処理手順を示すフローチャートである。まず、サービス受付部 101は、ユーザによ るリモコン操作や、アプリからの要求、または電源オン時の初期設定により指定された サービスに対応する数値を受け付け、受信部 102に通知する（S801)。受信部 102 は、受け付けた数値に対応するサービスの搬送波にチューニングし、 TSを受信する。 そして、受信した TSをデジタルデータに復調する（S802)。分離部 103は、 TSに多重 化されている PMT、 PATを取得し、 PMTに格納された PIDからビデオ ·オーディオデー タ、オブジェクトカルーセル、 AITを特定し、分離する（S803)。デコード部 109は、分 離部 103により分離されたビデオ'オーディオデータをデコードし、出力部 110は、デ コード部 109によりデコードされたデータを出力する（S804)。カルーセル記憶部 10 7は、選択されたサービスにおいて、起動対象となるアプリに係るオブジェクトカルー セルをキャッシュする（S805)。アプリ管理部 104は、アプリ実行制御処理を行う（S8 06)。

続いて図 9は、アプリ管理部 104によるアプリ実行制御処理に関するフローチャート を示す図である。アプリ管理部 104は、 AITから抽出されるアプリに関する情報である i nitial_class302に対応するクラスファイルのロードをアプリ実行部 108に指示する（S9

01)。カルーセル記憶部 107にロード対象のファイルがある力否かが判断される（S9

02)。ある場合は、アプリ実行部 108に initial_class302に対応するクラスファイルが読 み出され、アプリ管理部 104は、 Java (登録商標） I/Oより successを受け取る（S903)

。ない場合は、アプリ管理部 104は Java (登録商標） I/Oより falseを受け取る（S904)。 アプリ管理部 104は、他にアプリに関するクラスファイルが存在するカゝ否かを判断す る（S905)。具体的には、 AIT力 抽出されるアプリに関する情報である base_director y301及び classpath_extension303に基づ!/、て判断する。存在する場合は、 base.dire ctory301または classpath_extension303に示されるアプリを構成するファイルのロード をアプリ実行部 108に指示する（S906)。ステップ S902に移行する。存在しない場 合は、アプリ管理部 104は、アプリに関する全てのクラスファイルについて successを 受信したカゝ否かを判断する（S907)。判断結果が否定の場合は、 falseになったクラス ファイルのロードを再度指示する（S908)。判断結果が肯定の場合は、アプリ管理部 104はアプリ実行部 108に実行開始指示を行う。アプリ管理部 104によりアプリの実 行開始を指示されたアプリ実行部 108は、ロードされたクラスファイルを解釈し、実行 する（S909)。

[0042] 続いて、図 10はオブジェクトカルーセルで配送されるファイルシステム FS1の具体 例である。ファイルシステム FS1には 2つのアプリが含まれる。 1つはアプリ 1であり、も う一方はアプリ 2である。アプリ 1は、ファイル F1とファイル FCとで構成され、一方のァ プリ 2は、ファイル F2とファイル FCとで構成される。ここで、起動対象のアプリがアプリ 1であった場合、アプリ制御部 105は、キャッシュ完了監視部 106からのキャッシュ完 了通知を待ってアプリ実行部 108に対し実行開始指示を行う。したがって、力ルーセ ル記憶部 107は、ファイルシステム FS1に示す全てのファイルをキャッシュして!/、るの で、ファイルのキャッシュ処理を行うことなくアプリ実行部 108からのファイルの読み込 み要求に応答可能となる。よって、受信部 102からデータを受け取れない状態に陥 つたとしてもファイルの読み込みを保障することが可能である。

[0043] 以上のように本実施の形態によれば、アプリ制御部 105は、キャッシュ完了監視部 1 06からのキャッシュ完了通知を受け取った後に、アプリ実行部 108に実行開始指示 を行う。よって、アプリを構成するファイルが未キャッシュの状態でアプリが動作するこ とはないので、アプリの終了処理において、動作の安定が保障される。

また、アプリの構成ファイルの一部がメモリ上にキャッシュされた状態でアプリが動作 し、動作中に当該アプリ、またはその他のアプリが Tuning APIを実行する場合がある 。そのような場合であっても、上記に示したように、キャッシュ完了監視部 106からの キャッシュ完了通知を待って力 アプリを実行することにより、アプリの終了処理を保 障することができる。

[0044] また、アプリの構成ファイルの一部がメモリ上にキャッシュされた状態で動作し、動 作中に例えば、ケーブルを抜く行為等により受信状況が悪化し、 TSが受信不可能に なる場合がある。そのような場合であっても、上記に示したように、キャッシュ完了監視 部 106からのキャッシュ完了通知を待って力もアプリを実行することにより、アプリの終 了処理を保障することができる。

(第二実施形態）

第一実施形態では、ファイルシステム上のアプリの構成要素である全てのファイル をアプリ実行装置 10にキャッシュした後に、アプリを起動することにより、その後 TSの 変更があつたとしても、アプリの実行時においてファイル読み込みが失敗しないことを 保障した。し力しながら、アプリによってはファイル読み込みの保障は不要であり、起 動開始までの時間を速くした方が好適であるものも存在する。そこで本実施形態は、 アプリの特徴に合わせてアプリ毎に処理を変更する実施の形態である。

[0045] 本実施形態では、図 1に示すデジタル放送システムにお 、て、放送番組は、第一 実施形態で示した構成要素に加え、アプリの実行時にぉ ヽてファイル読み込みが失 敗しな 、ことを保障する必要がある力否かを示す属性 (以下、「キャッシュ保障属性」 という）を構成要素として含む。

図 11に本実施形態におけるアプリ実行装置 10aの機能ブロック図を示す。図 11に 示すように、アプリ実行装置 10aは、第一実施形態のアプリ実行装置 10の構成に加 えて、キャッシュ保障属性抽出部 1101を含む。

[0046] キャッシュ保障属性抽出部 1101は、 TS中のアプリの制御に関する情報である AIT から、キャッシュ保障属性を抽出し、アプリ制御部 105aに提供する。

また、本実施形態におけるアプリ制御部 105aは、サービス受付部 101によって指 定されたサービスの AITから起動すべきアプリの情報を抽出する。また、キャッシュ完 了監視部 106に抽出したアプリに関する情報を渡す。また、キャッシュ保障属性抽出 部 1101よりキャッシュ保障属性を受け取ると、アプリのキャッシュ保障属性が、フアイ ル読み込みが失敗しな ヽことを保障する必要の有る旨を示す属性カゝ否かを判断する 。判断結果が肯定である場合には、キャッシュ完了監視部からのキャッシュ完了通知 を待ってから、アプリ認証とアプリの実行開始指示を行う。判断結果が否定である場 合には、キャッシュ完了監視部力ものキャッシュ完了通知を待たずにアプリ実行部 10 8にアプリの実行開始指示を行う。

[0047] 図 12は、 DVB-MHP規格に、キャッシュ保障属性 CGを追カ卩した場合の具体例を示 す図である。図 12において、 DVB- MHPにおける AITでは、キャッシュ保障属性 CG は、 AIT内に定 れる application— descriptorの cache— guarantee— flagフィ ~~ノレトとして 追加される。

<動作 >

続いて、本実施形態におけるアプリ実行装置 10aの動作について説明する。

[0048] 図 13は、アプリ実行装置 10aの処理手順を示すフローチャートである。まず、サー ビス受付部 101は、ユーザによるリモコン操作や、アプリからの要求、または電源オン 時の初期設定により指定されたサービスに対応する数値を受け付け、受信部 102に 通知する（S1301)。受信部 102は、受け付けた数値に対応するサービスの搬送波 にチューニングし、 TSを受信する。そして、受信した TSをデジタルデータに復調する（ S1302) _o分離部 103は、 TSに多重化されている PMT、 PATを取得し、 PMTに格納さ れた PIDからビデオ.オーディオ、オブジェクトカルーセル、 AITを特定し、分離する（S 303)。デコード部 109は、ビデオ'オーディオデータをデコードし、出力部 110は、デ コードされたデータを出力する（S1304)。カルーセル記憶部 107は、選択されたサ 一ビスにお 、て、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュす る（S1305)。アプリ管理部 104aは、キャッシュ保障属性抽出部 1101よりキャッシュ 保障属性を受け取る。そして、キャッシュ保障属性が保障する必要がある旨を示す属 性であるか否かを判断する（S 1306)。判断が肯定の場合は、アプリ管理部 104aは 、図 9に示したアプリ実行制御処理を行う（S 1307)。判断が否定の場合は、アプリ管 理部 104aは、アプリ実行処理を行う（S 1308)。

[0049] 続いて図 14は、アプリ管理部 104aによるアプリ実行処理に関するフローチャートを 示す図である。アプリ管理部 104aは、 AITから抽出されるアプリに関する情報である i nitial_class302に対応するクラスファイルのロードをアプリ実行部 108に指示する（SI 401)。カルーセル記憶部 107にロード対象のファイルがある力否かが判断される（S 1402)。ある場合は、アプリ実行部 108に initial_class302に対応するクラスファイル が読み出され、アプリ管理部 104aは、 Java (登録商標） I/Oより successを受け取る（S 1404)。そして、アプリ管理部 104aはアプリ実行部 108に実行開始指示を行う。アブ リ管理部 104aによりアプリの実行開始を指示されたアプリ実行部 108は、ロードされ たクラスファイルを解釈し、実行する（S 1405)。ない場合は、アプリ管理部 104aは Ja va (登録商標） I/Oより falseを受け取る（S 1403)。 S1401に移行する。アプリ管理部 1 04aは、他にアプリに関するクラスファイルが存在するか否かを判断する（S1406)。 具体的には、 AIT力も抽出されるアプリに関する情報である base_directory301及び cl asspath_extension303に基づいて判断する。存在しない場合は、処理を終了する。 存在する場合は、他のファイルの読み込みが必要カゝ否かを判断する（S 1407)。他の ファイルの読み込みが必要であれば、アプリ管理部 104aは必要なファイルのロード を指示する（S1408)。カルーセル記憶部 107にロード対象のファイルがあるか否か が判断される（S 1409)。ある場合は、アプリ実行部 108にクラスファイルが読み出さ れ、アプリ管理部 104aは、 Java (登録商標） I/Oより successを受け取る（S1411)。そ して、アプリ実行部 108は読み出したクラスファイルを実行する（S 1405)。ない場合 は、アプリ管理部 104aは Java (登録商標） I/Oより falseを受け取る（S 1410)。 S 1408 に移行する。以上のように、アプリ実行処理では、キャッシュ完了通知を待たずに、ァ プリ管理部 104aはアプリ実行部 108にアプリの実行開始指示を行う。そして、アプリ 管理部 104aによりアプリの実行開始を指示されたアプリ実行部 108は、最初に実行 対象となるクラスファイルの読み込み処理を行 ヽ、そのクラスファイルを解釈 ·実行す る。さらに、解釈'実行の過程で必要になったその他のアプリの構成ファイルについて 、読み込み処理をその都度行い、読み込んだクラスファイルを解釈 '実行する。

続いて図 10を用いて説明する。図 10におけるオブジェクトカルーセルで配送され るファイルシステム FS 1の具体例において、起動対象のアプリがアプリ 1であり、かつ 、キャッシュ保障属性が保障する必要がある旨を示す属性であった場合は、第一実 施形態と同様の処理を行う。つまり、アプリ制御部 105aは、キャッシュ完了監視部 10 6からのキャッシュ完了通知を待ってアプリ実行部 108に実行開始指示を送る。した がって、カルーセル記憶部 107は、ファイルのキャッシュ処理を行うことなくファイルの 読み込み要求に応答可能となるため、受信部 102からデータを受け取れない状態に 陥ったとしてもファイルの読み込みを保障することが可能である。 [0051] 一方、起動対象のアプリがアプリ 1であり、かつ、キャッシュ保障属性が保障する必 要がある旨を示す属性でない場合は、アプリ制御部 105aはキャッシュ完了監視部 1 06からのキャッシュ完了通知を待たずに、アプリ実行部 108にアプリの起動指示を行 う。そのため、カルーセル記憶部 107は、アプリ実行部 108からのファイルの読み込 み要求に対して、できるだけレスポンスよく応答し、ファイルの読み込み要求がない空 き時間を利用して、キャッシュが完了して ヽな 、ファイルのキャッシュを行うと!、う処理 をする。したがって、全てのファイルがキャッシュされるのを待つ場合よりアプリの起動 が早い。

[0052] 以上のように本実施の形態によれば、キャッシュ保障属性によりファイルの読み込 みを保障する必要があるアプリと、保障は不要で起動速度やメモリ効率を優先したい アプリとのそれぞれに適した起動方法を選択することができる。

なお、本実施形態では、キャッシュ保障属性を新たに AITに含まれる属性として追 加し、用いたが、これに限らない。例えば、図 12に示される AITの既存属性であるプ ライオリティ属性 APを用いても良いし、サービスバウンド属性 SBを用いても良い。ブラ ィオリティ属性 APとは、複数のアプリが存在する場合に、どのアプリにリソースを優先 的に配分するかを示す属性である。サービスバウンド属性 SBは、アプリがサービスバ ゥンド力否かを示す属性である。アプリがサービスバウンドの場合は、他のサービスに 切り替わるとアプリは終了される。例えば、プライオリティ属性を用いる場合は、アプリ 制御部 105aは、プライオリティ情報が既定の閾値以上力否かを判断する。そして、 既定の閾値以上の場合には、アプリ制御部 105aはキャッシュ完了監視部 106からの キャッシュ完了通知を待ってから、実行指示を行うとしても良い。

[0053] また、サービスバウンド属性を用いる場合には、アプリ制御部 105aは、サービスバ ゥンド属性がサービスバウンドか否かを判断する。そして、サービスバウンドの場合に は、アプリ制御部 105aはキャッシュ完了監視部 106からのキャッシュ完了通知を待つ てから、実行指示を行うとしても良い。これにより、アプリの構成ファイルの一部がメモ リ上にキャッシュされた状態でサービスバウンドアプリが動作している最中に、チュー ユングを伴い、かつ、そのアプリの起動が許可されていないサービスへの切り替えが あった場合であっても、その後アプリを終了する際には、正常にアプリの終了処理を 行うことができる。

(第三実施形態）

第一実施形態では、ファイルシステムに複数のアプリを構成するファイルが存在す る場合に、それらの全てのファイルがキャッシュされてから開始指示をしていた。しか し、例えばファイルシステム上に存在する複数のアプリのうち、一つのアプリだけが起 動対象である場合が考えられる。その場合においても、複数のアプリの全ての構成フ アイルについてキャッシュするのを待っていたのでは効率が悪い。そこで、本実施形 態のアプリ実行装置は、一のアプリを構成するファイルを他のファイルと区別できるよ うに識別子を設け、複数のディレクトリに分割された状態で配信されるファイルにお ヽ て、一のアプリの実行に必要なファイルがキャッシュされれば、実行開始指示を行う。

[0054] 本実施形態では、図 1に示すデジタル放送システムにお ヽて、アプリを構成するフ アイルは、 1つ以上のディレクトリに分割した状態で配信される。放送番組は、第二実 施形態で示した構成要素に加え、一のアプリを構成するファイルを含むディレクトリを 示す属性 (以下、「マルチディレクトリ属性」と!、う）を構成要素として含む。

図 15において、アプリ実行装置 10bは、第二実施形態のアプリ実行装置 10aの構 成に加えて、マルチディレクトリ属性抽出部 1501を含み、かつキャッシュ完了監視部 106の代わりにディレクトリ別キャッシュ完了監視部 106bを含んで構成される。

[0055] マルチディレクトリ属性抽出部 1501は、 TS中のアプリの制御に関する情報である AI 丁から、マルチディレクトリ属性を抽出し、アプリ制御部 105bに提供する。

ディレクトリ別キャッシュ完了監視部 106bは、マルチディレクトリ属性に示されるディ レクトリにおいて、アプリの構成ファイルが全てキャッシュされた力否かを判断する。マ ルチディレクトリ属性に示される全てのディレクトリ内のファイルがキャッシュされると、 アプリ制御部 105bにキャッシュ完了を通知する。

[0056] また、本実施形態におけるアプリ制御部 105bは、サービス受付部 101によって指 定されたサービスの AITから起動すべきアプリの情報を抽出する。また、キャッシュ保 障属性をキャッシュ保障属性抽出部 1101より受け取ると、アプリのキャッシュ保障属 性が、ファイル読み込みが失敗しな 、ことを保障する必要の有る旨を示す属性か否 かを判断する。判断結果が肯定である場合には、ディレクトリ別キャッシュ完了監視部 106bからのキャッシュ完了通知を待ってから、アプリ認証とアプリの実行開始指示を 行う。判断結果が否定である場合には、ディレクトリ別キャッシュ完了監視部 106bか らのキャッシュ完了通知を待たずに、アプリ実行部 108にアプリの実行開始指示を行 う。また、ディレクトリ別キャッシュ完了監視部 106bに抽出したアプリに関する情報を 渡す。

[0057] 続いて、図 16は、 DVB-MHP規格に、本実施形態特有のマルチディレクトリ属性を 適用した場合の具体例を示す図である。図 16において、 DVB-MHPにおける AITで は、マルチディレクトリ属性 MD1は AIT内に定義される application_descriptorにおけ る既存の base_directoryフィールドの流用であり、マルチディレクトリ属性 MD2は appli cation— descriptorに新規に extension— directoryフィ ~~ノレトとして追ノ J卩 れ 。ここで、マ ルチディレクトリ属性 MD1はアプリの構成ファイルの中でアプリ起動時に最初に使用 するファイルを含むディレクトリ 'ツリーのパスを示す。また、マルチディレクトリ属性 M D2はマルチディレクトリ属性 MD1で示されるディレクトリ 'ツリーに含まれないその他 のアプリの構成ファイルを含むディレクトリ.ツリーのパスを示す。

<動作 >

次に、本実施形態におけるアプリ実行装置 10bの動作を説明する。

[0058] 図 17は、アプリ実行装置 10bの処理手順を示すフローチャートである。まず、サー ビス受付部 101は、ユーザによるリモコン操作や、アプリからの要求、または電源オン 時の初期設定により指定されたサービスに対応する数値を受け付け、受信部 102に 通知する（S1701)。受信部 102は、受け付けた数値に対応するサービスの搬送波 にチューニングし、 TSを受信する。そして、受信した TSをデジタルデータに復調する（ S1702) _o分離部 103は、 TSに多重化されている PMT、 PATを取得し、 PMTに格納さ れた PIDからビデオ.オーディオ、オブジェクトカルーセル、 AITを特定し、分離する（S 1703)。デコード部 109は、ビデオ'オーディオデータをデコードし、出力部 110は、 デコードされたデータを出力する（S1704)。カルーセル記憶部 107は、選択された サービスにおいて、起動対象となるアプリに係るオブジェクトカルーセルをキャッシュ する（S1705)。アプリ管理部 104bは、キャッシュ保障属性抽出部 1101よりキヤッシ ュ保障属性を、マルチディレクトリ属性抽出部 1501よりマルチディレクトリ属性を受け 取る。そして、キャッシュ保障属性情報が保障する必要がある旨を示す情報であるか 否かを判断する（S 1706)。判断が肯定の場合は、アプリ管理部 104bは、アプリ実行 制御処理 2を行う（S 1707)。判断が否定の場合は、アプリ管理部 104bは、図 14に 示したアプリ実行処理を行う（S 1708)。つまり、ディレクトリ別キャッシュ完了監視部 1 06bからのキャッシュ完了通知を待たずにアプリ実行部 108にアプリの起動指示を行 続いて図 18は、アプリ管理部 104bによるアプリ実行制御処理 2に関するフローチ ヤートを示す図である。アプリ管理部 104bは、マルチディレクトリ属性よりアプリの構 成ファイルの中でアプリ起動時に最初に使用するファイルを含むディレクトリを特定す る（S1801)。特定されたディレクトリ内の initial_classに対応するクラスファイルのロー ドをアプリ実行部 108に指示する（S1802)。カルーセル記憶部 107にロード対象の ファイルがあるか否かが判断される（S1803)。アプリ実行部 108は、 initiaLclassに対 応するクラスファイルをロードする。ある場合は、アプリ実行部 108に initial_class302 に対応するクラスファイルが読み出され、アプリ管理部 104bは、 Java (登録商標） I/O より successを受け取る（S1804)。ない場合は、アプリ管理部 104bは Java (登録商標） I/Oより falseを受け取る（S1805)。アプリ管理部 104bは、マルチディレクトリ属性に より示されるディレクトリ内に、他にアプリに関するクラスファイルが存在するか否かを 判断する（S1806)。具体的には、 AITから抽出されるアプリに関する情報である base _directory301及び classpath_extension303に基づ!/、て判断する。存在する場合は、 base_directory301または classpath_extension303に示されるアプリを構成するフアイ ルのロードをアプリ実行部 108に指示する（S1807)。ステップ SI 803に移行する。 存在しない場合は、アプリ管理部 104bは、マルチディレクトリ属性で示されるディレク トリが他に存在するカゝ否かを判断する（S1808)。存在する場合は、ディレクトリ内のフ アイルのロードをアプリ実行部 108に指示する（S 1809)。ステップ S 1803に移行す る。存在しない場合は、アプリ管理部 104bは、マルチディレクトリ属性で示されるディ レクトリ内における全てのファイルについて successを受信したか否かを判断する（S1 810)。判断結果が否定の場合は、 falseになったクラスファイルのロードを再度指示 する（S1811)。判断結果が肯定の場合は、アプリ管理部 104bはアプリ実行部 108 に実行開始指示を行う。アプリ管理部 104bによりアプリの実行開始を指示されたァ プリ実行部 108は、ロードされたクラスファイルを解釈し、実行する（S1812)。

[0060] 続いて図 10を用いて具体的に説明する。オブジェクトカルーセルで配送されるファ ィルシステム FS1の具体例において、起動対象のアプリがアプリ 1であり、かつ、キヤ ッシュ保障属性が保障する必要がある旨を示す属性であった場合は、アプリ制御部 1 05bはディレクトリ別キャッシュ完了監視部 106bからのキャッシュ完了通知を待って から、アプリ実行部 108にアプリの起動指示を行う。ここで、ディレクトリ別キャッシュ完 了監視部 106bが監視の対象とするファイルはファイル F1及びファイル FCに限定さ れる。また、マルチディレクトリ属性 MD1は 7appl"、マルチディレクトリ属性 MD2は" /common"となる。したがって、ディレクトリ別キャッシュ完了監視部 106bはファイル F 2のキャッシュ完了を待たずにキャッシュ完了通知をアプリ制御部 105bに通知する。 よって、カルーセル記憶部 105は、ファイルのキャッシュ処理を行うことなくファイルの 読み込み要求に応答可能となるため、受信部 102からデータを受け取れない状態に 陥ったとしてもファイルの読み込みを保障することが可能である。さらにキャッシュする ファイルを限定することにより、アプリの起動を早めることができる。

[0061] 一方、起動対象のアプリがアプリ 1であり、かつ、キャッシュ保障属性が保障する必 要がある旨を示す属性でない場合は、アプリ制御部 105bはディレクトリ別キャッシュ 完了監視部 106bからのキャッシュ完了通知を待たずに、アプリ実行部 108にアプリ の起動指示を行う。そのため、カルーセル記憶部 105は、アプリ実行部 108からのフ アイルの読み込み要求に対してできるだけレスポンスよく応答し、ファイルの読み込み 要求がな!、空き時間を利用してキャッシュが完了して ヽな 、ファイルのキャッシュを行 うという処理をする。したがって、マルチディレクトリ属性に示される全てのディレクトリ 中のファイルのキャッシュ完了を待つ場合よりアプリの起動が早い。

[0062] 以上のように本実施の形態によれば、マルチディレクトリ属性に基づいてアプリの実 行に必要なファイルのみをキャッシュした後に、アプリを起動することが可能となり、よ り早くアプリを起動することができる。

(第四実施形態）

本実施形態のアプリ実行装置 10cは、アプリを構成するファイルにおいて、複数の オブジェクトカルーセルに分割した状態で配信されたファイルをキャッシュすることで 、アプリの実行に必要なファイルだけを限定的にキャッシュする。

[0063] 本実施形態では、図 1に示すデジタル放送システムにお ヽて、アプリを構成するフ アイルは、複数のオブジェクトカルーセルに分割した状態で配信され、放送番組は、 第二実施形態で示した構成要素に加え、一のアプリを構成するファイルを含むォブ ジヱクトカル一セルを示す属性 (以下、「マルチカルーセル属性」 )も構成要素として 含む。

なお、本実施形態では、アプリを構成するファイルは、二つのオブジェクト力ルーセ ルに分割した状態で配信されるとする。

[0064] 図 19において、アプリ実行装置 10cは、第二実施形態のアプリ実行装置 10aの構 成に加えて、マルチカルーセル属性抽出部 1901を含み、かつ、カルーセル記憶部 1902と、キャッシュ完了監視部 1903とを含んで構成される。

マルチカルーセル属性抽出部 1901は、 TS中のアプリの制御に関する情報である A ITから、マルチカルーセル属性を抽出し、アプリ制御部 105cに提供する。

[0065] カルーセル記憶部 1902は、選択されたサービスに含まれる一のオブジェクトカル 一セルを、ファイルシステムとして参照可能な状態で記憶する。そして、アプリ実行部 108からのファイルの読み込み要求に応じて、要求されたファイルを提供する。この 際、カルーセル記憶部 1902及びカルーセル記憶部 107のうち、アプリ実行部 108よ り要求されたファイルをキャッシュしている一方のカルーセル記憶部がファイルを提供 する。

[0066] キャッシュ完了監視部 1903は、カルーセル記憶部 1902において、オブジェクト力 ルーセルが全てキャッシュされて 、るか否かを判断し、全てキャッシュされて 、ればァ プリ制御部 105cに完了を通知する。

また、本実施形態におけるカルーセル記憶部 107cは、選択されたサービスに含ま れる他方のオブジェクトカルーセルを、ファイルシステムとして参照可能な状態で記 憶する。

[0067] また、本実施形態におけるキャッシュ完了監視部 106cは、カルーセル記憶部 107 cにおいて、オブジェクトカルーセルが全てキャッシュされているか否かを判断し、全 てキャッシュされて 、ればアプリ制御部 105cに完了を通知する。

また、本実施形態におけるアプリ制御部 105cは、サービス受付部 101によって指 定されたサービスの AITから起動すべきアプリの情報を抽出する。また、キャッシュ保 障属性をキャッシュ保障属性抽出部 1101より受け取ると、アプリのキャッシュ保障属 性が、ファイル読み込みが失敗しな 、ことを保障する必要の有る旨を示す属性か否 かを判断する。判断結果が肯定である場合には、キャッシュ完了監視部 1903及びキ ャッシュ完了監視部 106cからのキャッシュ完了通知を待ってから、アプリ認証とアプリ の実行開始指示を行う。判断結果が否定である場合には、キャッシュ完了監視部 19 03及びキャッシュ完了監視部 106cからのキャッシュ完了通知を待たずに、アプリ実 行部 108にアプリの実行開始指示を行う。また、キャッシュ完了監視部 1903及びキ ャッシュ完了監視部 106cに抽出したアプリに関する情報を渡す。

ここで、図 20は、 DVB- MHP規格に、キャッシュ保障属性 CGとマルチカルーセル属 性 MCを加えた場合の具体例を示す図である。図 20において、 DVB-MHPにおける AITでは、マルチカルーセル属性 MCは AIT内に定義される application_descriptorの t ransport_protocol_lableフィールドの拡張として追加される。キャッシュ保障属性 CGは 第二実施形態と同様である。さらに、図 21は、 DVB-MHP規格における AIT内に定義 されるオリジナルの application_descriptorの例である。マルチカルーセル属性 MCの ために拡張された部分のオリジナルの属性であるトランスポート 'プロトコル 'ラベル属 性 TPLは、複数の配送経路を示すことができる。 1つの transport_protocol_lableフィー ルドの値はアプリの全ての構成ファイルを配信して!/、るオブジェクトカルーセル、また 【ま、 IP via DVB multiprotocol encapsulationを示す。 forノレープにより複数の transport— protocoljableフィールドの値を示すことが可能であるため複数の配信経路を示すこと が可能である。一方、図 20に示す拡張されたマルチカルーセル属性 MCでは、複数 の配送経路を示すことができる forループ内にさらに forループを追加している。この rループは、 1つの配信経路においてアプリを分割して配信している 1つ以上のォブ ジェタトカノレーセノレを示す。ここで、 IP via DVB multiprotocol encapsulationはォブジ エタトカル一セルと同様に TS内で配送されるファイルシステムであり、 DVB-MHP規格 においてアプリを構成するファイルを配送するための手段として使用される。 <動作 >

次に、本実施形態のアプリ実行装置 10cの動作を説明する。図 22は、アプリ実行 装置 10cの処理手順を示すフローチャートである。まず、サービス受付部 101は、ュ 一ザによるリモコン操作や、アプリからの要求、または電源オン時の初期設定により指 定されたサービスに対応する数値を受け付け、受信部 102に通知する（S2201)。受 信部 102は、受け付けた数値に対応するサービスの搬送波にチューニングし、 TSを 受信する。そして、受信した TSをデジタルデータに復調する（S2202)。分離部 103 は、 TSに多重化されている PMT、 PATを取得し、 PMTに格納された PIDからビデオ .ォ 一ディォ、オブジェクトカルーセル、 AITを特定し、分離する（S2203)。デコード部 10 9は、ビデオ'オーディオデータをデコードし、出力部 110は、デコードされたデータを 出力する（S2204)。カルーセル記憶部 107及びカルーセル記憶部 1902は、選択さ れたサービスにお!/、て、起動対象となるアプリに係るオブジェクトカルーセルをキヤッ シュする。二つのオブジェクトカルーセルをそれぞれ異なるカルーセル記憶部にキヤ ッシュする（S2205)。アプリ管理部 104cは、キャッシュ保障属性抽出部 1101よりキ ャッシュ保障属性を、マルチカルーセル属性抽出部 1901よりマルチカルーセル属性 を受け取る。そして、キャッシュ保障属性情報が保障する必要がある旨を示す情報で ある力否かを判断する（S2206)。判断が肯定の場合は、アプリ管理部 104cは、ァプ リ実行制御処理 3を行う（S2207)。判断が否定の場合は、アプリ管理部 104cは、図 14に示したアプリ実行処理を行う（S2208)。つまり、キャッシュ完了監視部 1903及 びキャッシュ完了監視部 106からのキャッシュ完了通知を待たずにアプリ実行部 108 にアプリの起動指示を行う。

続いて図 23は、アプリ管理部 104cによるアプリ実行制御処理 3に関するフローチヤ ートを示す図である。アプリ管理部 104cは、 AITから抽出されるアプリに関する情報 である initial_class302に対応するクラスファイルのロードをアプリ実行部 108に指示 する（S2301)。カルーセル記憶部 107cまたはカルーセル記憶部 1902にロード対 象のファイルがある力否かが判断される（S2302)。ある場合は、アプリ実行部 108に i nitial_class302に対応するクラスファイルが読み出され、アプリ管理部 104cは、 Java( 登録商標） I/Oより successを受け取る（S2303)。ない場合は、アプリ管理部 104cは Java (登録商標） I/Oより falseを受け取る（S2304)。アプリ管理部 104cは、マルチ力 ルーセル属性で示されるカルーセルに他のファイルが存在するか否かを判断する（S 2305)。具体的には、 AIT力も抽出されるアプリに関する情報である base_directory3 01及び classpath_extension303に基づ!/、て判断する。存在する場合は、 base_directo ry301または classpath_extension303に示されるアプリを構成するファイルのロードを アプリ実行部 108に指示する（S2306)。ステップ S2302に移行する。存在しない場 合は、アプリ管理部 104cは、マルチカルーセル属性で示されるカルーセル内の全て のファイルについて successを受信した力否かを判断する（S2307)。判断結果が否 定の場合は、 falseになったクラスファイルのロードを再度指示する（S2308)。判断結 果が肯定の場合は、アプリ管理部 104cはアプリ実行部 108に実行開始指示を行う。 アプリ管理部 104によりアプリの実行開始を指示されたアプリ実行部 108は、ロードさ れたクラスファイルを解釈し、実行する（S2309)。

[0070] 図 24はファイルシステム FS1が 2つのオブジェクトカルーセルに分割して配信され る場合の具体例である。図 24に示すようにファイルシステム FS 1は、ファイルシステム FS2とファイルシステム FS3に分割されて送信される。ファイルシステム FS2とフアイ ルシステム FS 3はそれぞれカルーセル記憶部 107c、及びカルーセル記憶部 1902 に記憶される。ここで、起動対象のアプリがアプリ 1であり、かつ、キャッシュ保障属性 が保障する必要がある旨を示す属性であった場合は、アプリ制御部 105cは、キヤッ シュ完了監視部 106cとキャッシュ完了監視部 1903の双方のキャッシュ完了通知を 待ってから、アプリ実行部 108にアプリの起動指示を行う。したがって、アプリ実行装 置 10cはファイル F2のキャッシュの完了を待つことはない。よって、カルーセル記憶 部 107cとカルーセル記憶部 1902は、ファイルのキャッシュ処理を行うことなくフアイ ルの読み込み要求に応答可能となるため、受信部 102からデータを受け取れない状 態に陥ったとしてもファイルの読み込みを保障することが可能である。さらにキヤッシ ュするファイルを限定することにより、アプリの起動を早めることができる。

[0071] 一方、起動対象のアプリがアプリ 1であり、かつ、キャッシュ保障属性が保障する必 要がある旨を示す属性でない場合は、アプリ管理部 104cはキャッシュ完了監視部 1 06c及びキャッシュ完了監視部 1903からのキャッシュ完了通知を待たずに、アプリ実 行部 108にアプリの起動指示を行う。そのため、カルーセル記憶部 107c及びカルー セル記憶部 1902は、アプリ実行部 108からのファイルの読み込み要求に対してでき るだけレスポンスよく応答し、ファイルの読み込み要求がない空き時間を利用してキヤ ッシュが完了していないファイルのキャッシュを行うという処理となる。したがって、マ ルチカルーセル属性に示されるカルーセル内の全てのファイルのキャッシュ完了を 待つ場合よりアプリの起動が早い。

[0072] 以上のように本実施の形態によれば、アプリの構成ファイルとその他のファイルとを 異なるカルーセルに分割して配送することが可能であるために、アプリの実行に必要 なファイルのみをキャッシュした後に、アプリを起動することが可能となり、より早くアブ リを起動することができる。

なお、本実施形態では、アプリ実行装置 10cは、カルーセル記憶部、キャッシュ完 了監視部を二組備えるとした力 三組以上備えるとしても良い。

<補足 >

以上、本発明に係るアプリ実行装置について、実施の形態に基づいて説明したが 、本発明は上記の実施の形態に限られないことは勿論である。

[0073] 上記実施の形態では、デジタル放送システムはアプリ実行装置及び放送装置がそ れぞれ一つずつで構成されるとしたが、それぞれが複数であっても良!、。

上記実施の形態では、アプリ実行装置はアプリを構成する全てのファイルをキヤッ シュした後に実行開始指示を行ったが、アプリを構成するファイルのうち、アプリの終 了処理にお!、て、 suspend処理を実行するために必要なファイルがキャッシュされれ ば、実行開始指示を行うとしても良い。この場合には、例えば図 9の S905において、 サスペンド処理を実行するために必要なファイルが他に存在するカゝ否かを判断する。 そして、 S907において、アプリを構成するファイルのうち、サスペンド処理を実行する ために必要な全てのファイルにつ 、て successを受信したか否かを判断する。これら の判断は、 AITに基づいて行われる。

[0074] 上記実施の形態では、各属性を AIT内に定義される既存の descriptorに追加する 例としている力 新たな descriptorを AIT内に追加しても良いし、 AIT以外のテーブル を用いる構成としてもよい。 上記実施の形態では、オブジェクトカルーセルでファイルを送信するとした力 ォブ ジェタトカノレーセノレの代わりに IP via DVB multiprotocol encapsulation,データカノレー セル、あるいは TCP/IPによる配信方法を用いる構成としても良いし、 DVD、 BDなどの 記録媒体に記録されたファイルを用いる構成としてもよい。例えば、 BDでは HD映像 を再生するので、 HD映像のシームレス再生を優先すると、キャッシュミスが発生する。 また、 BDがアプリ実行装置力も取り出された場合に、キャッシュミスが発生する。その ような場合であっても、上記処理により適切に終了処理を行うことができる。

[0075] 上記の実施形態では、アプリ実行装置を用いたが、本発明は上記フローチャートで 示したステップを含む方法、及び上記フローチャートで示したステップをコンピュータ に実行させるプログラムコードを含むプログラムであっても良い。

上記の実施形態では、キャッシュ完了監視部がアプリを構成する全てのファイルに っ 、てロードできた力否かを判断したが、同様の処理を実現するためのキャッシュ制 御用の API (Application Program Interface)を追加しても良い。その場合には、アプリ 管理部が実行制御するのではなぐアプリの mainルーチンが実行制御するとしても良 い。図 25に mainルーチンが実行制御を行う場合のフローチャートを示す。まず、ァプ リ管理部は、 mainルーチンのロードを指示する（S2501)。ファイルがキャッシュ済み か否かが判断され（S2502)、キャッシュ済みならロードされる。アプリの mainルーチ ンがロードできたら、アプリ管理部は mainルーチンを起動するようにアプリ実行部に指 示する（S2503)。 mainルーチンは APIを通じてアプリを構成する全てのクラスがロー ドされたか否かをチェックする（S2504)。全てのファイルがキャッシュされるまで、実 行を待機する（S2505)。全てのファイルがキャッシュされれば、 mainルーチンの実行 を継続し、さらに、アプリ全体を実行する（S2506)。そして、アプリを構成するフアイ ルをキャッシュアウトしないように APIを通じてカルーセル記憶部に指示する（S2507)

産業上の利用可能性

[0076] 本発明を構成するアプリケーションプログラム実行装置は、製造産業において経営 的に、また継続的及び反復的に製造し、販売することができる。特に、地上波、衛星 、またはケーブルデジタル放送用の STBやデジタル放送受信機能内蔵テレビ等とし て有用である。

Claims

請求の範囲

[1] 選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリ ケーシヨンプログラム実行装置であって、

キャッシュ手段と、

ユーザ力 サービスの選択を受け付ける受付手段と、

放送装置力 送信されるオブジェクトカルーセルから、ユーザが選択したサービス に係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段 に書き込む受信手段と、

前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するフ アイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして!/、る か否かを判断する判断手段と、

前記ファイルをキャッシュして 、ると判断すれば、前記キャッシュ手段にキャッシュさ れたアプリケーションプログラムを実行させる実行制御手段と、

を含むアプリケーションプログラム実行装置。

[2] 前記実行制御手段は、アプリケーションプログラムの実行時にぉ 、て、ファイル読み 込みが失敗しないことを保障する必要がある力否かを示すキャッシュ保障属性情報 を取得する取得手段を含み、

前記実行制御手段は、前記取得手段により取得されたキャッシュ保障属性情報が 保障する必要がある旨を示す場合に限り実行制御する、請求項 1記載のアプリケー シヨンプログラム実行装置。

[3] 前記実行制御手段は、複数のアプリケーションプログラムが存在する場合に、どのァ プリケーシヨンプログラムにリソースを優先的に配分するかを示すプライオリティ属性 情報を取得する取得手段を含み、

前記実行制御手段は、前記取得手段により取得されたプライオリティ属性情報が既 定の閾値以上の場合に限り実行制御する、請求項 1記載のアプリケーションプロダラ ム実行装置。

[4] 前記実行制御手段は、アプリケーションプログラムが前記サービスでのみ実行可能 か否かを示すサービスバウンド属性情報を取得する取得手段を含み、 前記実行制御手段は、前記取得手段により取得されたサービスバウンド属性情報 が前記サービスでのみ実行可能である旨を示す情報である場合に限り実行制御する

、請求項 1記載のアプリケーションプログラム実行装置。

[5] 前記判断手段による判断は、アプリケーションプログラムを構成する全ファイルに関 する情報に基づ 、て行われる、請求項 1記載のアプリケーションプログラム実行装置

[6] 前記実行制御手段は、前記情報にお!、て、前記アプリケーションプログラムを構成す るファイルを含んでいるディレクトリである力否かを示すディレクトリ属性を抽出する抽 出手段を含み、

前記サービスに係るアプリケーションプログラムを構成するファイルのうち、サスペン ド処理を実行するために必要なファイルとは、前記抽出手段により抽出されたディレ クトリ属性力 当該アプリケーションプログラムのファイルを含んで 、る旨を示すディレ クトリ内のファイルである

請求項 5記載のアプリケーションプログラム実行装置。

[7] 選択したサービス内でのみ実行可能なアプリケーションプログラムを実行する処理を コンピュータに行わせるコンピュータ読み取り可能なプログラムであって、

ユーザ力 サービスの選択を受け付ける受付コードと、

放送装置力 送信されるオブジェクトカルーセルから、ユーザが選択したサービス に係るアプリケーションプログラムを構成するファイルを受信し、前記コンピュータに 書き込む受信コードと、

前記コンピュータが前記サービスに係るアプリケーションプログラムを構成するファ ィルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして!/、るか 否かを判断する判断コードと、

前記ファイルをキャッシュして 、ると判断すれば、前記コンピュータにキャッシュされ たアプリケーションプログラムを実行させる実行制御コードと、

を含む手順をコンピュータに行わせるコンピュータ読み取り可能なプログラム。

[8] 選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリ ケーシヨンプログラム実行方法であって、 ユーザからのサービスの選択の受け付けと、

放送装置力 送信されるオブジェクトカルーセルから、ユーザが選択したサービス に係るアプリケーションプログラムを構成するファイルの受信と、

受信したファイルのコンピュータのキャッシュメモリへの書き込みと、

前記キャッシュメモリが前記サービスに係るアプリケーションプログラムを構成するフ アイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして!/、る か否かの判断と、

前記ファイルをキャッシュしているという判断の場合、前記キャッシュメモリにキヤッシ ュされたアプリケーションプログラムの実行制御と、

を含むアプリケーションプログラム実行方法。

[9] 選択したサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリ ケーシヨンプログラム実行装置であって、

キャッシュ手段と、

ユーザ力 サービスの選択を受け付ける受付手段と、

放送装置力 送信されるオブジェクトカルーセルから、ユーザが選択したサービス に係るアプリケーションプログラムを構成するファイルを受信し、前記キャッシュ手段 に書き込む受信手段と、

前記キャッシュ手段が前記サービスに係るアプリケーションプログラムを構成するフ アイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして!/、る か否かをチェックするインターフェイス手段とを含み、

前記アプリケーションプログラムは、メインルーチンが起動されると前記インターフエ イス手段を通じて、前記キャッシュ手段がアプリケーションプログラムを構成するフアイ ルのうち、サスペンド処理を実行するために必要なファイルをキャッシュして 、るか否 かをチェックし、キャッシュされていなければキャッシュされるまで実行を待機し、キヤ ッシュされると実行を継続する

アプリケーションプログラム実行装置。

[10] 所定のサービス内でのみ実行可能なアプリケーションプログラムを実行するアプリケ ーシヨンプログラム実行装置であって、 キャッシュ手段と、

前記所定のサービスに係るアプリケーションプログラムを構成するファイルを記録媒 体から読み出し、前記キャッシュ手段に書き込む書き込み手段と、

前記キャッシュ手段が前記所定のサービスに係るアプリケーションプログラムを構成 するファイルのうち、サスペンド処理を実行するために必要なファイルをキャッシュし ているか否かを判断する判断手段と、

前記ファイルをキャッシュして 、ると判断すれば、前記キャッシュ手段にキャッシュさ れたアプリケーションプログラムを実行させる実行制御手段と、

を含むアプリケーションプログラム実行装置。