JP6155142B2 - 配信支援サーバ - Google Patents

Description

本発明は、配信支援サーバに関するものである。

近年インターネットにおいては、ストリーミングによる動画配信サービスが普及している。また、受信端末において視聴したいコンテンツを選択し、配信サーバより選択したコンテンツを受信するＶＯＤ（Video On Demand）のような一対一の配信サービスに加え、同一のコンテンツを多数の受信端末に同時に伝送する一対多（放送型）の配信サービスが知られている。

さらに、ＩＰネットワークにおいて、放送型の動画配信サービスを効率よく行う方式として、ＩＰマルチキャストが知られている。しかし、このＩＰマルチキャスト方式では、通信事業者の専用ネットワークが必要であり、複数事業者を跨いだサービスが困難であった。

こうした背景から、通信事業者の専用のネットワークを必要とせずに、複数事業者を跨いだ放送型の動画配信サービスを可能とするため、ピアツーピア技術を用いたコンテンツの分散配信技術が考案された。こうした技術は、コンテンツを要求する端末同士で論理的なツリーを作り、端末上で動作するアプリケーションソフトが相互にデータ転送を行うことによりマルチキャスト（一対多通信）を実現する（例えば、特許文献１参照）。

特許文献１に記載のストリームデータ分散配信方法では、インターネット等のネットワーク環境において、各ノード間でストリームデータの送受信を行うために、各ノードは、上流ノードと下流ノードとの接続関係を示すトポロジ情報を交換して、上流ノードから下流ノードへストリームデータを中継している。このストリームデータ分散配信方法では、各ノード間でトポロジ情報を交換するために、各ノードが自律的にトポロジ情報を記憶及び更新し、さらに提供する等の管理を行う機能を備えている。

また、このようなコンテンツ配信方式の別の例として、配信サーバにおいて、ストリーミングメディアを複数のデータパケットに断片化し（断片化されたデータをチャンクと呼ぶ）、各端末は必要なチャンクを持つ端末を動的に検出し、検出した端末から、プル型でチャンクを受信し、受信したチャンクを再構成することにより、所望のストリーミングメディアを得る技術が知られている（例えば、非特許文献１参照）。

図９は、コンテンツ配信システムの一例を示す図である。図９に示す例では、配信サーバによって１〜６の６個に断片化したチャンクのうち、奇数番号のチャンクが実線に沿って、偶数番号のチャンクが破線に沿ってそれぞれ転送されることで、図示する６台の各端末（利用者端末）に対して、全てのチャンクが行き届いている様子を示している。このようなＰ２Ｐネットワークによるコンテンツ配信システムは、配信サーバから送出されるコンテンツを端末（Ｐ２Ｐ端末）が次々と中継していくことによって、配信サーバの負荷を軽減することが可能となり、低コストで大規模な配信を実現する方式として期待されている（以後、「Ｐ２Ｐ配信」と呼ぶ）。

ところが、このようなＰ２Ｐネットワークに参加するためには、端末においてピアツーピア機能を実装したアプリケーションソフトを動作させる必要がある。そのため、アプリケーションソフトを動作させることが困難な端末（スマートフォンやタブレット端末、スマートテレビなど）や、このようなソフトを利用したくないユーザの端末は、Ｐ２Ｐネットワークに参加してコンテンツを受信することができなかった。

ところで、昨今の動画配信では、専用のサーバと専用のプロトコルによるストリーミング配信方式から、汎用的なＷｅｂサーバによりＨＴＴＰプロトコルを用いてストリーミング配信する方式への移行が進んでおり、多くのデバイス向けの配信において主流となっている。このようなＨＴＴＰプロトコルによるストリーミング配信方式（アダプティブストリーミング）としては、ＩＴベンダによる独自技術が普及している他、これらストリーミング方式の統一を意図した国際標準規格の策定が進んでいる（例えば、非特許文献２参照）。いずれの技術も基本的なコンセプトは同様であり、Ｗｅｂサーバには動画コンテンツを数秒から数十秒程度のファイルに分割したもの（セグメント化データ）と、それらの動画コンテンツの属性やＵＲＬを記述したマニフェストファイルを用意し、端末はマニフェストファイルのＵＲＬに従って次々とセグメント化データを受信し、１本の動画コンテンツにつなぎ合わせて再生するものである。

ＨＴＴＰプロトコルによるストリーミング配信方式では、セグメント化データが順次生成される（例えば、非特許文献３参照）。図１０は、ＨＴＴＰプロトコルによるストリーミング配信方式の概念を示す図である。図１０では、ライブエンコーダでエンコードされたコンテンツが時間の進行に合わせて分割され１〜６のセグメント化データが順次生成されている。マニフェストも同様に、セグメント化データが生成されるのに合わせて内容が更新されている（一番左のマニフェストファイルには１〜３のセグメント化データのＵＲＬが登録されており、次のマニフェストファイルには２〜４のセグメント化データのＵＲＬが登録されているように、順次登録されているセグメント化データのＵＲＬが一定個数ずつスライドしている）。セグメント化データ及びマニフェストは順次Ｗｅｂサーバに供給されている。受信端末は、Ｗｅｂサーバからマニフェストファイルを受信し、マニフェストファイルに登録されているセグメント化データを順次ＨＴＴＰプロトコルにより受信する。また、更新されたマニフェストファイルを受信し、新規に登録されたセグメント化データを受信する処理を繰り返すことにより一連のコンテンツを受信することができる（以後、「ＨＴＴＰ配信」と呼ぶ）。

こうした状況から、Ｐ２Ｐ配信とＨＴＴＰ配信を併用し、Ｐ２Ｐネットワークに参加可能な端末（Ｐ２Ｐ端末）へはＰ２Ｐ配信を行い、Ｐ２Ｐネットワークに参加不可能な端末（Ｐ２Ｐ非対応端末）に対しては、コンテンツ配信網（ＣＤＮ：Contents Delivery Network）を利用してＨＴＴＰ配信を行っていた。図１１に、このような配信方式の一例を示す。

ＨＴＴＰ配信は、多くの端末やネットワーク環境において受信が可能である一方で、各端末がコンテンツ配信網に設置されたＷｅｂサーバから個別にコンテンツを受信するため、端末数に応じて配信コストが増大するといった問題があった。そこで、こうした問題に対して、端末装置がオーバーレイネットワークに参加することなく、オーバーレイネットワークで配信されるコンテンツを効率良く取得することを可能としたサーバ装置、ページ送信プログラム、及びページ送信方法が開示されている（例えば、特許文献２参照）。

特開２００３−１６９０８９号公報 特開２０１２−７８９０１号公報

CoolStreaming/DoNet: A Data-Driven Overlay Network for Efficient Live Media Streaming"、In Proc. Of the 24thIEEE INFOCO, March 2005,ｐ.2102-2111 XinyanZhang, Jiangchuan Liu, Bo Li and Tak-ShingPeter Yum "次世代動画配信技術「ＭＰＥＧ−ＤＡＳＨ」技術概要と標準化・関連技術動向"、映像情報メディア学会誌、Ｖｏｌ.６７、Ｎｏ.２、２０１３、ｐ.１０９−１１５

特許文献２に記載の技術によれば、サーバ装置は、第１の端末装置（Ｐ２Ｐ非対応端末）からリクエストされたコンテンツの検索結果に基づいて、Ｗｅｂページに記述する所在情報であって、オーバーレイネットワーク（Ｐ２Ｐネットワーク）を構成する情報処理装置（Ｐ２Ｐ端末）の所在を示す前記所在情報を決定する。そして、サーバ装置は、決定した所在情報が記述されるＷｅｂページを第１の端末装置へ送信することにより、端末装置がオーバーレイネットワークに参加することなく、オーバーレイネットワークで配信されるコンテンツを取得することを可能としている。

しかしながら、オーバーレイネットワークに参加する情報処理装置が一般利用者の端末であった場合、情報処理装置がいつ視聴を終了してオーバーレイネットワークから離脱するかは分からない。そのため第１の端末装置が、サーバ装置から受信したＷｅｂページに記載されている所在情報に基づいてコンテンツのリクエストをおこなっても、当該所在情報に該当する情報処理装置が既にオーバーレイネットワークから離脱してしまった場合、コンテンツを取得できず安定に視聴できないという問題があった。

また、一般家庭や企業のＰＣ（情報処理装置／Ｐ２Ｐ端末）は、ＮＡＴ（Network Address Translation）ルータを介してインターネットに接続していることが多い。このような情報処理装置は、自身から接続要求を行ってインターネット上の他のＰＣやサーバと接続を確立して通信を行うことができる一方で、インターネット上の他のＰＣやサーバからの接続要求はＮＡＴルータで遮られてしまうため、受付けることができず接続が確立できない。特許文献２はこの点を考慮していない。そのため仮に、情報処理装置がＮＡＴルータを介してインターネットに接続しており、接続要求を受付けることができない場合、第１の端末装置からコンテンツのリクエストを受け付けることができない。その結果、第１の端末装置はコンテンツを取得できず、安定に視聴することができないといった問題があった。

かかる事情に鑑みてなされた本発明の目的は、Ｐ２Ｐ非対応端末に対して、Ｐ２Ｐネットワークで中継されているコンテンツを安定かつ効率的に配信可能とする配信支援サーバを提供することにある。

また、上記課題を解決するため、本発明に係る配信支援サーバは、Ｐ２Ｐネットワークに参加可能な複数のＰ２Ｐ端末と、当該Ｐ２Ｐネットワークに参加不可能なＰ２Ｐ非対応端末と、ＨＴＴＰ配信のＷｅｂサーバとして振る舞う配信支援サーバとを備えるコンテンツ配信システムにおける配信支援サーバであって、当該配信支援サーバが、前記Ｐ２Ｐ非対応端末からコンテンツを分割したセグメント化データのリクエストを受信すると、前記Ｐ２Ｐ端末が他のＰ２Ｐ端末からの接続要求を受付けることが可能か否かを示す到達可否情報、及び前記Ｐ２Ｐ端末の、データチャンクを同時に分配可能な端末数から現在データチャンクを分配している端末数を差し引いた余剰の分配可能端末数を示す余剰分配数に基づいて、複数のＰ２Ｐ端末から前記リクエストの転送先候補端末となるＰ２Ｐ端末を選択し、該Ｐ２Ｐ端末に前記リクエストの転送が可能か否かを確認する転送受付要求を送信するリクエスト転送部と、前記転送先候補端末となるＰ２Ｐ端末から転送受付可能応答を受信した場合には、該Ｐ２Ｐ端末におけるセグメント化データのＵＲＬを含むレスポンスを前記Ｐ２Ｐ非対応端末に送信するＨＴＴＰレスポンス送信部と、を備え、前記リクエスト転送部は、前記到達可否情報が他の端末からの接続要求を受付けることが可能であることを示しているＰ２Ｐ端末のうち、前記余剰分配数が大きいものから優先して、前記リクエストの転送先候補端末となるＰ２Ｐ端末を選択し、前記転送先候補端末が存在しない場合、又は前記転送先候補端末の全てから転送受付不可応答を受信した場合は、転送不可情報を前記ＨＴＴＰレスポンス送信部に出力し、前記ＨＴＴＰレスポンス送信部は、前記リクエスト転送部から前記転送不可情報が入力されると、当該ＨＴＴＰレスポンス送信部から前記セグメント化データを前記Ｐ２Ｐ非対応端末に直接送信することを特徴とする。

本発明によれば、コンテンツ配信システムのＰ２Ｐネットワークに参加していない受信端末が、Ｐ２Ｐネットワークで中継されているコンテンツを受信できるようになるため、コストを削減しつつ、安定かつ効率的なコンテンツ配信が可能となる。

本発明の一実施形態に係るコンテンツ配信システムの構成例を示すブロック図である。 コンテンツ、セグメント化データ、及びデータチャンクの関係の一例を示す図である。 本発明の一実施形態に係るコンテンツ配信システムにおけるＰ２Ｐ端末の構成例を示すブロック図である。 本発明の一実施形態に係るコンテンツ配信システムにおける配信支援サーバの構成例を示すブロック図である。 マニフェストファイルの一例を示す図である。 本発明の一実施形態に係るコンテンツ配信システムにおけるＰ２Ｐ非対応端末の構成例を示すブロック図である。 本発明の一実施形態に係るコンテンツ配信方法の動作を示すシーケンス図である。 ＨＴＴＰリクエスト／ＨＴＴＰレスポンスのメッセージフォーマットの一例を示す図である。 従来のコンテンツ配信システムの一例を示す図である。 従来のＨＴＴＰプロトコルによるストリーミング配信方式の概念を示す図である。 従来のＰ２Ｐ配信とＨＴＴＰ配信を併用した配信方式の一例を示す図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、本発明の一実施形態に係るコンテンツ配信システムの構成例を示すブロック図である。この例では、コンテンツ配信システムは、オリジンサーバ１と、配信サーバ２と、配信支援サーバ３と、複数のＰ２Ｐ端末６と、Ｐ２Ｐ非対応端末７とを備え、それぞれインターネットに接続される。Ｐ２Ｐ端末６−１はポート開放可能ＮＡＴルータ４とのローカルネットワークを介してインターネットに接続され、Ｐ２Ｐ端末６−２はポート開放不可ＮＡＴルータ５とのローカルネットワークを介してインターネットに接続され、Ｐ２Ｐ端末６−３は直接インターネットに接続される。

なお、図１においては、オリジンサーバ１、配信サーバ２、及び配信支援サーバ３を個別のサーバとして表記しているが、一つのサーバに全ての機能を具備してもよい。また、Ｐ２Ｐ非対応端末７はインターネットに直接接続する例を示しているが、ポート開放可能ＮＡＴルータ４又はポート開放不可ＮＡＴルータ５を介してインターネットに接続してもよい。また、説明の便宜上、Ｐ２Ｐ端末６を３つのみとし、Ｐ２Ｐ非対応端末７を１つのみとしている。

ポート開放可能ＮＡＴルータ４は、例えばＵＰｎＰ（Universal Plug and Play）によるポート開放機能に対応しており、ルータの外部（インターネット）からの接続要求をローカルネットワーク内のＰ２Ｐ端末６−１に転送することができるルータである。よって、ポート開放可能ＮＡＴルータ４にローカルネットワークを介して接続しているＰ２Ｐ端末６−１は、インターネットを介して配信サーバ２、配信支援サーバ３、他のＰ２Ｐ端末６−１と、ＴＣＰ／ＩＰなどの通信プロトコルにより相互に接続要求・接続要求の受付けが可能であるとともに（到達可であり）、Ｐ２Ｐ端末６−２及びＰ２Ｐ非対応端末７からの接続要求の受付けが可能であり、接続を確立したうえで、データを送受信することが可能であるものとする。

一方、ポート開放不可ＮＡＴルータ５は、例えばＵＰｎＰによるポート開放機能などに対応していないか、対応していても当該機能を無効にしていることにより、ルータの外部からの接続要求をローカルネットワーク内のＰ２Ｐ端末６−２に転送することができないルータである。よってポート開放不可ＮＡＴルータ５にローカルネットワークを介して接続しているＰ２Ｐ端末６−２は、インターネットを介して配信サーバ２、配信支援サーバ３、及びＰ２Ｐ端末６−１に対して、自身が接続要求行うことで接続を確立し、データを送受信することは可能であるが、それら機器、及びＰ２Ｐ非対応端末７、他のＰ２Ｐ端末６−２からの接続要求を受け付けることはできないものとする。

オリジンサーバ１は、コンテンツの配信元となるサーバであり、コンテンツをセグメント化データに分割するとともに、マニフェストファイルを生成し、配信サーバ２及び配信支援サーバ３に送信する。

配信支援サーバ３は、Ｐ２Ｐ非対応端末７に対してＨＴＴＰ配信によりコンテンツを配信するＷｅｂサーバとして振る舞う。配信支援サーバ３は、オリジンサーバ１からセグメント化データ及びマニフェストファイルを受信し、Ｐ２Ｐ非対応端末７のリクエストに対してマニフェストファイルを送信するとともに、セグメント化データの配信先を転送する。セグメント化データを転送可能なＰ２Ｐ端末６が存在する場合には、Ｐ２Ｐ端末６を介してＰ２Ｐ非対応端末７にセグメント化データを配信し、セグメント化データを転送可能なＰ２Ｐ端末６が存在しない場合には、Ｐ２Ｐ非対応端末７に直接セグメント化データをＨＴＴＰ配信する。

配信サーバ２は、オリジンサーバ１から受信したセグメント化データをデータチャンクに分割し、配信サーバ２を頂点としてＰ２Ｐ端末が階層的に接続して構成されるＰ２Ｐネットワークに参加するＰ２Ｐ端末６に対し順次Ｐ２Ｐ配信する。

ここで、Ｐ２Ｐ配信におけるコンテンツの配信単位であるデータチャンクと、ＨＴＴＰ配信におけるコンテンツの配信単位であるセグメント化データの関係について説明する。Ｐ２Ｐ配信では、複数端末からのデータの並行受信やデータ受信先端末の切替えなど、端末間の配信制御をきめ細かく行うため、コンテンツは短い時間間隔（たとえば１秒以下）で分割され配信される。一方で、ＨＴＴＰ配信では、頻繁なマニフェストファイルの更新を避けるため、コンテンツは数秒〜数十秒といった比較的長い時間間隔で分割され配信される。以上から、データチャンクはセグメント化データをさらに分割したデータとする。なお、データチャンクをセグメント化データと同一サイズとしてもよい。

図２は、コンテンツ、セグメント化データ、及びデータチャンクの関係の一例を示す図である。図２では、コンテンツデータが、一定間隔あるいは任意の間隔でセグメント化データに分割され、それぞれのセグメント化データにセグメントＩｄが付与されている。なお、セグメント化データは例えば、「コンテンツ名＋セグメントＩｄ＋拡張子」などセグメント化データを一意に特定できる識別子でファイルとして保存されていてもよい。

次に、それぞれのセグメント化データは、データチャンクに分割され、それぞれのデータチャンクにはチャンク番号が付与されている。また、データチャンクが格納しているセグメント化データを識別するため、データチャンクには、格納しているセグメントのセグメントＩｄ、そのセグメントがいくつに分割されているかを示す分割数、分割されたセグメントの何番目に相当するかを示す分割番号が付与されている。図２の例では、セグメントＩｄ＝１のセグメント化データが３つに分割され、チャンク番号＝１のデータチャンクがセグメント化データの最初の分割データを格納し、チャンク番号＝２のデータチャンクが２番目の分割データを格納していることを示している。

Ｐ２Ｐ端末６は、配信サーバ２や他のＰ２Ｐ端末６と接続してデータチャンクを受信・転送するとともに、Ｐ２Ｐ非対応端末７にコンテンツのセグメント化データを送信する。

［Ｐ２Ｐ端末］
次に、Ｐ２Ｐ端末６の詳細について説明する。図３は、本発明のＰ２Ｐ端末の構成例を示すブロック図である。この例では、各Ｐ２Ｐ端末６は、Ｐ２Ｐ配信制御部１１と、ＨＴＴＰ配信制御部１２と、記憶部１３と、アプリケーション起動制御Ｉ／Ｆ１４と、通信Ｉ／Ｆ１５とを備える。

記憶部１３は、端末情報記憶部１３１と、コンテンツバッファ１３２とを備える。

端末情報記憶部１３１は、自端末（自身のＰ２Ｐ端末）の端末情報及びＰ２Ｐネットワークに参加している他のＰ２Ｐ端末６及び配信サーバ２の端末情報を格納する。表１に、端末情報記憶部１３１に格納されている端末情報の一例を示す。

表１の例では、各Ｐ２Ｐ端末の端末情報をデータベース化した端末情報データベースの項目として、端末ＩＤにそれぞれ関連付けられた、接続待受けアドレスと、ＨＴＴＰ通信ポートと、到達可否情報と、分配余力情報とを含んでいる。

端末ＩＤは、配信サーバ２及びＰ２Ｐ端末６を一意に識別する識別子である。

接続待受けアドレスは、他端末から接続要求を受け付けることができるＩＰアドレスとポート番号の組を示している。ただし、到達可否の情報が「到達不可」の場合（表１の例では「否」）は、他のＰ２Ｐ端末６からの接続受付けが不可能なため、表１ではポート番号を“−−−−”と示している。

ＨＴＴＰ通信ポートは、Ｐ２Ｐ非対応端末７からのＨＴＴＰ通信を待ち受けるポート番号を示している。ただし、到達可否情報が「到達不可」の場合は、Ｐ２Ｐ非対応端末７からのＨＴＴＰ通信の接続受付けが不可能なため、表１では”−−−−”と示している。

到達可否情報は、自端末がインターネットを介して他の端末からの接続要求を受付けることが可能か否かを示す情報である。例えば、接続要求を受付けることが可能な場合に到達可否情報の値を「到達可」とし、接続要求を受付けることできない場合に到達可否情報の値を「到達不可」とする。到達可否情報が「到達可」である端末は、インターネット上の他の端末からの接続要求はＮＡＴルータ（ポート開放可能ＮＡＴルータ４）で遮られず、接続要求を受け付けることができる。到達可否情報が「到達不可」である端末は、インターネット上の他の端末からの接続要求はＮＡＴルータ（ポート開放不可ＮＡＴルータ５）で遮られる。

分配余力情報は、他の端末に対するデータチャンクの分配余力を示す情報であり、例えば余剰分配数とすることができる。余剰分配数は、データチャンクの送受信に係る伝送能力から算出される、データチャンクを同時に分配可能な端末数から、現在データチャンクを分配している端末数を差し引いた余剰の分配可能端末数を示す。余剰分配数が大きいほど余裕があることを意味する。本実施形態では、分配余力情報を余剰分配数として、以下説明する。

コンテンツバッファ１３２は、配信サーバ２や他のＰ２Ｐ端末６から受信したデータチャンク番号順に順次蓄積し、再生時間になってから一定時間（例えば５秒）経過した後に先頭のデータチャンクから順次削除するバッファである。

Ｐ２Ｐ配信制御部１１は、接続制御部１１１と、端末情報管理部１１２と、通信環境計測部１１３と、コンテンツ再生部１１４と、データチャンク中継部１１５とを備える。

接続制御部１１１は、端末情報記憶部１３１から端末情報のリストを読み出し、自端末の接続相手（接続先）となる配信サーバ２又は他のＰ２Ｐ端末６を所定の処理により選択し、選択した配信サーバ２又は他のＰ２Ｐ端末６へ通信Ｉ／Ｆ１５を介して接続要求を行う。また、他のＰ２Ｐ端末６から通信Ｉ／Ｆ１５を介して接続要求を受付ける。また、現在の接続端末数を端末情報管理部１１２に出力する。

端末情報管理部１１２は、自端末の端末ＩＤと、到達可否判定部１１３１から入力される到達可否情報と、余剰分配数とを含む端末情報を生成し、端末情報記憶部１３１に記憶する。余剰分配数は、帯域計測部１１３２から入力される分配可能数及び接続制御部１１１から入力される現在の接続端末数から算出される。また、端末情報管理部１１２は、端末情報を通信Ｉ／Ｆ１５を介して配信支援サーバ３や、端末情報記憶部１３１に記憶されている他のＰ２Ｐ端末６へ送信する。さらに、端末情報管理部１１２は、他のＰ２Ｐ端末６から通信Ｉ／Ｆ１５を介して端末ＩＤを含む端末情報を受信し、端末情報記憶部１３１に端末ＩＤに関連付けて端末情報を記憶するとともに、端末情報記憶部１３１に記憶されている別のＰ２Ｐ端末６に対して、例えばゴシップ型マルチキャストなどを用いて転送してもよい。

通信環境計測部１１３は、到達可否判定部１１３１と、帯域計測部１１３２とを備える。

到達可否判定部１１３１は、自端末が他のＰ２Ｐ端末６から接続要求を受付けることができるか否かを判断することにより、到達可又は到達不可を判定し、その判定結果を到達可否情報として端末情報管理部１１２に出力する。「到達可」は、当該Ｐ２Ｐ端末６が外部からの接続要求を受付けることができることを意味する。また、「到達不可」は、当該Ｐ２Ｐ端末が外部からの接続要求を受付けることができないことを意味する。図１に示したＰ２Ｐ端末６−１及び６−３は「到達可」のＰ２Ｐ端末であり、Ｐ２Ｐ端末６−２は「到達不可」のＰ２Ｐ端末である。

具体的には、到達可否判定部１１３１は、自端末がインターネットに直接接続しているか否かを判断する。また、到達可否判定部１１３１は、インターネットに直接接続しておらず、ローカルネットワークを介してポート開放可能ＮＡＴルータ４又はポート開放不可ＮＡＴルータ５に接続していると判断した場合は、当該ルータが外部からの接続要求を自端末へ転送できるか否かを判断する。

例えば、到達可否判定部１１３１は、自端末のＩＰアドレスを送信元アドレスとし、当該送信元アドレスを折り返すように設定したデータを、通信Ｉ／Ｆ１５を介してインターネットに直接接続している所定のサーバへ送信する。そして、到達可否判定部１１３１は、通信Ｉ／Ｆ１５を介して受信した送り返しのデータから、送り返しの送信元アドレスと自端末のＩＰアドレスとが一致する場合、自端末はインターネットに直接接続していると判断し、自端末は到達可のＰ２Ｐ端末であると判定する。一方、到達可否判定部１１３１は、送り返しの送信元アドレスと自端末のＩＰアドレスとが一致しない場合、自端末はインターネットに直接接続していないと判断し、ローカルネットワークを介してポート開放可能ＮＡＴルータ４又はポート開放不可ＮＡＴルータ５に接続していると判断する。そして、到達可否判定部１１３１は、接続しているポート開放可能ＮＡＴルータ４又はポート開放不可ＮＡＴルータ５に対してポート開放要求を行い、その結果、ポート開放可能の応答がある場合、当該ルータが外部からの接続要求を自端末へ転送できると判断し、自端末は到達可のＰ２Ｐ端末であると判定する。一方、到達可否判定部１１３１は、ポート開放不可能の応答がある場合、又は応答がない場合（ポート開放が無効の場合）に、当該ルータが外部からの接続要求を自端末へ転送できないと判断し、自端末は到達不可のＰ２Ｐ端末であると判定する。

帯域計測部１１３２は、自端末のデータチャンクの送受信に係る帯域の伝送能力を計測し、計測した伝送能力を基に分配可能数を算出し、端末情報管理部１１２に出力する。例えば、単位時間において大容量のデータを送受信できる場合は、高い伝送能力の値が計測され、小容量のデータしか送受信できない場合は、低い伝送能力の値が計測される。具体的には、帯域計測部１１３２は、ネットワークのスループット（Ｍｂｉｔ／ｓｅｃ）を過去の通信履歴から又は事前に計測し、計測したスループットを伝送能力とする。分配可能数は、例えば、伝送能力とコンテンツのビットレートの比率とすることができる。あるいは、自端末が接続している契約回線種別の情報に応じて予め設定された規定値（例えば、契約回線種別がＦＴＴＨ、ＡＤＳＬ又は携帯回線の場合、ＦＴＴＨ＝８、ＡＤＳＬ＝４、携帯回線＝１）を分配可能数とすることができる。

コンテンツ再生部１１４は、コンテンツバッファ１３２に蓄積されたデータチャンクを再生する。

データチャンク中継部１１５は、コンテンツバッファ１３２からデータチャンクを取得し、通信Ｉ／Ｆ１５を介して他のＰ２Ｐ端末６に送信する。また、データチャンク中継部１１５は、他のＰ２Ｐ端末６から通信Ｉ／Ｆ１５を介してデータチャンクを取得し、コンテンツバッファ１３２に蓄積する。

ＨＴＴＰ配信制御部１２は、転送受付要求処理部１２１と、ＨＴＴＰ送受信部１２２と、セグメント化データ再構成部１２３と、アプリケーション終了制御部１２４とを備える。

転送受付要求処理部１２１は、配信支援サーバ３から通信Ｉ／Ｆ１５を介してセグメント化データの識別子であるセグメントＩｄを含む転送受付要求を受信する。そして、コンテンツバッファ１３２に当該セグメントＩｄを構成するデータチャンクが格納されており、且つ自端末の余剰分配数が所定の閾値以上（例えば、１以上）である場合に、配信支援サーバ３に転送受付が可能であることを示す転送受付可能応答を送信する。また、転送受付要求処理部１２１は、転送受付可能応答を送信する際に、アプリケーション終了制御部１２４の終了停止タイマを所定の時間（例えば、３秒）セットし、カウントダウンを開始する。一方、転送受付要求処理部１２１は、いずれかの条件が満たされない場合は、転送受付が不可能であることを示す転送受付不可応答を配信支援サーバ３に送信する。

ＨＴＴＰ送受信部１２２は、Ｐ２Ｐ非対応端末７からＨＴＴＰプロトコルによるセグメント化データのセグメントＩｄを含むＨＴＴＰリクエストを受信し、アプリケーション終了制御部１２４の終了停止タイマのカウントダウンを停止する。次に、ＨＴＴＰリクエストからセグメントＩｄを抽出し、セグメント化データ再構成部１２３に出力する。

セグメント化データ再構成部１２３は、コンテンツバッファ１３２から、ＨＴＴＰ送受信部１２２により抽出されたセグメントＩｄを構成するデータチャンクを抽出し、セグメント化データを再構成し、ＨＴＴＰ送受信部１２２に出力する。

ＨＴＴＰ送受信部１２２は、セグメント化データ再構成部１２３により再構成されたセグメント化データを入力し、当該セグメント化データを含むＨＴＴＰレスポンスをＰ２Ｐ非対応端末７へ送信する。セグメント化データの送信が終了するか、あるいはＰ２Ｐ非対応端末７が何らかの理由によりＨＴＴＰコネクションの切断を行った場合は、アプリケーション終了制御部１２４の終了停止タイマをクリアする。

アプリケーション終了制御部１２４は、終了停止タイマを保持し、終了停止タイマは転送受付要求処理部１２１又はＨＴＴＰ送受信部１２２により設定され、０になるまでカウントダウンする。アプリケーション起動制御Ｉ／Ｆ１４からアプリケーション終了命令が入力された場合、アプリケーション終了制御部１２４は、終了停止タイマが０になるまでの間、アプリケーションの終了処理を停止する。これにより、Ｐ２Ｐ非対応端末７からセグメント化データのリクエストを受信してセグメント化データを送信し終えるまでの間、アプリケーションの終了処理を停止させる。

アプリケーション起動制御Ｉ／Ｆ１４は、ユーザによる端末操作などによるアプリケーションの開始や終了命令を受付け、アプリケーション終了命令をアプリケーション終了制御部１２４に出力するインタフェースである。

［配信支援サーバ］
次に、配信支援サーバ３の詳細について説明する。図４は、配信支援サーバ３の構成例を示すブロック図である。この例では、配信支援サーバ３は、Ｐ２Ｐ端末情報受信部２１と、配信素材受信部２２と、ＨＴＴＰリクエスト受信部２３と、リクエスト解析部２４と、リクエスト転送部２５と、記憶部２６と、ＨＴＴＰレスポンス送信部２７と、通信Ｉ／Ｆ２８とを備える。

Ｐ２Ｐ端末情報受信部２１は、Ｐ２Ｐ端末６から端末情報を受信し、Ｐ２Ｐ端末情報記憶部２６１に格納する。Ｐ２Ｐ端末情報記憶部２６１に格納される端末情報は、表１に示すものと同様である。

配信素材受信部２２は、オリジンサーバ１からセグメント化データを受信し、セグメントバッファ２６２に順次格納するとともに、セグメント化データのＵＲＬを記載したマニフェストファイルを受信し、マニフェストファイル記憶部２６３に格納する。

図５は、マニフェストファイルの一例を示す図であり、ＩＥＴＦのインターネットドラフトである“HTTP Live Streaming”の仕様に従ったマニフェストファイルの例を示している。“HTTP Live Streaming”の詳細については、例えば、インターネット＜ＵＲＬ：http://tools.ietf.org/html/draft-pantos-http-live-streaming-11＞を参照されたい。

図５は、シーケンス番号（セグメントＩｄ）＝４５７８４６９３４を先頭として、３秒の３つのセグメント化データ（ｔｓファイル）のＵＲＬが存在する例である。セグメント化データのファイル名は、「コンテンツ名」（ｃｏｎｔｅｎｔ＿）、「セグメントＩｄ」（例えば４５７８４６９３４）、「拡張子」（.ｔｓ）を連結させた文字列となっている。マニフェストに記載されるセグメントは一定数（例えば５）として、新たなセグメント化データを受信する度に、最上段のセグメント化データの情報が削除され、最新のセグメント化データが末尾に追加される。

ＨＴＴＰリクエスト受信部２３は、通信Ｉ／Ｆ２８を介してＰ２Ｐ非対応端末７からＨＴＴＰプロトコルによるリクエストを受信し、受信したＨＴＴＰリクエストをリクエスト解析部２４に出力する。

リクエスト解析部２４は、ＨＴＴＰリクエスト受信部２３により受信したＨＴＴＰリクエストを解析し、リクエスト内容がマニフェストファイルである場合は、マニフェストファイルを送信するようにＨＴＴＰレスポンス送信部２７に指示する。一方で、リクエスト内容がセグメント化データ（ｔｓファイル）であった場合は、当該セグメント化データのセグメントＩｄをリクエスト転送部２５に出力する。

リクエスト転送部２５は、転送先端末選択部２５１と、転送受付要求部２５２とを備える。

転送先端末選択部２５１は、Ｐ２Ｐ端末情報記憶部２６１から端末情報を取得し、端末情報の到達可否情報及び余剰分配数を基にＨＴＴＰリクエストの転送先端末の候補となるＰ２Ｐ端末６（転送先候補端末６）を選択し、転送先候補端末６の端末情報を転送受付要求部２５２に出力する。具体的には、転送先端末選択部２５１は、到達可否情報が「到達可」であるＰ２Ｐ端末６のうちから、余剰分配数が大きいものを優先して転送先候補端末６とする。

転送受付要求部２５２は、ＨＴＴＰリクエストの転送が可能か否かを確認する転送受付要求を転送先候補端末６に送信する。転送受付要求はセグメントＩｄを含む。その後、転送先候補端末６から、転送受付可能応答を受信した場合は、転送先端末として端末Ｉｄ及びセグメントＩｄをＨＴＴＰレスポンス送信部２７に出力する。一方、転送受付不可応答を受信した場合は、転送先端末選択部２５１に戻り、転送先候補端末６の選択処理を繰り返すが、転送先候補端末６が存在しない場合、又は全ての転送先候補端末６から転送受付不可応答を受信した場合は、転送不可情報及びセグメントＩｄをＨＴＴＰレスポンス送信部２７に出力する。

ＨＴＴＰレスポンス送信部２７は、リクエスト解析部２４によりマニフェストファイルを送信するように指示された場合は、マニフェストファイル記憶部２６３からマニフェストファイルを入力し、Ｐ２Ｐ非対応端末７に送信する。

また、ＨＴＴＰレスポンス送信部２７は、リクエスト転送部２５から転送先端末の端末Ｉｄ及びセグメントＩｄを入力した場合は、ＨＴＴＰヘッダのステータスコードを”３０２ Ｆｏｕｎｄ”に設定するとともに、転送先端末の端末情報に含まれるＩＰアドレス、ＨＴＴＰ通信ポートを基に、当該セグメントＩｄのセグメント化データの転送先ＵＲＬを生成し、”Ｌｏｃａｔｉｏｎ”ヘッダに記述し、Ｐ２Ｐ非対応端末７に送信する。例えば”Ｌｏｃａｔｉｏｎ”ヘッダに、Location: http://192.168.0.1:8081/content_457846934.tsと記述する。

さらに、ＨＴＴＰレスポンス送信部２７は、リクエスト転送部２５から転送不可情報及びセグメントＩｄが入力された場合は、セグメントバッファ２６２から当該セグメントＩｄのセグメント化データを入力し、該セグメント化データをＰ２Ｐ非対応端末７に直接送信する。

［Ｐ２Ｐ非対応端末］
次に、Ｐ２Ｐ非対応端末７の詳細について説明する。図６は、Ｐ２Ｐ非対応端末７の構成例を示すブロック図である。この例では、Ｐ２Ｐ非対応端末７は、マニフェストファイル受信部７１と、マニフェストファイル解析部７２と、ＨＴＴＰリクエスト送信部７３と、ＨＴＴＰレスポンス受信部７４と、コンテンツバッファ７５と、コンテンツ再生部７６と、通信Ｉ／Ｆ７７とを備える。

マニフェストファイル受信部７１は、通信Ｉ／Ｆ７７を介して、配信支援サーバ３にマニフェストファイルをリクエストし、マニフェストファイルを受信する。マニフェストファイルの一例は図５に示した通りである。なお、マニフェストファイルのリクエストは、一定時間毎に定期的に行ってもよいし、マニフェストファイルに記載されている全てのセグメント化データを受信し終える直前に行ってもよい。

マニフェストファイル解析部７２は、マニフェストファイル受信部７１により受信したマニフェストファイルを解析し、セグメント化データのＵＲＬを取得する。

ＨＴＴＰリクエスト送信部７３は、マニフェストファイル解析部７２により取得したＵＲＬの配信支援サーバ３に対し、通信Ｉ／Ｆ７５を介してセグメント化データのリクエストを送信する。また、ＨＴＴＰリクエスト送信部７３は、配信支援サーバ３から受信したＨＴＴＰレスポンスにリクエストを転送可能なＰ２Ｐ端末６のＵＲＬ（転送先ＵＲＬ）が記載されている場合には、該転送先ＵＲＬにセグメント化データのリクエストを送信する。

ＨＴＴＰレスポンス受信部７４は、通信Ｉ／Ｆ７７を介してＰ２Ｐ端末６又は配信支援サーバ３から、ＨＴＴＰレスポンスを受信し、セグメント化データをコンテンツバッファ７５に蓄積する。

コンテンツ再生部７６は、コンテンツバッファ７５からセグメント化データを取得して再生する。

［コンテンツ配信方法］
次に、本発明の一実施形態に係るコンテンツ配信方法について説明する。特に、Ｐ２Ｐ非対応端末７に対してＨＴＴＰ配信を行うコンテンツ配信方法について説明する。図７は、Ｐ２Ｐ非対応端末７に対するコンテンツ配信方法を示すシーケンス図である。図８は、説明で使用するＨＴＴＰリクエスト／ＨＴＴＰレスポンスのメッセージフォーマットの一例を示す図である。ＨＴＴＰリクエスト／ＨＴＴＰレスポンスは、改行コードの上下でヘッダ部とボディ部に分かれており、ヘッダの最上位行はステータスコードが含まれている。ボディ部は存在しない場合もある。

Ｐ２Ｐ非対応端末７は、マニフェストファイル受信部７１によりマニフェストファイルを受信し、マニフェストファイル解析部７２によりマニフェストファイルから取得対象のセグメント化データを決定し、ＨＴＴＰリクエスト送信部７３によりセグメント化データのＵＲＬに対するＨＴＴＰリクエストを送信する（ステップＳ００１）。図８（ａ）に、このときのＨＴＴＰリクエストのメッセージフォーマットの一例を示す。

配信支援サーバ３は、ＨＴＴＰリクエスト受信部２３によりＰ２Ｐ非対応端末７からのＨＴＴＰリクエストを受信し（ステップＳ００２）、リクエスト解析部２４によりリクエストを解析してセグメントＩｄを抽出する（ステップＳ００３）。

リクエスト転送部２５は、Ｐ２Ｐ端末情報記憶部２６１から到達可否情報が「到達可」である端末を抽出する（ステップＳ００４）。ここでの抽出数をＮとする。そして、抽出した端末情報を余剰分配数が大きい順にソートし、転送先端末候補リストを生成する（ステップＳ００５）。次に、ループカウンタＩを０に設定し（ステップＳ００６）、ループ処理に入る。Ｉ＜Ｎであれば（ステップＳ００７−ＹＥＳ）、転送先端末候補リストからＩ番目のＰ２Ｐ端末６の端末情報を取得し（ステップＳ００８）、取得した端末情報の接続待受けアドレスを基に、セグメントＩｄを含む転送受付要求をＩ番目のＰ２Ｐ端末６に送信する（ステップＳ００９）。

Ｉ番目のＰ２Ｐ端末６は、転送受付要求処理部１２１により配信支援サーバ３から転送受付要求を受信し（ステップＳ０１０）、転送受付要求からセグメントＩｄを抽出する（ステップＳ０１１）。次に、コンテンツバッファ１３２にセグメントＩｄのセグメント化データを構成するデータチャンクを保有しており、且つ端末情報の余剰分配数が所定の閾値以上（例えば、１以上）である場合は（ステップＳ０１２−ＹＥＳ）、アプリケーション終了制御部１２４の終了停止タイマをＴ（例えば、３秒）にセットしてカウントダウンを開始し（ステップＳ０１３）、転送受付可能応答を配信支援サーバ３に送信する（ステップＳ０１４）。

配信支援サーバ３は、Ｉ番目のＰ２Ｐ端末６から転送受付可能応答を受信すると（ステップＳ０１５）、ＨＴＴＰレスポンス送信部２７により、Ｉ番目のＰ２Ｐ端末６の端末情報から取得したＩＰアドレス及びＨＴＴＰ通信ポートと、セグメントＩｄとを基に転送先ＵＲＬを生成し、ＨＴＴＰレスポンスヘッダの”Ｌｏｃａｔｉｏｎ”に設定する（ステップＳ０１６）。次に、ＨＴＴＰレスポンスヘッダのステータスコードを”３０２ Ｆｏｕｎｄ”に設定し（ステップＳ０１７）、ＨＴＴＰレスポンスをＰ２Ｐ非対応端末７に送信する（ステップＳ０１８）。図８（ｃ）に、このときのＨＴＴＰレスポンスのメッセージフォーマットの一例を示す。

Ｐ２Ｐ非対応端末７は、配信支援サーバ３からＨＴＴＰレスポンスを受信し（ステップＳ０１９）、ステータスコードが２００でなかった場合（つまり、３０２であった場合）（ステップＳ０２０−ＮＯ）は、ＨＴＴＰレスポンスヘッダの”Ｌｏｃａｔｉｏｎ”から転送先ＵＲＬを抽出する（ステップＳ０２１）。次に、該抽出した転送先ＵＲＬへＨＴＴＰリクエストを送信する（ステップＳ０２２）。図８（ｂ）に、このときのＨＴＴＰリクエストのメッセージフォーマットの一例を示す。

Ｐ２Ｐ端末６は、ＨＴＴＰ送受信部１２２によりＰ２Ｐ非対応端末７からのＨＴＴＰリクエストを受信すると（ステップＳ０２３）、アプリケーション終了制御部１２４により終了停止タイマのカウントダウンを停止し（ステップＳ０２４）、受信したＨＴＴＰリクエストからセグメントＩｄを抽出する（ステップＳ０２５）。次に、セグメント化データ再構成部１２３により、コンテンツバッファ１３２からセグメントＩｄを構成するデータチャンクを抽出し、セグメント化データを再構成し、ＨＴＴＰ送受信部１２２により、セグメント化データをＨＴＴＰレスポンスのボディ部に設定する（ステップＳ０２６）。次に、ＨＴＴＰレスポンスヘッダのステータスコードを”２００ ＯＫ”に設定し（ステップＳ０２７）、ＨＴＴＰレスポンスをＰ２Ｐ非対応端末７に送信する（ステップＳ０２８）。図８（ｄ）に、このときのＨＴＴＰレスポンスのメッセージフォーマットの一例を示す。そして、ＨＴＴＰ送受信部１２２は、終了停止タイマをクリアする（ステップＳ０２９）。

Ｐ２Ｐ非対応端末７は、ＨＴＴＰレスポンスを受信し（ステップＳ０１９）、ステータスコードが２００であった場合は（ステップＳ０２０−ＹＥＳ）、ＨＴＴＰレスポンスのボディ部からセグメント化データを抽出し（ステップＳ０３５）、セグメント化データの受信処理を終了する。

ここで、Ｐ２Ｐ端末６のステップＳ０１２の処理に戻り、コンテンツバッファ１３２にセグメントＩｄのセグメント化データを構成するデータチャンクを保有していないか、又は端末情報の余剰分配数が所定の閾値より小さい（例えば、０）である場合は（ステップＳ０１２−ＮＯ）、転送要求不可応答を配信支援サーバ３に送信する（ステップＳ０３０）。

配信支援サーバ３は、Ｐ２Ｐ端末６から転送要求不可応答を受信した場合には（ステップステップＳ０３１）、ループカウンタＩをインクリメントし（ステップＳ０３２）、ステップＳ００７の処理に戻る。ステップＳ００７でＮＯとなった場合、すなわち転送可能なＰ２Ｐ端末が存在しない場合は、セグメントバッファ２６２から当該セグメントＩｄのセグメント化データを抽出する。そして、ＨＴＴＰレスポンス送信部２７により、セグメント化データをＨＴＴＰレスポンスのボディ部に設定し（ステップＳ０３３）、ＨＴＴＰレスポンスヘッダのステータスコードを“２００ ＯＫ”に設定し、ＨＴＴＰレスポンスをＰ２Ｐ非対応端末７に送信する（ステップＳ０１８）。ステップＳ０１９以降の処理は前述の通りである。

このように、本発明では、Ｐ２Ｐ非対応端末７がコンテンツを分割したセグメント化データのＨＴＴＰリクエストを配信支援サーバ３に送信すると、配信支援サーバ３は到達可否情報及び分配余力情報を基に、複数のＰ２Ｐ端末６からＨＴＴＰリクエストの転送先候補端末となるＰ２Ｐ端末６を選択し、該Ｐ２Ｐ端末６に転送受付要求を送信する。Ｐ２Ｐ端末６は転送受付要求を受信すると、セグメント化データを保有しており、且つデータの分配余力が所定の閾値以上である場合に、転送受付可能応答を配信支援サーバ３に送信し、配信支援サーバ３はＰ２Ｐ端末６から転送受付可能応答を受信した場合は、該Ｐ２Ｐ端末６におけるセグメント化データのＵＲＬを含むＨＴＴＰレスポンスをＰ２Ｐ非対応端末７に送信する。Ｐ２Ｐ非対応端末７は配信支援サーバ３からＨＴＴＰレスポンスを受信すると、ＨＴＴＰレスポンスに含まれるＵＲＬにＨＴＴＰリクエストを送信し、Ｐ２Ｐ端末６はＰ２Ｐ非対応端末７からＨＴＴＰリクエストを受信すると、セグメント化データをＰ２Ｐ非対応端末７に送信する。配信支援サーバ３は、転送先候補端末６が存在しない場合、又は転送先候補端末６の全てから転送受付不可応答を受信した場合は、セグメント化データをＰ２Ｐ非対応端末７に直接送信する。以上の処理により、Ｐ２Ｐ非対応端末７は、Ｐ２Ｐ端末６からコンテンツを受信することができ、ＨＴＴＰ配信を行うＷｅｂサーバとして振る舞う配信支援サーバ３の配信コストを削減することができる。

また、配信支援サーバ３は到達可否情報を考慮して転送先候補端末を決定しているため、コンテンツを安定かつ効率的に配信可能となる。具体的には、到達可否情報が「到達不可」の（つまり、接続要求を受付けることができない）Ｐ２Ｐ端末６にＨＴＴＰリクエストを送信することを回避でき、受信の安定性を向上させることが可能となる。また、配信支援サーバ３は分配余力情報も考慮して転送先候補端末を決定しているため、分配余力が大きいＰ２Ｐ端末６から優先してコンテンツを受信することにより、Ｐ２Ｐ端末のコンテンツ配信の負荷を分散できるようになり、コンテンツ配信を効率的に行うことが可能となる。

また、Ｐ２Ｐ端末６は、転送受付可能応答を送信してから所定の時間、アプリケーションの終了処理を停止させるのが好適である。これにより、Ｐ２Ｐ非対応端末７がＰ２Ｐ端末６にリクエストを転送してからリクエストを完了するまでの間、Ｐ２Ｐ端末６のアプリケーションの終了（離脱）を停止させることができる。かくして、Ｐ２Ｐ非対応端末７がリクエストを送信した時に既にＰ２Ｐ端末６が離脱してしまっている、又はリクエストの完了前にＰ２Ｐ端末６が離脱してしまうといったことを禁止できるため、更に安定したコンテンツ配信が可能となる。

上述の実施形態は、代表的な例として説明したが、本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。例えば、実施形態に記載の複数の構成ブロックを１つに組み合わせたり、あるいは１つの構成ブロックを分割したりすることが可能である。

１ オリジンサーバ
２ 配信サーバ
３ 配信支援サーバ
４ ポート開放可能ＮＡＴルータ
５ ポート開放不可ＮＡＴルータ
６ Ｐ２Ｐ端末
７ Ｐ２Ｐ非対応端末
１１ Ｐ２Ｐ配信制御部
１２ ＨＴＴＰ配信制御部
１３ 記憶部
１４ アプリケーション起動制御Ｉ／Ｆ
１５ 通信Ｉ／Ｆ
２１ 端末情報受信部
２２ 配信素材受信部
２３ ＨＴＴＰリクエスト受信部
２４ リクエスト解析部
２５ リクエスト転送部
２６ 記憶部
２７ ＨＴＴＰレスポンス送信部
２８ 通信Ｉ／Ｆ
７１ マニフェストファイル受信部
７２ マニフェストファイル解析部
７３ ＨＴＴＰリクエスト送信部
７４ ＨＴＴＰレスポンス受信部
７５ コンテンツバッファ
７６ コンテンツ再生部
７７ 通信Ｉ／Ｆ
１１１ 接続制御部
１１２ 端末情報管理部
１１３ 通信環境計測部
１１４ コンテンツ再生部
１１５ データチャンク中継部
１２１ 転送受付要求処理部
１２２ ＨＴＴＰ送受信部
１２３ セグメント化データ再構成部
１２４ アプリケーション終了制御部
１３１ 端末情報記憶部
１３２ コンテンツバッファ
２５１ 転送先端末選択部
２５２ 転送受付要求部
２６１ 端末情報記憶部
２６２ セグメントバッファ
２６３ マニフェストファイル記憶部
１１３１ 到達可否判定部
１１３２ 帯域計測部

Claims (1)

1. Ｐ２Ｐネットワークに参加可能な複数のＰ２Ｐ端末と、当該Ｐ２Ｐネットワークに参加不可能なＰ２Ｐ非対応端末と、ＨＴＴＰ配信のＷｅｂサーバとして振る舞う配信支援サーバとを備えるコンテンツ配信システムにおける配信支援サーバであって、
   当該配信支援サーバが、前記Ｐ２Ｐ非対応端末からコンテンツを分割したセグメント化データのリクエストを受信すると、前記Ｐ２Ｐ端末が他のＰ２Ｐ端末からの接続要求を受付けることが可能か否かを示す到達可否情報、及び前記Ｐ２Ｐ端末の、データチャンクを同時に分配可能な端末数から現在データチャンクを分配している端末数を差し引いた余剰の分配可能端末数を示す余剰分配数に基づいて、複数のＰ２Ｐ端末から前記リクエストの転送先候補端末となるＰ２Ｐ端末を選択し、該Ｐ２Ｐ端末に前記リクエストの転送が可能か否かを確認する転送受付要求を送信するリクエスト転送部と、
   前記転送先候補端末となるＰ２Ｐ端末から転送受付可能応答を受信した場合には、該Ｐ２Ｐ端末におけるセグメント化データのＵＲＬを含むレスポンスを前記Ｐ２Ｐ非対応端末に送信するＨＴＴＰレスポンス送信部と、
   を備え、
   前記リクエスト転送部は、前記到達可否情報が他の端末からの接続要求を受付けることが可能であることを示しているＰ２Ｐ端末のうち、前記余剰分配数が大きいものから優先して、前記リクエストの転送先候補端末となるＰ２Ｐ端末を選択し、前記転送先候補端末が存在しない場合、又は前記転送先候補端末の全てから転送受付不可応答を受信した場合は、転送不可情報を前記ＨＴＴＰレスポンス送信部に出力し、
   前記ＨＴＴＰレスポンス送信部は、前記リクエスト転送部から前記転送不可情報が入力されると、当該ＨＴＴＰレスポンス送信部から前記セグメント化データを前記Ｐ２Ｐ非対応端末に直接送信することを特徴とする配信支援サーバ。