(57)【要約】  本技術は、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする情報処理装置、クライアント装置、及び、データ処理方法に関する。情報処理装置が、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入することで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようになる。本技術は、例えば、家庭内LAN等のネットワークに接続されるゲートウェイ装置や、コンテンツを再生可能なクライアント装置に適用することができる。
2018034172.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
情報処理装置。
【請求項２】
前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
請求項１に記載の情報処理装置。
【請求項３】
前記識別情報は、前記コンテンツの配信元を識別するための情報である
請求項２に記載の情報処理装置。
【請求項４】
前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
請求項３に記載の情報処理装置。
【請求項５】
前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも１つの情報をさらに含む
請求項４に記載の情報処理装置。
【請求項６】
前記処理部は、プロキシとしての機能を有する
請求項２に記載の情報処理装置。
【請求項７】
放送波を受信する受信部と、
インターネット上のサーバと通信を行う通信部と
をさらに備え、
前記処理部は、
前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
請求項６に記載の情報処理装置。
【請求項８】
前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
請求項７に記載の情報処理装置。
【請求項９】
前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
請求項７に記載の情報処理装置。
【請求項１０】
前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
請求項８に記載の情報処理装置。
【請求項１１】
前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
請求項１０に記載の情報処理装置。
【請求項１２】
前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
請求項１１に記載の情報処理装置。
【請求項１３】
前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
前記プロキシは、透過型のプロキシ（Transparent Proxy）である
請求項６に記載の情報処理装置。
【請求項１４】
情報処理装置のデータ処理方法において、
前記情報処理装置が、
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
データ処理方法。
【請求項１５】
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
を備え、
前記ゲートウェイ装置は、プロキシとしての機能を有し、
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
クライアント装置。
【請求項１６】
前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
請求項１５に記載のクライアント装置。
【請求項１７】
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
請求項１６に記載のクライアント装置。
【請求項１８】
前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
請求項１７に記載のクライアント装置。
【請求項１９】
前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
請求項１８に記載のクライアント装置。
【請求項２０】
クライアント装置のデータ処理方法において、
前記クライアント装置が、
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置、クライアント装置、及び、データ処理方法に関し、特に、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにした情報処理装置、クライアント装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
近年、放送サービスを高度化する目的で、放送だけでなく、通信を利用したサービスに関する技術が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2013-150089号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、放送と通信を利用したサービスの運用を行うに際して、インターネット上の通信サーバに対し、放送サービスをサービスエントリとしてアクセスしてくるデバイスと、一般のインターネットサイトをサービスエントリとしてアクセスするデバイスとが存在する場合が想定される。【０００５】
そのような場合において、放送事業者等の事業者からは、それらのデバイスを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。【０００６】
本技術はこのような状況に鑑みてなされたものであり、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにするものである。
【課題を解決するための手段】
【０００７】
本技術の第１の側面の情報処理装置は、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える情報処理装置である。【０００８】
本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の情報処理装置に対応するデータ処理方法である。【０００９】
本技術の第１の側面の情報処理装置、及び、データ処理方法においては、コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報が挿入される。【００１０】
本技術の第２の側面のクライアント装置は、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部とを備え、前記ゲートウェイ装置は、プロキシとしての機能を有し、前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立するクライアント装置である。【００１１】
本技術の第２の側面のクライアント装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面のクライアント装置に対応するデータ処理方法である。【００１２】
本技術の第２の側面のクライアント装置、及び、データ処理方法においては、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続が処理され、前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツが再生される。また、前記ゲートウェイ装置が、プロキシとしての機能を有しており、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続が確立される。
【発明の効果】
【００１３】
本技術の第１の側面、及び、第２の側面によれば、より柔軟に、放送と通信を利用したサービスの運用を行うことができる。【００１４】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】ゲートウェイ装置の構成例を示す図である。
【図３】クライアント装置の構成例を示す図である。
【図４】受信側の装置の実装例を説明する図である。
【図５】受信側の装置の実装例を説明する図である。
【図６】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図７】MPDメタデータの詳細を説明する図である。
【図８】MPDメタデータの詳細を説明する図である。
【図９】セグメントベースを利用する場合のMPDメタデータの例を示す図である。
【図１０】セグメントリストを利用する場合のMPDメタデータの例を示す図である。
【図１１】セグメントテンプレートを利用する場合のMPDメタデータの例を示す図である。
【図１２】MPDメタデータの例を示す図である。
【図１３】本技術の拡張ヘッダの例を示す図である。
【図１４】拡張ヘッダとして挿入される識別情報の例を示す図である。
【図１５】HTTPリクエストの例を示す図である。
【図１６】拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
【図１７】プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明するフローチャートである。
【図１８】プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明するフローチャートである。
【図１９】M-SEARCHリクエストの例を示す図である。
【図２０】M-SEARCHレスポンスの例を示す図である。
【図２１】デバイスディスクリプションリクエストの例を示す図である。
【図２２】デバイスディスクリプションレスポンスの例を示す図である。
【図２３】デバイスディスクリプションの例を示す図である。
【図２４】プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。
【図２５】プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。
【図２６】プロキシ自動構成スクリプトファイルの例を示す図である。
【図２７】拡張ヘッダ挿入処理の詳細を説明するフローチャートである。
【図２８】通信サーバ側のHTTPリクエスト対応処理の流れを説明するフローチャートである。
【図２９】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１７】
１．システムの構成
２．本技術の概要
３．HTTPリクエストヘッダの拡張方法
４．トランスペアレントプロキシの発見・接続方法
５．プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ
６．変形例
７．コンピュータの構成
【００１８】
＜１．システムの構成＞
【００１９】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００２０】
図１において、伝送システム１は、ゲートウェイ装置１０、クライアント装置２０−１乃至２０−Ｎ（Ｎ：１以上の整数）、放送サーバ４０、及び通信サーバ７０を含んで構成される。
【００２１】
伝送システム１において、ゲートウェイ装置１０と、クライアント装置２０−１乃至２０−Ｎは、エンドユーザ宅２に構築された家庭内LAN(Local Area Network)等のネットワーク３０を介して、相互に接続され、通信を行うことが可能である。
【００２２】
また、ゲートウェイ装置１０は、送信所５０から、放送伝送路６０を介して送信される放送波を受信する機能とともに、インターネット８０に接続可能な通信機能も有している。これにより、ゲートウェイ装置１０は、インターネット８０を介して、通信サーバ７０と相互に接続され、通信を行うことが可能である。
【００２３】
ゲートウェイ装置１０は、例えば、ゲートウェイ機能を提供するための専用のサーバや、通信機能を有するテレビ受像機やセットトップボックス（STB：Set Top Box）、ネットワークストレージなどから構成される。
【００２４】
ゲートウェイ装置１０は、送信所５０を介して、放送サーバ４０から送信されてくる放送波を受信し、放送波から得られるコンテンツのデータを、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｎに送信（転送）する。
【００２５】
また、ゲートウェイ装置１０は、インターネット８０を介して、通信サーバ７０から送信されてくるコンテンツのデータを受信し、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｎに送信（転送）する。
【００２６】
なお、ゲートウェイ装置１０の詳細な構成は、図２を参照して後述する。
【００２７】
クライアント装置２０−１は、ネットワーク３０を介してゲートウェイ装置１０から送信（転送）されてくるコンテンツを受信して再生する受信機である。すなわち、クライアント装置２０−１は、エンドユーザの操作などに応じて、ゲートウェイ装置１０を介して、放送経由又は通信経由で配信されるコンテンツを再生することができる。
【００２８】
クライアント装置２０−１は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。
【００２９】
クライアント装置２０−２乃至２０−Ｎは、クライアント装置２０−１と同様に、家庭内で使用される固定受信機又はモバイル受信機から構成され、ゲートウェイ装置１０を介して、放送経由又は通信経由で配信されるコンテンツを受信して再生する。
【００３０】
なお、以下の説明では、クライアント装置２０−１乃至２０−Ｎを、特に区別する必要がない場合、単に、クライアント装置２０と称するものとする。また、クライアント装置２０の詳細な構成は、図３を参照して後述する。
【００３１】
放送サーバ４０は、例えば、放送局などの放送事業者により提供されるサーバであって、送信所５０に設置される送出設備と、専用線などの所定の回線を介して接続される。
【００３２】
放送サーバ４０は、番組やCM等のコンテンツのファイル（データ）や制御情報（シグナリング）を処理し、その結果得られるデータを、専用線を介して送信所５０内の送出設備に送信する。そして、送信所５０内の送出設備は、放送サーバ４０からのデータに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送波が、放送伝送路６０を介して、エンドユーザ宅２内のゲートウェイ装置１０により受信される。
【００３３】
通信サーバ７０は、例えば、放送局などの放送事業者やその他の事業者により提供されるサーバであって、インターネット８０に接続される。
【００３４】
通信サーバ７０は、ゲートウェイ装置１０からのリクエストに応じて、番組やCM等のコンテンツのファイルや制御情報を処理し、その結果得られるデータを、インターネット８０を介して送信（ストリーミング配信）する。
【００３５】
なお、図１の伝送システムでは、ゲートウェイ装置１０とクライアント装置２０が、エンドユーザ宅２内に配置される場合を説明したが、ゲートウェイ装置１０は、エンドユーザ宅２内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。
【００３６】
すなわち、例えば、ゲートウェイ装置１０が、ケーブルオペレータのヘッドエンドに設置される場合、クライアント装置２０は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。また、例えば、ゲートウェイ装置１０が、モバイル網の基地局に設置される場合、クライアント装置２０は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイスとなる。
【００３７】
また、クライアント装置２０は、車両に搭載される車載機器であってもよい。さらに、図１の伝送システム１において、ネットワーク３０又はインターネット８０に接続されるデバイスやサーバの間で行われる通信は、無線通信及び有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。
【００３８】
（ゲートウェイ装置の構成）
図２は、図１のゲートウェイ装置１０の構成例を示す図である。
【００３９】
図２において、ゲートウェイ装置１０は、処理部１００、チューナ１０１、通信I/F１０２、通信I/F１０３、及び記憶部１０４から構成される。
【００４０】
処理部１００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１００は、各種の演算処理や、各部の動作制御などの処理を行う。
【００４１】
チューナ１０１は、アンテナを介して受信された放送波に対し、必要な処理（復調処理等）を施し、その結果得られる多重化ストリームを、処理部１００に供給する。処理部１００は、チューナ１０１から供給される多重化ストリームを処理し、その結果得られるデータを、通信I/F１０３に供給する。
【００４２】
通信I/F１０２は、処理部１００からの制御に従い、インターネット８０に接続された通信サーバ７０に、コンテンツの配信を要求する。通信I/F１０２は、通信サーバ７０から配信されるコンテンツのストリームを、インターネット８０を介して受信し、処理部１００に供給する。処理部１００は、通信I/F１０２から供給されるコンテンツのストリームを処理し、その結果得られるデータを、通信I/F１０３に供給する。
【００４３】
通信I/F１０３は、ネットワーク３０に接続されたクライアント装置２０から送信されてくるデータを受信し、処理部１００に供給する。また、通信I/F１０３は、処理部１００から供給されるデータを、ネットワーク３０を介して、クライアント装置２０に送信する。
【００４４】
なお、通信I/F１０２と通信I/F１０３は、例えば、通信インターフェース回路等から構成される。また、図２のゲートウェイ装置１０においては、説明の都合上、通信I/F１０２と通信I/F１０３を、別のブロックとして説明したが、通信I/F１０２と通信I/F１０３を共通化して、１つの通信I/Fとしてもよい。
【００４５】
記憶部１０４は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部１０４は、処理部１００からの制御に従い、各種のデータを記憶する。
【００４６】
処理部１００は、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４を含む。
【００４７】
UPnP/SSDPサーバ１１１と、プロキシアプリマネージャ１１２は、ゲートウェイ装置１０で稼働するサービスであって、ネットワーク３０に接続されるクライアント装置２０と、ローカルプロキシ１１３との接続を確立するための処理を行う。
【００４８】
なお、UPnP/SSDPサーバ１１１とプロキシアプリマネージャ１１２で行われる処理の詳細は、図１７及び図１８を参照して後述する。また、UPnP/SSDPサーバ１１１は、ウェブサーバ（ローカルウェブサーバ）の機能を有するようにすることができる。
【００４９】
ローカルプロキシ１１３は、ゲートウェイ装置１０で稼働するサービスであって、ネットワーク３０に接続されたクライアント装置２０からのリクエストを、インターネット８０に接続された通信サーバ７０に送信する。また、ローカルプロキシ１１３は、通信サーバ７０からのコンテンツのストリームを、インターネット８０を介して受信し、ネットワーク３０に接続されたクライアント装置２０に送信（転送）する。
【００５０】
なお、ローカルプロキシ１１３は、クライアント装置２０からのリクエストに対し、拡張ヘッダ挿入処理を行うが、その処理の詳細は、図１７、図１８、及び図２７などを参照して後述する。
【００５１】
SLS処理系１１４は、放送経由又は通信経由で取得される制御情報であるSLS(Service Layer Signaling)に関する処理を行う。なお、SLSの詳細は、図６を参照して後述する。また、SLS処理系１１４で行われる処理の詳細は、図２７を参照して後述する。
【００５２】
ゲートウェイ装置１０は、以上のように構成される。
【００５３】
（クライアント装置の構成）
図３は、図１のクライアント装置２０の構成例を示す図である。
【００５４】
図３において、クライアント装置２０は、処理部２００、通信I/F２０１、表示部２０２、及びスピーカ２０３から構成される。
【００５５】
処理部２００は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２００は、各種の演算処理や、各部の動作制御などの処理を行う。
【００５６】
通信I/F２０１は、例えば、通信インターフェース回路等から構成される。
【００５７】
通信I/F２０１は、処理部２００からの制御に従い、ネットワーク３０に接続されたゲートウェイ装置１０に対し、コンテンツの配信を要求する。また、通信I/F２０１は、ネットワーク３０を介して、ゲートウェイ装置１０から送信（転送）されてくるコンテンツのデータを受信し、処理部２００に供給する。
【００５８】
処理部２００は、通信I/F２０１から供給されるコンテンツのデータを処理し、その結果得られるデータのうち、ビデオデータを、表示部２０２に供給し、オーディオデータを、スピーカ２０３に供給する。
【００５９】
表示部２０２は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部２０２は、処理部２００から供給されるビデオデータに対応する映像を表示する。スピーカ２０３は、処理部２００から供給されるオーディオデータに対応する音声を出力する。
【００６０】
なお、表示部２０２が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部２００に供給され、処理部２００は、当該操作信号に応じた処理を行う。また、図３には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部２００に供給されるようにしてもよい。
【００６１】
処理部２００は、アプリケーション２１１及びブラウザ２１２を含む。アプリケーション２１１及びブラウザ２１２により、レンダラ機能が提供される。
【００６２】
アプリケーション２１１は、ネットワーク３０に接続されるクライアント装置２０が、ゲートウェイ装置１０で稼働するローカルプロキシ１１３との接続を確立するための処理を行う。なお、アプリケーション２１１で行われる処理の詳細は、図１７及び図１８を参照して後述する。
【００６３】
ブラウザ２１２は、通信I/F２０１から供給されるコンテンツのデータであって、ゲートウェイ装置１０により放送経由又は通信経由で受信されたデータを処理し、コンテンツを再生する。
【００６４】
なお、ブラウザ２１２は、DASHプレーヤとしての機能を有するが、その詳細は、図６を参照して後述する。また、ブラウザ２１２で行われる処理の詳細は、図１７、図１８、及び図２７などを参照して後述する。
【００６５】
クライアント装置２０は、以上のように構成される。
【００６６】
（受信側の装置の実装例）
ところで、図１の伝送システム１においては、ゲートウェイ装置１０が、放送経由又は通信経由で、送信側のサーバから配信されるデータを、受信側のクライアント装置２０に転送するための役割を担う構成を説明したが、その役割を、ネットワーク３０に接続されたクライアント装置２０のいずれかが担うようにした構成を採用することもできる。
【００６７】
ここでは、例えば、エンドユーザ宅２において、ネットワーク３０に接続された複数のクライアント装置２０のうち、クライアント装置２０−１が、チューナ及び通信I/Fなどのゲートウェイ装置１０と同様の機能を有し、放送経由及び通信経由で配信されるコンテンツのデータを受信可能な場合を想定する。
【００６８】
この場合において、クライアント装置２０−２乃至２０−Ｎは、ゲートウェイとして動作するクライアント装置２０−１を介して、放送経由又は通信経由で配信されるコンテンツのデータを受信することができる。ただし、この場合でも、クライアント装置２０−２乃至２０−Ｎは、ゲートウェイ装置１０に接続して、放送経由又は通信経由で配信されるコンテンツのデータを受信するようにしてもよい。
【００６９】
これらの関係をまとめると、図４に示すようになる。すなわち、図４において、ゲートウェイ装置１０は、図２の構成に示したように、チューナ１０１とともに、処理部１００として、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４を含んで構成される。
【００７０】
また、図４において、クライアント装置２０には、レンダラ機能のみを有する一般クライアント装置２０と、レンダラ機能だけでなく、ゲートウェイ機能をも有するオールインワン型（All in One）のクライアント装置２０との２種類がある。
【００７１】
なお、以下の説明では、適宜、オールインワンクライアント装置２０を、「AOC(All in One Client)」とも記述し、一般クライアント装置２０を、「NC(Normal Client)」とも記述する。また、ゲートウェイ装置１０は、「GW(Gateway)」とも記述する。
【００７２】
一般クライアント装置（NC）２０は、図３の構成に示したように、アプリケーション２１１及びブラウザ２１２によるレンダラ機能を含んで構成される。一方で、オールインワンクライアント装置（AOC）２０は、レンダラ機能のほかに、ゲートウェイ装置（GW）１０と同様に、チューナ１０１、UPnP/SSDPサーバ１１１、プロキシアプリマネージャ１１２、ローカルプロキシ１１３、及びSLS処理系１１４によるゲートウェイ機能を含んで構成される。
【００７３】
すなわち、一般クライアント装置（NC）２０は、ゲートウェイ機能を有するゲートウェイ装置（GW）１０、又はオールインワンクライアント装置（AOC）２０を介して、送信側のサーバとデータをやりとりするが、オールインワンクライアント装置（AOC）２０は、自身がゲートウェイ機能を有するため、単独で、送信側のサーバとデータをやりとりすることができる。
【００７４】
より具体的には、図５に示すような関係として表すことができる。
【００７５】
図５において、一般クライアント装置（NC）２０は、ゲートウェイ装置（GW）１０又はオールインワンクライアント装置（AOC）２０を介して、放送経由又は通信経由のデータを受信する。すなわち、ゲートウェイ装置（GW）１０は、一般クライアント装置（NC）２０に対し、ゲートウェイ機能を提供することができる。また、オールインワンクライアント装置（AOC）２０は、一般クライアント装置（NC）２０に対し、ゲートウェイ機能を提供することができる。
【００７６】
また、オールインワンクライアント装置（AOC）２０は、ゲートウェイ装置（GW）１０からゲートウェイ機能の提供を受けて、一般クライアント装置（NC）２０として機能することもできるが、通常は、自身のゲートウェイ機能を使って、放送経由又は通信経由のデータを受信する。
【００７７】
ゲートウェイ装置（GW）１０は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、一般クライアント装置（NC）２０又はオールインワンクライアント装置（AOC）２０に送信する。また、ゲートウェイ装置（GW）１０は、一般クライアント装置（NC）２０又はオールインワンクライアント装置（AOC）２０からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
【００７８】
オールインワンクライアント装置（AOC）２０は、ゲートウェイとして機能し、送信側のサーバから放送経由又は通信経由で配信されるデータを、自身で処理するか、又は一般クライアント装置（NC）２０に送信する。また、オールインワンクライアント装置（AOC）２０は、自身で処理したリクエスト、又は一般クライアント装置（NC）２０からのリクエストに対し、拡張ヘッダ挿入処理を施し、その結果得られるリクエストを、通信経由で送信する。
【００７９】
なお、受信側のクライアント装置２０に対し、送信側のサーバからのデータを中継するゲートウェイ機能を有する装置としては、放送経由と通信経由のデータを、同一の装置で処理してもよいし、放送経由のデータを処理する装置と、通信経由のデータを処理する装置とが異なるようにしてもよい。例えば、一般クライアント装置（NC）２０に対する、放送経由のデータを、ゲートウェイ装置（GW）１０が処理し、通信経由のデータを、オールインワンクライアント装置（AOC）２０が処理することができる。
【００８０】
（本技術のプロトコルスタック）
図６は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００８１】
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
【００８２】
例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等と同様に、IP伝送方式を採用することができる。
【００８３】
図６において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
【００８４】
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
【００８５】
ここで、ATSC3.0では、制御情報（シグナリング）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの２階層で伝送される。
【００８６】
LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
【００８７】
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００８８】
このROUTEセッションにより、サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
【００８９】
ここで、SLSは、サービスレベルの制御情報であり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。
【００９０】
USBDメタデータは、他のメタデータの取得先などの情報を含む。なお、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に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。なお、MPDメタデータの詳細は、図７乃至図１１、及び図１４などを参照して後述する。
【００９３】
ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００９４】
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００９５】
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
【００９６】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
【００９７】
このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
【００９８】
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、NRTコンテンツ以外のファイル（例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイル）がROUTEセッションで伝送されるようにしてもよい。
【００９９】
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
【０１００】
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
【０１０１】
すなわち、これらの階層によって、図１のインターネット８０等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
【０１０２】
HTTP層に隣接する上位階層のうち、一部の階層は、制御情報（Signaling）と、NRTコンテンツ（NRT）とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
【０１０３】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【０１０４】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
【０１０５】
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、クライアント装置２０、放送サーバ４０や通信サーバ７０では、実装の負担や処理の負担を軽減することができる。
【０１０６】
（MPDメタデータの詳細）
次に、図７乃至図１１を参照して、SLSとして伝送されるMPDメタデータの詳細を説明する。
【０１０７】
MPDメタデータには、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。
【０１０８】
例えば、図７に示すように、ルート要素となるMPD要素の下には、時間の区切りを示すPeriod要素があり、さらに、Period要素の下に、ビデオやオーディオ、字幕などのそれぞれのストリーム（エレメンタリストリーム）ごとに、AdaptationSet要素を配置して、それぞれのストリームの属性を記述する。
【０１０９】
また、AdaptationSet要素の下に、同一のストリーム（エレメンタリストリーム）から派生する、レート等の属性の異なる複数のストリームごとに、Representation要素に分けて、それぞれのレート等の属性を記述する。なお、Representation要素は、時間軸上で、複数のセグメント（Segment）に分割される。
【０１１０】
クライアント装置２０では、SLSとして伝送されるMPDメタデータをパースし、Representation要素に記述されたストリームに指定されるレートの値を参考にして、クライアント装置２０のおかれているネットワーク環境に応じた最適なストリームを選択できるようになっている。
【０１１１】
図８には、MPDメタデータにおける、Period要素と、AdaptationSet要素と、Representation要素との関係を詳細に示している。
【０１１２】
なお、Representation要素の下には、Representation要素がさらに複数のストリームから構成される場合に、各々のストリームの属性を記述するために、SubRepresentation要素を配置することができる。
【０１１３】
ここで、MPDメタデータに記述されるセグメントファイルは、URL（バイトレンジ）により特定される。セグメントは、Representation要素の一部であって、１つのRepresentation要素は、以下のいずれかにより構成される。
【０１１４】
（１）１つかそれ以上のセグメントリスト
（２）１つのセグメントテンプレート
（３）１つかそれ以上のベースURLと最大１つのセグメントベース（この場合にはセグメントリストも、セグメントテンプレートもない）
【０１１５】
以下、上記の（１）乃至（３）に対応するMPDメタデータの記述例を示す。
【０１１６】
図９は、セグメントベース（SegmentBase）を利用する場合のMPDメタデータの例を示す図である。
【０１１７】
図９に示すように、セグメントベースは、１つのRepresentation要素に、１つのメディアセグメント（セグメント）しかない場合に利用される。図９において、初期化情報のバイト列とRAP(Random Access Points)のバイト列が、ファイルの最初の834バイト以内に収まっている。なお、この834バイトは、SegmentBase要素のindexRange属性により記述される。
【０１１８】
図１０は、セグメントリスト（SegmentList）を利用する場合のMPDメタデータの例を示す図である。
【０１１９】
図１０に示すように、セグメントリストは、１つのRepresentation要素に、複数のセグメントURLが配置される場合に利用される。図１０のRepresentation要素において、SegmentList要素には、再生順に配置される複数のSegmentURL要素が列記される。
【０１２０】
SegmentURL要素は、DASHセグメントファイルのURL（そのファイル内のバイトレンジ）により表現される。なお、SegmentList要素の最初に配置されるInitilization要素には、初期化情報を格納したファイル（InitSegment）を指示している。
【０１２１】
図１１は、セグメントテンプレート（SegmentTemplate）を利用する場合のMPDメタデータの例を示す図である。
【０１２２】
図１１に示すように、セグメントテンプレートは、セグメントURLを自動生成するときに利用する。このユースケースの典型的な例としては、ライブストリーミングがある。すなわち、セグメントテンプレートにおいては、SegmentTemplate要素に記述されるセグメントURLのひな形の中の特別なパラメタを動的に置き換えていくことにより、完全なセグメントURLのリストを生成する。
【０１２３】
具体的には、SegmentTemplate要素のmedia属性の属性値として記述されるURLのうち、"$Number$"の部分が、置換パラメタ（ReplacementParameter）に相当し、当該パラメタを、startNumber属性の値から開始して、順次インクリメントしながら書き換えることで、セグメントURLが生成される。なお、このセグメントテンプレートを利用することで、MPDメタデータのサイズを非常に小さくすることが可能となる。
【０１２４】
＜２．本技術の概要＞
【０１２５】
ところで、伝送システム１においては、コンテンツの配信側（放送事業者）により管理されるサーバ（例えば通信サーバ７０）で、あるコンテンツに対するクライアント装置２０からのHTTPリクエストの履歴により、アクセス統計（視聴率）を管理するような運用が想定される。なお、ここでのコンテンツのデータは、DASHセグメントファイルのシーケンスのような、１つのコンテンツから生成されるチャンク化されたファイルシーケンス、又はフラグメントシーケンスにより伝送される。
【０１２６】
このような運用を行う場合に、チャンク化された各々のDASHセグメントに対するHTTPリクエストを記録するとき、各々のリクエスト間の相関がわかりにくいと、同一のコンテンツに対するリクエストのシーケンスであるかどうかを判断することが難しい。
【０１２７】
一方で、HTTPリクエストのリクエストヘッダ（以下、HTTPリクエストヘッダという）に記述されるリクエストURLの内容を解析して、同じパターンを特定することにより、HTTPリクエストのシーケンスを関連付ける（まとめる）ことは可能ではある。
【０１２８】
しかしながら、それらのURLの内容の相関がわかりやすい場合には、この方法を適用することができるが、同一のコンテンツのデータから生成されたDASHセグメントファイルであっても、MPDメタデータに記述されるAdaptationSet要素や、Representation要素の構成方法によっては、そこに含まれるセグメントURL（segmentUrl）が、それぞれ、全く相関のない内容になる可能性がある。
【０１２９】
そのような構成を記述したMPDメタデータの例を、図１２に示している。図１２のMPDメタデータにおいては、Period要素と、AdaptationSet要素と、Representation要素とが階層構造をなしているが、Representation要素には、セグメントリストとして、複数のセグメントURLが記述されている。
【０１３０】
このセグメントURLは、BaseURL要素の値として指定されるベースURLと、SegmentURL要素のmedia属性の値として指定されるファイルのURLとを結合することで、完全なURLが得られる。
【０１３１】
すなわち、図１２のMPDメタデータにおいては、同一のコンテンツから生成される２つのRepresentation要素の系列が記述され、一方の系列が、"http://cdn1.com/seg-201.mp4"，"http://cdn1.com/seg-202.mp4"，・・・となり、他方の系列が、"http://cdn2.com/s101.mp4"，"http://cdn2.com/s102.mp4"，・・・となる。
【０１３２】
なお、この例では、CDN(Content Delivery Network)サービスを利用して、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用が行われる場合を示している。
【０１３３】
ここで、"http://cdn1.com/seg-201.mp4"と"http://cdn2.com/s101.mp4"との関係などからは、図１２の２つのRepresentation要素に記述された系列ごとのDASHセグメントのシーケンスが、同一のコンテンツから生成されたDASHセグメントのシーケンスであることを類推することは、容易ではない。
【０１３４】
また、仮に、リクエストURLの内容に相関がある場合でも、HTTPリクエストを受けた通信サーバ７０では、以前に処理したURLのシーケンスを、常に保持しておいて、後続のHTTPリクエストのリクエストURLとの比較を行い、その内容に相関があれば、それらを同一のコンテンツから生成されるDASHセグメントであると類推して記憶するといった処理が必要となる。
【０１３５】
なお、ここで、リクエストURLの内容に相関がある場合とは、例えば、"http://cdn1.com/seg-201.mp4"，"http://cdn1.com/seg-202.mp4"，・・・のように、時系列順に並び、ある部分が規則性のある整数としてエンコードされる場合などである。
【０１３６】
しかしながら、このような運用を行う場合、通信サーバ７０側で、過去のリクエストURLの履歴（状態情報）を保持する負担が大きくなり、かつ、リクエストURLの比較や、同一の出元となるコンテンツ（コンテンツのソースの同一性）の可能性の類推などの余計な処理負荷を増加させるため、スケーラビリティを損ねることになる。したがって、通信サーバ７０側で、リクエストURLのみに頼るコンテンツの同一性の類推を行い、その結果を用いてアクセス統計の記録を行うことは、現実的ではない。
【０１３７】
その一方で、例えば、現在策定中のATSC3.0においては、サービスを提供する放送事業者等は、ATSC3.0の放送サービス（以下、ATSC3.0サービスともいう）で配信されるDASHセグメントへのアクセス統計を、次のように行いたいという要請がある。
【０１３８】
すなわち、ATSC3.0サービス（放送サービス）を、サービスエントリとしてアクセスしてくるエンドユーザデバイス（以下、ATSC3.0エンドデバイスともいう）と、そうではない一般のインターネットのサイトを、サービスエントリとしてアクセスしてくるエンドユーザデバイス（以下、一般エンドデバイスともいう）とを区別し、かつ、既存のCDNのロギングの機能を利用して、DASHセグメントへのアクセス統計を記録したいという要請がある。
【０１３９】
なお、ここでのATSC3.0エンドデバイスには、一般クライアント装置（NC）２０と、オールインワンクライアント装置（AOC）２０が共に該当する可能性がある。また、一般エンドデバイスについても、一般クライアント装置（NC）２０と、オールインワンクライアント装置（AOC）２０が共に該当する可能性がある。
【０１４０】
また、通信サーバ７０が、CDNのサーバとして提供されるようにすることで、通信サーバ７０によって、コンテンツのデータ（DASHセグメントファイル）の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。ここでは、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。
【０１４１】
以上のように、放送事業者等の事業者からは、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用などを行いたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。
【０１４２】
そこで、本技術では、放送と通信を利用したサービスの運用を行う場合において、ATSC3.0サービス（放送サービス）を導線（サービスエントリ）として、通信経由でアクセスしてくるATSC3.0エンドデバイス（クライアント装置２０）を識別可能にすることで、より柔軟に、放送と通信を利用したサービスの運用を行うことができるようにする。
【０１４３】
すなわち、本技術では、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合に、HTTPリクエストヘッダに対し、当該DASHセグメントの元となるコンテンツのソースの同一性を識別するための識別情報（以下、ソース識別情報という）が挿入されるようにする。
【０１４４】
例えば、同一のコンテンツであっても、例えば、レート等の属性や、放送経由又は通信経由等の配信経路が異なる場合があり、そのような場合でも、コンテンツのソースが同一である場合には、同一のソース識別情報（ソース同一性を識別する識別子）が付加されるようにすることで、ソースの同一性を識別することができる。
【０１４５】
これにより、通信サーバ７０側では、HTTPリクエストヘッダに含まれるソース識別情報を記憶しておくだけで、異なるサービスの配信に起因する、DASHセグメントに対するHTTPリクエストのリクエストURLの間の相関性を、HTTPリクエストごとに処理する必要がなくなり、通信サーバ７０側の処理負荷を大幅に低減することができる。
【０１４６】
ただし、HTTPリクエストに対し、このような特殊なヘッダを追加する処理は、一般のDASHクライアント（DASHプレーヤ）の実装に、容易に加えることはできない。
【０１４７】
そこで、本技術では、ATSC3.0サービス（放送サービス）で配信されるDASHセグメントに対するHTTPリクエストについては、それらのHTTPリクエストをすべて、ATSC3.0のプロキシサーバ（ゲートウェイ装置１０で稼働するローカルプロキシ１１３）を経由させるようにする。これにより、ローカルプロキシ１１３上のモジュールやサーバサイドスクリプトなどによって、HTTPリクエストヘッダに対し、拡張ヘッダ（ソース識別情報）を、容易に挿入することができるようになる。
【０１４８】
また、このローカルプロキシ１１３は、TLS(Transport Layer Security)等のセキュアなエンドトゥーエンドトランザクションをも透過的に処理可能な透過型のプロキシ（以下、トランスペアレントプロキシ(Transparent Proxy)という）として構成されるようにする。これにより、TLS等のエンドトゥーエンドのセキュアなトランスポートセッションで保護された（隠ぺいされた）DASHセグメントのリクエスト/レスポンストランザクションについても同様に、拡張ヘッダ挿入処理を行うことが可能となる。
【０１４９】
なお、トランスペアレントプロキシに関する技術としては、既に各種の技術が提案されており、ここでは、それらの公知の技術を用いることができる。
【０１５０】
＜３．HTTPリクエストヘッダの拡張方法＞
【０１５１】
（拡張ヘッダの例）
図１３は、本技術の拡張ヘッダの例を示す図である。
【０１５２】
図１３には、HTTPリクエストヘッダの拡張の一例として、ATSC3.0サービスの場合の拡張ヘッダの記述例を示している。
【０１５３】
図１３において、HTTPリクエストヘッダの汎用ヘッダに拡張する拡張ヘッダ名は、例えば、"ATSC3.0-Requset"とされる。ここで、汎用ヘッダは、リクエストやレスポンスのエンティティボディではなく、接続に対して適用されるヘッダを意味する。なお、拡張ヘッダ名を、プライベートヘッダとして定義する場合には、"X-ATSC3.0-Requset"とすることができる。
【０１５４】
拡張ヘッダの値としては、コンテンツのソースの同一性を識別するためのソース識別情報が配置される。このソース識別情報には、サービスID（service-id）、コンテンツID（contentId）、MPDメタデータのURL（mpd-uri）、及び時刻情報（broadcastTime）等のATSC3.0サービスの配信関連の主な属性を含めることができる。
【０１５５】
サービスIDは、ATSC3.0で規定されるサービスを識別するためのID（グローバルサービスID）である。このサービスIDは、必須の値とされる。
【０１５６】
なお、ATSC3.0規定のサービスID（globalServiceId）の詳細は、下記の非特許文献１の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されている。すなわち、サービスIDとしては、USBDメタデータのuserServiceDescription要素のglobalServiceID属性の値を用いることができる。
【０１５７】
非特許文献１：ATSC Candidate Standard：Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016
【０１５８】
MPDメタデータのURLは、USBDメタデータにより参照されるMPDメタデータの絶対パスを表したURI(Uniform Resource Locator)である。このURLは、オプショナルな値とされる。
【０１５９】
なお、上記の非特許文献１の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されているように、MPDメタデータのURLとしては、USBDメタデータのuserServiceDescription要素のfullMPDUri属性の値を用いることができる。
【０１６０】
時刻情報は、コンテンツが実際に放送された時刻を表している。ただし、放送時刻の内容の選択は、実装依存とされる。つまり、例えば、放送時刻が、コンテンツの配信スケジュールの開始時刻であるのか、あるいは配信スケジュールの開始から終了までの任意の時刻（HTTPリクエストのパケットが到着した時刻）であるのかは、運用に応じて設定される。この時刻情報は、オプショナルな値とされる。
【０１６１】
コンテンツIDは、コンテンツを識別するIDである。このコンテンツIDとしては、例えば、"EIDR"又は"Ad-ID"を指定することができる。ここで、"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad-ID"は、Advertising IDの略であり、広告用のIDである。このコンテンツIDは、オプショナルな値とされる。
【０１６２】
ここで、図１４には、HTTPリクエストに対し、拡張ヘッダとして挿入されるソース識別情報の例を示している。
【０１６３】
すなわち、図１４においては、XML形式のUSBDメタデータとMPDメタデータの記述例を示しているが、これらのメタデータから得られる情報を、ATSC3.0サービスの配信関連の属性として、ソース識別情報に含めることができる。
【０１６４】
例えば、USBDメタデータにおいては、userServiceDescription要素のglobalServiceID属性の値から、サービスID（グローバルサービスID）が得られ、userServiceDescription要素のfullMPDUri属性の値から、MPDメタデータのURLが得られる。また、例えば、MPDメタデータにおいては、Period要素のAssetIdentifier要素の値から、EIDRに対応したコンテンツIDが得られる。
【０１６５】
なお、詳細は、後述するが、拡張ヘッダ挿入処理に先立って、ソース識別情報を格納したマッピングデータベースをあらかじめ生成しておくことで、拡張ヘッダ挿入処理では、マッピングデータベースを参照することにより、HTTPリクエストに挿入すべき、ソース識別情報を取得することが可能となる。
【０１６６】
また、USBDメタデータのDeliveryMethod要素に記述されるURLと、MPDメタデータのRepresentation要素に記述されるURL（セグメントURL）とのマッチングを行うことで、コンテンツのデータ（ストリーム）の配信経路が、放送経由であるのか、あるいは通信経由であるのかを特定することができる。なお、MPDメタデータにおけるセグメントURLの記述と導出については、図７乃至図１１を参照して先に述べた通りである。
【０１６７】
次に、図１５及び図１６を参照して、HTTPリクエストヘッダの具体的な例を示す。ここでは、まず、図１５を参照して、拡張ヘッダ挿入前のHTTPリクエストヘッダを説明してから、図１６を参照して、拡張ヘッダ挿入後のHTTPリクエストヘッダを説明する。
【０１６８】
（HTTPリクエスト）
図１５は、HTTPリクエストの例を示す図である。
【０１６９】
図１５においては、セグメントURLが、"http://a.com/a.mp4"の場合に、このDASHセグメントファイルを取得するためのHTTPリクエストの例を示している。
【０１７０】
このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。HTTPリクエストでは、HOSTにより、ホスト名（サーバ名）が指定され、GETメソッドにより、リソースが指定される。なお、"HTTP/1.1"は、HTTPのバージョンを表している。
【０１７１】
なお、HTTPリクエストでは、１行目がHTTPリクエスト行となり、２行目以降がHTTPヘッダ行、すなわち、HTTPリクエストヘッダとされる。また、GETメソッドを利用する場合、HTTPボディ部には、何も記述されることはない。
【０１７２】
（拡張ヘッダ挿入後のHTTPリクエスト）
図１６は、拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
【０１７３】
図１６においては、図１５のHTTPリクエスト（HTTPリクエストヘッダ）に対し、拡張ヘッダとして、"atsc3.0-requset"である拡張ヘッダ名の行が追加されている。
【０１７４】
すなわち、この拡張ヘッダとして追加されるDASHセグメントファイルのコンテンツの属性は、セグメントURLを主キーとして、マッピングデータベースを参照することで得られるソース識別情報からなる。具体的には、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報等のソース識別情報が、拡張ヘッダとして追加されている。
【０１７５】
例えば、図１６のHTTPリクエストの拡張ヘッダでは、USBDメタデータのglobalServiceID属性の値である"urn:atsc:serviceId:NBCU-NFL-1"が、サービスID（service-id）として指定され、USBDメタデータのfullMPDUri属性の値である"http://a.com/a.mpd"が、MPDメタデータのURL（mpd-uri）として指定されている。
【０１７６】
また、図１６のHTTPリクエストの拡張ヘッダでは、MPDメタデータのAssetIdentifier要素に記述されるEIDRである"md:cid:EIDR:10.5240%2f0EFB-02CD-126E-8092-1E49-W"が、コンテンツID（contentId）として指定されている。さらに、図１６のHTTPリクエストの拡張ヘッダでは、当該コンテンツの放送時刻である2016年7月4日(金)23:54:58(グリニッジ標準時)を表した"Fri, 04 Jul 2016 23:54:58 GMT"が、時刻情報（broadcastTime）として指定されている。
【０１７７】
以上のように、本技術では、HTTPリクエストに対し、拡張ヘッダとして、ソース識別情報を挿入することで、放送サービスをサービスエントリとして、通信経由で、DASHセグメントに対するHTTPリクエストが送信される場合でも、コンテンツのソースの同一性を識別することができるようにしている。
【０１７８】
なお、ここでは、デジタル放送の規格として、米国等で採用される方式であるATSC（特にATSC3.0）を一例に説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
【０１７９】
すなわち、ソース識別情報は、コンテンツのソースの同一性を識別可能な情報であって、放送サービス（例えば、ATSC3.0サービス等）を識別するための情報となるので、様々な放送方式に適用することができる。ただし、上述した説明では、ソース識別情報として、ATSC3.0サービスを前提に、サービスIDやコンテンツIDなどを例示列挙したが、それらに限らず、ISDBやDVB等の規格ごとに、より適した情報を用いることができる。
【０１８０】
また、デジタル放送の規格以外で規定された情報を、必要に応じて、ソース識別情報に加えることもできる。例えば、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)で規定された情報を追加することもできる。具体的には、例えば、ソース識別情報として、3GPP-MBMS(Multimedia Broadcast Multicast Services)で規定される要素や属性を加えることができる。
【０１８１】
＜４．トランスペアレントプロキシの発見・接続方法＞
【０１８２】
ところで、エンドユーザ宅２内のほか、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置される可能性のある、ゲートウェイ装置１０（のローカルプロキシ１１３）を発見・接続する方法としては、いくつかの方法が想定される。
【０１８３】
例えば、クライアント装置２０において、ブラウザ２１２のインターネット接続設定のメニューにて、手動でローカルプロキシ１１３のIPアドレスやポート番号などを入力する方法や、プロキシ設定スクリプトのURLを登録する方法、あるいは自動設定による方法などがある。
【０１８４】
自動設定の方法としては、例えば、DHCP(Dynamic Host Configuration Protocol)サーバを用いる方法や、WPAD(Web Proxy Auto Discovery)を用いる方法などがある。また、プロキシ設定スクリプトによる自動設定は、JavaScript（登録商標）等のスクリプト言語で記述されたプロキシ自動構成スクリプトファイルを用意して、そのファイルをウェブサーバ上に配置する一方で、そのファイルのURLを、ブラウザ２１２の自動設定のスクリプトのURLに設定すればよい。
【０１８５】
WPADを用いる場合には、ブラウザ２１２自身が、プロキシ設定用のスクリプトファイルの位置（URL）を自動的に検出してダウンロードすることで、設定を行うことができる。なお、WPADでは、一般には、DHCPサーバのDHCPINFORMメッセージを用いる方法と、DNS(Domain Name System)を用いた方法により、"wpad"という名前を持つエントリを探して、そこからプロキシ設定スクリプトをダウンロードする方法が実装されている。
【０１８６】
ゲートウェイ装置１０（のローカルプロキシ１１３）の発見においても、同様の方法を用いることができる。ローカルプロキシ１１３では、HTTPSプロトコルによるセキュアなエンドトゥーエンドのトランスポートセッションを含むすべてのセッションを、ローカルプロキシ１１３が、仲介（横取り）できるようにする。一般的に、このようなプロキシが、トランスペアレントプロキシ（透過プロキシ）と呼ばれるのは、先に述べた通りである。
【０１８７】
本技術では、クライアント装置２０が、ネットワーク３０において、ローカルプロキシ１１３が稼働しているサーバであるゲートウェイ装置１０を発見し、当該ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号（以下、プロキシ待ち受けアドレス/ポートともいう）を取得する方式を提案する。
【０１８８】
そのためには、クライアント装置２０では、ローカルプロキシ１１３に対し、プロキシ待ち受けアドレス/ポートを問い合わせるためのWeb API(Application Programming Interface)を認識する必要がある。つまり、このWeb APIは、サービスを呼び出すためのインターフェースであると言える。
【０１８９】
ここで、トランスペアレントプロキシであるローカルプロキシ１１３の発見に、ユニバーサルプラグアンドプレイ(UPnP：Universal Plug and Play)を利用する場合、ローカルプロキシ１１３の発見と、機能の公開には、SSDP(Simple Service Discovery Protocol)が用いられる。
【０１９０】
なお、UPnPは、デバイスを接続するだけで、対象のネットワークに参加することを可能にするプロトコルである。また、SSDPは、UPnPで用いられるプロコトルの１つで、ネットワーク上のデバイスの探索や応答を行うためのものである。
【０１９１】
一般に、SSDPにおいては、公開されるサービスを発見する際にやりとりされるデバイスディスクリプションとして、デバイスが提供可能な機能や情報が記述されたXML形式のファイルが用いられる。このファイルには、対象のデバイスそのものについて記述したデバイスディスクリプションと、対象のデバイス上に実装された各サービスが持つアクションとしてのサービスディスクリプションとが記述される。
【０１９２】
本技術では、ローカルプロキシ１１３のディスクリプション（例えばサービスディスクリプション）に、当該ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号（プロキシ待ち受けアドレス/ポート）を返答するWeb APIのURLを記述できるようにする。
【０１９３】
また、本技術では、ATSC3.0サービス等の放送サービスに対応するローカルプロキシ１１３のサービスを発見するためのプロトコルを追加することにより、放送サービスを実装していない一般クライアント装置（NC）２０で、ブラウザ２１２のプロキシとして、プロキシ待ち受けアドレス/ポートを設定できるようにする。
【０１９４】
すなわち、放送サービスを実装していない一般クライアント装置（NC）２０（スマートフォンやタブレット型コンピュータ等の一般エンドデバイス）のブラウザ２１２で、あるスクリプト（Web API）を立ち上げると、放送サービスに対応するサーバであるゲートウェイ装置１０を発見し、そこで稼働するローカルプロキシ１１３のプロキシ待ち受けアドレス/ポートを、当該ブラウザ２１２のプロキシとして設定できるようにする。
【０１９５】
以下、このような、ゲートウェイ装置１０で稼働するローカルプロキシ１１３の発見と、ローカルプロキシ１１３のプロキシ待ち受けアドレス/ポートの取得のシーケンス（プロキシの発見・接続処理）を、上述したHTTPリクエストヘッダの拡張のシーケンス（拡張ヘッダ挿入処理）とあわせて説明する。
【０１９６】
なお、ここでは、ネットワーク上のデバイスの探索や応答を行うプロトコルとして、SSDPを一例に説明したが、DIAL(Discovery and Launch)等の他のプロトコルを用いることでも、同様の機能を実現することができる。DIALは、ネットワーク上にあるDIAL対応のデバイスをUPnPにより発見し、指定されたアプリケーションを起動させるプロトコルである。
【０１９７】
＜５．プロキシの発見・接続処理と、拡張ヘッダ挿入処理の流れ＞
【０１９８】
（プロキシの発見・接続処理と、拡張ヘッダ挿入処理）
図１７及び図１８のフローチャートを参照して、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明する。
【０１９９】
ただし、図１７及び図１８の説明では、図１９乃至図２６に示したリクエストやレスポンス等のメッセージの内容を適宜参照しながら説明するものとする。
【０２００】
また、図１７及び図１８の説明では、ネットワーク３０に接続されるゲートウェイ装置１０には、IPアドレスとして、"192.168.1.1"が割り当てられているものとする。また、このゲートウェイ装置１０で稼働するサービスのうち、UPnP/SSDPサーバ１１１には、"12345"であるポート番号、プロキシアプリマネージャ１１２には、"23456"であるポート番号、ローカルプロキシ１１３には、"34567"であるポート番号がそれぞれ割り当てられているものとする。
【０２０１】
なお、図１７及び図１８において、ステップＳ１０１乃至Ｓ１０２の処理と、ステップＳ１１１の処理と、ステップＳ１２１乃至Ｓ１２３の処理は、ゲートウェイ装置１０により実行される。一方で、ステップＳ２０１乃至Ｓ２０４の処理と、ステップＳ２１１乃至Ｓ２１２の処理は、クライアント装置２０により実行される。
【０２０２】
図１７のステップＳ２０１において、アプリケーション２１１は、ゲートウェイ装置１０で稼働するローカルプロキシ１１３の存在を確認するために、通信I/F２０１を介して、ネットワーク３０に接続されたデバイス（サーバ）に対し、M-SEARCHリクエストを、マルチキャストで送信する。
【０２０３】
図１９は、M-SEARCHリクエストの例を示す図である。
【０２０４】
M-SEARCHリクエストには、マルチキャストのIPアドレスとして、"239.255.255.250"が指定され、ポート番号として、"1900"が指定される。
【０２０５】
また、上述したように、UPnPのプロトコルとして、SSDPを用いるので、MANには、"ssdp:discover"が指定される。さらに、探索の対象が、ATSC3.0に対応したプロキシであるローカルプロキシ１１３となるので、STには、"urn:atsc:proxy"が指定される。
【０２０６】
図１７に戻り、ステップＳ２０１の処理で、クライアント装置２０により送信されるM-SEARCHリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
【０２０７】
ステップＳ１０１において、UPnP/SSDPサーバ１１１は、クライアント装置２０から受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、M-SEARCHレスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
【０２０８】
図２０は、M-SEARCHレスポンスの例を示す図である。
【０２０９】
M-SEARCHレスポンスにおいて、LOCATIONには、デバイスディスクリプションURLとして、"http://192.168.1.1:12345/deviceDescription.xml"が指定される。このデバイスディスクリプションURLは、XML形式のファイルのURLであって、このファイルは、ゲートウェイ装置１０で稼働するローカルウェブサーバが処理する。
【０２１０】
すなわち、ゲートウェイ装置１０においては、UPnP/SSDPサーバ１１１がローカルウェブサーバとしての機能を有しているので、デバイスディスクリプションURLには、ゲートウェイ装置１０に割り当てられたIPアドレスである"192.168.1.1"と、ローカルウェブサーバとしてのUPnP/SSDPサーバ１１１に割り当てられたポート番号である"12345"が記述される。
【０２１１】
図１７に戻り、ステップＳ１０１の処理で、ゲートウェイ装置１０により送信されるM-SEARCHレスポンスは、M-SEARCHリクエストを送信したクライアント装置２０により受信される。
【０２１２】
ステップＳ２０２において、アプリケーション２１１は、ゲートウェイ装置１０から受信したM-SEARCHレスポンス（のデバイスディスクリプションURL）に基づいて、ネットワーク３０に接続されたゲートウェイ装置１０で稼働するUPnP/SSDPサーバ１１１に対し、デバイスディスクリプションを要求する。
【０２１３】
図２１は、デバイスディスクリプションリクエストの例を示す図である。
【０２１４】
デバイスディスクリプションリクエストには、GETメソッドの対象のリソースとして、"deviceDescripion.xml"であるデバイスディスクリプションが記述される。また、HOSTには、ホスト名として、"192.168.1.1:12345"が記述される。
【０２１５】
すなわち、デバイスディスクリプションリクエストでは、M-SEARCHレスポンスに記述された内容に応じて、GETメソッドの対象のリソースが、"deviceDescripion.xml"となる。さらに、デバイスディスクリプションリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置１０のIPアドレスと、"12345"であるUPnP/SSDPサーバ１１１（ローカルウェブサーバ）のポート番号とが記述される。
【０２１６】
図１７に戻り、ステップＳ２０２の処理で、クライアント装置２０により送信されるデバイスディスクリプションリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
【０２１７】
ステップＳ１０２において、UPnP/SSDPサーバ１１１（ローカルウェブサーバ）は、クライアント装置２０から受信したデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
【０２１８】
図２２及び図２３は、デバイスディスクリプションレスポンスの例を示す図である。
【０２１９】
デバイスディスクリプションレスポンスのヘッダには、図２２に示すように、ファイルのタイプ等が指定される。また、図２３には、XML形式のデバイスディスクリプションの内容が示されている。
【０２２０】
すなわち、図２３のデバイスディスクリプションには、root要素のxmlns属性として、"urn:schemas-upnp-org:device-1-0"が記述され、UPnP準拠のデバイスディスクリプションであることが宣言されている。
【０２２１】
serviceList要素には、ゲートウェイ装置１０でサポートされるサービスの一覧が記述される。serviceList要素には、１又は複数のservice要素が記述される。
【０２２２】
service要素には、サポートされるサービスのうち、１つのサービスについての情報が記述される。service要素は、serviceType要素、serviceId要素、SCPDURL要素、及びcontrolURL要素などの上位要素となる。
【０２２３】
serviceType要素には、サービスのタイプとして、"urn:atsc:proxy"が記述され、ATSC3.0サービスのプロキシサービスであることを意味している。
【０２２４】
serviceId要素には、サービスIDとして、"urn:UPnP:serviceId:1234"が記述され、プロキシサービスのサービスIDを表している。
【０２２５】
controlURL要素には、プロキシ待ち受けアドレス/ポート取得Web APIのURLとして、"http://192.168.1.1:23456/getATSC3.0ProxyAddressPort"が記述される。このURLは、ローカルプロキシ１１３がリクエストを待ち受けるIPアドレスとポート番号を示すプロキシ待ち受けアドレス/ポートを取得するためのWeb APIを呼び出すための情報である。
【０２２６】
ここで、通常、SCPDURL要素には、ACRクライアントサービスについてのサービスディスクリプションのアドレスが記述されるので、HTTPで規定されるGETメソッドにより、サービスディスクリプションが取得される。その場合には、UPnPで規定されるSOAP(Simple Object Access Protocol)により、controlURL要素に記述されるURLに対し、アクションのメッセージを送付することで、アクションを呼び出すことになる。
【０２２７】
一方で、本技術では、より簡便にWeb APIを呼び出せるように、UPnPの規定とは異なる方法で、Web APIのURLを周知する方法を提案する。すなわち、本技術では、図２３に示すように、SCPDURL要素の値としては何も記述せずに（SCPDURL要素の中身は空にしておき）、SCPDURL要素に何も記述されていない場合に限り、controlURL要素に、直接、Web APIのURLを記述できるようにしている。
【０２２８】
なお、controlURL要素に、直接、Web APIのURLを記述するための条件としては、上述したような、SCPDURL要素の中身を空にするほか、例えば、controlURL要素に、ダミーの文字列を記述するようにしてもよい。
【０２２９】
図１７に戻り、ステップＳ１０２の処理で、ゲートウェイ装置１０により送信されるデバイスディスクリプションレスポンスは、デバイスディスクリプションリクエストを送信したクライアント装置２０により受信される。
【０２３０】
ステップＳ２０３において、アプリケーション２１１は、ゲートウェイ装置１０から受信したデバイスディスクリプションレスポンス（のプロキシ待ち受けアドレス/ポート取得Web APIのURL）に基づいて、ネットワーク３０に接続されたゲートウェイ装置１０で稼働するプロキシアプリマネージャ１１２に対し、プロキシ待ち受けアドレス/ポートを要求する。
【０２３１】
図２４は、プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。
【０２３２】
プロキシ待ち受けアドレス/ポートリクエストには、GETメソッドの対象のリソースとして、"getATSC3.0ProxyAddressPort"である対象のプロキシ待ち受けアドレス/ポートが記述される。また、HOSTには、ホスト名として、"192.168.1.1:23456"が記述される。
【０２３３】
すなわち、プロキシ待ち受けアドレス/ポートリクエストでは、デバイスディスクリプションレスポンスに記述された内容（controlURL要素の内容）に応じて、GETメソッドの対象が、"getATSC3.0ProxyAddressPort"となる。さらに、プロキシ待ち受けアドレス/ポートリクエストには、HOSTとして、"192.168.1.1"であるゲートウェイ装置１０のIPアドレスと、"23456"であるプロキシアプリマネージャ１１２のポート番号が記述される。
【０２３４】
図１７に戻り、ステップＳ２０３の処理で、クライアント装置２０により送信されるプロキシ待ち受けアドレス/ポートリクエストは、ネットワーク３０に接続されたゲートウェイ装置１０により受信される。
【０２３５】
ステップＳ１１１において、プロキシアプリマネージャ１１２は、クライアント装置２０から受信したプロキシ待ち受けアドレス/ポートリクエストに応じて、プロキシ待ち受けアドレス/ポートを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。
【０２３６】
図２５は、プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。
【０２３７】
プロキシ待ち受けアドレス/ポートレスポンスのボディ部には、プロキシ待ち受けアドレス/ポートとして、"192.168.1.1:34567"が記述されている。
【０２３８】
すなわち、ゲートウェイ装置１０において、ローカルプロキシ１１３がプロキシサーバとしての機能を有しているので、当該レスポンスのボディ部には、ゲートウェイ装置１０に割り当てられたIPアドレスである"192.168.1.1"と、ローカルプロキシ１１３に割り当てられたポート番号である"34567"が記述される。
【０２３９】
なお、この例では、Web APIへのリクエスト（プロキシ待ち受けアドレス/ポートリクエスト）を受け取るのが、プロキシアプリマネージャ１１２であるとして説明しているが、ローカルプロキシ１１３本体が、当該リクエストを受け取って、処理するようにしてもよい。
【０２４０】
図１７に戻り、ステップＳ１１１の処理で、ゲートウェイ装置１０により送信されるプロキシ待ち受けアドレス/ポートレスポンスは、プロキシ待ち受けアドレス/ポートリクエストを送信したクライアント装置２０により受信される。
【０２４１】
図１８のステップＳ２０４において、アプリケーション２１１は、ゲートウェイ装置１０から受信したプロキシ待ち受けアドレス/ポートレスポンス（のIPアドレスとポート番号）に基づいて、プロキシ自動構成スクリプトの更新と、ブラウザ２１２の起動（再起動）による構成変更の反映を行う。
【０２４２】
すなわち、クライアント装置２０において、アプリケーション２１１は、プロキシ待ち受けアドレス/ポートレスポンスから、プロキシ待ち受けアドレス/ポートとして得られるIPアドレスとポート番号（ATSC3.0ProxyAddressPort(192.168.1.1:34567)）により、プロキシ自動構成スクリプトファイルを書き換える。
【０２４３】
図２６は、プロキシ自動構成スクリプトファイルの例を示す図である。
【０２４４】
プロキシ自動構成スクリプトファイルは、スクリプト言語として、JavaScript（登録商標）を用いて記述することができる。
【０２４５】
図２６においては、FindProxyForURL関数が定義され、その引数として、url，hostが指定可能である。FindProxyForURL関数においては、条件分岐のelse文に、"PROXY 192.168.1.1:34567; DIRECT"、すなわち、プロキシ待ち受けアドレス/ポートが記述されている。つまり、"192.168.1.1"は、ゲートウェイ装置１０に割り当てられたIPアドレスであり、"34567"は、ローカルプロキシ１１３に割り当てられたポート番号である。
【０２４６】
このFindProxyForURL関数によって、サブネット内の特定のホストは直接外部と接続し、それ以外のホストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３を介して、外部に接続することになる。ただし、ここでのホストには、クライアント装置２０が含まれる。
【０２４７】
すなわち、クライアント装置２０では、アプリケーション２１１により、プロキシ自動構成スクリプトファイルが、プロキシ待ち受けアドレス/ポートにより書き換えられ、ブラウザ２１２が、起動（再起動）される。そして、当該ブラウザ２１２が参照するプロキシ自動構成スクリプトファイルにより、プロキシのIPアドレスとポート番号の設定（自動設定）が行われる。
【０２４８】
これにより、クライアント装置２０において、ブラウザ２１２は、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３にアクセスすることが可能となる。
【０２４９】
ステップＳ２１１において、ブラウザ２１２は、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、DASHセグメントを、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３に要求する。
【０２５０】
すなわち、ブラウザ２１２は、コンテンツのDASHセグメントを再生するDASHプレーヤとしての機能を有しており、一般クライアント装置２０（NC）のブラウザ２１２（DASHプレーヤ）からのリクエスト（例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエスト）は、すべて、ローカルプロキシ１１３を経由することになる。
【０２５１】
ステップＳ２１１の処理で、クライアント装置２０により送信される、DASHセグメントのHTTPリクエストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３により受信される。
【０２５２】
ステップＳ１２１において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストに対し、拡張ヘッダを挿入する。
【０２５３】
すなわち、ローカルプロキシ１１３は、トランスペアレントプロキシとしての機能を有し、拡張ヘッダ挿入処理を行うことで、クライアント装置２０からのHTTPリクエストに対し、コンテンツのソースの同一性を識別するためのソース識別情報（ソース同一性を識別する識別子）を挿入する。この拡張ヘッダ処理で挿入されるソース識別情報として、例えば、ATSC3.0サービスの場合には、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などを含めることができるのは、先に述べた通りである。
【０２５４】
なお、ATSC3.0サービスに対応した拡張ヘッダ挿入処理においては、トラップしたDASHセグメントファイルのHTTPリクエストに対して、拡張ヘッダを挿入する前に、あらかじめ生成されたマッピングデータベースを参照することで、当該HTTPリクエスト（のURL）が、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認する処理が行われる。この処理の詳細は、図２７のフローチャートを参照して、後述する。
【０２５５】
ステップＳ１２２において、ローカルプロキシ１１３は、ステップＳ１２１の処理（拡張ヘッダ挿入処理）で得られるHTTPリクエストを、通信I/F１０２を介して、インターネット８０に接続された通信サーバ７０に送信する。
【０２５６】
なお、詳細は、図２８を参照して後述するが、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０から送信されてくるHTTPリクエストを受信する。また、通信サーバ７０は、受信したHTTPリクエストに基づいて、DASHセグメントファイルを、インターネット８０を介して、ゲートウェイ装置１０に送信する。
【０２５７】
ここで、通信サーバ７０は、ゲートウェイ装置１０から受信したHTTPリクエストヘッダに、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されているため、当該ソース識別情報を確認することで、HTTPリクエストが、ATSC3.0サービスを導線として要求されたリクエストであることを認識することができる。
【０２５８】
通信サーバ７０により送信されるDASHセグメントファイルは、インターネット８０に接続されたゲートウェイ装置１０により受信される。
【０２５９】
ステップＳ１２３において、ローカルプロキシ１１３は、通信サーバ７０から受信したDASHセグメントファイルを、通信I/F１０３を介して、ネットワーク３０に接続されたクライアント装置２０に転送する。
【０２６０】
ステップＳ１２３の処理で、ゲートウェイ装置１０により転送されるDASHセグメントファイルは、ネットワーク３０に接続されたクライアント装置２０により受信される。
【０２６１】
ステップＳ２１２において、ブラウザ２１２は、ゲートウェイ装置１０から受信したDASHセグメントファイルを処理し、DASHプレーヤによるDASHセグメントファイルの再生を行う。これにより、クライアント装置２０においては、通信経由で配信された番組等のコンテンツが再生されることになる。
【０２６２】
以上、プロキシの発見・接続処理と、拡張ヘッダ挿入処理の一連の流れを説明した。
【０２６３】
（拡張ヘッダ挿入処理の詳細）
次に、図２７のフローチャートを参照して、拡張ヘッダ挿入処理の詳細を説明する。
【０２６４】
図２７のフローチャートに示した処理は、図１７及び図１８のプロキシの発見・接続処理と、拡張ヘッダ挿入処理のうち、拡張ヘッダ挿入処理に相当する処理であって、図１８のステップＳ１２１乃至Ｓ１２３の処理と、ステップＳ２１１乃至Ｓ２１２の処理に対応している。
【０２６５】
なお、図２７において、ステップＳ１５１乃至Ｓ１５４の処理と、ステップＳ１６１乃至Ｓ１６４の処理は、ゲートウェイ装置１０により実行される。また、ステップＳ２５１乃至Ｓ２５２の処理は、クライアント装置２０により実行される。
【０２６６】
ゲートウェイ装置１０においては、クライアント装置２０からのHTTPリクエストに対する拡張ヘッダ挿入処理に先立って、ステップＳ１５１乃至Ｓ１５３の処理が実行され、SLS処理系１１４によって、マッピングデータベースが生成され、記憶部１０４に記憶される。
【０２６７】
具体的には、ステップＳ１５１において、SLS処理系１１４は、多重化ストリームから、ROUTEセッションで伝送されるSLSを抽出する。
【０２６８】
ステップＳ１５２において、SLS処理系１１４は、ステップＳ１５１の処理で得られたSLSをパースする。
【０２６９】
ここでは、USBDメタデータとMPDメタデータが解析され、USBDメタデータのglobalServiceID属性により記述されるサービスID及びfullMPDUri属性により指定されるURI（MPDメタデータのURL）、並びにMPDメタデータに記述されるコンテンツID（EIDRやAd-ID）及びセグメントURLが得られる。
【０２７０】
ステップＳ１５３において、SLS処理系１１４は、ステップＳ１５２の処理で得られた解析結果に基づいて、マッピングデータベースを生成する。このマッピングデータベースは、記憶部１０４に記憶される。
【０２７１】
このマッピングデータベースは、クライアント装置２０からのHTTPリクエストに含まれるURLが、ATSC3.0サービスのどのサービスのDASHセグメントに対応するものなのかを解決するためのデータベースとなる。
【０２７２】
具体的には、マッピングデータベースでは、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報が対応付けられている。すなわち、このマッピングデータベースは、セグメントURLと、ソース識別情報との対応関係を格納している。なお、主キーとしては、セグメントURLに限らず、例えば、MPDメタデータのBaseURL要素により指定されるベースURLなど、URLの最初のパートにマッチする文字列を用いるようにしてもよい。
【０２７３】
このマッピングデータベースによって、SLS処理系１１４は、クライアント装置２０からのHTTPリクエストのURLに応じた属性（ソース識別情報）を、ローカルプロキシ１１３に提供することができる。換言すれば、拡張ヘッダ挿入処理を行うに際し、このマッピングデータベースを参照することで、拡張ヘッダを挿入する前に、対象のHTTPリクエストのURLが、ATSC3.0サービスで配信されたMPDメタデータに記述されたセグメントURLであるかどうかを確認することができる。
【０２７４】
ここで、クライアント装置２０において、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングになった場合、ブラウザ２１２は、DASHセグメントを、ネットワーク３０を介して、ゲートウェイ装置１０で稼働するローカルプロキシ１１３に要求する（Ｓ２５１）。
【０２７５】
ステップＳ２５１の処理で、クライアント装置２０により送信されるDASHセグメントのHTTPリクエストは、ゲートウェイ装置１０で稼働するローカルプロキシ１１３により受信される。
【０２７６】
ステップＳ１６１において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストヘッダのURLによる照会を、SLS処理系１１４に要求する。
【０２７７】
ステップＳ１５４において、SLS処理系１１４は、ローカルプロキシ１１３からのHTTPリクエストヘッダのURLによる照会に応じて、記憶部１０４に記憶されたマッピングデータベースを参照し、当該HTTPリクエストのURLに対応する属性（ソース識別情報）を返答する。
【０２７８】
ここで、マッピングデータベースには、セグメントURLを主キーとして、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が格納されているので、クライアント装置２０からのHTTPリクエストのURLに対応するセグメントURLに対応付けられたソース識別情報が取得され、当該HTTPリクエストヘッダのURLに対応する属性として返答される。
【０２７９】
ステップＳ１６２において、ローカルプロキシ１１３は、クライアント装置２０から受信したHTTPリクエストヘッダに対し、拡張ヘッダとして、SLS処理系１１４から返答された属性（ソース識別情報）を挿入する。これにより、図１６に示したように、HTTPリクエストヘッダには、サービスID、コンテンツID、MPDメタデータのURL、及び時刻情報などのソース識別情報が挿入されることになる。
【０２８０】
ステップＳ１６３において、ローカルプロキシ１１３は、拡張ヘッダが挿入されたHTTPリクエストを、通信I/F１０２を介して、インターネット８０に接続された通信サーバ７０に送信する。
【０２８１】
なお、通信サーバ７０で行われる処理の詳細は、図２８を参照して後述するが、簡単に説明すると、次のようになる。すなわち、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０から送信されてくるHTTPリクエストを受信する。そして、通信サーバ７０は、受信したHTTPリクエストに応じたDASHセグメントファイルを、インターネット８０を介して、ゲートウェイ装置１０に送信する。
【０２８２】
通信サーバ７０により送信されるDASHセグメントファイルは、インターネット８０に接続されたゲートウェイ装置１０により受信される。
【０２８３】
ステップＳ１６４において、ローカルプロキシ１１３は、通信サーバ７０から受信したDASHセグメントファイルを、通信I/F１０３を介して、ネットワーク３０に接続されたクライアント装置２０に転送する。
【０２８４】
ステップＳ１６４の処理で、ゲートウェイ装置１０により転送されるDASHセグメントファイルは、ネットワーク３０に接続されたクライアント装置２０により受信される。
【０２８５】
クライアント装置２０では、ブラウザ２１２によって、ゲートウェイ装置１０から受信したDASHセグメントファイルが再生される（Ｓ２５２）。これにより、クライアント装置２０においては、通信経由で配信された番組等のコンテンツが再生されることになる。
【０２８６】
以上、拡張ヘッダ挿入処理の詳細を説明した。
【０２８７】
この拡張ヘッダ挿入処理では、ゲートウェイ装置１０で稼働するローカルプロキシ１１３によって、クライアント装置２０からのHTTPリクエストに、拡張ヘッダ（ソース識別情報）が挿入されるため、容易に、HTTPリクエストヘッダに対し、ソース識別情報を追加することができる。すなわち、このような特殊なヘッダを、HTTPリクエストに追加する処理は、一般のDASHプレーヤ（ブラウザ２１２）の実装に、容易に加えることはできないが、HTTPリクエストが、ローカルプロキシ１１３を経由するようにすることで、拡張ヘッダ挿入処理を、ローカルプロキシ１１３上のモジュールやサーバサイドスクリプトなどによって、容易に実装することができる。
【０２８８】
（HTTPリクエスト対応処理）
次に、図２８のフローチャートを参照して、通信サーバ７０により実行されるHTTPリクエスト対応処理の流れを説明する。
【０２８９】
図２８のフローチャートに示した処理は、図１７及び図１８のプロキシの発見・接続処理と、拡張ヘッダ挿入処理における、ステップＳ１２２の処理（ローカルプロキシ１１３のHTTPリクエスト転送処理）に対応する処理、あるいは、図２７の拡張ヘッダ挿入処理におけるステップＳ１６３の処理（ローカルプロキシ１１３のHTTPリクエスト転送処理）に対応する処理となる。
【０２９０】
ステップＳ３０１において、通信サーバ７０は、インターネット８０を介してゲートウェイ装置１０（のローカルプロキシ１１３）から送信されてくるHTTPリクエストを受信する。
【０２９１】
ステップＳ３０２において、通信サーバ７０は、ステップＳ３０１の処理で得られたHTTPリクエストを処理する。
【０２９２】
ここで、HTTPリクエストヘッダには、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などのソース識別情報が挿入されている。通信サーバ７０は、HTTPリクエストヘッダに挿入されたソース識別情報に基づいて、当該HTTPリクエストが、放送サービスを導線として要求されたリクエストであることを認識することができる。
【０２９３】
すなわち、ゲートウェイ装置１０からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されていない場合、通信サーバ７０においては、例えば、"http(s)://a.com/a.mp4"であるセグメントURLのDASHセグメントファイルのHTTPリクエストが、ATSC3.0サービス等の放送サービスを導線（サービスエントリ）としたものかどうかを認識することはできない。
【０２９４】
一方で、ゲートウェイ装置１０からのHTTPリクエストに、拡張ヘッダとしてのソース識別情報が挿入されている場合、通信サーバ７０は、サービスIDやコンテンツID、MPDメタデータのURL、時刻情報などから、当該HTTPリクエストが、ATSC3.0サービス等の放送サービスを導線（サービスエントリ）としたものかどうかを認識することが可能となる。
【０２９５】
例えば、放送と通信を利用したサイマル放送を行う場合や、放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う場合などの、放送と通信を利用したサービスの運用を行う場合に、クライアント装置２０では、放送サービスをサービスエントリとして、通信経由で、コンテンツの配信を受けるタイミングが生じるときがある。そして、このような場合において、放送事業者等の事業者から、放送サービスを導線（サービスエントリ）として、通信経由でアクセスしてくるクライアント装置２０を識別したいという要請があるが、その要請に応えることができる。例えば、放送事業者は、ATSC3.0エンドデバイスと一般エンドデバイスとを区別して、アクセスの統計を管理する運用を、容易に行うことができる。
【０２９６】
また、ここでは、通信サーバ７０が、CDNのサーバとして提供されるようにすることで、通信サーバ７０によって、コンテンツのデータ（DASHセグメントファイル）の配信が行われるときに、既存のCDNのロギングの機能を利用して、DASHセグメントのアクセス統計を記録するという運用が可能となる。さらに、通信サーバ７０が、既存のCDNの機能を利用することで、追加コストを最小限に抑えることができる。さらに、例えば、同一のコンテンツを、異なるCDNのサーバから、配信元のパスを変えて配信する運用を行う場合に、同一のコンテンツから生成されたDASHセグメントのシーケンスを、容易に類推することができる。
【０２９７】
なお、上記の「放送と通信でそれぞれ伝送されるストリームを結合して得られるコンテンツの配信を行う」運用とは、例えば、放送経由で、ベースレイヤとして、低品質なビデオストリームを配信するとともに、通信経由で、エンハンスメントレイヤとして、ベースレイヤとしてのビデオストリームを強化するための付加情報（エンハンスのビデオストリーム）を配信するような運用が相当する。これにより、クライアント装置２０では、ベースレイヤに対応した通常品質の映像（例えば２Ｋ解像度の映像）を再生するだけでなく、ベースレイヤとエンハンスメントレイヤを結合して得られる高品質の映像（例えば４Ｋ解像度の映像）を再生するが可能となる。
【０２９８】
ステップＳ３０３において、通信サーバ７０は、ステップＳ３０１の処理で得られたHTTPリクエストに応じたDASHセグメントファイルを、インターネット８０を介してゲートウェイ装置１０に送信する。
【０２９９】
以上、通信サーバ７０側のHTTPリクエスト対応処理の流れを説明した。
【０３００】
＜６．変形例＞
【０３０１】
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDBや、欧州の各国等が採用する方式であるDVBなどに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０３０２】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
【０３０３】
（その他の変形例）
また、上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。
【０３０４】
また、制御情報が、XML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
【０３０５】
また、DASHプレーヤは、例えば、HTML5(HyperText Markup Language 5)などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションとすることができる。また、このアプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム（OS：Operating System）環境などで実行されるようにしてもよい。
【０３０６】
なお、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
【０３０７】
＜７．コンピュータの構成＞
【０３０８】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３０９】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０３１０】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０３１１】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０３１２】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３１３】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０３１４】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３１５】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３１６】
また、本技術は、以下のような構成をとることができる。
【０３１７】
（１）
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する処理部を備える
情報処理装置。
（２）
前記処理部は、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
（１）に記載の情報処理装置。
（３）
前記識別情報は、前記コンテンツの配信元を識別するための情報である
（１）又は（２）に記載の情報処理装置。
（４）
前記識別情報は、前記放送サービスを識別する識別子を少なくとも含む
（３）に記載の情報処理装置。
（５）
前記識別情報は、前記コンテンツを識別する識別子、前記コンテンツの再生を制御する制御情報の取得先を示す情報、及び前記コンテンツに関する時刻情報のうち、少なくとも１つの情報をさらに含む
（４）に記載の情報処理装置。
（６）
前記処理部は、プロキシとしての機能を有する
（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
放送波を受信する受信部と、
インターネット上のサーバと通信を行う通信部と
をさらに備え、
前記処理部は、
前記放送波から得られる制御情報に基づいて、前記識別情報を格納したマッピングデータベースを生成し、
HTTP(Hypertext Transfer Protocol)リクエストを、前記サーバに送信する場合、前記マッピングデータベースから得られる前記識別情報を、前記HTTPリクエストのリクエストヘッダに挿入し、
前記通信部は、前記HTTPリクエストを、前記インターネットを介して、前記サーバに送信する
（６）に記載の情報処理装置。
（８）
前記情報処理装置は、ネットワークに接続されたクライアント装置に対し、放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
（７）に記載の情報処理装置。
（９）
前記情報処理装置は、放送経由又は通信経由で配信されるコンテンツを再生するクライアント装置であり、
前記処理部は、前記クライアント装置からのHTTPリクエスト、又はネットワークに接続された他のクライアント装置からのHTTPリクエストを、前記サーバに送信する場合、前記HTTPリクエストのリクエストヘッダに、前記識別情報を挿入する
（７）に記載の情報処理装置。
（１０）
前記処理部は、前記クライアント装置との接続を確立する場合に、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報を、前記クライアント装置に提供する
（８）に記載の情報処理装置。
（１１）
前記クライアント装置は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
（１０）に記載の情報処理装置。
（１２）
前記処理部は、前記クライアント装置により、前記接続情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記接続情報を、前記クライアント装置に提供する
（１１）に記載の情報処理装置。
（１３）
前記リクエストは、セキュアなプロトコルを用いて通信が行われ、
前記プロキシは、透過型のプロキシ（Transparent Proxy）である
（６）乃至（１２）のいずれかに記載の情報処理装置。
（１４）
情報処理装置のデータ処理方法において、
前記情報処理装置が、
コンテンツのリクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入するステップを含む
データ処理方法。
（１５）
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を処理する処理部と、
前記ゲートウェイ装置から、ネットワークを介して転送されてくる前記コンテンツを再生する再生部と
を備え、
前記ゲートウェイ装置は、プロキシとしての機能を有し、
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立する
クライアント装置。
（１６）
前記処理部は、前記プロキシの構成を設定するためのスクリプトファイルの内容を、前記接続情報により書き換え、当該スクリプトファイルを実行することで、前記プロキシとの接続を確立する
（１５）に記載のクライアント装置。
（１７）
前記処理部は、前記ゲートウェイ装置から前記ネットワークを介して提供される、前記接続情報を取得するためのAPIを実行することで、前記接続情報を取得する
（１６）に記載のクライアント装置。
（１８）
前記プロキシは、前記クライアント装置からのコンテンツのリクエストを、インターネット上のサーバに送信する場合、前記リクエストに対し、当該コンテンツのソースの同一性を識別するための識別情報を挿入する
（１７）に記載のクライアント装置。
（１９）
前記プロキシは、放送サービスをサービスエントリとして、通信経由で、前記リクエストが送信される場合に、前記リクエストに対し、前記識別情報を挿入する
（１８）に記載のクライアント装置。
（２０）
クライアント装置のデータ処理方法において、
前記クライアント装置が、
放送経由又は通信経由で配信されるコンテンツを転送するゲートウェイ装置との接続を確立する場合に、プロキシとしての機能を有する前記ゲートウェイ装置からネットワークを介して提供される、前記プロキシがリクエストを待ち受けるIPアドレスとポート番号に関する接続情報に基づいて、前記プロキシとの接続を確立し、
前記ゲートウェイ装置から、前記ネットワークを介して転送されてくる前記コンテンツを再生する
ステップを含むデータ処理方法。
【符号の説明】
【０３１８】
１  伝送システム，  １０  ゲートウェイ装置，  ２０−１乃至２０−Ｎ，２０  クライアント装置，  ３０  ネットワーク，  ４０  放送サーバ，  ５０  送信所，  ６０  放送伝送路，  ７０  通信サーバ，  ８０  インターネット，  １００  処理部，  １０１  チューナ，  １０２  通信I/F，  １０３  通信I/F，  １０４  記憶部，  １１１  UPnP/SSDPサーバ，  １１２  プロキシアプリマネージャ，  １１３  ローカルプロキシ，  １１４  SLS処理系，  ２００  処理部，  ２０１  通信I/F，  ２０２  表示部，  ２０３  スピーカ，  ２１１  アプリケーション，  ２１２  ブラウザ，  １０００  コンピュータ，  １００１  CPU
【図１】
2018034172.tif 000003
【図２】
2018034172.tif 000004
【図３】
2018034172.tif 000005
【図４】
2018034172.tif 000006
【図５】
2018034172.tif 000007
【図６】
2018034172.tif 000008
【図７】
2018034172.tif 000009
【図８】
2018034172.tif 000010
【図９】
2018034172.tif 000011
【図１０】
2018034172.tif 000012
【図１１】
2018034172.tif 000013
【図１２】
2018034172.tif 000014
【図１３】
2018034172.tif 000015
【図１４】
2018034172.tif 000016
【図１５】
2018034172.tif 000017
【図１６】
2018034172.tif 000018
【図１７】
2018034172.tif 000019
【図１８】
2018034172.tif 000020
【図１９】
2018034172.tif 000021
【図２０】
2018034172.tif 000022
【図２１】
2018034172.tif 000023
【図２２】
2018034172.tif 000024
【図２３】
2018034172.tif 000025
【図２４】
2018034172.tif 000026
【図２５】
2018034172.tif 000027
【図２６】
2018034172.tif 000028
【図２７】
2018034172.tif 000029
【図２８】
2018034172.tif 000030
【図２９】
2018034172.tif 000031
【国際調査報告】
2018034172.tif 000032
2018034172.tif 000033
2018034172.tif 000034
2018034172.tif 000035