(57)【要約】  本技術は、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、コンテンツを受信し、コンテンツとともに伝送される、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、取得されたリソース配信情報に基づいて、リソースファイルの配信に応じた処理を行う。本技術は、例えば、デジタル放送を受信可能なテレビ受像機に適用することができる。
2017141701.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、
取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部と
を備える受信装置。
【請求項２】
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
請求項１に記載の受信装置。
【請求項３】
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
請求項２に記載の受信装置。
【請求項４】
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
請求項２に記載の受信装置。
【請求項５】
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
請求項４に記載の受信装置。
【請求項６】
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSID(Service-based Transport Session Instance Description)により特定される、ROUTEセッションで伝送されるEFDT(Extended FDT)に含まれる
請求項４に記載の受信装置。
【請求項７】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、
取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う
ステップを含むデータ処理方法。
【請求項８】
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
請求項７に記載のデータ処理方法。
【請求項９】
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
請求項８に記載のデータ処理方法。
【請求項１０】
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
請求項８に記載のデータ処理方法。
【請求項１１】
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
請求項１０に記載のデータ処理方法。
【請求項１２】
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
請求項１０に記載のデータ処理方法。
【請求項１３】
コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、
前記コンテンツとともに、前記リソース配信情報を送信する送信部と
を備える送信装置。
【請求項１４】
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
請求項１３に記載の送信装置。
【請求項１５】
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
請求項１４に記載の送信装置。
【請求項１６】
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
請求項１４に記載の送信装置。
【請求項１７】
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
請求項１６に記載の送信装置。
【請求項１８】
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
請求項１６に記載の送信装置。
【請求項１９】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成し、
前記コンテンツとともに、前記リソース配信情報を送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
番組やCM等のコンテンツに付随するアプリケーション（以下、単にアプリケーションともいう）の配信ライフサイクルコントロールに、AIT(Application information Table)等のアプリケーション制御情報を用いることが知られている（例えば、特許文献１参照）。このアプリケーション制御情報によって、受信機では、アプリケーションの起動や終了の動作を制御することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１８００６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、アプリケーションの配信ライフサイクルコントロールを簡素化する一方で、受信機側で、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにするための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部とを備える受信装置である。【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報が取得され、取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理が行われる。【０００９】
本技術の第２の側面の送信装置は、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、前記コンテンツとともに、前記リソース配信情報を送信する送信部とを備える送信装置である。【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報が生成され、前記コンテンツとともに、前記リソース配信情報が送信される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができる。【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】本技術を適用した伝送システムの一実施の形態の構成例を示す図である。
【図２】クライアント装置の構成例を示す図である。
【図３】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図４】LLSシグナリングとSLSシグナリングとの関係を示す図である。
【図５】アプリURLに応じたアプリケーション制御を説明する図である。
【図６】SLSシグナリングチャネルとLCCチャネルとの関係を示す図である。
【図７】スタートアップパッケージファイルの構造の例を示す図である。
【図８】W3CのWeb App Manifestのフォーマットの例を示す図である。
【図９】拡張Web App Manifestを利用する場合のスタートアップパッケージファイルの記述例を示す図である。
【図１０】拡張Web App Manifestのフォーマットの例を示す図である。
【図１１】拡張Web App Manifestの記述例を示す図である。
【図１２】図１１の拡張Web App Manifestの記述例を時系列で表した図である。
【図１３】EFDTに記述される転送制御情報を説明する図である。
【図１４】典型的なアプリケーションの構成例を示す図である。
【図１５】放送モードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。
【図１６】放送モードが設定された場合の送信側の処理の流れについて説明するフローチャートである。
【図１７】放送モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図１８】放送モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図１９】ハイブリッドモードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。
【図２０】ハイブリッドモードが設定された場合の送信側の処理の流れについて説明するフローチャートである。
【図２１】ハイブリッドモードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図２２】ハイブリッドモードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図２３】通信モードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。
【図２４】通信モードが設定された場合の送信側の処理の流れについて説明するフローチャートである。
【図２５】通信モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図２６】通信モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。
【図２７】USDメタデータのフォーマットの例を示す図である。
【図２８】S-TSIDメタデータのフォーマットの例を示す図である。
【図２９】SrcFlow要素のフォーマットの例を示す図である。
【図３０】EFDT要素のフォーマットの例を示す図である。
【図３１】EFDTのXMLスキーマの例を示す図である。
【図３２】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．システムの構成
２．本技術の概要
３．具体的な運用例
（Ａ）放送モード
（Ｂ）ハイブリッドモード
（Ｃ）通信モード
４．シグナリングの例
５．変形例
６．コンピュータの構成
【００１７】
＜１．システムの構成＞
【００１８】
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態の構成例を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００１９】
図１において、伝送システム１は、送信側システム１０と、受信側のクライアント装置２０から構成される。伝送システム１においては、送信側システム１０から送信されるデータが、放送網としての伝送路８０、又は通信網としてのインターネット９０を介してクライアント装置２０により受信される。
【００２０】
例えば、伝送システム１では、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0等の所定の規格に準拠したデータ伝送が行われる。
【００２１】
なお、ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【００２２】
送信側システム１０は、ATSC3.0等の所定の規格に準拠したデータを送信するための処理を行う。送信側システム１０は、DASHサーバ１０１、シグナリングサーバ１０２、アプリケーションサーバ１０３、SCH/PKGサーバ１０４、放送サーバ１０５、及び通信サーバ１０６から構成される。
【００２３】
DASHサーバ１０１は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００２４】
このMPEG-DASHの規格では、動画や音声のファイルの管理情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。なお、前者のマニフェストファイルは、MPD(Media Presentation Description)と称される。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００２５】
DASHサーバ１０１は、外部からMPDメタデータを生成するためのデータや、コンテンツのデータなどを受信する。DASHサーバ１０１は、外部からのデータに基づいて、MPDメタデータを生成し、シグナリングサーバ１０２に送信する。また、DASHサーバ１０１は、外部からのデータに基づいて、番組やCM等のコンテンツのセグメント（DASHセグメント）のファイルを生成し、放送サーバ１０５又は通信サーバ１０６に送信する。
【００２６】
シグナリングサーバ１０２は、外部からシグナリングを生成するためのデータを受信する。また、シグナリングサーバ１０２は、DASHサーバ１０１からのMPDメタデータを受信する。シグナリングサーバ１０２は、外部からのデータや、MPDメタデータなどに基づいて、シグナリングを生成し、放送サーバ１０５又は通信サーバ１０６に送信する。
【００２７】
ここで、例えば、ATSC3.0では、シグナリングとして、LLS(Link Layer Signaling)シグナリングとSLS(Service Layer Signaling)シグナリングを用いることが想定されている。LLSシグナリングは、SLSシグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。SLSシグナリングは、サービス単位のシグナリングである。
【００２８】
LLSシグナリングは、SLT(Service List Table)等のメタデータを含む。SLTメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含んでいる。
【００２９】
SLSシグナリングは、USD(User Service Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。USDメタデータは、他のメタデータの取得先などの情報を含む。ただし、USDは、USBD(User Service Bundle Description)と称されることがある。
【００３０】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの制御情報である。なお、ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
【００３１】
MPDメタデータは、上述したように、ストリーミング配信される動画や音声のファイルの管理情報である。なお、SLT，USD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述することができる。
【００３２】
シグナリングサーバ１０２は、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングを生成する。ただし、シグナリングサーバ１０２は、DASHサーバ１０１により生成されたMPDメタデータを、SLSシグナリングとして処理する。
【００３３】
アプリケーションサーバ１０３は、外部からアプリケーションを構成するファイルを生成するためのデータを受信する。アプリケーションサーバ１０３は、外部からのデータに基づいて、アプリケーションを構成するスタートアップページファイル（例えば、HTML文書ファイル等）や、１又は複数のリソースファイル（例えば、画像ファイルやスクリプトファイル等）を生成し、SCH/PKGサーバ１０４に送信する。
【００３４】
なお、アプリケーションは、番組やCM等のコンテンツに付随するアプリケーションである。また、このようなアプリケーションとしては、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションを用いることができる。
【００３５】
SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールを決定し、アプリケーションマニフェストファイルに含める。また、SCH/PKGサーバ１０４は、アプリケーションマニフェストファイル、スタートアップページファイル、及びリソースファイルを含むスタートアップパッケージファイルを生成し、放送サーバ１０５に送信する。
【００３６】
なお、スタートアップパッケージファイルとアプリケーションマニフェストファイルの詳細は、後述する。また、スタートアップパッケージファイルには、スタートアップページファイルとリソースファイルを必ずしも含める必要はない。また、スタートアップページファイルとリソースファイルは、通信経由で配信される場合、通信サーバ１０６に送信される。
【００３７】
また、SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールに応じた転送制御情報を含むEFDTを生成し、放送サーバ１０５に送信する。なお、転送制御情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルに関する情報であって、その詳細については後述する。
【００３８】
さらに、SCH/PKGサーバ１０４は、スタートアップページファイルにより後から参照されるリソースファイルである追加リソースファイルを、放送サーバ１０５又は通信サーバ１０６に送信する。
【００３９】
放送サーバ１０５は、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送を行うことが可能な送信機である。
【００４０】
放送サーバ１０５は、DASHサーバ１０１から送信されてくるDASHセグメント、シグナリングサーバ１０２から送信されてくるシグナリング、及び、SCH/PKGサーバ１０４から送信されるアプリケーションに関するファイル（例えば、スタートアップパッケージファイル等）を受信する。放送サーバ１０５は、DASHセグメント、シグナリング、及び、アプリケーションに関するファイルを処理し、伝送路８０を介して送信（一斉同報配信）する。
【００４１】
通信サーバ１０６は、インターネット９０に接続されたクライアント装置２０からの要求に応じて、インターネット９０を介して各種のデータを提供するサーバである。
【００４２】
通信サーバ１０６は、DASHサーバ１０１から送信されてくるDASHセグメント、シグナリングサーバ１０２から送信されてくるシグナリング、及び、SCH/PKGサーバ１０４から送信されるアプリケーションに関するファイル（例えば、追加リソースファイル等）を受信する。通信サーバ１０６は、DASHセグメント、シグナリング、及び、アプリケーションに関するファイルを処理する。そして、通信サーバ１０６は、クライアント装置２０からの要求に応じて、インターネット９０を介して、各種のファイルを送信する。
【００４３】
クライアント装置２０は、ATSC3.0等の所定の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置２０は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。また、クライアント装置２０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。なお、クライアント装置２０の詳細な構成は、図２を参照して後述する。
【００４４】
クライアント装置２０は、放送サーバ１０５から伝送路８０を介して送信（一斉同報配信）されてくる、DASHセグメント、シグナリングなどのファイルを受信して処理することで、放送番組などのコンテンツの映像や音声を出力する。
【００４５】
また、クライアント装置２０は、通信機能を有する場合、インターネット９０を介して、通信サーバ１０６にアクセスし、各種のファイルを取得することができる。例えば、クライアント装置２０は、通信サーバ１０６からインターネット９０を介して送信（適応的にストリーミング配信）される、DASHセグメントやMPDメタデータ等のファイルを受信して処理することで、VOD(Video On Demand)番組などのコンテンツの映像や音声を出力する。
【００４６】
また、クライアント装置２０は、放送サーバ１０５又は通信サーバ１０６から送信される、アプリケーションに関するファイルを受信して処理することで、アプリケーションを実行する。すなわち、クライアント装置２０では、放送経由又は通信経由で取得されたコンテンツに付随して、放送経由又は通信経由で取得されたアプリケーションが実行される。ただし、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作する場合もある（ユーザに認識されずに起動することがある）。
【００４７】
さらに、クライアント装置２０は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに含まれる配信スケジュール情報や、EFDTに含まれる転送制御情報に基づいて、アプリケーションのリソースファイルの配信に応じた処理を行うことができる。なお、配信スケジュール情報や転送制御情報の詳細は、図７乃至図１３などを参照して後述する。
【００４８】
なお、伝送システム１において、伝送路８０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
【００４９】
ここで、図１の伝送システム１においては、説明を簡単にするために、クライアント装置２０を１つだけ図示しているが、クライアント装置２０は複数設けることができ、送信側システム１０が送信（一斉同報配信）するデジタル放送信号は、伝送路８０を介して複数のクライアント装置２０で同時に受信することができる。
【００５０】
また、送信側システム１０も複数設けることができる。複数の送信側システム１０のそれぞれでは、別個のチャンネルとしての、例えば、別個の周波数帯域で、放送ストリームを含むデジタル放送信号を送信し、クライアント装置２０では、複数の送信側システム１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャンネルを選択することができる。
【００５１】
（クライアント装置の構成）
図２は、図１のクライアント装置２０の構成例を示す図である。
【００５２】
図２において、クライアント装置２０は、処理部２０１、入力部２０２、メモリ２０３、受信部２０４、放送ミドルウェア２０５、DASHクライアント２０６、デコーダ２０７、出力部２０８、ブラウザ２０９、及び通信部２１０から構成される。
【００５３】
処理部２０１は、クライアント装置２０の各部の動作を制御する処理など行う。
【００５４】
入力部２０２は、ユーザの操作に応じた操作信号を処理部２０１に供給する。処理部２０１は、入力部２０２から供給される操作信号に基づいて、クライアント装置２０の各部の動作を制御する。メモリ２０３は、処理部２０１からの制御に従い、各種のデータを記憶する。
【００５５】
受信部２０４は、チューナなどから構成される。受信部２０４は、アンテナ２２１によって、放送サーバ１０５から伝送路８０を介して送信（一斉同報配信）されてくる放送波（デジタル放送信号）を受信して処理し、それにより得られるデータを、放送ミドルウェア２０５に供給する。
【００５６】
放送ミドルウェア２０５は、受信部２０４から供給されるデータを処理し、処理部２０１、DASHクライアント２０６、又はブラウザ２０９に供給する。ここで、処理対象のデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント２０６に供給され、アプリケーションに関するデータは、ブラウザ２０９に供給され、シグナリング等のデータは、処理部２０１に供給される。
【００５７】
DASHクライアント２０６には、放送ミドルウェア２０５からMPDメタデータ及びDASHセグメントが供給される。DASHクライアント２０６は、MPDメタデータに基づいて、DASHセグメントを処理する。このDASHセグメントを処理して得られるビデオとオーディオのデータは、デコーダ２０７に供給される。
【００５８】
デコーダ２０７は、所定の復号方式（例えばHEVC(High Efficiency Video Coding)やAAC(Advanced Audio Coding)等）に従い、DASHクライアント２０６から供給されるビデオとオーディオのデータのデコードを行う。このデコードにより得られるビデオとオーディオのデータは、出力部２０８に供給される。
【００５９】
出力部２０８は、デコーダ２０７から供給されるビデオとオーディオのデータを出力する。これにより、クライアント装置２０では、番組やCM等のコンテンツが再生され、その映像や音声が出力されることになる。
【００６０】
ブラウザ２０９は、例えばHTML5に対応したブラウザである。ブラウザ２０９は、放送ミドルウェア２０５から供給される、アプリケーションのデータを処理し、出力部２０８に供給する。出力部２０８は、ブラウザ２０９から供給されるアプリケーションのデータを出力する。これにより、クライアント装置２０では、番組等に連動して、アプリケーションの映像が表示されることになる。
【００６１】
通信部２１０は、処理部２０１からの制御に従い、インターネット９０を介して、通信サーバ１０６とデータのやりとりを行う。通信部２１０により受信されるデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント２０６に供給され、アプリケーションに関するデータは、ブラウザ２０９に供給され、シグナリング等のデータは、処理部２０１に供給される。これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータと同様であるため、ここでは、その説明は省略する。
【００６２】
また、処理部２０１は、制御部２１１、プロキシサーバ２１２、及びレンダラ２１３を含んで構成される。制御部２１１は、クライアント装置２０の各部の動作を制御する。プロキシサーバ２１２は、処理対象のデータの送受信に関する処理などを行う。レンダラ２１３は、処理対象のデータを出力するための処理を行う。
【００６３】
クライアント装置２０は、以上のように構成される。
【００６４】
＜２．本技術の概要＞
【００６５】
（本技術のプロトコルスタック）
図３は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００６６】
図３において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層（Physical Layer）は、サービス（チャネル）のために割り当てられた放送波の周波数帯域が対応することになる。
【００６７】
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP層とされる。IP層は、通信の階層モデルにおけるネットワーク層に相当するものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層は、通信の階層モデルにおけるトランスポート層に相当するUDP(User Datagram Protocol)層とされ、さらにその上位の階層は、ROUTEとされる。
【００６８】
また、UDP層の上位の階層、すなわち、UDPパケットを含むIPパケット（IP/UDPパケット）には、SLTメタデータが格納され、伝送される。SLSメタデータは、LLSシグナリングであって、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含んでいる。
【００６９】
ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTEを拡張したものである。ROUTEに隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、LCC(Locally Cached Content)コンテンツ（LCC（NRT））とされる。
【００７０】
このシグナリングは、SLSシグナリングであって、例えば、USD，S-TSID，MPD等のメタデータが含まれる。すなわち、図４に示すように、クライアント装置２０では、最初に、LLSシグナリングとしてのSLTメタデータを取得してから、サービス単位のSLSシグナリング（S-TSID等）を取得することになる。
【００７１】
図３の説明に戻り、LCCコンテンツは、クライアント装置２０のストレージに一旦蓄積された後で再生が行われるコンテンツである。なお、LCC(Locally Cached Content)は、NRT(Non Real Time)と称される場合がある。上述したアプリケーションは、LCCコンテンツとしてROUTEセッションにより伝送することができる。さらに、LCCコンテンツとして、例えば、電子サービスガイド（ESG：Electronic Service Guide）などのコンテンツが、ROUTEセッションにより伝送されるようにしてもよい。
【００７２】
ROUTEに隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFF(ISO Base Media File Format)の規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
【００７３】
また、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。また、IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。すなわち、これらの階層によって、インターネット９０等のネットワークで稼働するTCP/IPなどのプロトコルが実装される。
【００７４】
HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、LCCコンテンツ（LCC（NRT））とされる。このシグナリングとしては、上述したROUTEで伝送されるシグナリングなど、すべてのシグナリングが含まれる。また、LCCコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
【００７５】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【００７６】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、放送サーバ１０５やクライアント装置２０では、実装の負担や処理の負担を軽減することができる。
【００７７】
（アプリケーションの制御）
ところで、番組やCM等のコンテンツに付随するアプリケーションを用いたサービスを提供するに際し、アプリケーションの制御モデルをシンプルに実装する提案が要請されている。例えば、ATSC3.0では、アプリケーションの配信ライフサイクルコントロールに、AST(Application Signaling Table)を用いることが検討されているが、ASTを利用する以外に、よりアプリケーションの制御モデルをシンプルに実装することが求められている。
【００７８】
例えば、図５に示すように、コンテンツに付随して起動するアプリケーションのURL（以下、アプリURL（App URL）という）を、特定のファイル（後述するアプリケーションマニフェストファイル）やシグナリングなどに記述しておくことで、アプリケーションの制御モデルをシンプルに実装することができる。このような実装を行った場合、クライアント装置２０においては、サービスが選局されたときに、直ちにそのファイルやシグナリングに記述されたアプリURLに従い、アプリケーションが取得され、起動されることになる。
【００７９】
このようなアプリURLに応じてアプリケーションを起動する手法を採用した場合、当該アプリURLにより、アプリケーションの最初のページのファイル（スタートアップページファイル（例えばHTML文書ファイル））のURL（スタートアップページURL）を、クライアント装置２０に通知することはできる。一方で、そのURLで示されるページのファイル（スタートアップページファイル）において参照される、画像ファイル（例えばjpegファイル）やスクリプトファイル（例えばJavaScript（登録商標）のコードが記述されたファイル）等の各種リソースファイルは、最初のページのファイル（スタートアップページファイル）を取得した後で、アプリケーションのニーズに応じて必要なタイミングで放送経由又は通信経由（インターネット経由）で取得される。
【００８０】
この場合、クライアント装置２０のブラウザ２０９（図２）では、最初に取得されたページのファイル（スタートアップページファイル）をパース（構文解析）して、必要なリソースファイルの取得先を示すURLが解決されると、その各々のURLにより特定されるリソースファイルを取得するためのリクエストを発行することになる。一般に、HTML文書（ページ）では、複数のリソースファイルを参照しているため、すべてのリソースファイルが、クライアント装置２０のメモリ２０３（図２）内に揃った時点で、アプリケーション（のページ）を表示する必要がある。
【００８１】
ここで、ATSC3.0では、クライアント装置２０のブラウザ２０９（図２）がアクセスする先（HTTPリクエストを送る先）は、ローカルのプロキシサーバ２１２（図２）とされている。そして、ATSC3.0で規定されるシグナリングやトランスポートプロトコルを終端する放送ミドルウェア２０５（図２）が、放送経由で配信されたシグナリングやコンテンツをローカルファイルシステムに展開し、ローカルのプロキシサーバ２１２（図２）上に実装されたサーバサイドスクリプト（モジュール）等によるプログラム処理により、放送ミドルウェア２０５（図２）と直接又は一体となって、DASHクライアント２０６（図２）やブラウザ２０９（図２）上で実行されるアプリケーション等（クライアント）からの取得リクエストに応じるモデルが想定されている。
【００８２】
上述したように、ブラウザ２０９（図２）が、最初のHTML文書ファイル（スタートアップページファイル）をパースして、そのHTML文書ファイルにより参照されているリソースファイルの取得リクエストを発行したとしても、そのリソースファイルが、ローカルファイルシステム上に展開されている状態となっているか、あるいは、ローカルのプロキシサーバ２１２（図２）のサーバサイドスクリプト（モジュール）がアクセス可能な状態となっていなければならならい。
【００８３】
すなわち、このような状態になっていないと、HTML文書ファイル（スタートアップページファイル）のすべてのリソースファイルを表示可能な状態とすることができないまま、リソースファイルの取得リクエストがタイムアウトとなり、ユーザによっては、不完全な状態でアプリケーション（のページ）がロードされたと誤認識されてしまうことになる。そのため、すべてのリソースファイルが最初にまとめて準備されていることが必須となる。
【００８４】
また、例えば、放送番組に付随するアプリケーションでは、最初のHTML文書ファイル（スタートアップページファイル）をロードした後に、各シーンごとに提示するリソースファイルが逐次変化（追加）していくのが一般的であり、このような番組全体に渡って必要なリソースファイルを俯瞰できないと、プロトコル処理やメモリ管理の最適化を行うことができない。すなわち、どれだけのリソースファイルがどういったタイミングで今後必要となってくるかについて、番組全体に渡って俯瞰して、クライアント装置２０のコンピューティングリソースを、各サービス（番組）に対してどのように分配するかなどについての最適化を図る必要がある。
【００８５】
本技術では、これらの問題を解決するために、次のような提案を行うものとする。すなわち、ROUTEプロトコルの制御情報であるEFDTに、スタートアップパッケージファイルについてのURL（スタートアップパッケージURL）を含む転送制御属性を記述し、そのスタートアップパッケージファイルに含まれるアプリケーションマニフェストファイルに、対象のアプリケーションのエントリのスタートアップページファイル（例えばHTML文書ファイル）を指定したURL（スタートアップページURL）が記述されるようにする。
【００８６】
すなわち、このスタートアップページURLが、上述したアプリURL（図５）に相当するものとなる。つまり、本技術のアプリケーション制御では、AITやAST等のアプリケーション制御情報を用いた場合のアプリケーション制御とは異なり、配信ライフサイクルコントロールは行わずに、スタートアップページURL（図５のアプリURL）に従い、即時にアプリケーションが起動（取得）されるという流れになるので、アプリケーションの制御モデルをよりシンプルに実装することができる。
【００８７】
なお、スタートアップパッケージファイルは、ROUTEのパッケージモードで構成されたファイルであって、スタートアップページファイル（例えばHTML文書ファイル）と、リソースファイル（例えば画像ファイルやスクリプトファイル等）を含むことができる。
【００８８】
また、スタートアップパッケージファイルのアプリケーションマニフェストファイルには、対象のアプリケーションに含まれるリソースファイルのすべてについての配信スケジューリングの最適化に利用可能な属性を記述できるようにする。このようなリソースファイルの全体を俯瞰するためのリソースリストがあれば、リソースファイルの取得タイミングの信頼性などを向上させることができる。さらに、各々のリソースファイルの転送属性が、各ファイルのURLを含む転送制御属性を記述するEFDTに記述できるようにする。
【００８９】
なお、上述したように、SLSシグナリングやLCCコンテンツは、ROUTEセッションで伝送されるが、図６に示すように、ROUTEプロトコルのサービスレイヤの制御に用いられるS-TSIDにより記述されるLCTチャネル（セッション）の１つが、ノンリアルタイムコンテンツであるLCCコンテンツの転送に割り当てられている。また、LCCコンテンツ用のLCTチャネルにおいては、ファイルモードで伝送されるEFDTにより、そのチャネルで転送するファイル群の転送制御パラメタが記述されるようにする。ここで、ファイルモード（File Mode）は、単一のファイルを転送するモードである。一方で、パッケージモード（Package Mode）は、複数のファイルをまとめて（同梱して）パッケージとして転送するモードとなる。
【００９０】
（スタートアップパッケージファイルの構造）
図７は、スタートアップパッケージファイルの構造の例を示す図である。
【００９１】
スタートアップパッケージファイルは、パッケージモードで配信され、アプリケーションマニフェストファイルとともに、スタートアップページファイル（例えばHTML文書ファイル）やリソースファイル（例えば画像ファイルやスクリプトファイル等）を同梱することができる。
【００９２】
ここで、アプリケーションマニフェストファイルは、フォーマットとして、例えば、W3C(World Wide Web Consortium)により標準化が進められているWeb App Manifest（"https://www.w3.org/TR/appmanifest/"）を利用することができる。
【００９３】
また、図７に示すように、アプリケーションマニフェストファイルが、どのフォーマットを利用するかは、パッケージモードで利用しているMultipart MIMEフォーマットのルートパートに格納される、MetadataEnvelopeのitem要素のcontent-Type属性に指定されるMIMEタイプ等により識別されるようにすることができる。なお、図７に示した２つのitem要素のうち、上側のitem要素は、アプリケーションマニフェストファイルのフォーマットに対応し、下側のitem要素は、スタートアップページファイルのフォーマットに対応している。
【００９４】
例えば、現状のアプリケーションマニフェストファイルでは、MetadataEnvelopeのitem要素のcontent-Type属性として、"application/w3c-manifest+json"が指定された場合には、W3CのWeb App Manifestのフォーマットを利用することになる。図８には、W3CのWeb App Manifestのフォーマットの例が示されている。図８のWeb App Manifestのフォーマットでは、"start_url"に対して、スタートアップページURLの値が指定可能である。
【００９５】
本技術では、リソース配信情報として、アプリケーションの一部である１又は複数のリソースファイルの配信スケジュールに関する配信スケジュール情報が配信されるようにするが、現状のアプリケーションマニフェストファイルのフォーマットでは、当該配信スケジュール情報を指定することができない。
【００９６】
そこで、本技術では、アプリケーションマニフェストファイルのフォーマットの１つである、Web App Manifestを拡張することで、スタートアップページURLだけでなく、リソースファイルごとに、配信スケジュール情報が指定できるようにする。
【００９７】
ただし、この拡張されたWeb App Manifest（以下、拡張Web App Manifestとも記述する）を、W3CのWeb App Manifest（図８）と区別するために、アプリケーションマニフェストファイルのフォーマットとして、拡張Web App Manifestを利用する場合には、スタートアップパッケージファイル（図７）のMetadataEnvelopeのitem要素のcontent-Type属性として、"application/atsc-manifest+json"が指定されるようにする（図９）。なお、"json"は、テキストフォーマットの一種であるJSON(JavaScript（登録商標） Object Notation)形式で表されることを意味している。
【００９８】
（拡張Web App Manifestの構造）
図１０は、拡張Web App Manifestのフォーマットの例を示す図である。なお、このフォーマットの例は、JSON形式で記述されている。このJSON形式のオブジェクトは、キーと値のペアをコロン（：）で対にして、これらの対をコンマ（，）で区切ってゼロ個以上列挙し、全体を波括弧（{}）でくくることで表現される。
【００９９】
図１０の拡張Web App Manifestでは、スタートアップページURLのほかに、リソースファイルごとの配信スケジュール情報が、配信スケジュール属性として指定可能である。この配信スケジュール属性としては、例えば、リソースファイルの取得先を示す情報、リソースファイルのサイズ、及びリソースファイルの配信時刻を指定することができる。
【０１００】
例えば、図１０の拡張Web App Manifestにおいて、"url"であるキーに対し、リソースファイルのファイルURLを示す値がペアになって指定されることを表している。ただし、リソースファイルのファイルURLは、必須の値である。また、"sizes"であるキーに対し、リソースファイルのサイズ（バイト単位）を示す値がペアになって指定される。ただし、リソースファイルのサイズは、任意の値である。
【０１０１】
"absoluteDeliveryTimeStart"であるキーに対し、絶対時刻での配信開始時刻を示す値がペアになって指定される。また、"absoluteDeliveryTimeEnd"であるキーに対し、絶対時刻での配信終了時刻を示す値がペアになって指定される。ただし、絶対時刻での配信開始時刻と配信終了時刻の形式は、"YYYY-MM-DDTHH:mm:ssZ"とすることができる。また、絶対時刻での配信開始時刻と配信終了時刻は、任意の値である。
【０１０２】
"relativeDeliveryTimeStart"であるキーに対し、ノーマルプレイタイム（Normal Play Time）的な番組の先頭からの相対時刻での配信開始時刻を示す値がペアになって指定される。また、"relativeDeliveryTimeEnd"であるキーに対し、ノーマルプレイタイム（Normal Play Time）的な番組の先頭からの相対時刻での配信終了時刻を示す値がペアになって指定される。ただし、相対時刻での配信開始時刻と配信終了時刻の形式は、"THH:mm:ss.ffffff"とすることができる。また、相対時刻での配信開始時刻と配信終了時刻は、任意の値である。
【０１０３】
なお、図１０の拡張Web App Manifestの例では、１つのリソースファイルに対する配信スケジュール属性が指定される場合が例示されているが、複数のリソースファイルが存在する場合には、リソースファイルごとに、配信スケジュール属性が記述される。一方で、リソースファイルが存在しない場合には、この配信スケジュール属性を記述する必要はない。
【０１０４】
（拡張Web App Manifestの記述例）
図１１は、拡張Web App Manifestの記述例を示す図である。
【０１０５】
図１１の拡張Web App Manifestにおいては、"StartUpPage-url"であるスタートアップページURLとともに、２つのリソースファイルごとの配信スケジュール属性が記述されている。
【０１０６】
１つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルのファイルURLとして、"ResourceFile-10-url"であるURLが指定され、当該リソースファイルのサイズとして、123バイトが指定されている。また、１つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルの相対時刻での配信開始時刻と配信終了時刻として、"T00:10:22.123456"と"T00:12:33.654321"が指定されている。
【０１０７】
２つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルのファイルURLとして、"ResourceFile-11-url"であるURLが指定され、当該リソースファイルのサイズとして、4567バイトが指定されている。また、２つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルの相対時刻での配信開始時刻と配信終了時刻として、"T00:13:44.345678"と"T00:16:55.654321"が指定されている。
【０１０８】
図１１の拡張Web App Manifestの記述例を時系列で表すと、図１２に示すようになる。すなわち、図１２においては、時間の方向は、図中の左側から右側に向かう方向とされるが、番組の先頭を起点（T00:00:00.000000）として、"T00:10:22.123456"から"T00:12:33.654321"までの間に、"ResourceFile-10-url"であるファイルURLのリソースファイルが提示される。また、番組の先頭を起点（T00:00:00.000000）として、"T00:13:44.345678"から"T00:16:55.654321"までの間に、"ResourceFile-11-url"であるファイルURLのリソースファイルが提示される。
【０１０９】
なお、図１２の例は、リソースファイルが放送経由で配信される場合を表しており、リソースファイルが通信経由で配信される場合には、指定された期間に、インターネット９０上の通信サーバ１０６から対象のリソースファイルが取得可能であることを示すことになる。
【０１１０】
（EFDTの転送制御情報）
図１３は、EFDTに記述される転送制御情報を説明する図である。
【０１１１】
リソース配信情報としては、上述した拡張Web App Manifestのフォーマットに記述される配信スケジュール情報（配信スケジュール属性）のほかに、EFDTに記述される転送制御情報（転送制御属性）がある。
【０１１２】
この転送制御情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの詳細な転送制御を行うための情報である。EFDTでは、リソースファイルごとの詳細な転送制御を行うための転送制御情報が、転送制御属性として指定可能である。この転送制御属性としては、例えば、各リソースファイルの再送周期及び再送終了日時の少なくとも一方を指定することができる。
【０１１３】
ここで、リソースファイルの再送周期（Retransmission-Cycle）の属性としては、例えば、"everyDay"，"everyHour"，"everyMinute"，"everySecond"などを指定することができる。
【０１１４】
"everyDay"は、対象のリソースファイルが１日１回は再送される可能性があることを意味する。すなわち、再送周期の属性として、"everyDay"が指定された場合、クライアント装置２０は、１日待っていれば、必ず再取得の可能性があることになる。
【０１１５】
"everyHour"は、１時間に１回は再送される可能性があることを意味する。"everyMinute"は、１分に１回は再送される可能性があることを意味する。"everySecond"は、１秒に１回は再送される可能性があることを意味する。
【０１１６】
また、リソースファイルの再送終了日時（Retransmission-End）の属性としては、例えば、その再送が終了する日時を表す、"YYYY-MM-DDTHH:mm:ss"の形式で指定されるようにすることができる。
【０１１７】
例えば、図１３のEFDTにおいては、リソースファイルの再送周期（Retransmission-Cycle）の属性として、"everyMinute"が記述され、リソースファイルの再送終了日時（Retransmission-End）の属性として、"2012-03-14T00:00:00"が記述されている。
【０１１８】
図１３のEFDTの記述例を時系列で表すと、図１３の右側に示すような関係となる。すなわち、図１３の右側の時系列においては、時間の方向は、図中の左側から右側に向かう方向とされるが、"ResourceFile-url"で識別されるリソースファイルは、毎秒ごとに再送され（00:00:00，00:01:00，00:02:00，・・・）、その再送が終わる日時（時刻）は、2012年3月14日の午前0時となる。
【０１１９】
クライアント装置２０では、リソースファイルの再送周期や再送終了日時の属性をヒントにして、取りこぼしたリソースファイル（例えば画像ファイル等）が、いつ再送されてくるのかを予測することができるため、リソースファイルを取得するためのスケジューリングの最適化を行うことができる。
【０１２０】
なお、リソースファイルの再送周期（Retransmission-Cycle）や再送終了日時（Retransmission-End）の属性は、少なくとも一方が記述されていればよく、例えば、再送周期の属性の記述をせずに、再送終了日時の属性のみが記述された場合には、当該再送終了日時の属性により指定される日時（時刻）までに、対象のリソースファイルが１度だけ再送されることを意味する。
【０１２１】
このように、拡張Web App Manifestのフォーマットを利用したアプリケーションマニフェストファイルによって、配信スケジュール情報が指定されることで、クライアント装置２０では、番組全体に渡っての個々のリソースファイルのサイズや配信タイミングを認識することができる。また、EFDTによって、転送制御情報として、個々のリソースファイルの配信予定区間内の細やかな再送周期や再送終了日時が指定されることで、クライアント装置２０では、受信処理を行うリソースについて、よりきめ細やかに、最適な配分を行うことが可能となる。
【０１２２】
＜３．具体的な運用例＞
【０１２３】
図１４は、典型的なアプリケーションの構成例を示す図である。
【０１２４】
図１４においては、時間の方向が、図中の左側から右側に向かう方向とされる。放送番組（Program）は、シーン１乃至シーン３を含み、シーン１（Scene1）、シーン２（Scene2）、シーン３（Scene3）の順に遷移される。
【０１２５】
最初のシーン１には、アプリケーションの最初のエントリとなるスタートアップページファイル（StartUpPage）が提示される。このスタートアップページファイルは、例えば、HTML文書ファイルからなり、画像ファイル（例えばjpegファイル）やスクリプトファイル（例えばJavaScript（登録商標）のコードが記述されたファイル）等の各種リソースファイル（Resource1，Resource2，Resource3）を参照することで、アプリケーションの１番目のビュー（The 1st View）として、同時に提示される。
【０１２６】
シーン１からシーン２に遷移すると、アプリケーションの２番目のビュー（The 2nd View）の内容が提示される。このとき、２番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、新たなリソースファイル（Resource4）が追加されている点が異なっている。
【０１２７】
また、シーン２において、アプリケーションは、２番目のビューから、３番目のビュー（The 3rd View）に切り替わり、３番目のビューの内容が提示される。このとき、３番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、提示されていたリソースファイル（Resource4）が消去され、新たなリソースファイル（Resource5）が追加されている点が異なっている。
【０１２８】
なお、繰り返しになるので、その説明は省略するが、各シーンにおいて、スタートアップページファイルにより参照されるリソースファイルが追加又は消去されることで、アプリケーションのビューが切り替わることになる。
【０１２９】
シーン２に続く、シーン３においては、アプリケーションは、N-1番目のビューから、N番目のビュー（The Nth View）に切り替わり、N番目のビューの内容が提示される。このとき、N番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、提示されていたリソースファイル（Resource4乃至Resource N-1）が消去され、新たなリソースファイル（Resource N）が提示されている。
【０１３０】
このように、放送番組に付随するアプリケーションでは、スタートアップページファイルを制御の中心にして、参照されるリソースファイルを追加又は消去することで、各シーンに応じた表示内容（ビューの内容）が提示されることになる。なお、異なるHTML文書ファイルが複数取得されるようにし、例えばインラインフレーム（HTMLで規定されるiframe要素）などを利用して、異なる文書（ドキュメント）をそのまま、一連のビューとして提示する方法もあるが、本技術の実施の形態では、スタートアップページファイルを制御の中心とした場合を説明する。
【０１３１】
また、本技術の実施の形態では、アプリケーションの配信モード（デリバリモード）として、次の３種類のモードをサポートする場合を説明する。すなわち、配信モードとしては、放送モード、ハイブリッドモード、及び通信モードを設定することができる。
【０１３２】
放送モード（Broadcast Only Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルにより参照されるリソースファイルが、放送経由での配信により完結しているモードである。
【０１３３】
ハイブリッドモード（Hybrid Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルで常に参照されるリソースファイル以外のリソースファイルについては、放送経由又は通信経由で配信されるモードである。この場合、EFDTには、常にスタートアップパッケージファイルURLが記述され、それ以外のリソースファイルについては、放送経由で配信するものについてのみ、転送制御属性を記述することになる。スタートアップページファイルとそのスタートアップページファイルで参照されるリソースファイルは、アトミックに取得、表示される。
【０１３４】
通信モード（Broadband Only Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルにより参照されるすべてのリソースファイルが、通信経由で配信されるモードである。この場合、EFDTには、常にスタートアップパッケージファイルURLが記述され、スタートアップパッケージファイルには、アプリケーションマニフェストファイルのみが格納されるため、それ以外のファイルの転送制御属性は記述されないことになる。
【０１３５】
以下、配信モードとして、放送モード、ハイブリッドモード、又は通信モードが設定された場合のそれぞれについて説明する。
【０１３６】
（Ａ）放送モード
まず、図１５乃至図１８を参照して、配信モードとして、放送モードが設定された場合について説明する。
【０１３７】
（放送モード時のデータの流れ）
図１５は、クライアント装置２０（図１）において、放送モードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図１５のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
【０１３８】
図１５においては、図中の左側から右側に向かう時間軸の上側に、ROUTEセッションのLCCチャネルで配信されるEFDTが時系列で表される一方で、時間軸の下側に、ROUTEセッションのLCCチャネルで配信されるスタートアップパッケージファイルやリソースのファイルが模式的に表されている。
【０１３９】
図１５において、ファイルモードで配信されるEFDTは、時系列でバージョンが更新されるが、最初に取得されるVer1.0（v.1）のEFDTは、シーン１（図１４）の間に配信されるEFDTであって、当該EFDTを識別するEFDT URLのほかに、スタートアップパッケージURLが記述されている。クライアント装置２０では、このEFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ１１）。
【０１４０】
このスタートアップパッケージファイル（StartUpPackage）には、当該スタートアップパッケージファイルを識別するスタートアップパッケージURL（StartUpPackageURL）が記述されるほかに、アプリケーションマニフェストファイル（AppManifest）と、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）が同梱されている。
【０１４１】
なお、スタートアップパッケージファイルにおいて、アプリケーションマニフェストのファイルと同梱されるファイルには、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）があるが、これらのファイルは、アプリケーションマニフェストのファイルと同時に取得されることが保証されている。
【０１４２】
また、リソースファイルは、例えば画像ファイルやスクリプトファイルである。例えば、Resource1は、JavaScript（登録商標）のコードが記述されたファイルであり、Resource2は、jpeg形式の画像ファイルであり、Resource3は、mp4形式の動画ファイルである。
【０１４３】
このスタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
【０１４４】
ここで、アプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用しており、ファイルURLとしてのアプリケーションマニフェストURL（AppManifestURL）が記述されるほかに、スタートアップページURL（StartUpPageURL）と、リソースファイルごとの配信スケジュールに関する配信スケジュール情報（Attributes）を含んでいる。このスタートアップページURLによって、アプリケーションのエントリファイル（スタートアップページファイル）を示している。また、配信スケジュール情報には、各リソースファイルのファイルURL、サイズ、及び配信時刻に関する情報などが含まれる。
【０１４５】
シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、シーン２の前段のパートで提示されるリソースファイル（Resource4）と、シーン２の後段のパートで提示されるリソースファイル（Resource5）のURLなどが記述される。
【０１４６】
Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ１２）、リソースファイルURLにより、放送経由のファイルモードで配信されるリソースファイル（Resource4，Resource5）が取得される（Ｓ１３，Ｓ１４）。
【０１４７】
すなわち、スタートアップページファイル（HTML文書ファイル）自体は、最初のスタートアップページファイルと同じであるが、新たなリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）や、リソースファイル（Resource4）の消去とリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
【０１４８】
２番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource4を参照している。また、３番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource3と、Resource5を参照している。
【０１４９】
さらに、シーン２からシーン３に遷移するまでの間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、リソースファイル（Resource N）のURLなどが記述される。
【０１５０】
Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ１５）、リソースファイルURLにより、放送経由のファイルモードで配信されるリソースファイル（Resource N）が取得される（Ｓ１５，Ｓ１６）。
【０１５１】
すなわち、スタートアップページファイル（HTML文書ファイル）自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4乃至Resource N-1）の消去とリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。N番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource3と、Resource Nを参照している。
【０１５２】
次に、図１６乃至図１８のフローチャートを参照して、放送モードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
【０１５３】
（送信側の処理の流れ）
最初に、図１６のフローチャートを参照して、送信側システム１０により実行される、放送モードが設定された場合の送信側の処理の流れについて説明する。なお、この送信側の処理では、アプリケーションサーバ１０３、SCH/PKGサーバ１０４、及び放送サーバ１０５により実行される、コンテンツに付随するアプリケーションに関する処理を中心に説明し、DASHサーバ１０１などにより実行される、放送番組等のコンテンツに関する処理は省略するものとする。
【０１５４】
図１６のステップＳ３０１乃至Ｓ３０２の処理は、アプリケーションサーバ１０３（図１）により実行される。
【０１５５】
ステップＳ３０１において、アプリケーションサーバ１０３は、アプリケーションのオーサリング処理を行う。このオーサリング処理では、スタートアップページファイルや１又は複数のリソースファイルが生成され、それらのファイル群により構成されるアプリケーションが生成される。
【０１５６】
ステップＳ３０２において、アプリケーションサーバ１０３は、ステップＳ３０１の処理で生成されたスタートアップページファイルや１又は複数のリソースファイルなどのファイル群を、SCH/PKGサーバ１０４に送信する。
【０１５７】
図１６のステップＳ４０１乃至Ｓ４０８の処理は、SCH/PKGサーバ１０４（図１）により実行される。また、SCH/PKGサーバ１０４においては、ステップＳ３０２の処理で送信されたファイル群が受信される。
【０１５８】
ステップＳ４０１において、SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールを決定する。
【０１５９】
ステップＳ４０２において、SCH/PKGサーバ１０４は、ステップＳ４０１の処理で決定された配信スケジュールに従い、EFDTを生成する。なお、EFDTには、ステップＳ４０１の処理で決定された配信スケジュールに応じた転送制御情報を含めることができる。ステップＳ４０３において、SCH/PKGサーバ１０４は、ステップＳ４０２の処理で生成されたEFDTを、放送サーバ１０５に送信する。
【０１６０】
ステップＳ４０４において、SCH/PKGサーバ１０４は、ステップＳ３０１の処理で生成されたファイル群（例えば、スタートアップページファイルや１又は複数のリソースファイル等）に基づいて、スタートアップパッケージファイルを生成する。なお、スタートアップパッケージファイルに格納されるアプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用することで、ステップＳ４０１の処理で決定された配信スケジュールに応じた配信スケジュール情報を含めることができる。
【０１６１】
ステップＳ４０５において、SCH/PKGサーバ１０４は、ステップＳ４０４の処理で生成されたスタートアップパッケージファイルを、放送サーバ１０５に送信する。
【０１６２】
ステップＳ４０６において、SCH/PKGサーバ１０４は、ステップＳ４０１の処理で決定された配信スケジュールに従い、EFDTを生成する。なお、EFDTには、ステップＳ４０１の処理で決定された配信スケジュールに応じた転送制御情報を含めることができる。ステップＳ４０７において、SCH/PKGサーバ１０４は、ステップＳ４０６の処理で生成されたEFDTを、放送サーバ１０５に送信する。
【０１６３】
ステップＳ４０８において、SCH/PKGサーバ１０４は、ステップＳ３０１の処理で生成されたファイル群のうち、追加リソースファイルを、放送サーバ１０５に転送する。
【０１６４】
図１６のステップＳ５０１乃至Ｓ５０４は、放送サーバ１０５（図１）により実行される。また、放送サーバ１０５においては、ステップＳ４０３又はＳ４０７の処理で送信されたEFDTと、ステップＳ４０５の処理で送信されたスタートアップパッケージファイルと、ステップＳ４０７の処理で送信された追加リソースファイルが受信される。
【０１６５】
ステップＳ５０１において、放送サーバ１０５は、ステップＳ４０２の処理で生成されたEFDTを、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
【０１６６】
ステップＳ５０２において、放送サーバ１０５は、ステップＳ４０４の処理で生成されたスタートアップパッケージファイルを、パッケージモードで、伝送路８０を介して送信（一斉同報配信）する。
【０１６７】
ステップＳ５０３において、放送サーバ１０５は、ステップＳ４０６の処理で生成されたEFDTを、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
【０１６８】
ステップＳ５０４において、放送サーバ１０５は、ステップＳ４０８の処理で転送された追加リソースファイル（ステップＳ３０１の処理で生成されたリソースファイル）を、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
【０１６９】
以上、送信側の処理の流れについて説明した。
【０１７０】
（受信側の処理の流れ）
次に、図１７及び図１８のフローチャートを参照して、クライアント装置２０により実行される、放送モードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理では、コンテンツに付随するアプリケーションに関する処理を中心に説明し、放送番組等のコンテンツに関する処理は省略するものとする。すなわち、図１７及び図１８の処理が実行される前提として、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
【０１７１】
ステップＳ２０１において、放送ミドルウェア２０５は、IP/UDPパケットに格納されるSLTメタデータと、ROUTEセッションで伝送されるSLSシグナリングを取得する。ここで、SLSシグナリングとしては、USDメタデータが取得されることで、そこに記述されている情報に従い、S-TSIDメタデータが取得される。
【０１７２】
ステップＳ２０２において、放送ミドルウェア２０５は、ステップＳ２０１の処理で取得されたSLSシグナリング（S-TSIDメタデータ）に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信されるEFDTを取得する。
【０１７３】
ステップＳ２０３において、放送ミドルウェア２０５は、ステップＳ２０２の処理で取得されたEFDTをパースする。
【０１７４】
ステップＳ２０４において、放送ミドルウェア２０５は、ステップＳ２０３の処理の解析結果に基づいて、ROUTEセッションのLCCチャネルで、パッケージモードにより配信されるスタートアップパッケージファイルを取得する。
【０１７５】
ステップＳ２０５において、放送ミドルウェア２０５は、ステップＳ２０４の処理で取得されたスタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されているかどうかを判定する。
【０１７６】
ステップＳ２０５において、新しいスタートアップページURLが記述されていないと判定された場合、処理は、ステップＳ２０１に戻り、それ以降の処理が繰り返される。そして、ステップＳ２０１乃至Ｓ２０５の処理が繰り返されることで、ステップＳ２０５の判定処理で、新しいスタートアップページURLが記述されていると判定された場合、処理は、ステップＳ２０６に進められる。
【０１７７】
ステップＳ２０６において、放送ミドルウェア２０５は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに記述された（新しい）スタートアップページURLを、ブラウザ２０９に通知する。これにより、アプリケーションの起動が開始されることになる。
【０１７８】
なお、このスタートアップページURLが、放送ミドルウェア２０５から、ブラウザ２０９に通知される時点で、ステップＳ２０４の処理で取得されたスタートアップパッケージファイルに格納されたスタートアップページファイルと１又は複数のリソースのファイルが、メモリ２０３のローカルファイルシステム上に展開されているか、あるいはプロキシサーバ２１２のサーバサイドスクリプトがアクセス可能になっている。すなわち、アプリケーションの起動が開始された場合に、ブラウザ２０９からの要求に対して、直ちに返答できるように、スタートアップページファイルやリソースファイルの返答の準備がなされている。
【０１７９】
また、アプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用しているため、リソースファイルごとの配信スケジュール情報（リソースファイルのサイズや配信時刻）が記述されているが、この配信スケジュール情報は、放送ミドルウェア２０５又は処理部２０１（制御部２１１）により解析され、その解析結果は、メモリ２０３に記憶される。そして、例えば、メモリ２０３のメモリ管理を行う場合に、メモリ２０３の容量に十分な余裕があるときには、この配信スケジュール情報の解析結果を用いて、最初に、各リソースファイルのバイト数の総和に応じた記憶領域をメモリ部２０３に確保しておく、といった処理を行うことができる。
【０１８０】
一方で、例えば、メモリ２０３の容量に、十分な余裕がないときには、メモリ２０３の記憶領域の確保が必要になった時に、配信スケジュール情報の解析結果を参照して、その時に必要な記憶領域を確保するといった処理を行うことができる。さらに、メモリ２０３の容量に、十分な余裕がないときには、将来取得するリソースファイルのEFDTが取得される前に、配信スケジュール情報の解析結果に応じて（しかるべきタイミングで）、リソースファイル（の返答）の準備が必要になったとき、リソースファイルのサイズを見積もることで、あらかじめ必要な記憶領域をメモリ２０３上に確保しておく、といった処理を行うこともできる。ただし、ここに述べた配信スケジュール情報（の解析結果）を用いた処理は一例であって、リソースファイルの配信に応じた各種の処理を行うことができる。
【０１８１】
ステップＳ２２１において、ブラウザ２０９は、ステップＳ２０６の処理で通知されたスタートアップページURLに応じて、プロキシサーバ２１２に対し、スタートアップページファイルを要求する。
【０１８２】
ステップＳ２０７において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイルの要求に応じて、返答の準備がなされているスタートアップページファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からのスタートアップページファイルを取得することができる。
【０１８３】
ステップＳ２２２において、ブラウザ２０９は、プロキシサーバ２１２に対し、スタートアップページファイルに同梱されたスタートアップページファイル内のリソースファイルを要求する。
【０１８４】
ステップＳ２０８において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイル内リソースファイルの要求に応じて、返答の準備がなされているスタートアップページファイルに同梱されたスタートアップページファイル内のリソースファイルを、ブラウザ２０９に返答する。
【０１８５】
ステップＳ２２３において、ブラウザ２０９は、プロキシサーバ２１２から取得されたスタートアップページファイル及びそのスタートアップページファイル内のリソースファイルに基づいて、レンダラ２１３を介してスタートアップページファイルを提示する。これにより、アプリケーション（のスタートアップページ）が、放送番組などのコンテンツとともに表示される。
【０１８６】
ステップＳ２０９において、放送ミドルウェア２０５は、ステップＳ２０１の処理で取得されたSLSシグナリング（S-TSIDメタデータ）に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信されるEFDTを取得する。
【０１８７】
ステップＳ２１０において、放送ミドルウェア２０５は、ステップＳ２０９の処理で取得されたEFDTをパースする。なお、ステップＳ２０９の処理で取得されたEFDTのバージョン（例えばVer2.0）は、ステップＳ２０２の処理で取得されたEFDTのバージョン（例えばVer1.0）よりも新しいものとする。また、EFDTの転送制御属性として、転送制御情報（図１３）が記述されている場合、放送ミドルウェア２０５又は処理部２０１（制御部２１１）は、転送制御情報を解析して、その解析結果に応じた処理を行うことができる。例えば、転送制御情報（図１３）は、特定のリソースファイルの再送周期や再送終了日時が記述されるので、放送ミドルウェア２０５は、この再送周期や再送終了日時に応じて、再送される特定のリソースファイルを取得することができる。
【０１８８】
ステップＳ２１１において、放送ミドルウェア２０５は、ステップＳ２１０の解析結果に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信される追加リソースファイルを取得する。
【０１８９】
一方で、ブラウザ２０９では、追加リソースファイルの提示タイミングが監視される（Ｓ２２４）。ステップＳ２２５において、ブラウザ２０９は、ステップＳ２２４の監視結果に基づいて、追加リソースファイルの提示タイミングが検知されたかどうかを判定する。
【０１９０】
ここでは、例えば、スタートアップページファイル内に、すべてのリソースファイルの提示タイミングが（番組全体にわたって）スケジューリングされている場合には、そのタイミングでタイマが発火するようにスクリプトをプログラムすることで、追加リソースファイルを提示するタイミングを検知することができる。また、スタートアップページファイルが、外部からのイベント（例えばコンテンツストリームにインバンドで転送されるアプリケーションサーバ１０３が発行するストリームイベント、又はユーザとのインタラクション）を持つようにスクリプトをプログラムすることで、追加リソースを提示するタイミングを検知することができる。
【０１９１】
これらのいずれにより検知する場合も、番組全体に渡って同一のスタートアップページファイルであればよく、スタートアップページファイルの更新は不要である。すなわち、スタートアップパッケージファイル内のスタートアップページファイルの更新はないため、常に、アプリケーションマニフェストファイル、スタートアップページファイル、スタートアップページファイル内で最初に参照されるリソースファイル（例えば、Resource1，Resource2，Resource3）は更新されないため、スタートアップパッケージファイルそのものの更新がないからである。
【０１９２】
ステップＳ２２５において、追加リソースファイルの提示タイミングが検知されていないと判定された場合、処理は、ステップＳ２２４に戻り、ステップＳ２２４乃至Ｓ２２５の監視処理が繰り返される。そして、ステップＳ２２５において、追加リソースファイルの提示タイミングが検知されたと判定された場合、処理は、ステップＳ２２６に進められる。
【０１９３】
ステップＳ２２６において、ブラウザ２０９は、ステップＳ２２５の処理の（提示タイミング検知の）検知結果に応じて、プロキシサーバ２１２に対し、追加リソースファイルを要求する。
【０１９４】
ステップＳ２１２において、プロキシサーバ２１２は、ブラウザ２０９からの追加リソースファイル要求に応じて、返答の準備がなされている追加リソースファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からの追加リソースファイルを取得することができる。
【０１９５】
ステップＳ２２７において、ブラウザ２０９は、レンダラ２１３を制御して、プロキシサーバ２１２から取得された追加リソースファイルを提示する。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
【０１９６】
以上、受信側の処理の流れについて説明した。
【０１９７】
（Ｂ）ハイブリッドモード
次に、図１９乃至図２２を参照して、配信モードとして、ハイブリッドモードが設定された場合について説明する。
【０１９８】
（ハイブリッドモード時のデータの流れ）
図１９は、クライアント装置２０（図１）において、ハイブリッドモードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図１９のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
【０１９９】
図１９において、クライアント装置２０では、上述した図１５のＳ１１（放送モード）と同様に、EFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ２１）。
【０２００】
このスタートアップパッケージファイルには、当該スタートアップパッケージファイルを識別するスタートアップパッケージURLが記述されるほかに、アプリケーションマニフェストファイルと、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）が同梱されている。
【０２０１】
これにより、シーン１（図１４）においては、スタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
【０２０２】
シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、シーン２の後段のパートで提示されるリソースファイル（Resource5）のURLのみが記述される。
【０２０３】
すなわち、図１９の例では、リソースファイル（Resource5）は、放送経由で配信される一方で、リソースファイル（Resource4）は、通信経由で配信されるので、Ver2.0のEFDTには、放送経由で配信されるリソースファイル（Resource5）に関する情報のみが記述される。
【０２０４】
そして、Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ２２）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource4）や、放送経由で配信されるリソースファイル（Resource5）が取得される（Ｓ２３，Ｓ２４）。
【０２０５】
ただし、通信経由で配信されるリソースファイル（Resource4）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイル（Resource4）のファイルURLが用いられる。また、放送経由で配信されるリソースファイル（Resource5）のリソースファイルURLは、Ver2.0のEFDTに記述されるリソースファイルURLが用いられる。
【０２０６】
これにより、シーン２（図１４）の前段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）が提示される。また、シーン２（図１４）の後段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4）の消去と、放送経由で配信されるリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
【０２０７】
さらに、シーン２からシーン３に遷移する間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLのみが記述される。
【０２０８】
そして、Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ２５）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource N）が取得される（Ｓ２６）。
【０２０９】
ただし、通信経由で配信されるリソースファイル（Resource N）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイルのファイルURLを用いることができる。
【０２１０】
これにより、シーン３では、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。
【０２１１】
次に、図２０乃至図２２のフローチャートを参照して、ハイブリッドモードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
【０２１２】
（送信側の処理の流れ）
最初に、図２０のフローチャートを参照して、送信側システム１０により実行される、ハイブリッドモードが設定された場合の送信側の処理の流れについて説明する。
【０２１３】
図２０のステップＳ３２１乃至Ｓ３２２においては、図１６のステップＳ３０１乃至Ｓ３０２と同様に、アプリケーションサーバ（図１）によって、オーサリング処理が行われ、アプリケーションを構成するファイル群が生成される。
【０２１４】
図２０のステップＳ４２１乃至Ｓ４２９においては、図１６のステップＳ４０１乃至Ｓ４０８と同様に、SCH/PKGサーバ１０４（図１）によって、配信スケジュールの決定と、EFDTの生成と、スタートアップパッケージファイルの生成の処理が行われるが、追加リソースファイルの転送先に、放送サーバ１０５だけでなく、通信サーバ１０６が含まれる点が異なっている。
【０２１５】
すなわち、ステップＳ４２８において、SCH/PKGサーバ１０４は、ステップＳ３２１の処理で生成されたファイル群のうち、追加リソースファイルの一部を、放送サーバ１０５に転送する。また、ステップＳ４２９において、SCH/PKGサーバ１０４は、ステップＳ３２１の処理で生成されたファイル群のうち、追加リソースファイルの一部を、通信サーバ１０６に転送する。
【０２１６】
ステップＳ５２１乃至Ｓ５２４においては、図１６のステップＳ５０１乃至Ｓ５０４と同様に、放送サーバ１０５（図１）によって、EFDTと追加リソースファイルがファイルモードで、スタートアップパッケージファイルがパッケージモードで、伝送路８０を介して送信（一斉同報配信）される。
【０２１７】
図２０のステップＳ６２１乃至Ｓ６２２は、通信サーバ１０６（図１）により実行される。また、通信サーバ１０６においては、ステップＳ４２９の処理で転送された追加リソースファイルが受信される。
【０２１８】
ステップＳ６２１において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０から追加リソースファイルが要求されたかどうかを判定する。ステップＳ６２１において、追加リソースファイルが要求されていないと判定された場合、ステップＳ６２１の判定処理が繰り返される。
【０２１９】
一方で、ステップＳ６２１において、追加リソースファイルが要求されたと判定された場合、処理は、ステップＳ６２２に進められる。ステップＳ６２２において、通信サーバ１０６は、ステップＳ４２９の処理で転送された追加リソースファイル（ステップＳ３２１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
【０２２０】
以上、送信側の処理の流れについて説明した。
【０２２１】
（受信側の処理の流れ）
次に、図２１及び図２２のフローチャートを参照して、クライアント装置２０により実行される、ハイブリッドモードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理が実行される前提として、上述した図１７及び図１８と同様に、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
【０２２２】
図２１のステップＳ２３１乃至Ｓ２３８においては、図１７のステップＳ２０１乃至Ｓ２０８と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTとスタートアップパッケージファイルが処理され、スタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されている場合には、当該スタートアップページURLが、ブラウザ２０９に通知される。また、プロキシサーバ２１２によって、ブラウザ２０９からの要求に応じて、スタートアップページファイルとそのスタートアップファイル内のリソースファイルが返答される。
【０２２３】
また、図２１のステップＳ２５１乃至Ｓ２５３においては、図１７のステップＳ２２１乃至Ｓ２２３と同様に、ブラウザ２０９によって、スタートアップページファイルとそのスタートアップファイル内のリソースファイルが要求され、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、スタートアップページが提示される。
【０２２４】
図２２のステップＳ２３９乃至Ｓ２４２においては、図１８のステップＳ２０９乃至Ｓ２１２と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTと追加リソースファイルが処理される。また、プロキシサーバ２１２によって、ブラウザ２０９からの要求に応じて、追加リソースファイルが返答される。
【０２２５】
また、図２２のステップＳ２５４乃至Ｓ２５７においては、図１８のステップＳ２２４乃至Ｓ２２７と同様に、ブラウザ２０９によって、放送経由で配信される追加リソースファイルの提示タイミングが監視され、その提示タイミングになったとき、追加リソースファイルが要求される。また、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、追加リソースファイルが提示される。
【０２２６】
このようにして、放送サーバ１０５から放送経由で配信される追加リソースファイルが提示される。一方で、追加リソースファイルが、通信サーバ１０６から通信経由で配信される場合、以下のように処理される。
【０２２７】
すなわち、図２２のステップＳ２５８において、ブラウザ２０９は、通信経由で配信される追加リソースファイルの提示タイミングを監視する。ステップＳ２５９において、ブラウザ２０９は、ステップＳ２５８の監視結果に基づいて、通信経由で配信される追加リソースファイルの提示タイミングが検知されたかどうかを判定する。
【０２２８】
ステップＳ２５９において、追加リソースファイルの提示タイミングが検知されていないと判定された場合、処理は、ステップＳ２５８に戻り、ステップＳ２５８乃至Ｓ２５９の監視処理が繰り返される。そして、ステップＳ２５９において、追加リソースファイルの提示タイミングが検知されたと判定された場合、処理は、ステップＳ２６０に進められる。
【０２２９】
ステップＳ２６０において、ブラウザ２０９は、ステップＳ２５９の処理の（提示タイミング検知の）検知結果に応じて、プロキシサーバ２１２に対し、追加リソースファイルを要求する。
【０２３０】
ステップＳ２４３において、プロキシサーバ２１２は、ブラウザ２０９からの追加リソースファイルの要求に応じて、インターネット９０を介して通信サーバ１０６に対し、追加リソースファイルを要求する。ステップＳ２４４において、プロキシサーバ２１２は、ステップＳ２４３の要求に応じて、インターネット９０を介して通信サーバ１０６から配信される追加リソースファイルを取得する。
【０２３１】
ステップＳ２４５において、プロキシサーバ２１２は、ステップＳ２４４の処理で取得した追加リソースファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からの追加リソースファイルを取得することができる。
【０２３２】
ステップＳ２６１において、ブラウザ２０９は、レンダラ２１３を制御して、プロキシサーバ２１２から取得された追加リソースファイルを提示する。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
【０２３３】
以上、受信側の処理の流れについて説明した。
【０２３４】
（Ｃ）通信モード
最後に、図２３乃至図２６を参照して、配信モードとして、通信モードが設定された場合について説明する。
【０２３５】
（通信モード時のデータの流れ）
図２３は、クライアント装置２０（図１）において、通信モードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図２３のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
【０２３６】
図２３において、クライアント装置２０では、上述した図１５のＳ１１（放送モード）と同様に、EFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ３１）。
【０２３７】
このスタートアップパッケージファイルには、当該スタートアップパッケージファイルを識別するスタートアップパッケージURLが記述されるほかに、アプリケーションマニフェストファイルが含まれる。
【０２３８】
アプリケーションマニフェストファイルには、スタートアップページURLのほか、配信スケジュール情報として、各リソースファイルのファイルURLが記述されている。クライアント装置２０は、これらのURLに従い、インターネット９０を介して通信サーバ１０６にアクセスすることで、通信経由で配信される、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）を取得することができる。
【０２３９】
これにより、シーン１（図１４）においては、スタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
【０２４０】
シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLが記述される。すなわち、通信モードでは、シーン２の前段のパートと後段のパートで提示されるリソースファイル（Resource4，Resource5）が共に通信経由で配信されるため、Ver2.0のEFDTには、リソースファイルのURLは不要とされる。
【０２４１】
そして、Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ３２）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource4，Resource5）が取得される（Ｓ３３，Ｓ３４）。
【０２４２】
ただし、通信経由で配信されるリソースファイル（Resource4，Resource5）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイル（Resource4，Resource5）のファイルURLが用いることができる。
【０２４３】
これにより、シーン２（図１４）の前段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）が提示される。また、シーン２（図１４）の後段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4）の消去と、通信経由で配信されるリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
【０２４４】
さらに、シーン２からシーン３に遷移する間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLのみが記述される。
【０２４５】
そして、Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ３５）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource N）が取得される（Ｓ３６）。
【０２４６】
ただし、通信経由で配信されるリソースファイル（Resource N）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイルのファイルURLを用いることができる。
【０２４７】
これにより、シーン３では、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。
【０２４８】
次に、図２４乃至図２６のフローチャートを参照して、通信モードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
【０２４９】
（送信側の処理の流れ）
最初に、図２４のフローチャートを参照して、送信側システム１０により実行される、通信モードが設定された場合の送信側の処理の流れについて説明する。
【０２５０】
図２４のステップＳ３４１乃至Ｓ３４２においては、図１６のステップＳ３０１乃至Ｓ３０２と同様に、アプリケーションサーバ（図１）によって、オーサリング処理が行われ、アプリケーションを構成するファイル群が生成される。
【０２５１】
図２４のステップＳ４２１乃至Ｓ４２７においては、図１６のステップＳ４０１乃至Ｓ４０８と同様に、SCH/PKGサーバ１０４（図１）によって、配信スケジュールの決定と、EFDTの生成と、スタートアップパッケージファイルの生成の処理が行われるが、スタートアップページファイルとそのスタートアップページファイル内のリソースファイル、追加リソースファイルの転送先が、放送サーバ１０５ではなく、通信サーバ１０６となる点が異なっている。
【０２５２】
図２４のステップＳ５４１乃至Ｓ５４２においては、図１６のステップＳ５０１乃至Ｓ５０２と同様に、放送サーバ１０５（図１）によって、EFDTがファイルモードで、スタートアップパッケージファイルがパッケージモードで、伝送路８０を介して送信（一斉同報配信）される。
【０２５３】
図２４のステップＳ６４１乃至Ｓ６４６は、通信サーバ１０６（図１）により実行される。また、通信サーバ１０６においては、ステップＳ４４６の処理で転送されたスタートアップページファイルとそのスタートアップページファイル内のリソースファイルと、ステップＳ４４７の処理で転送された追加リソースファイルが受信される。
【０２５４】
図２４のステップＳ６４１乃至Ｓ６４６においては、図２０のステップＳ６２１乃至Ｓ６２２と同様に、インターネット９０を介したクライアント装置２０からの要求に応じて、各種のファイルが配信される。
【０２５５】
ステップＳ６４１において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０からスタートアップページファイルが要求されたかどうかを判定する。ステップＳ６４１において、スタートアップページファイルが要求されていないと判定された場合、ステップＳ６４１の判定処理が繰り返される。
【０２５６】
一方で、ステップＳ６４１において、スタートアップページファイルが要求されたと判定された場合、処理は、ステップＳ６４２に進められる。ステップＳ６４２において、通信サーバ１０６は、ステップＳ４４６の処理で転送されたスタートアップページファイル（ステップＳ３４１の処理で生成されたスタートアップページファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
【０２５７】
ステップＳ６４３において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０からスタートアップページファイル内リソースファイルが要求されたかどうかを判定する。ステップＳ６４３において、スタートアップページファイル内リソースファイルが要求されていないと判定された場合、ステップＳ６４３の判定処理が繰り返される。
【０２５８】
一方で、ステップＳ６４３において、スタートアップページファイル内リソースファイルが要求されたと判定された場合、処理は、ステップＳ６４４に進められる。ステップＳ６４４において、通信サーバ１０６は、ステップＳ４４６の処理で転送されたスタートアップページファイル内リソースファイル（ステップＳ３４１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
【０２５９】
ステップＳ６４５において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０から追加リソースファイルが要求されたかどうかを判定する。ステップＳ６４５において、追加リソースファイルが要求されていないと判定された場合、ステップＳ６４５の判定処理が繰り返される。
【０２６０】
一方で、ステップＳ６４５において、追加リソースファイルが要求されたと判定された場合、処理は、ステップＳ６４６に進められる。ステップＳ６４６において、通信サーバ１０６は、ステップＳ４４７の処理で転送された追加リソースファイル（ステップＳ３４１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
【０２６１】
以上、送信側の処理の流れについて説明した。
【０２６２】
（受信側の処理の流れ）
次に、図２５及び図２６のフローチャートを参照して、クライアント装置２０により実行される、通信モードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理が実行される前提として、上述した図１７及び図１８と同様に、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
【０２６３】
図２５のステップＳ２７１乃至Ｓ２７５においては、図１７のステップＳ２０１乃至Ｓ２０５と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTとスタートアップパッケージファイルが処理され、スタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されているかどうかが判定される（Ｓ２７５）。
【０２６４】
ステップＳ２７５において、アプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されていると判定された場合、処理は、ステップＳ２７６に進められる。
【０２６５】
ステップＳ２７６において、プロキシサーバ２１２は、ステップＳ２７５の判定結果に応じて、インターネット９０を介して通信サーバ１０６に対し、スタートアップページファイルを要求する。ステップＳ２７７において、プロキシサーバ２１２は、ステップＳ２７６の要求に応じて、インターネット９０を介して通信サーバ１０６から配信されるスタートアップページファイルを取得する。
【０２６６】
ステップＳ２７８において、プロキシサーバ２１２は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに記述されるスタートアップページURLを、ブラウザ２０９に通知する。
【０２６７】
ステップＳ２９１において、ブラウザ２０９は、ステップＳ２７８の処理で通知されたスタートアップページURLに応じて、プロキシサーバ２１２に対し、スタートアップページファイルを要求する。
【０２６８】
ステップＳ２７９において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイルの要求に応じて、返答の準備がなされているスタートアップページファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からのスタートアップページファイルを取得することができる。
【０２６９】
ステップＳ２９２において、ブラウザ２０９は、プロキシサーバ２１２に対し、スタートアップページファイル内のリソースファイルを要求する。
【０２７０】
ステップＳ２８０において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイル内のリソースファイルの要求に応じて、インターネット９０を介して通信サーバ１０６に対し、スタートアップページファイル内のリソースファイルを要求する。ステップＳ２８１において、プロキシサーバ２１２は、ステップＳ２８０の要求に応じて、インターネット９０を介して通信サーバ１０６から配信されるスタートアップページファイル内のリソースファイルを取得する。
【０２７１】
ステップＳ２８２において、プロキシサーバ２１２は、ステップＳ２８１の処理で取得されたスタートアップページファイル内のリソースファイルを、ブラウザ２０９に返答する。
【０２７２】
ステップＳ２９３において、ブラウザ２０９は、プロキシサーバ２１２から取得されたスタートアップページファイル及びそのスタートアップページファイル内のリソースファイルに基づいて、スタートアップページを提示する。これにより、アプリケーションが、放送番組などのコンテンツとともに表示される。
【０２７３】
図２６のステップＳ２９４乃至Ｓ２９６は、図２２のステップＳ２５８乃至Ｓ２６０と同様に、ブラウザ２０９によって、通信経由で配信される追加リソースファイルの提示タイミングが監視され、その提示タイミングになったとき、追加リソースファイルが要求される。
【０２７４】
図２６のステップＳ２８３乃至Ｓ２８５は、図２２のステップＳ２４３乃至Ｓ２４５と同様に、プロキシサーバ２１２によって、インターネット９０を介して通信サーバ１０６から追加リソースファイルが取得され、返答される。また、図２６のステップＳ２９７は、図２２のステップＳ２６１と同様に、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、追加リソースファイルが提示される。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
【０２７５】
以上、受信側の処理の流れについて説明した。
【０２７６】
＜４．シグナリングの例＞
【０２７７】
次に、図２７乃至図３１を参照して、シグナリングのフォーマットの例を説明する。
【０２７８】
（USDのフォーマット）
図２７は、XML形式のUSDメタデータのフォーマットの例を示す図である。なお、図２７において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシグナリングのフォーマットでも同様とされる。
【０２７９】
bundleDescription要素は、ルート要素であって、userServiceDescription要素（USD要素）の上位要素となる。このuserServiceDescription要素は、serviceId属性、atsc:serviceId属性、atsc:fullMPDUri属性、atsc:sTSIDUri属性、name要素、serviceLanguage要素、atsc:capabilityCode要素、及び、deliveryMethod要素の上位要素となる。
【０２８０】
serviceId属性とatsc:serviceId属性には、サービスIDが指定される。atsc:fullMPDUri属性には、MPDメタデータを参照するためのURIが指定される。atsc:sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。なお、S-TSIDメタデータのフォーマットの詳細は、後述する図２８を参照して説明する。
【０２８１】
name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。atsc:capabilityCode要素には、機能に関するコードが指定される。
【０２８２】
deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、atsc:broadcastAppService要素及びatsc:unicastAppService要素の上位要素となる。atsc:broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。atsc:unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
【０２８３】
（S-TSIDのフォーマット）
図２８は、XML形式のS-TSIDメタデータのフォーマットの例を示す図である。
【０２８４】
S-TSID要素は、ルート要素であって、RS要素の上位要素となる。RS要素には、ROUTEセッションに関する情報が指定される。RS要素は、bsid属性、sIpAddr属性、dIpAddr属性、dport属性、PLPID属性、及び、LS要素の上位要素となる。
【０２８５】
bsid属性には、ブロードキャストストリームIDが指定される。sIpAddr属性には、送信元（source）のIPアドレスが指定される。dIpAddr属性には、宛先（destination）のIPアドレスが指定される。dport属性には、宛先（destination）のポート番号が指定される。PLPID属性には、ROUTEセッションのPLPのIDが指定される。
【０２８６】
LS要素には、LCTセッションに関する情報が指定される。LS要素は、tsi属性、PLPID属性、bw属性、startTime属性、endTime属性、SrcFlow要素、及び、RprFlow要素の上位要素となる。
【０２８７】
tsi属性には、TSIが指定される。PLPID属性には、PLPのIDが指定される。bw属性には、帯域幅が指定される。startTime属性とendTime属性には、開始日時と終了日時が指定される。SrcFlow要素には、ソースフロー情報が指定される。
【０２８８】
ここで、図２９には、図２８のS-TSIDメタデータに含まれるSrcFlow要素のフォーマットが示されている。
【０２８９】
図２９のSrcFlow要素は、rt属性、minBuffSize属性、EFDT要素、ContentInfo要素、及び、Payload要素の上位要素となる。
【０２９０】
minBuffSize属性には、クライアント装置２０が必要とする最小バッファサイズが指定される。EFDT要素には、拡張されたFDT（Extended FDT）に関する情報が指定される。ContentInfo要素には、コンテンツに関する情報が指定される。
【０２９１】
Payload要素は、codePoint属性、formatID属性、frag属性、order属性、srcFecPayloadID属性、及び、FECParams属性の上位要素であって、ソースフローのオブジェクトを格納するROUTEパケットのペイロードに関する情報が指定される。
【０２９２】
なお、formatID属性の値により、ファイルモード（単一のファイルを格納する構造）又はパッケージモード（複数のファイルを同梱する構造）が区別される。すなわち、Payload要素の属性であるcodePoint属性の値は、ファイルを分割して運ぶLCTパケットヘッダのCodePointに等しくなる。このCodePointの値によって、Payload要素の属性の値の組（Payload@formatID，Payload@frag，Payload@order，Payload@srcFecPayloadIDの値の組）を一意に指定することができるようになっている。
【０２９３】
すなわち、LCTパケットのTSI(Transport Session Identifier)の値により、S-TSIDの中の該当するLCTチャネル（セッション）の記述を検索し（S-TSID/RS/LS@tsi）、さらに、当該LSのSrcFlow/Payload@codePointの値と、LCTパケットヘッダのCodePointの値がマッチするPayload属性を検索する。そして、検索されたPayload属性の属性として記述されるformatID属性の値により、そのLCTパケットが運ぶファイルが、ファイルモードであるのか、あるいはパッケージモードであるのかが区別されることになる。
【０２９４】
ここで、図３０には、図２９のSrcFlow要素に含まれるEFDT要素のフォーマットが示されている。図３０のEFDT要素は、tsi属性、idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、FileTemplate属性、及び、FDTParameters属性の上位要素となる。
【０２９５】
EFDT要素のtsi属性の値で示されるROUTEプロトコルのLCTチャネル（セッション）には、EFDT（のファイル）と、そのEFDTにより記述されるファイル群が転送される。EFDT（のファイル）と、EFDTにより参照されるファイル群が転送されるLCTチャネル（セッション）において、EFDTは、TOI(Transport Object Identifier) = 0がアサインされる一方で、その他のファイル群のTOIは、EFDT内に記述される。
【０２９６】
ここで、EFDT要素は、図３０に示した構造を有し、ルート要素は、FDT-Instanceと呼ばれ、FDT-Instance型を持っている。このFDT-Instanceの中には、複数のFile要素が存在し、それぞれのファイルの転送制御属性が記述される。この転送制御属性の主なものとしては、例えば、ファイル名であるContent-Locationや、転送上の識別子であるTOIなどがある。
【０２９７】
図３１には、EFDTのXMLスキーマの例が図示されている。図３１においては、枠Ａ内に、リソースファイルの再送周期（Retransmission-Cycle）の属性（図１３）と、リソースファイルの再送終了日時（Retransmission-End）の属性（図１３）が定義されている。
【０２９８】
＜５．変形例＞
【０２９９】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０３００】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
【０３０１】
また、上述したシグナリングなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングなどの実質的な内容が異なるものではない。例えば、AST(Application Signaling Table)は、AIT(Application Information Table)などと称される場合がある。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
【０３０２】
また、上述した説明では、LLSシグナリングとして、SLTメタデータを説明したが、LLSシグナリングには、EAT(Emergency Alerting Table)やRRT(Region Rating Table)などのメタデータが含まれるようにしてもよい。EATメタデータは、緊急に告知する必要がある緊急情報に関する情報を含む。RRTメタデータは、レーティングに関する情報を含む。
【０３０３】
なお、アプリケーションは、HTML5等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、上述したコンテンツには、動画や広告のほか、例えば、電子書籍やゲーム、音楽など、あらゆるコンテンツを含めることができる。
【０３０４】
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。
【０３０５】
＜６．コンピュータの構成＞
【０３０６】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３０７】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０３０８】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
【０３０９】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０３１０】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３１１】
コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０３１２】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３１３】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３１４】
また、本技術は、以下のような構成をとることができる。
【０３１５】
（１）
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、
取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部と
を備える受信装置。
（２）
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
（１）に記載の受信装置。
（３）
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
（２）に記載の受信装置。
（４）
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
（２）に記載の受信装置。
（５）
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
（４）に記載の受信装置。
（６）
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSID(Service-based Transport Session Instance Description)により特定される、ROUTEセッションで伝送されるEFDT(Extended FDT)に含まれる
（４）又は（５）に記載の受信装置。
（７）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、
取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う
ステップを含むデータ処理方法。
（８）
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
（７）に記載のデータ処理方法。
（９）
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
（８）に記載のデータ処理方法。
（１０）
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
（８）に記載のデータ処理方法。
（１１）
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
（１０）に記載のデータ処理方法。
（１２）
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
（１０）又は（１１）に記載のデータ処理方法。
（１３）
コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、
前記コンテンツとともに、前記リソース配信情報を送信する送信部と
を備える送信装置。
（１４）
前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
（１３）に記載の送信装置。
（１５）
前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
（１４）に記載の送信装置。
（１６）
前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
（１４）に記載の送信装置。
（１７）
前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
（１６）に記載の送信装置。
（１８）
前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
（１６）又は（１７）に記載の送信装置。
（１９）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成し、
前記コンテンツとともに、前記リソース配信情報を送信する
ステップを含むデータ処理方法。
【符号の説明】
【０３１６】
１  伝送システム，  １０  送信側システム，  ２０  クライアント装置，  ８０  伝送路，  ９０  インターネット，  １０１  DASHサーバ，  １０２  シグナリングサーバ，  １０３  アプリケーションサーバ，  １０４  SCH/PKGサーバ，  １０５  放送サーバ，  １０６  通信サーバ，  ２０１  処理部２０１，  ２０２  入力部，  ２０３  メモリ，  ２０４  受信部，  ２０５  放送ミドルウェア，  ２０６  DASHクライアント，  ２０７  デコーダ，  ２０８  出力部，  ２０９  ブラウザ，  ２１０  通信部，  ２１１  制御部，  ２１２  プロキシサーバ，  ２１３  レンダラ，  １０００  コンピュータ，  １００１  CPU
【図１】
2017141701.tif 000003
【図２】
2017141701.tif 000004
【図３】
2017141701.tif 000005
【図４】
2017141701.tif 000006
【図５】
2017141701.tif 000007
【図６】
2017141701.tif 000008
【図７】
2017141701.tif 000009
【図８】
2017141701.tif 000010
【図９】
2017141701.tif 000011
【図１０】
2017141701.tif 000012
【図１１】
2017141701.tif 000013
【図１２】
2017141701.tif 000014
【図１３】
2017141701.tif 000015
【図１４】
2017141701.tif 000016
【図１５】
2017141701.tif 000017
【図１６】
2017141701.tif 000018
【図１７】
2017141701.tif 000019
【図１８】
2017141701.tif 000020
【図１９】
2017141701.tif 000021
【図２０】
2017141701.tif 000022
【図２１】
2017141701.tif 000023
【図２２】
2017141701.tif 000024
【図２３】
2017141701.tif 000025
【図２４】
2017141701.tif 000026
【図２５】
2017141701.tif 000027
【図２６】
2017141701.tif 000028
【図２７】
2017141701.tif 000029
【図２８】
2017141701.tif 000030
【図２９】
2017141701.tif 000031
【図３０】
2017141701.tif 000032
【図３１】
2017141701.tif 000033
【図３２】
2017141701.tif 000034
【国際調査報告】
2017141701.tif 000035
2017141701.tif 000036
2017141701.tif 000037
2017141701.tif 000038