(57)【要約】【課題】視聴履歴に関する運用を柔軟に行うことができるようにする。【解決手段】受信装置は、IP伝送方式を用いたデジタル放送の放送波を受信し、放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得し、取得された宛先情報に基づいて、視聴履歴情報を、通信回線を介して視聴履歴サーバ宛てに送信する制御を行う。本技術は、例えば、IP伝送方式に対応したテレビ受像機に適用することができる。【選択図】図１
2017011503.tif 000002
【特許請求の範囲】
【請求項１】
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、
前記放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得する取得部と、
取得された前記宛先情報に基づいて、前記視聴履歴情報を、通信回線を介して前記視聴履歴サーバ宛てに送信する制御を行う制御部と
を備える受信装置。
【請求項２】
前記宛先情報は、前記コンテンツの選局処理を制御するための情報を含む第１の制御情報に含めて伝送され、
前記取得部は、前記第１の制御情報に含まれる前記宛先情報を取得する
請求項１に記載の受信装置。
【請求項３】
前記第１の制御情報は、前記宛先情報を、前記コンテンツのサービスごとに指定するか、又は、前記サービスで共通になるように指定する
請求項２に記載の受信装置。
【請求項４】
前記第１の制御情報は、
IPパケットに含まれるUDP(User Datagram Protocol)パケットに配置されて伝送され、
ROUTE(Real-Time Object Delivery over Unidirectional Transport)セッション又はMMT(MPEG Media Transport)セッションで伝送される第２の制御情報に先行して取得される
請求項２に記載の受信装置。
【請求項５】
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのウォータマークに含めて伝送され、
前記取得部は、前記ウォータマークに含まれる前記宛先情報を取得する
請求項１に記載の受信装置。
【請求項６】
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのユーザデータに含めて伝送され、
前記取得部は、前記ユーザデータに含まれる前記宛先情報を取得する
請求項１に記載の受信装置。
【請求項７】
前記宛先情報は、前記コンテンツを構成する字幕を表示するためのTTML(Timed Text Markup Language)形式のTTML文書のメタデータに含めて伝送され、
前記取得部は、前記TTML文書のメタデータに含まれる前記宛先情報を取得する
請求項１に記載の受信装置。
【請求項８】
前記視聴履歴情報を管理する管理部をさらに備える
請求項１に記載の受信装置。
【請求項９】
前記IP伝送方式は、ATSC(Advanced Television Systems Committee)3.0に準拠し、
前記宛先情報は、前記視聴履歴サーバのURL(Uniform Resource Locator)であり、
前記視聴履歴情報は、ATSCで規定されるCDM(Consumption Data Message)である
請求項１に記載の受信装置。
【請求項１０】
受信装置のデータ処理方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得し、
取得された前記宛先情報に基づいて、前記視聴履歴情報を、通信回線を介して前記視聴履歴サーバ宛てに送信する制御を行う
ステップを含むデータ処理方法。
【請求項１１】
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を生成する生成部と、
生成された前記宛先情報を、前記コンテンツとともに、前記放送波で送信する送信部と
を備える送信装置。
【請求項１２】
前記宛先情報は、前記コンテンツの選局処理を制御するための情報を含む第１の制御情報に含めて伝送される
請求項１１に記載の送信装置。
【請求項１３】
前記第１の制御情報は、前記宛先情報を、前記コンテンツのサービスごとに指定するか、又は、前記サービスで共通になるように指定する
請求項１２に記載の送信装置。
【請求項１４】
前記第１の制御情報は、
IPパケットに含まれるUDPパケットに配置されて伝送され、
ROUTEセッション又はMMTセッションで伝送される第２の制御情報に先行して取得される
請求項１２に記載の送信装置。
【請求項１５】
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのウォータマークに含めて伝送される
請求項１１に記載の送信装置。
【請求項１６】
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのユーザデータに含めて伝送される
請求項１１に記載の送信装置。
【請求項１７】
前記宛先情報は、前記コンテンツを構成する字幕を表示するためのTTML形式のTTML文書のメタデータに含めて伝送される
請求項１１に記載の送信装置。
【請求項１８】
前記生成部は、前記宛先情報の変更依頼に応じて、前記宛先情報の内容を変更する
請求項１１に記載の送信装置。
【請求項１９】
前記IP伝送方式は、ATSC3.0に準拠し、
前記宛先情報は、前記視聴履歴サーバのURLであり、
前記視聴履歴情報は、ATSCで規定されるCDMである
請求項１１に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を生成し、
生成された前記宛先情報を、前記コンテンツとともに、前記放送波で送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、視聴履歴に関する運用を柔軟に行うことができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
放送の分野では、ユーザによるコンテンツの視聴履歴を収集して分析するなどの視聴履歴に関する運用が行われる場合がある。例えば、視聴履歴を、定期的に又は必要なときに伝送する技術が開示されている(例えば、特許文献１参照)。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−２７８６５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、視聴履歴に関する運用を行うための技術方式が確立されていないため、視聴履歴に関する運用を柔軟に行うための提案が要請されていた。
【０００５】
本技術はこのような状況に鑑みてなされたものであり、視聴履歴に関する運用を柔軟に行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、前記放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得する取得部と、取得された前記宛先情報に基づいて、前記視聴履歴情報を、通信回線を介して前記視聴履歴サーバ宛てに送信する制御を行う制御部とを備える受信装置である。
【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。
【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報が取得され、取得された前記宛先情報に基づいて、前記視聴履歴情報が、通信回線を介して前記視聴履歴サーバ宛てに送信される制御が行われる。
【０００９】
本技術の第２の側面の送信装置は、IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を生成する生成部と、生成された前記宛先情報を、前記コンテンツとともに、前記放送波で送信する送信部とを備える送信装置である。
【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。
【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報が生成され、生成された前記宛先情報が、前記コンテンツとともに、前記放送波で送信される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、視聴履歴に関する運用を柔軟に行うことができる。
【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】送信装置の構成例を示す図である。
【図３】受信装置の構成例を示す図である。
【図４】制御部の機能的構成例を示す図である。
【図５】視聴履歴サーバの構成例を示す図である。
【図６】本技術を適用したIP伝送方式のプロトコルスタックを示す図である。
【図７】視聴履歴情報(CDM)の収集例を示す図である。
【図８】CDMのシンタックスの例を示す図である。
【図９】従来の視聴履歴サーバURLの通知方法を示す図である。
【図１０】シグナリングを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【図１１】シグナリングを利用した場合における視聴履歴サーバURLの方式１の通知方法を示す図である。
【図１２】SLTのシンタックスの例を示す図である。
【図１３】SLTに配置される記述子の例を示す図である。
【図１４】シグナリングロケーション記述子のシンタックスの例を示す図である。
【図１５】URL_typeの例を示す図である。
【図１６】送信処理を説明するフローチャートである。
【図１７】シグナリングを利用した場合における視聴履歴サーバURL通知処理を説明するフローチャートである。
【図１８】初期スキャン処理を説明するフローチャートである。
【図１９】ストリーム・SLT取得処理を説明するフローチャートである。
【図２０】サービス切り替え時のSLT取得処理を説明するフローチャートである。
【図２１】視聴時のSLT取得処理を説明するフローチャートである。
【図２２】視聴履歴情報記録処理を説明するフローチャートである。
【図２３】視聴履歴情報送信処理を説明するフローチャートである。
【図２４】視聴履歴情報収集・分析処理を説明するフローチャートである。
【図２５】ビデオウォータマークを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【図２６】ビデオウォータマークを利用した場合における視聴履歴サーバURLの通知方法を示す図である。
【図２７】ウォータマークペイロードのシンタックスの例を示す図である。
【図２８】WMメッセージのシンタックスの例を示す図である。
【図２９】URIメッセージのシンタックスの例を示す図である。
【図３０】uri_typeの例を示す図である。
【図３１】ビデオウォータマークを利用した場合における視聴履歴サーバURL通知処理を説明するフローチャートである。
【図３２】ビデオウォータマークを利用した場合における視聴履歴サーバURL取得処理を説明するフローチャートである。
【図３３】オーディオユーザデータを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【図３４】SYSメタフレームのシンタックスの例を示す図である。
【図３５】sysTypeの例を示す図である。
【図３６】sysDataの例を示す図である。
【図３７】オーディオユーザデータを利用した場合における視聴履歴サーバURL通知処理を説明するフローチャートである。
【図３８】オーディオユーザデータを利用した場合における視聴履歴サーバURL取得処理を説明するフローチャートである。
【図３９】TTML文書のメタデータを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【図４０】TTML文書の記述例を示す図である。
【図４１】TTML文書のメタデータを利用した場合における視聴履歴サーバURL通知処理を説明するフローチャートである。
【図４２】TTML文書のメタデータを利用した場合における視聴履歴サーバURL取得処理を説明するフローチャートである。
【図４３】XML形式のSLTのシンタックスの例を示す図である。
【図４４】XML形式のSLTのシンタックスの例を示す図である。
【図４５】XML形式のSLTのシンタックスの例を示す図である。
【図４６】XML形式のSLTのシンタックスの例を示す図である。
【図４７】XML形式のシグナリングロケーション記述子のシンタックスの例を示す図である。
【図４８】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．システムの構成
２．本技術の概要
３．具体的な運用例
（１）方式１：シグナリングを利用した視聴履歴サーバURLの伝送
（２）方式２：ビデオウォータマークを利用した視聴履歴サーバURLの伝送
（３）方式３：オーディオユーザデータを利用した視聴履歴サーバURLの伝送
（４）方式４：TTML文書のメタデータを利用した視聴履歴サーバURLの伝送
４．変形例
５．コンピュータの構成
【００１７】
＜１．システムの構成＞
【００１８】
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合した物をいう。
【００１９】
伝送システム１は、送信装置１０−１乃至１０−Ｎ(Ｎは１以上の整数)、受信装置２０−１乃至２０−Ｍ(Ｍは１以上の整数)、視聴履歴サーバ３０、送信設備４０、及び、配信装置５０から構成される。また、受信装置２０−１乃至２０−Ｍと、視聴履歴サーバ３０とは、通信回線６０を介して相互に接続されている。
【００２０】
送信装置１０−１は、放送局Ａにより設置される、ATSC(Advanced Television Systems Committee)等のデジタル放送の規格に対応した送信機である。送信装置１０−１は、コンテンツ(例えばテレビ番組など)やシグナリングを含むデジタル放送信号を、送信設備４０を介して送信する。また、送信装置１０−１は、コンテンツ等を含むデジタル放送信号を、配信装置５０に送信する。なお、配信装置５０は、ケーブルテレビ(CATV)や衛星放送などの有料放送を提供するMVPD(Multichannel Video Programming Distributors)により設置され、送信装置１０−１により提供されるコンテンツを配信する。
【００２１】
送信装置１０−２乃至１０−Ｎは、放送局Ｂや放送局Ｚ等の各放送局により設置される。送信装置１０−２乃至１０−Ｎは、コンテンツやシグナリングを含むデジタル放送信号を、送信設備４０又は配信装置５０を介して送信する。なお、以下の説明において、送信装置１０−１乃至１０−Ｎを、特に区別する必要がない場合には、送信装置１０と称して説明する。
【００２２】
受信装置２０−１は、ATSC等のデジタル放送の規格に対応した受信機であって、例えば、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。また、受信装置２０−１は、例えば車載テレビなどの自動車に搭載される機器であってもよい。
【００２３】
受信装置２０−１は、送信装置１０から、電波塔としての送信設備４０を介して送信されてくるデジタル放送信号を、アンテナにより受信(直接受信)し、ユーザによるサービス(チャンネル)の選局操作に応じたコンテンツ(例えばテレビ番組など)を再生する。また、受信装置２０−１は、コンテンツの視聴履歴に関する視聴履歴情報を記録(蓄積)している。ここで、視聴履歴情報としては、ATSCで規定されるCDM(Consumption Data Message)を用いることができる。受信装置２０−１は、視聴履歴サーバ３０のURL(Uniform Resource Locator)に従い、視聴履歴情報(CDM)を、通信回線６０を介して視聴履歴サーバ３０に送信する。
【００２４】
なお、視聴履歴サーバ３０のURL(以下、視聴履歴サーバURLという)は、送信装置１０からのデジタル放送信号に含めて送信されてくるので、受信装置２０−１は、デジタル放送信号に含まれる視聴履歴サーバURLを取得して保持しておくことになる。この視聴履歴サーバURLの伝送方法としては、シグナリングを利用した方式である方式１、ビデオウォータマークを利用した方式である方式２、オーディオユーザデータを利用した方式である方式３、及び、TTML文書のメタデータを利用した方式である方式４があるが、その詳細については、後述するものとする。
【００２５】
受信装置２０−２は、受信装置２０−１と同様に、例えば、テレビ受像機等の固定受信機や、スマートフォン等のモバイル受信機などである。受信装置２０−２は、送信装置１０から、MVPDの配信装置５０を経由して配信されるコンテンツ(のデジタル放送信号)を受信(間接受信)し、サービスの選局操作に応じたコンテンツを再生する。
【００２６】
また、受信装置２０−２は、受信装置２０−１と同様に、コンテンツの視聴履歴情報(CDM)を記録(蓄積)するとともに、視聴履歴サーバURLに従い、視聴履歴情報(CDM)を、通信回線６０を介して視聴履歴サーバ３０に送信する。
【００２７】
受信装置２０−３乃至２０−Ｍは、受信装置２０−１や受信装置２０−２と同様に、例えば、テレビ受像機等の固定受信機や、スマートフォン等のモバイル受信機などである。
【００２８】
受信装置２０−３乃至２０−Ｍは、送信装置１０から、送信設備４０を介して送信されてくるデジタル放送信号を受信(直接受信)するか、あるいは、MVPDの配信装置５０を経由して配信されるコンテンツ(のデジタル放送信号)を受信(間接受信)して、サービスの選局操作に応じたコンテンツを再生する。
【００２９】
また、受信装置２０−３乃至２０−Ｍは、受信装置２０−１や受信装置２０−２と同様に、コンテンツの視聴履歴情報(CDM)を記録(蓄積)するとともに、視聴履歴サーバURLに従い、視聴履歴情報(CDM)を、通信回線６０を介して視聴履歴サーバ３０に送信する。なお、受信装置２０−１乃至２０−Ｍを、特に区別する必要がない場合、受信装置２０と称して説明する。
【００３０】
視聴履歴サーバ３０は、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)を収集して処理するサーバである。視聴履歴サーバ３０は、単独の放送事業者のほか、例えば、複数の放送事業者(例えば放送局Ａ乃至Ｚ)により設立された共同運営の事業者や、放送事業者とは関係のない第三者組織(例えば視聴率調査を専門で行う代理の組織)による事業者などの視聴履歴事業者により提供される。
【００３１】
視聴履歴サーバ３０は、受信装置２０−１乃至２０−Ｍから通信回線６０を介して送信されてくる視聴履歴情報(CDM)を受信して蓄積する(収集する)。そして、視聴履歴サーバ３０は、収集された視聴履歴情報(CDM)に対して、視聴履歴の分析や解析などの各種の処理を行う。例えば、視聴履歴サーバ３０は、放送局ごとの視聴履歴に関する視聴履歴レポートを生成し、各放送局の送信装置１０に提供する。
【００３２】
以上、伝送システム１の構成について説明した。次に、図１の伝送システム１を構成する、送信装置１０、受信装置２０、及び、視聴履歴サーバ３０の構成例について説明する。
【００３３】
（送信装置の構成）
図２は、図１の送信装置１０の構成例を示す図である。
【００３４】
図２において、送信装置１０は、制御部１１１、ビデオデータ取得部１１２、ビデオ処理部１１３、オーディオデータ取得部１１４、オーディオ処理部１１５、字幕データ取得部１１６、字幕処理部１１７、シグナリング生成部１１８、シグナリング処理部１１９、マルチプレクサ１２０、送信部１２１、及び、通信部１２２から構成される。
【００３５】
制御部１１１は、送信装置１０の各部の動作を制御する。
【００３６】
ビデオデータ取得部１１２は、外部のサーバ、カメラ、又は記録媒体等から、コンテンツ(例えばテレビ番組など)のビデオデータ(ビデオのコンポーネント)を取得し、ビデオ処理部１１３に供給する。ビデオ処理部１１３は、ビデオデータ取得部１１２から供給されるビデオデータに対して、例えば、所定の符号化方式に準拠した符号化処理などの処理を施し、マルチプレクサ１２０に供給する。
【００３７】
オーディオデータ取得部１１４は、外部のサーバ、マイクロフォン、又は記録媒体等から、コンテンツ(例えばテレビ番組など)のオーディオデータ(オーディオのコンポーネント)を取得し、オーディオ処理部１１５に供給する。オーディオ処理部１１５は、オーディオデータ取得部１１４から供給されるオーディオデータに対して、例えば、所定の符号化方式に準拠した符号化処理などの処理を施し、マルチプレクサ１２０に供給する。
【００３８】
字幕データ取得部１１６は、外部のサーバ又は記録媒体等から、コンテンツ(例えばテレビ番組など)の字幕データ(字幕のコンポーネント)を取得し、字幕処理部１１７に供給する。字幕処理部１１７は、字幕データ取得部１１６から供給される字幕データに対して、例えば、所定の符号化方式に準拠した符号化処理などの処理を施し、マルチプレクサ１２０に供給する。
【００３９】
シグナリング生成部１１８は、コンテンツの選局や再生等の処理で用いられるシグナリング情報を生成し、シグナリング処理部１１９に供給する。シグナリング処理部１１９は、シグナリング生成部１１８から供給されるシグナリング情報を処理し、マルチプレクサ１２０に供給する。ここでは、例えば、後述するLLS(Link Layer Signaling)シグナリング情報や、SLS(Service Layer Signaling)シグナリング情報が生成され、処理される。
【００４０】
マルチプレクサ１２０は、ビデオ処理部１１３から供給されるビデオストリームと、オーディオ処理部１１５から供給されるオーディオストリームと、字幕処理部１１７から供給される字幕ストリームと、シグナリング処理部１１９から供給されるシグナリング情報とを多重化して、その結果得られる多重化ストリームを、送信部１２１に供給する。
【００４１】
送信部１２１は、マルチプレクサ１２０から供給される多重化ストリームを、アンテナ１３１を介して、デジタル放送の放送波(デジタル放送信号)として送信する。
【００４２】
また、制御部１１１は、視聴履歴サーバURL生成部１５１を含む。視聴履歴サーバURL生成部１５１は、視聴履歴サーバURLを生成する。視聴履歴サーバURL生成部１５１は、方式１乃至方式４の方式に応じて、生成された視聴履歴サーバURLを、シグナリング生成部１１８、ビデオ処理部１１３、オーディオ処理部１１５、又は、字幕処理部１１７に供給する。視聴履歴サーバURLは、方式１乃至方式４の方式に応じて、マルチプレクサ１２０により多重化される多重化ストリームに含まれる。
【００４３】
通信部１２２は、制御部１１１からの制御に従い、各種のネットワーク(不図示)を介して視聴履歴サーバ３０(図１)との間で、データをやりとりする。例えば、通信部１２２は、視聴履歴サーバ３０から送信されてくる視聴履歴レポートを受信し、制御部１１１に供給する。制御部１１１は、通信部１２２から供給される視聴履歴レポートを取得して、例えば、視聴履歴レポートを提示するなどの処理を行う。
【００４４】
（受信装置の構成）
図３は、図１の受信装置２０の構成例を示す図である。
【００４５】
図３において、受信装置２０は、制御部２１１、記録部２１２、入力部２１３、受信部２１４、デマルチプレクサ２１５、ビデオ処理部２１６、ビデオ出力部２１７、オーディオ処理部２１８、オーディオ出力部２１９、字幕処理部２２０、表示部２２１、スピーカ２２２、及び、通信部２２３から構成される。なお、図３の構成では、表示部２２１とスピーカ２２２を含む構成を示しているが、表示部２２１とスピーカ２２２を含めない構成としてもよい。
【００４６】
制御部２１１は、受信装置２０の各部の動作を制御する。記録部２１２は、例えば、NVRAM(Non Volatile RAM)等の不揮発性メモリであって、制御部２１１からの制御に従い、各種のデータを記録する。入力部２１３は、ユーザの操作に応じて、操作信号を制御部２１１に供給する。
【００４７】
受信部２１４は、アンテナ２３１を介して受信されたデジタル放送の放送波(デジタル放送信号)から、サービスの選局操作に応じた信号を抽出して復調し、その結果得られる多重化ストリームを、デマルチプレクサ２１５に供給する。
【００４８】
デマルチプレクサ２１５は、受信部２１４から供給される多重化ストリームを、オーディオやビデオ、字幕のストリームと、シグナリング情報に分離する。デマルチプレクサ２１５は、ビデオデータ(ビデオのコンポーネント)をビデオ処理部２１６に、オーディオデータ(オーディオのコンポーネント)をオーディオ処理部２１８に、字幕データ(字幕のコンポーネント)を字幕処理部２２０に、シグナリング情報を制御部２１１にそれぞれ供給する。
【００４９】
制御部２１１は、デマルチプレクサ２１５から供給されるシグナリング情報に基づいて、コンテンツを再生するために、デマルチプレクサ２１５や各コンポーネントの処理部などの各部の動作を制御する。
【００５０】
ビデオ処理部２１６は、デマルチプレクサ２１５から供給されるビデオデータに対して、例えば、所定の復号方式に準拠した復号処理などの処理を施し、ビデオ出力部２１７に供給する。ビデオ出力部２１７は、ビデオ処理部２１６から供給されるビデオデータを、表示部２２１に出力する。これにより、表示部２２１には、サービスの選局操作に応じたコンテンツ(例えばテレビ番組など)の映像が表示される。
【００５１】
オーディオ処理部２１８は、デマルチプレクサ２１５から供給されるオーディオデータに対して、例えば、所定の復号方式に準拠した復号処理などの処理を施し、オーディオ出力部２１９に供給する。オーディオ出力部２１９は、オーディオ処理部２１８から供給されるオーディオデータを、スピーカ２２２に出力する。これにより、スピーカ２２２からは、サービスの選局操作に応じたコンテンツ(例えばテレビ番組など)の音声が出力される。
【００５２】
字幕処理部２２０は、デマルチプレクサ２１５から供給される字幕データに対して、例えば、所定の復号方式に準拠した復号処理などの処理を施し、ビデオ出力部２１７に供給する。ビデオ出力部２１７は、字幕処理部２２０から供給される字幕データに対応する字幕が、ビデオ処理部２１６から供給されるビデオデータに対応する映像に重畳して表示されるようにする。これにより、表示部２２１には、サービスの選局操作に応じたコンテンツ(例えばテレビ番組など)の映像に重畳された字幕が表示される。
【００５３】
通信部２２３は、制御部２１１からの制御に従い、通信回線６０を介して視聴履歴サーバ３０と、各種のデータをやりとりする。
【００５４】
（制御部の機能的構成）
図４は、図３の制御部２１１の機能的構成例を示す図である。
【００５５】
図４において、制御部２１１は、放送制御部２５１、通信制御部２５２、視聴履歴情報管理部２５３、及び、視聴履歴サーバURL取得部２５４を含んで構成される。
【００５６】
放送制御部２５１は、送信装置１０から送信されるデジタル放送信号に含まれるコンテンツを再生するために、受信部２１４やデマルチプレクサ２１５、各コンポーネントの処理部や出力部などの各部を制御する。
【００５７】
通信制御部２５２は、通信回線６０を介して視聴履歴サーバ３０と各種のデータをやりとりするために、通信部２２３を制御する。
【００５８】
視聴履歴情報管理部２５３は、コンテンツの視聴履歴情報(CDM)を管理する。視聴履歴情報管理部２５３は、視聴履歴情報(CDM)を記録するタイミングとなった場合に、ユーザによるコンテンツの視聴状況に応じた視聴履歴情報(CDM)を、記録部２１２に記録(蓄積)する。
【００５９】
視聴履歴サーバURL取得部２５４は、方式１乃至方式４の方式に応じて、デマルチプレクサ２１５により分離される多重化ストリームに含まれる視聴履歴サーバURLを取得し、記録部２１２に記録(保持)する。
【００６０】
視聴履歴情報管理部２５３は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、記録部２１２から、視聴履歴情報(CDM)と視聴履歴サーバURLを読み出し、通信制御部２５２に供給する。
【００６１】
通信制御部２５２には、視聴履歴情報管理部２５３から視聴履歴情報(CDM)と視聴履歴サーバURLが供給される。通信制御部２５２は、視聴履歴サーバURLに基づいて、視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０宛てに送信されるように、通信部２２３を制御する。
【００６２】
（視聴履歴サーバの構成）
図５は、図１の視聴履歴サーバ３０の構成例を示す図である。
【００６３】
図５において、視聴履歴サーバ３０は、制御部３１１、通信部３１２、及び、視聴履歴情報蓄積部３１３から構成される。
【００６４】
制御部３１１は、視聴履歴サーバ３０の各部の動作を制御する。制御部３１１は、視聴履歴情報管理部３５１及び視聴履歴情報分析部３５２から構成される。視聴履歴情報管理部３５１は、視聴履歴情報(CDM)を管理する。視聴履歴情報分析部３５２は、視聴履歴情報(CDM)を分析する。
【００６５】
通信部３１２は、制御部３１１からの制御に従い、受信装置２０から通信回線６０を介して送信されてくる視聴履歴情報(CDM)を受信し、制御部３１１に供給する。視聴履歴情報管理部３５１は、通信部３１２から供給される視聴履歴情報(CDM)を、視聴履歴情報蓄積部３１３に記録(蓄積)する。これにより、視聴履歴情報蓄積部３１３には、複数の受信装置２０から順次送られてくる視聴履歴情報(CDM)が収集され、例えば、放送局ごとに蓄積されることになる。
【００６６】
視聴履歴情報分析部３５２は、視聴履歴情報(CDM)を分析するタイミングとなった場合に、視聴履歴情報蓄積部３１３から、放送局ごとの視聴履歴情報(CDM)を読み出して分析する。視聴履歴情報分析部３５２は、視聴履歴情報(CDM)の分析結果に基づいて、放送局ごとの視聴履歴レポートを生成し、通信部３１２に供給する。通信部３１２は、制御部３１１からの制御に従い、放送局ごとの視聴履歴レポートを、各種のネットワーク(不図示)を介して、対象の放送局の送信装置１０に送信する。
【００６７】
＜２．本技術の概要＞
【００６８】
ところで、ATSC3.0と称される次世代のATSCの規格では、IP伝送方式が採用され、データ伝送に、TS(Transport Stream)パケットではなく、IP/UDPパケット、すなわち、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを用いることが決定されている。また、ATSC3.0以外の放送方式でも、将来的に、IPパケットを用いたIP伝送方式が用いられることが期待されている。
【００６９】
また、ATSC3.0においては、トランスポート・プロトコルとして、ROUTE(Real-Time Object Delivery over Unidirectional Transport)と、MMT(MPEG Media Transport)が併存し、いずれか一方のトランスポート・プロトコルを用いてビデオやオーディオ、字幕等(のコンポーネント)のストリームが伝送される。なお、トランスポート・プロトコルとして、ROUTEとMMTのいずれを用いるかは、放送事業者ごとに選択される。
【００７０】
ここで、ROUTEは、バイナリファイルを一方向でマルチキャスト転送するのに適したプロトコルであるFLUTE(File Delivery over Unidirectional Transport)を拡張したプロトコルである。また、MMTは、IP(Internet Protocol)上で用いられるトランスポート方式であり、制御情報によりIPアドレスやURL(Uniform Resource Locator)を設定することで、ビデオやオーディオ等のデータを参照することができる。
【００７１】
さらに、ATSC3.0においては、シグナリングとして、LLS(Link Layer Signaling)シグナリング情報と、SLS(Service Layer Signaling)シグナリング情報を規定することが想定されており、先行して取得されるLLSシグナリング情報に記述される情報に従い、サービスごとのSLSシグナリング情報が取得されることになる。
【００７２】
ここで、LLSシグナリング情報としては、例えば、SLT(Service List Table)等のメタデータが含まれる。SLTは、サービスの選局に必要な情報(選局情報)など、放送ネットワークにおけるストリームやサービスの構成を示す情報(サービス構成情報)を含む。
【００７３】
また、SLSシグナリング情報としては、例えば、USD(User Service Description)，LSID(LCT Session Instance Description)，MPD(Media Presentation Description)等のメタデータが含まれる。USDは、他のメタデータの取得先などの情報を含む。LSIDは、ROUTEプロトコルの制御情報である。MPDは、コンポーネントのストリームの再生を管理するための制御情報である。なお、USD，LSID，MPD等のメタデータは、XML(Extensible Markup Language)等のマークアップ言語により記述される。また、MPDは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)の規格に準じている。
【００７４】
（プロトコルスタック）
図６は、本技術を適用したIP伝送方式のプロトコルスタックを示す図である。
【００７５】
図６において、最も下位の階層は、物理層(Physical Layer)とされる。この物理層に隣接する上位の階層は、レイヤ２の階層(Layer2)とされ、さらに、レイヤ２の階層に隣接する上位の階層は、IP層とされる。また、IP層に隣接する上位の階層はUDP層とされる。すなわち、UDPパケットを含むIPパケット(IP/UDPパケット)が、レイヤ２のL2パケット(Genericパケット)のペイロードに配置され、カプセル化(encapsulation)される。また、物理層のL1フレーム(Physical Frame)は、プリアンブルとデータ部から構成されるが、データ部には、複数のL2パケットをカプセル化して得られるBBフレームに対してエラー訂正用のパリティを付加した後に、インターリーブやマッピング等の物理層に関する処理が行われることで得られるデータがマッピングされる。
【００７６】
UDP層に隣接する上位の階層は、ROUTE，MMT，SLTとされる。すなわち、ROUTEセッションで伝送される、ビデオ、オーディオ、及び、字幕のストリームと、SLSシグナリング情報のストリームと、NRTコンテンツのストリームは、IP/UDPパケットに格納されて伝送される。なお、NRTコンテンツは、NRT(Non Real Time)放送で配信されるコンテンツであって、受信装置２０のストレージに一旦蓄積された後で再生が行われる。また、NRTコンテンツ以外のファイル(例えばアプリケーションのファイル)がROUTEセッションで伝送されるようにしてもよい。
【００７７】
一方で、MMTセッションで伝送される、ビデオ、オーディオ、及び、字幕のストリームと、SLSシグナリング情報のストリームは、IP/UDPパケットに格納されて伝送される。また、SLTは、IP/UDPパケットに格納されて伝送される。
【００７８】
本技術を適用したIP伝送方式では、以上のようなプロトコルスタックが採用されることで、受信装置２０は、ROUTEセッションで伝送されるコンポーネントのストリームにより提供されるサービス(チャンネル)の選局時には、SLTに含まれる選局情報に従い、ROUTEセッションで伝送されるSLSシグナリング情報を取得する(Ｓ１−１，Ｓ１−２)。そして、受信装置２０は、USD，LSID，MPD等のメタデータに従い、選局されたサービスのコンポーネントのストリームに接続する(Ｓ１−３)。これにより、受信装置２０では、サービスの選局操作に応じたコンテンツ(例えばテレビ番組)の映像や音声が出力される。
【００７９】
また、受信装置２０は、MMTセッションで伝送されるコンポーネントのストリームにより提供されるサービスの選局時には、SLTに含まれる選局情報に従い、MMTセッションで伝送されるSLSシグナリング情報を取得する(Ｓ２−１，Ｓ２−２)。そして、受信装置２０は、USD，LSID，MPD等のメタデータに従い、選局されたサービスのコンポーネントのストリームに接続する(Ｓ２−３)。これにより、受信装置２０では、サービスの選局操作に応じたコンテンツ(例えばテレビ番組)の映像や音声が出力される。
【００８０】
（視聴履歴情報の収集例）
図７は、図１の伝送システム１における視聴履歴情報(CDM)の収集例を示す図である。なお、図７において、「CDM Server」は、視聴履歴サーバ３０を意味しており、後述する他の図でも同様とされる。
【００８１】
図７において、受信装置２０は、送信装置１０から送信されるデジタル放送信号を受信(直接受信又は間接受信)し、サービスの選局操作に応じたコンテンツを再生する。また、受信装置２０においては、ユーザによるコンテンツの視聴に応じて、視聴履歴情報(CDM)が記録(蓄積)されるとともに、当該視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０に送信される。
【００８２】
ここで、受信装置２０が、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信するためには、受信装置２０が、視聴履歴サーバ３０のURL(視聴履歴サーバURL)をあらかじめ取得しておく必要がある。
【００８３】
本技術では、送信装置１０が、デジタル放送信号に視聴履歴サーバURLを含めて送信することで、当該デジタル放送信号を受信した受信装置２０が、視聴履歴サーバURLを取得(保持)できるようにする技術を提案する。具体的には、視聴履歴サーバURLの伝送方法として、シグナリングを利用した方式である方式１、ビデオウォータマークを利用した方式である方式２、オーディオユーザデータを利用した方式である方式３、及び、TTML文書のメタデータを利用した方式である方式４を提案するが、その詳細については後述する。
【００８４】
図７においては、放送局Ａ，放送局Ｂ，及び放送局Ｃが共同で視聴履歴サーバ３０を運営している場合を示している。このとき、受信装置２０では、放送局Ａの送信装置１０−１から配信されるコンテンツと、放送局Ｂの送信装置１０−２から配信されるコンテンツと、放送局Ｃの送信装置１０−３から配信されるコンテンツがユーザにより視聴され、それらのコンテンツの視聴履歴情報(CDM)が蓄積されている。
【００８５】
また、各放送局の送信装置１０からは、方式１乃至方式４のいずれかの方式に従い、視聴履歴サーバURLを含むデジタル放送信号が送信されてくるので、受信装置２０は、この視聴履歴サーバURLを取得して保持する。ここでは、視聴履歴サーバ３０が、放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されているため、送信装置１０−１乃至１０−３は、視聴履歴サーバ３０にアクセスするための同一の視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)をそれぞれ通知することになる。
【００８６】
受信装置２０は、送信装置１０−１乃至１０−３からのデジタル放送信号を受信し、デジタル放送信号に含まれる視聴履歴サーバURLを取得して、保持することができる。これにより、受信装置２０は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【００８７】
視聴履歴サーバ３０は、通信回線６０を介して、受信装置２０から送信されてくる視聴履歴情報(CDM)を受信して蓄積する。なお、図７の例では、１台の受信装置２０のみを図示しているが、実際には、複数の受信装置２０(受信装置２０−１乃至２０−Ｍ)から視聴履歴情報(CDM)が送信されてくるので、視聴履歴サーバ３０は、複数の受信装置２０から収集した視聴履歴情報(CDM)を蓄積することになる。
【００８８】
視聴履歴サーバ３０では、このようにして複数の受信装置２０から収集された視聴履歴情報(CDM)に対して、例えば、分析処理などが施され、各放送局ごとの視聴履歴レポートが生成される。各放送局の視聴履歴レポートは、各放送局の送信装置１０に送信される。これにより、各放送局では、視聴履歴サーバ３０から提供される視聴履歴レポートを確認することができる。
【００８９】
また、視聴履歴サーバ３０は、各放送局の送信装置１０に対して、視聴履歴サーバURLの変更の依頼を要求することができる。各放送局の送信装置１０は、視聴履歴サーバ３０からの視聴履歴サーバURLの変更の依頼の要求を受け付けた場合、デジタル放送信号に含める視聴履歴サーバURLを変更して、変更後の視聴履歴サーバURL(例えば、"http://cdmServer_2.com/cdm"であるURL)が送信されるようにする。
【００９０】
ここで、視聴履歴サーバURLは、その運用上、定期的に又は不定期に変更されることが想定されるため、変更後の視聴履歴サーバURLを確実に、受信装置２０に通知することが要請されている。それに対して、デジタル放送信号に含まれる視聴履歴サーバURLをプッシュで通知する方式１乃至方式４を採用した場合、デジタル放送信号の特徴である同報性、即時性、拡張性(スケーラビリディ)を利用して、視聴履歴サーバURLを動的に変更して、不特定多数の受信装置２０−１乃至２０−Ｍに通知することができるため、その要請に応えることができる。また、これにより、視聴履歴サーバ３０にアクセスするための視聴履歴サーバURLを定期的に、又は必要な時に即時に変更することが可能となるため、例えば、視聴履歴サーバ３０に対するDoS攻撃(Denial of Service attack)の回避など、セキュリティを高めることができる。
【００９１】
なお、図７の例では、視聴履歴サーバ３０が、放送局Ａ，放送局Ｂ，及び放送局Ｃの複数の放送局により共同で運営される場合を説明したが、単一の放送局によって、視聴履歴サーバ３０が運営される場合もある。
【００９２】
この場合、放送局Ａの送信装置１０−１は、放送局Ａが運営する視聴履歴サーバ３０Ａにアクセスするための視聴履歴サーバURL(例えば、"http://cdmServer_A.com/cdm"であるURL)を受信装置２０に通知することになる。同様に、放送局Ｂの送信装置１０−２は、放送局Ｂが運営する視聴履歴サーバ３０Ｂにアクセスするための視聴履歴サーバURL(例えば、"http://cdmServer_B.com/cdm"であるURL)を通知し、放送局Ｃの送信装置１０−３は、放送局Ｃが運営する視聴履歴サーバ３０Ｃにアクセスするための視聴履歴サーバURL(例えば、"http://cdmServer_C.com/cdm"であるURL)を通知する。
【００９３】
すなわち、この場合において、送信装置１０−１乃至１０−３は、各放送局の視聴履歴サーバ３０(例えば、視聴履歴サーバ３０Ａ，視聴履歴サーバ３０Ｂ，視聴履歴サーバ３０Ｃ)にアクセスするための異なる視聴履歴サーバURLを、デジタル放送信号によって受信装置２０に通知することになる。
【００９４】
このように、視聴履歴サーバ３０の運営は、単一の放送局又は複数の放送局による共同運営が想定されるが、方式１乃至方式４による視聴履歴サーバURLの通知では、視聴履歴サーバ３０の運営形態に応じて視聴履歴サーバURLを通知することが可能となるため、放送局に依存せずに、視聴履歴サーバURLを通知することができる。例えば、図７に示したように、複数の放送局が共同で視聴履歴サーバ３０を運営する場合でも、各放送局(の送信装置１０)が、同一の視聴履歴サーバURLを伝送することで、そのような運用にも対応することができる。
【００９５】
以上のようにして、図１の伝送システム１においては、視聴履歴情報(CDM)の収集や分析などが行われる。すなわち、図１の伝送システム１においては、視聴履歴情報(CDM)を記録するサービス(チャンネル)と、視聴履歴情報(CDM)を送信する視聴履歴サーバ３０の視聴履歴サーバURLの通知とが、紐付けられているため、放送局ごとに、視聴履歴情報(CDM)を送信する視聴履歴サーバ３０を指定することを、容易に実現することができる。
【００９６】
また、デジタル放送の放送波(デジタル放送信号)によって、視聴履歴サーバ３０の視聴履歴サーバURLを、プッシュで通知することで、送信装置１０と受信装置２０との間の経路途中で、視聴履歴サーバURLが改ざんされる可能性を低くすることができるため、例えば、第三者のサーバに対して、視聴履歴情報(CDM)を誤送信する(させられる)ことを防止するなど、個人情報である視聴履歴情報(CDM)の安全性を高めることができる。
【００９７】
さらに、受信装置２０におけるテレビサービスの受信方法としては、大別すると、アンテナで受信(直接受信)を行う方法と、ケーブルテレビ(CATV)等のMVPD(の配信装置５０)を経由して受信(間接受信)を行う方法がある。前者の直接受信の場合、放送局(の送信装置１０)により配信されるデジタル放送信号に含まれるコンポーネント(例えばビデオやオーディオ、字幕など)のストリームや、メタデータ(例えばシグナリング情報)などのすべての情報が、受信装置２０により取得されるが、後者の間接受信の場合には、MVPD(の配信装置５０)により、メタデータ等が除去される(フィルタされる)可能性がある。
【００９８】
このような場合でも、図１の伝送システム１においては、例えば、方式２(ビデオウォータマークを利用した方式)や方式３(オーディオユーザデータを利用した方式である方式)，方式４(TTML文書のメタデータを利用した方式)などを採用することで、メタデータに関係なく、視聴履歴サーバURLを通知することができるため、アンテナによる直接受信や、MVPD経由による間接受信など、様々な受信環境に対応することができる。
【００９９】
（CDMのシンタックス）
図８は、XML形式のCDM(Consumption Data Message)のシンタックスの例を示す図である。なお、図８において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０１００】
図８において、ルート要素としてのCDM要素は、protocolVersion属性、AVChannel要素、及び、NRTService要素の上位要素となる。protocolVersion属性には、CDMのプロトコルバージョンが指定される。
【０１０１】
AVChannel要素には、配信されたコンテンツのチャンネル(サービス)ごとの視聴履歴に関する情報が指定される。AVChannel要素は、channelNum属性、serviceType属性、及び、ViewInterval要素の上位要素となる。channelNum属性には、チャンネル番号(サービスID)が指定される。serviceType属性には、例えば通常の放送や音声のみの放送などのサービスのタイプが指定される。
【０１０２】
ViewInterval要素は、startTime属性、endTime属性、usageType属性、timeShift属性、viewStartTime属性、viewEndTime属性、及び、DOInterval要素の上位要素となる。また、DOInterval要素は、doId属性、startTime属性、及び、endTime属性の上位要素となる。ViewInterval要素では、これらの要素や属性により、チャンネル(サービス)ごとの視聴履歴に関する情報が指定される。
【０１０３】
NRTService要素には、NRTサービスについての視聴履歴に関する情報が指定される。NRTService要素は、serviceID属性、及び、NRTInterval要素の上位要素となる。serviceID属性には、サービスIDが指定される。
【０１０４】
NRTInterval要素は、startTime属性、endTime属性、及び、NRTItem要素の上位要素となる。また、NRTItem要素は、contentItemId属性、startTime属性、及び、endTime属性の上位要素となる。NRTInterval要素では、これらの要素や属性により、NRTサービスごとに、視聴履歴に関する情報が指定される。
【０１０５】
なお、CDMは、ATSC2.0で規定されている。図９には、ATSC2.0における視聴履歴サーバURLの通知方法を示している。図９に示すように、ATSC2.0では、コンテンツを構成するコンポーネントのうち、字幕(CC：Closed Caption)において、SDO(Standards Developing Organization)としてのATSCにより規定されるService#6の(ペイロードとしての)プライベートデータ(PrivateData)に、視聴履歴サーバURLを配置している。
【０１０６】
ここで、ATSC3.0等で採用されるIP伝送方式は、ATSC2.0とは伝送方式が異なるので、IP伝送方式においても、視聴履歴サーバURLを受信装置２０に通知する方法が要請されており、本技術では、以下に説明する方式１乃至方式４の伝送方法によって、視聴履歴サーバURLを通知できるようにする。
【０１０７】
＜３．具体的な運用例＞
【０１０８】
（１）方式１：シグナリングを利用した視聴履歴サーバURLの伝送
【０１０９】
（視聴履歴情報の収集例）
図１０は、シグナリングを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【０１１０】
図１０において、各放送局の送信装置１０は、シグナリングを利用する方式１により、視聴履歴サーバURLをデジタル放送信号に含めて送信している。具体的には、LLSシグナリング情報であるSLTに配置されるシグナリングロケーション記述子(inet_signaling_location_descriptor)に、視聴履歴サーバURLが記述されることになる。
【０１１１】
ここでは、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されているため、送信装置１０−１乃至１０−３は、視聴履歴サーバ３０にアクセスするための同一の視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)を、デジタル放送信号で伝送されるSLTのシグナリングロケーション記述子により通知することになる。
【０１１２】
受信装置２０は、送信装置１０−１乃至１０−３からのデジタル放送信号を受信し、SLTのシグナリングロケーション記述子に記述された視聴履歴サーバURLを取得して、保持することができる。これにより、受信装置２０は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【０１１３】
視聴履歴サーバ３０は、通信回線６０を介して、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)を受信して蓄積する。視聴履歴サーバ３０は、このようにして複数の受信装置２０から収集された視聴履歴情報(CDM)に対して、例えば、分析処理などを施すことで、各放送局ごとの視聴履歴レポートを生成することができる。
【０１１４】
（視聴履歴サーバURLの通知方法）
図１１は、シグナリングを利用した場合における視聴履歴サーバURLの通知方法を示す図である。
【０１１５】
図１１において、送信装置１０は、ビデオやオーディオ、字幕(のコンポーネント)のストリームとともに、SLT等のシグナリング情報を、デジタル放送信号により伝送している。受信装置２０は、送信装置１０からのデジタル放送信号により伝送されるシグナリング情報に基づいて、コンポーネントのストリームを処理し、コンテンツを再生する。また、受信装置２０では、コンテンツの視聴履歴情報(CDM)が記録(蓄積)される。
【０１１６】
ここで、送信装置１０は、SLTに配置されるシグナリングロケーション記述子(inet_signaling_location_descriptor)に、視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)を記述して、デジタル放送信号により伝送されるようにする。受信装置２０は、送信装置１０からのデジタル放送信号により伝送されるSLTに配置されるシグナリングロケーション記述子から、視聴履歴サーバURLを取得して記録(保持)する。そして、受信装置２０は、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【０１１７】
（SLTのシンタックス）
図１２は、バイナリ形式のSLTのシンタックスの例を示す図である。
【０１１８】
8ビットのtable_idには、SLTのセクションが属するテーブルの識別子が指定される。4ビットのSLT_section_versionには、SLTのセクションのバージョンが指定される。12ビットのSLT_section_lengthには、SLTのセクション長が指定される。8ビットのSLT_protocol_versionには、SLTのプロトコルバージョンが指定される。
【０１１９】
16ビットのbroadcast_stream_idには、ブロードキャストIDが指定される。4ビットのSLT_section_numberとlast_SLT_section_numberには、SLTのセクション番号が指定される。
【０１２０】
8ビットのnum_serviceには、サービスの個数が指定される。このサービスの個数に応じてサービスループが繰り返される。サービスループには、以下の内容が指定される。
【０１２１】
16ビットのservice_idには、サービスIDが指定される。3ビットのSLT_service seq_numberには、サービスのシーケンス番号が指定される。1ビットのprotectedには、サービスの保護を示す暗号化情報が指定される。
【０１２２】
10ビットのmajor_channel_numberには、メジャーのチャンネル番号が指定される。10ビットのminor_channel_numberには、マイナーのチャンネル番号が指定される。4ビットのservice_categoryには、サービスのカテゴリが指定される。
【０１２３】
4ビットのshort_service_name_lengthには、ショートサービス名の長さが指定される。8*mビットのshort_service_name()には、ショートサービス名が指定される。1ビットのbroadcast_signaling_presentには、SLSシグナリング情報が伝送されているかどうかが指定される。
【０１２４】
1ビットのSLS_source_IP_address_presentには、送信元(source)のIPアドレスが存在しているかどうかが指定される。1ビットのbroadband_access_reuiredには、通信回線(ブロードバンド)にアクセスする必要があるかどうかが指定される。4ビットのSLS_protocol_typeには、SLSシグナリング情報のプロトコルのタイプが指定される。
【０１２５】
broadcast_signaling_presentが、SLSシグナリング情報が伝送されていることを示している場合、SLSシグナリング情報を取得するための情報として、SLS_PLP_ID，SLS_destination_IP_address，SLS_destination_UDP_port，SLS_protocol_versionが指定される。
【０１２６】
ただし、SLS_source_IP_address_presentが、送信元(source)のIPアドレスが存在していることを示している場合、SLS_source_IP_addressが指定される。
【０１２７】
8ビットのSLS_PLP_IDには、SLSシグナリング情報が伝送されるPLPのIDが指定される。32ビットのSLS_destination_IP_addressには、宛先(destination)のIPアドレスが指定される。16ビットのSLS_destination_UDP_portには、宛先(destination)のポート番号が指定される。
【０１２８】
32ビットのSLS_source_IP_addressには、送信元(source)のIPアドレスが指定される。8ビットのSLS_protocol_versionは、SLSシグナリング情報のプロトコルのバージョンが指定される。
【０１２９】
なお、num_ext_lenght_bitsが指定された場合、reserved1として、将来の拡張のためにリザーブとされる領域が確保される。また、ext_lengthにより、reserved2として、将来の拡張のためにリザーブとされる領域を確保することができる。
【０１３０】
4ビットのnum_service_level_descriptorsには、サービスレベルの記述子の個数が指定される。このサービスレベルの記述子の個数に応じて、サービスレベル記述子ループが繰り返される。図中の枠Ａで示すように、サービスレベル記述子ループには、サービスレベル記述子(service_level_descriptor)が配置される。
【０１３１】
サービスループの次には、4ビットのreservedに続いて、num_SLT_level_descriptorsが配置される。4ビットのnum_SLT_level_descriptorsには、SLTレベルの記述子の個数が指定される。このSLTレベルの記述子の個数に応じて、SLTレベル記述子ループが繰り返される。図中の枠Ｂで示すように、SLTレベル記述子ループには、SLTレベル記述子(SLT_level_descriptor)が配置される。
【０１３２】
なお、SLTレベル記述子ループの次は、将来の拡張のためのreserved3とされる。
【０１３３】
（SLTの記述子の例）
図１３は、SLTに配置される記述子の例を示す図である。
【０１３４】
SLTには、シグナリングロケーション記述子(inet_signaling_location_descriptor)，サービス言語記述子(service_language_descriptor)，ケイパビリティ記述子(capabilities_descriptor)などの記述子が配置される。
【０１３５】
シグナリングロケーション記述子には、通信経由で取得されるシグナリング情報の取得先を示す情報などのロケーション情報が指定される。例えば、方式１を採用する場合には、このシグナリングロケーション記述子に、視聴履歴サーバURLが記述される。
【０１３６】
このシグナリングロケーション記述子は、図１２Ａのサービスレベル記述子ループと、図１２ＢのSLTレベル記述子ループのいずれにも配置することができる。すなわち、シグナリングロケーション記述子を、SLTのサービスレベル記述子ループ(図１２Ａ)に配置した場合、サービスと、視聴履歴サーバURLとを関連付けることができる。この場合には、サービスごとに、視聴履歴サーバURLを指定することができる。一方で、シグナリングロケーション記述子を、SLTのSLTレベル記述子ループ(図１２Ｂ)に配置した場合、すべてのサービスについて、共通となる視聴履歴サーバURLを指定することができる。
【０１３７】
サービス言語記述子には、サービスの言語に関する情報が指定される。このサービス言語記述子は、図１２Ａのサービスレベル記述子ループと、図１２ＢのSLTレベル記述子ループのいずれにも配置することができる。
【０１３８】
ケイパビリティ記述子には、ケイパビリティに関する情報が指定される。このケイパビリティ記述子は、図１２Ａのサービスレベル記述子ループと、図１２ＢのSLTレベル記述子ループのいずれにも配置することができる。
【０１３９】
（シグナリングロケーション記述子のシンタックス）
図１４は、図１３Ｃのシグナリングロケーション記述子(inet_signaling_location_descriptor)のシンタックスの例を示す図である。
【０１４０】
8ビットのdescriptor_tagには、当該記述子の記述子タグが指定される。8ビットのdescriptor_lengthには、当該記述子の記述子長が指定される。
【０１４１】
8ビットのURL_typeには、URLのタイプが指定される。URL_bytes()は、8*(descriptor_length-1)ビットからなり、URL_typeで指定されるURLのタイプに応じたURLが指定される。
【０１４２】
例えば、図１５に示すように、URL_typeとして"0x00"が指定された場合には、URL_bytes()に、シグナリング情報を提供するシグナリングサーバのURLが指定されることを表している。また、URL_typeとして"0x01"が指定された場合には、URL_bytes()に、ESG(Electronic Service Guide)情報を提供するESGサーバのURLが指定されることを表している。
【０１４３】
また、URL_typeとして"0x02"が指定された場合には、URL_bytes()に、視聴履歴サーバ３０のURL(視聴履歴サーバURL)が指定されることを表している。すなわち、方式１では、SLTに配置されるシグナリングロケーション記述子を利用して、視聴履歴サーバURLを通知する場合に、URL_typeとして"0x02"を指定することで、URL_bytes()に指定されたURLが、視聴履歴サーバ３０のURL(視聴履歴サーバURL)であることが識別されることになる。
【０１４４】
なお、URL_typeにおいて、"0x03"〜"0xFF"は、将来の拡張のためにリザーブとされる値である。
【０１４５】
次に、図１６乃至図２４のフローチャートを参照して、方式１を採用した場合に、図１の伝送システム１を構成する各装置で実行される処理の内容について説明する。
【０１４６】
（送信処理）
まず、図１６のフローチャートを参照して、図１の送信装置１０により実行される送信処理の流れについて説明する。
【０１４７】
ステップＳ１０１においては、コンポーネント・シグナリング処理が行われる。
【０１４８】
このコンポーネント・シグナリング処理では、ビデオ処理部１１３等で処理されるビデオストリーム(ビデオビットストリーム)、オーディオ処理部１１５等で処理されるオーディオストリーム(オーディオビットストリーム)、字幕処理部１１７等で処理される字幕ストリーム、及び、シグナリング処理部１１９等で処理されるシグナリング情報に対する各種の処理が行われ、各コンポーネントのストリームとシグナリング情報が、デジタル放送信号として送信可能な状態とされる。
【０１４９】
ステップＳ１０２においては、送信部１２１により送信処理が行われ、ステップＳ１０１の処理で処理された各コンポーネントのストリームとシグナリング情報が、デジタル放送信号として、アンテナ１３１を介して送信される。ステップＳ１０２の処理が終了すると、図１６の送信処理は終了される。
【０１５０】
以上、送信処理の流れについて説明した。
【０１５１】
（視聴履歴サーバURL通知処理）
次に、図１７のフローチャートを参照して、シグナリングを利用した場合における視聴履歴サーバURL通知処理の流れについて説明する。なお、この視聴履歴サーバURL通知処理は、図１の送信装置１０により、図１６のステップＳ１０１の処理と並行して実行される処理とされる。
【０１５２】
ステップＳ１１１において、制御部１１１は、視聴履歴サーバURLを通知するタイミングであるかどうかを判定する。
【０１５３】
ステップＳ１１１において、視聴履歴サーバURLを通知するタイミングではないと判定された場合、ステップＳ１１１の判定処理が繰り返される。一方、ステップＳ１１１において、視聴履歴サーバURLを通知するタイミングであると判定された場合、処理は、ステップＳ１１２に進められる。
【０１５４】
ステップＳ１１２において、視聴履歴サーバURL生成部１５１は、対象となる視聴履歴サーバ３０の視聴履歴サーバURLを生成する。このようにして生成された視聴履歴サーバURLは、方式１を採用した場合には、シグナリング生成部１１８に供給される。
【０１５５】
ステップＳ１１３において、シグナリング生成部１１８は、SLTを生成する際に、ステップＳ１１２の処理で生成された視聴履歴サーバURLを、SLTのサービスレベル記述子ループ又はSLTレベル記述子ループに配置されるシグナリングロケーション記述子に追加する。
【０１５６】
ただし、このとき、シグナリングロケーション記述子では、URL_typeとして、"0x02"が指定される。また、例えば、図１０に示したように、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されている場合、放送局Ａ，放送局Ｂ，放送局Ｃの送信装置１０−１乃至１０−３では、SLTのシグナリングロケーション記述子のURL_bytes()に、視聴履歴サーバURLとして、"http://cdmServer.com/cdm"が記述されることになる。
【０１５７】
以上、視聴履歴サーバURL通知処理の流れについて説明した。この視聴履歴サーバURL通知処理では、シグナリングロケーション記述子に、"0x02"であるURL_typeと、視聴履歴サーバURLが指定されたURL_bytes()が記述される。そして、当該シグナリングロケーション記述子が、サービスレベル記述子ループ又はSLTレベル記述子ループに配置されたSLTが生成され（図１６のＳ１０１）、デジタル放送信号に含めて送信されることになる（図１６のＳ１０２）。
【０１５８】
（初期スキャン処理）
次に、図１８のフローチャートを参照して、図１の受信装置２０により実行される初期スキャン処理の流れについて説明する。
【０１５９】
ステップＳ２０１においては、制御部２１１によって、入力部２１３からの操作信号等が監視され、初期スキャン処理の開始イベントが発生した場合、初期スキャン処理が開始され、処理は、ステップＳ２０２に進められる。
【０１６０】
ステップＳ２０２において、受信部２１４は、放送制御部２５１からの制御に従い、周波数スキャン処理を行う。ステップＳ２０３においては、ステップＳ２０２の周波数スキャン処理によって、周波数スキャンに成功したかどうかが判定される。
【０１６１】
ステップＳ２０３において、周波数スキャンに失敗したと判定された場合、処理は、ステップＳ２０２の処理に戻り、再度、周波数スキャン処理が行われる。一方、ステップＳ２０３において、周波数スキャンに成功したと判定された場合、処理は、ステップＳ２０４に進められる。
【０１６２】
ステップＳ２０４においては、ストリーム・SLT取得処理が実行される。このストリーム・SLT取得処理では、多重化ストリームにより伝送されるSLTが取得され、記録部２１２に記録されることになる。なお、ストリーム・SLT取得処理の詳細な内容は、図１９のフローチャートを参照して後述する。
【０１６３】
ストリーム・SLT取得処理が終了すると、処理は、ステップＳ２０５に進められる。ステップＳ２０５においては、全周波数帯域のスキャンが完了したかどうかが判定される。
【０１６４】
ステップＳ２０５において、全周波数帯域のスキャンが未完了であると判定された場合、処理は、ステップＳ２０２に戻り、ステップＳ２０２以降の処理が繰り返される。これにより、各周波数帯域における周波数スキャン処理が行われ、周波数帯域ごとにSLTが取得され、記録部２１２に記録される。そして、ステップＳ２０５において、全周波数帯域のスキャンが完了したと判定された場合、図１８の初期スキャン処理は終了される。
【０１６５】
以上、初期スキャン処理の流れについて説明した。この初期スキャン処理では、各周波数帯域のスキャンが行われ、周波数帯域ごとに取得されるSLTから得られる情報(例えば選局情報)が、記録部２１２に記録される。
【０１６６】
（ストリーム・SLT取得処理）
ここで、図１９のフローチャートを参照して、図１８のステップＳ２０４の処理に対応するストリーム・SLT取得処理の詳細な内容について説明する。
【０１６７】
ステップＳ２１１において、受信部２１４は、デジタル放送信号に対して復調処理を行い、物理層のL1フレームからL2パケットを抽出(取得)して、当該L2パケットのペイロードにカプセル化されているIP/UDPパケットを抽出(取得)する。
【０１６８】
ステップＳ２１２においては、ステップＳ２１１の処理で抽出されたIP/UDPパケットにSLTが含まれているか、すなわち、SLTが伝送されているかどうかが判定される。
【０１６９】
ステップＳ２１２において、SLTが伝送されていると判定された場合、処理は、ステップＳ２１３に進められる。ステップＳ２１３において、放送制御部２５１は、IP/UDPパケットに含まれるSLTを取得する。また、ステップＳ２１４において、放送制御部２５１は、ステップＳ２１３の処理で取得されたSLTに含まれるサービス構成情報を、記録部２１２に記録する。
【０１７０】
ステップＳ２１５において、放送制御部２５１は、SLTに、シグナリングロケーション記述子(inet_signaling_location_descriptor)が存在し、かつ、そのURL_typeとして"0x02"が指定されているかどうか、すなわち、SLTに、視聴履歴サーバURLが記述されているかどうかを判定する。
【０１７１】
ステップＳ２１５において、SLTに、視聴履歴サーバURLが記述されていると判定された場合、処理は、ステップＳ２１６に進められる。ステップＳ２１６において、視聴履歴サーバURL取得部２５４は、ステップＳ２１５の処理結果に従い、SLT(のシグナリングロケーション記述子)に含まれる視聴履歴サーバURLを取得し、記録部２１２に記録する。
【０１７２】
一方、ステップＳ２１５において、SLTに、視聴履歴サーバURLが記述されていないと判定された場合、ステップＳ２１６の処理はスキップされる。また、ステップＳ２１２において、SLTが伝送されていないと判定された場合、ステップＳ２１３乃至Ｓ２１６の処理はスキップされる。
【０１７３】
その後、処理は、図１８のステップＳ２０４の処理に戻り、それ以降の処理が実行される。
【０１７４】
以上、ストリーム・SLT取得処理の流れについて説明した。このストリーム・SLT取得処理では、SLTが伝送されている場合には、SLTが取得され、さらに、SLTのシグナリングロケーション記述子に、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され記録される。
【０１７５】
（サービス切り替え時のSLT取得処理）
次に、図２０のフローチャートを参照して、図１の受信装置２０により実行されるサービス切り替え時のSLT取得処理の流れについて説明する。
【０１７６】
ステップＳ２２１においては、制御部２１１によって、入力部２１３からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２２２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２２３に進められる。
【０１７７】
ステップＳ２２３において、放送制御部２５１は、選局されたサービスに対応するサービスID(チャンネル番号)を取得する。また、ステップＳ２２４において、放送制御部２５１は、記録部２１２を参照して、選局情報が記録され、取得済みであるかどうかを判定する。
【０１７８】
ステップＳ２２４において、選局情報が取得済みであると判定された場合、処理は、ステップＳ２２５に進められる。ステップＳ２２５において、放送制御部２５１は、記録部２１２に記録された選局情報(選局されたサービスのサービスIDに対応する選局情報)を読み出して取得する。
【０１７９】
一方、ステップＳ２２４において、選局情報が未取得であると判定された場合、処理は、ステップＳ２２６に進められる。ステップＳ２２６においては、制御部２１１及び受信部２１４などにより、受信処理が行われ、IP/UDPパケットに含まれるSLTが取得される。これにより、放送制御部２５１は、ステップＳ２２６の処理で取得されたSLTから、選局情報(選局されたサービスのサービスIDに対応する選局情報)を取得することができる(Ｓ２２５)。
【０１８０】
なお、ここでは、ステップＳ２２６の処理で取得されたSLTに、シグナリングロケーション記述子が存在し、かつ、そのURL_typeとして"0x02"が指定されている場合には、SLTに含まれる視聴履歴サーバURLを取得し、記録部２１２に記録するようにしてもよい。また、記録部２１２において、既に視聴履歴サーバURLが記録されている場合には、視聴履歴サーバURLを上書きして、更新するようにしてもよい。
【０１８１】
ステップＳ２２５の処理により選局情報が取得されると、処理は、ステップＳ２２７に進められる。
【０１８２】
ステップＳ２２７において、放送制御部２５１は、ステップＳ２２５の処理で取得された選局情報に基づいて、各部の動作を制御することで、選局処理を行う。この選局処理により、ステップＳ２２１，Ｓ２２２の処理で選局されたサービスのコンテンツが再生され、選局中のサービスが切り替えられることになる。
【０１８３】
以上、サービス切り替え時のSLT取得処理の流れについて説明した。このサービス切り替え時のSLT取得処理では、サービス切り替え時に、選局情報が未取得である場合には、SLTが取得され、さらに、そのSLTのシグナリングロケーション記述子に、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され、記録されるようにすることができる。
【０１８４】
（視聴時のSLT取得処理）
次に、図２１のフローチャートを参照して、図１の受信装置２０により実行される視聴時のSLT取得処理の流れについて説明する。
【０１８５】
ステップＳ２３１においては、制御部２１１及び受信部２１４などにより、受信処理が行われ、SLTの伝送ポートの監視が行われる(Ｓ２３２)。
【０１８６】
ステップＳ２３３において、放送制御部２５１は、ステップＳ２３２の処理の監視結果に基づいて、IP/UDPパケットで伝送されるSLTが更新されているかどうかを判定する。
【０１８７】
ステップＳ２３３において、SLTが未更新であると判定された場合、処理は、ステップＳ２３１に戻り、ステップＳ２３１乃至Ｓ２３３の監視処理が繰り返される。一方、ステップＳ２３３において、SLTが更新されたと判定された場合、処理は、ステップＳ２３４に進められる。
【０１８８】
ステップＳ２３４において、放送制御部２５１は、記録部２１２を参照して、更新されたSLTに含まれるサービス構成情報(又はそのパラメータ)を更新する。
【０１８９】
ステップＳ２３５において、放送制御部２５１は、更新されたSLTに、シグナリングロケーション記述子(inet_signaling_location_descriptor)が存在し、かつ、URL_typeとして"0x02"が指定されている場合に、視聴履歴サーバURLが更新されているかどうかを判定する。
【０１９０】
ステップＳ２３５において、視聴履歴サーバURLが更新されていると判定された場合、処理は、ステップＳ２３６に進められる。ステップＳ２３６において、視聴履歴サーバURL取得部２５４は、ステップＳ２３５の処理結果に従い、SLTに含まれる視聴履歴サーバURLを取得し、記録部２１２に記録されている視聴履歴サーバURLを更新する。
【０１９１】
なお、ステップＳ２３５において、視聴履歴サーバURLが更新されていないと判定された場合、ステップＳ２３６の処理はスキップされ、処理は、ステップＳ２３７に進められる。また、記録部２１２に、視聴履歴サーバURLが記録されていない場合には、新規で取得された視聴履歴サーバURLが、そのまま記録部２１２に記録されることになる。
【０１９２】
ステップＳ２３７においては、ユーザによる視聴が終了するかどうかが判定される。ステップＳ２３７において、視聴が終了しないと判定された場合、処理は、ステップＳ２３１に戻り、それ以降の処理が繰り返される。一方、ステップＳ２３７において、視聴が終了すると判定された場合、図２１の視聴時のSLT取得処理は、終了される。
【０１９３】
以上、視聴時のSLT取得処理の流れについて説明した。この視聴時のSLT取得処理では、伝送されるSLTが更新された場合には、SLTが取得され、さらに、SLTのシグナリングロケーション記述子に、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され、視聴履歴サーバURLが更新される。
【０１９４】
（視聴履歴情報記録処理）
次に、図２２のフローチャートを参照して、図１の受信装置２０により実行される視聴履歴情報記録処理の流れについて説明する。
【０１９５】
ステップＳ２４１において、視聴履歴情報管理部２５３は、視聴履歴情報(CDM)を記録するタイミングであるかどうかを判定する。
【０１９６】
ステップＳ２４１において、視聴履歴情報(CDM)を記録するタイミングではないと判定された場合、ステップＳ２４１の判定処理が繰り返される。一方、ステップＳ２４１において、視聴履歴情報(CDM)を記録するタイミングであると判定された場合、処理は、ステップＳ２４２に進められる。
【０１９７】
ステップＳ２４２において、視聴履歴情報管理部２５３は、コンテンツの視聴履歴情報(CDM)を、記録部２１２に記録(蓄積)する。ステップＳ２４２の処理が終了すると、図２２の視聴履歴情報記録処理は終了する。
【０１９８】
以上、視聴履歴情報記録処理の流れについて説明した。この視聴履歴情報記録処理では、所定のタイミングで、視聴履歴情報(CDM)が記録されることで、記録部２１２には、例えば、サービス(チャンネル)ごとの視聴履歴情報(CDM)が順次蓄積されることになる。
【０１９９】
（視聴履歴情報送信処理）
次に、図２３のフローチャートを参照して、図１の受信装置２０により実行される視聴履歴情報送信処理の流れについて説明する。
【０２００】
ステップＳ２５１において、視聴履歴情報管理部２５３は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングであるかどうかを判定する。
【０２０１】
ステップＳ２５１において、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングではないと判定された場合、ステップＳ２５１の判定処理が繰り返される。一方、ステップＳ２５１において、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングであると判定された場合、処理は、ステップＳ２５２に進められる。
【０２０２】
ステップＳ２５２において、視聴履歴情報管理部２５３は、記録部２１２から、視聴履歴情報(CDM)を読み出して取得する。ただし、この視聴履歴情報(CDM)は、図２２の視聴履歴情報記録処理により記録部２１２に記録(蓄積)された視聴履歴情報(CDM)とされる。
【０２０３】
ステップＳ２５３において、視聴履歴情報管理部２５３は、記録部２１２から、視聴履歴サーバURLを読み出して取得する。ただし、この視聴履歴サーバURLは、例えば、図１９のステップＳ２１６の処理で記録部２１２に記録された視聴履歴サーバURLや、図２１のステップＳ２３６の処理で更新された視聴履歴サーバURLなどとされる。
【０２０４】
ステップＳ２５４において、通信制御部２５２は、ステップＳ２５３の処理で取得された視聴履歴サーバURLに基づいて、ステップＳ２５２の処理で取得された視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０宛てに送信されるように、通信部２２３を制御する。ステップＳ２５４の処理が終了すると、図２３の視聴履歴情報送信処理は終了する。
【０２０５】
以上、視聴履歴情報送信処理の流れについて説明した。この視聴履歴情報送信処理では、所定のタイミングで、記録部２１２に適宜記録される視聴履歴サーバURLと視聴履歴情報(CDM)が読み出され、視聴履歴サーバURLに従い、視聴履歴情報(CDM)が、視聴履歴サーバ３０宛てに送信されることになる。
【０２０６】
なお、上述した説明では、記録部２１２に適宜記録される視聴履歴情報(CDM)が、視聴履歴サーバ３０に送信されるとして説明したが、視聴履歴情報(CDM)を記録部２１２に記録せずに、視聴履歴情報(CDM)を生成したタイミングで、即時に、視聴履歴サーバ３０に送信されるようにしてもよい。
【０２０７】
（視聴履歴情報収集・分析処理）
最後に、図２４のフローチャートを参照して、図１の視聴履歴サーバ３０により実行される視聴履歴情報収集・分析処理の流れについて説明する。
【０２０８】
ステップＳ３０１においては、受信装置２０からの視聴履歴情報(CDM)が、通信回線６０を介して送信されてきたかどうかが判定される。
【０２０９】
ステップＳ３０１において、受信装置２０から視聴履歴情報(CDM)が送信されてきたと判定された場合、処理は、ステップＳ３０２に進められる。ステップＳ３０２において、通信部３１２は、制御部３１１からの制御に従い、通信回線６０を介して、受信装置２０から送信されてくる視聴履歴情報(CDM)を受信する。
【０２１０】
ステップＳ３０３において、視聴履歴情報管理部３５１は、ステップＳ３０２の処理で受信された視聴履歴情報(CDM)を、視聴履歴情報蓄積部３１３に蓄積する。
【０２１１】
ステップＳ３０３の処理が終了すると、処理は、ステップＳ３０４に進められる。なお、ステップＳ３０１において、受信装置２０から視聴履歴情報(CDM)が送信されてこないと判定された場合、ステップＳ３０２，Ｓ３０３の処理はスキップされ、処理は、ステップＳ３０４に進められる。
【０２１２】
ステップＳ３０４においては、視聴履歴情報蓄積部３１３に蓄積された視聴履歴情報(CDM)を分析するかどうかが判定される。
【０２１３】
ステップＳ３０４において、視聴履歴情報(CDM)を分析しないと判定された場合、処理は、ステップＳ３０１に戻り、それ以降の処理が繰り返される。すなわち、ステップＳ３０１乃至Ｓ３０４の処理が繰り返されることで、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)が収集され、サービス(チャンネル)ごとの視聴履歴情報(CDM)が、視聴履歴情報蓄積部３１３に蓄積されることなる。
【０２１４】
一方、ステップＳ３０４において、視聴履歴情報(CDM)を分析すると判定された場合、処理は、ステップＳ３０５に進められる。ステップＳ３０５において、視聴履歴情報分析部３５２は、ステップＳ３０３の処理により視聴履歴情報蓄積部３１３に蓄積された、複数の受信装置２０からの視聴履歴情報(CDM)を読み出して、視聴履歴情報(CDM)を分析する。
【０２１５】
ステップＳ３０６において、視聴履歴情報分析部３５２は、ステップＳ３０５の処理の分析結果に基づいて、放送局ごとの視聴履歴レポートを生成する。
【０２１６】
ステップＳ３０７において、通信部３１２は、制御部３１１からの制御に従い、ステップＳ３０６の処理で生成された、放送局ごと視聴履歴レポートを、各放送局の送信装置１０に送信する。ステップＳ３０７の処理が終了すると、図２４の視聴履歴情報収集・分析処理は終了する。
【０２１７】
以上、視聴履歴情報収集・分析処理の流れについて説明した。この視聴履歴情報収集・分析処理では、複数の受信装置２０からの視聴履歴情報(CDM)が順次蓄積され、所定のタイミングで、蓄積された視聴履歴情報(CDM)の分析が行われ、視聴履歴レポートが生成される。
【０２１８】
以上のように、視聴履歴サーバURLの伝送方法として、シグナリングを利用した方式である方式１を採用した場合、SLTに配置されるシグナリングロケーション記述子に、視聴履歴サーバURLを含めることで、送信装置１０から、受信装置２０に視聴履歴サーバURLが通知される。また、このような方式１を採用した場合、アンテナで直接受信を行う受信装置２０では、デジタル放送信号に含まれるメタデータ(SLT等のシグナリング情報)を確実に取得できるし、MVPDを経由した間接受信を行う受信装置２０であっても、運用によってはメタデータ(SLT等のシグナリング情報)が伝送されるため、様々な受信環境において、SLTに含まれる視聴履歴サーバURLを取得して、視聴履歴情報(CDM)の送信時に用いることができる。
【０２１９】
（２）方式２：ビデオウォータマークを利用した視聴履歴サーバURLの伝送
【０２２０】
（視聴履歴情報の収集例）
図２５は、ビデオウォータマークを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【０２２１】
図２５において、各放送局の送信装置１０は、ビデオウォータマーク(Video Watermark)を利用する方式２により、視聴履歴サーバURLをデジタル放送信号に含めて送信している。具体的には、ビデオストリームにおいてビデオウォータマークとして伝送されるウォータマークペイロード(Watermark payload)に、視聴履歴サーバURLが記述されることになる。
【０２２２】
ここでは、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されているため、送信装置１０−１乃至１０−３は、視聴履歴サーバ３０にアクセスするための同一の視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)を、デジタル放送信号で伝送されるビデオストリームのビデオウォータマークにより通知することになる。
【０２２３】
受信装置２０は、送信装置１０−１乃至１０−３からのデジタル放送信号を受信し、ビデオストリームにおいてビデオウォータマークとして伝送されるウォータマークペイロードに記述された視聴履歴サーバURLを取得して、保持することができる。これにより、受信装置２０は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【０２２４】
視聴履歴サーバ３０は、通信回線６０を介して、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)を受信して蓄積する。視聴履歴サーバ３０は、このようにして複数の受信装置２０から収集された視聴履歴情報(CDM)に対して、例えば、分析処理などを施すことで、各放送局ごとの視聴履歴レポートを生成することができる。
【０２２５】
（視聴履歴サーバURLの通知方法）
図２６は、ビデオウォータマークを利用した場合における視聴履歴サーバURLの通知方法を示す図である。
【０２２６】
図２６に示すように、１ビデオフレームにおいて、映像表示領域の上側の２ラインをビデオウォータマークとして利用することができる。このビデオウォータマークで利用される２ラインでは、１ブロックで１ビットの情報量を伝送する方式である標準データ伝送と、１ブロックで２ビットの情報量を伝送する方式である２倍率データ伝送のうち、いずれか一方のデータ伝送方式を用いることができる。
【０２２７】
例えば、図２６において、標準データ伝送を用いた場合には、先頭のブロックには"1"，２番目のブロックには"1"，３番目のブロックには"0"，４番目のブロックには"1"が順次格納されており、５番目以降のブロックにも、"0"又は"1"の１ビットがブロックごとに格納される。一方で、２倍率データ伝送を用いた場合には、先頭のブロックには"11"，２番目のブロックには"10"，３番目のブロックには"01"，４番目のブロックには"10"が順次格納されており、５番目以降のブロックにも、"0"と"1"の組み合わせからなる２ビットがブロックごとに格納される。
【０２２８】
また、ビデオウォータマークでは、ビデオビットストリームの２ラインを用い、ウォータマークペイロード(Watermark payload)を伝送することになる。
【０２２９】
（ウォータマークペイロードのシンタックス）
図２７は、ウォータマークペイロード(Watermark payload)のシンタックスの例を示す図である。
【０２３０】
16ビットのrun_in_patternには、ビデオウォータマークの伝送パターンと、白から黒までの範囲で表される１領域の分解能が指定される。この伝送パターンとしては、１ライン又は２ラインが指定される。また、１領域の分解能としては、8ビット〜12ビットが指定される。
【０２３１】
wm_message()は、ウォータマークのメッセージ領域を表している。8ビットのzero_padは、ゼロパディングを表している。
【０２３２】
（WMメッセージのシンタックス）
図２８は、図２７のWMメッセージ(wm_message)のシンタックスの例を示す図である。
【０２３３】
8ビットのwm_message_idには、WMメッセージIDが指定される。8ビットのwm_message_lengthには、WMメッセージ長が指定される。
【０２３４】
4ビットのwm_message_sequenceには、WMメッセージのシーケンスが指定される。2ビットのfragment_numberと、2ビットのlast_fragmentには、フラグメントに関する情報が指定される。
【０２３５】
ここで、WMメッセージIDとして、"0x01"が指定された場合、コンテントIDメッセージ(content_id_message)が配置される。また、WMメッセージIDとして、"0x02"が指定された場合、チャンネルIDメッセージ(channel_id_message)が配置される。さらに、WMメッセージIDとして、"0x03"が指定された場合、URIメッセージ(uri_message)が配置される。
【０２３６】
そして、ウォータマークペイロードに、視聴履歴サーバURLを記述する場合には、URIメッセージを利用することになるため、ここでは、WMメッセージIDとして、"0x03"を指定することになる。
【０２３７】
なお、WMメッセージには、message_CRC_32やCRC_32などの誤り検出符号が含まれる。
【０２３８】
（URIメッセージのシンタックス）
図２９は、図２８のURIメッセージ(uri_message)のシンタックスの例を示す図である。
【０２３９】
8ビットのuri_typeには、URIのタイプが指定される。8ビットのuri_strlenには、URI長が指定される。URI_string()は、8*uri_strlenビットからなり、uri_typeで指定されるURIのタイプに応じたURI(Uniform Resource Identifier)が指定される。
【０２４０】
例えば、図３０に示すように、uri_typeとして"0x01"又は"0x02"が指定された場合には、TBDが指定されることを表している。また、uri_typeとして"0x03"が指定された場合には、視聴履歴サーバ３０のURL(視聴履歴サーバURL)が指定されることを表している。なお、uri_typeにおいて、"0x00"，"0x04"〜"0xFF"は、将来の拡張のためにリザーブとされる値である。
【０２４１】
次に、図３１及び図３２のフローチャートを参照して、方式２を採用した場合に、図１の伝送システム１を構成する各装置で実行される処理の内容について説明する。
【０２４２】
（視聴履歴サーバURL通知処理）
まず、図３１のフローチャートを参照して、ビデオウォータマークを利用した場合における視聴履歴サーバURL通知処理の流れについて説明する。なお、この視聴履歴サーバURL通知処理は、図１の送信装置１０により、図１６のステップＳ１０１の処理と並行して実行される処理とされる。
【０２４３】
ステップＳ１２１において、制御部１１１は、視聴履歴サーバURLを通知するタイミングであるかどうかを判定する。
【０２４４】
ステップＳ１２１において、視聴履歴サーバURLを通知するタイミングではないと判定された場合、ステップＳ１２１の判定処理が繰り返される。一方、ステップＳ１２１において、視聴履歴サーバURLを通知するタイミングであると判定された場合、処理は、ステップＳ１２２に進められる。
【０２４５】
ステップＳ１２２において、視聴履歴サーバURL生成部１５１は、対象となる視聴履歴サーバ３０の視聴履歴サーバURLを生成する。このようにして生成された視聴履歴サーバURLは、方式２を採用した場合には、ビデオ処理部１１３に供給される。
【０２４６】
ステップＳ１２３において、ビデオ処理部１１３は、ビデオストリームを処理する際に、ステップＳ１２２の処理で生成された視聴履歴サーバURLを、各フレームのビデオウォータマークとして伝送されるウォータマークペイロード(のWMメッセージのURIメッセージ)に追加(記述)する。
【０２４７】
ただし、このとき、URIメッセージでは、uri_typeとして"0x03"が指定される。また、例えば、図２５に示したように、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されている場合、放送局Ａ，放送局Ｂ，放送局Ｃの送信装置１０−１乃至１０−３では、URIメッセージのURI_string()に、視聴履歴サーバURLとして、"http://cdmServer.com/cdm"が記述されることになる。
【０２４８】
以上、視聴履歴サーバURL通知処理の流れについて説明した。この視聴履歴サーバURL通知処理では、ウォータマークペイロードのWMメッセージのURIメッセージに、"0x03"であるuri_typeと、視聴履歴サーバURLが指定されたURI_string()が記述される。そして、当該URIメッセージを含むウォータマークペイロードが伝送されるビデオウォータマークを含むビデオフレーム(ビデオストリーム)が生成され、（図１６のＳ１０１）、デジタル放送信号に含めて送信されることになる（図１６のＳ１０２）。
【０２４９】
（視聴履歴サーバURL取得処理）
次に、図３２のフローチャートを参照して、ビデオウォータマークを利用した場合における視聴履歴サーバURL取得処理の流れについて説明する。なお、この視聴履歴サーバURL取得処理は、図１の受信装置２０において、例えば、ユーザによる選局操作に応じて選局されたサービスのコンテンツの視聴中に実行される処理とされる。
【０２５０】
ステップＳ２６１においては、制御部２１１によって、入力部２１３からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２６２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２６３に進められる。
【０２５１】
ステップＳ２６３において、放送制御部２５１は、記録部２１２に記録された選局情報に基づいて、受信部２１４等の動作を制御することで、選局処理を行う。
【０２５２】
ステップＳ２６４において、放送制御部２５１は、ビデオ処理部２１６、オーディオ処理部２１８、及び、字幕処理部２２０を制御することで、ビデオ、オーディオ、及び、字幕のコンポーネント(のストリーム)をレンダリングする。
【０２５３】
ステップＳ２６５においては、ビデオウォータマークに対する処理を行うかどうかが判定される。ステップＳ２６５において、ビデオウォータマークに対する処理を行うと判定された場合、処理は、ステップＳ２６６に進められる。ステップＳ２６６において、ビデオ処理部２１６は、ビデオウォータマークとして伝送されるウォータマークペイロード(のWMメッセージのURIメッセージ)に、視聴履歴サーバURLが記述されているかどうかを判定する。
【０２５４】
ステップＳ２６６において、ウォータマークペイロード(のWMメッセージのURIメッセージ)に、視聴履歴サーバURLが記述されていると判定された場合、処理は、ステップＳ２６７に進められる。ステップＳ２６７において、視聴履歴サーバURL取得部２５４は、ステップＳ２６６の処理結果に従い、ウォータマークペイロード(のWMメッセージのURIメッセージ)に記述される視聴履歴サーバURLを取得し、記録部２１２に記録する。
【０２５５】
一方、ステップＳ２６６において、ウォータマークペイロード(のWMメッセージのURIメッセージ)に、視聴履歴サーバURLが記述されていないと判定された場合、処理は、ステップＳ２６８に進められる。ステップＳ２６８において、ビデオ処理部２１６は、別のビデオウォータマーク処理(例えば、コンテントIDメッセージやチャンネルIDメッセージ等に対する処理)を行う。
【０２５６】
ステップＳ２６７の処理又はステップＳ２６８の処理が終了すると、処理は、ステップＳ２６９に進められる。また、ステップＳ２６５において、ビデオウォータマークに対する処理を行わないと判定された場合、ステップＳ２６６乃至Ｓ２６８の処理は、スキップされ、処理は、ステップＳ２６９に進められる。
【０２５７】
ステップＳ２６９においては、ユーザによる視聴が終了するかどうかが判定される。ステップＳ２６９において、視聴が終了しないと判定された場合、処理は、ステップＳ２６４に戻り、それ以降の処理が繰り返される。一方、ステップＳ２６９において、視聴が終了すると判定された場合、図３２の視聴履歴サーバURL取得処理は、終了される。
【０２５８】
以上、視聴履歴サーバURL取得処理の流れについて説明した。この視聴履歴サーバURL取得処理では、サービス選局イベントが発生したとき、すなわち、コンテンツの視聴時に、ビデオウォータマークで、ウォータマークペイロードが伝送され、WMメッセージのURIメッセージに、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され、記録されることになる。
【０２５９】
なお、図３２の視聴履歴サーバURL取得処理では、コンテンツの視聴時に、URIメッセージに記述された視聴履歴サーバURLが取得される場合を一例に説明したが、他のタイミングで、ビデオウォータマークを利用して伝送される視聴履歴サーバURLが取得され、記録(新規で記録又は更新)されるようにしてもよい。
【０２６０】
また、方式２を採用した場合においても、受信装置２０では、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合には、図２３の視聴履歴情報送信処理が実行され、ビデオウォータマークで伝送されるウォータマークペイロード(のWMメッセージのURIメッセージ)から取得された視聴履歴サーバURLに基づいて、視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０に送信されることになる。
【０２６１】
以上のように、視聴履歴サーバURLの伝送方法として、ビデオウォータマークを利用した方式である方式２を採用した場合、ビデオウォータマークに、視聴履歴サーバURLを含めることで、送信装置１０から、受信装置２０に視聴履歴サーバURLが通知される。また、このような方式２を採用した場合、アンテナで直接受信を行う受信装置２０では、ビデオウォータマークとして伝送されるウォータマークペイロードを処理できるし、MVPDを経由した間接受信を行う受信装置２０であっても、ビデオウォータマークとして伝送されるウォータマークペイロードを処理することができるため、それらの受信環境に関係なく、ウォータマークペイロード(のWMメッセージのURIメッセージ)に含まれる視聴履歴サーバURLを取得して、視聴履歴情報(CDM)の送信時に用いることができる。
【０２６２】
なお、上述した説明では、ビデオウォータマークに、視聴履歴サーバURLを含めた場合を説明したが、オーディオウォータマークが使用可能な場合には、当該オーディオウォータマークを利用して、そのウォータマークペイロードに、視聴履歴サーバURLを含めるようにしてもよい。
【０２６３】
（３）方式３：オーディオユーザデータを利用した視聴履歴サーバURLの伝送
【０２６４】
（視聴履歴情報の収集例）
図３３は、オーディオユーザデータを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【０２６５】
図３３において、各放送局の送信装置１０は、オーディオユーザデータ(Audio User Data)を利用する方式３により、視聴履歴サーバURLをデジタル放送信号に含めて送信している。具体的には、オーディオストリームで伝送されるオーディオユーザデータに、視聴履歴サーバURLが記述されることになる。
【０２６６】
ここでは、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されているため、送信装置１０−１乃至１０−３は、視聴履歴サーバ３０にアクセスするための同一の視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)を、デジタル放送信号で伝送されるオーディオストリームのオーディオユーザデータにより通知することになる。
【０２６７】
受信装置２０は、送信装置１０−１乃至１０−３からのデジタル放送信号を受信し、オーディオストリームで伝送されるオーディオユーザデータに記述された視聴履歴サーバURLを取得して、保持することができる。これにより、受信装置２０は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【０２６８】
視聴履歴サーバ３０は、通信回線６０を介して、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)を受信して蓄積する。視聴履歴サーバ３０は、このようにして複数の受信装置２０から収集された視聴履歴情報(CDM)に対して、例えば、分析処理などを施すことで、各放送局ごとの視聴履歴レポートを生成することができる。
【０２６９】
（SYSメタフレームのシンタックス）
図３４は、MPEG-H 3D Audioで規定されるSYSメタフレーム(SysMetaFrame)のシンタックスの例を示す図である。
【０２７０】
8ビットのsysTypeには、システムのタイプが指定される。dataLenには、データ長が指定される。sysDataは、8*dataLenビットからなり、sysTypeで指定されるタイプに応じたデータが指定される。
【０２７１】
例えば、図３５に示すように、sysTypeとして"1"が指定された場合、"SYS_MP2TS"、すなわち、MPEG2 TSシステムにより、sysDataで指定されるデータが利用されることを表している。また、sysTypeとして"2"が指定された場合、"SYS_MMT"、すなわち、MMTシステムにより、sysDataで指定されるデータが利用されることを表している。
【０２７２】
また、sysTypeとして"3"が指定された場合、"SYS_DASH"、すなわち、MPEG-DASHシステムにより、sysDataで指定されるデータが利用されることを表している。なお、"0"であるsysTypeの値は、未定義とされる。また、sysTypeの値において、"4"〜"127"は、は、国際標準化機構(ISO：International Organization for Standardization)が将来使用するためにリザーブとしている値である。さらに、"128"〜"255"は、将来の拡張のためにリザーブとされる値である。
【０２７３】
ここで、"128"〜"255"の将来の拡張用の値のうち、例えば、"128"を、"SYS_ATSC3.0"に割り当てるようにすることで、sysTypeとして"128"が指定された場合に、ATSC3.0システムにより、sysDataで指定されるデータが利用されること表すようにすることができる。
【０２７４】
図３６には、sysTypeとして、"SYS_ATSC3.0"が指定された場合における、sysData(sysData_atsc3.0)のシンタックスの例を示す図である。
【０２７５】
4ビットのversionには、バージョンが指定される。4ビットのsys_data_typeは、データタイプが指定される。ここでは、sys_data_typeとして、"cdm_uri"が指定される場合には、cdm_uri_lengthと、cdm_uriが指定される。
【０２７６】
16ビットのcdm_uri_lengthには、URI長が指定される。cdm_uriは、8*cdm_uri_lengthビットからなり、視聴履歴サーバURLとしてのURIが指定される。
【０２７７】
次に、図３７及び図３８のフローチャートを参照して、方式３を採用した場合に、図１の伝送システム１を構成する各装置で実行される処理の内容について説明する。
【０２７８】
（視聴履歴サーバURL通知処理）
まず、図３７のフローチャートを参照して、オーディオユーザデータを利用した場合における視聴履歴サーバURL通知処理の流れについて説明する。なお、この視聴履歴サーバURL通知処理は、図１の送信装置１０により、図１６のステップＳ１０１の処理と並行して実行される処理とされる。
【０２７９】
ステップＳ１３１において、制御部１１１は、視聴履歴サーバURLを通知するタイミングであるかどうかを判定する。
【０２８０】
ステップＳ１３１において、視聴履歴サーバURLを通知するタイミングではないと判定された場合、ステップＳ１３１の判定処理が繰り返される。一方、ステップＳ１３１において、視聴履歴サーバURLを通知するタイミングであると判定された場合、処理は、ステップＳ１３２に進められる。
【０２８１】
ステップＳ１３２において、視聴履歴サーバURL生成部１５１は、対象となる視聴履歴サーバ３０の視聴履歴サーバURLを生成する。このようにして生成された視聴履歴サーバURLは、方式３を採用した場合には、オーディオ処理部１１５に供給される。
【０２８２】
ステップＳ１３３において、オーディオ処理部１１５は、オーディオストリームを処理する際に、ステップＳ１３２の処理で生成された視聴履歴サーバURLを、オーディオユーザデータ(SYSメタフレームのsysData)に追加する。
【０２８３】
ただし、このとき、SYSメタフレーム(SysMetaFrame)では、sysTypeとして、"128"("SYS_ATSC3.0")が指定され、sysDataとして、sysData_atsc3.0が用いられる。また、sysData_atsc3.0では、sys_data_typeとして、"cdm_uri"が指定される。また、例えば、図３３に示したように、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されている場合、放送局Ａ，放送局Ｂ，放送局Ｃの送信装置１０−１乃至１０−３では、SYSメタフレームのsysData_atsc3.0のcdm_uriに、視聴履歴サーバURLとして、"http://cdmServer.com/cdm"が記述されることになる。
【０２８４】
以上、視聴履歴サーバURL通知処理の流れについて説明した。この視聴履歴サーバURL通知処理では、SYSメタフレームのsysData_atsc3.0に、"cdm_uri"であるsys_data_typeと、視聴履歴サーバURLが指定されたcdm_uriが記述される。そして、当該sysData_atsc3.0を含むSYSメタフレームを含むオーディオストリームが生成され（図１６のＳ１０１）、デジタル放送信号に含めて送信されることになる（図１６のＳ１０２）。
【０２８５】
（視聴履歴サーバURL取得処理）
次に、図３８のフローチャートを参照して、オーディオユーザデータを利用した場合における視聴履歴サーバURL取得処理の流れについて説明する。なお、この視聴履歴サーバURL取得処理は、図１の受信装置２０において、例えば、ユーザによる選局操作に応じて選局されたサービスのコンテンツの視聴中に実行される処理とされる。
【０２８６】
ステップＳ２７１においては、制御部２１１によって、入力部２１３からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２７２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２７３に進められる。
【０２８７】
ステップＳ２７３において、放送制御部２５１は、記録部２１２に記録された選局情報に基づいて、受信部２１４等の動作を制御することで、選局処理を行う。
【０２８８】
ステップＳ２７４において、放送制御部２５１は、ビデオ処理部２１６、オーディオ処理部２１８、及び、字幕処理部２２０を制御することで、ビデオ、オーディオ、及び、字幕のコンポーネント(のストリーム)をレンダリングする。
【０２８９】
ステップＳ２７５においては、オーディオストリームのオーディオユーザデータに対する処理を行うかどうかが判定される。ステップＳ２７５において、オーディオユーザデータに対する処理を行うと判定された場合、処理は、ステップＳ２７６に進められる。ステップＳ２７６において、オーディオ処理部２１８は、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に、視聴履歴サーバURLが記述されているかどうかを判定する。
【０２９０】
ステップＳ２７６において、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に、視聴履歴サーバURLが記述されていると判定された場合、処理は、ステップＳ２７７に進められる。ステップＳ２７７において、視聴履歴サーバURL取得部２５４は、ステップＳ２７６の処理結果に従い、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に記述される視聴履歴サーバURLを取得し、記録部２１２に記録する。
【０２９１】
一方、ステップＳ２７５において、オーディオユーザデータに対する処理を行わないと判定された場合、あるいは、ステップＳ２７６において、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に、視聴履歴サーバURLが記述されていないと判定された場合、処理は、ステップＳ２７８に進められる。
【０２９２】
ステップＳ２７８においては、ユーザによる視聴が終了するかどうかが判定される。ステップＳ２７８において、視聴が終了しないと判定された場合、処理は、ステップＳ２７４に戻り、それ以降の処理が繰り返される。一方、ステップＳ２７８において、視聴が終了すると判定された場合、図３８の視聴履歴サーバURL取得処理は、終了される。
【０２９３】
以上、視聴履歴サーバURL取得処理の流れについて説明した。この視聴履歴サーバURL取得処理では、サービス選局イベントが発生したとき、すなわち、コンテンツの視聴時に、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され、記録されることになる。
【０２９４】
なお、図３８の視聴履歴サーバURL取得処理では、コンテンツの視聴時に、SYSメタフレームのsysData_atsc3.0に記述された視聴履歴サーバURLが取得される場合を一例に説明したが、他のタイミングで、オーディオユーザデータを利用して伝送される視聴履歴サーバURLが取得され、記録(新規で記録又は更新)されるようにしてもよい。
【０２９５】
また、方式３を採用した場合においても、受信装置２０では、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合には、図２３の視聴履歴情報送信処理が実行され、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)から取得された視聴履歴サーバURLに基づいて、視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０に送信されることになる。
【０２９６】
以上のように、視聴履歴サーバURLの伝送方法として、オーディオユーザデータを利用した方式である方式３を採用した場合、オーディオユーザデータに、視聴履歴サーバURLを含めることで、送信装置１０から、受信装置２０に視聴履歴サーバURLが通知される。また、このような方式３を採用した場合、アンテナで直接受信を行う受信装置２０では、オーディオユーザデータを処理できるし、MVPDを経由した間接受信を行う受信装置２０であっても、オーディオユーザデータを処理することができるため、それらの受信環境に関係なく、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に含まれる視聴履歴サーバURLを取得して、視聴履歴情報(CDM)の送信時に用いることができる。
【０２９７】
なお、上述した説明では、オーディオユーザデータ(SYSメタフレームのsysData_atsc3.0)に、視聴履歴サーバURLを含めた場合を説明したが、ビデオユーザデータが使用可能な場合には、当該ビデオユーザデータを利用して、視聴履歴サーバURLを含めるようにしてもよい。
【０２９８】
（４）方式４：TTML文書のメタデータを利用した視聴履歴サーバURLの伝送
【０２９９】
（視聴履歴情報の収集例）
図３９は、TTML文書のメタデータを利用して視聴履歴サーバURLを伝送する場合における視聴履歴情報(CDM)の収集例を示す図である。
【０３００】
図３９において、各放送局の送信装置１０は、TTML文書のメタデータ(metadata)を利用する方式４により、視聴履歴サーバURLをデジタル放送信号に含めて送信している。具体的には、字幕ストリームで伝送されるTTML文書のメタデータに、視聴履歴サーバURLが記述されることになる。
【０３０１】
ここでは、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されているため、送信装置１０−１乃至１０−３は、視聴履歴サーバ３０にアクセスするための同一の視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)を、デジタル放送信号で伝送される字幕ストリームのTTML文書のメタデータにより通知することになる。
【０３０２】
受信装置２０は、送信装置１０−１乃至１０−３からのデジタル放送信号を受信し、字幕ストリームで伝送されるTTML文書のメタデータに記述された視聴履歴サーバURLを取得して、保持することができる。これにより、受信装置２０は、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合に、保持している視聴履歴サーバURL(例えば、"http://cdmServer.com/cdm"であるURL)に従い、通信回線６０を介して視聴履歴サーバ３０にアクセスして、視聴履歴情報(CDM)を送信することができる。
【０３０３】
視聴履歴サーバ３０は、通信回線６０を介して、複数の受信装置２０から送信されてくる視聴履歴情報(CDM)を受信して蓄積する。視聴履歴サーバ３０は、このようにして複数の受信装置２０から収集された視聴履歴情報(CDM)に対して、例えば、分析処理などを施すことで、各放送局ごとの視聴履歴レポートを生成することができる。
【０３０４】
（TTML文書の記述例）
図４０は、XML形式のTTML文書の記述例を示す図である。
【０３０５】
図４０において、TTML文書に記述されるhead要素のmetadata要素には、視聴履歴サーバURLを記述するためのcdmUri要素が記述されている。ここでは、標準化団体としてのATSC(ATSC3.0)の名前空間(name space)を定義して、cdmUri要素が、このATSC3.0の名前空間に属するようにすることで、TTML文書のメタデータが拡張されている。
【０３０６】
cdmUri要素の開始タグと終了タグの間には、視聴履歴サーバURLとして、"http://cdmServer.com/cdm"が記述されている。このように、metadata要素において、cdmUri要素を拡張することで、TTML文書のメタデータとして、視聴履歴サーバURLを記述することが可能となる。
【０３０７】
次に、図４１及び図４２のフローチャートを参照して、方式４を採用した場合に、図１の伝送システム１を構成する各装置で実行される処理の内容について説明する。
【０３０８】
（視聴履歴サーバURL通知処理）
まず、図４１のフローチャートを参照して、TTML文書のメタデータを利用した場合における視聴履歴サーバURL通知処理の流れについて説明する。なお、この視聴履歴サーバURL通知処理は、図１の送信装置１０により、図１６のステップＳ１０１の処理と並行して実行される処理とされる。
【０３０９】
ステップＳ１４１において、制御部１１１は、視聴履歴サーバURLを通知するタイミングであるかどうかを判定する。
【０３１０】
ステップＳ１４１において、視聴履歴サーバURLを通知するタイミングではないと判定された場合、ステップＳ１４１の判定処理が繰り返される。一方、ステップＳ１４１において、視聴履歴サーバURLを通知するタイミングであると判定された場合、処理は、ステップＳ１４２に進められる。
【０３１１】
ステップＳ１４２において、視聴履歴サーバURL生成部１５１は、対象となる視聴履歴サーバ３０の視聴履歴サーバURLを生成する。このようにして生成された視聴履歴サーバURLは、方式４を採用した場合には、字幕処理部１１７に供給される。
【０３１２】
ステップＳ１４３において、字幕処理部１１７は、字幕ストリームを処理する際に、ステップＳ１４２の処理で生成された視聴履歴サーバURLを、TTML文書のメタデータに追加する。
【０３１３】
ただし、例えば、図３９に示したように、視聴履歴サーバ３０が放送局Ａ，放送局Ｂ，放送局Ｃにより共同で運営されている場合、放送局Ａ，放送局Ｂ，放送局Ｃの送信装置１０−１乃至１０−３では、TTML文書のhead要素において、metadata要素のcdmUri要素の開始タグと終了タグの間に、"http://cdmServer.com/cdm"が記述されることになる。
【０３１４】
以上、視聴履歴サーバURL通知処理の流れについて説明した。この視聴履歴サーバURL通知処理では、TTML文書のhead要素において、metadata要素のcdmUri要素の開始タグと終了タグの間に、視聴履歴サーバURLが記述される。そして、当該metadata要素を含むTTML文書を含む字幕ストリームが生成され（図１６のＳ１０１）、デジタル放送信号に含めて送信されることになる（図１６のＳ１０２）。
【０３１５】
（視聴履歴サーバURL取得処理）
次に、図４２のフローチャートを参照して、TTML文書のメタデータを利用した場合における視聴履歴サーバURL取得処理の流れについて説明する。なお、この視聴履歴サーバURL取得処理は、図１の受信装置２０により、例えば、ユーザの選局操作に応じて選局されたサービスのコンテンツの視聴中に実行される処理とされる。
【０３１６】
ステップＳ２８１においては、制御部２１１によって、入力部２１３からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２８２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２８３に進められる。
【０３１７】
ステップＳ２８３において、放送制御部２５１は、記録部２１２に記録された選局情報に基づいて、受信部２１４等の動作を制御することで、選局処理を行う。
【０３１８】
ステップＳ２８４において、放送制御部２５１は、ビデオ処理部２１６、オーディオ処理部２１８、及び、字幕処理部２２０を制御することで、ビデオ、オーディオ、及び、字幕のコンポーネント(のストリーム)をレンダリングする。
【０３１９】
ステップＳ２８５においては、TTML文書のメタデータに対する処理を行うかどうかが判定される。ステップＳ２８５において、TTML文書のメタデータに対する処理を行うと判定された場合、処理は、ステップＳ２８６に進められる。ステップＳ２８６において、字幕処理部２２０は、TTML文書のメタデータ(metadata要素のcdmUri要素)に、視聴履歴サーバURLが記述されているかどうかを判定する。
【０３２０】
ステップＳ２８６において、TTML文書のメタデータ(metadata要素のcdmUri要素)に、視聴履歴サーバURLが記述されていると判定された場合、処理は、ステップＳ２８７に進められる。ステップＳ２８７において、視聴履歴サーバURL取得部２５４は、ステップＳ２８６の処理結果に従い、TTML文書のメタデータ(metadata要素のcdmUri要素)に記述される視聴履歴サーバURLを取得し、記録部２１２に記録する。
【０３２１】
一方、ステップＳ２８５において、TTML文書のメタデータに対する処理を行わないと判定された場合、あるいは、ステップＳ２８６において、TTML文書のメタデータ(metadata要素のcdmUri要素)に、視聴履歴サーバURLが記述されていないと判定された場合、処理は、ステップＳ２８８に進められる。
【０３２２】
ステップＳ２８８においては、ユーザによる視聴が終了するかどうかが判定される。ステップＳ２８８において、視聴が終了しないと判定された場合、処理は、ステップＳ２８４に戻り、それ以降の処理が繰り返される。一方、ステップＳ２８８において、視聴が終了すると判定された場合、図４２の視聴履歴サーバURL取得処理は、終了される。
【０３２３】
以上、視聴履歴サーバURL取得処理の流れについて説明した。この視聴履歴サーバURL取得処理では、サービス選局イベントが発生したとき、すなわち、コンテンツの視聴時に、TTML文書のメタデータ(metadata要素のcdmUri要素)に、視聴履歴サーバURLが記述されている場合には、当該視聴履歴サーバURLが取得され、記録されることになる。
【０３２４】
なお、図４２の視聴履歴サーバURL取得処理では、コンテンツの視聴時、TTML文書のメタデータに記述された視聴履歴サーバURLが取得される場合を一例に説明したが、他のタイミングで、TTML文書のメタデータを利用して伝送される視聴履歴サーバURLが取得され、記録(新規で記録又は更新)されるようにしてもよい。
【０３２５】
また、方式４を採用した場合においても、受信装置２０では、視聴履歴情報(CDM)を視聴履歴サーバ３０に送信するタイミングとなった場合には、図２３の視聴履歴情報送信処理が実行され、TTML文書のメタデータ(metadata要素のcdmUri要素)から取得された視聴履歴サーバURLに基づいて、視聴履歴情報(CDM)が、通信回線６０を介して視聴履歴サーバ３０に送信されることになる。
【０３２６】
以上のように、視聴履歴サーバURLの伝送方法として、TTML文書のメタデータを利用した方式である方式４を採用した場合、TTML文書のメタデータに、視聴履歴サーバURLを含めることで、送信装置１０から、受信装置２０に視聴履歴サーバURLが通知される。また、このような方式４を採用した場合、アンテナで直接受信を行う受信装置２０では、TTML文書のメタデータを処理できるし、MVPDを経由した間接受信を行う受信装置２０であっても、TTML文書のメタデータを処理することができるため、それらの受信環境に関係なく、TTML文書のメタデータに含まれる視聴履歴サーバURLを取得して、視聴履歴情報(CDM)の送信時に用いることができる。
【０３２７】
＜４．変形例＞
【０３２８】
上述した説明としては、地上デジタルテレビ放送の規格として、米国等で採用されている方式であるATSCを説明したが、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、地上デジタルテレビ放送に限らず、衛星デジタルテレビ放送やデジタル有線テレビ放送などで採用するようにしてもよい。
【０３２９】
また、上述した説明では、バイナリ形式のSLTについて説明したが、SLTは、XML形式などのテキスト形式であってもよい。図４３乃至図４６は、XML形式のSLTのシンタックスの例を示している。同様に、SLTに配置される記述子も、バイナリ形式に限らず、XML形式等のテキスト形式とすることができる。図４７は、XML形式のシグナリングロケーション記述子のシンタックスの例を示している。
【０３３０】
＜５．コンピュータの構成＞
【０３３１】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３３２】
コンピュータ９００において、CPU(Central Processing Unit)９０１，ROM(Read Only Memory)９０２，RAM(Random Access Memory)９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
【０３３３】
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
【０３３４】
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
【０３３５】
コンピュータ９００(CPU９０１)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３３６】
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
【０３３７】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含む。また、プログラムは、１のコンピュータ(プロセッサ)により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３３８】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３３９】
また、本技術は、以下のような構成をとることができる。
【０３４０】
（１）
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、
前記放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得する取得部と、
取得された前記宛先情報に基づいて、前記視聴履歴情報を、通信回線を介して前記視聴履歴サーバ宛てに送信する制御を行う制御部と
を備える受信装置。
（２）
前記宛先情報は、前記コンテンツの選局処理を制御するための情報を含む第１の制御情報に含めて伝送され、
前記取得部は、前記第１の制御情報に含まれる前記宛先情報を取得する
（１）に記載の受信装置。
（３）
前記第１の制御情報は、前記宛先情報を、前記コンテンツのサービスごとに指定するか、又は、前記サービスで共通になるように指定する
（２）に記載の受信装置。
（４）
前記第１の制御情報は、
IPパケットに含まれるUDP(User Datagram Protocol)パケットに配置されて伝送され、
ROUTE(Real-Time Object Delivery over Unidirectional Transport)セッション又はMMT(MPEG Media Transport)セッションで伝送される第２の制御情報に先行して取得される
（２）又は（３）に記載の受信装置。
（５）
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのウォータマークに含めて伝送され、
前記取得部は、前記ウォータマークに含まれる前記宛先情報を取得する
（１）に記載の受信装置。
（６）
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのユーザデータに含めて伝送され、
前記取得部は、前記ユーザデータに含まれる前記宛先情報を取得する
（１）に記載の受信装置。
（７）
前記宛先情報は、前記コンテンツを構成する字幕を表示するためのTTML(Timed Text Markup Language)形式のTTML文書のメタデータに含めて伝送され、
前記取得部は、前記TTML文書のメタデータに含まれる前記宛先情報を取得する
（１）に記載の受信装置。
（８）
前記視聴履歴情報を管理する管理部をさらに備える
（１）乃至（７）のいずれかに記載の受信装置。
（９）
前記IP伝送方式は、ATSC(Advanced Television Systems Committee)3.0に準拠し、
前記宛先情報は、前記視聴履歴サーバのURL(Uniform Resource Locator)であり、
前記視聴履歴情報は、ATSCで規定されるCDM(Consumption Data Message)である
（１）乃至（８）のいずれかに記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を取得し、
取得された前記宛先情報に基づいて、前記視聴履歴情報を、通信回線を介して前記視聴履歴サーバ宛てに送信する制御を行う
ステップを含むデータ処理方法。
（１１）
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を生成する生成部と、
生成された前記宛先情報を、前記コンテンツとともに、前記放送波で送信する送信部と
を備える送信装置。
（１２）
前記宛先情報は、前記コンテンツの選局処理を制御するための情報を含む第１の制御情報に含めて伝送される
（１１）に記載の送信装置。
（１３）
前記第１の制御情報は、前記宛先情報を、前記コンテンツのサービスごとに指定するか、又は、前記サービスで共通になるように指定する
（１２）に記載の送信装置。
（１４）
前記第１の制御情報は、
IPパケットに含まれるUDPパケットに配置されて伝送され、
ROUTEセッション又はMMTセッションで伝送される第２の制御情報に先行して取得される
（１２）又は（１３）に記載の送信装置。
（１５）
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのウォータマークに含めて伝送される
（１１）に記載の送信装置。
（１６）
前記宛先情報は、前記コンテンツを構成するビデオ又はオーディオのユーザデータに含めて伝送される
（１１）に記載の送信装置。
（１７）
前記宛先情報は、前記コンテンツを構成する字幕を表示するためのTTML形式のTTML文書のメタデータに含めて伝送される
（１１）に記載の送信装置。
（１８）
前記生成部は、前記宛先情報の変更依頼に応じて、前記宛先情報の内容を変更する
（１１）乃至（１７）のいずれかに記載の送信装置。
（１９）
前記IP伝送方式は、ATSC3.0に準拠し、
前記宛先情報は、前記視聴履歴サーバのURLであり、
前記視聴履歴情報は、ATSCで規定されるCDMである
（１１）乃至（１８）のいずれかに記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、コンテンツの視聴履歴に関する視聴履歴情報を収集する視聴履歴サーバの宛先を示す宛先情報を生成し、
生成された前記宛先情報を、前記コンテンツとともに、前記放送波で送信する
ステップを含むデータ処理方法。
【符号の説明】
【０３４１】
１  伝送システム，  １０  送信装置，  ２０  受信装置，  ３０  視聴履歴サーバ，  ４０  送信設備，  ５０  配信装置，  ６０  通信回線，  １１１  制御部，  １１２  ビデオデータ取得部，  １１３  ビデオ処理部，  １１４  オーディオデータ取得部，  １１５  オーディオ処理部，  １１６  字幕データ取得部，  １１７  字幕処理部，  １１８  シグナリング生成部，  １１９  シグナリング処理部，  １２０  マルチプレクサ，  １２１  送信部，  １２２  通信部，  １５１  視聴履歴サーバURL生成部，  ２１１  制御部，  ２１２  記録部，  ２１３  入力部，  ２１４  受信部，  ２１５  デマルチプレクサ，  ２１６  ビデオ処理部，  ２１７  ビデオ出力部，  ２１８  オーディオ処理部，  ２１９  オーディオ出力部，  ２２０  字幕処理部，  ２２１  表示部，  ２２２  スピーカ，  ２２３  通信部，  ２５１  放送制御部，  ２５２  通信制御部，  ２５３  視聴履歴情報管理部，  ２５４  視聴履歴サーバURL取得部，  ３１１  制御部，  ３１２  通信部，  ３１３  視聴履歴情報蓄積部，  ３５１  視聴履歴情報管理部，  ３５２  視聴履歴情報分析部，  ９００  コンピュータ，  ９０１  CPU
【図１】
2017011503.tif 000003
【図２】
2017011503.tif 000004
【図３】
2017011503.tif 000005
【図４】
2017011503.tif 000006
【図５】
2017011503.tif 000007
【図６】
2017011503.tif 000008
【図７】
2017011503.tif 000009
【図８】
2017011503.tif 000010
【図９】
2017011503.tif 000011
【図１０】
2017011503.tif 000012
【図１１】
2017011503.tif 000013
【図１２】
2017011503.tif 000014
【図１３】
2017011503.tif 000015
【図１４】
2017011503.tif 000016
【図１５】
2017011503.tif 000017
【図１６】
2017011503.tif 000018
【図１７】
2017011503.tif 000019
【図１８】
2017011503.tif 000020
【図１９】
2017011503.tif 000021
【図２０】
2017011503.tif 000022
【図２１】
2017011503.tif 000023
【図２２】
2017011503.tif 000024
【図２３】
2017011503.tif 000025
【図２４】
2017011503.tif 000026
【図２５】
2017011503.tif 000027
【図２６】
2017011503.tif 000028
【図２７】
2017011503.tif 000029
【図２８】
2017011503.tif 000030
【図２９】
2017011503.tif 000031
【図３０】
2017011503.tif 000032
【図３１】
2017011503.tif 000033
【図３２】
2017011503.tif 000034
【図３３】
2017011503.tif 000035
【図３４】
2017011503.tif 000036
【図３５】
2017011503.tif 000037
【図３６】
2017011503.tif 000038
【図３７】
2017011503.tif 000039
【図３８】
2017011503.tif 000040
【図３９】
2017011503.tif 000041
【図４０】
2017011503.tif 000042
【図４１】
2017011503.tif 000043
【図４２】
2017011503.tif 000044
【図４３】
2017011503.tif 000045
【図４４】
2017011503.tif 000046
【図４５】
2017011503.tif 000047
【図４６】
2017011503.tif 000048
【図４７】
2017011503.tif 000049
【図４８】
2017011503.tif 000050