WO2012011490A1

WO2012011490A1 - コンテンツ取得装置、コンテンツ送信装置、コンテンツ送受信システム、データ構造、制御方法、制御プログラム、及び記録媒体

Info

Publication number: WO2012011490A1
Application number: PCT/JP2011/066431
Authority: WO
Inventors: 靖昭徳毛; 真毅高橋; 琢也岩波; 義昭荻澤; 毅金子; 典男伊藤
Original assignee: シャープ株式会社
Priority date: 2010-07-20
Filing date: 2011-07-20
Publication date: 2012-01-26

Abstract

　クライアント（１１）は、Content-Typeヘッダと、品質種別が独立に設定された複数のムービーフラグメントと、X-Representation-Idヘッダとを含む応答メッセージを受信し、受信したContent-Typeヘッダから、コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記ムービーフラグメントを、X-Representation-Idヘッダを参照しながら再生する。

Description

コンテンツ取得装置、コンテンツ送信装置、コンテンツ送受信システム、データ構造、制御方法、制御プログラム、及び記録媒体

　本発明は、コンテンツ要求を送信して取得したコンテンツを再生するコンテンツ取得装置等に関する。

　従来から、通信ネットワークを介したコンテンツの提供を行う技術が広く用いられている。例えば、下記の特許文献１には、クライアントからサーバにＨＴＴＰでコンテンツのリクエストを送信し、クライアントがこのリクエストに対する応答として受信したコンテンツをストリーミング再生するコンテンツストリーミングサービスシステムが開示されている。

　また、近年では、パーソナルコンピュータ等のみならず、テレビジョン受像機や、携帯端末等の様々な機器によって、様々なネットワークを介してコンテンツの送受信が行われるようになっている。そして、ネットワークのトラフィックは、時間によって変化する。

　このため、コンテンツを送受信するときには、送受信に関わる機器の種類や性能、使用する通信手段、そのときのネットワークトラフィック等に応じた送受信態様とすることが望ましい。

　例えば、同じコンテンツに再生品質の異なる２つのバージョンが存在する場合、ネットワークトラフィックに余裕があれば、データの容量が大きくても再生品質の高いバージョンを送受信することが望まれる。一方、ネットワークトラフィックに余裕がなければ、データの容量の小さい再生品質の低いバージョンを送受信することが望まれる。

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

　ここで、上記特許文献１で送信されるコンテンツは、ＭＰ４の動画像であり、ＭＰ４は、１つのファイルが複数のフラグメントで構成されているという特徴がある。このようなフラグメント化されたコンテンツであれば、フラグメント単位で再生品質やコンテンツの種別を設定可能とすることにより、ネットワーク状況等に応じたきめ細かい適応化を行うことが可能になる。

　しかしながら、従来は、各フラグメントの再生品質や種別が独立に設定されたコンテンツをネットワーク上で取り扱うための技術が確立されておらず、ネットワーク状況等に応じたきめ細かい適応化を行うことはできなかった。

　本発明は、上記の問題点に鑑みてなされたものであり、その目的は、各フラグメントの再生品質及び種別の少なくとも何れかが独立に設定されたコンテンツを取り扱うことを可能にするコンテンツ取得装置等を提供することにある。

　上記の課題を解決するために、本発明のコンテンツ取得装置は、コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置であって、上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信手段と、上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生手段とを備えていることを特徴としている。

　そして、本発明のコンテンツ取得装置の制御方法は、上記課題を解決するために、コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置の制御方法であって、上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信ステップと、上記応答受信ステップで受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生ステップとを含むことを特徴としている。

　上記の構成によれば、複数のフラグメントを１つのメディアセグメントとして受信するので、１つのフラグメントを１つの応答メッセージで受信する場合と比べて、少ない応答メッセージの受信回数で要求するコンテンツ全体を取得することができる。なお、メディアセグメントは、上記の通り、複数のフラグメントで構成されたコンテンツの一部または全部を構成するものであり、少なくとも２つのフラグメントを含むものである。つまり、コンテンツは１つ以上のメディアセグメントで構成され、メディアセグメントは２つ以上のフラグメントで構成される。

　また、上記の構成によれば、送信形式情報にメディアセグメントを送信する旨が示されているので、この応答メッセージを受信したコンテンツ取得装置は、メディアセグメントが受信されることを認識することができ、これにより、受信したメディアセグメントに含まれる各フラグメントを適切に扱うことが可能になる。

　そして、上記の構成によれば、受信したフラグメントの再生品質及び種別の少なくとも何れかが独立に設定されている。このため、受信したフラグメントを再生するときには、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わる可能性がある。なお、この再生品質は、例えば解像度やビットレートのように、音声や画像の品質（精細さ）を規定するものであり、再生品質が高いほど、フラグメントのデータサイズが大きくなるものである。また、上記種別は、例えば音声言語や使用コーデック等のように、当該フラグメントの再生時の取り扱いに影響を与えるものである。つまり、再生品質及び種別の少なくとも何れかが異なるフラグメントとは、何れも１つのコンテンツの一部を構成している点で共通しているが、音声や画像の品質及び再生時の取り扱いの何れかまたは両方が異なっているフラグメントである。

　ここで、上記応答メッセージには、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報が含まれている。このため、上記コンテンツ取得装置は、この品質／種別情報を参照して、再生しようとするフラグメントの再生品質及び種別の少なくとも何れかを特定することにより、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わったとしても再生することができる。

　したがって、上記の構成によれば、各フラグメントの再生品質及び種別の少なくとも何れかが独立に設定されたメディアセグメントを取り扱うことを可能にすることができるという効果を奏する。

　また、本発明のコンテンツ送信装置は、上記課題を解決するために、要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置であって、上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、上記付加情報生成手段が生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成手段とを備えていることを特徴としている。

　また、本発明のコンテンツ送信装置の制御方法は、上記課題を解決するために、要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置の制御方法であって、上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成ステップと、上記付加情報生成ステップで生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成ステップとを含むことを特徴としている。

　上記の構成によれば、複数のフラグメントを１つのメディアセグメントとして送信するので、１つのフラグメントを１つの応答メッセージで送信する場合と比べて、１つのコンテンツを送信するために必要な応答メッセージの送信回数を減らすことができる。

　また、上記の構成によれば、付加情報にメディアセグメントを送信する旨が示されているので、この応答メッセージを受信した装置（コンテンツを要求した装置）は、メディアセグメントが受信されることを認識することができ、これにより、受信したメディアセグメントに含まれる各フラグメントを適切に扱うことが可能になる。

　そして、上記の構成によれば、送信するフラグメントの再生品質及び種別の少なくとも何れかが独立に設定されている。このため、受信したフラグメントを再生するときには、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わる可能性がある。

　そこで、上記の構成によれば、上記応答メッセージに、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報を含めている。このため、この応答メッセージを受信した装置は、この品質／種別情報を参照して、再生しようとするフラグメントの再生品質及び種別の少なくとも何れかを特定することにより、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わったとしても再生することができる。つまり、上記の構成によれば、再生品質及び種別の少なくとも何れかが独立に設定されたメディアセグメントを取り扱うことを可能にすることができるという効果を奏する。

　そして、上記の構成によれば、ネットワークのトラフィック等の状況に応じて、フラグメントの再生品質及び種別の少なくとも何れかを切り替えたとしても、この応答メッセージを受信した装置が、それらのフラグメントを再生することができる。

　また、本発明のデータ構造は、上記課題を解決するために、コンテンツ取得装置から要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置が生成する応答メッセージのデータ構造であって、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含み、上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断して、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生することを特徴としている。

　上記の構成によれば、１つの応答メッセージに複数のフラグメントを１つのメディアセグメントとして含めるので、１つの応答メッセージに１つのフラグメントを含める場合と比べて、コンテンツ全体を送信するための応答メッセージの数が少なくて済む。

　また、上記の構成によれば、付加情報にメディアセグメントを送信する旨が示されているので、この応答メッセージを受信したコンテンツ取得装置は、メディアセグメントが受信されることを認識することができ、これにより、受信したメディアセグメントに含まれる各フラグメントを適切に扱うことが可能になる。

　そして、上記の構成によれば、メディアセグメントに含まれる各フラグメントの再生品質及び種別の少なくとも何れかが独立に設定されている。このため、上記の応答メッセージを受信した装置が、その応答メッセージに含まれるフラグメントを再生するときには、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わる可能性がある。

　ここで、上記応答メッセージには、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報が含まれている。このため、上記コンテンツを再生するときには、この品質／種別情報を参照して、再生しようとするフラグメントの再生品質及び種別の少なくとも何れかを特定することにより、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わったとしても再生することができる。

　また、本発明のコンテンツ取得装置は、コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置であって、上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを受信する応答受信手段と、上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照しながら、上記各フラグメントを再生する再生手段とを備えていることを特徴としている。

　上記の構成によれば、複数のフラグメントを１つのメディアセグメントとして受信するので、１つのフラグメントを１つの応答メッセージで受信する場合と比べて、少ない応答メッセージの受信回数で要求するコンテンツ全体を取得することができる。

　そして、上記の構成によれば、受信したフラグメントのそれぞれにタイムスタンプが対応付けられており、このタイムスタンプを参照しながら、各フラグメントを再生する。

　したがって、上記の構成によれば、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定し、これを用いて再生を行うことができるという効果を奏する。

　なお、各フラグメントの再生開始時間を特定することにより、フラグメントがその再生時間より前に受信されたかを確認することができ、これによりフラグメントの受信遅延の有無を検出することもできる。また、ある再生開始時間のフラグメントの再生品質が低い場合に、その再生開始時間と所望の再生品質を指定して、より再生品質が高いバージョンのフラグメントを要求することも容易である。

　また、本発明のコンテンツ送信装置は、要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置であって、上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、上記付加情報生成手段が生成した付加情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを生成する応答メッセージ生成手段とを備えていることを特徴としている。

　上記の構成によれば、複数のフラグメントを１つのメディアセグメントとして送信するので、１つのフラグメントを１つの応答メッセージで送信する場合と比べて、少ない応答メッセージの送信回数で要求されたコンテンツ全体を送信することができる。

　そして、上記の構成によれば、受信したフラグメントのそれぞれにタイムスタンプが対応付けられている。

　したがって、上記の構成によれば、上記応答メッセージを受信した装置に、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定させることができるという効果を奏する。

　また、本発明のデータ構造は、コンテンツ取得装置から要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置が生成する応答メッセージのデータ構造であって、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、上記複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられており、上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照しながら上記各フラグメントを再生することを特徴としている。

　上記の構成によれば、複数のフラグメントを１つのメディアセグメントとしているので、１つのフラグメントを１つの応答メッセージで送信する場合と比べて、少ない応答メッセージの送信回数で要求されたコンテンツ全体を送信することができる。

　そして、上記の構成によれば、各フラグメントのそれぞれにタイムスタンプが対応付けられている。

　したがって、上記の構成によれば、上記応答メッセージを受信した装置に、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定させ、これを用いた再生を行わせることができるという効果を奏する。

　以上のように、本発明のコンテンツ取得装置は、要求メッセージに対する応答として、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信手段と、上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生手段とを備えている構成である。

　また、本発明のコンテンツ取得装置の制御方法は、要求メッセージに対する応答として、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信ステップと、上記応答受信ステップで受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生ステップとを含む構成である。

　上記の構成によれば、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わっているメディアセグメントを再生することができるという効果を奏する。

　また、本発明のコンテンツ送信装置は、以上のように、コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、上記付加情報生成手段が生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成手段とを備えている構成である。

　また、本発明のコンテンツ送信装置の制御方法は、コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成ステップと、上記付加情報生成ステップで生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成ステップとを含む構成である。

　上記の構成によれば、上記応答メッセージを受信した装置が、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わっているメディアセグメントを再生することを可能にすることができるという効果を奏する。

　また、本発明のデータ構造は、以上のように、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含み、上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断して、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する構成である。

　上記の構成によれば、上記データ構造の応答メッセージを受信したコンテンツ取得装置が、フラグメント間で再生品質及び種別の少なくとも何れかが切り替わっているメディアセグメントを、上記品質／種別情報を参照しながら再生することができるという効果を奏する。

　また、本発明のコンテンツ取得装置は、以上のように、要求メッセージに対する応答として、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを受信する応答受信手段と、上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照して、上記各フラグメントの再生開始時間を特定する開始時間特定手段とを備えている構成である。

　したがって、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定し、これを参照しながら各フラグメントを再生することができるという効果を奏する。

　また、本発明のコンテンツ送信装置は、以上のように、コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、上記付加情報生成手段が生成した付加情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを生成する応答メッセージ生成手段とを備えている構成である。

　したがって、上記応答メッセージを受信した装置に、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定させることができるという効果を奏する。

　また、本発明のデータ構造は、以上のように、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、上記複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられており、上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照して、上記各フラグメントの再生開始時間を特定する構成である。

　したがって、上記応答メッセージを受信した装置に、フラグメントの解析等を行うことなく、極めて容易に各フラグメントの再生開始時間を特定させ、これを参照しながら再生させることができるという効果を奏する。

　本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、添付図面を参照した次の説明で明白になるであろう。

本発明の一実施形態にかかる通信システムの概要を示す図であり、同図（ａ）は、通信システムを構成するクライアント、プロキシ、及びサーバの要部構成を示すブロック図であり、同図（ｂ）は、通信システムの構成例を示す図である。上記通信システムで取り扱うコンテンツを示す図であり、品質種別（ビットレート）の異なる３種類のメディアファイルで構成されるコンテンツの例を示している。上記通信システムがコンテンツの伝送単位として扱うメディアセグメントの概念を示す図であり、同図（ａ）は同じビットレート（品質種別）のムービーフラグメントでメディアセグメントを構成した例、同図（ｂ）は異なるビットレート（品質種別）のムービーフラグメントでメディアセグメントを構成した例を示す。上記サーバがコンテンツ伝送の適応化を行う場合のシーケンスの一例を示す図である。リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）（ｃ）は図４のリクエストの、同図（ｂ）（ｄ）はレスポンスのＨＴＴＰメッセージをそれぞれ示している。上記サーバの実行する処理の一例を示すフローチャートである。上記プロキシがコンテンツ伝送の適応化を行う場合のシーケンスの一例を示す図である。リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）（ｃ）（ｄ）は図７のリクエストの、同図（ｂ）（ｅ）はレスポンスのＨＴＴＰメッセージをそれぞれ示している。上記プロキシの実行する処理の一例を示すフローチャートであり、同図（ａ）は処理の全体の流れを示し、同図（ｂ）は同図（ａ）のＳ９０４で行われるリクエスト処理の詳細を示し、同図（ｃ）は同図（ａ）のＳ９０５で行われるレスポンス処理の詳細を示している。上記クライアントがコンテンツ伝送の適応化を行う場合のシーケンスの一例を示す図である。リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）（ｃ）は図１０のリクエストの、同図（ｂ）（ｄ）はレスポンスのＨＴＴＰメッセージをそれぞれ示している。上記クライアントの実行する処理の一例を示すフローチャートである。リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）（ｃ）は図４のリクエストの、同図（ｂ）（ｄ）はレスポンスのＨＴＴＰメッセージをそれぞれ示している。一般的なプロキシを適用した場合に、上記サーバがＮＷの状況等に基づいてコンテンツ伝送の適応化を行うシーケンスの一例を示す図である。リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図１４のリクエストの、同図（ｂ）（ｃ）はレスポンスのＨＴＴＰメッセージをそれぞれ示している。上記レスポンスの他の例を示す図である。

　＜通信システムの概要＞
　以下、本発明の実施の形態について、図１～図１６に基づいて詳細に説明する。まず、本実施形態の通信システムの概要を図１に基づいて説明する。図１は、通信システム（コンテンツ送受信システム）１の概要を示す図であり、同図（ａ）は、通信システム１を構成するクライアント（コンテンツ取得装置）１１、プロキシ（コンテンツ送信装置、中継装置）１２、及びサーバ（コンテンツ送信装置、コンテンツ提供装置）１３の要部構成を示すブロック図であり、同図（ｂ）は、通信システム１の構成例を示す図である。

　図示のように、クライアント１１は、ＮＷ１を介してプロキシ１２に接続し、プロキシ１２は、ＮＷ２を介してサーバ１３に接続しており、これらの機器によって通信システム１が構成されている。なお、ＮＷ１及びＮＷ２は、上記の各機器が相互に通信可能なものであればよく、有線通信のネットワークであってもよいし、無線通信のネットワークであってもよい。

　通信システム１は、クライアント１１が、サーバ１３から動画などのコンテンツを取得することのできるシステムである。本発明の通信システム１は、サーバ１３がコンテンツ毎にビットレートなど品質種別の異なる複数のデータを有している。そして、通信中のＮＷの状況等に基づいて、システム内で送受信されるコンテンツの品質をクライアント１１、プロキシ１２、サーバ１３のそれぞれが切り替えることができることを主な特徴としている。なお、クライアント１１は、サーバ１３と直接には接続されていないので、プロキシ１２を介してコンテンツを取得する。

　通信システム１では、クライアント１１は、ＮＷ１を介してプロキシ１２にコンテンツのリクエストを送信する。このリクエストを受信したプロキシ１２は、要求されたコンテンツがキャッシュ格納部１４に格納されているか確認し、格納されていればそのコンテンツをクライアント１１に送信する。

　一方、格納されていなければ、ＮＷ２を介してサーバ１３にそのコンテンツのリクエストを送信する。そして、このリクエストを受信したサーバ１３は、要求されたコンテンツをコンテンツ格納部１５から読み出してプロキシ１２に送信し、プロキシ１２がこのコンテンツをクライアント１１に送信する。これにより、クライアント１１は、要求したコンテンツを取得することができる。

　なお、図１（ａ）では、クライアント１１及びプロキシ１２を１つのみ示しているが、同図（ｂ）に示すように、１つのサーバ１３に複数のプロキシ１２が接続されていてもよく、１つのプロキシ１２に複数のクライアント１１が接続されていてもよい。同図（ｂ）の例では、１つのサーバ１３に複数のプロキシ１２（Ｐ_１、Ｐ_２、…）が接続されている。そして、Ｐ_１及びＰ_２には複数のクライアント１１（Ｃ_１１、Ｃ_１２、…、及び、Ｃ_２１、Ｃ_２２、…）がそれぞれ接続されている。

　つまり、同図（ｂ）の例では、Ｃ_１１、Ｃ_１２、…のクライアント１１は、Ｐ_１のプロキシ１２を介してコンテンツを取得し、Ｃ_２１、Ｃ_２２、…のクライアント１１は、Ｐ_２のプロキシ１２を介してコンテンツを取得する。なお、図１（ａ）（ｂ）では、全てのクライアント１１がＮＷ１に接続した構成となっているが、一部のクライアント１１はＮＷ２に接続しサーバ１３と直接通信可能な構成であってもかまわない。

　クライアント１１は、コンテンツを要求して取得する装置である。同図には示していないが、クライアント１１は、ユーザ操作を受け付ける入力部を備えており、この入力部で受け付けた入力操作に基づき、コンテンツを要求する。

　図示のように、クライアント１１は、クライアント１１の動作を統括して制御するクライアント制御部２０と、クライアント１１が外部の装置と通信するためのクライアント通信部２４を備えている。また、クライアント制御部２０には、クライアント状況判断部（事象検出手段、開始時間特定手段）２１、リクエスト実行部（応答受信手段、要求メッセージ送信手段）２２、及びコンテンツ再生部（再生手段）２３が含まれている。

　クライアント状況判断部２１は、予め定められた事象の発生を検出する。具体的には、クライアント状況判断部２１は、クライアント１１が要求したコンテンツが、予定よりも十分に早く受信されたという事象、及び予定よりも遅延して受信されたという事象を検出する。これらの事象は、クライアント１１が接続するＮＷ１の通信状況の良し悪しを示す事象である。

　リクエスト実行部２２は、コンテンツの送信を要求する要求メッセージを生成し、クライアント通信部２４を介してプロキシ１２に送信し、これに対する応答として応答メッセージを受信する。なお、クライアント１１がＮＷ２に接続されておりサーバ１３と直接通信可能な場合には、要求メッセージの送信先は、サーバ１３であってもよい。詳細については後述するが、リクエスト実行部２２が生成する要求メッセージは、MIMEマルチパート形式でコンテンツを受信可能であることを示すヘッダと、マルチパート化されたコンテンツを指定する情報とを含む点を特徴としている。

　また、リクエスト実行部２２は、クライアント状況判断部２１の判断結果に基づき、その後要求するコンテンツのビットレートを設定する。具体的には、クライアント状況判断部２１が、通信状況が悪いことを示す事象を検出した場合には、要求するコンテンツの品質をビットレートの低いものに切り替える。一方、通信状況が良いことを示す事象を検出した場合には、要求するコンテンツの品質をビットレートの高いものへ切り替える。

　コンテンツ再生部２３は、リクエスト実行部２２が取得したコンテンツを再生する。例えば、取得したコンテンツが動画像のコンテンツである場合には、コンテンツ再生部２３は、取得したコンテンツをデコードし、これにより得られた映像及び音声を外部の表示装置（図示せず）に出力させる。

　プロキシ１２は、要求されたコンテンツを送信する装置であると共に、コンテンツを要求して取得する装置である。プロキシ１２は、サーバ１３から受信したコンテンツ等を格納するキャッシュ格納部１４と接続されている。そして、要求されたコンテンツがキャッシュ格納部１４にあれば、キャッシュ格納部１４から読み出してクライアント１１に送信し、キャッシュ格納部１４になければサーバ１３に要求する。なお、キャッシュ格納部１４は、プロキシ１２に内蔵されていてもよい。

　図示のように、プロキシ１２は、プロキシ１２の動作を統括して制御するプロキシ制御部２５と、プロキシ１２が外部の装置と通信するためのプロキシ通信部２８とを備えている。また、プロキシ制御部２５には、プロキシ状況判断部（送信時事象検出手段）２６及びレスポンス／リクエスト実行部（付加情報生成手段、応答メッセージ生成手段、要求メッセージ送信手段）２７が含まれている。

　プロキシ状況判断部２６は、予め定められた事象の発生を検出する。具体的には、プロキシ状況判断部２６は、プロキシ１２が要求したコンテンツが、予定よりも十分に早く受信されたという事象、及び予定よりも遅延して受信されたという事象を検出する。これらの事象は、ＮＷ２の通信状況の良し悪しを示す事象である。また、クライアント１１に要求されたコンテンツが、予定よりも十分に早く送信されたという事象、及び予定よりも遅延して送信されたという事象を検出する。これらの事象は、ＮＷ１の通信状況の良し悪しを示す事象である。

　レスポンス／リクエスト実行部２７は、クライアント１１から受信した要求メッセージで指定されたコンテンツをキャッシュ格納部１４から読み出す。そして、読み出したコンテンツをMIMEマルチパート形式で送信する応答メッセージを生成し、これをクライアント１１に送信する。詳細については後述するが、レスポンス／リクエスト実行部２７が生成する応答メッセージは、MIMEマルチパート形式でコンテンツを送信することを示すヘッダと、マルチパート化されたコンテンツのフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含み、各フラグメントの再生品質が独立に設定されている点を特徴としている。

　また、要求メッセージで指定されたコンテンツがキャッシュ格納部１４に格納されていない場合には、そのコンテンツを要求する要求メッセージを生成し、これをサーバ１３に送信する。

　さらに、レスポンス／リクエスト実行部２７は、プロキシ状況判断部２６の検出結果に基づき、その後要求・応答するコンテンツのビットレートを設定する。具体的には、プロキシ状況判断部２６が、ＮＷ１の通信状況が悪いことを示す事象を検出した場合には、応答メッセージに含めるコンテンツの品質をビットレートの低いものに切り替える。一方、通信状況が良いことを示す事象を検出した場合には、応答メッセージに含めるコンテンツの品質をビットレートの高いものへ切り替える。また、プロキシ状況判断部２６が、ＮＷ２の通信状況が悪いことを示す事象を検出した場合には、サーバ１３に要求するコンテンツの品質をビットレートの低いものに切り替える。一方、通信状況が良いことを示す事象を検出した場合には、要求するコンテンツの品質をビットレートの高いものへ切り替える。

　サーバ１３は、要求されたコンテンツを送信する装置である。サーバ１３は、動画などのコンテンツを格納するコンテンツ格納部１５と接続されている。なお、コンテンツ格納部１５は、サーバ１３に内蔵されていてもよい。

　図示のように、サーバ１３は、サーバ１３の動作を統括して制御するサーバ制御部２９と、サーバ１３が外部の装置と通信するためのサーバ通信部３２とを備えている。また、サーバ制御部２９には、サーバ状況判断部（送信時事象検出手段）３０及びレスポンス実行部（付加情報生成手段、応答メッセージ生成手段）３１が含まれている。

　サーバ状況判断部３０は、予め定められた事象を検出する。具体的には、サーバ状況判断部３０は、プロキシ１２に要求されたコンテンツが、予定よりも十分に早く送信されたという事象、及び予定よりも遅延して送信されたという事象を検出する。これらの事象は、ＮＷ２の通信状況の良し悪しを示す事象である。

　レスポンス実行部３１は、プロキシ１２から受信した要求メッセージで指定されたコンテンツをコンテンツ格納部１５から読み出し、読み出したコンテンツをMIMEマルチパート形式で送信する応答メッセージを生成し、これをプロキシ１２に送信する。なお、要求メッセージの送信元は、クライアント１１であってもよく、この場合にはクライアント１１に直接応答メッセージを送信する。この応答メッセージは、レスポンス／リクエスト実行部２７が生成、送信するものと同様である。

　また、レスポンス実行部３１は、サーバ状況判断部３０の検出結果に基づき、その後応答するコンテンツのビットレートを設定する。具体的には、サーバ状況判断部３０が、ＮＷ２の通信状況が悪い事を示す事象を検出した場合には、応答メッセージに含めるコンテンツの品質をビットレートの低いものに切り替える。一方、通信状況が良いことを示す事象を検出した場合には、応答メッセージに含めるコンテンツの品質をビットレートの高いものへ切り替える。

　＜コンテンツのフォーマット＞
　続いて、サーバ１３に接続されているコンテンツ格納部１５に格納されているコンテンツのフォーマット（蓄積フォーマット）を、図２に基づいて説明する。図２では、（ａ）～（ｃ）に示した、品質種別（ここではビットレート）の異なる３種類のメディアファイル１、メディアファイル２、メディアファイル３で構成されるコンテンツが格納されている例を示している。

　なお、各メディアファイルの品質種別（ビットレート）は、メディアファイル１が４Ｍｂｐｓ、メディアファイル２が２Ｍｂｐｓ、そしてメディアファイル３が１Ｍｂｐｓである。ここでは、各メディアファイルの品質種別としてビットレートのみが異なる場合の例を説明するが、ビットレートの違いに加え、画像解像度、音声言語、コーデック等の品質種別が異なるメディアファイルで構成されるコンテンツであっても構わない。また、ビットレートは同じで、画像解像度、音声言語、及びコーデック等の少なくとも何れかが異なるコンテンツであってもよい。

　つまり、品質種別とは、コンテンツの再生品質及びコンテンツの種別の少なくとも何れかを指し、品質種別の異なるメディアファイルとは、コンテンツの内容は同じであるが、再生品質及び種別の少なくとも何れかが異なるメディアファイルを指す。

　図示のように、コンテンツを構成する各メディアファイルは、予め定められた単位でフラグメント化されている。この単位はコンテンツを構成するメディアファイル間で共通とし、例えば１秒といった時間単位や、画像符号化におけるＧＯＰ（Group Of Picture）単位などであれば構わない。

　以降の説明では、このフラグメントをムービーフラグメントと呼び、本発明の通信システム１において、クライアント１１で再生されるコンテンツの品質切り替えを行うことができる最小単位である。また、以降の説明では、ムービーフラグメントで構成されるメディアファイルの具体例としてＭＰ４ファイルを用いる。

　メディアファイルをＭＰ４ファイルとする場合、フラグメント内の映像・音声を管理するヘッダ情報を格納した「ｍｏｏｆ」と、クライアントで再生される映像・音声などのデータが格納された「ｍｄａｔ」で構成されたフラグメントがムービーフラグメントに相当する。

　ここで、ＭＰ４ファイルにおいては、「ｍｏｏｆ」、「ｍｄａｔ」以外に、メディアファイル全体に係る情報、例えばムービーフラグメント画像解像度やプロファイル情報等、クライアント１１における再生装置（コンテンツ再生部２３）の初期化に必要な情報（再生情報）が前述の「ｍｏｏｆ」、「ｍｄａｔ」とは別の「ｍｏｏｖ」に格納されている。

　このため、「ｍｏｏｖ」に格納された再生情報は、再生開始前にクライアント１１へ通知する必要がある。「ｍｏｏｖ」に格納された再生情報は、ムービーフラグメントとは別の手順で通知してもよく、必ずしも「ｍｏｏｖ」をムービーフラグメントに含める必要はないが、以降の説明では、各メディアファイルの先頭ムービーフラグメントが「ｍｏｏｖ」を含む例を説明する。つまり、図２の「再生装置の初期化に必要な情報」は、「ｍｏｏｖ」である。

　また、図２に示す通り、各メディアファイル内のムービーフラグメントには、先頭のムービーフラグメントから順に「movie fragment 1」、「movie fragment 2」と連番を付している。なお、各ムービーフラグメントには１秒分の映像データが含まれるものとする。
＜コンテンツの伝送プロトコル及びコンテンツの伝送単位＞
　次に、本発明の通信システム１において、コンテンツの送受信に用いる伝送プロトコル及びコンテンツの伝送単位について説明する。

　伝送プロトコルとしては、クライアント１１～プロキシ１２間、及びプロキシ１２～サーバ間共に、汎用的なファイル伝送プロトコルとして広く用いられているＨＴＴＰを用いる。ただし、通信システム１において使用可能伝送プロトコルは、ＨＴＴＰに限定されるものではなく、類似する他の伝送プロトコルを適用することも可能である。

　続いて、コンテンツの伝送単位を図３に基づいて説明する。通信システム１においては、クライアント１１～プロキシ１２間、およびプロキシ１２～サーバ１３間共に、コンテンツをメディアセグメントと呼ぶ単位に分割し、ＨＴＴＰを用いて伝送を行う。

　図３は、通信システム１がコンテンツの伝送単位として扱うメディアセグメントの概念を示す図であり、同図（ａ）は同じビットレート（品質種別）のムービーフラグメントでメディアセグメントを構成した例を示し、同図（ｂ）は異なるビットレート（再生品質）のムービーフラグメントでメディアセグメントを構成した例を示している。

　メディアセグメントは、少なくとも１つのムービーフラグメントを含んで構成されるものである。別の観点からは、コンテンツは１つ以上のメディアセグメントで構成されており、各メディアセグメントは１つ以上のムービーフラグメントで構成されていると言える。通常、メディアセグメントは、所定のコンテンツにおいて、再生時間の連続する２つ以上のムービーフラグメントを含んで構成されるが、１つのムービーフラグメントで構成されてもよいし、再生時間が連続しないムービーフラグメントで構成されていてもよい。

　メディアセグメントは、単独のメディアファイルに属するムービーフラグメントのみから構成されていてもよいし、複数のメディアファイルにまたがったムービーフラグメントから構成されていても構わない。つまり、異なるメディアファイルに含まれている、再生品質の異なるムービーフラグメントを組み合わせてメディアセグメントを構成してもよい。

　具体的には、同図（ａ）は、単独のメディアファイルに属する４Ｍｂｐｓのムービーフラグメント1～3をまとめて、１つのメディアセグメントとしている例である。また、同図（ｂ）は、複数のメディアファイルにまたがり、ビットレートが４Ｍｂｐｓの「movie fragment1」と、ビットレートが２Ｍｂｐｓの「movie fragment2」「movie fragment3」をまとめて、１つのメディアセグメントとしている例である。

　なお、メディアセグメントは、所定のコンテンツにおける再生時間の連続する２つ以上のムービーフラグメントを含むものであればよく、１つのメディアセグメントに含まれるムービーフラグメントの数は特に限定されない。

　≪実施の形態１－１：サーバによる適応化≫
　ここでは、ＮＷ２の状況に応じて、サーバ１３がコンテンツ伝送の適応化を行う例について、図４の通信シーケンス例を用いて説明する。なお、図４の通信シーケンス例は、サーバ１３に接続されたコンテンツ格納部１５に４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの３種類のメディアファイルで構成されるコンテンツが格納されており、プロキシ１２に接続されたキャッシュ格納部１４には、サーバ１３から受信したメディアセグメントのキャッシュが存在していない状態で開始される通信シーケンス例であり、図中に示した時点でＮＷ２の通信状況の悪化（通信トラフィックの増加）が生じた場合への適応例を示している。

　まず、クライアント１１は、予め通知されたＵＲＬを用いて、所望するコンテンツの冒頭部分のメディアセグメントである「media segment1」を要求する（リクエスト４１）。

　リクエスト４１を受信したプロキシ１２は、要求されたＵＲＬに紐づけられた「media segment1」がキャッシュ格納部１４に格納されているかを確認する。この「media segment1」が格納されていないことを確認したプロキシ１２は、「media segment1」を要求するリクエスト４２をサーバ１３に送信する。

　リクエスト４２を受信したサーバ１３は、要求された「media segment1」を構成する各ムービーフラグメントをコンテンツ格納部１５から読み出してプロキシ１２に送信する。この時点では、ＮＷ２の通信状況は良好であるため、サーバ１３は、最も再生品質の高い（ビットレートの高い）４Ｍｂｐｓのメディアファイルで「media segment1」を構成して応答する。

　なお、図４の例では「media segment1」はコンテンツ冒頭の０～６０秒のデータに相当する。上述のように、各ムービーフラグメントには１秒分の映像データが含まれるため、このメディアセグメントを構成するムービーフラグメントとして、４Ｍｂｐｓ品質のムービーフラグメントが６０個含まれている。また、「media segment1」には、再生装置の初期化に必要な情報を含む２Ｍｂｐｓ品質、及び１Ｍｂｐｓ品質のムービーフラグメントが各１個含まれており、合計６２個のムービーフラグメントが含まれる。（レスポンス４３）。

　レスポンス４３を受信したプロキシ１２は、メディアセグメントに含まれる各ムービーフラグメントを順次キャッシュ格納部１４に格納すると共に、クライアント１１に転送する（レスポンス４４）。

　クライアント１１がレスポンス４４を受信完了した後、ＮＷ２の通信状況が悪化したものとして、以降の処理を説明する。クライアント１１は、続く２番目のメディアセグメント（所定コンテンツの６０秒～１２０秒）のＵＲＬを指定して要求する（リクエスト４５）。

　リクエスト４５を受信したプロキシ１２は、リクエスト４１の場合と同様に、要求されたメディアセグメントがキャッシュ格納部１４に存在しないため、サーバ１３に当該メディアセグメントを要求する（リクエスト４６）。

　サーバ１３がリクエスト４６を受信した時点では、サーバ１３はＮＷ２の通信状況の悪化を検知しておらず、リクエスト４１を受信した場合と同様に、４Ｍｂｐｓ品質のムービーフラグメントを用いて応答を開始する。しかし、この時点ではＮＷ２の通信状況が悪化しているため、プロキシ１２への応答遅延が発生する。

　サーバ１３は、この応答遅延を検知してＮＷ２の通信状況が悪化したと判断し、以降送信するムービーフラグメントを低ビットレート（図４の例では２Ｍｂｐｓ）に切り替えて送信する（レスポンス４７）。なお、サーバ１３の動作詳細については後述する。

　レスポンス４７を受信したプロキシ１２は、各ムービーフラグメントを順次キャッシュ格納部１４に格納するとともに、クライアント１１に転送する（レスポンス４８）。以降同様に、クライアント１１にコンテンツ全体が取得されるまで処理を繰り返す。

　＜ＨＴＴＰメッセージ＞
　続いて、図４のシーケンス図で使用されるリクエストメッセージ及びレスポンスメッセージの詳細を図５に基づいて説明する。図５は、リクエストメッセージまたはレスポンスメッセージとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図４のリクエスト４１及び４２の、同図（ｂ）はレスポンス４３及び４４の、同図（ｃ）はリクエスト４５及び４６の、そして同図（ｄ）はレスポンス４７及び４８のＨＴＴＰメッセージをそれぞれ示している。なお、ここでは、ＨＴＴＰメッセージに含まれる要素のうち、本発明に特有の要素を中心に説明し、公知の要素については適宜説明を省略する。

　（コンテンツを要求するリクエスト１）
　同図（ａ）に示すように、「media segment1」（コンテンツの０秒～６０秒部分）を要求するリクエスト４１及び４２に対応するＨＴＴＰメッセージには、リクエストラインとヘッダが含まれる。

　同図（ａ）のリクエストラインには、コンテンツを取得するメソッドを示す「ＧＥＴ」と、サーバ１３から取得する対象リソースのＵＲＬが記述されている。このＵＲＬは、予めサーバ１３が提供可能なリソース（各メディアセグメント）毎に割り当てた識別子である。

　なお、以降の説明では、サーバ１３が提供可能な各メディアセグメントに対し、「／コンテンツ名／メディアセグメント番号」、あるいは「／コンテンツ名／メディアセグメント番号／品質種別識別子（再生品質指定情報）」の形式でＵＲＬを割り当てているものとする。この２種類のＵＲＬの形式はそれぞれ、前者が指定されたメディアセグメントの最大品質を送信側（サーバ１３あるいはプロキシ１２）で決定する場合に使用し、後者は指定されたメディアセグメントの最大品質を受信側（クライアント１１あるいはプロキシ１２）で指定する場合に使用するためのものである。

　同図（ａ）では、ＵＲＬが「/content1/1」であり、これは、コンテンツ名が「content1」の１番目のメディアセグメントに対する取得要求であることを示している。また、品質種別識別子が含まれていないので、このリクエストメッセージに対して送信されるメディアセグメントの最大品質は、サーバ１３が決定する。

　また、同図（ａ）のヘッダには、クライアント１１が処理可能なデータ形式を示す「Accept」ヘッダが含まれている。そして、この「Accept」ヘッダに、サーバ１３あるいはプロキシ１２がメディアセグメントを送信する際に用いるデータ形式を示す「multipart/media-segment」が記述されている。これにより、クライアント１１が当該データ形式でのデータ受信可能であることを示している。

　（コンテンツを送信するレスポンス１）
　同図（ｂ）に示すように、コンテンツの冒頭部分の「media segment1」を送信するレスポンス４３及び４４に対応するＨＴＴＰメッセージには、ステータスライン、付加情報を通知するヘッダ、及び「media segment1」を格納するメッセージボディが含まれる。

　ステータスラインには、リクエストを正常に受け付けたことを示すステータス番号「200」等が記述されている。

　ヘッダには、送信するコンテンツに関する情報が記述される。図示の例では、送信するコンテンツの種別を示す「Content-Type」ヘッダ（送信形式情報）、送信するメディアセグメントのコンテンツ全体に対する位置を示す「X-Media-Segment-Index」ヘッダ、送信するメディアセグメントのタイムスタンプを示す「X-Media-Segment-Timestamp」ヘッダ、及び選択可能な品質種別のリストを示す「X-Representation-List」ヘッダが含まれている。なお、ヘッダの名称中の先頭の「X」は、そのヘッダを本実施形態で新規に定義したことを示している。

　図示の例では、「Content-Type」ヘッダに「multipart/media-segment」が記述されており、メッセージボディにメディアセグメントがMIMEマルチパート形式で格納されていることを示している。これにより、このヘッダを受信した装置（クライアント１１またはプロキシ１２）は、このヘッダに続いて受信するデータが、MIMEマルチパート形式で送信されたメディアセグメントであることを認識することができる。そして、このヘッダには、マルチパートの各パートの境界が「THIS_STRING_SEPARATES」であることを示す情報が含まれている。

　さらに図示の例では、「X-Media-Segment-Index」ヘッダが含まれている。このヘッダは、コンテンツの全体に対する当該メディアセグメント番号を示すものである。同図では、「1/60」と記述されており、これは、コンテンツ全体で６０のメディアセグメントがあるうち、１番目のメディアセグメントを示している。この情報により、コンテンツの全長及び現在の再生位置を把握できるので、この情報を参照して、コンテンツ中の任意のメディアセグメントにアクセスすることもできる。

　また、図示の例では、「X-Representation-List」ヘッダが含まれている。このヘッダは、当該コンテンツの品質種別の選択肢を示すものである。このヘッダには、品質種別識別子と、品質種別情報と、テンプレートＵＲＬとを含むリストが記述されている。図示の例では、「1; bitrate=4000000; url=”/content1/$index$/1”, 2; bitrate=2000000; url=”/content1/$index$/2”, 3; bitrate=1000000; url=”/content1/$index$/3”, *;bitrate=*; url=”/content1/$index$”」と記述されている。これは、品質種別識別子１～３で示される３種類の中から品質指定が可能であり、それぞれの品質種別情報としてビットレートが４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの品質であることを示している。また各品質種別のメディアセグメントを取得するためのＵＲＬがそれぞれ、「/content1/$index$/1」、「/content1/$index$/2」、「/content1/$index$/3」であることを示している。

　「$index$」はメディアセグメント番号に置き換えて用いることを示すパラメタであり、前述の通り、サーバ１３が各メディアセグメントに「／コンテンツ名／メディアセグメント番号／品質種別識別子」の形式でＵＲＬを割り当てていることを示している。なお、当該ヘッダの「*;bitrate=*; url=”/content1/$index$”」は、品質種別を指定せずに当該コンテンツの各メディアセグメントへアクセスするためのＵＲＬを示している。そして、前述の通り、「／コンテンツ名／メディアセグメント番号」の形式でサーバ１３がＵＲＬを割り当てていることを示している。

　ただし、通信システム１において、クライアント１１、あるいはプロキシ１２がＵＲＬで品質種別の指定を行った場合でも、サーバ１３、あるいはプロキシ１２が指定した品質のメディアセグメントが必ずしも送受信される訳ではない。通信システム１では、指定された品質を上限として、ＮＷの通信状況に応じて、適応的に異なる品質のムービーフラグメントで構成されたメディアセグメントが送受信される。

　クライアント１１は、「X-Media-Segment-Index」ヘッダ、及び「X-Representation-List」ヘッダの情報を用いることで、当該コンテンツの任意のメディアセグメントのＵＲＬを把握し、所望のメディアセグメントにアクセスすることが可能である。従って、クライアント１１がサーバ１３上のコンテンツを取得するには、事前に当該コンテンツの先頭メディアセグメントのＵＲＬのみ通知されていれば、以降のメディアセグメントには、当該ヘッダの情報を用いてアクセスが可能である。このように、テンプレートＵＲＬを使用することで、サーバにおいて自由度の高いコンテンツＵＲＬの設計が可能となる。

　また、これらのヘッダが存在することにより、プロキシ１２のような中継装置が、別途サーバ１３との通信を必要とせず、サーバ１３の提供可能なメディアセグメントの品質種別（ビットレート）及び当該メディアセグメントへのアクセス手段（ＵＲＬ）を把握することが可能になる。なお、図示の例では、「X-Representation-List」ヘッダにおける品質種別情報の例として、ビットレート情報のみを用いている。しかし、ビットレート情報に加えて、またはビットレート情報の代わりに、画面解像度情報、言語情報、コーデック情報などを用いる構成でも構わない。

　また、「X-Media-Segment-Timestamp」ヘッダは、メディアセグメントのタイムスタンプを示すものであり、メディアセグメントに含まれる先頭のムービーフラグメントのタイムスタンプがミリ秒単位で記述されている。このタイムスタンプは、クライアント１１、プロキシ１２、サーバ１３のそれぞれが、ＮＷの通信状況の変化を検知する目的などで使用する。

　メッセージボディには、メディアセグメントを構成する複数のムービーフラグメントがMIMEマルチパート形式で格納されている。ここでは、４Ｍｂｐｓ（品質種別識別子＝１）の１番目～６０番目までの６０個のムービーフラグメントと、再生装置の初期化に必要な情報を含む２Ｍｂｐｓ（品質種別識別子＝１）及び１Ｍｂｐｓ（品質種別識別子＝２）の１番目のムービーフラグメントとでメディアセグメントが構成されている。このように構成にすることにより、再生装置の初期化に必要な情報を別途予めクライアント１１に送信しておく必要がなくなる。

　MIMEマルチパート形式の各パートにはメディアセグメントを構成する各ムービーフラグメントが格納されており、この各パートのヘッダにも付加情報が記載されている。図示の例では、ムービーフラグメントのコンテンツ種別を示す「Content-Type」ヘッダ、当該ムービーフラグメントのタイムスタンプ（単位はミリ秒）を示す「X-Timestamp」ヘッダが記述されている。この「X-Timestamp」ヘッダの示すタイムスタンプを参照することにより、ムービーフラグメントを解析することなく、そのムービーフラグメントの再生時間（再生開始タイミング）を特定することができる。また、ムービーフラグメントの品質種別を示す「X-Representation-Id」ヘッダ（品質／種別情報）も記述されている。

　「X-Representation-Id」には、上述の「X-Representation-List」に示される品質種別識別子のいずれかが記述されている。この「X-Representation-Id」ヘッダ、及び「X-Representation-List」ヘッダを参照することにより、そのムービーフラグメントの品質種別（ビットレート）を特定することができる。このため、この応答メッセージを受信したクライアント１１は、連続して再生するムービーフラグメントのビットレートが切り替わりを検出して再生することができる。そして、各パートには、そのパートのムービーフラグメントのデータ実体（バイナリデータ）が含まれる。

　なお、各パートに含まれるヘッダはこれらの例に限られず、ムービーフラグメントに関する任意のデータをヘッダに含めることができる。例えば、ムービーフラグメントの解像度を示すヘッダ、ムービーフラグメントの使用言語を示すヘッダ、ムービーフラグメントの使用コーデックを示すヘッダ等を追加してもよい。

　（コンテンツを要求するリクエスト２）
　同図（ｃ）に示すように、リクエスト４５及び４６に対応するＨＴＴＰメッセージは、リクエスト対象のＵＲＬ（メディアセグメント）が変わっている点を除けば、同図（ａ）のＨＴＴＰメッセージ形式と同様である。

　ここで、リクエスト４５及び４６は、同図（ａ）に示す１回目のリクエストの次に送信されるリクエストであり、リクエストＵＲＬは予めクライアント１１に通知されたものではなく、同図（ｂ）に示す１回目のレスポンスの「X-Representation-List」ヘッダ及び「X-Media-Segment-Index」ヘッダの値を基に、クライアント１１が生成したものである。

　（コンテンツを送信するレスポンス２）
　同図（ｄ）に示すように、レスポンス４７及び４８に対応するＨＴＴＰメッセージは、同図（ｂ）のＨＴＴＰメッセージの形式と基本的に同様である。ただし、メディアセグメントレスポンス４７及び４８は、２つ目のメディアセグメントを送信するものである。このため、「X-Media-Segment-Index」ヘッダは「2/60」と記述されており、サーバがＮＷ２の通信状況悪化を検知後に送信されたムービーフラグメントが２Ｍｂｐｓ（品質種別識別子＝2: 「X-Representation-Id」ヘッダが「2」）となっている。

　＜サーバの動作フローチャート＞
　次に、サーバ１３が実行する処理の詳細を図６に基づいて説明する。図６は、サーバ１３の実行する処理の一例を示すフローチャートである。

　サーバ１３のレスポンス実行部３１は、リクエストの受信を待ち受けており、リクエストの受信を確認する（Ｓ６０１）と、受信したリクエストを解析して、どのようなメディアセグメントで応答するかを決定する（Ｓ６０２）。具体的には、リクエストは図５（ａ）のようなＨＴＴＰメッセージとして受信するので、レスポンス実行部３１は、このメッセージに含まれるＵＲＬから、送信するメディアセグメントのビットレートなどの品質種別の初期値を決定する。ＵＲＬで品質種別の指定があれば、そこで指定された品質種別を初期値とし、指定が無い場合には最も品質の高いものを初期値とする。なお、直前のレスポンス送信時に検出したＮＷ２の通信状況を考慮して初期値を決定しても構わない。

　続いて、レスポンス実行部３１は、レスポンスとして送信するＨＴＴＰメッセージを生成し、このＨＴＴＰメッセージのヘッダ部分を、サーバ通信部３２を介して、リクエストの送信元（クライアント１１またはプロキシ１２）に送信する（Ｓ６０３）。このＨＴＴＰメッセージは、例えば図５（ｂ）のようなメッセージである。また、レスポンス実行部３１は、ヘッダ部分を送信した旨をサーバ状況判断部３０に通知する。

　この通知を受信したサーバ状況判断部３０は、ムービーフラグメントの送信時間を評価するため、メディアセグメントの送信開始と共にタイマを初期化し、時間のカウントを開始させる。タイマの初期値としては、メディアセグメントのタイムスタンプを示す「X-Media-Segment-Timestamp」ヘッダの値から予め定めた閾値Ｔ_ｉｎｉｔを引いた値を用いる。

　続いて、サーバ状況判断部３０は、送信時間の評価を行う（Ｓ６０５）。具体的には、サーバ状況判断部３０は、Ｓ６０４でカウントを開始したタイマの示す時間ｔと、送信するムービーフラグメントのタイムスタンプＴ_ｆｒ（X-Timestampの値）とを比較する。

　この比較の結果、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には、予定より十分に早くムービーフラグメントの送信が完了すると判断し、Ｓ６０６に進む。これに対し、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には、遅延が生じると判断し、Ｓ６０７に進む。一方、上記の何れにも該当しない場合（｜ｔ－Ｔ_ｆｒ｜≦Ｔ_ｔｈの場合）には、Ｓ６０８に進む。

　つまり、サーバ状況判断部３０は、送信するムービーフラグメントに対応付けられたタイムスタンプの値をＴ_ｆｒとし、予め定めたゼロ以上の閾値をＴ_ｔｈとして、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には通信状況が悪いことを示す事象を検出したと判断する。一方、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には通信状況が良いことを示す事象を検出したと判断する。

　Ｓ６０６では、サーバ状況判断部３０は、通信状況が良いことを示す事象を検出した旨をレスポンス実行部３１に通知する。そして、この通知を受信したレスポンス実行部３１は、送信するムービーフラグメントを、要求された品質種別指定のビットレートを超えない範囲で高ビットレートのものに切り替える。この後、処理はＳ６０８に進む。

　Ｓ６０７では、サーバ状況判断部３０は、通信状況が悪いことを示す事象を検出した旨をレスポンス実行部３１に通知する。そして、この通知を受信したレスポンス実行部３１は、送信するムービーフラグメントを低ビットレートのものに切り替える。この後、処理はＳ６０８に進む。

　Ｓ６０８では、レスポンス実行部３１は、ムービーフラグメントを、MIMEマルチパートの１パートとして送信する。そして、レスポンス実行部３１は、Ｓ６０２で決定したメディアセグメントに含まれる全てのムービーフラグメントを送信したかを確認する（Ｓ６０９）。そして、全て送信済みであることを確認した場合（Ｓ６０９でＹＥＳ）にはＳ６１０の処理に進み、未送信のものが確認された場合（Ｓ６０９でＮＯ）には、Ｓ６０５の処理に戻る。

　Ｓ６１０では、レスポンス実行部３１は、要求されたコンテンツの全てのメディアセグメントを送信したかを確認する。そして、全て送信済みであることを確認した場合（Ｓ６１０でＹＥＳ）には処理を終了し、未送信のものが確認された場合（Ｓ６１０でＮＯ）には、Ｓ６０１の処理に戻る。

　なお、上記では、ムービーフラグメント単位でビットレートの切り替えを行う例を示したが、メディアセグメント単位でビットレートの切り替えを行ってもよい。この場合には、直前に送信したメディアセグメントに含まれるムービーフラグメントのうち、送信に遅延が生じると判断された（または十分に早く送信されると判断された）ものの割合に基づいて、次に送信するメディアセグメントのビットレートを決定してもよい。

　例えば、サーバ状況判断部３０は、送信に要した時間が予定時間より十分に早かったムービーフラグメントの数Ｎ_１と、送信に遅延が生じたムービーフラグメントの数Ｎ_２とを、例えばＳ６０６、６０７でカウントしておいてもよい。そして、１つのメディアセグメントの送信完了後、Ｎ_２－Ｎ_１＞０であれば、全体的に遅延があると判断（通信状況が悪いことを示す事象を検出したと判断）して、その旨をレスポンス実行部３１に通知すればよい。一方、Ｎ_２－Ｎ_１＜０であれば、全体的に予定送信時間より十分に早いと判断（通信状況が良いことを示す事象を検出したと判断）して、その旨をレスポンス実行部３１に通知すればよい。

　これにより、レスポンス実行部３１は、Ｓ６０２において、全体的に遅延がある場合には、次に送信するメディアセグメントを、低ビットレートのムービーフラグメントで構成することを決定することができ、送信が十分に早い場合には、高ビットレートのムービーフラグメントで構成されるメディアセグメントを送信することを決定することができる。

　≪実施の形態１－２：プロキシによる適応化≫
　次に、ＮＷ１またはＮＷ２の状況に応じて、プロキシ１２がコンテンツ伝送の適応化を行う例について、通信システム１で行われる通信シーケンス例を図７に基づいて説明する。なお、図７の通信シーケンス例は、サーバ１３に接続されたコンテンツ格納部１５に４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの３種類のメディアファイルで構成されるコンテンツが格納されており、プロキシ１２に接続されているキャッシュ格納部１４には、上述のコンテンツの各品質別の冒頭部分「media segment1」が事前の通信においてキャッシュされている状態で開始される通信シーケンス例であり、図中に示した時点でＮＷ１の通信状況の悪化（通信トラフィックの増加）が生じた場合への適応例を示している。

　まずクライアント１１は、予め通知されたＵＲＬを用いて所望のコンテンツの冒頭部分（「media segment1」）を要求する（リクエスト７１）。リクエスト７１を受信したプロキシ１２は、要求されたＵＲＬに紐付けられた「media segment1」がキャッシュ格納部１４に格納されているか確認する。

　ここでは、要求された「media segment1」がキャッシュ格納部１４に格納されているため、プロキシ１２は、サーバ１３へのアクセスを行うことなく、キャッシュ格納部１４から当該メディアセグメントを読み出して、クライアント１１に送信を開始する（レスポンス７２）。

　レスポンス７２を構成する各ムービーフラグメントを順次送信する過程で、ＮＷ１の通信状況が悪化し、プロキシ１２では、応答遅延が発生する。プロキシ１２は、発生した応答遅延を検知して、ＮＷ１の通信状況が悪化したと判断する。

　そして、プロキシ１２は、キャッシュ格納部１４に格納されていた「media segment1」の「X-Representation-List」ヘッダの記載内容に基づき、当該「media segment1」と低品質版（低ビットレート）に相当するＵＲＬ（ここでは２Ｍｂｐｓ）に紐付けられたメディアセグメントがキャッシュ格納部１４に格納されているかを確認する。ここでは、このメディアセグメントがキャッシュ格納部１４に格納されているため、プロキシ１２は、以降のムービーフラグメントを当該メディアセグメント（２Ｍｂｐｓ）で構成してクライアント１１に送信する。なお、プロキシ１２の詳細動作については後述する。

　レスポンス７２を受信したクライアント１１は、続く２番目のメディアセグメント(所定コンテンツの６０秒～１２０秒)のＵＲＬを指定して要求する（リクエスト７４）。

　プロキシ１２は、要求されたＵＲＬに紐付けられた「media segment2」がキャッシュ格納部１４に格納されているか確認する。そして、このメディアセグメントが存在しないことを確認したプロキシ１２は、この時点でＮＷ１の通信状況が悪化したと判断しているため、リクエストＵＲＬに２Ｍｂｐｓの品質種別を示す品質種別識別子を加えてサーバ１３に要求する（リクエスト７４）。

　このリクエスト７４を受信したサーバ１３は、リクエストＵＲＬで示された「media segment2」(２Ｍｂｐｓ)を送信する（レスポンス７５）。

　レスポンス７５を受信したプロキシ１２は、各ムービーフラグメントをキャッシュ格納部１４に格納するとともに、クライアント１１に転送する（レスポンス７６）。
以降同様に、クライアント１１にコンテンツ全体が取得されるまで処理を繰り返す。

　なお、上記では、プロキシ１２が、クライアント１１にレスポンス７２を送信終了した後に、６０秒以降のメディアセグメントのリクエスト７４をサーバ１３に送信する例を示したが、レスポンス７２の送信と並行して、リクエスト７４を送信してもよい。これにより、プロキシ１２が６０秒以降のメディアセグメントを取得するタイミングを早めることができる。

　＜ＨＴＴＰメッセージ＞
　続いて、図７のシーケンス図で使用されるリクエスト及びメッセージの詳細を図８に基づいて説明する。図８は、リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図７のリクエスト７１の、同図（ｂ）はレスポンス７２の、同図（ｃ）はリクエスト７３の、同図（ｄ）はリクエスト７４の、そして同図（ｅ）はレスポンス７５及び７６のＨＴＴＰメッセージをそれぞれ示している。なお、同図（ａ）～（ｃ）（ｅ）は、それぞれ図５（ａ）～（ｄ）と同じであるから、ここでは説明を省略し、図５（ａ）～（ｄ）との相違点を中心に説明する。

　（コンテンツを要求するリクエスト）
　図８（ｄ）に示すように、「media segment2」を要求するリクエスト７４に対応するＨＴＴＰメッセージは、リクエスト対象のメディアセグメントが変わっている点を除けば、同図（ｃ）のＨＴＴＰメッセージ（リクエスト７３）と同様である。

　ここでは、図７で説明したように、プロキシ１２は、品質種別の指定がないリクエスト７３を受信しているが、ＮＷ１を介した応答処理に遅延が生じていると判断したため、サーバ１３への要求転送時にＵＲＬに２Ｍｂｐｓの品質種別指定を追加した、メディアセグメントを要求するリクエスト７４を送信している。
＜プロキシの動作フローチャート＞
　次に、プロキシ１２が実行する処理の詳細を図９に基づいて説明する。図９は、プロキシ１２の実行する処理の一例を示すフローチャートであり、同図（ａ）は処理の全体の流れを示し、同図（ｂ）は同図（ａ）のＳ９０４で行われるリクエスト処理の詳細を示し、同図（ｃ）は同図（ａ）のＳ９０５で行われるレスポンス処理の詳細を示している。

　（処理全体の流れ：図９（ａ））
　プロキシ１２のレスポンス／リクエスト実行部２７は、リクエストの受信を待ち受けており、リクエストの受信を確認する（Ｓ９０１）と、受信したリクエストを解析して、どのようなメディアセグメントで応答するかを決定する（Ｓ９０２）。具体的には、リクエストは図８（ａ）のようなＨＴＴＰメッセージとして受信するので、レスポンス／リクエスト実行部２７は、このメッセージに含まれるＵＲＬから、送信するメディアセグメントのビットレート等の品質種別の初期値を決定する。

　なお、レスポンス／リクエスト実行部２７は、２回目以降のリクエスト受信時には、先に受信したリクエストに対して送信したレスポンスの送信状況に応じて、メディアセグメント（ムービーフラグメント）のビットレート等の品質種別の初期値を決定する。

　具体的には、２回目以降のリクエスト受信時には、プロキシ状況判断部２６は、後述のＳ９０４、９０５で求めるＮ_Ｒ１、Ｎ_Ｒ２、Ｎ_Ｓ１、Ｎ_Ｓ２を用いて遅延の有無を判断する。すなわち、Ｎ_Ｒ２－Ｎ_Ｒ１＞０および／またはＮ_Ｓ２－Ｎ_Ｓ１＞０である場合には、全体的に遅延があると判断（通信状況が悪いことを示す事象を検出したと判断）する。そして、その旨をレスポンス／リクエスト実行部２７に通知する。そして、この通知を受信したレスポンス／リクエスト実行部２７は、メディアセグメントを構成するムービーフラグメントを低ビットレートのものに切り替える。

　一方、Ｎ_Ｒ２－Ｎ_Ｒ１＜０および／またはＮ_Ｓ２－Ｎ_Ｓ１＜０であれば、プロキシ状況判断部２６は、全体的に予定送／受信時間より十分に早いと判断（通信状況が良いことを示す事象を検出したと判断）する。そして、その旨をレスポンス／リクエスト実行部２７に通知する。そして、この通知を受信したレスポンス／リクエスト実行部２７は、メディアセグメントを構成するムービーフラグメントを高ビットレートのものに切り替える。

　続いて、レスポンス／リクエスト実行部２７は、要求されたメディアセグメントがキャッシュ格納部１４に格納されているか確認する（Ｓ９０３）。ここで、格納されていることが確認された場合（Ｓ９０３でＹＥＳ）には、Ｓ９０５に進み、格納されていないことが確認された場合（Ｓ９０３でＮＯ）には、Ｓ９０４に進む。

　Ｓ９０４では、レスポンス／リクエスト実行部２７は、リクエスト処理を実行する。詳細については後述するが、リクエスト処理では、Ｓ９０２で決定したメディアセグメントをサーバ１３に要求し、このリクエストに対するレスポンスとして受信したメディアセグメントをキャッシュ格納部１４に格納する。

　そして、Ｓ９０５では、レスポンス／リクエスト実行部２７は、レスポンス処理を実行する。詳細については後述するが、レスポンス処理では、キャッシュ格納部１４から読み出したメディアセグメントをクライアント１１に送信する。

　最後に、レスポンス／リクエスト実行部２７は、クライアント１１から要求されたコンテンツの全てのメディアセグメントを送信したかを確認する。そして、全て送信済みであることを確認した場合（Ｓ９０６でＹＥＳ）には処理を終了し、未送信のものが確認された場合（Ｓ９０６でＮＯ）には、Ｓ９０１の処理に戻る。

　（リクエスト処理の流れ：図９（ｂ））
　続いて、図９（ａ）のＳ９０４で行われるリクエスト処理の流れを、同図（ｂ）に基づいて説明する。レスポンス／リクエスト実行部２７は、プロキシ通信部２８を介してサーバ１３にリクエストを送信する（Ｓ９０４１）。ここで送信するリクエストは、同図（ａ）のＳ９０２で決定したメディアセグメントを要求するＨＴＴＰメッセージである。

　リクエストを受信したサーバ１３は、Ｓ９０４１で送信したリクエストに対するレスポンスとして、まず、ヘッダを送信するので、レスポンス／リクエスト実行部２７はこれを受信し（Ｓ９０４２）、その旨をプロキシ状況判断部２６に通知する。

　この通知を受信したプロキシ状況判断部２６は、ムービーフラグメントの受信時間を評価するため、タイマを初期化し、時間のカウントを開始させる。また、プロキシ状況判断部２６は、この評価に用いる変数（カウンタ）を初期化（Ｎ_Ｒ１＝Ｎ_Ｒ２＝０）しておく（Ｓ９０４３）。

　サーバ１３は、Ｓ９０４１で送信したリクエストに対するレスポンスとして、ヘッダの後に複数のムービーフラグメントをマルチパート化したボディを送信する。このため、レスポンス／リクエスト実行部２７はこれらのムービーフラグメントを受信し（Ｓ９０４４）、その旨をプロキシ状況判断部２６に通知する。

　ここで、プロキシ状況判断部２６は、サーバ１３からのムービーフラグメントの受信時間の評価を行う（Ｓ９０４５）。具体的には、プロキシ状況判断部は、Ｓ９０４３でカウントを開始したタイマの示す時間ｔと、受信したムービーフラグメントのタイムスタンプＴ_ｆｒ（X-Timestampの値）とを比較する。

　この比較の結果、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には、予定より十分に早く受信完了したと判断し、Ｓ９０４６に進む。これに対し、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には、遅延が生じたと判断し、Ｓ９０４７に進む。一方、上記の何れにも該当しない場合（｜ｔ－Ｔ_ｆｒ｜≦Ｔ_ｔｈの場合）には、Ｓ９０４８に進む。

　Ｓ９０４６では、プロキシ状況判断部２６は、予定受信時間より十分に早くムービーフラグメントを受信した回数のカウンタであるＮ_Ｒ１をインクリメントする。この後、処理はＳ９０４８に進む。

　Ｓ９０４７では、プロキシ状況判断部２６は、ムービーフラグメントを遅延して受信した回数のカウンタであるＮ_Ｒ２をインクリメントする。この後、処理はＳ９０４８に進む。

　Ｓ９０４８では、レスポンス／リクエスト実行部２７は、サーバ１３から受信したムービーフラグメントをキャッシュ格納部１４に格納する。そして、図９（ａ）のＳ９０２で決定したメディアセグメントに含まれる全てのムービーフラグメントを送信したかを確認する（Ｓ９０４９）。そして、全て受信済みであることを確認した場合（Ｓ９０４９でＹＥＳ）にはリクエスト処理を終了し、未受信のものが確認された場合（Ｓ９０４９でＮＯ）には、Ｓ９０４４の処理に戻る。

　（レスポンス処理の流れ：図９（ｃ））
　続いて、図９（ａ）のＳ９０５で行われるリクエスト処理の流れを、同図（ｃ）に基づいて説明する。まず、レスポンス／リクエスト実行部２７は、レスポンスとして送信するＨＴＴＰメッセージを生成し、このＨＴＴＰメッセージのヘッダ部分を、プロキシ通信部２８を介して、リクエストの送信元であるクライアント１１に送信する（Ｓ９０５１）。このＨＴＴＰメッセージは、例えば図８（ｂ）のようなメッセージであってもよい。また、レスポンス／リクエスト実行部２７は、ヘッダ部分を送信した旨をプロキシ状況判断部２６に通知する。

　この通知を受信したプロキシ状況判断部２６は、ムービーフラグメントの送信時間を評価するため、タイマを初期化し、時間のカウントを開始させる。また、プロキシ状況判断部２６は、この評価に用いる変数（カウンタ）を初期化（Ｎ_Ｓ１＝Ｎ_Ｓ２＝０）しておく（Ｓ９０５２）。

　そして、プロキシ状況判断部２６は、受信時間の評価を行う（Ｓ９０５３）。具体的には、プロキシ状況判断部２６は、Ｓ９０５２でカウントを開始したタイマの示す時間ｔと、送信するムービーフラグメントのタイムスタンプＴ_ｆｒ（X-Timestampの値）とを比較する。

　この比較の結果、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には、予定送信時間より十分に早いと判断し、Ｓ９０５４に進む。これに対し、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には、送信に遅延が発生していると判断し、Ｓ９０５５に進む。一方、上記の何れにも該当しない場合（｜ｔ－Ｔ_ｆｒ｜≦Ｔ_ｔｈの場合）には、Ｓ９０５６に進む。

　Ｓ９０５４では、プロキシ状況判断部２６は、予定送信時間より十分に早くムービーフラグメントを送信した回数のカウンタであるＮ_Ｓ１をインクリメントする。なお、この段階で高品質のムービーフラグメントの送信が可能であると判断できるので、キャッシュ格納部１４にキャッシュされていれば、送信するムービーフラグメントを、要求された品質種別指定のビットレートを超えない範囲で高ビットレートのものに切替えてもよい。この後、処理はＳ９０５６に進む。

　Ｓ９０５５では、プロキシ状況判断部２６は、ムービーフラグメントを遅延して送信した回数のカウンタであるＮ_Ｓ２をインクリメントする。なお、この段階で高品質のムービーフラグメントの送信が困難であると判断できるので、キャッシュ格納部１４にキャッシュされていれば、送信するムービーフラグメントを低ビットレートのものに切替えてもよい。この後、処理はＳ９０５６に進む。

　Ｓ９０５６では、レスポンス／リクエスト実行部２７は、図９（ａ）のＳ９０２で決定したムービーフラグメントをマルチパートの１パートとして送信する。そして、レスポンス／リクエスト実行部２７は、図９（ａ）のＳ９０２で決定したメディアセグメント内のすべてのムービーフラグメントを送信したかを確認する（Ｓ９０５７）。そして、全て送信済みであることを確認した場合（Ｓ９０５７でＹＥＳ）にはレスポンス処理を終了し、未送信のものが確認された場合（Ｓ９０５７でＮＯ）には、Ｓ９０５３の処理に戻る。

　≪実施の形態１－３：クライアントによる適応化≫
　次に、ＮＷ１の状況に応じて、クライアント１１がコンテンツ伝送の適応化を行う例について、図１０～１２に基づいて説明する。

　本実施形態において、通信システム１で行われる通信シーケンスを図１０に基づいて説明する。図１０は、クライアント１１がコンテンツ伝送の適応化を行う場合のシーケンスの一例を示す図である。なお、図１０の通信シーケンス例は、サーバ１３と接続されたコンテンツ格納部１５に４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの３種類のメディアファイルで構成されるコンテンツが格納されており、プロキシ１２のキャッシュ格納部１４には、上述のコンテンツの各品質別の冒頭部分「media segment1」が事前の通信においてキャッシュされている状態で開始される通信シーケンス例であり、図中に示した時点でＮＷ１の通信状況の悪化（通信トラフィックの増加）が生じた場合への適応例を示している。

　まず、クライアント１１は、ＵＲＬを指定してコンテンツの冒頭「media segment1」を要求する（リクエスト１０１）。このリクエスト１０１を受信したプロキシ１２は、要求された「media segment1」がキャッシュ格納部１４に格納されているか確認する。

　ここでは、要求されたコンテンツ（メディアセグメント）がキャッシュ格納部１４に格納されている。このため、プロキシ１２は、サーバ１３へのアクセスを行うことなく、キャッシュ格納部１４からそのメディアセグメントを読み出して、MIMEマルチパート形式でクライアント１１に送信する（レスポンス１０２）。

　レスポンス１０２を受信する過程でクライアント１１は、各ムービーフラグメントの受信遅延からＮＷ１の通信状況が悪化したと判断する。そこで、クライアント１１は、続く「media segment2」を要求する際には、前回要求したビットレートよりも低いビットレート（ここでは１Ｍｂｐｓ）をプロキシ１２に要求する（リクエスト１０３）。

　そして、プロキシ１２は、要求された「media segment2」が、キャッシュ格納部１４に格納されているかを確認し、ここでは格納されていないため、その要求をサーバ１３に転送する（リクエスト１０４）。

　このリクエスト１０４を受信したサーバ１３は、要求された「media segment2」、すなわちコンテンツの６０～１２０秒部分の１Ｍｂｐｓ版をMIMEマルチパート形式で送信する（レスポンス１０５）。

　レスポンス１０５を受信したプロキシ１２は、各ムービーフラグメントをキャッシュ格納部１４に順次格納するとともに、クライアント１１にMIMEマルチパート形式で応答する（レスポンス１０６）。以降同様に、クライアント１１にコンテンツ全体が取得されるまで処理を繰り返す。

　＜ＨＴＴＰメッセージ＞
　続いて、図１０のシーケンス図で使用されるリクエスト及びメッセージの詳細を図１１に基づいて説明する。図１１は、リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図１０のリクエスト１０１の、同図（ｂ）はレスポンス１０２の、同図（ｃ）はリクエスト１０３、１０４の、同図（ｄ）はレスポンス１０５、１０６のＨＴＴＰメッセージをそれぞれ示している。なお、同図（ａ）（ｂ）は、それぞれ図５（ａ）（ｂ）と同じであるから、ここでは説明を省略し、図５（ａ）～（ｄ）との相違点を中心に説明する。

　（コンテンツを要求するリクエスト）
　図１１（ｂ）のレスポンス１０２における「X-Representation-List」ヘッダによって、クライアント１１は、「content 1」は、ビットレートが４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの３種類あり、１ＭｂｐｓのコンテンツのテンプレートＵＲＬが「/content1/$index$/3」であることを認識できる。そのため、６０秒以降のコンテンツ「media segment2」を要求する際には、$index$の部分を「２」に置き換えた「/content1/2/3」を用いている。このため、リクエスト１０３、１０４に対応するＨＴＴＰメッセージでは、図１１（ｃ）に示すように、「ＧＥＴ」の後に記述される、リクエスト対象となるコンテンツのＵＲＬが「/content1/2/3」となっている。

　そして、上記リクエスト１０３、１０４に対して送信されるレスポンス１０５、１０６では、図１１（ｄ）に示すように、「X-Representation-Id」ヘッダは「3」と記述されている。

　＜クライアントの動作フローチャート＞
　次に、クライアント１１が実行する処理の詳細を図１２に基づいて説明する。図１２は、クライアント１１の実行する処理の一例を示すフローチャートである。

　クライアント１１のリクエスト実行部２２は、ユーザの入力操作等を契機として、コンテンツのリクエストを送信することを決定すると、まず、要求するコンテンツのメディアセグメントを決定する（Ｓ１２０１）。具体的には、リクエスト実行部２２は図１１（ａ）のようなＨＴＴＰメッセージとして送信するので、リクエスト実行部２２は、このメッセージに含まれるＵＲＬ（コンテンツ名、ビットレート等）を決定する。

　なお、リクエスト実行部２２は、２回目以降のリクエスト送信時には、先に送信したリクエストに対して受信したレスポンスの受信状況に応じて、メディアセグメント（ムービーフラグメント）のビットレート等を決定する。

　具体的には、２回目以降のリクエスト送信時には、クライアント状況判断部２１は、後述のＳ１２０７、１２０８で求めたＮ_１、Ｎ_２を用い、Ｎ_２－Ｎ_１＞０である場合には、全体的に遅延があると判断（通信状況が悪いことを示す事象を検出したと判断）する。そして、その旨をリクエスト実行部２２に通知する。そして、この通知を受信したリクエスト実行部２２は、要求するメディアセグメントを低ビットレートのものに切り替える。

　一方、Ｎ_２－Ｎ_１＜０であれば、クライアント状況判断部２１は、全体的に予定受信時間より十分に早いと判断（通信状況が良いことを示す事象を検出したと判断）し、その旨をリクエスト実行部２２に通知する。そして、この通知を受信したリクエスト実行部２２は、要求するメディアセグメントを高ビットレートのものに切り替える。

　続いて、リクエスト実行部２２は、Ｓ１２０１で決定したメディアセグメントを要求するＨＴＴＰリクエストを、クライアント通信部２４を介してプロキシ１２に送信する（Ｓ１２０２）。プロキシ１２は、このリクエストに対するレスポンスとして、まず、ヘッダを送信するので、リクエスト実行部２２はこれを受信し（Ｓ１２０３）、その旨をクライアント状況判断部２１に通知する。

　この通知を受信したクライアント状況判断部２１は、ムービーフラグメントの受信時間を評価するため、タイマを初期化し、時間のカウントを開始させる。また、クライアント状況判断部２１は、この評価に用いる変数（カウンタ）を初期化（Ｎ_１＝Ｎ_２＝０）しておく（Ｓ１２０４）。

　そして、プロキシ１２は、Ｓ１２０２で送信したリクエストに対するレスポンスとして、ヘッダの後に複数のムービーフラグメントをマルチパート化したボディを送信する。このため、リクエスト実行部２２はこれらのムービーフラグメントを受信し（Ｓ１２０５）、その旨をクライアント状況判断部２１に通知する。

　また、リクエスト実行部２２は、受信したヘッダに含まれる「Content-Type」ヘッダの値から、MIMEマルチパート形式でムービーフラグメントを受信したと判断し、その旨をコンテンツ再生部２３に通知すると共に、受信したムービーフラグメントをコンテンツ再生部２３に送信する。そして、コンテンツ再生部２３は、受信したムービーフラグメントの「X-Representation-Id」ヘッダを参照して、そのムービーフラグメントの品質種別（ビットレート等）を特定し、その品質種別（ビットレート等）に応じた初期化情報を用いて再生を行う。

　ここで、クライアント状況判断部２１は、受信時間の評価を行う（Ｓ１２０６）。具体的には、クライアント状況判断部２１は、Ｓ１２０４でカウントを開始したタイマの示す時間ｔと、Ｓ１２０５で受信したムービーフラグメントのタイムスタンプＴ_ｆｒ（X-Timestampの値）とを比較する。

　この比較の結果、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には、予定受信時間より十分に早いと判断（通信状況が良いことを示す事象を検出したと判断）し、Ｓ１２０７に進む。これに対し、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には、遅延が生じていると判断（通信状況が悪いことを示す事象を検出したと判断）し、Ｓ１２０８に進む。一方、上記の何れにも該当しない場合（｜ｔ－Ｔ_ｆｒ｜≦Ｔ_ｔｈの場合）には、Ｓ１２０９に進む。

　Ｓ１２０７では、クライアント状況判断部２１は、予定受信時間より十分に早くムービーフラグメントを受信した回数のカウンタであるＮ_１をインクリメントする。この後、処理はＳ１２０９に進む。

　Ｓ１２０８では、クライアント状況判断部２１は、ムービーフラグメントを遅延して受信した回数のカウンタであるＮ_２をインクリメントする。この後、処理はＳ１２０９に進む。

　Ｓ１２０９では、リクエスト実行部２２は、Ｓ１２０２で送信したリクエストで指定されるメディアセグメントに含まれる全てのムービーフラグメントを送信したかを確認し、未受信のものが確認された場合（Ｓ１２０９でＮＯ）には、Ｓ１２０５の処理に戻る。

　一方、全て受信済みであることを確認した場合（Ｓ１２０９でＹＥＳ）には、リクエスト実行部２２は、リクエスト対象となっているコンテンツの全てのメディアセグメントを受信したかを確認（Ｓ１２１０）する。そして、全て受信済みであることを確認した場合（Ｓ１２１０でＹＥＳ）には処理を終了し、未受信のものが確認された場合（Ｓ１２１０でＮＯ）には、Ｓ１２０１の処理に戻る。

　なお、上記では、メディアセグメント単位でビットレートの切り替えを行う（Ｓ１２０１）例を示したが、ムービーフラグメント単位でビットレートの切り替えを行ってもよい。この場合には、例えば、Ｓ１２０６で行う受信時間の評価結果に応じて、要求ビットレートを変更（ＵＲＬの品質種別識別子の部分を変更）したリクエストを新たに送信し、先に送信したリクエストに基づいて送信されるムービーフラグメントを破棄してもよい。また、クライアント１１は、ＮＷ１の通信状況だけでなく、ユーザ操作により再生中の表示画面サイズが変更されたなどの理由により、適応化を行う構成であっても構わない。例えば、表示画面サイズが大きく変更されたときに品質の高いものに切り替え、小さく変更されたときに品質の低いものに切り替えてもよい。

　〔クライアントがMIMEマルチパート形式のデータを処理することができない場合〕
　上記実施形態１（１－１～１－３）では、クライアント１１がMIMEマルチパート形式のデータを処理可能な場合について説明した。しかし、特許文献１に示されているような現在広く利用されている従来のクライアントにおいては、MIMEマルチパート形式のデータを処理できない。

　ＮＷ１及びＮＷ２を現在広く利用されているインターネットなどの広域ネットワークとした場合、このような従来のクライアントが本システムのプロキシ１２やサーバ１３に接続する場合も考えられる。

　このような場合に、プロキシ１２やサーバ１３は、リクエストメッセージのAcceptヘッダの値に「multipart/media-segment」が含まれていないことを確認したときには、MIMEマルチパート形式で応答するのではなく、メディアセグメント内のすべてのムービーフラグメントを結合したものを１つのボディとして応答すればよい。これにより、MIMEマルチパート形式のデータを処理できないクライアントが、受信したコンテンツを再生することが可能となる。

　≪実施の形態２：伝送速度を加味した適応制御≫
　上記実施形態では、リアルタイム再生が可能となるように、通信システム１に含まれる各機器が、応答または要求するムービーフラグメント／メディアセグメントを適応的に制御する構成とした。

　これに対し、本実施形態では、リアルタイム再生に限らず、伝送時間に制約のない通常のダウンロードや、早見再生等の特殊再生を目的とした高速ダウンロードなどを行う場合にも、プロキシ１２やサーバ１３が容易に適応制御できる通信システム１について説明する。

　ここで、伝送速度を加味した適応制御を行うためには、コンテンツのビットレートに加えて、伝送ビットレートに関する情報が必要である。本実施形態では、それぞれのビットレートを付加情報として用いるのではなく、それぞれのビットレートの比を付加情報として用いることによってこの適応制御を行う。

　なお、本実施形態の通信システム１の、システム構成（図１）、コンテンツの蓄積及び伝送フォーマット（図２、３）、動作シーケンス（図４）は、実施形態１と同様である。ここでは、実施形態１と同様の構成については同一の参照番号を付し、その説明を省略する。

　＜ＨＴＴＰメッセージ＞
　まず、本実施形態の通信システム１で使用されるリクエスト及びメッセージの詳細を図１３に基づいて説明する。図１３は、リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図４のリクエスト４１、４２の、同図（ｂ）はレスポンス４３、４４の、同図（ｃ）はリクエスト４５、４６の、同図（ｄ）はレスポンス４７、４８のＨＴＴＰメッセージをそれぞれ示している。なお、同図（ｂ）（ｄ）は、それぞれ図５（ｂ）（ｄ）と同じであるから、ここでは説明を省略し、図５（ａ）～（ｄ）との相違点を中心に説明する。

　（コンテンツを要求するリクエスト）
　図１３（ａ）（ｃ）に示すように、コンテンツを要求するリクエスト４１、４２、４５、４６に対応するＨＴＴＰメッセージには、要求伝送速度を示す「X-Transport-Speed」ヘッダ（要求転送速度情報）が含まれている。

　「X-Transport-Speed」の値には、要求する伝送速度として、実時間（＝コンテンツのビットレート）に対する比を記述する。つまり、「X-Transport-Speed」の値は、コンテンツ自身のビットレートに対して、何倍の速度での伝送を要求するかを示す。例えば、４倍速の早見再生等を行うために、高速ダウンロードを要求する場合には、「X-Transport-Speed: 4」となる。逆に、リアルタイム再生の必要がなく、伝送時間に特にこだわらない場合には、「X-Transport-Speed: 0.1」等、１より小さい値に設定してもよい。

　そして、「X-Transport-Speed」ヘッダを含むリクエストを受信したプロキシ１２またはサーバ１３は、要求されたコンテンツのビットレートと、「X-Transport-Speed」ヘッダの値とに基づいてコンテンツを送信する。

　＜動作フローチャート＞
　本実施形態の通信システム１における、サーバ１３、プロキシ１２、及びクライアント１１の動作フローは、基本的に実施形態１（図６、図９、図１２）と同様であるが、ＮＷ１または２の状況を評価するためのタイマのカウント速度を、「X-Transport-Speed」ヘッダの値に応じて変化させる点で異なる。

　すなわち、サーバ１３が適応化する場合、図６のＳ６０４において、タイマのカウント速度を、「X-Transport-Speed」ヘッダの値に応じた速度に設定する。例えば、「X-Transport-Speed」ヘッダの値が４の場合には、タイマを実時間の４倍の速度で動作させ、「X-Transport-Speed」ヘッダの値が０．１の場合には、タイマを実時間の０．１倍の速度で動作させる。

　同様に、プロキシ１２が適応化する場合には、図９（ｂ）のＳ９０４３、図９（ｃ）のＳ９０５２において、タイマのカウント速度を、「X-Transport-Speed」ヘッダの値に応じた速度に設定する。また、クライアント１１が適応化する場合には、図１２のＳ１２０４において、タイマのカウント速度を、「X-Transport-Speed」ヘッダの値に応じた速度に設定する。

　上記のように、リクエストに要求伝送速度情報（X-Transport-Speedヘッダ）を含めることで、プロキシ１２やサーバ１３は、通常ダウンロード、高速ダウンロード等の要求内容を考慮した処理順序の最適化を行うこともできる。

　また、処理順序の最適化に伴う適応制御については、要求伝送速度情報（X-Transport-Speedヘッダ）に基づき、送受信時間の評価に用いるタイマの動作速度を変更するのみでよい。すなわち、特別な処理を追加することなく実施形態１と同様の方法で適応制御を実現することができる。

　また、リアルタイム再生を行う場合には、最初のリクエストだけ要求伝送速度を１より大きな値にしておいてもよい。例えば、リクエスト実行部２２は、送信するメッセージが、要求するコンテンツの先頭部分を含むメディアセグメントに対する要求メッセージであるか否かを、例えばその要求メッセージにおいてメディアセグメントを指定する番号が１であるか否かにより判断する。そして、先頭部分を含むメディアセグメントに対する要求メッセージであると判断した場合に、その要求メッセージの「X-Transport-Speed」ヘッダの値を１より大きくしてもよい。これにより、クライアント１１における再生開始までのバッファリング時間を短縮して、要求から再生開始までの待ち時間を短くすることができる。

　≪実施の形態３：一般的なプロキシを適用≫
　実施形態１及び２におけるプロキシ１２は、従来の一般的なプロキシが行う動作に加えて、クライアント１１から送信されたリクエストにおける要求ビットレートの変更や、クライアント１１へ送信するレスポンスにおけるムービーフラグメントの適応化等の動作が可能である。

　しかしながら、通信システム１に含まれるプロキシ１２は、このような適応化機能を有するものに限られず、従来のプロキシであってもよい。本実施形態では、従来のプロキシを用いつつ、キャッシュ制御を行うことで、ネットワーク状況に適応したなムービーフラグメントの応答を可能した通信システム１について、図１４～１６に基づいて説明する。

　なお、本実施形態の通信システム１の、システム構成、コンテンツの蓄積及び伝送フォーマットは、実施形態１と同様である（図１～３）。ここでは、実施形態１と同様の構成については同一の参照番号を付し、その説明を省略する。ただし、本実施形態のプロキシ１２は、プロキシ状況判断部２６を備えておらず、一般的なプロキシと同様の機能を有するものとする。

　＜通信シーケンス＞
　本実施形態において、通信システム１で行われる通信シーケンスを図１４に基づいて説明する。図１４は、一般的なプロキシを適用した場合に、サーバ１３がＮＷ２の状況等に基づいてコンテンツ伝送の適応化を行うシーケンスの一例を示す図である。なお、図１４の通信シーケンス例は、サーバ１３と接続されたコンテンツ格納部１５に４Ｍｂｐｓ、２Ｍｂｐｓ、１Ｍｂｐｓの３種類のメディアファイルで構成されるコンテンツが格納されており、プロキシ１２と接続されたキャッシュ格納部１４には、サーバ１３から受信したメディアセグメントのキャッシュが存在していない状態で開始される通信シーケンス例である。また、図１４の例では、２つのクライアント１１（クライアントＡとクライアントＢ）が存在している。

　まず、クライアントＡは、ＵＲＬを指定してコンテンツの冒頭部分「media segment1」を要求する（リクエスト１４０１）。そして、このリクエスト１４０１を受信したプロキシ１２は、要求されたＵＲＬに紐付けられた「media segment1」がキャッシュ格納部１４に格納されているか確認する。

　プロキシ１２は、「media segment1」が存在しないことを確認し、リクエスト１４０２をサーバ１３に送信する。リクエスト１４０２を受信したサーバ１３は、「media segment1」をコンテンツ格納部１５から読み出して、MIMEマルチパート形式でプロキシ１２に送信する（レスポンス１４０３）。

　ここで、サーバ１３は、レスポンス１４０３として、４Ｍｂｐｓのムービーフラグメントを用いて送信を開始するが、ＮＷ２の状況を検出し、応答処理に遅延が発生したことを確認したとする。

　このような場合、サーバ１３は、ＮＷ２の状況に適応するため、以降のムービーフラグメントは、より低いビットレートのもの（ここでは１Ｍｂｐｓ）に切り替える。また、サーバ１３は、このとき、送信する「media segment1」のキャッシュ保持期間をＮＷ２の通信状況の回復が見込まれる時間を考慮して指定する。

　レスポンス１４０３を受信したプロキシ１２は、クライアントＡに順次レスポンス１４０３を転送する（レスポンス１４０４）と共に、レスポンス１４０３をキャッシュ格納部１４に格納する。また、プロキシ１２は、上記格納したレスポンス１４０３のキャッシュ保持期間を、サーバ１３から指定された期間に設定する。なお、従来のプロキシでは、MIMEマルチパート形式の各パートを個別には扱わず、レスポンス全体をまとめて取り扱う。

　ここで、上記キャッシュ保持期間経過後、ＮＷ２の通信状況が回復したものとして、以降のシーケンスについて説明を続ける。別のクライアントＢがクライアントＡと同じコンテンツの冒頭部分「media segment1」を要求する（リクエスト１４０５）。

　通常であれば、レスポンス１４０３で受信した「media segment1」がプロキシ１２のキャッシュ格納部１４に格納されている。このため、サーバ１３へのアクセスは行わず、キャッシュ格納部１４に格納されている「media segment1」をクライアントＢに送信する。しかし、ここでは上述のとおり、当該キャッシュには、キャッシュ保持期間が設定されており、すでにキャッシュ保持期間を超過している。このため、要求されたコンテンツがキャッシュに存在しないと判断し、サーバ１３にコンテンツを要求する（リクエスト１４０６）。

　このリクエスト１４０６を受信したサーバ１３は、「media segment1」をコンテンツ格納部１５から読み出して、MIMEマルチパート形式でプロキシ１２に送信する（レスポンス１４０７）。

　ここでサーバ１３は、レスポンス１４０７として４Ｍｂｐｓのムービーフラグメントを用いて、送信を開始する。なお、レスポンス１４０７の送信の際には、ＮＷ２の遅延は検出されなかったため、レスポンス１４０７ではキャッシュ保持期間の設定を行わない。

　レスポンス１４０７を受信したプロキシ１２は、レスポンス１４０７をクライアントＢに転送する（レスポンス１４０８）と共に、キャッシュ格納部１４に格納する。

　＜ＨＴＴＰメッセージ＞
　続いて、図１４のシーケンス図で使用されるリクエスト及びメッセージの詳細を図１５及び図１６に基づいて説明する。図１５は、リクエストまたはレスポンスとして送受信されるＨＴＴＰメッセージの一例を示す図であり、同図（ａ）は図１４のリクエスト１４０１、１４０２、１４０５、１４０６の、同図（ｂ）はレスポンス１４０３、１４０４の、同図（ｃ）はレスポンス１４０７、１４０８のＨＴＴＰメッセージをそれぞれ示している。また、図１６は、レスポンス１４０３の他の例を示している。なお、同図（ａ）（ｃ）は、それぞれ図５（ａ）（ｂ）と同じであるから、ここでは説明を省略し、図５（ａ）～（ｄ）との相違点を中心に説明する。

　（キャッシュ保持期間を指定するレスポンス１）
　図１５（ｂ）に示すように、レスポンス１４０３及びこれをクライアントＡに転送するレスポンス１４０４では、ＨＴＴＰメッセージのボディ部分に、複数のビットレートのムービーフラグメントが含まれている。

　このように、リクエストとは異なる、適応化したレスポンスをプロキシ１２に送信する場合には、一定時間経過後に同じリクエストをプロキシ１２が受信したときには、ＮＷ２の状況が異なっている可能性がある。このため、この適応化したレスポンスがキャッシュ格納部１４から読み出されて送信されないようにする必要がある。そこで、サーバ１３は、適応化したレスポンスの送信時には、キャッシュ保持期間を短く指定している。

　ここで、サーバ１３は、ムービーフラグメント単位で適応化したレスポンスを送信することを、ヘッダ送信開始時に認識できる場合と、そうでない場合がある。

　ヘッダ送信開始時に認識できる場合には、図１５（ｂ）に示すように、キャッシュ保持期間を指定するための制御情報である「Cache-Control」ヘッダによって、キャッシュ保持期間を短く指定することができる。図示の例では、Cache-Controlヘッダの値を「max-age=60」としており、これによりキャッシュ保持期間を６０秒に指定している。無論、次のリクエスト受信時に、ＮＷ２の通信状況の回復が見込める時間であれば、Cache-Controlヘッダの値は、この例に限られず、６０秒以下としてもよいし、６０秒以上としてもよい。なお、Cache-Controlヘッダの値を「no-store」として、キャッシュさせないように設定してもよい。また、以降のリクエストに対して、キャッシュの使用可否（キャッシュされているデータが現在のネットワーク条件を反映したデータか否か）をサーバ１３に再検証するよう指示するための制御情報（Cache-Control: no-cache）をヘッダに記述してもよい。この場合、サーバ１３は、キャッシュ期間の計算などの特別な処理が不要となる。

　また、Cache-Control: no-cacheは、リクエストのヘッダにも記述可能であり、これにより、リクエスト側からの制御でサーバ１３に再検証を行わせることができる。例えば、クライアント１１は、リクエスト１４０５にCache-Control: no-cacheを記述することにより、既にキャッシュされているレスポンス１４０３の使用可否を、サーバ１３に再検証するよう指示することができる。

　一方、サーバ１３が、ムービーフラグメント単位で適応化したレスポンスを送信することを、ヘッダ送信開始時に認識できない場合、ＨＴＴＰにおけるチャンク転送を用い、メッセージの末尾に記述される付加情報であるtrailerにてCache-Controlを記述すればよい。

　具体的には、図１６のようなＨＴＴＰメッセージとしてもよい。同図のＨＴＴＰメッセージのヘッダには、チャンク転送であることを示す「Transfer-Encoding: chunked」、メッセージの末尾に記述される付加情報のリストを示す「Trailer」ヘッダ等が記述されている。ここでは、メッセージの末尾にCache-Controlを記述することを想定しているので、Trailerヘッダの値は「Cache-Control」となっている。

　また、同図のＨＴＴＰメッセージのボディには、複数のチャンクが含まれている。ここでは、１番目のチャンクに、３種のビットレートに対応する３つのムービーフラグメント 1を含むようにし、以降のチャンクには、それぞれ１つのムービーフラグメントを含むようにしている。これにより、ムービーフラグメント1～60にそれぞれ対応する１番目～６０番目のチャンクが形成される。

　さらに、各チャンクには、チャンクサイズを示す情報である「CHUNK_SIZE_N」（Ｎはチャンク番号）が記述されている。なお、「CHUNK_SIZE_N」は、Ｎ番目のチャンクのファイルサイズを１６進数で表したバイト数に置き換えられる。

　そして、メッセージの末尾には、Cache-Controlが記述される。これにより、チャンク転送後に、キャッシュ保持時間を設定することが可能になる。例えば、チャンク転送の結果、ムービーフラグメント単位で適応化された（複数のビットレートのムービーフラグメントが混在している）ことが分かった場合、キャッシュ保持期間を短く設定するか、あるいはキャッシュ保持させないようにする値（Cache-Control: max-age=60、Cache-Control: no-store等）を記述すればよい。

　また、ムービーフラグメントが適応化されていない（全てのムービーフラグメントが要求ビットレート通りである）ことが分かった場合、キャッシュ保持時間を十分長い期間とする値（Cache-Control: max-age=3600）を記述すればよい。この場合には、キャッシュ保持時間が３６００秒、すなわち２時間となる。無論、キャッシュ保持時間は上述の例に限られない。

　＜動作フローチャート＞
　本実施形態のサーバ１３及びクライアント１１の動作は、基本的に実施形態１（図６、１２）と同様である。ただし、チャンク転送を行う場合には、メディアセグメント内の全てのムービーフラグメントを送信した後に、trailer（メッセージ末尾に記述する付加情報。例えば、Cache-Control: max-age=60）を送信するステップが追加される（図１６参照）。

　＜まとめ＞
　上記のように、実施形態３のサーバ１３は、キャッシュ制御を行うことで、プロキシ１２が、既存のものであっても、実施形態１、２で示したような適応化機能を有したものであっても、現在のネットワーク状況を反映した適切なムービーフラグメントの応答をすることを可能としている。

　すなわち、既存プロキシは、サーバ１３の制御により、適応化されていない（すべてのムービーフラグメントが要求ビットレート通りである）メディアセグメントのみを通常通りキャッシュする。一方、適応化された（複数のビットレートのムービーフラグメントが混在している）メディアセグメントは、通常より短い期間キャッシュするかキャッシュしない。これにより、ネットワーク状況の変化に適切に対応することができる。

　例えば、サーバ１３は、あるクライアントから４Ｍｂｐｓのファイルに対するリクエストがあったときに、ネットワークの状況が悪いことを検出した場合には、要求よりも低いビットレート（例えば１Ｍｂｐｓ）のムービーフラグメントを含むメディアセグメントでプロキシ１２に応答する。

　このような場合であっても、プロキシ１２において、キャッシュ保持期間が短く（max-age=60）、またはキャッシュしない（no-store）ように、サーバ１３が制御する。このため、プロキシ１２は、一定時間後にネットワークの状況が回復し、同じＵＲＬを指定するリクエスト（４Ｍｂｐｓのファイルに対するリクエスト）を受信した場合であっても、キャッシュヒットすることがない。

　したがって、プロキシ１２は、サーバ１３にリクエストを送信することになり、サーバ１３の判断により、現在のネットワーク状況に適応したコンテンツが応答されることになる。

　また、プロキシ１２が適応化機能を有したものであれば、ネットワークの状況に応じて、キャッシュ格納部１４に格納されているビットレートの異なる複数のメディアセグメントから、ムービーフラグメントを選択してメディアセグメントを再構成し、適応的にクライアント１１に送信することができる。適応化されていないメディアセグメントについては、サーバ１３のキャッシュ制御の対象外となり、十分な期間だけキャッシュ格納部１４に格納されるからである。

　≪実施形態１、２、３の変形例・応用例≫
　実施形態１、２、３におけるサーバ１３からのレスポンスにおいて、時間を示す情報として、メディアセグメントのタイムスタンプ（X-Media-Segment-Timestampヘッダ）や、各ムービーフラグメントのタイムスタンプ（X-Timestampヘッダ）を記述した。しかし、この例に限られず、これらに加えて、メディアセグメントの再生期間（X-Media-Segment-Durationヘッダ）や、メディアセグメントを構成する各ムービーフラグメントの再生期間（X-Durationヘッダ）を記述してもよい。例えば、図５（ｂ）のレスポンスメッセージの場合、メディアセグメントの再生期間は６００００ミリ秒で、各ムービーフラグメントの再生期間は１０００ミリ秒である。よって、ヘッダに「X-Media-Segment-Duration: 60000」、ボディにおける各パートのヘッダに「X-Duration: 1000」を記述すればよい。これにより、続くムービーフラグメントのタイムスタンプを取得することなく、現ムービーフラグメントの再生期間を取得することができる。

　また、タイムスタンプや再生期間の単位をミリ秒としたが、別途タイムスケール（X-Timescaleヘッダ）を記述し、タイムスケールに基づいてX-TimestampやX-Duration等の値を記述してもよい。例えば、単位を秒とする場合「X-Timescale: 1」、ミリ秒とする場合「X-Timescale: 1000」、マイクロ秒とする場合「X-Timescale: 1000000」などと記述し、「タイムスタンプ＝２秒」を表す場合、それぞれ「X-Timestamp: 2」、「X-Timestamp: 2000」、「X-Timestamp: 2000000」のように記述すればよい。これにより、サーバ１３は、コンテンツの蓄積フォーマットに合ったタイムスケールでタイムスタンプ（X-Timestampヘッダ）や再生期間（X-Durationヘッダ）を記述することができるため、伝送の際の時間単位の変換処理が不要になる。

　実施形態１、２、３におけるクライアントからの最初のリクエストでは、コンテンツの再生位置を示すために「/content1/1」のように、ＵＲＬにメディアセグメント番号を記述する形式を用いたが、メディアセグメント番号の代わりに再生開始位置（再生開始時間）を示すタイムスタンプｔを記述してもよい。例えば、ＵＲＬクエリを用いて、「/content1？t=120.0」のような形式でコンテンツの再生位置を示すようにしてもよい。これにより、タイムスタンプｔで指定した任意の時間位置から再生開始させることが可能である。

　また、上述のように、各ムービーフラグメントには、「X-Timestamp」ヘッダにより、タイムスタンプが記述可能になっている。これを利用することにより、ダウンロード済みのコンテンツをムービーフラグメント単位で更新することもできる。

　例えば、ダウンロードしたコンテンツに品質の低い部分（例えば、「X-Representation-Id」ヘッダの値が3、すなわち１Ｍｂｐｓのムービーフラグメント）が含まれている場合、そのムービーフラグメントのタイムスタンプを用いて、品質の高いものをリクエストすることにより、当該部分を高品質なものに更新することができる。

　なお、このように、特定の品質のコンテンツを取得したい場合には、クライアント１１は、ＵＲＬに所望の品質種別を指定すると共に、実施形態２で説明した要求伝送速度を示す「X-Transport-Speed」ヘッダに小さい値を設定してリクエストを送信してもよい。

　また、上記各実施形態では、ネットワーク（ＮＷ１、２）の通信状況に応じて、送信するムービーフラグメントのビットレートを切り替える例を示したが、ビットレート切り替えの契機となる事象は、通信状況に限られない。この事象は、容量の大きいコンテンツの送信が困難または不要であることを示す事象、または容量の大きいコンテンツの送信が可能または必要であることを示す事象であればよい。

　例えば、コンテンツを要求するクライアント数が、所定の閾値を上回ったことを検出した場合に、送信するコンテンツのビットレートを低いものに切り替えてもよい。同様に所定の閾値を下回ったことを検出した場合に、送信するコンテンツのビットレートを高いものに切り替えてもよい。

　同様に、コンテンツの要求時のビットレート切り替えの契機となる事象も、容量の大きいコンテンツの要求が困難または不要であることを示す事象、または容量の大きいコンテンツの要求が可能または必要であることを示す事象であればよく、通信状況に限られない。

　例えば、要求したコンテンツを全画面表示している場合には、容量の大きいコンテンツの要求が必要と考えられる。そこで、通常画面表示から、全画面表示への切り替えが行われたという事象を検出したときに、要求するビットレートを高いものに切り替えてもよい。同様に、全画面表示から通常画面表示または小画面表示への切り替えが行われたという事象を検出したときに、要求するビットレートを低いものに切り替えてもよい。

　また、上記各実施形態では、ＨＴＴＰメッセージを用いてコンテンツの要求及び送信を行う例を示したが、この例に限られず、コンテンツの要求及び送信に用いられる任意のメッセージが適用可能である。

　そして、上記各実施形態では、ムービーフラグメントで構成されるメディアファイルの例として、ＭＰ４を示したが、送信・要求の対象となるコンテンツは、フラグメント化されたものであり、再生の対象となるもの（音声、動画像等）であればよく、この例に限られない。例えば、ＭＰＥＧ－２トランスポートストリームを用いてもよく、メディアセグメントを構成するムービーフラグメントにＭＰ４とＭＰＥＧ－２トランスポートストリームが混在する構成でも構わない。

　また、上記各実施形態では、コンテンツの再生品質及び種別の例として、ビットレートを適用する例を示したが、画像解像度、音声言語、コーデック種別等、ビットレート以外の再生品質または種別をムービーフラグメント単位で設定可能としてもよい。

　本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

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

　〔発明の作用効果〕
　本発明のコンテンツ取得装置は、要求メッセージに対する応答として、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信手段と、上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生手段とを備えており、上記コンテンツ取得装置は、コンテンツの再生品質を指定する再生品質指定情報を含む要求メッセージを送信する要求メッセージ送信手段を備えていることが好ましい。

　上記の構成によれば、再生品質指定情報を含む要求メッセージを送信するので、上記コンテンツ取得装置のユーザは、この再生品質指定情報で所望の再生品質を指定することにより、所望の再生品質のコンテンツを取得することが可能になる。

　また、上記コンテンツ取得装置は、予め定めた第１事象及び第２事象の少なくとも何れかを検出する事象検出手段を備え、上記要求メッセージ送信手段は、上記事象検出手段が上記第１事象を検出した場合に、その後送信する要求メッセージの再生品質指定情報を、上記第１事象の検出前よりも低い再生品質を指定するものに切り替え、上記事象検出手段が上記第２事象を検出した場合に、その後送信する要求メッセージの再生品質指定情報を、上記第２事象の検出前よりも高い再生品質を指定するものに切り替えることが好ましい。

　上記の構成によれば、第１・第２事象の検出の有無に応じて、その後送信する要求メッセージの再生品質指定情報を切り替える。したがって、第１・第２事象の検出の有無に応じた再生品質のコンテンツを受信することができる。

　このため、第１事象としては、その事象の検出後は、低い再生品質のコンテンツを要求することが適当であるような事象を適用することが望ましい。例えば、コンテンツ要求先の装置と自装置との間の通信状況が不良であることを示す事象（フラグメントの受信が予定受信時間よりも遅延した等）や、再生したコンテンツをユーザに提示する画面（ウィンドウ）が小さいものに切り替えられた事象等を第１事象としてもよい。

　同様に、第２事象としては、その事象の検出後は、高い再生品質のコンテンツを要求することが適当であるような事象を適用することが望ましい。例えば、コンテンツ要求先の装置と自装置との間の通信状況が良好であることを示す事象（フラグメントの受信が予定受信時間よりも早く完了した等）や、再生したコンテンツをユーザに提示する画面（ウィンドウ）が大きいものに切り替えられた（例えば全画面表示に切り替えられた）事象等を第２事象としてもよい。

　また、上記応答受信手段は、上記各フラグメントの再生開始時間を示すタイムスタンプが、各フラグメントに対応付けられた応答メッセージを受信し、上記事象検出手段は、上記応答メッセージに含まれるフラグメントの１つである第１フラグメントの受信開始後、その次に受信するフラグメントである第２フラグメントの受信開始までの時間ｔをカウントし、上記第１フラグメントに対応付けられたタイムスタンプの値と、上記第２フラグメントに対応付けられたタイムスタンプの値との差をＴ_ｆｒとし、予め定めたゼロ以上の閾値をＴ_ｔｈとして、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には上記第１事象を検出したと判断し、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には上記第２事象を検出したと判断することが好ましい。

　ここで、Ｔ_ｆｒ＝ｔとなるときには、再生までの処理で発生するタイムラグ等を無視すれば、第２フラグメントをそのタイムスタンプが示すタイミングで再生開始することができる。つまり、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔとなる場合は、第２フラグメントの受信が、そのタイムスタンプが示すタイミングで再生開始することができないほど遅延していると言える。また、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈとなる場合には、第２フラグメントの受信が十分に早かったと言える。

　そこで、上記の構成によれば、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には上記第１事象が発生したと判断して、その後送信する要求メッセージの再生品質指定情報を、上記第１事象の検出前よりも低い再生品質を指定するものに切り替える。これにより、現在の悪い通信状況を反映させて、以後受信するコンテンツに遅延が発生することを防ぐことができる。

　また、上記の構成によれば、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には上記第２事象が発生したと判断して、その後送信する要求メッセージの再生品質指定情報を、上記第２事象の検出前よりも高い再生品質を指定するものに切り替える。これにより、現在の余裕のある通信状況を反映させて、高品質のコンテンツを取得することができる。

　そして、上記要求メッセージ送信手段は、コンテンツの要求転送速度を、該コンテンツのビットレートに対する倍率で示す要求転送速度情報を含む要求メッセージを送信することが好ましい。

　上記の構成によれば、要求転送速度情報を含む要求メッセージを生成するので、この要求転送速度情報で指定した所望の転送速度でコンテンツを受信することができる。

　また、上記要求転送速度情報は、コンテンツの要求転送速度を該コンテンツの通常転送速度に対する倍率で示したものであるため、コンテンツの送信を要求された装置は、この情報を利用してコンテンツの送信状況を容易に判断することができる。

　つまり、コンテンツの送信を要求された装置は、複数のフラグメントを送信するので、各フラグメントの送信時間間隔から、フラグメントの送信状況（遅延して送信されているか、あるいは十分に早く送信されているか）を判断することができる。そして、この送信時間間隔をカウントするカウンタの速度に、上記要求転送速度情報の示す倍率を乗じることにより、上記コンテンツ取得装置の要求する転送速度がどのようなものであっても、同じ処理でフラグメントの送信状況を判断することができる。

　また、上記要求メッセージ送信手段は、送信する要求メッセージが、要求するコンテンツの先頭部分を含むメディアセグメントに対する要求メッセージであると判断した場合に、上記要求転送速度情報を１より大きい値とすることが好ましい。

　上記の構成によれば、要求するコンテンツの先頭部分を含むメディアセグメントに対する要求メッセージの要求転送速度情報を１より大きい値とする。したがって、要求するコンテンツの先頭部分を含むメディアセグメントをより早く受信することができ、これにより、再生開始までの待ち時間を短くすることができる。

　また、本発明のコンテンツ送信装置は、コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、上記付加情報生成手段が生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成手段とを備えており、上記応答メッセージ生成手段は、複数の再生品質のそれぞれに対応する、該再生品質のコンテンツを再生するための再生情報が、当該再生品質のフラグメントに含まれている応答メッセージを生成することが好ましい。

　ここで、応答メッセージを受信した装置において、該応答メッセージに含まれるフラグメントを再生するためには、そのフラグメントを再生するための再生情報（例えばデコーダの初期化情報等）が必要となる。そして、このような再生情報は、コンテンツの再生品質毎に異なっていることが多い。

　そこで、上記の構成によれば、複数の再生品質のそれぞれに対応する、各再生品質のコンテンツを再生するための再生情報が、その再生品質のフラグメントに含まれている応答メッセージを生成する。

　これにより、この応答メッセージを受信した装置は、再生情報を用いることによりそのフラグメントを再生することができ、また、この後、上記複数の再生品質の何れのコンテンツを受信した場合であっても、これを再生することが可能となる。なお、再生情報は、コンテンツの再生前に必要になるものであるから、各再生品質のコンテンツの先頭部分に対応するフラグメントに付加しておくことがより好ましい。

　また、上記応答メッセージ生成手段は、上記各フラグメントの再生開始時間を示すタイムスタンプが、各フラグメントに対応付けられた応答メッセージを生成することが好ましい。

　上記の構成によれば、各フラグメントの再生開始時間を示すタイムスタンプが、各フラグメントに対応付けられた応答メッセージを生成する。このため、この応答メッセージを受信した装置に、フラグメントを解析することなく、各フラグメントの再生開始時間を特定させることができる。これにより、応答メッセージを受信した装置は、例えば、受信したフラグメントの一部を再生品質の高いものと置換したい場合に、タイムスタンプの値を指定してそのフラグメントを要求することもできる。

　また、上記付加情報生成手段は、上記メディアセグメントの上記コンテンツの全長に対する再生位置を示す情報を、上記付加情報として生成することが好ましい。

　上記の構成によれば、メディアセグメントのコンテンツの全長に対する再生位置を示す情報を付加情報として生成する。このため、この付加情報を含む応答メッセージを受信した装置は、コンテンツの全長及び受信したメディアセグメントがどの再生位置にあたるのかを容易に認識することができる。これにより、応答メッセージを受信した装置は、例えば、コンテンツの全長に対する別の再生位置のフラグメントを要求することもできる。つまり、コンテンツへのランダムアクセスが可能になる。

　また、上記付加情報生成手段は、自装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかを示す情報を、上記付加情報として生成することが好ましい。

　上記の構成によれば、コンテンツ送信装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかを示す情報を、上記付加情報として生成するので、この付加情報を含む応答メッセージを受信した装置は、上記コンテンツ送信装置に対して、どのような再生品質／種別のコンテンツを要求できるかを認識することができる。

　特に、コンテンツの要求元から中継装置を介してコンテンツの要求を受けた場合には、コンテンツ送信装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかを示す情報を送信することにより、コンテンツ送信装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかを中継装置に認識させることができる。これにより、コンテンツ送信装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかに応じた適切な中継処理を中継装置に行わせることができる。

　また、上記コンテンツ送信装置は、予め定めた第３事象及び第４事象の少なくとも何れかを検出する送信時事象検出手段を備え、上記応答メッセージ生成手段は、上記送信時事象検出手段が上記第３事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第３事象の検出前よりも低いものに切り替え、上記送信時事象検出手段が上記第４事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第４事象の検出前よりも高いものに切り替えることが好ましい。

　上記の構成によれば、第３・第４事象の検出の有無に応じて、その後送信する応答メッセージに含めるフラグメントの再生品質を切り替える。したがって、第３・第４事象の検出の有無に応じた再生品質のコンテンツを送信することができる。

　このため、第３事象としては、その事象の検出後は、低い再生品質のコンテンツを送信することが適当であるような事象を適用することが望ましい。例えば、コンテンツ送信先の装置と自装置との間の通信状況が不良であることを示す事象（フラグメントの送信が予定送信時間よりも遅延した等）事象等を第３事象としてもよい。

　同様に、第４事象としては、その事象の検出後は、高い再生品質のコンテンツを送信することが適当であるような事象を適用することが望ましい。例えば、コンテンツ送信先の装置と自装置との間の通信状況が良好であることを示す事象（フラグメントの送信が予定送信時間よりも早く完了した等）等を第４事象としてもよい。

　また、上記コンテンツ送信装置は、送信中のフラグメントに対応付けられたタイムスタンプのを値Ｔ_ｆｒとし、該フラグメントの送信開始からカウントした経過時間をｔとし、予め定めたゼロ以上の閾値をＴ_ｔｈとして、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には第３事象が発生したと判断し、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には第４事象が発生したと判断する送信時事象検出手段を備え、上記応答メッセージ生成手段は、上記送信時事象検出手段が上記第３事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第３事象の検出前よりも低いものに切り替え、上記送信時事象検出手段が上記第４事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第４事象の検出前よりも高いものに切り替えることが好ましい。

　ここで、Ｔ_ｆｒ＝ｔとなった時点で送信完了していない場合、当該送信中のフラグメントが送信相手装置に受信される時点では、すでにそのＴ_ｆｒが示す時刻を経過していることになる。つまり、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔとなる場合は、当該フラグメントの送信が、そのタイムスタンプが示すタイミングで再生開始することができないほど遅延すると判断される。また、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈとなる場合には、当該フラグメントの送信が十分に早いと言える。

　そこで、上記の構成によれば、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には上記第３事象が発生したと判断して、その後送信する応答メッセージに含まれるフラグメントの再生品質を、第３事象の検出前よりも低いものに切り替える。これにより、現在の悪い通信状況を反映させて、以後送信するコンテンツに遅延が発生することを防ぐことができる。

　また、上記の構成によれば、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には上記第４事象が発生したと判断して、その後送信する応答メッセージに含まれるフラグメントの再生品質を、第４事象の検出前よりも高いものに切り替える。これにより、現在の余裕のある通信状況を反映させて、高品質のコンテンツを送信することができる。

　また、上記付加情報生成手段は、自装置が送信するコンテンツをキャッシュ格納部に格納して他の装置に伝送する中継装置に送信する応答メッセージの付加情報として、上記メディアセグメントに含まれる各フラグメントを上記キャッシュ格納部に格納しないように指示する情報、該フラグメントを上記キャッシュ格納部に格納する保持期間を指定する情報、または上記中継装置がこれ以後に受信するコンテンツ要求に対する、上記キャッシュ格納部に格納されているフラグメントの使用可否を自装置に問い合わせるように指示する情報を生成することが好ましい。

　上記の構成によれば、中継装置に送信する応答メッセージの付加情報として、該応答メッセージのメディアセグメントに含まれる各フラグメントをキャッシュ格納部に格納しないように指示する情報、該フラグメントを上記キャッシュ格納部に格納する保持期間を指定する情報、または中継装置がこれ以後に受信するコンテンツ要求に対する、上記キャッシュ格納部に格納されているフラグメントの使用可否を自装置に問い合わせるように指示する情報を生成する。

　このため、この応答メッセージを受信した中継装置は、その応答メッセージのメディアセグメントに含まれる各フラグメントをキャッシュ格納部に格納しないか、指定された保持期間だけ保持するか、あるいはそれ以降のコンテンツ要求があったときにキャッシュ格納部に格納されているフラグメントの使用可否をコンテンツ送信装置に問い合わせる。

　これにより、コンテンツの要求元が、意図しない品質／種別のフラグメントを含むメディアセグメントを中継装置から取得することを防ぐことができる。

　例えば、中継装置がコンテンツ送信装置に、４Ｍｂｐｓの「media segment1」を要求した場合に、コンテンツ送信装置が４Ｍｂｐｓのフラグメントと２Ｍｂｐｓのフラグメントとを含む「media segment1」を送信したとする。そして、次に、中継装置が４Ｍｂｐｓの「media segment1」に対する要求を受信したとする。

　この２回目の要求の対象は、１回目の要求と同じく４Ｍｂｐｓの「media segment1」であるが、１回目の要求を受信したときとは通信状況や要求元が異なっていることも考えられる。このため、２回目の要求に対しては、４Ｍｂｐｓのフラグメントと２Ｍｂｐｓのフラグメントとを含む「media segment1」を送信することが妥当でない場合がある。

　そこで、上記の構成のように、キャッシュ格納部に格納しないように指示する情報を含めることによって、上記のような場合に、複数のビットレートのフラグメントを含むメディアセグメントを送信することを防ぐことができる。また、保持期間を指定する情報によって、保持期間を短く設定することによっても、このようなメディアセグメントの送信を防ぐことができる。そして、キャッシュ格納部に格納されているフラグメントの使用可否をコンテンツ送信装置に問い合わせることを指示する情報を含めることによっても、このようなメディアセグメントの送信を防ぐことができる。

　また、上記応答メッセージ生成手段は、要求されたコンテンツがキャッシュ格納部に格納されている場合、上記コンテンツを上記キャッシュ格納部から取得し、上記コンテンツ送信装置は、要求されたコンテンツが上記キャッシュ格納部に格納されていない場合、該コンテンツを提供可能なコンテンツ提供装置に、該コンテンツの送信を要求する要求メッセージを送信する要求メッセージ送信手段を備えていることが好ましい。

　上記の構成によれば、要求されたコンテンツがキャッシュ格納部に格納されている場合、そのコンテンツをキャッシュ格納部から取得し、要求されたコンテンツがキャッシュ格納部に格納されていない場合、コンテンツ提供装置に要求メッセージを送信する。

　したがって、コンテンツを要求した装置は、要求したコンテンツがキャッシュ格納部に格納されている場合には、コンテンツ提供装置を介することなく、そのコンテンツを取得することができる。また、要求したコンテンツがキャッシュ格納部に格納されていない場合には、コンテンツ送信装置とコンテンツ提供装置とを介することによって、そのコンテンツを取得することができる。

　つまり、上記コンテンツ送信装置は、コンテンツの要求元の装置と、コンテンツ提供装置との中継を行う中継装置として機能する。これにより、コンテンツ提供装置の数に対して、コンテンツの要求元の装置の数が多い場合であっても、各コンテンツの要求元の装置がコンテンツをスムーズに取得することが可能になる。

　また、上記コンテンツ取得装置と、該コンテンツ取得装置の要求に応じてコンテンツを送信する上記コンテンツ送信装置とを含むコンテンツ送受信システムであれば、上記コンテンツ取得装置または上記コンテンツ送信装置と同様の効果を奏する。

　また、本発明のデータ構造は、コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含み、上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断して、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生するものであり、上記応答メッセージは、上記複数のフラグメントをそれぞれ１つのパートとして含む、MIMEマルチパート形式のＨＴＴＰメッセージであることが好ましい。

　上記の構成によれば、ブラウザ等で広く利用されているＨＴＴＰにより、各フラグメントの再生品質及び種別の少なくとも何れかが独立に設定されたメディアセグメントを取り扱うことを可能にすることができる。

　なお、上記コンテンツ取得装置及び上記コンテンツ送信装置は、コンピュータによって実現してもよい。この場合には、コンピュータを上記コンテンツ取得装置及び上記コンテンツ送信装置の各手段として動作させることにより、上記コンテンツ取得装置及び上記コンテンツ送信装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。

　発明の詳細な説明の項においてなされた具体的な実施形態または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する請求の範囲内で、いろいろと変更して実施することができるものである。

　本発明は、通信ネットワークを介したコンテンツの送信または受信を行う装置に利用することができる。

　１　通信システム（コンテンツ送受信システム）
１１　クライアント（コンテンツ取得装置）
１２　プロキシ（コンテンツ取得装置、コンテンツ送信装置）
１３　サーバ（コンテンツ送信装置）
１４　キャッシュ格納部
１５　コンテンツ格納部
２１　クライアント状況判断部（事象検出手段、開始時間特定手段）
２２　リクエスト実行部（応答受信手段、要求メッセージ送信手段）
２３　コンテンツ再生部（再生手段）
２６　プロキシ状況判断部（送信時事象検出手段）
２７　レスポンス／リクエスト実行部（付加情報生成手段、応答メッセージ生成手段、要求メッセージ送信手段）
３０　サーバ状況判断部（送信時事象検出手段）
３１　レスポンス実行部（付加情報生成手段、応答メッセージ生成手段）

Claims

　コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置であって、
　上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信手段と、
　上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生手段とを備えていることを特徴とするコンテンツ取得装置。
　コンテンツの再生品質を指定する再生品質指定情報を含む要求メッセージを送信する要求メッセージ送信手段を備えていることを特徴とする請求項１に記載のコンテンツ取得装置。
　予め定めた第１事象及び第２事象の少なくとも何れかを検出する事象検出手段を備え、
　上記要求メッセージ送信手段は、上記事象検出手段が上記第１事象を検出した場合に、その後送信する要求メッセージの再生品質指定情報を、上記第１事象の検出前よりも低い再生品質を指定するものに切り替え、上記事象検出手段が上記第２事象を検出した場合に、その後送信する要求メッセージの再生品質指定情報を、上記第２事象の検出前よりも高い再生品質を指定するものに切り替えることを特徴とする請求項２に記載のコンテンツ取得装置。
　上記応答受信手段は、上記各フラグメントの再生開始時間を示すタイムスタンプが、各フラグメントに対応付けられた応答メッセージを受信し、
　上記事象検出手段は、上記応答メッセージに含まれるフラグメントの１つである第１フラグメントの受信開始後、その次に受信するフラグメントである第２フラグメントの受信開始までの時間ｔをカウントし、上記第１フラグメントに対応付けられたタイムスタンプの値と、上記第２フラグメントに対応付けられたタイムスタンプの値との差をＴ_ｆｒとし、予め定めたゼロ以上の閾値をＴ_ｔｈとして、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には上記第１事象を検出したと判断し、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には上記第２事象を検出したと判断することを特徴とする請求項３に記載のコンテンツ取得装置。
　上記要求メッセージ送信手段は、コンテンツの要求転送速度を、該コンテンツのビットレートに対する倍率で示す要求転送速度情報を含む要求メッセージを送信することを特徴とする２から４の何れか１項に記載のコンテンツ取得装置。
　上記要求メッセージ送信手段は、送信する要求メッセージが、要求するコンテンツの先頭部分を含むメディアセグメントに対する要求メッセージであると判断した場合に、上記要求転送速度情報を１より大きい値とすることを特徴とする請求項５に記載のコンテンツ取得装置。
　要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置であって、
　上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、
　上記付加情報生成手段が生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成手段とを備えていることを特徴とするコンテンツ送信装置。
　上記応答メッセージ生成手段は、複数の再生品質のそれぞれに対応する、該再生品質のコンテンツを再生するための再生情報が、当該再生品質のフラグメントに含まれている応答メッセージを生成することを特徴とする請求項７に記載のコンテンツ送信装置。
　上記応答メッセージ生成手段は、上記各フラグメントの再生開始時間を示すタイムスタンプが、各フラグメントに対応付けられた応答メッセージを生成することを特徴とする請求項７または８に記載のコンテンツ送信装置。
　上記付加情報生成手段は、上記メディアセグメントの上記コンテンツの全長に対する再生位置を示す情報を、上記付加情報として生成することを特徴とする請求項７から９の何れか１項に記載のコンテンツ送信装置。
　上記付加情報生成手段は、自装置が送信可能なコンテンツの再生品質及び種別の少なくとも何れかを示す情報を、上記付加情報として生成することを特徴とする請求項７から１０の何れか１項に記載のコンテンツ送信装置。
　予め定めた第３事象及び第４事象の少なくとも何れかを検出する送信時事象検出手段を備え、
　上記応答メッセージ生成手段は、上記送信時事象検出手段が上記第３事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第３事象の検出前よりも低いものに切り替え、上記送信時事象検出手段が上記第４事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第４事象の検出前よりも高いものに切り替えることを特徴とする請求項７から１１の何れか１項に記載のコンテンツ送信装置。
　送信中のフラグメントに対応付けられたタイムスタンプのを値Ｔ_ｆｒとし、該フラグメントの送信開始からカウントした経過時間をｔとし、予め定めたゼロ以上の閾値をＴ_ｔｈとして、Ｔ_ｆｒ＋Ｔ_ｔｈ＞ｔであった場合には第３事象が発生したと判断し、ｔ＜Ｔ_ｆｒ－Ｔ_ｔｈであった場合には第４事象が発生したと判断する送信時事象検出手段を備え、
　上記応答メッセージ生成手段は、上記送信時事象検出手段が上記第３事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第３事象の検出前よりも低いものに切り替え、上記送信時事象検出手段が上記第４事象を検出した場合に、その後送信する応答メッセージに含まれる上記フラグメントの再生品質を、上記第４事象の検出前よりも高いものに切り替えることを特徴とする請求項９に記載のコンテンツ送信装置。
　上記付加情報生成手段は、自装置が送信するコンテンツをキャッシュ格納部に格納して他の装置に伝送する中継装置に送信する応答メッセージの付加情報として、上記メディアセグメントに含まれる各フラグメントを上記キャッシュ格納部に格納しないように指示する情報、該フラグメントを上記キャッシュ格納部に格納する保持期間を指定する情報、または上記中継装置がこれ以後に受信するコンテンツ要求に対する、上記キャッシュ格納部に格納されているフラグメントの使用可否を自装置に問い合わせるように指示する情報を生成することを特徴とする請求項７から１３の何れか１項に記載のコンテンツ送信装置。
　上記応答メッセージ生成手段は、要求されたコンテンツがキャッシュ格納部に格納されている場合、上記コンテンツを上記キャッシュ格納部から取得し、
　要求されたコンテンツが上記キャッシュ格納部に格納されていない場合、該コンテンツを提供可能なコンテンツ提供装置に、該コンテンツの送信を要求する要求メッセージを送信する要求メッセージ送信手段を備えていることを特徴とする請求項７から１４の何れか１項に記載のコンテンツ送信装置。
　請求項１から６の何れか１項に記載のコンテンツ取得装置と、該コンテンツ取得装置の要求に応じてコンテンツを送信する、請求項７から１５の何れか１項に記載のコンテンツ送信装置とを含むコンテンツ送受信システム。
　コンテンツ取得装置から要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置が生成する応答メッセージのデータ構造であって、
　上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、
　再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、
　各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含み、
　上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断して、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生することを特徴とするデータ構造。
　上記応答メッセージは、上記複数のフラグメントをそれぞれ１つのパートとして含む、MIMEマルチパート形式のＨＴＴＰメッセージであることを特徴とする請求項１７に記載のデータ構造。
　コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置の制御方法であって、
　上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを受信する応答受信ステップと、
　上記応答受信ステップで受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、複数の上記フラグメントを、上記品質／種別情報を参照しながら再生する再生ステップとを含むことを特徴とするコンテンツ取得装置の制御方法。
　要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置の制御方法であって、
　上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成ステップと、
　上記付加情報生成ステップで生成した付加情報と、再生品質及び種別の少なくとも何れかが独立に設定された複数のフラグメントと、各フラグメントの再生品質及び種別の少なくとも何れかを示す品質／種別情報とを含む応答メッセージを生成する応答メッセージ生成ステップとを含むことを特徴とするコンテンツ送信装置の制御方法。
　請求項１から６の何れか１項に記載のコンテンツ取得装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
　請求項７から１５の何れか１項に記載のコンテンツ送信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
　請求項２１または２２に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
　コンテンツの送信を要求する要求メッセージを送信してコンテンツを取得するコンテンツ取得装置であって、
　上記要求メッセージに対する応答として、上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを受信する応答受信手段と、
　上記応答受信手段が受信した上記送信形式情報から、上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照して、上記各フラグメントの再生開始時間を特定する開始時間特定手段とを備えていることを特徴とするコンテンツ取得装置。
　要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置であって、
　上記コンテンツを、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報を上記付加情報として生成する付加情報生成手段と、
　上記付加情報生成手段が生成した付加情報と、複数の上記フラグメントとを含み、該複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられた応答メッセージを生成する応答メッセージ生成手段とを備えていることを特徴とするコンテンツ送信装置。
　コンテンツ取得装置から要求されたコンテンツを、該コンテンツと、該コンテンツに関する付加情報とを含む応答メッセージで送信するコンテンツ送信装置が生成する応答メッセージのデータ構造であって、
　上記コンテンツの一部または全部を、該コンテンツを構成する複数のフラグメントの少なくとも２つを含むメディアセグメントとして送信することを示す送信形式情報と、複数の上記フラグメントとを含み、
　上記複数のフラグメントのそれぞれに、該フラグメントの再生開始時間を示すタイムスタンプが対応付けられており、
　上記応答メッセージを受信した上記コンテンツ取得装置が、上記送信形式情報から上記コンテンツをメディアセグメントとして受信したと判断した場合に、上記タイムスタンプを参照して、上記各フラグメントの再生開始時間を特定することを特徴とするデータ構造。