JP2012048665A - 配信システム、情報処理装置、情報処理プログラム、及びコンテンツ取得方法 - Google Patents

Abstract

【課題】コンテンツを安定した速度で迅速に取得することが可能な情報処理装置、情報処理プログラム、配信システム、及びコンテンツ取得方法を提供する。
【解決手段】本発明の情報処理装置は、オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信する第１送信手段と、前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信する第２送信手段と、を備える。そして、情報処理装置は、前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させ、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得する。
【選択図】図３

Description

本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型の配信システムの技術分野に関する。

近年、ピアツーピア型の配信システムが知られている。ピアツーピア型の配信システムでは、複数のノード装置によりオーバーレイネットワークが構成されている。そして、オーバーレイネットワークに参加している複数のノード装置に複数のコンテンツデータが分散保存されている。そして、オーバーレイネットワークで複数のノード装置に分散保存されたコンテンツデータの所在は、例えば特許文献１に開示されるような分散ハッシュテーブルを利用して効率良く検索可能になっている。以下、コンテンツデータを「コンテンツ」という。このようなピアツーピア型の配信システムでは、クライアント−サーバ型の配信システムのような配信サーバへの負荷集中を軽減することができる。

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

しかしながら、ピアツーピア型の配信システムでは、オーバーレイネットワークで複数のノード装置に分散保存されたコンテンツを検索するためのメッセージがネットワーク上で飛び交う。そのため、ピアツーピア型の配信システムではコンテンツの所在の検索に時間がかかる場合があり、配信サーバからコンテンツを取得する場合と比べると、安定した速度でコンテンツを取得できないという問題があった。

そこで、本発明は、以上の点等に鑑みてなされたものであり、コンテンツを安定した速度で迅速に取得することが可能な情報処理装置、情報処理プログラム、配信システム、及びコンテンツ取得方法を提供すること等を課題とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれる前記情報処理装置であって、前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信する第１送信手段と、前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信する第２送信手段と、前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させる制御手段と、前記第１送信手段により送信された前記検索要求、または、前記第２送信手段により送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得する取得手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記第２送信手段は、前記所定のコンテンツの中の再生開始に必要となるデータの前記取得要求を前記配信装置へ送信することを特徴とする。

請求項３に記載の発明は、請求項２に記載の情報処理装置において、前記第１送信手段は、前記再生開始に必要となるデータを除いた範囲の前記コンテンツの前記検索要求を前記所定の情報処理装置へ送信することを特徴とする。

請求項４に記載の発明は、請求項１乃至３の何れか一項に記載の情報処理装置において、前記情報処理装置は、前記オーバーレイネットワークに定常的に参加する定常装置であり、前記所定のコンテンツを取得する要求を示す取得要求を、端末装置から受信する受信手段を更に備え、前記制御手段は、前記受信手段により前記取得要求が受信されたときに、前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させることを特徴とする。

請求項５に記載の発明は、請求項１乃至４の何れか一項に記載の情報処理装置において、前記第２送信手段は、再生開始に必要となるデータとして、前記コンテンツの再生に必要な制御ファイルを取得する要求を示す取得要求を、前記制御ファイルを保存している前記配信装置へ送信することを特徴とする。

請求項６に記載の発明は、請求項１乃至４の何れか一項に記載の情報処理装置において、前記第２送信手段は、再生開始に必要となるデータとして、前記コンテンツの再生時間軸上での前記コンテンツの再生開始位置から、所定サイズのコンテンツを取得する要求を示す取得要求を、前記所定サイズのコンテンツを保存している前記配信装置へ送信することを特徴とする。

請求項７に記載の発明は、請求項１乃至４の何れか一項に記載の情報処理装置において、前記情報処理装置は、前記所定のコンテンツが再生の重要度が高いコンテンツであるか否かを判定する判定手段を更に備え、前記制御手段は、前記判定手段により再生の重要度が高いコンテンツでないと判定された場合には、前記第２送信手段による前記取得要求の送信を禁止させることを特徴とする。

請求項８に記載の発明は、請求項７に記載の情報処理装置において、前記判定手段は、前記所定のコンテンツがストリーミング再生されるコンテンツである場合、再生の重要度が高いコンテンツであると判定することを特徴とする。

請求項９に記載の発明は、請求項７に記載の情報処理装置において、前記オーバーレイネットワークは、カラオケで使用されるカラオケデータを、前記コンテンツとして、前記他の情報処理装置から取得するように構成され、前記判定手段は、前記所定のコンテンツがカラオケ装置において予約された少なくとも１曲目のカラオケデータである場合、再生の重要度が高いコンテンツであると判定することを特徴とする。

請求項１０に記載の発明は、請求項７に記載の情報処理装置において、前記判定手段は、前記所定のコンテンツのＵＲＬに含まれる情報であってコンテンツの種類を示す情報に基づいて、再生の重要度が高いコンテンツであるか否かを判定することを特徴とする。

請求項１１に記載の発明は、ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれるコンピュータに、前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信するステップと、前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信するステップと、前記検索要求を送信させるとともに、前記取得要求を送信させるステップと、前記送信された前記検索要求、または、前記送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得するステップと、を実行させるための情報処理プログラムである。

請求項１２に記載の発明は、ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムにおいて、前記情報処理装置は、前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信する第１送信手段と、前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信する第２送信手段と、前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させる制御手段と、前記第１送信手段により送信された前記検索要求、または、前記第２送信手段により送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得する取得手段と、を備えることを特徴とする。

請求項１３に記載の発明は、ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれるコンテンツ取得方法であって、前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信するステップと、前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信するステップと、前記検索要求を送信させるとともに、前記取得要求を送信させるステップと、前記送信された前記検索要求、または、前記送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得するステップと、を含むことを特徴とする。

請求項１、１１乃至１３に記載の発明によれば、オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在の検索が行われるとともに、このコンテンツの中の少なくとも再生開始に必要となるデータが配信装置から取得すること可能となる。この結果、オーバーレイネットワークで複数のノード装置に分散保存されたコンテンツを検索するためのメッセージがネットワーク上で飛び交い、コンテンツの所在の検索に時間がかかる場合であっても、配信装置からコンテンツを安定した速度で迅速に取得することができる。その結果、コンテンツの再生を迅速に開始することができる。

請求項２に記載の発明によれば、配信装置から所定のコンテンツの中の再生開始に必要となるデータだけが取得されるので、配信装置の処理負荷を一定量以下に抑えることができる。

請求項３に記載の発明によれば、情報処理装置から送信される検索要求の数を抑えることができる。端末装置のユーザによっては、オーバーレイネットワークに参加したくないユーザも存在する。そのため、請求項４に記載の発明によれば、オーバーレイネットワークに参加、非参加に関わらず、請求項１に記載の発明と同様の効果を得ることができる。

請求項５に記載の発明によれば、配信装置から所定のコンテンツの中の再生開始に必要となる制御ファイルだけが取得されるので、配信装置の処理負荷を一定量以下に抑えることができる。

請求項６に記載の発明によれば、配信装置から所定のコンテンツの中の所定サイズのコンテンツだけが取得されるので、配信装置の処理負荷を一定量以下に抑えることができる。

請求項７に記載の発明によれば、所定のコンテンツが再生の重要度が高いコンテンツでない場合、情報処理装置が配信装置へアクセスすることなく、所定のコンテンツをオーバーレイネットワークを介して取得する。その結果、配信装置の処理負荷を低減することができる。

請求項８に記載の発明によれば、コンテンツのストリーミング再生を迅速に開始することができる。

請求項９に記載の発明によれば、予約された少なくとも１曲目のカラオケデータの再生を迅速に開始することができる。

請求項１０に記載の発明によれば、特定の種類のコンテンツの再生を迅速に開始することができる。

本実施形態に係るコンテンツ配信システムの概要構成例を示す図である。 （Ａ）は、ＷｅｂサーバＷＳの概要構成例を示すブロック図である。（Ｂ）は、ノードＮｎの概要構成例を示すブロック図である。（Ｃ）は、視聴端末Ｔｎ−ｌの概要構成例を示すブロック図である。 （Ａ）は、ノードＮｎの制御部２１におけるコンテンツ取得処理を示すフローチャートである。（Ｂ）は、コンテンツを再生時間軸上に展開した例を示す図である。

以下、本発明の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ配信システムに本発明を適用した場合の実施形態である。

［１．コンテンツ配信システムの構成及び動作概要］
始めに、図１を参照して、本実施形態に係るコンテンツ配信システムの構成及び動作概要について説明する。図１は、本実施形態に係るコンテンツ配信システムの概要構成例を示す図である。図１に示すように、本実施形態に係るコンテンツ配信システムＳは、ＷｅｂサーバＷＳ、及びノード装置Ｎｎ（ｎ＝１，２，３・・・ｊ）等により構成されている。ＷｅｂサーバＷＳ、及びノード装置ＮｎはネットワークＮＷに接続されている。ネットワークＮＷは、インターネット等からなる。ＷｅｂサーバＷＳは、ネットワークＮＷ上で動画等のコンテンツを公開する配信サイトを構成するためのサーバである。また、ＷｅｂサーバＷＳは、本発明における配信装置の一例である。ノード装置は、本発明における情報処理装置及び定常装置の一例である。なお、ノード装置を、以下、「ノード」という。

また、図１に示すように、コンテンツ配信システムＳには、複数の拠点Ｐｎ毎に拠点ネットワークＮＬｎが構築されている。この拠点の例としては、例えばカラオケ店舗、学校、会社、住宅、又はその他の施設等が挙げられる。拠点ネットワークＮＬｎは、例えば、ＬＡＮ（Local Area Network）等のプライベートネットワークである。また、各拠点ネットワークＮＬｎには、ノードＮｎと複数の視聴端末Ｔｎ−ｌ（ｌ＝１，２，３）とが接続されている。そして、各拠点ＰｎにおけるノードＮｎは、同じ拠点ネットワークＮＬｎに接続されている視聴端末Ｔｎ−ｌへコンテンツを提供するエッジサーバとしての機能を有する。視聴端末Ｔｎ−ｌは、本発明における端末装置の一例である。なお、各拠点Ｐｎにおける視聴端末Ｔｎ−ｌは、同じ拠点ネットワークＮＬｎに接続されているノードＮｎだけと通信を行うことに限定されるものではない。例えば、拠点Ｐ１における視聴端末Ｔ１−１は、同じ拠点ネットワークＮＬ１に接続されているノードＮ１だけでなく、他の拠点Ｐ２等におけるノードＮ２等やＷｅｂサーバＷＳとも通信を行うことができる。また、図１に示すように、コンテンツ配信システムＳには、ネットワークＮＷを介して互いに通信可能な複数のノードＮｎ（ｎ＝１，２，３・・・ｋ）の参加によりオーバーレイネットワークＯＮが構成されている。オーバーレイネットワークＯＮは、仮想的なリンクを構成する論理的なネットワークである。オーバーレイネットワークＯＮは、特定のアルゴリズム、例えば、分散ハッシュテーブルを利用したアルゴリズムにより実現される。なお、分散ハッシュテーブルを、以下、「ＤＨＴ（Distributed Hash Table）」という。ここで、オーバーレイネットワークＯＮに参加するとは、ＤＨＴを用いたルーティングテーブルに基づいてオーバーレイネットワークＯＮを介して他のノードＮｎとの間で各種メッセージを送受信できる状態に稼動することをいう。なお、ＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

そして、本実施形態においては、各ノードＮｎはオーバーレイネットワークＯＮに定常的に参加している。ここで、「定常的に参加」とは、例えば、ノードＮｎが故障時又はメンテナンス時以外の時には、オーバーレイネットワークＯＮから脱退せず参加していることを意味する。本実施形態では、定常的に参加するノードＮｎは、例えば、ルータである。この場合、ルータに、ノードＮｎとして制御処理を実行させるプログラムがインストールされる。各拠点以外にも、各家庭で常時ネットワークに接続される機器に、ノードＮｎとして制御処理を実行させるプログラムがインストールされても良い。また、オーバーレイネットワークＯＮに参加している各ノードＮｎにはノードＩＤが付与されている。このノードＩＤは、ノードＮｎを、オーバーレイネットワークＯＮに参加しているノードＮｎの中から識別する固有の識別情報である。また、オーバーレイネットワークＯＮに参加している複数のノードＮｎには、内容の異なる様々なコンテンツが分散保存されている。なお、コンテンツは、例えばカラオケで使用されるカラオケデータとしてもよい。カラオケデータを、以下、「カラオケ用のコンテンツ」という。この場合、オーバーレイネットワークＯＮは、あるノードＮｎがカラオケ用のコンテンツを他のノードＮｎから取得するように構成される。

また、オーバーレイネットワークＯＮで各ノードＮｎに保存されている各コンテンツには、コンテンツＩＤが付与されている。コンテンツＩＤは、コンテンツを、オーバーレイネットワークＯＮでノードＮｎに保存されるコンテンツの中から識別する固有の識別情報である。なお、ノードＩＤ及びコンテンツＩＤは、例えば、オーバーレイネットワークＯＮで共通のハッシュ関数により生成される。

ここで、コンテンツを保存しているノードＮｎを、以下、「コンテンツ保持ノード」という。また、コンテンツの所在を示す情報は、インデックス情報として、コンテンツの所在を管理しているノードＮｎに記憶される。コンテンツの所在を管理しているノードＮｎを、以下、「ルートノード」という。インデックス情報には、コンテンツを保存しているコンテンツ保持ノードのノード情報と、コンテンツのコンテンツＩＤとの組が含まれる。ノード情報には、例えば、コンテンツ保持ノードのＩＰアドレス、ポート番号、及びノードＩＤが含まれる。ルートノードは、例えば、コンテンツＩＤと最も近いノードＩＤが割り当てられたノードＮｎであるように定められる。コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。

更に、オーバーレイネットワークＯＮに参加しているノードＮｎは、ＨＴＴＰ（HyperText Transfer Protocol）Ｐｒｏｘｙの機能を有する。このため、ノードＮｎは、視聴端末Ｔｎ−ｌから送信されたＨＴＴＰリクエストを受信する。このＨＴＴＰリクエストは、所定のコンテンツを取得する要求を示す取得要求の一例である。そして、ノードＮｎは、一般的なＨＴＴＰ Ｐｒｏｘｙであれば、視聴端末Ｔｎ−ｌから送信されたＨＴＴＰリクエストを、そのままＷｅｂサーバＷＳへ転送するところを、ＨＴＴＰリクエストで要求された所定のコンテンツの所在をオーバーレイネットワークＯＮから検索する検索処理を行う。この検索処理を行うノードＮｎを、以下、「ユーザノード」という。この検索処理において、ユーザノードは、要求されたコンテンツの所在を検索する要求を示す検索要求を、オーバーレイネットワークＯＮにおける所定のノードＮｎへ送信する。具体的には、ユーザノードは、先ず、検索要求を含むコンテンツ所在問合せメッセージを生成する。コンテンツ所在問合せメッセージは、検索要求に対応するコンテンツの所在をルートノードに問い合わせるためのメッセージである。また、コンテンツ所在問合せメッセージには、このメッセージを送信するユーザノードのＩＰアドレス及びポート番号、並びに検索要求に対応するコンテンツのコンテンツＩＤが含まれる。このコンテンツＩＤは、例えばＨＴＴＰリクエストに含まれるコンテンツのＵＲＬに基づいて生成される。そして、ユーザノードは、ＤＨＴを用いてルーティングテーブルに基づいて、コンテンツ所在問合せメッセージを、オーバーレイネットワークＯＮにおける所定のノードＮｎへ送信する。こうして送信されたコンテンツ所在問合せメッセージは、ＤＨＴルーティングにより、検索要求に対応するコンテンツのルートノードへ送信される。なお、ＤＨＴルーティングは、例えば特開２００７−０５３６６２号公報等で公知であるので、詳しい説明を省略する。コンテンツ所在問合せメッセージを受信したルートノードは、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応するインデックス情報を取得する。そして、ルートノードは、取得したインデックス情報を、ユーザノードへ返信する。このように返信されたインデックス情報には、検索要求に対応するコンテンツを保存している１以上のコンテンツ保持ノードのＩＰアドレス等が含まれている。こうして、ユーザノードは、検索要求の結果として、ルートノードからインデックス情報を取得する。そして、ユーザノードは、取得したインデックス情報に含まれるコンテンツ保持ノードのＩＰアドレス等に基づいてコンテンツ保持ノードにアクセスする。そして、ユーザノードは、検索要求に対応するコンテンツをコンテンツ保持ノードから取得する。こうして取得されたコンテンツは、ＨＴＴＰリクエストを送信した視聴端末Ｔｎ−ｌへ転送される。

ところで、コンテンツ保持ノードからコンテンツを取得する場合、上述した検索処理によりコンテンツの所在を検索する必要がある。この場合、オーバーレイネットワークＯＮで複数のノードＮｎに分散保存されたコンテンツを検索するため、メッセージがネットワークＮＷ上で飛び交う場合がある。そのため、この場合、ＷｅｂサーバＷＳからコンテンツを取得する場合と比べると、コンテンツの取得が遅くなることがある。そこで、本実施形態においては、ユーザノードは、上述したようにＨＴＴＰリクエストで要求されたコンテンツの検索要求を送信するとともに、このコンテンツの中の少なくとも再生開始に必要となる一部分のデータを取得する要求を示す取得要求を一般的なＨＴＴＰ Ｐｒｏｘｙサーバと同様に、ＷｅｂサーバＷＳに送信する。なお、本実施形態においては、ＷｅｂサーバＷＳはオーバーレイネットワークＯＮに属していない。しかしながら、ＷｅｂサーバＷＳがオーバーレイネットワークＯＮに属していても良い。属しているとは、ＷｅｂサーバＷＳがオーバーレイネットワークＯＮに参加していることを示す。ここで、一部分のデータを取得する要求を示す取得要求は、例えば、ＨＴＴＰリクエストに含まれてＷｅｂサーバＷＳに送信される。なお、一部分のデータを、以下、「部分データ」という。部分データは、本発明における第１データの一例である。この結果、ユーザノードは、コンテンツ保持ノードからコンテンツを取得するまでの間に、取得要求に対応する少なくとも再生開始に必要となる部分データをＷｅｂサーバＷＳからクライアント−サーバ方式で取得することが可能となる。そして、ユーザノードにより取得された少なくとも再生開始に必要となる部分データは、ＨＴＴＰリクエストを送信した視聴端末Ｔｎ−ｌへ転送される。その結果、視聴端末Ｔｎ−ｌは、オーバーレイネットワークＯＮを介して取得されるコンテンツを待たずに、再生開始に必要となる部分データを用いてコンテンツの再生を迅速に開始することができる。

［２．ＷｅｂサーバＷＳの構成及び機能］
次に、図２（Ａ）を参照して、ＷｅｂサーバＷＳの構成及び機能について説明する。図２（Ａ）は、ＷｅｂサーバＷＳの概要構成例を示すブロック図である。ＷｅｂサーバＷＳは、図２（Ａ）に示すように、制御部１１、記憶部１２、及び通信部１３等を備えて構成される。制御部１１、記憶部１２、及び通信部１３はバス１４を介して相互に接続されている。ＷｅｂサーバＷＳは、アプリケーションサーバ、及びデータベースサーバ等の複数のサーバから構成されてもよい。

記憶部１２は、例えばハードディスクドライブ等から構成される。記憶部１２には、オペレーティングシステム、及びサーバプログラム等が記憶されている。また、記憶部２に設けられたコンテンツ保存領域には、配信サイトに登録されたコンテンツが所定のファイル形式で記憶されている。このようなコンテンツは、例えば、再生対象のリソースファイルから構成される。ここで、リソースファイルとしては、例えば、動画ファイル、画像ファイル、音声ファイル、テキストファイル等が挙げられる。動画ファイルの例としては、ｗｍｖファイル、ａｓｆファイル、ｆｌｖファイル、３ｇｐファイル等がある。画像ファイルの例としては、ｂｍｐファイル、ｊｐｅｇファイル、ｇｉｆファイル等がある。音声ファイルの例としては、ｍｐ３ファイル等がある。テキストファイルの例としては、ＸＭＬファイル等がある。

また、コンテンツがリソースファイルと、リソースファイルの再生に必要な制御ファイルから構成される場合がある。制御ファイルの例としては、ｓｗｆファイル等がある。ｓｗｆファイルには、動画等のリソースの出力制御を行うためのスプリプトがAction Scriptと呼ばれる言語で記述されている。ここで、出力制御には、例えば、リソースファイルに格納された動画等のリソースの出力タイミングの制御が含まれる。出力タイミングとは、言い換えれば、各動画等のリソースの再生開始からの経過した時間である。また、出力制御は、画像やテキストを所定のディスプレイに表示する表示制御が含まれる場合もある。この表示制御には、例えば、画像やテキストの表示位置の制御が含まれる。

なお、コンテンツが複数のリソースファイルと各リソースファイルの再生に必要な制御ファイルから構成される場合がある。この場合、制御ファイルには、例えば各リソースファイルが再生される順番が規定される。

また、記憶部１２には、視聴端末Ｔｎ−ｌ等に提供可能なＷｅｂページが記憶されている。Ｗｅｂページは、ＨＴＭＬ（Hyper Text Markup Language）やＸＭＬ（Extensible Markup Language）等により記述された構造化文書ファイルからなる。また、Ｗｅｂページには、コンテンツを再生するソフトウェアであるプレイヤーの識別子が記述される。更に、Ｗｅｂページには、視聴端末Ｔｎ−ｌ等に提供可能なコンテンツの所在を示す所在情報が記述される。この所在情報の例としては、コンテンツのＵＲＬ（Uniform Resource Locator）が挙げられる。ＵＲＬは、ＵＲＩの一例である。なお、ＵＲＩには、リソースの場所を識別するＵＲＬと、リソースの名前を識別するＵＲＮとが含まれる。このＵＲＬには、コンテンツを構成するファイルのファイルパス及びファイル名が含まれる。なお、Ｗｅｂページには、コンテンツのメタファイルのＵＲＬが記述されるように構成してもよい。コンテンツのメタファイルは、ＷｅｂブラウザがＷｅｂページからコンテンツへアクセスするためのテキストファイルである。そのため、コンテンツのメタファイルには、コンテンツのＵＲＬが記述される。メタファイルの例としては、ｗｖｘファイル、ａｓｘファイル等が挙げられる。このようなメタファイルを利用することで、ＷｅｂブラウザがＷｅｂページに示されるプレイヤーを起動させコンテンツのストリーミング再生が可能になる。また、一つのコンテンツが複数のファイルから構成される場合がある。この場合、コンテンツのメタファイルには、コンテンツを構成する各ファイルのＵＲＬが記述される。

通信部１３は、ネットワークＮＷを通じて視聴端末Ｔｎ−ｌ又はノードＮｎ等との間の通信制御を行う。

制御部１１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、ＷｅｂサーバＷＳとしての処理を行う。

［３．ノードＮｎの構成及び機能等］
次に、図２（Ｂ）を参照して、ノードＮｎの構成及び機能について説明する。図２（Ｂ）は、ノードＮｎの概要構成例を示すブロック図である。ノードＮｎは、図２（Ｂ）に示すように、制御部２１、バッファメモリ２２、記憶部２３、通信部２４ａ、及び通信部２４ｂ等を備えて構成される。制御部２１、バッファメモリ２２、記憶部２３、通信部２４ａ、及び通信部２４ｂはバス２５を介して相互に接続されている。なお、本実施形態において、ノードＮｎは、ネットワークＮＷと拠点ネットワークＮＬｎと間でＩＰ（Internet Protocol）パケットを中継する中継機器であるものとする。この中継機器は、例えばルータ又はＬ３スイッチングハブ等である。

バッファメモリ２２は、通信部２４ａを介して受信されたコンテンツを一時的に蓄積する。

記憶部２３は、例えばハードディスクドライブ等から構成される。記憶部２３には、オペレーティングシステム、ＩＰパケット中継処理プログラム、及びノード処理プログラム等が記憶されている。なお、ノード処理プログラム等は、例えば、ネットワークＮＷに接続された所定のサーバからダウンロードされるようにしてもよい。或いは、ノード処理プログラム等は、例えば、記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。

また、記憶部２３には、オーバーレイネットワークＯＮで使用されるＤＨＴを用いたルーティングテーブル等が記憶されている。また、記憶部２３に設けられたコンテンツ保存領域には、コンテンツが記憶されている。このコンテンツは、ＷｅｂサーバＷＳの記憶部１２に記憶されるコンテンツと同様である。また、コンテンツが複数のファイルから構成される場合がある。この場合、例えば、各ファイルが一つのコンテンツとしてオーバーレイネットワークＯＮに参加している複数のノードＮｎに分散保存される。そのため、一つのノードＮｎの記憶部２３には、コンテンツを構成する複数のファイルの中の一つのファイルが記憶される場合もある。例えば、コンテンツが、第１の動画ファイル、第２の動画ファイル、及び制御ファイルから構成されるとする。この場合、第１の動画ファイルは、例えばノードＮ１の記憶部２３に保存される。また、第２の動画ファイルは、例えばノードＮ２の記憶部２３に保存される。また、制御ファイルは、例えばノードＮ３の記憶部２３に保存される。なお、このようにコンテンツとして分散保存された各ファイルには、夫々固有のコンテンツＩＤが付与されている。

通信部２４ａは、ネットワークＮＷを通じて他のノードＮｎ又はＷｅｂサーバＷＳ等との間の通信制御を行う。通信部２４ｂは、拠点ネットワークＮＬｎを通じて視聴端末Ｔｎ−ｌとの間の通信制御を行う。

制御部２１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部２１は、本発明における受信手段、第１送信手段、第２送信手段、判定手段、制御手段、及び取得手段の一例である。制御部２１は、ＣＰＵが記憶部２３等に記憶されたＩＰパケット中継処理プログラムの実行により、ＩＰパケット中継処理部２１ａとして動作する。ＩＰパケット中継処理部２１ａは、ＯＳＩ（Open Systems Interconnection）参照モデルの第３層であるネットワーク層において、他のルータ又はホストからのＩＰパケットを中継する処理を行う。なお、ＩＰパケット中継処理部２１ａの機能は、公知のルータ又はＬ３スイッチングハブ等と同様であるので、詳しい説明を省略する。また、制御部２１は、ＣＰＵが記憶部２３等に記憶されたノード処理プログラムの実行により、ノード処理部２１ｂとして動作する。なお、ＩＰパケット中継処理部２１ａとノード処理部２１ｂの処理は、１つのＣＰＵがマルチタスク又はマルチコアにより実行される。或いは、ＩＰパケット中継処理部２１ａとノード処理部２１ｂの処理は、２つのＣＰＵで夫々のＣＰＵにより実行されるように構成してもよい。

［４．視聴端末Ｔｎ−ｌの構成及び機能等］
次に、図２（Ｃ）を参照して、視聴端末Ｔｎ−ｌの構成及び機能について説明する。図２（Ｃ）は、視聴端末Ｔｎ−ｌの概要構成例を示すブロック図である。視聴端末Ｔｎ−ｌは、図２（Ｃ）に示すように、制御部３１、記憶部３２、バッファメモリ３３、デコーダ部３４、映像処理部３５、表示部３６、音声処理部３７、スピーカ３８、通信部３９、及び入力部３９ａ等を備えて構成される。制御部３１、記憶部３２、バッファメモリ３３、デコーダ部３４、映像処理部３５、表示部３６、音声処理部３７、通信部３９、及び入力部３９ａは、バス３９ｂを介して相互に接続されている。なお、視聴端末Ｔｎ−ｌには、パーソナルコンピュータ又はカラオケ装置が適用可能である。カラオケ装置は、カラオケ用のコンテンツを再生する装置である。

記憶部３２は、例えばハードディスクドライブ等から構成される。記憶部３２には、オペレーティングシステム、Ｗｅｂブラウザのプログラム、及びプレイヤーのプログラム等が記憶されている。また、記憶部３２には、ＷｅｂサーバＷＳのＩＰアドレス及びポート番号が記憶されている。

バッファメモリ３３は、受信されたコンテンツをバッファリングする。デコーダ部３４は、コンテンツに含まれる映像データ及び音声データ等のデータ伸張や復号化等のデコード処理を行う。映像処理部３５は、デコーダ部３４によりデコードされた映像データ等に対して所定の描画処理を施し映像信号として再生出力する。表示部３６は、映像処理部３５から再生出力された映像信号に基づきディスプレイに映像等を表示する。また、表示部３６は、デコーダ部３４によりデコードされた画像を表示する。音声処理部３７は、デコーダ部３４によりデコードされた音声データをアナログ音声信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して再生出力する。スピーカ３８は、音声処理部３７から再生出力された音声信号を音波として出力する。

通信部３９は、ネットワークＮＷを通じてＷｅｂサーバＷＳ又はノードＮｎ等との間の通信制御を行う。

制御部３１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。また、制御部３１は、ＣＰＵが記憶部３２等に記憶されたＷｅｂブラウザのプログラムの実行により、Ｗｅｂブラウザ３１ａとして動作する。このＷｅｂブラウザ３１ａによりＷｅｂサーバＷＳから取得されたＷｅｂページがディスプレイに表示される。また、制御部３１は、ＣＰＵが記憶部３２等に記憶されたプレイヤーのプログラムの実行により、プレイヤー３１ｂとして動作する。このプレイヤー３１ｂによりデコーダ部３４等が制御されてコンテンツが再生される。

なお、制御部３１は、ノードＮｎの制御部２１と同様、ノード処理プログラムを実行することでノード処理部として動作するように構成してもよい。この場合、視聴端末Ｔｎ−ｌは、オーバーレイネットワークＯＮに参加してノードＮｎとして動作することが可能になる。

［５．コンテンツ配信システムＳの動作］
次に、図３を参照して、本実施形態に係るコンテンツ配信システムＳの動作について説明する。図３（Ａ）は、ノードＮｎの制御部２１におけるコンテンツ取得処理を示すフローチャートである。なお、以下の説明では、ノードＮ１と視聴端末Ｔ１−１を例にとる。また、視聴端末Ｔ１−１の表示部３６には、Ｗｅｂブラウザ３１ａによりＷｅｂサーバＷＳから受信されたＷｅｂページが表示されているものとする。このＷｅｂページは、配信サイトで公開されたコンテンツの視聴用のページである。また、このＷｅｂページには、コンテンツのＵＲＬ又はコンテンツのメタファイルのＵＲＬが含まれている。このようにＷｅｂページが表示されている状態において、例えば、視聴端末Ｔ１−１のユーザにより入力部３９ａを介してコンテンツの再生指示があるとする。この場合、視聴端末Ｔ１−１のＷｅｂブラウザ３１ａは、再生指示されたコンテンツを取得する要求を示すＨＴＴＰリクエストを、拠点ネットワークＮＬ１を介してノードＮ１に送信する。或いは、Ｗｅｂブラウザ３１ａがＷｅｂページを受信したことを条件として、ＨＴＴＰリクエストがノードＮ１に送信されるように構成してもよい。このＨＴＴＰリクエストには、Ｗｅｂページから抽出されたコンテンツのＵＲＬが含まれている。なお、ＷｅｂページにコンテンツのメタファイルのＵＲＬが含まれる場合がある。この場合、Ｗｅｂブラウザ３１ａは、先ず、コンテンツのメタファイルを取得してこのメタファイルからコンテンツのＵＲＬを抽出する。そして、Ｗｅｂブラウザ３１ａは、抽出したコンテンツのＵＲＬを含むＨＴＴＰリクエストをノードＮ１に送信する。また、一つのコンテンツが複数のファイルから構成される場合がある。この場合、各ファイルのＵＲＬがＨＴＴＰリクエストに含まれることになる。

そして、図３（Ａ）に示す処理は、ノードＮ１が視聴端末Ｔ１−１からＨＴＴＰリクエストを受信することにより開始される。図３（Ａ）に示す処理が開始されると、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツが再生の重要度が高いコンテンツであるか否かを判定する（ステップＳ１）。この判定は、コンテンツ中の少なくとも再生開始に必要となる部分データをＷｅｂサーバＷＳから取得するか否かを決定するために行われる。ここで、再生の重要度が高いコンテンツとは、例えば、視聴端末Ｔ１−１が受信してから迅速に再生を開始するべきコンテンツをいう。再生の重要度が高いコンテンツは、言い換えれば、再生重視のコンテンツである。

再生の重要度が高いコンテンツであるか否かの判定方法の例としては、以下の（ａ）〜（ｄ）が挙げられる。

（ａ）ストリーミング再生されるか否かに基づく判定
視聴端末Ｔ１−１から、ＨＴＴＰリクエストにより、コンテンツのストリーミング再生が要求される場合がある。ストリーミング再生されるコンテンツは、視聴端末Ｔ１−１が受信してから迅速に再生を開始するべきコンテンツである。そのため、ノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツがストリーミング再生されるコンテンツである場合、再生の重要度が高いコンテンツであると判定する。ここで、ストリーミング再生されるコンテンツとは、所定量のデータがバッファメモリ３３にバッファリングされたときに再生が開始されるコンテンツをいう。また、ストリーミング再生されるコンテンツであることを示す情報は、Ｗｅｂページに記述されている。そのため、この場合、視聴端末Ｔ１−１から送信されるＨＴＴＰリクエストのヘッダには、ストリーミング再生されるコンテンツであることを示す情報が含められる。（ａ）の判定方法によれば、視聴端末Ｔ１−１はコンテンツのストリーミング再生を迅速に開始することができる。一方、視聴端末Ｔ１−１から要求されたコンテンツがストリーミング再生されるコンテンツでない場合、ＷｅｂサーバＷＳの処理負荷を低減することができる。

（ｂ）複数のコンテンツの再生順番に基づく判定
視聴端末Ｔ１−１から、ＨＴＴＰリクエストにより、順番に再生される複数のコンテンツが要求される場合がある。複数のコンテンツの中の１番目に再生されるコンテンツは、視聴端末Ｔ１−１が受信してから迅速に再生を開始するべきコンテンツである。そのため、ノード処理部２１ｂは、要求された複数のコンテンツの中の１番目に再生されるコンテンツを、再生の重要度が高いコンテンツであると判定する。例えば、視聴端末Ｔ１−１がカラオケ装置であり、カラオケ用のコンテンツが要求される場合がある。この場合、ノード処理部２１ｂは、カラオケ装置において予約された１曲目のコンテンツを、再生の重要度が高いコンテンツであると判定する。一方、複数のコンテンツの中の２番目以降に再生されるコンテンツは、１番目のコンテンツの再生終了後に再生されればよい。そのため、このようなコンテンツは、再生の重要度が高いコンテンツでないと判定される。なお、視聴端末Ｔ１−１から送信されるＨＴＴＰリクエストのヘッダには、各コンテンツに対応する曲の再生順番又は予約順番を示す情報が含められる。また、例えば視聴端末Ｔ１−１において１曲目のコンテンツの再生中に、ユーザから入力部３９ａを介して２曲目以降のコンテンツの予約が指示される場合がある。この場合、ノード処理部２１ｂは、要求された２曲目以降のコンテンツを、再生の重要度が高いコンテンツでないと判定する。なお、この場合、ＨＴＴＰリクエストのヘッダには、予約された２曲目以降のコンテンツであることを示す情報が含められる。（ｂ）の判定方法によれば、視聴端末Ｔ１−１は、複数のコンテンツの中の１番目のコンテンツの再生を迅速に開始することができる。一方、視聴端末Ｔ１−１から要求されたコンテンツが２番目以降のコンテンツである場合、ＷｅｂサーバＷＳの処理負荷を低減することができる。

（ｃ）コンテンツの種類に基づく判定
コンテンツの種類には、例えば、動画、静止画、音声、テキスト等の種類がある。なお、動画は映像ともいう。このうち、動画のコンテンツは、視聴端末Ｔ１−１が受信してから迅速に再生を開始するべきコンテンツである。そのため、ノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツが動画のコンテンツである場合、再生の重要度が高いコンテンツであると判定する。一方、静止画のコンテンツは、画像ファイル全体が揃って初めて視聴できるコンテンツであるため、部分的に迅速に取得できることによるメリットはないと考えられる。そのため、このようなコンテンツは、再生の重要度が高いコンテンツでないと判定される。なお、コンテンツの種類は、視聴端末Ｔ１−１から送信されるＨＴＴＰリクエストに含まれるコンテンツのＵＲＬにより判別できる。例えば、コンテンツのＵＲＬには、コンテンツを構成するファイルのファイル名が含まれている場合がある。そのファイル名に含まれる拡張子によりコンテンツの種類を判別できる。拡張子が、例えば「ｗｍｖ」、「ｆｌｖ」、又は「３ｇｐ」であれば、動画のコンテンツであると判定できる。なお、ファイル名に含まれる拡張子は、コンテンツの種類を示す情報の一例である。（ｃ）の判定方法によれば、視聴端末Ｔ１−１は、動画のコンテンツの再生を迅速に開始することができる。

（ｄ）重視するストリームに基づく判定
コンテンツが音声ストリームと映像ストリームの両方のデータからなる場合において、一方のストリームがより重視されるケースがある。ここで、ストリームとは連続的な流れを意味する。例えば、カラオケ用のコンテンツの場合、瞬間的であっても音声ストリームが途切れることは問題である。しかし、動画ストリームの方は一瞬停止したとしてもカラオケの用途上は大きな問題とはならない。なお、音声ストリームのデータは音声ファイルに格納される。一方、映像ストリームのデータは動画ファイルに格納される。この場合、ノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツを構成する音声ファイルと動画ファイルのうち、音声ファイルを再生の重要度が高いコンテンツであると判定する。一方、要求されたコンテンツを構成する音声ファイルと動画ファイルのうち、動画ファイルを再生の重要度が低いコンテンツであると判定する。なお、音声ファイルと動画ファイルの区別は、例えば、そのファイル名に含まれる拡張子により行うことができる。（ｄ）の判定方法によれば、視聴端末Ｔ１−１は、重視するストリーム再生を迅速に開始することができる。

なお、上記（ａ）〜（ｄ）とは別の判定方法を適用してもよい。例えば、視聴端末Ｔ１−１のユーザが急ぎで取得したいコンテンツを再生の重要度が高いコンテンツとして指定することが考えられる。この場合、視聴端末Ｔ１−１から送信されるＨＴＴＰリクエストのヘッダには、再生の重要度が高いコンテンツであることを示す情報が含められる。

そして、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツが再生の重要度が高いコンテンツでないと判定した場合には（ステップＳ１：ＮＯ）、ステップＳ５に進む。つまり、この時点では、ノード処理部２１ｂは、ＷｅｂサーバＷＳへコンテンツを取得する要求を示すＨＴＴＰリクエストを送信することを禁止する。この場合、オーバーレイネットネットワークＯＮからコンテンツを発見できれば、ノード処理部２１ｂからＷｅｂサーバＷＳへはコンテンツの要求が行われないので、ＷｅｂサーバＷＳの処理負荷を低減することができる。

一方、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツが再生の重要度が高いコンテンツであると判定した場合には（ステップＳ１：ＹＥＳ）、ステップＳ２に進む。

ステップＳ２では、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツの中の再生開始に必要となる部分データを決定する。再生開始に必要となる部分データの例としては、動画等の出力制御を行うためのデータが挙げられる。動画等の出力制御を行うためのデータは、例えば図３（Ｂ）に示すように、コンテンツの再生時間軸上での再生開始位置から所定バイト目までの所定サイズのデータ５１中に含まれる。そのため、ノード処理部２１ｂは、所定サイズのデータ５１を、再生開始に必要となる部分データとして決定する。なお、図３（Ｂ）は、コンテンツを再生時間軸上に展開した例を示す。再生時間軸上での再生開始位置とはコンテンツの０バイト目の位置である。

また、例えばコンテンツのフォーマットによっては、動画等の出力制御を行うためのデータは、図３（Ｂ）に示すように、コンテンツの再生時間軸上での所定バイト目から再生終了位置までの所定サイズのデータ５３中に含まれる場合もある。この場合、ノード処理部２１ｂは、所定サイズのデータ５３を、再生開始に必要となる部分データとして決定する。或いは、動画等の出力制御を行うためのデータが、コンテンツの再生時間軸上での再生開始位置から第１のバイト目までの所定サイズのデータ５１と、第１のバイトよりも大きい第２のバイト目から再生終了位置までの所定サイズのデータ５３とに分かれて含まれる場合がある。この場合、ノード処理部２１ｂは、所定サイズのデータ５１と、所定サイズのデータ５３を、再生開始に必要となる部分データとして決定する。

また、視聴端末Ｔ１−１から要求されたコンテンツが複数のリソースファイルから構成される場合がある。また、各リソースファイルには再生される順番が設定されている。この場合、ノード処理部２１ｂは、再生される順番が１番のリソースファイル、又は再生される順番が１番から所定順番までのリソースファイルを、再生開始に必要となる部分データとして決定するように構成してもよい。

また、視聴端末Ｔ１−１から要求されたコンテンツがリソースファイルと、リソースファイルの再生に必要な制御ファイルから構成される場合がある。この場合、ノード処理部２１ｂは、制御ファイルを再生開始に必要となる部分データとして決定するように構成してもよい。

また、上述した（ｄ）の判定方法で、音声ファイルを再生の重要度が高いコンテンツであると判定される一方、動画ファイルを再生の重要度が低いコンテンツであると判定される場合がある。この場合、ノード処理部２１ｂは、この音声ファイルを再生開始に必要となる部分データとして決定するように構成してもよい。

そして、ノードＮ１のノード処理部２１ｂは、上記ステップＳ２で決定された再生開始に必要となる部分データをクライアント−サーバ方式で取得する要求を示すＨＴＴＰリクエストをネットワークＮＷを介してＷｅｂサーバＷＳへ送信する（ステップＳ３）。ここで、ＨＴＴＰリクエストには、視聴端末Ｔ１−１から要求されたコンテンツのＵＲＬとこのコンテンツの中の再生開始に必要となる部分データの範囲を示す情報が含まれる。部分データの範囲は、Ｘバイト〜Ｙバイトというように表される。また、一つのコンテンツを構成する複数のファイルの中の一部のファイルが再生開始に必要となる部分データであると判定される場合がある。この場合、ＨＴＴＰリクエストには、再生開始に必要となる部分データとして判定されたファイルのＵＲＬが含まれる。このように、ＷｅｂサーバＷＳに要求するデータを、再生開始に必要となる部分データのみとすることで、ＷｅｂサーバＷＳの処理負荷を一定量以下に抑えることができる。

なお、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツの全データを取得する要求を示すＨＴＴＰリクエストをＷｅｂサーバＷＳに送信するように構成してもよい。この構成によれば、視聴端末Ｔ１−１から要求されたコンテンツを完全な形でＷｅｂサーバＷＳから取得することができる。そのため、ノード処理部２１ｂは、このコンテンツをオーバーレイネットワークＯＮから発見できなかった場合に、ＷｅｂサーバＷＳから取得されたコンテンツをオーバーレイネットワークＯＮへ投入することができる。また、この場合、ノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツのＵＲＬを含むＨＴＴＰリクエストをＷｅｂサーバＷＳに転送すればよいので、効率が良い。ここで、「コンテンツの投入」とは、オーバーレイネットワークＯＮで取得可能なコンテンツとして新たなコンテンツを何れかのノードＮｎに保存させることをいう。

そして、ＷｅｂサーバＷＳは、ノードＮ１から送信されたＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストに含まれるＵＲＬで示されるコンテンツを取得してノードＮ１へ送信する。また、ＨＴＴＰリクエストに部分データの範囲を示す情報が含まれていた場合、この範囲の部分データが取得されノードＮ１に送信される。

次いで、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳへコンテンツの取得要求をしたことを示す情報を記憶し（ステップＳ４）、ステップＳ５に進む。

ステップＳ５では、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツの所在をオーバーレイネットワークＯＮから検索する検索処理を行う。具体的には、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツのコンテンツＩＤを含むコンテンツ所在問合せメッセージを生成する。そして、ノード処理部２１ｂは、生成したコンテンツ所在問合せメッセージを、ＤＨＴルーティングによりコンテンツのルートノード宛に送信する。ここで、コンテンツＩＤは、例えば、ノードＩＤを生成するハッシュ関数と同じハッシュ関数によりコンテンツのＵＲＬがハッシュ化されて生成される。この場合、コンテンツのＵＲＬのハッシュ値がコンテンツＩＤとなる。このようにコンテンツのＵＲＬに基づきコンテンツＩＤが生成されるので、オーバーレイネットワークＯＮへ投入されるコンテンツのコンテンツＩＤを記述するためにＷｅｂページの記述を変更しなくてもよい。

ところで、視聴端末Ｔ１−１から要求されたコンテンツを構成する各ファイルのＵＲＬがＨＴＴＰリクエストに含まれている場合がある。この場合、各ファイルのＵＲＬに基づき各ファイルのコンテンツＩＤが生成される。このように生成されたコンテンツＩＤを含むコンテンツ所在問合せメッセージはファイル毎に生成される。そして、生成された各コンテンツ所在問合せメッセージは、各ファイルのルートノード宛に送信される。

また、一つのコンテンツを構成する複数のファイルの中の一部のファイルが再生開始に必要となる部分データとしてＷｅｂサーバＷＳへ要求される場合がある。この場合、この一部のファイル以外のファイルのＵＲＬに基づきファイルのコンテンツＩＤが生成される。そして、このように生成されたコンテンツＩＤを含むコンテンツ所在問合せメッセージがファイルのルートノード宛に送信される。つまり、再生開始に必要となるデータを除いた範囲のコンテンツの検索する要求を示す検索要求がルートノード宛に送信される。ノードＮ１から送信されるコンテンツ所在問合せメッセージの数を抑えることができる。

そして、ルートノードは、ノードＮ１から送信されたコンテンツ所在問合せメッセージを受信すると、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応するインデックス情報を取得してノードＮ１へ送信する。一方、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応するインデックス情報が記憶されていない場合がある。この場合、ルートノードは、コンテンツ無メッセージをノードＮ１へ送信することになる。このコンテンツ無メッセージは、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応するコンテンツを保存しているコンテンツ保持ノードが無いことを示すメッセージである。

なお、上記例では、制御部３１がノード処理部２１ｂにコンテンツ所在問合せメッセージを所定のノードＮｎに送信させ、且つ、このコンテンツ所在問合せメッセージの送信前の所定時間内にＨＴＴＰリクエストをＷｅｂサーバＷＳに送信させるように構成した。しかし、このコンテンツ所在問合せメッセージの送信は、上記ステップＳ３におけるＨＴＴＰリクエストのＷｅｂサーバＷＳへの送信よりも前に行われるように構成してもよい。つまり、制御部３１がノード処理部２１ｂにコンテンツ所在問合せメッセージを所定のノードＮｎに送信させ、且つ、このコンテンツ所在問合せメッセージの送信後の所定時間内にＨＴＴＰリクエストをＷｅｂサーバＷＳに送信させるように構成してもよい。或いは、このコンテンツ所在問合せメッセージと、上記ステップＳ３におけるＨＴＴＰリクエストとが同時に送信されるように構成してもよい。

そして、ステップＳ６では、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳからコンテンツ又は再生開始に必要となる部分データが受信されたか否かを判定する。ＷｅｂサーバＷＳからコンテンツ又は再生開始に必要となる部分データが受信された場合には（ステップＳ６：ＹＥＳ）、処理はステップＳ７へ進む。一方、ＷｅｂサーバＷＳからコンテンツ又は再生開始に必要となる部分データが受信されていない場合には（ステップＳ６：ＮＯ）、処理はステップＳ１３へ進む。

ステップＳ７では、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳから受信されたコンテンツ又は再生開始に必要となる部分データをバッファメモリ２２に一時的に保存させる。

次いで、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳから受信されたコンテンツ又は再生開始に必要となる部分データを拠点ネットワークＮＬ１を介して視聴端末Ｔ１−１へ転送する（ステップＳ８）。視聴端末Ｔ１−１のＷｅｂブラウザ３１ａは、コンテンツ又は再生開始に必要となる部分データを受信すると、Ｗｅｂページに記述されたプレイヤーの識別子に対応するプレイヤー３１ｂを起動する。そして、プレイヤー３１ｂによりコンテンツの再生が開始される。

次いで、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求された全コンテンツの転送を完了したか否かを判定する（ステップＳ９）。そして、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１へ全コンテンツの転送を完了したと判定した場合には（ステップ９：ＹＥＳ）、ステップＳ１０へ進む。一方、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１へ全コンテンツの転送を完了していないと判定した場合には（ステップ９：ＮＯ）、ステップＳ１３へ進む。

ステップＳ１０では、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳからクライアント−サーバ方式で取得したコンテンツをオーバーレイネットワークＯＮへ投入する必要があるか否かを判定する。例えば、後述するステップＳ２１でオーバーレイネットワークＯＮからコンテンツを発見できないことを示す情報が記憶されていた場合、オーバーレイネットワークＯＮへ投入する必要があると判定される。そして、ノードＮ１のノード処理部２１ｂは、オーバーレイネットワークＯＮへ投入する必要があると判定した場合には（ステップ１０：ＹＥＳ）、 Ｓ１１へ進む。一方、ノードＮ１のノード処理部２１ｂは、オーバーレイネットワークＯＮへ投入する必要がないと判定した場合には（ステップ１０：ＮＯ）、図３（Ａ）に示す処理を終了する。

ステップＳ１１では、ノードＮ１のノード処理部２１ｂは、コンテンツの投入処理を行う。この投入処理では、先ず、ノードＮ１のノード処理部２１ｂは、コンテンツの投入先となる所定数のノードＮｎのＩＰアドレス及びポート番号を記憶部２３に記憶されているＩＰアドレス及びポート番号の中から取得する。例えば、投入先となるノードＮｎのＩＰアドレス及びポート番号は、ＤＨＴを用いたルーティングテーブルに登録されているＩＰアドレス及びポート番号の中から取得される。また、ノードＮ１のノード処理部２１ｂがオーバーレイネットワークＯＮを介して他のノードＮｎとの間で行ったメッセージの送受信の履歴情報が記憶部２３に記憶されている場合がある。この履歴情報に他のノードＮｎのＩＰアドレス及びポート番号が含まれている場合、この中から投入先となるノードＮｎのＩＰアドレス及びポート番号が取得されるように構成してもよい。そして、ノードＮ１のノード処理部２１ｂは、取得した各ＩＰアドレス及びポート番号に基づいてノードＮｎへアクセスし、コンテンツ保存依頼メッセージを送信する。このコンテンツ保存依頼メッセージは、コンテンツの保存を依頼するメッセージである。このコンテンツ保存依頼メッセージを受信したノードＮｎは、例えば、このノードＮｎの記憶部にコンテンツを保存するための空き領域がある場合、コンテンツ保存許可メッセージを返信する。このコンテンツ保存許可メッセージは、コンテンツの保存を許可するメッセージである。一方、コンテンツ保存依頼メッセージを受信したノードＮｎは、例えば、このノードＮｎの記憶部にコンテンツを保存するための空き領域がない場合、コンテンツ保存拒否メッセージを返信する。このコンテンツ保存拒否メッセージは、コンテンツの保存を拒否するメッセージである。そして、ノードＮ１のノード処理部２１ｂはコンテンツ保存許可メッセージを受信した場合、バッファメモリ２２に一時的に保存されているコンテンツを取得する。そして、ノードＮ１のノード処理部２１ｂは、バッファメモリ２２から取得したコンテンツを、コンテンツ保存許可メッセージを送信したノードＮｎへ送信する。こうして、コンテンツを受信したノードＮｎは、このコンテンツを保存しコンテンツ保持ノードとなる。

次いで、ノードＮ１のノード処理部２１ｂは、バッファメモリ２２に保存されているコンテンツを削除し（ステップＳ１２）、図３（Ａ）に示す処理を終了する。

ステップＳ１３では、ノードＮ１のノード処理部２１ｂは、ルートノードからインデックス情報が受信されたか否かを判定する。ルートノードからインデックス情報が受信された場合には（ステップＳ１３：ＹＥＳ）、処理はステップＳ１４へ進む。一方、ルートノードからインデックス情報が受信されていない場合には（ステップＳ１３：ＮＯ）、処理はステップＳ１５へ進む。

ステップＳ１４では、ノードＮ１のノード処理部２１ｂは、ルートノードから取得したインデックス情報から、コンテンツ保持ノードのＩＰアドレス及びポート番号を選択する。

次いで、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツを取得する要求を示すコンテンツ要求メッセージを、選択したコンテンツ保持ノードへ送信し（ステップＳ１５）、ステップＳ１６に進む。なお、上記ステップＳ３で再生開始に必要となる部分データのみがＷｅｂサーバＷＳへ要求される場合がある。この場合、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツ中の再生開始に必要となるデータを除いた範囲のコンテンツを取得する要求を示すコンテンツ要求メッセージをコンテンツ保持ノードへ送信するように構成してもよい。

ステップＳ１６では、ノードＮ１のノード処理部２１ｂは、コンテンツ保持ノードからコンテンツが受信されたか否かを判定する。コンテンツ保持ノードからコンテンツが受信された場合には（ステップＳ１６：ＹＥＳ）、処理はステップＳ１７へ進む。なお、ステップＳ１７〜Ｓ１９の処理は、ステップＳ７〜Ｓ９の処理と同様に行われる。また、コンテンツ保持ノードからコンテンツが受信されたときにＷｅｂサーバＷＳからのコンテンツが受信中である場合、ＷｅｂサーバＷＳからのコンテンツの受信は中止される。つまり、ノード処理部２１ｂは、ＷｅｂサーバＷＳから受信したコンテンツの視聴端末Ｔ１−１への転送を、コンテンツ保持ノードから受信したコンテンツの視聴端末Ｔ１−１への転送に途中で切り替える。このような動作により、視聴端末Ｔ１−１はＷｅｂサーバＷＳからのコンテンツの取得以上に待たされることなく再生を開始させることができる。

一方、コンテンツ保持ノードからコンテンツが受信されていない場合には（ステップＳ１６：ＮＯ）、処理はステップＳ２０へ進む。

ステップＳ２０では、ノードＮ１のノード処理部２１ｂは、コンテンツ無メッセージが受信されたか否かを判定する。コンテンツ無メッセージが受信された場合には（ステップＳ２０：ＹＥＳ）、処理はステップＳ２１へ進む。なお、ノードＮ１のノード処理部２１ｂは、上記ステップＳ５でコンテンツ所在問合せメッセージを送信してから所定時間以内にインデックス情報が受信されなかった場合にステップＳ２１へ進むように構成してもよい。一方、コンテンツ無メッセージが受信されていない場合には（ステップＳ２０：ＮＯ）、処理はステップＳ６へ戻る。

ステップＳ２１では、ノードＮ１のノード処理部２１ｂは、オーバーレイネットワークＯＮからコンテンツを発見できないことを示す情報を記憶する。

次いで、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳにコンテンツを取得要求済であるか否かを判定する（ステップＳ２２）。そして、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳにコンテンツを取得要求済であると判定した場合には（ステップＳ２２：ＹＥＳ）、ステップＳ６に戻る。一方、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳにコンテンツを取得要求済でないと判定した場合には（ステップＳ２２：ＮＯ）、ステップＳ２３に進む。

ステップＳ２３では、ノードＮ１のノード処理部２１ｂは、視聴端末Ｔ１−１から要求されたコンテンツを取得する要求を示すＨＴＴＰリクエストをＷｅｂサーバＷＳへ送信し、ステップＳ６に戻る。なお、上記ステップＳ３で再生開始に必要となる部分データのみをＷｅｂサーバＷＳに要求する場合がある。この場合、コンテンツの中の再生開始に必要となる部分データを除いた範囲のコンテンツをＷｅｂサーバＷＳへ要求してもよい。

以上説明したように、上記実施形態によれば、オーバーレイネットワークＯＮでコンテンツ保持ノードに保存された所定のコンテンツの所在の検索中に、このコンテンツの中の少なくとも再生開始に必要となる部分データがＷｅｂサーバＷＳから取得することが可能となる。この結果、ノードＮｎはコンテンツを安定した速度で迅速に取得することができる。その結果、視聴端末Ｔ１−１はコンテンツの再生を迅速に開始することができる。

なお、上記実施形態において、オーバーレイネットワークＯＮにおけるコンテンツ保持ノードからの応答よりも、ＷｅｂサーバＷＳからの応答の方が早い可能性が高い。しかし、ＷｅｂサーバＷＳの処理性能が低い、又はＷｅｂサーバＷＳがアクセス集中により反応が遅いなどの状況により、ＷｅｂサーバＷＳからの応答よりも、コンテンツ保持ノードからの応答の方が早い場合がある。この場合、ノードＮ１のノード処理部２１ｂは、ＷｅｂサーバＷＳからのコンテンツの送信を待たずに、コンテンツ保持ノードから受信したコンテンツを視聴端末Ｔ１−１に転送することになる。つまり、ＷｅｂサーバＷＳとコンテンツ保持ノードのうち早く応答してきた方から取得されたコンテンツが視聴端末Ｔ１−１に転送される。その結果、視聴端末Ｔ１−１は、どのような状況であっても迅速にコンテンツの再生を開始することができる。

また、上記実施形態において、本発明における定常装置として中継機器を例にとって説明したが、定常装置はネットワークＮＷに接続されているサーバ等であってもよい。また、定常装置は、基本的にネットワークＮＷに定常的に接続されているゲートウェイ等の機器であっても良い。

また、上記実施形態においては、オーバーレイネットワークＯＮに、ＤＨＴを利用したピアツーピアネットワークを適用したが、これに限られるものではない。例えば、他のオーバーレイネットワークを用いたシステムが適用されてもよい。ＤＨＴを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。

１１，２１，３１ 制御部
１２，２３，３２ 記憶部
１３，２４ａ，２４ｂ，３９ 通信部
３３ バッファメモリ
ＷＳ Ｗｅｂサーバ
Ｎｎ ノード
ＮＷ ネットワーク
ＯＮ オーバーレイネットワーク
Ｓ コンテンツ配信システム

Claims (13)

1. ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれる前記情報処理装置であって、
   前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信する第１送信手段と、
   前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信する第２送信手段と、
   前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させる制御手段と、
   前記第１送信手段により送信された前記検索要求、または、前記第２送信手段により送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得する取得手段と、
   を備えることを特徴とする情報処理装置。
2. 前記第２送信手段は、前記所定のコンテンツの中の再生開始に必要となるデータの前記取得要求を前記配信装置へ送信することを特徴とする請求項１に記載の情報処理装置。
3. 前記第１送信手段は、前記再生開始に必要となるデータを除いた範囲の前記コンテンツの前記検索要求を前記所定の情報処理装置へ送信することを特徴とする請求項２に記載の情報処理装置。
4. 前記情報処理装置は、前記オーバーレイネットワークに定常的に参加する定常装置であり、前記所定のコンテンツを取得する要求を示す取得要求を、端末装置から受信する受信手段を更に備え、
   前記制御手段は、前記受信手段により前記取得要求が受信されたときに、前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させることを特徴とする請求項１乃至３の何れか一項に記載の情報処理装置。
5. 前記第２送信手段は、再生開始に必要となるデータとして、前記コンテンツの再生に必要な制御ファイルを取得する要求を示す取得要求を、前記制御ファイルを保存している前記配信装置へ送信することを特徴とする請求項１乃至４の何れか一項に記載の情報処理装置。
6. 前記第２送信手段は、再生開始に必要となるデータとして、前記コンテンツの再生時間軸上での前記コンテンツの再生開始位置から、所定サイズのコンテンツを取得する要求を示す取得要求を、前記所定サイズのコンテンツを保存している前記配信装置へ送信することを特徴とする請求項１乃至４の何れか一項に記載の情報処理装置。
7. 前記情報処理装置は、前記所定のコンテンツが再生の重要度が高いコンテンツであるか否かを判定する判定手段を更に備え、
   前記制御手段は、前記判定手段により再生の重要度が高いコンテンツでないと判定された場合には、前記第２送信手段による前記取得要求の送信を禁止させることを特徴とする請求項１乃至４の何れか一項に記載の情報処理装置。
8. 前記判定手段は、前記所定のコンテンツがストリーミング再生されるコンテンツである場合、再生の重要度が高いコンテンツであると判定することを特徴とする請求項７に記載の情報処理装置。
9. 前記オーバーレイネットワークは、カラオケで使用されるカラオケデータを、前記コンテンツとして、前記他の情報処理装置から取得するように構成され、
   前記判定手段は、前記所定のコンテンツがカラオケ装置において予約された少なくとも１曲目のカラオケデータである場合、再生の重要度が高いコンテンツであると判定することを特徴とする請求項７に記載の情報処理装置。
10. 前記判定手段は、前記所定のコンテンツのＵＲＬに含まれる情報であってコンテンツの種類を示す情報に基づいて、再生の重要度が高いコンテンツであるか否かを判定することを特徴とする請求項７に記載の情報処理装置。
11. ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれるコンピュータに、
    前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信するステップと、
    前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信するステップと、
    前記検索要求を送信させるとともに、前記取得要求を送信させるステップと、
    前記送信された前記検索要求、または、前記送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得するステップと、
    を実行させるための情報処理プログラム。
12. ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムにおいて、
    前記情報処理装置は、
    前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信する第１送信手段と、
    前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信する第２送信手段と、
    前記第１送信手段に前記検索要求を送信させるとともに、前記第２送信手段に前記取得要求を送信させる制御手段と、
    前記第１送信手段により送信された前記検索要求、または、前記第２送信手段により送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得する取得手段と、
    を備えることを特徴とする配信システム。
13. ネットワークを介して互いに通信可能な複数の情報処理装置により構成されるオーバーレイネットワークで前記情報処理装置が他の情報処理装置からコンテンツを取得するように構成された配信システムに含まれるコンテンツ取得方法であって、
    前記オーバーレイネットワークで情報処理装置に保存された所定のコンテンツの所在を検索する要求を示す検索要求を、前記オーバーレイネットワークにおける所定の情報処理装置へ送信するステップと、
    前記所定のコンテンツの中の少なくとも再生開始に必要となる第１データを取得する要求を示す取得要求を、前記第１データを保存している配信装置へ送信するステップと、
    前記検索要求を送信させるとともに、前記取得要求を送信させるステップと、
    前記送信された前記検索要求、または、前記送信された前記取得要求の結果に基づいて、前記検索要求に対応する前記所定のコンテンツ、または、前記取得要求に対応する前記第１データを取得するステップと、
    を含むことを特徴とするコンテンツ取得方法。

Images