JPWO2018043111A1 - 情報処理装置、情報処理方法、及び、情報処理システム - Google Patents

Abstract

本技術は、プロキシを複数設置する場合に、適切な負荷分散を行うことができるようにする情報処理装置、情報処理方法、及び、情報処理システムに関する。情報処理装置が、複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定することで、プロキシを複数設置する場合に、適切な負荷分散を行うことができるようになる。本技術は、例えば、家庭内LANやケーブルオペレータのヘッドエンド、モバイル網の基地局等のネットワークに接続されるFWプロキシ装置に適用することができる。

Description

本技術は、情報処理装置、情報処理方法、及び、情報処理システムに関し、特に、プロキシを複数設置する場合に、適切な負荷分散を行うことができるようにした情報処理装置、情報処理方法、及び、情報処理システムに関する。

インターネットを介してコンテンツを配信するサーバと、当該コンテンツを再生するクライアント装置との間に、プロキシサーバ（プロキシ）を設置することで、クライアント装置からの要求に対する応答性能を高める技術が提案されている（例えば、特許文献１参照）。

特開2015-49650号公報

ところで、クライアント装置が接続されるネットワークに、複数のプロキシが設置される場合に、プロキシごとの負荷を適切に分散させたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。

本技術はこのような状況に鑑みてなされたものであり、プロキシを複数設置する場合に、適切な負荷分散を行うことができるようにするものである。

本技術の第１の側面の情報処理装置は、複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備える情報処理装置である。

本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の情報処理方法は、上述した本技術の第１の側面の情報処理装置に対応する情報処理方法である。

本技術の第１の側面の情報処理装置、及び、情報処理方法においては、複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲が決定される。

本技術の第２の側面の情報処理システムは、マスタプロキシが稼働する第１の情報処理装置と、スレーブプロキシが稼働する１又は複数の第２の情報処理装置と、１又は複数のクライアント装置とが、ネットワークを介して接続された情報処理システムにおいて、前記第１の情報処理装置は、複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記スレーブプロキシに対する前記マスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備え、前記第２の情報処理装置は、複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記マスタプロキシに対する前記スレーブプロキシとして機能し、前記マスタプロキシにより決定された担当範囲に応じたサービスにより配信されるコンテンツのストリームを処理する処理部を備える情報処理システムである。

本技術の第２の側面の情報処理システムにおいては、マスタプロキシが稼働する第１の情報処理装置と、スレーブプロキシが稼働する１又は複数の第２の情報処理装置と、１又は複数のクライアント装置とが、ネットワークを介して接続された情報処理システムにおいて、前記第１の情報処理装置によって、複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記スレーブプロキシに対する前記マスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲が決定され、複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記マスタプロキシに対する前記スレーブプロキシとして機能し、前記マスタプロキシにより決定された担当範囲に応じたサービスにより配信されるコンテンツのストリームが処理される。

本技術の第１の側面、及び、第２の側面によれば、プロキシを複数設置する場合に、適切な負荷分散を行うことができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術を適用した伝送システムの一実施の形態の構成を示す図である。 マスタ・プロキシ装置の構成例を示す図である。 スレーブ・プロキシ装置の構成例を示す図である。 クライアント装置の構成例を示す図である。 本技術のIP伝送方式のプロトコルスタックの例を示す図である。 本技術の概要を説明するフローチャートである。 プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの一連の処理の流れを説明するフローチャートである。 プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの一連の処理の流れを説明するフローチャートである。 スレーブプロキシからの存在確認に応じたマスタプロキシによる設定管理APIの通知の詳細を説明するフローチャートである。 デバイスディスクリプションレスポンスの例を示す図である。 サービス担当範囲リクエストの例を示す図である。 サービス担当範囲レスポンスの例を示す図である。 マスタプロキシによるサービス担当範囲の割り当ての例を示す図である。 さらに新たなスレーブプロキシが追加された場合におけるサービス担当範囲の割り当て処理の流れを説明するフローチャートである。 マスタプロキシによるサービス担当範囲の割り当ての例を示す図である。 マスタプロキシによる既存のスレーブプロキシに対する設定管理APIの再通知の詳細を説明する。 NOTIFYメッセージの例を示す図である。 マスタプロキシ設定処理の流れを説明するフローチャートである。 プロキシ待ち受けアドレス/ポートリクエストの例を示す図である。 プロキシ待ち受けアドレス/ポートレスポンスの例を示す図である。 機械的なサービス担当範囲の割り当ての例を示す図である。 サービスのアクセス頻度に応じた担当範囲の割り当ての例を示す図である。 サービスのアクセス頻度に応じたBSごとの担当範囲の割り当ての例を示す図である。 サービスのアクセス頻度に応じたBSごとの担当範囲の割り当ての例を示す図である。 ネットワークが、家庭内LAN等の場合におけるトポロジの例を示す図である。 ネットワークが、車両間の無線通信の場合におけるトポロジの例を示す図である。 伝送システムの他の構成例を示す図である。 コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

１．システムの構成
２．本技術の概要
３．マスタプロキシとスレーブプロキシの関係によるFWプロキシ装置の負荷分散
（１）新規のスレーブ・プロキシ装置が追加される場合の例
（２）新規のスレーブ・プロキシ装置がさらに追加される場合の例
（３）クライアント装置によるマスタプロキシの発見・接続の例
４．マスタプロキシとスレーブプロキシの実装例
（１）機械的なサービス担当範囲の割り当ての例
（２）サービスのアクセス頻度に応じた担当範囲の割り当ての例
（３）サービスのアクセス頻度に応じたBSごとの担当範囲の割り当ての例
（４）マスタプロキシとスレーブプロキシのトポロジの例
５．変形例
６．コンピュータの構成

＜１．システムの構成＞

（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。

図１において、伝送システム１は、FWプロキシ装置１０−１乃至１０−Ｎ（Ｎ：１以上の整数）、クライアント装置２０−１乃至２０−Ｍ（Ｍ：１以上の整数）、及び放送サーバ４０を含んで構成される。

伝送システム１において、FWプロキシ装置１０−１乃至１０−Ｎと、クライアント装置２０−１乃至２０−Ｍとは、エンドユーザ宅２に構築された家庭内LAN(Local Area Network)等のネットワーク３０を介して、相互に接続され、通信を行うことが可能である。

FWプロキシ装置１０−１は、ネットワーク３０に接続されたデバイスと、放送サーバ４０や送信所５０などからなる放送伝送路６０との間に設置され、フォワードプロキシ（Forward Proxy）としての機能（ゲートウェイ機能）を有している。FWプロキシ装置１０−１は、フォワードプロキシ機能を提供するための専用のサーバや、テレビ受像機やセットトップボックス（STB：Set Top Box）、ネットワークストレージなどから構成される。

FWプロキシ装置１０−１は、送信所５０を介して、放送サーバ４０から送信されてくる放送波を受信し、放送波から得られるコンテンツのストリームを、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｍのいずれかに送信（転送）する。

FWプロキシ装置１０−２乃至１０−Ｎは、FWプロキシ装置１０−１と同様に、専用のサーバやテレビ受像機などから構成され、フォワードプロキシとしての機能を有している。FWプロキシ装置１０−２乃至１０−Ｎは、放送サーバ４０からの放送波から得られるコンテンツのストリームを、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｍのいずれかに送信（転送）する。

ここで、詳細は後述するが、ネットワーク３０に接続されるFWプロキシ装置１０−１乃至１０−Ｎにおいては、いずれかのFWプロキシ装置１０が、マスタプロキシとして機能し、それ以外のFWプロキシ装置１０が、スレーブプロキシとして機能するマスタ・スレーブ関係を有している。そして、FWプロキシ装置１０−１乃至１０−Ｎが、マスタ・スレーブ関係を有することで、マスタプロキシが稼働するFWプロキシ装置１０によって、各FWプロキシ装置１０に対し、サービスの担当範囲が割り当てられる。

なお、FWプロキシ装置１０−１乃至１０−Ｎを、特に区別する必要がない場合、単に、FWプロキシ装置１０と称するものとする。

また、以下の説明では、マスタプロキシとしての機能を有するFWプロキシ装置１０を、マスタ・プロキシ装置１０Ｍと称する一方で、スレーブプロキシとしての機能を有するFWプロキシ装置１０を、スレーブ・プロキシ装置１０Ｓと称して区別する。

なお、マスタ・プロキシ装置１０Ｍの詳細な構成は、図２を参照して後述する。また、スレーブ・プロキシ装置１０Ｓの詳細な構成は、図３を参照して後述する。また、以下の説明では、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓを、特に区別する必要がない場合には、FWプロキシ装置１０と称するものとする。つまり、FWプロキシ装置１０は、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓのいずれかとなる。

クライアント装置２０−１は、ネットワーク３０を介してFWプロキシ装置１０−１乃至１０−Ｎのいずれから送信（転送）されてくるコンテンツのストリームを受信して再生する受信機である。すなわち、クライアント装置２０−１は、エンドユーザの操作などに応じて、FWプロキシ装置１０−１乃至１０−Ｎのいずれかを介して、放送経由で配信されるコンテンツを再生することができる。

クライアント装置２０−１は、テレビ受像機やセットトップボックス、パーソナルコンピュータなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機として構成される。さらに、クライアント装置２０−１は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。

クライアント装置２０−２乃至２０−Ｍは、クライアント装置２０−１と同様に、家庭内で使用される固定受信機又はモバイル受信機などから構成され、FWプロキシ装置１０−１乃至１０−Ｎのいずれかを介して、放送経由で配信されるコンテンツのストリームを受信して再生する。

なお、以下の説明では、クライアント装置２０−１乃至２０−Ｍを、特に区別する必要がない場合、単に、クライアント装置２０と称するものとする。また、クライアント装置２０の詳細な構成は、図４を参照して後述する。

放送サーバ４０は、例えば、放送局などの放送事業者により提供されるサーバであって、送信所５０に設置される送出設備と、専用線などの所定の回線を介して接続される。

放送サーバ４０は、番組やCM等のコンテンツのファイル（データ）や制御情報（シグナリング）を処理し、その結果得られるデータを、専用線を介して送信所５０内の送出設備に送信する。そして、送信所５０内の送出設備は、放送サーバ４０からのデータに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送波が、放送伝送路６０を介して、エンドユーザ宅２内のFWプロキシ装置１０により受信される。

なお、図１の伝送システムでは、FWプロキシ装置１０とクライアント装置２０が、エンドユーザ宅２内に配置される場合を説明したが、FWプロキシ装置１０は、エンドユーザ宅２内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。

すなわち、例えば、FWプロキシ装置１０が、ケーブルオペレータのヘッドエンドに設置される場合、クライアント装置２０は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。また、例えば、FWプロキシ装置１０が、モバイル網の基地局に設置される場合、クライアント装置２０は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイスとなる。

また、FWプロキシ装置１０やクライアント装置２０は、自動車等の車両に搭載される車載機器であってもよい。さらに、図１の伝送システム１において、ネットワーク３０に接続されるデバイスやサーバの間で行われる通信は、無線通信及び有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。

（マスタ・プロキシ装置の構成）
図２は、図１のFWプロキシ装置１０のうち、マスタ・プロキシ装置１０Ｍの構成例を示す図である。

図２において、マスタ・プロキシ装置１０Ｍは、処理部１００、チューナ１０１、通信I/F１０２、及び記憶部１０３から構成される。

処理部１００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１００は、各種の演算処理や、各部の動作制御などの処理を行う。

チューナ１０１は、アンテナを介して受信された放送波に対し、必要な処理（復調処理等）を施し、その結果得られる多重化ストリームを、処理部１００に供給する。処理部１００は、チューナ１０１から供給される多重化ストリームを処理し、その結果得られるコンテンツのストリームを、通信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が処理されることで、多重化ストリームから、所望のコンテンツのストリーム（担当範囲のサービスで配信されるコンテンツのストリーム）が得られる。なお、SLSの詳細は、図５を参照して後述する。

マスタ・プロキシ装置１０Ｍは、以上のように構成される。

（スレーブ・プロキシ装置の構成）
図３は、図１のFWプロキシ装置１０のうち、スレーブ・プロキシ装置１０Ｓの構成例を示す図である。

図３において、スレーブ・プロキシ装置１０Ｓは、処理部１５０、チューナ１５１、通信I/F１５２、及び記憶部１５３から構成される。なお、チューナ１５１乃至記憶部１５３は、図２のチューナ１０１乃至記憶部１０３と同様に構成されるため、ここではその説明は省略する。

処理部１５０は、例えば、CPUやマイクロプロセッサ等から構成される。処理部１５０は、各種の演算処理や、各部の動作制御などの処理を行う。

処理部１５０は、スレーブプロキシ１６１及びSLS処理系１６２を含む。

スレーブプロキシ１６１は、スレーブ・プロキシ装置１０Ｓで稼働するサービスであって、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１に対するスレーブプロキシとして機能する。

スレーブプロキシ１６１は、マスタプロキシ１１１により割り当てられたサービスの担当範囲に従い、担当範囲のサービスに関する処理を行う。なお、スレーブプロキシ１６１により行われる処理の詳細は、図７及び図８などを参照して後述する。

SLS処理系１６２は、放送経由で取得される制御情報であるSLSに関する処理を行う。SLS処理系１６２によりSLSが処理されることで、多重化ストリームから、所望のコンテンツのストリーム（担当範囲のサービスで配信されるコンテンツのストリーム）が得られる。なお、SLSの詳細は、図５を参照して後述する。

スレーブ・プロキシ装置１０Ｓは、以上のように構成される。

（クライアント装置の構成）
図４は、図１のクライアント装置２０の構成例を示す図である。

図４において、クライアント装置２０は、処理部２００、通信I/F２０１、表示部２０２、及びスピーカ２０３から構成される。

処理部２００は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２００は、各種の演算処理や、各部の動作制御などの処理を行う。

通信I/F２０１は、例えば、通信インターフェース回路等から構成される。

通信I/F２０１は、処理部２００からの制御に従い、ネットワーク３０に接続されたマスタ・プロキシ装置１０Ｍに対し、所望のサービスで配信されるコンテンツを要求する。また、通信I/F２０１は、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓから送信（転送）されてくるコンテンツのストリームを受信し、処理部２００に供給する。

処理部２００は、通信I/F２０１から供給されるコンテンツのストリームを処理し、その結果得られるデータのうち、ビデオデータを、表示部２０２に供給し、オーディオデータを、スピーカ２０３に供給する。

表示部２０２は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部２０２は、処理部２００から供給されるビデオデータに対応する映像を表示する。スピーカ２０３は、処理部２００から供給されるオーディオデータに対応する音声を出力する。

なお、表示部２０２が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部２００に供給され、処理部２００は、当該操作信号に応じた処理を行う。また、図４には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部２００に供給されるようにしてもよい。

処理部２００は、アプリケーション２１１及びブラウザ２１２を含む。アプリケーション２１１及びブラウザ２１２により、レンダラ機能が提供される。

アプリケーション２１１は、ネットワーク３０に接続されるクライアント装置２０が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１との接続を確立するための処理を行う。なお、アプリケーション２１１で行われる処理の詳細は、図１８などを参照して後述する。

ブラウザ２１２は、通信I/F２０１から供給されるコンテンツのストリームであって、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓにより放送経由で受信されたデータを処理し、コンテンツを再生する。

なお、ブラウザ２１２は、DASHプレーヤとしての機能を有するが、その詳細は、図５を参照して後述する。また、ブラウザ２１２で行われる処理の詳細は、図８や図１８などを参照して後述する。

クライアント装置２０は、以上のように構成される。

（本技術のプロトコルスタック）
図５は、本技術の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メタデータは、他のメタデータの取得先などの情報を含む。

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)の派生フォーマットである。

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セグメント単位で伝送することができる。

そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、各装置での実装の負担や処理の負担を軽減することができる。

なお、図１の伝送システム１では、送信側に、放送系の放送サーバ４０が設けられ、一方向の放送系のストリーミング配信のみに対応した構成を示したが、図５のプロトコルスタックに示したように、本技術は、双方向の通信系のストリーミング配信にも対応することができる。このような双方向の通信系のストリーミング配信に対応した構成については、図２７を参照して後述するものとする。

＜２．本技術の概要＞

ところで、図１に示した伝送システム１のような、ネットワーク３０に、複数のFWプロキシ装置１０−１乃至１０−Ｎが設置されている環境では、クライアント装置２０からのDASHセグメントのリクエストの送付先が、特定のFWプロキシ装置１０に固定されてしまうと、それ以外のFWプロキシ装置１０（例えば後から追加で設置されたFWプロキシ装置１０）が機能しなくなる。

また、クライアント装置２０で実行されるブラウザ２１２のプロキシ設定を利用することで、各クライアント装置２０が接続するFWプロキシ装置１０をそれぞれ異なるように手動で設定することも可能ではあるが、管理が煩雑となり、FWプロキシ装置１０ごとの負荷が容易に分散されない可能性がある。

このように、複数のFWプロキシ装置１０−１乃至１０−Ｎが設置されている環境において、FWプロキシ装置１０ごとの負荷を、適切に分散させたいという要請があるが、現状では、そのような要請に応えるための技術方式は確立されていない。

そこで、本技術では、複数のFWプロキシ装置１０−１乃至１０−Ｎが設置される場合に、FWプロキシ装置１０の間に、マスタとスレーブとの関係を持たせて、マスタ・プロキシ装置１０Ｍによって、クライアント装置２０からのDASHセグメントのリクエストが、適切にリダイレクションされるようにする。これにより、ネットワーク３０において、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０ＳのいずれかとなるFWプロキシ装置１０ごとの負荷が、適切に分散されることになる。

このFWプロキシ装置１０の間のマスタとスレーブとの関係は、FWプロキシ装置１０がネットワーク３０に追加される度に、手動で設定してもよいし、あるいはFWプロキシ装置１０同士が、例えば各自の能力属性（処理能力やストレージ能力等）等に応じたネゴシエーションを行うことで決定してもよい。

ここでは、例えば、ネットワーク３０に最初に接続したFWプロキシ装置１０をマスタ・プロキシ装置１０Ｍとし、その後、FWプロキシ装置１０が追加された場合には、FWプロキシ装置１０の能力属性に応じて、マスタ・プロキシ装置１０Ｍを決定すればよい。ただし、マスタ・プロキシ装置１０Ｍは固定とし、常に同一のFWプロキシ装置１０が、その役割を担うようにしてもよい。また、マスタ・プロキシ装置１０Ｍは、１つに限らず、複数設置するようにしてもよい。複数のマスタ・プロキシ装置１０Ｍを設けることで、各マスタプロキシ１１１の処理の負荷を分散させることができる。

マスタとなったFWプロキシ装置１０（マスタ・プロキシ装置１０Ｍ）は、例えば、ユニバーサルプラグアンドプレイ(UPnP：Universal Plug and Play)のSSDP(Simple Service Discovery Protocol)等を利用して、サービス（チャネル）の担当範囲を調整するためのAPI(Application Programming Interface)を公開し、当該APIを通じて、スレーブとなった各FWプロキシ装置１０（スレーブ・プロキシ装置１０Ｓ）に、サービス担当範囲を割り当てる。

ここでは、マスタ・プロキシ装置１０Ｍによって、サービス担当範囲を割り当てるためのデータベース（以下、プロキシ−サービス担当範囲データベースという）が生成されることで、各FWプロキシ装置１０（で稼働するマスタプロキシ１１１とスレーブプロキシ１６１）に対し、サービス担当範囲が割り当てられる。

なお、UPnPは、デバイスを接続するだけで、対象のネットワークに参加することを可能にするプロトコルである。また、SSDPは、UPnPで用いられるプロコトルの１つで、ネットワーク上のデバイスの探索や応答を行うためのものである。

マスタ・プロキシ装置１０Ｍは、クライアント装置２０から、DASHセグメントのリクエストを受けた場合、プロキシ−サービス担当範囲データベースを参照して、担当のFWプロキシ装置１０に特定し、当該FWプロキシ装置１０にリダイレクションを行う。そして、リダイレクションを受けたFWプロキシ装置１０は、割り当てられたサービスの範囲内で、放送経由で配信されるコンテンツのストリームを受信し、ネットワーク３０を介してクライアント装置２０に送信する。

なお、マスタ・プロキシ装置１０Ｍは、プロキシ−サービス担当範囲データベースを生成する際に、各種のポリシ（規則）に従い、FWプロキシ装置１０に対し、サービス担当範囲が割り当てられるようにする。

このようなポリシとしては、例えば、複数のFWプロキシ装置１０に対し、対象のエリア内で受信可能な全サービスを機械的に割り当てたり、あるいは、エンドユーザの視聴履歴を考慮に入れて、アクセス頻度の高いサービス群が優先的に負荷分散されるように割り当てたりすることができる。さらには、サービス（チャネル）のザッピングの高速化を図るために、同時に受信可能なサービス群をまとめるなど、様々な規則を選択できるようにする。

なお、サービス群をまとめる単位としては、例えば、ブロードキャストストリームID（BSID： Broadcast Stream ID）単位とすることができる。FWプロキシ装置１０において、ブロードキャストストリームIDで指定される周波数帯域（例えば6MHz）で伝送されるデータは一度に取得することができる。このブロードキャストストリームIDについては、例えば、下記の非特許文献１の「Table 6.2 SLT XML Format」などに、その詳細が記述されている。

非特許文献１：ATSC Candidate Standard：Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016

また、新しいFWプロキシ装置１０がネットワーク３０に接続された場合には、当該ネットワーク３０に接続されるFWプロキシ装置１０のうち、同一のマスタ・プロキシ装置１０Ｍ（で稼働するマスタプロキシ１１１）を共有している１又は複数のスレーブ・プロキシ装置１０Ｓ（で稼働するスレーブプロキシ１６１）のそれぞれのサービス担当範囲の再設定が行われる。

ここで、図６には、本技術を適用した場合に行われる、プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの処理の流れの概要を示している。

すなわち、ネットワーク３０において、新規のFWプロキシ装置１０が接続され、ネットワーク３０に参加してきたとき（Ｓ１）、マスタ・プロキシ装置１０Ｍ（で稼働するマスタプロキシ１１１）は、ネットワーク３０に接続された複数のFWプロキシ装置１０で稼働するマスタプロキシ１１１とスレーブプロキシ１６１が受け持つサービスの担当範囲を決定する（Ｓ２）。

このとき、マスタ・プロキシ装置１０Ｍでは、各FWプロキシ装置１０が担当するサービス範囲に関するデータを格納したプロキシ−サービス担当範囲データベースが生成され、各FWプロキシ装置１０に対し、サービス担当範囲が通知される。これにより、各FWプロキシ装置１０においては、マスタ・プロキシ装置１０Ｍからのサービス担当範囲に従い、サービスチューニングの準備が行われる。

その後、ネットワーク３０において、クライアント装置２０が接続され、放送経由で配信されるコンテンツの再生が開始されるとき、マスタ・プロキシ装置１０Ｍ（で稼働するマスタプロキシ１１１）は、クライアント装置２０からのDASHセグメントのリクエストのリダイレクションを行う（Ｓ３）。

このとき、マスタ・プロキシ装置１０Ｍでは、プロキシ−サービス担当範囲データベースを参照して、クライアント装置２０からのDASHセグメントのリクエストの処理を担当すべきFWプロキシ装置１０を決定し、当該FWプロキシ装置１０に対し、クライアント装置２０からのDASHセグメントのリクエストを送信する（リダイレクションする）。

以上のようにして、プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの処理を行うことで、ネットワーク３０に複数設置されたFWプロキシ装置１０の負荷分散を行うことが可能となるが、以下、その詳細な内容について説明する。

＜３．マスタプロキシとスレーブプロキシの関係によるFWプロキシ装置の負荷分散＞

（１）新規のスレーブ・プロキシ装置が追加される場合の例

（サービス担当範囲の割り当てと、リクエストリダイレクションの処理の流れ）
まず、図７及び図８のフローチャートを参照して、新規のスレーブ・プロキシ装置１０Ｓが追加される場合における、プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの一連の処理の流れを説明する。

図７及び図８の説明では、マスタ・プロキシ装置１０Ｍが存在するネットワーク３０に対し、新規のスレーブ・プロキシ装置１０Ｓと、クライアント装置２０がその順に接続し、クライアント装置２０により、放送経由で配信されるコンテンツの再生が指示される場合を説明する。

図７及び図８において、ステップＳ１１１乃至Ｓ１１７の処理は、マスタ・プロキシ装置１０Ｍにより実行され、ステップＳ１２１乃至Ｓ１３０の処理は、新規で追加されるスレーブ・プロキシ装置１０Ｓにより実行される。一方で、ステップＳ１０１乃至Ｓ１０５の処理は、クライアント装置２０により実行される。

新規のスレーブ・プロキシ装置１０Ｓが、ネットワーク３０に接続されると（Ｓ１２１）、ステップＳ１２２において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１の存在を確認するために、通信I/F１５２を介して、ネットワーク３０に接続されたデバイスに対し、存在確認用のメッセージを、マルチキャストで送信する。

ステップＳ１２２の処理で、スレーブ・プロキシ装置１０Ｓにより送信されるメッセージは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１１１において、マスタプロキシ１１１は、スレーブ・プロキシ装置１０Ｓから受信したメッセージに応じて、設定管理APIを生成し、レスポンスとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓに通知する。

なお、スレーブプロキシ１６１からの存在確認に応じたマスタプロキシ１１１による設定管理APIの通知の詳細は、図９のフローチャートを参照して後述する。

ステップＳ１１１の処理で、マスタ・プロキシ装置１０Ｍにより送信される設定管理APIは、ネットワーク３０を介して、スレーブ・プロキシ装置１０Ｓにより受信される。

ステップＳ１２３において、スレーブプロキシ１６１は、チューナ１５１を制御して、サービスのスキャンを行う。ここでは、例えば、チューナ１５１により初期スキャン処理が行われることで、LLSとして伝送されるSLTメタデータ等から、スレーブ・プロキシ装置１０Ｓにより受信可能なサービスを示すサービススキャン結果が得られる。

一方で、このとき、マスタ・プロキシ装置１０Ｍにおいても、チューナ１０１により再スキャン処理が行われる（Ｓ１１２）。これにより、マスタ・プロキシ装置１０Ｍでは、LLSとして伝送されるSLTメタデータ等から、マスタ・プロキシ装置１０Ｍにより受信可能なサービスを示すサービススキャン結果が得られる。

ただし、このような、スレーブ・プロキシ装置１０Ｓがサービススキャンを行うタイミングで、マスタ・プロキシ装置１０Ｍによるサービススキャンを行うかどうかは、任意である。

すなわち、マスタ・プロキシ装置１０Ｍが受信可能なサービスは、頻繁に変わるものではないため、一度、サービススキャンを行えば、そのサービススキャン結果を利用し続けることができる。ただし、マスタ・プロキシ装置１０Ｍが、モバイル受信機や車載機器などの移動可能なデバイスとなる場合には、現時点でのエリアにより受信可能なサービスが変化する可能性が高いため、サービススキャンを再度行う必要がある。

ステップＳ１２４において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１に対し、ステップＳ１２３の処理で得られるサービススキャン結果を通知する。また、スレーブプロキシ１６１は、マスタプロキシ１１１に対し、サービス担当範囲を要求する（Ｓ１２５）。

なお、スレーブプロキシ１６１は、サービススキャン結果を、サービス担当範囲のリクエストに含めて、同時に送信するようにしてもよい。

ステップＳ１２４，Ｓ１２５の処理で、スレーブ・プロキシ装置１０Ｓにより送信される、サービススキャン結果と、サービス担当範囲のリクエストは、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１１３において、マスタプロキシ１１１は、サービススキャン結果に基づいて、サービス担当範囲を決定する。

ここでは、サービススキャン結果として、マスタ・プロキシ装置１０Ｍ自身のサービススキャン結果と、新規のスレーブ・プロキシ装置１０Ｓのサービススキャン結果が得られる。そして、マスタプロキシ１１１では、これらのサービススキャン結果を用いて、あらかじめ定められたポリシ（規則）に従い、各FWプロキシ装置１０のサービス担当範囲を決定する。

例えば、ここでのポリシとしては、複数のFWプロキシ装置１０に対し、対象のエリア内で受信可能な全サービスを機械的に割り当てたり、あるいは、エンドユーザの視聴履歴を考慮に入れて、アクセス頻度の高いサービス群が優先的に負荷分散されるように割り当てたりすることができるのは、先に述べた通りである。なお、ポリシの詳細については、図２１乃至図２４を参照して後述する。

また、ここでは、各FWプロキシ装置１０の能力属性（例えば処理能力等）が取得されるようにすることで、当該能力属性を用いて、ポリシに応じたサービスの担当範囲が決定されるようにしてもよい。これにより、例えば、処理能力が高いFWプロキシ装置１０に対しては、担当のサービスの範囲を広げるといったことが可能となる。

なお、ここでは、各FWプロキシ装置１０（マスタプロキシ１１１やスレーブプロキシ１６１）と、サービス担当範囲とを対応付けたプロキシ−サービス担当範囲データベースが生成され、記憶部１０３に記憶される。

ステップＳ１１４において、マスタプロキシ１１１は、スレーブプロキシ１６１に対し、ステップＳ１１３の処理で決定されたサービス担当範囲を示す情報（以下、サービス担当範囲情報という）を通知する。

ステップＳ１１４の処理で、マスタ・プロキシ装置１０Ｍにより送信される、サービス担当範囲情報は、スレーブ・プロキシ装置１０Ｓにより受信される。

ステップＳ１２６において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍから受信したサービス担当範囲情報に基づいて、チューナ１５１を制御して、自身の担当範囲のサービスのチューニングの準備を行う。ここでは、サービス担当範囲情報が示す各サービスの選局の準備が行われる。

一方で、このとき、マスタ・プロキシ装置１０Ｍにおいても、自身の担当範囲のサービスのチューニングの準備が行われる（Ｓ１１５）。なお、スレーブ・プロキシ装置１０Ｓにおいては、リソースに余裕がある場合には、担当範囲のサービスについて、事前にサービスチューニングが行われるようにしてもよい（図８のＳ１２７）。

その後、図８に示すように、クライアント装置２０が、ネットワーク３０に接続されると（Ｓ１０１）、当該クライアント装置２０と、マスタ・プロキシ装置１０Ｍとの間で、マスタプロキシ設定処理が行われる（Ｓ１０２）。

このマスタプロキシ設定処理では、クライアント装置２０と、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１との間の接続が確立される。なお、マスタプロキシ設定処理の詳細は、図１８のフローチャートを参照して後述する。

ステップＳ１０３において、アプリケーション２１１は、マスタプロキシ１１１に対し、サービス−MPDテーブルを要求する。

ステップＳ１０３の処理で、クライアント装置２０により送信されるサービス−MPDテーブルのリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１１６において、マスタプロキシ１１１は、クライアント装置２０から受信したテーブルのリクエストに応じて、サービス−MPDテーブルを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に返答する。

ここで、サービス−MPDテーブルは、サービスとMPDメタデータとを対応付けたテーブルである。サービス−MPDテーブルは、SLSから生成される。なお、ここでは、説明の簡略化のため、サービス−MPDテーブルがマスタプロキシ１１１により生成されるとして説明するが、サービス−MPDテーブルは、SLS処理系１１５により生成されるようにしてもよい。

ステップＳ１１６の処理で、マスタ・プロキシ装置１０Ｍにより送信されるサービス−MPDテーブルは、ネットワーク３０を介して、クライアント装置２０により受信される。

ステップＳ１０４において、アプリケーション２１１は、マスタ・プロキシ装置１０Ｍから受信したサービス−MPDテーブルを参照して、所望のサービスに対応したMPDメタデータに基づいて、マスタプロキシ１１１に対し、DASHセグメントを要求する。

ステップＳ１０４の処理で、クライアント装置２０により送信されるDASHセグメントのリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１１７において、マスタプロキシ１１１は、クライアント装置２０から受信したDASHセグメントのリクエストに対するスレーブプロキシ１６１への割り振りを、プロキシ−サービス担当範囲データベースを参照して判断し、その判断結果に応じたリダイレクションを行う。

これにより、マスタプロキシ１１１によって、クライアント装置２０（のアプリケーション２１１）からのDASHセグメントのリクエストが、適切なスレーブプロキシ１６１に対し、リダイレクションされることになる。

なお、ここでは、説明を簡略化するために、リダイレクションされるDASHセグメントのリクエストが、マスタプロキシ１１１からスレーブプロキシ１６１に対して直接通知されるとして説明しているが、実際には、図８の点線で示しているように、マスタプロキシ１１１からクライアント装置２０を経由して、いわば間接的に、スレーブプロキシ１６１に通知される。また、セグメントリクエストのリダイレクションの詳細は、図２５及び図２６を参照して後述する。

ステップＳ１１７の処理で、マスタ・プロキシ装置１０ＭによりリダイレクションされたDASHセグメントのリクエストは、適切であると判断されたスレーブプロキシ１６１が稼働しているスレーブ・プロキシ装置１０Ｓにより受信される。

ステップＳ１２８において、スレーブプロキシ１６１は、事前サービスチューニングを行っているかどうかを判定する。ここでは、上述のステップＳ１２７の処理で、リソースに余裕がなく、事前サービスチューニングを行っていない場合には、ステップＳ１２８の判定処理で、「NO」と判定され、処理は、ステップＳ１２９に進められる。

ステップＳ１２９において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍから受信したDASHセグメントのリクエストに基づいて、チューナ１０１を制御して、サービスのチューニングを行う。これにより、DASHセグメントのリクエストに応じたDASHセグメントファイルが、放送サーバ４０から放送経由で取得される。

一方、上述のステップＳ１２７の処理で、リソースに余裕があって、事前サービスチューニングが行われていた場合には、放送サーバ４０から放送経由で得られる、担当範囲のサービスのストリームは展開済みであるので、ステップＳ１２９の処理はスキップされる。この場合、展開済みのストリームから、DASHセグメントのリクエストに応じたDASHセグメントファイルが取得される。

DASHセグメントファイルが取得されると、処理は、ステップＳ１３０に進められる。ステップＳ１３０において、スレーブプロキシ１６１は、放送サーバ４０から受信したDASHセグメントファイルを、通信I/F１０２を介して、ネットワーク３０に接続されたクライアント装置２０に返答する。

ステップＳ１３０の処理で、スレーブ・プロキシ装置１０Ｓにより送信（転送）されるDASHセグメントファイルは、ネットワーク３０を介して、クライアント装置２０により受信される。

クライアント装置２０では、ブラウザ２１２によって、スレーブ・プロキシ装置１０Ｓから受信したDASHセグメントファイルが再生される（Ｓ１０５）。これにより、クライアント装置２０においては、放送経由で配信された番組等のコンテンツが再生されることになる。

以上、新規のスレーブ・プロキシ装置１０Ｓが追加される場合における、プロキシのサービス担当範囲の割り当てと、セグメントリクエストのリダイレクションの一連の処理の流れを説明した。

（設定管理APIの通知の詳細）
次に、図９のフローチャートを参照して、スレーブプロキシ１６１からの存在確認に応じたマスタプロキシ１１１による設定管理APIの通知の詳細を説明する。すなわち、図９のフローチャートに示した処理は、上述の図７のステップＳ１２２，Ｓ１１１の処理に対応したものとなる。

ステップＳ１５１においては、図７のステップＳ１２２と同様に、新規のスレーブ・プロキシ装置１０Ｓで稼働するスレーブプロキシ１６１が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１の存在を確認するために、ネットワーク３０に接続されたデバイスに対し、M-SEARCHリクエストを、マルチキャストで送信する。

このM-SEARCHリクエストは、HTTPリクエストであって、SSDPであるプロトコルを利用して、ネットワーク３０に接続されたデバイスの探索を行う際に用いられる。

ステップＳ１５１の処理で、スレーブ・プロキシ装置１０Ｓにより送信されるM-SEARCHリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１４１において、UPnP/SSDPサーバ１１２は、スレーブ・プロキシ装置１０Ｓから受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、M-SEARCHレスポンスとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓに送信する。

このM-SEARCHレスポンスは、M-SEARCHリクエストに対する応答であって、LOCATIONとして、デバイスディスクリプションURLを含んでいる。このデバイスディスクリプションURLは、XML形式のファイルのURLである。

ステップＳ１４１の処理で、マスタ・プロキシ装置１０Ｍにより送信されるM-SEARCHレスポンスは、ネットワーク３０を介して、スレーブ・プロキシ装置１０Ｓにより受信される。

ステップＳ１５２において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍから受信したM-SEARCHレスポンス（のデバイスディスクリプションURL）に基づいて、ネットワーク３０に接続されたマスタ・プロキシ装置１０Ｍで稼働するローカルウェブサーバ１１４に対し、デバイスディスクリプションを要求する。

このデバイスディスクリプションリクエストは、HTTPリクエストであって、GETメソッドの対象のリソースとして、M-SEARCHレスポンスのデバイスディスクリプションURLに応じた内容が記述される。

ステップＳ１５２の処理で、スレーブ・プロキシ装置１０Ｓにより送信されるデバイスディスクリプションリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１４２において、ローカルウェブサーバ１１４は、スレーブ・プロキシ装置１０Ｓから受信したデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓに送信する。

図１０は、デバイスディスクリプションレスポンスの例を示す図である。

なお、図１０の例では、記載を省略しているが、デバイスディスクリプションレスポンスのヘッダには、ファイルのタイプなどが記述される。また、当該ヘッダに続いて、XML形式のデバイスディスクリプションの内容が記述される。

すなわち、図１０に示すように、デバイスディスクリプションには、root要素のxmlns属性として、"urn:schemas-upnp-org:device-1-0"が記述され、UPnP準拠のデバイスディスクリプションであることが宣言されている。

serviceList要素には、マスタ・プロキシ装置１０Ｍでサポートされるサービスの一覧が記述される。serviceList要素には、１又は複数のservice要素が記述される。

service要素には、サポートされるサービスのうち、１つのサービスについての情報が記述される。service要素は、serviceType要素、serviceId要素、SCPDURL要素、及びcontrolURL要素などの上位要素となる。

図１０の例では、２つのservice要素が記述されている。

１つ目のservice要素において、serviceType要素には、サービスのタイプとして、"urn:atsc:proxy"が記述され、ATSC3.0サービスのプロキシサービスであることを意味している。

また、serviceId要素には、サービスIDとして、"urn:UPnP:serviceId:1234"が記述され、プロキシサービスのサービスIDを表している。

また、controlURL要素には、プロキシ待ち受けアドレス/ポート取得APIのURLとして、"http://192.168.1.1:23456/getATSC3.0ProxyAddressPort"が記述される。このURLは、マスタプロキシ１１１がリクエストを待ち受けるIPアドレスとポート番号を示すプロキシ待ち受けアドレス/ポートを取得するためのWeb APIを呼び出すための情報である。

２つ目のservice要素において、serviceType要素には、サービスのタイプとして、"urn:atsc:configMan"が記述され、ATSC3.0の設定管理サービスであることを意味している。

また、serviceId要素には、サービスIDとして、"urn:UPnP:serviceId:5678"が記述され、プロキシサービスのサービスIDを表している。

また、controlURL要素には、設定管理APIのURLとして、"http://192.168.1.1:23456/getServiceScope"が記述される。このURLは、マスタプロキシ１１１がサービス担当範囲情報を取得するためのWeb APIを呼び出すための情報である。

なお、各service要素において、通常、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要素に、ダミーの文字列を記述するようにしてもよい。

図９に戻り、ステップＳ１４２の処理で、マスタ・プロキシ装置１０Ｍにより送信されるデバイスディスクリプションレスポンスは、デバイスディスクリプションリクエストを送信したスレーブ・プロキシ装置１０Ｓにより受信される。

そして、スレーブ・プロキシ装置１０Ｓでは、マスタ・プロキシ装置１０Ｍから受信したデバイスディスクリプションレスポンスに基づいて、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１から、サービス担当範囲情報を取得することになる。

ここで、図９のフローチャートには、スレーブ・プロキシ装置１０Ｓで稼働するスレーブプロキシ１６１における、デバイスディスクリプションレスポンスを受信した後の処理を記載していないが、次のような処理が行われる。

すなわち、スレーブプロキシ１６１は、デバイスディスクリプションレスポンスの設定管理APIのURLに基づいて、マスタプロキシ１１１に対し、サービス担当範囲を要求する。なお、このスレーブプロキシ１６１の処理は、上述の図７のステップＳ１２５の処理に相当する。

図１１は、サービス担当範囲リクエストの例を示す図である。

サービス担当範囲リクエストには、GETメソッドの対象のリソースとして、"getServiceScope"であるサービス担当範囲情報が記述される。また、HOSTには、ホスト名として、"192.168.1.1:23456"が記述される。

すなわち、サービス担当範囲リクエストでは、デバイスディスクリプションレスポンスに記述された内容（controlURL要素の内容）に応じて、GETメソッドの対象が、"getServiceScope"となる。さらに、サービス担当範囲リクエストには、HOSTとして、"192.168.1.1"であるマスタ・プロキシ装置１０ＭのIPアドレスと、"23456"であるマスタプロキシ１１１のポート番号が記述される。

このようなサービス担当範囲リクエストは、ネットワーク３０に接続されたマスタ・プロキシ装置１０Ｍにより受信される。そして、マスタプロキシ１１１は、スレーブ・プロキシ装置１０Ｓから受信したサービス担当範囲リクエストに応じて、サービス担当範囲情報を生成し、レスポンスとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓに送信する。なお、このマスタプロキシ１１１の処理は、上述の図７のステップＳ１１３，Ｓ１１４の処理に相当する。

なお、サービス担当範囲リクエストのボディに対し、ステップＳ１２３の処理で得られるサービススキャン結果を記述するようにしてもよい。

図１２は、サービス担当範囲レスポンスの例を示す図である。

サービス担当範囲レスポンスのボディ部には、サービス担当範囲情報として、"ServiceId-A"や"ServiceId-B"などのサービスIDのリストが記述されている。このリストは、サービスIDを示す文字列を改行して列挙したリストとされる。

すなわち、マスタプロキシ１１１によって、"ServiceId-A"であるサービスIDのサービスAと、"ServiceId-B"であるサービスIDのサービスBが、スレーブプロキシ１６１のサービス担当範囲として割り当てられたことになる。

このようなサービス担当範囲レスポンスは、ネットワーク３０に接続されたスレーブ・プロキシ装置１０Ｓにより受信される。そして、スレーブ・プロキシ装置１０Ｓでは、マスタ・プロキシ装置１０Ｍから受信したサービス担当範囲レスポンス（サービス担当範囲情報）に基づいて、サービスのチューニングの準備が行われる。

ここでは、例えば、サービスAと、サービスBのストリームを受信するための準備が、スレーブ・プロキシ装置１０Ｓにより行われる。なお、このスレーブプロキシ１６１の処理は、上述の図７のステップＳ１２６の処理に相当する。また、このとき、マスタ・プロキシ装置１０Ｍにおいても、サービスのチューニングの準備が行われる（図７のＳ１１５）。

以上のようにして、スレーブ・プロキシ装置１０Ｓに対し、サービス担当範囲が割り当てられるが、図１３には、サービス担当範囲の割り当てのより具体的な例を示している。

すなわち、図１３においては、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓで受信可能な放送サービスとして、サービス１（Service-1），サービス２（Service-2），サービス３（Service-3），サービス４（Service-4），サービス５（Service-5），サービス６（Service-6），及びサービス７（Service-7）の７つのサービスがスキャンされた場合を想定する。

なお、各サービスのストリームは、サービスIDにより識別される。また、各サービスのストリームは、ブロードキャストストリームIDにより識別されるブロードキャストストリーム（BS：Broadcast Stream）で伝送される。さらに、各サービスのストリームでは、PLP IDで識別されるPLP(Physical Layer Pipe)のストリームが伝送される。

ブロードキャストストリーム１（BS-1）においては、PLP-1，PLP-2を含むサービス１のストリームと、PLP3を含むサービス２のストリームが伝送される。また、ブロードキャストストリーム２（BS-2）では、PLP-1を含むサービス３のストリームと、PLP-2，PLP-3，PLP-4を含むサービス４のストリームが伝送される。

ブロードキャストストリーム３（BS-3）においては、PLP-1を含むサービス５のストリームと、PLP-2を含むサービス６のストリームが伝送される。また、ブロードキャストストリーム４（BS-4）では、PLP-1を含むサービス７のストリームが伝送される。

マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、マスタプロキシ１１１とスレーブプロキシ１６１が受け持つサービスの担当範囲を決定する。図１３の例では、スキャンされた放送サービスのうち、サービス１乃至４が、マスタプロキシ１１１のサービス担当範囲に割り当てられ、サービス５乃至７が、スレーブプロキシ１６１のサービス担当範囲に割り当てられている。

このようなサービス担当範囲の割り当てが、マスタプロキシ１１１からスレーブプロキシ１６１に対して通知される設定管理APIにより実現されるのは、先に述べた通りである。

以上、スレーブプロキシ１６１からの存在確認に応じたマスタプロキシ１１１による設定管理APIの通知の詳細を説明した。

（２）新規のスレーブ・プロキシ装置がさらに追加される場合の例

（サービス担当範囲の割り当て処理の流れ）
次に、図１４のフローチャートを参照して、新規のスレーブ・プロキシ装置１０Ｓがさらに追加される場合における、プロキシのサービス担当範囲の割り当て処理の流れを説明する。

図１４の説明では、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１が存在するネットワーク３０に対し、新規のスレーブ・プロキシ装置１０Ｓ−２がさらに接続される場合を説明する。

ただし、以下の説明では、スレーブプロキシ１６１として、スレーブ・プロキシ装置１０Ｓ−１で稼働するものを、スレーブプロキシ１６１−１（図中では「スレーブプロキシ１」と略記する）と称する一方で、スレーブ・プロキシ装置１０Ｓ−２で稼働するものを、スレーブプロキシ１６１−２（図中では「スレーブプロキシ２」と略記する）と称して、区別するものとする。

また、図１４において、ステップＳ１９１乃至Ｓ１９６の処理は、マスタ・プロキシ装置１０Ｍにより実行される。一方で、ステップＳ２０１乃至Ｓ２０４の処理は、スレーブ・プロキシ装置１０Ｓ−１により実行され、ステップＳ２１１乃至Ｓ２１６の処理は、スレーブ・プロキシ装置１０Ｓ−２により実行される。

新規のスレーブ・プロキシ装置１０Ｓ−２が、ネットワーク３０に接続されると（Ｓ２１１）、ステップＳ２１２において、スレーブプロキシ１６１−２は、マスタプロキシ１１１の存在を確認するために、通信I/F１５２を介して、ネットワーク３０に接続されたデバイスに対し、存在確認用のメッセージを、マルチキャストで送信する。

ステップＳ１９１，Ｓ１９２において、マスタプロキシ１１１は、マルチキャストで送信されてくるメッセージに応じて、設定管理APIを生成し、ネットワーク３０を介して、スレーブ・プロキシ装置１０Ｓ−１とスレーブ・プロキシ装置１０Ｓ−２に通知（再通知）する。

ステップＳ２１３において、スレーブプロキシ１６１−２は、マスタ・プロキシ装置１０Ｍからの通知に応じて、チューナ１５１を制御して、サービスのスキャンを行う。ここでは、例えば、チューナ１５１により初期スキャン処理が行われることで、LLSとして伝送されるSLTメタデータ等から、スレーブ・プロキシ装置１０Ｓ−２により受信可能なサービスを示すサービススキャン結果が得られる。

このとき、スレーブプロキシ１６１−１が稼働するスレーブ・プロキシ装置１０Ｓ−１では、マスタ・プロキシ装置１０Ｍからの通知に応じて、サービスの再スキャンが行われ、サービススキャン結果が得られる（Ｓ２０１）。また、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍにおいても、サービスの再スキャンが行われ、サービススキャン結果が得られる（Ｓ１９３）。

ただし、先に述べたように、スレーブ・プロキシ装置１０Ｓ−２がサービススキャンを行うタイミングで、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１によるサービススキャンを行うかどうかは、任意である。

スレーブプロキシ１６１−２は、サービスのスキャン（Ｓ２１３）が終了したとき、マスタプロキシ１１１に対し、当該サービススキャン結果の通知と、サービス担当範囲の要求を行う（Ｓ２１４，Ｓ２１５）。

同様に、スレーブプロキシ１６１−１は、サービスのスキャン（Ｓ２０１）が終了したとき、マスタプロキシ１１１に対し、当該サービススキャン結果の通知と、サービス担当範囲の要求を行う（Ｓ２０２，Ｓ２０３）。

スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２により送信される、サービススキャン結果とサービス担当範囲リクエストは、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ１９４において、マスタプロキシ１１１は、サービススキャン結果に基づいて、サービス担当範囲を決定する。

ここでは、サービススキャン結果として、マスタ・プロキシ装置１０Ｍ自身のサービススキャン結果、既存のスレーブ・プロキシ装置１０Ｓ−１のサービススキャン結果、及び新規のスレーブ・プロキシ装置１０Ｓ−２のサービススキャン結果が得られる。そして、マスタプロキシ１１１では、これらのサービススキャン結果を用いて、あらかじめ定められたポリシ（規則）に従い、各FWプロキシ装置１０のサービス担当範囲を決定する。

ここでは、各FWプロキシ装置１０（マスタプロキシ１１１やスレーブプロキシ１６１−１，１６１−２）と、サービス担当範囲とを対応付けたプロキシ−サービス担当範囲データベースが生成され、記憶部１０３に記憶される。なお、ポリシの詳細については、図２１乃至図２４を参照して後述する。

ステップＳ１９５において、マスタプロキシ１１１は、スレーブプロキシ１６１−１とスレーブプロキシ１６１−２に対し、ステップＳ１９４の処理で得られるサービス担当範囲を通知する。

スレーブプロキシ１６１−２が稼働するスレーブ・プロキシ装置１０Ｓ−２では、マスタ・プロキシ装置１０Ｍからのサービス担当範囲情報に基づいて、チューナ１５１を制御して、自身の担当範囲のサービスのチューニングの準備が行われる（Ｓ２１６）。

同様に、スレーブプロキシ１６１−２が稼働するスレーブ・プロキシ装置１０Ｓ−１においても、マスタ・プロキシ装置１０Ｍからのサービス担当範囲情報に応じた自身の担当範囲のサービスのチューニングの準備が行われる（Ｓ２０４）。さらに、マスタ・プロキシ装置１０Ｍにおいても、自身の担当範囲のサービスのチューニングの準備が行われる（Ｓ１９６）。

このようにして、ネットワーク３０に接続された各FWプロキシ装置１０では、自身の担当範囲のサービスのチューニングの準備が完了して、クライアント装置２０からのDASHセグメントのリクエストに対し、ネットワーク３０内の適切なFWプロキシ装置１０が対応することになる。

ここで、図１５には、サービス担当範囲の割り当てのより具体的な例を示している。なお、図１５のブロードキャストストリームと、サービスのストリームと、PLPのストリームとの関係は、図１３と同様である。

図１５の例では、スキャンされた放送サービスのうち、サービス１，２が、マスタプロキシ１１１のサービス担当範囲に割り当てられ、サービス３乃至６が、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられ、サービス５乃至７が、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられている。

この例では、サービス５，６が、スレーブプロキシ１６１−１とスレーブプロキシ１６１−２により重複して担当範囲となっているが、例えば、サービス５，６が選択（選局）される可能性が大きい場合などに、このような担当範囲の割り当てを行うことができる。ただし、図１３の例のように、マスタプロキシ１１１やスレーブプロキシ１６１に対し、重複したサービスの担当範囲を持たせないようにしてもよい。

なお、セグメントリクエストのリダイレクションの処理は、図８に示した処理と同様であるため、ここでは、その説明は省略する。

以上、新規のスレーブ・プロキシ装置１０Ｓがさらに追加された場合における、プロキシのサービス担当範囲の割り当て処理の流れを説明した。

（設定管理APIの再通知の詳細）
次に、図１６のフローチャートを参照して、マスタプロキシ１１１による既存のスレーブプロキシ１６１−１に対する設定管理APIの再通知の詳細を説明する。すなわち、図１６のフローチャートに示した処理は、上述の図１４のステップＳ１９２の処理に対応したものとなる。

ステップＳ２２１において、UPnP/SSDPサーバ１１２は、スレーブ・プロキシ装置１０Ｓ−２から受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、NOTIFYメッセージとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓ−１に送信する。

図１７は、NOTIFYメッセージの例を示す図である。

NOTIFYメッセージにおいて、LOCATIONには、デバイスディスクリプションURLとして、"http://192.168.1.1:12345/deviceDescription.xml"が指定される。このデバイスディスクリプションURLは、XML形式のファイルのURLである。

すなわち、マスタ・プロキシ装置１０Ｍにおいて、このXML形式のファイルは、ローカルウェブサーバ１１４により処理されるので、デバイスディスクリプションURLには、マスタ・プロキシ装置１０Ｍに割り当てられたIPアドレスである"192.168.1.1"と、ローカルウェブサーバ１１４に割り当てられたポート番号である"12345"が記述されている。

図１６に戻り、ステップＳ２３１において、スレーブプロキシ１６１−１は、マスタ・プロキシ装置１０ＭからのNOTIFYメッセージ（のデバイスディスクリプションURL）に基づいて、ネットワーク３０に接続されたマスタ・プロキシ装置１０Ｍで稼働するローカルウェブサーバ１１４に対し、デバイスディスクリプションを要求する。

このデバイスディスクリプションリクエストは、HTTPリクエストであって、GETメソッドの対象のリソースとして、NOTIFYメッセージのデバイスディスクリプションURLに応じた内容が記述される。

ステップＳ２２２において、ローカルウェブサーバ１１４は、スレーブ・プロキシ装置１０Ｓ−１からのデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク３０を介してスレーブ・プロキシ装置１０Ｓ−１に送信する。なお、このデバイスディスクリプションレスポンスの内容は、上述の図１０に示した通りである。

そして、スレーブ・プロキシ装置１０Ｓ−１では、マスタ・プロキシ装置１０Ｍから受信したデバイスディスクリプションレスポンスに基づいて、マスタプロキシ１１１から、サービス担当範囲情報を取得することになる。

以上、マスタプロキシ１１１による既存のスレーブプロキシ１６１−１に対する設定管理APIの再通知の詳細を説明した。

（３）クライアント装置によるマスタプロキシの発見・接続の例

ところで、エンドユーザ宅２内のほか、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置される可能性のある、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１を発見・接続する方法としては、いくつかの方法が想定される。

例えば、クライアント装置２０において、ブラウザ２１２のインターネット接続設定のメニューにて、手動でマスタプロキシ１１１の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"という名前を持つエントリを探して、そこからプロキシ設定スクリプトをダウンロードする方法が実装されている。

マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１の発見においても、同様の方法を用いることができる。本技術では、クライアント装置２０が、ネットワーク３０において、マスタプロキシ１１１が稼働しているマスタ・プロキシ装置１０Ｍを発見し、当該マスタプロキシ１１１がリクエストを待ち受けるIPアドレスとポート番号（以下、プロキシ待ち受けアドレス/ポートともいう）を取得する方式を提案する。

そのためには、クライアント装置２０では、マスタプロキシ１１１に対し、プロキシ待ち受けアドレス/ポートを問い合わせるためのWeb APIを認識する必要がある。つまり、このWeb APIは、サービスを呼び出すためのインターフェースであると言える。

ここで、マスタプロキシ１１１の発見に、ユニバーサルプラグアンドプレイ(UPnP)を利用する場合、マスタプロキシ１１１の発見と、機能の公開には、SSDPが用いられる。

一般に、SSDPにおいては、公開されるサービスを発見する際にやりとりされるデバイスディスクリプションとして、デバイスが提供可能な機能や情報が記述されたXML形式のファイルが用いられる。このファイルには、対象のデバイスそのものについて記述したデバイスディスクリプションと、対象のデバイス上に実装された各サービスが持つアクションとしてのサービスディスクリプションとが記述される。

本技術では、マスタプロキシ１１１のディスクリプション（例えばサービスディスクリプション）に、当該マスタプロキシ１１１がリクエストを待ち受けるIPアドレスとポート番号（プロキシ待ち受けアドレス/ポート）を返答するWeb APIのURLを記述できるようにする。

また、本技術では、ATSC3.0サービス等の放送サービスに対応するマスタプロキシ１１１のサービスを発見するためのプロトコルを追加することにより、放送サービスを実装していない一般のクライアント装置２０で、ブラウザ２１２のプロキシとして、プロキシ待ち受けアドレス/ポートを設定できるようにする。

すなわち、放送サービスを実装していない一般のクライアント装置２０（スマートフォンやタブレット型コンピュータ等の一般エンドデバイス）のブラウザ２１２で、あるスクリプト（Web API）を立ち上げると、放送サービスに対応するサーバであるマスタ・プロキシ装置１０Ｍを発見し、そこで稼働するマスタプロキシ１１１のプロキシ待ち受けアドレス/ポートを、当該ブラウザ２１２のプロキシとして設定できるようにする。

以下、このような、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１の発見と、マスタプロキシ１１１のプロキシ待ち受けアドレス/ポートの取得のシーケンス（プロキシの発見・接続処理）を説明する。

なお、ここでは、ネットワーク上のデバイスの探索や応答を行うプロトコルとして、SSDPを一例に説明したが、DIAL(Discovery and Launch)等の他のプロトコルを用いることでも、同様の機能を実現することができる。DIALは、ネットワーク上にあるDIAL対応のデバイスをUPnPにより発見し、指定されたアプリケーションを起動させるプロトコルである。

（マスタプロキシ設定処理）
図１８は、図８のステップＳ１０２の処理に対応するマスタプロキシ設定処理の流れを説明するフローチャートである。

なお、図１８の説明では、ネットワーク３０に接続されるマスタ・プロキシ装置１０Ｍには、IPアドレスとして、"192.168.1.1"が割り当てられているものとする。また、このマスタ・プロキシ装置１０Ｍで稼働するサービスのうち、UPnP/SSDPサーバ１１２には、"12345"であるポート番号、プロキシアプリマネージャ１１３には、"23456"であるポート番号、マスタプロキシ１１１には、"34567"であるポート番号がそれぞれ割り当てられているものとする。

また、図１８において、ステップＳ２８１乃至Ｓ２８２の処理と、ステップＳ２９１の処理は、マスタ・プロキシ装置１０Ｍにより実行される。一方で、ステップＳ２７１乃至Ｓ２７４の処理は、クライアント装置２０により実行される。

ステップＳ２７１において、アプリケーション２１１は、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１の存在を確認するために、通信I/F２０１を介して、ネットワーク３０に接続されたデバイス（サーバ）に対し、M-SEARCHリクエストを、マルチキャストで送信する。

ステップＳ２７１の処理で、クライアント装置２０により送信されるM-SEARCHリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ２８１において、UPnP/SSDPサーバ１１２は、クライアント装置２０から受信したM-SEARCHリクエストに応じて、デバイスディスクリプションURLを生成し、M-SEARCHレスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。

ステップＳ２８１の処理で、マスタ・プロキシ装置１０Ｍにより送信されるM-SEARCHレスポンスは、M-SEARCHリクエストを送信したクライアント装置２０により受信される。

ステップＳ２７２において、アプリケーション２１１は、マスタ・プロキシ装置１０Ｍから受信したM-SEARCHレスポンス（のデバイスディスクリプションURL）に基づいて、UPnP/SSDPサーバ１１２に対し、デバイスディスクリプションを要求する。

ステップＳ２７２の処理で、クライアント装置２０により送信されるデバイスディスクリプションリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。

ステップＳ２８２において、UPnP/SSDPサーバ１１２（ローカルウェブサーバ１１４）は、クライアント装置２０から受信したデバイスディスクリプションリクエストに応じて、デバイスディスクリプションを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に送信する。

このデバイスディスクリプションレスポンスには、図１０に示したように、serviceList要素に記述された２つのservice要素のうち、１つ目のservice要素の内容が記述される。

すなわち、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を呼び出すための情報である。

ステップＳ２８２の処理で、マスタ・プロキシ装置１０Ｍにより送信されるデバイスディスクリプションレスポンスは、デバイスディスクリプションリクエストを送信したクライアント装置２０により受信される。

ステップＳ２７３において、アプリケーション２１１は、マスタ・プロキシ装置１０Ｍから受信したデバイスディスクリプションレスポンス（のプロキシ待ち受けアドレス/ポート取得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)）により、プロキシ自動構成スクリプトファイルを書き換える。

すなわち、クライアント装置２０では、アプリケーション２１１により、プロキシ自動構成スクリプトファイルが、プロキシ待ち受けアドレス/ポートにより書き換えられ、ブラウザ２１２が、起動（再起動）される。そして、当該ブラウザ２１２が参照するプロキシ自動構成スクリプトファイルにより、マスタプロキシ１１１のIPアドレスとポート番号の設定（自動設定）が行われる。

これにより、クライアント装置２０において、ブラウザ２１２は、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１にアクセスすることが可能となる。

以上、マスタプロキシ設定処理の流れを説明した。

＜４．マスタプロキシとスレーブプロキシの実装例＞

まず、ここでは、マスタプロキシ１１１が、サービス担当範囲を決定する際のポリシ（規則）の詳細について説明する。

（１）機械的なサービス担当範囲の割り当ての例

図２１は、機械的なサービス担当範囲の割り当ての例を示す図である。

図２１においては、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２で受信可能なサービスとして、サービス１乃至１９の19個のサービスがスキャンされた場合を想定する。

ブロードキャストストリーム１（BS-1）においては、サービス１乃至４のストリームが伝送される。また、ブロードキャストストリーム２（BS-2）では、サービス５乃至７のストリームが伝送される。さらに、ブロードキャストストリーム３（BS-3）では、サービス８乃至１０のストリームが伝送される。

また、ブロードキャストストリーム４（BS-4）においては、サービス１１乃至１４のストリームが伝送される。さらに、ブロードキャストストリーム５（BS-5）では、サービス１５乃至１９のストリームが伝送される。

マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、あらかじめ定められたポリシに従い、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２が受け持つサービスの担当範囲を決定する。

図２１の例では、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２に対し、ブロードキャストストリーム単位（例えば6MHzの周波数帯域の単位）で、機械的にサービス担当範囲が割り当てられている。

すなわち、スキャンされた放送サービスのうち、ブロードキャストストリーム１（BS-1）のサービス１乃至４が、マスタプロキシ１１１のサービス担当範囲に割り当てられる。また、ブロードキャストストリーム２（BS-2）のサービス５乃至７と、ブロードキャストストリーム３（BS-3）のサービス８乃至１０が、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられる。

また、ブロードキャストストリーム４（BS-4）のサービス１１乃至１４と、ブロードキャストストリーム５（BS-5）のサービス１５乃至１９が、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられる。

なお、図２１の例では、ブロードキャストストリーム単位で、機械的にサービス担当範囲を割り当てる場合を説明したが、機械的にサービス担当範囲を割り当てる単位としては、ブロードキャストストリーム単位に限らず、例えば、サービス単位などの他の単位であってもよい。

このように、マスタプロキシ１１１が、サービス担当範囲を決定する際のポリシとしては、マスタプロキシ１１１とスレーブプロキシ１６１に対し、ブロードキャストストリーム単位やサービス単位などの所定の単位で、機械的にサービス担当範囲を割り当てる規則を用いることができる。

（２）サービスのアクセス頻度に応じた担当範囲の割り当ての例

図２２は、サービスのアクセス頻度に応じた担当範囲の割り当ての例を示す図である。

図２２においては、図２１と同様に、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２で受信可能なサービスとして、サービス１乃至１９の19個のサービスがスキャンされた場合を想定する。また、各ブロードキャストストリームで伝送されるサービスのストリームについても、図２１と同様とされる。

マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、あらかじめ定められたポリシに従い、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２が受け持つサービスの担当範囲を決定する。

図２２の例では、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２に対し、エンドユーザのコンテンツの視聴履歴を考慮に入れて、サービス担当範囲が割り当てられている。

ここで、図２２においては、サービスごとのアクセス頻度を表したグラフ（図中のハッチングが施された四角）が示されており、図中の横方向の幅が広いグラフのサービスほど、アクセスの頻度が高いサービスであることを表している。例えば、ブロードキャストストリーム１（BS-1）においては、サービス１，３のアクセス頻度が高く、サービス４のアクセス頻度が低くなる。また、サービス２のアクセス頻度は、それらのサービスの中間の頻度となる。

このようなサービスごとのアクセス頻度を考慮に入れることで、スキャンされた放送サービスのうち、ブロードキャストストリーム１（BS-1）のサービス１乃至４と、ブロードキャストストリーム２（BS-2）のサービス５，６は、マスタプロキシ１１１のサービス担当範囲に割り当てられる。

また、ブロードキャストストリーム２（BS-2）のサービス７と、ブロードキャストストリーム３（BS-3）のサービス８，１０と、ブロードキャストストリーム４（BS-4）のサービス１１，１２と、ブロードキャストストリーム５（BS-5）のサービス１５は、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられる。

さらに、ブロードキャストストリーム３（BS-3）のサービス９と、ブロードキャストストリーム４（BS-4）のサービス１３，１４と、ブロードキャストストリーム５（BS-5）のサービス１６乃至１９は、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられる。

この例では、ブロードキャストストリーム１のサービス１，３と、ブロードキャストストリーム２のサービス６と、ブロードキャストストリーム４のサービス１１，１２と、ブロードキャストストリーム５のサービス１５，１７，１９などのアクセス頻度が高いサービスが、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２に対し、ほぼ均等に割り当てられ、サービスのアクセス頻度に応じた負荷分散がなされている。

このように、マスタプロキシ１１１が、サービス担当範囲を決定する際のポリシとしては、マスタプロキシ１１１とスレーブプロキシ１６１に対し、アクセス頻度の高いサービスが、優先的に負荷分散されるように、サービス担当範囲を割り当てる規則を用いることができる。

（３）サービスのアクセス頻度に応じたBSごとの担当範囲の割り当ての例

図２３は、サービスのアクセス頻度に応じたブロードキャストストリーム（BS）ごとの担当範囲の割り当ての例を示す図である。

図２３においては、図２１及び図２２と同様に、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２で受信可能なサービスとして、サービス１乃至１９の19個のサービスがスキャンされた場合を想定する。また、各ブロードキャストストリームで伝送されるサービスのストリームについても、図２１及び図２２と同様とされる。

マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、あらかじめ定められたポリシに従い、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２が受け持つサービスの担当範囲を決定する。

図２３の例では、マスタプロキシ１１１と、スレーブプロキシ１６１−１，１６１−２に対し、エンドユーザのコンテンツの視聴履歴を考慮に入れて、サービス担当範囲が割り当てられている。

ここで、図２３においては、ブロードキャストストリーム（BS）ごとのアクセス頻度（サービスのアクセス頻度の合計）を表したグラフ（図中のハッチングが施された四角）が示されており、図中の横方向の幅が広いグラフのブロードキャストストリームほど、アクセスの頻度が高いブロードキャストストリームであることを表している。例えば、ブロードキャストストリーム１（BS-1）乃至５（BS-5）のうち、ブロードキャストストリーム５が最もアクセス頻度高くなり、ブロードキャストストリーム１，４，２，３の順に、アクセス頻度が低くなる。

このようなブロードキャストストリームごとのアクセス頻度を考慮に入れることで、スキャンされた放送サービスのうち、ブロードキャストストリーム２（BS-2）のサービス５乃至７と、ブロードキャストストリーム３（BS-3）のサービス８乃至１０は、マスタプロキシ１１１のサービス担当範囲に割り当てられる。

また、ブロードキャストストリーム１（BS-1）のサービス１乃至４と、ブロードキャストストリーム４（BS-4）のサービス１１乃至１４は、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられる。さらに、ブロードキャストストリーム５（BS-5）のサービス１５乃至１９は、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられる。

この例では、アクセス頻度が最も高いブロードキャストストリーム５のみが、スレーブプロキシ１６１−２に対して割り当てられ、残りのブロードキャストストリーム１乃至４が、マスタプロキシ１１１とスレーブプロキシ１６１−１に対し、ほぼ均等に割り当てられ、ブロードキャストストリームのアクセス頻度に応じた負荷分散がなされている。

このように、マスタプロキシ１１１が、サービス担当範囲を決定する際のポリシとしては、マスタプロキシ１１１とスレーブプロキシ１６１に対し、アクセス頻度の高いブロードキャストストリームが、優先的に負荷分散されるように、サービス担当範囲を割り当てる規則を用いることができる。

すなわち、ここでは、同一のブロードキャストストリームIDのブロードキャストストリーム内で伝送されるサービス群のストリームのデータは、同時に処理（取得）できるため、ブロードキャストストリームのアクセス頻度に応じた負荷分散を行うことで、ストリームのデータを同時に取得できるサービスが集約されることになる。そして、ストリームのデータを同時に取得できるサービス群がまとめられることで、例えば、チャネルザッピングの高速化を図ることができる。

また、例えば、図２４に示すように、特定のブロードキャストストリームのアクセス頻度が、突出して高い場合には、それに対応した適切な負荷分散がなされるようにしてもよい。

この例では、アクセス頻度が突出して高いブロードキャストストリーム５が、スレーブプロキシ１６１−１とスレーブプロキシ１６１−２（の２つのFWプロキシ装置１０）に対して割り当てられ、残りのブロードキャストストリーム１乃至４が、マスタプロキシ１１１に対して割り当てられている。これにより、特定のブロードキャストストリームのアクセス頻度が、突出して高い場合でも、適切な負荷分散がなされている。

以上、サービス担当範囲を決定する際のポリシについて説明したが、これらのポリシは一例であって、最適な負荷分散を行うことが可能なサービス担当範囲を割り当てることができる規則であれば、他のポリシを用いるようにしてもよい。

また、これらのポリシのうち、どのポリシを使用するかは、エンドユーザが設定することができる。例えば、ポリシの設定画面が、FWプロキシ装置１０又はクライアント装置２０などに提示されるようにすることで、エンドユーザは、当該設定画面（のユーザインターフェース（UI：User Interface））を操作して、所望のポリシを設定することができる。なお、ポリシの設定は、エンドユーザの操作に限らず、例えば、過去のデータを蓄積しておき、機械学習などの手法を用いて設定されるようにしてもよい。

なお、各FWプロキシ装置１０が近い位置に存在する場合には、FWプロキシ装置１０ごとのサービススキャン結果は同一になる可能性が高いが、運用によっては、各FWプロキシ装置１０が離れた位置に存在する場合もあり、そのような場合には、FWプロキシ装置１０ごとのサービススキャン結果は同一にならない可能性もあるので、そのような位置関係を考慮に入れるようにしてもよい。

また、エンドユーザのコンテンツの視聴履歴情報は、マスタ・プロキシ装置１０Ｍで管理するほか、スレーブ・プロキシ装置１０Ｓや専用のサーバ（視聴履歴サーバ）を設置して、それらが管理するようにしてもよい。マスタ・プロキシ装置１０Ｍ以外の他のサーバが管理する場合、マスタプロキシ１１１は、サービス担当範囲の決定時に、ネットワーク３０に接続された他のサーバから、視聴履歴情報を取得することになる。

また、上述した説明では、マスタプロキシ１１１に対しても、サービス担当範囲を割り当てていたが、マスタプロキシ１１１にはサービス担当範囲を割り当てずに、サービス担当範囲の割り当て処理や、リクエストリダイレクション処理などの処理だけが行われるようにしてもよい。この場合、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍでは、コンテンツのストリームを受信する必要がないため、チューナを有しない専用のサーバなどを用いることができる。

（４）マスタプロキシとスレーブプロキシのトポロジの例

次に、図２５及び図２６を参照して、ネットワーク３０に接続されるFWプロキシ装置１０とクライアント装置２０のトポロジ（接続形態）を説明する。

（家庭内LAN等の場合のトポロジ）
図２５は、ネットワーク３０が、家庭内LAN等の場合におけるトポロジの例を示す図である。

図２５においては、エンドユーザ宅２内の家庭内LAN等のネットワーク３０に、マスタ・プロキシ装置１０Ｍ、スレーブ・プロキシ装置１０Ｓ−１、スレーブ・プロキシ装置１０Ｓ−２、クライアント装置２０−１、クライアント装置２０−２、及びクライアント装置２０−３が接続されている。

また、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１によって、スレーブ・プロキシ装置１０Ｓ−１で稼働するスレーブプロキシ１６１−１と、スレーブ・プロキシ装置１０Ｓ−２で稼働するスレーブプロキシ１６１−２に対し、サービス担当範囲が割り当てられている。

すなわち、マスタプロキシ１１１には、サービス担当範囲として、サービス１乃至１４が割り当てられている。同様に、サービス担当範囲として、スレーブプロキシ１６１−１には、サービス１５乃至１９が割り当てられ、スレーブプロキシ１６１−２には、サービス１５乃至１９が割り当てられている。なお、このサービス担当範囲の割り当ては、図２４に示したブロードキャストストリームごとのアクセス頻度に応じた割り当てと同様である。

ここで、クライアント装置２０−１において、サービス７で配信されるコンテンツの再生が指示された場合、サービス７のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス７のDASHセグメントのリクエストを、自身（マスタプロキシ１１１）が担当することを決定する。

そして、マスタ・プロキシ装置１０Ｍでは、放送経由で配信される、サービス７のDASHセグメントファイルが処理され、クライアント装置２０−１に送信される。これにより、クライアント装置２０−１においては、サービス７で配信されるコンテンツが再生される。

また、クライアント装置２０−２において、サービス１５で配信されるコンテンツの再生が指示された場合、サービス１５のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス１５のDASHセグメントのリクエストを、スレーブプロキシ１６１−１（又はスレーブプロキシ１６１−２）が担当することを決定する。

そして、マスタプロキシ１１１は、スレーブプロキシ１６１−１に対し、サービス１５のDASHセグメントのリクエストをリダイレクトする。スレーブ・プロキシ装置１０Ｓ−１では、放送経由で配信される、サービス１５のDASHセグメントファイルが処理され、クライアント装置２０−２に送信される。これにより、クライアント装置２０−２においては、サービス１５で配信されるコンテンツが再生される。

また、クライアント装置２０−３において、サービス１５で配信されるコンテンツの再生が指示された場合、サービス１５のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス１５のDASHセグメントのリクエストを、スレーブプロキシ１６１−２（又はスレーブプロキシ１６１−１）が担当することを決定する。

そして、マスタプロキシ１１１は、スレーブプロキシ１６１−２に対し、サービス１５のDASHセグメントのリクエストをリダイレクトする。スレーブ・プロキシ装置１０Ｓ−２では、放送経由で配信される、サービス１５のDASHセグメントファイルが処理され、クライアント装置２０−３に送信される。これにより、クライアント装置２０−３においては、サービス１５で配信されるコンテンツが再生される。

なお、図２５においては、ネットワーク３０が、エンドユーザ宅２内の家庭内LANである場合を説明したが、上述したように、マスタ・プロキシ装置１０Ｍやスレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２を、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域（広範囲なLANのセグメント）をカバーするようにしてもよい。

すなわち、例えば、マスタ・プロキシ装置１０Ｍやスレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２が、ケーブルオペレータのヘッドエンドに設置される場合、テレビ受像機やパーソナルコンピュータ等のクライアント装置２０−１乃至２０−３は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。

また、例えば、マスタ・プロキシ装置１０Ｍやスレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２が、モバイル網の基地局に設置される場合、スマートフォンやタブレット型コンピュータ等のクライアント装置２０−１乃至２０−３は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイスとなる。

（車車間通信の場合のトポロジ）
図２６は、ネットワーク３０が、車両間の無線通信の場合におけるトポロジの例を示す図である。

図２６においては、自動車間の無線通信によるネットワーク３０に、各自動車に搭載された車載機器としてのマスタ・プロキシ装置１０Ｍ、スレーブ・プロキシ装置１０Ｓ−１、及びスレーブ・プロキシ装置１０Ｓ−２が接続されている。また、このネットワーク３０には、エンドユーザにより所持されている、スマートフォンやヘッドマウントディスプレイなどのクライアント装置２０−４乃至２０−１２が接続されている。

なお、このような状況としては、例えば、あるイベント会場の駐車場に、多数の自動車が停車している場合に、イベントの参加者がデバイスを所持しているときなどが想定される。

また、ある自動車内のマスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１によって、他の自動車内のスレーブ・プロキシ装置１０Ｓ−１で稼働するスレーブプロキシ１６１−１と、さらに他の自動車内のスレーブ・プロキシ装置１０Ｓ−２で稼働するスレーブプロキシ１６１−２に対し、サービス担当範囲が割り当てられている。

すなわち、マスタプロキシ１１１には、サービス担当範囲として、サービス１乃至４が割り当てられている。同様に、サービス担当範囲として、スレーブプロキシ１６１−１には、サービス５乃至１０が割り当てられ、スレーブプロキシ１６１−２には、サービス１１乃至１９が割り当てられている。

ここで、クライアント装置２０−５において、サービス１で配信されるコンテンツの再生が指示された場合、サービス１のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス１のDASHセグメントのリクエストを、自身（マスタプロキシ１１１）が担当することを決定する。

そして、マスタ・プロキシ装置１０Ｍでは、放送経由で配信される、サービス１のDASHセグメントファイルが処理され、クライアント装置２０−５に送信される。これにより、クライアント装置２０−５においては、サービス１で配信されるコンテンツが再生される。

また、クライアント装置２０−８において、サービス１０で配信されるコンテンツの再生が指示された場合、サービス１０のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス１０のDASHセグメントのリクエストを、スレーブプロキシ１６１−１が担当することを決定する。

そして、マスタプロキシ１１１は、スレーブプロキシ１６１−１に対し、サービス１０のDASHセグメントのリクエストをリダイレクトする。スレーブ・プロキシ装置１０Ｓ−１では、放送経由で配信される、サービス１０のDASHセグメントファイルが処理され、クライアント装置２０−８に送信される。これにより、クライアント装置２０−８においては、サービス１０で配信されるコンテンツが再生される。

また、クライアント装置２０−１１において、サービス１５で配信されるコンテンツの再生が指示された場合、サービス１５のDASHセグメントのリクエストは、マスタ・プロキシ装置１０Ｍに送信される。マスタプロキシ１１１は、プロキシ−サービス担当範囲データベースを参照して、サービス１５のDASHセグメントのリクエストを、スレーブプロキシ１６１−２が担当することを決定する。

そして、マスタプロキシ１１１は、スレーブプロキシ１６１−２に対し、サービス１５のDASHセグメントのリクエストをリダイレクトする。スレーブ・プロキシ装置１０Ｓ−２では、放送経由で配信される、サービス１５のDASHセグメントファイルが処理され、クライアント装置２０−１１に送信される。これにより、クライアント装置２０−１１においては、サービス１５で配信されるコンテンツが再生される。

以上、マスタプロキシ１１１とスレーブプロキシ１６１の実装例について説明した。

＜５．変形例＞

（通信経由の配信）
上述した図１の伝送システム１においては、コンテンツのストリームが、放送伝送路６０を介して放送経由で配信される場合を説明したが、コンテンツのストリームは、インターネット等の通信伝送路を介して通信経由で配信されるようにしてもよい。

図２７には、伝送システムの他の構成例を示している。図２７の伝送システム６においては、図１の伝送システム１と比べて、送信側に、放送系の放送サーバ４０に加えて、通信系の通信サーバ７０が設けられている点が異なっている。

FWプロキシ装置１０は、放送伝送路６０を介して送信される放送波を受信する受信機能とともに、インターネット８０に接続可能な通信機能（通信I/F（不図示））も有している。これにより、FWプロキシ装置１０は、インターネット８０を介して、通信サーバ７０と相互に接続され、通信を行うことが可能である。

FWプロキシ装置１０は、ネットワーク３０に接続されたクライアント装置２０からのリクエストを、インターネット８０に接続された通信サーバ７０に送信する。また、FWプロキシ装置１０は、インターネット８０を介して、通信サーバ７０から送信されてくるコンテンツのストリームを受信し、ネットワーク３０に接続されたクライアント装置２０に送信（転送）する。

ここで、上述したように、ネットワーク３０に接続されるFWプロキシ装置１０−１乃至１０−Ｎにおいては、いずれかのFWプロキシ装置１０が、マスタプロキシとして機能し、それ以外のFWプロキシ装置１０が、スレーブプロキシとして機能するマスタ・スレーブ関係を有している。そして、FWプロキシ装置１０−１乃至１０−Ｎが、マスタ・スレーブ関係を有することで、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍによって、各FWプロキシ装置１０に対し、サービスの担当範囲が割り当てられるのは、先に述べた通りである。

これにより、ネットワーク３０に接続されたクライアント装置２０は、エンドユーザの操作などに応じて、FWプロキシ装置１０（マスタ・プロキシ装置１０Ｍ、又はスレーブ・プロキシ装置１０Ｓ）を介して、放送経由又は通信経由で配信されるコンテンツを再生することができる。

通信サーバ７０は、例えば、放送局などの放送事業者やその他の事業者により提供されるサーバであって、インターネット８０に接続される。

通信サーバ７０は、FWプロキシ装置１０からのリクエストに応じて、番組やCM等のコンテンツのファイルや制御情報を処理し、その結果得られるデータを、インターネット８０を介して送信（ストリーミング配信）する。

なお、放送サーバ４０や通信サーバ７０は、番組等のコンテンツだけでなく、例えば、アプリケーションなどを配信するようにしてもよい。すなわち、伝送システム６においては、アプリケーションが放送経由又は通信経由で配信され、FWプロキシ装置１０を介して、クライアント装置２０により受信される。

また、伝送システム１（図１）と、伝送システム６（図２７）においては、FWプロキシ装置１０により、少なくとも、放送経由で配信されるコンテンツのストリームが処理される構成を示したが、送信側に、通信系の通信サーバ７０のみを設け、FWプロキシ装置１０では、通信経由で配信されるコンテンツのストリームのみが処理されるようにしてもよい。この場合、クライアント装置２０は、通信経由で配信されるコンテンツのみを再生することになる。

（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。

また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV：Common Antenna TeleVision）等の有線放送などの規格に適用することができる。

（その他の変形例）
上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。

また、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１００２や記録部１００８に、あらかじめインストールしておくことができる。

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

また、本技術は、以下のような構成をとることができる。

（１）
複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備える
情報処理装置。
（２）
前記処理部は、各プロキシが稼働する情報処理装置にて受信可能なサービスを示すサービススキャン結果に基づいて、前記ポリシに応じたサービスの担当範囲を決定する
（１）に記載の情報処理装置。
（３）
前記処理部は、各プロキシが稼働する情報処理装置の能力属性に基づいて、前記ポリシに応じたサービスの担当範囲を決定する
（２）に記載の情報処理装置。
（４）
前記ポリシは、各プロキシに対し、ストリーム単位又はサービス単位で、サービスの担当範囲を割り当てる規則である
（２）又は（３）に記載の情報処理装置。
（５）
前記ポリシは、エンドユーザのコンテンツの視聴履歴に基づいて、サービスの担当範囲を割り当てる規則である
（２）乃至（４）のいずれかに記載の情報処理装置。
（６）
前記処理部は、アクセス頻度の高いサービスが、優先的に負荷分散されるように、サービスの担当範囲を決定する
（５）に記載の情報処理装置。
（７）
前記処理部は、コンテンツのストリームのデータを同時に取得できるサービスが集約されるように、サービスの担当範囲を決定する
（５）に記載の情報処理装置。
（８）
前記処理部は、アクセス頻度の高いストリームが、優先的に負荷分散されるように、サービスの担当範囲を決定する
（７）に記載の情報処理装置。
（９）
前記処理部は、前記スレーブプロキシごとに、各スレーブプロキシの担当するサービスを示す担当範囲情報を通知する
（２）乃至（８）のいずれかに記載の情報処理装置。
（１０）
前記処理部は、前記スレーブプロキシにより、前記担当範囲情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記担当範囲情報を、前記スレーブプロキシに通知する
（９）に記載の情報処理装置。
（１１）
前記処理部は、
各プロキシと、サービスの担当範囲とを対応付けたデータベースを生成し、
前記クライアント装置から、サービスのリクエストを受けた場合、前記データベースを参照して、当該サービスを担当するプロキシに対し、当該サービスのリクエストがリダイレクションされるようにする
（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）
前記ポリシは、エンドユーザにより設定される
（１）乃至（１１）のいずれかに記載の情報処理装置。
（１３）
前記マスタプロキシが稼働する情報処理装置と、前記スレーブプロキシが稼働する他の情報処理装置では、自身のサービスの担当範囲が決定した場合に、自身の担当範囲に応じたサービスを受信するための準備が行われる
（１）乃至（１２）のいずれかに記載の情報処理装置。
（１４）
前記スレーブプロキシが稼働する他の情報処理装置は、前記ネットワーク上に複数設置されている
（１）乃至（１３）のいずれかに記載の情報処理装置。
（１５）
放送波を受信する受信部をさらに備え、
前記処理部は、放送経由で配信される前記コンテンツのストリームを、前記ネットワークを介して前記クライアント装置に送信する
（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）
インターネット上のサーバと通信を行う通信部をさらに備え、
前記処理部は、通信経由で配信される前記コンテンツのストリームを、前記ネットワークを介して前記クライアント装置に送信する
（１５）に記載の情報処理装置。
（１７）
情報処理装置の情報処理方法において、
前記情報処理装置が、
複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定するステップを含む
情報処理方法。
（１８）
マスタプロキシが稼働する第１の情報処理装置と、スレーブプロキシが稼働する１又は複数の第２の情報処理装置と、１又は複数のクライアント装置とが、ネットワークを介して接続された情報処理システムにおいて、
前記第１の情報処理装置は、
複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記スレーブプロキシに対する前記マスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備え、
前記第２の情報処理装置は、
複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記マスタプロキシに対する前記スレーブプロキシとして機能し、前記マスタプロキシにより決定された担当範囲に応じたサービスにより配信されるコンテンツのストリームを処理する処理部を備える
情報処理システム。

１，６ 伝送システム， １０−１乃至１０−Ｍ，１０ FWプロキシ装置，１０Ｍ マスタ・プロキシ装置，１０Ｓ スレーブ・プロキシ装置， ２０−１乃至２０−Ｍ，２０ クライアント装置， ３０ ネットワーク， ４０ 放送サーバ， ５０ 送信所， ６０ 放送伝送路， ７０ 通信サーバ， ８０ インターネット， １００ 処理部， １０１ チューナ， １０２ 通信I/F， １０３ 記憶部， １１１ マスタプロキシ， １１２ UPnP/SSDPサーバ， １１３ プロキシアプリマネージャ， １１４ ローカルウェブサーバ， １１５ SLS処理系， １５０ 処理部， １５１ チューナ， １５２ 通信I/F， １５３ 記憶部， １６１ スレーブプロキシ， １６２ SLS処理系， ２００ 処理部， ２０１ 通信I/F， ２０２ 表示部， ２０３ スピーカ， ２１１ アプリケーション， ２１２ ブラウザ， １０００ コンピュータ， １００１ CPU

Claims (18)

1. 複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備える
   情報処理装置。
2. 前記処理部は、各プロキシが稼働する情報処理装置にて受信可能なサービスを示すサービススキャン結果に基づいて、前記ポリシに応じたサービスの担当範囲を決定する
   請求項１に記載の情報処理装置。
3. 前記処理部は、各プロキシが稼働する情報処理装置の能力属性に基づいて、前記ポリシに応じたサービスの担当範囲を決定する
   請求項２に記載の情報処理装置。
4. 前記ポリシは、各プロキシに対し、ストリーム単位又はサービス単位で、サービスの担当範囲を割り当てる規則である
   請求項２に記載の情報処理装置。
5. 前記ポリシは、エンドユーザのコンテンツの視聴履歴に基づいて、サービスの担当範囲を割り当てる規則である
   請求項２に記載の情報処理装置。
6. 前記処理部は、アクセス頻度の高いサービスが、優先的に負荷分散されるように、サービスの担当範囲を決定する
   請求項５に記載の情報処理装置。
7. 前記処理部は、コンテンツのストリームのデータを同時に取得できるサービスが集約されるように、サービスの担当範囲を決定する
   請求項５に記載の情報処理装置。
8. 前記処理部は、アクセス頻度の高いストリームが、優先的に負荷分散されるように、サービスの担当範囲を決定する
   請求項７に記載の情報処理装置。
9. 前記処理部は、前記スレーブプロキシごとに、各スレーブプロキシの担当するサービスを示す担当範囲情報を通知する
   請求項２に記載の情報処理装置。
10. 前記処理部は、前記スレーブプロキシにより、前記担当範囲情報を取得するためのAPI(Application Programming Interface)が実行された場合に、前記担当範囲情報を、前記スレーブプロキシに通知する
    請求項９に記載の情報処理装置。
11. 前記処理部は、
    各プロキシと、サービスの担当範囲とを対応付けたデータベースを生成し、
    前記クライアント装置から、サービスのリクエストを受けた場合、前記データベースを参照して、当該サービスを担当するプロキシに対し、当該サービスのリクエストがリダイレクションされるようにする
    請求項１に記載の情報処理装置。
12. 前記ポリシは、エンドユーザにより設定される
    請求項１に記載の情報処理装置。
13. 前記マスタプロキシが稼働する情報処理装置と、前記スレーブプロキシが稼働する他の情報処理装置では、自身のサービスの担当範囲が決定した場合に、自身の担当範囲に応じたサービスを受信するための準備が行われる
    請求項１に記載の情報処理装置。
14. 前記スレーブプロキシが稼働する他の情報処理装置は、前記ネットワーク上に複数設置されている
    請求項１に記載の情報処理装置。
15. 放送波を受信する受信部をさらに備え、
    前記処理部は、放送経由で配信される前記コンテンツのストリームを、前記ネットワークを介して前記クライアント装置に送信する
    請求項１に記載の情報処理装置。
16. インターネット上のサーバと通信を行う通信部をさらに備え、
    前記処理部は、通信経由で配信される前記コンテンツのストリームを、前記ネットワークを介して前記クライアント装置に送信する
    請求項１５に記載の情報処理装置。
17. 情報処理装置の情報処理方法において、
    前記情報処理装置が、
    複数のサービスごとに配信されるコンテンツのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定するステップを含む
    情報処理方法。
18. マスタプロキシが稼働する第１の情報処理装置と、スレーブプロキシが稼働する１又は複数の第２の情報処理装置と、１又は複数のクライアント装置とが、ネットワークを介して接続された情報処理システムにおいて、
    前記第１の情報処理装置は、
    複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記スレーブプロキシに対する前記マスタプロキシとして機能し、各プロキシに対して、あらかじめ定められたポリシに応じたサービスの担当範囲を決定する処理部を備え、
    前記第２の情報処理装置は、
    複数のサービスごとに配信されるコンテンツのストリームを受信して、前記ネットワークに接続された前記クライアント装置に送信するプロキシであって、前記マスタプロキシに対する前記スレーブプロキシとして機能し、前記マスタプロキシにより決定された担当範囲に応じたサービスにより配信されるコンテンツのストリームを処理する処理部を備える
    情報処理システム。

Images