(57)【要約】  本技術は、エンドユーザの嗜好に応じたコンテンツを提供することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置が、エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、コンテンツとともに配信される、質問を表す質問情報を処理することで、エンドユーザの嗜好に応じたコンテンツを提供する。本技術は、例えば、テレビ受像機に適用することができる。
2018074265.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報を処理する処理部と
を備える受信装置。
【請求項２】
前記処理部は、
前記第１の回答情報を生成し、
前記第１の回答情報と、前記質問に対して前記コンテンツを提供する提供者により設定された回答を表す第２の回答情報とのマッチング処理を行い、
前記マッチング処理の結果に従い、前記コンテンツのフィルタリング処理を行う
請求項１に記載の受信装置。
【請求項３】
前記処理部は、前記配信情報に基づいて、前記サービスを特定する
請求項２に記載の受信装置。
【請求項４】
前記配信情報は、前記コンテンツとともに配信される制御情報に含まれ、
前記処理部は、前記制御情報に含まれる前記配信情報に基づいて、前記サービスで配信される前記質問情報を取得する
請求項３に記載の受信装置。
【請求項５】
前記配信情報は、前記コンテンツに対して事前に配信される番組情報に含まれ、
前記処理部は、前記番組情報に含まれる前記配信情報に基づいて、前記サービスの配信を事前に通知する
請求項３に記載の受信装置。
【請求項６】
前記処理部は、前記参照情報に基づいて、前記アプリケーションを取得して起動することで、前記第１の回答情報を生成する
請求項２に記載の受信装置。
【請求項７】
前記参照情報は、前記サービスを配信するためのセッションの制御情報に含まれ、
前記処理部は、前記制御情報に含まれる前記参照情報に基づいて、前記アプリケーションを取得する
請求項６に記載の受信装置。
【請求項８】
前記参照情報は、前記サービスを配信するためのセッションで配信される前記質問情報のファイルのヘッダに含まれ、
前記処理部は、前記ヘッダに含まれる前記参照情報に基づいて、前記アプリケーションを取得する
請求項６に記載の受信装置。
【請求項９】
前記コンテンツは、IP(Internet Protocol)伝送方式を用いたデジタル放送により放送配信される
請求項１に記載の受信装置。
【請求項１０】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報を処理する
ステップを含むデータ処理方法。
【請求項１１】
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報を生成する生成部と、
コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報を送信する送信部と
を備える送信装置。
【請求項１２】
前記生成部は、前記質問に対してコンテンツを提供する提供者により設定された回答を表す第２の回答情報であって、前記第１の回答情報とのマッチング処理に用いられる前記第２の回答情報を生成し、
前記送信部は、前記第２の回答情報を送信する
請求項１１に記載の送信装置。
【請求項１３】
前記配信情報は、前記コンテンツとともに配信される制御情報に含まれる
請求項１２に記載の送信装置。
【請求項１４】
前記配信情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
請求項１２に記載の送信装置。
【請求項１５】
前記参照情報は、前記サービスを配信するためのセッションの制御情報に含まれる
請求項１２に記載の送信装置。
【請求項１６】
前記参照情報は、前記サービスを配信するためのセッションで配信される前記質問情報のファイルのヘッダに含まれる
請求項１２に記載の送信装置。
【請求項１７】
前記第２の回答情報は、前記コンテンツとともに配信される制御情報に含まれる
請求項１２に記載の送信装置。
【請求項１８】
前記第２の回答情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
請求項１２に記載の送信装置。
【請求項１９】
前記コンテンツは、IP伝送方式を用いたデジタル放送により放送配信される
請求項１１に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報を生成し、
コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報を送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、エンドユーザの嗜好に応じたコンテンツを提供することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
各国のデジタル放送の規格では、伝送方式としてMPEG2-TS（Moving Picture Experts Group phase 2 - Transport Stream）方式が採用されているが、今後は、通信の分野で用いられているIP（Internet Protocol）パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。【０００３】
例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用することが決定されている（非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ATSC Candidate Standard: Link-Layer Protocol (A/330)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、IP伝送方式を用いたデジタル放送においては、エンドユーザの嗜好に応じたコンテンツを提供できるようにしたいという要求が想定されるが、現状では、エンドユーザの嗜好に応じたコンテンツを提供するための技術方式は確立されていない。【０００６】
本技術はこのような状況に鑑みてなされたものであり、エンドユーザの嗜好に応じたコンテンツを提供することができるようにするものである。
【課題を解決するための手段】
【０００７】
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報を処理する処理部とを備える受信装置である。【０００８】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００９】
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報が処理される。【００１０】
本技術の第２の側面の送信装置は、エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報を生成する生成部と、コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報を送信する送信部とを備える送信装置である。【００１１】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１２】
本技術の第２の側面の送信装置、及び、データ処理方法においては、エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報が生成され、コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報が送信される。
【発明の効果】
【００１３】
本技術の第１の側面、及び、第２の側面によれば、エンドユーザの嗜好に応じたコンテンツを提供することができる。【００１４】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示すブロック図である。
【図２】各サーバの構成例を示すブロック図である。
【図３】クライアント装置の構成例を示すブロック図である。
【図４】処理部の構成の詳細を示すブロック図である。
【図５】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図６】一般的なコンテンツの配信サービスでのコンテンツフィルタリングの例を示す図である。
【図７】理想的なコンテンツの配信サービスでのコンテンツフィルタリングの例を示す図である。
【図８】PDIスキーマの例を示す図である。
【図９】PDIスキーマの例を示す図である。
【図１０】PDIスキーマの例を示す図である。
【図１１】PDI-Qの記述例を示す図である。
【図１２】質問と回答の画面の例を示す図である。
【図１３】PDI-Aの記述例を示す図である。
【図１４】メタデータに含まれるPDI-Aの例を示す図である。
【図１５】PDIの全体像を示す図である。
【図１６】第１のPDI処理方式の全体像を示す図である。
【図１７】SLTメタデータのserviceCategory属性の値の例を示す図である。
【図１８】SLTメタデータの記述例を示す図である。
【図１９】ESGのServiceType要素の値の例を示す図である。
【図２０】ESG情報の記述例を示す図である。
【図２１】PDI配信サービスが利用可能である場合のXMLフラグメントの関係を示す図である。
【図２２】ESGサービスの画面の表示例を示す図である。
【図２３】ファイルモード配信の場合に、EFDTパラメータを拡張するときの例を示す図である。
【図２４】拡張されたEFDTスキーマの例を示す図である。
【図２５】エンティティモード配信の場合に、HTTPヘッダを拡張するときの例を示す図である。
【図２６】第１のPDI処理方式（パターン１）の場合の送信側と受信側の各装置で実行されPDI対応処理の流れを説明するフローチャートである。
【図２７】PDI配信サービスの画面の表示例を示す図である。
【図２８】第１のPDI処理方式（パターン２）の場合の送信側と受信側の各装置で実行されるPDI対応処理の流れを説明するフローチャートである。
【図２９】第１のPDI処理方式（パターン２）の場合の送信側と受信側の各装置で実行されるPDI対応処理の流れを説明するフローチャートである。
【図３０】第２のPDI処理方式の全体像を示す図である。
【図３１】PDI-SアプリケーションとPDI-Qの配信の詳細を示す図である。
【図３２】第２のPDI処理方式の場合の送信側と受信側の各装置で実行されるPDI対応処理の流れを説明する。
【図３３】PDIを利用したコンテンツフィルタリング処理の流れを説明するフローチャートである。
【図３４】PDIを利用したコンテンツフィルタリング処理の流れを説明するフローチャートである。
【図３５】PDI配信サービスの画面の表示例を示す図である。
【図３６】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１７】
１．システムの構成
２．本技術の概要
３．PDI対応処理
（１）第１のPDI処理方式
（１−１）配信情報の配信方法
（１−２）参照情報の配信方法
（１−３）パターン１のPDI対応処理
（１−４）パターン２のPDI対応処理
（２）第２のPDI処理方式
（３）PDIを利用したコンテンツフィルタリング処理
４．変形例
５．コンピュータの構成
【００１８】
＜１．システムの構成＞
【００１９】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示すブロック図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００２０】
図１において、伝送システム１は、送信側システム１０と、受信側のクライアント装置２０から構成される。伝送システム１においては、送信側システム１０から送信されるデータが、放送網としての伝送路４０、又は通信網としてのインターネット５０を介してクライアント装置２０により受信される。
【００２１】
送信側システム１０は、コンテンツサーバ１０１、PDIサーバ１０２、ESGサーバ１０３、メタデータサーバ１０４、アプリケーションサーバ１０５、放送サーバ１０６、及び通信サーバ１０７から構成される。
【００２２】
コンテンツサーバ１０１は、番組等のコンテンツを処理し、コンテンツのストリームデータを、放送サーバ１０６又は通信サーバ１０７に送信する。
【００２３】
PDIサーバ１０２は、PDI-Qを生成し、メタデータサーバ１０４及びアプリケーションサーバ１０５に送信する。
【００２４】
ここで、PDI(Preference Demographic and Interest)は、エンドユーザへの質問とそれに対する回答で構成される、エンドユーザの嗜好等を表現する動的なメタデータ機構である。なお、PDIの詳細は、図６乃至図１５を参照して後述するが、PDIとしては、PDI-Qと、PDI-Aと、PDI-Sがある。
【００２５】
PDI-Q(Question)は、エンドユーザの嗜好についての質問を表す情報（以下、質問情報ともいう）である。PDI-A(Answer)は、PDI-Qの質問に対して設定された回答を表す情報（以下、回答情報ともいう）である。PDI-S(Script)は、PDI-Aを取得するためのスクリプトを表している。以下、このPDI-Sに対応したアプリケーションを、PDI-Sアプリケーションと称する。
【００２６】
ESGサーバ１０３は、ESG(Electronic Service Guide)情報を生成し、メタデータサーバ１０４に送信する。なお、詳細は、図５等を参照して後述するが、ESG情報は、番組情報である。
【００２７】
メタデータサーバ１０４は、制御情報（シグナリング）を生成し、放送サーバ１０６又は通信サーバ１０７に送信する。また、メタデータサーバ１０４は、PDIサーバ１０２からのPDI-Qや、ESGサーバ１０３からのESG情報を処理し、その結果得られるデータを、放送サーバ１０６又は通信サーバ１０７に送信することができる。
【００２８】
アプリケーションサーバ１０５は、アプリケーションを生成し、放送サーバ１０６又は通信サーバ１０７に送信する。例えば、アプリケーションサーバ１０５は、PDIサーバ１０２からのPDI-Qに基づいて、PDI-Sアプリケーションを生成することができる。
【００２９】
放送サーバ１０６は、コンテンツサーバ１０１からのコンテンツのストリームデータ、メタデータサーバ１０４からの制御情報やESG情報、及びアプリケーションサーバ１０５からのアプリケーションのデータを受信する。
【００３０】
放送サーバ１０６は、コンテンツのストリームデータ、制御情報やESG情報、アプリケーションなどのデータを処理し、その結果得られる伝送データを、専用線などの所定の回線を介して、送信所３０に設置される送出設備に送信する。
【００３１】
送信所３０内の送出設備が、放送サーバ１０６からの伝送データに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送信号（放送波）が、伝送路４０を介して、クライアント装置２０により受信される。
【００３２】
通信サーバ１０７は、クライアント装置２０からの要求に応じて、インターネット５０を介して各種のデータを提供するサーバである。
【００３３】
通信サーバ１０７は、コンテンツサーバ１０１からのコンテンツのストリームデータ、メタデータサーバ１０４からの制御情報やESG情報、及びアプリケーションサーバ１０５からのアプリケーションのデータを受信して処理する。
【００３４】
通信サーバ１０７は、クライアント装置２０からの要求に応じて、コンテンツのストリームデータ、制御情報、ESG情報、又はアプリケーションを、インターネット５０を介して配信する。
【００３５】
クライアント装置２０は、例えば、テレビ受像機やセットトップボックス（STB：Set Top Box）、ネットワークストレージ、ゲーム機などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。
【００３６】
また、クライアント装置２０は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。さらに、クライアント装置２０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。
【００３７】
クライアント装置２０は、放送サーバ１０６から伝送路４０を介して送信されてくる放送信号を受信して、処理することで、放送経由で配信された番組等のコンテンツを再生することができる。また、クライアント装置２０は、通信サーバ１０７からインターネット５０を介して配信されるストリームデータを処理することで、通信経由で配信された番組等のコンテンツを再生することができる。
【００３８】
クライアント装置２０は、放送サーバ１０６又は通信サーバ１０７から配信されるアプリケーションのデータを処理することで、アプリケーションを実行することができる。また、クライアント装置２０は、PDIに関する処理を行うことができる。なお、クライアント装置２０の詳細な構成は、図３及び図４を参照して後述する。
【００３９】
なお、図１の伝送システム１においては、説明を簡単にするために、１台のクライアント装置２０のみを図示しているが、クライアント装置２０は、複数台設けることができる。そして、放送サーバ１０６から送信（一斉同報配信）される放送信号は、伝送路４０を介して、複数台のクライアント装置２０で同時に受信することができる。
【００４０】
（各サーバの構成例）
図２は、図１の各サーバの構成例を示すブロック図である。
【００４１】
図２においては、図１の送信側システム１０を構成するサーバのうち、PDIサーバ１０２、ESGサーバ１０３、メタデータサーバ１０４、及び放送サーバ１０６を図示しており、これらのサーバを中心に説明する。
【００４２】
PDIサーバ１０２は、PDI-Qジェネレータ１２１を有する。PDI-Qジェネレータ１２１は、PDI-Qを生成し、メタデータサーバ１０４に送信する。
【００４３】
ESGサーバ１０３は、ESG情報を生成し、メタデータサーバ１０４に送信する。
【００４４】
メタデータサーバ１０４は、ESG処理部１４１、メタデータ処理部１４２、及びPDI-Aジェネレータ１４３を有する。
【００４５】
ESG処理部１４１は、ESGサーバ１０３からのESG情報を処理し、放送サーバ１０６に送信する。ここでは、ESG情報に対し、PDI配信サービス（PDI Delivery Service）が配信されていることを示す情報（以下、配信情報ともいう）を含めることができる。
【００４６】
メタデータ処理部１４２は、コンテンツとともに配信される制御情報（が含むメタデータ）を処理し、放送サーバ１０６に送信する。ここでは、制御情報（後述するSLTメタデータ）に対し、配信情報を含めることができる。
【００４７】
PDI-Aジェネレータ１４３は、PDIサーバ１０２からのPDI-Qに基づいて、PDI-Aを生成し、ESG処理部１４１又はメタデータ処理部１４２に供給する。
【００４８】
ESG処理部１４１は、PDI-Aジェネレータ１４３からのPDI-Aを、ESG情報に含めることができる。また、メタデータ処理部１４２は、PDI-Aジェネレータ１４３からのPDI-Aを、制御情報（後述するMPDメタデータ）に含めることができる。
【００４９】
放送サーバ１０６は、送信部１６１及び配信処理部１６２を有する。
【００５０】
送信部１６１は、コンテンツサーバ１０１からのコンテンツとともに、メタデータサーバ１０４からの制御情報やESG情報を送信する。さらに、送信部１６１は、アプリケーションサーバからのアプリケーションを送信することができる。
【００５１】
配信処理部１６２は、配信方式に応じて、PDI-Sアプリケーションの参照先を示す情報（以下、参照情報ともいう）を配信することができる。ここで、参照情報は、例えば、URL(Uniform Resource Locator)であり、例えば、PDI配信サービスを配信するセッションの制御情報（後述するEFDT）又はPDI-Qのファイルのヘッダ（後述するHTTPヘッダ）などに含めることができる。
【００５２】
各サーバは、以上のように構成される。
【００５３】
（クライアント装置の構成例）
図３は、図１のクライアント装置２０の構成例を示すブロック図である。
【００５４】
図３において、クライアント装置２０は、処理部２０１、入力部２０２、記憶部２０３、チューナ２０４、放送ミドルウェア２０５、DASHクライアント２０６、レンダラ２０７、出力部２０８、ブラウザ２０９、及び通信I/F２１０から構成される。
【００５５】
処理部２０１は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部２０１は、各種の演算処理や、各部の動作制御など、クライアント装置２０における中心的な処理装置として動作する。処理部２０１は、クライアント装置２０内の各部との間で、各種のデータをやりとりすることができる。
【００５６】
入力部２０２は、例えば、物理的なボタン等であり、ユーザの操作に応じた操作信号を、処理部２０１に供給する。処理部２０１は、入力部２０２から供給される操作信号に基づいて、各部の動作を制御する。
【００５７】
記憶部２０３は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部２０３は、処理部２０１からの制御に従い、各種のデータを記憶する。
【００５８】
チューナ２０４は、アンテナを介して、放送サーバ１０６から送信されてくる放送信号を受信して処理し、その結果得られるデータを、放送ミドルウェア２０５に供給する。
【００５９】
放送ミドルウェア２０５は、チューナ２０４から供給されるデータを処理し、その結果得られるデータの種別に応じて、処理部２０１、DASHクライアント２０６、又はブラウザ２０９に供給する。
【００６０】
ここで、処理対象のデータのうち、コンテンツのストリームデータ（DASHセグメント）は、DASHクライアント２０６に供給され、アプリケーションのデータは、ブラウザ２０９に供給される。また、制御情報やESG情報、PDIに関する情報は、処理部２０１に供給される。
【００６１】
DASHクライアント２０６には、放送ミドルウェア２０５から供給されるDASHセグメントを処理し、その結果得られるビデオとオーディオのデータを、レンダラ２０７に供給される。なお、実際には、このDASHセグメントを処理して得られるビデオとオーディオのデータは、デコーダによりデコードされた後に、レンダラ２０７に供給されることになる。
【００６２】
レンダラ２０７は、DASHクライアント２０６から供給されるビデオとオーディオのデータに対し、レンダリング処理を行い、その結果得られるデータを、出力部２０８に供給する。
【００６３】
出力部２０８は、レンダラ２０７から供給されるビデオとオーディオのデータを出力する。これにより、クライアント装置２０では、番組等のコンテンツが再生され、その映像や音声が出力される。
【００６４】
なお、番組等のコンテンツは、録画されるようにしてもよい。また、映像を表示するディスプレイや、音声を出力するスピーカは、クライアント装置２０の内部に設けるほか、外部に設けて出力部２０８からのデータが供給されるようにしてもよい。
【００６５】
ブラウザ２０９は、例えばHTML5(HyperText Markup Language 5)に対応したブラウザである。ブラウザ２０９は、放送ミドルウェア２０５から供給されるアプリケーションのデータを処理し、その結果得られるデータを、出力部２０８に供給する。これにより、クライアント装置２０では、アプリケーションの映像が表示される。例えば、ブラウザ２０９は、PDI-Sアプリケーションを実行することができる。
【００６６】
通信I/F２１０は、通信インターフェース回路等から構成される。通信I/F２１０は、インターネット５０を介して通信サーバ１０７と各種のデータのやりとりを行う。
【００６７】
ここで、受信対象のデータのうち、コンテンツのストリームデータ（DASHセグメント）は、DASHクライアント２０６に供給され、アプリケーションのデータは、ブラウザ２０９に供給される。また、制御情報やESG情報、PDIに関する情報は、処理部２０１に供給される。
【００６８】
なお、これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータに対する処理と同様であるため、ここでは、その説明は省略する。
【００６９】
クライアント装置２０は、以上のように構成される。
【００７０】
（処理部の構成）
図４は、図３の処理部２０１の構成の詳細を示すブロック図である。
【００７１】
図４において、処理部２０１は、ネイティブモジュール２２１、アプリケーションマネージャ２２２、及びフィルタリング処理部２２３を有する。また、記憶部２０３は、PDI-Q又はPDI-Aを格納するPDIストア２６１を含む。
【００７２】
ネイティブモジュール２２１は、いわゆるネイティブアプリケーションとして、クライアント装置２０で起動されるオペレーティングシステム（OS：Operating System）環境などで実行される。ネイティブモジュール２２１は、PDIクライアント２４１を有する。
【００７３】
PDIクライアント２４１は、ネイティブアプリケーションとして、PDIに関する処理を行う。例えば、PDIクライアント２４１は、PDI-Qに基づいて、PDI-Aを生成する。
【００７４】
アプリケーションマネージャ２２２は、いわゆるWebアプリケーションとしてのアプリケーションを管理する。例えば、アプリケーションマネージャ２２２は、PDI-Sアプリケーションの取得や起動を管理する。
【００７５】
フィルタリング処理部２２３は、PDI-Aのマッチング処理を行うことで、取得対象のコンテンツを特定する。また、フィルタリング処理部２２３は、マッチング処理の結果に従い、特定のコンテンツのフィルタリング処理を行う。
【００７６】
処理部２０１は、以上のように構成される。
【００７７】
＜２．本技術の概要＞
【００７８】
（本技術のプロトコルスタック）
図５は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００７９】
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
【００８０】
例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等の放送方式と同様に、IP伝送方式を採用することができる。
【００８１】
図５において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
【００８２】
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
【００８３】
ここで、ATSC3.0では、制御情報（シグナリング）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの２階層で伝送される。
【００８４】
LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、放送サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームや放送サービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
【００８５】
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００８６】
このROUTEセッションにより、放送サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
【００８７】
ここで、SLSは、サービスレベルの制御情報であり、対象の放送サービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)，HELD(HTTP Entry Location Description)等のメタデータを含む。
【００８８】
USBDメタデータは、他のメタデータの取得先などの情報を含む。
【００８９】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
【００９０】
MPDメタデータは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。HELDメタデータは、アプリケーションの制御情報である。
【００９１】
ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００９２】
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００９３】
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
【００９４】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
【００９５】
このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
【００９６】
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われるコンテンツである。また、例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイルなど、NRTコンテンツ以外のファイルを、ROUTEセッションで伝送することもできる。なお、PDI配信サービスでは、関連するすべてのファイルを、NRTコンテンツと同様に転送することができる。
【００９７】
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
【００９８】
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
【００９９】
すなわち、これらの階層によって、インターネット等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
【０１００】
HTTP層に隣接する上位階層のうち、一部の階層は、制御情報（Signaling）と、NRTコンテンツ（NRT）とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
【０１０１】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【０１０２】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
【０１０３】
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、各装置での実装の負担や処理の負担を軽減することができる。
【０１０４】
（一般的なコンテンツフィルタリングの例）
図６は、一般的なコンテンツの配信サービスでのコンテンツフィルタリングの例を示す図である。
【０１０５】
図６に示すように、一般的なコンテンツの配信サービスにおいては、コンテンツを提供するプロバイダ側の送信サーバにおいて設定されたフィルタリング属性を、コンテンツメタデータ（フィルタリング属性）としてコンテンツに付与することで、コンテンツを受信するクライアント装置（のフィルタリングモジュール）でのコンテンツのフィルタリング処理が行われるようにしている。
【０１０６】
このコンテンツメタデータは、ATSC（Advanced Television Systems Committee standards）やARIB（Association of Radio Industries and Business）等の標準化団体によって規定されたメタデータセットの中から選択されたメタデータの要素についての値として設定される。
【０１０７】
すなわち、例えば、要素名として、「視聴対象」が選択され、その要素についての値として「10代」が設定されたコンテンツメタデータが付与されたコンテンツは、「視聴対象が10代である視聴者向けのコンテンツ」が取得されるように、フィルタリング処理を行うクライアント装置に提供されることになる。
【０１０８】
しかしながら、標準化団体によって規定されたメタデータセットに含まれないコンテンツメタデータ（フィルタリング属性）を、コンテンツに付与することはなされていない。
【０１０９】
例えば、プロバイダ側が、「視聴対象が10代であり、かつ、就職活動に興味がある視聴者向けのコンテンツ」を配信したい場合であっても、標準化団体によって規定されたメタデータセットの中に、「就職活動に興味があるかどうか」がコンテンツメタデータの要素として存在しない場合、コンテンツに対し、「就職活動に興味がある」が設定されたコンテンツメタデータを付与することはできない。
【０１１０】
したがって、プロバイダ側では、その時のニーズに応じた（例えば、流行を考慮した）、エンドユーザの関心事をコンテンツメタデータとして付与したコンテンツを配信することができなかった。一方で、このような場合に、クライアント装置においては、その時のニーズに応じたコンテンツを取得するようなフィルタリング処理を行うことはできなかった。
【０１１１】
（理想的なコンテンツフィルタリングの例）
図７は、理想的なコンテンツの配信サービスでのコンテンツフィルタリングの例を示す図である。
【０１１２】
例えば、プロバイダ側で、「視聴対象が10代であり、かつ、就職活動に興味がある視聴者向けのコンテンツ」を配信したい場合に、「就職活動に興味があるかどうか」という基準が、標準化団体で規定されるコンテンツメタデータに含まれていないとき、何らかの手法で、「就職活動に興味がある」という嗜好を、エンドユーザから事前に聴取して、クライアント装置（のフィルタリングモジュール）に設定しておく必要がある。
【０１１３】
ここでは、図７に示すように、コンテンツメタデータとして、「"視聴対象" = "10代"」のほかに、要素名として、プロバイダ別質問事項１を規定し、その要素についての値として、「YES」が含まれるようにする。すなわち、プロバイダ別質問事項１は、「求職中ですか？」が設定されているため、その値として「YES」が設定された場合には、求職中である（就職活動に興味がある）ことを表している。
【０１１４】
このようなコンテンツメタデータを付与したコンテンツを配信することで、クライアント装置では、例えば、コンテンツメタデータとして、「"視聴対象" = "10代"」、かつ、「"プロバイダ別質問事項１" = "YES"」が付与されたコンテンツ、すなわち、視聴対象が10代であり、かつ、就職活動に興味がある視聴者向けのコンテンツのみを取得するためのフィルタリング処理を行うことができる。
【０１１５】
なお、ここでは、追加した質問も、コンテンツメタデータとともに配信されるようにすることが望ましい。さらに、プロバイダが提供する質問の内容が、高度な対話性（ユーザの反応により条件分岐するような質問）を必要とする場合には、単に質問事項のみを、クライアント装置に配信するばかりでなく、エンドユーザとの対話を行うスクリプト等により実行されるアプリケーションとして配信して、エンドユーザの嗜好を精度良く、汲み取れることが望ましい。
【０１１６】
また、リアルタイムで配信される実況中継番組など、事前に内容の展開が予想できないようなコンテンツの場合には、コンテンツの配信の開始時や配信継続中に、エンドユーザとの対話を行い、エンドユーザのその時点での気分や嗜好に合わせたストリームの選択制御を行ったり、そのコンテンツに関連してダウンロードされるアプリケーション（スクリプト）を選択実行させたりしたい場合がある。
【０１１７】
この場合、当該コンテンツが配信されると同時（又は配信開始の直前若しくは配信中）に、上述した対話型のスクリプト等によって、エンドユーザの嗜好を汲み取る処理が行われることが望ましい。
【０１１８】
ここで、このような対話型のスクリプト等によって、エンドユーザの嗜好を汲み取る処理を行い、標準化団体によって規定されたコンテンツメタデータ以外の、その時のニーズに応じたコンテンツメタデータが付与されたコンテンツを配信するための手法として、ATSC2.0で採用されたPDI（Preference Demographic and Interest）がある（下記の非特許文献２参照）。
【０１１９】
非特許文献２：ATSC Standard: Interactive Services Standard
【０１２０】
（PDIスキーマの例）
図８乃至図１０には、PDIスキーマの例を示している。なお、図８乃至図１０においては、説明の都合上、各行に行番号を記述している。
【０１２１】
図８において、４行目乃至８行目には、質問のそれぞれについての名称及び型の宣言を示している。
【０１２２】
具体的には、４行目の"QIA"の名称で定義される質問の型"pdi:QIAType"は、その質問が整数値型の回答を求める質問であることを示している。また、５行目の"QBA"の名称で定義される質問の型"pdi:QBAType"は、その質問が論理値型の回答を求める質問であることを示している。
【０１２３】
６行目の"QSA"の名称で定義される質問の型"pdi:QSAType"は、その質問が回答候補選択型の回答を求める質問であることを示している。また、７行目の"QTA"の名称で定義される質問の型"pdi:QTAType"は、その質問が文字列型の回答を求める質問であることを示している。
【０１２４】
８行目の"QAA"の名称で定義される質問の型"pdi:QAAType"は、その質問が回答の型を制限しない質問であることを示している。以下の行においては、上述のように宣言された各質問それぞれの要素の宣言を示している。
【０１２５】
なお、１４行目には、オプショナルな要素として、referredByAppUrl要素が定義されている。このreferredByAppUrl要素は、PDI-Sアプリケーションの参照先を示す参照情報（例えば、URL）を通知するために、新たに追加された要素である。
【０１２６】
すなわち、このreferredByAppUrl要素によって、PDIインスタンスに、PDI-SアプリケーションのURLを直接記述することが可能となる。この参照情報としてのreferredByAppUrl要素の詳細は、後述する。
【０１２７】
ここで、PDIとしては、エンドユーザの嗜好についての質問を表す情報（質問情報）であるPDI-Q(Question)と、PDI-Qの質問に対するエンドユーザにより設定された回答を表す情報（回答情報）であるPDI-A(Answer)（以下、クライアント側PDI-Aともいう）と、PDI-Qの質問に対するプロバイダにより設定された回答を表す情報（回答情報）であるPDI-A（以下、プロバイダ側PDI-Aともいう）がある。
【０１２８】
図８乃至図１０に示したPDIスキーマは、XML（Extensible Markup Language）文書からなるPDI-Qの構造を定義するためのXMLスキーマの例となる。ただし、PDI-Qとして定義される質問に対する回答であるPDI-Aの構造を定義するためのXMLスキーマは、基本的にPDI-Qの構造を定義したXMLスキーマと同様の構造を有している。
【０１２９】
なお、XMLスキーマにより定義されるPDI-QやPDI-Aの構造は、図８乃至図１０に示した構造に限定されず、他の構造を採用することができる。
【０１３０】
（PDI-Qの記述例）
図１１は、PDI-Qの記述例を示す図である。
【０１３１】
図１１において、QSA要素の開始タグと終了タグの間には、Q要素、QText要素、及びSelection要素が記述されており、回答候補選択型の回答を求める質問を定義している。また、QSA要素のid要素には、質問と回答候補の組の識別子として、"ProviderA:123"が記述されている。
【０１３２】
Q要素のminChoice属性には、"1"が指定されており、回答される選択肢の数が１つに制約されることを意味している。
【０１３３】
QText要素には、質問として、"Which do you prefer, captions for adult or for children?"（大人向けの字幕であるか、子供向けの字幕であるか？）が記述されている。
【０１３４】
Selection要素には、質問に対する回答の選択肢として、"1"であるselectionId属性が付与された"For adults"（大人向け）と、"2"であるselectionId属性が付与された"For children"（子供向け）がそれぞれ記述されている。
【０１３５】
（質問と回答の表示例）
図１２は、クライアント装置が、送信サーバから受信したPDI-Q（図１１）に定義されている質問と回答の画面（エンドユーザとの対話画面）を表示している例を示す図である。
【０１３６】
図１２においては、図１１のPDI-Qの開始タグと終了タグの間に記述されるQText要素の記述内容に対応して、"Which do you prefer, captions for adult or for children?"である質問が表示されている。
【０１３７】
また、この質問の下段には、Selection要素の記述内容に対応した"For adults"と、"For children"である回答の選択肢が表示されている。
【０１３８】
クライアント装置では、質問を確認したエンドユーザにより、いずれか一方の選択肢が選択可能になされている。すなわち、エンドユーザによる質問に対する回答の選択肢の選択の結果に応じて、PDI-A（クライアント側PDI-A）が生成される。
【０１３９】
なお、プロバイダ側においても、図１２の対話画面が表示され、プロバイダ（コンテンツの提供者）による質問に対する回答の選択肢の選択の結果に応じて、PDI-A（プロバイダ側PDI-A）が生成される。
【０１４０】
（PDI-Aの記述例）
図１３は、PDI-Aの記述例を示す図である。
【０１４１】
図１３において、QSA要素の開始タグと終了タグの間には、Q要素、QText要素、Selection要素、及びA要素が記述されており、回答候補選択型の回答を求める質問とその回答を定義している。
【０１４２】
すなわち、図１３のPDI-Aは、図１１のPDI-Qと比べて、A要素が追加されている点が異なっている。A要素のanswer属性には、"2"が指定されている。このanswer属性の値は、Selection要素のselectionId属性の値に対応している。
【０１４３】
すなわち、図１３のPDI-Aの記述例では、図１２の対話画面において、"Which do you prefer, captions for adult or for children?"である質問に対する、"For adults"と"For children"である回答の選択肢のうち、"For children"が選択された場合を示している。
【０１４４】
（コンテンツのフィルタリング処理）
クライアント装置では、エンドユーザにより設定された回答に応じたPDI-A（クライアント側PDI-A）と、プロバイダ（コンテンツの提供者）により設定された回答に応じたPDI-A（プロバイダ側PDI-A）とのマッチング処理結果に従い、コンテンツのフィルタリング処理が行われる。
【０１４５】
なお、プロバイダ側PDI-Aは、配信されるコンテンツのメタデータ（後述するMPDメタデータやESG情報など）に含めて配信される。
【０１４６】
例えば、クライアント装置において、クライアント側PDI-Aとして、図１３に示したPDI-Aが生成された場合に、送信サーバから配信されるメタデータを受信したとき、当該メタデータに、図１４に示したPDI-A（プロバイダ側PDI-A）が含まれていたとする。
【０１４７】
ここで、図１４のＡのPDI-A（プロバイダ側PDI-A）は、図１２の対話画面において、質問に対する回答の選択肢のうち、"For children"が選択された場合を示している。一方で、図１４のＢのPDI-A（プロバイダ側PDI-A）は、図１２の対話画面において、質問に対する回答の選択肢のうち、"For adults"が選択された場合を示している。
【０１４８】
そして、クライアント装置では、配信されるコンテンツのメタデータに、図１４のＡのプロバイダ側PDI-Aが含まれる場合、当該プロバイダ側PDI-Aとクライアント側PDI-Aとはマッチする（"For children"でセレクション項目が一致する）と判断して、当該コンテンツを選択する。
【０１４９】
一方で、クライアント装置では、配信されるコンテンツのメタデータに、図１４のＢのプロバイダ側PDI-Aが含まれる場合、当該プロバイダ側PDI-Aとクライアント側PDI-Aとはマッチしない（"For adults"と"For children"とでセレクション項目が一致しない）と判断して、当該コンテンツを選択しない。
【０１５０】
すなわち、回答候補選択型（セレクション型）のPDI-Qに対するPDI-Aの場合には、クライアント装置側のコンテンツフィルタに設定されるPDI-A（クライアント側PDI-A）が示す選択されたセレクション項目の１つでも満足するPDI-A（プロバイダ側PDI-A）がアサインされているコンテンツを取得対象とするコンテンツフィルタリングが行われる。
【０１５１】
（PDIの全体像）
以上をまとめると、図１５に示すようになる。図１５は、PDIの全体像を示す図である。
【０１５２】
図１５に示すように、プロバイダサーバでは、クライアント装置を使用するユーザの嗜好についての質問を表す情報であるPDI-Qと、ユーザの嗜好についての質問に対してプロバイダにより設定された回答を表す情報であるPDI-A（プロバイダ側PDI-A）が生成され、クライアント装置に送信される。
【０１５３】
なお、詳細は後述するが、プロバイダ側PDI-Aは、コンテンツとともに伝送されるMPDメタデータやESG情報に含めて送信することができる。
【０１５４】
一方で、クライアント装置では、PDI-Qが受信されると、PDI-Qの質問に対するユーザの回答を表す情報であるPDI-A（クライアント側PDI-A）が生成され、保存される。
【０１５５】
そして、クライアント装置では、プロバイダから配信されるコンテンツの受信に際し、プロバイダからのプロバイダ側PDI-Aと、保存されたクライアント側PDI-Aとのマッチング処理を行い、PDI-Aがマッチしたコンテンツのみが再生（又は録画）されることになる。
【０１５６】
このように、最適なコンテンツを選択する際の選択基準となるパラメータのバリエーションとして、ATSC2.0で採用されたPDIと呼ばれるエンドユーザへの質問とそれに対する回答で構成される、エンドユーザの嗜好等を表現する動的なメタデータ機構がある。
【０１５７】
そして、ATSC3.0等の放送方式においても、PDIを採用して、エンドユーザの嗜好に応じたコンテンツを提供できるようにすることが期待されている。
【０１５８】
そこで、本技術では、メタデータ機構により生成されるメタデータ（コンテンツメタデータ）を配信するフォーマットであるPDI-Qのインスタンスを転送するサービス（PDI配信サービス）の定義とその制御情報（シグナリング）、さらにそのフォーマットやサービスの制御情報（シグナリング）に、配信した後にエンドユーザとのインタラクションにより、PDI-Aを生成するアプリケーションなどの参照情報などを格納できるようにすることで、エンドユーザの嗜好に応じたコンテンツを提供できるようにする。
【０１５９】
＜３．PDI対応処理＞
【０１６０】
（１）第１のPDI処理方式
【０１６１】
第１のPDI処理方式では、プロバイダ（放送局）側で、PDI-Qインスタンスが生成される、あるいは一旦配信されたPDI-Qインスタンスを更新又は削除した場合、生成、更新、又は削除されたPDI-Qインスタンスについて、PDI-Q配信用のサービス（PDI配信サービス）を宣言して、そこで転送されるようにする。
【０１６２】
一方で、クライアント装置２０においては、ネイティブモジュール２２１のPDI処理系（PDIクライアント２４１）が、ESG情報やSLTメタデータを監視して、このPDI配信サービスの配信を検知して受信する。この場合、クライアント装置２０側で、PDI-Qの生成、更新、又は削除を検知して受信することができるため、最新のPDIに基づいた嗜好設定が可能となり、コンテンツのフィルタリング処理の精度が保証されることになる。
【０１６３】
また、クライアント装置２０においては、PDI-Qに基づいたPDI-Aの生成を、ネイティブモジュール２２１のPDIクライアント２４１が行うほか、WebアプリケーションとしてのPDI-SアプリケーションがPDI-Qを処理して、対応するPDI-Aを生成し、PDIストア２６１に格納させるようにすることもできる。
【０１６４】
すなわち、クライアント装置２０で、PDI-Aを生成してPDIストア２６１に格納させる方法としては、以下の２つのパターンがある。
【０１６５】
１つ目のパターンとしては、ネイティブモジュール２２１のPDIクライアント２４１が、PDI-Qを直接パースして、エンドユーザとの間で必要なインタラクションを行うか、あるいは、エンドユーザの視聴履歴情報等を参照することで、エンドユーザの嗜好を類推して、対応するPDI-Aを生成し、PDIストア２６１に格納するものである。
【０１６６】
以下、この１つ目のパターンを、パターン１と称する。なお、パターン１のPDI対応処理の詳細は、図２６のフローチャートを参照して後述する。
【０１６７】
２つ目のパターンとしては、ネイティブモジュール２２１のPDIクライアント２４１が、PDI-Qの配信と同時に通知されるWebアプリケーションとしてのPDI-Sアプリケーションを、ブラウザ２０９上に起動する。
【０１６８】
そして、このPDI-Sアプリケーションが、エンドユーザとの間で必要なインタラクションを行うか、あるいは、エンドユーザの視聴履歴情報等を参照することで、エンドユーザの嗜好を類推して、対応するPDI-Aを生成し、PDIストア２６１に格納するものである。
【０１６９】
以下、この２つ目のパターンを、パターン２と称する。なお、パターン２のPDI対応処理の詳細は、図２８及び図２９のフローチャートを参照して後述する。
【０１７０】
（第１のPDI処理方式の全体像）
図１６は、第１のPDI処理方式の全体像を示す図である。
【０１７１】
図１６の上段に示すように、SLTメタデータのService要素のserviceCategory属性として、serviceCategory = "PDI delivery service"が指定されたPDI-Q配信用のサービス（PDI配信サービス）のROUTEセッションでは、PDI-Qのファイルが転送されている。
【０１７２】
また、図１６の下段に示すように、SLTメタデータのService要素のserviceCategory属性として、serviceCategory = "Linear TV"又は"App-based"が指定されたApp配信用のサービスのROUTEセッションでは、PDI-Sアプリケーションのファイルが転送されている。
【０１７３】
ここで、クライアント装置２０において、パターン１のPDI対応処理を行う場合には、放送ミドルウェア２０５が、PDI配信サービスのROUTEセッションで配信されるPDI-Qを取得し、PDIストア２６１に格納する。
【０１７４】
その後、ネイティブモジュール２２１（のPDIクライアント２４１）が、PDIストア２６１に格納されたPDI-Qを直接パースして、例えば、図１２の対話画面などにより、エンドユーザとの間で必要なインタラクションを行うことで、対応するPDI-A（クライアント側PDI-A）を生成する。生成されたPDI-A（クライアント側PDI-A）は、PDIストア２６１に格納される。
【０１７５】
一方で、クライアント装置２０において、パターン２のPDI対応処理を行う場合には、放送ミドルウェア２０５が、PDI配信サービスのROUTEセッションで配信されるPDI-Qを取得し、PDIストア２６１に格納する。
【０１７６】
その後、ネイティブモジュール２２１（のPDIクライアント２４１）が、PDIストア２６１に格納されたPDI-Qに記述された参照情報（PDI-S Ref：PDI-Sアプリケーションの参照先のURL）に従い、App配信用のサービスで配信されるPDI-Sアプリケーションを取得して、ブラウザ２０９上で起動する。なお、ここでは、放送配信されるPDI-Sアプリケーションのほか、インターネット５０を介して通信配信されるPDI-Sアプリケーションが取得されるようにしてもよい。
【０１７７】
そして、ブラウザ２０９上で実行されるPDI-Sアプリケーションが、PDI-Qに基づいて、例えば、図１２の対話画面などにより、エンドユーザとの間で必要なインタラクションを行うことで、対応するPDI-A（クライアント側PDI-A）を生成する。生成されたPDI-A（クライアント側PDI-A）は、PDIストア２６１に格納される。
【０１７８】
本技術では、パターン１とパターン２のPDI対応処理を実現するために、PDI配信サービスが配信されていることを示す配信情報と、PDI-Sアプリケーションの参照先を示す参照情報を規定している。そこで、以下の説明では、先に、配信情報と参照情報の詳細を説明してから、その後に、パターン１とパターン２のPDI対応処理の詳細についても説明する。
【０１７９】
なお、図１６の例では、PDI配信サービスが配信されていることを示す配信情報が、SLTメタデータに含まれる場合を例示しているが、この配信情報は、ESG情報などに含めることができる。
【０１８０】
また、図１６の例では、PDI-Sアプリケーションの参照先を示す参照情報（PDI-S Ref）が、上述した図８のPDIスキーマに示したように、PDI-QのreferredByAppUrl属性に記述されている場合を例示しているが、この参照情報は、EFDTパラメータを拡張するか、あるいはHTTPヘッダを拡張することでも配信することができる。
【０１８１】
また、以下の説明では、プロバイダとして放送局を一例に説明するが、例えば、パーソナライゼーションサービスプロバイダ等の他のエンティティであってもよい。
【０１８２】
（１−１）配信情報の配信方法
【０１８３】
次に、配信情報の配信方法について説明する。第１のPDI配信方式では、例えば、LLSを拡張するか、あるいはESG情報を拡張することで、配信情報を配信することができる。
【０１８４】
（LLSの拡張による配信情報の配信）
LLSの１つであるSLTメタデータにおいては、サービスの種別を示すserviceCategory属性が規定されている（下記の非特許文献３参照）。
【０１８５】
非特許文献３：ATSC Candidate Standard: Signaling, Delivery, Synchronization,and Error Protection(A/331)
【０１８６】
図１７には、SLTメタデータのサービスループ内に配置されるserviceCategory属性の値の例が示されている。
【０１８７】
図１７に示すように、このserviceCategory属性により、例えば、通常の放送サービス（1：Linear A/V service）であるとか、音声のみのサービス（2：Linear audio only service）であるとかのサービスの種別を指定することができる。なお、音声のみのサービスは、現行のラジオ放送に相当する。
【０１８８】
上記の非特許文献３の「Table 6.4 Code Values for SLT.Service@serviceCategory」に規定されているように、serviceCategory属性には、0〜5とOther valuesの値が定義されている。
【０１８９】
第１のPDI処理方式では、このserviceCategory属性の値として、新たに"6"を定義して、PDI配信サービス（PDI Delivery Service）を意味するようにする。すなわち、ここでは、要素や属性の追加ではなく、属性値の追加拡張によって、SLTメタデータに、PDI配信サービスが配信されることを示す配信情報を含めることができる。
【０１９０】
図１８には、SLTメタデータの記述例を示している。例えば、2016年9月12日の13時から15時までの間に、このオフローディングサービス（PDI配信サービス）が利用可能である場合、この時間帯のSLTメタデータのService要素のうちの１つに、serviceCategory属性の値として、serviceCategory = "6"が指定される。つまり、2016年9月12日の13時から15時までの間は、当該SLTメタデータが配信されることになる。
【０１９１】
（ESGの拡張による配信情報の配信）
ESGサービスは、携帯電話の規格策定を行う組織であるOMA（Open Mobile Alliance）によって規定されている電子サービスガイド（電子番組表）であるが、ATSC3.0においてもOMA-ESGに準拠した番組情報（ESG）を利用することが想定されている（下記の非特許文献４参照）。
【０１９２】
非特許文献４：ATSC Candidate Standard: Service Announcement (A/332)
【０１９３】
図１９に示すように、ATSC3.0の番組情報（ESG）においては、通常の放送サービス（Liner service）、ラジオ放送（Linear audio only service）、又はApp-basedサービス（app-based enhancement service）であるかのサービスの種別を示すServiceTypeという要素がある。
【０１９４】
なお、ESGのServiceType要素と、SLTメタデータのserviceCategory属性とを比べれば、ESGの通常の放送サービスは、SLTメタデータで定義される通常の放送サービス（1：Linear A/V service）に相当し、ESGのラジオ放送は、SLTメタデータで定義される音声のみのサービス（2：Linear audio only service）に相当する。さらに、ESGのApp-basedサービスは、SLTメタデータで定義されるApp-basedサービス（3：App-based service）に相当する。
【０１９５】
すなわち、ESGのServiceType要素としては、上記の非特許文献４の「5.2.2.1.1 Service Type」に規定される値が規定されている。
【０１９６】
第１のPDI処理方式では、このServiceType要素の値として、図１９に示すように、新たに"230"を定義して、PDI配信サービス（PDI Delivery Service）を意味するようにする。すなわち、ここでは、要素や属性の追加ではなく、要素のコンテントとして格納する値の追加拡張によって、ESG情報に、PDI配信サービスが配信されることを示す配信情報を含めることができる。
【０１９７】
図２０には、ESG情報の記述例を示している。図２０に示すように、ESG情報のサービスフラグメント（Service fragment）に、ServiceType要素の値として、ServiceType = "230"が指定され、対象のサービスが、PDI配信サービスであることを表している。
【０１９８】
また、例えば、2016年9月12日の13時から15時までの間などの時間帯で、PDI配信サービスが利用可能である場合、ESG情報では、図２０に示したサービスフラグメント（Service fragment）のほか、コンテンツフラグメント（Content fragment）や、スケジュールフラグメント（Schedule fragment）等のXMLフラグメントを用いて、当該PDI配信サービスの有効期間を事前に通知することができる。その具体例を、図２１及び図２２に示す。
【０１９９】
（XMLフラグメントの関係）
図２１は、ある時間帯で、PDI配信サービスが利用可能である場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０２００】
サービスフラグメントは、"//a.com/Service-1"であるIDで識別され、ServiceType要素の値として、ServiceType = "230"が指定されている。つまり、当該サービス（Service-1）が、PDI配信サービスであることを表している。
【０２０１】
コンテンツフラグメントは、"//a.com/Content-1-1"であるIDで識別され、Name要素として、"PDI delivery service"が指定されている。つまり、当該コンテンツの名称は、PDI配信サービスである。
【０２０２】
なお、図２１において、コンテンツフラグメントは、ServiceReference要素のidRef属性の値により、サービスフラグメントと関連付けられている。
【０２０３】
スケジュールフラグメントは、"//a.com/Schedule-1-1"であるIDで識別され、ContentReference要素の子要素となるPresentationWindow要素のstartTime属性として、"2016-09-12T13:00:00+00:00"が指定され、endTime属性として、"2016-09-12T15:00:00+00:00"が指定される。
【０２０４】
つまり、startTime属性とendTime属性によって、PDI配信サービスの開始時刻t1と終了時刻t2が指定される。この例の場合には、2016年9月12日の13時から15時までの間で、PDI配信サービスが配信されることになる。
【０２０５】
なお、図２１において、スケジュールフラグメントは、ServiceReference要素のidRef属性の値により、サービスフラグメントと関連付けられている。また、スケジュールフラグメントは、ContentReference要素のidRef属性の値により、コンテンツフラグメントと関連付けられている。
【０２０６】
（ESGサービスの画面例）
図２２は、PDI配信サービスが利用可能である場合のESGサービスの画面の表示例を示す図である。
【０２０７】
図２２のESGサービスの画面は、図２１に示したXMLフラグメントを含むESG情報を受信したクライアント装置２０で表示される画面の表示例である。
【０２０８】
すなわち、このESGサービスの画面においては、開始時刻t1（2016年9月12日の13時）から終了時刻t2（2016年9月12日の15時）までの時間帯の枠内に、Service-1として、PDI配信サービス（PDI Delivery Service）が表示されている。これにより、エンドユーザに対し、その時間帯に、PDI配信サービスが配信されることを、事前に通知（周知）することができる。
【０２０９】
ただし、PDI配信サービスの配信を、ESGサービスの画面上に表示するかどうかは、クライアント装置２０のUI(User Interface)の実装次第である。そのため、例えば、クライアント装置２０によっては、PDI配信サービスの配信を、エンドユーザには提示せずに、クライアント装置２０のPDI処理系（PDIクライアント２４１）の独自判断でPDI-Qを取得して、最新のPDI-Qに更新するという場合もある。
【０２１０】
なお、第１のPDI配信方式においては、LLSの拡張、及び、ESGの拡張による配信情報の配信方法のうち、少なくとも一方の配信方法によって、配信情報を配信するようにすればよい。また、LLSの拡張、及び、ESGの拡張による配信情報の配信方法以外の配信方法によって、配信情報が配信されるようにしてもよい。
【０２１１】
（１−２）参照情報の配信方法
【０２１２】
次に、参照情報の配信方法について説明する。第１のPDI配信方式では、例えば、EFDTパラメータを拡張するか、あるいはHTTPヘッダを拡張することで、参照情報を配信することができる。
【０２１３】
なお、ROUTEセッションの配信モードとしては、ファイルモード（FileMode）配信と、エンティティモード（EntityMode）配信とがあり、配信モードごとに、参照情報の配置方法が異なる。ここで、ファイルモード配信とは、ファイルそのものが配信されるモードである。また、エンティティモード配信とは、HTTPヘッダ（Entityヘッダ）が付加されたファイルが配信されるモードである。
【０２１４】
（EFDTパラメータの拡張による参照情報の配信）
図２３は、ファイルモード配信の場合に、EFDTパラメータを拡張するときの例を示す図である。
【０２１５】
図２３においては、ファイルモード配信時のSLSシグナリングセッションで運ばれるSLSと、PDIファイルセッションで運ばれるPDI-Qと、これらのROUTEセッションとは独立して配信されるPDI-Sアプリケーションとの関係を表している。
【０２１６】
なお、SLSシグナリングセッション（TSI = "sls-tsi"）は、パッケージモードで配信され、PDIファイルセッション（TSI = "pdi-tsi"）は、ファイルモードで配信される。また、PDI-Sアプリケーションは、放送配信又は通信配信される。
【０２１７】
SLSシグナリングセッションにおいては、特定のTOI（TOI = "0"）で識別されるUSDフラグメント（USBDメタデータ）と、S-TSIDフラグメント（S-TSIDメタデータ）が転送される。USDフラグメントを取得することで、S-TSIDフラグメントを参照することができる。
【０２１８】
S-TSIDフラグメントでは、LS要素のtsi属性の値として、tsi = "pdi-tsi"が指定されているが、このtsi属性の値により、PDIファイルセッションが参照される。このPDIファイルセッションでは、EFDTと、PDI-Qのファイルが転送される。ただし、EFDTは、特定のTOI（TOI = "0"）により識別される。
【０２１９】
第１のPDI配信方式では、このEFDTのFDTParameters要素の子要素となるFile要素に、PDI-QインスタンスファイルのファイルURLを指定するContent-Location属性と並列に、referredByAppUrl属性を新たに定義する。そして、このreferredByAppUrl属性により、当該PDI-Qインスタンスファイルを参照して処理するPDI-SアプリケーションのURL（EntryLocationUrl）が指定されるようにする。すなわち、EFDTのreferredByAppUrl属性の値として指定されるURLが、参照情報（PDI-S Ref）となる。
【０２２０】
クライアント装置２０では、EFDTから得られるURL（pdi-sAppUrl）に基づいて、放送サーバ１０６又は通信サーバ１０７から配信されるPDI-Sアプリケーションのファイル（PDI-S AppFile）を取得することができる。そして、クライアント装置２０では、当該PDI-Sアプリケーションが起動され、PDI-Qのファイルが処理されることになる。
【０２２１】
なお、PDIファイルセッションにおいて、EFDTのFDTParameters要素のFile要素のTOI属性の値として、TOI = "pdi-qToi"が指定されているが、このTOI属性の値により、PDI-Qのファイル（PDI-S File）が参照されて取得される。また、ROUTEセッションでは、TSI(Transport Session Identifier)とTOI(Transport Object Identifier)の２つの識別情報により、データを識別することが可能となる。
【０２２２】
（EFDTスキーマの例）
図２４は、拡張されたEFDTスキーマの例を示す図である。
【０２２３】
図２４においては、FDTParameters要素の子要素となるFile要素に、referredByAppUrl属性が追加され、EFDTが拡張されている。図２４に示すように、referredByAppUrl属性は、PDI-QインスタンスファイルのファイルURLを指定するContent-Location属性と並列に定義されている。
【０２２４】
なお、図２４に示したEFDTスキーマの構造は一例であって、他の構造を採用するようにしてもよい。
【０２２５】
（HTTPヘッダの拡張による参照情報の配信）
図２５は、エンティティモード配信の場合に、HTTPヘッダを拡張するときの例を示す図である。
【０２２６】
図２５においては、エンティティモード配信時のSLSシグナリングセッションで運ばれるSLSと、PDIファイルセッションで運ばれるPDI-Qと、これらのROUTEセッションとは独立して配信されるPDI-Sアプリケーションとの関係を表している。
【０２２７】
なお、SLSシグナリングセッション（TSI = "sls-tsi"）は、パッケージモードで配信され、PDIファイルセッション（TSI = "pdi-tsi"）は、ファイルモードで配信される。また、PDI-Sアプリケーションは、放送配信又は通信配信される。
【０２２８】
SLSシグナリングセッションにおいては、特定のTOI（TOI = "0"）で識別されるUSDフラグメント（USBDメタデータ）と、S-TSIDフラグメント（S-TSIDメタデータ）が転送される。USDフラグメントを取得することで、S-TSIDフラグメントを参照することができる。
【０２２９】
S-TSIDフラグメントでは、LS要素のtsi属性の値として、tsi = "pdi-tsi"が指定されているが、このtsi属性の値により、PDIファイルセッションが参照される。このPDIファイルセッションでは、PDI-Qのファイルが転送される。
【０２３０】
第１の配信方式では、このPDI-Qのファイルの中に、HTTPヘッダ（Entityヘッダ）の拡張として、referredByAppUrlヘッダを新たに定義する。そして、このreferredByAppUrlヘッダにより、当該PDI-Qインスタンスファイルを参照して処理するPDI-SアプリケーションのURL（EntryLocationUrl）が指定されるようにする。すなわち、HTTPヘッダのreferredByAppUrlヘッダの値として指定されるURLが、参照情報（PDI-S Ref）となる。
【０２３１】
クライアント装置２０では、referredByAppUrlヘッダから得られるURL（pdi-sAppUrl）に基づいて、放送サーバ１０６又は通信サーバ１０７から配信されるPDI-Sアプリケーションのファイル（PDI-S AppFile）を取得することができる。そして、クライアント装置２０では、当該PDI-Sアプリケーションが起動され、PDI-Qのファイルが処理されることになる。
【０２３２】
なお、第１のPDI配信方式においては、EFDTパラメータの拡張、及び、HTTPヘッダの拡張による参照情報の配信方法のうち、少なくとも一方の配信方法によって、参照情報を配信するようにすればよい。
【０２３３】
また、EFDTパラメータの拡張、及び、HTTPヘッダの拡張による参照情報の配信方法以外の配信方法によって、参照情報が配信されるようにしてもよい。例えば、ここでは詳細は述べなかったが、上述した図８のPDIスキーマに示したように、PDI-QのreferredByAppUrl属性に、PDI-Sアプリケーションの参照先のURLを直接記載するようにしてもよい。
【０２３４】
（１−３）パターン１のPDI対応処理
【０２３５】
（パターン１のPDI対応処理の流れ）
まず、図２６のフローチャートを参照して、第１のPDI処理方式（パターン１）の場合の送信側と受信側の各装置で実行されPDI対応処理の流れを説明する。
【０２３６】
なお、図２６において、ステップＳ１０１乃至Ｓ１０２、Ｓ１１１乃至Ｓ１１４、及びＳ１２１乃至Ｓ１２３の処理は、送信側システム１０のPDIサーバ１０２、メタデータサーバ１０４、及び放送サーバ１０６によりそれぞれ実行される。
【０２３７】
一方で、ステップＳ１３１乃至Ｓ１３３、及びＳ１４１乃至Ｓ１４２の処理は、クライアント装置２０の放送ミドルウェア２０５、及び（ネイティブモジュール２２１の）PDIクライアント２４１により実行される。
【０２３８】
ステップＳ１１１において、ESG処理部１４１は、ESGサーバ１０３により生成されたESG情報を処理する。ステップＳ１１１で処理されたESG情報は、放送サーバ１０６に転送される（Ｓ１１２）。ステップＳ１２１において、送信部１６１は、メタデータサーバ１０４からのESG情報を送信する。
【０２３９】
ここで、送信側システム１０からPDI-Qが配信予定である場合には、ESG情報のServiceType要素（配信情報）として、"PDI delivery service"を記述することで、対象の配信予定のサービスが、PDI配信サービスであることを事前に通知することができる。
【０２４０】
ステップＳ１１３において、メタデータ処理部１４２は、SLSとしてのSLTメタデータを処理する。ステップＳ１１３で処理されたSLTメタデータは、放送サーバ１０６に転送される（Ｓ１１４）。ステップＳ１２２において、送信部１６１は、メタデータサーバ１０４からのSLTメタデータを送信する。
【０２４１】
ここで、送信側システム１０からPDI-Qが配信される場合には、SLTメタデータのServiceCategory属性（配信情報）として、"PDI delivery service"を記述することで、対象のROUTEセッションで配信されるサービスが、PDI配信サービスであることを通知することができる。
【０２４２】
ただし、ESG情報とSLTメタデータに対し、配信情報としての"PDI delivery service"を指定することで、PDI配信サービスが配信されることを通知することが可能であるが、少なくとも一方に配信情報を含めるようにすればよい。
【０２４３】
例えば、PDI配信サービスが配信されることを事前に通知する場合には、ESG情報を利用する一方で、PDI配信サービスが配信されていることをリアルタイムで通知する場合には、SLTメタデータを利用するなどして、使い分けることができる。
【０２４４】
ステップＳ１０１において、PDI-Qジェネレータ１２１は、PDI-Qを生成する。ここで生成されたPDI-Qは、放送サーバ１０６に転送される（Ｓ１０２）。ステップＳ１２３において、送信部１６１は、PDIサーバ１０２からのPDI-Qを送信する。
【０２４５】
一方で、ステップＳ１３１において、放送ミドルウェア２０５は、チューナ２０４により受信された放送信号から得られるESG情報を処理し、ESGサービスの画面（図２２）を、出力部２０８を介してディスプレイに提示されるようにする。
【０２４６】
なお、ESG情報の提示は必須ではなく、エンドユーザの操作などにより、必要に応じて提示されることになる。また、送信側システム１０からPDI-Qが配信予定である場合には、ESG情報のServiceType要素として、"PDI delivery service"が記述されているため、対象の配信予定のサービスが、PDI配信サービスであることを認識することができる（図２２のESGサービスの画面）。
【０２４７】
ステップＳ１３２において、放送ミドルウェア２０５は、チューナ２０４により受信された放送信号から得られるSLTメタデータを処理する。
【０２４８】
ここで、送信側システム１０からPDI-Qが配信される場合には、SLTメタデータのServiceCategory属性として、"PDI delivery service"が記述されているので、放送ミドルウェア２０５は、SLTメタデータのパース結果に従い、PDI配信サービスが配信されるROUTEセッションを特定し、PDI-Qを取得することができる（Ｓ１３３）。
【０２４９】
ステップＳ１３４において、放送ミドルウェア２０５は、ROUTEセッションから取得したPDI-Qを、PDIストア２６１に格納する。なお、PDIストア２６１に、既にPDI-Qが格納されている場合には、格納済みのPDI-Qを、新たに取得したPDI-Qに更新したり、あるいは、格納済みのPDI-Qを削除したりすることができる。すなわち、ここでは、PDI-Qの格納、更新、又は削除が行われる。
【０２５０】
ステップＳ１４１において、PDIクライアント２４１は、PDIストア２６１に格納されたPDI-Qを読み出す。また、ステップＳ１４２において、PDIクライアント２４１は、読み出されたPDI-Qに応じてPDI-A（クライアント側PDI-A）を生成し、PDIストア２６１に格納する。
【０２５１】
ここで、PDI-QがPDI配信サービス（PDI Delivery Service）により配信されたタイミングで、あるいはエンドユーザが本編番組などを再生視聴しているタイミングで、PDI-Qが届けられる場合に、PDIクライアント２４１は、エンドユーザに新たに届いたPDI-Qに対するエンドユーザの回答であるPDI-Aを生成する必要がある。
【０２５２】
このPDI-Aを生成するタイミングとしては、その実装やUI(User Interface)に依存するが、例えば、次のように行うことができる。
【０２５３】
すなわち、複数のPDI-Qの新規配信を待って、PDI-Aの生成を行う場合には、ディスプレイ上に、処理候補となるPDI-Qのリストを提示して、エンドユーザに回答を生成する対象を選択させるというような実装をすることができる。なお、このとき、再生視聴している番組と関係のある質問だけでなく、当該番組とは特別関係のない質問がなされるようにしてもよい。
【０２５４】
具体的には、図２７のＡに示すように、PDI配信サービスにより、新たなPDI-Q群が配信されると、新たなPDI-Aのセットを生成させるために、エンドユーザにPDI-Aの生成を促すための画面が表示される。例えば、図２７のＡの例では、「ANBC放送からのプリファレンス設定依頼あり」とのメッセージが表示されている。
【０２５５】
そして、エンドユーザがPDI-Aの生成を行う場合には、図２７のＢに示すように、個々のPDI-Qに対応する項目として、例えば、QText要素の文字列から抽出して提示し（あるいは、最初から複数文字列を切り出す等して提示してもよい）、エンドユーザの選択を促すようにする。例えば、図２７の例では、「1 あなたのプロファイル設定」、「2 最近興味あること・・・」、及び「3 購入したいもの・・・」の選択肢が表示されている。
【０２５６】
このように、PDI-Qで定義されている質問に対する回答を、ディスプレイに表示させて、エンドユーザによる質問に対する回答の入力又は選択を受け付けることで、その回答の入力又は選択の結果に応じたPDI-A（クライアント側PDI-A）が生成され、PDIストア２６１に格納されることになる。
【０２５７】
なお、PDI配信サービスで配信されるPDI-Qとしては、新たなPDI-Qインスタンスが届く場合もあれば、以前に配信されたPDI-Qインスタンスの新しいバージョンが届けられる場合もある。例えば、その場合には、PDIストア２６１に格納されているPDI-Qを、新しいバージョンに更新したり、古いバージョンのPDI-Qを、削除したりすることができる。
【０２５８】
また、ここでは、PDIクライアント２４１が、PDI-Qをパースして、エンドユーザとの間で必要なインタラクションを行うことで、PDI-Aが生成される場合を説明したが、上述したように、ステップＳ１４２の処理では、エンドユーザの視聴履歴情報等を参照して、エンドユーザの嗜好を類推することで、PDI-Aが生成されるようにしてもよい。
【０２５９】
以上、パターン１のPDI対応処理の流れについて説明した。
【０２６０】
（１−４）パターン２のPDI対応処理
【０２６１】
（パターン２のPDI対応処理の流れ）
次に、図２８及び図２９のフローチャートを参照して、第１のPDI処理方式（パターン２）の場合の送信側と受信側の各装置で実行されるPDI対応処理の流れを説明する。
【０２６２】
なお、図２８及び図２９において、ステップＳ１５１乃至Ｓ１５３、Ｓ１６１乃至Ｓ１６２、Ｓ１７１乃至Ｓ１７４、及びＳ１８１乃至Ｓ１８７の処理は、送信側システム１０のアプリケーションサーバ１０５、PDIサーバ１０２、メタデータサーバ１０４、及び放送サーバ１０６によりそれぞれ実行される。
【０２６３】
一方で、ステップＳ１９１乃至１９４、Ｓ２０１乃至Ｓ２０２、及びＳ２１１の処理は、クライアント装置２０の放送ミドルウェア２０５、（ネイティブモジュール２２１の）PDIクライアント２４１、及びブラウザ２０９により実行される。
【０２６４】
ステップＳ１７１，Ｓ１７２，Ｓ１８１においては、図２６のステップＳ１１１，Ｓ１１２，Ｓ１２１と同様に、ESG情報が処理されて送信される。ここで、送信側システム１０からPDI-Qが配信予定である場合には、ESG情報のServiceType要素（配信情報）として、"PDI delivery service"を記述することで、対象の配信予定のサービスが、PDI配信サービスであることを事前に通知することができる。
【０２６５】
ステップＳ１７３，Ｓ１７４，Ｓ１８２においては、図２６のステップＳ１１３，Ｓ１１４，Ｓ１２２と同様に、SLTメタデータが処理されて送信される。ここで、送信側システム１０からPDI-Qが配信される場合には、SLTメタデータのServiceCategory属性（配信情報）として、"PDI delivery service"を記述することで、対象のROUTEセッションで配信されるサービスが、PDI配信サービスであることを通知することができる。
【０２６６】
ステップＳ１６１において、PDI-Qジェネレータ１２１は、PDI-Qを生成する。ステップＳ１６１の処理で生成されたPDI-Qは、アプリケーションサーバ１０５に転送される（Ｓ１６２）。
【０２６７】
ステップＳ１５１において、アプリケーションサーバ１０５は、PDIサーバ１０２からのPDI-Qに基づいて、PDI-Sアプリケーションを生成する。また、ステップＳ１５２において、アプリケーションサーバ１０５は、対象のPDI-Qを、放送サーバ１０６に通知する。
【０２６８】
ステップＳ１８３において、配信処理部１６２は、PDI-Qの配信方式を判定する。ステップＳ１８３において、配信方式が、ファイルモード配信（File Mode）であると判定された場合、処理は、ステップＳ１８４に進められる。
【０２６９】
ステップＳ１８４において、配信処理部１６２は、EFDTに、参照情報として、referredByAppUrl属性を記述する。このreferredByAppUrl属性の値としては、PDI-Sアプリケーションの参照先を示すURL（pdi-sAppUrl）が記述される。
【０２７０】
一方で、ステップＳ１８３において、配信方式が、エンティティ配信（Entity Mode）であると判定された場合、処理は、ステップＳ１８５に進められる。
【０２７１】
ステップＳ１８５において、配信処理部１６２は、HTTPヘッダ（Entityヘッダ）に、参照情報として、referredByAppUrlを記述する。このreferredByAppUrlの値としては、PDI-Sアプリケーションの参照先を示すURL（pdi-sAppUrl）が記述される。
【０２７２】
ステップＳ１８４又はＳ１８５の処理が終了すると、処理は、ステップＳ１８６に進められる。ステップＳ１８６において、送信部１６１は、ファイルモード配信又はエンティティ配信の配信方式に従い、アプリケーションサーバ１０５からのPDI-Qを送信する。
【０２７３】
一方で、ステップＳ１９１においては、図２６のステップＳ１３１と同様に、ESG情報が処理され、必要に応じて提示される。なお、PDI-Qが配信予定である場合には、ESG情報のServiceType要素として、"PDI delivery service"が記述されているため、対象の配信予定のサービスが、PDI配信サービスであることを認識することができる。
【０２７４】
ステップＳ１９２においては、図２６のステップＳ１３２と同様に、SLTメタデータが処理される。ここでは、PDI-Qが配信される場合には、SLTメタデータのServiceCategory属性として、"PDI delivery service"が記述されているので、放送ミドルウェア２０５は、SLTメタデータのパース結果に従い、PDI配信サービスが配信されるROUTEセッションを特定し、PDI-Qを取得する（Ｓ１９３）。
【０２７５】
そして、ステップＳ１９４においては、図２６のステップＳ１３４と同様に、ROUTEセッションから取得したPDI-QがPDIストア２６１に格納される。なお、ここでも同様に、PDI-Qの格納、更新、又は削除が行われる。
【０２７６】
ここで、パターン２のPDI対応処理の場合には、アプリケーションサーバ１０５により生成されるPDI-Sアプリケーションが、放送サーバ１０６に転送される（Ｓ１５３）。そして、ステップＳ１８７において、送信部１６１は、アプリケーションサーバ１０５からのPDI-Sアプリケーションを送信する。
【０２７７】
一方で、ステップＳ２０１において、PDIクライアント２４１は、PDIストア２６１に格納されたPDI-Qを読み出す。また、ステップＳ２０２において、PDIクライアント２４１は、参照情報（PDI-S Ref）に対応したPDI-Sアプリケーションを取得して起動する。
【０２７８】
すなわち、参照情報としてのPDI-Sアプリケーションの取得先を示すURL（pdi-sAppUrl）は、配信方式が、ファイルモード配信である場合には、EFDTのreferredByAppUrl属性により指定され、エンティティ配信である場合には、HTTPヘッダのreferredByAppUrlにより指定される。この参照情報（URL）を用いることで、放送配信されるPDI-Sアプリケーションを取得することができる。
【０２７９】
なお、ここでは、PDI-Sアプリケーションが、ROUTEセッションにより、放送配信される例を説明したが、通信サーバ１０７から通信配信されるようにしてもよい。この場合、クライアント装置２０は、参照情報（URL）に従い、インターネット５０を介して通信サーバ１０７にアクセスし、PDI-Sアプリケーションを取得することになる。
【０２８０】
このようにして放送経由又は通信経由で取得されたPDI-Sアプリケーションは、ブラウザ２０９上で起動され、PDIストア２６１から読み出されたPDI-Qに応じてPDI-A（クライアント側PDI-A）を生成し、PDIストア２６１に格納する（Ｓ２１１）。
【０２８１】
ここでは、図２６のステップＳ１４２と同様に、PDI-Qで定義されている質問に対する回答を、ディスプレイに表示させて、エンドユーザによる質問に対する回答の入力又は選択を受け付けることで、その回答の入力又は選択の結果に応じたPDI-Aが生成され、PDIストア２６１に格納される。ここでも同様に、PDI配信サービスの画面（図２７）を表示させることができる。
【０２８２】
なお、上述したように、ステップＳ２１１の処理では、エンドユーザの視聴履歴情報等を参照して、エンドユーザの嗜好を類推することで、PDI-Aが生成されるようにしてもよい。
【０２８３】
以上、パターン２のPDI対応処理の流れについて説明した。
【０２８４】
（２）第２のPDI処理方式
【０２８５】
第２のPDI処理方式においては、サブリソースとしてのPDI-Qを、PDI-Sアプリケーションとともに配信する方式である。この第２のPDI処理方式では、PDI-Sアプリケーションが、PDI-Aを生成し、PDIストア２６１に格納することになる。
【０２８６】
すなわち、第２のPDI処理方式では、送信側システム１０側でPDI-Qインスタンスが生成されるか、あるいは、一旦配信されたPDI-Qインスタンスが更新される場合に、生成又は更新されるPDI-Q（PDI-Qインスタンス）が、PDI-Sアプリケーションのサブリソースとして配信されるようにする。そして、クライアント装置２０では、PDI-Sアプリケーションが、サブリソースとしてのPDI-Qをパースして、対応するPDI-Aを生成することができる。
【０２８７】
そのため、放送局側の意向に正確に基づいて、クライアント装置２０側における対応するPDI-Aの生成を、精度よく確実に行うことが可能となり、かつ、クライアント装置２０側のPDI対応処理の負担を軽減することができる。
【０２８８】
（第２のPDI処理方式の全体像）
図３０は、第２のPDI処理方式の全体像を示す図である。
【０２８９】
図３０に示すように、SLTメタデータのService要素のserviceCategory属性として、serviceCategory = "Linear TV"又は"App-based"が指定されたApp・PDI-Q配信用のサービスのROUTEセッションでは、PDI-Sアプリケーションと、そのサブリソースとしてのPDI-Qのファイルが転送されている。
【０２９０】
ここで、クライアント装置２０においては、アプリケーションマネージャ２２２が、放送ミドルウェア２０５を介して、App・PDI-Q配信用のサービスのROUTEセッションで配信されるPDI-Sアプリケーションを取得して、ブラウザ２０９上で起動する。なお、ここでは、放送配信されるPDI-Sアプリケーションのほか、インターネット５０を介して通信配信されるPDI-Sアプリケーションが取得されるようにしてもよい。
【０２９１】
また、同一のROUTEセッションで配信されるPDI-Qは、ブラウザ２０９上で起動されたPDI-Sアプリケーション内で参照されて処理される。
【０２９２】
そして、当該PDI-Sアプリケーションが、サブリソースとしてのPDI-Qに基づいて、例えば、図１２の対話画面などにより、エンドユーザとの間で必要なインタラクションを行うことで、対応するPDI-A（クライアント側PDI-A）を生成する。生成されたPDI-A（クライアント側PDI-A）は、PDIストア２６１に格納される。
【０２９３】
（PDI-SアプリケーションとPDI-Qの配信の詳細）
図３１は、PDI-SアプリケーションとPDI-Qの配信の詳細を示す図である。
【０２９４】
図３１においては、SLSシグナリングセッションで運ばれるSLSと、PDIファイルセッションで運ばれるPDI-Qと、放送配信又は通信配信されるPDI-Sアプリケーションとの関係を表している。
【０２９５】
なお、SLSシグナリングセッション（TSI = "sls-tsi"）は、パッケージモードで配信され、PDIファイルセッション（TSI = "app-tsi"）は、ファイルモードで配信される。
【０２９６】
SLSシグナリングセッションにおいては、特定のTOI（TOI = "0"）で識別されるUSDフラグメント（USBDメタデータ）と、S-TSIDフラグメント（S-TSIDメタデータ）と、HELDフラグメント（HELDメタデータ）が転送される。USDフラグメントを取得することで、S-TSIDフラグメントとHELDフラグメントを参照することができる。
【０２９７】
S-TSIDフラグメントでは、LS要素のtsi属性の値として、tsi = "app-tsi"が指定されているが、このtsi属性の値により、PDIファイルセッションが参照される。このPDIファイルセッションでは、EFDTと、PDI-Qのファイルと、PDI-Sアプリケーションのファイルとが転送される。
【０２９８】
ここで、放送配信されるPDI-Sアプリケーションを取得（起動）する場合には、例えば、次のような処理が行われる。
【０２９９】
すなわち、クライアント装置２０では、HELDフラグメントのHTMLEntryPageEntryUrl要素の値（appEntryUrl）と、EFDTのFDTParameters要素のFile要素のContent-Location属性の値（appEntryUrl）とのマッチング処理を行い、TOI（appEntryToi）を特定することで、PDIファイルセッションで転送されるPDI-Sアプリケーションのファイルを取得することができる。
【０３００】
そして、クライアント装置２０では、放送配信されたPDI-Sアプリケーションが起動され、当該PDI-Sアプリケーション内で、同一のPDIファイルセッションで転送されるPDI-Qのファイル（サブリソース）が参照されて処理されることになる。
【０３０１】
一方で、通信配信されるPDI-Sアプリケーションを取得（起動）する場合には、例えば、次のような処理が行われる。
【０３０２】
すなわち、クライアント装置２０では、HELDフラグメントのalternateEntryUrl要素の値（appEntryUrl）に基づいて、インターネット５０を介して通信サーバ１０７から配信されるPDI-Sアプリケーションのファイルを取得することができる。
【０３０３】
そして、クライアント装置２０では、通信配信されたPDI-Sアプリケーションが起動され、当該PDI-Sアプリケーション内で、PDIファイルセッションで転送されるか、若しくは、PDI-Sアプリケーション内に記述されるURL(pdi-qUrl)に基づいて、インターネット５０を介して通信サーバ１０７から配信されるPDI-Qのファイル（サブリソース）が参照されて処理されることになる。
【０３０４】
（PDI対応処理の流れ）
次に、図３２のフローチャートを参照して、第２のPDI処理方式の場合の送信側と受信側の各装置で実行されるPDI対応処理の流れを説明する。
【０３０５】
なお、図３２において、ステップＳ２５１乃至Ｓ２５２、Ｓ２６１乃至Ｓ２６２、及びＳ２７１の処理は、送信側システム１０のアプリケーションサーバ１０５、PDIサーバ１０２、及び放送サーバ１０６によりそれぞれ実行される。
【０３０６】
一方で、ステップＳ２８１及びＳ２９１の処理は、クライアント装置２０のアプリケーションマネージャ２２２及びブラウザ２０９により実行される。
【０３０７】
ステップＳ２６１において、PDI-Qジェネレータ１２１は、PDI-Qを生成する。ステップＳ２６１の処理で生成されたPDI-Qは、アプリケーションサーバ１０５に転送される（Ｓ２６２）。
【０３０８】
ステップＳ２５１において、アプリケーションサーバ１０５は、PDIサーバ１０２からのPDI-Qに基づいて、PDI-Sアプリケーションを生成する。また、ステップＳ２５２において、アプリケーションサーバ１０５は、PDI-Sアプリケーションとともに、対象のPDI-Q（サブリソース）を、放送サーバ１０６に転送する。
【０３０９】
ステップＳ２７１において、送信部１６１は、アプリケーションサーバ１０５からのPDI-Sアプリケーションと、サブリソースとしてのPDI-Qを送信する。
【０３１０】
一方で、ステップＳ２８１において、アプリケーションマネージャ２２２は、放送ミドルウェア２０５を介して、ROUTEセッションで配信されるPDI-Sアプリケーションを取得して起動する。このPDI-Sアプリケーションは、ブラウザ２０９上で起動され、サブリソースとしてのPDI-Qに応じてPDI-A（クライアント側PDI-A）を生成し、PDIストア２６１に格納する（Ｓ２９１）。
【０３１１】
ここでは、ブラウザ２０９上で実行されるPDI-Sアプリケーションが、PDI-Qに基づいて、例えば、図１２の対話画面などにより、エンドユーザとの間で必要なインタラクションを行うことで、対応するPDI-A（クライアント側PDI-A）を生成することができる。
【０３１２】
以上、PDI対応処理の流れについて説明した。
【０３１３】
なお、第２のPDI処理方式のバリエーションとしては、PDI-Qインスタンスのファイルそのものを生成せずに、PDI-S機能を包含したアプリケーションのみを配信して、クライアント装置２０側で、PDI-Aの生成を行うケースがある。なお、このアプリケーションとしては、例えば、PDI-Qの内容をハードコードしたものや、アプリケーションロジックにインテグレートしたものなどが想定される。
【０３１４】
（３）PDIを利用したコンテンツフィルタリング処理
【０３１５】
（コンテンツフィルタリング処理の流れ）
次に、上述したPDIを利用したコンテンツフィルタリング処理について説明する。図３３及び図３４は、PDIを利用したコンテンツフィルタリング処理の流れを説明するフローチャートである。
【０３１６】
なお、図３３及び図３４において、ステップＳ３０１乃至Ｓ３０２、Ｓ３１１乃至Ｓ３１２、Ｓ３２１乃至Ｓ３２３、及びＳ３３１乃至Ｓ３３２の処理は、送信側システム１０のPDIサーバ１０２、コンテンツサーバ１０１、メタデータサーバ１０４、及び放送サーバ１０６によりそれぞれ実行される。
【０３１７】
一方で、ステップＳ３４１乃至Ｓ３４２、Ｓ３５１乃至Ｓ３５２、及びＳ３６１は、クライアント装置２０の放送ミドルウェア２０５、フィルタリング処理部２２３、及びレンダラ２０７により実行される。
【０３１８】
また、このコンテンツフィルタリング処理に先立って、クライアント装置２０では、上述した第１のPDI処理方式（パターン１）のPDI対応処理（図２６）、第１のPDI処理方式（パターン２）のPDI対応処理（図２８，図２９）、又は第２のPDI処理方式のPDI対応処理（図３２）が実行され、PDIストア２６１に、PDI-A（クライアント側PDI-A）が格納されているものとする。
【０３１９】
ステップＳ３０１において、PDI-Qジェネレータ１２１は、PDI-Qを生成する。ここで生成されたPDI-Qは、メタデータサーバ１０４に転送される（Ｓ３０２）。
【０３２０】
ステップＳ３２１において、PDI-Aジェネレータ１４３は、PDIサーバ１０２からのPDI-Qに基づいて、対象のコンテンツをフィルタリングするためのPDI-A（プロバイダ側PDI-A）を生成する。
【０３２１】
ここでは、例えば、放送局等のプロバイダのスタッフ（コンテンツの提供者）の操作に応じて、PDI-Qが生成された場合に、PDI-Qで定義されている質問に対する回答を、ディスプレイに表示させて（例えば、図１２の対話画面）、プロバイダのスタッフに、その質問に対する回答を入力又は選択させることで、その回答を表すPDI-A（プロバイダ側PDI-A）を生成する。
【０３２２】
ステップＳ３２２において、ESG処理部１４１は、ESG情報に、PDI-A（プロバイダ側PDI-A）を格納する。また、メタデータ処理部１４２は、MPDメタデータに、PDI-A（プロバイダ側PDI-A）を格納する。
【０３２３】
なお、PDI-A（プロバイダ側PDI-A）は、ESG情報又はMPDメタデータのうち、少なくとも一方に格納されるようにすればよい。ここで生成されたESG情報やMPDメタデータは、放送サーバ１０６に転送される（Ｓ３２３）。
【０３２４】
ステップＳ３１１において、コンテンツサーバ１０１は、配信対象のコンテンツを処理する。この処理で得られるストリームデータ（DASHセグメント）は、放送サーバ１０６に転送される（Ｓ３１２）。
【０３２５】
ステップＳ３３１において、送信部１６１は、メタデータサーバ１０４からのESG情報やMPDメタデータを送信する。また、ステップＳ３３２において、送信部１６１は、コンテンツサーバ１０１からのコンテンツのストリームデータを送信する。
【０３２６】
一方で、ステップＳ３４１において、放送ミドルウェア２０５は、チューナ２０４により受信された放送信号から得られるESG情報やMPDメタデータを処理する。ここで、ESG情報又はMPDメタデータには、PDI-A（プロバイダ側PDI-A）が含まれているので、このプロバイダ側PDI-Aのパース結果が、フィルタリング処理部２２３に通知される。
【０３２７】
ステップＳ３５１において、フィルタリング処理部２２３は、PDIストア２６１に格納されているPDI-A（クライアント側PDI-A）を照会して、ESG情報又はMPDメタデータに含まれるPDI-A（プロバイダ側PDI-A）とのマッチング処理を行い、取得対象のコンテンツを特定する。
【０３２８】
また、ステップＳ３４２において、放送ミドルウェア２０５は、放送信号から得られるコンテンツのストリームデータを処理する。
【０３２９】
ステップＳ３５２において、フィルタリング処理部２２３は、特定のコンテンツのフィルタリングを行い、マッチング処理結果に応じたコンテンツのストリームデータを取得する。
【０３３０】
ここでは、図３５のESG画面の例に示すように、マッチング処理結果に応じて、PDI-Aのマッチング度合いが高い順に、コンテンツのリストとして表示することができる。図３５のESG画面の例では、コンテンツ１、コンテンツ２、コンテンツ３の順に、PDI-Aのマッチング度合いが高いことを表している。
【０３３１】
このようなESG画面を提示することで、エンドユーザは、PDI-Aのマッチング度合いの高いコンテンツを優先的に選択することができる。
【０３３２】
なお、図３５に示したESG画面は、フィルタリング処理結果を提示するための画面の一例であって、他の表示形態で表示されるようにしてもよい。
【０３３３】
図３４に戻り、ステップＳ３６１において、レンダラ２０７は、フィルタリングの結果得られるコンテンツのストリームデータをレンダリングする。
【０３３４】
ここでは、例えば、図３５のESG画面のリストから、エンドユーザにより、コンテンツ１が選択された場合、コンテンツ１のストリームデータがレンダリングされ、コンテンツ１の映像と音声が再生（又は録画）される。これにより、エンドユーザの嗜好に応じたコンテンツが再生（又は録画）されることになる。
【０３３５】
以上、コンテンツフィルタリング処理の流れについて説明した。
【０３３６】
＜４．変形例＞
【０３３７】
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
【０３３８】
また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０３３９】
さらに、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV：Common Antenna TeleVision）等の有線放送などの規格に適用することができる。
【０３４０】
（その他の変形例）
上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報などの実質的な内容が異なるものではない。
【０３４１】
例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)と称され、ESG(Electronic Service Guide)は、EPG(Electronic Program Guide)と称される場合がある。さらに、例えば、HELD(HTTP Entry Location Description)は、AST(Application Signaling Table)やAIT(Application Information Table)などと称される場合がある。
【０３４２】
なお、アプリケーションとしては、HTML5などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。
【０３４３】
また、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
【０３４４】
＜５．コンピュータの構成＞
【０３４５】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３６は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３４６】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０３４７】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０３４８】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０３４９】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３５０】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０３５１】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３５２】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３５３】
また、本技術は、以下のような構成をとることができる。
【０３５４】
（１）
コンテンツを受信する受信部と、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報を処理する処理部と
を備える受信装置。
（２）
前記処理部は、
前記第１の回答情報を生成し、
前記第１の回答情報と、前記質問に対して前記コンテンツを提供する提供者により設定された回答を表す第２の回答情報とのマッチング処理を行い、
前記マッチング処理の結果に従い、前記コンテンツのフィルタリング処理を行う
前記（１）に記載の受信装置。
（３）
前記処理部は、前記配信情報に基づいて、前記サービスを特定する
前記（２）に記載の受信装置。
（４）
前記配信情報は、前記コンテンツとともに配信される制御情報に含まれ、
前記処理部は、前記制御情報に含まれる前記配信情報に基づいて、前記サービスで配信される前記質問情報を取得する
前記（３）に記載の受信装置。
（５）
前記配信情報は、前記コンテンツに対して事前に配信される番組情報に含まれ、
前記処理部は、前記番組情報に含まれる前記配信情報に基づいて、前記サービスの配信を事前に通知する
前記（３）に記載の受信装置。
（６）
前記処理部は、前記参照情報に基づいて、前記アプリケーションを取得して起動することで、前記第１の回答情報を生成する
前記（２）乃至（５）のいずれかに記載の受信装置。
（７）
前記参照情報は、前記サービスを配信するためのセッションの制御情報に含まれ、
前記処理部は、前記制御情報に含まれる前記参照情報に基づいて、前記アプリケーションを取得する
前記（６）に記載の受信装置。
（８）
前記参照情報は、前記サービスを配信するためのセッションで配信される前記質問情報のファイルのヘッダに含まれ、
前記処理部は、前記ヘッダに含まれる前記参照情報に基づいて、前記アプリケーションを取得する
前記（６）に記載の受信装置。
（９）
前記コンテンツは、IP(Internet Protocol)伝送方式を用いたデジタル放送により放送配信される
前記（１）乃至（８）のいずれかに記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報に基づいて、前記コンテンツとともに配信される、前記質問を表す質問情報を処理する
ステップを含むデータ処理方法。
（１１）
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報を生成する生成部と、
コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報を送信する送信部と
を備える送信装置。
（１２）
前記生成部は、前記質問に対してコンテンツを提供する提供者により設定された回答を表す第２の回答情報であって、前記第１の回答情報とのマッチング処理に用いられる前記第２の回答情報を生成し、
前記送信部は、前記第２の回答情報を送信する
前記（１１）に記載の送信装置。
（１３）
前記配信情報は、前記コンテンツとともに配信される制御情報に含まれる
前記（１２）に記載の送信装置。
（１４）
前記配信情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
前記（１２）に記載の送信装置。
（１５）
前記参照情報は、前記サービスを配信するためのセッションの制御情報に含まれる
前記（１２）乃至（１４）のいずれかに記載の送信装置。
（１６）
前記参照情報は、前記サービスを配信するためのセッションで配信される前記質問情報のファイルのヘッダに含まれる
前記（１２）乃至（１４）のいずれかに記載の送信装置。
（１７）
前記第２の回答情報は、前記コンテンツとともに配信される制御情報に含まれる
前記（１２）乃至（１６）のいずれかに記載の送信装置。
（１８）
前記第２の回答情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
前記（１２）乃至（１６）のいずれかに記載の送信装置。
（１９）
前記コンテンツは、IP伝送方式を用いたデジタル放送により放送配信される
前記（１１）乃至（１８）のいずれかに記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
エンドユーザの嗜好を表現する動的なメタデータを提供するサービスが配信されていることを示す配信情報、及び、エンドユーザの嗜好についての質問に対してエンドユーザにより設定された回答を表す第１の回答情報を生成するアプリケーションの参照先を示す参照情報のうち少なくとも一方の情報を生成し、
コンテンツとともに、前記質問を表す質問情報と、前記配信情報及び前記参照情報のうち、少なくとも一方の情報を送信する
ステップを含むデータ処理方法。
【符号の説明】
【０３５５】
１  伝送システム，  １０  送信側システム，  ２０  クライアント装置，  ３０  送信所，  ４０  伝送路，  ５０  インターネット，  １０１  コンテンツサーバ，  １０２  PDIサーバ，  １０３  ESGサーバ，  １０４  メタデータサーバ，  １０５  アプリケーションサーバ，  １０６  放送サーバ，  １０７  通信サーバ，  １２１  PDI-Qジェネレータ，  １４１  ESG処理部，  １４２  メタデータ処理部，  １４３  PDI-Aジェネレータ，  １６１  送信部，  １６２  配信処理部，  ２０１  処理部，  ２０２  入力部，  ２０３  記憶部，  ２０４  チューナ，  ２０５  放送ミドルウェア，  ２０６  DASHクライアント，  ２０７  レンダラ，  ２０８  出力部，  ２０９  ブラウザ，  ２１０  通信I/F，  ２２１  ネイティブモジュール，  ２２２  アプリケーションマネージャ，  ２２３  フィルタリング処理部，  ２４１  PDIクライアント，  ２６１  PDIストア，  １０００  コンピュータ，  １００１  CPU
【図１】
2018074265.tif 000003
【図２】
2018074265.tif 000004
【図３】
2018074265.tif 000005
【図４】
2018074265.tif 000006
【図５】
2018074265.tif 000007
【図６】
2018074265.tif 000008
【図７】
2018074265.tif 000009
【図８】
2018074265.tif 000010
【図９】
2018074265.tif 000011
【図１０】
2018074265.tif 000012
【図１１】
2018074265.tif 000013
【図１２】
2018074265.tif 000014
【図１３】
2018074265.tif 000015
【図１４】
2018074265.tif 000016
【図１５】
2018074265.tif 000017
【図１６】
2018074265.tif 000018
【図１７】
2018074265.tif 000019
【図１８】
2018074265.tif 000020
【図１９】
2018074265.tif 000021
【図２０】
2018074265.tif 000022
【図２１】
2018074265.tif 000023
【図２２】
2018074265.tif 000024
【図２３】
2018074265.tif 000025
【図２４】
2018074265.tif 000026
【図２５】
2018074265.tif 000027
【図２６】
2018074265.tif 000028
【図２７】
2018074265.tif 000029
【図２８】
2018074265.tif 000030
【図２９】
2018074265.tif 000031
【図３０】
2018074265.tif 000032
【図３１】
2018074265.tif 000033
【図３２】
2018074265.tif 000034
【図３３】
2018074265.tif 000035
【図３４】
2018074265.tif 000036
【図３５】
2018074265.tif 000037
【図３６】
2018074265.tif 000038
【国際調査報告】
2018074265.tif 000039
2018074265.tif 000040