JP2006350510A - 文書管理システム、クライアント端末、サーバ、クライアントプログラム及びサーバプログラム - Google Patents

Abstract

【課題】 電子文書を円滑に回覧できる文書管理システム、クライアント端末、サーバ、クライアントプログラム及びサーバプログラムを提供する。
【解決手段】 ユーザクライアント端末１は、回覧対象文書データの回覧順序を表す回覧ルート情報を取得し、回覧対象文書データとともに文書管理サーバ３へ送信する承認申請クライアント１１と、回覧対象文書データを取得してユーザに提示し、これに対する承認結果を取得して文書管理サーバ３へ送信する承認登録クライアント１２とを有し、文書管理サーバ３は、ユーザクライアント端末１から取得した回覧ルート情報の示す回覧順序が、承認フローテンプレートに規定された条件に適合するか否かを判断し、適合すると判断した回覧対象文書データを、要求に応じてユーザクライアント端末１へ送信するサーバプログラム３３を有し、同じ回覧順位に複数の回覧者を設定可能である。
【選択図】 図１

Description

本発明は、ネットワーク上で電子文書の認証処理を行うための文書管理システムに関し、特に、認証処理を円滑に行うための文書管理システムに関する。

企業においては、社員が作成した文書を所定の者が回覧し、各自が承認しなければならない場合がある。例えば、業務に関わる規程を新規作成した場合や、改訂する場合などである。

近年は、環境保護の観点から、企業においてもペーパレス化が進んでおり、電子文書を紙文書と同様に回覧する必要がある。

電子文書を回覧することを目的とした従来技術としては、特許文献１に開示される「電子文書回覧方法、プログラム、記録媒体及び電子文書回覧システム」がある。
特許文献１に開示される発明は、複数の電子文書を回覧する場合に、各電子文書の回覧先を全て抽出し、抽出した回覧先を所定の順序で並べ、全文書をその回覧ルートで回覧するものである。
特開２００２−０８３１０３号公報

しかし、従来の電子文書回覧システムは、回覧先を直列にしか設定できない。例えば、最初にＡ氏の承認が必要で、次にＢ氏及びＣ氏の両名の承認が必要だが順序は不問であり、最後にＤ氏の承認が必要な場合には、Ａ→Ｂ→Ｃ→Ｄ又は、Ａ→Ｃ→Ｂ→Ｄのどちらかの回覧ルートに設定しなければならない。前者に設定した場合、Ｂ氏が何らかの事情で直ちに承認処理を行えないと、回覧がそこで停滞してしまう。このとき、Ｃ氏がすぐに承認処理を行える状況にあったとしても、Ｂ氏の承認が済んでいないためＣ氏は処理を行えない。後者に設定した場合も同様であり、Ｃ氏が承認を行えないと回覧が停滞してしまう。

このように、従来の電子文書回覧システムは、電子文書を円滑に回覧できない場合があるという問題があった。

本発明はかかる問題に鑑みてなされたものであり、電子文書を円滑に回覧できる文書管理システム、クライアント端末、サーバ、クライアントプログラム及びサーバプログラムを提供することを目的とする。

上記目的を達成するため、本発明は、第１の態様として、少なくとも一つのユーザクライアント端末と、サーバとがネットワークを介して接続され、回覧対象の文書データをユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、ユーザクライアント端末は、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバへ送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段とを有し、サーバは、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段とを有し、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする文書管理システムを提供するものである。

本発明の第１の態様においては、ユーザクライアント端末は、回覧対象文書データの回覧順序の変更箇所を取得する手段と、該回覧順序の変更箇所をサーバに通知する手段とを有し、サーバは、ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することが好ましい。

また、上記目的を達成するため、本発明は、第２の態様として、少なくとも一つのユーザクライアント端末と、サーバとがネットワークを介して接続され、回覧対象の文書データをユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、ユーザクライアント端末は、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバに送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段と、自端末のユーザが回覧の申請者である回覧対象文書データの回覧順序の変更箇所を、ユーザの操作によって取得する手段と、該回覧順序の変更箇所をサーバに通知する手段とを有し、サーバは、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段と、ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とする文書管理システムを提供するものである。

本発明の第２の態様においては、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることが好ましい。

本発明の第１の態様、又は第２の態様の上記のいずれの構成においても、サーバは、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して所定の期間が経過したことを通知する手段を有することが好ましい。また、サーバは、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更することが好ましい。

本発明の第１の態様又は第２の態様の上記のいずれの構成においても、ユーザクライアント端末は、自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとしてサーバから取得する手段と、回覧予定文書データを出力する手段とを有することが好ましく、これに加えて、ユーザクライアント端末は、回覧予定文書データの承認結果を取得する手段と、取得した回覧予定文書データの承認結果を、サーバへ送信する手段とを有し、サーバは、任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を回覧対象文書データの承認結果とすることがより好ましい。

本発明の第１の態様又は第２の態様の上記のいずれの構成においても、回覧対象文書データが２以上の異なるファイル形式のデータ群で構成される場合に、これらのデータのファイル形式を特定の一つファイル形式に変換するとともに、一つに結合する手段をさらに有することが好ましい。また、最下位の回覧順位の回覧者による回覧対象文書データの回覧が完了した際に、該回覧対象文書データの回覧が完了したことを所定のユーザに通知する手段を有することが好ましい。また、任意の回覧順位において回覧対象文書データの認証結果が否認であった場合に、該回覧対象文書データの回覧申請者及び否認された回覧順位よりも上位の回覧者に、該回覧対象文書データが否認されたことを通知する手段を有することが好ましい。

また、上記目的を達成するため、本発明は第３の態様として、少なくとも一つのユーザクライアント端末と、管理クライアント端末と、サーバとデータベースとがネットワークを介して接続され、回覧対象の文書データをユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、ユーザクライアント端末は、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバへ送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段とを有し、データベースは、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、回覧中の文書ファイルの状態を表す承認中文書情報が格納される承認中文書情報格納手段と、回覧が完了した文書ファイルの状態を表す正式版文書情報が格納される正式版文書情報格納手段とを有し、サーバは、ユーザクライアント端末から取得した回覧ルート情報に応じた回覧規則情報を、データベースから取得する手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、データベースから取得した回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段とを有し、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする文書管理システムを提供するものである。

また、上記目的を達成するため、本発明は、第４の態様として、ネットワークを介してサーバと情報を送受信する手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバに送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段とを有し、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするクライアント端末を提供するものである。

本発明の第４の態様においては、回覧対象文書データの回覧順序の変更箇所を取得する手段と、該回覧順序の変更箇所をサーバに通知する手段とを有することが好ましい。

また、上記目的を達成するため、本発明は、第５の態様として、ネットワークを介してサーバと情報を送受信する手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書の送信要求をサーバに送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段と、回覧対象文書データの回覧順序の変更箇所を取得する手段と、該回覧順序の変更箇所をサーバに通知する手段とを有することを特徴とするクライアント端末を提供するものである。

本発明の第５の態様においては、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることが好ましい。

本発明の第４の態様又は第５の態様の上記のいずれの構成においても、自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとしてサーバから取得する手段と、回覧予定文書データを出力する手段とを有することが好ましく、これに加えて、回覧予定文書データの承認結果を取得する手段と、取得した回覧予定文書データの承認結果を、サーバへ送信する手段とを有することがより好ましい。

また、上記目的を達成するため、本発明は、第６の態様として、ネットワークを介して少なくとも一つのユーザクライアント端末と接続されたサーバであって、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、ユーザクライアント端末から取得する手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段とを有し、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするサーバを提供するものである。

本発明の第６の態様においては、各ユーザクライアント端末から、回覧対象文書データの回覧順序の変更箇所を取得する手段と、ユーザクライアント端末から回覧順序の変更箇所を取得した回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所を変更した後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することが好ましい。

また、上記目的を達成するため、本発明は、第７の態様として、ネットワークを介して少なくとも一つのユクライアント端末と接続されるサーバであって、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、ユーザクライアント端末から取得する手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段と、ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、ユーザクライアント端末から要求された回覧順序の変更箇所を変更後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とするサーバを提供するものである。

本発明の第７の態様においては、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることが好ましい。

本発明の第６の態様又は第７の態様の上記のいずれの構成においても、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して所定の期間が経過したことを通知する手段を有することが好ましい。

また、本発明の第６の態様又は第７の態様の上記のいずれの構成においても、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更することが好ましく、これに加えて、ユーザクライアント端末からの要求に応じ、要求元のユーザクライアント端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして要求元のユーザクライアント端末へ送信する手段と、回覧予定文書データの承認結果をユーザクライアント端末から取得する手段と、任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を回覧対象文書データの承認結果とする手段とを有することがより好ましい。

また、上記目的を達成するため、本発明は、第８の態様として、ネットワークを介して接続されたサーバと情報を送受信する機能を有するクライアント端末を制御するコンピュータを、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバに送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段と、として機能させ、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするクライアントプログラムを提供するものである。

本発明の第８の態様においては、コンピュータを、回覧対象文書データの回覧順序の変更箇所を取得する手段と、該回覧順序の変更箇所をサーバに通知する手段と、として機能させることが好ましい。

また、上記目的を達成するため、本発明は、第９の態様として、ネットワークを介して接続されたサーバと情報を送受信する機能を有するクライアント端末を制御するコンピュータを、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、回覧対象文書データ及び回覧ルート情報を、サーバへ送信する手段と、回覧対象文書データの送信要求をサーバに送信する手段と、回覧対象文書データをサーバから受信する手段と、サーバから受信した回覧対象文書データを出力する手段と、出力した回覧対象文書データに対する承認結果を取得する手段と、該承認結果をサーバへ送信する手段と、回覧対象文書データの回覧順序の変更箇所を取得する手段と、該回覧順序の変更箇所をサーバに通知する手段と、として機能させることを特徴とするクライアントプログラムを提供するものである。

本発明の第９の態様においては、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることが好ましい。

本発明の第８の態様又は第９の態様の上記のいずれの構成においても、コンピュータを、自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとしてサーバから取得する手段と、回覧予定文書データを出力する手段と、として機能させることが好ましく、これに加えて、コンピュータを、回覧予定文書データの承認結果を取得する手段と、取得した回覧予定文書データの承認結果を、サーバへ送信する手段と、として機能させることがより好ましい。

また、上記目的を達成するため、本発明は、第１０の態様として、ネットワークを介して少なくとも一つのユーザクライアント端末と接続されたサーバを制御するコンピュータを、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、ユーザクライアント端末から取得する手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段と、として機能させ、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするサーバプログラムを提供するものである。

本発明の第１０の態様においては、コンピュータを、各ユーザクライアント端末から、回覧対象文書データの回覧順序の変更箇所を取得する手段と、ユーザクライアント端末から回覧順序の変更箇所を取得した回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを確認する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所を変更した後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段と、として機能させることが好ましい。

また、上記目的を達成するため、本発明は、第１１の態様として、ネットワークを介して少なくとも一つのユクライアント端末と接続されるサーバを制御するコンピュータを、文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、ユーザクライアント端末から取得する手段と、ユーザクライアント端末から取得した回覧ルート情報の示す回覧順序が、回覧規則情報格納手段に格納されている回覧規則情報が示す規則に適合するか否かを判断する手段と、回覧順序が、回覧規則情報に適合すると判断した回覧対象文書データを、ユーザクライアント端末からの要求に応じて送信する手段と、ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、回覧規則情報が示す規則に適合するか否かを判断する手段と、ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段と、として機能させることを特徴とするサーバプログラムを提供するものである。

本発明の第１１の態様においては、回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることが好ましい。

本発明の第１０の態様又は第１１の態様の上記のいずれの構成においても、コンピュータを、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して所定の期間が経過したことを通知する手段として機能させることが好ましい。

また、本発明の第１０の態様又は第１１の態様の上記のいずれの構成においても、コンピュータに、任意の回覧順位の回覧者による回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更させることが好ましく、これに加えて、コンピュータを、ユーザクライアント端末からの要求に応じ、要求元のユーザクライアント端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして要求元のユーザクライアント端末へ送信する手段と、回覧予定文書データの承認結果をユーザクライアント端末から取得する手段と、任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を回覧対象文書データの承認結果とする手段と、として機能させることがより好ましい。

本発明によれば、電子文書を円滑に回覧できる文書管理システム、クライアント端末、サーバ、クライアントプログラム及びサーバプログラムを提供できる。

〔第１の実施形態〕
本発明を好適に実施した第１の実施形態について説明する。図１に本実施形態にかかる電子文書回覧システムの構成を示す。このシステムは、ユーザクライアント端末１、管理クライアント端末２、文書管理サーバ３、データベースサーバ（ＤＢＳ）４、メールサーバ５及びネットワークプリンタ６がネットワーク７を介して接続された構成である。各端末及びサーバはネットワーク７を介してデータを送受信する機能を備える。また、ネットワークプリンタ６は、ネットワーク７を介してデータを受信する機能を備える。

ユーザクライアント端末１は、承認申請クライアント１１、承認登録クライアント１２、承認変更クライアント１３及びマスタ情報クライアント１４を有する。これらのクライアントは、ユーザクライアント端末１の不図示ＣＰＵが不図示のＲＡＭをワークエリアとしてアプリケーションを実行することによって、該ＣＰＵ上に形成される。
承認申請クライアント１１は、ユーザが文書の承認を申請する際に用いられるクライアントである。承認登録クライアント１２は、他者から文書の承認を要求されたユーザが、文書を承認する際に用いられるクライアントである。承認変更クライアント１３は、文書の承認を申請したユーザが、承認フローを変更する際に用いられるクライアントである。マスタ情報クライアント１４は、データベースサーバ４に登録されているマスタ情報を変更したり、新たに登録したりする際に用いられるクライアントである。
なお、これらのクライアントの動作については、後段で説明する。

管理クライアント端末２は、文書変換クライアント２１、文書発行クライアント２２、メール送信クライアント２３を有する。これらのクライアントは、管理クライアント端末２の不図示ＣＰＵが不図示のＲＡＭをワークエリアとしてアプリケーションを実行することによって、該ＣＰＵ上に形成される。
文書変換クライアント２１は、承認申請クライアント１１によって承認を申請された文書のデータを所定のファイル形式に変換する。文書発行クライアント２２は、承認手続きが完了した文書を、正式な文書として登録したり、配信したりする処理を行う。メール送信クライアントは、承認処理の経過や結果などを電子メールによって関係者に通知する処理を行う。

文書管理サーバ３は、承認中電子文書ファイル格納部３１、正式版電子文書ファイル格納部３２、サーバプログラム３３を有する。
承認中電子文書ファイル３１は、ユーザクライアント１から承認が申請された文書のデータを格納する。正式版電子文書ファイル３２は、承認手続きが完了した文書のデータを格納する。サーバプログラム３３は、ユーザクライアント端末１及び管理クライアント端末２が備える各クライアント（承認申請クライアント１１、承認登録クライアント１２、承認変更クライアント１３、マスタ情報クライアント１４、文書変換クライアント２１、文書発行クライアント２２、メール送信クライアント２３）のそれぞれに対応するサーバ側のプログラム群を含んでおり、各クライアントと連動して所定の動作を実行する。サーバプログラム３３は、文書管理サーバ３の不図示ＣＰＵが不図示のＲＡＭをワークエリアとしてアプリケーションを実行することによって、該ＣＰＵ上に形成される。

データベースサーバ４は、承認中文書情報格納部４１、正式版文書情報格納部４２、マスタ情報格納部４３及びメール送信データ格納部４４を有する。
承認中文書情報格納部４１は、承認中の文書の書誌的な情報を格納する。正式版文書情報格納部４２は、承認手続が完了した文書の書誌的な情報を格納する。マスタ情報格納部４３は、文書の承認手続きを行うために必要な定義に関する情報を格納する。メール送信データ格納部４４は、メール送信クライアント２３が電子メールとして送信するデータを格納する。

図２に、承認中文書情報のデータ構造を示す。承認中文書情報は、承認申請テーブル、承認フロー詳細テーブル、承認申請文書ファイルテーブル、文書要求テーブル、文書要求関連文書テーブル、文書要求無効文書テーブル及び文書要求配布先テーブルを有する。
承認申請テーブルは、承認の対象となる文書を特定するための情報と文書の状態とを表す。承認フロー詳細テーブルは、承認フロー各段における認証者や処理状態を表す。承認申請文書ファイルテーブルは、承認の対象となる文書がどのようなファイルによって構成されているかを表す。文書要求テーブルは、承認の対象となる文書の状態を表す。要求文書関連文書テーブルは、承認対象の文書に関連づけられている他の文書を特定する情報を表す。文書要求無効文書テーブルは、承認対象の文書が発行された場合に無効とすべき文書を特定するための情報である。文書要求配布先テーブルは、承認対象の文書が発行された場合に、どこにどれだけの量をどのようにして配布するかを表す情報である。
なお、承認フロー詳細テーブル、承認申請文書ファイルテーブル及び文書要求テーブルは、承認申請テーブルに付随する情報である。また、文書要求関連文書テーブル、文書要求無効文書テーブル及び文書要求配布先テーブルは、文書要求テーブルに付随する情報である。
承認対象の文書に関連文書や無効指定文書がない場合には、文書要求関連文書テーブルや文書要求無効文書テーブルは存在しない。

図３に、正式版文書情報のデータ構造を示す。正式版文書情報は、文書テーブル、配布先テーブル、無効文書テーブル、文書発行履歴テーブル、関連文書テーブル、承認フロー詳細テーブル及び発行通知テーブルを有する。
文書テーブルは、文書を特定するための情報とその状態とを表す。配布先テーブルは、どこにどれだけの量をどのようにして配布したのかを表す。文書無効テーブルは、文書を発行した際に無効とした文書を特定するための情報を表す。文書発行履歴テーブルは、現在までの発行の履歴を表す。承認フロー詳細テーブルは、どのような承認フローを経て文書が発行されたのかを表す。関連文書テーブルは、関連文書として登録されている文書を特定するための情報である。発行通知テーブルは、文書の発行・無効を区別し、発行の場合は文書をどこにどれだけ配信したか、無効の場合はどこにどれだけ配信されていたかを表す情報である。
なお、承認フロー詳細情報は、文書発行履歴情報に付随するデータである。配布先情報、無効文書情報及び関連文書情報は文書情報に付随するデータである。
承認申請時に関連文書や無効指定文書が登録されていなかった場合には、関連文書テーブルや無効文書テーブルは存在しない。

図４に、マスタ情報格納部４３に格納されているマスタ情報のデータ構造例を示す。
マスタ情報には、採番マスタ、役職マスタ、部門マスタ、ユーザマスタ、発行通知マスタ、申請文書マスタ、申請種類マスタ、承認フローテンプレート及び承認フローユーザテンプレートがある。マスタ情報は、認証処理を実行する上で必要となる情報のデータ構造を表している。
採番マスタは、承認対象の文書に対して申請番号を付与するために用いる情報のデータ構造を示す。役職マスタは、役職コードと役職名との対応を示す情報のデータ構造を示す。部門マスタは部門コードと部門名称及び配信先プリンタとの対応を示す情報のデータ構造を示す。ユーザマスタは、各ユーザの個人情報のデータ構造を示す。発行通知マスタは、文書を発行した際にどの部門の誰に通知するかを示す情報のデータ構造を示す。申請文書マスタは承認申請した文書を示す情報のデータ構造を示す。申請種類マスタは、どの申請種類で承認申請がされたかを示す情報のデータ構造を示す。承認フローテンプレートは、任意の申請文書、申請種類、順位における認証の種類（査閲、承認、合議など）とそれを行う権限を持つ最低の役職とを示す情報のデータ構造を示す。

図５に、承認フローテンプレートの具体例を示す。承認フローテンプレートは、申請文書と申請種類とによるマトリックス状に分類できる。例えば、申請文書として「規程」、申請種類として「新規」を選択した場合、申請した文書が発行されるためには、最初に主任以上の役職の者による査閲を必要とし、次に、部長以上の役職の者による承認を必要とし、続いて課長以上の役職の者による合議を必要とし、最後に部長以上の役職の者による最終承認を必要とすることを意味する。

このシステムにおいては、電子メールデータを作成しうるクライアントやサーバプログラムは複数存在する。各クライアントやサーバプログラムが作成した電子メールデータは、データベースサーバ４のメール送信データ格納部４４に格納される。メール送信データ格納部４４に格納されているメールデータは、メール送信クライアント２３の処理によって実際に送信される。
この動作について図６を用いて説明する。メール送信クライアント２３は、起動時に設定ファイルを読み込んで処理インターバル時間、メールサーバアドレス、エラー時メール送信アドレスなどを取得する。そして、メール送信データの未処理（処理フラグ：０）のデータを取得して、処理中（処理フラグ：１）に更新する。次に、実際にメールサーバ宛に送信処理を行って処理済み（処理フラグ：２）に更新する。これを所定時間（インターバル時間）ごとに繰り返す。処理中に何らかのエラー（メールサーバの停止、メールアドレスの間違い）が発生した場合は、エラー時メール送信アドレス（例えば、申請者のメールアドレス）にエラー通知すると共に、その文書のステータスをエラー（処理フラグ：Ｅ）とする。

本実施形態にかかる電子文書回覧システムの動作について説明する。
図７に、承認申請処理の動作の流れを示す。文書の承認を希望するユーザの入力操作に応じて、承認申請クライアント１１は、承認の対象となる文書ファイルを文書管理サーバ３へアップロードする（ステップＳ１０１）。図８に、文書ファイルをユーザクライアント端末１（端末名：PC1）から文書管理サーバ３へアップロードする動作の具体例を示す。ここでは、文書ファイル１.docと文書ファイル２.xlsとの二つのファイルからなる文書をアップロードするものとする。
承認申請クライアント１１からの要求に応じて、承認申請サーバプログラムは、所定のフォルダにユーザクライアント端末１の文書ファイル（文書ファイル１.doc、文書ファイル２.xls）を読み込む。このときファイル名は、ユーザクライアント端末名と連番との組合せへと変更し、拡張子は変更しない。上記の例では、PC1-1.doc及びPC-2.xlsというファイル名に変換される。

次に、承認申請サーバプログラムは、ユーザが承認申請クライアントに対して入力操作を行った文書に関する情報や承認フローに関する情報を、ユーザクライアント端末１から取得する。

承認申請サーバプログラムは、未完成の承認申請テーブルに含まれる申請文書コードを参照し、その申請文書コードに対応する採番マスタから承認申請番号を取得する（ステップＳ１０２）。この承認申請番号は、採番マスタの採番体系に従って組み立てられる。また、申請文書に対して申請可能な申請種類の登録もマスタ情報（申請種類マスタ）として登録されている。
なお、申請種類が発行済み文書に対する申請（新規以外の申請）の場合は、承認申請サーバプログラムは、発行済み文書の正式版文書情報を参照し、文書テーブルの申請中フラグを立てることにより、同じ文書に対して承認申請が多重に行われないようにする。

次に、承認申請サーバプログラムは、文書番号を採番する。
承認種類が新規発行の場合、承認申請クライアントから入力された文書記号と文書工程区分とを基に、文書連番を取得して、文書番号体系に沿って文書番号を採番する。この具体例を図９に示す。文書記号と文書工程区分とをキーとして、文書記号マスタを取得する。次に、文書記号マスタに含まれる連番の値を取得し、これを１インクリメントした値で＄ＮＮＮＮ＄の部分を置換する。連番の値の桁数が３以下の場合は、０を付加して４桁の値とする。そして、＄ＥＤＩＴ２＄の部分を版数（ここでは、新規承認なので０１）で置換する。
一方、承認種類が新規以外の場合は、発行済み文書の正式版文書情報を参照し、文書番号末尾の版数をインクリメントすることによって文書番号を採番する。

次に承認申請サーバプログラムは、承認申請クライアント１１がユーザからの入力操作によって取得した各承認順位における承認者に関する情報が承認フローテンプレートに適合するかをチェックする。このチェックは、承認フローテンプレートに設定されている役職コードと、承認申請クライアントを用いてユーザが入力したユーザ情報に含まれる役職コードとを比較することで行う（ステップＳ１０３）。
なお、承認申請サーバプログラムは、任意の承認順位において、承認者が複数人になることは妨げない。すなわち、任意の承認順位に関して、承認者として指定されている全ての者が、承認フローテンプレートに定められている役職コードが表す役職よりも上位の役職であるか否かを確認する。

承認フローに問題が無いことを確認したのち、承認申請サーバプログラムは、最初の承認順位の承認者のユーザＩＤ（承認ユーザＩＤ）を基にユーザ情報を参照して、承認依頼通知メールを送信するために必要となる情報（メールアドレスなど）を取得し、メール送信データ格納部４４に格納する（ステップＳ１０４）。承認依頼通知メールのメール送信データをメール送信データ格納部４４に格納した後、承認申請サーバプログラムは、最初の順位の承認フロー詳細テーブルの「承認依頼済みフラグ」を立てる。

なお、最初の承認者が申請者と同一である場合には、承認申請サーバプログラムは、承認フロー詳細情報の中の「承認登録ステータス」の項目を「済」に変更した上で２番目の承認者ユーザＩＤを基にユーザ情報を参照し、承認依頼通知メールを送信するために必要となる情報を取得して、メール送信データ格納部４４に格納する。これにより、申請者自身による承認登録が省略され、承認処理が円滑に行われる。

メール本文は、メールの種類ごとにフォーマットが予め登録されており、フォーマット中の可変分（承認申請番号や文書番号など）が、承認申請クライアント１１で入力した値（又は文字列）や承認申請サーバプログラムが取得した値に置き換えられる。これは、他のクライアントやサーバプログラムに関しても同様である。

次に、承認申請サーバプログラムは、承認申請された文書に関連文書が登録されているか否か（文書要求関連文書テーブルの有無）を確認し、登録されているのであれば文書要求関連文書テーブルを参照して関連文書の承認申請番号を取得する。そして、取得した承認申請番号を基に正式版文書情報格納部４２内のデータを参照し、その承認申請番号に該当する文書が発行済みであるか否かを調べる（ステップＳ１０５）。

続いて、承認申請サーバプログラムは、承認申請された文書に無効指定文書が登録されているか否か（文書要求無効文書テーブルの有無）を確認し、登録されているのであれば文書要求無効文書テーブルを参照して無効指定文書の承認申請番号を取得する。そして、取得した承認申請番号を基に正式版文書情報格納部４２内のデータを参照し、その承認申請番号に該当する文書が発行済みであるか否かを調べる（ステップＳ１０６）。

関連文書や無効指定文書の存在を確認した後、承認申請サーバプログラムは、承認申請された文書の承認中文書情報を承認中文書情報格納部４１に格納する（ステップＳ１０７）。

そして、承認申請クライアント１１からアップロードされている文書ファイルのファイル名を「承認申請番号−連番．拡張子」に変更した上で、所定のフォルダに移動する（ステップＳ１０８）。承認申請サーバプログラムは、承認申請文書ファイル情報に、変換後のファイル名を登録する。

以上のような動作によって、文書の承認申請が行われる。

次に、文書変換フローについて説明する。
図１０に、文書変換処理の動作の流れを示す。管理クライアント端末２内の文書変換クライアント２１は、メール送信クライアント２３と同様に、起動時に設定ファイルを読み込む。まず、承認中電子文書ファイル格納部３１にデータが登録されているが、文書変換が未了（文書変換済みフラグ：０）である電子文書の承認申請情報を取得する（ステップＳ２０１）。文書変換クライアント２１は、文書変換クライアントは、文書変換が未了の電子文書の文書ファイルのダウンロードを文書変換サーバプログラムに要求する。文書変換サーバプログラムは、文書変換クライアントからの要求に応じ、所定のフォルダに登録されている文書変換未了の文書ファイルを読み出し、管理クライアント端末２の所定のフォルダへ送信する（ステップＳ２０２）。文書変換クライアント２１は、ダウンロードした文書ファイルを特定の形式（例えば、Docuworks形式）のファイルに変換する（ステップＳ２０３）。
なお、一つの文書に複数のファイルが含まれる場合、文書変換クライアント２１は個別にファイル形式を変換し、変換した文書ファイルを結合し（ステップＳ２０４）、結合後の文書ファイルのファイル名を変更する（ステップＳ２０５）。文書が一つのファイルで構成される場合には、これらのステップはスキップされる。

その後、文書変換クライアント２１は、所定の位置にアノテーションを付加する（ステップＳ２０６）。アノテーションは文書に付加される注釈であり、電子データとして文書に組み込まれ、文書本体と共に表示・印刷される。アノテーションは、任意の文章やマークなどを用いて構成可能である。例えば、文書の各頁に発行日などの文字列や社章のようなマーク、あるいはこれらの組合せを付加することが可能である。
なお、アノテーションの付加は任意の処理であり、必ずしもこれを付加しなければならない訳ではない。

次に、文書変換クライアント２１は、アノテーションを付加後のデータを文書管理サーバ３へ送り、文書管理サーバ３内の所定のフォルダにアップロードする（ステップＳ２０７）。この際、文書変換クライアント２１からの要求に応じて、文書変換サーバプログラムが所定のフォルダにデータを格納する。
なお、文書変換クライアント２１は、アップロード完了後に管理クライアント端末２内の変換済み文書ファイルを削除する。
また、文書変換クライアント２１は、文書管理サーバ３からダウンロードした文書ファイルを文書管理サーバ３内のバックアップ用フォルダにアップロードする（ステップＳ２０８）。

ここで、図１１を用いて、文書変換時の動作について具体例を挙げて説明する。
承認申請クライアント１１からアップロードされ、承認申請サーバプログラムによる処理を終えた承認申請中の文書の承認申請番号がBSH-20050601-001、申請種類が新規発行で採番された文書番号がAXX-CA-1234-01であるとする。また、承認申請された文書は、BSH-20050601-001-01.doc、BSH-20050601-001-02.xls及びBSH-20050601-001-03.docの三つのファイルで構成されるものとする。
まず、文書変換クライアント２１は、データベースサーバ４の承認中文書情報格納部４１内のデータを参照し、承認申請番号BSH-20050601-001の文書ファイル情報を取得する。次に、文書変換クライアント２１は、文書変換サーバプログラムに依頼して、文書管理サーバ３内の所定のフォルダから同じく管理クライアント端末２内の所定のフォルダへ文書ファイルをダウンロードする。なお、ダウンロードの際にはファイル名は変更しない。
次に、文書変換クライアント２１は、ダウンロードした文書ファイルのデータ形式を同じフォルダ内でDocuworks形式に変換する。このとき、ファイル名は、BSH-20050601-001-01.XDW、BSH-20050601-001-02.XDW及びBSH-20050601-001-03.XDWとなる。なお、変換後の各ファイルには、変換前のファイルがオリジナルとして添付されている（換言すると、変換後のデータには変換前のデータが含まれている）。

文書変換クライアント２１は、変換後のファイルを結合する。これは以下のような手順で行う。
まず、BSH-20050601-001-01.xdwの後にBSH-20050601-001-02.xdwを結合してBSH-20050601-001-00.xdwというファイルを作成する。次に、結合前のBSH-20050601-001-01.xdwを削除する。そして、BSH-20050601-001-00.xdwのファイル名をBSH-20050601-001-01.xdwにリネームする。最後に、リネームしたBSH-20050601-001-01.xdwの後にBSH-20050601-001-03.xdwを結合してBSH-20050601-001-00.xdwを作成する。

その後、文書変換クライアント２１は、BSH-20050601-001-00.xdwのファイル名をBSH-20050601-001.xdwにリネームする。そして、結合前のBSH-20050601-001-02.xdwとBSH-20050601-001-03.xdwとを削除する。

次に、文書変換クライアント２１は、変換後の文書ファイルにアノテーションを付加する。そして、文書変換クライアント２１は、文書変換サーバプログラムに依頼して、BSH-20050601-001.xdwを文書管理サーバ３へアップロードし、さらに、文書変換前のデータを文書管理サーバ３のバックアップフォルダへアップロードする。

以上のような動作によって、文書ファイルのファイル形式が変換され、複数のファイルが一つに結合される。

次に、文書の承認をされた者が文書を承認（又は否認）する場合のシステムの動作について説明する。図１２に、承認登録処理の動作の流れを示す。
承認登録クライアント１２は、ユーザクライアント端末１のユーザがシステムにログインした際に、ログインしたユーザが承認を行うべき文書で、承認処理が未了のものが存在するか否かを確認する（ステップＳ３０１）。これは、承認登録クライアント１２が承認中文書情報格納部４１内の承認フロー詳細テーブルを確認し、ログインしたユーザのＩＤが承認ユーザＩＤとして登録されており、かつ承認登録ステータスが承認中であるデータが存在するか否かを調べることによって行われる。

承認処理が未了の文書が存在しなければ（ステップＳ３０２／なし）、処理を終了する。一方、承認処理が未了の文書が存在するのであれば（ステップＳ３０２／あり）、承認登録クライアント１２は、承認処理が未了の文書の承認申請情報を承認中文書情報格納部４１から読み出してユーザに提示する（ステップＳ３０３）。そして、提示した承認申請情報のいずれかを選択する入力操作がユーザによって行われると、承認登録クライアント１２は、その文書のダウンロードを承認登録サーバプログラムに要求する。承認登録サーバプログラムは、承認登録クライアント１２からの要求に応じ、承認中電子文書ファイル格納部３１に格納されている文書ファイルを読み出し、これを要求元のユーザクライアント端末１へ送信する。文書ファイルを取得した承認登録クライアント１２は、文書をユーザに提示する（ステップＳ３０４）。

文書の内容を確認したユーザによって、承認及び否認のいずれかを選択するための入力操作がなされると、承認登録クライアント１２は、入力操作の内容を取得する（ステップＳ３０５）。なお、文書の内容を確認せずに承認のみを行う行為を防止するために、承認登録クライアント１２は、文書をユーザクライアント端末１で表示した後でなければ承認のための入力操作をユーザが行えないようにすることが好ましい。

ユーザによってなされた入力操作が、承認申請されている文書を否認するものであれば（ステップＳ３０６／否認）、承認登録クライアント１２は、承認フロー詳細テーブルを参照して申請者及び承認登録済みの承認者のユーザＩＤを取得し、さらに取得したユーザＩＤを基にユーザ情報を参照してこれらの者のメールアドレスを取得する。そして承認申請されている文書が否認されたことを示す「否認完了メール」をこれらの者に送信するための情報を生成し、メール送信データ格納部４４に格納する（ステップＳ３０７）。なお、承認登録クライアント１２は、承認フロー詳細テーブルを参照した際に、承認依頼済みで承認処理が完了していない承認者が存在するのであれば、上記同様にしてその者のメールアドレスを取得し、承認依頼取り消すためのメールをその者に対して送信するための情報も生成し、メール送信データ格納部４４に格納する。

一方、ユーザによってなされた入力操作が、承認申請されている文書を承認するものであれば（ステップＳ３０６／承認）、承認登録クライアント１２は、承認中電子文書情報格納部４１に格納されている承認フロー詳細テーブルを参照し、承認フローを確認する（ステップＳ３０８）。

同じ順位の承認者が存在するのであれば（ステップＳ３０９／あり）、処理を終了する。
同じ順位の承認者が存在しなければ（ステップＳ３０９／なし）、次の順位の承認者が存在するか否かを確認する（ステップＳ３１０）。次の順位の承認者が存在するのであれば（ステップＳ３１０／あり）、承認登録クライアント１２は承認フロー詳細テーブルを参照して、次の順位の承認者のユーザＩＤを取得し、さらに取得したユーザＩＤを基にユーザ情報を参照してメールアドレスを取得する。そして、文書の承認依頼メールを作成するためのデータを生成し、メール送信データ格納部４４に格納する（ステップＳ３１１）。なお、次の順位における承認者が複数の場合には、全員に承認依頼メールを送信するようにメール送信データを作成する。

次の順位の承認者が存在しないのであれば（ステップＳ３１０／なし）、その承認者が最終承認者であるから、承認登録クライアント１２は承認申請情報のステータスを「承認完了」に書き換える。そして、申請者に対して認証処理が完了した旨を通知するためのメールを送信するための情報を生成し、メール送信データ格納部４４に格納する（ステップ３１２）。

承認登録クライアント１２によってメール送信データ格納部４４に格納されたメール送信データは、メール送信クライアント１３によって、メールサーバ５へと送られ、各宛先へと配信される。

以上のような動作によって、承認申請がなされた文書の承認・否認が行われる。

次に、文書発行処理の動作の流れについて説明する。図１３に、文書発行時の動作の流れを示す。文書発行クライアント２２が所定のタイミングで文書発行サーバプログラムへトリガを発することによって、動作が開始される。
文書発行サーバプログラムは、承認中文書情報の承認申請テーブルを参照し、ステータスが「承認完了」となっている文書があるか否かを確認する（ステップＳ４０１）。ステータスが「承認完了」となっている文書があれば（ステップＳ４０２／あり）、文書発行サーバプログラムは、承認中文書情報格納部４１に格納されている承認中文書情報を基に正式版文書情報を生成し、これを正式版文書情報報格納部４２へ格納する（ステップＳ４０３）。この際文書発行サーバプログラムは、申請種類に関わらず文書情報に付随するデータとして文書発行履歴情報を必ず生成する。承認フロー詳細情報は、文書発行履歴情報に付随するデータとして生成される。配布先情報、無効文書情報及び関連文書情報は文書情報に付随するデータとして生成される。

さらに、文書発行サーバプログラムは、その文書に無効指定文書が存在するのであれば、指定された文書記号、文書区分及び連番を基に、無効化の対象である文書の文書情報を取得し、その文書を無効とする処理を行う（ステップＳ４０４）。これは、その文書の文書情報の「文書ステータス」の項目を「無効」とすることによって行う。

そして、文書発行サーバプログラムは、どの文書が正式な文書として発行されたかを示す「発行通知メール」及びどの文書が無効とされたかを示す「無効通知メール」を送信するために必要なデータ（文書番号、宛先メールアドレス）を生成する（ステップＳ４０５）。これは、発行しようとする文書の配布先情報を参照することによって行う。

そして、文書発行サーバプログラムは、正式な文書として発行する文書のファイルを承認中電子文書ファイル格納部３１から読み出し、管理クライアント２内の所定のフォルダにダウンロードする（ステップＳ４０６）。

文書発行クライアント２２は、ダウンロードした文書の承認フロー詳細情報を基に承認履歴情報を生成する。例えば、文書発行クライアントは、「承認申請番号−rireki.txt」というファイル名のテキストデータとして承認履歴情報を生成する。
そして、文書発行クライアントは、このテキストデータをDocuworks形式に変換し、必要に応じてアノテーションを付加した後、ダウンロードした文書ファイルの末尾に結合することによって正式版電子文書ファイルを生成する（ステップＳ４０７）。

文書発行クライアント２２は、生成した正式版電子文書ファイルを正式版電子文書ファイル格納部３２にアップロードする（ステップＳ４０８）。ここでアップロードした電子文書ファイルは、正式版の原本となるデータである。アップロードが完了すると、文書発行サーバプログラムは、アップロードした文書の文書情報の文書ステータスを「発行済み」に更新する。

次に、文書発行サーバプログラムは、配布先情報を参照して、普通紙や無塵紙での配布の指定があるか否かを確認する（ステップＳ４０９）。指定があれば（ステップＳ４０９／あり）、文書発行サーバプログラムは、部門情報を参照して配布先のプリンタを表す情報（配信先プリンタ設定）を取得する。そして、文書発行サーバプログラムは、配布先として指定されているプリンタに対して配布先情報で定められている部数分の印刷を要求する（ステップＳ４１０）。その後、ステップＳ４０１に戻って、ステータスが「承認完了」となっている文書がまだ残っているか確認し、あれば上記同様の動作を行う。

また、普通紙や無塵紙での配布の指定がない場合（ステップＳ４０９／なし）も同様に、ステップＳ４０１に戻ってステータスが「承認完了」となっている文書がまだ残っているか確認し、あれば上記同様の動作を行う。

ステータスが「承認完了」となっている文書が無ければ（ステップＳ４０２／なし）、文書発行サーバプログラムは、発行通知データがあるか否かを確認する（ステップＳ４１１）。発行通知データがあるならば（ステップＳ４１１／あり）、文書発行サーバプログラムは、所定のフォーマットに従って発行通知メールや無効通知メールを作成する（ステップＳ４１２）。この際、同じ宛先に複数の発行通知メールや無効通知メールを送るのであれば、それらをまとめて一つの発行通知メールや無効通知メールを生成するようにしてもよい。例えば、部署Ａに文書Ａと文書Ｂとの発行を通知するのであれば、一つでこれらを通知するようにメールを生成してもよい。なお、一つの部署に発行通知メールと無効通知メールの両方を送るのであれば、これらは別々のメールとしてもよい。例えば、部署Ａに、文書Ａ及び文書Ｂの発行並びに文書Ｃ及び文書Ｄの無効を通知するのであれば、で文書Ａ及び文書Ｂの発行を通知するメール（発行通知メール）と、文書Ｃ及び文書Ｄの無効を通知するメール（無効通知メール）とを別個に生成してもよい。

発行通知メールや無効通知メールを生成したら、文書発行サーバプログラムはそれをメールサーバ５へ送り、メールの送信を依頼する（ステップＳ４１３）。

以上のような動作によって、承認が完了した文書が発行される。

文書に有効期限が設定されている場合には、所定の時刻となった時に文書を無効とする処理を行う。この際の動作について説明する。
図１４に、文書期限切れ処理の動作の流れを示す。
サーバプログラム３３の一つである文書期限切れ処理プログラムは、所定の間隔（例えば、毎午前零時）で起動され、その際に、文書管理サーバ３に登録されている時刻情報を取得する（ステップＳ５０１）。文書発行サーバプログラムは、データベースサーバ４の正式版文書情報格納部４２に格納されている正式版文書情報を参照し、有効期限が現在時刻よりも前となっている文書の有無を調べる（ステップＳ５０２）。有効期限を超過している文書があれば（ステップＳ５０２／あり）、その文書の正式版文書情報の文書テーブルに含まれる文書ステータスを「無効」とする（ステップＳ５０３）。その後、文書期限切れ処理プログラムは、配布先テーブルを参照し、無効とした文書の配布先であったところを宛先として、期限切れのため文書を無効としたことを通知する「期限切れ通知メール」を作成する（ステップＳ５０４）。作成したメールデータは、メール送信データ格納部４４に格納し、メール送信クライアント２３によって送信される。

このような動作によって、有効期限が切れた文書は無効化される。

以上の各動作によって、文書の承認申請及び承認登録がなされ、承認が完了した文書が発行されることとなるが、何らかの事情によって承認フローを変更する必要が生じることもある。この場合の動作について次に説明する。

図１５及び図１６に、承認フロー変更処理の動作の流れを示す。
承認変更クライアント１３は、起動時に、ユーザクライアント端末１のユーザのユーザＩＤを取得し、これを基に承認中文書情報格納部４１内の承認申請情報を参照し、要求ユーザＩＤの項目が自端末のユーザのＩＤと一致する承認中文書の承認申請番号を取得する。承認変更クライアント１３は、取得した承認申請番号をユーザに提示して選択を要求する。承認変更クライアント１３は、ユーザの入力操作によって選択された承認申請番号の文書を対象として承認フローの変更処理を行う。すなわち、一旦承認申請がなされた文書の承認フローを変更できるのは申請者のみである。

承認変更クライアント１３は、現在の承認フローをユーザに提示して変更箇所の指定及び変更内容の入力を要求する（ステップＳ６０１）。ユーザの操作によって承認フローの任意の箇所に変更内容が入力されると、承認変更クライアント１３は、変更内容が入力された箇所について承認フロー詳細テーブルの承認登録ステータスの項目を参照し、変更前の承認者が承認済みであるか否かを確認する（ステップ６０２）。

変更前の承認者が承認済みであるならば（ステップＳ６０２／了）、その部分については承認フローの変更を許可せず処理を終了する。一方、変更前の承認者が承認済みでないならば（ステップＳ６０２／未了）、変更内容を承認変更サーバプログラムへ通知する。変更内容の通知を受けた承認変更サーバプログラムは、承認フロー詳細テーブルの承認登録ステータスの項目を参照し、変更前の承認者が承認済みであるか否かを確認する（ステップＳ６０３）。

変更前の承認者が承認済みであるならば（ステップＳ６０３／了）、その部分については承認フローの変更を許可せず処理を終了する。一方、変更前の承認者が承認済みでないならば（ステップＳ６０３／未了）、承認変更サーバプログラムは、変更後の承認者のユーザＩＤを基に、その者の役職コードを取得する（ステップＳ６０４）。

そして、承認順位が変更された箇所については、変更後の承認者の承認順位が承認テンプレートに登録されているか否かを確認する。例えば、図５に示した承認テンプレートにおいて「限度見本−改版」がテンプレートとして選択されているならば、承認順位としては１〜３しか取り得ないため、変更後の承認順位がこの範囲内にあるか否かを確認する（ステップＳ６０５）。
変更後の承認順位が承認フローテンプレートに登録された範囲に無ければ（ステップＳ６０５／Ｎｏ）、承認フローの変更を許可せずに処理を終了する。一方、変更後の承認順位が承認フローテンプレートに登録された範囲にあれば（ステップＳ６０５／Ｙｅｓ）、変更後の承認区分が承認フローテンプレートに登録されたものと同じであり、かつ、変更後の承認者が承認フローテンプレートに登録されている最低限の役職よりも上位の役職にあるか否かを確認する（ステップＳ６０６）。例えば、承認フローテンプレートが「限度見本−改版」であれば、承認順位１位は「査閲」、承認順位２位は「承認」、承認順位３位は「合議」でなければならず、承認順位１位を「承認」とするような変更内容は、承認フローテンプレートに登録されている内容と一致しないと判断する。また、承認権限を有する最低限の役職は、承認順位１位では「主任」、承認順位２位では「課長」、承認順位３位では「主任」であるから、承認順位２位の承認者に役職が主任である者を指定する変更は、変更後の承認者に承認の権限が無いと判断する。変更後の承認区分が承認フローテンプレートに登録されている内容と一致しない場合や、変更後の承認者に承認の権限が無い場合には（ステップＳ６０６／Ｎｏ）、承認変更サーバプログラムは、承認フローの変更を許可せずに処理を終了する。一方、変更後の承認区分が承認フローテンプレートに登録されている内容と一致し、かつ変更後の承認者に承認の権限がある場合には（ステップＳ６０６／Ｙｅｓ）、承認変更サーバプログラムは、承認中文書情報（承認フロー詳細テーブル）を更新する（ステップＳ６０７）。

承認者を変更した場合、承認変更サーバプログラムは承認フロー詳細テーブルを参照して、変更前の承認者に対して承認依頼済みであるか否かを確認する（ステップＳ６０８）。既に承認を依頼済みであるならば（ステップＳ６０８／済み）、承認変更サーバプログラムは、変更前の承認者のユーザＩＤを基にユーザ情報を参照してメールアドレスを取得し、承認依頼を取り消す旨を通知するメールのデータを生成し、メール送信データ格納部４４に格納する（ステップＳ６０９）。

変更前の承認者に対して承認依頼済みでないならば（ステップＳ６０８／未了）、変更した箇所の承認順位が現在承認中の順位と一致するか否かを確認する（ステップＳ６１０）。一致しなければ（ステップＳ６１０／不一致）、承認申請クライアント１３は処理を終了する。一致するのであれば（ステップＳ６１０／一致）、承認変換サーバプログラムは変更後の承認者に対する承認依頼メールのデータを生成し、メール送信データ格納部４４に格納する（ステップＳ６１１）。

承認フロー変更の具体例を図１７に示す。ここでは、順位２のＢ課長をＤ課長に変更し、順位３にＥ主任を追加する変更を行おうとする場合を考える。
まず、順位１のＡ主任は、承認登録済みであるため、承認変更クライアント１３はこれを変更しようとする要求がユーザからなされた場合にはその要求を却下するが、ここでは変更の対象は承認登録が未了のＢ課長であるため、承認変更クライアントは他の要件を満たすか確認する。そして、ここで行おうとする変更は、承認区分を変更するものではなく、また、順位２の承認者をＤ課長とする変更及び順位３の承認者としてＥ主任を追加する変更は、いずれも変更前の承認者と同じ役職の者を承認者として指定するものであるから、承認変更クライアント１３は、要求された承認フローの変更を有効に受け付け、変更内容を承認変更サーバプログラムへ通知する。
変更内容の通知を受けた承認変更サーバプログラムは、上記同様に変更後の承認フローが承認フローテンプレートに適合するかを確認するが、ここでは適合するため、承認中文書情報を更新する。
変更前の承認者であるＢ課長には、承認依頼メールを送信済みであるから、承認変更サーバプログラムは、承認依頼取消メールを生成する。また、変更後の承認者であるＤ課長は、現在の承認順位の承認者であるから、Ｄ課長に対する承認依頼メールを生成する。順位３の承認者として追加したＥ主任は、現在の承認順位の承認者ではないから、承認変更サーバプログラムはＥ主任に対する承認依頼メールは生成しない。

なお、承認依頼を取り消す場合、承認変更サーバプログラムは、承認フロー詳細情報そのものを削除（又は上書き）するのではなく、承認登録ステータスを「取消」と更新することによって承認依頼を取り消す。これにより、承認依頼を取り消したことを履歴として残すことができる。

このように、承認変更クライアント１３及び承認変更サーバプログラムは、予め定められている承認フローテンプレートに適合する範囲内でのみ承認フローの変更を許可する。このため、申請者が証人フローを変更したとしても、業務上の不都合が生じることはない。
また、既に承認処理を行った承認者を変更することを禁止するため、既に完了した承認処理が無駄になることはない。
なお、承認変更クライアント１３と承認変更サーバプログラムとで同じチェックを重複して行うことにより、承認変更クライアント１３でのチェック時に承認未完了であった承認者がその後で承認を完了したとしても、承認変更サーバプログラムが変更を却下することが可能となる。

〔第２の実施形態〕
本発明を好適に実施した第２の実施形態について説明する。システムの構成は、第１の実施形態と同様である。
本実施形態においては、承認する順番が回ってきていないユーザに対して、将来承認する予定の文書を提示することによって、順番が回ってきた際に速やかに承認を行えるようにする。また、承認の順番がくる前に閲覧した文書の承認結果を登録しておき、承認する順番が回ってきた段階でそれを正式な承認結果とすることによって、承認フローが円滑に進むようにする。

図１８に、本実施形態にかかる電子文書回覧システムの承認予約処理の動作の流れを示す。
承認登録クライアント１２は、承認フロー詳細テーブルを参照し、ユーザクライアント端末１のユーザが承認者として指定されており、且つ承認依頼済みフラグが未了の文書ファイルが存在するか否かを確認する（ステップＳ７０１）。該当するデータがあるならば（ステップＳ７０２／あり）、承認登録クライアント１２は、該当する文書ファイルのダウンロードを承認登録サーバプログラムに要求し、文書ファイルを取得する。また、その文書ファイルの承認中文書情報を承認中文書情報格納部４１から取得する。承認登録クライアント１２は、これらをユーザに提示して、確認を促す（ステップＳ７０３）。ユーザが仮承認登録のための入力操作を行ったならば（ステップＳ７０４／あり）、承認登録クライアント１２は、ユーザクライアント端末１のユーザが承認者として指定されている承認フロー詳細テーブルの承認登録ステータスの項目を「仮承認」に変更する（ステップＳ７０５）。

なお、ユーザクライアント端末１のユーザが承認者として指定されており、且つ承認依頼済みフラグが未了の文書ファイルが存在しない場合や（ステップＳ７０２／なし）、ユーザが仮承認登録のための入力操作を行わなかった場合には（ステップＳ７０４／なし）、処理を終了する。

図１９に、本実施形態にかかるシステムにおける通常の承認登録処理の動作の流れを示す。この動作は、第１の実施形態に係るシステムとほぼ同様であるが、ステップＳ３２１及びステップＳ３２２が追加されている。
ユーザがある文書を承認した場合、文書登録クライアント１２は次の順位の承認者が存在するか否かを確認するが、次の順位の承認者が存在する場合には（ステップＳ３１０／あり）、その承認者が仮承認を行っているか否かを確認する（ステップＳ３２１）。
次の順位の承認者が仮承認を行っていなければ（ステップＳ３２１／未了）、第１の実施形態と同様に、その者に対して承認依頼メールを送信する（ステップＳ３１１）。しかし、次の順位の承認者が仮承認を行っていれば（ステップＳ３２１／済み）、承認登録クライアント１２は、次の承認者の承認フロー詳細情報の承認登録ステータスを「仮承認」から「承認済」へ変更し（ステップＳ３２２）、さらに次の順位の承認者が存在するか否かを確認する（ステップＳ３１０）。
なお、ユーザが文書を否認した場合、文書登録クライアントは、それよりも高位の承認者（承認予定者）に対して文書が否認されたことを示すデータを生成し、そのデータをメール送信データ格納部４４に格納する。これにより、承認予定者は、自分が承認者となる予定であった文書が否認され、内容を確認する必要が無くなったことを知ることができる。

なお、高位の承認者が文書を否認する場合には、下位の承認者の承認結果に関わらずその文書は否認されることとなるため、承認予定者によって否認が予約された場合には、その時点で承認フローを中止するようにしても良い。
ただし、本実施形態においても承認フローの変更は可能であるため、予約された結果が正式な結果となるまで待ってから承認フローを中止するようにしても良い。もちろん、承認又は否認が予約された段階で、その承認予定者に関する承認フローの変更を禁止するようにしてもよい。

〔第３の実施形態〕
本発明を好適に実施した第３の実施形態について説明する。システムの構成は、第１の実施形態と同様である。
本実施形態においては、電子文書回覧システムは、所定の承認期限を超過しても承認者が承認処理を完了していない場合に、予め定められている別の者に承認者を変更する。

図２０に、承認者変更処理の動作の流れを示す。
承認変更クライアント１３は、ユーザクライアント端末１に設定されている時刻情報を取得する（ステップＳ８０１）。次に、承認変更クライアント１３は、承認フロー詳細テーブルを参照し、承認依頼済みで未承認かつ承認期限がユーザクライアント端末１に設定されている時刻よりも前の承認中文書ファイルがあるか否かを確認する（ステップＳ８０２）。

該当する承認中文書ファイルがあれば（ステップＳ８０３／あり）、承認変更クライアント１３は、承認期限を超過している承認依頼に関する承認フロー詳細テーブルに代理承認者が設定されているか否かを確認する（ステップＳ８０４）。

代理承認者が登録されていなければ（ステップＳ８０４／登録なし）、承認変更クライアント１３は、承認者に対して承認期限の超過を通知するメールを作成し、そのデータをメール送信データ格納部４４に格納する（ステップＳ８０５）。

代理承認者が登録されているならば（ステップＳ８０４／登録あり）、承認変更クライアント１３は、承認期限を超過している承認依頼に関する承認フロー詳細テーブルの承認登録ステータスの項目を「取消」に変更する（ステップＳ８０６）。

さらに、取り消した承認者に対して、承認依頼を取り消す旨を通知するメールを作成し、そのデータをメール送信データ格納部４４へ格納する（ステップＳ８０７）。

その後、承認変更クライアント１３は、代理承認者を承認者とする承認フロー詳細テーブルを生成する（ステップＳ８０８）。

承認変更クライアント１３は、新たに生成した承認フロー詳細テーブルに関して、承認者（元の代理承認者）に対して文書の依頼を依頼するメールを作成し、そのデータをメール送信データ格納部４４に格納する（ステップＳ８０９）。

承認変更クライアント１３は、該当するデータが無くなるまで（ステップＳ８０３でなしとなるまで）上記の動作を繰り返す。

本実施形態においては、認証フローの各段階において、代理承認者が登録されているならば、承認期限が超過した場合に自動的に代理承認者に文書の承認を依頼できる。このため、認証フローが停滞しにくくなる。

なお、上記各実施形態は本発明の好適な実施の一例であり、本発明はこれらに限定されることはない。
例えば、上記各実施形態においては、承認申請がなされた文書のファイル形式を特定の形式に変換する場合を例としたが、ファイル形式の変換は必ずしも行う必要はない。
また、上記各実施形態においては、文書管理サーバ３とデータベースサーバ４とが別個の構成である場合を例としたが、これらは一体の構成であっても良い。
また、管理クライアント端末２の機能は、ユーザクライアント１のいずれかが備えていてもよい。
また、第１の実施形態においては、申請者は承認フローを自由に変更可能であったが、承認フローの変更に関して承認フローテンプレートとは異なる制限を設けるようにしても良い。例えば、承認フローを変更可能な範囲を、申請者よりも上位の役職にある者が限定（一例をあげると、「同一部門内の課長以上」のように）できるようにしても良い。
また、第３の実施形態においては、承認期限を超過した場合に代理承認者に対して文書の承認を依頼する場合を例としたが、承認期限を超過する前に代理承認者に対して文書の承認を依頼してもよい。例えば、ユーザが承認不能であること（出張による長期不在など）を自発的に登録できるようにし、その登録がなされたユーザに承認の順番が回ってきた段階で代理承認者に対して申請中文書の承認を依頼するようにしても良い。
このように、本発明は様々な変形が可能である。

本発明を好適に実施した第１の実施形態に係る電子文書回覧システムの構成を示す図である。 承認中文書情報のデータ構造を示す図である。 正式版文書情報のデータ構造を示す図である。 マスタ情報のデータ構造を示す図である。 承認フローテンプレートの一例を示す図である。 メール送信クライアントによるメール送信処理を表す図である。 認証申請処理の動作の流れを示す図である。 承認対象文書をユーザクライアント端末から文書管理サーバへアップロードする処理を表す図である。 文書記号マスタの一例を示す図である。 文書変換処理の動作の流れを示す図である。 文書変換処理の動作の一例を表す図である。 文書承認登録時の動作の流れを示す図である。 文書発行処理の動作の流れを示す図である。 期限切れ文書無効化処理の動作の流れを示す図である。 承認フロー変更処理の動作の流れを示す図である。 承認フロー変更処理時の動作の流れを示す図である。 承認フロー変更処理の一例を示す図である。 予約承認処理の動作の流れを示す図である。 承認登録処理の動作の流れを示す図である。 承認者変更処理の動作の流れを示す図である。

符号の説明

１ ユーザクライアント端末
２ 管理クライアント端末
３ 文書管理サーバ
４ データベースサーバ
５ メールサーバ
６ ネットワークプリンタ
７ ネットワーク
１１ 承認申請クライアント
１２ 承認登録クライアント
１３ 承認変更クライアント
１４ マスタ情報クライアント
２１ 文書変換クライアント
２２ 文書発行クライアント
２３ メール送信クライアント
３１ 承認中電子文書ファイル格納部
３２ 正式版電子文書ファイル格納部
３３ サーバプログラム
４１ 承認中文書情報格納部
４２ 正式版文書情報格納部
４３ マスタ情報格納部
４４ メール送信データ格納部

Claims (38)

1. 少なくとも一つのユーザクライアント端末と、サーバとがネットワークを介して接続され、回覧対象の文書データを前記ユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、
   前記ユーザクライアント端末は、
   回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
   前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
   前記回覧対象文書データの送信要求を前記サーバへ送信する手段と、
   前記回覧対象文書データを前記サーバから受信する手段と、
   前記サーバから受信した回覧対象文書データを出力する手段と、
   前記出力した回覧対象文書データに対する承認結果を取得する手段と、
   該承認結果を前記サーバへ送信する手段とを有し、
   前記サーバは、
   文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
   前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
   回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段とを有し、
   前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする文書管理システム。
2. 前記ユーザクライアント端末は、前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
   該回覧順序の変更箇所を前記サーバに通知する手段とを有し、
   前記サーバは、前記ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、
   前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、
   前記ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則にと適合するか否かを判断する手段と、
   前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とする請求項１記載の文書管理システム。
3. 少なくとも一つのユーザクライアント端末と、サーバとがネットワークを介して接続され、回覧対象の文書データを前記ユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、
   前記ユーザクライアント端末は、
   回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
   前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
   前記回覧対象文書データの送信要求を前記サーバに送信する手段と、
   前記回覧対象文書データを前記サーバから受信する手段と、
   前記サーバから受信した回覧対象文書データを出力する手段と、
   前記出力した回覧対象文書データに対する承認結果を取得する手段と、
   該承認結果を前記サーバへ送信する手段と、
   自端末のユーザが回覧の申請者である回覧対象文書データの回覧順序の変更箇所を、ユーザの操作によって取得する手段と、
   該回覧順序の変更箇所を前記サーバに通知する手段とを有し、
   前記サーバは、
   文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
   前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
   回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段と、
   前記ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、
   前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、
   前記ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
   前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とする文書管理システム。
4. 前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする請求項３記載の文書管理システム。
5. 前記サーバは、任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して前記所定の期間が経過したことを通知する手段を有することを特徴とする請求項１から４のいずれか１項記載の文書管理システム。
6. 前記サーバは、任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更することを特徴とする請求項１から５のいずれか１項記載の文書管理システム。
7. 前記ユーザクライアント端末は、自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして前記サーバから取得する手段と、
   前記回覧予定文書データを出力する手段とを有することを特徴とする請求項１から６のいずれか１項記載の文書管理システム。
8. 前記ユーザクライアント端末は、前記回覧予定文書データの承認結果を取得する手段と、
   取得した前記回覧予定文書データの承認結果を、前記サーバへ送信する手段とを有し、
   前記サーバは、任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を前記回覧対象文書データの承認結果とすることを特徴とする請求項７記載の文書管理システム。
9. 前記回覧対象文書データが２以上の異なるファイル形式のデータ群で構成される場合に、これらのデータのファイル形式を特定の一つファイル形式に変換するとともに、一つに結合する手段をさらに有することを特徴とする請求項１から８のいずれか１項記載の文書管理システム。
10. 最下位の回覧順位の回覧者による前記回覧対象文書データの回覧が完了した際に、該回覧対象文書データの回覧が完了したことを所定のユーザに通知する手段を有することを特徴とする請求項１から９のいずれか１項記載の文書管理システム。
11. 任意の回覧順位において前記回覧対象文書データの認証結果が否認であった場合に、該回覧対象文書データの回覧申請者及び否認された回覧順位よりも上位の回覧者に、該回覧対象文書データが否認されたことを通知する手段を有することを特徴とする請求項１から１０のいずれか１項記載の文書管理システム。
12. 少なくとも一つのユーザクライアント端末と、管理クライアント端末と、サーバとデータベースとがネットワークを介して接続され、回覧対象の文書データを前記ユーザクライアント端末の複数のユーザで回覧する文書管理システムであって、
    前記ユーザクライアント端末は、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
    前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
    前記回覧対象文書データの送信要求を前記サーバへ送信する手段と、
    前記回覧対象文書データを前記サーバから受信する手段と、
    前記サーバから受信した回覧対象文書データを出力する手段と、
    前記出力した回覧対象文書データに対する承認結果を取得する手段と、
    該承認結果を前記サーバへ送信する手段とを有し、
    前記データベースは、
    文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
    回覧中の文書ファイルの状態を表す承認中文書情報が格納される承認中文書情報格納手段と、
    回覧が完了した文書ファイルの状態を表す正式版文書情報が格納される正式版文書情報格納手段とを有し、
    前記サーバは、
    前記ユーザクライアント端末から取得した回覧ルート情報に応じた前記回覧規則情報を、前記データベースから取得する手段と、
    前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記データベースから取得した回覧規則情報が示す規則に適合するか否かを判断する手段と、
    回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段とを有し、
    同じ回覧順位に複数の回覧者を設定可能であることを特徴とする文書管理システム。
13. ネットワークを介してサーバと情報を送受信する手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
    前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
    前記回覧対象文書データの送信要求を前記サーバに送信する手段と、
    前記回覧対象文書データを前記サーバから受信する手段と、
    前記サーバから受信した回覧対象文書データを出力する手段と、
    前記出力した回覧対象文書データに対する承認結果を取得する手段と、
    該承認結果を前記サーバへ送信する手段とを有し、
    前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするクライアント端末。
14. 前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    該回覧順序の変更箇所を前記サーバに通知する手段とを有することを特徴とする請求項１３記載のクライアント端末。
15. ネットワークを介してサーバと情報を送受信する手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
    前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
    前記回覧対象文書の送信要求を前記サーバに送信する手段と、
    前記回覧対象文書データを前記サーバから受信する手段と、
    前記サーバから受信した回覧対象文書データを出力する手段と、
    前記出力した回覧対象文書データに対する承認結果を取得する手段と、
    該承認結果を前記サーバへ送信する手段と、
    前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    該回覧順序の変更箇所を前記サーバに通知する手段とを有することを特徴とするクライアント端末。
16. 前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする請求項１５記載のクライアント端末。
17. 自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして前記サーバから取得する手段と、
    前記回覧予定文書データを出力する手段とを有することを特徴とする請求項１３から１６のいずれか１項記載のクライアント端末。
18. 前記回覧予定文書データの承認結果を取得する手段と、
    取得した前記回覧予定文書データの承認結果を、前記サーバへ送信する手段とを有することを特徴とする請求項１７記載のクライアント端末。
19. ネットワークを介して少なくとも一つのユーザクライアント端末と接続されたサーバであって、
    文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、前記ユーザクライアント端末から取得する手段と、
    前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段とを有し、
    前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするサーバ。
20. 前記各ユーザクライアント端末から、前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    前記ユーザクライアント端末から回覧順序の変更箇所を取得した回覧対象文書データの回覧状況を取得する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とする請求項１９記載のサーバ。
21. ネットワークを介して少なくとも一つのユクライアント端末と接続されるサーバであって、
    文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、前記ユーザクライアント端末から取得する手段と、
    前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段と、
    前記ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、
    前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、
    前記ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段とを有することを特徴とするサーバ。
22. 前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする請求項２１記載のサーバ。
23. 任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して前記所定の期間が経過したことを通知する手段を有することを特徴とする請求項１９から２２のいずれか１項記載のサーバ。
24. 任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更することを特徴とする請求項１９から２３のいずれか１項記載のサーバ。
25. 前記ユーザクライアント端末からの要求に応じ、要求元のユーザクライアント端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして前記要求元のユーザクライアント端末へ送信する手段と、
    前記回覧予定文書データの承認結果を前記ユーザクライアント端末から取得する手段と、
    任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を前記回覧対象文書データの承認結果とする手段とを有することを特徴とする請求項２４記載のサーバ。
26. ネットワークを介して接続されたサーバと情報を送受信する機能を有するクライアント端末を制御するコンピュータを、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
    前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
    前記回覧対象文書データの送信要求を前記サーバに送信する手段と、
    前記回覧対象文書データを前記サーバから受信する手段と、
    前記サーバから受信した回覧対象文書データを出力する手段と、
    前記出力した回覧対象文書データに対する承認結果を取得する手段と、
    該承認結果を前記サーバへ送信する手段と、として機能させ、
    前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするクライアントプログラム。
27. 前記コンピュータを、
    前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    該回覧順序の変更箇所を前記サーバに通知する手段と、として機能させることを特徴とする請求項２６記載のクライアントプログラム。
28. ネットワークを介して接続されたサーバと情報を送受信する機能を有するクライアント端末を制御するコンピュータを、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を取得する手段と、
    前記回覧対象文書データ及び前記回覧ルート情報を、前記サーバへ送信する手段と、
    前記回覧対象文書データの送信要求を前記サーバに送信する手段と、
    前記回覧対象文書データを前記サーバから受信する手段と、
    前記サーバから受信した回覧対象文書データを出力する手段と、
    前記出力した回覧対象文書データに対する承認結果を取得する手段と、
    該承認結果を前記サーバへ送信する手段と、
    前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    該回覧順序の変更箇所を前記サーバに通知する手段と、として機能させることを特徴とするクライアントプログラム。
29. 前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする請求項２８記載のクライアントプログラム。
30. 前記コンピュータを、自端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして前記サーバから取得する手段と、
    前記回覧予定文書データを出力する手段と、として機能させることを特徴とする請求項２６から２９のいずれか１項記載のクライアントプログラム。
31. 前記コンピュータを、前記回覧予定文書データの承認結果を取得する手段と、
    取得した前記回覧予定文書データの承認結果を、前記サーバへ送信する手段と、として機能させることを特徴とする請求項３０記載のクライアントプログラム。
32. ネットワークを介して少なくとも一つのユーザクライアント端末と接続されたサーバを制御するコンピュータを、
    文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、前記ユーザクライアント端末から取得する手段と、
    前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段と、として機能させ、
    前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とするサーバプログラム。
33. 前記コンピュータを、
    前記各ユーザクライアント端末から、前記回覧対象文書データの回覧順序の変更箇所を取得する手段と、
    前記ユーザクライアント端末から回覧順序の変更箇所を取得した回覧対象文書データの回覧状況を取得する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを確認する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    前記ユーザクライアント端末から取得した回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段と、として機能させることを特徴とする請求項３２記載のサーバプログラム。
34. ネットワークを介して少なくとも一つのユクライアント端末と接続されるサーバを制御するコンピュータを、
    文書データを回覧する上での規則を示す回覧規則情報が少なくとも一つ格納された回覧規則情報格納手段と、
    回覧の対象となる回覧対象文書データの回覧順序を回覧者と回覧順位とによって表す回覧ルート情報を、前記ユーザクライアント端末から取得する手段と、
    前記ユーザクライアント端末から取得した前記回覧ルート情報の示す回覧順序が、前記回覧規則情報格納手段に格納されている前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    回覧順序が、前記回覧規則情報に適合すると判断した回覧対象文書データを、前記ユーザクライアント端末からの要求に応じて送信する手段と、
    前記ユーザクライアント端末から回覧順序の変更箇所を通知された回覧対象文書データの回覧状況を取得する手段と、
    前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであるか否かを判断する手段と、
    前記ユーザクライアント端末から要求された回覧順序の変更箇所を変更した後の回覧順序が、前記回覧規則情報が示す規則に適合するか否かを判断する手段と、
    前記ユーザクライアント端末から通知された回覧順序の変更箇所が、回覧が未完了の回覧者を変更するものであり、かつ前記回覧規則情報が示す規則に適合する場合に、回覧順序の変更を許可する手段と、として機能させることを特徴とするサーバプログラム。
35. 前記回覧ルート情報には、同じ回覧順位に複数の回覧者を設定可能であることを特徴とする請求項３４記載のサーバプログラム。
36. 前記コンピュータを、任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書でデータの回覧を完了していない場合には、回覧未完了の回覧者に対して前記所定の期間が経過したことを通知する手段として機能させることを特徴とする請求項３２から３５のいずれか１項記載のサーバプログラム。
37. 前記コンピュータに、任意の回覧順位の回覧者による前記回覧対象文書データの回覧が完了してから所定の期間内に次の回覧順位の回覧者が該回覧対象文書データの回覧を完了していない場合、該回覧対象文書データに代理回覧者が予め登録されていれば、該代理回覧者を正式な回覧者として回覧順序を変更させることを特徴とする請求項３２から３６のいずれか１項記載のサーバプログラム
38. 前記コンピュータを、前記ユーザクライアント端末からの要求に応じ、要求元のユーザクライアント端末のユーザが回覧者として指定されているが回覧する順番となっていない回覧対象文書データを回覧予定文書データとして前記要求元のユーザクライアント端末へ送信する手段と、
    前記回覧予定文書データの承認結果を前記ユーザクライアント端末から取得する手段と、
    任意の回覧順位の回覧者による回覧が完了した際に次の回覧順位の回覧者の回覧予定文書データの承認結果が登録されているか否かを確認し、登録されていれば、その承認結果を前記回覧対象文書データの承認結果とする手段と、として機能させることを特徴とする請求項３７記載のサーバプログラム。

Images