ファイル管理システム、ファイル管理プログラム及びファイル管理方法
【課題】有用なファイルを効率的に検索するファイル管理システムを提供する。
【解決手段】ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じてファイルを提供するファイルサーバを備えるファイル管理システムであって、ファイルサーバは、ネットワークと接続するインターフェイスと、プログラムを実行するプロセッサと、プログラム及びプログラムが使用する情報を格納するメモリと、ファイルを格納するストレージ装置とを備え、メモリは組織を構成する部署を記録した組織情報を格納し、プロセッサは、ファイルのアクセス履歴を記録し、組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署についてファイルの有用性が高いと判定し、有用性が高いと判定されたファイルを検索する。
【解決手段】ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じてファイルを提供するファイルサーバを備えるファイル管理システムであって、ファイルサーバは、ネットワークと接続するインターフェイスと、プログラムを実行するプロセッサと、プログラム及びプログラムが使用する情報を格納するメモリと、ファイルを格納するストレージ装置とを備え、メモリは組織を構成する部署を記録した組織情報を格納し、プロセッサは、ファイルのアクセス履歴を記録し、組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署についてファイルの有用性が高いと判定し、有用性が高いと判定されたファイルを検索する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル共有システムに関し、特に、ファイルサーバに格納されたファイルを管理する技術に関する。
【背景技術】
【０００２】
近年、業務効率を向上させるために多くの組織がファイル共有システムを導入している。ファイル共有システムでは、メンバ間で活用可能なファイルをファイル所有者がファイルサーバに登録することによって、他のメンバも登録されたファイルを利用することができる。
【０００３】
例えば、あるメンバが新製品の特徴及びメリットを顧客に効果的に紹介する資料を作成すれば、他のメンバも作成された製品紹介資料を活用できる。ファイル共有システムでは、資料作成者が新製品の製品紹介資料をファイルサーバに登録すると、他のメンバは新製品を顧客に紹介する際にこの製品紹介資料を容易に入手することができ、同種の資料を作成する手間を省くことができる。
【０００４】
このようなファイル共有システムは、いくつかの特許文献に開示される技術によって利便性の向上が図られている。例えば、特許文献１では、有用なファイルをファイルサーバに登録することを促進するための技術が開示されている。詳細には、ファイルサーバにファイルを登録したメンバに、人事評価に影響するポイントが付与される。
【０００５】
また、特許文献２では、ファイルサーバに登録されたファイルをより多くのメンバが活用するための技術が開示されている。詳細には、登録されたファイルからキーワードを抽出し、キーワードと、部署などのグループに対応付けられたキーワードが一致すれば、ファイルが登録されたことをキーワードが一致した部署のメンバに通知する。
【０００６】
さらに、特許文献３では、共有ファイルの検索結果を並び替える技術が開示されている。詳細には、メンバの所属部署内で過去に使用されたキーワードに基づいてファイルの検索結果を並び替えることによって、必要なファイルの取得を容易にする。
【特許文献１】特開２００１−２２２５９７号公報
【特許文献２】特開２００５−９２３４０号公報
【特許文献３】特開２００４−３４８６２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、前述の従来技術によってファイル共有システムの利便性が向上しても、共有ファイルを有効に活用できない場合がある。
【０００８】
特許文献２に開示された技術では、他の部署のファイルでも所属する部署に付与したキーワードとマッチすればサーバに登録されたことが所属する部署のメンバに通知される。しかし、無駄な通知を排除し、有用なファイルの登録通知を効率的に取得するためには、キーワードを頻繁にメンテナンスしなければならない。また、有用なファイルが自部署のサーバに格納されていても、不要なファイルがサーバに多く含まれていると、検索の処理速度及び精度が低下してしまう。
【０００９】
特許文献３に開示された技術では、検索結果から有用なファイルを見つけ出すことができても、検索の処理速度及び精度そのものを改善することはできない。
【課題を解決するための手段】
【００１０】
本発明の代表的な一形態では、ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムであって、前記ファイルサーバは、前記ネットワークと接続する第１インターフェイスと、前記第１インターフェイスと接続され、プログラムを実行する第１プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第１メモリと、前記ファイルを格納する第１ストレージ装置と、を備え、前記第１メモリは、組織を構成する部署を記録した組織情報を格納し、前記第１プロセッサは、前記ファイルのアクセス履歴を記録し、前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、前記有用性が高いと判定されたファイルを検索することを特徴とする。
【発明の効果】
【００１１】
本発明の一形態によれば、有用性が高いと判定されたファイルを部署と対応付けて管理することによって、検索精度の向上及び検索速度の高速化を図ることができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態を添付図面に基づいて説明する。
【００１３】
（第１の実施の形態）
第１の実施の形態では、ファイルサーバに格納されたファイルに対するアクセス履歴を記録し、周期的にアクセス履歴を解析してファイルが高い有用性を持つ部署を判定し、ファイルのメタデータを当該部署に対応付けて管理する。
【００１４】
（システムの全体構成）
図１は、第１の実施の形態のファイル共有システム全体の構成図である。第１の実施の形態のファイル共有システムは、ファイルサーバ１、メタデータサーバ２及びクライアント３を含む。ファイルサーバ１、メタデータサーバ２及びクライアント３は、ネットワーク４によって接続される。ネットワーク４は、例えば、ＩＰネットワークによって構成される。
【００１５】
ファイルサーバ１は、メンバ間で共有するファイルを格納及び管理する計算機である。例えば、ファイルサーバ１は、ＣＩＦＳ（ＣＯＭＭＯＮ ＩＮＴＥＲＮＥＴ ＦＩＬＥ ＳＹＳＴＥＭ、ＭＩＣＲＯＳＯＦＴ社のＷＩＮＤＯＷＳ（登録商標）のファイル共有サービスで利用されるプロトコル）あるいはＳａｍｂａ（ＷＩＮＤＯＷＳ(登録商標）
マシンにファイル共有のサービスを提供するＵＮＩＸ（登録商標）系ＯＳ向けのフリーソフトウェア）などを実装することによって、クライアント３にファイル共有機能を提供する。
【００１６】
メタデータサーバ２は、ファイルサーバ１に格納されたファイルのメタデータを格納及び管理する計算機である。メタデータサーバ２は、リレーショナルデータベース（以下、「ＲＤＢ」）が実装され、メタデータを格納及び管理する。なお、メタデータとは、ファイルに関する情報を記述したデータであり、例えば、ファイルのパス、作成者及び作成日などの書誌的／システム的情報、ファイルに含まれる文字列やキーワードなどである。
【００１７】
クライアント３は、組織のメンバが使用する計算機である。クライアント３は、ファイルをファイルサーバ１に登録したり、ファイルサーバ１に格納されたファイルにアクセスする。
【００１８】
なお、図１では、ファイルサーバ１及びメタデータサーバ２は、それぞれ１台ずつの計算機が対応しているが、これに限定する必要はない。ファイルサーバ１及びメタデータサーバ２は同一の計算機に実装されてもよいし、ファイルサーバ１又はメタデータサーバ２がそれぞれ複数の計算機によって構成されてもよい。
【００１９】
（ハードウェア構成）
図２は、第１の実施の形態のファイルサーバ１のハードウェア構成図である。なお、ファイルサーバ１、メタデータサーバ２及びクライアント３のハードウェアは、すべて同一である。
【００２０】
ファイルサーバ１は、ＣＰＵ１０、ネットワークインターフェース１５、ハードディスク２０、メモリ３０、ディスプレイ４０、ディスプレイ制御部４１、キーボード５０、キーボード制御部５１、マウス６０、マウス制御部６１及びバス７０を含む。
【００２１】
ＣＰＵ１０は、メモリ３０に格納されたプログラムを実行することによって、データの入出力及び各種処理を実行する。ネットワークインターフェース１５は、ネットワークを介して他の計算機と通信する。ハードディスク２０は、プログラム及びデータを格納する。メモリ３０は、ＣＰＵ１０によって実行されるプログラム及びデータを記憶する。
【００２２】
ディスプレイ４０は、利用者にデータを表示し、ディスプレイ制御部４１によって制御される。キーボード５０は、利用者からの入力を受け付け、キーボード制御部５１によって制御される。マウス６０は、利用者からの入力を受け付け、マウス制御部６１によって制御される。バス７０は、各構成要素にデータを受け渡す。
【００２３】
（ファイルサーバ１のモジュール構成）
図３は、第１の実施の形態のファイルサーバ１のモジュール構成図である。ファイルサーバ１は、各種処理を実行する処理部、データを格納するデータ格納部及び一時的に生成されるデータを格納するテンポラリデータ部を含む。処理部は矩形、データ格納部はドラム形、テンポラリデータ部はテープ形で表す。
【００２４】
（ファイルサーバ１のモジュール構成：処理部）
ファイルサーバ１の処理部は、ファイル登録部１１Ａ、ファイル管理部１１Ｂ及びファイル検索部１１Ｃを含む。
【００２５】
ファイル登録部１１Ａは、クライアント３から送信された登録ファイル１３Ａをファイル格納部１２Ａに格納する。また、ファイル登録部１１Ａは、登録ファイル１３Ａを格納するとき、登録ファイル１３Ａを基にメタデータを生成する。そして、ファイル登録部１１Ａは、メタデータ配置コマンド１３Ｂを作成してメタデータサーバ２に送信する。
【００２６】
ファイル管理部１１Ｂは、ファイルサーバ１に格納されたファイルの有用性を判定し、メタデータを再配置する。ファイル管理部１１Ｂの構成は、図４にて詳細を後述する。
【００２７】
ファイル検索部１１Ｃは、クライアント３で入力された検索条件１３Ｃを受信して検索コマンド１３Ｄを生成し、メタデータサーバ２に送信する。そして、ファイル検索部１１Ｃは、メタデータサーバ２から検索結果１３Ｅを受信し、表示用検索結果１３Ｆを生成してクライアント３に送信する。さらに、ファイル検索部１１Ｃは、クライアント３でファイル名１３Ｇが選択されると、ファイル格納部１２Ａから該当するファイル１３Ｈを抽出し、クライアント３に送信する。
【００２８】
（ファイル管理部１１Ｂの詳細なモジュール構成）
図４は、第１の実施の形態のファイル管理部１１Ｂの詳細なモジュール構成図である。ファイル管理部１１Ｂは、処理部（矩形）、データ格納部（ドラム形）、テンポラリデータ部（テープ形）及びテーブル（平行四辺形）の４種類のモジュールを含む。なお、図４に示すアクセスログ格納部１２Ｂ、アクセス履歴格納部１２Ｃ、組織情報格納部１２Ｄ及びメタデータ配置コマンド１３Ｂは、図３に示すファイルサーバ１を構成するモジュールと同じであり、詳細は後述する。
【００２９】
（ファイル管理部１１Ｂの詳細なモジュール構成：処理部）
ファイル管理部１１Ｂの処理部は、アクセス履歴抽出部１１Ｂ１、ファイル有用性判定部１１Ｂ２及びメタデータ配置部１１Ｂ３を含む。
【００３０】
アクセス履歴抽出部１１Ｂ１は、アクセスログ格納部１２Ｂからファイルサーバ１に格納されたアクセスログを取得する。アクセスログとは、ファイルサーバ１にファイルを登録したり、ファイルサーバ１に格納されたファイルを参照した履歴である。
【００３１】
また、アクセス履歴抽出部１１Ｂ１は、アクセスログからアクセス履歴を抽出し、アクセス履歴格納部１２Ｃに格納する。アクセス履歴とは、アクセスログに記録された情報のうち、ファイルを参照した記録のみを抽出したものである。
【００３２】
ファイル有用性判定部１１Ｂ２は、アクセス履歴格納部１２Ｃに格納されたアクセス履歴を解析し、ファイルの有用性を判定する。なお、ファイルの有用性を判定する処理については、図２４にて後述する。
【００３３】
メタデータ配置部１１Ｂ３は、有用と判定されたファイルを部署と対応付ける。具体的には、このファイルのメタデータを部署と対応付けるためのメタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。なお、メタデータを再配置する処理については、図２２にて後述する。
【００３４】
（ファイル管理部１１Ｂの詳細なモジュール構成：テーブル）
図５は、第１の実施の形態のアクセス履歴テーブル１１Ｂ４の構成を示す図である。アクセス履歴テーブル１１Ｂ４は、エントリ１１Ｂ４０１及び所属１１Ｂ４０２を含む。
【００３５】
エントリ１１Ｂ４０１は、あるファイルを参照したメンバの氏名又は当該メンバが所属する部署名を格納する。所属１１Ｂ４０２は、エントリ１１Ｂ４０１に格納されたメンバ又は部署が所属する部署名を格納する。
【００３６】
図５は、第５行目にエントリとしてメンバの氏名「鈴木一郎」が格納されており、所属は「営業１課」であることを示している。
【００３７】
（ファイルサーバ１のモジュール構成：データ格納部）
ファイルサーバ１のデータ格納部は、ファイル格納部１２Ａ、アクセスログ格納部１２Ｂ、アクセス履歴格納部１２Ｃ及び組織情報格納部１２Ｄを含む。
【００３８】
ファイル格納部１２Ａは、共有ファイルを格納する。アクセスログ格納部１２Ｂは、ファイルサーバ１に対するアクセスログを格納する。例えば、ファイル共有機能を提供するＣＩＦＳプロトコル又はＳａｍｂａが出力するログを使用する。アクセス履歴格納部１２Ｃは、前述のように、アクセスログ格納部１２Ｂに格納されたアクセスログから抽出されたアクセス履歴を格納する。組織情報格納部１２Ｄは、部署及び組織のメンバを含む組織の構成情報を格納する。
【００３９】
以下、各データ格納部の構成について説明する。
【００４０】
（ファイル格納部１２Ａの構成）
図６は、第１の実施の形態のファイル格納部１２Ａの構成図である。ファイル格納部１２Ａは、ファイル名１２Ａ０１、ファイルデータ１２Ａ０２、メタデータテーブル名１２Ａ０３及びメタデータ配置日１２Ａ０４を含む。
【００４１】
ファイル名１２Ａ０１は、ファイルサーバ１に格納された共有ファイルのパスを含んだファイル名を格納する。ファイルデータ１２Ａ０２は、ファイルの文字列や書式情報などを含むファイルの内容を格納する。ファイルデータ１２Ａ０２は、ファイルそのものであってもよいし、ファイルの格納場所を示すリンクであってもよい。
【００４２】
メタデータテーブル名１２Ａ０３は、後述するメタデータ格納部２２Ａに含まれるメタデータテーブル２２Ａ００の名前を格納する。メタデータ配置日１２Ａ０４は、メタデータをメタデータテーブル２２Ａ００に配置した日付を格納する。
【００４３】
図６に示すように、第１行目にはファイル名が「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」であるファイルのデータ「○月×日に、課長同行の下、Ａ社殿にご提案し、…」が格納されている。さらに、このファイルのメタデータは、テーブル「ｅｉｇｙｏ１」に格納され、２００５年１２月３日に配置されたことが記録されている。
【００４４】
なお、図６ではファイルデータ１２Ａ０２としてテキストデータのみを示しているが、画像ファイル又は動画ファイルなどであってもよい。また、図６は、ファイル格納部１２Ａを表形式で示しているが、ファイルに属性としてこれらの情報を保持させてもよい。
【００４５】
（アクセスログ格納部１２Ｂの構成）
図７は、第１の実施の形態のアクセスログ格納部１２Ｂの構成図である。アクセスログ格納部１２Ｂは、アクセス日１２Ｂ０１、アクセス者１２Ｂ０２、ファイル名１２Ｂ０３及びアクセス種別１２Ｂ０４を含む。
【００４６】
アクセス日１２Ｂ０１は、ファイルサーバ１に格納されたファイルにアクセスした日付が格納される。図７では日付のみが表示されているが、詳細なアクセス時刻を記録してもよい。アクセス者１２Ｂ０２は、ファイルにアクセスしたメンバのユーザＩＤを格納する。ファイル名１２Ｂ０３は、アクセスされたファイルのファイル名を格納する。アクセス種別１２Ｂ０４は、ファイルの登録、参照又は削除などアクセスの種別が格納される。
【００４７】
図７に示すように、第１行目には、２００５年の１０月２４日にユーザＩＤが「ｋａｔｏｈ」であるメンバがファイル「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」を登録したことが記録されている。
【００４８】
（アクセス履歴格納部１２Ｃの構成）
図８は、第１の実施の形態のアクセス履歴格納部１２Ｃの構成図である。アクセス履歴格納部１２Ｃは、アクセス日１２Ｃ０１、アクセス者１２Ｃ０２、及びファイル名１２Ｃ０３を含む。
【００４９】
アクセス日１２Ｃ０１には、ファイルのアクセス日を格納する。なお、図８では日付のみを記録されているが、詳細なアクセス時刻を記録してもよい。アクセス者１２Ｃ０２には、ファイルにアクセスしたメンバのユーザＩＤを格納する。ファイル名１２Ｃ０３には、アクセスされたファイル名を格納する。
【００５０】
図８に示すように、第１行目には２００５年の１０月２４日にユーザＩＤが「ｙａｍａｄａ」であるメンバがファイル「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」にアクセスした履歴が記録されている。
【００５１】
（組織情報格納部１２Ｄの構成）
図９は、第１の実施の形態の組織情報格納部１２Ｄの構成図である。組織情報格納部１２Ｄは、エントリ１２Ｄ０１、ユーザＩＤ１２Ｄ０２、所属１２Ｄ０３及びメタデータテーブル名１２Ｄ０４を含む。
【００５２】
エントリ１２Ｄ０１は、組織を構成する部署名又は部署に所属するメンバ名が格納される。ユーザＩＤ１２Ｄ０２は、ファイル共有システムにおけるエントリのユーザＩＤが格納される。所属１２Ｄ０３は、エントリが所属する部署名が格納される。メタデータテーブル名１２Ｄ０４は、後述するメタデータ格納部２２Ａにおいてエントリに対応するメタデータテーブル名が格納される。
【００５３】
図９に示すように、第１行目にはエントリ「庶務課」が「総務部」に所属し、対応するメタデータテーブルの名前が「ｓｙｏｍｕ」であることが記録されている。また、第５行目にはエントリ「鈴木一郎」のユーザＩＤは「ｓｕｚｕｋｉ」であり、「営業１課」に所属していることが記録されている。
【００５４】
なお、図９ではエントリが部署の場合はユーザＩＤが付与されていないが、部署にユーザＩＤを付与して部署としての権限でファイルをファイルサーバ１に登録及びアクセスすることも可能である。また、エントリがメンバ（人）の場合には、メタデータテーブル名が対応付けられていないが、メンバを組織を構成する最小の単位として対応付けてもよい。このとき、あるメンバのみが利用するファイルのメタデータは、当該メンバに対応させて管理する。
【００５５】
さらに、組織情報格納部１２Ｄは、組織で導入／利用されているＩＴシステムのデータを流用してもよい。具体的には、セキュリティシステムにおけるＬＤＡＰ、メールシステムにおける電子電話帳、文書管理システムにおけるユーザ情報などを組織情報として用いてもよい。
【００５６】
（ファイルサーバ１のモジュール構成：テンポラリデータ部）
テンポラリデータ部は、登録ファイル１３Ａ、メタデータ配置コマンド１３Ｂ、検索条件１３Ｃ、検索コマンド１３Ｄ、検索結果１３Ｅ、表示用検索結果１３Ｆ、ファイル名１３Ｇ及びファイル１３Ｈを含む。
【００５７】
登録ファイル１３Ａは、クライアント３からファイルサーバ１に登録するファイルである。メタデータ配置コマンド１３Ｂは、メタデータサーバ２にメタデータを配置するコマンドである。検索条件１３Ｃは、クライアント３からメンバが入力したファイルの検索条件である。検索コマンド１３Ｄは、メタデータを検索するためのコマンドである。検索結果１３Ｅは、検索コマンド１３Ｄを実行した結果である。表示用検索結果１３Ｆは、検索結果１３Ｅを表示するために加工されたデータである。ファイル名１３Ｇは、メンバが選択したファイルのファイル名である。ファイル１３Ｈは、ファイル名１３Ｇに対応するファイルそのものである。
【００５８】
（登録ファイル１３Ａの一例）
図１０は、第１の実施の形態の登録ファイル１３Ａの一例を示す図である。登録ファイル１３Ａは、ファイルデータ１３Ａ０１を格納する。図１０に示すように、ファイルデータ１３Ａ０１の内容は、「営業日報 ○月×日、Ａ社殿に事務システムのご提案…」となっている。
【００５９】
（メタデータ配置コマンド１３Ｂの一例）
図１１及び図１２は、第１の実施の形態のファイルサーバ１からメタデータサーバ２に送信するメタデータ配置コマンド１３Ｂの一例を示す図である。第１の実施の形態では、前述のようにメタデータサーバ２にはＲＤＢが実装されているため、メタデータ配置コマンド１３Ｂは、ＲＤＢに対するＳＱＬコマンドとなる。
【００６０】
ＳＱＬコマンド１３Ｂ０１は、メタデータをメタデータサーバ２のＲＤＢに登録するためのコマンドの一例である。ＳＱＬコマンド１３Ｂ０１は、ファイル名が「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」及びメタデータが「Ａ社」「提案」「事務システム」となるレコードをメタデータテーブル「ｅｉｇｙｏ１」に挿入する。
【００６１】
ＳＱＬコマンド１３Ｂ０２は、メタデータサーバ２に登録済みのメタデータを再配置するＳＱＬコマンドの一例である。ＳＱＬコマンド１３Ｂ０２は、ファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」のメタデータをメタデータテーブル名「ｅｉｇｙｏ１」から「ｅｉｇｙｏ」に移動させる。
【００６２】
（検索条件１３Ｃの一例）
図１３は、第１の実施の形態のファイル検索条件１３Ｃの一例を示す図である。検索条件１３Ｃは、ユーザＩＤ１３Ｃ０１、クライアント１３Ｃ０２、部署１３Ｃ０３及びキーワード１３Ｃ０４を含む。
【００６３】
ユーザＩＤ１３Ｃ０１は、検索条件を入力した利用者のユーザＩＤを格納する。クライアント１３Ｃ０２は、検索条件を入力した利用者が使用しているクライアント３の識別名を格納する。部署１３Ｃ０３は、利用者が検索条件として指定した部署を格納する。キーワード１３Ｃ０４は、利用者が検索条件として入力したキーワードを格納する。
【００６４】
図１３は、ユーザＩＤが「ｓａｔｏｈ」であるメンバがクライアント「ｓａｔｏｈ−ｐｃ」において、「営業１課」にて有用性が高いと判定されたファイルのうち「Ａ社、提案」をキーワードとして含むファイルを検索する条件を示している。
【００６５】
（検索コマンド１３Ｄの一例）
図１４は、第１の実施の形態のファイル検索部１２Ｃがメタデータサーバ２に送信する検索コマンド１３Ｄの一例を示す図である。前述のようにメタデータはＲＤＢに格納されているため、検索コマンド１３ＤはＳＱＬコマンド１３Ｄ０１である。
【００６６】
ＳＱＬコマンド１３Ｄ０１は、メタデータテーブル「ｅｉｇｙｏ１」からメタデータに「Ａ社」及び「提案」を含むレコードのファイル名を取得する。
【００６７】
（検索結果１３Ｅの一例）
図１５は、第１の実施の形態のファイル検索部１２Ｃがメタデータサーバ２から受信する検索結果１３Ｅの一例を示す図である。
【００６８】
検索結果１３Ｅは、検索コマンド１３Ｄの実行結果１３Ｅ０１である。図１５に示すように、第１行目には、図１４に示す検索コマンド１３Ｄの実行結果１３Ｅ０１としてファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」が格納されている。
【００６９】
（表示用検索結果１３Ｆの一例）
図１６は、第１の実施の形態のファイル検索部１２Ｃがクライアント３に送信する表示用検索結果１３Ｆの一例を示す図である。
【００７０】
表示用検索結果１３Ｆには、検索結果１３Ｅから取得されたファイル名と、ファイルの内容の一部又は全部とが含まれている。図１６に示すように、表示用検索結果１３Ｆの第１行目には表示内容１３Ｆ０１として、ファイル名「ｆｉｌｅ１．ｄｏｃ」が、第２行目にはファイルの内容「○月×日，課長同行の下，Ａ社殿に…」が格納されている。
【００７１】
（ファイル名１３Ｇの一例）
図１７は、第１の実施の形態の利用者によって選択されたファイル名１３Ｇの一例を示す図である。図１７に示すように、利用者が選択したファイル名１３Ｇ０１として「ｆｉｌｅ１．ｄｏｃ」が格納されている。
【００７２】
（ファイル１３Ｈの一例）
図１８は、第１の実施の形態のメンバが指定したファイル名を有するファイル１３Ｈの一例を示す図である。ファイル１３Ｈは、ファイルデータ１３Ｈ０１を格納する。図１８に示すように、ファイルデータ１３Ｈ０１には「○月×日，課長同行の下，Ａ社殿にご提案…」が格納されている。
【００７３】
（メタデータサーバ２のモジュール構成）
図１９は、第１の実施の形態のメタデータサーバ２のモジュール構成図である。メタデータサーバ２は、図３に示したファイルサーバ１と同様に、処理部、データ格納部及びテンポラリデータ部を含む。
【００７４】
（メタデータサーバ２のモジュール構成：処理部）
メタデータサーバ２の処理部は、メタデータ登録部２１Ａ、メタデータ管理部２１Ｂ及びメタデータ検索部２１Ｃを含む。
【００７５】
メタデータ登録部２１Ａは、ファイルサーバ１から送信されたメタデータ配置コマンド１３Ｂを受信し、メタデータ格納部２２Ａにメタデータを格納する。メタデータ管理部２１Ｂは、ファイルサーバ１からメタデータ配置コマンド１３Ｂを受信し、メタデータ格納部２２Ａに格納されているメタデータを再配置する。メタデータ検索部２１Ｃは、ファイルサーバ１から検索コマンド１３Ｄを受信し、メタデータ格納部２２に対して検索コマンド１３Ｄを実行し、検索結果１３Ｅをファイルサーバ１に送信する。
【００７６】
（メタデータサーバ２のモジュール構成：データ格納部）
図２０は、第１の実施の形態のメタデータ格納部２２Ａの構成図である。前述のようにメタデータサーバ２にはＲＤＢが実装されており、メタデータ格納部２２Ａは、組織の各部署に対応するテーブル２２Ａ００を格納する。
【００７７】
テーブル２２Ａ００は、ファイル名２２Ａ０１及びメタデータ２２Ａ０２を含む。ファイル名２２Ａ０１は、ファイルサーバ１に格納されているファイルのファイル名を格納する。メタデータ２２Ａ０２は、当該ファイルのメタデータを格納する。
【００７８】
図２０に示すように、第１行目のレコードにファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」と、対応するメタデータ「営業日報、Ａ社、提案…」が格納されている。
【００７９】
なお、メタデータ２２Ａ０２には、一例として、ファイルから抽出したキーワードを示しているが、ファイルの作成者名又は作成日のようにファイル属性として取得可能な書誌的データ又はアノテーションなどを含んでもよい。
【００８０】
（メタデータサーバ２のモジュール構成：テンポラリデータ格納部）
メタデータサーバ２のテンポラリデータ格納部は、メタデータ配置コマンド１３Ｂ、検索コマンド１３Ｄ及び検索結果１３Ｅを含む。メタデータ配置コマンド１３Ｂ、検索コマンド１３Ｄ及び検索結果１３Ｅは、ファイルサーバ１のテンポラリデータ格納部と共通であるため、説明を省略する。
【００８１】
以上、第１の実施の形態のファイル共有システムの構成について説明した。
【００８２】
（ファイル共有システムの処理手順）
続いて、第１の実施の形態のファイル共有システムで実行される処理について説明する。第１の実施の形態では、部署によってファイルの有用性が異なる点に着目し、ファイルのアクセス履歴に基づき、利用者の多い部署において有用性が高いと判定する。そこで、ファイルが有用と判定された部署に対応させてファイルのメタデータを配置する。さらに、時間の経過とともにファイルの有用性が変化しうる点を考慮し、周期的にファイルの有用性を判定し、メタデータを再配置する。
【００８３】
図２１は、第１の実施の形態のファイル共有システム内に常駐して実行される処理を示すフローチャートである。なお、説明文の末尾の括弧内の数字は、各フローチャートにおける処理番号である。
【００８４】
ファイルサーバ１は、現在時刻が予め定められたメタデータ再配置処理の実行時刻と一致するか否かを判定する（Ｓ１０１）。ファイルサーバ１は、メタデータ再配置処理の実行時刻になると（Ｓ１０１の結果が「Ｙ」）、メタデータ再配置処理を実行する（Ｓ１０２）。メタデータ再配置処理の詳細は、図２４にて後述する。
【００８５】
ファイルサーバ１は、現在時刻がメタデータを再配置する時刻でない場合には（Ｓ１０１の結果が「Ｎ」）、クライアント３からの入力の有無を判定する（Ｓ１０３）。
【００８６】
ファイルサーバ１は、クライアント３から指示が入力された場合には（Ｓ１０３の結果が「Ｙ」）、入力指示が登録指示であるか否かを判定する（Ｓ１０４）。一方、クライアント３からの入力がなかった場合には、Ｓ１０１の処理に戻る。
【００８７】
ファイルサーバ１は、クライアント３からの入力が登録指示であった場合には（Ｓ１０４の結果が「Ｙ」）、ファイルの登録処理を実行する（Ｓ１０５）。ファイルの登録処理は、ファイル登録部１１Ａによって実行される。
【００８８】
ファイル登録部１１Ａは、クライアント３から送信された登録ファイル１３Ａを受信し、ファイル格納部１２Ａに格納する。
【００８９】
また、ファイル登録部１１Ａは、登録ファイル１３Ａを格納するとともに、登録ファイル１３Ａからキーワードを抽出する。キーワードの抽出は、非特許文献１（下畑光夫等、“文字種切り出しと複合語分解によるキーワード抽出”、情報処理学会、自然言語処理研究会報告、１２０−１３、１９９７）又は非特許文献２（原正巳等“テキストのフォーマットと単語の範囲内重要度を利用したキーワード抽出”、情報処理学会、論文誌、ＶＯＬ．３８、ＮＯ．２、１９９７）に記載の従来技術を適用することによって実現できる。また、ファイルを登録する者がキーワードを手入力する構成としてもよい。
【００９０】
また、ファイル登録部１１Ａは、組織情報格納部１２Ｄを参照し、登録ファイル１３Ａを送信したメンバの所属を取得し、さらに取得した所属からメタデータテーブル名１２Ｄ０４を取得する。そして、ファイル登録部１１Ａは、抽出したキーワードをメタデータとしてメタデータテーブルに挿入する。具体的には、メタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。
【００９１】
メタデータサーバ２のメタデータ登録部２１Ａは、メタデータ配置コマンド１３Ｂを受信すると、メタデータ格納部２２Ａに対してコマンドを実行し、メタデータを格納する。
【００９２】
その後、ファイル登録部１１Ａは、メタデータを格納したメタデータテーブル名をファイル格納部１２Ａのメタデータテーブル名１２Ａ０３に記録する。さらに、ファイル登録部１１Ａは、登録日をファイル格納部１２Ａのメタデータ配置日１２Ａ０４に記録して、Ｓ１０１の処理に戻る（Ｓ１０５）。
【００９３】
ファイルサーバ１は、クライアント３からの入力が検索指示であるかを判定する（Ｓ１０６）。検索指示でない場合には、Ｓ１０１の処理に戻る（Ｓ１０６の結果が「Ｎ」）。
【００９４】
ファイルサーバ１は、クライアント３からの入力が検索指示であった場合には（Ｓ１０６の結果が「Ｙ」）、ファイル検索を実行する（Ｓ１０７）。ファイル検索は、ファイル検索部１１Ｃによって実行される。
【００９５】
ファイル検索部１１Ｃは、クライアントから送信された検索条件１３Ｃを受信する。ファイル検索部１１Ｃは、検索コマンド１３Ｄを生成し、メタデータサーバ２に送信する。メタデータサーバ２のメタデータ検索部２１Ｃは、検索コマンド１３Ｄを受信すると、検索コマンド１３Ｄをメタデータ格納部２２Ａに対して実行する。メタデータ検索部２１Ｃは、検索結果１３Ｅをファイルサーバ１のファイル検索部１１Ｃに送信する。
【００９６】
ファイル検索部１１Ｃは、検索結果１３Ｅを基に表示用検索結果１３Ｆを作成する。表示用検索結果１３Ｆには、ファイル名及びファイルの内容の一部又は全部が含まれる。ファイル検索部１１Ｃは、作成した表示用検索結果１３Ｆをクライアント３に送信する。
【００９７】
クライアント３は、受信した表示用検索結果１３Ｆを画面に表示する。メンバが表示されたファイル名を選択すると、クライアント３は、選択されたファイル名１３Ｇをファイルサーバ１に送信する。ファイルサーバ１は、ファイル名１３Ｇを受信し、該当するファイル１３Ｈをファイル格納部１１Ａから取得し、クライアント３に送信する。クライアント３は、ファイルサーバ１から送信されたファイル１３Ｈを画面に表示する（Ｓ１０７）。
【００９８】
（メタデータ再配置処理の詳細な処理手順）
図２２は、第１の実施の形態のメタデータ再配置処理の処理手順を示すフローチャートである。
【００９９】
ファイル管理部１１Ｂは、まずアクセス履歴格納部１２Ｃをクリアしてアクセスログ格納部１２Ｂからアクセス種別１２Ｂ０４が「参照」であるアクセスログを抽出してアクセス履歴格納部１２Ｃに格納する（Ｓ２０１）。さらに、ファイル管理部１１Ｂは、ファイル名１２Ｃ０３をキーとしてアクセス履歴格納部１２Ｃのレコードをソートする（Ｓ２０２）。したがって、アクセス履歴格納部１２Ｃには、同一ファイルに対するアクセスを記録したレコードが連続して格納される。そして、アクセス履歴格納部１２Ｃを先頭レコードから順次処理し、ファイルごとの有用性を判定する。
【０１００】
ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃの処理対象となるレコードのインデックスを示す大域変数ｉに１をセットする（Ｓ２０３）。
【０１０１】
ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のレコードに格納されているファイル名を大域変数ＦＮにセットする（Ｓ２０４）。変数ＦＮには、有用性を判定するファイルのファイル名が格納される。ファイル管理部１１Ｂは、ファイル格納部１２Ａを参照し、ＦＮに対応するメタデータテーブル名を取得し、大域変数ＴＮ１にセットする（Ｓ２０５）。
【０１０２】
ファイル管理部１１Ｂは、大域変数ＴＮ２を初期化する（Ｓ２０６）。ＴＮ２は、Ｓ２０７の処理にてファイルの有用性を判定し、有用と判定された部署に対応するメタデータテーブルのテーブル名を格納する変数である。
【０１０３】
続いて、ファイル管理部１１Ｂは、インデックスｉの値を増やしながらアクセス履歴格納部１２Ｃからアクセス履歴を読み込み、ＦＮの有用性を判定する（Ｓ２０７）。ファイル有用性判定処理では、ＴＮ２に現時点で有用と判定された部署に対応するメタデータテーブルのテーブル名を格納する。
【０１０４】
ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが異なっているか否かを判定する（Ｓ２０８）。ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが異なっている場合には（Ｓ２０８の結果が「Ｙ」）、ＦＮを有用と判定した部署が変化したため、メタデータを再配置する（Ｓ２０９）。メタデータの再配置は、ファイル名がＦＮに対応するメタデータをテーブルＴＮ１からＴＮ２に移動する。具体的には、ファイル管理部１１Ｂは、メタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する（Ｓ２０９）。
【０１０５】
一方、ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが等しい場合（Ｓ２０８の結果が「Ｎ」）、又はメタデータの再配置を完了した場合には、ファイル格納部１２ＡのＦＮに対応するレコードを更新する（Ｓ２１０）。具体的には、メタデータテーブル名１２Ａ０３及びメタデータ配置日１２Ａ０４を更新する。メタデータを再配置しない場合であっても、メタデータ配置日１２Ａ０４を更新することによって、メタデータ配置日時点でファイルが有用であることを判断することができる。
【０１０６】
ファイル管理部１１Ｂは、インデックスｉの値とアクセス履歴格納部１２Ｃのレコード件数とを比較する（Ｓ２１１）。インデックスｉがアクセス履歴格納部１２Ｃに格納されたアクセス履歴数以下の場合には（Ｓ２１１の結果が「Ｎ」）、すべてのファイルについて有用性が判定されていないため、Ｓ２０４の処理に移行し、残りのファイルの有用性を判定する。インデックスｉがアクセス履歴数よりも大きい場合には（Ｓ２１１の結果が「Ｙ」）、アクセスされたすべてのファイルの有用性の判定が終了したため、メタデータ再配置処理Ｓ１０２を終了する。
【０１０７】
（組織におけるファイルの有用性）
ここで、ファイルの有用性判定処理について説明する前に、組織におけるファイルの有用性について説明する。
【０１０８】
ファイルの有用性は、前述のように、ファイルに対するアクセスの頻度によって判定する。具体的には、アクセス頻度が高ければファイルの有用性が高いと判定し、反対に頻度が低ければ有用性が低いと判定する。
【０１０９】
さらに、ファイルが「誰にとって」有用であるかを考慮し、あるファイルが有用である可能性が高いメンバがこのファイルにアクセスしやすいように管理する。具体的には、あるファイルにアクセスしたメンバを多く含む部署にとってファイルが有用であると判定し、ファイルと部署とを対応付けて管理する。
【０１１０】
また、ファイルの有用性は時間の経過とともに変化する。アクセス頻度が高く有用であったファイルであってもアクセス頻度が低くなれば有用性も低下する。また、ファイルを作成した段階ではアクセス頻度が低かったファイルであっても時間の経過とともにアクセス頻度が高くなれば有用性は高くなる。そこで、有用である部署が変化したか否かを周期的にチェックし、変化していれば新たに有用であると判定された部署とファイルとを対応付ける。
【０１１１】
図２３は、ファイルのアクセス頻度とファイルが有用である部署との関係を説明する図である。一例として、組織は、「Ｘ部」、「Ｙ部」及び「Ｚ部」によって構成され、「Ｘ部」はさらに「Ｘ１課」、「Ｘ２課」及び「Ｘ３課」によって構成される。
【０１１２】
図２３の（Ａ）は、ファイルサーバに登録されているファイルが「Ｘ１課」のメンバからアクセスされている状態を表す。この状態では、当該ファイルは「Ｘ１課」において有用であると考えられる。
【０１１３】
ここで、（Ａ）の状態から（Ｂ）の状態に変化し、「Ｘ３課」からも当該ファイルにアクセスされるようになったとする。このとき、（Ｃ）に示すように、「Ｘ１課」に加えて「Ｘ３課」でも当該ファイルが有用になったと考えられる。
【０１１４】
しかし、（Ｃ）では、「Ｘ３課」のみで有用であるファイルと、「Ｘ１課」と「Ｘ３課」とで共通して有用なファイルが同様に扱われてしまう。その結果、「Ｘ３課」のみで有用なファイル、例えば、「Ｘ３課」の業務にのみ関連したファイルを検索する場合であっても、「Ｘ１課」と「Ｘ３課」で共通の有用なファイルがともに抽出され、検索精度が悪化するなどの問題が生じてしまう。
【０１１５】
そこで、第１の実施の形態では、あるファイルについて（Ａ）から（Ｂ）に示す状態に変化した場合には、ファイルが有用である組織のレベルが変化したものとする。具体的には、（Ｄ）に示すように「Ｘ１課」と「Ｘ３課」の共通の上位部署である「Ｘ部」が当該ファイルが有用である部署と判定する。こうすることによって、「Ｘ３課」のみで有用なファイルと明確に区別することができる。そして、ファイルが有用である部署を指定することによって、業務に直結したファイル又は組織内で一段上位のレベルで有用なファイルなど、利用者が必要とするファイルを容易に取得することができる。
【０１１６】
また、（Ａ）の状態から（Ｂ）の状態にアクセス頻度が変化したということは、今後「Ｘ部」に属する部署で「Ｘ１課」及び「Ｘ３課」以外の部署、すなわち「Ｘ２課」からもアクセス頻度が増加する可能性がある。そこで、（Ｄ）に示すように上位部署である「Ｘ部」で有用であると判定すれば、「Ｘ２課」からも容易に当該ファイルにアクセスできるようになる。
【０１１７】
（ファイル有用性判定処理の処理手順）
図２４は、図２２に示すメタデータ再配置処理Ｓ１０２のファイル有用性判定処理Ｓ２０７の処理手順を示すフローチャートである。ファイル有用性判定処理Ｓ２０７は、ファイル管理部１１Ｂによって実行される。
【０１１８】
ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４のインデックスを示す変数ｊに１をセットして初期化する（Ｓ３０１）。
【０１１９】
続いて、ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のアクセス者１２Ｃ０２を抽出し、組織情報格納部１２Ｄを参照してユーザＩＤ１２Ｄ０２と一致するエントリ１２Ｄ０１を取得する。そして、取得したエントリ１２Ｄ０１をアクセス履歴テーブル１１Ｂ４のｊ番目のレコードのエントリ１１Ｂ４０１に格納する（Ｓ３０２）。同様に、アクセス履歴格納部ｉ番目のアクセス者の所属を取得し、アクセス履歴テーブル１１Ｂ４のｊ番目のレコードの所属１１Ｂ４０２にセットする（Ｓ３０３）。
【０１２０】
次に、ファイル管理部１１Ｂは、ｉとｊをそれぞれ１ずつ加算する（Ｓ３０４）。さらに、アクセス履歴格納部１２Ｃのｉ番目のファイル名がＦＮと一致するか否かを判定する（Ｓ３０５）。一致する場合には（Ｓ３０５の結果が「Ｙ」）、該当するレコードがＦＮに対するアクセス履歴であるため、ファイル管理部１１Ｂは、Ｓ３０２の処理を実行し、アクセス履歴テーブル１１Ｂ４にレコードを追加する。
【０１２１】
また、ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のファイル名がＦＮと一致しない場合には（Ｓ３０５の結果が「Ｎ」）、アクセス履歴テーブル１１Ｂ４に対するレコードの追加が完了したため、Ｓ３０６以降の処理を実行する。アクセス履歴格納部１２Ｃは、前述のように、ファイル名でソートされており、アクセス履歴はファイルごとに連続して格納される。したがって、アクセス履歴１２Ｃのｉ番目のファイル名がＦＮと一致しなくなった時点で、ＦＮのアクセス履歴に対応するレコードがアクセス履歴テーブル１１Ｂ４に生成されている。なお、この時点で、インデックスｊには、ＦＮのアクセス数＋１の値が格納されている。
【０１２２】
そして、ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４を集計する（Ｓ３０６）。アクセス履歴テーブル１１Ｂ４の集計とは、ＦＮに対する総アクセス数に占める各所属のアクセス数の割合を算出することである。
【０１２３】
ファイル管理部１１Ｂは、アクセス数が最も多い所属の割合が所定の値α（例えば８０％）を超えるか否かを判定する（Ｓ３０７）。アクセス数が最も多い所属の割合がαを超える場合には（Ｓ３０７の結果が「Ｙ」）、当該所属にとってＦＮの有用性が高いと判定されたため、組織情報格納部１２Ｄを参照し、この所属に対応するメタデータテーブル名１２Ｄ０４を取得し、ＴＮ２に格納する（Ｓ３０８）。
【０１２４】
一方、ファイル管理部１１Ｂは、アクセス数が最も多い所属の割合がαを超えない場合には（Ｓ３０７の結果が「Ｎ」）、ＦＮの有用性が高いと判定された部署が存在しなかったため、アクセス履歴テーブル１１Ｂ４に格納された所属の上位の所属で再度集計する。以下、上位の所属で再集計する処理について説明する。
【０１２５】
ファイル管理部１１Ｂは、まず、アクセス履歴テーブル１１Ｂ４のインデックスを示す変数ｋに１をセットして初期化する（Ｓ３０９）。
【０１２６】
次に、ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４のｋ番目の所属１１Ｂ４０２をエントリ１１Ｂ４０１に複写する（Ｓ３１０）。ここで、ファイル管理部１１Ｂは、組織情報格納部１２Ｄを参照し、複写されたエントリに上位の所属が存在するか否かを判定する（Ｓ３１１）。上位の所属が存在する場合には（Ｓ３１１の結果が「Ｙ」）、アクセス履歴テーブル１１Ｂ４のｋ番目の所属１１Ｂ４０２に上位の所属をセットする（Ｓ３１２）。
【０１２７】
その後、ファイル管理部１１Ｂは、ｋの値に１を加算し（Ｓ３１３）、ｋの値がｊの値以上であるか否かを判定する（Ｓ３１４）。Ｓ３１４の処理では、変数ｊにファイルＦＮのアクセス数＋１の値が格納されているため、アクセス履歴テーブル１１Ｂ４に格納された所属を上位の所属にすべて更新したか否かを判定することができる。
【０１２８】
ファイル管理部１１Ｂは、ｋの値がｊの値よりも小さい場合には（Ｓ３１４の結果が「Ｎ」）、アクセス履歴テーブル１１Ｂ４の残りのレコードについてＳ３１０からＳ３１３までの処理を実行する。ｋの値がｊの値以上の場合には（Ｓ３１４の結果が「Ｙ」）、アクセス履歴テーブル１１Ｂ４のすべてのレコードの更新が完了したため、更新した所属で再度集計し（Ｓ３０６）、ファイルの有用性を判定する（Ｓ３０７）。
【０１２９】
なお、Ｓ３０８の処理にて、アクセス数の最も多い所属のメタデータテーブル名１２Ｄ０４をＴＮ２に格納しているが、ＴＮ２にセットするテーブル名は１つに限定する必要はない。ファイルをアクセスする利用者の利便性を考慮し、複数のテーブルにメタデータを配置することも可能である。以下、その一例について図２３を用いて説明する。
【０１３０】
あるファイルが主にＸ１課のメンバによってアクセスされていた状態（（Ａ）の状態）から、Ｘ３課のメンバによってもアクセスされる状態（（Ｂ）の状態）となったとする。このとき、通常の処理では、このファイルのメタデータは、Ｘ１課に対応するメタデータテーブルからＸ部に対応するメタデータテーブルに移動する（（Ｄ）の状態）。
【０１３１】
一方、メタデータを再配置する際に依然としてＸ１課からのアクセスも多い場合には、Ｘ１課に対応するテーブルに格納されているメタデータをそのまま残し、同時にＸ部に対応するメタデータテーブルにも同じメタデータを格納してもよい。具体的には、Ｓ３０８の処理において、アクセス数の最も多い所属に対応するメタデータテーブル名１２Ｄ０４及びＴＮ１をＴＮ２に格納すればよい。
【０１３２】
以上、フローチャートを用いて本発明の第１の実施の形態のファイル共有システムの処理手順について説明した。
【０１３３】
（ファイル検索におけるクライアント画面の一例）
ここで、ファイル検索処理Ｓ１０７を実行するための検索指示画面と、検索結果表示画面について説明する。検索指示画面及び検索結果表示画面は、クライアント３にて表示される。
【０１３４】
（ファイル検索におけるクライアント画面の一例：検索指示画面）
図２５は、第１の実施の形態のクライアント３に表示される検索指示画面の一例を示す図である。検索指示画面は、検索キー入力エリア４０１、検索範囲指定エリア４０２、検索指示ボタン４０３、終了指示ボタン４０４及び検索結果表示エリア４０５を含む。
【０１３５】
検索キー入力エリア４０１は、ファイルを検索するためのキーワードを入力する領域である。図２５には、検索キー入力エリア４０１に利用者がキーワードとして「Ａ社」及び「提案」と入力されている。
【０１３６】
検索範囲指定エリア４０２は、ファイルを検索する部署の範囲を指定する項目である。図２５には、検索対象の部署として「営業１課」及び「営業部」が指定されている。
【０１３７】
検索指示ボタン４０３は、利用者がファイル共有システムにファイルの検索の実行を指示する。終了指示ボタン４０４は、システムにファイル検索の終了を指示する。検索結果表示エリア４０５は、ファイルの検索結果を表示するエリアである。
【０１３８】
（ファイル検索におけるクライアント画面の一例：検索結果表示画面）
図２６は、図２５に示した検索条件にしたがって実行された検索結果を表示する画面の一例を示している。なお、画面の構成は、図２５と同じである。
【０１３９】
図２５で入力された検索条件は、検索指示ボタン４０３が押下されると、検索条件１３Ｃとしてネットワーク４を通じてファイルサーバ１のファイル検索部１１Ｃに送信される。ファイル検索部１１Ｃは、検索条件１３Ｃを受信すると、前述のようにファイル検索処理Ｓ１０７を実行し、表示用検索結果１３Ｆをクライアント３に送信する。クライアント３は、表示用検索結果１３Ｆを受信すると、図２６に示すように、抽出されたファイルのファイル名とその内容の一部を検索結果表示エリア４０５に表示する。
【０１４０】
（ファイル検索におけるクライアント画面の一例：部署指定一覧表示画面）
また、キーワードを指定せずに部署のみを指定してファイルを検索してもよい。部署のみを指定してファイルを検索することによって、部署ごとに有用性が高いと判定されたファイルの一覧を取得することができる。
【０１４１】
図２７は、部署指定一覧表示画面の一例である。部署指定一覧表示画面は、部署指定欄４０２、一覧表示ボタン４０６、終了指示ボタン４０４及び一覧表示部４０８を含む。なお、図２５と同じ符号が割り当てられている要素については、同じ機能を備えるものとし、説明を省略する。また、キーワードを入力せずに検索可能とすれば、図２５に示した検索指示画面を使用してもよい。
【０１４２】
一覧表示ボタン４０６は、指定された部署をファイルサーバ１に送信する。ファイルサーバ１は、検索条件１３Ｃとして部署を受信すると、検索コマンド１３Ｄを生成して検索処理を実行し、表示用検索結果１３Ｆをクライアント３に送信する。このとき、表示用検索結果１３Ｆは、部署ごとの一覧としてクライアント３に送信される。
【０１４３】
クライアント３は、表示用検索結果１３Ｆを受信すると、一覧表示部４０８に部署ごとに有用性が高いと判定されたファイルの一覧を表示する。図２７では、一覧表示部４０８は、ファイルの一覧を部署ごとに切替えて表示できるように構成されている。
【０１４４】
（第１の実施の形態の効果）
第１の実施の形態によれば、有用性が高いファイルと判定されたを部署と対応付けて管理することによって、検索精度の向上及び検索速度の高速化を図ることができる。
【０１４５】
第１の実施の形態では、ファイルのメタデータを利用し、有用性が高いと判定されたファイルのメタデータを部署と対応付けて管理する。したがって、ファイルそのものではなく、メタデータを検索対象とするため、検索速度を高速化することができる。
【０１４６】
さらに、第１の実施の形態によれば、ファイルの有用性に応じてメタデータを再配置する処理が周期的に実行されるため、管理者及び利用者がメタデータを再配置する必要が無く、メンテナンス性を向上させることができる。
【０１４７】
（第１の実施の形態の変形例）
第１の実施の形態では、ファイル共有機能の実装をＣＩＦＳプロトコル又はＳａｍｂａを利用する構成としたが、文書管理システムのファイル共有機能を利用してもよい。すなわち、文書管理システムにおける文書管理サーバをファイルサーバ１とし、さらに、文書格納部をファイル格納部１２Ａ、システムログをアクセスログ格納部１２Ｂ、ユーザ情報を組織情報１２Ｄ、文書登録部をファイル登録部１１Ａとすることによって、第１の実施の形態を実装できる。
【０１４８】
また、ＷＥＢサーバをファイルサーバ１とみなし、ＷＥＢシステムにおけるＷＥＢページ格納エリアをファイル格納部１２Ａ、ＷＥＢページに対するアクセスログをアクセスログ格納部１２Ｂとみなして本発明を実装することも可能である。
【０１４９】
（第２の実施の形態）
第２の実施の形態では、有用性が低いファイルのメタデータを各部署に対応させずに不要ファイルとして管理する。なお、第１の実施の形態と同様の機能を果たす構成には同一の符号を付して重複する説明を適宜省略する。
【０１５０】
第２の実施の形態のファイル共有システムの構成は、第１の実施の形態の構成と同じであり、それぞれ図１〜図２０に示した通りである。ただし、図２０のメタデータ格納部２２Ａには、各部署に対応するテーブルに加え、不要と判定されたファイルのメタデータを格納するテーブルを追加する。なお、不要と判定されたファイルのメタデータを格納するテーブルの構成は、各部署に対応するメタデータを格納するテーブルの構成と同じである。
【０１５１】
第２の実施の形態におけるファイル共有システムの処理手順は、Ｓ１０２のメタデータを再配置する処理を除いて、第１の実施の形態と同じである。したがって、システムに常駐して実行される処理は、図２１のフローチャートに示した手順と同じである。
【０１５２】
（第２の実施の形態のメタデータ再配置処理Ｓ１０２の詳細な処理手順）
図２８は、第２の実施の形態のメタデータ再配置処理Ｓ１０２の処理手順を示すフローチャートである。
【０１５３】
図２８に示すフローチャートのＳ２０１からＳ２１１までの処理は、図２２に示した第１の実施の形態のＳ２０１からＳ２１１の処理と同じである。すなわち、ファイル管理部１１Ｂは、まずアクセス履歴格納部１２Ｃをクリアしてアクセスログ格納部１２Ｂからアクセス履歴を抽出してアクセス履歴格納部１２Ｃに格納し（Ｓ２０１）、ファイル名でソートする（Ｓ２０２）。そして、アクセス履歴格納部１２Ｃの先頭レコードから順にファイルの有用性を判定し、メタデータを再配置する（Ｓ２０４〜Ｓ２１１）。なお、ファイルの有用性を判定する手順は、図２４のフローチャートに示した手順と同じである。
【０１５４】
ファイル管理部１１Ｂは、メタデータの再配置処理が完了すると、不要ファイルのメタデータを再配置する（Ｓ２１２）。なお、第２の実施の形態では、一定期間（例えば６ヶ月間）、利用者にアクセスされていないファイルを不要ファイルと判定する。そして、ファイル管理部１１Ｂは、該当するファイルのメタデータを不要ファイルのメタデータを格納するメタデータテーブルに移動させる。
【０１５５】
具体的には、まず、ファイル管理部１１Ｂは、ファイル格納部１２Ａを参照し、メタデータ配置日１２Ａ０４がγ（例えば６ヶ月前の日付）以前のレコードを抽出する。次に、ファイル管理部１１Ｂは、抽出されたレコードからファイル名とメタデータテーブル名を取得する。さらに、ファイル管理部１１Ｂは、取得したメタデータテーブル名から取得したファイル名をもとにメタデータを抽出する。そして、抽出したメタデータを不要ファイルのメタデータを格納するメタデータテーブルに移動させるメタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。
【０１５６】
（第２の実施の形態の効果）
第２の実施の形態によれば、一定期間、アクセスされていないファイルは有用性が低下したものとし、メタデータを不要データを格納するメタデータテーブルに移動させる。こうすることで、検索対象となるメタデータを有用性の高いファイルのメタデータに限定することができ、ファイルの検索精度の向上及び検索速度の高速化を図ることができる。
【０１５７】
また、第２の実施の形態の変形例として、不要と判定されたファイルのメタデータを移動させるのではなく、ファイルの登録者に削除を依頼するように通知してもよい。
【０１５８】
（第３の実施の形態）
他部署のファイルサーバに格納された有用なファイルは、メール又はインスタントメッセージなどの情報伝達ツールを利用して、間接的に取得される場合がある。例えば、他部署のファイルサーバに有用なファイルが格納されている場合、このファイルを利用しようとする者は他部署のメンバにファイルの送付を依頼することが考えられる。そこで、依頼を受けた他部署のメンバは、メールシステムの添付ファイル機能又はインスタントメッセージシステムのファイル転送機能を用いて依頼者にファイルを送付する。
【０１５９】
このような場合には、ファイルサーバにアクセスした者は、依頼を受けた他部署のメンバではなく、依頼者と考えるべきである。
【０１６０】
そこで、第３の実施の形態のファイル共有システムでは、メールシステムにおける添付ファイルの送信ログからもアクセス履歴を抽出する。
【０１６１】
（第３の実施の形態におけるシステム構成）
図２９は、第３の実施の形態のファイル共有システムの構成を示す図である。第３の実施の形態のファイル共有システムは、ファイルサーバ１、メタデータサーバ２、クライアント３、ネットワーク４及びメールサーバ５を含む。ファイルサーバ１、メタデータサーバ２、クライアント３及びネットワーク４は、第１の実施の形態と同じ構成である。
【０１６２】
メールサーバ５は、送信されたメールを受信し、メールのヘッダに記載されたあて先を参照してメールを送信する。また、クライアント３からメールを参照する指示があれば、クライアント３の利用者宛に送信されたメールをクライアント３に送信する。
【０１６３】
第３の実施の形態のメールサーバ５のハードウェア構成は、図２に示した構成と同一である。
【０１６４】
（第３の実施の形態におけるモジュール構成）
続いて、第３の実施の形態のファイル共有システムのモジュール構成を説明する。
【０１６５】
図３０は、第３の実施の形態のファイル共有システムのファイルサーバ１のモジュール構成図である。処理部（矩形）、データ格納部（ドラム形）及びテンポラリデータ部（テープ形）は、図３に示す第１の実施の形態のモジュール構成と同じである。ただし、第３の実施の形態では、ファイル管理部１１Ｂがクライアント３のメールログ格納部３２Ａを参照する点が相違する。他のモジュールについては、図５から図１８に示す構成と同じであり、説明を省略する。
【０１６６】
メタデータサーバ２のモジュール構成は、図１９に示す構成と同一であり、詳細な説明は省略する。また、メールサーバ５は、ＳＥＮＤＭＡＩＬ（登録商標）などの既存のソフトウェアを実装することによって構築可能であり、詳細な説明は省略する。
【０１６７】
クライアント３は、第１の実施の形態の構成に加え、メールシステムのクライアント機能を有する。
【０１６８】
図３１は、クライアント３のメールクライアント機能に関連するモジュール構成を示す図である。クライアント３のメールクライアント機能のモジュールは、メールクライアント部３１Ａ、メールログ格納部３２Ａ、メール３３Ａ及びファイル３３Ｂを含む。
【０１６９】
メールクライアント部３１Ａは、メールを送受信する。メールログ格納部３２Ａは、メールクライアント部３１Ａが実行した処理のログを格納する。メール３３Ａは、利用者が送受信したメールのデータである。ファイル３３Ｂは、利用者がメールを作成するときに添付したファイルのデータである。
【０１７０】
（第３の実施の形態におけるファイル共有システムの処理手順）
次に、第３の実施の形態のファイル共有システムの処理手順を説明する。第３の実施の形態の処理手順は、第１の実施の形態の処理手順と概ね同じである。ただし、メタデータ配置処理Ｓ１０２において、ファイルのアクセス履歴を抽出する処理Ｓ２０１が相違する。
【０１７１】
第３の実施の形態では、アクセスログ格納部１２Ｂからファイルに対するアクセス履歴を抽出するとともに、クライアント３のメールログ格納部３２Ａからメールログを取得する。メールログの内容からファイルサーバ１のファイル格納部１２Ａに格納されたファイルを添付ファイルとして送信した場合には、メールの受信者をファイルのアクセス者とする。そして、メールの受信者は、ファイルを送信したメールのヘッダ情報に含まれる宛先を参照することによって抽出される。
【０１７２】
なお、第３の実施の形態では、クライアント３からメールログを収集しているが、メールサーバ５でメールログを収集してもよい。
【０１７３】
（第３の実施の形態の効果）
第３の実施の形態によれば、メールシステムなどによる第三者を介したファイルアクセスをアクセス履歴に含むことによって、より実態に近いアクセス履歴を取得することができる。したがって、ファイルの有用性をより正確に判定することができ、ファイルの検索精度をさらに向上させることができる。
【０１７４】
（第３の実施の形態の変形例）
第３の実施の形態の変形例として、メールシステムの代わりにインスタントメッセージシステムに対して適用してもよい。この場合には、メールサーバ５の代わりにインスタントメッセージングサーバを使用する。アクセス履歴は、インスタントメッセージングサーバ上で収集してもよいし、クライアント３から収集してもよい。
【図面の簡単な説明】
【０１７５】
【図１】第１の実施の形態のファイル共有システムの構成を示す図である。
【図２】第１の実施の形態のファイルサーバ１、メタデータサーバ２及びクライアント３のハードウェア構成を示す図である。
【図３】第１の実施の形態のファイルサーバ１のモジュール構成を示す図である。
【図４】第１の実施の形態のファイルサーバ１のファイル管理部１１Ｂのモジュール構成を示す図である。
【図５】第１の実施の形態のアクセス履歴テーブルの構成を示す図である。
【図６】第１の実施の形態のファイル格納部の構成を示す図である。
【図７】第１の実施の形態のアクセスログ格納部の構成を示す図である。
【図８】第１の実施の形態のアクセス履歴格納部の構成を示す図である。
【図９】第１の実施の形態の組織情報格納部の構成を示す図である。
【図１０】第１の実施の形態の登録ファイルの一例を示す図である。
【図１１】第１の実施の形態のメタデータ配置コマンド（登録）の一例を示す図である。
【図１２】第１の実施の形態のメタデータ配置コマンド（移動）の一例を示す図である。
【図１３】第１の実施の形態の検索条件の一例を示す図である。
【図１４】第１の実施の形態の検索コマンドの一例を示す図である。
【図１５】第１の実施の形態の検索結果の一例を示す図である。
【図１６】第１の実施の形態の表示用検索結果の一例を示す図である。
【図１７】第１の実施の形態のファイル名の一例を示す図である。
【図１８】第１の実施の形態のファイルの一例を示す図である。
【図１９】第１の実施の形態のメタデータサーバ２のモジュール構成を示す図である。
【図２０】第１の実施の形態のメタデータ格納部の構成を示す図である。
【図２１】第１の実施の形態のファイル共有システムの処理手順を示すフローチャートである。
【図２２】第１の実施の形態のメタデータ再配置処理の手順を示すフローチャートである。
【図２３】第１の実施の形態のファイルのアクセス頻度とファイルが有用である部署との関係を説明する図である。
【図２４】第１の実施の形態のファイル有用性判定処理の手順を示すフローチャートである。
【図２５】第１の実施の形態のファイル検索指示画面の画面の一例である。
【図２６】第１の実施の形態のファイルの検索結果を表示する画面の一例である。
【図２７】第１の実施の形態の部署ごとの有用なファイルの一覧を表示する画面の一例である。
【図２８】第２の実施の形態のメタデータ再配置処理の手順を示すフローチャートである。
【図２９】第３の実施の形態のファイル共有システムの構成を示す図である。
【図３０】第３の実施の形態のファイルサーバのモジュール構成を示す図である。
【図３１】第３の実施の形態のクライアントのモジュール構成を示す図である。
【符号の説明】
【０１７６】
１ ファイルサーバ
２ メタデータサーバ
３ クライアント
４ ネットワーク
５ メールサーバ
１０ ＣＰＵ
１５ ネットワークインターフェイス
２０ ハードディスク
３０ メモリ
４０ ディスプレイ
４１ ディスプレイ制御部
５０ キーボード
５１ キーボード制御部
６０ マウス
６１ マウス制御部
７０ バス
１１Ａ ファイル登録部
１１Ｂ ファイル管理部
１１Ｃ ファイル検索部
１２Ａ ファイル格納部
１２Ｂ アクセスログ格納部
１２Ｃ アクセス履歴格納部
１２Ｄ 組織情報格納部
１３Ａ 登録ファイル
１３Ｂ メタデータ配置コマンド
１３Ｃ 検索条件
１３Ｄ 検索コマンド
１３Ｅ 検索結果
１３Ｆ 表示用検索結果
１３Ｇ ファイル名
１３Ｈ ファイル
２１Ａ メタデータ登録部
２１Ｂ メタデータ管理部
２１Ｃ メタデータ検索部
２２Ａ メタデータ格納部
１１Ｂ１ アクセス履歴抽出部
１１Ｂ２ ファイル有用性判定部
１１Ｂ３ メタデータ配置部
１１Ｂ４ アクセス履歴テーブル
【技術分野】
【０００１】
本発明は、ファイル共有システムに関し、特に、ファイルサーバに格納されたファイルを管理する技術に関する。
【背景技術】
【０００２】
近年、業務効率を向上させるために多くの組織がファイル共有システムを導入している。ファイル共有システムでは、メンバ間で活用可能なファイルをファイル所有者がファイルサーバに登録することによって、他のメンバも登録されたファイルを利用することができる。
【０００３】
例えば、あるメンバが新製品の特徴及びメリットを顧客に効果的に紹介する資料を作成すれば、他のメンバも作成された製品紹介資料を活用できる。ファイル共有システムでは、資料作成者が新製品の製品紹介資料をファイルサーバに登録すると、他のメンバは新製品を顧客に紹介する際にこの製品紹介資料を容易に入手することができ、同種の資料を作成する手間を省くことができる。
【０００４】
このようなファイル共有システムは、いくつかの特許文献に開示される技術によって利便性の向上が図られている。例えば、特許文献１では、有用なファイルをファイルサーバに登録することを促進するための技術が開示されている。詳細には、ファイルサーバにファイルを登録したメンバに、人事評価に影響するポイントが付与される。
【０００５】
また、特許文献２では、ファイルサーバに登録されたファイルをより多くのメンバが活用するための技術が開示されている。詳細には、登録されたファイルからキーワードを抽出し、キーワードと、部署などのグループに対応付けられたキーワードが一致すれば、ファイルが登録されたことをキーワードが一致した部署のメンバに通知する。
【０００６】
さらに、特許文献３では、共有ファイルの検索結果を並び替える技術が開示されている。詳細には、メンバの所属部署内で過去に使用されたキーワードに基づいてファイルの検索結果を並び替えることによって、必要なファイルの取得を容易にする。
【特許文献１】特開２００１−２２２５９７号公報
【特許文献２】特開２００５−９２３４０号公報
【特許文献３】特開２００４−３４８６２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、前述の従来技術によってファイル共有システムの利便性が向上しても、共有ファイルを有効に活用できない場合がある。
【０００８】
特許文献２に開示された技術では、他の部署のファイルでも所属する部署に付与したキーワードとマッチすればサーバに登録されたことが所属する部署のメンバに通知される。しかし、無駄な通知を排除し、有用なファイルの登録通知を効率的に取得するためには、キーワードを頻繁にメンテナンスしなければならない。また、有用なファイルが自部署のサーバに格納されていても、不要なファイルがサーバに多く含まれていると、検索の処理速度及び精度が低下してしまう。
【０００９】
特許文献３に開示された技術では、検索結果から有用なファイルを見つけ出すことができても、検索の処理速度及び精度そのものを改善することはできない。
【課題を解決するための手段】
【００１０】
本発明の代表的な一形態では、ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムであって、前記ファイルサーバは、前記ネットワークと接続する第１インターフェイスと、前記第１インターフェイスと接続され、プログラムを実行する第１プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第１メモリと、前記ファイルを格納する第１ストレージ装置と、を備え、前記第１メモリは、組織を構成する部署を記録した組織情報を格納し、前記第１プロセッサは、前記ファイルのアクセス履歴を記録し、前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、前記有用性が高いと判定されたファイルを検索することを特徴とする。
【発明の効果】
【００１１】
本発明の一形態によれば、有用性が高いと判定されたファイルを部署と対応付けて管理することによって、検索精度の向上及び検索速度の高速化を図ることができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態を添付図面に基づいて説明する。
【００１３】
（第１の実施の形態）
第１の実施の形態では、ファイルサーバに格納されたファイルに対するアクセス履歴を記録し、周期的にアクセス履歴を解析してファイルが高い有用性を持つ部署を判定し、ファイルのメタデータを当該部署に対応付けて管理する。
【００１４】
（システムの全体構成）
図１は、第１の実施の形態のファイル共有システム全体の構成図である。第１の実施の形態のファイル共有システムは、ファイルサーバ１、メタデータサーバ２及びクライアント３を含む。ファイルサーバ１、メタデータサーバ２及びクライアント３は、ネットワーク４によって接続される。ネットワーク４は、例えば、ＩＰネットワークによって構成される。
【００１５】
ファイルサーバ１は、メンバ間で共有するファイルを格納及び管理する計算機である。例えば、ファイルサーバ１は、ＣＩＦＳ（ＣＯＭＭＯＮ ＩＮＴＥＲＮＥＴ ＦＩＬＥ ＳＹＳＴＥＭ、ＭＩＣＲＯＳＯＦＴ社のＷＩＮＤＯＷＳ（登録商標）のファイル共有サービスで利用されるプロトコル）あるいはＳａｍｂａ（ＷＩＮＤＯＷＳ(登録商標）
マシンにファイル共有のサービスを提供するＵＮＩＸ（登録商標）系ＯＳ向けのフリーソフトウェア）などを実装することによって、クライアント３にファイル共有機能を提供する。
【００１６】
メタデータサーバ２は、ファイルサーバ１に格納されたファイルのメタデータを格納及び管理する計算機である。メタデータサーバ２は、リレーショナルデータベース（以下、「ＲＤＢ」）が実装され、メタデータを格納及び管理する。なお、メタデータとは、ファイルに関する情報を記述したデータであり、例えば、ファイルのパス、作成者及び作成日などの書誌的／システム的情報、ファイルに含まれる文字列やキーワードなどである。
【００１７】
クライアント３は、組織のメンバが使用する計算機である。クライアント３は、ファイルをファイルサーバ１に登録したり、ファイルサーバ１に格納されたファイルにアクセスする。
【００１８】
なお、図１では、ファイルサーバ１及びメタデータサーバ２は、それぞれ１台ずつの計算機が対応しているが、これに限定する必要はない。ファイルサーバ１及びメタデータサーバ２は同一の計算機に実装されてもよいし、ファイルサーバ１又はメタデータサーバ２がそれぞれ複数の計算機によって構成されてもよい。
【００１９】
（ハードウェア構成）
図２は、第１の実施の形態のファイルサーバ１のハードウェア構成図である。なお、ファイルサーバ１、メタデータサーバ２及びクライアント３のハードウェアは、すべて同一である。
【００２０】
ファイルサーバ１は、ＣＰＵ１０、ネットワークインターフェース１５、ハードディスク２０、メモリ３０、ディスプレイ４０、ディスプレイ制御部４１、キーボード５０、キーボード制御部５１、マウス６０、マウス制御部６１及びバス７０を含む。
【００２１】
ＣＰＵ１０は、メモリ３０に格納されたプログラムを実行することによって、データの入出力及び各種処理を実行する。ネットワークインターフェース１５は、ネットワークを介して他の計算機と通信する。ハードディスク２０は、プログラム及びデータを格納する。メモリ３０は、ＣＰＵ１０によって実行されるプログラム及びデータを記憶する。
【００２２】
ディスプレイ４０は、利用者にデータを表示し、ディスプレイ制御部４１によって制御される。キーボード５０は、利用者からの入力を受け付け、キーボード制御部５１によって制御される。マウス６０は、利用者からの入力を受け付け、マウス制御部６１によって制御される。バス７０は、各構成要素にデータを受け渡す。
【００２３】
（ファイルサーバ１のモジュール構成）
図３は、第１の実施の形態のファイルサーバ１のモジュール構成図である。ファイルサーバ１は、各種処理を実行する処理部、データを格納するデータ格納部及び一時的に生成されるデータを格納するテンポラリデータ部を含む。処理部は矩形、データ格納部はドラム形、テンポラリデータ部はテープ形で表す。
【００２４】
（ファイルサーバ１のモジュール構成：処理部）
ファイルサーバ１の処理部は、ファイル登録部１１Ａ、ファイル管理部１１Ｂ及びファイル検索部１１Ｃを含む。
【００２５】
ファイル登録部１１Ａは、クライアント３から送信された登録ファイル１３Ａをファイル格納部１２Ａに格納する。また、ファイル登録部１１Ａは、登録ファイル１３Ａを格納するとき、登録ファイル１３Ａを基にメタデータを生成する。そして、ファイル登録部１１Ａは、メタデータ配置コマンド１３Ｂを作成してメタデータサーバ２に送信する。
【００２６】
ファイル管理部１１Ｂは、ファイルサーバ１に格納されたファイルの有用性を判定し、メタデータを再配置する。ファイル管理部１１Ｂの構成は、図４にて詳細を後述する。
【００２７】
ファイル検索部１１Ｃは、クライアント３で入力された検索条件１３Ｃを受信して検索コマンド１３Ｄを生成し、メタデータサーバ２に送信する。そして、ファイル検索部１１Ｃは、メタデータサーバ２から検索結果１３Ｅを受信し、表示用検索結果１３Ｆを生成してクライアント３に送信する。さらに、ファイル検索部１１Ｃは、クライアント３でファイル名１３Ｇが選択されると、ファイル格納部１２Ａから該当するファイル１３Ｈを抽出し、クライアント３に送信する。
【００２８】
（ファイル管理部１１Ｂの詳細なモジュール構成）
図４は、第１の実施の形態のファイル管理部１１Ｂの詳細なモジュール構成図である。ファイル管理部１１Ｂは、処理部（矩形）、データ格納部（ドラム形）、テンポラリデータ部（テープ形）及びテーブル（平行四辺形）の４種類のモジュールを含む。なお、図４に示すアクセスログ格納部１２Ｂ、アクセス履歴格納部１２Ｃ、組織情報格納部１２Ｄ及びメタデータ配置コマンド１３Ｂは、図３に示すファイルサーバ１を構成するモジュールと同じであり、詳細は後述する。
【００２９】
（ファイル管理部１１Ｂの詳細なモジュール構成：処理部）
ファイル管理部１１Ｂの処理部は、アクセス履歴抽出部１１Ｂ１、ファイル有用性判定部１１Ｂ２及びメタデータ配置部１１Ｂ３を含む。
【００３０】
アクセス履歴抽出部１１Ｂ１は、アクセスログ格納部１２Ｂからファイルサーバ１に格納されたアクセスログを取得する。アクセスログとは、ファイルサーバ１にファイルを登録したり、ファイルサーバ１に格納されたファイルを参照した履歴である。
【００３１】
また、アクセス履歴抽出部１１Ｂ１は、アクセスログからアクセス履歴を抽出し、アクセス履歴格納部１２Ｃに格納する。アクセス履歴とは、アクセスログに記録された情報のうち、ファイルを参照した記録のみを抽出したものである。
【００３２】
ファイル有用性判定部１１Ｂ２は、アクセス履歴格納部１２Ｃに格納されたアクセス履歴を解析し、ファイルの有用性を判定する。なお、ファイルの有用性を判定する処理については、図２４にて後述する。
【００３３】
メタデータ配置部１１Ｂ３は、有用と判定されたファイルを部署と対応付ける。具体的には、このファイルのメタデータを部署と対応付けるためのメタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。なお、メタデータを再配置する処理については、図２２にて後述する。
【００３４】
（ファイル管理部１１Ｂの詳細なモジュール構成：テーブル）
図５は、第１の実施の形態のアクセス履歴テーブル１１Ｂ４の構成を示す図である。アクセス履歴テーブル１１Ｂ４は、エントリ１１Ｂ４０１及び所属１１Ｂ４０２を含む。
【００３５】
エントリ１１Ｂ４０１は、あるファイルを参照したメンバの氏名又は当該メンバが所属する部署名を格納する。所属１１Ｂ４０２は、エントリ１１Ｂ４０１に格納されたメンバ又は部署が所属する部署名を格納する。
【００３６】
図５は、第５行目にエントリとしてメンバの氏名「鈴木一郎」が格納されており、所属は「営業１課」であることを示している。
【００３７】
（ファイルサーバ１のモジュール構成：データ格納部）
ファイルサーバ１のデータ格納部は、ファイル格納部１２Ａ、アクセスログ格納部１２Ｂ、アクセス履歴格納部１２Ｃ及び組織情報格納部１２Ｄを含む。
【００３８】
ファイル格納部１２Ａは、共有ファイルを格納する。アクセスログ格納部１２Ｂは、ファイルサーバ１に対するアクセスログを格納する。例えば、ファイル共有機能を提供するＣＩＦＳプロトコル又はＳａｍｂａが出力するログを使用する。アクセス履歴格納部１２Ｃは、前述のように、アクセスログ格納部１２Ｂに格納されたアクセスログから抽出されたアクセス履歴を格納する。組織情報格納部１２Ｄは、部署及び組織のメンバを含む組織の構成情報を格納する。
【００３９】
以下、各データ格納部の構成について説明する。
【００４０】
（ファイル格納部１２Ａの構成）
図６は、第１の実施の形態のファイル格納部１２Ａの構成図である。ファイル格納部１２Ａは、ファイル名１２Ａ０１、ファイルデータ１２Ａ０２、メタデータテーブル名１２Ａ０３及びメタデータ配置日１２Ａ０４を含む。
【００４１】
ファイル名１２Ａ０１は、ファイルサーバ１に格納された共有ファイルのパスを含んだファイル名を格納する。ファイルデータ１２Ａ０２は、ファイルの文字列や書式情報などを含むファイルの内容を格納する。ファイルデータ１２Ａ０２は、ファイルそのものであってもよいし、ファイルの格納場所を示すリンクであってもよい。
【００４２】
メタデータテーブル名１２Ａ０３は、後述するメタデータ格納部２２Ａに含まれるメタデータテーブル２２Ａ００の名前を格納する。メタデータ配置日１２Ａ０４は、メタデータをメタデータテーブル２２Ａ００に配置した日付を格納する。
【００４３】
図６に示すように、第１行目にはファイル名が「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」であるファイルのデータ「○月×日に、課長同行の下、Ａ社殿にご提案し、…」が格納されている。さらに、このファイルのメタデータは、テーブル「ｅｉｇｙｏ１」に格納され、２００５年１２月３日に配置されたことが記録されている。
【００４４】
なお、図６ではファイルデータ１２Ａ０２としてテキストデータのみを示しているが、画像ファイル又は動画ファイルなどであってもよい。また、図６は、ファイル格納部１２Ａを表形式で示しているが、ファイルに属性としてこれらの情報を保持させてもよい。
【００４５】
（アクセスログ格納部１２Ｂの構成）
図７は、第１の実施の形態のアクセスログ格納部１２Ｂの構成図である。アクセスログ格納部１２Ｂは、アクセス日１２Ｂ０１、アクセス者１２Ｂ０２、ファイル名１２Ｂ０３及びアクセス種別１２Ｂ０４を含む。
【００４６】
アクセス日１２Ｂ０１は、ファイルサーバ１に格納されたファイルにアクセスした日付が格納される。図７では日付のみが表示されているが、詳細なアクセス時刻を記録してもよい。アクセス者１２Ｂ０２は、ファイルにアクセスしたメンバのユーザＩＤを格納する。ファイル名１２Ｂ０３は、アクセスされたファイルのファイル名を格納する。アクセス種別１２Ｂ０４は、ファイルの登録、参照又は削除などアクセスの種別が格納される。
【００４７】
図７に示すように、第１行目には、２００５年の１０月２４日にユーザＩＤが「ｋａｔｏｈ」であるメンバがファイル「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」を登録したことが記録されている。
【００４８】
（アクセス履歴格納部１２Ｃの構成）
図８は、第１の実施の形態のアクセス履歴格納部１２Ｃの構成図である。アクセス履歴格納部１２Ｃは、アクセス日１２Ｃ０１、アクセス者１２Ｃ０２、及びファイル名１２Ｃ０３を含む。
【００４９】
アクセス日１２Ｃ０１には、ファイルのアクセス日を格納する。なお、図８では日付のみを記録されているが、詳細なアクセス時刻を記録してもよい。アクセス者１２Ｃ０２には、ファイルにアクセスしたメンバのユーザＩＤを格納する。ファイル名１２Ｃ０３には、アクセスされたファイル名を格納する。
【００５０】
図８に示すように、第１行目には２００５年の１０月２４日にユーザＩＤが「ｙａｍａｄａ」であるメンバがファイル「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」にアクセスした履歴が記録されている。
【００５１】
（組織情報格納部１２Ｄの構成）
図９は、第１の実施の形態の組織情報格納部１２Ｄの構成図である。組織情報格納部１２Ｄは、エントリ１２Ｄ０１、ユーザＩＤ１２Ｄ０２、所属１２Ｄ０３及びメタデータテーブル名１２Ｄ０４を含む。
【００５２】
エントリ１２Ｄ０１は、組織を構成する部署名又は部署に所属するメンバ名が格納される。ユーザＩＤ１２Ｄ０２は、ファイル共有システムにおけるエントリのユーザＩＤが格納される。所属１２Ｄ０３は、エントリが所属する部署名が格納される。メタデータテーブル名１２Ｄ０４は、後述するメタデータ格納部２２Ａにおいてエントリに対応するメタデータテーブル名が格納される。
【００５３】
図９に示すように、第１行目にはエントリ「庶務課」が「総務部」に所属し、対応するメタデータテーブルの名前が「ｓｙｏｍｕ」であることが記録されている。また、第５行目にはエントリ「鈴木一郎」のユーザＩＤは「ｓｕｚｕｋｉ」であり、「営業１課」に所属していることが記録されている。
【００５４】
なお、図９ではエントリが部署の場合はユーザＩＤが付与されていないが、部署にユーザＩＤを付与して部署としての権限でファイルをファイルサーバ１に登録及びアクセスすることも可能である。また、エントリがメンバ（人）の場合には、メタデータテーブル名が対応付けられていないが、メンバを組織を構成する最小の単位として対応付けてもよい。このとき、あるメンバのみが利用するファイルのメタデータは、当該メンバに対応させて管理する。
【００５５】
さらに、組織情報格納部１２Ｄは、組織で導入／利用されているＩＴシステムのデータを流用してもよい。具体的には、セキュリティシステムにおけるＬＤＡＰ、メールシステムにおける電子電話帳、文書管理システムにおけるユーザ情報などを組織情報として用いてもよい。
【００５６】
（ファイルサーバ１のモジュール構成：テンポラリデータ部）
テンポラリデータ部は、登録ファイル１３Ａ、メタデータ配置コマンド１３Ｂ、検索条件１３Ｃ、検索コマンド１３Ｄ、検索結果１３Ｅ、表示用検索結果１３Ｆ、ファイル名１３Ｇ及びファイル１３Ｈを含む。
【００５７】
登録ファイル１３Ａは、クライアント３からファイルサーバ１に登録するファイルである。メタデータ配置コマンド１３Ｂは、メタデータサーバ２にメタデータを配置するコマンドである。検索条件１３Ｃは、クライアント３からメンバが入力したファイルの検索条件である。検索コマンド１３Ｄは、メタデータを検索するためのコマンドである。検索結果１３Ｅは、検索コマンド１３Ｄを実行した結果である。表示用検索結果１３Ｆは、検索結果１３Ｅを表示するために加工されたデータである。ファイル名１３Ｇは、メンバが選択したファイルのファイル名である。ファイル１３Ｈは、ファイル名１３Ｇに対応するファイルそのものである。
【００５８】
（登録ファイル１３Ａの一例）
図１０は、第１の実施の形態の登録ファイル１３Ａの一例を示す図である。登録ファイル１３Ａは、ファイルデータ１３Ａ０１を格納する。図１０に示すように、ファイルデータ１３Ａ０１の内容は、「営業日報 ○月×日、Ａ社殿に事務システムのご提案…」となっている。
【００５９】
（メタデータ配置コマンド１３Ｂの一例）
図１１及び図１２は、第１の実施の形態のファイルサーバ１からメタデータサーバ２に送信するメタデータ配置コマンド１３Ｂの一例を示す図である。第１の実施の形態では、前述のようにメタデータサーバ２にはＲＤＢが実装されているため、メタデータ配置コマンド１３Ｂは、ＲＤＢに対するＳＱＬコマンドとなる。
【００６０】
ＳＱＬコマンド１３Ｂ０１は、メタデータをメタデータサーバ２のＲＤＢに登録するためのコマンドの一例である。ＳＱＬコマンド１３Ｂ０１は、ファイル名が「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」及びメタデータが「Ａ社」「提案」「事務システム」となるレコードをメタデータテーブル「ｅｉｇｙｏ１」に挿入する。
【００６１】
ＳＱＬコマンド１３Ｂ０２は、メタデータサーバ２に登録済みのメタデータを再配置するＳＱＬコマンドの一例である。ＳＱＬコマンド１３Ｂ０２は、ファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」のメタデータをメタデータテーブル名「ｅｉｇｙｏ１」から「ｅｉｇｙｏ」に移動させる。
【００６２】
（検索条件１３Ｃの一例）
図１３は、第１の実施の形態のファイル検索条件１３Ｃの一例を示す図である。検索条件１３Ｃは、ユーザＩＤ１３Ｃ０１、クライアント１３Ｃ０２、部署１３Ｃ０３及びキーワード１３Ｃ０４を含む。
【００６３】
ユーザＩＤ１３Ｃ０１は、検索条件を入力した利用者のユーザＩＤを格納する。クライアント１３Ｃ０２は、検索条件を入力した利用者が使用しているクライアント３の識別名を格納する。部署１３Ｃ０３は、利用者が検索条件として指定した部署を格納する。キーワード１３Ｃ０４は、利用者が検索条件として入力したキーワードを格納する。
【００６４】
図１３は、ユーザＩＤが「ｓａｔｏｈ」であるメンバがクライアント「ｓａｔｏｈ−ｐｃ」において、「営業１課」にて有用性が高いと判定されたファイルのうち「Ａ社、提案」をキーワードとして含むファイルを検索する条件を示している。
【００６５】
（検索コマンド１３Ｄの一例）
図１４は、第１の実施の形態のファイル検索部１２Ｃがメタデータサーバ２に送信する検索コマンド１３Ｄの一例を示す図である。前述のようにメタデータはＲＤＢに格納されているため、検索コマンド１３ＤはＳＱＬコマンド１３Ｄ０１である。
【００６６】
ＳＱＬコマンド１３Ｄ０１は、メタデータテーブル「ｅｉｇｙｏ１」からメタデータに「Ａ社」及び「提案」を含むレコードのファイル名を取得する。
【００６７】
（検索結果１３Ｅの一例）
図１５は、第１の実施の形態のファイル検索部１２Ｃがメタデータサーバ２から受信する検索結果１３Ｅの一例を示す図である。
【００６８】
検索結果１３Ｅは、検索コマンド１３Ｄの実行結果１３Ｅ０１である。図１５に示すように、第１行目には、図１４に示す検索コマンド１３Ｄの実行結果１３Ｅ０１としてファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」が格納されている。
【００６９】
（表示用検索結果１３Ｆの一例）
図１６は、第１の実施の形態のファイル検索部１２Ｃがクライアント３に送信する表示用検索結果１３Ｆの一例を示す図である。
【００７０】
表示用検索結果１３Ｆには、検索結果１３Ｅから取得されたファイル名と、ファイルの内容の一部又は全部とが含まれている。図１６に示すように、表示用検索結果１３Ｆの第１行目には表示内容１３Ｆ０１として、ファイル名「ｆｉｌｅ１．ｄｏｃ」が、第２行目にはファイルの内容「○月×日，課長同行の下，Ａ社殿に…」が格納されている。
【００７１】
（ファイル名１３Ｇの一例）
図１７は、第１の実施の形態の利用者によって選択されたファイル名１３Ｇの一例を示す図である。図１７に示すように、利用者が選択したファイル名１３Ｇ０１として「ｆｉｌｅ１．ｄｏｃ」が格納されている。
【００７２】
（ファイル１３Ｈの一例）
図１８は、第１の実施の形態のメンバが指定したファイル名を有するファイル１３Ｈの一例を示す図である。ファイル１３Ｈは、ファイルデータ１３Ｈ０１を格納する。図１８に示すように、ファイルデータ１３Ｈ０１には「○月×日，課長同行の下，Ａ社殿にご提案…」が格納されている。
【００７３】
（メタデータサーバ２のモジュール構成）
図１９は、第１の実施の形態のメタデータサーバ２のモジュール構成図である。メタデータサーバ２は、図３に示したファイルサーバ１と同様に、処理部、データ格納部及びテンポラリデータ部を含む。
【００７４】
（メタデータサーバ２のモジュール構成：処理部）
メタデータサーバ２の処理部は、メタデータ登録部２１Ａ、メタデータ管理部２１Ｂ及びメタデータ検索部２１Ｃを含む。
【００７５】
メタデータ登録部２１Ａは、ファイルサーバ１から送信されたメタデータ配置コマンド１３Ｂを受信し、メタデータ格納部２２Ａにメタデータを格納する。メタデータ管理部２１Ｂは、ファイルサーバ１からメタデータ配置コマンド１３Ｂを受信し、メタデータ格納部２２Ａに格納されているメタデータを再配置する。メタデータ検索部２１Ｃは、ファイルサーバ１から検索コマンド１３Ｄを受信し、メタデータ格納部２２に対して検索コマンド１３Ｄを実行し、検索結果１３Ｅをファイルサーバ１に送信する。
【００７６】
（メタデータサーバ２のモジュール構成：データ格納部）
図２０は、第１の実施の形態のメタデータ格納部２２Ａの構成図である。前述のようにメタデータサーバ２にはＲＤＢが実装されており、メタデータ格納部２２Ａは、組織の各部署に対応するテーブル２２Ａ００を格納する。
【００７７】
テーブル２２Ａ００は、ファイル名２２Ａ０１及びメタデータ２２Ａ０２を含む。ファイル名２２Ａ０１は、ファイルサーバ１に格納されているファイルのファイル名を格納する。メタデータ２２Ａ０２は、当該ファイルのメタデータを格納する。
【００７８】
図２０に示すように、第１行目のレコードにファイル名「￥￥ｆｓ￥ｆｉｌｅ１．ｄｏｃ」と、対応するメタデータ「営業日報、Ａ社、提案…」が格納されている。
【００７９】
なお、メタデータ２２Ａ０２には、一例として、ファイルから抽出したキーワードを示しているが、ファイルの作成者名又は作成日のようにファイル属性として取得可能な書誌的データ又はアノテーションなどを含んでもよい。
【００８０】
（メタデータサーバ２のモジュール構成：テンポラリデータ格納部）
メタデータサーバ２のテンポラリデータ格納部は、メタデータ配置コマンド１３Ｂ、検索コマンド１３Ｄ及び検索結果１３Ｅを含む。メタデータ配置コマンド１３Ｂ、検索コマンド１３Ｄ及び検索結果１３Ｅは、ファイルサーバ１のテンポラリデータ格納部と共通であるため、説明を省略する。
【００８１】
以上、第１の実施の形態のファイル共有システムの構成について説明した。
【００８２】
（ファイル共有システムの処理手順）
続いて、第１の実施の形態のファイル共有システムで実行される処理について説明する。第１の実施の形態では、部署によってファイルの有用性が異なる点に着目し、ファイルのアクセス履歴に基づき、利用者の多い部署において有用性が高いと判定する。そこで、ファイルが有用と判定された部署に対応させてファイルのメタデータを配置する。さらに、時間の経過とともにファイルの有用性が変化しうる点を考慮し、周期的にファイルの有用性を判定し、メタデータを再配置する。
【００８３】
図２１は、第１の実施の形態のファイル共有システム内に常駐して実行される処理を示すフローチャートである。なお、説明文の末尾の括弧内の数字は、各フローチャートにおける処理番号である。
【００８４】
ファイルサーバ１は、現在時刻が予め定められたメタデータ再配置処理の実行時刻と一致するか否かを判定する（Ｓ１０１）。ファイルサーバ１は、メタデータ再配置処理の実行時刻になると（Ｓ１０１の結果が「Ｙ」）、メタデータ再配置処理を実行する（Ｓ１０２）。メタデータ再配置処理の詳細は、図２４にて後述する。
【００８５】
ファイルサーバ１は、現在時刻がメタデータを再配置する時刻でない場合には（Ｓ１０１の結果が「Ｎ」）、クライアント３からの入力の有無を判定する（Ｓ１０３）。
【００８６】
ファイルサーバ１は、クライアント３から指示が入力された場合には（Ｓ１０３の結果が「Ｙ」）、入力指示が登録指示であるか否かを判定する（Ｓ１０４）。一方、クライアント３からの入力がなかった場合には、Ｓ１０１の処理に戻る。
【００８７】
ファイルサーバ１は、クライアント３からの入力が登録指示であった場合には（Ｓ１０４の結果が「Ｙ」）、ファイルの登録処理を実行する（Ｓ１０５）。ファイルの登録処理は、ファイル登録部１１Ａによって実行される。
【００８８】
ファイル登録部１１Ａは、クライアント３から送信された登録ファイル１３Ａを受信し、ファイル格納部１２Ａに格納する。
【００８９】
また、ファイル登録部１１Ａは、登録ファイル１３Ａを格納するとともに、登録ファイル１３Ａからキーワードを抽出する。キーワードの抽出は、非特許文献１（下畑光夫等、“文字種切り出しと複合語分解によるキーワード抽出”、情報処理学会、自然言語処理研究会報告、１２０−１３、１９９７）又は非特許文献２（原正巳等“テキストのフォーマットと単語の範囲内重要度を利用したキーワード抽出”、情報処理学会、論文誌、ＶＯＬ．３８、ＮＯ．２、１９９７）に記載の従来技術を適用することによって実現できる。また、ファイルを登録する者がキーワードを手入力する構成としてもよい。
【００９０】
また、ファイル登録部１１Ａは、組織情報格納部１２Ｄを参照し、登録ファイル１３Ａを送信したメンバの所属を取得し、さらに取得した所属からメタデータテーブル名１２Ｄ０４を取得する。そして、ファイル登録部１１Ａは、抽出したキーワードをメタデータとしてメタデータテーブルに挿入する。具体的には、メタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。
【００９１】
メタデータサーバ２のメタデータ登録部２１Ａは、メタデータ配置コマンド１３Ｂを受信すると、メタデータ格納部２２Ａに対してコマンドを実行し、メタデータを格納する。
【００９２】
その後、ファイル登録部１１Ａは、メタデータを格納したメタデータテーブル名をファイル格納部１２Ａのメタデータテーブル名１２Ａ０３に記録する。さらに、ファイル登録部１１Ａは、登録日をファイル格納部１２Ａのメタデータ配置日１２Ａ０４に記録して、Ｓ１０１の処理に戻る（Ｓ１０５）。
【００９３】
ファイルサーバ１は、クライアント３からの入力が検索指示であるかを判定する（Ｓ１０６）。検索指示でない場合には、Ｓ１０１の処理に戻る（Ｓ１０６の結果が「Ｎ」）。
【００９４】
ファイルサーバ１は、クライアント３からの入力が検索指示であった場合には（Ｓ１０６の結果が「Ｙ」）、ファイル検索を実行する（Ｓ１０７）。ファイル検索は、ファイル検索部１１Ｃによって実行される。
【００９５】
ファイル検索部１１Ｃは、クライアントから送信された検索条件１３Ｃを受信する。ファイル検索部１１Ｃは、検索コマンド１３Ｄを生成し、メタデータサーバ２に送信する。メタデータサーバ２のメタデータ検索部２１Ｃは、検索コマンド１３Ｄを受信すると、検索コマンド１３Ｄをメタデータ格納部２２Ａに対して実行する。メタデータ検索部２１Ｃは、検索結果１３Ｅをファイルサーバ１のファイル検索部１１Ｃに送信する。
【００９６】
ファイル検索部１１Ｃは、検索結果１３Ｅを基に表示用検索結果１３Ｆを作成する。表示用検索結果１３Ｆには、ファイル名及びファイルの内容の一部又は全部が含まれる。ファイル検索部１１Ｃは、作成した表示用検索結果１３Ｆをクライアント３に送信する。
【００９７】
クライアント３は、受信した表示用検索結果１３Ｆを画面に表示する。メンバが表示されたファイル名を選択すると、クライアント３は、選択されたファイル名１３Ｇをファイルサーバ１に送信する。ファイルサーバ１は、ファイル名１３Ｇを受信し、該当するファイル１３Ｈをファイル格納部１１Ａから取得し、クライアント３に送信する。クライアント３は、ファイルサーバ１から送信されたファイル１３Ｈを画面に表示する（Ｓ１０７）。
【００９８】
（メタデータ再配置処理の詳細な処理手順）
図２２は、第１の実施の形態のメタデータ再配置処理の処理手順を示すフローチャートである。
【００９９】
ファイル管理部１１Ｂは、まずアクセス履歴格納部１２Ｃをクリアしてアクセスログ格納部１２Ｂからアクセス種別１２Ｂ０４が「参照」であるアクセスログを抽出してアクセス履歴格納部１２Ｃに格納する（Ｓ２０１）。さらに、ファイル管理部１１Ｂは、ファイル名１２Ｃ０３をキーとしてアクセス履歴格納部１２Ｃのレコードをソートする（Ｓ２０２）。したがって、アクセス履歴格納部１２Ｃには、同一ファイルに対するアクセスを記録したレコードが連続して格納される。そして、アクセス履歴格納部１２Ｃを先頭レコードから順次処理し、ファイルごとの有用性を判定する。
【０１００】
ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃの処理対象となるレコードのインデックスを示す大域変数ｉに１をセットする（Ｓ２０３）。
【０１０１】
ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のレコードに格納されているファイル名を大域変数ＦＮにセットする（Ｓ２０４）。変数ＦＮには、有用性を判定するファイルのファイル名が格納される。ファイル管理部１１Ｂは、ファイル格納部１２Ａを参照し、ＦＮに対応するメタデータテーブル名を取得し、大域変数ＴＮ１にセットする（Ｓ２０５）。
【０１０２】
ファイル管理部１１Ｂは、大域変数ＴＮ２を初期化する（Ｓ２０６）。ＴＮ２は、Ｓ２０７の処理にてファイルの有用性を判定し、有用と判定された部署に対応するメタデータテーブルのテーブル名を格納する変数である。
【０１０３】
続いて、ファイル管理部１１Ｂは、インデックスｉの値を増やしながらアクセス履歴格納部１２Ｃからアクセス履歴を読み込み、ＦＮの有用性を判定する（Ｓ２０７）。ファイル有用性判定処理では、ＴＮ２に現時点で有用と判定された部署に対応するメタデータテーブルのテーブル名を格納する。
【０１０４】
ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが異なっているか否かを判定する（Ｓ２０８）。ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが異なっている場合には（Ｓ２０８の結果が「Ｙ」）、ＦＮを有用と判定した部署が変化したため、メタデータを再配置する（Ｓ２０９）。メタデータの再配置は、ファイル名がＦＮに対応するメタデータをテーブルＴＮ１からＴＮ２に移動する。具体的には、ファイル管理部１１Ｂは、メタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する（Ｓ２０９）。
【０１０５】
一方、ファイル管理部１１Ｂは、ＴＮ１とＴＮ２とが等しい場合（Ｓ２０８の結果が「Ｎ」）、又はメタデータの再配置を完了した場合には、ファイル格納部１２ＡのＦＮに対応するレコードを更新する（Ｓ２１０）。具体的には、メタデータテーブル名１２Ａ０３及びメタデータ配置日１２Ａ０４を更新する。メタデータを再配置しない場合であっても、メタデータ配置日１２Ａ０４を更新することによって、メタデータ配置日時点でファイルが有用であることを判断することができる。
【０１０６】
ファイル管理部１１Ｂは、インデックスｉの値とアクセス履歴格納部１２Ｃのレコード件数とを比較する（Ｓ２１１）。インデックスｉがアクセス履歴格納部１２Ｃに格納されたアクセス履歴数以下の場合には（Ｓ２１１の結果が「Ｎ」）、すべてのファイルについて有用性が判定されていないため、Ｓ２０４の処理に移行し、残りのファイルの有用性を判定する。インデックスｉがアクセス履歴数よりも大きい場合には（Ｓ２１１の結果が「Ｙ」）、アクセスされたすべてのファイルの有用性の判定が終了したため、メタデータ再配置処理Ｓ１０２を終了する。
【０１０７】
（組織におけるファイルの有用性）
ここで、ファイルの有用性判定処理について説明する前に、組織におけるファイルの有用性について説明する。
【０１０８】
ファイルの有用性は、前述のように、ファイルに対するアクセスの頻度によって判定する。具体的には、アクセス頻度が高ければファイルの有用性が高いと判定し、反対に頻度が低ければ有用性が低いと判定する。
【０１０９】
さらに、ファイルが「誰にとって」有用であるかを考慮し、あるファイルが有用である可能性が高いメンバがこのファイルにアクセスしやすいように管理する。具体的には、あるファイルにアクセスしたメンバを多く含む部署にとってファイルが有用であると判定し、ファイルと部署とを対応付けて管理する。
【０１１０】
また、ファイルの有用性は時間の経過とともに変化する。アクセス頻度が高く有用であったファイルであってもアクセス頻度が低くなれば有用性も低下する。また、ファイルを作成した段階ではアクセス頻度が低かったファイルであっても時間の経過とともにアクセス頻度が高くなれば有用性は高くなる。そこで、有用である部署が変化したか否かを周期的にチェックし、変化していれば新たに有用であると判定された部署とファイルとを対応付ける。
【０１１１】
図２３は、ファイルのアクセス頻度とファイルが有用である部署との関係を説明する図である。一例として、組織は、「Ｘ部」、「Ｙ部」及び「Ｚ部」によって構成され、「Ｘ部」はさらに「Ｘ１課」、「Ｘ２課」及び「Ｘ３課」によって構成される。
【０１１２】
図２３の（Ａ）は、ファイルサーバに登録されているファイルが「Ｘ１課」のメンバからアクセスされている状態を表す。この状態では、当該ファイルは「Ｘ１課」において有用であると考えられる。
【０１１３】
ここで、（Ａ）の状態から（Ｂ）の状態に変化し、「Ｘ３課」からも当該ファイルにアクセスされるようになったとする。このとき、（Ｃ）に示すように、「Ｘ１課」に加えて「Ｘ３課」でも当該ファイルが有用になったと考えられる。
【０１１４】
しかし、（Ｃ）では、「Ｘ３課」のみで有用であるファイルと、「Ｘ１課」と「Ｘ３課」とで共通して有用なファイルが同様に扱われてしまう。その結果、「Ｘ３課」のみで有用なファイル、例えば、「Ｘ３課」の業務にのみ関連したファイルを検索する場合であっても、「Ｘ１課」と「Ｘ３課」で共通の有用なファイルがともに抽出され、検索精度が悪化するなどの問題が生じてしまう。
【０１１５】
そこで、第１の実施の形態では、あるファイルについて（Ａ）から（Ｂ）に示す状態に変化した場合には、ファイルが有用である組織のレベルが変化したものとする。具体的には、（Ｄ）に示すように「Ｘ１課」と「Ｘ３課」の共通の上位部署である「Ｘ部」が当該ファイルが有用である部署と判定する。こうすることによって、「Ｘ３課」のみで有用なファイルと明確に区別することができる。そして、ファイルが有用である部署を指定することによって、業務に直結したファイル又は組織内で一段上位のレベルで有用なファイルなど、利用者が必要とするファイルを容易に取得することができる。
【０１１６】
また、（Ａ）の状態から（Ｂ）の状態にアクセス頻度が変化したということは、今後「Ｘ部」に属する部署で「Ｘ１課」及び「Ｘ３課」以外の部署、すなわち「Ｘ２課」からもアクセス頻度が増加する可能性がある。そこで、（Ｄ）に示すように上位部署である「Ｘ部」で有用であると判定すれば、「Ｘ２課」からも容易に当該ファイルにアクセスできるようになる。
【０１１７】
（ファイル有用性判定処理の処理手順）
図２４は、図２２に示すメタデータ再配置処理Ｓ１０２のファイル有用性判定処理Ｓ２０７の処理手順を示すフローチャートである。ファイル有用性判定処理Ｓ２０７は、ファイル管理部１１Ｂによって実行される。
【０１１８】
ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４のインデックスを示す変数ｊに１をセットして初期化する（Ｓ３０１）。
【０１１９】
続いて、ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のアクセス者１２Ｃ０２を抽出し、組織情報格納部１２Ｄを参照してユーザＩＤ１２Ｄ０２と一致するエントリ１２Ｄ０１を取得する。そして、取得したエントリ１２Ｄ０１をアクセス履歴テーブル１１Ｂ４のｊ番目のレコードのエントリ１１Ｂ４０１に格納する（Ｓ３０２）。同様に、アクセス履歴格納部ｉ番目のアクセス者の所属を取得し、アクセス履歴テーブル１１Ｂ４のｊ番目のレコードの所属１１Ｂ４０２にセットする（Ｓ３０３）。
【０１２０】
次に、ファイル管理部１１Ｂは、ｉとｊをそれぞれ１ずつ加算する（Ｓ３０４）。さらに、アクセス履歴格納部１２Ｃのｉ番目のファイル名がＦＮと一致するか否かを判定する（Ｓ３０５）。一致する場合には（Ｓ３０５の結果が「Ｙ」）、該当するレコードがＦＮに対するアクセス履歴であるため、ファイル管理部１１Ｂは、Ｓ３０２の処理を実行し、アクセス履歴テーブル１１Ｂ４にレコードを追加する。
【０１２１】
また、ファイル管理部１１Ｂは、アクセス履歴格納部１２Ｃのｉ番目のファイル名がＦＮと一致しない場合には（Ｓ３０５の結果が「Ｎ」）、アクセス履歴テーブル１１Ｂ４に対するレコードの追加が完了したため、Ｓ３０６以降の処理を実行する。アクセス履歴格納部１２Ｃは、前述のように、ファイル名でソートされており、アクセス履歴はファイルごとに連続して格納される。したがって、アクセス履歴１２Ｃのｉ番目のファイル名がＦＮと一致しなくなった時点で、ＦＮのアクセス履歴に対応するレコードがアクセス履歴テーブル１１Ｂ４に生成されている。なお、この時点で、インデックスｊには、ＦＮのアクセス数＋１の値が格納されている。
【０１２２】
そして、ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４を集計する（Ｓ３０６）。アクセス履歴テーブル１１Ｂ４の集計とは、ＦＮに対する総アクセス数に占める各所属のアクセス数の割合を算出することである。
【０１２３】
ファイル管理部１１Ｂは、アクセス数が最も多い所属の割合が所定の値α（例えば８０％）を超えるか否かを判定する（Ｓ３０７）。アクセス数が最も多い所属の割合がαを超える場合には（Ｓ３０７の結果が「Ｙ」）、当該所属にとってＦＮの有用性が高いと判定されたため、組織情報格納部１２Ｄを参照し、この所属に対応するメタデータテーブル名１２Ｄ０４を取得し、ＴＮ２に格納する（Ｓ３０８）。
【０１２４】
一方、ファイル管理部１１Ｂは、アクセス数が最も多い所属の割合がαを超えない場合には（Ｓ３０７の結果が「Ｎ」）、ＦＮの有用性が高いと判定された部署が存在しなかったため、アクセス履歴テーブル１１Ｂ４に格納された所属の上位の所属で再度集計する。以下、上位の所属で再集計する処理について説明する。
【０１２５】
ファイル管理部１１Ｂは、まず、アクセス履歴テーブル１１Ｂ４のインデックスを示す変数ｋに１をセットして初期化する（Ｓ３０９）。
【０１２６】
次に、ファイル管理部１１Ｂは、アクセス履歴テーブル１１Ｂ４のｋ番目の所属１１Ｂ４０２をエントリ１１Ｂ４０１に複写する（Ｓ３１０）。ここで、ファイル管理部１１Ｂは、組織情報格納部１２Ｄを参照し、複写されたエントリに上位の所属が存在するか否かを判定する（Ｓ３１１）。上位の所属が存在する場合には（Ｓ３１１の結果が「Ｙ」）、アクセス履歴テーブル１１Ｂ４のｋ番目の所属１１Ｂ４０２に上位の所属をセットする（Ｓ３１２）。
【０１２７】
その後、ファイル管理部１１Ｂは、ｋの値に１を加算し（Ｓ３１３）、ｋの値がｊの値以上であるか否かを判定する（Ｓ３１４）。Ｓ３１４の処理では、変数ｊにファイルＦＮのアクセス数＋１の値が格納されているため、アクセス履歴テーブル１１Ｂ４に格納された所属を上位の所属にすべて更新したか否かを判定することができる。
【０１２８】
ファイル管理部１１Ｂは、ｋの値がｊの値よりも小さい場合には（Ｓ３１４の結果が「Ｎ」）、アクセス履歴テーブル１１Ｂ４の残りのレコードについてＳ３１０からＳ３１３までの処理を実行する。ｋの値がｊの値以上の場合には（Ｓ３１４の結果が「Ｙ」）、アクセス履歴テーブル１１Ｂ４のすべてのレコードの更新が完了したため、更新した所属で再度集計し（Ｓ３０６）、ファイルの有用性を判定する（Ｓ３０７）。
【０１２９】
なお、Ｓ３０８の処理にて、アクセス数の最も多い所属のメタデータテーブル名１２Ｄ０４をＴＮ２に格納しているが、ＴＮ２にセットするテーブル名は１つに限定する必要はない。ファイルをアクセスする利用者の利便性を考慮し、複数のテーブルにメタデータを配置することも可能である。以下、その一例について図２３を用いて説明する。
【０１３０】
あるファイルが主にＸ１課のメンバによってアクセスされていた状態（（Ａ）の状態）から、Ｘ３課のメンバによってもアクセスされる状態（（Ｂ）の状態）となったとする。このとき、通常の処理では、このファイルのメタデータは、Ｘ１課に対応するメタデータテーブルからＸ部に対応するメタデータテーブルに移動する（（Ｄ）の状態）。
【０１３１】
一方、メタデータを再配置する際に依然としてＸ１課からのアクセスも多い場合には、Ｘ１課に対応するテーブルに格納されているメタデータをそのまま残し、同時にＸ部に対応するメタデータテーブルにも同じメタデータを格納してもよい。具体的には、Ｓ３０８の処理において、アクセス数の最も多い所属に対応するメタデータテーブル名１２Ｄ０４及びＴＮ１をＴＮ２に格納すればよい。
【０１３２】
以上、フローチャートを用いて本発明の第１の実施の形態のファイル共有システムの処理手順について説明した。
【０１３３】
（ファイル検索におけるクライアント画面の一例）
ここで、ファイル検索処理Ｓ１０７を実行するための検索指示画面と、検索結果表示画面について説明する。検索指示画面及び検索結果表示画面は、クライアント３にて表示される。
【０１３４】
（ファイル検索におけるクライアント画面の一例：検索指示画面）
図２５は、第１の実施の形態のクライアント３に表示される検索指示画面の一例を示す図である。検索指示画面は、検索キー入力エリア４０１、検索範囲指定エリア４０２、検索指示ボタン４０３、終了指示ボタン４０４及び検索結果表示エリア４０５を含む。
【０１３５】
検索キー入力エリア４０１は、ファイルを検索するためのキーワードを入力する領域である。図２５には、検索キー入力エリア４０１に利用者がキーワードとして「Ａ社」及び「提案」と入力されている。
【０１３６】
検索範囲指定エリア４０２は、ファイルを検索する部署の範囲を指定する項目である。図２５には、検索対象の部署として「営業１課」及び「営業部」が指定されている。
【０１３７】
検索指示ボタン４０３は、利用者がファイル共有システムにファイルの検索の実行を指示する。終了指示ボタン４０４は、システムにファイル検索の終了を指示する。検索結果表示エリア４０５は、ファイルの検索結果を表示するエリアである。
【０１３８】
（ファイル検索におけるクライアント画面の一例：検索結果表示画面）
図２６は、図２５に示した検索条件にしたがって実行された検索結果を表示する画面の一例を示している。なお、画面の構成は、図２５と同じである。
【０１３９】
図２５で入力された検索条件は、検索指示ボタン４０３が押下されると、検索条件１３Ｃとしてネットワーク４を通じてファイルサーバ１のファイル検索部１１Ｃに送信される。ファイル検索部１１Ｃは、検索条件１３Ｃを受信すると、前述のようにファイル検索処理Ｓ１０７を実行し、表示用検索結果１３Ｆをクライアント３に送信する。クライアント３は、表示用検索結果１３Ｆを受信すると、図２６に示すように、抽出されたファイルのファイル名とその内容の一部を検索結果表示エリア４０５に表示する。
【０１４０】
（ファイル検索におけるクライアント画面の一例：部署指定一覧表示画面）
また、キーワードを指定せずに部署のみを指定してファイルを検索してもよい。部署のみを指定してファイルを検索することによって、部署ごとに有用性が高いと判定されたファイルの一覧を取得することができる。
【０１４１】
図２７は、部署指定一覧表示画面の一例である。部署指定一覧表示画面は、部署指定欄４０２、一覧表示ボタン４０６、終了指示ボタン４０４及び一覧表示部４０８を含む。なお、図２５と同じ符号が割り当てられている要素については、同じ機能を備えるものとし、説明を省略する。また、キーワードを入力せずに検索可能とすれば、図２５に示した検索指示画面を使用してもよい。
【０１４２】
一覧表示ボタン４０６は、指定された部署をファイルサーバ１に送信する。ファイルサーバ１は、検索条件１３Ｃとして部署を受信すると、検索コマンド１３Ｄを生成して検索処理を実行し、表示用検索結果１３Ｆをクライアント３に送信する。このとき、表示用検索結果１３Ｆは、部署ごとの一覧としてクライアント３に送信される。
【０１４３】
クライアント３は、表示用検索結果１３Ｆを受信すると、一覧表示部４０８に部署ごとに有用性が高いと判定されたファイルの一覧を表示する。図２７では、一覧表示部４０８は、ファイルの一覧を部署ごとに切替えて表示できるように構成されている。
【０１４４】
（第１の実施の形態の効果）
第１の実施の形態によれば、有用性が高いファイルと判定されたを部署と対応付けて管理することによって、検索精度の向上及び検索速度の高速化を図ることができる。
【０１４５】
第１の実施の形態では、ファイルのメタデータを利用し、有用性が高いと判定されたファイルのメタデータを部署と対応付けて管理する。したがって、ファイルそのものではなく、メタデータを検索対象とするため、検索速度を高速化することができる。
【０１４６】
さらに、第１の実施の形態によれば、ファイルの有用性に応じてメタデータを再配置する処理が周期的に実行されるため、管理者及び利用者がメタデータを再配置する必要が無く、メンテナンス性を向上させることができる。
【０１４７】
（第１の実施の形態の変形例）
第１の実施の形態では、ファイル共有機能の実装をＣＩＦＳプロトコル又はＳａｍｂａを利用する構成としたが、文書管理システムのファイル共有機能を利用してもよい。すなわち、文書管理システムにおける文書管理サーバをファイルサーバ１とし、さらに、文書格納部をファイル格納部１２Ａ、システムログをアクセスログ格納部１２Ｂ、ユーザ情報を組織情報１２Ｄ、文書登録部をファイル登録部１１Ａとすることによって、第１の実施の形態を実装できる。
【０１４８】
また、ＷＥＢサーバをファイルサーバ１とみなし、ＷＥＢシステムにおけるＷＥＢページ格納エリアをファイル格納部１２Ａ、ＷＥＢページに対するアクセスログをアクセスログ格納部１２Ｂとみなして本発明を実装することも可能である。
【０１４９】
（第２の実施の形態）
第２の実施の形態では、有用性が低いファイルのメタデータを各部署に対応させずに不要ファイルとして管理する。なお、第１の実施の形態と同様の機能を果たす構成には同一の符号を付して重複する説明を適宜省略する。
【０１５０】
第２の実施の形態のファイル共有システムの構成は、第１の実施の形態の構成と同じであり、それぞれ図１〜図２０に示した通りである。ただし、図２０のメタデータ格納部２２Ａには、各部署に対応するテーブルに加え、不要と判定されたファイルのメタデータを格納するテーブルを追加する。なお、不要と判定されたファイルのメタデータを格納するテーブルの構成は、各部署に対応するメタデータを格納するテーブルの構成と同じである。
【０１５１】
第２の実施の形態におけるファイル共有システムの処理手順は、Ｓ１０２のメタデータを再配置する処理を除いて、第１の実施の形態と同じである。したがって、システムに常駐して実行される処理は、図２１のフローチャートに示した手順と同じである。
【０１５２】
（第２の実施の形態のメタデータ再配置処理Ｓ１０２の詳細な処理手順）
図２８は、第２の実施の形態のメタデータ再配置処理Ｓ１０２の処理手順を示すフローチャートである。
【０１５３】
図２８に示すフローチャートのＳ２０１からＳ２１１までの処理は、図２２に示した第１の実施の形態のＳ２０１からＳ２１１の処理と同じである。すなわち、ファイル管理部１１Ｂは、まずアクセス履歴格納部１２Ｃをクリアしてアクセスログ格納部１２Ｂからアクセス履歴を抽出してアクセス履歴格納部１２Ｃに格納し（Ｓ２０１）、ファイル名でソートする（Ｓ２０２）。そして、アクセス履歴格納部１２Ｃの先頭レコードから順にファイルの有用性を判定し、メタデータを再配置する（Ｓ２０４〜Ｓ２１１）。なお、ファイルの有用性を判定する手順は、図２４のフローチャートに示した手順と同じである。
【０１５４】
ファイル管理部１１Ｂは、メタデータの再配置処理が完了すると、不要ファイルのメタデータを再配置する（Ｓ２１２）。なお、第２の実施の形態では、一定期間（例えば６ヶ月間）、利用者にアクセスされていないファイルを不要ファイルと判定する。そして、ファイル管理部１１Ｂは、該当するファイルのメタデータを不要ファイルのメタデータを格納するメタデータテーブルに移動させる。
【０１５５】
具体的には、まず、ファイル管理部１１Ｂは、ファイル格納部１２Ａを参照し、メタデータ配置日１２Ａ０４がγ（例えば６ヶ月前の日付）以前のレコードを抽出する。次に、ファイル管理部１１Ｂは、抽出されたレコードからファイル名とメタデータテーブル名を取得する。さらに、ファイル管理部１１Ｂは、取得したメタデータテーブル名から取得したファイル名をもとにメタデータを抽出する。そして、抽出したメタデータを不要ファイルのメタデータを格納するメタデータテーブルに移動させるメタデータ配置コマンド１３Ｂを作成し、メタデータサーバ２に送信する。
【０１５６】
（第２の実施の形態の効果）
第２の実施の形態によれば、一定期間、アクセスされていないファイルは有用性が低下したものとし、メタデータを不要データを格納するメタデータテーブルに移動させる。こうすることで、検索対象となるメタデータを有用性の高いファイルのメタデータに限定することができ、ファイルの検索精度の向上及び検索速度の高速化を図ることができる。
【０１５７】
また、第２の実施の形態の変形例として、不要と判定されたファイルのメタデータを移動させるのではなく、ファイルの登録者に削除を依頼するように通知してもよい。
【０１５８】
（第３の実施の形態）
他部署のファイルサーバに格納された有用なファイルは、メール又はインスタントメッセージなどの情報伝達ツールを利用して、間接的に取得される場合がある。例えば、他部署のファイルサーバに有用なファイルが格納されている場合、このファイルを利用しようとする者は他部署のメンバにファイルの送付を依頼することが考えられる。そこで、依頼を受けた他部署のメンバは、メールシステムの添付ファイル機能又はインスタントメッセージシステムのファイル転送機能を用いて依頼者にファイルを送付する。
【０１５９】
このような場合には、ファイルサーバにアクセスした者は、依頼を受けた他部署のメンバではなく、依頼者と考えるべきである。
【０１６０】
そこで、第３の実施の形態のファイル共有システムでは、メールシステムにおける添付ファイルの送信ログからもアクセス履歴を抽出する。
【０１６１】
（第３の実施の形態におけるシステム構成）
図２９は、第３の実施の形態のファイル共有システムの構成を示す図である。第３の実施の形態のファイル共有システムは、ファイルサーバ１、メタデータサーバ２、クライアント３、ネットワーク４及びメールサーバ５を含む。ファイルサーバ１、メタデータサーバ２、クライアント３及びネットワーク４は、第１の実施の形態と同じ構成である。
【０１６２】
メールサーバ５は、送信されたメールを受信し、メールのヘッダに記載されたあて先を参照してメールを送信する。また、クライアント３からメールを参照する指示があれば、クライアント３の利用者宛に送信されたメールをクライアント３に送信する。
【０１６３】
第３の実施の形態のメールサーバ５のハードウェア構成は、図２に示した構成と同一である。
【０１６４】
（第３の実施の形態におけるモジュール構成）
続いて、第３の実施の形態のファイル共有システムのモジュール構成を説明する。
【０１６５】
図３０は、第３の実施の形態のファイル共有システムのファイルサーバ１のモジュール構成図である。処理部（矩形）、データ格納部（ドラム形）及びテンポラリデータ部（テープ形）は、図３に示す第１の実施の形態のモジュール構成と同じである。ただし、第３の実施の形態では、ファイル管理部１１Ｂがクライアント３のメールログ格納部３２Ａを参照する点が相違する。他のモジュールについては、図５から図１８に示す構成と同じであり、説明を省略する。
【０１６６】
メタデータサーバ２のモジュール構成は、図１９に示す構成と同一であり、詳細な説明は省略する。また、メールサーバ５は、ＳＥＮＤＭＡＩＬ（登録商標）などの既存のソフトウェアを実装することによって構築可能であり、詳細な説明は省略する。
【０１６７】
クライアント３は、第１の実施の形態の構成に加え、メールシステムのクライアント機能を有する。
【０１６８】
図３１は、クライアント３のメールクライアント機能に関連するモジュール構成を示す図である。クライアント３のメールクライアント機能のモジュールは、メールクライアント部３１Ａ、メールログ格納部３２Ａ、メール３３Ａ及びファイル３３Ｂを含む。
【０１６９】
メールクライアント部３１Ａは、メールを送受信する。メールログ格納部３２Ａは、メールクライアント部３１Ａが実行した処理のログを格納する。メール３３Ａは、利用者が送受信したメールのデータである。ファイル３３Ｂは、利用者がメールを作成するときに添付したファイルのデータである。
【０１７０】
（第３の実施の形態におけるファイル共有システムの処理手順）
次に、第３の実施の形態のファイル共有システムの処理手順を説明する。第３の実施の形態の処理手順は、第１の実施の形態の処理手順と概ね同じである。ただし、メタデータ配置処理Ｓ１０２において、ファイルのアクセス履歴を抽出する処理Ｓ２０１が相違する。
【０１７１】
第３の実施の形態では、アクセスログ格納部１２Ｂからファイルに対するアクセス履歴を抽出するとともに、クライアント３のメールログ格納部３２Ａからメールログを取得する。メールログの内容からファイルサーバ１のファイル格納部１２Ａに格納されたファイルを添付ファイルとして送信した場合には、メールの受信者をファイルのアクセス者とする。そして、メールの受信者は、ファイルを送信したメールのヘッダ情報に含まれる宛先を参照することによって抽出される。
【０１７２】
なお、第３の実施の形態では、クライアント３からメールログを収集しているが、メールサーバ５でメールログを収集してもよい。
【０１７３】
（第３の実施の形態の効果）
第３の実施の形態によれば、メールシステムなどによる第三者を介したファイルアクセスをアクセス履歴に含むことによって、より実態に近いアクセス履歴を取得することができる。したがって、ファイルの有用性をより正確に判定することができ、ファイルの検索精度をさらに向上させることができる。
【０１７４】
（第３の実施の形態の変形例）
第３の実施の形態の変形例として、メールシステムの代わりにインスタントメッセージシステムに対して適用してもよい。この場合には、メールサーバ５の代わりにインスタントメッセージングサーバを使用する。アクセス履歴は、インスタントメッセージングサーバ上で収集してもよいし、クライアント３から収集してもよい。
【図面の簡単な説明】
【０１７５】
【図１】第１の実施の形態のファイル共有システムの構成を示す図である。
【図２】第１の実施の形態のファイルサーバ１、メタデータサーバ２及びクライアント３のハードウェア構成を示す図である。
【図３】第１の実施の形態のファイルサーバ１のモジュール構成を示す図である。
【図４】第１の実施の形態のファイルサーバ１のファイル管理部１１Ｂのモジュール構成を示す図である。
【図５】第１の実施の形態のアクセス履歴テーブルの構成を示す図である。
【図６】第１の実施の形態のファイル格納部の構成を示す図である。
【図７】第１の実施の形態のアクセスログ格納部の構成を示す図である。
【図８】第１の実施の形態のアクセス履歴格納部の構成を示す図である。
【図９】第１の実施の形態の組織情報格納部の構成を示す図である。
【図１０】第１の実施の形態の登録ファイルの一例を示す図である。
【図１１】第１の実施の形態のメタデータ配置コマンド（登録）の一例を示す図である。
【図１２】第１の実施の形態のメタデータ配置コマンド（移動）の一例を示す図である。
【図１３】第１の実施の形態の検索条件の一例を示す図である。
【図１４】第１の実施の形態の検索コマンドの一例を示す図である。
【図１５】第１の実施の形態の検索結果の一例を示す図である。
【図１６】第１の実施の形態の表示用検索結果の一例を示す図である。
【図１７】第１の実施の形態のファイル名の一例を示す図である。
【図１８】第１の実施の形態のファイルの一例を示す図である。
【図１９】第１の実施の形態のメタデータサーバ２のモジュール構成を示す図である。
【図２０】第１の実施の形態のメタデータ格納部の構成を示す図である。
【図２１】第１の実施の形態のファイル共有システムの処理手順を示すフローチャートである。
【図２２】第１の実施の形態のメタデータ再配置処理の手順を示すフローチャートである。
【図２３】第１の実施の形態のファイルのアクセス頻度とファイルが有用である部署との関係を説明する図である。
【図２４】第１の実施の形態のファイル有用性判定処理の手順を示すフローチャートである。
【図２５】第１の実施の形態のファイル検索指示画面の画面の一例である。
【図２６】第１の実施の形態のファイルの検索結果を表示する画面の一例である。
【図２７】第１の実施の形態の部署ごとの有用なファイルの一覧を表示する画面の一例である。
【図２８】第２の実施の形態のメタデータ再配置処理の手順を示すフローチャートである。
【図２９】第３の実施の形態のファイル共有システムの構成を示す図である。
【図３０】第３の実施の形態のファイルサーバのモジュール構成を示す図である。
【図３１】第３の実施の形態のクライアントのモジュール構成を示す図である。
【符号の説明】
【０１７６】
１ ファイルサーバ
２ メタデータサーバ
３ クライアント
４ ネットワーク
５ メールサーバ
１０ ＣＰＵ
１５ ネットワークインターフェイス
２０ ハードディスク
３０ メモリ
４０ ディスプレイ
４１ ディスプレイ制御部
５０ キーボード
５１ キーボード制御部
６０ マウス
６１ マウス制御部
７０ バス
１１Ａ ファイル登録部
１１Ｂ ファイル管理部
１１Ｃ ファイル検索部
１２Ａ ファイル格納部
１２Ｂ アクセスログ格納部
１２Ｃ アクセス履歴格納部
１２Ｄ 組織情報格納部
１３Ａ 登録ファイル
１３Ｂ メタデータ配置コマンド
１３Ｃ 検索条件
１３Ｄ 検索コマンド
１３Ｅ 検索結果
１３Ｆ 表示用検索結果
１３Ｇ ファイル名
１３Ｈ ファイル
２１Ａ メタデータ登録部
２１Ｂ メタデータ管理部
２１Ｃ メタデータ検索部
２２Ａ メタデータ格納部
１１Ｂ１ アクセス履歴抽出部
１１Ｂ２ ファイル有用性判定部
１１Ｂ３ メタデータ配置部
１１Ｂ４ アクセス履歴テーブル
【特許請求の範囲】
【請求項１】
ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムであって、
前記ファイルサーバは、前記ネットワークと接続する第１インターフェイスと、前記第１インターフェイスと接続され、プログラムを実行する第１プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第１メモリと、前記ファイルを格納する第１ストレージ装置と、を備え、
前記第１メモリは、組織を構成する部署を記録した組織情報を格納し、
前記第１プロセッサは、
前記ファイルのアクセス履歴を記録し、
前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、
前記有用性が高いと判定されたファイルを検索することを特徴とするファイル管理システム。
【請求項２】
前記ファイルのメタデータを格納するメタデータサーバを、さらに備え、
前記メタデータサーバは、前記ネットワークと接続する第２インターフェイスと、前記第２インターフェイスと接続され、プログラムを実行する第２プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第２メモリと、前記メタデータを格納する第２ストレージ装置と、を備え、
前記第２プロセッサは、前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署との対応を前記第２ストレージ装置に記録することを特徴とする請求項１に記載のファイル管理システム。
【請求項３】
前記ファイルは、ファイルの有用性が高いと判定される部署が存在しないとき、不要ファイルとして管理されることを特徴とする請求項２に記載のファイル管理システム。
【請求項４】
前記第１プロセッサは、前記ファイルの有用性が高いと判定される部署が存在しないとき、前記ファイルサーバから前記ファイルの削除の依頼を通知することを特徴とする請求項３に記載のファイル管理システム。
【請求項５】
前記第１プロセッサは、周期的に前記ファイルの有用性を判定することを特徴とする請求項１に記載のファイル管理システム。
【請求項６】
検索条件として部署の指定を受け付け、前記指定された部署にとって有用性が高いと判定されたファイルを検索することを特徴とする請求項１に記載のファイル管理システム。
【請求項７】
前記有用性が高いと判定されたファイルを前記部署ごとに表示することを特徴とする請求項１に記載のファイル管理システム。
【請求項８】
メールシステム又はインスタントメッセージシステムをさらに備え、
前記メールシステム又はインスタントメッセージシステムによってファイルサーバに格納されたファイルが送信されたとき、前記送信されたファイルは、受信した者によってアクセスされたものとしてアクセス履歴が記録されることを特徴とする請求項１に記載のファイル管理システム。
【請求項９】
前記第１プロセッサは、前記ファイルごとの特定の部署からのアクセス数の当該ファイルの総アクセス数に対する比率が所定の値よりも大きいとき、前記特定の部署を前記アクセス数の多い部署と判定することを特徴とする請求項１に記載のファイル管理システム。
【請求項１０】
ファイルサーバに格納されたファイルを管理するプログラムであって、
クライアントからのアクセス履歴を記録する手順と、
組織情報に格納された部署ごとに前記アクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定する手順と、
前記有用性が高いと判定されたファイルを検索する手順とを計算機に実行させることを特徴とするファイル管理プログラム。
【請求項１１】
前記ファイルに関する情報を記述したメタデータを格納する手順と、
前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署とを対応付ける手順とを、さらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１２】
有用性が高いと判定される部署が存在しないファイルを、不要ファイルとして管理する手順を、さらに計算機に実行させることを特徴とする請求項１１に記載のファイル管理プログラム。
【請求項１３】
有用性が高いと判定される部署が存在しないファイルを、前記ファイルサーバから削除するように通知する手順を、さらに計算機に実行させることを特徴とする請求項１２に記載のファイル管理プログラム。
【請求項１４】
前記ファイルの有用性を判定する手順を周期的に計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１５】
検索条件として前記部署の指定を受け付け、前記指定された部署について有用性が高いと判定されたファイルを検索する手順を、さらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１６】
前記有用性が高いと判定されたファイルを前記部署ごとに表示する手順をさらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１７】
前記アクセス履歴を記録する手順は、メールシステム又はインスタントメッセージシステムによって前記ファイルが送信されたとき、受信側で前記ファイルをアクセスしたものとしてアクセス履歴を記録することを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１８】
前記ファイルの有用性を判定する手順は、前記ファイルごとの特定の部署からのアクセス数の当該ファイルの総アクセス数に対する比率が所定の値よりも大きいとき、前記特定の部署を前記アクセス数の多い部署と判定することを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１９】
ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムにおけるファイル管理方法であって、
組織を構成する部署を記録した組織情報を格納し、
前記ファイルのアクセス履歴を記録し、
前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、
前記有用性が高いと判定されたファイルを検索することを特徴とするファイル管理方法。
【請求項２０】
前記ファイル管理システムは、前記ファイルに関する情報を記述したメタデータを格納するメタデータサーバをさらに備え、
前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署とを対応付けることを特徴とする請求項１９に記載のファイル管理方法。
【請求項１】
ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムであって、
前記ファイルサーバは、前記ネットワークと接続する第１インターフェイスと、前記第１インターフェイスと接続され、プログラムを実行する第１プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第１メモリと、前記ファイルを格納する第１ストレージ装置と、を備え、
前記第１メモリは、組織を構成する部署を記録した組織情報を格納し、
前記第１プロセッサは、
前記ファイルのアクセス履歴を記録し、
前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、
前記有用性が高いと判定されたファイルを検索することを特徴とするファイル管理システム。
【請求項２】
前記ファイルのメタデータを格納するメタデータサーバを、さらに備え、
前記メタデータサーバは、前記ネットワークと接続する第２インターフェイスと、前記第２インターフェイスと接続され、プログラムを実行する第２プロセッサと、前記プログラム及び前記プログラムが使用する情報を格納する第２メモリと、前記メタデータを格納する第２ストレージ装置と、を備え、
前記第２プロセッサは、前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署との対応を前記第２ストレージ装置に記録することを特徴とする請求項１に記載のファイル管理システム。
【請求項３】
前記ファイルは、ファイルの有用性が高いと判定される部署が存在しないとき、不要ファイルとして管理されることを特徴とする請求項２に記載のファイル管理システム。
【請求項４】
前記第１プロセッサは、前記ファイルの有用性が高いと判定される部署が存在しないとき、前記ファイルサーバから前記ファイルの削除の依頼を通知することを特徴とする請求項３に記載のファイル管理システム。
【請求項５】
前記第１プロセッサは、周期的に前記ファイルの有用性を判定することを特徴とする請求項１に記載のファイル管理システム。
【請求項６】
検索条件として部署の指定を受け付け、前記指定された部署にとって有用性が高いと判定されたファイルを検索することを特徴とする請求項１に記載のファイル管理システム。
【請求項７】
前記有用性が高いと判定されたファイルを前記部署ごとに表示することを特徴とする請求項１に記載のファイル管理システム。
【請求項８】
メールシステム又はインスタントメッセージシステムをさらに備え、
前記メールシステム又はインスタントメッセージシステムによってファイルサーバに格納されたファイルが送信されたとき、前記送信されたファイルは、受信した者によってアクセスされたものとしてアクセス履歴が記録されることを特徴とする請求項１に記載のファイル管理システム。
【請求項９】
前記第１プロセッサは、前記ファイルごとの特定の部署からのアクセス数の当該ファイルの総アクセス数に対する比率が所定の値よりも大きいとき、前記特定の部署を前記アクセス数の多い部署と判定することを特徴とする請求項１に記載のファイル管理システム。
【請求項１０】
ファイルサーバに格納されたファイルを管理するプログラムであって、
クライアントからのアクセス履歴を記録する手順と、
組織情報に格納された部署ごとに前記アクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定する手順と、
前記有用性が高いと判定されたファイルを検索する手順とを計算機に実行させることを特徴とするファイル管理プログラム。
【請求項１１】
前記ファイルに関する情報を記述したメタデータを格納する手順と、
前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署とを対応付ける手順とを、さらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１２】
有用性が高いと判定される部署が存在しないファイルを、不要ファイルとして管理する手順を、さらに計算機に実行させることを特徴とする請求項１１に記載のファイル管理プログラム。
【請求項１３】
有用性が高いと判定される部署が存在しないファイルを、前記ファイルサーバから削除するように通知する手順を、さらに計算機に実行させることを特徴とする請求項１２に記載のファイル管理プログラム。
【請求項１４】
前記ファイルの有用性を判定する手順を周期的に計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１５】
検索条件として前記部署の指定を受け付け、前記指定された部署について有用性が高いと判定されたファイルを検索する手順を、さらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１６】
前記有用性が高いと判定されたファイルを前記部署ごとに表示する手順をさらに計算機に実行させることを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１７】
前記アクセス履歴を記録する手順は、メールシステム又はインスタントメッセージシステムによって前記ファイルが送信されたとき、受信側で前記ファイルをアクセスしたものとしてアクセス履歴を記録することを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１８】
前記ファイルの有用性を判定する手順は、前記ファイルごとの特定の部署からのアクセス数の当該ファイルの総アクセス数に対する比率が所定の値よりも大きいとき、前記特定の部署を前記アクセス数の多い部署と判定することを特徴とする請求項１０に記載のファイル管理プログラム。
【請求項１９】
ファイルを格納し、クライアントからの要求に応じ、ネットワークを通じて前記ファイルを提供するファイルサーバを備えるファイル管理システムにおけるファイル管理方法であって、
組織を構成する部署を記録した組織情報を格納し、
前記ファイルのアクセス履歴を記録し、
前記組織情報に格納された部署ごとのアクセス履歴を集計し、アクセス数の多い部署について前記ファイルの有用性が高いと判定し、
前記有用性が高いと判定されたファイルを検索することを特徴とするファイル管理方法。
【請求項２０】
前記ファイル管理システムは、前記ファイルに関する情報を記述したメタデータを格納するメタデータサーバをさらに備え、
前記有用性が高いと判定されたファイルのメタデータと、前記アクセス数の多い部署とを対応付けることを特徴とする請求項１９に記載のファイル管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２００７−２９３７４６（Ｐ２００７−２９３７４６Ａ）
【公開日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願番号】特願２００６−１２３１９３（Ｐ２００６−１２３１９３）
【出願日】平成１８年４月２７日（２００６．４．２７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願日】平成１８年４月２７日（２００６．４．２７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]