JP2003006032A - 分散ファイル共有システム - Google Patents

Abstract

(57)【要約】 【課題】 ファイル共有システムに関し、特に企業内あ
るいは企業間で個人同士がお互いにファイルを公開し、
一対一でファイルの交換を行うピアツーピア形式の分散
されたファイルを簡易且つ効率的に共有するシステムを
提供する。 【解決手段】 ネットワークと、それに接続されるロー
カルファイル３１〜３４を保有する複数のコンピュータ
２１〜２３、及び前記各々のローカルファイルへそのア
ドレス情報によってリンクされた仮想ディレクトリを表
示するディレクトリサーバ１０と、を備える。前記仮想
ディレクトリへのアクセスにより、そのアドレス情報か
ら対応する前記複数のコンピュータのローカルファイル
が公開される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はファイル共有システ
ムに関し、特に企業内あるいは企業間で個人同士がお互
いにファイルを公開し、一対一でファイルの交換を行う
ピアツーピア形式のコンテンツ共有システムであって、
データベース、ディレクトリサービス、又は文書管理シ
ステム等においてネットワーク上に分散した資源を管理
するファイル分散型の共有システムに関するものであ
る。

【０００２】

【従来の技術】現在、ネットワークを介したファイル共
有システムとしては、 （１）ＷＷＷ (World Wide Web) による公開 （２）レプリケーション (Replication) /ミラーリング
(Mirroring) （３）Ｗｉｎｄｏｗｓのファイル共有 （４）メールやＦＴＰ (File Transfer Protocol) 等の
ユーザ操作による個別送信 等が用いられており、例えば（１）及び（４）はインタ
ーネットやイントラネットに、（２）はデータベースや
グループウェアに、また（３）はＬＡＮ (LocalArea Ne
twork) に主に使用されている。

【０００３】

【発明が解決しようとする課題】従来技術（１）〜
（４）は、上記の各使用分野においては有効に機能する
が、これらを企業内及び／又は企業間において個人ベー
スで互いに各自のファイルを公開し、一対一でファイル
交換を行うピアツーピア形式のコンテンツ共有システム
に適用しようとすると以下に示すような問題が存在して
いた。

【０００４】なお、ここでの企業内及び／又は企業間に
おける個人ベースによるピアツーピア形式のコンテンツ
共有とは、例えばソフトウェア会社Ａの技術者ａと、そ
の子会社Ｂの技術者ｂとがイントラネットやインターネ
ットを介して、各自の設計ファイルａ’及びｂ’を相互
に共有して作業するような場合をいい、またコンテンツ
共有システムは、データベース、ディレクトリサービ
ス、又は文書管理システム等において各コンテンツがネ
ットワーク上に分散して存在するようなコンテンツ分散
型の共有システムをいう。

【０００５】（１）のＷＷＷは、所定の情報を一方的に
配信するのには適しているが、ピアツーピア形式で相互
のファイルを逐次更新するのに煩雑な操作を必要とす
る。すなわち、更新情報の提供側はその都度ユーザ自身
の操作でＨＴＴＰ (Hyper TextTransfer Protocol) サ
ーバ上へ更新したファイルを一旦アップロードする必要
がある、またＨＴＭＬ (Hyper Text Markup Language)
形式のインデックスファイル (index.html等)を編集し
て更新したファイルへの新たなリンクを追加する必要も
生じる、さらにファイアウォール内部に配置されたＨＴ
ＴＰサーバのコンテンツは容易に参照できない、等の問
題があった。

【０００６】（２）のレプリケーション/ミラーリング
は、その対象となる全てのサーバに対してファイルの複
製を送信する必要があるためトラフィックや各コンピュ
ータの管理スペースが増大する、またファイアウォール
にまたがるシステム構築ができない、等の問題があっ
た。

【０００７】（３）のＷｉｎｄｏｗｓ（登録商標）のフ
ァイル共有は、ディレクトリ構成が各コンピュータ単位
の物理的な構成に制限されるため、論理的又は概念的な
階層構成として各ユーザにディレクトリを割り当てるこ
とができない、またファイルを保持するコンピュータが
オフラインの場合はそこからファイルを取得することが
できない、さらにファイアウォールにまたがるシステム
構成ができない、等の問題があった。

【０００８】（４）のメール／ＦＴＰは、ユーザ操作に
よって共有ファイルを構築する必要があるため、煩雑な
操作に起因するミス等により完全に同期した共有状態を
ユーザ相互間で維持することが困難である、という問題
があった。

【０００９】そこで本発明の目的は、上記各問題点に鑑
み、ネットワーク上の企業内又は企業間の複数の拠点間
において、個人ベースで互いにファイルを公開し、一対
一でファイル交換をおこなうピアツーピア形式のコンテ
ンツ共有システムを提供することにある。そのため、従
来手法のうち特に（１）及び（４）の簡便性を積極的に
取り入れることによって容易に構築できるピアツーピア
形式のファイル共有システムを提供する。

【００１０】

【課題を解決するための手段】本発明によれば、ネット
ワークと、それに接続されるローカルファイルを保有す
る複数のコンピュータ、及び前記各々のローカルファイ
ルへそのアドレス情報によってリンクされた仮想ディレ
クトリを表示するディレクトリサーバと、を備え、前記
仮想ディレクトリへのアクセスにより、そのアドレス情
報から対応する前記複数のコンピュータのローカルファ
イルが公開される分散ファイル共有システムが提供され
る。

【００１１】前記アドレス情報は、前記複数のコンピュ
ータの内の１つを示すホスト情報とそのコンピュータ内
のファイル位置情報とを含み、前記アドレス情報の書き
換えにより、ファイル共有者の一人による公開ファイル
の更新が可能となる。また、ファイル公開に必要なメッ
セージをファイアウォールを介して通信するためのメッ
セージ変換サーバを含み、さらに前記複数のコンピュー
タのいずれかがオフラインの時に、それに代えて保存し
てある公開ファイルを公開するバックアップサーバを含
むことができる。

【００１２】

【発明の実施の形態】図１は、本発明の基本構成を図式
的に示したものである。図１において、ＨＴＴＰに対応
したディレクトリサーバ１０は、各ホストコンピュータ
２１〜２３が分散して保有する種々のファイル３１〜３
４を一つの統合した仮想ディレクトリ構成の画面として
表示する。本例では、ディレクトリ１１をルートとする
ツリー状の階層構造をなしており、各ディレクトリ１２
〜１５には各ホストコンピュータ２１〜２３のホスト情
報及び各ホスト内部のファイル３１〜３４へのリンク情
報であるファイル情報が保持されている。

【００１３】本例において、ディレクトリ１２はホスト
コンピュータ２１のファイル３１へリンクされており、
同様にディレクトリ１３はホストコンピュータ２１のフ
ァイル３２へ、ディレクトリ１４はホストコンピュータ
２２のファイル３３へ、及びディレクトリ１５はホスト
コンピュータ２３のファイル３４へそれぞれリンクされ
ている。ディレクトリ１２及び１３の例から明らかなよ
うに、ディレクトリを仮想化することでＷｉｎｄｏｗｓ
のファイル共有においけるディレクトリとホストコンピ
ュータとを一対一に対応させる物理的な制約から解放さ
れる。

【００１４】図２には、仮想ディレクトリ内の各ディレ
クトリ１２〜１５に格納されるホスト／ファイル情報
と、各ホストコンピュータ２１〜２３内に存在するファ
イルの実体とを関連付ける一例を示している。図２の左
側はディレクトリサーバ１０が各ディレクトリ１２〜１
５に対応して保有するＵＲＬ (Universal Resource Loc
ator) 情報の例を示している。

【００１５】このように、上述した各ディレクトリ１２
〜１５に格納されるホスト情報及びファイル情報をＵＲ
Ｌ形式で保持することにより、例えばホスト情報として
“ｗｗｗ．ｆｊｏｋｕｂｏ”を、ファイル情報として
“／ｓｐｅｃ／ｓｐｅｃ１．ｄｏｃ”を同時に指示する
ことができ、さらにディレクトリサーバ１０と各ホスト
コンピュータ２１〜２３との間の通信にもインターネッ
トで一般に使用されるＨＴＴＰ“ｈｔｔｐ：／／”をそ
のまま使用することができる。

【００１６】一方、図２の右側に示すように各ホストコ
ンピュータ２１〜２３の側においても、それらがＨＴＴ
Ｐをサポートする場合には、ディレクトリサーバ１０よ
り受信したＵＲＬを元に、そのホスト情報“ｗｗｗ．ｆ
ｊｏｋｕｂｏ”から自ホストへの要求であることを判断
し、それに続くファイル情報“／ｓｐｅｃ／ｓｐｅｃ
１．ｄｏｃ”から自ホスト内部のエイリアス機能若しく
は変換テーブル等を使って要求ファイルへのリンク情報
“／ｕｓｅｒ／ｏｋｕｂｏ／ｄｏｃｓ／ｓｐｅｃ／ｓｐ
ｅｃ１．ｄｏｃ”を容易に得ることができる。

【００１７】以下では、上記の説明を前提に図１におけ
る基本的な動作を説明する。ここでは上記ＵＲＬを使用
することを前提とし、そのため個々のホストコンピュー
タ２１〜２３はＨＴＴＰをサポートするファイルサーバ
の機能を持つ。各ユーザが自己のファイルを公開するた
めには自身のファイルサーバに公開するファイルのパス
を登録する必要がある。これについては、上述したエイ
リアス機能や変換テーブル等が用いられる。

【００１８】すなわち、各ホストコンピュータ２１〜２
３はファイルサーバとして他の任意のコンピュータから
ファイルを一意に特定できるアドレス情報(ＵＲＬ；ホ
スト情報及びファイル情報)を生成し、そのアドレス情
報と公開するファイルへのローカルパスのマッピング情
報とを保持する。次に、各ホストコンピュータ２１〜２
３は、図１に示したディレクトリサーバ１０における仮
想ディレクトリ内の任意のディレクトリに自己の公開フ
ァイルのアドレス情報を登録し公開する。

【００１９】図３には、各ホストコンピュータ２１〜２
３がディレクトリサーバ１０へ公開ファイルを登録する
際の登録画面の一例を示している。すなわち、各ホスト
コンピュータ２１〜２３からの公開ファイル登録要求に
よってディレクトリサーバ１０からは図３の登録画面が
送られてくる。本例では、公開ファイル“ｓｐｅｃ１．
ｄｏｃ”が登録ディレクトリ“開発プロジェクト／仕様
／詳細仕様”に登録される。この際には、登録ユーザを
認証するためのパスワード等が要求される。

【００２０】前記登録ディレクトリは、仮想ディレクト
リ画面内の１つのディレクトリに対応しユーザが任意に
選択できる。また、図示はしていないが、ユーザは所定
の画面操作により新規にディレクトリを生成して仮想デ
ィレクトリ内の任意の位置に配置したり、さらに不要と
なった既存の登録ディレクトリを削除することができ
る。このディレクトリ生成の時点で、一例としてユーザ
がその登録ディレクトリ名“開発プロジェクト／仕様／
詳細仕様”に対応させたＵＲＬ情報“ｗｗｗ．ｆｊｏｋ
ｕｂｏ／ｓｐｅｃ／”を設定する。

【００２１】その結果、ディレクトリサーバ１０は、前
記登録ディレクトリ“開発プロジェクト／仕様／詳細仕
様”にマッピングされるＵＲＬ情報“ｗｗｗ．ｆｊｏｋ
ｕｂｏ／ｓｐｅｃ／ｓｐｅｃ１．ｄｏｃ”を生成して保
持する。他の例としては、ディレクトリサーバ１０が、
すでに登録してあるユーザ情報から登録ディレクトリに
対応するＵＲＬ情報“ｗｗｗ．ｆｊｏｋｕｂｏ／ｓｐｅ
ｃ／”を自動的に生成するように構成することも当然可
能である。

【００２２】他のコンピュータは、ＷＷＷブラウザ等を
使用してディレクトリサーバ１０にアクセスし、ＷＷＷ
ブラウザに表示された仮想ディレクトリ内のディレクト
リ“開発プロジェクト／仕様／詳細仕様”をクリックす
ると、ディレクトリサーバ１０は自身が保持するマッピ
ング情報から“ｗｗｗ．ｆｊｏｋｕｂｏ／ｓｐｅｃ／ｓ
ｐｅｃ１．ｄｏｃ”宛に公開ファイル“ｓｐｅｃ１．ｄ
ｏｃ”の要求を行う。

【００２３】その際、ディレクトリサーバ１０はＩＰパ
ケットの送信元ＩＰアドレスをファイル要求をしてきた
コンピュータのＩＰアドレスに置き換える。その結果、
公開ファイル“ｓｐｅｃ１．ｄｏｃ”を保有するコンピ
ュータは、自装置内のローカルファイル“／ｕｓｅｒ／
ｏｋｕｂｏ／ｄｏｃｓ／ｓｐｅｃ／ｓｐｅｃ１．ｄｏ
ｃ”を検出して、ファイル要求元の他のコンピュータへ
直接その公開ファイル“ｓｐｅｃ１．ｄｏｃ”を送信す
ることになる。

【００２４】このように、本発明によれば分散して保有
される各コンピュータ２１〜２３の公開ファイルが他の
ユーザによって直接参照されるため、そのファイルがロ
ーカルに更新された時にも従来例の（１）及び（２）の
ようにファイルのアップロードや複製等の手順が不要と
なり、常にユーザが意図する最新のファイル内容が公開
される。

【００２５】また、仮想ディレクトリをネットワーク上
で共有することにより、ファイルの物理的な位置を意識
せずにファイルを参照することが可能になる。この仮想
化によって従来例の（３）のように物理的なコンピュー
タ単位のディレクトリ構成に制限されず、さらに従来例
の（４）のようにユーザ手動のファイル操作が不要とな
る。

【００２６】さらに、公開ファイルを保有するコンピュ
ータユーザ以外の他のコンピュータユーザが共有ファイ
ルを更新する場合には、他のコンピュータのユーザがネ
ットワークを介して共有ファイルを取得し、それを自身
のコンピュータ上で変更する。次に、ディレクトリサー
バ１０にアクセスして仮想ディレクトリ上の対応する登
録ディレクトリの前述したアドレス情報を自身のものに
書き換える。

【００２７】このように、ファイル共有ユーザによるフ
ァイルの相互更新も容易に行なうことができ、従来例の
（１）における一方向への配信という制限が解消する。
なお、この場合には、ディレクトリサーバ１０において
各ファイル共有ユーザが登録ディレクトリのアドレス情
報の書き換えが許可されている必要がある。

【００２８】図４は、本発明によるファイアウォールを
介したファイル取得の一構成例を示したものである。公
開ファイルがファイアウォール３０を挟んで別のドメイ
ン内のコンピュータに保有されて場合、ファイアウォー
ルに設定されたアプリケーションの制限からプロトコル
によってはファイアウォール内にあるそのコンピュータ
と直接通信できない場合が生じる。そのため、ファイア
ウォール３０の前後でファイアウォールを通過可能なプ
ロトコル形式に変換することによって、固有のファイア
ウォールを具備する組織間においてもファイル交換を可
能にする。

【００２９】ファイアウォール３０の前後に置かれるメ
ッセージ中継器３２及び３３がファイル要求メッセージ
や公開ファイルをファイアウォール通過可能な所定のア
プリケーション形式に変換する。本例ではそのようなア
プリケーションとしてメールが使用されている。先ず、
要求元のコンピュータ３１（例えば、図１のディレクト
リサーバ又はそれにアクセスしたコンピュータ）がファ
イル要求メッセージを送信すると、メッセージ中継器３
１がその要求を受信する。メッセージ中継器３１は、受
信したメッセージをメール本文に含めるたちでファイア
ウォール３０を通過させる。

【００３０】ファイアウォール３０を通過したメール
は、要求先のメッセージ中継器３３で元のメッセージに
復元されてから公開ファイルを保有するコンピュータ３
４で受信される。コンピュータ３４が要求された公開フ
ァイルを応答送信すると、その宛先アドレスから要求先
のメッセージ中継器３３が応答メッセージをファイアウ
ォール通過可能なメール形式に変換する。その際、受信
した公開ファイルはメール本文として又はメールの添付
ファイルとしてファイアウォール３０を通過する。

【００３１】以降は、要求元のメッセージ中継器３２が
公開ファイルを復元して要求元のコンピュータ３１へ送
信する。このように、ファイアウォールを介した通信も
容易に実現することができる。なお、ファイアウォール
を介する通信の場合にはファイル要求メッセ−ジや公開
ファイルを含む応答メッセージの全てをファイアウォー
ルの両側に置かれたディレクトリサーバを中継するよう
に構成してもよい。この場合、両ディレクトリサーバ間
のファイアウォールの設定はその間のパケット通信だけ
を許可する簡易なパケットフィルタリング処理でよく、
アプリケーションレベルでファイアウォールを通過させ
るメッセージ中継器等を省くこともできる。

【００３２】図５は、本発明による分散ファイル共有シ
ステムの一実施例を示したものである。図５において、
引用符号１０及び４６はディレクトリサーバであり、ま
た引用符号２１、２２及び３４はホストコンピュータで
ある。ここで、引用符号４０及び４１の各枠線で囲まれ
たシステムはそれぞれのファイヤウォール内部のシステ
ムであることを示す。

【００３３】ホストコンピュータ２１、２２及び３４内
部のファイルサーバ２１−１、２２−１、及び３４−１
は、自身が保有するファイルを公開するための機能モジ
ュールに相当し、公開ファイルに対する要求や応答をＨ
ＴＴＰによって実行し、通常のＨＴＴＰサーバと同等の
機能を有する。なお、マッピング情報や公開ファイル等
はこれまでの説明の通りである。また、ディレクトリサ
ーバ１０及び４６も図１の説明と同様である。

【００３４】プロキシサーバ４３は、ファイアウォール
単位に設置される通常のプロキシサーバと同じであり、
公開されるファイルをキャッシングすることでそれに対
するアクセスや応答を高速に行なう。メッセージ中継サ
ーバ３２及び３３は、それぞれ図４のメッセージ中継器
３２及び３３に対応しており、ＨＴＴＰとＳＭＴＰ ((S
imple Mail Transfer Protocol) ／ＰＯＰ (PostOffice
Protocol) との間のメッセージプロトコルの変換を行
なう。また、メッセージ中継サーバ単位に、送受信を行
うためのメールアカウントを用意する。

【００３５】メールサーバ４４及び４５は、ＳＭＴＰ／
ＰＯＰを使ってファイアウォールを介したファイル要求
メッセージやその応答メッセージの送受信を行う。これ
らの各サーバ動作については、本発明と関連するものに
ついてはすでに説明してあり、またその他のサーバ動作
については一般のものと同様であることから、ここでは
更に説明しない。

【００３６】バックアップサーバ４２は、公開されたフ
ァイルのバックアップを行い、またバックアップしたフ
ァイルに対する要求に対してその要求ファイルを送信す
る。バックアップファイルの要求には、先に説明したＵ
ＲＬ形式のアドレス情報がそのホスト情報がバックアッ
プサーバを示す以外はそのまま用いられる。

【００３７】バックアップサーバ４２は、通常のバック
アップ動作以外に、要求された公開ファイルを保有する
コンピュータがオフラインの場合でもその要求ファイル
を提供できる利点がある。従って、ディレクトリサーバ
１０はファイル要求先からの応答が無い時にはバックア
ップサーバ４２へファイル要求メッセージを送信してフ
ァイル取得を可能にすることができる。但しこの場合、
取得ファイルが最新であることは保証されない。

【００３８】図６〜１２は、図５の実施例におけるファ
イル共有の基本的な手順をシーケンス図で示したもので
ある。図６は、ファイルの公開手順を示したシーケンス
図である。図６において、利用者が仮想ディレクトリの
中から、ファイルを公開するディレクトリを特定し，自
身のファイルサーバ２１−１内ではファイルのＵＲＬお
よび、前記ＵＲＬとローカルパスとの間のマッピング情
報が生成され保持される（Ｓ１０１）。

【００３９】なお、先に説明した本発明の基本動作では
ディレクトリサーバ１０を対象にその登録手順の一例を
上げて図３の登録画面を使用したが、図５以降の実施例
では同様な手順をコンピュータ内のファイルサーバ２１
−１に対して行い、ファイルサーバ２１−１がディレク
トリサーバ１０との間で同様な登録動作を自動的に実行
する。従って、利用者のＷＷＷブラウザにはファイルサ
ーバ２１−１が提供する登録画面（図３）が表示され
る。

【００４０】すなわち、ファイルサーバ２１−１はディ
レクトリサーバ１０に対して、１）ファイル名、２）フ
ァイルのＵＲＬ、及び３）ファイルを登録するディレク
トリの情報、を自動送信してファイルの公開を依頼する
（Ｓ１０２）。ディレクトリサーバ１０は、仮想ディレ
クトリ上にファイル名とＵＲＬを追加する。

【００４１】図７は、ファイルの参照手順を示したシー
ケンス図である。先ず、利用者が自身のコンピュータ２
１のＷＷＷブラウザ上に表示されたディレクトリサーバ
１０の仮想ディレクトリ上のある登録ディレクトリ又は
そのディレクトリ内のファイルアイコンを選択すると
（Ｓ２０１）、図示しないディレクトリサーバ１０から
は対応するファイルのＵＲＬを使い且つＩＰパケットの
発信元をホストコンピュータ２１のＩＰアドレスに書き
換えたＨＴＴＰによるファイル要求メッセージが送信さ
れる（Ｓ２０２）。

【００４２】前記メッセージをファイル提供側のホスト
コンピュータ２２内のファイルサーバ２２−１が受信す
ると、自身のＵＲＬLとローカルパスのマッピング情報
を参照して公開ファイルを特定する。次に、ＨＴＴＰの
応答形式で利用者のホストコンピュータ２１へファイル
を直接送信する（Ｓ２０３）。

【００４３】図８は、ファイルの更新手順を示したシー
ケンス図である。先ず、利用者がファイルを取得して変
更する。次に、それを図示しないファイルサーバ２１−
１からの更新画面等を用いてファイルサーバ２１−１に
指示する（Ｓ３０１）。ファイルサーバ２１−１は更新
したファイルに対応するＵＲＬを新規に生成するか又は
既存のＵＲＬを更新する。ここで、ＵＲＬを新規に生成
する場合は、更新前のファイルを後で再利用することが
できる利点がある。

【００４４】次に、ファイルサーバ２１−１はディレク
トリサーバ１０に更新依頼を行なう（Ｓ３０２）。ディ
レクトリサーバ１０は、仮想ディレクトリ上の公開ファ
イルに登録されているＵＲＬを前記新規に公開したファ
イルのＵＲＬに置き換える。その結果、以降の公開ファ
イルは更新後のファイルとなる。

【００４５】図９は、ファイアウォールの外に存在する
ファイルの公開手順を示したシーケンス図である。ディ
レクトリサーバ１０はファイルを登録すると、自身のフ
ァイアウォールの外に存在する他のディレクトリサーバ
４６に対して１）ファイル名、２）ＵＲＬ、及び３）フ
ァイルを登録するディレクトリ、の情報を送信してファ
イル登録を依頼する（Ｓ４０１）。

【００４６】メッセージ中継サーバ３２がその依頼メッ
セージを受信し、それをメールに変換してファイアウォ
ールの外に存在する他のメッセージ中継サーバ３３宛に
送信する（Ｓ４０２）。この場合、送信メッセージには
転送元メッセージ中継サーバのメールアドレスが付加さ
れる。

【００４７】他のメッセージ中継サーバ３３は図示しな
いメールサーバ４５を経由してメッセージを受信し、元
のメッセージ形式に変換して自ファイアウォール内のデ
ィレクトリサーバ４６に転送する（Ｓ４０３）。これに
より、ディレクトリサーバ４６は、１）ファイル名、
２）ＵＲＬ、及び３）提供側メッセージ中継サーバ３３
のメールアドレスを仮想ディレクトリに追加する。

【００４８】図１０は、ファイアウォールの外に存在す
るファイル取得手順を示したシーケンス図である。先
ず、利用者が自身のコンピュータ２１のＷＷＷブラウザ
上に表示されたディレクトリサーバ１０の仮想ディレク
トリ上のある登録ディレクトリ又はそのディレクトリ内
のファイルアイコンを選択すると、図示しないディレク
トリサーバ１０は選択したファイルに対応するメールア
ドレスおよびＵＲＬによるＨＴＴＰ要求メッセージを作
成し、メッセージ中継サーバ３２に送信する（Ｓ５０
１）。

【００４９】メッセージ中継サーバは受信したＨＴＴＰ
メッセージをメール形式に変換し、メッセージ中のメー
ルアドレスに対して要求メッセージを送信する（Ｓ５０
２）。その要求メッセージはメールとしてファイアウォ
ールを通過し、提供側のメッセージ中継サーバ３３がそ
れを受信して再びＨＴＴＰ要求に変換して提供側のホス
トコンピュータ３４内のファイルサーバ３４−１へ送信
する（Ｓ５０３）。

【００５０】ファイル提供側のファイルサーバ３４−１
はＨＴＴＰ要求を受信すると、そのＵＲＬとローカルパ
スのマッピング情報とを参照して公開ファイルを特定す
る。特定された公開ファイルはＨＴＴＰの応答形式でメ
ッセージ中継サーバ３３に送信される（Ｓ５０４）。メ
ッセージ中継サーバ３３はそれをメール形式に変換して
要求側のメッセージ中継サーバ３２に送信する（Ｓ５０
５）。要求側のメッセージ中継サーバ３２はそれを元の
ＨＴＴＰ形式に変換して利用者のコンピュータ２１へ送
信する（Ｓ５０６）。

【００５１】図１１及び１２は、オフライン時のコンピ
ュータ上にあるファイルの得手順を示したシーケンス図
である。オフラインのコンピュータが保有するファイル
を取得する方法には、１）プロキシサーバ４３に残され
たキャッシュより取得する、及び２）バックアップサー
バ４２のファイルより取得する、の２通りの方法が存在
するが、ここでは後者２）の方法について述べる。

【００５２】図１１は、バックアップ手順を示したもの
で、ファイル公開時にディレクトリサーバ１０がバック
アップサーバ４２にファイルのバックアップを依頼し
（Ｓ６０１）、それを受けてバックアップサーバ４２が
サーバ内にファイルを保存し、それに対応する公開時の
ＵＲＬを生成してディレクトリサーバ１０に通知する
（Ｓ６０２）。これにより、ディレクトリサーバ１０は
当該ファイルのバックアップ参照用のＵＲＬを仮想ディ
レクトリ上に公開するか、又はファイル提供側のコンピ
ュータがオフラインの時にアクセスするため保持してお
く。

【００５３】図１２は、バックアップファイルの取得手
順を示しており、利用者がこれまで述べた通常の公開フ
ァイルの取得に失敗した場合（Ｓ７０１〜７０３）、利
用者は別の方法として上述したディレクトリサーバ１０
上のバックアップ用のＵＲＬにアクセスする（Ｓ７０
４）。ディレクトリサーバ４２は保存するＵＲＬをもと
にＨＴＴＰ要求を作成してバックアップサーバ４２へ送
信する（Ｓ７０５）。

【００５４】バックアップサーバ４２がＨＴＴＰ要求を
受信すると、そのＵＲＬとローカルパスのマッピング情
報とを参照してバックアップファイルを特定し、それを
ＨＴＴＰの応答形式で利用者のコンピュータ２１へ送信
する。なお、図示はしないがディレクトリサーバ１０が
何らかの手段で予めファイル提供側のホストコンピュー
タがオフラインであることを認識している場合には、デ
ィレクトリサーバ１０が保持するバックアップファイル
のＵＲＬを使って通常の手順でバックアップサーバ４２
から直接利用者のコンピュータ２１へ送信するようにし
てもよい。

【００５５】

【発明の効果】以上述べたように、本発明によればネッ
トワーク上の企業内又は企業間の複数の拠点間におい
て、個人ベースで互いにファイルを公開し、一対一でフ
ァイル交換をおこなうピアツーピア形式のファイル共有
システムを既存の技術を利用して容易に構築することが
できる。本発明によれば分散されたファイルの存在位置
を意識することなく、また常に最新のファイルが公開さ
れ、さらに共有ファイルの相互による更新も容易に行な
うことが可能となる。

【図面の簡単な説明】

【図１】本発明による分散ファイル共有システムの基本
構成例を図式的に示した図である。

【図２】仮想ディレクトリ内のホスト／ファイル情報と
ホストコンピュータ内のファイル実体との関連付けを示
した図である。

【図３】公開ファイルの登録画面の一例を示した図であ
る。

【図４】ファイアウォールを介したファイル取得の一構
成例を示した図である。

【図５】本発明による分散ファイル共有システムの一実
施例を示した図である。

【図６】ファイルの公開手順を示したシーケンス図であ
る。

【図７】ファイルの参照手順を示したシーケンス図であ
る。

【図８】ファイルの更新手順を示したシーケンス図であ
る。

【図９】ファイアウォールの外に存在するファイルの公
開手順を示したシーケンス図である。

【図１０】ファイアウォールの外に存在するファイルの
取得手順を示したシーケンス図である。

【図１１】オフライン時のコンピュータ上にあるファイ
ルのバックアップ手順を示したシーケンス図である。

【図１２】オフライン時のコンピュータ上にあるファイ
ルのバックアップファイル取得手順を示したシーケンス
図である。

【符号の説明】

１０、４６…ディレクトリサーバ １１、１２〜１５…仮想ディレクトリ ２１〜２３…ホストコンピュータ ２１−１、２２−１、３４−１…ファイルサーバ ３０、４０，４１…ファイアウォール ３１〜３４…公開ファイル ３２、３３…メッセージ中継サーバ ４２…バックアップサーバ ４３…プロキシサーバ ４４、４５…メールサーバ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B082 HA01 HA09 5B085 AA01 BG07

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ネットワークと、 それに接続されるローカルファイルを保有する複数のコ
   ンピュータ、及び前記各々のローカルファイルへそのア
   ドレス情報によってリンクされた仮想ディレクトリを表
   示するディレクトリサーバと、を備え、 前記仮想ディレクトリへのアクセスにより、そのアドレ
   ス情報から対応する前記複数のコンピュータのローカル
   ファイルが公開されることを特徴とする分散ファイル共
   有システム。
2. 【請求項２】 前記アドレス情報は、前記複数のコンピ
   ュータの内の１つを示すホスト情報とそのコンピュータ
   内のファイル位置情報とを含む、請求項１記載のシステ
   ム。
3. 【請求項３】 前記アドレス情報の書き換えにより、フ
   ァイル共有者の一人による公開ファイルの更新を可能と
   する、請求項１又は２記載のシステム。
4. 【請求項４】 さらに、ファイル公開に必要なメッセー
   ジをファイアウォールを介して通信するためのメッセー
   ジ変換サーバを含む、請求項１〜３のいずれか一つに記
   載のシステム。
5. 【請求項５】 さらに、前記複数のコンピュータのいず
   れかがオフラインの時に、それに代えて保存してある公
   開ファイルを公開するバックアップサーバを含む、請求
   項１〜４のいずれか一つに記載のシステム。