(57)【要約】  プロキシ（２５０）は、プロキシ（２００）からの映像リクエストの検出時に、サーバ（３００）の代理で自身がマルチキャストで映像を送信できる旨を示す情報を該プロキシに送信する処理部（２５１）とプロキシ（２００）からのＪＯＩＮメッセージ受信時に該プロキシをマルチキャストグループに登録する処理部（２５３）とを備える。処理部（２５３）はキャッシュ（２５２）の映像を登録済の各プロキシにマルチキャストで中継する。
2012011449.tif 000002
【特許請求の範囲】
【請求項１】
通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバであって、
ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信手段と、
上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録手段と、
上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継手段と、を備えていることを特徴とするプロキシサーバ。
【請求項２】
請求項１に記載のプロキシサーバであって、
上記通信装置は複数存在し、
上記送信装置は上記通信装置からの要求に応じて相異なる複数のコンテンツを送信可能に構成されており、
上記送信手段は、同一のコンテンツについて一定期間内に一定数以上の通信装置から上記第１の要求が送られたことを検出した場合に限り、上記情報を上記通信装置に送信することを特徴とするプロキシサーバ。
【請求項３】
請求項１または２に記載のプロキシサーバであって、
上記第１の要求はＨＴＴＰリクエストメッセージであり、
上記送信手段は、上記情報をヘッダ情報として含むＨＴＴＰレスポンスメッセージとして送信するようになっており、
上記ヘッダ情報には、上記マルチキャストグループのアドレスを示す値が含まれていることを特徴とするプロキシサーバ。
【請求項４】
請求項１から３のいずれか１項に記載のプロキシサーバであって、
上記送信装置は、上記通信装置からの要求に応じて、上記コンテンツを複数に分割することにより得られる各分割データを順次送信するように構成されており、
上記中継手段は、上記記憶部にキャッシュされた各分割データを上記通信装置に順次中継することを特徴とするプロキシサーバ。
【請求項５】
請求項１から４のいずれか１項に記載のプロキシサーバであって、
上記コンテンツは映像コンテンツであり、
上記映像コンテンツは複数のムービーフラグメントから構成されていることを特徴とするプロキシサーバ。
【請求項６】
請求項５に記載のプロキシサーバであって、
上記送信装置から送信される上記映像コンテンツは、各パートが１つの上記ムービーフラグメントを含むマルチパート形式のデータであることを特徴とするプロキシサーバ。
【請求項７】
請求項６に記載のプロキシサーバであって、
各パートには、上記１つのムービーフラグメントだけでなく、上記複数のムービーフラグメントのうち、当該１つのムービーフラグメントを、上記映像コンテンツを再生する再生装置が何番目に再生すべきかを示す値も含まれていることを特徴とするプロキシサーバ。
【請求項８】
請求項５から７のいずれか１項に記載のプロキシサーバであって、
上記中継手段は、マルチキャスト通信により複数のパケットを各通信装置に送信することにより、各通信装置に中継すべき映像コンテンツを中継するように構成されており、
上記複数のパケットの各々には、たかだか１つのムービーフラグメントの全体または一部のデータが含まれていることを特徴とするプロキシサーバ。
【請求項９】
請求項１から８のいずれか１項に記載のプロキシサーバである送信側プロキシサーバに対し上記第１の要求を送信する上記通信装置として機能するプロキシサーバであって、
上記コンテンツを再生する再生装置から受信した上記第１の要求に応じて当該コンテンツを上記再生装置に中継する中継手段と、
上記再生装置から受信した上記第１の要求を中継することにより上記情報を受信したときに、上記第２の要求を上記送信側プロキシサーバに送信すべきか否かを判定する第１の判定手段を備えていることを特徴とするプロキシサーバ。
【請求項１０】
請求項９に記載のプロキシサーバであって、
上記中継手段は、上記再生装置に上記コンテンツを中継している間、該コンテンツの中継のために上記再生装置と確立した接続状態を保つようになっており、
上記中継手段は、第１のコンテンツを上記再生装置に中継している間に第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツを中継するために上記再生装置と確立した接続状態を解除することを特徴とするプロキシサーバ。
【請求項１１】
請求項１０に記載のプロキシサーバであって、
上記第１のコンテンツを上記再生装置に中継している間に上記第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツが中継されている各通信装置が所属するマルチキャストグループから自装置を解除する旨の要求を上記送信側プロキシサーバに送信する送信手段と、
上記第１のコンテンツが自装置に送信されなくなってから一定時間が経過したか否かを判定する第２の判定手段と、をさらに備え、
上記第１の判定手段は、一定時間が経過したと上記第２の判定手段が判定した場合に、上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定することを特徴とするプロキシサーバ。
【請求項１２】
上記コンテンツを再生する再生装置と、請求項１から８のいずれか１項に記載のプロキシサーバと、請求項９から１１のいずれか１項に記載のプロキシサーバと、上記通信装置と、を含む通信システム。
【請求項１３】
通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバにおける中継方法であって、
ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信工程と、
上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録工程と、
上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継工程と、を含んでいることを特徴とする中継方法。
【請求項１４】
請求項１から８のいずれか１項に記載のプロキシサーバを動作させるプログラムであって、コンピュータを上記各手段として機能させるための中継制御プログラム。
【請求項１５】
請求項１４に記載の中継制御プログラムが記録されているコンピュータ読み取り可能な記録媒体。
【請求項１６】
請求項９から１１のいずれか１項に記載のプロキシサーバを動作させるプログラムであって、コンピュータを上記各手段として機能させるための中継制御プログラム。
【請求項１７】
請求項１６に記載の中継制御プログラムが記録されているコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、再生装置または再生装置のプロキシサーバといった通信装置からの要求に基づいて送信装置から送信されたデータを、通信装置に中継する送信装置のプロキシサーバ、およびそのようなプロキシサーバにおける中継方法に関する。また、本発明は、そのようなプロキシサーバとしてコンピュータを動作させる中継制御プログラム、および、該中継制御プログラムを記憶している記録媒体に関する。さらに、本発明は、そのようなプロキシサーバと、通信装置と、送信装置と、を少なくとも含む通信システムに関する。
【背景技術】
【０００２】
近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等の静的コンテンツで構成されたＷＥＢページを見るだけでなく、動画コンテンツおよび音声コンテンツを、ストリーミング配信を受けて鑑賞することを望むユーザが増えてきている。【０００３】
一般に、テキストデータや静止画データ等の静的コンテンツは、http(s)プロトコル等によるユニキャスト通信により送受信されるようになっている。また、動画コンテンツおよび音声コンテンツもユニキャスト通信により送受信されることが多い。【０００４】
ユニキャスト通信により動画コンテンツを配信する配信方式として、MPEG（Moving Picture Expert Group）のMP4ファイルフォーマットを順次ダウンロードさせることによる配信方式（特許文献１）や、MPEGのISO Media File Formatのフラグメント映像形式を用いた配信方式（特許文献２）等が挙げられる。【０００５】
一般にユニキャスト通信によるデータの送受信は、通信元と通信先とでコネクションを確立した上で行われるため、データの送受信の信頼性が高いというメリットがある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】日本国特許公開公報「特開２００５−１１０２４４号公報（２００５年４月２１日公開）」
【特許文献２】日本国特許公開公報「特開２００７−１７３９８７号公報（２００７年７月５日公開）」
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来のようなユニキャスト通信による配信方式では、図２３において矢印で示したように、配信サーバは、配信要求を出した各クライアント装置に対して個別に動画コンテンツを配信するため、多数のクライアント装置から一度に配信要求を受けた場合にネットワークの帯域負荷が高まるという問題がある。また、配信サーバは、一度に多数の再生装置とコネクションを確立する必要があるため、配信サーバ自体の処理負荷も高まるという問題がある。【０００８】
本発明は上記の問題を鑑みてなされたものであり、その主な目的は、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることが可能な、送信装置のプロキシサーバを実現することにある。
【課題を解決するための手段】
【０００９】
本発明に係るプロキシサーバは、上記課題を解決するために、通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバであって、ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信手段と、上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録手段と、上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継手段と、を備えていることを特徴としている。【００１０】
上記プロキシサーバは、例えば、上記第１の要求がＨＴＴＰリクエストメッセージであり、上記送信手段が、上記情報をヘッダ情報として含むＨＴＴＰレスポンスメッセージとして送信するようになっており、上記ヘッダ情報には、上記マルチキャストグループのアドレスを示す値が含まれるように構成することができる。【００１１】
上記の構成によれば、上記プロキシサーバは、通信装置からの要求に応じて上記送信装置から送信されるコンテンツを、上記送信装置の代わりに自身がマルチキャスト通信により送信可能であることを示す情報を通信装置に送信する。そして、上記プロキシサーバは、マルチキャスト通信を用いて上記コンテンツを送信すべき旨の要求を上記通信装置から受信した場合に、上記送信装置の代わりに自身がマルチキャスト通信を用いて上記コンテンツを上記通信装置に送信する。【００１２】
したがって、複数の通信装置から上記送信装置に対してユニキャスト通信によるコンテンツの配信要求があった場合に、上記プロキシサーバは、上記複数の通信装置に対してマルチキャスト通信によりコンテンツを配信することができる。【００１３】
これにより、複数の通信装置から上記送信装置に対してユニキャスト通信によるコンテンツの配信要求があった場合に、上記送信装置からユニキャスト通信により個別に送信された各コンテンツをそのまま中継する従来のプロキシサーバに比べ、本発明のプロキシサーバは、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることができるという効果を奏する。【００１４】
本発明に係る中継方法は、上記課題を解決するために、通信装置からの要求に応じて送信装置から送信されるコンテンツを、記憶部にキャッシュするとともに上記通信装置に中継するプロキシサーバにおける中継方法であって、ユニキャスト通信によりコンテンツを送信すべき旨の第１の要求が上記通信装置から上記送信装置に送られたことを検出した場合に、上記送信装置の代わりに該プロキシサーバがマルチキャスト通信により該コンテンツを送信可能であることを示す情報を上記通信装置に送信する送信工程と、上記通信装置からマルチキャスト通信を用いて上記コンテンツを送信すべき旨の第２の要求を受信した場合に、上記通信装置をマルチキャストグループに登録する登録工程と、上記記憶部にキャッシュされた該コンテンツを、マルチキャスト通信を用いて上記マルチキャストグループに登録された各通信装置に中継する中継工程と、を含んでいることを特徴としている。【００１５】
上記の構成によれば、本発明の中継方法は、本発明のプロキシサーバと同様の作用効果を奏する。
【発明の効果】
【００１６】
以上のように、本発明のプロキシサーバは、送信装置から送信されるデータによるネットワークの帯域負荷を抑えることができるという効果を奏する。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態に係る配信システムの全体構成を示した図である。
【図２】図１の配信システムにおいて、配信サーバからクライアント装置に映像コンテンツが配信されている間の各装置間の通信処理を模式的に示した図である。
【図３】図１の配信システムを構成する各装置の詳細な構成を示した機能ブロック図である。
【図４】映像コンテンツのビットストリームと、ムービーフラグメントと、の関係を模式的に示した図である。
【図５】メディアセグメントと、ムービーフラグメントと、の関係を模式的に示した図である。
【図６】図１の配信システムの各装置間において、クライアント装置が映像コンテンツの配信要求を出してから、クライアント装置への映像コンテンツの配信が完了するまでに行われる全処理工程の前半部分を示すシーケンス図である。
【図７】図１の配信システムの各装置間において、クライアント装置が映像コンテンツの配信要求を出してから、クライアント装置への映像コンテンツの配信を完了するまでに行われる全処理工程の後半部分を示すシーケンス図である。
【図８】図６および図７のシーケンスが表わす処理工程の中で送信されるメッセージの一例を示す図である。（ａ）はクライアント装置が送信するリクエストメッセージを示す図であり、（ｂ）は配信サーバが送信するレスポンスメッセージを示す図である。
【図９】図６および図７のシーケンスが表わす処理工程の中で送信されるメッセージの別の一例を示す図である。（ａ）は配信サーバのプロキシサーバが送信するレスポンスメッセージを示す図である。また、（ｂ）および（ｃ）は、それぞれ、クライアント装置のプロキシサーバが送信するＨＴＴＰメッセージ形式のマルチキャストグループのＪＯＩＮメッセージおよびＬＥＡＶＥメッセージを示している。
【図１０】（ａ）〜（ｃ）は、図１の配信システムにおいて、配信サーバのプロキシサーバからクライアント装置のプロキシサーバに対して送信されるマルチキャストパケットの構造を示す図である。
【図１１】図１の配信システムにおいて、配信サーバのプロキシサーバが、どのようにしてＨＴＴＰのレスポンスメッセージとして送信された映像コンテンツのデータをマルチキャストのパケットに変換するかを具体的に示した図である。
【図１２】図１の配信システムにおいて、各装置間の通信処理を模式的に示した図である。（ａ）は配信要求を出しているクライアント装置の数が３つである場合の図であり、（ｂ）は配信要求を出しているクライアント装置の数が３つである場合の図である。
【図１３】図１の配信システムにおいて、映像コンテンツの再生を中断する旨の指示をクライアント装置がユーザから受けた場合における、各装置間の処理の流れを示すシーケンス図である。
【図１４】図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるＨＴＴＰ処理部の動作を示すフローチャートである。
【図１５】図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるマルチキャスト処理部の動作を示すフローチャートである。
【図１６】図１の配信システムにおいて、配信サーバのプロキシサーバが備えるＨＴＴＰ処理部が行う動作を示すものであり、クライアント装置のプロキシサーバを送信先とするレスポンスメッセージを受信した場合に行う動作を示すフローチャートである。
【図１７】図１の配信システムにおいて、クライアント装置のプロキシサーバが備えるマルチキャスト処理部の動作を示すフローチャートである。
【図１８】図１の配信システムにおいて、配信サーバのプロキシサーバが備えるＨＴＴＰ処理部の動作を示すものであり、ＪＯＩＮメッセージを受信した場合に行う動作を示すフローチャートである。
【図１９】図１の配信システムにおいて、クライアント装置の動作を示すフローチャートである。
【図２０】図１の配信システムにおいて、マルチキャスト通信中にマルチキャストパケットが欠損した場合に、クライアント装置に送信されるＨＴＴＰのレスポンスメッセージの一例を示す図である。
【図２１】図１の配信システムにおいて、クライアント装置が、再生中のコンテンツを同時に録画する場合に、マルチキャスト通信により欠損したムービーフラグメントを、ＨＴＴＰ通信により取得した欠損部のムービーフラグメントにより補完する処理を示すフローチャートである。
【図２２】図１の配信システムにおいて、映像コンテンツの再生を中断する旨の指示をユーザから受けた場合に、クライアント装置が行う動作を示すフローチャートである。
【図２３】従来技術を示すものであり、複数のクライアント装置の各々が配信サーバから個別に映像コンテンツのデータを受信する配信システムを示す図である。
【図２４】図１の配信システムにおいて、マルチキャスト配信がすでに行われている状態で新たにクライアント装置が映像コンテンツの配信要求を出した場合の動作例を示すシーケンス図である。
【図２５】図１の配信システムにおいて、クライアント装置で再生する映像コンテンツを切り替えた場合の動作例を示すシーケンス図である。
【発明を実施するための形態】
【００１８】
（実施形態１）
本発明の一実施形態に係る配信システムについて図面を参照しながら説明する。
【００１９】
図１は、本実施形態に係る配信システム１の全体構成を示した図である。配信システム１は、Ｎ台のクライアント装置１００（１００−１、１００−２、・・、１００−Ｎ）と、各クライアント装置１００のプロキシであるプロキシサーバ２００（２００−１、２００−２、・・、２００−Ｎ）と、配信サーバ３００と、配信サーバ３００のプロキシサーバ２５０と、を含むシステムである。
【００２０】
図１に示すように、配信システム１では、プロキシサーバ２５０と、配信サーバ３００と、により配信側ネットワーク（ＬＡＮ）が形成され、クライアント装置１００−１〜１００−Ｎと、プロキシサーバ２００−１〜２００−Ｎと、により、再生側ネットワーク（ＬＡＮ）が形成されている。また、２つのＬＡＮは、基幹ネットワーク５００により隔てられており、基幹ネットワーク５００には各プロキシサーバ２００−１〜２００−Ｎ、２５０が接続されている。
【００２１】
なお、本実施形態では、基幹ネットワーク５００は、プロキシサーバ２００とプロキシサーバ２５０と間にルーターが介在しないネットワークを想定している。
【００２２】
また、配信システム１では、配信サーバ３００が複数のチャンネルの映像コンテンツを配信可能になっている。そして、クライアント装置１００では、図示しない操作部を介してチャンネルの指定をユーザから受けると、指定されたチャンネルの映像コンテンツ（以下、「対象映像コンテンツ」とも称する）が配信サーバ３００から配信されるようになっている。クライアント装置１００からの配信要求、および配信サーバ３００から配信される映像コンテンツは、まず、対応するプロキシサーバに向けて送信されるようになっている。
【００２３】
図２は、配信システム１において、配信サーバ３００からクライアント装置１００−１〜１００−Ｎに映像コンテンツが配信されている間の各装置間の通信処理を模式的に示した図である。図２において右向きおよび左向きの細い矢印はＨＴＴＰプロトコル（すなわち、ユニキャスト通信）による映像コンテンツの要求および応答を示している。また、図２において、太い矢印はマルチキャスト通信による映像コンテンツの伝送を示している。
【００２４】
図２に示すように、配信システム１では、各ＬＡＮ内では、データ伝送プロトコルの１つであるHTTP（Hypertext Transfer Protocol）プロトコルのリクエスト・レスポンスの仕組みを用いて、映像コンテンツが送信される。また、このとき、映像コンテンツは、HTTPプロトコルで規定されているMIMEマルチパート形式（単に「マルチパート形式」と称する）でやりとりされる。
【００２５】
さらに、図２に示すように、配信システム１では、基幹ネットワーク内において、映像コンテンツがマルチキャスト通信により配信されるようになっている。マルチキャスト通信を用いることにより、プロキシサーバ２５０は、データ（映像コンテンツのパケット）を一度送信するだけで、当該データを、送信先のマルチキャストグループに属する複数のプロキシサーバ２００に向けて配信できるようになっている。
【００２６】
以下では、図３を参照しながら、クライアント装置１００、プロキシサーバ２００、プロキシサーバ２５０および配信サーバ３００についての詳細な構成を説明する。
【００２７】
（クライアント装置１００）
クライアント装置１００は、ＨＴＴＰ処理部１０１および再生部１０２を備えている。
【００２８】
ＨＴＴＰ処理部１０１は、後述するメディアセグメント（映像コンテンツを一定時間ごとに分割して得られる各単位、各図中において単に「ＭＳ」とも略称する）単位で、映像コンテンツの配信要求（リクエストメッセージ）をプロキシサーバ２００に送信する。
【００２９】
また、ＨＴＴＰ処理部１０１は、映像コンテンツをメディアセグメント単位で、後述するムービーフラグメント（フラグメント）を各パートとするマルチパート形式のレスポンスメッセージとしてプロキシサーバ２００から受信する。
【００３０】
再生部１０２は、ＨＴＴＰ処理部１０１が受信した各メディアセグメントを読み出すことにより映像コンテンツを再生する。
【００３１】
（プロキシサーバ２００）
プロキシサーバ２００は、ＨＴＴＰ処理部２０１、キャッシュ部２０２、およびマルチキャスト処理部２０３を備えている。
【００３２】
ＨＴＴＰ処理部２０１は、クライアント装置１００から受信した配信要求を、プロキシサーバ２００を送信元としてプロキシサーバ２５０に転送したり、配信要求を受けたデータをキャッシュ部２０２から読み出してクライアント装置１００に送信したりする。
【００３３】
キャッシュ部２０２は、データを保持するキャッシュメモリである。
【００３４】
マルチキャスト処理部２０３は、マルチキャストグループへの参加およびマルチキャストグループからの離脱をプロキシサーバ２５０に要求する。また、マルチキャスト処理部２０３は、マルチキャスト通信により伝送されてきたデータを受信してＨＴＴＰレスポンスメッセージの形式に変換する。
【００３５】
（プロキシサーバ２５０）
プロキシサーバ２５０は、ＨＴＴＰ処理部２５１、キャッシュ部２５２、マルチキャスト処理部２５３、およびマルチキャストグループ情報記憶部２５４を備えている。
【００３６】
ＨＴＴＰ処理部２５１は、プロキシサーバ２００から受信した配信要求を配信サーバ３００に中継する。また、ＨＴＴＰ処理部２５１は、所定の台数以上の通信装置に対象映像コンテンツを配信中の場合に、配信サーバ３００から送られてきた対象映像コンテンツのレスポンスメッセージに、対象映像コンテンツをマルチキャスト配信可能であることを示すヘッダ情報を付加した上でプロキシサーバ２００に中継する。
【００３７】
さらに、ＨＴＴＰ処理部２５１は、対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループ（以下、「対象マルチキャストグループ」とも称する）に所属するプロキシサーバ２００が存在する場合（すなわち、対象映像コンテンツをマルチキャスト配信すべきプロキシサーバ２００が存在する場合）には、プロキシサーバ２５０自身をリクエスト元として対象映像コンテンツの各メディアセグメントのレスポンスメッセージを配信サーバ３００から順に取得し、キャッシュ部２５２にキャッシュするようになっている。
【００３８】
キャッシュ部２５２は、データを保持するキャッシュメモリである。キャッシュ部２５２は、配信サーバ３００から送信されたレスポンスメッセージを保持する。
【００３９】
マルチキャスト処理部２５３は、対象マルチキャストグループへの参加の要求をプロキシサーバ２００−ｉ（ｉ：１〜Ｎの任意の値）から受け付けると、プロキシサーバ２００−ｉのアドレスを対象マルチキャストグループに所属しているものとしてマルチキャストグループ情報記憶部２５４に記録する。また、マルチキャスト処理部２５３は、対象マルチキャストグループからの離脱の要求をプロキシサーバ２００−ｉから受け付けると、対象マルチキャストグループに所属しているものとして記録されているプロキシサーバ２００−ｉのアドレスをマルチキャストグループ情報記憶部２５４から削除する。
【００４０】
さらに、マルチキャスト処理部２５３は、対象映像コンテンツをマルチキャスト配信すべきプロキシサーバ２００が存在する場合、キャッシュ部２５２に記録されているＨＴＴＰのレスポンスメッセージを、順次、マルチキャスト配信可能な形式のパケット（図１０および図１１を参照して後述する）に変換してマルチキャスト配信すべきプロキシサーバ２００に配信する。
【００４１】
マルチキャストグループ情報記憶部２５４は、不揮発性のメモリである。マルチキャストグループ情報記憶部２５４は、映像コンテンツ毎に定められた複数のマルチキャストグループの各々について、当該マルチキャストグループに所属する送信先の通信装置のアドレスを保持するようになっている。
【００４２】
（配信サーバ３００）
配信サーバ３００は、ＨＴＴＰ処理部３０１およびメモリ部３０２を備えている。
【００４３】
ＨＴＴＰ処理部３０１は、配信要求された映像コンテンツのメディアセグメントをメモリ部３０２から読み出して、ムービーフラグメントを各パートとするマルチパート形式のレスポンスメッセージとしてプロキシサーバ２５０に送信する。
【００４４】
メモリ部３０２は、複数のチャンネルの映像コンテンツを保持している。
【００４５】
以上、クライアント装置１００、プロキシサーバ２００、２５０および配信サーバ３００の詳細な構成について説明したが、配信システム１の動作を説明する前に、前述したムービーフラグメントおよびメディアセグメントについて図４および図５を参照しながら以下に説明する。
【００４６】
（メディアセグメントおよびムービーフラグメントについて）
最初に図４を参照しながらムービーフラグメントについて説明する。
【００４７】
図４は、映像コンテンツのビットストリーム(Contents.mp4)と、ビットストリームを分割・格納した各ムービーフラグメントと、の関係を模式的に示した図である。また、図５は、メディアセグメントと、メディアセグメントを構成する各ムービーフラグメントと、の関係を模式的に示した図である。
【００４８】
図４に示すように、ビットストリームは、分割されて複数のムービーフラグメントに格納される。図中、mdatが分割されたビットストリームデータである。各ムービーフラグメントは、ビットストリームを一定期間単位で区切った単位部分に対応している。本実施形態では、ムービーフラグメントとして、ISO Media File Format で規定されるフラグメント映像形式を想定している。
【００４９】
MP4ファイルのビットストリームにおける先頭のムービーフラグメント（フラグメント１）には、moovヘッダ４１ｂが含まれている。moovヘッダ４１ｂは、映像を再生するためのビットストリーム全体に関するメタ情報（初期化情報など）を保持するようになっている。MP4ファイルのビットストリームにおける後続のムービーフラグメント（フラグメント２、３、・・）には、moofヘッダ４２ｂが含まれている。各ムービーフラグメントのmoofヘッダ４２ｂは、当該ムービーフラグメントの映像を再生するためのメタ情報をヘッダである。
【００５０】
そして、各ムービーフラグメントには、ヘッダの他にメディアデータ（映像自体のデータ）mdatが含まれている。各ムービーフラグメントのメディアデータmdatには、該ムービーフラグメントに対応する期間における部分データがそれぞれ格納されている。例えば、フラグメントが１秒単位でビットストリームを区切ったデータである場合、フラグメント１のメディアデータmdatには、映像コンテンツの再生開始から１秒間分の映像データが格納されている。
【００５１】
次に図５を参照しながらメディアセグメントについて説明する。
【００５２】
図５に示すように、メディアセグメントは複数のムービーフラグメントから構成されている。メディアセグメントも、コンテンツデータを一定期間単位で区切った単位部分に対応している。さらに、本実施形態では、このメディアセグメントを、１つのレスポンスデータに格納されるコンテンツデータとして扱う。即ち、メディアセグメントは、一度のリクエストで獲得されるコンテンツデータの単位となっている。
【００５３】
また、メディアセグメントが複数のムービーフラグメントから構成されることからわかるように、１つのメディアセグメントに対応する期間の長さは、１つのムービーフラグメントに対応する期間の長さの整数倍となっている（ただし、これはムービーフラグメントの長さが固定の場合であり、ムービーフラグメントの長さが可変の場合は整数倍には限られない）。なお、次に説明する動作例では、１つのメディアセグメントに対応する期間を３０秒とし、１つのムービーフラグメントに対応する期間の長さを１秒として説明する。
【００５４】
（配信システム１の動作例１）
次に、クライアント装置１００が対象映像コンテンツの配信要求を出してからクライアント装置１００への対象映像コンテンツの配信が完了するまでに配信システム１で行われる動作の一具体例について図６〜図１２を参照しながら説明する。
【００５５】
図６および図７は、それぞれ、上記動作の前半部分および後半部分を示すシーケンス図である。
【００５６】
なお、この動作例では、プロキシサーバ２５０のＨＴＴＰ処理部２５１は、４台以上の装置に対象映像コンテンツを配信中の場合に限り、マルチキャスト配信可能であることを示すヘッダ情報を付加するようになっている。また、動作の開始前に、すでに３台のクライアント装置１００−２〜１００−４に対象映像コンテンツを配信中であるものとし、新たにクライアント装置１００−１が対象映像コンテンツの配信要求を出すものとする。
【００５７】
最初に、クライアント装置１００−１は、対象映像コンテンツの先頭のメディアセグメントを要求するＨＴＴＰのリクエスト４１（第１の要求）をプロキシサーバ２００−１に送信する（Ｓ０１）。このリクエスト４１は、図８（ａ）に示すようなデータであるが、図８（ａ）からわかるように、クライアント装置１００−１は、プロキシサーバ２００−１とキープアライブで接続するようになっている。すなわち、クライアント装置１００−１は、リクエスト４１に対するレスポンスの受信後も接続状態を保つようになっている。
【００５８】
次に、プロキシサーバ２００−１のＨＴＴＰ処理部２０１は、クライアント装置１００−１から受信したリクエスト４１を、自身のＩＰアドレスを送信元として設定した上でプロキシサーバ２５０に送信する（Ｓ０２）。そして、プロキシサーバ２５０のＨＴＴＰ処理部２５１は、配信サーバ３００にキープアライブにより接続し、リクエスト４１を配信サーバ３００に中継する（Ｓ０３）。
【００５９】
リクエスト４１を受けた配信サーバ３００のＨＴＴＰ処理部３０１は、メモリ部３０２から対象映像コンテンツを読み出し、図８（ｂ）に示すようなレスポンスメッセージ５１を生成してプロキシサーバ２５０に送信する（Ｓ０４）。
【００６０】
図８（ｂ）において、レスポンスメッセージ５１内の”www.sample.com”は配信サーバ３００のホストドメイン名を示しており、”content1”は対象映像コンテンツのファイル名を示している。また、X-Segment-Fragment-Index:1/60は、メディアセグメントのインデックス値を示している。すなわち、X-Segment-Fragment-Index:1/60は、対象映像コンテンツが６０個のメディアセグメントから構成され、このレスポンスメッセージが１つ目のメディアセグメントのデータであることを示している。
【００６１】
さらに、「{binary-data:fragment-01}」〜「{binary-data:fragment-30}」の部分は、１つ目のメディアセグメントを構成する３０個のムービーフラグメントを示している。
【００６２】
レスポンスメッセージ５１を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、対象映像コンテンツのクライアント装置１００からの要求頻度を確認する（Ｓ０５）。すなわち、ＨＴＴＰ処理部２５１は、一定期間内に同一の対象映像コンテンツに対するリクエスト４１を何回受信したかをカウントする。ここでは、クライアント装置１００の台数がクライアント装置１００−１〜１００−４の４台であり要求頻度が一定以上であるため、レスポンスメッセージ５１にマルチキャスト配信可能であることを示すヘッダ情報を付加することにより図９（ａ）に示すようなレスポンスメッセージ５１ａを生成する（Ｓ０６）。
【００６３】
図９（ａ）において破線の枠で囲んだ文字列（”X-alternative-cast”から始まる文字列）は、付加したヘッダ情報を示している。
【００６４】
X-alternative-castのヘッダ情報は、次の書式を取るようになっている。
<配信形式>://<配信アドレス＞/<TTL>?session_id=<セッションID>?session_name=<セッション名>
ここで、<配信形式>は、コンテンツの配信方法を示しており、図９（ａ）では、マルチキャスト配信である“multicast”を示している。また、配信形式がマルチキャスト配信である場合における＜配信アドレス＞（図９（ａ）で”224.1.1.1”）は、マルチキャストアドレスを示している。マルチキャストアドレスは、一般的に、クラスＤのIPマルチキャストグループアドレスを記述する。
【００６５】
また、＜ＴＴＬ＞は、パケットの有効期間(time to live)を示している。これは、ネットワーク内の伝達範囲を設定する。プロキシサーバ２００とプロキシサーバ２５０との間にルーターが含まれているネットワークにおいて、ルーターを超えてマルチキャストデータを配信する際に＜ＴＴＬ＞を大きな値に設定する必要があるが、本実施形態では、基幹ネットワーク５００にルーターが介在しないので＜ＴＴＬ＞の値は”1”となっている。また、＜セッションID>および<セッション名>は、セッションを識別するために用いられる。
【００６６】
Ｓ０６の処理の後、ＨＴＴＰ処理部２５１は、生成したレスポンスメッセージ５１ａをプロキシサーバ２００−１に送信する（Ｓ０７）。
【００６７】
レスポンスメッセージ５１ａを受信したプロキシサーバ２００−１のＨＴＴＰ処理部２０１は、”X-alternative-cast”のヘッダ情報があることを確認すると（Ｓ０８）、その旨をマルチキャスト処理部２０３に通知するとともに、レスポンスメッセージ５１ａを元のレスポンスメッセージ５１に変換してクライアント装置１００−１に送信する（Ｓ０９）。なお、レスポンスメッセージ５１を受信したクライアント装置１００−１の再生部１０２は、対象映像コンテンツの再生を開始することになる。
【００６８】
その後、プロキシサーバ２００−１のＨＴＴＰ処理部２０１は、図９（ｂ）に示すようなマルチキャスト受信要求（対象マルチキャストグループへの参加を要求するJOINメッセージ４２）をプロキシサーバ２５０に送信する（Ｓ１０）。JOINメッセージ４２（第２の要求）および後述するLEAVEメッセージ４３は、図９（ｂ）および図９（ｃ）に示すように、ＧＥＴリクエスト形式のＨＴＴＰメッセージである。JOINメッセージ４２およびLEAVEメッセージ４３のヘッダ部のX-alternative-multicast-set ヘッダには、それぞれ、マルチキャストグループへの参加を示す文字列、および、マルチキャストグループからの離脱を示す文字列が付与される。すなわち、JOINメッセージ42には”JOIN”が付与され、LEAVEメッセージ43には”LEAVE”が付与される。
【００６９】
JOINメッセージ４２を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスメッセージを返却するとともに、プロキシサーバ２００−１のアドレスを対象マルチキャストグループに所属するものとしてマルチキャストグループ情報記憶部２５４に記録する（Ｓ１１）。
【００７０】
一方、Ｓ１０でJOINメッセージを受信したＨＴＴＰ処理部２５１は、対象映像コンテンツのメディアセグメントを取得して（Ｓ１２）、キャッシュ部２５２に記録する（Ｓ１３）。Ｓ１２およびＳ１３の処理は、その後繰り返し行われる。すなわち、対象映像コンテンツを構成する全メディアセグメントについてＳ１２およびＳ１３の処理が行われる。なお、Ｓ１２の処理を繰り返す周期は特に限定されない。すなわち、１つのメディアセグメントのクライアント装置１００における再生時間よりも短い周期でＳ１２の処理を繰り返せばよい。
【００７１】
一方、ステップＳ１１の処理を終えた後、マルチキャスト処理部２５３は、キャッシュ部２５２に記録されたメディアセグメントのレスポンスメッセージ５１を順次、マルチキャストのパケットに変換する（Ｓ１４）。
【００７２】
ここで、Ｓ１４の処理の詳細について図１０および図１１を参照しながら以下に説明する。
【００７３】
最初にマルチキャストパケットのフォーマットについて図１０を参照して説明する。
【００７４】
マルチキャストパケットは、図１０（ｃ）に示すように、ＵＤＰヘッダ部と、ＲＴＰヘッダ部と、ＲＴＰデータ部と、を含んでいる。マルチキャストパケットのより具体的な構造を図１０（ａ）および図１０（ｂ）を参照して説明すると以下の通りである。
【００７５】
図１０（ａ）は、マルチキャストのパケットを構成するＵＤＰパケットのフォーマットを示している。ＵＤＰパケットのＵＤＰヘッダ部には、マルチキャストパケットの送信元のポート番号、マルチキャストパケットの送信先のポート番号、ＵＤＰパケットのパケット長、パケットの整合性を取るためのチェックサムのフィールドがある。ＵＤＰパケットのデータ部は可変長になっている。
【００７６】
図１０（ｂ）はＵＤＰパケットのデータ（データグラム）部分を構成するＲＴＰパケットのフォーマットを示している。ＲＴＰパケットのＲＴＰデータ部（ペイロードデータ）には、レスポンスメッセージ５１の一部が記録されるようになっている。
【００７７】
また、ＲＴＰパケットのＲＴＰヘッダ部には、マルチキャストパケットの送信順序を示すシーケンス番号と、タイムスタンプと、が格納される。ここで、ＲＴＰパケットのタイムスタンプには、該ＲＴＰパケットのＲＴＰデータ部にその一部が含まれるレスポンスメッセージ５１のうち、最も小さいタイムスタンプ(X-timestamp)の値が格納される。例えば、ＲＴＰデータ部に２つ目のメディアセグメントに対応するレスポンスメッセージ５１の一部が含まれる場合、ＲＴＰヘッダ部のタイムスタンプには「３０」が格納される。
【００７８】
次に、図１１を参照して、マルチキャスト処理部２５３がＨＴＴＰのレスポンスメッセージ５１をどのようにマルチキャストパケットに変換するかについて具体的に説明する。
【００７９】
図１１中の左側部分は、変換後のマルチキャストパケット５２−１、５２−２、５２−３、・・・を模式的に示している。また、図１１中の右側部分は、ＨＴＴＰのレスポンスメッセージ５１（５１−１、５１−２・・・）内のヘッダ部分のデータとボデイ部分の各パートのデータとがどのマルチキャストパケットにペイロードデータとして格納されるかを模式的に示している。
【００８０】
マルチキャスト処理部２５３は、メディアセグメントのレスポンスメッセージ５１−１をキャッシュ部２５２から読み出すと、レスポンスメッセージ５１のContent-Locationヘッダの文字列中で「対象映像コンテンツのファイル名」および「メディアセグメントのインデックス値」の部分（すなわち、”/content1/1”）を抽出して、最初のマルチキャストパケット５２−１にペイロードデータとして格納する。
【００８１】
そして、マルチキャスト処理部２５３は、メッセージ５１−１のうち、ヘッダ部分を次のマルチキャストパケット５２−２にペイロードデータとして格納する。
【００８２】
さらに、マルチキャスト処理部２５３は、メッセージ５１−１のボディ部分のデータを後続するマルチキャストパケット５２−３・・にペイロードデータとして格納していく。より具体的には、マルチキャスト処理部２５３は、各パートに含まれるムービーフラグメントを、ムービーフラグメントのデータサイズに応じて１または複数のマルチキャストパケット５２に格納する。マルチキャスト処理部２５３は、メッセージ５１−２以降の各メッセージ５１についても同様の処理を行う。
【００８３】
なお、各パートに含まれるムービーフラグメントのバイナリデータは先頭部分がマルチキャストパケット５２のペイロードの先頭部分と必ず一致するようにマルチキャストパケット５２に格納される。同様に、各パートに含まれるムービーフラグメントのバイナリデータは末尾部分がマルチキャストパケット５２のペイロードの末尾部分と必ず一致するようにマルチキャストパケット５２に格納される。すなわち、複数のムービーフラグメントのバイナリデータが１つのマルチキャストパケットに格納されないようになっている。
【００８４】
また、マルチキャスト処理部２５３は、マルチキャストパケットのヘッダ部分には、前述したＵＤＰヘッダ部、ＲＴＰヘッダ部、およびＲＴＰデータ部に適切な値を格納する他、ＩＰヘッダ部にＩＰマルチキャストアドレス（マルチキャストグループアドレス）である”224.1.1.1”を格納するようになっている。
【００８５】
マルチキャスト処理部２５３は、以上のようにして変換したマルチキャストパケット５２を、順次、プロキシサーバ２００−１に配信する（Ｓ１５）。
【００８６】
プロキシサーバ２００−１のマルチキャスト処理部２０３は、Ｓ１５にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンスメッセージ５１に変換し（Ｓ１６）、キャッシュ部２０２にキャッシュする（Ｓ１７）。Ｓ１５〜Ｓ１７の処理は、その後繰り返し行われる。すなわち、対象映像コンテンツを構成する全メディアセグメントについてＳ１２およびＳ１３の処理が行われる。
【００８７】
一方、クライアント装置１００−１は、続けて、対象映像コンテンツの２番目のメディアセグメントを要求するＨＴＴＰのリクエスト４１をプロキシサーバ２００−１に送信する（Ｓ１８）。
【００８８】
リクエスト４１を受信したプロキシサーバ２００−１のＨＴＴＰ処理部２０１は、２番目のメディアセグメントのレスポンスメッセージ５１をキャッシュ部２０２から読み出す（Ｓ１９）。なお、ＨＴＴＰ処理部２０１は、読み出しを試行した時点でキャッシュ部２０２にレスポンスメッセージ５１がキャッシュされていない場合、レスポンスメッセージ５１がキャッシュされるまで待機してから読み出す。
【００８９】
レスポンスメッセージ５１を読み出したＨＴＴＰ処理部２０１は、レスポンスメッセージ５１をクライアント装置１００−１に送信する。このＳ１８、Ｓ１９の処理も、続きの３番目以降のメディアセグメントに対して順次行われる。
【００９０】
その後、配信サーバ３００が最後のメディアセグメントを要求するリクエスト４１をプロキシサーバ２５０から受け付けたものとする。
【００９１】
配信サーバ３００のＨＴＴＰ処理部３０１は、最後のメディアセグメントのレスポンスメッセージとして、通常のレスポンスメッセージ５１のヘッダ部に”Connection:Close”のヘッダを付加したレスポンスメッセージ５１’をプロキシサーバ２５０に送信する（Ｓ２０）。
【００９２】
ＨＴＴＰ処理部２５１は、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”の文字列があることを確認すると、配信サーバ３００との接続状態が解除されたことを認識する（Ｓ２１）。
【００９３】
そして、マルチキャスト処理部２５３は、キャッシュ部２５２にキャッシュされたレスポンスメッセージ５１’をマルチキャストパケット５２に変換してプロキシサーバ２００−１に送信する（Ｓ２２）。
【００９４】
プロキシサーバ２００−１のマルチキャスト処理部２０３は、Ｓ２２にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンスメッセージ５１’に変換し、キャッシュ部２０２にキャッシュする。なお、マルチキャスト処理部２０３は、キャッシュしたレスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認する。
【００９５】
クライアント装置１００−１は、続きのメディアセグメントを要求するＨＴＴＰのリクエスト４１をプロキシサーバ２００−１に送信すると、リクエスト４１を受信したプロキシサーバ２００−１のＨＴＴＰ処理部２０１は、そのメディアセグメントのレスポンスメッセージ５１’をキャッシュ部２０２から読み出す。
【００９６】
レスポンスメッセージ５１’を読み出したＨＴＴＰ処理部２０１は、ヘッダ部に”Connection:Close”のヘッダがあることを確認すると（Ｓ２３）、レスポンスメッセージ５１’をクライアント装置１００−１に送信するとともにクライアント装置１００−１との接続状態を解除する（Ｓ２４）。これにより、クライアント装置１００−１は、プロキシサーバ２００との接続状態が解除されたことを認識する。したがって、再生部１０２が、このレスポンスメッセージ５１’のメディアセグメント（すなわち、対象映像コンテンツの最後のメディアセグメント）の再生を終えた時点で、対象映像コンテンツの再生が完了することになる。
【００９７】
一方、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認したマルチキャスト処理部２０３は、その旨をＨＴＴＰ処理部２０１に通知し、ＨＴＴＰ処理部２０１は、図９（ｃ）に示すようなマルチキャスト受信終了通知（対象マルチキャストグループからの離脱を要求するLEAVEメッセージ）４３をプロキシサーバ２５０に送信する。
【００９８】
LEAVEメッセージ４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスを返却し、受信したメッセージがLEAVEメッセージ４３であることを確認する（Ｓ２６）。
【００９９】
そして、ＨＴＴＰ処理部２５１は、対象マルチキャストグループに所属するものとして記録されている、マルチキャストグループ情報記憶部２５４内のプロキシサーバ２００−１のアドレスを削除する（Ｓ２７）。これにより、プロキシサーバ２００−１が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
【０１００】
なお、同様に、クライアント装置１００−２〜１００−４およびプロキシサーバ２００−２〜２００−４に対しても、Ｓ２２以降の処理が施される。すなわち、クライアント装置１００−２〜１００−４においても対象映像コンテンツの映像再生が完了し、プロキシサーバ２００−２〜２００−４が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
【０１０１】
このようにして、対象マルチキャストグループに所属していた全装置が所属から外れるので、対象マルチキャストグループのマルチキャストグループアドレスとして使用していた”224.1.1.1”を別の映像コンテンツをマルチキャスト配信する際に使用できることになる。
【０１０２】
以上、配信システム１の動作例を図６および図７のシーケンス図を用いて説明した。
【０１０３】
ところで、Ｓ２３にて、ＨＴＴＰ処理部２０１およびマルチキャスト処理部２０３が、レスポンスメッセージ５１’のヘッダ部に”Connection:Close”のヘッダがあることを確認するものとした。これに代えて、ＨＴＴＰ処理部２０１およびマルチキャスト処理部２０３は、ヘッダ部のX-Media-Segment-indexヘッダを参照し、メディアセグメントのインデックス値（図８（ｂ）において”1”）と、対象映像コンテンツを構成するメディアセグメントの個数を示す値(図８（ｂ）において”60”)が同値になったか否かを確認するようにしてもよい。そして、同値である場合、ＨＴＴＰ処理部２０１は、その旨をマルチキャスト処理部２０３に通知することにより、マルチキャスト処理部２０３にLEAVEメッセージを送信させてもよい。
【０１０４】
（クライアント装置で映像コンテンツの再生を中断した場合の配信システム１の動作）
次に、ユーザからの再生中断指示によって、クライアント装置１００−１が対象映像コンテンツの再生を中断する場合の配信システム１の動作について図１３を参照しながら以下に説明する。ここでは、クライアント装置１００−１が配信サーバ３００から対象映像コンテンツの配信を受けている唯一の装置であることを前提として説明する。
【０１０５】
図１３は、映像コンテンツの再生を中断する旨の指示をクライアント装置１００−１がユーザから受けた場合における、各装置間の処理の流れを示すシーケンス図である。
【０１０６】
図１３に示すように、図示しない操作部を通じて再生中断指示を受け付けると、クライアント装置１００−１の再生部１０２は対象映像コンテンツの再生を中断する。また、ＨＴＴＰ処理部１０１は、次のメディアセグメントを要求するＨＴＴＰのリクエスト４１のヘッダ部に”Connection:Close”のヘッダを付加したリクエスト４１’をプロキシサーバ２００−１に送信する（Ｓ２８）。
【０１０７】
リクエスト４１’を受信したプロキシサーバ２００−１のＨＴＴＰ処理部２０１は、リクエスト４１’のヘッダ部に”Connection:Close”のヘッダが付加されていることを確認する（Ｓ２９）。そして、ＨＴＴＰ処理部２０１は、メディアセグメントのレスポンスメッセージ５１をキャッシュ部２０２から読み出して、クライアント装置１００−１に送信するとともに、クライアント装置１００−１との接続状態を解除する。
【０１０８】
また、”Connection:Close”のヘッダが付加されていることを確認したＨＴＴＰ処理部２０１は、付加されている旨をマルチキャスト処理部２０３に通知する（Ｓ３０）。加えて、ＨＴＴＰ処理部２０１は、図９（ｃ）に示すような対象マルチキャストグループからの離脱を要求するLEAVEメッセージ４３をプロキシサーバ２５０に送信する（Ｓ３１）。
【０１０９】
LEAVEメッセージ４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、レスポンスをプロキシサーバ２００に返却するとともに、受信したメッセージがLEAVEメッセージ４３であることを確認する（Ｓ３２）。
【０１１０】
そして、ＨＴＴＰ処理部２５１は、対象マルチキャストグループに所属するものとして記録されている、マルチキャストグループ情報記憶部２５４内のプロキシサーバ２００−１のアドレスを削除する（Ｓ３３）。これにより、プロキシサーバ２００−１が対象映像コンテンツをマルチキャスト配信すべきマルチキャストグループから外れることになる。
【０１１１】
対象マルチキャストグループに所属する装置が存在しなくなると、マルチキャスト処理部２５３は、ＨＴＴＰ処理部２５１にその旨を通知する。そして、ＨＴＴＰ処理部２５１は、ヘッダ部に”Connection:Close”のヘッダを付加してHTTPメッセージを配信サーバ３００に送信する（Ｓ３４）。これにより、配信サーバ３００とプロキシサーバ２５０との接続状態が解除されることになる。
【０１１２】
以上、配信システム１全体の処理の流れを動作例として説明したが、以下では、配信システム１を構成する各装置の動作について図１４〜図２２を参照しながら説明する。
【０１１３】
〔プロキシサーバ２００の動作〕
最初に、クライアント装置１００のプロキシサーバ２００の動作について説明するが、ＨＴＴＰ処理部２０１とマルチキャスト処理部２０３とに分けて動作を説明する。
【０１１４】
（ＨＴＴＰ処理部２０１の動作）
ＨＴＴＰ処理部２０１の動作について図１４を参照しながら説明する。図１４は、ＨＴＴＰ処理部２０１の動作を示すフローチャートである。
【０１１５】
図１４に示すように、ＨＴＴＰ処理部２０１は、クライアント装置１００からメディアセグメントのリクエスト４１を受信する（Ｓ１１０１）。
【０１１６】
次に、ＨＴＴＰ処理部２０１は、キャッシュ部２０２に何らかのデータがキャッシュされているか否かを判定する（Ｓ１１０２）。
【０１１７】
キャッシュ部２０２に何らかのデータがキャッシュされていると判定した場合（Ｓ１１０２においてＹＥＳ）、ＨＴＴＰ処理部２０１は、Ｓ１１０１にて受信したリクエスト４１からリクエストＵＲＩ（図８（ａ）の例では”/content1/1”）を読み出す（Ｓ１１０７）。そして、ＨＴＴＰ処理部２０１は、このリクエストＵＲＩに対応するレスポンスメッセージ（図８（ａ）の例の”/content1/1”に対応するレスポンスメッセージは、ファイル名がcontent1であるような対象映像コンテンツの先頭メディアセグメントのレスポンスメッセージ）をキャッシュ部２０２から読み出す（Ｓ１１０８）。その後、Ｓ１１０９に進む。
【０１１８】
一方、キャッシュ部２０２に何もデータがキャッシュされていないと判定した場合（Ｓ１１０２においてＮＯ）、ＨＴＴＰ処理部２０１は、リクエスト４１をプロキシサーバ２５０に送信し（Ｓ１１０３）、その後、対応するレスポンスメッセージをプロキシサーバ２５０から受信する（Ｓ１１０４）。
【０１１９】
ＨＴＴＰ処理部２０１は、受信したレスポンスメッセージにプロキシサーバ２５０がマルチキャスト通信により該コンテンツを送信可能であることを示すヘッダ情報（X-alternative-castヘッダ）が含まれているか否かを判定する（Ｓ１１０５）。含まれていないと判定した場合（Ｓ１１０５においてＮＯ）、Ｓ１１０９に進み、含まれていると判定した場合（Ｓ１１０５においてＹＥＳ）、Ｓ１１０６に進む。
【０１２０】
Ｓ１１０６において、ＨＴＴＰ処理部２０１は、マルチキャスト受信を行うための指示（受信するマルチキャストアドレスの通知）を行い、Ｓ１１１８にて、JOINメッセージの送受信をプロキシサーバ２５０と行い、Ｓ１１１０に進む。
【０１２１】
Ｓ１１０９において、ＨＴＴＰ処理部２０１は、クライアント装置１００に送信すべきレスポンスメッセージを生成し、Ｓ１１１０に進む。
【０１２２】
Ｓ１１１０において、ＨＴＴＰ処理部２０１は、Ｓ１１０１にて受信したリクエスト４１に通信終了通知（”Connection:Close”ヘッダ）が含まれているか否かを判定する。通信終了通知が含まれていると判定した場合（Ｓ１１１０においてＹＥＳ）、ＨＴＴＰ処理部２０１は、マルチキャスト受信の終了をマルチキャスト処理部２０３に通知し（Ｓ１１１１）、Ｓ１１１２に進む。一方、通信終了通知が含まれていないと判定した場合（Ｓ１１１０においてＮＯ）、Ｓ１１１２に進む。
【０１２３】
Ｓ１１１２において、ＨＴＴＰ処理部２０１は、Ｓ１１０４にて受信したレスポンスに通信終了通知（”Connection:Close”ヘッダ）が含まれているか否かを判定する。通信終了通知が含まれていると判定した場合（Ｓ１１１２においてＹＥＳ）、Ｓ１１１９に進む。Ｓ１１１９において、ＨＴＴＰ処理部２０１は、LEAVEメッセージ４３の送受信をプロキシサーバ２５０と行い、Ｓ１１１５に進む。
【０１２４】
一方、通信終了通知が含まれていないと判定した場合（Ｓ１１１０においてＮＯ）、Ｓ１１１３に進む。Ｓ１１１３において、ＨＴＴＰ処理部２０１は、Ｓ１１０４にて受信したレスポンスが最後のメディアセグメントのレスポンスであるか否かを判定する（Ｓ１１３）。すなわち、ヘッダ部のX-Media-Segment-indexヘッダを参照し、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値であるか否かを判定する。
【０１２５】
最後のメディアセグメントであると判定した場合（Ｓ１１１３においてＹＥＳ）、Ｓ１１１５に進む。一方、最後のメディアセグメントでないと判定した場合（Ｓ１１１３においてＮＯ）、Ｓ１１０９にて生成したレスポンスメッセージをそのままクライアント装置１００に送信し（Ｓ１１１４）、Ｓ１１０１に戻る。
【０１２６】
Ｓ１１１５において、ＨＴＴＰ処理部２０１は、Ｓ１１０９にて生成したレスポンスメッセージに通信終了通知を付加する（Ｓ１１１５）。そして、ＨＴＴＰ処理部２０１は、通信終了通知を含むレスポンスメッセージをクライアント装置１００に送信し（Ｓ１１１６）、クライアント装置１００との接続状態を解除して（Ｓ１１１７）、処理を終了する。
【０１２７】
（マルチキャスト処理部２０３の動作）
マルチキャスト処理部２０３の動作について図１５を参照しながら説明する。なお、ここで説明する動作は、前述したＳ１１０６の処理をＨＴＴＰ処理部２０１が行った場合に開始される動作である。
【０１２８】
図１５は、マルチキャスト処理部２０３の動作を示すフローチャートである。最初に、マルチキャスト処理部２０３は、マルチキャスト受信を開始する旨の通知をＨＴＴＰ処理部２０１から受信する（Ｓ１２０１）。
【０１２９】
その後、マルチキャスト処理部２０３は、マルチキャストデータ受信のため、初期化を行う。具体的には、マルチキャスト配信を受けるため（プロキシサーバ２５０から定期的に送信されるクエリーに応答するため）に、ＨＴＴＰ処理部２０１からマルチキャストグループアドレスを取得する（Ｓ１２０２）。
【０１３０】
その後、マルチキャスト処理部２０３は、マルチキャストのパケットを順次受信し（Ｓ１２０３）、Ｓ１２０５にて受信した複数のパケットを、メディアセグメントのHTTP形式のレスポンスメッセージに変換する（Ｓ１２０４）。
【０１３１】
その後、マルチキャスト処理部２０３は、変換により得られたレスポンスメッセージをキャッシュ部２０２にキャッシュする（Ｓ１２０５）とともに、レスポンスメッセージに含まれているヘッダ部のX-Media-Segment-indexヘッダを参照する（Ｓ１２０６）。すなわち、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値であるか否かを判定する。
【０１３２】
マルチキャスト処理部２０３が対象映像コンテンツの全データの受信を完了していない場合（Ｓ１２０７においてＮＯ）、すなわち、メディアセグメントのインデックス値と、対象映像コンテンツを構成するメディアセグメントの個数を示す値と、が同値でない場合、Ｓ１２０３に戻る。
【０１３３】
一方、マルチキャスト処理部２０３が対象映像コンテンツの全データの受信を完了した場合（Ｓ１２０７においてＹＥＳ）、Ｓ１２０８に進む。
【０１３４】
Ｓ１２０８において、マルチキャスト処理部２０３は、ＨＴＴＰ処理部２０１にマルチキャスト受信が終了した旨を通知し、処理を終了する。
【０１３５】
〔プロキシサーバ２５０の動作〕
次に、配信サーバ３００のプロキシサーバ２５０の動作について説明するが、ＨＴＴＰ処理部２５１とマルチキャスト処理部２５３とに分けて動作を説明する。
【０１３６】
（ＨＴＴＰ処理部２５１の動作）
ＨＴＴＰ処理部２５１の動作を図１６および図１８を参照して説明する。
【０１３７】
ＨＴＴＰ処理部２５１は、プロキシサーバ２００から対象映像コンテンツのメディアセグメントのリクエストを受信する（Ｓ１３０１）。
【０１３８】
次に、ＨＴＴＰ処理部２５１は、受信したリクエストを配信サーバ３００に送信し（Ｓ１３０２）、該リクエストに対応するレスポンスを配信サーバ３００から受信する（Ｓ１３０３）。
【０１３９】
ＨＴＴＰ処理部２５１は、対象映像コンテンツをすでにマルチキャスト配信中であるか否かを判定する（Ｓ１３０４）。すなわち、ＨＴＴＰ処理部２５１は、マルチキャストグループ情報記憶部２５４を参照し、対象マルチキャストグループに参加しているプロキシサーバ２００が存在するか否かを判定する。
【０１４０】
対象映像コンテンツをマルチキャスト配信中であると判定した場合（Ｓ１３０４においてＹＥＳ）、Ｓ１３０６に進む。一方、対象映像コンテンツをマルチキャスト配信中でないと判定した場合（Ｓ１３０４においてＮＯ）、Ｓ１３０５に進む。
【０１４１】
Ｓ１３０５において、ＨＴＴＰ処理部２５１は、対象映像コンテンツのクライアント装置１００からの要求頻度を確認する。このＳ１３０５の処理は、図６のＳ０５の処理と同じ処理である。すなわち、ＨＴＴＰ処理部２５１は、一定期間内に同一の対象映像コンテンツに対するリクエスト４１を何回受信したかをカウントする。ここで、ＨＴＴＰ処理部２５１は、リクエスト４１に含まれるURIのうちコンテンツのファイル名”content1”が同一であれば、同一の対象映像コンテンツに対するリクエストとしてカウントするようになっている。例えば、“content1/2”を含むリクエスト４１と、”content1/3“を含むリクエスト４１と、を受信した場合、両者が同一の対象映像コンテンツに対するリクエストとしてカウントされる。
【０１４２】
同一の対象映像コンテンツに対するリクエストを一定期間内に受信した回数が所定の回数以上である場合（Ｓ１３０５においてＹＥＳ）、Ｓ１３０６に進む。一方、同一の対象映像コンテンツに対するリクエストを一定期間内に受信した回数が所定の回数未満である場合（Ｓ１３０５においてＮＯ）、Ｓ１３０７に進む。
【０１４３】
Ｓ１３０６において、ＨＴＴＰ処理部２５１は、＜配信方式＞をマルチキャスト配信とするX-alternative-castヘッダを生成して、Ｓ１３０４にて配信サーバ３００から送信されたレスポンスメッセージのヘッダ部にX-alternative-castヘッダを付加する。ここで、X-alternative-castヘッダの＜配信アドレス＞は、すでに対象映像コンテンツをマルチキャスト配信中である場合、対象映像コンテンツの配信に使用しているマルチキャストグループアドレスとなる。一方、対象映像コンテンツをマルチキャスト配信中でない場合、ＨＴＴＰ処理部２５１は、＜配信アドレス＞として、未使用である任意のクラスＤのマルチキャストグループアドレスを使用する。
【０１４４】
Ｓ１３０７において、ＨＴＴＰ処理部２５１は、レスポンスメッセージをプロキシサーバ２００に送信し、Ｓ１３０８に進む。
【０１４５】
ＨＴＴＰ処理部２５１は、プロキシサーバ２００からJOINメッセージを受信した場合（Ｓ１３０８においてＹＥＳ）、対象映像コンテンツをすでにマルチキャスト配信中であるか否かを判定する（Ｓ１３０９）。対象映像コンテンツをすでにマルチキャスト配信中であると判定した場合（Ｓ１３０９においてＹＥＳ）、Ｓ１３１１に進む。また、プロキシサーバ２００から一定期間内にJOINメッセージを受信しなかった場合（Ｓ１３０８においてＮＯ）にも、Ｓ１３１１に進む。
【０１４６】
一方、対象映像コンテンツをすでにマルチキャスト配信中であると判定した場合（Ｓ１３０９においてＹＥＳ）、ＨＴＴＰ処理部２５１は、配信サーバ３００とキープアライブで接続し、配信サーバ３００から対象映像コンテンツの各レスポンスメッセージを取得する処理（図１８を用いて詳細を後述する）を開始する（Ｓ１３１０）。
【０１４７】
Ｓ１３１０において、ＨＴＴＰ処理部２５１は、配信サーバ３００から取得するレスポンスメッセージのヘッダ部に”Connection:Close”ヘッダが含まれているか否かを判定する（Ｓ１３１１）。
【０１４８】
”Connection:Close”ヘッダが含まれていると判定した場合（Ｓ１３１１においてＹＥＳ）、ＨＴＴＰ処理部２５１は、プロキシサーバ２００からLEAVEメッセージを受信するまで待機して（Ｓ１３１２）、受信後に処理を終了する。
【０１４９】
一方、”Connection:Close”ヘッダが含まれていないと判定した場合（Ｓ１３１１においてＮＯ）、Ｓ１３１３に進む。ＨＴＴＰ処理部２５１は、マルチキャスト処理部からマルチキャスト配信終了が通知されたか否かを判定する（Ｓ１３１３）。マルチキャスト配信終了が通知されていないと判定された場合（Ｓ１３１３においてＮＯ）、そのまま処理を終了する。
【０１５０】
一方、マルチキャスト配信終了が通知されたと判定した場合（Ｓ１３１３においてＹＥＳ）、ＨＴＴＰ処理部２５１は、配信サーバとの接続状態を解除し（Ｓ１３１４）、処理を終了する。
【０１５１】
前述した、配信サーバ３００から対象映像コンテンツの各レスポンスメッセージを取得する処理について、図１８を参照して説明する。
【０１５２】
最初に、ＨＴＴＰ処理部２５１は、配信サーバ３００から直前に受信したレスポンスメッセージに基づき、次に配信サーバ３００に送信すべきリクエストのＵＲＩを生成する（Ｓ１５０１）。例えば、配信サーバ３００から直前に受信したレスポンスメッセージのContent-Locationの末尾が”/content1/1”である場合、”/content1/2”をリクエストのＵＲＩとして生成する。
【０１５３】
次に、ＨＴＴＰ処理部２５１は、配信サーバ３００にリクエストを送信し（Ｓ１５０２）、配信サーバ３００からレスポンスを受信する（Ｓ１５０３）。
【０１５４】
そして、ＨＴＴＰ処理部２５１は、配信サーバ３００から受信したレスポンスを、Ｓ１５０２にて送信したリクエストのＵＲＩ情報と関連づけて、キャッシュ部２５２にキャッシュする（Ｓ１５０４）。
【０１５５】
最後に、ＨＴＴＰ処理部２５１は、対象映像コンテンツ(ファイル名が”content1”のコンテンツ)の全レスポンスメッセージを受信したか否かを判定する（Ｓ１５０５）。受信していないレスポンスメッセージがあると判定した場合（Ｓ１５０５においてＮＯ）、Ｓ１５０１に戻る。一方、全レスポンスメッセージを受信したと判定した場合（Ｓ１５０５においてＹＥＳ）、処理を終了する。
【０１５６】
（マルチキャスト処理部２５３の動作）
マルチキャスト処理部２５３の動作について図１７を参照しながら説明する。なお、ここで説明する動作は、前述したＳ１３０８においてＨＴＴＰ処理部２５１がJOINメッセージを受信したときに開始される動作である。
【０１５７】
最初に、マルチキャスト処理部２５３は、JOINメッセージをＨＴＴＰ処理部２５１から取得する（Ｓ１４０１）。
【０１５８】
次に、マルチキャスト処理部２５３は、JOINメッセージに含まれている対象映像コンテンツのファイル名に基づいて対象マルチキャストグループを特定し、対象マルチキャストグループに、JOINメッセージを送信したプロキシサーバ２００のアドレスを登録する。（Ｓ１４０２）。
【０１５９】
次に、マルチキャスト処理部２５３は、キャッシュ部２５２からレスポンスメッセージを読み出して（Ｓ１４０３）、複数のマルチキャストパケットに変換する（Ｓ１４０４）。
【０１６０】
そして、マルチキャスト処理部２５３は、変換により得られた複数のマルチキャストパケットをプロキシサーバ２００に配信する（Ｓ１４０５）。
【０１６１】
その後、マルチキャスト処理部２５３は、ＨＴＴＰ処理部２５１からLEAVEメッセージを受け取ったか否かを判定する（Ｓ１４０６）。LEAVEメッセージを受け取っていないと判定した場合（Ｓ１４０６においてＮＯ）、Ｓ１４０３に戻る。
【０１６２】
一方、LEAVEメッセージを受け取ったと判定した場合（Ｓ１４０６においてＹＥＳ）、マルチキャスト処理部２５３は、そのLEAVEメッセージを送信したプロキシサーバ２００のアドレスを対象マルチキャストグループから削除し（Ｓ１４０７）、Ｓ１４０８に進む。
【０１６３】
Ｓ１４０８において、マルチキャスト処理部２５３は、対象マルチキャストグループに所属する他のプロキシサーバ２００が存在するか否かを判定する。存在すると判定した場合（Ｓ１４０８においてＹＥＳ）、Ｓ１４０３に戻る。
【０１６４】
存在しないと判定した場合（Ｓ１４０８においてＮＯ）、マルチキャスト処理部２５３が対象映像コンテンツのマルチキャスト配信を終了したこと（マルチキャスト配信終了）をＨＴＴＰ処理部２５１に通知して（Ｓ１４０９）、処理を終了する。
【０１６５】
〔クライアント装置１００の動作〕
（クライアント装置１００の動作その１）
次に、クライアント装置１００が対象映像コンテンツの再生指示をユーザから受け付けてから対象映像コンテンツ全体の再生が完了するまでのクライアント装置１００の動作について、図１９〜図２１を参照しながら以下に説明する。
【０１６６】
クライアント装置１００のＨＴＴＰ処理部１０１は、対象映像コンテンツのメディアセグメントのリクエストをプロキシサーバ２００に送信し（Ｓ１７０１）、プロキシサーバ２００からレスポンスを受信する（Ｓ１７０２）。
【０１６７】
ＨＴＴＰ処理部１０１は、Ｓ１７０２にて受信したレスポンスメッセージにmoovヘッダが含まれているか否かを判定する（Ｓ１７０３）。moovヘッダが含まれていると判定した場合（Ｓ１７０３においてＹＥＳ）、Ｓ１７０４に進み、moovヘッダが含まれていないと判定した場合（Ｓ１７０３においてＮＯ）、Ｓ１７０５に進む。
【０１６８】
Ｓ１７０４において、再生部１０２は、moovヘッダを参照することにより、対象映像コンテンツの再生に必要な初期化処理を行う。
【０１６９】
Ｓ１７０５において、Ｓ１７０２にて受信したレスポンスメッセージのX-Timestampの値を参照することにより、メディアセグメント内に欠損部（欠損したムービーフラグメント）が存在するか否かを判定する。
【０１７０】
ここで、ムービーフラグメントの欠損について図２０を参照して説明する。図２０中の左側部分は、配信サーバ３００からプロキシサーバ２５０に送信されるレスポンスメッセージを示しており、図２０中の右側部分は、クライアント装置１００に送信されるレスポンスメッセージを示している。
【０１７１】
図２０中の左側部分に示すレスポンスメッセージから変換された複数のマルチキャストパケット５２は、プロキシサーバ２００に送信されるが、基幹ネットワーク５００を通過する過程で一部のパケット５２が欠落する場合がある。図２０の例では、ムービーフラグメント０３およびムービーフラグメント０４を構成するパケット５２が欠落しており、クライアント装置１００が受信するレスポンス５１は、ムービーフラグメント０３およびムービーフラグメント０４が欠損したデータとなっている。
【０１７２】
なお、ムービーフラグメント０３およびムービーフラグメント０４のみが欠損したデータとなるのは、レスポンス５１は、ムービーフラグメントを各パートとするマルチパート形式のレスポンスメッセージであるからである。また、ムービーフラグメント０３およびムービーフラグメント０４の２つのムービーフラグメントが欠損したことは、図２０に示すように、ムービーフラグメントが本実施形態では１秒間のデータであるにもかかわらず、隣接する各パートに含まれるタイムスタンプ（ムービーフラグメント０２のX-Timestamp:1.00と、ムービーフラグメント０５のX-Timestamp:4.00と、）の差が１秒でなく３秒であることから、再生部１０２が検出できるようになっている。
【０１７３】
Ｓ１７０２にて受信したレスポンスメッセージに欠損部が存在しないと判定された場合（Ｓ１７０５においてＮＯ）、Ｓ１７１３に進み、欠損部が存在すると判定された場合（Ｓ１７０５においてＹＥＳ）、Ｓ１７０６に進む。
【０１７４】
Ｓ１７０６において、ＨＴＴＰ処理部１０１は、欠損部を補完するか否かを判定する。すなわち、図示しない操作部を介して予めユーザにより行われた設定（欠損部を補完した上でメディアセグメントを再生すべきか、欠損部を補完せずにメディアセグメントを再生すべきか、の設定）に基づいて、欠損部を補完するか否かを判定する。
【０１７５】
欠損部を補完しないと判定した場合（Ｓ１７０６においてＮＯ）、再生部１０２は、受信したメディアセグメント内のMovie Fragmentデータの再生時間を調整する（Ｓ１７０７）。すなわち、メディアセグメント内のMovie Fragmentデータには、X-TimestampにてMovieFragmentの再生開始時間が記述されており、クライアントは、X-Timesampから再生すべき時刻のMovieFragmentデータを取得し再生を行う。メディアセグメント内に欠損が生じると、再生すべき時刻のMovieFragmentが存在せず、再生が停止してしまうように見えるため、X-Timestampの値を調整して、Movie Fragmentが(時間的に)連続するようにする。例えば、ムービーフラグメント０５のX-Timestampを、ムービーフラグメント０２から連続するように、2.00として取得する。そして、以降のムービーフラグメントのX-Timestampも同様に連続するように調整する。また、再生時に調整してもよい。例えば、欠損したムービーフラグメントが対象映像コンテンツのｔ秒目からｔ＋１秒目までに再生すべきムービーフラグメントである場合、再生部１０２は、欠損したムービーフラグメントのひとつ前のムービーフラグメントがｔ−１秒目からｔ＋１秒目までの２秒間再生されるよう（例えば、（ａ）ひとつ前のムービーフラグメントが１／２倍速再生されるよう、あるいは、（ｂ）ひとつ前のムービーフラグメントが最初の１秒間通常再生され、その後の１秒間該ムービーフラグメントを構成する最後のフレーム（静止画像）が再生されるよう）制御を行う。この制御としては、例えば、再生部１０２は、上記ひとつ前のムービーフラグメントのmoofヘッダに２秒間再生すべき旨の情報を記録する処理が挙げられる。Ｓ１７０７の処理の後、Ｓ１７１３に進む。
【０１７６】
一方、欠損部を補完すると判定した場合（Ｓ１７０６においてＮＯ）、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントを取得するリクエストをプロキシサーバ２００に送信し（Ｓ１７０８）、Ｓ１７０９に進む。欠損したムービーフラグメントを取得するリクエストは、欠損したムービーフラグメントを含むようなメディアセグメントのリクエストであってもよいし、欠損したムービーフラグメントのみを取得するリクエストであってもよい。
【０１７７】
欠損したムービーフラグメントのみを取得するリクエストのURIは、例えば、/＜対象映像コンテンツのファイル名＞/＜メディアセグメントのインデックス番号＞/＜欠損したムービーフラグメントが該メディアセグメント内の何番目のムービーフラグメントであるかを示す値＞のように構成される。例えば、欠損したムービーフラグメントのタイムスタンプ(X-timestamp)が４５である場合、リクエストのURIは、/content1/2/16となる。
【０１７８】
Ｓ１７０２にて受信したメディアセグメントの再生を開始すべき時刻になると、再生部１０２は、Ｓ１７０８のリクエストに対応する欠損部のムービーフラグメントをすでにＨＴＴＰ処理部１０１が取得したか否かを判定する（Ｓ１７０９）。取得したと判定した場合（Ｓ１７０９においてＹＥＳ）、再生部１０２は、欠損したムービーフラグメントを、取得した新たなムービーフラグメントにより補完する（新たなムービーフラグメントに置き換える）（Ｓ１７１０）。Ｓ１７１０の処理の後、Ｓ１７１３に進む。
【０１７９】
一方、まだ取得していないと判定した場合（Ｓ１７０９においてＹＥＳ）、再生部１０２は、受信したメディアセグメント内のMovie Fragmentデータの再生時間を調整する（Ｓ１７１１）。このＳ１７１１の処理は、Ｓ１７０７の処理と同様の処理である。
【０１８０】
その後、再生部１０２は、Ｓ１７０２にて受信したメディアセグメントの各ムービーフラグメントを順次再生する（Ｓ１７１２）。Ｓ１７１２の処理の後、Ｓ１７１４に進む。
【０１８１】
Ｓ１７１３にて、再生部１０２は、Ｓ１７０２にて受信した（あるいはＳ１７１０で補完後の）メディアセグメントの各ムービーフラグメントを順次再生し、Ｓ１７１４に進む。
【０１８２】
Ｓ１７１４において、再生部１０２は、再生したメディアセグメントを図示しない記憶部に蓄積すべきか否かを判定する。すなわち、再生部１０２は、操作部を介してユーザから対象映像コンテンツを録画すべき旨の指示を受けていた場合には蓄積すべきであると判定し、録画すべき旨の指示を受けていなかった場合には蓄積すべきでないと判定する。
【０１８３】
再生したメディアセグメントを蓄積すべきであると判定された場合（Ｓ１７１４においてＹＥＳ）、Ｓ１７１５にて後述するデータ補完処理が行われた後、再生したメディアセグメントを記憶部に蓄積する（Ｓ１７１６）。Ｓ１７１６の処理の後、Ｓ１７１７に進む。一方、蓄積すべきでないと判定された場合（Ｓ１７１４においてＮＯ）、Ｓ１７１７に進む。
【０１８４】
Ｓ１７１７において、再生部１０２は、Ｓ１７１３にて再生したメディアセグメントが対象映像コンテンツの最後のメディアセグメントであるか否かを判定する。最後のメディアセグメントではないと判定された場合（Ｓ１７１７においてＮＯ）、Ｓ１７０１に戻る。一方、最後のメディアセグメントであると判定された場合（Ｓ１７１７においてＹＥＳ）、Ｓ１７１８に進む。
【０１８５】
Ｓ１７１８において、ＨＴＴＰ処理部１０１は、プロキシサーバ２００との接続状態を解除して対象映像コンテンツの再生を終了し、Ｓ１７１９に進む。
【０１８６】
Ｓ１７１９において、再生部１０２は、対象映像コンテンツの各メディアセグメントを録画したか否かを判定する。録画したと判定した場合（Ｓ１７１９においてＹＥＳ）、Ｓ１７２０のデータ補完処理を行い、処理を終了する。録画していないと判定した場合（Ｓ１７１９においてＮＯ）、そのまま処理を終了する。
【０１８７】
（データ補完処理について）
Ｓ１７１５およびＳ１７２０にて行われるデータ補完処理の流れについて図２１を参照しながら以下に説明する。図２１は、クライアント装置１００のデータ補完処理の流れを示すフローチャートである。
【０１８８】
図２１に示すように、クライアント装置１００の再生部１０２は、Ｓ１７１３において再生されたメディアセグメントの中に欠損部が存在するか否かを判定する（Ｓ１８０１）。欠損部が存在すると判定された場合（Ｓ１８０１）、Ｓ１７０８にて既に欠損部のムービーフラグメントを取得するリクエストが出されているが、このリクエストに対応する欠損部のムービーフラグメントをすでにＨＴＴＰ処理部１０１が取得したか否かを判定する（Ｓ１８０２）。欠損部のムービーフラグメントを取得済みであると判定された場合（Ｓ１８０２においてＹＥＳ）、Ｓ１８０３に進み、欠損部のムービーフラグメントをまだ取得していないと判定された場合（Ｓ１８０２においてＮＯ）、Ｓ１８０４に進む。
【０１８９】
Ｓ１８０３において、ＨＴＴＰ処理部１０１は、欠損部を補完するか否かを判定する。すなわち、図示しない操作部を介して予めユーザにより行われた設定（対象映像コンテンツ全体の再生を完了した後に補完するか、対象映像コンテンツの再生中に補完するかの設定）に基づいて、欠損部を補完するか否かを判定する。
【０１９０】
欠損部を補完すると判定された場合（Ｓ１８０３においてＹＥＳ）、Ｓ１８０６に進む。一方、欠損部を補完しないと判定された場合（Ｓ１８０３においてＮＯ）、データ補完処理を終了する。
【０１９１】
Ｓ１８０４において、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントを取得すべきか否かを判定する。ここで、ＨＴＴＰ処理部１０１は、欠損部を補完せずにメディアセグメントを再生すべき旨の指示が出ていた場合には欠損部のムービーフラグメントを取得すべきであると判定し、欠損部を補完した上でメディアセグメントを再生すべき旨の指示が出ていた場合には欠損部のムービーフラグメントを取得すべきでないと判定するようになっている。
【０１９２】
欠損部のムービーフラグメントを取得すべきであると判定された場合（Ｓ１８０４においてＹＥＳ）、ＨＴＴＰ処理部１０１は、欠損部のムービーフラグメントをプロキシサーバ２００から取得し（Ｓ１８０５）、Ｓ１８０６に進む。一方、欠損部のムービーフラグメントを取得すべきでないと判定された場合（Ｓ１８０４にＮＯ）、データ補完処理を終了する。
【０１９３】
Ｓ１８０６において、再生部１０２は、欠損したムービーフラグメントを、Ｓ１７０８またはＳ１８０６にて取得した新たなムービーフラグメントにより補完し、データ補完処理を終了する。
【０１９４】
以上、クライアント装置１００の動作を説明した。以上の説明からわかるように、クライアント装置１００は、受信したメディアセグメントに欠損部が存在する場合に、欠損部のムービーフラグメントをプロキシサーバ２００から取得する。ここで、クライアント装置１００は、欠損部を含むメディアセグメントを再生する前に欠損部のムービーフラグメントを取得した場合には、欠損部を補完した状態でメディアセグメントを再生することができる。また、欠損部を含むメディアセグメントの再生後に欠損部のムービーフラグメントを取得した場合には、欠損部を補完した状態でメディアセグメントを蓄積することにより、完全な状態で対象映像コンテンツを録画することができる。
【０１９５】
（クライアント装置１００の動作その２）
次に、クライアント装置１００が対象映像コンテンツを再生中に再生中断指示をユーザから受け付けた場合のクライアント装置１００の動作について、図２２を参照しながら以下に説明する。
【０１９６】
クライアント装置１００の再生部１０２が対象映像コンテンツ中の再生中（Ｓ１９０１）、随時、再生部１０２は、再生中断指示をユーザから受け付けたか否かを判定する（Ｓ１９０２）。
【０１９７】
再生中断指示を受け付けたと判定された場合（Ｓ１９０２において）、ＨＴＴＰ処理部１０１は、次に、プロキシサーバ２００に送信すべきリクエストとしてヘッダ部に”Connection:Close”ヘッダを付与されたリクエストを生成する（Ｓ１９０３）。
【０１９８】
その後、ＨＴＴＰ処理部１０１は、Ｓ１９０３にて生成したリクエストをプロキシサーバ２００に送信する（Ｓ１９０４）。
【０１９９】
Ｓ１９０４にて送信したリクエストに対応するレスポンスを受信すると、そのレスポンスのメディアセグメントを再生し終えた時点で対象映像コンテンツの再生を終了（中断）する（Ｓ１９０５）。
【０２００】
（配信システム１の動作例２）
次に、クライアント装置１００が対象映像コンテンツの配信要求を出した場合に配信システム１で行われる動作の別の一具体例について、図２４を参照しながら説明する。
【０２０１】
この動作例では、動作の開始時点においてすでにクライアント装置１００−１〜１００−４の４台のクライアント装置１００が対象映像コンテンツのマルチキャスト配信を配信サーバ３００から受け付けているものとし、新たにクライアント装置１００−５が対象映像コンテンツの配信要求を出すものとする。
【０２０２】
また、この動作例では、図示しないライブカメラから配信サーバ３００に入力されているライブ映像が、対象映像コンテンツとしてクライアント装置１００にライブ配信されている。また、配信サーバ３００に入力されるライブ映像はメモリ部３０２に記録された上でライブ配信されるため、ライブ配信が終了した後に、クライアント装置１００は、対象映像コンテンツのＶＯＤ配信を配信サーバ３００から受けることが可能になっている。
【０２０３】
図２４は、配信システム１の上記動作例を示すシーケンス図である。なお、図２４では、クライアント装置１００−２〜１００−４およびプロキシサーバ２００−２〜２００−４の動作の記載は省略している。
【０２０４】
プロキシサーバ２５０のマルチキャスト処理部２５３は、対象映像コンテンツのマルチキャストパケット５２をプロキシサーバ２００に送信する（Ｓ４０）。
【０２０５】
次に、クライアント装置１００−１は、対象映像コンテンツのメディアセグメントのリクエスト４１をプロキシサーバ２００に送信する（Ｓ４１）と、プロキシサーバ２００のＨＴＴＰ処理部２０１は、当該メディアセグメントのレスポンス５１を、Ｓ４０にて受信したマルチキャストパケット５２を用いて生成し、クライアント装置１００−１にレスポンス５１を送信する（Ｓ４２）。
【０２０６】
次に、クライアント装置１００−５が対象映像コンテンツのリクエスト４３をプロキシサーバ２００−５に送信する（Ｓ４３）。ここで、リクエスト４３は、対象映像コンテンツ全体の送信を要求するために用いられるリクエストである。すなわち、リクエスト４３は、対象映像コンテンツ中の指定されたメディアセグメントの送信を要求するために用いられるリクエスト４１とは異なっている。
【０２０７】
リクエスト４３を受信したプロキシサーバ２００−５のＨＴＴＰ処理部２０１は、リクエスト４３をプロキシサーバ２５０に中継する（Ｓ４４）。
【０２０８】
リクエスト４３を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、リクエストのURI(“/content1/”)を確認する（Ｓ４５）。すなわち、対象映像コンテンツ（ファイル名が”content1”のコンテンツ）をすでにマルチキャスト配信しているか否か（すなわち、対象マルチキャストグループに所属する通信装置がすでに存在するか否か）を判定する。ここでは、プロキシサーバ２００−１〜２００−４が対象マルチキャストグループに所属しているので、マルチキャスト配信していると判定する。
【０２０９】
対象映像コンテンツをマルチキャスト配信していると判定したＨＴＴＰ処理部２５１は、X-alternative-castヘッダを生成する。そして、ＨＴＴＰ処理部２５１は、キャッシュ部２５２にキャッシュ済みの最新のメディアセグメント（インデックス値がｔのメディアセグメントとする）のレスポンスメッセージ５１に、＜配信アドレス＞を対象マルチキャストグループのアドレスとするX-alternative-castヘッダを付与する（Ｓ４６）。
【０２１０】
そして、ＨＴＴＰ処理部２５１は、X-alternative-castヘッダを含むレスポンスメッセージ５１’をプロキシサーバ２００−５に送信する（Ｓ４７）。
【０２１１】
プロキシサーバ２００−５のＨＴＴＰ処理部２０１は、レスポンスメッセージ５１’をレスポンスメッセージ５１に変換してクライアント装置１００−５に送信する（Ｓ４８）。クライアント装置１００−５の再生部１０２は、ＨＴＴＰ処理部１０１が受信した最新のメディアセグメント（インデックス値ｔのメディアセグメント）のレスポンスメッセージ５１を再生する。これにより、クライアント装置１００−５はライブ映像の再生を開始することになる。
【０２１２】
一方、プロキシサーバ２００−５のＨＴＴＰ処理部２０１は、マルチキャスト受信要求（JOINメッセージ）４２をプロキシサーバ２５０に送信する（Ｓ４９）。
【０２１３】
プロキシサーバ２５０のＨＴＴＰ処理部２５１は、JOINメッセージ４２を受信すると、JOINメッセージ４２に対するレスポンスをプロキシサーバ２００−５に送信する（Ｓ５０）。さらに、ＨＴＴＰ処理部２５１は、プロキシサーバ２００−５のアドレスを対象マルチキャストグループに所属するものとして、マルチキャストグループ情報記憶部２５４に記録する（Ｓ５１）。
【０２１４】
以降、マルチキャスト処理部２５３は、インデックス値がｔ＋１以降のメディアセグメントのマルチキャストパケット５２をプロキシサーバ２００−１〜２００−５に送信するようになる（Ｓ５２）。
【０２１５】
一方、Ｓ４８にて、インデックス値ｔのメディアセグメントのレスポンスメッセージ５１を受信したクライアント装置１００−５のＨＴＴＰ処理部１０１は、次の（インデックス値ｔ＋１の）メディアセグメントを要求するリクエスト４１をプロキシサーバ２００−５に送信し（Ｓ５３）、リクエスト４１に対応するレスポンス５１（インデックス値ｔ＋１のメディアセグメント）を受信する（Ｓ５４）。
【０２１６】
以降、後続するメディアセグメント（インデックス値ｔ＋２、ｔ＋３、・・）について、クライアント装置１００−５は、Ｓ５３とＳ５４との処理を繰り返すことになる。
【０２１７】
以上の動作例２の説明からわかるように、プロキシサーバ２５０から対象映像コンテンツのマルチキャスト配信が行われている場合には、クライアント装置１００からの対象映像コンテンツの配信要求が配信サーバ３００に到達しないようになっている。
【０２１８】
したがって、配信サーバ３００から対象映像コンテンツが配信されるクライアント装置１００の台数が増えたとしても、配信サーバ３００の処理負荷および配信サーバ３００とプロキシサーバ２５０との間のネットワークの負荷が抑えられる。したがって、配信サーバ３００から各クライアント装置１００に効率的に対象映像コンテンツが配信されることになる。
【０２１９】
また、すでに説明したように、クライアント装置１００は、ユーザからの指示に応じて対象映像コンテンツの再生と同時に録画をすることもできるようになっている。上記動作例２において、クライアント装置１００−５が対象映像コンテンツの録画を行うよう設定されていた場合には、クライアント装置１００−５には、対象映像コンテンツのうちインデックス値がｔ以降のメディアセグメントが蓄積されることになる。
【０２２０】
したがって、クライアント装置１００−５は、ライブ配信終了後にＶＯＤ配信される対象映像コンテンツについて、インデックス値がｔ以前のメディアセグメントのリクエスト４１を送信してｔ−１個のレスポンス５１を取得および蓄積することにより、ライブ配信された対象映像コンテンツ全体を効率良く録画することができる。
【０２２１】
（プロキシサーバ２５０の利点）
以上のように、配信システム１のプロキシサーバ２５０において、ＨＴＴＰ処理部２５１は、プロキシサーバ２００から対象映像コンテンツを要求するリクエスト４１が送られたことを検出した場合に、配信サーバ３００の代わりにプロキシサーバ２５０がマルチキャスト通信により対象映像コンテンツを送信可能であることを示すX-alternative-cast情報をプロキシサーバ２００に送信する。また、マルチキャスト処理部２５３は、プロキシサーバ２００からＪＯＩＮメッセージ４２を受信した場合にプロキシサーバ２００を対象マルチキャストグループに登録する。そして、マルチキャスト処理部２５３は、キャッシュ部２５２の対象映像コンテンツを、対象マルチキャストグループに登録された各プロキシサーバ２００にマルチキャスト通信を用いて中継する。
【０２２２】
すなわち、対象映像コンテンツが配信されるクライアント装置１００が３台である（配信要求を受ける頻度が一定未満である）ときには、配信サーバ３００は、図１２（ａ）に示すように、同一内容のメディアセグメントについて、配信要求を３回受けてその度にメディアセグメントのレスポンスを返す。一方、図１２（ｂ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が所定の台数（４台）になる（配信要求を受ける頻度が一定以上になる）と、その後、配信サーバ３００は、同一内容のメディアセグメントについて、配信要求を受けてメディアセグメントのレスポンスを返す処理を１回で済ませることができる。したがって、配信サーバ３００の処理負荷、および配信サーバ３００とプロキシサーバ２５０との間のネットワークの負荷が抑えられることになる。
【０２２３】
また、図１２（ａ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が３台である（配信要求を受ける頻度が一定未満である）ときには、プロキシサーバ２５０も、同一内容のメディアセグメントについて、配信要求を３回受けてその度にメディアセグメントのレスポンスを返す。一方、図１２（ｂ）に示すように、対象映像コンテンツが配信されるクライアント装置１００が所定の台数（４台）になる（配信要求を受ける頻度が一定以上になる）と、プロキシサーバ２５０は、メディアセグメントをマルチキャスト配信することができる。すなわち、４台のクライアント装置１００に同一内容のメディアセグメントを配信するためにプロキシサーバ２５０が送信するデータのデータ量は、メディアセグメント１つ分のデータ量となる。したがって、基幹ネットワークの特にプロキシサーバ２５０に近接する領域の帯域負荷が抑えられることになる。
【０２２４】
さらに、上述したように、メディアセグメントは各パートをムービーフラグメントとするＭＩＭＥマルチパート形式で配信サーバ３００からプロキシサーバ２５０に送信されるが、プロキシサーバ２５０は、１つのパート（ムービーフラグメント）の全部または一部のデータを１つのマルチキャストパケットに格納してマルチキャスト配信するようになっている。したがって、多数のマルチキャストパケットの伝送中に１つのマルチキャストパケットが欠落しても、欠落の影響は１つのムービーフラグメントにしか及ばないようになっている。従って、クライアント装置１００に安定して映像コンテンツを再生させることができるようになっている。
【０２２５】
（実施形態２）
本実施形態では、プロキシサーバ２００は、IGMPのJOINメッセージおよびLEAVEメッセージを送信することにより、マルチキャストグループへの参加およびマルチキャストグループからの離脱を行うようになっている。
【０２２６】
IGMPとは、ＩＰ放送（ＩＰマルチキャスト）において、マルチメディアルーターがマルチキャストデータのルーティングを行う際に用いるプロトコルである。
【０２２７】
一般に、マルチメディアルーターは、マルチキャストグループに参加しているホスト機器が存在するか否かをIGMPを利用して把握するように構成されている。マルチメディアルーターは、マルチキャストグループに参加しているホスト機器に対してマルチキャストデータを送信する。このため、ホスト機器が、あるマルチキャストデータを受信するためには、そのマルチキャストデータの送信先となるマルチキャストグループへの参加を要求するIGMP JOINメッセージをマルチメディアルーターに対して送信する必要がある。
【０２２８】
また、ホスト機器は、マルチキャストデータを継続して受信するためには、一定期間ごとにマルチメディアルーターから送信されるクエリー（IGMP QUERY）に応答する(IGMP REPORTを送信する)必要がある。さらに、ホスト機器は、マルチキャストデータを受信しないようにするために、そのマルチキャストデータの送信先となるマルチキャストグループからの離脱を要求するIGMP LEAVEメッセージをする必要がある。
【０２２９】
このため、マルチメディアルーターは、ホスト機器をマルチキャストグループに参加させる処理、クエリーの送信処理、ホスト機器をマルチキャストグループから離脱させる処理等の各種処理を行うことが必要である。
【０２３０】
このうち、ホスト機器をマルチキャストグループから離脱させる処理は時間を要する処理となっている。これは、マルチメディアルーターは、IGMP LEAVEメッセージを受信すると、マルチキャストデータを送信すべき他のホスト機器が存在するか否かをクエリーにより確認してから、マルチキャストデータの送信を停止するためである。
【０２３１】
したがって、ホスト機器がIGMP LEAVEメッセージを送信してからもしばらくの間、ホスト機器に向けてマルチメディアデータが送信されることになる。
【０２３２】
このため、ホスト機器がある映像コンテンツのマルチキャスト配信を受けている間にチャンネルザッピングが行われると、しばらくの間、チャンネル切換先の映像コンテンツのマルチキャストデータだけでなく、チャンネル切換元の映像コンテンツのマルチキャストデータも送信されることになる。すなわち、マルチキャスト配信では一般に一定の帯域幅が補償されているため、チャンネルザッピングの際にはネットワークの帯域が無駄に圧迫されるという問題がある。
【０２３３】
ここで、ネットワークの帯域圧迫の問題を回避するために、ホスト機器にチャンネル切換元の映像コンテンツのマルチキャストデータが送信されなくなってから、ホスト機器をチャンネル切換先の映像コンテンツを送信先とするマルチキャストグループに参加させることも可能である。ただし、この場合には、チャンネル切換元の映像コンテンツの再生を停止してからチャンネル切換先の映像コンテンツの再生を開始するまでにタイムラグが発生するという別の問題が生じることになる。
【０２３４】
以下、本実施形態における配信システム１の動作例について図２５を参照しながら以下に説明する。なお、本実施形態では、クライアント装置１００−１において、ファイル名が”content1”の映像コンテンツ（「切換元映像コンテンツ」とも称する）を再生中に、ユーザから、再生すべき映像コンテンツをファイル名が”content2”の映像コンテンツ（「切換先映像コンテンツ」とも称する）に切り替えるチャンネル切換の指示が出されるものとする。また、チャンネル切換の指示が出される前に、プロキシサーバ２５０は、切換先映像コンテンツを他のクライアント装置１００にすでにマルチキャスト配信しているものとする。
【０２３５】
図２５は、上記動作例を示すシーケンス図である。実施形態１に示したように、クライアント装置１００−１から切換元映像コンテンツのリクエスト４１を受けたプロキシサーバ２００は、プロキシサーバ２５０からレスポンス５１ａを受信し、切換元映像コンテンツをマルチキャスト配信の送信先とするマルチキャストグループ（「切換元マルチキャストグループ」と称する）への参加を要求するIGMP JOINメッセージをプロキシサーバ２００に送信する（Ｓ５０）。
【０２３６】
IGMP JOINメッセージを受信したマルチキャスト処理部２５３は、プロキシサーバ２００に向けて切換元映像コンテンツのマルチキャストパケット５２の送信（Ｓ５１）を開始する。その後、実施形態１と同様の方法で（以下のＳ５１〜Ｓ５４の処理が反復されて）プロキシサーバ２００−１からクライアント装置１００−１に切換元映像コンテンツのレスポンス５１が配信されていくことになる。
【０２３７】
すなわち、プロキシサーバ２００−１のマルチキャスト処理部２０３は、Ｓ５１にて配信された複数のマルチキャストパケット５２をまとめて、メディアセグメントのレスポンス５１に変換し（Ｓ５２）、キャッシュ部２０２にキャッシュする（Ｓ５３）。
【０２３８】
一方、クライアント装置１００−１は、切換元映像コンテンツのメディアセグメントを要求するリクエスト４１をプロキシサーバ２００−１に送信すると、ＨＴＴＰ処理部２０１は、対応するレスポンス５１をキャッシュ部２０２から読み出して（Ｓ５４）、クライアント装置１００−１に送信する。
【０２３９】
上記Ｓ５１〜Ｓ５４の処理が繰り替えされている間（すなわち、クライアント装置１００−１で切換元映像コンテンツを再生中）に、クライアント装置１００−１が操作部を介してユーザから上記チャンネル切換の指示を受けたものとする。
【０２４０】
チャンネル切換の指示を受け付けたクライアント装置１００−１のＨＴＴＰ処理部１０１は、切換元映像コンテンツのリクエスト４１’（すなわち、”Connection:Close”ヘッダが付加されたリクエスト）をプロキシサーバ２００に送信する（Ｓ５５）。
【０２４１】
同時に、ＨＴＴＰ処理部１０１は、切換先映像コンテンツのリクエスト４１をプロキシサーバ２００に送信する（Ｓ５６）。
【０２４２】
プロキシサーバ２００−１のＨＴＴＰ処理部２０１は、Ｓ５６にて新たに切換先映像コンテンツのリクエスト４１を受信すると、切換元映像コンテンツのリクエスト４１’を受信したか否かを判定する。ここでは、Ｓ５５にてリクエスト４１’を受信しているので、リクエストＵＲＩが変更になったと判定する（Ｓ５７）。リクエストＵＲＩが変更になったと判定したので、ＨＴＴＰ処理部２０１は、リクエスト４１をプロキシサーバ２５０に中継する（Ｓ６０）。
【０２４３】
一方、Ｓ５６にてＨＴＴＰ処理部２０１がリクエスト４１’を受信したので、マルチキャスト処理部２０３は、切換元マルチキャストグループからの離脱を要求するIGMP LEAVEメッセージをプロキシサーバ２５０に送信する（Ｓ５８）。
【０２４４】
プロキシサーバ２５０のマルチキャスト処理部２５３は、プロキシサーバ２００−１を切換元マルチキャストグループからの離脱させる処理を開始する（Ｓ５９）。前述したようにこの処理には一定の時間を要するため、しばらくの間、切換元映像コンテンツのマルチキャストパケット５２はプロキシサーバ２００−１に向けて送信されることになる。この場合、プロキシサーバ２００−１は、マルチキャストパケット５２を破棄することになる。
【０２４５】
一方、リクエスト４１を受信したプロキシサーバ２５０のＨＴＴＰ処理部２５１は、リクエスト４１を配信サーバ３００に中継する（Ｓ６１）。
【０２４６】
切換先映像コンテンツはすでにマルチキャスト配信されているため、ＨＴＴＰ処理部２５１は、リクエスト４１に対応するレスポンス５１を配信サーバ３００から受信すると、レスポンスメッセージ５１に＜配信アドレス＞を切換先マルチキャストグループのアドレスとするX-alternative-castヘッダを付与して（Ｓ６２）、レスポンス５１’を生成する。
【０２４７】
その後、ＨＴＴＰ処理部２５１は、切換先映像コンテンツのレスポンス５１’をプロキシサーバ２００−１に送信する（Ｓ６３）。
【０２４８】
レスポンス５１’を受信したプロキシサーバ２００−１のＨＴＴＰ処理部２０１は、切換先映像コンテンツのレスポンス５１をクライアント装置１００−１に送信する（Ｓ６４）。この時点からクライアント装置１００−１において切換先映像コンテンツの再生が開始される。
【０２４９】
そして、マルチキャスト処理部２０３は、切換先マルチキャストグループへの参加を要求するIGMP JOINメッセージをプロキシサーバ２５０に送信する。これにより、プロキシサーバ２００には、切換先映像コンテンツのマルチキャストパケット５２が配信されるようになる。ここで、マルチキャスト処理部２０３が切換先マルチキャストグループへの参加を要求するIGMP JOINメッセージをプロキシサーバ２５０に送信するタイミングは、マルチキャスト処理部２０３がIGMP JOINメッセージを送信すべきであると判定した時であることが望ましい。具体的には、マルチキャスト処理部２０３が切換元映像コンテンツのマルチキャストパケット５２を受信および破棄しなくなってから一定時間経過したことをもってIGMP JOINメッセージを送信すべきであると判定し、上記一定時間が経過する前のタイミングではIGMP JOINメッセージを送信すべきでないと判定することが望ましい。
【０２５０】
なお、Ｓ５６にてＨＴＴＰ処理部２０１が切換先映像コンテンツ（第２のコンテンツ）のリクエスト４１を受信した場合に、クライアント装置１００−１に送信すべき切換元映像コンテンツ（第１のコンテンツ）のレスポンス５１に”Connection:Close”ヘッダが付加した上で、クライアント装置１００−１に送信するようにしてもよい。この場合、レスポンスの送信直後のタイミングで、切替元映像コンテンツを中継するためにクライアント装置１００−１とプロキシサーバ２００との間で確立されていた接続状態が解除されることになる。
【０２５１】
以上のように、本実施形態の配信システム１では、チャンネル切換が行われた場合にクライアント装置１００は、切換元映像コンテンツのリクエスト４１’（”Connection:Close”ヘッダを含むHTTPリクエスト）と切換先映像コンテンツのリクエスト４１とをプロキシサーバ２００に送信すれば、すぐに切換先映像コンテンツの再生を開始することができる。また、チャンネル切換の間にクライアント装置１００とプロキシサーバ２００とのネットワークの帯域も圧迫されることはない。
【０２５２】
したがって、映像コンテンツをマルチキャスト通信によって受信する（すなわち、チャンネルザッピングの際に切換元マルチキャストグループから離脱を要求するIGMP LEAVEメッセージをマルチメディアルーターに送信する）従来のクライアント装置に比べ、配信システム１のクライアント装置１００は、切換先映像コンテンツの素早い再生と、クライアント装置１００側のネットワーク帯域負荷の抑制と、を両立させることができるという効果を奏する。
【０２５３】
また、切換先映像コンテンツを素早く再生することが可能であるので、切換先映像コンテンツがすでにライブ配信されているライブ映像のコンテンツであるような場合に、ユーザに早いタイミングでライブ映像を視聴させることができる。
【０２５４】
さらに、映像コンテンツが、例えば、H.264で規定された圧縮方式により圧縮符号化されている場合、本実施形態のクライアント装置１００と、上記従来のクライアント装置とで、チャンネル切換されてから切換先映像コンテンツの再生を開始するまでに要する時間の差がさらに広がる場合がある。
【０２５５】
すなわち、映像コンテンツが圧縮符号化されている場合、例えば、クライアント装置は、符号化されたキーフレームのデータを取得してデコードするまで映像をユーザに視聴させることができない。ＩＰマルチキャスト配信では、伝送中にマルチキャストパケットが欠損する可能性がある。すなわち、従来のようにクライアント装置が切換先映像コンテンツのマルチキャストパケットを直接受信する場合には、マルチキャストパケットの欠損によるキーフレームの欠如により、切換先映像コンテンツの再生開始が遅れる可能性がある。
【０２５６】
一方、本実施形態のクライアント装置１００では、前述したように、チャンネル切換されてから切換先映像コンテンツの再生を開始するまでは、クライアント装置１００と配信サーバ３００との間は一貫して通信の信頼性の高いＨＴＴＰ通信により行われる。すなわち、切換先映像コンテンツの再生を開始するまでは、配信サーバ３００からクライアント装置１００に切換先映像コンテンツが配信される過程で、キーフレームの欠如が発生することはない。したがって、本実施形態のクライアント装置１００は、切換先映像コンテンツが圧縮符号化されている場合であっても、確実に素早く切換先映像コンテンツの再生を開始することができる。
【０２５７】
なお、配信サーバ３００またはプロキシサーバ２５０をX-Transport-Speedヘッダの処理が可能なように構成し、クライアント装置１００が、X-Transport-Speedヘッダを含むＨＴＴＰリクエストをプロキシサーバ２００に送信することが望ましい。X-Transport-Speedヘッダは、ヘッダで指定した値に応じた伝送速度でデータを伝送するようＨＴＴＰサーバに要求するためのヘッダである。
【０２５８】
この場合、クライアント装置１００は、X-Transport-Speedヘッダとして大きな値を設定することにより、高速で切換先映像コンテンツのデータを受信することが可能である。このため、クライアント装置１００は、切換先映像コンテンツのデータの先頭部分にキーフレームが含まれていない場合であっても、より素早く切換先映像コンテンツの再生を開始することができる。
【０２５９】
なお、プロキシサーバ２５０がマルチメディアルーターの役割を果たす（すなわち、プロキシサーバ２００とプロキシサーバ２５０との間の通信経路上にマルチメディアルーターが存在しない）前提で本実施形態を説明した。ただし、基幹ネットワーク５００としては、プロキシサーバ２００とプロキシサーバ２５０との間にマルチメディアルーターが介在しているようなネットワークも想定される。この場合、プロキシサーバ２００は、プロキシサーバ２５０との通信経路上にあるマルチメディアルーターのうち最もプロキシサーバ２００に近いマルチメディアルーターにIGMP JOINやIGMP LEAVE等の通知を送信することになる。
【０２６０】
（付記事項１）
実施形態１および２では、クライアント装置１００がメディアセグメント単位で対象映像コンテンツのリクエストを出すものとしたが、クライアント装置１００は、対象映像コンテンツ全体を単位としてリクエストを出すようにしてもよい。この場合、プロキシサーバ２５０は、プロキシサーバ２００から受信したリクエストを、メディアセグメント単位のリクエストに変換することになる。
【０２６１】
例えば、ＨＴＴＰ処理部２５１は、対象映像コンテンツ全体のリクエスト(冒頭が”GET /content1/1 HTTP/1.1”で始まるリクエストメッセージ)を受信した場合に、”GET /content1/1 HTTP/1.1”で始まるリクエスト４１を生成して配信サーバ３００に送信し、対応するレスポンスを受信する。
【０２６２】
その後、ＨＴＴＰ処理部２５１は、”GET /content1/t/ HTTP/1.1”で始まるリクエスト４１を生成して配信サーバ３００に送信し、対応するレスポンスを受信するという処理を、２以上のｔについてｔをインクリメントしながら対象映像コンテンツ全体を受信するまで繰り返すことになる。
【０２６３】
（付記事項２）
実施形態１および２では、プロキシサーバ２５０がプロキシサーバ２００からリクエスト４１を受信したときに、マルチキャスト配信を行っていなければ、リクエスト４１を配信サーバ３００に中継するものとしたが、マルチキャスト配信を行っていない状態でプロキシサーバ２５０を以下のように動作させてもよい。
【０２６４】
すなわち、プロキシサーバ２５０は、プロキシサーバ２００からリクエスト４１を受信したときにリクエスト４１に対応するレスポンス５１がキャッシュ部２５２にキャッシュされている場合には、キャッシュされているレスポンス５１（またはレスポンス５１から生成したレスポンス５１’）をプロキシサーバ２００に送信するようにしてもよい。
【０２６５】
（付記事項３）
実施形態１および２では、各装置のIPアドレスがIPv4で規定されるアドレスであるものとして説明したが、これに限定されない。すなわち、各装置のIPアドレスはIPv6で規定されるアドレスであってもよい。この場合、プロキシサーバ２５０は、IPv6で構成されるネットワークを対象として規定されたマルチキャスト配信方式を用いてマルチキャスト配信を行ってもよい。
【０２６６】
（付記事項４）
実施形態１では、クライアント装置１００が、受信したメディアセグメントに欠損部が存在するか否かを判定し、欠損部が存在すると判定した場合に、欠損部のデータを取得する（すなわち、欠損部のムービーフラグメント（または欠損部を含むメディアセグメント）の配信要求を出す）ものとしたが、この処理をクライアント装置１００のプロキシサーバ２００が行ってもよい。また、プロキシサーバ２００は、欠損部のデータを取得するために、パケット再送信技術やＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）等を利用してもよい。
【０２６７】
このようにすることにより、プロキシサーバ２００が複数のクライアント装置１００の代理サーバとなっている場合に、各クライアント装置１００に個別に欠損部のデータの取得を行わせるよりも効率的に欠損部のデータを取得することができる。
【０２６８】
（付記事項５）
実施形態１および２において、クライアント装置１００とプロキシサーバ２００との間のネットワークの障害が発生する場合等に、クライアント装置１００から送信されたリクエスト４１がしばらくプロキシサーバ２００に届かなかったり、プロキシサーバ２００から送信されたレスポンス５１がクライアント装置１００に届かなくなったりして、一定期間映像コンテンツを適切に受信できない場合がある。
【０２６９】
このような場合、上記一定期間の間にプロキシサーバ２００では、キャッシュされるレスポンス５１の累積量がキャッシュ部２０２の記憶容量を超えてしまい、以降にプロキシサーバ２５０からマルチキャスト配信されるマルチキャストパケット５２を破棄してしまうことがある。
【０２７０】
ただし、このような場合であっても、上記一定期間の後に、クライアント装置１００から、キャッシュ部２０２にキャッシュされていないレスポンス５１を要求するリクエスト４１を受信した場合に、プロキシサーバ２００は、リクエスト４１を中継することでプロキシサーバ２５０からレスポンス５１を取得することができる。また、クライアント装置１００は、上記一定期間の間にどのメディアセグメントを取得できなかったかを把握できるので、上記一定期間の間に取得できなかった全メディアセグメントを再取得することができる。
【０２７１】
なお、映像コンテンツが基本レイヤと拡張レイヤとからなる階層化されたコンテンツ（スケーラブルコンテンツ）として提供される場合、または、複数の品質（異なる複数のビットレート、解像度またはフレームレート）のデータを有するコンテンツ（例えば、１３セグとワンセグ）として提供される場合、プロキシサーバ２００は、キャッシュ部２０２にキャッシュするデータの累積量がキャッシュ部２０２の記憶容量を超えるのを抑制するために、以下のように動作させてもよい。
【０２７２】
すなわち、プロキシサーバ２００のマルチキャスト処理部２０３は、キャッシュ部２０２にキャッシュされているデータ量が一定の閾値を超過したと判定した場合に、マルチキャストパケット５２が構成する階層化されたメディアセグメントのうち一部の階層のデータのみを抽出してレスポンスメッセージに変換し、キャッシュ部２０２にキャッシュするようにしてもよい。例えば、マルチキャストパケット５２が構成するメディアセグメントが基本レイヤと拡張レイヤからなる場合、基本レイヤのみを抽出したレスポンスメッセージをキャッシュ部２０２にキャッシュするようにしてもよい。
【０２７３】
さらに、マルチキャスト処理部２０３は、キャッシュ部２０２にキャッシュされているデータ量が一定の閾値を超過したと判定した場合に、マルチキャストパケット５２が構成する複数の品質のデータからなるメディアセグメントのうち一部の品質のデータのみを抽出してレスポンスメッセージに変換し、キャッシュ部２０２にキャッシュするようにしてもよい。例えば、マルチキャストパケット５２が構成するメディアセグメントがワンセグのデータと１３セグのデータとからなる場合、ワンセグのデータのみを抽出したレスポンスメッセージをキャッシュ部２０２にキャッシュするようにしてもよい。
【０２７４】
なお、この場合、プロキシサーバ２００のＨＴＴＰ処理部２０１は、キャッシュ部２０２にキャッシュされたレスポンス５１を読み出すとともに、提供可能な階層や品質（ビットレート）等を示す情報を、レスポンス５１のヘッダ部またはマルチパートの各パートの部分に付加することにより、クライアント装置１００に取得すべき階層（または品質）を変更させることができる。
【０２７５】
（プログラム、記憶媒体）
クライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００（３００’）の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
【０２７６】
後者の場合、クライアント装置１００、プロキシサーバ２００、２５０及び配信サーバ３００は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記クライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０２７７】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
【０２７８】
また、上記プログラムコードは、通信ネットワークを介してクライアント装置１００、プロキシサーバ２００、２５０、及び配信サーバ３００に供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【０２７９】
なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【０２８０】
以上のように、本発明のプロキシサーバでは、上記通信装置が複数存在し、上記送信装置が上記通信装置からの要求に応じて相異なる複数のコンテンツを送信可能に構成されており、上記送信手段が、同一のコンテンツについて一定期間内に一定数以上の通信装置から上記第１の要求が送られたことを検出した場合に限り、上記情報を上記通信装置に送信することが望ましい。
【０２８１】
上記の構成によれば、本発明のプロキシサーバは、同一のコンテンツについて、短期間の間に多数の通信装置からユニキャスト通信によりコンテンツを送信すべき旨の要求を受けた場合に、当該コンテンツをマルチキャスト通信により上記多数の通信装置に中継することができる。また、同一のコンテンツについて、少数の通信装置からしかユニキャスト通信によりコンテンツを送信すべき旨の要求を受けていない場合には、当該コンテンツをユニキャスト通信により上記少数の通信装置に中継する。
【０２８２】
したがって、上記プロキシサーバは、ネットワークの帯域負荷の状況に応じて、マルチキャスト通信によるネットワークの帯域負荷の抑制と、ユニキャスト通信による安定した伝送と、のバランスを良好に維持することができるというさらなる効果を奏する。
【０２８３】
上記送信装置が、上記通信装置からの要求に応じて、上記コンテンツを複数に分割することにより得られる各分割データを順次送信するように構成されており、上記プロキシサーバの上記中継手段は、上記記憶部にキャッシュされた各分割データを上記通信装置に順次中継することが望ましい。
【０２８４】
上記の構成によれば、プロキシサーバは、より効率的にマルチキャスト通信を行うことができるというさらなる効果を奏する。
【０２８５】
上記プロキシサーバでは、上記コンテンツは映像コンテンツであり、上記映像コンテンツは複数のムービーフラグメントから構成されていることが望ましい。
【０２８６】
上記の構成によれば、上記プロキシサーバは、上記コンテンツを再生する再生装置における上記映像コンテンツの細かな再生制御を可能にするというさらなる効果を奏する。
【０２８７】
上記プロキシサーバでは、上記送信装置から送信される上記映像コンテンツが、各パートが１つの上記ムービーフラグメントを含むマルチパート形式のデータであることが望ましい。
【０２８８】
上記の構成によれば、上記プロキシサーバから上記映像コンテンツが伝送される過程で、１つのパートのデータが欠損した場合であっても、上記通信装置が受信できないムービーフラグメントは１つとなる。
【０２８９】
したがって、プロキシサーバは、上記通信装置に欠損したデータを短期間で取得させることができるというさらなる効果を奏する。
【０２９０】
上記プロキシサーバでは、各パートには、上記１つのムービーフラグメントだけでなく、上記複数のムービーフラグメントのうち、当該１つのムービーフラグメントを、上記映像コンテンツを再生する再生装置が何番目に再生すべきかを示す値も含まれていることが望ましい。
【０２９１】
上記の構成によれば、上記プロキシサーバは、マルチパート形式のデータを受信した通信装置に、受信した各パートに上記何番目に再生すべきかを示す値が含まれているか否かを判定させることにより、欠損したムービーフラグメントを容易に把握させることができるというさらなる効果を奏する。
【０２９２】
上記プロキシサーバは、上記中継手段が、マルチキャスト通信により複数のパケットを各通信装置に送信することにより、各通信装置に中継すべき映像コンテンツを中継するように構成されており、上記複数のパケットの各々には、たかだか１つのムービーフラグメントの全体または一部のデータが含まれていることが望ましい。
【０２９３】
上記の構成によれば、上記プロキシサーバがマルチキャスト通信により通信装置に送信したＭ個のパケットのうちＮ個のパケットが伝送中に欠損した場合であっても、上記通信装置は、Ｍ−Ｎ個以上のムービーフラグメントを受信することができる。
【０２９４】
したがって、上記プロキシサーバは、伝送中に相当数のパケットが欠損した場合であっても、上記通信装置に欠損したデータを短期間で取得させることができるというさらなる効果を奏する。
【０２９５】
なお、上記プロキシサーバ（送信側プロキシサーバ）に対し上記第１の要求を送信する上記通信装置として機能するプロキシサーバであって、上記コンテンツを再生する再生装置から受信した上記第１の要求に応じて当該コンテンツを上記再生装置に中継する中継手段と、上記再生装置から受信した上記第１の要求を中継することにより上記情報を受信したときに、上記第２の要求を上記送信側プロキシサーバに送信すべきか否かを判定する第１の判定手段と、を備えているプロキシサーバも本発明の範疇に含まれる。
【０２９６】
上記の構成によれば、上記プロキシサーバは、上記第１の判定手段が上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定した場合に限り、送信側プロキシサーバからマルチキャスト通信によりコンテンツを受信する。
【０２９７】
したがって、上記プロキシサーバは、状況に応じて、マルチキャスト通信によりネットワークの帯域負荷の抑制をするか、ユニキャスト通信により安定した伝送を確保するか、を適宜選択することができるという効果を奏する。
【０２９８】
また、上記プロキシサーバは、上記中継手段が、上記再生装置に上記コンテンツを中継している間、該コンテンツの中継のために上記再生装置と確立した接続状態を保つようになっており、第１のコンテンツを上記再生装置に中継している間に第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツを中継するために上記再生装置と確立した接続状態を解除することが望ましい。
【０２９９】
上記の構成によれば、上記プロキシサーバは、上記再生装置が上記第１のコンテンツから上記第２のコンテンツに再生するコンテンツを切り替えた場合に、上記第１のコンテンツに関する処理をすぐに終了することができる。
【０３００】
したがって、上記プロキシサーバは、上記再生装置の上記コンテンツの切換による処理負荷を低減させることができるというさらなる効果を奏する。
【０３０１】
また、上記プロキシサーバは、上記第１のコンテンツを上記再生装置に中継している間に上記第２のコンテンツを送信すべき旨の第１の要求を受信した場合に、上記第１のコンテンツが中継されている各通信装置が所属するマルチキャストグループから自装置を解除する旨の要求を上記送信側プロキシサーバに送信する送信手段と、上記第１のコンテンツが自装置に送信されなくなってから一定時間が経過したか否かを判定する第２の判定手段と、をさらに備え、上記第１の判定手段は、一定時間が経過したと上記第２の判定手段が判定した場合に、上記第２の要求を上記送信側プロキシサーバに送信すべきであると判定することが望ましい。
【０３０２】
上記の構成によれば、上記プロキシサーバは、上記再生装置が上記第１のコンテンツから上記第２のコンテンツに再生するコンテンツを切り替えた場合において、上記第１のコンテンツおよび上記第２のコンテンツの双方をマルチキャスト通信により上記送信側プロキシサーバから受信するというプロキシサーバ間のネットワークの無駄な帯域負荷を抑制することができるというさらなる効果を奏する。
【０３０３】
なお、本発明は、上記各プロキシサーバと、上記再生装置と、上記送信装置と、を含む通信システムとしても実現することができる。また、本発明に係るプロキシサーバを動作させるためのプログラムであって、コンピュータを上記の各手段として機能させることを特徴とする中継制御プログラム、および、その中継制御プログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
【産業上の利用可能性】
【０３０４】
本発明に係る通信システムは、映像配信システムとして広く利用することができる。
【符号の説明】
【０３０５】
１００                        クライアント装置（再生装置、通信装置）
１００−１、１００−２        クライアント装置
１１０                          ＨＴＴＰ処理部
１２０                          再生部
２００                        クライアント装置のプロキシサーバ（通信装置）
２００−１、２００−２        クライアント装置のプロキシサーバ
２０１                          ＨＴＴＰ処理部（中継手段）
２０２                          キャッシュ部
２０３                          マルチキャスト処理部（送信手段、第１の判定手段、第２の判定手段）
２５０                        配信サーバのプロキシサーバ
２５１                          ＨＴＴＰ処理部（送信手段）
２５２                          キャッシュ部（記憶部）
２５３                          マルチキャスト処理部（登録手段、中継手段）
２５４                          マルチキャストグループ情報記憶部
３００                        配信サーバ
３０１                          ＨＴＴＰ処理部
３０２                          メモリ部
【図１】
2012011449.tif 000003
【図２】
2012011449.tif 000004
【図３】
2012011449.tif 000005
【図４】
2012011449.tif 000006
【図５】
2012011449.tif 000007
【図６】
2012011449.tif 000008
【図７】
2012011449.tif 000009
【図８】
2012011449.tif 000010
【図９】
2012011449.tif 000011
【図１０】
2012011449.tif 000012
【図１１】
2012011449.tif 000013
【図１２】
2012011449.tif 000014
【図１３】
2012011449.tif 000015
【図１４】
2012011449.tif 000016
【図１５】
2012011449.tif 000017
【図１６】
2012011449.tif 000018
【図１７】
2012011449.tif 000019
【図１８】
2012011449.tif 000020
【図１９】
2012011449.tif 000021
【図２０】
2012011449.tif 000022
【図２１】
2012011449.tif 000023
【図２２】
2012011449.tif 000024
【図２３】
2012011449.tif 000025
【図２４】
2012011449.tif 000026
【図２５】
2012011449.tif 000027
【国際調査報告】
2012011449.tif 000028
2012011449.tif 000029