(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムであって、
前記複数のノード装置に含まれる一のノード装置は、
前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信手段と、
前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段と、
前記要求情報に含まれる前記識別情報が、前記記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定手段と、
前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得手段と、
前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得手段により取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信手段と、
前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信手段と、
を有することを特徴とする情報配信システム。
【請求項２】
ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおける情報配信方法であって、
前記複数のノード装置に含まれる一のノード装置が、前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信ステップと、
前記一のノード装置が、前記要求情報に含まれる前記識別情報が、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定ステップと、
前記一のノード装置が、前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得ステップと、
前記一のノード装置が、前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得ステップにおいて取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信ステップと、
前記一のノード装置が、前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信ステップと、
を含むことを特徴とする情報配信方法。
【請求項３】
ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおけるノード装置であって、
前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信手段と、
前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段と、
前記要求情報に含まれる前記識別情報が、前記記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定手段と、
前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得手段と、
前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得手段により取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信手段と、
前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信手段と、
を有することを特徴とするノード装置。
【請求項４】
請求項３に記載のノード装置であって、
前記通信繁忙度認定手段は、前記ノード情報に対応する前記コンテンツ記憶ノード装置から前記通信繁忙度に対応する通信繁忙度情報を受信することにより前記通信繁忙度を認定することを特徴とするノード装置。
【請求項５】
請求項３または４に記載のノード装置であって、
前記ストリーミング配信ノード情報送信手段は、
前記取得手段により取得された前記ノード情報に対応する前記コンテンツ受信中ノード装置における前記コンテンツの受信状況を示す受信状況情報を、前記コンテンツ受信中ノード装置から受信する受信状況情報受信手段と、
前記受信状況情報に基づいて、前記取得手段により取得された前記コンテンツ受信中ノード装置を示す前記ノード情報の中から前記ストリーミング配信ノード装置を示す前記ノード情報を少なくとも一以上選択する選択手段と、
を有し、
前記選択手段により選択された前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置。
【請求項６】
請求項３乃至５のいずれか一項に記載のノード装置であって、
前記通信繁忙度が所定の範囲外である場合には、前記ストリーミング配信ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信するストリーミング配信ノード情報送信指示情報送信手段を有することを特徴とするノード装置。
【請求項７】
請求項６に記載のノード装置であって、
前記通信繁忙度が所定の範囲内である場合には、前記コンテンツ記憶ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のコンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信するコンテンツ記憶ノード情報送信指示情報送信手段を有することを特徴とするノード装置。
【請求項８】
請求項７に記載のノード装置であって、
前記通信繁忙度が所定の範囲内である旨の所定範囲内報告情報を、前記ストリーミング配信ノード情報送信指示情報の送信先の前記ノード装置から受信する所定範囲内報告情報受信手段をさらに有し、
前記所定範囲内報告情報を受信した場合に、
前記コンテンツ記憶ノード情報送信手段は、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、
前記コンテンツ記憶ノード情報送信指示情報送信手段は、前記コンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信することを特徴とするノード装置。
【請求項９】
請求項７または８に記載のノード装置であって、
前記通信繁忙度が所定の範囲外である旨の所定範囲外報告情報を、前記コンテンツ記憶ノード情報送信指示情報の送信先の前記ノード装置から受信する所定範囲外報告情報受信手段をさらに有し、
前記所定範囲外報告情報を受信した場合に、
前記ストリーミング配信ノード情報送信手段は、前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、
前記ストリーミング配信ノード情報送信指示情報送信手段は、前記ストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信することを特徴とするノード装置。
【請求項１０】
請求項３または４に記載のノード装置であって、
前記ストリーミング配信ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から受信するストリーミング配信ノード情報送信指示情報受信手段を有し、
前記ストリーミング配信ノード情報送信指示情報を受信した場合に、前記ストリーミング配信ノード情報送信手段は、前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、
前記ストリーミング配信ノード装置を示す前記ノード情報を他の前記ノード装置に送信したことを示す送信済情報を前記ストリーミング配信ノード情報送信指示情報の送信元の前記ノード装置に送信する送信済情報送信手段を有することを特徴とするノード装置。
【請求項１１】
請求項１０に記載のノード装置であって、
前記コンテンツ記憶ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のコンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から受信するコンテンツ記憶ノード情報送信指示情報受信手段を有し、
前記コンテンツ記憶ノード情報送信指示情報を受信した場合または前記ストリーミング配信ノード情報送信指示情報を受信していない場合に、前記コンテンツ記憶ノード情報送信手段は、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置。
【請求項１２】
請求項１０または１１に記載のノード装置であって、
前記通信繁忙度が所定の範囲内である場合には、前記通信繁忙度が所定の範囲内である旨の所定範囲内報告情報を、前記ストリーミング配信ノード情報送信指示情報の送信元の前記ノード装置に送信する所定範囲内報告情報送信手段をさらに有することを特徴とするノード装置。
【請求項１３】
請求項１１に記載のノード装置であって、
前記通信繁忙度が所定の範囲外である場合には、前記通信繁忙度が所定の範囲外である旨の所定範囲外報告情報を、前記コンテンツ記憶ノード情報送信指示情報の送信元の前記ノード装置に送信する所定範囲外報告情報送信手段をさらに有することを特徴とするノード装置。
【請求項１４】
請求項３乃至１３のいずれか一項に記載のノード装置であって、
前記ストリーミング配信ノード情報送信手段は、一の前記ストリーミング配信ノード装置に対して所定の数以下の前記要求情報の送信元の前記ノード装置に、前記ストリーミング配信ノード装置を示す前記ノード情報を送信することを特徴とするノード装置。
【請求項１５】
ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおけるノード装置に含まれるコンピュータに、
前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信ステップと、
前記要求情報に含まれる前記識別情報が、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定ステップと、
前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得ステップと、
前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得ステップにおいて取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信ステップと、
前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信ステップと、
を実行させることを特徴とする情報処理プログラム。
【請求項１６】
請求項１に記載の情報配信システムであって、
前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報の送信先である前記要求情報の送信元の前記ノード装置を、新たな前記ストリーミング配信ノード装置として認定するストリーミング配信ノード装置認定手段と、
前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報と、前記認定手段により前記ストリーミング配信ノード装置として認定された前記ノード装置を示す前記ノード情報と、を対応付けて記憶する第２記憶手段と、
をさらに有し、
前記ストリーミング配信ノード情報送信手段は、
前記第２記憶手段に対応付けて記憶された前記ノード情報に基づいて、各前記ストリーミング配信ノード装置により前記コンテンツが順次転送されるように、送信される前記ノード情報を選択する選択手段を有し、
前記ストリーミング配信ノード情報送信手段は、前記選択手段により選択された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とする情報配信システム。
【請求項１７】
請求項１６に記載の情報配信システムであって、
前記選択手段は、複数の前記ストリーミング配信ノード装置により前記コンテンツの配信経路がツリー状に形成されるように、送信される前記ノード情報を選択することを特徴とする情報配信システム。
【請求項１８】
請求項１、１６及び１７のいずれか一項に記載の情報配信システムであって、
前記要求情報の送信元の前記ノード装置は、
前記ストリーミング配信ノード装置または前記コンテンツ記憶ノード装置を示す前記ノード情報を受信した場合には、前記コンテンツの送信を要求するコンテンツ要求情報を、受信した前記ノード情報に対応する前記ノード装置に送信するコンテンツ要求情報送信手段、
を有し、
前記コンテンツ要求情報を受信した前記ストリーミング配信ノード装置または前記コンテンツ記憶ノード装置は、
前記コンテンツを、前記コンテンツ要求情報の送信元のノード装置に送信するコンテンツ送信手段、
を有することを特徴とする情報配信システム。
【請求項１９】
請求項３乃至１４のいずれか一項に記載のノード装置であって、
前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報の送信先である前記要求情報の送信元の前記ノード装置を、新たな前記ストリーミング配信ノード装置として認定するストリーミング配信ノード装置認定手段と、
前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報と、前記認定手段により前記ストリーミング配信ノード装置として認定された前記ノード装置を示す前記ノード情報と、を対応付けて記憶する第２記憶手段と、
をさらに有し、
前記ストリーミング配信ノード情報送信手段は、
前記第２記憶手段に対応付けて記憶された前記ノード情報に基づいて、各前記ストリーミング配信ノード装置により前記コンテンツが順次転送されるように、送信される前記ノード情報を選択する選択手段を有し、
前記ストリーミング配信ノード情報送信手段は、前記選択手段により選択された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置。
【請求項２０】
請求項１９に記載のノード装置であって、
前記選択手段は、複数の前記ストリーミング配信ノード装置により前記コンテンツの配信経路がツリー状に形成されるように、送信される前記ノード情報を選択することを特徴とするノード装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに接続された複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型の情報（コンテンツ）配信システムに関し、特に、複数のノード装置が一のノード装置に集中してコンテンツを要求する場合にコンテンツ要求により回線が混雑する不都合を解消した情報（コンテンツ）配信システムおよび方法等の技術分野に関する。
【背景技術】
【０００２】
ピアツーピア型の情報配信システムにおいて、例えば、分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用して論理的に構築されたオーバーレイネットワークでは、各ノード装置が、当該オーバーレイネットワークに参加している全てのノード装置へのリンク情報（例えば、ＩＰアドレス）を認識しているわけではなく、参加の際などに得られる一部のノード装置へのリンク情報だけを保持しており、かかるリンク情報に基づき、データの問い合わせ等を行うようになっている。
【０００３】
このようなオーバーレイネットワークにおいては、ノード装置の参加及び脱退（離脱）が頻繁に行われても、負荷分散が適切に行われる必要があり、非特許文献１には、オーバーレイネットワークにおいて、参加及び脱退（離脱）が頻繁に行われる場合であっても、適切に負荷分散を行うための技術が開示されている。
【０００４】
こうしたピアツーピア型のコンテンツ配信システムにおいては、各ノード装置がコンテンツデータを保持するコンテンツ配信サーバとなり、また、各ノード装置がコンテンツ配信要求クライアントにもなる。
【０００５】
このようなコンテンツ配信システムにおいて、コンテンツ配信サーバであるノード装置がコンテンツデータを保持しているだけでなく、ネットワーク上の他のノード装置もコンテンツデータの複製を保持しているものが知られている。以下、コンテンツデータの複製を保持しているノード装置をレプリカノードともいう。コンテンツ配信要求クライアントであるノード装置は、要求するコンテンツをこのようなレプリカノードから入手することもできる。このようなコンテンツ配信システムは、あるコンテンツに対する配信要求が増加した場合に、コンテンツ配信サーバであるノード装置だけでなく、その複製を保持しているレプリカノード装置からもコンテンツを配信できるため、コンテンツ配信サーバであるノード装置へのアクセスの集中を回避できるものである。
【０００６】
また、Ｐ２Ｐ型のコンテンツ配信方法として、コンテンツ配信サーバと、クライアント装置群と、サーバ装置およびクライアント装置との接続関係を制御するトポロジ制御装置とで構成されたシステムにおける方法が知られている（特許文献１参照）。このコンテンツ配信方法では、クライアント装置がコンテンツ取得要求をトポロジ制御装置に問い合わせると、トポロジ制御装置において接続先候補に含まれるピア装置の識別情報をクライアント装置に通知し、クライアント装置において識別情報で示されるピア装置に対し接続を試み、クライアント装置においてパケットを受信する。トポロジ制御装置においては、接続先候補に含まれるピア装置の中から、事前に定義された選択ポリシにより接続先候補を絞り込んで抽出している。このトポロジ制御装置による動作により、あるクライアント装置に対して情報を送信するサーバ装置またはコンテンツ配信可能なクライアント装置の中から適切な接続先を選択する手段を提供し、ユーザに対してコンテンツ再生の中断、スキップ、逆戻りなどが発生しない高品質なサービスを提供している。
【非特許文献１】「分散ハッシュテーブルの軽量な負荷分散手法の検討」  社団法人  電子情報通信学会  信学技報
【特許文献１】特開２００４−２４６７９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来のサーバ−クライアント型のコンテンツ配信システムにおいては、特定の人気コンテンツを有するサーバ装置にクライアント装置からのアクセスが集中し、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが困難になるという不都合がある。
【０００８】
一方、Ｐ２Ｐ型のコンテンツ配信システムにおいては、特定の人気コンテンツを有するノード装置の他に、当該コンテンツの複製を保持しているレプリカノードを配置することにより、上述のようにコンテンツ配信サーバであるノード装置へのアクセスの集中を回避している。
【０００９】
しかしながら、レプリカノードが十分に配置されていない場合には、従来のサーバ−クライアント型のコンテンツ配信システムと同様の不都合が想定される。すなわち、コンテンツの配信を希望する複数のユーザのノード装置において、通信がとぎれたり、エラーが発生することにより、コンテンツの品質が低下する可能性が高くなる。そのため、ユーザはコンテンツをストレスなく高品質に入手して視聴することが困難になる。
【００１０】
特許文献１に開示されたコンテンツ配信方法においては、Ｐ２Ｐ型のコンテンツ配信において、いわゆるツリー型の配信トポロジを制御して適切な接続先を選択する技術が開示されているものの、ある装置に対するアクセスの集中を回避するという観点からは技術が開示されていない。
【００１１】
本発明は、以上の不都合に鑑みてなされたものであり、複数のノード装置を有するＰ２Ｐ型のコンテンツ配信システムにおいて、複数のノード装置が一のノード装置に集中してコンテンツを要求することによるコンテンツの品質低下等の不都合を解消したコンテンツ配信システム及び方法等を提供することを課題とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムであって、前記複数のノード装置に含まれる一のノード装置は、前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信手段と、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段と、前記要求情報に含まれる前記識別情報が、前記記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定手段と、前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得手段と、前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得手段により取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信手段と、前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信手段と、を有することを特徴とする情報配信システムである。
【００１３】
これによれば、クエリ（要求情報）の送信元のノード装置であるユーザのリクエストノードから、コンテンツに対応するクエリが送信された際に、クエリに含まれるコンテンツＩＤ（識別情報）とこれに対応するコンテンツノード（情報記憶ノード装置）のＩＰアドレス（ノード情報）を記憶するルートノードやキャッシュノードは、コンテンツノードの通信状況に応じて、リクエストノードがコンテンツを要求する要求先を分散させることができる。すなわち、ルートノードやキャッシュノードは、コンテンツノードの通信が局所的に集中して繁忙（混雑）している場合（通信繁忙度が所定の範囲外）には、コンテンツを受信中であるリクエストノードをストリーム型コンテンツノード（ストリーミング配信ノード装置）として、当該ストリーム型コンテンツノードのＩＰアドレスをコンテンツ要求先のノード装置としてリクエストノードに知らせる。一方、ルートノードやキャッシュノードは、コンテンツノードの通信が繁忙（混雑）していない場合（通信繁忙度が所定の範囲内）には、通常通り、コンテンツノードのＩＰアドレスをコンテンツ要求先のノード装置としてリクエストノードに知らせる。
【００１４】
したがって、コンテンツノードの通信が繁忙している場合、すなわち、特定の人気コンテンツにアクセスが集中してきた場合には、上述のようにストリーミング配信ノード情報送信手段が動作するため、多数のリクエストノードへコンテンツ配信することによりコンテンツノードに過大な負荷がかかることや、コンテンツの配信を希望する複数のユーザのリクエストノードにおいて、通信がとぎれたり、エラーが発生することにより、コンテンツの品質が低下することが防止される。その結果、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【００１５】
上記課題を解決するために、請求項２に記載の発明は、ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおける情報配信方法であって、前記複数のノード装置に含まれる一のノード装置が、前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信ステップと、前記一のノード装置が、前記要求情報に含まれる前記識別情報が、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定ステップと、前記一のノード装置が、前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得ステップと、前記一のノード装置が、前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得ステップにおいて取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信ステップと、前記一のノード装置が、前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信ステップと、を含むことを特徴とする情報配信方法である。
【００１６】
上記課題を解決するために、請求項３に記載の発明は、ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおけるノード装置であって、前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信手段と、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段と、前記要求情報に含まれる前記識別情報が、前記記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定手段と、前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得手段と、前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得手段により取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信手段と、前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信手段と、を有することを特徴とするノード装置である。
【００１７】
これによれば、上述のコンテンツの配信を希望する複数のユーザのリクエストノードにおいて希望のコンテンツをストレスなく高品質に入手して視聴することを可能とする、情報配信システムにおけるルートノードやキャッシュノードを提供できる。
【００１８】
上記課題を解決するために、請求項４に記載の発明は、請求項３に記載のノード装置であって、前記通信繁忙度認定手段は、前記ノード情報に対応する前記コンテンツ記憶ノード装置から前記通信繁忙度に対応する通信繁忙度情報を受信することにより前記通信繁忙度を認定することを特徴とするノード装置である。
【００１９】
これによれば、ルートノードやキャッシュノードは、コンテンツノードから通信繁忙度情報を直接入手することにより、その通信状況を把握し、適切なタイミングでリクエストノードの情報要求先を分散させることができる。そのため、コンテンツの配信を希望する複数のユーザのリクエストノードにおいて、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【００２０】
上記課題を解決するために、請求項５に記載の発明は、請求項３または４に記載のノード装置であって、前記ストリーミング配信ノード情報送信手段は、前記取得手段により取得された前記ノード情報に対応する前記コンテンツ受信中ノード装置における前記コンテンツの受信状況を示す受信状況情報を、前記コンテンツ受信中ノード装置から受信する受信状況情報受信手段と、前記受信状況情報に基づいて、前記取得手段により取得された前記コンテンツ受信中ノード装置を示す前記ノード情報の中から前記ストリーミング配信ノード装置を示す前記ノード情報を少なくとも一以上選択する選択手段と、を有し、前記選択手段により選択された前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置である。
【００２１】
これによれば、具体的に、コンテンツノードからコンテンツを受信中であるリクエストノード（コンテンツ受信中ノード装置）のうち、コンテンツの受信状況が良好な装置をルートノードが選択することができる。そして、ルートノードは、選択したリクエストノード（コンテンツ受信中ノード装置）をストリーム型コンテンツノードとし、当該ストリーム型コンテンツノードをコンテンツの要求先として他の新たなリクエストノードに知らせることができる。そのため、コンテンツの配信を希望する複数のユーザのリクエストノードにおいて、特にコンテンツの受信状況が良好なノード装置（ストリーム型コンテンツノード）から希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。なお、ルートノードがこのようなストリーム型コンテンツノードを選択する動作を行い、キャッシュノードは通常この動作を行わない。
【００２２】
上記課題を解決するために、請求項６に記載の発明は、請求項３乃至５のいずれか一項に記載のノード装置であって、前記通信繁忙度が所定の範囲外である場合には、前記ストリーミング配信ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信するストリーミング配信ノード情報送信指示情報送信手段を有することを特徴とするノード装置である。
【００２３】
これによれば、通信繁忙度を認定したルートノードが、通信が繁忙していると判断した場合に、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを同様に記憶している他のノード装置（キャッシュノードを示す。）に対し、ストリーム型コンテンツノードのＩＰアドレスをリクエストノードに送信すべき旨のストリーミング配信ノード情報送信指示情報を送信する。そのため、キャッシュノードにおいてクエリを受信した場合に、ルートノードまでクエリを転送することなくストリーム型コンテンツノードのＩＰアドレスをリクエストノードに知らせる（送信する）ことができ、リクエストノードが早くコンテンツ要求先のＩＰアドレスを入手できるとともに、通信の数を減らすこともできる。よって、コンテンツ配信システム全体の通信数を減らすことができ、システムにおける負荷が低減される。
【００２４】
上記課題を解決するために、請求項７に記載の発明は、請求項６に記載のノード装置であって、前記通信繁忙度が所定の範囲内である場合には、前記コンテンツ記憶ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のコンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信するコンテンツ記憶ノード情報送信指示情報送信手段を有することを特徴とするノード装置である。
【００２５】
これによれば、通信繁忙度を認定したルートノードが、通信が繁忙していないと判断した場合に、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを同様に記憶しているキャッシュノードに対し、通常のコンテンツノードのＩＰアドレスをリクエストノードに送信すべき旨のコンテンツ記憶ノード情報送信指示情報を送信する。そのため、キャッシュノードにおいてクエリを受信した場合に、ルートノードまでクエリを転送することなく通常のコンテンツノードのＩＰアドレスをリクエストノードに知らせる（送信する）ことができ、リクエストノードが早くコンテンツ要求先のＩＰアドレスを入手できるとともに、通信の数を減らすこともできる。よって、コンテンツ配信システム全体の通信数を減らすことができ、システムにおける負荷が低減される。
【００２６】
上記課題を解決するために、請求項８に記載の発明は、請求項７に記載のノード装置であって、前記通信繁忙度が所定の範囲内である旨の所定範囲内報告情報を、前記ストリーミング配信ノード情報送信指示情報の送信先の前記ノード装置から受信する所定範囲内報告情報受信手段をさらに有し、前記所定範囲内報告情報を受信した場合に、前記コンテンツ記憶ノード情報送信手段は、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、前記コンテンツ記憶ノード情報送信指示情報送信手段は、前記コンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信することを特徴とするノード装置である。
【００２７】
これによれば、通信繁忙度を認定したキャッシュノードが、通信が繁忙していないと判断した場合に、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを同様に記憶しているルートノードや他のキャッシュノードは、通信が繁忙していない旨の所定範囲内報告情報を受信する。この所定範囲内報告情報を受け取ったルートノードや他のキャッシュノードは、通常のコンテンツノードのＩＰアドレスをリクエストノードに送信するとともに、上記コンテンツ記憶ノード情報送信指示情報を送信する。そのため、コンテンツノードの通信状況が繁忙していないことをキャッシュノードが最初に知った場合に、そのことをルートノードや他のキャッシュノードに報告するため、いち早く通常のコンテンツノードを主体としたいわゆるグリッド型の通信形態に戻すことができる。
【００２８】
上記課題を解決するために、請求項９に記載の発明は、請求項７または８に記載のノード装置であって、前記通信繁忙度が所定の範囲外である旨の所定範囲外報告情報を、前記コンテンツ記憶ノード情報送信指示情報の送信先の前記ノード装置から受信する所定範囲外報告情報受信手段をさらに有し、前記所定範囲外報告情報を受信した場合に、前記ストリーミング配信ノード情報送信手段は、前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、前記ストリーミング配信ノード情報送信指示情報送信手段は、前記ストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置に送信することを特徴とするノード装置である。
【００２９】
これによれば、通信繁忙度を認定したキャッシュノードが、通信が繁忙していると判断した場合に、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを同様に記憶しているルートノードやキャッシュノードは、通信が繁忙している旨の所定範囲外報告情報を受信する。この所定範囲外報告情報を受け取ったルートノードは、ストリーム型コンテンツノードを選択するとともに、ストリーム型コンテンツノードのＩＰアドレスをリクエストノードに送信するようにし、上記ストリーミング配信ノード情報送信指示情報を送信する。そのため、コンテンツノードの通信状況が繁忙していることをキャッシュノードが最初に知った場合に、そのことをルートノードや他のキャッシュノードに報告するため、いち早くリクエストノードの情報要求先を分散させたいわゆるツリー型の通信形態に変更することができる。そして、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【００３０】
上記課題を解決するために、請求項１０に記載の発明は、請求項３または４に記載のノード装置であって、前記ストリーミング配信ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のストリーミング配信ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から受信するストリーミング配信ノード情報送信指示情報受信手段を有し、前記ストリーミング配信ノード情報送信指示情報を受信した場合に、前記ストリーミング配信ノード情報送信手段は、前記ストリーミング配信ノード装置を示す前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信し、前記ストリーミング配信ノード装置を示す前記ノード情報を他の前記ノード装置に送信したことを示す送信済情報を前記ストリーミング配信ノード情報送信指示情報の送信元の前記ノード装置に送信する送信済情報送信手段を有することを特徴とするノード装置である。
【００３１】
これによれば、ルートノードまたはキャッシュノードからストリーミング配信ノード情報送信指示情報を受信したキャッシュノードが新たなリクエストノードに対し、ストリーム型コンテンツノードのＩＰアドレスをリクエストノードに送信する。そのため、キャッシュノードは、ルートノードまでクエリを転送することなくストリーム型コンテンツノードのＩＰアドレスをリクエストノードに知らせる（送信する）ことができ、リクエストノードが早くコンテンツ要求先のＩＰアドレスを入手できるとともに、通信の数を減らすこともできる。よって、コンテンツ配信システム全体の通信数を減らすことができ、システムにおける負荷が低減される。
【００３２】
また、キャッシュノードがストリーミング配信ノード情報送信指示情報を受信した場合に、キャッシュノードがリクエストノードにコンテンツ要求先としてストリーム型コンテンツノードのＩＰアドレスを知らせる。また、キャッシュノードは、このようにリクエストノードにストリーム型コンテンツノードを知らせたことを送信済情報としてストリーミング配信ノード情報送信指示情報の送信元であるルートノードに返すこととなる。このことにより、ルートノードはその送信済情報を元に、その後リクエストノードに知らせるストリーム型コンテンツノードを選択し直すことができ、コンテンツ要求先を分散させた適切なストリーム型コンテンツノードを新たなリクエストノードに知らせることが可能となる。
【００３３】
上記課題を解決するために、請求項１１に記載の発明は、請求項１０に記載のノード装置であって、前記コンテンツ記憶ノード装置を示す前記ノード情報を前記要求情報の送信元の前記ノード装置に送信すべき旨のコンテンツ記憶ノード情報送信指示情報を、前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から受信するコンテンツ記憶ノード情報送信指示情報受信手段を有し、前記コンテンツ記憶ノード情報送信指示情報を受信した場合または前記ストリーミング配信ノード情報送信指示情報を受信していない場合に、前記コンテンツ記憶ノード情報送信手段は、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置である。
【００３４】
これによれば、キャッシュノードがルートノードまたは他のキャッシュノードからコンテンツ記憶ノード情報送信指示情報を受信した場合、または、上記ストリーミング配信ノード情報送信指示情報を受信していない場合に、キャッシュノードがクエリを受信すると、ルートノードまでクエリを転送することなく通常のコンテンツノードのＩＰアドレスをリクエストノードに知らせる（送信する）ことができ、リクエストノードが早くコンテンツ要求先のＩＰアドレスを入手できるとともに、通信の数を減らすこともできる。よって、コンテンツ配信システム全体の通信数を減らすことができ、システムにおける負荷が低減される。
【００３５】
上記課題を解決するために、請求項１２に記載の発明は、請求項１０または１１に記載のノード装置であって、前記通信繁忙度が所定の範囲内である場合には、前記通信繁忙度が所定の範囲内である旨の所定範囲内報告情報を、前記ストリーミング配信ノード情報送信指示情報の送信元の前記ノード装置に送信する所定範囲内報告情報送信手段をさらに有することを特徴とするノード装置である。
【００３６】
これによれば、通信繁忙度を認定したキャッシュノードは、通信が繁忙していないと判断した場合に、上記ストリーミング配信ノード情報送信指示情報の送信元であるルートノードやキャッシュノードに、通信が繁忙していない旨の所定範囲内報告情報を送信する。そのため、この所定範囲内報告情報を受け取ったルートノードやキャッシュノードは、通常のコンテンツノードのＩＰアドレスをリクエストノードに送信したり、他のキャッシュノードに、上記コンテンツ記憶ノード情報送信指示情報を送信することができる。よって、コンテンツノードの通信状況が繁忙していないことをキャッシュノードが最初に知った場合に、そのことをルートノードや他のキャッシュノードに報告するため、いち早く通常のコンテンツノードを主体としたいわゆるグリッド型の通信形態に戻すことができる。
【００３７】
上記課題を解決するために、請求項１３に記載の発明は、請求項１１に記載のノード装置であって、前記通信繁忙度が所定の範囲外である場合には、前記通信繁忙度が所定の範囲外である旨の所定範囲外報告情報を、前記コンテンツ記憶ノード情報送信指示情報の送信元の前記ノード装置に送信する所定範囲外報告情報送信手段をさらに有することを特徴とするノード装置である。
【００３８】
これによれば、通信繁忙度を認定したキャッシュノードが、通信が繁忙していると判断した場合に、上記コンテンツ記憶ノード情報送信指示情報の送信元であるルートノードや他のキャッシュノードに、通信が繁忙している旨の所定範囲外報告情報を送信する。そのため、この所定範囲外報告情報を受け取ったルートノードは、ストリーム型コンテンツノードを選択することができ、ストリーム型コンテンツノードのＩＰアドレスをリクエストノードに送信するとともに、上記ストリーミング配信ノード情報送信指示情報を送信する。そのため、コンテンツノードの通信状況が繁忙していることをキャッシュノードが最初に知った場合に、そのことをルートノードや他のキャッシュノードに報告するため、いち早くリクエストノードの情報要求先を分散させたいわゆるツリー型の通信形態に変更することができる。そして、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【００３９】
上記課題を解決するために、請求項１４に記載の発明は、請求項３乃至１３のいずれか一項に記載のノード装置であって、前記ストリーミング配信ノード情報送信手段は、一の前記ストリーミング配信ノード装置に対して所定の数以下の前記要求情報の送信元の前記ノード装置に、前記ストリーミング配信ノード装置を示す前記ノード情報を送信することを特徴とするノード装置である。
【００４０】
これによれば、ルートノードやキャッシュノードは、一のストリーム型コンテンツノードについて、そのＩＰアドレスを所定の数以下のリクエストノードに知らせる。そのため、一のストリーム型コンテンツノードには、所定の数以下のリクエストノードからコンテンツ要求が送信されることとなる。よって、多数のリクエストノードへコンテンツ配信することによりストリーム型コンテンツノードに過大な負荷がかかることや、コンテンツの配信を希望する複数のユーザのリクエストノードにおいて、通信がとぎれたり、エラーが発生することにより、コンテンツの品質が低下することが防止される。その結果、ストリーム型コンテンツノードにおいても、コンテンツの配信を希望する複数のユーザが、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【００４１】
上記課題を解決するために、請求項１５に記載の発明は、ネットワークを介して接続された複数のノード装置を備え、前記複数のノード装置に分散して記憶されるコンテンツが、前記複数のノード装置に含まれるノード装置から他のノード装置に配信される情報配信システムにおけるノード装置に含まれるコンピュータに、前記コンテンツを送信可能な前記ノード装置を示すノード情報の送信を要求するための要求情報であって、前記コンテンツに対応する固有の識別情報を含む前記要求情報を、前記複数のノード装置に含まれる前記ノード装置から受信する要求情報受信ステップと、前記要求情報に含まれる前記識別情報が、前記複数のノード装置に分散して記憶されるコンテンツの中で特定の前記コンテンツを記憶する前記ノード装置であるコンテンツ記憶ノード装置を示す前記ノード情報と、前記コンテンツに対応する固有の識別情報と、を対応付けて記憶する記憶手段に記憶されている場合には、前記要求情報に含まれる前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置と他のノード装置との通信の局所的集中の程度を示す通信繁忙度を認定する通信繁忙度認定ステップと、前記識別情報に対応する前記ノード情報が示す前記コンテンツ記憶ノード装置から前記コンテンツを受信中の前記ノード装置であるコンテンツ受信中ノード装置を示す前記ノード情報を、前記コンテンツ記憶ノード装置または前記要求情報に含まれる前記識別情報に対応する前記ノード情報を同様に記憶している他のノード装置から取得する取得ステップと、前記通信繁忙度が所定の範囲外である場合には、前記コンテンツをストリーミング配信する前記ノード装置であるストリーミング配信ノード装置を示す前記ノード情報として、前記取得ステップにおいて取得された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するストリーミング配信ノード情報送信ステップと、前記通信繁忙度が所定の範囲内である場合には、前記要求情報に含まれる前記識別情報に対応して前記記憶手段に記憶された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信するコンテンツ記憶ノード情報送信ステップと、を実行させることを特徴とする情報処理プログラムである。
上記課題を解決するために、請求項１６に記載の発明は、請求項１に記載の情報配信システムであって、前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報の送信先である前記要求情報の送信元の前記ノード装置を、新たな前記ストリーミング配信ノード装置として認定するストリーミング配信ノード装置認定手段と、前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報と、前記認定手段により前記ストリーミング配信ノード装置として認定された前記ノード装置を示す前記ノード情報と、を対応付けて記憶する第２記憶手段と、をさらに有し、前記ストリーミング配信ノード情報送信手段は、前記第２記憶手段に対応付けて記憶された前記ノード情報に基づいて、各前記ストリーミング配信ノード装置により前記コンテンツが順次転送されるように、送信される前記ノード情報を選択する選択手段を有し、前記ストリーミング配信ノード情報送信手段は、前記選択手段により選択された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とする情報配信システムである。
上記課題を解決するために、請求項１７に記載の発明は、請求項１６に記載の情報配信システムであって、前記選択手段は、複数の前記ストリーミング配信ノード装置により前記コンテンツの配信経路がツリー状に形成されるように、送信される前記ノード情報を選択することを特徴とする情報配信システムである。
上記課題を解決するために、請求項１８に記載の発明は、請求項１、１６及び１７のいずれか一項に記載の情報配信システムであって、前記要求情報の送信元の前記ノード装置は、前記ストリーミング配信ノード装置または前記コンテンツ記憶ノード装置を示す前記ノード情報を受信した場合には、前記コンテンツの送信を要求するコンテンツ要求情報を、受信した前記ノード情報に対応する前記ノード装置に送信するコンテンツ要求情報送信手段、を有し、前記コンテンツ要求情報を受信した前記ストリーミング配信ノード装置または前記コンテンツ記憶ノード装置は、前記コンテンツを、前記コンテンツ要求情報の送信元のノード装置に送信するコンテンツ送信手段、を有することを特徴とする情報配信システムである。
上記課題を解決するために、請求項１９に記載の発明は、請求項３乃至１４のいずれか一項に記載のノード装置であって、前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報の送信先である前記要求情報の送信元の前記ノード装置を、新たな前記ストリーミング配信ノード装置として認定するストリーミング配信ノード装置認定手段と、前記ストリーミング配信ノード情報送信手段より送信された前記ノード情報と、前記認定手段により前記ストリーミング配信ノード装置として認定された前記ノード装置を示す前記ノード情報と、を対応付けて記憶する第２記憶手段と、をさらに有し、前記ストリーミング配信ノード情報送信手段は、前記第２記憶手段に対応付けて記憶された前記ノード情報に基づいて、各前記ストリーミング配信ノード装置により前記コンテンツが順次転送されるように、送信される前記ノード情報を選択する選択手段を有し、前記ストリーミング配信ノード情報送信手段は、前記選択手段により選択された前記ノード情報を、前記要求情報の送信元の前記ノード装置に送信することを特徴とするノード装置である。
上記課題を解決するために、請求項２０に記載の発明は、請求項１９に記載のノード装置であって、前記選択手段は、複数の前記ストリーミング配信ノード装置により前記コンテンツの配信経路がツリー状に形成されるように、送信される前記ノード情報を選択することを特徴とするノード装置である。
【発明の効果】
【００４２】
本発明によれば、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【発明を実施するための最良の形態】
【００４３】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、配信する情報をコンテンツ情報とし、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。
【００４４】
［１．コンテンツ配信システムの構成等］
始めに、図１を参照して、情報配信システムとしてのコンテンツ配信システムの概要構成等について説明する。
【００４５】
図１は、本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【００４６】
図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、および通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界のネットワーク）８が構築されている。
【００４７】
コンテンツ配信システムＳは、このようなネットワーク８を介して相互に接続された複数のノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・を備えて構成されることになり、ピアツーピア方式のネットワークシステムとなっている。各ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・には、ノード装置を示す情報（本発明におけるノード情報）としての固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。なお、製造番号およびＩＰアドレスは、複数のノード装置１間で重複しないものである。なお、以下の説明において、ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・のうち何れかのノード装置を示す場合には、便宜上、ノード装置１という場合がある。
【００４８】
［１．１．ＤＨＴの概要］
以下に、本実施形態に係る分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用したアルゴリズムについて説明する。
【００４９】
上述したコンテンツ配信システムＳにおいて、当該ノード装置１同士が、互いに情報をやり取りする際には、お互いのノード情報としてのＩＰアドレスを知っていなければならない。
【００５０】
例えば、コンテンツを互いに共有するシステムにおいては、ネットワーク８に参加している各ノード装置１が互いにネットワーク８に参加している全てのノード装置１のＩＰアドレスを知っておくのが単純な手法であるが、端末数が何万何十万と多数になると、その全てのノード装置１のＩＰアドレスを覚えておくのは現実的ではない。また、任意のノード装置の電源がＯＮ或いはＯＦＦとすると、各ノード装置１にて記憶している当該任意のノード装置のＩＰアドレスの更新が頻繁になり、運用上困難となる。
【００５１】
そこで、１台のノード装置１では、ネットワーク８に参加している全てのノード装置１のうち、必要最低限のノード装置１のＩＰアドレスだけを覚えて（記憶して）おいて、ＩＰアドレスを知らない（記憶していない）ノード装置１については、各ノード装置１間で互いに情報を転送し合って届けてもらうというシステムが考案されている。
【００５２】
このようなシステムの一例として、ＤＨＴを利用したアルゴリズムによって、図１の上部枠１００内に示すような、オーバレイネットワーク９が構築されることになる。つまり、このオーバレイネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するネットワークを意味する。
【００５３】
本実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバレイネットワーク９を前提としており、このオーバレイネットワーク９上に配置されたノード装置１を、コンテンツ配信システムＳに参加（言い換えれば、オーバレイネットワーク９に参加）しているノード装置１という。なお、コンテンツ配信システムＳへの参加は、未だ参加していないノード装置が、既に参加している任意のノード装置１に対して参加要求を送ることによって行われる。
【００５４】
コンテンツ配信システムＳに参加している各ノード装置１のノードＩＤ（識別情報）は、それぞれのノード装置毎にユニーク（固有）な番号を付与する。この番号は、ノード装置の最大運用台数を収容できるだけのｂｉｔ数を持たせる必要がある。例えば、１２８ｂｉｔの番号とすれば、2＾128＝340×10＾36台のノード装置を運用できる。
【００５５】
より具体的には、各ノード装置１のノードＩＤは、それぞれのノード装置のＩＰアドレスあるいは製造番号等のノード装置毎に固有の値を、共通のハッシュ関数（ハッシュアルゴリズム）によりハッシュ化して得たハッシュ値であり、一つのＩＤ空間に偏りなく分散して配置されることになる。このように共通のハッシュ関数により求められた（ハッシュ化された）ノードＩＤは、当該ＩＰアドレスあるいは製造番号が異なれば、同じ値になる確率が極めて低いものである。なお、ハッシュ関数については公知であるので詳しい説明を省略する。なお、本実施形態では、ＩＰアドレス（グローバルＩＰアドレス）を共通のハッシュ関数によりハッシュ化した値をノードＩＤとする。
【００５６】
また、コンテンツ配信システムＳに参加している複数のノード装置１には、１のノード装置１から他のノード装置1に配信される共用情報としてのコンテンツ（例えば、映画や音楽等）データが分散して保存（格納）されているが、当該コンテンツデータにも、それぞれのコンテンツデータ毎にユニーク（固有）な番号（以下、コンテンツＩＤ（本発明の識別情報）という。）を付与する。
【００５７】
そして、当該コンテンツＩＤは、ノードＩＤと同様の長さ（例えば、１２８ｂｉｔ等）とし、例えば、コンテンツの名称（コンテンツタイトル）やコンテンツの概要情報（あらすじ）等のキーワードが、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化され（つまり、ノード装置１のＩＰアドレスのハッシュ値と同一のＩＤ空間に配置）、そのハッシュ値と最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノード装置１が、当該コンテンツデータが保存するか、あるいは、コンテンツデータを保持するノード装置へのリンク情報（コンテンツ保持ノードのＩＰアドレス）を保持する。これにより、コンテンツデータを偏りなくコンテンツ配信システムＳ上に分散させることが可能となる。なお、異なるコンテンツデータであっても、同一のキーワード（例えば、コンテンツの名称）になる場合が想定されるが、この場合、同じハッシュ値になってしまうので、これを避けるために、ハッシュ化するキーワードを、例えば、コンテンツの名称と著作権情報（例えば、出演者名、監督名、原作者名、歌手名、作曲者名、または作詞者名等）の組み合わせとすればよい。
【００５８】
このように、各ノード装置１および各コンテンツデータに付与されたノードＩＤおよびコンテンツＩＤは、共通のハッシュ関数によって生成したため、図２に示す如く、同一のリング状のＩＤ空間上にさほど偏ることなく、散らばって存在するものとして考えることができる。同図は３２ｂｉｔでノードＩＤおよびコンテンツＩＤを付与し、図示したものである。図中黒点はノードＩＤを、黒ひし形はコンテンツＩＤを示し、反時計回りでＩＤが増加するものとする。
【００５９】
次に、どのノード装置１に、どのコンテンツデータが保存されるかを、一定の規則の下に決定する。本実施形態においては、「あるコンテンツＩＤを有するコンテンツデータを管理するノード装置は、そのコンテンツＩＤに近いノードＩＤを有するノード装置１である」という規則とする。ここで、「近い」ことの定義は、当該コンテンツＩＤを超えず、コンテンツＩＤとノードＩＤとの差が一番少ないものとするが、実際には、各コンテンツデータの管理を各ノード装置１に割り振る際に、一貫していればよい。同図に示す例では、この定義に基づいて、コンテンツＩＤａは、ノードＩＤａを有するノード装置に管理され、コンテンツＩＤｂは、ノードＩＤｂを有するノード装置に管理され、コンテンツＩＤｃは、ノードＩＤｃを有するノード装置１に管理される。
【００６０】
なお、ここで「管理」というのは、コンテンツデータを保存／保持していることを意味するのではなく、「コンテンツデータが何れのノード装置１に保存されているかを知っている」ことを言う。すなわち、図２において、ノードＩＤａを有するノード装置１は、コンテンツＩＤａを有するコンテンツデータが何れのノード装置１に保存されているかを知っており、ノードＩＤｂを有するノード装置１およびノードＩＤｃを有するノード装置１も同様にそれぞれコンテンツＩＤｂを有するコンテンツデータおよびコンテンツＩＤｃを有するコンテンツデータが何れのノード装置１に保存されているかを知っている、ということになる。このように、あるコンテンツデータが何れのノード装置１に保存されているかを知っているノード装置を、そのコンテンツデータのルートノードと言う。つまり、ノードＩＤａを有するノード装置１は、コンテンツＩＤａを有するコンテンツデータのルートノードであって、ノードＩＤｂを有するノード装置１は、コンテンツＩＤｂを有するコンテンツデータのルートノードであって、ノードＩＤｃを有するノード装置１は、コンテンツＩＤｃを有するコンテンツデータのルートノードである。また、コンテンツデータを保持（記憶）しているノード装置１をコンテンツノードという。
【００６１】
［１．２．ルーティングテーブルの作成］
ここで、図３を参照して、ＤＨＴで用いるルーティングテーブルの作成手法の一例について説明する。
【００６２】
図３は、ＤＨＴによってルーティングテーブルが作成される様子の一例を示す図である。
【００６３】
まず、図３（Ａ）に示す如く、ＩＤ空間を幾つかのエリアに分割する。実際には、１６分割程度が良く用いられるが、説明を簡単にするためここでは４分割とし、ＩＤをビット長１６Ｂｉｔの４進数で表すこととした。そして、ノード装置１ＮのノードＩＤを「10230210」とし、このノード装置１Ｎのルーティングテーブルを作る例について説明する。
【００６４】
（レベル１のルーティング）
まず、ＩＤ空間を４分割とすると、それぞれのエリアは４進数で表すと最大桁が異なる４つのエリア「0XXXXXXX」「1XXXXXXX」、「2XXXXXXX」、「3XXXXXXX」（Ｘは０から３の自然数、以下同様。）で分けられる。ノード装置１Ｎは、当該ノード装置１Ｎ自身のノードＩＤが「10230210」であるため、図中左下「1XXXXXXX」のエリアに存在することになる。そして、ノード装置１Ｎは、自分の存在するエリア（すなわち、「1XXXXXXX」のエリア）以外のエリアに存在するノード装置１を適当に選択し、当該ノードＩＤのＩＰアドレスをレベル１のテーブルに記憶する。図４（Ａ）がレベル１のテーブルの一例である。２列目はノード装置１Ｎ自身を示しているため、ＩＰアドレスを記憶する必要は無い。
【００６５】
（レベル２のルーティング）
次に、図３（Ｂ）に示す如く、上記ルーティングによって４分割したエリアのうち、自分の存在するエリアを更に４分割し、更に４つのエリア「10XXXXXX」「11XXXXXX」、「12XXXXXX」、「13XXXXXX」と分ける。そして、上記と同様に自分の存在するエリア以外のエリアに存在するノード装置１を適当に選択し、当該ノードＩＤのＩＰアドレスをレベル２のテーブルに記憶する。図４（Ｂ）がレベル２のテーブルの一例である。１列目はノード装置１Ｎ自身を示しているため、ＩＰアドレスを記憶する必要は無い。
【００６６】
（レベル３のルーティング）
さらに、図３（Ｃ）に示す如く、上記ルーティングによって４分割したエリアのうち、自分の存在するエリアを更に４分割し、更に４つのエリア「100XXXXX」「101XXXXX」、「102XXXXX」、「103XXXXX」と分ける。そして、上記と同様に自分の存在するエリア以外のエリアに存在するノード装置１を適当に選択し、当該ノードＩＤのＩＰアドレスをレベル１のテーブルに記憶する。図４（Ｃ）がレベル３のテーブルの一例である。３列目はノード装置１Ｎ自身を示しているため、ＩＰアドレスを記憶する必要は無く、２列目、４列目はそのエリアにノード装置が存在しないため空白となる。
【００６７】
このようにして、レベル４以下レベル８まで同様にルーティングテーブル図４（Ｄ）に示す如く作成することにより、１６ｂｉｔのＩＤ全てを網羅することができる。レベルが上がる毎にテーブルの中に空白が目立つようになる。
【００６８】
以上説明した手法に従って作成したルーティングテーブルを、全てのノード装置１が夫々作成して所有することになる。
【００６９】
［１．３．コンテンツデータの検索方法］
次に、図５を参照して、コンテンツデータの保存元であるノード装置１の検索方法の一例について説明する。
【００７０】
図５は、ＤＨＴによりコンテンツデータの保存元であるノード装置１が検索される様子の一例を示す図である。
【００７１】
ここでは、ノードＩＤ「12003030」のノード装置１−１（以下、このようにコンテンツデータを探し、コンテンツデータの受信を要求するノード装置を「リクエストノード」と言う。）が、コンテンツＩＤ「31330012」を有するコンテンツデータを探す際の手順について説明する。
【００７２】
リクエストノードは、自己が保持しているルーティングテーブルのレベル１のテーブルを参照して、コンテンツＩＤ「31330012」と同じエリアのノードＩＤを持つノード装置に対してコンテンツの在処を問い合わせる要求情報（以下、本発明の「要求情報」（コンテンツの在処を問い合わせる要求情報）を「クエリ」と言う。）を送信する。つまり、コンテンツＩＤ「31330012」は「3XXXXXXX」のエリアであるため、当該「3XXXXXXX」のエリアに属すノード装置１のうち、ＩＰアドレスを知っている（すなわち、自己が保持しているルーティングテーブルにＩＰアドレスが記憶されている）ノード装置１−２に対してクエリを送信する。このように、クエリはコンテンツに対応する固有の識別情報であるコンテンツＩＤを含むものである。
【００７３】
図５に示す例に拠れば、ノードＩＤが「30100000」であるノード装置１−２のＩＰアドレスがリクエストノードのルーティングテーブルに記憶されていたので、リクエストノードは、ノードＩＤが「30100000」であるノード装置１−２に対してクエリを送信する。
【００７４】
次に、クエリを受信したノード装置１−２は、当該ノード装置１−２自身が保持しているルーティングテーブルのレベル２のテーブルを参照して、「31XXXXXX」のエリアに属すノード装置１のうち、ＩＰアドレスを知っているノード装置１−３（ノードＩＤ「31012001」）に対してクエリを転送する。
【００７５】
このように、コンテンツＩＤの桁を上から順に適合していく要領でクエリの転送が進み、最終的に当該コンテンツデータを管理するノード装置１−５、すなわちルートノードに辿り着くと、当該ルートノードは、クエリに含まれるコンテンツＩＤ「31330012」を、自身が管理しているインデックス情報（後述する）の中から検索し、当該コンテンツデータを所有しているノード装置１のＩＰアドレス等をリクエストノードに返信するようになっている。
【００７６】
こうして、リクエストノード（ノード装置１−１）は、上記ルートノード（ノード装置１−５）から、コンテンツＩＤ「31330012」のコンテンツデータの所在、即ち、保存元のノード装置１のＩＰアドレスを受信して知ることになり、当該保存元のノード装置１から、そのコンテンツデータを取得（ダウンロード）することになる。
【００７７】
［１．４．コンテンツデータの登録方法］
このような構成のコンテンツ配信システムＳの中で、例えば、あるノード装置１が新しいコンテンツデータを、コンテンツ配信システムＳ上の他のノード装置に見えるように公開する際の手法について述べる。このノード装置１がコンテンツデータを保持する（記憶する）情報記憶ノード装置としてのコンテンツノードとなる。
【００７８】
当該コンテンツノードは、コンテンツのタイトル等からコンテンツＩＤを求め、当該コンテンツＩＤと同じノードＩＤを持つノード装置に向けて（このノード装置が実在するか否かはこの時点ではわからない。）公開メッセージを送信する。そして、この公開メッセージも、上記クエリと同様にルーティングテーブルに従って、次々と転送されていき、当該公開メッセージに含まれるコンテンツＩＤに最も近いノードＩＤを有するノード装置１まで転送されたところで、そのノード装置１はもはや送信先のノード装置が他にないと判断すると、当該ノード装置１自身がそのコンテンツのルートノードとなるべきだと判断し、当該コンテンツＩＤ、補助情報（タイトル、ジャンル等の属性情報や、監督名等の著作権情報等）およびコンテンツノードのＩＰアドレスをインデックス情報として記憶する。
【００７９】
更にまた、本実施形態では、ルートノードに至る経路の途中のノード装置でも、当該ルートノードが記憶しているインデックス情報をキャッシュとして保持しておくキャッシュノードを備える。これにより、ルートノードがクエリを受信するより前に、より早くキャッシュノード装置にクエリが転送された時点でキャッシュノードがコンテンツノードのＩＰアドレスを、コンテンツの所在を問い合わせたリクエストノードに返信することが可能になる。
【００８０】
公開メッセージを転送していく際には、通常、上述のようにキャッシュノードがインデックス情報のみを保持していく。一方、後述する実施形態においては、必要に応じて、図６に示すように、各キャッシュノードがインデックス情報を保持するとともに、自らのＩＰアドレスおよびその手前でインデックス情報を保持しているキャッシュノードのＩＰアドレスをインデックス情報とともに次のキャッシュノードやルートノードへ転送する。
【００８１】
従って、図６においては、コンテンツノードがインデックス情報を含む公開メッセージを送信すると、これを受け取ったノード装置１は、当該インデックス情報を保持することによりキャッシュノード（１）として機能する。そして、キャッシュノード（１）は、公開メッセージに自らのＩＰアドレス情報を付加して転送する。当該公開メッセージを受け取ったノード装置１は、当該インデックス情報およびキャッシュノード（１）のＩＰアドレス情報を保持することによりキャッシュノード（２）として機能する。そして、キャッシュノード（２）は、キャッシュノード（１）のＩＰアドレス情報が付加された公開メッセージに、さらに自らのＩＰアドレス情報を付加して転送する。当該公開メッセージを受け取ったノード装置１は、当該インデックス情報およびキャッシュノード（１）、（２）のＩＰアドレス情報を保持することによりルートノードとして機能する。なお、図６においては、コンテンツノードとルートノードの間の二台のノード装置がキャッシュノードとして機能することとしたが、これに限定されず、キャッシュノードの台数や転送されるノード装置全てをキャッシュノードとするか否か、等はそのコンテンツ配信システムＳにおいて自由に決定することができる。
【００８２】
［２．ノード装置の構成等］
次に、図７を参照して、ノード装置１の構成および機能について説明する。尚、各ノード装置１は、それぞれが行う処理によってコンテンツの所在を問い合わせるクエリを送信するリクエストノード、当該リクエストノードや経路上の端末からクエリを受信するキャッシュノードまたはルートノード、リクエストノードによって問い合わせの対象とされているコンテンツを保持する情報記憶ノード装置としてのコンテンツノード、コンテンツをダウンロード中（配信中）であり当該コンテンツを一部記憶している情報部分記憶ノード装置としてのストリーム型コンテンツノード（リクエストノードでもある）として作用するが、その構成は同じである。
【００８３】
図７は、ノード装置１の概要構成例を示す図である。
【００８４】
各ノード装置１は、図７に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、上記コンテンツデータ、上記インデックス情報、上記ＤＨＴおよびプログラム等を記憶保存（格納）するためのＨＤ等から構成された記憶手段としての記憶部１２（上記コンテンツデータは、保存されていないノード装置１もある）と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）およびオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４および通信部２０はバス２２を介して相互に接続されている。
【００８５】
そして、制御部１１におけるＣＰＵが記憶部１２等に記憶された各種プログラムを実行することにより、ノード装置１全体を統括制御するようになっており、また、入力部２１からの指示信号に応じて、コンテンツデータ登録処理等を行うようになっている。ノード装置１は、実行されるプログラムに応じて、リクエストノード、キャッシュノード、ルートノード、情報記憶ノード装置としてのコンテンツノード、情報部分記憶ノード装置としてのストリーム型コンテンツノード（コンテンツ配信（受信）中のノード装置としてのダウンロード中ノード）として機能する。
【００８６】
具体的には、ノード装置１がリクエストノードとして機能する際には、当該制御部１１は、コンテンツの在処を問い合わせる要求情報（クエリ）送信手段、共用情報（コンテンツ）要求情報送信手段、として機能する。ノード装置１がキャッシュノード或いはルートノードとして機能する際には、当該制御部１１は、記憶手段、要求情報受信手段、通信繁忙度認定手段、情報部分記憶ノード情報送信手段、情報記憶ノード情報送信手段、として機能する。
【００８７】
また、ノード装置１がルートノードとして機能する際には、当該制御部１１は、配信中ノード情報受信手段、受信状況情報受信手段、選択手段、通信繁忙時指示情報送信手段、非通信繁忙時指示情報送信手段、非通信繁忙時報告情報受信手段、通信繁忙時報告情報受信手段として機能する。ノード装置１がキャッシュノードとして機能する際には、当該制御部１１は、通信繁忙時指示情報受信手段、送信済情報送信手段、非通信繁忙時指示情報受信手段、非通信繁忙時報告情報送信手段、通信繁忙時報告情報送信手段として機能する。ノード装置１がコンテンツノード（情報記憶ノード装置）或いはストリーム型コンテンツノード（情報部分記憶ノード装置）として機能する際には、当該制御部１１は、共用情報要求情報受信手段、共用情報送信手段として機能する。
【００８８】
［３．コンテンツ配信システムの概略］
本実施形態のコンテンツ配信システムＳの概略を説明する。図１の上部枠１００内、図８の上部枠１００内に示すようなオーバレイネットワーク９（いわゆるグリッド型のネットワーク）において、複数のノード装置（例えば、１ａ、１ｄ、１ｅ、１ｆ、１ｊ、１ｚ（斜格子線で示す））が特定のコンテンツデータを有する一のノード装置（例えば、１ｈ（格子線で示す））に集中して当該コンテンツデータをダウンロードしようとした場合に、図８の下部枠１０２内に示すように、リクエストノードのコンテンツ要求先を分散させるものである。
【００８９】
すなわち、本実施形態のコンテンツ配信システムＳは、特定の人気のあるコンテンツデータを有するコンテンツノードに通信が集中する（コンテンツがレプリカノードに記憶されて複製が作られていく時間に比べて短い時間にリクエストが数多く発生した場合に、特定のコンテンツノードにアクセスが局所的に集中する）と、いわゆるグリッド型の通信形態からいわゆるツリー型の通信形態に変更するものである。具体的に、図８の上部枠１００および下部枠１０２に示すように、特定の人気のあるコンテンツを有する一のコンテンツノード装置１ｈから、過去に当該コンテンツを要求してリクエストノードとなり、コンテンツをダウンロードしてその一部を保持している他のノード装置１ｅ、１ｚ（以下、「ダウンロード中ノード」という。）が存在する。そして、これらのノード装置１ｅ、１ｚから、さらに他の新たにリクエストノードとなったノード装置１ａ、１ｄ、１ｆ、１ｊがコンテンツデータをダウンロードするよう、後に詳述するようにルートノードが管理するものである。
【００９０】
このように、上述のダウンロード中ノード１ｅ、１ｚは、自身がコンテンツをノード装置１ｈから受信するとともに、受信したコンテンツを次々に他のノード装置に配信していくようになり、コンテンツがストリーミング配信されているようであるため、このようなノード装置１ｅ、１ｚを、本実施形態においては「ストリーム型コンテンツノード」という。
【００９１】
このようにリクエストノードのコンテンツ要求先を分散させることにより、人気コンテンツを保有するノード装置への通信の集中が防止でき、通信が途中で途切れるなど、コンテンツ情報の品質の低下が防止できるため、コンテンツ情報を要求するノード装置のユーザがコンテンツ情報をストレスなく視聴することができる。
【００９２】
［３．１コンテンツ配信システムの動作］
次に、コンテンツ配信システムＳの動作について図９乃至図２１を用いて説明する。
【００９３】
［３．１．１．コンテンツ配信システム全体の動作］
まず、コンテンツ配信システムＳ全体の動作について、図９乃至図１４を参照し、例を挙げて説明する。図９および図１０は、ルートノードがストリーム型コンテンツノードを選択する際の動作を説明する図である。図１１乃至図１４は、リクエストノードが所望のコンテンツデータを保持するコンテンツノードの所在を問い合わせる際のリクエストノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、キャッシュノード間のシーケンスチャートである。
【００９４】
（１）  コンテンツノードの通信状況が繁忙（混雑）している場合
まず、コンテンツノードの通信状況が繁忙（混雑）している場合の動作について、図９乃至図１２を参照して説明する。なお、必要に応じて上述の図面を参照する。
【００９５】
この動作の前提として、図６、図９および図１０に示すように、リクエストノードが配信を要求するコンテンツのコンテンツＩＤ（識別情報）を「30210113」、このコンテンツを記憶するコンテンツノードのＩＰアドレス（ノード情報）を「100.23.156.1」とする。
【００９６】
まず、図９および図１０について説明する。図９（Ａ）は、ルートノードが複数のリクエストノードからストリーム型コンテンツノードを選択する際に作成する情報テーブルであり、コンテンツノードの通信が繁忙し始めた瞬間に作成されるストリーム型コンテンツノードの情報テーブルを示す。図９（Ｂ）は、図９（Ａ）の情報テーブルに対応するものであり、コンテンツノードにリクエストノードからのアクセスが集中し、コンテンツノードの通信が繁忙し始めた瞬間（もしくは通信が繁忙し始める直前）のコンテンツ配信形態を示す模式図である。
【００９７】
図１０（Ａ）は、図９（Ａ）の情報テーブルが更新されたものであり、コンテンツノードの通信が繁忙し始めた後、さらに増えたリクエストノードを含めて作成されるストリーム型コンテンツノードの情報テーブルを示す。図１０（Ｂ）は、図１０（Ａ）の情報テーブルに対応し、ストリーム型コンテンツノードが作成されたツリー型のコンテンツ配信形態を示す模式図である。
【００９８】
図９（Ｂ）に示すようにコンテンツノードにリクエストノードからのアクセスが集中してくると、ルートノードは、コンテンツノードの通信繁忙度が所定の範囲外（局所的集中が発生している）と判断し、図９（Ａ）に示すように、複数のリクエストノードからストリーム型コンテンツノードを選択するための情報テーブルを作成する。この情報テーブルは、ルートノードが管理するコンテンツノードごとに作成され、ルートノードの記憶部１２に記憶される。なお、複数のコンテンツノードのＩＰアドレスを記憶している場合には、複数の情報テーブルが作成される。
【００９９】
ルートノードは、ストリーム型コンテンツノードの情報テーブルの作成を開始すると、図９（Ａ）に示すように、ダウンロード中ノード情報（配信中ノード情報）として、各ダウンロード中ノードのノードＩＤ、ＩＰアドレス、各ダウンロード中ノードのクエリ送信日時の情報を取得する。図９（Ａ）乃至図１０（Ｂ）においては、この各ダウンロード中ノードについて、仮にノード番号＜１＞〜＜７＞を付している。
【０１００】
次いで、ルートノードは、図９（Ａ）に示すように、受信状況情報として、ＤＬ（ダウンロード）開始日時、ＤＬ（ダウンロード）元とのＨＯＰ数、ＤＬ（ダウンロード）ステータス、想定有効帯域等の情報を取得する。ルートノードはコンテンツノードの通信繁忙時（通信繁忙度が所定の範囲外）に新規リクエストノードからのクエリを受信すると、これらの受信状況情報からストリーム型コンテンツを選択するための情報として、環境評価値、ＤＬ（ダウンロード）可能装置数、ＤＬ（ダウンロード）中装置数等を決定（推定）する。これらの環境評価値、ＤＬ可能装置数、ＤＬ中装置数等の情報を配信能力情報とする。
【０１０１】
次いで、ルートノードは、図１０（Ａ）に示すように、配信能力情報を参照して、新規のリクエストノード（ノード番号＜４＞〜＜７＞のノード装置）に紹介すべきＤＬ（ダウンロード）元ＩＰアドレスを決定し、このＩＰアドレスを新規リクエストノードからのクエリの返答として返信する。このとき、後述のように、新規リクエストノードに知らせるＤＬ元ＩＰアドレスに対応するノード装置１に対し、他のノード装置１にコンテンツのダウンロードが可能か否かを問い合わせてもよい。そして、トポロジー情報としてのＤＬ中の装置のＩＰアドレス、ツリー内での段数等の情報が、リクエストノードがコンテンツを受信する元のストリーム型コンテンツノード等に従って決定される。この図１０（Ａ）に示すトポロジー情報から、図１０（Ｂ）に示すようなツリー型の配信形態が把握される。そして、図１０（Ｂ）の状態の後、ノード番号＜５＞や＜７＞のノード装置１に、新規なリクエストノードが接続されて（図１０（Ｂ）の破線の矢印と楕円欄参照）、コンテンツを配信することとなる。
【０１０２】
ここで、図９（Ａ）および図１０（Ａ）の情報テーブルにおける各情報について説明する。
【０１０３】
クエリ送信日時は、ダウンロード中ノードがクエリを送信した日時を示し、ダウンロード開始日時は、ダウンロード中ノードがダウンロードを開始した日時を示す。
【０１０４】
ダウンロード元とのＨＯＰ数は、ダウンロード中ノードからダウンロード元であるコンテンツノードまでのホップ数を示し、このホップ数はダウンロード中ノードがコンテンツノードとやり取りを行う際にＩＰパケット中のＴＴＬフィールドの減少量等から取得することができる。ホップ数が小さい程、ダウンロード中ノードからコンテンツノードまでが近く、ダウンロード中ノードの受信状況が良好であることを示す。
【０１０５】
ダウンロードステータスは、ダウンロード中ノードにおけるダウンロード済コンテンツの割合を示し、ダウンロードステータスが１００％に近い程、ダウンロード中コンテンツの受信が終了に近いことを示す。リクエストノードは、ダウンロードステータスが１００％に近いノード装置１（ストリーム型コンテンツノード）からコンテンツをダウンロードした方が、最後までコンテンツデータが途切れずに受信できる確率が高くなる。そのため、後述するストリーム型コンテンツノードを選択するためのポリシーにもよるが、ルートノードは、リクエストノードに返答するストリーム型コンテンツノードを選択する際に、ダウンロードステータスが１００％に近いノード装置１の優先順位を上げて選択することができる。
【０１０６】
想定有効帯域は、ダウンロード中ノードにおいて想定される通信速度をｂｐｓ（bit per second）単位で表したもので、この大きさが大きい程、ダウンロード中ノードの受信状況が良好であることを示す。想定有効帯域は、ダウンロード中ノードから直接得てもよいし、上記したダウンロード開始日時とダウンロードステータスからルートノードが算出したものであってもよい。本実施形態において、想定有効帯域はダウンロード中ノードから直接得たものとし、ダウンロード中ノード自身が想定有効帯域を認識していない等、想定有効帯域の情報が得られなかった場合には、図１０（Ａ）のノード番号＜４＞および＜６＞のようにunknownで示される。
【０１０７】
環境評価値は、ダウンロード中ノードの通信環境を評価した値であり、本実施形態においては、Ａを最も良好とし、Ｄおよびunknownを最も良好でないとしている。環境評価値は、上述のダウンロード元とのＨＯＰ数、ダウンロードステータス、想定有効帯域等の少なくともいずれか一つから算出される。本実施形態においては、想定有効帯域のみから環境評価値を算出し、想定有効帯域２０Ｍｂｐｓ以上を環境評価値Ａ、想定有効帯域１０Ｍｂｐｓ以上２０Ｍｂｐｓ未満を環境評価値Ｂ、想定有効帯域５Ｍｂｐｓ以上１０Ｍｂｐｓ未満を環境評価値Ｃ、想定有効帯域５Ｍｂｐｓ未満を環境評価値Ｄとし、想定有効帯域が不明なもの（unknown）は同様に環境評価値もunknownとしている。
【０１０８】
ダウンロード可能装置数は、１台のノード装置１から同時にダウンロード可能な装置の台数を示すものであり、環境評価値に応じて推定される。ダウンロード可能装置数は、本実施形態においては、環境評価値Ａ：４台、環境評価値Ｂ：２台、環境評価値Ｃ：１台、環境評価値Ｄおよび環境評価値unknown：０台、としている。ダウンロード可能装置数が１台以上のダウンロード中ノードは、ストリーム型コンテンツノードとして認定されたノード装置であり、ダウンロード可能装置数が０台のダウンロード中ノードは、ストリーム型コンテンツノードとして認定されなかったノード装置である。このようにして、ルートノードは、ネットワーク環境が良いダウンロード中ノードを他のノード装置にコンテンツを配信できる装置として一以上選択する。
【０１０９】
ダウンロード中の装置数は、現時点で実際に該当ノード装置からコンテンツをダウンロードしているノード装置の数を示す。このダウンロード中の装置数がダウンロード可能装置数を超えないようにルートノードにおいて管理される。情報テーブルを作成し始めた時点では、図９（Ａ）に示すようにダウンロード中の装置数はゼロであるが、リクエストノードが増えてきた後の図１０（Ａ）においては、ノード番号＜１＞のダウンロード中ノード装置からダウンロードしているリクエストノードが１台、ノード番号＜２＞のダウンロード中ノード装置からダウンロードしているリクエストノードが２台、ノード番号＜５＞のダウンロード中ノード装置からダウンロードしているリクエストノードが１台、となっている。
【０１１０】
ＤＬ元ＩＰアドレスは、当該ノード装置１がどのノード装置から直接コンテンツデータをダウンロードするのか、ダウンロードしているのか、を示すノード情報である。すなわち、ＤＬ元ＩＰアドレスは、当該ノード装置１のツリー型の配信形態における上流に向けてのリンク情報といえる。なお、通信非繁忙時（通信繁忙度が所定の範囲内）には、ダウンロード元ＩＰアドレスは、いずれもルートノードが管理するコンテンツノードのＩＰアドレス「100.23.156.1」となる。
【０１１１】
ＤＬ中の装置のＩＰアドレスは、当該ノード装置１からツリー型の配信形態の下流に向けて、どのノード装置１にコンテンツを配信しているか、を示す情報である。すなわち、ＤＬ中の装置のＩＰアドレスは、当該ノード装置１のツリー型の配信形態における下流に向けてのリンク情報といえる。一のノード装置から複数のノード装置にコンテンツを配信する場合もあるので、ＤＬ中の装置のＩＰアドレスは、図１０（Ａ）のノード番号＜２＞のノード装置のように、複数のＩＰアドレスのリストとして保持する。
【０１１２】
ツリー内での段数は、当該ノード装置１がツリー型の配信形態の何段目に位置するかを示す数字である。ツリー内での段数は、ツリー型の配信形態に新規のリクエストノードを追加する際、当該新規のリクエストノードをどの枝（ノード装置１）に接続するのが良いかを判断するときに参照される。
【０１１３】
これらのトポロジー情報（ＤＬ元ＩＰアドレス、ＤＬ中の装置のＩＰアドレス、ツリー内での段数の３つの情報）により、ツリー型の配信形態のトポロジーが把握できる。
【０１１４】
なお、図９（Ａ）の情報テーブルにおいては、通信が繁忙し始めた時点の情報を示しているため、ＤＬ元ＩＰアドレスは、全てのノード装置１（ノード番号＜１＞〜＜３＞）において、コンテンツノードのＩＰアドレス「100.23.156.1」を示している。その後にクエリを送信した当該コンテンツに対する新規のリクエストノードは、図９（Ａ）の情報テーブルの下欄に順次管理されていき、例えば、図１０（Ａ）で追加されたノード番号＜４＞のノード装置１は、ノード番号＜１＞のノード装置に接続するように管理した結果、当該＜Ａ＞ノード装置のＤＬ元ＩＰアドレスは、ストリーム型コンテンツノードであるノード番号＜１＞のノード装置のＩＰアドレス「205.60.222.23」となっている。言い換えると、ノード番号＜４＞のノード装置がクエリを発したときに、ルートノードがクエリの返答として、ノード番号＜１＞のノード装置のＩＰアドレスを返答した結果、図１０（Ａ）の情報テーブルおよび図１０（Ｂ）のツリー型の配信形態になったものである。
【０１１５】
このように、ルートノードはツリー型の配信形態のトポロジー情報の管理もできるように情報テーブルを保持している。すなわち、どのノードがどのノードからコンテンツをダウンロードしているかという情報をルートノードがすべて把握しており、新たにリクエストノードが現れた場合、配信ツリーのどの位置に接続すべきかを紹介する事が出来る。
【０１１６】
ここで、図９（Ａ）、図１０（Ａ）に示す情報テーブルにおけるトポロジー情報等の各種情報は、これに限定されず、実施形態に応じて変更することができる。例えば、各ノード装置を示す記憶変数間をポインタで繋ぎ、ＬＩＳＰのＳ式を用いて (0 (1 (4)) (2 (5 (7)) (6)) (3))のような記憶形式としても良い。
【０１１７】
また、さらにリクエストノードがもうひとつ現れた場合は、ルートノードは、図１０（Ｂ）の破線で表された位置につながるようにストリーム型コンテンツノードを選んで、そのノード装置１のＩＰアドレスを、クエリの返答として返信する。この例では接続候補がノード番号＜５＞と＜７＞の２つあるが、どのように選択するかは、様々なポリシーが考えられ、様々な方法が可能である。
【０１１８】
例えば、なるべくツリーをバランス良く成長させたい、というポリシーの場合は、ツリー内での段数の浅いノードから順に、ＤＬ数に余裕のあるノード（ＤＬ可能装置数とＤＬ中装置数の差が１以上のノード）を選ぶと良い。ツリーのバランスが良くないと、極端に長い枝が出来て、その枝に含まれるノード装置１がもし脱退した場合に、多くの下流のノード装置１に影響が出るため、避けた方がよい。図９、図１０の例で言うと、＜６＞のノードがクエリしたときに、＜５＞の下流も空いていたはずだが、段数の浅い＜２＞のほうを優先して紹介した結果、図１０（Ａ）および（Ｂ）のように接続されている。あるいは、各ノード装置１がなるべく均等に負荷を分担するようにしたい、というポリシーの場合は、ＤＬ数に余裕のあるノードのうちから余裕の最も多いノードを選ぶと良い。あるいは、ストリーミング途中での再生中断をできるだけ避けたい、というポリシーの場合は、なるべくＤＬステータスが１００％に近いノードを選ぶと良い。
【０１１９】
なお、図９（Ａ）に示す「ルートノードが管理するストリーム型コンテンツノードの情報テーブル」においては、さらに時間が進んだ場合、ダウンロードが完了した（ダウンロードステータスが１００％となった）ストリーム型コンテンツノードを削除して、新たなコンテンツノード（レプリカノード）として管理したり、どのストリーム型コンテンツノードからどのリクエストノードがダウンロードしているか、等を管理する情報を追加する等、ストリーム型コンテンツノードの認定を更新していくことができる。また、後述するように、コンテンツノードの通信状況が繁忙でなくなると、図９（Ａ）、図１０（Ａ）に示す「ルートノードが管理するストリーム型コンテンツノードの情報テーブル」がルートノードの記憶部１２において削除される。当該情報テーブルが削除される形態については、図１７のステップＳ５７において詳述する。
【０１２０】
次いで、図１１を参照してコンテンツノードの通信状況が繁忙（混雑）している場合のシステムＳの動作を説明する。図１１に示すように、リクエストノードがクエリ（コンテンツＩＤ「30210113」を含む。）を送信すると、場合によっては中間ノードを介してルートノードにクエリが転送される（１）。図５に示した例によれば、ノード装置１−１がリクエストノードとなり、ノード装置１−２、１−３、１−４が中間ノードとなり、ノード装置１−５がルートノードとなる。
【０１２１】
クエリを受信したルートノードは、クエリに含まれるコンテンツＩＤを、自身が管理（記憶）しているインデックス情報の中から検索し、図６に示すようにコンテンツＩＤ「30210113」とこれに対応するコンテンツノードのＩＰアドレス「100.23.156.1」を記憶しているため、コンテンツノードに対して通信繁忙度を問い合わせる（２）。
【０１２２】
そして、コンテンツノードは、自身の通信繁忙度を認定し、これに対応する通信繁忙度情報をルートノードに送信する（３）。具体的に、コンテンツノードは、図９（Ａ）、（Ｂ）に示すように、現在３つのノード装置にコンテンツを配信中であること等を示す通信繁忙度情報を送信する。なお、コンテンツノードは、この時点で通信繁忙度が所定の範囲外である旨等の情報をルートノードに送信してもよい。
【０１２３】
次いで、ルートノードは、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲外、すなわち、コンテンツノードが非常に混雑していると判断した場合（４）、リクエストノードのコンテンツ要求先を分散すべく、コンテンツノードに対してコンテンツ配信（受信）中のノード装置（上述のダウンロード中ノードを示す。）を問い合わせる（５）。
【０１２４】
そして、コンテンツノードは、ダウンロード中ノードを確認し（６）、これらの各ノード装置に対応する配信中ノード情報（ＩＰアドレス：図９（Ａ）参照）をルートノードに送信する（７）。次いで、ルートノードは、受信した配信中ノード情報を元に、図９（Ａ）に示すようなストリーム型コンテンツノード情報テーブルの作成を開始し（８）、受信したＩＰアドレスに対応するダウンロード中ノード（このときはリクエストノード）に対し、コンテンツ受信状況（クエリ日時、ダウンロード開始日時、ダウンロード元とのＨＯＰ数、ダウンロードステータス、想定有効帯域等）を問い合わせる（９）。コンテンツ受信状況を問い合わせられたダウンロード中ノードは、可能な範囲で受信状況を示す受信状況情報（図９（Ａ）参照）をルートノードに送信する（１０）。なお、「可能な範囲」としたのは、ダウンロード中ノードがコンテンツの受信状況を認識していない場合にまで受信状況情報を送らせるものではないことを示し、例えば、図１０（Ａ）に示すように、ノード番号＜４＞、＜６＞のノード装置１から想定有効帯域が得られなければ、ルートノードにおいては「unknown」と認識する。
【０１２５】
ダウンロード中ノードから受信状況情報を得たルートノードは、想定有効帯域等から、図９（Ａ）に示すように、ストリーム型コンテンツノードを選択するための情報を作成する。具体的には、図９（Ａ）を用いて上述したように、環境評価値、ダウンロード可能装置数、ダウンロード中の装置数、ダウンロード元ＩＰアドレス、ダウンロード中のノード装置１のＩＰアドレスのリスト、ツリー内での段数、を決定する。なお、この段階ではストリーム型コンテンツノードを決定するための処理を行っているため、この時点でのダウンロード元ＩＰアドレスは、コンテンツノードのＩＰアドレスであり、ダウンロード中のＩＰアドレスのリストは空であり、ダウンロード中の装置数は０（ゼロ）である。
【０１２６】
ルートノードは、これらの配信中ノード情報、受信状況情報、ストリーム型コンテンツノードを選択するための情報を、「ストリーム型コンテンツノード情報テーブル」として記憶する（図９（Ａ））。
【０１２７】
そして、ルートノードは、環境評価値から他の装置にコンテンツを配信できる配信中ノード装置として選択した一以上のノード装置（例えば、ノード番号＜１＞、＜２＞のノード装置１）に対し、コンテンツ情報配信が可能か問い合わせる（１１）。なお、ここで、ルートノードで推定したＤＬ可能装置数が、確度の高いものであるならば、この問い合わせは省略しても良い。あるいは逆に、確度の低い推定しか出来ない場合には、情報テーブルに環境評価値を持たない構成としても良い。
【０１２８】
このようにして問い合わせられたダウンロード中ノードが、コンテンツ情報配信が可能とルートノードに送信した場合（１２）、ルートノードは当該ノード装置をストリーム型コンテンツノードとして認定する（１３）。そして、ルートノードは、ストリーム型コンテンツノードとして認定したノード装置の中からリクエストノードにＩＰアドレスを知らせる（送信する）ノード装置を選択する。ストリーム型コンテンツノードの選択の仕方については、上述のトポロジー情報について説明した通りである。
【０１２９】
ルートノードは、選択されたストリーム型コンテンツノードのＩＰアドレスをコンテンツ要求先とし、リクエストノードにクエリへの返信として送信する（１４）。なお、ルートノードは、一のストリーム型コンテンツノードに対して所定の数（上述のダウンロード可能装置数）以下のリクエストノード（クエリの送信元のノード装置）に、当該ストリーム型コンテンツノードのＩＰアドレスを送信することが好ましい。このことにより、ストリーム型コンテンツノードの通信状況が混雑し、通信がとぎれたり、エラーが発生することにより、コンテンツの品質が低下することが防止される。その結果、コンテンツの配信を希望する複数のユーザのノード装置において、希望のコンテンツをストレスなく高品質に入手して視聴することが可能となる。
【０１３０】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するストリーム型コンテンツノードに対し、コンテンツ要求（本発明の共用情報要求情報）を送信する（１５）。当該コンテンツ要求を受けたストリーム型コンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（１６）。このようにして、コンテンツ配信システムＳは、一時的に図１０（Ｂ）に示すようないわゆるツリー型の通信形態となり、コンテンツノードにおける通信の混雑が緩和される。なお、新たなリクエストノードがストリーム型コンテンツノードからのコンテンツのダウンロードを開始すると、ルートノードは、図９（Ａ）および図１０（Ａ）に示すノード装置１を増やし、配信能力情報やトポロジー情報、受信状況情報のＤＬステータス等を更新していく。
【０１３１】
また、ストリーム型コンテンツノードをルートノードが選択すると（１３）、「ストリーム型コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の通信繁忙時指示情報をルートノードがキャッシュノードに対して送信する（１７）。このとき、図６に示すように、ルートノードにはコンテンツノードの公開メッセージが転送されてくる際に併せてキャッシュノードのＩＰアドレスが転送されてくるので、ルートノードは、当該ＩＰアドレスに対応する全てのキャッシュノードに通信繁忙時指示情報を送信する。
【０１３２】
その後、リクエストノードがクエリを送信し、中間ノードを介してキャッシュノードにクエリが転送された場合（１８）、キャッシュノードは、コンテンツ要求先としてストリーム型コンテンツノードを示すＩＰアドレスを、クエリの送信元のリクエストノードに送信する（１９）。
【０１３３】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するストリーム型コンテンツノードに対し、コンテンツ要求を送信する（２０）。当該コンテンツ要求を受けたストリーム型コンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（２１）。
【０１３４】
次いで、図１２を参照してコンテンツノードの通信状況が繁忙（混雑）している場合のシステムＳの他の動作を説明する。図１２は、ルートノードよりも先にキャッシュノードがコンテンツノードに通信繁忙度を問い合わせて、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲外、すなわち、コンテンツノードが非常に混雑していると判断した場合の動作を示す。なお、以下においては、図１１を用いて説明した事項と同様の事項については省略して説明する。
【０１３５】
図１２に示すように、リクエストノードがクエリを送信すると、場合によっては中間ノードを介してキャッシュノードにクエリが転送される（３１）。
【０１３６】
クエリを受信したキャッシュノードは、クエリに含まれるコンテンツＩＤを、自身が管理（記憶）しているインデックス情報の中から検索し、自身がキャッシュノードであることを判断し、コンテンツノードに対して通信繁忙度を問い合わせる（３２）。
【０１３７】
そして、コンテンツノードは、自身の通信繁忙度を認定し、これに対応する通信繁忙度情報をキャッシュノードに送信する（３３）。キャッシュノードは、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲外、すなわち、コンテンツノードが非常に混雑していると判断した場合（３４）、通信繁忙度が所定の範囲外である旨の通信繁忙時報告情報をルートノードに送信する（３５）。キャッシュノードがルートノードに通信繁忙時報告情報を送信する際には、クエリが転送されるのと同様の手順で送信される。
【０１３８】
そして、ルートノードにおいては、図１１に示した通信繁忙度が所定の範囲外であると自身で判断したときの（４〜１３）と同様に、ストリーム型コンテンツノード情報テーブルを作成し（３６〜４４）、ストリーム型コンテンツノードとなるノード装置を選択し、上述の（１７）と同様の通信繁忙時指示情報をキャッシュノードに送信する（４５）。
【０１３９】
そして、キャッシュノードは、指示されたストリーム型コンテンツノードのＩＰアドレスをコンテンツ要求先としてリクエストノードに送信する（４６）。
【０１４０】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するストリーム型コンテンツノードに対し、コンテンツ要求を送信する（４７）。当該コンテンツ要求を受けたストリーム型コンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（４８）。
【０１４１】
一方、キャッシュノードは、指示されたストリーム型コンテンツノードのＩＰアドレスをコンテンツ要求先としてリクエストノードに送信すると（４６）、そのことを示す送信済情報をルートノードに送信する（４９）。
【０１４２】
送信済情報を受信したルートノードは、そのＩＰアドレスに対応するストリーム型コンテンツノードから一台のリクエストノードがコンテンツダウンロード中であることを考慮して、ストリーム型コンテンツノード情報テーブルを更新する（５０）。ここでは、ダウンロード中の装置数やダウンロード中の装置のＩＰアドレスの情報等を更新し、ツリー型の通信形態に参加しているノード装置１を新たにストリーム型コンテンツノードとして情報テーブルに追加登録し、ツリー型の通信形態におけるトポロジー情報の更新を行う。
【０１４３】
なお、情報テーブルの更新について、上述のようにキャッシュノードがリクエストノードからのクエリに返答した段階でトポロジー情報を更新するのではなく、リクエストノードが実際にコンテンツノードからデータを受け取り始めようとしたときに情報テーブルを更新することがより好ましい。この場合、クエリだけ送信して実際にはコンテンツのダウンロードを開始しないリクエストノードがあった場合に、ルートノードが情報テーブルをより正確に保持できることとなる。このような形態とする場合には、図１２における（４９）の処理の代わりに、リクエストノードからルートノードに対して「あるストリーム型コンテンツノードからコンテンツのダウンロードを開始した」旨の報告情報を送信することになる。
【０１４４】
このように、キャッシュノードがルートノードと同様にストリーム型コンテンツノードをリクエストノードに知らせることにより、特にコンテンツデータを保持しているノード装置が複数ある場合に、ルートノードにクエリが集中して転送され、ルートノードにおいて処理が滞ることを防止できる。
【０１４５】
（２）  コンテンツノードの通信状況が繁忙（混雑）していない場合
次いで、コンテンツノードの通信状況が繁忙（混雑）していない場合の動作について、図１３、図１４を参照して説明する。なお、必要に応じて上述の図面を参照する。
【０１４６】
図１３に示すように、リクエストノードがクエリを送信すると、場合によっては中間ノードを介してルートノードにクエリが転送される（５１）。
【０１４７】
クエリを受信したルートノードは、クエリに含まれるコンテンツＩＤを、自身が管理（記憶）しているインデックス情報の中から検索し、自身がルートノードであることを判断し、コンテンツノードに対して通信繁忙度を問い合わせる（５２）。
【０１４８】
そして、コンテンツノードは、自身の通信繁忙度を認定し、これに対応する通信繁忙度情報をルートノードに送信する（５３）。ルートノードは、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲内、すなわち、コンテンツノードが空いていると判断した場合（５４）、上述のストリーム型コンテンツノード情報テーブルが作成されている場合にはこのテーブルを削除して、通常と同様にコンテンツノードのＩＰアドレスをコンテンツ要求先としてクエリ送信元のリクエストノードに送信する（５５）。
【０１４９】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するコンテンツノードに対し、コンテンツ要求を送信する（５６）。当該コンテンツ要求を受けたコンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（５７）。
【０１５０】
また、通信繁忙度が所定の範囲内であるとルートノードが判断すると（５４）、「コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の非通信繁忙時指示情報をルートノードがキャッシュノードに対して送信する（５８）。
【０１５１】
その後、リクエストノードがクエリを送信し、中間ノードを介してキャッシュノードにクエリが転送された場合（５９）、キャッシュノードは、コンテンツ要求先としてコンテンツノードを示すＩＰアドレスを、クエリの送信元のリクエストノードに送信する（６０）。
【０１５２】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するコンテンツノードに対し、コンテンツ要求を送信する（６１）。当該コンテンツ要求を受けたコンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（６２）。
【０１５３】
次いで、図１４を参照してコンテンツノードの通信状況が繁忙（混雑）していない場合のシステムＳの他の動作を説明する。図１４は、ルートノードよりも先にキャッシュノードがコンテンツノードに通信繁忙度を問い合わせて、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲内、すなわち、コンテンツノードが空いてきたことを判断した場合の動作を示す。
【０１５４】
図１４に示すように、リクエストノードがクエリを送信すると、場合によっては中間ノードを介してキャッシュノードにクエリが転送される（７１）。
【０１５５】
クエリを受信したキャッシュノードは、クエリに含まれるコンテンツＩＤを、自身が管理（記憶）しているインデックス情報の中から検索し、自身がキャッシュノードであることを判断し、コンテンツノードに対して通信繁忙度を問い合わせる（７２）。
【０１５６】
通信繁忙度を問い合わせられたコンテンツノードは、自身の通信繁忙度を認定し、これに対応する通信繁忙度情報をキャッシュノードに送信する（７３）。キャッシュノードは、受信した通信繁忙度情報に対応する通信繁忙度が所定の範囲内、すなわち、コンテンツノードが空いていると判断した場合（７４）、通信繁忙度が所定の範囲内である旨の非通信繁忙時報告情報をルートノードに送信する（７５）。
【０１５７】
そして、キャッシュノードは、コンテンツ要求先としてコンテンツノードを示すＩＰアドレスを、クエリの送信元のリクエストノードに送信する（７６）。
【０１５８】
コンテンツ要求先のＩＰアドレスを受信したリクエストノードは、当該ＩＰアドレスに対応するコンテンツノードに対し、コンテンツ要求を送信する（７７）。当該コンテンツ要求を受けたコンテンツノードは、コンテンツ要求の送信元のリクエストノードに対し、コンテンツの配信を開始する（７８）。
【０１５９】
一方、非通信繁忙時報告情報を受信したルートノードにおいては（７５）、上述のストリーム型コンテンツノード情報テーブルが作成されている場合には、このテーブルを削除して、上述と同様の非通信繁忙時指示情報をキャッシュノードに送信する（７９）。このとき、ルートノードは、上述の非通信繁忙時報告情報の送信元のキャッシュノード以外のキャッシュノードのみに当該非通信繁忙時指示情報を送付してもよい。
【０１６０】
［３．１．２．各ノードの動作］
次に、リクエストノードがコンテンツ要求を行う際のそれぞれのノードで行なわれる処理について詳細に説明するが、上述したように、コンテンツ配信システムＳに含まれる全てのノード装置１は、リクエストノード、キャッシュノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、経路上の中間ノード或いはその他のノード等、何れのノード装置にもなり得る。
【０１６１】
例えば、ユーザがノード装置１に備えられた入力部２１を操作することによって、所望のコンテンツデータの所在の問い合わせが指示されると、当該ノード装置１がクエリを送信するリクエストノードして機能する。また、当該リクエストノードからクエリを受信しコンテンツデータの所在の問い合わせがされたノード装置１は、自身の記憶部１２に記憶したインデックス情報に当該コンテンツの情報（ノードＩＤおよびこれに対応するＩＰアドレス）が在る場合にはキャッシュノード或いはルートノードとして機能する。なお、自身がキャッシュノードであるかルートノードであるか、については、［１．４．コンテンツデータの登録方法］において説明したように、問い合わせをされたコンテンツＩＤが自己のノードＩＤと最も近いかどうか（ルーティングテーブルを見て他に転送先がないかどうか）という判断で、各ノード装置１において認識される。また、自身が当該コンテンツを保持している場合にはコンテンツノードとして機能する。さらに、リクエストノードであるノード装置１は、コンテンツをダウンロード中である場合にはダウンロード中ノードとして機能し、そのときダウンロード中であるコンテンツを他のノード装置１へ配信することとなった場合には、当該ノード装置１はストリーム型コンテンツノードとして機能する。
【０１６２】
以下に、それぞれのノードとして機能する際にノード装置１で行なわれる処理について図１５乃至図２１を用いて詳細に説明する。
【０１６３】
まず、図１５を用いて、ノード装置１が受けたメッセージ（または入力処理）により、制御部１１がどのような処理を行うか、リクエストノード等のどのノード装置の役割を担うか、について説明する。図１５は、ノード装置１におけるメッセージ解析処理を示すフローチャートである。
【０１６４】
ノード装置１の制御部１１は、電源が入れられたことを認識すると（電源オン：ステップＳ１）、ノード装置１の表示部１６におけるＵＩ表示等やポートの設定を初期化し（ステップＳ２）、電源が切られたか否か？（電源オフか？）の判断を行う（ステップＳ３）。通常は電源が急に切られないため、制御部１１は電源が切られていないと判断し（ステップＳ３ＮＯ）、入力部２１からのコンテンツの視聴要求の入力があったか否かを判断する（ステップＳ４）。制御部１１が入力部２１からの「コンテンツの視聴要求の入力」があったと判断した場合には（ステップＳ４ＹＥＳ）、ノード装置１はリクエストノードとして動作し、クエリ送信処理を行う（ステップＳ５）。なお、リクエストノードはその後ダウンロード中ノードとなり、また、ストリーム型コンテンツノードとなる場合がある。
【０１６５】
一方、制御部１１が入力部２１からの「コンテンツの視聴要求の入力」がなかったと判断した場合には（ステップＳ４ＮＯ）、制御部１１が通信部２０からメッセージを受信したか否かを判断する（ステップＳ６）。制御部１１が通信部２０からメッセージを受信していないと判断した場合には（ステップＳ６ＮＯ）、ステップＳ３に戻り、制御部１１が通信部２０からメッセージを受信したと判断した場合には（ステップＳ６ＹＥＳ）、通信部２０から受信したメッセージを解析する（ステップＳ７）。
【０１６６】
制御部１１が解析したメッセージが「クエリ」であった場合には、ノード装置１がそのクエリに含まれるコンテンツＩＤに対応するＩＰアドレスを記憶しているか否か、からノード装置１自身がルートノードまたはキャッシュノードであるか否かを判断する（ステップＳ８）。クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを記憶していない場合には、ノード装置１はそのコンテンツのルートノードおよびキャッシュノードでないため、制御部１１はそのように判断し（ステップＳ８ＮＯ）、受信したクエリを転送する処理を行う（ステップＳ９）。クエリを転送する処理は、上述の通りである。
【０１６７】
クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを記憶している場合には、ノード装置１の制御部１１は、問い合わせられたコンテンツＩＤが自己のノードＩＤと最も近いか否か（ルーティングテーブルを参照して他に転送先がないかどうか）という判断から、そのコンテンツのルートノードであるか、キャッシュノードであるか、を判断する（ステップＳ８）。これより制御部１１が、問い合わせられたコンテンツＩＤが自己のノードＩＤと最も近く、自身が当該コンテンツＩＤのルートノードであると判断した場合には（ステップＳ８ルートノード）、コンテンツノード（ストリーム型コンテンツノードを含む）のノード情報であるＩＰアドレスを送信するための処理（１）を行う（ステップＳ１０）。一方、ステップＳ８において、ノード装置１の制御部１１は、問い合わせられたコンテンツＩＤが自己のノードＩＤと最も近くなく、他に転送先があるため、自身が当該コンテンツＩＤのキャッシュノードであると判断した場合には（ステップＳ８キャッシュノード）、コンテンツノード（ストリーム型コンテンツノードを含む）のノード情報であるＩＰアドレスを送信するための処理（２）を行う（ステップＳ１１）。
【０１６８】
制御部１１が解析したメッセージが「指示情報」であった場合には、ノード装置１はキャッシュノードまたはその他のノード装置１として動作し、指示情報対応処理を行う（ステップＳ１２）。制御部１１が解析したメッセージが「報告情報」であった場合には、ノード装置１はルートノード、キャッシュノードまたはその他のノード装置１として動作し、報告情報対応処理を行う（ステップＳ１３）。
【０１６９】
制御部１１が解析したメッセージが「コンテンツ要求（共用情報要求情報）」であった場合には、ノード装置１はコンテンツノードまたはストリーム型コンテンツノードとして動作し、コンテンツ配信処理（ステップＳ１４）を行う。
【０１７０】
これらの各ステップＳ５、Ｓ９〜Ｓ１４の後、ノード装置１の制御部１１は、ステップＳ３の処理に戻る。制御部１１は、再度電源が切られたか否か？の判断を行い（ステップＳ３）、ノード装置１の電源が切られた場合には、制御部１１は電源が切られたと判断し（ステップＳ３ＹＥＳ）、この処理を終了する（エンド）。
【０１７１】
以下に各ノード装置１の処理について説明する。
【０１７２】
［３．１．２．1．リクエストノードの処理］
図１６を用いてリクエストノードの処理およびリクエストノードがダウンロード中ノード、ストリーム型コンテンツノードになる処理（上述のステップＳ５）について説明する。図１６は、リクエストノードの制御部１１に記憶されたプログラムが当該制御部１１により実行されることにより行われる処理を示すフローチャートである。
【０１７３】
ユーザが入力部２１を操作することにより、コンテンツのタイトル等を入力し、所望のコンテンツデータの所在の問い合わせが行われると（ステップＳ５：スタート）、このことを認識した制御部１１は、当該コンテンツのタイトル等をハッシュ化して当該コンテンツデータを示すコンテンツＩＤ（共用情報に対応する固有の識別情報）を生成すると共に、当該生成されたコンテンツＩＤを含むクエリを、記憶部１２に記憶したルーティングテーブルを参照して他のノード装置１に送信する（ステップＳ２１）。当該他のノード装置１の選択手法は、上述した「１−３コンテンツデータの検索方法」にて詳細に説明した手法に拠る。
【０１７４】
次に、ルートノード或いはキャッシュノードからコンテンツノードのＩＰアドレス情報（ノード情報）を受信すると（ステップＳ２２）、当該ＩＰアドレス情報により特定されるコンテンツノードに対してコンテンツ要求情報を送信し（ステップＳ２３）、コンテンツを受信する（ステップＳ２４）。このとき、このノード装置１はダウンロード中ノードとなる。次いで、コンテンツ受信が完了したかを判断し（ステップＳ２５）、このままコンテンツ受信が完了すると（ステップＳ２５ＹＥＳ）、受信（ダウンロード）したコンテンツの再生処理を行い（ステップＳ２６）、ルートノードへレプリカノード（実際にはコンテンツノードと同様のコンテンツを保持しているため、コンテンツノードと区別されない）として登録し（ステップＳ２７）、処理を終了する（エンド）。
【０１７５】
他方、ステップＳ２５においてコンテンツ受信が完了していない場合には（ステップＳ２５ＮＯ）、制御部１１はルートノードから受信状況の問い合わせがあったか否かを判断し（ステップＳ２８）、受信状況の問い合わせがない場合には（ステップＳ２８ＮＯ）、ステップＳ２５に戻ってＳ２５とＳ２８の判断を繰り返しながらコンテンツ受信を続ける。
【０１７６】
また、受信状況の問い合わせがあった場合には（ステップＳ２８ＹＥＳ）、制御部１１は、問い合わせられた受信状況の情報を問い合わせ元のルートノードに送信する（ステップＳ２９）。次いで、「他のノード装置に現在受信中のコンテンツの配信が可能か」の問い合わせがあったか否かを判断し（ステップＳ３０）、「コンテンツ配信が可能か」の問い合わせがない場合には、制御部１１はそのように判断し（ステップＳ３０ＮＯ）、コンテンツの受信が完了するまで受信を続け（ステップＳ３１）、上述のステップＳ２６に進む。
【０１７７】
一方、「コンテンツ配信が可能か」の問い合わせがあった場合には、制御部１１はそのように判断し（ステップＳ３０ＹＥＳ）、さらに、他のノード装置１にコンテンツを配信できる環境にあるか否かを判断する（ステップＳ３２）。
【０１７８】
制御部１１が他のノード装置１にコンテンツを配信できる環境にあると判断した場合には（ステップＳ３２ＹＥＳ）、他のノード装置１にコンテンツを配信できる旨のメッセージを問い合わせ元のルートノードに送信し（ステップＳ３３）、上述のステップＳ３１に進む。他方、制御部１１が他のノード装置にコンテンツを配信できる環境にないと判断した場合には（ステップＳ３２ＮＯ）、他のノード装置にコンテンツを配信できない旨のメッセージを問い合わせ元のルートノードに送信し（ステップＳ３４）、上述のステップＳ３１に進む。そして、ステップＳ３１においてコンテンツの受信が完了した場合には、上記と同様に、ダウンロードしたコンテンツの再生処理を行い（ステップＳ２６）、ルートノードへレプリカノード（実際にはコンテンツノードと同様のコンテンツを保持しているため、コンテンツノードと区別されない）として登録し（ステップＳ２７）、この処理を終了する（エンド）。
【０１７９】
［３．１．２．２．ルートノードの処理］
図１７および図１８を用いてルートノードの処理（上述のステップＳ１０およびステップＳ１３）について説明する。図１７および図１８は、ルートノードの制御部１１に記憶されたプログラムが当該制御部１１により実行されることにより行われる処理を示すフローチャートである。
【０１８０】
まず、図１７を用いてルートノードが記憶するコンテンツＩＤとＩＰアドレスの組み合わせにおけるコンテンツＩＤと同一のコンテンツＩＤを含むクエリをルートノードが受信した場合の処理を説明する。
【０１８１】
ルートノードの制御部１１は、クエリが転送されて当該クエリに含まれるコンテンツＩＤから、問い合わせられたコンテンツＩＤが自己のノードＩＤと最も近く、転送先がないために自身が当該コンテンツＩＤのルートノードであると判断し（ステップＳ８ルートノード）、コンテンツノードのＩＰアドレスを送信するための処理（１）を開始する（ステップＳ１０：スタート）。
【０１８２】
まず、制御部１１は、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを検索して、コンテンツノードに通信繁忙度を問い合わせる（ステップＳ４１）。次いで、制御部１１はコンテンツノードから受信した通信繁忙度情報から通信繁忙度が所定範囲内か否かを判断する（ステップＳ４２）。制御部１１は、コンテンツノードの通信状況が著しく混雑しており、通信繁忙度が所定範囲外と判断すると（ステップＳ４２ＮＯ）、再度コンテンツノードへコンテンツを配信中のノード装置（上述のダウンロード中ノード）を問い合わせる（ステップＳ４３）。
【０１８３】
制御部１１は、コンテンツノードからコンテンツダウンロード中ノードを示す配信中ノード情報（ＩＰアドレス）を受信すると（ステップＳ４４）、ストリーム型コンテンツノード情報テーブルの作成を開始し、当該ＩＰアドレスに対応するノード装置（ダウンロード中ノード）に対し、コンテンツの受信状況を問い合わせる（ステップＳ４５）。
【０１８４】
次いで、制御部１１は、コンテンツの受信状況の情報（各ダウンロード中ノードのクエリ送信日時、ダウンロード開始日時、ダウンロード元ＩＰアドレス、ダウンロード元とのＨＯＰ数、ダウンロードステータス、想定有効帯域等の情報）を各ダウンロード中ノードから受信すると（ステップＳ４６）、この受信状況の情報に基づいて、ストリーム型コンテンツノードを選択するための情報（環境評価値、ダウンロード可能装置数、ツリー分岐段数、新ダウンロード元ＩＰアドレス、ダウンロード中の装置数）を決定する（ステップＳ４７）。なお、現時点では、ダウンロード元ＩＰアドレスは元のコンテンツノードのＩＰアドレスであり、ダウンロード中の装置数は０（ゼロ）である。
【０１８５】
これらのストリーム型コンテンツノードを選択するための情報は、図９（Ａ）を用いて上述したとおりであり、制御部１１は、この中から環境評価値がＡ，Ｂ又はＣでありストリーム型コンテンツノードとなることが可能と判断されるダウンロード中ノードがあるか否かを判断する（ステップＳ４８）。このとき、制御部１１は、環境評価値がＡ，Ｂ又はＣでありストリーム型コンテンツノードとなることが可能と判断されるダウンロード中ノードがあると判断すると（ステップＳ４８ＹＥＳ）、そのようなダウンロード中ノードに対して「他のノード装置に現在受信中のコンテンツを配信することが可能か？」問い合わせる（ステップＳ４９）。
【０１８６】
一方、制御部１１は、環境評価値がＡ，Ｂ又はＣでありストリーム型コンテンツノードとなることが可能と判断されるダウンロード中ノードがないと判断すると（ステップＳ４８ＮＯ）、ステップＳ４３に戻り、ステップＳ４４からＳ４７を経て再度ストリーム型コンテンツノードとなることが可能であるリクエストノードを選択する。
【０１８７】
次いで、ルートノードの制御部１１は、問い合わせの送信先の１以上のリクエストノードから、上述のステップＳ３３のように「他のノード装置へコンテンツ配信が可能である」またはステップＳ３４のように「他のノード装置へコンテンツ配信が可能でない」というメッセージを受信し（ステップＳ５０）、「他のノード装置へコンテンツ配信が可能である」というメッセージの送信元のダウンロード中ノードをストリーム型コンテンツノードとして認定する（ステップＳ５１）。
【０１８８】
次いで、制御部１１は、コンテンツ要求先として認定したストリーム型コンテンツノードの中から、クエリを受信しているリクエストノードのコンテンツ要求先として、一または複数のノード装置１を選択し（ステップＳ５２）、選択したノード装置１のＩＰアドレスを当該リクエストノードへ送信する（ステップＳ５３）。このとき、制御部１１は、ツリー型の通信形態のトポロジーがバランス良く成長するように（または、ストリーム型コンテンツノードを選択するための所定のポリシーに合致するように）ストリーム型コンテンツノードを選択して、リクエストノードに知らせるようにする。次いで、制御部１１は、「ストリーム型コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の通信繁忙時指示情報をキャッシュノードに送信し（ステップＳ５４）、処理を終了する（エンド）。
【０１８９】
一方、ステップＳ４２において、制御部１１は、コンテンツノードの通信状況が比較的空いており、通信繁忙度が所定範囲内と判断すると（ステップＳ４２ＹＥＳ）、制御部１１は、クエリを受信しているリクエストノードのコンテンツ要求先として、通常のコンテンツノードの中から一または複数のノード装置１を選択し（ステップＳ５５）、選択したノード装置１のＩＰアドレスを当該リクエストノードへ送信する（ステップＳ５６）。
【０１９０】
また、制御部１１は、上述のストリーム型コンテンツノード情報テーブルが作成されている場合にはこのテーブルを削除するための処理を行う（ステップＳ５７）。具体的には、コンテンツノードが繁忙でなくなっても、依然としてツリー型の通信形態でコンテンツのダウンロードが行われている可能性が高い。そのため、ルートノードが情報テーブルを削除する際に、ツリー型の通信形態でコンテンツをダウンロードしているリクエストノードが有る場合には、コンテンツノードからコンテンツを直接ダウンロードするように接続を変更すべき旨の指示情報を当該リクエストノードに送信することが一例として挙げられる。
【０１９１】
また、ルートノードが情報テーブルを削除する際に、ツリー型の通信形態でコンテンツをダウンロードしているリクエストノードにはそのままダウンロードを続けさせ、当該リクエストノードのダウンロードが全て終わるまでは、情報テーブルを保持しておくことが一例として挙げられる。なお、情報テーブルを保持していても、通信繁忙度が所定範囲内であることを認識した後は（ステップＳ４２）、情報テーブルに新たな情報を追加せずに、ダウンロードが終了したリクエストノードの情報から順に情報テーブルから削除していき、全部のリクエストノードが情報テーブルから削除されたら、情報テーブル自体を削除する。なお、ストリーム型コンテンツノード情報テーブルが作成されていない場合には、制御部１１は速やかにステップＳ５８の処理に進む。
【０１９２】
次いで、制御部１１は、「コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の非通信繁忙時指示情報を、キャッシュノードに送信し（ステップＳ５８）、処理を終了する（エンド）。
【０１９３】
なお、図１７には明記していないが、キャッシュノードがリクエストノードにストリーム型コンテンツノードのＩＰアドレスを送信することをきっかけとして、ルートノードが送信済情報を受信することとなる（後述のステップＳ８７）。この送信済情報により、ルートノードはどのリクエストノードがどのストリーム型コンテンツノードにコンテンツを要求するかを認識することができる。そのため、自身がリクエストノードに知らせたストリーム型コンテンツノードの情報の他、この送信済情報を元に情報テーブルを更新することができる。
【０１９４】
次いで、図１８を参照してノード装置１が通信繁忙時報告情報または非通信繁忙時報告情報等の報告情報を受信した場合（図１５におけるステップＳ１３）のノード装置１の動作について説明する。
【０１９５】
制御部１１は、他のノード装置１から報告情報を受信すると、報告情報対応処理を開始する（ステップＳ１３：スタート）。まず、制御部１１は、通信繁忙時報告情報を受信したか否かを判断する（ステップＳ６１）。制御部１１が通信繁忙時報告情報を受信したと判断すると（ステップＳ６１ＹＥＳ）、コンテンツノードへコンテンツを配信中のノード装置（上述のダウンロード中ノード）を問い合わせる（ステップＳ６２）。このステップＳ６２は上述の図１７におけるステップＳ４３と同様である。また、この後のステップＳ６３〜ステップＳ７０も、図１７におけるステップＳ４４〜ステップＳ５１と同様である。このようにしてリクエストノードのコンテンツ要求先としてストリーム型コンテンツノードとなるノード装置を認定し、「ストリーム型コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の通信繁忙時指示情報をキャッシュノードに送信し（ステップＳ７１）、処理を終了する（エンド）。
【０１９６】
一方、ステップＳ６１において、制御部１１が通信繁忙時報告情報を受信していないと判断すると（ステップＳ６１ＮＯ）、次いで非通信繁忙時報告情報を受信したか否かを判断する（ステップＳ７２）。制御部１１が非通信繁忙時報告情報を受信したと判断すると（ステップＳ７２ＹＥＳ）、上述のストリーム型コンテンツノード情報テーブルが作成されている場合には、上述のステップＳ５７と同様に、このテーブルを削除するための処理を行い（ステップＳ７３）、「コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の非通信繁忙時指示情報をキャッシュノードに送信し（ステップＳ７４）、処理を終了する（エンド）。
【０１９７】
また、ステップＳ７２において、制御部１１が非通信繁忙時報告情報を受信していないと判断すると（ステップＳ７２ＮＯ）、他の報告情報を受信しているため、当該報告情報に対応する処理を行い（ステップＳ７５）、処理を終了する（エンド）。
【０１９８】
なお、図示しないが、ルートノードが通信繁忙時指示情報や非通信繁忙時指示情報を送信した後、クエリを受信した場合には、図１７を用いて説明したように動作してもよいし、予め定められた一定の間は自ら送信した指示情報に従って、クエリの送信元のリクエストノードにＩＰアドレスを返信することとしてもよい。
【０１９９】
［３．１．２．３．キャッシュノードの処理］
図１９および図２０を用いてキャッシュノードの処理（上述のステップＳ１１およびステップＳ１２）について説明する。図１９および図２０は、キャッシュノードの制御部１１に記憶されたプログラムが当該制御部１１により実行されることにより行われる処理を示すフローチャートである。
【０２００】
まず、図１９を用いてキャッシュノードが記憶するコンテンツＩＤとＩＰアドレスの組み合わせにおけるコンテンツＩＤと同一のコンテンツＩＤを含むクエリをキャッシュノードが受信した場合の処理を説明する。
【０２０１】
キャッシュノードの制御部１１は、クエリが転送されて当該クエリに含まれるコンテンツＩＤから、問い合わせられたコンテンツＩＤが自己のノードＩＤと最も近くなく、他に転送先があるため、自身が当該コンテンツＩＤのキャッシュノードであると判断し（ステップＳ８キャッシュノード）、コンテンツノードのＩＰアドレスを送信するための処理を開始する（ステップＳ１１：スタート）。
【０２０２】
制御部１１は、クエリに含まれるコンテンツＩＤに対応するＩＰアドレスを検索して、コンテンツノードに通信繁忙度を問い合わせる（ステップＳ８１）。次いで、制御部１１はコンテンツノードから受信した通信繁忙度情報から通信繁忙度が所定範囲内か否かを判断する（ステップＳ８２）。制御部１１は、コンテンツノードの通信状況が著しく混雑しており、通信繁忙度が所定範囲外と判断すると（ステップＳ８２ＮＯ）、ルートノードへ「通信繁忙度が所定の範囲外である旨」の通信繁忙時報告情報を送信する（ステップＳ８３）。
【０２０３】
次いで、キャッシュノードの制御部１１は、「ストリーム型コンテンツノードを示すＩＰアドレスをクエリの送信元のリクエストノードに送信すべき旨」の通信繁忙時指示情報を受け取り（ステップＳ８４）、当該指示情報に含まれるストリーム型コンテンツノードに対応するＩＰアドレスを、クエリを受信しているリクエストノードのコンテンツ要求先として選択し（ステップＳ８５）、選択したノード装置１のＩＰアドレスを当該リクエストノードへ送信する（ステップＳ８６）。次いで、制御部１１は、「リクエストノードにストリーム型コンテンツノードのＩＰアドレスを送信した旨」の送信済情報をルートノードに送信し（ステップＳ８７）、処理を終了する（エンド）。なお、送信済情報は、どのリクエストノードにどのストリーム型コンテンツノードのＩＰアドレスを知らせたか、を含む情報とする。
【０２０４】
一方、ステップＳ８２において、制御部１１は、コンテンツノードの通信状況が比較的空いており、通信繁忙度が所定範囲内と判断すると（ステップＳ８２ＹＥＳ）、「通信繁忙度が所定の範囲内である旨」の非通信繁忙時報告情報をルートノードに送信し（ステップＳ８８）、クエリを受信しているリクエストノードのコンテンツ要求先として、通常のコンテンツノードの中から一または複数のノード装置１を選択し（ステップＳ８９）、選択したノード装置１のＩＰアドレスを当該リクエストノードへ送信し（ステップＳ９０）、処理を終了する（エンド）。
【０２０５】
次いで、図２０を参照してノード装置１が通信繁忙時指示情報または非通信繁忙時指示情報等の指示情報を受信した場合（図１５におけるステップＳ１２）のノード装置１の動作について説明する。
【０２０６】
制御部１１は、他のノード装置１から指示情報を受信すると、指示情報対応処理を開始する（ステップＳ１２：スタート）。まず、制御部１１は、通信繁忙時指示情報を受信したか否かを判断する（ステップＳ９１）。制御部１１が通信繁忙時指示情報を受信したと判断すると（ステップＳ９１ＹＥＳ）、当該指示情報に含まれるストリーム型コンテンツノードのＩＰアドレスを、クエリを受信した場合に返信する情報として記憶して（ステップＳ９２）、処理を終了する（エンド）。
【０２０７】
一方、ステップＳ９１において、制御部１１が通信繁忙時指示情報を受信していないと判断すると（ステップＳ９１ＮＯ）、次いで非通信繁忙時指示情報を受信したか否かを判断する（ステップＳ９３）。制御部１１が非通信繁忙時指示情報を受信したと判断すると（ステップＳ９３ＹＥＳ）、クエリを受信した場合に通常のコンテンツノードのＩＰアドレスを返信することを記憶して（ステップＳ９４）、処理を終了する（エンド）。
【０２０８】
また、ステップＳ９３において、制御部１１が非通信繁忙時指示情報を受信していないと判断すると（ステップＳ９３ＮＯ）、他の指示情報を受信しているため、当該指示情報に対応する処理を行い（ステップＳ９５）、処理を終了する（エンド）。
【０２０９】
なお、図示しないが、キャッシュノードが通信繁忙時指示情報や非通信繁忙時指示情報を受信した後、クエリを受信した場合には、図１９を用いて説明したように動作してもよいし、予め定められた一定の間は受信した指示情報に従って、クエリの送信元であるリクエストノードにＩＰアドレスを返信することとしてもよい。
【０２１０】
［３．１．２．４．コンテンツノードおよびストリーム型コンテンツノードの処理］
図２１を用いてコンテンツノードおよびストリーム型コンテンツノードのコンテンツ配信処理（上述のステップＳ１４）について説明する。図２１は、リクエストノードの制御部１１に記憶されたプログラムが当該制御部１１により実行されることにより行われる処理を示すフローチャートである。
【０２１１】
コンテンツノードまたはストリーム型コンテンツノードの制御部１１は、リクエストノードからコンテンツ要求を受信したことを認識すると、コンテンツ配信処理を開始する（ステップＳ１４：スタート）。
【０２１２】
制御部１１は、リクエストノードからコンテンツ要求を受信すると、当該コンテンツ要求の送信元のリクエストノードに対してコンテンツ配信を開始し（ステップＳ１０１）、コンテンツ配信中のリクエストノードのＩＰアドレスをダウンロード中ノードの配信中ノード情報として記憶する（ステップＳ１０２）。この記憶した配信中ノード情報は、ルートノードからコンテンツノードに、ダウンロード中ノードについて問い合わせがあったときに、ルートノードに送信する。
【０２１３】
そして、制御部１１は、コンテンツ配信を続け（ステップＳ１０３）、コンテンツ配信が完了したか否かを判断し（ステップＳ１０４）、コンテンツ配信が完了するまでは（ステップＳ１０４ＮＯ）、コンテンツ配信を続け（ステップＳ１０３）、コンテンツ配信が完了したことを判断すると（ステップＳ１０４ＹＥＳ）、処理を終了する（エンド）。
【０２１４】
コンテンツノードとストリーム型コンテンツノードのコンテンツ配信動作は上述のフローチャートにて説明したように同様であるが、ストリーム型コンテンツノードは、コンテンツ配信開始時に、他のコンテンツノードからコンテンツを受信中である点で異なる。
【０２１５】
なお、図示しないが、コンテンツノードは、ルートノードやキャッシュノードから通信繁忙度を問い合わせられると、コンテンツノード自身の通信繁忙度を認定して、問い合わせ元のノード装置に通信繁忙度情報を送信する。
【０２１６】
［４．変形形態］
本実施形態においては、コンテンツノードにおける他のノード装置（リクエストノード）との通信の局所的集中の程度を示す通信繁忙度を認定するために、ルートノードやキャッシュノードがコンテンツノードに通信状況を直接問い合わせているが、この実施形態に限定されない。以下に通信繁忙度が所定の範囲外、所定の範囲内、について説明するように、ルートノードやキャッシュノードが一定時間あたりに一のコンテンツノードのＩＰアドレスを送信した数（コンテンツのＩＰアドレス送信数）や、ルートノードやキャッシュノードがリクエストノードから一定時間あたりにクエリを受信した数（クエリ受信数）等を基準に通信繁忙度を認定することもできる。
【０２１７】
また、ルートノードやキャッシュノードは、上述のコンテンツのＩＰアドレス送信数やクエリ受信数が所定値以上となった場合に初めてコンテンツノードに通信状況を問い合わせる形態とすることもできる。この場合、通信数が減るためにコンテンツ配信システムＳにおける負荷が低減される。
【０２１８】
ここで、「通信繁忙度が所定の範囲外」については、コンテンツノードの通信の局所的集中が発生した場合、具体的に、実施形態において説明したように、コンテンツノード自身が「通信が繁忙している」と判断した場合や、ルートノードやキャッシュノードが一定時間あたりに所定数以上の一のコンテンツノードのＩＰアドレスを知らせた（送信した）場合、ルートノードやキャッシュノードがリクエストノードから一定時間あたりに所定数以上のクエリを受信した場合、一のコンテンツノードへ配信要求を再度行うリクエストノードが増加した場合、等と定義することができ、実施形態により適宜決定することができる。
【０２１９】
また、「通信繁忙度が所定の範囲内」については、コンテンツノードの通信が元々混んでいない場合、コンテンツノードのコンテンツの複製を記憶したレプリカノードが一定数以上に増加してコンテンツ配信が安定した場合、リクエストノードが一定時間あたりに所定数以下に減少してきた場合等のコンテンツノードの通信の局所的集中が解除された場合、具体的に、実施形態において説明したように、コンテンツノード自身が「通信が繁忙していない」と判断した場合や、ルートノードやキャッシュノードが一定時間あたりに所定数未満の一のコンテンツノードのＩＰアドレスを知らせた（送信した）場合、ルートノードやキャッシュノードがリクエストノードから一定時間あたりに所定数未満のクエリを受信した場合、一のコンテンツノードへ配信要求を再度行うリクエストノードがなくなった場合、等と定義することができ、実施形態により適宜決定することができる。上述の「通信繁忙度が所定の範囲内」と「通信繁忙度が所定の範囲外」における所定の範囲は、同一でなくてもよい。
【０２２０】
本実施形態のコンテンツ配信システムＳにおいて、ストリーム型コンテンツノードを用いたいわゆるツリー型の通信形態とした後、ストリーム型コンテンツノードがコンテンツノードからコンテンツを受信し終わると、当該ストリーム型コンテンツノードは、コンテンツノードとの通信が切断され、コンテンツノード（レプリカノード）として機能することができる。このようにコンテンツノードとなったノード装置については、従来公知の方法でルートノードまたはキャッシュノードがリクエストノードにこの新たなコンテンツノードのＩＰアドレスを送信することができる。また、このようなコンテンツノードが増えてきた場合には、ルートノードはこのことを考慮してリクエストノードにＩＰアドレスを知らせるノード装置（元のコンテンツノード、新たなコンテンツノードまたはストリーム型コンテンツノード）を選択することができる。
【０２２１】
本発明における「情報記憶ノード装置」は、本実施形態においてコンテンツノードとして説明したが、コンテンツノードだけでなく、そのコンテンツの複製を記憶しているレプリカノードを含んでいてもよい。なお、実施形態においては、便宜的にレプリカノードという言葉を用いているが、実際にはコンテンツノードとレプリカノードは同一のコンテンツデータを有しているため、両者は区別されない。「情報記憶ノード装置」にレプリカノードを含ませる場合には、例えば、ルートノードやキャッシュノードは、コンテンツノードと全てのレプリカノードに通信繁忙度を問い合わせる形態とすることができる。また、ルートノードやキャッシュノードは、コンテンツノードとレプリカノードの数が一定数以下までは全ての該当するノード装置に通信繁忙度を問い合わせ、コンテンツノードとレプリカノードの数が一定数を超えると、優先順位の高い方から一定数のノード装置のみに通信繁忙度を問い合わせる形態としてもよい。この優先順位は、通信繁忙度情報の返答速度等を基準としてルートノードやキャッシュノードが任意に決定できる。
【０２２２】
本発明における「情報部分記憶ノード装置」は、上述のように初めはコンテンツの配信を要求するリクエストノードであり、コンテンツを受信中はダウンロード中ノードであり、ルートノードに認定されるとストリーム型コンテンツノードとなって他のリクエストノードにコンテンツを配信するものである。
【０２２３】
本実施形態においては、いわゆるツリー型の通信形態として、図８下部枠や図１０（Ｂ）において説明したように、コンテンツノード１ｈ、ストリーム型コンテンツノード１ｅ・１ｚ（ノード番号＜１＞、＜２＞；１段目）、新たなリクエストノード１ｊ、１ｆ、１ｄ、１ａ（ノード番号＜４＞、＜５＞、＜６＞；２段目）の順でツリーが形成されたものである。ツリー型の通信形態は、ルートノードが図９（Ａ）、図１０（Ａ）におけるトポロジー情報を用いて管理することにより、２段目のリクエストノード１ｊ、１ｆ、１ｄ、１ａもストリーム型コンテンツノードとし、その下流にさらに新たなリクエストノード（ノード番号＜７＞；３段目）を通信させる形態とすることもできる。
【０２２４】
本実施形態では、ルートノードがキャッシュノードの所在を知るために、「１．４．コンテンツデータの登録方法」において図６を用いて説明したように、キャッシュノードは自身のＩＰアドレス（ノード情報）を公開メッセージに付加して転送している。ルートノードがキャッシュノードに情報を送信するためには、上記の方法に限定されず、例えば、コンテンツデータの登録時に、公開メッセージがコンテンツノードからキャッシュノードを中継してルートノードに転送される過程で、各キャッシュノードがメッセージの送信元のＩＰアドレスを記憶しておくことで、ルートノードからキャッシュノードへ逆向きに情報を転送していくこともできる。
【０２２５】
本実施形態においては、ルートノードが通信繁忙時指示情報送信手段、非通信繁忙時指示情報送信手段、通信繁忙時報告情報受信手段および非通信繁忙時報告情報受信手段を有し、キャッシュノードが通信繁忙時報告情報送信手段、非通信繁忙時報告情報送信手段、通信繁忙時指示情報受信手段および非通信繁忙時指示情報受信手段を有している。実際には、上述のようにキャッシュノードが通信繁忙時指示情報・非通信繁忙時指示情報を転送することもあるため、キャッシュノードが通信繁忙時報告情報受信手段および非通信繁忙時報告情報受信手段を有している場合もある。
【０２２６】
また、上述のノード装置１の各動作に対応するプログラムをフレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、或いはインターネット等のネットワークを介して取得して記録しておき、これをマイクロコンピュータ等により読み出して実行することにより、当該マイクロコンピュータを実施形態に係る制御部１１として機能させることも可能である。
【図面の簡単な説明】
【０２２７】
【図１】本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【図２】ＩＤ空間の説明図である。
【図３】ＤＨＴによってルーティングテーブルが作成される様子の一例を示す図である。
【図４】（Ａ）レベル１のテーブルの一例である。（Ｂ）レベル２のテーブルの一例である。（Ｃ）レベル３のテーブルの一例である。（Ｄ）完成したルーティングテーブルの一例である。
【図５】ＤＨＴによりコンテンツデータの保存元であるノード装置１が検索される様子の一例を示す図である。
【図６】コンテンツノードの公開メッセージが転送される様子をスパニングツリー状に表した図である。
【図７】ノード装置１の概要構成例を示す図である。
【図８】本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【図９】ルートノードがストリーム型コンテンツノードを選択する際の動作を説明する図（１）である。
【図１０】ルートノードがストリーム型コンテンツノードを選択する際の動作を説明する図（２）である。
【図１１】通信繁忙度が所定の範囲外である場合のリクエストノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、キャッシュノードの間のクエリ等各種情報の授受を示すシーケンスチャート（１）である。
【図１２】通信繁忙度が所定の範囲外である場合のリクエストノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、キャッシュノードの間のクエリ等各種情報の授受を示すシーケンスチャート（２）である。
【図１３】通信繁忙度が所定の範囲内である場合のリクエストノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、キャッシュノードの間のクエリ等各種情報の授受を示すシーケンスチャート（３）である。
【図１４】通信繁忙度が所定の範囲内である場合のリクエストノード、ルートノード、コンテンツノード、ダウンロード中ノード、ストリーム型コンテンツノード、キャッシュノードの間のクエリ等各種情報の授受を示すシーケンスチャート（４）である。
【図１５】ノード装置の制御部において受信等したメッセージを解析する処理を示すフローチャートである。
【図１６】リクエストノードの制御部における処理を示すフローチャートである。
【図１７】ルートノードの制御部におけるノード情報送信処理（１）を示すフローチャートである。
【図１８】ルートノードの制御部における報告情報対応処理を示すフローチャートである。
【図１９】キャッシュノードの制御部におけるノード情報送信処理（２）を示すフローチャートである。
【図２０】キャッシュノードの制御部における指示情報対応処理を示すフローチャートである。
【図２１】コンテンツノードおよびストリーム型コンテンツノードの制御部における処理を示すフローチャートである。
【符号の説明】
【０２２８】
１  ノード装置
８  ネットワーク
９  オーバレイネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
２０  通信部
２１  入力部
２２  バス
Ｓ  コンテンツ配信システム
【図１】
0004715388.tif 000002
【図２】
0004715388.tif 000003
【図３】
0004715388.tif 000004
【図４】
0004715388.tif 000005
【図５】
0004715388.tif 000006
【図６】
0004715388.tif 000007
【図７】
0004715388.tif 000008
【図８】
0004715388.tif 000009
【図９】
0004715388.tif 000010
【図１０】
0004715388.tif 000011
【図１１】
0004715388.tif 000012
【図１２】
0004715388.tif 000013
【図１３】
0004715388.tif 000014
【図１４】
0004715388.tif 000015
【図１５】
0004715388.tif 000016
【図１６】
0004715388.tif 000017
【図１７】
0004715388.tif 000018
【図１８】
0004715388.tif 000019
【図１９】
0004715388.tif 000020
【図２０】
0004715388.tif 000021
【図２１】
0004715388.tif 000022