(57)【特許請求の範囲】
【請求項１】
放送信号を受信する放送受信部と、
前記放送信号からアプリケーション情報テーブルを取得するアプリケーション情報テーブル取得部と、
取得した前記アプリケーション情報テーブルにおいて指定されるアプリケーションに関するリソースデータを取得し、蓄積するファイル蓄積部と、
前記アプリケーション情報テーブルから、初期提示に必須のリソースデータであるか否かを示す情報を取得するとともに、初期提示に必須のリソースデータの蓄積が完了したときに初期提示リソース蓄積完了を検知するファイル蓄積検知部と、
前記ファイル蓄積検知部によって検知された初期提示リソース蓄積完了を通知する蓄積状態通知部と、
前記蓄積状態通知部からの前記初期提示リソース蓄積完了の通知を受けると、前記アプリケーション情報テーブルで指定されたアプリケーションによる提示を開始するよう制御する蓄積待受部と、
前記蓄積待受部からの提示開始の制御にしたがって前記アプリケーションを実行するアプリケーション実行部と、
を具備し、
前記蓄積待受部は、前記リソースデータを待受けるためのリスナーを登録し、
前記蓄積状態通知部は、登録された前記リスナーを介して、前記初期提示リソース蓄積完了を通知するものであり、
前記蓄積待受部が、ディレクトリをリソースとして指定して前記リスナーを登録した場合、且つそのディレクトリが前記初期提示に必須のリソースデータであるか否かを示す情報に含まれていない場合、前記蓄積状態通知部は、前記初期提示に必須のリソースデータであるか否かを示す情報に基づき当該ディレクトリ内のファイルのうち初期提示に必要なファイルがすべて蓄積完了した時点で、当該ディレクトリの初期提示リソース蓄積完了を通知蓄積待受部に通知し、
前記蓄積待受部が、リソースを指定せずに前記リスナーを登録した場合、前記蓄積状態通知部は、現在起動しようとしているアプリケーションに関する前記アプリケーション情報テーブル内の前記初期提示に必須のリソースデータであるか否かを示す情報に基づいて、初期提示に必須であると定義されているすべてのディレクトリ内のすべてのファイルが蓄積完了した場合、あるいは、初期提示に必須であると定義されているすべてのファイルが蓄積完了した場合に、初期提示リソース蓄積完了を前記蓄積待受部に通知する、
ことを特徴とする受信機。
【請求項２】
前記ファイル蓄積検知部は、前記アプリケーション情報テーブルの記述子領域に含まれるアプリケーションイニシャルディレクトリ記述子から初期提示に必須のリソースデータであるか否かを示す情報をディレクトリ単位で取得し、または前記アプリケーション情報テーブルの記述子領域に含まれるアプリケーションイニシャルリソース記述子から初期提示に必須のリソースデータであるか否かを示す情報をリソースデータ単位で取得する、
ことを特徴とする請求項１に記載の受信機。
【請求項３】
放送信号受信手段が受信した放送信号からアプリケーション情報テーブルを取得するアプリケーション情報テーブル取得手段、
取得した前記アプリケーション情報テーブルにおいて指定されるアプリケーションに関するリソースデータを取得し、蓄積するファイル蓄積手段、
前記アプリケーション情報テーブルから、初期提示に必須のリソースデータであるか否かを示す情報をリソースデータごとに取得するとともに、初期提示に必須のリソースデータの蓄積が完了したときに初期提示リソース蓄積完了を検知するファイル蓄積検知手段、
前記ファイル蓄積検知手段によって検知された初期提示リソース蓄積完了を通知する蓄積状態通知手段、
前記蓄積状態通知手段からの前記初期提示リソース蓄積完了の通知を受けると、前記アプリケーション情報テーブルで指定されたアプリケーションによる提示を開始するよう制御する蓄積待受手段、
前記蓄積待受手段からの提示開始の制御にしたがって前記アプリケーションを実行するアプリケーション実行手段、
としてコンピューターを機能させるためのプログラムであって、
前記蓄積待受手段は、前記リソースデータを待受けるためのリスナーを登録し、
前記蓄積状態通知手段は、登録された前記リスナーを介して、前記初期提示リソース蓄積完了を通知するものであり、
前記蓄積待受手段が、ディレクトリをリソースとして指定して前記リスナーを登録した場合、且つそのディレクトリが前記初期提示に必須のリソースデータであるか否かを示す情報に含まれていない場合、前記蓄積状態通知手段は、前記初期提示に必須のリソースデータであるか否かを示す情報に基づき当該ディレクトリ内のファイルのうち初期提示に必要なファイルがすべて蓄積完了した時点で、当該ディレクトリの初期提示リソース蓄積完了を通知蓄積待受手段に通知し、
前記蓄積待受手段が、リソースを指定せずに前記リスナーを登録した場合、前記蓄積状態通知手段は、現在起動しようとしているアプリケーションに関する前記アプリケーション情報テーブル内の前記初期提示に必須のリソースデータであるか否かを示す情報に基づいて、初期提示に必須であると定義されているすべてのディレクトリ内のすべてのファイルが蓄積完了した場合、あるいは、初期提示に必須であると定義されているすべてのファイルが蓄積完了した場合に、初期提示リソース蓄積完了を前記蓄積待受手段に通知する、
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信機およびプログラムに関する。特に、放送信号を受信するための受信機およびプログラムに関する。
【背景技術】
【０００２】
近年、テレビ放送を受信する受信機側で、アプリケーションを実行させるための技術が研究、開発されている。既存の技術では、ＡＩＴ（Application Information Table，アプリケーション情報テーブル）を放送局側から送信する放送信号内に含めて、受信機側で放送信号からそのＡＩＴを取得し、受信したＡＩＴ内の記述に従ってアプリケーションの実行を制御する。具体的には、例えば、受信機は、ＡＩＴ内のアプリケーション情報記述子ループにおいてアプリケーションごとに必ず１つ含まれているＭＨ−簡易アプリケーションロケーション記述子により、アプリケーションの起動を制御している。
【０００３】
非特許文献１の「１０．１６  アプリケーション情報符号化方式」（ｐ．５４−７３）および非特許文献２の「１０．３．２  アプリケーション伝送方式に用いるテーブル」には、ＡＩＴ（アプリケーション情報テーブル）の構成、およびＡＩＴ内の各記述子について記載されている。
また、非特許文献１には、データ放送のコンテンツを構成するファイルやアプリケーションの実行において参照されるファイルなどのデータを、放送を介して伝送可能なデータカルーセル伝送方式について記載されている。
非特許文献２には、伝送されるデータ（アイテム）を含むアセットのリストやアセットのネットワーク上の配置などパッケージを構成する情報を与えるＭＭＴ（MPEG Media Transport）パッケージテーブル（ＭＰテーブル）の構成、およびＭＰテーブル内の各記述子について記載されている。また、非特許文献２には、アプリケーションを構成するファイルシステムのディレクトリ構造を提供するデータディレクトリ管理テーブルの構成、およびデータディレクトリ管理テーブル内の各記述子について記載されている。また、非特許文献２には、アセット内のＭＰＵ（Media Processing Unit）の構成とＭＰＵごとのバージョン情報を提供するデータアセット管理テーブルの構成、およびデータアセット管理テーブル内の各記述子について記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「デジタル放送におけるデータ放送符号化方式と伝送方式  標準規格  DATA CODING AND TRANSMISSION SPECIFICATION FOR DIGITAL BROADCASTING  ARIB STANDARD  ARIB STD-B24  5.9版」，平成２６年（２０１４年）３月１８日，社団法人電波産業会
【非特許文献２】「デジタル放送におけるＭＭＴによるメディアトランスポート方式  標準規格  MMT-BASED MEDIA TRANSPORT SCHEME IN DIGITAL BROADCASTING SYSTEMS  ARIB STANDARD  ARIB STD-B60  1.0版」，平成２６年（２０１４年）７月３１日，社団法人電波産業会
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載された技術では、ＡＩＴ内において、エントリーポイントとなるファイルの指定を行うことができる。また、非特許文献２に記載された技術では受信機が受信するデータディレクトリ管理テーブルを参照することにより、アプリケーションに含まれる、その時点でのすべてのファイルの集合を知ることはできる。しかしながら、受信機側では、エントリーポイントを指定されただけでは、どのタイミングで画面に初期表示を行うことができるかを素早く知ることができないという問題がある。例えば、受信機は、上記のエントリーポイントとして示されるファイルや、そのエントリーポイントから関連付けられるファイルのロケーションを知り、実際に放送または通信によりそれらのファイルを獲得する。しかし、それらのファイルのうち、どのファイルを蓄積し終えれば画面への初期表示を開始することができるかを、受信機は即座に知ることができない。
【０００６】
実際には、アプリケーションは例えばＨＴＭＬ５で記述され、受信機はいわゆるブラウザ機能でそのＨＴＭＬ５で書かれたファイルを実行することが多い。したがって、ＨＴＭＬ５で書かれたデータをパース（parsing）すれば、データディレクトリ管理テーブルに記載されているファイルのうち、どのファイルが初期表示のために必要かを解析することはできる。しかし、そのようなパース処理自体に時間がかかるため、やはり、受信機は、画面への表示を開始するために必要な初期ファイルの集合を特定するのには時間がかかる。
【０００７】
本発明は、上記のような課題認識に基づいて行なわれたものであり、アプリケーションのソースファイルについてのパース等の処理をすることなく、初期ファイルを特定し、可能な限り早いタイミングでアプリケーションの画面の表示を開始することのできる受信機、およびそのプログラムを提供しようとするものである。
【課題を解決するための手段】
【０００８】
［１］上記の課題を解決するため、本発明の一態様による受信機は、放送信号を受信する放送受信部と、前記放送信号からアプリケーション情報テーブルを取得するアプリケーション情報テーブル取得部と、取得した前記アプリケーション情報テーブルにおいて指定されるアプリケーションに関するリソースデータを取得し、蓄積するファイル蓄積部と、前記アプリケーション情報テーブルから、初期提示に必須のリソースデータであるか否かを示す情報を取得するとともに、初期提示に必須のリソースデータの蓄積が完了したときに初期提示リソース蓄積完了を検知するファイル蓄積検知部と、ファイル蓄積検知部によって検知された初期提示リソース蓄積完了を通知する蓄積状態通知部と、前記蓄積状態通知部からの前記初期提示リソース蓄積完了の通知を受けると、前記アプリケーション情報テーブルで指定されたアプリケーションによる提示を開始するよう制御する蓄積待受部と、前記蓄積待受部からの提示開始の制御にしたがって前記アプリケーションを実行するアプリケーション実行部と、を具備することを特徴とする。
この構成により、ファイル蓄積検知部は、アプリケーション情報テーブルから初期提示に必須のリソースデータであるか否かを示す情報を取得する。また、ファイル蓄積検知部は、その初期提示に必須のリソースデータであるか否かを示す情報に基づいて、初期提示に必須のリソースの蓄積を完了したか否かを検知する。そして、蓄積状態通知部は、初期提示に必須のリソースの蓄積を完了した旨を蓄積待受部に通知する。蓄積待受部はその旨の通知を受けるとアプリケーションによる提示を開始する。したがって、受信機は、初期提示に必須のリソースであるか否かを判別するためにリソースデータそのものを解析する必要がない。
【０００９】
［２］また、本発明の一態様は、上記の受信機において、前記ファイル蓄積検知部は、前記アプリケーション情報テーブルの記述子領域に含まれるアプリケーションイニシャルディレクトリ記述子から初期提示に必須のリソースデータであるか否かを示す情報をディレクトリ単位で取得し、または前記アプリケーション情報テーブルの記述子領域に含まれるアプリケーションイニシャルリソース記述子から初期提示に必須のリソースデータであるか否かを示す情報をリソースデータ単位で取得する、ことを特徴とする
【００１０】
［３］また、本発明の一態様は、上記の受信機において、前記蓄積待受部は、前記リソースデータを待受けるためのリスナーを登録し、前記蓄積状態通知部は、登録された前記リスナーを介して、前記初期提示リソース蓄積完了を通知する、ことを特徴とする。
【００１１】
［４］また、本発明の一態様は、放送信号受信手段が受信した放送信号からアプリケーション情報テーブルを取得するアプリケーション情報テーブル取得手段、取得した前記アプリケーション情報テーブルにおいて指定されるアプリケーションに関するリソースデータを取得し、蓄積するファイル蓄積手段、前記アプリケーション情報テーブルから、初期提示に必須のリソースデータであるか否かを示す情報をリソースデータごとに取得するとともに、初期提示に必須のリソースデータの蓄積が完了したときに初期提示リソース蓄積完了を検知するファイル蓄積検知手段、前記ファイル蓄積検知手段によって検知された初期提示リソース蓄積完了を通知する蓄積状態通知手段、前記蓄積状態通知手段からの前記初期提示リソース蓄積完了の通知を受けると、前記アプリケーション情報テーブルで指定されたアプリケーションによる提示を開始するよう制御する蓄積待受手段、前記蓄積待受手段からの提示開始の制御にしたがって前記アプリケーションを実行するアプリケーション実行手段、としてコンピューターを機能させるためのプログラムである。
【発明の効果】
【００１２】
本発明によれば、受信機は、アプリケーションのソースコードを解析することなく、初期提示に必須のリソースを把握することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態による受信機の概略機能構成を示すブロック図である。
【図２】同実施形態による受信機を含むテレビシステム全体の概略構成を示す構成図である。
【図３】同実施形態で用いるアプリケーション情報テーブルのデータ構造を示す概略図である。
【図４】上記のアプリケーション情報テーブルの記述子領域に配置される、アプリケーションイニシャルディレクトリ記述子のデータ構造を示す概略図である。
【図５】上記のアプリケーション情報テーブルの記述子領域に配置される、アプリケーションイニシャルリソース記述子のデータ構造を示す概略図である。
【図６】同実施形態による受信機が受信するＩＰデータフローの構成を示す概略構成図である。
【図７】同実施形態による受信機が用いるイベントリスナーのインターフェースおよび、関連する定義等を示す概略図である。
【図８】同実施形態による受信機が用いる関数addDataResourceEventListenerの仕様を示す概略図である。
【図９】同実施形態による受信機が用いる関数removeDataResourceEventListenerの仕様を示す概略図である。
【図１０】同実施形態による受信機が用いるデータ型MMTDataResourceEventTypeの仕様を示す概略図である。
【図１１】同実施形態による受信機が用いる関数DataResourceEventListenerの仕様を示す概略図である。
【図１２】同実施形態による受信機によるリソース（ファイルまたはディレクトリ）の監視開始から監視終了までの受信機１における処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下では、図面を参照しながら、本発明の実施形態について説明する。
［第１の実施形態］
図１は、本実施形態による受信機の概略機能構成を示すブロック図である。同図に示す受信機１は、テレビの放送信号を受信して、映像および音声からなるテレビ放送のコンテンツを視聴者に提示する機能を備えるとともに、アプリケーション（以下、「アプリ」と呼ぶ場合がある）を実行する環境を備えるものである。同図に示すように、受信機１は、放送受信部１１と、放送信号解析部１２と、ＡＩＴ取得部１３（アプリケーション情報テーブル取得部）と、通信送受信部１４と、アプリ実行制御部１５と、アプリ実行部１７（アプリケーション実行部）と、ファイルシステム２１（ファイル蓄積部）と、ファイル蓄積検知部２２と、蓄積状態通知部２３と、蓄積待受部２４と、を含んで構成される。
【００１５】
放送受信部１１は、放送信号を受信する。放送信号は、電波として空中を伝搬したり、ケーブルテレビ用のケーブルを媒介して伝搬したりするものである。放送受信部１１が受信する放送信号には、映像の信号や、音声の信号や、データ放送の信号や、制御情報の信号などが含まれている。そして、制御情報の一部として、ＡＩＴ（アプリケーション情報テーブル、Application Information Table）、データディレクトリ管理テーブル、データアセット管理テーブル、ＭＰテーブルなどが含まれている。
【００１６】
放送信号解析部１２は、放送受信部１１によって受信された放送信号を解析し、映像や音声や制御情報などといったそれぞれ必要なデータを、抽出し、ファアイルとしてファイルシステム２１に書き込むものである。一例として、放送信号は、ＩＰデータフローを含む形で伝送される。このＩＰデータフローの内部の構成例については、後で別の図面を参照しながら説明する。
放送信号解析部１２は、ＩＰデータフローから抽出したデータのうちＡＩＴをＡＩＴ取得部１３に渡す。また、放送信号解析部１２は、データアセットを抽出し、データアセットからアイテムを抽出する。アイテムは、アプリの実行に必要なリソースを含む。リソースのうちの一部は、当該アプリのエントリーポイントとなるエントリーポイントリソースである。また、リソースのうちの一部は、当該アプリに関して初期提示に必須のリソースである。
【００１７】
ＡＩＴ取得部１３は、放送信号解析部１２によって解析された放送信号の中から得られるＡＩＴを取得する。また、ＡＩＴ取得部１３は、取得したＡＩＴの中から、必要に応じて各種の情報を抽出する。ＡＩＴ取得部１３が抽出する情報には、各種の記述子が含まれる。また、ＡＩＴ取得部１３が抽出する記述子の中には、アプリケーションイニシャルディレクトリ記述子やアプリケーションイニシャルリソース記述子のいずれか一方、または両方が含まれる。アプリケーションイニシャルディレクトリ記述子やアプリケーションイニシャルリソース記述子は、「アプリケーション初期提示記述子」と総称されることもある。また、ＡＩＴ取得部１３は、ＡＩＴ内の情報に基づいて、アプリの実行に必要なリソースを取得するよう、放送信号解析部１２や通信送受信部１４に指示する。ＡＩＴ内部の構成については、別の図面を参照しながら後で詳しく説明する。
【００１８】
通信送受信部１４は、通信ネットワークを介して、外部の機器との間でデータの通信を行うものである。通信送受信部１４は、例えば、ＩＰ（インターネットプロトコル）を用いて、外部の機器との間のデータ交換を行う。アプリのリソースデータが外部のサーバー装置等から通信にて配信される場合、通信送受信部１４は、通信で受信したアプリのリソースデータを、ファイルとしてファイルシステム２１に書き込む。
【００１９】
アプリ実行制御部１５は、ＡＩＴ取得部１３が取得したＡＩＴにしたがって、アプリ実行部１７におけるアプリの実行を制御する。アプリ実行制御部１５による制御の一例は、例えば、アプリのライフサイクル管理である。つまり、アプリ実行制御部１５は、アプリを起動したり、スリープさせたり、終了させたりといった制御を行う。また、アプリ実行制御部１５は、アプリが特定のサービスに束縛されている（service-bound）か否かに応じた実行制御などをも行う。
【００２０】
アプリ実行部１７は、ＡＩＴ内に記載されている制御情報にしたがって受信機１が取得したアプリを実行させる機能を有する実行環境である。アプリ実行部１７は、例えば、ＨＴＭＬ５で記述されたハイパーテキストを提示したり、ＨＴＭＬデータ内に埋め込まれているプログラムコード（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）で書かれたコード）を実行したりすることができる。アプリ実行部１７は、例えばいわゆるウェブブラウザの技術を用いて実現される。
なお、アプリ実行部１７は、蓄積待受部２４からの提示開始の制御にしたがってアプリを実行する。後述する構成および手順により、初期提示に必須のリソースがファイルシステム２１に蓄積できた段階でアプリ実行部１７が初期提示を開始することができる。ここで、提示とは、画像や映像を画面に表示したり、音声をスピーカー等から出力したりすることである。そして、初期提示とは、アプリを実行する際の初期の必要最低限の提示である。もしそのアプリを実行（提示）するためのすべてのリソース（ファイル）がそろっていなくても、それらの一部のみがそろっていれば初期提示が可能な場合はある。本実施形態では、後述するように、初期提示に必要なリソースであるか否かを、ＡＩＴの中の情報から読み取れるようにする。
【００２１】
ファイルシステム２１は、ＡＩＴ取得部１３が取得したＡＩＴにおいて指定されるアプリケーションに関するリソースデータを取得し、蓄積する。ファイルシステム２１は、ファイルを記憶する機能そのものと、ツリー構造を有するディレクトリでファイルを管理する機能とを兼ね備える。ファイルシステム２１は、受信機１内の他の機能（例えばコンピューター上で稼働するプログラムとして実現）に対して提供するインターフェースにより、ファイルの生成、ファイルの書き込み（蓄積）、ファイルの読み出しなどといったサービスを提供する。
【００２２】
ファイル蓄積検知部２２は、ＡＩＴから、初期提示に必須のリソースデータであるか否かを示す情報を取得するとともに、初期提示に必須のリソースデータの蓄積が完了したときに初期提示リソース蓄積完了を検知する。
具体的には、ファイル蓄積検知部２２は、ＡＩＴの記述子領域に含まれるアプリケーションイニシャルディレクトリ記述子から初期提示に必須のリソースデータであるか否かを示す情報をディレクトリ単位で取得する。あるいは、ファイル蓄積検知部２２は、ＡＩＴの記述子領域に含まれるアプリケーションイニシャルリソース記述子から初期提示に必須のリソースデータであるか否かを示す情報をリソースデータ単位で取得する。
【００２３】
蓄積状態通知部２３は、ファイル蓄積検知部２２によって検知された初期提示リソース蓄積完了を、蓄積待受部２４に通知する。
具体的には、蓄積状態通知部２３は、蓄積待受部２４によって登録されたリスナーを介して、初期リソース蓄積完了を蓄積待受部２４に通知する。なお、イベントを待受けるためのリスナー機能については後述する。
【００２４】
蓄積待受部２４は、蓄積状態通知部２３からの初期提示リソース蓄積完了の通知を受けると、ＡＩＴで指定されたアプリケーションによる提示を開始するよう制御する。
具体的には、蓄積待受部２４は、リソースデータを待受けるためのリスナーを登録し、そのリスナーを介して、蓄積状態通知部２３からの初期提示リソース蓄積完了の通知を受ける。
【００２５】
上記のような構成を有する受信機１の動作の概略は、次の通りである。即ち、受信機１において、まず、放送受信部１１が放送信号を受信する。そして、放送信号解析部１２がその放送信号を解析し、ＡＩＴ取得部１３が放送信号から抽出されるＡＩＴを取得する。ＡＩＴ内には、アプリケーションごとに、アプリケーションのエントリーポイント（ロケーション）の情報や、アプリケーションの実行に必要なリソースの情報が含まれている。また、ＡＩＴ内の定義により、アプリケーションが特定の放送サービス（チャンネル等）に関連付けられたものであるか、サービスから独立のものであるかが区別される。また、ＡＩＴ内のライフサイクル制御コードに基づき、受信機１は、アプリケーションの起動や終了との制御を行う。また、ＡＩＴ内の記述にしたがって、受信機１は、アプリケーションの実行に必要なリソースを取得する。そのリソースは、放送信号から抽出される場合と、外部のサーバー装置等から通信（例えば、インターネット経由の通信）によって取得される場合とがある。それらのリソースを取得するにあたり、ＡＩＴ内の記述子の情報を、ファイル蓄積検知部２２は予め読み取っておく。これにより、ディレクトリ単位で、あるいはリソースデータ（ファイル）単位で、リソースが初期提示に必須のものであるか否かが把握される。また、アプリ実行制御部１５の制御によってアプリが起動されるとき、蓄積待受部２４は、イベントの待受けのためのリスナーを登録する。このリスナーは、ファイル蓄積検知部２２によって検知された状態（蓄積が完了したか否かを示す状態）を蓄積待受部２４に通知するために用いられる。
アプリがＪａｖａＳｃｒｉｐｔ（登録商標）を利用する場合、蓄積待受部２４は、そのように受けた通知に基づきアプリの実行を開始するか否かを制御する。つまり、初期提示に必要なリソースがすべてファイルシステム２１に蓄積完了した状態において、蓄積待受部２４は、そのアプリによる初期提示の開始を許可する。
アプリがＪａｖａＳｃｒｉｐｔ（登録商標）を利用せず、ＨＴＭＬ５のみで記述されている場合には、アプリ実行制御部１５が初期提示に必要なリソースを知り、ファイル蓄積検知部２２にそれらのファイルが何であるかを伝える。ファイルシステム２１にそれらのファイルのすべてが蓄積されると、ファイル蓄積検知部２２は、蓄積状態通知部２３から蓄積待受部２４への通知手段を経由して、アプリ実行制御部１５に蓄積完了を通知し、アプリ実行制御部１５はアプリ実行部１７に提示が可能であることを通知する。そして、アプリ実行部１７はファイルシステム２１からリソースを読出し、提示を行う。
これにより、初期提示に必要なリソースが必ずそろってから、初期提示を開始することができるようになる。また、アプリ実行部１７は、初期提示のために必須のリソースを区別するために、アプリのソース（例えばＨＴＭＬ５で記述されたコード）をパースして解析する必要がない。
【００２６】
図２は、前述の受信機１を含むテレビシステムの概略構成を示す構成図である。図示するように、テレビシステム１００は、送信装置３と、サーバー装置５と、受信機１とを含んで構成される。
【００２７】
送信装置３は、放送信号を送信する。送信装置３が送信する放送信号には、映像のデータや、音声のデータや、データ放送等のデータや、制御情報のデータなどが含まれる。そして、送信装置３が送信する信号の中の制御情報のデータの一部として、前述のＡＩＴが含まれる。送信装置３が送信した放送信号は、無線（地上波や衛星放送波）または有線（テレビ放送用ケーブル）によって伝送される。
【００２８】
サーバー装置５は、受信機１からの要求に応じて、アプリケーションプログラムのコード等のデータを提供する。サーバー装置５は、通信ネットワーク（例えば、インターネット）を介して受信機１に接続されており、受信機１からのデータを受信したり、受信機１に対してデータを送信したりすることができる。サーバー装置５は、例えば、コンピューターを用いて実現される。
【００２９】
受信機１は、送信装置３からの放送信号を受信するとともに、サーバー装置５との間の通信を行う。受信機１は、送信装置３からの放送信号の中に含まれるＡＩＴに従って、送信装置３またはサーバー装置５からアプリケーションプログラムを受信する。受信機１は、受信したＡＩＴ内のアプリケーション制御コードに従って、アプリケーションの実行を制御する。つまり、受信機１は、受信したＡＩＴ内のアプリケーション制御コードに従って、アプリケーションを起動可能な状態にしたり、起動したり、終了させたりといった制御を行う。
【００３０】
次に、本実施形態で使用するＡＩＴの構成について、説明する。
図３は、ＡＩＴのデータ構造を示す概略図である。同図では、データ構造と、そのデータ構造に含まれる各データ項目のビット数およびデータ表記を示している。同図では、データ構造は、ブロック構造を有する形式言語で表現されている。なお、データ表記における「ｕｉｍｓｂｆ」は、「unsigned integer, most significant bit first」、すなわち、符号なし整数であって最上位ビットが先頭であることを表す。また「ｂｓｌｂｆ」は、「bit string, left bit first」、すなわち、ビット列であって左ビットが先頭であることを表す。また「ｒｐｃｈｏｆ」は、「remainder polynomial coefficients, highest order first」、すなわち、多項式係数の剰余であって最上位階数が先頭であることを表す。
【００３１】
図示する通り、ＡＩＴは、内部に、第１記述子領域および第２記述子領域を含んでいる。第１記述子領域においては、「ｆｏｒ」節が表している通り、Ｎ個（ｉ＝０，１，・・・，Ｎ−１）の記述子「ｄｅｓｃｒｉｐｔｏｒ（）」が繰り返される。また、第２記述子領域においては、「ｆｏｒ」節が表している通り、Ｍ個（ｊ＝０，１，・・・，Ｍ−１）の記述子「ｄｅｓｃｒｉｐｔｏｒ（）」が繰り返される。本実施形態では、ＡＩＴ内の第２記述子領域に、アプリケーションイニシャルディレクトリ記述子「Ａｐｐｌｉｃａｔｉｏｎ＿Ｉｎｉｔｉａｌ＿Ｄｉｒｅｃｔｏｒｙ＿Ｄｅｓｃｒｉｐｔｏｒ（）」またはアプリケーションイニシャルリソース記述子「Ａｐｐｌｉｃａｔｉｏｎ＿Ｉｎｉｔｉａｌ＿Ｒｅｓｏｕｒｃｅ＿Ｄｅｓｃｒｉｐｔｏｒ（）」を設ける。
【００３２】
第１記述子領域は、１個のＡＩＴ内に一箇所のみ存在する。第１記述子領域には、複数のアプリケーションに共通の共通記述子（common descriptor）が設けられる。
第２記述子領域は、ＡＩＴ内のアプリケーションループ内で、各アプリケーションに対応して一箇所存在する。第２記述子領域には、そのアプリケーション用のアプリケーション記述子（application descriptor）が設けられる。アプリケーション初期提示記述子は、第２記述子領域に設けられるため、アプリケーションごとにエントリーポイントリソースとイニシャルリソースとを特定するための情報が記述される。つまり、受信機１は、ＡＩＴを取得し、そのＡＩＴのアプリケーションループ内に含まれる各アプリケーションについて、アプリケーション初期提示記述子を参照して、エントリーポイントリソースとイニシャルリソースとを特定する。例えば、アプリケーションイニシャルディレクトリ記述子がＡＩＴに含まれている場合、受信機１は、アプリケーションイニシャルディレクトリ記述子を参照し、イニシャルディレクトリを識別するディレクトリ識別情報に基づいて、イニシャルディレクトリに格納されるエントリーポイントリソースとイニシャルリソースとを特定する。また、例えば、アプリケーションイニシャルリソース記述子がＡＩＴに含まれている場合、受信機１は、アプリケーションイニシャルリソース記述子を参照し、エントリーポイントリソースまたはイニシャルリソースを識別するリソース識別情報に基づいて、エントリーポイントリソースとイニシャルリソースとを特定する。
【００３３】
言い換えれば、ＡＩＴ取得部１３は、アプリケーションごとのアプリケーション初期提示記述子を参照することによって、エントリーポイントリソースとイニシャルリソースとを特定する。そして、ＡＩＴ取得部１３は、特定したエントリーポイントリソースとイニシャルリソースとを通信送受信部１４または放送信号解析部１２を介して取得する。
【００３４】
以下では、ＡＩＴの、第１記述子領域と第２記述子領域以外の部分について説明する。
（１）section_syntax_indicator（セクションシンタックス指示）
このセクションシンタックス指示は１ビットのフィールドで、その値は常に「１」である。
（２）section_length（セクション長）
セクション長フィールドからCRC32を含むセクションの最後までのセクションのバイト数を示す１２ビットのフィールドである。全セクションの長さが４０９６を超えないようにするため、セクション長の値は４０９３（１６進数で「０ｘＥＦＤ」）を超えないものとする。
（３）application_type（アプリケーション形式）
ＡＩＴの制御対象となるアプリケーションの形式を示す１６ビットのフィールドである。
アプリケーション形式の値とその意味は次の通りである。すなわち、値「０ｘ００００」は、将来の使用のためにリザーブされている。値「０ｘ０００１」は、ARIB-Jアプリケーションであることを示す。値「０ｘ０００２」から「０ｘ０００Ｆ」までは、将来の使用のためにリザーブされている。値「０ｘ００１０」は、放送通信連携ＨＴＭＬ５アプリケーションであることを示す。値「０ｘ００１１」は、将来の使用のためにリザーブされている。値「０ｘ００１２」から「０ｘ７ＦＦＦ」までは、将来の使用のためにリザーブされている。
【００３５】
（４）version_number（バージョン番号）
５ビットのフィールドであり、サブテーブルのバージョン番号である。バージョン番号はサブテーブル内の情報に変化があった場合に１加算される。その値が３１（２進数の「１１１１１」）になった場合には、その次には０に戻る。
（５）current_next_indicator（カレントネクスト指示）
１ビットのフィールドであり、常に「１」とする。
（６）section_number（セクション番号）
８ビットのフィールドであり、セクションの番号を表す。サブテーブル内で最初のセクションのセクション番号は「０ｘ００」である。セクション番号は、同一のテーブル識別およびアプリケーション形式をもつセクションの追加ごとに１加算される。
（７）last_section_number（最終セクション番号）
８ビットのフィールドであり、そのセクションが属するサブテーブルにおける最後のセクションの番号を規定する。
（８）common_descriptors_length（共通記述子ループ長）
この１２ビットのフィールドであり、後続の共通記述子領域のバイト長を規定する。この記述子領域内の記述子は、ＡＩＴサブテーブル内のすべてのアプリケーションに適用される。
【００３６】
（９）application_loop_length（アプリケーション情報ループ長）
１２ビットのフィールドであり、後続するアプリケーション情報が格納されるループ全体のバイト長を規定する。
（１０）application_control_code（アプリケーション制御コード）
８ビットのフィールドであり、アプリケーションの状態を制御する制御コードを規定する。このフィールドのセマンティックスはアプリケーション形式ごとに規定する。アプリケーション形式ごとに規定されない場合は、以下に示すセマンティクスとする。すなわち、アプリケーション制御コードの値が「０ｘ０１」（識別名：ＡＵＴＯＳＴＡＲＴ）のとき、アプリケーションを起動することを意味する。値が「０ｘ０２」（識別名：ＰＲＥＳＥＮＴ）のとき、アプリケーションが実行可能な状態であることを示す。値が「０ｘ０４」（識別名：ＫＩＬＬ）のとき、アプリケーションを終了することを意味する。値が「０ｘ０５」（識別名：ＰＲＥＦＥＴＣＨ）のとき、アプリケーションを取得し保持することを意味する。
（１１）application_descriptors_loop_length（アプリケーション情報記述子ループ長）
１２ビットのフィールドであり、後続の記述子領域のバイト長を規定する。この記述子領域内の記述子は、指定したアプリケーションのみに適用される。
（１２）CRC_32（ＣＲＣ，巡回上長符号）
誤り検出／誤り訂正のための巡回上長符号であり、ＩＴＵ−Ｔ勧告Ｈ．２２２．０に従うものである。
【００３７】
次に、図４および図５を参照してアプリケーションの初期提示のための記述子のデータ構造について説明する。図４に示すアプリケーションイニシャルディレクトリ記述子は、ディレクトリごとに必須フラグを指定するための記述子である。一方で、図５に示すアプリケーションイニシャルリソース記述子は、リソースデータ（ファイル）ごとに必須フラグを指定するための記述子である。本実施形態によるシステムでは、アプリケーションイニシャルディレクトリ記述子とアプリケーションイニシャルリソース記述子のいずれか一方のみを使用するように実装しても良いし、アプリケーションイニシャルディレクトリ記述子とアプリケーションイニシャルリソース記述子の両方の使用を許容するように実装しても良い。
【００３８】
図４は、本実施形態において用いられるアプリケーションイニシャルディレクトリ記述子のデータ構造を示す概略図である。このアプリケーションイニシャルディレクトリ記述子は、図３に示されるＡＩＴ内の第２記述子領域に設けられる。
以下では、アプリケーションイニシャルディレクトリ記述子内の各フィールドについて説明する。
（１）descriptor_tag（記述子タグ）
記述子タグは各記述子を識別する。記述子タグのビット長は用いるメディアトランスポートシステムにより異なる。本実施形態において、アプリケーションイニシャルディレクトリ記述子の記述子タグフィールドのビット数は１６である。
（２）descriptor_length（記述子長）
記述子長は、このフィールドより後に続くデータバイト数を示す。つまり、記述子長フィールドは、このフィールドより後に続くデータバイト数を示す書き込む領域である。記述子長フィールドのビット数は、アプリケーションイニシャルディレクトリ記述子により異なる。本実施形態において、アプリケーションイニシャルディレクトリ記述子の記述子長フィールドのビット数は８である。
【００３９】
（３）initial_directory_number（初期ディレクトリ数）
初期ディレクトリ数は、イニシャルリソースを格納するイニシャルディレクトリの数を示す。つまり、初期ディレクトリ数は、エントリーポイントリソースとイニシャルリソースを格納するディレクトリの数を書き込む領域である。本実施形態において、アプリケーションイニシャルディレクトリ記述子の初期ディレクトリ数フィールドのビット数は８である。
（４）node_tag（ノードタグ）
ノードタグは、ファイルシステムにおけるノード（ここでは、ディレクトリ）を識別する情報である。アプリケーションイニシャルディレクトリ記述子におけるノードタグフィールドは、イニシャルディレクトリを示すノードタグを書き込む領域である。このＡＩＴ内におけるノードタグは、後述するデータディレクトリ管理テーブル内のノードタグと関連付けられる。本実施形態において、アプリケーションイニシャルディレクトリ記述子のノードタグフィールドのビット数は１６である。
【００４０】
（５）required_flag（必須フラグ）
必須フラグは、対応するデータが初期提示にために必須であるか否かを示す。つまり、必須フラグは、対応するデータの重要度を表す重要度情報である。アプリケーションイニシャルディレクトリ記述子における必須フラグフィールドは、イニシャルディレクトリが格納するイニシャルリソースがアプリケーションの初期提示において必須であるか否かを書き込む領域である。イニシャルリソースがアプリケーションの初期提示において必須であるとは、アプリケーションの起動処理において、そのイニシャルリソースが必ず参照されなくてはならないことである。イニシャルリソースがアプリケーションの初期提示において必須ではないとは、アプリケーションの起動処理において、そのイニシャルリソースが参照されることが望ましいが、参照されなくてもよいことである。つまり、あるイニシャルリソースが必須ではない場合、そのイニシャルリソースを参照することなく、受信機１が最低限の状態でアプリケーションの初期提示を行える。必須フラグのビット長は１である。イニシャルリソースが必須である場合、必須フラグフィールドには、値「１」が書き込まれる。これに対して、イニシャルリソースが必須ではない場合、必須フラグフィールドには、値「０」が書き込まれる。
【００４１】
以上のように、アプリケーションイニシャルディレクトリ記述子は、イニシャルディレクトリの識別情報を含むデータである。これにより、受信機1は、ＡＩＴを参照するだけでイニシャルリソースが所属するイニシャルディレクトリを特定することができる。これにより、受信機１は、放送波などから蓄積したデータをパースすることなく、直接的にイニシャルリソースを特定し、取得することができるため、アプリケーションの初期提示における処理量を低減することができる。また、ＡＩＴの生成装置は、イニシャルリソースの指定において、複数のイニシャルリソースをまとめたイニシャルディレクトリの単位でイニシャルリソースを指定することができるため、処理を簡潔にすることができる。
【００４２】
また、アプリケーションイニシャルディレクトリ記述子は、イニシャルディレクトリが格納するイニシャルリソースの重要度を示す必須フラグを含むデータである。これにより、受信機１は、例えば、重要度の高いイニシャルリソースを優先的に取得し、重要度が高いイニシャルリソースを取得できた時点で、アプリケーションの初期提示を行うことができる。従って、受信機１は、アプリケーションの初期提示に要する時間を低減することができる。また、ＡＩＴの生成装置は、イニシャルリソースの指定において、複数のイニシャルリソースをまとめたイニシャルディレクトリの単位でイニシャルリソースの重要度を指定することができるため、処理を簡潔にすることができる。
【００４３】
図５は、本実施形態において用いられるアプリケーションイニシャルリソース記述子のデータ構造を示す概略図である。このアプリケーションイニシャルリソース記述子は、図３に示されるＡＩＴ内の第２記述子領域に設けられる。
（１）descriptor_tag（記述子タグ）
記述子タグは各記述子を識別する。記述子タグのビット長は用いるメディアトランスポートシステムにより異なる。本実施形態において、アプリケーションイニシャルリソース記述子の記述子タグフィールドのビット数は１６である。
（２）descriptor_length（記述子長）
記述子長は、このフィールドより後に続くデータバイト数を示す。つまり、記述子長フィールドは、このフィールドより後に続くデータバイト数を示す書き込む領域である。記述子長フィールドのビット数は、アプリケーションイニシャルリソース記述子により異なる。本実施形態において、アプリケーションイニシャルリソース記述子の記述子長フィールドのビット数は８である。
【００４４】
（３）initial_resource_number（初期リソース数）
初期リソース数は、イニシャルディレクトリの数を示す。つまり、初期ディレクトリ数は、エントリーポイントリソースとイニシャルリソースを格納するディレクトリの数を書き込む領域である。本実施形態において、アプリケーションイニシャルリソース記述子の初期リソース数フィールドのビット数は８である。
（４）Item_id（アイテム識別）
アイテム識別は、アイテムを識別する識別情報（ＩＤ）を示す。つまり、アプリケーションイニシャルリソース記述子におけるアイテム識別フィールドは、イニシャルリソースに対応するアイテムのアイテム識別を書き込む領域である。本実施形態において、アプリケーションイニシャルリソース記述子のアイテム識別フィールドのビット数は３２である。
【００４５】
（５）node_tag（ノードタグ）
ノードタグは、ファイルシステムにおけるノード（ここでは、リソース（ファイル））を識別する情報である。アプリケーションイニシャルリソース記述子におけるノードタグフィールドは、エントリーポイントリソースおよびイニシャルリソースを示すアイテムのノードタグを書き込む領域である。このＡＩＴ内におけるノードタグは、後述するデータディレクトリ管理テーブル内のノードタグと関連付けられる。本実施形態において、アプリケーションイニシャルリソース記述子のノードタグフィールドのビット数は１６である。
【００４６】
なお、本実施形態において、アプリケーションイニシャルリソース記述子におけるアイテム識別およびノードタグは、いずれもエントリーポイントリソースまたはイニシャルリソースを識別する。従って、アプリケーションイニシャルリソース記述子において、アイテム識別とノードタグとのいずれかが省略されてもよい。また、アイテム識別とノードタグとが両方含まれる場合、受信機１は、そのいずれかに基づいて、エントリーデータおよびイニシャルリソースを取得する。
【００４７】
（６）required_flag（必須フラグ）
必須フラグは、対応するデータが初期提示のために必須であるか否かを示す。アプリケーションイニシャルリソース記述子における必須フラグフィールドは、上述したアイテム識別またはノードタグが示すイニシャルリソースがアプリケーションの初期提示において必須であるか否かを書き込む領域である。イニシャルリソースがアプリケーションの初期提示において必須であるとは、アプリケーションの起動処理において、そのイニシャルリソースが必ず参照されなくてはならないことである。イニシャルリソースがアプリケーションの初期提示において必須ではないとは、アプリケーションの起動処理において、そのイニシャルリソースが参照されることが望ましいが、参照されなくてもよいことである。つまり、あるイニシャルリソースが必須ではない場合、そのイニシャルリソースを参照することなく、受信機１が最低限の状態でアプリケーションの初期提示を行える。必須フラグのビット長は１である。イニシャルリソースが必須である場合、必須フラグフィールドには、値「１」が書き込まれる。これに対して、イニシャルリソースが必須ではない場合、必須フラグフィールドには、値「０」が書き込まれる。
【００４８】
以上のように、アプリケーションイニシャルリソース記述子は、イニシャルリソースの識別情報を含むデータである。これにより、受信機１は、ＡＩＴを参照するだけでイニシャルリソースを特定することができる。これにより、受信機１は、放送波などから蓄積したデータをパースすることなく、直接的にイニシャルリソースを特定することができる。また、データディレクトリ管理テーブルを参照することなく、イニシャルリソースを特定することができる。これにより、アプリケーションの初期提示における処理量を低減することができる。また、ＡＩＴの生成装置は、イニシャルリソースの指定において、複数のイニシャルリソースを個別に指定することができるため、例えば、イニシャルリソースが所属するディレクトリがアプリケーションの初期提示において参照されないリソースを含む場合などであっても、処理を簡潔にすることができる。また、このような場合であっても、受信機１は、イニシャルリソースのみを取得することができるため、アプリケーションの初期提示における処理量を低減することができる。
【００４９】
また、アプリケーションイニシャルディレクトリ記述子は、イニシャルリソースの重要度を示す必須フラグを含むデータである。これにより、受信機１は、例えば、重要度の高いイニシャルリソースを優先的に取得したり、重要度が高いイニシャルリソースを取得できた時点で、アプリケーションの初期提示を行ったりすることができる。従って、受信機１は、アプリケーションの初期提示を行うまでの時間を低減することができる。
【００５０】
次に、放送信号として伝送されるデータの構成について説明する。本実施形態では、伝送のための技術として、ＭＭＴ（MPEG Media Transport）を用いる。
図６は、放送信号の一部として伝送されるＩＰデータフローの構成を示す概略構成図である。図示するように、ＩＰデータフローで伝送されるパッケージは、データ伝送メッセージ、ＭＰテーブル（ＭＭＴ（MPEG Media Transport）パッケージテーブル）、データアセットを含む。データ伝送メッセージは、データディレクトリ管理テーブルとデータアセット管理テーブルとを含む。なお、このＩＰデータフローの構成自体は、既存の技術によるものである。
【００５１】
データディレクトリ管理テーブルは、ファイルごとに、パス名とノードタグとのペアのエントリーを有している。パス名は、ディレクトリノード名とディレクトリ内におけるファイル名とを合わせたものであり、ファイルをユニークに識別するための名前である。ノードタグもまたデータディレクトリ管理テーブルの各エントリーを識別可能な値であり、データアセット管理テーブル内のエントリーとの関連付けなどのためにこのノードタグが用いられる。
【００５２】
データアセット管理テーブルは、データアセットを管理するためのテーブルである。データアセット管理テーブルにおける各エントリーは、コンポーネントタグ、ＭＰＵ（Media Processing Unit）シーケンス番号、アイテムＩＤ、ノードタグを有している。このうち、コンポーネントタグは、アセットを識別するための情報であり、ＭＰテーブル内のコンポーネントタグと関連付けられる。また、アイテムＩＤは、データアセット内の具体的なアイテムを指し示す。ノードタグは、前述の通り、データディレクトリ管理テーブル内のエントリーと関連付けるために用いられる。
【００５３】
ＭＰテーブルは、アセットのロケーションへのリンクを有するテーブルである。ＭＰテーブルにおける各エントリーは、アセットＩＤ、コンポーネントタグ、ロケーション情報を含む。このうち、アセットＩＤは、映像アセットや、データアセットや、データアセット等のアセットを識別するための情報である。また、コンポーネントタグは、データアセット管理テーブル内のエントリーとの関連付けのために用いられる値である。また、ロケーション情報は、具体的なデータアセットのロケーションを指し示す。ロケーション情報は、例えば、放送波のＩＰデータフローにおけるデータアセットの位置の情報や、外部の装置において管理されるデータアセットの取得ＵＲＬ（Uniform Resource Locator）などを示す。
【００５４】
データアセットは、実際のアセットのデータを格納するものである。各データアセットは、単数または複数のＭＰＵを含む。また、各ＭＰＵは、データアセット内においてＭＰＵシーケンス番号で識別されるとともに、単数または複数のアイテムを含む。
【００５５】
次に、受信機１の内部においてアプリを実行させるにあたり、初期提示に必須であるリソースの到着を待受けるための機能について説明する。
図７は、受信機１が内部で用いるイベントリスナーのインターフェースおよび、関連する定義等を示すものである。
同図において、MMTResoureReference（ＭＭＴリソース参照）は、データリソースであるファイルのパス名を表すデータ構造である。このデータ構造は、フォルダーパス（folder_path）とファイル名（filename）という２つのストリングで構成される。
また、関数addDataResourceEventListenerは、データリソースに関するリスナーを登録するためのものである。この関数addDataResourceEventListenerは、２つのパラメーターで呼び出される。第１のパラメーターは、resource_ref（リソース参照）であり、これは上記のMMTResoureReferenceの型を有する。第２のパラメーターは、listener（リスナー）であり、MMTDataResourceEventListenerの型を有する。このlistenerは、イベントが到着した際に、イベントの種別と、そのイベントの対象のリソースの情報とを返す手段である。
また、関数removeDataResoureEventListenerは、上記のリスナーを削除するためのものである。
【００５６】
関数addDataResourceEventListenerおよび関数removeDataResourceEventListenerは、蓄積待受部２４から呼び出される機能である。蓄積待受部２４は、関数addDataResourceEventListenerを用いてリスナーを登録した後、そのリスナーを削除するまでの間、指定したリソースに関するイベントを待ち受ける。また、蓄積待受部２４は、到着したイベントに関する通知を受ける。この通知は、ファイルシステム２１における状態の変化に応じて、蓄積状態通知部２３から発せられるものである。
MMTDataResourceEventTypeは、上記のイベントの種別を表すものである。ここでのイベントの種別は、"updated"と"stored"と"stored_required"と"deleted"である。"updated"は、対象のリソースの更新が開始されたこと（元々そのリソースがない状態のときから受信が開始された場合を含む）を表すイベントである。また、"stored"は、対象のリソースが蓄積された（取得完了）ことを表すイベントである。また、"stored_required"は、対象のリソースのうち少なくとも初期提示のために必要なリソースが蓄積された（取得完了）ことを表すイベントである。また、"deleted"は、対象のリソースがファイルシステム２１から削除されたことを表すイベントである。
【００５７】
図８は、上記の関数addDataResourceEventListenerの仕様を示すものである。同図に示すように、この関数addDataResourceEventListenerは、データリソースの更新・取得完了を監視するイベントリスナーを登録するものである。パラメーターresource_refは、監視対象とするリソースの参照（パス名）である。パラメーターlistenerは、監視中のリソースが更新または取得完了されたときに呼び出されるべき関数である。
【００５８】
図９は、上記の関数removeDataResourceEventListenerの仕様を示すものである。同図に示すように、この関数removeDataResourceEventListenerは、上記の関数addDataResourceEventListenerで登録したイベントリスナーを削除するものである。パラメーターlistenerは、削除対象とするイベントリスナーである。このパラメーターlistenerが省略された場合には、その時点で登録されているすべてのイベントリスナーが削除されることを意味する。
【００５９】
図１０は、データ型MMTDataResourceEventTypeの仕様を示すものである。"updated"は、監視中のデータリソースが受信開始、更新開始されたことによってリスナーが呼び出されたことを示す。"stored"は、監視中のデータリソースが受信機に取得完了されたことによってリスナーが呼び出されたことを示す。"stored_required"は、初期提示に必要なデータリソースが受信機に取得完了されたことによってリスナーが呼び出されたことを示す。"deleted"は、監視中のデータリソースがキャッシュ（受信機１のファイルシステムにおけるキャッシュ）から削除されたことによってリスナーが呼び出されたことを示す。
【００６０】
図１１は、イベント発生時に呼び戻される関数DataResourceEventListenerの仕様を示すものである。同図に示すように、この関数DataResourceEventListenerのパラメーターevent_typeは、イベントの種別を表すデータであり、図１０に示した通りである。また、パラメーターresource_refは、開始対象として指定されたリソースであり、今回のイベントが発生したリソースを表す。
なお、蓄積状態通知部２３は、この関数DataResourceEventListenerの機能を用いてリソースの状態の変化を蓄積待受部２４に通知する。
【００６１】
図１２は、特定のリソースに関する、監視開始から監視終了までの受信機１における処理の流れを示すフローチャートである。以下、このフローチャートに沿って説明する。ここで、リソースとは、リソースデータ（ファイル）や、リソースデータを格納するディレクトリである。
ステップＳ１：まず、蓄積待受部２４が、特定のリソースを指定して、リスナーを登録する。
ステップＳ２：次に、蓄積待受部２４は、上のステップＳ１で登録したリスナーで指定されたリソースに関して、イベントの到着を待つ。この間、ファイル蓄積検知部２２は、対象のリソースを監視し続ける。なお、このステップＳ２でファイル蓄積検知部２２がファイルの状況を監視している間に、蓄積待受部２４は登録していたリスナーを削除することもできる。指定されたリソースに関して予め定められた状態の変化が生じた場合、あるいは蓄積待受部２４がリスナーを削除する関数を発行した場合に、このステップＳ２を抜けて次のステップに進む。
【００６２】
ステップＳ３：次に、蓄積状態通知部２３は、ステップＳ２を抜けた理由を解析する。ステップＳ２を抜けるのは、蓄積待受部２４がリスナーを削除した場合、またはファイル蓄積検知部２２が監視対象としているリソースの状態の変化を検知した場合である。リスナーが削除された場合（ステップＳ３：ＹＥＳ）、受信機１はこのフローチャート全体の処理を終える。ファイル蓄積検知部２２がファイルの状態の変化を検知した場合（ステップＳ３：ＮＯ）、次のステップＳ４に進む。
ステップＳ４：ステップＳ４に移った場合には、蓄積状態通知部２３は、関数DataResourceEventListenerを呼ぶことによって、発生したイベントを蓄積待受部２４に通知する。ステップＳ４における処理が終了すると、ステップＳ２に戻って当該リソースに関する次のイベントを待つ。
【００６３】
なお、アプリがＪａｖａＳｃｒｉｐｔ（登録商標）を利用する場合、蓄積待受部２４は、受けた通知に基づきアプリの実行を開始するか否かを制御する。つまり、初期提示に必要なリソースがすべてファイルシステム２１に蓄積完了した状態において、蓄積待受部２４は、そのアプリによる初期提示の開始を許可する。
アプリがＪａｖａＳｃｒｉｐｔ（登録商標）を利用せず、ＨＴＭＬ５のみで記述されている場合には、アプリ実行制御部１５が初期提示に必要なリソースを知り、ファイル蓄積検知部２２にそれらのファイルが何であるかを伝える。ファイルシステム２１にそれらのファイルのすべてが蓄積されると、ファイル蓄積検知部２２は、蓄積状態通知部２３から蓄積待受部２４への通知手段を経由して、アプリ実行制御部１５に蓄積完了を通知し、アプリ実行制御部１５はアプリ実行部１７に提示が可能であることを通知する。そして、アプリ実行部１７はファイルシステム２１からリソースを読出し、提示を行う。
【００６４】
ここで、上で説明したイベント"stored"および"stored_required"の意味の持たせ方について、複数の場合を説明する。
（Ａ）リソースを指定してリスナーを登録する場合
前述のとおり、関数addDataResourceEventListenerは、パラメーターとしてresource_refを指定して呼び出される。ここでパラメーターとして指定されるリソースは、ディレクトリの場合と、単体のファイルの場合とがあり得る。
（Ａ−１）指定されるリソースがディレクトリである場合
指定されるリソースがディレクトリである場合であって、且つそのディレクトリがアプリケーションイニシャルディレクトリ記述子内において「初期提示に必須」であると定義されている場合、蓄積状態通知部２３は、当該ディレクトリ内のすべてのファイルの蓄積完了が検知された時点で、当該ディレクトリの蓄積完了（"stored"）を蓄積待受部２４に通知する。
指定されるリソースがディレクトリである場合であって、且つそのディレクトリに関する情報がアプリケーションイニシャルディレクトリ記述子内に含まれていない場合、蓄積状態通知部２３は、当該ディレクトリ内のすべてのファイルの蓄積完了が検知された時点で、当該ディレクトリの蓄積完了（"stored"）を蓄積待受部２４に通知する。また、蓄積状態通知部２３は、当該ディレクトリ内のファイルのうち初期提示に必要なファイル（アプリケーションイニシャルリソース記述子内での定義に基づく）がすべて蓄積完了した時点で、当該ディレクトリの「初期提示に必要なデータリソースが取得完了」したこと（"stored_required"）を蓄積待受部２４に通知する。
（Ａ−２）指定されるリソースが単体のファイルである場合：
指定されるリソースが単体のファイルである場合、蓄積状態通知部２３は、当該ファイルの蓄積完了が検知された時点で、当該ディレクトリの蓄積完了（"stored"）を蓄積待受部２４に通知する。
【００６５】
（Ｂ）リソースを指定せずにリスナーを登録する場合
ここで説明するように、パラメーターとしてresource_refを指定せずに関数addDataResourceEventListenerを呼び出すことができるようにしても良い。
この場合、現在起動しようとしているアプリケーションに関するＡＩＴ内のアプリケーションイニシャルディレクトリ記述子内において「初期提示に必須」であると定義されているすべてのディレクトリ内のすべてのファイルが蓄積完了した場合、あるいは、同ＡＩＴ内のアプリケーションイニシャルリソース記述子内において「初期提示に必須」であると定義されているすべてのファイルが蓄積完了した場合に、蓄積状態通知部２３は、「初期提示に必要なデータリソースが取得完了」したこと（"stored_required"）を蓄積待受部２４に通知する。
また、この場合、現在起動しようとしているアプリケーションに必要なすべてのリソースの蓄積が完了した段階で、蓄積状態通知部２３は、「蓄積完了」（"stored "）を蓄積待受部２４に通知する。
【００６６】
上記の（Ａ）または（Ｂ）のいずれの場合においても、蓄積待受部２４は、初期提示に必須のリソースがそろった段階で、初期提示を開始するよう、アプリ実行部１７に指示する。
【００６７】
なお、上述した実施形態における受信機の機能の一部をコンピューターで実現するようにしても良い。その場合、受信機の機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【００６８】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【００６９】
本発明は、テレビ放送をはじめとして映像等によるコンテンツを提供する事業、およびそのための受信機等に利用することが可能である。また、そのような受信機上で稼働するアプリケーションを提供する事業に利用することが可能である。
【符号の説明】
【００７０】
１  受信機
３  送信装置
５  サーバー装置
１１  放送受信部
１２  放送信号解析部
１３  ＡＩＴ取得部（アプリケーション情報テーブル取得部）
１４  通信送受信部
１５  アプリ実行制御部
１７  アプリ実行部（アプリケーション実行部）
２１  ファイルシステム（ファイル蓄積部）
２２  ファイル蓄積検知部
２３  蓄積状態通知部
２４  蓄積待受部
１００  テレビシステム
【図１】
0006478381.tif 000002
【図２】
0006478381.tif 000003
【図３】
0006478381.tif 000004
【図４】
0006478381.tif 000005
【図５】
0006478381.tif 000006
【図６】
0006478381.tif 000007
【図７】
0006478381.tif 000008
【図８】
0006478381.tif 000009
【図９】
0006478381.tif 000010
【図１０】
0006478381.tif 000011
【図１１】
0006478381.tif 000012
【図１２】
0006478381.tif 000013