(57)【要約】【課題】複数のファイルを一つの文書のバージョンに容易にまとめることを可能にすると共に、バージョンの更新者に関する情報を設定可能にすることを目的とする。【解決手段】ネットワークを介して通信可能なクライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、ファイルから最終更新者情報を抽出する抽出手段と、ファイルをバージョンとして文書に対して登録する登録手段と、抽出手段で抽出された最終更新者情報を登録手段で登録されたバージョンの属性情報として設定する設定手段と、を有することによって課題を解決する。【選択図】図１６
2010020645.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して通信可能なクライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、
前記受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、
前記判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出手段と、
前記ファイルをバージョンとして前記文書に対して登録する登録手段と、
前記抽出手段で抽出された前記最終更新者情報を前記登録手段で登録されたバージョンの属性情報として設定する設定手段と、
を有することを特徴とする文書管理装置。
【請求項２】
前記受信手段で受信された前記バージョン一括登録要求に文書名が含まれている場合、前記バージョン一括登録要求に含まれるファイルの並び順情報に基づいて、先頭の実ファイルに前記文書名を付けて登録する文書登録手段を更に有し、
前記判定手段は、前記バージョン一括登録要求に含まれるファイルの並び順情報及び実ファイルに基づいて、前記文書登録手段で登録された文書に対してバージョンとして登録するファイルが存在するか否かを判定することを特徴とする請求項１に記載の文書管理装置。
【請求項３】
前記受信手段で受信された前記バージョン一括登録要求にバージョンの登録に係るルール情報が含まれている場合、前記ルール情報に基づいて、前記バージョン一括登録要求に含まれる実ファイルの中の一つのファイルに文書名を付けて登録する文書登録手段を更に有し、
前記判定手段は、前記バージョン一括登録要求に含まれるルール情報及び実ファイルに基づいて、前記文書登録手段で登録された文書に対してバージョンとして登録するファイルが存在するか否かを判定することを特徴とする請求項１に記載の文書管理装置。
【請求項４】
前記判定手段は、前記受信手段で受信された前記バージョン一括登録要求に既存の文書を識別する識別情報が存在する場合、前記バージョン一括登録要求に含まれるバージョンの登録に係るルール情報及び実ファイルに基づいて、前記既存の文書に対してバージョンとして登録するファイルが存在するか否かを判定することを特徴とする請求項１に記載の文書管理装置。
【請求項５】
クライアント端末装置と、前記クライアント端末装置とネットワークを介して通信可能な文書管理装置と、を含む文書管理システムであって、
前記クライアント端末装置は、
文書に係るバージョン一括登録要求を作成する作成手段と、
前記作成手段で作成された前記バージョン一括登録要求を前記文書管理装置に送信する送信手段と、
を有し、
前記文書管理装置は、
前記クライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、
前記受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、
前記判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出手段と、
前記ファイルをバージョンとして前記文書に対して登録する登録手段と、
前記抽出手段で抽出された前記最終更新者情報を前記登録手段で登録されたバージョンの属性情報として設定する設定手段と、
を有することを特徴とする文書管理システム。
【請求項６】
前記作成手段は、画面を介したユーザの操作に基づいて、文書名と、ファイルの並び順情報と、複数の実ファイルと、を含んだ前記バージョン一括登録要求を作成することを特徴とする請求項５に記載の文書管理システム。
【請求項７】
前記作成手段は、画面を介したユーザの操作に基づいて、バージョンの登録に係るルール情報と、複数の実ファイルと、を含んだ前記バージョン一括登録要求を作成することを特徴とする請求項５に記載の文書管理システム。
【請求項８】
前記作成手段は、画面を介したユーザの操作に基づいて、既存の文書を識別する識別情報と、バージョンの登録に係るルール情報と、複数の実ファイルと、を含んだ前記バージョン一括登録要求を作成することを特徴とする請求項５に記載の文書管理システム。
【請求項９】
前記クライアント端末装置は、
前記文書管理装置より、前記バージョン一括登録要求に対するバージョン一括登録結果を受信するバージョン一括登録結果受信手段と、
前記バージョン一括登録結果受信手段で受信したバージョン一括登録結果に基づいて、バージョンとして登録されたファイルの一覧を表示するバージョン一括登録結果表示手段と、
を更に有することを特徴とする請求項５乃至８の何れか１項に記載の文書管理システム。
【請求項１０】
文書管理装置における文書管理方法であって、
ネットワークを介して通信可能なクライアント端末装置から文書に係るバージョン一括登録要求を受信する受信ステップと、
前記受信ステップで受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定ステップと、
前記判定ステップで文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出ステップと、
前記ファイルをバージョンとして前記文書に対して登録する登録ステップと、
前記抽出ステップで抽出された前記最終更新者情報を前記登録ステップで登録されたバージョンの属性情報として設定する設定ステップと、
を有することを特徴とする文書管理方法。
【請求項１１】
クライアント端末装置と、前記クライアント端末装置とネットワークを介して通信可能な文書管理装置と、を含む文書管理システムにおける文書管理方法であって、
前記クライアント端末装置が、文書に係るバージョン一括登録要求を作成する作成ステップと、
前記クライアント端末装置が、前記作成ステップで作成された前記バージョン一括登録要求を前記文書管理装置に送信する送信ステップと、
前記文書管理装置が、前記クライアント端末装置から文書に係るバージョン一括登録要求を受信する受信ステップと、
前記文書管理装置が、前記受信ステップで受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定ステップと、
前記文書管理装置が、前記判定ステップで文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出ステップと、
前記文書管理装置が、前記ファイルをバージョンとして前記文書に対して登録する登録ステップと、
前記文書管理装置が、前記抽出ステップで抽出された前記最終更新者情報を前記登録ステップで登録されたバージョンの属性情報として設定する設定ステップと、
を有することを特徴とする文書管理方法。
【請求項１２】
コンピュータを、
ネットワークを介して通信可能なクライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、
前記受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、
前記判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出手段と、
前記ファイルをバージョンとして前記文書に対して登録する登録手段と、
前記抽出手段で抽出された前記最終更新者情報を前記登録手段で登録されたバージョンの属性情報として設定する設定手段と、
して機能させることを特徴とするプログラム。
【請求項１３】
請求項１２に記載のプログラムを記憶したコンピュータにより読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理装置、文書管理システム及び文書管理方法に関する。
【背景技術】
【０００２】
Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）等のファイルシステムでは、ファイルは１ファイル１バージョンとして管理されている。このようなファイルシステム上で、１つのファイルに対して複数のユーザによって共同編集を行う場合には、ファイル名によって複数のバージョンに分けて管理する方法が一般的である。一方、１つのファイル（文書）を複数のバージョンで管理可能な文書管理システムもある。このような文書管理システムでは、ユーザは、最初に登録した文書をチェックアウトすることで編集開始を宣言し、編集終了時にチェックインを行う。このような文書管理システムのバージョン管理機能では、ユーザがチェックアウトとチェックインとを行うと、文書に対して１つ新しいバージョンが追加登録する。また、このような文書管理システムでは、過去のバージョン履歴の閲覧やダウンロードを可能にする機能も提供する。
【０００３】
前述したファイル名でバージョン管理が行われていたファイルシステムからバージョン管理機能を持つ文書管理システムへデータを移行する場合ユーザは一番古いファイルを新規登録し、ファイルの数だけチェックアウトとチェックインとを繰り返す必要があった。
これを解決するために、バージョン管理機能を持たないファイルシステムからバージョン管理機能を持つシステムにコピーしたファイルを監視し、その後更新されたファイルを自動的に新しいバージョンに追加する方法が提案されている（特許文献１）。
【０００４】
【特許文献１】特開２００５−３１６７１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の技術では、既存の複数のファイルを一度の操作でまとめて登録することはできない。また、各ファイルを更新したユーザの情報を管理していないため、どのバージョンをどのユーザが更新したのかを文書管理システム上で把握することができない問題がある。
【０００６】
本発明はこのような問題点に鑑みなされたもので、複数のファイルを一つの文書のバージョンに容易にまとめることを可能にすると共に、バージョンの更新者に関する情報を設定可能にすることを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明は、ネットワークを介して通信可能なクライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、前記受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、前記判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出手段と、前記ファイルをバージョンとして前記文書に対して登録する登録手段と、前記抽出手段で抽出された前記最終更新者情報を前記登録手段で登録されたバージョンの属性情報として設定する設定手段と、を有することを特徴とする。
【０００８】
また、本発明は、クライアント端末装置と、前記クライアント端末装置とネットワークを介して通信可能な文書管理装置と、を含む文書管理システムであって、前記クライアント端末装置は、文書に係るバージョン一括登録要求を作成する作成手段と、前記作成手段で作成された前記バージョン一括登録要求を前記文書管理装置に送信する送信手段と、を有し、前記文書管理装置は、前記クライアント端末装置から文書に係るバージョン一括登録要求を受信する受信手段と、前記受信手段で受信されたバージョン一括登録要求に基づいて、文書に対してバージョンとして登録するファイルが存在するか否かを判定する判定手段と、前記判定手段で文書に対してバージョンとして登録するファイルが存在すると判定された場合、前記ファイルから最終更新者情報を抽出する抽出手段と、前記ファイルをバージョンとして前記文書に対して登録する登録手段と、前記抽出手段で抽出された前記最終更新者情報を前記登録手段で登録されたバージョンの属性情報として設定する設定手段と、を有することを特徴とする。
【０００９】
また、本発明は、文書管理方法、プログラム及び記憶媒体としてもよい。
【発明の効果】
【００１０】
本発明によれば、複数のファイルを一つの文書のバージョンに容易にまとめることを可能にすると共に、バージョンの更新者に関する情報を設定可能にすることができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態について図面に基づいて説明する。
【００１２】
＜実施形態１＞
図１は、文書管理システムとクライアントコンピュータとの概略構成の一例を示す図である。図１に示すように、クライアントコンピュータ１０１と文書管理システム１０６とは、インターネットや企業内ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１００を介して通信可能に接続されている。
【００１３】
１０１は、クライアント端末装置の一例である、ユーザが使用するパーソナルコンピュータ等のクライアントコンピュータ機器（以下、ＰＣという）である。Ｗｅｂブラウザ１０２は、Ｗｅｂサーバにアクセスするための一般的なＷｅｂブラウザである。ファイル選択部１０３は、Ｗｅｂブラウザ１０２上で動作し、ファイル保存部１０５から任意のファイルを選択するためのモジュールである。なお、ファイル選択部１０３は、Ｗｅｂブラウザ１０２とは別にＰＣ１０１にインストールするプラグインモジュールであってもよい。文書情報設定部１０４は、Ｗｅｂブラウザ１０２上で動作し、ファイル選択部１０３によって選択した一つ以上のファイルの登録順や文書名を設定するためのモジュールである。文書情報設定部１０４は、Ｗｅｂブラウザ１０２とは別にＰＣ１０１にインストールするプラグインモジュールであってもよい。なお、本実施形態ではＷｅｂブラウザとプラグインモジュールとによる構成を例に記載するが、本発明は任意のファイルとファイルに関する情報とを送信可能なクライアントアプリケーションに適用可能なものであり、この構成に限定するものではない。また、ファイル保存部１０５は、ＰＣ１０１内の記憶装置にあってもよいし、ネットワーク１００によって接続された任意のファイルサーバ上の記憶装置にあってもよい。
【００１４】
文書管理装置の一例である文書管理システム１０６は１つ以上の情報処理装置によって構成され、複数の処理部や情報格納部によって構成される。文書管理システム１０６では、キャビネットやフォルダ、文書及びバージョンを階層構造で管理することが可能であるが、詳細は省略する。本実施形態においては、文書管理システム１０６に任意のキャビネット、フォルダ、文書、これらの情報にアクセス可能なユーザ情報が予め登録されているものとする。１０７、１０８、１０９、１１０、１１１、１１２は、処理部（処理手段）であり、ＰＣ１０１からの要求に応じて処理を実行する。１１３、１１４、１１５、１１６は、情報格納部であり、各処理部によって情報の読み出しや書き込みが実行される。
図２は、文書管理システムやクライアントコンピュータのハードウェア構成の一例を示す図である。２０１は、情報処理装置の演算・制御を司る中央演算装置（以下、ＣＰＵという）である。２０２は、ランダムアクセスメモリ（以下、ＲＡＭという）であり、ＣＰＵ２０１の主メモリとして及び実行プログラムの領域や実行プログラムの実行エリア並びにデータエリアとして機能する。
【００１５】
２０３は、ＣＰＵ２０１の動作処理手順等を記憶しているリードオンリーメモリ（以下、ＲＯＭという）である。ＲＯＭ２０３には情報処理装置の機器制御を行うシステムプログラムである基本ソフト（ＯＳ）を記録したプログラムＲＯＭと、システムを稼働するために必要な情報等が記録されているデータＲＯＭと、がある。また、ＲＯＭ２０３の代わりに、後述のＨＤＤ２０９を用いる場合もある。
２０４は、ネットワークインターフェース（ＮＥＴＩＦ）であり、ネットワークを介して情報処理装置間のデータ転送を行うための制御や接続状況の診断を行う。２０５は、ビデオＲＡＭ（ＶＲＡＭ）であり、後述する情報処理装置の稼働状態を示すＣＲＴ２０６の画面に表示させるための画像を展開し、その表示の制御を行う。
【００１６】
２０６は、ディスプレイ等の表示装置（以下、ＣＲＴという）である。２０７は、外部入力装置２０８からの入力信号を制御するためのコントローラ（以下、ＫＢＣという）である。２０８は、利用者が行う操作を受け付けるための外部入力装置（以下、ＫＢＣという）であり、例えばキーボードやマウス等のポインティングデバイスが用いられる。
２０９は、ハードディスクドライブ（以下、ＨＤＤという）であり、アプリケーションプログラムや各種データ保存用に用いられる。本実施形態におけるアプリケーションプログラムとは、本実施形態における各種処理部を実現するソフトウェアプログラム等である。
【００１７】
２１０は、外部入出力装置（以下、ＦＤＤという）であり、例えばフレキシブルディスクドライブ、ＣＤＲＯＭドライブ等のリムーバブルディスクを入出力するものであり、上述したアプリケーションプログラムの媒体からの読み出し等に用いられる。
２１１は、ＦＤＤ２１０によって読み出しされる磁気記録媒体、光記録媒体（例えば、ＣＤ−ＲＯＭ）等の取り外し可能なデータ記録媒体（リムーバブル・メディア）である（以下、ＦＤという）。また、２１１は、光磁気記録媒体（例えば、ＭＯ）、半導体記録媒体（例えば、メモリカード）であってもよい。
なお、ＨＤＤ２０９に格納するアプリケーションプログラムやデータをＦＤＤ２１０に格納して使用することも可能である。
【００１８】
図３は、文書管理メイン画面の一例を示す図である。３００は、ユーザがＰＣ１０１のＷｅｂブラウザ１０２を使用して接続し、ログインした場合に表示される文書管理メイン画面である。
フォルダツリー表示部３０１は、文書管理システム１０６で管理されているフォルダ階層を表示する画面構成部分である。ユーザが画面内の＋や−記号をクリックすることで、ＰＣ１０１は、フォルダを開閉する。またユーザがフォルダを選択することで、ＰＣ１０１は、文書一覧表示部３０２に選択されたフォルダ内のサブフォルダや文書の一覧を表示する。
【００１９】
文書一覧表示部３０２は、選択されたフォルダ内の情報を一覧表示するための画面構成部分である。ユーザはこの画面を主に操作し、フォルダや文書に対する処理を指示（入力）する。前記処理の指示とは、例えば、サブフォルダの作成、文書の登録、チェックアウト、チェックイン、削除、ダウンロード等の指示である。これらの処理はユーザが操作ボタン群３０３をクリックすることでＰＣ１０１又は文書管理システム１０６において実行される。
図４は、ＰＣ１０１内のファイル保存部１０５に記憶されているファイルの一覧を表示する画面の一例を示す図である。本実施形態では、図４に表示されている"レビュー資料"で始まる５つのファイルを使用して説明を行う。
【００２０】
図５は、文書一覧表示部３０２において文書登録ボタンがクリックされ、ＰＣ１０１が図４の５つのファイルを登録実行した後の画面の一例を示す図である。文書一覧表示部５０１には５つのファイルがそれぞれ個別の文書として登録された状態が表示されている。文書の作成者は文書登録処理を実行したユーザであるｙａｍａｄａが設定されている。この状態では、バージョン管理機能を持たないＰＣ１０１上のファイルシステム等にファイルを保管しているのと同様である。
図６は、バージョン一括登録画面の一例を示す図である。６０１は、登録対象のファイル一覧を表示する登録対象ファイルリスト部である。ユーザがＰＣ１０１にあるファイルを登録対象ファイルリスト部６０１にドラッグ・アンド・ドロップすることで一覧にファイルが追加される。登録対象ファイルリスト部６０１にはファイル名、拡張子、更新日時、サイズが表示される。各項目でファイルリストの並び順を変更可能にしてもよいが、並び順は更新日時やファイル名の昇順で固定としてもよい。この並び順がバージョンの並び順に反映される。
【００２１】
６０２は、ファイルの振り分け方法指定部であり、登録対象ファイルリスト部６０１に追加されたファイルを、１つ文書のバージョンにまとめるのか、規定のルールに従ってファイルを複数の文書に振り分けるのかを指定する部である。規定のルールの設定方法に関しては後述する。ルールによっては、文書管理システム１０６は、複数のファイルを複数のバージョンを持つ複数の文書に振り分けることができる。ユーザは、全てのファイルを１つの文書にまとめるように指定した場合、文書名を入力する。図６では、ユーザが、全てのファイルを１つの文書にまとめて、文書名に、"レビュー資料"を指定した場合の一例を示している。
６０３は、登録対象ファイルリスト部から対象ファイルを削除するための操作ボタンである。ユーザが、登録対象ファイルリスト部で任意のファイルを１つ以上選択し、削除ボタンをクリックすると登録対象ファイルから除外される。
【００２２】
６０４は、実行ボタンであり、ユーザが実行ボタンをクリックすると、ＰＣ１０１においてバージョン一括登録要求が作成され、文書管理システム１０６に送信される。バージョン一括登録要求にはファイルの属性（属性情報）や並び順（並び順情報）を含んだファイルリスト、振り分け方法、指定された文書名、全ファイルの実体（実ファイル）も含まれる。ユーザが振り分け方法指定部６０２で規定のルールに従うことを指定した場合、文書名や並び順はバージョン一括登録要求に含まれない。
図７は、ユーザが図６において実行ボタン６０４をクリックし、バージョン一括登録を実行した結果の文書一覧表示画面の一例を示す図である。ユーザが振り分け方法指定部６０２で全てのファイルを１つの文書にまとめるように指定したため、文書一覧表示部７０１には文書が１つのみ表示される。５つのファイルをバージョンに登録した結果、バージョン数は５となる。図７において、ユーザが文書選択ボックス７０２で文書を選択し、バージョン一覧表示ボタン７０３をクリックすると、図８のバージョン一覧表示画面８００が表示される。
【００２３】
図８は、バージョン一覧表示画面の一例を示す図である。図８では、図６の操作により、５つのバージョンが"レビュー資料"のバージョンとして登録された結果（"レビュー資料"のバージョンとして登録されたファイルの一覧）を示している。バージョン一覧表示部８０１には、バージョンのリストが表示される。バージョン名８０２は、各ファイルのファイル名である。拡張子８０３は、各ファイルの拡張子である。作成者８０５は、バージョン一括登録を要求したユーザのユーザ名であり、文書管理システム１０６上でバージョンを作成した（作成することを要求した）ユーザである。最終更新者８０６は、登録されたファイルの実体から抽出された最終更新者の情報である。抽出ができなかった場合には空白で表示される。
文書管理システム１０６は、ＰＣ１０１よりバージョン一括登録要求を受信し、後述する図１６に示すようなバージョン一括登録に係る処理を実行した後、実行結果（バージョン一括登録要求に対するバージョン一括登録結果）をＰＣ１０１に送信する。ＰＣ１０１は、この実行結果を受信する（バージョン一括登録結果受信）。ＰＣ１０１は、受信した実行結果に基づき、図７や図８に示すような画面を表示する（バージョン一括登録結果表示）。
【００２４】
以上が、ユーザがＰＣ１０１のＷｅｂブラウザ１０２を使用して複数のファイルをまとめて１つの文書のバージョンとして登録するための手順と登録結果（実行結果）とである。
【００２５】
次に図６において、ユーザが"規定のルールに従う"を選択して、複数のファイルを複数の文書のバージョンにまとめて登録する場合の例を説明する。
図９は、予め文書を振り分けるルールを設定するための、振り分けルール設定画面の一例を示す図である。文書が新規に登録される場合と既存の文書に追加される場合とで設定内容は異なる。９０１は、１つの文書にまとめるためのルール（ルール情報）を設定するための、振り分けルール設定部である。９０２は、バージョンの登録順を決定するためのソート順のルールを設定するソート順設定部である。ユーザは、ソート順設定部９０２を操作して、更新日時やファイル名の昇降順を設定することができる。９０３は、振り分けた結果の文書の文書名を決定するための文書名決定ルール設定部である。ユーザは、文書名決定ルール設定部９０３を操作して、文書名を最新バージョンのファイル名か、振り分けルールの先頭文字か、最新バージョンの登録日時か、を選択することができる。
【００２６】
９０４は、新規登録ではなく、既存の文書のバージョンに複数のファイルを一括登録する場合に有効な、重複ファイル取り扱い指定部である。文書振り分けルール設定画面９００は、キャビネットやフォルダ単位に文書振り分けルールを設定可能とするが、システム単位に文書振り分けルールを設定してもよい。また、複数のルールをシステムやキャビネット、フォルダ単位に設定しておき、登録時にルールを選択する方法をとしてもよい。しかしながら、説明の簡略化のため、本実施形態においては複数のルールの管理方法や選択方法に関しては省略する。
【００２７】
図１０は、ＰＣ１０１内のファイル保存部１０５に記憶されているファイル一覧の画面の一例を示す図である。ここでは、規定のルールに従ってファイルを振り分ける例として、"レビュー資料"で始まる５つのファイルと"新商品企画書"で始まる３つのファイルとを使用する。
図１１は、図６と同じくバージョン一括登録画面の一例を示す図である。図１１では、登録対象ファイルリスト部１１０１に図１０の８つのファイルが追加された状態を示している。ファイルの振り分け方法指定部１１０２は、"規定のルールに従う"が選択された状態である。この状態でユーザが実行ボタンをクリック（又は押下）すると、ＰＣ１０１からファイルの属性を含んだファイルリスト、振り分け方法、全ファイルの実体を含むバージョン一括登録要求が、文書管理システム１０６に送信される。
【００２８】
図１２は、図１１においてユーザによって実行ボタンがクリックされ、文書管理システム１０６においてバージョン一括登録処理が実行された結果の文書一覧表示画面の一例を示す図である。ファイルの振り分け方法指定部１１０２で、ユーザがルールに従うよう指定したため、図９で設定されたルールに従ってファイルが振り分けられている。ファイル振り分けルール設定部９０１に従い、ファイル名の先頭６文字と拡張子が等しいファイルが同一の文書のバージョンとして登録され、２つの文書が新規に登録されている。文書名決定ルール設定部９０３に従い、ファイル名の先頭６文字である、"レビュー資料"と"新商品企画書"が文書名に設定されている。また、"レビュー資料"のバージョン数は５、"新商品企画書"のバージョン数は３で振り分けられている。図１２において、ユーザが文書選択ボックス１２０２で"新商品企画書"を選択し、バージョン一覧表示ボタン１２０３をクリックすると、図１３のバージョン一覧表示画面１３００がＰＣ１０１上に表示される。
【００２９】
図１３は、図８と同じくバージョン一覧表示画面の一例を示す図である。図１３では、図１１の操作により、３つのファイルが"新商品企画書"のバージョンとして登録された結果を示している。表示されている各項目の内容に関しては図８と同様である。図９のソート順設定部９０２に従い、各ファイルの更新日時の昇順、つまり古いファイルからバージョンが追加されている。"レビュー資料"に関しては、図８と同じく５つのバージョンがルールに従い登録されているが、ここでは説明を省略する。
【００３０】
次に、既存の文書に対して、少なくとも１つ以上のファイルをバージョンとして一括して追加する例を説明する。特に、既存のバージョンに、追加対象のファイルと同じものが存在していた場合、文書管理システム１０６が、重複して追加しない例を示す。つまり、図９の重複ファイル取り扱い指定部９０４において、重複ファイルは登録しない設定がされていた場合の例を示す。
図１３においてユーザが、バージョン一括登録ボタン１３０２をクリックするか、図１２において文書選択ボックス１２０２で"新商品企画書"を選択し、バージョン一括登録ボタン１２０４をクリックする。すると、ＰＣ１０１は、図１４のバージョン一括登録画面１４００を表示する。
【００３１】
図１４は、図１１と同じくバージョン一括登録画面の一例を示す図である。図１４では、既に登録済みのファイルと新規に登録するファイルとの２つのファイルが登録対象ファイルリストに追加されていることを示している。既存の文書にバージョンを追加登録する場合、ファイル振り分け方法指定部１４０３は、「規定のルールに従う」だけを選択可能とする。つまり、図９で設定した追加登録時の重複ファイル取り扱い指定部９０４のルールが適用される。なお、複数のファイルを既存の複数文書に振り分けるルールを規定しておいて、ユーザが複数のファイルを選択した場合、文書管理システム１０６が選択された複数のファイルを既存の複数文書に振り分けるようにしてもよい。
図１４において、実行ボタンがクリックされると、ＰＣ１０１からファイルの属性を含んだファイルリスト、振り分け方法、全ファイルの実体を含んだバージョン一括登録要求が文書管理システム１０６に送信される。なお、ＰＣ１０１は、これらの情報を、複数のデータに分割し、順次、文書管理システム１０６に送信するようにしてもよい。
【００３２】
図１５は、図１４において実行ボタンがクリックされ、既存の文書に対してバージョン一括登録が実行された結果のバージョン一覧表示画面の一例を示す図である。バージョン一覧表示部１５０１の、既存のバージョンと同じファイルである"新商品企画書０９１４"は、重複ファイルを追加しないルールに従ってバージョンには追加されていない。バージョン番号が４の"新商品企画書０９２９"のみが追加されたことを示している。ここでは省略するが、図１４において実行ボタンがクリックされ、既存の文書に対してバージョン一括登録が実行された結果、図１２の文書一覧表示部１２０１に表示される"新商品企画書"のバージョン数も４に更新される。
【００３３】
次にフローチャートを使用して、文書管理システム内の処理を説明する。図１６は、図６、図１１、図１４等を介してユーザがバージョン一括登録の実行を指示した際の文書管理システム側の処理の一例を示したフローチャートである。バージョン一括登録画面において、ユーザが実行ボタンをクリックすると、ＰＣ１０１のＷｅｂブラウザ１０２は、文書管理システム１０６に対して、バージョン一括登録要求を送信する。バージョン一括登録要求と共に送信されるデータは、バージョン一括登録画面までのユーザによる画面操作に依存する。
ステップＳ１６００において、文書管理システム１０６内のバージョン一括登録要求受信部１０７は、バージョン一括登録要求を受信すると、受信データの内容を判別する。
ステップＳ１６０１において、バージョン一括登録要求受信部１０７は、受信データ内に既存の文書の識別子（識別情報）が含まれているか否かを判定する。受信データ内に既存の文書の識別子が含まれていない、即ち新規に文書を登録する場合、バージョン一括登録要求受信部１０７は、処理をステップ１６０２に進める。一方、受信データ内に既存の文書の識別子が含まれている、即ち既存の文書にバージョンを追加する場合、バージョン一括登録要求受信部１０７は、処理をステップＳ１６１２に進める。
【００３４】
ステップＳ１６０２において、バージョン一括登録要求受信部１０７は、受信データを判別し、文書名が含まれているか否かを判定する。文書名が含まれている、即ち受信した全てのファイルを１つの文書のバージョンとして登録する場合、バージョン一括登録要求受信部１０７は、処理をステップＳ１６０３に進める。文書名が含まれていない、即ち規定のルールに従って文書とバージョンを振り分ける場合、バージョン一括登録要求受信部１０７は、ステップＳ１６０４に処理を進める。
ステップＳ１６０３において、バージョン一括登録要求受信部１０７は、受信データ内のファイルリストから登録する文書の情報とファイルの属性と並び順とを取得し、ＲＡＭ２０２に展開する。同時に、バージョン一括登録要求受信部１０７は、受信したファイル（実ファイル）をＨＤＤ２０９の一時記憶域に格納する。
【００３５】
ステップＳ１６０５において、文書登録部１０８は、ＲＡＭ２０２に展開された情報から新規に登録が必要な文書があるか否かを判別する。ステップＳ１６０３からステップＳ１６０５に進んだ場合、１つの文書の登録が必要であるため、文書登録部１０８は、処理をステップＳ１６０６に進める。
ステップＳ１６０６において、文書登録部１０８は、新規に登録する文書の情報をＲＡＭ２０２から読み出して、文書／バージョン情報記憶部１１３に格納する。また同時に文書登録部１０８は、必要な文書属性（文書属性情報）をＲＡＭ２０２から読み出して、文書属性記憶部１１４に格納する。
ステップＳ１６０７において、バージョン登録部１１０は、ＲＡＭ２０２に展開された情報からバージョンとして追加するファイルが残っているか否かを判別する。バージョン登録部１１０は、残っている場合、処理をステップＳ１６０８に進め、残っていない場合、処理をステップＳ１６０５に戻す。ここでは文書を新規に登録しただけであるので、バージョン登録部１１０は、処理をステップＳ１６０８に進める。
【００３６】
ステップＳ１６０８において、ファイル属性抽出部１０９は、ＨＤＤ２０９の一時記憶域に格納されたファイルを読み出して、ファイルの最終更新者属性（最終更新者情報）を抽出し、ＲＡＭ２０２に展開する。
ステップＳ１６０９において、バージョン登録部１１０は、一時的に該当する文書をチェックアウト状態にするために、文書属性記憶部１１４の情報を更新する。
ステップＳ１６１０において、バージョン登録部１１０は、ＨＤＤ２０９の一時記憶域に格納されたファイルを読み出して、文書／バージョン情報記憶部１１３に格納する。同時にバージョン登録部１１０は、前記文書をチェックイン状態に戻すために、文書属性記憶部１１４の情報を更新する。
【００３７】
ステップＳ１６１１において、バージョン登録部１１０は、ＲＡＭ２０２から最終更新者等のファイルの属性を読み出し、バージョン属性記憶部１１５に格納する。
次にバージョン登録部１１０は、処理をステップＳ１６０７に戻す。受信ファイル全てに対して、ステップＳ１６０８からステップＳ１６１１までの処理を繰り返す。文書管理システム１０６は、全てのファイルの処理が完了した場合、処理をステップＳ１６０５に戻すが、１つの文書が登録されるケースにおいてはここで図１６に示す処理を終了する。
上記の処理フローの結果として、例えば、バージョン一括登録結果が文書管理システム１０６からＰＣ１０１に送信される。そして、ＰＣ１０１は、バージョン一括登録結果を受信し、受信したバージョン一括登録結果に基づき、図７の文書一覧表示画面及び図８のバージョン一覧表示画面等を表示する。
【００３８】
次に規定のルールに従って処理を行う処理フローに関して説明する。
ステップＳ１６０４において、バージョン一括登録要求受信部１０７は、受信データ内のファイルリストから登録する文書の情報とファイルの属性とを取得し、ＲＡＭ２０２に展開する。同時に、バージョン一括登録要求受信部１０７は、受信したファイルをＨＤＤ２０９の一時記憶域に格納する。また、バージョン振り分け部１１１は、振り分けルール記憶部１１６から文書及びバージョンの振り分けルールを取得する。バージョン振り分け部１１１は、取得した振り分けルールを基にして、ＲＡＭ２０２に展開されたファイルリストの情報から振り分け処理を実行し、振り分け結果をＲＡＭ２０２に展開する。
【００３９】
以降、文書管理システム１０６は、ステップＳ１６０５からＳ１６１１までの処理を、振り分け結果に応じて、文書及びバージョンの数だけ繰り返す。ステップＳ１６０５で文書登録部１０８が、登録が必要な文書がないと判別した場合、図１６に示す処理を終了する。
上記の処理フローの結果として、例えば、バージョン一括登録結果が文書管理システム１０６からＰＣ１０１に送信される。そして、ＰＣ１０１は、バージョン一括登録結果を受信し、受信したバージョン一括登録結果に基づき、図１２の文書一覧表示画面及び図１３のバージョン一覧表示画面等を表示する。
【００４０】
次に既存の文書にバージョンを追加する処理フローに関して説明する。
ステップＳ１６１２において、バージョン一括登録要求受信部１０７は、受信データ内のファイルリストから既存の文書の識別子と登録するファイルの属性を取得し、ＲＡＭ２０２に展開する。同時に、バージョン一括登録要求受信部１０７は、受信したファイルをＨＤＤ２０９の一時記憶域に格納する。
また、バージョン振り分け部１１１は、振り分けルール記憶部１１６からバージョンの振り分けルールのうち、ソート順と重複ファイルの取り扱いの情報とを取得する。バージョン振り分け部１１１は、取得した情報を基にして、ＲＡＭ２０２に展開されたファイルリストの情報からソート処理を実行し、ソート結果と重複ファイルの取り扱い情報とをＲＡＭ２０２に展開する。
【００４１】
ステップＳ１６１３において、バージョン登録部１１０は、ＲＡＭ２０２に展開された情報からバージョンとして追加するファイルが残っているか否かを判別する。バージョン登録部１１０は、残っている場合、処理をステップＳ１６１４に進め、残っていない場合、図１６に示す処理を終了する。本実施形態ではバージョン登録部１１０は、処理をステップＳ１６１４に進める。
ステップＳ１６１４において、バージョン登録部１１０は、ＲＡＭ２０２に展開された重複ファイルの取り扱い情報を取得し、バージョン内の重複ファイルは登録不要か否か、判別を行う。バージョン登録部１１０は、重複ファイルも登録するルールであった場合、処理をステップＳ１６１７に進め、重複ファイルは登録しないルールであった場合、処理をステップＳ１６１５に進める。ここでは、重複ファイルは登録しない設定であるため、バージョン登録部１１０は、処理をステップＳ１６１５に進める。
【００４２】
ステップＳ１６１５において、ファイル属性抽出部１０９は、ＨＤＤ２０９の一時記憶域から該当するファイルを取得し、ファイルのハッシュ値を計算する。ハッシュ値の計算手法は公知の技術であるため詳細は省略するが、ハッシュ値は３２桁の１６進数で表されるものが最も一般的である。ファイル属性抽出部１０９は、取得したハッシュ値をＲＡＭ２０２に展開する。
ステップＳ１６１６において、バージョン登録部１１０は、バージョン属性記憶部１１５から該当する文書に属する全バージョンのハッシュ値を取得し、追加するファイルのハッシュ値と等しいバージョンが存在するか否かを判別する。存在している場合、バージョン登録部１１０は、処理をステップＳ１６１３に戻し、該当するファイルをバージョンとして追加しない。存在してない場合、バージョン登録部１１０は、処理をステップＳ１６１７に進める。
ステップＳ１６１７からステップＳ１６２０までの処理は、Ｓ１６０８からＳ１６１１までの処理と同じであるため説明を省略する。
【００４３】
上記の処理フローの結果として例えば、バージョン一括登録結果が文書管理システム１０６からＰＣ１０１に送信される。そして、ＰＣ１０１は、バージョン一括登録結果を受信し、受信したバージョン一括登録結果に基づき、１５のバージョン一覧表示画面を表示する。つまり、図１４のバージョン一括登録の実行時には、１つのファイルは追加され、１つのファイルは追加されない。
【００４４】
図１７と図１８とは、文書属性及びバージョン属性のデータ例を示した図である。図１７と図１８とは、図７の文書一覧表示画面に示した文書と図８のバージョン一覧表示画面に示したバージョンとのうち、Ｎｏ．１からＮｏ．３までのバージョンのデータに対応している。文書データとバージョンデータ（バージョン情報）とは、文書識別子をキーに関連付けがされている。バージョンデータには、バージョン番号や拡張子、ファイルサイズ、ファイルのハッシュ値等の情報が含まれている。なお、この例は最低限必要な情報であり、本実施形態を実現する上では異なるデータ構成であってもよい。
以上により、バージョン管理がされていないファイルシステム上の複数のファイルを１つの文書として一括登録することが可能になる。また、各バージョンの最終更新者を把握できるようにもなる。更に、既に同じファイルが同じ文書内に存在している場合、ファイルを追加しないことも可能になる。
【００４５】
＜その他の実施形態＞
また、本発明の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置の中央演算処理手段（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行する。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記憶媒体は本発明を構成することになる。
【００４６】
また、システム或いは装置の前記中央演算処理手段が読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、システム或いは装置上で稼働しているオペレーティングシステム（ＯＳ）等が実際の処理の一部又は全部を行う。その処理によって上述した実施形態の機能が実現される場合も含まれる。
【００４７】
更に、記憶媒体から読み出されたプログラムコードが、前記システム或いは装置に挿入された機能拡張カードや、接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。
【００４８】
本発明を前記記憶媒体に適用する場合、その記憶媒体（コンピュータ読み取り可能な記憶媒体）には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【００４９】
以上、上述した各実施形態によれば、複数のファイルを一つの文書のバージョンに容易にまとめることを可能にすると共に、バージョンの更新者に関する情報を設定可能にすることができる。
【００５０】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【００５１】
【図１】文書管理システムとクライアントコンピュータとの概略構成の一例を示す図である。
【図２】文書管理システムやクライアントコンピュータのハードウェア構成の一例を示す図である。
【図３】文書管理メイン画面の一例を示す図である。
【図４】ＰＣ１０１内のファイル保存部１０５に記憶されているファイルの一覧を表示する画面の一例を示す図である。
【図５】文書一覧表示部３０２において文書登録ボタンがクリックされ、ＰＣ１０１が図４の５つのファイルを登録実行した後の画面の一例を示す図である。
【図６】バージョン一括登録画面の一例を示す図である。
【図７】ユーザが図６において実行ボタン６０４をクリックし、バージョン一括登録を実行した結果の文書一覧表示画面の一例を示す図である。
【図８】バージョン一覧表示画面の一例を示す図である。
【図９】予め文書を振り分けるルールを設定するための、振り分けルール設定画面の一例を示す図である。
【図１０】ＰＣ１０１内のファイル保存部１０５に記憶されているファイル一覧の画面の一例を示す図である。
【図１１】図６と同じくバージョン一括登録画面の一例を示す図である。
【図１２】図１１においてユーザによって実行ボタンがクリックされ、文書管理システム１０６においてバージョン一括登録処理が実行された結果の文書一覧表示画面の一例を示す図である。
【図１３】図８と同じくバージョン一覧表示画面の一例を示す図である。
【図１４】図１１と同じくバージョン一括登録画面の一例を示す図である。
【図１５】図１４において実行ボタンがクリックされ、既存の文書に対してバージョン一括登録が実行された結果のバージョン一覧表示画面の一例を示す図である。
【図１６】図６、図１１、図１４等を介してユーザがバージョン一括登録の実行を指示した際の文書管理システム側の処理の一例を示したフローチャートである。
【図１７】文書属性及びバージョン属性のデータ例を示した図（その１）である。
【図１８】文書属性及びバージョン属性のデータ例を示した図（その２）である。
【符号の説明】
【００５２】
１００  ネットワーク
１０１  クライアントコンピュータ
１０２  Ｗｅｂブラウザ
１０３  ファイル選択部
１０４  文書情報設定部
１０５  ファイル保存部
１０７  バージョン一括登録要求受信部
１０８  文書登録部
１０９  ファイル属性抽出部
１１０  バージョン登録部
１１１  バージョン振り分け部
１１２  バージョン振り分けルール設定部
１１３  文書／バージョン情報記憶部
１１４  文書属性記憶部
１１５  バージョン属性記憶部
１１６  振り分けルール記憶部
【図１】
2010020645.tif 000003
【図２】
2010020645.tif 000004
【図３】
2010020645.tif 000005
【図４】
2010020645.tif 000006
【図５】
2010020645.tif 000007
【図６】
2010020645.tif 000008
【図７】
2010020645.tif 000009
【図８】
2010020645.tif 000010
【図９】
2010020645.tif 000011
【図１０】
2010020645.tif 000012
【図１１】
2010020645.tif 000013
【図１２】
2010020645.tif 000014
【図１３】
2010020645.tif 000015
【図１４】
2010020645.tif 000016
【図１５】
2010020645.tif 000017
【図１６】
2010020645.tif 000018
【図１７】
2010020645.tif 000019
【図１８】
2010020645.tif 000020