WO2012011466A1

WO2012011466A1 - 中継装置、中継方法、通信システム、中継制御プログラム、および記録媒体

Info

Publication number: WO2012011466A1
Application number: PCT/JP2011/066353
Authority: WO
Inventors: 渡部　秀一; 高橋　真毅; 徳毛　靖昭; 琢也岩波
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2010-07-20
Filing date: 2011-07-19
Publication date: 2012-01-26
Anticipated expiration: 2013-01-20

Abstract

　プロキシ（２００）は、クライアント（１００－１）からＳＤ映像およびＨＤ映像を含むレスポンスを要求するリクエストを受信した場合にＳＤ映像またはＨＤ映像を含むデータがキャッシュされているかを判定する処理部（２２０）とレスポンスをクライアント（１００－１）に送信する送信部（２６０）とを備え、処理部（２２０）は、「キャッシュされている」と判定した場合に、キャッシュを用いて送信すべきレスポンスを生成する。

Description

中継装置、中継方法、通信システム、中継制御プログラム、および記録媒体

　本発明は、送信装置から送信されたコンテンツのデータを再生装置に送信する中継装置、およびそのような中継装置における中継方法に関する。また、本発明は、そのような中継装置としてコンピュータを動作させる中継制御プログラム、および、該中継制御プログラムを記憶している記録媒体に関する。さらに、本発明は、そのような中継装置と、該中継装置が送信したコンテンツのデータを受信する受信装置とを含む通信システムに関する。

　近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等で構成されたＷＥＢページを見るだけでなく、動画コンテンツや音声コンテンツ等を、ストリーミング配信を受けて鑑賞することを望むユーザが増えてきている。

　一般に、ユーザはブラウザでＷＥＢページにアクセスすることにより、ＷＥＢページのテキストデータや静止画データ等を手に入れることができるが、この場合のテキストデータや静止画データは、http(s)プロトコルを用いて送信されるようになっている。

　一方、動画コンテンツや音声コンテンツ等は、リアルタイム性を重視して設計されたプロトコルであるRTPプロトコル等を用いて配信されることが多い。

　ところで、ユーザがインターネットを利用する用途としては、ブラウザでＷＥＢページにアクセスする用途が圧倒的に多い。このため、一般に、ファイヤーウォールでは、http(s)プロトコルの通信に使用するポートは開放されている。一方、RTPプロトコル等の通信はファイヤーウォールで遮断されることもある。

　このため、いつでもどこでも動画や音声等のコンテンツを鑑賞したいというユーザの要望に応えるために、コンテンツの通信をhttp(s)プロトコルで行う技術が開発されている。

　また、特に、イベントをリアルタイムに不特定多数あるいは特定多数にhttp通信で同時配信するライブストリーミング配信が求められている。このようなライブストリーミング配信の代表的な配信方式として、MPEG（Moving Picture Expert Group）のMP4ファイルフォーマットを順次ダウンロードさせることによる配信方式（特許文献１）や、MPEGのISO Media File Formatのフラグメント映像形式を用いた配信方式（特許文献２）等が挙げられる。

　インターネットやＮＧＮ等の基幹ネットワークを利用したライブストリーミング配信では、同一の時間帯に多数の配信要求が発生するため、基幹ネットワークのトラフィック（帯域負荷）が急騰する問題がある。特許文献２に記載されている中間サーバ（プロキシ（代理）サーバ）はこの問題を回避するように設計されている。

　すなわち、特許文献２の中間サーバは、同一内容（すなわち、同一タイトル）のコンテンツに対する配信要求を複数のクライアント装置から受けた場合に、各配信要求をひとつの配信要求にまとめて基幹ネットワークに流し、配信サーバから受け取ったコンテンツを各クライアント装置に逐次的に転送するようになっている。

日本国特許公開公報「特開２００５－１１０２４４号公報（２００５年４月２１日公開）」日本国特許公開公報「特開２００７－１７３９８７号公報（２００７年７月５日公開）」

　上記特許文献２に記載の中間サーバで複数の階層の映像データを保持可能なスケーラブル映像のコンテンツに対する配信要求をクライアント装置から受け付ける場合、以下のような状況が生じる場合がある。

　すなわち、配信サーバが記録しているスケーラブル映像のコンテンツの階層数がＮであるものとすると、配信サーバは、クライアント装置から、クライアント装置の映像再生能力等に応じて、最上位階層がｉ（１≦ｉ≦Ｎ）番目の階層となるようなスケーラブル映像のコンテンツの配信要求を受けることになる。従って、映像再生能力等が相異なる多数のクライアント装置からスケーラブル映像のコンテンツの配信要求を受け付けた場合、配信サーバは、各要求が同一タイトルのコンテンツについての配信要求であっても、Ｎ通りのスケーラブル映像のコンテンツデータをクライアント装置に送信する必要が生じる場合がある。

　そして、この場合、特許文献２の中間サーバは、キャッシュの状況によっては最大Ｎ回配信サーバに配信要求を転送する（すなわち、最大Ｎ回配信サーバから同一タイトルのコンテンツデータを受信する）ことになる。これにより、短期間に多数のクライアント装置から配信要求を受けた場合に、中間サーバの処理負荷、および、中間サーバと配信サーバとの間のネットワークの帯域負荷が極めて高くなるという問題がある。

　本発明は上記の問題を鑑みてなされたものであり、その主な目的は、送信装置から送信されるコンテンツがスケーラブルなコンテンツである場合に、コンテンツを多数の再生装置に中継することに起因する送信装置との間のネットワークの帯域負荷を抑えることが可能な中継装置を実現することにある。

　本発明に係る中継装置は、上記課題を解決するために、再生装置からの要求に応じて、品質が相異なる最大Ｎ個（Ｎ：２以上の整数）の再生対象コンテンツからなるコンテンツデータを送信装置から上記再生装置に中継するとともに該コンテンツデータを記録部に記録する中継装置において、上記再生装置から上記要求を受信した場合に、要求された第１のコンテンツデータを構成する再生対象コンテンツの何れかを含む第２のコンテンツデータが上記記録部に記録されているか否かを判定する判定手段と、上記第１のコンテンツデータを上記再生装置に送信する送信手段と、上記第２のコンテンツデータが上記記録部に記録されていると上記判定手段が判定した場合に、上記第１のコンテンツデータを、上記記録部に記録されている上記第２のコンテンツデータを用いて生成する生成手段と、を備えていることを特徴としている。

　上記の構成によれば、上記中継装置は、再生装置から要求された第１のコンテンツデータを構成するｋ（≦Ｎ）個の再生対象コンテンツの何れかを含む第２のコンテンツデータが上記記録部に記録されている場合に、上記第１のコンテンツデータを、上記記録部に記録されている上記第２のコンテンツデータを用いて生成する。

　したがって、上記中継装置は、ｋ個の再生対象コンテンツから構成される第１のコンテンツデータそのものが上記記録部に記録されていない場合に従来のプロキシサーバのように第１のコンテンツデータそのものを送信装置から取得しなくても、再生装置に中継する第１のコンテンツデータを生成することができる。

　これにより、上記中継装置は、送信装置から送信されるコンテンツがスケーラブルなコンテンツである場合に、コンテンツを多数の再生装置に中継することに起因する送信装置との間のネットワークの帯域負荷を抑えることが出来るという効果を奏する。

　本発明に係る中継方法は、上記課題を解決するために、再生装置からの要求に応じて、品質が相異なる最大Ｎ個（Ｎ：２以上の整数）の再生対象コンテンツからなるコンテンツデータを送信装置から上記再生装置に中継するとともに該コンテンツデータを記録部に記録する中継装置の中継方法において、上記再生装置から上記要求を受信した場合に、要求された第１のコンテンツデータを構成する再生対象コンテンツの何れかを含む第２のコンテンツデータが上記記録部に記録されているか否かを判定する判定工程と、上記第２のコンテンツデータが上記記録部に記録されていると上記判定工程にて判定された場合に、上記第１のコンテンツデータを、上記記録部に記録されている上記第２のコンテンツデータを用いて生成する生成工程と、上記生成工程にて生成された上記第１のコンテンツデータを上記再生装置に送信する送信工程と、を含んでいることを特徴としている。

　上記の構成によれば、本発明に係る中継方法は、本発明に係る中継装置と同様の作用効果を奏する。

　以上のように、本発明の中継装置は、送信装置から送信されるコンテンツがスケーラブルなコンテンツである場合に、コンテンツを多数の再生装置に中継することに起因する送信装置との間のネットワークの帯域負荷を抑えることができる。

本発明の実施形態１に係る通信システムの全体構成を示した図である。図１の通信システムを構成する各装置の詳細な構成を示した機能ブロック図である。各実施形態を示すものであり、ライブカメラからの原映像に対して図１の通信システムの各装置が行う処理を模式的に示した図である。スケーラブル映像を構成する各階層のビットストリームと、ムービーフラグメントと、の関係を模式的に示した図である。メディアセグメントと、ムービーフラグメントと、の関係を模式的に示した図である。各実施形態を示すものであり、（ａ）は、クライアント装置からコンテンツサーバに送信されるリクエストメッセージの一例であり、（ｂ）は、コンテンツサーバからクライアント装置に送信されるレスポンスメッセージの一例である。各実施形態を示すものであり、（ａ）は、クライアント装置からコンテンツサーバに送信されるリクエストメッセージの別の一例であり、（ｂ）は、コンテンツサーバからクライアント装置に送信されるレスポンスメッセージの別の一例である。実施形態１の通信システムの一動作例を示したシーケンス図である。図８のシーケンス図に従った動作中にプロキシサーバが行うメッセージの抽出処理について、抽出対象となるキャッシュされたレスポンスメッセージと、抽出により得られ、クライアント装置に送信されるレスポンスメッセージと、を示した図である。実施形態１の通信システムの別の一動作例を示したシーケンス図である。（ａ）は、図１０のシーケンス図に従った動作中にクライアント装置からコンテンツサーバに送信されるリクエストメッセージの一例である。また、（ｂ）は、図１０のシーケンス図に従った動作中にプロキシサーバが行うメッセージの抽出処理について、抽出対象となるキャッシュされたレスポンスメッセージと、抽出により得られ、クライアント装置に送信されるレスポンスメッセージと、を示した図である。実施形態１の通信システムのさらに別の一動作例を示したシーケンス図である。（ａ）は、図１２のシーケンス図に従った動作中にプロキシサーバからコンテンツサーバに送信されるリクエストメッセージの一例である。また、（ｂ）は、図１０のシーケンス図に従った動作中にプロキシサーバが行うメッセージのマージ処理について、マージに用いる２つのレスポンスメッセージと、マージにより得られ、クライアント装置に送信されるレスポンスメッセージと、を示した図である。実施形態１の通信システムのさらに別の一動作例を示したシーケンス図である。図１４のシーケンス図の各動作が行われた後の続きの動作を表わすシーケンス図である。実施形態１の通信システムに含まれるプロキシサーバの動作を示すフローチャートである。実施形態２の通信システムを構成する各装置の詳細な構成を示した機能ブロック図である。実施形態２の通信システムの一動作例を示したシーケンス図である。図１８のシーケンス図に従った動作中にプロキシサーバが行うメッセージの抽出処理について、抽出対象となるレスポンスメッセージと、抽出により得られ、クライアント装置に送信されるレスポンスメッセージと、を示した図である。実施形態３の通信システムを構成する各装置の詳細な構成を示した機能ブロック図である。実施形態３の通信システムの一動作例を示したシーケンス図である。（ａ）の左右の図は、それぞれ、図２０のシーケンス図に従った動作中に、クライアント装置およびプロキシサーバが送信するリクエストメッセージの一例である。（ｂ）は、図２０のシーケンス図に従った動作中にプロキシサーバが行うメッセージの抽出処理について、抽出対象となる２つのレスポンスメッセージと、抽出により得られ、クライアント装置に送信されるレスポンスメッセージと、を示した図である。クライアント装置からコンテンツサーバに送信されるリクエストメッセージの別の一例を示す図である。実施形態１の通信システムに含まれるプロキシサーバの別の動作を示すフローチャートである。

　（実施形態１）
　本発明の一実施形態に係る通信システムについて図面を参照しながら説明する。

　本実施形態に係る通信システムでは、コンテンツサーバが、ライブ映像のコンテンツデータを要求および再生するクライアント装置に対し、コンテンツデータをライブ配信するようになっている。クライアント装置からの要求、およびコンテンツサーバからの配信は、プロキシサーバによって中継される。

　本実施形態では、データ伝送プロトコルの１つであるHTTP（Hypertext Transfer Protocol）プロトコルのリクエスト・レスポンスの仕組みを用いて、コンテンツデータのやりとりを行うものとする。そして、このコンテンツデータは、HTTPプロトコルで規定されているMIMEマルチパート形式（単に「マルチパート形式」と称する）でやりとりされる。

　また、本実施形態の通信システムで配信されるコンテンツデータは、複数の階層の映像（再生対象コンテンツ）を再生可能な、複数の異なるデータからなるスケーラブルコンテンツデータであり、高低２つの空間解像度（以下、単に「解像度」と呼ぶ）の映像を、それぞれ、ベースレイヤ及び拡張レイヤを併せたデータ、ベースレイヤのみのデータとして再生可能な空間解像度スケーラブル映像のコンテンツデータである。なお、ここで言う解像度は、クライアント装置が表示する映像の表示解像度に直接対応するものでなくてもよい。このため、特に再生映像については、以下、ＨＤクオリティ、ＳＤクオリティの再生映像、といった表現を用いている。

　以下、本発明の一実施形態に係る通信システムの構成について以下に図１および図２を参照しながら説明する。

　図１は、本実施形態に係る通信システムの全体構成を示した図である。通信システム１は、クライアント装置１００－１、１００－２と、プロキシサーバ２００と、コンテンツサーバ３００と、を含むシステムである。

　プロキシサーバ２００と、コンテンツサーバ３００と、は、基幹ネットワーク（インターネット）５００上のノードである。

　また、クライアント装置１００－１、１００－２、およびプロキシサーバ２００は、同一のローカルエリアネットワーク（ＬＡＮ）を構成するように配置されている。

　クライアント装置１００－１、１００－２は、再生映像のクオリティに応じた空間解像度スケーラブル映像のコンテンツデータを配信するようコンテンツサーバ３００に要求するようになっている。また、クライアント装置１００－１は、低解像度（ＳＤクオリティ）および高解像度（ＨＤクオリティ）の映像を再生可能であり、クライアント装置１００－２は、低解像度（ＳＤクオリティ）の映像のみ再生可能である。以下では、クライアント装置１００－１、１００－２は、それぞれ、ＨＤクオリティ、および、ＳＤクオリティの映像を再生するものとして説明を行う。

　プロキシサーバ２００は、一般的なプロキシサーバとしての機能を備えている。

　すなわち、プロキシサーバ２００は、一般的なプロキシサーバと同様に、クライアント装置１００－１、１００－２からの配信要求を受けると、配信要求されたコンテンツデータそのものがキャッシュ（図１で図示せず）に含まれている場合には、配信要求を出したクライアント装置に向けてキャッシュのコンテンツデータを送信する。また、プロキシサーバ２００は、配信要求されたコンテンツデータそのものがキャッシュに含まれていない場合には、配信要求をコンテンツサーバ３００に転送する。さらに、プロキシサーバ２００は、コンテンツサーバ３００から配信されたコンテンツデータをキャッシュするとともに配信要求を出したクライアント装置に向けて転送するようになっている。

　また、プロキシサーバ２００は、以下の特有の機能を備えている。

　すなわち、プロキシサーバ２００は、最上位階層がＳＤクオリティであるコンテンツデータの配信要求を受けたときに最上位階層がＨＤクオリティのコンテンツデータがキャッシュされている場合、配信要求をコンテンツサーバ３００に転送せずに、キャッシュから最上位階層がＳＤクオリティであるコンテンツデータ（ベースレイヤのデータ）を選んで、配信要求を出したクライアント装置に向けて送信する。

　さらに、プロキシサーバ２００は、最上位階層がＨＤクオリティであるコンテンツデータの配信要求を受けたときに最上位階層がＳＤクオリティのコンテンツデータがキャッシュされている場合、不足するＨＤクオリティのコンテンツデータ（拡張レイヤのデータ）のみをコンテンツサーバ３００に配信要求する。そして、プロキシサーバ２００は、コンテンツサーバ３００から受信したＨＤクオリティのコンテンツデータ（拡張レイヤのデータ）と、キャッシュされている最上位階層がＳＤクオリティのコンテンツデータ（ベースレイヤのデータ）と、をマージすることにより、最上位階層がＨＤクオリティであるコンテンツデータを生成し、配信要求を出したクライアント装置に向けて送信する。

　コンテンツサーバ３００は、ライブカメラ（図１で図示せず）から入力されるストリーミングの原映像に空間スケーラブル符号化処理を施すことにより、ＳＤクオリティおよびＨＤクオリティの映像を再生可能な、符号化された異なる２個の映像データからなる、空間解像度スケーラブル映像のコンテンツデータを生成する。そして、コンテンツサーバ３００は、ＨＤクオリティのコンテンツデータの配信要求を受け付けた場合には、ＳＤクオリティおよびＨＤクオリティの映像を両方共再生可能な（すなわち、最上位階層がＨＤクオリティの）コンテンツデータを送信する。また、コンテンツサーバ３００は、ＳＤクオリティのコンテンツデータの配信要求を受け付けた場合には、ＳＤクオリティの映像のみを再生可能な（すなわち、最上位階層がＳＤクオリティの）コンテンツデータを送信する。

　以下では、図２を参照しながら、クライアント装置１００－１、１００－２、プロキシサーバ２００、およびコンテンツサーバ３００についての詳細な構成を説明する。

　（クライアント装置１００－１、１００－２）
　クライアント装置１００－１、１００－２は、リクエスト送信部１１０、再生部１２０、レスポンス受信部１３０を備えている。

　リクエスト送信部１１０は、後述するメディアセグメント単位（ライブ映像のコンテンツデータを一定時間ごとに区切った単位）で、同じく後述するムービーフラグメント（フラグメント）を各パートとするマルチパート形式のコンテンツデータの配信要求をリクエストデータとして、プロキシサーバ２００経由でコンテンツサーバ３００に送信する。

　再生部１２０は、レスポンス受信部１３０が受信したレスポンスデータに含まれるマルチパート形式のコンテンツデータを復号して、映像を再生する。最上位階層がＳＤクオリティのコンテンツデータからは、ＳＤクオリティのコンテンツデータを再生される。

　また、最上位階層がＨＤクオリティのコンテンツデータからは、ＨＤクオリティの映像が再生される。

　レスポンス受信部１３０は、リクエスト送信部１１０が送信した配信要求に対応するメディアセグメントごとのコンテンツデータをレスポンスデータとして受信する。

　（プロキシサーバ２００）
　プロキシサーバ２００は、リクエスト受信部２１０、処理部２２０、キャッシュ部２３０、リクエスト送信部２４０、レスポンス受信部２５０、およびレスポンス送信部２６０を備えている。

　リクエスト受信部２１０は、クライアント装置１００－１、１００－２が送信したメディアセグメント単位のリクエストデータを受信し、処理部２２０に供給する。

　リクエスト送信部２４０は、処理部２２０から供給されたリクエストデータをコンテンツサーバ３００に送信する。

　レスポンス受信部２５０は、コンテンツサーバ３００が送信するレスポンスデータを受信して処理部２２０に供給する。

　キャッシュ部２３０は、高速な読み出しおよび書き込みが可能なキャッシュメモリである。

　レスポンス送信部２６０は、処理部２２０から供給されたメディアセグメントを含むレスポンスデータを、対応するリクエストデータを送信したクライアント装置（１００－１または１００－２）に送信する。

　処理部２２０は、リクエスト受信部２１０から供給されたリクエストデータに対応するメディアセグメントを含んだレスポンスデータがキャッシュ部２３０にキャッシュされている場合には、そのレスポンスデータを読み出してレスポンス送信部２６０に供給する。また、処理部２２０は、最上位階層がＳＤクオリティであるメディアセグメントを要求するリクエストデータがリクエスト受信部２１０から供給された場合であって、最上位階層がＨＤクオリティであるメディアセグメントを含んだレスポンスデータがキャッシュ部２３０にキャッシュされている場合、キャッシュ部２３０のレスポンスデータから、最上位階層がＳＤクオリティであるメディアセグメントを抽出してレスポンスデータを形成し、そのレスポンスデータをレスポンス送信部２６０に供給する。

　また、処理部２２０は、リクエスト受信部２１０から供給されたリクエストデータに対応するメディアセグメントを含んだレスポンスデータがキャッシュ部２３０にキャッシュされていない場合には、リクエストデータをそのままリクエスト送信部２４０に供給する。また、処理部２２０は、最上位階層がＨＤクオリティであるメディアセグメントを要求するリクエストデータがリクエスト受信部２１０から供給された場合であって、最上位階層がＳＤクオリティであるメディアセグメントのみを含んだレスポンスデータがキャッシュ部２３０にキャッシュされている場合、ＨＤクオリティのみのメディアセグメントを要求するリクエストデータを生成して、リクエスト送信部２４０に供給する。

　さらに、処理部２２０は、レスポンス受信部２５０から供給されたレスポンスデータ（メディアセグメント）をキャッシュ部２３０にキャッシュする。また、レスポンス受信部２５０から供給されたレスポンスデータのメディアセグメントがＨＤクオリティのみの場合、処理部２２０は、そのメディアセグメントと、キャッシュ部２３０にキャッシュされている最上位階層がＳＤクオリティであるメディアセグメントと、をマージし、最上位階層がＨＤクオリティであるメディアセグメントを含むレスポンスデータを形成する。そして、処理部２２０は、マージにより得られた最上位階層がＨＤクオリティであるメディアセグメントを含むレスポンスデータをレスポンス送信部２６０に供給する。

　（コンテンツサーバ３００）
　コンテンツサーバ３００は、リクエスト受信部３１０、処理部３２０、レスポンス送信部３３０、メモリ部３４０、符号化部３５０、および原映像受信部３６０を備えている。

　リクエスト受信部３１０は、プロキシサーバ２００が送信したリクエストデータを受信し、処理部３２０に供給する。

　処理部３２０は、リクエスト受信部３１０から供給されたリクエストデータに対応するメディアセグメントをメモリ部３４０から読み出してレスポンスデータを形成し、レスポンス送信部３３０に供給する。

　原映像受信部３６０は、図示しないライブカメラが配信した原映像（ライブ映像）を受信し、符号化部３５０に供給する。

　符号化部３５０は、ライブ映像に対し、順次、空間スケーラブル符号化処理を施し、処理後のデータをメモリ部３４０に記録する。すなわち、符号化部３５０は、ＳＤクオリティおよびＨＤクオリティの映像を再生可能な符号化済みのコンテンツデータを順次メモリ部３４０に記録していく。

　レスポンス送信部３３０は、処理部３２０から供給されたレスポンスデータを、対応するリクエストデータを送信したクライアント装置あるいはプロキシサーバに向けて送信する。

　以上、クライアント装置１００－１、１００－２、プロキシサーバ２００、およびコンテンツサーバ３００の詳細な構成について説明した。

　次に、ライブカメラでの撮影により生成された映像が、空間スケーラブル符号化され、コンテンツサーバ３００、プロキシサーバ２００を通してクライアント装置１００－１で再生されるまでの流れを簡単に説明する。

　図３は、この流れを模式的に示した図である。

　図３に示すように、コンテンツサーバ３００の符号化部３５０は、原映像３０に空間スケーラブル符号化処理を施して、ベースレイヤビットストリームBase、拡張レイヤビットストリームEnhcの２つの符号化ビットストリームを生成する。これらのビットストリームは、後述するようにそれぞれムービーフラグメントに分割されて、コンテンツサーバ３００からプロキシサーバ２００へ、プロキシサーバ２００からクライアント装置１００－１、１００－２へと伝送される。

　クライアント装置１００－１は、最上位階層がＨＤクオリティのコンテンツデータを配信要求する。このため、コンテンツサーバ３００（処理部３２０）あるいはプロキシサーバ２００（処理部２２０）では、ベースレイヤビットストリームBase、拡張レイヤビットストリームEnhcを含むフラグメントを共にクライアント装置１００－１に送信する。そして、クライアント装置１００－１の再生部１２０は、フラグメントをベースレイヤBase、拡張レイヤEnhc２つのビットストリームに戻し、これらをスケーラブル復号して表示部（図示せず）に高画質（ＨＤクオリティ）の映像３２を表示する。

　クライアント装置１００－２は、最上位階層がＳＤクオリティのコンテンツデータを配信要求する。このため、コンテンツサーバ３００（処理部３２０）あるいはプロキシサーバ２００（処理部２２０）では、ベースレイヤビットストリームBaseを含むフラグメントのみをクライアント装置１００－２に送信する。そして、クライアント装置１００－２の再生部１２０は、受信したフラグメントをベースレイヤビットストリームBaseのみに戻し、復号して表示部（図示せず）に低画質（ＳＤクオリティ）の映像３１を表示する。

　（メディアセグメントおよびムービーフラグメントについて）
　次に、前述したムービーフラグメントおよびメディアセグメントについて図４および図５を参照しながら以下に説明する。

　最初に図４を参照しながらムービーフラグメントについて説明する。

　図４は、２つのビットストリームと、ビットストリームを分割・格納した各ムービーフラグメントと、の関係を模式的に示した図である。また、図５は、メディアセグメントと、メディアセグメントを構成する各ムービーフラグメントと、の関係を模式的に示した図である。

　図４に示すように、ベースレイヤビットストリーム(Base)および拡張レイヤビットストリーム(Enhc)の各ビットストリームは、分割されて複数のムービーフラグメントにより格納される。図中、mdatが分割されたビットストリームデータである。図４の例では、ベースレイヤビットストリームは、分割されて、フラグメントB0、フラグメントB1、・・・に格納されており、拡張レイヤビットストリームは、分割されて、フラグメントE0、フラグメントE1・・に格納されている。なお、図４からわかるように、各ムービーフラグメントに格納されたビットストリームの分割データは、ビットストリームを一定期間単位で区切った単位部分に対応している。

　そして、ベースレイヤビットストリームおよび拡張レイヤビットストリームを格納したムービーフラグメントは、全体で、MP4ファイル形式（それぞれ、Base.mp4,Enhc.mp4）を形成している。

　各ビットストリームに対応したMP4ファイルの先頭のムービーフラグメント（フラグメントB0、フラグメントE0）には、moovヘッダ41b,41eが含まれている。moovヘッダ41b,41eは、符号化映像を再生するためのビットストリーム全体に関するメタ情報（初期化情報など）を保持するヘッダである。また、各MP4ファイルの先頭を除くムービーフラグメントには、moofヘッダ42b,42eが含まれている。moofヘッダ42b,42eは、各ムービーフラグメント部分の映像を再生するためのメタ情報を保持するようになっている。

　また、各ビットストリームの各ムービーフラグメントは、ヘッダの他に映像自体のデータmdatが含まれている。各ビットストリームの各ムービーフラグメントのデータmdatには、該ムービーフラグメントに対応する期間における該ビットストリームの部分データがそれぞれ格納されている。

　なお、前述したように各ビットストリームはライブ映像のビットストリームである。すなわち、フラグメントB0,E0のデータmdatには、ライブカメラが撮影（ライブ映像の生成）を開始した時点（撮影時刻０）から一定期間の映像が保持される。同様に、フラグメントBt、Et(t>0)のデータmdatには、ムービーフラグメントB(t-1)、E(t-1)に対応する期間の直後の一定期間の映像が保持される。

　次に図５を参照しながらメディアセグメントについて説明する。

　図５に示すように、メディアセグメントは複数のムービーフラグメントから構成されている。前述したようにメディアセグメントは、ライブ映像のコンテンツデータを一定期間単位で区切った単位部分に対応している。さらに、本実施形態では、このメディアセグメントを、１つのレスポンスデータに格納されるコンテンツデータとして扱う。即ち、メディアセグメントは、一度のリクエストで獲得されるコンテンツデータの単位となっている。

　なお、メディアセグメントが複数のムービーフラグメントから構成されることからわかるように、１つのメディアセグメントに対応する期間の長さは、１つのムービーフラグメントに対応する期間の長さの整数倍となっている（ただし、これはムービーフラグメントの長さが固定の場合であり、ムービーフラグメントの長さが可変の場合には整数倍とは限られない）。本実施形態の図６以降の説明では、説明の簡便のため、１つのメディアセグメントに対応する期間を１０秒とし、１つのムービーフラグメントに対応する期間の長さを１秒として説明する。

　また、図５に示したような最上位階層が拡張レイヤビットストリーム（ＨＤクオリティの映像ストリーム）であるメディアセグメントは、ベースレイヤビットストリームを構成する複数のムービーフラグメントと、拡張レイヤビットストリームを構成する複数のムービーフラグメントと、により構成される。図５の例では、メディアセグメントenhc/0がフラグメントB0～B(N-1)とフラグメントE0～E(N-1)と、により構成され、メディアセグメントenhc/1がフラグメントBN～B(2N-1)とフラグメントEN～E(2N-1)と、により構成されている。

　最上位階層がベースレイヤビットストリーム（ＳＤクオリティの映像ストリーム）であるメディアセグメントは、ベースレイヤビットストリームを構成する複数のムービーフラグメントのみにより構成される。例えば、メディアセグメントbase/0がフラグメントB0～B(N-1)により構成され、メディアセグメントbase/1が、フラグメントBN～B(2N-1)により構成される。

　（リクエストデータおよびレスポンスデータのデータ構造について）
　次に、クライアント装置１００－１（１００－２）と、コンテンツサーバ３００と、の間でやりとりされる基本的なリクエストデータおよびレスポンスデータのデータ構造について、図６および図７を参照しながら以下に説明する。

　最初に、クライアント装置が新規にライブ映像を再生するにあたり、コンテンツサーバ３００に向けて送信するリクエストデータ４Ａ、およびコンテンツサーバ３００から送信されるレスポンスデータ５Ａ（初期レスポンスデータ）について説明する。

　図６（ａ）はリクエストデータ４Ａのデータ構造を示した図であり、図６（ｂ）はレスポンスデータ５Ａのデータ構造を示した図である。リクエストデータ４Ａのうち、先頭の行「GET /content1 HTTP/1.1」はリクエスト行、残りはヘッダ部と呼ばれる。レスポンスデータ５Ａのうち先頭の行「HTTP/1.1 200 OK」はレスポンス行、「Content-Type:～」から空白行の前の「Cache-Control: no-store」まではヘッダ部、空白行の下、「--BOUNDARY」から「--BOUNDARY--」まではボディ部と呼ばれる。なお、図６（ｂ）を含む各図における「{binary-data:fragmentBt}」「{binary-data:fragmentEt}」(t=0,1,2,・・)の部分は、各ムービーフラグメントのバイナリデータを簡略化して記載したものであり、データ構造の内部に「{binary-data:・・・}」というテキストデータが含まれることを意味するものではない。

　図６（ａ）に示すように、リクエストデータ４Ａはマルチパート形式でのデータ送信を要求するHTTPメッセージとなっている（ヘッダ部のAccept: …, multipart/media-segmentがそのことを示している）。以降、リクエストデータ４Ａのことを「マルチパートのリクエストデータ」とも称することにする。

　また、図６（ｂ）に示すように、リクエストデータ４Ａに対応するレスポンスデータ５Ａは、ヘッダ部に、レスポンスデータ５Ａがマルチパート形式のデータであることを示す文字列５０１と、コンテンツサーバ３００がＳＤクオリティおよびＨＤクオリティの映像の要求を受付可能であることを示す文字列５０２－１、５０２－２と、キャッシュ制御に関する情報「Cache-Control: no-store」を含んでいる。また、レスポンスデータ５Ａは、ボディ部に、ベースレイヤ（ＳＤクオリティ）の先頭ムービーフラグメントに関するデータ５０３－１と、拡張レイヤ（ＨＤクオリティ）の先頭ムービーフラグメントに関するデータ５０３－２と、を含んでいる。

　先頭ムービーフラグメントに関するデータ５０３－１、５０３－２は、マルチパート形式の各々のパートにあたる。さらに、各パートは、パートのボディにあたる先頭ムービーフラグメントのデータ自体と、パートのヘッダにあたるコンテンツタイプを示す行(ビデオの形式を示すvideo/mp4、及びデータがbaseかenhcかを示すname)と、を含んでいる。各パートのヘッダとボディも空白行で区切られている。

　また、レスポンスデータ５Ａのヘッダ部に「Cache-Control:no-store」という文字列が含まれていることからわかるように、レスポンスデータ５Ａはコンテンツサーバ３００においてキャッシュされないようになっている。

　さらに、ヘッダ部の文字列５０２－１、５０２－２は、クライアント装置がマルチパート形式で各クオリティの映像を要求するために指定すべきURL（図６（ｂ）では“content1/base/1”、“/content1/enhc/1”）を示している。また、URLの末尾の数値（図６（ｂ）では“1”）は、コンテンツサーバ３００が配信中の（即ち現時点でクライアント装置に配信開始可能な）メディアセグメントに対応する１０秒間の期間が、ライブ映像の先頭から何秒目からの期間であるかを示している。すなわち、末尾の数値がtである場合には、t*10秒目からの期間であることを示している（図６（ｂ）では、“1”が10秒目からの期間であることを示している）。

　なお、以降の説明では、ライブ映像の先頭からt*10秒目からの１０秒間のことを単に「期間ｔ」とも称することにする。また、配信中（クライアント装置に新たに配信開始可能な）メディアセグメントに対応する期間が「期間ｔ」であることを示すレスポンスデータ５Ａを「期間ｔの初期レスポンスデータ」とも称することにする。図６（ｂ）のレスポンスデータ５Ａは「期間１の初期レスポンスデータ」である。

　以上、リクエストデータ４Ａおよびレスポンスデータ５Ａについて説明したが、ここで、レスポンスデータ５Ａにデータ５０３－１、５０３－２を含める理由について簡単に触れておく。

　たびたび述べているように、通信システム１では、クライアント装置はライブ映像のコンテンツデータを再生するため、クライアント装置が最初に再生するライブ映像は、ライブ映像の配信が開始されてから相当期間経過後の映像であることもある。この場合、配信中のメディアセグメントには初期化など符号化映像の再生に必要なメタ情報を含むmoovヘッダ41b,41eが含まれておらず、メディアセグメントを受信してもクライアント装置はライブ映像を再生することができない。

　したがって、クライアント装置がいつでもライブ映像を再生することを可能にするために、moovヘッダ41b、41eを含む先頭ムービーフラグメントを初期レスポンスデータであるレスポンスデータ５Ａに含めて送るようになっている。

　次に、クライアント装置がライブ映像を再生中の期間において１０秒ごとにコンテンツサーバ３００に向けて送信するリクエストデータ４Ｂ、およびコンテンツサーバ３００から送信されるレスポンスデータ５Ｂについて図７を参照しながら説明する。

　図７（ａ）はリクエストデータ４Ｂのデータ構造を示した図であり、図７（ｂ）はレスポンスデータ５Ｂのデータ構造を示した図である。リクエストデータ４Ｂのうち、先頭の行「GET /content1/enhc/1 HTTP/1.1」はリクエスト行、残りはヘッダ部と呼ばれる。レスポンスデータ５Ｂのうち先頭の行「HTTP/1.1 200 OK」はレスポンス行、「Content-Type:～」から空白行の前の「X-Content-Hd-Url: …」まではヘッダ部、空白行の下、「--BOUNDARY」から「--BOUNDARY--」まではボディ部と呼ばれる。

　図７（ａ）の特に“enhc/1”の部分からわかるように、リクエストデータ４Ｂは、最上位階層がＨＤクオリティであるような期間１のレスポンスデータをマルチパート形式で送信するよう要求するHTTPメッセージとなっている。以降、このようなリクエストデータ４Ｂのことを、必要に応じて「期間１のＨＤクオリティのリクエストデータ」のように称する。

　また、図７（ｂ）に示すように、リクエストデータ４Ｂに対応するレスポンスデータ５Ｂは、ヘッダ部に、マルチパート形式であることを示す文字列５０１と、各コンテンツデータ（MP4ファイル）が取得される実際のURLを示す文字列５０２－１、５０２－２と、を含んでいる。なお、「http://www.sample.com/content1/base/t」は、期間ｔのベースレイヤのコンテンツデータが得られるURLを示している。また、「http://www.sample.com/content1/enhc/t」は、期間ｔのベースレイヤおよび拡張レイヤのコンテンツデータが得られるURLを示している。また、レスポンスデータ５Ｂは、ボディ部に、期間ｔ（図７（ｂ）では１）のメディアセグメントを構成する合計２０個のムービーフラグメントに関するデータ（５０３－１、５０３－２、・・・・５０３－２０）を含んでいる。

　２０個のデータ（５０３－１、・・）の各々は、マルチパート形式の各々のパートにあたる。そして、各パートは、パートのボディ部にあたるムービーフラグメント自体のバイナリデータと、パートのヘッダ部にあたる、コンテンツタイプを示す行(ビデオの形式を示すvideo/mp4、及びデータがbaseかenhcかを示すname)と、ライブ映像の先頭を時刻０とした該ムービーフラグメントの再生時刻を示すタイムスタンプと、を含んでいる。

　また、２０個のデータは、含まれるタイムスタンプの値が大きいものほどレスポンスデータ５Ｂの末尾側に記録されるようになっている。

　なお、図７（ｂ）で示したレスポンスデータ５Ｂは、最上位階層がＨＤクオリティであるような期間１のレスポンスデータであるが、ＳＤクオリティのリクエストデータ４Ｂに対応するレスポンスデータ５Ｂでは、ムービーフラグメントに関するデータとしては、ベースレイヤを構成するムービーフラグメントに関する１０個のデータのみが含まれたレスポンスデータとなる。

　なお、レスポンスデータ５Ｂを受信したクライアント装置は、レスポンスデータ５Ｂの先頭側から順に同一時刻のムービーフラグメントを読み取って再生する。すなわち、クライアント装置は、データ５０３－１と５０３－２、データ５０３－３と５０３－４、・・の順にデータに含まれるムービーフラグメントのバイナリデータを読み取り、スケーラブルデコードおよび再生を行う。

　また、図２３は、最上位階層がＨＤクオリティである期間１のレスポンスデータの別の例（レスポンスデータ５Ｂ’）を示した図である。図７（ｂ）のレスポンスデータ５Ｂとの違いは、base、enhcといったレイヤの情報をnameでなく「X-Representation-Id:」として表し、属性、URL等をヘッダ部の「X-Representation-List:」でまとめて表している点、及び、期間ｔのｔを「X-Media-Segment-Index:」で表している点である。また、各パートのヘッダ部に付けられた「X-Representation-Id:」には、「1,2」または「2」が付されており、ＨＤクオリティのムービーフラグメントを抽出する場合には「Id=2」を指定することで全てのフラグメントを、ＳＤクオリティのムービーフラグメントを抽出する場合には「Id=1」を指定することでbaseフラグメントのみを、容易に抽出可能なように構成されている。ここで、Id=1,2は、X-Representation-List:の各URLを示すリストの先頭に付けられた付番1、2に対応する。すなわち、図７（ｂ）と同様に、「http://www.sample.com/content1/base/ｔ」（ｔはX-Media-Segment-Indexで与えられる）は期間ｔのベースレイヤのコンテンツデータ（ムービーフラグメント）が得られるURL、「http://www.sample.com/content1/enhc/t」は期間ｔのベースレイヤおよび拡張レイヤのコンテンツデータ（ムービーフラグメント）が得られるURLを示している。

　以上が本実施形態におけるリクエストデータ及びレスポンスデータの構造である。なお、後述するように、本実施形態では、プロキシサーバがレスポンスデータに含まれるムービーフラグメントを取捨あるいはマージすることで新たなレスポンスデータを形成するが、この処理は、前述したリクエストデータ、レスポンスデータのリクエスト行・レスポンス行、ヘッダ部の情報、マルチパートの各パートヘッダの情報のみを用いて行い、ムービーフラグメントの中のデータを一切見ないで行う。このため、プロキシサーバは容易にスケーラブルコンテンツのデータを扱うことができるようになっている。

　以下、通信システム１の一動作例について、図６～図９を参照しながら説明する。

　（動作例１）
　図８は、上記動作例を示すシーケンス図であり、図９は、図８のシーケンス図に従った動作中にやり取りされるHTTPメッセージを示している。図９の左側のデータは、ステップＳ１２にてコンテンツサーバ３００から送信されるレスポンスデータ５Ｂ－１を示しており、図９の右側のデータは、ステップＳ１９にてプロキシサーバ２００からクライアント装置に送信されるレスポンスデータ５Ｂ－２を示している。

　なお、この動作例は、同一のライブ映像のコンテンツデータについて、クライアント装置１００－１がＨＤクオリティのコンテンツデータを要求した後に、クライアント装置１００－２がＳＤクオリティのコンテンツデータを要求した場合の動作例である。また、前提として、動作の開始前にプロキシサーバ２００のキャッシュは空であるものとし、動作の開始時点でコンテンツサーバ３００は期間１のムービーフラグメントを配信中であるものとする。

　まず、クライアント装置１００－１は、マルチパートのリクエストデータ４Ａをプロキシサーバ２００に送信する（Ｓ１）。プロキシサーバ２００はリクエストデータ４Ａをそのままコンテンツサーバ３００に転送する（Ｓ２）。

　リクエストデータ４Ａを受信したコンテンツサーバ３００は、現在配信中である期間１の初期レスポンスデータ５Ａをプロキシサーバ２００に送信する（Ｓ３）。プロキシサーバ２００は初期レスポンスデータ５Ａをキャッシュせずにそのままクライアント装置１００－１に転送する（Ｓ４）。

　期間１の初期レスポンスデータ５Ａを受信したクライアント装置１００－１は、初期レスポンスデータ５Ａに含まれる先頭ムービーフラグメントのmoovヘッダを参照し、再生を開始するための初期化処理を行う。さらに、クライアント装置１００－１は、初期レスポンスデータ５Ａのヘッダ部の文字列５０２－１、５０２－２を参照することによりＨＤクオリティおよびＳＤクオリティのライブ映像をコンテンツサーバ３００が配信可能であると判定する。

　前述したように、クライアント装置１００－１は、ＨＤクオリティの映像を再生するユーザ指示を受けている（あるいは装置の設定・仕様によりＨＤクオリティの映像を再生することが予め決まっている）ので、クライアント装置１００－１は、期間１のＨＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００に送信する（Ｓ５）。プロキシサーバ２００は、Ｓ５にて送信されたリクエストデータ４Ｂについてクライアント装置１００－１に送信すべきレスポンスデータ５Ｂ（メディアセグメント）を構成する全部または一部の階層がキャッシュに含まれているか判定する。判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照することで行う。ここでは、キャッシュが空なので、プロキシサーバ２００はリクエストデータ４Ｂをそのままコンテンツサーバ３００に送信する（Ｓ６）。

　リクエストデータ４Ｂを受信したコンテンツサーバ３００は、要求された期間１の最上位階層がＨＤクオリティのレスポンスデータ５Ｂをプロキシサーバ２００に送信する（Ｓ７）。レスポンスデータ５Ｂを受信したプロキシサーバ２００は、レスポンスデータ５Ｂをキャッシュするとともに、レスポンスデータ５Ｂをそのままクライアント装置１００－１に送信する（Ｓ８）。

　レスポンスデータ５Ｂを受信したクライアント装置１００－１は、レスポンスデータ５Ｂに含まれる２０個のムービーフラグメントを順にデコードしてＨＤクオリティの映像を再生する。すなわち、この時点からクライアント装置１００－１ではＨＤクオリティのライブ映像の再生が開始されることになる。

　次に、クライアント装置１００－１は、次の期間（期間２）のＨＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００に送信する（Ｓ９）が、同様の処理（すなわち、Ｓ５～Ｓ８までに相当する処理）がその後繰り返される。以下では、クライアント装置１００－１は、期間４のＨＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００に送信する（Ｓ１０）時点からの動作を説明する。

　Ｓ１０～Ｓ１３では、Ｓ５～Ｓ８と同様の処理が行われるが、Ｓ１２において、コンテンツサーバ３００が図９の左側に示すようなレスポンスデータ５Ｂ－１をプロキシサーバ２００に送信し、プロキシサーバ２００はレスポンスデータ５Ｂ－１をキャッシュするものとする。

　ここで、図示しない操作部を介してユーザによる再生指示を受け付けたクライアント装置１００－２は、マルチパートのリクエストデータ４Ａをプロキシサーバ２００に送信する（Ｓ１４）。そして、クライアント装置１００－２と、プロキシサーバ２００と、コンテンツサーバ３００と、の間で、Ｓ２～Ｓ４と同様の処理であるＳ１５～Ｓ１７の処理が行われる。

　そして、Ｓ１７において送信された期間４の初期レスポンスデータ５Ａを受信したクライアント装置１００－２は、期間４のＳＤクオリティのリクエストデータ４Ｂを送信する（Ｓ１８）。

　ここで、プロキシサーバ２００の処理部２２０は、Ｓ１８にて送信されたリクエストデータ４Ｂについてクライアント装置１００－２に送信すべきレスポンスデータ５Ｂ－２（第１のコンテンツデータ）を構成する全部または一部の階層がキャッシュに含まれているか判定する。判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照することで行う。キャッシュには、図９の左側に示すレスポンスデータ５Ｂ－１（第２のコンテンツデータ）がすでに含まれているが、レスポンスデータ５Ｂ－１は、期間４の最上位階層がＨＤクオリティのレスポンスデータである。そして、処理部２２０は、このレスポンスデータ５Ｂ－１を受信したときのリクエストデータ４Ｂのリクエスト行、及びレスポンスデータ５Ｂ－１ヘッダ部の「X-Content-Sd-Url:」「X-Content-Hd-Url:」行から、レスポンスデータ５Ｂ－1がベースレイヤ、拡張レイヤのムービーフラグメントを含んでいることを検出する。

　したがって、ここでは、レスポンスデータ５Ｂ－２を構成する全部の階層（すなわちＳＤクオリティの階層）が含まれていると判定する。このため、プロキシサーバ２００はコンテンツサーバ３００に対して、ここでは配信要求を行わない（すなわち、クライアント装置１００－２から受信したリクエストデータ４Ｂを転送しない）。

　レスポンスデータ５Ｂ－２を構成する全部の階層がキャッシュに含まれていると判定した場合、処理部２２０は、レスポンスデータ５Ｂ－１の中から不要な部分（図９の左側の図において点線で囲まれた部分）を削除することにより、レスポンスデータ５Ｂ－２を抽出することができる。この処理は、マルチパートの各パートのヘッダ部に記載されたコンテンツタイプを示す情報（図９中、ムービーフラグメントのデータがbaseかenhcかを示すname）を参照することで容易に行うことができる。

　最後に、プロキシサーバ２００は、抽出したレスポンスデータ５Ｂ－２をクライアント装置１００―２に送信する（Ｓ１９）。これにより、クライアント装置１００－２でもＳＤクオリティのライブ映像の再生が開始されることになる。

　以上のように、プロキシサーバ２００は、従来のプロキシサーバと異なり、最上位階層がＳＤクオリティのスケーラブル映像の配信要求を受け取った場合に、最上位階層がＨＤクオリティのスケーラブル映像がキャッシュに含まれていれば、コンテンツサーバ３００に別途配信要求を行うことなく、キャッシュから、最上位階層がＳＤクオリティのスケーラブル映像を抽出してクライアント装置に送信することになる。

　これにより、通信システム１のプロキシサーバ２００とコンテンツサーバ３００との間の基幹ネットワークの帯域負荷は、通信１のプロキシサーバ２００を従来のプロキシサーバに置き換えた場合における基幹ネットワークの帯域負荷に比べ小さくなる。

　さらに、上述したように、送信すべきレスポンスデータを構成する全部または一部の階層がキャッシュに含まれているかの判定、並びに、最上位階層がＨＤクオリティのレスポンスデータのキャッシュからＳＤクオリティのレスポンスデータを抽出する処理は、リクエストデータのリクエスト行、レスポンスデータのヘッダ部、及びマルチパートの各パートのヘッダ部のみを参照することで行われ、ムービーフラグメントのデータ自体を確認する必要がない。加えて、抽出の処理は、一部のパートを削除するというHTTPレスポンスデータからHTTPレスポンスデータへの置換処理に過ぎないため、極めて容易に実現できる。このように、本実施形態の通信システムでは、異なる配信要求をするクライアント装置が多数ある場合でも、プロキシサーバの処理の負荷を抑えたコンテンツデータの配信が可能である。

　次に、通信システム１の別の一動作例について、図６、図７、図１０および図１１を参照しながら説明する。

　（動作例２）
　図１０は、動作例２を示すシーケンス図であり、図１１は、図１０のシーケンス図に従った動作中にやり取りされる一部のHTTPメッセージを示している。図１１（ａ）は、Ｓ３８にてクライアント装置１００－２から送信されるマルチパートのリクエストデータ４Ｃを示している。また、図１１（ｂ）の左側のデータは、ステップＳ３２にてコンテンツサーバ３００から送信されるレスポンスデータ５Ｂ－１を示しており、図１１（ｂ）の右側のデータは、ステップＳ３９にてプロキシサーバ２００からクライアント装置に送信されるレスポンスデータ５Ｂ－３を示している。

　ここで、動作例２の動作について説明する前に、クライアント装置で再生している映像と、図示しない撮影中のライブカメラが生成している映像と、にタイムラグがあることを述べておく。

　すなわち、コンテンツサーバ３００が期間ｔのレスポンスデータを送信してからクライアント装置が該レスポンスデータを受信して再生するまでにタイムラグがある。さらに、コンテンツサーバ３００が期間ｔのレスポンスデータを送信するタイミングでは、すでに期間ｔ＋１（またはそれ以降の期間）のレスポンスデータとして送信すべき映像をライブカメラが生成中である。

　動作例２は動作例１と類似しているが、動作例２に従って通信システム１が動作した場合には、クライアント装置１００－２では、前述したタイムラグが動作例１の場合と比べて小さくなるように映像を再生することができる。以下、動作例２の動作について図１０を参照しながら具体的に説明するが、動作例２の動作開始時点の前提条件は、動作例１の場合と同様である。

　Ｓ２１～Ｓ３７までの動作は、動作例１のＳ１～Ｓ１７までの動作と同様であるので、説明を省略する。

　Ｓ３７において送信された期間４の初期レスポンスデータ５Ａを受信したクライアント装置１００－２は、期間４のＳＤクオリティのリクエストデータ４Ｃを送信する（Ｓ３８）。図１１（ａ）からわかるように、リクエストデータ４Ｃは、リクエストデータ４Ｂの末尾に「X-Range:now-and-later-only」という文字列を付加したデータとなっている。このリクエストデータ４Ｃを受信したプロキシサーバ２００では、以下の処理を行う。

　すなわち、プロキシサーバ２００の処理部２２０は、Ｓ３８にて送信されたリクエストデータ４Ｃについてクライアント装置１００－２に送信すべきレスポンスデータ５Ｂ－３を構成する全部または一部の階層がキャッシュに含まれているか判定する。判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照して行う。ここでは、レスポンスデータ５Ｂ－３を構成する全部の階層（すなわちＳＤクオリティの階層）が含まれていると判定する。そして、処理部２２０は、キャッシュのレスポンスデータ５Ｂ－１から拡張レイヤビットストリームを構成する１０個の不要なムービーフラグメントに関するデータを削除する。ここまでは、リクエストデータ４Ｂを受信した場合と同様の動作であるが、処理部２２０は、さらに以下のような動作を行う。

　すなわち、処理部２２０は、キャッシュのレスポンスデータ５Ｂ－１から、ベースレイヤビットストリームを構成する１０個のムービーフラグメントに関するデータのうち、一部のデータを削除する。削除は、マルチパートを構成する各パートのヘッダ部のコンテンツタイプ情報（baseかenhcかを示すname）を参照することで行う。ここで、値の小さいタイムスタンプを含むデータを優先的に削除する。

　削除対象となる該データの個数は、プロキシサーバ２００が、クライアント装置１００－１から期間４のリクエストデータ４Ｂを受信した時点からクライアント装置１００－２のリクエストデータ４Ｃを受信した時点までの期間の長さに応じた個数となる。即ち、この期間の長さ分のムービーフラグメントを削除することによって、プロキシサーバ２００に繋がる各クライアント装置が再生しているコンテンツの再生位置が略揃うこととなる。また、後から要求したクライアント装置でも、ライブカメラでライブ映像を構成する画像が生成されてからその画像がクライアント装置で再生されるまでのタイムラグが小さくなるように（すなわち、クライアント装置でよりリアルタイムに近い映像を表示部に表示することが出来るように）、再生することが可能となる。本動作例では、ベースレイヤを構成する１０個のムービーフラグメントに関するデータのうち４０から４４までの値をタイムスタンプとして含む５つのデータが削除される。削除は、マルチパートの各パートのヘッダ部に記載されたタイムスタンプ情報を参照することで行う。

　結果として、処理部２２０は、図１１（ｂ）の左側のレスポンスデータ５Ｂ－１から点線部分で囲まれた部分を削除して、図１１（ｂ）の右側のレスポンスデータ５Ｂ－３を抽出する。

　最後に、プロキシサーバ２００は、抽出したレスポンスデータ５Ｂ－３をクライアント装置１００―２に送信する（Ｓ３９）。これにより、クライアント装置１００－２でもライブ映像の再生が開始されることになる。

　クライアント装置１００－２では、タイムスタンプの値が４５であるムービーフラグメントから再生が開始されるため、タイムスタンプの値が４０であるムービーフラグメントから再生が開始する実施例１と比べ、クライアント装置１００－２で再生中の映像と、ライブカメラで生成中の映像と、のタイムラグが小さくなることになる。

　次に、通信システム１のさらに別の一動作例について、図６、図７、図１２および図１３を参照しながら説明する。

　（動作例３）
　図１２は、動作例３を示すシーケンス図であり、図１３は、図１２のシーケンス図に従った動作中にやり取りされるHTTPメッセージを示している。図１３（ａ）はステップＳ６８にてプロキシサーバ２００がコンテンツサーバ３００に送信するリクエストデータ４Ｄを示している。また、図１３（ｂ）の左上のデータは、ステップＳ６９にてコンテンツサーバ３００から送信されるレスポンスデータ５Ｃを示しており、図１３（ｂ）の左下のデータは、ステップＳ６１にてコンテンツサーバ３００から送信されるレスポンスデータ５Ｂ－４を示している。さらに、図１３（ｂ）の右側のデータは、ステップＳ７０にてプロキシサーバ２００がクライアント装置に送信するレスポンスデータ５Ｂ－５を示している。

　なお、この動作例は、動作例１および動作例２と異なり、同一のライブ映像のコンテンツデータについて、クライアント装置１００－２がＳＤクオリティのコンテンツデータを要求した後に、クライアント装置１００－１がＨＤクオリティのコンテンツデータを要求した場合の動作例である。また、前提として、動作の開始前にプロキシサーバ２００のキャッシュは空であるものとし、動作の開始時点でコンテンツサーバ３００は期間０のムービーフラグメントを配信中であるものとする。

　まず、クライアント装置１００－２は、マルチパートのリクエストデータ４Ａをプロキシサーバ２００に送信する（Ｓ５１）。プロキシサーバ２００はリクエストデータ４Ａをそのままコンテンツサーバ３００に転送する（Ｓ５２）。

　リクエストデータ４Ａを受信したコンテンツサーバ３００は、現在配信中である（クライアント装置１００－２に新たに配信開始可能な）期間０の初期レスポンスデータ５Ａをプロキシサーバ２００に送信する（Ｓ５３）。プロキシサーバ２００は初期レスポンスデータ５Ａをキャッシュせずにそのままクライアント装置１００－２に転送する（Ｓ５４）。

　期間０の初期レスポンスデータ５Ａを受信したクライアント装置１００－２は、期間０のＳＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００に送信する（Ｓ５５）。プロキシサーバ２００の処理部２２０は、Ｓ５５にて送信されたリクエストデータ４Ｂについてクライアント装置１００－２に送信すべきレスポンスデータ５Ｂ（メディアセグメント）を構成する全部または一部の階層がキャッシュに含まれているか判定する。ここでは、キャッシュが空なので、プロキシサーバ２００はリクエストデータ４Ｂをそのままコンテンツサーバ３００に送信する（Ｓ５６）。前述の通り、判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照して行う。

　リクエストデータ４Ｂを受信したコンテンツサーバ３００は、要求された期間０の最上位階層がＳＤクオリティのレスポンスデータ５Ｂをプロキシサーバ２００に送信する（Ｓ５７）。レスポンスデータ５Ｂを受信したプロキシサーバ２００の処理部２２０は、レスポンスデータ５Ｂをキャッシュする。そして、プロキシサーバ２００は、レスポンスデータ５Ｂをそのままクライアント装置１００－２に送信する（Ｓ５８）。

　以降、Ｓ５５～Ｓ５８の処理を繰り返し、次に、クライアント装置１００－２は、期間２のＳＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００に送信する（Ｓ５９）。Ｓ６０～Ｓ６２の処理は、Ｓ５６～Ｓ５８の処理と同様の処理であるが、図１３（ｂ）の左下に示されているようなレスポンスデータ５Ｂ－４がＳ６１にてプロキシサーバ２００に送信され、プロキシサーバ２００は、レスポンスデータ５Ｂ－４をキャッシュするようになっている。

　ここで、図示しない操作部を介してユーザによる再生指示を受け付けたクライアント装置１００－１は、マルチパートのリクエストデータ４Ａをプロキシサーバ２００に送信する（Ｓ６３）。そして、クライアント装置１００－１と、プロキシサーバ２００と、コンテンツサーバ３００と、の間で、Ｓ５２～Ｓ５４と同様の処理であるＳ６４～Ｓ６６の処理が行われる。

　そして、Ｓ６６において送信された期間２の初期レスポンスデータ５Ａを受信したクライアント装置１００－１は、期間２のＨＤクオリティのリクエストデータ４Ｂを送信する（Ｓ６７）。

　ここで、プロキシサーバ２００の処理部２２０は、Ｓ６７にて送信されたリクエストデータ４Ｂについてクライアント装置１００－１に送信すべきレスポンスデータ５Ｂ－５を構成する全部または一部の階層がキャッシュに含まれているか判定する。判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照することで行われる。キャッシュには、図１３（ｂ）の左下に示すレスポンスデータ５Ｂ－４がすでに含まれているが、レスポンスデータ５Ｂ－４は、期間２の最上位階層がＳＤクオリティのレスポンスデータである。

　したがって、ここでは、レスポンスデータ５Ｂ－５を構成する一部の階層（すなわちＳＤクオリティの階層）が含まれていると判定する。レスポンスデータ５Ｂ－４がＳＤクオリティの階層を含むことは、このレスポンスデータ５Ｂ－４を要求したリクエストデータ４Ｂのリクエスト行からわかる。また、対応するＨＤクオリティのデータがあることが、レスポンスデータ５Ｂ－４のヘッダ部の「X-Cntent-Sd-Url:」「X-Cntent-Hd-Url:」行からわかる。

　レスポンスデータ５Ｂ－５を構成する一部の階層がキャッシュに含まれていると判定した場合、プロキシサーバ２００は、残りの必要な階層（すなわちここではＨＤクオリティの階層）のみを要求するリクエストデータ４Ｄを生成してコンテンツサーバ３００に送信する（Ｓ６８）。

　リクエストデータ４Ｄを受信したコンテンツサーバ３００は、期間２のＨＤクオリティのみのレスポンスデータ５Ｃ（第３のコンテンツデータ）をプロキシサーバ２００に送信する（Ｓ６９）。

　そして、プロキシサーバ２００の処理部２２０は、キャッシュ済みのレスポンスデータ５Ｂ－４（第２のコンテンツデータ）と、Ｓ６９にて送信されたレスポンスデータ５Ｃと、をマージする。すなわち、図１３（ｂ）の左上の図において一点鎖線で囲まれた部分（すなわち、レスポンスデータ５Ｃに含まれる、拡張レイヤビットストリームを構成する１０個のムービーフラグメントに関するデータ）と、図１３（ｂ）の左下の図において破線で囲まれた部分（すなわち、レスポンスデータ５Ｂ－４に含まれる、ベースレイヤビットストリームを構成する１０個のムービーフラグメントに関するデータ）と、の両方を含むレスポンスデータ５Ｂ－５を生成する。この処理は、マルチパートの各パートのヘッダ部に記載されたコンテンツタイプを示す情報（図１３中、ムービーフラグメントのデータがbaseかenhcかを示すname）及びタイムスタンプ情報を参照することで容易に行うことができる。

　最後に、プロキシサーバ２００は、マージにより生成したレスポンスデータ５Ｂ－５（第１のコンテンツデータ）をクライアント装置１００―１に送信する（Ｓ７０）。これにより、クライアント装置１００－１でもライブ映像の再生が開始されることになる。

　以上のように、プロキシサーバ２００は、従来のプロキシサーバと異なり、最上位階層がＨＤクオリティのスケーラブル映像の配信要求を受け取った場合に、最上位階層がＳＤクオリティのスケーラブル映像がキャッシュに含まれていれば、ＨＤクオリティの映像のみを要求する配信要求をコンテンツサーバ３００に送信する（従来のプロキシサーバでは、最上位階層がＨＤクオリティのスケーラブル映像の配信要求をそのままコンテンツサーバに送信する）。

　従って、従来のプロキシサーバでは、コンテンツサーバからＨＤクオリティおよびＳＤクオリティの２つの階層を含むスケーラブル映像を受信することになるが、プロキシサーバ２００では、コンテンツサーバからＨＤクオリティの階層のみのスケーラブル映像を受信することになる。

　これにより、通信システム１のプロキシサーバ２００とコンテンツサーバ３００との間の基幹ネットワークの帯域負荷は、プロキシサーバ２００を従来のプロキシサーバに置き換えた場合における基幹ネットワークの帯域負荷に比べ小さくなる。

　さらに、上述したように、送信すべきレスポンスデータを構成する全部または一部の階層がキャッシュに含まれているかの判定、並びに、最上位階層がＨＤクオリティのスケーラブル映像のレスポンスデータを形成する処理は、リクエストデータのリクエスト行、レスポンスデータのヘッダ部、及びマルチパートの各パートのヘッダ部のみを参照することで行われ、ムービーフラグメントのデータ自体を確認する必要がない。加えて、レスポンスデータの形成の処理は、マルチパートの各パートのデータを順に配列するHTTPレスポンスデータからHTTPレスポンスデータへの置換処理に過ぎないため、極めて容易に実現できる。このように、本実施形態の通信システムでは、異なる配信要求をするクライアント装置が多数ある場合でも、プロキシサーバの処理の負荷を抑えたコンテンツデータの配信が可能である。

　次に、通信システム１のさらに別の一動作例について、図６、図７、図１４および図１５を参照しながら説明する。

　（動作例４）
　図１４および図１５は、動作例４を示すシーケンス図であり、図１５のシーケンス図で表わされる各ステップの処理は、図１４のシーケンス図で表わされる各ステップの処理が終了した後に開始される。

　なお、この動作例では、２つのクライアント装置１００－１、１００－２の両方で映像を再生中の場合において、プロキシサーバ２００がクライアント装置１００－２から期間ｔのＳＤクオリティのリクエストデータ４Ｂを受信したときにキャッシュに期間ｔのレスポンスデータが含まれていなければ、プロキシサーバ２００は、期間ｔのＨＤクオリティのリクエストデータ４Ｂをコンテンツサーバ３００に送信するようになっている。

　Ｓ８１～Ｓ９２の処理は、動作例３のＳ５１～Ｓ６２の処理と同様の処理であるので説明を省略する。

　図示しない操作部を介してユーザによる再生指示を受け付けたクライアント装置１００－１は、マルチパートのリクエストデータ４Ａをプロキシサーバ２００に送信する（Ｓ９３）。そして、クライアント装置１００－１と、プロキシサーバ２００と、コンテンツサーバ３００と、の間で、Ｓ６４～Ｓ６６と同様の処理であるＳ９４～Ｓ９６の処理が行われる。

　そして、Ｓ９６において送信された期間３の初期レスポンスデータ５Ａを受信したクライアント装置１００－１は、期間３のＨＤクオリティのリクエストデータ４Ｂを送信する（Ｓ９７）。

　ここで、プロキシサーバ２００の処理部２２０は、Ｓ９７にて送信されたリクエストデータ４Ｂについてクライアント装置１００－１に送信すべきレスポンスデータ５Ｂを構成する全部または一部の階層がキャッシュに含まれているか判定する。前述の通り、判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照して行う。キャッシュには、ステップＳ９１にて送信された期間３の最上位階層がＳＤクオリティのレスポンスデータ５Ｂが記録されている。したがって、ここでは、クライアント装置１００－１に送信すべきレスポンスデータ５Ｂを構成する一部の階層（すなわちＳＤクオリティの階層）がキャッシュに含まれていると判定する。

　クライアント装置１００－１に送信すべきレスポンスデータ５Ｂを構成する一部の階層（換言すれば、該一部の階層からなるムービーフラグメント）がキャッシュに含まれていると判定した場合、プロキシサーバ２００は、Ｓ９７にて送信されたリクエストデータ４Ｂをそのままコンテンツサーバ３００に転送する（Ｓ９８）。

　そして、リクエストデータ４Ｂを受信したコンテンツサーバ３００は、期間３の最上位階層がＨＤクオリティのレスポンスデータ５Ｂをプロキシサーバ２００に送信する（Ｓ９９）。さらに、プロキシサーバ２００の処理部２２０は、Ｓ９１にて既にキャッシュされている最上位階層がＳＤクオリティのレスポンスデータ５Ｂを、Ｓ９９で新たに受信した最上位階層がＨＤクオリティのレスポンスデータ５Ｂで上書きする。なお、上書きでなく単にキャッシュ部２３０の空いている領域に記録するようにしてもよい。そして、プロキシサーバ２００は、この新たな最上位階層がＨＤクオリティのレスポンスデータ５Ｂをクライアント装置１００－１に送信する（Ｓ１００）。

　この時点から、クライアント装置１００－１ではＨＤクオリティの映像が再生され、クライアント装置１００－２ではＳＤクオリティの映像が再生されている状態となる。

　以降、クライアント装置１００－１が期間ｔ（ｔ≧４）のＨＤクオリティのリクエストデータ４Ｂを送信する前に、クライアント装置１００－２が、期間ｔのＳＤクオリティのリクエストデータ４Ｂを送信し、プロキシサーバ２００はその順で各クライアント装置からのリクエストデータを受信することとなる。

　クライアント装置１００－２は、期間４のＳＤクオリティのリクエストデータ４Ｂを送信する（Ｓ１０１）。

　リクエストデータ４Ｂを受信したプロキシサーバ２００の処理部２２０は、Ｓ１０１にて送信されたリクエストデータ４Ｂについてクライアント装置１００－２に送信すべきレスポンスデータ５Ｂを構成する全部または一部の階層がキャッシュに含まれているか判定する。キャッシュには期間４のレスポンスデータが記録されていないので、プロキシサーバ２００は、「含まれていない」と判定する。

　「含まれていない」と判定した場合、プロキシサーバ２００は、さらに以下の処理を行う。

　すなわち、処理部２２０は、既に接続が確立されている他の全てのクライアント装置（ここでは、クライアント装置１００－１のみ）について、受信したリクエストデータ４Ｂよりも上位の階層で同じコンテンツを再生しているクライアント装置が存在するかを判定する。処理部２２０は、存在すると判定した場合、そのクライアント装置で再生されている該コンテンツの最上位階層（最高解像度）がどの階層であるか（すなわち、該コンテンツの階層数Ｍ）を検出する。判定および検出は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照することにより、行うことが可能である。ここでは、直前のクライアント装置１００－１との通信処理の工程であるＳ９７において、期間３の最上位階層がＨＤクオリティのリクエストデータをクライアント装置１００－１から受信している。このことから、処理部２２０は、クライアント装置１００－１がＨＤクオリティの映像を再生していると判定し、期間４の最上位階層をＨＤクオリティとする要求（より多くの階層（階層数Ｍ＝２）からなる第１のコンテンツデータを対象とする要求）をいずれ受信することを推定する。なお、コンテンツの解像度（階層）が３段階（３階層）以上存在する場合であって、尚且つ、リクエストデータ４Ｂを送信したクライアント装置よりも上位の階層で当該クライアント装置と同じコンテンツを再生しているクライアント装置が複数台存在する場合には、処理部２２０は、複数台のクライアント装置のうち最も上位の階層でコンテンツを再生しているクライアント装置を特定してもよい。そして、処理部２２０は、特定したクライアント装置が再生しているコンテンツの階層数Ｍを検出してもよい。

　このようにして、処理部２２０は、他の各クライアント装置が再生している映像中の最高解像度（ここでは、クライアント装置１００－１のＨＤクオリティ）を認識する。

　そして、プロキシサーバ２００は、期間４の認識した最高解像度（ＨＤクオリティ）のリクエストデータ４Ｂをコンテンツサーバ３００に送信する（Ｓ１０２）。

　リクエストデータ４Ｂを受信したコンテンツサーバ３００は、期間４の最上位階層がＨＤクオリティのレスポンスデータ５Ｂ－１を送信する（Ｓ１０３）。

　プロキシサーバ２００は、受信したレスポンスデータ５Ｂ－１をキャッシュするとともに、キャッシュしたレスポンスデータ５Ｂ－１（図９の左側に示すデータ）から最上位階層がＳＤクオリティのレスポンスデータ５Ｂ－２（図９の右側に示すデータ）を抽出する。

　そして、プロキシサーバ２００は、抽出したレスポンスデータ５Ｂ－２をクライアント装置１００－２に送信する（Ｓ１０４）。

　次に、クライアント装置１００－１は、期間４のＨＤクオリティのリクエストデータ４Ｂを送信する（Ｓ１０５）。

　リクエストデータ４Ｂを受信したプロキシサーバ２００の処理部２２０は、Ｓ１０５にて送信されたリクエストデータ４Ｂについてクライアント装置１００－１に送信すべきレスポンスデータ５Ｂ－１を構成する全部または一部の階層がキャッシュに含まれているか判定する。キャッシュには、クライアント装置１００－１に送信すべきレスポンスデータ５Ｂ－１（Ｓ１０３の処理の直後にキャッシュされたレスポンスデータ）そのものが含まれている。

　プロキシサーバ２００は、クライアント装置１００－１に送信すべきレスポンスデータ５Ｂ－１そのものがキャッシュに含まれていると判定したので、レスポンスデータ５Ｂ－１をキャッシュから読み出してそのままクライアント装置１００－１に送信する（Ｓ１０６）。

　以上のように、動作例４では、ＳＤクオリティの映像を再生中のクライアント装置１００－２から期間ｔのリクエストデータを受信したときにＨＤクオリティの映像を再生中のクライアント装置１００－１から期間ｔのリクエストデータをまだ受信していなければ、プロキシサーバ２００は、期間ｔのＨＤクオリティのリクエストデータをコンテンツサーバ３００に送信する。

　これにより、その後、ＨＤクオリティの映像を再生中のクライアント装置１００－１から期間ｔのリクエストデータを受信したときには、クライアント装置１００－１に送信すべきレスポンスデータはキャッシュされている。

　したがって、期間ｔの映像をクライアント装置１００－１および１００－２の両装置が再生するためにプロキシサーバ２００がコンテンツサーバ３００との間で行われるＨＴＴＰ通信は常にたかだか１往復となる。これは、映像を再生中のクライアント装置が３台以上に増えた場合であっても同様である。

　これにより、プロキシサーバ２００およびコンテンツサーバ３００でのＨＴＴＰ通信に要する処理負荷が抑制されることになる。

　（プロキシサーバ２００の動作）
　以上、状況に応じた通信システム１の動作例を、動作例１～動作例４として説明した。以下では、配信要求のリクエストデータ４Ｂをクライアント装置から受信してから対応するレスポンスデータ（メディアセグメント）５Ｂを該クライアント装置に送信するまでのプロキシサーバ２００の動作を、図５、図６、図９、図１３、および図１６を参照しながら説明する。

　図１６は、プロキシサーバ２００の動作を示すフローチャートである。

　最初に、プロキシサーバ２００のリクエスト受信部２１０は、クライアント装置からリクエストデータを受信する（Ｓ３０１）。

　リクエスト受信部２１０からリクエストデータを供給された処理部２２０は、リクエストデータで指定された期間のレスポンスデータ（メディアセグメント）がキャッシュ部２３０にキャッシュされているか否かを判定する（Ｓ３０２）。

　キャッシュされていると判定された場合（Ｓ３０２においてＹＥＳ）、処理部２２０は、キャッシュ部２３０にキャッシュされているレスポンスデータがクライアント装置に送信すべきレスポンスデータそのものであるかを判定する（Ｓ３０３）。すなわち、クライアント装置に送信すべきメディアセグメントの最上位階層と、キャッシュに記録されているメディアセグメントの最上位階層と、が一致するかを判定する。

　レスポンスデータそのものであると判定された場合（Ｓ３０３においてＹＥＳ）、Ｓ３１２に進む。一方、レスポンスデータそのものでないと判定された場合（Ｓ３０３においてＮＯ）、Ｓ３０４に進む。

　処理部２２０は、キャッシュ部２３０にキャッシュされているレスポンスデータ（第２のコンテンツデータ）がクライアント装置に送信すべきレスポンスデータ（第１のコンテンツデータ）を構成する全階層を含んでいるか（換言すれば、キャッシュ部２３０にキャッシュされているレスポンスデータを構成する階層の集合が、クライアント装置に送信すべきレスポンスデータを構成する階層の集合にクライアント装置に向けて送信すべきレスポンスデータを構成しない階層を要素として加えた集合になっているか）を判定する（Ｓ３０４）。すなわち、キャッシュ部２３０にキャッシュされているメディアセグメントの最上位階層がクライアント装置に送信すべきメディアセグメントの最上位階層よりも階層が高いかを判定する。

　キャッシュ部２３０に全階層を含んでいると判定した場合（Ｓ３０４においてＹＥＳ）、図９に示すように、処理部２２０は、キャッシュ部２３０のレスポンスデータからクライアント装置に送信すべきレスポンスデータの最上位階層よりも高い階層のデータ（第１のコンテンツデータを構成しない再生対象コンテンツ）を削除することにより、クライアント装置に送信すべきレスポンスデータを抽出する（Ｓ３０５）。

　一方、キャッシュ部２３０に全階層を含んでいない（すなわち一部の階層を含んでいる）と判定した場合（Ｓ３０４においてＮＯ）、処理部２２０は、キャッシュ部２３０のレスポンスデータの最上位階層よりも高い階層のデータについてのみ配信を要求するリクエストデータを生成し、リクエスト送信部２４０は、処理部２２０が生成したリクエストデータをコンテンツサーバ３００に送信する（Ｓ３０６）。

　その後、レスポンス受信部２５０は、リクエスト送信部２４０が送信したリクエストデータに対応するレスポンスデータを受信する（Ｓ３０７）。

　図１３（ｂ）に示すように、処理部２２０は、キャッシュ部２３０のレスポンスデータと、レスポンス受信部２５０が受信したレスポンスデータと、をマージすることにより、クライアント装置に送信すべきレスポンスデータを生成する（Ｓ３０８）。

　さらに処理部２２０は、マージされたレスポンスデータをキャッシュ部２３０にキャッシュする（Ｓ３１３）。

　一方、リクエストデータで指定された期間のレスポンスデータ（メディアセグメント）がキャッシュ部２３０に全くキャッシュされていないと判定された場合（Ｓ３０２においてＮＯ）、処理部２２０は、リクエスト受信部２１０がＳ３０１にて受信したリクエストデータをそのままコンテンツサーバ３００に送信する（Ｓ３０９）。

　その後、レスポンス受信部２５０は、リクエスト送信部２４０が送信したリクエストデータに対応するレスポンスデータを受信し（Ｓ３１０）、処理部２２０は、レスポンス受信部２５０が受信したレスポンスデータをキャッシュ部２３０にキャッシュする（Ｓ３１１）。

　最後に、Ｓ３１２において、クライアント装置にレスポンスデータを送信する。

　また、図２４は、動作例４のプロキシサーバ２００の動作を示すフローチャートである。図２４のフローチャートを見るとわかるように、このフローチャートは、図１６のフローチャートにおけるＳ３０８およびＳ３０９の工程を、Ｓ３１４の「レスポンス受信部２５０が受信したレスポンスデータを、処理部２２０がキャッシュする」工程に置き換えた形で表される。

　（プロキシサーバ２００の利点）
　以上のように、プロキシサーバ２００は、クライアント装置１００－１からＳＤクオリティおよびＨＤクオリティの映像を含むレスポンスデータ５Ｂ－５を要求するリクエストデータ５Ａを受信した場合に、処理部２２０は、レスポンスデータ５Ｂ－５に含めるべきＳＤクオリティおよびＨＤクオリティのいずれかの映像を含むレスポンスデータがキャッシュ部２３０に記録されているか否かを判定する。

　動作例３では、処理部２２０は、ＳＤクオリティの映像を含むレスポンスデータ５Ｂ－４がキャッシュ部２３０に記録されていると判定し、図１３（ｂ）に示すように、キャッシュ部２３０に記録されているレスポンスデータ５Ｂ－４を用いて要求されるレスポンスデータ５Ｂ－５を生成する。すなわち、プロキシサーバ２００は、ＨＤクオリティの映像のみを含むレスポンスデータをコンテンツサーバ３００から受信することになる。

　一方、従来のプロキシサーバは、クライアント装置１００－１からＳＤクオリティおよびＨＤクオリティの映像を含むレスポンスデータ５Ｂ－５を要求するリクエストデータ５Ａを受信した場合に、レスポンスデータ５Ｂ－５そのものがキャッシュに記録されていなければ、ＨＤクオリティおよびＳＤクオリティの両方の映像を含むレスポンスデータ５Ｂ－５をコンテンツサーバ３００から受信することになる。

　また、動作例４では、処理部２２０は、ＨＤクオリティのリクエストデータ４Ｂがいずれ受信されることを推定する。そして、リクエスト受信部２１０がＳＤクオリティのリクエストデータ４Ｂを受信した時点で、リクエスト送信部２４０は、コンテンツサーバ３００に最上位階層がＨＤクオリティのレスポンスデータ５Ｂ－1を要求する。その後、処理部２２０は、コンテンツサーバ３００から受信したレスポンスデータ５Ｂ－1をキャッシュ部２３０にキャッシュする。

　そして、その後のＳＤクオリティのリクエストデータ４Ｂに対しては、処理部２２０は、キャッシュされた最上位階層がＨＤクオリティのレスポンスデータ５Ｂ－1から最上位階層がＳＤクオリティのレスポンスデータ５Ｂ－２を抽出し、レスポンス送信部２６０がレスポンスデータ５Ｂ－２をクライアント装置に送信する。また、その後受信されるＨＤクオリティのリクエストデータ４Ｂに対しては、既にキャッシュされているＨＤクオリティのレスポンスデータ５Ｂ－1を送信する。従って、コンテンツサーバ３００への要求は、最上位階層がＨＤクオリティのレスポンスデータ５Ｂ－1の要求１回のみとされる。

　したがって、プロキシサーバ２００は、従来のプロキシサーバよりも、空間解像度スケーラブルな映像を多数のクライアント装置に中継することに起因するコンテンツサーバとの間のネットワークの帯域負荷を抑えることができる。

　（実施形態２）
　次に、本発明の別の一実施形態に係る通信システム１ａについて、図１７～図１９を参照しながら以下に説明する。

　通信システム１ａは、図１７に示すように、クライアント装置１００－１、１００－２、プロキシサーバ２００ａ、およびコンテンツサーバ３００’により構成されている。

　実施形態１では、コンテンツサーバ３００が、ライブ映像を再生中のクライアント装置に対し、メディアセグメント単位でライブ映像のコンテンツデータを送信していた。対して、本実施形態では、コンテンツサーバ３００’が、ライブ映像を再生中のクライアント装置に対し、HTTPプロトコルの転送コーディング形式であるチャンク形式によりライブ映像のコンテンツデータを配信するようになっている。

　チャンク形式とは、チャンクデータと、チャンクのデータサイズを表わすチャンクサイズ情報と、を含むチャンクをHTTPメッセージのボディ部に順に格納し、最後に格納したチャンクの後にチャンクの終わりを示す“０”とHTTPメッセージ全体のデータサイズを示したフッタを付ける転送コーディング形式であり、予め全体のデータサイズが判らないようなコンテンツであっても送信可能とする転送形式である。

　すなわち、本実施形態では、１つのリクエストデータ（４Ｆ）に対して、配信するコンテンツの先頭のデータから順次チャンクに詰められたレスポンスデータ（５Ｄ－1）が返される。さらに、キャッシュされたレスポンスデータ中のチャンク（ムービーフラグメント）は、キャッシュのサイズに応じて過去のものから順にキャッシュから削除されていく。

　図１７からわかるように、本実施形態の通信システム１ａの構成は、実施形態１の通信システム１の構成と、以下の点のみ異なっている。

　すなわち、プロキシサーバ２００ａの処理部２２０ａは、図１９（ｂ）の左側の図に示すような（キャッシュに残されている）チャンク形式の最上位階層がＨＤクオリティのデータから、図１９（ｂ）の右側の図に示すようなチャンク形式の最上位階層がＳＤクオリティのデータを抽出する処理を行うようになっている。

　また、コンテンツサーバ３００’の処理部３２０’は、リクエスト受信部３１０からリクエストデータが供給されたときに、チャンク形式のレスポンスデータを生成してレスポンス送信部３３０に供給するようになっている。

　以下、図１８および図１９を参照しながら通信システム１ａの一動作例について説明する。

　図１８は、上記動作例を示すシーケンス図である。図１９は図１８のシーケンス図で示される動作例中で扱われるHTTPメッセージを示している。図１９（ａ）は、ステップＳ１１１にてクライアント装置１００－１から送信するリクエストデータ４Ｆを示している。また、図１９（ｂ）の左側の図は、ステップＳ１１３にてコンテンツサーバ３００’がプロキシサーバ２００ａに送信するレスポンスデータ５Ｄ－１を示している。また、図１９（ｂ）の右側の図は、ステップＳ１１６にてプロキシサーバ２００ａがクライアント装置１００－２に送信するレスポンスデータ５Ｄ－２を示している。

　図１９（ｂ）の左側の図からわかるように、コンテンツサーバ３００’は、ムービーフラグメントに関するデータ５０７（すなわち、ムービーフラグメントのバイナリデータとムービーフラグメントに関するメタ情報（タイムスタンプ等））をチャンクデータとしている。そして、図１９（ｂ）の左側の図中の文字列５０６が、そのチャンクのサイズを示している（文字列５０６の部分は、テキストデータではなく、１６進数の数値データである）。

　なお、この動作例は、同一のライブ映像のコンテンツデータについて、クライアント装置１００－１がＨＤクオリティのリクエストデータを要求した後に、クライアント装置１００－２がＳＤクオリティのリクエストデータを要求した場合の動作例である。また、前提として、動作の開始前にプロキシサーバ２００ａのキャッシュは空であるものとする。また、シーケンス図では、クライアント装置１００－１、１００－２と、コンテンツサーバ３００’との間のリクエストデータ４Ａおよびレスポンスデータ５Ａのやりとりの記載を省略している。

　クライアント装置１００－１は、ＨＤクオリティのリクエストデータ４Ｆをプロキシサーバ２００ａに送信する（Ｓ１１１）。

　プロキシサーバ２００ａは、クライアント装置１００－１から要求されたムービーフラグメントがキャッシュに含まれているか否かを判定する。ここでは、キャッシュが空なので、プロキシサーバ２００ａはリクエストデータ４Ｂをそのままコンテンツサーバ３００’に送信する（Ｓ１１２）。

　リクエストデータ４Ｆを受信したコンテンツサーバ３００’は、受信した時点で配信すべき（図では時刻０からの）拡張レイヤおよびベースレイヤのムービーフラグメントをチャンク形式で格納したレスポンスメッセージ５Ｄ－１を生成し、プロキシサーバ２００ａに送信する（Ｓ１１３）。

　プロキシサーバ２００ａは、受信したレスポンスメッセージ５Ｄ－１をキャッシュするとともに、クライアント装置１００－１に送信する（Ｓ１１４）。

　先に説明したとおり、チャンク形式により配信を行うコンテンツサーバ３００’は、１つのリクエストデータ４Ｆを受信すると、コンテンツデータを構成するムービーフラグメントを最後のフラグメントまで順次送信する。そのため、プロキシサーバ２００ａのキャッシュ部２３０に記録されたレスポンスメッセージ５Ｄ－１中のチャンクは、キャッシュのサイズに合せて順次古いほうから削除されていく。

　次に、クライアント装置１００－２は、ＳＤクオリティのリクエストデータ４Ｆをプロキシサーバ２００ａに送信する（Ｓ１１５）。

　プロキシサーバ２００ａの処理部２２０ａは、リクエストデータ４Ｆを受信したとき、ＳＤクオリティのムービーフラグメントがキャッシュ部２３０にキャッシュされているか否かを判定する。具体的には、処理部２２０ａは、プロキシサーバ２００ａが過去に受信した（キャッシュ部２３０にキャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照することにより、判定を行う。

　そして、処理部２２０ａは、キャッシュ部２３０にキャッシュされていると判定した場合、キャッシュ部２３０に残されている最も古いベースレイヤのチャンク（ムービーフラグメント）から古い順にベースレイヤのチャンク（ムービーフラグメント）を抽出して、レスポンスデータ５Ｄ－２を形成する。ここでは、処理部２２０ａは、タイムスタンプが３０のベースレイヤのムービーフラグメントがキャッシュ部２３０に残されている最も古いムービーフラグメントであるとして、クライアント装置１００－２に送信すべきレスポンスデータ５Ｄ－２を形成する。

　抽出は、具体的には、チャンクに含まれるMIMEパートデータのうちコンテンツタイプを示すヘッダ情報を参照することによって行ってもよい。あるいは、実施形態１の動作例２と同様に、ライブ映像中のある画像がライブカメラで生成される時刻と、その画像がクライアント装置１００において再生される時刻と、にタイムラグがあることを考慮してもよい。すなわち、タイムラグを縮めるために、キャッシュされているムービーフラグメントを古いほうから幾つか削除した上で、最も古いムービーフラグメントから古い順に抽出してレスポンスデータ５Ｄ－２を形成するようにしてもよい。

　最後に、プロキシサーバ２００ａは、クライアント装置１００－２にレスポンスデータ５Ｄ－２を送信する（Ｓ１１６）。

　以上のように、プロキシサーバ２００ａは、プロキシサーバ２００と同様、最上位階層がＳＤクオリティのスケーラブル映像の配信要求を受け取った場合に、最上位階層がＨＤクオリティのスケーラブル映像がキャッシュに含まれていれば、キャッシュから、最上位階層がＳＤクオリティのスケーラブル映像を抽出してクライアント装置に送信することになる。

　これにより、通信システム１ａのプロキシサーバ２００ａとコンテンツサーバ３００’との間の基幹ネットワークの帯域負荷は、通信１のプロキシサーバ２００ａを従来のプロキシサーバに置き換えた場合における基幹ネットワークの帯域負荷に比べ小さくなる。

　また、チャンク形式のデータは、チャンク毎のチャンクサイズを含むものの、全体のデータサイズを予め含んでいないことから、通信中に一部のチャンクが失われても再送を要することなくクライアント装置で映像を表示することが可能である。

　したがって、通信システム１ａではクライアント装置がより安定して映像を表示することができる。

　また、プロキシサーバ２００ａは、接続しているクライアント装置の数が増大し、クライアント装置と、プロキシサーバ２００ａとの間のネットワークのトラフィックがある規定以上増大してしまった場合に、適応レート制御を行っても良い。ここで、適応レート制御とは、クライアント装置がＨＤクオリティの映像を要求してきた場合であっても、ＨＤクオリティのムービーフラグメントの一部または全部を削除したレスポンスデータをクライアント装置に送信する処理である。

　このようにすることにより、プロキシサーバ２００ａとクライアント装置との間のネットワークのトラフィックを減少させることができる。

　（実施形態３）
　さらに、本発明の別の一実施形態に係る通信システム１ｂについて、図２０～図２２を参照しながら以下に説明する。

　通信システム１ｂは、図２０に示すように、クライアント装置１００－１、１００’、プロキシサーバ２００ｂ、およびコンテンツサーバ３００により構成されている。

　実施形態１では、２つのクライアント装置１００－１、１００－２が、ともに、マルチパート形式でのデータ送信を要求するようになっていたが、本実施形態では、２つのクライアント装置のうち一方のクライアント装置１００’がシングルパート形式でのデータ送信を要求するようになっている。

　図２０からわかるように、本実施形態の通信システム１ａの構成は、実施形態１の通信システム１の構成と、以下の点のみ異なっている。

　すなわち、クライアント装置１００’のリクエスト送信部１１０’は、シングルパート形式でのデータ送信を要求するためのリクエストデータを送信する。

　プロキシサーバ２００ｂの処理部２２０ｂは、図２２（ｂ）の右段の図に示すような最上位階層がＨＤクオリティの（マルチパート形式の）レスポンスデータ５Ｂ－１から、図２２（ｂ）の左下段の図に示すようなＳＤクオリティのシングルパート形式のデータを抽出する処理を行うようになっている。

　また、処理部２２０ｂは、シングルパート形式でのデータ送信を要求するためのリクエストデータ（シングルパートのリクエストデータ）４Ｅを受信した場合に、リクエストデータ４Ｅをマルチパートのリクエストデータ４Ａに変換するようになっている。

　以下、図２１および図２２を参照しながら通信システム１ａの一動作例について説明する。

　図２１は、上記動作例を示すシーケンス図である。また、図２２（ａ）の左側の図は、ステップＳ１２５にてクライアント装置１００’がプロキシサーバ２００ｂに送信するリクエストデータ４Ｅを示している。

　クライアント装置１００－１は、期間４のＨＤクオリティのリクエストデータ４Ｂをプロキシサーバ２００ａに送信する（Ｓ１２１）。

　プロキシサーバ２００ｂの処理部２２０ｂは、Ｓ１２１にて送信されたリクエストデータ４Ｂについてクライアント装置１００－１に送信すべきレスポンスデータ５Ｂ（メディアセグメント）を構成する全部または一部の階層がキャッシュに含まれているか判定する。ここでは、キャッシュが空なので、プロキシサーバ２００はリクエストデータ４Ｂをそのままコンテンツサーバ３００に送信する（Ｓ１２２）。

　リクエストデータ４Ｂを受信したコンテンツサーバ３００は、要求された期間４の最上位階層がＨＤクオリティのレスポンスデータ５Ｂ－１をプロキシサーバ２００に送信する（Ｓ１２３）。レスポンスデータ５Ｂ－１を受信したプロキシサーバ２００は、レスポンスデータ５Ｂ－１をキャッシュするとともに、レスポンスデータ５Ｂ－１をそのままクライアント装置１００－１に送信する（Ｓ１２４）。

　一方、クライアント装置１００’は、シングルパート形式でＳＤクオリティの映像を配信するよう要求するリクエストデータ４Ｅをプロキシサーバ２００ｂに送信する（Ｓ１２５）。ここで、要求がシングルパート形式であることは、リクエストデータ４Ｅのヘッダ部のAcceptに文字列“multipart/media-segment”が宣言されていないことにより表されている。また、マルチパート非対応であることから、スケーラブルデコードが不可であり、クライアント装置１００’の復号可能なデータはベースレイヤのＳＤクオリティのデータに限られることがわかる。これに対して、コンテンツサーバ３００はマルチパート対応であることから、リクエストデータ４Ｅを受信したプロキシサーバ２００ｂの処理部２２０ｂは、リクエストデータ４Ｅのヘッダ部のAcceptに文字列”multipart/media-segment”を追加して、マルチパートのリクエストデータ４Ａを生成する。

　そして、プロキシサーバ２００ｂは、マルチパートのリクエストデータ４Ａをコンテンツサーバ３００に送信する（Ｓ１２６）。

　コンテンツサーバ３００は、図２２（ｂ）の左上段の図に示している期間４の初期レスポンスデータ５Ａをプロキシサーバ２００ｂに送信する（Ｓ１２７）。

　期間４の初期レスポンスデータ５Ａを受信したプロキシサーバ２００ｂの処理部２２０ｂは、期間４のベースレイヤ（ＳＤクオリティ）を階層に含むレスポンスデータ（メディアセグメント）がキャッシュに記録されているかを判定する。前述の通り、判定は、過去に受信した（キャッシュした）リクエストデータのリクエスト行、及びキャッシュしたレスポンスデータのヘッダ部を参照して行う。Ｓ１２３の直後に、期間４の最上位階層が拡張レイヤ（ＨＤクオリティ）のレスポンスデータ５Ｂ－１がキャッシュに記録されているので、ここでは、「キャッシュに記録されている」と判定する。

　「キャッシュに記録されている」と判定した場合、処理部２２０ｂは、クライアント装置１００’に送信すべき期間４のシングルパート形式のレスポンスデータ５Ｅを生成する。

　すなわち、処理部２２０ｂは、クライアント装置１００’に送信すべきレスポンスデータ５Ｅのヘッダ部として、レスポンスデータ５Ｂ－１中のレスポンス行“HTTP/1.1 200 OK”およびMIMEパート中のコンテンツタイプを示すヘッダ”Content-Type:video/mp4”を抽出する。

　さらに、処理部２２０ｂは、レスポンスデータ５Ｅのボディ部を次のように形成する。すなわち、処理部２２０ｂは、Ｓ１２４にてキャッシュされたレスポンスデータ５Ｂ－１に含まれるベースレイヤの各ムービーフラグメントのうち、先頭のムービーフラグメント（fragmentB40）のヘッダを、moofヘッダから、Ｓ１２７にて受信した初期レスポンスデータ５Ａ中のベースレイヤの先頭ムービーフラグメント（fragmentB0）のmoovヘッダに置換する。その上で、ヘッダ置換後のfragmentB40、fragmentB41、・・、およびfragmentB49（図２２（ｂ）の右側の図の破線で囲まれた部分）を結合したデータをレスポンスデータ５Ｅのボディ部のデータとする。moovヘッダからmoofヘッダにヘッダを置換する処理以外の処理は、マルチパートの各パートのヘッダ部を参照することにより、ムービーフラグメントの中のデータを参照することなく行われる。

　最後に、プロキシサーバ２００ｂは、クライアント装置１００’にレスポンスデータ５Ｅを送信する（Ｓ１２８）。

　以上のように、通信システム１ｂでは、スケーラブル映像の再生に対応したクライアント装置１００－１であっても、スケーラブル映像の再生に対応していないクライアント装置１００’であっても、コンテンツサーバ３００が配信するライブ映像を再生することができる。

　また、殆どの処理がリクエストデータのリクエスト行、レスポンスデータのヘッダ部、及びマルチパートの各パートのヘッダ部のみを参照することで行われ、ムービーフラグメントのデータ自体を確認する必要がないため、上記した通信システム１ｂは容易に実現可能である。
（付記事項１）
　なお、上記各実施形態では、通信システム１（１ａ、１ｂ）に、１つのコンテンツサーバ３００（３００’）、１つのプロキシサーバ２００（２００ａまたは２００ｂ）、２つのクライアント装置１００－１、１００－２（１００－１、１００’）が設けられているものとしたが、通信システム１、１ａ、１ｂを構成する各サーバおよびクライアント装置の数は当然これに限定されない。また、各実施形態では、空間スケーラブル映像を構成する階層の数が、基本レイヤと拡張レイヤとの２つであるものとしたが、階層の数はこれに限定されない。すなわち、QCIF映像を保持するレイヤとSD映像を保持するレイヤとHD映像を保持するレイヤとの３つの階層で空間スケーラブル映像（つまり、品質の異なる最大３個の映像からなる空間スケーラブル映像）が構成されていてもよいし、４つ以上の階層で構成されていてもよい。

　また、上記各実施形態では、本発明に係る中継装置が中継するコンテンツデータの例として、空間解像度（品質）が相異なる複数の階層の映像（再生対象映像）からなる空間解像度スケーラブル映像のコンテンツデータを挙げた。本発明に係る中継装置が中継するコンテンツデータはこれに限られず、量子化精度の異なる複数の階層を持つSNRスケーラブルな映像のコンテンツデータであってもよい。あるいは、コンテンツデータは、クロマフォーマットの異なる複数の階層（例えば、4:2:0,4:2:2,4:4:4の３つの階層）を持つクロマスケーラブルな映像のコンテンツデータであってもよい。あるいは、フレームレートの異なる複数の階層を持つ時間スケーラブルな映像のコンテンツデータ等であってもよい。

　さらに、動的コンテンツのデータは、量子化ビット数の異なる複数の階層（例えば、16bit,8bit,4bit）を持つスケーラブル音声のコンテンツデータであってもよい。

　あるいは、本発明の上記各実施形態を適用する他の例として、マルチ言語映像のライブ配信をあげることもできる。すなわち、映像データをベースレイヤとし、音声データ１、２、・・・のそれぞれを拡張レイヤと解釈して本発明の上記各実施形態を適用することも可能である。また、映像データ＋音声データ１をベースレイヤとし、音声データ２、３、・・・を音声データ１に上書き置換して再生する拡張レイヤとして本発明の上記各実施形態を適用することも可能である。（すなわち拡張レイヤを用いることで、音声データ１以外の言語に対応可能になる。例えば、音声データ１を日本語音声とし、音声データ２を英語、音声データ３をフランス語音声とする。ベースレイヤのみを再生するクライアント装置（利用者）は日本語で映像コンテンツを再生（視聴）する。拡張レイヤを再生可能なクライアント装置（利用者）は音声データ２又は３を得て英語またはフランス語で映像コンテンツを再生（視聴）する。）さらには、映像データ＋音声データをベースレイヤとし、字幕やピクチャインピクチャ等による重畳画像や重畳映像等を拡張レイヤとして本発明の上記各実施形態を適用することも可能である（すなわち拡張レイヤを用いることで、字幕の追加、変更や特典映像の視聴が可能になる）。
（付記事項２）
　ムービーフラグメントの期間の長さは１秒に限られない。また、メディアセグメントの期間の長さは１０秒に限られない。すなわち、例えば、ムービーフラグメントの期間の長さをMPEG-4の符号化の単位であるGOP（Group of Picture）に合せて0.5秒としてもよいし、2秒等の長いものにすることも可能である。また、コンテンツサーバ３００は、メディアセグメントの期間の長さを、HTTPメッセージの発生頻度に応じてユーザが設定した長さに適宜変更可能な構成となっていてもよい。すなわち、目的や状況に応じて、ユーザはメディアセグメントの期間の長さを３０秒あるいは１分等としてリクエストメッセージおよびレスポンスメッセージの発生頻度を抑えるようにすることもできるし、あるいは、頻繁に切替えが発生するような場合には５秒等にしてレスポンスを早くするようにしてもよい。

　さらに、ムービーフラグメントの長さを可変にする（途中で変える）ことも可能である。メディアセグメントの長さを可変にする（格納されるムービーフラグメントの個数を変える）ことも可能である。

　また、コンテンツデータを所定の長さに区切って取り扱えるようにしたデータ形式であれば、ムービーフラグメント以外のデータ形式であっても本発明を適用可能である。すなわち、本発明の通信システムが扱えるデータ形式はムービーフラグメント形式に限らない。例えば、MPEG-2のPES（Packetized Elementary Stream）パケットや、MPEG-2 TS（Transport Stream）のTSパケットを用いて本発明の通信システムを構成することもできる。すなわち、本発明の通信システムは、コンテンツデータを、所定の長さに区切った単位データ（PESパケット、TSパケット）毎にMIMEマルチパート形式でHTTPメッセージに格納する。これによって、プロキシサーバは、マルチパートの各パートに記録されたデータの中身を見なくとも、HTTPメッセージのヘッダ情報等を使って格納されたデータのフィルタリング、ハンドリングを行うことができる。

　（プログラム、記憶媒体）
　クライアント装置１００－１（１００－２、１００’）、プロキシサーバ２００（２００ａ、２００ｂ）、及びコンテンツサーバ３００（３００’）の各ブロック、特に処理部２２０（２２０ａ、２２０ｂ）、処理部３２０（３２０’）は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。

　なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

　以上のように、本発明に係る中継装置は、上記判定手段が、上記第２のコンテンツデータが上記記録部に記録されていると判定した場合に、さらに、上記第２のコンテンツデータが、上記第１のコンテンツデータを構成する全再生対象コンテンツと上記第１のコンテンツデータを構成しない再生対象コンテンツとを共に含んでいるかを判定するようになっており、上記判定手段が「共に含んでいる」と判定した場合には、上記生成手段は、生成すべき上記第１のコンテンツデータを上記第２のコンテンツデータから抽出することが望ましい。

　上記の構成によれば、再生装置に送信すべき上記第1のコンテンツデータを構成する再生対象コンテンツの数が、上記記録部に記録されている上記第２のコンテンツデータを構成する再生対象コンテンツの数よりも少ない場合に、送信装置との間のネットワークに負荷をかけずに、上記第２のコンテンツデータから上記第１のコンテンツデータを生成することができる。

　上記中継装置は、上記第２のコンテンツデータが上記記録部に記録されていると上記判定手段が判定した場合に、上記第１のコンテンツデータを構成する全再生対象コンテンツのうち、上記第２のコンテンツデータに含まれていない再生対象コンテンツを含む第３のコンテンツデータを上記送信装置から取得する取得手段をさらに備え、上記生成手段が、上記第２のコンテンツデータと上記第３のコンテンツデータとを用いて上記第１のコンテンツデータを生成することが望ましい。

　上記の構成によれば、再生装置に送信すべき上記第1のコンテンツデータを構成する再生対象コンテンツの数が、上記記録部に記録されている上記第２のコンテンツデータを構成する再生対象コンテンツの数よりも多い場合であっても、上記第２のコンテンツデータから上記第１のコンテンツデータを生成することができる。

　上記中継装置は、複数の再生装置から上記要求を受信する中継装置であって、上記Ｎ個の再生対象コンテンツは品質が相異なるＮ階層の階層データであり、各再生装置から次に受信することが予定される要求のうちの最も多くの階層からなる第１のコンテンツデータを対象とする要求について、当該第１のコンテンツデータを構成する階層データの階層数Ｍを推定する推定手段をさらに備え、上記第２のコンテンツデータが上記記録部に記録されていないと上記判定手段が判定した場合に、Ｍ階層の階層データからなる第２のコンテンツデータを上記送信装置から取得する取得手段をさらに備えていることが望ましい。

　上記の構成によれば、上記中継装置は、内容が同一であって階層数が異なる第１のコンテンツデータを上記複数の再生装置から要求された場合であっても、上記内容の第２のコンテンツデータを送信装置から取得する回数はたかだか１回となる。

　したがって、上記推定手段を備えていないような中継装置と比較して送信装置との間のネットワークの帯域負荷をより抑えることができるというさらなる効果を奏する。

　また、上記中継装置は、複数の再生装置から上記要求を受信する中継装置であって、上記Ｎ個の再生対象コンテンツは品質が相異なるＮ階層の階層データであり、上記再生装置から上記要求を受信した場合に、より多くの階層から構成される第１のコンテンツデータの要求を他の再生装置から受信することが予定されるか否かを判定するととともに、予定されると判定されたときに当該第１のコンテンツデータを構成する階層データの階層数Ｍを推定する推定手段と、上記第２のコンテンツデータが上記記録部に記録されていないと上記判定手段が判定した場合であって上記階層数Ｍが推定された場合に、Ｍ階層の階層データからなるコンテンツデータを上記送信装置から取得する取得手段をさらに備えていることが望ましい。

　上記の構成によれば、上記中継装置は、ある再生装置から階層数Ｍ’の第１のコンテンツデータの要求を受信した場合において、他の再生装置から階層数Ｍ（＞Ｍ’）の第１のコンテンツデータの要求を受信する見込みがあるときは、記録部に第２のコンテンツデーが記録されていない限り、階層数Ｍのコンテンツデータを送信装置から取得する。したがって、後に階層数Ｍ’以下の第１のコンテンツデータの要求を受信する時には、コンテンツデータを送信装置から取得する必要はない。

　上記中継装置は、上記コンテンツデータはマルチパート形式のＨＴＴＰメッセージとして送受信されるようになっており、上記ＨＴＴＰメッセージの各パートには、再生対象コンテンツと、該再生対象コンテンツの品質を示す情報とが別々に記録されている、ことが望ましい。

　上記の構成によれば、各パートにおいて、上記情報は、上記再生対象コンテンツの一部として記録されているのではなく、上記再生対象コンテンツとは別に記録されている。

　したがって、品質が相異なる複数の再生対象コンテンツが含まれているＨＴＴＰメッセージから特定の品質の再生対象コンテンツを抽出する場合に、各パートの上記情報を参照することにより再生対象コンテンツ自体を解析することなく容易に抽出することができるというさらなる効果を奏する。

　なお、上記情報を再生対象コンテンツとは別に記録する方法としては、例えば、上記情報を上記再生対象コンテンツに関連付けられたヘッダとして記録する方法などが挙げられる。

　また、上記中継装置では、上記ＨＴＴＰメッセージのヘッダ部には、上記ＨＴＴＰメッセージに含まれているすべての再生対象コンテンツの品質を示す情報が記録されていることが望ましい。

　上記の構成によれば、上記中継装置は、特定の品質の再生対象コンテンツを中継するよう再生装置から要求された場合に、要求された品質の再生対象コンテンツを上記コンテンツデータから抽出可能であるかを、上記ＨＴＴＰメッセージのヘッダ部の情報を参照することにより即座に把握することができるというさらなる効果を奏する。

　また、上記中継装置は、上記コンテンツデータがチャンク形式のＨＴＴＰメッセージであることが望ましい。

　上記の構成によれば、通信中のコンテンツデータの一部が欠損した場合であっても、上記再生装置が上記第１のコンテンツデータを安定して再生することができるというさらなる効果を奏する。

　上記中継装置は、上記送信手段が、上記第１のコンテンツデータを上記ＨＴＴＰメッセージとして送信するようになっており、上記生成手段が、上記ＨＴＴＰメッセージの各パートに、上記第１のコンテンツデータを構成する１つのフラグメントであって上記再生装置において再生した場合に所定の時間だけ再生されるフラグメントを含めるようになっており、上記生成手段が、上記ＨＴＴＰメッセージに含める上記フラグメントの個数を、該中継装置が上記要求を上記再生装置から受信した時刻に応じた個数とすることが望ましい。

　上記の構成によれば、上記中継装置は、上記再生装置から上記要求を受信した時刻に応じて、再生装置に送信するＨＴＴＰメッセージに含める上記フラグメントの個数を変えることになる。

　これにより、上記中継装置は、上記再生装置が上記フラグメントの部分を再生している時刻と、該フラグメントを上記送信装置が送信した時刻と、のタイムラグを減らすことができるというさらなる効果を奏する。

　上記中継装置は、上記要求がたかだか１個の再生対象コンテンツを含む第１のコンテンツデータをシングルパート形式のHTTPメッセージとして送信すべき旨の要求である場合に、該要求を、該再生対象コンテンツを含むコンテンツデータをマルチパート形式のＨＴＴＰメッセージとして送信すべき旨の要求に変換する第１の変換手段と、上記第１の変換手段による変換後の要求を上記送信装置に送信することにより、上記マルチパート形式のＨＴＴＰメッセージとしてのコンテンツデータを取得する第２の取得手段と、を備え、上記第２の取得手段が取得したコンテンツデータを、シングルパート形式のHTTPメッセージである上記第１のコンテンツデータに変換する第２の変換手段と、を備えていることが望ましい。

　上記の構成によれば、上記中継装置は、上記送信装置がマルチパート形式のＨＴＴＰメッセージの送信しかサポートしておらず、上記再生装置がシングルパート形式のＨＴＴＰメッセージを再生することを要求する場合であっても、上記再生装置に第１のコンテンツデータを再生させることができるというさらなる効果を奏する。

　なお、本発明は、上記中継装置と、上記再生装置と、を含む通信システムとしても実現することができる。また、本発明は、上記中継装置と、上記再生装置と、上記送信装置と、を含む通信システムとしても実現することができる。さらに、本発明に係る再生装置を動作させるためのプログラムであって、コンピュータを上記の各手段として機能させることを特徴とする中継制御プログラム、および、その中継制御プログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。

　本発明に係る通信システムは、映像配信システムとして広く利用することができる。

　１００－１、１００－２　　　クライアント装置（再生装置）
　１００’　　　　　　　　　　　クライアント装置
　１１０、１１０’　　　　　　　リクエスト送信部
　１２０　　　　　　　　　　　　再生部
　１３０　　　　　　　　　　　　レスポンス受信部
　２００、２００ａ、２００ｂ　プロキシサーバ（中継装置）
　２１０　　　　　　　　　　　　リクエスト受信部
　２２０、２２０ａ、２２０ｂ　　処理部（判定手段、生成手段、第１の変換手段、第２の変換手段、推定手段）
　２３０　　　　　　　　　　　　キャッシュ部（記録部）
　２４０　　　　　　　　　　　　リクエスト送信部（取得手段、第２の取得手段）
　２５０　　　　　　　　　　　　レスポンス受信部（取得手段、第２の取得手段）
　２６０　　　　　　　　　　　　レスポンス送信部（送信手段）
　３００、３００’　　　　　　コンテンツサーバ（送信装置）
　３１０　　　　　　　　　　　　リクエスト受信部
　３２０、３２０’　　　　　　　処理部
　３３０　　　　　　　　　　　　レスポンス送信部
　３４０　　　　　　　　　　　　メモリ部
　３５０　　　　　　　　　　　　符号化部
　３６０　　　　　　　　　　　　原映像受信部

Claims

　再生装置からの要求に応じて、品質が相異なる最大Ｎ個（Ｎ：２以上の整数）の再生対象コンテンツからなるコンテンツデータを送信装置から上記再生装置に中継するとともに該コンテンツデータを記録部に記録する中継装置において、
　上記再生装置から上記要求を受信した場合に、要求された第１のコンテンツデータを構成する再生対象コンテンツの何れかを含む第２のコンテンツデータが上記記録部に記録されているか否かを判定する判定手段と、
　上記第１のコンテンツデータを上記再生装置に送信する送信手段と、
　上記第２のコンテンツデータが上記記録部に記録されていると上記判定手段が判定した場合に、上記第１のコンテンツデータを、上記記録部に記録されている上記第２のコンテンツデータを用いて生成する生成手段と、を備えていることを特徴とする中継装置。
　請求項１に記載の中継装置であって、
　上記判定手段は、上記第２のコンテンツデータが上記記録部に記録されていると判定した場合に、さらに、上記第２のコンテンツデータが、上記第１のコンテンツデータを構成する全再生対象コンテンツと上記第１のコンテンツデータを構成しない再生対象コンテンツとを共に含んでいるかを判定するようになっており、
　上記判定手段が「共に含んでいる」と判定した場合には、上記生成手段は、生成すべき上記第１のコンテンツデータを上記第２のコンテンツデータから抽出することを特徴とする中継装置。
　請求項１または２に記載の中継装置であって、
　上記第２のコンテンツデータが上記記録部に記録されていると上記判定手段が判定した場合に、上記第１のコンテンツデータを構成する全再生対象コンテンツのうち、上記第２のコンテンツデータに含まれていない再生対象コンテンツを含む第３のコンテンツデータを上記送信装置から取得する取得手段をさらに備え、
　上記生成手段は、上記第２のコンテンツデータと上記第３のコンテンツデータとを用いて上記第１のコンテンツデータを生成することを特徴とする中継装置。
　複数の再生装置から上記要求を受信する請求項１または２に記載の中継装置であって、
　上記Ｎ個の再生対象コンテンツは品質が相異なるＮ階層の階層データであり、
　各再生装置から次に受信することが予定される要求のうちの、最も多くの階層からなる第１のコンテンツデータを対象とする要求について、当該第１のコンテンツデータを構成する階層データの階層数Ｍを推定する推定手段をさらに備え、
　上記第２のコンテンツデータが上記記録部に記録されていないと上記判定手段が判定し
た場合に、Ｍ階層の階層データからなるコンテンツデータを上記送信装置から取得する取得手段をさらに備えていることを特徴とする中継装置。
　複数の再生装置から上記要求を受信する請求項１または２に記載の中継装置であって、
　上記Ｎ個の再生対象コンテンツは品質が相異なるＮ階層の階層データであり、
　上記再生装置から上記要求を受信した場合に、より多くの階層から構成される第１のコンテンツデータの要求を他の再生装置から受信することが予定されるか否かを判定するととともに、予定されると判定されたときに当該第１のコンテンツデータを構成する階層データの階層数Ｍを推定する推定手段と、
　上記第２のコンテンツデータが上記記録部に記録されていないと上記判定手段が判定し
た場合であって上記階層数Ｍが推定された場合に、Ｍ階層の階層データからなるコンテンツデータを上記送信装置から取得する取得手段をさらに備えていることを特徴とする中継装置。
　請求項１から５のいずれか１項に記載の中継装置であって、
　上記コンテンツデータはマルチパート形式のＨＴＴＰメッセージとして送受信されるようになっており、
　上記ＨＴＴＰメッセージの各パートには、再生対象コンテンツと、該再生対象コンテンツの品質を示す情報とが別々に記録されている、ことを特徴とする中継装置。
　上記ＨＴＴＰメッセージのヘッダ部には、上記ＨＴＴＰメッセージに含まれているすべての再生対象コンテンツの品質を示す情報が記録されていることを特徴とする請求項６に記載の中継装置。
　上記コンテンツデータはチャンク形式のＨＴＴＰメッセージであることを特徴とする請求項１から７のいずれか１項に記載の中継装置。
　請求項６または７に記載の中継装置であって、
　上記送信手段は、上記第１のコンテンツデータを上記ＨＴＴＰメッセージとして送信するようになっており、
　上記生成手段は、上記ＨＴＴＰメッセージの各パートに、上記第１のコンテンツデータを構成する１つのフラグメントであって上記再生装置において再生した場合に所定の時間だけ再生されるフラグメントを含めるようになっており、
　上記生成手段は、上記ＨＴＴＰメッセージに含める上記フラグメントの個数を、該中継装置が上記要求を上記再生装置から受信した時刻に応じた個数とすることを特徴とする中継装置。
　請求項１から９のいずれか１項に記載の中継装置であって、
　上記要求がたかだか１個の再生対象コンテンツを含む第１のコンテンツデータをシングルパート形式のHTTPメッセージとして送信すべき旨の要求である場合に、該要求を、該再生対象コンテンツを含むコンテンツデータをマルチパート形式のＨＴＴＰメッセージとして送信すべき旨の要求に変換する第１の変換手段と、
　上記第１の変換手段による変換後の要求を上記送信装置に送信することにより、上記マルチパート形式のＨＴＴＰメッセージとしてのコンテンツデータを取得する第２の取得手段と、を備え、
　上記第２の取得手段が取得したコンテンツデータを、シングルパート形式のHTTPメッセージである上記第１のコンテンツデータに変換する第２の変換手段と、を備えていることを特徴とする中継装置。
　再生装置からの要求に応じて、品質が相異なる最大Ｎ個（Ｎ：２以上の整数）の再生対象コンテンツからなるコンテンツデータを送信装置から上記再生装置に中継するとともに該コンテンツデータを記録部に記録する中継装置の中継方法において、
　上記再生装置から上記要求を受信した場合に、要求された第１のコンテンツデータを構成する再生対象コンテンツの何れかを含む第２のコンテンツデータが上記記録部に記録されているか否かを判定する判定工程と、
　上記第２のコンテンツデータが上記記録部に記録されていると上記判定工程にて判定された場合に、上記第１のコンテンツデータを、上記記録部に記録されている上記第２のコンテンツデータを用いて生成する生成工程と、
　上記生成工程にて生成された上記第１のコンテンツデータを上記再生装置に送信する送信工程と、を含んでいることを特徴とする中継方法。
　請求項１から１０の何れか１項に記載の中継装置と、上記再生装置と、を含む通信システム。
　請求項１から１０の何れか１項に記載の中継装置と、上記再生装置と、上記送信装置と、を含む通信システム。
　請求項１から１０の何れか１項に記載の中継装置を動作させるプログラムであって、コンピュータを上記各手段として機能させるための中継制御プログラム。
　請求項１４に記載の中継制御プログラムが記録されているコンピュータ読み取り可能な記録媒体。