(57)【要約】  サーバ（１）のコンテンツ送信部（２２）は、クライアント（２）からのリクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスをクライアント（２）に送信する。これにより、遅延を抑制して高品質な低遅延ライブストリーミングを実行することが可能になる。
2014010445.tif 000002
【特許請求の範囲】
【請求項１】
複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ再生装置に送信するコンテンツ送信装置であって、
上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、
上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信することを特徴とするコンテンツ送信装置。
【請求項２】
上記送信手段は、セグメントが配信可能な状態であるか否かを、上記コンテンツに対応付けられたコンテンツ管理情報に基づいて判断することを特徴とする請求項１に記載のコンテンツ送信装置。
【請求項３】
上記送信手段は、セグメントが配信可能な状態であるか否かを、上記リクエストに付加されたセグメントの配信時刻に基づいて判断することを特徴とする請求項１に記載のコンテンツ送信装置。
【請求項４】
上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合であって、上記リクエストを受信してからセグメントが配信可能な状態になるまで、所定時間以上かかる場合、上記コンテンツ再生装置に処理中であることを示すステータスを通知することを特徴とする請求項１〜３の何れか１項に記載のコンテンツ送信装置。
【請求項５】
複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、
上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得手段を備え、
上記取得手段は、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信することを特徴とするコンテンツ再生装置。
【請求項６】
上記取得手段は、再生順序が前のセグメントの送信を要求するリクエストに対するレスポンスの取得が完了する前に、再生順序が後のセグメントの送信を要求するリクエストを送信することを特徴とする請求項５に記載のコンテンツ再生装置。
【請求項７】
上記取得手段は、セグメントの送信を要求する複数のリクエストをパイプライン化して送信することを特徴とする請求項６に記載のコンテンツ再生装置。
【請求項８】
上記取得手段は、上記リクエストにセグメントの配信時刻を付加して送信することを特徴とする請求項５〜７の何れか１項に記載のコンテンツ再生装置。
【請求項９】
請求項１〜４の何れか１項に記載のコンテンツ送信装置と、
請求項５〜８の何れか１項に記載のコンテンツ再生装置とを含むことを特徴とするコンテンツ配信システム。
【請求項１０】
コンテンツ再生装置とコンテンツ送信装置との間に介在する中継装置であって、
コンテンツ再生装置から送信されたリクエストをコンテンツ送信装置に転送すると共に、当該リクエストに対する応答として、上記コンテンツ送信装置から送信されたレスポンスを上記コンテンツ再生装置に転送する転送手段を備え、
コンテンツは、複数のセグメントから構成されるものであり、
上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該リクエストを上記コンテンツ送信装置に送信することを特徴とする中継装置。
【請求項１１】
上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合であって、上記リクエストを受信してから上記セグメントを含むレスポンスを上記コンテンツ送信装置から取得するまで、所定時間以上かかる場合、上記コンテンツ再生装置に処理中であることを示すステータスを通知することを特徴とする請求項１０に記載の中継装置。
【請求項１２】
上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合であって、上記リクエストにセグメントの配信時刻が付加されている場合、セグメントの配信時刻以降に、上記リクエストを上記コンテンツ送信装置に送信することを特徴とする請求項１０または１１に記載の中継装置。
【請求項１３】
複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、
上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、
上記送信ステップでは、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信することを特徴とするコンテンツ送信装置の制御方法。
【請求項１４】
複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、
上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得ステップを含み、
上記取得ステップでは、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信することを特徴とするコンテンツ再生装置の制御方法。
【請求項１５】
コンテンツ再生装置がコンテンツ送信装置から取得する複数のセグメントから構成されたコンテンツに対応付けられたコンテンツ管理情報のデータ構造であって、
プリフェッチの可否を示すプリフェッチ可否フラグを含むことを特徴とするコンテンツ管理情報のデータ構造。
【請求項１６】
コンテンツ再生装置がコンテンツ送信装置に対してコンテンツを構成する各セグメントの送信を要求するリクエストのデータ構造であって、
上記リクエストのヘッダに、セグメントの配信時刻を示すセグメント配信時刻情報を含むことを特徴とするリクエストのデータ構造。
【請求項１７】
請求項１〜４の何れか１項に記載のコンテンツ送信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１８】
請求項５〜８の何れか１項に記載のコンテンツ再生装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１９】
請求項１７および１８の少なくとも１項に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを送信するコンテンツ送信装置、コンテンツを取得・再生するコンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、データ構造、制御プログラムおよび記録媒体に関するものである。
【背景技術】
【０００２】
インターネットの普及やコンピュータの高性能化に伴い、インターネットを介して動画像などの大容量コンテンツを配信することが広く行われている。例えば、ユーザの要求に応じて動画等のコンテンツを提供するＶＯＤ（Video On Demand）というサービスがある。ＶＯＤでは、例えば、特許文献１に記載されているように、ＨＴＴＰ（HyperText Transfer Protocol）を用いて、サーバ（コンテンツ提供装置）とクライアント（コンテンツ再生装置）との間でデータを送受信する。【０００３】
ここで、ＨＴＴＰによるコンテンツの配信に関して、様々な技術が開発されている。例えば、ＭＰＥＧ（Motion Picture Experts Group）は、ＨＴＴＰを利用した適応ストリーミング技術をＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規格として国際標準化を進めている。【０００４】
ＭＰＥＧ−ＤＡＳＨでは、コンテンツは、複数のセグメント（segment）に時分割され、セグメント単位で伝送される。また、各セグメントは、１または複数のフラグメント（fragment）で構成される。また、コンテンツは、１または複数のピリオド（period）で構成されており、１つのピリオドに１または複数のセグメントが含まれる。【０００５】
また、ＭＰＥＧ−ＤＡＳＨでは、１つのコンテンツに対して品質種別（ビットレート、画像解像度等の再生品質や、データフォーマット等の種別）が異なる複数のRepresentationが準備される。例えば、セグメント毎に異なるビットレートで符号化した複数のセグメントデータを準備する。これにより、コンテンツを受信して再生するクライアントは、コンテンツの受信状況等に応じて、要求するコンテンツ（セグメント）のビットレートを変えることにより、適応ストリーミングを実行することができる。【０００６】
ＭＰＥＧ−ＤＡＳＨでは、ライブストリーミングに対応しており、セグメントの長さを小さくすることで低遅延ライブストリーミングに対応することを想定している。サーバおよびクライアントによる処理遅延やネットワーク上の遅延等が発生するため、クライアントが厳密にリアルタイムに再生することは不可能である。そのため、わずかに遅延しているが、実質的にリアルタイムでのライブストリーミングを低遅延ライブストリーミングと称する。【０００７】
また、ＭＰＥＧ−ＤＡＳＨでは、コンテンツにＭＰＤ（Media Presentation Description）が対応付けられており、ＭＰＤによってコンテンツを管理する。ＭＰＤは、コンテンツのメタデータであって、コンテンツの管理情報をＸＭＬ形式で記述したものである。換言すると、ＭＰＤは、クライアントがコンテンツの取得・再生時に利用する情報である。【０００８】
ＭＰＤの具体的な記述例を図１７に基づいて説明する。図１７は、ＭＰＤの記述例を示す図である。図１７に示すように、ＭＰＤ２００には、タイプ情報２１１、プロファイル情報２１２、バッファリング時間情報２１３、ＭＰＤ更新間隔情報２１４、配信開始時刻情報２１５を含む情報２１０が記述されている。【０００９】
タイプ情報２１１は、ライブ配信であるかオンデマンド配信であるかを示す情報（属性「type」の属性値）である。図示の例では、属性「type」の属性値が「dynamic」であり、このＭＰＤ２００が対応付けられたコンテンツがライブ配信コンテンツであることを示す。一方、オンデマンド配信の場合、属性「type」の属性値に「static」が記述される。【００１０】
プロファイル情報２１２は、コンテンツのプロファイルを示す情報である。また、バッファリング時間情報２１３は、最小のバッファリング時間を示す情報である。図示の例では、属性「minBufferTime」の属性値が「PT10S」であるため、クライアントは少なくとも１０秒のバッファリングを行うことを示す。【００１１】
ＭＰＤ更新間隔情報２１４は、クライアントがサーバに対して当該ＭＰＤ２００の更新の有無を確認する最小の間隔を示す情報である。図示の例では、属性「minimumUpdateperiod」の属性値が「PT60S」であるため、クライアントは少なくとも６０秒毎にＭＰＤの更新の有無を確認することを示す。【００１２】
配信開始時刻情報２１５は、サーバがコンテンツのライブストリーミング配信を開始する時刻を示す情報（属性「availabilityStartTime」の属性値）である。図示の例では、属性「availabilityStartTime」の属性値が「2012-07-01T18:00:00」であり、２０１２年７月１日１８時にライブストリーミング配信が開始されることを示す。【００１３】
また、ＭＰＤ２００には、コンテンツの取得先を示す取得先情報２２０が記述されている。図示の例では、取得先情報２２０として、サーバのＵＲＬが記述されている。【００１４】
また、コンテンツの再生期間を区切った各ピリオドに関するピリオド情報２３０が記述されている。図示の例では、ピリオド情報２３０として、コンテンツの配信開始時刻を基準とした場合のそのピリオドの開始時刻（属性「start」の属性値）およびそのピリオドの期間（属性「duration」の属性値）が記述されている。【００１５】
また、ここでは、コンテンツとして、ビットレートが1024kbpsの高品質Representationと、ビットレートが512kbpsの低品質Representationが用意されているものとする。そのため、ＭＰＤ２００には、或るピリオド（再生時刻０秒から６０秒まで）に含まれるセグメントとして、高品質セグメントを示す高品質セグメント情報２４１と、低品質セグメントを示す低品質セグメント情報２４２とが記述されている。高品質セグメント情報２４１には、当該ピリオドに含まれる高品質RepresentationのＩＤおよびビットレートが記述されている。また、当該ピリオドに含まれる各セグメントの長さおよびＵＲＬが記述されている。また、低品質セグメント情報２４２も同様である。なお、当該ピリオドは、セグメント＃１〜セグメント＃６０の６０個のセグメントで構成されている。【００１６】
次に、ライブストリーミングを実行するサーバおよびクライアントの動作シーケンスおよびライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図１８および図１９に基づいて説明する。図１８は、ライブストリーミングを実行するサーバおよびクライアントの動作シーケンスの一例を示す図である。また、図１９は、ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。【００１７】
ここで、セグメント＃ｉが配信可能となる時刻をｔ（ｉ）とする。なお、セグメント＃ｉの配信時刻ｔ（ｉ）は、ＭＰＤ２００の配信開始時刻情報２１５の示すコンテンツ配信開始時刻および各セグメントの長さに基づいて算出される。【００１８】
図１８および図１９に示すように、まず、クライアントは、ＭＰＤ２００を参照して、時刻ｔ（ｎ）にセグメント＃ｎの送信を要求するためのリクエストメッセージ３０１をサーバに送信する。セグメント＃ｎの配信時刻ｔ（ｎ）以降であるため、サーバは、リクエストメッセージ３０１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ３０２をクライアントに送信し、クライアントはセグメント＃ｎを受信する。【００１９】
クライアントは、セグメント＃ｎを受信した後、時刻ｔ（ｎ＋１）になると、次のセグメント＃ｎ＋１の送信を要求するためのリクエストメッセージ３０３をサーバに送信する。ここでも、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）以降であるため、サーバは、リクエストメッセージ３０３の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ３０４をクライアントに送信し、クライアントはセグメント＃ｎ＋１を受信する。【００２０】
クライアントは、続いて、同様にセグメント＃ｎ＋２、セグメント＃ｎ＋３を取得する。ここで、図１８に示すように、クライアントが各セグメントのリクエストを送信してからセグメントのデータ本体を受信するまでにdelayが発生する。また、このdelayには、揺らぎがある。そのため、セグメントの長さを小さくする場合、安定的に低遅延ライブストリーミングを実行することが困難になる。【００２１】
一般的に、delayの揺らぎの影響を小さくするために、プリフェッチが行われる。そこで、プリフェッチを適用した場合のサーバおよびクライアントの動作シーケンスおよびＨＴＴＰメッセージについて図２０および図２１に基づいて説明する。図２０は、プリフェッチを適用した場合のサーバおよびクライアントの動作シーケンスの一例を示す図である。また、図２１は、プリフェッチを適用した場合のＨＴＴＰメッセージの一例を示す図である。【００２２】
図２０および図２１に示すように、まず、クライアントは、ＭＰＤ２００を参照して、時刻ｔ（ｎ）にセグメント＃ｎの送信を要求するためのリクエストメッセージ３１１をサーバに送信する。セグメント＃ｎの配信時刻ｔ（ｎ）以降であるため、サーバは、リクエストメッセージ３１１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ３１２をクライアントに送信し、クライアントはセグメント＃ｎを受信する。【００２３】
ここで、クライアントは、プリフェッチを行い、セグメント＃ｎを受信した直後に、次のセグメント＃ｎ＋１の送信を要求するためのリクエストメッセージ３１３をサーバに送信する。しかしながら、サーバがリクエストメッセージ３１３を受信した時点は、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）前であるため、サーバは、リクエストメッセージ３１３の応答として、応答エラー（サーバにリソースが存在しない、または、セグメントデータが配信可能な状態ではない）を示すレスポンスメッセージ３１４をクライアントに送信する。【００２４】
クライアントは、応答エラーを受信すると、再度、セグメント＃ｎ＋１の送信を要求するためのリクエストメッセージ３１５をサーバに送信する。このときは、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）以降であるため、サーバは、リクエストメッセージ３１５の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ３１６をクライアントに送信し、クライアントはセグメント＃ｎ＋１を受信する。【００２５】
クライアントは、セグメント＃ｎ＋１を受信すると、直ぐに、次のセグメント＃ｎ＋２の送信を要求するためのリクエストメッセージ３１７をサーバに送信する。サーバがリクエストメッセージ３１７を受信した時点は、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）以降であるため、サーバは、リクエストメッセージ３１７の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ３１８をクライアントに送信し、クライアントはセグメント＃ｎ＋２を受信する。【００２６】
そして、クライアントは、セグメント＃ｎ＋２を受信すると、直ぐに、次のセグメント＃ｎ＋３の送信を要求するためのリクエストメッセージ３１９をサーバに送信する。しかしながら、ここでも、サーバがリクエストメッセージ３１９を受信した時点は、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）前であるため、サーバは、リクエストメッセージ３１９の応答として、応答エラーを示すレスポンスメッセージ３２０をクライアントに送信する。【００２７】
クライアントは、応答エラーを受信すると、再度、セグメント＃ｎ＋３の送信を要求するためのリクエストメッセージ３２１をサーバに送信する。このときは、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）以降であるため、サーバは、リクエストメッセージ３２１の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ３２２をクライアントに送信し、クライアントはセグメント＃ｎ＋３を受信する。【００２８】
このように、ＭＰＥＧ−ＤＡＳＨにおけるライブストリーミングでは、プリフェッチを行っても、セグメントの配信時刻前にリクエストした場合、エラーが返信されるため、delayの問題は解消されない。それどころか、応答エラーの受信処理、再リクエストの送信処理等により、遅延量が増加する場合もある。
【先行技術文献】
【特許文献】
【００２９】
【特許文献１】特開２００５−１１０２４４号公報（２００５年４月２１日公開）
【非特許文献】
【００３０】
【非特許文献１】“ISO/IEC 23009-1”、[online]、２０１２年４月１日、ISO/IEC、[平成２４年６月１９日検索]、インターネット＜ＵＲＬ：http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip＞
【発明の概要】
【発明が解決しようとする課題】
【００３１】
ＭＰＥＧ−ＤＡＳＨにおけるライブストリーミングにおいて、ＨＴＴＰのリクエストパイプラインを用いてセグメントのリクエストを送信することを考える。リクエストパイプラインを適用した場合のサーバおよびクライアントの動作シーケンスおよびＨＴＴＰメッセージについて図２２および図２３に基づいて説明する。図２２は、リクエストパイプラインを適用した場合のサーバおよびクライアントの動作シーケンスの一例を示す図である。また、図２３は、リクエストパイプラインを適用した場合のＨＴＴＰメッセージの一例を示す図である。【００３２】
図２２および図２３に示すように、まず、クライアントは、ＭＰＤ２００を参照して、時刻ｔ（ｎ）にセグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ３３１〜３３４をパイプライン化してサーバに送信する。【００３３】
サーバは、リクエストメッセージ３３１〜３３４を受信し、順次処理を行う。まず、リクエストメッセージ３３１に対して、セグメント＃ｎの配信時刻ｔ（ｎ）以降であるため、サーバは、リクエストメッセージ３３１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ３３５をクライアントに送信する。次に、リクエストメッセージ３３２に対して、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）前であるため、サーバは、リクエストメッセージ３３２の応答として、応答エラーを示すレスポンスメッセージ３３６をクライアントに送信する。そして、リクエストメッセージ３３３に対して、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）前であるため、サーバは、リクエストメッセージ３３３の応答として、応答エラーを示すレスポンスメッセージ３３７をクライアントに送信する。最後に、リクエストメッセージ３３４に対して、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）前であるため、サーバは、リクエストメッセージ３３４の応答として、応答エラーを示すレスポンスメッセージ３３８をクライアントに送信する。【００３４】
このように、プリフェッチの場合と同様に、リクエストパイプラインを行っても、セグメントの配信時刻前にリクエストした場合、エラーが返信されるため、delayの問題は解消されない。それどころか、応答エラーの受信処理、再リクエストの送信処理等により、遅延量が増加する場合もある。【００３５】
すなわち、ＭＰＥＧ−ＤＡＳＨにおけるライブストリーミングでは、従来技術を単純に適用しても、delayの問題を解消することができない。【００３６】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、遅延を抑制して高品質な低遅延ライブストリーミングを実行するコンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、データ構造、制御プログラムおよび記録媒体を実現することにある。
【課題を解決するための手段】
【００３７】
本発明に係るコンテンツ送信装置は、上記課題を解決するために、複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信することを特徴としている。【００３８】
また、本発明に係るコンテンツ送信装置の制御方法は、上記課題を解決するために、複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップでは、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信することを特徴としている。【００３９】
上記の構成によれば、上記送信手段は、セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信する。そのため、セグメントが配信可能な状態になる前に、当該セグメントの送信を要求するリクエストを受信した場合であっても、応答エラーを示すレスポンスを送信することがない。さらに、コンテンツ再生装置が再度リクエスト送信することも要しない。よって、遅延を抑制し高品質な低遅延ライブストリーミングを実行することができるという効果を奏する。【００４０】
また、本発明に係るコンテンツ送信装置は、上記送信手段は、セグメントが配信可能な状態であるか否かを、上記コンテンツに対応付けられたコンテンツ管理情報に基づいて判断することが好ましい。【００４１】
また、本発明に係るコンテンツ送信装置は、上記送信手段は、セグメントが配信可能な状態であるか否かを、上記リクエストに付加されたセグメントの配信時刻に基づいて判断することが好ましい。【００４２】
また、本発明に係るコンテンツ送信装置は、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合であって、上記リクエストを受信してからセグメントが配信可能な状態になるまで、所定時間以上かかる場合、上記コンテンツ再生装置に処理中であることを示すステータスを通知することが好ましい。【００４３】
例えば、コンテンツ再生装置がリクエストを送信してから所定時間以内にレスポンスを受信しない場合、タイムアウトするとする。この場合でも、上記構成のように、上記送信手段は、上記リクエストを受信してからセグメントが配信可能な状態になるまで、所定時間以上かかる場合、上記コンテンツ再生装置に処理中であることを示すステータスを通知するため、タイムアウトを防ぐことができる。【００４４】
また、本発明に係るコンテンツ再生装置は、上記課題を解決するために、複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得手段を備え、上記取得手段は、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信することを特徴としている。【００４５】
また、本発明に係るコンテンツ再生装置の制御方法は、上記課題を解決するために、複数のセグメントから構成されるコンテンツをセグメント毎にコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得ステップを含み、上記取得ステップでは、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信することを特徴としている。【００４６】
上記の構成によれば、上記取得手段は、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信する。そのため、コンテンツ送信装置がセグメントの配信時刻前に来たリクエストに対して、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信する場合、コンテンツ送信装置は、セグメントが配信可能な状態になるとレスポンスの送信処理を行うため、コンテンツ再生装置がセグメントを取得する際の遅延を抑制することができる。よって、遅延を抑制し高品質な低遅延ライブストリーミングを実行することができるという効果を奏する。【００４７】
また、本発明に係るコンテンツ再生装置は、上記取得手段は、再生順序が前のセグメントの送信を要求するリクエストに対するレスポンスの取得が完了する前に、再生順序が後のセグメントの送信を要求するリクエストを送信することが好ましい。【００４８】
上記の構成によれば、セグメント長の小さい連続したセグメントを取得する場合であっても、遅延の揺らぎの影響を小さくすることができるため、より安定的に低遅延ライブストリーミングを実行することができる。【００４９】
また、本発明に係るコンテンツ再生装置は、上記取得手段は、セグメントの送信を要求する複数のリクエストをパイプライン化して送信することが好ましい。【００５０】
また、本発明に係るコンテンツ再生装置は、上記取得手段は、上記リクエストにセグメントの配信時刻を付加して送信することが好ましい。【００５１】
上記の構成によれば、コンテンツ再生装置がコンテンツ送信装置にセグメントの配信時刻を通知し、コンテンツ送信装置が通知された配信時刻に基づいてセグメントが配信可能な状態であるか否かを判断する。よって、コンテンツ再生装置は、コンテンツ送信装置のセグメントの送信タイミングを制御することができる。【００５２】
また、本発明に係るコンテンツ配信システムは、上記コンテンツ送信装置と、上記コンテンツ再生装置とを含むことが好ましい。【００５３】
上記の構成によれば、コンテンツ配信システムは、上記コンテンツ送信装置および上記コンテンツ再生装置と同様の効果を奏する。【００５４】
また、本発明に係る中継装置は、上記課題を解決するために、コンテンツ再生装置とコンテンツ送信装置との間に介在する中継装置であって、コンテンツ再生装置から送信されたリクエストをコンテンツ送信装置に転送すると共に、当該リクエストに対する応答として、上記コンテンツ送信装置から送信されたレスポンスを上記コンテンツ再生装置に転送する転送手段を備え、コンテンツは、複数のセグメントから構成されるものであり、上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該リクエストを上記コンテンツ送信装置に送信することを特徴としている。【００５５】
また、本発明に係る中継装置は、上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合であって、上記リクエストを受信してから上記セグメントを含むレスポンスを上記コンテンツ送信装置から取得するまで、所定時間以上かかる場合、上記コンテンツ再生装置に処理中であることを示すステータスを通知することが好ましい。【００５６】
また、本発明に係る中継装置は、上記転送手段は、上記コンテンツ再生装置から送信されたリクエストがセグメントの送信を要求するものである場合であって、上記リクエストにセグメントの配信時刻が付加されている場合、セグメントの配信時刻以降に、上記リクエストを上記コンテンツ送信装置に送信することが好ましい。【００５７】
また、コンテンツ再生装置がコンテンツ送信装置から取得する複数のセグメントから構成されたコンテンツに対応付けられたコンテンツ管理情報のデータ構造であって、プリフェッチの可否を示すプリフェッチ可否フラグを含むことを特徴とするコンテンツ管理情報のデータ構造も本発明の範疇に含まれる。【００５８】
また、コンテンツ再生装置がコンテンツ送信装置に対してコンテンツを構成する各セグメントの送信を要求するリクエストのデータ構造であって、上記リクエストのヘッダに、セグメントの配信時刻を示すセグメント配信時刻情報を含むことを特徴とするリクエストのデータ構造も本発明の範疇に含まれる。【００５９】
なお、上記コンテンツ送信装置および上記コンテンツ再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記コンテンツ送信装置および上記コンテンツ再生装置の各手段として動作させることにより、上記コンテンツ送信装置および上記コンテンツ再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
【発明の効果】
【００６０】
以上のように、本発明に係るコンテンツ送信装置は、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信する。【００６１】
また、本発明に係るコンテンツ送信装置の制御方法は、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップでは、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントが配信可能な状態になるまで待ち、当該セグメントが配信可能な状態になってから、当該セグメントを含むレスポンスを当該コンテンツ再生装置に送信する。【００６２】
よって、遅延を抑制し高品質な低遅延ライブストリーミングを実行することができるという効果を奏する。【００６３】
また、本発明に係るコンテンツ再生装置は、上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得手段を備え、上記取得手段は、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信する。【００６４】
また、本発明に係るコンテンツ再生装置の制御方法は、上記コンテンツ送信装置に対して各セグメントの送信を要求するリクエストを送信し、当該リクエストに対する応答として、当該セグメントを含むレスポンスを取得する取得ステップを含み、上記取得ステップでは、各セグメントの配信時刻前に、当該セグメントの送信を要求するリクエストを送信する。【００６５】
よって、遅延を抑制し高品質な低遅延ライブストリーミングを実行することができるという効果を奏する。
【図面の簡単な説明】
【００６６】
【図１】本発明の実施形態を示すものであり、サーバおよびクライアントの要部構成の一例を示す図である。
【図２】上記サーバおよび上記クライアントを含むコンテンツ配信システムの構成の一例を示すブロック図である。
【図３】上記サーバのコンテンツ送信処理の一例を示すフローチャートである。
【図４】上記クライアントのコンテンツ取得処理の一例を示すフローチャートである。
【図５】本発明で用いるＭＰＤの記述例を示す図である。
【図６】ライブストリーミングを実行する上記サーバおよび上記クライアントの動作シーケンスの一例を示す図である。
【図７】ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。
【図８】プロキシを含むコンテンツ配信システムの構成の一例を示すブロック図である。
【図９】処理中であることを示すステータスを通知するサーバおよびクライアントの動作シーケンスの一例を示す図である。
【図１０】処理中であることを示すステータスを通知するためのＨＴＴＰメッセージの一例を示す図である。
【図１１】処理中であることを示すステータスを通知するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。
【図１２】処理中であることを示すステータスを通知するためのＨＴＴＰメッセージの一例を示す図である。
【図１３】サーバが、セグメントが配信可能な状態であるか否かを、リクエストに付加されたセグメントの配信時刻に基づいて判断する場合の動作シーケンスの一例を示す図である。
【図１４】セグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージの一例を示す図である。
【図１５】プロキシが、クライアントから送信されたリクエストに付加されたセグメントの配信時刻に基づいて、サーバへのリクエストの送信タイミングを制御する場合の動作シーケンスの一例を示す図である。
【図１６】セグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージの一例を示す図である。
【図１７】従来のＭＰＤの記述例を示す図である。
【図１８】ライブストリーミングを実行するサーバおよびクライアントの動作シーケンスの一例を示す図である。
【図１９】ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。
【図２０】プリフェッチを適用した場合のサーバおよびクライアントの動作シーケンスの一例を示す図である。
【図２１】プリフェッチを適用した場合のＨＴＴＰメッセージの一例を示す図である。
【図２２】リクエストパイプラインを適用した場合のサーバおよびクライアントの動作シーケンスの一例を示す図である。
【図２３】リクエストパイプラインを適用した場合のＨＴＴＰメッセージの一例を示す図である。
【発明を実施するための形態】
【００６７】
本発明の一実施形態について図１から図１６に基づいて説明すると以下の通りである。まず、本実施形態のコンテンツ配信システムの概要について、図２に基づいて説明する。
【００６８】
〔コンテンツ配信システムの概要〕
図２は、本実施形態に係るコンテンツ配信システム６の概要を示す図である。図２に示すように、コンテンツ配信システム６は、サーバ１、クライアント２、ＭＰＤ記憶装置４およびセグメント記憶装置５を含む。
【００６９】
図２に示すように、クライアント２は、サーバ１と接続する。また、サーバ１は、ＭＰＤ記憶装置４およびセグメント記憶装置５と接続する。各装置は、有線通信または無線通信の任意のネットワークで接続される。
【００７０】
サーバ１は、クライアント２からコンテンツの送信を要求を受けて、コンテンツを送信するコンテンツ送信装置である。サーバ１は、コンテンツのデータ本体（セグメントデータ）を送信する前に、予めＭＰＤデータをクライアント２に送信する。なお、サーバ１は、ネットワーク７上のＭＰＤ記憶装置４およびセグメント記憶装置５からＭＰＤデータおよびセグメントデータを取得するものであるが、これに限るものではない。例えば、各サーバ１は、ローカルでＭＰＤデータおよびセグメントデータを保持していてもよい。
【００７１】
クライアント２は、サーバ１等の他の装置から取得したコンテンツ、または、自装置に格納しているコンテンツを再生するコンテンツ再生装置である。クライアント２は、例えば、デジタルテレビ、レコーダ、ＳＴＢ（Set Top Box）、ＰＣ、携帯電話機、スマートフォン、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、デジタルビデオ等である。
【００７２】
また、コンテンツ配信システム６の構成は図２に示す例に限るものではない。例えば、コンテンツ配信システム６は、サーバ１を複数含んでいてもよいし、クライアント２を複数含んでいてもよい。また、コンテンツ配信システム６は、サーバ１−クライアント２間のデータを中継するプロキシ３を１または複数含んでいてもよい。
【００７３】
また、本実施形態では、コンテンツ配信システム６におけるネットワーク上の伝送プロトコルは、ハイパーテキスト転送プロトコルとして広く用いられているＨＴＴＰを用いるものとする。また、サーバ１が配信するコンテンツは、映像コンテンツであり、コンテンツは、セグメント化されたＩＳＯＢＦＦデータであるものとする。すなわち、本実施形態では、コンテンツ配信システム６は、上述のＭＰＥＧ−ＤＡＳＨ規格に基づくコンテンツを配信するものである。
【００７４】
〔各装置の構成〕
次に、図１に基づいて、サーバ１およびクライアント２の要部構成について説明する。図１は、サーバ１およびクライアント２の要部構成の一例を示す図である。
【００７５】
（サーバについて）
図１に示すように、サーバ１は、サーバ制御部１１、サーバ記憶部１２およびサーバ通信部１３を備える構成である。
【００７６】
サーバ通信部１３は、無線通信手段または有線通信手段によって、クライアント２、ＭＰＤ記憶装置４およびセグメント記憶装置５等の他の装置と通信を行い、サーバ制御部１１の指示に従って、データのやりとりを行うものである。
【００７７】
サーバ制御部１１は、サーバ記憶部１２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、サーバ１が備える各部を統括的に制御するものである。
【００７８】
本実施形態では、サーバ制御部１１は、機能ブロックとして、コンテンツ取得部２１およびコンテンツ送信部（送信手段）２２備える構成である。サーバ制御部１１の各機能ブロック（２１、２２）は、ＣＰＵ（central processing unit）が、ＲＯＭ（read only memory）等で実現された記憶装置に記憶されているプログラムをＲＡＭ（random access memory）等で実現された一時記憶部に読み出して実行することで実現できる。
【００７９】
コンテンツ取得部２１は、コンテンツ送信部２２からの指示に基づいて、ＭＰＤ記憶装置４からＭＰＤデータまたはセグメント記憶装置５からセグメントデータを取得するものである。コンテンツ取得部２１は、取得したＭＰＤデータまたはセグメントデータをコンテンツ送信部２２に出力する。
【００８０】
なお、コンテンツ取得部２１は、コンテンツ送信部２２からの指示の有無に関わらず、事前に、ＭＰＤデータおよび／またはセグメントデータを取得していても良い。この場合、コンテンツ取得部２１は、事前に取得したＭＰＤデータおよびセグメントデータをサーバ記憶部１２に格納しておき、コンテンツ送信部２２からの指示に基づいて、サーバ記憶部１２からＭＰＤデータおよびセグメントデータを読み出す。
【００８１】
コンテンツ送信部２２は、クライアント２からリクエストを受信すると、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを判定する。受信したリクエストがセグメントの送信を要求するリクエストである場合、コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１は当該セグメントが配信可能な状態（available）となるまで待つ。そして、コンテンツ送信部２２は、配信可能な状態になるとコンテンツ取得部２１からセグメントデータを取得し、当該セグメントデータを含むレスポンスをクライアント２に送信する。
【００８２】
一方、受信したリクエストがセグメントの送信を要求するリクエストではない場合、リクエストに対するレスポンスを当該クライアント２に送信する。例えば、クライアント２からコンテンツ管理情報（ＭＰＤ）の送信を要求するリクエストを受信すると、当該コンテンツのＭＰＤを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からＭＰＤデータを取得すると、取得したＭＰＤデータを含むレスポンスをクライアント２に送信する。また、クライアント２からWebページ等のリソースの送信を要求するリクエストを受信すると、当該リソースを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からリソースを取得すると、取得したリソースを含むレスポンスをクライアント２に送信する。
【００８３】
なお、コンテンツ送信部２２は、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを、受信したリクエストによって指定されたリソースのメディアタイプがセグメントであるか否かに基づいて判定してもよい。
【００８４】
また、コンテンツ送信部２２は、セグメントが配信可能な状態であるか否かを、当該セグメントの配信時刻に基づいて判断してもよい。すなわち、コンテンツ送信部２２は、セグメントの配信時刻より前は、配信可能な状態ではないと判断し、セグメントの配信時刻以降を配信可能な状態であると判断する。
【００８５】
サーバ記憶部１２は、サーバ制御部１１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部２１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。
【００８６】
（クライアントについて）
図１に示すように、クライアント２は、クライアント制御部４１、クライアント記憶部４２、クライアント通信部４３、表示部４４および音声出力部４５を備える。なお、クライアント２は、操作部、音声入力部等の部材を備えていてもよいが、発明の特徴点とは関係がないため当該部材を図示していない。
【００８７】
クライアント通信部４３は、無線通信手段または有線通信手段によって、サーバ１、プロキシ３等の他の装置と通信を行い、クライアント制御部４１の指示に従って、データのやりとりを行うものである。
【００８８】
表示部４４は、クライアント制御部４１の指示に従って画像を表示するものである。表示部４４は、クライアント制御部４１の指示に従って画像を表示するものであればよく、例えば、ＬＣＤ（液晶ディスプレイ）、有機ＥＬディスプレイ、プラズマディスプレイなどを適用することが可能である。
【００８９】
音声出力部４５は、クライアント制御部４１から電気信号を受信し、受信した電気信号を音に変換し、クライアント２の外部に音を出力するものである。音声出力部４５は、いわゆるスピーカである。
【００９０】
クライアント制御部４１は、クライアント記憶部４２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、クライアント２が備える各部を統括的に制御するものである。
【００９１】
本実施形態では、クライアント制御部４１は、機能ブロックとして、コンテンツ取得部（取得手段）５１およびコンテンツ再生部５２を備える構成である。これらのクライアント制御部４１の各機能ブロック（５１、５２）は、ＣＰＵが、ＲＯＭ等で実現された記憶装置に記憶されているプログラムをＲＡＭ等で実現された一時記憶部に読み出して実行することで実現できる。
【００９２】
コンテンツ取得部５１は、サーバ１にクライアント通信部４３を介してリクエストを送信し、サーバ１からコンテンツ（コンテンツに対応付けられたＭＰＤおよびコンテンツを構成するセグメント）を取得するものである。
【００９３】
具体的には、コンテンツ取得部５１は、ユーザから操作部（不図示）を介してコンテンツの取得（再生）指示が入力されると、当該コンテンツの管理情報（ＭＰＤ）の送信を要求するリクエストをサーバ１に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのＭＰＤデータを受信する。コンテンツ取得部５１は、受信したＭＰＤデータを参照して、上記コンテンツを構成するセグメントの送信を要求するリクエストをサーバ１に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのセグメントデータを取得する。コンテンツ取得部５１は、取得したセグメントデータをコンテンツ再生部５２に出力する。
【００９４】
通常、図１６に示すように、コンテンツ取得部５１は、ＭＰＤを参照して、セグメントの配信時刻（または配信時刻以降）に当該セグメントのリクエストを送信する。また、コンテンツ取得部５１は、前のセグメントを取得してから（前のセグメントのリクエストに対するレスポンスを受信してから）、次のセグメントのリクエストを送信し、セグメントを１つずつ取得する。
【００９５】
本発明では、ＭＰＤにプリフェッチ可否フラグ（詳細は後述する）が記述されており、コンテンツ取得部５１は、ＭＰＤに記述されているプリフェッチ可否フラグがプリフェッチ可能であることを示す場合、セグメントの配信時刻より前に当該セグメントのリクエストを送信する。また、コンテンツ取得部５１は、ＭＰＤに記述されているプリフェッチ可否フラグがプリフェッチ可能であることを示す場合、前のセグメントの取得が完了する前に（前のセグメントのリクエストに対するレスポンスを待たずに）、次のセグメントのリクエストを送信する。例えば、コンテンツ取得部５１は、セグメントの送信を要求する複数のＨＴＴＰリクエストをパイプライン化して送信する。
【００９６】
コンテンツ再生部５２は、コンテンツ取得部５１からセグメントデータを取得すると、ＭＰＤデータを参照して、取得したセグメントデータに基づいてコンテンツを再生するものである。
【００９７】
クライアント記憶部４２は、クライアント制御部４１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部５１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。
【００９８】
〔サーバの処理〕
次に、図３に基づいて、サーバ１のコンテンツ送信処理について説明する。図３は、サーバ１のコンテンツ送信処理の一例を示すフローチャートである。
【００９９】
図３に示すように、サーバ１は、クライアント２からＨＴＴＰリクエストメッセージが送信されるのを待つ。そして、サーバ１は、ＨＴＴＰリクエストメッセージを受信すると（Ｓ１）、受信したＨＴＴＰリクエストメッセージがセグメントの送信を要求するＨＴＴＰリクエストメッセージであるか否かを判定する（Ｓ２）。
【０１００】
受信したＨＴＴＰリクエストメッセージがセグメントの送信を要求するＨＴＴＰリクエストメッセージである場合（Ｓ２でＹＥＳ）、コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１からセグメントデータを取得し、当該セグメントが配信可能な状態（available）となるまで待つ（Ｓ３）。そして、コンテンツ送信部２２は、配信可能な状態になると当該セグメントデータを含むレスポンスをクライアント２に送信する（Ｓ４）。
【０１０１】
一方、受信したＨＴＴＰリクエストメッセージがセグメントの送信を要求するＨＴＴＰリクエストメッセージではない場合（Ｓ２でＮＯ）、リクエストに対するレスポンスを当該クライアント２に送信する（Ｓ４）。
【０１０２】
〔クライアントの処理〕
次に、図４に基づいて、クライアント２のコンテンツ取得処理について説明する。図４は、クライアント２のコンテンツ取得処理の一例を示すフローチャートである。
【０１０３】
図４に示すように、まず、コンテンツ取得部５１は、サーバ１にコンテンツ管理情報（ＭＰＤ）の送信を要求するリクエストを送信する（Ｓ１１）。そして、コンテンツ取得部５１は、このリクエストに対するレスポンスを受信し、レスポンスに含まれるＭＰＤデータを取得する（Ｓ１２）。
【０１０４】
次に、コンテンツ取得部５１は、受信したＭＰＤデータに記述されているプリフェッチ可否フラグを参照して、プリフェッチ可能か否かを判定する（Ｓ１３）。プリフェッチ可能な場合、コンテンツ取得部５１は、受信したＭＰＤデータを参照して、連続した複数のセグメントの送信を要求する複数のリクエストを各セグメントの配信時刻前に送信する（Ｓ１４）。
【０１０５】
コンテンツ取得部５１は、リクエストの送信処理と平行して、レスポンスの受信処理を行い、セグメントを順次取得する。コンテンツ取得部５１は、Ｓ１４でリクエストした全てのセグメントを取得し（Ｓ１５でＹＥＳ）、コンテンツを構成する全てのセグメントのリクエストの送信が完了している場合（Ｓ１６でＹＥＳ）、コンテンツ取得処理を終了する。
【０１０６】
なお、Ｓ１３において、プリフェッチが可能ではない場合（Ｓ１３でＮＯ）、コンテンツ取得部５１は、通常のコンテンツ取得処理（Ｓ１７）を実行するため、ここでは説明を省略する。
【０１０７】
なお、コンテンツ取得部５１は、取得したセグメントを順次、コンテンツ再生部５２に出力し、コンテンツ再生部５２は、上述のコンテンツ取得処理と平行して、取得したセグメントに基づいてコンテンツを再生する。
【０１０８】
〔ＭＰＤの記述例〕
次に、本発明で用いるＭＰＤの記述例について図５に基づいて説明する。図５は、本発明で用いるＭＰＤの記述例を示す図である。
【０１０９】
図５に示すように、本発明で用いるＭＰＤ７０は、図１７に示す従来のＭＰＤ２００に、さらに、プリフェッチ可否フラグが追記されたものである。具体的には、従来のＭＰＤ２００の情報２１０に、プリフェッチ可否フラグが追記されている。図５に示すように、本発明で用いるＭＰＤ７０の情報７１にプリフェッチ可否フラグとして、属性「preFetch」が記述されており、その属性「preFetch」の属性値として、プリフェッチ可能であることを示す「true」が記述されている。なお、プリフェッチ可能ではない場合、属性値に「false」が記述される。
【０１１０】
〔実施例１〕
次に、ライブストリーミングを実行するサーバ１およびクライアント２の動作シーケンスおよびライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図６および図７に基づいて説明する。図６は、ライブストリーミングを実行するサーバ１およびクライアント２の動作シーケンスの一例を示す図である。また、図７は、ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。
【０１１１】
ここでは、クライアント２が、ＭＰＤ７０を参照して、セグメント＃ｎの配信時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の４つのセグメントのリクエストをパイプライン化して送信するものとする。
【０１１２】
図６および図７に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ８１〜８４をパイプライン化してサーバ１に送信する。
【０１１３】
サーバ１は、リクエストメッセージ８１〜８４がセグメントの送信を要求するものであるため、セグメント＃ｎ〜＃ｎ＋３の配信時刻になるまで待つ。そして、セグメント＃ｎの配信時刻ｔ（ｎ）になると、サーバ１は、リクエストメッセージ８１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ８５をクライアント２に送信し、クライアント２はセグメント＃ｎを受信する。
【０１１４】
また、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）になると、サーバ１は、リクエストメッセージ８２の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ８６をクライアント２に送信し、クライアント２はセグメント＃ｎ＋１を受信する。また、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）になると、サーバ１は、リクエストメッセージ８３の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ８７をクライアント２に送信し、クライアント２はセグメント＃ｎ＋２を受信する。また、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）になると、サーバ１は、リクエストメッセージ８４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ８８をクライアント２に送信し、クライアント２はセグメント＃ｎ＋３を受信する。
【０１１５】
このように、クライアント２がセグメントの配信時刻前にリクエストを送信し、サーバ１が当該リクエストに対するレスポンスを、配信時刻になるまで待ってから送信することにより、delayの揺らぎの影響を小さくすることができる。よって、ＮＷジッタに対応した高品質な低遅延ライブストリーミングを実行することができる。
【０１１６】
〔変形例１〕
本実施形態では、コンテンツ配信システム６は、サーバ１、クライアント２、ＭＰＤ記憶装置４およびセグメント記憶装置５を含むものであるが、さらに、プロキシを含んでいてもよい。具体的には、図８に示すように、コンテンツ配信システム６ａは、サーバ１、クライアント２、プロキシ３、ＭＰＤ記憶装置４およびセグメント記憶装置５を含んでいてよい。
【０１１７】
図示のように、クライアント２は、プロキシ３を介して、サーバ１と接続する。また、コンテンツ配信システム６ａは、プロキシ３を複数含んでいてもよい。
【０１１８】
プロキシ３は、サーバ１とクライアント２との間に介在する中継装置であり、クライアント２から送信されたリクエストをサーバ１に転送したり、サーバ１から送信されたレスポンスをクライアント２に転送したりする転送手段（不図示）を備えるものである。また、プロキシ３は、プロキシ記憶部（不図示）を備えていてもよく、クライアント２から送信されたリクエスト、並びに、サーバ１から送信されたレスポンスおよびレスポンスに含まれるセグメントデータ等を格納してもよい。
【０１１９】
〔変形例２〕
本実施形態では、クライアント２は、セグメントの配信時刻より前にリクエストを送信するため、リクエストの送信から当該リクエストに対するレスポンスの受信までの間隔が長い場合がある。この場合、設定によってはタイムアウトとなり、クライアント２が再度リクエストを送信しなければならない。そこで、タイムアウトを防ぎ、再リクエストを送信しないようにするために、サーバ１は、セグメントの送信を要求するリクエストを受信してから所定時間以内に、当該リクエストに対するレスポンスを送信できない場合（セグメントが配信可能な状態にならない場合）、処理中であることを示すステータスをクライアント２に通知してもよい。
【０１２０】
次に、処理中であることを示すステータスを通知するサーバ１およびクライアント２の動作シーケンスおよび処理中であることを示すステータスを通知するためのＨＴＴＰメッセージについて図９および図１０に基づいて説明する。図９は、処理中であることを示すステータスを通知するサーバ１およびクライアント２の動作シーケンスの一例を示す図である。また、図１０は、処理中であることを示すステータスを通知するためのＨＴＴＰメッセージの一例を示す図である。
【０１２１】
ここでは、図６および図７で示すものと同様に、クライアント２が、ＭＰＤ７０を参照して、セグメント＃ｎの配信時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の４つのセグメントのリクエストをパイプライン化して送信するものとする。
【０１２２】
図９および図１０に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ９１〜９４をパイプライン化してサーバ１に送信する。
【０１２３】
サーバ１は、リクエストメッセージ９１〜９４がセグメントの送信を要求するものであるため、セグメント＃ｎ〜＃ｎ＋３の配信時刻になるまで待つ。そして、セグメント＃ｎの配信時刻ｔ（ｎ）になると、サーバ１は、リクエストメッセージ９１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ９５をクライアント２に送信し、クライアント２はセグメント＃ｎを受信する。
【０１２４】
また、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）になると、サーバ１は、リクエストメッセージ９２の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ９６をクライアント２に送信し、クライアント２はセグメント＃ｎ＋１を受信する。
【０１２５】
ここで、リクエストメッセージ９３および９４に対する応答をセグメント＃ｎ＋２、＃ｎ＋３の配信時刻ｔ（ｎ＋２）、ｔ（ｎ＋３）まで待つとそれぞれタイムアウトしてしまうため、サーバ１は、タイムアウトする前に、リクエストメッセージ９３および９４に対して、処理中であることを示すステータスを示すレスポンスメッセージ９７および９８をクライアント２に送信する。クライアント２は、レスポンスメッセージ９７および９８を受信したため、タイムアウトすることなく、リクエストメッセージ９３および９４の応答を待つ。
【０１２６】
そして、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）になると、サーバ１は、リクエストメッセージ９３の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ９９をクライアント２に送信し、クライアント２はセグメント＃ｎ＋２を受信する。また、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）になると、サーバ１は、リクエストメッセージ９４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１００をクライアント２に送信し、クライアント２はセグメント＃ｎ＋３を受信する。
【０１２７】
次に、図８に示すように、プロキシ３を含む場合のサーバ１、クライアント２およびプロキシ３の動作シーケンスおよびＨＴＴＰメッセージについて図１１および図１２に基づいて説明する。図１１は、処理中であることを示すステータスを通知するサーバ１、クライアント２およびプロキシ３の動作シーケンスの一例を示す図である。また、図１０は、処理中であることを示すステータスを通知するためのＨＴＴＰメッセージの一例を示す図である。
【０１２８】
図１１および図１２に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ１１１〜１１４をパイプライン化してプロキシ３に送信する。プロキシ３は、リクエストメッセージ１１１〜１１４を受信して、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ１１５〜１１８をパイプライン化してサーバ１に送信する。
【０１２９】
サーバ１は、リクエストメッセージ１１５〜１１８がセグメントの送信を要求するものであるため、セグメント＃ｎ〜＃ｎ＋３の配信時刻になるまで待つ。そして、セグメント＃ｎの配信時刻ｔ（ｎ）になると、サーバ１は、リクエストメッセージ１１５の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１１９をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１１９を受信して、リクエストメッセージ１１１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１２０をクライアント２に送信し、クライアント２はセグメント＃ｎを受信する。
【０１３０】
また、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）になると、サーバ１は、リクエストメッセージ１１６の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１２１をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１２１を受信して、リクエストメッセージ１１２の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１２２をクライアント２に送信し、クライアント２はセグメント＃ｎ＋１を受信する。
【０１３１】
ここで、リクエストメッセージ１１３および１１４に対する応答をセグメント＃ｎ＋２、＃ｎ＋３の配信時刻ｔ（ｎ＋２）、ｔ（ｎ＋３）まで待つとそれぞれタイムアウトしてしまうため、プロキシ３は、タイムアウトする前に、リクエストメッセージ１１３および１１４に対して、処理中であることを示すステータスを示すレスポンスメッセージ１２３および１２４をクライアント２に送信する。クライアント２は、レスポンスメッセージ１２３および１２４を受信したため、タイムアウトすることなく、リクエストメッセージ１１３および１１４の応答を待つ。
【０１３２】
そして、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）になると、サーバ１は、リクエストメッセージ１１７の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１２５をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１２５を受信して、リクエストメッセージ１１３の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１２６をクライアント２に送信し、クライアント２はセグメント＃ｎ＋２を受信する。
【０１３３】
また、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）になると、サーバ１は、リクエストメッセージ１１８の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１２７をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１２７を受信して、リクエストメッセージ１１４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１２８をクライアント２に送信し、クライアント２はセグメント＃ｎ＋３を受信する。
【０１３４】
〔変形例３〕
本実施形態では、サーバ１は、セグメントが配信可能な状態であるか否かを、ＭＰＤを参照して、当該セグメントの配信時刻に基づいて判断するが、これに限るものではない。例えば、クライアント２が、セグメントの送信を要求するリクエストに当該セグメントの配信時刻を付加してもよい。この場合、サーバ１は、セグメントが配信可能な状態であるか否かを、リクエストに付加されたセグメントの配信時刻に基づいて判断する。
【０１３５】
例えば、クライアント２は、ＨＴＴＰリクエストメッセージの拡張ヘッダを用いて、セグメントの配信時刻を示すセグメント配信時刻情報を付加してもよい。具体的には、ＨＴＴＰリクエストメッセージのヘッダに属性「X-Available」を記述し、その属性値としてセグメントの配信時刻ｔ（ｎ）を記述してもよい。
【０１３６】
次に、サーバ１が、セグメントが配信可能な状態であるか否かを、リクエストに付加されたセグメントの配信時刻に基づいて判断する場合の動作シーケンスおよびセグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージについて図１３および図１４に基づいて説明する。図１３は、サーバ１が、セグメントが配信可能な状態であるか否かを、リクエストに付加されたセグメントの配信時刻に基づいて判断する場合の動作シーケンスの一例を示す図である。また、図１４は、セグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージの一例を示す図である。
【０１３７】
ここでは、図６および図７で示すものと同様に、クライアント２が、ＭＰＤ７０を参照して、セグメント＃ｎの配信時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の４つのセグメントのリクエストをパイプライン化して送信するものとする。また、図８に示すように、クライアント２がプロキシ３を介してリクエストを送信するものとする。
【０１３８】
図１３および図１４に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ１３１〜１３４をパイプライン化してプロキシ３に送信する。プロキシ３は、リクエストメッセージ１３１〜１３４を受信して、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ１３５〜１３８をパイプライン化してサーバ１に送信する。
【０１３９】
サーバ１は、リクエストメッセージ１３５〜１３８がセグメントの送信を要求するものであるため、リクエストメッセージ１３５〜１３８にそれぞれ付加されたセグメント＃ｎ〜＃ｎ＋３の配信時刻になるまで待つ。そして、セグメント＃ｎの配信時刻ｔ（ｎ）になると、サーバ１は、リクエストメッセージ１３５の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１３９をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１３９を受信して、リクエストメッセージ１３１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１４０をクライアント２に送信し、クライアント２はセグメント＃ｎを受信する。
【０１４０】
また、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）になると、サーバ１は、リクエストメッセージ１３６の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１４１をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１４１を受信して、リクエストメッセージ１３２の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１４２をクライアント２に送信し、クライアント２はセグメント＃ｎ＋１を受信する。
【０１４１】
また、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）になると、サーバ１は、リクエストメッセージ１３７の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１４３をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１４３を受信して、リクエストメッセージ１３３の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１４４をクライアント２に送信し、クライアント２はセグメント＃ｎ＋２を受信する。
【０１４２】
また、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）になると、サーバ１は、リクエストメッセージ１３８の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１４５をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１４５を受信して、リクエストメッセージ１３４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１４６をクライアント２に送信し、クライアント２はセグメント＃ｎ＋３を受信する。
【０１４３】
また、クライアント２がプロキシ３を介してサーバ１にリクエストを送信する場合、プロキシ３は、クライアント２から送信されたリクエストに付加されたセグメントの配信時刻に基づいて、サーバ１へのリクエストの送信タイミングを制御してもよい。
【０１４４】
具体的には、プロキシ３は、クライアント２から送信されたリクエストを受信すると、直ぐに、サーバ１へリクエストを転送するのではなく、当該リクエストに付加されたセグメントの配信時刻になるまで待つ。そして、プロキシ３は、リクエストに付加されたセグメントの配信時刻になると、リクエストをサーバ１に送信する。
【０１４５】
プロキシ３が、クライアント２から送信されたリクエストに付加されたセグメントの配信時刻に基づいて、サーバ１へのリクエストの送信タイミングを制御する場合の動作シーケンスおよびセグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージについて図１５および図１６に基づいて説明する。図１５は、プロキシ３が、クライアント２から送信されたリクエストに付加されたセグメントの配信時刻に基づいて、サーバ１へのリクエストの送信タイミングを制御する場合の動作シーケンスの一例を示す図である。また、図１６は、セグメントの配信時刻が付加されたＨＴＴＰリクエストメッセージの一例を示す図である。
【０１４６】
図１５および図１６に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、時刻ｔ（ｎ）の前に、セグメント＃ｎ〜＃ｎ＋３の送信を要求するためのリクエストメッセージ１３１〜１３４をパイプライン化してプロキシ３に送信する。
【０１４７】
ここで、プロキシ３は、受信したリクエストメッセージ１５１〜１５４がセグメントの送信を要求するものであるため、リクエストメッセージに付加されたセグメント＃ｎ〜＃ｎ＋３の配信時刻になるまで待つ。そして、セグメント＃ｎの配信時刻ｔ（ｎ）になると、プロキシ３は、セグメント＃ｎの送信を要求するためのリクエストメッセージ１５５をサーバ１に送信する。
【０１４８】
サーバ１は、リクエストメッセージ１５５の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１５６をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１５６を受信して、リクエストメッセージ１５１の応答として、セグメント＃ｎのデータ本体を含むレスポンスメッセージ１５７をクライアント２に送信し、クライアント２はセグメント＃ｎを受信する。
【０１４９】
また、セグメント＃ｎ＋１の配信時刻ｔ（ｎ＋１）になると、プロキシ３は、セグメント＃ｎ＋１の送信を要求するためのリクエストメッセージ１５８をサーバ１に送信する。サーバ１は、リクエストメッセージ１５８の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１５９をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１５９を受信して、リクエストメッセージ１５２の応答として、セグメント＃ｎ＋１のデータ本体を含むレスポンスメッセージ１６０をクライアント２に送信し、クライアント２はセグメント＃ｎ＋１を受信する。
【０１５０】
また、セグメント＃ｎ＋２の配信時刻ｔ（ｎ＋２）になると、プロキシ３は、セグメント＃ｎ＋２の送信を要求するためのリクエストメッセージ１６１をサーバ１に送信する。サーバ１は、リクエストメッセージ１６１の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１６２をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１６２を受信して、リクエストメッセージ１５３の応答として、セグメント＃ｎ＋２のデータ本体を含むレスポンスメッセージ１６３をクライアント２に送信し、クライアント２はセグメント＃ｎ＋２を受信する。
【０１５１】
また、セグメント＃ｎ＋３の配信時刻ｔ（ｎ＋３）になると、プロキシ３は、セグメント＃ｎ＋３の送信を要求するためのリクエストメッセージ１６４をサーバ１に送信する。サーバ１は、リクエストメッセージ１６４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１６５をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ１６５を受信して、リクエストメッセージ１５４の応答として、セグメント＃ｎ＋３のデータ本体を含むレスポンスメッセージ１６６をクライアント２に送信し、クライアント２はセグメント＃ｎ＋３を受信する。
【０１５２】
〔補足〕
本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【０１５３】
最後に、サーバ１およびクライアント２の各ブロック、特にサーバ制御部１１およびクライアント制御部４１は、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。
【０１５４】
すなわち、サーバ１およびクライアント２は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（central processing unit）、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるサーバ１およびクライアント２の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記サーバ１およびクライアント２に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０１５５】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ（登録商標）／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
【０１５６】
また、サーバ１およびクライアント２を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【産業上の利用可能性】
【０１５７】
本発明は、ＭＰＥＧ−ＤＡＳＨ規格のコンテンツを送信するコンテンツ送信装置、および、当該コンテンツを取得・再生するコンテンツ再生装置に利用することができる。
【符号の説明】
【０１５８】
１    サーバ
２    クライアント
３    プロキシ
４    ＭＰＤ記憶装置
５    セグメント記憶装置
６、６ａ    コンテンツ配信システム
２１    コンテンツ取得部
２２    コンテンツ送信部（送信手段）
５１    コンテンツ取得部（取得手段）
５２    コンテンツ再生部
【図１】
2014010445.tif 000003
【図２】
2014010445.tif 000004
【図３】
2014010445.tif 000005
【図４】
2014010445.tif 000006
【図５】
2014010445.tif 000007
【図６】
2014010445.tif 000008
【図７】
2014010445.tif 000009
【図８】
2014010445.tif 000010
【図９】
2014010445.tif 000011
【図１０】
2014010445.tif 000012
【図１１】
2014010445.tif 000013
【図１２】
2014010445.tif 000014
【図１３】
2014010445.tif 000015
【図１４】
2014010445.tif 000016
【図１５】
2014010445.tif 000017
【図１６】
2014010445.tif 000018
【図１７】
2014010445.tif 000019
【図１８】
2014010445.tif 000020
【図１９】
2014010445.tif 000021
【図２０】
2014010445.tif 000022
【図２１】
2014010445.tif 000023
【図２２】
2014010445.tif 000024
【図２３】
2014010445.tif 000025
【国際調査報告】
2014010445.tif 000026
2014010445.tif 000027
2014010445.tif 000028
2014010445.tif 000029
2014010445.tif 000030
2014010445.tif 000031