JP5373723B2 - 共有ファイル管理システム、その制御方法、およびプログラム - Google Patents

Description

本発明は、共有ファイル管理システム、その制御方法、およびプログラムに関し、特に、サーバ、複数のクライアント、およびこれらを相互に接続するネットワークから成り、前記サーバは前記複数のクライアントの各々がアクセス可能な共有ファイルを格納する共有ファイル管理システム、その制御方法、およびプログラムに関する。

従来、サーバに格納された一つの共有ファイルを複数のクライアントで共有しながら編集する場合、一のクライアントにて共有ファイルを編集するときにはこの共有ファイルを他のクライアントで編集できない状態（以下、「ロック状態」という。）とし、一のクライアントにて共有ファイルの編集が終了したのを確認してから他の共有クライアントで編集できる状態（以下、「アンロック状態」という。）とするのが一般的である。ここで、共有ファイルを読み出して編集するときにこの共有ファイルをロック状態とする作業を「チェックアウト」、共有ファイルの編集を終了してこの共有ファイルをアンロック状態とする作業を「チェックイン」という。

このような方法では、一つの共有ファイルを複数のクライアントが同時に編集してデータの不整合を生じてしまうことはないものの、一のクライアントが共有ファイルを長時間にわたって編集していると他のクライアントはこの共有ファイルの編集を行なうことができず、非効率的であった。

これに対し、一つの共有ファイルを複数の部分領域に分け、その部分領域ごとにクライアントによるアクセスを管理する技術が提案されている（たとえば、特許文献１参照）。この技術では、共有ファイルのうちある部分領域を編集するためにその部分領域にアクセスしたとしても、その部分領域がすでに一のクライアントによりロック状態とされている場合があり、この場合には他のクライアントは該当する部分領域を編集することはできず、仮にアクセスできたとしても編集はできない読み取り専用モードでのアクセスを余儀なくされてしまう。したがって、一のクライアントにてこの共有ファイルを編集しているユーザは、このような問題を生じることのないよう、共有ファイルの編集をしているときにはチェックイン・チェックアウトを念頭に入れなければならない。

特開２００５−３０１８３８号公報

しかしながら、共有ファイルの編集に携わるすべてのユーザがチェックイン・チェックアウトを行なうことに慣れているわけではないため、共有ファイルを編集すべくチェックアウトしたユーザが編集作業を終了した後にチェックインをするのを忘れてしまう場合がある。また、サーバや編集作業をしていたクライアント、またはこれらを接続するネットワークがダウンすることに伴い共有ファイルがチェックインされないまま放置される場合もある。このような場合、編集作業が終わっていたとしても共有ファイルがロック状態のまま長時間にわたって放置されることとなり、共有ファイルを効率よく管理することができなかった。

本発明は、上述した課題を解決するためになされたものであり、より効率よく共有ファイルを管理することのできる共有ファイル管理システム、共有ファイル管理システムの制御方法、およびプログラムを提供することを目的とする。

本発明に係る共有ファイル管理システムは、複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、一のクライアントの編集開始要求に基づいてこの一のクライアントのみが前記共有ファイルを編集できるロック状態とするとともに、前記一のクライアントからの編集終了要求に基づいて前記共有ファイルをロック状態が解除されたアンロック状態とする状態制御手段と、前記共有ファイルがロック状態またはアンロック状態であるかを表わす状態情報を記憶する状態情報記憶手段と、前記状態情報記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させる状態情報出力手段とを備えることを特徴とする。

前記状態制御手段は、前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とする。

さらに、 前記複数のクライアントの各々は、前記複数のクライアントのうち前記共有ファイルを編集している前記一のクライアントと前記ネットワークを介して通信する通信手段をさらに備えるものとしてもよい。

また、ロック状態とされた前記共有ファイルに対する他のクライアントからの編集開始要求を予め受け付け、前記状態制御手段に前記共有ファイルがアンロック状態となり次第この共有ファイルをロック状態として前記他のクライアントのみにその共有ファイルを編集させる予約手段をさらに備えるものとしてもよい。

さらに、前記共有ファイルが前記ロック状態とされてからの経過時間が閾値に達したときには、この共有ファイルを強制的に前記アンロック状態とする強制終了手段をさらに備えるものとしてもよい。

本発明に係る共有ファイル管理システムの制御方法は、複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、前記複数のクライアントのうち一のクライアントの編集開始要求または編集終了要求に基づいてそれぞれこの一のクライアントのみが前記共有ファイルを編集できるロック状態またはこのロック状態が解除されたアンロック状態とする状態制御ステップと、前記共有ファイルが前記ロック状態または前記アンロック状態であるかを少なくとも含む状態情報を記憶手段に記憶するステップと、前記記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させるステップとを備え、前記状態制御ステップは、前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とすることを特徴とする。

本発明に係るプログラムは、複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、前記複数のクライアントのうち一のクライアントの編集開始要求または編集終了要求に基づいてそれぞれこの一のクライアントのみが前記共有ファイルを編集できるロック状態またはこのロック状態が解除されたアンロック状態とする状態制御機能と、前記共有ファイルが前記ロック状態または前記アンロック状態であるかを少なくとも含む状態情報を記憶手段に記憶する機能、前記記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させる機能とをコンピュータに実現させ、前記状態制御機能は、前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とすることを特徴とする。

本発明によれば、共有ファイルがロック状態またはアンロック状態であるかを少なくとも含む状態情報を記憶し、共有ファイルの状態情報を複数のクライアントの各々に出力させることにより、クライアントを操作しているユーザは、共有ファイルが他のユーザによって編集中であるか否かを容易に把握することができるので、共有ファイルをより効率的に管理することができる。

また、共有ファイルを編集しているクライアントから編集終了要求がなされたときには、この編集終了要求がなされて所定時間が経過するのを待ってからこの共有ファイルをアンロック状態とすることにより、共有ファイルを編集しているクライアントが誤って編集終了要求をしたときでも、そのクライアントがその所定時間の間に再び編集開始要求をすれば、その共有ファイルが他のクライアントによってロック状態とされてしまうことを防ぐことができる。

さらに、複数のクライアントの各々が、クライアントのうち共有ファイルを編集しているものとの間でネットワークを介して連絡を取ることができるので、共有ファイルの編集を希望するクライアント同士で交渉をすることができる。これにより、共有ファイルの管理をより効率的に行なうことができる。

また、共有ファイルがロック状態であるときに複数のクライアントのいずれかから編集開始要求があったときには、この共有ファイルがアンロック状態となり次第このクライアントが編集できるよう予約を行なうことにより、この共有ファイルの編集作業を効率よく行なうことができる。

さらに、共有ファイルがロック状態とされてからの経過時間が閾値に達したときには、この共有ファイルをアンロック状態としてこの共有ファイルの編集作業を強制的に終了させることにより、共有ファイルがあるクライアントによって長時間にわたって編集されて、他のクライアントが編集することができなくなることを抑制できる。

本発明の実施の形態に係る共有ファイル管理システムの構成を示す図である。 本発明の実施の形態に係る共有ファイル管理システムのサーバの一構成例を示すブロック図である。 本発明の実施の形態に係る共有ファイル管理システムのクライアントの一構成例を示すブロック図である。 本発明の実施の形態に係る共有ファイル管理システムが格納する共有ファイル管理テーブルの一構成例を示す図である。 本発明の実施の形態に係る共有ファイル管理システムにおいてクライアント２から共有ファイルの編集開始要求を受け付けたときにサーバが実行する編集開始ルーチンを示すフローチャートである。 本発明の実施の形態に係る共有ファイル管理システムにおいてクライアントの表示部に表示される共有ファイルの状態を確認するための監視画面の一例を示す図である。 本発明の実施の形態に係る共有ファイル管理システムにおいてクライアントから共有ファイルの編集終了要求を受け付けたときにサーバが実行する編集終了ルーチンを示すフローチャートである。 本発明の実施の形態に係る共有ファイル管理システムの動作の一例を示すシーケンス図である。 本発明の実施の形態に係る共有ファイル管理システムにおいてサーバが実行する強制終了ルーチンを示すフローチャートである。 本発明の実施の形態に係る共有ファイル管理システムの変形例を示すブロック図である。

次に、本発明の実施の形態について図面を参照しながら詳細に説明する。なお、各図において、同一の構成要素に対して同一の符号を付している。

［実施の形態］
まず、図１〜３を参照して、本発明の実施の形態に係る共有ファイル管理システム１００の構成を説明する。本実施の形態に係る共有ファイル管理システム１００は、図１に示すように、サーバ１０と、Ｎ台のクライアント２０（２０−１〜２０−Ｎ）と、これらを相互に接続するＬＡＮ（Local Area Network）３０とから構成されている。

このうち、サーバ１０は、図示しない、ＣＰＵ、記憶装置、入出力装置、および通信インターフェースを備え、機能的には、図２に示すように、記憶部１１、状態制御部１２、状態情報記憶部１３、予約部１４、状態情報出力部１５、強制終了部１６、および通信部１７という各機能部を備えている。
記憶部１１は、クライアント２０（２０−１〜２０−Ｎ）の各々がアクセス可能な共有ファイルなどのデータを格納するものである。ここで、共有ファイルとは、複数のコンピュータ（クライアント２０）の各々がネットワーク（ＬＡＮ３０）を介してアクセスできるファイルのことをいう。
状態制御部１２は、クライアント２０からの編集開始要求に応じて共有ファイルをクライアント２０−１〜２０−Ｎのうち一のクライアントしか編集することができないロック状態にしたり、そのクライアントからの編集終了要求に応じてその共有ファイルのロック状態が解除されたアンロック状態とするものである。
状態情報記憶部１３は、記憶部１１に記憶された共有ファイルがロック状態であるかアンロック状態であるかを含む共有ファイルの状態情報を記憶するものである。
予約部１４は、ロック状態とされている共有ファイルに対してクライアント２０から編集開始要求があったときに、その共有ファイルのロック状態が解除され次第そのクライアント２０が編集できるよう予約を行なうものである。
状態情報出力部１５は、状態情報記憶部１３に記憶されている状態情報を読み出してクライアント２０に出力させるものである。
強制終了部１６は、共有ファイルがクライアント２０−１〜２０−Ｎのうち一のクライアントによりチェックアウトされてロック状態のまま長時間（たとえば、１０時間や２０時間など）が経過したときには、その共有ファイルを強制的にアンロック状態とするものである。
通信部１７は、ＬＡＮ３０を介してクライアント２０−１〜２０−Ｎと間で通信を行う機能を実現する。

一方、クライアント２０は、図示しない、ＣＰＵ、記憶装置、入出力装置、および通信インターフェースを備え、機能的には、図３に示すように、表示部２１、操作部２２、および通信連絡部２３を備えている。
表示部２１は、ディスプレイ装置など、各種画面を表示するものである。
操作部２２は、キーボードやマウスなど、ユーザの操作に基づいて、文字や数字、記号、方向などの信号をクライアント２０が備える図示しないＣＰＵへと入力するものである。
通信連絡部２３は、ＬＡＮ３０を介してサーバ１０や他のクライアント２０との間で通信を行なう機能を実現するものである。

次に、状態情報記憶部１３が記憶する共有ファイルの状態情報について説明する。
図４は、状態情報記憶部１３が格納する共有ファイル管理テーブルの構造の一例を示す図である。状態情報記憶部１３が格納する共有ファイル管理テーブルは、図４に示すように、「共有ファイルＩＤ」、「フラグＦ１」、「編集者ＩＤ」、「フラグＦ２」、「予約者ＩＤ」、および「更新時刻」というフィールドからなるレコードを含んでいる。
「共有ファイルＩＤ」は、共有ファイルを一意に特定するためのＩＤであり、たとえば各共有ファイルのパスや各共有ファイルに対して一意に付された文字列などを用いることができる。
「フラグＦ１」は、対応する共有ファイルがクライアント２０によって編集がなされているか否か、すなわちその共有ファイルがロック状態であるかアンロック状態であるかを示すものである。具体的には、その共有ファイルがアンロック状態であるときには値「０」が入力され、ロック状態であるときには値「１」が入力される。
「編集者ＩＤ」は、該当する共有ファイルが編集中であるときに、その共有ファイルを編集しているクライアントを一意に特定するためのＩＤを示すものであり、たとえばクライアントのＩＰアドレスや、ＭＡＣアドレス、認証したユーザ名などが入力される。このため、「フラグＦ１」の値が「１」であるときには、「編集者ＩＤ」によって特定されるクライアント２０以外の他のクライアント２０はその共有ファイルを編集することができない。なお、この共有ファイルが編集中ではないときには「フラグＦ１」の値は「０」、「編集者ＩＤ」のフィールドの値はＮＵＬＬとなる。
「フラグＦ２」は、その共有ファイルがあるクライアントによって編集中であるとき、すなわち「フラグＦ１」の値が「１」とされてロック状態となっているときに、他のクライアントが次に編集する権利の予約をしているか否かを示すものである。具体的には、その共有ファイルが予約されてないときには値「０」が入力され、すでに予約済みであるときには値「１」が入力される。
「予約者ＩＤ」は、この共有ファイルの編集権が予約されているときに、その共有ファイルの編集権を予約しているクライアントを一意に特定するためのＩＤを示すものであり、たとえばクライアントのＩＰアドレスや、ＭＡＣアドレス、認証したユーザ名などが入力される。したがって、この「フラグＦ２」の値が「１」である共有ファイルについて、編集作業が終了してそのロック状態が解除され次第、「予約者ＩＤ」により特定されるクライアント２０がその共有ファイルを編集することができることになる。なお、この共有ファイルが予約がなされていなければ、「フラグＦ２」の値は「０」、「予約者ＩＤ」のフィールドの値はＮＵＬＬとなる。
「更新時刻」は、該当するレコードに対応する共有ファイルの編集作業を開始した時刻、または編集作業の途中に保存された共有ファイルにあっては最後に保存された時刻を示すものである。これは、強制終了部１６が、共有ファイルがロック状態のまま長時間が経過したか否かを調べる際に用いられる。なお、該当するレコードに対応する共有ファイルが編集中でないときには、このフィールドの値はＮＵＬＬとなる。
状態情報記憶部１３は、この共有ファイル管理テーブルにデータを入力することによって共有ファイルの状態情報を記憶しているのである。

次に、共有ファイル管理システム１００における各動作を説明する。

まず、クライアント２０を操作するユーザが、表示部２１に表示された共有ファイルをクリックするなど所定の操作をし、編集用プログラムを用いてこの共有ファイルの編集作業を開始しようとした場合における、共有ファイル管理システム１００の動作を説明する。このように、クライアント２０を操作するユーザが共有ファイルの編集作業を開始しようとすると、通信連絡部２３はサーバ１０に対して共有ファイルの編集開始要求を通知する信号を送信する。サーバ１０は、クライアント２０から編集開始要求が通知されると、共有ファイル管理テーブルを参照したうえで、編集作業を承認するか否かを決定する。以下、フローチャートを用いてその内容を説明する。

図５は、本発明の実施の形態に係る共有ファイル管理システム１００においてサーバ１０がＬＡＮ３０を介してクライアント２０から共有ファイルの編集開始要求を受け付けたときに実行する編集開始ルーチンを示すフローチャートである。
はじめに、サーバ１０が、クライアント２０から共有ファイルＩＤおよびそのクライアント２０を特定するＩＤ（以下、「クライアントＩＤ」という。）とともに、共有ファイルの編集開始要求を受け付けると、クライアント２０は共有ファイル管理テーブルを参照し、該当する共有ファイルに対応するレコードの「フラグＦ１」および「フラグＦ２」を読み込み（ステップＳ１００）、「フラグＦ１」の値が「０」であるか否かを調べる（ステップＳ１１０）。

その結果、読み込んだ「フラグＦ１」の値が「０」であるときは（ステップＳ１１０；ＹＥＳ）、この共有ファイルは編集中ではないと判断し、この共有ファイルをチェックアウトする処理、すなわちこのクライアント２０がこの共有ファイルを排他的に編集できるようロック状態にする処理を行なう。
具体的には、まず、状態制御部１２が、共有ファイルＩＤで紐づけられたレコードの「フラグＦ１」の値を「１」に更新すると共に「編集者ＩＤ」にこのクライアント２０のクライアントＩＤを入力し、「更新時刻」に現在時刻を入力する（ステップＳ１２０）。このように、「フラグＦ１」の値を「１」に更新することにより、状態制御部１２は「編集者ＩＤ」によって特定されるクライアント２０以外のクライアント２０がこの共有ファイルへアクセスするのを制限する。
次いで、通信部１７が、このクライアント２０に対して該当する共有ファイルをダウンロードし（ステップＳ１３０）、この共有ファイルが編集中となった旨をすべてのクライアント２０−１〜２０−Ｎに対して通知して（ステップＳ１４０）、編集開始ルーチンを終了する。

ステップＳ１４０の処理によって、クライアント２０−１〜２０−Ｎにおいて、該当する共有ファイルが編集中となった旨は次のように出力される。
図６に、ビル管理システムに関わる複数の共有ファイルを対象とする場合を例にとって、本発明の実施の形態に係る共有ファイル管理システム１００においてクライアント２０の表示部２１に表示される共有ファイルの状態を確認するための監視画面の一例を示す。図６（ａ）はすべての共有ファイルについてアンロック状態であるときの監視画面、図６（ｂ）はある共有ファイルがロック状態であるときの監視画面を示している。図６に示すように、ビルのエリア毎に表示された各共有ファイルの共有ファイル名の横にはその共有ファイルの状態を示すアイコンがついており、アンロック状態であるときは白抜きの四角形だったアイコンが、ロック状態となることにより「×」印のついた四角形のアイコンに変化している。このため、クライアント２０を操作するユーザはこの画面を開いて共有ファイルの前にあるアイコンの状態を確認することによって、この共有ファイルが編集中であるか否かを確認することができるのである。
また、クライアント２０を操作しているユーザは、たとえば、編集中でロック状態となっている共有ファイルの共有ファイル名をクリックすることにより、通信連絡部２３の機能を用いてその共有ファイルを編集しているクライアント２０に対してメッセージを送信したり通話を行なうこともできる。このように、クライアント２０で共有ファイルの監視画面を開いてその画面上で所定の操作をすることにより、共有ファイルの編集を希望するユーザ同士で連絡を取り合い、共有ファイルのロック状態を解除するよう交渉することができる。
なお、本実施の形態ではツリー構造の監視画面を例にとって説明しているが、共有ファイルの状態が確認できる出力状態であれば表示の形態はどのようなものであってもよく、たとえばテーブル形状で表示してもよい。

図５のステップＳ１１０の処理の説明に戻る。
ステップＳ１１０の処理において、「フラグＦ１」の値が「１」であるときは（ステップＳ１１０；ＮＯ）、この共有ファイルは編集中であると判断し、「フラグＦ２」の値が「０」であるか否かをさらに判断する（ステップＳ１５０）。
「フラグＦ２」の値が「０」であるときは（ステップＳ１５０；ＹＥＳ）、この共有ファイルは未だ予約がなされていないと判断して予約部１４は予約処理を行なう。具体的には、「フラグＦ２」の値を「１」に更新すると共に「予約者ＩＤ」にこのクライアント２０のクライアントＩＤを入力して（ステップＳ１６０）、編集開始ルーチンを終了する。現在編集をしているクライアント２０から予約処理を行なったクライアント２０へ、共有ファイルの編集をする権限が移動するタイミングについては、後述することにする。なお、ステップＳ１６０の予約処理を行なう前に、クライアント２０の表示部２１にポップアップを表示して予約を行なうか否かについてユーザの意志を確認する処理を行なってもよい。
これに対して「フラグＦ２」の値が「１」であるときは（ステップＳ１５０；ＮＯ）、この共有ファイルはすでに予約済みであると判断し、予約部１４は予約処理を行なわずに編集開始ルーチンを終了する。

次に、クライアント２０を操作するユーザが、共有ファイルの編集を行なうためのプログラムを終了したり、このプログラム上で編集していた共有ファイルを閉じるなどして編集作業を終了した場合における、共有ファイル管理システム１００の動作を説明する。このように、クライアント２０を操作するユーザが共有ファイルの編集作業を終了すると、通信連絡部２３はサーバ１０に対して共有ファイルの編集終了要求を通知する信号を送信する。サーバ１０は、クライアント２０から編集終了要求が通知されると、共有ファイル管理テーブルを参照し、この共有ファイルに予約処理が施されているか否かを参照したうえで、共有ファイルのロック状態を解除する。以下、フローチャートを用いてその内容を説明する。

図７は、本発明の実施の形態に係る共有ファイル管理システム１００においてサーバ１０がクライアント２０から共有ファイルの編集終了要求を受け付けたときに実行する編集終了ルーチンを示すフローチャートである。
まず、状態制御部１２が、所定時間（たとえば、１０秒や２０秒など）以内に再び同じクライアント２０から編集開始要求（すなわち、編集終了要求のキャンセル）がないかを確認する（ステップＳ２００）。
所定時間以内に同じクライアント２０から再び編集開始要求があったときには（ステップＳ２００；ＮＯ）、後述するチェックインをせずに、編集終了ルーチンを終了する。このため、共有ファイルのロック状態は解除されず、同じクライアントが継続してその共有ファイルを編集することができる。
このように、状態制御部１４が所定時間にわたって同じクライアント２０からの編集開始要求のみを受け付けることとしたのは、クライアント２０を操作しているユーザが誤ってプログラムを終了するなどして共有ファイルの編集作業を終了してしまったときに、他のクライアント２０によりその共有ファイルがロック状態とされて編集ができなくなってしまうのを防ぐためである。

これに対し、所定時間以内に同じクライアント２０から再び編集開始要求がないときには（ステップＳ２００；ＹＥＳ）、この共有ファイルをチェックインするため、すなわちこの共有ファイルのロック状態を解除してアンロック状態とするため、以下の処理を行なう。
まず、共有ファイル管理テーブルを参照して、該当する共有ファイルのレコードの「フラグＦ２」を読み込み（ステップＳ２１０）、この「フラグＦ２」の値が「０」であるか否かを判断する（ステップＳ２２０）。
読み込んだ「フラグＦ２」の値が「０」であるときには（ステップＳ２２０；ＹＥＳ）、この共有ファイルは予約されていないものと判断し、状態制御部１２はチェックインの処理を行なう。
具体的には、状態制御部１２が「フラグＦ２」の値を「０」に更新し、「編集者ＩＤ」の値をＮＵＬＬに更新し、「更新時刻」の値をＮＵＬＬに更新する（ステップＳ２３０）。また、通信部１７がこの共有ファイルが編集可能となった旨を全クライアントに対して通知し（ステップＳ２４０）、編集終了ルーチンを終了する。ここで、通信部１７が共有ファイルが編集可能となった旨をクライアント２０−１〜２０−Ｎに対して通知すると、上述したように、クライアント２０−１〜２０−Ｎの表示部２１にて、共有ファイルの状態の監視画面を開いて共有ファイルの共有ファイル名の横にあるアイコンを確認すれば、「×」印のついた四角形から白抜きの四角形に変化しているのが分かる。このため、ユーザはこの監視画面を開けば該当する共有ファイルが編集中であるか否かを容易に判断することができるのである。

一方、読み込んだ「フラグＦ２」の値が「１」であるときには（ステップＳ２２０；ＮＯ）、この共有ファイルは予約されているものと判断し、状態制御部１２はこの共有ファイルの編集を予約していたクライアント２０に対して編集を承認する処理を行なう。
具体的には、状態制御部１２は、「編集者ＩＤ」に「予約者ＩＤ」を入力し、「予約者ＩＤ」をＮＵＬＬに更新し、「フラグＦ２」の値を「０」に更新する（ステップＳ２５０）。通信部１７は予約していたクライアント２０に対して共有ファイルのダウンロードを実行すると共にこの共有ファイルに対する編集要求が承認された旨を通知し（ステップＳ２６０）、編集終了ルーチンを終了する。ここで、予約していたクライアント２０に対して編集要求が承認された旨を通知する方法としては、たとえば予約をしたクライアント２０の表示部２１にて上述した共有ファイルの監視画面を開いたときに、編集要求が承認された旨をポップアップにより表示したり、あるいはチャイムを生成したりする方法が挙げられる。このように、予約していたクライアント２０に対して編集要求が承認された旨を通知する処理を行なうので、クライアント２０を操作しているユーザは、共有ファイルの状態を確認するためにわざわざサーバ１０にアクセスする必要がなくなり、共有ファイルの編集要求が承認された旨の通知を待ちながら、他の作業に集中することができるのである。

次に、本発明の実施の形態に係る共有ファイル管理システム１００の動作の一例を図８に示すシーケンス図を用いて説明する。
なお、説明の便宜上、このシーケンス図ではクライアント２０−１およびクライアント２０−２という２台のクライアントのみが描かれているが、クライアント２０の台数が２台に限られないのは言うまでもない。

まず、クライアント２０−１を使用しているユーザが、サーバ１０に格納されている共有ファイルの編集を開始するための所定の操作を実行すると、クライアント２０−１からサーバ１０に対して編集開始要求が送信され（ステップＳ３００）、サーバ１０は、図５を用いて説明した編集開始ルーチンを実行する（ステップＳ３１０）。ここで、編集開始要求がなされた共有ファイルは誰にも編集されておらず、共有ファイル管理テーブルの該当するレコードの「フラグＦ１」の値は「０」となっているものとする。すると、編集開始要求が承認されるので、図５のステップＳ１２０、Ｓ１３０、Ｓ１４０で説明した通常のチェックアウト処理、すなわち共有ファイル管理テーブルの該当レコードの「フラグＦ１」の値を「１」に更新し、「編集者ＩＤ」にクライアント２０−１のクライアントＩＤを入力し、「更新時刻」に現在時刻を入力し、クライアント２０−１に対して共有ファイルのダウンロードを行ない、クライアント２０−１、２０−２に対してこの共有ファイルがロック状態となった旨を通知する処理を行なう。

次いで、ライアント２０−２を操作しているユーザが、同一の共有ファイルを編集するための操作を行なうと、クライアント２０−２からサーバ１０に対してこの共有ファイルに対する編集開始要求が送信され（ステップＳ３２０）、サーバ１０は再び図５で説明した編集開始ルーチンを実行する（ステップＳ３３０）。ここで、編集開始要求がなされた共有ファイルはすでにクライアント２０−１によって編集されており、共有ファイル管理テーブルの該当するレコードの「フラグＦ１」の値は「１」となっている。このため、クライアント２０−２からの編集開始要求は認められず、図５のステップＳ１５０で「フラグＦ２」の値が「０」であるか否かが判断される。この共有ファイルはまだ編集の予約がなされておらず「フラグＦ２」の値が「０」となっていれば、図５のステップＳ１６０で「フラグＦ２」の値を「１」に更新すると共に「予約者ＩＤ」にクライアント２０−２のクライアントＩＤを入力する。

次いで、クライアント２０−１を操作しているユーザがダウンロードした共有ファイルを上書き保存する操作を行なうと、この共有ファイルがサーバ１０にアップロードされる（ステップＳ３４０）。さらに、編集用プログラム上でこの共有ファイルを閉じるなどしてその編集作業を終了すると、クライアント２０−１からサーバ１０に対して編集終了要求が送信され（ステップＳ３５０）、サーバ１０は図７を用いて説明した編集終了ルーチンを実行する（ステップＳ３６０）。ここで、すでにクライアント２０−２によって共有ファイルを次に編集できるよう予約がなされ、共有ファイル管理テーブルの該当レコードの「フラグＦ２」の値が「１」となっているため、図７のステップＳ２５０で共有ファイル管理テーブルの該当レコードの「編集者ＩＤ」に「予約者ＩＤ」の値を入力し、「予約者ＩＤ」の値をＮＵＬＬに更新し、「フラグＦ２」の値を「０」に更新した後、図７のステップＳ２６０でクライアント２０−２に対して共有ファイルをダウンロードすると共にこの共有ファイルの編集が承認された旨を通知する。この結果、クライアント２０−２を操作しているユーザは、クライアント２０−１による編集が終わり次第、即座に編集が承認されたことを把握でき、すぐに共有ファイルの編集作業にとりかかることができる。

クライアント２０−２を操作しているユーザが、共有ファイルの上書き保存をする操作を行なうと、この共有ファイルがサーバ１０にアップロードされる（ステップＳ３７０）。さらに、編集用プログラム上でこの共有ファイルを閉じるなどしてその編集作業を終了すると、クライアント２０−２からサーバ１０に対して編集終了要求が送信され（ステップＳ３８０）、サーバ１０は再び図７を用いて説明した編集終了ルーチンを実行する（ステップＳ３９０）。ここで、上述したステップＳ３６０の処理にて、共有ファイル管理テーブルの該当するレコードにおいて「フラグＦ２」の値は「０」に更新されて、その共有ファイルに対する予約が解除されている。このため、図７のステップＳ２２０にて肯定的な判断がなされ、図７のステップＳ２３０にて共有ファイル管理テーブルの該当するレコードの「フラグＦ１」の値を「０」に更新し、「編集者ＩＤ」の値をＮＵＬＬに更新し、「更新時刻」の値をＮＵＬＬに更新し、図７のステップＳ２４０にてクライアント２０−１、２０−２に対して共有ファイルが編集可能となった旨を通知する。この結果、クライアント２０−１、２０−２を操作しているユーザはわざわざサーバ１０にアクセスして問い合わせをすることなく、共有ファイルが編集可能となったことを把握することができるのである。
なお、上述したように、共有ファイルのアップロード（ステップＳ３７０）と、共有ファイルの編集終了要求（ステップＳ３８０）とは互いに独立した処理となっている。これは、クライアント２０がシステムダウンしたときに備えて、ユーザは、共有ファイルの編集作業の途中であっても、それまで編集した内容をこまめにサーバ１０にアップロードしたいという要望があるためである。

最後に、長時間にわたってロック状態とされた共有ファイルについて、強制終了部１６がそのロック状態を強制的に解除する仕組みを説明する。
図９は、サーバ１０が実行する強制終了ルーチンを示すフローチャートである。このフローチャートは、所定時間毎（たとえば、数十分毎や数時間毎）に実行される。

まず、共有ファイル管理テーブルからレコードを一つ取り出す（ステップＳ４００）。ここで、取り出すレコードとしては、共有ファイル管理テーブルに格納されているレコードのうち、「フラグＦ１」の値が「１」であるもの、すなわちロック状態とされているものを抽出して取り出せばよい。
次いで、このレコードの「更新時刻」を読み出し、「更新時刻」からの経過時間ΔＴを演算する（ステップＳ４１０）。この「更新時刻」は、対応する共有ファイルの編集作業が開始された時刻、または編集作業の途中に上書き保存された共有ファイルにあっては最後に上書きされた時刻が入力されている。このため、経過時間ΔＴは、編集中の共有ファイルが一度も上書き保存されていないときにはその編集作業を開始してからの経過時間を示し、編集作業の途中に上書き保存された共有ファイルについては最後に上書き保存されてからの経過時間を示すこととなる。

続いて、こうして演算した経過時間ΔＴを、閾値Ｔ１およびこれより大きい閾値Ｔ２と比較する（ステップＳ４２０）。ここで、閾値Ｔ２は、すでに共有ファイルの編集作業が終了しているにもかかわらずロック状態とされていると予測できる程度の時間として設定され、たとえば１０〜２０時間などに設定される。また、閾値Ｔ１は、閾値Ｔ２より１〜２時間ほど短い時間として設定され、ロック状態の共有ファイルを強制的にアンロック状態にする前にその予告を行なうために用いるものである。

経過時間ΔＴが閾値Ｔ１未満であるときには（ステップＳ４２０；ΔＴ＜Ｔ１）、共有ファイルが長時間にわたってロック状態とされているわけではないので、強制終了に関わる処理は実行しない。
経過時間ΔＴが閾値Ｔ１以上かつ閾値Ｔ２未満であるときには（ステップＳ４２０；Ｔ１≦ΔＴ＜Ｔ２）、しばらくすると経過時間ΔＴが閾値Ｔ２以上となり、後述するように共有ファイルの編集処理を強制終了することとなるため、このレコードに対応する共有ファイルを編集しているユーザに対して共有ファイルの保存を促すポップアップを表示する（ステップＳ４３０）。なお、ポップアップの表示内容として、共有ファイルの保存を促すメッセージとともに、強制終了処理が実行されるまでの残り時間を表示させるようにしてもよい。
経過時間ΔＴが閾値Ｔ２以上となったときには（ステップＳ４２０；Ｔ２＜ΔＴ）、すでに共有ファイルの編集作業が終了しているにもかかわらず共有ファイルがロック状態のまま放置されていると判断し、強制終了処理を実行する。具体的には、図７を用いて説明した編集終了ルーチンを実行することによって（ステップＳ４４０）、その共有ファイルに対して予約がないときにはロック状態を解除してアンロック状態とし、その共有ファイルに対して予約があるときには予約をしたクライアントに対して編集作業の承認をする。このような処理を実行することにより、共有ファイルが一のクライアント２０によって長時間にわたってロック状態とされ、他のクライアント２０が編集できなくなる事態を抑制できる。この際、所定時間にかぎり編集をしているクライアントから編集要求を受け付ける図７のステップＳ２００は省略してもよい。編集終了ルーチンを実行した後、共有ファイルを長時間にわたってロック状態としていたユーザに対して、共有ファイルの編集作業を強制終了した旨をポップアップにより通知する（ステップＳ４５０）。

このようなステップＳ４００〜Ｓ４５０の処理を、共有ファイル管理テーブルの全てのレコードについて実行したのを確認してから（ステップＳ４６０）、強制終了ルーチンを終了する。このようにして、共有ファイルのうち一のクライアント２０によって長時間にわたってロック状態とされているものがあればそのロック状態を強制的に解除するので、共有ファイルの編集作業を効率よく行なうことができる。また、ロック状態を強制的に解除する前にはその共有ファイルを編集しているユーザに対して共有ファイルの保存を促す通知を行なうので（ステップＳ４３０）、共有ファイルの編集作業が継続しているにもかかわらず強制的にロック状態を解除してしまうことも抑制できるのである。

以上説明した、本実施の形態に係る共有ファイル管理システム１００によれば、サーバ１０は、共有ファイル管理テーブルにおいて、共有ファイルがロック状態またはアンロック状態であるかを示す「フラグＦ１」の値を記憶し、この「フラグＦ１」の値が更新されると全てのクライアント２０に対してその通知している（図５のステップＳ１４０、図７のステップＳ２４０）。クライアント２０のユーザは、表示部２１にて、共有ファイルの状態を管理するための監視画面を開いて、共有ファイルの前にあるアイコンの状態を確認することによって容易にその共有ファイルが編集中であるか否かを把握することができる。したがって、共有ファイルを効率的に管理することができるのである。

また、本実施の形態に係る共有ファイル管理システム１００では、共有ファイルの編集をしていたクライアント２０からサーバ１０に対して編集終了要求があったときでも、サーバ１０は所定時間（たとえば、１０秒や２０秒など）以内に再び同じクライアント２０から編集開始要求がないかを確認している（図７のステップＳ２００）。このため、共有ファイルを編集しているユーザが誤って共有ファイルの編集作業を終了してしまったときでも、そのユーザが所定時間の間に再びその共有ファイルの編集作業を開始するための操作をすれば、その共有ファイルが他のクライアント２０によってロック状態とされて編集できなくなることを防ぐことができる。

さらに、本実施の形態に係る共有ファイル管理システム１００では、クライアント２０を操作するユーザは、図６に示した共有ファイル監視画面を開いて、所定の操作をすることにより、通信連絡部２３の機能を用いて共有ファイルの編集を希望するユーザ同士で連絡を取り合い、共有ファイルのロック状態を解除するよう交渉することができる。このため、共有ファイルの編集作業を効率よく行なうことができる。

また、本実施の形態に係る共有ファイル管理システム１００では、サーバ１０は、共有ファイルがあるクライアント２０により編集中でロック状態とされているときに、他のクライアント２０から編集開始要求があったときには、次にその共有ファイルを編集することができるよう予約を行ない（図５のステップＳ１６０）、編集作業が終わり次第、共有ファイルのダウンロードをして編集を承認した旨を通知するので（図７のステップＳ２５０、Ｓ２６０）、共有ファイルの編集作業を効率的に行なうことができる。

さらに、本実施の形態に係る共有ファイル管理システム１００では、サーバ１０が図９で説明した強制終了ルーチンを実行することにより、共有ファイルのうち一のクライアント２０によって長時間にわたってロック状態とされているものがあればそのロック状態を強制的に解除するので、共有ファイルの編集作業を効率よく行なうことができる。

［変形例］
なお、上述した実施の形態に係る共有ファイル管理システム１００では、記憶部１１と、状態制御部１２、状態情報記憶部１３、予約部１４、状態情報出力部１５、および強制終了部１６とは、いずれも同一のサーバ１０に備わるものとして説明したが、図１０に示すように、それぞれ別々のサーバに備わるものとしてもよい。
図１０に示した例では、サーバ１０−１が記憶部１１を備え、サーバ１０−２が状態制御部１２、状態情報記憶部１３、予約部１４、状態情報出力部１５、および強制終了部１６を備えている。
この場合、図５のステップＳ１３０や図７のステップＳ２６０で説明した共有ファイルをクライアント２０に対してダウンロードする処理についてはサーバ１０−１が実行し、それ以外の処理についてはサーバ１０−２が行なうこととなる。

また、上述した実施の形態に係る共有ファイル管理システム１００では、図５のステップＳ１４０や図７のステップＳ２４０の処理で説明したように、共有ファイルの状態がロック状態とアンロック状態との間で変動したときには、サーバ１０から全てのクライアント２０に対して通知するものとして説明したが、通知しないものとしてもよい。この場合、たとえば、クライアント２０の各々が、所定時間毎（たとえば、数分毎や数十分毎など）に共有ファイル管理テーブルの変動を問い合わせるためのＳＱＬをサーバ１０に向かって発信するものとすればよい。
あるいは、サーバ１０から全てのクライアント２０に対する通知は、共有ファイル管理テーブルに変動があった旨だけであり、これを引き金としてクライアント２０（２０−１〜２０−Ｎ）の各々がその具体的な内容を問い合わせるＳＱＬ文をサーバ１０に対して送信するものとしてもよい。

また、上述した実施の形態に係る共有ファイル管理システム１００では、サーバ１０と、クライアント２０（２０−１〜２０−Ｎ）とは、ＬＡＮ３０により接続されているが、ＬＡＮ３０ではなくインターネット網を介して接続されているものとしてもよい。

さらに、上述した実施の形態の図７の編集終了ルーチンにおいて、所定時間にわたって共有ファイルを編集しているクライアントから編集開始要求（編集終了要求のキャンセル）を受け付けるステップＳ２００の処理を省略してもよい。

また、上述した実施の形態に係る共有ファイル管理システム１００では、予約は一のクライアント２０しかできないものとして説明しているが、複数のクライアント２０から予約を受け付けるものとしてもよく、この際、たとえばその予約を受け付けた順にクライアント２０が編集することができるようにしてもよい。

さらに、上述した実施の形態に係る共有ファイル管理システム１００において、サーバ１０は予約部１４や強制終了部１６を備えるが、これらを備えないものとしてもよい。

また、上述した実施の形態では、本発明を共有ファイル管理システム１００の形態として説明したが、共有ファイル管理システム１００の制御方法の形態や共有ファイル管理システム１００に組み込まれるプログラムの形態としてもよい。

なお、上述した実施の形態において、サーバ１０やクライアント２０が備える各機能部は、サーバ１０やクライアント２０がそれぞれ備えるＣＰＵ、記憶装置、および外部機器とのインターフェースなどのハードウェア資源と、これらのハードウェア資源を制御するプログラムとが協働することによって実現することができる。この共有ファイル管理システム１００の制御方法を実現するためのプログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはメモリカードなどの記録媒体に記録された状態で提供される。ＣＰＵは、記録媒体から読み込んだプログラムを記憶装置に書き込み、プログラムにしたがって実施の形態で説明した処理を実行する。

本発明は共有ファイル管理システムの製造業などに利用可能である。

１０（１０−１、１０−２）…サーバ、１１…記憶部、１２…状態制御部、１３…状態情報記憶部、１４…予約部、１５…状態情報出力部、１６…強制終了部、１７…通信部、２０（２０−１〜２０−Ｎ）…クライアント、２１…表示部、２２…操作部、２３…通信連絡部、３０…ＬＡＮ、１００…共有ファイル管理システム。

Claims (6)

1. 複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、一のクライアントの編集開始要求に基づいてこの一のクライアントのみが前記共有ファイルを編集できるロック状態とするとともに、前記一のクライアントからの編集終了要求に基づいて前記共有ファイルをロック状態が解除されたアンロック状態とする状態制御手段と、
   前記共有ファイルがロック状態またはアンロック状態であるかを表わす状態情報を記憶する状態情報記憶手段と、
   前記状態情報記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させる状態情報出力手段と
   を備え、
   前記状態制御手段は、
   前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とする
   ことを特徴とする共有ファイル管理システム。
2. 請求項１に記載の共有ファイル管理システムにおいて、
   前記複数のクライアントの各々は、
   前記複数のクライアントのうち前記共有ファイルを編集している前記一のクライアントと前記ネットワークを介して通信する通信手段
   をさらに備えることを特徴とする共有ファイル管理システム。
3. 請求項１または２に記載の共有ファイル管理システムにおいて、
   ロック状態とされた前記共有ファイルに対する他のクライアントからの編集開始要求を予め受け付け、前記状態制御手段に前記共有ファイルがアンロック状態となり次第この共有ファイルをロック状態として前記他のクライアントのみにその共有ファイルを編集させる予約手段
   をさらに備えることを特徴とする共有ファイル管理システム。
4. 請求項１〜３のいずれかに記載の共有ファイル管理システムにおいて、
   前記共有ファイルが前記ロック状態とされてからの経過時間が閾値に達したときには、この共有ファイルを強制的に前記アンロック状態とする強制終了手段
   をさらに備えることを特徴とする共有ファイル管理システム。
5. 複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、前記複数のクライアントのうち一のクライアントの編集開始要求または編集終了要求に基づいてそれぞれこの一のクライアントのみが前記共有ファイルを編集できるロック状態またはこのロック状態が解除されたアンロック状態とする状態制御ステップと、
   前記共有ファイルが前記ロック状態または前記アンロック状態であるかを少なくとも含む状態情報を記憶手段に記憶するステップと、
   前記記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させるステップと
   を備え、
   前記状態制御ステップは、
   前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とする
   ことを特徴とする共有ファイル管理システムの制御方法。
6. 複数のクライアントの各々がネットワークを介してアクセス可能な共有ファイルについて、前記複数のクライアントのうち一のクライアントの編集開始要求または編集終了要求に基づいてそれぞれこの一のクライアントのみが前記共有ファイルを編集できるロック状態またはこのロック状態が解除されたアンロック状態とする状態制御機能と、
   前記共有ファイルが前記ロック状態または前記アンロック状態であるかを少なくとも含む状態情報を記憶手段に記憶する機能、
   前記記憶手段に記憶された前記共有ファイルの状態情報を前記複数のクライアントの各々に出力させる機能と
   をコンピュータに実現させ、
   前記状態制御機能は、
   前記一のクライアントから前記編集終了要求がなされた後、この編集終了要求がなされて所定時間が経過するまでに、前記一のクライアントから前記編集開始要求がなされない場合にはこの共有ファイルをアンロック状態とし、前記一のクライアントから前記編集開始要求がなされた場合にはこの共有ファイルをロック状態とする
   ことを特徴とするプログラム。

Images