(57)【要約】【課題】文書に関する方式的な要件不備を効果的に抑止することを課題とする。【解決手段】端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、原本ファイルと原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持し、端末が文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、受信済原本ファイルが属するグループに関する情報として端末が文書管理サーバから受信済原本ファイルとともに予め受信することで保持していた情報を、端末から受信し、受信された受信済原本ファイルのグループに関する情報と、保持される受信済原本ファイルのグループに関する情報とを比較することで、受信済原本ファイルが現に属するグループに変更があったか否かを判定し、判定結果を端末に送信する。【選択図】        図１
2008250943.tif 000002
【特許請求の範囲】
【請求項１】
文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する方法を、前記文書管理サーバとしてのコンピュータに実行させる文書管理サーバプログラムであって、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手順と、
前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手順と、
前記グループ情報受信手順によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手順によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手順と、
前記判定手順によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手順と、
を前記文書管理サーバとしてのコンピュータに実行させることを特徴とする文書管理サーバプログラム。
【請求項２】
前記保持手順は、前記原本ファイルを識別する原本識別子と、前記グループに関する情報として、当該原本識別子によって識別される原本ファイルが現に属するグループを識別するグループ識別子、および、当該グループ識別子によって識別されるグループに現に属する原本ファイルを識別する原本識別子のリストとを対応づけ可能に保持し、
前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記リストと、前記保持手順によって保持される前記受信済原本ファイルの前記リストとを比較することで、当該受信済原本ファイルが現に属するグループについて、当該グループに属している原本ファイルに分割が行われたこと、あるいは、当該グループに属している原本ファイルに統合が行われたことを判定し、
前記変更情報送信手順は、前記原本ファイル変更情報として、分割、あるいは、統合を示す情報を送信することを特徴とする請求項１に記載の文書管理サーバプログラム。
【請求項３】
前記保持手順は、前記原本ファイルと前記原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する他に、当該原本ファイルを更新した日時に関する情報をさらに保持し、
前記グループ情報受信手順は、前記端末が前記文書管理サーバから前記受信済原本ファイルとともに予め受信することで保持していた情報として、当該受信済原本ファイルの日時に関する情報をさらに受信し、
前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記日時に関する情報と、前記保持手順によって保持される前記受信済原本ファイルを更新した日時に関する情報とを比較することで、当該受信済原本ファイルに改訂が行われたか否かをさらに判定し、
前記変更情報送信手順は、前記原本ファイル変更情報として、改訂を示す情報をさらに送信することを特徴とする請求項１または２に記載の文書管理サーバプログラム。
【請求項４】
前記グループ情報受信手順は、前記端末において前記受信済原本ファイルとともに予め受信することで保持されていたマクロが、当該端末で実行されることで前記情報を受信し、
前記判定手順は、前記マクロが前記端末で実行されることで判定すること特徴とする請求項１〜３のいずれか一つに記載の文書管理サーバプログラム。
【請求項５】
文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する文書管理サーバであって、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手段と、
前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手段と、
前記グループ情報受信手段によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手段によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手段と、
前記判定手段によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手段と、
を備えたことを特徴とする文書管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、文書管理サーバプログラム、および文書管理サーバに関する。
【背景技術】
【０００２】
従来より、日常業務の一つとして、社内定型フォーマットによる各種申請などが盛んに行われており、これを支援する技術として、文書管理システムなどが存在する。ここで、文書管理システムとは、ファイルサーバたる文書管理サーバが雛形文書（以下、原本ファイル）を格納することで、原本ファイルの版数の管理や原本ファイルの共有化などを実現しているシステムのことである。
【０００３】
具体的に例を挙げて説明すると、例えば、文書管理システムの利用者は、用途ごとに適合する原本ファイルを各自のローカルマシンにダウンロード（コピー）し、ダウンロードした原本ファイルを用いて具体的な内容を記載することにより、文書を完成させる。ところで、例えば、社内規約の見直しなどに伴って、原本ファイルのフォーマットが改訂された場合には、文書管理サーバは、その都度、最新版の原本ファイルを格納することになる。この場合、利用者は、利用の都度、文書管理サーバから原本ファイルをダウンロードすることで、最新版の原本ファイルによる文書を作成している。
【０００４】
例えば、特許文献１には、文書管理システムである帳票申請システムが開示されているが、このシステムにおいて、原本ファイルのフォーマットが改訂された場合には、帳票申請サーバは、その都度、最新版の原本ファイルを格納し、申請者は、申請の都度、帳票申請サーバから原本ファイルをダウンロードすることで、最新版の原本ファイルによる申請書を作成している。また、例えば、特許文献２には、クライアントのファイルを、サーバからの情報により更新することを目的としたプログラム更新方式が開示されているが、この方式において、クライアントは、ファイルの版数（バージョン）情報をチェックし、チェックの結果に応じて、最新のバージョンのファイルをダウンロードするなどしている。
【０００５】
【特許文献１】特開２００３−１５０８９３号公報
【特許文献２】特開平１１−９５９８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、上記した従来の技術では、以下に説明するように、文書に関する方式的な要件不備を効果的に抑止することができないという課題があった。
【０００７】
まず、特許文献１に開示されている手法では、申請者は、申請の都度、帳票申請サーバから原本ファイルをダウンロードすることで、最新版の原本ファイルによる申請書を作成することから、確かに、文書に関する方式的な要件不備を抑止することはできる。しかしながら、例えば、帳票申請システムについて考えてみるとわかるように、申請内容にはほぼ同じ内容の記述をすることが多く、一部の修正で新たな申請書を作成することができるので、一旦過去に作成した申請書を流用することにより、日常業務の合理化（生産性および品質の向上など）が行われているのが一般的であるのに対し、特許文献１に開示されている手法は、このような流用を想定するものではなく、文書に関する方式的な要件不備を効果的に抑止するものではない。
【０００８】
また、特許文献２に開示されている手法によっても、文書に関する方式的な要件不備を効果的に抑止することができない。すなわち、例えば、社内規約の見直しに伴って原本ファイルが改訂されたとして、改訂の前後において、申請に必要な全ての原本が一対一対応しているとは限らないことから、クライアントにおいて編集しようとする申請ファイルの版数とサーバの版数とを比較するのみでは、改訂後の申請に必要な条件を全て満たしているか否かを判断することができない場合がある。言い換えると、例えば、複数の申請ファイルを添付して一つの申請を処理していた業務が、申請処理の合理化により、一つの申請ファイルに統合される場合がある。また、例えば、一つの申請ファイルで申請を処理していた業務が、申請内容の多様化又は監査基準の変更に伴い、複数の申請ファイルの添付を要求する場合がある。このような場合に、編集しようとする申請ファイルの版数のみを確認する特許文献２に開示されている手法では、添付すべき申請ファイルについて要件を具備しているか否かの判断ができず、結局、文書に関する方式的な要件不備を効果的に抑止することができない。
【０００９】
なお、上記したような課題は、帳票申請システムに限られず、あらゆる文書管理システムにおいて同様に課題となりうるものである。
【００１０】
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、文書に関する方式的な要件不備を効果的に抑止することが可能な文書管理サーバプログラム、および文書管理サーバを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、請求項１に係る発明は、文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する方法を、前記文書管理サーバとしてのコンピュータに実行させる文書管理サーバプログラムであって、前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手順と、前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手順と、前記グループ情報受信手順によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手順によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手順と、前記判定手順によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手順と、を前記文書管理サーバとしてのコンピュータに実行させることを特徴とする。
【００１２】
また、請求項２に係る発明は、上記の発明において、前記保持手順は、前記原本ファイルを識別する原本識別子と、前記グループに関する情報として、当該原本識別子によって識別される原本ファイルが現に属するグループを識別するグループ識別子、および、当該グループ識別子によって識別されるグループに現に属する原本ファイルを識別する原本識別子のリストとを対応づけ可能に保持し、前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記リストと、前記保持手順によって保持される前記受信済原本ファイルの前記リストとを比較することで、当該受信済原本ファイルが現に属するグループについて、当該グループに属している原本ファイルに分割が行われたこと、あるいは、当該グループに属している原本ファイルに統合が行われたことを判定し、前記変更情報送信手順は、前記原本ファイル変更情報として、分割、あるいは、統合を示す情報を送信することを特徴とする。
【００１３】
また、請求項３に係る発明は、上記の発明において、前記保持手順は、前記原本ファイルと前記原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する他に、当該原本ファイルを更新した日時に関する情報をさらに保持し、前記グループ情報受信手順は、前記端末が前記文書管理サーバから前記受信済原本ファイルとともに予め受信することで保持していた情報として、当該受信済原本ファイルの日時に関する情報をさらに受信し、前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記日時に関する情報と、前記保持手順によって保持される前記受信済原本ファイルを更新した日時に関する情報とを比較することで、当該受信済原本ファイルに改訂が行われたか否かをさらに判定し、前記変更情報送信手順は、前記原本ファイル変更情報として、改訂を示す情報をさらに送信することを特徴とする。
【００１４】
また、請求項４に係る発明は、上記の発明において、前記グループ情報受信手順は、前記端末において前記受信済原本ファイルとともに予め受信することで保持されていたマクロが、当該端末で実行されることで前記情報を受信し、前記判定手順は、前記マクロが前記端末で実行されることで判定すること特徴とする。
【００１５】
また、請求項５に係る発明は、文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する文書管理サーバであって、前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手段と、前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手段と、前記グループ情報受信手段によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手段によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手段と、前記判定手段によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手段と、を備えたことを特徴とする。
【発明の効果】
【００１６】
請求項１または５の発明によれば、文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する方法を、前記文書管理サーバとしてのコンピュータに実行させる文書管理サーバプログラムであって、端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、原本ファイルと原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持し、端末が文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、受信済原本ファイルが属するグループに関する情報として端末が文書管理サーバから受信済原本ファイルとともに予め受信することで保持していた情報を、端末から受信し、受信された受信済原本ファイルのグループに関する情報と、保持される受信済原本ファイルのグループに関する情報とを比較することで、受信済原本ファイルが現に属するグループに変更があったか否かを判定し、判定された判定結果を、原本ファイル変更情報として端末に送信するので、文書に関する方式的な要件不備を効果的に抑止することが可能になる。
【００１７】
また、請求項２の発明によれば、原本ファイルを識別する原本識別子と、グループに関する情報として、原本識別子によって識別される原本ファイルが現に属するグループを識別するグループ識別子、および、グループ識別子によって識別されるグループに現に属する原本ファイルを識別する原本識別子のリストとを対応づけ可能に保持し、受信された受信済原本ファイルのリストと、保持される受信済原本ファイルのリストとを比較することで、受信済原本ファイルが現に属するグループについて、グループに属している原本ファイルに分割が行われたこと、あるいは、グループに属している原本ファイルに統合が行われたことを判定し、原本ファイル変更情報として、分割、あるいは、統合を示す情報を送信するので、文書に関する方式的な要件不備として、原本ファイルの分割や統合による要件不備を効果的に抑止することが可能になる。
【００１８】
また、請求項３の発明によれば、原本ファイルと原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する他に、原本ファイルを更新した日時に関する情報をさらに保持し、端末が文書管理サーバから受信済原本ファイルとともに予め受信することで保持していた情報として、受信済原本ファイルの日時に関する情報をさらに受信し、受信された受信済原本ファイルの日時に関する情報と、保持される受信済原本ファイルを更新した日時に関する情報とを比較することで、受信済原本ファイルに改訂が行われたか否かをさらに判定し、原本ファイル変更情報として、改訂を示す情報をさらに送信するので、文書に関する方式的な要件不備として、原本ファイルの改訂による要件不備を効果的に抑止することが可能になる。
【００１９】
また、請求項４の発明によれば、端末において受信済原本ファイルとともに予め受信することで保持されていたマクロが、端末で実行されることで情報を受信し、マクロが端末で実行されることで判定するので、文書に関する方式的な要件不備を効果的かつ簡易に抑止することが可能になる。
【発明を実施するための最良の形態】
【００２０】
以下に添付図面を参照して、本発明に係る文書管理サーバプログラム、および文書管理サーバの実施例を詳細に説明する。なお、以下では、文書管理サーバとしての「帳票申請サーバ」と端末としての「帳票申請端末」とで構成される「帳票申請システム」を実施例として説明するが、本発明はこれに限られるものではなく、文書の原本である原本ファイルを管理する文書管理サーバと、文書管理サーバから受信した原本ファイルを利用する端末とで構成される文書管理システムであれば、本発明を同様に適用することができる。まず、実施例１に係る文書管理システム（帳票申請システム）の概要および特徴を説明し、次に、実施例１に係る文書管理システム（帳票申請システム）の構成、実施例１に係る文書管理システム（帳票申請システム）による処理の手順、実施例１の効果を説明し、続いて、他の実施例について説明する。
【実施例１】
【００２１】
［実施例１に係る文書管理システム（帳票申請システム）の概要および特徴］
まず、図１を用いて、実施例１に係る文書管理システム（帳票申請システム）の概要および特徴を説明する。図１は、実施例１に係る文書管理システム（帳票申請システム）の概要および特徴を説明するための図である。なお、以下の実施例では、一つの帳票申請サーバと、一つの帳票申請端末とで構成される帳票申請システムについて説明するが、本発明はこれに限られるものではなく、例えば、一つの帳票申請サーバと、複数の帳票申請端末とで構成される帳票申請システムなど、その他の構成の帳票申請システムなどにも、本発明を同様に適用することができる。
【００２２】
実施例１における帳票申請システムは、帳票の原本である原本ファイルを管理する帳票申請サーバと、帳票申請サーバから受信した所定の原本ファイルを利用する帳票申請端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更（例えば、分割を伴う改訂、統合を伴う改訂など）に関する情報である原本ファイル変更情報を、帳票申請サーバが帳票申請端末に送信することを概要とし、帳票に関する方式的な要件不備を効果的に抑止することを主たる特徴とする。
【００２３】
この主たる特徴について簡単に説明すると、実施例１における帳票申請システムは、図１に示すように、帳票申請サーバと帳票申請端末とが通信可能に接続されている。また、帳票申請サーバは、記憶部に、帳票申請端末において共に利用されるべき複数の原本ファイルを、同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持している。
【００２４】
例えば、図１の例で説明すると、帳票申請サーバは、図１の（Ａ）の段階においては、記憶部に、原本ファイル「旅費申請書」について、帳票申請端末において共に利用されるべき原本ファイルが他にないことから、「旅費申請書」と、「旅費申請書」が現に属するグループに関する情報として『グループＩＤ』「0002」とを対応づけ可能に保持している。また、帳票申請サーバは、図１の（Ｂ）の段階（図１の（Ａ）の段階から所定の時間が経過したものとする）においては、記憶部に、帳票申請端末において共に利用されるべき複数の原本ファイルとして「旅費申請書」および「旅券添付書」と、当該「旅費申請書」および「旅券添付書」が現に属するグループに関する情報として『グループＩＤ』「0002」とを対応づけ可能に保持している。つまり、図１の例では、図１の（Ａ）の段階においては、「旅費申請書」は、「旅費申請書」のみで利用されればよい帳票であったが、図１の（Ｂ）の段階においては、「旅費申請書」および「旅券添付書」が共に利用されなければならない帳票に変更されたことになる。なお、図１の例では、説明の便宜上から、帳票申請サーバが記憶部に一つの原本ファイルのグループを保持する事例を例示したが、当然ながら、帳票申請サーバが記憶部に多数の原本ファイルのグループを保持する事例にも、本発明を同様に適用することができる。
【００２５】
ところで、図１の（Ａ）の段階において、帳票申請端末は、帳票申請サーバから、「旅費申請書」を予め受信している。また、帳票申請端末は、当該「旅費申請書」が属するグループに関する情報として、例えば、『グループＩＤ』「0002」を保持している。すなわち、図１の（Ａ）の段階においては、「旅費申請書」は、「旅費申請書」のみで利用されればよい帳票であったことから、この段階で「旅費申請書」をダウンロードした帳票申請端末は、「旅費申請書」のみと『グループＩＤ』「0002」とを対応づけて保持している。その後、帳票申請端末は、ダウンロードした「旅費申請書」に申請内容を記載するなどして、当該「旅費申請書」を利用することになる。
【００２６】
このような構成のもと、所定の時間が経過して、図１の（Ｂ）の状態になったとする。つまり、上記したように、図１の（Ｂ）の段階においては、「旅費申請書」および「旅券添付書」が共に利用されなければならない帳票に変更されたことから、帳票申請サーバは、図１の（Ｂ）に示すように、記憶部に、帳票申請端末において共に利用されるべき複数の原本ファイルとして「旅費申請書」および「旅券添付書」と、当該「旅費申請書」および「旅券添付書」が現に属するグループに関する情報として『グループＩＤ』「0002」とを対応づけ可能に保持している。
【００２７】
ここで、帳票申請端末は、過去（図１の（Ａ）の段階）に申請内容を記載するなどして利用した「旅費申請書」を流用することを目的として、まず、帳票申請サーバから予め受信していた原本ファイル（当該原本ファイルに申請内容を記入したものを含む）である受信済原本ファイルについて、受信済原本ファイルが属するグループに関する情報として、帳票申請端末が帳票申請サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、帳票申請サーバに送信する。
【００２８】
例えば、帳票申請端末は、図１の（Ｂ）の（１）に示すように、受信済原本ファイル「旅費申請書」について、グループに関する情報として、『原本ＩＤ』「0002」と『グループＩＤ』「0002」とを、帳票申請サーバに送信する。
【００２９】
すると、帳票申請サーバは、かかる情報を受信して、次に、帳票申請端末から受信したグループに関する情報と、記憶部に保持する受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する。つまり、帳票申請サーバが記憶部に保持するグループに関する情報とは、原本ファイルが「現に」属するグループに関する情報であることから、帳票申請端末から受信した「過去」のグループに関する情報と比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定することができるのである。
【００３０】
例えば、帳票申請サーバは、図１の（Ｂ）の（２）に示すように、帳票申請端末から受信した『原本ＩＤ』「0002」および『グループＩＤ』「0002」と、記憶部に保持する『原本ＩＤ』「0002」が現に属する『グループＩＤ』「0002」に『原本ＩＤ』「0005」が追加されていることを示す情報とを比較することで、当該「旅費申請書」が現に属するグループ『グループＩＤ』「0002」に変更があったこと（分割を伴う改訂が行われたこと）を判定する。
【００３１】
そして、帳票申請サーバは、判定された判定結果を、原本ファイルの変更に関する情報である原本ファイル変更情報として、帳票申請端末に送信する。例えば、帳票申請サーバは、図１の（Ｂ）の（３）に示すように、「『旅費申請書』が現に属するグループには、『分割を伴う改訂』がありました。」といった内容の原本ファイル変更情報を、帳票申請端末に送信する。
【００３２】
このようなことから、実施例１における帳票申請システムは、帳票申請端末において、原本ファイルが現に属するグループに変更があったことを認識することができるようになり、帳票に関する方式的な要件不備を効果的に抑止することが可能になる。
【００３３】
［実施例１に係る文書管理システム（帳票申請システム）の構成］
続いて、図２〜図７を用いて、実施例１に係る文書管理システムの構成を説明する。図２は、実施例１に係る文書管理システムの構成を示すブロック図であり、図３は、原本記憶部を説明するための図であり、図４は、原本管理情報記憶部を説明するための図であり、図５は、外部定義記憶部を説明するための図であり、図６は、申請書記憶部を説明するための図であり、図７は、申請書記憶部を説明するための図である。
【００３４】
図２に示すように、帳票申請システムは、帳票申請サーバ１００と帳票申請端末２００とが、ネットワーク３００を介して通信可能に接続されて構成されている。
【００３５】
［帳票申請サーバ１００］
帳票申請サーバ１００は、入力部１１１と、出力部１１２と、入出力制御Ｉ／Ｆ部１１３と、通信部１１４と、記憶部１２０と、制御部１３０とから構成される。
【００３６】
入力部１１１は、制御部１３０による各種処理に用いるデータや、各種処理をするための操作指示などを、キーボード、マウス、または記憶媒体などによって入力する。出力部１１２は、制御部１３０による各種処理の結果や、各種処理をするための操作指示などを、モニタ、またはプリンタなどに出力する。入出力制御Ｉ／Ｆ部１１３は、入力部１１１および出力部１１２と、記憶部１２０および制御部１３０との間におけるデータ転送を制御する。通信部１１４は、帳票申請端末２００や図示しない管理者端末４００とネットワーク３００を介して通信する。具体的には、通信部１１４は、帳票申請端末２００による申請に関する通信や、管理者端末４００による原本ファイルの登録に関する通信などを行う。
【００３７】
記憶部１２０は、制御部１３０による各種処理に用いるデータを記憶する。特に本発明に密接に関連するものとしては、図２に示すように、原本記憶部１２１と、原本管理情報記憶部１２２とを備える。なお、原本記憶部１２１および原本管理情報記憶部１２２は、特許請求の範囲に記載の「保持手順」に対応する。
【００３８】
原本記憶部１２１は、帳票の原本である原本ファイルを記憶する。具体的には、原本記憶部１２１は、帳票申請システムの運用開始前などに、入力部１１１や管理者端末４００などから入力される原本ファイルを記憶したり、帳票申請システムの運用開始後に、入力部１１１や管理者端末４００などから入力される原本ファイル（変更された原本ファイルなど）を記憶するなどする。例えば、原本記憶部１２１は、図３に示すように、『原本ファイル名』と、『管理情報』と、『帳票データ』と、『版数確認マクロ』とを対応づけて記憶する。また、『管理情報』は、『原本ＩＤ』と、『更新日時』と、『グループＩＤ』と、『原本ＩＤリスト』と、『サーバ情報』とから構成される。
【００３９】
ここで、図３の（Ｂ）は、図３の（Ａ）に示す原本記憶部１２１の内容例の状態から、原本ファイルの改訂が行われた後の原本記憶部１２１の内容例を示すものである。かかる改訂の内容について、具体的に説明すると、まず、『原本ファイル名』が「発注申請書.doc」で示される原本ファイルは、『更新日時』がともに「2007/03/03-10:00」であり、改訂が実施されていないことを示している。
【００４０】
また、『原本ファイル名』が「旅費申請書.doc」で示される原本ファイルは、『更新日時』がともに「2007/03/03-10:00」であり、その原本の内容自体には変更が無いことを示しているが、図３の（Ｂ）において、『原本ＩＤリスト』に「0005」が追加されていることから、添付書面が追加される改訂（以下、説明の便宜上、「分割を伴う改訂」、または単に「分割」と呼ぶ）が実施されたことを示している。
【００４１】
また、『原本ファイル名』が「社外勤務時間申請書.doc」で示される原本ファイルは、図３の（Ａ）における『更新日時』が「2007/03/03-10:00」であるのに対し、図３の（Ｂ）における『更新日時』が「2007/04/01-10:00」であることから、原本ファイルの更新が行われたことを示しており、図３の（Ｂ）において、『原本ＩＤリスト』から「0004」が削除されていることから、添付書面が削除される改訂（以下、説明の便宜上、「統合を伴う改訂」、または単に「統合」と呼ぶ）が実施されたことを示している。
【００４２】
また、『原本ファイル名』が「勤務時間証明添付書.doc」で示される原本ファイルは、図３の（Ａ）において、『原本ファイル名』が「社外勤務時間申請書.doc」で示される原本ファイルと同じ『グループＩＤ』「0003」を付与されて登録されているが、図３の（Ｂ）においては、登録されていないことから、当該原本ファイルを廃止する改訂（以下、説明の便宜上、「統合による廃止」、または単に「廃止」と呼ぶ）が実施されたことを示している。
【００４３】
また、『原本ファイル名』が「旅券添付書.doc」で示される原本ファイルは、図３の（Ａ）においては、登録されていないが、図３の（Ｂ）において、『原本ファイル名』が「旅費申請書.doc」と同じ『グループＩＤ』「0002」を付与されて登録されていることから、当該原本ファイルを追加する改訂（以下、説明の便宜上、「分割を伴う改訂」、または単に「分割」、「追加」と呼ぶ）が実施されたことを示している。
【００４４】
原本管理情報記憶部１２２は、原本ファイルの管理に関する情報である原本管理情報を記憶する。具体的には、原本管理情報記憶部１２２は、帳票申請システムの運用開始前などに、入力部１１１や管理者端末４００などから入力される原本管理情報を記憶したり、入力部１１１や管理者端末４００などから入力された原本ファイルの属性を原本管理情報として記憶するなどする。また、原本管理情報記憶部１２２は、帳票申請システムの運用開始後に、入力部１１１や管理者端末４００などから入力される原本管理情報を記憶したり、入力部１１１や管理者端末４００などから入力された原本ファイルの属性（変更された原本ファイルの属性など）を原本管理情報として記憶するなどする。例えば、原本管理情報記憶部１２２は、図４に示すように、『原本ＩＤ』と、『更新日時』と、『グループＩＤ』と、『格納パス』とを対応づけて記憶する。
【００４５】
ここで、図４の（Ｂ）は、図４の（Ａ）に示す原本管理情報記憶部１２２の内容例の状態から原本ファイルの改訂が行われた後の原本管理情報記憶部１２２の内容例を示すものである。かかる改訂の内容は、図３で説明した改訂と同様である。
【００４６】
また、図４の（Ｃ）は、図４の（Ｂ）に示す内容例のその他の実施例を示したものである。図４の（Ｂ）との相違点は、登録されている原本管理情報が有効か否かを示す『状態』の項目を備えている点、および、図４の（Ｂ）において廃止により削除された『原本ＩＤ』「0004」で特定される原本管理情報が、図４の（Ｃ）においては削除されずに存続している点の２点であり、その他の点では同じである。
【００４７】
制御部１３０は、帳票申請サーバ１００を制御して各種処理を実行し、特に本発明に密接に関連するものとしては、図２に示すように、原本登録部１３１と、原本送信部１３２と、マクロ添付部１３３と、管理情報添付部１３４と、問合せ受付部１３５と、原本管理情報取得部１３６と、原本改訂判定部１３７と、分割統合判定部１３８と、版数通知部１３９とを備える。なお、問合せ受付部１３５は、特許請求の範囲に記載の「グループ情報受信手順」に対応し、原本管理情報取得部１３６、原本改訂判定部１３７、および分割統合判定部１３８は、特許請求の範囲に記載の「判定手順」に対応し、版数通知部１３９は、特許請求の範囲に記載の「変更情報送信手順」に対応する。
【００４８】
原本登録部１３１は、帳票申請サーバ１００における原本ファイルの登録を行う。例えば、原本登録部１３１は、入力部１１１や管理者端末４００などから入力される原本ファイルを、原本記憶部１２１に記憶させる。
【００４９】
原本送信部１３２は、管理者端末４００や帳票申請端末２００などに対する原本ファイル（原本ファイルの写し）の送信を行う。例えば、原本送信部１３２は、管理者端末４００との間で行われる原本ファイルの登録に関する処理の中で、管理者端末４００に、原本ファイルを送信するなどする。また、例えば、原本送信部１３２は、帳票申請端末２００との間で行われる原本ファイルのダウンロードに関する処理の中で、帳票申請端末２００に、原本ファイルを送信するなどする。
【００５０】
マクロ添付部１３３は、原本ファイルの原本記憶部への登録を行う際、又は管理者端末４００や帳票申請端末２００などに対して原本ファイルの送信を行う際に、送信対象の原本ファイルに版数確認マクロを添付する。また、管理情報添付部１３４は、原本ファイルの原本記憶部への登録を行う際、又は管理者端末４００や帳票申請端末２００などに対して原本ファイルの送信を行う際に、送信対象の原本ファイルに管理情報を添付する。もっとも、原本ファイルが、図３に示したような形態で原本記憶部１２１に記憶されている場合には、管理者端末４００や帳票申請端末２００などに対して原本ファイルの送信を行う際のマクロ添付部１３３や管理情報添付部１３４による上記添付処理は、必ずしも必須ではない。すなわち、原本記憶部１２１が、原本ファイルとともに版数確認マクロや管理情報を記憶している場合には、マクロ添付部１３３や管理情報添付部１３４による添付なしに、原本送信部１３２が、原本記憶部１２１に記憶されている原本ファイルをそのまま送信することで、管理者端末４００や帳票申請端末２００などに対して、版数確認マクロや管理情報をも送信することができる。一方、図２０に示すような形態で原本記憶部１２１に記憶されている場合には、管理者端末４００や帳票申請端末２００などに対して原本ファイルの送信を行う際にマクロ添付部１３３や管理情報添付部１３４による上記添付処理を行えばよく、原本ファイルの原本記憶部への登録を行う際のマクロ添付部１３３や管理情報添付部１３４による上記添付処理は、必ずしも必須ではない。この点については、実施例２で詳述する。
【００５１】
問合せ受付部１３５は、帳票申請端末２００などからの版数問合せ要求を受け付ける。具体的には、問合せ受付部１３５は、帳票申請端末２００が、帳票申請サーバ１００に対して原本ファイルの版数確認に関する版数問合せ要求を行う際に、当該版数問合せ要求を受け付け、受け付けた当該版数問合せ要求に含まれる管理情報を取得する。
【００５２】
原本管理情報取得部１３６は、原本管理情報を取得する。具体的には、原本管理情報取得部１３６は、帳票申請端末２００が、帳票申請サーバ１００に対して原本ファイルの版数確認に関する版数問合せ要求を行った際に、当該版数問合せ要求から『原本ＩＤ』や『グループＩＤ』を取得し、取得した『原本ＩＤ』や『グループＩＤ』を用いて、原本管理情報記憶部１２２から対応する原本管理情報を取得する。
【００５３】
原本改訂判定部１３７は、原本ファイルの変更として、原本ファイルの改訂や廃止が行われたか否かを判定する。また、分割統合判定部１３８は、原本ファイルの変更として、原本ファイルの置換や、分割、あるいは統合が行われたか否かを判定する。
【００５４】
版数通知部１３９は、原本ファイルの変更に関する情報を帳票申請端末２００に送信する。具体的には、版数通知部１３９は、原本改訂判定部１３７や分割統合判定部１３８によって判定された判定結果を、版数問合せ要求を行った帳票申請端末２００に送信する。
【００５５】
なお、これまで、帳票申請サーバ１００を構成する各部について、簡単に説明してきたが、各部が行う処理の詳細については、実施例１に係る文書管理システム（帳票申請システム）による処理の手順を説明する際に、詳述することとする。
【００５６】
［帳票申請端末２００］
ここで、図２に戻ると、帳票申請端末２００は、入力部２１１と、出力部２１２と、入出力制御Ｉ／Ｆ部２１３と、通信部２１４と、記憶部２２０と、制御部２３０とから構成される。
【００５７】
入力部２１１は、制御部２３０による各種処理に用いるデータや、各種処理をするための操作指示などを、キーボード、マウス、または記憶媒体などによって入力する。出力部２１２は、制御部２３０による各種処理の結果や、各種処理をするための操作指示などを、モニタ、またはプリンタなどに出力する。入出力制御Ｉ／Ｆ部２１３は、入力部２１１及び出力部２１２と、記憶部２２０および制御部２３０との間におけるデータ転送を制御する。通信部２１４は、帳票申請サーバ１００とネットワーク３００を介して通信する。具体的には、通信部１１４は、申請に関する通信などを行う。
【００５８】
記憶部２２０は、制御部２３０による各種処理に用いるデータを記憶する。特に本発明に密接に関連するものとしては、図２に示すように、外部定義記憶部２２１と、申請書記憶部２２２とを備える。
【００５９】
外部定義記憶部２２１は、外部定義情報を記憶する。実施例１においては、外部定義記憶部２２１は、図５に示すように、外部定義情報として、帳票申請サーバ１００のネットワーク上のアドレスを示す情報（サーバ情報）を記憶する。なお、図５の（Ｂ）は、図５の（Ａ）に示す外部定義記憶部２２１の内容例の状態から、帳票申請サーバ１００のネットワーク上のアドレス変更に伴い、外部定義情報が書き換えられた後の外部定義記憶部２２１の内容例を示すものである。
【００６０】
申請書記憶部２２２は、申請ファイルを記憶する。具体的には、申請書記憶部２２２は、帳票申請端末２００が、帳票申請サーバ１００に対して申請を行う際に利用される申請ファイル（帳票申請サーバ１００から予め受信していた原本ファイルの写しや、当該原本ファイルの写しに申請内容を記入したものなど）を記憶する。
【００６１】
ここで、申請書記憶部２２２が記憶する申請ファイル２２３は、図６に示すように、管理情報２２３１と、版数確認マクロ２２３２と、帳票情報２２３３とを一体として構成される。申請ファイル２２３の版数確認マクロ２２３２には、図６に示すように、管理情報取得部２２３２ａ、サーバ取得部２２３２ｂ、外部定義書込部２２３２ｃ、版数問合せ部２２３２ｄ、および出力部２２３２ｅの各種マクロが記憶され、これらの各種マクロは、後述するマクロ実行部２３２によって実行される。
【００６２】
申請書記憶部２２２が記憶する情報について、具体的に例を挙げて説明すると、申請書記憶部２２２は、図７に示すように、『申請ファイル名』と、『管理情報』と、『帳票情報』と、『版数確認マクロ』とを対応づけて記憶する。また、『管理情報』は、『原本ＩＤ』と、『取得日時』と、『グループＩＤ』と、『原本ＩＤリスト』と、『サーバ情報』とから構成される。
【００６３】
図７の（Ａ）に示すように、例えば、『申請ファイル名』が「発注申請書_xxx1.doc」で示される申請書ファイルは、『原本ＩＤ』「0001」と『取得日時』「2007/03/03-15:00」と『グループＩＤ』「0001」と『原本ＩＤリスト』「0001」と『サーバ情報』「192.168.0.1」とで構成される管理情報、帳票情報、および版数マクロから構成されており、『原本ＩＤ』「0001」で特定される原本ファイルであって、「2007/03/03-15:00」に取得した原本ファイルに基づいて作成された申請ファイルであることが示されている。
【００６４】
また、図７の（Ｂ）は、図３で説明した原本ファイルの改訂が行われた後に、図７の（Ａ）に示す申請ファイルを流用して新たな申請ファイルを作成した場合の申請書記憶部２２２の内容例を示すものである。図７の（Ｂ）において、申請ファイル名に「_xxx2」を有するものは、「_xxx1」を有する申請ファイルを流用して作成したものや、流用できず新たにダウンロードした原本ファイルに基づいて作成された申請ファイルであることを示している。
【００６５】
制御部２３０は、帳票申請端末２００を制御して各種処理を実行し、特に本発明に密接に関連するものとしては、図２に示すように、原本取得部２３１と、マクロ実行部２３２と、申請ファイル編集部２３３と、申請書送信部２３４とを備える。
【００６６】
原本取得部２３１は、原本ファイルを取得する。具体的には、原本取得部２３１は、帳票申請サーバ１００との間で行われる原本ファイルのダウンロードに関する処理の中で、原本ファイルを取得するなどする。
【００６７】
マクロ実行部２３２は、申請ファイル２２３に添付されている版数確認マクロ２２３２を実行する。具体的には、マクロ実行部２３２は、申請ファイル編集部２３３から実行の依頼を受けた際に、実行の依頼を受けた申請ファイル２２３に添付されている版数確認マクロ２２３２を実行可能な形式に翻訳し、当該申請ファイル２２３の版数確認の処理を実行する。また、マクロ実行部２３２は、帳票申請サーバ１００から受信した回答文を出力するなどする。
【００６８】
申請ファイル編集部２３３は、申請ファイル２２３の編集を行う。具体的には、申請ファイル編集部２３３は、申請ファイル２２３の編集を行うとともに、当該申請ファイル２２３に版数確認マクロが添付されている場合には、当該版数確認マクロの実行を、マクロ実行部２３２に依頼する。
【００６９】
申請書送信部２３４は、申請ファイル２２３を帳票申請サーバ１００に送信する。具体的には、申請書送信部２３４は、申請ファイル編集部２３３によって編集された申請ファイル２２３を、帳票申請サーバ１００に送信することで、申請を行う。
【００７０】
なお、これまで、帳票申請端末２００を構成する各部について、簡単に説明してきたが、各部が行う処理の詳細については、実施例１に係る文書管理システム（帳票申請システム）による処理の手順を説明する際に、詳述することとする。
【００７１】
［実施例１に係る文書管理システム（帳票申請システム）による処理の手順］
次に、図８〜図１９を用いて、実施例１に係る文書管理システム（帳票申請システム）による処理の手順を説明する。図８は、原本登録処理（新規）の手順を示すシーケンス図であり、図９は、原本登録処理（新規）の処理画面を説明するための図であり、図１０は、原本登録処理（置換）の手順を示すシーケンス図であり、図１１は、原本登録処理（置換）の処理画面を説明するための図であり、図１２は、原本登録処理（分割）の手順を示すシーケンス図であり、図１３は、原本登録処理（分割）の処理画面を説明するための図であり、図１４は、原本登録処理（統合）の手順を示すシーケンス図であり、図１５は、原本登録処理（統合）の処理画面を説明するための図であり、図１６は、原本ダウンロード処理の手順を示すシーケンス図であり、図１７は、版数確認処理の手順を示すシーケンス図であり、図１８は、判定処理の手順を示すシーケンス図であり、図１９は、メッセージ出力画面について説明するための図である。
【００７２】
［原本登録処理］
実施例１における帳票申請サーバ１００は、原本登録部１３１において、原本ファイルの登録を行う。原本ファイルの登録は、原本登録部１３１が、入力部１１１や管理者端末４００などから入力される原本ファイルを、原本記憶部１２１に記憶させることによって行われるが、以下では、原本登録部１３１が、管理者端末４００から入力される原本ファイルを、原本記憶部１２１に記憶させる処理について説明する。なお、原本ファイルの登録には、新規の原本ファイルを登録する処理、原本ファイルを置換して登録する処理、原本ファイルを分割して登録する処理、および原本ファイルを統合して登録する処理があるので、以下では、これらの処理を順に説明するが、重複する点については、省略する。
【００７３】
新規の原本ファイルを登録する処理は、例えば、図８に示すような手順によって行われる。まず、管理者端末４００が、帳票申請サーバ１００に対して、原本登録画面を要求する（ステップＳ８０１）。すると、帳票申請サーバ１００が、管理者端末４００に対して、登録種別選択画面を送信する（ステップＳ８０２）。ここで、登録種別選択画面とは、例えば、図９の（Ａ）に示すような画面である。図９の（Ａ）では、『新規』、『置換』、『分割』、および『統合』のアイコンを出力することで、処理種別を選択させている。
【００７４】
次に、管理者端末４００は、帳票申請サーバ１００から受信した登録種別画面の中から、登録種別として、『新規』を選択する（ステップＳ８０３）。すると、帳票申請サーバ１００は、管理者端末４００によって選択された『新規』用の原本登録画面を、管理者端末４００に送信する（ステップＳ８０４）。ここで、『新規』用の原本登録画面とは、例えば、図９の（Ｂ）に示すような画面である。図９の（Ｂ）では、管理者端末４００が『新規』に登録しようと考えている原本ファイルであって、ローカルディスクに保持している原本ファイルを、『参照』のアイコンを利用することで選択させている。
【００７５】
すると、管理者端末４００は、帳票申請サーバ１００から受信した『新規』用の原本登録画面において、管理者端末４００が『新規』に登録しようと考えている原本ファイルであって、ローカルディスクに保持している原本ファイルを、『参照』のアイコンを利用することで選択する（ステップＳ８０５）。そして、管理者端末４００は、選択した原本ファイルを、帳票申請サーバ１００に対して、仮送信する（ステップＳ８０６）。
【００７６】
次に、帳票申請サーバ１００は、管理者端末４００に対して、管理情報入力画面を送信する（ステップＳ８０７）。ここで、管理情報入力画面とは、例えば、図９の（Ｃ）に示すような画面である。
【００７７】
続いて、管理者端末４００は、帳票申請サーバ１００から管理情報入力画面を受信すると、当該管理情報入力画面に、原本ファイルの管理情報を入力する（ステップＳ８０８）。例えば、管理者端末４００は、図９の（Ｃ）に示すような画面に、格納パスや、グループＩＤ、あるいは適用日付などを入力する。そして、管理者端末４００は、原本ファイルを送信する（ステップＳ８０９）。
【００７８】
すると、帳票申請サーバ１００が、管理者端末４００に対して、確認画面を送信するので（ステップＳ８１０）、これに応答するように、管理者端末４００が、帳票申請サーバ１００に対して、原本登録要求を送信する（ステップＳ８１１）。
【００７９】
その後、帳票申請サーバ１００においては、管理者端末４００において入力された管理情報や自動採番された識別番号などに基づいて原本管理情報を原本管理情報記憶部１２２に格納したり（ステップＳ８１２）、版数確認マクロを原本ファイルに添付したり（ステップＳ８１３）、上述のステップＳ８１２において自動採番された識別番号を用いて原本管理情報記憶部１２２から取得される原本管理情報に基づいて管理情報を原本ファイルに添付するなどして（ステップＳ８１４）、原本ファイルを原本記憶部１２１に格納する（ステップＳ８１５）。
【００８０】
例えば、図３（Ａ）に示す『原本ファイル名』が「社外勤務時間申請書.doc」で特定される原本ファイルを登録する際には、上述のステップＳ８１２において自動採番された識別番号「0003」を用いて、図４（Ａ）に示す原本管理情報から『原本ＩＤ』が「0003」で特定される原本管理情報から『更新日時』「2007/03/03-10：00」、『グループＩＤ』「0003」が取得され、当該『グループＩＤ』を用いて特定される管理情報の一群から得られる『原本ＩＤ』から『原本ＩＤリスト』「0003,0004」が取得され、帳票申請サーバの通信部１１４に設定されているネットワークアドレス等により示されるサーバ情報を通信部１１４から取得し、これらの情報に基づいた管理情報が原本ファイルに添付される。
【００８１】
また、原本ファイルを置換して登録する処理は、例えば、図１０に示すような手順によって行われる。新規の原本ファイルを登録する処理と主に異なる点は、ステップＳ１００３で、管理者端末４００が、登録種別として、『置換』を選択する点、ステップＳ１００４で、帳票申請サーバ１００が、『置換』用の原本登録画面を送信する点、ステップＳ１００９で、管理者端末４００が、置換対象を入力する点である。なお、『置換』用の原本登録画面とは、図１１の（Ｂ）に示すような画面であり、『置換』用の管理情報入力画面とは、図１１の（Ｃ）に示すような画面である。
【００８２】
また、原本ファイルを分割して登録する処理は、例えば、図１２に示すような手順によって行われる。新規の原本ファイルを登録する処理と主に異なる点は、ステップＳ１２０３で、管理者端末４００が、登録種別として、『分割』を選択する点、ステップＳ１２０４で、帳票申請サーバ１００が、『分割』用の原本登録画面を送信する点、ステップＳ１２０８で、管理者端末４００が、原本ファイルの管理情報として『グループＩＤ』を入力する点である。なお、『分割』用の原本登録画面とは、図１３の（Ｂ）に示すような画面であり、『分割』用の管理情報入力画面とは、図１３の（Ｃ）に示すような画面である。ここで選択されたグループＩＤに原本ファイルが登録されると、当該グループに属している原本ファイルに分割が行われたことになる。
【００８３】
また、原本ファイルを統合して登録する処理は、例えば、図１４に示すような手順によって行われる。新規の原本ファイルを登録する処理と主に異なる点は、ステップＳ１４０３で、管理者端末４００が、登録種別として、『統合』を選択する点、ステップＳ１４０４で、帳票申請サーバ１００が、『統合』用の原本登録画面を送信する点、ステップＳ１４０８で、管理者端末４００が、原本ファイルの管理情報として、削除する原本ファイルの指定を入力する点である。なお、『統合』用の原本登録画面とは、図１５の（Ｂ）に示すような画面であり、『統合』用の管理情報入力画面とは、図１５の（Ｃ）に示すような画面である。例えば、『様式Ａ』のチェックボックスにチェックを入力すると、当該『様式Ａ』は、削除する原本ファイルとして指定されたことになる。
【００８４】
上述の『分割』又は『統合』が行われる際には、帳票申請サーバ１００において、当該グループに属する原本ファイルの管理情報に示される『原本ＩＤリスト』の更新処理を行う必要がある。すなわち、『分割』において新たに追加された原本ファイル又は『統合』において削除された原本ファイルに示される『グループＩＤ』を用いて特定される原本ファイル群の管理情報に示される『原本ＩＤリスト』を、『分割』又は『統合』後のグループに属する原本ファイルの構成にあわせて更新を行う。
【００８５】
なお、当該「原本ＩＤリスト」の更新処理によっては、原本ファイルの管理情報に示される更新日時及び原本管理情報記憶部の原本管理情報に示される更新日時の値は変更されない。すなわち、当該更新日時は原本ファイルに示される『帳票情報』の値が更新されることに伴って変更されるものであるため、『帳票情報』の更新を伴わない「原本ＩＤリスト」の更新処理によって当該更新日時が変更されることはない。
【００８６】
［原本ダウンロード処理］
実施例１における帳票申請端末２００は、原本取得部２３１において、原本ファイルのダウンロードを行う。原本ダウンロード処理は、例えば、図１６に示すような手順によって行われる。まず、帳票申請端末２００が、帳票申請サーバ１００に対して、原本一覧取得を依頼する（ステップＳ１６０１）。すると、帳票申請サーバ１００が、帳票申請端末２００に対して、原本一覧を送信する（ステップＳ１６０２）。
【００８７】
次に、帳票申請端末２００が、帳票申請サーバ１００に対して、原本取得を依頼する（ステップＳ１６０３）。すると、帳票申請サーバ１００は、原本ファイルを取得し（ステップＳ１６０４）、帳票申請端末２００に対して、当該原本ファイルを送信する（ステップＳ１６０７）。すると、帳票申請端末２００は、受信した原本ファイルを、申請書記憶部２２２に格納する（ステップＳ１６０８）。
【００８８】
［版数確認処理］
実施例１における帳票申請端末２００は、版数確認処理を行う。版数確認処理は、例えば、図１７に示すような手順によって行われる。まず、帳票申請端末２００の利用者による申請ファイルの編集が可能になるように、帳票申請端末２００は、帳票申請ファイル編集部２３３において、申請ファイルの内容を申請書記憶部２２２から申請ファイル編集部２３３に読み込むことを目的として、申請ファイルを選択する（ステップＳ１７０１）。
【００８９】
続いて、帳票申請端末２００は、申請ファイル編集部２３３において、申請ファイルを申請書記憶部２２２から読み込む際に、申請ファイルに版数確認マクロが添付されているか否かを判定する（ステップＳ１７０２）。申請ファイルに版数確認マクロが添付されている場合には、帳票申請端末２００は、マクロ実行部２３２に版数確認マクロの実行を依頼する。実施例１においては、申請ファイルに版数マクロが添付されているものとするので、帳票申請端末２００は、マクロ実行部２３２に、版数確認マクロの実行を依頼する（ステップ１７０３）。
【００９０】
すると、帳票申請端末２００は、マクロ実行部２３２において、実行依頼を受けた版数確認マクロを実行可能な形式に翻訳し、選択された申請ファイルの版数確認の処理を実行する。まず、帳票申請端末２００は、マクロ実行部２３２において、選択された申請ファイルの管理情報を取得する（ステップＳ１７０４）。例えば、申請書記憶部２２２に記憶されている『申請ファイル名』が「発注申請書_xxx1.doc」の申請ファイルに添付されている管理情報は、図７の（Ａ）に示すように、『原本ＩＤ』「0001」、『取得日時』「2007/03/03-15:00」、『グループＩＤ』「0001」、『原本ＩＤリスト』「0001」、『サーバ情報』「192.168.0.1」であるので、帳票申請端末２００は、マクロ実行部２３２において、これらの管理情報を取得する。
【００９１】
次に、帳票申請端末２００は、マクロ実行部２３２において、取得した管理情報に示される『サーバ情報』を用いて、版数問い合わせ要求の送信先となる帳票申請サーバ１００との接続確立を行う（ステップＳ１７０５）。接続の確立が成功した場合は、当該『サーバ情報』を用いて、外部定義記憶部２２１に格納されている『サーバ情報』の値を書き換える（ステップＳ１７０５）。
【００９２】
ここで、申請ファイルから取得される管理情報は、当該申請ファイルを作成する際に用いた原本ファイルを帳票申請サーバ１００からダウンロードした時の情報が記録されているものである（あるいは、帳票申請サーバ１００から帳票申請端末２００に原本ファイルをダウンロードする際に、原本記憶部１２１以外の構成が実質的に介在しない構成とする場合には、原本記憶部１２１に原本ファイルを登録した時の情報である）。そうであるとすると、過去に作成された申請ファイルを流用する場合には、この情報は過去の情報であることから、帳票申請サーバ１００で管理される現在の管理情報の値と不整合を生じる可能性がある。すなわち、ネットワークの構成変更に伴い、帳票申請サーバ１００のネットワーク上のアドレスが変更されることにより、変更前に作成された過去の申請ファイルの管理情報に示される『サーバ情報』を用いた場合には、変更後の帳票申請サーバ１００との接続を確立できないことになる。このような場合には、帳票申請端末２００は、マクロ実行部２３２において、外部定義記憶部２２１を参照し、外部定義記憶部２２１に示される『サーバ情報』を用いて、帳票申請サーバ１００の問合せ受付部１３５との接続の確立を行う。接続が確立した場合には、帳票申請端末２００は、当該申請ファイルの管理情報に示される『サーバ情報』を、外部定義情報に示される『サーバ情報』の値を用いて書き換える。一方、外部定義情報に示される『サーバ情報』によっても接続の確立ができない場合は、帳票申請端末２００は、版数問合せ処理を異常終了させる。なお、この場合においても、帳票申請端末２００は、新たな帳票申請サーバから適当な原本ファイルをダウンロードした後に、当該原本ファイルについての版数チェックマクロの実行による上述の外部定義情報の書き換えが行われるため、当該外部定義書換え処理を実行後に、当該申請ファイルについて処理を再度行うことにより、帳票申請サーバ１００との接続の確立が可能になる。
【００９３】
さて、図１７に戻ると、帳票申請端末２００は、マクロ実行部２３２において、取得した管理情報のうち、『原本ＩＤ』、『取得日時』、『グループＩＤ』、および『原本ＩＤリスト』で構成される版数問い合わせ要求を、帳票申請サーバ１００に送信する（ステップＳ１７０６）。
【００９４】
すると、帳票申請サーバ１００は、問合せ受付部１３５において、帳票申請端末２００から送信される版数問合せ要求を受信し、版数問合せ要求に含まれる管理情報を取得する（ステップＳ１７０７）。例えば、帳票申請サーバ１００は、問合せ受付部１３５において、『申請ファイル名』が「発注申請書_xxx1.doc」の申請ファイルに添付されている管理情報として、『原本ＩＤ』「0001」、『取得日時』「2007/03/03-15:00」、『グループＩＤ』「0001」、および『原本ＩＤリスト』「0001」を取得する。
【００９５】
そして、帳票申請サーバ１００は、原本管理情報取得部１３６において、帳票申請端末２００による版数問合せ要求から取得した管理情報に示される『原本ＩＤ』を用いて、原本管理情報記憶部１２２から、対応する原本管理情報を取得する（ステップＳ１７０８）。例えば、帳票申請サーバ１００は、原本管理情報取得部１３６において、『原本ＩＤ』「0001」に対応する原本管理情報として、『更新日時』「2007/03/03-10:00」、『グループＩＤ』「0001」、および『格納パス』「／原本／購買／発注申請書.doc」を取得する（図４を参照）。
【００９６】
続いて、帳票申請サーバ１００は、原本改訂判定部１３７において、原本ファイルに改訂があるか否かを判定する（ステップＳ１７０９）。なお、原本改訂判定部１３７による原本改訂判定処理については、分割統合判定部１３８による分割統合判定処理とともに、判定処理として後に詳述する。
【００９７】
次に、帳票申請サーバ１００は、原本管理情報取得部１３６において、帳票申請端末２００による版数問合せ要求から取得した管理情報に示される『グループＩＤ』を用いて、原本管理情報記憶部１２２から、対応する原本管理情報を取得する（ステップＳ１７１０）。例えば、帳票申請サーバ１００は、原本管理情報取得部１３６において、『グループＩＤ』「0001」に対応する原本管理情報を取得するが、図４の（Ｂ）に示すように、『グループＩＤ』「0001」に対応する原本管理情報は、『原本ＩＤ』「0001」で特定される原本管理情報のみである。
【００９８】
もし、帳票申請サーバ１００が、原本管理情報取得部１３６において、『申請ファイル名』が「旅費申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得される『グループＩＤ』「0002」に対応する原本管理情報を取得しようとすると、図４の（Ｂ）に示すように、『グループＩＤ』「0002」に対応する原本管理情報は、『原本ＩＤ』「0002」で特定される原本管理情報と、『原本ＩＤ』「0005」で特定される原本管理情報との２件である。また、帳票申請サーバ１００が、原本管理情報取得部１３６において、『申請ファイル名』が「社外勤務時間申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得される『グループＩＤ』「0003」に対応する原本管理情報を取得しようとすると、図４の（Ｂ）に示すように、『グループＩＤ』「0003」に対応する原本管理情報は、『原本ＩＤ』「0003」で特定される原本管理情報のみである。また、帳票申請サーバ１００が、原本管理情報取得部１３６において、『申請ファイル名』が「勤務時間証明添付書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得される『グループＩＤ』「0003」に対応する原本管理情報を取得しようとすると、図４の（Ｂ）に示すように、『グループＩＤ』「0003」に対応する原本管理情報は、『原本ＩＤ』「0003」で特定される原本管理情報のみである。
【００９９】
続いて、帳票申請サーバ１００は、分割統合判定部１３８において、置換、分割、あるいは統合の有無を判定する（ステップＳ１７１１）。なお、分割統合判定部１３８による分割統合判定処理については、原本改訂判定部１３７による原本改訂判定処理とともに、判定処理として後に詳述する。
【０１００】
その後、帳票申請サーバ１００が、版数通知部１３９において、帳票申請端末２００に対して、原本改訂判定部１３７による原本改訂判定処理や、分割統合判定部１３８による分割統合判定処理で判定した判定結果を、回答文として送信すると（ステップＳ１７１２）、帳票申請端末２００は、帳票申請サーバ１００から受信した回答文を、メッセージとして出力する（ステップＳ１７１３）。
【０１０１】
［判定処理］
上記したように、実施例１における帳票申請サーバ１００は、判定処理として、原本改訂判定部１３７による原本改訂判定処理や、分割統合判定部１３８による分割統合判定処理を行う。これらの判定処理は、例えば、図１８に示すような手順によって行われる。なお、図１８においては、説明の便宜上から、原本管理情報取得部１３６による原本管理情報の取得についても、再掲する。
【０１０２】
まず、帳票申請サーバ１００は、原本管理情報取得部１３６において、帳票申請端末２００による版数問合せ要求から取得した管理情報に示される『原本ＩＤ』を用いて、原本管理情報記憶部１２２から、対応する原本管理情報を取得する（ステップＳ１８０１。ステップＳ１７０８に相当）。
【０１０３】
次に、帳票申請サーバ１００は、原本改訂判定部１３７において、原本管理情報取得部１３６が原本管理情報の取得に成功したか否かを判定する（ステップＳ１８０２）。例えば、版数問合せ要求から取得した管理情報に示される『原本ＩＤ』に対応する原本管理情報が、原本管理情報記憶部１２２に登録されていない場合には、帳票申請サーバ１００は、原本改訂判定部１３７において、「取得失敗」と判定する（ステップＳ１８０２否定）。この場合、帳票申請サーバ１００は、原本改訂判定部１３７において、当該『原本ＩＤ』で特定される原本ファイルが廃止されたと判定し（ステップＳ１８０３）、「廃止」と出力するなどして、ステップＳ１８０８の処理へと移行する。
【０１０４】
例えば、帳票申請サーバ１００が、原本改訂判定部１３７において、原本管理情報取得部１３６が、『申請ファイル名』「勤務時間証明添付書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『原本ＩＤ』「0004」に対応する原本管理情報の取得に成功したか否かを判定すると、図４の（Ｂ）に示すように、『原本ＩＤ』「0004」に対応する原本管理情報は原本管理情報記憶部１２２に登録されていないことから、帳票申請サーバ１００は、原本管理情報取得部１３６において、管理情報の取得に失敗し、原本改訂判定部１３７において、「取得失敗」と判定し、当該『原本ＩＤ』「0004」で特定される原本ファイルが廃止されたと判定する。
【０１０５】
一方、版数問合せ要求から取得した管理情報に示される『原本ＩＤ』に対応する原本管理情報が、原本管理情報記憶部１２２に登録されている場合には、帳票申請サーバ１００は、原本改訂判定部１３７において、「取得成功」と判定する（ステップＳ１８０２肯定）。
【０１０６】
この場合、帳票申請サーバ１００は、原本改訂判定部１３７において、版数問合せ要求から取得した管理情報に示される『取得日時』と、原本管理情報記憶部１２２から取得した原本管理情報に示される『更新日時』とを比較して（ステップＳ１８０４）、原本ファイルについて、改訂の有無を判定する（ステップＳ１８０５〜ステップＳ１８０７）。具体的には、帳票申請サーバ１００は、原本改訂判定部１３７において、取得日時が更新日時より前の日時となるとき（ステップＳ１８０５肯定、「取得日時」＜「更新日時」）、原本ファイルの帳票申請端末２００による取得後に改訂が行われたと判定し（ステップＳ１８０６）、「改訂あり」と出力するなどする。一方、帳票申請サーバ１００は、原本改訂判定部１３７において、取得日時が更新日時と同日時であるか、または、取得日時が更新日時より後の日時となるとき（ステップＳ１８０５否定、「取得日時」≧「更新日時」）、取得後の改訂は行われていないと判定し（ステップＳ１８０７）、「改訂なし」と出力するなどする。
【０１０７】
例えば、帳票申請サーバ１００が、原本改訂判定部１３７において、『申請ファイル名』「発注申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『取得日時』「2007/03/03-10:00」と、原本管理情報記憶部１２２から取得した原本管理情報であって『原本ＩＤ』「0001」で特定される原本管理情報に示される『更新日時』「2007/03/03-10:00」とを比較すると、取得日時が更新日時より後の日時となることから、原本ファイルの帳票申請端末２００による取得後の改訂は行われていないと判定し、「改訂なし」と出力する。また、同様に、帳票申請サーバ１００が、原本改訂判定部１３７において、『申請ファイル名』「旅費申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『取得日時』「2007/03/03-10:00」と、原本管理情報記憶部１２２から取得した原本管理情報であって『原本ＩＤ』「0002」で特定される原本管理情報に示される『更新日時』「2007/03/03-10:00」とを比較すると、取得日時が更新日時より後の日時となることから、原本ファイルの帳票申請端末２００による取得後の改訂は行われていないと判定し、「改訂なし」と出力する。
【０１０８】
また、例えば、帳票申請サーバ１００が、原本改訂判定部１３７において、『申請ファイル名』「社外勤務時間申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『取得日時』「2007/03/03-10:00」と、原本管理情報記憶部１２２から取得した原本管理情報であって『原本ＩＤ』「0003」で特定される原本管理情報に示される『更新日時』「2007/04/01-10:00」とを比較すると、取得日時が更新日時より前の日時となることから、原本ファイルの帳票申請端末２００による取得後の改訂が行われたと判定し、「改訂あり」と出力する。
【０１０９】
続いて、帳票申請サーバ１００は、原本管理情報取得部１３６において、帳票申請端末２００による版数問合せ要求から取得した管理情報に示される『グループＩＤ』を用いて、原本管理情報記憶部１２２から、対応する原本管理情報を取得する（ステップＳ１８０８。ステップＳ１７１０に相当）。
【０１１０】
次に、帳票申請サーバ１００は、分割統合判定部１３８において、版数問合せ要求から取得した管理情報に示される『原本ＩＤリスト』と、原本管理情報記憶部１２２から取得した原本管理情報であって版数問合せ要求から取得した管理情報に示される『グループＩＤ』に対応する原本管理情報に示される『原本ＩＤ』とを比較して（ステップＳ１８０９）、置換、分割、あるいは統合の有無を判定する（ステップＳ１８１０〜ステップＳ１８１６）。
【０１１１】
具体的には、帳票申請サーバ１００は、分割統合判定部１３８において、版数問合せ要求から取得した管理情報に示される『原本ＩＤリスト』の要素数と、原本管理情報記憶部１２２から取得した所定の原本管理情報の要素数とを比較し（ステップＳ１８１０）、原本管理情報の要素数が『原本ＩＤリスト』の要素数よりも多い場合（ステップＳ１８１０肯定、「原本ＩＤリストの要素数」＜「原本管理情報の要素数」）、帳票申請端末２００による原本ファイルの取得後に分割を伴う改訂が行われたと判定し（ステップＳ１８１１）、「分割」と出力するなどする。
【０１１２】
また、帳票申請サーバ１００は、分割統合判定部１３８において、版数問合せ要求から取得した管理情報に示される『原本ＩＤリスト』の要素数と、原本管理情報記憶部１２２から取得した所定の原本管理情報の要素数とを比較し（ステップＳ１８１０）、原本管理情報の要素数が『原本ＩＤリスト』の要素数よりも多くない場合（ステップＳ１８１０否定）、次に、帳票申請サーバ１００は、分割統合判定部１３８において、版数問合せ要求から取得した管理情報に示される『原本ＩＤリスト』の要素数と、原本管理情報記憶部１２２から取得した所定の原本管理情報の要素数とが同じであるか比較し（ステップＳ１８１２）、同じではない場合（ステップＳ１８１２否定、「原本ＩＤリストの要素数」＞「原本管理情報の要素数」）、原本ファイルの取得後に統合を伴う改訂が行われたと判定し（ステップＳ１８１３）、「統合あり」と出力するなどする。
【０１１３】
また、帳票申請サーバ１００は、分割統合判定部１３８において、版数問合せ要求から取得した管理情報に示される『原本ＩＤリスト』の要素数と、原本管理情報記憶部１２２から取得した所定の原本管理情報の要素数とが同じであるか比較し（ステップＳ１８１２）、同じ場合（ステップＳ１８１２肯定、「原本ＩＤリストの要素数」＝「原本管理情報の要素数」）、次に、帳票申請サーバ１００は、分割統合判定部１３８において、『原本ＩＤリスト』の要素値である『原本ＩＤ』と、『グループＩＤ』を用いて原本管理情報記憶部１２２から取得した原本管理情報に示される『原本ＩＤ』とを比較して（ステップＳ１８１４）、不一致となる原本管理情報の存在を検知した場合（ステップＳ１８１５否定）、原本ファイルを取得した後に置換を伴う改訂が行われたと判定し（ステップＳ１８１６）、「置換」と出力するなどする。
【０１１４】
なお、図１８には図示を割愛したが、帳票申請サーバ１００は、分割統合判定部１３８において、『原本ＩＤリスト』の要素値である『原本ＩＤ』と、『グループＩＤ』を用いて原本管理情報記憶部１２２から取得した原本管理情報に示される『原本ＩＤ』とを比較して（ステップＳ１８１４）、不一致となる原本管理情報の存在を検知しない場合（ステップＳ１８１５肯定）であって、かつ、上記した原本改訂判定部１３７による判定で「改訂なし」と判定された原本ファイルについては、原本ファイルの取得後に改訂は行われてないと判定し、「改訂なし」と出力するなどする。反対に、不一致となる原本管理情報の存在を検知しない場合（ステップＳ１８１５肯定）であって、かつ、上記した原本改訂判定部１３７による判定で「改訂あり」と判定された原本ファイルについては、原本ファイルの取得後に原本ファイルの内容自体の更新による改訂が行われたと判定し、「更新」と出力するなどする。
【０１１５】
例えば、帳票申請サーバ１００が、分割統合判定部１３８において、『申請ファイル名』「発注申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『グループＩＤ』は「0001」であり、『原本ＩＤリスト』は「0001」であるが、原本管理情報記憶部１２２から取得した原本管理情報であって『グループＩＤ』「0001」に対応する原本管理情報に示される『原本ＩＤ』は、「0001」の１件であることから、原本管理情報の要素数が『原本ＩＤリスト』の要素数と同じになり、要素値も「0001」で同じであることから、「分割」でも「統合」でも「置換」でもないと判定され、上記した原本改訂判定部１３７による判定で「改訂なし」と判定された原本ファイルであることから、「改訂なし」と出力する。
【０１１６】
また、例えば、帳票申請サーバ１００が、分割統合判定部１３８において、『申請ファイル名』「旅費申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『グループＩＤ』は「0002」であり、『原本ＩＤリスト』は「0002」であるが、原本管理情報記憶部１２２から取得した原本管理情報であって『グループＩＤ』「0002」に対応する原本管理情報に示される『原本ＩＤ』は、「0002」および「0005」の２件であることから、原本管理情報の要素数が『原本ＩＤリスト』の要素数より多くなることから、分割を伴う改訂が行われたと判定し、「分割あり」と出力する。
【０１１７】
また、例えば、帳票申請サーバ１００が、分割統合判定部１３８において、『申請ファイル名』「社外勤務時間申請書_xxx1.doc」の申請ファイルについての版数問合せ要求から取得した管理情報に示される『グループＩＤ』は「0003」であり、『原本ＩＤリスト』は「0003」および「0004」であるが、原本管理情報記憶部１２２から取得した原本管理情報であって『グループＩＤ』「0003」に対応する原本管理情報に示される『原本ＩＤ』は、「0003」の１件であることから、原本管理情報の要素数が『原本ＩＤリスト』の要素数より少なくなることから、統合を伴う改訂が行われたと判定し、「統合あり」と出力する。
【０１１８】
なお、帳票申請端末２００におけるメッセージ出力画面を例示すると、例えば、図１９のようになる。図１９の（Ａ）は、分割を伴う改訂が行われた場合の例であり、版数問合せ要求で問合せをした申請については、様式Ｂおよび様式Ｃの原本ファイルが追加され、様式Ａ、様式Ｂ、および様式Ｃの申請ファイルで構成されていることを示している。また、図１９の（Ｂ）は、統合を伴う改訂が行われた場合の例であり、版数問合せ要求で問合せをした申請については、様式Ｂの原本ファイルが削除され、様式Ａのみの申請ファイルで構成されていることを示している。
【０１１９】
［実施例１の効果］
上記してきたように、実施例１によれば、文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する方法を、前記文書管理サーバとしてのコンピュータに実行させる文書管理サーバプログラムであって、端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、原本ファイルと原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持し、端末が文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、受信済原本ファイルが属するグループに関する情報として端末が文書管理サーバから受信済原本ファイルとともに予め受信することで保持していた情報を、端末から受信し、受信された受信済原本ファイルのグループに関する情報と、保持される受信済原本ファイルのグループに関する情報とを比較することで、受信済原本ファイルが現に属するグループに変更があったか否かを判定し、判定された判定結果を、原本ファイル変更情報として端末に送信するので、文書に関する方式的な要件不備を効果的に抑止することが可能になる。
【０１２０】
また、実施例１によれば、原本ファイルを識別する原本識別子と、グループに関する情報として、原本識別子によって識別される原本ファイルが現に属するグループを識別するグループ識別子、および、グループ識別子によって識別されるグループに現に属する原本ファイルを識別する原本識別子のリストとを対応づけ可能に保持し、受信された受信済原本ファイルのリストと、保持される受信済原本ファイルのリストとを比較することで、受信済原本ファイルが現に属するグループについて、グループに属している原本ファイルに分割が行われたこと、あるいは、グループに属している原本ファイルに統合が行われたことを判定し、原本ファイル変更情報として、分割、あるいは、統合を示す情報を送信するので、文書に関する方式的な要件不備として、原本ファイルの分割や統合による要件不備を効果的に抑止することが可能になる。
【０１２１】
また、実施例１によれば、原本ファイルと原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する他に、原本ファイルを更新した日時に関する情報をさらに保持し、端末が文書管理サーバから受信済原本ファイルとともに予め受信することで保持していた情報として、受信済原本ファイルの日時に関する情報をさらに受信し、受信された受信済原本ファイルの日時に関する情報と、保持される受信済原本ファイルを更新した日時に関する情報とを比較することで、受信済原本ファイルに改訂が行われたか否かをさらに判定し、原本ファイル変更情報として、改訂を示す情報をさらに送信するので、文書に関する方式的な要件不備として、原本ファイルの改訂による要件不備を効果的に抑止することが可能になる。
【０１２２】
また、実施例１によれば、端末において受信済原本ファイルとともに予め受信することで保持されていたマクロが、端末で実行されることで情報を受信し、マクロが端末で実行されることで判定するので、文書に関する方式的な要件不備を効果的かつ簡易に抑止することが可能になる。
【０１２３】
また、本実施例においては、当該送信時の管理情報や版数確認マクロの添付処理を行わない構成とする点で、後述の実施例２と異なる。例えば、原本記憶部１２１を帳票申請サーバ１００とは異なるサーバコンピュータ（ファイルサーバ）を用いて構成する等、帳票申請端末２００への原本ファイルの送信時に、原本記憶部１２１以外の本発明に係る構成が実質的に介在しない構成とする場合には、帳票申請サーバ１００は、本実施例における図３に示した形式で原本記憶部１２１を構成することが望ましい。すなわち、本実施例のように、帳票申請端末２００への原本ファイルの送信時に原本記憶部１２１以外の本発明に係る構成が実質的に介在しない構成とする場合は、帳票申請端末２００は、申請書記憶部２２２に登録する申請ファイルの情報を取得する上で、原本ファイルのダウンロード以外の通信処理を実質的に省略することが可能となるため、後述の実施例２における図２０に示した形式による原本記憶部１２１の構成と比較して、図３に示した形式で原本記憶部１２１を構成する方が、原本ファイルのダウンロード処理に要する時間を短縮することができ（なぜなら、帳票申請端末２００は、帳票申請サーバ１００との間で通信を行う必要がなく、帳票申請サーバ１００とは異なるサーバコンピュータに構成された原本記憶部１２１との間でのみ通信を行えばよい）、帳票申請端末２００における原本ダウンロードの操作性の向上を図ることができる。
【実施例２】
【０１２４】
ところで、これまで、帳票申請サーバ１００の原本記憶部１２１が、図３に示すような形式で原本ファイルを記憶している例を説明してきたが、本発明における原本記憶部１２１が原本ファイルを記憶する形式は、これに限られるものではない。実施例２における原本記憶部１２１を例示すると、原本記憶部１２１は、例えば、図２０に示すような形式で原本ファイルを記憶する。
【０１２５】
実施例１における原本ファイル記憶部１２１（図３を参照）との相違点は、管理情報および版数確認マクロを備えていない点、並びに、原本ＩＤを備えている点であり、その他の点では同じである。すなわち、実施例１において原本ファイルを原本記憶手段に登録する際に行っていた添付処理（図８におけるＳ８１３及びＳ８１４、図１０におけるＳ１０１４及びＳ１０１５、図１２におけるＳ１２１３及びＳ１２１４、図１４におけるＳ１４１３及びＳ１４１４）は、本実施例においては実行されない。この場合には、帳票申請サーバ１００は、原本ファイルの記憶容量を削減することとなり、実施例１における場合と比較して、原本記憶部１２１の記憶容量を有効に活用することができる。なお、実施例２における原本ファイル記憶部１２１（図２０を参照）による場合には、帳票申請サーバ１００は、帳票申請端末２００への原本ファイル（原本ファイルの写し）の送信時に、図３に示した管理情報や版数確認マクロを、送信対象の原本ファイルの写しに添付（図１６におけるＳ１６０５及びＳ１６０６）して送信する。当該添付処理は、実施例１において原本ファイルを原本記憶手段に登録する際に行った添付処理と同様であるため、説明を省略する。
【実施例３】
【０１２６】
［他の実施例］
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【０１２７】
上記の実施例では、端末において版数確認マクロが実行されることで、文書管理サーバ（帳票申請サーバ）における処理が行われる事例について説明したが、本発明はこれに限られるものではなく、版数確認マクロ以外の手法によって、文書管理サーバ（帳票申請サーバ）における処理が行われる事例にも、本発明を同様に適用することができる。
【０１２８】
また、上記の実施例では、文書管理サーバが、廃止、更新、分割を伴う改訂、統合を伴う改訂、および置換を伴う改訂を全て判定する事例について説明しが、本発明は必ずしもこれに限られるものではなく、文書管理サーバの利用目的や運用形態などに即して必要な項目を判定すればよい。
【０１２９】
［システム構成等］
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１３０】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示（例えば、図２など）の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１３１】
［プログラム］
ところで、上記の実施例１で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２１および図２２を用いて、上記の実施例１と同様の機能を有する文書管理プログラムを実行するコンピュータの一例を説明する。図２１は、文書管理プログラムを実行するコンピュータ（帳票申請サーバ）を示す図であり、図２２は、文書管理プログラムを実行するコンピュータ（帳票申請端末）を示す図である。
【０１３２】
図２１に示すように、帳票申請サーバとしてのコンピュータ５００は、キャッシュ５１０、ＲＡＭ５２０、ＨＤＤ５３０、ＲＯＭ５４０、およびＣＰＵ５５０をバス５６０で接続して構成される。ここで、ＲＯＭ５４０には、上記の実施例１と同様の機能を発揮する文書管理プログラム、つまり、図２１に示すように、原本登録プログラム５４１と、原本送信プログラム５４２と、マクロ添付プログラム５４３と、管理情報添付プログラム５４４と、問合せ受付プログラム５４５と、原本管理情報取得プログラム５４６と、原本改訂判定プログラム５４７と、分割統合判定プログラム５４８と、版数通知プログラム５４９とがあらかじめ記憶されている。
【０１３３】
そして、ＣＰＵ５５０は、これらのプログラム５４１〜５４９を読み出して実行することで、図２１に示すように、各プログラム５４１〜５４９は、原本登録プロセス５５１、原本送信プロセス５５２、マクロ添付プロセス５５３、管理情報添付プロセス５５４、問合せ受付プロセス５５５、原本管理情報取得プロセス５５６、原本改訂判定プロセス５５７、分割統合判定プロセス５５８、および版数通知プロセス５５９となる。なお、各プロセス５５１〜５５９は、図２に示した、原本登録部１３１、原本送信部１３２、マクロ添付部１３３、管理情報添付部１３４、問合せ受付部１３５、原本管理情報取得部１３６、原本改訂判定部１３７、分割統合判定部１３８、および版数通知部１３９にそれぞれ対応する。
【０１３４】
また、ＨＤＤ５３０には、図２１に示すように、原本テーブル５３１および原本管理情報テーブル５３２が設けられる。なお、各テーブル５３１および５３２は、図２に示した、原本記憶部１２１および原本管理情報記憶部１２２にそれぞれ対応する。
【０１３５】
ところで、上記した各プログラム５４１〜５４９については、必ずしもＲＯＭ５４０に記憶させておく必要はなく、例えば、コンピュータ５００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ５００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ５００に接続される「他のコンピュータ（またはサーバ）」に記憶させておき、コンピュータ５００がこれらからプログラムを読み出して実行するようにしてもよい。
【０１３６】
次に、図２２に示すように、帳票申請端末としてのコンピュータ６００は、キャッシュ６１０、ＲＡＭ６２０、ＨＤＤ６３０、ＲＯＭ６４０、およびＣＰＵ６５０をバス６６０で接続して構成される。ここで、ＲＯＭ６４０には、上記の実施例１と同様の機能を発揮する文書管理プログラム、つまり、図２２に示すように、原本取得プログラム６４１と、マクロ実行プログラム６４２と、申請ファイル編集プログラム６４３と、申請書送信プログラム６４４とがあらかじめ記憶されている。
【０１３７】
そして、ＣＰＵ６５０は、これらのプログラム６４１〜６４４を読み出して実行することで、図２２に示すように、各プログラム６４１〜６４４は、原本取得プロセス６５１と、マクロ実行プロセス６５２と、申請ファイル編集プロセス６５３と、申請書送信プロセス６５４となる。なお、各プロセス６５１〜６５４は、図２に示した、原本取得部２３１と、マクロ実行部２３２と、申請ファイル編集部２３３と、申請書送信部２３４にそれぞれ対応する。
【０１３８】
また、ＨＤＤ６３０には、図２２に示すように、外部定義テーブル６３１および申請書テーブル６３２が設けられる。なお、各テーブル６３１および６３２は、図２に示した、外部定義記憶部２２１および申請書記憶部２２２にそれぞれ対応する。
【０１３９】
ところで、上記した各プログラム６４１〜６４４については、必ずしもＲＯＭ６４０に記憶させておく必要はなく、例えば、コンピュータ６００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ６００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ６００に接続される「他のコンピュータ（またはサーバ）」に記憶させておき、コンピュータ６００がこれらからプログラムを読み出して実行するようにしてもよい。
【０１４０】
（付記１）文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する方法を、前記文書管理サーバとしてのコンピュータに実行させる文書管理サーバプログラムであって、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手順と、
前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手順と、
前記グループ情報受信手順によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手順によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手順と、
前記判定手順によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手順と、
を前記文書管理サーバとしてのコンピュータに実行させることを特徴とする文書管理サーバプログラム。
【０１４１】
（付記２）前記保持手順は、前記原本ファイルを識別する原本識別子と、前記グループに関する情報として、当該原本識別子によって識別される原本ファイルが現に属するグループを識別するグループ識別子、および、当該グループ識別子によって識別されるグループに現に属する原本ファイルを識別する原本識別子のリストとを対応づけ可能に保持し、
前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記リストと、前記保持手順によって保持される前記受信済原本ファイルの前記リストとを比較することで、当該受信済原本ファイルが現に属するグループについて、当該グループに属している原本ファイルに分割が行われたこと、あるいは、当該グループに属している原本ファイルに統合が行われたことを判定し、
前記変更情報送信手順は、前記原本ファイル変更情報として、分割、あるいは、統合を示す情報を送信することを特徴とする付記１に記載の文書管理サーバプログラム。
【０１４２】
（付記３）前記保持手順は、前記原本ファイルと前記原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する他に、当該原本ファイルを更新した日時に関する情報をさらに保持し、
前記グループ情報受信手順は、前記端末が前記文書管理サーバから前記受信済原本ファイルとともに予め受信することで保持していた情報として、当該受信済原本ファイルの日時に関する情報をさらに受信し、
前記判定手順は、前記グループ情報受信手順によって受信された前記受信済原本ファイルの前記日時に関する情報と、前記保持手順によって保持される前記受信済原本ファイルを更新した日時に関する情報とを比較することで、当該受信済原本ファイルに改訂が行われたか否かをさらに判定し、
前記変更情報送信手順は、前記原本ファイル変更情報として、改訂を示す情報をさらに送信することを特徴とする付記１または２に記載の文書管理サーバプログラム。
【０１４３】
（付記４）前記グループ情報受信手順は、前記端末において前記受信済原本ファイルとともに予め受信することで保持されていたマクロが、当該端末で実行されることで前記情報を受信し、
前記判定手順は、前記マクロが前記端末で実行されることで判定すること特徴とする付記１〜３のいずれか一つに記載の文書管理サーバプログラム。
【０１４４】
（付記５）文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する文書管理サーバであって、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手段と、
前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信手段と、
前記グループ情報受信手段によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手段によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手段と、
前記判定手段によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手段と、
を備えたことを特徴とする文書管理サーバ。
【０１４５】
（付記６）文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信する文書管理方法であって、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持工程と、
前記端末が前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該端末から受信するグループ情報受信工程と、
前記グループ情報受信工程によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持工程によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定工程と、
前記判定工程によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信工程と、
を含んだことを特徴とする文書管理方法。
【０１４６】
（付記７）文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続され、原本ファイルの変更に関する情報である原本ファイル変更情報を、前記文書管理サーバが前記端末に送信する文書管理システムであって、
前記端末は、
前記文書管理サーバから予め受信していた原本ファイルである受信済原本ファイルについて、当該受信済原本ファイルが属するグループに関する情報として当該端末が当該文書管理サーバから当該受信済原本ファイルとともに予め受信することで保持していた情報を、当該文書管理サーバに送信するグループ情報送信手段を備え、
前記文書管理サーバは、
前記端末において共に利用されるべき複数の原本ファイルを同一のグループに属する原本ファイルとして管理し、当該原本ファイルと当該原本ファイルが現に属するグループに関する情報とを対応づけ可能に保持する保持手段と、
前記グループ情報送信手段によって送信される前記情報を受信するグループ情報受信手段と、
前記グループ情報受信手段によって受信された前記受信済原本ファイルのグループに関する情報と、前記保持手段によって保持される前記受信済原本ファイルのグループに関する情報とを比較することで、当該受信済原本ファイルが現に属するグループに変更があったか否かを判定する判定手段と、
前記判定手段によって判定された判定結果を、前記原本ファイル変更情報として前記端末に送信する変更情報送信手段と、
を備えたことを特徴とする文書管理システム。
【産業上の利用可能性】
【０１４７】
以上のように、本発明に係る文書管理サーバプログラムおよび文書管理サーバは、文書の原本である原本ファイルを管理する文書管理サーバと当該文書管理サーバから受信した所定の原本ファイルを利用する端末とが通信可能に接続されるシステムにおいて、原本ファイルの変更に関する情報である原本ファイル変更情報を前記端末に送信することに有用であり、特に、文書に関する方式的な要件不備を効果的に抑止することに適する。
【図面の簡単な説明】
【０１４８】
【図１】実施例１に係る文書管理システム（帳票申請システム）の概要および特徴を説明するための図である。
【図２】実施例１に係る文書管理システム（帳票申請システム）の構成を示すブロック図である。
【図３】原本記憶部を説明するための図である。
【図４】原本管理情報記憶部を説明するための図である。
【図５】外部定義記憶部を説明するための図である。
【図６】申請書記憶部を説明するための図である。
【図７】申請書記憶部を説明するための図である。
【図８】原本登録処理（新規）の手順を示すシーケンス図である。
【図９】原本登録処理（新規）の処理画面を説明するための図である。
【図１０】原本登録処理（置換）の手順を示すシーケンス図である。
【図１１】原本登録処理（置換）の処理画面を説明するための図である。
【図１２】原本登録処理（分割）の手順を示すシーケンス図である。
【図１３】原本登録処理（分割）の処理画面を説明するための図である。
【図１４】原本登録処理（統合）の手順を示すシーケンス図である。
【図１５】原本登録処理（統合）の処理画面を説明するための図である。
【図１６】原本ダウンロード処理の手順を示すシーケンス図である。
【図１７】版数確認処理の手順を示すシーケンス図である。
【図１８】判定処理の手順を示すシーケンス図である。
【図１９】メッセージ出力画面について説明するための図である。
【図２０】原本記憶部（実施例２）を説明するための図である。
【図２１】文書管理プログラムを実行するコンピュータ（帳票申請サーバ）を示す図である。
【図２２】文書管理プログラムを実行するコンピュータ（帳票申請端末）を示す図である。
【符号の説明】
【０１４９】
１００  帳票申請サーバ
１１１  入力部
１１２  出力部
１１３  入出力制御Ｉ／Ｆ部
１１４  通信部
１２０  記憶部
１２１  原本記憶部
１２２  原本管理情報記憶部
１３０  制御部
１３１  原本登録部
１３２  原本送信部
１３３  マクロ添付部
１３４  管理情報添付部
１３５  問合せ受付部
１３６  原本管理情報取得部
１３７  原本改訂判定部
１３８  分割統合判定部
１３９  版数通知部
２００  帳票申請端末
２１１  入力部
２１２  出力部
２１３  入出力制御Ｉ／Ｆ部
２１４  通信部
２２０  記憶部
２２１  外部定義記憶部
２２２  申請書記憶部
２３０  制御部
２３１  原本取得部
２３２  マクロ実行部
２３３  申請ファイル編集部
２３４  申請書送信部
５００  文書管理プログラム（サーバコンピュータ）
５１０  キャッシュ
５２０  ＲＡＭ
５３０  ＨＤＤ
５４０  ＲＯＭ
５５０  ＣＰＵ
５６０  バス
６００  文書管理プログラム（端末コンピュータ）
６１０  キャッシュ
６２０  ＲＡＭ
６３０  ＨＤＤ
６４０  ＲＯＭ
６５０  ＣＰＵ
６６０  バス
【図１】
2008250943.tif 000003
【図２】
2008250943.tif 000004
【図３】
2008250943.tif 000005
【図４】
2008250943.tif 000006
【図５】
2008250943.tif 000007
【図６】
2008250943.tif 000008
【図７】
2008250943.tif 000009
【図８】
2008250943.tif 000010
【図９】
2008250943.tif 000011
【図１０】
2008250943.tif 000012
【図１１】
2008250943.tif 000013
【図１２】
2008250943.tif 000014
【図１３】
2008250943.tif 000015
【図１４】
2008250943.tif 000016
【図１５】
2008250943.tif 000017
【図１６】
2008250943.tif 000018
【図１７】
2008250943.tif 000019
【図１８】
2008250943.tif 000020
【図１９】
2008250943.tif 000021
【図２０】
2008250943.tif 000022
【図２１】
2008250943.tif 000023
【図２２】
2008250943.tif 000024