JP3709975B2

JP3709975B2 - 文書一括管理方法、文書一括管理システムおよび記録媒体

Info

Publication number: JP3709975B2
Application number: JP2000133321A
Authority: JP
Inventors: 誠岡崎; 俊彦佐々木
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2000-05-02
Filing date: 2000-05-02
Publication date: 2005-10-26
Anticipated expiration: 2020-05-02
Also published as: JP2001312422A

Description

【０００１】
【発明が属する技術分野】
この発明は複数のコンピュータで作成される文書データを一括管理する技術、更に詳しくは、クライアントコンピュータ（以下、単に「クライアントＰＣ」）で作成、更新される文書をサーバコンピュータ（以下、単に「サーバＰＣ」）で一元管理するための技術に関するものである。
【０００２】
【先行技術】
「ナレッジマネージメント」という概念を研究する企業が増えており、その概念に基づいた経営手法の導入も検討されている。一方、クライアント／サーバ構成によって管理する技術については、様々な課題に基づき、それぞれ対応したシステム構築がなされている。例えば、「文書データの一元管理」という課題に対しては、クライアントＰＣの使用者がサーバの特定のフォルダへ文書を保存するなどして対応している。また、「セキュリティ」という課題に対しては、例えば、クライアントＰＣの使用者がパスワードを入力しないとサーバへアクセスできないようにしている。
【０００３】
なお、「（ナレッジ＋ナレッヂ）＊（マネージメント＋マネジメント）」というキーワードにて特許出願を検索したところ、特開平９−２０４３４８号、特開平９−３２５９６８号の２件を抽出したので、その要約文を検討したが、本願発明と直接関係はないと考えられる。
【０００４】
【発明が解決しようとする課題】
しかし、「文書データの一元管理」に関しては、以下のような問題点があった。第一に、文書データの保存、更新などは、クライアントＰＣの使用者による「サーバへの保存」という行為に依存しているため、保存の失念という人為的なミスによって「一元管理」が達成できないこととなる。この「保存の失念」という事態は、経験的、統計的に見て、極めて起こりやすい。
【０００５】
第二に、重要度の低い文書と高い文書との整理の問題である。すなわち、クライアントＰＣから長期間アクセスがないような文書は重要度が低いと判断できるが、その「判断および整理」という行為はサーバ管理者に依存している。このため、判断や整理という行為を長期間怠ると、重要度が低い文書が高い文書と混在することとなり、検索に時間が掛かるなどの問題が出てくる。
【０００６】
第三に、複数のファイルサーバを用いた場合、各サーバの役割が管理者の「運用」という行為に依存しているため、特定のサーバへの負荷が増大する可能性があるという問題がある。
本発明が解決すべき課題は、クライアント／サーバ構成における文書データの一元自動管理や、それに付随するデータ重要度の判断および整理、加えてそれらにおける複数サーバの自動運用にある。
【０００７】
ここで、請求項１から請求項４記載の発明の目的は、クライアント／サーバ構成における文書データの一元自動管理や、それに付随するデータ重要度の判断および整理を行える技術を提供することである。
【０００８】
【課題を解決するための手段】
本発明は、上記した目的を達成するためのものである。
（請求項１）
請求項１記載の発明は、クライアントＰＣにおいて所定のディレクトリ内のファイル変更イベントを監視するファイル変更イベント監視手順と、ファイル変更イベントが発生した場合に、当該変更イベントが発生したディレクトリ内を検索して、監視対象とされた拡張子を持つファイルを抽出し、通信用のディレクトリに出力するファイル変更イベント通知手順と、そのファイル変更イベント通知手順によって抽出されたファイルを文書管理サーバへ送信し、文書管理サーバへの送信が完了したファイルを送信済みファイルリストに登録する文書移動手順と、その文書移動手順によって移動された文書データを、文書管理サーバにおいて蓄積する文書データ記憶手順と、前期送信済みファイルリストに記載されたファイルにつき、一定周期でクライアントＰＣからの消去を試みるファイル消去手順と、そのファイル消去手順によって消去が成功した場合には、当該ファイル名を送信済みファイルリストから削除するデータ消去手順とを備えた文書一括管理方法に係る。
【０００９】
（用語説明）
「起動確認手順」は、クライアントＰＣにおけるサーバ監視機能と、文書管理サーバにおけるクライアント監視機能とによって達成される。「アプリケーション起動規制手順」は、例えば以下の２つの手法によって達成する。第一に、クライアントＰＣにおける文書作成アプリケーション起動監視機能と、文書管理サーバにおけるクライアント情報管理機能とによって達成される場合である。第二に、クライアントＰＣにおける起動抑制機能付きロードモジュールと、文書管理サーバにおけるクライアント情報管理機能とによって達成される場合である。
【００１０】
（作用）
文書を管理サーバへ保存させるという行為を人間の行為に頼らないので、「文書の一元管理」に寄与する。
【００１１】
（請求項２）
請求項２記載の発明は、請求項１に記載の文書一括管理方法を限定したものである。
すなわち、文書記憶手順にて蓄積された文書データが文書移動手順によって一のクライアントＰＣに送信された場合には、当該文書データを他のクライアントＰＣに送信不能とする排他ロック手順と、文書移動手順および文書データ記憶手順によって当該文書データが再び蓄積された場合には、クライアントＰＣからの要求に応じて移動可能とするための排他ロック解除手順とを備えた文書一括管理方法に係る。
【００１２】
（請求項３）
請求項３記載の発明は、文書管理サーバとクライアントＰＣを備えた文書一括管理システムに係る。
前記文書管理サーバは、通信対象となる文書管理サーバのサーバ名またはIPアドレス、監視対象アプリケーション名、または監視対象となるファイル拡張子情報を少なくとも含む初期データをクライアントＰＣに送信する送信手段と、クライアントＰＣから送信された文書データを蓄積する文書データ記憶手段とを備える。
前記クライアントＰＣは、文書管理サーバに、前記初期データの送信を要求する初期データ要求手段と、文書管理サーバから、前記初期データを受信する初期データ受信手段と、文書管理サーバの起動を確認する文書管理サーバ起動確認手段と、文書管理サーバから受信した前記初期データに係る監視対象アプリケーションが起動されていないかを監視するアプリケーション起動監視手段とを備える。
更に、前記文書管理サーバ起動確認手段によって文書管理サーバの起動が確認されず、かつ前記アプリケーション起動監視手段によって監視対象アプリケーションの起動が確認された場合において、前記初期データに係る監視対象アプリケーションを強制終了させるアプリケーション終了手段と、所定のディレクトリ内におけるファイルの変更イベントを監視するファイル変更イベント監視手段と、ファイルの変更イベントを検知すると、該変更イベントが発生したディレクトリ内を検索し、前記初期データ記載の監視対象とされたファイル拡張子をもつファイルがあった場合にはそのファイルを抽出する監視対象ファイル抽出手段と、前記監視対象ファイル抽出手段によって抽出されたファイルを、文書管理サーバに送信する文書送信手段と、文書管理サーバへの送信が完了したファイルを、送信済みファイルリストに登録する送信済みファイル登録手段と、前記送信済みファイルリストに登録されたファイルにつき、一定周期でクライアントＰＣからの消去を試みるファイル消去手段と、そのファイル消去手段によるファイルの消去が成功した場合に、当該ファイル名を送信済みファイルリストから削除するデータ消去手段とを備えることを特徴とする。
【００１３】
（請求項４）
請求項４記載の発明は、請求項３に記載の文書一括管理システムを限定したものである。
すなわち、文書データ記憶手段によって蓄積された文書データが文書送信手段によって一のクライアントＰＣに送信された場合には、当該文書データを他のクライアントＰＣに送信不能とする排他ロック手段と、文書データ記憶手段によって当該文書データが再び蓄積された場合には、クライアントＰＣからの要求に応じて移動可能とするための排他ロック解除手段とを備えた文書一括管理システムに係る。
【００１４】
【発明の実施の形態】
以下、本発明を実施の形態及び図面に基づいて、更に詳しく説明する。ここで使用する図面は、図１乃至図６に示す概念図と、図７乃至図１７に示すフローチャートである。
【００１５】
（概要）
クライアントＰＣのユーザが文書作成アプリケーションで、文書を作成するには、文書管理サーバが起動していなければならないよう、各種アプリケーション起動監視機能が働く。
クライアントＰＣのユーザが起動を許可されたアプリケーションで文書を作成し、文書データを保存するには、その文書データに関する属性データを入力しなければならないようにしている。文書データを保存しようとすると、ファイル送信機能によって文書管理サーバへ強制的にその文書データは移動させられ、クライアントＰＣからは当該文書データは自動的に消去される。文書管理サーバにおいては、文書管理機能によって文書管理番号を自動付与され、その番号に基づいて管理される。クライアントＰＣからのアクセスは、管理文書アクセス記録機能によって記録されており、所定期間アクセスのない文書データについては、管理文書自動保管機能によって自動的に別の記録媒体へ移動する。
【００１６】
クライアントＰＣのユーザは、作成した文書データを専用のブラウザによって一覧表示させ、編集することができる。一覧表示機能では、作成したクライアントＰＣのアドレス、文書データの作成者、文書データに付された属性データなどで選別が可能となっている。
【００１７】
（アプリケーション起動規制）
アプリケーション起動規制を実現するためには、二つの処理方式がある。これらを図１とともに説明する。
【００１８】
（第一の処理方式）
第一の処理方式は、クライアント側にサーバ監視機能と、文書作成アプリケーション起動監視機能とを備え、文書管理サーバ側にクライアント監視機能と、クライアント情報管理機能とを備えることによって達成する。一定周期に文書管理サーバのアプリケーションとの通信を試みる。通信に成功したら、サーバからクライアント文書管理アプリケーションに必要な各種情報を受信する。ここで、「各種情報」とは、通信相手のサーバのサーバ名やＩＰアドレス、起動制限されるアプリケーション名、監視対象となるファイルの拡張子情報などである。
【００１９】
通信に失敗したら、以下に述べるアプリケーションの起動制限が機能する。すなわち、以前サーバから受信したまたは以前から保持している起動制限されるアプリケーション名に従って、一定周期で当該アプリケーションが起動されていないかを監視する。監視はウィンドウのタイトルバーのテキストデータによって行う。もし、当該アプリケーションが起動されていたら、そのウィンドウに対して終了メッセージ（例えば、Microsoft社のWindowsでは、ＷＭ＿ＣＬＯＳＥ）を送信し、当該アプリケーションを強制終了させるのである。
【００２０】
文書管理サーバにおけるクライアント監視機能では、echoを送信することによってクライアントＰＣのマシン名／ＩＰアドレスを監視する。そして、ＰＣが起動されているにもかかわらず一定時間以上、そのＰＣとの通信が行われていない場合には、警告を発し、無許可でクライアントＰＣにおいて文書管理アプリケーションを動作しないようにする。
クライアント情報管理機能では、クライアントＰＣにおいて必要な、通信相手となるサーバ名／ＩＰアドレス、起動制限されるアプリケーション名、監視対象となるファイルの拡張子情報を一元管理する。この情報は、クライアントＰＣとの通信時に送信される。
【００２１】
（第二の処理方式）
第二の処理方式は、クライアント側にサーバ監視機能と、起動抑制機能付きロードモジュールとを備え、文書管理サーバ側にクライアント監視機能と、クライアント情報管理機能とを備えることによって達成する。
【００２２】
（図２）
図２には、起動抑制機能付きロードモジュールの概念を示す。すなわち、各種の文書作成用アプリケーション（例えばワープロソフト、表計算ソフトなど）をロードモジュール内にデータ（リソース）として取り込み、ロードモジュール起動時に、サーバ監視機能と通信して文書管理サーバの起動が確認できた場合には、当該アプリケーション部分をファイルとして抽出し、起動するものである。文書管理サーバの起動が確認できなければ、当該アプリケーションは起動できないので、文書データが新たに作成されることも、アップデートされることもない。
【００２３】
（文書の強制移動、属性入力、文書管理番号の自動付与）
図３には、文書の強制移動、属性入力、文書管理番号の自動付与の概念を示す。
【００２４】
（ファイル監視機能）
まず、クライアントＰＣで有効なドライブ名の変更を監視し、その中で取り外し可能な媒体、ＣＤ−ＲＯＭ、リモートアクセスドライブを除外して、監視対象を特定する。そして、各ドライブのルートディレクトリからサブディレクトリを辿り、全ディレクトリに、ディレクトリ内のファイル変更時にイベントを発生させるイベントハンドラを設定する。ただし、処理効率を考えてイベントハンドラを設定するディレクトリからＯＳ（オペレーションズシステム）や各種アプリケーションが頻繁にアクセスする可能性の高いディレクトリ（例えばシステムディレクトリ、テンポラリディレクトリなど）を除外することとしてもよい。
また設定するイベントハンドラの数が膨大になる場合は、全ディレクトリではなく、ある階層までのディレクトリに限定してイベントハンドラを設定する。その場合にイベントハンドラが設定される最下層のディレクトリのイベントハンドラは、サブディレクトリのファイル変更イベントも拾うように設定する。
【００２５】
変更イベントが発生したらイベントの発生したディレクトリ（ある階層までにイベントハンドラを設定するディレクトリを限定した場合のイベントハンドラが設定された最下層ディレクトリの場合はサブディレクトリを含む）の内部をサーチし、サーバが監視対象であると特定しているファイル拡張子を持つファイルを抽出する。そして、そのファイルのタイムスタンプを見て、前回の起動時から変更のあったファイルを対象とする。抽出したファイルは、文書管理サーバへ送信される。
なお、監視中にディレクトリ構造に変更が加えられる場合もあるので、各ドライブにディレクトリの変更イベントハンドラも設定しておく。そして、ディレクトリ構造に変更があった場合は、ファイルの変更イベントハンドラおよびディレクトリの変更イベントハンドラを再設定する。
【００２６】
（文書属性入力機能）
次に、変更があったとして抽出されたファイルには、クライアントＰＣのユーザに対して、そのファイルの属性データを入力させるためのウィンドウを表示する。同じファイルに対して２回以上ウィンドウが開かないように、ファイル名と入力されたと属性データとを関連づけてクライアントＰＣ上に保持しておく。
【００２７】
（文書の強制送信）
変更があったとして抽出されたファイルは、クライアントＰＣ名、ファイルのフルパス名、入力された属性データなどの各種情報とともに、文書管理サーバへ送信する。そして、送信済みのファイルはクライアントＰＣから消去する。
なお、当該クライアントＰＣにおける他のアプリケーションがそのファイルを使用している場合には、排他制御機能が働き、消去できない可能性がある。したがって、クライアントＰＣにおいて、送信済みファイルのリストを保持しておき、一定周期でファイルの消去を試み、消去が成功した場合には、前記リストから該当するファイル名を消去する。
【００２８】
（文書管理機能）
クライアントＰＣから、クライアントＰＣ名、ファイルのフルパス名、入力された属性データなどの各種情報とともに文書管理サーバへ送信されてきた変更ファイルは、当該サーバの受信機能によって受信した後、文書管理サーバ内へ登録するのである。更に詳しく説明する。
【００２９】
まず、クライアントＰＣからファイルの送信要求を受け、次に、文書管理番号管理データベースから一意性を保証された文書管理番号（例えば、クライアントＰＣ名、西暦年月日、通し番号）を取得する。続いて、サーバ上の特定ディレクトリ内にクライアントＰＣ名のサブディレクトリを作成し、そこに受信するファイル名のサブディレクトリを作成し、更にそこに作成日時（例えば、西暦年月日、時分秒）のディレクトリを作成して、受信したファイルデータのファイルを保存する。ファイル保存が完了したら、文書管理データベースに、クライアントＰＣから受信した各種の情報と、サーバ上での物理的な保存場所とを登録する。
なお、送信要求の以前に「チェックアウト」が済んだファイルであれば、排他ロックを解除する。そして、文書管理データベースでは、ロック状態である旨を管理する。（「チェックアウト」については後述する。）
【００３０】
（文書の自動保管）
図４は、所定期間アクセスのない文書データを、サーバの負担軽減等のため、自動的に別の記録媒体へ保管する機能を示す概念を示している。
【００３１】
まず、管理文書アクセス記録機能によって、管理文書毎に、クライアントＰＣからの最新アクセス日時を文書管理データベースへ登録される。そして、所定周期（例えば１週間から１ヶ月程度）で、管理文書に対するアクセス状況を監視する。監視の結果、予め「長期間」と定められた期間（例えば１年間）以上、アクセスがない文書データについては、管理文書自動保管機能によって、外部の記録媒体（例えば磁気テープなど）へ移動させ、サーバからは文書データを消去する。そして、文書管理データベースには、当該文書データが外部媒体へ待避済みであることを、媒体ＩＤとともに登録しておく。なお、媒体ＩＤの形式は、書き込まれた西暦年月日および書き込まれた時分秒とすることによって、一意性を保証する。
【００３２】
（管理文書の一覧表示、文書の編集）
図５では、管理文書の一覧表示をし、文書の編集を行えるという機能を示す概念を示している。
【００３３】
（管理文書情報受信機能）
クライアントＰＣは、管理文書情報受信機能によって、文書管理サーバが管理している文書の一覧情報を受信する。一覧情報とは、例えば、文書名、作成日時、版数、文書登録したＰＣ名、入力された属性データなどである。受信した一覧情報は、ブラウザによって表示される。属性データなどから、表示された文書データのうちの欲するものを選択することができる。なお、属性データにおけるセキュリティ情報によって、特定クライアントからの文書データ閲覧を禁止させることもできる。
【００３４】
（管理文書受信機能、対応ＡＰ（アプリケーション）起動機能）
管理文書受信機能によって、一覧表示されたリストから選択した文書を、文書管理サーバから受信する。受信したファイルは、予め設定された作業ディレクトリへ作成するものとし、ファイルがクライアントＰＣに対するファイル監視機能により送信／削除されてしまわないようにプログラム内で既に送信済みファイルとして扱う。更に、下記に示すアプリケーション自動起動が行われるまで当該ファイルの削除を遅延させるため、送信済みファイルリスト中に削除遅延フラグを設け、一定時間は削除対象のファイルから除外する。
続いて、対応ＡＰ起動機能によって、受信したファイルに、ＯＳ上で対応付けされたアプリケーションを自動的に起動する。
【００３５】
（管理文書情報送信機能）
文書管理サーバは、管理文書情報送信機能によって、管理している文書の一覧情報をクライアントＰＣへ送信する。前述したように、属性データにおけるセキュリティ情報によって、特定クライアントからの文書データ閲覧を禁止させることもできる。
【００３６】
（管理文書送信機能）
文書管理サーバは、管理文書送信機能によって、クライアントＰＣから要求があったファイルを送信する。送信後は、「排他ロック」を機能させることによって、他のクライアントＰＣから要求があっても送信しない。すなわち、文書管理データベースにおいては、ロック状態で管理する。このロック状態は、当該ファイルが文書管理サーバへチェックインされるまで解除しない。
【００３７】
（拡張構成時のサーバ制御方式）
図６には、サーバが複数存在する、いわゆる拡張構成が構築された際のサーバ間の機能を示している。複数のサーバが文書管理サーバとして存在する場合、マスターサーバを１台とし、それ以外をスレーブサーバとする。各種の管理データベースは、マスターサーバ上にて一元管理する。
スレーブサーバ監視手順によって「接続負荷が小さい」と判断されるのは、複数あるスレーブサーバの中で相対的に小さい場合である。全く同一ならば、最も古く接続されたスレーブサーバが対象となる。
【００３８】
（スレーブサーバ監視機能）
マスターサーバは、スレーブサーバと定期的に通信し、稼働しているスレーブサーバを常に把握している。また、クライアントＰＣとスレーブサーバとの通信が行われ、その通信の終了時には、マスターサーバは、当該スレーブサーバとの間で通信することにより、当該スレーブサーバの通信状況を把握する。これによって、マスターサーバは、各スレーブサーバに接続しようとしているクライアントＰＣの数を把握することができる。
【００３９】
（通信負荷分散機能）
クライアントＰＣは、必ずマスターサーバに対してのみ通信要求を送信することとしている。クライアントＰＣからの要求において、ファイルの送信要求およびファイルの受信要求に対しては、当該クライアントＰＣとスレーブサーバとの間で通信が行われる。そのスレーブサーバは、前述したスレーブサーバ監視機能によって通信負荷が小さいとしてマスターサーバが選択したスレーブサーバである。マスターサーバは、クライアントＰＣへ選択したスレーブサーバのＩＰアドレスをクライアントへ通知し、そのＩＰアドレスによってクライアントＰＣとスレーブサーバとの間で通信が行われるのである。なお、マスターサーバ、スレーブサーバおよびクライアントＰＣとの間でどのように機能するかという詳細な説明は、図１７を用いて後述する。
【００４０】
（図７）
図７は、クライアントがサーバの起動を確認する処理を示す。文書管理サーバアプリケーションは、通信接続待ちの状態において、クライアントからの接続があった場合には、接続を確認し、クライアントから送信されるコマンドを受信する。コマンドを受信したら確認メッセージをクライアントへ送信する。コマンドを受信し、確認メッセージを受信したクライアントは受信内容を確認し、クライアント情報を送信する。サーバは、送信されたクライアント情報を受信したら、接続クライアント情報を登録する。そして、通信接続待ちの状態に戻る。
【００４１】
クライアントアプリケーション側について補足する。サーバへの接続確認がＮＧの場合には、サーバ起動確認フラグをリセットする。そして、所定周期でサーバに再接続を試みることとしている。また、サーバからの接続確認メッセージを受信し、受信内容を確認した結果がＮＧの場合には、サーバ起動確認フラグをリセットし、サーバとの接続を切断する。その後、所定周期でのサーバに再接続を試みることとしている。
【００４２】
（図８）
図８は、クライアントアプリケーションの起動時において、監視アプリケーションがファイル情報を取得、監視する処理を示す。文書管理サーバアプリケーションは、通信接続待ちの状態において、クライアントからの接続があった場合には、接続を確認し、クライアントは、初期情報をサーバに要求するコマンドを送信する。サーバは、そのコマンドを受信し、監視対象のアプリケーションのウィンドウタイトル名、ファイル拡張子名のリストを送信する。監視対象のリストを受信したクライアントは、そのリストを登録し、サーバとの接続を切断する。
【００４３】
（図９）
図９は、クライアントアプリケーションの作動を示す。ＯＳ上に現在存在する全ウィンドウのタイトル名の一覧を取得し、以下の処理をその一覧中にタイトル名がある間は繰り返す。すなわち、一覧中からウィンドウのタイトル名を取り出し、監視対象リストの中のタイトル名と比較する。同じタイトル名が存在する場合には、そのウィンドウに対して「ウィンドウ終了」のメッセージを送信し、自動的に終了させる。これを、ある一定周期で繰り返すのである。
【００４４】
（図１０）
図１０は、サーバのクライアント監視処理の作動を示す。文書管理サーバのアプリケーションが起動しているとする。まず、接続されているクライアントの情報を調査する。一定時間以上、通信が行われていないクライアントＰＣがあるかどうかを確認し、そのようなクライアントＰＣの一覧を取得する。
【００４５】
一覧の中にデータが存在する場合には、先頭のクライアントＰＣのデータを取り出し、当該クライアントＰＣが立ち上がっているかどうかを確認するため、ping/echoを送信する。Pingの結果、当該クライアントＰＣが立ち上がっていると判断した場合には、そのクライアント名を画面に表示して、サーバ管理者へ警告を発する。Pingの結果、当該クライアントＰＣが立ち上がっていないと判断した場合には、通信が行われていないクライアントＰＣの一覧に対して、先頭クライアントＰＣのデータを削除する。以上の操作を、前記一覧のデータがなくなるまで繰り返す。
【００４６】
繰り返した結果、一覧からデータがなくなったら、ある一定周期での監視体制に戻る。
【００４７】
（図１１）
図１１は、前述してきた処理方法とは異なる処理方法を示している。サーバの監視方法は、図１に示した方法と同様である。
【００４８】
クライアントＰＣにおいて、各種の文書作成アプリケーションを内蔵したアプリケーションと、文書作成用のアプリケーションとが起動されているとする。まず、内蔵アプリケーションが起動したら監視アプリケーションに接続する。一方、クライアントアプリケーションは、通信接続待ちをしており、監視アプリケーションの制御を受ける。内蔵アプリケーションは、サーバ起動状況の問い合わせを送信し、クライアントアプリケーションは、その問い合わせを受信する。そして、サーバ起動確認フラグの状況を送信し、内蔵アプリケーションが受信する。そして、クライアントアプリケーションとの接続を切断する。
【００４９】
この後、サーバのアプリケーションが起動しているかどうかを確認し、起動していない場合には、この内蔵アプリケーションを終了する。起動している場合には、内蔵アプリケーションをファイルに展開し、展開したアプリケーションを起動する。この時点で文書作成アプリケーション、例えばワードプロセッサーアプリケーション等が起動できる。
【００５０】
（図１２、図１３）
図１２および図１３は、クライアントＰＣにて作成された文書データを、サーバへ強制的に移動する作動、そして移動する際に当該文書データに関する属性を入力させるための処理を示す。初期処理としては、以下のような処理を行う。まず、ＰＣ上の有効なドライブを検索し、続いて各ドライブ内のディレクトリを検索する。そして、各ディレクトリにファイル変更イベント通知用のハンドラを設定し、続いて各ドライブにディレクトリ変更イベント通知用のハンドラを設定する。そこで、初期処理を終了する。
【００５１】
ファイル変更イベントが発生した場合の処理は、以下のような処理である。まず、イベント発生のディレクトリを特定する。そして、ディレクトリ内で監視対象リスト内の拡張子と同じ拡張子を持ったファイルを検索する。ファイルがない場合には処理を終了する。ファイルがあった場合には、ファイルを通信用のディレクトリにコピーし、コピーしたファイルを文書管理サーバへ送信する。そして、送信について成功したか否かをチェックし、成功していなければエラー処理をして処理を終了する。
【００５２】
送信が成功した場合には、文書管理サーバへコピーした元のファイルを削除する。削除できたかどうかをチェックし、できていない場合には、削除ファイルリストに当該ファイルを追加する。削除できている場合、あるいは削除ファイルリストに当該ファイルを追加した後、以前に属性入力を済ませたファイルかどうかを検証する。属性入力したファイルであれば処理を終了する。属性入力がされていないファイルの場合、属性入力画面を表示して入力を促す。そして、入力された属性を文書管理サーバへ送信する。送信が成功すれば処理を終了し、送信が成功しなければエラー処理をして終了する。
以上の処理によって、クライアントＰＣには、文書データが残らないこととなる。
【００５３】
（図１４）
図１４は、ファイル削除の処理フローと、ディレクトリ変更イベント発生時の処理フローとを示している。
削除ファイルリストのポインタを先頭にし、削除ファイルリストのポインタの位置から一つずつ順にファイル名を取り出す。そして、一覧中にファイルがまだあるかどうか検証する。ない場合には、所定周期が経過した後、削除ファイルリストのポインタを先頭にする処理から繰り返す。一覧中にファイルがまだある場合には、ファイルを削除し、削除できたかどうか検証する。削除できた場合には、削除ファイルリストからも当該ファイル名を削除し、ポインタを一つ進める。ファイルの削除ができなかった場合には、削除ファイルリストから当該ファイル名を削除せずにポインタを一つ進める。
【００５４】
ディレクトリ変更イベント発生時には、ハンドラをすべて解除する。そして、ＰＣ上の有効なドライブを検索し、各ドライブ内のディレクトリを検索する。そして、各ディレクトリにファイル変更イベント通知用のハンドラを設定し、各ドライブにもディレクトリ変更イベント通知用のハンドラを設定し、処理を終了する。
【００５５】
（図１５）
図１５は、管理文書の一覧表示の処理を示している。文書管理サーバにおけるアプリケーションとクライアントアプリケーションとが同時に起動しており、サーバのアプリケーションは通信接続待ちをしている。そして、クライアントからの接続があると、管理文書情報を要求するコマンドを受信したら、管理文書情報をクライアントへ送信する。その後、通信接続待ちとなる。
【００５６】
クライアントアプリケーションでは、サーバへの接続をし、管理文書情報を要求するコマンドを送信し、管理文書情報を受信する。そして、管理文書一覧の画面を表示させ、サーバとの接続を切断する。
【００５７】
（図１６）
図１６は、管理文書を編集した場合の処理を示している。
文書管理サーバにおけるアプリケーションとクライアントアプリケーションとが同時に起動しており、サーバのアプリケーションは通信接続待ちをしている。そして、クライアントから編集を希望する対象ファイル名の受信があると、当該ファイルをクライアントへ送信する。そして、そのファイルを排他ロック状態とする。ここにおいて、他のクライアントから当該ファイルの編集希望があってもそのファイルを送信しない。
【００５８】
クライアントアプリケーションでは、編集を希望する対象ファイル名を送信し、当該ファイルをサーバから受信する。そして、ファイルに関連したアプリケーションを起動してファイルを開かせたら、サーバとの接続を切断する。
【００５９】
（図１７）
図１７は、複数のサーバが存在する場合についての処理を示している。
サーバのうちの１台がマスターサーバとなり、残りはスレーブサーバとする。マスターサーバは、すべてのクライアントからの通信接続を待っている。そして、スレーブサーバの中でクライアントとの接続が最も少ないサーバまたは接続した時間がもっとも古いサーバのアドレスを、通信接続されたクライアントへ通知する。そして、アドレスの対象となったスレーブサーバの接続カウンタをひとつ加算し、次の通信接続待ち状態となる。
【００６０】
クライアントは、マスターサーバとの接続をし、マスターサーバが指定するアドレスを受信したら、マスターサーバとの接続を切断する。そして、指定されたアドレスのスレーブサーバへ接続する。そして、ファイルの送信または受信処理を行い、スレーブサーバとの接続を切断し、処理を終了するのである。スレーブサーバは、クライアントからの通信接続を待ち、クライアントとのファイルの受信または送信処理を行う。続いて、マスターサーバへ接続し、通信完了の通知を送信する。完了通知のマスターサーバ側の受信を確認したら、マスターサーバとの接続を切断する。
【００６１】
マスターサーバは、スレーブサーバからの通信接続を待っており、通信完了通知を受信した場合には、通信完了通知を受信した旨の確認を当該スレーブサーバへ送信する。そして、スレーブサーバの接続カウンタからひとつ減算をする。なお、クライアントＰＣとスレーブサーバとの間の通信後、何かのトラブルによってマスターサーバに通信終了通知が届かない場合が想定される。その場合には、送信時間から換算した予想最長通信時間を超過したら、自動的にスレーブサーバの接続カウンタを一つ減らすこととして対応する。
【００６２】
【発明の効果】
請求項１から請求項４記載の発明によれば、クライアント／サーバ構成における文書データの一元自動管理や、それに付随するデータ重要度の判断および整理を行える技術を提供することができた。
【図面の簡単な説明】
【図１】アプリケーション起動規制の概念を示す。
【図２】起動抑制機能付きロードモジュールの概念を示す。
【図３】文書の強制移動、属性入力、文書管理番号の自動付与の概念を示す。
【図４】文書の自動保管の概念を示す。
【図５】管理文書の一覧表示、文書の編集についての概念を示す。
【図６】拡張構成サーバについての制御方式の概念を示す。
【図７】クライアントがサーバの起動を確認する処理フローを示す。
【図８】監視アプリケーション、監視ファイル情報の取得処理フローを示す。
【図９】アプリケーション監視処理フローを示す。
【図１０】サーバのクライアント監視処理フローを示す。
【図１１】サーバのクライアント監視処理フローを示す。
【図１２】作成された文書データを、サーバへ強制的に移動する作動を示す。
【図１３】作成された文書データを、サーバへ強制的に移動する作動する際に当該文書データに関する属性を入力させるための処理を示す。
【図１４】ファイル削除の処理フローと、ディレクトリ変更イベント発生時の処理フローを示す。
【図１５】管理文書の一覧表示の処理を示す。
【図１６】管理文書を編集した場合の処理を示す。
【図１７】複数のサーバが存在する場合についての処理を示す。

Claims

クライアントＰＣにおいて文書管理サーバの起動を確認する起動確認手順と、
その起動確認手順によって文書管理サーバの起動を確認した場合に、クライアントＰＣにおいて文書作成アプリケーションの起動を許可するアプリケーション起動規制手順と、
クライアントＰＣにおいて所定のディレクトリ内のファイル変更イベントを監視するファイル変更イベント監視手順と、
ファイル変更イベントが発生した場合に、当該変更イベントが発生したディレクトリ内を検索して、監視対象とされた拡張子を持つファイルを抽出し、通信用のディレクトリに出力するファイル変更イベント通知手順と、
そのファイル変更イベント通知手順によって抽出されたファイルを文書管理サーバへ送信し、文書管理サーバへの送信が完了したファイルを送信済みファイルリストに登録する文書移動手順と、
その文書移動手順によって移動された文書データを、文書管理サーバにおいて蓄積する文書データ記憶手順と、
前記送信済みファイルリストに記載されたファイルにつき、一定周期でクライアントＰＣからの消去を試みるファイル消去手順と、
そのファイル消去手順によって消去が成功した場合には、当該ファイル名を送信済みファイルリストから削除するデータ消去手順とを備えた文書一括管理方法。
文書記憶手順にて蓄積された文書データが文書移動手順によって一のクライアントＰＣに送信された場合には、当該文書データを他のクライアントＰＣに送信不能とする排他ロック手順と、
文書移動手順および文書データ記憶手順によって当該文書データが再び蓄積された場合には、クライアントＰＣからの要求に応じて移動可能とするための排他ロック解除手順とを備えた請求項１に記載の文書一括管理方法。
文書管理サーバとクライアントＰＣを備えた文書一括管理システムであって、
前記文書管理サーバは、通信対象となる文書管理サーバのサーバ名または IP アドレス、監視対象アプリケーション名、または監視対象となるファイル拡張子情報を少なくとも含む初期データをクライアントＰＣに送信する送信手段と、クライアントＰＣから送信された文書データを蓄積する文書データ記憶手段とを備え、
前記クライアントＰＣは、
文書管理サーバに、前記初期データの送信を要求する初期データ要求手段と、
文書管理サーバから、前記初期データを受信する初期データ受信手段と、
文書管理サーバの起動を確認する文書管理サーバ起動確認手段と、
文書管理サーバから受信した前記初期データに係る監視対象アプリケーションが起動されていないかを監視するアプリケーション起動監視手段と、
前記文書管理サーバ起動確認手段によって文書管理サーバの起動が確認されず、かつ前記アプリケーション起動監視手段によって監視対象アプリケーションの起動が確認された場合において、前記初期データに係る監視対象アプリケーションを強制終了させるアプリケーション終了手段と、
所定のディレクトリ内におけるファイルの変更イベントを監視するファイル変更イベント監視手段と、
ファイルの変更イベントを検知すると、該変更イベントが発生したディレクトリ内を検索し、前記初期データ記載の監視対象とされたファイル拡張子をもつファイルがあった場合にはそのファイルを抽出する監視対象ファイル抽出手段と、
前記監視対象ファイル抽出手段によって抽出されたファイルを、文書管理サーバに送信する文書送信手段と、
文書管理サーバへの送信が完了したファイルを、送信済みファイルリストに登録する送信済みファイル登録手段と、
前記送信済みファイルリストに登録されたファイルにつき、一定周期でクライアントＰＣからの消去を試みるファイル消去手段と、
そのファイル消去手段によるファイルの消去が成功した場合に、当該ファイル名を送信済みファイルリストから削除するデータ消去手段とを備えることを特徴とする文書一括管理システム。
文書データ記憶手段によって蓄積された文書データが文書送信手段によって一のクライアントＰＣに送信された場合には、当該文書データを他のクライアントＰＣに送信不能とする排他ロック手段と、
文書データ記憶手段によって当該文書データが再び蓄積された場合には、クライアントＰＣからの要求に応じて移動可能とするための排他ロック解除手段とを備えた請求項３に記載の文書一括管理システム。