WO2016199513A1

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

Info

Publication number: WO2016199513A1
Application number: PCT/JP2016/062984
Authority: WO
Inventors: 山岸　靖明
Original assignee: ソニー株式会社
Priority date: 2015-06-09
Filing date: 2016-04-26
Publication date: 2016-12-15
Also published as: KR20180016976A; CA2981693A1; CA2981693C; EP3310065B1; US20220335475A1; EP3310065A4; US11410199B2; CN107615774B; US20210081995A1; MX2017015534A; JPWO2016199513A1; CN107615774A; KR102532046B1; EP3310065A1; US20180053217A1; US10885555B2

Abstract

受信装置に、受信装置側ユーザに応じた広告等のコンテンツを選択して出力可能とする装置、方法を提供する。送信装置が、ユーザ情報設定領域を有するシグナリングデータ（ＭＰＤ）と、ＭＰＤに対する処理によって生成されるユーザ情報設定済みデータを適用してアクセスまたは生成可能な制御情報ファイルと、制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応広告を送信する。受信装置は、ＭＰＤのユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用してユーザ情報対応広告の制御情報ファイルを取得し、取得した制御情報ファイルの記述データを適用してユーザ情報対応広告を取得し、出力する。

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　本開示の第１の側面は、
　ユーザ情報設定領域を有するシグナリングデータを受信する通信部と、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツを取得するデータ処理部を有する受信装置にある。

　さらに、本開示の第２の側面は、
　ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信する通信部を有する送信装置にある。

　さらに、本開示の第３の側面は、
　受信装置において実行するデータ処理方法であり、
　通信部が、ユーザ情報設定領域を有するシグナリングデータを受信し、
　データ処理部が、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツの取得処理を実行するデータ処理方法にある。

　さらに、本開示の第４の側面は、
　送信装置において実行するデータ処理方法であり、
　ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信するデータ処理方法にある。

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

　本開示の一実施例の構成によれば、受信装置に、受信装置側のユーザに応じた広告等のコンテンツを選択して出力可能とする装置、方法が実現される。
　具体的には、送信装置が、ユーザ情報設定領域を有するシグナリングデータ（ＭＰＤ）と、ＭＰＤに対する処理によって生成されるユーザ情報設定済みデータを適用してアクセスまたは生成可能な制御情報ファイルと、制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応広告を送信する。受信装置は、ＭＰＤのユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用してユーザ情報対応広告の制御情報ファイルを取得し、取得した制御情報ファイルの記述データを適用してユーザ情報対応広告を取得し、出力する。
　本構成により、受信装置に、受信装置側のユーザに応じた広告等のコンテンツを選択して出力可能とした装置、方法が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。送信装置の送信データについて説明する図である。送信装置および受信装置のプロトコルスタックの例を示す図である。ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。受信装置（クライアント）３０におけるデータ出力例を説明する図である。様々なユーザ情報を利用した出力広告の選択例について説明する図である。受信装置の構成例について説明する図である。受信装置の構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの利用シーケンス例について説明する図である。ＭＰＤ内の広告対応ピリオド情報の構成例について説明する図である。ＭＰＤの広告対応ピリオド情報を利用した処理シーンスについて説明する図である。ＭＰＤ内の広告対応ピリオド情報の構成例について説明する図である。ＭＰＤの広告対応ピリオド情報を利用した処理シーンスについて説明する図である。ＭＰＤの広告対応ピリオド情報を利用した処理シーンスについて説明する図である。クエリパラメータ付きＵＲＬを含むシグナリングデータや、ピリオド情報ファイルの提供処理例について説明する図である。クエリパラメータ付きＵＲＬと、ピリオド情報ファイルとの対応関係の設定例について説明する図である。クエリパラメータ付きＵＲＬを含むシグナリングデータや、ピリオド情報ファイルの提供処理例について説明する図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例の処理シーケンスについて説明する図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）の一例を示す図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）のＸＭＬデータの一例を示す図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）の一例を示す図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）のＸＭＬデータの一例を示す図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する図である。クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する図である。クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤ内の広告対応ピリオド情報の構成例について説明する図であピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブル（対応表）の一例を示す図すである。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブル（対応表）の一例を示す図すである。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブル（対応表）の一例を示す図すである。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する図である。ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する図である。クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する図である。クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する図である。通信装置である送信装置と受信装置の構成例について説明する図である。通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

　以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．受信装置におけるデータ出力例について
　５．受信装置の構成例と処理例について
　６．ＭＰＤを利用したピリオド（Ｐｅｒｉｏｄ）単位のシグナリングデータについて
　７．ユーザ情報に応じた広告提供処理を実行するための具体的構成例について
　８．受信装置にユーザ情報対応の選択コンテンツを出力するためのピリオド情報ファイルの提供と利用処理の具体的実施例について
　８－１．（実施例１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例
　８－２．（実施例２）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬ（またはクエリパラメータ）とのマッピングテーブルを受信装置に提供する実施例
　８－３．（実施例３）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例
　８－４．（実施例４）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する実施例
　８－５．（実施例５）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する実施例
　８－６．（実施例６）質問回答形式メタデータ（ＰＤＩ）を利用した実施例
　８－６－１．（実施例６－１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例
　８－６－２．（実施例６－２）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する構成において、ＰＤＩテーブルを利用した実施例
　８－６－３．（実施例６－３）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する構成において、ＰＤＩテーブルを利用した実施例
　８－６－４．（実施例６－４）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する構成において、ＰＤＩテーブルを利用した実施例
　９．送信装置と受信装置の構成例について
　１０．本開示の構成のまとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　［５．受信装置の構成例と処理例について］
　次に、図７以下を参照して受信装置３０の構成例と処理例について説明する。
　なお、図７には、受信装置の例として、チューナ実装受信装置（クライアントＡ）３５と、チューナ非実装受信装置（クライアントＢ）３６を示している。
　チューナ実装受信装置（クライアントＡ）３５は、放送サーバや、広告サーバ等の送信装置２０からの送信データを受信するミドルウェア１１０と、受信データの解析や蓄積処理を実行するプロキシサーバ１２０を有する受信装置である。

　一方、チューナ非実装受信装置（クライアントＢ）３６は、送信装置２０からの送信データを受信するミドルウェア１１０や、受信データの解析や蓄積処理を実行するプロキシサーバ１２０を有していない受信装置である。
　チューナ非実装受信装置（クライアントＢ）３６は、例えばイーサネット（登録商標）やＷｉ－Ｆｉ等のネットワークによって、チューナ実装受信装置（クライアントＡ）３５と接続され、チューナ実装受信装置（クライアントＡ）３５との通信を実行する。
　チューナ非実装受信装置（クライアントＢ）３６は、チューナ実装受信装置（クライアントＡ）３５が、放送サーバや、広告サーバ等の送信装置２０から受信したデータを、チューナ実装受信装置（クライアントＡ）３５を介して受信し、コンテンツ再生を実行する。

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

　図７に示すように、チューナ実装受信装置３５はミドルウェア１１０、ＨＴＴＰプロキシサーバ１２０、再生制御部（ＤＡＳＨクライアント）１３１、出力制御部１３２を有する。

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

　ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１ａに格納される。プロキシサーバ１２０は、さらにネットワーク経由で送信装置２０から取得したデータをキャッシュ部（プロキシキャッシュ）１２１ｂに格納する。
　プロキシサーバ１２０は、再生制御部１３１からのデータ要求をアドレス解決＆リンク解決部（Ａｄｄｒｅｓｓ　＆　Ｘｌｉｎｋ　Ｒｅｓｏｌｖｅｒ）１２２に入力し、要求されたデータをキャッシュ部（プロキシキャッシュ）１２１ａ，ｂ、または外部から取得して提供する。

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

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

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

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

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

　なお、番組スケジュール（番組表）や、アドレス情報、コーデック情報等のシグナリングデータは、随時更新される可能性があり、受信装置では、最新のシグナリングデータを利用した処理を行なう必要がある。

　さらに、図７に示すチューナ非実装受信装置（クライアントＢ）３６は、例えばイーサネット（登録商標）やＷｉ－Ｆｉ等のネットワークによって、チューナ実装受信装置（クライアントＡ）３５と接続され、チューナ実装受信装置（クライアントＡ）３５との通信を実行する。
　チューナ非実装受信装置（クライアントＢ）３６は、チューナ実装受信装置（クライアントＡ）３５が、放送サーバ２１や広告サーバ２２等の送信装置２０から受信したコンテンツ等のデータを、チューナ実装受信装置（クライアントＡ）３５を介して受信し、コンテンツ再生を実行する。

　図７に示すチューナ非実装受信装置（クライアントＢ）３６は、
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１５１、
　出力制御部１５２、
　これらの構成を有する。
　これらの構成、機能は、チューナ実装受信装置（クライアントＡ）３５において説明した再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１、出力制御部１３２と同様である。

　図８は、チューナ実装受信装置（クライアントＡ）３５の有する、
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１、
　出力制御部１３２、
　これらの詳細構成を示す図である。

　チューナ実装受信装置（クライアントＡ）３５の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＭＰＤ取得部２０１、ＭＰＤ解析部２０２、セグメント取得部２０３、セグメント（ＭＰ４）解析部２０４を有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　受信装置は、図１３に示す広告対応のピリオド情報３１１内のリンク情報（Ｘｌｉｎｋ）に含まれるユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）にユーザ情報（パラメータ）を設定する。
　ユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）にユーザ情報（パラメータ）を設定したデータ（ユーザ情報設定済みデータ）が、ユーザに対応する広告データ対応のピリオド情報ファイルのアクセス情報（ＵＲＬ）、またはＵＲＬの構成データとなる。

　すなわち、図１１、図１３に示すＭＰＤ内の広告対応のピリオド情報には、広告データを格納したセグメントファイルのアクセス情報（セグメントＵＲＬ）は、記録されていない。
　図１１、図１３に示すＭＰＤ内の広告対応のピリオド情報内のリンク情報（Ｘｌｉｎｋ）に含まれるユーザ情報設定フィールドにユーザ情報（パラメータ）を設定することで、ユーザ対応の広告データ（セグメントファイル）を取得するためのアクセス情報を記録した真のピリオド情報ファイルを取得するためのアクセス情報（ＵＲＬ）が完成する。または、真のピリオド情報ファイルを取得するためのアクセス情報（ＵＲＬ）を特定するためのデータが完成する。

　図１３に示す広告対応のピリオド情報３１１のデータ構成について説明する。
　「Ｐｅｒｉｏｄ　Ａ１　（Ａｄ　Ｂｒｅａｋ　＃１）」は、ピリオド情報の識別子記録領域であり、識別子（Ａ１）の広告（Ａｄ）関連のピリオド情報であることを示している。

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

　本構成の場合、具体的には、本来のピリオド情報、すなわち、図１０、図１２を参照して説明した、以下の各データ、
　アダプテーション、
　リプレゼンテーション、
　セグメントインフォ、
　これらの具体的データの記述を有するピリオド情報ファイルを取得するためのアクセス情報（ＵＲＬ）を記録したフィールドとなる。

　ただし、ユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）にユーザ情報（パラメータ）を設定して始めてユーザ情報に従って選択される広告データに対応する真のピリオド情報ファイルを取得するためのアクセス情報（ＵＲＬ）が完成する。

　ユーザ情報設定フィールドには、例えば、視聴者（ユーザ）の年齢、性別、住所、趣味、嗜好等を設定することができる。
　年齢設定例としては、例えば、「ａｇｅ＝１０－１９」のような設定が可能である。この設定は、ユーザが１０～１９歳の範囲にあることを示す。
　住所設定例としては、例えば、「ｌｏｃａｔｉｏｎ＝ＬＡ」のような設定が可能である。この設定は、ユーザがロスアンゼルス（ＬＡ）に住んでいることを示す。

　このようなユーザ情報をユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）に設定することで、ユーザ対応の広告データに関する全ての制御情報（アダプテーション、リプレゼンテーション、セグメントインフォ等）を含む真のピリオド情報ファイルのアクセス情報（ＵＲＬ）を完成させることができる。

　「＠ｘｌｉｎｋ：ａｃｔｕａｔｅ＝"ｏｎＲｅｑｕｅｓｔ"」
　この情報記録フィールドも、リンク（Ｘｌｉｎｋ）情報記録フィールドの構成要素である。
　なお、「＠ｘｌｉｎｋ：ａｃｔｕａｔｅ＝」は、「＠ｘｌｉｎｋ：ｈｒｅｆ＝」に示されたＵＲＬによってアクセスされるデータの取得タイミングを規定したフィールドであることを示している。

　本構成の場合、このフィールドは、上記のパラメータ設定ＵＲＬを利用して取得可能となるピリオド情報ファイルの取得タイミングを規定するフィールドとなる。
　取得タイミングの設定としては、
　（ａ）ａｃｔｕａｔｅ＝"ｏｎＲｅｑｕｅｓｔ"
　（ｂ）ａｃｔｕａｔｅ＝"ｏｎＬｏａｄ"
　上記（ａ），（ｂ）の２種類が設定可能である。

　（ａ）ａｃｔｕａｔｅ＝"ｏｎＲｅｑｕｅｓｔ"
　この設定は、上記のパラメータ設定ＵＲＬを利用して取得可能となるピリオド情報ファイルの取得タイミングは、広告開始タイミング（図１１の例では時間ｔ０）までであれば、いつでも可能であることを示している。

　（ｂ）ａｃｔｕａｔｅ＝"ｏｎＬｏａｄ"
　この設定は、上記のパラメータ設定ＵＲＬを利用して取得可能となるピリオド情報ファイルの取得を、図１１に示すＭＰＤの取得後、すぐに行うことを要求する設定であることを示している。

　「＠ｓｔａｒｔ＝０」
　この情報記録フィールドは、このピリオド情報対応のデータ（広告コンテンツ）の出力開始タイミングを記録したフィールドである。
　ｓｔａｒｔ（開始時間）＝０（図１１の例における時間ｔ０に相当）から、広告が開始されることを示している。

　「＠ｄｕｒａｔｉｏｎ＝６０ｓｅｃ」
　この情報記録フィールドは、このピリオド情報対応のデータ（広告コンテンツ）の出力継続時間を記録したフィールドである。
　ｄｕｒａｔｉｏｎ（継続時間）＝６０ｓｅｃは、６０秒間の広告であることを示している。

　図１１や図１３を参照して説明したように、本開示の構成では、ＭＰＤに設定する広告出力時間区間に対応のピリオド情報に、ユーザ情報設定フィールドを設け、各受信装置（クライアント）において設定したユーザ情報に応じて、提供広告を動的に変更可能な構成としている。

　受信装置（クライアント）に配信されるＭＰＤ（例えばサービスシグナリングにより配信される）は、
　ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆの位置にユーザ情報を設定してピリオド情報ファイルのアクセス情報（ＵＲＬ）を記述することができる。
　このＵＲＬは、例えば受信装置のプロキシサーバ１２０のリンク解決部（ＸＬｉｎｋ　Ｒｅｓｏｌｖｅｒ）１２２において、特定のピリオド情報ファイルのアクセス情報（ＵＲＬ）として認識できる。

　ＵＲＬは、例えば、ｈｔｔｐ：／／ａ．ｃｏｍ？ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄のような形式でエンコードされており、受信装置（クライアント）では、ｇｒｏｕｐＩＤのパラメータ部分にエンドユーザを特定するユーザ情報として例えばグループＩＤ（ｇｒｏｕｐＩＤ）の値を挿入する。
　例えば、ｈｔｔｐ：／／ａ．ｃｏｍ？ｕｓｅｒ＝ｃｌａｓｓＡ

　このユーザ情報設定ＵＲＬを、リモートのｈｔｔｐサーバ、もしくは、クライアントデバイスに実装されたＨＴＴＰ　Ｓｅｒｖｅｒ上のリンク解決部（ＸＬｉｎｋ　Ｒｅｓｏｌｖｅｒ）にｈｔｔｐリクエストとして発行する。
　リンク解決部（ＸＬｉｎｋ　Ｒｅｓｏｌｖｅｒ）は、ｃｌａｓｓＡのユーザ向けに生成されて、ＲＯＵＴＥプロトコル（一方向マルチキャストネットワーク（地上波等の放送を含む）経由の場合）や、ＨＴＴＰ（双方向ネットワーク経由の場合）により配信される広告セグメントのＵＲＬ等を含むピリオド情報ファイルを受信装置の再生制御部に返信する。
　受信装置の再生制御部は、ピリオド情報ファイルに記録された広告セグメントＵＲＬを用いて広告セグメントの取得処理を行い、広告を再生する。

　図１３に示すような広告データ対応のピリオド情報３１１を適用して、受信装置側で広告データを取得して出力（再生）する処理を実行する場合の処理シーケンスについて、図１４に示すフローチャートを参照して説明する。

　図１４に示すフローチャートは、例えば、図１１や図１３に示すピリオド単位の情報を記録したＭＰＤを取得した受信装置において実行する処理シーケンスを説明するフローチャートである。
　以下、各ステップの処理について、順次、説明する。

　　（ステップＳ１１）
　まず、受信装置は、制御対象の番組に対応するシグナリンクデータとして、番組開始前に受信済みのＭＰＤ、例えば、図１１に示すピリオド情報３１１～３１４を含むＭＰＤから、広告（Ａｄ）に対応するピリオド情報を選択する。
　さらに、選択した広告（Ａｄ）対応のピリオド情報中のリンク情報（Ｘｌｉｎｋ）内に設定された「ユーザ情報設定フィールド」にパラメータ（ユーザ情報）を設定する。

　このパラメータ設定により、ユーザに最適な広告コンテンツに対応する制御情報を記録したビリオド情報ファイルのアクセス情報（ＵＲＬ）が完成する。
　例えば、以下のようなパラメータ設定ＵＲＬを生成する。
　パラメータ設定ＵＲＬ例：ｈｔｔｐ：／／ａ．ｃｏｍ／ＸＬｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝１０－１９＆ｌｏｃａｔｉｏｎ＝ＬＡ

　上記ＵＲＬ例は、ユーザ情報として、
　年齢（ａｇｅ）＝１０～１９歳
　住所または居所（Ｌｏｃａｔｉｏｎ）＝ＬＡ（ロスアンゼルス）
　これらのパラメータを設定したＵＲＬである。
　このパラメータ設定ＵＲＬによって、ロスアンゼルスに住んでいる１０～１９歳のユーザ（視聴者）に最適な広告コンテンツのアクセス情報（セグメントＵＲＬ）等が記録されたユーザ対応のピリオド情報を取得することができる。

　　（ステップＳ１２）
　次に、受信装置は、ステップＳ１２において、パラメータを設定したピリオド情報ファイルのアクセス情報（ＵＲＬ）を利用して、ユーザ対応のピリオド情報ファイルの取得処理を実行する。

　様々なユーザに対応する異なるピリオド情報ファイルは、例えば、放送波、ネットワークを介して随時、取得可能となる。ピリオド情報ファイルは、先に図２を参照して説明したシグナリングデータ５０の一部であり、送信装置２０から、放送波、ネットワークを介して随時、送信されている。受信装置３０は、ステップＳ１１において生成したパラメータ設定済みのＵＲＬによって、取得するピリオド情報ファイルを特定して１つのユーザ対応のピリオド情報ファイルを取得する。

　　（ステップＳ１３）
　次に、受信装置は、ステップＳ１３において、取得したユーザ対応のピリオド情報ファイルに記録された広告セグメントアクセス情報（広告セグセメントＵＲＬ）を適用して、広告セグメントを取得する。

　取得したユーザ対応のピリオド情報ファイルには、先に図９、図１２を参照して説明した情報、すなわち、
　アダプテーション情報、
　リプレゼンテーション情報、
　セグメントインフォ情報、
　これらの情報が記録されており、ユーザ対応の広告データの取得、再生に必要な全ての情報が記録されている。

　受信装置は、取得したユーザ対応のピリオド情報ファイルに記録された広告セグメントアクセス情報（広告セグセメントＵＲＬ）を適用して、広告セグメントを取得する。

　　（ステップＳ１４）
　最後に、受信装置は、ステップＳ１４において、取得した広告セグメントを、ユーザ装置である受信装置において、出力（再生）する。なお、出力時間等は、取得したピリオド情報ファイルに記録されている。
　これらの処理によって、受信装置には、ユーザ（視聴者）に応じた最適な広告が出力されることになる。

　ステップＳ１１におけるパラメータ設定例として説明したパラメータ、すなわち、ユーザ情報として、
　年齢（ａｇｅ）＝１０～１９歳
　住所または居所（Ｌｏｃａｔｉｏｎ）＝ＬＡ（ロスアンゼルス）
　これらのパラメータを設定した場合、
　ステップＳ１４では、ロスアンゼルス在住の１０～１９歳の視聴者（ユーザ）をメインターゲットとした広告が選択されて出力されることになる。

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

　受信装置は、図１３に示す広告対応のピリオド情報３１１内のリンク情報（Ｘｌｉｎｋ）に含まれるアクセス情報（ＵＲＬ）内のユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）にユーザ情報（パラメータ）を設定して、ユーザ情報（パラメータ）を設定したアクセス情報（ＵＲＬ）を用いてユーザ対応の広告データに関する制御情報を記録したピリオド情報ファイルを取得する。

　しかし、この構成とすると、ユーザ情報（パラメータ）を設定したアクセス情報（ＵＲＬ）を適用して、広告出力時間までにピリオド情報ファイルが取得できないとユーザ対応広告が出力できない事態が発生する恐れがある。
　図１５に示すピリオド情報３１１ｂは、このような事態を防止可能とした構成を持つ。

　図１５に示すピリオド情報３１１ｂは、ユーザ情報設定フィールドを含むリンク情報３２０に加えて、ユーザ情報を適用することなく、多くのユーザに共通に提供可能な広告に関するピリオド情報を予め記録した構成を持つ。
　図１５に示すユーザ情報非適用ピリオド情報記録領域３２１には、多くのユーザに共通に提供可能な広告に関するピリオド情報が記録される。
　すなわち、ユーザ情報非適用ピリオド情報記録領域３２１には、多くのユーザに共通に提供可能な広告に関するピリオド情報の全て、すなわち、アダプテーション、リプレゼンテーション、セグメントインフォ、これらの具体的データの記述が含まれる。

　このような構成とすることで、受信装置は、ユーザ情報（パラメータ）設定ＵＲＬにより、ユーザ対応の広告に関するピリオド情報が取得できない場合でも、ピリオド情報３１１ｂを適用して広告セグメントを取得して、受信装置において出力することが可能となる。

　図１５に示すユーザ情報非適用ピリオド情報記録領域３２１を有するピリオド情報３１１ｂを適用して、受信装置側で広告データを取得して出力（再生）する処理を実行する場合の処理シーケンスについて、図１６に示すフローチャートを参照して説明する。
　以下、各ステップの処理について、順次、説明する。

　　（ステップＳ２１～Ｓ２２）
　ステップＳ２１～Ｓ２２の処理は、図１４に示すフローにおいて説明したステップＳ１１～Ｓ１２の処理と同様の処理である。
　まず、受信装置は、制御対象の番組に対応するシグナリンクデータとして、番組開始前に受信済みのＭＰＤ、例えば、図１１に示すピリオド情報３１１～３１４を含むＭＰＤから、広告（Ａｄ）に対応するピリオド情報を選択する。
　さらに、選択した広告（Ａｄ）対応のピリオド情報中のリンク情報（Ｘｌｉｎｋ）内に設定された「ユーザ情報設定フィールド」にパラメータ（ユーザ情報）を設定する。

　次に、受信装置は、ステップＳ２２において、パラメータを設定したピリオド情報ファイルのアクセス情報（ＵＲＬ）を利用して、ユーザ対応のピリオド情報ファイルの取得処理を実行する。

　　（ステップＳ２３）
　受信装置は、ステップＳ２３において、予め規定した時間以内にユーザ対応ピリオド情報ファイルの取得に成功したか否かを判定する。
　取得に成功した場合は、ステップＳ２４に進み、取得に失敗した場合はステップＳ２５に進む。

　　（ステップＳ２４）
　ステップＳ２３において、ユーザ対応ピリオド情報ファイルの取得に成功したことが確認された場合、受信装置は、ステップＳ２４において、取得したユーザ対応のピリオド情報ファイルに記録された広告セグメントアクセス情報（広告セグセメントＵＲＬ）を適用して、広告セグメントを取得する。

　　（ステップＳ２５）
　一方、ステップＳ２３において、ユーザ対応ピリオド情報ファイルの取得に失敗したことが確認された場合、受信装置は、ステップＳ２５において、取得済みのピリオド情報（図１５に示すピリオド情報３１１ｂ）に記録されたユーザ情報非適用ピリオド情報を読み取り、このピリオド情報３１１ｂに記録された広告セグメントアクセス情報（広告セグセメントＵＲＬ）を適用して、広告セグメントを取得する。

　　（ステップＳ２６）
　最後に、受信装置は、ステップＳ２６において、取得した広告セグメントを、ユーザ装置である受信装置において、出力（再生）する。なお、出力時間等は、取得したピリオド情報ファイルに記録されている

　ステップＳ２４の処理を実行した場合は、ユーザ（視聴者）情報に対応した広告が出力されることになる。
　一方、ステップＳ２５の処理を実行した場合は、ユーザ（視聴者）情報を適用しない、多くのユーザに共通に提供される広告が出力されることになる。

　図１３～図１６を参照して説明したように、リンク情報を記録したピリオド情報には、様々な設定が可能であり、その記録情報に応じた処理が受信装置において実行される。
　図１７は、受信装置３０における処理シーケンスを説明する図である。
　図１７には、受信装置３０のプロキシサーバ１２０と、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１を示している。

　プロキシサーバ１２０は、放送波やネットワークを介して送信装置２０から送信される様々なデータを予め取得し、キャッシュ部（プロキシキャッシュ）１２１に格納する。

　再生制御部１３１は、まず、ステップＳ５１において、視聴対象番組に対応するシグナリングデータ（制御情報）を含むＭＰＤをプロキシサーバ１２０から取得する。
　例えば、図１１に示すＭＰＤである。

　次に、再生制御部１３１は、取得したＭＰＤに記録されたユーザ情報設定フィールドを含むアクセス情報（ＵＲＬ）にユーザ情報（パラメータ）を設定する。
　再生制御部１３１は、ステップＳ５２において、ユーザ情報（パラメータ）設定ＵＲＬをプロキシサーバ１２０のリンク解決部（ＸＬｉｎｋ　Ｒｅｓｏｌｖｅｒ）１２２に出力する。

　プロキシサーバ１２０のリンク解決部（ＸＬｉｎｋ　Ｒｅｓｏｌｖｅｒ）１２２は、ユーザ情報（パラメータ）設定ＵＲＬを解析して、ＵＲＬに対応するピリオド情報ファイルをキャッシュ部１２１から取得し、ステップＳ５３において、再生制御部１３１に出力する。

　再生制御部１３１は、取得したピリオド情報ファイルに記録された広告セグメントＵＲＬを適用して、ステップＳ５４において、プロキシサーバ１２０から広告セグメントを取得して出力する。
　このようなシーケンスによって、ユーザ対応の広告が選択出力されることになる。

　なお、プロキシサーバ１２０のキャッシュ部１２１に、再生制御部１３１から要求されたデータが格納されていない場合は、プロキシサーバ１２０は、放送波、ネットワークを介してデータ取得処理を実行することになる。

　　［８．受信装置にユーザ情報対応の選択コンテンツを出力するためのピリオド情報ファイルの提供と利用処理の具体的実施例について］
　次に、受信装置にユーザ情報対応の選択コンテンツを出力するためのピリオド情報ファイルの提供と利用処理の具体的実施例について説明する。

　以下の複数の実施例について、順次、説明する。
　（実施例１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例
　（実施例２）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬ（またはクエリパラメータ）とのマッピングテーブルを受信装置に提供する実施例
　（実施例３）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例
　（実施例４）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する実施例
　（実施例５）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する実施例
　（実施例６）質問回答形式メタデータ（ＰＤＩ）を利用した実施例
　（実施例６－１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例
　（実施例６－２）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する構成において、ＰＤＩテーブルを利用した実施例
　（実施例６－３）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する構成において、ＰＤＩテーブルを利用した実施例
　（実施例６－４）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する構成において、ＰＤＩテーブルを利用した実施例
　以下、各実施例の詳細について、順次、説明する。

　　［８－１．（実施例１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例］
　まず、実施例１として、ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例について説明する。

　クエリパラメータは、所定のクエリ（質問）に対する回答となるパラメータである。
　クエリ（質問）は、例えば、
　ａｇｅ（年齢）は？、
　Ｌｏｃａｔｉｏｎ（居住地）は？、
　これらのユーザ情報に関する質問である。
　クエリパラメータは、この回答であり、
　ａｇｅ＝３５
　Ｌｏｃａｔｉｏｎ＝ＬＡ
　これらのパラメータである。

　クエリパラメータ付きＵＲＬとは、図１１や図１３等を参照して説明したＭＰＤ中の広告対応ピリオド情報ファイルのユーザ情報設定フィールドに所定のユーザ情報（クエリパラメータ）を予め記録したユーザ情報（クエリパラメータ）設定済みのＵＲＬである。
　クエリパラメータ付きＵＲＬは、設定されたクエリパラメータ（ユーザ情報）によって決定される１つのピリオド情報ファイルのアクセス情報（ＵＲＬ）として利用可能となる。

　クエリパラメータとは、たとえば、以下のようなパラメータ（ユーザ情報）となる。
　（１）ａｇｅ＝１０－１９
　（２）ａｇｅ＝１０－１９，Ｌｏｃａｔｉｏｎ＝ＬＡ
　（３）ａｇｅ＝２０－５０，
　　　　・・・
　先に図１１、図１３等を参照して説明したＭＰＤのピリオド情報ファイルのユーザ情報設定フィールドには、様々なクエリパラメータ（ユーザ情報）が設定可能である。

　送信装置は、予め様々なユーザ情報に応じて準備された複数の広告に対応する複数のピリオド情報ファイルのアクセス情報として、複数のクエリパラメータ付きＵＲＬを用意し、これらの複数のクエリパラメータ付きＵＲＬをシグナリングデータとして受信装置に提供する。
　図１８に示すシグナリングデータ＃１は、受信装置に提供する複数のクエリパラメータ付きＵＲＬ中、１つのクエリパラメータ（ａｇｅ＝１０，Ｌｏｃａｔｉｏｎ＝ＬＡ）を設定したＵＲＬを含む１つのシグナリングデータである。
　送信装置２０は、この図１８に示すシグナリングデータ＃１の他、多数の異なるクエリパラメータ（ユーザ情報）を設定した多数のＵＲＬをシグナリングデータとしてマルチキャスト送信する。

　本実施例１では、ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬをＲＯＵＴＥプロトコルに従ったメタデータであるシグナリングデータに格納して、受信装置３０に提供する。

　本実施例１では、シグナリングデータとしてＳ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）を用いる。
　Ｓ－ＴＳＩＤのコンテンツロケーション（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）要素、あるいは、ヘッダにクエリパラメータ付きＵＲＬを格納して受信装置に提供する。

　さらに、送信装置２０は、クエリパラメータ（ユーザ情報）対応の広告データを格納した広告セグメント（ＡｄＳｅｇｍｅｎｔ）のアクセス情報（セグメントＵＲＬ）等の記述を含むピリオド情報ファイル（Ｐｅｒｉｏｄファイル）についても、ＲＯＵＴＥプロトコルで受信装置（クライアント）にマルチキャスト（放送）配信する。
　送信装置は、ユーザの年齢や住所に応じた様々な広告コンテンツ各々に対応した多数のピリオド情報ファイルを送信する。

　多数の異なるクエリパラメータ付きＵＲＬを記録したシグナリングデータ（Ｓ－ＴＳＩＤ）と、ピリオド情報ファイルの送信処理例として、以下、ＲＯＵＴＥプロトコルに規定される以下のデータ転送モード、すなわち、
　（ａ）ファイルモード、
　（ｂ）エンティティモード
　これら２種類のデータ転送モードを利用した場合の処理例について説明する。

　ファイルモードは、ファイル単位のデータ転送処理を実行するモードである。エンティティモードは、複数のファイルを含むエンティティ単位のデータ転送を許容したモードである。

　まず、ファイルモードを利用して、多数の異なるクエリパラメータ付きＵＲＬを記録したシグナリングデータ（Ｓ－ＴＳＩＤ）と、多数のピリオド情報ファイルを受信装置に提供する処理例について図１８以下を参照して説明する。

　図１８には、送信装置２０、受信装置３０を示している。
　送信装置２０は、シグナリングデータ４０１、およびピリオド情報ファイル４０２をＲＯＵＴＥプロトコルのファイルモードに従ってマルチキャスト送信する。
　受信装置３０は、通信部を有するミドルウェア１１０によって、これらのデータを受信し、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１にこれらのデータを格納する。

　シグナリングデータ４０１は、ユーザ情報設定フィールドにクエリパラメータを記録したＵＲＬを含むデータである。
　ピリオド情報ファイル４０２は、ユーザの年齢や住所に応じた様々な広告コンテンツのアクセス情報（広告セグメントファイルＵＲＬ）等を含むピリオド情報ファイルである。

　シグナリングデータ４０１は、例えばＲＯＵＴＥプロトコルにおいて規定されたＳ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）が利用される。Ｓ－ＴＳＩＤの１つのデータ要素であるコンテンツロケーション（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）要素にユーザ情報（クエリパラメータ）を記録したＵＲＬを記録して送信する。
　図１８に示すように、シグナリングデータ４０１であるＳ－ＴＳＩＤの、
　Ｓ－ＴＳＩＤ／ＲＳ／ＬＳ／ＳｒｃＦｌｏｗ／ＥＦＤＴ／Ｆｉｌｅ／ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ要素に、ピリオド情報ファイルのアクセス情報（ＵＲＬ）となる特定のクエリパラメータ（ユーザ情報）を設定したＵＲＬを１つ格納して受信装置３０にマルチキャスト（放送）配信する。

　受信装置３０の再生制御部１３１は、例えば図１１、図１３を参照して説明したＭＰＤ中の広告対応ピリオド情報中のユーザ情報設定フィールド（クエリパラメータ）にユーザ情報、例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　これらのユーザ情報（パラメータ）を設定してＵＲＬを完成させ、プロキシサーバ１２０のリンク解決部１２２に出力する。

　リンク解決部１２２は、再生制御部１３１から入力したＵＲＬと、シグナリングデータ１４０に記録されたクエリパラメータ（ユーザ情報）設定済みＵＲＬを比較する。再生制御部１３１から入力したＵＲＬと一致するクエリパラメータ（ユーザ情報）設定済みＵＲＬを記録したシグナリングデータ（Ｓ－ＴＳＩＤ）を選択し、選択したシグナリングデータ（Ｓ－ＴＳＩＤ）に記録されたクエリパラメータ（ユーザ情報）設定済みＵＲＬに基づいて１つのピリオド情報ファイルを取得して、再生制御部１３１に出力する。

　例えば、図１８に示すシグナリングデータ＃１に基づいて、図１８に示すピリオド情報ファイル＃１が選択されて再生制御部１３１に提供される。
　図１８に示すピリオド情報ファイル＃１は、図１８に示すシグナリングデータ＃１に記録されたクエリパラメータとしてのユーザ情報、すなわち、
　ａｇｅ＝１０－１９
　Ｌｏｃａｔｉｏｎ　＝ＬＡ
　これらのユーザ情報によって限定されるＬＡ在住の１０～１９歳のユーザに最適な広告コンテンツのアクセス情報を記録したピリオド情報ファイルとなる。

　図１８に示すシグナリングデータと、ピリオド情報ファイルは、１対１で対応づけられていることが必要である。
　この対応関係について図１９を参照して説明する。
　図１９に示すように、ピリオド情報ファイルは、複数のＬＣＴパケットに分割して格納されている。

　各ＬＣＴパケットのパケットヘッダには、ペイロードのデータを識別可能とした識別子であるＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）が記録される。

　一方、クエリパラメータ（ユーザ情報）設定済みＵＲＬを記録したシグナリングデータ（Ｓ－ＴＳＩＤ）には、ＴＯＩ記録フィールド（＜ＴＯＩ＞・・・＜／ＴＯＩ＞）が設けられている。
　図に示す例では、
　＜ＴＯＩ＞１２３４＜／ＴＯＩ＞
　の設定となっている。

　受信装置３０のプロキシサーバ１２０のリンク解決部１２２は、このクエリパラメータ（ユーザ情報）設定済みＵＲＬを記録したシグナリングデータ（Ｓ－ＴＳＩＤ）には、ＴＯＩ記録フィールド（＜ＴＯＩ＞・・・＜／ＴＯＩ＞）のデータ（本例ては１２３４）を取得する。
　この取得したＴＯＩ値＝１２３４をヘッダに設定したＬＣＴパケットを選択して１つのピリオド情報ファイルを格納したＬＣＴパケット群を選択することができる。

　次に、複数ファイルをまとめて送信可能としたエンティティモードを利用して、多数の異なるクエリパラメータ付きＵＲＬと、多数のピリオド情報ファイルを受信装置に提供する処理例について図２０を参照して説明する。

　図２０には、先に説明した図１８と同様、送信装置２０、受信装置３０を示している。
　送信装置２０は、ヘッダ情報（ＨＴＴＰ－Ｅｎｔｉｔｙ　Ｈｅａｄｅｒ）４０３とピリオド情報ファイル４０４からなるエンティティをＲＯＵＴＥプロトコルのエンティティモードに従ってマルチキャスト送信する。
　受信装置３０は、通信部を有するミドルウェアム１１０によって、データを受信し、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１にこれらのデータを格納する。

　エンティティモードの場合は、ファイルの先頭に付加するヘッダ情報（ＨＴＴＰエンティティヘッダ）４０３内のコンテンツロケーション（Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）記録位置に特定のクエリパラメータ（ユーザ情報）を設定したＵＲＬを１つ格納する。

　さらに、この特定のクエリパラメータ（ユーザ情報）を設定したＵＲＬに従ってアクセスされるピリオド情報ファイル４０４をヘッダ情報４０３に続けて設定して、１つのエンティティを生成して受信装置３０にマルチキャスト（放送）配信する。

　図２０に示すエンティティ＃１は、受信装置に提供する複数のエンティティの１つである。１つのクエリパラメータ（ａｇｅ＝１０，Ｌｏｃａｔｉｏｎ＝ＬＡ）を設定したＵＲＬと、このＵＲＬによってアクセスされるピリオド情報を含む１つのエンティティである。。

　送信装置２０は、この図２０に示すエンティティ＃１の他、多数の異なるクエリパラメータ（ユーザ情報）を設定したＵＲＬと、そのＵＲＬによってアクセスされるピリオド情報の組み合わせからなる多数のエンティティをマルチキャスト送信する。

　この図２０に示す例では、クエリパラメータ（ユーザ情報）を設定したＵＲＬと、そのＵＲＬによってアクセスされるピリオド情報が１つのエンティティとして一体化されている。

　受信装置の再生制御部１３１は、例えば図１１、図１３を参照して説明したＭＰＤ中の広告対応ピリオド情報中のユーザ情報設定フィールド（クエリパラメータ）にユーザ情報、例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　これらのユーザ情報（パラメータ）を設定してＵＲＬを完成させ、プロキシサーバ１２０のリンク解決部１２２に出力する。

　リンク解決部１２２は、再生制御部１３１から入力したＵＲＬと、エンティティに記録されたクエリパラメータ（ユーザ情報）設定済みＵＲＬを比較する。再生制御部１３１から入力したＵＲＬと一致するクエリパラメータ（ユーザ情報）設定済みＵＲＬを記録したエンティティを選択し、選択したエンティティに併せて記録された１つのピリオド情報ファイルを取得して、再生制御部１３１に出力する。

　次に、図２１に示すシーケンス図を参照して、本実施例１、すなわち、ピリオド情報ファイルのアクセス情報（ＵＲＬ）となるクエリパラメータ付きＵＲＬを受信装置に提供する実施例の処理シーケンスについて説明する。
　図２１には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバ、
　（ｅ）受信装置の構成要素である再生制御部、
　以下、図２１に示す各ステップの処理について、順次、説明する。

　　（ステップＳ１０１）
　ステップＳ１０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　なお、広告サーバが送信する広告には、様々なユーザに対応した異なる広告コンテンツが含まれる。すなわち、様々な年齢や居住地の様々な異なるユーザに提供するためのユーザに応じた様々な広告コンテンツを格納した広告セグメントファイルを送信する。なお、この広告セグメントファイルの送信処理は、継続的に繰り返し実行する設定としてよい。

　　（ステップＳ１０２）
　広告サーバは、ステップＳ１０２において、ステップＳ１０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成して送信する。

　広告サーバの生成、送信するピリオド情報ファイルは、ステップＳ１０１において生成、送信した広告セグメントの種類に相当する数の異なるピリオド情報ファイルである。
　複数の異なるピリオド情報ファイルが、放送波、あるいはネットワークを介してマルチキャスト送信される。
　なお、このピリオド情報ファイルも継続的に繰り返し送信する設定としてよい。

　　（ステップＳ１０３）
　広告サーバは、さらに、ステップＳ１０３において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録される。
　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ１０４）
　ステップＳ１０４は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　ＭＰＤは、先に図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録されている。

　　（ステップＳ１０５）
　受信装置の再生制御部は、ステップＳ１０５において、ステップＳ１０４で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　このようなユーザ情報を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　受信装置の再生制御部は、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）をプロキシサーバに出力し、リンク情報（Ｘｌｉｎｋ）の解析（リンク解決）を要求する。
　この要求処理は、例えば、ＨＴＴＰ－ＧＥＴリクエストとして実行される。

　　（ステップＳ１０６）
　受信装置のプロキシサーバは、ステップＳ１０６において、再生制御部からのリンク解決要求に応じた処理を実行する。
　すなわち、プロキシサーバのリンク解決部が、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）に基づいてアクセスされるピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）から取得して、再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ１０５において、再生制御部が設定したユーザ情報（パラメータ）に応じて選択されるピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ１０７）
　最後に、受信装置の再生制御部は、ステップＳ１０７において、プロキシサーバから取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　なお、広告コンテンツの復号態様や、出力時間等の制御情報は、ピリオド情報ファイルに記録されており、再生制御部は、ピリオド情報ファイルに記録された情報に従った処理を実行して広告コンテンツの出力処理を実行する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ１０５において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－２．（実施例２）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬ（またはクエリパラメータ）とのマッピングテーブルを受信装置に提供する実施例］
　次に、実施例２として、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬ（またはクエリパラメータ）とのマッピングテーブル（対応表）を受信装置に提供する実施例について説明する。

　ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）の一例を図２２に示す。
　図２２には、
　以下の２つのピリオド情報ファイルのアクセス情報（ＵＲＬ）、すなわち、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　これらを示している。
　さらに、これら２つのピリオド情報ファイルのアクセス情報（ＵＲＬ－１，ＵＲＬ－２）の各々に対応付けられたクエリパラメータ付きＵＲＬを示している。

　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に対応付けられたクエリパラメータ付きＵＲＬは、以下の２つのＵＲＬである。
　（ａ１）ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ｃｈｉｌｄ＆Ｌｏｃａｔｉｏｎ＝ＣＡ
　（ａ２）ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ｃｈｉｌｄ＆Ｌｏｃａｔｉｏｎ＝ＮＹ

　（ａ１）は、ユーザ情報として以下のパラメータが設定されている。
　ａｇｅ＝ｃｈｉｌｄ
　Ｌｏｃａｔｉｏｎ＝ＣＡ
　また、（ａ２）は、ユーザ情報として以下のパラメータが設定されている。
　ａｇｅ＝ｃｈｉｌｄ
　Ｌｏｃａｔｉｏｎ＝ＮＹ

　すなわち、ユーザ情報として、
　カリフォルニア（ＣＡ）在住の子供（ｃｈｉｌｄ）、
　ニューヨーク（ＮＹ）在住の子供（ｃｈｉｌｄ）、
　これらのいずれかが設定された場合、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。
　この広告は、カリフォルニア（ＣＡ）在住の子供（ｃｈｉｌｄ）と、ニューヨーク（ＮＹ）在住の子供（ｃｈｉｌｄ）を主なターゲットとした子供向けの広告となる。

　また、（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－２）に対応付けられたクエリパラメータ付きＵＲＬは、以下の３つのＵＲＬである。
　（ｂ１）ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆Ｌｏｃａｔｉｏｎ＝ＭＡ
　（ｂ２）ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆Ｌｏｃａｔｉｏｎ＝ＭＳ
　（ｂ３）ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆Ｌｏｃａｔｉｏｎ＝ＭＤ

　（ｂ１）は、ユーザ情報として以下のパラメータが設定されている。
　ａｇｅ＝ａｄｕｌｔ
　Ｌｏｃａｔｉｏｎ＝ＭＡ
　また、（ｂ２）は、ユーザ情報として以下のパラメータが設定されている。
　ａｇｅ＝ａｄｕｌｔ
　Ｌｏｃａｔｉｏｎ＝ＭＳ
　また、（ｂ３）は、ユーザ情報として以下のパラメータが設定されている。
　ａｇｅ＝ａｄｕｌｔ
　Ｌｏｃａｔｉｏｎ＝ＭＤ

　すなわち、ユーザ情報として、
　マサチューセッツ（ＭＡ）在住の大人（ａｄｕｌｔ）、
　ミシシッピ（ＭＳ）在住の大人（ａｄｕｌｔ）、
　メリーランド（ＭＤ）在住の大人（ａｄｕｌｔ）、
　これらのいずれかが設定された場合、
　（Ｂ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－２）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。
　この広告は、マサチューセッツ（ＭＡ）、ミシシッピ（ＭＳ）、メリーランド（ＭＤ）在住の大人（ａｄｕｌｔ）を主なターゲットとした大人向けの広告となる。

　なお、送信装置２０から、受信装置３０に提供されるマッピングテーブルは、実際には、例えば図２３に示すＸＭＬデータとして送信される。すなわち、例えば、以下に示すＸＭＬデータ［ピリオド解決テーブル（ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ）］が、送信装置２０から受信装置３０に提供される。

＜ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ＞　
　＜ＰｅｒｉｏｄＴｏＸＬｉｎｋ　ｉｄ＝１＞
　　＜ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ＜／ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞
　　＜ＸＬｉｎｋＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ｃｈｉｌｄ＆ｌｏｃａｔｉｏｎ＝ＣＡ＜／ＸＬｉｎｋＵＲＬ＞
　　＜ＸＬｉｎｋＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ｃｈｉｌｄ＆ｌｏｃａｔｉｏｎ＝ＮＹ＜／ＸＬｉｎｋＵＲＬ＞
　＜／ＰｅｒｉｏｄＴｏＸＬｉｎｋ＞
　＜ＰｅｒｉｏｄＴｏＸＬｉｎｋ　ｉｄ＝２＞
　　＜ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ＜／ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞
　　＜ＸＬｉｎｋＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆ｌｏｃａｔｉｏｎ＝ＭＡ＜／ＸＬｉｎｋＵＲＬ＞
　　＜ＸＬｉｎｋＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆ｌｏｃａｔｉｏｎ＝ＭＳ＜／ＸＬｉｎｋＵＲＬ＞
　　＜ＸＬｉｎｋＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｘｌｉｎｋＲｅｓｏｌｖｅｒ？ａｇｅ＝ａｄｕｌｔ＆ｌｏｃａｔｉｏｎ＝ＭＤ＜／ＸＬｉｎｋＵＲＬ＞
　＜／ＰｅｒｉｏｄＴｏＸＬｉｎｋ＞
＜／ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ＞

　上記のＸＭＬデータは、図２２に示すマッピングテーブル（対応表）の内容を記述したデータとして送信される。このＸＭＬデータは、サービスレイヤ・シグナリングデータ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）として、他の制御情報を記述したＸＭＬデータと同様、受信装置（クライアント）側に送信され、受信装置側で、更新・管理される。
　なお、マッピングテーブルには、バージョン識別子が設定され、更新された場合、バージョン識別子が変更され、受信装置は、更新されたことを検出した場合、キャッシュ部に格納されたマッピングテーブルを新しいデータに置き換えるデータ更新処理を実行する。

　図２２は、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブル（対応表）であるが、、クエリパラメータ付きＵＲＬを用いず、ユーザ情報となるパラメータのみを用いたマッピングテーブルを利用した構成も可能である。
　すなわち、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータとのマッピングテーブル（対応表）を利用する構成である。

　ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータとのマッピングテーブル（対応表）の一例を図２４に示す。
　図２４には、
　以下の２つのピリオド情報ファイルのアクセス情報（ＵＲＬ）、すなわち、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　これらを示している。
　さらに、これら２つのピリオド情報ファイルのアクセス情報（ＵＲＬ－１，ＵＲＬ－２）の各々に対応付けられたクエリパラメータを示している。

　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に対応付けられたクエリパラメータは、以下の２つのパラメータである。
　（ａ１）ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆに指定されるパラメータ（例ｇｒｏｕｐＩｄ等）の値その１（例：　ｇｒｏｕｐＩｄ＝１２３）
　（ａ２）ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆに指定されるパラメータ（例ｇｒｏｕｐＩｄ等）の値その２（例：　ｇｒｏｕｐＩｄ＝４５６）

　（ａ１）は、ユーザ情報として以下のパラメータが設定されている。
　ｇｒｏｕｐＩｄ＝１２３
　また、（ａ２）は、ユーザ情報として以下のパラメータが設定されている。
　ｇｒｏｕｐＩｄ＝４５６

　すなわち、ユーザ情報として、
　ｇｒｏｕｐＩｄ＝１２３、または４５６
　これらのいずれかが設定された場合、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。
　この広告は、予め何らかの基準に従って規定されたユーザグループ１２３，４５６を主なターゲットとした広告となる。

　また、（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－２）に対応付けられたクエリパラメータは、以下の３つのパラメータである。
　（ｂ１）ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆに指定されるパラメータ（例ｇｒｏｕｐＩｄ等）の値その３（例：　ｇｒｏｕｐＩｄ＝７８９）
　（ｂ２）ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆに指定されるパラメータ（例ｇｒｏｕｐＩｄ等）の値その４（例：　ｇｒｏｕｐＩｄ＝１３５）
　（ｂ３）ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆに指定されるパラメータ（例ｇｒｏｕｐＩｄ等）の値その５（例：　ｇｒｏｕｐＩｄ＝２４６）

　すなわち、ユーザ情報として、
　ｇｒｏｕｐＩｄ＝７８９、または１３５、または２４６
　これらのいずれかが設定された場合、
　（Ｂ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。
　この広告は、予め何らかの基準に従って規定されたユーザグループ７８９，１３５，２４６を主なターゲットとした広告となる。

　なお、送信装置２０から、受信装置３０に提供されるマッピングテーブルは、実際には、例えば図２５に示すＸＭＬデータとして送信される。すなわち、例えば、以下に示すＸＭＬデータ［ピリオド解決テーブル（ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ）］が、送信装置２０から受信装置３０に提供される。

＜ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ＞　
　　＜ＰｅｒｉｏｄＴｏＸＬｉｎｋ　ｉｄ＝１＞　
　　　＜ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ＜／ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞　
　　　＜ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　ｇｒｏｕｐＩｄ＝'１２３'　＜／ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　
　　　＜ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　ｇｒｏｕｐＩｄ＝'４５６'＜／ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞
　＜／ＰｅｒｉｏｄＴｏＸＬｉｎｋ＞
　＜ＰｅｒｉｏｄＴｏＸＬｉｎｋ　ｉｄ＝２＞
　　　　＜ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ＜／ＰｅｒｉｏｄＦｉｌｅＵＲＬ＞
　　　　＜ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　ｇｒｏｕｐＩｄ＝'７８９'＜／ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞
　　　　＜ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　ｇｒｏｕｐＩｄ＝'１３５'＜／ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞
　　　　＜ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞　ｇｒｏｕｐＩｄ＝'２４６'　＜／ＰａｒａｍｅｔｅｒＮａｍｅＶａｌｕｅＰａｉｒ＞
　＜／ＰｅｒｉｏｄＴｏＸＬｉｎｋ＞
＜／ＰｅｒｉｏｄＲｅｓｏｌｖｉｎｇＴａｂｌｅ＞　

　上記のＸＭＬデータは、図２４に示すマッピングテーブル（対応表）の内容を記述したデータとして送信される。このＸＭＬデータは、サービスレイヤ・シグナリングデータ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）として、他の制御情報を記述したＸＭＬデータと同様、受信装置（クライアント）側に送信され、受信装置側で、更新・管理される。
　なお、マッピングテーブルには、バージョン識別子が設定され、更新された場合、バージョン識別子が変更され、受信装置は、更新されたことを検出した場合、キャッシュ部に格納されたマッピングテーブルを新しいデータに置き換えるデータ更新処理を実行する。

　次に、図２６、図２７以下に示すシーケンス図を参照して、本実施例２、すなわち、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、クエリパラメータ付きＵＲＬとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する。
　図２６～図２７には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるプロキシサーバのリンク解決部（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）、
　（ｆ）受信装置の構成要素である再生制御部、
　以下、図２６～図２７に示す各ステップの処理について、順次、説明する。

　　（ステップＳ２０１）
　ステップＳ２０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ２０２）
　広告サーバは、ステップＳ２０２において、ステップＳ２０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成して送信する。

　広告サーバの生成、送信するピリオド情報ファイルは、ステップＳ２０１において生成、送信した広告セグメントの種類に相当する数の異なるピリオド情報ファイルである。
　複数の異なるピリオド情報ファイルが、放送波、あるいはネットワークを介してマルチキャスト送信される。
　なお、このピリオド情報ファイルも継続的に繰り返し送信する設定としてよい。

　　（ステップＳ２０３）
　広告サーバは、さらに、ステップＳ２０３において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録される。
　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ２０４）
　ステップＳ２０４は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ２０５）
　受信装置の再生制御部は、ステップＳ２０５において、ステップＳ２０４で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　このようなユーザ情報を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　受信装置の再生制御部は、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）、またはユーザ情報（パラメータ）をプロキシサーバに出力し、リンク情報（Ｘｌｉｎｋ）の解析（リンク解決）を要求する。
　この要求処理は、例えば、ＨＴＴＰ－ＧＥＴリクエストとして実行される。

　　（ステップＳ２０６）
　ステップＳ２０６の処理は、広告サーバの処理である。
　広告サーバは、ピリオド情報ファイルと、クエリパラメータ付きＵＲＬ対応表（マッピングテーブル）、または、ピリオド情報ファイルと、クエリパラメータ対応表（マッピングテーブル）を生成して送信する。
　図２２、図２４を参照して説明したマッピングテーブルである。ただし、実際の送信データは、例えば図２３、図２５を参照して説明したＸＭＬデータである。
　このマッピングテーブルは、随時、定期的に送信、また更新して送信することが可能である。マッピングテーブルにはバージョン識別子が設定され、受信装置は、バージョン管理によって随時、更新データをキャッシュする処理を行なう。

　　（ステップＳ２０７～Ｓ２０９）
　受信装置のプロキシサーバは、ステップＳ２０７～Ｓ２０９において、再生制御部からのリンク解決要求（Ｓ２０５）に応じた処理を実行する。
　すなわち、プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）が、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）に基づいてアクセスされるピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）から取得して、再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）は、ステップＳ２０６において広告サーバから受信したマッピングテーブルを利用して１つのピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）から選択取得して、再生制御部に出力する。

　プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）は、まず、受信装置の再生制御部から入力したＵＲＬ、すなわち、ＭＰＤの広告対応ピリオド情報のユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）、またはユーザ情報（パラメータ）と一致するＵＲＬまたはパラメータをマッピングテーブルから抽出する。

　次に、マッピングテーブルにおいて、一致したクエリパラメータ付きＵＲＬ、またはパラメータと対応付けられたピリオド情報ファイルのＵＲＬを選択し、このＵＲＬを適用して１つのピリオド情報ファイルを取得し、これを再生制御部に出力する。

　このピリオド情報ファイルは、ステップＳ２０５において、再生制御部が設定したユーザ情報（パラメータ）に応じて選択されるピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ２１０）
　最後に、受信装置の再生制御部は、ステップＳ２１０において、プロキシサーバから取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ２０５において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－３．（実施例３）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例］
　次に、実施例３として、クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例について説明する。

　本実施例３は、受信装置３０が、送信装置２０から受信したスクリプト（プログラム）を利用して、再生制御部の生成したクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する実施例である。

　図２８、図２９以下に示すシーケンス図を参照して、本実施例３、すなわち、クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する。
　図２８～図２９には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるプログラム（スクリプト）実行部
　（ｆ）受信装置の構成要素である再生制御部、

　なお、「（ｅ）受信装置の構成要素であるプログラム（スクリプト）実行部」は、受信装置内のプロキシサーバ１２０内に構成してもよいし、再生制御部１３１内に構成としてもよい、あるいは独立したデータ処理部として設定してもよい。
　以下、図２８～図２９に示す各ステップの処理について、順次、説明する。

　　（ステップＳ３０１）
　ステップＳ３０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ３０２）
　広告サーバは、ステップＳ３０２において、データ処理プログラムであるスクリプトファイルを生成して受信装置に送信する。
　このスクリプトは、受信装置の再生制御部がＭＰＤを利用して生成するクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプトである。
　すなわち、リンク解決（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）処理を実行して、ピリオド情報ファイルを生成するスクリプトである。

　このスクリプトは、ステップＳ３０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成する処理を実行する。

　　（ステップＳ３０３）
　広告サーバは、さらに、ステップＳ３０３において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録される。
　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ３０４）
　ステップＳ３０４は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ３０５）
　受信装置の再生制御部は、ステップＳ３０５において、ステップＳ３０４で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　このようなユーザ情報を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　受信装置の再生制御部は、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬ（ピリオド情報ファイルアクセス情報）をプログラム（スクリプト）実行部に出力し、リンク情報（Ｘｌｉｎｋ）の解析（リンク解決）を要求する。
　この要求処理は、例えば、ＨＴＴＰ－ＧＥＴリクエストとして実行される。

　　（ステップＳ３０６～Ｓ３０７）
　ステップＳ３０６～Ｓ３０７の処理は、受信装置のプログラム（スクリプト）実行部の処理である。

　ステップＳ３０６において、ステップＳ３０２で広告サーバから受信したスクリプトを起動する。
　すなわち、クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプトを起動する。
　さらに、ステップＳ３０７においてスクリプトを実行し、クエリパラメータ付きＵＲＬ、すなわちステップＳ３０５において再生制御部から入力したユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬを解析して、このＵＲＬに対応するピリオド情報ファイルを生成して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ３０５において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ３０８）
　最後に、受信装置の再生制御部は、ステップＳ３０８において、プログラム（スクリプト）実行部から取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ３０５において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－４．（実施例４）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する実施例］
　次に、実施例４として、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する実施例について説明する。

　まず、サービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ　Ｗｏｒｋｅｒ）の概要について、図３０～図３２を参照して説明する。
　サービスワーカー（ＳＷ）は、放送サーバや、広告サーバ等の送信装置２０から受信装置３０に提供される。

　サービスワーカー（ＳＷ）は、受信装置（クライアント）３０において実行されるアプリケーション（＝アプリケーションプログラム）や、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。具体的には、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって構成される。

　サービスワーカー（ＳＷ）は、例えば送信装置２０が提供する放送番組（放送コンテンツ）に対応して設定され、送信装置２０から受信装置３０に提供されるアプリケーションの制御および管理プログラムとして、受信装置３０に提供される。

　サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイル、これらは、例えば先に図２、図３を参照して説明したＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、送信装置２０から受信装置３０に提供される。
　あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置３０に提供する構成としてもよい。

　サービスワーカー（ＳＷ）は、例えば、受信装置３０においてＷｅｂページ等の閲覧処理を実行するために利用されるプログラムであるブラウザを利用して情報表示を実行するアプリケーション等の管理（取得、保持、更新、削除等）処理などを実行する。

　サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について、図３０、図３１を参照して説明する。
　図３０は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。

　放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイルを受信装置３０に提供する。
　以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
　放送サーバ２１は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー（ＳＷ）を、やはりＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として受信装置３０に提供する。

　受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションおよびデータファイルを利用して、図３０に示すように、番組表示に併せて、天気情報の表示を行うことができる。
　このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。

　これは、天気情報表示アプリケーション等のリソースは、番組受信中は、受信装置３０において利用可能な設定、例えば、一時記憶キャッシュに格納され、利用可能な状態に設定されるが、番組終了、あるいはユーザがチャンネルを切り替えると、これらのキャッシュデータが消去、あるいはアクセス不可能な状態に設定されてしまうためである。

　サービスワーカー（ＳＷ）は、このような番組対応のアプリケーションやデータを、番組終了後や、チャンネル切り替え後、あるいは放送の非受信状態、ネットワーク非接続状態等のオフライン状態であっても利用可能とするためのリソース管理プログラムとして機能する。

　図３１に示すように、天気情報表示アプリケーションを、このアプリを提供した番組の終了後や、他のチャンネルに切り換え後、あるいはデータ受信を実行していないオフライン状態であっても、利用することが可能となる。すなわち天気情報を受信装置３０の表示部に表示して閲覧することが可能となる。
　なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。

　この天気情報表示アプリケーションは、サービスワーカー（ＳＷ）の制御によって、受信装置３０の記憶部（永続キャッシュ）に格納される。例えばユーザによる表示要求等のリクエスト（イベント）があると、サービスワーカー（ＳＷ）の制御によって、の記憶部（永続キャッシュ）から読み出され、表示部に表示される。
　なお、アプリケーション等のリソースを格納する記憶部（永続キャッシュ）は、受信装置３０の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
　このように、サービスワーカー（ＳＷ）を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。

　なお、サービスワーカー（ＳＷ）は、例えばある番組対応のリソース（アプリケーション、およびアプリ関連データ）単位ごとに設定され、リソースに併せて、あるいはリソース送信に前後して送信装置２０から受信装置３０に提供される。
　サービスワーカー（ＳＷ）は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー（ＳＷ）を設定することもできる。
　サービスワーカー（ＳＷ）と、サービスワーカー（ＳＷ）によって管理されるリソース（アプリケーションおよびアプリ関連データ）は、受信装置３０の記憶部（永続キャッシュ）に格納される。

　図３２は、サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。
　図３２には、受信装置３０が送信装置２０からリソースとしてのＷｅｂページ（例えば図３０、図３１に示す天気情報表示ページ）を取得して受信装置３０の記憶部（永続キャッシュ）に格納して利用するシーケンスの一例を示している。
　なお、Ｗｅｂページは、所定のＷｅｂページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
　図３２には、受信装置内のブラウザ４５０の構成要素として表示処理部４５１、サービスワーカー（ＳＷ）４５２、キャッシュ（記憶部）４５３を示している。

　ステップＳ３５１～Ｓ３５２は、受信装置３０による送信装置２０に対する初回アクセス処理によるリソース（Ｗｅｂページ）取得処理である。
　これは、例えば放送サーバ等の送信するＮＲＴコンテンツから取得される。
　この取得処理後、表示処理部４５１によって、Ｗｅｂページ４５５が、受信装置３０の表示部に表示される。この表示は、このＷｅｂページを提供している番組に併せて表示されている状態であり、先に図３を参照して説明した表示状態に相当する。

　この表示期間において、例えばユーザによる指示としてリソース（Ｗｅｂページ）の登録（インストール）要求がなされると、ステップＳ３５３において、サービスワーカー（ＳＷ）４５２が、リソース（Ｗｅｂページ）の登録（インストール）処理を開始する。
　具体的には、ステップＳ３５４に示すようにリソースをキャッシュ４５３に渡し、記憶部（永続キャッシュ）に格納する処理を行なう。

　その後、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態において、ステップＳ３５５において、ユーザがＷｅｂペーシの閲覧要求を行う。
　サービスワーカー（ＳＷ）４５２は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップＳ３５６において、リソース（Ｗｅｂページ）を記憶部（永続キャッシュ）から取得する。
　表示処理部４５１は、ステップＳ３５７において、Ｗｅｂページ４５６を表示する。

　このＷｅｂページ表示処理は、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態における表示処理であり、先に図３１を参照して説明した表示状態に相当する。

　このように、サービスワーカー（ＳＷ）を利用することで、様々なアプリケーション等のプログラムを、番組の表示、非表示と無関係に利用することが可能となり、例えば、番組付属の表示情報として設定されたＷｅｂページを番組と無関係に、任意のタイミングで表示する等の処理が可能となる。

　このように、サービスワーカー（ＳＷ）は、例えば、Ｗｅｂページ、ＨＴＭＬページ、ＪａｖａＳｃｒｉｐｔ（登録商標）等を構成要素としたアプリケーションやプログラム、アプリケーション等に利用されるデータ等からなるリソースの取得、保存、更新、削除等の、リソース管理を実行する。

　リソースの保存される記憶部（キャッシュ）は、格納データを永続的に保存する記憶部（キャッシュ）であり、通常のローカル／テンポラリなキャッシュとは異なり、アプリケーションが稼働していなくても、データが保存される。
　Ｗｅｂページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバをアクセスしてＷｅｂページを取得して表示可能としたイメージである。

　なお、サービスワーカー（ＳＷ）自身も永続キャッシュに格納（インストール）される。サービスワーカー（ＳＷ）が、受信装置にインストールされると、このサービスワーカー（ＳＷ）の管理対象とするリソースについて、様々な制御が可能となる。
　例えば、リソースへのアクセスリクエスト（リソースへのフェッチリクエスト）に応じて、ブラウザ側の処理（ローカルキャッシュやネットワークからのリソースの取得）がはじまる前に、サービスワーカー（ＳＷ）の処理が開始され、永続キャッシュからのリソースの提供が行われる。
　また、サービスワーカー（ＳＷ）は、ＪａｖａＳｃｉｒｐｔ（登録商標）で提供されるため、さまざまな手続きを組み込むことが可能であり、永続キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。

　なお、サービスワーカー（ＳＷ）自身も更新可能である。サービスワーカー（ＳＷ）は、送信装置２０から提供されるが、このサービスワーカー（ＳＷ）のヘッダ情報（ＨＴＴＰ　Ｃａｃｈｅ－Ｃｏｎｔｒｏｌ）に更新日時情報や更新データのアクセス情報等、更新処理に必要となる各種情報が記録され、このヘッダ情報に基づいて更新処理が実行される。
　例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置３０は、新しいバージョンのサービスワーカ（ＳＷ）の取得処理を実行して、キャッシュに格納された旧バージョンのＳＷを置き換える更新処理を行なう。

　受信装置３０は、サービスワーカー（ＳＷ）を利用して、任意のタイミングで、例えば図３０、図３１を参照して説明したような天気情報表示アプリケーション等のアプリケーションやプログラム、すなわちサービスワーカ（ＳＷ）の管理対象てあるアプリケーションやプログラムを実行することが可能となる。

　本実施例４は、このサービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例である。

　図３３、図３４以下に示すシーケンス図を参照して、本実施例４、すなわち、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する。
　図３３～図３４には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるブラウザキャッシュ
　（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部
　（ｇ）受信装置の構成要素である再生制御部、

　なお、上記構成中、（ｅ）受信装置の構成要素であるブラウザキャッシュと、（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部は、上述したサービスワーカー（ＳＷ）の管理キャッシュおよび実行部である。
　以下、図３３～図３４に示す各ステップの処理について、順次、説明する。

　　（ステップＳ４０１）
　ステップＳ４０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ４０２）
　広告サーバは、ステップＳ４０２において、ステップＳ４０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成して送信する。

　広告サーバの生成、送信するピリオド情報ファイルは、ステップＳ４０１において生成、送信した広告セグメントの種類に相当する数の異なるピリオド情報ファイルである。
　複数の異なるピリオド情報ファイルが、放送波、あるいはネットワークを介してマルチキャスト送信される。
　なお、このピリオド情報ファイルも継続的に繰り返し送信する設定としてよい。

　　（ステップＳ４０３）
　広告サーバは、ステップＳ４０３において、データ処理プログラムであるサービスワーカー（ＳＷ）スクリプトファイルを生成して受信装置に送信する。
　このサービスワーカー（ＳＷ）スクリプトファイルは、受信装置のプロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する処理を実行するスクリプトである。

　　（ステップＳ４０４～Ｓ４０６）
　ステップＳ４０４～Ｓ４０６の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ４０４において、ステップＳ４０２で広告サーバから受信したサービスワーカー（ＳＷ）スクリプトファイルを起動する。
　すなわち、受信装置のプロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する処理を実行するサービスワーカー（ＳＷ）スクリプトファイルを起動する。

　さらに、ステップＳ４０５～Ｓ４０６において、サービスワーカー（ＳＷ）スクリプトを実行し、プロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する。

　　（ステップＳ４０７）
　広告サーバは、ステップＳ４０７において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録される。
　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ４０８）
　ステップＳ４０８は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ４０９）
　受信装置の再生制御部は、ステップＳ４０９において、ステップＳ４０８で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　このようなユーザ情報を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　　（ステップＳ４１０）
　ステップＳ４１０の処理は、受信装置のブラウザキャッシュの処理である。
　ブラウザキャッシュは、再生制御部から入力したＨＴＴＰ－ＧＥＴリクエストに対する応答処理を実行する。
　具体的には、再生制御部から入力したユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬを解析して、このＵＲＬに対応するピリオド情報ファイルを取得して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ４０９において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ４１１）
　最後に、受信装置の再生制御部は、ステップＳ４１１において、ブラウザキャッシシュから取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ４０９において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－５．（実施例５）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する実施例］
　次に、実施例５として、クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する実施例について説明する。

　本実施例５は、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する処理を実行する実施例である。
　本実施例５は、受信装置３０が、送信装置２０から受信したサービスワーカー（ＳＷ）スクリプトを利用して、再生制御部の生成したクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する実施例である。

　図３５、図３６以下に示すシーケンス図を参照して、本実施例５、すなわち、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する。
　図３５～図３６には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるブラウザキャッシュ
　（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部
　（ｇ）受信装置の構成要素である再生制御部、

　なお、上記構成中、（ｅ）受信装置の構成要素であるブラウザキャッシュと、（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部は、上述したサービスワーカー（ＳＷ）の管理キャッシュおよび実行部である。
　以下、図３５～図３６に示す各ステップの処理について、順次、説明する。

　　（ステップＳ５０１）
　ステップＳ５０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ５０２）
　広告サーバは、ステップＳ５０２において、データ処理プログラムであるサービスワーカー（ＳＷ）スクリプトファイルを生成して受信装置に送信する。
　このサービスワーカー（ＳＷ）スクリプトファイルは、広告サーバが送信し、受信装置のプロキシキャッシュに格納された広告セグメントファイルを、ブラウザキャッシュから取り出してブラウザキャッシュに格納する処理を実行する。さらに、受信装置の再生制御部がＭＰＤを利用して生成するクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する。すなわち、リンク解決（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）処理を実行して、ピリオド情報ファイルを生成する。
　これらの処理を実行するサービスワーカー（ＳＷ）スクリプトである。

　このサービスワーカー（ＳＷ）スクリプトは、ステップＳ５０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成する処理を実行する。

　　（ステップＳ５０３～Ｓ５０４）
　ステップＳ５０３～Ｓ５０４の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ５０３において、ステップＳ５０２で広告サーバから受信したサービスワーカー（ＳＷ）スクリプトファイルを起動する。
　さらに、ステップＳ５０４において、サービスワーカー（ＳＷ）スクリプトを実行し、プロキシキャッシュに格納された広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する。

　　（ステップＳ５０５）
　広告サーバは、ステップＳ５０５において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図１１を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドが設けられた未完成のＵＲＬが記録される。
　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ５０６）
　ステップＳ５０６は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ５０７）
　受信装置の再生制御部は、ステップＳ５０７において、ステップＳ５０６で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　例えば、
　ａｇｅ＝１０－１９、
　Ｌｏｃａｔｉｏｎ＝ＬＡ、
　このようなユーザ情報を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　　（ステップＳ５０８）
　ステップＳ５０８の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ５０８において、サービスワーカー（ＳＷ）スクリプトを実行し、クエリパラメータ付きＵＲＬ、すなわちステップＳ５０７において再生制御部から入力したユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＵＲＬを解析して、このＵＲＬに対応するピリオド情報ファイルを生成して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ５０７において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ５０９）
　最後に、受信装置の再生制御部は、ステップＳ５０９において、プログラム（スクリプト）実行部から取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　　［８－６．（実施例６）質問回答形式メタデータ（ＰＤＩ）を利用した実施例］
　次に、実施例６として質問回答形式メタデータ（ＰＤＩ）を利用した実施例について説明する。
　ＰＤＩ（Ｐｒｅｆｅｒｅｎｃｅ　Ｄｅｍｏｇｒａｐｈｉｃ　Ｉｎｔｅｒｅｓｔ）は、放送波およびネットワークを介したデータ配信システムに関する規格であるＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）２．０規格において規定された質問回答（クエリアンサー）形式メタデータのフォーマットである。

　ＰＤＩは、受信装置（クライアント）に質問（クエリ）を行い、受信装置（クライアント）側のユーザの回答（アンサー）を取得する処理を可能としたメタデータである。
　受信装置（クライアント）に対する質問（クエリ）は、受信装置（クライアント）側のユーザの趣味嗜好（Ｐｒｅｆｅｒｅｎｃｅ）、ユーザ属性（Ｄｅｍｏｇｒａｐｈｉｃ）、ユーザの興味（Ｉｎｔｅｒｅｓｔ）を問い合わせる質問である。これらの質問に対する受信装置（クライアント）側のユーザの回答（アンサー）を取得する。

　例えばＰＤＩに基づいて、受信装置（クライアント）から取得した回答に基づいて受信装置（クライアント）に提供するコンテンツやデータを選択して提供するといった処理が可能となる。

　以下に説明する実施例６は、このＰＤＩを利用して受信装置（クライアント）に提供する広告を選択する実施例である。

　図３７は、本実施例６、すなわち質問回答形式メタデータ（ＰＤＩ）を利用してユーザ対応の広告を提供する実施例において利用されるＭＰＤの構成例を示す図である。
　図３７は、先に図５を参照して説明した放送番組と広告を交互に出力するコンテンツ出力処理に対応する制御情報記述データ（シグナリングデータ）であるＭＰＤの構成例を示している。

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

　図３８は、図３７に示すＭＰＤ中の１つのピリオド情報５１１の構成について説明する図である。
　ピリオド情報５１１は、時間ｔ０～ｔ１において受信装置で出力する広告に対応する制御情報であるピリオド情報である。

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

　このピリオド情報は、先に図１１、図１３を参照して説明したピリオド情報とほぼ同様の構成を有するが、リンク情報５２０中のユーザ情報設定フィールドの構成が異なっている。その他の構成は、先に図１１、図１３を参照して説明したピリオド情報と同様である。

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

　受信装置は、図１３に示す広告対応のピリオド情報３１１内のリンク情報（Ｘｌｉｎｋ）に含まれるアクセス情報（ＵＲＬ）内のユーザ情報設定フィールド（ｐｄｉ＝＄ｐｄｉ＄）にユーザ情報（パラメータ）を設定する。
　ユーザ情報（パラメータ）を設定したアクセス情報（ＵＲＬ）を用いてアクセス可能となるデータが、ユーザに対応する広告データ対応のピリオド情報ファイルである。

　本実施例では、このユーザ情報設定フィールド（ｐｄｉ＝＄ｐｄｉ＄）にユーザ情報（パラメータ）を設定する場合に、質問回答形式メタデータ（ＰＤＩ）を利用する。
　質問回答形式メタデータ（ＰＤＩ）を利用して、ユーザ情報設定フィールドに、所定のパラメータ、すなわちＰＤＩのクエリアンサー（質問回答）データを含むパラメータを設定することで、ユーザに対応する広告データ対応のピリオド情報ファイルのアクセス情報（ＵＲＬ）が生成される。

　以下、質問回答形式メタデータ（ＰＤＩ）を利用した実施例６について、以下の４つの具体的実施例について、順次、説明する。
　（実施例６－１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例
　（実施例６－２）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する構成において、ＰＤＩテーブルを利用した実施例
　（実施例６－３）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する構成において、ＰＤＩテーブルを利用した実施例
　（実施例６－４）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する構成において、ＰＤＩテーブルを利用した実施例

　　［８－６－１．（実施例６－１）ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例］
　実施例６－１として、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例について説明する。

　ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブル（対応表）の一例を図３９、図４０に示す。
　図３９～図４０は、マッピングテーブルの一部を示す図である。
　図３９、図４０には、
　以下の２つのピリオド情報ファイルのアクセス情報（ＵＲＬ）、すなわち、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　これらを示している。
　さらに、これら２つのピリオド情報ファイルのアクセス情報（ＵＲＬ－１，ＵＲＬ－２）の各々に対応付けられたＰＤＩインスタンス（＝ＰＤＩクエリアンサーパラメータ設定例）を示している。

　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に対応付けられたＰＤＩインスタンスは、以下の２つのＰＤＩインスタンスである。
　（ａ１）ＰＤＩインスタンス－その１
　＜ＰＤＩＴａｂｌｅ　…＞
　　＜ＱＩＡＴｙｐｅ　＠ｉｄ＝'１２３'　…　＞
　　　＜Ｑ　…　＞＜ＱＴｅｘｔ　…＞Ｈｏｗ　ｏｌｄ　ａｒｅ　ｙｏｕ？＜／ＱＴｅｘｔ＞＜／Ｑ＞
　　　＜Ａ　＠ａｎｓｗｅｒ＝'３５'　…　／＞
　　＜ＱＩＡＴｙｐｅ＞
　＜／ＰＤＩＴａｂｌｅ＞）

　（ａ２）ＰＤＩインスタンス－その２
　＜ＰＤＩＴａｂｌｅ　…＞
　　＜ＱＢＡＴｙｐｅ　＠ｉｄ＝'４５６'　…　＞
　　　＜Ｑ＞＜ＱＴｅｘｔ＞Ａｒｅ　ｙｏｕ　ｍａｌｅ？＜／ＱＴｅｘｔ＞＜／Ｑ＞
　　　＜Ａ　＠ａｎｓｗｅｒ＝'ｔｒｕｅ'／＞
　　＜ＱＢＡＴｙｐｅ＞
　＜／ＰＤＩＴａｂｌｅ＞）

　（ａ１）は、ＱＩＡ（Ｑｕｅｒｙ　ｆｏｒ　Ｉｎｔｅｇｅｒ　Ａｎｓｗｅｒ）タイプのＰＤＩの例である。ＱＩＡタイプは、回答（アンサー）として整数値（Ｉｎｔｅｇｅｒ）を要求する質問（クエリ）を有するＰＤＩである。
　質問（クエリ）＝Ｈｏｗ　ｏｌｄ　ａｒｅ　ｙｏｕ？（あなたは何歳ですか？）
　回答（アンサー）＝３５
　これらのクエリアンサー（質問回答）の設定されたＰＤＩインスタンスである。

　（ａ２）は、ＱＢＡ（Ｑｕｅｒｙ　ｆｏｒ　Ｂｏｏｌｅａｎ　Ａｎｓｗｅｒ）タイプのＰＤＩの例である。ＱＢＡタイプは、回答（アンサー）としてｔｒｕｅ，ｆａｌｓｅ等の論理値（Ｂｏｏｌｅａｎ　ｖａｌｕｅ）を要求する質問（クエリ）を有するＰＤＩである。
　質問（クエリ）＝Ａｒｅ　ｙｏｕ　ｍａｌｅ？（あなたは男性ですか？）
　回答（アンサー）＝ｔｒｕｅ
　これらのクエリアンサー（質問回答）の設定されたＰＤＩインスタンスである。

　すなわち、ユーザ情報として、
　３５歳、
　男性、
　これらのいずれかが回答として得られた場合、
　（Ａ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－１．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－１）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。
　この広告は、３５歳の人、あるいは男性を主なターゲットとした広告となる。

　なお、図３９に示す（ａ１），（ａ２）のＰＤＩインスタンスは、図３７、図３８を参照して説明したＭＰＤ中のユーザ情報設定フィールドに格納することで、ピリオド情報ファイルのＵＲＬとして設定される。

　また、図４０に示す（Ｂ）ＵＲＬ－２＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－２）に対応付けられたＰＤＩインスタンスは、図４０に示す（ｂ１）～（ｂ３）の３つである。

　（ｂ１）は、ＱＳＡ（Ｑｕｅｒｙ　ｆｏｒ　Ｓｅｌｅｃｔｉｏｎ　Ａｎｓｗｅｒ）タイプのＰＤＩの例である。ＱＳＡタイプは、回答（アンサー）として、予め規定された複数の回答候補からの選択を要求する質問（クエリ）を有するＰＤＩである。
　（ｂ２）は、ＱＴＡ（Ｑｕｅｒｙ　ｆｏｒ　Ｔｅｘｔ　Ａｎｓｗｅｒ）タイプのＰＤＩの例である。ＱＴＡタイプは、回答（アンサー）として、任意のテキストの入力を要求する質問（クエリ）を有するＰＤＩである。
　（ｂ３）は、ＱＢＡ（Ｑｕｅｒｙ　ｆｏｒ　Ｂｏｏｌｅａｎ　Ａｎｓｗｅｒ）タイプのＰＤＩの例である。ＱＢＡタイプは、回答（アンサー）としてｔｒｕｅ，ｆａｌｓｅ等の論理値（Ｂｏｏｌｅａｎ　ｖａｌｕｅ）を要求する質問（クエリ）を有するＰＤＩである。

　受信装置が、図４０（ｂ１）～（ｂ３）のいずれかに示すＰＤＩインスタンスに一致するユーザ情報（クエリパラメータ）を設定した場合、
　（Ｂ）ＵＲＬ－１＝ｈｔｔｐ：／／ａ．ｃｏｍ／ｐｅｒｉｏｄ－２．ｘｍｌ
　このピリオド情報ファイルアクセス情報（ＵＲＬ－２）に従って取得されるピリオド情報ファイルが選択され、選択されたピリオド情報ファイルに記録された広告コンテンツアクセス情報（広告セグメントＵＲＬ）によって取得されるコンテンツが受信装置に提供されて出力されることになる。

　なお、送信装置２０から受信装置３０に提供されるマッピングテーブルは、実際には、例えば図４１に示すＸＭＬデータとして送信される。なお、ＸＭＬデータは、サービスレイヤ・シグナリングデータ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）として、他の制御情報を記述したＸＭＬデータと同様、受信装置（クライアント）側に送信され、受信装置側で、更新・管理される。
　なお、マッピングテーブルには、バージョン識別子が設定され、更新された場合、バージョン識別子が変更され、受信装置は、更新されたことを検出した場合、キャッシュ部に格納されたマッピングテーブルを新しいデータに置き換えるデータ更新処理を実行する。

　次に、図４２、図４３以下に示すシーケンス図を参照して、本実施例６－１、すなわち、ピリオド情報ファイルのアクセス情報（ＵＲＬ）と、ＰＤＩインスタンスとのマッピングテーブルを受信装置に提供する実施例の処理シーケンスについて説明する。
　図４２～図４３には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるプロキシサーバのリンク解決部（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）、
　（ｆ）受信装置の構成要素である再生制御部、
　以下、図４２～図４３に示す各ステップの処理について、順次、説明する。

　　（ステップＳ６０１）
　ステップＳ６０１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ６０２）
　広告サーバは、ステップＳ６０２において、ステップＳ６０１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成して送信する。

　広告サーバの生成、送信するピリオド情報ファイルは、ステップＳ６０１において生成、送信した広告セグメントの種類に相当する数の異なるピリオド情報ファイルである。
　複数の異なるピリオド情報ファイルが、放送波、あるいはネットワークを介してマルチキャスト送信される。
　なお、このピリオド情報ファイルも継続的に繰り返し送信する設定としてよい。

　　（ステップＳ６０３）
　広告サーバは、さらに、ステップＳ６０３において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図３７、図３８を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ構成に従ってユーザ情報を設定するフィールドが設けられた未完成のＵＲＬが記録される。

　受信装置においてユーザ情報設定フィールドに所定のユーザ情報（パラメータ）を設定することで、特定の広告コンテンツのアクセス情報等を記録した１つのユーザ対応ピリオド情報ファイル取得用ＵＲＬを生成することができる。

　　（ステップＳ６０４）
　ステップＳ６０４は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ６０５）
　受信装置の再生制御部は、ステップＳ６０５において、ステップＳ６０４で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ユーザ情報設定フィールドを持つＵＲＬを取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　具体的には、図３９、図４０を参照して説明したＰＤＩインスタンスと同様、様々なタイプのＰＤＩのクエリに応じたアンサー（回答）をユーザ情報として設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　受信装置の再生制御部は、ＰＤＩ形式に従ったユーザ情報をプロキシサーバに出力し、リンク情報（Ｘｌｉｎｋ）の解析（リンク解決）を要求する。

　　（ステップＳ６０６）
　ステップＳ６０６の処理は、広告サーバの処理である。
　広告サーバは、ピリオド情報ファイルと、ＰＤＩインスタンス対応表（マッピングテーブル）を生成して送信する。
　図３９～図４０を参照して説明したマッピングテーブルである。ただし、実際の送信データは、例えば図４１を参照して説明したＸＭＬデータである。
　このマッピングテーブルは、随時、定期的に送信、また更新して送信することが可能である。マッピングテーブルにはバージョン識別子が設定され、受信装置は、バージョン管理によって随時、更新データをキャッシュする処理を行なう。

　　（ステップＳ６０７～Ｓ６０９）
　受信装置のプロキシサーバは、ステップＳ６０７～Ｓ６０９において、再生制御部からのリンク解決要求（Ｓ６０５）に応じた処理を実行する。
　すなわち、プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）が、ＰＤＩインスタンスに基づいてマッピングされたＵＲＬに従ってアクセスされるピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）から取得して、再生制御部に出力する。

　プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）は、ステップＳ６０６において広告サーバから受信したマッピングテーブルを利用して１つのピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）から選択取得して、再生制御部に出力する。

　プロキシサーバのリンク解決部（ＸＬｉｎｋＲｅｓｏｌｖｅｒ）は、まず、受信装置の再生制御部から入力したユーザ情報、すなわちＰＤＩ形式のクエリアンサー情報を含むデータと一致するＰＤＩインスタンスをマッピングテーブルから抽出する。

　次に、マッピングテーブルにおいて、一致したＰＤＩインスタンスと対応付けられたピリオド情報ファイルのＵＲＬを選択し、このＵＲＬを適用して１つのピリオド情報ファイルを取得し、これを再生制御部に出力する。

　このピリオド情報ファイルは、ステップＳ６０５において、再生制御部が設定したユーザ情報（パラメータ）に応じて選択されるピリオド情報ファイルであり、設定したユーザ情報（ＰＤＩの回答）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ６１０）
　最後に、受信装置の再生制御部は、ステップＳ６１０において、プロキシサーバから取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ６０５において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－６－２．（実施例６－２）クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する構成において、ＰＤＩテーブルを利用した実施例］
　次に、実施例６－２として、クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する構成において、ＰＤＩテーブルを利用した実施例について説明する。

　本実施例６－２は、受信装置３０が、送信装置２０から受信したスクリプト（プログラム）を利用して、再生制御部の生成したクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する実施例である。

　本実施例では、受信装置の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）からクエリアンサー構成を持つＰＤＩ構成を持つユーザ情報がプログラム（スクリプト）実行部に出力される。
　例えば、
　ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆ属性のＵＲＬであるクエリパラメータ付ＵＲＬ、例えば、
　ｈｔｔｐ：／／ａ．ｃｏｍ／ＸＬｉｎｋＲｅｓｏｌｖｅｒ？＜ＰＤＩＴａｂｌｅ　…＞＜ＱＩＡＴｙｐｅ　＠ｉｄ＝'１２３'　…　＞＜Ｑ　…　＞＜ＱＴｅｘｔ　…＞Ｈｏｗ　ｏｌｄ　ａｒｅ　ｙｏｕ？＜／ＱＴｅｘｔ＞＜／Ｑ＞＜Ａ　＠ａｎｓｗｅｒ＝'３５'　…　／＞＜ＱＩＡＴｙｐｅ＞＜／ＰＤＩＴａｂｌｅ＞
　このようなユーザ情報がプログラム（スクリプト）実行部に出力される。

　プログラム（スクリプト）実行部は、プログラム（スクリプト）を実行して、このユーザ情報を含むＰＤＩに従って、ユーザ情報に対応する特定のピリオド情報ファイルを生成して）再生制御部に出力する。

　図４４、図４５以下に示すシーケンス図を参照して、本実施例６－２、すなわち、クエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプト（プログラム）を受信装置に提供する実施例の処理シーケンスについて説明する。
　図４４～図４５には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるプログラム（スクリプト）実行部
　（ｆ）受信装置の構成要素である再生制御部、

　なお、「（ｅ）受信装置の構成要素であるプログラム（スクリプト）実行部」は、受信装置内のプロキシサーバ１２０内に構成してもよいし、再生制御部１３１内に構成としてもよい、あるいは独立したデータ処理部として設定してもよい。
　以下、図４４～図４５に示す各ステップの処理について、順次、説明する。

　　（ステップＳ６３１）
　ステップＳ６３１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ６３２）
　広告サーバは、ステップＳ６３２において、データ処理プログラムであるスクリプトファイルを生成して受信装置に送信する。
　このスクリプトは、受信装置の再生制御部がＭＰＤを利用して生成するクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプトである。
　すなわち、リンク解決（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）処理を実行して、ピリオド情報ファイルを生成するスクリプトである。

　このスクリプトは、ステップＳ６３１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成する処理を実行する。

　　（ステップＳ６３３）
　広告サーバは、さらに、ステップＳ６３３において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図３７、図３８を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ構成に従ってユーザ情報を設定するフィールドが設けられた未完成のＵＲＬが記録される。

　　（ステップＳ６３４）
　ステップＳ６３４は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ６３５）
　受信装置の再生制御部は、ステップＳ６３５において、ステップＳ６３４で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ形式のユーザ情報設定フィールドを持つリンク情報（Ｘｌｉｎｋ）を取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　受信装置の再生制御部は、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定したＰＤＩデータをプログラム（スクリプト）実行部に出力し、リンク情報（Ｘｌｉｎｋ）の解析（リンク解決）を要求する。
　この要求処理は、例えば、ＨＴＴＰ－ＧＥＴリクエストとして実行される。

　　（ステップＳ６３６～Ｓ６３７）
　ステップＳ６３６～Ｓ６３７の処理は、受信装置のプログラム（スクリプト）実行部の処理である。

　ステップＳ６３６において、ステップＳ６３２で広告サーバから受信したスクリプトを起動する。
　すなわち、ＰＤＩ情報を含むクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成するスクリプトを起動する。
　さらに、ステップＳ６３７においてスクリプトを実行し、ステップＳ６３５において再生制御部から入力したＰＤＩ形式のユーザ情報（パラメータ）を解析して、このユーザ情報に対応するピリオド情報ファイルを生成して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ６３５において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ６３８）
　最後に、受信装置の再生制御部は、ステップＳ６３８において、プログラム（スクリプト）実行部から取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ６３５において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－６－３．（実施例６－３）サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する構成において、ＰＤＩテーブルを利用した実施例］
　次に、実施例６－３として、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する構成において、ＰＤＩテーブルを実施例について説明する。

　サービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ　Ｗｏｒｋｅｒ）は、先に図３０～図３２を参照して説明したように、受信装置（クライアント）３０において実行されるアプリケーション（＝アプリケーションプログラム）や、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。具体的には、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって構成される。

　本実施例６－３は、このサービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例である。

　図４６、図４７以下に示すシーケンス図を参照して、本実施例４、すなわち、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルをキャッシュ部（プロキシキャッシュ）に格納する処理を実行させる実施例の処理シーケンスについて説明する。
　図４６～図４７には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるブラウザキャッシュ
　（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部
　（ｇ）受信装置の構成要素である再生制御部、

　なお、上記構成中、（ｅ）受信装置の構成要素であるブラウザキャッシュと、（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部は、上述したサービスワーカー（ＳＷ）の管理キャッシュおよび実行部である。
　以下、図４６～図４７に示す各ステップの処理について、順次、説明する。

　　（ステップＳ６５１）
　ステップＳ６５１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ６５２）
　広告サーバは、ステップＳ６５２において、ステップＳ６５１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成して送信する。

　広告サーバの生成、送信するピリオド情報ファイルは、ステップＳ６５１において生成、送信した広告セグメントの種類に相当する数の異なるピリオド情報ファイルである。
　複数の異なるピリオド情報ファイルが、放送波、あるいはネットワークを介してマルチキャスト送信される。
　なお、このピリオド情報ファイルも継続的に繰り返し送信する設定としてよい。

　　（ステップＳ６５３）
　広告サーバは、ステップＳ６５３において、データ処理プログラムであるサービスワーカー（ＳＷ）スクリプトファイルを生成して受信装置に送信する。
　このサービスワーカー（ＳＷ）スクリプトファイルは、受信装置のプロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する処理を実行するスクリプトである。

　　（ステップＳ６５４～Ｓ６５６）
　ステップＳ６５４～Ｓ６５６の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ６５４において、ステップＳ６５２で広告サーバから受信したサービスワーカー（ＳＷ）スクリプトファイルを起動する。
　すなわち、受信装置のプロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する処理を実行するサービスワーカー（ＳＷ）スクリプトファイルを起動する。

　さらに、ステップＳ６５５～Ｓ６５６において、サービスワーカー（ＳＷ）スクリプトを実行し、プロキシキャッシュに格納されたピリオド情報ファイルや、広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する。

　　（ステップＳ６５７）
　広告サーバは、ステップＳ６５７において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図３７、図３８を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ構成に従ってユーザ情報を設定するフィールドが設けられた未完成のＵＲＬが記録される。

　　（ステップＳ６５８）
　ステップＳ６５８は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ６５９）
　受信装置の再生制御部は、ステップＳ６５９において、ステップＳ６５８で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ形式のユーザ情報設定フィールドを持つリンク情報（Ｘｌｉｎｋ）を取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　　（ステップＳ６６０）
　ステップＳ６６０の処理は、受信装置のブラウザキャッシュの処理である。
　ブラウザキャッシュは、再生制御部から入力したＨＴＴＰ－ＧＥＴリクエストに対する応答処理を実行する。
　具体的には、再生制御部から入力したＰＤＩ形式のユーザ情報（パラメータ）を解析して、このユーザ情報に対応するピリオド情報ファイルを取得して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ６５９において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ６６１）
　最後に、受信装置の再生制御部は、ステップＳ６６１において、ブラウザキャッシシュから取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

　ここで、受信装置に出力される広告コンテンツは、ステップＳ６５９において再生制御部が設定したユーザ情報に応じて選択された広告であり、ユーザ（視聴者）の特性、例えばユーザの年齢や居住地等によって選択されたユーザを主なターゲットとしたユーザ対応の広告である。

　　［８－６－４．（実施例６－４）クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する構成において、ＰＤＩテーブルを利用した実施例］
　次に、実施例６－４として、クエリパラメータ付きＵＲＬを入力して、サービスワーカー（ＳＷ）を利用してピリオド情報ファイルを生成する構成において、ＰＤＩテーブルを利用した実施例について説明する。

　本実施例６－４は、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する処理を実行する実施例である。
　本実施例６－４は、受信装置３０が、送信装置２０から受信したサービスワーカー（ＳＷ）スクリプトを利用して、再生制御部の生成したクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する実施例である。

　図４８、図４９以下に示すシーケンス図を参照して、本実施例６－４、すなわち、サービスワーカー（ＳＷ）を利用して、ピリオド情報ファイルを生成する実施例の処理シーケンスについて説明する。
　図４８～図４９には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置の構成要素である広告サーバ、
　（ｂ）送信装置の構成要素である放送サーバ、
　（ｃ）受信装置の構成要素であるミドルウェア、
　（ｄ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｅ）受信装置の構成要素であるブラウザキャッシュ
　（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部
　（ｇ）受信装置の構成要素である再生制御部、

　なお、上記構成中、（ｅ）受信装置の構成要素であるブラウザキャッシュと、（ｆ）受信装置の構成要素であるブラウザプログラム（スクリプト）実行部は、上述したサービスワーカー（ＳＷ）の管理キャッシュおよび実行部である。
　以下、図４８～図４９に示す各ステップの処理について、順次、説明する。

　　（ステップＳ６７１）
　ステップＳ６７１において、広告サーバが、広告コンテンツを格納した広告セグメントファイルを生成し、転送する。放送波、あるいはネットワークを介して、受信装置を送信対象としたマルチキャスト送信を行う。

　　（ステップＳ６７２）
　広告サーバは、ステップＳ６７２において、データ処理プログラムであるサービスワーカー（ＳＷ）スクリプトファイルを生成して受信装置に送信する。
　このサービスワーカー（ＳＷ）スクリプトファイルは、広告サーバが送信し、受信装置のプロキシキャッシュに格納された広告セグメントファイルを、ブラウザキャッシュから取り出してブラウザキャッシュに格納する処理を実行する。さらに、受信装置の再生制御部がＭＰＤを利用して生成するクエリパラメータ付きＵＲＬを入力して、ピリオド情報ファイルを生成する。すなわち、リンク解決（ＸｌｉｎｋＲｅｓｏｌｖｅｒ）処理を実行して、ピリオド情報ファイルを生成する。
　これらの処理を実行するサービスワーカー（ＳＷ）スクリプトである。

　このサービスワーカー（ＳＷ）スクリプトは、ステップＳ６７１で送信した様々な広告コンテンツ各々に対するアクセス情報（広告セグメントＵＲＬ）等、受信装置において、広告コンテンツを取得し、復号、出力（再生）するために必要な制御情報を記録したピリオド情報ファイルを生成する処理を実行する。

　　（ステップＳ６７３～Ｓ６７４）
　ステップＳ６７３～Ｓ６７４の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ６７３において、ステップＳ６７２で広告サーバから受信したサービスワーカー（ＳＷ）スクリプトファイルを起動する。
　さらに、ステップＳ６７４において、サービスワーカー（ＳＷ）スクリプトを実行し、プロキシキャッシュに格納された広告セグメントファイルを取得してサービスワーカー（ＳＷ）の管理キャッシュであるブラウザキャッシュに格納する。

　　（ステップＳ６７５）
　広告サーバは、ステップＳ６７５において、ＭＰＤの送信処理を実行する。
　ここで送信するＭＰＤは、例えば図３７、図３８を参照して説明したＭＰＤである。すなわち、広告対応のピリオド情報を含み、広告対応のピリオド情報には、リンク情報（Ｘｌｉｎｋ）、すなわち、ＰＤＩ構成に従ってユーザ情報を設定するフィールドが設けられた未完成のＵＲＬが記録される。

　　（ステップＳ６７６）
　ステップＳ６７６は、受信装置の再生制御部の処理である。
　受信装置の再生制御部は、送信装置の送信したＭＰＤを取得し、取得したＭＰＤの解析（パース）を実行する。
　なお、ＭＰＤは、受信装置のミドルウェアによって受信され、プロキシサーバのキャッシュ部に格納され、その後、再生制御部がキャッシュ部から取得する。

　　（ステップＳ６７７）
　受信装置の再生制御部は、ステップＳ６７７において、ステップＳ６７６で取得したＭＰＤの広告対応のピリオド情報に記録されたリンク情報（Ｘｌｉｎｋ）、すなわち、
ＰＤＩ形式のユーザ情報設定フィールドを持つリンク情報（Ｘｌｉｎｋ）を取得して、ユーザ情報設定フィールドにユーザ情報（パラメータ）を設定する。
　ユーザ情報の設定処理は、例えば受信装置の記憶部に予め登録（記録）されたユーザ情報を用いてもよいし、遂次、ユーザに入力させる構成として、ユーザ入力情報を用いる構成としてもよい。

　　（ステップＳ６７８）
　ステップＳ６７８の処理は、受信装置のブラウザプログラム（スクリプト）実行部の処理である。

　ステップＳ６７８において、サービスワーカー（ＳＷ）スクリプトを実行する。すなわちステップＳ６７７において再生制御部から入力したＰＤＩ形式のユーザ情報（パラメータ）を解析して、このユーザ情報に対応するピリオド情報ファイルをを生成して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

　このピリオド情報ファイルは、ステップＳ６７７において、再生制御部が設定したユーザ情報（パラメータ）に応じたピリオド情報ファイルであり、設定したユーザ情報（ａｇｅ，Ｌｏｃａｔｉｏｎ等）によって選択される特定ユーザに提供するための最適な広告コンテンツのアクセス情報（広告セグメントＵＲＬ）等を記録したピリオド情報ファイルである。

　　（ステップＳ６７９）
　最後に、受信装置の再生制御部は、ステップＳ６７９において、プログラム（スクリプト）実行部から取得したピリオド情報ファイルの記録情報を読み出し、解析する。
　再生制御部は、ピリオド情報ファイルの記録情報に含まれる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を利用して、広告コンテンツを格納した広告セグメントファイルを取得し、受信装置の表示部やスピーカ等の出力部を介して出力する。

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

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

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

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

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

　データ処理部７７１は、通信データ処理部７７１ａ、再生処理部７７１ｂを有し、例えば先に説明した実施例に従った処理等を実行する。
　具体的には、アプリケーションや、ピリオド情報ファイル、ＡＰＩ、さらに、サービスワーカー（ＳＷ）を利用したデータ処理等を実行する。

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

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

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

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

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

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

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

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

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　ユーザ情報設定領域を有するシグナリングデータを受信する通信部と、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツを取得するデータ処理部を有する受信装置。

　（２）前記データ処理部は、
　前記ユーザ情報設定済みデータを適用して、前記制御情報ファイルのアクセス情報を生成し、生成したアクセス情報を適用して前記制御情報ファイルを取得する（１）に記載の受信装置。

　（３）前記データ処理部は、
　前記ユーザ情報設定済みデータを適用して、前記制御情報ファイルを生成する（１）に記載の受信装置。

　（４）前記シグナリングデータは、ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）であり、
　前記データ処理部は、ＭＰＤの前記ユーザ情報対応コンテンツ対応のシグナリングデータ記録領域に含まれるユーザ情報設定領域にユーザ情報を設定する（１）～（３）いずれかに記載の受信装置。

　（５）前記ＭＰＤは、再生時間単位の制御情報を記録したピリオド情報を含み、
　前記データ処理部は、ＭＰＤの前記ユーザ情報対応コンテンツ対応のピリオド情報に含まれるユーザ情報設定領域にユーザ情報を設定する（４）に記載の受信装置。

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

　（７）前記ユーザ情報設定領域にユーザ情報を設定して生成されるユーザ情報設定済みデータは、前記制御情報ファイルのアクセス情報であるＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）、または前記ＵＲＬを特定可能なデータである（１）～（６）いずれかに記載の受信装置。

　（８）前記ユーザ情報設定領域は、質問（クエリ）に対する回答（クエリパラメータ）を入力するＰＤＩ（Ｐｒｅｆｅｒｅｎｃｅ　Ｄｅｍｏｇｒａｐｈｉｃ　Ｉｎｔｅｒｅｓｔ）形式を有するデータ領域である（１）～（７）いずれかに記載の受信装置。

　（９）前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　各々が異なるユーザ情報設定済みデータを含む複数の第２のシグナリングデータと、
　前記複数の第２のシグナリングデータの各々に対応付けられた制御情報ファイルを受信し、
　前記データ処理部は、
　前記ＭＰＤのユーザ情報設定領域にユーザ情報を設定して生成されたユーザ情報設定済みデータと一致するユーザ情報設定済みデータを含む第２のシグナリングデータを選択し、
　選択した第２のシグナリングデータに対応付けられた制御情報ファイルを取得する（１）～（８）いずれかに記載の受信装置。

　（１０）前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報対応コンテンツの制御情報ファイルのアクセス情報と、ユーザ情報設定済みデータとのマッピングテーブルを受信し、
　前記データ処理部は、
　前記ＭＰＤのユーザ情報設定領域にユーザ情報を設定して生成されたユーザ情報設定済みデータと一致するデータを前記マッピングテーブルから抽出し、
　前記マッピングテーブルから、抽出データに対応付けられた制御情報ファイルのアクセス情報を選択し、選択したアクセス情報に基づいてユーザ情報対応コンテンツの制御情報ファイルを取得する（１）～（８）いずれかに記載の受信装置。

　（１１）前記通信部は、さらに、
　前記制御情報ファイルを生成するスクリプトファイルを受信し、
　前記データ処理部は、
　前記スクリプトファイルを適用して、前記ユーザ情報設定済みデータに基づいてユーザ情報対応コンテンツの制御情報ファイルを生成する（１）～（８）いずれかに記載の受信装置。

　（１２）前記通信部は、
　前記制御情報ファイル、および前記ユーザ情報対応コンテンツのブラウザキャッシュへの引き込み処理を実行するスクリプトファイルを受信し、
　前記データ処理部は、
　前記スクリプトファイルを適用して、前記制御情報ファイル、および前記ユーザ情報対応コンテンツのブラウザキャッシュへの引き込み処理を実行する（１）～（８）いずれかに記載の受信装置。

　（１３）ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信する通信部を有する送信装置。

　（１４）前記シグナリングデータは、ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）であり、
　前記ＭＰＤは、再生時間単位の制御情報を記録したピリオド情報を含み、ユーザ情報対応コンテンツ対応のピリオド情報内に前記ユーザ情報設定領域が含まれる構成である（１３）に記載の送信装置。

　（１５）前記ユーザ情報設定領域は、質問（クエリ）に対する回答（クエリパラメータ）を入力するＰＤＩ（Ｐｒｅｆｅｒｅｎｃｅ　Ｄｅｍｏｇｒａｐｈｉｃ　Ｉｎｔｅｒｅｓｔ）形式を有するデータ領域である（１３）または（１４）に記載の送信装置。

　（１６）前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報設定済みデータを含む第２のシグナリングデータと、
　前記第２のシグナリングデータの各々に対応付けられた制御情報ファイルを送信する（１３）～（１５）いずれかに記載の送信装置。

　（１７）前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報対応コンテンツの制御情報ファイルのアクセス情報と、ユーザ情報設定済みデータとのマッピングテーブルを送信する（１３）～（１５）いずれかに記載の送信装置。

　（１８）前記通信部は、
　前記ユーザ情報設定済みデータに基づいて、前記制御情報ファイルを生成するスクリプトファイルを送信する（１３）～（１５）いずれかに記載の送信装置。

　（１９）受信装置において実行するデータ処理方法であり、
　通信部が、ユーザ情報設定領域を有するシグナリングデータを受信し、
　データ処理部が、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツの取得処理を実行するデータ処理方法。

　（２０）送信装置において実行するデータ処理方法であり、
　ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信するデータ処理方法。

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

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

　以上、説明したように、本開示の一実施例の構成によれば、受信装置に、受信装置側のユーザに応じた広告等のコンテンツを選択して出力可能とする装置、方法が実現される。
　具体的には、送信装置が、ユーザ情報設定領域を有するシグナリングデータ（ＭＰＤ）と、ＭＰＤに対する処理によって生成されるユーザ情報設定済みデータを適用してアクセスまたは生成可能な制御情報ファイルと、制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応広告を送信する。受信装置は、ＭＰＤのユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用してユーザ情報対応広告の制御情報ファイルを取得し、取得した制御情報ファイルの記述データを適用してユーザ情報対応広告を取得し、出力する。
　本構成により、受信装置に、受信装置側のユーザに応じた広告等のコンテンツを選択して出力可能とした装置、方法が実現される。

　　１０　通信システム
　　２０　送信装置
　　２１　放送サーバ
　　２２　広告サーバ
　　２３　データ配信サーバ
　　３０　受信装置
　　３１　ＴＶ
　　３２　ＰＣ
　　３３　携帯端末
　　３５　チューナ実装受信装置
　　３６　チューナ非実装受信装置
　　５０　シグナリングデータ
　　６０　ＡＶセグメント
　　７０　その他のデータ
　１１０　ミドルウェア
　１１１　通信部（ＰＨＹ／ＭＡＣ）
　１１２　シグナリング取得部
　１１３　シグナリング解析部
　１１４　セグメント取得部
　１２０　ＨＴＴＰプロキシサーバ
　１２１　キャッシュ部
　１２２　アドレス＆リンク解決部
　１３１　再生制御部
　１３２　出力制御部
　２０１　ＭＰＤ取得部
　２０２　ＭＰＤ解析部
　２０３　セグメント取得部
　２０４　セグメント解析部
　２１１　復号部
　２１２　出力部
　３１１～３１４　ピリオド情報
　４０１　シグナリングデータ
　４０２　ピリオド情報ファイル
　４５０　プラウザ
　４５１　表示処理部
　４５２　サービスワーカー（ＳＷ）
　４５３　キャッシュ
　４５５，４５６　Ｗｅｂページ
　５１１～５１４　ピリオド情報
　７５１　データ処理部
　７５２　通信部
　７５３　記憶部
　７７１　データ処理部
　７７２　通信部
　７７３　記憶部
　７７４　入力部
　７７５　出力部
　８０１　ＣＰＵ
　８０２　ＲＯＭ
　８０３　ＲＡＭ
　８０４　バス
　８０５　入出力インタフェース
　８０６　入力部
　８０７　出力部
　８０８　記憶部
　８０９　通信部
　８１０　ドライブ
　８１１　リムーバブルメディア

Claims

　ユーザ情報設定領域を有するシグナリングデータを受信する通信部と、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツを取得するデータ処理部を有する受信装置。
　前記データ処理部は、
　前記ユーザ情報設定済みデータを適用して、前記制御情報ファイルのアクセス情報を生成し、生成したアクセス情報を適用して前記制御情報ファイルを取得する請求項１に記載の受信装置。
　前記データ処理部は、
　前記ユーザ情報設定済みデータを適用して、前記制御情報ファイルを生成する請求項１に記載の受信装置。
　前記シグナリングデータは、ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）であり、
　前記データ処理部は、ＭＰＤの前記ユーザ情報対応コンテンツ対応のシグナリングデータ記録領域に含まれるユーザ情報設定領域にユーザ情報を設定する請求項１に記載の受信装置。
　前記ＭＰＤは、再生時間単位の制御情報を記録したピリオド情報を含み、
　前記データ処理部は、ＭＰＤの前記ユーザ情報対応コンテンツ対応のピリオド情報に含まれるユーザ情報設定領域にユーザ情報を設定する請求項４に記載の受信装置。
　前記ユーザ情報対応コンテンツは、ユーザ情報に応じて選択される広告コンテンツである請求項１に記載の受信装置。
　前記ユーザ情報設定領域にユーザ情報を設定して生成されるユーザ情報設定済みデータは、前記制御情報ファイルのアクセス情報であるＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）、または前記ＵＲＬを特定可能なデータである請求項１に記載の受信装置。
　前記ユーザ情報設定領域は、質問（クエリ）に対する回答（クエリパラメータ）を入力するＰＤＩ（Ｐｒｅｆｅｒｅｎｃｅ　Ｄｅｍｏｇｒａｐｈｉｃ　Ｉｎｔｅｒｅｓｔ）形式を有するデータ領域である請求項１に記載の受信装置。
　前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　各々が異なるユーザ情報設定済みデータを含む複数の第２のシグナリングデータと、
　前記複数の第２のシグナリングデータの各々に対応付けられた制御情報ファイルを受信し、
　前記データ処理部は、
　前記ＭＰＤのユーザ情報設定領域にユーザ情報を設定して生成されたユーザ情報設定済みデータと一致するユーザ情報設定済みデータを含む第２のシグナリングデータを選択し、
　選択した第２のシグナリングデータに対応付けられた制御情報ファイルを取得する請求項１に記載の受信装置。
　前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報対応コンテンツの制御情報ファイルのアクセス情報と、ユーザ情報設定済みデータとのマッピングテーブルを受信し、
　前記データ処理部は、
　前記ＭＰＤのユーザ情報設定領域にユーザ情報を設定して生成されたユーザ情報設定済みデータと一致するデータを前記マッピングテーブルから抽出し、
　前記マッピングテーブルから、抽出データに対応付けられた制御情報ファイルのアクセス情報を選択し、選択したアクセス情報に基づいてユーザ情報対応コンテンツの制御情報ファイルを取得する請求項１に記載の受信装置。
　前記通信部は、さらに、
　前記制御情報ファイルを生成するスクリプトファイルを受信し、
　前記データ処理部は、
　前記スクリプトファイルを適用して、前記ユーザ情報設定済みデータに基づいてユーザ情報対応コンテンツの制御情報ファイルを生成する請求項１に記載の受信装置。
　前記通信部は、
　前記制御情報ファイル、および前記ユーザ情報対応コンテンツのブラウザキャッシュへの引き込み処理を実行するスクリプトファイルを受信し、
　前記データ処理部は、
　前記スクリプトファイルを適用して、前記制御情報ファイル、および前記ユーザ情報対応コンテンツのブラウザキャッシュへの引き込み処理を実行する請求項１に記載の受信装置。
　ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信する通信部を有する送信装置。
　前記シグナリングデータは、ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）であり、
　前記ＭＰＤは、再生時間単位の制御情報を記録したピリオド情報を含み、ユーザ情報対応コンテンツ対応のピリオド情報内に前記ユーザ情報設定領域が含まれる構成である請求項１３に記載の送信装置。
　前記ユーザ情報設定領域は、質問（クエリ）に対する回答（クエリパラメータ）を入力するＰＤＩ（Ｐｒｅｆｅｒｅｎｃｅ　Ｄｅｍｏｇｒａｐｈｉｃ　Ｉｎｔｅｒｅｓｔ）形式を有するデータ領域である請求項１３に記載の送信装置。
　前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報設定済みデータを含む第２のシグナリングデータと、
　前記第２のシグナリングデータの各々に対応付けられた制御情報ファイルを送信する請求項１３に記載の送信装置。
　前記通信部は、
　前記ユーザ情報設定領域を有する第１のシグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と、
　ユーザ情報対応コンテンツの制御情報ファイルのアクセス情報と、ユーザ情報設定済みデータとのマッピングテーブルを送信する請求項１３に記載の送信装置。
　前記通信部は、
　前記ユーザ情報設定済みデータに基づいて、前記制御情報ファイルを生成するスクリプトファイルを送信する請求項１３に記載の送信装置。
　受信装置において実行するデータ処理方法であり、
　通信部が、ユーザ情報設定領域を有するシグナリングデータを受信し、
　データ処理部が、
　前記ユーザ情報設定領域にユーザ情報を設定し、生成したユーザ情報設定済みデータを適用して、ユーザ情報対応コンテンツの制御情報ファイルを取得し、
　取得した制御情報ファイルの記述データを適用して、前記ユーザ情報対応コンテンツの取得処理を実行するデータ処理方法。
　送信装置において実行するデータ処理方法であり、
　ユーザ情報設定領域を有するシグナリングデータと、
　受信装置において前記ユーザ情報設定領域にユーザ情報を設定することで生成されるユーザ情報設定済みデータを適用して、アクセスまたは生成可能な制御情報ファイルと、
　前記制御情報ファイルの記述データに基づいて、取得、再生可能なユーザ情報対応コンテンツを送信するデータ処理方法。