JP6543819B2 - 処理装置およびプログラム - Google Patents

Description

本発明は、処理装置、プログラムおよびデータ構造に関する。

本発明は、放送伝送路や通信伝送路を用いて配信されるアプリケーションプログラム（以下、アプリケーションと呼ぶ）に係るコンテンツファイルを一括して扱うためのパッケージ化方法、フォーマットに関する。当該フォーマットは、放送通信連携サービス用アプリケーションの開発環境におけるプロジェクト管理、放送局・制作者間における素材交換、放送波や通信伝送路に各種のコンテンツファイル群を送信する送信装置に供給する際の共通フォーマットとして利用される。

第一世代の地上波デジタル放送／ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓａｔｅｌｌｉｔｅ）デジタル放送／ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ）デジタル放送では、コンテンツ記述言語であるＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いてコンテンツが記述されていた。ＢＭＬは、非特許文献１に規定されているデータ放送サービス専用のコンテンツ記述言語である。非特許文献１では、ＢＭＬによるコンテンツの記述方式や、ＢＭＬによって記述されたコンテンツをＭＰＥＧ−２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）を用いて多重化および伝送するためのデータ構造について記載されている。しかしながら、ＢＭＬが規定された時点において、ＢＭＬを用いて記述されていたコンテンツファイル群を一括して扱うためのパッケージ化する方式について規定されていなかった。番組制作者と放送局との間、もしくは放送局間における素材交換における入力形式と、コンテンツを放送波で送信するための送信プログラムへの入力形式が個々に異なっていたため相互運用性の確保が課題であった。

そこで、非特許文献２に記載のコンテンツの物理構造とメタ情報の記述言語であるＢＣＭＬ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｅｎｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が規定された。コンテンツの物理構造とは、フォルダの階層構造と、当該コンテンツが格納されるコンテンツファイル群の配置方法を意味する。これにより、データ放送サービスの運用における相互運用性が改善された。
しかし、サービス提供の際、非特許文献２に記載のコンテンツの物理構造を、非特許文献１に規定される当該コンテンツの送信時におけるデータ構造（例えば、カルーセル、モジュール等）に対応させる必要がある。そのため、ＢＭＬを用いてコンテンツを記述する際、及び、ＢＣＭＬを用いてコンテンツのメタ情報を記述する際、コンテンツ制作者は種々の要件を理解することが求められる。種々の要件として、例えば、インターネット上に掲載されるウェブページの記述言語として普及しているＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）との言語仕様の差異、伝送方式への理解の必要性、コンテンツ構造の自由度の低さ、専用の開発環境の必要性、等がある。そのため、ＢＭＬ及びＢＣＭＬを用いて記述されたデータ放送コンテンツの制作環境の普及や技術を有する人材の確保が阻まれていた。

他方、インターネットを介して提供されるウェブページの記述言語として、従来のＨＴＭＬの仕様を拡張したＨＴＭＬ５が策定された。ＨＴＭＬ５では、映像、音声、２Ｄ（２−Ｄｉｍｅｎｓｉｏｎａｌ）／３Ｄグラフィックスなど、従来のＨＴＭＬよりも多様なメディアを高い自由度で取り扱うことが可能になる。かかる動きに呼応して、データ放送コンテンツの記述言語としてＨＴＭＬ５を利用する方式が策定された（非特許文献３参照）。第一世代のデジタル放送サービスの付加サービスの一部として非特許文献３に規定される仕様に準拠したＨＴＭＬ５アプリケーションを用いた放送通信連携サービス（ハイブリッドキャスト（登録商標））が、２０１５年３月現在、既に実用化されている。

実用化されている放送通信連携サービスでは、受信機がアプリケーションを取得するのに最低限必要な制御情報をＭＰＥＧ−２ ＴＳに多重化したうえで放送波により伝送し、コンテンツファイル群をインターネットに接続されたウェブサーバを介して配信する。しかしながら、既存の受信機の動作保証、伝送帯域の制約などの理由により、ＨＴＭＬ５アプリケーションのコンテンツファイル群の放送波による伝送は、２０１５年３月現在実用化されていない。

放送サービスにおけるＨＴＭＬ５アプリケーションの採用と並行して、第二世代デジタル放送の標準化が進められている。例えば、非特許文献４には、ＭＰＥＧ−Ｈ ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ、単にＭＭＴとも呼ばれる）を利用したデジタル放送の多重化方式が規定されている。第二世代デジタル放送の伝送方式としてＭＰＥＧ−２ ＴＳを採用する場合でも既存の受信機の動作を保証しないことが許容されれば、放送通信連携サービスにおいてＨＴＭＬ５アプリケーションのコンテンツファイル群の放送波による伝送が実用化される可能性がある。伝送において通信伝送路の他、放送波を用いることで、ウェブサーバへのアクセス負荷の低減、通信伝送路に接続していない受信機によるアプリケーションの取得、実行が期待される。

電波産業会，デジタル放送におけるデータ放送符号化方式と伝送方式，ＡＲＩＢ ＳＴＤ−Ｂ２４ ６．１版，２０１４．１２．１６ 電波産業会，デジタル放送におけるデータ放送番組交換方式，ＡＲＩＢ ＳＴＤ−Ｂ３５ １．２版，２００６．３．１４ ＩＰＴＶフォーラム，ＨＴＭＬ５ブラウザ仕様，ＩＰＴＶＦＪ ＳＴＤ−００１１ ２．０版，２０１４．６．２９ 電波産業会，デジタル放送におけるＭＭＴによるメディアトランスポート方式，ＳＴＤ−Ｂ６０ １．１版，２０１４．１２．１６ "．ＺＩＰ Ｆｉｌｅ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ"，［ｏｎｌｉｎｅ］，ＰＫＷＡＲＥ Ｉｎｃ．，［２０１５年２月２０日検索］，インターネット＜ｈｔｔｐｓ：／／ｐｋｗａｒｅ．ｃａｃｈｅｆｌｙ．ｎｅｔ／ｗｅｂｄｏｃｓ／ＡＰＰＮＯＴＥ／ＡＰＰＮＯＴＥ−６．３．３．ＴＸＴ＞ Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ，Ｔｈｅ ＭＸＦ Ｆｉｌｅ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ （ｔｈｅ ｏｖｅｒａｌｌ ｍａｓｔｅｒ ｄｏｃｕｍｅｎｔ），ＳＭＰＴＥ ３７７Ｍ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＦＩＬＥ ＴＲＡＮＳＦＥＲ ＰＲＯＴＯＣＯＬ（ＦＴＰ），Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ９５９，１９８５．１０

２０１５年３月現在、実用化されている放送通信連携サービスでは、ＨＴＭＬ５アプリケーションは通信伝送路のみを介して伝送される。サービス提供者は、送信に際しコンテンツファイル群をそのまま１台もしくは複数台のウェブサーバにアップロードすればよい。このため、特にコンテンツファイル群の内部構造、メタ情報の記述方法を規定せず、単にコンテンツの基底となるフォルダをそのまま圧縮（例えば、非特許文献５）しても直ちに相互運用性は損なわれない。しかしながら、今後、サービス規模の拡大、第二世代デジタル放送サービスにおけるアプリケーションの放送波伝送の実用化により伝送経路が多様になる一方で、コンテンツ制作者、サービス提供者が個々に運用するとコンテンツファイル群の相互運用性が損なわれるおそれがある。また、相互運用において、コンテンツファイル群を一括して取り扱う場合のように比較的簡易な運用では、非特許文献５に記載のＺＩＰ形式のファイルとして構成されていても利便性が確保される。これに対し、ファイル単位でのコンテンツファイル群の伝送や番組アーカイブシステムとの親和性を確保するためには、非特許文献６に記載のＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）との相互運用が期待される。

本発明は上記の点に鑑みてなされたものであり、デジタル放送サービスで提供されるアプリケーションプログラムに関するコンテンツの相互運用性を向上できる処理装置、プログラムおよびデータ構造を提供することを課題とする。また、コンテンツファイル群が時間経過に応じて変化しない静的なＨＴＭＬ５アプリケーションの他、送信対象のコンテンツファイル群が時間経過に応じて動的に変化するアプリケーションの送信、あるいはそれらの動作検証を実現する。また、ＺＩＰファイルとして構成されたコンテンツファイル群とＭＸＦファイルとして構成されたコンテンツファイル群との相互運用性を確保する。

本発明は上記の課題を解決するためになされたものであり、［１］本発明の一態様は、デジタル放送サービスのアプリケーションプログラムに関するコンテンツファイルが配置されたコンテンツルートフォルダと、前記アプリケーションプログラムのエントリポイントを示すコンテンツ情報を含むパッケージエントリポイントメタデータとが配置されたアプリケーションパッケージから、前記パッケージエントリポイントメタデータを解析して前記アプリケーションプログラムを特定するメタデータ解析部と、前記コンテンツルートフォルダ以下のフォルダの構造を解析して、前記アプリケーションプログラムに関するコンテンツファイルを前記コンテンツルートフォルダから抽出するコンテンツ構造解析部と、ファイル制御部と、を備え、前記コンテンツ構造解析部は、前記コンテンツファイルのファイル名を解析して、前記ファイル名が示す時刻と前記コンテンツファイルの所在を示す制御対象ファイルリストを生成することを特徴とし、前記ファイル制御部は、制御対象ファイルリストを参照して、番組の編成時刻に相当する時刻を示すファイル名を有するコンテンツファイルを選択する処理装置である。
［１］の構成によれば、パッケージエントリメタデータを参照して、アプリケーションプログラムの最初に参照されるエントリポイントの所在が直ちに識別される。制作者が任意に構成したコンテンツファイルが処理対象として効率的に抽出されるので、制作者と放送事業者もしくはサービス提供者間において共通の処理対象が特定されることにより相互運用性が向上する。また、時間経過に応じてコンテンツファイルが更新されるコンテンツについても、番組編成の際にファイル名により処理開始時刻と処理対象のファイルが直ちに特定される。制作者は、処理の開始やその時刻を効率的に検証することができ、放送事業者もしくはサービス提供者は、制作者が意図した処理開始時刻に基づいた番組編成を円滑に行うことができる。

［２］本発明の一態様は、上述の処理装置であって、前記ファイル制御部は選択したコンテンツファイルが空ファイルである場合、前記選択したファイルのファイル名が示す時刻において前記コンテンツファイルに係る処理を停止させることを特徴とする。
［２］の構成によれば、番組編成の際に停止されるコンテンツについて、ファイル名により停止時刻と停止対象のファイルが直ちに特定される。制作者は、処理の停止やその時刻を効率的に検証することができ、放送事業者もしくはサービス提供者は、制作者が意図した処理停止時刻に基づいた番組編成を円滑に行うことができる。

［３］本発明の一態様は、上述の処理装置であって、前記コンテンツファイルが配置されるフォルダならびに識別情報を示すヘッダと、前記コンテンツファイルに格納されたデータとを含むセットがコンテンツファイル間で連結された第１の形式のファイルから、前記セット毎に前記データを格納したコンテンツファイルを前記ヘッダが示すフォルダに配置して前記アプリケーションパッケージとして展開する展開部を備える。
［３］の構成によれば、第１の形式のファイルから展開により再生されたアプリケーションパッケージから番組編成の際に処理対象のコンテンツファイルが特定される。番組編成において一括した取扱いに便宜な第１の形式のファイルの活用を図ることができる。

［４］本発明の一態様は、上述の処理装置であって、前記セットの配置を示す区分データが前記セットそれぞれの先頭にさらに配置された第２の形式のファイルから、前記区分データをそれぞれ除外して前記第１の形式のファイルに変換する第１変換部を備える。
［４］の構成によれば、第２の形式のファイルを、第１の形式のファイルへの変換を区分データの除外といった簡素な処理により実現することができる。区分データによる個々のコンテンツファイルに対するアクセスが容易な第２の形式のファイルを、第１の形式のファイルに変換して一括した取扱いを促進することができる。

［５］本発明の一態様は、上述の処理装置であって、前記第１の形式に含まれる前記セットそれぞれの先頭に前記セットの配置を示す区分データを配置して第２の形式のファイルに変換する第２変換部を備える。
［５］の構成によれば、第１の形式のファイルから第２の形式へのファイルへの変換を区分データの配置といった簡素な処理により実現することができる。そのため、一括した取扱いに便宜な第１の形式のファイルを、第２の形式のファイルに変換して個々のコンテンツファイルに対するアクセスを促進することができるので、コンテンツ制作、編集を効率よく行うことができる。

［６］本発明の一態様は、上述の処理装置であって、前記パッケージエントリポイントメタデータは、前記コンテンツファイルの伝送方式を示すトランスミッション情報を含み、前記トランスミッション情報が示す伝送方式を用いて前記コンテンツファイルを送信させる送信制御部を備える。
［６］の構成によれば、制作者が任意に構成したコンテンツファイルが送信対象として効率的に抽出され、放送事業者もしくはサービス提供者が指定した所望の伝送方式を用いて送信される。そのため、デジタル放送サービスを提供において、制作者と放送事業者もしくはサービス提供者との間の相互運用性が向上する。

［７］本発明の一態様は、上述の処理装置であって、前記アプリケーションプログラムに記述される命令が示す処理を実行する実行部を備える。
［７］の構成によれば、制作者が任意に構成したコンテンツファイルが処理対象として効率的に抽出されるので、制作されたアプリケーションパッケージに配置されるアプリケーションプログラムの動作検証を円滑に行うことができる。

［８］本発明の一態様は、処理装置のコンピュータに、デジタル放送サービスのアプリケーションプログラムに関するコンテンツファイルが配置されたコンテンツルートフォルダと、前記アプリケーションプログラムのエントリポイントを示すコンテンツ情報を含むパッケージエントリポイントメタデータとが配置されたアプリケーションパッケージから、前記パッケージエントリポイントメタデータを解析して前記アプリケーションプログラムを特定するメタデータ解析手順、前記コンテンツルートフォルダ以下のフォルダの構造を解析して、前記アプリケーションプログラムに関するコンテンツファイルを前記コンテンツルートフォルダから抽出するコンテンツ構造解析手順、ファイル制御手順、を実行させるためのプログラムであって、前記コンテンツ構造解析手順は、前記コンテンツファイルのファイル名を解析して、前記ファイル名が示す時刻と前記コンテンツファイルの所在を示す制御対象ファイルリストを生成することを特徴とし、前記ファイル制御手順は、制御対象ファイルリストを参照して、番組の編成時刻に相当する時刻を示すファイル名を有するコンテンツファイルを選択する手順を含むプログラムである。
［８］の構成によれば、パッケージエントリメタデータを参照して、アプリケーションプログラムの最初に参照されるエントリポイントの所在が直ちに識別される。制作者が任意に構成したコンテンツファイルが処理対象として効率的に抽出できるので、制作者と放送事業者もしくはサービス提供者との間の相互運用性が向上する。また、時間経過に応じてコンテンツファイルが更新されるコンテンツについても、番組編成の際にファイル名により処理開始時刻と処理対象のファイルが直ちに特定される。制作者は、処理の開始やその時刻を効率的に検証することができ、放送事業者もしくはサービス提供者は、制作者が意図した処理開始時刻に基づいた番組編成を円滑に行うことができる。

本発明によれば、デジタル放送サービスで提供されるアプリケーションプログラムに関するコンテンツの相互運用性を向上することができる。

本実施形態に係る放送通信連携システムの構成を示す概略ブロック図である。 本実施形態に係るアプリケーションパッケージのデータ構造を示す図である。 コンテンツフォルダ内のコンテンツの構造の一例を示す図である。 送信対象ファイルの時間変化の一例を示す図である。 コンテンツフォルダ内のコンテンツの構造の他の例を示す図である。 送信対象ファイルの時間変化の一例を示す図である。 本実施形態に係るアプリケーション送信装置の構成を示す概略ブロック図である。 コンテンツファイル群の例を示す図である。 本実施形態に係るパッケージ読み込み処理を示すフローチャートである。 タイムコード制御対象ファイルリストの例を示す図である。 本実施形態に係るファイル制御処理を示すフローチャートである。 本実施形態に係る送信制御処理を示すフローチャートである。 本実施形態に係るアプリケーション動作検証装置の構成を示す概略ブロック図である。 各形式のアプリケーションパッケージのデータ構成の例を示す図である。 本実施形態に係るＺＩＰ−ＭＸＦ変換を示すフローチャートである。 本実施形態に係るＭＸＦ−ＺＩＰ変換を示すフローチャートである。

以下、図面を参照しながら本発明の実施形態について説明する。
図１は、本実施形態に係る放送通信連携システムＢ１の構成を示す概略ブロック図である。
本実施形態に係る放送通信連携システムＢ１は、コンテンツ管理装置１０、コンテンツ送信装置２０、アプリケーション送信装置３０、符号化装置４０、多重化装置５０、サーバ装置６０、放送設備７０、受信機８０、アプリケーション動作検証装置９０及びルータ装置１００を含んで構成される。

コンテンツ管理装置１０は、番組毎のコンテンツパッケージを記憶する記憶媒体を含んで構成される。個々のコンテンツパッケージは、番組の構成要素として１個又は複数個のマルチメディアデータを格納したファイル群である。マルチメディアデータとは、番組として放送される内容、つまり、映像、音声、字幕、アプリケーション、その他情報等のデータを示す。アプリケーションは、記述言語、例えば、ＨＴＭＬ５で記述され、記述された命令が示す処理を受信機８０に実行させることにより放送通信連携サービスを実現するプログラムであり、その実行により、番組の一部を構成するマルチメディアデータが提示される。放送通信連携サービスにより提供されるコンテンツを、特に放送通信連携コンテンツと呼ぶことがある。以下の説明では、アプリケーションその他のプログラムに記述された命令が示す処理を実行させることを、単にアプリケーションその他のプログラムを「実行する」と呼ぶことがある。コンテンツパッケージが番組の構成要素のうち、アプリケーションに係るファイルのみを含む場合には、そのコンテンツパッケージを単にアプリケーションパッケージと呼ぶことがある。コンテンツパッケージが、アプリケーションを構成するファイルに加えて、映像、音声、字幕、その他データ等を含むことを、コンテンツパッケージがアプリケーションパッケージを内包していると呼ぶことがある。コンテンツ管理装置１０は、例えば、複数のコンテンツパッケージを記憶する番組アーカイブ装置である。コンテンツ管理装置１０は、主に放送事業者、番組制作者により管理される。また、コンテンツパッケージを構成するファイル群は、例えばＭＸＦやＺＩＰなどの形式でパッケージ化されていてもよい。

コンテンツ送信装置２０は、コンテンツ読み込みトリガと、放送する番組のコンテンツパッケージ名情報が入力されるとき、パッケージ名情報で指定されるコンテンツパッケージをコンテンツ管理装置１０から取得する。コンテンツ読み込みトリガは、番組編成情報を管理する上位システムである番組編成情報管理装置（図示せず）から入力される。番組編成情報には、放送番組に係るコンテンツパッケージのパッケージ名、当該番組の編成時刻情報、その番組の放送中に実行されるアプリケーションのアプリケーション編成情報などが含まれる。コンテンツ送信装置２０は、取得したコンテンツパッケージに格納されたマルチメディアデータを読み出し、読み出したマルチメディアデータを符号化装置４０に出力する。また、コンテンツ送信装置２０は、当該コンテンツパッケージもしくは当該コンテンツパッケージに内包されたアプリケーションパッケージを読み込み、読み込んだアプリケーションパッケージをアプリケーション送信装置３０に出力する。

アプリケーション送信装置３０は、コンテンツ送信装置２０からアプリケーションパッケージを取得する。アプリケーション送信装置３０には、番組編成情報管理装置（図示せず）から直接、もしくはコンテンツ送信装置２０を経由して間接的に、パッケージ読み込みトリガとアプリケーションパッケージ名情報が入力される。アプリケーション送信装置３０は、パッケージ名情報で指定されるアプリケーションパッケージを展開してアプリケーションに係るファイル群を生成する。アプリケーション送信装置３０は、アプリケーションの動作を制御するための制御情報を生成する。制御情報には、例えば、アプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）が含まれる。ＡＩＴは、受信機８０によるアプリケーションの起動、終了などの動作の制御、放送映像の表示レイアウト変更可否等の機能の権限、アプリケーションの取得先、取得経路等を示すデータである。アプリケーション送信装置３０は、展開したアプリケーションに関するコンテンツファイル群と制御情報を多重化装置５０又はサーバ装置６０に送信する。

符号化装置４０は、コンテンツ送信装置２０から受信したマルチメディアデータを、それぞれのメディアに応じた所定の符号化方式で符号化する。映像符号化方式は、例えば、ＩＳＯ／ＩＥＣ ２３００８−２ ＨＥＶＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ／Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ ２３００８ Ｐａｒｔ２ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ、ＨＥＶＣとも呼ばれる）で規格化された符号化方式である。音声符号化方式は、例えば、ＩＳＯ／ＩＥＣ １４４９６ −３ Ａｕｄｉｏ（ＭＰＥＧ−４ オーディオとも呼ばれる）で規格化された符号化方式である。符号化装置４０は、符号化したマルチメディアデータを多重化装置５０に送信する。なお、コンテンツパッケージに格納されたマルチメディアデータが、そのまま多重化装置５０において処理可能な符号化済みのデータである場合、符号化装置４０は省略されてもよい。

多重化装置５０は、符号化装置４０から受信した符号化済みのマルチメディアデータと、アプリケーション送信装置３０から受信した制御情報及びコンテンツファイル群を多重化し、所定の形式の多重化データを生成する。多重化データは、例えば、ＭＭＴＰ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットを包含する複数のＩＰパケットからなるＩＰフローとして構成される。ＭＭＴＰパケットには、ＭＭＴパッケージテーブル（ＭＰＴ：ＭＭＴ Ｐａｃｋａｇｅ Ｔａｂｌｅ）が含まれる。ＭＰＴは、放送番組の構成要素である１個または複数個のマルチメディアデータ、つまり、映像、音声、字幕、アプリケーション、その他情報等のリストやその要件を示す制御情報である。多重化装置５０は、生成した多重化データをルータ装置１００又は放送設備７０に送信する。

サーバ装置６０は、アプリケーション送信装置３０からアプリケーションに係るコンテンツファイル群と制御情報のファイルを受信し、受信したファイルを記憶する。サーバ装置６０は、受信機８０から受信した要求情報で指定されるファイルを、その応答として通信伝送路ＮＴを介して受信機８０に送信する。
また、ルータ装置１００は、多重化装置５０から受信した多重化データを、通信伝送路ＮＴを介して受信機８０に送信する。ルータ装置１００は、通信伝送路ＮＴを介して多重化データを送信する必要がない場合には、省略されてもよい。
通信伝送路ＮＴは、サーバ装置６０もしくはルータ装置１００と受信機８０との間で各種のデータを双方向的に伝送する伝送路である。通信伝送路ＮＴは、例えば、インターネット、公衆無線通信網、等の広域通信網を含んで構成される。なお、通信伝送路ＮＴを介して各種のデータを伝送（又は送信、受信）することを、「通信で伝送（又は送信、受信）する」と呼ぶことがある。

放送設備７０は、多重化装置５０から受信した多重化データを、放送伝送路ＢＴを介して受信機８０に送信する。
放送伝送路ＢＴは、放送設備７０が送信するデータを同時に不特定多数の受信機８０に一方向的に伝送する伝送路である。放送伝送路ＢＴは、例えば、放送衛星で中継される所定の周波数帯域の電波（放送波）である。放送伝送路ＢＴには、放送設備７０から電波を送信するための送信局までのネットワークが含まれてもよい。なお、放送伝送路ＢＴを介して各種のデータを伝送（又は、送信、受信）することを、「放送で伝送（又は、送信、受信）する」と呼ぶことがある。

受信機８０は、放送伝送路ＢＴ又は通信伝送路ＮＴで伝送される多重化データと、通信伝送路ＮＴを介して受信するコンテンツファイル群に基づいて放送通信連携サービスを提供する。受信機８０は、放送伝送路ＢＴで受信した多重化データからＭＰＴを抽出し、ＭＰＴで指定されたマルチメディアデータ、制御情報及びコンテンツファイル群を受信した多重化データから抽出する。受信機８０は、ＭＰＴで指定された要件に従って当該マルチメディアデータに基づくコンテンツを提示する。また、受信機８０は、抽出した制御情報で指定された要求先のサーバ装置６０に対して、当該制御情報で指定されたアプリケーションのファイルの要求情報を、通信伝送路ＮＴを介して送信する。受信機８０は、その応答として当該アプリケーションに係るコンテンツファイル群を受信する。受信機８０は、放送伝送路ＢＴ又は通信伝送路ＮＴを介して受信したコンテンツファイル群で伝送されたアプリケーションを実行してコンテンツを提示する。受信機８０は、制御情報で表示レイアウトの変更の許可が指示されている場合には、相互にコンテンツの提示領域が重複しないように、コンテンツの表示レイアウトを変更してもよい。
従って、放送通信連係サービスにより、放送で伝送される映像、音声その他のコンテンツと、放送又は通信で伝送されるアプリケーションの実行により提供されるコンテンツにより多様な放送サービスが構成される。

アプリケーション動作検証装置９０は、制作者が制作したアプリケーションパッケージを取得し、取得したアプリケーションパッケージに配置されたアプリケーションのファイルを展開する。アプリケーション動作検証装置９０は、入力されたアプリケーション編成情報で指定された時刻において、アプリケーションを実行することにより、その動作を検証する。アプリケーション動作検証装置９０で動作検証を完了したアプリケーションに係るコンテンツファイル群を格納したアプリケーションパッケージは、番組の素材の一部として提供されることがある。

なお、図１に示す例では、受信機８０の個数は１個であるが、一般には複数個である。図１に示す例では、サーバ装置６０の個数は１個であるが、複数個であってもよい。また、放送通信連携システムＢ１の全部又は一部は、放送事業者により実施される他、他の業者により実施されてもよい。例えば、コンテンツ管理装置１０とアプリケーション動作検証装置９０は、コンテンツ制作者（以下、制作者）により実施されうる。また、アプリケーション送信装置３０とサーバ装置６０と、ルータ装置１００は、放送事業者とは別個のサービス提供者により実施されうる。受信機８０は、主に番組の視聴を目的に各家庭や事業所等に配置される。

（アプリケーションパッケージのデータ構造）
次に、本実施形態に係るアプリケーションパッケージのデータ構造（物理構造）について説明する。
図２は、本実施形態に係るアプリケーションパッケージのデータ構造を示す図である。
本実施形態に係るアプリケーションパッケージは、パッケージルートフォルダを基底フォルダとして有する。パッケージルートフォルダには、当該フォルダを特定するためのフォルダ名が付される。パッケージルートフォルダのフォルダ名として人間が識別可能な任意の名称が設定可能である。パッケージルートフォルダとして、当該フォルダ内に格納されるアプリケーションの名称、略称、別名、バージョン番号又はこれらを含む名称を有するフォルダ名が付されてもよい。パッケージルートフォルダには、パッケージエントリメタデータとコンテンツルートフォルダ、イベントメッセージフォルダ及びドキュメントフォルダが配置される。

パッケージエントリメタデータは、所定の記述言語により、アプリケーションパッケージに格納されるアプリケーションに関する情報が記述されたデータである。記述言語には、例えば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）をベースに放送通信連携コンテンツに関する情報の記述方式を定義することができる。その拡張言語仕様は、例えば、ＨＣＭＬ（Ｈｙｂｒｉｄｃａｓｔ Ｃｏｎｔｅｎｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）と呼ばれる。パッケージエントリメタデータに記述される情報は、格納されるアプリケーションの所在として、そのエントリポイント（アプリケーションエントリポイント）となるファイルのファイル名等を示すコンテンツ情報、アプリケーションパッケージの構造等を示すパッケージ情報、当該アプリケーションの伝送方式及び送信先である受信機８０における当該アプリケーションの制御等を示すトランスミッション情報を含む。

コンテンツ情報が示すアプリケーションエントリポイントのファイル名として、当該ファイルが配置されるフォルダを示すファイルパスを用いて指定されてもよい。エントリポイントとは、アプリケーションに係るファイル群のうち、アプリケーションの実行環境であるブラウザ等が最初に実行又は参照するファイルを意味する。コンテンツ情報には、当該アプリケーションのアプリケーション名、番組名、放送局名、制作者名等の属性情報が含まれてもよい。トランスミッション情報においては、伝送方式の１つの要素である伝送プロトコルとして、例えば、ＭＭＴＰ（ＭＭＴ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が指定される。伝送方式の他の要素である伝送経路として、例えば、放送伝送路ＢＴ又は通信伝送路ＮＴならびにその起点であるサーバ装置６０、ルータ装置１００のＩＰアドレス、ポート番号などが指定される。また、伝送方式の他の要素である伝送時のフォルダ階層情報として、例えば、ＭＭＴＰによる伝送に用いられるフォルダ構造もしくはＦＴＰによる転送先のフォルダ構造において、アプリケーションの起点となるフォルダ名が指定される。ＦＴＰが用いられる場合、トランスミッション情報にサーバ装置６０におけるファイルおよびフォルダのパーミッション設定に係る情報が含まれてもよい。伝送方式の指定は、アプリケーションパッケージ全体についてなされてもよいし、アプリケーションパッケージに含まれる一部のファイル群毎になされてもよいし、ファイル毎になされてもよい。アプリケーションの制御として、例えば、起動、停止、表示レイアウトの変更の許否が指定される。パッケージ情報には、コンテンツルートフォルダのフォルダ名、イベントメッセージフォルダの有無、イベントメッセージフォルダのフォルダ名、ドキュメントフォルダの有無、ドキュメントフォルダのフォルダ名、コンテンツルートフォルダに格納されるコンテンツのコンテンツ構成情報が指定されてもよい。コンテンツ構成情報として、例えば、当該コンテンツのデータが格納されるファイルのファイルパスが含まれる。それぞれのファイルパスは、各ファイルのファイル名と当該ファイルが配置されるフォルダ名を示し、ファイルパスの全体により当該コンテンツのコンテンツフォルダの階層構造が表される。これらのファイルが上述したコンテンツファイル群に相当する。パッケージエントリメタデータの名称は、所定の名称、例えば、“ｐａｃｋａｇｅ＿ｅｎｔｒｙ．ｈｃｍｌ”と予め定めておいてもよい。拡張子の“ｈｃｍｌ”は、ＨＣＭＬで記述されたメタデータファイルであることを示す。

コンテンツルートフォルダは、コンテンツファイル群が格納される基底となるフォルダである。格納されるコンテンツファイル群には、指定されるアプリケーションエントリポイントが含まれるアプリケーションのファイルと、当該ファイルに格納されたアプリケーションから参照されるコンテンツのファイル（コンテンツファイル）が含まれる。参照されるコンテンツには、アプリケーションエントリポイントとは異なる部分のアプリケーション、例えば、サブプログラムが含まれることがある。なお、アプリケーションエントリポイントのファイルは、必ずしもコンテンツルートフォルダに配置されていなくてもよく、コンテンツルートフォルダよりも下位のフォルダに配置されてもよい。図２に示す例では、アプリケーションエントリポイントのファイルは、コンテンツルートフォルダに配置され、そのファイル名は、“ｉｎｄｅｘ．ｈｔｍｌ”である。拡張子の“ｈｔｍｌ”は、ＨＴＭＬ５で当該アプリケーションが記述されていることを示す。コンテンツルートフォルダには、アプリケーションの制作者が独自に定義した物理構造を有するコンテンツファイル群が内包される。物理構造として、当該コンテンツが格納されるコンテンツファイルのそれぞれが配置されるフォルダと、それらのフォルダの階層構造が定義される。つまり、コンテンツルートフォルダに配置されるコンテンツファイル群の物理構造を、コンテンツ構成情報を用いて制作者が任意に指定可能である。コンテンツルートフォルダのフォルダ名がパッケージエントリメタデータにおいて指定されない場合には、デフォルトのフォルダ名（例えば、“ｃｏｎｔｅｎｔｓ”）が用いられてもよい。なお、以下の説明では、コンテンツルートフォルダ以下の階層のフォルダをコンテンツフォルダと呼ぶ。

イベントメッセージフォルダは、イベントメッセージの内容に係るファイルや、それらの伝送タイミングなどのイベントメッセージに関する制御情報に係るファイルが配置されるフォルダである。イベントメッセージフォルダのフォルダ名がパッケージエントリメタデータにおいて指定されない場合には、デフォルトのフォルダ名（例えば、“ｅｖｅｎｔ＿ｍｅｓｓａｇｅｓ”）が用いられてもよい。

ドキュメントフォルダは、アプリケーションの仕様書、説明文章など当該アプリケーションに関わる任意のファイル（アプリケーション本体を除く）が配置されるフォルダである。ドキュメントフォルダ内に配置されたファイルは、伝送対象にならないファイルである。ドキュメントフォルダのフォルダ名がパッケージエントリメタデータにおいて指定されない場合には、デフォルトのフォルダ名（例えば、“ｄｏｃｕｍｅｎｔｓ”）が用いられてもよい。

イベントメッセージが利用されない場合には、イベントメッセージフォルダが省略されてもよい。また、ドキュメントフォルダに配置するファイルがない場合には、ドキュメントフォルダが省略されてもよい。
また、個々のアプリケーションパッケージは、上述のデータ構造を示す単一のデータファイルとして構成されてもよい。そのようなアプリケーションパッケージのデータ形式は、例えば、ＺＩＰ形式のファイル（ＺＩＰファイル）、ＭＸＦ形式のファイル（ＭＸＦファイル）である。ＺＩＰファイル、ＭＸＦファイルは、１つ以上の個々のファイルに格納された実体データ（ファイルデータ）とメタデータを含み、所定の形式で一体に構成されたアーカイブファイルである。

（コンテンツの構造の例）
次に、コンテンツフォルダに配置されたコンテンツの構造の例について説明する。
図３は、コンテンツフォルダ内のコンテンツの構造の一例を示す図である。
図３に示す例は、放送通信連携サービスにおいて、放送時間が３０分間である番組枠に連動して編成される番組連動型コンテンツのデータが格納されるファイルの例である。これらのファイルは、コンテンツルートフォルダ内の“ｄａｔａ”フォルダに配置され、放送中においてアプリケーションの実行により参照される。図３に示す４個のファイルは、番組の進行に伴って順次差し替えの制御がなされる。ファイル名が“ｔｅｘｔ．ｊｓｏｎ”であるファイルは、番組の編成開始時刻から提供されるファイル（当初ファイル）である。当初ファイルのファイル名を以下の説明では原ファイル名と呼ぶことがある。ファイル名が“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”であるファイルは、番組開始後１２分３４秒に当初ファイルから置き換えられる差替ファイルである。差替ファイルのファイル名は、半角英数文字からなる編成タイムコード“００−１２−３４”、アンダーバー“＿”及び原ファイル名“ｔｅｘｔ．ｊｓｏｎ”、をその順序で含んで構成される。編成タイムコード“００−１２−３４”は、番組の編成開始時刻を起点として当該ファイルが置き換えられる時刻が１２分３４秒であることを示す。差替ファイルのファイル名に含まれる原ファイル名“ｔｅｘｔ．ｊｓｏｎ”により、差し替え元の当初ファイルが特定される。ファイル名が編成タイムコードを含むことにより、当該ファイル名を有するファイルが差替ファイルであることが特定される。なお、アプリケーションパッケージ内におけるファイル名にタイムコードを含む差替ファイルも、アプリケーション送信装置３０から送信される際には、タイムコードとアンダーバーを除いた原ファイル名のファイルとして送信される。

従って、アプリケーション送信装置３０は、図４に示すように、“００−００−００”以降であって“００−１２−３４”より前の編成タイムコードが指示される場合には、当初ファイル“ｔｅｘｔ．ｊｓｏｎ”を送信対象ファイルとして送信する。アプリケーション送信装置３０は、番組開始後１２分３４秒後において、送信対象ファイルを当初ファイルから、“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”のファイルに置き換える。“００−１２−３４”以降であって“００−２２−５７”より前の編成タイムコードが指示される場合には、差替ファイル“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”が送信される。アプリケーション送信装置３０は、番組開始後２２分５７秒後において、送信対象ファイルを“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”のファイルから、“００−２２−５７＿ｔｅｘｔ．ｊｓｏｎ”のファイルに置き換える。“００−２２−５７”以降であって“００−２８−１１”より前の編成タイムコードが指示される場合には、差替ファイル“００−２２−５７＿ｔｅｘｔ．ｊｓｏｎ”が送信される。アプリケーション送信装置３０は、番組開始後２８分１１秒後において、送信対象ファイルを“００−２２−５７＿ｔｅｘｔ．ｊｓｏｎ”のファイルから、“００−２８−１１＿ｔｅｘｔ．ｊｓｏｎ”のファイルに置き換える。“００−２８−１１”以降であって“００−３０−００”より前の編成タイムコードが指示される場合には、差替ファイル“００−２８−１１＿ｔｅｘｔ．ｊｓｏｎ”が送信される。

図５は、コンテンツフォルダ内のコンテンツの構造の他の例を示す図である。
図５に示す例は、放送通信連携サービスにおいて、放送時間が３０分間である番組枠に連動して編成される番組連動型コンテンツのデータを格納するファイルの他の例である。これらのファイルは、コンテンツルートフォルダ内の“ｉｍａｇｅｓ”フォルダに配置される、放送の信号によるアプリケーションからの参照の要否が制御される。図４に示す４個のファイルのうち、ファイル名が“ｌｏｇｏ．ｊｐｅｇ”であるファイルは、当初ファイルである。ファイル名が“００−０８−４３＿ｌｏｇｏ．ｊｐｅｇ”であるファイルは、当初ファイル又は差替ファイルの送信の停止を指示するファイル（送信停止ファイル）である。送信停止ファイルのファイル名は、差替ファイルと同様に、半角英数文字からなる編成タイムコード“００−０８−４３”、アンダーバー“＿”及び原ファイル名“ｌｏｇｏ．ｊｐｅｇ”をその順序で含んで構成される。但し、送信停止ファイルは、格納される実体データのデータ量（ファイルサイズ）が０バイトである空ファイルであることにより、特定される。送信停止時刻は、その編成タイムコードが示す時刻で指定される。送信を停止する停止対象ファイルとして指定される差替ファイルは、送信停止ファイルのファイル名に含まれる原ファイル名と、送信停止時刻よりも前の時刻を示すもののうち、最後の時刻を示す編成タイムコードを含むファイル名を有するファイルである。そのようなファイルが存在しない場合には、当初ファイルが送信停止ファイルとして指定される。

他方、ファイル名が“００−１５−４１＿ｌｏｇｏ．ｊｐｅｇ”であるファイルは、ファイル送信の再開を指示するファイル（送信再開ファイル）である。送信再開ファイルは、差替対象ファイルと同様に実体データを有するファイルであって、ファイル名が、半角英数文字からなる編成タイムコード“００−１５−４１”、アンダーバー“＿”及び原ファイル名“ｌｏｇｏ．ｊｐｅｇ”をその順序で含んで構成される。送信再開時刻は、その編成タイムコードが示す時刻で指定される。送信停止時刻よりも後の時刻を示す編成タイムコードを含むファイル名を有するファイルのうち、最も早い時刻を示す編成タイムコードを含むファイル名を有するファイルが送信再開ファイルと特定される。

従って、アプリケーション送信装置３０は、図６に示すように、“００−００−００”以降であって“００−０８−３４”より前の編成タイムコードが指示される場合には、当初ファイル“ｌｏｇｏ．ｊｐｅｇ”を送信する。アプリケーション送信装置３０は、番組開始後８分４３秒において、当初ファイル“ｌｏｇｏ．ｊｐｅｇ”の送信を停止する。よって、“００−０８−４３”以降であって“００−１５−４１”より前の編成タイムコードが指示される場合には、ファイルの送信が行われない。アプリケーション送信装置３０は、番組開始後１５分４１秒において、ファイル“００−１５−４１＿ｌｏｇｏ．ｊｐｅｇ”の送信を開始する。よって、“００−１５−４１”以降であって“００−２５−１６”より前の編成タイムコードが指示される場合には、送信再開ファイル“００−１５−４１＿ｌｏｇｏ．ｊｐｅｇ”が送信される。アプリケーション送信装置３０は、番組開始後２５分１６秒後において、送信再開ファイル“００−１５−４１＿ｌｏｇｏ．ｊｐｅｇ”の送信を停止する。よって、“００−２５−１６”以降の編成タイムコードが指示される場合には、ファイルの送信が行われない。
なお、当初ファイルは、編成タイムコードとして編成開始時刻を示す“００−００−００”とアンダーバー“＿”と原ファイル名（例えば、“ｔｅｘｔ．ｊｓｏｎ”）をその順序で含んで構成されるファイル名を有してもよい。また、差替ファイル、送信停止ファイルもしくは送信再開ファイルのファイル名における編成タイムコードは、例えば“００−１２−３４．２００−ｔｅｘｔ．ｊｓｏｎ”（．２００は２００ミリ秒を示す）など、より高い時刻の精度を表すものであってもよい。

（アプリケーション送信装置の構成）
次に、本実施形態に係るアプリケーション送信装置３０の構成について説明する。
図７は、本実施形態に係るアプリケーション送信装置３０の構成を示す概略ブロック図である。
アプリケーション送信装置３０は、パッケージ記憶部３１、制御部３２、外部ファイル更新部３３、一時フォルダ３４及び送信部３５を含んで構成される。アプリケーション送信装置３０は、専用の装置であってもよいし、汎用のサーバ装置において所定の送信制御プログラムに記述される命令が示す処理を実行することにより構成されてもよい。また、１または複数の機能ブロックは、複数の専用装置もしくはサーバ装置間で分散されてもよい。

パッケージ記憶部３１は、コンテンツ送信装置２０から入力されたアプリケーションパッケージを記憶する。パッケージ記憶部３１は、例えば、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ−ｄｉｓｋ Ｄｒｉｖｅ）等を含んで構成される。以下に説明する例では、アプリケーションパッケージがＺＩＰファイルとして構成されている場合を例にする。

制御部３２は、中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の制御装置（図示せず）と記憶媒体を含んで構成され、記憶媒体から読み取った所定の送信プログラムに記述される命令が示す処理を実行することにより、パッケージ展開部３２１、展開パッケージ記憶部３２２、メタデータ解析部３２３、コンテンツ構造解析部３２４、ファイル制御部３２６、制御情報生成部３２８及び送信制御部３２９として機能する。記憶媒体は、例えば、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュＲＯＭ（Ｒｅａｄ−ｏｎｌｙ Ｍｅｍｏｒｙ）、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ−ｄｉｓｋ Ｄｒｉｖｅ）等を含んで構成される。制御部３２の機能については、後述する。

外部ファイル更新部３３には、外部システム（図示せず）からの受信データに基づいてリアルタイムコンテンツを格納するコンテンツファイルを、その提供単位毎に生成する。リアルタイムコンテンツは、情報提供者により逐次（リアルタイム）に更新されるコンテンツである。リアルタイムコンテンツには、例えば、時事情報（ニュース）、気象情報、株価や為替等の相場情報等があり、放送事業者以外の情報提供者から提供される情報が含まれてもよい。外部ファイル更新部３３は、生成したコンテンツファイルを一時フォルダ３４に記憶することにより、同種のリアルタイムコンテンツのコンテンツファイルを更新する。これにより、アプリケーションの実行により参照されるリアルタイムコンテンツのコンテンツファイルが更新される。

一時フォルダ３４は、送信対象ファイルを一時的に記憶する記憶部である。一時フォルダ３４は、制御部３２で利用される記憶媒体の記憶領域とは、別個の記憶領域であってもよい。一時フォルダ３４は、外部システムから所定の伝送プロトコル（例えば、ＮＦＳ：Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ、ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ＦＴＰ、等）を用いて外部ファイル更新部３３を介してアクセス可能であってもよい。

送信部３５は、一時フォルダに記憶された各種のファイルをサーバ装置６０又は多重化装置５０に送信する。送信対象ファイル、送信時刻、送信方式等は、制御部３２により制御される。

次に、制御部３２の機能について説明する。パッケージ展開部３２１は、外部システムである番組編成情報管理装置（図示せず）からパッケージ読み込みトリガとアプリケーションパッケージ名情報が入力されるとき、アプリケーションパッケージ名情報が示すアプリケーションパッケージをパッケージ記憶部３１から読み込む。なお、アプリケーション送信装置３０は、パッケージ記憶部３１を備えずに、ネットワーク等を介して、コンテンツ管理装置１０（図１）の記憶領域から直接、もしくは、コンテンツ送信装置２０を介してパッケージを取得してもよい。アプリケーション名情報には、アプリケーションパッケージが格納されるファイルを示すファイルパスが含まれることがある。番組編成情報管理装置が管理するアプリケーション編成情報は、アプリケーションの編成時刻情報、アプリケーションパッケージ名情報を含む。編成時刻情報は、編成開始時刻、編成終了時刻など番組におけるアプリケーションの編成に関する情報を含む。番組編成情報管理装置は、少なくとも編成開始時刻よりもアプリケーション送信装置３０による処理に要する時間（処理遅延）よりも早い時刻に、アプリケーション送信装置３０にパッケージ読み込みトリガとアプリケーションパッケージ名情報のセットを出力する。パッケージ展開部３２１は、ＺＩＰファイルとして構成されたアプリケーションパッケージを展開する。展開されたアプリケーションパッケージは、上述した複数のフォルダを有し、展開により得られた個々のファイル（ローカルファイル）は、ＺＩＰファイルに含まれるローカルファイルヘッダ（後述）で指定されたフォルダに配置される。パッケージ展開部３２１は、展開したアプリケーションパッケージを展開パッケージ記憶部３２２に記憶する。パッケージ読み込み処理については、後述する。
展開パッケージ記憶部３２２は、展開されたアプリケーションパッケージを記憶する記憶部である。展開パッケージ記憶部３２２は、上述した記憶媒体の記憶領域の一部が用いられる。

メタデータ解析部３２３は、展開パッケージ記憶部３２２からパッケージエントリメタデータを読み込み、読み込んだパッケージエントリメタデータを解析する。パッケージエントリメタデータにおいてコンテンツルートフォルダのフォルダ名が指定されている場合には、メタデータ解析部３２３は、指定されたフォルダ名を有するフォルダをコンテンツルートフォルダと特定する。コンテンツルートフォルダのフォルダ名が指定されていない場合には、メタデータ解析部３２３は、デフォルトのフォルダ名“ｃｏｎｔｅｎｔｓ”を有するフォルダをコンテンツルートフォルダと特定する（図８（ａ）参照）。メタデータ解析部３２３は、パッケージエントリメタデータ内の記述を解析し、コンテンツ情報をコンテンツ構造解析部３２４に、トランスミッション情報を制御情報生成部３２８及び送信制御部３２９に出力する。

コンテンツ構造解析部３２４は、メタデータ解析部３２３から入力されたパッケージエントリメタデータに記述されたコンテンツ情報とパッケージ情報に基づいてコンテンツルートフォルダ以下の階層であるコンテンツフォルダ内のコンテンツの構造を解析する。まず、コンテンツ構造解析部３２４は、パッケージエントリメタデータのコンテンツ情報で指定されたアプリケーションエントリポイントとなるアプリケーションのファイルを送信対象ファイルとして検出する（図８（ａ）参照）。コンテンツ構造解析部３２４は、パッケージ情報を解析し、パッケージ情報を構成するファイルパスで指定されるコンテンツファイルと当該コンテンツファイルが配置されているフォルダを検出する。送信対象ファイルとして、アプリケーションエントリポイントのファイルと、そのアプリケーションの参照先、つまり、起動、取得、提示等の処理対象として指定されたコンテンツのコンテンツファイルが検出される（図８（ｂ）参照）。コンテンツ構造解析部３２４は、編成開始時刻から送信される送信対象ファイルを格納されているパッケージの構成を保ったまま一時フォルダ３４に記憶する。コンテンツ構造解析部３２４は、編成タイムコードをファイル名に含まないコンテンツファイル又は編成タイムコード“００−００−００”をファイル名に含むコンテンツファイルを編成開始時刻から送信される送信対象ファイルとして特定する。なお、コンテンツ構造解析部３２４は、アプリケーションエントリポイントとなるアプリケーションの記述を解析して、他のファイルを参照する処理の実行命令に係る記述において指定された参照先のコンテンツファイルを検出してもよい。

検出されるファイルには、編成タイムコードによる制御対象となるタイムコード制御対象ファイルが含まれることがある。コンテンツ構造解析部３２４は、ファイル名に編成タイムコードを含む差替ファイル、送信停止ファイル及び送信再開ファイルを、タイムコード制御対象ファイルとして特定する。コンテンツ構造解析部３２４は、特定したタイムコード制御対象ファイル毎に、タイムコードとファイルパスとを対応付けたセットを含むリストを生成し、タイムコードが示す時刻の早い順にこれらのセットを並び替える。並び替えによって得られたリストを、タイムコード制御対象ファイルリストと呼ぶ。コンテンツ構造解析部３２４は、生成したタイムコード制御対象ファイルリストをファイル制御部３２６に出力する。

ファイル制御部３２６には、コンテンツ構造解析部３２４からタイムコード制御対象ファイルリストと、番組編成情報管理装置（図示せず）から編成タイムコードが入力される。ファイル制御部３２６は、タイムコード制御対象パッケージに格納されたタイムコード制御対象ファイルのうち、タイムコード制御対象ファイルリストを参照し、編成タイムコードに適合したタイムコードに対応したファイル名を有するファイルを特定する。ファイル制御部３２６は、特定したファイルを送信対象ファイルと判定し、展開パッケージ記憶部３２２に記憶されたアプリケーションパッケージから抽出する。ファイル制御部３２６は、抽出したファイルを、一時フォルダ３４において抽出元のアプリケーションパッケージのフォルダに相当するフォルダの記憶領域に記憶する。図８（ｃ）に示す例では、編成タイムコードが“００−１２−３４”になると同時もしくは直後に、ファイル制御部３２６は、展開パッケージ記憶部３２２のフォルダ“ｄａｔａ”に配置されたファイル“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”を抽出する。ファイル制御部３２６は、一時フォルダ３４におけるフォルダ“ｄａｔａ”の記憶領域にある当初ファイル“ｔｅｘｔ．ｊｓｏｎ”を削除し、ファイル“００−１２−３４＿ｔｅｘｔ．ｊｓｏｎ”のファイル名を“ｔｅｘｔ．ｊｓｏｎ”と変更して一時フォルダ３４に配置する。ファイル削除とファイル配置は瞬時に行われるため、ファイルの書き換えに等しい。

特定したファイルのファイルサイズが０ｂｙｔｅ（空ファイル）である場合には、ファイル制御部３２６は当該ファイルを送信停止ファイルと判定し、判定した送信停止ファイルと同種のファイルを一時フォルダ３４から消去する。図８（ｃ）に示す例では、ファイル制御部３２６は、展開パッケージ記憶部３２２のフォルダ“ｉｍａｇｅｓ”に配置されたファイル“００−１５−４１＿ｌｏｇｏ．ｊｓｏｎ”のファイルサイズが０ｂｙｔｅであることを特定する。ファイル制御部３２６は、当該ファイルが送信停止ファイルと判別する。ファイル制御部３２６は、同種のファイルとして送信停止ファイルが配置されているフォルダ“ｉｍａｇｅｓ”に相当する一時フォルダ３４のフォルダ“ｉｍａｇｅｓ”の記憶領域に記憶されていた原ファイル名が共通であるファイル“ｌｏｇｏ．ｊｐｅｇ”を検出する。ファイル制御部３２６は、検出したファイルを消去することにより、送信対象ファイルを更新する。ファイル制御部３２６によるファイル制御処理については後述する。

制御情報生成部３２８は、一時フォルダ３４における送信対象ファイルの記憶状態およびメタデータ解析部３２３から入力されたパッケージエントリメタデータが示すトランスミッション情報に基づいて、送信対象ファイルから構成されるアプリケーションに関する制御情報を生成する。トランスミッション情報が、一部のファイル群又はファイル毎に定められている場合には、制御情報生成部３２８は、トランスミッション情報のうち当該送信対象ファイルに関する部分の情報を含む制御情報を生成する。制御情報として、トランスミッション情報が示す、起動、終了などの動作の制御、放送映像の表示レイアウト変更可否等の機能の権限等の情報が含まれる。また、伝送経路として通信伝送路ＮＴが指定され、かつ伝送プロトコルとしてＦＴＰが指定される場合には、サーバ装置６０のＩＰアドレスが受信機８０からの取得先として制御情報に含まれる。なお、制御情報生成部３２８は、トランスミッション情報において指定された伝送方式に応じた形式の制御情報を生成する。例えば、ＭＭＴＰが指定される場合、制御情報生成部３２８は、制御情報として非特許文献４に記載のＭＨ−アプリケーション情報テーブル（ＭＨ−ＡＩＴ）、データディレクトリ管理テーブル、データアセット管理テーブル及びデータコンテント管理テーブル等を生成する。ＦＴＰが指定される場合、制御情報生成部３２８は、制御情報としてファイル形式のＡＩＴ等を生成する。制御情報生成部３２８は、生成した制御情報を送信制御部３２９に出力する。

送信制御部３２９は、メタデータ解析部３２３から入力されたパッケージエントリメタデータが示すトランスミッション情報を参照して、一時フォルダ３４に記憶された送信対象ファイルの伝送方式を特定する。送信制御部３２９は、当該ファイルと、制御情報生成部３２８から入力された制御情報を送信部３５に出力し、出力したファイルと制御情報を特定した伝送方式を用いて送信させる。送信制御部３２９による送信制御処理については後述する。

（パッケージ読み込み処理）
次に、本実施形態に係るパッケージ読み込み処理について説明する。
図９は、本実施形態に係るパッケージ読み込み処理を示すフローチャートである。
（ステップＳ１０１）パッケージ展開部３２１は、番組編成情報管理装置（図示せず）からパッケージ読み込みトリガ入力の有無を判定する。あると判定されるとき（ステップＳ１０１ ＹＥＳ）、ステップＳ１０２に進む。ないと判定されるとき（ステップＳ１０１ ＮＯ）、ステップＳ１０１の処理を繰り返す（待ち受け）。
（ステップＳ１０２）パッケージ展開部３２１は、入力されたアプリケーションパッケージ名情報で指定されたアプリケーションパッケージ名情報が示すアプリケーションパッケージをパッケージ記憶部３１から読み込む。パッケージ展開部３２１は、ＺＩＰファイルとして構成されたアプリケーションパッケージを展開し、展開したアプリケーションパッケージを展開パッケージ記憶部３２２に記憶する。その後、ステップＳ１０３に進む。

（ステップＳ１０３）メタデータ解析部３２３は、展開パッケージ記憶部３２２からパッケージエントリメタデータを読み込む。メタデータ解析部３２３は、読み込んだパッケージエントリメタデータを解析し、コンテンツのファイル群が格納されたコンテンツフォルダを特定する。その後、ステップＳ１０４に進む。

（ステップＳ１０４）コンテンツ構造解析部３２４は、パッケージエントリメタデータに記述されたコンテンツ情報とパッケージ情報に基づいてコンテンツフォルダ内のコンテンツの構造を解析し送信対象ファイルと、タイムコード制御対象ファイルを検出する。コンテンツ構造解析部３２４は、編成開始時刻（タイムコード“００−００−００”）からの送信対象ファイルを一時フォルダ３４に記憶する。その後、ステップＳ１０５に進む。

（ステップＳ１０５）コンテンツ構造解析部３２４は、検出したタイムコード制御対象ファイル毎のタイムコードとファイルパスとのセットを、そのタイムコードが示す時刻の順に配列したタイムコード制御対象ファイルリストを生成する。コンテンツ構造解析部３２４は、生成したタイムコード制御対象ファイルリストをファイル制御部３２６に出力する。

図１０は、タイムコード制御対象ファイルリストの例を示す図である。
図１０に示すタイムコード制御対象ファイルリストは、図３、５に示すコンテンツのファイルがアプリケーションパッケージに配置されている場合を例にして、生成されたファイルリストである。このタイムコード制御対象ファイルリストには、２種類の当初ファイル“ｌｏｇｏ．ｊｐｅｇ”、“ｔｅｘｔ．ｊｓｏｎ”に関連するタイムコード制御対象ファイルに関する情報のセットを各３件含む。例えば、第２行に示すセットは、番号“１”、タイムコード“００−０８−４３”及び“ファイルパスｃｏｎｔｅｎｔｓ／ｉｍａｇｅｓ／００−０８−４３＿ｌｏｇｏ．ｊｐｅｇ”からなる。タイムコード“００−０８−４３”は、タイムコード制御に係る時刻が編成開始時刻から８分４３秒後であることを示す。ファイル“００−０８−４３＿ｌｏｇｏ．ｊｐｅｇ”は送信停止ファイルであるので、この時刻は直前の順序の同種のファイル（この場合、当初ファイル“ｌｏｇｏ．ｊｐｅｇ”）の送信停止時刻を示す。ファイルパス“ｃｏｎｔｅｎｔｓ／ｉｍａｇｅｓ／００−０８−４３＿ｌｏｇｏ．ｊｐｅｇ”は、配置されるフォルダが“ｃｏｎｔｅｎｔｓ／ｉｍａｇｅｓ／”であり、ファイル名が“００−０８−４３＿ｌｏｇｏ．ｊｐｅｇ”であることを示す。タイムコード制御対象ファイルリストは、タイムコードとファイルパスの他に、ファイルサイズやファイル操作種別等を要素として含んでもよい。

（ファイル制御処理）
次に、本実施形態に係るファイル制御処理について説明する。
図１１は、本実施形態に係るファイル制御処理を示すフローチャートである。
（ステップＳ１１１）制御部３２は、編成開始時にファイル制御部３２６の機能を実行するスレッドを起動することにより、ファイル制御処理を開始する。その後、ステップＳ１１２に進む。
（ステップＳ１１２）ファイル制御部３２６は、番組編成情報管理装置（図示せず）から入力される編成タイムコードを参照し、パッケージエントリメタデータに含まれるコンテンツ情報が示す番組の継続時間と比較して、編成終了か否かを判定する。編成タイムコードが示す時刻が継続時間以上であるとき、ファイル制御部３２６は編成終了と判定する。編成タイムコードが示す時刻が継続時間未満であるとき、ファイル制御部３２６は編成中と判定する。その後、ステップＳ１１３に進む。

（ステップＳ１１３）ファイル制御部３２６が編成終了と判定する場合（ステップＳ１１３ ＹＥＳ）、ステップＳ１１７に進む。ファイル制御部３２６が編成中と判定する場合（ステップＳ１１３ ＮＯ）、ステップＳ１１４に進む。
（ステップＳ１１４）ファイル制御部３２６は、タイムコード制御対象ファイルリストにおける先頭の項目（未処理のタイムコード制御対象ファイルのうち最先の項目）のタイムコードの値と、編成タイムコードの値とを比較する。その後、ステップＳ１１５に進む。
（ステップＳ１１５）編成タイムコードの値の方が小さいと判定されたとき（ステップＳ１１５ ＹＥＳ）、ステップＳ１１２に戻る。編成タイムコードの値が、タイムコード制御対象ファイルリストのタイムコードの値と等しいか、より大きいと判定されたとき（ステップＳ１１５ ＮＯ）、ステップＳ１１６に進む。

（ステップＳ１１６）ファイル制御部３２６は、一時フォルダ３４に記憶されたタイムコード制御対象パッケージから当該ファイルを送信対象ファイルとして抽出する。ファイル制御部３２６は、抽出したファイルを一時フォルダ３４の送信対象ファイル領域に記憶されている同種のファイルを抽出したファイルに置き換え、その同種のファイルを削除する。但し、抽出したファイルが送信停止ファイル（ファイルサイズが０バイト）である場合には、ファイル制御部３２６は、当該ファイルを送信停止ファイルと判定する。そして、ファイル制御部３２６は、当該ファイルについて置き換えを行わず、一時フォルダ３４に記憶されている同種のファイルを削除する。その後、ファイル制御部３２６は、ファイル制御部３２６は、タイムコード制御対象ファイルリストの先頭の項目に記述された情報を削除し、その後、ステップＳ１１２に戻る。

なお、ファイル制御部３２６は、抽出した送信対象ファイルのファイル名を、編成タイムコードとアンダーバーが除去された原ファイル名に置き換え、ファイル名を置き換えた送信対象ファイルを一時フォルダ３４に記憶してもよい。これにより、受信機８０は、アプリケーションにおいて指定された参照先のファイル名を変更せずに、置き換えられた送信対象ファイルを参照することができる。

（送信制御処理）
次に、本実施形態に係る送信制御処理について説明する。
図１２は、本実施形態に係る送信制御処理を示すフローチャートである。
（ステップＳ１２１）制御部３２は、送信プログラムの実行開始時において送信制御部３２９の機能を実行するスレッドを起動することにより、送信制御処理を開始する。その後、ステップＳ１２２に進む。
（ステップＳ１２２）送信制御部３２９は、番組編成情報管理装置（図示せず）から送信開始トリガが入力されたか否かを判定する。入力されたと判定する場合（ステップＳ１２２ ＹＥＳ）、ステップＳ１２３に進む。入力されないと判定する場合（ステップＳ１２２ ＮＯ）、ステップＳ１２２の処理を繰り返す（待ち受け）。
（ステップＳ１２３）送信制御部３２９は、一時フォルダ３４に記憶された送信対象ファイルを送信部３５に出力することにより、パッケージエントリメタデータに含まれるトランスミッション情報で指定された伝送方式を用いて送信させる。送信制御部３２９は、制御情報生成部３２８から入力された制御情報についても同様に、送信部３５に送信させる。
その後、ステップＳ１２４に進む。
（ステップＳ１２４）送信制御部３２９は、番組編成情報管理装置（図示せず）から送信終了トリガが入力されたか否かを判定する。入力されたと判定された場合（ステップＳ１２４ ＹＥＳ）、ステップＳ１２２に戻る（待ち受け）。入力されないと判定された場合（ステップＳ１２４ ＮＯ）、ステップＳ１２３に戻る（送信継続）。

なお、トランスミッション情報において伝送プロトコルとしてＭＭＴＰが指定される場合（ファイル送信）、送信制御部３２９は送信部３５に対して直接の送信先として多重化装置５０（図１）を指定し、送信先が多重化装置５０と指定された送信対象ファイル（コンテンツファイル群）と制御情報を送信部３５に送信させる。送信制御部３２９は、多重化装置５０に送信させた送信対象ファイルと制御情報を、指定された伝送方式で多重化装置５０に送信させる。多重化装置５０は、アプリケーション送信装置３０から受信した送信対象ファイル、制御情報及び符号化装置４０から受信したマルチメディアデータを多重化して得られた多重化データを生成する。多重化装置５０は、生成した多重化データを細分化し、細分化されたデータを格納したＭＭＴＰパケットを生成する。多重化装置５０は、生成したＭＭＴＰパケットを格納した一連のＩＰパケットからなるＩＰフローを生成する。多重化装置５０は、生成したＩＰフローをアプリケーション送信装置３０から指定された伝送経路に応じた送信先に送信する。伝送経路として通信伝送路ＮＴが指定された場合には、多重化装置５０は、ＩＰフローをルータ装置１００（図１）に送信する。伝送経路として放送伝送路ＢＴが指定された場合には、多重化装置５０は、ＩＰフローを放送設備７０（図１）に送信する。ルータ装置１００に送信されたＩＰフローは、通信伝送路ＮＴを介して受信機８０（図１）に伝送される。放送設備７０に送信されたＩＰフローは、放送伝送路ＢＴを介して受信機８０に伝送される。受信機８０は、伝送されたＩＰフローから送信対象ファイルの全体を取得できるように、送信制御部３２９は、送信対象ファイルを所定期間毎に繰り返し送信させる。また、アプリケーションを構成するファイル群を番組編成時刻から送信開始する場合、受信機８０が全てのファイルを受信し、アプリケーションが実行可能になるまでの遅延が生じる。このため、受信機８０において番組開始時刻と同時にアプリケーションを実行できるようにするため、番組編成時刻よりも早い時刻において送信制御部３２９に送信開始トリガを与え、ファイル群の送信を開始させてもよい。

ファイル制御部３２６により一時フォルダ３４に記憶された送信対象ファイルが更新されてから、送信制御部３２９により更新後の送信対象ファイルが送信されるまでに遅延が生じることがある。例えば、一時フォルダ３４内のすべてのファイルを一回ずつ送信するのに５秒を要する場合、更新後のファイルの送信が終了するまでに、最大で５秒の遅延が生じる可能性がある。そこで、ファイル制御部３２６は、タイムコード制御対象ファイルを一時フォルダ３４に記憶するとき、送信対象ファイルが当該タイムコード制御対象ファイルに更新されたことを示すファイル更新情報を送信制御部３２９に出力してもよい。これにより、送信制御部３２９は、ファイル制御部３２６から入力されたファイル更新情報が示す更新後のタイムコード制御対象ファイルを優先して送信させ、受信機８０（図１）において実行中のアプリケーションにファイルの更新が反映されるまでの遅延を低減することができる。なお、トランスミッション情報において、ＩＰフローの伝送方式としてＭＭＴＰ以外の伝送プロトコルが指定されてもよい。また、トランスミッション情報において、送信対象ファイルが格納されるデータ形式としてＩＰフロー以外のデータ形式、例えば、ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）が指定されてもよい。なお、アプリケーション送信装置３０と多重化装置５０との間における伝送方式として、異なる階層の伝送方式が利用可能である。一例として、アプリケーション送信装置３０の送信制御部３２９がファイルの細分化とＭＭＴＰパケットの生成を行い、多重化装置５０が制御情報の再構成とＩＰフローの多重化を行ってもよい。

トランスミッション情報において、伝送プロトコルとしてＦＴＰが指定される場合（ファイル転送）、送信制御部３２９は送信部３５に対して出力先としてサーバ装置６０（図１）を指定する。ＦＴＰの指定により、伝送経路として、通信伝送路ＮＴが指定される。サーバ装置６０は、アプリケーション送信装置３０から受信した送信対象ファイル（コンテンツファイル群）のうち受信機８０（図１）からの要求情報で指定されるファイルを、その応答として通信伝送路ＮＴを介して受信機８０に送信する。そのため、サーバ装置６０は、番組の編成開始時刻よりも前にアプリケーション送信装置３０からの送信対象ファイルの受信が完了している必要がある。そこで、送信制御部３２９は、編成開始時刻よりも少なくとも送信開始から送信完了までの送信時間（ファイル転送時間）だけ早い時刻に送信対象ファイルの送信を開始させてもよい。なお、送信制御部３２９は、ファイル制御部３２６により一時フォルダ３４に記憶させた送信対象ファイルの削除に応じて、送信部３５に対してサーバ装置６０に送信した送信対象ファイルの削除を指示するＦＴＰコマンドを送信させてもよい。また、送信制御部３２９は、ファイル制御部３２６により一時フォルダ３４に記憶させた送信対象ファイルの更新に応じて、送信部３５に対してサーバ装置６０に当該送信対象ファイルの更新を指示するＦＴＰコマンドを送信させてもよい。ＦＴＰコマンドの送信タイミングは、ファイル制御部３２６に入力される編成タイムコードが示す時刻よりも少なくともファイル転送時間だけ早い時刻であってもよい。なお、トランスミッション情報において、送信先としてサーバ装置６０が指定される場合であっても、伝送プロトコルとしてＦＴＰ以外の伝送プロトコルが指定されてもよい。

複数のアプリケーションパッケージにおいて、それぞれ異なる伝送方式がトランスミッション情報において指定されている場合には、送信制御部３２９は、それぞれ指定された伝送方式を用いて並列に送信対象ファイルを送信させてもよい。また、トランスミッション情報においてファイル群毎に伝送方式が指定されている場合には、送信制御部３２９は、送信対象ファイルが属するファイル群の伝送方式を用いて当該送信対象ファイルを送信させてもよい。また、トランスミッション情報において、ファイル毎に伝送方式が指定されている場合には、送信制御部３２９は、送信対象ファイルに係る伝送方式を用いて当該送信対象ファイルを送信させてもよい。なお、トランスミッション情報において伝送プロトコルとしてＭＭＴＰが指定されているとき、ＩＰフローへの多重周期が指定可能であってもよく、多重周期は、ファイルに格納される情報の重要性、緊急性等に応じて、可変であってもよい。多重周期が指定されている場合には、送信制御部３２９は、指定された多重周期で送信対象ファイルのデータを多重化装置５０に多重化させることによりＩＰフローを生成させる。

なお、パッケージ展開部３２１は、パッケージ読み込みトリガとアプリケーションパッケージ名情報のセットが複数セット入力されるとき、それぞれのアプリケーションパッケージ名情報で指定されるアプリケーションパッケージを読み込む。制御部３２は、読み込んだ複数のアプリケーションパッケージについて、それぞれ上記の処理を並列に行い、それぞれの番組に係るコンテンツファイル群を送信してもよい。
また、ファイル制御部３２６、送信制御部３２９は、制御部３２の他の構成とは別個のプログラムの実行により、その機能を実現してもよい。また、外部ファイル更新部３３の機能を実現するために、制御部３２と同一のプログラムの実行により実現してもよいし、異なるプログラムの実行により実現してもよい。

（アプリケーション動作検証装置の構成）
次に、本実施形態に係るアプリケーション動作検証装置９０の構成について説明する。アプリケーション送信装置３０（図７）と同一の構成については、同一の符号を付してその説明を援用する。
図１３は、本実施形態に係るアプリケーション動作検証装置９０の構成を示す概略ブロック図である。
アプリケーション動作検証装置９０は、パッケージ記憶部３１、一時フォルダ３４、制御部９２及び実行部９３を含んで構成される。アプリケーション動作検証装置９０は、専用の装置であってもよい。また、アプリケーション動作検証装置９０は、汎用のサーバ装置又はパーソナルコンピュータに所定のアプリケーション動作検証プログラムに記述される命令が示す処理を実行させることにより構成されてもよい。

制御部９２は、ＣＰＵ等の制御装置（図示せず）と記憶媒体を含んで構成され、記憶媒体から読み取った所定のアプリケーション動作検証プログラムに記述される命令が示す処理を実行することにより、パッケージ展開部３２１、展開パッケージ記憶部３２２、メタデータ解析部３２３、コンテンツ構造解析部３２４及びファイル制御部３２６として機能する。制御部９２の構成は、アプリケーション送信装置３０の制御部３２（図７）において制御情報生成部３２８及び送信制御部３２９が省略された構成に相当する。このことは、アプリケーション動作検証装置９０がファイルの送信を要しないためである。従って、制御部９２は、パッケージ記憶部３１から読み取ったアプリケーションパッケージから送信対象ファイルに代えて検証対象ファイルを特定し、特定した検証対象ファイルを一時フォルダ３４に記憶する。また、制御部９２は、当該アプリケーションパッケージから、編成タイムコードに適合したタイムコードをファイル名に含むタイムコード制御対象ファイルを、一時フォルダ３４の検証対象ファイル領域に検証対象ファイルとして記憶する。これらの検証対象ファイルは、ファイル制御部３２６に入力される編成タイムコードで指定される時刻において受信機８０（図１）に送信されるコンテンツファイルに相当する。

実行部９３には、ユーザからの操作入力による操作信号が入力され、入力された操作信号で指定されるアプリケーションエントリポイントのファイルを特定し、特定したファイルを一時フォルダ３４から読み込む。実行部９３は、読み込んだファイルに格納されたアプリケーションに記述された命令が示す処理を実行する。実行部９３は、記述されたアプリケーションを解析し、参照先として指定された他のコンテンツファイルを一時フォルダ３４から読み込む。実行部９３は、処理の実行により読み込んだコンテンツファイルに格納されたコンテンツの提示を制御する。従って、アプリケーションエントリポイントのファイルへアクセスすることにより、編成タイムコードが示す時刻を指定した動作検証が可能になる。実行部９３は、アプリケーション動作検証プログラムとは別個のプログラム、例えば、ウェブブラウザを実行することにより実現されてもよい。

（相互変換）
上述した説明では、アプリケーション送信装置３０、アプリケーション動作検証装置９０のパッケージ展開部３２１（図７、１３）がＺＩＰ形式のアプリケーションパッケージを展開する場合を例にしたが、これには限られない。アプリケーション送信装置３０、アプリケーション動作検証装置９０は、それぞれＭＸＦ形式のアプリケーションパッケージを読み込み、読み込んだＭＸＦ形式のアプリケーションパッケージについて形式変換を行ってＺＩＰ形式のアプリケーションパッケージを生成する第１変換部（図示せず）を備えてもよい。また、アプリケーション動作検証装置９０は、ＺＩＰ形式のアプリケーションパッケージについて形式変換を行ってＭＸＦ形式のアプリケーションパッケージを生成する第２変換部（図示せず）を備えてもよい。以下の説明では、これらの変換部を、単に変換部と総称する。また、ＺＩＰファイルからＭＸＦファイルへの形式変換をＺＩＰ−ＭＸＦ変換と呼び、ＭＸＦファイルからＺＩＰファイルへの形式変換をＭＸＦ−ＺＩＰ変換と呼ぶ。また、図１のコンテンツ管理装置１０に記憶されるアプリケーションに係るファイルとは別個の映像、音声等のマルチメディアデータを含むコンテンツパッケージのデータ形式がＭＸＦ形式である場合、コンテンツ管理装置１０の出力部もしくはコンテンツ送信装置２０がコンテンツパッケージについてＭＸＦ−ＺＩＰ変換を行ってもよい。その場合には、アプリケーション送信装置３０にはＭＸＦ−ＺＩＰ変換によって得られたＺＩＰ形式のアプリケーションパッケージが入力される。

次に、各形式のアプリケーションパッケージのデータ構成について説明する。
図１４は、各形式のアプリケーションパッケージのデータ構成の例を示す図である。
図１４の上段は、ＺＩＰファイルとして構成されたアプリケーションパッケージの構成の一例を示す。ＺＩＰファイルは、ローカルファイルヘッダとファイルデータ（ファイルエントリ）等からなる複数個のセット、複数個のセントラルディレクトリヘッダ、エンドオブセントラルディレクトリレコードをその順序で含んで構成されるファイルである。ローカルファイルヘッダは、アプリケーションパッケージに配置される個々のファイル（ローカルファイル）に当該ファイルに関する情報、例えば、ファイルサイズ、ファイルパスを示すデータである。ローカルファイルは、アプリケーションのファイル、アプリケーションから参照される各種のコンテンツのファイル、パッケージエントリメタデータ、イベントメッセージに関するファイル、ドキュメントフォルダに配置される各種のファイルが該当する。ローカルファイルヘッダにより、個々のローカルファイルのファイルデータ（実体データ）が区分される。ローカルファイルヘッダに後続する領域に、当該ローカルファイルのファイルデータが格納される。各セントラルディレクトリヘッダは、それぞれのローカルファイルの圧縮方式、圧縮前後のファイルサイズ、ＺＩＰファイル全体において当該ローカルファイルが格納される位置などの情報を示すデータである。エンドオブセントラルディレクトリレコードは、ＺＩＰファイルの終端を示すデータである。この構成により、ＺＩＰファイルには、パッケージルートフォルダ以下のフォルダ間の階層構造、各フォルダに配置されるローカルファイルをそれぞれ示すデータが一括して格納される。そのため、ＺＩＰファイルは、パッケージルートフォルダを起点として、コンテンツファイルの構成フォルダの物理構造と、それぞれのフォルダに配置される個々のローカルファイルに展開することができる。各ローカルファイルに付随する情報として、ローカルファイルヘッダに後続する領域と、ファイルデータに後続する領域の一方又は両方に他のデータ構造が含まれていてもよい。また、先頭のセントラルディレクトリヘッダの前の領域と、最後尾のセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコードとの間の領域の一方又は両方に、他のデータ構造が含まれていてもよい。

図１４の下段は、ＭＸＦファイルとして構成されたアプリケーションパッケージの構成の一例を示す。ＭＸＦファイルは、コンテンツの制作、管理においてしばしば用いられるデータ形式を有するファイルである。ＭＸＦファイルにおいて、ＺＩＰファイルを構成する各ローカルファイルのローカルヘッダとファイルデータのセットを、その順序で含む所定のデータ配列（Ｇｅｎｅｒｉｃ Ｓｔｒｅａｍ Ｐａｒｔｉｔｉｏｎ）に格納される。ＭＸＦファイルは、Ｋｅｙ、Ｌｅｎｇｔｈ及びＶａｌｕｅ領域をその順序で含み、さらにＶａｌｕｅ領域に複数のＫＬＶ構造を内包して構成されるファイルである。複数のＫＬＶ構造からなるデータ配列は、Ｇｅｎｅｒｉｃ Ｓｔｒｅａｍと呼ばれる。図１４の下段における先頭のＫｅｙは、当該ＭＸＦファイルがアプリケーションパッケージのＧｅｎｅｒｉｃ Ｓｔｒｅａｍを有することを示す値（アプリケーションパッケージ識別値）が設定される。後続するＬｅｎｇｔｈには、後続する複数のＫＬＶ構造全体のデータサイズを示す値が設定される。アプリケーションパッケージ識別値を持つＫＬＶ構造のＶａｌｕｅ領域に内包される個々のＫＬＶ構造は、Ｋｅｙ、Ｌｅｎｇｔｈ及びＶａｌｕｅをその順序で含み、Ｖａｌｕｅ領域に種々のデータを格納して構成されるデータ構造である。冒頭から末尾の直前までのＫＬＶ構造のＫｅｙには、アプリケーションパッケージを構成するローカルファイルが格納されていることを示す値（ローカルファイル識別値）が設定される。Ｌｅｎｇｔｈには、後続するＶａｌｕｅ領域に格納されるデータのデータサイズを示す値（データサイズ値）が設定される。Ｖａｌｕｅ領域は、個々のローカルファイルのローカルファイルヘッダと当該ローカルファイルのファイルデータが格納されるデータ領域である。ファイルデータに付随する情報として、ローカルファイルヘッダとは別個のデータ構造を含む場合には、そのデータ構造も同一のＶａｌuｅ領域に併せて格納される。即ち、ＫｅｙとＬｅｎｇｔｈは、それらの挿入により、個々のローカルファイルヘッダとファイルデータのセットが区分される区分データである。ＺＩＰファイルに格納される個々のローカルファイルのローカルファイルヘッダが、そのローカルファイルに関する情報（プロパティ記述）として利用可能である。

アプリケーションパッケージに係るＭＸＦファイルの末尾のＫＬＶ構造のＫｅｙには、各ローカルファイルのセントラルディレクトリヘッダが格納されることを示す値（セントラルディレクトリレコード識別値）が設定される。Ｌｅｎｇｔｈには、後続するＶａｌｕｅに格納されるＶａｌｕｅに格納されるデータのデータサイズ値が設定される。Ｖａｌｕｅは、各ローカルファイルに係るセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコードをその順序で格納されるデータ領域である。なお、冒頭のセントラルディレクトリヘッダの前の領域、最後尾のセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコードとの間の領域の一方又は両方に、他のデータ構造が含まれていてもよい。従って、末尾のＫＬＶ構造には、ＺＩＰファイルに格納される個々のセントラルディレクトリヘッダで構成されるファイルインデックスが、そのままアプリケーションのコンテンツファイル群のインデックス情報として格納される。ＭＸＦファイルにおいて、アプリケーションパッケージ識別値を有するＧｅｎｅｒｉｃ Ｓｔｒｅａｍが内包するＫＬＶ構造の数は、格納されるローカルファイルの数よりも１個多い。このようなデータ構造により、後述するＺＩＰファイルとＭＸＦファイル相互間の形式変換が簡素になる。また、上記のアプリケーションパッケージに係るＭＸＦファイルの構造を、映像、音声など他のマルチメディアデータを格納したＭＸＦファイルの構造と結合した、番組コンテンツをまとめたコンテンツパッケージとして構成されてもよい。

（形式変換）
次に、形式変換について説明する。ＺＩＰ−ＭＸＦ変換では、変換部は、ＺＩＰファイルに含まれるローカルファイル毎のローカルファイルヘッダとファイルデータ等のセットを格納したＫＬＶ構造を順次連結することにより、ＭＸＦファイルを生成する。具体的には、変換部は図１５に示す処理を行う。

図１５は、本実施形態に係るＺＩＰ−ＭＸＦ変換を示すフローチャートである。
（ステップＳ１３１）変換部は、記憶媒体に記憶されたＺＩＰファイルに含まれる個々のローカルファイルのローカルファイルヘッダとファイルデータのセットをそれぞれ抽出する。さらにローカルファイルに係るデータ構造がファイルデータの前後に存在する場合には、変換部は、それらもまとめて抽出する。その後、ステップＳ１３２に進む。
（ステップＳ１３２）変換部は、抽出したセット毎に、ローカルファイル識別値が設定されたＫｅｙと、当該セットのデータサイズ値が設定されたＬｅｎｇｔｈと、当該セットのローカルファイルヘッダとファイルデータ等を格納したＶａｌｕｅ領域とを連結し、ＫＬＶ構造を生成する。その後、ステップＳ１３３に進む。

（ステップＳ１３３）変換部は、当該ＺＩＰファイルに含まれる個々のローカルファイルのセントラルディレクトリヘッダとエンドオブディレクトリレコードを抽出する。冒頭のセントラルディレクトリヘッダの前の領域と、最後尾のセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコードとの間の領域の一方又は両方に、特定のローカルファイルに限定されない情報を持つ他のデータ構造が含まれている場合には、変換部は、それらもまとめて抽出する。その後、ステップＳ１３４に進む。
（ステップＳ１３４）変換部は、セントラルディレクトリレコード識別値が設定されたＫｅｙと、抽出したセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコード等の全体のデータサイズが設定されたＬｅｎｇｔｈと、抽出したセントラルディレクトリヘッダとエンドオブセントラルディレクトリレコード等を格納したＶａｌｕｅ領域とを連結し、ＫＬＶ構造を生成する。その後、ステップＳ１３５に進む。

（ステップＳ１３５）変換部は、アプリケーションパッケージ識別値が設定されたＫｅｙと、ステップＳ１３２、Ｓ１３４において生成されたＫＬＶ構造全体のデータサイズが設定されたＬｅｎｇｔｈと、ステップＳ１３２、Ｓ１３４において生成されたＫＬＶ構造を連結してＧｅｎｅｒｉｃ Ｓｔｒｅａｍを生成し、ＭＸＦファイルを出力する。変換部は、出力したＭＸＦファイルを記憶媒体に記憶する。この際、変換部は、必要に応じて、別途生成された映像、音声等、他のマルチメディアデータを格納したＭＸＦファイルと結合し、コンテンツパッケージを構成してもよい。その後、図１５に示す処理を終了する。

ＭＸＦ−ＺＩＰ変換では、変換部は、ＭＸＦファイルに含まれるローカルファイル毎のＫＬＶ構造を区分するＫｅｙとＬｅｎｇｔｈを除外し、Ｖａｌｕｅ領域に格納されたローカルファイルヘッダとファイルデータ等のセットを順次連結することにより、ＺＩＰファイルを生成する。具体的には、変換部は図１６に示す処理を行う。

図１６は、本実施形態に係るＭＸＦ−ＺＩＰ変換を示すフローチャートである。
（ステップＳ１４１）変換部は、記憶媒体に記憶されたアプリケーションパッケージのＭＸＦファイルもしくはアプリケーションパッケージを内包するコンテンツパッケージのＭＸＦファイルを読み込み、Ｋｅｙの設定値に基づきアプリケーションパッケージが格納されていること、及びその格納位置を判別し、後続するＬｅｎｇｔｈに基づいてＭＸＦファイルのうちアプリケーションパッケージに係るＫＬＶ構造を内包するＶａｌｕｅ領域のデータサイズを判定する。その後、ステップＳ１４２に進む。

（ステップＳ１４２）変換部は、アプリケーションパッケージ識別値を持つＫＬＶ構造のＶａｌｕｅ領域に内包されるＫＶＬ構造のうち、冒頭から末尾の直前までのＫＬＶ構造のそれぞれについて、冒頭のＫｅｙの設定値に基づきローカルファイルが格納されていることを判別する。変換部は、後続するＬｅｎｇｔｈに基づいてさらに後続するＶａｌｕｅ領域に格納されたデータのデータサイズを判定する。変換部は、ローカルファイルヘッダとファイルデータ等が格納されたＶａｌｕｅ領域を抽出する。その後、ステップＳ１４３に進む。
（ステップＳ１４３）変換部は、アプリケーションパッケージ識別値を有するＫＬＶ構造のＶａｌｕｅ領域に内包されるＫＶＬ構造のうち、末尾のＫＬＶ構造について、その冒頭のＫｅｙの設定値に基づきセントラルディレクトリレコードが格納されることを判別する。変換部は、後続するＬｅｎｇｔｈに基づいてさらに後続するＶａｌｕｅ領域に格納されたデータのデータサイズを判定する。変換部は、セントラルディレクトリヘッダとエンドオブセントラルディレクトリレコード等が格納されたＶａｌｕｅ領域を抽出する。その後、ステップＳ１４４に進む。

（ステップＳ１４４）変換部は、ステップＳ１１２で抽出したＶａｌｕｅ領域を順次連結し、ステップＳ１４３で抽出したＶａｌｕｅ領域をさらに連結してＺＩＰファイルを生成する。その後、図１６に示す処理を終了する。

以上に説明したように、本実施形態に係るアプリケーション送信装置３０及びアプリケーション動作検証装置９０は、それぞれメタデータ解析部３２３及びコンテンツ構造解析部３２４を備える。メタデータ解析部３２３は、アプリケーションパッケージから、パッケージエントリポイントメタデータを解析してアプリケーションプログラムを特定する。アプリケーションパッケージには、デジタル放送サービスのアプリケーションプログラムに関するコンテンツファイルが配置されたコンテンツルートフォルダと、アプリケーションプログラムのエントリポイントを示すコンテンツ情報を含むパッケージエントリポイントメタデータとが配置されている。コンテンツ構造解析部３２４は、コンテンツルートフォルダ以下のフォルダの構造を解析して、アプリケーションプログラムに関するコンテンツファイルを前記コンテンツルートフォルダから抽出する。
この構成によれば、パッケージエントリメタデータを参照して、アプリケーションプログラムの最初に参照されるエントリポイントの所在が直ちに識別される。制作者が任意に構成したコンテンツファイルが処理対象として効率的に抽出されるので、制作者と放送事業者もしくはサービス提供者間において共通の処理対象が特定される。例えば、本アプリケーションパッケージを放送事業者もしくはサービス提供者と制作者との間の素材交換、放送事業者における送信装置への共通のデータ形式として利用することにより相互運用性が向上する。

また、コンテンツ構造解析部３２４は、コンテンツファイルのファイル名を解析して、ファイル名が示す時刻とコンテンツファイルの所在を示す制御対象ファイルリストを生成する。そして、アプリケーション送信装置３０及びアプリケーション動作検証装置９０は、制御対象ファイルリストを参照して、番組の編成時刻に相当する時刻を示すファイル名を有するコンテンツファイルを選択するファイル制御部３２６を備える。
この構成によれば、時間経過に応じてコンテンツファイルが更新されるコンテンツについても、番組編成の際にファイル名により処理開始時刻と処理対象のファイルが直ちに特定される。制作者は、処理の開始やその時刻を効率的に検証することができ、放送事業者もしくはサービス提供者は、制作者が意図した処理開始時刻に基づいた番組編成を円滑に行うことができる。

また、ファイル制御部３２６は、選択したコンテンツファイルが空ファイルである場合、選択したファイルのファイル名が示す時刻においてコンテンツファイルに係る処理を停止させることを特徴とする。
この構成によれば、番組編成の際に停止されるコンテンツについて、ファイル名により停止時刻と停止対象のファイルが直ちに特定される。制作者は、処理の停止やその時刻を効率的に検証することができ、放送事業者もしくはサービス提供者は、制作者が意図した処理停止時刻に基づいた番組編成を円滑に行うことができる。

また、アプリケーション送信装置３０及びアプリケーション動作検証装置９０は、それぞれパッケージ展開部３２１を備える。パッケージ展開部３２１は、第１の形式のファイルから、セット毎にデータを格納したコンテンツファイルをヘッダが示すフォルダに配置してアプリケーションパッケージとして展開する。第１の形式のファイルは、コンテンツファイルが配置されるフォルダならびに識別情報を示すヘッダと、コンテンツファイルに格納されたデータとを含むセットがコンテンツファイル間で連結されて構成される。第１の形式のファイルは、例えば、ＺＩＰファイルである。
この構成によれば、第１の形式のファイルから展開により再生されたアプリケーションパッケージから番組編成の際に処理対象のコンテンツファイルが特定される。番組編成において一括した取扱いに便宜な第１の形式のファイルの活用を図ることができる。

また、アプリケーション送信装置３０及びアプリケーション動作検証装置９０は、それぞれ変換部を備える。変換部は、第２の形式のファイルから、区分データをそれぞれ除外して前記第１の形式のファイルに変換する。第２の形式のファイルは、コンテンツファイルが配置されるフォルダならびに識別情報を示すヘッダと、コンテンツファイルに格納されたデータとを含むセットの配置を示す区分データが当該セットそれぞれの先頭にさらに配置されたファイルである。第２の形式のファイルは、例えば、ＭＸＦファイルである。
この構成によれば、第２の形式のファイルから、第１の形式のファイルへの変換を区分データの除外といった簡素な処理により実現することができる。区分データによる個々のコンテンツファイルに対するアクセスが容易な第２の形式のファイルを、第１の形式のファイルに変換して一括した取扱いを促進することができる。

また、アプリケーション動作検証装置９０は、第１の形式に含まれる上述したセットそれぞれの先頭に前記セットの配置を示す区分データを配置して第２の形式のファイルに変換する変換部を備える。
この構成によれば、第１の形式のファイルから第２の形式へのファイルへの変換を区分データの配置といった簡素な処理により実現することができる。そのため、一括した取扱いに便宜な第１の形式のファイルを、第２の形式のファイルに変換して個々のコンテンツファイルに対するアクセスを促進することができるので、コンテンツ制作、編集を効率よく行うことができる。そのため、第１の形式のファイルによる簡易な運用、第２の形式のファイルによるファイルベースシステムとの親和性や長期的なアーカイブへの適用性を両立することができる。

また、アプリケーション送信装置３０は、パッケージエントリポイントメタデータに含まれるトランスミッション情報が示すコンテンツファイルの伝送方式を用いて抽出したコンテンツファイルを送信させる送信制御部３２９を備える。
この構成によれば、制作者が任意に構成したコンテンツファイルが送信対象として効率的に抽出され、放送事業者もしくはサービス提供者が指定した所望の伝送方式を用いて送信される。そのため、デジタル放送サービスを提供において、制作者と放送事業者もしくはサービス提供者との間の相互運用性が向上する。

また、アプリケーション動作検証装置９０は、特定されたアプリケーションプログラムに記述される命令が示す処理を実行する実行部９３を備える。
この構成によれば、制作者が任意に構成したコンテンツファイルが処理対象として効率的に抽出されるので、制作されたアプリケーションパッケージに配置されるアプリケーションプログラムの動作検証を円滑に行うことができる。

以上、図面を参照してこの発明の一実施形態について説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

例えば、アプリケーション送信装置３０は、コンテンツ送信装置２０、符号化装置４０及び多重化装置５０のいずれか、又はそれらの任意の組み合わせと一体化した単一の装置として構成されてもよい。また、アプリケーション動作検証装置９０は、コンテンツ管理装置１０と一体化した単一の装置として構成されてもよい。

Ｂ１…放送通信連携システム、ＢＴ…放送伝送路、ＮＴ…通信伝送路、１０…コンテンツ管理装置、２０…コンテンツ送信装置、３０…アプリケーション送信装置、３１…パッケージ記憶部、３２…制御部、３２１…パッケージ展開部、３２２…展開パッケージ記憶部、３２３…メタデータ解析部、３２４…コンテンツ構造解析部、３２６…ファイル制御部、３２８…制御情報生成部、３２９…送信制御部、３３…外部ファイル更新部、３４…一時フォルダ、３５…送信部、４０…符号化装置、５０…多重化装置、６０…サーバ装置、７０…放送設備、８０…受信機、９０…アプリケーション動作検証装置、９２…制御部、９３…実行部、１００…ルータ装置

Claims (8)

1. デジタル放送サービスのアプリケーションプログラムに関するコンテンツファイルが配置されたコンテンツルートフォルダと、前記アプリケーションプログラムのエントリポイントを示すコンテンツ情報を含むパッケージエントリポイントメタデータとが配置されたアプリケーションパッケージから、
   前記パッケージエントリポイントメタデータを解析して前記アプリケーションプログラムを特定するメタデータ解析部と、
   前記コンテンツルートフォルダ以下のフォルダの構造を解析して、前記アプリケーションプログラムに関するコンテンツファイルを前記コンテンツルートフォルダから抽出するコンテンツ構造解析部と、
   ファイル制御部と、を備え、
   前記コンテンツ構造解析部は、前記コンテンツファイルのファイル名を解析して、前記ファイル名が示す時刻と前記コンテンツファイルの所在を示す制御対象ファイルリストを生成することを特徴とし、
   前記ファイル制御部は、制御対象ファイルリストを参照して、番組の編成時刻に相当する時刻を示すファイル名を有するコンテンツファイルを選択する
   処理装置。
2. 前記ファイル制御部は、選択したコンテンツファイルが空ファイルである場合、前記選択したファイルのファイル名が示す時刻において前記コンテンツファイルに係る処理を停止させることを特徴とする請求項１に記載の処理装置。
3. 前記コンテンツファイルが配置されるフォルダならびに識別情報を示すヘッダと、前記コンテンツファイルに格納されたデータとを含むセットがコンテンツファイル間で連結された第１の形式のファイルから、前記セット毎に前記データを格納したコンテンツファイルを前記ヘッダが示すフォルダに配置して前記アプリケーションパッケージとして展開する展開部
   を備える請求項１または請求項２に記載の処理装置。
4. 前記セットの配置を示す区分データが前記セットそれぞれの先頭にさらに配置された第２の形式のファイルから、前記区分データをそれぞれ除外して前記第１の形式のファイルに変換する第１変換部
   を備える請求項３に記載の処理装置。
5. 前記第１の形式に含まれる前記セットそれぞれの先頭に前記セットの配置を示す区分データを配置して第２の形式のファイルに変換する第２変換部
   を備える請求項３または請求項４に記載の処理装置。
6. 前記パッケージエントリポイントメタデータは、前記コンテンツファイルの伝送方式を示すトランスミッション情報を含み、
   前記トランスミッション情報が示す伝送方式を用いて前記コンテンツファイルを送信させる送信制御部
   を備える請求項１から請求項５のいずれか一項に記載の処理装置。
7. 前記アプリケーションプログラムに記述される命令が示す処理を実行する実行部
   を備える請求項１から請求項５のいずれか一項に記載の処理装置。
8. 処理装置のコンピュータに、
   デジタル放送サービスのアプリケーションプログラムに関するコンテンツファイルが配置されたコンテンツルートフォルダと、前記アプリケーションプログラムのエントリポイントを示すコンテンツ情報を含むパッケージエントリポイントメタデータとが配置されたアプリケーションパッケージから、
   前記パッケージエントリポイントメタデータを解析して前記アプリケーションプログラムを特定するメタデータ解析手順、
   前記コンテンツルートフォルダ以下のフォルダの構造を解析して、前記アプリケーションプログラムに関するコンテンツファイルを前記コンテンツルートフォルダから抽出するコンテンツ構造解析手順、
   ファイル制御手順、を実行させるためのプログラムであって、
   前記コンテンツ構造解析手順は、前記コンテンツファイルのファイル名を解析して、前記ファイル名が示す時刻と前記コンテンツファイルの所在を示す制御対象ファイルリストを生成することを特徴とし、
   前記ファイル制御手順は、制御対象ファイルリストを参照して、番組の編成時刻に相当する時刻を示すファイル名を有するコンテンツファイルを選択する手順を含む
   プログラム。

Images