JP2006048575A - クライアントシステム、データ配信サーバ、データ転送システム、プログラム及び記録媒体 - Google Patents

Abstract

【課題】ネットワーク品質の影響を受けずにクライアントシステムに合理的に同報通信を行うことができるようする。
【解決手段】クライアントシステムに含まれる各端末２１は、動画配信サーバ１１からデータをダウンロードしようとする場合に、動画配信サーバ１１に対してデータのダウンロード要求を送信する前に、クライアントシステムに含まれる他の端末２１に対して、ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信する。この問い合わせに応じて端末２１から該当データを保持していることを示す応答が返信された場合、その端末からデータのダウンロードを行う。また他の端末２１いずれからも応答が返信されなかった場合、該当データを動画配信サーバ１１からダウンロードする。
【選択図】図１

Description

本発明は、サーバからクライアントに対してデータ転送を行うための技術に関し、例えば、低速回線で接続された場所に対して大容量データを同報送信するのに好適な技術に関する。

例えば、地理的に分散して配置されている多数の小規模オフィスを持つ大企業等があるが、このような場合に、情報の伝達、共有などの要望を実現するために、大企業の大規模オフィスと小規模オフィスとの間にネットワークが敷設されている。

図２５は、上記のような企業等の大規模オフィスと小規模オフィスとを接続するネットワークについて説明するための図で、図中、１０は大規模オフィス、１１は動画配信サーバ、１２はルータ、１３は大規模オフィス内部のネットワーク、２０は小規模オフィス、２１は端末、２２はルータ、２３は小規模オフィス内部のネットワーク、３０は大規模オフィス１０と小規模オフィス２０と接続するネットワークで、ネットワーク３０は、その通信品質を模式的に示している。

大規模オフィス１０と小規模オフィス２０と接続するネットワーク３０を、全て高品質ネットワークで接続しようとすると、どうしてもネットワーク３０の価格が高価となってしまう。小規模オフィス２０は地理的に分散して多数あることも多く、小規模オフィス２０には少人数の社員しかいないこともある。このため、高価なネットワークを多数の小規模オフィス２０に敷設すると、費用対効果の面で不合理となる。このため、大規模オフィス１０と小規模オフィス２０とを接続するネットワーク３０は、低価格な、すなわち低品質なものに終始している場合が少なくない。

上記のような場合に、低品質のネットワークは、帯域が細かったり、帯域が太くてもそれが補償されていなかったり、またＲＴＴなどの値が悪いためにエラーチェックつき通信を行おうとすると帯域を活用できないというような問題が発生する。

また従来から、社内に情報を周知するツールとして、テキストベースのメールや掲示板システムなどがある。しかしながら、今後コンピュータの処理能力やコンテンツ作成環境が整備されて、高品質な動画像なども社内の情報周知に活用されることが考えられる。このような高品質なデータは大容量となることが多く、それを小規模オフィス２０で複数のコンピュータ（端末２１）が受信しようとすると、中間の低品質ネットワーク３１がボトルネックとなり、充分な転送速度が実現できなかったり、他の重要な通信に影響を与えたりする。

図２６は、大規模オフィスと小規模オフィスとのデータ転送を円滑に行うための従来の手法について説明するための図である。
上記のような問題を解決する従来の技術として、小規模オフィス２０側に代理サーバ（レプリケーション動画配信サーバ）２４を設置し、ネットワーク消費の少ない例えば夜間のうちに、大規模オフィス１０から小規模オフィス２０にデータを転送しておき、その代理サーバ２４からユーザが使用する端末２１にデータを供給するという構成がとられる。

また、例えば、特許文献１には、サーバ等を用いたネットワークにおいて、サーバを経由するトラフィックを軽減して各情報処理装置の利用者間における円滑かつ多様なコミュニケーションを実現する情報処理技術が開示されている。ここでは、グローバルＩＰアドレスを有するクライアント間同士の接続をピアツーピア接続とし、その他のクライアント間の接続をサーバを経由したクライアント・サーバ型接続とする。ピアツーピア接続は、サーバから取得した互いのグローバルアドレスに基づいて確立され、クライアント・サーバ型接続からピアツーピア接続への一部遷移によって、サーバに対するトラフィックの一極集中を避けるようにしている。
特開２００３−２０３０２３号公報

上記のように、小規模オフィス２０側に代理サーバ２４を設置し、ネットワーク消費の少ない例えば夜間のうちにデータを転送するような構成は、小規模オフィス２０に代理サーバ２４を設置する必要がある。小規模オフィス２０は通常人員も少なく、従って代理サーバ２４を管理する人員を割けないことも少なくない。また、小規模オフィス２０は数が多く、投資額も高価になるという問題も生じる。

また、上記特許文献１の技術は、端末とサーバが通信を行い、ピアツーピア通信が可能なＩＰアドレスをもつ端末の情報を取得して、その端末に対してサーバを介したクライアント・サーバ型通信から、ピアツーピア通信に遷移させる。
すなわち、特許文献１の技術は、端末同士が通信する場合に、サーバ・クライアント通信からピアツーピア通信に遷移させることにより、サーバ・クライアント通信によるサーバへのトラフィックの集中を避けるようにしたものにすぎず、サーバから端末（クライアント）へのデータ配信を行う際の通信障害を解消する目的でなされたものではない。
この場合に、サーバから端末へのデータ配信量を抑えるために、端末がデータの取得先を検索することもなく、すでにデータ配信がなされている端末にピアツーピア接続することも生じる。

本発明は、上述のごとき実情に鑑みてなされたもので、データのダウンロードを常にサーバから行うことなく、クライアントシステム内の他端末から適宜取得できるようにすることにより、ネットワーク品質の影響を受けずにクライアントシステムに合理的に同報通信を行うことができるようした、クライアントシステム、データ配信サーバ、データ転送システム、プログラム及び記録媒体を提供することを目的とするものである。

請求項１の発明は、サーバとの間でネットワークを介して接続され、該サーバからのデータのダウンロードを可能とする複数のコンピュータよりなり、該複数のコンピュータが相互に接続されてなるクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記サーバからデータをダウンロードしようとする場合に、前記サーバに対してデータのダウンロード要求を送信する前に該クライアントシステムに含まれる他のコンピュータに対して、前記ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信する問い合わせ送信手段と、前記問い合わせ情報に応じて前記他のコンピュータのいずれかが前記ダウンロードしようとするデータを保持していることを示す応答を返信した場合、該応答を返信したコンピュータからデータのダウンロードを行う手段と、前記他のコンピュータのいずれからも前記ダウンロードしようとするデータを保持していることを示す応答が返信されなかった場合、前記サーバから前記データをダウンロードする手段とを有することを特徴とする。

請求項２の発明は、請求項１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記問い合わせ送信手段による問い合わせ情報の送信を行う前に、前記サーバに対して前記ダウンロードしようとするデータ容量を問い合わせるデータ容量問い合わせ手段と、該データ容量の問い合わせに応じて前記サーバから返信されたデータ容量の情報と、前記問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、該データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記データバッファの保存データを削除して使用可能容量を確保するデータバッファ確保手段を有し、前記データバッファ確保手段によりデータバッファ容量を確保した上で、前記他のコンピュータまたは前記サーバからデータのダウンロードを行うことを特徴とする。

請求項３の発明は、請求項１または２に記載のクライアントシステムにおいて、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、ＬＲＵによって未使用の時間が最も長いデータから削除していくことを特徴とする。

請求項４の発明は、請求項１ないし４のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、他のコンピュータに対して、該他のコンピュータが保持しているデータについて問い合わせる手段を有し、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記保持しているデータの問い合わせに対する他のコンピュータからの回答に基づいて、保持しているコンピュータ数が多いデータから優先して削除することを特徴とする。

請求項５の発明は、請求項１ないし４のいずれか１に記載のクライアントシステムにおいて、前記問い合わせ情報送信手段は、マルチキャスト通信により、複数の他のコンピュータに対して問い合わせ情報を送信することを特徴とする。

請求項６の発明は、請求項１ないし５のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記問い合わせに対する応答を返信したコンピュータからデータのダウンロードを行う際、前記応答を返信したコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出する手段と、前記サーバに対して、該サーバが配布している前記ダウンロードデータに該当するメッセージダイジェスト値を取得する手段と、前記ダウンロードしたデータから算出したメッセージダイジェスト値と前記サーバから取得したメッセージダイジェスト値を比較する手段と、該メッセージダイジェスト値を比較した結果、該比較したメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にする手段とを有することを特徴とする。

請求項７の発明は、サーバとの間でネットワークを介して接続され、該サーバからのデータのダウンロードを可能とする複数のコンピュータよりなり、該複数のコンピュータが相互に接続されてなるクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記サーバから前記クライアントシステムのコンピュータに対するプッシュ転送によりデータをダウンロードする手段と、該プッシュ転送によりダウンロードしたデータを、前記クライアントシステムに含まれる他のコンピュータにプッシュ転送する手段とを有することを特徴とする。

請求項８の発明は、請求項７に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、他のコンピュータから前記プッシュ転送されたデータをダウンロードする手段と、該他のコンピュータからプッシュ転送によりダウンロードしたデータを、前記クライアントシステムに含まれる更に他のコンピュータにプッシュ転送する手段とを有することを特徴とする。

請求項９の発明は、請求項７または８に記載のクライアントシステムにおいて、前記サーバからダウンロードしたデータ、または前記他のコンピュータからダウンロードしたデータを前記プッシュ転送する手段は、マルチキャスト通信により、複数の他のコンピュータに対してプッシュ転送を行うことを通知することを特徴とする。

請求項１０の発明は、請求項７ないし９のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、前記サーバからのプッシュ転送によるダウンロードを行うに際し、または前記他のコンピュータからのプッシュ転送によるダウンロードを行うに際し、前記サーバに対して前記ダウンロードしようとするデータ容量を問い合わせるデータ容量問い合わせ手段と、該データ容量の問い合わせに応じて前記サーバから返信されたデータ容量の情報と、前記問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、該データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記データバッファの保存データを削除して使用可能容量を確保するデータバッファ確保手段を有し、該データバッファ確保手段によりデータバッファ容量を確保した上で、前記サーバまたは前記他のコンピュータからデータのダウンロードを行うことを特徴とする。

請求項１１の発明は、請求項１０に記載のクライアントシステムにおいて、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、ＬＲＵによって未使用の時間が最も長いデータから削除していくことを特徴とする。

請求項１２の発明は、請求項１０に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、他のコンピュータに対して、該他のコンピュータが保持しているデータについて問い合わせる手段を有し、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記保持しているデータの問い合わせに対する他のコンピュータからの回答に基づいて、保持しているコンピュータ数が多いデータから優先して削除することを特徴とする。

請求項１３の発明は、請求項７ないし１２のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記プッシュ転送により他のコンピュータからデータのダウンロードを行う際、前記他のコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出する手段と、前記サーバに対して、該サーバが配布している前記ダウンロードデータに該当するメッセージダイジェスト値を取得する手段と、前記他のコンピュータからダウンロードしたデータから算出したメッセージダイジェスト値と前記サーバから取得したメッセージダイジェスト値を比較する手段と、該メッセージダイジェスト値を比較した結果、該比較したメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にする手段とを有することを特徴とする。

請求項１４の発明は、請求項７ないし１３のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムが含まれる各コンピュータは、予め同一データを転送する転送回数を定めて保持する手段と、前記プッシュ転送より他のコンピュータにデータを転送してダウンロードさせる場合に、データの転送回数を計数し、該転送回数が前記予め定めた転送回数に達した場合に前記データ転送を停止する手段とを有することを特徴とする。

請求項１５の発明は、請求項１ないし６のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、コンピュータ自身から前記サーバ装置までのルートのトレースを行ってその結果を保持するルートトレース手段と、前記問い合わせ送信手段による問い合わせ先を選択するため、問い合わせ先の候補となる他のコンピュータに対して、該他のコンピュータから前記サーバまでのルートのトレース結果を要求するルートトレース結果要求手段と、該ルートトレース要求手段の要求に応答して得られた前記他のコンピュータのルートトレース結果と前記コンピュータ自身のルートトレース結果とを比較して、コンピュータ自身のルートトレース結果に似ている他のコンピュータを検出するルートトレース比較検出手段とを有し、前記問い合わせ送信手段は、前記ルートトレース比較検出手段の検出結果に従って、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、前記ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信することを特徴とする。

請求項１６の発明は、請求項７ないし１４のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、コンピュータ自身から前記サーバ装置までのルートのトレースを行ってその結果を保持するルートトレース手段と、前記プッシュ転送によるデータ転送先を選択するため、転送先の候補となる他のコンピュータに対して、該他のコンピュータから前記サーバまでのルートのトレース結果を要求するルートトレース結果要求手段と、該ルートトレース結果要求手段の要求に応答して得られた前記他のコンピュータのルートトレース結果と前記コンピュータ自身のルートとレース結果とを比較して、コンピュータ自身のルートトレース結果に似ている他のコンピュータを検出するルートトレース比較検出手段とを有し、前記プッシュ転送により他のコンピュータにデータを転送してダウンロードさせる場合、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、前記プッシュ転送を実行することを特徴とする。

請求項１７の発明は、請求項１ないし１６のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれるコンピュータ同士の通信は、ピアツーピアにより行われることを特徴とする。

請求項１８の発明は、クライアントに対してデータをダウンロードさせるようにしたデータ配信サーバであって、該データのメッセージダイジェスト値をクライアントから要求された場合、及び該データのダウンロードが要求された場合に、該クライアントが該データを取り扱ったものと認識して、該メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することを特徴とする。

請求項１９の発明は、請求項１ないし１７のいずれか１に記載のクライアントシステムと、該クライアントシステムにネットワークを介して接続し、該クライアントシステムに対してデータをダウンロードさせるサーバとを有することを特徴とする。

請求項２０の発明は、請求項１９に記載のデータ転送システムにおいて、前記サーバは、ダウンロード可能なデータのメッセージダイジェスト値をクライアントシステムのコンピュータから要求された場合、及び該データのダウンロードが該クライアントシステムのコンピュータから要求された場合に、該コンピュータが該データを取り扱ったものと認識して、前記メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することを特徴とする。

請求項２１の発明は、請求項１ないし１７のいずれか１に記載のクライアントシステム、請求項１８に記載のデータ配信サーバ、または請求項１９または２０に記載のデータ転送システムの機能を実現するためのプログラムである。

請求項２２の発明は、請求項２１に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体である。

本発明によれば、データのダウンロードを常にサーバから行うことなく、クライアントシステム内の他端末から適宜取得できるようにすることにより、ネットワーク品質の影響を受けずにクライアントシステムに合理的に同報通信を行うことができるようになる。

すなわち本発明では、クライアントシステムに含まれる各コンピュータがサーバからデータをダウンロードしようとする場合に、サーバに対してデータのダウンロード要求を送信する前にクライアントシステムに含まれる他のコンピュータに対して、ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信し、その問い合わせ情報に応じて他のコンピュータのいずれかがダウンロードしようとするデータを保持していることを示す応答を返信した場合、応答を返信したコンピュータからデータのダウンロードを行い、また他のコンピュータのいずれからもダウンロードしようとするデータを保持していることを示す応答が返信されなかった場合、サーバからデータをダウンロードすることにより、遠隔の離れたサーバからのダウンロードを避けて、クライアントシステム内の近隣のコンピュータから目的のデータを取得することができる。このため、サーバとクライアントシステムとの間のネットワークの伝送路が品質の悪い伝送路であっても、このような伝送路をできるだけ使用することなく、品質の良いクライアントシステム内のネットワークを利用してデータ転送を受けることができるようになる。

さらに本発明では、クライアントシステムの各コンピュータは、上記の問い合わせ情報の送信を行う前に、サーバに対してダウンロードしようとするデータ容量を問い合わせ、サーバから返信されたデータ容量の情報と、問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、データバッファの使用可能容量がサーバから返信されたデータ容量より小さいときは、データバッファの保存データを削除して使用可能容量を確保することにより、サーバからのデータのダウンロードを確実に信頼性をもって実行することができる。

また、このときに、ＬＲＵによって未使用の時間が最も長いデータから削除していくことにより、利用頻度の低いデータが削除され、これによってデータの再転送が増加することを避ける事ができる。
また、上記ＬＲＵに代えて、他のコンピュータが保持しているデータについて問い合わせ、その回答に基づいて、データを保持しているコンピュータ数が多いデータから優先して削除することにより、クライアントシステム内の複数のコンピュータがデータを重複して保持する状態を合理化することができ、複数のコンピュータが連携してより多くのデータをシステム内に保持することが可能となる。

また、上記の問い合わせ情報の送信をマルチキャスト通信で実行することにより、問い合わせを行う相手先のコンピュータを特定して制限し、また、マルチキャストパケットの配信範囲を制限することによって、コンピュータ間のデータ転送を行う範囲を制限することができるようになる。

また上記の問い合わせに対する応答を返信したコンピュータからデータのダウンロードを行う際、応答を返信したコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出するともに、サーバが配布しているダウンロードデータに該当するメッセージダイジェスト値を取得し、これらのメッセージダイジェスト値を比較して、これらメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にすることにより、他のコンピュータからダウンロードするデータが改竄あるいは修正されていることを知ることができ、改竄や修正のないデータを確実に取得することができるようになる。

また、クライアントシステムに含まれる各コンピュータは、サーバからプッシュ転送によりデータをダウンロードし、さらにこのプッシュ転送によりダウンロードしたデータを、クライアントシステムに含まれる他のコンピュータにプッシュ転送することにより、サーバからクライアントシステムまでの伝送路の帯域消費を抑制しつつ、サーバから離れた場所に配された複数のコンピュータにデータを配布することが可能となる。

さらに、他のコンピュータからプッシュ転送されたデータを、クライアントシステムに含まれる更に他のコンピュータにプッシュ転送することにより、クライアントシステム内の全てのコンピュータにサーバからプッシュ転送したデータを合理的に配布することが可能となる。

また上記サーバからダウンロードしたデータ、または他のコンピュータからダウンロードしたデータのプッシュ転送を、マルチキャスト通信により実行することにより、プッシュ転送を行う相手先のコンピュータを特定して制限し、また、マルチキャストパケットの配信範囲を制限することによって、コンピュータ間のデータ転送を行う範囲を制限することができるようになる。

また、クライアントシステムのコンピュータが、サーバからのプッシュ転送によるダウンロードまたは他のコンピュータからのプッシュ転送によるダウンロードを行うに際し、サーバに対してダウンロードしようとするデータ容量を問い合わせ、その問い合わせに応じてサーバから返信されたデータ容量の情報と、問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、そのデータバッファの使用可能容量がサーバから返信されたデータ容量より小さいときは、データバッファの保存データを削除して使用可能容量を確保することにより、サーバからのプッシュ転送によるデータのダウンロード、及び他のコンピュータからのプッシュ転送によるデータのダウンロードを確実に信頼性をもって実行することができる。

また、このときに、ＬＲＵによって未使用の時間が最も長いデータから削除していくことにより、利用頻度の低いデータが削除され、これによってデータの再転送が増加することを避けることができる。
また、上記ＬＲＵに代えて、他のコンピュータが保持しているデータについて問い合わせ、その回答に基づいて、データを保持しているコンピュータ数が多いデータから優先して削除することにより、クライアントシステム内の複数のコンピュータがデータを重複して保持する状態を合理化することができ、複数のコンピュータが連携してより多くのデータをシステム内に保持することが可能となる。

また、クライアントシステムに含まれる各コンピュータは、上記のプッシュ転送により他のコンピュータからデータのダウンロードを行う際、他のコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出するとともに、サーバが配布しているダウンロードデータに該当するメッセージダイジェスト値を取得し、これらメッセージダイジェスト値を比較した結果、比較したメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にすることにより、他のコンピュータからプッシュ転送によりダウンロードするデータが改竄あるいは修正されていることを知ることができ、改竄や修正のないデータを確実に取得することができるようになる。

また、クライアントシステムのコンピュータが、予め同一データを転送する転送回数を定めて保持し、プッシュ転送より他のコンピュータにデータを転送してダウンロードさせる場合に、データの転送回数を計量し、その転送回数が上記の予め定めた転送回数に達した場合にデータ転送を停止することにより、特定のコンピュータに転送負荷を集中させることなくクライアント内のコンピュータへのデータ転送を実行できるようになる。

また、クライアントシステムに含まれる各コンピュータは、コンピュータ自身からサーバ装置までのルートのトレースを行ってその結果を保持し、データ転送の問い合わせ先を選択するため、問い合わせ先の候補となる他のコンピュータに対して、そのコンピュータからサーバまでのルートのトレース結果を要求し、これに応答して得られた他のコンピュータのルートトレース結果と、上記コンピュータ自身のルートトレース結果とを比較して、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信することにより、ルートが似ている近隣のコンピュータ同士におけるデータ転送を優先して実行することができ、ネットワークリソースを節約することができる。

また、クライアントシステムに含まれる各コンピュータは、コンピュータ自身からサーバ装置までのルートのトレースを行ってその結果を保持し、プッシュ転送によるデータ転送先を選択するため、転送先の候補となる他のコンピュータに対して、そのコンピュータからサーバまでのルートのトレース結果を要求し、その要求に応答して得られた他のコンピュータのルートトレース結果と上記のコンピュータ自身のルートトレース結果とを比較して、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、プッシュ転送を実行することにより、ルートが似ている近隣のコンピュータ同士におけるデータ転送を優先して実行することができ、ネットワークリソースを節約することができる。

また、クライアントシステムに含まれるコンピュータ同士の通信をピアツーピアにより行うことにより、コンピュータ間のデータ転送を、送信量を増大させることなく最短経路で合理的に実行することができるようになる。

また、データ配信を行うサーバにおいて、データのメッセージダイジェスト値をクライアントから要求された場合、及びデータのダウンロードがクライアントから要求された場合に、そのクライアントが該当データを取り扱ったものと認識して、メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することにより、これら要求は各クライアントがデータを取得しようとした情報であるため、データの視聴情報として管理し適宜利用することができる。

また、上記のクライアントシステムと、そのクライアンシステムにネットワークを介して接続し、クライアントシステムに対してデータをダウンロードさせるサーバとを有することにより、サーバとクライアントシステムからなり、上述のごとくの各効果が得られるデータ転送システムを提供することができる。
ここで、データ転送システムのサーバは、ダウンロード可能なデータのメッセージダイジェスト値をクライアントシステムのコンピュータから要求された場合、及びデータのダウンロードがクライアントシステムのコンピュータから要求された場合に、コンピュータがそのデータを取り扱ったものと認識して、メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することにより、これら要求は各クライアントシステムのコンピュータがデータを取得しようとした情報であるため、データの視聴情報として管理し適宜利用することができる。

また、本発明により、上記のクライアントシステム、データ配信サーバ、またはデータ転送システムの機能を実現するためのコンピュータ読み取り可能なプログラム及び記録媒体を提供することができる。

図１は、本発明を適用可能なシステム構成例を示す図である。図１において、１０は大規模オフィス、１１は動画配信サーバ、１２はルータ、１３は大規模オフィス内部のネットワーク、２０は小規模オフィス、２１は端末、２２はルータ、２３は小規模オフィス内部のネットワーク、３０は大規模オフィス１０と小規模オフィス２０と接続するネットワークである。ここでは、大規模オフィス１０の内部には、動画配信サーバ１１が設置され、該サーバ１１が設置された大規模オフィス１０と小規模オフィス２０とがルータ１２，２２を介してネットワーク３０で接続されている。

本例では、大規模オフィス１０のネットワーク１３や、小規模オフィス２０のネットワーク２３は、１００ｂａｓｅ−Ｔや１０００ｂａｓｅ−Ｔなどの高速なＬＡＮ技術を使って構築されている。これに対して、大規模オフィスと小規模オフィスとの間を接続するネットワーク３０は、バンド幅が小さかったり、ＲＴＴが大きい回線を利用して接続されている。また、小規模オフィスの内部には、大規模オフィス内の動画配信サーバからデータ供給を受ける端末（I〜III）２１が存在する。各端末２１は、動画配信サーバ１１からのデータのダウンロードが可能なコンピュータであり、これらは小規模オフィス２０のネットワーク２３にて相互に接続されている。すなわち、上記小規模オフィス２０の複数の端末装置２１がネットワークで接続された構成が、本発明のクライアントシステムに該当し、動画配信サーバ１１が本発明のデータ配信サーバに該当し、これらを接続してなるシステムが本発明のデータ転送システムに該当する。

以下に示す各実施例は、上記のような動画配信サーバ１１を有する高品質ネットワーク（例えば、大規模オフィス１０）と、他の高品質ネットワーク（例えば、上記の小規模オフィス２０）とが、低品質のネットワーク３０で接続された構成を想定する。また、データ配信を行うサーバとして、ここでは動画配信サーバ１１を考えるが、本発明では動画を配信するサーバに限定されるものではなく、テキストベースや静止画像等の各種データを配信するサーバであってもよい。

（実施例１）
図２及び図３は、本発明の第１の実施例を説明するための図で、クライアントシステムの各端末が持っている機能と、動画配信サーバが持っている機能とをそれぞれ説明するための図である。本実施例によれば、小規模オフィス２０内で、動画配信サーバ１１からダウンロードしたデータをピアツーピア共有することによって、ネットワーク３０による細い回線の負荷を最小限にすることができるという効果が得られる。

図２において、小規模オフィス２０側の端末２１は、ユーザからのデータダウンロード要求に応じた処理機能２１１、他端末からデータ保持確認を受けたときに実行する処理機能２１２、及び他端末からデータ送信要求を受けたときに実行する処理機能２１３を実現可能で、またデータを保持するデータバッファ２１４を有している。

ユーザからのデータダウンロード要求に応じた処理機能２１１は、ダウンロードしようとしているデータを保持しているかどうかを他端末に問い合わせる問い合わせ送信手段２１１ａ、他端末がデータを保持している場合にその端末からデータのダウンロードを行う手段２１１ｂ、他端末でデータを保持してない場合に動画配信サーバからデータをダウンロードする手段２１１ｃ、動画配信サーバに対してダウンロードしようとするデータ容量を問い合わせる手段２１１ｄ、動画配信サーバに問い合わせたデータ容量と自端末のデータバッファ容量に応じてデータバッファ領域を確保する手段２１１ｅ、動画配信サーバまたは他端末からデータのダウンロードを行う際にダウンロードしたデータのメッセージダイジェスト値を算出する手段２１１ｆ、動画配信サーバからメッセージダイジェスト値を取得する手段２１１ｇ、取得したメッセージダイジェスト値とダウンロードしたデータのメッセージダイジェスト値を比較する手段２１１ｈ、メッセージダイジェスト値を比較した結果、一致しなければダウンロードを無効とする手段２１１ｉ、コンピュータ自身から動画配信サーバまでのルートのトレースを行う手段２１１ｊ、他のコンピュータに対して他のコンピュータから動画配信サーバまでのルートのトレースを行ってその結果を要求する手段２１１ｋ、得られたこれらのルートのトレースの結果を比較し、似ているルートをもつ他の端末を検出する手段２１１ｌ、を適宜実行することにより実現される。

また、図３において、大規模オフィス１０側の動画配信サーバ１１は、動画配信機能１１１、データの容量送信機能１１２、及びデータのメッセージダイジェスト値送信機能１１３を実現可能であり、さらに視聴履歴情報を保持する視聴情報１１４を有している。
なお、動画配信サーバ１１が提供しているデータ容量送信機能１１２や、データのメッセージダイジェスト値送信機能１１３については、別途サーバを用意して、そのサーバによりこれらの機能を提供しても良いものとする。

図４は、端末においてユーザからのデータダウンロード要求に応じた処理機能２１１を実現するときの処理の流れを説明するためのフローチャートである。端末がユーザからデータダウンロード要求を受けると（ステップＳ１）、端末は、データ容量の情報を動画配信サーバ（単にサーバとする）から取得する（ステップＳ２）。そして、取得した容量のデータが自身のバッファに入りきる量であるかどうか判断し（ステップＳ３）、入りきらなければエラー終了する。また自身のバッファに入るデータ容量であれば、さらに自身のバッファの残容量が、ダウンロードするデータ容量より大きいかどうかを判断する（ステップＳ４）。

ここで、バッファに充分な残容量がなかった場合は、既存のデータを削除する。この時の削除順序はＬＲＵ（Least Recently Used）として、最近もっとも参照していないデータから削除するものとする（ステップＳ１５）。

バッファの残容量が充分であった場合、端末は、ユーザから要求されたデータをすぐにサーバから取得しようとはせず、マルチキャスト通信を使って自身と同じく端末であるホスト（他端末）に対してそのデータを持っているかどうかを確認する。すなわち、専用マルチキャストアドレスに向けて、他端末のバッファ内に、ダウンロードしようとしている該当データを保持していないかどうか問い合わせる（ステップＳ５）。

これに対する応答が他端末から得られなかった場合は、タイムアウトを待って、近隣の端末には該当データが保持されていないものと見なして、サーバからデータをダウンロードして取得する（ステップＳ６，Ｓ１６，Ｓ１７）。このときにエラーが発生すれば、エラー終了し、エラーがなければ、自端末は、ダウンロードしたデータを自身のバッファに保存して、再生する（ステップＳ１８，Ｓ１９）。
また、ステップＳ６で、近隣の端末から該当データを保持している旨の通知を受けた場合は、その端末からデータをダウンロードする。

ここでは、まず応答があった端末に対して、ローカルでダウンロードすることを要求し（ステップＳ７）、その端末からピアツーピア（Ｐ２Ｐ）で該当データを受信する（ステップＳ８）。エラーがあった場合は、ダウンロードした端末からの応答を無効として（ステップＳ２０）、ステップＳ５に戻り、エラーがなければ、ダウンロードしたデータをメッセージダイジェスト関数で演算して、ダイジェスト値を得る（ステップＳ１０）。

さらに、端末は、ダウンロードデータのサーバ上のダイジェスト値を該サーバに対して質問し（ステップＳ１１）、サーバから得られたダイジェスト値と、自身で演算したダイジェスト値とを比較する（ステップＳ１２）。比較結果が一致すれば、その端末は、得られたデータを自身のバッファに保存し、再生する（ステップＳ１４）。また比較結果が一致しなければ、ダウンロードした端末からの応答を無効とし（ステップＳ２０）、ステップＳ５に戻る。

上記の場合、端末からダウンロードしたデータは、途中でデータが改竄や修正が施されている可能性があるため、ダウンロード後に、データのメッセージダイジェスト値を演算し、さらに動画配信サーバからもメッセージダイジェスト値を取得し、その両者を比較して、同一のメッセージダイジェスト値が得られれば、改竄や修正はなかったものと見なして、データを自身でバッファリングする。

図５は、端末において他端末からデータ保持確認を受けたときに実行する処理機能２１２を実現するときの処理の流れについて説明するためのフローチャートである。
端末は、他端末からマルチキャストによって、特定のファイルを保持しているかどうかの確認要求が到着することがある。自分がそのファイルを保持している場合、送信元の端末に対して、ユニキャストによってその旨を通知する。

ここでは、まず、ネットワーク上の他端末から、データをバッファに保持しているかどうかの問い合わせをマルチキャストで受け取る（ステップＳ３１）。
そして自身のバッファ内にデータを保持しているかどうかを判断し（ステップＳ３２）、保持していれば、要求されたデータがバッファ内にあることを返答する（ステップＳ３３）。なお、このときの返答はユニキャスト通信で行う。また自身のバッファ内にデータが保持されていなければ、問い合わせ元の端末に対して何も返答しないものとする（ステップＳ３４）。

図６は、端末において他端末からデータ送信要求を受けたときに実行する処理機能２１３を実現するときの処理の流れについて説明するためのフローチャートである。
端末は、自身のデータバッファ内に保持しているデータの転送を要求された場合、そのデータを転送する機能を持つ。ここでは、まずネットワーク上の他端末からデータのダウンロードが要求されると（ステップＳ４１）、そのデータを自身のバッファ内に保持しているかどうかを判別し（ステップＳ４２）、データを保持していれば、バッファ内のデータを、要求した端末に送信し（ステップＳ４３）、データを保持していなければ、その要求元の端末に対してエラーを返して終了する（ステップＳ４４）。

図７は、動画配信サーバにおいてデータのメッセージダイジェスト値送信機能１１３を実現するときの処理の流れについて説明するためのフローチャートである。端末からデータのメッセージダイジェスト値が要求されると（ステップＳ５１）、視聴情報１１４に、使用が実施されたことを記載する（ステップＳ５２）。そして指定されたデータのメッセージダイジェスト値を、要求された端末に送信する（ステップＳ５３）。視聴情報１１４はデータの視聴履歴を保持するもので、ここでは、メッセージダイジェスト値が要求された時点で、そのデータが端末で視聴されたものとみなして視聴情報として保存する。

図８は、動画配信サーバにおいてデータの容量送信機能１１２を実現する処理の流れについて説明するためのフローチャートである。まず、端末からデータの容量が要求されると（ステップＳ６１）、指定されたデータの容量を、要求された端末に送信する（ステップＳ６２）。

図９は、動画配信サーバにおいて動画配信機能１１１を実現する処理の流れについて説明するためフローチャートである。動画配信する際は、視聴情報１１４に視聴が実施されたことを記載し（ステップＳ７１）、その後動画を配信する（ステップＳ７２）。

上記のように、動画配信サーバは、動画を配信する際や、メッセージダイジェスト値を端末（クライアント）が要求してきたときに、その端末情報を視聴情報として内部に蓄積する。そしてその後、動画を配信したり、メッセージダイジェスト値を端末に送信したりする。

（実施例２）
本実施例では、動画配信サーバから端末に対してデータを能動的に転送する処理を実現する。図１０及び図１１は、本発明の第２の実施例を説明するための図で、各端末が持っている機能と、動画配信サーバが持っている機能とをそれぞれ説明するための図である。
図１０において、端末２１は、図２に示す機能に加えて、サーバからのデータプッシュを受け付ける機能２１５、及び他端末からのデータプッシュを受け付ける機能２１６を有している。
動画配信サーバからのデータプッシュを受け付ける機能２１５は、動画配信サーバからのプッシュ転送によりデータダウンロードを実行する手段２１５ａ、動画配信サーバからダウンロードしたデータを他端末にプッシュ転送する手段２１６ｂ、動画配信サーバにデータ容量を問い合わせるデータ容量問い合わせ手段２１５ｃ、データバッファの容量を確保するデータバッファ領域確保手段２１５ｄ、データを転送する転送回数（規定値）を保持する手段２１５ｅ、回転回数が予め定めた転送回数に達した場合にデータ転送を停止する手段２１５ｆ、自端末から動画配信サーバまでのルートトレースを行う手段２１５ｇ、他端末に動画配信サーバまでのルートのトレースの結果を要求する手段２１５ｈ、得られた各ルートのトレース結果を比較し、似ているルートをもつ他端末を検出するルートトレース比較検出手段２１５ｉ、を適宜実行することにより、実現される。

また、他端末からのデータプッシュを受け付ける機能２１６は、他端末からのプッシュ転送によるデータダウンロードを実行する手段２１６ａ、他端末からダウンロードしたデータを更に他の端末にプッシュ転送する手段２１６ｂ、動画配信サーバにデータ容量を問い合わせるデータ容量問い合わせ手段２１６ｃ、データバッファの容量を確保するデータバッファ領域確保手段２１６ｄ、他端末からデータのダウンロードを行う際にダウンロードしたデータのメッセージダイジェスト値を算出する手段２１６ｅ、動画配信サーバからメッセージダイジェスト値を取得する手段２１６ｆ、取得したメッセージダイジェスト値とダウンロードしたデータのメッセージダイジェスト値を比較する手段２１６ｇ、メッセージダイジェスト値を比較した結果、一致しなければダウンロードを無効とする手段２１６ｈ、データを転送する転送回数（規定値）を保持する手段２１６ｉ、回転回数が予め定めた転送回数に達した場合にデータ転送を停止する手段２１６ｊ、自端末から動画配信サーバまでのルートのトレースを行う手段２１６ｋ、他端末に動画配信サーバまでのルートのトレース結果を要求する手段２１６ｌ、得られた各ルートのトレース結果を比較し、似ているルーとをもつ他端末を検出するルートトレース比較検出手段２１６ｍ、を適宜実行することにより、実現される。
また、図１１において、動画配信サーバ１１は、図３に示す機能に加えて、プッシュによる動画配信機能１１５を有している。

図１２は、動画配信サーバにおいてプッシュによる動画配信機能１１５を実現する処理の流れを説明するためのフローチャートである。動画配信サーバ（単にサーバとする）が、端末に対してデータを送信する際、まずサーバから端末に対してデータプッシュを要求し（ステップＳ８１）、続けてデータ容量を送信する（ステップＳ８２）。そして、端末からの送信許可を示すＡＣＫ信号がサーバで受け付けられると（ステップＳ８３）、その端末に対してデータを送信する（ステップＳ８４）。以降は、端末のマルチキャスト通信範囲内で自動的にデータが送信されることになる。

図１３は、端末において動画配信サーバからのデータプッシュを受け付ける機能２１５を実現する処理の流れを説明するためのフローチャートである。端末が動画配信サーバ（単にサーバとする）からのデータプッシュ要求を受信すると（ステップＳ９１）、端末は、続いてサーバからデータ容量の情報を取得する（ステップＳ９２）。そして、取得した容量のデータが自身のバッファに入りきる量であるかどうか判断し（ステップＳ９３）、入りきらなければサーバにエラーを通知する（ステップＳ１０２）。また自身のバッファに入るデータ容量であれば、さらに自身のバッファの残容量が、ダウンロードするデータ容量より大きいかどうかを判断する（ステップＳ９４）。ここで、バッファに充分な残容量がなかった場合は、既存のデータを削除する。この時の削除順序はＬＲＵとして、最近もっとも参照していないデータから削除するものとする（ステップＳ１０３）。

バッファの残容量が充分であった場合、端末は、サーバからデータを受信し（ステップＳ９５）、自身のバッファに保存する。そしてマルチキャスト通信を使い、専用マルチキャストアドレスに向けて、プッシュによるデータ転送があることを通知する（ステップＳ９６）。これにより、サーバから受信したデータの転送を受けていない端末を探索する。

端末は、上記の通知に対する応答を待ち（ステップＳ９７）、応答が得られずにタイムアウトになった場合は（ステップＳ９８）、終了する。また、他端末からの応答があり、プッシュによるデータ転送を行うべき他端末が発見された場合、その発見された端末に対してデータ転送を行う（ステップＳ９９）。そして、他端末への転送を行う毎に転送回数をインクリメントしていき（ステップＳ１００）、転送回数が予め定めた規定回数に達したかどうかを判別し（ステップＳ１０１）、転送回数が規定回数に達した時点で処理を終了する。また、規定回数に達していなければ、ステップＳ９６に戻る。

図１４は、端末において他端末からデータプッシュを受け付ける機能２１６を実現する処理の流れについて説明するためのフローチャートである。端末が他端末からのデータプッシュ要求を受信すると（ステップＳ１１１）、端末は、続いてデータ容量の情報を動画配信サーバ（単にサーバとする）から取得する（ステップＳ１１２）。そして、取得した容量のデータが自身のバッファに入りきる量であるかどうか判断し（ステップＳ１１３）、入りきらなければ動画配信サーバにエラーを通知する（ステップＳ１２６）。また自身のバッファに入るデータ容量であれば、さらに自身のバッファの残容量が、ダウンロードするデータ容量より大きいかどうかを判断する（ステップＳ１１４）。ここで、バッファに充分な残容量がなかった場合は、既存のデータを削除する。この時の削除順序はＬＲＵとして、最近もっとも参照していないデータから削除するものとする（ステップＳ１２７）。

バッファの残容量が充分であった場合、端末は、他端末からデータを受信し（ステップＳ１１５）、自身のバッファに保存する。そして受信したデータをメッセージダイジェスト関数で演算して、メッセージダイジェスト値を得る（ステップＳ１１６）。さらにその端末は、受信データのサーバ上のメッセージダイジェスト値を該サーバに対して質問し（ステップＳ１１７）、サーバから得られたメッセージダイジェスト値と、自身で演算したメッセージダイジェスト値とを比較する（ステップＳ１１８）。比較結果が一致すれば、その端末は、そしてマルチキャスト通信を使い、専用マルチキャストアドレスに向けて、プッシュによるデータ転送があることを通知する（ステップＳ１１９，Ｓ１２０）。これにより、サーバから受信したデータの転送を受けていない端末を探索する。また、比較結果が一致しなければ、エラー終了する。

端末は、上記の通知に対する応答を待ち（ステップＳ１２１）、応答が得られずにタイムアウトになった場合は（ステップＳ１２２）、処理を終了する。また、他端末からの応答があり、プッシュによるデータ転送を行うべき他端末が発見された場合、その発見された端末に対してデータ転送を行う（ステップＳ１２３）。そして、他端末への転送を行う毎に転送回数をインクリメントしていき（ステップＳ１２４）、転送回数が予め定めた規定回数に達したかどうかを判別し（ステップＳ１２５）、転送回数が規定回数に達した時点で処理を終了する。また、規定回数に達していなければ、ステップＳ１２０に戻る。

以上の手順によって、データをプッシュ形式によって転送する。なお、ネットワーク障害など、プッシュによるデータ転送を受けられなかった端末についても、データを参照しようとした際に、実施例１と同じ手法でマルチキャストの送信範囲内のホストからデータの転送を受けることができる。

（実施例３）
本実施例は、データをデータバッファ内に効率的に保持する手段を有するものである。同一のマルチキャスト範囲内で重複するデータを保持すると、クライアントシステム全体としてのデータ保持量が少なくなる。この問題を解決するために、クライアントシステムのネットワーク内で多数の端末が保持しているデータを優先的に削除する。

図１５は、本発明の第３の実施例を説明するための図で、各端末が持っている機能を説明するための図である。端末２１は、従来のデータバッファ２１４の他に、データ削除順序リスト２１７を保持し、さらにデータの削除を行う機能２１８、保持データ一覧要求を受けたときの処理機能２１９、データ削除順序リストを整理する機能２２０を有している。

上記各実施例のデータ削除処理では、ＬＲＵによって削除を行っていたが、本実施例では、端末２１がデータ削除要求を受けたときに、データ削除順序リスト２１７の先頭にあるデータを削除し、その後データ削除順序リスト２１７の先頭の項目を削除する。

図１６は、端末においてデータの削除を行う機能２１８について説明するためのフローチャートである。まず、端末がデータ削除命令を受け付けると（ステップＳ１３１）、データ削除順序リストの先頭のデータをデータバッファから削除する（ステップＳ１３２）。そして、データ削除順序リストの先頭にある項目を削除する（ステップＳ１３３）。

図１７は、端末においてデータ削除順序リストを整理する機能２２０を実現する処理について説明するためのフローチャートである。データ削除順序リストを整理する処理では、データ削除順序リストを生成するために、マルチキャスト通信により、周囲の各端末が保持しているデータを送信するよう要求する。ここでは、まず、専用マルチキャストアドレスに向けて各端末が保持しているデータ一覧を要求する（ステップＳ１４１）。そして、他端末からの応答を待ち（ステップＳ１４２）、他端末からの応答があった場合は、各データ毎の保持端末数をカウントし（ステップＳ１４５）、さらにステップＳ１４２で他端末の応答を待つ。そしてタイムアウトになるまで応答がなければ（ステップＳ１４３）、データ保持端末数が多い順にデータ削除順序リストを並べ替える（ステップＳ１４４）。上記のデータ削除順序リストの整理処理は、一定期間毎に行うか、あるいはデータの削除要求があったときに実施するものとする。

各端末は、上記の一覧要求のマルチキャストに応じて、自身が保持しているデータを送信する機能を有する。図１８は、端末において保持データ一覧要求を受けたときの処理機能２１９を実現する処理の流れについて説明するためのフローチャートである。端末は、ネットワーク上の他端末から、自身が保持しているデータの一覧を要求されると（ステップＳ１５１）、これに応じて自身が保持しているデータの一覧を送信する（ステップＳ１５２）。

以上の処理によって、多数の端末が保持しているデータから順に削除することができる。図１９は、データ削除順序リスト２１７の整理の様子を説明するための図である。
図１９（Ａ）は、ある端末のデータバッファの一例を示すもので、ここでは、データＡとデータＤとが保持されている。このとき、データ削除順序リストの整理が要求されたものとする。これに応じて、その端末は、マルチキャストによって周囲の端末が保持しているデータの一覧を要求する。データ一覧を要求された他端末は、その要求に応じて自身が保持しているデータの一覧を送信してくる。この結果、データ削除順序リストの整理が要求された端末では、データ毎に、そのデータを保持している周囲の端末数が得られる。
図１９（Ｂ）は、データの保持端末数の集計結果を示す図で、ここでは、データＡは４端末で保持され、データＢは２端末で保持され、データＣを保持する端末はなく、さらにデータＤは５端末で保持されていることがわかる。

そして、データを保持している端末数が多い順に、端末自身が保持しているデータの削除順序リストを更新する。図１９（Ｃ）は、得られたデータ削除順序リストを示す図で、ここでは、削除順序Ｄ―Ａという結果が得られる。
以降、この端末でデータ削除が必要となった場合、最初にデータＤを削除し、次にデータＡを削除することになる。

（実施例４）
本実施例は、より効率的なデータダウンロードを行うことができるようにするものである。ピアツーピアによる通信を離れた端末同士で行うと、ネットワークリソースを消費するため効率的ではない。マルチキャストによって応答のあったホストについて、ネットワーク的に自端末に近い他端末と優先的にピアツーピア通信するようにできれば、ピアツーピア通信が効率化する。

本実施例では、ネットワーク上の距離順に、ピアツーピア通信先を並べる処理を行う。図２０は、本発明の第４の実施例を説明するための図で、各端末が持っている機能を説明するための図である。端末装置は、従来のデータバッファの他に、ピアツーピア通信先順序リスト２２１を保持し、さらにピアツーピア通信先順序リストの整理処理機能２２２、サーバへのルートのトレース結果要求に応じた処理機能２２３を有している。

図２１は、ピアツーピア送信先順序リストの整理処理機能２２２を実現するための処理の流れを説明するためのフローチャートである。まず、ピアツーピア通信先順序リスト（以下単に順序リストとする）を生成しようとする端末は、自端末から動画配信サーバ（単にサーバとする）に向けてルートのトレース（e.ｇ．traceroute）を行い、その結果を保持する（ステップＳ１６１）。次に、順序リストを生成しようとする端末は、マルチキャストによって、専用マルチキャストアドレスに向けて、サーバへのルートのトレース結果を送信するよう要求する（ステップＳ１６２）。

そして、ルートのトレース結果の要求に対する応答を待ち（ステップＳ１６３）、応答があればそのルートのトレース結果を保持する（ステップＳ１６６）。応答がなくなり、タイムアウトになれば（ステップＳ１６４）、自端末のルートのトレース結果に近いトレース結果を返してきたホストを順序リストに記載する（ステップＳ１６５）。

図２２は、サーバへのルートのトレース結果要求に応じた処理機能２２３を実現する処理の流れを説明するためのフローチャートである。まず、動画配信サーバ（単にサーバとする）へのルートのトレース結果をネットワーク上の他端末から要求されると（ステップＳ１７１）、指定されたサーバに対してルートのトレースを行う（ステップＳ１７２）。そして、得られたルートのトレースの結果を、要求された他端末に対して送信する（ステップＳ１７３）。

図２３は、ルートのトレース結果に応じたピアツーピア通信先順序リスト２２１の生成例を説明する図である。上記のような処理において、例えば、自端末におけるルートのトレース結果が、図２３（Ａ）に示すように、「自端末→Ｘ→Ｙ→Ｚ→サーバ」という経路であったとする。
そして、マルチキャストによって他端末のルートのトレース結果を要求した結果、例えば、図２３（Ｂ）のように、端末Ａ〜端末Ｄの４台が応答し、それぞれのルートのトレース結果が得られたものとする。得られた他端末のルートのトレース結果のうち、順序リストを生成しようとする自端末のトレース結果に最も近いものが、「端末Ｂ」の「Ｂ→Ｘ→Ｙ→Ｚ→サーバ」である。そして次に近いのが、端末ＡおよびＣの「Ａ／Ｃ→Ｏ→Ｙ→Ｚ→サーバ」である。また、最もトレース結果が異なるものが、端末Ｄの「Ｄ→Ｈ→Ｉ→Ｊ→サーバ」である。
上記の結果から、図２３（Ｃ）に示すピアツーピア通信先端末順序リストを生成する。ここでは、他端末からのルートのトレース結果と自端末のトレース結果とを比較し、自端末のトレース結果に似ている順に、端末を並べることでリストを作成する。図２３（Ｃ）の場合は、端末Ｂ，端末Ａ，端末Ｃ，端末Ｄの順になる。

上記の処理により得られたピアツーピア通信先端末順序リストを用いて、ネットワーク的に自端末に近い端末と優先的にピアツーピア通信を行うようにする。これにより、ピアツーピア通信が効率化し、資源を効率良く使用することができるようになる。

以上の本発明に係わる実施例において、各手段が動画配信サーバ１１や端末２１としての情報処理装置に備えられている形態を説明している。図２４は、一般的な情報処理装置の構成例を示すブロック図で、図中、４１は入力装置、４２は表示装置、４３は出力装置、４４はＣＰＵ、４５はＲＯＭ、４６はＲＡＭ、４７はバスである。

情報処理装置としては汎用コンピュータが挙げられ、各種情報を入力するためのキーボード，マウス，記録媒体読取装置，他の機器からの入力用のネットワーク機器などの入力装置４１、検索結果やその他の情報を表示するためのＣＲＴ，ＬＣＤなどのディスプレイである表示装置４２、印刷装置，記録媒体用記録装置，ネットワーク接続装置（ネットワークに接続して通信を行うためのネットワークボード等の通信機器であり）などの出力装置４３、さらには、プログラムを記録したハードディスクやＲＯＭ４５、そこに格納されたプログラムを実行するためのＣＰＵ４４、及びその実行領域としてのＲＡＭ４６をその主要な構成要素とし、それらがバス４７により接続されているものとして例示している。

動画配信サーバ１１に搭載される場合のプログラムは、上述する実施例の各手段（或いは各手段の一部）の機能を実現するようにコンピュータのＣＰＵ４４等を制御するプログラム（コンピュータを機能させるプログラム）である。同様に、端末２１に搭載される場合のプログラムは、上述する端末２１が動画配信サーバ１１及び他端末２１にアクセス可能とし、且つ各種情報を入力・送信して上記実施例の機能を実現するように、コンピュータのＣＰＵ等を制御するプログラムである。これらのプログラムは、装置ユーザが使用する際に容易となるように、表示装置４２用のグラフィカルユーザインターフェース（ＧＵＩ）を備えるようにするとよい。そして、これら装置で取り扱われる情報は、その処理時に一時的にＲＡＭ４６に蓄積され、その後、各種ＲＯＭ４５やハードディスクに格納され、必要に応じて、ＣＰＵ４４によって読み出し、修正・書き込みが行われる。

これら上述した機能を実現するプログラムは、予め例えば、ＣＤ−ＲＯＭ等の記録媒体に記憶しておき、コンピュータ等に搭載したＣＤ-ＲＯＭドライブのような媒体駆動装置に当該記録媒体を装着して、これらのプログラムをコンピュータのメモリあるいは記録装置に格納し、それを実行することにより、本発明の機能を実現することができる。この場合、記録媒体から読み出されたプログラム自体が上述した実施例の機能を実現することになり、そのプログラム及びプログラムを記録した記録媒体も本発明を構成する。

なお、プログラムを格納する記録媒体としては、半導体媒体（例えば、ＲＯＭ，不揮発性メモリカード等）、光記録媒体（例えば、ＤＶＤ，ＭＯ，ＭＤ，ＣＤ等）、磁気記録媒体（例えば、磁気テープ，フレキシブルディスク等）等のいずれであってもよい。

また、ロードしたプログラムを実行することにより、上述した実施例の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、上述した実施例の機能が実現される場合もある。

市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送することができる。この場合、サーバコンピュータの記憶装置も本発明の記録媒体に含まれる。
なお、コンピュータでは、可搬型の記録媒体上のプログラム、または転送されてくるプログラムを、コンピュータに接続した記録媒体にインストールし、そのインストールされたプログラムを実行することによって上述した実施例の機能が実現される。

本発明を適用可能なシステム構成例を示す図である。 本発明の第１の実施例を説明するための図で、各端末が持っている機能を説明するための図である。 本発明の第１の実施例を説明するための図で、動画配信サーバが持っている機能を説明するための図である。 端末においてユーザからのデータダウンロード要求に応じた処理機能を実現するときの処理の流れを説明するためのフローチャートである。 端末において他端末からデータ保持確認を受けたときに実行する処理機能を実現するときの処理の流れについて説明するためのフローチャートである。 端末において他端末からデータ送信要求を受けたときに実行する処理機能を実現するときの処理の流れについて説明するためのフローチャートである。 動画配信サーバにおいてデータのメッセージダイジェスト値送信機能を実現するときの処理の流れについて説明するためのフローチャートである。 動画配信サーバにおいてデータの容量送信機能を実現する処理の流れについて説明するためのフローチャートである。 動画配信サーバにおいて動画配信機能を実現する処理の流れについて説明するためフローチャートである。 本発明の第２の実施例を説明するための図で、各端末が持っている機能を説明するための図である。 本発明の第２の実施例を説明するための図で、動画配信サーバが持っている機能を説明するための図である。 動画配信サーバにおいてプッシュによる動画配信機能を実現する処理の流れを説明するためのフローチャートである。 端末において動画配信サーバからのデータプッシュを受け付ける機能を実現する処理の流れを説明するためのフローチャートである。 端末において他端末からデータプッシュを受け付ける機能を実現する処理の流れについて説明するためのフローチャートである。 本発明の第３の実施例を説明するための図で、各端末が持っている機能を説明するための図である。 端末においてデータの削除を行う機能について説明するためのフローチャートである。 端末においてデータ削除順序リストを整理する機能を実現する処理について説明するためのフローチャートである。 端末において保持データ一覧要求を受けたときの処理機能を実現する処理の流れについて説明するためのフローチャートである データ削除順序リストの整理の様子を説明するための図である。 本発明の第４の実施例を説明するための図で、各端末が持っている機能を説明するための図である。 ピアツーピア送信先順序リストの整理処理機能を実現するための処理の流れを説明するためのフローチャートである。 サーバへのルートのトレース結果要求に応じた処理機能を実現する処理の流れを説明するためのフローチャートである。 自端末におけるルートのトレース結果一例を示す図である。 一般的な情報処理装置の構成例を示すブロック図である。 企業等の大規模オフィスと小規模オフィスとを接続するネットワークについて説明するための図である。 大規模オフィスと小規模オフィスとのデータ転送を円滑に行うための従来の手法について説明するための図である。

符号の説明

１０…大規模オフィス、１１…動画配信サーバ、１２…ルータ、１３…大規模オフィス内部のネットワーク、２０…小規模オフィス、２１…端末、２２…ルータ、２３…小規模オフィス内部のネットワーク、２４…代理サーバ、３０…大規模オフィスと小規模オフィスと接続するネットワーク、４１…入力装置、４２…表示装置、４３…出力装置、４４…ＣＰＵ、４５…ＲＯＭ、４６…ＲＡＭ、４７…バス、１１１…動画配信機能、１１２…データの容量送信機能、１１３…データのメッセージダイジェスト値送信機能、１１４…視聴情報、１１５…プッシュによる動画配信機能、２１１…ユーザからのデータダウンロード要求に応じた処理機能、２１２…他端末からデータ保持確認を受けたときに実行する処理機能、２１３…他端末からデータ送信要求を受けたときに実行する処理機能、２１４…データバッファ、２１５…サーバからのデータプッシュを受け付ける機能、２１６…他端末からのデータプッシュを受け付ける機能、２１７…データ削除順序リスト、２１８…データの削除を行う機能、２１９…保持データ一覧要求を受けたときの処理機能、２２０…データの削除順序リストを整理する機能、２２１…ピアツーピア通信先順序リスト、２２２…通信先順序リスト整理処理機能、２２３…サーバへのルートのトレース結果要求に応じた処理機能。

Claims (22)

1. サーバとの間でネットワークを介して接続され、該サーバからのデータのダウンロードを可能とする複数のコンピュータよりなり、該複数のコンピュータが相互に接続されてなるクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記サーバからデータをダウンロードしようとする場合に、前記サーバに対してデータのダウンロード要求を送信する前に該クライアントシステムに含まれる他のコンピュータに対して、前記ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信する問い合わせ送信手段と、前記問い合わせ情報に応じて前記他のコンピュータのいずれかが前記ダウンロードしようとするデータを保持していることを示す応答を返信した場合、該応答を返信したコンピュータからデータのダウンロードを行う手段と、前記他のコンピュータのいずれからも前記ダウンロードしようとするデータを保持していることを示す応答が返信されなかった場合、前記サーバから前記データをダウンロードする手段とを有することを特徴とするクライアントシステム。
2. 請求項１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記問い合わせ送信手段による問い合わせ情報の送信を行う前に、前記サーバに対して前記ダウンロードしようとするデータ容量を問い合わせるデータ容量問い合わせ手段と、該データ容量の問い合わせに応じて前記サーバから返信されたデータ容量の情報と、前記問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、該データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記データバッファの保存データを削除して使用可能容量を確保するデータバッファ確保手段を有し、前記データバッファ確保手段によりデータバッファ容量を確保した上で、前記他のコンピュータまたは前記サーバからデータのダウンロードを行うことを特徴とするクライアントシステム。
3. 請求項１または２に記載のクライアントシステムにおいて、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、ＬＲＵによって未使用の時間が最も長いデータから削除していくことを特徴とするクライアントシステム。
4. 請求項１ないし４のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、他のコンピュータに対して、該他のコンピュータが保持しているデータについて問い合わせる手段を有し、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記保持しているデータの問い合わせに対する他のコンピュータからの回答に基づいて、保持しているコンピュータ数が多いデータから優先して削除することを特徴とするクライアントシステム。
5. 請求項１ないし４のいずれか１に記載のクライアントシステムにおいて、前記問い合わせ情報送信手段は、マルチキャスト通信により、複数の他のコンピュータに対して問い合わせ情報を送信することを特徴とするクライアントシステム。
6. 請求項１ないし５のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記問い合わせに対する応答を返信したコンピュータからデータのダウンロードを行う際、前記応答を返信したコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出する手段と、前記サーバに対して、該サーバが配布している前記ダウンロードデータに該当するメッセージダイジェスト値を取得する手段と、前記ダウンロードしたデータから算出したメッセージダイジェスト値と前記サーバから取得したメッセージダイジェスト値を比較する手段と、該メッセージダイジェスト値を比較した結果、該比較したメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にする手段とを有することを特徴とするクライアントシステム。
7. サーバとの間でネットワークを介して接続され、該サーバからのデータのダウンロードを可能とする複数のコンピュータよりなり、該複数のコンピュータが相互に接続されてなるクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記サーバから前記クライアントシステムのコンピュータに対するプッシュ転送によりデータをダウンロードする手段と、該プッシュ転送によりダウンロードしたデータを、前記クライアントシステムに含まれる他のコンピュータにプッシュ転送する手段とを有することを特徴とするクライアントシステム。
8. 請求項７に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、他のコンピュータから前記プッシュ転送されたデータをダウンロードする手段と、該他のコンピュータからプッシュ転送によりダウンロードしたデータを、前記クライアントシステムに含まれる更に他のコンピュータにプッシュ転送する手段とを有することを特徴とするクライアントシステム。
9. 請求項７または８に記載のクライアントシステムにおいて、前記サーバからダウンロードしたデータ、または前記他のコンピュータからダウンロードしたデータを前記プッシュ転送する手段は、マルチキャスト通信により、複数の他のコンピュータに対してプッシュ転送を行うことを通知することを特徴とするクライアントシステム。
10. 請求項７ないし９のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、前記サーバからのプッシュ転送によるダウンロードを行うに際し、または前記他のコンピュータからのプッシュ転送によるダウンロードを行うに際し、前記サーバに対して前記ダウンロードしようとするデータ容量を問い合わせるデータ容量問い合わせ手段と、該データ容量の問い合わせに応じて前記サーバから返信されたデータ容量の情報と、前記問い合わせを行ったコンピュータ自身が有するデータバッファの使用可能容量とを比較し、該データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記データバッファの保存データを削除して使用可能容量を確保するデータバッファ確保手段を有し、該データバッファ確保手段によりデータバッファ容量を確保した上で、前記サーバまたは前記他のコンピュータからデータのダウンロードを行うことを特徴とするクライアントシステム。
11. 請求項１０に記載のクライアントシステムにおいて、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、ＬＲＵによって未使用の時間が最も長いデータから削除していくことを特徴とするクライアントシステム。
12. 請求項１０に記載のクライアントシステムにおいて、前記クライアントシステムに含まれる各コンピュータは、他のコンピュータに対して、該他のコンピュータが保持しているデータについて問い合わせる手段を有し、前記データバッファ確保手段は、前記データバッファの使用可能容量が前記サーバから返信されたデータ容量より小さいときは、前記保持しているデータの問い合わせに対する他のコンピュータからの回答に基づいて、保持しているコンピュータ数が多いデータから優先して削除することを特徴とするクライアントシステム。
13. 請求項７ないし１２のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、前記プッシュ転送により他のコンピュータからデータのダウンロードを行う際、前記他のコンピュータからダウンロードしたデータのメッセージダイジェスト値を算出する手段と、前記サーバに対して、該サーバが配布している前記ダウンロードデータに該当するメッセージダイジェスト値を取得する手段と、前記他のコンピュータからダウンロードしたデータから算出したメッセージダイジェスト値と前記サーバから取得したメッセージダイジェスト値を比較する手段と、該メッセージダイジェスト値を比較した結果、該比較したメッセージダイジェスト値が互いに一致していなければ、ダウンロードしたデータを無効にする手段とを有することを特徴とするクライアントシステム。
14. 請求項７ないし１３のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムが含まれる各コンピュータは、予め同一データを転送する転送回数を定めて保持する手段と、前記プッシュ転送より他のコンピュータにデータを転送してダウンロードさせる場合に、データの転送回数を計数し、該転送回数が前記予め定めた転送回数に達した場合に前記データ転送を停止する手段とを有することを特徴とするクライアントシステム。
15. 請求項１ないし６のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、コンピュータ自身から前記サーバ装置までのルートのトレースを行ってその結果を保持するルートトレース手段と、前記問い合わせ送信手段による問い合わせ先を選択するため、問い合わせ先の候補となる他のコンピュータに対して、該他のコンピュータから前記サーバまでのルートのトレース結果を要求するルートトレース結果要求手段と、該ルートトレース要求手段の要求に応答して得られた前記他のコンピュータのルートトレース結果と前記コンピュータ自身のルートトレース結果とを比較して、コンピュータ自身のルートトレース結果に似ている他のコンピュータを検出するルートトレース比較検出手段とを有し、前記問い合わせ送信手段は、前記ルートトレース比較検出手段の検出結果に従って、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、前記ダウンロードしようとするデータを保持しているかどうかの問い合わせ情報を送信することを特徴とするクライアントシステム。
16. 請求項７ないし１４のいずれか１に記載のクライアントシステムにおいて、該クライアントシステムに含まれる各コンピュータは、コンピュータ自身から前記サーバ装置までのルートのトレースを行ってその結果を保持するルートトレース手段と、前記プッシュ転送によるデータ転送先を選択するため、転送先の候補となる他のコンピュータに対して、該他のコンピュータから前記サーバまでのルートのトレース結果を要求するルートトレース結果要求手段と、該ルートトレース結果要求手段の要求に応答して得られた前記他のコンピュータのルートトレース結果と前記コンピュータ自身のルートとレース結果とを比較して、コンピュータ自身のルートトレース結果に似ている他のコンピュータを検出するルートトレース比較検出手段とを有し、前記プッシュ転送により他のコンピュータにデータを転送してダウンロードさせる場合、コンピュータ自身のルートトレース結果に似ているルートトレース結果を有する他のコンピュータ順に、前記プッシュ転送を実行することを特徴とするクライアントシステム。
17. 請求項１ないし１６のいずれか１に記載のクライアントシステムにおいて、前記クライアントシステムに含まれるコンピュータ同士の通信は、ピアツーピアにより行われることを特徴とするクライアントシステム。
18. クライアントに対してデータをダウンロードさせるようにしたデータ配信サーバであって、該データのメッセージダイジェスト値をクライアントから要求された場合、及び該データのダウンロードが要求された場合に、該クライアントが該データを取り扱ったものと認識して、該メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することを特徴とするデータ配信サーバ。
19. 請求項１ないし１７のいずれか１に記載のクライアントシステムと、該クライアントシステムにネットワークを介して接続し、該クライアントシステムに対してデータをダウンロードさせるサーバとを有することを特徴とするデータ転送システム。
20. 請求項１９に記載のデータ転送システムにおいて、前記サーバは、ダウンロード可能なデータのメッセージダイジェスト値をクライアントシステムのコンピュータから要求された場合、及び該データのダウンロードが該クライアントシステムのコンピュータから要求された場合に、該コンピュータが該データを取り扱ったものと認識して、前記メッセージダイジェスト値の要求及びダウンロードの要求履歴を保持することを特徴とするデータ転送システム。
21. 請求項１ないし１７のいずれか１に記載のクライアントシステム、請求項１８に記載のデータ配信サーバ、または請求項１９または２０に記載のデータ転送システムの機能を実現するためのプログラム。
22. 請求項２１に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。