WO2012011467A1

WO2012011467A1 - データ配信システム、データ配信方法、配信側データ中継装置、及び受信側データ中継装置

Info

Publication number: WO2012011467A1
Application number: PCT/JP2011/066355
Authority: WO
Inventors: 渡部　秀一; 高橋　真毅
Original assignee: シャープ株式会社
Priority date: 2010-07-20
Filing date: 2011-07-19
Publication date: 2012-01-26
Also published as: CN103004229A; EP2597825A4; JPWO2012011467A1; EP2597825A1; US20130124683A1

Abstract

　ＭＩＭＥマルチパート形式によるＨＴＴＰでコンテンツデータを配信するデータ配信システムにおいて、サーバ側プロキシは、同一リクエストの発生頻度等に応じて、放送経路と通信経路を用いて適応的なフラグメント分割配信を行う。クライアント側プロキシでは、通信経路のレスポンスメッセージに続き、適応的に配信される通信経路からのデータと放送経路からのデータの情報（経路識別、同期情報）のマージ処理を行う。

Description

データ配信システム、データ配信方法、配信側データ中継装置、及び受信側データ中継装置

　本発明は、マルチメディアデータ配信技術に関するもので、より詳細には、データ伝送プロトコルによる通信、放送連携配信に適した効率的なマルチメディアデータ配信を実現するデータ配信システム及びデータ配信方法に関するものである。

　近年、動画像のコンテンツやライブの映像や音声をはじめとするマルチメディアデータ配信の需要が高まっている。これらのマルチメディアのデータ（テキスト、静止画、動画等）を配信する方法としては、インターネット上で提供されるハイパーテキストシステムであるWorld Wide Web（単にWebとも呼ばれる）が広く利用されている。World Wide Webは、クライアントサーバモデルに基づくシステムである。クライアントであるユーザ端末がWorld Wide Web上でウェブページなどの資源を取得する場合には、ウェブブラウザを用いてWorld Wide Webサーバからマルチメディアのデータを取得する。この時、ファイル転送のために使用されるプロトコルとしては、ＨＴＴＰ（HyperText　Transfer　Protocol）が使用されている。このＨＴＴＰを用いて、手軽に映像が利用できる仕組みについての要求も高くなっており、色々な配信方式が検討されている。

　ここでは、まず、ＨＴＴＰに関して簡単に説明する。ＨＴＴＰは、クライアントとコンテンツサーバ間でマルチメディアデータを伝送するためのプロトコルである。ＨＴＴＰによるデータの受け渡し形式の基本構成は、「ヘッダ部」+「区切り（空の行）」+「データ部」である。ヘッダ部にはデータの内容に関する情報や制御情報が記述される。データ部にはデータ本体が記載される。

　クライアントからコンテンツサーバに対して、コンテンツサーバへ入手したいコンテンツデータがあるとき、クライアントは、ＨＴＴＰでリクエストメッセージを送信する。コンテンツデータを要求するリクエストメッセージには、基本的に「データ部」がないため、「ヘッダ部」とヘッダ部の終わりを示す「区切り（空の行）」が送られる。コンテンツサーバでは、クライアントからのコンテンツ要求のリクエストを受けると、受信した「ヘッダ部」に指定されている情報より、リクエストのあったページ情報を抽出し、抽出したページ情報を「データ部」に格納したレスポンスメッセージ（「ヘッダ部」+「区切り（空の行）」+「データ部」）をクライアントに配信する。

　次にＨＴＴＰで配信するデータ構造について説明する。図２９は、従来のフラグメント映像形式を含むＭＰ４ファイル形式のデータ構造を説明するための図である。フラグメント（fragment）とは、コンテンツのデータを所定の長さに分割した上で配信可能な形にまとめた単位データである。フラグメント単位でデータが扱えることにより、データの選別や分離、合成が容易になる。ＭＰ４ファイルを構成するフラグメントは、先頭に、映像を再生するための全体の情報（初期化情報など）を格納したmoovヘッダを含むフラグメント２９０１と、それ以外の、各フラグメント内のデータを再生するための情報を格納したmoofヘッダを含む残りのフラグメント２９０２からなる。尚、１つのフラグメントは、１つのヘッダとそのヘッダに対応するメディアデータ部のmdatにより構成される。１つのＭＰ４ファイルは、１つ以上のフラグメントにより構成される。

　特許文献１には、ＭＰＥＧのISO Base Media File Formatのフラグメント映像形式（Fragmented Movie）を用いた配信方式が記載されている。フラグメント映像形式では、動画全体に関わるデータと、ある基準で分割された分割動画データに対応するメタデータをファイルの先頭に記述し、その後にメタデータに対応する分割動画データを記録する。ここでメタデータとは、分割動画データそのものではなく、分割動画データに関連する情報のこと、例えばデータに含まれる映像の数、画像サイズ、符号化方式、ビットレート、データ位置、タイムスタンプ等を言う。以下同様に分割動画データのメタデータと、対応する分割動画データを時系列に従って順次記録して行く。１つの分割動画データとそのメタデータとの組み合わせを一つの塊として取り扱うことにより、データサイズが予めわかるため、ＨＴＴＰ等のファイル転送のプロトコルにおいても活用することができる。この特許文献１では、配信側の処理負荷や通信ネットワークのトラフィック等を軽減するため、ネットワークカメラから複数の再生装置に映像を配信する際に、両者の間にプロキシを配置したシステム構成とし、このプロキシを経由して、ネットワークカメラから各再生装置に向けて配信する映像信号のマスターデータは同一のものをクライアントへ個別データとして配信している。

　また、伝送帯域が常に確保されている衛星放送の伝送路を用いて、高画質・高音質のコンテンツを多数の視聴者に一斉に配信する高速ダウンロードのサービスが検討されている。通信で用いられるＩＰパケット形式のファイルデータを放送波にのせてダウンロード放送するといったことも行われつつあり、例えば、ARIB STD-B45「高度広帯域衛星デジタル放送におけるダウンロード方式」（非特許文献１）が既に規格化され、開示されている。この規格は、放送と通信が連携することを前提として作成された規格で、ニーズの高いコンテンツは放送伝送路を用いて一斉配信し、個別にリクエストされるコンテンツ（ライセンス等）については通信伝送路を用いて個別に配信するハイブリット型の方式として規定されている。

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

"高度広帯域衛星デジタル放送におけるダウンロード方式"、[online]、社団法人電波産業会、平成22年4月26日、ARIB STD-B45、[平成22年7月8日検索]、インターネット<URL:HTTP://www.arib.or.jp/english/html/overview/doc/2-STD-B45v1_0.pdf>

　しかしながら、上記特許文献１のような従来の通信によるコンテンツデータの一斉配信の方式だけでは、通信ネットワークのトラフィックの増大を抑制するには限界があり、特に、ライブ映像を配信するような場合が問題となる。多数の視聴者が各自のＴＶ端末（クライアント）から放送局側のコンテンツサーバに対して、同時に、同一コンテンツデータに対する視聴要求をするような場合、コンテンツサーバは、利用者それぞれに同一のコンテンツデータを配信するため、通信ネットワークのトラフィックが急激に増大してしまい、通信速度が極端に遅くなってしまうという課題が残る。

　また、上記非特許文献１をはじめとして、放送と通信が連携することを前提に放送でコンテツデータを一斉配信する配信方式も確立されているが、配信方式自体は放送と通信とで独立したものであった。すなわち、通信経路と放送経路からそれぞれ受信したデータを連携・同期するための仕組みが無く、例えば双方から受信したデータを組み合わせて一つのコンテンツとして扱うこと等もできなかった。

　本発明は上記の問題を解決するためになされたものであり、コンテンツサーバ側のプロキシからクライアント側のプロキシへデータ配信する際に、通信経路と放送経路を適応的に利用して同時配信時の負荷を分散することにより、通信ネットワークのトラフィックを抑制するデータ配信システム及びデータ配信方法を提供することを目的とする。

　本発明に係るデータ配信システムは、複数のコンテンツデータを、所定の形式によりメディアセグメント単位で配信するデータ配信装置と、前記データ配信装置と通信網と放送網に接続され、前記データ配信装置から配信された前記コンテンツデータを前記放送網と前記通信網の少なくとも何れかを介して配信する配信側データ中継装置と、前記通信網と前記放送網に接続され、前記配信側データ中継装置から配信される前記コンテンツデータを受信端末装置に配信する受信側データ中継装置と、前記受信側データ中継装置から配信される前記コンテンツデータを受信可能な受信端末装置とを有するデータ配信システムであって、前記配信側データ中継装置は、受信端末装置からのデータ要求に応じて、前記放送網と前記通信網に適応的に分割配信することを特徴とする。

　本発明に係るデータ配信方法は、複数のコンテンツデータを、所定の形式によりメディアセグメント単位で配信するデータ配信ステップと、前記データ配信ステップによって配信された前記コンテンツデータを放送網と通信網の少なくとも何れかを介して配信する配信側データ中継ステップと、前記配信側データ中継ステップによって前記通信網と前記放送網から配信される前記コンテンツデータを配信する受信側データ中継ステップと、前記受信側データ中継ステップによって配信される前記コンテンツデータを受信する受信ステップとを含むデータ配信方法であって、前記配信側データ中継ステップでは、データ要求に応じて、前記放送網と前記通信網に適応的に分割配信することを特徴とする。

　本発明にかかる配信側データ中継装置は、コンテンツをデータ配信装置から受信端末装置にネットワーク経由で配信するデータ配信システムにおいて、前記受信端末装置の要求するコンテンツを前記データ配信装置から受信して前記受信端末装置に配信する配信側データ中継装置であって、前記コンテンツを第１の配信経路で配信する第１送信手段と、前記コンテンツを上記第１の配信経路とは異なる第２の配信経路で配信する第２送信手段と、前記受信端末装置が要求する前記コンテンツを、前記第１送信手段および前記第２送信手段の何れを用いて配信するかを選択する選択手段と、を備えることを特徴とする。

　上記構成によれば、選択手段は、受信端末装置が要求するコンテンツを、受信端末装置に配信する際、第１送信手段または第２送信手段の何れかを選択することができる。よって、２つの送信手段を適応的に選択し、コンテンツを送信することができる。

　本発明にかかる受信側データ中継装置は、コンテンツをデータ配信装置から受信端末装置にネットワーク経由で配信するデータ配信システムにおいて、配信された前記コンテンツを受信して前記受信端末装置に送信する受信側データ中継装置であって、第１の配信経路で配信された前記コンテンツを受信する第１受信手段と、前記第１の配信経路とは異なる第２の配信経路により、前記第１の配信経路とは異なる送信データ形式で配信された前記コンテンツを受信する第２受信手段と、前記第１受信手段および前記第２受信手段の何れで受信したコンテンツについても、同一の送信データ形式で前記受信端末装置に送信する形式統一手段と、を備えることを特徴とする。

　上記構成によれば、形式統一手段は、異なる通信経路を用い異なる送信データ形式で配信されたコンテンツを同一の送信データ形式にし、受信端末装置に送信する。これにより、受信端末装置は、当該コンテンツがどのような経路を用いどのような送信データ形式で配信されたのかを意識することなく、当該コンテンツを利用することができる。

　本発明に係るデータ配信システム及びデータ配信方法では、コンテンツサーバ側のプロキシからクライアント側のプロキシへデータ配信する際に、通信経路と放送経路を適応的に利用して同時配信時の負荷を分散し、通信ネットワークのトラフィックを抑制することが可能となる。

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

本発明の実施形態１に係るデータ配信システムの全体構成を表すシステム構成図である。本発明の実施形態１に係るクライアント側とサーバ側のプロキシの機能ブロック図である。本発明の実施形態１に係るメディアセグメントの説明をするための図である。本発明の実施形態１に係るマルチパート形式を説明するための図である。本発明の実施形態１に係るサーバに最初のコンテンツ要求のリクエストがあった時のレスポンス経路の切替処理を説明するためのシーケンス図である。本発明の実施形態１に係るサーバに最初のコンテンツ要求のリクエストがあった時のレスポンス経路の切替処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態１に係る既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が低い場合のレスポンス経路の切替処理を説明するためのシーケンス図である。本発明の実施形態１に係る既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が低い場合のレスポンス経路の切替処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態１に係る既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が高い場合のレスポンス経路の切替処理を説明するためのシーケンス図である。本発明の実施形態１に係る既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が高い場合のレスポンス経路の切替処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態１に係る放送経路から配信するレスポンスを説明するための図である。本発明の実施形態１に係る放送経路の利用者確認をするためのＨＴＴＰメッセージを説明するための図である。本発明の実施形態１に係る既に放送経路で配信中に他のコンテンツへの切替処理を説明するためのシーケンス図である。本発明の実施形態２に係る放送配信の開始時刻を利用可能時刻とする場合の処理を説明するためのシーケンス図である。本発明の実施形態２に係る放送配信の開始時刻を利用可能時刻とする場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態２に係る放送配信の開始時刻を利用可能時刻とする場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態２に係る放送配信の終了時刻を利用可能時刻とする場合の処理を説明するためのシーケンス図である。本発明の実施形態２に係る放送配信の終了時刻を利用可能時刻として通知するためのメッセージを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理を説明するためのシーケンス図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に放送経路から配信するレスポンスを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の合成処理後に配信するＨＴＴＰメッセージを説明するための図である。本発明の実施形態４に係るクライアント側プロキシに複数のクライアントが繋がる場合の機能ブロック図である。本発明の実施形態５に係るモバイル機器の無線アクセス通信網を使ったデータ配信システムの全体構成を表したシステム構成図である。本発明の実施形態５に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。従来のフラグメント映像形式を含むＭＰ４ファイル形式のデータ構造を説明する図である。

　以下、本発明を、その実施形態を示す図面に基づいて詳述する。

　〔実施形態１〕
　本発明の第１の実施形態は、クライアントとコンテンツサーバ間の通信をＨＴＴＰのプロトコルを用いて行い、ＭＩＭＥマルチパート形式にしたＨＴＴＰメッセージでフラグメント化したコンテンツデータを配信するシステムを用い、放送網と通信網との連携によりコンテンツデータの配信を行う例を説明する。

　図１は、本発明の実施形態１に係るデータ配信システムの全体構成を表すシステム構成図である。本発明のデータ配信システムは、複数のクライアント（受信端末装置）１０１（１０１－１～ｎ）と、各クライアントに接続しクライアントからのリクエストを受けるクライアント側のプロキシ（受信側データ中継装置）１０２（１０２－１～ｎ）と、各クライアント側の複数のプロキシ１０２（１０２－１～ｎ）からのコンテンツ要求のリクエストを代理応答するプロキシ（配信側データ中継装置）１０３と、プロキシ１０３に接続され、多数のコンテンツを管理し、プロキシ経由のクライアントからのリクエストに対して応答するコンテンツサーバ（データ配信装置）１０４とで構成されたクライアントサーバ型のシステムである。本発明のデータ配信システムでは、配信経路として通信経路（通信網、第２の配信経路）と放送経路（放送網、第１の配信経路）の２つが選択的に使用可能である。

　サーバ側のプロキシ１０３は、通信経路の状況に応じて、通信経路と放送経路のどちらの経路を使用して配信するかを決定し、配信経路を切替える機能を備えている。

　また、クライアント側の複数プロキシ１０２（１０２－１～ｎ）は、コンテンツサーバ側のプロキシ１０３から指示された配信経路に対応して、それぞれの配信データを受信し、放送網と通信網の両方の連携により、配信されたコンテンツデータをひとつのコンテンツデータとして、クライアントに配信する機能を備えている。

　本データ配信システムに関して、典型的には、サーバ１０４とプロキシ１０３が放送局に、クライアント１０１とプロキシ１０２がテレビ受像機にあたると想定する。クライアント側プロキシ１０２は、図中点線のようにテレビ受像機に内蔵されていてもよいし、テレビ受像機と独立した外部機器として用意されていてもよい。例えば、昨今のデジタル放送を受信する多くのテレビ受像機は、放送と同時に通信を受ける口を備えている。つまり、放送の受信部と通信の受信部とを備えている。そのようなテレビ受像機ではプロキシを内蔵すると想定することが容易である。クライアント側プロキシをテレビ受像機に内蔵した場合は、クライアントとクライアントに繋がるクライアント側プロキシとは、１対１になる。無論、クライアント側プロキシが外部機器の場合、１つのクライアント側プロキシに複数のクライアントが繋がることが可能である。

　但し、本発明の実施形態１の形態では、クライアント側プロキシ１０２とサーバ側プロキシ１０３の間でのデータ、メッセージの送受をメインに説明するため、特に断らない限りクライアント側プロキシ１０２に繋がるクライアント１０１は１つで説明する。図中点線で囲まれたクライアント１０１、プロキシ１０２を含むテレビ受像機がシステム中に複数存在する（１０１－１～ｎ、１０２－１～ｎ）。

　尚、図１では、コンテンツサーバ１０４には、プロキシ１０３が一台しか接続されていないが、サーバ側に複数のプロキシがある構成としても良い。例えば、配信する放送網の放送局毎にプロキシが用意されていても良いし、サーバに格納されているコンテツのカテゴリー別に用意されていても良い。また、プロキシ１０３に対してコンテンツサーバ１０４が複数接続されていてもよい。

　図２は、本発明の第１の実施の形態に係るデータ配信システムにおいて、クライアント側プロキシ１０２、サーバ側プロキシ１０３双方の内部機能構成の一例を図示した機能ブロック図である。

　クライアント側プロキシ１０２は、クライアント１０１からリクエストを受信する受信部２０１と、メッセージをサーバ側プロキシに送信する送信部２０２と、通信経路でサーバ側プロキシからのレスポンスを受信する受信部（第２受信手段）２０３と、放送経路でサーバ側プロキシからのレスポンスを受信する受信部（第１受信手段）２０４と、通信経路からのレスポンスメッセージを解釈して通信経路、放送経路からのそれぞれのメッセージデータを受信し、メッセージを合成する処理部（形式統一手段）２０５と、処理部２０５がメッセージデータをキャッシュするキャッシュ部２０６と、クライアントにレスポンスメッセージを配信する送信部２０７とから構成されている。なお、メッセージの合成は、放送経路及び通信経路の何れで受信したデータについても、クライアントにおいて同様に取り扱うことができるように、同一のデータ形式に統一するための処理である。ここでは、通信経路で受信したメッセージ（ＭＩＭＥマルチパート形式のメッセージ）は合成せずにそのままクライアントに転送し、放送経路（ＩＰデータキャスト）で受信したデータをＭＩＭＥマルチパート形式のメッセージに合成する。これにより、何れの通信経路が用いられた場合であっても、クライアントにはＭＩＭＥマルチパート形式のメッセージが受信される。

　サーバ側プロキシ１０３は、クライアント側プロキシからリクエストを受信する受信部３０１と、メッセージをサーバ１０４に送信する送信部３０２と、受信したリクエストを監視する監視部３０３と、サーバ１０４からのレスポンスを受信する受信部３０４と、監視部３０３からの通知を受けて受信部３０４のレスポンスメッセージを分解し、通信経路、放送経路向けにデータ形式を整え、経路別にレスポンスメッセージを振り分ける処理部３０５（選択手段）と、処理部３０５がサーバ１０４からのレスポンスをキャッシュするキャッシュ部３０６と、処理部３０５により通信経路向けデータ形式に整えられたレスポンスメッセージを通信経路に配信する送信部（第２送信手段）３０７と、処理部３０５により放送経路向けデータ形式に整えられたレスポンスメッセージを放送経路に配信する送信部（第１送信手段）３０８とから構成されている。

　図３は、本発明の実施形態１に係るメディアセグメント（Media segment）の説明をするための図である。１つのＨＴＴＰメッセージに格納されるフラグメントの組をメディアセグメントとして定義する。サーバ側プロキシ１０３とクライアント側プロキシ１０２の間では、メディアセグメントの単位でメッセージの送受信が行われる。本発明では、コンテンツデータを取り扱うために、図２９に記載したようなフラグメントのデータ構造を基本構造としている。図３には、コンテンツが所定の長さのフラグメントに分割され、コンテンツの先頭をfragment0とし、それ以降をfragment1、・・・、fragment（N-1）、fragmentN、・・・、fragment（2N-1）、fragment（2N）、・・・等で示されている。図３に記載してあるコンテンツ（content）の最初のメディアセグメント（content/0）はfragment0からfragment（N-1）のＮ個のフラグメントから構成されている。コンテンツの２番目のメディアセグメント（content/1）は、fragmentNからfragment（2N-1）のＮ個のフラグメントから構成されている。以下同様に、コンテンツの最後のデータまでメディアセグメントは、同じＮ個のフラグメントで構成されている。

　最後のメディアセグメントに対応するフラグメントの数がＮ個に満たない場合は、足りない分だけ、ダミー用のフラグメントを挿入する。又は、最後のメディアセグメントのみ、有効なフラグメントの数のみとするようにしても良い。コンテンツの先頭のフラグメント：fragment0には、コンテンツ全体の長さの情報も入っているので、その値から最後のメディアセグメントに含まれるフラグメントの数を算出できる。

　図４は、本発明の実施形態１に係るデータ配信システムで使用するクライアントから送信するリクエストと、コンテンツサーバ側のプロキシ１０３経由で配信するコンテンツサーバ１０４からのマルチパート形式のレスポンスを説明するための図である。

　図４（ａ）は、クライアントから送信するリクエストのＨＴＴＰメッセージの一例を示す。これは、ＨＴＴＰメッセージのリクエストを「ＧＥＴ」コマンドを用いて記載したものであり、「content1」のコンテンツの「0」番目のメディアセグメントのデータをサーバへ要求をしている。尚、使用する通信プロトコルは、「ＨＴＴＰ」のバージョン「１．１」である。「Accept」のリクエストヘッダフィールドは、レスポンスで受け入れ可能なメディアタイプを指定するために使われる。ここでは、ＭＰ４のファイル形式の映像信号：「video/mp4」、あるいはＭＩＭＥマルチパート形式のメディアセグメント：「multipart/media-segment」をレスポンスで要求している。

　図４（ｂ）は、１つのメディアセグメントをＭＩＭＥマルチパート形式によるＨＴＴＰレスポンスメッセージで記載した場合の一例を示しており、１つのメディアセグメントは、１０個のフラグメントから構成されている。４０１がＨＴＴＰレスポンスメッセージの「ヘッダ部」である。次の空の行が「区切り」で続いて「データ部」が記載されている。「データ部」は、プロキシ内でのＨＴＴＰレスポンスメッセージの分解、合成を容易にするため、コンテンツのフラグメントのバイナリデータの部分をＭＩＭＥ（Multipurpose Internet Mail Extensions）形式のデータにエンコードし、ＨＴＴＰのメッセージにマルチパート形式で記載し、これをＨＴＴＰレスポンスメッセージとして利用している。本発明の説明で使用しているマルチパート形式とは、１つのＨＴＴＰメッセージの「データ部」に、ヘッダ部の「boundary=」で指定される文字列「BOUNDARY」で区切られた複数の部分データ、本実施形態ではフラグメントを記載するＨＴＴＰメッセージの形式である。４０２－１の部分が１番目のフラグメントである。４０２－２の部分が２番目のフラグメントであり、４０２－１０の１０番目のフラグメントまで連続して記載し、１つメディアセグメントのＨＴＴＰレスポンスメッセージを構成している。尚、図４（ｂ）の例では１つのフラグメントの時間長さを１秒、１つのメディアセグメントの時間長さを１０秒としている。以下の実施の形態の図面及び説明は、これをベースに行う。但し、実際にはフラグメントの長さ、メディアセグメントの長さは任意に設定可能である。

　図５は、本発明の実施形態１に係るデータ配信システムにおいて、サーバに最初のコンテンツ要求のリクエストがあった時のレスポンス経路の切替処理を説明するためのシーケンス図である。Ｓ５０１（Ｓは「ステップ」を示す、以下同様）においては、クライアント１０１は、コンテンツサーバ１０４に見たいコンテンツがある場合、コンテンツサーバ１０４に対してコンテンツ要求のリクエストを送信する。クライアント１０１から発せられたリクエストは、通信経路でクライアント側プロキシ１０２を経由して、クライアント側プロキシ１０２からコンテツサーバの代理処理を行うサーバ側プロキシ１０３へと送信される（Ｓ５０２）。サーバ側プロキシ１０３の受信部３０１がリクエストを受信すると、監視部３０３で、同じリクエストを既に受信しているか、対応するレスポンスが既にキャッシュ３０６にキャッシュされているか、即ち過去の受信の有無が確認される。また、同一コンテンツに対する要求の頻度が確認される（Ｓ５０３）。

　要求の頻度とは、所定の時間内に同一コンテンツに対するリクエストの要求がどれだけ送られてくるかを測った尺度であり、頻度＝回数／時間で与える。本実施形態では、同一の時間帯に同じリクエストが集中することを想定し、そのような状況で放送路を効果的に活用して最適なコンテンツ配信を行うことを目的とするため、要求の頻度を利用する。つまり、本実施形態では、通信網のトラフィックが大きい場合に生じる、要求の頻度が高いという事象の発生を検出した場合に、放送路による配信を選択する。これにより、通信網のトラフィックを抑制して効率のよいコンテンツ配信が可能になる。なお、検出する事象は、通信網のトラフィックが大きい場合に生じる事象であればよく、この例に限られない。例えば、通信路でセグメントを配信した後、次のセグメントに対するリクエストを受信するまでの期間が通常よりも長い場合には、通信網のトラフィックが大きいと考えられるので、この期間が所定のしきい値を超えたことを検出する構成としてもよい。

　図５では、同一コンテンツに対するリクエストを未だ受信していないため、サーバ側プロキシ１０３の処理部３０５は、監視部３０３からの要求頻度の通知：「要求頻度が低い（無）」を受けて、受信部３０１で受信したクライアント１０１からのリクエストを送信部３０２よりコンテンツサーバ１０４に送る（Ｓ５０４）。

　コンテンツサーバ１０４は、クライアント１０１からのリクエストに対応したＭＩＭＥマルチパート形式のコンテンツデータを含むレスポンスをサーバ側プロキシ１０３に返す（Ｓ５０５）。この時点では同一のコンテンツの要求の頻度は高くないため、サーバ側プロキシ１０３の処理部３０５は、放送経路ではなく通信経路でのレスポンスの配信を選択する。コンテンツサーバ１０４からのレスポンスを受信部３０４で受信したサーバ側プロキシ１０３の処理部３０５は、送信部（通信経路）３０７より通信経路でクライアント側プロキシ１０２に返す（Ｓ５０６）。クライアント側プロキシ１０２は、受信したレスポンスを、クライアント１０１まで返す（Ｓ５０７）。クライアント１０１はコンテンツを再生する（Ｓ５０８）。クライアント１０１は次のコンテンツデータをリクエストする（Ｓ５０９）。

　図６は、図５のシーケンス図で示される本発明の実施形態１に係るデータ配信システムの動作において、サーバに最初のコンテンツ要求のリクエストがあった時のレスポンス経路の切替処理の際に送受信されるＨＴＴＰメッセージを説明するための図である。

　図６（ａ）のＭ５０１（Ｍは「ＨＴＴＰメッセージ」を示す、以下同様）は、図５のＳ５０１のクライアント１０１からコンテンツサーバ１０４に通信経路を用いて送信するＨＴＴＰリクエストメッセージの一例を示す。このリクエストメッセージＭ５０１は、図５でクライアント１０１からクライアント側プロキシ１０２及びサーバ側プロキシ１０３を経由してコンテンツサーバ１０４に送られるＨＴＴＰリクエストメッセージで、それぞれの機器間で通信Ｓ５０１、Ｓ５０２、Ｓ５０４で同じＭ５０１が送られる。

　図６（ｂ）のＭ５０５は、図５のコンテンツサーバ１０４からクライアント１０１に通信経路を用いて配信するＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。このレスポンスメッセージは図５でコンテンツサーバ１０４からサーバ側プロキシ１０３及びクライアント側プロキシ１０２を経由してクライアント１０１に配信するＨＴＴＰリクエストメッセージで、それぞれの機器間の通信Ｓ５０５、Ｓ５０６、Ｓ５０７で同じＭ５０５が送られる。

　図６（ｃ）のＭ５０９は、図５のクライアント１０１からコンテンツサーバ１０４に通信経路を用いて送信する２番目のメディアセグメントのＨＴＴＰリクエストメッセージの一例を示す。図５にはクライアント１０１からクライアント側プロキシ１０２へのリクエストを配信するＳ５０９しか記載していないが、このリクエストもＳ５０１と同様に、クライアント１０１からクライアント側プロキシ１０２及びサーバ側プロキシ１０３を経由してコンテンツサーバ１０４に送られるＨＴＴＰリクエストメッセージで、それぞれの機器間で送信するリクエストメッセージである。

　図７は、本発明の実施形態１に係るデータ配信システムにおいて、既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が低い場合のレスポンス経路の切替処理を説明するためのシーケンス図である。他のクライアントから同じコンテンツ要求のリクエストを既に受信済で、かつ、複数のクライアントからの同一のコンテンツ要求の頻度が高くない状況での処理を示している。

　クライアント１０１からは、コンテンツサーバ１０４に対してコンテンツ要求のリクエストを送信する。コンテンツ要求のリクエストは、まず、クライアント１０１からクライアント側プロキシ１０２に送信する（Ｓ７０１）。クライアント側プロキシ１０２で受信したコンテンツ要求のリクエストは、クライアント側プロキシ１０２からサーバ側プロキシ１０３に送信する（Ｓ７０２）。サーバ側プロキシ１０３の受信部３０１は、クライアント側プロキシ１０２経由で送信されたクライアント１０１からのコンテンツ要求のリクエストを受信する。前記リクエスト受信後、サーバ側プロキシ１０３の監視部３０３は、同じリクエストを既に受信しているかどうか、対応するレスポンスが既にキャッシュ３０６にキャッシュされているか、即ち過去の受信の有無を確認する。また、同一コンテンツに対する要求の頻度を確認する（Ｓ７０３）。

　図７では、コンテンツサーバ１０４に既に他のクライアントからのコンテンツ要求のリクエストがあり、サーバ側プロキシ１０３は既に最初のコンテンツ要求に対してレスポンスを返している状態である。即ち、同一のコンテンツ要求に対応するレスポンスをキャッシュ３０６に既に保持している状態である。かつ、同一のコンテンツ要求の頻度は低いことが確認されたものとする。

　サーバ側プロキシ１０３の処理部３０５は、監視部３０３からの要求頻度の通知：「要求頻度が低い」を受けて、放送経路ではなく通信経路でのレスポンスの配信を選択する。既に対応するレスポンスをキャッシュ３０６に保持しているため、サーバ側プロキシ１０３の処理部３０５は、コンテンツサーバ１０４へはリクエストを送信せず、キャッシュ済みのレスポンスをキャッシュ部３０６から抽出し、送信部（通信経路）３０７より、クライアント側プロキシ１０２経由でクライアント１０１に配信する（Ｓ７０４、Ｓ７０５）。クライアント１０１は、ＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージを受信後、コンテンツデータを抽出し、コンテンツ即ち映像を再生する（Ｓ７０６）。次に、クライアント１０１は、コンテンツサーバ１０４に対して次のメディアセグメントのリクエストをクライアント側プロキシ１０２経由で配信する（Ｓ７０７）。

　図８は、図７のシーケンス図で示される本発明の実施形態１に係るデータ配信システムの動作において、既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が低い場合のレスポンス経路の切替処理の際に送受信されるＨＴＴＰメッセージを説明するための図である。

　図８（ａ）のＭ７０１は、図７のクライアント１０１からコンテンツサーバ１０４に対して通信経路を用いて送信するＨＴＴＰリクエストメッセージの一例を示す。図７に示す通り、このリクエストは結果的にはコンテンツサーバ１０４には送られない。このリクエストメッセージは図７のクライアント１０１からクライアント側プロキシ１０２を経由してサーバ側プロキシ１０３に送られるＨＴＴＰリクエストメッセージで、それぞれの機器間でのＳ７０１、Ｓ７０２で同じリクエストＭ７０１が送信される。

　図８（ｂ）のＭ７０４は、図７のサーバ側プロキシ１０３からクライアント１０１に通信経路を用いて配信するＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。このレスポンスメッセージは図７のコンテンツサーバ１０４からサーバ側プロキシ１０３に他のクライアントからのリクエストを受けて一度配信されたものであり、サーバ側プロキシ１０３が、そのレスポンスをキャッシュ３０６に保持していたものである。サーバ側プロキシ１０３は、クライアント１０１からの同一のコンテンツ要求を受信した場合には、コンテンツサーバ１０４の代わりに代理応答して、キャッシュ３０６に保持していたレスポンスを、コンテンツ要求のリクエストを送信したクライアント１０１に対してクライアント側プロキシ１０２経由で配信する。このＨＴＴＰレスポンスメッセージは、それぞれの機器間のＳ７０４、Ｓ７０５で同じＭ７０４が配信される。

　図８（ｃ）のＭ７０７は、図７のクライアント１０１からコンテンツサーバ１０４に対して通信経路を用いて送信する２番目のメディアセグメントのＨＴＴＰリクエストメッセージの一例を示す。このリクエストも結果的にコンテンツサーバ１０４には送られない。図７にはクライアント１０１からクライアント側プロキシ１０２へのリクエストＳ７０７しか記載していないが、このリクエストもＳ７０１と同様に、クライアント１０１からクライアント側プロキシ１０２を経由してサーバ側プロキシ１０３に送信されるＨＴＴＰリクエストメッセージである。

　図９は、本発明の実施形態１に係るデータ通信システムにおいて、既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が高い場合のレスポンス経路の切替処理を説明するための図である。他のクライアントから同じコンテンツ要求のリクエストを既に受信済で、かつ、複数のクライアントから、同一のコンテンツ要求の頻度が高い状況での処理を示している。

　クライアント１０１からは、コンテンツサーバ１０４に対してコンテンツ要求のリクエストが送信される。図９に示す通り、このリクエストは結果的にはコンテンツサーバ１０４には送られない。コンテンツ要求のリクエストは、まず、クライアント１０１からクライアント側プロキシ１０２に配信する（Ｓ９０１）。クライアント側プロキシ１０２で受信されたコンテンツ要求のリクエストは、クライアント側プロキシ１０２からサーバ側プロキシ１０３へ送信される（Ｓ９０２）。サーバ側プロキシ１０３の受信部３０１が、クライアント側プロキシ１０２経由で送られたクライアント１０１からのコンテンツ要求のリクエストを受信すると、監視部３０３で、同じリクエストを既に受信しているか（即ち対応するレスポンスが既にキャッシュ３０６にキャッシュされているか）即ち過去の受信の有無が確認される。また、同一コンテンツに対する要求の頻度が確認される（Ｓ９０３）。

　同じリクエストを既に多数受信し、かつ、Ｓ９０２のリクエストを受信することで要求の頻度が所定のしきい値を超えたとする。つまり、ここでは予め要求頻度のしきい値を設定しておき、このしきい値と現在の頻度とを比較することによって、要求頻度が高いか低いかを判断する。このとき、既にリクエストに対応するレスポンスメッセージはキャッシュ部３０６にキャッシュされているため、コンテンツサーバ１０４にはリクエストを送らない。さらに、サーバ側プロキシ１０３の処理部３０５は、監視部３０３からの要求頻度の通知：「要求頻度が高い」を受けて、通信経路だけではなく放送経路でのレスポンスの配信を選択し、以下の処理を実行する。

　まず、サーバ側プロキシ１０３の処理部３０５では、受信したリクエストに対応するレスポンスを放送経路で既に配信中かどうかを確認する（Ｓ９０４）。配信中でなければ、放送経路を確認し、確保し、レスポンスＳ９０６の後に続く以降のコンテンツデータについて放送経路での配信を開始する。既に配信中であれば、その放送経路を確認する。尚、放送経路での配信を中止するか否かは利用状況をモニタして行うので、要求頻度の変動とは必ずしも同期しない。このため、既に放送経路で配信中か否かを確認する必要がある（Ｓ９０４）。利用状況のモニタについては後述する。

　次に、サーバ側プロキシ１０３の処理部３０５は、クライアント１０１からのリクエストに対応するレスポンスを既にキャッシュ３０６に保持しているため、コンテンツサーバ１０４へのリクエストはせず、キャッシュ３０６からキャッシュ済みのレスポンスを抽出する。そして、抽出したレスポンスに対して、サーバ側プロキシ１０３の処理部３０５により、監視部３０３からの要求頻度の通知に応じて選択された経路情報が付加される。ここでは、「要求頻度が高い」ため放送経路が選択され、処理部３０５は、リクエストに対応したレスポンスメッセージのヘッダに、Ｓ９０４で確認又は確保された放送経路を示す、以下の放送経路の情報を付加する（Ｓ９０５）。
X-Alternative-Path: broadcast-ipdatacast
X-Broadcast-Channel: 1
X-Ipdatacast-Address: 200.1.1.1
　具体的なレスポンスメッセージの例は後述する図１０（ｂ）に示している。処理部３０５は、放送経路で送ることを示す情報（X-Alternative-Path: broadcast-ipdatacast）と共に、上記Ｓ９０４で確認又は確保した放送経路の情報、即ち、データを送る放送経路を識別するため情報（X-Broadcast-Channel: 1）、及びその放送経路内でデータを識別するための情報（X-Ipdatacast-Address: 200.1.1.1）をＨＴＴＰのレスポンスメッセージのヘッダ部分に付加する。ヘッダに放送経路情報が付加されたレスポンスは、通信経路の送信部３０７より、通信経路を用い、クライアント側プロキシ１０２に配信される（Ｓ９０６）。

　上記した放送経路を示す情報の例は、ＩＰデータキャストによる放送配信の例を示している。後述するように、マルチパート化したコンテンツデータを含むレスポンスメッセージをＩＰパケット化し、チャンネル1に、宛先アドレス200.1.1.1として配信する例である。クライアント側プロキシ１０２は宛先アドレスでＩＰパケットを識別する。チャンネル情報は周波数帯を直接指定する情報に置き換えることもできる。尚、これら放送配信に利用するチャンネルとＩＰアドレスは、サーバ側プロキシ１０３に予め設定されていてもよいし、サーバ側プロキシ１０３が各チャンネルの空き情報等を把握し、都度決定するようにしてもよい。また、クライアントの端末が可搬なモバイル機器であった場合に、クライアント端末の現在位置をモバイル機器に搭載される位置情報通知機能（Geolocation APIなど）を使って取得し、サーバ側プロキシ１０３がクライアントの現在位置に最適な放送経路、チャンネル、ＩＰアドレスを決定するといった形態も可能である。

　このほか、図示しないが、デジタル放送のデータ放送で用いられるデータカルーセル方式を用いてコンテンツデータを含むレスポンスメッセージを放送配信することも可能である。この場合、ヘッダに追加される情報の例は以下である。
X-Alternative-Path: broadcast-datacarrousel
X-Broadcast-Channel: 1
X-Dataevent-Id: 200
　これは、マルチパート化したコンテンツデータを含むレスポンスメッセージをカルーセルにカプセル化し、チャンネル1に、イベントID 200として配信する例である。クライアント側プロキシ１０２はイベントIDでカルーセルを識別する。

　クライアント側プロキシ１０２の処理部２０５は、サーバ側プロキシ１０３から経路情報を付加したレスポンスメッセージを受信すると、Ｓ９０５で付加したヘッダをレスポンスメッセージから削除する。クライアント側プロキシ１０２の処理部２０５は、経路情報が削除されたレスポンスをクライアント１０１に送る（Ｓ９０７）。

　クライアント１０１は、ＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージを受信後、コンテンツデータを抽出し、コンテンツ即ち映像を再生する（Ｓ９０８）。

　更に、クライアント側プロキシ１０２の処理部２０５は、Ｓ９０５で付加されたヘッダの情報をみて、以降、放送経路で伝送されてくるデータを識別し、取得する（Ｓ９１０）。識別には各ＩＰパケットに付されたＩＰデータキャストアドレス（宛先アドレス）を利用する。尚、図示しないが、放送配信ではルーティング処理が不要なために、先頭以外のＩＰパケットのヘッダについては、先頭パケットと同一のヘッダであることを示す識別子に置き換え（この処理によりヘッダのデータ量が低減される）、この識別子でＩＰパケットを識別することも行われる。そして、クライアント側プロキシ１０２の処理部２０５は、受信されたデータをマルチパート形式のレスポンスメッセージに合成する（Ｓ９１１）。

　尚、このとき、放送経由で配信するレスポンスメッセージには、利用前にサーバ側プロキシ１０３での検証が必要であることを示す情報（Cache-Control: proxy-revalidate）及び、検証に使う識別タグ情報（ETag: “abcde”）を付して送る。具体的なレスポンスメッセージの例は後述する図１１に示している。（なお、ここでは、説明を容易にするため、サーバ側プロキシ１０３での処理において識別タグ情報ETagが初めて現れるが、ETagは本来、コンテンツサーバ１０４が個々のメッセージに対して付けるタグ情報である。従って、本実施形態の各図には図示されていないが、ETagはコンテンツサーバ１０４から配信されるレスポンスメッセージの各々に予め付けられていると考えてよい。また、ETagが付けられていない場合に、サーバ側プロキシ１０３が独自のタグ、例えばX-proxy-ETagを付けるとしてもよい。この、検証が必要であるとの情報が付されることにより、クライアント側プロキシ１０２は、合成されたレスポンスＳ９１１が有効か否かを検証するために検証のリクエストをサーバ側プロキシ１０３に対して必ず送信することとなる（Ｓ９１２）。サーバ側プロキシ１０３は検証のリクエストに対して、リクエストメッセージに記載されている識別タグ情報からレスポンスＳ９１１が有効か確認し、有効であることが確認された場合には、有効を示すレスポンスをクライアント側プロキシ１０２に配信する（Ｓ９１４）。これと同時に、サーバ側プロキシ１０３は、この検証のリクエストの受信状態をモニタすることで、放送経路で送ったコンテンツデータがクライアントでどの程度利用されているかを判断する。そして、検証のリクエストが来なければ、放送経路で送ったコンテンツを受信しているクライアントは無くなったと判断し、放送経路での配信を中止する。なお、検証のリクエストが来ない状況となっているか否かは、例えば予め定めた期間、検証のリクエストが受信されない状態が継続しているか否かによって判断してもよい。

　クライアント１０１は、コンテンツサーバ１０４に対する次のメディアセグメントのリクエストをクライアント側プロキシ１０２に送信し（Ｓ９０９）、対応するレスポンスを受け取って（Ｓ９１５）、コンテンツを再生する（Ｓ９１６）。このとき、図９に示す通り、クライアント側プロキシ１０２での動作は、放送経由で受け取っているレスポンスをクライアント１０１に返しているのみであり、クライアント１０１のリクエストはサーバ側プロキシ１０３及びコンテンツサーバ１０４に送られることはない。また、Ｓ９０９で配信するリクエストとＳ９１０～Ｓ９１４の処理とは必ずしも同期している必要はなく、Ｓ９０９のリクエストに対するレスポンスＳ９１５を返すまでにＳ９１０～Ｓ９１４の処理が完了していればよい。

　図１０乃至図１２は、図９のシーケンス図で示される本発明の実施形態１に係るデータ配信システムの動作において、既にコンテンツ要求のリクエストがあった時、コンテンツ要求頻度が高い場合のレスポンス経路の切替処理の際に送受信するＨＴＴＰメッセージ及び放送経路上の配信データを説明するための図である。

　図１０（ａ）のＭ９０１は、図９のＳ９０１でクライアント１０１からコンテンツサーバ１０４に対して通信経路を用いて送信されるＨＴＴＰリクエストメッセージの一例を示す。図９に示す通り、このリクエストはコンテンツサーバ１０４までは送られない。このリクエストメッセージは、図９のクライアント１０１からクライアント側プロキシ１０２を経由してサーバ側プロキシ１０３に送られるＨＴＴＰリクエストメッセージで、それぞれの機器間のＳ９０１、Ｓ９０２で同じリクエストＭ９０１が伝送される。

　図１０（ｂ）のＭ９０６は、図９のＳ９０６でサーバ側プロキシ１０３からクライアント側プロキシ１０２に通信経路を用いて配信するＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。このレスポンスメッセージのうち放送経路を示したヘッダ部の情報を除くレスポンスメッセージは図９のコンテンツサーバ１０４からサーバ側プロキシ１０３に他のクライアントからのリクエストに応じて一度配信されたものであり、サーバ側プロキシ１０３が、そのレスポンスをキャッシュ３０６に保持していたものである。サーバ側プロキシ１０３は、クライアント１０１からの同一のコンテンツ要求を受信した場合に、コンテンツサーバ１０４の代わりに代理応答して、キャッシュ３０６に保持していたレスポンスを、コンテンツをリクエストしたクライアント１０１のクライアント側プロキシ１０２に対して配信する。そしてこのとき、処理部３０５は、Ｓ９０３の要求頻度の確認で監視部３０３からコンテンツの要求頻度が高いとの通知を受け、放送経路を選択し、Ｓ９０５でレスポンスメッセージＭ９０６のヘッダ部分に上記した放送経路を示す経路情報を付加している。

　図１０（ｃ）のＭ９０７は、図９のＳ９０７でクライアント側プロキシ１０２からクライアント１０１に通信経路を用いて配信するＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。このレスポンスメッセージは、図９のサーバ側プロキシ１０３からＳ９０６で配信された経路情報が付加されたレスポンスメッセージをクライアント側プロキシ１０２が受信した際、処理部２０５で、Ｓ９０５で付加された全ての経路情報を削除し、再構成したレスポンスメッセージである。

　図１１は、図９のシーケンス図で示される本発明の実施形態１に係るデータ配信システムの動作にて、放送経路で配信するレスポンスのデータの形式を説明するための図である。図９のＳ９１０では、ＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージをＩＰパケット化されたデータＭ９１０を形成し、ＩＰデータキャストによる放送配信をしている。図１１は、配信しようとするＨＴＴＰメッセージとＩＰパケット化して形成される放送配信データＭ９１０との関係を示している。ＩＰパケットは、ＩＰデータキャストアドレスが格納されるヘッダ部分と転送したいデータ本体を格納するペイロードデータで構成されている。ペイロードデータには、レスポンスメッセージを要求した元のリクエストメッセージが指定していたＵＲＩであるリクエストデータＵＲＩ、配信しようとするＨＴＴＰレスポンスメッセージのヘッダ部のデータ、並びに、メッセージのデータ部の各フラグメントのデータが各々、１つまたは複数のＩＰパケットに分割されて格納されている。フラグメントデータは、メディアセグメント分だけのデータが格納されている。また、フラグメントデータ毎にＩＰパケットが分れて格納されていることで、放送配信中に一部のデータが失われた場合でも、失われたデータに対応するフラグメントデータ以外のデータを復元して、コンテンツを再生可能とできるといった利点がある。

　さらに、この配信しようとするＨＴＴＰレスポンスメッセージには、上記で既に説明した通り、利用前にサーバ側プロキシ１０３での検証が必要であることを示す情報（Cache-Control: proxy-revalidate）及び、検証に使う識別タグ情報（ETag: “abcde”）とが含まれている。

　図１２も同じく、図９のシーケンス図で示される本発明の実施形態１に係るデータ配信システムの動作において送受信されるＨＴＴＰメッセージを説明するための図である。特に、図１２（ａ）、（ｂ）は、放送経路で送られたデータについて利用者確認をするために用いられるＨＴＴＰメッセージの例を示している。

　図１２（ａ）のＭ９１２は、図９のＳ９１１で合成したレスポンスが有効か否かを検証するために、Ｓ９１２でクライアント側プロキシ１０２からサーバ側プロキシ１０３に通信経路を用いて送信する、検証のためのＨＴＴＰリクエストメッセージの一例を示す。この例では、ETag“abcde”と同じ識別タグ情報が付されたレスポンスメッセージがサーバ側プロキシ１０３にあるかを問い合わせる形で検証を行う。（同じものがあればクライアント側プロキシ１０２にあるレスポンスメッセージはサーバ側プロキシ１０３から得たものであると確認され、即ち有効と判断される。）
　図１２（ｂ）のＭ９１４は、図９のＳ９１２の検証のリクエストの検証結果を示すＳ９１４のレスポンスであって、サーバ側プロキシ１０３からクライアント側プロキシ１０２に通信経路を用いて送信するＨＴＴＰレスポンスメッセージの一例を示す。この例では、サーバ側プロキシ１０３に同一のものがあることが示される。

　図１２（ｃ）のＭ９１５は、図９のＳ９０９に対するＳ９１５のレスポンスであって、クライアント側プロキシ１０２からクライアント１０１に配信するＭＩＭＥマルチパート形式のレスポンスメッセージの一例を示す。

　このように、本実施の形態のデータ配信システムでは、要求の頻度によってコンテンツの配信経路を適応的に切替えることにより、通信帯域を圧迫しない程度に要求が少ないと判断できれば通信経路を利用して高速にコンテンツデータを送るし、通信帯域を圧迫するほどに要求が多い状況であれば放送経由でコンテンツを一斉配信する。これにより、コンテンツの伝送速度、通信帯域の状態の双方を加味した最適なコンテンツ配信が実現できる。

　次に、本発明の実施形態１に係るデータ配信システムにおいて、放送経路で既に配信中の他のコンテンツへ受信するコンテンツを切替える際の処理を図１３を用いて説明する。

　図１３は、本発明の実施形態１に係るデータ配信システムにおいて、既に放送経路で配信中の他のコンテンツへ受信コンテンツを切替える際の切替処理（切替時点）を説明するためのシーケンス図である。

　クライアント１０１は、配信されているコンテンツの切替をリクエストする。具体的には、ＳＤ０１、ＳＤ０２において、図９のＭ９０１の“/content1/0”を“/content2/0”に変更したリクエストを送る。（つまり、クライアントは受信するコンテンツをコンテンツ１からコンテンツ２に切り替えたということである。）ここで、図９で説明したのと同様に、ＳＤ０３で新しく要求されたコンテンツ２の要求頻度を確認し、確認の結果、要求の頻度が高いと判断され、ＳＤ０４で既にコンテンツ２が放送経路で配信中かを確認し、本実施形態では配信中であるとし、ＳＤ０５で、ＳＤ０４で確認された既に配信中の放送経路を示した情報をレスポンスのヘッダに付加して、ＳＤ０６、ＳＤ０７を経由して（“/content2/0”のフラグメントを含む）マルチパート形式のレスポンスメッセージをクライアント１０１に返す。

　ここで、クライアント側プロキシ１０２は、図９で説明したのと同様に、放送経路による配信データを受信するように切替えることが可能であるが、放送経路による配信ではデータ受信並びに受信データの再生に時間が掛かってしまうといった問題がある。例えば、放送経路により配信されるデータの取得においては、逐次流れているデータから先頭のデータを発見するのに時間が掛かってしまうことがある。また、再生時間に合せたリアルタイムのデータの配信を行うような放送経路を利用する場合であれば、デコード開始時の初期バッファリングのために先頭データをクライアントが早く要求したとしても、先頭データだけを高速に受信することができない等の問題がある。そこで、本実施形態１の図１３では、受信するコンテンツの切替を行った際に、クライアント側プロキシ１０２がデコードを開始するために必要な分のデータの量を判断し、既に放送経路でデータが配信されていたとしても、デコード開始に必要な分のデータだけは通信経路でＳＤ０８～ＳＤ１１のステップを繰り返し実行することで受信するようにする。図１３のＳＤ０８～ＳＤ１１の処理を所定の回数繰り返すことにより、先頭データが通信経由で高速に伝送されるため、クライアントが受信（再生、視聴）コンテンツを切り換えた際のデータ待ちが低減されて、クライアント１０１は速やかに再生を開始することができるようになる。

　以上、説明した第１の実施形態の構成により、要求の少ないコンテンツは通信で高速にデータ配信すると共に、多数要求のあるコンテンツは放送経由で一斉配信し通信ネットワークのトラフィックの増大を抑制する。また、コンテンツの切替時には先頭データのみを通信経由で高速伝送することにより、コンテンツ切替時の待ちを低減する。本発明は、ＨＴＴＰによる通信をベースとしており、クライアントからはＨＴＴＰによる１対１通信をしているように見える。

　〔実施形態２〕
　本発明の第２の実施形態は、クライアントとコンテンツサーバ間の通信をＨＴＴＰのプロトコルを用いて行い、ＭＩＭＥマルチパート形式にしたＨＴＴＰメッセージでフラグメント化したコンテンツデータを配信するシステムで、放送網を経由して配信する際に、放送配信の配信時刻をクライアントに対して通知する例について説明する。本実施形態に係るデータ配信システムの全体構成、並びにプロキシ内部の機能ブロック構成については、実施形態１と同様に図１、図２のシステム構成図、機能ブロック図を参照して説明する。

　図１４は、本発明の実施形態２に係るデータ配信システムにおいて、放送配信の開始時刻を利用可能時刻（再生開始可能時刻）とする場合の処理を説明するためのシーケンス図である。

　クライアント１０１は、コンテンツサーバ１０４に見たいコンテンツがある場合、コンテンツサーバ１０４に対してコンテンツ要求のリクエストを配信する（ＳＥ０１）。クライアント１０１から発せられたリクエストは、通信経路でクライアント側プロキシ１０２を経由して、クライアント側プロキシ１０２からコンテツサーバの代理処理を行うサーバ側プロキシ１０３へと伝送される（ＳＥ０２）。サーバ側プロキシ１０３の受信部３０１がリクエストを受信すると、監視部３０３で、同じリクエストを既に受信しているか確認し、図１４では、同一コンテンツに対するリクエストを未だ受信していないため、サーバ側プロキシ１０３の処理部３０５は、受信部３０１で受信したクライアント１０１からのリクエストを送信部３０２よりコンテンツサーバ１０４に送信する（ＳＥ０３）。

　コンテンツサーバ１０４は、クライアント１０１からのリクエストに対応したＭＩＭＥマルチパート形式のコンテンツデータ（メディアセグメント）を含むレスポンスをサーバ側プロキシ１０３に返す（ＳＥ０４）。サーバ側プロキシ１０３の処理部３０５は、通信経路ではなく、所定時刻での放送経路によるレスポンスの配信を選択し、コンテンツサーバ１０４からのレスポンスに、配信する経路情報と時刻情報（配信開始時刻、配信終了時刻）とを付加し、クライアント側プロキシ１０２に送信する（ＳＥ０６）。クライアント側プロキシ１０２は、受信したレスポンスから時刻情報を抽出して、クライアント１０１に対して、利用可能時刻の通知をレスポンスメッセージにて行う（ＳＥ０７）。サーバ側プロキシ１０３は、最初のメディアセグメントのデータをＳＥ０６で配信した後、次のメディアセグメントのデータをコンテンツサーバ１０４に対してリクエストする（ＳＥ０８）。コンテンツサーバ１０４は、ＳＥ０８に対するレスポンスをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージで送信する（ＳＥ０９）。このあと、サーバ側プロキシ１０３は、一つのコンテンツデータを受信完了するまで、ＳＥ０８・ＳＥ０９のステップを繰り返し実行する。

　クライアント１０１は、ＳＥ０７のレスポンスで利用可能時刻の通知を受けた後、指定された利用可能時刻の経過後に、クライアント側プロキシ１０２に対して、再びリクエストを送信する（ＳＥ１０）。

　図１４は、利用可能時刻として、放送経路でのコンテンツデータの配信開始時間を指定する例である。即ち、クライアント側プロキシ１０２では、利用可能時刻を経過後、放送経路でコンテンツデータのフラグメントを格納したレスポンスメッセージを別途受信、合成しながら、クライアント１０１に対してはレスポンスメッセージを返していく。

　配信の開始時刻を過ぎると、クライアント側プロキシ１０２は、放送経路で伝送されてくるメディアセグメントデータを識別し、順次取得する。識別には後述する各ＩＰパケットに付されたＩＰデータキャストアドレスを利用する。そして、受信されたデータをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージに合成する（ＳＥ１５）。

　このとき、放送経由で配信するレスポンスメッセージには、利用前にサーバ側プロキシ１０３での検証が必要であることを示す情報及び、検証に使う識別タグ情報を付して送る。これらについては、図１１及び実施形態１での検証処理の説明で既に詳しく説明している。これらにより、クライアント側プロキシ１０２は、合成されたレスポンスＳＥ１５が有効か否かを検証するためのリクエストをサーバ側プロキシ１０３に対して送信し（ＳＥ１６）、サーバ側プロキシ１０３は有効を示すレスポンスをクライアント側プロキシ１０２に返す（ＳＥ１８）。この検証処理によって、放送経路で送ったコンテンツデータがクライアントで利用されているかをサーバ側プロキシ１０３がモニタでき、配信の中止の判断などに利用することができる。但し、本実施形態では、配信終了時刻を予め指定するので、このモニタの処理は必須ではない。

　クライアント側プロキシ１０２は、ＳＥ１０に対するレスポンスとして、クライアント１０１に通信経路のＳＥ０６で配信された最初のメディアセグメントデータをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージで配信する（ＳＥ１１）。クライアント１０１は、受信したＳＥ１１のレスポンスよりコンテンツデータ（フラグメントのデータ）を抽出し、コンテンツ即ち映像の再生を開始する（ＳＥ１２）。以降、クライアント１０１は、次のメディアセグメントデータをコンテンツサーバ１０４にリクエストする（ＳＥ１３）。

　クライアント側プロキシ１０２は、上記で配信の開始時刻を過ぎた時点から別途メディアセグメントデータの取得を行っているので、クライアント側プロキシ１０２は、クライアント１０１からのリクエスト時点で既に取得、合成しているメディアセグメントデータのレスポンスメッセージをクライアント１０１に配信する（ＳＥ１９）。クライアント１０１は、受信したレスポンスメッセージからコンテンツデータ（フラグメントのデータ）を抽出し、ＳＥ１２の再生に続けて抽出したデータを再生する（ＳＥ２０）。以降、コンテンツ即ち映像の再生が終了するまで、ＳＥ１３からＳＥ２０のステップを繰り返し実行する。但し、既に説明した通り、ＳＥ１３、ＳＥ１９とＳＥ１４からＳＥ１８までの処理とは、同期しない。

　図１５及び図１６は、図１４に示される本発明の実施形態２に係るデータ配信システムの動作において、放送配信の開始時刻を利用可能時刻（再生開始可能時刻）とする場合の処理の際に送受信するＨＴＴＰメッセージを説明するための図である。

　図１５（ａ）のＭＥ０１は、図１４のＳＥ０１、ＳＥ０２、ＳＥ０３、ＳＥ１０のＨＴＴＰリクエストメッセージの一例を示す。図１５（ｂ）のＭＥ０４は、図１４のＳＥ０４、ＳＥ１１のＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。図１５（ｃ）のＭＥ０６は、図１４のＳＥ０６の経路情報と時刻情報が付加されたＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。
X-Alternative-Path: broadcast-ipdatacast
X-Broadcast-Channel: 1
X-Ipdatacast-Address=200.1.1.1
が、実施形態１と同様、放送経路の経路情報を示している。また、
X-Ipdatacast-Starttime: 03:00:00
は放送経路によるデータ配信の開始時刻を、
X-Ipdatacast-Endtime: 04:00:00
は放送経路のよるデータ配信の終了時刻を表すものである。

　図１６（ａ）のＭＥ０７は、図１４のＳＥ０７の利用可能時刻の通知を行うＨＴＴＰレスポンスメッセージの一例を示す。この例では、図１５（ｃ）のＭＥ０６に記録された時刻情報のうち配信開始時刻の値がX-available-time:で利用可能時刻（再生開始可能時刻）として設定されている。図１６（ｂ）のＭＥ０８は、図１４のＳＥ０８、ＳＥ１３のＨＴＴＰリクエストメッセージの一例を示す。図１６（ｃ）のＭＥ０９は、図１４のＳＥ０９、ＳＥ１９のＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。図１６（ｄ）のＭＥ１４は、図１４のＳＥ１４で配信されるＩＰデータキャストによるＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの放送配信データの一例を示し、ここでは図１１のＭ９１０と同一である。図１６（ｅ）のＭＥ１６は、図１４のＳＥ１６の検証のＨＴＴＰリクエストメッセージの一例を示す。図１６（ｆ）のＭＥ１８は、図１４のＳＥ１６の検証のリクエストに対するＳＥ１８のＨＴＴＰレスポンスメッセージの一例を示す。

　次に、利用可能時刻として、放送配信開始時刻でなく、放送配信の終了時刻を設定した場合の例を示す。

　図１７は、本発明の実施形態２に係るデータ配信システムにおいて、放送配信の終了時刻を利用可能時刻（再生開始可能時刻）とする場合の処理を説明するためのシーケンス図である。

　ＳＨ０１からＳＨ０６までの動作は、上記で図１４で説明したＳＥ０１からＳＥ０６までの動作と同じである。そして次に、クライアント側プロキシ１０２は、受信したレスポンスから時刻情報を抽出して、クライアント１０１に対して、利用可能時刻の通知をレスポンスメッセージにて行う（ＳＨ０７）が、ここでは、通知される時刻を配信の終了時刻に設定する。

　サーバ側プロキシ１０３は、最初のメディアセグメントのデータをＳＨ０６で配信した後、次のメディアセグメントのデータをコンテンツサーバ１０４に対してリクエストする（ＳＨ０８）。コンテンツサーバ１０４は、ＳＨ０８に対するレスポンスをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージで送信する（ＳＨ０９）。このあと、サーバ側プロキシ１０３は、一つのコンテンツデータを受信完了するまで、ＳＨ０８・ＳＨ０９のステップを繰り返し実行する。

　クライアント側プロキシ１０２は、配信開始時刻が経過後（図示していない）、放送経路で伝送されてくるＳＨ０９以降のメディアセグメントデータを識別し、順次取得する（ＳＨ１０）。識別には、既に上記で説明した、各ＩＰパケットに付されたＩＰデータキャストアドレスを利用する。そして、受信されたデータを逐次ＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージに合成する（ＳＨ１１）。

　このとき、放送経由で配信するレスポンスメッセージには、既に上記で説明した、利用前にサーバ側プロキシ１０３での検証が必要であることを示す情報及び、検証に使う識別タグ情報を付して送る。これにより、クライアント側プロキシ１０２は、合成されたレスポンスＳＨ１１が有効か否かを検証するためのリクエストをサーバ側プロキシ１０３に送り（ＳＨ１２）、サーバ側プロキシ１０３は有効を示すレスポンスをクライアント側プロキシ１０２に返す（ＳＨ１４）。この検証処理により、放送経路で送ったコンテンツデータがクライアントで利用されているかをサーバ側プロキシ１０３がモニタでき、配信の中止の判断等に利用できる。但し、本実施形態では、配信終了時刻を予め指定するので、このモニタの処理は必須ではない。そして、クライアント側サーバは一つのコンテンツデータを受信完了するまでＳＨ１０～ＳＨ１４のステップを繰り返し実行し、配信の終了時刻（即ちクライアント１０１に通知した利用可能時刻）までに全てのコンテンツデータの取得を完了する。

　クライアント１０１は、ＳＨ０７のレスポンスで利用可能時刻の通知を受けた後、指定された利用可能時刻の経過後に、クライアント側プロキシ１０２に対して、リクエストを配信する（ＳＨ１５）。クライアント側プロキシ１０２は、ＳＨ１５のレスポンスとして、ＳＨ０６でクライアント１０１に通信経路で配信された最初のメディアセグメントデータをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージで配信する（ＳＨ１６）。クライアント１０１は、受信したＳＨ１６のレスポンスよりコンテンツデータ（フラグメントのデータ）を抽出し、再生を開始する（ＳＨ１７）。以降、クライアント１０１は、次のメディアセグメントデータをコンテンツサーバ１０４にリクエストし（ＳＨ１８）、クライアント側プロキシ１０２からレスポンスを受信し（ＳＨ１９）、受信したレスポンスからコンテンツデータを抽出し、ＳＨ１７の再生に続けて抽出したデータを再生する（ＳＨ２０）。これらのレスポンスのデータは、クライアント側プロキシ１０２で、既に利用可能時刻＝配信終了時刻前に得られている。以降、コンテンツの再生が終了するまで、ＳＨ１８からＳＨ２０のステップを繰り返し実行する。

　図１８は、図１７のシーケンス図で示される本発明の実施形態２に係るデータ配信システムの動作において、放送配信の終了時刻を利用可能時刻（再生開始可能時刻）として通知するときのメッセージを説明するための図である。

　図１８（ａ）のＭＨ０７は、図１７のＳＨ０７で利用可能時刻の通知を行うＨＴＴＰレスポンスメッセージの一例を示す。この例では、図１５（ｃ）のＭＥ０６に記録された時刻情報のうち配信終了時刻の値がX-available-time:で利用可能時刻（再生開始可能時刻）として設定されている。

　図１４、図１７は、第１の実施の形態と同様に放送経路でコンテンツデータを配信する場合に、更に、所定の配信時刻を設定して配信するケースを示している。最初の各クライアント１０１のリクエスト（ＳＥ０１、ＳＨ０１）に対しては、利用可能となる時刻を返し（ＳＥ０７、ＳＨ０７）、利用可能時刻後の再リクエスト（ＳＥ１０、ＳＥ１３、ＳＨ１５、ＳＨ１８）に対して、クライアント側プロキシ１０２に既にキャッシュされているマルチパート形式のレスポンスを返す（ＳＥ１１、ＳＥ１９、ＳＨ１６、ＳＨ１９）。

　利用可能時刻として、図１４、図１７の２つの場合がある。

　図１４は、放送配信の開始時刻を利用可能時刻としてクライアント１０１に通知し、クライアント側プロキシ１０２が放送での受信を行いながら、クライアント１０１へ順次レスポンスを返していく場合である。データの配信時刻と再生時刻とが同期されたリアルタイム伝送のＩＰデータキャスト配信の場合などに向いている。

　図１７は、放送配信の終了時刻を利用可能時刻としてクライアント１０１に通知し（即ち、利用可能時刻の時点でクライアント側プロキシ１０２は全てのデータを受信及び検証済である）、クライアント１０１のリクエストに対して順次受信済のデータを格納したレスポンスを返していく場合を示している。ダウンロード完了後に再生可能とするダウンロード型放送配信の場合などに向いている。

　このようにして、本実施形態２のデータ配信システムでは、通信経路、放送経路で連携したコンテンツデータの配信を可能としている。

　〔実施形態３〕
　本発明の第３の実施形態は、クライアントとコンテンツサーバ間の通信をＨＴＴＰのプロトコルを用いて行い、ＭＩＭＥマルチパート形式にしたＨＴＴＰメッセージでフラグメント化したコンテンツデータを配信するシステムで、データ量の多い映像データを放送網経由で配信し、データ量の少ない音声データを通信網で配信する場合の例について説明する。本実施形態に係るデータ配信システムの全体構成、並びにプロキシ内部の機能ブロック構成については、実施形態１と同様に図１、図２のシステム構成図、機能ブロック図を参照して説明する。

　図１９は、本発明の実施形態３に係る、映像データを放送で配信し、音声データを通信で配信する場合の処理を説明するための図である。

　サーバ側プロキシ１０３からクライアント側プロキシ１０２へ、コンテンツデータのうち映像データについては、放送経路を使って共通に送り、音声データのみを通信で個別に送る。多言語コンテンツの配信などを想定している。

　このため、メディアセグメントを構成するフラグメントは、同一時刻の映像データを格納したフラグメントfragment1-XXvと、音声データを格納したフラグメントfragment1-XXaとで構成される（ＳＪ１０、ＳＪ２３など）。

　図１９は、既に同じコンテンツの要求があり、コンテンツを構成する映像データが既に放送経由で配信されていて、かつ、クライアント１０１が、要求済みでない日本語（ja）の音声データを含むコンテンツを新たに要求した場合のシーケンスを図示した例である。ＳＪ０３で、既に映像データが放送経路で配信中であることを確認する。更にＳＪ０４では、要求された日本語（ja）音声データが受信済かを確認し、未受信のため、サーバ側プロキシ１０３がコンテンツサーバ１０４に音声データをリクエストする（ＳＪ０５）。コンテンツサーバ１０４は、サーバ側プロキシ１０３に対して音声データをＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージにして配信する。サーバ側プロキシ１０３は、コンテンツサーバ１０４から受信したレスポンスメッセージより、音声データを抽出し、キャッシュ済みの映像データと合成したＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージを形成し（ＳＪ０７）、このメッセージに経路情報を付加する（ＳＪ０８）。サーバ側プロキシ１０３は、経路情報を付加したＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージをクライアント側プロキシ１０２に配信する（ＳＪ０９）。

　第１の実施の形態と同様に、ＳＪ０８でコンテンツデータを配信する放送経路の情報をサーバ側プロキシ１０３からクライアント側プロキシ１０２に送るレスポンスメッセージのヘッダに付加するが、本実施の形態では、放送経路で映像データのみを配信することを示す情報（X-Alternative-Path: broadcast-ipdatacast; video-only）が付される。

　映像データについては、前の実施の形態と同様に放送経路で取得され（ＳＪ１３）、メッセージの形式に復元され（ＳＪ１４）、検証される（ＳＪ１５、ＳＪ１７）。このため、映像データには検証のための情報（ETag: “abcde”、Cache-Control: proxy-revalidate）が付されて伝送される。

　音声データについては、個別にリクエストを出し（ＳＪ１８）、レスポンスを受け取る（ＳＪ２１）。そして、検証済の映像データと併せたマルチパート形式のレスポンスメッセージをクライアント側プロキシ１０２で形成し（ＳＪ２２）、クライアント１０１へ送る（ＳＪ２３）。クライアント１０１はこれを再生する（ＳＪ２４）。

　このように、本実施の形態のデータ配信システムでは、個別に送る必要のあるデータ（本実施の形態では音声データ）のみを通信経由で送り、共通のデータ（本実施の形態では映像データ）は放送経由で一斉配信することにより、通信帯域を圧迫しない最適なコンテンツ配信が実現できる。尚、本実施の形態では映像データと音声データとを例に挙げたが、本形式で配信可能なデータの組合せはこれに限らない。例えば、映像、音声を含むコンテンツデータを共通のデータとして放送経由で配信し、字幕データのみを通信で配信する、といったケースもあり得る。

　図２０、図２１、図２２は、本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に配信するＨＴＴＰメッセージを説明するための図である。

　図２０（ａ）のＭＪ０１は、図１９のＳＪ０１、ＳＪ０２のＨＴＴＰリクエストメッセージの一例を示す。図２０（ｂ）のＭＪ０５は、図１９のＳＪ０５の音声データをリクエストするためのＨＴＴＰリクエストメッセージの一例を示す。図２０（ｃ）のＭＪ０６は、図１９のＳＪ０６のＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。

　図２１（ａ）のＭＪ０９は、図１９のＳＪ０９の経路情報を付加したＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。

　図２２（ａ）のＭＪ１０は、図１９のＳＪ１０のＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。図２２（ｂ）のＭＪ１２は、図１９のＳＪ１２の次のメディアセグメントをリクエストするためのＨＴＴＰリクエストメッセージの一例を示す。

　図２３は、本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に放送経路から配信するレスポンスを説明するための図である。

　図２３のＳＪ１３では、ＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージをＩＰパケット化したデータＭＪ１３を形成し、ＩＰデータキャストによる放送配信をしている。図１１は、配信しようとするＨＴＴＰメッセージとＩＰパケット化して形成される放送配信データＭＪ１３との関係を示している。ＩＰパケットは、ＩＰデータキャストアドレスが格納されるヘッダ部分と転送したいデータ本体を格納するペイロードデータで構成されている。ペイロードデータには、レスポンスメッセージを要求した元のリクエストメッセージが指定していたＵＲＩであるリクエストデータＵＲＩ、配信しようとするＨＴＴＰレスポンスメッセージのヘッダ部のデータ、並びに、メッセージのデータ部の各フラグメントのデータが各々、１つまたは複数のＩＰパケットに分割されて格納されている。フラグメントデータは、メディアセグメント分だけのデータが格納されている。また、フラグメントデータ毎にＩＰパケットが分れて格納されていることで、放送配信中に一部のデータが失われた場合でも、失われたデータに対応するフラグメントデータ以外のデータを復元して、コンテンツを再生可能とできるといった利点がある。

　図２４は、本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の処理の際に配信するＨＴＴＰメッセージを説明するための図である。

　図２４（ａ）のＭＪ１５は、図１９のＳＪ１５の検証のためのＨＴＴＰリクエストメッセージの一例を示す。図２４（ｂ）のＭＪ１７は、図１９のＳＪ１７の検証のためのＨＴＴＰレスポンスメッセージの一例を示す。図２４（ｃ）のＭＪ１８は、図１９のＳＪ１８、ＳＪ１９の次のメディアセグメントの音声データをリクエストするためのＨＴＴＰリクエストメッセージの一例を示す。図２４（ｄ）のＭＪ２０は、図１９のＳＪ２０、ＳＪ２１のＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。

　図２５は、本発明の実施形態３に係る映像データを放送で配信し、音声データを通信で配信する場合の合成処理後に配信するＨＴＴＰメッセージを説明するための図である。

　図２５（ａ）のＭＪ２３は、図１９でクライアント側プロキシ１０２から、クライアント１０１にＳＪ２３のレスポンスで配信するＭＩＭＥマルチパート形式のＨＴＴＰレスポンスメッセージの一例を示す。このレスポンスのデータには、図１９のＳＪ２３の放送経路からで受信した映像データと通信経路から受信した音声データをＳＪ２２で合成したデータが記載されている。

　〔実施形態４〕
　本発明の第４の実施形態は、クライアント側のプロキシに複数のクライアントが繋がる場合について説明する。クライアントとコンテンツサーバ間の通信をＨＴＴＰのプロトコルを用いて行い、ＭＩＭＥマルチパート形式にしたＨＴＴＰメッセージでフラグメント化したコンテンツデータ（メディアフラグメント単位）を配信するシステムで、データ量の多い映像データを放送経路で配信し、データ量の少ない音声データを通信経路で配信する。

　図２６は、本発明の実施形態４に係るクライアント側プロキシ１０５に複数のクライアントが繋がる場合の機能ブロック図である。

　クライアント側プロキシ１０５にクライアントが複数繋がるケースでは、クライアント側プロキシ１０５も監視部２６０１を備え、キャッシュ管理する。既に受信済のリクエストに対しては、コンテンツサーバにリクエストせずに、既にキャッシュされたレスポンスをクライアント側プロキシ１０５が代理応答する。

　〔実施形態５〕
　以上、第１から第４までの実施形態では、クライアントの装置としてテレビ受像機を想定し、通信網及び放送網経由でコンテンツデータを配信することを想定してきた。一方、昨今では、携帯電話等のモバイル機器についても、ワンセグをはじめとするテレビ放送受信機能が搭載されてきており、これらについてもテレビ受像機同様に本発明を適用可能な（通信網及び放送網経由でコンテンツデータを受信可能な）クライアント装置と捉えることが可能である。

　更に、携帯電話等モバイル環境の通信網において放送と同様の一斉配信を実現する方式として、通信網でのマルチキャスト配信がある。３ＧＰＰ（Third Generation Partnership Project）で規定されているＭＢＭＳ（Multimedia Broadcast and Multicast Service）はその１つであり、無線アクセス通信網上で放送に類したデータの一斉配信を行うものである。

　ＭＢＭＳは多数の端末に一斉に同報配信するには高効率な方式であると言える。しかし、端末数が少ない場合には、必ずしも効率が良いとは言えない。すなわち、受信する携帯電話・モバイル機器（クライアント）数が少なければ、ユニキャスト配信で各端末に配信するほうが高速にデータ配信を完了することができ、効率的であることがある。しかし、そのような場合でも、従来、配信側では接続の状況が判らないため、予め接続される端末数を見込んでユニキャスト配信するか、ＭＢＭＳ配信するかを配信側で決め、配信していた。すなわち、見込みが誤っていたような場合には、効率の低いコンテンツ配信が行われていた。

　そこで、本実施形態では、上記実施形態１から４で説明した通信網と放送網経由での切替配信の制御を、無線アクセス通信網におけるユニキャスト配信とＭＢＭＳマルチキャスト配信との切替配信の制御に拡張する。

　図２７は、本実施形態５に係るモバイル機器の無線アクセス通信網を使ったデータ配信システムの全体構成を表したシステム構成図である。

　本データ配信システムでは、コンテンツサーバ１０４には、コアネットワークに対して複数の無線アクセスネットワークＲＡＮ（Radio Access Network）：ＲＡＮ－１～ｍがプロキシ１０８を介して接続され、このＲＡＮ－１～ｍのそれぞれに複数のクライアント装置（携帯電話、モバイル機器）が接続する構成となっている。コンテンツサーバ１０４及びサーバ側プロキシ１０８はコアネットワークを構成するノードである。また、クライアント装置（携帯電話、モバイル機器）は、クライアント自体（クライアントアプリなどを指す）１０６－１～ｎとプロキシ１０７－１～ｎとが内蔵されて構成されている。

　クライアント装置はモバイル機器なので、利用時にはＲＡＮに接続し、利用が無ければ接続を切る。すなわち、ＲＡＮのそれぞれについて、ある時点、時点で接続されているクライアント装置の数は可変となる。また、クライアント装置があるＲＡＮから異なるＲＡＮに移った場合にも、接続されているクライアント装置の数は変化する。

　このため、ある時点でクライアント装置が多数接続されているＲＡＮに対しては、ＭＢＭＳで配信して一斉にコンテンツデータを送る方が効率が良く、一方、ある時点で接続されているクライアント装置の数が少ないＲＡＮでは、各クライアント装置毎にユニキャスト配信したほうが効率が良い、といったことが起こり得る。

　そこで、本実施形態のデータ配信システム内のサーバ側プロキシ１０８は、自身に接続されている各ＲＡＮの接続状況（接続中のクライアントの数）をモニタして、各ＲＡＮにデータ配信する配信モードをＨＴＴＰよるユニキャストモードで配信するか、ＭＢＭＳによるマルチキャストモードで配信するかを判断して切り替える。つまり、本実施形態では、配信先の候補となり得る接続中のクライアント数が多いＲＡＮからは、リクエストが集中すると考えられるので、このようなＲＡＮに対してはマルチキャストモードで配信する。一方、配信先の候補となり得る接続中のクライアント数が少ないＲＡＮからは、さほどリクエストが集中するとは考えられないので、このようなＲＡＮに対してはユニキャストモードで配信する。そして、接続中のクライアント数の増減に応じてこれらのモードを適応的に切り替える。なお、クライアント数が多いか少ないかは、予め基準となるしきい値を設定しておき、検出した接続中のクライアント数が、このしきい値を超えるか否かによって判断することができる。このような配信モードの切り替えは、実施形態１から４で説明した、通信経路から放送経路への切替えと同様の仕組みで行う。

　すなわち、接続状況のモニタリングの結果、あるＲＡＮ内の配信をユニキャストモードからマルチキャストモードに切り替えると判定された場合に、サーバ側プロキシ１０８は、ＭＢＭＳ配信の経路情報をＨＴＴＰレスポンスメッセージのヘッダに付けて該当のＲＡＮ内のクライアント装置１０６にクライアント側プロキシ１０７経由で送り、それ以降のコンテンツデータについてＭＢＭＳ配信を開始する。

　図２８に、ＭＢＭＳによるマルチキャスト配信に切り替える直前時点での、サーバ側プロキシ１０８からクライアント側プロキシ１０７に配信するＭＩＭＥマルチパート形式にしたＨＴＴＰメッセージレスポンスメッセージの一例を示す。これは、実施形態１で通信網から放送網に切替える直前時点で配信するＭ９０６に対応するものであり、放送経路の代わりに、ＭＢＭＳマルチキャスト配信の経路情報を示すヘッダ、X-Alternative-Path:・・・・・中略・・・・・session_name=multicast_content1が付されている。詳細は、図２８（ａ）ＭＲ０１を参照のこと。それ以降の動作は実施形態１等で説明したのと同様である。

　以上、本実施形態に係るモバイルアクセス通信網を使ったデータ通信システムでは、各ＲＡＮのクライアント装置の接続状態から、データ配信方式をユニキャスト、マルチキャストに適宜切替えることで、最適なコンテンツ配信を実現する。ここでクライアント装置は携帯電話やモバイル機器を想定している。

　尚、本実施形態の上記説明では、サーバ側プロキシ１０８に繋がったＲＡＮを複数あるとし、これらを別個のもの、例えば物理的に違った位置に設置されている基地局を基点として形成されるＲＡＮ等として説明したが、１つのＲＡＮに繋がっているクライアント装置をそれぞれの要求の状態に合せて複数のグループにグルーピングし、それら各グループから仮想的に複数のＲＡＮが形成されるとして、本実施形態を適用することも可能である。

　本発明の実施形態の説明では、ムービーフラグメントを１秒、メディアセグメントを１０秒として説明してきたが、ムービーフラグメントの期間の長さは１秒に限られないし、また、メディアセグメントの期間の長さは１０秒に限られない。すなわち、例えば、ムービーフラグメントの期間の長さをMPEG-4の符号化の単位であるＧＯＰ（Group of Picture）に合せて0.5秒としてもよいし、2秒等の長いものにすることも可能である。また、コンテンツサーバ１０４は、メディアセグメントの期間の長さを、ＨＴＴＰメッセージの発生頻度に応じてユーザが設定した長さに適宜変更可能な構成となっていてもよい。すなわち、目的や状況に応じて、ユーザはメディアセグメントの期間の長さを３０秒あるいは１分等としてリクエストメッセージおよびレスポンスメッセージの発生頻度を抑えるようにすることもできるし、あるいは、頻繁に切替えが発生するような場合には５秒等にしてレスポンスを早くするようにしてもよい。更に、ムービーフラグメントの長さを可変にしたり、メディアセグメントの長さを可変にすることも可能である。

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

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

　（まとめ）
　以上のように、従来は、ストリーミングによる一斉配信では、同一のメッセージが通信ネットワーク上を流れ、トラフィック増大の問題があった。また、放送経路と通信経路を同じ仕組みで利用し、異なる経路で受信したデータを簡単に繋ぐ、更には、データを連携・同期するための仕組みがなかった。

　そこで、上述のデータ配信システムでは、ＭＩＭＥマルチパート形式によるＨＴＴＰでコンテンツデータをメディアセグメント単位で配信するという前提の下、サーバ側プロキシでは、同一リクエストの発生頻度等に応じて、放送経路と通信経路を用いて、適応的なフラグメント分割配信を行う。また、クライアント側プロキシでは、通信経路のレスポンスメッセージに続き、適応的に配信される通信経路からのデータと放送経路からのデータの情報（経路識別、同期情報）のマージ処理を行う。さらに、放送による配信中に他のコンテンツ要求を行った場合には、コンテンツ切替え直後の先頭データのみ通信経由で高速伝送する。これにより、上記従来の課題が解決される。

　（本発明の好ましい形態）
　本発明に係るデータ配信システムは、複数のコンテンツデータを、所定の形式によりメディアセグメント単位で配信するデータ配信装置と、前記データ配信装置と通信網と放送網とに接続され、前記データ配信装置から配信された前記コンテンツデータを前記放送網及び前記通信網の少なくとも何れかを介して配信する配信側データ中継装置と、前記通信網と前記放送網とに接続され、前記配信側データ中継装置から配信される前記コンテンツデータを受信端末装置に配信する受信側データ中継装置と、前記受信側データ中継装置から配信される前記コンテンツデータを受信可能な受信端末装置とを有するデータ配信システムであって、前記配信側データ中継装置は、受信端末装置からのデータ要求に応じて、前記放送網と前記通信網に適応的に分割配信することを特徴としており、前記所定の形式は、ＨＴＴＰであることが好ましい。

　また、本発明にかかる配信側データ中継装置は、コンテンツを第１の配信経路で配信する第１送信手段と、コンテンツを前記第１の配信経路とは異なる第２の配信経路で配信する第２送信手段と、受信端末装置が要求するコンテンツを、前記第１送信手段および前記第２送信手段の何れを用いて配信するかを選択する選択手段と、を備えることを特徴としており、前記第１の配信経路は放送網を介した通信経路であり、前記第２の配信経路は通信網を介した通信経路であり、前記通信網のトラフィックが大きい場合に生じる所定の事象の発生を検出する検出手段を更に備え、前記選択手段は、前記検出手段が前記事象の発生を検出している場合に、当該コンテンツを前記第１送信手段で配信することを選択することが好ましい。

　上記構成によれば、通信網のトラフィックが大きいときに、コンテンツを放送網で送信することができるため、通信網のトラフィックの増大を抑えることができる。

　また、前記配信側データ中継装置は、前記第１の配信経路は放送網を介した通信経路であり、前記第２の配信経路は通信網を介した通信経路であり、前記選択手段は、前記コンテンツを前記第１送信手段で配信することを選択した場合、放送網から当該コンテンツを取得するための情報を付加して、当該コンテンツを前記第１送信手段で配信することが好ましい。

　上記構成によれば、放送網からコンテンツを取得するための情報を付加して、当該コンテンツを放送網で配信する。これにより、受信端末装置は、放送網から前記情報を取得して、当該コンテンツを取得することができる。

　また、前記配信側データ中継装置の前記選択手段は、前記コンテンツを前記第１送信手段で配信することを選択した場合、当該コンテンツの有効性の検証を自装置に対して要求することが必要であることを示す情報を付加して、当該コンテンツを前記第１送信手段で配信し、前記第１送信手段による配信の後、自装置に対する検証の要求の受信状況に応じて、前記第１送信手段による配信を中止することが好ましい。

　上記構成によれば、第１送信手段で配信したコンテンツの有効性が検証できる。また、コンテンツの検証の要求の受信状況に応じて第１送信手段による配信を中止するので、例えば検証の要求が一定時間以上受信されておらず、放送網によるコンテンツの取得が行われていない可能性が高いような場合に、放送網による配信を中止することができる。

　また、前記コンテンツが複数のセグメントに分割されている場合、前記選択手段は、前記複数のセグメントのうち、一部のセグメントを前記第１送信手段で配信し、他のセグメントを前記第２送信手段で配信することを選択してもよい。

　上記構成によれば、第１、第２の配信経路のそれぞれの特性を生かして、１つのコンテンツを配信することが可能になる。例えば、第１の配信経路は通信速度が遅いが多量のデータ送信に適し、第２の配信経路は通信速度が速いが多量のデータを送信するには適さないような場合が考えられる。上記構成によれば、このような場合に、複数のセグメントのうち、データサイズが小さいものや早期に送信すべきセグメントを第２送信手段で配信し、データサイズが大きいセグメントは第１送信手段で送信することも可能である。

　また、前記第１の配信経路は、コンテンツをマルチキャストする通信経路であり、前記第２の配信経路は、コンテンツをユニキャストする通信経路であってもよく、この場合、前記選択手段は、前記コンテンツの配信先の候補となる前記受信端末装置の数が所定のしきい値を超えている場合には、前記コンテンツを前記第１送信手段で配信することを選択し、前記しきい値以下の場合には、前記コンテンツを前記第２送信手段で配信することが好ましい。

　上記構成によれば、コンテンツの配信先が所定のしきい値以下であり、配信要求が比較的少ないことが予想される場合には、コンテンツをユニキャストする。また、コンテンツの配信先が所定のしきい値を超えており、配信要求の大量受信が見込まれる場合には、コンテンツをマルチキャストする。したがって、状況に応じた適切な通信経路でのコンテンツの配信が可能になる。

　また、本発明にかかる受信側データ中継装置は、第１の配信経路で配信されたコンテンツを受信する第１受信手段と、前記第１の配信経路とは異なる第２の配信経路により、前記第１の配信経路とは異なる送信データ形式で配信されたコンテンツを受信する第２受信手段と、前記第１受信手段および前記第２受信手段の何れで受信したコンテンツについても、同一の送信データ形式で前記受信端末装置に送信する形式統一手段とを備えており、前記コンテンツが複数のセグメントに分割されている場合、前記形式統一手段は、前記複数のセグメントのうち、一部のセグメントを前記第１受信手段で受信し、他のセグメントを前記第２受信手段で受信した場合、受信した各セグメントの送信データ形式を統一すると共に、１つのコンテンツに合成して前記受信端末装置に送信することが好ましい。

　上記構成によれば、複数のセグメントを第１受信手段と第２受信手段とで受信した場合であっても、受信した各セグメントの送信データ形式を統一すると共に、１つのコンテンツに合成する。これにより、受信端末装置は、当該コンテンツを構成する各セグメントが異なる経路及びデータ形式で配信されたことを意識することなく、当該コンテンツを1つのコンテンツとして利用することができる。

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

　本発明にかかるデータ配信システム及びデータ配信方法は、マルチメディアデータ配信技術、より詳細には、データ伝送プロトコルによる通信、放送連携配信に適した効率的なマルチメディアデータ配信に適用可能である。

　１０１－１～１０１－ｎ、１０６－１～１０６－ｎ　クライアント（受信端末装置）
　１０２、１０２－１～１０２－ｎ　クライアント側プロキシ（受信側データ中継装置）
　１０５、１０７－１～１０７－ｎ　クライアント側プロキシ（受信側データ中継装置）
　１０３、１０８　サーバ側プロキシ（配信側データ中継装置）
　１０４　コンテンツサーバ（データ配信装置）
　２０１　受信部
　２０３　受信部（第２受信手段）
　２０４　受信部（第１受信手段）
　３０１、３０４　受信部
　２０２、２０７　送信部
　３０２　送信部
　３０７　送信部（第２送信手段）
　３０８　送信部（第１送信手段）
　３０３　、２６０１　監視部
　２０５　処理部（形式統一手段）
　３０５、２６０２　処理部（選択手段）
　２０６、３０６　キャッシュ部
　ＲＡＮ－1～ＲＡＮ－ｍ　無線アクセスネットワーク

Claims

　複数のコンテンツデータを、所定の形式によりメディアセグメント単位で配信するデータ配信装置と、
　前記データ配信装置と通信網と放送網とに接続され、前記データ配信装置から配信された前記コンテンツデータを前記放送網及び前記通信網の少なくとも何れかを介して配信する配信側データ中継装置と、
　前記通信網と前記放送網とに接続され、前記配信側データ中継装置から配信される前記コンテンツデータを受信端末装置に配信する受信側データ中継装置と、
　前記受信側データ中継装置から配信される前記コンテンツデータを受信可能な受信端末装置とを有するデータ配信システムであって、
　前記配信側データ中継装置は、受信端末装置からのデータ要求に応じて、前記放送網と前記通信網に適応的に分割配信することを特徴とするデータ配信システム。
　複数のコンテンツデータを、所定の形式によりメディアセグメント単位で配信するデータ配信ステップと、
　前記データ配信ステップによって配信された前記コンテンツデータを放送網及び通信網の少なくとも何れかを介して配信する配信側データ中継ステップと、
　前記配信側データ中継ステップによって前記通信網及び前記放送網の少なくとも何れかを介して配信される前記コンテンツデータを配信する受信側データ中継ステップと、
　前記受信側データ中継ステップによって配信される前記コンテンツデータを受信する受信ステップとを含むデータ配信方法であって、
　前記配信側データ中継ステップでは、データ要求に応じて、前記放送網と前記通信網に適応的に分割配信することを特徴とするデータ配信方法。
　前記所定の形式は、ＨＴＴＰであることを特徴とする請求項１記載のデータ配信システム。
　コンテンツをデータ配信装置から受信端末装置にネットワーク経由で配信するデータ配信システムにおいて、前記受信端末装置の要求するコンテンツを前記データ配信装置から受信して前記受信端末装置に配信する配信側データ中継装置であって、
　前記コンテンツを第１の配信経路で配信する第１送信手段と、
　前記コンテンツを前記第１の配信経路とは異なる第２の配信経路で配信する第２送信手段と、
　前記受信端末装置が要求する前記コンテンツを、前記第１送信手段および前記第２送信手段の何れを用いて配信するかを選択する選択手段と、を備えることを特徴とする配信側データ中継装置。
　前記第１の配信経路は放送網を介した通信経路であり、前記第２の配信経路は通信網を介した通信経路であり、
　前記通信網のトラフィックが大きい場合に生じる所定の事象の発生を検出する検出手段を更に備え、
　前記選択手段は、前記検出手段が前記事象の発生を検出している場合に、当該コンテンツを前記第１送信手段で配信することを選択することを特徴とする請求項４に記載の配信側データ中継装置。
　前記第１の配信経路は放送網を介した通信経路であり、前記第２の配信経路は通信網を介した通信経路であり、
　前記選択手段は、前記コンテンツを前記第１送信手段で配信することを選択した場合、放送網から当該コンテンツを取得するための情報を付加して、当該コンテンツを前記第１送信手段で配信することを特徴とする請求項４または５に記載の配信側データ中継装置。
　前記選択手段は、前記コンテンツを前記第１送信手段で配信することを選択した場合、当該コンテンツの有効性の検証を自装置に対して要求することが必要であることを示す情報を付加して、当該コンテンツを前記第１送信手段で配信し、
　前記第１送信手段による配信の後、自装置に対する検証の要求の受信状況に応じて、前記第１送信手段による配信を中止することを特徴とする請求項５または６に記載の配信側データ中継装置。
　前記コンテンツは複数のセグメントに分割されており、
　前記選択手段は、前記複数のセグメントのうち、一部のセグメントを前記第１送信手段で配信し、他のセグメントを前記第２送信手段で配信することを選択することを特徴とする請求項４から７の何れか１項に記載の配信側データ中継装置。
　前記第１の配信経路は、コンテンツをマルチキャストする通信経路であり、前記第２の配信経路は、コンテンツをユニキャストする通信経路であり、
　前記選択手段は、前記コンテンツの配信先の候補となる前記受信端末装置の数が所定のしきい値を超えている場合には、前記コンテンツを前記第１送信手段で配信することを選択し、前記しきい値以下の場合には、前記コンテンツを前記第２送信手段で配信することを選択することを特徴とする請求項４に記載の配信側データ中継装置。
　コンテンツをデータ配信装置から受信端末装置にネットワーク経由で配信するデータ配信システムにおいて、配信された前記コンテンツを受信して前記受信端末装置に送信する受信側データ中継装置であって、
　第１の配信経路で配信された前記コンテンツを受信する第１受信手段と、
　前記第１の配信経路とは異なる第２の配信経路により、前記第１の配信経路とは異なる送信データ形式で配信された前記コンテンツを受信する第２受信手段と、
　前記第１受信手段および前記第２受信手段の何れで受信したコンテンツについても、同一の送信データ形式で前記受信端末装置に送信する形式統一手段と、を備えることを特徴とする受信側データ中継装置。
　前記コンテンツは複数のセグメントに分割されており、
　前記形式統一手段は、前記複数のセグメントのうち、一部のセグメントを前記第１受信手段で受信し、他のセグメントを前記第２受信手段で受信した場合、受信した各セグメントの送信データ形式を統一すると共に、１つのコンテンツに合成して前記受信端末装置に送信することを特徴とする請求項１０に記載の受信側データ中継装置。