JP7473025B2 - コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム - Google Patents

Description

本開示は、宛先が異なり、かつ、コンテンツ識別子が同一である複数のユニキャストトラヒックの、ユニキャストからマルチキャストへ、および、マルチキャストからユニキャストへの変換方法に関する。

インターネットのトラヒック量は、年々増加傾向にあり、特に映像トラヒックの増加が著しい。インターネットにおけるトラヒック量の増加は、通信事業者のネットワークを経由するトラヒックの増加を意味する。これに対し、コンテンツ配信事業者および通信事業者は、輻輳などが生じないよう、設備投資を行わなければならない。

設備投資を抑制するために、ネットワークにおける伝送帯域を効率良く利用する事が挙げられる。

具体的な方法として、マルチキャストがある（非特許文献１）。マルチキャストは、同一のコンテンツを多数のエンドユーザに配信する場合に有効で、各エンドユーザ宛てにユニキャストで配信する場合と比較して消費する伝送帯域が少ない。受信するエンドユーザが多いほどその効果は高まるため、多数のエンドユーザによる受信が見込まれるコンテンツに向いている。

この他、監視カメラネットワークにおいて、監視カメラからユニキャストで送信された監視画像を、マルチキャストに変換し、監視拠点に送信する技術も存在する（特許文献１）。

また、マルチキャストで送信されたコンテンツを、ユニキャストに変換する技術も存在する。例えば、特許文献２では、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）によるアクセス回線を経由したトラヒックを宅内において無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）にて送信する際に、マルチキャストからユニキャストに変換を行っている。これにより、無線ＬＡＮ区間において、より確実なトラヒック送信を実現している。

特許第４６６５００７号，”監視映像送信装置および方法” 特許第４８１４９９８号，”マルチキャスト・データを信頼できる形で送達するための方法および装置”

ＲＦＣ １１１２， "Ｈｏｓｔ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔｉｎｇ"

コンテンツ配信サービスは、配信設備、ネットワーク、受信者端末があって初めて成立するものである。よって、これら装置および設備には、相互に接続性が確保されていなければならない。前記したマルチキャストには、この接続性に関する課題がある。

コンテンツ配信サービスにおいては、配信設備とネットワークとの接続インターフェース（以下、ＳＮＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ－Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ））、および、ネットワークと受信者端末との接続インターフェース（以下、ＵＮＩ（Ｕｓｅｒ－Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ））において、入出力するトラヒックの条件を整合させる必要がある。これをＩＦ（Ｉｎｔｅｒｆａｃｅ）条件と呼ぶ事がある。入出力するトラヒックをユニキャストとするか、マルチキャストとするかもＩＦ条件に含まれ、サービス提供にあたっては、これを決定する必要がある。

ここで、トラヒックとは、コンテンツに、そのコンテンツを配信するための各種情報が付加されたものとする。例えば、コンテンツをＩＰパケットに格納して送信する場合は、ＩＰヘッダと、コンテンツが格納されたペイロードを合わせたものをトラヒックと呼ぶ事とする。

次に、ＳＮＩとＵＮＩのいずれか、あるいは両方のＩＦ条件をマルチキャストとした場合の課題を示す。配信事業者ＡおよびＢからのトラヒックはマルチキャストで送出されているため、トラヒックの消費帯域は配信チャネル数×受信者端末１台分で済み、伝送帯域の削減は実現できている。しかし、このような場合は、配信設備、受信者端末の両方が、マルチキャストに対応した機能を具備する必要が生じる。つまり、マルチキャスト配信が可能な配信設備や、マルチキャストを受信可能な受信者端末が必要となり、そうでない設備、端末は接続する事ができない。

マルチキャスト配信や受信に対応した装置自体は市中に存在するものの、インターネットトラヒックは、一般的にはユニキャストであるため、マルチキャスト配信や受信に対応させるとなると、そのネットワーク向けに特別な設定が必要となり、運用が煩雑になる。この問題を解決するためには、ＳＮＩとＵＮＩの両方をユニキャストとする事が考えられる。しかし、ネットワーク部分は、前記した伝送帯域の効率的利用の観点から、マルチキャストである事が望ましい。これらは相反する条件であるため、両立させるための技術が必要である。

そのような技術の一例として、ＳＮＩへユニキャストで入力したコンテンツは、ネットワークではマルチキャストに変換後、多地点に配信したのち、各拠点では再びユニキャストに変換してＵＮＩから出力する事が考えられる。しかし、ユニキャストを前提とする映像配信はＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）や、上位レイヤとしてはＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いることが多い。一方で、マルチキャストはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）や、上位レイヤとしてはＲＴＰ（Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などが使われるため、単純なＩＰヘッダの変換では不十分である。

このような動作は、前記と同様に、市中のユニキャストからマルチキャスト、および、マルチキャストからユニキャストへの変換技術を単に組み合わせるだけでは実現できない。

そこで本開示では、ＨＴＴＰをベースとしたウェブ配信システムにおいて、ユニキャストであるＨＴＴＰを維持しながら、効率的にコンテンツを転送可能にすることを目的とする。

本開示は上記の課題を解決するためになされたものであり、ウェブ配信を行うコンテンツサーバと、受信する端末間のネットワークに、ユニキャストマルチキャスト変換装置すなわちユニキャスト・マルチキャスト変換部（以下、ＵＭＣと称する。）と、マルチキャストユニキャスト変換装置すなわちマルチキャスト・ユニキャスト変換部（以下、ＭＵＣと称する。）を設け、そのＵＭＣとＭＵＣ間のトラヒックにおいてマルチキャスト通信を利用可能にする。これにより、サーバ設備、ネットワーク設備の投資軽減を促進し、および配信映像画質の高画質化、安定化を実現する。

具体的には、本開示に係るコンテンツ配信システムは、
ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムであって、
ユニキャスト通信からマルチキャスト通信へ変換し、前記マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置と、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置と、を備え、
前記マルチキャストユニキャスト変換装置は、
複数のコンテンツがグルーピングされているコンテンツグループを識別し、前記コンテンツグループ毎にユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて送信されたコンテンツを前記マルチキャスト通信ネットワークから受信し、前記コンテンツグループに含まれるコンテンツを格納するコンテンツ受信キャッシュ部と、
前記端末からのリクエストに基づき、前記コンテンツ受信キャッシュ部に格納されているコンテンツを前記端末に送信するユニキャスト送信部と、
前記端末からのリクエストに対応するコンテンツが前記コンテンツ受信キャッシュ部に格納されていない場合、前記端末からのリクエストに対応するコンテンツを含むコンテンツグループの要求を、ユニキャスト通信及びマルチキャスト通信のいずれか一方又は双方の通信方式で選択的に行うコンテンツリクエスト部と、
を備え、
前記ユニキャストマルチキャスト変換装置は、
前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
前記コンテンツリクエスト部からのリクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
を備える。

具体的には、本開示に係るユニキャストマルチキャスト変換装置は、
ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置であって、
前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、格納するユニキャスト受信キャッシュ部と、
前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信するコンテンツ送信部と、
前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行うユニキャストリクエスト部と、
を備える。

具体的には、本開示に係るコンテンツ配信方法は、
ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間に接続され、ユニキャスト通信からマルチキャスト通信へ変換し、マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置が実行するコンテンツ配信方法であって、
前記コンテンツサーバからユニキャスト通信を用いてコンテンツを受信し、当該コンテンツをユニキャスト受信キャッシュ部に格納し、
コンテンツ送信部が、前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換するマルチキャストユニキャスト変換装置から、複数のコンテンツがグルーピングされているコンテンツグループのリクエストを受信すると、当該リクエストに対応するコンテンツグループを前記ユニキャスト受信キャッシュ部から読み出し、読み出したコンテンツグループを、ユニキャスト通信およびマルチキャスト通信のいずれか一方又は双方の通信方式を用いて、前記マルチキャスト通信ネットワークに送信し、
ユニキャストリクエスト部が、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループが前記ユニキャスト受信キャッシュ部に格納されていない場合、前記マルチキャストユニキャスト変換装置からのリクエストに対応するコンテンツグループの要求を、ユニキャスト通信を用いて前記コンテンツサーバに対して行う。

具体的には、本開示に係るコンテンツ配信プログラムは、本開示に係るユニキャストマルチキャスト変換装置又はマルチキャストユニキャスト変換装置に備わる各機能部としてコンピュータを実現させるためのプログラムであり、本開示に係るコンテンツ配信方法に備わる各ステップをコンピュータに実行させるためのプログラムである。

本開示によれば、ＨＴＴＰをベースとしたウェブ配信システムにおいて、ユニキャストであるＨＴＴＰを維持しながら、効率的にコンテンツを転送可能にすることができる。

第１の実施形態に係るシステム構成の一例を示す。 ＭＵＣ及びＵＭＣにキャッシュがない場合の第１の実施形態のシーケンスを示す。 ＭＵＣの機能の一例を示す。 ＵＭＣの機能の一例を示す。 第９の実施形態に係るシステムの概略構成図である。 第１０の実施形態に係るシステムの概略構成図である。 ＭＵＣおよびＵＭＣにキャッシュがない場合の第１０の実施形態のシーケンスを示す。 ＭＵＣおよびＵＭＣにキャッシュがない場合の第１１の実施形態のシーケンスを示す。 第１４の実施形態のシーケンスの第１例を示す。 第１４の実施形態のシーケンスの第２例を示す。 第１５の実施形態のＵＭＣの概略構成を示す。 第１５の実施形態のＭＵＣの概略構成を示す。 テーブル８０１が保持するテーブルイメージの一例を示す。 テーブル８０２とテーブル８０３が保持するテーブルイメージの一例を示す。

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

また、本説明において、本開示に係るコンテンツ配信方法によって配信されるコンテンツは映像コンテンツであるものと仮定するが、本開示においては、他のコンテンツ（例えば、画像、Ｗｅｂページ、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）のアップデートファイル、ウイルス対策ソフトの定義ファイル等）も配信可能である。

（第１の実施形態）
図１に、本開示に係るコンテンツ配信方法を備えたネットワーク構成の一例を示す。本開示に係る配信システムは、コンテンツサーバ１０６とＵＭＣ１０５とＭＵＣ１０４と端末１０７を備える。また、コンテンツサーバ１０６と端末１０７の間には、マルチキャスト通信が可能なネットワークであるマルチキャスト通信ネットワーク１０２が存在している。図においては、ネットワーク１０１とネットワーク１０３とは別となっているが、単一のネットワークであってもかまわない。

また、ＵＭＣ１０５はネットワーク１０３とネットワーク１０２の境界もしくはネットワーク１０２に置かれ、ＭＵＣ１０４はネットワーク１０２とネットワーク１０１の境界もしくはネットワーク１０２に置かれる。

ＵＭＣ１０５とＭＵＣ１０４がない場合は、コンテンツサーバ１０６及び端末１０７間は、ユニキャストのＨＴＴＰを用いて通信を行っている。本配信システムでは、ＵＭＣ１０５とＭＵＣ１０４が間に入ることによって、ＵＭＣ１０５では、主に通信をユニキャストからマルチキャストへ、ＭＵＣ１０４では主にマルチキャストからユニキャストへその通信を変換する。これにより、本開示は、ウェブ配信というコンテンツサーバ１０６と端末１０７間の接続方法を変更する必要がなくなる。また、ＭＵＣ１０４は１台以上であり、それぞれ０台以上の端末１０７と接続される。

ここで、ＭＵＣ１０４は、主にマルチキャストからユニキャストへその通信を変換するが、変換前の通信はユニキャスト通信を含む場合やユニキャスト通信のみになることがある。また、ＵＭＣ１０５は、主に、ユニキャストからマルチキャストへその通信を変換するが、変換後の通信はユニキャスト通信を含む場合やユニキャスト通信のみになることもある。ＭＵＣ１０４及びＵＭＣ１０５がユニキャスト通信のみを行う場合は、本開示のシステムは多段のｗｅｂプロキシシステムとほぼ等価である。本開示は、アプリケーション層であるｗｅｂプロキシシステム（本開示にけるＵＭＣ１０５とＭＵＣ１０４）において、その通信の一部（ＵＭＣ１０５とＭＵＣ１０４間）を適応的にマルチキャスト化するシステムである。

図２に、ＭＵＣ１０４及びＵＭＣ１０５にキャッシュがない場合の通信の流れを示す。
端末１０７からのＨＴＴＰリクエストｒｅｑ．１はプロキシであるＭＵＣ１０４に送信される。

ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ１を実行する。ステップＳ１において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがないと判断し、上位のプロキシサーバであるＵＭＣ１０５へＨＴＴＰリクエストｒｅｑ．２を転送する。同様に、ＵＭＣ１０５は、ステップＳ２において、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがないと判断し、コンテンツサーバ１０６へＨＴＴＰリクエストｒｅｑ．３を転送する。

コンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答する。ｒｅｓ．１を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成し、キャッシュファイルをＵＭＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。

ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４では、ＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。ＭＵＣ１０４は、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。

以上のように、本開示は、ユニキャスト通信であるＲｅｓ．２と、マルチキャスト通信であるＭ－ｒｅｓ．２のメッセージを併用することにより、次の効果が期待できる。

・マルチキャスト通信により、不必要なユニキャスト通信を削減することで、ネットワークの利用帯域およびサーバへの負荷が低減される。これによりユニキャスト通信のみを利用した場合に比べ、より安定的に、より高画質な映像を配信可能とする。

・マルチキャスト通信が疎通できない環境では、従来のユニキャスト通信による疎通性を確保することができる。疎通できない環境とは、マルチキャスト通信をサポートしていない環境のほか、マルチキャストアドレスやマルチキャストルート数の枯渇や、マルチキャスト用のトラヒック量の超過などの一時的な非疎通環境も考えられる。さらには、動的にマルチキャストルートを生成するネットワークの場合は、そのルートが生成される以前に先んじてユニキャスト通信で配信することで、動画再生開始までの時間の短縮を可能とする。

・また、ユニキャスト通信をマルチキャスト通信データの再送用としての利用することで、信頼性を向上させることができる。特に、伝送路中のパケットロスや、受信機（ＭＵＣ１０４）の受信ミス等により、マルチキャストパケットを再送することは、ロスをしたＭＵＣ１０４だけでなく、他のＭＵＣ１０４にもマルチキャストパケットを伝送することになりネットワーク帯域や、他のＭＵＣ１０４負荷軽減ため、再送については、個別のＭＵＣ１０４に対して実施するこが望ましいからである。

・同様に、ｗｅｂベースでは同一のファイルに対して、同一のタイミングで複数の端末１０７からファイルへのリクエストが発生するとは限らない。そのため、特定のＭＵＣ１０４においてキャッシュが消去された後に端末１０７からのリクエストがあった場合は、マルチキャスト通信ではなく、ユニキャスト通信での配信が望ましい。これは、該当ＭＵＣ１０４とは別のＭＵＣ１０４がキャッシュファイルを保持している場合には、その配信が無駄になるからである。

また、本システムは、リアルタイム性のあるコンテンツの配信だけでなく、キャッシュによって、リアルタイム性の低いコンテンツの配信にも対応が可能となる。

図３に、図２における各ステップを実行するためのＭＵＣ１０４の機能の一例を示す。ＭＵＣ１０４は、コンテンツリクエスト部２０４と、コンテンツ受信キャッシュ部２０５と、ユニキャスト送信部２０６と、を持つ。

ユニキャスト送信部２０６は、端末１０７からのリクエストｒｅｑ．１に基づきコンテンツ受信キャッシュ部２０５からｒｅｑ．１に対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルをｒｅｓ．３で端末１０７に送信する。このキャッシュは、ＨＴＴＰにおけるファイルまたはストリームである。また、キャッシュは完全なファイルでなくてもよく、一部のデータのみでも順次、ユニキャスト通信として送信することができる。これにより、端末１０７からはコンテンツサーバ１０６に直接ＨＴＴＰリクエストを送信および、ＨＴＴＰレスポンスを受信する処理と同様の処理で、ＭＵＣ１０４のユニキャスト送信部２０６と通信が可能となる。

コンテンツリクエスト部２０４は、端末１０７からのリクエストに対応するキャッシュが無い場合、ＵＭＣ１０５へコンテンツをｒｅｑ．２で要求する。要求は、ユニキャスト通信又はマルチキャスト通信の両方の通信又は片方の通信方式で選択的に行う。例えば、この要求は、ＨＴＴＰリクエストを利用し、選択的要求はＨＴＴＰヘッダを用いて区別する。

コンテンツ受信キャッシュ部２０５は、コンテンツリクエスト部２０４からリスエストしたコンテンツを、複数のコンテンツでグルーピングしたコンテンツグループに識別し、前記コンテンツグループ毎にユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的にコンテンツ受信しキャッシュする。ここでのコンテンツは例えば、ファイルである。ウェブ配信システムでは、複数のファイルで１の番組を成すことがあるため、マルチキャスト等のストリームに変換する際に、複数のファイルを１のコンテンツグループとして扱うことで、効率的にマルチキャスト通信に変換が可能である。つまり、１の番組の異なるファイルの転送に際して、同一のマルチキャストのソースアドレス、グループアドレスでその転送を実施できるという利点がある。

ここで、コンテンツ受信キャッシュ部２０５において、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的に受信するとは、例えば、マルチキャストパスが確立される前もしくは、何らかの理由でマルチキャストが転送できないネットワークにおいてはユニキャスト通信を行い、マルチキャストパスが確立後にはマルチキャスト通信を行うことをなどが考えられる。

また、何らかの理由でマルチキャスト通信が受信できなかった場合などに、その受信ができなかったＭＵＣ１０４のみにデータを転送する場合である。マルチキャスト通信が受信できなかった場合としては、パケットロス等の受信エラーの他、マルチキャスト受信後にＭＵＣ１０４においてキャッシュアウトして再取得が必要になった場合や、ＵＭＣ１０５からはマルチキャスト配信されていたものの、ＭＵＣ１０４の受信準備ができておらず、データが取得できていない場合などがある。

このようにマルチキャスト通信とユニキャスト通信を組み合わせることで、同報性、即時性の高いコンテンツはマルチキャスト通信を用い、エラー回復もしくは同報性が低いか、即時性の低いコンテンツはユニキャスト通信を用いることで、ネットワーク設備、帯域を効率的に利用することが可能となる。

図４に、図２における各ステップを実行するためのＵＭＣ１０５の機能を示す。ＵＭＣ１０５は、ユニキャストリクエスト部２０１と、ユニキャスト受信キャッシュ部２０２と、コンテンツ送信部２０３を持つ。

コンテンツ送信部２０３は、ＭＵＣ１０４からのリクエストに基づきキャッシュからコンテンツを読み出し、ＭＵＣ１０４へコンテンツを送信する。この際、ＭＵＣ１０４は、コンテンツグループ毎に、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的に送信する。このように、ユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方もしくは選択的に受信するために、ＵＭＣ１０５とＭＵＣ１０４は連携を行う。

例えば、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５は、目的のマルチキャスト信号が受信可能か、ＵＭＣ１０５に通知する機構を持つ。これによりＵＭＣ１０５のコンテンツ送信部２０３は、ユニキャスト通信をマルチキャスト通信に切り替えることができる。

例えば、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５は、マルチキャストパスが確立される前に、マルチキャスト信号とユニキャスト信号の両方を受信する。マルチキャストパスが確立する前の場合、コンテンツ受信キャッシュ部２０５は、ユニキャスト信号によりキャッシュを生成する。コンテンツ受信キャッシュ部２０５がマルチキャスト信号を受信できたことで、コンテンツ受信キャッシュ部２０５は、マルチキャスト信号が受信可能であると判定することができる。

例えば、マルチキャスト信号のみをＵＭＣ１０５が送信し、ＭＵＣ１０４が受信し、ＭＵＣ１０４が受信を一部失敗した場合には、コンテンツ受信キャッシュ部２０５はマルチキャスト信号が受信できないと判定する。この場合、コンテンツリクエスト部２０４は、ユニキャスト信号を指定して、コンテンツ送信部２０３へ要求する。

ユニキャストリクエスト部２０１は、コンテンツリクエスト部２０４からのリクエストに対応するキャッシュが無い場合にコンテンツサーバ１０６にユニキャスト通信でコンテンツを要求する。例えば、この要求はＨＴＴＰが用いられ、コンテンツサーバ１０６にとっては、本システムとの特別な接続インタフェースを持つ必要がなく、通常の端末１０７の直接ＨＴＴＰリクエストを受けることと同様の処理で済ませることができる。

ユニキャスト受信キャッシュ部２０２は、ユニキャストリクエスト部２０１からのリクエストに基づき、コンテンツサーバ１０６からユニキャスト通信により送信されたコンテンツを受信し、キャッシュする。

なお、本開示では、ＭＵＣ１０４は複数あることを想定している。ＭＵＣ１０４にキャッシュがない場合は、ｒｅｑ．１起因で、ｒｅｑ．２、ｒｅｑ．３とコンテンツサーバ１０６へコンテンツをリクエストし、順次ｒｅｓ．１、ｒｅｓ．２およびＭ－ｒｅｓ．２、ｒｅｓ．３でキャッシュを作成しながら、端末１０７へ応答する。

同一コンテンツに対する他端末からのリクエストは時間差があるため、同一コンテンツへの最初リクエストから遅れてのリクエストは、同一ＭＵＣ１０４であれば、そのコンテンツ受信キャッシュ部２０５から直接応答が返される。別ＭＵＣ１０４であっても、マルチキャスト等によりコンテンツが配信済みであれば、同様にそのコンテンツ受信キャッシュ部２０５から応答が返される。別ＭＵＣ１０４であり、ＵＭＣ１０５からコンテンツが未配信であれば、ＵＭＣ１０５へｒｅｑ．２は送られるものの、そのリクエストのコンテンツに対してはＵＭＣ１０５で待ち合わせを実施し、ＭＵＣ１０４がマルチキャストまたはユニキャストでの配信を待つ。別ＭＵＣ１０４であり、ＵＭＣ１０５からのマルチキャスト等によりコンテンツが配信済みの場合は、別ＭＵＣ１０４が受信ミスまたは、ＩＰマルチキャストのマルチキャストグループへの未参加が考えられるため、ＵＭＣ１０５からはユニキャスト通信によりｒｅｓ．２が返される。

（第２の実施形態）
本実施形態では、コンテンツグループの識別方法について説明する。ユニキャスト受信キャッシュ部２０２は、複数のコンテンツでグルーピングしたコンテンツグループを生成する。この際、ユニキャスト受信キャッシュ部２０２は、複数のコンテンツでグルーピングしたコンテンツグループに識別するためのコンテンツグループ識別子を生成する。

例えば、ユニキャスト受信キャッシュ部２０２は、コンテンツの配置場所及びファイル名などからなるコンテンツ識別子から一部を抽出したコンテンツグループ識別子を生成する。このように、同一のコンテンツグループが同一の識別子を有していてもよい。

例えば、ＨＴＴＰでは、コンテンツを指定する際に、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）が用いられる。ＵＲＬは、ｈｏｓｔ名、パス、ファイル名、クエリストリング等からなる。今、下記のＵＲＬの複数のファイルが１の番組を成すとする。
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００１．ｔｓ
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００２．ｔｓ
・・・
ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓｘｘｘｘ．ｔｓ

この場合、例えば、”ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１”が同一であれば、同一の番組、すわなち、同一コンテンツグループとする。この場合、「ｈｔｔｐ／／ｗｗｗ２．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ１／ｓｔｒｅａｍｓ０００１．ｔｓ」や「ｈｔｔｐ／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｃｏｎｔｅｎｔｓ２／ｓｔｒｅａｍｓ０００１．ｔｓ」は、別のコンテンツグループとして識別される。

また、これらのコンテンツ識別子から一部を抽出したコンテンツグループ識別子はかならずしも既知である必要はなく、予測可能であればよい。例えば、“ｈｔｔｐ／／Ｙ－ＨＯＳＴ／Ｚ－ＰＡＴＨ／ｓｔｒｅａｍｓ－Ｘ－ＮＵＭＢＥＲ．ｔｓ”において、“Ｙ－ＨＯＳＴ”が何等かのホスト名に合致、Ｚ－ＰＡＴＨが何らかのパスに合致、“Ｘ－ＮＵＭＢＥＲ”が何らかの数に合致する場合のうち、“Ｙ－ＨＯＳＴ／Ｚ－ＰＡＴＨ”部分が同一のものを同一のコンテンツグループであるとする。

これらは正規表現のマッチングで実装可能である。また、既定のコンテンツグループ識別子または、予想可能なコンテンツグループ識別子でない場合は、その他のコンテンツグループとしてマルチキャスト通信を実施してもよい。

また、複数のコンテンツでグルーピングしたコンテンツグループに識別するためは、映像として複数のコンテンツをリスト化・グループ化し、そのコンテンツの所在を示すマニフェストファイルを元にコンテンツグループを識別する機能を備えることとしてもよい。

ウェブ動画配信システムでは、複数のファイルを１つのコンテンツグループにと見なすとともに、ダウンロードすべきファイルを示すために、マニフェストファイルが利用される。そこで、マニフェストファイルを解析し、マニフェストに記載のファイル群を、同一のコンテンツグループとすることもできる。

コンテンツ識別子から、同一コンテンツグループを識別する場合は、そのコンテンツ識別子の部分集合であるコンテンツグループ識別子が既知または予想可能である必要があるが、マニフェストからコンテンツを識別する場合は、コンテンツ識別子が既知である必要がない。

また、マニフェストファイルのコンテンツ識別子が既知であってもよいが、ウェブ動画配信システムでは、マニフェストファイルの拡張子は、ｍ３ｕ８や、ｍｐｄ等、方式に応じて既知であることから、拡張子からマニフェストファイルであることを判定し、解析を実施してもよい。

（第３の実施形態）
本実施形態では、コンテンツグループのマルチキャスト通信の詳細について説明する。コンテンツグループは、マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度を制御または区別し、マルチキャスト通信を行う機能を備えてもよい。

ＩＰマルチキャストにおける、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）や、ＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）では、同一のマルチキャストグループを、宛先であるマルチキャストグループアドレスを用いて識別するか、併せて、送信元であるソースアドレスを用いて識別する。

そこで、本開示では、これらマルチキャスト通信としてＩＰマルチキャストを用いる場合には、同一コンテンツグループに、同一のマルチキャストグループアドレスまたは、併せてソースアドレスを割り当てて通信を実施してもよい。また、ＩＰマルチキャストとしての同一のマルチキャストグループとすることに加えて、ポート番号や、パケットの優先度を設定、区別することもできる。

パケットの優先度は、イーサネット（登録商標）のＣｏｓ値や、ＩＰパケットのヘッダのＩＰ Ｐｒｅｃｅｄｅｎｃｅや、ＤＳＣＰなどを利用する場合が考えられる。ポート番号を区別することで、ＩＰマルチキャストの単一マルチキャストグループを小分けにして利用することや、ファイヤウォール等でフィルタリングが実施しやすくすることが可能となる。必要によりパケットの優先度を区別することで、コンテンツグループにサービスとしての優劣をつけることが可能となる。

またコンテンツグループの判定や、これに対応する前記マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度などのマルチキャスト通信の識別子を利用した送受信はＭＵＣ１０４や、ＵＭＣ１０５で行われ、これらの情報の一部または全部をＵＭＣ１０５等で集中管理することができる。この場合は、ＭＵＣ１０４では、ステップＳ１やＳ４の実行時に、ＵＭＣ１０５では、ステップＳ２やステップＳ３で管理問い合わせを実施することができる。

（第４の実施形態）
本実施形態のシステムは、マルチキャスト対象コンテンツと非対象コンテンツの弁別機能を備える。

ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツがマルチキャスト対象のコンテンツか判断し、マルチキャスト対象ではない場合には、ＵＭＣ１０５またはコンテンツサーバ１０６にユニキャスト通信でコンテンツを要求する機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合、ユニキャストでコンテンツを送信する機能を備える。マルチキャスト通信を併用して利用するコンテンツのほか、ＭＵＣ１０４または、ＵＭＣ１０５を一般的なウェブプロキシシステムとして利用するコンテンツを併存させても構わない。

マルチキャスト通信を利用する場合は、コンテンツグループを識別し、それぞれを異なるマルチキャスト通信とする処理を実施しなければならないが、ウェブプロキシでは、拡張子などを使って、事前の簡易的な処理の分岐が一般的に可能である。例えば、動画以外の拡張子については、マルチキャスト通信を利用する処理や判定を実施するステップに移行せずに、そのままウェブプロキシシステムとして処理することができる。これにより、本開示のシステムは、マルチキャスト化処理を簡易化できると共に、動画などのマルチキャスト化対象以外のＨＴＴＰリクエストを受け付け可能となり、汎用のプロキシとしての利用が可能となる。

（第５の実施形態）
本実施形態のシステムは、マルチキャストの動的ｊｏｉｎ／ｌｅａｖｅ機能を備える。ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツがマルチキャスト対象のコンテンツである場合、コンテンツグループに対応するマルチキャストグループに参加しているか否かを判定する。未参加の場合、コンテンツリクエスト部２０４は、参加信号を送出する。一方、参加済みのマルチキャストグループに対応するコンテンツグループのコンテンツの要求が一定時間ない場合には、コンテンツリクエスト部２０４は、マルチキャストグループからの離脱信号を送出する。

ＩＰマルチキャストでは、そのマルチキャストグループのルータへの登録が必要である。本実施形態は、静的な参加登録のほか、対象のマルチキャスト通信が発生する都度に、動的にマルチキャストルートの参加登録、参加離脱を実施することができる。この動的な参加登録、参加離脱の仕組みにはたとえばＩＧＭＰやＭＬＤが利用できる。

この動的な参加登録、参加離脱によって、複数あるＭＵＣ１０４のうち、視聴がないコンテンツグループのマルチキャスト通信を実施しないことができ、不要なトラヒックを抑制することが可能となる。またマルチキャストグループの登録数に制限がある場合に、その登録数の抑制が可能となる。なお、ルータへ静的なマルチキャストグループの設定を行うことを前提とすることもできる。

（第６の実施形態）
本実施形態のシステムは、マルチキャストｊｏｉｎ前にユニキャスト通信を行う。マルチキャスト通信ネットワーク１０２では、ＭＵＣ１０４が参加信号を送出し、ＭＵＣ１０４までのマルチキャストルートが確立された後に、ＭＵＣ１０４へのマルチキャスト通信を用いたコンテンツの配信が可能になる。本開示は、このようなＭＵＣ１０４のマルチキャストの動的参加離脱機能への対応が可能である。

具体的には、コンテンツリクエスト部２０４は、参加信号を送出後、マルチキャストルートが確立される前に、ＵＭＣ１０５にユニキャスト通信でコンテンツを要求する。この場合、コンテンツ受信キャッシュ部２０５は、ＵＭＣ１０５からユニキャスト通信によりコンテンツ受信し、キャッシュする。一方、ＵＭＣ１０５に備わるコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する。

これはルータにマルチキャストグループを動的設定する際に、その伝搬、設定の時間の間についても、コンテンツのＵＭＣ１０５からＭＵＣ１０４へのコンテンツの送受を可能とするものである。この際は、ＭＵＣ１０４はｒｅｑ．２で、明示的にマルチキャスト不要の指示をすることができる。このメッセージを受けたＵＭＣ１０５は、ユニキャスト通信のｒｅｓ．２を必ず応答する。

また、ＵＭＣ１０５は、マルチキャスト通信のＭ－ｒｅｓ．２を合わせて応答することもできる。この場合、ＵＭＣ１０４は、Ｍ－ｒｅｓ．２の到着を待たずｒｅｓ．２を受信することで、キャッシュを生成する。

ルータへのマルチキャストグループへ動的な参加登録の完了は、簡易的には、タイマによる設定が可能である。設定タイマ経過後は、ルータへマルチキャストグループの登録が行われたものとして、マルチキャスト通信を前提に動作を実施することができる。

また、前記のようにＵＭＣ１０５はｒｅｓ．２とＭ－ｒｅｓ．２を同時に送信することもできる。ＭＵＣ１０４では、Ｍ－ｒｅｓ．２を受け取ったことを以て、ルータへのマルチキャストグループの動的な参加登録が完了したと判定することもできる。

マルチキャストグループへの登録完了等のマルチキャスト通信が可能とＭＵＣ１０４が判定したのちは、ｒｅｓ．２では、マルチキャスト通信のＭ－ｒｅｓ．２のみを要求することができる。

（第７の実施形態）
本実施形態のシステムは、マルチキャスト通信のＦＥＣ機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、マルチキャスト送信機能において、前方誤り訂正符号（ＦＥＣ）情報を付加してマルチキャスト送信する機能を備えていてもよい。この場合、ＭＵＣ１０４のコンテンツ受信キャッシュ部２０５が、ＵＭＣ１０５からのＦＥＣ情報が付加されたマルチキャスト信号を、ＦＥＣ情報に基づいて、訂正する機能を備える。

ＩＰマルチキャストによる通信は、一対多通信であり、自動再送要求（ＡＲＱ）等の個別の誤り訂正ができない。そこで、ＦＥＣ情報として一定の冗長データを付加することで、伝送路中のパケットロスや、受信機によるパケット受信ミスなどによるデータの欠陥を補うことができる。これによりパケットロスが起こりやすい不安定な伝送路や、受信機が安定的なパケット受信できない場合でも、安定的な通信を可能とすることができる。

マルチキャスト通信に用いるＦＥＣは、以下の構成を採用してもよい。例えば、ＦＥＣが付加される前のコンテンツ情報と、付加されたＦＥＣ情報を異なるパケットとしてマルチキャスト送信する。この場合、ＦＥＣ情報が付加される前のコンテンツ情報のパケットと前記付加されたＦＥＣ情報のパケットとは、マルチキャストグループアドレス、ソースアドレス、ポート番号、パケット優先度の一部または全部が異なる。

ＦＥＣはその強度に応じて、ＦＥＣ情報を付加する前のデータに対して、１又は２割前後の冗長データが増える。これを元のデータと単一のコンテンツグループとすることもでるが、別とすることも可能である。これにより、処理を分離しやく、また、ネットワーク中でのモニタや、フィルタリングが容易に実施しやすくなる。

また、特に優先度の高いパケットは、トータルのネットワーク帯域を設計する必要がある。そのため。元のデータのみを優先度を高くし、ＦＥＣ情報の優先度を相対的に下げたり、反対に、ＦＥＣ情報のみの優先度を高くし、元のデータの優先度を相対的に下げたりすることができる。これにより、有限な高優先パケットを効率的に利用することが可能となる。

（第８の実施形態）
本実施形態のシステムは、マルチキャスト通信のＡＲＱ機能を備える。ＭＵＣ１０４のコンテンツリクエスト部２０４はＡＲＱユニキャストリクエスト機能を備え、コンテンツ受信キャッシュ部２０５はＡＲＱユニキャスト受信キャッシュ機能を備える。ＵＭＣ１０５のコンテンツ送信部２０３は、ユニキャスト送信機能を備える。

ＡＲＱユニキャストリクエスト機能は、ＵＭＣ１０５から受信したマルチキャスト信号に損失があった場合に、ユニキャスト通信を用いてコンテンツを要求する旨のユニキャストリクエストを送信する機能である。ＡＲＱユニキャスト受信キャッシュ機能は、ＵＭＣ１０５からユニキャスト通信を用いてコンテンツ受信し、コンテンツ受信キャッシュ部２０５にキャッシュする機能である。ＵＭＣ１０５のコンテンツ送信部２０３は、ＭＵＣ１０４からユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する機能を備えてもよい。

ＭＵＣ１０４において、Ｍ－ｒｅｓ．２の受信待ち状態で、その受信信号が完成しない場合は、パケットロスやＭＵＣ１０４の受信ミス等が原因として考えられ、結果としてＭＵＣ１０４ではその信号の損失となる。この際には、ＭＵＣ１０４は、ユニキャスト通信に限定してｒｅｑ．２を再発行することで、このロスを補完することができる。これはファイル単位での自動再送要求（ＡＲＱ）である。ファイル単位でのＡＲＱは、パケット単位やブロック単位でのＡＲＱに比べて、ＨＴＴＰリクエストの仕組みが利用できることから、実装が容易である。

また、本開示が他のマルチキャストシステムと異なり、ＨＴＴＰベースによるファイルベースのマルチキャスト化を実施していることから可能となる方式である。また、動画ファイルは、その再生時間を数秒程度に区切ったファイルに分割されていることがある。このような場合は、ファイル単位での再送処理でも十分な効率が保たれる。

本実施形態は、マルチキャスト通信のＡＲＱにおいて、分割要求を行ってもよい。例えば、ＭＵＣ１０４のコンテンツリクエスト部２０４は、コンテンツの一部を要求する機能を備える。この場合、コンテンツ受信キャッシュ部２０５は、ＵＭＣ１０５からユニキャスト通信およびマルチキャスト通信に分かれたコンテンツ受信し、元のコンテンツを復元した上でキャッシュするマルチキャスト・ユニキャスト混合受信キャッシュ機能を備える。ＵＭＣ１０５に備わるコンテンツ送信部２０３は、ＭＵＣ１０４からコンテンツの一部のユニキャストリクエストを受けた場合に、ユニキャストでコンテンツを送信する。

コンテンツリクエスト部２０４は、ファイル単位に限定せず、パケット単位、コンテンツを複数のブロックに分割したブロック単位でのＡＲＱも可能である。この際は、ＨＴＴＰリクエストｒｅｑ．２を用いることは、オーバーヘッドの観点から適切でない。そこでコンテンツリクエスト部２０４は、ｒｅｑ．２ではない、ＡＲＱメッセージを利用することが好ましい。

コンテンツリクエスト部２０４は、ＮＡＣＫ（未到着応答確認）メッセージを利用したＡＲＱを行ってもよい。この方式は、ファイル単位のＡＲＱよりも、応答の高速性と帯域効率性に優れる。

本実施形態のシステムは、パケット単位、ブロック単位でのＡＲＱを実施してもよい。この場合には、ＡＲＱを行うパケットや、コンテンツに含まれるブロックに対して順序番号を振り、順序番号により欠落の是非を判定および再要求を実施する。また、ファイル単位のＡＲＱとパケット単位、ブロック単位のＡＲＱを併用することもできる。

（第９の実施形態）
本実施形態のシステムは、２以上の複数のＵＭＣ１０５を備え、複数のＵＭＣ１０５の全部または一部が常用系として動作し、常用系のＵＭＣ１０５が故障や過負荷の場合に、全部または一部の常用系のＵＭＣ１０５の機能を、他の常用系または非常用系のＵＭＣ１０５で代替する。

図５に複数のＵＭＣ１０５がある場合の構成を示す。ＵＭＣ１０５に対応する複数のＵＭＣは、４０１、４０２、４０３である。４０１と４０２が常用系であり、４０３が非常用系であるとすると、ＵＭＣ４０１が故障や過負荷になった場合に、ＵＭＣ４０１の機能の全部または一部をＵＭＣ４０３に引き継ぐことができる。

ＵＭＣ４０１とＵＭＣ４０２は負荷分散系であり、例えば、コンテンツグループ毎にＭＵＣ１０４からＵＭＣ４０１及び４０２への接続先を変更することができる。

また、常用系は故障時の縮退動作も可能である。例えば、ＵＭＣ４０１が故障時には、ＵＭＣ４０１の機能と、ＵＭＣ４０２がＵＭＣ４０１の故障前から担当していた機能とを、ＵＭＣ４０２が併せて担当することができる。例えば、ＵＭＣ４０２が過負荷時には、ＵＭＣ４０１が担当する一部のコンテンツグループの処理機能と、ＵＭＣ４０２がＵＭＣ４０１の過負荷になる前から担当していた機能とを、ＵＭＣ４０２が併せて担当することができる。

このような機能は、システム稼働率の向上を可能にするだけでなく、システムの置き換え、拡張においてもサービスを断にすることなく移行することを可能とする。

（第１０の実施形態）
本実施形態のシステムは、２以上の複数のＭＵＣ１０４を備え、端末１０７からのリクエストを受けたＭＵＣ１０４が過負荷の場合、異なるＭＵＣ１０４へリダイレクトする信号を端末１０７へ送信し、リダイレクトを受信した端末１０７が、リダイレクトに基づき再びＭＵＣ１０４へリクエストを送信する。

図６に、複数のＭＵＣ１０４がある場合の構成の一例を示す。図７に、ＭＵＣおよびＵＭＣにキャッシュがない場合のシーケンスを示す。ＭＵＣ１０４に対応する複数のＭＵＣは、５０１と５０２である。通常時にＭＵＣ５０１が特定の端末１０７と接続されており、ＭＵＣ５０１が過負荷である場合、ＭＵＣ５０１は、端末１０７のＨＴＴＰリクエストｒｅｑ．１に対して、ＭＵＣ５０２へのＨＴＴＰリダイレクトｒｅｄｉｒｅｃｔ．１を送信することができる。

リダイレクトには、恒久的リダイレクトと、一時的リダイレクトがある。ＭＵＣ１０４は、当面ＭＵＣ５０１が応答できない場合又はＭＵＣ５０１からの設備移行が必要な場合、恒久的リダイレクトを実施し、それ以外は一時的リダイレクトを実施する。本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。

ＭＵＣ５０１からリダイレクト後に、ＭＵＣ５０２のコンテンツ受信キャッシュ部にキャッシュがない場合は、ＭＵＣ５０２のコンテンツリクエスト部は、ＵＭＣ１０５にリクエストを送信する。本実施形態では、ＵＭＣ１０５からコンテンツサーバ１０６にリクエストが転送された後、レスポンスがＵＭＣ１０５を経て、ＭＵＣ５０２のコンテンツ受信キャッシュ部に格納される。これにより、ｒｅｓ．３で端末１０７が応答を受信する。これにより、複数の端末１０７からの負荷が集中しやすいＭＵＣのピーク分散が可能となり、ＭＵＣへの設備投資を抑制することができる。

（第１１の実施形態）
図１のシステムにおいて、端末１０７からのリクエストを受けたＭＵＣ１０４が過負荷の場合がある。本実施形態のシステムは、ＭＵＣ１０４に代えてＵＭＣ１０５に対してリダイレクトを行うことで、ＭＵＣ１０４の負荷を分散する。

本実施形態のＭＵＣ１０４のユニキャスト送信部２０６は、過負荷の場合、ＵＭＣ１０５へリダイレクトする旨のメッセージを、リクエストの送信元の端末１０７へ送信する。端末１０７が、リダイレクトメッセージに基づき、ＵＭＣ１０５へリクエストを送信する。ＵＭＣ１０５のユニキャスト送信部２０６は、端末１０７からリクエストを受けた場合に、ユニキャストでコンテンツを端末１０７に送信する。

図８に、ＭＵＣおよびＵＭＣにキャッシュがない場合のシーケンスを示す。通常時にＭＵＣ１０４が特定の端末１０７に接続されており、ＭＵＣ１０４が過負荷である場合、ＭＵＣ１０４は、端末１０７のＨＴＴＰリクエストｒｅｑ．１に対して、ＵＭＣ１０５へのＨＴＴＰリダイレクトｒｅｄｉｒｅｃｔ．１を送信する。

ＵＭＣ１０５は、端末１０７からのリクエストを受けると、ユニキャスト受信キャッシュ部２０２にコンテンツが格納されているか否かを確認する。ユニキャスト受信キャッシュ部２０２にコンテンツが格納されていない場合、コンテンツサーバ１０６からユニキャストでコンテンツを取得し、ユニキャスト受信キャッシュ部２０２に格納する。そして、コンテンツ送信部２０３は、コンテンツをユニキャストで端末１０７に送信する。

リダイレクトには、恒久的リダイレクトと、一時的リダイレクトがある。ＭＵＣ１０４は、当面ＭＵＣ１０４が応答できない場合又はＭＵＣ１０４からの設備移行が必要な場合、恒久的リダイレクトを実施し、それ以外は一時的リダイレクトを実施する。本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。

リダイレクト後にＵＭＣ１０５のユニキャスト受信キャッシュ部２０２にキャッシュがない場合は、ＵＭＣ１０５のユニキャストリクエスト部２０１がコンテンツサーバ１０６にリクエストを送信し、ＵＭＣ１０５のユニキャスト受信キャッシュ部２０２がコンテンツサーバ１０６からのレスポンスｒｅｓ．１を受信してコンテンツを格納する。このように、コンテンツサーバ１０６からのコンテンツは、ＵＭＣ１０５を経てｒｅｓ．３で、ユニキャスト通信を用いて端末１０７に応答される。これにより、複数の端末１０７からの負荷が集中しやすいＭＵＣ１０４のピーク分散が可能となり、ＭＵＣ１０４への設備投資を抑制することができる。

なお、この端末１０７については、マルチキャストへの変換をせず、通常のウェブプロキシの動とほぼ同等である。また、ＭＵＣ１０４同士の負荷分散と、ＭＵＣ１０４からＵＭＣ１０５への負荷分散は併用可能である。端末１０７からのネットワーク距離の近さ、経由するネットワークの輻輳状況により使い分けることが可能である。

（第１２の実施形態）
ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、コンテンツを分割して記憶してもよい。この場合、ＵＭＣ１０５に備わるコンテンツ送信部２０３は、分割したキャッシュ単位で、ＭＵＣ１０４にマルチキャストまたはユニキャストで送信する機能を備える。ＭＵＣ１０４では、分割されたキャッシュ単位でコンテンツ受信キャッシュ部２０５に格納し、ユニキャスト送信部２０６は、分割されたキャッシュからコンテンツを復元し、端末１０７へユニキャスト送信する。

ＨＴＴＰではファイルが転送の基本単位であり、コンテンツサーバ１０６からＵＭＣ１０５がＨＴＴＰレスポンスｒｅｓ．１でファイルを完全に取得してから、マルチキャスト通信を開始すると、遅延が増える。ＵＭＣ１０５がｒｅｓ．１でコンテンツの取得を開始した段階で、１のファイルを分割してキャッシュし、Ｍ－ｒｅｓ．２のマルチキャスト通信を開始することで、遅延の隠ぺいが可能となる。

さらに、ＭＵＣ１０４では、分割されたキャッシュをコンテンツ受信キャッシュ部２０５が１以上受信完了した時点で、ユニキャスト送信部２０６が端末１０７へのユニキャスト送信を開始してもよい。

ＨＴＴＰではファイルが転送の基本単位である。そのため、ＵＭＣ１０５からＭＵＣ１０４がファイルを完全に取得してから、ＭＵＣ１０４から端末１０７へのＨＴＴＰレスポンスｒｅｓ．３の通信を開始すると、遅延が増える。そのため、ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５がコンテンツの取得を開始した段階で、１のファイルを分割してコンテンツ受信キャッシュ部２０５にキャッシュし、ユニキャスト送信部２０６がｒｅｓ．３を開始することが好ましい。これにより、本実施形態は、マルチキャスト通信ネットワーク１０２における遅延の隠ぺいが可能となる。

ＭＵＣ１０４に備わるコンテンツ受信キャッシュ部２０５及びＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、コンテンツをキャッシュするデータ保存領域を複数持っていてもよい。この場合、コンテンツ受信キャッシュ部２０５及びユニキャスト受信キャッシュ部２０２は、コンテンツの利用頻度、アクセス時刻、コンテンツグループのキャッシュ使用量、コンテンツまたはコンテンツグループ対する設定に応じて、前記データ保存領域間でキャッシュファイルを移動する機能を備えていてもよい。

多数の端末１０７と接続されるＭＵＣ１０４や、複数のＭＵＣ１０４や端末１０７へコンテンツを提供するＵＭＣ１０５では、キャッシュの読み書き速度が応答速度や、負荷に影響を及ぼす。高速なキャッシュの読み書きができるほど、多くの端末１０７等を収容しやすい。このようなキャッシュはメモリ上に置くことが望ましい。一方で、メモリ上のキャッシュはサイズに制限があるため、キャッシュによる配信効率の向上のためには、より多くのキャッシュを持つことも望ましい。

そこで、１次キャッシュをメモリ上に、２次キャッシュをディスク上に配置することで、速度と容量の２つの要件を満たすことができる。ここで１次キャッシュから２次キャッシュの移動は、コンテンツの利用頻度、アクセス時刻、コンテンツグループのキャッシュ使用量、コンテンツまたはコンテンツグループ対する設定に応じて実施することができる。

コンテンツ利用頻度に応じたキャッシュの移動は、例えば、コンテンツ毎に利用回数のテーブルを保持し、その利用回数に応じて２次キャッシュへのキャッシュアウトを制御する。アクセス時刻に応じたキャッシュの移動は、例えば、最終アクセス時刻をもとにタイマにより２次キャッシュへキャッシュアウトする。コンテンツグループのキャッシュ使用量に応じたキャッシュの移動は、例えば、特定の単一もしくは複数コンテンツグループで最大キャッシュ量を制限する。同一の制御ポリシが適用されるコンテンツグループ内でのキャッシュアウトは、前記のコンテンツの利用頻度、アクセス時間等により制御される。また、これらの設定は、個別のコンテンツもしくはコンテンツグループに対して、設定することもできる。

（第１３の実施形態）
本実施形態では、ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、ＭＵＣ１０４からのリクエストに拠らず、コンテンツサーバ１０７からコンテンツを受信する。例えば、コンテンツがコンテンツサーバ１０６からＵＭＣ１０５にプッシュ配信される。ＵＭＣ１０５に備わるユニキャスト受信キャッシュ部２０２は、受信したコンテンツからキャッシュを生成し、格納する。そして、ＵＭＣ１０５に備わるコンテンツ送信部２０３が、コンテンツグループ毎に、マルチキャスト通信またはユニキャスト通信を用いて、コンテンツを送信する。

前述までのシステムは、端末１０７からのＨＴＴＰリクエストｒｅｑ．１を起因とし、リクエストとレスポンスをリレーすることから、配信遅延が蓄積する場合がある。ウェブ動画配信システムでは、アダプティブビットレート（ＡＢＲ）として、複数レベルの画質のファイルを用意して、端末１０７のプレイヤで、能動的にダウンロードする画質のファイル選択することが一般的である。配信遅延が蓄積した場合、そのネットワークの帯域は十分であって、遅延から低画質の映像に切り替わる可能性がある。そこで、コンテンツサーバ１０６からプッシュでＵＭＣ１０５へコンテンツファイルを送信し、且つ、ＵＭＣ１０５からＭＵＣ１０４へ同様にプッシュでマルチキャストまたはユニキャストで送信することで、端末１０７からのリクエストが行われる前までにＭＵＣ１０４にキャッシュを作成することもできる。これにより、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。

（第１４の実施形態）
端末１０７からのリクエストに拠らず、ＭＵＣ１０４に備わるコンテンツリクエスト部２０４またはＵＭＣ１０５に備わるユニキャストリクエスト部２０１が、コンテンツグループのコンテンツのリクエストする機能を備えていてもよい。

前述のコンテンツサーバ１０６からのプッシュは、通常のウェブサーバの機能の拡張が必要である。そこで、ＭＵＣ１０４またはＵＭＣ１０５は、既知のコンテンツを、端末１０７からのリクエストによらず、主体的にリクエストしてもよい。

例えば、図９に示すようにステップＳ１で主体的にＨＴＴＰリクエストｒｅｑ．２を生成する場合がある。なお、図９はシーケンス開始時にキャッシュがない場合である。
ＨＴＴＰリクエストｒｅｑ．２を受けたＵＭＣ１０５は、ステップＳ２において、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがないと判断し、コンテンツサーバ１０６へＨＴＴＰリクエストｒｅｑ．３を転送する。

コンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答する。ｒｅｓ．１を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成し、キャッシュファイルをＭＵＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。

ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。

次に、端末１０７からのＨＴＴＰリクエストｒｅｑ．１はＭＵＣ１０４に送信される。ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがあると判断し、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。

なお、ｒｅｓ．１は、必ずしもｒｅｓ．２又はＭ－ｒｅｓ２によるキャッシュ作成後に発生する必要はない。ｒｅｑ．２より後にｒｅｓ．１が発生することで、キャッシュ生成までの時間を短縮できるからである。

例えば、図１０に示すようにステップＳ２で主体的にＨＴＴＰリクエストｒｅｑ．３を生成する場合がある。なお、図１０はシーケンス開始時にキャッシュがない場合である。

ＨＴＴＰリクエストｒｅｑ．３を受けたコンテンツサーバ１０６は、ｒｅｑ．３に対応するコンテンツファイルを、ＨＴＴＰレスポンスｒｅｓ．１でＵＭＣ１０５へ応答し、ＵＭＣ１０５は、ｒｅｓ．１に含まれるコンテンツファイルを用いてキャッシュファイルを生成する。

次に、端末１０７からのＨＴＴＰリクエストｒｅｑ．１はＭＵＣ１０４に送信される。
ｒｅｑ．１を受信したＭＵＣ１０４は、ステップＳ１を実行する。ステップＳ１において、ＭＵＣ１０４は、端末１０７からのＨＴＴＰリクエストｒｅｑ．１に対応するキャッシュがないと判断し、上位のプロキシサーバであるＵＭＣ１０５へＨＴＴＰリクエストｒｅｑ．２を転送する。

ｒｅｓ．２を受信したＵＭＣ１０５は、ステップＳ３を実行する。ステップＳ３において、ＵＭＣ１０５は、ＭＵＣ１０４からのＨＴＴＰリクエストｒｅｑ．２に対応するキャッシュがあると判断し、キャッシュファイルをＵＭＣ１０４へ応答する。ここで、ＵＭＣ１０５からＭＵＣ１０４への応答は、ＨＴＴＰリクエストｒｅｑ．２に対応する応答であり、ＨＴＴＰレスポンスｒｅｓ．２、又はマルチキャストによるレスポンスＭ－ｒｅｓ．２、又はｒｅｓ．２及びＭ－ｒｅｓ２の両方、のいずれも採用することができる。

ｒｅｓ．２又はＭ－ｒｅｓ２を受信したＭＵＣ１０４は、ステップＳ４を実行する。ステップＳ４では、ＭＵＣ１０４は、ｒｅｓ．２又はＭ－ｒｅｓ．２に含まれるキャッシュファイルを格納する。ＭＵＣ１０４は、格納しているキャッシュファイルをＨＴＴＰレスポンスｒｅｓ．３を応答する。ｒｅｓ．３は、ＨＴＴＰリクエストｒｅｑ．１に対応する端末１０７への応答である。なお、ＭＵＣ１０４とＵＭＣ１０５のキャッシュはディスク等の記憶容量の制限、もしくは、配信ポリシから、適切なタイミングで消去される。

なお、ｒｅｓ．１は、必ずしもｒｅｓ．３によるキャッシュ作成後に発生する必要はない。ｒｅｑ．３より後にｒｅｓ．１が発生することで、キャッシュ生成までの時間を短縮できるからである。

これにより、コンテンツサーバ１０６に特別な拡張をすることなく、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。

端末１０７からのリクエストに拠らずにＭＵＣ１０４又はＵＭＣ１０５がコンテンツのリクエストを行う場合、ＭＵＣ１０４に備わるコンテンツリクエスト部２０４又はＵＭＣ１０５に備わるユニキャストリクエスト部２０１は、コンテンツサーバ１０６でのコンテンツ生成時刻を識別、設定、予測して、前記コンテンツ生成時刻に同期することを特徴としてもよい。

静的なコンテンツの場合はコンテンツに対する既知のＵＲＬがあり、端末１０７からのリクエストによらない、ＭＵＣ１０４またはＵＭＣ１０５によるリクエストを生成できる。ライブ等の未来のコンテンツに対しては、静的な設定によるリクエスト生成はできない場合がある。そのため、コンテンツリクエスト部２０４又はユニキャストリクエスト部２０１は、マニフェストファイルを解析することで、マニフェストファイル記載の最新のコンテンツもしくは、マニフェストファイル記載のルールから短期的未来に生成されると予測されるコンテンツに対してのリクエストを生成してもよい。これにより、ライブ、またはリニア映像配信においても、コンテンツサーバに特別な拡張をすることなく、最短の応答時間でコンテンツを端末１０７に送信することができ、高画質で安定的な配信を実現できる。

コンテンツに時間順序性があるコンテンツグループの場合、端末１０７からのリクエストがあったコンテンツより前又は後のコンテンツをリクエストする機能を、コンテンツリクエスト部２０４又はユニキャストリクエスト部２０１が備えていてもよい。

特定のコンテンツの再生が開始されると、端末１０７の操作者は、端末１０７上の再生バーを操作して、再生開始時の時刻順ではなく、前もしくは後ろに時刻不連続に再生する場合がある。このような場合に高画質で安定的な配信を実現するために、再生時刻近傍の時刻のファイルまたは、統計的に再生頻度の高いファイルをＭＵＣ１０４またはＵＭＣ１０５がリクエストしてもよい。

（第１５の実施形態）
マルチキャスト通信に利用可能なマルチキャストグループアドレス、ソースアドレス、ポート番号等のマルチキャスト通信識別子の未使用の組み合わせを貯めておき、端末１０７からのリクエストに基づく新たなコンテンツグループのコンテンツの通信が発生するたびに、貯めておいたマルチキャスト通信識別子の未使用の組み合わせを割り当て、また、一定時間利用が無い時には前記マルチキャスト通信識別子の利用を停止し、再びマルチキャスト通信識別子の未使用の組み合わせに貯めてもよい。

アドレス管理及び配布元は、ＵＭＣ１０５又はその他の管理サーバで実施することが考えられる。また、アドレスの配布先は、ＵＭＣ１０５におけるコンテンツ送信部２０３およびＭＵＣ１０４におけるコンテンツ受信キャッシュ部２０５である。

図１１及び図１２に、ＵＭＣ１０５がマルチキャストグループアドレス、ソースアドレス、ポート番号等の空きマルチキャスト通信識別子のテーブルを持った場合のテーブル配置を示す。８０１が空きマルチキャスト通信識別子テーブル、８０２がコンテンツ送信部２０３によるマルチキャスト通信時にそのマルチキャスト通信識別子を保存しているテーブル、８０３がコンテンツ受信キャッシュ部２０５によるマルチキャスト受信時にそのマルチキャスト識別子を保存しているテーブルである。

コンテンツ送信部２０３はマルチキャスト通信の送信を始める際、テーブル８０２を参照し、該当コンテンツグループに対応するマルチキャスト識別子がない場合には、テーブル８０１からマルチキャスト識別子を取得し、テーブル８０２に登録する。同様に、コンテンツ受信キャッシュ部２０５はマルチキャスト通信の受信を始める際、テーブル８０３を参照し、該当コンテンツグループに対応するマルチキャスト識別子がない場合には、テーブル８０１からマルチキャスト識別子を取得し、テーブル８０３に登録する。テーブル８０１は、マルチキャスト識別子を払い出したのち、払い出したコンテンツグループによる利用フラグをテーブルに書き込む。

図１３にテーブル８０１が保持するテーブルイメージを示す。ここでは、マルチキャスト識別子ＩＤＭ２がコンテンツグループＩＤＧ１に対して、マルチキャスト識別子ＩＤＭ３がコンテンツグループＩＤＧ２に対して払い出され、共にＭＵＣ１０４が利用していることを、その他のマルチキャスト識別子は未利用であることを示している。

なお、テーブル８０３はテーブル８０２の部分集合であるため、テーブル８０１からマルチキャスト識別子を取得するのではなく、テーブル８０２から取得してもかまわない。この場合、テーブル８０１における利用ＭＵＣは、テーブル８０２で管理しても構わない。

なお、図１３に示すテーブルは模式的に表しており、メモリを節約し、テーブル検索をしやすいようハッシュを利用するか、リストによるデータ構造等他の形態での実装でも構わない。

図１４にテーブル８０２とテーブル８０３の一例を示す。ここでは、コンテンツグループＩＤＧ１に対してマルチキャスト識別子ＩＤＭ２が、コンテンツグループＩＤＧ２に対してマルチキャスト識別子ＩＤＭ３が利用されていることを示し、テーブルの他の部分は空き示している。

なお、図１４に示すテーブルは模式的に表しており、メモリを節約し、テーブル検索をしやすいようハッシュを利用するか、リストによるデータ構造等他の形態での実装でも構わない。ここで、テーブル８０２はテーブル８０１の部分集合であり、同一機能部に実装した場合は、単一のテーブルで管理しても構わない。

また、ＭＵＣ１０４において、コンテンツの利用がない場合には、タイマ等を利用してその利用停止を判定し、テーブル８０３から該当のコンテンツグループとマルチキャスト識別子を削除するとともに、テーブル８０１又はテーブル８０２における利用ＭＵＣから自身のＭＵＣを削除してもよい。利用ＭＵＣが空になると、マルチキャスト受信を行うＭＵＣが無いと判定されるため、テーブル８０１の利用コンテンツグループ列の該当コンテンツグループと、テーブル８０２の該当コンテンツグループの行を削除する。この操作により、マルチキャスト識別子が再利用できる。

（第１６の実施形態）
複数のＭＵＣ１０４に同一のＩＰアドレスを割り当て、端末１０７からは複数のＭＵＣ１０４を区別せずに最寄りのＭＵＣ１０４にリクエストを送信することができる構成を採用してもよい。

端末１０７からのＭＵＣ１０４のリクエスト受付インタフェースをＩＰエニーキャストによるルーティングを利用し、端末１０７の最寄りのＭＵＣへアクセスするよう誘導してもよい。これにより、ＤＮＳ等他の方式による管理に比べに、その管理を容易とすることが可能となる。さらに、ＭＵＣ１０４のリクエスト受付インタフェースに対する攻撃も分散化されることになり、攻撃に対して堅牢化することが可能となる。

（第１７の実施形態）
マニフェストファイルに記載のコンテンツ所在位置を、コンテンツサーバ１０６からＭＵＣ１０４に変更し、端末１０７からのＭＵＣ１０４へリクエストを行うようにしてもよい。

ウェブの動画配信システムでは、動画の最初の読み込みにあたりマニフェストと呼ばれる動画データの実態ファイル名や、ファイルの場所を示すファイルを読み込む。このマニフェストファイル中の動画データのファイル場所のＭＵＣ１０４へ変更することで、端末１０７からのＨＴＴＰリクエストｒｅｑ．１をＭＵＣ１０４宛に変更することができる。

マニフェストファイル自体もＨＴＴＰリクエスト、レスポンスにより端末１０７に送信されるため、コンテンツサーバ１０６による端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により、端末１０７の視聴環境にあったマニフェストファイルを端末１０７に個別に送信し分けることも容易になる。

これにより、本実施形態は、ＤＮＳによる振り分けと比べ、より柔軟な配信制御が可能となるとともに、ウェブシステムに閉じて、制御が完結できシステムの構築が容易になる。また、このマニフェストファイル書き換えによるリクエスト先の変更は、他のリクエスト先の変更方法と組み合わせてもよい。

マニフェストファイルは、書き換え前のマニフェストファイルが格納されたコンテンツサーバ１０６で書き換えを実施してもよいが、別の書き換え用のサーバを利用しても構わない。これにより、コンテンツサーバ１０６が直接ＭＵＣ１０４の位置を知ることなく、端末１０７からＭＵＣ１０４へのリクエストを実現できる。これは、コンテンツサーバ１０６と、ＭＵＣ１０４の管理主体が異なる場合に有効であり、ＭＵＣ１０４の管理主体がマニフェストファイル書き換えサーバを管理することにより実現できる。

（第１８の実施形態）
端末１０７からのコンテンツサーバ１０６へのリクエストを、コンテンツサーバ１０６がＭＵＣ１０４へリダイレクトすることにより、端末１０７からのＭＵＣ１０４へのリクエストを行うことを特徴としてもよい。

該当コンテンツサーバ１０６において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７がＭＵＣ１０４へアクセスするためにＨＴＴＰリダイレクトすることができる。

リダイレクトメッセージには恒久的リダイレクトと一時的リダイレクトがあるが、本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。これによりコンテンツそのものを書き換えることなしに、また、端末１０７の一次リクエストをコンテンツサーバ１０６に集約しながら、端末１０７からのＭＵＣ１０４へのアクセスを実現できる。また、このリダイレクトよるリクエスト先の変更は、他のリクエスト先の変更方法と組み合わせてもよい。

（第１９の実施形態）
本実施形態は、図１に示すシステムが、コンテンツ又はコンテンツグループのリクエストを転送する転送部（不図示）を更に備える。本実施形態は、端末１０７からのコンテンツサーバ１０６へのリクエストを、コンテンツサーバ１０６が転送部へリダイレクトし、転送部が端末１０７から転送部へのリクエストをＭＵＣ１０４へリダイレクトする。これにより、本実施形態は、端末１０７からのＭＵＣ１０４へのリクエストを行う。これは、コンテンツサーバ１０６は、転送部となる別サーバに一次リダイレクトを実施し、更に転送部がＭＵＣ１０４へリダイレクトするものである。

該当コンテンツサーバ１０６において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７が転送部へアクセスするためにＨＴＴＰリダイレクトし、更に、転送部において、端末ＩＰアドレスや、ＨＴＴＰリクエストのヘッダ情報、ＨＴＴＰリクエストのクエリストリング情報等のＨＴＴＰリクエストから取得できる端末１０７に依存するか端末１０７から付加できる情報により判定を実施し、端末１０７がＭＵＣ１０４へアクセスするためにＨＴＴＰリダイレクトすることができる。

これにより、コンテンツサーバ１０６が直接ＭＵＣ１０４の位置を知ることなく、端末１０７からＭＵＣ１０４へのリクエストを実現できる。これは、コンテンツサーバ１０６と、ＭＵＣ１０４の管理主体が異なる場合に有効であり、ＭＵＣ１０４の管理主体が転送部用のサーバを管理することにより実現できる。

このリダイレクトメッセージには恒久的リダイレクトと一時的リダイレクトがあるが、本実施形態は、一時的リダイレクト又は恒久的リダイレクトを、端末１０７に対してファイルのキャッシュをしない指定をして利用することができる。なお、恒久的リダイレクトを前期ファイルのキャッシュをしない指定をして利用した場合には、一時的リダイレクトの用途に利用できる。

本開示の装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

本開示は情報通信産業に適用することができる。

１０１、１０３：ネットワーク
１０２：マルチキャスト通信ネットワーク
１０４、５０１、５０２：ＭＵＣ
１０５、４０１、４０２、４０３：ＵＭＣ
１０６：コンテンツサーバ
１０７：端末
２０１：ユニキャストリクエスト部
２０２：ユニキャスト受信キャッシュ部
２０３：コンテンツ送信部
２０４：コンテンツリクエスト部
２０５：コンテンツ受信キャッシュ部
２０６：ユニキャスト送信部
８０１、８０２、８０３：テーブル

Claims (9)

1. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置であって、
   前記マルチキャスト通信ネットワークからユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的にコンテンツを受信し、キャッシュするコンテンツ受信キャッシュ部と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信するユニキャスト送信部と、
   前記端末からのリクエストに対応するコンテンツがマルチキャスト対象のコンテンツであるか否かを判定し、マルチキャスト対象でない場合には、ユニキャスト通信を用いたコンテンツの要求を行うコンテンツリクエスト部と、
   を備え、
   前記コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測し、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信すると、コンテンツ受信キャッシュ部に格納する、
   マルチキャストユニキャスト変換装置。
2. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置であって、
   前記マルチキャスト通信ネットワークからユニキャスト通信またはマルチキャスト通信の両方の通信もしくは片方の通信方式で選択的にコンテンツを受信し、キャッシュするコンテンツ受信キャッシュ部と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信するユニキャスト送信部と、
   自装置が前記端末からのリクエストに対応するコンテンツに対応するマルチキャストグループに参加しているか否かを判定し、参加済みの場合、前記端末からのリクエストに対応するコンテンツの要求を、参加済みのマルチキャストグループに対して行い、未参加の場合、ユニキャスト通信を用いたコンテンツの要求を行うコンテンツリクエスト部と、
   を備え、
   前記コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測し、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信すると、コンテンツ受信キャッシュ部に格納する、
   マルチキャストユニキャスト変換装置。
3. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムであって、
   ユニキャスト通信からマルチキャスト通信へ変換し、前記マルチキャスト通信ネットワークへ送出するユニキャストマルチキャスト変換装置と、
   前記マルチキャスト通信ネットワークで伝送されたマルチキャスト通信をユニキャスト通信へ変換する、請求項１または２に記載のマルチキャストユニキャスト変換装置と、
   を備え、
   前記コンテンツサーバ及び前記ユニキャストマルチキャスト変換装置は、プッシュでコンテンツファイルを送信する、
   コンテンツ配信システム。
4. 前記コンテンツサーバ又は前記コンテンツサーバ以外のマニフェストファイル書き換えサーバが、マニフェストファイルに記載のコンテンツ所在位置を、前記コンテンツサーバから前記マルチキャストユニキャスト変換装置に変更する、
   請求項３に記載のコンテンツ配信システム。
5. 前記端末の視聴環境にあったマニフェストファイルを前記端末ごとに個別に送信する、
   請求項３に記載のコンテンツ配信システム。
6. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置が実行する方法であって、
   コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測する手順と、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信し、コンテンツ受信キャッシュ部にキャッシュする手順と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信する手順と、
   前記端末からのリクエストに対応するコンテンツがマルチキャスト対象のコンテンツであるか否かを判定し、マルチキャスト対象でない場合には、ユニキャスト通信を用いたコンテンツの要求を行う手順と、
   を有する方法。
7. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置が実行する方法であって、
   コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測する手順と、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信し、コンテンツ受信キャッシュ部にキャッシュする手順と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信する手順と、
   自装置が前記端末からのリクエストに対応するコンテンツに対応するマルチキャストグループに参加しているか否かを判定し、参加済みの場合、前記端末からのリクエストに対応するコンテンツの要求を、参加済みのマルチキャストグループに対して行い、未参加の場合、ユニキャスト通信を用いたコンテンツの要求を行う手順と、
   を有する方法。
8. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置に、
   コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測する手順と、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信し、コンテンツ受信キャッシュ部にキャッシュする手順と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信する手順と、
   前記端末からのリクエストに対応するコンテンツがマルチキャスト対象のコンテンツであるか否かを判定し、マルチキャスト対象でない場合には、ユニキャスト通信を用いたコンテンツの要求を行う手順と、
   を実行させるためのプログラム。
9. ユニキャスト通信のウェブ配信システムにおける端末とコンテンツサーバの途中区間がマルチキャスト通信ネットワークを用いて接続されているコンテンツ配信システムに備わるマルチキャストユニキャスト変換装置に、
   コンテンツの所在を示すマニフェストファイル記載のコンテンツ又はルールに基づいて未来に生成されるコンテンツに対してのリクエストを予測する手順と、
   予測したコンテンツを前記マルチキャスト通信ネットワークから受信し、コンテンツ受信キャッシュ部にキャッシュする手順と、
   前記端末からのリクエストに基づき前記コンテンツ受信キャッシュ部から前記リクエストに対応するコンテンツファイルを読み出し、ユニキャスト通信で当該コンテンツファイルを前記端末に送信する手順と、
   自装置が前記端末からのリクエストに対応するコンテンツに対応するマルチキャストグループに参加しているか否かを判定し、参加済みの場合、前記端末からのリクエストに対応するコンテンツの要求を、参加済みのマルチキャストグループに対して行い、未参加の場合、ユニキャスト通信を用いたコンテンツの要求を行う手順と、
   を実行させるためのプログラム。

Images