JP4497984B2 - ファイル共有制御システムおよび共有制御プログラム - Google Patents

ファイル共有制御システムおよび共有制御プログラム Download PDF

Info

Publication number
JP4497984B2
JP4497984B2 JP2004102455A JP2004102455A JP4497984B2 JP 4497984 B2 JP4497984 B2 JP 4497984B2 JP 2004102455 A JP2004102455 A JP 2004102455A JP 2004102455 A JP2004102455 A JP 2004102455A JP 4497984 B2 JP4497984 B2 JP 4497984B2
Authority
JP
Japan
Prior art keywords
file
information table
name
directory
mail
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004102455A
Other languages
English (en)
Other versions
JP2005292869A (ja
Inventor
昭男 作山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Japan Research Institute Ltd
Original Assignee
Japan Research Institute Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Japan Research Institute Ltd filed Critical Japan Research Institute Ltd
Priority to JP2004102455A priority Critical patent/JP4497984B2/ja
Publication of JP2005292869A publication Critical patent/JP2005292869A/ja
Application granted granted Critical
Publication of JP4497984B2 publication Critical patent/JP4497984B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は、電子メールを用いたファイルのバックアップおよびその共有を制御するシステム、共有制御サーバおよびプログラムに関する。
近年のコンピュータ機器の性能向上によりパーソナルコンピュータの小型化が進み、 オフィス内で使用されるパーソナルコンピュータが小型化しつつある。また、オフィススペースの制約により、使用されるパーソナルコンピュータも、デスクトップ型のものからノート型の物にシフトしつつある。さらにまた、当然のように、ローカルエリアネットワーク(LAN)によってネットワーク接続され、仕事の成果物である各種ファイル(ドキュメントファイルや表計算ソフトのデータファイル等)は、ファイルサーバーに格納するという業務運用が一般化してきている。
特開2003−296175号公報
しかしながら、ノート型のパーソナルコンピュータが利用されるようになってくると、つぎのような事態が多々発生するようになってきた。
(1)オフィス内のLAN接続できない場所での作業時にノート型パーソナルコンピュータ(以下、「ノートPC」とも称する。)をLANから切り離して移動し作業する。
(2)オフィス内にとどまらず、出先にもノートPCを持ち出して作業する。
このような利用方法を取る場合、以下のような作業方法をとるケースが頻繁に発生している。
タイプ1
業務に使用する各種のファイルはファイルサーバーから一旦ノートPCのローカルディスクにコピーして使用する。
作業終了後、ローカルディスクからファイルサーバーに書き戻す
タイプ2
新規に作成するファイルは、ローカルディスク内にて作成し、作業完了後ファイルサーバーに書き出す。
しかしながら、このような使用方法では、以下のようなトラブルが生じたときに、業務に必要とするファイルが永遠に失われてしまう事態となりかねない。
(1)使用しているノートPCが故障した場合
(2)誤操作により必要ファイルを削除してしまった場合
(3)ノートPCを紛失(盗難)した場合
上述した状況が発生する背景として、主として以下のような原因があると言われている。
(1)ファイルサーバーへのコピー作業が人間の手作業に依存している。
(2)ノートPCのローカルディスクのバックアップ手段になかなかよい物がない。
また、コストの問題と、使用場所を選ばなくても作業できるノートPCという特性上、 各ノートPCにバックアップ装置をつけるというのも現実的に無理という問題点もある。
その結果、一旦ノートPCに障害が発生した場合には、ファイルを復旧できないという致命的な事態となる確率が大きくなってきている。そして、コンピュータ性能の向上によりより大きなローカルディスクが標準的に装着されるようになってきており、その被害影響度合いはますます深刻度を増している。
また、システム設計などにおいて、1つのプロジェクトを複数人で実現することが一般化している。この場合、自己の担当箇所について、パーソナルコンピュータにて作業し、その成果物である各種ファイルを、サーバにも格納し、他の者がこれを閲覧し、場合によっては、更新できるようにしておく。
たとえば、特許文献1には、プロセス定義情報により、グループ名の羅列による処理経路が表わされ、あるグループが処理を終了すると、次のグループが処理を開始できるような協同作業支援システムが開示されている。しかしながら、各作業者が自由に作業を進めることで、全体を進行される場合には、上記システムを利用するのは困難である。また、予めプロセス定義情報を作成しておくという手順も必要となる。
本発明は、ユーザによる煩雑な操作なくメールを利用したファイルのバックアップができ、また、煩雑な操作なく、複数のコンピュータ間で、メールを利用してファイルを共有することができるシステムを提供することを目的とする。
本発明の目的は、自己が所有するファイルが格納されたディレクトリパス、所有ディレクトリ名を含むレコードを格納する所有ディレクトリ情報テーブル、メールの添付ファイルとして送信すべきファイルの所有者を示す所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値を含むレコードを格納するアップロードキュー情報テーブル、記憶装置に記憶されたファイルを管理するファイル管理手段であって、ファイルの作成、変更を検知し、作成、変更されたファイルに関するレコードを、前記アップロードキュー情報テーブルに格納するローカルファイル管理手段、および、前記アップロードキューテーブルのレコードに基づき、前記所有ノード名、ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値とともに、前記ファイルを添付ファイルとしたメールを送信するローカルメール処理手段を有するクライアントコンピュータと、前記ローカルメール処理手段から送信されたメールを受信するセンターメール処理手段、前記ネットワークを介して、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づく、所有ノード名、および、所有ディレクトリ名を含むレコードを格納する所有者情報テーブル、前記所有ノード名、所有ディレクトリ名、ディレクトリパス、および、ファイル名を含むレコードを格納する実ファイル情報テーブル、ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを格納する実ファイル世代情報テーブル、並びに、前記センターメール処理手段により受理されたメールに添付されたファイルをデータベースに格納するとともに、実ファイル情報テーブル、および、実ファイル世代情報テーブルの該当レコードを更新するセンターファイル管理手段を有する制御サーバとを備えたことを特徴とするファイル共有制御システムにより達成される。
本発明によれば、ローカルファイル管理手段により検知され、作成され、更新されたファイルおよび当該ファイルに関する情報が、メールにて制御サーバに送られ、制御サーバに保管される。これにより、ユーザが煩雑な操作をすることなく、ファイルのバックアップ(制御サーバへのファイルのアップロード)や、バックアップされたファイルの取得(制御サーバからのファイルのダウンロード)を実現することができる。
好ましい実施態様においては、さらに、クライアントコンピュータが、利用したいファイルを所有する他のクライアントコンピュータの利用ノード名、前記利用したいファイルの所有ノード名、利用ディレクトリ名を含むレコードを有する利用ディレクトリ情報テーブルを有し、前記制御サーバが、前記ローカルメール処理手段から送信され、前記センターメール処理手段により受信されたメールに基づく、利用したいファイルの所有者のノード名、利用ディレクトリ名を含むレコードを格納する利用者情報テーブルを有し、前記ファイル管理手段が、前記ローカルメール手段から送信され、センターメール処理手段により受信されたメールに基づく、所有ノード名、利用ディレクトリ名にしたがって、前記メールに添付されたファイルをデータベースに格納するとともに、前記実ファイル情報テーブル、および、前記実ファイル世代情報テーブルを更新し、前記センターメール処理手段が、前記所有ノード名、前記利用ディレクトリ情報テーブル中、前記所有ノード名および利用ディレクトリ名を含むレコードの他の利用ノード名により特定されるクライアントコンピュータに、前記ファイルを添付したメールを送信する。
本実施の形態によれば、クライアントコンピュータにおいて、他のクライアントコンピュータが所有するファイル中、利用したいものの情報を、利用ディレクトリ情報テーブルのレコードとして用意しておけば、他のクライアントコンピュータが所有するファイルを、利用者が共有することが可能となる。
より好ましい実施態様においては、前記所有ディレクトリテーブルのレコードが、ファイルの公開の可否を示す公開フラグ、公開が可能である場合のファイルの更新の可否を示す公開タイプ情報を含み、前記所有者情報テーブルが、前記公開フラグおよび公開タイプ情報を含み、前記ファイル管理手段が、前記所有者情報テーブルの、公開フラグおよび公開タイプ情報を参照して、前記ファイルのDBへの格納の可否を判断する。
たとえば、ファイルの内容を示す情報は、ファイルのハッシュ値であり、センターファイル管理手段が、ハッシュ値を比較することにより、ファイルの内容の一致を判断する。
別の好ましい実施態様においては、さらに、クライアントコンピュータが、所定のタイミングで、所有ノード名、所有ディレクトリ名、ファイル名、ファイルの内容を示す値、タイムスタンプを含む情報を収集する同期処理手段を有し、前記ローカルメール処理手段が、前記同期処理手段が収集した情報を含むメールを、前記制御サーバに送信し、前記制御サーバは、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づき、前記ファイルを添付したメールのクライアントコンピュータへの送信、或いは、前記クライアントコンピュータに対する、前記ファイルを添付したメールの送信要求の必要性を判断するセンター同期処理手段を有する。
また、本発明の目的は、上述した構成のファイル共有制御システムにおいて、自己が所有するファイルが格納されたディレクトリパス、所有ディレクトリ名を含むレコードを格納する所有ディレクトリ情報テーブル、および、メールの添付ファイルとして送信すべきファイルの所有者を示す所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値を含むレコードを格納するアップロードキュー情報テーブルを備えたクライアントコンピュータにより読み出し可能なファイル共有制御プログラムであって、前記クライアントコンピュータを、記憶装置に記憶されたファイルを管理するファイル管理手段であって、ファイルの作成、変更を検知し、作成、変更されたファイルに関するレコードを、前記アップロードキュー情報テーブルに格納するローカルファイル管理手段、並びに、前記アップロードキューテーブルのレコードに基づき、前記所有ノード名、ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値とともに、前記ファイルを添付ファイルとしたメールを送信するローカルメール処理手段として機能させることを特徴とするファイル共有制御プログラムによっても達成される。
さらに、本発明の目的は、上記構成のファイル共有制御システムにおいて、前記ネットワークを介して、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づく、所有ノード名、および、所有ディレクトリ名を含むレコードを格納する所有者情報テーブル、前記所有ノード名、所有ディレクトリ名、ディレクトリパス、および、ファイル名を含むレコードを格納する実ファイル情報テーブル、並びに、ファイル名、ファイルのタイムスタンプ、ファイルの内容を示す情報を含むレコードを格納する実ファイル世代情報テーブルを有する制御サーバにより読み出し可能なファイル共有制御プログラムであって、前記制御サーバを、前記ローカルメール処理手段から送信されたメールを受信するセンターメール処理手段、並びに、前記センターメール処理手段により受理されたメールに添付されたファイルをデータベースに格納するとともに、実ファイル情報テーブル、および、実ファイル世代情報テーブルの該当レコードを更新するセンターファイル管理手段として機能させることを特徴とするファイル共有制御プログラムによっても達成される。
本発明によれば、ユーザによる煩雑な操作なくファイルのバックアップができ、また、煩雑な操作なく、複数のコンピュータ間で、ファイルを共有することができるシステムを提供することが可能となる。
以下、添付図面を参照して、本発明の実施の形態について説明する。図1は、本発明の実施の形態にかかるファイルバックアップ・共有制御サーバ(以下、「制御サーバ」或いは場合によって「センターコントローラ」と称する。)を含むシステム全体の構成を示すブロックダイヤグラムである。図1に示すように、ファイルバックアップ・共有制御サーバ10と、複数のクライアント・パーソナルコンピュータ(以下、「クライアントPC」或いは場合によって「ノード」と称する)12−1、12−2、・・・、12−nは、ネットワーク14を介して接続可能となっている。また、ネットワーク14には、制御サーバ10におけるファイルバックアップやファイル共有の処理について、クライアントPCに通知するメールサーバ16が接続されていても良い。本実施の形態において、ネットワークとして、TCP/IPを利用しているが、これに限定されるものではなく、任意の有線或いは無線のネットワークを利用することができる。
図2(a)に示すように、制御サーバ10は、後述するオンラインノード管理テーブル200、所有者パス(path)情報テーブル201、実ファイル情報テーブル202、実ファイル世代情報テーブル203、および、利用者情報テーブル204を含むデータベース20を有する。また、制御サーバ10は、ファイルの同期に関する処理を実行する同期処理部(センター同期判断部)22と、ファイルの読み出し/書き込みおよび送信/受信を管理するファイル管理部(センターファイル管理部)24と、クライアントマシン12との間のメール送受信を制御するメール処理部(センターメール処理部)26とを有している。同期処理部22、ファイル管理部24およびメール処理部26の機能は、制御サーバ10のメモリなどの記憶装置に記憶されたエージェントプログラム(以下、単に「エージェント」と称する。)により実現される。
図2(b)に示すように、各クライアントPC12の記憶装置30には、ノード基本情報テーブル211、所有ディレクトリ情報テーブル212、利用ディレクトリ情報テーブル213、ローカル情報テーブル214およびアップロードキュー情報テーブル215が記憶される。また、各クライアントPC12は、ファイルの同期に関する処理を実行する同期処理部(ローカル同期処理部)32、ファイルをアップロード或いはダウンロードするファイル管理部(ローカルファイル管理部)34、制御サーバ10との間のメール送受信を制御するメール処理部(ローカルメール処理部)36を備えている。記憶装置32には、エージェント(図示せず)が記憶されており、同期処理部32、ファイル管理部34、および、メール処理部36の機能は、エージェントにより実現される。
本実施の形態においては、クライアントPC(たとえば、クライアントPC12−1)が、自己の所有するディレクトリのファイルを、制御サーバ10にバックアップすることができる。このように、ファイルを所有する側のものを、本明細書において「所有者」とも称する。また、本実施の形態においては、クライアントPC12−1が、他のクライアントPC(たとえば、クライアントPC12−2)が所有者であるようなディレクトリのファイルを閲覧し、或いは、作成、変更することも可能である。このように、他のクライアントPCが所有するファイルを利用する者(たとえば、クライアントPC12−2)を、本明細書において、「利用者」とも称する。
図3は、ノード基本情報テーブル211のデータ構成を示す図である。図3に示すように、ノード基本情報テーブル211は、項目として、「自ノード名」、「ノード識別コード」、「PGP暗号Passフェーズ」、「センター電子メールアドレス」、「ユーザタイプ」、「SMTPサーバ名」、「自動受信用メールサーバ名」、「通知受信用電子メールアドレス」、「ファイル受信用電子メールアドレス」、「ファイル受信用アカウント」、「ファイル受信用パスワード」、「メール自動発信時アドレス」、「センターコントローラID」、「アップロード/ダウンロード作業ディレクトリ」および「前回SyncCheck(同期チェック)日時」を含む。ノード基本情報テーブルには、クライアントPC(以下、「ノード」とも称する。)12が、制御サーバ(以下、「センターコントローラ」とも称する。)10にアクセスし、或いは、メールを送受信する際の基本的な情報が含まれる。
図4は、所有ディレクトリ情報テーブル212のデータ構成を示す図である。図4に示すように、所有ディレクトリ情報テーブル212のレコードは、項目として、「所有ディレクトリPath(パス)」、「削除フラグ」、「所有ディレクトリ呼称」、「センター通知FLG(フラグ)」、「センター受領FLG(フラグ)」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」、および、「通知メール受信タイプ」を含む。を含む。
所有ディレクトリ情報テーブルのレコードは、クライアントPC(たとえば、クライアントPC12−1)が所有する一群のファイルを特定するための情報である。たとえば、「所有ディレクトリPath」および「所有ディレクトリ呼称」により特定されるディレクトリに属するファイル群を特定することができる。「公開フラグ」が「ON」である場合には、そのファイル群は、他のクライアントPC(たとえば、クライアントPC12−2)と共有することができる。
また、「削除FLG」は、ディレクトリの所有者によってディレクトリが削除された場合に、「ON」となる。
「センター通知FLG」は、所有ディレクトリの通知、つまり、当該レコードの情報を、センターコントローラにメールにて通知しているか否かを示す。また、「センター受領FLG」は、通知に対する登録確認を受領しているか否かを示す。
図5は、利用ディレクトリ情報テーブル213のデータ構成を示す図である。図5に示すように、利用ディレクトリ情報テーブル213のレコードは、項目として、「所有者ノード名」、「所有者ディレクトリ呼称」、「公開パスワード」、「更新可否FLG」、「ファイル格納先基準ディレクトリPath(パス)」、「センター通知FLG」および「センター受領FLG」を含む。「所有者ノード名」および「所有ディレクトリ呼称」により、クライアントPC(たとえば、クライアントPC12−1)が、ファイルの共有を希望する他のクライアントPC(たとえば、クライアントPC12−2)のファイル群が特定される。「公開パスワード」により、そのファイル群の共有が許可される。また、「ファイル格納先基準ディレクトリパス」により、クライアントPC(たとえば、クライアントPC12−1)が、他のクライアントPC(たとえば、クライアントPC12−2)から共有を希望するファイル群をダウンロードした際の、クライアントPC(たとえば、クライアントPC12−1)における格納場所が特定される。「更新可否FLG」は、そのディレクトリのファイルが更新可であるか更新不可であるかが示される。
「センター通知FLG」は、利用ディレクトリの通知、つまり、当該レコードの情報を、センターコントローラにメールにて通知しているか否かを示す。また、「センター受領FLG」は、通知に対する登録確認を受領しているか否かを示す。
図6(a)は、ローカルファイル情報テーブル214のデータ構成を示す図である。図6(a)に示すように、ローカルファイル情報テーブル214のレコードは、項目として、「所有者ノード名」、「所有ディレクトリ呼称」、「ローカル相対Path(パス)」、「ファイル名」、「ファイルハッシュ値」、「タイムスタンプ」、「ファイルサイズ」および「アップロード検知作業中FLG」を含む。
「ローカル相対Path」は、所有ディレクトリや利用ディレクトリとして指定したローカルディスク内のPathを基準とした相対Pathであり、これにより、ファイルの記憶装置30中の格納位置を特定することができる。「ファイルハッシュ値」は、ファイルのMD5ハッシュ値である。ローカルファイル情報テーブルのレコードは、クライアントPCの記憶装置30(ローカルディスク)に保管されるファイルの情報を示す。この情報を使用して、アップロードすべきファイルが判断される。
図6(b)は、アップロードキュー情報テーブル215のデータ構成を示す図である。図6(b)に示すように、アップロードキュー情報テーブル215のレコードは、項目として、「アップロード検知日時」、「所有ノード名」、「所有ディレクトリ呼称」、「ファイル名」、「ファイルハッシュ値」、「タイムスタンプ」、「ファイルサイズ」、「削除FLG(フラグ)」、「センターアップロードFLG」および「ファイル別名」を含む。「削除FLG」は、ファイルが記憶装置30(ローカルディスク)から削除されているか否かを示す。また、「センターアップロードFLG」は、ファイルを制御サーバにアップロード済みか否かを示す。
図7は、オンラインノード管理テーブル200のデータ構成を示す図である。図7に示すように、オンラインノード管理テーブルのレコードは、項目として、「ノード名」、「仮登録FLG(フラグ)」、「ノード識別コード」、「ユーザタイプ」、「ノード発信電子メールアドレス」、「通知用電子メールアドレス」、「ファイル受信用電子メールアドレス」、「ノード登録日」、「受信頻度タイプ」および「ノード登録申請者名」を含む。このレコードに含まれる項目の値により、制御サーバ10は、ネットワーク14を介して接続したクライアントPC12を特定することができる。
図8は、所有者情報テーブル201のデータ構成を示す図である。図8に示すように、所有者パス情報テーブル210のレコードは、項目として、「ノード名」、「所有ディレクトリ呼称」、「削除FLG(フラグ)」、「削除日時」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」および「通知メール受信タイプ」を含む。
このレコードは、クライアントPC12の所有ディレクトリ情報テーブル212のレコードが、制御サーバ10に登録される際に新規に作成される。したがって、「ノード名」は、クライアントPCのノード名に相当し、また、所有者パス情報テーブルのレコード中、「削除FLG」、「所有ディレクトリ呼称」、「最大保存世代数」、「削除ファイル保存期間」、「公開フラグ」、「公開パスワード」、「公開タイプ」、「通知メール受領フラグ」および「通知メール受信タイプ」の値が、所有ディレクトリ情報のレコード中、対応する項目の値として格納される。
図9(a)は、利用者情報テーブル204のデータ構成を示す図である。図9(a)に示すように、利用者情報テーブル204のレコードは、項目として、「利用ノード名」、「所有ノード名」、「利用ディレクトリ呼称」および「削除フラグ」を有する。これらは、利用者であるクライアントPCを特定する情報である。「利用ノード名」は、利用者のクライアントPCのノード名に相当し、「所有ノード名」は、利用者が利用するファイルやディレクトリの所有者のノード名を示す。「削除フラグ」は、利用者によってディレクトリが削除されたか否かを示す。
図9(b)は、実ファイル情報テーブル202のデータ構成を示す図である。図9(b)に示すように、実ファイル情報テーブル202のレコードは、項目として、「所有ノード名」、「所有ディレクトリ呼称」、「相対Path(パス)」、「実ファイル名」、「サーバファイル名」および「削除フラグ」を有する。「所有ノード名」は、クライアントPC12のノード名に対応し、「所有ディレクトリ呼称」は、所有ディレクトリ情報テーブルのレコード中、「所有ディレクトリ呼称」に対応する。「相対Path」は、ファイルが、クライアントPC12において、所有ディレクトリ内のサブディレクトリに格納されている場合の、所有ディレクトリからの相対パスを示す。また、「サーバファイル名」は、当該ファイルを制御サーバ10において格納する場合のファイル名である。この実ファイル情報テーブル202のレコードにより、クライアントPC12中のファイルを特定することができる。
図9(c)は、実ファイル世代情報テーブル203のデータ構成を示す図である。図9(c)に示すように、実ファイル世代情報テーブル203のレコードは、項目として、「サーバファイル名」、「登録日時」、「登録ディレクトリ」、「登録ノード名」、「格納ファイルサイズ」、「ファイルサイズ」、「ハッシュ値」、「圧縮後ハッシュ値」および「タイムスタンプ」を有する。「登録日時」は、ファイルが制御サーバ10の記憶装置に格納された日時に相当する。「登録ディレクトリ」は、制御サーバ10にファイルを格納するときのパスに相当する。制御サーバ10は、記憶装置に、格納ファイル情報テーブル(図示せず)を記憶しておく。この格納ファイル情報テーブルのレコードには、クライアントPC12からアップロードされたファイルを、制御サーバ10にて保存する、記憶装置内のディレクトリパスに相当する「ファイルバックアップ基準Path(パス)」が含まれる。登録ディレクトリは、格納ファイル情報テーブルの何れかのレコードの値と一致する。
次に、本システムを構成するクライアントPCを利用するユーザのタイプについて説明する。利用者のネットワーク環境(特に電子メール環境)をから分類すると、以下の2つのタイプにユーザを分けることができる。
タイプ1:ファイル送受信専用アカウント可の環境、つまり、ローカルファイルのアップロード/センターコントローラからのダウンロードは全てバックグラウンドで自動に行われる環境
タイプ2:ファイル送受信専用アカウント不可の環境、つまり、ローカルファイルのアップロードは全てバックグラウンドで自動的に行われるが、ダウンロード用のメールアドレスを利用できない為、通常のメールと同じメールアドレスに送付する環境
また、本システムにおいては、クライアントPCの記憶装置のディレクトリ(ローカルディレクトリ:サブディレクトリも含む)のファイルを、センターコントローラ上にディレクトリ呼称として登録し、ネットワーク内に、非公開、公開(更新不可)或いは公開(更新可)として利用する形をとる。この場合に、ディレクトリの所有者と、ディレクトリの利用者という2つの形態で利用方法を使い分ける。
ディレクトリ所有者は、そのローカルディレクトリ内にファイルを作成・修正・削除する事が出来る。センターコントローラにディレクトリ呼称として登録したディレクトリ(サブディレクトリも含む)内のファイルに対するその変更(新規・修正・削除)内容は、 センターコントローラ側に自動的にアップロードされ、センターコントローラにおいて、履歴管理される。また、そのディレクトリ呼称毎に、以下の定義が可能である。
(1)利用者からは見えない(非公開):(ローカルディスクのバックアップ)
(2)利用者からは参照のみ可(公開・更新不可):ファイルの自動配布
(3)利用者が新規・修正・削除できる(公開・更新可):共同作業によるファイルの作成
また、ディレクトリ利用者は、ネットワーク内に公開されたディレクトリ呼称を使用する場合、利用ディレクトリとして登録することにより、そのディレクトリ呼称の情報を自動的にダウンロード(さらには、ディレクトリが更新可であれば自動的にアップロード)することが出来る。
次に、ファイルの受信タイプについて説明する。本システムでは、クライアントPCがファイルを受取る場合に、以下の2つの形態をサポートすることができる。
(1)ファイル受信用の専用メールアカウントが使用できる環境(ユーザタイプ=1)
(2)通常の電子メールアカウントでファイルを受信できる環境(ユーザタイプ=2)
ファイル受信用の専用メールアカウントが使用できる環境においては、クライアントPCにインストールされたプログラム(メール処理部)が、定期的にメールサーバ(図示せず9に対して受信チェックし、メールが受信していた場合は、クライアントPCにダウンロードし、暗号を復号化して所定のディレクトリにファイルを格納する。
その一方、通常の電子メールアカウントでファイルを受信できる環境では、クライアントPC側にダウンロードするために、利用者が普段使用する電子メールソフトを利用する。ファイルが添付されたメールは電子メールソフト上では通常の添付ファイルとして認識されるが、拡張子を特殊なものに設定して、マウスによるダブルクリックなどによって、拡張子対応のプログラムの自動起動機能によりファイルの複号化、所定のディレクトリへの保存が自動で行えるようにする。
この2の環境を使い分ける事により利用者が使用できる環境に合わせたファイル受信が可能となる。
次に、ファイル送信タイプについて説明する。本システムでは、クライアントPC側からファイルを送信する場合、以下の形態をサポートする。
クライアントPC側でファイル送信の必要性(新規/変更/削除ファイルが発生)な時に自動的に、対象ファイルを暗号化してセンターコントローラ宛の電子メールとして送信する。ただし、但し、送信処理は、ネットワークに接続し、SMTPサーバ(図示せず)との通信が可能な場合にのみ実行される。
その結果、以下の2つのユーザをサポートすることが可能である。
(1)ネットワークに常時接続して利用しているユーザ
(2)ネットワークには必要な時のみ接続しているユーザ
上述したように構成されたクライアントPC12および制御サーバ10における処理について以下に説明する。
まず、クライアントPC12から制御サーバ10への初期的な基本情報の登録処理について簡単に説明する。
初期作業として、クライアントPC12のメール処理部36は、以下の情報を添付ファイルとして、制御サーバ10に送信する。
自ノード名
ユーザタイプ
PGP暗号Passフェーズ
センター電子メールアドレス
SMTPサーバ名
メールサーバ名
通知受信用電子メールアドレス
ファイル受信用電子メールアドレス
ファイル受信用アカウント
ファイル受信用パスワード
メール自動発信時電子メールアドレス
アップロード/ダウンロード作業ディレクトリPath
ここで、「ユーザタイプ」とは、前述した利用者のネットワーク環境、つまり、
タイプ1:ファイル送受信専用アカウント可の環境、つまり、ローカルファイルのアップロード/センターコントローラからのダウンロードは全てバックグラウンドで自動に行われる環境
タイプ2:ファイル送受信専用アカウント不可の環境、つまり、ローカルファイルのアップロードは全てバックグラウンドで自動的に行われるが、ダウンロード用のメールアドレスを利用できない為、通常のメールと同じメールアドレスに送付する環境
のいずれかである。
上記以外の情報は、基本的に、クライアントPC12のノード基本情報テーブル211に格納しておいたものに相当する。管理サーバ10は、ネットワーク14を介して受信した情報を、オンラインノード管理テーブルのレコードなどに格納しておく。
次に、所有ディレクトリの登録および利用ディレクトリの登録について説明する。
ユーザは、クライアントPC12を操作して、所有ディレクトリ情報テーブル212のレコードに値を格納しておく。クライアントPC12のメール処理部36は、所有ディレクトリ情報テーブル212を読み出して、これを添付ファイルとしたメールを、制御サーバ10に送信する。制御サーバ10は、受信したファイルの情報を、所有者情報テーブル201のレコードとして格納し、その後、登録完了メールを、クライアントPC12に送信する。
クライアントPC12のメール処理部36は、登録完了メールを受信すると、所有ディレクトリ情報テーブル212の該当レコード中、「センター受領FLG」を「ON」にする。
利用ディレクトリの登録についても同様の手順で実現できる。
次に、本実施の形態にかかるクライアントPCにおけるファイルのアップロードおよびダウンロードの基本的な流れについて説明する。図10は、制御サーバ10をファイルバックアップ装置として利用する例を示す。クライアントPC12−1が、制御サーバ10の所有者情報テーブル201にその情報を登録したディレクトリのファイルを作成、更新すると(ステップ1001)、作成、更新にかかるファイルを添付したメールが制御サーバ10に送信される(ステップ1002)。制御サーバ10は、作成、変更されたファイルを履歴として格納する(ステップ1003)。これにより、ファイルのアップロードが実現できる。また、クライアントPC12−1の要求などにしたがって、制御サーバ10から、ファイルが添付されたメールが送信される(ステップ1004)。これにより、ファイルのアップロードが実現される。
図11は、ファイルを共有する例を示す図である。まず、所有者であるクライアントPC12−1が、制御サーバ10の所有者情報テーブル201に情報を登録しておく。この際に、「公開フラグ=公開」、「公開タイプ=更新可」としておく(ステップ1101)。また、他のクライアントPC12−2等は、制御サーバ10の利用者情報テーブル204に、所有者のディレクトリの利用を登録しておく。これにより、他のクライアントPC12−2等は、そのディレクトリのファイルを更新等することが可能となる(ステップ1102)。クライアントPC12−2によりファイルが更新されると、他のクライアントPC(クライアントPC12−1、12−3など)には、更新されたファイルが添付されたメールが送信される(ステップ1103)。このようにしてファイルの共有が実現できる。
以下、より具体的に、クライアントPC12における処理、制御サーバ10における処理、および、クライアントPC12と制御サーバ10との間の処理について説明する。
まず、クライアントPC12における、制御サーバ10にアップロードすべきファイルの検知処理について説明する。
図12に示すように、クライアントPCのファイル管理部34は、一定間隔ごとに、所有ディレクトリ情報のレコードごとに、当該所有ディレクトリPath内の全てのファイルに関して、以下のチェックを実行する。
(1)ローカルファイル情報テーブルのアップロード検知作業中FLGを全てONに変更する(ステップ1201)。
(2)所有ディレクトリ情報の所有ディレクトリPath配下(サブディレクトリを含む)の全ファイルについて以下の処理を行う。
A.ローカルファイル情報テーブル内にPath,ファイル名が同じものが存在するかチェックする(ステップ1202)。
B.存在しない場合には(ステップ1202でノー(No))、
a)ローカルファイル情報テーブルに,以下のレコードを追加する(ステップ1203)。
所有者ノード名=自ノード名
所有ディレクトリ呼称 =所有ディレクトリ情報テーブルの所有ディレクトリ呼称
ファイル名=該当ファイルのファイル名
ファイルハッシュ値=該当ファイルのMD5ハッシュ値
タイムスタンプ=該当ファイルのタイムスタンプ
ファイルサイズ=該当ファイルのファイルサイズ
ローカルPath=所有ディレクトリを基準とした相対Path
b)基本情報ファイルテーブルのアップロード/ダウンロード作業ディレクトリに該当ファイルをコピーする(ステップ1204)。なお。コピー先のファイル名はユニークに採番されたファイル名とする。
c)アップロードキュー情報テーブルに、以下のレコードを追加する(ステップ1205)。
アップロード検知日時=該当ファイルを見つけたマシン日時
所有ディレクトリ呼称=所有ディレクトリ情報テーブルの所有ディレクトリ呼称
ファイル名=該当ファイルのファイル名
ファイルハッシュ値=該当ファイルのMD5ハッシュ値
タイムスタンプ=該当ファイルのタイムスタンプ
ファイルサイズ=該当ファイルのファイルサイズ
削除FLG=OFF
アップロード通知メールFLG=OFF
センターアップロードFLG=OFF
ファイル別名=コピー後のファイル名
d)ローカルファイル情報の該当レコードのUpload検知作業中FLGをOFFに変更する(ステップ1206)。
C.存在する場合には、
a)ローカルファイル情報テーブルに登録されているタイムスタンプと該当ファイルのタイムスタンプをチェックする(ステップ1207)。
b)タイムスタンプが同じである場合(ステップ1207でイエス(Yes))
ローカルファイル情報テーブルのアップロード検知作業中FLGをOFFに変更する(ステップ1206)。その後、次のファイルのチェックに進む
c)タイムスタンプが異なる場合(ステップ1207でノー(No))
該当ファイルのMD5ハッシュ値を算出する。
ローカルファイル情報のファイルハッシュ値を算出したMD5ハッシュ値を比較する(ステップ1208)。
ハッシュ値が同じである場合には(ステップ1208でイエス(Yes))、ローカルファイル情報のアップロード検知作業中FLGをOFFに変更し(ステップ1206)、次のファイルのチェックに進む。
その一方、ハッシュ値が異なる場合には、基本情報ファイルテーブルのアップロード/ダウンロード作業ディレクトリに該当ファイルをコピーする(ステップ1209)。なお、コピー先のファイル名はユニークに採番されたファイル名とする。
次いで、アップロードキュー情報テーブルに、以下のレコードを追加する(ステップ1210)。
アップロード検知日時=該当ファイルを見つけたマシン日時
所有ディレクトリ呼称=所有ディレクトリ情報テーブルの所有ディレクトリ呼称
ファイル名=該当ファイルのファイル名
ファイルハッシュ値=該当ファイルのMD5ハッシュ値
タイムスタンプ=該当ファイルのタイムスタンプ
ファイルサイズ=該当ファイルのファイルサイズ
削除FLG=OFF
アップロード通知メールFLG=OFF
センターアップロードFLG=OFF
ファイル別名=コピー後のファイル名
この後、ローカルファイル情報テーブルの該当レコードのアップロード検知作業中FLGをOFFに変更する(ステップ1206)。
この処理では、基本的には、新たにファイルが作成され、或いは、更新されている場合には、アップロード/ダウンロード作業ディレクトリに、そのファイルがコピーされ、また、ファイルの情報のレコードが、アップロードキューテーブルに追加される。
また、全てのファイルについて処理を実行し終わった状態で、ローカルファイル情報テーブル内にアップロード検知作業中FLGがONのレコードが残っている場合もある(図13のステップ1300でイエス(Yes))。これは、ファイルが削除してしまった場合に相当する。ファイルの削除を考慮して、ファイル管理部34は、図13に示す処理を実行する。
A.まず、ファイル管理部34は、アップロードキュー情報テーブルに、以下のレコードを追加する(ステップ1301)。
アップロード検知日時=マシン日時
所有者ノード名=自ノード名
所有ディレクトリ呼称=ローカルファイル情報の所有ディレクトリ呼称
ファイル名=ローカルファイル情報のファイル名
ファイルハッシュ値=ローカルファイル情報のMD5ハッシュ値
タイムスタンプ=ローカルファイル情報のタイムスタンプ
ファイルサイズ=ローカルファイル情報のファイルサイズ
削除FLG=ON
アップロード通知メールFLG=OFF
センターアップロードFLG=OFF
ファイル別名=未登録
B.次いで、ローカルファイル情報テーブルの該当レコードを削除する(ステップ1302)。
後述するように、アップロードキュー情報テーブルに、ファイルが削除されたことを示すレコードを格納し、このレコードが制御サーバ10に伝達されることにより、制御サーバ10においても、ファイルが削除されたことを把握できる。
利用ディレクトリ情報テーブルのレコード中の、ファイル格納ローカルPath(サブディレクトリも含む)の全てのファイルについて、図12および図13に示すものと同等の処理を実行することにより、作成、更新されたファイルや削除されたファイルを検出することができる。
次に、クライアントPC12から制御サーバ10へのファイルのアップロード処理について説明する。クライアントPC12のファイル管理部34は、一定時間ごとに、アップロードキュー情報テーブルを参照して、レコード中、センターアップロードFLGがOFFであるレコードが存在するか否かを判断する。センターアップロードFLGがOFFであるレコードが存在する場合には、ファイル管理部34が必要な情報を収集し、メール処理部36が、収集された情報やファイルを添付したメールを、制御サーバ10に送信する。
図14に示すように、まず、アップロードメール用の制御ファイルが生成される(ステップ1401)。制御ファイルには以下の情報が含まれる。
情報数:1つのメールに幾つのファイルに関する情報が入っているかを示す(基本的には「1」をセットする)。
メールタイプ:アップロードメールである事をキーワード(例えばUPLOAD)
アップロードノード名:基本情報テーブル中の自ノード名
アップロードノード識別コード:基本情報テーブル中の自ノード識別コード
所有ノード名:ローカルファイル情報テーブル中の該当項目
所有ディレクトリ呼称:ローカルファイル情報テーブル中の該当項目
ファイル名:ローカルファイル情報テーブル中の該当項目
ファイルハッシュ値:ローカルファイル情報テーブル中の該当項目
ファイルタイムスタンプ:ローカルファイル情報テーブル中の該当項目
ファイルサイズ:ローカルファイル情報テーブル中の該当項目
相対Path:ローカルファイル情報テーブル中のローカル相対Path
ファイルハッシュ値:ローカルファイル情報テーブルの該当項目
ファイル別名:アップロードキュー情報テーブル中の該当項目
次いで、アップロードメール用メールファイルが作成される(ステップ1402)。ここでは、ステップ1401で作成されたアップロードメール用の制御ファイル、および、該当するローカルファイル情報テーブルのファイル別名で特定されるファイルをアーカイブファイルとして圧縮する。ただし、ローカルファイル情報テーブルのレコードにおいて、削除FLG=ONの場合には、実ファイルはアーカイブされない。
圧縮されたファイルが暗号化される(ステップ1403)。暗号化には、たとえば、PGPの鍵方式が利用される。
次いで、メール処理部36は、生成されたアップロードメールを、ノード基本情報テーブルに記載されたセンター電子メールアドレス宛に送信する(ステップ1404)。なお、ここでは、発信者は、ノード基本情報テーブルに記載された通知受信用電子メールアドレスとする。
その後、アップロードキュー情報テーブルの該当レコード中、センターアップロードFLGがONされる(ステップ1405)。
次に、クライアントPC12から送信されたメールを受信した制御サーバ10のメール処理部26およびファイル管理部24の処理について、図15を参照して説明する。
まず、メール処理部26が受信したメールの送信元電子メールアドレスを抽出し、ファイル管理部24が、オンラインノード管理テーブルを参照して、送信元のノード名などを特定する(ステップ1501)。より具体的には、オンラインノード管理テーブルから以下の情報が抽出される。
ノード名
仮登録FLG
ノード識別コード
通知用電子メールアドレス
ファイル受信用電子メールアドレス
次いで、メール処理部26においてメールが復号化される(ステップ1502)。復号化された制御ファイルから、ファイル名等から特定されるレコードが、実ファイル情報テーブル中に存在するか否かを判断する(ステップ1503)。存在しない場合には(ステップ1503でノー(No))、実ファイル情報テーブルおよび実ファイル世代情報テーブルの新たなレコードを作成するとともに(ステップ1504)、ファイルをDB20中の所定の領域に記憶する(ステップ1505)。
レコードが実ファイル情報テーブル中に存在する場合には(ステップ1503でイエス(Yes))、ファイル管理部24は、実ファイル世代情報の該当レコードを参照して、同一ハッシュ値のレコードが存在するか否かを判断する(ステップ1506)。存在しない場合(ステップ1506でノー(No))には、実ファイル世代情報に新たなレコードを追加するとともに(ステップ1507)、ファイルをDB20中の所定の領域に記憶する(ステップ1508)。
このような処理の後、アップロードメールを送信してきたクライアントPC12に、アップロード完了通知メールが送信される(ステップ1509)。
さらに、ファイル管理部24は、利用者ディレクトリ情報テーブルを参照して、メール送信されたファイルのノード名、ディレクトリ名と同一のノード名(所有ノード名)、ディレクトリ名(利用ディレクトリ名)を含むレコードが存在するか否かを判断する(ステップ1510)。存在する場合(ステップ1510でイエス(Yes))、当該レコード中の利用ノード名に基づき、利用者を特定して、メール処理部26が、そのクライアントPC宛(ファイル受信用電子メールアドレス宛)に、ダウンロードメールを作成して送信する。(ステップ1511)。
アップロード完了通知のメールを受信したクライアントPC12においては、アップロードキュー情報テーブル中の該当レコードが削除され、また、当該削除されるレコード中のファイル別名を持つファイルが、アップロード/ダウンロード作業ディレクトリから削除される。
なお、上述した説明においては、所有者のクライアントPC(たとえば、クライアントPC12−1)においてファイルが作成、変更され、そのファイルがアップロードされる例を示した。これに加えて、所有者のディレクトリが公開可でかつ更新可であれば、利用者のクライアントPC(たとえば、クライアントPC12−2)が、ファイルを作成、更新することも生じる。この場合にも、ほぼ同様の手順でファイルがアップロードされる。この場合、ダウンロードメールは、ファイルの所有者および他の利用者のクライアントPCに対して送信される。
次に、クライアントPCによる、制御サーバ10からのダウンロード処理について説明する。制御サーバ10は、ファイルが作成、変更されたことを通知するとともに、作成、変更されたファイルを、クライアントPCに送信するために、以下の情報を含むメールを作成する。
情報数:1(1つのメールに幾つの情報が入っているかを示す。この場合は1つ)
メールタイプ:アップロード完了メールである事を示すキーワード(例えばUPLOADDONE)
アップロード検知日時:アップロードメールの該当項目
所有ノード名:アップロードメールの該当項目
所有ディレクトリ呼称:アップロードメールの該当項目
ファイル名:アップロードメールの該当項目
ファイルハッシュ値:アップロードメールの該当項目
なお、上記情報およびファイルは、受信者の鍵で暗号化されて、メールに添付される。
クライアントPC12のメール処理部36は、受信したメールの添付ファイルを復号化する。ファイル管理部34は、所有ディレクトリ情報テーブル、利用ディレクトリテーブルを参照して、メール中の所有ノード名、所有ディレクトリ名を含むレコードが存在するか否かを判断する。該当レコードが存在すれば、記憶装置30中の該当するディレクトリに添付されたファイルを保存する。
本実施の形態においては、データ交換に電子メールを使用する。したがって、未配達という事態が発生し得る。また、通常の電子メールアドレスを使用してダウンロードメールを受取るユーザは、受信したメールの添付ファイルをクリックして、クライアントPCの記憶装置(ローカルディスク)にファイル等を登録する手順を忘れてしまう場合がある。
このため、一定間隔(たとえば、1回/日、1回/週、1回/月)で、記憶装置(ローカルディスク)の状態とコントロールセンタの状態を比較し、異なる部分に補完する作業が必要となる。
処理タイミングが到来すると、クライアントPC12の同期処理部32は、所有ディレクトリ情報テーブルに登録されている所有ディレクトリ毎、および、利用ディレクトリ情報テーブルに登録されている利用ディレクトリ毎に、以下に述べる処理を実行する。なお、同期処理部32は、アップロードキューテーブルに、未処理のレコードが存在していた場合は、未処理レコードが全てなくなるまで処理を延期する。
同期処理部32は、所有ディレクトリ情報テーブルに登録されている各レコードについて以下の処理を行う。
図16に示すように、まず、基本情報ノードテーブル中の自ノード名と、所有ディレクトリ情報テーブルのレコード中の所有ディレクトリ呼称を使用して、ローカルファイル情報テーブルを検索する(ステップ1601)。該当するレコードがない場合は(ステップ1602でノー(No))、次の所有ディレクトリ情報テーブルのレコード処理に進む。該当レコードが存在する場合には(ステップ1602でイエス(Yes))、以下の情報を含む同期チェックメール用のテキストファイルを作成する(ステップ1603)。
情報数:1つのメールに幾つの情報が入っているかを示す(該当するレコード数)。
以下の項目(メールタイプ〜ファイルサイズ)は、該当するレコード毎に作成される。
メールタイプ:同期チェックメールである事をキーワード(例えばSYNCCHECK)
ノード識別コード:基本情報ファイルテーブルの自ノード識別コード
ディレクトリタイプ:所有ディレクトリ
所有ノード名:所有ディレクトリ情報テーブルの所有者ノード名
所有ディレクトリ呼称:所有ディレクトリ情報テーブルの所有ディレクトリ呼称
相対Path:ローカルファイル情報テーブルのローカル相対Path
ファイル名:ローカルファイル情報テーブルのファイル名
ファイルハッシュ値:ローカルファイル情報テーブルのファイルハッシュ値
タイムスタンプ:ローカルファイル情報テーブルのタイムスタンプ
ファイルサイズ:ローカルファイル情報テーブルのファイルサイズ
次いで、上記テキストファイルが暗号化され(ステップ1604)、暗号化されたファイルを添付したメールが、制御サーバ宛に送信される(ステップ1605)。
同期処理部32は、利用ディレクトリ情報テーブルに登録されている各レコードについても同様の処理を実行する。簡単に説明すると、利用ディレクトリ情報テーブルの所有者ノード名と所有ディレクトリ呼称を使用して、ローカルファイル情報テーブルを検索する(ステップ1611)。該当するレコードがない場合は、次の利用ディレクトリ情報テーブルのレコード処理に進む。
該当レコードが存在する場合には、以下の情報を含む同期チェックメール用のテキストファイルを作成する。
情報数:1つのメールに幾つの情報が入っているかを示す(該当するレコード数)。
以下の項目(メールタイプ〜ファイルサイズ)は、該当するレコード毎に作成される。
メールタイプ:同期チェックメールである事をキーワード(例えばSYNCCHECK)
ノード識別コード:基本情報ファイルテーブルの自ノード識別コード
ディレクトリタイプ:利用ディレクトリ
所有ノード名:利用ディレクトリ情報テーブルの所有者ノード名
所有ディレクトリ呼称:利用ディレクトリ情報テーブルの所有ディレクトリ呼称
相対Path:ローカルファイル情報テーブルのローカル相対Path
ファイル名:ローカルファイル情報テーブルのファイル名
ファイルハッシュ値:ローカルファイル情報テーブルのファイルハッシュ値
タイムスタンプ:ローカルファイル情報テーブルのタイムスタンプ
ファイルサイズ:ローカルファイル情報テーブルのファイルサイズ
次いで、上記テキストファイルが暗号化され、暗号化されたファイルを添付したメールが、制御サーバ宛に送信される。
同期チェックメールを受信した制御サーバ10における処理について以下に説明する。
図17に示すように、制御サーバ10のメール処理部26がメールを受信すると、同期処理部22が、メールから抽出された送信元電子メールアドレスが、オンラインノード管理テーブルに登録されているかチェックし、オンラインノード管理テーブルの該当レコードから、以下の情報を取得する(ステップ1701)。
ノード名
仮登録FLG
ノード識別コード
通知用電子メールアドレス
ファイル受信用電子メールアドレス
また、メール処理部26は、添付されたテキストファイルを復号化する(ステップ1702)。同期処理部22は、復号化されたメールから、以下の項目を抽出する(ステップ1703)。
所有ノード名
所有ディレクトリ呼称
相対Path
ファイル名
同期処理部22は、これらを含むレコードが、実ファイル情報テーブルに存在するか否かを判断する(ステップ1704)。実ファイル情報テーブルにレコードが存在する場合には(ステップ1704でイエス(Yes))、実ファイル世代情報テーブルの該当レコードの最新のハッシュ値と、メール中のファイルハッシュ値とを比較する(ステップ1705)。双方のハッシュ値が同一であれば(ステップ1706でイエス(Yes))、同期チェックメールを送信したクライアントPCにあるファイルと、制御サーバ10にあるファイルとは同一であると判断する。
ハッシュ値が異なる場合(ステップ1706でノー(No))、同期処理部22は、実ファイル情報テーブルの該当レコードのタイムスタンプと、メール中のタイムスタンプとを比較する(ステップ1707)。メール中のタイムスタンプが新しい場合(ステップ1708でイエス(Yes))には、同期チェックメールを送信したクライアントPCに、アップロード依頼メールを送信する(ステップ1709)。その一方、メール中のタイムスタンプが古い場合(ステップ1708でノー(No))、同期チェックメールを送信したクライアントPCに、ダウンロードメールを送信する(ステップ1710)。
レコードが実ファイル情報テーブルに存在しない場合には(ステップ1704でノー(No))、図18に示すように、同期処理部22は、メール中のディレクトリタイプが所有ディレクトリである場合(ステップ1801でイエス(Yes)、または、メール中のディレクトリタイプが利用ディレクトリで(ステップ1802でイエス(Yes))、かつ、所有ディレクトリ情報テーブル中、関連するレコードの「公開フラグ=公開」かつ「公開タイプ=更新可」であれば(ステップ1803でイエス(Yes))、同期チェックメールを送信したクライアントPCに、アップロード依頼メールを送信する(ステップ1804)。
さらに、メール本文中、全てのファイルについて、上記図17および図18に示す処理が実行された後、実ファイル情報テーブル中に、同期処理が行われていないレコードが残った場合には、当該レコードに関して、所有者のクライアントPC宛にダウンロードメールを送信する。
制御サーバ10におけるダウンロードメール、および、アップロード依頼メールの作成について以下に簡単に説明する。ダウンロードメールは、以下の情報を含むテキストファイルを添付した状態で、クライアントPCに送信される。
情報数:1(1つのメールに幾つの情報が入っているかを示す。この場合には1つ)
メールタイプ:ダウンロードメールである事を示すキーワード(例えばDOWNLOAD)
所有ノード名:実ファイル情報テーブルの所有ノード名
所有ディレクトリ呼称:実ファイル情報テーブルの所有ディレクトリ呼称
ファイル名:実ファイル情報テーブルの実ファイル名
ファイルハッシュ値:実ファイル世代情報テーブルのハッシュ値
添付ファイル名:実ファイル世代情報テーブルのサーバーファイル名
また、アップロード依頼メールは、以下の情報を含むテキストファイルを添付した状態で、クライアントPCに送信される。
情報数:1(1つのメールに幾つの情報が入っているかを示す。この場合1つ)
メールタイプ:アップロード依頼メールである事を示すキーワード(例えばREQUPLOAD)
所有ノード名:同期チェックメール本文内の所有者ノード名
所有ディレクトリ呼称:同期チェックメール本文内の所有ディレクトリ呼称
相対Path:同期チェックメール本文内のローカル相対Path
ファイル名:同期チェックメール本文内のファイル名
クライアントPCにおけるファイルのダウンロード処理については、前述したとおりである。また、アップロード依頼に応じたアップロード処理も、基本的には、アップロード処理と同様である。
次に、本実施の形態の適用事例について説明する。まず、制御サーバ10を、クライアントPC12のファイルバックアップ装置として使用する場合について説明する。図10の例で、クライアントPC12−1において、あるファイル(クライアントPC12−1がファイル所有者となっているファイル)が更新されたと考える。クライアントPC12−1は、更新されたファイルを含むメールを制御サーバ12に送信する(ステップ1102)。制御サーバ10は、ファイルの変更を検知した後(図12、図13参照)、ファイルが添付されたメールを、制御サーバ10に送信する。制御サーバ10は、送信されたメールに添付されたファイルを、DB20中の所定の位置に格納するとともに、実ファイル世代情報テーブルのレコードを更新する。これにより、データのバックアップを実現することができる。
次に、チームで作業をする場合について説明する。あるクライアントPC(たとえば、クライアントPC12−1)がライブラリアンとして機能し、他のクライアントPC(たとえば、クライアントPC12−2、12−3、・・・)が、チームのメンバーとして機能すると考える。
システム設計など、複数人で1つのプロジェクトに関する仕事をする場合などでは、いつだれがどのファイルを作成・変更したかの記録と作成・変更タイミングの衆知徹底がプロジェクト推進上重要なポイントとなる。このような場合は本機構の補助手段としてE-Mailのメーリングリスト機能をもったメールサーバ16を組み合わせることにより、ファイルを共有化した作業を実現できる。
まず、ドキュメント全体を管理する立場の人(ライブラリアン)が所有ディレクトリを定義して、ライブラリアンのクライアントPC12−1が、所有ディレクトリ情報テーブルのレコードを、制御サーバ10に登録する。これにより、制御サーバ10には、必要な所有者Path情報テーブルのレコードが生成される。
実際の作業に携わるプロジェクトのメンバーは他のメンバーが作成・修正したファイルを制御サーバ10から受信して、自動的に、自己のクライアントPCのローカルディスクに保管することができ、かつ、自己のクライアントPCにおいて、ファイルの変更が検知されると、当該クライアントPCから変更されたファイルが添付されたメールを、制御サーバ10に送信する。
また、プロジェクトが一区切りついたとき(例えば、製品の1次リリース向けの作業完了時)には、ライブラリアンがその所有ディレクトリを公開・更新可から公開・更新不可と属性変更することにより、ドキュメントの凍結を行う事が簡単にできる。
また、そのリリース時点のファイルを固定・保管する為に、ライブラリアンが利用ディレクトリを定義し、一旦固定したファイルをローカルディスクに、ダウンロードし、その後、改めてそのローカルディスクのディレクトリを先に登録した、所有ディレクトリとは別の所有ディレクトリ(公開・更新不可)として定義する事により、特定時点のファイルを永久に保管する事が可能である。その後、元の所有ディレクトリを公開・更新可と属性変更することにより、次のリリースに向けた変更作業が継続できるようになる。
たとえば、図11に示すように、ライブラリアンのクライアントPC12−1は、共有するファイルの所有ディレクトリ情報テーブルのレコードを、制御サーバ10に送信する。ここで、レコード中、「公開フラグ」は「ON」、「公開タイプ」は「更新可」としておく。送信されたレコードは、制御サーバ10において、所有者パス情報テーブルのレコードとして登録される。
その一方、プロジェクトのメンバーのクライアントPC12−2、12−3、・・・においては、制御サーバ10の所有者パス情報テーブルのレコードを参照して、クライアントPCの記憶装置中に、利用ディレクトリ情報テーブルのレコードを作成しておく。
たとえば、プロジェクトのメンバーのクライアントPC12−2は、利用ディレクトリ情報テーブルのレコードにて特定されるディレクトリのファイルを作成、更新する。ファイルが作成、更新されると、クライアントPC12−2は、更新されたファイルを添付したメールを、制御サーバ10に送信する。
制御サーバ10は、ファイルをDB20に記憶するとともに、実ファイル世代情報の該当レコードを更新する。また、制御サーバ10は、ファイルを添付したメールを、他のクライアントPC12−1、12−3、・・・に送信する。
次に、ファイルの凍結作業と次のフェーズの作業開始について説明する。クライアントPC12−1は、所有ディレクトリ情報テーブルの該当ファイルのレコードにおいて、「公開タイプ」を「更新可」から「更新不可」に変更する。なお、これに先立って、ライブラリアンのクライアントPC12−1は、変更作業停止の通知を、メールなどの手段により、クライアント12−2、12−3、・・・に通知しても良い。
その後、クライアントPC12−1は、凍結ファイル格納用のディレクトリを、記憶装置30中に新規作成し、そのディレクトリを、利用ディレクトリとして登録する。つまり、利用ディレクトリ情報テーブルのレコードを作成する。これにより、制御サーバ10から、各ファイルの最新バージョンのものが全て、クライアントPC12−1に、添付ファイルとしてメールにて送信される。
メールの受信後、つまり、ダウンロード終了後、クライアントPC12−1において、利用者ディレクトリ情報テーブルのレコードを削除し、改めて、そのローカルディレクトリについて、所有ディレクトリとして定義する。つまり、そのローカルディレクトリの情報を、所有ディレクトリ情報テーグルのレコードとして格納する。ここでは、「公開タイプ」を「更新不可」としておく。これにより、このローカルディレクトリのファイルは、別途、制御サーバ10で管理されることになる。
その後、当初のディレクトリの「公開タイプ」を、「更新不可」から「更新可」に変更することで、利用者によるファイルの更新が可能となる。たとえば、クライアントPC12−1は、変更作業再開の通知を、メールにて、クライアント12−2、12−3に通知しても良い。
上述したクライアントPC12−1の処理の結果、制御サーバ10のDB20には、各メンバーが継続して作業するための所有ディレクトリ(もともと作業に使用していたディレクトリ)と、リリースに伴って固定されたファイルが格納されている変更不可の所有ディレクトリの2つが存在することになる。
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
図1は、本発明の実施の形態にかかるファイルバックアップ・共有制御サーバを含むシステム全体の構成を示すブロックダイヤグラムである。 図2(a)は制御サーバの構成を示すブロックダイヤグラム、図2(b)は、クライアントPCの構成を示すブロックダイヤグラムである。 図3は、本実施の形態にかかるノード基本情報テーブルのデータ構成を示す図である。 図4は、本実施の形態にかかる所有ディレクトリ情報テーブルのデータ構成を示す図である。 図5は、本実施の形態にかかる利用ディレクトリ情報テーブルのデータ構成を示す図である。 図6(a)は、本実施の形態にかかるローカルファイル情報テーブルのデータ構成を示す図、図6(b)は、アップロードキュー情報テーブルのデータ構成を示す図である。 図7は、本実施の形態にかかるオンラインノード管理テーブルのデータ構成を示す図である。 図8は、本実施の形態にかかる所有者情報テーブルのデータ構成を示す図である。 図9(a)は、本実施の形態にかかる利用者情報テーブルのデータ構成を示す図、図9(b)は、実ファイル情報テーブルのデータ構成を示す図、図9(c)は、実ファイル世代情報テーブルのデータ構成を示す図である。 図10は、本実施の形態において、制御サーバをファイルバックアップ装置として利用する例を示す図である。 図11は、本実施の形態において、制御サーバをファイル共有装置として利用する例を示す図である。 図12は、本実施の形態にかかるクライアントPCにて実行される処理を示すフローチャートである。 図13は、本実施の形態にかかるクライアントPCにて実行される処理を示すフローチャートである。 図14は、本実施の形態にかかるクライアントPCにて実行される処理を示すフローチャートである。 図15は、本実施の形態にかかる制御サーバにて実行される処理を示すフローチャートである。 図16は、本実施の形態にかかるクライアントPCにて実行される処理を示すフローチャートである。 図17は、本実施の形態にかかる制御サーバにて実行される処理を示すフローチャートである。 図18は、本実施の形態にかかる制御サーバにて実行される処理を示すフローチャートである。
符号の説明
10 制御サーバ
12 クライアントPC
14 ネットワーク
16 メールサーバ
20 DB
22 同期処理部(センター同期処理部)
24 ファイル管理部(センターファイル管理部)
26 メール処理部(センターメール処理部)
30 記憶装置
32 同期処理部(ローカル同期処理部)
34 ファイル管理部(ローカルファイル管理部)
36 メール処理部(ローカルメール処理部)

Claims (7)

  1. 自己が所有するファイルが格納されたディレクトリパスおよび所有ディレクトリ名を含むレコードを格納する所有ディレクトリ情報テーブルと、
    メールの添付ファイルとして送信すべきファイルの所有者を示す所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値を含むレコードを格納するアップロードキュー情報テーブルと、
    前記所有ディレクトリ情報テーブルのレコードの、ディレクトリパスおよび所有ディレクトリ名にて特定されるファイルと、を格納した第1の記憶装置、
    前記第1の記憶装置に記憶されたファイルを管理するローカルファイル管理手段であって、ファイルの作成、変更を検知し、作成、変更されたファイルに関するレコードを生成して、前記アップロードキュー情報テーブルに格納するローカルファイル管理手段、並びに、
    前記アップロードキュー情報テーブルのレコードに基づき、前記所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値とともに、前記ファイルを添付ファイルとしたメールを送信するローカルメール処理手段を有するクライアントコンピュータと、
    前記ローカルメール処理手段から送信されたメールを受信するセンターメール処理手段、
    前記ネットワークを介して、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づく、所有ノード名、および、所有ディレクトリ名を含むレコードを格納する所有者情報テーブルと、
    前記所有ノード名、所有ディレクトリ名、ディレクトリパス、および、ファイル名を含むレコードを格納する実ファイル情報テーブルと、
    ファイル名、ファイルのタイムスタンプ、ファイルの内容を示すを含むレコードを格納する実ファイル世代情報テーブルと、を格納した第2の記憶装置、並びに、
    前記センターメール処理手段により受理されたメールに添付された前記ファイルを、前記第2の記憶装置に格納するとともに、前記実ファイル情報テーブル、および、前記実ファイル世代情報テーブルの該当レコードを更新するセンターファイル管理手段を有する制御サーバとを備え、
    前記制御サーバの第2の記憶装置が、前記ローカルメール処理手段から送信され、前記センターメール処理手段により受信されたメールに基づく、前記利用したいファイルのある他のクライアントコンピュータのノード名である利用ノード名、前記利用したいファイルに関する所有ノード名、前記利用したいファイルの所有ディレクトリ名である利用ディレクトリ名を含むレコードを格納する利用者情報テーブルを有し、
    前記センターファイル管理手段が、前記実ファイル情報テーブル、および、前記実ファイル世代情報テーブルを更新するとともに、前記利用者情報テーブルを参照して、前記ファイルに関する、前記所有ノード名および所有ディレクトリ名を含むレコードの存在を判断し、当該レコードに含まれる利用ノード名を特定し、
    前記センターメール処理手段が、前記特定された利用ノード名に示される他のクライアントコンピュータに、前記ファイルを添付したメールを送信することを特徴とするファイル共有制御システム。
  2. 前記他のクライアントコンピュータを含む前記クライアントコンピュータの第1の記憶装置が、利用したいファイルを所有するクライアントコンピュータの所有ノード名、前記利用したいファイルの所有ノード名、および、所有ディレクトリ名を含むレコードを格納する利用ディレクトリ情報テーブルを有し、
    前記ローカルファイル管理手段は、前記利用ディレクトリ情報テーブルのレコードに基づき、前記メールに添付された前記ファイルを前記第2の記憶装置に格納することを特徴とする請求項1に記載のファイル共有制御システム。
  3. 前記クライアントコンピュータの前記第1の記憶装置に格納された前記所有ディレクトリ情報テーブルのレコードが、ファイルの公開の可否を示す公開フラグ、公開が可能である場合のファイルの更新の可否を示す公開タイプ情報を含み、
    前記制御サーバの前記第2の記憶装置に格納された前記所有者情報テーブルのレコードが、前記公開フラグおよび公開タイプ情報を含み、
    前記クライアントから前記制御サーバに、前記所有ディレクトリ情報テーブルのレコードが送信されると、前記センターファイル管理手段が、前記所有者情報テーブルのレコードを作成・更新し、
    前記センターファイル管理手段が、前記所有者情報テーブルのレコードの、前記公開フラグおよび公開タイプ情報を参照して、前記ファイルの第2の記憶装置への格納の可否を判断することを特徴とする請求項2に記載のファイル共有制御システム。
  4. 前記ファイルの内容を示すが、ファイルのハッシュ値であり、前記ローカルファイル管理手段が、ハッシュ値を比較することにより、ファイルの内容の一致を判断し、これに基づき前記ファイルの変更を判断することを特徴とする請求項1ないし3の何れか一項に記載のファイル共有制御システム。
  5. さらに、クライアントコンピュータが、所定のタイミングで、所有ノード名、所有ディレクトリ名、ファイル名、ファイルの内容を示す値、タイムスタンプを含む情報を収集する同期処理手段を有し、
    前記ローカルメール処理手段が、前記同期処理手段が収集した情報を含むメールを、前記制御サーバに送信し、
    前記制御サーバは、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づき、前記ファイルを添付したメールのクライアントコンピュータへの送信、或いは、前記クライアントコンピュータに対する、前記ファイルを添付したメールの送信要求の必要性を判断するセンター同期処理手段を有することを特徴とする請求項1ないし4の何れか一項に記載のファイル共有制御システム。
  6. 自己が所有するファイルが格納されたディレクトリパスおよび所有ディレクトリ名を含むレコードを格納する所有ディレクトリ情報テーブルと、
    メールの添付ファイルとして送信すべきファイルの所有者を示す所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値を含むレコードを格納するアップロードキュー情報テーブルと、
    前記所有ディレクトリ情報テーブルのレコードの、ディレクトリパスおよび所有ディレクトリ名にて特定されるファイルと、を格納した第1の記憶装置を備えたクライアントコンピュータにおいて、
    前記第1の記憶装置に記憶されたファイルを管理するローカルファイル管理手段であって、ファイルの作成、変更を検知し、作成、変更されたファイルに関するレコードを生成して、前記アップロードキュー情報テーブルに格納するローカルファイル管理ステップと、
    前記アップロードキュー情報テーブルのレコードに基づき、前記所有ノード名、所有ディレクトリ名、ファイル名、タイムスタンプ、および、ファイルの内容を示す値とともに、前記ファイルを添付ファイルとしたメールを送信するローカルメール処理ステップと、を有し、
    前記ネットワークを介して、前記ローカルメール処理手段から送信され、センターメール処理手段により受信されたメールに基づく、所有ノード名、および、所有ディレクトリ名を含むレコードを格納する所有者情報テーブルと、
    前記所有ノード名、所有ディレクトリ名、ディレクトリパス、および、ファイル名を含むレコードを格納する実ファイル情報テーブルと、
    ファイル名、ファイルのタイムスタンプ、ファイルの内容を示すを含むレコードを格納する実ファイル世代情報テーブルと、を格納した第2の記憶装置を備えた制御サーバにおいて、
    前記ローカルメール処理手段から送信されたメールを受信するセンターメール処理ステップと、
    前記センターメール処理ステップにおいて受理されたメールに添付された前記ファイルを、前記第2の記憶装置に格納するとともに、前記実ファイル情報テーブル、および、前記実ファイル世代情報テーブルの該当レコードを更新するセンターファイル管理ステップと、を有し、
    前記制御サーバの第2の記憶装置が、ローカルメール処理ステップにおいて送信され、前記センターメール処理ステップにおいて受信されたメールに基づく、前記利用したいファイルのある他のクライアントコンピュータのノード名である利用ノード名、前記利用したいファイルに関する所有ノード名、前記利用したいファイルの所有ディレクトリ名である利用ディレクトリ名を含むレコードを格納する利用者情報テーブルを有し、
    前記センターファイル管理ステップが、前記実ファイル情報テーブル、および、前記実ファイル世代情報テーブルを更新するとともに、前記利用者情報テーブルを参照して、前記ファイルに関する、前記所有ノード名および所有ディレクトリ名を含むレコードの存在を判断し、当該レコードに含まれる利用ノード名を特定するステップを有し、
    前記センターメール処理ステップが、前記特定された利用ノード名に示される他のクライアントコンピュータに、前記ファイルを添付したメールを送信するステップを有することを特徴とするファイル共有制御方法。
  7. 前記他のクライアントコンピュータを含む前記クライアントコンピュータの第1の記憶装置が、利用したいファイルを所有するクライアントコンピュータの所有ノード名、前記利用したいファイルの所有ノード名、および、所有ディレクトリ名を含むレコードを格納する利用ディレクトリ情報テーブルを有し、
    前記ローカルファイル管理ステップが、前記利用ディレクトリ情報テーブルのレコードに基づき、前記メールに添付された前記ファイルを前記第2の記憶装置に格納するステップを含むことを特徴とする請求項6に記載のファイル共有制御方法。
JP2004102455A 2004-03-31 2004-03-31 ファイル共有制御システムおよび共有制御プログラム Expired - Fee Related JP4497984B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004102455A JP4497984B2 (ja) 2004-03-31 2004-03-31 ファイル共有制御システムおよび共有制御プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004102455A JP4497984B2 (ja) 2004-03-31 2004-03-31 ファイル共有制御システムおよび共有制御プログラム

Publications (2)

Publication Number Publication Date
JP2005292869A JP2005292869A (ja) 2005-10-20
JP4497984B2 true JP4497984B2 (ja) 2010-07-07

Family

ID=35325777

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004102455A Expired - Fee Related JP4497984B2 (ja) 2004-03-31 2004-03-31 ファイル共有制御システムおよび共有制御プログラム

Country Status (1)

Country Link
JP (1) JP4497984B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2007234696B2 (en) * 2006-04-07 2011-08-18 Data Storage Group Data compression and storage techniques
KR100713108B1 (ko) * 2006-10-27 2007-05-02 주식회사 대광엔지니어링 일체형 항온항습기의 에어 쿨링장치
JP4996489B2 (ja) * 2008-01-21 2012-08-08 日本電信電話株式会社 分散バックアップシステム、分散バックアップ方法、寄託者装置、管理者装置
JP5217776B2 (ja) * 2008-08-25 2013-06-19 日本電気株式会社 クライアントサーバシステム、クライアントコンピュータ、ファイル管理方法及びそのプログラム
JP2010176256A (ja) * 2009-01-28 2010-08-12 Ri Co Ltd バックアッププログラム
JP2010266933A (ja) * 2009-05-12 2010-11-25 Ri Co Ltd ドキュメント管理プログラム、ドキュメント管理システム及びドキュメント管理方法
JP2013073557A (ja) * 2011-09-29 2013-04-22 Hitachi Solutions Ltd 情報検索システム、検索サーバ及びプログラム
JP6152329B2 (ja) * 2013-09-27 2017-06-21 株式会社沖データ 情報処理装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117801A (ja) * 1999-10-22 2001-04-27 Sharp Corp データベース同期処理装置及びデータベース同期処理プログラムを記録した記録媒体
JP2001195521A (ja) * 2000-01-07 2001-07-19 Nippon Digital Kenkyusho:Kk データの同期方法、インターネット会計処理システム、及び会計データの同期処理プログラムの記録媒体
JP2003006023A (ja) * 2001-06-20 2003-01-10 Hitachi Ltd 情報資源の更新方法
JP2003345953A (ja) * 2002-05-27 2003-12-05 Cybozu Inc グループ間情報共有システム、グループ内情報共有装置及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117801A (ja) * 1999-10-22 2001-04-27 Sharp Corp データベース同期処理装置及びデータベース同期処理プログラムを記録した記録媒体
JP2001195521A (ja) * 2000-01-07 2001-07-19 Nippon Digital Kenkyusho:Kk データの同期方法、インターネット会計処理システム、及び会計データの同期処理プログラムの記録媒体
JP2003006023A (ja) * 2001-06-20 2003-01-10 Hitachi Ltd 情報資源の更新方法
JP2003345953A (ja) * 2002-05-27 2003-12-05 Cybozu Inc グループ間情報共有システム、グループ内情報共有装置及びプログラム

Also Published As

Publication number Publication date
JP2005292869A (ja) 2005-10-20

Similar Documents

Publication Publication Date Title
US11561931B2 (en) Information source agent systems and methods for distributed data storage and management using content signatures
US10911518B2 (en) Network folder synchronization
US6615405B1 (en) Method and system for distributing and maintaining software across a computer network
EP3685268B1 (en) File system point-in-time restore using recycle bin and version history
US9083707B2 (en) System and method for preventing access to data on a compromised remote device
US20120117665A1 (en) Methods and computer program products for controlling restricted content
US20150199414A1 (en) Locally cached file system
US8046329B2 (en) Incremental backup of database for non-archive logged servers
US20060015545A1 (en) Backup and sychronization of local data in a network
JP2006099730A (ja) プロジェクトデータのキャッシュおよび同期をとる方法およびシステム
JP2007299284A (ja) ログ収集システム、クライアント装置、及びログ収集エージェント装置
JP4497984B2 (ja) ファイル共有制御システムおよび共有制御プログラム
JP4497983B2 (ja) ファイル共有制御システム、共有制御サーバおよび共有制御プログラム
KR100935831B1 (ko) 복수의 이벤트 식별자가 포함된 데이타구조체를 이용한 데이타동기화 방법 및 상기 방법을 이용한 데이타 백업솔루션
JP4766127B2 (ja) 情報処理装置、ファイル管理システムおよびプログラム
WO2013065544A1 (ja) データ分散管理システム
JP2011197849A (ja) セキュリティ管理システム及びセキュリティ管理プログラム
JP4261551B2 (ja) アーカイブシステム
US20240184910A1 (en) Data management device, data sharing system and method, and non-transitory computer readable medium
Wesselius et al. Backup and Restore
JP5667702B2 (ja) データ分散管理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070402

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091215

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100212

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100406

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100413

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130423

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130423

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160423

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees