(57)【特許請求の範囲】
【請求項１】
ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムにおいて、
上記インデックスサーバは、
過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、
トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、
上記転送元ノードを決定する転送元ノード決定手段とを備え、
上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定する
ことを特徴とするファイル転送システム。
【請求項２】
上記転送元ノード決定手段は、あるノードからファイル転送を受けている受信中のノードをも、転送元ノードの候補として、転送元ノードを決定するものであり、転送が終了している転送元ノードの候補が存在しない場合にのみ、受信中の転送元ノードの候補を転送元ノードに決定することを特徴とする請求項１に記載のファイル転送システム。
【請求項３】
ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムにおけるインデックスサーバにおいて、
過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、
トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、
上記転送元ノードを決定する転送元ノード決定手段とを備え、
上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定する
ことを特徴とするインデックスサーバ。
【請求項４】
ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送方法において、
上記インデックスサーバは、トポロジ情報管理手段、決定用パラメータ管理手段及び転送元ノード決定手段を備え、
上記トポロジ情報管理手段は、過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだ、ツリー構造のトポロジ情報を、ファイル毎に管理し、
上記決定用パラメータ管理手段は、トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理し、
上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定する
ことを特徴とするファイル転送方法。
【請求項５】
ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムのインデックスサーバに搭載されるファイル転送プログラムにおいて、
過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、
トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、
転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定する転送元ノード決定手段と
して機能させることを特徴とするファイル転送プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はファイル転送システム、ファイル転送方法、ファイル転送プログラム及びインデックスサーバに関し、例えば、同一のファイルを多数のノードに転送する場合に適用して好適なものである。
【背景技術】
【０００２】
例えば、コンテンツ配信システムにおいては、同一のコンテンツ（ファイル）を多くの端末に配信する。このようなシステムでは、端末の能力や仕様などが様々であるため、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を中心とした汎用ネットワークプロトコルにより相互通信可能な環境下でコンテンツを配信する。例えば、１０ＭＢを越えるような大容量のコンテンツは、転送が困難であり、転送中、送信元装置（サーバ）側のリソースが転送処理に傾注されるため、該当サーバへの負荷が集中すると、ネットワークが輻輳したり送信元装置の処理が追いつかずサービス不能になったりという事象が生じやすい。
【０００３】
そのため、送信元装置の負荷を軽減し、輻輳を回避することが望まれている。また、ファイルを適当なサイズに分割した上で配信し、途中で転送が中断しても修復可能なようにすることが望まれている。
【０００４】
このような要求に応えるべく、Ｐ２Ｐ型ファイル交換技術を利用することが考えられている。
【０００５】
クライアント／サーバ型のシステムでは、ファイルはサーバに存在するので、ファイルの「場所」を探す必要はない。
【０００６】
一方、Ｐ２Ｐ型のシステムでは、ファイルは各ピアが保持しており、固定的な場所にファイルがまとまって存在しているわけではない。そのため、ファイルを要求するノードは、ファイルの取得を開始する前に、何らかの方法でファイルの所在情報を得る「データ探索」が必要である。Ｐ２Ｐアプリケーションは、探索方法にそれぞれ様々な工夫を凝らしており、その工夫により、（１）ハイブリッドＰ２Ｐ、（２）ピュアＰ２Ｐ、（３）スーパーノード型ハイブリッドＰ２Ｐなどに分類できる（非特許文献１参照）。
【０００７】
「ハイブリッドＰ２Ｐ」は、クライアント／サーバ型とＰ２Ｐ型のハイブリッドである。ファイルの所在情報は固定的なサーバが一手に引き受ける。各ノードは、予め知っているサーバに問い合わせることで、ファイルの場所を知る。ファイルの探索を行うサーバのことを「インデックスサーバ」という。インデックスサーバは、ファイルの所在情報のみを扱い、ファイルの実体は、ピア同士でやり取りする点が、クライアント／サーバ型と異なっている。
【０００８】
特許文献１は、このようなハイブリッドＰ２Ｐを、コンテンツ配信システムに適用した技術を記載している。特許文献１に記載のシステムは、コンテンツを相互に配信する多数のダイナミックピアと、コンテンツの配信を管理するセンタサーバとを備える。各ダイナミックピアは、自身の動作状況をセンタサーバに通知し、センタサーバは、その動作状況に基づいて、各ダイナミックピアの負荷を計算し、登録する。各ダイナミックピアは、センタサーバからコンテンツリストを取得し、所望のコンテンツを取得している他のダイナミックピアを探し、負荷が最も低いダイナミックピアからコンテンツをダウンロードする。
【非特許文献１】ｈｔｔｐ：／／ｊａｐａｎ．ｉｎｔｅｒｎｅｔ．ｃｏｍ／ｃｏｌｕｍｎ／ｗｅｂｔｅｃｈ／２００５０５１１／８．ｈｔｍｌ
【特許文献１】特開２００６−７２４３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
特許文献１に記載のようなＰ２Ｐ型のシステムでは、ピア同士で効率的なトポロジを構成し、ピア同士のファイル転送を行うことによってサーバ（やスタチックピア）への負荷集中という問題を軽減できる。
【００１０】
しかしながら、特許文献１の記載技術では、各ダイナミックピアにコンテンツを複製して分散配置させているが、その時点で負荷が最も小さいダイナミックピアを配信元に決定するようにしているため、センタサーバは、各ダイナミックピアの負荷状況を常時把握していなければならず、また、負荷が常時変化する中で、各コンテンツを保持しているダイナミックピアを認識していなければならず、これらの処理の負担は大きい。また、ダイナミックピアやスタチックピアも、頻繁に負荷をセンタサーバに報告しなければならない。
【００１１】
なお、Ｐ２Ｐ型を適用したとしても、ファイルを保持しているノード（サーバ又はピア）が一つの場合には、アクセスは、そのファイルを持つノードに集中せざるを得ない。
【００１２】
また、Ｐ２Ｐ型システムは、中身とは異なるファイル名による偽装捏造、ウィルスを混入させた悪質ファイルの流通等、ファイルの正当性の保証に問題があると共に、著作権の侵害がある場合や個人情報・国家機密・企業機密等の流通が望ましくない情報も一度ファイルが広まったら流通を止められないといった問題も、最近の情報漏洩等の数々の事件から顕在化してきている。
【００１３】
さらに、従来のファイル転送方式では、目的とするファイルがネットワーク内に極端に少ない状況では、一度転送元との接続が切れてしまうと転送元を再度見つけるのが容易ではないという問題が生じる恐れがある。例えば、特許文献１の記載技術の場合、コンテンツの転送を受けていたダイナミックピアが、接続が切れる異常により、転送元の情報を消失した場合、センタサーバに、どの転送元から転送していたかの情報が残っていないため、転送元を再度見つけるのが容易ではなく、転送元の決定から再度やり直さなければならないという課題を有する。
【００１４】
本発明は、以上の点に鑑みなされたものであり、ネットワーク輻輳、サーバへの負荷集中というインフラ系の課題を解決でき、さらに、正当性の保証、望ましくない情報流通の阻止、情報流通の効率化を達成できるファイル転送システム、ファイル転送方法、ファイル転送プログラム及びインデックスサーバを提供しようとするものである。
【課題を解決するための手段】
【００１５】
第１の本発明は、ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムにおいて、上記インデックスサーバは、過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、上記転送元ノードを決定する転送元ノード決定手段とを備え、上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定することを特徴とする。
【００１６】
第２の本発明は、ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムにおけるインデックスサーバにおいて、（１）過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、（２）トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、（３）上記転送元ノードを決定する転送元ノード決定手段とを備え、（４）上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定することを特徴とする。
【００１７】
第３の本発明は、ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送方法において、（１）上記インデックスサーバは、トポロジ情報管理手段、決定用パラメータ管理手段及び転送元ノード決定手段を備え、（２）上記トポロジ情報管理手段は、過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだ、ツリー構造のトポロジ情報を、ファイル毎に管理し、（３）上記決定用パラメータ管理手段は、トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理し、（４）上記転送元ノード決定手段は、転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定することを特徴とする。
【００１８】
第４の本発明は、ファイルを欲するノードが、インデックスサーバにそのファイルを保持している転送元ノードとなるノードを問合せ、インデックスサーバが決定した転送元ノードの返信を受け、その転送元ノードからファイルの転送を受けるファイル転送システムのインデックスサーバに搭載されるファイル転送プログラムにおいて、上記インデックスサーバに搭載されるコンピュータを、（１）過去の転送における転送元及び転送先ノードを方向を持ったリンクで結んだツリー構造のトポロジ情報を、ファイル毎に、管理するトポロジ情報管理手段と、（２）トポロジ構造面以外で転送元ノードを決定するためのパラメータであって、転送元ノードとなり得るノード毎に、少なくともノードが属する地域及び利用可能な帯域を管理する決定用パラメータ管理手段と、（３）転送元ノードの候補の中から、ファイルを欲するノードの近傍地域に属するノードであって利用帯域が大きなノードを、上記転送元ノードに決定する転送元ノード決定手段として機能させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ネットワーク輻輳、サーバへの負荷集中というインフラ系の課題を解決でき、さらに、正当性の保証、望ましくない情報流通の阻止、情報流通の効率化を達成できるようになる。
【発明を実施するための最良の形態】
【００２０】
（Ａ）第１の実施形態
以下、本発明によるファイル転送システム、ファイル転送方法、ファイル転送プログラム及びインデックスサーバの第１の実施形態を、図面を参照しながら詳述する。ここで、第１の実施形態に係るファイル転送システムは、Ｐ２Ｐ型ファイル交換技術の分類から言えば、ハイブリッドＰ２Ｐ型に属するものとなっている。
【００２１】
（Ａ−１）第１の実施形態の構成
図２は、第１の実施形態に係るファイル転送システム１０の構成要素のネットワーク接続構成を示している。
【００２２】
図２において、第１の実施形態に係るファイル転送システム１０は、ファイル探索情報を全て把握している１又は複数のインデックスサーバ１２と、エンドユーザが利用するファイルの転送元、転送先となり得る複数のクライアント端末（以下、端末と略する）１３がそれぞれ、インターネット１１に接続されて構成されている。
【００２３】
各インデックスサーバ１２は、ハードウェアとして汎用サーバを利用することが可能であり、各端末１３は、ハードウェアとして汎用端末を利用することが可能であり、サーバ側処理もクライアント側処理も、ソフトウェア（第１の実施形態のファイル転送プログラム）として、各々のハードウェアに機能収容される。端末１３のソフトウェアは、例えば、Ｐ２Ｐアプリケーションとして搭載される。インデックスサーバ１２は、１台のインデックスサーバで構成されても良く、負荷分散や、信頼性確保のための冗長を目的とし、複数台を分散配備して構成されても良い（図２は複数台を分散配備して構成している場合を示している）。複数台での分散処理の場合は、リアルタイムで後述する各種データベースの同期がなされることが望ましく、このため、１つのデータベースを複数台のサーバで共用したり、複数のデータベースで冗長構成をとったりする方式も適用するようにしても良い。
【００２４】
図１は、インデックスサーバ１２の論理的な機能構成と、端末１３の論理的な機能構成を示すブロック図である。
【００２５】
インデックスサーバ１２は、図１（Ａ）に示すように、制御部２１、端末選定部２２、情報修正部２３、ログ記録・格納部２４、入出力部２５、端末データベース部２６及びファイルデータベース部２７を有する。なお、図１（Ａ）では通信部を省略している。
【００２６】
端末データベース部２６及びファイルデータベース部２７は、インデックスサーバ１２内に機能縮退されていても良いし、別装置であっても良い。縮退の場合は、入出力部２５は、ＰＣＩ、ＡＴＡＰＩ、ＳＣＳＩ、ＵＳＢ等の装置内インタフェース機能であり、別装置の場合は、入出力部２５はネットワークインタフェース機能である。
【００２７】
制御部２１は、ＣＰＵ及びＣＰＵが実行するプログラムで構成され、バスを介して他の各機能部の処理を制御するものである。
【００２８】
端末選定部２２は、転送元探索要求を送信した端末１３にとって最適な接続先端末（転送元端末）を選択し、指定接続先として転送元探索要求を送信した端末１３に対して通知する。端末選定部２２は、転送元探索要求に係るファイル情報に基づいて、ファイルデータベース部２７を検索して得られる保持している端末１３の情報と、端末データベース部２６を検索して得られる端末情報（利用帯域、所属地域情報、端末当り最大許容転送数、現在の端末の転送数）を用いて、転送元探索要求を送信した端末１３にとって最適な接続先端末を選択するものである。
【００２９】
第１の実施形態の場合、端末選定部２２は、基本的には、バケツリレー方式又は回覧方式と呼ぶのが相応しい方式（以下、回覧方式と呼ぶ）に従って接続先端末（転送元端末）を選択（決定）するようになされている。回覧方式による１直線上の直近の端末１３が、利用帯域、所属地域情報、端末当り最大許容転送数、現在の端末の転送数などの接続先制約条件から見て、接続先端末になれない場合に、その直線上の他の端末を候補とし、接続先制約条件を満足する他の端末１３を接続先端末（転送元端末）に選択する。従って、上述のように、ファイルの流れは回覧方式を基本としながら、上流側で枝分かれすることがあり、トポロジ的にはツリー構造である。
【００３０】
端末データベース部２６は、当該ファイル転送システム１０に収容されている各端末１３の情報（端末情報）を管理するものである。端末情報（１レコード）は、図３に示すように、利用者のＩＤ・パスワード２６ａ、端末のアドレス２６ｂ、利用帯域２６ｃ、ファイル当り最大許容転送数２６ｄ、端末当り最大許容転送数２６ｅ、現在の端末の転送数２６ｆ、所属地域情報２６ｇ、保有ファイル２６ｈ等である。
【００３１】
利用者のＩＤ・パスワード２６ａは、利用者の認証に利用するものである。
【００３２】
端末のアドレス２６ｂは、例えば、ＩＣＭＰによるｔｒａｃｅｒｏｕｔｅ等を用いて得られたホップ数の小さい方を優先接続先として選択するのに利用される。すなわち、同様なレベルの接続先候補がある場合には、ホップ数を考慮して接続先が決定される。
【００３３】
利用帯域２６ｃは、その端末１３が接続先端末（転送元端末）として転送可能な帯域の上限である。すなわち、ファイルの種類を問わず、転送元として転送している総帯域がこの利用帯域を越えることはできない。利用帯域２６ｃは、例えば、より大きな値を持つ端末１３を優先接続先として選択するのに利用される。
【００３４】
ファイル当り最大許容転送数２６ｄは、システムとして転送可能な１ファイル当りの上限の数であり、言い換えると、ファイル転送可能な最大リンク（分岐）数である。すなわち、あるファイルについて、転送元として転送する数は、このファイル当り最大許容転送数を超えることができない。同様な接続先の候補が複数ある場合には、後述する端末当り最大許容転送数２６ｅに余裕が大きい方を優先させることもできる。また、ファイル当り最大許容転送数２６ｄに満たない場合には、複数の転送元から同時に異なる部分の情報を受信することも可能である。
【００３５】
端末当り最大許容転送数２６ｅは、その端末１３が、ファイルの種類を問わず、転送元として送信し得る転送の上限である。
【００３６】
現在の端末の転送数２６ｆは、その時点までに、その端末１３が接続先端末（転送元端末）として転送した延べファイル数（ファイルの種類を問わない総転送数）や、ファイル毎の転送数である。
【００３７】
所属地域情報２６ｇは、その端末１３が所属している地域の情報である。例えば、端末選定部２２は、ファイル転送を許容する地域間の情報（例えば、同一地域や、近傍地域など）を内部記憶している。所属地域情報２６ｇは、同一あるいは近傍の所属地域情報を持つ端末１３を優先接続先として選択するのに利用される。なお、所属地域情報２６ｇは、ファイル転送を許容する地域間か否かの判定に利用するようにしても良い。
【００３８】
保有ファイル２６ｈは、その端末１３が保守しているファイルの種類（ファイル名）と各ファイルについて転送した数である。
【００３９】
ファイルデータベース部２７には、端末１３から提供されるアップロードリスト２７Ａの情報に加え、ファイル毎（ファイルの種類毎）に、ファイル転送経路に関するトポロジ情報２７Ｂが格納されている。ファイルデータベース部２７には、その他、判定未受信リスト２７Ｃも設けられている。
【００４０】
ファイルの流れは、回覧方式を基本としながら、上流側で枝分かれすることがあるので、トポロジ情報２７Ｂは、直線状、又は、下方に向かって枝分かれしているツリー構造をとる。
【００４１】
アップロードリスト２７Ａは、各端末が送信可能なファイルのリストであり、図４に示すように、各ファイルに関し、ファイル名２７Ａａ、ファイルサイズ２７Ａｂ、ハッシュ情報２７Ａｃ、ファイル種別２７Ａｄ、検索キーワード２７Ａｅ、サンプリングレート２７Ａｆや利用コーデック２７Ａｇや解像度２７Ａｈ等の関連パラメータといった情報を含んでいる。
【００４２】
ファイル名２７Ａａ、ファイルサイズ２７Ａｂ、ハッシュ情報２７Ａｃ及びファイル種別２７Ａｄという４つのパラメータの組によって、各ファイルを一意に識別可能となっている。
【００４３】
検索キーワード２７Ａｅは、端末１３に対して、利用者がこの検索キーワード２７Ａｅを用いてファイルの検索を指示するようにすることができるものであり、検索キーワード２７Ａｅを含むファイルの存在を識別するために利用される。
【００４４】
ファイル種別２７Ａｄ、サンプリングレート２７Ａｆ、利用コーデック２７Ａｇ、解像度２７Ａｈは、音声、動画像ファイルに関して、端末１３（利用者）が再生可能な環境を準備できているか否かを識別するために利用される。例えば、再生可能な環境が準備できていない場合は、転送終了後、端末１３にその旨を通知する仕組みを加えることで利用者の使い勝手を向上させることができる。
【００４５】
判定未受信リスト２７Ｃは、ある端末が転送元としてファイルを転送したときに、その転送先の端末が、受信したファイルの正当性を判定してインデックスサーバ１２に通知するが、その通知を受けていない場合に、このリスト２７Ｃに転送元の端末をリストアップしておくものである。
【００４６】
ログ記録・格納部２４は、当該インデックスサーバ１２の転送、情報送受信等の各種処理や障害イベント等に関わる情報を蓄積するものである。
【００４７】
情報修正部２３は、端末データベース部２６やファイルデータベース部２７の情報を更新するための演算や情報修正を行うものである。
【００４８】
一方、各端末１３は、図１（Ｂ）に示すように、制御部３１、設定格納部３２、ログ記録・格納部３３、ファイル格納部３４、入出力部３５、部分キャッシュ格納部３６及び接続状態監視部３７を有する。なお、図１（Ｂ）では通信部を省略している。
【００４９】
制御部３１は、ＣＰＵ及びＣＰＵが実行するプログラムで構成され、バスを介して他の各機能部の処理を制御するものである。
【００５０】
設定格納部３２は、当該端末１３についての、利用者のＩＤ・パスワード、端末のアドレス、利用帯域などなどの設定を格納しているものである。
【００５１】
ログ記録・格納部３３は、当該端末１３の転送、情報送受信等の各種処理や障害イベント等に関わる情報を蓄積するものである。
【００５２】
ファイル格納部３４は、ハードディスクその他の大容量記憶装置が該当し、ファイルの情報を保持しているものである。ファイルの情報は、例えば、ファイル名、ファイルサイズ、ハッシュ情報、ファイル種別、検索キーワード、サンプリングレートや利用コーデックや解像度等の関連パラメータ等である。
【００５３】
入出力部３５は、キーボードやマウスなどの入力部と、ディスプレイやプリンタなどの出力部とが該当する。入出力部３５は、利用者によるファイル転送の要求を受け付けたり、転送されたファイルを表示出力したり印刷出力したりするものである。
【００５４】
部分キャッシュ格納部３６は、転送の送信中のファイル、若しくは、転送されてきているファイルを一時的に格納しておくものである。当該端末１３が、転送元端末として動作する際には、ファイル格納部３４に格納されている該当するファイルが部分キャッシュ格納部３６に移動される。当該端末１３が、転送先端末として動作する際には、受信中のファイルは部分キャッシュ格納部３６に格納され、転送終了時に、ファイルは部分キャッシュ格納部３６からファイル格納部３４に移動される。
【００５５】
接続状態監視部３７は、インターネット１１を介した、他の端末１３やインデックスサーバ１２との接続状態を関し、必要に応じて、再送制御などを行うものである。
【００５６】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るファイル転送システム１０の各種動作を説明である。インデックスサーバ１２が、複数台で負荷分散して動作しても良いことは上述の通りである。但し、以下の説明では、説明の簡単化のため、インデックスサーバ１２が１台で構成されているように説明する。
【００５７】
まず、インデックスサーバ１２におけるサービス起動時及びサービス停止時の動作を説明する。
【００５８】
初期状態（サービスの待機状態）にあるインデックスサーバ１２は、起動操作に応じて起動処理を行い、起動処理の正常性を確認し、正常と判断されると、サービスの運用状態となる。起動処理の正常性の確認結果が異常と判断されると、インデックスサーバ１２は初期状態を維持する。
【００５９】
また、運用状態にあるインデックスサーバ１２は、停止操作に応じてサービスの停止処理を行い、停止処理の正常性を確認し、正常と判断されると初期状態となる。停止処理の正常性確認の結果が異常と判断されると、運用状態を維持する。
【００６０】
次に、端末１３のシステム接続時の動作を、図５のフローチャートを参照しながら説明する。また、端末１３のシステム接続時の動作に呼応するインデックスサーバ１２の動作も併せて説明する。
【００６１】
インデックスサーバ１２が運用状態にあるとき、端末１３は、システム切断状態（ステップ１０１）から、インターネット１１を介して、所定のインデックスサーバ１２に対して、端末情報を伴って認証要求を行う（ステップ１０２）。この要求に先立ち、端末１３は、利用者から利用者のＩＤ及びパスワードを取込み、これらに加え、端末のアドレス、利用帯域、転送されるファイル当りの最大許容転送数、端末当りの最大許容被転送数、所属地域情報を、端末情報に含めて認証要求を行う。
【００６２】
ここで、端末情報を伴って認証要求が到来したインデックスサーバ１２は、認証要求元の端末１３の利用者のＩＤ及びパスワードにより、認証を行い、認証結果を端末１３へ返信し、端末１３は、認証結果を確認する（ステップ１０３）。なお、認証が失敗した場合には、インデックスサーバ１２は端末１３の接続を拒否し、端末１３は、認証結果の返信に基づいて切断状態を維持する。認証が成功した場合には、端末１３は、アップロードリスト情報をインデックスサーバ１２へ送信する（ステップ１０４）。
【００６３】
インデックスサーバ１２は、端末１３からアップロードリスト情報を受信すると、このアップロードリスト情報に基づいて、ファイルの捏造・不良率を確認し、その結果を端末１３に通知する（ステップ１０５）。ファイルの捏造・不良率とは、アップロードリスト情報に記載されているファイルの総数を分母とし、アップロードリスト情報に記載されているファイルのうちの捏造又は不良などの異常なファイルの数を分子にとった比率である。捏造・不良率が所定の閾値以上の場合には、インデックスサーバ１３は端末１３の接続を拒否し、端末１３は切断状態を維持する。捏造・不良率が閾値未満の場合には、端末１３は接続状態に移行する（ステップ１０６）。
【００６４】
第１の実施形態の場合、ファイル転送の際、ファイルを授受する端末１３同士は、互いにツリー型のトポロジを採っており、ファイルの流れは回覧型である。転送先（下流側）の端末は、転送元（上流側）の端末の部分キャッシュ格納部３６の容量以上のファイルの情報を受信することはできない。
【００６５】
次に、端末１３が所望するファイルの転送を受ける場合の動作を、図６及び図７のフローチャートを参照しながら詳述する。図６は、端末１３側の動作を示し、図７は、インデックスサーバ側の動作を示している。
【００６６】
端末１３は、システムの接続状態にあるときに（ステップ１５１）、利用者から所望するファイルの受信要求操作がなされた場合（例えば、検索キーワードなどでファイルを特定する）には、そのファイルの転送を受けるための接続先となる他の端末を、インデックスサーバ１２へ問い合わせる（ステップ１５２）。
【００６７】
インデックスサーバ１２は、運用状態において（ステップ２０１）、端末１３から問合せを受けると（ステップ２０２）、所望ファイルの有無や、利用可能な接続先端末有無の確認を行う（ステップ２０３）。所望ファイルが存在しない場合には、その旨を問合せの返答として端末１３に返信し（ステップ２１０）、所望ファイルが存在するが利用可能な接続先端末が存在しない場合には、待機を指示する旨を問合せの返答として端末１３に返信し（ステップ２０９）、所望ファイルが存在し、かつ、利用可能な接続先端末が存在する場合には、指定接続先を決定した上で（候補が１個の場合には自動的にその端末に決定される）、決定された指定接続先情報を問合せの返答として端末１３に返信する（ステップ２０４）。
【００６８】
インデックスサーバ１２は、問合せの返答を行う際には、適宜、端末データベース部２６やファイルデータベース部２７の更新や、ログ記録・格納部２４に対するログの格納などを行う。例えば、ファイルデータベース部２７のトポロジ情報に、問合せ端末を「受信中端末」として追加する。
【００６９】
所望ファイルが存在するが利用可能な接続先端末が存在しない場合とは、例えば、接続先端末となり得る端末が、現在転送中であって、並列転送の能力がない場合や、並列転送の能力はあっても利用帯域の未使用帯域では所望ファイルを転送できない場合などが該当する。
【００７０】
端末１３から問合せを受けたインデックスサーバ１２は、例えば、以下のようにして指定接続先を決定する。
【００７１】
まず、保持端末が接続先になり得るかを確認し、接続先になり得る保持端末が一つのときには、その保持端末を接続先端末に決定する。「保持端末」とは、第１の実施形態においては当該ファイル転送システム１０内に、そのファイルが導入された際の端末（ツリー構造のトップノードとなる端末）をいう。なお、後述する第２の実施形態においては、「保持端末」とは、ファイルの全体を格納した端末をいい、当該ファイル転送システム１０内にそのファイルが導入された際の端末だけでなく、転送を受けたためにファイルの全体を格納した端末も保持端末の概念に含まれる。
【００７２】
複数の保持端末が接続先になり得る場合には、問合せ端末の近傍地域（同一地域を含む概念）の端末で、かつ、利用帯域の大きな端末が優先される。この面での優先レベルが高い保持端末も複数ある場合には、上述した種々のパラメータにおける値から決定する。各種パラメータ間の優先関係は任意に定めて良く、各パラメータの段階を数値化し、それら数値の重み付け加算値を評価値として算出し、評価値が高いものを選定するようにしても良い。すなわち、優先度判断のアルゴリズムに関しては、パラメータによる重み付け設定が可能であることが望ましい。
【００７３】
全ての保持端末が、他の端末への転送で新たな接続要求を受け付ける余地がない場合や、端末当り最大許容転送数の割当に達してもはや転送元になり得ない場合など、接続先になれない場合には、保持端末以外の非保持端末のうち、ファイルを受信中でないものの中から、接続先を決定する。このような端末が複数ある場合の接続先の選定アルゴリズムは、保持端末の場合と同様であり、接続先端末を一つ決定する。
【００７４】
非保持端末のうちファイルを受信中でない端末が存在しない場合には、受信中端末の中から接続先を選定する。受信中端末からの接続先の選定アルゴリズムにおいては、上位階層（トップノードに近い上流側）の端末が優先され、同一階層における複数の端末の中からの選定では、保持端末における選定アルゴリズムを準用する。受信中端末も、転送元端末になることもこの実施形態の一つの特徴となっている。受信中端末については、上位階層（トップノードに近い上流側）の端末を優先するようにしたので、受信しているファイル部分が、下位階層の端末より多いためである。
【００７５】
接続先の決定処理に際し、ファイル当り最大許容転送数、端末当り最大許容転送数の割当に達した保持端末又は非保持端末は、接続先としての選定対象から外される。
【００７６】
以上のような接続先の決定方法により、一定期間に多数の転送元探索要求が集中するような場合に、受信端末によるツリー構造の転送経路トポロジが形成されることになる。
【００７７】
端末１３は、問い合せたインデックスサーバ１２から、所望ファイルが存在しない旨、又は、所望ファイルが存在するが利用可能な接続先端末が存在しない旨が返信された場合（ステップ１５３）、接続状態（待機状態）に戻る。
【００７８】
これに対して、端末１３は、問い合せたインデックスサーバ１２から、接続先端末の指定が返信されると（ステップ１５４）、指定された接続先の端末に、該当するファイルの転送を要求し（ステップ１５５）、転送されてきたファイルを受信し（ステップ１５６）、ファイル転送が完了するのを待ち受ける（ステップ１５７）。
【００７９】
端末１３は、ファイル転送が完了する前に、接続先端末（転送元端末）との接続が切断された場合には（ファイル転送が未了の場合には）、インデックスサーバ１２への問合せから処理をやり直す。なお、図７では省略しているが、インデックスサーバ１２は過去のログなどから、同一の端末１３が再び問合せしてきたことを認識し、過去の決定を考慮して接続先端末を決定する。
【００８０】
端末１３は、ファイル転送が完了すると、インデックスサーバ１２に対し転送完了通知（受信完了通知）を送信する（ステップ１５８）。
【００８１】
インデックスサーバ１２は、転送完了通知を受信すると（ステップ２０５）、その受信時の処理を行う（ステップ２０６）。例えば、送信端末の転送数を１つ削減すると共に、ファイルデータベース部２７のトポロジ情報において、受信端末を「受信中端末」から該当ファイルを保持している「非保持端末」へ書き換えたり、配下の受信端末の階層情報を該当受信端末を基準として書き換えたりする。また例えば、正当性の判定結果を未受信である端末リストに、接続先端末（転送元端末）の情報を追加する。
【００８２】
端末１３は、転送されたファイルが捏造されたもの（例えばハッシュ情報から判断する）であるかや、不良なファイル（例えばウィルスに感染しているファイル）であるかなどの正当性を判定し、その判定結果を、インデックスサーバ１２に送信し（ステップ１５９）、その接続状態（待機状態）に戻る。正当性の判定方法としては、既存の種々のものを適用できる。
【００８３】
インデックスサーバ１２は、正当性の判定結果を受信すると、その受信時の処理を行う（ステップ２０８）。例えば、捏造・不良率情報を計算し直したり、判定未受信リストから、接続先（転送元）端末を削除したりする。また、判定結果が捏造又は不良ファイルを表している場合には、今回の接続先（転送元）端末を、今後、接続先端末として決定できないように情報を更新する処理を行う。
【００８４】
接続先端末（転送元端末）の具体的な決定例を、図８を用いて説明する。図８は、端末１３Ａが保持端末であり、保持端末１３Ａから端末１３Ｂ及び１３Ｃがファイルの転送を受け、端末１３Ｂから端末１３Ｄがファイルの転送を受け、このようなトポロジ情報がインデックスサーバ１２に記憶されている場合である。このような場合において、端末１３Ｅがインデックスサーバ１２に問合せを行ったとする。
【００８５】
唯一の保持端末１３Ａが接続先端末になり得る場合であれば、保持端末１３Ａが接続先端末に決定される。
【００８６】
例えば、保持端末１３Ａのファイル当り最大許容転送数が「２」であって、保持端末１３Ａがもはや接続先端末になり得ない場合であれば、インデックスサーバ１２は、端末１３Ｂ〜１３Ｄの中から接続先端末を決定する。まず、端末１３Ｂ〜１３Ｄの中でファイル受信を完了しているものがあるか否かを確認する。ファイル受信を完了しているものが端末１３Ｂだけであれば、この端末１３Ｂを接続先端末に決定する。ファイル受信を完了しているものが端末１３Ｂ及び１３Ｃであれば（端末１３Ｄは受信中）、これら端末１３Ｂ及び１３Ｃを、まず、端末１３Ｅとの地域の一致性と利用帯域の多少とで比較し、一方の端末１３Ｂ又は１３Ｃを接続先端末に決定する。地域の一致性と利用帯域の多少との面が同レベルであれば、他のパラメータから優先する端末を決定する。
【００８７】
また例えば、保持端末１３Ａ及び端末１３Ｂがもはや接続先端末になり得ない場合であれば、インデックスサーバ１２は、端末１３Ｃ及び１３Ｄの中から接続先端末を決定する。端末１３Ｃ及び１３Ｄが共にファイル受信を完了している場合には、階層の相違は関係なく、上述した、ファイル受信を完了している端末が端末１３Ｂ及び１３Ｃである場合と同様な方法で接続先端末を決定する。端末１３Ｃ及び１３Ｄが共に受信中端末である場合には、端末１３Ｃの方が上位階層であるので、端末１３Ｃを接続先端末に決定する。
【００８８】
例えば、端末１３Ｅの接続先端末として端末１３Ｃが決定された場合には、トポロジ情報には、端末１３Ｅ及び１３Ｃを結ぶリンクが追加され、また、端末データベース部２６における端末１３Ｅ及び１３Ｃの情報の更新などが実行される。
【００８９】
フローチャートの図示は省略しているが、ある端末１３において、ファイル格納部３４から、あるファイルが削除された場合は、その旨が、端末１３からインデックスサーバ１２に通知され、インデックスサーバ１２は、それを契機として、ファイルデータベース部２７から、該当端末１３がそのファイルを保持していることを表す情報を削除する。
【００９０】
次に、端末１３のシステム切断時の動作を説明する。端末１３が接続状態（待機状態）のときに、切断操作がなされると、インターネット１１を介して、所定のインデックスサーバ１２に対して、切断要求を行う。インデックスサーバ１２では、切断要求を受信すると、システム切断処理を行い、切断応答を端末１３へ送信する。端末１３は、切断応答を受信すると、切断状態となる。また、端末１３の接続状態時あるいは切断要求時に、ネットワークやシステムに障害が起こると、端末１３は強制的に切断状態となる。
【００９１】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、ハイブリッドＰ２Ｐ型に属するファイル転送システムであるので、ネットワーク輻輳、サーバへの負荷集中というインフラ系の課題を解決できる。すなわち、ファイル保持端末が分散するため、アクセスの集中による輻輳が避けられる。
【００９２】
また、ファイル転送に関する情報を、インデックスサーバ側で管理できるため、違法ファイル（例えば著作権侵害ファイル）やウィルス等が入った有害ファイルの流通を防止し易い。
【００９３】
さらに、ツリー状トポロジによるファイル流通であるため、流通の効率化を達成することができ、また、ダウンロードしたユーザを記録に残せるため、ファイル（情報）の流通を管理し易い。
【００９４】
さらにまた、既存のＰ２Ｐアプリケーションのように、端末同士のトポロジ構成は全てのファイル検索やダウンロードで一意というわけではなく、転送ファイル毎に異なる構成が自律的に発生し、そのため、より効率的な帯域利用が可能になる。
【００９５】
また、ファイル転送が途中で中断しても、インデックスサーバなどのログ情報などに基づいて、接続先を容易に検索することができる。
【００９６】
（Ｂ）第２の実施形態
次に、本発明によるファイル転送システム、ファイル転送方法、ファイル転送プログラム及びインデックスサーバの第２の実施形態を、図面を参照しながら説明する。
【００９７】
上述した第１の実施形態において、ファイルの転送元となり得る端末は、当該ファイル転送システム１０内にそのファイルが導入された際の保持端末、保持端末以外の端末であってファイルの全体を保持している端末、ファイルを受信中の端末、の３分類に分けられ、これら分類の相違も、接続先端末の決定に影響するものであった。
【００９８】
この第２の実施形態では、当該ファイル転送システム１０内にそのファイルが導入された際の端末であるためにファイルの全体を格納しているか、ファイル転送を受けたためにファイルの全体を格納しているかを問わず、ファイルの全体を格納している端末を保持端末としている。従って、第２の実施形態では、保持端末と受信中端末との２分類しかなく、接続先端末の決定にはこの２分類の相違を反映する。保持端末と受信中端末との間では、インデックスサーバ１２で設定されたファイル当り最大許容転送数（転送チェーン数）に満たない場合には、保持端末を優先させる。
【００９９】
インデックスサーバ１２は、ファイルの転送完了通知を受信したときに行う、上述した図７のステップ２０６の処理において、「受信中端末」を「保持端末」に書き直す処理を実行すれば良い。その他は、第１の実施形態と同様である。
【０１００】
「受信中端末」を「保持端末」に書き直すことは、図９に示すように、その受信中の端末を転送元端末としてファイル転送を受けている端末があれば、その端末に係るトポロジも変更したと同様になる。
【０１０１】
第２の実施形態によっても、第１の実施形態と同様な効果を奏することができる。これに加え、端末の分類数を少なくしたので、接続先（転送元）端末の決定アルゴリズムを簡易にすることができるという効果をも奏する。
【０１０２】
（Ｃ）他の実施形態
上記各実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【０１０３】
上記各実施形態では、ファイルを転送し合うノードが端末であるものを示したが、本発明は端末に限定されないものである。すなわち、ファイルを転送し合うノードが対応であれば良く、端末に限定されるものではない。例えば、放送のキー局の装置が、その傘下の地方局の装置にコンテンツを配信し、各局の装置が有線で各利用者の装置にコンテンツを配信するようなシステムにおいて、各局の装置へのコンテンツの配信にも本発明を適用することができる。
【０１０４】
また、上記各実施形態では、ファイルの転送先端末へは、一つの転送元装置からファイルを転送する場合を示したが、複数の転送元装置から一つの転送先装置へファイルを転送するようにしても良い。例えば、ある端末Ｃへの転送元端末として、端末Ａからのファイルを受信中の端末Ｂが決定された場合、端末Ｂは端末Ｃからの転送要求が与えられたときに、受信済みのファイル部分を端末Ｃへ転送し、端末Ａは、端末Ｂからの指示に従い、端末Ｂへ転送する残りのファイル部分をコピーして、端末Ｂ及び端末Ｃに並列に転送するようにしても良い。
【０１０５】
上記実施形態では、受信中端末間で、上位階層の端末を優先させるものを示したが、問合せ時刻又は受信開始時刻が早いものを優先させるようにしても良い。
【０１０６】
また、転送元端末として、受信中端末を認めないようにしても良い。この場合において、受信完了が直近の端末を接続先端末の決定で優先させるようにしても良い。また、システムを構成するノード数が少ない場合には、各ノードは他の１つのノードにのみ１つのファイルを転送できるようにしても良い。なお、受信中端末を含めても、受信開始時刻が遅いものを接続先端末の決定で優先させるようにしても良い。
【０１０７】
上記説明は、転送されるファイルが動画コンテンツのイメージで説明したが、転送ファイルの種類は限定されるものではない。
【図面の簡単な説明】
【０１０８】
【図１】第１の実施形態におけるインデックスサーバとクライアント端末との論理的な機能構成を示すブロック図である。
【図２】第１の実施形態に係るファイル転送システムの構成要素のネットワーク接続の概要を示すブロック図である。
【図３】第１の実施形態における端末データベース部の格納内容の説明図である。
【図４】第１の実施形態におけるアップロードリストの構成の説明図である。
【図５】第１の実施形態におけるクライアント端末のシステム接続時の動作を示すフローチャートである。
【図６】第１の実施形態におけるクライアント端末が所望するファイルの転送を受ける場合のクライアント端末側の動作を示すフローチャートである。
【図７】第１の実施形態におけるクライアント端末が所望するファイルの転送を受ける場合のインデックスサーバ側の動作を示すフローチャートである。
【図８】第１の実施形態における接続先端末（転送元端末）の具体的な決定方法の説明図である。
【図９】第２の実施形態におけるファイル転送システムの特徴の説明図である。
【符号の説明】
【０１０９】
１０…ファイル転送システム、１１…インターネット、１２…インデックスサーバ、１３…クライアント端末、２１…制御部、２２…端末選定部、２３…情報修正部、２４…ログ記録・格納部、２５…入出力部、２６…端末データベース部、２７…ファイルデータベース部、３１…制御部、３２…設定格納部、３３…ログ記録・格納部、３４…ファイル格納部、３５…入出力部、３６…部分キャッシュ格納部、３７…接続状態監視部。
【図１】
0005119844.tif 000002
【図２】
0005119844.tif 000003
【図３】
0005119844.tif 000004
【図４】
0005119844.tif 000005
【図５】
0005119844.tif 000006
【図６】
0005119844.tif 000007
【図７】
0005119844.tif 000008
【図８】
0005119844.tif 000009
【図９】
0005119844.tif 000010