(57)【要約】  本技術は、視聴履歴に関する運用を柔軟に行うことができるようにする情報処理装置、及び、情報処理方法に関する。情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、コンテンツを再生した機器が、デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む視聴履歴情報を生成することで、視聴履歴に関する運用を柔軟に行うことができる。本技術は、例えば、視聴履歴に関する運用の対象となる機器に適用することができる。
2018012315.tif 000002
【特許請求の範囲】
【請求項１】
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える
情報処理装置。
【請求項２】
前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
請求項１に記載の情報処理装置。
【請求項３】
前記固有な情報は、HTTP(Hypertext Transfer Protocol)リクエストのユーザエージェントに含まれる情報である
請求項２に記載の情報処理装置。
【請求項４】
前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IP(Internet Protocol)アドレスをさらに含む
請求項３に記載の情報処理装置。
【請求項５】
前記ユーザエージェントは、オペレーティングシステム（OS：Operating System）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
請求項３に記載の情報処理装置。
【請求項６】
前記デジタル放送の放送波を受信する受信部と、
前記放送波から得られる、前記デジタル放送の規格に準拠したデータを処理するデータ処理部と、
前記非対応機器から送信されてくるHTTPリクエストに応じて、ネットワークを介して、前記データ処理部からの前記データを、前記非対応機器に送信する通信部と
をさらに備え、
前記視聴履歴処理部は、前記非対応機器で再生された前記コンテンツの視聴履歴に対し、前記非対応機器からのHTTPリクエストから得られるユーザエージェントに含まれる情報と、前記非対応機器に割り当てられたIPアドレスを関連付けた前記視聴履歴情報を生成する
請求項４に記載の情報処理装置。
【請求項７】
前記視聴履歴処理部は、HTTPプロキシサーバのモジュールとして実装される
請求項６に記載の情報処理装置。
【請求項８】
前記対応機器又は前記非対応機器において、前記コンテンツは、ブラウザ上で再生される
請求項６に記載の情報処理装置。
【請求項９】
前記通信部は、前記視聴履歴情報を、ネットワークを介して、前記視聴履歴情報を収集する視聴履歴サーバに送信する
請求項６に記載の情報処理装置。
【請求項１０】
前記データ処理部からの前記データを再生する再生部をさらに備える
請求項６に記載の情報処理装置。
【請求項１１】
情報処理装置の情報処理方法において、
前記情報処理装置が、
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成するステップを含む
情報処理方法。
【請求項１２】
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、
複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部と
を備える情報処理装置。
【請求項１３】
前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
請求項１２に記載の情報処理装置。
【請求項１４】
前記固有な情報は、HTTPリクエストのユーザエージェントに含まれる情報である
請求項１３に記載の情報処理装置。
【請求項１５】
前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IPアドレスをさらに含む
請求項１４に記載の情報処理装置。
【請求項１６】
前記ユーザエージェントは、オペレーティングシステム（OS）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
請求項１４に記載の情報処理装置。
【請求項１７】
情報処理装置の情報処理方法において、
前記情報処理装置が、
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信し、
複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する
ステップを含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置、及び、情報処理方法に関し、特に、視聴履歴に関する運用を柔軟に行うことができるようにした情報処理装置、及び、情報処理方法に関する。
【背景技術】
【０００２】
放送の分野では、ユーザによるコンテンツの視聴履歴を収集して分析するなどの視聴履歴に関する運用が行われる場合がある。例えば、視聴履歴を、定期的に又は必要なときに伝送する技術が開示されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−２７８６５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、視聴履歴に関する運用を行うための技術方式が確立されていないため、視聴履歴に関する運用を柔軟に行うための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、視聴履歴に関する運用を柔軟に行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える情報処理装置である。【０００７】
本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の情報処理方法は、上述した本技術の第１の側面の情報処理装置に対応する情報処理方法である。【０００８】
本技術の第１の側面の情報処理装置、及び、情報処理方法においては、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報が生成される。【０００９】
本技術の第２の側面の情報処理装置は、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部とを備える情報処理装置である。【００１０】
本技術の第２の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の情報処理方法は、上述した本技術の第２の側面の情報処理装置に対応する情報処理方法である。【００１１】
本技術の第２の側面の情報処理装置、及び、情報処理方法においては、デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報が受信され、複数の機器からの前記視聴履歴情報が収集され、収集された複数の前記視聴履歴情報が、前記機器情報に応じて処理される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、視聴履歴に関する運用を柔軟に行うことができる。【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】IP伝送方式に対応したプロトコルスタックの例を示す図である。
【図２】IP伝送方式に対応した伝送システムの構成を示す図である。
【図３】現行のCDMのフォーマットの例を示す図である。
【図４】DeviceInfoの詳細な内容を説明する図である。
【図５】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図６】本技術のCDMのフォーマットの例を示す図である。
【図７】ATSC3.0非対応機器のCDMの記載例を示す図である。
【図８】ATSC3.0非対応機器のCDMの記載例を示す図である。
【図９】CDMのJSONスキーマの例を示す図である。
【図１０】CDMのJSONスキーマの例を示す図である。
【図１１】CDMのJSONスキーマの例を示す図である。
【図１２】CDMのJSONスキーマの例を示す図である。
【図１３】URサーバとURクライアントとの間のプロトコルの例を示す図である。
【図１４】URサーバの構成例を示す図である。
【図１５】SLTのフォーマットの例を示す図である。
【図１６】urlType属性の属性値の例を示す図である。
【図１７】視聴履歴情報対応処理の流れを説明するフローチャートである。
【図１８】視聴履歴情報対応処理の流れを説明するフローチャートである。
【図１９】ATSC3.0対応機器のCDMの記載例を示す図である。
【図２０】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．本技術の概要
２．システムの構成
３．本技術の視聴履歴情報（CDM）
４．Usage Reporting装置間のプロトコル
５．視聴履歴情報対応処理の流れ
６．変形例
７．コンピュータの構成
【００１７】
＜１．本技術の概要＞
【００１８】
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。
【００１９】
（プロトコルスタックの例）
図１は、IP伝送方式に対応したプロトコルスタックの例を示す図である。
【００２０】
図１のプロトコルスタックにおいて、物理層(PHY：Physical Layer)とMAC層の上位の階層は、UDP/IP層とされる。UDP/IP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDP(User Datagram Protocol)パケットが特定される。
【００２１】
ここで、ATSC3.0では、シグナリングとして、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送されるシグナリングである。SLSは、サービス単位のシグナリングである。すなわち、ATSC3.0では、トランスポート層のシグナリングが、LLSとSLSの２階層で伝送される。
【００２２】
LLSは、UDP/IPパケットに格納されて伝送される。LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。
【００２３】
UDP/IP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００２４】
このROUTEセッションにより、サービス（Service）ごとに、SLSのファイル（Service Signaling File）や、DASHセグメントのファイル（Audio/Video/CC DASH File）、LCC(Locally Cached Content)のファイル（LCC(NRT) File）などが伝送される。
【００２５】
SLSは、サービスレベルのシグナリングであり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation 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に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。ここで、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)の派生フォーマットである。ISO BMFFは、ボックス（Box）と称される木構造から構成される。
【００３１】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。なお、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
【００３２】
なお、LLSとしてのSLTメタデータと、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記載されたテキスト形式のデータとすることができる。
【００３３】
このように、ROUTEセッションで伝送される、ビデオ、オーディオ、及び、字幕のストリームと、SLSのストリームと、LCCコンテンツのストリームは、UDP/IPパケットに格納されて伝送される。なお、LCCコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、LCCコンテンツ以外のファイル（例えばアプリケーションのファイル）がROUTEセッションで伝送されるようにしてもよい。
【００３４】
（伝送システムの構成）
図２は、IP伝送方式に対応した伝送システムの構成を示す図である。ここでは、IP伝送方式の一例として、ATSC3.0に対応した伝送システムの実装モデルを説明する。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００３５】
図２の伝送システムは、送信システム１０、対応クライアント装置２０、及び非対応クライアント装置３０から構成される。対応クライアント装置２０は、インターネット６０を介して送信システム１０と相互に接続される。また、対応クライアント装置２０は、家庭内LAN(Local Area Network)等のLAN７０を介して非対応クライアント装置３０と相互に接続される。
【００３６】
送信システム１０は、テレビ番組等のコンテンツを、所定の伝送路を介して配信するためのシステムである。ここで、伝送路としては、地上波等の放送伝送路のほか、インターネット６０等の通信伝送路がある。
【００３７】
送信システム１０は、テレビ番組等のコンテンツを、ATSC3.0に準拠したデータとして処理し、デジタル放送の放送波として、中継局５０を介して、複数の対応クライアント装置２０に送信（一斉同報配信）する。また、送信システム１０は、テレビ番組等のコンテンツを、ストリーミング配信するためのデータとして処理し、インターネット６０を介して、対応クライアント装置２０に送信（ストリーミング配信）する。
【００３８】
対応クライアント装置２０は、ATSC3.0に準拠したデータを処理可能な電子機器（ATSC3.0対応機器）である。例えば、対応クライアント装置２０は、テレビ受像機やゲートウェイ、ネットワークストレージ、セットトップボックスなどの固定受信機からなる。
【００３９】
対応クライアント装置２０は、制御部２００、放送ミドルウェア２０１、HTTPプロキシサーバ２０２、ブラウザ２０３、及び通信1/F２０４−１，２０４−２から構成される。
【００４０】
制御部２００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。制御部２００は、対応クライアント装置２０の各部の動作を制御する。
【００４１】
放送ミドルウェア２０１は、放送系受信スタックが実装されたクライアントローカルATSCミドルウェア（Client Local ATSC Middleware）である。放送ミドルウェア２０１は、制御部２００からの制御に従い、送信システム１０からのデジタル放送の放送波を受信し、放送波から得られるデータを処理する。
【００４２】
放送ミドルウェア２０１は、PHY・MAC処理部２１１、LLSレトリーバ２１２、LLSパーサ２１３、SLSレトリーバ２１４、SLSパーサ２１５、及びセグメントレトリーバ２１６から構成される。
【００４３】
PHY・MAC処理部２１１は、例えば、チューナやデモジュレータ等から構成される。PHY・MAC処理部２１１は、放送波から得られる物理層フレームに対する処理を行う。この物理層フレームのデータ部からALP(ATSC Link-Layer Protocol)パケットが抽出され、さらに、ALPパケットのペイロードから、UDP/IPパケットが得られる。
【００４４】
LLSレトリーバ２１２は、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケットに含まれるLLS（SLTメタデータ）を取得し、LLSパーサ２１３に供給する。LLSパーサ２１３は、LLSレトリーバ２１２からのLLS（SLTメタデータ）に対する構文解析を行い、その解析結果を、SLSレトリーバ２１４に供給する。
【００４５】
SLSレトリーバ２１４は、LLSパーサ２１３からのLLSの解析結果に基づいて、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケット（に含まれるLCTパケット）として伝送されるROUTEセッションのストリームに含まれるSLS（USBD，S-TSID等のメタデータ）を取得し、SLSパーサ２１５に供給する。
【００４６】
SLSパーサ２１５は、SLSレトリーバ２１４からのSLS（USBD，S-TSID等のメタデータ）に対する構文解析を行い、その解析結果を、セグメントレトリーバ２１６及びHTTPプロキシサーバ２０２（のプロキシキャッシュ２２１）に供給する。
【００４７】
セグメントレトリーバ２１６は、SLSパーサ２１５からのSLSの解析結果に基づいて、PHY・MAC処理部２１１で処理されたデータから、UDP/IPパケット（に含まれるLCTパケット）として伝送されるROUTEセッションのストリームに含まれるDASHセグメントファイルを取得し、HTTPプロキシサーバ２０２（のプロキシキャッシュ２２１）に供給する。
【００４８】
HTTPプロキシサーバ２０２は、対応クライアント装置２０上に実装されたクライアントローカルHTTPプロキシサーバ（Client Local HTTP Proxy Server）である。HTTPプロキシサーバ２０２は、制御部２００からの制御に従い、放送系受信処理を行う放送ミドルウェア２０１又は通信系受信処理を行う通信I/F２０４−１により受信されたDASHセグメントファイルやSLSのファイルを、コンテンツの再生を行うアプリケーションに供給する。
【００４９】
HTTPプロキシサーバ２０２は、プロキシキャッシュ２２１、プロキシキャッシュ２２２、及び放送・通信アドレスリゾルバ２２３から構成される。
【００５０】
プロキシキャッシュ２２１は、放送ミドルウェア２０１からのDASHセグメントやMPDメタデータのファイルを取得する。プロキシキャッシュ２２２は、通信I/F２０４−１により受信されたDASHセグメントやMPDメタデータのファイルを取得する。なお、通信I/F２０４−１は、制御部２００からの制御に従い、インターネット６０を介して、送信システム１０からストリーミング配信されたデータとして、DASHセグメントやMPDメタデータのファイルを受信する。
【００５１】
放送・通信アドレスリゾルバ２２３は、ATSC3.0クライアントアプリケーション（例えば、DASHクライアント２３１やDASHクライアント３１１）からの要求に応じて、プロキシキャッシュ２２１又はプロキシキャッシュ２２２により取得されたDASHセグメントやMPDメタデータのファイルを、ブラウザ２０３又は通信I/F２０４−２に供給する。
【００５２】
具体的には、ATSC3.0クライアントアプリケーションが、DASHセグメントやMPDメタデータのファイル群を要求（HTTPリクエスト）すると、それを受けたHTTPプロキシサーバ２０２では、放送・通信アドレスリゾルバ２２３が、放送経由で（放送受信スタックを介して）取得するか、あるいは通信経由で（通信受信スタックを介して）取得するかの判断を行う。
【００５３】
この判断の材料となる情報は、SLSパーサ２１５から供給される。すなわち、SLSパーサ２１５は、SLSレトリーバ２１４に対し、USBDメタデータやT-TSIDメタデータ等の取得要求を行う。SLSレトリーバ２１４は、PHY・MAC処理部２１１を介して受信されるSLSのLCTパケットに含まれるシグナリングメタを抽出する。
【００５４】
SLSパーサ２１５は、ATSC3.0クライアントアプリケーションからの要求に含まれるURL(Uniform Resource Locator)から、LCTパケットに含まれるシグナリングメタを引いて、対象となるファイル群を取得するための放送配信アドレス情報を解決する。そして、放送経由で配信されることがわかれば、その放送配信アドレス情報に基づき、セグメントレトリーバ２１６が、DASHセグメントファイルを含むLCTパケットを、ROUTEセッションのストリームから取得し、HTTPプロキシサーバ２０２のプロキシキャッシュ２２１内に展開する。
【００５５】
HTTPプロキシサーバ２０２は、このようにしてプロキシキャッシュ２２１内に展開されたファイル群を、ATSC3.0クライアントアプリケーションからの要求（HTTPリクエスト）に対する応答（HTTPレスポンス）として返す。
【００５６】
なお、ATSC3.0クライアントアプリケーションからの要求に含まれるURLが、LCTパケットのシグナリングメタに存在しない場合には、HTTPプロキシサーバ２０２は、プロキシキャッシュ２２２内に展開された、通信受信スタックを介して取得されたファイル群を、ATSC3.0クライアントアプリケーションからの要求（HTTPリクエスト）に対する応答（HTTPレスポンス）として返す。
【００５７】
ブラウザ２０３は、例えば、HTML5(HyperText Markup Language 5)に対応したブラウザである。ブラウザ２０３は、制御部２００からの制御に従い、放送・通信アドレスリゾルバ２２３からのDASHセグメントやMPDメタデータのファイルを処理し、送信システム１０から配信されたコンテンツを再生する。
【００５８】
ブラウザ２０３は、DASHクライアント２３１、デコーダ２３２、及びレンダラ２３３から構成される。また、DASHクライアント２３１は、MPDレトリーバ２４１、MPDパーサ２４２、セグメントレトリーバ２４３、及びMP4パーサ２４４から構成される。
【００５９】
DASHクライアント２３１は、対応クライアント装置２０上に実装されたブラウザ２０３により実行されるATSC3.0クライアントアプリケーション（ATSC3.0 DASH Client）である。DASHクライアント２３１は、HTTPプロキシサーバ２０２を介して、放送ミドルウェア２０１又は通信I/F２０４−１により受信されたDASHセグメントやMPDメタデータのファイルを処理する。なお、DASHクライアント２３１はブラウザ２０３上で実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして提供されるようにしてもよい。
【００６０】
MPDレトリーバ２４１は、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）から供給されるデータから、MPDメタデータのファイルを取得し、MPDパーサ２４２に供給する。MPDパーサ２４２は、MPDレトリーバ２４１からのMPDメタデータに対する構文解析を行い、その解析結果を、セグメントレトリーバ２４３に供給する。
【００６１】
セグメントレトリーバ２４３は、MPDパーサ２４２からのMPDメタデータの解析結果に基づいて、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）から供給されるデータから、DASHセグメントファイルを取得し、MP4パーサ２４４に供給する。
【００６２】
MP4パーサ２４４は、セグメントレトリーバ２４３からのDASHセグメントファイル（セグメント）に対する構文解析を行い、その解析結果を、DASHセグメントファイルとともに、デコーダ２３２に供給する。
【００６３】
デコーダ２３２は、MP4パーサ２４４からの解析結果に従い、DASHセグメントファイルから得られるデータのデコードを行い、その結果得られる復号後のデータを、レンダラ２３３に供給する。レンダラ２３３は、デコーダ２３２からの復号後のデータに対し、レンダリング処理を行う。
【００６４】
このレンダリング処理で得られるビデオデータに対応する映像が、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイに表示され、オーディオデータに対応する音声が、スピーカから出力される。なお、ディスプレイやスピーカは、対応クライアント装置２０が備えるようにしてもよいし、あるいは外部の装置が備えるようにしてもよい。
【００６５】
通信I/F２０４−２は、制御部２００からの制御に従い、家庭内LAN等のLAN７０を介して、非対応クライアント装置３０との間でデータのやりとりを行う。なお、図２では、説明の都合上、通信I/F２０４−２は、通信I/F２０４−１と別個に設けられるとして説明しているが、通信I/F２０４−１と通信I/F２０４−２を１つの通信インターフェース回路として構成するようにしてもよい。
【００６６】
例えば、通信I/F２０４−２は、LAN７０を介して、非対応クライアント装置３０からコンテンツの配信が要求された場合、その要求を、HTTPプロキシサーバ２０２（の放送・通信アドレスリゾルバ２２３）に供給する。
【００６７】
放送・通信アドレスリゾルバ２２３は、通信I/F２０４−２からの要求（HTTPリクエスト）に応じて、プロキシキャッシュ２２１又はプロキシキャッシュ２２２により取得されたDASHセグメントやMPDメタデータのファイルを、通信I/F２０４−２に供給する。そして、通信I/F２０４−２は、放送・通信アドレスリゾルバ２２３からのDASHセグメントやMPDメタデータのファイルを、LAN７０を介して、非対応クライアント装置３０に送信する。
【００６８】
非対応クライアント装置３０は、ATSC3.0に準拠したデータを処理できない電子機器（ATSC3.0非対応機器）である。例えば、非対応クライアント装置３０は、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機からなる。
【００６９】
非対応クライアント装置３０は、制御部３００、通信I/F３０１、及びブラウザ３０２を含んで構成される。
【００７０】
制御部３００は、例えば、CPUやマイクロプロセッサ等から構成される。制御部３００は、非対応クライアント装置３０の各部の動作を制御する。
【００７１】
通信I/F３０１は、例えば、通信インターフェース回路等から構成される。通信I/F３０１は、制御部３００からの制御に従い、家庭内LAN等のLAN７０を介して、対応クライアント装置２０との間でデータのやりとりを行う。
【００７２】
例えば、通信I/F３０１は、対応クライアント装置２０に対し、コンテンツの配信を要求する場合、その要求（HTTPリクエスト）を、LAN７０を介して、対応クライアント装置２０に送信する。これにより、通信I/F３０１は、LAN７０を介して、対応クライアント装置２０から送信されてくるDASHセグメントやMPDメタデータのファイルを受信し、ブラウザ３０２に供給する。
【００７３】
ブラウザ３０２は、例えば、HTML5に対応したブラウザである。ブラウザ３０２は、制御部３００からの制御に従い、通信I/F３０１からのDASHセグメントやMPDメタデータのファイルを処理し、対応クライアント装置２０から送信されてくるコンテンツを再生する。なお、対応クライアント装置２０から送信されてくるコンテンツは、送信システム１０により配信されたコンテンツとなる。
【００７４】
ブラウザ３０２は、DASHクライアント３１１、デコーダ３１２、及びレンダラ３１３から構成される。また、DASHクライアント３１１は、MPDレトリーバ３２１、MPDパーサ３２２、セグメントレトリーバ３２３、及びMP4パーサ３２４から構成される。
【００７５】
DASHクライアント３１１は、非対応クライアント装置３０上に実装されたブラウザ３０２により実行されるATSC3.0クライアントアプリケーション（ATSC3.0 DASH Client）である。DASHクライアント３１１は、通信I/F３０１により受信されたDASHセグメントやMPDメタデータのファイルを処理する。なお、DASHクライアント３１１はブラウザ３０２上で実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして提供されるようにしてもよい。
【００７６】
MPDレトリーバ３２１は、通信I/F３０１から供給されるデータから、MPDメタデータのファイルを取得し、MPDパーサ３２２に供給する。MPDパーサ３２２は、MPDレトリーバ３２１からのMPDメタデータに対する構文解析を行い、その解析結果を、セグメントレトリーバ３２３に供給する。
【００７７】
セグメントレトリーバ３２３は、MPDパーサ３２２からのMPDメタデータの解析結果に基づいて、通信I/F３０１から供給されるデータから、DASHセグメントファイルを取得し、MP4パーサ３２４に供給する。
【００７８】
MP4パーサ３２４は、セグメントレトリーバ３２３からのDASHセグメントファイル（セグメント）に対する構文解析を行い、その解析結果を、DASHセグメントファイルとともに、デコーダ３１２に供給する。
【００７９】
デコーダ３１２は、MP4パーサ３２４からの解析結果に従い、DASHセグメントファイルから得られるデータのデコードを行い、その結果得られる復号後のデータを、レンダラ３１３に供給する。レンダラ３１３は、デコーダ３１２からの復号後のデータに対し、レンダリング処理を行う。
【００８０】
このレンダリング処理で得られるビデオデータに対応する映像が、LCDやOELD等のディスプレイに表示され、オーディオデータに対応する音声が、スピーカから出力される。なお、ディスプレイやスピーカは、非対応クライアント装置３０が備えるようにしてもよいし、あるいは外部の装置が備えるようにしてもよい。
【００８１】
IP伝送方式に対応した伝送システムは、以上のように構成される。
【００８２】
この伝送システムにおいては、ATSC3.0に準拠した送信システム１０から配信されるコンテンツを、ATSC3.0対応機器である対応クライアント装置２０だけでなく、ATSC3.0非対応機器である非対応クライアント装置３０も再生することが可能となる。
【００８３】
すなわち、非対応クライアント装置３０は、ATSC3.0に準拠したデータを処理することはできないが、ATSC3.0クライアントアプリケーションとしてのDASHクライアント３１１を搭載することはできる。そして、このDASHクライアント３１１によって、対応クライアント装置２０で得られるDASHセグメントやMPDメタデータのファイルを処理することで、送信システム１０から配信されるコンテンツを再生することが可能となる。
【００８４】
また、このとき、ATSC3.0クライアントアプリケーションとしてのDASHクライアント２３１やDASHクライアント３１１からすれば、必ず、対応クライアント装置２０のHTTPプロキシサーバ２０２を介して、外部からのデータにアクセスすることになる。なお、LAN７０上の非対応クライアント装置３０からのHTTPリクエストが、すべて、HTTPプロキシサーバ２０２を経由するようにするための設定は、例えば、WPAD(Web Proxy Auto-Discovery Protocol)等を利用して行われる。
【００８５】
そのため、DASHクライアント２３１やDASHクライアント３１１は、処理対象のファイル群を、放送経由で取得しているのか、あるいは通信経由で取得しているのかの区別を意識する必要がない（ネットワークの透過性が提供される）ため、アプリケーションの可搬性を高めることができる。その結果として、クライアント装置を、放送系受信にのみに特化して実装する必要がなく、また、放送系受信と、通信系受信のどうちらを使うかによらない実装にすることができる。
【００８６】
ところで、放送の分野では、Usage Reportingとして、コンテンツの視聴履歴を収集して分析するなどの視聴履歴に関する運用が行われる場合がある。例えば、ATSC3.0においても、視聴履歴情報を収集するためのプロトコルが検討途上にある（例えば、非特許文献１参照）。
【００８７】
非特許文献１：ATSC Candidate Standard : Service Usage Reporting(A/333) Doc. S33-170r316 May 2016
【００８８】
現状のATSC3.0では、視聴履歴のエンドポイントとなるクライアント装置を、機器IDにより識別して、個々のクライアント装置ごとの視聴履歴をレポートすることになっている。ここで、図２に示した伝送システムの構成のように、ゲートウェイとしての対応クライアント装置２０（ATSC3.0対応機器）に実装されるHTTPプロキシサーバ２０２を介して、LAN７０上の非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態が想定される。
【００８９】
このような構成の場合には、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴についてもレポートすることになるが、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）とを区別して、個々のクライアント装置ごとの視聴履歴をレポートすることは困難であった。そのため、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）とを区別できるようにして、視聴履歴に関する運用を柔軟に行うための提案が要請されていた。
【００９０】
そこで、本技術では、視聴履歴情報に、コンテンツを再生したクライアント装置が、デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含めることで、当該視聴履歴情報が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別できるようにする。
【００９１】
すなわち、本技術においては、例えば、ゲートウェイとしての対応クライアント装置２０（ATSC3.0対応機器）に実装されるHTTPプロキシサーバ２０２に対し、アクセスしてくる非対応クライアント装置３０（ATSC3.0非対応機器）からの再生対象のコンテンツに対するHTTPリクエストのヘッダの中の機器に固有な情報と、HTTPリクエストの送信元のIPアドレスが、視聴履歴情報に含まれるようにする。
【００９２】
これにより、図２に示した、非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツ（送信システム１０により配信されたコンテンツ）にアクセスする形態であっても、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別することが可能となる。その結果として、視聴履歴に関する運用を柔軟に行うことが可能となる。
【００９３】
ここで、Usage Reportingとしてレポートされる視聴履歴情報であるが、ATSC3.0では、CDM(Consumption Data Message)の構造からなる。なお、CDMの構造は、上述した非特許文献１の「Table 4.1 CDM Logical Structure」に記載されている。
【００９４】
（CDMの構造例）
図３は、現状のCDMのフォーマットの例を示す図である。なお、CDMは、テキストフォーマットの一種であるJSON(JavaScript（登録商標） Object Notation)形式で記載される。
【００９５】
protocolVersionには、CDMのプロトコルのバージョンが指定される。
【００９６】
DeviceInfoには、機器情報（デバイス情報）が指定される。ここで、現状のCDMでは、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDeviceが規定されている。ここで、図４には、DeviceInfoの属性値の詳細な内容が示されている。DeviceInfoは、各機器に対し、１つだけ記載される。
【００９７】
deviceIDは、対象の機器の識別子である機器IDが指定される。ただし、この機器IDを意図的に隠す場合には、"NOTREPORTED"が記載される。
【００９８】
deviceModelは、対象の機器のモデル番号が指定される。ただし、このモデル番号は、ベンダ固有のフォーマットとされる。また、このモデル番号を意図的に隠す場合には、"NOTREPORTED"が記載される。
【００９９】
deviceManufacturerは、対象の機器のベンダが指定される。ただし、このベンダを意図的に隠す場合には、"NOTREPORTED"が記載される。
【０１００】
deviceOSは、対象の機器のオペレーティングシステム（OS：Operating System）のバージョンが指定される。このバージョンを意図的に隠す場合には、"NOTREPORTED"が記載される。
【０１０１】
peripheralDeviceは、対象の機器が周辺機器であるかどうかを識別するための情報が指定される。この識別情報を意図的に隠す場合には、"NOTREPORTED"が記載される。
【０１０２】
図３の説明に戻り、AVServiceには、対象の機器で再生されたATSC3.0のサービスのストリームに関する情報が指定される。AVServiceの属性値として、serviceID，serviceType，reportIntervalが規定されている。
【０１０３】
serviceIDには、対象の機器で再生されたサービスのIDが指定される。ただし、このサービスIDは、グローバルでユニークな値とされる。serviceTypeには、サービスIDで識別されるサービスのタイプが指定される。
【０１０４】
reportIntervalの属性値として、startTime，endTime，DestinationDeviceType，contentID，component，AppIntervalが規定されている。また、contentIDの属性値として、type，cidが規定されている。また、componentの属性値として、componentType，componentRole，componentName，componentID，componentLang，startTime，endTime，SourceDeliveryPathが規定され、さらに、SourceDeliveryPathには、属性値として、type，startTime，endTimeが規定されている。また、AppIntervalの属性値として、appId，startTime，endTime，LifeCycle，Tagsが規定されている。
【０１０５】
これらの属性値によって、サービスIDで識別されるサービスごとに、視聴履歴に関する情報を記載することができる。
【０１０６】
ただし、DestinationDeviceTypeとしては、下記の値が規定されており、例えば、"0"が指定された場合には、テレビ受像機により対象のサービスが視聴されたことを表し、"1"が指定された場合には、テレビ受像機以外の機器（例えば、タブレット型コンピュータ等）により対象のサービスが視聴されたことを表している。
【０１０７】
0 - Content is presented on a Primary Device
1 - Content is presented on a Companion Device 
2 - Content is sent to a Time-shift-buffer
3 - Content is sent to a Hard-drive
4 to 255 - Reserved.
【０１０８】
また、contentIDのtypeとしては、"EIDR"又は"Ad ID"を指定することができる。"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad ID"は、Advertising IDの略であり、広告用のIDである。
【０１０９】
また、SourceDeliveryPathのtypeとしては、下記の値が規定されており、例えば、"0"が指定された場合には、対象のサービスのコンポーネントが放送経由で配信されたことを表し、"1"が指定された場合には、対象のサービスのコンポーネントが通信経由で配信されたことを表している。
【０１１０】
0 - Broadcast delivery (content component is delivered by broadcast)
1 - Broadband delivery (content component is delivered by broadband)
2 - Time-shift-buffer source (content source is local time shift buffer)
3 - Hard-drive source (content source is local hard drive)
4 to 255 - Reserved.
【０１１１】
なお、図３において、Cardinalityの項目は、出現数を表している。例えば、"1"が指定された場合には、その要素又は属性は必ず１つだけ指定される。また、例えば、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意であり、"1..N"が指定された場合には、その要素又は属性は１以上指定される。
【０１１２】
＜２．システムの構成＞
【０１１３】
次に、図５を参照して、Usage Reportingに対応した伝送システムの構成について説明する。
【０１１４】
（本技術の伝送システムの構成例）
図５は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【０１１５】
図５においては、図２と同様に、IP伝送方式の一例として、ATSC3.0に対応した伝送システムの実装モデルを説明する。図５の伝送システムにおいて、図２の伝送システムと対応する部分には、同一の符号が付してあり、その説明は繰り返しになるので、適宜省略するものとする。
【０１１６】
すなわち、図５において、送信システム１０には、視聴履歴情報を収集するUR(Usage Reporting)サーバ１０１が設けられている。また、対応クライアント装置２０には、視聴履歴情報をレポートするための機能（モジュール）として、HTTPプロキシサーバ２０２に、URクライアント２２４及びHTTPリクエストハンドラ２２５が設けられている。
【０１１７】
これらの機能を、送信側の送信システム１０と、受信側の対応クライアント装置２０に追加することで、対応クライアント装置２０のブラウザ２０３（のDASHクライアント２３１）でのコンテンツの再生履歴（視聴履歴）や、非対応クライアント装置３０のブラウザ３０２（のDASHクライアント３１１）でのコンテンツの再生履歴（視聴履歴）を記録して、レポートすることが可能となる。
【０１１８】
対応クライアント装置２０のHTTPプロキシサーバ２０２において、URクライアント２２４は、HTTPリクエストハンドラ２２５からの通知に応じて、本技術のCDMの構造からなる視聴履歴情報を生成するモジュールである。
【０１１９】
HTTPリクエストハンドラ２２５は、ATSC3.0クライアントアプリケーション（DASHクライアント２３１やDASHクライアント３１１）からの要求（HTTPリクエスト）を、最初に受信して解析するモジュールである。
【０１２０】
これにより、URクライアント２２４は、HTTPリクエストハンドラ２２５からの通知に応じて、対応クライアント装置２０のブラウザ２０３（のDASHクライアント２３１）でのコンテンツの再生に応じた視聴履歴情報や、非対応クライアント装置３０のブラウザ３０２（のDASHクライアント３１１）でのコンテンツの再生に応じた視聴履歴情報を生成することになる。
【０１２１】
すなわち、URクライアント２２４は、HTTPリクエストハンドラ２２５を介して、HTTPリクエストのトラフィックを監視することで、対応クライアント装置２０の内部に実装されたDASHクライアント２３１と、対応クライアント装置２０の外部に実装されたDASHクライアント３１１とのコンテンツの再生履歴（視聴履歴）を記録することが可能となる。
【０１２２】
ここで、視聴履歴情報は、本技術のCDMの構造からなる。上述したように、ATSC3.0で規定されたCDMの構造は、機器情報としてのDeviceInfo要素と、その機器で再生されたATSC3.0のサービスのストリームに関するAVService要素を含んでいる。
【０１２３】
本技術では、CDMの構造として、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）を含めることで、対象の視聴履歴情報（CDM）が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別できるようにする。
【０１２４】
すなわち、URクライアント２２４は、HTTPプロキシサーバ２０２に対してアクセスしてくる非対応クライアント装置３０（ATSC3.0非対応機器）からの再生対象のコンテンツに対するHTTPリクエストのヘッダの中の機器に固有な情報と、HTTPリクエストの送信元のIPアドレスが、視聴履歴情報（CDM）に含まれるようにする。なお、本技術のCDMの構造からなる視聴履歴情報の詳細な内容は、図６乃至図１２を参照して後述する。
【０１２５】
また、URクライアント２２４は、所定のタイミングで、視聴履歴情報を、通信I/F２０４−１に供給する。通信I/F２０４−１は、URクライアント２２４からの視聴履歴情報を、インターネット６０を介して、URサーバ１０１に送信する。
【０１２６】
なお、URクライアント２２４が視聴履歴情報を送信するタイミングとしては、例えば、あらかじめ定められた間隔で定期的に送信したり、あるいは、送信システム１０から対応クライアント装置２０に送信されるシグナリングや、ビデオやオーディオのウォータマークメッセージに含まれるコメントなどに応じて送信したりすることができる。
【０１２７】
URサーバ１０１は、インターネット６０を介して、対応クライアント装置２０（のURクライアント２２４）から送信されてくる視聴履歴情報を受信する。なお、図５においては、説明の都合上、１台の対応クライアント装置２０のみを図示しているが、実際には、URサーバ１０１では、複数の対応クライアント装置２０（のURクライアント２２４）からの視聴履歴情報が受信され、複数の視聴履歴情報が収集される。
【０１２８】
URサーバ１０１は、収集された視聴履歴情報に対して、視聴履歴の分析や解析などの各種の処理を行う。例えば、URサーバ１０１は、放送局ごとの視聴履歴に関する視聴履歴レポートを生成し、各放送局に提供することができる。
【０１２９】
ここで、本技術のCDMの構造からなる視聴履歴情報には、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）が含まれている。
【０１３０】
そのため、URサーバ１０１は、対象の視聴履歴情報が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別して、視聴履歴レポートを生成することができる。つまり、非対応クライアント装置３０（ATSC3.0非対応機器）が、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態であっても、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別することが可能となる。
【０１３１】
なお、図３に示した現状のCDMにおいては、DestinationDeviceTypeにより、テレビ受像機と、テレビ受像機以外の機器のいずれかにより、対象のサービスのコンテンツが再生されたということは分かるが、本技術のCDMのように、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれかにより、対象のサービスのコンテンツが再生されたということまでは分からない。
【０１３２】
本技術の伝送システムは、以上のように構成される。
【０１３３】
＜３．本技術の視聴履歴情報（CDM）＞
【０１３４】
次に、図６乃至図１２を参照して、本技術のCDMの構造からなる視聴履歴情報の詳細について説明する。
【０１３５】
（本技術のCDMの構造例）
図６は、本技術のCDMのフォーマットの例を示す図である。上述したように、CDMは、JSON形式で記載される。
【０１３６】
図６のCDMのフォーマットは、上述のCDMのフォーマット（図３）と比べて、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDeviceのほかに、non3.0DeviceAttributesが追加されている点が異なっている。
【０１３７】
non3.0DeviceAttributesは、ATSC3.0に準拠したデータを処理可能な機器であるかを示す属性である。このnon3.0DeviceAttributesにより、対象のCDMが、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別することが可能となる。
【０１３８】
non3.0DeviceAttributesの属性値としては、"schemeIdUri"と"value"の組を指定することができる。例えば、"schemeIdUri"に対し、HTTPリクエストのユーザエージェント（UserAgent）のヘッダの内容であることを識別するURI(Uniform Resource Identifier)として、"urn:browserUserAgent"である値を定義することで、ユーザエージェントのヘッダに格納されている文字列（情報）を、"value"の値として記載することができる。
【０１３９】
ここで、非対応クライアント装置３０により発行される、放送サービスのDASHセグメントファイルやアプリケーションファイルに対するHTTPリクエストのユーザエージェントのヘッダ（HTTPリクエストヘッダ）には、ユーザエージェントとして、オペレーティングシステム（OS）に関する情報やモバイル端末であるかどうかを示す情報が含まれている。なお、このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。
【０１４０】
例えば、ユーザエージェントとして、"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"が得られると、非対応クライアント装置３０が、Windows（登録商標）をオペレーティングシステム（OS）とするパーソナルコンピュータであることが分かる。
【０１４１】
また、例えば、ユーザエージェントとして、"Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"が得られると、非対応クライアント装置３０が、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであることが分かる。なお、当該ユーザエージェントにおいて、"Mobile"の記載がないと、タブレット型コンピュータで有ることが分かる。
【０１４２】
また、non3.0DeviceAttributesにおいて、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURI（"urn:browserUserAgent"）のほかに、IPアドレスの内容であることを識別するURIとして、"urn:ipAddress"である値を定義することで、ローカルのIPアドレスを、"value"の値として記載することができる。
【０１４３】
例えば、"value"の値として、"192.168.0.12"が得られると、非対応クライアント装置３０に割り当てられているローカルのIPアドレスが、"192.168.0.12"であることが分かる。
【０１４４】
（本技術のCDMの記載例）
次に、図７及び図８を参照して、本技術のCDMの記載例を説明する。なお、JSON形式のオブジェクトは、キーと値のペアをコロン（：）で対にして、これらの対を、コンマ（，）で区切ってゼロ個以上列挙し、全体を波括弧（｛｝）でくくることで表現される。
【０１４５】
（Ａ）CDMの記載例１
図７は、ATSC3.0非対応機器に固有な情報として、ユーザエージェントに関する情報を含めた場合のCDMの記載例を示す図である。なお、図７においては、説明の簡略化のため、DeviceInfoの属性値と、AVServiceの属性値の一部を抜粋して記載している。
【０１４６】
図７のCDMにおいては、DeviceInfoの属性値として、deviceID，deviceModel，deviceManufacturer，deviceOS，peripheralDevice，non3.0DeviceAttributesが含まれる。
【０１４７】
deviceIDであるキーに対し、"NOTREPORTED"である値がペアになって指定されている。すなわち、機器IDが意図的に隠されていることを表している。
【０１４８】
また、deviceModel，deviceManufacturer，deviceOS，peripheralDeviceに対しても、"NOTREPORTED"である値がそれぞれ指定され、対象の機器のモデル番号、対象の機器の製造元（ベンダ）、対象の機器のオペレーティングシステム（OS）のバージョン、及び対象の機器が周辺機器かどうかを識別するための情報が、意図的に隠されていることを表している。
【０１４９】
non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されている。ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURIとして、"urn:browserUserAgent"である値が定義され、ユーザエージェントのヘッダに格納されている文字列（情報）が、"value"の値として記載されている。
【０１５０】
図７の例では、"value"の値として、"Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"と記載されており、非対応クライアント装置３０が、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであることを表している。
【０１５１】
AVServiceのreportIntervalにおいて、ContentIDの属性値として、"type"と"cid"の組が指定されている。ここでは、"type"に対し、"EIDR"である値が定義され、EIDRのフォーマットのコンテンツ識別子（CID：Content ID）である"cid"の値として、"10.5240/EA73-79D7-1B2B-B378-3A73-M"が設定されていることを表している。
【０１５２】
Componentの属性値として、"componentType"が指定されている。ここでは、"componentType"に対し、"1"である値が設定され、対象のコンポーネントが、ビデオであることを表している。
【０１５３】
以上のように、図７のCDMの記載例では、non3.0DeviceAttributesの属性値で識別された、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンとしての非対応クライアント装置３０（ATSC3.0非対応機器）により再生されたコンテンツが、"10.5240/EA73-79D7-1B2B-B378-3A73-M"であるEIDR形式のコンテンツ識別子（CID）を有するビデオのコンテンツであることを表している。
【０１５４】
（Ｂ）CDMの記載例２
図８は、ATSC3.0非対応機器に固有な情報として、ユーザエージェントに関する情報とIPアドレスを含めた場合のCDMの記載例を示す図である。なお、図８においても、説明の簡略化のため、DeviceInfoの属性値と、AVServiceの属性値の一部を抜粋して記載しているが、図７の記載例と対応する部分についてはその説明は省略するものとする。
【０１５５】
図８のCDMにおいては、non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されているが、ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURI（"urn:browserUserAgent"）のほかに、IPアドレスの内容であることを識別するURIとして、"urn:ipAddress"である値が定義され、IPアドレスの値が、"value"の値として記載されている。
【０１５６】
図８の例では、"value"の値として、"192.168.0.12"と記載されており、非対応クライアント装置３０に割り当てられているローカルのIPアドレスが、"192.168.0.12"であることを表している。
【０１５７】
以上のように、図８のCDMの記載例では、non3.0DeviceAttributesの属性値で識別された、Android（登録商標）をオペレーティングシステム（OS）とするスマートフォンであって、"192.168.0.12"であるローカルのIPアドレスが割り当てられた非対応クライアント装置３０（ATSC3.0非対応機器）により再生されたコンテンツが、"10.5240/EA73-79D7-1B2B-B378-3A73-M"であるEIDR形式のコンテンツ識別子（CID）を有するビデオのコンテンツであることを表している。
【０１５８】
なお、図７及び図８においては、JSON形式のCDMの記載例を示したが、本技術のCDMの記載形式は、JSON形式に限らず、例えば、XML(Extensible Markup Language)形式など、他のテキスト形式のデータを採用することもできる。
【０１５９】
また、図７及び図８においては、DeviceInfoの属性値（deviceID等）は、必須の値となるため、意図的に隠す場合には、"NOTREPORTED"が記載されるとしたが、DeviceInfoの属性値が任意の値となるようにすることで、意図的に隠す場合に、DeviceInfoの属性値自体の記載を省略することもできる。
【０１６０】
（JSONスキーマの例）
図９乃至図１２は、本技術のCDMのJSONスキーマの例を示す図である。
【０１６１】
図９乃至図１２のJSONスキーマは、図６に示した本技術のCDMのフォーマットに対応している。すなわち、このJSONスキーマは、ATSC3.0で規定されている現状のCDMを拡張した本技術のCDMに対応しており、拡張された部分以外の構造は、現状のCDMのJSONスキーマの構造と同様である。現状のCDMのJSONスキーマの構造は、上述の非特許文献１の「Annex A: Schema」に開示されているため、ここでは、その説明は省略するものとする。
【０１６２】
図９乃至図１２に示したCDMのJSONスキーマのうち、図９の29乃至44の段落には、DeviceInfoの属性値として、non3.0DeviceAttributesが定義されている。ここでは、配列型となるnon3.0DeviceAttributesの属性値として、文字列型の"schemeIdUri"と、文字列型の"value"との組が定義されている。ただし、それらの組において、"schemeIdUri"は、必須の要素とされる。
【０１６３】
このようなCDMのJSONスキーマを定義することで、例えば、"schemeIdUri"に対し、"urn:browserUserAgent"である値を定義することで、HTTPリクエストのユーザエージェントの情報を、"value"の値として記載することができる。また、例えば、"schemeIdUri"に対し、"urn:ipAddress"である値を定義することで、ローカルのIPアドレスを、"value"の値として記載することができる。
【０１６４】
＜４．Usage Reporting装置間のプロトコル＞
【０１６５】
（UsageReportingプロトコルの例）
図１３は、図５に示したURサーバ１０１と、対応クライアント装置２０のURクライアント２２４との間のプロトコルの例を示す図である。
【０１６６】
対応クライアント装置２０においては、放送ミドルウェア２０１により、送信システム１０からのLLSが処理され、SLTメタデータが得られるが、このSLTメタデータに、URサーバ１０１のURLが含まれている。そして、通信I/F２０４−１は、SLTメタデータに含まれるURサーバ１０１のURLに従い、インターネット６０を介してURサーバ１０１にアクセスすることができる。なお、SLTメタデータにて周知されるURサーバ１０１のURLの詳細は、図１５及び図１６を参照して後述する。
【０１６７】
ここでは、HTTPプロキシサーバ２０２のURクライアント２２４により生成された視聴履歴情報（CDM）が、インターネット６０を介して、URサーバ１０１に送信される。この視聴履歴情報（CDM）は、HTTPリクエストのPUTメソッドを利用して、ボディ部に格納することができる。
【０１６８】
すなわち、対応クライアント装置２０（URクライアント２２４）から、URサーバ１０１に対しては、図１３に示したCDMメッセージの形式で、視聴履歴情報（CDM）を送信することができるが、このCDMメッセージでは、１行目のリクエスト行に、メソッドを示す「PUT」と、指定されたURLのディレクトリとパス名を示すURIと、HTTPバージョンを示す「HTTP/1.1」が記載される。
【０１６９】
また、CDMメッセージにおいて、２行目乃至４行目のヘッダ部に、指定されたURLのホスト名を示す「Host」と、データの形式が指定される「Content-Type」と、ボディ部の長さが指定される「Content-Length」が記載される。そして、改行を挟んで６行目のボディ部に、JSON形式でエンコードされたCDM構造からなる視聴履歴情報を格納することができる。
【０１７０】
このようなプロトコルに従い、対応クライアント装置２０（URクライアント２２４）から送信されてくる視聴履歴情報（CDM）が、インターネット６０を介してURサーバ１０１により受信され、処理されることになる。なお、URサーバ１０１の詳細な構成は、図１４を参照して後述する。
【０１７１】
（URサーバの構成例）
図１４は、図５のURサーバ１０１の構成例を示す図である。
【０１７２】
URサーバ１０１は、通信I/F１１１、CDM記録部１１２、CDM分析部１１３、及び出力部１１４から構成される。
【０１７３】
通信I/F１１１は、例えば、通信インターフェース回路等から構成され、インターネット６０を介して、対応クライアント装置２０とデータをやりとりする。通信I/F１１１は、インターネット６０を介して、複数の対応クライアント装置２０から送信されてくる視聴履歴情報を受信し、CDM記録部１１２に供給する。
【０１７４】
CDM記録部１１２は、例えば、ハードディスク（HDD：Hard Disk Drive）や半導体メモリ等から構成される。CDM記録部１１２は、通信I/F１１１からの視聴履歴情報を記録する。これにより、複数の対応クライアント装置２０からの視聴履歴情報が収集される。この視聴履歴情報は、図６に示した本技術のCDMの構造からなる。
【０１７５】
CDM分析部１１３は、例えば、CPUやマイクロプロセッサ等から構成される。CDM分析部１１３は、CDM記録部１１２に記録されている視聴履歴情報を読み出し、読み出された視聴履歴情報を分析する。CDM分析部１１３は、視聴履歴情報の分析結果に従い、視聴履歴に関する視聴履歴レポートを生成し、出力部１１４に供給する。
【０１７６】
出力部１１４は、例えば、出力インターフェース回路や、LCD等のディスプレイから構成される。出力部１１４は、CDM分析部１１３からの視聴履歴レポートを、外部の装置に出力する。また、出力部１１４がディスプレイから構成される場合には、当該ディスプレイに、視聴履歴レポートを表示させるようにしてもよい。
【０１７７】
URサーバ１０１は、以上のように構成される。
【０１７８】
（SLTメタデータの構造例）
図１５は、XML形式のSLTメタデータのフォーマットの例を示す図である。なお、図１５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０１７９】
ただし、SLTメタデータのフォーマットについては、下記の非特許文献２の「Table 6.2 SLT XML Format」にその詳細な内容が記載されている。そのため、図１５のフォーマットの例では、SLTメタデータのうち、特に本技術に関係する部分を抜粋して記載している。
【０１８０】
非特許文献２：ATSC Candidate Standard : Signaling, Delivery, Synchronization,and Error Protection(A/331) Doc. S33-174r15 January 2016
【０１８１】
SLT要素は、ルート要素であって、sltInetUrl要素を含んでいる。sltInetUrl要素には、ブロードキャストストリームIDで識別される周波数帯域（例えば6MHz）ごとに、urlType属性の属性値で指定されるURLタイプに応じたURLを指定することができる。
【０１８２】
ここで、図１６には、urlType属性の属性値の例を示している。
【０１８３】
urlType属性として、"1"が指定された場合、sltInetUrl要素に、SLSを提供するシグナリングサーバのURLが指定されることを表している。また、urlType属性として、"2"が指定された場合、sltInetUrl要素に、電子番組表（ESG：Electronic Service）を提供するESGサーバのURLが指定されることを表している。
【０１８４】
また、urlType属性として、"3"が指定された場合には、sltInetUrl要素に、URサーバ１０１のURLが指定されることを表している。すなわち、図５に示した伝送システムの構成を採用した場合、Usage Reportingとして、コンテンツの視聴履歴に関する運用が行われるので、SLTメタデータのsltInetUrl要素には、URサーバ１０１のURLが記載され、urlType属性として、"3"が指定される。
【０１８５】
図１５の説明に戻り、SLT要素は、１又は複数のService要素を含んでいる。Service要素には、サービス単位で、各サービスに関する情報が指定される。このService要素は、svcInetUrl要素を含んでいる。svcInetUrl要素には、サービスIDで識別されるサービスごとに、urlType属性の属性値で指定されるURLタイプに応じたURLを指定することができる。
【０１８６】
ここで、svcInetUrl要素のurlType属性の属性値についても、図１６に示した属性値が指定される。すなわち、urlType属性として、"3"が指定された場合には、svcInetUrl要素に、URサーバ１０１のURLが指定されることになる。
【０１８７】
このように、URサーバ１０１のURLを、ブロードキャストストリームIDで識別される周波数帯域ごとに指定する場合には、SLT要素の配下のsltInetUrl要素に記載すればよい。また、URサーバ１０１のURLを、サービスIDで識別されるサービスごとに指定する場合には、Service要素の配下のsvcInetUrl要素に記載すればよい。
【０１８８】
なお、図１５において、useの項目は、出現数を表している。例えば、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。また、例えば、"1"が指定された場合には、その要素又は属性は必ず１つだけ指定され、"1..N"が指定された場合には、その要素又は属性は１以上指定される。
【０１８９】
また、図１５において、Data Typeの項目は、データ形式を表している。例えば、"anyURI"が指定された場合には、そのデータは、URIの形式をした文字列であることを表している。また、例えば、"unsignedByte"が指定された場合には、0から255までの整数であることを表している。
【０１９０】
＜５．視聴履歴情報対応処理の流れ＞
【０１９１】
次に、図１７及び図１８のフローチャートを参照して、図５の伝送システムにより実行される視聴履歴情報対応処理の流れを説明する。
【０１９２】
なお、図１７及び図１８において、ステップＳ１０１の処理は、送信システム１０により実行される。また、ステップＳ２０１乃至Ｓ２０６とＳ２２１乃至Ｓ２２５の処理は、対応クライアント装置２０により実行される。また、ステップＳ３０１乃至Ｓ３０２の処理は、非対応クライアント装置３０により実行される。
【０１９３】
図１７のステップＳ３０１において、非対応クライアント装置３０の制御部３００は、通信I/F３０１を制御し、LAN７０を介して、コンテンツのDASHセグメントファイルを、対応クライアント装置２０に要求する。ここでは、例えば、ユーザ操作により、送信システム１０から配信されるテレビ番組等のコンテンツの再生が指示された場合に、非対応クライアント装置３０からのHTTPリクエストが格納されたIPパケットが、対応クライアント装置２０に通知される。
【０１９４】
対応クライアント装置２０においては、非対応クライアント装置３０からのHTTPリクエストが格納されたIPパケットが、通信I/F２０４−２により受信され、HTTPプロキシサーバ２０２のHTTPリクエストハンドラ２２５に供給される。
【０１９５】
ステップＳ２０１において、HTTPリクエストハンドラ２２５は、HTTPリクエストが格納されたIPパケットの送信元アドレス（ソースアドレス）をチェックする。
【０１９６】
ステップＳ２０２において、HTTPリクエストハンドラ２２５は、ステップＳ２０１の送信元アドレスのチェック結果に従い、当該送信元アドレスが、ローカルDASHクライアントからのものであるかどうかを判定する。ここでは、DASHクライアント３１１が搭載された非対応クライアント装置３０に割り当てられたIPアドレスが、送信元アドレスとなるので、当該送信元アドレスが、ローカルDASHクライアントからのものであると判定され（Ｓ２０２の「YES」）、処理は、ステップＳ２０３に進められる。
【０１９７】
なお、ステップＳ２０２の判定処理で、送信元アドレスが、ローカルDASHクライアントからのものではないと判定された場合には、必要な処理が行われた後に、処理は終了される。
【０１９８】
ステップＳ２０３において、HTTPリクエストハンドラ２２５は、ステップＳ２０２の処理で判定対象となった送信元アドレスを、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からの送信元アドレスが、URクライアント２２４により受信される。
【０１９９】
ステップＳ２２１において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のDeviceInfo.non3.0DeviceAttributes）に対し、HTTPリクエストハンドラ２２５からの送信元アドレスに応じたIPアドレスを記録する。
【０２００】
また、ステップＳ２０４において、HTTPリクエストハンドラ２２５は、ステップＳ２０２の処理で判定対象となった送信元アドレスのIPパケットに格納されたHTTPリクエストヘッダから、ユーザエージェント（UserAgent）の文字列を抽出し、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からのユーザエージェントの情報が、URクライアント２２４により受信される。
【０２０１】
ステップＳ２２２において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のDeviceInfo.non3.0DeviceAttributes）に対し、HTTPリクエストハンドラ２２５からのユーザエージェントの情報を記録する。このユーザエージェントの情報としては、例えば、オペレーティングシステム（OS）に関する情報やモバイル端末であるかどうかを示す情報が含まれている。
【０２０２】
なお、送信元アドレス（IPアドレス）やユーザエージェントの情報は、同一の内容となる場合には、必ずしも繰り返し取得する必要はなく、取得済みのものを再利用することができる。
【０２０３】
図１８のステップＳ２０５において、HTTPリクエストハンドラ２２５は、送信システム１０から配信されるテレビ番組等のコンテンツのデータであって、放送ミドルウェア２０１の処理で得られるDASHセグメントファイルを、LAN７０を介して、非対応クライアント装置３０に転送する。
【０２０４】
ステップＳ３０２において、非対応クライアント装置３０のDASHクライアント３１１は、対応クライアント装置２０（のHTTPプロキシサーバ２０２のHTTPリクエストハンドラ２２５）から転送されてくるDASHセグメントファイルを再生する。これにより、非対応クライアント装置３０では、送信システム１０から配信されるテレビ番組等のコンテンツが再生され、ユーザにより視聴されることになる。
【０２０５】
ステップＳ２０６において、HTTPリクエストハンドラ２２５は、ステップＳ２０５の処理で非対応クライアント装置３０に転送されたDASHセグメントファイルに対応したセグメントURLを、URクライアント２２４に通知する。これにより、HTTPプロキシサーバ２０２においては、HTTPリクエストハンドラ２２５からのセグメントURLが、URクライアント２２４により受信される。
【０２０６】
ステップＳ２２３において、URクライアント２２４は、非対応クライアント装置３０ごとに管理されているCDM（のAVService）に対し、HTTPリクエストハンドラ２２５からのセグメントURLに対応する情報を記録する。
【０２０７】
ここでは、例えば、MPDメタデータを参照することにより、セグメントURLに対応するコンテンツID（ContentID）を取得できるので、当該コンテンツIDを、CDMのAVService.reportInterval.contentIDに記録することができる。また、ここでは、図６に示したCDMの構造に含まれる情報であれば、コンテンツID以外の情報を記録することもできる。例えば、必要に応じて処理された時間を、CDMのAVService.reportInterval.startTime（endTime）に記録することができる。
【０２０８】
ステップＳ２２４において、制御部２００は、CDMを送信するタイミングであるかどうかを判定する。この判定条件としては、例えば、あらかじめ定められた間隔で定期的に送信するための条件のほか、送信システム１０から対応クライアント装置２０に送信されるシグナリングや、ビデオやオーディオのウォータマークメッセージに含まれるコメントなどに応じた条件などが用いられる。
【０２０９】
ステップＳ２２４において、CDMを送信するタイミングではないと判定された場合、処理は、ステップＳ２２１に戻り、それ以降の処理が繰り返される。すなわち、この場合には、非対応クライアント装置３０からの要求に応じてDASHセグメントファイルが転送されるとともに、その再生履歴（視聴履歴）が記録され続ける。
【０２１０】
一方で、ステップＳ２２４において、CDMを送信するタイミングであると判定された場合、処理は、ステップＳ２２５に進められる。ステップＳ２２５において、URクライアント２２４は、ステップＳ２２１乃至Ｓ２２３の処理で得られるJSON形式にエンコードされたCDMを、視聴履歴情報として、インターネット６０を介してURサーバ１０１に送信する。
【０２１１】
なお、ここでは、通信I/F２０４−１が、SLTメタデータから得られるURサーバ１０１のURLに従い、インターネット６０を介してURサーバ１０１にアクセスすることで、URクライアント２２４からの視聴履歴情報（CDM）が、URサーバ１０１に送信される。
【０２１２】
これにより、URサーバ１０１においては、対応クライアント装置２０からの視聴履歴情報（CDM）が、通信I/F１１１により受信される。なお、URサーバ１０１においては、複数の対応クライアント装置２０から視聴履歴情報が受信され、複数の視聴履歴情報が収集される。
【０２１３】
ステップＳ１０１において、URサーバ１０１のCDM分析部１１３は、収集された視聴履歴情報（CDM）を分析し、視聴履歴に関する視聴履歴レポートを生成する。
【０２１４】
ここで、視聴履歴情報（CDM）には、コンテンツを再生したクライアント装置が、ATSC3.0に準拠したデータを処理可能な機器であるかどうかを示す機器情報（non3.0DeviceAttributes）が含まれている。そのため、CDM分析部１１３は、対象の視聴履歴情報（CDM）が、対応クライアント装置２０（ATSC3.0対応機器）と、非対応クライアント装置３０（ATSC3.0非対応機器）のいずれのレポートであるのかを識別して、視聴履歴レポートを生成することができる。
【０２１５】
以上、視聴履歴情報対応処理の流れを説明した。
【０２１６】
＜６．変形例＞
【０２１７】
（ATSC3.0対応機器のCDMの記載例）
上述した説明では、非対応クライアント装置３０が、対応クライアント装置２０を介して、ATSC3.0のプロトコルで伝送されたコンテンツにアクセスする形態において、非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴を識別するために、CDMのDeviceInfoの属性値に、non3.0DeviceAttributesを追加して、非対応クライアント装置３０に固有な情報が指定されるようにしている。
【０２１８】
ここでは、対応クライアント装置２０（ATSC3.0対応機器）の視聴履歴を識別するために、CDMのDeviceInfoのnon3.0DeviceAttributesに対し、対応クライアント装置２０に固有な情報が指定されるようにしてもよい。この場合には、対応クライアント装置２０に固有な情報として、HTTPリクエストのユーザエージェントに含まれる情報を含めることができる。
【０２１９】
図１９には、ATSC3.0対応機器に固有な情報として、ユーザエージェントに関する情報を含めた場合のCDMの記載例を示している。図１９においては、non3.0DeviceAttributesの属性値として、"schemeIdUri"と"value"の組が指定されている。
【０２２０】
ここでは、"schemeIdUri"に対し、HTTPリクエストのユーザエージェントのヘッダの内容であることを識別するURIとして、"urn:browserUserAgent"である値が定義され、ユーザエージェントのヘッダに格納されている文字列（情報）が、"value"の値として記載されている。この"value"の値としては、例えば、オペレーティングシステム（OS）に関する情報や、モバイル端末であるかどうかを示す情報などが記載される。
【０２２１】
また、対応クライアント装置２０（ATSC3.0対応機器）において、HTTPプロキシサーバ２０２に対する、ブラウザ２０３のDASHクライアント２３１からのHTTPリクエストには、対応クライアント装置２０に割り当てられたIPアドレスは含まれていない。そのため、対応クライアント装置２０（ATSC3.0対応機器）の視聴履歴情報（CDM）に、IPアドレスを含めないようにすることで、IPアドレスを含めることが可能な非対応クライアント装置３０（ATSC3.0非対応機器）の視聴履歴情報（CDM）（例えば、図８のCDMの記載例）と区別することが可能となる。
【０２２２】
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式である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）等の有線放送などの規格に適用することができる。
【０２２４】
（その他の変形例）
また、上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。例えば、CDMにおいて、ATSC3.0に準拠したデータを処理可能な機器であるかを示す属性として、「non3.0DeviceAttributes」を定義したが、他の名称を用いるようにしてもよい。また、例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、LCC(Locally Cached Content)は、NRT(Non Real Time)などと称される場合がある。
【０２２５】
＜７．コンピュータの構成＞
【０２２６】
上述した一連の処理（図１７及び図１８の視聴履歴情報対応処理）は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２０は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０２２７】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０２２８】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０２２９】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０２３０】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０２３１】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０２３２】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０２３３】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０２３４】
また、本技術は、以下のような構成をとることができる。
【０２３５】
（１）
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成する視聴履歴処理部を備える
情報処理装置。
（２）
前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
（１）に記載の情報処理装置。
（３）
前記固有な情報は、HTTP(Hypertext Transfer Protocol)リクエストのユーザエージェントに含まれる情報である
（２）に記載の情報処理装置。
（４）
前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IP(Internet Protocol)アドレスをさらに含む
（３）に記載の情報処理装置。
（５）
前記ユーザエージェントは、オペレーティングシステム（OS：Operating System）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
（３）又は（４）に記載の情報処理装置。
（６）
前記デジタル放送の放送波を受信する受信部と、
前記放送波から得られる、前記デジタル放送の規格に準拠したデータを処理するデータ処理部と、
前記非対応機器から送信されてくるHTTPリクエストに応じて、ネットワークを介して、前記データ処理部からの前記データを、前記非対応機器に送信する通信部と
をさらに備え、
前記視聴履歴処理部は、前記非対応機器で再生された前記コンテンツの視聴履歴に対し、前記非対応機器からのHTTPリクエストから得られるユーザエージェントに含まれる情報と、前記非対応機器に割り当てられたIPアドレスを関連付けた前記視聴履歴情報を生成する
（４）に記載の情報処理装置。
（７）
前記視聴履歴処理部は、HTTPプロキシサーバのモジュールとして実装される
（３）乃至（６）のいずれかに記載の情報処理装置。
（８）
前記対応機器又は前記非対応機器において、前記コンテンツは、ブラウザ上で再生される
（２）乃至（６）のいずれかに記載の情報処理装置。
（９）
前記通信部は、前記視聴履歴情報を、ネットワークを介して、前記視聴履歴情報を収集する視聴履歴サーバに送信する
（６）に記載の情報処理装置。
（１０）
前記データ処理部からの前記データを再生する再生部をさらに備える
（６）乃至（９）のいずれかに記載の情報処理装置。
（１１）
情報処理装置の情報処理方法において、
前記情報処理装置が、
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を生成するステップを含む
情報処理方法。
（１２）
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信する受信部と、
複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する処理部と
を備える情報処理装置。
（１３）
前記視聴履歴情報は、前記機器情報として、前記デジタル放送の規格に対応した対応機器、又は前記デジタル放送の規格に対応していない非対応機器に固有な情報を含む
（１２）に記載の情報処理装置。
（１４）
前記固有な情報は、HTTPリクエストのユーザエージェントに含まれる情報である
（１３）に記載の情報処理装置。
（１５）
前記固有な情報は、前記HTTPリクエストが、前記非対応機器からのものである場合、IPアドレスをさらに含む
（１４）に記載の情報処理装置。
（１６）
前記ユーザエージェントは、オペレーティングシステム（OS）に関する情報と、モバイル端末であるかどうかを示す情報を少なくとも含んでいる
（１３）又は（１４）に記載の情報処理装置。
（１７）
情報処理装置の情報処理方法において、
前記情報処理装置が、
デジタル放送のコンテンツの視聴履歴に関する視聴履歴情報であって、前記コンテンツを再生した機器が、前記デジタル放送の規格に準拠したデータを処理可能な機器であるかどうかを示す機器情報を含む前記視聴履歴情報を受信し、
複数の機器からの前記視聴履歴情報を収集し、収集された複数の前記視聴履歴情報を、前記機器情報に応じて処理する
ステップを含む情報処理方法。
【符号の説明】
【０２３６】
１０  送信システム，  ２０  対応クライアント装置，  ３０  非対応クライアント装置，  ５０  中継局，  ６０  インターネット，  ７０  LAN，  ２００  制御部，  ２０１  放送ミドルウェア，  ２０２  HTTPプロキシサーバ，  ２０３  ブラウザ，  ２０４−１，２０４−２  通信I/F，  ２１１  PHY・MAC処理部，  ２１２  LLSレトリーバ，  ２１３  LLSパーサ，  ２１４  SLSレトリーバ，  ２１５  SLSパーサ，  ２１６  セグメントレトリーバ，  ２２１  プロキシキャッシュ，  ２２２  プロキシキャッシュ，  ２２３  放送・通信アドレスリゾルバ，  ２３１  DASHクライアント，  ２３２  デコーダ，  ２３３  レンダラ，  ２４１  MPDレトリーバ，  ２４２  MPDパーサ，  ２４３  セグメントレトリーバ，  ２４４  MP4パーサ，  ３００  制御部，  ３０１  通信I/F，  ３０２  ブラウザ，  ３１１  DASHクライアント，  ３１２  デコーダ，  ３１３  レンダラ，  ３２１  MPDレトリーバ，  ３２２  MPDパーサ，  ３２３  セグメントレトリーバ，  ３２４  MP4パーサ，  １０００  コンピュータ，  １００１  CPU
【図１】
2018012315.tif 000003
【図２】
2018012315.tif 000004
【図３】
2018012315.tif 000005
【図４】
2018012315.tif 000006
【図５】
2018012315.tif 000007
【図６】
2018012315.tif 000008
【図７】
2018012315.tif 000009
【図８】
2018012315.tif 000010
【図９】
2018012315.tif 000011
【図１０】
2018012315.tif 000012
【図１１】
2018012315.tif 000013
【図１２】
2018012315.tif 000014
【図１３】
2018012315.tif 000015
【図１４】
2018012315.tif 000016
【図１５】
2018012315.tif 000017
【図１６】
2018012315.tif 000018
【図１７】
2018012315.tif 000019
【図１８】
2018012315.tif 000020
【図１９】
2018012315.tif 000021
【図２０】
2018012315.tif 000022
【国際調査報告】
2018012315.tif 000023
2018012315.tif 000024