WO2016203850A1 - 受信装置、送信装置、およびデータ処理方法 - Google Patents

Abstract

受信装置において適用する再生アプリを、事前に受信可能なＳＬＴに記録したサービスカテゴリ識別子を用いて決定可能な構成を実現する。送信装置の提供番組等、提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信装置に送信する。サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なう。サービスカテゴリ識別子は、レジデンシャル再生アプリ、ブロードキャスト再生アプリ、これらのいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である。

Description

受信装置、送信装置、およびデータ処理方法

　本開示は、受信装置、送信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの受信または送信を実行する受信装置、送信装置、および通信データ対応のデータ処理方法に関する。

　画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ　Ｔｈｅ　Ｔｏｐ）がある。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ－Ｖ（Ｏｖｅｒ　Ｔｈｅ　Ｔｏｐ　Ｖｉｄｅｏ）と呼ばれる。

　ＯＴＴ－Ｖに従ったデータストリーミング配信規格としてＤＡＳＨ（Ｄｙｎａｍｉｃ　Ａｄａｐｔｉｖｅ　Ｓｔｒｅａｍｉｎｇ　ｏｖｅｒＨＴＴＰ）規格がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。

　アダプティブ（適応型）ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）を記述したマニフェスト・ファイルを作成し、クライアントに提供する。

　クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１－８７１０３号公報）に記載がある。

　放送局やその他のコンテンツサーバ等の送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
　なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献２（特開２０１４－０５７２２７号公報）がある。

　放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０の規格化が進行中である。
　ＡＴＳＣ３．０では、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ－ＰＨＹ）を実装した受信装置に、ＡＴＳＣ３．０放送の受信処理等を実行するミドルウェアを実装させることで、ＡＴＳＣ放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。

　具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。

　例えば、家庭内やホットスポットに設置された放送サービスを受信するサーバ（専用サーバの他、ＰＣ、ＴＶ、タブレット、スマホ等）にＡＴＳＣ３．０準拠物理層（ＡＴＳＣ－ＰＨＹ）、ならびに、ＡＴＳＣ３．０放送受信ミドルウェアを実装する。
　これらのサーバが、いったんＡＴＳＣ３．０放送サービスを受信した後、ネットワーク（ホームネットワークやホットスポット等のＬＡＮ／ＷｉＦｉ等）を介して、ユーザ装置（ＰＣ、ＴＶ、タブレット、スマホ等）に放送受信データを転送する。

　サーバを介して転送された放送受信データを入力したユーザ装置は、ユーザ装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０　ＤＡＳＨクライアントアプリケーション）を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。

　放送番組を送信する放送局等の放送サーバは、ユーザ装置であるＴＶ等の受信装置（クライアント）に対して、番組データ（放送コンテンツ）のみならず、番組データの再生処理を実行するアプリケーション（再生アプリ、プレーヤアプリ等と呼ばれる）を提供することも可能である。

　例えば、放送局Ａが、放送局Ａの提供コンテンツの再生にのみ適用可能な再生アプリａを受信装置（クライアント）に放送波等を介して提供する。
　受信装置（クライアント）は、再生アプリａを受信して、受信した再生アプリａを適用した再生処理によって、放送局Ａの提供コンテンツの再生を行なうことができる。
　放送局Ｂは、再生アプリａとは異なる再生アプリｂを提供し、放送局Ｂの提供コンテンツの再生を行なう場合には、再生アプリｂを利用して再生を行なう。

　さらに、放送サーバは、放送局単位の再生アプリケーションではなく、特定の番組単位の再生アプリを提供することもできる。受信装置（クライアント）は、特定番組の再生時に、送信装置から受信した番組対応の再生アプリを適用して番組再生を行なう。

　しかし、テレビ等の受信装置（クライアント）は、本来、受信装置の製造時に装置に内蔵された再生アプリ、いわゆるレジデンシャル（常駐型）の再生アプリケーションを保持し、通常の番組再生には、チャンネル設定とは無関係に１つのレジデンシャル再生アプリケーションを利用して再生をするというのがこれまでのテレビ等の受信装置（クライアント）の一般的な処理である。

　今後、上記のように、放送サーバが、放送局単位、あるいは番組単位で再生アプリを提供すると、受信装置（クライアント）は、各番組の再生に適用する再生アプリケーションを、複数の再生アプリケーションから選択して利用することが必須となる。
　受信装置が、放送局あるいは番組対応の正しい再生アプリケーションの取得や選択に失敗すると、正しい番組再生ができないといった事態が発生する。

　例えば、ある放送局の提供する番組の再生に適用すべき再生アプリが、その放送局が配信する放送局提供アプリに限定される場合に、受信装置が誤ってレジデンシャル再生アプリを利用してしまった場合等には、正しい番組再生ができないといった事態が発生する。
　しかし、現状において、再生アプリの提供処理や、受信装置における再生アプリ取得、選択処理、利用処理等の構成について、まだ、具体的な仕様が定まっていないというのが現状である。

特開２０１１－８７１０３号公報 特開２０１４－０５７２２７号公報

　本開示は、例えば上記問題点に鑑みてなされたものであり、放送局や、放送番組等に対応した再生アプリを受信装置に提供する構成において、再生アプリの適正な選択、や利用処理を実現可能とした受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

　本開示の第１の側面は、
　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信する通信部と、
　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理部を有する受信装置にある。

　さらに、本開示の第２の側面は、
　受信装置において利用可能なサービスの構成データと、
　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
　前記サービスに適用するアプリケーションを送信する通信部を有する送信装置にある。

　さらに、本開示の第３の側面は、
　受信装置において実行するデータ処理方法であり、
　通信部が、
　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信し、
　データ処理部が、
　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理方法にある。

　さらに、本開示の第４の側面は、
　送信装置において実行するデータ処理方法であり、
　受信装置において利用可能なサービスの構成データと、
　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
　前記サービスに適用するアプリケーションを送信するデータ処理方法にある。

　本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

　本開示の一実施例の構成によれば、受信装置において適用する再生アプリを、事前に受信可能なＳＬＴに記録したサービスカテゴリ識別子を用いて決定可能な構成が実現される。
　具体的には、送信装置の提供番組等、提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信装置に送信する。サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なう。サービスカテゴリ識別子は、レジデンシャル再生アプリ、ブロードキャスト再生アプリ、これらのいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である。
　本構成により、受信装置において適用する再生アプリを、事前に受信可能なＳＬＴに記録したサービスカテゴリ識別子を用いて決定可能な構成が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。 送信装置から受信装置への送信データと、受信装置におけるデータ処理例について説明する図である。 送信装置から受信装置への送信データと、受信装置におけるデータ処理例について説明する図である。 受信装置の構成例について説明する図である。 受信装置の構成例について説明する図である。 送信装置から受信装置へ送信されるデータと、サービスリストテーブル（ＳＬＴ）について説明する図である。 サービスリストテーブル（ＳＬＴ）について説明する図である。 サービスカテゴリ識別子の設定例について説明する図である。 サービスカテゴリ識別子の設定例について説明する図である。 サービスカテゴリ識別子の設定例について説明する図である。 サービスカテゴリ識別子の設定例について説明する図である。 サービスカテゴリ識別子を用いた処理シーケンスについて説明するフローチャートを示す図である。 アプリケーション情報テーブル（ＡＩＴ）における配信アプリ識別フラグの設定構成について説明する図である。 アプリケーション情報テーブル（ＡＩＴ）に配信アプリ識別フラグを記述したＸＭＬデータの例について説明する図である。 配信アプリ識別フラグを用いた処理シーケンスについて説明するフローチャートを示す図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 送信装置から受信装置に対するデータ送信処理と、受信装置におけるアプリケーションを適用処理の実行シーケンスの一例について説明する図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

　以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．受信装置におけるアプリケーション選択処理と、アプリケーション適用処理の処理例について
　５．受信装置の構成例と処理例について
　６．放送局や番組等、サービス単位の制御情報、属性情報を通知するシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）について
　７．送信装置の提供サービスのサービスカテゴリ設定構成について
　８．アプリケーション情報テーブル（ＡＩＴ）に、ブロードキャスト再生アプリの適用情報を記録した構成について
　９．送信装置と受信装置の実行する処理の処理シーケンスについて
　９－１．（処理例１）受信装置において、レジデンシャル再生アプリを実行し、さらに、その後、ブロードキャストアプリケーションを併せて実行する処理例
　９－２．（処理例２）受信装置において、レジデンシャル再生アプリを実行し、その後、ＡＩＴ記述に基づいてブロードキャスト再生アプリを実行し、さらに次のＡＩＴ記述に基づいてレジデンシャル再生アプリを実行する処理例
　９－３．（処理例３）受信装置において、ＡＩＴ記述に基づいて、ブロードキャスト再生アプリを実行する処理例
　９－４．（処理例４）受信装置において、ＡＩＴ記述に基づいて、ブロードキャストアプリケーションを実行する処理例
　１０．送信装置と受信装置の構成例について
　１１．本開示の構成のまとめ

　　［１．通信システムの構成例について］
　まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
　図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを受信する通信装置である受信装置３０を有する。

　送信装置２０は、具体的には、例えば、主にＴＶ番組等のデータ（コンテンツ）を送信する放送サーバ（放送局）２１や、様々なデータを送信するデータ配信サーバ２２等、様々なデータ（放送番組、広告、その他のデータ）を提供する装置である。
　一方、受信装置３０は、例えば一般ユーザのクライアント装置であり、具体的には、テレビ３１、ＰＣ３２、携帯端末３３等によって構成される。
　なお、図１では、送信装置２０の例として、放送サーバ（放送局）２１、データ配信サーバ２２を区別して記載しているが、１つのサーバが放送番組、広告、その他のデータをすべて送信する構成としてもよい。

　送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。

　送信装置２０から受信装置３０に対するデータ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ－ＤＡＳＨ規格に従って実行する。
　ＭＰＥＧ－ＤＡＳＨ規格には、以下の２つの規格が含まれる。
　（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
　（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
　送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ－ＤＡＳＨ規格に従って実行する。

　送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。

　送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。

　送信装置２０の送信データについて図２を参照して説明する。
　ＭＰＥＧ－ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０

　ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。なお、ＡＶセグメントは、ＤＡＳＨセグメントとも呼ばれる。

　一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
　受信装置３０は、このシグナリングデータ５０を、再生対象となる番組コンテンツを格納したＡＶセグメント６０の受信に先行して受信することが必要となる。
　このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）形式のデータとして送信装置２０から送信される。

　シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
　これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
　クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。

　その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
　ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
　ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。

　ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。

　図２に示す以下のデータ、すなわち、
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
　これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）に従って送信される。

　　［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
　データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
　例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。

　受信装置（クライアント）３０は、例えば記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
　同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
　なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）等のプロトコルで記述することもできる。

　なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。

　従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ　Ｏｂｊｅｃｔ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）と呼ばれる。

　放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。

　　［３．送信装置と受信装置の実行する通信処理例について］
　次に、送信装置と受信装置の実行する通信処理例について説明する。
　図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
　図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
　（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
　（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）

　図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
　図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックである。

　図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
　（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）
　（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）
　（３）ＵＤＰレイヤ
　（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））

　なお、（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）の上位レイヤとしてシグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤが設定される。
　シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報などが含まれる。

　シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。

　シグナリングデータには、情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
　ＵＳＤには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ））がある。

　各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントやアプリケーション（アプリケーションプログラム）の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル（メタファイル）として設定され、送信装置から送信される。

　なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ　Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。

　（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
　（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
　（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。

　（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
　ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。
　図４に、ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す。

　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。

　ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ　Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）がある。
　ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。

　ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ－ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。

　先に図２を参照して説明した以下のデータ、すなわち、
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０
　これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。

　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。

　ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。

　ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
　前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
　Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。

　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。

　一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
　（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ　ＰＨＹ）
　（２）ＩＰユニキャストレイヤ（ＩＰ　Ｕｎｉｃａｓｔ）
　（３）ＴＣＰレイヤ
　（４）ＨＴＴＰレイヤ
　（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））

　（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ　ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
　（２）ＩＰユニキャストレイヤ（ＩＰ　Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
　（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
　この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。

　なお、送信装置（サーバ）２０、受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
　（ａ）ブロードキャスト通信（例えば放送型データ配信）
　（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
　これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。

　図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。

　前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０の規格化が進められている。
　ＡＴＳＣ３．０におけるＩＰベースのトランスポートスタックの標準化において、ＭＰＥＧ－ＤＡＳＨのファイルフォーマット（ＩＳＯ－ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルをＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）を拡張したＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ　Ｏｂｊｅｃｔ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法が提案され、標準候補方式として設定された。

　ＲＯＵＴＥプロトコルを適用することで、ＤＡＳＨ規格のフラグメント化されたＭＰ４（ｆｒａｇｍｅｎｔｅｄ　ＭＰ４）ファイルシーケンスと、ＤＡＳＨ規格の制御情報（シグナリングデータ）格納メタファイルであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ））、ならびに、放送配信のためのシグナリングデータであるＵＳＢＤ／ＵＳＤ、Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）等を転送することができる。

　前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ－ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。

　ＡＴＳＣ３．０サービスレイヤのシグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）として提案されているＵＳＢＤ／ＵＳＤ、Ｓ－ＴＳＩＤ、ＭＰＤ等はすべてＲＯＵＴＥセッションにより転送される。

　　［４．受信装置におけるアプリケーション選択処理と、アプリケーション適用処理の処理例について］
　次に、放送サーバ２１等の送信装置２０からデータを受信して、出力する受信装置（クライアント）３０における再生アプリケーション等のアプリケーション選択処理と、アプリケーション適用処理の処理例について説明する。

　受信装置３０は、受信装置の記憶部に、放送番組等のコンテンツの再生を実行する再生アプリケーションプログラム（レジデンシャル（常駐型）再生アプリ）を格納している。
　この再生アプリは、特定放送局専用型ではない従来からの再生アプリケーションであり、様々な放送局の提供番組（コンテンツ）の再生に適用可能である。

　放送サーバ（放送局）等の送信装置から提供される放送局対応の再生アプリや、番組対応の再生アプリの利用が要求されない場合、受信装置は、このレジデンシャル再生アプリを適用してコンテンツ（番組）再生を行なうことができる。
　放送局や番組対応の再生アプリ［ブロードキャスト（放送配信型）再生アプリ］を適用しない場合に利用される受信装置が予め保持している再生アプリケーションであり、特定の放送局や、番組の専用アプリではない再生アプリケーションをレジデンシャル（常駐型）再生アプリと呼ぶ。

　なお、レジデンシャル再生アプリには、ブラウザ上で実行可能なウェブアプリケーションや、ブラウザを起動することなく実行可能なアプリケーションなど、様々なタイプのアプリケーションが含まれる。

　図５に示すように、送信装置２０には、例えば、各々が個別の放送局に相当する複数の放送局２０Ａ，２０Ｂ、・・・が含まれる。
　これらの放送局２０Ａ，２０Ｂ、・・・の各々は、それぞれの放送番組データを放送波やネットワークを介して受信装置３０に提供する。
　さらに、放送局２０Ａ，２０Ｂ、・・・の各々は、それぞれの放送番組の再生に適用する再生アプリケーションや、シグナリングデータ等の制御情報も、放送波やネットワークを介して受信装置３０に提供することができる。

　放送局２０Ａ，２０Ｂ各々が提供する再生アプリケーション［ブロードキャスト（放送配信型）再生アプリ］は、各放送局の提供する放送番組コンテンツを再生するための再生アプリである。すなわち、特定の放送局や特定の番組の再生専用の再生アプリケーションである。

　例えば放送局Ａの提供するある番組ａ１については、放送局Ａ専用の再生アプリケーション（Ａａｐｌ）を利用することが必要となる。
　また、放送局Ａの提供するある番組ａ２については、放送局Ａの提供番組ａ２専用の再生アプリケーション（Ａ－ａ２対応再生アプリ）を利用することが必要となる。
　このように、放送局２０Ａ，２０Ｂ、・・・の各々が、放送波やネットワークを介して受信装置３０に提供する再生アプリケーションをブロードキャスト（放送配信型）再生アプリケーション（ブロードキャスト再生アプリ）と呼ぶ。

　図６は、各放送局の提供する番組と、各番組の再生に適用する再生アプリとの対応関係の一例について示した図である。
　放送局Ａの提供番組と、適用すべき再生アプリとの対応関係は以下の通りである。
　番組ａ１－レジデンシャル再生アプリ
　番組ａ２－ブロードキャスト再生アプリ（＝放送局Ａ対応再生アプリ）
　番組ａ３－ブロードキャスト再生アプリ（＝番組ａ３対応再生アプリ）
　番組ａ４－ブロードキャスト再生アプリ（＝放送局Ａ対応再生アプリ）

　また、放送局Ｂの提供番組と、適用すべき再生アプリとの対応関係は以下の通りである。
　番組ｂ１－ブロードキャスト再生アプリ（＝放送局Ｂ対応再生アプリ）
　番組ｂ２－ブロードキャスト再生アプリ（＝番組ｂ２対応再生アプリ）
　番組ｂ３－レジデンシャル再生アプリ

　受信装置２０は、記憶部にレジデンシャル再生アプリを保持しており、放送局から提供される番組中、ブロードキャスト再生アプリの適用が求められない番組については、レジデンシャル再生アプリを適用した再生処理を実行する。
　しかし、放送局から提供される番組中、ブロードキャスト再生アプリの適用が求められた番組については、放送局の提供するブロードキャスト再生アプリを取得して、取得したブロードキャスト再生アプリを適用して番組再生を行なうことが必要となる。

　受信装置３０において、番組に対応した正しい再生アプリが選択されない場合、正しい番組再生ができず、再生エラーが発生する場合がある。

　以下に説明する本開示の構成は、このような再生エラーの発生を防止し、受信装置３０において、コンテンツ（番組）対応の正しい再生アプリの選択取得、適用処理を実現し、また、チャンネル切り替え時の再生アプリの変更処理なども確実に正しく実行可能とした構成を実現するものである。

　　［５．受信装置の構成例と処理例について］
　次に、図７以下を参照して受信装置３０の構成例と処理例について説明する。
　なお、図７には、受信装置３０の一構成例を示している。
　受信装置３０は、放送サーバ等の送信装置２０からの送信データを受信するミドルウェア１１０と、受信データの解析や蓄積処理を実行するプロキシサーバ１２０、番組コンテンツやその他アプリケーション等の再生処理を実行する再生処理部（アプリケーション実行部）１３０を有する。

　放送サーバ等の送信装置２０は、放送波や、ネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるＡＶセグメント、シグナリングデータ、その他のデータを送信する。

　図７に示す受信装置３０のミドルウェア１１０は、放送送信装置２０の提供データを受信し、解析する。
　ミドルウェア１１０は、通信部（ＰＨＹ／ＭＡＣ）１１１、シグナリングデータを取得するシグナリング取得部１１２、シグナリングデータを解析するシグナリング解析部１１３、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ等のデータファイルを取得するセグメント取得部１１４を有する。

　ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１に格納される。プロキシサーバ１２０は、再生制御部１３１からのデータ要求をアドレス解決部（Ａｄｄｒｅｓｓ　Ｒｅｓｏｌｖｅｒ）１２２に入力し、要求されたデータをキャッシュ部（プロキシキャッシュ）１２１、または外部から取得して提供する。

　再生処理部（アプリケーション実行部）１３０は、再生アプリケーションや、その他のアプリケーションを実行する。
　なお、再生処理部（アプリケーション実行部）１３０の実行するアプリケーションは、例えば以下のアプリケーションである。
　（ａ）受信装置の記憶部に予め格納されたレジデンシャル（常駐型）再生アプリ、
　（ｂ）送信装置から受信するブロードキャスト（放送配信型）再生アプリ、
　（ｃ）受信装置の記憶部に予め格納されたその他のアプリケーション、
　（ｄ）送信装置から受信するその他のアプリケーション、
　例えば、これらの様々なアプリケーションを実行する。

　再生処理部（アプリケーション実行部）１３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＤＡＳＨ（ＭＰＥＧ－ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
　前述したように、ＭＰＥＧ－ＤＡＳＨ規格には、以下の２つの規格が含まれる。
　（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
　（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
　送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ－ＤＡＳＨ規格に従って実行される。

　コンテンツは、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って所定単位の分割データであるセグメントとして送信され、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、マニフェスト・ファイル（ＭＰＤ）を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。

　出力制御部１３２は、再生制御部の取得したセグメントから符号化コンテンツを取り出して復号し、表示部等の出力部に出力する。

　なお、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、シグナリングデータ処理部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ＆Ｖｉｅｗｅｒ）としても機能する。
　送信装置２０（放送サーバ２１等）が送信するシグナリングデータに基づく処理を実行する。
　先に図２を参照して説明したように、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。

　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、シグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）を取得して取得したシグナリングデータに基づく処理を実行する。
　例えば、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ）、コーデック情報（符号化方式など）を再生制御部１３１に提供する処理や、シグナリングデータの表示、例えば番組表の表示処理などを行う。

　なお、番組スケジュール（番組表）や、アドレス情報、コーデック情報等のシグナリングデータは、随時更新される可能性があり、受信装置では、最新のシグナリングデータを利用した処理を行なう必要がある。
　送信装置の送信するシグナリングデータには、ージョン識別子が設定され、受信装置は、バージョン識別子に基づいて、より新しいシグナリングデータを判別して取得し、利用することができる。

　図８は、受信装置３０の再生処理部（アプリケーション実行部）１３０内の、
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１、
　出力制御部１３２、
　これらの詳細構成を示す図である。

　再生処理部（アプリケーション実行部）１３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＭＰＤ取得部２０１、ＭＰＤ解析部２０２、セグメント取得部２０３、セグメント（ＭＰ４）解析部２０４を有する。

　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、前述したように、ＤＡＳＨ（ＭＰＥＧ－ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
　ＭＰＤ取得部２０１は、動画や音声ファイルの管理情報記述ファイルであるマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）を取得する。
　ＭＰＤは、放送サーバ２１等の送信装置２０から提供され、プロキシサーバ１２０に格納された後、再生制御部１３１が取得する。

　ＭＰＤは、動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイルである。
　放送局の提供する番組構成データであるＡＶセグメントに関するアクセス情報や、再生制御情報、具体的にはコーデック情報、再生時間情報等、番組コンテンツの取得、再生処理に必要な制御情報が記録されている。む

　ＭＰＤ解析部２０２は、ＭＰＤ取得部２０１の取得したＭＰＤの記述内容を解析し、再生対象データに対応するセグメントの取得に必要となる情報等をセグメント取得部に提供する。

　セグメント取得部２０３は、ＭＰＤ解析部２０２のＭＰＤ解析結果に従って、再生対象データに対応するセグメントの取得を行う。
　セグメントは、ＡＶデータからなるコンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に従って設定される所定の単位データである。

　セグメント解析部２０４は、セグメント取得部２０３の取得したセグメントから、符号化画像データ、符号化音声データ等を取得して、出力制御部１３２の復号部（デコーダ）２１１に出力する。

　再生処理部（アプリケーション実行部）１３０の出力制御部１３２は、復号部（デコーダ）２１１と、出力部（レンダラ）２１２を有する。
　これらの各処理部では、実行するアプリケーションプログラに従った処理を実行することになる。
　復号部（デコーダ）２１１は、セグメント解析部２０４から提供された符号化画像データ、符号化音声データの復号処理（テーコード）を実行する。
　出力部２１２は、復号された画像データ、音声データを出力部（ディスプレイ、スピーカ）に出力する。

　先に図５、図６等を参照して説明したように、各放送局は、送信コンテンツ（番組）に応じて、再生処理に適用するアプリケーションを指定することが可能である。
　具体的には、例えば、
　（ａ）受信装置に予め格納されたレジデンシャル（常駐型）再生アプリケーション、
　（ｂ）放送局等の送信装置が放送波やネットワークを介して提供するブロードキャスト（放送配信型）再生アプリケーション、
　これらのいずれの再生アプリを利用すべきかを指定することができる。

　受信装置（クライアント）３０の再生処理部（アプリケーション実行部）１３０は、再生コンテンツに応じて利用するアプリケーションを正しく選択することが必要となる。
　このアプリ選択に必要となる情報は、シグナリングデータを適用して送信装置２０から受信装置３０に送信される。
　このシグナリングデータの詳細、および利用処理の詳細については、後述する。

　受信装置（クライアント）３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＡＴＳＣ３．０クライアントアプリケーション（３．０　ＤＡＳＨ　Ｃｌｉｅｎｔ）の実行部でもある。
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＡＴＳＣ３．０放送受信クライアントデバイス上に実装されたブラウザ上で実行されるブラウザアプリケーションや、その他のアプリケーションを実行する。

　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１の実行するＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０　ＤＡＳＨクライアントアプリケーション（３．０　ＤＡＳＨ　Ｃｌｉｅｎｔ）や、ＡＴＳＣ３．０ストリーム付随アプリケーション（３．０　Ａｐｐｌｉｃａｔｉｏｎ）等からなる。

　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ミドルウェア（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＡＴＳＣ　Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータ、プロキシサーバ（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＨＴＴＰ　Ｐｒｏｘｙ　Ｓｅｒｖｅｒ）１２０がネットワークを介して受信したデータの処理を実行する。

　すなわち、再生処理部（アプリケーション実行部）１３０は、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１と、出力制御部１３２を用いて、ミドルウェア１１０、またはプロキシサーバ１２０の取得した、ＤＡＳＨ－ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）ファイルを入力して、ストリームのレンダリングや、アプリケーションの制御を行う。

　図７に示すモデルは、再生処理部（アプリケーション実行部）１３０の実行するＡＴＳＣ３．０クライアントアプリケーションや、その他のアプリケーションからすると、必ずプロキシサーバ１２０を介して外の世界にアクセスするため、それらファイル群を放送経由で取得しているのか、ネット経由で取得しているのかの区別を意識することがない（ネットワーク透過性が提供される）ため、アプリケーションの可搬性を高めることが可能となる。
　従って放送向けのみに特化してアプリケーションを実装する必要がなく、放送もインターネットのどちらを使うかによらない実装とすることができる。

　再生処理部（アプリケーション実行部）１３０の実行するアプリケーションがＤＡＳＨ－ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０が、アドレス解決部（Ａｄｄｒｅｓｓ　Ｒｅｓｏｌｖｅｒ）１２２において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。

　判断材料となる情報は、シグナリングデータの解析結果として提供される。再生制御（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、シグナリング取得部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２に、ＡＴＳＣ３．０のシグナリングメタであるＵＳＢＤ／ＵＳＤやＳ－ＴＳＩＤ等の取得要求を行う。

　シグナリング取得部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２は、通信部（ＡＴＳＣチューナ：ＡＴＳＣ３．０　ＰＨＹ／ＭＡＣ）１１１を介して放送受信するＳＬＳ　ＬＣＴパケットにより運ばれるシグナリングメタを抽出する。

　シグナリング解析部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３は、また、セグメントやアプリケーションリソースの取得要求に含まれるＵＲＬから、シグナリングメタを抽出して、対象となるファイルを取得するための放送配信アドレス情報を解決する。放送配信される（た）ことがわかれば、その放送配信アドレス情報をもとにして、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、キャッシュ（Ｐｒｏｘｙ　Ｃａｃｈｅ）部１２１内に展開する。プロキシサーバ１２０は、当該ファイルを再生制御部１３１に（ＨＴＴＰのレスポンスとして）返す。アプリケーションパーツの取得要求に含まれるＵＲＬがシグナリングメタになければ、プロキシサーバ１２０は、通常のネットスタックを介して当該ファイルを取得する。

　　［６．放送局や番組等、サービス単位の制御情報、属性情報を通知するシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）について］
　次に、サービス（放送局や番組等）単位の制御情報、属性情報を通知するシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）について説明する。

　前述したように、放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０の規格化が進行中である。

　ＡＴＳＣ３．０においては、ＩＰベースのトランスポートスタックの標準化作業が行われており、画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式であるＯＴＴ（Ｏｖｅｒ　Ｔｈｅ　Ｔｏｐ）配信で主流となりつつあるＭＰＥＧ－ＤＡＳＨ規格に従ったファイルフォーマット（ＩＳＯ－ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルを、先に図３、図４を参照して説明したＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ　Ｏｂｊｅｃｔ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法を提案している。

　送信装置２０は、ＲＯＵＴＥプロトコルに従って、例えば、以下の各データを送信する。
　（１）ＤＡＳＨ規格に従って転送されるフラグメント化（細分化）されたＭＰ４ファイル（ｆｒａｇｍｅｎｔｅｄ　ＭＰ４）、
　（２）ＤＡＳＨ規格に従った制御メタデータ（シグナリングデータ）であるＭＰＤ、
　（３）放送配信のためのシグナリング（３ＧＰＰ－ＭＢＭＳ３－ＵＳＤ（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）を拡張したＡＴＳＣバージョンのＵＳＤやＲＯＵＴＥプロトコルの制御メタデータ（シグナリングデータ）であるＳ－ＴＳＩＤ等、
　このような様々なデータの送信を行う。

　先に図３、図４等を参照して説明したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとして拡張されたプロトコルである。
　ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータ（シグナリングデータ）はＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）と呼ばれるが、ＲＯＵＴＥにおいてＦＤＴに相当する制御メタデータ（シグナリングデータ）は、Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ－ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｉｎｓｔａｎｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれる。

　Ｓ－ＴＳＩＤは、あるサービス（例えば、放送のチャンネルや番組）単位で転送されるすべてのサービスコンポーネント（ビデオ／オーディオ／データコンポーネントストリーム等）についての転送制御メタデータを記述する。
　なお、サービスコンポーネント（ビデオ／オーディオ／データコンポーネントストリーム等）は、すべてファイル転送セッションで転送される。

　サービス単位のシグナリングデータであるＳ－ＴＳＩＤ自身も、ＲＯＵＴＥセッションの中で、サービスシグナリングデータ転送セッションを利用して転送される。Ｓ－ＴＳＩＤは１つのサービス内で転送されるコンポーネントファイル転送セッションについてのシグナリングデータである。

　さらに、Ｓ－ＴＳＩＤ自身が転送されるサービス毎のサービスレベルシグナリングデータ転送セッションのアドレス（サービスブートストラップアドレス）を取得（アドレス解決）するためのメタデータ（シグナリングデータ）として、サービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）が利用される。

　サービスリストテーブル（ＳＬＴ）は、ＵＤＰ／ＩＰ上で、それぞれのサービスとは異なる特別なアドレスおよびポート（Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓ／Ｄｅｓｔｉｎａｔｉｏｎ　Ｐｏｒｔ）を利用して転送される。
　図９以下を参照してサービスリストテーブル（ＳＬＴ）について説明する。

　図９は、サービスリストテーブル（ＳＬＴ）３０１と、各サービス３１１～３１３との対応関係を説明するプロトコルスタックを示す図である。
　図９に示すプロトコルスタックは、先に図３を参照して説明したプロトコルスタックの一部に相当する。
　図９に示すサービスリストテーブル（ＳＬＴ）３０１は、図３に示すプロトコルスタックのシグナリングデータ（Ｓｉｇｎａｌｉｎｇ）の一構成要素である。

　図９に示す複数のサービス（Ｓｅｒｖｉｃｅ）３１１～３１３単位のレイヤは、各放送局や番組単位のサービス単位の転送データレイヤである。各サービス３１１～３１３は、以下の各データを転送する。
　（ａ）サービス単位の制御データ、属性データを含むシグナリングデータであるＳ－ＴＳＩＤ等のサービスレベルシグナリングデータファイル３２１、
　（ｂ）番組コンテンツ等の構成データとなるＡ／Ｖ／ＣＣ－ＤＡＳＨファイル３２２、
　（ｃ）再生アプリケーションや、インデックスファイル、その他のアプリケーション等のノンリアルタイムデータによって構成されるＮＲＴファイル３２３、

　サービスリストテーブル（ＳＬＴ）３０１には、各サービス３１１～３１３単位で転送される上記データを取得するための情報をリストアップしたテーブルである。
　サービスリストテーブル（ＳＬＴ）３０１の具体的構成例を図１０に示す。

　サービスリストテーブル（ＳＬＴ）３０１は、図１０に示すように、
　サービス単位のサービスエントリ３５１～３５３を有する。
　各サービスエントリ３５１～３５３には、
　（ｐ）サービス単位の基本属性情報３６１、
　（ｑ）サービスシグナリングブートストラップアドレス３６２、
　これらの各データが記録されている。

　サービスシグナリングブートストラップアドレス３６２は、各サービス単位のメタデータ（シグナリングデータ）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得するためのアドレスに相当する。

　受信装置（クライアント）３０は、あるチャンネルに設定し、受信するサービス（放送局、あるいは番組等）を決定すると、まず、最初にシグナリングデータであるサービスリストテーブル（ＳＬＴ）から必要な情報を取得する。
　なお、サービスリストテーブル（ＳＬＴ）等のシグナリングデータは、随時、放送局等の送信装置２０から繰り返し送信され、受信装置３０は、随時、サービスリストテーブル（ＳＬＴ）を受信することができる。

　なお、サービスリストテーブル（ＳＬＴ）は、随時、更新可能であり、受信装置３０きは、サービスリストテーブル（ＳＬＴ）に設定されたバージョン識別子に基づいて、最新のサービスリストテーブル（ＳＬＴ）を選択取得して受信装置の記憶部に格納して利用する。

　受信装置３０は、取得したサービスリストテーブル（ＳＬＴ）から、受信予定のサービス（放送局や番組）に対応するサービスエントリを選択し、選択したサービスエントリに記録された情報、すなわち、
　（ｐ）サービス単位の基本属性情報３６１、
　（ｑ）サービスシグナリングブートストラップアドレス３６２、
　これらの情報を取得する。

　（ｑ）サービスシグナリングブートストラップアドレス３６２は、各サービス（例えば図９のサービス３１１）対応の属性情報や制御情報等を記述したメタデータ（シグナリングデータ）であるサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得するためのアドレス情報等が記録されている。
　受信装置（クライアント）は、このアドレスを用いて、サービス単位のメタデータ（シグナリングデータ）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　サービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）には、サービス（例えば図９のサービス３１１）対応の各データ、例えば図９に示す以下のデータ、すなわち、
　（ｂ）番組コンテンツ等の構成データとなるＡ／Ｖ／ＣＣ－ＤＡＳＨファイル３２２、
　（ｃ）再生アプリケーションや、インデックスファイル、その他のアプリケーション等のノンリアルタイムデータによって構成されるＮＲＴファイル３２３、
　これらのデータを取得するための情報や、これらのデータ利用した処理（再生処理やアプリケーション実行等の処理）に必要な情報等のサービス属性情報、制御情報等が記録されている。

　受信装置（クライアント）は、サービス単位のメタデータ（シグナリング）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）に記録されたデータを用いて、サービス単位の提供データ（ＡＶコンテンツやアプリケーション）を受領して、番組再生処理等を実行する。

　ＡＴＳＣ３．０では、図１０に示すＳＬＴ３０１のサービスエントリ単位で記録するサービス単位の基本属性３６１の１つとして、サービスの種類を識別するための情報である「サービスカテゴリ」を記録することについての議論がなされている。

　例えば、具体的なサービスカテゴリの種類として、以下のような提案がなされている。
　（１）サービスカテゴリ－１：リニアＡＶ＝［ＬｉｎｅａｒＡＶ（通常の音声ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ）放送ストリームと、放送チャネルの付随アプリケーションを適宜起動できるサービス）］、
　（２）サービスカテゴリ－２：リニアＡ＝［ＬｉｎｅａｒＡ（通常の音声（Ａｕｄｉｏ）放送サービス（ラジオと等価）と、放送チャネルの付随アプリケーションを適宜起動できるサービス）］、

　なお、上記のサービスカテゴリ－１，２のリニアＡＶ（ＬｉｎｅａｒＡＶ）と、リニアＡ（ＬｉｎｅａｒＡ）の各サービスをまとめて、
　リニアサービス（Ｌｉｎｅａｒ　Ｓｅｒｖｉｃｅ）という上位のサービスカテゴリの定義についても提案されている。
　さらに、もう１つのサービスカテゴリとして、
　（３）サービスカテゴリ－３：アプリベース［Ａｐｐ－ｂａｓｅｄ（放送チャネルのアプリケーションが最初に起動するサービス－アプリケーションは任意）
　このカテゴリについても検討されている。

　上記のサービスカテゴリとして定義されるリニア（Ｌｉｎｅａｒ）サービスの場合、受信装置（クライアント）が、ある１つのサービスの提供チャンネルに、チャンネルを設定（チューン）すると、受信装置（クライアント）は、そのサービス対応の放送ストリームに含まれる音声／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリームのレンダリング処理を含む再生処理を開始する。

　この再生処理は、現行のＴＶ等では、ＴＶ製造時にＴＶに内蔵された再生アプリケーション、すなわちレジデンシャル再生アプリケーションが実行する。
　しかし、今後、各放送局等の送信装置２０は、放送局独自の再生アプリケーション（ブロードキャスト再生アプリ）を、受信装置３０に提供することを予定している。

　今後、利用が普及されると予測される高機能型テレビ、例えばブラウザ上で実行されるウェブアプリ等の実行機能を持つハイブリッド・ブロードキャスト・ブロードバンド・テレビ（ＨｂｂＴＶ）等の受信装置は、放送局等の送信装置が提供するブロードキャスト再生アプリを受信し、これを利用して番組再生処理を行なうことができる。

　なお、送信装置２０が提供するブロードキャスト再生アプリの起動処理等の制御は、送信装置２０から送信される再生アプリ対応のメタデータ（シグナリングデータ）であるアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記録されている。
　受信装置（クライアント）３０は、ブロードキャスト再生アプリと、ブロードキャスト再生アプリ対応のアプリケーション情報テーブル（ＡＩＴ）の双方を取得して、ブロードキャスト再生アプリを適用した番組再生を行なう。

　送信装置は、アプリケーション情報テーブル（ＡＩＴ）はシグナリングデータの１つであり、送信装置は、アプリケーション情報テーブル（ＡＩＴ）を継続的に、繰り返し送信する。
　受信装置（クライアント）は、アプリケーション情報テーブル（ＡＩＴ）を任意タイミングで取得して、ＡＩＴに従って、特定の放送局から提供されたブロードキャスト再生アプリケーションの制御、例えば起動や停止処理を実行することができる。

　現行のテレビ等の受信装置（クライアント）は、多くの場合、放送番組の再生処理を、レジデンシャル再生アプリケーションを利用して実行する。
　なお、レジデンシャル再生アプリケーションには、以下の２種類がある。
　（ａ）テレビ等の受信装置に予め内蔵された内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）、
　（ｂ）ブラウザ上で実行されるウェブアプリケーション、

　内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）は、ＴＶ等の製造メーカ（デバイスベンダ）が提供することを想定しており、内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）は、放送局や番組に依存しない再生アプリケーションプログラムであり、多くの異なる放送局の提供するサービス（番組コンテンツ）の再生に利用される。

　レジデンシャル再生アプリケーションとしてのウェブアプリケーションも、製造メーカ（デバイスベンダ）が例えばテレビ製造時にテレビ等の受信装置（クライアント）内の記憶部に格納する。あるいは、例えば、ネットワーク等を介してベンダーの管理サーバからテレビ等の受信装置（クライアント）に送信して記憶部に格納するといった設定等がある。

　一方、放送局等の送信装置が、各放送局の提供サービス（番組コンテンツ）専用の再生アプリケーションとして提供するブロードキャスト再生アプリケーションは、上述したように、アプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に起動、停止等の制御情報が記録されている。

　受信装置（クライアント）は、ブロードキャスト再生アプリケーションを利用した再生処理を実行する場合は、以下の２つのデータを取得することが必要となる。
　（１）サービス対応のブロードキャスト再生アプリケーション
　（２）ブロードキャスト再生アプリケーションの制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）

　　［７．送信装置の提供サービスのサービスカテゴリ設定構成について］
　先に説明したように、ＡＴＳＣ３．０において、図１０に示すＳＬＴ３０１のサービスエントリ単位で記録するサービス単位の基本属性３６１の１つとして、サービスカテゴリの記録について議論がなされている。
　すなわち、送信装置の提供サービスについて、受信装置側でその種類を把握するためのサービスカテゴリ設定である。

　前述したように、サービスカテゴリの種類として、ＡＴＳＣ３．０では、例えば以下のようなカテゴリ設定についての提案がなされている。
　（１）サービスカテゴリ－１：リニアＡＶサービス＝［ＬｉｎｅａｒＡＶ（通常の音声ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ）放送ストリームと、放送チャネルの付随アプリケーションを適宜起動できるサービス］、
　（２）サービスカテゴリ－２：リニアＡサービス＝［ＬｉｎｅａｒＡ（通常の音声（Ａｕｄｉｏ）放送サービス（ラジオと等価）と、放送チャネルの付随アプリケーションを適宜起動できるサービス］、
　（３）サービスカテゴリ－３：アプリベースサービス＝［Ａｐｐ－ｂａｓｅｄサービス（放送チャネル対応のアプリケーションが最初に起動するサービス）］

　上記のサービスカテゴリをサービスリストテーブル（ＳＬＴ）の各サービスエントリの「サービス単位の基本属性」の１つの属性情報として記録することで、受信装置（クライアント）は、受信予定のサービス（番組コンテンツ）の再生に、放送チャネルの付随アプリケーション、すなわち、放送局の提供するブロードキャスト再生アプリを適用すべきか否かを判定することができる。

　しかし、これらのカテゴリ分類のみでは、受信装置（クライアント）３０が受信予定のサービス（番組コンテンツ）の再生に適用すべき再生アプリを確実に選択できないという問題がある。
　例えば、放送局の提供する番組再生に、内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）や、内蔵ウェブアプリケーション等のレジデンシャル再生アプリケーションが利用できるか否かを判定することができないという問題等がある。

　また、受信装置（クライアント）３０において、チャンネル切り替え等、受信サービスの遷移を行う際に、番組再生に適用する再生アプリの変更が発生することがあるが、このサービス遷移時に受信装置において再生アプリの停止、起動処理に時間を要すると、チャンネル切り替え後の番組の再生開始に遅れが発生してしまうといった問題が発生する。

　以下、このような問題を解決するサービスカテゴリの設定例と、利用処理例について説明する。
　以下において説明する構成において、サービスカテゴリは、再生処理に適用すべき再生アプリが、少なくとも以下のいずれであるかを判別可能とした設定とする。
　（１）レジデンシャル（常駐型）再生アプリ、
　（２）ブロードキャスト（放送型）再生アプリ、

　例えば、以下の２つのサービスカテゴリを含むカテゴリ設定とする。
　（１）サービスカテゴリ－Ｒ：リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード
　（２）サービスカテゴリ－Ｂ：リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード

　以下、各サービスカテゴリの詳細について説明する。
　（１）サービスカテゴリ－Ｒ：リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード（Ｌｉｎｅａｒ　Ｓｅｒｖｉｃｅ－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌモード）は、放送局の提供するＡＶストリームの再生処理（レンダリング処理等）を、放送局や番組等のサービス専用再生アプリではなく、サービス非依存型のレジデンシャル再生アプリを利用して再生可能であることを示すカテゴリ区分である。
　なお、レジデンシャル再生アプリには、内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）や、内蔵ウェブアプリケーション等が含まれる。

　このサービスカテゴリ－Ｒに区分されるサービスにおいて、放送サーバ等の送信装置から送信される番組コンテンツの再生処理には、受信装置（クライアント）が予め保持しているレジデンシャル再生アプリを利用することができる。

　なお、送信装置は、このサービスカテゴリ－Ｒに区分されるサービスの提供に際して、ブロードキャスト再生アプリの提供は行う必要がないが、その他のアプリケーションは提供する場合がある。
　例えば番組コンテンツにオーバーレイ表示するデータの表示アプリケーションや、番組のバックグラウンドで実行される非表示型のアプリケーション、放送局提供の視聴状況モニタリングアプリケーション等のサービス付随アプリケーションは、例えばＮＲＴコンテンツとしてサービスに含めて送信装置から受信装置に提供される場合がある。

　これらのサービス付随ウェブアプリケーションは、各サービス対応のシグナリングデータであるＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）によって送信されるアプリケーション情報テーブル（ＡＩＴ）を適用して制御される。
　すなわち、アプリケーション対応のＡＩＴによって、例えばアプリケーションの起動、停止、ライフサイクル等の制御が行われる。

　しかし、このＡＩＴは、特定のサービス付随ウェブアプリケーションの制御に利用されるのみであり、サービスのメインコンテンツとなる番組コンテンツの再生処理に利用するレジデンシャル再生アプリの制御には利用されない。

　次に、もう１つのサービスカテゴリである、
　「（２）サービスカテゴリ－Ｂ：リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード」について説明する。
　（２）サービスカテゴリ－Ｂ：リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード（Ｌｉｎｅａｒ　Ｓｅｒｖｉｃｅ－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌモード）は、放送局の提供するＡＶストリームの再生処理（レンダリング処理等）を、放送局や番組等のサービス専用再生アプリ、すなわちブロードキャスト再生アプリを利用して再生可能であることを示すカテゴリ区分である。

　このサービスカテゴリは、サービスを提供する放送局等の送信装置から例えばノンリアルタイム（ＮＲＴ）コンテンツとして送信されるブロードキャスト再生アプリを利用することで再生可能となるサービス（番組コンテンツ）であることを示すカテゴリである。

　ブロードキャスト再生アプリは、例えば、受信装置（クライアント）のブラウザ上で実行されウェブアプリケーションである。

　なお、このウェブアプリケーションは、番組コンテンツの再生処理以外の処理を実行する複数の番組付随アプリケーションの制御処理を行なう場合もある。
　番組付随アプリケーションとは、例えば番組コンテンツにオーバーレイ表示するデータの表示アプリケーションや、番組のバックグラウンドで実行される非表示型のアプリケーション、放送局提供の視聴状況モニタリングアプリケーション等である。

　なお、もう１つのサービスカテゴリとして、
　（３）サービスカテゴリ－Ａｐｐを設定する。
　サービスカテゴリ－Ａｐｐは、アプリベース＝［Ａｐｐ－ｂａｓｅｄサービス（放送チャネル対応のアプリケーションが最初に起動するサービス）］

　アプリベース（Ａｐｐ－ｂａｓｅｄ）サービスを利用する場合、受信装置（クライアント）が、そのサービスの提供チャンネルに遷移すると、まず、最初にそのサービスのウェブアプリケーションを起動する。

　このアプリケーションの制御、例えばライフサイクル制御等は、やはりサービスシグナリングデータとして転送されるアプリケーション情報テーブル（ＡＩＴ）によって行われる。
　なお、このアプリベース（Ａｐｐ－ｂａｓｅｄ）サービスは、基本的に放送番組となるリアルタイムストリームは利用しない。ＮＲＴ（Ｎｏｎ　Ｒｅａｌ　Ｔｉｍｅファイル非同期配信）もしくはオンディマンドストリーミングのみが利用される。受信装置（クライアント）が、アプリベース（Ａｐｐ－ｂａｓｅｄ）サービスに遷移した場合、遷移先の放送アプリがすべての処理を掌握する。

　このように、サービスカテゴリの区分として、少なくとも、以下の３つのサービスカテゴリを設定する。
　（１）サービスカテゴリ－Ｒ：リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード
　（２）サービスカテゴリ－Ｂ：リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード
　（３）サービスカテゴリ－Ａｐｐ：アプリベース（Ａｐｐ－ｂａｓｅｄ）サービス

　このようなサービスカテゴリを設定する。
　送信装置は、サービスカテゴリ情報を、図９、図１０を参照して説明したサービスリストテーブル（ＳＬＴ）のサービス単位の基本属性記録フィールドに記録して、受信装置に提供する。

　受信装置は、ある放送局の提供番組である特定のサービスを受領する場合、ＳＬＴの「サービスエントリ」の「サービス単位の基本属性」を参照してサービスカテゴリを確認する。
　この確認結果に基づいて、再生に利用するアプリケーションを適確に選択することが可能となる。

　例えば、受信装置は、サービスリストテーブル（ＳＬＴ）から受信予定のサービス対応の「サービスエントリ」をほ選択し、選択した「サービスエントリ」に記録された「サービス単位の基本属性」のサービスカテゴリの識別子を確認する。
　サービスカテゴリ識別子が、「サービスカテゴリ－Ｒ」、すなわち、「リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード」を示している場合は、受信装置に保持されているレジデンシャル再生アプリを起動して、受信データ（ＡＶセグメント）の再生処理を実行する。

　また、サービスカテゴリの識別子が、「サービスカテゴリ－Ｂ」、すなわち、「リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード」を示している場合は、放送局等の送信装置から提供されるブロードキャスト再生アプリを取得して、この再生アプリを起動して、受信データ（ＡＶセグメント）の再生処理を実行する。
　なお、この場合には、ブロードキャスト再生アプリに対応するアプリケーション情報テーブル（ＡＩＴ）も取得し、このＡＩＴの記録情報に従ったアプリケーション制御を行う。

　また、サービスカテゴリの識別子が、「サービスカテゴリ－Ａｐｐ」、すなわち、「アプリベース（Ａｐｐ－ｂａｓｅｄ）サービス」を示している場合は、放送局等の送信装置から提供されるアプリケーションを取得して、このアプリケーションを起動して処理を実行する。
　なお、この場合には、このアプリケーションに対応するアプリケーション情報テーブル（ＡＩＴ）も取得し、このＡＩＴの記録情報に従ったアプリケーション制御を行う。

　受信装置（クライアント）がチャンネルを変更する場合、すなわちサービス遷移処理を実行する場合は、以下のような制御が実行される。

　まず、チャンネル変更前に、サービスカテゴリが、「サービスカテゴリ－Ｒ」、すなわち、「リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード」であるサービス（チャネル）を受信し、その放送ストリームの再生処理を、レジデンシャル再生アプリを適用して実行しているとする。

　この状態で、受信装置（クライアント）においてチャネル切り替えが発生し、他のサービス（チャネル）に遷移するとする。
　遷移先サービス（チャネル）のサービスカテゴリが、
　「サービスカテゴリ－Ｂ」、すなわち、「リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード」であるとする。

　この場合、実行中だったレジデンシャル再生アプリを停止する。
　「サービスカテゴリ－Ｂ」、すなわち、「リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード」のサービスに含まれるＡＶストリーム再生には、そのサービス（チャネル）専用の再生アプリ、すなわち、ブロードキャスト再生アプリ（ウェブアプリ）を利用することが必須となる。

　このブロードキャスト再生アプリ（ウェブアプリ）を利用して再生処理を行なうためには、以下の処理が必要となる。
　（Ｓ１）遷移先サービス対応のブロードキャスト再生アプリ（ウェブアプリ）を取得、
　（Ｓ２）取得したブロードキャスト再生アプリ（ウェブアプリ）の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ）を取得、
　（Ｓ３）アプリケーション情報テーブル（ＡＩＴ）の記録情報に従って、ブロードキャスト再生アプリ（ウェブアプリ）を起動。

　なお、遷移先サービス対応のブロードキャスト再生アプリ（ウェブアプリ）や、アプリケーション情報テーブル（ＡＩＴ）は、チャンネル遷移前に予め取得し、受信装置（クライアント）の記憶部に格納しておいてもよい。

　また、遷移先サービス（チャネル）のサービスカテゴリが、
　「サービスカテゴリ－Ａｐｐ」、すなわち、「アプリベース（Ａｐｐ－ｂａｓｅｄ）サービス」である場合は、受信装置（クライアント）は、以下の処理を行なう。

　まず、実行中だったレジデンシャル再生アプリを停止する。
　「サービスカテゴリ－Ａｐｐ」、すなわち、「アプリベース（Ａｐｐ－ｂａｓｅｄ）サービス」のサービスの実行には、そのサービス専用のアプリケーション（ウェブアプリ）を利用することが必須となる。

　このアプリケーション（ウェブアプリ）を利用したアプリケーション処理を行なうためには、以下の処理が必要となる。
　（Ｓ１）遷移先サービス対応のアプリケーション（ウェブアプリ）を取得、
　（Ｓ２）取得したアプリケーション（ウェブアプリ）の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ）を取得、
　（Ｓ３）アプリケーション情報テーブル（ＡＩＴ）の記録情報に従って、アプリケーションを起動。

　このように、チャンネル切り替え等、サービス遷移が発生すると、受信装置（クライアント）で実行すべきアプリケーションの切り替え処理を行なう必用が発生する場合がある。
　このようなアプリ切り替え処理に際しては、例えばアプリケーションの起動処理、レンダリングリソース（バッファ等）の初期化処理等の複数の処理を行なうことが必要となり、これらの処理に起因して、ストリーム再生動画の中断（黒画面等の動画間の切れ目）が発生してしまう可能性がある。

　チャネル切り替え時における動画の中断（黒画面）を最小限に抑えるための方法の１つとして、以下の方法がある。
　例えばチャネル遷移の前後の２つのサービスが、いずれもレジデンシャル再生アプリを適用可能なサービスである場合、実行中のレジデンシャル再生アプリの停止処理を行なうことなく、そのまま継続実行する。
　このような処理を行なえば、再生アプリの停止、起動処理を行なうことなく、２つの異なるサービスの提供コンテンツの再生を、継続的に実行することが可能となる。

　しかし、このような処理を行なうためには、チャンネル切り替え後のサービス、すなわちサービス遷移処理後のサービスの処理に適用するアプリケーションが何であるかをサービスの切り替え実行前、あるいは切り替え実行時に瞬時に判別することが必要である。

　すなわち、受信装置（クライアント）は、サービス遷移後のサービスに適用するアプリケーションの種類を、より早く把握することで、遷移前のサービス対応の実行中のアプリケーションの停止処理や、遷移後のサービス対応のアプリケーションの起動処理を省略することが可能となる場合がある。

　サービス遷移後のサービス適用アプリの確認を、より早いタイミングで行うことを可能とするため、図９、図１０を参照して説明したシグナリングデータであるサービスリストテーブル（ＳＬＴ）を利用する。
　すなわち、サービスリストテーブル（ＳＬＴ）のサービスエントリの「サービス単位の基本属性」の構成情報の１つとして、上述した３種類のサービスカテゴリ情報を記録する。

　すなわち、サービスリストテーブル（ＳＬＴ）のサービスエントリの「サービス単位の基本属性」に、各サービスが、以下の３種類のどのサービスカテゴリに属するかを判別可能なサービスカテゴリ識別子を記録する。
　（１）サービスカテゴリ－Ｒ：リニア（Ｌｉｎｅａｒ）サービス－レジデンシャル制御モード
　（２）サービスカテゴリ－Ｂ：リニア（Ｌｉｎｅａｒ）サービス－ブロードキャスト制御モード
　（３）サービスカテゴリ－Ａｐｐ：アプリベース（Ａｐｐ－ｂａｓｅｄ）サービス

　サービスリストテーブル（ＳＬＴ）は、サービス対応のシグナリングデータ、すなわち、Ｓ－ＴＳＩＤ等のサービスレベルシグナリングの受信前に受信装置（クライアント）によって取得される。
　従って、受信装置（クライアント）は、より早い段階で次の遷移先サービスに適用すべきアプリケーションの種類を確認することが可能となる。

　すなわち、遷移先のサービスに適用すべきアプリケーションが、
　（ａ）レジデンシャル再生アプリ、
　（ｂ）ブロードキャスト再生アプリ、
　（ｃ）ブロードキャスト再生アプリではないブロードキャストアプリケーション、
　これら（ａ）～（ｃ）のいずれであるかを、より早い段階で確認することが可能となる。

　図１１に、サービスリストテーブル（ＳＬＴ）の各サービスエントリの記録データである「サービス単位の基本属性」の一属性として記録されるサービスカテゴリの種類の一例を示す。

　図１１に示す例は、以下のサービスカテゴリ識別子（０ｘ００～０ｘＦＦ）と、意味との対応関係を有するサービスカテゴリ設定例である。
　（１）０ｘ００＝不特定［Ｎｏｔ　ｓｐｅｃｉｆｉｅｄ］
　（２）０ｘ０１＝リニアサービス（音声／ビデオ、または音声のみ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（３）０ｘ０２＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ］
　（４）０ｘ０３＝アプリケーションベースサービス－ブロードキャストアプリケーションの適用制御サービス［Ａｐｐ－ｂａｓｅｄ　ｓｅｒｖｉｃｅ］
　（５）０ｘ０４～０ｘ０Ｆ＝リザーブ領域［Ｒｅｓｅｒｖｅｄ　ｆｏｒ　ｆｕｔｕｒｅ　ｕｓｅ］

　送信装置は、サービスリストテーブル（ＳＬＴ）の各サービスエントリの記録データである「サービス単位の基本属性」に、例えば、図１１に示すサービスカテゴリ識別のいずれかを設定して送信する。

　受信装置は、受信予定の放送局番組（サービス）に対応するサービスエントリを、サービスリストテーブル（ＳＬＴ）から選択して、そのサービスエントリの記録データである「サービス単位の基本属性」に、図１１に示すどのサービスカテゴリ識別子が記録されているかを確認する。
　この確認処理によって、受信予定のサービスに適用するアプリケーションの種類を判別することが可能となる。

　受信装置は、サービス遷移前後における適用アプリ、例えば放送局対応のチャンネル切り替え前に実行しているアプリケーションと、チャンネル切り替え後に適用するアプリケーションが同じであるか否かを判定することが可能となり、同じ場合、実行中の再生アプリの停止処理や再起動処理を行なうことなく、継続させることが可能となる。
　このアプリ継続処理によって、受信装置の出力途切れ時間を削減することが可能となる。

　図１１に示すサービスカテゴリ設定例は、
　音声／ビデオ（Ａ／Ｖ）と、
　音声のみ（Ａｕｄｉｏ　ｏｎｌｙ）
　これらの２種類のサービスを同一カテゴリとした設定例である。
　これらを異なるサービスカテゴリとして、それぞれに異なるサービスカテゴリ識別子を設定してもよい。
　この設定としたカテゴリ設定例を図１２に示す。

　図１２に示す例は、以下のサービスカテゴリ識別子（０ｘ００～０ｘＦＦ）と、意味との対応関係を有するサービスカテゴリ設定例である。
　（１）０ｘ００＝不特定［Ｎｏｔ　ｓｐｅｃｉｆｉｅｄ］
　（２）０ｘ０１＝リニアサービス（音声／ビデオ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（３）０ｘ０２＝リニアサービス（音声／ビデオ）－ブロードキャスト再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ］
　（４）０ｘ０３＝リニアサービス（音声のみ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａｕｄｉｏ　ｏｎｌｙ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（５）０ｘ０４＝リニアサービス（音声のみ）－ブロードキャスト再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ］
　（６）０ｘ０５＝アプリケーションベースサービス－ブロードキャストアプリケーションの適用制御サービス［Ａｐｐ－ｂａｓｅｄ　ｓｅｒｖｉｃｅ］
　（７）０ｘ０６～０ｘ０Ｆ＝リザーブ領域［Ｒｅｓｅｒｖｅｄ　ｆｏｒ　ｆｕｔｕｒｅ　ｕｓｅ］

　この図１２に示すサービスカテゴリの設定例は、
　レジデンシャル再生アプリを適用する音声＆ビデオ提供サービス、
　ブロードキャスト再生アプリを適用する音声＆ビデオ提供サービス、
　レジデンシャル再生アプリを適用する音声のみの提供サービス、
　ブロードキャスト再生アプリを適用する音声のみの提供サービス、
　受信装置は、サービスリストテーブル（ＳＬＴ）に基づいて、これらの各サービスを区別して確認することが可能となる。

　図１１、および図１２に示すサービスカテゴリの設定例は、
　レジデンシャル再生アプリを適用するサービス、
　ブロードキャスト再生アプリを適用するサービス、
　ブロードキャストアプリケーションを適用するサービス、
　基本的にこれら３種類のサービスカテゴリの区別を可能としている。

　しかし、例えば、複数の異なる放送局Ａ，Ｂ，Ｃがあり、
　各放送局Ａ，Ｂ，Ｃの提供する様々な番組において、同一のブロードキャスト再生アプリ（共用アプリ）を適用する場合も想定される。
　例えば、各放送局Ａ，Ｂ，Ｃは、番組単位で、以下の（１），（２）の異なるブロードキャスト再生アプリのいずれかを選択適用させるようなサービス（番組）提供を行う場合が想定される。
　（１）ブロードキャスト再生アプリ（共用アプリ）を適用して再生するサービス（番組）、
　（２）放送局、あるいは番組単位の専用のブロードキャスト再生アプリ（専用アプリ）を適用して再生するサービス（番組）

　図１３、図１４は、上記のような設定を考慮したサービスカテゴリ識別子の設定例を示す図である。
　図１３に示す例は、以下のサービスカテゴリ識別子（０ｘ００～０ｘＦＦ）と、意味との対応関係を有するサービスカテゴリ設定例である。
　（１）０ｘ００＝不特定［Ｎｏｔ　ｓｐｅｃｉｆｉｅｄ］
　（２）０ｘ０１＝リニアサービス（音声／ビデオ、または音声のみ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（３）０ｘ０２＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス（専用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｎａｔｉｖｅ］
　（４）０ｘ０３＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス（共用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｓｈａｒｅｄ］
　（５）０ｘ０４＝アプリケーションベースサービス－ブロードキャストアプリケーションの適用制御サービス［Ａｐｐ－ｂａｓｅｄ　ｓｅｒｖｉｃｅ］
　（６）０ｘ０５～０ｘ０Ｆ＝リザーブ領域［Ｒｅｓｅｒｖｅｄ　ｆｏｒ　ｆｕｔｕｒｅ　ｕｓｅ］

　送信装置は、サービスリストテーブル（ＳＬＴ）の各サービスエントリの記録データである「サービス単位の基本属性」に、例えば、図１３に示すサービスカテゴリ識別のいずれかを設定して送信する。

　図１３に示す例は、図１１に示すカテゴリ識別子設定例に含まれる以下のカテゴリ、すなわち、
　（３）０ｘ０２＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ］
　このカテゴリを、さらに２つに細区分した例である。

　ブロードキャスト再生アプリが、特定のサービス（特定の放送局や特定の番組）専用タイプであるか、あるいは、複数のサービス（複数の放送局や複数の番組）に共通に利用される共用タイプであるかに応じた２つのカテゴリに区分したのが、図１３に示す例である。

　ブロードキャスト再生アプリが、特定のサービス（特定の放送局や特定の番組）専用タイプである場合が、図１３に示す以下のカテゴリに対応する。
　（３）０ｘ０２＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス（専用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｎａｔｉｖｅ］

　一方、ブロードキャスト再生アプリが、複数のサービス（複数の放送局や複数の番組）に共通に利用される共用タイプある場合が、図１３に示す以下のカテゴリに対応する。
　（４）０ｘ０３＝リニアサービス（音声／ビデオ、または音声のみ）－ブロードキャスト再生アプリの適用制御サービス（共用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ　ｏｒ　Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｓｈａｒｅｄ］

　受信装置は、受信予定の放送局番組（サービス）に対応するサービスエントリを、サービスリストテーブル（ＳＬＴ）から選択して、そのサービスエントリの記録データである「サービス単位の基本属性」に、図１３に示すどのサービスカテゴリ識別子が記録されているかを確認する。
　この確認処理によって、受信予定のサービスに適用するアプリケーションの種類を判別することが可能となる。

　受信装置は、サービス遷移前後における適用アプリ、例えば放送局対応のチャンネル切り替え前に実行しているアプリケーションと、チャンネル切り替え後に適用するアプリケーションが同じであるか否かを判定することが可能となり、同じ場合、実行中の再生アプリの停止処理や再起動処理を行なうことなく、継続させることが可能となる。
　図１３に示すカテゴリ識別子を利用した場合は、チャンネル切り替え前後のサービスが、いずれもブロードキャスト再生アプリ（共用）である場合にも、実行中の再生アプリの停止処理や再起動処理を行なうことなく、継続させることが可能となる。
　このアプリ継続処理によって、受信装置の出力途切れ時間を削減することが可能となる。

　図１４に示すカテゴリ識別子設定例は、以下のサービスカテゴリ識別子（０ｘ００～０ｘＦＦ）と、意味との対応関係を有するサービスカテゴリ設定例である。
　（１）０ｘ００＝不特定［Ｎｏｔ　ｓｐｅｃｉｆｉｅｄ］
　（２）０ｘ０１＝リニアサービス（音声／ビデオ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（３）０ｘ０２＝リニアサービス（音声／ビデオ）－ブロードキャスト再生アプリの適用制御サービス（専用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｎａｔｉｖｅ］
　（４）０ｘ０３＝リニアサービス（音声／ビデオ）－ブロードキャスト再生アプリの適用制御サービス（共用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａ／Ｖ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｓｈａｒｅｄ］
　（５）０ｘ０４＝リニアサービス（音声のみ）－レジデンシャル再生アプリの適用制御サービス［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａｕｄｉｏ　ｏｎｌｙ）－Ｒｅｓｉｄｅｎｔｉａｌ　Ｃｏｎｔｒｏｌ］
　（６）０ｘ０５＝リニアサービス（音声のみ）－ブロードキャスト再生アプリの適用制御サービス（専用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｎａｔｉｖｅ］
　（７）０ｘ０６＝リニアサービス（音声のみ）－ブロードキャスト再生アプリの適用制御サービス（共用アプリ）［Ｌｉｎｅａｒ　ｓｅｒｖｉｃｅ（Ａｕｄｉｏ　ｏｎｌｙ）－Ｂｒｏａｄｃａｓｔｅｒ　Ｃｏｎｔｒｏｌ－Ｓｈａｒｅｄ］
　（８）０ｘ０７＝アプリケーションベースサービス－ブロードキャストアプリケーションの適用制御サービス［Ａｐｐ－ｂａｓｅｄ　ｓｅｒｖｉｃｅ］
　（９）０ｘ０８～０ｘ０Ｆ＝リザーブ領域［Ｒｅｓｅｒｖｅｄ　ｆｏｒ　ｆｕｔｕｒｅ　ｕｓｅ］

　図１４に示す例も、図１２に示すカテゴリ識別子設定例に含まれる「ブロードキャスト再生アプリの適用制御サービス」を、２つのカテゴリに細区分している。
　図１２に示すブロードキャスト再生アプリのカテゴリ識別子について、
　特定のサービス（特定の放送局や特定の番組）専用タイプであるか、あるいは、
　複数のサービス（複数の放送局や複数の番組）に共通に利用される共用タイプであるか、
　このいずれであるかに応じて２つのカテゴリに区分したのが、図１４に示す例である。

　受信装置は、受信予定の放送局番組（サービス）に対応するサービスエントリを、サービスリストテーブル（ＳＬＴ）から選択して、そのサービスエントリの記録データである「サービス単位の基本属性」に、図１４に示すどのサービスカテゴリ識別子が記録されているかを確認する。
　この確認処理によって、受信予定のサービスに適用するアプリケーションの種類を判別することが可能となる。

　受信装置は、サービス遷移前後における適用アプリ、例えば放送局対応のチャンネル切り替え前に実行しているアプリケーションと、チャンネル切り替え後に適用するアプリケーションが同じであるか否かを判定することが可能となり、同じ場合、実行中の再生アプリの停止処理や再起動処理を行なうことなく、継続させることが可能となる。
　図１４のカテゴリ識別子の設定を利用した場合は、チャンネル切り替え前後のサービスが、いずれもブロードキャスト再生アプリ（共用）である場合にも、実行中の再生アプリの停止処理や再起動処理を行なうことなく、継続させることが可能となる。
　このアプリ継続処理によって、受信装置の出力途切れ時間を削減することが可能となる。

　図１５に示すフローチャートは、受信装置３０がシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を受信し、ＳＬＴからサービスカテゴリ識別子を取得して、アプリケーションの制御を実行するシーケンスについて説明するフローチャートである。

　図１５に示すフローチャートに従った処理は、受信装置のデータ処理部（再生処理部等）において実行される。例えば、予め処理シーケンスを記録した再生制御プログラムを記憶部から読み出してプログラムに従った処理として実行される。
　各ステップの処理について説明する。

　　（ステップＳ１１）
　まず、受信装置は、放送局や番組等、サービス単位の制御情報、属性情報を通知するシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を受信する。

　サービスリストテーブル（ＳＬＴ）は、図９、図１０を参照して説明したように、サービスエントリ毎の情報として、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの各データを記録している。
　（ｐ）サービス単位の基本属性情報には、図１１～図１４を参照して説明したいずれかのタイプのカテゴリ識別子情報が記録されている。、
　なお、サービスリストテーブル（ＳＬＴ）は、受信装置におけるサービス実行、すなわち、放送局の提供する番組の再生開始前に予め取得しておく。

　　（ステップＳ１２）
　受信装置は、ステップＳ１２において、サービス遷移の発生の有無を判断する。具体的にはチャンネルの変更、あるいは異なるサービスに設定された異なる番組間の遷移等が発生したか否かを検知する。
　サービス遷移が発生していない場合は、ステップＳ１４に進む。
　一方、サービス遷移が発生した場合は、ステップＳ１３に進む。

　　（ステップＳ１３）
　ステップＳ１２においてサービス遷移が発生したことを検知すると、受信装置のデータ処理部は、ステップＳ１３において、ＳＬＴを参照してサービス遷移前後のサービスカテゴリ識別子が同一か否かを判定する。
　同一であることが確認された場合は、ステップＳ１４に進む。
　同一でないことが確認された場合は、ステップＳ１５に進む。

　　（ステップＳ１４）
　（ａ）ステップＳ１２において、サービス遷移が発生していないと確認された場合、
　（ｂ）あるいは、ステップＳ１２において、サービス遷移の発生が確認され、ステプＳ１３において、サービス遷移前後でサービスカテゴリ識別子が一致することが確認された場合、
　上記（ａ），または（ｂ）、いずれかと判定された場合は、ステップＳ１４に進み、ステップＳ１４において、現在、実行中のアプリを停止することなく、そのまま継続する。
　すなわち、サービス遷移前のサーコビスに適用していたアプリケーションを、そのまま、サービス遷移後のサービスに適用して処理を実行する。

　このアプリ継続処理によって、例えば、チヤンネル切り替え前後において、アプリの停止、起動等に起因する画面の途切れの発生等を防止でき、スムーズなサービス切り替え（チャンネル切り替え）が可能となる。

　　（ステップＳ１５）
　一方、ステップＳ１２において、サービス遷移の発生が確認され、ステプＳ１３において、サービス遷移前後でサービスカテゴリ識別子が一致しないことが確認された場合は、ステップＳ１５に進む。
　ステップＳ１５では、現在、実行中のアプリを停止し、遷移後のサービスのサービスカテゴリ識別子に応じた新たなアプリケーションを起動して、新たに起動したアプリケーションを適用して、遷移後のサービスに対する処理を実行する。

　このように、受信装置は、シグナリングデータとしてのＳＬＴに基づいて、例えば、図１１～図１４に示すサービスカテゴリ識別子に基づいて、サービス切り替え前後の各サービスに適用するアプリケーションが一致するか否かを事前に判定することができ、一致する場合は、実行中のアプリケーションを停止させることなく継続実行することができる。これにより、例えばチャンネル切り替え時の画面停止等を最小限にすることが可能となり、スムーズなサービス遷移が実現される。

　　［８．アプリケーション情報テーブル（ＡＩＴ）に、ブロードキャスト再生アプリの適用情報を記録した構成について］
　次に、アプリケーション情報テーブル（ＡＩＴ）に、ブロードキャスト再生アプリの適用情報を記録した構成について説明する。

　放送局等の送信装置２０から受信装置３０に提供され、受信装置３０において実行されるアプリケーションには、そのアプリケーションに関する属性情報や制御情報を記録したシグナリングデータとしてのアプリケーション情報テーブル（ＡＩＴ）がアプリケーションに対応付けて提供される。

　受信装置３０は、送信装置２０から受信したアプリケーションの起動、停止処理や、ライフサイクル等の制御情報を、送信装置２０からのシグナリングデータとして受信したアプリケーション情報テーブル（ＡＩＴ）から取得し、ＡＩＴの記述に従ってアプリケーションを実行する。
　上述したブロードキャスト再生アプリケーションや、その他のアプリケーション等、送信装置２０から受信装置３０に提供されるアプリケーションは、基本的に全て各アプリケーション対応のＡＩＴが送信装置２０から受信装置３０に提供される。

　以下に説明する構成は、放送局等の送信装置２０が送信するアプリケーションに対応するシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）に、そのＡＩＴが制御対象とするアプリケーションが、送信装置の提供番組等、提供サービスのレンダリング等の再生処理に適用可能か否かを示すフラグを設定した構成である。
　なお、このフラグを配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）と呼ぶ。

　具体的な配信アプリ識別フラグ設定の一例は以下の通りである。
　（ａ）放送局の提供サービス（番組コンテンツ）のレンダリング等の再生処理に適用可能なブロードキャスト再生アプリに対応するＡＩＴは、
　配信アプリ識別フラグ＝ｔｒｕｅ
　（ｂ）放送局の提供サービス（番組コンテンツ）のレンダリング等の再生処理に適用可能なブロードキャスト再生アプリ以外のアプリケーションに対応するＡＩＴは、
　配信アプリ識別フラグ＝ｆａｌｓｅ
　このような設定とする。

　受信装置は、放送局等の送信装置２０から提供されるアプリケーション、例えば、放送番組の再生処理に適用するブロードキャスト再生アプリケーションや、その他のアプリケーションを受信して実行する場合に、そのアプリケーションの制御メタデータ（シグナリングデータ）であるＡＩＴを受信し、参照することで、実行予定のアプリケーションが、番組再生に適用可能か否かを即座に判別することが可能となる。

　具体的には、例えばチャンネル切り替え後に実行するアプリケーションの実行前に、そのアプリケーションが番組再生に適用可能なアプリであるか否かを判別することが可能となる。
　従って、例えばチャンネル切り替え前に実行中のアプリケーションを停止すべきか停止不要かについて、チャンネル切り替えタイミングより前に判断することができ、不要なアプリケーションの停止処理や起動処理を省略することができ、画面中断の発生等を防止できる。

　図１６は、アプリケーション情報テーブル（ＡＩＴ）内の配信アプリ識別フラグ設定位置を説明する図である。
　アプリケーション情報テーブル（ＡＩＴ）は、シグナリングデータの１つの構成要素であり、例えば、図１６に示すサービスディスカバリ（ＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙ）要素４１０をルート要素にもつＸＭＬドキュメントとして、送信装置２０から受信装置３０に送信される。

　サービスディスカバリ（ＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙ）要素４１０の下位要素として設定されるアプリケーションディスカバリ要素４１１以下に、アプリケーションに関する属性情報や、制御情報が記録される。

　配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）は、例えば、図１６に示すように、その他の識別情報（ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ）要素４１２以下に設定する。
　すなわち、以下の設定位置にフラグを記録する設定とする。
　ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ／ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ／ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒの下に、
　新たにａｔｓｃ：ｃｏｎｔｉｎｕｏｕｓＣｏｍｐｏｎｅｎｔＳｕｐｐｏｒｔａｂｌｅというブーリアン（ｂｏｏｌｅａｎ）型の要素、すなわち真＝ｔｒｕｅ、偽＝ｆａｌｓｅの２値を設定可能な要素を導入する。

　このように、配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）を設定したアプリケーション情報テーブル（ＡＩＴ）を、ＸＭＬデータとして受信装置に提供する。

　図１７、および以下にＸＭＬデータとしてエンコーディングしたデータ例を示す。
　この例は、配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）＝ｔｒｕｅの場合のデータ例である。

＜ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ・・・＞・・・
　＜ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ・・・＞・・・
　　＜ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ・・・＞・・・
　　　＜ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ・・・＞・・・
　　　　＜ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ・・・＞・・・
　　　　　＜ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ・・・＞・・・
　　　　　　＜ａｔｓｃ：ＣｏｎｔｉｎｕｏｕｓＣｏｍｐｏｎｅｎｔＳｕｐｐｏｒｔａｂｌｅ＞ｔｒｕｅ＜／ａｔｓｃ：ＣｏｎｔｉｎｕｏｕｓＣｏｍｐｏｎｅｎｔＳｕｐｐｏｒｔａｂｌｅ＞・・・
　　　　　＜／ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ＞・・・
　　　　＜／ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ＞・・・
　　　＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞・・・
　　＜／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ＞・・・
　＜／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ＞・・・
＜／ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ＞

　受信装置は、放送局等の送信装置２０から提供されるアプリケーション、例えば、放送番組の再生処理に適用するブロードキャスト再生アプリケーションや、その他のアプリケーションを受信して実行する場合、そのアプリケーションの制御メタデータ（シグナリングデータ）として、上記の配信アプリ識別フラグを記録したＡＩＴを受信する。

　受信装置はＡＩＴの配信アプリ識別フラグを参照することで、実行予定のアプリケーションが、番組再生に適用可能か否かを即座に判別することが可能となる。

　図１８に示すフローチャートは、受信装置３０が放送局等の送信装置から提供される配信アプリケーション、および配信アプリに対応する制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を受信し、ＡＩＴから配信アプリ識別フラグを取得して、フラグに従ったアプリケーション制御を実行するシーケンスについて説明するフローチャートである。

　図１８に示すフローチャートに従った処理は、受信装置のデータ処理部（再生処理部等）において実行される。例えば、予め処理シーケンスを記録した再生制御プログラムを記憶部から読み出してプログラムに従った処理として実行される。
　各ステップの処理について説明する。

　　（ステップＳ２１）
　まず、受信装置は、ステップＳ２１において、放送局等の送信装置から提供される配信アプリケーション、および配信アプリに対応する制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を受信する。

　配信アプリは、例えば、放送局の提供する番組等のサービスのメインコンテンツの再生に適用するブロードキャスト再生アプリ、あるいは、番組再生に用いない、付随的なアプリケーションなど、様々である。
　アプリケーション情報テーブル（ＡＩＴ）は、各配信アプリに関する属性情報や制御情報を記録したシグナリングデータ（メタデータ）である。
　ＡＩＴには、図１６、図１７を参照して説明したように、配信アプリ識別フラグ、すなわち、
　放送局の提供する番組等のサービスのメインコンテンツの再生に適用するブロードキャスト再生アプリであるか（フラグ＝ｔｒｕｅ）、それ以外のアプリであるか（フラグ＝ｆａｌｓｅ）を示す配信アプリ識別フラグが記録されている。

　　（ステップＳ２２）
　受信装置は、ステップＳ２２において、受信した、あるいは受信予定の配信アプリ対応のアプリケーション情報テーブル（ＡＩＴ）を参照し、アプリケーション情報テーブル（ＡＩＴ）に記録された配信アプリ識別フラグの値を確認する。

　配信アプリ識別フラグ＝ｔｒｕｅの場合は、ステップＳ２３に進む。
　一方、配信アプリ識別フラグ＝ｆａｌｓｅの場合は、ステップＳ２４に進む。

　　（ステップＳ２３）
　ステップＳ２２におけるアプリケーション情報テーブル（ＡＩＴ）に記録された配信アプリ識別フラグの値を確認処理の結果、配信アプリ識別フラグ＝ｔｒｕｅの場合は、ステップＳ２３に進む。
　この場合、受信装置は、ステップＳ２３において、実行予定の配信アプリは、ブロードキャスト再生アプリであると判断し、配信アプリであるブロードキャスト再生アプリを起動して、サービスのメインコンテンツ（番組コンテンツ）の再生を実行する。

　　（ステップＳ２４）
　一方、ステップＳ２２におけるアプリケーション情報テーブル（ＡＩＴ）に記録された配信アプリ識別フラグの値を確認処理の結果、配信アプリ識別フラグ＝ｆａｌｓｅの場合は、ステップＳ２４に進む。

　この場合、受信装置は、ステップＳ２４において、実行予定の配信アプリは、ブロードキャスト再生アプリではなく、その他のブロードキャストアプリケーションであると判断し、現在実行中の再生アプリ（レジデンシャル再生アプリ、またはブロードキャスト再生アプリ）をそのまま継続し、さらに、配信アプリ（ブロードキャストアプリケーション）を実行する。

　すなわち、例えば、現在実行中の再生アプリ（レジデンシャル再生アプリ、またはブロードキャスト再生アプリ）をそのまま継続してサービスのメインコンテンツ（番組コンテンツ）の再生を継続し、さらに、並列にブロードキャストアプリケーションを実行して、その実行結果を並列出力する処理等を行う。

　このように、受信装置は、放送局から提供される配信アプリが、
　放送局の提供する番組等のサービスのメインコンテンツの再生に適用するブロードキャスト再生アプリであるか（フラグ＝ｔｒｕｅ）、
　それ以外のアプリであるか（フラグ＝ｆａｌｓｅ）について、
　配信アプリ対応のシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）に記録された配信アプリ識別フラグに基づいて確認することが可能となる。
　受信装置は、このフラグ確認結果に基づいて、アプリの起動、停止、継続等の処理を決定することができる。

　　［９．送信装置と受信装置の実行する処理の処理シーケンスについて］
　次に、図１９以下に示すシーケンス図を参照して、送信装置と受信装置の実行する処理の処理シーケンスについて説明する。

　以下の複数の処理例について、順次、説明する。
　（処理例１）受信装置において、レジデンシャル再生アプリを実行し、さらに、その後、ブロードキャストアプリケーションを併せて実行する処理例
　（処理例２）受信装置において、レジデンシャル再生アプリを実行し、その後、ＡＩＴ記述に基づいてブロードキャスト再生アプリを実行し、さらに次のＡＩＴ記述に基づいてレジデンシャル再生アプリを実行する処理例
　（処理例３）受信装置において、ＡＩＴ記述に基づいて、ブロードキャスト再生アプリを実行する処理例
　（処理例４）受信装置において、ＡＩＴ記述に基づいて、ブロードキャストアプリケーションを実行する処理例

　　［９－１．（処理例１）受信装置において、レジデンシャル再生アプリを実行し、さらに、その後、ブロードキャストアプリケーションを併せて実行する処理例］
　まず、図１９～図２０を参照して、（処理例１）受信装置において、レジデンシャル再生アプリを実行し、さらに、その後、ブロードキャストアプリケーション（ブロードキャスト再生アプリではない）を併せて実行する処理例について説明する。

　図１９、図２０には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素であるアプリサーバ、
　（ｂ）送信装置の構成要素であるＤＡＳＨサーバ、
　（ｃ）送信装置の構成要素である放送サーバ、
　（ｄ）受信装置の構成要素であるミドルウェア、
　（ｅ）受信装置の構成要素である再生処理部のレジデンシャルアプリ実行部、
　（ｆ）受信装置の構成要素である再生処理部のブロードキャストアプリ実行部、
　（ｇ）受信装置側のユーザ（番組視聴者等のサービス受領者）

　なお、「（ａ）送信装置の構成要素であるアプリサーバ」は、例えばブロードキャスト再生アプリ、あるいはその他のアプリケーション、さらに、各アプリケーションの制御情報等を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）等の生成処理、送信処理を実行する。
　また、「（ｂ）送信装置の構成要素であるＤＡＳＨサーバ」は、例えば、番組コンテンツを構成するＡＶセグメントの生成、送信、さらに、ＡＶセグメントの取得、再生処理に必要となる制御情報等を記録したシグナリングデータとしてのＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）等の生成処理、送信処理を実行する。
　さらに、「（ｃ）送信装置の構成要素である放送サーバ」は、サービス単位の制御情報、属性情報を通知するシグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）や、ＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）の生成、送信等を実行する。
　なお、アプリケーションの制御情報等を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）は、ＳＬＳに格納されて送信される場合もある。

　なお、送信装置の以下の構成要素、すなわち、
　（ａ）送信装置の構成要素であるアプリサーバ、
　（ｂ）送信装置の構成要素であるＤＡＳＨサーバ、
　（ｃ）送信装置の構成要素である放送サーバ、
　これらはそれぞれ独立したサーバとして構成してもよいし、全ての機能を実行する１つのサーバとして構成してもよい。

　（ｄ）受信装置の構成要素であるミドルウェアは、送信装置からのデータ受信を実行し、主にシグナリングデータの解析等を実行する。、
　（ｅ）受信装置の構成要素である再生処理部のレジデンシャルアプリ実行部は、レジデンシャル再生アプリ等、受信装置に内蔵された再生アプリやその地の内蔵アプリケーションを実行する。さらに、シグナリングデータであるＭＰＤの解析（パース）等を実行して、放送サービスのレンダリングを伴う再生処理を実行する。

　なお、レジデンシャル再生アプリには、ブラウザ上で実行されるウェブアプリケーションや、ブラウザとは無関係に実行可能な内蔵ビデオプレーヤ（Ｅｍｂｅｄｄｅｄ　Ｖｉｄｅｏ　Ｐｌａｙｅｒ）等、様々な種類がある。

　（ｆ）受信装置の構成要素である再生処理部のブロードキャストアプリ実行部は、送信装置から提供されるブロードキャスト再生アプリ、その他のアプリケーションを実行する。さらに、シグナリングデータであるＭＰＤの解析（パース）等を実行して、放送サービスのレンダリングを伴う再生処理を実行する。

　以下、図１９～図２０に示す各ステップの処理について、順次、説明する。

　　（ステップＳ１０１）
　ステップＳ１０１において、放送サーバが、シグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を送信する。
　サービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）は、先に、図９、図１０を参照して説明したように、各放送局や番組等、サービス単位の制御情報を記録したテーブルである。

　サービスリストテーブル（ＳＬＴ）は、図１０に示すように、
　サービス単位のサービスエントリを有し、各サービスエントリには、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの各データが記録されている。

　サービスシグナリングブートストラップアドレスは、各サービス単位のメタデータ（シグナリングデータ）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得するためのアドレスに相当する。

　受信装置（クライアント）３０は、あるチャンネルに設定し、受信予定のサービス（放送局、あるいは番組等）を決定すると、まず、最初にシグナリングデータであるサービスリストテーブル（ＳＬＴ）を取得する。
　さらに、取得したサービスリストテーブル（ＳＬＴ）に記録された決定された受領サービスに対応するサービスエントリを選択し、選択したサービスエントリに記録された情報、すなわち、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの情報を取得する。

　（ｐ）サービス単位の基本属性情報には、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。
　すなわち、サービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　少なくともこれらのいずれであるかを確認可能としたサービスカテゴリ識別子が記録されている。

　図１３、図１４を参照して説明したサービスカテゴリ識別子を利用した場合は、
　ブロードキャスト再生アプリ（専用タイプ）
　ブロードキャスト再生アプリ（共用タイプ）
　これらの区別も可能となる。

　また、サービスリストテーブル（ＳＬＴ）に記録されたサービス単位の（ｑ）サービスシグナリングブートストラップアドレスは、各サービス対応のシグナリングデータであるサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得するためのアドレス情報等が記録されている。
　受信装置（クライアント）は、このアドレスを用いて、サービス単位のメタデータ（シグナリングデータ）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　サービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）には、サービスに属する例えば図９に示す以下のデータ、すなわち、
　（ｂ）番組コンテンツ等の構成データとなるＡ／Ｖ／ＣＣ－ＤＡＳＨファイル、
　（ｃ）再生アプリケーションや、インデックスファイル、その他のアプリケーション等のノンリアルタイムデータによって構成されるＮＲＴファイル、
　これらのデータを取得するための情報や、再生に必要な情報等のサービス属性情報、制御情報が記録されている。

　受信装置（クライアント）は、サービス単位のメタデータ（シグナリング）であるＳ－ＴＳＩＤ等のサービスレベルシグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）に記録されたデータを用いて、サービス単位の提供データ（ＡＶコンテンツやアプリケーション）を受領して、再生処理を実行することができる。

　　（ステップＳ１０２）
　次に、受信装置のミドルウェアは、送信装置から受信したＳＬＴに基づいて、送信装置の提供サービスのリスト、例えば番組リストを表示部に表示する。

　　（ステップＳ１０３）
　受信装置側のユーザは、ステップＳ１０３において、受信装置の表示部に表示されたサービスリスト（番組リスト）から、視聴したい番組を選択する。すなわち受信サービスを決定する。
　決定情報は、受信装置のミドルウェアに入力される。
　本処理例においては、ユーザが、チャンネルＱの番組ｑ１を選択したのものとする。

　　（ステップＳ１０４）
　受信装置のミドルウェアは、ステップＳ１０４において、ユーザの選択したサービス（例えばサービス＝チャンネルＱ、またはサービス＝チャンネルＱの番組ｑ１）のサービスカテゴリを、ステップＳ１０２において受信したサービスリストテーブル（ＳＬＴ）を参照して確認する。

　前述したように、サービスリストテーブル（ＳＬＴ）には、各サービスの、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの情報が記録されている。
　さらに、（ｐ）サービス単位の基本属性情報として、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。

　受信装置のミドルウェアは、ステップＳ１０４において、ユーザの選択したサービスのサービスカテゴリ識別子を確認し、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　このいずれであるかを確認する。

　本処理例では、ユーザの選択したサービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）のサービスカテゴリ識別子が、レジデンシャル再生アプリの適用サービスであるとする。
　この場合、受信装置は、再生処理部において実行中のアプリケーションの確認を行い、再生処理部において、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを継続して実行させる。
　一方、再生処理部において、レジデンシャル再生アプリが未起動の場合は、レジデンシャル再生アプリの起動処理を実行する。

　例えば、チャンネルＱの設定前の設定チャンネル＝Ｐの番組ｐ１が、レジデンシャル再生アプリによって再生されていた場合等、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリをそのまま継続して実行させる。

　　（ステップＳ１０５）
　ステップＳ１０５は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ１０５において、シグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）を生成して送信する。
　ＭＰＤは、様々なサービス（番組コンテンツ）の制御情報を記録したシグナリングデータである。例えば、サービス（番組コンテンツ）を構成するＡＶコンテンツのセグメントファイルのアクセス情報等が記録されている。

　　（ステップＳ１０６）
　ステップＳ１０６は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ１０６において、サービス（番組）を構成するコンテンツであるＡＶセグメントを生成して送信する。

　　（ステップＳ１０７）
　ステップＳ１０７は、受信装置の再生処理部のレジデンシャルアプリ実行部の処理である。
　再生処理部は、送信装置から受信したＭＰＤを解析し、ＭＰＤに記録されたＡＶセグメントのアクセス情報を適用して、ＡＶセグメントを取得し、レジデンシャル再生アプリを適用して、サービス（番組）のコンテンツのレンダリング処理を含む再生処理を実行する。

　すなわち、ユーザの選択したサービスであるチャンネルＱの番組ｑ１の再生を、レジデンシャル再生アプリを適用して実行する。

　なお、このステップＳ１０７において再生処理対象とするサービスは、先のステップＳ１０４において、サービスカテゴリ識別子を確認したサービスである。
　すなわち、サービスリストテーブル（ＳＬＴ）のデータ確認によって、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリであることが確認されたサービス（番組）である。

　　（ステップＳ１０８）
　ステップＳ１０８は、送信装置のアプリサーバの処理である。
　アプリサーバは、ステップＳ１０８において、ブロードキャストアプリケーションと、その制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を生成する。

　なお、本処理例において、ステップＳ１０８において生成するアプリケーションは、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリではなく、再生アプリの実行に併せて実行可能な付随的なアプリケーションとしてのブロードキャストアプリケーションであるものとする。

　　（ステップＳ１０９）
　ステップＳ１０９は、送信装置の放送サーバの処理である。
　放送サーバは、ステップＳ１０８において、アプリサーバが生成したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を生成して送信する。

　ＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）は、サービス単位の制御情報、属性情報を記録したシグナリングデータである。
　先に、図９、図１０を参照て説明したように、受信装置は、先行して受信するサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に記録されたサービスエントリ内の記録情報に基づいて、ＳＬＳを取得することができる。

　　（ステップＳ１１０）
　ステップＳ１１０は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ１１０において、ステップＳ１０９で送信装置の放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、現在、受信装置の再生処理部において再生中のサービス（番組）に対応付けられた同一サービスに属するサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ１１１）
　ステップＳ１１１は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ１１１において、ブロードキャストアプリケーションを生成して送信する。
　送信処理は、放送波、またはネットワークを介して実行される。

　なお、ステップＳ１１１で送信されるアプリケーションは、例えば、現在受信装置において再生中のサービス（番組）に併せて出力されるデータの出力処理等を実行するアプリケーションである。

　具体的には、例えば、受信装置がステップＳ１０７でレジデンシャル再生アプリを適用しているサービス（チャンネルＱの番組ｑ１）が野球中継である場合、このステップＳ１１１で生成し受信装置に提供するアプリケーションは受信装置の表示部に野球選手の選手情報等のデータを出力するアプリケーションである。

　すなわち、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリではない、その他のブロードキャストアプリケーションである。

　　（ステップＳ１１２）
　ステップＳ１１２は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ１１０で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。
　このＳＬＳに含まれるＡＩＴは、ステップＳ１１１で、送信装置のアプリサーバが送信したブロードキャストアプリケーションの属性や制御情報を記録したＡＩＴである。

　受信装置のミドルウェアは、取得したＡＩＴに記録された配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）の値（ｔｒｕｅ、またはｆａｌｓｅ）を確認する。

　本処理例では、ステップＳ１１１で送信装置のアプリサーバが送信したアプリケーションは、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリではなく、番組付随のアプリケーションである。
　従って、配信アプリ識別フラグの値はｆａｌｓｅに設定されている。すなわち、このＡＩＴに対応付けらけれたアプリケーション（ステップＳ１１１で送信装置のアプリサーバが送信したアプリケーション）は、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリではないことが確認される。

　受信装置のミドルウェアは、この配信アプリ識別フラグ確認に基づいて、ステップＳ１１１で送信装置のアプリサーバが送信したアプリケーションを受信装置の再生処理部のブロードキャストアプリ実行部において起動して、実行させる。

　すなわち、受信装置の再生処理部は、レジデンシャル再生アプリを適用して番組（チャンネルＱの番組ｑ１）の再生を実行するとともに、ブロードキャストアプリ実行部において、番組に付随するアプリケーションも併せて並列に実行する。

　この処理によって、例えばレジデンシャル再生アプリを適用して野球中継が再生されるとともに、ブロードキャストアプリケーションを適用して生成される選手情報等のデータが、野球中継画面上にオーバーレイ（重畳）して出力される。

　なお、図１９～図２０を参照して説明したシーケンス中、様々なシグナリングデータ（ＳＬＴ、ＳＬＳ、ＡＩＴ、ＭＰＤ等）が送信装置から送信され、受信装置において受信されるが、図１９～図２０を参照して説明したシグナリングデータの送信タイミングや、受信タイミングは一例である。
　シグナリングデータは、送信装置から、継続的に繰り返し送信され、受信装置は、様々なタイミングで受信することが可能である。従って、シグナリングデータの送受信処理は、図１９～図２０を参照して説明した送受信タイミングと異なるタイミングで実行することが可能である。

　ＮＲＴ（ノンリアルタイム）コンテンツであるブロードキャスト再生アプリや、ブロードキャストアプリケーションについても、送信装置は、随時、繰り返し送信可能であり、これらのデータの送受信タイミングも図１９～図２０を参照して説明した送受信タイミングと異なるタイミングで実行可能である。

　また、送信装置が送信するシグナリングデータは、適宜、更新され、バージョン番号等によって更新の有無が確認可能な構成を持つ。受信装置は、受信したシグナリングデータのバージョンを確認し、受信済みのシグナリングデータより新しいシグナリングデータの受信を確認した場合は、受信済みのシグナリングデータを破棄して、更新されたシグナリングデータを記憶部に格納し、更新シグナリングデータを適用した処理を実行する。
　このような処理によって、受信装置では、随時、新しいシグナリングデータに従った処理が実行される。

　　［９－２．（処理例２）受信装置において、レジデンシャル再生アプリを実行し、その後、ＡＩＴ記述に基づいてブロードキャスト再生アプリを実行し、さらに次のＡＩＴ記述に基づいてレジデンシャル再生アプリを実行する処理例］
　次に、図２１～図２３を参照して、（処理例２）受信装置において、レジデンシャル再生アプリを実行し、その後、ＡＩＴ記述に基づいてブロードキャスト再生アプリを実行し、さらに次のＡＩＴ記述に基づいてレジデンシャル再生アプリを実行する処理例について説明する。

　図２１～図２３には、図１９、図２０と同様、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素であるアプリサーバ、
　（ｂ）送信装置の構成要素であるＤＡＳＨサーバ、
　（ｃ）送信装置の構成要素である放送サーバ、
　（ｄ）受信装置の構成要素であるミドルウェア、
　（ｅ）受信装置の構成要素である再生処理部のレジデンシャルアプリ実行部、
　（ｆ）受信装置の構成要素である再生処理部のブロードキャストアプリ実行部、
　（ｇ）受信装置側のユーザ（番組視聴者等のサービス受領者）
　これらの各構成要素は、先に図１９、図２０を参照して説明した処理と同様の処理を実行する。

　また、送信装置の以下の構成要素、すなわち、
　（ａ）送信装置の構成要素であるアプリサーバ、
　（ｂ）送信装置の構成要素であるＤＡＳＨサーバ、
　（ｃ）送信装置の構成要素である放送サーバ、
　これらはそれぞれ独立したサーバとして構成してもよいし、全ての機能を実行する１つのサーバとして構成してもよい。
　以下、図２１～図２３に示す各ステップの処理について、順次、説明する。

　　（ステップＳ１５１）
　ステップＳ１５１において、放送サーバが、シグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を送信する。
　サービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）は、先に、図９、図１０を参照して説明したように、各放送局や番組等、サービス単位の制御情報を記録したテーブルである。

　サービスリストテーブル（ＳＬＴ）は、図１０に示すように、
　サービス単位のサービスエントリを有し、各サービスエントリには、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの各データが記録されている。

　（ｐ）サービス単位の基本属性情報には、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。
　すなわち、サービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　少なくともこれらのいずれであるかを確認可能としたサービスカテゴリ識別子が記録されている。

　図１３、図１４を参照して説明したサービスカテゴリ識別子を利用した場合は、
　ブロードキャスト再生アプリ（専用タイプ）
　ブロードキャスト再生アプリ（共用タイプ）
　これらの区別も可能となる。

　　（ステップＳ１５２）
　次に、受信装置のミドルウェアは、送信装置から受信したＳＬＴに基づいて、送信装置の提供サービスのリスト、例えば番組リストを表示部に表示する。

　　（ステップＳ１５３）
　受信装置側のユーザは、ステップＳ１５３において、受信装置の表示部に表示されたサービスリスト（番組リスト）から、視聴したい番組を選択する。すなわち受信サービスを決定する。
　決定情報は、受信装置のミドルウェアに入力される。
　本処理例においては、ユーザが、チャンネルＱの番組ｑ１を選択したのものとする。

　　（ステップＳ１５４）
　受信装置のミドルウェアは、ステップＳ１５４において、ユーザの選択したサービス（例えばサービス＝チャンネルＱ、またはサービス＝チャンネルＱの番組ｑ１）のサービスカテゴリを、ステップＳ１５２において受信したサービスリストテーブル（ＳＬＴ）を参照して確認する。

　前述したように、サービスリストテーブル（ＳＬＴ）には、各サービスの、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの情報が記録されている。
　さらに、（ｐ）サービス単位の基本属性情報として、先に図１１、図１２を参照して説明したサービスカテゴリ識別子が記録されている。

　受信装置のミドルウェアは、ステップＳ１５４において、ユーザの選択したサービスのサービスカテゴリ識別子を確認し、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　このいずれであるかを確認する。

　本処理例では、ユーザの選択したサービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）のサービスカテゴリ識別子が、レジデンシャル再生アプリの適用サービスであるとする。
　この場合、受信装置は、再生処理部において実行中のアプリケーションの確認を行い、再生処理部において、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを継続して実行させる。
　一方、再生処理部において、レジデンシャル再生アプリが未起動の場合は、レジデンシャル再生アプリの起動処理を実行する。

　例えば、チャンネルＱの設定前の設定チャンネル＝Ｐの番組ｐ１が、レジデンシャル再生アプリによって再生されていた場合等、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリをそのまま継続して実行させる。

　　（ステップＳ１５５）
　ステップＳ１５５は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ１５５において、シグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）を生成して送信する。
　ＭＰＤは、様々なサービス（番組コンテンツ）の制御情報を記録したシグナリングデータである。例えば、サービス（番組コンテンツ）を構成するＡＶコンテンツのセグメントファイルのアクセス情報等が記録されている。

　　（ステップＳ１５６）
　ステップＳ１５６は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ１５６において、サービス（番組）を構成するコンテンツであるＡＶセグメントを生成して送信する。

　　（ステップＳ１５７）
　ステップＳ１５７は、受信装置の再生処理部のレジデンシャルアプリ実行部の処理である。
　再生処理部は、送信装置から受信したＭＰＤを解析し、ＭＰＤに記録されたＡＶセグメントのアクセス情報を適用して、ＡＶセグメントを取得し、レジデンシャル再生アプリを適用して、サービス（番組）のコンテンツのレンダリング処理を含む再生処理を実行する。

　すなわち、ユーザの選択したサービスであるチャンネルＱの番組ｑ１の再生を、レジデンシャル再生アプリを適用して実行する。

　なお、このステップＳ１５７において再生処理対象とするサービスは、先のステップＳ１５４において、サービスカテゴリ識別子を確認したサービスである。
　すなわち、サービスリストテーブル（ＳＬＴ）のデータ確認によって、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリであることが確認されたサービス（番組）である。

　　（ステップＳ１５８）
　ステップＳ１５８は、送信装置のアプリサーバの処理である。
　アプリサーバは、ステップＳ１５８において、ブロードキャスト再生アプリと、その制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を生成する。

　なお、本処理例において、ステップＳ１５８において生成するアプリケーションは、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリである。すなわち、ブロードキャスト再生アプリであるものとする。

　　（ステップＳ１５９）
　ステップＳ１５９は、送信装置の放送サーバの処理である。
　放送サーバは、ステップＳ１５８において、アプリサーバが生成したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を生成して送信する。

　ＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）は、サービス単位の制御情報、属性情報を記録したシグナリングデータである。
　先に、図９、図１０を参照て説明したように、受信装置は、先行して受信するサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に記録されたサービスエントリ内の記録情報に基づいて、ＳＬＳを取得することができる。

　　（ステップＳ１６０）
　ステップＳ１６０は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ１６０において、ステップＳ１５９で送信装置の放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、現在、受信装置の再生処理部において再生中のサービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）に対応付けられた同一サービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）に属するサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ１６１）
　ステップＳ１６１は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ１６１において、ブロードキャスト再生アプリを生成して送信する。
　送信処理は、放送波、またはネットワークを介して実行される。

　なお、ステップＳ１６１で送信されるアプリケーションは、現在受信装置において再生中のサービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）の再生処理に適用可能なブロードキャスト再生アプリである。

　受信装置がステップＳ１５７でレジデンシャル再生アプリを適用して再生しているサービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）の再生に適用可能なブロードキャスト再生アプリである。

　　（ステップＳ１６２）
　ステップＳ１６２は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ１６０で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。
　このＳＬＳに含まれるＡＩＴは、ステップＳ１６１で、送信装置のアプリサーバが送信したブロードキャスト再生アプリの属性や制御情報を記録したＡＩＴである。

　受信装置のミドルウェアは、取得したＡＩＴに記録された配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）の値（ｔｒｕｅ、またはｆａｌｓｅ）を確認する。

　本処理例では、ステップＳ１６１で送信装置のアプリサーバが送信したアプリケーションは、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリである。
　従って、配信アプリ識別フラグの値はｔｒｕｅに設定されている。すなわち、このＡＩＴに対応付けらけれたアプリケーション（ステップＳ１６１で送信装置のアプリサーバが送信したアプリケーション）は、サービスのメインコンテンツ（チャンネルＱの番組ｑ１）のＡＶセグメントの再生アプリとして適用可能であることが確認される。

　受信装置のミドルウェアは、この配信アプリ識別フラグ確認に基づいて、ステップＳ１６１で送信装置のアプリサーバが送信したブロードキャスト再生アプリを受信装置の再生処理部のブロードキャストアプリ実行部において起動して、実行させる。
　なお、このブロードキャスト再生アプリの起動に併せて、現在、再生処理部のレジデンシャルアプリ実行部においてメインコンテンツの再生に適用されているレジデンシャル再生アプリを停止する。

　このように、受信装置は、ＡＩＴの配信アプリ識別フラグの確認に基づいて、サービス（チャンネルＱ、またはチャンネルＱの番組ｑ１）の再生に適用される再生アプリを、レジデンシャル再生アプリから、ブロードキャスト再生アプリに切り替える処理を実行する。

　　（ステップＳ１６３）
　ステップＳ１６３は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ１６３において、サービス（例えばチャンネルＱの番組ｑ１）を構成するコンテンツであるＡＶセグメントを生成して送信する。

　　（ステップＳ１６４）
　ステップＳ１６４は、受信装置の再生処理部のブロードキャストアプリ実行部の処理である。
　再生処理部のブロードキャストアプリ実行部は、送信装置から受信したＭＰＤを解析し、ＭＰＤに記録されたＡＶセグメントのアクセス情報を適用して、ＡＶセグメントを取得し、ブロードキャスト再生アプリを適用して、サービス（例えばチャンネルＱの番組ｑ１）のコンテンツのレンダリング処理を含む再生処理を実行する。

　　　（ステップＳ１６５）
　ステップＳ１６５は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ１６５において、放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、現在、受信装置の再生処理部において再生中のサービス（チャンネルＱの番組ｑ１）に対応付けられた同一サービスに属するサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ１６６）
　ステップＳ１６６は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ１６５で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。

　受信装置のミドルウェアは、このＳＬＳに含まれるＡＩＴが、ステップＳ１６１で、送信装置のアプリサーバが送信したブロードキャスト再生アプリの属性や制御情報を記録したＡＩＴであることが確認された場合、その記述内容を確認する。
　受信装置のミドルウェアは、このＡＩＴが、現在、再生処理部において実行中のブロードキャスト再生アプリの停止命令を記述したＡＩＴであることが確認された場合、実行中のブロードキャスト再生アプリを停止し、レジデンシャル再生アプリを起動する処理を実行する。

　このように、受信装置は、ＡＩＴの記録データに基づいて、サービスの再生に適用される再生アプリを、ブロードキャスト再生アプリから、レジデンシャル再生アプリに切り替える処理を実行する。

　　（ステップＳ１６７）
　ステップＳ１６７は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ１６７において、放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、現在、受信装置の再生処理部において再生中のサービス（チャンネルＱの番組ｑ１）に対応付けられた同一サービスに属するサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ１６８）
　ステップＳ１６８は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ１６８において、ブロードキャストアプリケーションを生成して送信する。
　送信処理は、放送波、またはネットワークを介して実行される。

　なお、ステップＳ１６８で送信されるアプリケーションは、例えば、現在受信装置において再生中のサービス（チャンネルＱの番組ｑ１）に併せて出力されるデータの出力処理等を実行するアプリケーションである。

　具体的には、例えば、受信装置がステップＳ１６６において起動したレジデンシャル再生アプリを適用しているサービス（チャンネルＱの番組ｑ１）が野球中継である場合、このステップＳ１６８で生成し受信装置に提供するアプリケーションは受信装置の表示部に野球選手の選手情報等のデータを出力するアプリケーションである。

　すなわち、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリではない、その他のブロードキャストアプリケーションである。

　　（ステップＳ１６９）
　ステップＳ１６９は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ１６７で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。
　このＳＬＳに含まれるＡＩＴは、ステップＳ１６８で、送信装置のアプリサーバが送信したブロードキャストアプリケーションの属性や制御情報を記録したＡＩＴである。

　受信装置のミドルウェアは、取得したＡＩＴに記録された配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）の値（ｔｒｕｅ、またはｆａｌｓｅ）を確認する。

　本処理例では、ステップＳ１６８で送信装置のアプリサーバが送信したアプリケーションは、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリではなく、番組付随のアプリケーションである。
　従って、配信アプリ識別フラグの値はｆａｌｓｅに設定されている。すなわち、このＡＩＴに対応付けらけれたアプリケーション（ステップＳ１６８で送信装置のアプリサーバが送信したアプリケーション）は、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリではないことが確認される。

　受信装置のミドルウェアは、この配信アプリ識別フラグ確認に基づいて、ステップＳ１６８で送信装置のアプリサーバが送信したアプリケーションを受信装置の再生処理部のブロードキャストアプリ実行部において起動して、実行させる。

　すなわち、受信装置の再生処理部は、レジデンシャル再生アプリを適用して番組再生を実行するとともに、ブロードキャストアプリ実行部において、番組に付随するアプリケーションも併せて並列に実行する。

　この処理によって、例えばレジデンシャル再生アプリを適用して野球中継が再生されるとともに、ブロードキャストアプリケーションを適用して生成される選手情報等のデータが、野球中継画面上にオーバーレイ（重畳）して出力される。

　なお、図２１～図２３を参照して説明したシーケンス中、様々なシグナリングデータ（ＳＬＴ、ＳＬＳ、ＡＩＴ、ＭＰＤ等）が送信装置から送信され、受信装置において受信されるが、図２１～図２３を参照して説明したシグナリングデータの送信タイミングや、受信タイミングは一例である。
　シグナリングデータは、送信装置から、継続的に繰り返し送信され、受信装置は、様々なタイミングで受信することが可能である。従って、シグナリングデータの送受信処理は、図２１～図２３を参照して説明した送受信タイミングと異なるタイミングで実行することが可能である。

　ＮＲＴ（ノンリアルタイム）コンテンツであるブロードキャスト再生アプリや、ブロードキャストアプリケーションについても、送信装置は、随時、繰り返し送信可能であり、これらのデータの送受信タイミングも図２１～図２３を参照して説明した送受信タイミングと異なるタイミングで実行可能である。

　また、送信装置が送信するシグナリングデータは、適宜、更新され、バージョン番号等によって更新の有無が確認可能な構成を持つ。受信装置は、受信したシグナリングデータのバージョンを確認し、受信済みのシグナリングデータより新しいシグナリングデータの受信を確認した場合は、受信済みのシグナリングデータを破棄して、更新されたシグナリングデータを記憶部に格納し、更新シグナリングデータを適用した処理を実行する。
　このような処理によって、受信装置では、随時、新しいシグナリングデータに従った処理が実行される。

　　［９－３．（処理例３）受信装置において、ＡＩＴ記述に基づいて、ブロードキャスト再生アプリを実行する処理例］
　次に、図２４、図２５を参照して、（処理例３）受信装置において、ＡＩＴ記述に基づいて、ブロードキャスト再生アプリを実行する処理例について説明する。

　以下、図２４～図２５に示す各ステップの処理について、順次、説明する。

　　（ステップＳ２０１）
　ステップＳ２０１において、放送サーバが、シグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を送信する。
　サービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）は、先に、図９、図１０を参照して説明したように、各放送局や番組等、サービス単位の制御情報を記録したテーブルである。

　サービスリストテーブル（ＳＬＴ）は、図１０に示すように、
　サービス単位のサービスエントリを有し、各サービスエントリには、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの各データが記録されている。
　さらに、（ｐ）サービス単位の基本属性情報には、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。
　すなわち、サービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　少なくともこれらのいずれであるかを確認可能としたサービスカテゴリ識別子が記録されている。

　図１３、図１４を参照して説明したサービスカテゴリ識別子を利用した場合は、
　ブロードキャスト再生アプリ（専用タイプ）
　ブロードキャスト再生アプリ（共用タイプ）
　これらの区別も可能となる。

　　（ステップＳ２０２）
　次に、受信装置のミドルウェアは、送信装置から受信したＳＬＴに基づいて、送信装置の提供サービスのリスト、例えば番組リストを表示部に表示する。

　　（ステップＳ２０３）
　受信装置側のユーザは、ステップＳ２０３において、受信装置の表示部に表示されたサービスリスト（番組リスト）から、視聴したい番組を選択する。すなわち受信サービスを決定する。
　決定情報は、受信装置のミドルウェアに入力される。
　本処理例においては、ユーザが、現在視聴中のチャンネルＱの番組ｑ１から、チャンネルを変更して、チャンネルＲの番組ｒ１を選択したのものとする。

　　（ステップＳ２０４）
　受信装置のミドルウェアは、ステップＳ２０４において、ユーザの選択したサービス（例えばサービス＝チャンネルＲ、またはサービス＝チャンネルＲの番組ｒ１）のサービスカテゴリを、ステップＳ２０２において受信したサービスリストテーブル（ＳＬＴ）を参照して確認する。

　前述したように、サービスリストテーブル（ＳＬＴ）には、各サービスの、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの情報が記録されている。
　さらに、（ｐ）サービス単位の基本属性情報として、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。

　受信装置のミドルウェアは、ステップＳ２０４において、ユーザの選択したサービス（チャンネルＲ、またはチャンネルＲの番組ｒ１）のサービスカテゴリ識別子を確認し、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　このいずれであるかを確認する。

　本処理例では、ユーザの選択したサービス（チャンネルＲ、またはチャンネルＲの番組ｒ１）のサービスカテゴリ識別子が、ブロードキャスト再生アプリの適用サービスであるとする。
　この場合、受信装置は、再生処理部において実行中のアプリケーションの確認を行い、再生処理部において、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを停止させる。

　例えば、チャンネルＲの設定前の設定チャンネル＝Ｑの番組ｑ１が、レジデンシャル再生アプリによって再生されていた場合等、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを停止させる。

　　（ステップＳ２０５）
　ステップＳ２０５は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ２０５において、ブロードキャスト再生アプリと、その制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を生成する。

　なお、本処理例において、ステップＳ２０５において生成するアプリケーションは、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリである。すなわち、ブロードキャスト再生アプリであるものとする。

　　（ステップＳ２０６）
　ステップＳ２０６は、送信装置の放送サーバの処理である。
　放送サーバは、ステップＳ２０６において、アプリサーバが生成したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を生成して送信する。

　ＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）は、サービス単位の制御情報、属性情報を記録したシグナリングデータである。
　先に、図９、図１０を参照て説明したように、受信装置は、先行して受信するサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に記録されたサービスエントリ内の記録情報に基づいて、ＳＬＳを取得することができる。

　　（ステップＳ２０７）
　ステップＳ２０７は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ２０７において、ステップＳ２０６で送信装置の放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、ユーザが選択したサービス（チャンネルＲ、またはチャンネルＲの番組ｒ１）に対応付けられた同一サービス（チャンネルＲ、またはチャンネルＲの番組ｒ１）に属するサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ２０８）
　ステップＳ２０８は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ２０８において、ブロードキャスト再生アプリを生成して送信する。
　送信処理は、放送波、またはネットワークを介して実行される。

　なお、ステップＳ２０８で送信されるアプリケーションは、ユーザの選択したサービス（チャンネルＲの番組ｒ１）の再生処理に適用可能なブロードキャスト再生アプリである。

　　（ステップＳ２０９）
　ステップＳ２０９は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ２０７で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。
　このＳＬＳに含まれるＡＩＴは、ステップＳ２０８で、送信装置のアプリサーバが送信したブロードキャストアプリケーションの属性や制御情報を記録したＡＩＴである。

　受信装置のミドルウェアは、取得したＡＩＴに記録された配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）の値（ｔｒｕｅ、またはｆａｌｓｅ）を確認する。

　本処理例では、ステップＳ２０８で送信装置のアプリサーバが送信したアプリケーションは、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリとしてのブロードキャスト再生アプリである。
　従って、配信アプリ識別フラグの値はｔｒｕｅに設定されている。すなわち、このＡＩＴに対応付けらけれたアプリケーション（ステップＳ２０８で送信装置のアプリサーバが送信したアプリケーション）は、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリであることが確認される。

　受信装置のミドルウェアは、この配信アプリ識別フラグ確認に基づいて、ステップＳ２０８で送信装置のアプリサーバが送信したブロードキャスト再生アプリを受信装置の再生処理部のブロードキャストアプリ実行部において起動して、実行させる。
　これにより、ユーザの選択したサービス（チャンネルＲの番組ｒ１）の受信、再生準備が完了する。

　　（ステップＳ２１０）
　ステップＳ２１０は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ２１０において、シグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）を生成して送信する。
　ＭＰＤは、様々なサービス（番組コンテンツ）の制御情報を記録したシグナリングデータである。例えば、サービス（番組コンテンツ）を構成するＡＶコンテンツのセグメントファイルのアクセス情報等が記録されている。

　　（ステップＳ２１１）
　ステップＳ２１１は、送信装置のＤＡＳＨサーバの処理である。
　ＤＡＳＨサーバは、ステップＳ２１１において、サービス（チャンネルＲの番組ｒ１）を構成するコンテンツであるＡＶセグメントを生成して送信する。

　　（ステップＳ２１２）
　ステップＳ２１２は、受信装置の再生処理部のブロードキャストアプリ実行部の処理である。
　再生処理部は、送信装置から受信したＭＰＤを解析し、ＭＰＤに記録されたＡＶセグメントのアクセス情報を適用して、ＡＶセグメントを取得し、ブロードキャスト再生アプリを適用して、サービス（チャンネルＲの番組ｒ１）のコンテンツのレンダリング処理を含む再生処理を実行する。

　すなわち、ユーザの選択したサービスであるチャンネルＱの番組ｑ１の再生を、レジデンシャル再生アプリを適用して実行する。

　なお、このステップＳ２１０において再生処理対象とするサービスは、先のステップＳ２０４において、サービスカテゴリ識別子を確認したサービスである。
　すなわち、サービスリストテーブル（ＳＬＴ）のデータ確認によって、ユーザの選択したサービス（放送局Ｒの番組ｒ１）対応のデータの処理に適用するアプリケーションが、
　ブロードキャスト再生アプリであることが確認されたサービス（番組）である。

　これらの処理によって、例えばレジデンシャル再生アプリを適用して再生されていた遷移前のサービス（チャンネルＱの番組ｑ１）は停止し、ユーザの選択した遷移先サービス（チャンネルＲの番組ｒ１）が、ブロードキャスト再生アプリを適用して再生されることになる。

　なお、図２４～図２５を参照して説明したシーケンス中、様々なシグナリングデータ（ＳＬＴ、ＳＬＳ、ＡＩＴ、ＭＰＤ等）が送信装置から送信され、受信装置において受信されるが、図２４～図２５を参照して説明したシグナリングデータの送信タイミングや、受信タイミングは一例である。
　シグナリングデータは、送信装置から、継続的に繰り返し送信され、受信装置は、様々なタイミングで受信することが可能である。従って、シグナリングデータの送受信処理は、図２４～図２５を参照して説明した送受信タイミングと異なるタイミングで実行することが可能である。

　ＮＲＴ（ノンリアルタイム）コンテンツであるブロードキャスト再生アプリや、ブロードキャストアプリケーションについても、送信装置は、随時、繰り返し送信可能であり、これらのデータの送受信タイミングも図２４～図２５を参照して説明した送受信タイミングと異なるタイミングで実行可能である。

　また、送信装置が送信するシグナリングデータは、適宜、更新され、バージョン番号等によって更新の有無が確認可能な構成を持つ。受信装置は、受信したシグナリングデータのバージョンを確認し、受信済みのシグナリングデータより新しいシグナリングデータの受信を確認した場合は、受信済みのシグナリングデータを破棄して、更新されたシグナリングデータを記憶部に格納し、更新シグナリングデータを適用した処理を実行する。
　このような処理によって、受信装置では、随時、新しいシグナリングデータに従った処理が実行される。

　　［９－４．（処理例４）受信装置において、ＡＩＴ記述に基づいて、ブロードキャストアプリケーションを実行する処理例］
　次に、図２６、図２７を参照して、（処理例４）受信装置において、ＡＩＴ記述に基づいて、ブロードキャストアプリケーション（ブロードキャスト再生アプリではない）を実行する処理例について説明する。

　以下、図２６～図２７に示す各ステップの処理について、順次、説明する。

　　（ステップＳ３０１）
　ステップＳ３０１において、放送サーバが、シグナリングデータであるサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）を送信する。
　サービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）は、先に、図９、図１０を参照して説明したように、各放送局や番組等、サービス単位の制御情報を記録したテーブルである。

　サービスリストテーブル（ＳＬＴ）は、図１０に示すように、
　サービス単位のサービスエントリを有し、各サービスエントリには、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの各データが記録されている。
　さらに、（ｐ）サービス単位の基本属性情報には、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。
　すなわち、サービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　少なくともこれらのいずれであるかを確認可能としたサービスカテゴリ識別子が記録されている。

　図１３、図１４を参照して説明したサービスカテゴリ識別子を利用した場合は、
　ブロードキャスト再生アプリ（専用タイプ）
　ブロードキャスト再生アプリ（共用タイプ）
　これらの区別も可能となる。

　　（ステップＳ３０２）
　次に、受信装置のミドルウェアは、送信装置から受信したＳＬＴに基づいて、送信装置の提供サービスのリスト、例えば番組リストを表示部に表示する。

　　（ステップＳ３０３）
　受信装置側のユーザは、ステップＳ３０３において、受信装置の表示部に表示されたサービスリスト（番組リスト）から、視聴したい番組を選択する。すなわち受信サービスを決定する。
　決定情報は、受信装置のミドルウェアに入力される。
　本処理例においては、ユーザが、現在視聴中のチャンネルＱの番組ｑ１から、アプリベースのサービスを選択したのものとする。

　　（ステップＳ３０４）
　受信装置のミドルウェアは、ステップＳ３０４において、ユーザの選択したサービス（例えばサービス＝アプリベースサービス）のサービスカテゴリを、ステップＳ３０２において受信したサービスリストテーブル（ＳＬＴ）を参照して確認する。

　前述したように、サービスリストテーブル（ＳＬＴ）には、各サービスの、
　（ｐ）サービス単位の基本属性情報、
　（ｑ）サービスシグナリングブートストラップアドレス、
　これらの情報が記録されている。
　さらに、（ｐ）サービス単位の基本属性情報として、先に図１１～図１４を参照して説明したサービスカテゴリ識別子が記録されている。

　受信装置のミドルウェアは、ステップＳ３０４において、ユーザの選択したサービス（アプリベースサービス）のサービスカテゴリ識別子を確認し、ユーザの選択したサービス対応のデータの処理に適用するアプリケーションが、
　レジデンシャル再生アプリ、
　ブロードキャスト再生アプリ、
　その他のブロードキャストアプリケーション、
　このいずれであるかを確認する。

　本処理例では、ユーザの選択したサービス（アプリベースサービス）のサービスカテゴリ識別子は、その他のブロードキャストアプリケーション、すなわちブロードキャストアプリケーションの適用サービスであるとする。
　この場合、受信装置は、再生処理部において実行中のアプリケーションの確認を行い、再生処理部において、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを停止させる。

　例えば、サービス遷移前の設定チャンネル＝Ｑの番組ｑ１が、レジデンシャル再生アプリによって再生されていた場合等、レジデンシャル再生アプリが起動中の場合は、レジデンシャル再生アプリを停止させる。

　　（ステップＳ３０５）
　ステップＳ３０５は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ３０５において、ユーザの選択したアプリベースサービスの実行に適用されるブロードキャストアプリケーションと、その制御情報を記録したシグナリングデータであるアプリケーション情報テーブル（ＡＩＴ）を生成する。

　なお、本処理例において、ステップＳ３０５において生成するアプリケーションは、サービスを構成するメインコンテンツである番組そのものを構成するＡＶセグメントの再生処理に適用される再生アプリではない。すなわち、ブロードキャスト再生アプリとは異なるアプリベースサービスの実行に適用するブロードキャストアプリケーションであるものとする。

　　（ステップＳ３０６）
　ステップＳ３０６は、送信装置の放送サーバの処理である。
　放送サーバは、ステップＳ３０６において、アプリサーバが生成したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を生成して送信する。

　ＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）は、サービス単位の制御情報、属性情報を記録したシグナリングデータである。
　先に、図９、図１０を参照て説明したように、受信装置は、先行して受信するサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に記録されたサービスエントリ内の記録情報に基づいて、ＳＬＳを取得することができる。

　　（ステップＳ３０７）
　ステップＳ３０７は、受信装置のミドルウェアの処理である。
　受信装置のミドルウェアは、ステップＳ３０７において、ステップＳ３０６で送信装置の放送サーバが送信したアプリケーション情報テーブル（ＡＩＴ）を格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）を取得する。

　これは、ユーザが選択したサービス（アプリベースサービス）に対応付けられたサービス対応のシグナリングデータとして送信装置から送信されたＳＬＳである。

　　（ステップＳ３０８）
　ステップＳ３０８は、送信装置のアプリサーバの処理である。
　送信装置のアプリサーバは、ステップＳ３０８において、ブロードキャストアプリケーションを生成して送信する。
　送信処理は、放送波、またはネットワークを介して実行される。

　なお、ステップＳ３０８で送信されるアプリケーションは、ユーザの選択したサービス（アプリベースサービス）の実行に適用可能なブロードキャストアプリケーションである。

　　（ステップＳ３０９）
　ステップＳ３０９は、受信装置のミドルウェア、および再生処理部のブロードキャストアプリ実行部の処理である。
　受信装置のミドルウェアは、ステップＳ３０７で受信したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）から、アプリケーション情報テーブル（ＡＩＴ）を取得する。
　このＳＬＳに含まれるＡＩＴは、ステップＳ３０８で、送信装置のアプリサーバが送信したブロードキャストアプリケーションの属性や制御情報を記録したＡＩＴである。

　受信装置のミドルウェアは、取得したＡＩＴに記録された配信アプリ識別フラグ（Ｃｏｎｔｉｎｕｏｕｓ　Ｃｏｍｐｏｎｅｎｔ　Ｓｕｐｐｏｒｔａｂｌｅ　ｆｌｕｇ）の値（ｔｒｕｅ、またはｆａｌｓｅ）を確認する。

　本処理例では、ステップＳ３０８で送信装置のアプリサーバが送信したアプリケーションは、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリであるブロードキャスト再生アプリではない、その他の処理を実行するブロードキャストアプリケーションである。
　従って、配信アプリ識別フラグの値はｆａｌｓｅに設定されている。すなわち、このＡＩＴに対応付けらけれたアプリケーション（ステップＳ３０８で送信装置のアプリサーバが送信したアプリケーション）は、サービスのメインコンテンツ（番組）のＡＶセグメントの再生アプリではないことが確認される。

　受信装置のミドルウェアは、この配信アプリ識別フラグ確認に基づいて、ステップＳ３０８で送信装置のアプリサーバが送信したブロードキャストアプリケーションを受信装置の再生処理部のブロードキャストアプリ実行部において起動して、実行させる。
　これにより、ユーザの選択したサービス（アプリベースサービス）の受信、および実行が開始される。

　これらの処理によって、例えばレジデンシャル再生アプリを適用して再生されていた遷移前のサービス（チャンネルＱの番組ｑ１）は停止し、ユーザの選択した遷移先サービス（アプリベースサービス）が、ブロードキャストアプリケーションを適用して実行されることになる。

　なお、図２６～図２７を参照して説明したシーケンス中、様々なシグナリングデータ（ＳＬＴ、ＳＬＳ、ＡＩＴ、ＭＰＤ等）が送信装置から送信され、受信装置において受信されるが、図２６～図２７を参照して説明したシグナリングデータの送信タイミングや、受信タイミングは一例である。
　シグナリングデータは、送信装置から、継続的に繰り返し送信され、受信装置は、様々なタイミングで受信することが可能である。従って、シグナリングデータの送受信処理は、図２６～図２７を参照して説明した送受信タイミングと異なるタイミングで実行することが可能である。

　ＮＲＴ（ノンリアルタイム）コンテンツであるブロードキャスト再生アプリや、ブロードキャストアプリケーションについても、送信装置は、随時、繰り返し送信可能であり、これらのデータの送受信タイミングも図２４～図２５を参照して説明した送受信タイミングと異なるタイミングで実行可能である。

　また、送信装置が送信するシグナリングデータは、適宜、更新され、バージョン番号等によって更新の有無が確認可能な構成を持つ。受信装置は、受信したシグナリングデータのバージョンを確認し、受信済みのシグナリングデータより新しいシグナリングデータの受信を確認した場合は、受信済みのシグナリングデータを破棄して、更新されたシグナリングデータを記憶部に格納し、更新シグナリングデータを適用した処理を実行する。
　このような処理によって、受信装置では、随時、新しいシグナリングデータに従った処理が実行される。

　　［１０．送信装置と受信装置の構成例について］
　次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０の装置構成例について、図２８、図２９を参照して説明する。

　図２８には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
　送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
　受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
　データ処理部には通信データ処理部７７１ａ、再生処理部７７１ｂが含まれる。

　送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供する番組データ等を構成するＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータ等の生成、送信処理を行う。

　通信部７５２は、番組データ等を構成するＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータ等の配信処理等の通信処理を行う。
　記憶部７５３は配信対象とする番組データ等を構成するＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータなどが格納される。
　さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。

　一方、受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
　通信部７７２は、送信装置（サーバ）２０から配信されるデータ、例えば番組データ等を構成するＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータ等を受信する。

　データ処理部７７１は、通信データ処理部７７１ａ、再生処理部７７１ｂを有し、例えば先に説明した実施例に従った処理等を実行する。
　具体的には、ＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータ等を利用したデータ処理等を実行する。

　ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、インストール等の様々なコマンドは入力部７７４を介して入力される。
　再生データは表示部やスピーカ等の出力部７７５に出力される。
　記憶部７７３は番組データ等を構成するＡＶセグメントや、アプリケーション、その他の様々なデータや、シグナリングデータなどが格納される。
　さらに、記憶部７７３は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。

　図２９は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。

　ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。

　ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。

　入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。

　入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。

　なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。

　　［１１．本開示の構成のまとめ］
　以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信する通信部と、
　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理部を有する受信装置。

　（２）　前記アプリケーションは、
　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
　前記サービスカテゴリ識別子は、
　（ａ）受信装置常駐型の再生アプリであるレジデンシャル再生アプリ、
　（ｂ）送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリ、
　上記（ａ），（ｂ）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である（１）に記載の受信装置。

　（３）　前記データ処理部は、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが、いずれもレジデンシャル再生アプリである場合、サービス遷移前のアプリケーションの継続処理を行なう（２）に記載の受信装置。

　（４）　前記アプリケーションは、
　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
　前記サービスカテゴリ識別子は、
　（ｂ１）送信装置の提供サービス専用の再生アプリであり、複数の異なるサービスに対する再生処理に適用可能な共用型ブロードキャスト再生アプリ、
　（ｂ２）送信装置の提供サービス専用の再生アプリであり、１つのサービスに対する再生処理にのみ適用可能な専用型ブロードキャスト再生アプリ、
　上記（ｂ１），（ｂ２）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である（１）～（３）いずれかに記載の受信装置。

　（５）　前記データ処理部は、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが、いずれも共用型ブロードキャスト再生アプリである場合、サービス遷移前のアプリケーションの継続処理を行なう（４）に記載の受信装置。

　（６）　前記通信部は、
　前記サービスカテゴリ識別子を、送信装置の送信するシグナリングデータとして受信する（１）～（５）いずれかに記載の受信装置。

　（７）　前記シグナリングデータは、サービス単位の情報を記録したサービスエントリを格納したサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）である（６）に記載の受信装置。

　（８）前記サービスカテゴリ識別子は、
　放送局単位のサービス、または放送局の提供する番組単位のサービス、少なくともいずれかのサービスに対応付けて設定された識別子である（１）～（７）いずれかに記載の受信装置。

　（９）　前記データ処理部は、
　受信チャンネルの切り替え時に、チャンネル切り替え前後の番組再生に適用するアプリケーションが同一であるか否かを、前記サービスカテゴリ識別子に基づいて判断し、チャンネル切り替え前後の番組再生に適用するアプリケーションが同一であることを確認した場合、チャンネル切り替え前に実行中のアプリケーションの継続処理を行なう（１）＝（８）いずれかに記載の受信装置。

　（１０）　前記通信部は、さらに、
　前記送信装置から受信するアプリケーションが、前記送信装置の提供するサービスの再生処理に適用する再生アプリであるか否かを示す配信アプリ識別フラグを受信し、
　前記データ処理部は、
　前記配信アプリ識別フラグの値に基づいて、アプリケーション制御を実行する（１）～（９）いずれかに記載の受信装置。

　（１１）　前記データ処理部は、
　前記配信アプリ識別フラグの値が、再生アプリであることを示す場合は、送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリを実行し、
　前記配信アプリ識別フラグの値が、再生アプリでないことを示す場合は、送信装置が提供するブロードキャストアプリケーションを実行する（１０）に記載の受信装置。

　（１２）　前記配信アプリ識別フラグは、
　送信装置が提供するアプリケーションに対応する制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記録された構成である（１０）または（１１）に記載の受信装置。

　（１３）　受信装置において利用可能なサービスの構成データと、
　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
　前記サービスに適用するアプリケーションを送信する通信部を有する送信装置。

　（１４）　前記アプリケーションは、
　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
　前記サービスカテゴリ識別子は、
　（ａ）受信装置常駐型の再生アプリであるレジデンシャル再生アプリ、
　（ｂ）送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリ、
　上記（ａ），（ｂ）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である（１３）に記載の送信装置。

　（１５）　前記アプリケーションは、
　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
　前記サービスカテゴリ識別子は、
　（ｂ１）送信装置の提供サービス専用の再生アプリであり、複数の異なるサービスに対する再生処理に適用可能な共用型ブロードキャスト再生アプリ、
　（ｂ２）送信装置の提供サービス専用の再生アプリであり、１つのサービスに対する再生処理にのみ適用可能な専用型ブロードキャスト再生アプリ、
　上記（ｂ１），（ｂ２）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である（１３）～（１４）いずれかに記載の送信装置。

　（１６）前記通信部は、
　サービス単位の情報を記録したサービスエントリを格納したサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に前記サービスカテゴリ識別子を記録して送信する（１３）～（１５）いずれかに記載の送信装置。

　（１７）　前記サービスカテゴリ識別子は、
　放送局単位のサービス、または放送局の提供する番組単位のサービス、少なくともいずれかのサービスに対応付けて設定された識別子である（１３）～（１６）いずれかに記載の送信装置。

　（１８）　前記通信部は、さらに、
　前記送信装置の送信アプリケーションが、前記送信装置の提供するサービスの再生処理に適用する再生アプリであるか否かを示す配信アプリ識別フラグを送信する（１３）～（１７）いずれかに記載の受信装置。

　（１９）　受信装置において実行するデータ処理方法であり、
　通信部が、
　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信し、
　データ処理部が、
　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理方法。

　（２０）　送信装置において実行するデータ処理方法であり、
　受信装置において利用可能なサービスの構成データと、
　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
　前記サービスに適用するアプリケーションを送信するデータ処理方法。

　また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

　なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

　以上、説明したように、本開示の一実施例の構成によれば、受信装置において適用する再生アプリを、事前に受信可能なＳＬＴに記録したサービスカテゴリ識別子を用いて決定可能な構成が実現される。
　具体的には、送信装置の提供番組等、提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信装置に送信する。サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なう。サービスカテゴリ識別子は、レジデンシャル再生アプリ、ブロードキャスト再生アプリ、これらのいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である。
　本構成により、受信装置において適用する再生アプリを、事前に受信可能なＳＬＴに記録したサービスカテゴリ識別子を用いて決定可能な構成が実現される。

　　１０　通信システム
　　２０　送信装置
　　２１　放送サーバ
　　２２　データ配信サーバ
　　３０　受信装置
　　３１　ＴＶ
　　３２　ＰＣ
　　３３　携帯端末
　　５０　シグナリングデータ
　　６０　ＡＶセグメント
　　７０　その他のデータ
　１１０　ミドルウェア
　１１１　通信部（ＰＨＹ／ＭＡＣ）
　１１２　シグナリング取得部
　１１３　シグナリング解析部
　１１４　セグメント取得部
　１２０　ＨＴＴＰプロキシサーバ
　１２１　キャッシュ部
　１２２　アドレス解決部
　１３０　再生処理部（アプリケーション実行部）
　１３１　再生制御部
　１３２　出力制御部
　２０１　ＭＰＤ取得部
　２０２　ＭＰＤ解析部
　２０３　セグメント取得部
　２０４　セグメント解析部
　２１１　復号部
　２１２　出力部
　３０１　サービスリストテーブル（ＳＬＴ）
　３１１～３１３　サービス（Ｓｅｒｖｉｃｅ）
　３５１～３５３　サービスエントリ
　３６１　サービス単位の基本属性情報
　３６２　サービスシグナリングブートストラップアドレス
　７５１　データ処理部
　７５２　通信部
　７５３　記憶部
　７７１　データ処理部
　７７２　通信部
　７７３　記憶部
　７７４　入力部
　７７５　出力部
　８０１　ＣＰＵ
　８０２　ＲＯＭ
　８０３　ＲＡＭ
　８０４　バス
　８０５　入出力インタフェース
　８０６　入力部
　８０７　出力部
　８０８　記憶部
　８０９　通信部
　８１０　ドライブ
　８１１　リムーバブルメディア

Claims (20)

1. 　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信する通信部と、
   　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
   　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理部を有する受信装置。
2. 　前記アプリケーションは、
   　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
   　前記サービスカテゴリ識別子は、
   　（ａ）受信装置常駐型の再生アプリであるレジデンシャル再生アプリ、
   　（ｂ）送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリ、
   　上記（ａ），（ｂ）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である請求項１に記載の受信装置。
3. 　前記データ処理部は、
   　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが、いずれもレジデンシャル再生アプリである場合、サービス遷移前のアプリケーションの継続処理を行なう請求項２に記載の受信装置。
4. 　前記アプリケーションは、
   　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
   　前記サービスカテゴリ識別子は、
   　（ｂ１）送信装置の提供サービス専用の再生アプリであり、複数の異なるサービスに対する再生処理に適用可能な共用型ブロードキャスト再生アプリ、
   　（ｂ２）送信装置の提供サービス専用の再生アプリであり、１つのサービスに対する再生処理にのみ適用可能な専用型ブロードキャスト再生アプリ、
   　上記（ｂ１），（ｂ２）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である請求項１に記載の受信装置。
5. 　前記データ処理部は、
   　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが、いずれも共用型ブロードキャスト再生アプリである場合、サービス遷移前のアプリケーションの継続処理を行なう請求項４に記載の受信装置。
6. 　前記通信部は、
   　前記サービスカテゴリ識別子を、送信装置の送信するシグナリングデータとして受信する請求項１に記載の受信装置。
7. 　前記シグナリングデータは、サービス単位の情報を記録したサービスエントリを格納したサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）である請求項６に記載の受信装置。
8. 　前記サービスカテゴリ識別子は、
   　放送局単位のサービス、または放送局の提供する番組単位のサービス、少なくともいずれかのサービスに対応付けて設定された識別子である請求項１に記載の受信装置。
9. 　前記データ処理部は、
   　受信チャンネルの切り替え時に、チャンネル切り替え前後の番組再生に適用するアプリケーションが同一であるか否かを、前記サービスカテゴリ識別子に基づいて判断し、チャンネル切り替え前後の番組再生に適用するアプリケーションが同一であることを確認した場合、チャンネル切り替え前に実行中のアプリケーションの継続処理を行なう請求項１に記載の受信装置。
10. 　前記通信部は、さらに、
    　前記送信装置から受信するアプリケーションが、前記送信装置の提供するサービスの再生処理に適用する再生アプリであるか否かを示す配信アプリ識別フラグを受信し、
    　前記データ処理部は、
    　前記配信アプリ識別フラグの値に基づいて、アプリケーション制御を実行する請求項１に記載の受信装置。
11. 　前記データ処理部は、
    　前記配信アプリ識別フラグの値が、再生アプリであることを示す場合は、送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリを実行し、
    　前記配信アプリ識別フラグの値が、再生アプリでないことを示す場合は、送信装置が提供するブロードキャストアプリケーションを実行する請求項１０に記載の受信装置。
12. 　前記配信アプリ識別フラグは、
    　送信装置が提供するアプリケーションに対応する制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記録された構成である請求項１０に記載の受信装置。
13. 　受信装置において利用可能なサービスの構成データと、
    　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
    　前記サービスに適用するアプリケーションを送信する通信部を有する送信装置。
14. 　前記アプリケーションは、
    　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
    　前記サービスカテゴリ識別子は、
    　（ａ）受信装置常駐型の再生アプリであるレジデンシャル再生アプリ、
    　（ｂ）送信装置提供サービス用の再生アプリとして送信装置が提供するブロードキャスト再生アプリ、
    　上記（ａ），（ｂ）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である請求項１３に記載の送信装置。
15. 　前記アプリケーションは、
    　送信装置の提供するコンテンツの再生処理に適用する再生アプリケーションであり、
    　前記サービスカテゴリ識別子は、
    　（ｂ１）送信装置の提供サービス専用の再生アプリであり、複数の異なるサービスに対する再生処理に適用可能な共用型ブロードキャスト再生アプリ、
    　（ｂ２）送信装置の提供サービス専用の再生アプリであり、１つのサービスに対する再生処理にのみ適用可能な専用型ブロードキャスト再生アプリ、
    　上記（ｂ１），（ｂ２）のいずれの再生アプリを適用して再生するサービスであるかを識別可能とした識別子である請求項１３に記載の送信装置。
16. 　前記通信部は、
    　サービス単位の情報を記録したサービスエントリを格納したサービスリストテーブル（ＳＬＴ：Ｓｅｒｖｉｃｅ　Ｌｉｓｔ　Ｔａｂｌｅ）に前記サービスカテゴリ識別子を記録して送信する請求項１３に記載の送信装置。
17. 　前記サービスカテゴリ識別子は、
    　放送局単位のサービス、または放送局の提供する番組単位のサービス、少なくともいずれかのサービスに対応付けて設定された識別子である請求項１３に記載の送信装置。
18. 　前記通信部は、さらに、
    　前記送信装置の送信アプリケーションが、前記送信装置の提供するサービスの再生処理に適用する再生アプリであるか否かを示す配信アプリ識別フラグを送信する請求項１３に記載の受信装置。
19. 　受信装置において実行するデータ処理方法であり、
    　通信部が、
    　送信装置の提供サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子を受信し、
    　データ処理部が、
    　前記サービスカテゴリ識別子に応じて、前記サービスに適用するアプリケーションを決定し、
    　サービス遷移時に、遷移前後の各サービスに対する適用アプリケーションが同一である場合、サービス遷移前のアプリケーションの継続処理を行なうデータ処理方法。
20. 　送信装置において実行するデータ処理方法であり、
    　受信装置において利用可能なサービスの構成データと、
    　前記サービスに対する適用アプリケーションを識別可能としたサービスカテゴリ識別子と、
    　前記サービスに適用するアプリケーションを送信するデータ処理方法。

Images