(57)【要約】【課題】ファイルサーバの台数を削減すると共に、ファイルサーバの運用支援を行うための管理用コンピュータの導入を必要最小限にするための技術を提供する。【解決手段】本発明では、業務文書処理装置は、クローリング処理を実行する際に、ファイルサーバが有する１つのフォルダに含まれる複数のファイルのうち、ファイルサイズが所定の閾値以上のサイズを有するファイルについてのみ属性情報を取得する。そして、当該装置は、入力されたサーチ条件に基づいて、所定の閾値以上のファイルサイズを有するファイルの属性情報をサーチし、サーチ条件に合致するファイルの情報を、ユーザが所望のファイルを削除可能なように出力する。【選択図】図１
2015087942.tif 000002
【特許請求の範囲】
【請求項１】
ファイルサーバに存在する複数のファイルの集計結果を表示する業務文書処理装置であって、
前記ファイルサーバに存在する前記複数のファイルについてクローリング処理を実行し、ファイルの属性情報を取得するプロセッサと、
前記プロセッサが取得した前記ファイルの属性情報を保持するメモリと、を有し、
前記プロセッサは、
前記クローリング処理において、前記ファイルサーバが有する１つのフォルダに含まれる複数のファイルのうち、ファイルサイズが所定の閾値以上のサイズを有するファイルについてのみ前記属性情報を取得し、前記メモリに格納する第１の処理を実行し、
入力されたサーチ条件に基づいて、前記メモリに保持された、前記所定の閾値以上のファイルサイズを有するファイルの前記属性情報をサーチし、前記サーチ条件に合致するファイルの情報を、ユーザが所望のファイルを削除可能なように出力する第２の処理を実行することを特徴とする業務文書処理装置。
【請求項２】
請求項１において、
前記プロセッサは、前記１つのフォルダがサブフォルダを有する場合、当該サブフォルダの直下に含まれるファイルについて、前記第１の処理を実行することを特徴とする業務文書処理装置。
【請求項３】
請求項１において、
前記プロセッサは、前記１つのフォルダに含まれる複数のファイルに対して、前記クローリング処理を再度実行し、前記所定の閾値以上のファイルサイズを有するファイルについてのみ前記属性情報を再度取得し、前記メモリに保持される属性情報を更新する第３の処理を実行することを特徴とする業務文書処理装置。
【請求項４】
請求項１において、
前記プロセッサは、前記第２の処理において、
前記サーチ条件に合致するファイルの集計結果を、複数の要素に分類して表示画面に表示する処理と、
前記複数の要素の１つが指定された場合に、（i）当該指定された要素に対応するファイルの詳細情報と、（ii）個々のファイルの削除を指定するための第１の表示と、前記指定された要素に対応するファイルが属する個々のフォルダの削除を指定するための第２の表示と、前記指定された要素に対応するファイルが属する個々のフォルダに含まれるファイルの情報を表示させるための第３の表示と、を前記表示画面に表示させる処理と、
を実行することを特徴とする業務文書処理装置。
【請求項５】
請求項４において、
前記プロセッサは、ユーザによって前記第３の表示が選択された場合、前記選択されたフォルダに含まれる全てのファイルの情報と、前記選択されたフォルダに含まれる個々のファイルの削除を指定するための表示と、前記選択されたフォルダ自体の削除を指定するための表示と、を前記表示画面に表示させる処理を実行することを特徴とする業務文書処理装置。
【請求項６】
請求項４において、
前記サーチ条件は、ファイルサイズ、最終更新日、最終アクセス日、ファイル所有者、又は、ファイル拡張子であることを特徴とする業務文書処理装置。
【請求項７】
業務文書処理装置を用いて、ファイルサーバに存在する複数のファイルの集計結果を表示する業務文書処理方法であって、
前記業務文書処理装置は、前記ファイルサーバに存在する前記複数のファイルについてクローリング処理を実行し、ファイルの属性情報を取得するプロセッサと、前記プロセッサが取得した前記ファイルの属性情報を保持するメモリと、を有し、
前記業務文書処理方法は、
前記プロセッサが、前記クローリング処理において、前記ファイルサーバが有する１つのフォルダに含まれる複数のファイルのうち、ファイルサイズが所定の閾値以上のサイズを有するファイルについてのみ前記属性情報を取得し、前記メモリに格納する第１の処理を実行するステップと、
前記プロセッサが、入力されたサーチ条件に基づいて、前記メモリに保持された、前記所定の閾値以上のファイルサイズを有するファイルの前記属性情報をサーチし、前記サーチ条件に合致するファイルの情報を、ユーザが所望のファイルを削除可能なように出力する第２の処理を実行するステップと、
を有することを特徴とする業務文書処理方法。
【請求項８】
請求項７において、さらに、
前記プロセッサが、前記１つのフォルダがサブフォルダを有する場合、当該サブフォルダの直下に含まれるファイルについて、前記第１の処理を実行するステップを含むことを特徴とする業務文書処理方法。
【請求項９】
請求項７において、さらに、
前記プロセッサが、前記１つのフォルダに含まれる複数のファイルに対して、前記クローリング処理を再度実行し、前記所定の閾値以上のファイルサイズを有するファイルについてのみ前記属性情報を再度取得し、前記メモリに保持される属性情報を更新する第３の処理を実行するステップを含むことを特徴とする業務文書処理方法。
【請求項１０】
請求項７において、
前記第２の処理は、
前記プロセッサが、前記サーチ条件に合致するファイルの集計結果を、複数の要素に分類して表示画面に表示する処理を実行するステップと、
前記プロセッサが、前記複数の要素の１つが指定された場合に、（i）当該指定された要素に対応するファイルの詳細情報と、（ii）個々のファイルの削除を指定するための第１の表示と、前記指定された要素に対応するファイルが属する個々のフォルダの削除を指定するための第２の表示と、前記指定された要素に対応するファイルが属する個々のフォルダに含まれるファイルの情報を表示させるための第３の表示と、を前記表示画面に表示させる処理と、
を実行するステップと、
を含むことを特徴とする業務文書処理方法。
【請求項１１】
請求項１０において、さらに、
ユーザによって前記第３の表示が選択された場合、前記プロセッサが、前記選択されたフォルダに含まれる全てのファイルの情報と、前記選択されたフォルダに含まれる個々のファイルの削除を指定するための表示と、前記選択されたフォルダ自体の削除を指定するための表示と、を前記表示画面に表示させる処理を実行するステップを含むことを特徴とする業務文書処理方法。
【請求項１２】
請求項１０において、
前記サーチ条件は、ファイルサイズ、最終更新日、最終アクセス日、ファイル所有者、又は、ファイル拡張子であることを特徴とする業務文書処理方法。
【請求項１３】
コンピュータを請求項１に記載の業務文書処理装置として機能させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体。
【請求項１４】
コンピュータを請求項１に記載の業務文書処理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務文書処理装置、業務文書処理方法、プログラム、及びコンピュータ読み取り可能な記憶媒体に関し、例えば、大量の文書を効率的に管理するための技術に関する。
【背景技術】
【０００２】
近年、組織内のファイルサーバは、電子データの保存・共有のための利便性が高くなっており、広く普及してきている。また、ファイルサーバの利用が進み、多くのファイルが保存されるようになったことに伴い、その運用を支援するための技術が提案されている（以下では「運用支援システム」と呼ぶ）。
【０００３】
例えば、非特許文献１においては、ファイルサーバに保存されているファイルの種類・サイズ・最終更新年月日・所有者などをグラフ表示することで、ユーザによるファイルサーバの利用状況の把握を支援するとともに、不要なファイルの削除を支援する機能を有する。また、非特許文献１では、ファイルサーバに保存されているファイル群についてあらかじめ属性情報を収集し、その内容を運用支援システムに保持しておくことで運用支援の機能を実現している。
【０００４】
なお、例えば、ファイルの属性情報は、非特許文献２に示すリレーショナルデータベースや非特許文献３に示す分散型データベースに保存しておくことが可能である。いずれの技術においても、保存するデータの件数（ファイル数）が増加した場合には、複数台のコンピュータにデータを分散配置することで、１台のコンピュータに対する負荷が高くなるという課題に対応することになる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】MEANS ファイルサーバスリム化ソリューション  ［平成２５年１０月１０日検索］  インターネット＜URL：http://www.hitachi-solutions.co.jp/means/sp/products/＞
【非特許文献２】パーティショニング：用途と利点−Let’s Postgres  ［平成２５年１０月１０日検索］  インターネット＜URL：http://lets.postgresql.jp/documents/technical/partitioning/1＞
【非特許文献３】HBaseとはどんなNoSQLデータベースなのか？  ［平成２５年１０月１０日検索］  インターネット＜URL：http://www.publickey1.jp/blog/10/hbasenosql.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述の非特許文献１乃至３による技術を用いた場合、ファイルサーバの運用支援を行うコンピュータ（メタデータを保持する管理用コンピュータ：業務文書処理装置）の台数が、削減可能なファイルサーバの台数と比べて多くなってしまうという状況に陥る危険性がある。これでは、ファイルサーバの運用支援を行うシステムによりユーザに不要なファイルを削除させ、ファイルサーバの必要台数を削減することはできてもトータルのコンピュータ台数を削減することはできない。つまり、そのような管理用コンピュータの購入及び運用コストが嵩んでしまうという新たな課題が発生してしまう。
【０００７】
本発明はこのような状況に鑑みてなされたものであり、ファイルサーバの台数を削減すると共に、ファイルサーバの運用支援を行うための管理用コンピュータの導入を必要最小限にするための技術を提供するものである。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明では、業務文書処理装置が、クローリング処理を実行する際に、ファイルサーバが有する１つのフォルダに含まれる複数のファイルのうち、ファイルサイズが所定の閾値以上のサイズを有するファイルについてのみ属性情報を取得する。そして、当該装置は、入力されたサーチ条件に基づいて、所定の閾値以上のファイルサイズを有するファイルの属性情報をサーチし、サーチ条件に合致するファイルの情報を、ユーザが所望のファイルを削除可能なように出力する。
【０００９】
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本発明の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。
【００１０】
本明細書の記述は典型的な例示に過ぎず、本発明の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。
【発明の効果】
【００１１】
本発明によれば、大量のファイルが保存されたファイルサーバにおいて、より効率的にファイルの属性情報を管理し、不要なファイルの削除を支援することができるようになる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態による業務文書処理装置の概略構成例を示す機能ブロック図である。
【図２】ファイルデータのデータ構造例を示す図である。
【図３】各種インデクスデータの構造例を示す図である。
【図４】本発明の実施形態による業務文書処理装置において実行される処理全体を説明するためのフローチャートである。
【図５】初期クローリング処理の詳細を説明するためのフローチャートである。
【図６】差分クローリング処理の詳細を説明するためのフローチャートである。
【図７】サイズ別グラフ表示処理により生成される画面例を示す図である。
【図８】最終更新日別グラフ表示処理により生成される画面例を示す図である。
【図９】最終アクセス日別グラフ表示処理により生成される画面例を示す図である。
【図１０】所有者別グラフ表示処理による生成される画面例を示す図である。
【図１１】拡張子別グラフ表示処理により生成される画面例を示す図である。
【図１２】個別ファイル表示処理により生成される画面例を示す図である。
【図１３】フォルダ削除処理により生成される画面例を示す図である。
【発明を実施するための形態】
【００１３】
以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【００１４】
本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。
【００１５】
更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。
【００１６】
なお、以後の説明では「テーブル」形式によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。
【００１７】
以下では、初期クローリング処理部やインデクシング処理部等の「各処理部」を主語（動作主体）として本発明の実施形態における各処理について説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサ（中央処理装置）を主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００１８】
＜不要ファイル削除に関する知見＞
発明者は、ファイルサーバに保存されているファイルの統計的傾向、不要なファイルの削除におけるユーザ行動、およびファイルサーバの管理者が不要なファイルの削除に際しユーザに期待する行動について調査を行った結果、下記の４つの新規な知見を得るに至った。
【００１９】
（１）知見１
ファイルサーバに保存されているファイルのサイズは均一ではなく、少数の大容量ファイルが多くの容量割合を占めている。
【００２０】
ファイルサーバに保存されているファイルのサイズが様々であることは自明である。テキスト情報しか持たないファイルであれば、小さいサイズのものは１キロバイトにも満たない。逆に、画像を多く貼りこんだプレゼンテーションファイルであれば、近年では１メガバイトを超えるものも珍しくない。また、コンピュータの処理能力の向上に伴い、ユーザが快適に作成・閲覧できるファイルの最大サイズは徐々に増加している。ファイルサーバには過去から現在に至るファイルが保存されていることから、小さいサイズのファイルの方が多く存在するであろうことは容易に想像できる。しかし、実際にファイルを収集してサイズを調査すると、その分布の偏りは予想をはるかにしのぐものであり、非常に少数の割合の非常に巨大なファイルが存在し、それ以外の大多数のファイルのサイズは相対的に無視できるほど小さいという状況が観察された。一般に「パレートの法則」「８０：２０の法則」と言われる経験則があり、「売上の８０％は、２０％の顧客から得られる」「売り上げの８０％は、２０％の商品銘柄から得られる」「社会全体の所得の８０％は、２０％の高額所得者が得ている」「不良全体の８０％は、２０％の原因に由来する」ということが知られている。しかし、ファイルサーバに関しては偏在の度合いははるかに強く、ファイルサイズが５０ＫＢよりも大きいファイルは、全体容量の９５％以上を占有するが、ファイル数では全体の１０％に過ぎない場合さえあった。
【００２１】
とすれば、ファイル管理用コンピュータが保持しなければならないファイル数或いはその属性情報量が従来の１／１０になったとしても管理可能であるということになる。つまり、ファイル用管理コンピュータが保持すべき情報量を１／１０にすれば、容量削減効果は１０倍になる。
【００２２】
（２）知見２
ユーザのファイルサーバ使用容量と、ファイルサーバに保存しているファイル数とは、線形関係にある。
【００２３】
ユーザごとに、ファイルサーバの使用容量やファイルサーバに保存しているファイルの数が様々であることは自明である。一方、ファイルの平均サイズについてユーザごとのばらつきがあるのかどうかは一般には分からないと想像される。
【００２４】
しかし、実際にファイルごとに所有者であるユーザを調べ、各ユーザについて縦軸に「そのユーザが所有するファイルの容量和（そのユーザが使用している容量）」、横軸に「そのユーザが保存しているファイルの数」をプロットすると、線形関係を示した。このことは、大容量を占有しているユーザは「少数の大容量ファイル」だけを保存しているのではなく、ほとんど容量を使用していないユーザと平均ファイルサイズにおいてはあまり変わりがないことを意味している。
【００２５】
例えば、ユーザＡのファイルに関する使用容量がユーザＢのそれの１０倍であったとすると、ユーザＡが所有するファイル数もユーザＢのそれの１０倍程度であったことが分かった。従って、ユーザＡとユーザＢとでは、１ファイルあたりの平均ファイルサイズはほぼ同じであることが分かった。
【００２６】
（３）知見３
不要なファイルの削除を支援するシステムでは、ファイルの属性情報の表示を行うに際し、中立的に情報を表示しているのではなく「不要（または不要である可能性が高い）と思われるファイル群が占有している（大きな）容量」を明示している。例えば、ファイルの最終アクセス日の年ごとに容量合計を表示する場合、ファイルサーバの管理者の要望としては、「２０１３年にアクセスが行われたファイルの容量合計は、全容量の何割か」を具体的に示したいというよりは、「もう何年間もアクセスが全く行われていないファイルが（大きな）容量を占有している」ことを明示し、該当ファイルの削除を促したいということが考えられる。
【００２７】
（４）知見４
ユーザは不要なファイルの削除を行う際、フォルダ単位で削除を行う場合が多い。ファイルサーバでは、サーバ内に様々なファイルが数多く保存されるため、フォルダの分類ルールの周知徹底が時間の経過とともに徹底されなくなっていってしまう場合があることは想像に難くない。また、複数ユーザで共有されるファイルが保存されている。したがって、単一のユーザでは削除可否を判断できないファイルが存在することも考えられる。
【００２８】
しかし、実際にファイルサーバにおけるユーザのファイル削除行動を調査すると、ファイルサーバのフォルダツリーは局所的には管理体系が保たれて「同時に作成・参照・編集されるファイルは近傍にまとめて保存される」状態が維持されている場合が多いことが分かった。また、そのような局所的フォルダツリーは単一ユーザによって管理されている場合が多いことも分かった。したがって、不要なファイルの削除が行われる際には、該当のフォルダのサブツリーが丸ごと削除される場合が多いことが分かった。
【００２９】
＜上記知見に基づく本発明の機能＞
上記の知見から、発明者は、上述の課題を解決するための手段として、下記の４つの機能を提案する。
【００３０】
（１）機能１
本発明では、予め定めた閾値よりも大きいファイルサイズを持つファイルのみ、属性情報を保持する。つまり、小さいサイズのファイルの属性情報を保持する必要はない。
【００３１】
上記の知見１から、ファイルサーバの使用容量増大を防ぐためにファイルを削除するのであれば、サイズが大きいファイルのみを削除可否の確認対象とし、属性情報の保持を行えば十分効果が得られること（逆に、サイズが小さいファイルをどんなに削除しても、削除可否確認の手間・工数が増大するばかりで、ファイルサーバの容量確保は遅々として進まないこと。例えば先ほどの「ファイルサイズが50KBよりも大きいファイルが、全体容量の９５％を占めるが、ファイル数では全体の１０％に過ぎない」場合では、ファイル数で９０％を占めるサイズの小さなファイルについて属性情報を保持し、仮にそれらがすべて削除可能であったとしても、全体容量の５％しか削減できないこと）が分かる。
【００３２】
（２）機能２
本発明では、予め定めた閾値よりも大きいファイルサイズを持つファイルのみについての属性情報の集計結果をグラフ表示する。
【００３３】
上記の知見２から、「ユーザごとに、所有するファイルのサイズ和」をグラフ表示する場合、サイズが閾値以上のファイルのみについてサイズ和を集計しても、全てのファイルを対象にサイズ和を集計した場合と同じ傾向が得られることが分かる。したがって、大容量を占有しているユーザに対して所有ファイルのうち不用なものの削除を促す場合、閾値以上のファイルのみについての集計結果の表示を行えば十分効果が得られることが分かる。
【００３４】
（３）機能３
本発明では、予め定めた閾値よりも大きいファイルサイズを持つファイルについて、属性情報による検索結果を列挙表示し、ユーザによる削除指定を受け付ける。
【００３５】
ファイルの属性情報のうち、最終更新日、最終アクセス日、拡張子などについては、その属性の値によって平均ファイルサイズにばらつきが存在しないことは確認されていない。
【００３６】
しかし、上記の知見１から「もし特定の属性情報の値を持つファイルの容量和が大きい場合、その属性情報の値を持つ、サイズが大きいファイルが、容量和の大きな割合を占める」ことが分かる。このことと、上記の知見３から、不要なファイルの削除を支援する目的においては、不要（または不要である可能性が高い）と思われる属性情報を持ち、サイズが大きいファイルを表示し削除の指定を受け付けることで十分効果が得られることが分かる。
【００３７】
（４）機能４
本発明では、予め定めた閾値よりも大きいファイルサイズを持つファイルについて、属性情報による検索結果を列挙表示し、ファイルが保存されているフォルダの表示および削除についてユーザによる指定を受け付ける。
【００３８】
上記の知見４から、不要なファイルの削除を支援する目的においては、不要（または不要である可能性が高い）と思われる属性情報を持つファイルについて、そのファイルが保存されているフォルダの削除可否を確認するための手段および、削除を行うための手段の効果が高いことが分かる。
【００３９】
＜システム構成＞
図１は、本発明の実施形態による業務文書処理システムの概略構成を示す機能ブロック図である。業務文書処理システム１において、ファイルサーバ１０６以外の構成が、上述のファイル管理用コンピュータに相当するものである。
【００４０】
業務文書処理装置１は、データを表示するための表示装置１００と、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード１０１と、マウスなどのポインティングデバイス１０２と、必要な演算処理や制御処理などを行う中央処理装置１０３と、中央処理装置１０３での処理に必要なプログラムを格納するプログラムメモリ１０４と、中央処理装置１０３での処理に必要なデータを格納するデータメモリ１０５と、ファイルサーバ１０６と、ファイル属性情報DB１０７と、を備えている。
【００４１】
中央処理装置１０３は、初期クローリング処理部１０８と、インデクシング処理部１０９と、差分クローリング処理部１１０と、サーチ処理部１１１とを備えている。本発明の実施形態の場合、業務文書処理システムはコンピュータによって構成されるため、初期クローリング処理部１０８と、インデクシング処理部１０９と、差分クローリング処理部１１０と、サーチ処理部１１１は、いずれもコンピュータ上で実行されるプログラムの機能の一部として実現される。なお、これらのプログラムは、プログラムメモリ１０４に格納されている。
【００４２】
サーチ処理部１１１は、グラフ表示処理部１１２と、個別ファイル表示処理部１１３と、フォルダ削除処理部１１４と、を有している。
【００４３】
グラフ表示処理部１１２は、サイズ別グラフ表示処理部１１５と、最終更新日別グラフ表示処理部１１６と、最終アクセス日別グラフ表示処理部１１７と、所有者別グラフ表示処理部１１８と、拡張子別グラフ表示処理部１１９と、を有している。
【００４４】
初期クローリング処理部１０８および差分クローリング処理部１１０は、上記機能１を実現するものであり、グラフ表示処理部１１２は上記機能２を実現するものである。さらに、個別ファイル表示処理部１１３は上記機能３を実現するものであり、フォルダ削除処理部１１４は上記機能４を実現するものである。
【００４５】
データメモリ１０５は、サイズ閾値１２０と、ファイル属性情報１２１と、最終更新日別インデクス１２２と、最終アクセス日別インデクス１２３と、サイズ別インデクス１２４と、所有者別インデクス１２５と、拡張子別インデクス１２６と、設定ファイル１２７と、をファイル管理に必要な情報として保持している。なお、データメモリ１０５に含まれるサイズ閾値１２０は、０以上の整数の形で保持される。
【００４６】
＜ファイル属性情報＞
図２は、データメモリ１０５に含まれるファイル属性情報１２１のデータ構造例を示す図である。
ファイル属性情報１２１は、フォルダパス２００と、最終更新日２０１と、最終アクセス日２０２と、サイズ２０３と、所有者２０４と、拡張子２０５と、ファイルサーバ１０６から該当ファイルの属性情報を取得した日時を示すクローリング日時２０６と、を構成情報として含んでいる。
【００４７】
＜インデクスデータ＞
図３は、本発明の実施形態で用いられる各種インデクスデータのデータ構造例を示す図である。データメモリ１０５に含まれるインデクスデータは、例えば、最終更新日別インデクス１２２と、最終アクセス日別インデクス１２３と、サイズ別インデクス１２４と、所有者別インデクス１２５と、拡張子別インデクス１２６と、を含んでいる。
【００４８】
最終更新日別インデクス１２２は、最終更新日別インデクスデータの配列の形で、最終アクセス日別インデクス１２３は、最終アクセス日別インデクスデータの配列の形で、サイズ別インデクス１２４は、サイズ別インデクスデータの配列の形で、所有者別インデクス１２５は、所有者別インデクスデータの配列の形で、拡張子別インデクス１２６は、拡張子別インデクスデータの配列の形で保持される。
【００４９】
最終更新日別インデクスデータは、閾値期日３００、サイズ３０１、ファイル数３０２を含んでいる。閾値期日３００には、年度末・年末・期末・月末などの、最終更新日によるファイルの集計において利用される閾値の値が設定されている。サイズ３０１およびファイル数３０２には、初期状態では０が設定されている。
【００５０】
最終アクセス日別インデクスデータは、閾値期日３０３、サイズ３０４、ファイル数３０５を含んでいる。閾値期日３０３には、年度末・年末・期末・月末などの、最終アクセス日によるファイルの集計において利用される閾値の値が設定されている。サイズ３０４およびファイル数３０５には、初期状態では０が設定されている。
【００５１】
サイズ別インデクスデータは、閾値サイズ３０６、サイズ３０７、ファイル数３０８を含んでいる。閾値サイズ３０６には、ファイルサイズによるファイルの集計において利用される閾値の値が設定されている。サイズ３０７およびファイル数３０８には、初期状態では０が設定されている。
【００５２】
所有者別インデクスデータは、ユーザ名３０９、サイズ３１０、ファイル数３１１を含んでいる。初期状態では配列の要素数は０であり、業務文書処理装置の処理の進展に従い、新しい所有者によるファイルが見つかるたびに配列の要素が追加される。
【００５３】
拡張子別インデクスデータは、拡張子３１２、サイズ３１３、ファイル数３１４を含んでいる。初期状態では配列の要素数は０であり、業務文書処理装置の処理の進展に従い、新しい所有者によるファイルが見つかるたびに配列の要素が追加される。
【００５４】
なお、各インデクスデータにおいて、サイズやファイル数は、各インデクスデータおいて同じ数値が用いられているが、これは便宜上そのようにしているのであって、通常は、各インデクスデータにおいて異なる数値となっているものである。
【００５５】
＜業務文書処理（全体）＞
続いて、本発明の実施形態による業務文書処理装置１において行われる処理について説明する。図４は、業務文書処理装置１において行われる全体処理を説明するためのフローチャートである。
【００５６】
図４において、まず、初期クローリング処理部１０８は、管理対象のファイルサーバに対する初期クローリングとして、ファイルサーバに保存されているファイルの情報を取得する（ステップ４００）。ステップ４００における処理の詳細については、後述する（図５参照）。
【００５７】
そして、インデクシング処理部１０９は、初期クローリングで収集した情報を基に、ファイルサーバに存在するファイルの集計を行うため（サーチを高速に実行できるようにするため）のインデクシングを行う（ステップ４０１）。すなわち、インデクシング処理部１０９は、ファイル属性情報１２１として保持されているファイル群のうち、最終更新日２０１が閾値期日３００より古いファイルを探してそのサイズ２０３の和をサイズ３０１に、ファイルの数をファイル数３０２に設定する。また、インデクシング処理部１０９は、最終アクセス日２０２が閾値期日３０３より古いファイルを探してそのサイズ２０３の和をサイズ３０４に、ファイルの数をファイル数３０５に設定する。さらに、インデクシング処理部１０９は、サイズ２０３が閾値サイズ３０６より小さいファイルを探してそのサイズ２０３の和をサイズ３０７に、ファイルの数をファイル数３０８に設定する。また、インデクシング処理部１０９は、所有者２０４の各値に所有者別インデクスデータの要素を用意し、ユーザ名３０９に所有者２０４の値を、ファイル属性情報１２１に保持されているファイル群のうち、所有者２０４がユーザ名３０９と等しいファイルを探してそのサイズ２０３の和をサイズ３１０に、ファイルの数をファイル数３１１に設定する。また、インデクシング処理部１０９は、拡張子２０５の値ごとに拡張子別インデクスデータの要素を用意し、拡張子３１２に拡張子２０５の値を、ファイル属性情報１２１に保持されているファイル群のうち、拡張子２０５が拡張子３１２と等しいファイルを探してそのサイズ２０３の和をサイズ３１３に、ファイルの数をファイル数３１４に設定する。なお、ステップ４０１の処理については、非特許文献１で示したような既存技術で実施可能である。
【００５８】
さらに、サーチ処理部１１１は、ユーザの要求に応じて、インデクシングの結果を用いてファイルサーバに存在するファイルの集計結果の表示を行う（ステップ４０２）。なお、ステップ４０２のサーチ処理部１１１による処理については、図７乃至１３を用いて詳細に説明する。
【００５９】
続いて、差分クローリング処理部１１０は、設定ファイル１２７を見て、クローリングを繰返す指定がされているかをチェックする（ステップ４０３）。設定ファイル１２７がクローリングを繰り返すように指定されている場合（ステップ４０３でＹｅｓの場合）、処理はステップ４０４に移行する。指定されていない場合（ステップ４０３でＮｏの場合）、処理は終了する。
【００６０】
ステップ４０４において、差分クローリング処理部１１０は、差分クローリングを実行する日時を取得し（ステップ４０４）、差分クローリングを行う（ステップ４０５）。ステップ４０５の詳細については後述する（図６参照）。なお、ステップ４０５を実行後、ステップ４０１から処理が繰り返される。
【００６１】
＜初期クローリング処理の詳細＞
図５は、図４のステップ４００における、初期クローリング処理の詳細について説明するためのフローチャートである。
【００６２】
初期クローリング処理部１０８は、まず、クローリング対象のフォルダの直下にあるファイルを得る（ステップ５００）。
【００６３】
次に、初期クローリング処理部１０８は、ファイルを数えるための変数file_idxを１で初期化する（ステップ５０１）。
【００６４】
その後、初期クローリング処理部１０８は、クローリング対象のフォルダにfile_idx以上のファイルがあるかどうかを調べる（ステップ５０２）。file_idx以上のファイルがある場合（ステップ５０２でＹｅｓの場合）、処理はステップ５０３に移行する。一方、file_idx未満のファイルしかない場合（ステップ５０２でＮｏの場合）、処理はステップ５０７に移行する。
【００６５】
ステップ５０３において、初期クローリング処理部１０８は、属性情報を調べ、当該属性情報を取得する（ステップ５０３）。
また、初期クローリング処理部１０８は、ステップ５０３で取得した属性情報を用いて、ファイルサイズ２０３がサイズ閾値１２０以上であるか調べる（ステップ５０４）。該当するファイルのサイズがサイズ閾値１２０以上である場合（ステップ５０４でＹｅｓの場合）、処理はステップ５０５に移行する。該当するファイルのサイズがサイズ閾値１２０未満である場合（ステップ５０４でＮｏの場合）、処理はステップ５０６に移行する。
【００６６】
ステップ５０５において、初期クローリング処理部１０８は、ステップ５０３で調べたファイルの属性情報をファイル属性情報ＤＢ１０７に保存する（ステップ５０５）。
【００６７】
そして、初期クローリング処理部１０８は、file_idxをインクリメントして（ステップ５０６）、ステップ５０２から処理をやり直す。
【００６８】
一方、ステップ５０２において条件に合致しない場合（ステップ５０２でＮｏの場合）、ステップ５０７において、初期クローリング処理部１０８は、直下にあるフォルダを得る（ステップ５０７）。
【００６９】
次に、初期クローリング処理部１０８は、フォルダを数えるための変数folder_idxを１で初期化する（ステップ５０８）。
【００７０】
そして、初期クローリング処理部１０８は、folder_idx以上のフォルダがあるかどうかを調べる（ステップ５０９）。folder_idx以上のフォルダがある場合（ステップ５０９でＹｅｓの場合）、初期クローリング処理部１０８は、再帰呼出（図５のフローチャートによる処理をサブフォルダについて行う）を行い（ステップ５１０）、folder_idxをインクリメントして（ステップ５１１）、ステップ５０９から処理をやり直す。
ステップ５０９において条件に合致しない場合（ステップ５０９でＮｏの場合）、処理は終了する
【００７１】
＜差分クローリング処理の詳細＞
図６は、図４のステップ４０５における差分クローリングの処理の詳細について説明するためのフローチャートである。
【００７２】
差分クローリング処理部１１０は、まず、クローリング対象のフォルダの直下にあるファイルを得る（ステップ６００）。
【００７３】
また、差分クローリング処理部１１０は、ファイルを数えるための変数file_idxを１で初期化する（ステップ６０１）。
【００７４】
次に、差分クローリング処理部１１０は、クローリング対象フォルダにfile_idx以上のファイルがあるかどうかを調べる（ステップ６０２）。file_idx以上のファイルがある場合（ステップ６０２でＹｅｓの場合）、処理はステップ６０３に移行し、そうでない場合（ステップ６０２でＮｏの場合）、処理はステップ６１１に移行する。
【００７５】
ステップ６０３において、差分クローリング処理部１１０は、属性情報を調べ（ステップ６０３）、該当ファイルのファイルサイズ２０３がサイズ閾値１２０以上であるか調べる（ステップ６０４）。該当ファイルのサイズがサイズ閾値１２０以上である場合（ステップ６０４でＹｅｓの場合）、処理はステップ６０５に移行し、そうでない場合（ステップ）６０４でＮｏの場合）、処理はステップ６０９に移行する。
【００７６】
ステップ６０５において、差分クローリング処理部１１０は、対象ファイルの属性情報がファイル属性情報ＤＢ１０７に登録済かどうか調べる（ステップ６０５）。登録済である場合（ステップ６０５でＹｅｓの場合）処理はステップ６０６に移行し、登録済でない場合（ステップ６０５でＮｏの場合）、処理はステップ６０７に移行する。
【００７７】
ステップ６０６において、差分クローリング処理部１１０は、登録内容を更新する（ステップ６０６）。一方、ステップ６０７において、差分クローリング処理部１１０は、対象ファイルの属性情報を追加登録する（ステップ６０７）。
【００７８】
そして、ステップ６０８において、差分クローリング処理部１１０は、file_idxをインクリメントして（ステップ６０８）、ステップ６０２から処理を繰り返す。
【００７９】
一方、ステップ６０９において、差分クローリング処理部１１０は、対象ファイルの属性情報がファイル属性情報ＤＢ１０７に登録済かどうか調べる（ステップ６０９）。対象ファイルの属性情報が登録済の場合（ステップ６０９でＹｅｓの場合）、差分クローリング処理部１１０は、登録内容を削除して（ステップ６１０）、ステップ６０８から処理を続ける。
【００８０】
一方、ステップ６０２において条件に合致しない場合、ステップ６１１において、差分クローリング処理部１１０は、ファイル属性情報ＤＢ１０７から、クローリング日時２０６の値がステップ４０４で取得した値よりも古いファイルを削除する（ステップ６１１）。これにより、前回存在したが今回存在していないファイルの属性情報を削除することが可能となる。
【００８１】
続いて、差分クローリング処理部１１０は、直下にあるサブフォルダを得て（ステップ６１２）、フォルダを数えるための変数folder_idxを１で初期化する（ステップ６１３）。
【００８２】
次に、差分クローリング処理部１１０は、対象フォルダにfolder_idx以上のフォルダがあるかどうかを調べる（ステップ６１４）。対象フォルダにfolder_idx以上のフォルダがある場合（ステップ６１４でＹｅｓの場合）、処理はステップ６１５に移行し、そうでない場合（ステップ６１４でＮｏの場合）、処理は終了する。
【００８３】
ステップ６１５において、差分クローリング処理部１１０は、再帰呼出（図６のフローチャートを呼び出して実行する）を行い（ステップ６１５）、folder_idxをインクリメントして（ステップ６１６）、ステップ６１４から処理を繰り返す。
【００８４】
＜サーチ処理の具体例＞
図７乃至１３を用いて、図４のステップ４０２のサーチ処理部１１１による処理の具体例について説明する。
【００８５】
（１）サイズ別グラフ表示処理
図７は、サーチ処理部１１１のグラフ表示処理部１１２におけるサイズ別グラフ表示処理部１１５を用いて画面表示を行う場合について示している。
【００８６】
表領域７００には、サイズ別の集計値について、サイズ別インデクス１２４を参照して表示する。
【００８７】
領域７０１には、容量ではなくファイル数での表示を行ったり、表でなくグラフで表示したりするためのユーザ操作を受け付けるためのインタフェースを表示する。
【００８８】
また、領域７０２には、サイズ閾値１２０について表示するとともに、次回差分クローリングからこの値を変更するためのインタフェースを表示する。
【００８９】
さらに、領域７０３には、特定の範囲のファイルサイズを持つファイルについて、個別表示を行うためのユーザ操作を受け付けるためのインタフェースを表示する。
【００９０】
なお、ユーザが領域７０３をクリックすると図１２のような表示に切り替わるようになっている。
【００９１】
（２）最終更新日別グラフ表示処理
図８は、サーチ処理部１１１のグラフ表示処理部１１２における最終更新日別グラフ表示処理部１１６を用いて画面表示を行う場合について示している。
【００９２】
グラフ領域８００には、最終更新日別の集計値について、最終更新日別インデクス１２２を参照して表示する。
【００９３】
領域８０１には、領域７０１と同様に、容量ではなくファイル数での表示を行ったり、表でなくグラフで表示したりするためのユーザ操作を受け付けるためのインタフェースを表示する。
【００９４】
また、領域８０２には、領域７０２と同様に、サイズ閾値１２０について表示するとともに、次回差分クローリングからこの値を変更するためのインタフェースを表示する。
【００９５】
さらに、領域８０３には、特定の範囲の最終更新日を持つファイルについて、個別表示を行うためのユーザ操作を受け付けるためのインタフェースを表示する。
【００９６】
なお、ユーザが領域８０３をクリックすると図１２のような表示（ただし、ファイル一覧１２００の文言が「最終更新日が２０１１年」に変わる）に切り替わるようになっている。
【００９７】
（３）最終アクセス日別グラフ表示処理
図９は、サーチ処理部１１１のグラフ表示処理部１１２における最終アクセス日別グラフ表示処理部１１７を用いて画面表示を行う場合について示している。
【００９８】
グラフ領域９００には、最終アクセス日別の集計値について、最終アクセス日別インデクス１２３を参照して表示する。
【００９９】
領域９０１には、領域７０１及び８０１と同様に、容量ではなくファイル数での表示を行ったり、表でなくグラフで表示したりするためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１００】
また、領域９０２には、領域７０２及び８０２と同様に、サイズ閾値１２０について表示するとともに、次回差分クローリングからこの値を変更するためのインタフェースを表示する。
【０１０１】
さらに、領域９０３には、特定の範囲の最終アクセス日を持つファイルについて、個別表示を行うためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１０２】
なお、ユーザが領域９０３をクリックすると図１２のような表示（ただし、ファイル一覧１２００の文言が「最終アクセス日が２０１２年」に変わる）に切り替わるようになっている。
【０１０３】
（４）所有者別グラフ表示処理
図１０は、サーチ処理部１１１のグラフ表示処理部１１２における所有者別グラフ表示処理部１１８を用いて画面表示を行う場合について示している。
【０１０４】
グラフ領域１０００には、所有者別の集計値について、所有者別インデクス１２５を参照して表示する。
【０１０５】
領域１００１には、領域７０１、８０１及び９０１と同様に、容量ではなくファイル数での表示を行ったり、表でなくグラフで表示したりするためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１０６】
また、領域１００２には、領域７０２、８０２及び９０２と同様に、サイズ閾値１２０について表示するとともに、次回差分クローリングからこの値を変更するためのインタフェースを表示する。
【０１０７】
さらに、領域１００３には、特定の所有者を持つファイルについて、個別表示を行うためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１０８】
なお、ユーザが領域１００３をクリックすると図１２のような表示（ただし、ファイル一覧１２００の文言が「ユーザ０１のファイル」に変わる）に切り替わるようになっている。
【０１０９】
（５）拡張子別グラフ表示処理
図１１は、サーチ処理部１１１のグラフ表示処理部１１２における拡張子別グラフ表示処理部１１９を用いて画面表示を行う場合について示している。
【０１１０】
グラフ領域１１００には、拡張子別の集計値について、拡張子別インデクス１２６を参照して表示する。
【０１１１】
領域１１０１には、領域７０１、８０１、９０１及び１００１と同様に、容量ではなくファイル数での表示を行ったり、表でなくグラフで表示したりするためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１１２】
また、領域１１０２には、領域７０２、８０２、９０２及び１００２と同様に、サイズ閾値１２０について表示するとともに、次回差分クローリングからこの値を変更するためのインタフェースを表示する。
【０１１３】
さらに、領域１１０３には、特定の拡張子を持つファイルについて、個別表示を行うためのユーザ操作を受け付けるためのインタフェースを表示する。
【０１１４】
なお、ユーザが領域１１０３をクリックすると図１２のような表示（ただし、ファイル一覧１２００の文言が「ｍｐ３ファイル」に変わる）に切り替わるようになっている。
【０１１５】
＜個別ファイル表示＞
図１２は、サーチ処理部１１１の個別ファイル表示処理部１１３を用いて画面表示を行う場合について示している。この画面表示は、領域７０３、８０３、９０３、１００３及び１１０３に対するユーザ操作を受け付けて表示されるものである。
【０１１６】
領域１２００には、この画面で表示しているファイルはどのような属性情報を持つファイルを抽出したのかを表示する。
【０１１７】
表示１２０１には、この画面で表示しているファイルはどのような順序で並んでいるかを示すと共に、ユーザによる属性の指定を受け付けて表示ファイルを並べ替えるためのインタフェースを表示する。領域１２０２には、各ファイルについての情報を表示する。
【０１１８】
チェック欄１２０３には、ユーザの操作を受け付けて各ファイルを削除するためのインタフェースを表示する。チェック欄１２０４には、ユーザの操作を受け付けて、各ファイルが存在するフォルダ全体を削除するためのインタフェースを表示する。フォルダ表示１２０５には、ユーザの操作を受け付けて、各ファイルが存在するフォルダの表示を行うためのインタフェースを表示する。
【０１１９】
なお、ユーザがフォルダ表示１２０５をクリックすると、図１３のフォルダ削除画面が表示されるようになっている。
【０１２０】
＜フォルダ削除画面＞
図１３は、サーチ処理部１１１のフォルダ削除処理部１１４を用いて画面表示を行う場合について示している。この画面表示は、フォルダ表示１２０５に対するユーザ操作を受け付けて表示されるものである。
【０１２１】
領域１３００には、この画面で表示しているフォルダのパスを表示する。表示１３０１には、この画面で表示しているファイルはどのような順序で並んでいるかを示すと共に、ユーザによる属性の指定を受け付けて表示ファイルを並べ替えるためのインタフェースを表示する。
【０１２２】
領域１３０２には、領域１３００で示したフォルダに存在するファイルについての情報を表示する。領域１３０３には、ユーザの操作を受け付けて各ファイルを削除するためのインタフェースを表示する。
【０１２３】
また、チェック欄１３０４には、ユーザの操作を受け付けて表示中のフォルダ全体を削除するためのインタフェースを表示する。
【０１２４】
＜変形例＞
上述の実施形態では、ファイルの属性情報の集計において、拡張子別の例を示した。この方法に代えて、例えば「拡張子がｚｉｐのファイル」でなく「圧縮ファイル」、または「拡張子がｍｐ３のファイル」でなく「音楽ファイル」など、ファイルの種類ごとに集計を行う方式も可能である。
【０１２５】
また、本実施形態では、チェック欄１２０３、１２０４、１３０３及び１３０４において、ユーザの操作を受け付けてファイルまたはフォルダ全体を削除する例を示した。この方式に代えて、不要ファイルを一時的に格納するためにあらかじめ用意した領域（例えば、ごみ箱フォルダ）にファイルまたはフォルダ全体を移動する方式や、不要なファイルである旨をファイル属性情報ＤＢに保持しておき次回の差分クローリングで削除または移動をまとめて行う方式も可能である。
【０１２６】
また、本実施形態で述べたフォルダ削除処理部に代えて、個別ファイル表示処理部から各ユーザのコンピュータにおけるオペレーティングシステムからフォルダの表示機能を呼び出すように構成しても良い。
【０１２７】
＜まとめ＞
（i）本発明の実施形態では、業務文書処理装置は、まず、クローリング処理において、ファイルサーバが有する１つのフォルダに含まれる複数のファイルのうち、ファイルサイズが所定の閾値以上のサイズを有するファイルについてのみ属性情報を取得し、ファイル属性情報ＤＢに保持させておく。そして、当該装置は、ユーザが入力したサーチ条件に基づいて、ファイル属性情報ＤＢをサーチし、サーチ条件に合致するファイルの情報をユーザに提示する。このようにすることにより、ユーザは、所望の不要ファイルを削除することができるようになる。また、ファールサーバに格納されている一部のファイルの属性情報のみを管理するようにしているので、メタデータを保持する管理用コンピュータ（つまり、業務文書処理装置）の負荷を軽減することができるようになる。
【０１２８】
ファイルの属性情報の取得処理を実行する対象である１つのフォルダがサブフォルダを有する場合には、当該業務文書処理装置は、このサブフォルダの直下に含まれるファイルについて、所定の閾値以上のサイズを有するか判断し、当該サイズ以上のファイルの属性情報のみをさらに取得する。サブフォルダがさらにある場合には、この処理を繰り返すようにする。このようにすることにより、管理が必要なファイルのみの属性情報を漏れなく、かつ効率的に取得することができるようになる。
【０１２９】
また、業務文書処理装置は、１つのフォルダに含まれる複数のファイルに対して、クローリング処理を再度実行（差分クローリング処理）し、所定の閾値以上のファイルサイズを有するファイルについてのみ属性情報を再度取得して、属性情報ＤＢを更新する。このようにすることにより、時間経過により削除されたり、ファイルサイズに変動があったりした場合に適切に対応することが可能となる。
【０１３０】
業務文書処理装置は、サーチ処理を実行する場合、サーチ条件に合致するファイルの集計結果（サーチ結果）を、複数の要素（図７：ファイルサイズ別、図８及び９：最終更新年別、図１０：ユーザ別、図１１：ファイルの種類別等）に分類して表示画面に表示する。また、ユーザが集計結果の１つの要素を選択した場合には、業務文書処理装置は、（i）当該選択された要素に対応するファイルの詳細情報と、（ii）個々のファイルの削除を指定するためのチェック欄表示と、選択された要素に対応するファイルが属する個々のフォルダの削除を指定するためのチェック欄表示と、選択された要素に対応するファイルが属する個々のフォルダに含まれるファイルの情報を表示させるためのフォルダ閲覧指定の表示と、を表示画面に表示させる。このようにすることにより、ファイル削除に対する様々なユーザのニーズに応えることができるようになる。
【０１３１】
また、ユーザがフォルダ閲覧指定表示を選択すると、選択されたフォルダに含まれる全てのファイルの情報と、選択されたフォルダに含まれる個々のファイルの削除を指定するためのチェック欄表示と、選択されたフォルダ自体の削除を指定するためのチェック欄と、が表示画面に表示される。このようにフォルダ自体の削除を指定することを可能にすることにより、ユーザは効率よく不要ファイルを整理することができるようになる。
【０１３２】
（ii）本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【０１３３】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【０１３４】
さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【０１３５】
最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
【０１３６】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【０１３７】
加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。
【符号の説明】
【０１３８】
１００・・・表示装置
１０１・・・キーボード
１０２・・・ポインティングデバイス
１０３・・・中央処理装置
１０４・・・プログラムメモリ
１０５・・・データメモリ
１０６・・・ファイルサーバ
１０７・・・ファイル属性情報ＤＢ
【図１】
2015087942.tif 000003
【図２】
2015087942.tif 000004
【図３】
2015087942.tif 000005
【図４】
2015087942.tif 000006
【図５】
2015087942.tif 000007
【図６】
2015087942.tif 000008
【図７】
2015087942.tif 000009
【図８】
2015087942.tif 000010
【図９】
2015087942.tif 000011
【図１０】
2015087942.tif 000012
【図１１】
2015087942.tif 000013
【図１２】
2015087942.tif 000014
【図１３】
2015087942.tif 000015