WO2017038353A1

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

Info

Publication number: WO2017038353A1
Application number: PCT/JP2016/072748
Authority: WO
Inventors: 山岸　靖明
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2015-08-28
Filing date: 2016-08-03
Publication date: 2017-03-09
Anticipated expiration: 2018-02-28
Also published as: CA2996275C; EP3343938A4; US10878076B2; KR20180048618A; MX2018002208A; MX382801B; CA2996275A1; CN107925798A; US20180196935A1; CN107925798B; JPWO2017038353A1; EP3343938A1; KR102586630B1

Abstract

アプリケーションの正当性を確認したことを条件としてアプリケーションを実行させる構成を提供する。送信装置が、アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する。受信装置は、これらのデータを受信し、認証情報に基づく認証処理を実行し、アプリケーションの正当性を確認し、正当性が確認されたアプリケーションを実行する。アプリケーションは、ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションであり、ユーザ情報に応じた正しい広告を確実にユーザに提供することが可能となる。

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

　本開示は、例えば上記問題点に鑑みてなされたものであり、放送番組等を受信し、再生する受信装置において実行するアプリケーションの正当性を確認した上で、アプリケーションを実行することで、例えば不正アプリケーションの処理による不正なデータが再生されるといった事態を防止する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

　本開示の一つの実施態様においては、ユーザに応じた広告等、ユーザ対応コンテンツの選択的出力を行うために利用されるアプリケーションの正当性を確認した上で、アプリケーションを実行することで、ユーザに応じた広告等、ユーザ対応コンテンツを確実に出力可能とする受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

　本開示の第１の側面は、
　アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信する通信部と、
　前記アプリケーションを実行するデータ処理部を有し、
　前記データ処理部は、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証部と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するアプリケーション実行部を有する受信装置にある。

　さらに、本開示の第２の側面は、
　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する通信部を有する送信装置にある。

　さらに、本開示の第３の側面は、
　受信装置において実行するデータ処理方法であり、
　通信部が、アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信し、
　データ処理部が、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証処理と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するデータ処理方法にある。

　さらに、本開示の第４の側面は、
　送信装置において実行するデータ処理方法であり、
　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信するデータ処理方法にある。

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

　本開示の一実施例の構成によれば、アプリケーションの正当性を確認したことを条件としてアプリケーションを実行させる構成が実現される。
　具体的には、送信装置が、アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する。受信装置は、これらのデータを受信し、認証情報に基づく認証処理を実行し、アプリケーションの正当性を確認し、正当性が確認されたアプリケーションを実行する。アプリケーションは、ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションであり、ユーザ情報に応じた正しい広告を確実にユーザに提供することが可能となる。
　本構成により、受信装置において、アプリケーションの正当性を確認したことを条件としてアプリケーションを実行させる構成が実現される。
　例えば、広告選択処理を実行するアプリの正当性を確認させることで、受信装置側のユーザに応じた広告等のコンテンツを間違いなく選択出力する構成が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。送信装置の送信データについて説明する図である。送信装置および受信装置のプロトコルスタックの例を示す図である。ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。受信装置（クライアント）３０におけるデータ出力例を説明する図である。様々なユーザ情報を利用した出力広告の選択例について説明する図である。受信装置の構成例について説明する図である。受信装置の構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの構成例について説明する図である。ＭＰＤの利用シーケンス例について説明する図である。ＭＰＤ内の広告対応ピリオド情報の構成例について説明する図である。ＭＰＤの広告対応ピリオド情報を利用した処理シーンスについて説明する図である。ＭＰＤ内の広告対応ピリオド情報を利用した処理シーンスについて説明する図である。アプリケーション情報テーブル（ＡＩＴ）の構成例について説明する図である。アプリケーション情報テーブル（ＡＩＴ）にアプリケーションの認証情報を記録した構成例について説明する図である。アプリケーション情報テーブル（ＡＩＴ）内の認証情報記録位置について説明する図である。アプリケーション情報テーブル（ＡＩＴ）に記録される認証情報のデータ例について説明する図である。アプリケーション情報テーブル（ＡＩＴ）に認証情報記録する送信装置の処理シーケンスについて説明するフローチャートを示す図である。アプリケーション情報テーブル（ＡＩＴ）に記録される認証情報のデータ例について説明する図である。ＸＭＬ署名の例について説明する図である。アプリケーション制御部にアプリケーション検証部を設定した受信装置の構成例について説明する図である。アプリケーション情報テーブル（ＡＩＴ）内の認証情報を利用した処理シーケンスについて説明する図である。アプリケーション情報テーブル（ＡＩＴ）内の認証情報を利用した処理シーケンスについて説明する図である。アプリケーション情報テーブル（ＡＩＴ）内の認証情報を利用した処理シーケンスについて説明する図である。ＭＰＤにアプリケーションの認証情報を記録した構成例について説明する図である。ＭＰＤ内の認証情報記録位置について説明する図である。ＭＰＤに記録される認証情報のデータ例について説明する図である。ＭＰＤ内の認証情報記録位置について説明する図である。ＭＰＤに記録される認証情報のデータ例について説明する図である。再生制御部にアプリケーション検証部を設定した受信装置の構成例について説明する図である。ＭＰＤ内の認証情報を利用した処理シーケンスについて説明する図である。ＭＰＤ内の認証情報を利用した処理シーケンスについて説明する図である。ＭＰＤ内の認証情報を利用した処理シーケンスについて説明する図である。通信装置である送信装置と受信装置の構成例について説明する図である。通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

　以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．受信装置におけるデータ出力例について
　５．受信装置の構成例と処理例について
　６．ＭＰＤを利用したピリオド（Ｐｅｒｉｏｄ）単位のシグナリングデータについて
　７．ユーザ情報に応じた広告提供処理を実行するための具体的構成例について
　８．不正アプリケーションによる不正広告の出力処理について
　９．（実施例１）アプリケーション情報テーブル（ＡＩＴ）に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について
　９－１．アプリケーション情報テーブル（ＡＩＴ）に対する認証情報の記録構成について
　９－２．アプリケーション情報テーブル（ＡＩＴ）を適用したアプリケーション認証処理を実行する構成とシーケンスについて
　１０．（実施例２）ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について
　１０－１．ＭＰＤに対する認証情報の記録構成について
　１０－２．ＭＰＤを適用したアプリケーション認証処理を実行する構成とシーケンスについて
　１１．送信装置と受信装置の構成例について
　１２．本開示の構成のまとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　図７に示す受信装置３０は、放送サーバや、広告サーバ等の送信装置２０からの送信データを受信するミドルウェア１１０と、受信データの解析やキャッシュ処理を実行するプロキシサーバ１２０、番組再生やアプリケーション実行によるデータ再生処理を実行する再生処理部１３０を有する。

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

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

　ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキュッシュ制御部１２１介してキャッシュ部（プロキシキャッシュ）１２２に格納される。プロキシサーバ１２０は、さらにネットワーク経由で送信装置２０から取得したデータをキャッシュ部１２２に格納する。

　プロキシサーバ１２０のキャッシュ制御部１２１は、再生処理部１３０の再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２からのデータ取得要求を入力し、要求データを再生処理部に提供する。
　例えば、キャッシュ制御部１２１は、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２からのデータ取得要求に応じたアドレス解決処理等を行い、アドレスに応じたデータをキャッシュ部１２２から取得して、再生処理部１３０の再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２に出力する。なお、キャッシュ部１２２に要求データが格納されていない場合は、外部から取得して提供する場合もある。

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

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

　アプリケーション制御部１３２は、例えば、先に図５、図６を参照して説明した天気予報、広告のアプリケーション等、送信装置２０から提供されるアプリケーションの実行、開始、終了等の制御を行う。

　出力制御部１３３は、再生制御部１３１やアプリケーション制御部１３２から提供される番組構成データやアプリケーション実行用データを取得し、取得データの復号処理や、表示部への出力処理等を実行する。

　なお、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２は、送信装置２０（放送サーバ２１、広告サーバ２２等）が送信するシグナリングデータを参照し、シグナリングデータに記述された情報に従って必要なデータをプロキシサーバ１２０から取得し、また、シグナリングデータに記述された情報に従って再生制御やアプリケーション制御を実行する。

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

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

　例えば、アプリケーション制御部１３２は、アプリケーション対応の属性情報や制御情報を記録した様々なシグナリングデータに基づくアプリケーション制御を実行する。具体的には、例えば、ＡＴＳＣ３．０のシグナリングデータであるＵＳＢＤ／ＵＳＤや、Ｓ－ＴＳＩＤ、あるいは、個々のアプリケーションに対応する属性情報や制御情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）などを利用したアプリケーション制御を実行する。

　なお、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２は、プロキシサーバ１２０のキャッシュ部１２２に格納されたデータを利用した処理を実行する。
　キャッシュ部１２２に格納されるデータは、ミドルウェア（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＡＴＳＣ　Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータや、プロキシサーバ１２０がネットワークを介して受信したデータである。

　ミドルウェア１１０、またはプロキシサーバ１２０が放送波あるいは通信ネットワークを介して取得するデータは、例えば、ＤＡＳＨ－ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）ファイル等である。
　これらは、キャッシュ制御部１２１の制御に基づいてキャッシュ部１２２に格納される。

　その後、キャッシュ制御部１２１は、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２の要求に応じて、キャッシュ部１２２から要求データを取得して、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２に提供され、ストリームのレンダリングや、アプリケーションの実行等のデータ再生処理に利用される。

　再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１や、アプリケーション制御部１３２がセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を、プロキシサーバ１２０のキャッシュ制御部１２１に対して要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０のキャッシュ制御部１２１は、キャッシュ部１２２からデータ取得を行う。なお、キャッシュ部１２２にデータがない場合は、放送、またはネット経由での取得処理を行う。

　また、再生制御（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、コンテンツの再生、アプリケーションの制御情報等を記録したシグナリングデータを取得する。これらは、シグナリング取得部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２によって取得される。
　例えば、ＵＳＢＤ／ＵＳＤや、ＡＩＴや、Ｓ－ＴＳＩＤ、ＭＰＤ等の様々なシグナリングデータが取得され、利用される。

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

　これらのシグナリングデータは、ミドルウェア１１０のシグナリング取得部１１２によって取得され、シグナリング解析部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３において解析される。
　シグナリングデータには、例えば、番組再生に必要となるＡＶセグメントや、アプリケーションの実行に必要となる様々なデータファイル（リソース）等を取得するためのアドレス情報（ＵＲＬ）が含まれ、シグナリング解析部１１３は、必要となるセグメントやリソースファイルを取得するアドレス情報（放送配信アドレス情報）の取得処理などを行う。

　この放送配信アドレス情報に基づいて、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、取得データがプロキシサーバ１２０のキャッシュ部１２２内に展開される。

　図８は、受信装置（クライアント）３０の有する、
　再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１、
　出力制御部１３３、
　これらの詳細構成を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　受信装置（クライアント）に配信されるＭＰＤ（例えばサービスシグナリングにより配信される）は、
　ＭＰＤ／Ｐｅｒｉｏｄ／＠ｘｌｉｎｋ：ｈｒｅｆの位置にユーザ情報を設定してピリオド情報（ピリオド要素）のアクセス情報（ＵＲＬ）を記述することができる。
　このＵＲＬは、設定したユーザ情報に応じて選択される広告のアクセス情報等を記録した特定のピリオド情報（ピリオド要素）のアクセス情報（ＵＲＬ）として認識できる。

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

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

　アプリケーション制御部１３２は、リンク解決アプリ（スクリプト）の実行により、ユーザ情報に応じたピリオド要素を選択し、選択したユーザ情報対応の広告を格納した広告セグメントのＵＲＬ等を含むピリオド要素を受信装置３０の再生制御部１３１に返信する。
　受信装置３０の再生制御部１３１は、ピリオド要素に記録された広告セグメントＵＲＬを用いて広告セグメントの取得処理を行い、広告を再生する。

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

　図１４～図１５には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置、
　（ｂ）受信装置の構成要素であるミドルウェア、
　（ｃ）受信装置の構成要素であるプロキシサーバのキャッシュ部（プロキシキャッシュ）、
　（ｄ）受信装置の構成要素であるブラウザキャッシュ
　（ｅ）受信装置の構成要素であるアプリケーション（スクリプト）制御部
　（ｆ）受信装置の構成要素である再生制御部、

　なお、ブラウザキャッシュは、アプリケーション（スクリプト）制御部で実行するアプリケーションが、ブラウザ上で実行されるアプリケーションである場合に、アプリケーション（スクリプト）によって利用されるキャッシュ部である。
　以下、図１４～図１５に示す各ステップの処理について、順次、説明する。

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

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

　　（ステップＳ１２）
　送信装置は、ステップＳ１２において、リンク解決処理（ｘｌｉｎｋ　Ｒｅｓｏｌｖｅｒ）を実行するアプリケーション、例えばブラウザ上で実行されるＪａｖａ（登録商標）Ｓｃｒｉｐｔを生成して、受信装置に送信する。

　すなわち、先に図１３を参照して説明したユーザ情報設定ＵＲＬ（＝ユーザ情報に応じたピリオド要素のアクセス情報）に基づいて、ユーザ情報に応じたピリオド要素を選択するリンク解決（ｘｌｉｎｋ　Ｒｅｓｏｌｖｅｒ）処理を実行するアプリケーションである。

　　（ステップＳ１３～Ｓ１４）
　ステップＳ１３～Ｓ１４の処理は、受信装置のアプリケーション制御部で実行する処理である。
　ステップＳ１３において、ステップＳ１２で送信装置から受信したリンク解決アプリ（スクリプト）を起動する。

　さらに、ステップＳ１４において、リンク解決アプリ（スクリプト）を実行し、解決結果に基づいて取得されるピリオド要素や、広告セグメントファイルを取得してブラウザキャッシュに格納する。

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

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

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

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

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

　　（ステップＳ１８）
　ステップＳ１８の処理は、受信装置のアプリケーション制御部の処理である。
　アプリケーション制御部は、再生制御部から入力したユーザ情報（パラメータ）設定ＵＲＬを解析して、このユーザ情報に対応するピリオド要素を取得して再生制御部に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

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

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

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

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

　このようにして、各々のユーザの属性、例えば性別、年齢、居住地等のユーザ情報に応じた最適な広告を選択してユーザに提供することが可能となる。

　　［８．不正アプリケーションによる不正広告の出力処理について］
　上述したように、現在開発途上のＡＴＳＣ３．０では、放送局等の番組もしくは番組関連アプリケーション等のコンテンツ提供者（もしくはコンテンツ配信サービス提供者）が提供する番組の間（もしくは前後）に広告（Ａｄ）コンテンツを挿入する方式についての検討を行っている。

　さらに、上述したように、ＤＡＳＨ規定シグナリングデータであるのＭＰＤのピリオド情報（ピリオド要素）を利用した方式についての検討が進められ、広告コンテンツの配信効果を上げるため、クライアント側での広告コンテンツの視聴者の性別、年齢、居住地等のデモグラフィック属性等のパラメータをベースとした提供広告の最適化についての検討がなされている。

　ＤＡＳＨ規格のピリオド情報を利用した広告コンテンツ挿入は、先に図１３等を参照して説明したように、図１３に示す広告対応のピリオド情報３１１内のリンク情報（ｘｌｉｎｋ）に含まれるユーザ情報設定フィールド（ｕｓｅｒ＝＄ｇｒｏｕｐＩＤ＄）にユーザ情報（パラメータ）を設定することで実現される。
　すなわち、ピリオド情報内のｘｌｉｎｋ：ｈｒｅｆ属性として付加されるｕｒｌを視聴者にとって最適な広告コンテンツに解決するアドレスとすることによって実現される。

　この最適な広告コンテンツへの解決処理（アドレス解決処理／リンク解決処理）は例えば、スクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）と呼ばれる例えば放送局等のブロードキャストプロバイダ（もしくは広告コンテンツ挿入サービスプロバイダ）が提供するブラウザ上（もしくはスクリプト実行環境）で実行されるアプリケーションプログラム（スクリプトアプリ、またはウェブアプリケーション等と呼ばれる）により実行される。
　図１４、図１５を参照して説明したシーケンス図において、アプリケーション制御部１３２が実行するアプリケーションであり、ステップＳ１３で起動し、ステップＳ１８において、リンク解決処理が実行される。

　なお、このリンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）は、放送番組に付随して、放送のような一方向ネットワーク（ブロードキャスト／マルチキャスト）により配信される場合もあれば、インターネットのような双方向ネットワークで配信される場合もある。
　リンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）の配信タイミングは、広告挿入対象となる番組のオンエアの時間内に配信される場合もあれば、番組をオンエアする前にあらかじめ受信デバイスに配信しておく場合もある。

　また、リンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）は、視聴者が番組を視聴する時（オンエア時点でリアルタイムに視聴する場合もあれば、オンエア時点とは異なる時間帯に録画もしくはダウンロードして視聴する場合もある）に番組の再生と同時に稼働する。

　先に図１４、図１５を参照したシーケンスに従って、リンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）を利用した処理を実行することで、受信装置３０において出力する広告をユーザの年齢、性別、居住地等のユーザ情報に応じた広告とすることが可能となる。

　しかし、先に図１４、図１５を参照して説明した処理シーケンスにおいて、アプリケーション制御部が実行するリンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）が、不正なアプリに置き換えられてしまう可能性がある。

　すなわち、図１４に示すステップＳ１３において、アプリケーション制御部１３２が起動するアプリが、不正なアプリに置き換えられてしまった場合、この不正なリンク解決実行アプリケーション（ＳｃｒｉｐｔＡｐｐ）の処理が行われることになる。
　リンク解決処理が不正なアプリケーションによって実行されると、本来のユーザ属性に応じた広告コンテンツではない不正な広告コンテンツが選択され、再生されることになる。

　図１５に示すステップＳ１８の処理は、アプリケーション制御部１３２が、再生制御部１３１から入力したＵＲＬに対応するピリオド要素（ピリオド情報（ピリオド要素））、すなわち広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を記録したピリオド要素を取得して再生制御部１３１に出力する処理である。

　このステップＳ１８の処理が、不正アプリによって実行されると、本来のユーザ属性に応じた広告コンテンツのアクセス情報ではない異なる広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を記録したピリオド要素が再生制御部１３１に提供される。

　再生制御部１３１は、アプリケーション制御部１３２から取得したピリオド要素に記録された広告コンテンツのアクセス情報（広告セグメントＵＲＬ）を適用して広告コンテンツを格納したセグメントを取得して再生する処理を行なうことになり、ユーザ属性と無関係の広告が出力されてしまう可能性がある。

　このように、アプリケーション制御部１３２において実行されるリンク解決処理を実行するプログラムが不正プログラムに置き換えられた場合、元々のＭＰＤを提供したブロードキャストプロバイダの意図どおりの広告が選択されず、誤った不正な広告が再生される可能性がある。
　以下では、この問題を解決する構成について説明する。

　　［９．（実施例１）アプリケーション情報テーブル（ＡＩＴ）に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について］
　まず、本開示の実施例１として、アプリケーション情報テーブル（ＡＩＴ）に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について説明する。

　　［９－１．アプリケーション情報テーブル（ＡＩＴ）に対する認証情報の記録構成について］
　最初に、アプリケーション情報テーブル（ＡＩＴ）に対する認証情報の記録構成について説明する。
　送信装置２０は、受信装置３０が実行するアプリケーションを受信装置３０に送信するとともに、送信アプリケーションのアクセス情報や、アプリケーションの属性情報、制御情報を記録した様々なシグナリングデータを受信装置３０に提供する。

　送信装置２０が受信装置３０に提供するシグナリングデータとしては、例えば、以下のデータがある。
　（１）ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｂｕｎｄｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）
　（２）Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）、
　（３）アプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）

　前述したように、ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）であり、ＵＳＤもＵＳＢＤも内容的には同じ制御情報を格納したシグナリングデータである。。

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

　アプリケーション情報テーブル（ＡＩＴ）は、１つまたは複数のアプリケーションに対応して設定されたアプリケーション固有のシグナリングデータであり、アプリケーションの取得用情報（ＵＲＬ）や、アプリ実行に適用される制御情報等が記録される。

　図１６を参照して、アプリケーション情報テーブル（ＡＩＴ）の記録データの一例について説明する。
　図１６に示すＡＩＴには、以下のデータが記録されている。
　アプリケーションＩＤ、
　アプリケーションアクセス情報（ＡｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））、
　アプリケーション実行タイミング情報、
　ＡＩＴにはこれらの他にも様々なアプリケーションの属性情報、制御情報が記録される。

　アプリケーションＩＤは、アプリケーション識別子である。
　アプリケーションアクセス情報（ＡｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））は、アプリケーションを取得するために利用されるＵＲＩである。
　アプリケーション実行タイミング情報は、受信装置３０におけるアプリケーションの実行タイミングが記録される。
　図７に示す受信装置３０のアプリケーション制御部１３２は、このアプリケーション情報テーブル（ＡＩＴ）を参照して、アプリケーションの取得、制御を行う。

　アプリケーション情報テーブル（ＡＩＴ）は、送信装置２０の提供する様々なアプリケーションに対応付けて設定され、送信装置２０から送信される。
　例えば、先に図１４～図１５を参照して説明したアプリケーション制御部１３２がステップＳ１３において起動し、ステップＳ１８におけるリンク解決処理を実行するリンク解決アプリ（スクリプト（ＳｃｒｉｐｔＡｐｐ））についてもこのアプリ対応の属性や制御情報を記録したアプリケーション情報テーブル（ＡＩＴ）が設定され、送信装置２０から受信装置３０に提供される。

　本実施例１では、このアプリケーション情報テーブル（ＡＩＴ）に、ＡＩＴに対応付けられたアプリケーションに関する認証情報を格納する。
　図１７に示すように、アプリケーション４００の属性情報や、制御情報を記録したアプリ４００対応のアプリケーション情報テーブル（ＡＩＴ）４０１に、アプリケーション認証情報４０２を記録する。

　なお、アプリケーション認証情報４０２には、例えば認証対象となるアプリケーション４００の構成データに基づいて生成されたダイジェスト値（照合用ダイジェスト値）や、ダイジェスト値を含む認証情報構成データに基づいて生成された署名が含まれる。

　受信装置３０は、アプリケーション４００を実行する前に、そのアプリケーション４００に対応付けられたアプリケーション情報テーブル（ＡＩＴ）４０１の認証情報４０２を適用した認証処理を実行する。
　具体的には、まず、認証情報４０２内の署名検証処理を実行し、署名検証成立が確認された場合、さらに検証対象となる実行予定のアプリケーション４００に基づいて新たに算出した算出ダイジェスト値と、認証情報４０２に記録された照合用ダイジェスト値との一致確認処理を実行する。

　この認証処理によって、アプリケーションが改ざんの無い正当なアプリケーションであることが確認された場合にのみ、このＡＩＴに対応付けられたアプリケーションの実行を許容する。

　例えば、受信装置３０のアプリケーション制御部１３２が図１４に示すステップＳ１３においてリンク（ｘｌｉｎｋ）解決処理用アプリケーション（スクリプトアプリ）を起動する場合、受信装置３０は、このアプリケーション（スクリプトアプリ）に対応付けられたアプリケーション情報テーブル（ＡＩＴ）を取得し、ＡＩＴに記録された認証情報を利用した認証処理を実行する。

　この認証処理によって、アプリケーション（スクリプトアプリ）が改ざんの無い正当なアプリケーションであることが確認された場合にのみ、このスクリプトアプリを適用したリンク（ｘｌｉｎｋ）解決処理を実行することができる。

　なお、認証処理によって、スクリプトアプリの正当性が確認されなかった場合は、アプリケーション制御部におけるアプリケーションの実行は中止される。

　図１７を参照して説明したように、本実施例では、アプリケーションの認証情報をアプリケーション情報テーブル（ＡＩＴ）に記録する構成としている。
　ＡＩＴにおける認証情報の記録領域の設定例について、図１８を参照して説明する。

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

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

　認証情報は、例えば、図１８に示すように、その他の識別情報（ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ）要素４１２以下に設定する。
　すなわち、以下の設定位置に認証情報を記録する設定とする。
　ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ／ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ／ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒの下に、
　新たに、認証情報記録フィールドである、
　ａｔｓｃ：ａｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ要素を導入する。

　このように、認証情報（ＡｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）を設定したアプリケーション情報テーブル（ＡＩＴ）を、ＸＭＬデータとして受信装置に提供する。

　図１９、および以下にＸＭＬデータとしてエンコーディングしたデータ例を示す。
　この例は、認証情報（ＡｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）を含むアプリケーション情報テーブル（ＡＩＴ）のデータ例である。

＜ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ　…＞　…
　＜ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ　…＞　…
　＜ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ　…＞　…
　＜ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ　…＞　…
　＜ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ　…＞　…
　＜ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ　…＞　…
　＜ａｔｓｃ：ａｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ＞
　＜Ｓｉｇｎａｔｕｒｅ＞
　＜Ｓｉｇｎｅｄｉｎｆｏ＞
　　＜ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞
　　＜ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｄｓａ－ｓｈａ１"／＞
　　＜Ｒｅｆｅｒｅｎｃｅ　ＵＲＩ＝"ｈｔｔｐ：／／ａ．ｃｏｍ／ａｐｐ．ｘｍｌ"＞
　　＜Ｔｒａｎｓｆｏｒｍｓ＞＜Ｔｒａｎｓｆｏｒｍ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞＜／Ｔｒａｎｓｆｏｒｍｓ＞
　　＜ＤｉｇｅｓｔＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
　　＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖＺｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ２４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞
　　＜／Ｒｅｆｅｒｅｎｃｅ＞
　＜／ＳｉｇｎｅｄＩｎｆｏ＞
　＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ＤｐＥｙｌｈＱｏｉＵＫＢｏＫＷｍＹｆａｊＸＯ７ＬＺｘｉＤＹｇＶｔＵｔＣＮｙＴｇｗＺｇｏＣｈｚｏｒＡ２ｎｈｋＱ＝＝＜／ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
　＜／Ｓｉｇｎａｔｕｒｅ＞
　＜／ａｔｓｃ：ａｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ＞　…
　＜／ｍｈｐ：ｏｔｈｅｒＤｅｓｃｒｉｐｔｏｒ＞　…
　＜／ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＤｅｓｃｒｉｐｔｏｒ＞　…
　＜ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ＞ｈｔｔｐ：／／ａ．ｃｏｍ／ａｐｐ．ｘｍｌ＜／ｍｈｐ：ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ＞　…
　＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞　…
　＜／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ＞　…
　＜／ｍｈｐ：ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｏｖｅｒｙ＞　…
＜／ＳｅｒｖｉｃｅＤｅｓｃｏｖｅｒｙ＞

　上記データ中、認証情報は、
　「＜Ｓｉｇｎａｔｕｒｅ＞～＜／Ｓｉｇｎａｔｕｒｅ＞」このデータ区間の領域である。

　また、この認証情報データ中、
　「＜Ｒｅｆｅｒｅｎｃｅ　ＵＲＩ＝"ｈｔｔｐ：／／ａ．ｃｏｍ／ａｐｐ．ｘｍｌ"＞」
　このデータが、認証対象となるアプリケーションを示すアプリケーション識別情報（参照ＵＲＩ）である。

　また、
　「＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖＺｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ２４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞」
　このデータが、認証情報を構成するダイジェスト値（照合用ダイジェスト値）である。

　さらに、
　「＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ＤｐＥｙｌｈＱｏｉＵＫＢｏＫＷｍＹｆａｊＸＯ７ＬＺｘｉＤＹｇＶｔＵｔＣＮｙＴｇｗＺｇｏＣｈｚｏｒＡ２ｎｈｋＱ＝＝＜／ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞」
　このデータが、署名である。署名は、署名要素を除く認証情報の構成データ、例えば、上記データ中の＜ＳｉｇｎｅｄＩｎｆｏ＞～＜／ＳｉｇｎｅｄＩｎｆｏ＞、これらのデータを対象として生成される。

　署名は、例えば、アプリケーション情報テーブル（ＡＩＴ）の生成を実行した放送局等の送信装置の秘密鍵を適用して実行される。
　署名検証処理は、、署名値を作成した送信装置の秘密鍵に対応する公開鍵を用いて実行される。
　受信装置は、送信装置の公開鍵を予め取得し、取得した公開鍵によって署名検証処理を実行する。
　なお、署名は、共通鍵暗号方式を用いて生成することも可能であり、この場合は、署名生成、検証のいずれも共通鍵を適用して実行される。

　図２０に示すフローチャートを参照して、送信装置において実行する認証情報の生成処理とアプリケーション情報テーブル（ＡＩＴ）に対する記録処理のシーケンスについて説明する。

　　（ステップＳ２１）
　送信装置のデータ処理部は、まず、ステップＳ２１において、認証情報生成対象データ、すなわちリンク解決アプリ（スクリプトアプリ）等のアプリケーションファイルを取得する。

　　（ステップＳ２２）
　送信装置のデータ処理部は、次に、ステップＳ２２において、認証情報生成対象データ（アプリケーションファイル）の正規化処理、例えば、改行データ等を削除し、実質データを抽出する処理やデータ長を調整する等の処理を含む正規化処理を実行する。

　　（ステップＳ２３）
　送信装置のデータ処理部は、次に、ステップＳ２３において、正規化された認証情報生成対象データに基づくダイジェスト値を生成する。
　例えば所定のハッシュ値生成アルゴリズムなどを適用した処理によってダイジェスト値を生成する。

　　（ステップＳ２４）
　送信装置のデータ処理部は、次に、ステップＳ２４において、ダイジェスト値の正規化処理、例えば、データ長の調整処理値等を実行し、署名値生成用ダイジェストを生成する。

　　（ステップＳ２５）
　送信装置のデータ処理部は、次に、ステップＳ２５において、正規化ダイジェストに対する署名値を生成する。
　署名は、例えば、アプリケーション情報テーブル（ＡＩＴ）の生成を実行する放送局等の送信装置の秘密鍵を適用して実行される。

　　（ステップＳ２６）
　送信装置のデータ処理部は、次に、ステップＳ２６において、生成したダイジェスト値、署名値を含む認証情報をアプリケーション情報テーブル（ＡＩＴ）に記録する。

　アプリケーション情報テーブル（ＡＩＴ）に記録される認証情報の例を図２１に示す。図２１に示す認証情報は、先に図１９を参照して説明したアプリケーション情報テーブル（ＡＩＴ）の記録データの一部、すなわち、＜Ｓｉｇｎａｔｕｔｅｒ＞～＜／Ｓｉｇｎａｔｕｒｅ＞の要素に対応する。

　この認証情報には、図２１に示すように、以下の情報が含まれる。
　（ａ）認証対象アプリ識別情報（参照ＵＲＬ）
　（ｂ）ダイジェスト値
　（ｃ）署名値

　図２１に示す認証情報の構成について、簡単に説明する。
　Ｓｉｇｎａｔｕｒｅ要素は、ＸＭＬ署名のルート要素である。
　ＳｉｇｎｅｄＩｎｆｏ要素は、署名の対象および使用するアルゴリズムを指定要素である。
　ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ要素は署名値を計算する前に、Ｓｉｇｎｅｄｉｎｆｏ要素を正規化するアルゴリズムを指定する要素である。

　ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ要素は、正規化されたＳｉｇｎｅｄｉｎｆｏ要素からＳｉｇｎａｔｕｒｅＶａｌｕｅ要素に格納する署名値を求めるアルゴリズムを指定する要素である。
　Ｒｅｆｅｒｅｎｃｅ要素（リスト）は署名される対象リソースをＵＲＩによって指定する要素である。
　Ｔｒａｎｓｆｏｒｍｓ要素は、ダイジェスト値の記録フィールドであるＤｉｇｅｓｔＶａｌｕｅ要素の値として格納される対象リソースのハッシュを計算する前にリソースに適用する変換方式を指定する要素である。

　ＤｉｇｅｓｔＭｅｔｈｏｄ要素は、ダイジェスト（ハッシュ）アルゴリズムを指定する要素である。
　ＤｉｇｅｓｔＶａｌｕｅ要素は、ＤｉｇｅｓｔＭｅｔｈｏｄ要素により指定されたハッシュアルゴリズムで計算した対象リソースのハッシュ値を格納する要素である。
　ＳｉｇｎａｔｕｒｅＶａｌｕｅ要素は、ＳｉｇｎｅｄＩｎｆｏ要素をＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ要素で指定されたアルゴリズムにより正規化した後の署名値を格納する要素である。

　なお、署名対象データは、図１９や、図２１を参照して説明したＸＭＬデータであり、署名値もＸＭＬデータとして記録される。
　このようなタイプの署名はＸＭＬ署名と呼ばれる。
　ＸＭＬ署名は，ＸＭＬ文書をはじめとするさまざまな電子データに対して付けられる電子署名である。ＸＭＬ文書によって構成される電子データにＸＭＬ署名を付ければ，その電子データの完全性が保証でき、成り済まし防止や否認防止に有効となる。

　Ｗｅｂサイトやインターネットなど、ネットワークを介してデータを送受信する場合、送受信の途中等において、第三者によってデータが改ざんされてしまうおそれがある。ＸＭＬ署名では、電子データのダイジェスト値を署名対象データに含める設定としている。

　データに追記されたＸＭＬ署名の検証により、データが改ざんされているかどうかを検証し、さらに、認証情報中に記録されたダイジェスト値（照合用ダイジェスト値）と、検証対象となるデータ（例えばアプリケーション）から新たに算出したしたダイジェスト値（算出タイジェスト値）を比較することで、検証対象となるデータ（例えばアプリケーション）の改ざんの有無を判定することができる。

　ＸＭＬ署名の種類について、図２２を参照して説明する。
　ＸＭＬ署名には、図２２に示すように、
　（ａ）エンベロープ型署名（Ｅｎｖｅｌｏｐｅｄ署名・Ｅｎｖｅｌｏｐｉｎｇ署名）
　（ｂ）デタッチ型署名（Ｄｅｔａｃｈｅｄ署名）
　これらの種類がある。

　（ａ）エンベロープ型署名は、認証対象となる文書ファイル内に認証情報が記録される形式である。
　一方、
　（ｂ）デタッチ型署名（Ｄｅｔａｃｈｅｄ署名）は、認証対象となる文書ファイルと、認証情報とは切り離された形式である。

　本実施例では、
　認証対象データは、アプリケーションであり、認証情報は、アプリケーションとは別のアプリケーション情報テーブル（ＡＩＴ）に記録される。
　すなわち、図２２に示すデタッチ型署名（Ｄｅｔａｃｈｅｄ署名）の形式を利用することができる。

　　［９－２．アプリケーション情報テーブル（ＡＩＴ）を適用したアプリケーション認証処理を実行する構成とシーケンスについて］
　次に、アプリケーション情報テーブル（ＡＩＴ）を適用したアプリケーション認証処理を実行する構成とシーケンスについて説明する。

　図２３は、受信装置３０の再生処理部１３０の構成例を示す図である。
　受信装置３０は、先に図７を参照して説明したように、
　ミドルウェア１１０、
　ＨＴＴＰプロキシサーバ１２０、
　再生処理部１３０、
　これらの構成を有する。

　図２３は、これらの構成中の再生処理部１３０の構成を示している。
　再生処理部は、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１、アプリケーション制御部１３２、出力制御部１３３を有する。

　先に、図７、図８を参照して説明したように、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１は、例えば、ＭＰＤの解析を実行し、解析結果に基づいて再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
　アプリケーション制御部１３２は、送信装置２０から提供されるアプリケーションの実行制御を行う。
　また、アプリケーションに対応付けられたアプリケーション情報テーブル（ＡＩＴ）の解析処理を実行する。

　図２３に示すように、アプリケーション制御部１３２は、
　アプリケーション検証部１５１、
　アプリケーション実行部１５２、
　これらの構成を有する。

　アプリケーション検証部１５１は、実行予定のアプリケーションに対応付けられたアプリケーション情報テーブル（ＡＩＴ）に記録された認証情報を取得して、アプリケーションが改ざんの無い、正当なアプリケーションであるか否かの検証処理を実行する。

　アプリケーション実行部１５２は、アプリケーション検証部１５１における検証処理の結果、改ざんの無い、正当なアプリケーションであると判断されたアプリケーションのみを実行する。

　アプリケーション制御部１３２は、アプリケーション検証部１５１における検証処理の結果、改ざんの無い、正当なアプリケーションであると判断されなかったアプリケーションについては、実行を中止する。

　次に、図２４～図２６に示すシーケンス図を参照して、送信装置における認証情報を記録したアプリケーション情報テーブル（ＡＩＴ）の生成、アプリケーション、およびアプリケーション情報テーブル（ＡＩＴ）の送信処理、さらに、受信装置におけるＡＩＴの認証情報を用いたアプリケーションの検証と、アプリケーションの実行までの処理シーケンスについて説明する。

　図２４～図２６には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置２０、
　（ｂ）受信装置３０の構成要素であるアプリケーション検証部１５１、
　（ｃ）受信装置３０の構成要素であるアプリケーション実行部１５２、
　（ｄ）受信装置３０構成要素である再生制御部１３１、
　以下、図２４～図２６に示す各ステップの処理について、順次、説明する。

　　（ステップＳ１０１）
　ステップＳ１０１～Ｓ１０５の処理は、送信装置２０において実行する処理である。
　すなわち、送信装置２０における認証情報を記録したアプリケーション情報テーブル（ＡＩＴ）の生成、アプリケーション、およびアプリケーション情報テーブル（ＡＩＴ）の送信処理のシーケンスである。

　まず、送信装置のデータ処理部は、まず、ステップＳ１０１において、認証情報生成対象データ、例えばリンク解決アプリ（スクリプトアプリ）等のアプリケーションファイルを取得し、証情報生成対象データ（アプリケーションファイル）の正規化処理、例えば、改行データ等を削除し、実質データを抽出する処理やデータ長を調整する等の処理を含む正規化処理を実行し、ダイジェスト生成用データを生成する。

　　（ステップＳ１０２）
　送信装置のデータ処理部は、次に、ステップＳ１０２において、ステップＳ１０１で生成したダイジェスト生成用データに基づいてダイジェスト値を生成する。
　例えば所定のハッシュ値生成アルゴリズムなどを適用した処理によってダイジェスト値を生成する。

　さらに、算出したダイジェスト値を含む署名対象情報（ＳｉｇｎｅｄＩｎｆｏ要素）を生成する。
　これは、具体的には、例えば図２１に示す認証情報中の＜ＳｉｇｎｅｄＩｎｆｏ＞～＜／ＳｉｇｎｅｄＩｎｆｏ＞の構成データを生成する処理である。

　　（ステップＳ１０３）
　送信装置のデータ処理部は、次に、ステップＳ１０３において、算出したダイジェスト値を含む署名対象情報（ＳｉｇｎｅｄＩｎｆｏ要素）に対する署名を実行する。
　署名は、例えば、アプリケーション情報テーブル（ＡＩＴ）の生成を実行する放送局等の送信装置の秘密鍵を適用して実行される。

　　（ステップＳ１０４）
　送信装置のデータ処理部は、次に、ステップＳ１０４において、生成したダイジェスト値、署名値を含む認証情報をアプリケーション情報テーブル（ＡＩＴ）に記録して、生成したＡＩＴをシグナリングデータとしてのＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）を利用して、送信する。

　前述したように、ＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）は、ＡＴＳＣ３．０サービスレイヤのシグナリングデータであり、ＡＩＴ、ＵＳＢＤ／ＵＳＤ、Ｓ－ＴＳＩＤ、ＭＰＤ等の送信に利用される。

　なお、本実施例において、このアプリケーション情報テーブル（ＡＩＴ）は、例えばリンク解決処理を実行するリンク解決アプリ（スクリプトアプリ（ＳｃｒｉｐｔＡｐｐ））の属性情報、制御情報を記録したＡＩＴである。

　　（ステップＳ１０５）
　送信装置のデータ処理部は、次に、ステップＳ１０５において、送信したアプリケーション情報テーブル（ＡＩＴ）に対応付けられたアプリケーション、例えば、リンク解決処理を実行するリンク解決アプリ（スクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）を送信する。

　以上で、送信装置２０側の処理の説明を終了し、次に、図２５、図２６を参照して、受信装置３０側の処理について説明する。

　　（ステップＳ１１１）
　図２５に示すステップＳ１１１～Ｓ１１４は、受信装置３０の再生処理部１３０のアプリケーション制御部１３２に設定されたアプリケーション検証部１５１の実行する処理である。

　まず、受信装置３０のアプリケーション検証部１５１は、ステップＳ１１１において、送信装置２０から受信したアプリケーション情報テーブル（ＡＩＴ）から、ダイジェスト値、署名値を含む認証情報を取得する。さらに、認証対象アプリケーションを特定する。

　なお、認証対象アプリケーションの特定処理は、ＡＩＴの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）、例えば図１９、図２１を参照して説明したＡＩＴの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）に基づいて実行される。

　　（ステップＳ１１２）
　次に、受信装置３０のアプリケーション検証部１５１は、ステップＳ１１２において、アプリケーション情報テーブル（ＡＩＴ）から署名値を取得し、署名検証処理を実行する。
　署名検証処理は、例えば、公開鍵暗号方式を適用した署名である場合は、署名値を作成した送信装置２０の秘密鍵に対応する公開鍵を用いて実行される。
　署名が、共通鍵暗号方式を用いて生成されている場合は、共通鍵を適用した署名検証処理が実行される。

　ステップＳ１１２における署名検証が成立し、認証情報が改ざんの無い正当な認証情報であることが確認された場合は、次の処理に進む。
　一方、署名検証不成立の場合は、以下の処理を中止する。
　この場合、このアプリケーション情報テーブル（ＡＩＴ）に対応付けられたアプリケーションの実行も中止される。

　　（ステップＳ１１３）
　次に、受信装置３０のアプリケーション検証部１５１は、ステップＳ１１３において、ステップＳ１１１で特定した認証対象アプリケーションを取得する。
　すなわち、ＡＩＴの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）に従って特定された認証対象アプリケーションを取得し、取得アプリケーションの構成データに基づくダイジェスト値を算出する。

　　（ステップＳ１１４）
　次に、受信装置３０のアプリケーション検証部１５１は、ステップＳ１１４において、ステップＳ１１３で認証対象アプリから算出した算出ダイジェスト値と、アプリケーション情報テーブル（ＡＩＴ）に記録された照合用ダイジェスト値を比較する。

　２つのダイジェスト値が一致した場合は、認証対象アプリケーションは、改ざんの無い正当なアプリケーションであると判定する。この判定がなされたことを条件として、次の処理に進む。
　一方、２つのダイジェスト値が一致しなかった場合は、認証対象アプリケーションは、改ざんのある不正なアプリケーションであると判定する。この判定がなされた場合は、以下の処理を中止する。
　この場合、このアプリケーション情報テーブル（ＡＩＴ）に対応付けられたアプリケーションの実行も中止される。

　　（ステップＳ１２１）
　図２６に示すステップＳ１２１～Ｓ１２５の処理は、図２５を参照して説明したアプリケーション検証部１５１の処理において、アプリケーション情報テーブル（ＡＩＴ）に記録された認証情報に基づくアプリケーション認証が成立した場合、すなわちＡＩＴ対応のアプリケーションが改ざんの無い正当なアプリケーションであると判断された場合にのみ実行される処理である。

　受信装置３０のアプリケーション検証部１５１は、ステップＳ１１１～Ｓ１１４におけるアプリケーション認証が成立し、ＡＩＴ対応のアプリケーションが改ざんの無い正当なアプリケーションであると判断された場合、ステップＳ１２１において、アプリケーション実行部１５２に対してアプリケーションの起動を依頼する。
　起動依頼対象アプリケーションは、ＡＩＴ記録の認証情報に基づく認証処理を行ない認証の成立したアプリケーションである。

　本例では、認証対象アプリは、リンク（ｘｌｉｎｋ）解決処理を実行するリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）であり、アプリケーション検証部１５１は、アプリケーション実行部１５２に対してリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）の起動依頼を行う。

　　（ステップＳ１２２）
　次に、受信装置３０のアプリケーション実行部１５２は、ステップＳ１２２において、アプリケーション検証部１５１から起動依頼のあったアプリケーションを起動する。
　アプリケーション実行部１５２は、認証が成立し正当性の確認されたリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）の起動処理を実行する。

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

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

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

　　（ステップＳ１２４）
　ステップＳ１２４の処理は、受信装置３０のアプリケーション実行部１５２の処理である。
　アプリケーション実行部１５２は、認証が成立し、正当性の確認されたリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）を実行して、リンク解決処理を行なう。
　すなわち、再生制御部１３１から入力したユーザ情報（パラメータ）設定ＵＲＬを解析して、このユーザ情報に対応するピリオド情報（ピリオド要素）を取得して再生制御部１３１に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

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

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

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

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

　このようにして、アプリケーション検証部１５１の実行した認証処理により正当性の確認されたリンク解決アプリケーションを実行して、各々のユーザの属性、例えば性別、年齢、居住地等のユーザ情報に応じた正しい広告が選択され、ユーザに提供することが可能となる。

　　［１０．（実施例２）ＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について］
　次に、本開示の実施例２として、送信装置２０が、受信装置３０に送信するシギナリングデータの１つであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ））に記録したアプリケーション認証情報を適用したアプリケーション認証処理を実行する構成について説明する。

　　［１０－１．ＭＰＤに対する認証情報の記録構成について］
　最初に、ＭＰＤに対する認証情報の記録構成について説明する。
　送信装置２０は、受信装置３０が実行するアプリケーションを受信装置３０に送信するとともに、送信アプリケーションのアクセス情報や、アプリケーションの属性情報、制御情報を記録した様々なシグナリングデータを受信装置３０に提供する。

　前述したように、送信装置２０が受信装置３０に提供するシグナリングデータとしては、例えば、以下のデータがある。
　（１）ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｂｕｎｄｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）
　（２）Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）、
　（３）アプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）

　ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）であり、ＵＳＤもＵＳＢＤも内容的には同じ制御情報を格納したシグナリングデータである。。

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

　先に、図７、図８を参照して説明した様に、受信装置３０の再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１は、ＭＰＤを解析して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。

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

　本実施例２は、このＭＰＤに対して、ＭＰＤに対応付けられたアプリケーションに関する認証情報を格納する。
　図２７に示すように、アプリケーション５００に対応付けられたＭＰＤ５０１に、アプリケーション認証情報５０２を記録する。
　なお、ＭＰＤには、認証対象となるアプリケーションの識別情報（参照ＵＲＬ）が記録され、１つのアプリケーションとその認証情報を記録したＭＰＤとの対応付けがなされる。

　アプリケーション認証情報５０２には、例えば認証対象となるアプリケーション５００の構成データに基づいて生成されたダイジェスト値（照合用ダイジェスト値）や、ダイジェスト値を含む認証情報構成データに基づいて生成された署名が含まれる。

　受信装置３０は、アプリケーション５００を実行する前に、そのアプリケーション５００に対応付けられたＭＰＤ５０１に記録された認証情報を適用した認証処理を実行する。
　具体的には、まず、認証情報５０２内の署名検証処理を実行し、署名検証成立が確認された場合、さらに検証対象となる実行予定のアプリケーション５００に基づいて新たに算出した算出ダイジェスト値と、認証情報５０２に記録された照合用ダイジェスト値との一致確認処理を実行する。

　この認証処理によって、アプリケーション５００が改ざんの無い正当なアプリケーションであることが確認された場合にのみ、このＭＰＤ５０１に対応付けられたアプリケーション５００の実行を許容する。

　例えば、受信装置３０のアプリケーション制御部１３２がリンク（ｘｌｉｎｋ）解決処理用アプリケーション（スクリプトアプリ）を起動する場合、このアプリケーション（スクリプトアプリ）に対応付けられたＭＰＤに記録された認証情報を利用した認証処理を実行する。

　図２７を参照して説明したように、本実施例では、アプリケーションの認証情報をＭＰＤに記録する構成としている。
　ＭＰＤにおける認証情報の記録領域の設定例について、図２８以下を参照して説明する。

　図２８は、ＭＰＤにおける認証情報設定位置の一例を説明する図である。
　図２８に示す例は、ＭＰＤ要素下に、認証情報、すなわちＳｉｇｎａｔｕｒｅ要素を設定した例である。

　認証情報は、例えば、図２８に示すように、ＭＰＤ要素５１０下に設定されるその他要素（ｏｔｈｅｒ）５１１に記録する。

　このように、認証情報（ＡｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）を設定したＭＰＤを受信装置に提供する。
　図２９、および以下に認証情報を含むＭＰＤのＸＭＬデータ例を示す。

＜ＭＰＤ・・ｉｄ＝"１２３４５"＞・・
　＜Ｐｅｒｉｏｄ・・＞・・
　　＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　　＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　＜／Ｐｅｒｉｏｄ＞・・
　＜Ｐｅｒｉｏｄ・・＞・・
　　＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　　＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　＜／Ｐｅｒｉｏｄ＞・・
　　＜Ｓｉｇｎａｔｕｒｅ＞
　　＜Ｓｉｇｎｅｄｉｎｆｏ＞
　　＜ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞
　　＜ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｄｓａ－ｓｈａ１"／＞
　　＜Ｒｅｆｅｒｅｎｃｅ　ＵＲＩ＝"ｈｔｔｐ：／／ａ．ｃｏｍ／ａｐｐ．ｘｍｌ"＞
　　　＜Ｔｒａｎｓｆｏｒｍｓ＞＜Ｔｒａｎｓｆｏｒｍ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞＜／Ｔｒａｎｓｆｏｒｍｓ＞
　　　＜ＤｉｇｅｓｔＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
　　　＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖＺｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ２４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞
　　＜／Ｒｅｆｅｒｅｎｃｅ＞
　　＜Ｒｅｆｅｒｅｎｃｅ　　ｉｄ＝"＃１２３４５"＞
　　　＜Ｔｒａｎｓｆｏｒｍ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｅｎｖｅｌｏｐｅｄ－ｓｉｇｎａｔｕｒｅ"＞
　　　＜ＤｉｇｅｓｔＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
　　　＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖｔｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ１４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞
　　＜／Ｒｅｆｅｒｅｎｃｅ＞
　＜／ＳｉｇｎｅｄＩｎｆｏ＞
　＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ＤｐＥｙｌｈＱｏｉＵＫＢｏＫＷｍＺｆａｊＸＯ７ＬＺｘｉＤＹｇＶｔＵｔＣＮｙＴｇｗＺｇｏＣｈｚｏｒＡ２ｎｈｋＱ＝＝＜／ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
　＜／Ｓｉｇｎａｔｕｒｅ＞
＜／ＭＰＤ　＞

　また、
　「＜Ｒｅｆｅｒｅｎｃｅ　　ｉｄ＝"＃１２３４５"＞」
　このデータが、このＭＰＤの識別情報（ＩＤ）である。

　署名は、例えば、ＭＰＤの生成を実行した放送局等の送信装置の秘密鍵を適用して実行される。
　署名検証処理は、、署名値を作成した送信装置の秘密鍵に対応する公開鍵を用いて実行される。
　受信装置は、送信装置の公開鍵を予め取得し、取得した公開鍵によって署名検証処理を実行する。
　なお、署名は、共通鍵暗号方式を用いて生成することも可能であり、この場合は、署名生成、検証のいずれも共通鍵を適用して実行される。

　図３０に、ＭＰＤにおける認証情報設定位置の第２例を説明する図を示す。
　図３０に示す例は、ＭＰＤ要素下のピリオド（Ｐｅｒｉｏｄ）要素下に、認証情報、すなわちＳｉｇｎａｔｕｒｅ要素を設定した例である。

　認証情報は、図３０に示すように、ＭＰＤ要素５１０下に設定されるピリオド（Ｐｅｒｉｏｄ）要素５２１下のその他要素（ｏｔｈｅｒ）５２２に記録する。

　このように、認証情報（ＡｐｐｌｉｃａｔｉｏｎＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）をピリオド要素下に設定したＭＰＤを受信装置に提供してもよい。
　図３１、および以下に認証情報を含むＭＰＤのＸＭＬデータ例を示す。

＜ＭＰＤ・・＞・・
　＜Ｐｅｒｉｏｄ・・＞・・
　　＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　　＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　＜／Ｐｅｒｉｏｄ＞・・
　＜Ｐｅｒｉｏｄ・・ｘｌｉｎｋ：ｈｒｅｆ＝'ｈｔｔｐ：／／ａ．ｃｏｍ／ａｄｐ－１'　　ｉｄ＝"４５６７８"＞・・
　　＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　　＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞・・
　　　＜Ｓｉｇｎａｔｕｒｅ＞
　　　＜Ｓｉｇｎｅｄｉｎｆｏ＞
　　　＜ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞
　　　＜ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｄｓａ－ｓｈａ１"／＞
　　　＜Ｒｅｆｅｒｅｎｃｅ　ＵＲＩ＝"ｈｔｔｐ：／／ａ．ｃｏｍ／ａｐｐ．ｘｍｌ"＞
　　　＜Ｔｒａｎｓｆｏｒｍｓ＞＜Ｔｒａｎｓｆｏｒｍ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＲＥＣ－ｘｍｌ－ｃ１４ｎ－２００１０３１５＃ＷｉｔｈＣｏｍｍｅｎｔｓ"／＞＜／Ｔｒａｎｓｆｏｒｍｓ＞
　　　＜ＤｉｇｅｓｔＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
　　　＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖＺｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ２４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞
　　＜／Ｒｅｆｅｒｅｎｃｅ＞
　　＜Ｒｅｆｅｒｅｎｃｅ　　ｉｄ＝"＃４５６７８"＞
　　　＜Ｔｒａｎｓｆｏｒｍ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｅｎｖｅｌｏｐｅｄ－ｓｉｇｎａｔｕｒｅ"＞
　　　＜ＤｉｇｅｓｔＭｅｔｈｏｄ　Ａｌｇｏｒｉｔｈｍ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１"／＞
　　　＜ＤｉｇｅｓｔＶａｌｕｅ＞６０ＮｖｔｖｔｄＴＢ＋７ＵｎｌＬｐ／Ｈ１４ｐ７ｈ４ｂｓ＝＜／ＤｉｇｅｓｔＶａｌｕｅ＞
　　＜／Ｒｅｆｅｒｅｎｃｅ＞
　　＜／ＳｉｇｎｅｄＩｎｆｏ＞
　　＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞ＤｐＥｙｌｈＱｏｉＵＫＢｏＫＷｍＺｆａｊＸＯ７ＬＺｘｉＤＹｇＶｔＵｔＣＮｙＴｇｗＺｇｏＣｈｚｏｒＡ２ｎｈｋＱ＝＝＜／ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞
　　＜／Ｓｉｇｎａｔｕｒｅ＞
　＜／Ｐｅｒｉｏｄ＞・・
＜／ＭＰＤ　＞

　また、
　「＜Ｒｅｆｅｒｅｎｃｅ　　ｉｄ＝"＃４５６７８"＞」
　このデータが、認証情報を記録したＭＰＤの１つのピリオドの識別情報（ＩＤ）である。

　図２９、図３１に示すＭＰＤに記録する認証情報の構成要素には、先に説明したＡＩＴ内に記録される認証情報と同様、以下の情報が含まれる。
　（ａ）認証対象アプリ識別情報（参照ＵＲＬ）
　（ｂ）ダイジェスト値
　（ｃ）署名値
　この他、先に図２１を参照して説明したと同様のデータ、例えば、署名アルゴリズム、正規化アルゴリズム、ダイジェスト値生成アルゴリズム等のデータが記録される。

　なお、署名は、先に図２２を参照して説明したＸＭＬ署名が利用される。例えば、図２２に示すように、
　（ａ）エンベロープ型署名（Ｅｎｖｅｌｏｐｅｄ署名・Ｅｎｖｅｌｏｐｉｎｇ署名）
　（ｂ）デタッチ型署名（Ｄｅｔａｃｈｅｄ署名）
　これらのいずれかのタイプの署名が利用されることになる。

　　［１０－２．ＭＰＤを適用したアプリケーション認証処理を実行する構成とシーケンスについて］
　次に、ＭＰＤを適用したアプリケーション認証処理を実行する構成とシーケンスについて説明する。

　図３２は、受信装置３０の再生処理部１３０の構成例を示す図である。
　受信装置３０は、先に図７を参照して説明したように、
　ミドルウェア１１０、
　ＨＴＴＰプロキシサーバ１２０、
　再生処理部１３０、
　これらの構成を有する。

　図３２は、これらの構成中の再生処理部１３０の構成を示している。
　再生処理部は、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１、アプリケーション制御部１３２、出力制御部１３３を有する。

　先に、図７、図８を参照して説明したように、再生制御部（（Ｅｍｂｅｄｅｄ）　Ｍｅｄｉａ　Ｐｌａｙｅｒ）１３１は、例えば、ＭＰＤの解析を実行し、解析結果に基づいて再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
　アプリケーション制御部１３２は、送信装置２０から提供されるアプリケーションの実行制御を行う。
　また、アプリケーションに対応付けられたＭＰＤの解析処理を実行する。

　図３２に示すように、本実施例では、ＭＰＤ解析を実行する再生制御部１３１に、
　アプリケーション検証部６０１を有する。

　アプリケーション検証部６０１は、実行予定のアプリケーションに対応付けられたＭＰＤに記録された認証情報を取得して、アプリケーションが改ざんの無い、正当なアプリケーションであるか否かの検証処理を実行する。

　アプリケーション制御部１３２は、アプリケーション検証部６０１における検証処理の結果、改ざんの無い、正当なアプリケーションであると判断されたアプリケーションのみを実行する。

　アプリケーション制御部１３２は、アプリケーション検証部６０１における検証処理の結果、改ざんの無い、正当なアプリケーションであると判断されなかったアプリケーションについては、実行を中止する。

　次に、図３３～図３５に示すシーケンス図を参照して、送信装置における認証情報を記録したＭＰＤの生成、アプリケーション、およびＭＰＤの送信処理、さらに、受信装置におけるＭＰＤの認証情報を用いたアプリケーションの検証と、アプリケーションの実行までの処理シーケンスについて説明する。

　図３３～図３５には、左から以下の各装置、構成要素を示している。
　（ａ）送信装置２０、
　（ｂ）受信装置３０の構成要素であるアプリケーション制御部１３２、
　（ｃ）受信装置３０の構成要素である再生制御部１３１のアプリケーション検証部６０１、
　（ｄ）受信装置３０構成要素である再生制御部１３１、
　以下、図３３～図３５に示す各ステップの処理について、順次、説明する。

　　（ステップＳ２０１）
　ステップＳ２０１～Ｓ２０５の処理は、送信装置２０において実行する処理である。
　すなわち、送信装置２０における認証情報を記録したＭＰＤの生成、アプリケーション、およびＭＰＤの送信処理のシーケンスである。

　まず、送信装置のデータ処理部は、まず、ステップＳ２０１において、認証情報生成対象データ、例えばリンク解決アプリ（スクリプトアプリ）等のアプリケーションファイルを取得し、証情報生成対象データ（アプリケーションファイル）の正規化処理、例えば、改行データ等を削除し、実質データを抽出する処理やデータ長を調整する等の処理を含む正規化処理を実行し、ダイジェスト生成用データを生成する。

　　（ステップＳ２０２）
　送信装置のデータ処理部は、次に、ステップＳ２０２において、ステップＳ２０１で生成したダイジェスト生成用データに基づいてダイジェスト値を生成する。
　例えば所定のハッシュ値生成アルゴリズムなどを適用した処理によってダイジェスト値を生成する。

　さらに、算出したダイジェスト値を含む署名対象情報（ＳｉｇｎｅｄＩｎｆｏ要素）を生成する。
　これは、具体的には、例えば図２９、図３１に示す認証情報中の＜ＳｉｇｎｅｄＩｎｆｏ＞～＜／ＳｉｇｎｅｄＩｎｆｏ＞の構成データを生成する処理である。

　　（ステップＳ２０３）
　送信装置のデータ処理部は、次に、ステップＳ２０３において、算出したダイジェスト値を含む署名対象情報（ＳｉｇｎｅｄＩｎｆｏ要素）に対する署名を実行する。
　署名は、例えば、ＭＰＤの生成を実行する放送局等の送信装置の秘密鍵を適用して実行される。

　　（ステップＳ２０４）
　送信装置のデータ処理部は、次に、ステップＳ２０４において、生成したダイジェスト値、署名値を含む認証情報をＭＰＤに記録して、生成したＭＰＤをシグナリングデータとしてのＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）を利用して、送信する。

　前述したように、ＳＬＳ（Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）は、ＡＴＳＣ３．０サービスレイヤのシグナリングデータであり、ＭＰＤ、ＵＳＢＤ／ＵＳＤ、Ｓ－ＴＳＩＤ、ＭＰＤ等の送信に利用される。

　なお、本実施例において、このＭＰＤは、例えばリンク解決処理を実行するリンク解決アプリ（スクリプトアプリ（ＳｃｒｉｐｔＡｐｐ））の属性情報、制御情報を記録したＭＰＤである。

　　（ステップＳ２０５）
　送信装置のデータ処理部は、次に、ステップＳ２０５において、送信したＭＰＤに対応付けられたアプリケーション、例えば、リンク解決処理を実行するリンク解決アプリ（スクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）を送信する。

　以上で、送信装置２０側の処理の説明を終了し、次に、図３４、図３５を参照して、受信装置３０側の処理について説明する。

　　（ステップＳ２１１）
　図３４に示すステップＳ２１１～Ｓ２１４は、受信装置３０の再生処理部１３０の再生制御部１３１に設定されたアプリケーション検証部６０１の実行する処理である。

　まず、受信装置３０のアプリケーション検証部６０１は、ステップＳ２１１において、送信装置２０から受信したＭＰＤから、ダイジェスト値、署名値を含む認証情報を取得する。さらに、認証対象アプリケーションを特定する。

　なお、認証対象アプリケーションの特定処理は、ＭＰＤの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）、例えば図２９、図３１を参照して説明したＭＰＤの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）に基づいて実行される。

　　（ステップＳ２１２）
　次に、受信装置３０のアプリケーション検証部６０１は、ステップＳ２１２において、ＭＰＤから署名値を取得し、署名検証処理を実行する。
　署名検証処理は、例えば、公開鍵暗号方式を適用した署名である場合は、署名値を作成した送信装置２０の秘密鍵に対応する公開鍵を用いて実行される。
　署名が、共通鍵暗号方式を用いて生成されている場合は、共通鍵を適用した署名検証処理が実行される。

　ステップＳ２１２における署名検証が成立し、認証情報が改ざんの無い正当な認証情報であることが確認された場合は、次の処理に進む。
　一方、署名検証不成立の場合は、以下の処理を中止する。
　この場合、このＭＰＤに対応付けられたアプリケーションの実行も中止される。

　　（ステップＳ２１３）
　次に、受信装置３０のアプリケーション検証部６０１は、ステップＳ２１３において、ステップＳ２１１で特定した認証対象アプリケーションを取得する。
　すなわち、ＭＰＤの認証情報内に記録された認証対象アプリ識別情報（参照ＵＲＩ）に従って特定された認証対象アプリケーションを取得し、取得アプリケーションの構成データに基づくダイジェスト値を算出する。

　　（ステップＳ２１４）
　次に、受信装置３０のアプリケーション検証部６０１は、ステップＳ２１４において、ステップＳ２１３で認証対象アプリから算出した算出ダイジェスト値と、ＭＰＤに記録された照合用ダイジェスト値を比較する。

　２つのダイジェスト値が一致した場合は、認証対象アプリケーションは、改ざんの無い正当なアプリケーションであると判定する。この判定がなされたことを条件として、次の処理に進む。
　一方、２つのダイジェスト値が一致しなかった場合は、認証対象アプリケーションは、改ざんのある不正なアプリケーションであると判定する。この判定がなされた場合は、以下の処理を中止する。
　この場合、このＭＰＤに対応付けられたアプリケーションの実行も中止される。

　　（ステップＳ２２１）
　図３５に示すステップＳ２２１～Ｓ２２５の処理は、図３４を参照して説明したアプリケーション検証部６０１の処理において、ＭＰＤに記録された認証情報に基づくアプリケーション認証が成立した場合、すなわちＭＰＤ対応のアプリケーションが改ざんの無い正当なアプリケーションであると判断された場合にのみ実行される処理である。

　受信装置３０のアプリケーション検証部６０１は、ステップＳ２１１～Ｓ２１４におけるアプリケーション認証が成立し、ＭＰＤ対応のアプリケーションが改ざんの無い正当なアプリケーションであると判断された場合、ステップＳ２２１において、アプリケーション制御部１３２に対してアプリケーションの起動を依頼する。
　起動依頼対象アプリケーションは、ＭＰＤ記録の認証情報に基づく認証処理を行ない認証の成立したアプリケーションである。

　本例では、認証対象アプリは、リンク（ｘｌｉｎｋ）解決処理を実行するリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）であり、アプリケーション検証部６０１は、アプリケーション制御部１３２に対してリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）の起動依頼を行う。

　　（ステップＳ２２２）
　次に、受信装置３０のアプリケーション制御部１３２は、ステップＳ２２２において、アプリケーション検証部６０１から起動依頼のあったアプリケーションを起動する。
　アプリケーション制御部１３２は、認証が成立し正当性の確認されたリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）の起動処理を実行する。

　　（ステップＳ２２３）
　ステップＳ２２３は、受信装置の再生制御部１３１の処理である。
　受信装置３０の再生制御部１３１は、送信装置２０の送信したＭＰＤを取得し、取得したＭＰＤの解析を実行する。
　なお、このＭＰＤは、ステップＳ２１１～Ｓ２１４において認証情報に基づくアプリ認証を行ったＭＰＤ、すなわち、認証情報を記録したＭＰＤと同じＭＰＤとなる。

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

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

　　（ステップＳ２２４）
　ステップＳ２２４の処理は、受信装置３０のアプリケーション制御部１３２の処理である。
　アプリケーション制御部１３２は、認証が成立し、正当性の確認されたリンク解決アプリ（ＳｃｒｉｐｔＡｐｐ）を実行して、リンク解決処理を行なう。
　すなわち、再生制御部１３１から入力したユーザ情報（パラメータ）設定ＵＲＬを解析して、このユーザ情報に対応するピリオド情報（ピリオド要素）を取得して再生制御部１３１に出力する。
　この出力処理は、例えばＨＴＴＰ－レスポンスとして実行される。

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

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

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

　このようにして、アプリケーション検証部６０１の実行した認証処理により正当性の確認されたリンク解決アプリケーションを実行して、各々のユーザの属性、例えば性別、年齢、居住地等のユーザ情報に応じた正しい広告が選択され、ユーザに提供することが可能となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信する通信部と、
　前記アプリケーションを実行するデータ処理部を有し、
　前記データ処理部は、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証部と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するアプリケーション実行部を有する受信装置。

　（２）　前記アプリケーションは、
　ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションである（１）に記載の受信装置。

　（３）　前記アプリケーションは、
　受信装置に提供されるデータ中のユーザ情報設定領域にユーザ情報を設定したユーザ情報設定済みデータに基づいて、ユーザ情報対応コンテンツの制御情報を選択するリンク解決処理を実行するアプリケーションである（１）または（２）に記載の受信装置。

　（４）　前記ユーザ情報対応コンテンツの制御情報は、
　シグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）内のピリオド要素である（３）に記載の受信装置。

　（５）　前記認証情報は、
　アプリケーション対応の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記録されており、
　前記アプリケーション検証部は、
　アプリケーション情報テーブル（ＡＩＴ）から認証情報を抽出してアプリケーションの正当性確認処理としての認証処理を実行する（１）～（４）いずれかに記載の受信装置。

　（６）　前記認証情報は、
　アプリケーションに対応付けられたＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に記録されており、
　前記アプリケーション検証部は、
　ＭＰＤから認証情報を抽出してアプリケーションの正当性確認処理としての認証処理を実行する（１）～（４）いずれかに記載の受信装置。

　（７）　前記認証情報は、
　認証対象のアプリケーションの構成データに基づくダイジェスト値を含み。
　前記アプリケーション検証部は、
　認証対象となるアプリケーションの構成データに基づいて算出した算出ダイジェスト値と、前記認証情報中に記録されたダイジェスト値の照合処理を実行する（１）～（６）いずれかに記載の受信装置。

　（８）　前記認証情報は、
　前記ダイジェスト値を含むデータに対して設定された署名データを含み。
　前記アプリケーション検証部は、
　前記署名データを適用した署名検証処理を実行する（７）に記載の受信装置。

　（９）　前記認証情報は、
　認証対象となるアプリケーションのアプリケーション識別子を含み、
　前記アプリケーション検証部は、
　前記アプリケーション識別子に基づいて、認証対象のアプリケーションを特定する（１）～（８）いずれかに記載の受信装置。

　（１０）　前記アプリケーション検証部は、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性が確認されたことを条件として、前記アプリケーション実行部にアプリケーション起動依頼を出力する（１）～（９）いずれかに記載の受信装置。

　（１１）　前記アプリケーションはブラウザ上で実行されるスクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）である（１）～（１０）いずれかに記載の受信装置。

　（１２）　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する通信部を有する送信装置。

　（１３）　前記送信装置は、さらに、
　前記認証情報を記録したシグナリングデータを生成するデータ処理部を有する（１２）に記載の送信装置。

　（１４）　前記アプリケーションは、
　ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションである（１２）または（１３）に記載の送信装置。

　（１５）　前記データ処理部は、
　アプリケーション対応の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に認証情報を記録する（１３）に記載の送信装置。

　（１６）　前記データ処理部は、
　アプリケーションに対応付けられたＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に認証情報を記録する（１３）に記載の送信装置。

　（１７）　前記認証情報は、
　認証対象のアプリケーションの構成データに基づくダイジェスト値と、
　前記ダイジェスト値を含むデータに対して設定された署名データと、
　認証対象となるアプリケーションのアプリケーション識別子を含む（１２）～（１６）いずれかに記載の送信装置。

　（１８）　前記アプリケーションはブラウザ上で実行されるスクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）である（１２）～（１７）いずれかに記載の送信装置。

　（１９）　受信装置において実行するデータ処理方法であり、
　通信部が、アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信し、
　データ処理部が、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証処理と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するデータ処理方法。

　（２０）　送信装置において実行するデータ処理方法であり、
　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信するデータ処理方法。

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

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

　以上、説明したように、本開示の一実施例の構成によれば、アプリケーションの正当性を確認したことを条件としてアプリケーションを実行させる構成が実現される。
　具体的には、送信装置が、アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する。受信装置は、これらのデータを受信し、認証情報に基づく認証処理を実行し、アプリケーションの正当性を確認し、正当性が確認されたアプリケーションを実行する。アプリケーションは、ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションであり、ユーザ情報に応じた正しい広告を確実にユーザに提供することが可能となる。
　本構成により、受信装置において、アプリケーションの正当性を確認したことを条件としてアプリケーションを実行させる構成が実現される。
　例えば、広告選択処理を実行するアプリの正当性を確認させることで、受信装置側のユーザに応じた広告等のコンテンツを間違いなく選択出力する構成が実現される。

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

Claims

　アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信する通信部と、
　前記アプリケーションを実行するデータ処理部を有し、
　前記データ処理部は、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証部と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するアプリケーション実行部を有する受信装置。
　前記アプリケーションは、
　ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションである請求項１に記載の受信装置。
　前記アプリケーションは、
　受信装置に提供されるデータ中のユーザ情報設定領域にユーザ情報を設定したユーザ情報設定済みデータに基づいて、ユーザ情報対応コンテンツの制御情報を選択するリンク解決処理を実行するアプリケーションである請求項１に記載の受信装置。
　前記ユーザ情報対応コンテンツの制御情報は、
　シグナリングデータであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）内のピリオド要素である請求項３に記載の受信装置。
　前記認証情報は、
　アプリケーション対応の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に記録されており、
　前記アプリケーション検証部は、
　アプリケーション情報テーブル（ＡＩＴ）から認証情報を抽出してアプリケーションの正当性確認処理としての認証処理を実行する請求項１に記載の受信装置。
　前記認証情報は、
　アプリケーションに対応付けられたＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に記録されており、
　前記アプリケーション検証部は、
　ＭＰＤから認証情報を抽出してアプリケーションの正当性確認処理としての認証処理を実行する請求項１に記載の受信装置。
　前記認証情報は、
　認証対象のアプリケーションの構成データに基づくダイジェスト値を含み。
　前記アプリケーション検証部は、
　認証対象となるアプリケーションの構成データに基づいて算出した算出ダイジェスト値と、前記認証情報中に記録されたダイジェスト値の照合処理を実行する請求項１に記載の受信装置。
　前記認証情報は、
　前記ダイジェスト値を含むデータに対して設定された署名データを含み。
　前記アプリケーション検証部は、
　前記署名データを適用した署名検証処理を実行する請求項７に記載の受信装置。
　前記認証情報は、
　認証対象となるアプリケーションのアプリケーション識別子を含み、
　前記アプリケーション検証部は、
　前記アプリケーション識別子に基づいて、認証対象のアプリケーションを特定する請求項１に記載の受信装置。
　前記アプリケーション検証部は、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性が確認されたことを条件として、前記アプリケーション実行部にアプリケーション起動依頼を出力する請求項１に記載の受信装置。
　前記アプリケーションはブラウザ上で実行されるスクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）である請求項１に記載の受信装置。
　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信する通信部を有する送信装置。
　前記送信装置は、さらに、
　前記認証情報を記録したシグナリングデータを生成するデータ処理部を有する請求項１２に記載の送信装置。
　前記アプリケーションは、
　ユーザ情報に応じた広告コンテンツの選択処理に利用されるアプリケーションである請求項１２に記載の送信装置。
　前記データ処理部は、
　アプリケーション対応の制御情報を記録したアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）に認証情報を記録する請求項１３に記載の送信装置。
　前記データ処理部は、
　アプリケーションに対応付けられたＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に認証情報を記録する請求項１３に記載の送信装置。
　前記認証情報は、
　認証対象のアプリケーションの構成データに基づくダイジェスト値と、
　前記ダイジェスト値を含むデータに対して設定された署名データと、
　認証対象となるアプリケーションのアプリケーション識別子を含む請求項１２に記載の送信装置。
　前記アプリケーションはブラウザ上で実行されるスクリプトアプリ（ＳｃｒｉｐｔＡｐｐ）である請求項１２に記載の送信装置。
　受信装置において実行するデータ処理方法であり、
　通信部が、アプリケーション、および該アプリケーションの認証情報を記録したシグナリングデータを受信し、
　データ処理部が、
　前記認証情報に基づく認証処理を実行し、前記アプリケーションの正当性を確認するアプリケーション検証処理と、
　前記認証処理によって正当性が確認されたアプリケーションを実行するデータ処理方法。
　送信装置において実行するデータ処理方法であり、
　アプリケーション、および該アプリケーションの正当性を確認可能とした認証情報を記録したシグナリングデータを送信するデータ処理方法。