(57)【要約】【課題】  サーバからディジタル・コンテンツを再構成するに必要とされる最小のパケットを送信するだけで、ローカル・ネットワークに接続されたすべてのクライアントに対して同一のディジタル・コンテンツを共有させること。【解決手段】  本発明のディジタル・コンテンツ配信システム１０は、第１のネットワーク１２に接続される第２のネットワーク２２、２８を構成し、ディジタル・コンテンツを受信して提供するためのクライアント２０を含む。サーバ１４は、コリジョン・ドメインとして構成された第２のネットワーク２８に参加しているクライアント２０のアドレス識別値を格納するクライアント・リストと、クライアント・リストに登録されたクライアント識別値をランダムに選択する手段とを含んでおり、選択に応答して、選択されたクライアント２０に対してディジタル・コンテンツを構成するための最小単位のパケットを送信する。【選択図】  図１
2005027243.tif 000002
【特許請求の範囲】
【請求項１】
第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのシステムであって、
前記第１のネットワークに接続され、ディジタル・コンテンツを送信するサーバと、
前記第１のネットワークに接続される前記第２のネットワークを構成し、前記ディジタル・コンテンツを受信して提供するためのクライアントとを含み、
前記サーバは、前記第２のネットワークの所定のドメインに参加しているクライアントのアドレス識別値を格納するクライアント・リストと、
前記クライアント・リストに登録されたクライアント識別値をランダムに選択する手段と、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信する手段とを含み、
前記クライアントは、前記サーバから受信した前記最小単位のパケットからコピー・パケット作成して、前記クライアントが帰属される第２のネットワークへと前記コピー・パケットをマルチキャストさせる手段を含む
ディジタル・コンテンツ配信システム。
【請求項２】
前記サーバは、マルチキャスト・アドレス値を前記クライアントに送信する手段を含む、請求項１に記載のディジタル・コンテンツ配信システム。
【請求項３】
前記サーバは、前記クライアントが前記第２のネットワークへと接続されたことを検出して、前記クライアント・リストを更新する手段を含む、
請求項１に記載のコンテンツ配信システム。
【請求項４】
前記サーバは、前記最小単位のパケットを受信する前記クライアントからの応答により、前記クライアント・リストから前記クライアントのアドレス識別値を削除する手段を含む、請求項１に記載のコンテンツ配信システム。
【請求項５】
前記サーバは、次に最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境を格納したドメイン・リストを含む、請求項１に記載のコンテンツ配信システム。
【請求項６】
前記第２のネットワークは、少なくともワイヤレス・ローカル・ネットワーク環境を含み、前記クライアントは、ワイヤレス・ローカル・ネットワーク環境でネットワークされた携帯端末である、請求項１に記載のコンテンツ配信システム。
【請求項７】
第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するための方法であって、
前記第１のネットワークに接続されたサーバにより前記第２のネットワークのネットワーク環境に応答して選択される前記第２のネットワークに帰属されるクライアントが、前記第１のネットワークを介してディジタル・コンテンツを構成するための最小単位のパケットを受信するステップと、
前記最小単位のパケットを受信した前記クライアントに対して、前記最小単位のパケットのコピー・パケットを作成させるステップと、
前記クライアントから前記クライアントが帰属される第２のネットワークへと前記作成されたコピー・パケットをマルチキャストさせ、前記第２のネットワークに帰属されるすべてのクライアントに対して前記最小単位のパケットを共有させるステップと
を含む、ディジタル・コンテンツ配信方法。
【請求項８】
前記クライアントは、前記サーバが保持するクライアント・リストに登録された前記クライアントのアドレス識別値をランダムに選択することにより選択される、請求項７に記載の方法。
【請求項９】
前記クライアント・リストは、前記クライアントが前記第２のネットワークへの接続および前記クライアントの応答に応じて更新される、請求項８に記載の方法。
【請求項１０】
前記クライアントが、前記サーバから、前記第２のネットワーク内でマルチキャストを行うためのマルチキャスト・アドレス値を取得するステップを含む、請求項７に記載の方法。
【請求項１１】
第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのシステムにおいて使用されるサーバであって、前記サーバは、
前記第２のネットワークの所定のドメインに参加しているクライアントのアドレス識別値を格納したクライアント・リストから、前記クライアント・リストに登録されたクライアント識別値をランダムに選択する手段と、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信する手段と、
前記クライアントの前記第２のネットワークへの接続および前記最小単位のパケットを受信する前記クライアントからの応答を検出して、前記クライアント・リストへのアドレス識別値の追加または削除により前記クライアント・リストを更新する手段と
を含むサーバ。
【請求項１２】
さらに、前記第２のネットワーク内で使用されるマルチキャスト・アドレス値を前記クライアントに送信する手段を含む、請求項１１に記載のサーバ。
【請求項１３】
前記サーバは、最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境を格納したドメイン・リストを含む、請求項１１に記載のサーバ。
【請求項１４】
第１のネットワークと第２のネットワークとを介するディジタル・コンテンツの配信方法を実行させるサーバとしてコンピュータを制御するためのコンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータに対して
前記第２のネットワークの所定のドメインに接続しているクライアントのアドレス識別値を格納したクライアント・リストから、前記クライアント・リストに登録されたクライアント識別値をランダムに選択させるステップと、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信させるステップと、
前記クライアントの前記第２のネットワークへの接続および前記最小単位のパケットを受信する前記クライアントからの応答を検出して、前記クライアント・リストのアドレス識別値の追加または削除により前記クライアント・リストを更新するステップと、
前記第２のネットワーク内で使用されるマルチキャスト・アドレス値を前記クライアントに送信させるステップと
をコンピュータに対して実行させる、プログラム。
【請求項１５】
前記サーバに対して、さらに最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境情報を格納したドメイン・リストを参照させるステップを実行させる、請求項１４に記載のプログラム。
【請求項１６】
第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのクライアントとしてコンピュータを制御するためのコンピュータ実行可能なプログラムであって、前記プログラムは、
前記第１のネットワークに接続されたサーバから前記第２のネットワークのネットワーク環境に応答して選択されたコンピュータに対してディジタル・コンテンツを構成するための最小単位のパケットを受信するステップと、
前記最小単位のパケットを受信した前記コンピュータに対して、前記最小単位のパケットのコピー・パケットを作成させるステップと、
前記コンピュータから前記コンピュータが帰属される第２のネットワークへと前記作成されたコピー・パケットをマルチキャストさせ、前記第２のネットワークに帰属されるすべてのコンピュータに対して前記受信した最小単位のパケットを共有させるステップと
を実行させる、プログラム。
【請求項１７】
前記コンピュータに対し、前記サーバから送信され、前記第２のネットワーク内でマルチキャストを行うためのマルチキャスト・アドレス値を取得させるステップを実行させる、請求項１６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してサーバから、複数のローカル・ネットワークに接続されたクライアントへのディジタル・コンテンツの配信に関する。より詳細には、本発明は、サーバからディジタル・コンテンツを再構成するに必要とされる最小のパケットを送信するだけで、ローカル・ネットワークに接続されたすべてのクライアントに対して同一のディジタル・コンテンツを共有させることを可能とする、ディジタル・コンテンツ配信システム、ディジタル・コンテンツ配信方法、そのためのサーバ、クライアント、サーバとしてコンピュータを制御するためのコンピュータ実行可能なプログラム、およびクライアントとしてコンピュータを制御するためのコンピュータ実行可能なプログラムに関する。
【背景技術】
【０００２】
近年では、コンピュータ、公衆電話回線、ＩＳＤＮ、光通信、無線通信、ＡＤＳＬ、ＣＡＴＶなどの方式を介したインターネットといったネットワークがますます普及している。今後、電子メールといったディジタル・コンテンツの配信ばかりではなく、ネットワークを介してテキスト・データ、音声データ、画像データ、およびこれらの複合したマルチメディア・データを、ディジタル・コンテンツを提供するサイトに配置されたサーバから、ネットワークを介して複数のコンピュータ、または携帯端末といったクライアントへと配信するサービスがさらに普及するものと考えられる。
【０００３】
これまで種々の手法が一対多のデータ配信のために提案されてきているものの、コンピュータ装置およびネットワーク環境の多様化の速度も相俟って、さまざまな問題が生じてきている。図１９および図２０には、従来の上述した一対多のデータ配信を行う場合の代表的な手法を示す。図１９を使用して従来技術を説明すると、図１９（ａ）がユニキャストを使用したデータ配信プロセスを示し、図１９（ｂ）がIPマルチキャストを使用したデータ配信を示している。図１９（ａ）に示したユニキャストを用いるデータ配信は、ネットワーク１００を通してデータを配信することを想定した場合、送信先のクライアント１０２の数の増加に伴い同一のデータを共有させるためのデータ・ストリームも比例して増加することになる。このため、あて先の異なる同一のデータが重複してネットワークを１００を介して通信されるので、ネットワーク１００またはネットワーク１００に接続された所定のドメインを規定するルータの混雑を引き起こすことになる。同様の不都合は、配信サーバ１０４についても発生し、配信サーバ１０４の負荷がクライアント１０２の増加に伴って大きくなるという問題も生じる。
【０００４】
図１９（ｂ）には、ユニキャストの持つ問題を解決する方法として提案されている、IPマルチキャストの概略的な手法を示す。IPマルチキャストでは、ネットワーク１００には、専用ルータ１０６が接続されている。専用ルータ１０６は、サーバ１０４が所定のマルチキャスト・アドレスにデータ・ストリームを送信すると、ネットワーク１００経路上の専用ルータ１０６がパケットを受信して、パケットを、そのマルチキャスト・アドレスに登録されている複数のクライアント１０２へのデータ配信が実行される。
【０００５】
この場合、専用ルータ１０６間には、クライアント１００の数にかかわらず、単一のデータ・ストリームしか流れないために、ネットワークの混雑が防止され、またサーバの負荷も大幅に軽減される。しかしながら、IPマルチキャストを用いるためには経路上のすべてのルータを専用ルータ１０６で置き換える対応が不可欠であり、インフラ基盤への投資が不可欠で、膨大な設備投資が必要となる。さらにIPマルチキャストに対応している専用ルータ１０６でも、運用上、マルチキャスト・パケットを通させない設定になっている場合が多い。このため、IPマルチキャストによる配信は多くの場合現実的でない。
【０００６】
上のようなIPマルチキャストの問題を解決する一つの方法として、MBoneに代表される「マルチキャスト・トンネリング」がある。これはマルチキャストの通らないネットワーク間をユニキャストによる仮想的なトンネルで結び、マルチキャスト・パケットが届くようにしたものである。この方法では、トンネルを構成するコンピュータでトンネルを構成させるため、常にデーモン・プロセスが機能している必要がある。マルチキャスト・トンネリングを使用すれば、IPマルチキャストのみを用いる場合に比べて適用範囲は広がるものの、インフラサポートを必要とすること、ルーティングの難しさなど、IPマルチキャストに付随する数々の問題は依然として完全には解決されるものではない。さらにIPマルチキャストには、アドレスが全世界で一意に決められているため、限られたドメインへの配信を行うのが一般に困難であるという問題があり、これはマルチキャスト・トンネリングに関しても同様である。
【０００７】
また、IPマルチキャストの変形例として、Small Group Multicast (XCast) も知られている。Small Group Multicast (XCast)は、パケット内にすべての宛先リストを記しておき、ネットワーク上に存在するSGM対応のルータがパケットを解釈して個別的にユニキャストを行うものである。この方法では、SGM非対応のルータが間に存在してもよいこと、IPマルチキャストと比較すると単純な実装かつ配信範囲を規定できるということなどの特色がある。しかしながらこの方法も、名の示すとおり小規模なグループに同時配信を行う技術であるために、グループの規模がある程度大きくなると宛先リストが肥大化し、パケットごとの負荷が大きくなるので適用範囲が限定されてしまう。
【０００８】
図２０には、いわゆるアプリケーションレベル・マルチキャストとして参照される、データ配信手法を概略的に示す。図２０に示されたアプリケーションレベル・マルチキャストは、IPマルチキャストと同等の動作を、クライアントのアプリケーション上で実現する技術の総称である。このアプリケーションレベル・マルチキャストでは、サーバ１０４は、ユニキャストを用いて、単独あるいは少数のクライアント１０２へとデータを送信する。データの配信を受けたクライアント１０２ａは、別のクライアント１０２ｂ〜クライアント１０２ｆにデータを転送することで、最終的にこれらの全クライアントにデータを共有させている。このようなアプリケーションレベル・マルチキャストは、インフラへの追加投資を必要としないという特長がある。しかしながら、アプリケーションレベル・マルチキャストは、通常ではクライアント構成の変化に応じた配信ルートの更新が複雑になるという欠点がある。
【０００９】
さらに、アプリケーションレベル・マルチキャストにおいて、クライアントの役割が固定されている場合には、上流に位置するクライアントがローカル・ネットワークから離脱したり、突然ダウンしたりした場合、下流のクライアントまでデータが届かなくなるという本質的問題も生じる。この問題を解決するには、各クライアントに対し、各クライアントが配信を受ける必要のない時にも転送のみを行うデーモン・プロセスを動かしておくことで対応することも考えられる。しかしクライアントに障害が発生した場合や、ワイヤレスLANのホット・スポットのようにクライアントが物理的に離脱してしまう場合などにはこの方法では対応できない。
【非特許文献１】「Multicast. Routing inInternetworks and Extended LANs」（Stanford University, Department of ComputerScience Technical Report: STAN-CS-88-1214, July, 1988）.
【非特許文献２】Small Group Multicast (XCast)RickBoivie et al., “Small Group Multicast: A New Solution for Multicasting on theInternet”, IEEE Internet Computing, May/June 2000, pp 75-77.
【非特許文献３】Dimitrios Pendarakis, Sherlia Shi,Dinesh Verma, and Marcel Waldvogel. Almi: An application level multicastinfrastructure. In Proceedings of the 3rd USENIX Symposium on InternetTechnologies and Systems (USITS), pages 49--60, 2001.
【非特許文献４】Y. Chu, S. Rao, and H. Zhang. ACase For End System Multicast. In Proc. ACM Sigmetrics, June 2000; P. Francis,“Yoid: extending the interent multicast architecture”, preprint available fromhttp://www.isis.edu/div7/yoid/, April 2000）.
【００１０】
これらの問題を解決するひとつの方法として、本願発明者らは、下記特許文献１において、新規なデータ配信手法を提案した。
【特許文献１】特願２００２−３０３８５０号明細書
【００１１】
以下、上記明細書に開示されたデータ配信を、「P2G（ピア−ツウ−グループ）型データ配信」として参照する。図２１には、特願２００２−３０３８５０号公報に開示されたP2G型データ配信の手法を概略的に示した図である。P2Gデータ配信は、サーバ１０４からクライアント１０２のうち一台にユニキャストでパケットを送信する。その後複数のクライアントで構成される「ドメイン」内でユニキャストを用いてP2P型のデータ共有を行うことで、クライアント全体にデータを配信している。さらに配信サーバから最初にデータを送る送信先クライアントをランダムに変更することで、負荷分散とともに、配信システムの頑強性を実現している。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、本発明者らによる検討の結果、上述したP2G型データ配信は、ワイヤレスLANやリピータによる有線LANなどのコリジョン・ドメイン（非スイッチング環境）においては必ずしも効率的でない場合があることを見出した。図２２には、コリジョン・ドメインにおいて発生する不都合について、概略的に説明する。図２２（ａ）がスイッチング手段を使用するP2Gデータ配信のトラフィック経路を概略的に示した図であり、図２２（ｂ）がコリジョン・ドメインにおいて発生する不都合を概略的に示した図である。図２２（ａ）に示すように、スイッチング・ハブといったスイッチング手段を使用するP2Gデータ配信では、パケットが送信先の端末の接続されたポートに対してのみ送信されるため、P2Gデータ配信により送られるデータのドメイン内での通信に大きな不都合は生じない。
【００１３】
ところで、図２２（ｂ）に示すコリジョン・ドメインでは、任意の２クライアント間の通信は、該当するクライアントFとの間ばかりではなく、他のすべてのクライアントに到達することになる。このため、せっかくP2Gデータ配信を使用して最小パケットを送信したとしても、結局のところ所定のクライアント、例えばクライアントFには(n-1)の同一のパケットが送られることになる。このとき、クライアントFは、自分宛のデータのみを選択して取り込むが、通信パケットの転送中、他のすべてのクライアントの通信が妨げられることになる。
【００１４】
より具体的に説明すると、例えば、ワイヤレスLAN、リピータ・ハブ／ブリッジなどにより形成されているドメインといった非スイッチング環境のネットワーク内にP2Gデータ配信を適用した場合には、一対一の通信が宛先のみならずコリジョン・ドメイン内全体に一度は行き渡る。このため、コリジョン・ドメイン内では、P2P型のデータ共有を行うためにあて先とされるクライアント以外にも影響を与える大量のパケット（O(n2), 
n はクライアント数）が重複して通信されてしまう。
【００１５】
このことは、P2G型データ配信を、ワイヤレスLAN環境を含むネットワークへと配信することを想定すると、ネットワークの帯域幅を無駄に消費することになり、コリジョン・ドメイン内において、全体の通信速度の低下などの問題を生じさせる。また、所定の通信パケットを一つのクライアントから他のクライアントへと通信している間には、これとは関係のないクライアント−クライアント間の通信が妨げられることになる。
【００１６】
上述したように、P2G型データ配信は、ドメイン内のクライアントがスイッチング・ハブといったスイッチ手段で接続されている、いわゆるコリジョンレス・ドメインの場合には高効率で、クライアント構成の変化に対する頑強性も併せ持っているといえる。しかしながら、コリジョン・ドメイン（非スイッチング環境）では、上述したように、コリジョン・ドメイン内での通信が効率的に行えないために、適用範囲が限定されてしまうという不都合があることが本発明者らのさらなる検討により判明した。したがって、従来のP2G型データ配信において、インフラへの追加投資をなるべく少なくしつつ、コリジョン・ドメインとして参照されるネットワーク環境において多数のクライアントに効率的にデータを配信する方法が必要であることが判明した。
【課題を解決するための手段】
【００１７】
本発明は、上記P2G型データ配信において、スイッチング手段を使用しないネットワーク環境での不都合を改善するためになされたものである。本発明では、サーバがすべて、あるいは一部の配信先クライアントと接続可能であると仮定し、サーバが任意の１クライアントにユニキャストでソース・パケットを送信する。受信したクライアントは、所定のローカルなマルチキャスト・アドレスに向けて、コピー・パケットを転送する。配信サービスを受けるすべてのクライアントは、このマルチキャスト・アドレスにアクセスできる。このため、最初にどのクライアントが配信サーバから直接パケットを受信したかに関わらず、すべてのクライアントが常にパケットを受信することが可能である。
【００１８】
さらに本発明では、サーバが最初にパケットを送信するクライアントをランダムに変化させることにより、各クライアントがマルチキャスト・アドレスに対してコピー・パケットを送信する頻度は、クライアントの数が増加すればするほどクライアント数に反比例して低くなる。このため、クライアント間の負荷が分散されると同時に、特定のクライアントのネットワークへの参加・離脱への対応が容易になる。また、クライアントが協働してディジタル・コンテンツの共有を可能とするべく動作するので、対応コリジョン・ドメインにおいて２次サーバなどの追加投資を不要とすることができる。
【００１９】
すなわち、本発明によれば、第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのシステムであって、
前記第１のネットワークに接続され、ディジタル・コンテンツを送信するサーバと、
前記第１のネットワークに接続される前記第２のネットワークを構成し、前記ディジタル・コンテンツを受信して提供するためのクライアントとを含み、
前記サーバは、前記第２のネットワークの所定のドメインに参加しているクライアントのアドレス識別値を格納するクライアント・リストと、
前記クライアント・リストに登録されたクライアント識別値をランダムに選択する手段と、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信する手段とを含み、
前記クライアントは、前記サーバから受信した前記最小単位のパケットからコピー・パケット作成して、前記クライアントが帰属される第２のネットワークへと前記コピー・パケットをマルチキャストさせる手段を含む
ディジタル・コンテンツ配信システムが提供される。
【００２０】
前記サーバは、マルチキャスト・アドレス値を前記クライアントに送信する手段を含む。前記サーバは、前記クライアントが前記第２のネットワークへと接続されたことを検出して、前記クライアント・リストを更新する手段を含む。前記サーバは、前記最小単位のパケットを受信する前記クライアントからの応答により、前記クライアント・リストから前記クライアントのアドレス識別値を削除する手段を含む。前記サーバは、次に最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境を格納したドメイン・リストを含む。前記第２のネットワークは、少なくともワイヤレス・ローカル・ネットワーク環境を含み、前記クライアントは、ワイヤレス環境でネットワークされた携帯端末である。
【００２１】
また、本発明によれば、第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するための方法であって、
前記第１のネットワークに接続されたサーバにより前記第２のネットワークのネットワーク環境に応答して選択される前記第２のネットワークに帰属されるクライアントが、前記第１のネットワークを介してディジタル・コンテンツを構成するための最小単位のパケットを受信するステップと、
前記最小単位のパケットを受信した前記クライアントに対して、前記最小単位のパケットのコピー・パケットを作成させるステップと、
前記クライアントから前記クライアントが帰属される第２のネットワークへと前記作成されたコピー・パケットをマルチキャストさせ、前記第２のネットワークに帰属されるすべてのクライアントに対して前記最小単位のパケットを共有させるステップと
を含む、ディジタル・コンテンツ配信方法が提供される。
【００２２】
本発明の前記クライアントは、前記サーバが保持するクライアント・リストに登録された前記クライアントのアドレス識別値をランダムに選択することにより選択される。本発明の前記クライアント・リストは、前記クライアントが前記第２のネットワークへの接続および前記クライアントの応答に応じて更新される。前記クライアントが、前記サーバから、前記第２のネットワーク内でマルチキャストを行うためのマルチキャスト・アドレス値を取得するステップを含む。
【００２３】
さらに、本発明によれば、第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのシステムにおいて使用されるサーバであって、前記サーバは、
前記第２のネットワークの所定のドメインに参加しているクライアントのアドレス識別値を格納したクライアント・リストから、前記クライアント・リストに登録されたクライアント識別値をランダムに選択する手段と、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信する手段と、
前記クライアントの前記第２のネットワークへの接続および前記最小単位のパケットを受信する前記クライアントからの応答を検出して、前記クライアント・リストへのアドレス識別値の追加または削除により前記クライアント・リストを更新する手段と
を含むサーバが提供される。
【００２４】
本発明のサーバは、さらに、前記第２のネットワーク内で使用されるマルチキャスト・アドレス値を前記クライアントに送信する手段を含む。前記サーバは、最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境を格納したドメイン・リストを含む。
【００２５】
また、本発明によれば、第１のネットワークと第２のネットワークとを介するディジタル・コンテンツの配信方法を実行させるサーバとしてコンピュータを制御するためのコンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータに対して
前記第２のネットワークの所定のドメインに接続しているクライアントのアドレス識別値を格納したクライアント・リストから、前記クライアント・リストに登録されたクライアント識別値をランダムに選択させるステップと、
前記選択に応答して、選択されたクライアントに対して前記ディジタル・コンテンツを構成するための最小単位のパケットを送信させるステップと、
前記クライアントの前記第２のネットワークへの接続および前記最小単位のパケットを受信する前記クライアントからの応答を検出して、前記クライアント・リストのアドレス識別値の追加または削除により前記クライアント・リストを更新するステップと、
前記第２のネットワーク内で使用されるマルチキャスト・アドレス値を前記クライアントに送信させるステップと
をコンピュータに対して実行させる、プログラムが提供される。
【００２６】
本発明では、サーバに対してさらに前記サーバに対して、さらに最小単位のパケットを送信するべきクライアントの選択手段を変更するために使用される前記第２のネットワークの環境情報を格納したドメイン・リストを参照させるステップを実行させる。
【００２７】
さらに、本発明によれば、第１のネットワークと第２のネットワークとを介してディジタル・コンテンツを配信するためのクライアントとしてコンピュータを制御するためのコンピュータ実行可能なプログラムであって、前記プログラムは、
前記第１のネットワークに接続されたサーバから前記第２のネットワークのネットワーク環境に応答して選択されたコンピュータに対してディジタル・コンテンツを構成するための最小単位のパケットを受信するステップと、
前記最小単位のパケットを受信した前記コンピュータに対して、前記最小単位のパケットのコピー・パケットを作成させるステップと、
前記コンピュータから前記コンピュータが帰属される第２のネットワークへと前記作成されたコピー・パケットをマルチキャストさせ、前記第２のネットワークに帰属されるすべてのコンピュータに対して前記受信した最小単位のパケットを共有させるステップと
を実行させる、プログラムが提供される。
【００２８】
本発明では、前記コンピュータに対し、前記サーバから送信され、前記第２のネットワーク内でマルチキャストを行うためのマルチキャスト・アドレス値を取得させるステップを実行させることができる。
【発明を実施するための最良の形態】
【００２９】
セクションI  P2G型データ配信の概略的な説明
図１は、本発明のディジタル・コンテンツ配信システム１０の概略図である。本発明のディジタル・コンテンツ配信システム１０は、ネットワーク１２に接続されたサーバ１４と、それぞれルータ１６およびスイッチング・ハブ１８といったネットワーク機器を介してネットワーク１２に接続された複数のクライアント２０とを含んで構成されている。図１に示されたネットワーク１２としては、インターネット、ＷＡＮ、ＬＡＮといったネットワークを挙げることができ、ネットワークを構成するための通信媒体としては、公衆電話回線、ＩＳＤＮ、ＡＤＳＬ、光通信、地上波無線通信などを使用することができる。サーバ１４は、ネットワーク１２およびネットワーク２２を介して、クライアント２０へと、本発明により、ディジタル・コンテンツを配信する。
【００３０】
本発明において配信されるディジタル・コンテンツとしては、リアルタイム性を持って同時に複数のクライアントに対してコンテンツの提供を行うことが必要な、ＭＰＥＧ２、ＭＰＥＧ４、またはさらに高次の動画イメージ・データなどを挙げることができる。また、本発明においてはディジタル・コンテンツとしては、動画イメージ・データの他、動画イメージ・データと音響データ、テキスト・データといった複数の種類のディジタル・データを含んで構成されたマルチメディア・データを用いることもできる。また、本発明においては、マルチメディア・データの他にも、ソフトウェアなどを含む任意のディジタル・データを配信することができる。
【００３１】
また、クライアント２０は、ルータ１６およびスイッチング・ハブ１８などを介してネットワーク１２へと接続されている。また、クライアント２０は、同一のルータ１６ごとに割り当てられた、たとえばＩＰアドレスなどのドメイン識別値に基づき、所定のドメイン番号などが割り当てられるなどの方法によってサーバ１４により識別されている。また、所定のドメイン内においてクライアント２０は、本発明の好ましい実施の形態においては、P2P接続で接続されたネットワーク２２を形成していて、ドメイン内でのクライアント相互の通信が可能とされている。
【００３２】
さらに、本発明においては、スイッチング・ハブ１８を使用して形成されるコリジョンレス・ドメインの他、例えばルータ１６を介してネットワーク１２から分岐され、ワイヤレス・ローカルエリア・ネットワーク（ＬＡＮ）のためのターミナル、リピータ・ハブ／ブリッジといったスイッチング機能を有しないネットワーク手段２４によりドメインとして構成されたコリジョン・ドメイン２６を含んで構成されている。より具体的には、コリジョン・ドメイン２６は、例えばワイヤレス・ローカル・ネットワーク、赤外線ローカル・ネットワークといったいわゆるワイヤレスＬＡＮや、イーサネット（登録商標）といった有線ＬＡＮ、光ファイバなどで相互接続された光ＬＡＮなどを使用するローカル・ネットワーク２８として構成されている。
【００３３】
本発明において使用することができるサーバ１４としては、パーソナル・コンピュータ、またはワークステーションから構成することが可能であり、このパーソナル・コンピュータ、またはワークステーションとしては、ＰＥＮＴＩＵＭ（登録商標）：インテル社、といったＣＰＵ、またはこれと互換性のあるＣＰＵを搭載することが可能で、ＷＩＮＤＯＷＳ（登録商標）：マイクロソフト・コーポレーション）、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ（マイクロソフト・コーポレーション）、ＯＳ／２（商標：インターナショナル・ビジネス・マシーンズ・コーポレーション）、ＡＩＸ（商標：インターナショナル・ビジネス・マシーンズ・コーポレーション）、ユニックス、リナックスといったオペレーティング・システムを動作させることが可能なパーソナル・コンピュータやワークステーションを挙げることができるが、これらのものに限定されるわけではない。
【００３４】
また、本発明において使用することができるクライアント２０としては、上述したサーバ１４に適用することができるパーソナル・コンピュータ、またはワークステーションを使用することができる。この他にも、特にコリジョン・ドメイン２６では、ノートブック型パーソナル・コンピュータや、ＰＤＡ、セルラ電話などの携行性の高いコンピュータなどを使用することができる。
【００３５】
図１に示したディジタル・コンテンツ配信システムは、スイッチング手段を使用したコリジョンレス・ドメインと、コリジョン・ドメインとが共存しているものとして示されている。しかしながら、本発明は、すべてのドメインがコリジョン・ドメインであってもよい。
【００３６】
図１に示した本発明のディジタル・コンテンツ配信システム１０のコンテンツ配信処理を概略的に説明すると、サーバ１４は、動画イメージ・データを複数のストリームへと分解し、１つのストリームをさらに複数のパケットへと分割して、サーバ１４から、選択されたクライアント２０へと、ソース・パケットとして重複することなく送信する構成とされている。本発明においては、ソース・パケットは、ディジタル・コンテンツを再構成するために必要とされる最小単位のパケットのことを意味し、所定のドメインには、後述するように、特に障害が発生しない限り、重複送信されることのないパケットを意味する。ソース・パケットは、クライアントを選択するための選択手段がコリジョンレス・ドメインまたはコリジョン・ドメインに依存して変更されるものの、所定のドメインに帰属される少なくとも１つのクライアントへと送信される。ソース・パケットを受信したクライアントは、そのドメイン内に含まれる他のクライアントへと、受信したソース・パケットのコピー（以下コピー・パケットとして参照する。）を送信する。
【００３７】
コピー・パケットを受信したクライアントは、所定の期間にわたりコピー・パケットを蓄積し、所定の期間経過後に、パケットに付されたたとえば連番として付されたパケット識別子を使用してストリームを再構成し、クライアントにおいてディジタル・コンテンツを表示または再生させる。すなわち、本発明においては、サーバ１４は、１つのグループに対して重複したパケットをクライアントごとに送信すること無く、所定のグループに属するクライアントに同一のディジタル・コンテンツの共有を可能とする。コリジョンレス・ドメイン上述したコンテンツ配信処理のより詳細については、上記特許文献１において詳述したので、これ以上の説明は、行わない。
【００３８】
セクションII  コリジョン・ドメインへのコンテンツ配信および共有
図２には、図１に示したコンテンツ配信システムにおいて、サーバ１４からコリジョン・ドメイン２６へとソース・パケットが送信される場合の、ソース・パケットと、コピー・パケットの送信の実施の形態を示す。図２において、実線で示した矢線がソース・パケットの伝送を示し、破線で示した矢線が、コピー・パケットの伝送を示す。なお、図２に示した実施の形態は、説明のため、コリジョンレス・ドメインおよび他のコリジョン・ドメインについて省略して示している。
【００３９】
サーバ１４からネットワーク１２へと送出されたソース・パケットは、ルータ１６ａを介して、スイッチング機能を有しないネットワーク機器２４に到達する。ソース・パケットには、サーバがランダムに選択したコリジョン・ドメインに帰属されるクライアント２０ａ〜２０ｆのうちの１つの例えば、クライアント２０ａのIPアドレスといったアドレス識別値が含まれている。ネットワーク機器２４は、受け取ったソース・パケットをローカル・ネットワーク２８へと送出させている。ソース・パケットは、ローカル・ネットワーク２８へと送出された後、ソース・パケットに含まれたアドレス識別値を有するクライアントへと読み込まれる。
【００４０】
図３には、本発明において使用することができるソース・パケット３０の概略的な構成を示す。図３に示すように、サーバ１４から送信されたソース・パケット３０は、ＩＰヘッダ情報を含んで構成されている。ＩＰヘッダ情報は、ＩＰバージョン情報や送信元アドレス３０ａ、宛先アドレス３０ｂを含んで構成されている。さらに、ソース・パケット３０は、配信を行うデータ・パケット３０ｃと、ソース・パケット３０に固有の連番として付されたパケット識別子３０ｄとを含むのが示されている。また、ソース・パケット３０には、サーバ１４がソース・パケット３０を送信した送信時刻３０ｅが付加される。本発明においては、上述したデータ・パケット３０ｃ、パケット識別子３０ｄと、送信時刻３０ｅとを、アプリケーション・レベルで作成する独自パケットとして構成することができる。
【００４１】
図４には、本発明において使用することができるコピー・パケット３２の概略的な実施の形態を示す。コピー・パケット３２は、概ね、受け取ったデータ・パケット３０ｃと、パケット識別値３０ｄとがコピーされ、同時に当該コリジョン・ドメイン内でマルチキャスト可能なマルチキャスト・アドレス３２ａ、例えば239.xxx.yyy.zzzと、コピー・パケット３２を送出したクライアント２０ａの送信元アドレス３２ｂとを含んでいる。図４に示されたコピー・パケット３２は、ローカル・ネットワーク２８へと送出された後、ローカル・ネットワーク２８に接続された、図２に示された他のクライアント２０ｂ〜２０ｆにより取得され、バッファ・メモリに格納される。
【００４２】
上述したクライアント２０ａ〜２０ｆの処理は、適切な間隔で元のディジタル・コンテンツを再生できるだけ、パケットがバッファ・メモリに蓄積されるまで繰り返される。その後、パケット識別値を使用してパケットの完全性を判断し、必要に応じてパケットのソーティングを実行し、各クライアントにおいてディジタル・コンテンツの再構築が実行される。本発明においては、ソース・パケットを構成させるために特定の形式、アプリケーションを指定するものではないが、例えば、ソース・パケットを「.wav」ファイルの形式で作成し、例えば再生プログラムとして、MediaPlayer（商標）といったアプリケーションを使用することができる。
【００４３】
セクションIII  本発明のサーバ、クライアントおよびそれらの実行する処理
図５は本発明のサーバ１４の概略的な構成を示した図である。図５に示されたサーバ１４は、ネットワーク１２に対して、モデム、ＤＳＵ、またはネットワーク・インタフェイス・カードといった通信手段３４を介して接続されており、図示しないクライアントへとディジタル・コンテンツを配信している。サーバ１４には、たとえば、番組、講演会、挨拶、教育プログラムなどが、記憶装置３６に保持されている。本発明におけるディジタル・データとしては、上述した動画イメージ・データを含む、マルチメディア・データとして構成することが好ましいが、これ以外にもディジタル・データであれば、いかなるものであってもよい。
【００４４】
サーバ１４が、ディジタル・コンテンツをクライアントへと送信する場合には、まず、ＣＰＵ３８が、記憶装置３６からディジタル・コンテンツを読み出し、読み出されたディジタル・コンテンツをソース・エンコーダ４０およびＦＥＣエンコーダ４２へと送る。ディジタル・データを受信したソース・エンコーダ４０およびＦＥＣエンコーダ４２は、ディジタル・データに対してストリーミング処理を施し、さらに１ストリームを所定のサイズのパケットに分割する。また、サーバ１４は、送信するべきドメインのネットワーク環境に依存して送付するべきクライアントのアドレス識別値の選択をおこなうためのクライアント選択手段４４を含んで構成されている。
【００４５】
クライアント選択手段４４は、メモリ４６に格納されたクライアント・リスト５０およびドメイン・リスト５６を参照して、クライアント識別子を取得する。その後、取得されたアドレス識別値、送信元アドレス、送信時刻、パケット識別値などを追加して、ソース・パケット３０が生成される。生成されたソース・パケット３０は、通信手段３４を介して、ランダムに選択されたコリジョン・ドメインに帰属されるクライアントへと配信される。この場合にも、サーバ１４は、所定のコリジョン・ドメインに対し、最小単位のパケットが送信させるにすぎず、重複したソース・パケットの送信を行うことがない。
【００４６】
図６には、本発明において使用することができるクライアント・リスト（ａ）およびドメイン・リスト（ｂ）の実施の形態を示す。図６（ａ）に示したクライアント・リスト５０は、コリジョン・ドメインごとに与えられるドメイン識別値５２に基づき、ドメイン番号が１〜Ｎまで登録されている。また、クライアント・リスト５０には、そのドメインに帰属されるクライアントであって、その時点でドメインに接続されており、P2G型データ配信への参加要求“Joinrequest”を発行したクライアントのアドレス識別値５４が登録されている。
【００４７】
また、図６（ｂ）に示されたドメイン・リスト５６は、ドメインのネットワーク環境と、ドメイン番号といったドメイン識別値とを含んで構成される、ハッシュ・テーブルまたはデータベースとして構成することができる。このドメイン・リスト５６は、P2G型データ配信を希望するドメインのネットワーク管理者が、P2G型データ配信に登録する際に、サーバ１４に対してそのドメインのネットワーク環境を登録した時点で、あらかじめサーバ１４に作成され、同様にハッシュ・テーブルや、データベースといった形態で格納させておくことができる。
【００４８】
また、本発明では、図６に示したように、クライアント・リスト５０を、単一のクライアント・リストとして、すべてのドメインを登録しておき、ドメイン・リスト５６を別に構成することもできる。また、本発明の別の実施の形態では、クライアント・リストとドメイン・リストとを同一のテーブルとして構成し、このテーブルに対して、例えばコリジョン環境識別カラムを設け、クライアントからの接続要求または参加要求または後述するレスポンス・パケットを受け取った段階で、テーブルの更新、異なるクライアント選択処理といったサーバ処理を実行させることができる。
【００４９】
本発明では、クライアント・リスト５０は、ハッシュ・テーブルといった構成で実装することができる。クライアント・リスト５０の更新は、アドレス識別値の追加、または削除により実行される。クライアントのアドレス識別値を追加する場合の処理は、クライアントがコリジョン・ドメインを形成しているローカル・ネットワーク２６に接続された段階で、サーバ１４に対して参加通知“Joinrequest”を発行し、参加通知“Joinrequest”に応答して、サーバ１４が“IPmulticastaddress”を送付し、クライアントに対してIPマルチキャスト・アドレスの購読処理が完了した時点で、クライアント・リスト５０に追加させることができる。
【００５０】
また、本発明の別の実施の形態において、サーバ１４がIPマルチキャスト・アドレスを送付せずともクライアントが該当するマルチキャスト・アドレスを購読できる場合には、ドメインにクライアントが接続した段階で、クライアントからサーバ１４へと“helloacknowledgement”を通知した段階でクライアント・リスト５０にアドレス識別値を追加して更新することができる。
【００５１】
以下、コリジョン・ドメインにおいてクライアントを選択するためのクライアント選択手段４４の機能処理を含むサーバ１４の処理について詳細に説明する。サーバ１４は、P2G型データ配信への参加要求、例えば“Joinrequest”を受け取ると、参加要求のパケットを解析して、参加要求を発行したクライアントを特定する。この場合、本発明を明確に説明するため、参加要求は、コリジョン・ドメインに帰属されたクライアントから発行されたものとして説明を行う。参加要求から、クライアントが帰属されるドメインの、例えばサブネットワーク・マスクなどのドメイン識別値が特定されると、サーバ１４は、当該ドメイン識別値に帰属されるクライアントのIPアドレスといったアドレス識別値をランダムに選択して、宛先アドレスとして設定する。その後、サーバ１４は、選択されたクライアントのアドレス識別値を含んだ図３に示した構成を有するソース・パケット３０を生成して、通信手段３４を介してネットワーク１２へと送出させることにより、クライアント２０へのソース・パケット３０の送信を行う。
【００５２】
サーバ１４が、クライアント・リストからクライアント識別値を選択する場合には、本発明の特定の実施の形態において、コリジョン・ドメインについては、ランダムに登録されているクライアント識別値を選択することができる。また、本発明の他の実施の形態では、直前にソース・パケットを送信したクライアント識別値を１つだけ除外して、残されたクライアント識別値からランダムにソース・パケットの選択を実行させることもできる。上述した他の実施の形態では、直前に送付されたソース・パケットからコピー・パケットを作成している処理を実行しているクライアントに再度ソース・パケットが送付される可能性を確実に排除することができるので、コリジョン・ドメインに対してより効率的なコンテンツ配信を行うことを可能とする。
【００５３】
本発明の好適な実施の形態では、図５に示すように通信手段３４は、送信バッファ３４ａを含んで構成されている。送信バッファ３４ａには、ソース・パケット３０を送信したクライアントごとに、キュー３４ｂが格納されている。一方、クライアント選択手段４４は、クライアントごとに割り当てられたキューの残量をモニタする、キュー・モニタ４４ａを含んで構成されている。
【００５４】
図７には、本発明の送信バッファ３４ａ内に格納されたキュー３４ｂの状態と、それに対応するクライアント２０ａ〜２０ｆのレスポンス状態を、送信指令がなされた時刻t0から、あらかじめ設定された時間間隔ｔ後の状態を使用して概略的に示す。図７に示されるように、送信バッファ３４ａに格納されたキューの占有割合は、クライアント２０ｆに示されるように、ソース・パケット３０の受信処理に遅延が生じているほど、ソース・パケット３０の送信を行った時刻t0bからの時間tだけ経過した段階での送信データによるキュー占有割合が増加することが示される。なお、図７では、残されたデータを黒の領域で示している。他方では、図７には、受信処理を迅速に行うことができるクライアント２０ａは、ソース・パケット３０の送信指令t0fから時間tだけ経過した後のキュー占有割合が低くなることも示されている。
【００５５】
本発明の好適な実施の形態では、クライアント選択手段４４に含まれたキュー・モニタ４４ａは、クライアントごとのキュー占有割合を算出し、その値を、クライアントのレスポンス指標とすることができる。このレスポンス指標は、値が小さければクライアントが良好なレスポンスを有していることに対応し、大きければクライアントが低いレスポンスを有していることを示す。このレスポンス指標は、より詳細には後述するが、コリジョンレス・ドメインにおける、ソース・パケットを送信する次のクライアントの指定や、コリジョンレス・ドメインおよびコリジョン・ドメインでのクライアントの離脱やダウンなどをモニタするために使用することができる。
【００５６】
また、本発明のさらに他の実施の形態では、クライアントのレスポンス状態をモニタするために、特願２００２−３０３８５０号明細書に記載されるように、ラウンド・トリップ・タイム(Round Trip Time:RTT)を使用することができる。この実施の形態では、サーバ１４は、クライアントからソース・パケット３０を受け取ったことを通知するレスポンス・パケットをモニタしている。レスポンス・パケットには、ソース・パケット３０において説明したIPヘッダ情報の他、受信したパケットのパケット識別値のコピー、ソース・パケット３０に付された送信時刻のコピーなどを含ませることができる。本発明では、レスポンス・パケットを使用して、サーバ１４がRTTを算出し、当該クライアントのその時点のローカル・ネットワークにおける負荷状態および接続状態を確認する。このための具体的な処理としては、所定の宛先に送付したソース・パケット３０をサーバ１４の適切なメモリに格納させておき、サーバ１４がレスポンス・パケットを受信した段階で、それぞれのレスポンス・パケットに記録された送信時刻と、サーバ１４におけるその時点での時間の時間差を算出して、サーバ１４にRTTを取得させることができる。さらに、本発明において、特に不都合がない範囲で、RTTを直接クライアントの接続状態を示す指標として使用することもできる。
【００５７】
その後サーバ１４は、本発明の特定の実施の形態では、RTT-1を計算して、クライアントのレスポンス指標(indicator)とする。RTT-1の値は、クライアント選択手段４４においては、コリジョン・ドメインに帰属されるクライアントに対しては、レスポンスに対するしきい値Tと比較される。コリジョン・ドメインのクライアントについては、RTT-1≦Tの場合には、クライアントが例えば、ダウンしてしまった、またはホット・スポットから離脱してしまった、と判断することができる。
【００５８】
本発明において、上述したレスポンス指標を使用してクライアントのレスポンスを判断し、所定のしきい値との比較に基づきクライアントがソース・パケット３０の配信において信頼性が低下したことを検出する。本発明においては、上述した基準でのレスポンス指標を具体的な実施の形態として説明したものの、それ以外にもこれまで知られた方法・手段を使用してレスポンス指標を取得することができる。上述したように、レスポンス指標の生成方法によらず、レスポンスの信頼性が低下した場合には、ソース・パケット３０の共有が保証できないこととなる。このため、サーバ１４は、メモリからソース・パケット３０を読み出して、クライアント・リスト５０の他のクライアント識別値を割り当ててリトライ・パケットを生成する。リトライ・パケットは、新たに選択されたクライアントに向けて送信される。サーバ１４は、リトライ・パケットを送信したクライアントからのレスポンス・パケットをモニタして、確実にP2G型データ配信を行うことができる。
【００５９】
また、レスポンス指標に基づき異常遅延を示したクライアントは、処理が過大になっているか、またはまったくレスポンスできない状態となっているので、ソース・パケットの配信を受けるには適切ではない。このため、本発明の特定の実施の形態では、コリジョン・ドメインについて上述した異常遅延が検出されると、サーバ１４は、クライアント・リスト５０から当該クライアントのアドレス識別値を削除することにより、上述したソース・パケットの重複送信処理が繰り返されないように、クライアント・リストを更新させる。
【００６０】
本発明において、異常遅延を与えたクライアントをクライアント・リストから削除したとしてもコリジョン・ドメイン内では、IPマルチキャストでコピー・パケットが送信される。このため、例えばホット・スポットからクライアントが離脱したような場合であっても、また何らかの処理で応答が遅れた場合であっても、その時点でローカル・ネットワークに接続されているクライアントには、確実にコピー・パケットが送られるので、P2G型データ配信には、大きな問題を生じさせることがない。
【００６１】
図８には、サーバ１４の実行する処理の概略的なフローチャートを示す。サーバ１４は、ステップＳ１０で、クライアントからP2G型データ配信を希望する、例えば“Joinrequest”を受信する。ステップＳ１２で、“Joinrequest”を発行したクライアントに対してマルチキャスト・アドレスを送付して、パケットのドメイン内での送受信を可能とさせる。ステップＳ１４では、クライアント・リストからアドレス識別値をランダムに１つ選択し、ステップＳ１６で、ソース・パケットを生成させ、ネットワークにソース・パケットを送出する。
【００６２】
ステップＳ１８では、サーバ１４は、クライアントのレスポンス状態を、キュー占有割合またはRTTを使用してモニタし、ステップＳ２０において、キュー占有状態またはRTTからレスポンス指標を計算させ、メモリに格納させる。ステップＳ２２で、レスポンスが充分ではない、またはネットワークから離脱した可能性があると判断した場合(no)には、サーバ１４は、ステップＳ２４においてクライアント・リストから、該当するクライアントのアドレス識別値を削除する。次いで、ステップＳ２６で、ソース・パケットの喪失が生じないようにするため、まだ登録されているクライアントの中から次のアドレス識別値をランダムに選択する。ステップＳ２８では、サーバ１４の適切なメモリに格納されているソース・パケットを読み出し、新たなアドレス識別子を追加してリトライ・パケットを作成し、ネットワークへと送信し、ステップＳ１８において、レスポンス・パケットを再度モニタして、処理を継続させる。一方、レスポンス指標に基づき、クライアントのレスポンスが充分であると判断した場合(yes)には、サーバ１４は、処理をステップＳ１８へと戻し、次のソース・パケットの送信処理を実行する。
【００６３】
図９は、本発明において使用することのできるクライアント２０の構成を示した図である。図９に示したクライアント２０は、ネットワーク・インタフェイス・カード（ＮＩＣ）６０を介して、ローカル・ネットワーク２８へと接続されている。クライアント２０は、さらに、受信バッファ６２と、RAMなどのメモリ６４とを含んで構成されている。受信バッファ６２は、受信したソース・パケットおよびコピー・パケットを、動画イメージ・データのストリームの再構成処理が開始されるまでの間、保持している。
【００６４】
本発明においては、受信バッファ６２は、受信したパケットを受信するごとにパケット識別値に対応したアドレスに受信したパケットを書き込みを行う、リング・バッファとして構成することができる。また、クライアント２０は、中央処理装置（ＣＰＵ）６６と、ソース・デコーダ６８と、ＦＥＣデコーダ７０とを含んで構成されている。ただし、本発明においてはＦＥＣデコーダは、必ずしも必要ではない。ＣＰＵ６６は、クロックにより駆動されており、受信バッファ６２において所定期間ごとに蓄積されたパケットを読み出してＦＥＣデコーダ７０およびソース・デコーダ６８へと送り、１ストリーム分の動画イメージ・データを再構成している。再構成された１ストリーム分の動画イメージ・データは、ディスプレイ７２へと表示または再生され、クライアントのユーザに対して提供される。
【００６５】
ユーザに対して表示または再生された動画イメージ・データは、クライアント２０から削除することもできるし、また、ディジタル・コンテンツの開始から終了までの全ストリームをメモリ６４に保持させておき、ハードディスク、光磁気ディスク、磁気テープといった記憶装置７４に記憶させておくこともできる。
【００６６】
図１０には、本発明におけるクライアント２０におけるソース・パケット３０の受信およびコピー・パケットの送出までの処理の概略的なフローチャートを示す。図１０に示したクライアントの処理は、ステップＳ３０において、パケットを受信する時点から開始する。ステップＳ３２では、受信したパケットを受信バッファに格納させる。ステップＳ３４で受信したパケットが、ソース・パケットであるか否かを判断する。受信したパケットがソース・パケットである場合(yes)には、クライアント２０は、処理をステップＳ３６へと進ませ、ソース・パケットからコピー・パケットを作成して、適切な送信バッファなどに格納させる。ステップＳ３８では、コピー・パケットをIPマルチキャストを使用してローカル・ネットワークへと送出させ、他のクライアントに対しパケットの共有を可能とさせる。一方、受信したパケットがソース・パケットでない場合(no)には、ステップＳ３０へと処理を戻し、次のパケットを受信する。上述した処理を実行するサーバ１４とクライアント２０とを使用して、コリジョン・ドメインに対しても良好なP2G型データ配信が可能となる。
【００６７】
図１１は、コリジョンレス・ドメインとコリジョン・ドメインとが混在するネットワーク・システムにおいて、P2G型データ配信を行うためのサーバの処理を示した図である。本発明において、コリジョンレス・ドメインとコリジョン・ドメインとの間の処理の大きな違いは、ソース・パケットを送信するクライアントの選択方法にある。
【００６８】
図１１に示したサーバ１４の処理は、ステップＳ４０から開始し、クライアント２０からのP2G型データ配信への参加要求である、“Joinrequest”を受け取る。サーバ１４は、ステップＳ４２で受け取った“Joinrequest”からクライアント２０が帰属されるドメイン識別値を取得し、ドメイン・リスト５６を参照して、コリジョンレス・ドメインであるか、またはコリジョン・ドメインであるかを判断する。ステップＳ４２の判断において、コリジョン・ドメインからの“Joinrequest”であると判断した場合(yes)には、サーバ１４は、ステップＳ４４でコリジョン・ドメイン処理を呼出す。また、ステップＳ４２でコリジョン・ドメインからの“Joinrequest”でないと判断した場合(no)には、ステップＳ４６でコリジョンレス・ドメイン処理を呼び出すことにより、ドメインの能力に応答した適切なデータ配信を実行させる。
【００６９】
図１２は、本発明のコンテンツ配信システムのより具体的な実施の形態を示した図である。図１２に示す実施の形態は、P2Gサーバ８０からインターネットといったネットワーク８２を介して、スイッチング・ハブ８４によりルーティングされたローカル・ネットワーク８６と、リピータ／ブリッジ８８によりルーティングされたローカル・ネットワーク９０とが接続されているのが示されている。LAN８６は、スイッチング・ハブ８４を介して、例えば10BASE−5、10BASE−10、10BASE−100、10BASE−TXといった規格を使用したイーサネット（登録商標）により相互接続されたコリジョンレスのネットワーク環境として構築されている。また、図１２では、ローカル・ネットワーク９０は、イーサネット（登録商標）により相互接続された環境にあるものの、リピータ／ブリッジ８８を使用したコリジョンの生じる可能性のあるネットワーク環境として構築されている。
【００７０】
詳細については、本発明の要旨ではないので説明しないが、P2Gサーバ８０は、さらにコリジョンレス・ドメインに対応した別のクライアント・リストを含んで構成されている。このクライアント・リストには、コリジョンレス・ドメインの各クライアントのアドレス識別値である、例えばIPアドレス情報と、前回ソース・パケットを送信したときのレスポンス・パケットを使用して得られた、クライアントのオーバー・ヘッドに対応する、実効スループットとが登録されている。
【００７１】
P2Gサーバ８０は、コリジョンレス環境にあるローカル・ネットワーク８６に対してP2G型データ配信を実行させるべく、上述したように、クライアント９２ａ〜クライアント９２ｄとの間でのレスポンス指標を生成させ、最も信頼性の高い、すなわちオーバー・ヘッドが小さいクライアントを順次選択して、ソース・パケットを送信させている。また、ソース・パケットを受け取ったクライアント９２ａ〜９２ｄは、ソース・パケットからコピー・パケットを作成し、当該ドメインに含まれる他のクライアントのアドレスを使用してユニキャストでコピー・パケットを配信している。
【００７２】
さらに、P2Gサーバ８０がコリジョン・ドメインに対してソース・パケットを送信する場合について説明する。P2Gサーバ８０は、ソース・パケットを送信する場合には、まずクライアント・リストに登録されたクライアントのアドレス識別値をランダムに選択する。その後、ソース・パケットを、コリジョン・ドメインに帰属されるクライアント９４ａへとユニキャストする。ソース・パケットを受け取ったクライアント９４ａは、IPマルチキャスト・アドレスを付したコピー・パケットを作成し、ローカル・ネットワーク９０へとコピー・パケットをマルチキャストすることにより、他のクライアント９４ｂ〜９４ｄに対してパケットの共有を可能とさせている。また、ソース・パケットを受け取ったクライアントは、どのドメインに帰属されているかにかかわらず、レスポンス・パケットをP2Gサーバ８０へと送り、クライアントが、ソース・パケットの受信が可能であったこと、または実効スループット、または接続状態をP2Gサーバ８０へと通知することができる。
【００７３】
図１３は、本発明のコリジョン・ドメインを構成するローカル・ネットワーク９０が、ワイヤレス通信を使用するネットワークである場合の実施の形態を示す。図１３に示すように、ワイヤレス通信を使用したローカル・ネットワーク９０の環境では、アクセス・ポイント９６を中心としてホット・スポット９８が規定される。このホット・スポット９８に含まれたクライアント９４、例えばノートブック型コンピュータ９４ａ、携帯電話９４ｂ、PDA９４ｃなどが、アクセス・ポイント９６を介して相互通信が可能とされている。図１２に示した実施の形態において問題となるのは、クライアント９４の高い移動性(mobility)にある。図１３に示したワイヤレス・ローカル・ネットワーク９０は、リピータ／ブリッジ８８により構成されるローカル・ネットワークよりもクライアント８４の離脱／参加が随時行われるので、本発明のP2G型データ配信を使用することが特に効果的に適用される。
【００７４】
以下、本発明についてワイヤレス・ローカル・ネットワーク９０を使用する場合のP2G型データ配信プロトコルの詳細について説明する。図１４は、コリジョン・ドメインがワイヤレス・ローカル・ネットワークとして構成された場合のクライアント９４と、アクセス・ポイント９６と、P2Gサーバ８０との間のトランザクションを、通信セッション確立から、ソース・パケットの送受信までの処理を時系列的に示した図である。なお、本発明において使用する用語「無線」は広く、「有線(wired)」ではないことを意味し、光通信、無線通信などを含み、通信プロトコルにしてもBluetoothなど、これまで知られたいかなるプロトコルでも使用することができる。また、P2G型データ配信は、サービス・プロバイダに対して、ユーザが登録し、所定のIPマルチキャスト・アドレスまたは必要なアクセス情報を取得することにより登録されたユーザ・ドメインごとに行われるものとして説明する。
【００７５】
図１４を使用してワイヤレス・ローカル・ネットワークにおける実施の形態を説明すると、まず、クライアントがホット・スポットに到達すると、クライアントがアクセス・ポイントを見出す。このためには、例えばIEEE802.11で規定されるActive Scanningおよびアクセス・ポイントが定期的にビーコン・パケットを送信し、クライアントがその呼びかけに応答する接続方式(Accession protocol)を使用することができる。図１４に示した実施の形態は、このうち、Active Scanning方式で、まずクライアントがアクセス・ポイントへとプローブ・パケットを送信する。プローブ・パケットを受信したアクセス・ポイントは、クライアントへと応答パケットを返し、データ・リンク層での接続を確立させる。
【００７６】
クライアントは、予めネットワーク管理者などからサーバのIPアドレスや、ポート番号などの情報を取得しており、適切な不揮発性メモリに格納させている。クライアントは、アクセス・ポイントとの間のデータ・リンク層レベルでの接続を確立した後、ネットワーク層／トランスポート層レベルで、“helloacknowledge”をP2Gサーバへと送りTCPセッションをP2Gサーバとの間で確立する。P2Gサーバは、“helloacknowledge”を受け取ると、クライアントのアドレス識別子を取得し、クライアント・リストにアドレス識別子を追加して、クライアントへと“hellopermission”を送信してクライアント−P2Gサーバ間のTCPセッションを確立させる。
【００７７】
“hello permission”を受け取ったクライアントは、その後P2G型データ配信に参加するための“Joinrequest”をP2Gサーバへと送信する。この“Joinrequest”を受け取ったP2Gサーバは、クライアントに対して、コリジョン・ドメインに対しては当該ドメインに対して予め割り当てられているマルチキャスト・アドレスを通知し、アプリケーション層レベルでのP2G型データ配信のためのセッションを確立させる。その後、P2Gサーバは、ランダムにクライアント選択するか、またはソース・パケットを送信した時刻t0からの時間tを使用してレスポンス指標を取得して、クライアントを選択し、選択されたクライアントに対してソース・パケット“sourcepacket”を送信する。なお、時間tは、レスポンス指標として、上述したように、キュー占有割合に基づいて算出される指標を使用する場合には、あらかじめ定められたサーバ１４に設定されたしきい値時間であり、RTTを使用してレスポンス指標とする場合には、破線で示されるようにレスポンス・パケットを受信した時間とされる。
【００７８】
図１５は、コリジョンレス・ドメインとコリジョン・ドメインとを含む場合のトランザクションを時系列的に示した図である。クライアントが、ホット・スポット内に入ると、アクセス・ポイントとの接続を確立させ、図１５において示したと同様に“helloacknowledgemnt”および“hellopermission”の送受信により、P2Gサーバへの登録を実行する。P2Gサーバは、ネットワーク・マップを格納しており、“helloacknowledgemnt”の受信と共に、P2G型データ配信の処理を選択し、図１５に示した実施の形態では、コリジョン・ドメインに対してはマルチキャスト・アドレスまたはコリジョンレス・ドメインに対しては、P2G木構造情報やドメイン識別情報といった必要なアクセス情報を送信して、図１４に示したと同様の処理を経て、P2G型データ配信を可能とさせている。
【００７９】
図１６〜図１８を使用して、ワイヤレス・ローカル・ネットワーク９０に接続されたクライアントとP2Gサーバとの間の接続を切断する場合のトランザクションについて説明する。クライアントとP2Gサーバとは、図１４または図１５で説明したセッション確立プロトコルにしたがって、P2G型データ配信を受けている。P2G型データ配信からクライアントが離脱する場合には、概ね３通りがある。第１の場合は、クライアントが正常にシャットダウンする場合であり、第２の場合は、P2Gサーバが配信を終了するなど、P2Gサーバからの切断を行う場合であり、第３の場合は、例えばワイヤレス・ローカル・ネットワークを使用している場合などのようにホット・スポットからクライアントが出てしまった場合またはクライアントの異常終了の場合である。
【００８０】
図１６には、クライアントが正常にシャットダウンする第１の場合を示す。図１６に示された場合には、クライアントは、例えば帰宅や、別業務のために長時間席を離れるなどの理由から、クライアントをシャットダウンすることを希望しているものと仮定する。ユーザが、クライアントに対してシャットダウン操作を行うと、クライアントは、P2Gサーバに対して例えば、“goodbye”コマンドを送信し、接続を解除することを通知する。P2Gサーバは、“goodbye”コマンドを受け取ると、IPヘッダ情報からシャットダウンしようとしているクライアントのアドレス識別子を取得する。さらにP2Gサーバは、それ以後にソース・パケットが送信されないようにするべく、クライアント・リストから該当するアドレス識別子を検索してクライアント・リストから削除する処理を実行する。
【００８１】
図１７には、P2Gサーバから特定のクライアントへの配信を終了させる場合について示されている。図１７に示された場合には、P2Gサーバの都合またはクライアント側の都合により、P2Gサーバは、クライアントとの接続状態を解除しようとする。この場合、P2Gサーバは、クライアントに対して、例えば、“kill”コマンドを送信すると共に、クライアント・リストから該当するクライアントのアドレス識別値を削除する処理を実行する。
【００８２】
また、図１８には、クライアントの異常終了や、ホット・スポットからの離脱がある場合の処理を説明する。この場合の処理、図１８に示すように、P2Gサーバからソース・パケットの送信と、それに対するクライアントのレスポンス指標とを使用して実行される。P2Gサーバは、ソース・パケットの送信後、キュー占有割合またはレスポンス・パケットから得られるRTTに基づき、レスポンス指標を当該クライアントについて所定のしきい値と比較するなどして判断し、レスポンス指標に基づき何らかの異常がクライアントに発生したと判断する場合には、コリジョン・ドメインにおいては、当該クライアントのアドレス識別値をクライアント・リストから削除する。一方、コリジョンレス・ドメインについては、オーバー・ヘッドが小さいことを示すレスポンス指標の順に次のクライアントを選択することにより対応が行われ、コリジョンレス・ドメインについてのクライアント・リストからのアドレス識別値の削除は行わなくとも良い。その後、送信したソース・パケットの喪失がないように、同一のドメインの他のクライアントに対して、リトライ・パケットを送付して、データの完全性を確保する。さらに、時間がたっても、クライアントからの“helloacknowledgement”が再度届かない場合には、TCPセッション自体をタイムアウトとして終了させ、セッションを終了させる。
【００８３】
本発明においては、上述した処理を行うことにより、これまで知られたいかなる形式のローカル・ネットワークに接続されたクライアントに対しても効率的、かつ高い確実性をもって、低コストのデータ配信を可能とする。
【００８４】
本発明の上述した各機能を実現する手段または部分は、コンピュータ実行可能なプログラム言語により記述されたソフトウェアまたはソフトウエア・モジュール群として構成することができ、必ずしも図面に記載した機能ブロックとして構成される必要はない。
【００８５】
本発明のディジタル・コンテンツ配信を実行させるための上述したプログラムは、種々のプログラミング言語、例えばＣ言語、Ｃ＋＋言語、Ｊａｖａ（登録商標）、などを使用して記述することができ、本発明のプログラムを記述したコードは、磁気テープ、フレキシブル・ディスク、ハードディスク、コンパクト・ディスク（ＣＤ）、光磁気ディスク、デジタル・バーサタイル・ディスク（ＤＶＤ）といったコンピュータ可読な記録媒体に保持させることができる。
【００８６】
これまで本発明を図面に記載した具体的な実施の形態をもって説明してきたが、本発明は、上述した特定の実施の形態に制限されるものではなく、種々の変更例および他の実施の形態であっても、本発明の効果を奏する範囲において、これまで知られたいかなる構成要素であっても用いることができる。
【図面の簡単な説明】
【００８７】
【図１】本発明のディジタル・コンテンツ配信システムの概略図。
【図２】図１に示したコンテンツ配信システムにおいて、サーバからコリジョン・ドメインへとソース・パケットが送信される場合の、ソース・パケットと、コピー・パケットの送信の実施の形態を示した図。
【図３】本発明において使用することができるソース・パケットの概略的な構成を示した図。
【図４】本発明において使用することができるコピー・パケットの概略的な実施の形態を示した図。
【図５】本発明のサーバの概略的な構成を示した図。
【図６】本発明において使用することができるクライアント・リスト（ａ）およびドメイン・リスト（ｂ）の実施の形態を示した図。
【図７】本発明において使用する送信バッファと送信バッファに格納されたキューの占有状態とを示した図。
【図８】サーバの実行する処理の概略的なフローチャートを示した図。
【図９】本発明において使用することのできるクライアントの構成を示した図。
【図１０】本発明のクライアントにおけるソース・パケットの受信およびコピー・パケットの送出までの処理の概略的なフローチャート。
【図１１】コリジョンレス・ドメインとコリジョン・ドメインとが混在するネットワーク・システムにおいて、P2G型データ配信を行うためのサーバの処理を示した図。
【図１２】本発明のコンテンツ配信システムのより具体的な実施の形態を示した図。
【図１３】本発明のコリジョン・ドメインが、ワイヤレス通信を使用するネットワークである場合の実施の形態を示した図。
【図１４】コリジョン・ドメインがワイヤレスLANとして構成された場合のクライアントと、アクセス・ポイントと、P2Gサーバとの間のトランザクションを時系列的に示した図。
【図１５】コリジョンレス・ドメインとコリジョン・ドメインとを含む場合のトランザクションを時系列的に示した図。
【図１６】クライアントとP2Gサーバとの間の接続を切断する場合のトランザクションを示した図。
【図１７】クライアントとP2Gサーバとの間の接続を切断する場合のトランザクションを示した図。
【図１８】クライアントとP2Gサーバとの間の接続を切断する場合のトランザクションを示した図。
【図１９】従来の一対多のデータ配信を行う場合の代表的な手法を示した図。
【図２０】従来の一対多のデータ配信を行う場合の代表的な手法を示した図。
【図２１】P2G型データ配信の手法を概略的に示した図。
【図２２】コリジョン・ドメインにおいて発生する不都合を、概略的に説明した図。
【符号の説明】
【００８８】
１０…ディジタル・コンテンツ配信システム、１２…ネットワーク、１４…サーバ、１６…ルータ、１８…スイッチング・ハブ、２０…クライアント、２２…第２のネットワーク、２４…ネットワーク機器、２６…コリジョン・ドメイン、２８…第２のネットワーク、３０…ソース・パケット、３２…コピー・パケット、３４…通信手段、３６…記憶装置、３８…ＣＰＵ、４０…ソース・エンコーダ、４２…ＦＥＣエンコーダ、４４…クライアント選択手段、４６…メモリ、５０…クライアント・リスト、５６…ドメイン・リスト、６０…ＮＩＣ、６２…受信バッファ、６４…メモリ、６６…ＣＰＵ、６８…ソース・デコーダ、７０…ＦＥＣデコーダ、７２…ディスプレイ、７４…記憶装置、８０…P2Gサーバ、８２…ネットワーク、８４…スイッチング・バブ、８６…ローカル・ネットワーク、８８…リピータ／ブリッジ、９０…ローカル・ネットワーク、９２…クライアント、９４…クライアント、９６…アクセス・ポイント、９８…ホット・スポット
【図１】
2005027243.tif 000003
【図２】
2005027243.tif 000004
【図３】
2005027243.tif 000005
【図４】
2005027243.tif 000006
【図５】
2005027243.tif 000007
【図６】
2005027243.tif 000008
【図７】
2005027243.tif 000009
【図８】
2005027243.tif 000010
【図９】
2005027243.tif 000011
【図１０】
2005027243.tif 000012
【図１１】
2005027243.tif 000013
【図１２】
2005027243.tif 000014
【図１３】
2005027243.tif 000015
【図１４】
2005027243.tif 000016
【図１５】
2005027243.tif 000017
【図１６】
2005027243.tif 000018
【図１７】
2005027243.tif 000019
【図１８】
2005027243.tif 000020
【図１９】
2005027243.tif 000021
【図２０】
2005027243.tif 000022
【図２１】
2005027243.tif 000023
【図２２】
2005027243.tif 000024