WO2017047434A1

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

Info

Publication number: WO2017047434A1
Application number: PCT/JP2016/076052
Authority: WO
Inventors: 五十嵐　卓也; 山岸　靖明
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2015-09-18
Filing date: 2016-09-05
Publication date: 2017-03-23
Anticipated expiration: 2018-03-18
Also published as: MX389734B; MX2018002981A; KR102640835B1; CN108028963A; US11102536B2; US20190014366A1; EP3352469A1; JPWO2017047434A1; KR20180058219A; CA2998129A1; EP3352469A4

Abstract

異なるチャンネルを介した送信コンテンツの配信時間が重複した場合に、受信装置が、優先度情報に基づいて取得対象を選択可能とした構成を実現する。送信装置が、送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、サービス選択優先度情報を受信装置に送信する。サービス選択優先度情報は、異なるチャンネルを介した送信コンテンツの配信時間が重複する場合に、受信装置が、サービス選択優先度情報の高い値のコンテンツをキャッシュ対象として選択することを可能とした優先度情報として利用される。

Description

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

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

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

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

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

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

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

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

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

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

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

　さらに、国際標準仕様策定団体である３ＧＰＰ（Ｔｈｉｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）や、アダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ－ＤＡＳＨ規格の規格化団体であるＤＡＳＨ－ＩＦにおいては広告コンテンツの配信、再生構成についての規格化を進めている。
　具体的には、例えば、受信装置側の視聴ユーザに応じて、各受信装置に出力する広告を動的に変更する構成等についての規格化を進めている。
　ただし、この構成を実現する構成については、まだ、具体化されていないというのが現状である。

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

　本開示は、例えば上記問題点に鑑みてなされたものであり、放送番組等を受信し、再生する受信装置において、受信装置側のユーザに応じた広告等、ユーザ対応コンテンツの選択的出力を可能とする送信装置、受信装置、およびデータ処理方法を提供することを目的とする。

　本開示の第１の側面は、
　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理部を有する送信装置にある。

　さらに、本開示の第２の側面は、
　コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置にある。

　さらに、本開示の第３の側面は、
　送信装置において実行するデータ処理方法であり、
　データ処理部が、
　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理方法にある。

　さらに、本開示の第４の側面は、
　受信装置において実行するデータ処理方法であり、
　データ処理部が、コンテンツを受信し、キャッシュ部に格納する処理を実行し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法にある。

　さらに、本開示の第５の側面は、
　受信装置において実行されるアプリケーション制御方法であり、アプリケーション制御部が、配信されるコンテンツをキャッシュ部に格納するかの指示、ならびに、キャッシュに格納されたコンテンツを所定期間に出力するか否かを指示するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を有し、最終的にコンテンツを出力するか否かを、アプリケーションの判断により行うアプリケーション制御方法にある。

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

　本開示の一実施例の構成によれば、異なるチャンネルを介した送信コンテンツの配信時間が重複した場合に、受信装置が、優先度情報に基づいて取得対象を選択可能とした構成が実現される。
　具体的には、送信装置が、送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、サービス選択優先度情報を受信装置に送信する。サービス選択優先度情報は、異なるチャンネルを介した送信コンテンツの配信時間が重複する場合に、受信装置が、サービス選択優先度情報の高い値のコンテンツをキャッシュ対象として選択することを可能とした優先度情報として利用される。
　本構成により、異なるチャンネルを介した送信コンテンツの配信時間が重複した場合に、受信装置が、優先度情報に基づいて取得対象を選択可能とした構成が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。送信装置の送信データについて説明する図である。送信装置および受信装置のプロトコルスタックの例を示す図である。ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。受信装置（クライアント）３０におけるデータ出力例を説明する図である。様々なユーザ情報を利用した出力広告の選択例について説明する図である。受信装置の構成例について説明する図である。受信装置の構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの利用シーケンス例について説明する図である。ＭＰＤ内の広告対応ピリオド情報の構成例について説明する図である。受信装置におけるアプリケーションを利用した処理例について説明する図である。受信装置におけるアプリケーションを利用した処理例について説明する図である。受信装置におけるアプリケーションを利用した処理例について説明する図である。複数の広告の配信順設定例について説明する図である。複数の広告の配信順設定例と再生可能な広告について説明する図である。送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。送信装置の送信する広告コンテンツに配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を設定した例について説明する図である。配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の送信処理を実行する送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の受信処理を実行する受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する例について説明する図である。異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する場合において、受信装置が受信するデータを選択可能とした構成例について説明する図である。異なるチャンネルを介して送信される広告コンテンツの配信時間が重複する場合において、受信装置が受信するデータを選択可能とした構成例について説明する図である。サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の送信処理を実行する送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の受信処理を実行する受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。優先度情報の記録と送信処理例について説明する図である。優先度情報の記録構成の一例について説明する図である。優先度情報の記録構成の一例について説明する図である。優先度情報の記録構成の一例について説明する図である。優先度情報の記録構成の一例について説明する図である。優先度情報の記録構成の一例について説明する図である。優先度情報の記録構成の一例について説明する図である。通信装置である送信装置と受信装置の構成例について説明する図である。通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

　以下、図面を参照しながら本開示の送信装置、受信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．受信装置におけるデータ出力例について
　５．受信装置の構成例と処理例について
　６．ＭＰＤを利用したピリオド（Ｐｅｒｉｏｄ）単位のシグナリングデータについて
　７．ユーザ情報に応じた広告提供処理を実行するための具体的構成例について
　８．広告コンテンツの配信順の制御構成について
　９．配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づく処理例について
　１０．サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を適用した処理について
　１１．各優先度情報の記録構成例について
　１２．送信装置と受信装置の構成例について
　１３．本開示の構成のまとめ

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

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

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

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

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

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

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

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

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

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

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

　ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
　なお、ＮＲＴコンテンツの配信時間、並びにプレゼンテーション時間などのスケジュールはＥＳＧに記述される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　［４．受信装置におけるデータ出力例について］
　次に、放送サーバ２１、広告サーバ２２等の送信装置２０からデータを受信して、出力する受信装置（クライアント）３０におけるデータ出力例について説明する。
　図５は、受信装置（クライアント）３０におけるデータ出力例を説明する図である。

　受信装置３０には、図５下部に示すタイムライン（時間軸（ｔ））に従って、例えば映画やニュース、その他の放送番組（メインコンテンツ）と広告が交互に出力される。
　ユーザが選択したあるチャンネルの番組開始時間をｔ０とすると、以下のように、時間推移に従って放送番組と広告が交互に出力される。
　時間ｔ０～ｔ１：広告
　時間ｔ１～ｔ２：放送番組
　時間ｔ２～ｔ３：広告
　時間ｔ３～ｔ４：放送番組
　時間ｔ４～ｔ５：広告
　時間ｔ５～：放送番組

　ここで、受信装置３０に出力される広告は、多くの広告コンテンツの中から、受信装置３０側の視聴ユーザに応じて選択された広告である。
　受信装置３０において設定されるユーザ（視聴者）情報に基づき、アプリケーションの制御により、ユーザに最適な広告が選択されて出力される。
　ユーザ情報とは、例えば、ユーザ（視聴者）の年齢、性別、住所、趣味嗜好など、さまざまな情報である。
　これらのユーザ情報は、受信装置の記憶部に予め登録した情報を用いる。
　あるいは、番組開始時点で、ユーザ（視聴者）にユーザ情報を入力させ、この入力情報を用いる構成としてもよい。
　あるいは、出力広告を受信装置３０に対するユーザ入力に応じて自由に選択可能な構成としてもよい。

　ユーザ情報の設定および利用態様には様々な態様がある。例えば、各番組単位でユーザ情報を設定させて利用する構成、チャンネル単位の設定、全チャンネル共通の設定等、様々な設定および利用構成が可能である。
　これらのユーザ情報は、受信装置の記憶部に格納され、必要に応じて利用される。
　ユーザ情報を利用した広告選択の具体的構成については後述する。

　なお、ユーザに最適な広告の選択はアプリケーション制御部で実行されるアプリケーションが行うため、アプリケーションがインターネット経由にてサーバから取得しても良いし、アプリケーション自身が性別、年齢などの質問を表示し、ユーザの反応等によってユーザに問い合わせる等なども可能である。

　図６を参照して、様々なユーザ情報を利用した出力広告の選択例について説明する。
　図６には、以下の３種類の具体例を示している。
　（Ａ）年齢別の広告設定例
　（Ｂ）居住地別の広告設定例
　（Ｃ）年齢と、居住地別の広告設定例

　（Ａ）年齢別の広告設定例には、以下の例を示している。
　ユーザ（視聴者）の年齢（ａｇｅ）＝２０歳以上→アルコール飲料（酒類）の広告を選択して出力する。
　ユーザ（視聴者）の年齢（ａｇｅ）＝１５歳以下→おもちゃの広告を選択して出力する。
　この例は、受信装置３０側で登録されたユーザ情報として、ユーザの年齢の登録を実行させて、登録されたユーザ情報（視聴者年齢）に基づいて、そのユーザが利用している受信装置３０に、ユーザ年齢に応じた広告を出力させる例である。

　（Ｂ）居住地別の広告設定例には、以下の例を示している。
　ユーザ（視聴者）の住所（Ｌｏｃａｔｉｏｎ）＝アラスカ→暖房器具の広告を選択して出力する。
　ユーザ（視聴者）の住所（Ｌｏｃａｔｉｏｎ）＝ハワイ→冷房器具の広告を選択して出力する。
　この例は、受信装置３０側で登録されたユーザ情報として、ユーザの住所の登録を実行させて、登録されたユーザ情報（視聴者住所）に基づいて、そのユーザが利用している受信装置３０に、ユーザの住所に応じた広告を出力させる例である。

　（Ｃ）年齢と、居住地別の広告設定例には、以下の例を示している。
　ユーザ（視聴者）の年齢（ａｇｅ）＝１８歳以上、かつ、
　ユーザ（視聴者）の住所（Ｌｏｃａｔｉｏｎ）＝ニューヨーク、
　この２つの条件が満たされる場合に、ニューヨークの飲食店の広告を選択して出力する。
　ユーザ（視聴者）の年齢（ａｇｅ）＝１５歳以下、かつ、
　ユーザ（視聴者）の住所（Ｌｏｃａｔｉｏｎ）＝カリフォルニア、
　この２つの条件が満たされる場合に、カリフォルニアの玩具店の広告を選択して出力する。
　この例は、受信装置３０側で登録されたユーザ情報として、ユーザの年齢と住所を登録させて、登録されたユーザ情報（視聴者年齢と住所）に基づいて、そのユーザが利用している受信装置３０に、ユーザ年齢と住所に応じた広告を出力させる例である。

　このように、本開示の処理では、受信装置３０側において設定された様々なユーザ情報に応じて、アプリケーション制御部で実行されるアプリケーションがユーザ（視聴者）に最適、すなわち広告効果が大きいと判断される広告を選択して出力する構成を実現する。
　具体的な処理については、後述する。

　　［５．受信装置の構成例と処理例について］
　次に、図７以下を参照して受信装置３０の構成例と処理例について説明する。
　なお、受信装置３０は、先に図１を参照して説明したように、テレビ３１、ＰＣ３２、携帯端末３３、あるいは、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な機器によって構成される。

　図７に示す受信装置３０は、放送サーバや、広告サーバ等の送信装置２０からの送信データ、すなわち、先に図２を参照して説明した以下の各データ、
　シグナリングデータ５０、
　ＡＶセグメント６０、
　その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０、
　これらのデータを受信して、処理を実行する。

　受信装置３０は、図７に示すように、アプリケーション制御部１１０、再生制御部（Ｅｍｂｅｄｅｄ　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１２０、ベースシステム１３０を有する。
　アプリケーション制御部１１０は、アプリケーション実行部１１１を有し、例えば放送局等の送信装置２０から送信されるアプリケーション、あるいは受信装置３０内に予め格納されたアプリケーション等を実行する。
　再生制御部１２０は、番組再生やアプリケーション実行によるデータ再生処理を実行する。

　ベースシステム１３０は、キャッシュ制御部１３１、キャッシュ部１３２、第１通信部（チューナ）１３３、第２通信部（ネットワークＩ／Ｆ）１３４、出力制御部１３５を有し、送信装置２０からのデータを受信し格納する処理、さらに表示部、スピーカ等に対するデータ出力制御等を実行する。
　第１通信部（チューナ）１３３は、放送波の受信処理を実行する。第２通信部（ネットワークＩ／Ｆ）１３４は、インターネット等のネットワークを介したデータ通信を実行する。

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

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

　なお、再生制御部１２０や、アプリケーション制御部１１０は、送信装置２０（放送サーバ２１、広告サーバ２２等）が送信するシグナリングデータを参照し、シグナリングデータに記述された情報に従って必要なデータをキャッシュ部１３２から取得し、また、シグナリングデータに記述された情報に従って再生制御やアプリケーション制御を実行する。
　なお、キャッシュ部１３２には、放送波、またはネットワークを介して受信したデータ等が格納される。

　先に図２を参照して説明したように、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。

　再生制御部１２０や、アプリケーション制御部１１０は、シグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）を取得して取得したシグナリングデータに基づくデータ取得処理や、データ再生制御や、アプリケーション実行制御等を実行する。

　再生制御１２０や、アプリケーション制御部１１０は、コンテンツの再生、アプリケーションの制御情報等を記録したシグナリングデータとして、例えば、ＵＳＢＤ／ＵＳＤや、アプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）や、Ｓ－ＴＳＩＤ、ＭＰＤ等の様々なシグナリングデータを取得して利用する。

　シグナリングデータには、例えば、番組再生に必要となるＡＶセグメントや、アプリケーションの実行に必要となる様々なデータファイル（リソース）等を取得するためのアドレス情報（ＵＲＬ）が含まれる。

　図８は、受信装置（クライアント）３０の有する、
　再生制御部１２０、
　出力制御部１３５、
　これらの詳細構成を示す図である。

　受信装置（クライアント）３０の再生制御部１２０は、ＭＰＤ取得部１２１、ＭＰＤ解析部１２２、セグメント取得部１２３、セグメント（ＭＰ４）解析部１２４を有する。

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

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

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

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

　受信装置（クライアント）３０の出力制御部１３５は、復号部（デコーダ）１４１と、出力部（レンダラ）１４２を有する。
　復号部（デコーダ）１４１は、セグメント解析部１２４から提供された符号化画像データ、符号化音声データの復号処理（デコード）を実行する。
　出力部１４２は、復号された画像データ、音声データを出力部（ディスプレイ、スピーカ）に出力する。

　受信装置（クライアント）３０の再生制御部１２０は、ＡＴＳＣ３．０クライアントアプリケーション（３．０　ＤＡＳＨ　Ｃｌｉｅｎｔ）の実行部である。
　ＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０放送受信クライアントデバイス上に実装されたブラウザ上で実行される。あるいは、ブラウザアプリケーションとしてだけではなくネィティブアプリケーションとして実行される場合もある。

　　［６．ＭＰＤを利用したピリオド（Ｐｅｒｉｏｄ）単位のシグナリングデータについて］
　先に図２等を参照して説明したように、送信装置２０は、受信装置３０に対して、様々な制御情報からなるシグナリングデータ５０を提供する。
　前述したように、シグナリングデータには情報に応じた様々な種類がある。具体的には、例えば、番組等のサービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ））がある。

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

　ＤＡＳＨ規格に規定されたシグナリングデータの１つであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）は、例えばある番組の放送時間を細分化した時間区間であるピリオド（Ｐｅｒｉｏｄ）単位で、様々な制御データを受信装置（クライアント）３０に提供することができる。

　図９は、ＭＰＤのフォーマットの一例を示す図である。
　ＭＰＤは、画像や、音声それぞれのストリームごとに、以下の様々な規定範囲単位で属性等の情報や制御情報を記述可能である。
　（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
　（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
　（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
　（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）

　図１０は、ＭＰＤに記録されるＡＶセグメント対応の情報（制御情報や管理情報、属性情報など）を時系列に展開して示した図である。
　左から右に時間が経過するものとする。この時間軸は、例えば受信装置におけるＡＶコンテンツの再生時間に対応する。

　ＡＶセグメントに対応する様々な情報がＭＰＤに記録される。なお、ＭＰＤはシグナリングデータの一部であり、例えばＡＶセグメントに先行して送信される。
　ＭＰＤは、図９を参照して説明したように、以下の各データ単位で情報が記録できる。
　（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
　（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
　（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
　（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）
　図１０は、これらのデータ領域を時間軸、およびデータ種類別に展開して示した図である。

　図１０には、以下の２つのアダプテーション（Ａｄａｐｔａｔｉｏｎ）を示している。
　（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））
　（Ａ）音声対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））

　（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））は、異なる属性を持つストリーム単位の情報記録領域として、以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
　（Ｖ１）低ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ１））
　（Ｖ２）高ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ２））

　同様に、（Ａ）音声像対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））は、異なる属性を持つストリーム単位の情報記録領域としての以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
　（Ａ１）日本語音声対応の情報記録領域であるリプレゼンテーション（Ａ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ１））
　（Ａ２）英語音声対応の情報記録領域であるリプレゼンテーション（Ａ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ２））

　さらに、各リプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は、再生時間軸対応のピリオド、さらに、セグメント単位で情報が記録可能な構成となっている。

　例えば、高ビットレート画像と日本語音声を選択して再生する受信装置（クライアント）は、ピリオド１のセグメント（１１）の再生に際して、再生対象とする高ビットレート画像と日本語音声に関する情報をＭＰＤから選択して取得することになる。
　この選択対象とするＭＰＤの記録情報が、図に示すセグメント領域３０１，３０２の情報となる。

　このように、受信装置は、シグナリングデータとして送信装置から送信されるＭＰＤから、自装置で再生対象とするデータ（セグメント）に対応する情報のみを選択して参照する。
　このように、ＭＰＤには、データ種別、時間単位のセグメント対応情報を記録することができる。

　先に図５を参照して説明したように、放送番組と広告を交互に出力するコンテンツ出力処理を行なう場合、送信装置は、受信装置に対して、上述した所定時間（ピリオド）単位の制御情報を記録したＭＰＤを利用することで、各時間単位のコンテンツ（放送番組、広告）の制御が可能となる。具体的には先に図５を参照して説明したユーザ対応の広告を提供する処理を実現することができる。

　図１１は、先に図５を参照して説明した放送番組と広告を交互に出力するコンテンツ出力処理に対応する制御情報記述データ（シグナリングデータ）であるＭＰＤの構成例を示す図である。

　ＭＰＤは、所定時間区間の出力コンテンツに相当する広告、および放送番組単位のピリオド情報３１１～３１４に区分される。
　ピリオド情報３１１は、時間ｔ０～ｔ１に受信装置で出力される広告に対応する制御情報（シグナリングデータ）である。
　ピリオド情報３１２は、時間ｔ１～ｔ２に受信装置で出力される放送番組に対応する制御情報（シグナリングデータ）である。
　ピリオド情報３１３は、時間ｔ２～ｔ３に受信装置で出力される広告に対応する制御情報（シグナリングデータ）である。
　ピリオド情報３１４は、時間ｔ３～ｔ４に受信装置で出力される放送番組に対応する制御情報（シグナリングデータ）である。

　ビリオド情報には、送信装置から送信される放送番組や広告のアクセス情報（ＵＲＬ）等、受信装置に出力するデータ（コンテンツ）の取得に必要となる情報や、復号方法（コーデック）等、受信装置においてコンテンツを取得し出力するために必要となる各種の情報が記録されている。

　送信装置は、時間ｔ０より以前に、図に示すＭＰＤを受信装置に送信する。
　受信装置は、このＭＰＤを参照して、広告や放送番組を放送波やネットワークを介して取得し、指定されたコーデックを使用して復号処理等を行ない、表示部、スピーカ等に出力する。

　図１２は、受信装置において実行するＭＰＤの解析処理（パース）の手順を説明する図である。
　図１２には、以下の各図を示している。
　（１）ＭＰＤ
　（２）ピリオド情報
　（３）リプレゼンテーション情報
　（４）セグメント情報

　ＡＶセグメントを受信してＡＶコンテンツの再生処理を実行する受信装置（クライアント）は、ＡＶセグメント受信前に予め受信するシグナリンクデータに含まれるＭＰＤを取得し、自装置が再生するデータに対応する情報をＭＰＤから取得する。

　まず、図１０に示す（１）ＭＰＤから、ＡＶセグメント再生時間に相当する特定のピリオド（時間区間）の情報を記録した（２）ピリオド情報を選択する。
　さらに、自装置（クライアント）において再生するデータの種類に対応した（３）リプレゼンテーション情報を選択し、さらに、再生対象セグメントに対応する（４）セグメント情報を選択する。
　この（４）セグメント情報に記録されたデータを参照して、再生対象となるＡＶセグメントの取得や、ＡＶセグメント再生に必要となる様々な情報を取得することができる。

　　［７．ユーザ情報に応じた広告提供処理を実行するための具体的構成例について］
　次に、ユーザ情報に応じた広告提供処理を実行するための具体的構成例について説明する。
　図１３を参照して、図１１に示すＭＰＤ中の１つのピリオド情報３１１の構成について説明する。
　図１１から理解されるように、ピリオド情報３１１は、時間ｔ０～ｔ１において受信装置で出力する広告に対応する制御情報であるピリオド情報である。

　図１３に示すように、広告対応のピリオド情報３１１は、以下の記述データを有する。
　Ｐｅｒｉｏｄ　Ａ１　（Ａｄ　Ｂｒｅａｋ　＃１）：
　＠ｘｌｉｎｋ：ｈｒｅｆ＝ｈｔｔｐ：／／ａｄｓｅｒｖｉｃｅ．ｃｏｍ？ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄
　＠ｘｌｉｎｋ：ａｃｔｕａｔｅ＝"ｏｎＲｅｑｕｅｓｔ"
　＠ｓｔａｒｔ＝０
　＠ｄｕｒａｔｉｏｎ＝６０ｓｅｃ
　・・・・・

　広告対応のピリオド情報３１１には、先に、図１０、図１２を参照して説明した
　アダプテーション、
　リプレゼンテーション、
　セグメントインフォ、
　これらの具体的データの記述を省略し、これらの具体的記述を持つピリオド情報を取得するためのアクセス情報としてのリンク情報（ｘｌｉｎｋ）が記録される。

　「＠ｘｌｉｎｋ：ｈｒｅｆ＝ｈｔｔｐ：／／ａｄｓｅｒｖｉｃｅ．ｃｏｍ？ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄」
　この情報記録フィールドはリンク（ｘｌｉｎｋ）情報記録フィールドである。
　なお、「＠ｘｌｉｎｋ：ｈｒｅｆ＝」は、参照すべきＵＲＬの設定フィールドであることを示している。

　このｘｌｉｎｋＵＲＬ（＝ユーザ情報に応じたピリオド要素のアクセス情報）に基づいて、ユーザ情報に応じたピリオド要素を選択取得する処理は、例えば、送信装置から提供されるアプリケーション（リンク解決アプリ）によって実行される。
　リンク解決アプリは、受信装置３０のアプリケーション制御部１１０において実行される。
　アプリケーション制御部１１０は、リンク解決アプリの実行によるリンク解決処理を実行する。

　図１４を参照して、ユーザ情報に応じた広告（Ａｄ）出力処理のために行われるユーザ情報に応じたピリオド要素選択処理について説明する。
　アプリケーション制御部１１０のアプリケーション実行部１１１では、例えば放送局等の送信装置２０から提供されたアプリケーションを実行する。
　アプリケーション実行部１１１は、リンク解決処理を行なうＡＰＩ（広告挿入ＡＰＩ１１２）を適用した処理を実行する。
　すなわち、アプリケーション実行部１１１は、広告挿入ＡＰＩ１１２を適用して、Ｘｌｉｎｋ　ＵＲＬを実行中のアプリケーションに通知し、アプリケーションはＸｌｉｎｋ　ＵＲＬならびにユーザ情報から広告挿入期間に挿入される広告コンテンツを選択し、その広告コンテンツに対応したピリオド要素を選択するリンク解決（ｘｌｉｎｋ　Ｒｅｓｏｌｖｅｒ）処理を実行する。[0]

　アプリケーション実行部１１１は、広告挿入ＡＰＩ１１２を適用した処理によって、選択したユーザ情報対応の広告を格納した広告セグメントのＵＲＬ等を含むピリオド要素を受信装置３０の再生制御部１２０に返信する。
　受信装置３０の再生制御部１２０は、ピリオド要素に記録された広告セグメントＵＲＬを用いて広告セグメントの取得処理を行い、広告を再生する。
　すなわち、広告挿入期間においては、ＭＰＤに記載されていた元のピリオド要素の代わりに、アプリケーションから指定されたピリオド要素、すなわち、広告コンテンツを再生する。

　なお、受信装置３０のアプリケーション制御部１１０のアプリケーション実行部１１１において実行されるアプリケーションは、放送局等の送信装置２０から送信される様々な広告コンテンツの取得、キャッシュ処理の制御も行う。
　なお、アプリケーションの起動は、放送の受信中であれば放送にて配信されるシグナリングデータであるＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記述データに従って行われる。放送を受信していない場合、例えば、深夜などにおいては、ＥＳＧにアプリケーションの起動時間をスケジュールすることもできる。

　例えば、ユーザ情報に応じた様々な広告コンテンツは、ＮＲＴ（ノンリアルタイム）コンテンツファイルとして、放送番組の配信と別に送信される。
　受信装置３０は、例えば予め取得するＥＳＧ（電子サービスガイド：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）や、その他、ＦＤＴ等のシグナリングデータに基づいて、広告データを格納したＮＲＴコンテンツファイルの配信情報やアクセス情報を取得し、これらの情報を用いて広告データを取得する。

　図１５を参照して、受信装置３０において実行される広告データの取得処理について説明する。
　受信装置３０のアプリケーション制御部１１０のアプリケーション実行部１１１では、例えば放送局等の送信装置２０から提供されたアプリケーションが実行される。
　アプリケーション実行部１１１で実行されるアプリケーションは、広告データのキャッシュ制御を実行するキャッシュ制御ＡＰＩ（ＣａｃｈｅＳｔｏｒａｇｅＭａｎａｇｅｒ）１１４を適用したキャッシュ制御を行う。

　アプリケーション実行部１１１で実行されるアプリケーションは、キャッシュ制御ＡＰＩ（ＣａｃｈｅＳｔｏｒａｇｅＭａｎａｇｅｒ）１１４を適用して、受信装置３０のベースシステム１３０内のキャッシュ制御部１３１の制御を行い、キャッシュ制御部１３１に、送信装置２０から送信される広告データファイル（ＮＲＴコンテンツファイル）の取得、さらに、キャッシュ部１３２に対する格納処理を実行させる。

　送信装置２０から送信される広告データファイル（ＮＲＴコンテンツファイル）の取得、キャッシュ処理、さらに、キャッシュされた広告データの出力処理、これらの一連の処理シーケンスについて図１６を参照して説明する。

　図１６は、左から右に示す時間（ｔ）軸に従った処理を説明する図である。
　時間軸に示す時間ｔ１～ｔ９の各タイミングにおいて、受信装置３０において実行される処理をステップＳ１１～Ｓ２６の処理として示している。

　図１６に示す時間軸の上側の処理は、受信装置３０のアプリケーション制御部１１０において実行するアプリケーションによる処理である。
　一方、図１６に示す時間軸の下側の処理は、受信装置３０のキャッシュ制御部１３１、および再生制御部１２０の実行する処理である。
　以下、図１６に示す各ステップの処理について、順次、説明する。

　　（ステップＳ１１）
　まず、ステップＳ１１において、アプリケーション制御部１１０において実行されるアプリケーションが、キャッシュ制御部１３１にアクセスし、広告データを格納するためのキャッシュスペースの確保要求（ファイル生成）を行う。
　この処理は、先に図１５を参照して説明したキャッシュ制御ＡＰＩ１１４を適用して実行される。

　　（ステップＳ１２）
　次に、ステップＳ１２において、アプリケーション制御部１１０において実行中のアプリケーションが、キャッシュ制御ＡＰＩＩ１１４を適用し、キャッシュ制御部に広告データ取得処理の開始を指示する。
　この取得処理は、受信装置３０が、事前に取得したＥＳＧ（電子サービスガイド：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）を参照して実行される。ＥＳＧには、広告データを格納したＮＲＴコンテンツファイルの配信スケジュールやアクセス情報が記録されており、これらの情報を用いて広告データを取得する。

　　（ステップＳ１３～Ｓ１４）
　ステップＳ１３において、キャッシュ制御部１３１は、アプリケーションによって取得された広告データのキャッシュ部１３２に対する格納処理（フェッチ）を実行する。
　ステップＳ１４において、キャッシュ格納が完了する。

　　（ステップＳ２１）
　ステップＳ２１以降の処理は、キャッシュ部１３２に格納された広告データファイル（ＮＲＴコンテンツファイル）を読み出して、出力する処理である。
　なお、放送局からの配信コンテンツは、図１６に示すように、所定の放送番組の間（時間ｔ７～ｔ８）に予め規定の広告（デフォルト広告）が設定されたコンテンツとなっている。
　従って、受信装置３０側で、広告の差し替え処理を行なわなければ、この規定広告（デフォルト広告）が出力される。

　以下、説明する処理は、先に図１１、図１３等を参照して説明したＭＰＤの広告対応のピリオド情報に記録されたリンク（ｘｌｉｎｋ）情報を適用して、ユーザ情報に基づいて選択されるユーザ対応の広告をアプリケーションが選択し、再生制御部に指示し、再生制御部はキャッシュ部１３２から指定されて広告コンテンツを取得して、規定広告（デフォルト広告）に差し替えて出力する処理である。

　ステップＳ２１において、受信装置３０の再生制御部１２０は、ＭＰＤの解析処理を実行し、ＭＰＤの広告対応のピリオド情報に記録されたリンク（ｘｌｉｎｋ）情報を検出する。
　再生制御部１２０は、ピリオド情報に記録されたリンク（ｘｌｉｎｋ）情報の検出に応じて、アプリケーション制御部１１０において実行中のアプリケーションに対して、リンク（ｘｌｉｎｋ）解決要求を行う。

　　（ステップＳ２２～Ｓ２３）
　アプリケーション制御部１１０において実行中のアプリケーションは、再生制御部からのリンク解決要求の入力に応じて、リンク解決処理を実行する。

　この処理は、先に図１４を参照して説明した広告挿入ＡＰＩ１１２を適用した処理である。アプリケーション制御部１１０は、広告挿入ＡＰＩ１１２を適用して、ｘｌｉｎｋＵＲＬに基づいて、ユーザ情報に応じたピリオド要素を選択するリンク解決（ｘｌｉｎｋ　Ｒｅｓｏｌｖｅｒ）処理を実行する。
　具体的には、ユーザ情報に応じたピリオド要素を選択し、選択したユーザ情報対応の広告を格納した広告セグメントのＵＲＬ等を含むピリオド要素を受信装置３０の再生制御部１２０に返信する。

　　（ステップＳ２４～Ｓ２５）
　次に、ステップＳ２４において、受信装置３０の再生制御部１２０は、ピリオド要素に記録された広告セグメントＵＲＬを用いて、キャッシュ部１３２から、広告セグメントの取得処理を行い、ステップＳ２５において取得した広告を再生する。

　すなわち、時間ｔ７～ｔ８において放送番組に連続して再生予定の規定広告（デフォルト広告）を、キャッシュ部から取得した広告に差し替えて再生する処理を実行する。
　この処理によって、ユーザ情報に応じて選択された広告の再生が行われることになる。

　　（ステップＳ２６）
　広告再生が完了すると、再生制御部１２０は指定された広告コンテンツの再生がおこなわれたことをアプリケーション制御部１１０の広告挿入ＡＰＩ１１２を適用してアプリケーションに通知する。

　　（ステップＳ２７）
　アプリケーションは、広告挿入ＡＰＩ１１２を適応してキャッシュ制御部にキャッシュされた広告コンテンツのファイルの削除を指示し、キャッシュ制御部１３１は、指定されたファイルの削除処理を行う。

　このようにして、受信装置３０では、アプリケーション制御部１１０において実行されるアプリケーションの管理の下、様々な広告コンテンツの取得処理、および選択再生処理が実行される。

　　［８．広告コンテンツの配信順の制御構成について］
　次に、広告コンテンツの配信順の制御構成について説明する。

　上述した説明から理解されるように、放送局等の送信装置２０は、１つの広告再生時間に出力可能な広告として、多数の異なる広告コンテンツを受信装置３０に提供する。
　受信装置３０は、送信装置２０から送信される多数の広告コンテンツから、１つの広告を選択して再生することになる。
　すなわち、送信装置２０の提供する複数の広告コンテンツ中、１つの受信装置において再生される広告コンテンツは１つのみである。

　受信装置３０における広告選択処理は、広告再生時間より前に実行することが必要である。
　受信装置３０は、予め設定された広告出力時間の前に、その広告再生時間対応の複数の広告を受信装置３０のキャッシュ部１３２に格納する処理を実行し、その中から、１つの再生対象のコンテンツを選択して出力することになる。

　しかし、キャッシュ部に格納される複数の広告には、多くのユーザ（視聴者）によって選択される可能性の高い広告や、選択される可能性の低い広告が混在する。

　例えば、広告の設定された番組が野球中継である場合、その視聴者は、野球の好きな男性視聴者である割合が高いと推定される。このような番組対応の広告として、以下の複数の異なる広告コンテンツを送信したものとする。
　（広告１）子供向けの広告コンテンツ、
　（広告２）成人男性向けの広告コンテンツ、
　（広告３）女性向けの広告コンテンツ、
　これらの、様々なユーザ層別広告コンテンツを送信しだ場合、受信装置３０において選択される可能性の高い広告は、
　（広告２）成人男性向けの広告コンテンツ、
　であることが予想される。

　このように、放送地域において選択可能性の高い広告と、選択可能性の低い広告が、予め推定されている場合、これら複数の広告コンテンツの配信順を制御することで、受信装置における広告の取得可能性や視聴率を高める制御を行う。

　図１７を参照して、広告コンテンツの配信順制御構成について説明する。
　図１７には、以下の図を示している。
　（ａ）広告別ユーザ視聴分布予測データ
　（ｂ）広告送信順および配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の設定例

　（ａ）広告別ユーザ視聴分布予測データは、広告配信を行う放送局等の送信装置２０が保持しているデータである。例えば、過去の広告視聴履歴データ等に基づいて分析した結果である。

　（ｂ）広告送信順および配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の設定例は、（ａ）広告別ユーザ視聴分布予測データに基づいて設定した広告配信順に従った広告配信例を示している。
　（ｂ）には、送信装置２０が送信する以下の各データを示している。
　（ｂ１）放送ＡＶセグメント
　（ｂ２）ＮＲＴコンテンツファイル

　送信装置２０が送信する（ｂ１）放送ＡＶセグメントによる再生処理を行なう場合、受信装置では、放送番組と、予め設定された規定広告（デフォルト広告）としての広告１（Ａｄ１）の出力が行われる。
　送信装置２０が送信する（ｂ２）ＮＲＴコンテンツファイルには、時間ｔａ～ｔｂ間の広告再生時間において、規定広告（デフォルト広告）である広告１（Ａｄ１）に差し替え可能な広告コンテンツファイル（ＮＲＴコンテンツファイル）の配信例を示している。

　受信装置３０は、（ｂ２）ＮＲＴコンテンツファイルとして送信される広告２（Ａｄ２）～広告４（Ａｄ４）をキャッシュ部に格納し、これらの広告のいずれかを選択し、再生時間：ｔａ～ｔｂにおいて、広告１（Ａｄ１）に差し替えて、選択広告を出力することができる。

　（ａ）広告別ユーザ視聴分布予測データに示すように、広告別の視聴予測データは、以下の設定である。
　広告１（Ａｄ１）＝５５％
　広告２（Ａｄ２）＝２５％
　広告３（Ａｄ３）＝１５％
　広告４（Ａｄ４）＝５％
　これは、図１７（ｂ１）に示す放送ＡＶセグメントに基づく再生番組中の時間ｔａ～ｔｂにおいて選択出力可能な４種類の広告コンテンツ（Ａｄ１～Ａｄ４）の視聴割合の予測データである。
　すなわち、時間ｔａ～ｔｂにおいて広告を視聴するユーザ全体を１００％としたとき、広告１（Ａｄ１）～広告４（Ａｄ４）の各広告の視聴割合の分布を示すデータである。

　放送局が、この視聴予測データを、予め取得している場合、番組とともに配信する規定広告（デフォルト広告）を最も視聴可能性の高い広告（広告１（Ａｄ１））とする。
　さらに、広告再生時間ｔａの直前に、次に視聴可能性の高い広告（広告２（Ａｄ２））を送信する設定とする。
　例えば、広告２（Ａｄ２）は、時間ｔ３～ｔ４に送信装置２０から、受信装置３０に送信される。

　さらに、広告（広告２（Ａｄ２））の配信前に、次に視聴可能性の高い広告（広告３３（Ａｄ３））を配信する設定とする。
　例えば、広告２（Ａｄ２）は、時間ｔ２～ｔ３に送信装置２０から、受信装置３０に送信される。

　さらに、広告（広告３（Ａｄ３））の配信前に、次に視聴可能性の高い広告（広告４（Ａｄ４））を配信する設定とする。
　例えば、広告３（Ａｄ３）は、時間ｔ１～ｔ２に送信装置２０から、受信装置３０に送信される。

　このように、広告再生開始時間（ｔａ）に最も近い時間（ｔ３）に視聴可能性の高い広告を送信する設定とする。最も視聴可能性の低い広告は、広告再生開始時間（ｔａ）から最も離れた時間（ｔ１）に送信が開始される。

　図１７（ｂ１）に示す放送セグメントは、ある１つの放送局の配信番組であり、受信装置３０がその放送局にチューニング（チャンネル設定）していなければ受信されないデータである。
　図１７（ｂ２）に示すＮＲＴコンテンツファイルもまた、（ｂ１）に示す放送セグメントの受信設定、すなわち、その放送局にチューニング（チャンネル設定）を行なっている受信装置３０のみが受信可能なデータである。

　受信装置３０は、ユーザ（視聴者）によって、任意のタイミングでＯＮ／ＯＦＦされ、また、任意タイミングでチャンネルの切り替えが行われる。
　広告再生時間ｔａ～ｔｂに、広告１（Ａｄ１）～広告４（Ａｄ４）のいずれかの広告を視聴するユーザ（視聴者）は、受信装置がＯＮであり、さらに、受信装置３０をこの広告を配信しているチャンネルに設定しているユーザのみである。

　例えば、図１７（ｂ）に示すデータを配信しているチャンネルをチャンネルＡとする。
　受信装置３０側のユーザが、受信装置３０のチャンネル設定を行い、チャンネルＡに設定するタイミングは様々である。

　図１８には、受信装置３０における複数のチャンネル設定タイミングの例を示している。
　例えば、受信装置３０が、時間ＴｐにチャンネルＡに設定すれば、受信装置３０は、ＮＲＴコンテンツファイルとして送信装置２０から送信される３つの広告コンテンツ（広告２～広告４）の全てを取得してキャッシュ部に格納し、３つの広告コンテンツのいずれかを選択して出力することができる。

　また、受信装置３０が、時間ＴｑにチャンネルＡに設定した場合は、受信装置３０は、ＮＲＴコンテンツファイルとして送信装置２０から送信される３つの広告コンテンツ（広告２～広告４）中、広告４（Ａｄ４）については取得できず、広告２～広告３のみを取得してキャッシュ部に格納し、これら２つの広告コンテンツのいずれかを選択して出力することができる。

　また、受信装置３０が、時間ＴｒにチャンネルＡに設定した場合は、受信装置３０は、ＮＲＴコンテンツファイルとして送信装置２０から送信される３つの広告コンテンツ（広告２～広告４）中、広告３（Ａｄ３）と広告４（Ａｄ４）については取得できず、広告２（Ａｄ２）のみを取得してキャッシュ部に格納し、この広告２（Ａｄ２）を選択して出力することができる。

　また、受信装置３０が、時間ＴｓにチャンネルＡに設定した場合は、受信装置３０は、ＮＲＴコンテンツファイルとして送信装置２０から送信される３つの広告コンテンツ（広告２～広告４）のいずれも取得できない、この場合、放送番組とともに送信される規定広告（広告１）の再生のみが可能となる。

　なお、時間Ｔｐ～Ｔｓにおいて、受信装置３０がチャンネルＡに設定されていても、広告出力開始時間ｔａより前に、受信装置３０が他のチャンネルに切り替えられてしまうと、広告１～広告４のいずれも視聴されないことになる。
　受信装置３０が、広告１～広告４のいずれかを視聴するためには、広告出力タイミングｔａに受信装置３０がチャンネルＡに設定していることが必要である。

　広告出力タイミングｔａに受信装置３０が出力可能な広告は、受信装置３０がチャンネルＡに設定した時間に応じて以下のような設定となる。
　（１）チャンネルＡ設定時間＝Ｔｐ以前～ｔａ：広告１（Ａｄ１）～広告４（Ａｄ４）
　（２）チャンネルＡ設定時間＝Ｔｑ～ｔａ：広告１（Ａｄ１）～広告３（Ａｄ３）
　（３）チャンネルＡ設定時間＝Ｔｒ～ｔａ：広告１（Ａｄ１）～広告２（Ａｄ２）
　（４）チャンネルＡ設定時間＝Ｔｓ～ｔａ：広告１（Ａｄ１）

　すなわち、各広告の再生可能なチャンネル設定タイミングは、以下のようになる。
　（１）広告１（Ａｄ１）＝Ｔｐ，Ｔｑ，Ｔｒ，Ｔｓ
　（２）広告２（Ａｄ２）＝Ｔｐ，Ｔｑ，Ｔｒ
　（３）広告３（Ａｄ３）＝Ｔｐ，Ｔｑ
　（４）広告４（Ａｄ４）＝Ｔｐ
　このように、広告１（Ａｄ１）が最も再生可能となる確率が高く、広告４（Ａｄ４）が最も再生可能となる確率が低いという結果となる。

　この検討結果から、規定広告（デフォルト広告（広告１））に差し替え可能な広告を、ＮＲＴコンテンツファイルとして送信する場合、再生開始時間ｔａの直前に送信する方が、受信装置３０における受信および再生可能性を高めることができるという結論が得られる。

　すなわち、広告の出力開始時間（ｔａ）の直前に、より視聴可能性の高い広告コンテンツを送信し、視聴可能性の低い広告コンテンツは、それ以前に送信するといった送信順の設定を行うことで、受信装置３０におけるユーザ選択やユーザ情報に従って選択される広告の受信および再生可能性を高めることができる。

　送信装置２０は、この検討結果に基づいて、ＮＲＴコンテンツファイルとして送信する広告コンテンツの送信順を設定して送信する。
　図１９に示すフローチャートを参照して送信装置２０の実行する広告コンテンツの配信制御シーケンスについて説明する。

　　（ステップＳ１０１）
　送信装置のデータ処理部は、まず、ステップＳ１０１において、複数の配信広告に関する視聴分布予測データを取得する。
　すなわち、例えば図１７（ａ）に示すような広告別ユーザ視聴分布予測データである。例えば、広告別の視聴予測データは以下の設定を持つ。
　広告１（Ａｄ１）＝５５％
　広告２（Ａｄ２）＝２５％
　広告３（Ａｄ３）＝１５％
　広告４（Ａｄ４）＝５％

　これは、図１７（ｂ１）に示す放送ＡＶセグメントに基づく再生番組中の時間ｔａ～ｔｂにおいて選択出力可能な４種類の広告コンテンツ（Ａｄ１～Ａｄ４）の視聴割合の予測データである。
　すなわち、時間ｔａ～ｔｂにおいて広告を視聴するユーザ全体を１００％としたとき、広告１（Ａｄ１）～広告４（Ａｄ４）の各広告の視聴割合の分布を示すデータである。

　　（ステップＳ１０２）
　次に、送信装置は、ステップＳ１０２において、視聴予測データに基づいて、最も視聴可能性が高い広告（Ａｄ１）を番組付随の規定広告（デフォルト広告）に設定する。

　　（ステップＳ１０３）
　次に、送信装置は、ステップＳ１０３において、視聴予測データに基づいて、２番目以降の視聴可能性を持つ広告を、視聴可能性の高い順（Ａｄ２）～（Ａｄｎ）に配列する。

　　（ステップＳ１０４）
　次に、送信装置は、ステップＳ１０４において、視聴可能性の高い順に配列した広告（Ａｄ２）～（Ａｄｎ）を、視聴可能性の低い広告（Ａｄｎ）を先頭の送信データとし、視聴可能性の高い広告（Ａｄ２）を広告再生時間ｔａの直前に配信完了するように配信順と配信時間を決定し、決定した配信順と配信時間に従って、各広告データを格納したＮＲＴコンテンツファイルを送信する。

　　（ステップＳ１０５）
　次に、送信装置は、ステップＳ１０５において、最も視聴可能性が高い広告（Ａｄ１）を番組付随の規定広告（デフォルト広告）として送信する。

　このように、送信装置２０は、例えば図１７に示す広告別ユーザ視聴分布予測データに基づいて、広告の配信順を決定し、送信する。すなわち、視聴可能性の高いコンテンツの送信時間をコンテンツ出力時間に最も近い時間とし、視聴可能性の低いコンテンツの送信時間を視聴可能性の高いコンテンツの送信時間より前に設定する送信順決定処理を実行する。

　例えば図１７に示す広告別ユーザ視聴分布予測データは、遂次更新する設定としもよい。例えば、先行して出力された広告コンテンツの視聴率情報を取得し、取得した視聴率情報に基づいて、図１７に示す広告別ユーザ視聴分布予測データを逐次、更新し、更新されたデータを利用して配信順を決定する処理を行なう構成としてもよい。
　先行して出力された広告の視聴率は、受信装置もしくはアプリケーション実行部で実行されるアプリケーションがインターネット等の通信回線を用いて放送局に広告の出力結果を通知することで行える。

　次に、受信装置３０において実行する処理シーケンスの例について図２０に示すフローチャートを参照して説明する。

　　（ステップＳ１２１）
　まず、受信装置のデータ処理部は、ステップＳ１２１において、ユーザ情報、またはユーザ選択に従った再生広告の選択処理を実行する。
　これは、例えば、先に図１３等を参照して説明したユーザ情報を設定したリンク情報（ｘｌｉｎｋ）に基づく広告選択処理、あるいは受信装置に対するユーザ入力に基づく広告選択処理である。

　　（ステップＳ１２２）
　次に、受信装置は、ステップＳ１２２において、選択された広告は番組付随の規定広告（デフォルト広告）であるか否かを判断する。

　選択された広告が番組付随の規定広告（デフォルト広告）である場合は、ステップＳ１２３に進む。
　選択された広告が番組付随の規定広告（デフォルト広告）でない場合はステップＳ１２４に進む。

　　（ステップＳ１２３）
　選択された広告が番組付随の規定広告（デフォルト広告）である場合は、ステップＳ１２３に進み、番組付随の規定広告（デフォルト広告）を再生する。

　　（ステップＳ１２４）
　一方、選択された広告が番組付随の規定広告（デフォルト広告）でない場合は、ステップＳ１２４に進み、さらに、選択された広告が、キャッシュ済みであるか否かを確認する。
　選択された広告が、キャッシュ済みである場合は、ステップＳ１２５に進む。

　一方、選択された広告が、キャッシュ済みでない場合は、ステップＳ１２３に進み、番組付随の規定広告（デフォルト広告）を再生する。

　　（ステップＳ１２５）
　ステップＳ１２４において、選択された広告が、キャッシュ済みである場合は、ステップＳ１２５に進み、ステップＳ１２５において、キャッシュ部から選択広告を取得して再生する。

　　［９．配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づく処理例について］
　送信装置２０からＮＲＴコンテンツとして送信される差し替え処理用の広告コンテンツの各々には、それぞれ受信装置３０における受信およびキャッシュ処理の実行要否を判定させる判定基準としての優先度を設定することができる。
　この優先度を配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）と呼ぶ。

　配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）は、ＮＲＴコンテンツファイルとして送信される広告コンテンツ自体にも設定可能であるが、広告コンテンツの配信前に送信されるデータ（例えば、ＦＤＴ等のシグナリングデータやＥＳＧ等）に記録して、予め受信装置に提供することが可能である。

　以下、この配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を利用した処理例について説明する。
　図２１は、送信装置２０が、送信するＮＲＴコンテンツファイルとしての差し替え用広告コンテンツ（Ａｄ２～Ａｄ４）各々に対応する対応情報（例えば、ＦＤＴ等のシグナリングデータやＥＳＧ等）の記録データの例を示す図である。

　各広告データ（Ａｄ２～Ａｄ４）の各々に対応する対応情報には、各広告に関する以下の属性データが記録される。
　（ａ）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（ｂ）配信時間情報（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）
　（ｃ）広告出力開始終了時間（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）

　（ａ）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）は、各広告についての受信装置３０における受信およびキャッシュ処理の実行要否を判定させる判定基準としての優先度であり、送信装置２０側で自由に設定可能な値である。
　図に示す例では、
　広告２（Ａｄ２）の配信優先度情報＝５
　広告３（Ａｄ３）の配信優先度情報＝４
　広告４（Ａｄ４）の配信優先度情報＝１
　上記設定であり、広告２（Ａｄ２）の配信優先度情報の設定値が最も高くなっている。

　受信装置３０は、例えは、受信装置３０において予め規定した判定基準値としての規定値を用い、規定値以上の配信優先度の設定された広告データを優先的に選択して受信し、キャッシュする処理を行なうことができる。

　送信装置２０は、受信装置３０に送信する複数の広告コンテンツの各々について配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を設定し、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を、受信装置３０に送信する。
　なお、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）は、例えば、視聴可能性の高低に応じた値として設定される。

　（ｂ）配信時間情報（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）には、広告の配信される時間情報であり、配信開始時間と、配信終了時間が記録される。
　（ｃ）広告出力開始終了時間（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）は、受信装置におけるその広告の出力開始時間と出力終了時間の記録領域である。

　なお、これらの各情報を記録した具体的なデータ、例えば、ＦＤＴ等のシグナリングデータやＥＳＧ等の情報記録例については、後段で説明する。

　図２２に示すフローチャートを参照して送信装置２０の実行する広告対応の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の生成、送信シーケンスについて説明する。

　　（ステップＳ１４１）
　送信装置のデータ処理部は、まず、ステップＳ１４１において、複数の配信広告に関する視聴分布予測データを取得する。
　すなわち、例えば図１７（ａ）に示すような広告別ユーザ視聴分布予測データである。例えば、広告別の視聴予測データは以下の設定を持つ。
　広告１（Ａｄ１）＝５５％
　広告２（Ａｄ２）＝２５％
　広告３（Ａｄ３）＝１５％
　広告４（Ａｄ４）＝５％

　　（ステップＳ１４２）
　次に、送信装置は、ステップＳ１４２において、視聴予測データに基づいて、各広告（Ａｄ１～Ａｄｎ）に対する配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を設定する。
　例えば、図２１を参照して説明した優先度情報、
　広告２（Ａｄ２）の配信優先度情報＝５
　広告３（Ａｄ３）の配信優先度情報＝４
　広告４（Ａｄ４）の配信優先度情報＝１
　これらの情報を設定する。

　　（ステップＳ１４３）
　次に、送信装置は、ステップＳ１４３において、視聴予測データに基づく各広告（Ａｄ１～Ａｄｎ）対応の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を記録したデータ、例えばシグナリングデータを生成して送信する。

　なお、ここで生成するシグナリングデータ等には、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）のみならず、その他の様々な広告対応の情報が記録されている。少なくとも、先に図２１参照して説明したように、以下の各データが記録されている。
　（ａ）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（ｂ）配信時間情報（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）
　（ｃ）広告出力開始終了時間（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）

　次に、受信装置３０において実行する配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づく処理シーケンスの例について図２３に示すフローチャートを参照して説明する。

　　（ステップＳ１６１）
　まず、受信装置のデータ処理部は、ステップＳ１６１において、視聴予測データに基づく、各広告（Ａｄ１～Ａｄｎ）対応の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）を記録したデータ、例えばシグナリングデータを受信する。
　なお、受信したシグナリングデータには、先に図２１を参照して説明したように、以下の各データが記録されている。
　（ａ）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（ｂ）配信時間情報（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）
　（ｃ）広告出力開始終了時間（ｓｔａｒｔ／ｅｎｄ　ｔｉｍｅ）

　　（ステップＳ１６２）
　次に、受信装置は、ステップＳ１６２において、送信装置から送信される広告（Ａｄｘ）各々について、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）の設定値を確認し、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が、予め設定した規定値以上であるか否かを判定する。

　送信広告（Ａｄｘ）の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が、予め設定した規定値以上である場合は、ステップＳ１６３に進む。
　送信広告（Ａｄｘ）の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が、予め設定した規定値以上でない場合は、ステップＳ１６４に進む。

　　（ステップＳ１６３）
　送信広告（Ａｄｘ）の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が、予め設定した規定値以上である場合は、ステップＳ１６３に進み、送信広告（Ａｄｘ）を受信し、キャッシュ部に格納する処理を実行する。

　　（ステップＳ１６４）
　一方、送信広告（Ａｄｘ）の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が、予め設定した規定値以上でない場合は、ステップＳ１６４に進み、送信広告（Ａｄｘ）の受信処理、キャッシュ部格納処理を中止する。

　このように、受信装置は、各広告対応の配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づいてキャッシュ格納処理の要否を判定し、より優先度の高い広告のみをキャッシュ部に格納して再生することが可能となる。
　これにより、本来、配信されるＮＲＴコンテンツをキャッシュに格納するかはアプリケーションの制御によって行われるが、キャッシュ制御部、あるいはキャッシュ制御部を制御する受信装置のデータ処理部はアプリケーションからの要求がない場合でも、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づいて、キャッシュするかの判断が可能となる。

　　［１０．サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を適用した処理について］
　次に、複数の異なるチャンネルからの広告配信が競合した場合の処理について説明する。
　具体的には、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を適用した処理について説明する。

　広告を配信する放送局は多数あり、それぞれの放送局等の複数の送信装置２０が様々な時間に様々な広告配信を実行している。
　受信装置３０のユーザが、特定の放送局２０を視聴中（チューニングされた）状態であれば、受信装置３０は、その選択チャンネルの番組コンテンツと、その番組付随のＮＲＴコンテンツ、例えば差し替え用の広告コンテンツを格納したＮＲＴコンテンツファイルを受信することになる。

　しかし、受信装置３０が特定チャンネルの放送を受信していない状態、例えば、深夜、受信装置がスタンバイモードに設定されている間に、送信装置２０は、様々なデータファィルを送信する場合がある。

　受信装置３０は、予め受信済みのＥＳＧ（電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ））等のシグナリングデータに基づいて、様々なコンテンツの配信スケジュールを予め知ることができ、深夜等に配信されるデータを、スタンバイモード状態で受信し、キャッシュ部に格納することができる。

　例えばＥＳＧや、ＦＤＴ等のシグナリングデータには、配信データのアクセス情報、配信タイミング情報が記録されており、受信装置３０は、スタンバイモードにおいて、適宜、データを受信するためのチューニング（チャンネル設定）を自動的に実行して、配信データを取得してキャッシュ部に格納することができる。

　しかし、例えば異なる放送局から同一タイミングで異なるデータ、例えば、２つの異なる放送局から、各々異なる広告、広告１（Ａｄ１）と、広告２（Ａｄ２）が送信されると、受信装置３０は、いずれか一方の広告のみの受信処理しかできない。
　すなわち、このような配信データの競合が発生した場合、受信装置３０は、何らかのアルゴリズムに従って受信データの選択処理を実行することが必要となる。

　図２４は、異なる放送局（放送局Ａと放送局Ｂ）から同一タイミングで異なる広告、広告１（Ａｄ１）と、広告２（Ａｄ２）が送信される場合の送信シーケンスを示している。

　放送局Ａ（ｃｉｄ＝１）は、ＮＲＴコンテンツファイルとして、時間ｔ１～ｔ２において、広告１（Ａｄ１）を送信する。
　放送局Ｂ（ｃｉｄ＝２）も、ＮＲＴコンテンツファイルとして、時間ｔ１～ｔ２において、広告２（Ａｄ２）を送信する。
　このような配信データの競合が発生した場合、受信装置３０は、何らかのアルゴリズムに従って受信データの選択処理を実行することが必要となる。

　以下、このような場合に、受信装置３０がいずれかの広告を選択取得する構成について説明する。広告配信処理前に送信装置２０から受信装置３０に送信されるデータ、例えばＥＳＧやＦＤＴ等のシグナリングデータに選択取得判定用の優先度情報を設定し、この優先度情報に基づいて選択取得する広告を決定する。
　なお、この広告選択に適用する優先度情報は、
　サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）と呼ぶ。

　図２５、図２６を参照して、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を記録したシグナリングデータの送信、利用処理について説明する。

　図２５には、放送局Ａ（ｃｉｄ＝１）、放送局Ｂ（ｃｉｄ＝２）各々の送信する広告データ（ＮＲＴコンテンツファイル）と、広告対応属性情報、例えばＥＳＧやシグナリングデータの送信処理例を示している。図に示す広告対応属性情報は、各放送局の提供する広告１（Ａｄ１）、広告２（Ａｄ２）に関する属性情報、制御情報を記録したＥＳＧ、あるいはＦＤＴ等のシグナリングデータである。

　ＥＳＧ、あるいはＦＤＴ等のシグナリングデータには、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）が記録される。
　このサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、広告等の配信コンテンツの配信時間が重複した場合に、１つのコンテンツを選択的に受信、キャッシュするためのコンテンツ選択判定処理に適用される。

　図２６を参照して、受信装置において実行するサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を用いた取得コンテンツ選択処理について説明する。

　まず、受信装置は、ステップＡに示すように、配信広告に関する配信時間情報等のアクセス情報を記録した事前取得データ、例えばＥＳＧや、シグナリングデータであるＦＤＴを受信し、各広告の配信時間を確認する。

　ここで、ステップＢに示すように、複数の異なる広告の配信時間が重複（競合）していることが確認されたとする。
　この場合、受信装置３０は、各放送局から送信されるＥＳＧ、またはＦＤＴ等のシグナリングデータを参照し、各配信広告に対応付けられたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を参照する。

　なお、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の記録データとしては、例えば、
　（ａ）番組表等を含む電子サービスガイドであるＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）
　（ｂ）各送信ファイルのメタデータを記録したＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）
　（ｃ）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）記録用の専用データであるＣＲＴ（Ｃｏｎｆｌｉｃｔ　Ｒｅｓｏｌｕｔｉｏｎ　Ｔａｂｌｅ）
　例えば、これらのデータのいずれかの利用が可能である。

　次に、受信装置３０は、図に示すステップＣにおいて、各配信広告に対応付けられたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を比較し、より高い優先度情報の設定された広告を受信、キャッシュ対象として選択する。

　図２６に示す例では、放送局Ａ（ｃｉｄ＝１）から送信される広告１（Ａｄ１）対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、［５］である。
　一方、放送局Ｂ（ｃｉｄ＝２）から送信される広告２（Ａｄ２）対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、［７］である。
　この場合、受信装置３０は、放送局Ｂ（ｃｉｄ＝２）から送信される広告２（Ａｄ２）を選択して受信し、キャッシュ処理を実行する。

　このような処理を実行することで、受信装置３０は、複数のコンテンツ（広告等）の配信時間が重複した場合でも、１つの受信コンテンツを確実に選択して、取得することが可能となる。

　なお、各放送局対応の提供コンテンツを受信する場合、受信対象コンテンツの受信処理を実行するための放送局対応のアプリケーションを起動して処理を実行することになる。
　すなわち、受信装置３０は、各配信広告に対応付けられたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を比較し、より高い優先度情報の設定された広告を受信することを決定し、その広告を受信するためのアプリケーションを起動して、広告受信処理およびキャッシュ処理を実行する。

　図２７に示すフローチャートを参照して送信装置２０の実行するサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の生成、送信シーケンスについて説明する。

　　（ステップＳ２０１）
　送信装置のデータ処理部は、まず、ステップＳ２０１において、配信広告対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を記録した送信用データ（ＦＤＴ，ＥＳＧ，ＣＲＴ等）を生成する。

　前述したように、例えば、
　（ａ）番組表等を含む電子サービスガイドであるＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）
　（ｂ）各送信ファイルのメタデータを記録したＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）
　（ｃ）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）記録用の専用データであるＣＲＴ（Ｃｏｎｆｌｉｃｔ　Ｒｅｓｏｌｕｔｉｏｎ　Ｔａｂｌｅ）
　例えば、これらのデータのいずれかにサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を記録する。

　　（ステップＳ２０２）
　次に、送信装置は、ステップＳ２０２において、配信広告対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を記録した送信用データ（ＦＤＴ，ＥＳＧ，ＣＲＴ等）を送信する。

　次に、受信装置３０において実行するサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に基づく処理シーケンスの例について図２８に示すフローチャートを参照して説明する。

　　（ステップＳ２２１）
　まず、受信装置のデータ処理部は、ステップＳ２２１において、例えばＥＳＧや、ＦＤＴ等の事前取得データから、配信広告の送信時間情報を取得する。

　　（ステップＳ２２２）
　次に、受信装置は、ステップＳ２２２において、複数の異なる配信広告の送信時間が重複するか否かを判定する。
　重複することが確認された場合は、ステップＳ２２３に進む。
　重複しないことが確認された場合はステップＳ２２５に進む。

　　（ステップＳ２２３）
　複数の異なる配信広告の送信時間が重複することが確認された場合は、ステップＳ２２３に進み、配信広告対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を記録したデータ（ＦＤＴ，ＥＳＧ，ＣＲＴ等）を参照する。

　　（ステップＳ２２４）
　次に、受信装置は、ステップＳ２２４において、ステップＳ２２３で参照したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に基づいて、サービス選択優先度情報の高い広告を受信、キャッシュ対象として選択し、選択した広告を受信し、キャッシュ部に格納する。

　なお、アプリケーション制御により、この広告受信、キャッシュ処理を実行するためには、受信対象となる広告の受信、キャッシュ格納処理に適用するアプリケーションを起動することが必要であり、受信装置３０は、選択広告対応の処理を実行するアプリケーションを起動して、広告の受信、キャッシュ処理を実行する。

　　（ステップＳ２２５）
　一方、ステップＳ２２２の判定処理において、複数の異なる配信広告の送信時間が重複しないことが確認された場合はステップＳ２２５に進み、配信広告を順次、受信してキャッシュ部に格納する処理を実行する。

　このようにして、受信装置３０は、複数の異なる広告等のコンテンツの配信時間が競合した場合、１つのコンテンツを選択して受信、キャッシュ格納することが可能となる。

　上記の実施例ではアプリケーションを起動してその制御によりキャッシュ処理を実行したが、事前にアプリケーションがキャッシュＡＰＩによりＮＲＴファイルの取得を指示していた場合は、アプリケーションの起動なしに、データ受信部はＥＳＧの配信時間から判断して、ＮＲＴコンテンツをキャッシュに格納する処理を行うことも可能である。

　　［１１．各優先度情報の記録構成例について］
　上述した説明において、受信装置３０における広告等のコンテンツの優先取得判定に適用する優先度情報として、以下の２つの優先度情報について説明した。
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）

　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）は、先に図２１～図２３を参照して説明したように、特定の１つのチャンネルの１つの広告出力時間帯に出力可能な複数の広告コンテンツの各々に対応付けられた優先度情報である。
　１つのＮＲＴ送信チャンネルを介して連続的に配信される異なるコンテンツ（例えば異なる広告）データの各々に設定される優先度情報である。
　受信装置３０は、配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）に基づいて配信優先度の高いコンテンツ（広告）を選択的に受信、キャッシュすることができる。

　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、先に図２４～図２８を参照して説明したように、複数の異なるチャンネルを介して配信される広告コンテンツの各々に対応付けられた優先度情報である。
　受信装置３０は、複数の異なるチャンネルを介して配信される広告コンテンツの配信時間が重複する場合、各広告対応のサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を参照し、サービス選択優先度の高いコンテンツ（広告）を選択して受信、キャッシュすることができる。

　これら２つの優先度情報は、送信装置２０が受信装置に送信する広告コンテンツそのものに付随して送信することも可能であり、また、各広告コンテンツに先行して送信されるＥＳＧや、ＦＤＴ等のシグナリングデータに記録して提供することも可能である。

　これら２つの優先度情報は、広告データファィル（ＮＲＴコンテンツファイル）に直接記録することも可能であるが、広告データファイルに先行して送信される、例えば、以下の各データに記録して送信装置２０から受信装置３０に送信することが可能である。
　（ａ）番組表等を含む電子サービスガイドであるＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）
　（ｂ）各送信ファイルのメタデータを記録したＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）
　（ｃ）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）記録用の専用データであるＣＲＴ（Ｃｏｎｆｌｉｃｔ　Ｒｅｓｏｌｕｔｉｏｎ　Ｔａｂｌｅ）
　例えば、これらのデータのいずれかの利用が可能である。

　図２９に、各送信ファイルのメタデータを記録したＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）に、以下の２つの優先度情報を記録した例を示す。
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）

　図２９には、
　（１）放送番組等の配信データ
　（２）シグナリングデータ
　（３）広告セグセメント（ＮＲＴ）の配信データ
　これらの各データの配信例を示している。
　さらに、シグナリングデータの詳細として、
　（２ａ）広告２（Ａｄ２）対応のシグナリングデータ、
　（２ｂ）広告３（Ａｄ３）対応のシグナリングデータ、
　これらのシグナリングデータの詳細を示している。

　各シグナリングデータには、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの各優先度情報が記録され、さらに広告の配信時間情報等が記録される。

　受信装置は、各広告が送信装置から送信される前にこのシグナリングデータを受信し、シグナリングデータの解析を実行する。
　このシグナリングデータの解析に基づいて、送信予定の各広告に関する以下の各優先度情報、すなわち、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの優先度情報を取得し、取得した優先度情報に基づいて、受信、キャッシュ処理を実行する広告コンテンツを選択することができる。

　図３０以下を参照して、各送信ファイルのメタデータを記録するシグナリングデータであるＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）に、以下の２つの優先度情報を記録する場合の各優先度情報の記録位置の例について説明する。
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）

　図３０、図３１に示す例は、シグナリングデータであるＳ－ＴＳＩＤの、
　Ｓ－ＴＳＩＤ／ＲＳ／ＬＳ／ＳｒｃＦｌｏｗ／ＥＦＤＴ要素の属性（Ａｔｔｒｉｂｕｔｅ）に、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの優先度情報を記録した例である。

　図３０は、ＲＯＵＴＥで規定しているシグナリングデータであるＳ－ＴＳＩＤの構成を示している。Ｓ－ＴＳＩＤは、以下の各要素の階層構成を持つ。
　Ｓ－ＴＳＩＤ要素４１１、
　ＲＯＵＴＥセッション（ＲＯＵＴＥＳｅｓｓｉｏｎ）要素４１２、
　ＬＣＴセッション（ＬＣＴＳｅｓｓｉｏｎ）要素４１３、
　ソースフロー（ＳｏｕｒｃｅＦｌｏｗ）要素４１４、
　ＥＦＤＴ要素４１５、
　ファイル（Ｆｉｌｅ）要素４１７、
　これらの階層設定となる。

　各広告データに関する優先度情報は、
　ＥＦＤＴ要素４１５単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素４１６に記録することができる。
　この詳細構成を図３１に示す。

　アトリビュート（属性）記録領域には、規定の属性（Ａｔｔｒｉｂｕｔｅ）情報の記録領域の他、自由なデータを格納可能なデータ記録フィールド（ａｎｙ）が設定される。
　このデータ記録フィールド（ａｎｙ）に、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）４２１
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）４２２
　これらの優先度情報を記録する。

　なお、このアトリビュート（属性）記録領域には、図に示すように、複数の広告対応の上記２種類の優先度情報を、各広告毎に記録する設定とすることができる。
　あるいは、１つの広告対応の上記２種類の優先度情報のみを記録する設定としてもよい。

　各優先度情報の具体的な記述例（ＸＭＬデータ）を図３２、および、以下に示す。
　＜Ｓ－ＴＳＩＤ＞・・・＜ＲＳ＞・・・＜ＬＳ＞・・・＜ＳｒｃＦｌｏｗ＞・・・
　＜ＥＦＤＴ　ＤｅｌｉｖｅｒｙＰｒｉｏｒｉｔｙ＝"１０"　ＳｅｒｖｉｃｅＳｅｌｅｃｔｉｏｎＰｒｉｏｒｉｔｙ＝"８"＞・・・＜／ＥＦＤＴ＞
＜ＳｒｃＦｌｏｗ＞・・・＜ＬＳ＞・・・＜ＲＳ＞＞...＜／Ｓ－ＴＳＩＤ＞

　上記ＸＭＬデータは、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）＝１０
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）＝８
　の設定を持つ優先度情報を記録したデータの例である。

　図３０～図３２を参照して説明した例は、Ｓ－ＴＳＩＤのＥＦＤＴ要素の属性（Ａｔｔｒｉｂｕｔｅ）として、２つの優先度情報を記録した例であるが、図３０に示すＥＦＤＴ要素４１５の下位のＦｉｌｅ要素４１７の属性（Ａｔｔｒｉｂｕｔｅ）要素４１８に２つの優先度情報を記録することも可能である。

　すなわち、Ｓ－ＴＳＩＤ／ＲＳ／ＬＳ／ＳｒｃＦｌｏｗ／ＥＦＤＴ／Ｆｉｌｅ要素の属性（Ａｔｔｒｉｂｕｔｅ）に、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの優先度情報を記録することもできる。

　広告データの送信ファイルであるＮＲＴコンテンツファイル単位の属性情報は、
　ファイル（Ｆｉｌｅ）要素４１７単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素４１８に記録することができる。
　この詳細構成を図３３に示す。

　さらに、図３４を参照して、番組表等を含む電子サービスガイドであるＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）に、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの各優先度情報を記録する場合のデータ記録例について説明する。

　図３４は、ＥＳＧの構成（一部構成）を示す図である。
　ＥＳＧ５１０には、スケジュール（Ｓｃｈｅｄｕｌｅ）要素５１１が設定される。
　さらに、スケジュール（Ｓｃｈｅｄｕｌｅ）要素５１１以下に、
　コンテンツリフェランス（ＣｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ）要素５１３、
　ディストリビューションウィンドウ（ＤｉｓｔｒｉｂｕｔｉｏｎＷｉｎｄｏｗ）要素５１５、
　プレゼンテーションウィンドウ（ＰｒｅｓｅｎｔａｔｉｏｎＷｉｎｄｏｗ）要素５１６、
　これらの要素が配置される。
　各要素単位でアトリビュート（属性）要素が設定され、各要素単位の属性情報を記録することができる。

　コンテンツリフェランス（ＣｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ）要素５１３直下のアトリビュート（属性）要素５１４には、
　ｉｄＲｅｆ５２１が記録される。
　ｉｄＲｅｆ５２１は、このスケジュール要素全体に記録されている情報が、どのコンテンツセグメント対応の情報であるかを識別可能とした情報である。例えば、このスケジュール要素全体に記録されている情報が、どの広告コンテンツ対応の情報であるかを識別することができる。

　「配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）」は、
　ディストリビューションウィンドウ（ＤｉｓｔｒｉｂｕｔｉｏｎＷｉｎｄｏｗ）要素５１５直下のアトリビュート（属性）要素５３１に記録する。

　また、「サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）」は、
　プレゼンテーションウィンドウ（ＰｒｅｓｅｎｔａｔｉｏｎＷｉｎｄｏｗ）要素５１６直下のアトリビュート（属性）要素５３２に記録する。

　図３５に、ディストリビューションウィンドウ（ＤｉｓｔｒｉｂｕｔｉｏｎＷｉｎｄｏｗ）要素５１５直下のアトリビュート（属性）要素５３１の記録情報と、
　プレゼンテーションウィンドウ（ＰｒｅｓｅｎｔａｔｉｏｎＷｉｎｄｏｗ）要素５１６直下のアトリビュート（属性）要素５３２の記録情報の例を示す。

　ディストリビューションウィンドウ（ＤｉｓｔｒｉｂｕｔｉｏｎＷｉｎｄｏｗ）要素５１５直下のアトリビュート（属性）要素５３１には、図に示すように、
　広告コンテンツ（ＮＲＴコンテンツファイル）の配信時間情報、すなわち、広告コンテンツ（ＮＲＴコンテンツファイル）の配信開始時間と終了時間が記録され、さらに、
　サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）が記録される。

　また、プレゼンテーションウィンドウ（ＰｒｅｓｅｎｔａｔｉｏｎＷｉｎｄｏｗ）要素５１６直下のアトリビュート（属性）要素５３２には、
　広告コンテンツの出力時間情報、すなわち受信装置における広告の出力時間の開始時間と終了時間が記録され、さらに、
　配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）が記録される。

　受信装置は、各放送局が送信する様々な広告コンテンツの配信前にＥＳＧを受信可能であり、受信したＥＳＧを解析して、配信予定の各広告コンテンツに対応する、以下の優先度情報、すなわち、
　（１）配信優先度情報（Ｄｅｌｉｖｅｒｙ　Ｐｒｉｏｒｉｔｙ）
　（２）サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）
　これらの各優先度情報を取得することが可能となる。

　受信装置３０は、取得した優先度情報に従って、受信、キャッシュ処理を実行する広告コンテンツを選択することが可能となる。

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

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

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

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

　一方、受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
　通信部７７２は、送信装置（サーバ）２０から配信されるデータ、例えばＡＶセグメントやアプリケーション、アプリケーションによって利用されるデータ、ＮＲＴコンテンツファイル、シグナリングデータ等を受信する。

　データ処理部７７１は、通信データ処理部７７１ａ、再生処理部７７１ｂを有し、例えば先に説明した実施例に従った処理等を実行する。
　具体的には、アプリケーションを利用したデータ処理等を実行する。

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

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

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

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

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

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

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

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

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理部を有する送信装置。

　（２）　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、
　異なるチャンネルを介した送信コンテンツの配信時間が重複する場合に、前記受信装置が、前記サービス選択優先度情報の高い値のコンテンツをキャッシュ対象として選択することを可能とした優先度情報である（１）に記載の送信装置。

　（３）　前記データ処理部は、
　送信コンテンツの各々についての配信時間情報を前記受信装置に送信する（１）または（２）に記載の送信装置。

　（４）　前記コンテンツは、広告コンテンツである（１）～（３）いずれかに記載の送信装置。

　（５）　前記コンテンツは、
　受信装置において、ユーザ（視聴者）情報に応じて選択出力される広告コンテンツである（１）～（４）いずれかに記載の送信装置。

　（６）　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、電子サービスガイド（ＥＳＧ：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）に記録して送信する（１）～（５）いずれかに記載の送信装置。

　（７）　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、シグナリングデータに記録して送信する（１）～（５）いずれかに記載の送信装置。

　（８）　前記シグナリングデータは、ＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）である（７）に記載の送信装置。

　（９）　コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置。

　（１０）　前記データ処理部は、
　異なるチャンネルを介して送信される複数コンテンツの配信時間が重複するか否かを判定し、
　配信時間が重複すると判定した場合に、
　配信時間が重複する複数コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する（９）に記載の受信装置。

　（１１）　前記コンテンツは、広告コンテンツである（９）または（１０）に記載の受信装置。

　（１２）　前記コンテンツは、
　受信装置において、ユーザ（視聴者）情報に応じて選択出力される広告コンテンツである（９）～（１１）いずれかに記載の受信装置。

　（１３）　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、電子サービスガイド（ＥＳＧ：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）から取得する（９）～（１２）いずれかに記載の受信装置。

　（１４）　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、シグナリングデータから取得する（９）～（１２）いずれかに記載の受信装置。

　（１５）　前記シグナリングデータは、ＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）である（１４）に記載の受信装置。

　（１６）　送信装置において実行するデータ処理方法であり、
　データ処理部が、
　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理方法。

　（１７）　受信装置において実行するデータ処理方法であり、
　データ処理部が、コンテンツを受信し、キャッシュ部に格納する処理を実行し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法。

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

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

　以上、説明したように、本開示の一実施例の構成によれば、異なるチャンネルを介した送信コンテンツの配信時間が重複した場合に、受信装置が、優先度情報に基づいて取得対象を選択可能とした構成が実現される。
　具体的には、送信装置が、送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、サービス選択優先度情報を受信装置に送信する。サービス選択優先度情報は、異なるチャンネルを介した送信コンテンツの配信時間が重複する場合に、受信装置が、サービス選択優先度情報の高い値のコンテンツをキャッシュ対象として選択することを可能とした優先度情報として利用される。
　本構成により、異なるチャンネルを介した送信コンテンツの配信時間が重複した場合に、受信装置が、優先度情報に基づいて取得対象を選択可能とした構成が実現される。

　　１０　通信システム
　　２０　送信装置
　　２１　放送サーバ
　　２２　広告サーバ
　　２３　データ配信サーバ
　　３０　受信装置
　　３１　ＴＶ
　　３２　ＰＣ
　　３３　携帯端末
　　５０　シグナリングデータ
　　６０　ＡＶセグメント
　　７０　その他のデータ
　１１０　アプリケーション制御部
　１１１　アプリケーション実行部
　１１２　広告挿入ＡＰＩ
　１１４　キャッシュ制御ＡＰＩ
　１２０　再生制御部
　１２１　ＭＰＤ取得部
　１２２　ＭＰＤ解析部
　１２３　セグメント取得部
　１２４　セグメント解析部
　１３０　ベースシステム
　１３１　キャッシュ制御部
　１３２　キャッシュ部
　１３３　第１通信部（チューナ）
　１３４　第２通信部（ネットワークＩ／Ｆ）
　１３３　出力制御部
　１４１　復号部
　１４２　出力部
　３１１～３１４　ピリオド情報
　７５１　データ処理部
　７５２　通信部
　７５３　記憶部
　７７１　データ処理部
　７７２　通信部
　７７３　記憶部
　７７４　入力部
　７７５　出力部
　８０１　ＣＰＵ
　８０２　ＲＯＭ
　８０３　ＲＡＭ
　８０４　バス
　８０５　入出力インタフェース
　８０６　入力部
　８０７　出力部
　８０８　記憶部
　８０９　通信部
　８１０　ドライブ
　８１１　リムーバブルメディア

Claims

　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理部を有する送信装置。
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）は、
　異なるチャンネルを介した送信コンテンツの配信時間が重複する場合に、前記受信装置が、前記サービス選択優先度情報の高い値のコンテンツをキャッシュ対象として選択することを可能とした優先度情報である請求項１に記載の送信装置。
　前記データ処理部は、
　送信コンテンツの各々についての配信時間情報を前記受信装置に送信する請求項１に記載の送信装置。
　前記コンテンツは、広告コンテンツである請求項１に記載の送信装置。
　前記コンテンツは、
　受信装置において、ユーザ（視聴者）情報に応じて選択出力される広告コンテンツである請求項１に記載の送信装置。
　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、電子サービスガイド（ＥＳＧ：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）に記録して送信する請求項１に記載の送信装置。
　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、シグナリングデータに記録して送信する請求項１に記載の送信装置。
　前記シグナリングデータは、ＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）である請求項７に記載の送信装置。
　コンテンツを受信し、キャッシュ部に格納するデータ処理部を有し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する受信装置。
　前記データ処理部は、
　異なるチャンネルを介して送信される複数コンテンツの配信時間が重複するか否かを判定し、
　配信時間が重複すると判定した場合に、
　配信時間が重複する複数コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納する請求項９に記載の受信装置。
　前記コンテンツは、広告コンテンツである請求項９に記載の受信装置。
　前記コンテンツは、
　受信装置において、ユーザ（視聴者）情報に応じて選択出力される広告コンテンツである請求項９に記載の受信装置。
　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、電子サービスガイド（ＥＳＧ：Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）から取得する請求項９に記載の受信装置。
　前記データ処理部は、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を、シグナリングデータから取得する請求項９に記載の受信装置。
　前記シグナリングデータは、ＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）である請求項１４に記載の受信装置。
　送信装置において実行するデータ処理方法であり、
　データ処理部が、
　送信コンテンツの各々について、受信装置におけるキャッシュ処理優先度判定基準として利用可能なサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を設定し、
　前記サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を受信装置に送信するデータ処理方法。
　受信装置において実行するデータ処理方法であり、
　データ処理部が、コンテンツを受信し、キャッシュ部に格納する処理を実行し、
　前記データ処理部は、
　前記コンテンツの各々に対応して設定されたサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）を取得し、
　取得したサービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）に従い、サービス選択優先度情報（Ｓｅｒｖｉｃｅ　Ｓｅｌｅｃｔｉｏｎ　Ｐｒｉｏｒｉｔｙ）の設定値の高いコンテンツを優先して受信し、キャッシュ部に格納するデータ処理方法。