JP2005135134A - 案件保管方法およびそのシステム - Google Patents

Abstract

【課題】 複数種類のアプリケーションによって起案された案件に関する情報およびその案件の添付ファイルであっても、統一的に文書保管サーバで管理できる文書保管方法を提供することである。
【解決手段】 保管が必要な案件を起案するアプリケーションサーバ（３）と、この案件を決裁する決裁基盤サーバ（１）と、この案件を保管する文書保管サーバ（２）とが互いにネットワークを介して接続された文書保管システムにおける文書保管方法であって、アプリケーションサーバ（３）で起案された案件は、決裁基盤サーバ（１）に送信され、決裁基盤サーバ（１）において決裁された後で、決裁基盤サーバ（１）が作成した保管案件を選択するリスト画面から選択されて、決裁基盤サーバ（１）から文書保管サーバ（２）に送信されて保管されることを特徴とする文書保管方法を課題の解決手段とする。
【選択図】 図１

Description

本発明は、１以上のアプリケーションで入力された案件に関する情報およびその案件の添付ファイルを、電子決裁基盤を介して案件保管装置にて保管・管理する電子決裁基盤を用いた案件保管方法およびそのシステムに関する。

従来、行政機関などにおいて発生する文書は、各部課において、紙ベースの書類として一定期間保存されて管理されてきた。しかしながら、一般市民への情報公開や、事務処理の効率化などを目的として、業務で発生する文書の電子化が進んでいる。このように業務で発生する文書が電子化されることで、文書保管装置などを用いることにより容易に行政文書を集中管理することができる。

このような、文書保管装置の例として、特許文献１には、行政機関などにおいて発生した文書目録および添付データを、決裁者が決裁する稟議決裁部と、決裁された文書目録および添付データとを保存する文書目録管理部と、保存された文書目録と添付データとを公開する情報公開部とを有する文書管理支援システムが提案されている。特許文献１に記載の文書管理支援システムによると、取扱う文書データに関する情報である文書目録をデータベース化することで、文書データの検索や、文書管理支援システムの管理運営を円滑に行うことができ、情報公開を迅速に行うことができる。
特開２００１−２４３１０３号公報（段落番号００３８〜００４７、図２）

しかしながら、特許文献１に記載の文書管理支援システムでは、文書目録管理部に接続された端末機から文書データを入力する構成となっており、行政機関の業務で用いられる複数種類の業務アプリケーションによって作成される文書データおよびその文書に関する情報を保管・管理しようとすると、連携をとることが難しく、作業効率が低下してしまう問題点があった。また、一般的に、複数種類の業務アプリケーションで作成された文書データを文書保管装置で管理しようとする場合、各業務アプリケーションにおいて保管・管理用の画面を作成する必要があり、文書保管装置に連携する業務アプリケーションの数が増える場合には、各業務アプリケーションを改修して入力のフォーマットを統一したり、保管・管理用の画面を再構成したりする必要があり、文書保管装置と連携する業務アプリケーションの追加に伴うコストを引き上げる原因となっていた。また、連携する業務アプリケーションによっては例外的な処理が多いものもあり、統一されたフォーマットでの入力では連携が難しいという問題点もあった。

したがって、本発明が解決しようとする技術的課題は、複数種類の業務アプリケーションによって入力された案件に関する情報およびその案件の添付ファイルであっても、統一的に案件保管サーバで管理できる案件保管方法およびそのシステムを提供することである。

前記した課題を解決するためになされた本発明に係る案件保管方法は、保管が必要な案件を起案するアプリケーションサーバと、この案件を決裁する決裁基盤サーバと、この案件を保管する案件保管サーバとが互いにネットワークを介して接続された案件保管システムにおける案件保管方法であって、アプリケーションサーバで起案された案件が、決裁基盤サーバに送信され、決裁基盤サーバにおいて決裁された後で、決裁基盤サーバが作成した保管対象の案件を選択するリスト画面から選択されて、決裁基盤サーバから案件保管サーバに送信され、保管されることを特徴としている。

このような構成の案件保管方法によると、全ての案件が決裁基盤サーバを通って案件保管サーバに保管されるため、案件の登録管理をアプリケーションサーバではなく、決裁基盤サーバにおいて、統一的に行うことができる。

また、前記した課題を解決するためになされた本発明に係る案件保管システムは、保管が必要な案件を起案するアプリケーションサーバと、この案件を決裁する決裁基盤サーバと、この案件を保管する案件保管サーバとが互いにネットワークを介して接続された案件保管システムとして構成される。そしてこの案件保管システムにおいて、案件は、案件の添付ファイルと、添付ファイルへのリンク情報を含んだ案件に関する情報である案件情報とから構成される。アプリケーションサーバには、前記案件情報を入力するインターフェイスプログラムが組み込まれる。このアプリケーションサーバから、案件情報と添付ファイルとを受信した決裁基盤サーバは、案件情報と添付ファイルとを決裁基盤サーバの記憶手段に登録し、決裁された後で、決裁が終了した案件情報のリスト画面を作成し、前記リスト画面から当該案件情報が選択されると、この案件情報を案件保管サーバに送信する。案件保管サーバは、受信した案件情報に、案件の保管場所に関する情報などを付加する表示画面を作成し、案件情報に案件の保管場所に関する情報を付加すると、この案件情報に含まれるリンク情報を用いて、決裁基盤サーバに添付ファイルの送信を要求し、この案件情報と受信した添付ファイルとを案件保管サーバの記憶手段に保管することを特徴としている。

このような構成の案件管理システムによると、案件の登録管理を決裁基盤サーバで統一的に行えることに加えて、案件保管サーバに案件を送信する際に、先に案件情報のみを送信することで、保管場所に関する情報などを付加する表示画面の応答を早くすることができる。

また、この案件情報には、当該案件の保管可能者に関する情報が設定され、決裁基盤サーバから前記案件情報を案件保管サーバに送信する際に、案件の選択者が保管可能者であるか否かを判定することにしてもよい。

このような構成の案件管理システムによると、起案者が退職や異動などで、保管作業が行えない場合であっても、予め設定された保管可能者が保管作業を行うことができる。

本発明に係る案件保管システムによると、決裁基盤サーバにおいて保管対象である案件の一覧を確認することができ、かつ保管対象の案件をまとめて案件保管サーバに登録することが可能なため、アプリケーションごとに案件保管作業を行う際に比べて、保管作業の能率が向上する。

次に、添付した図面を参照して、本発明の実施の形態を詳細に説明する。本実施の形態では、行政機関などにおいて、財務会計、人事給与などの業務アプリケーションで起案された案件に関する情報である案件情報およびこの案件に関する添付ファイルを、決裁基盤サーバに送信して決裁し、この案件情報および添付ファイルを案件保管サーバで保管する案件保管システムおよびその方法について説明する。なお、本実施の形態において、添付ファイルとは、業務アプリケーションで作成された文書データや画像データなどの他に、アプリケーションプログラムなどのコンテンツや、ファイルのＵＲＩ（Uniform Resource Identifiers）、実際の帳票などに付けられたインデックスなどを含んだ意味で用いる。また、「案件ファイル」という言葉は、案件情報とその添付ファイルを合わせたものを指す意味で用いる。

（システム構成）
図１は、本実施の形態の案件保管システムの構成例を示した図である。図１を参照して、本実施の形態の案件保管システムは、業務アプリケーションサーバ３から案件ファイルを受信して決裁を行う決裁基盤サーバ１と、決裁基盤サーバ１で決裁された案件ファイルを保管する案件保管サーバ２と、案件ファイルを起案する業務アプリケーションサーバ３とがネットワークを介して互いに接続されて構成されている。次に、この案件保管システムの各構成要素について説明する。

決裁基盤サーバ１は、業務アプリケーションサーバ３から受け取った案件に関す情報である案件情報およびその添付ファイルを、それぞれ案件情報ＤＢ１１および添付ファイルＤＢ１２に登録する登録処理部１４と、決裁者に決裁対象の案件の案件情報を提示し、決裁を受け、決裁に関する情報である決裁情報を作成して、この決裁情報を決裁情報ＤＢ１３に登録する決裁処理部１５と、決裁を受けた案件の案件情報および決裁情報の一覧画面である保管一覧画面を作成し、保管対象の案件ファイルおよび決裁情報を案件保管サーバ２に受け渡す処理などを行う案件保管処理部１６とから構成される。この決裁基盤サーバ１は、典型的には通信機能を有したサーバ用コンピュータを用いることができ、サーバ用コンピュータを登録処理部１４、決裁処理部１５および案件保管処理部１６として機能させるプログラムをＲＡＭ（Random Access Memory）に展開して実行することで決裁基盤サーバ１が実現される。なお、登録処理部１４、決裁処理部１５および案件保管処理部１６の詳しい動作については後記するフローチャートを用いて説明する。

案件保管サーバ２は、決裁基盤サーバ１から受信した保管対象の案件の案件情報を、後記する案件保管画面に表示し、この案件情報にリンクされた添付ファイルおよび決裁情報の要求情報を決裁基盤サーバ１に送信して、この案件の添付ファイルおよび決裁情報を受け取り、案件ＤＢ２１および決裁情報ＤＢ２２に保管する案件保管部２３を含む。さらに決裁基盤サーバ１は、業務アプリケーションサーバ３などからの要求に応じて、案件を検索する案件検索部２４を含んで構成される。案件保管サーバ２も典型的には通信機能を有したサーバ用コンピュータを用いることができる。このとき、このサーバ用コンピュータを案件保管部２３と、案件検索部２４として機能させるプログラムをＲＡＭに展開して実行することで案件保管サーバ２が実現される。なお、案件検索部２４としては公知のファイル検索プログラムを用いることができ、検索のキー情報としては案件情報に含まれる各項目の情報を用いることができる。また、案件保管部２３の詳しい動作については後記するフローチャートを用いて説明する。

業務アプリケーションサーバ３は、財務会計、人事給与などの公知の業務アプリケーションを実行するサーバであって、業務アプリケーションサーバ３本体とそれに接続されたクライアント端末とから構成され、本実施の形態の業務アプリケーションサーバ３には、業務アプリケーションのプログラムに加えて、起案される案件の案件情報を入力し、決裁基盤サーバ１に受け渡す際のインターフェイスとなる起案ＡＰＩ（Application Programming Interface）のプログラムが登録されている。この起案ＡＰＩは、業務アプリケーションサーバ３の扱う業務アプリケーションごとにカスタマイズすることが可能である。

本実施の形態の案件保管システムの各構成要素を接続するネットワークとしては専用線、ＶＰＮ（Virtual Private Network）、ＬＡＮ（Local Area Network）などの様々なネットワークを用いることができる。

なお、本実施の形態の案件保管システムには、図示しない人事ＤＢ（Data Base）サーバがさらに接続されている。この人事ＤＢサーバには、職員ごとに一意に付けられたＩＤである職員ＩＤ、当該職員の名前、所属部課、役職、異動履歴などの情報を含んだテーブルデータから構成される人事ＤＢが含まれている。決裁基盤サーバ１、案件保管サーバ２および業務アプリケーションサーバ３は、必要に応じて適宜、人事ＤＢサーバにアクセスして、人事ＤＢを利用可能である。

また、決裁基盤サーバ１は、起案ＡＰＩが組み込まれた複数種類の業務アプリケーションサーバで起案された案件ファイルを統括して処理することも可能であるが、本実施の形態では、説明のため、１台の業務アプリケーションサーバ３が接続された構成としている。

（案件決裁過程）
次に、本実施の形態の案件保管システムを用いて、業務アプリケーションサーバ３で起案された案件ファイルが、決裁されて案件保管サーバ２に保管される過程について説明する。ここで、図２は、業務アプリケーションサーバ３で起案された案件ファイルが決裁基盤サーバ１に登録され、決裁されるまでのフローチャートを示している。図２に示したフローチャートを参照して、案件ファイルの決裁過程について説明する。

初めに、業務アプリケーションサーバ３では、起案された決裁を必要とする案件について起案ＡＰＩを起動して、案件情報を登録する（ステップＳ１００）。ここで、起案ＡＰＩは、案件情報の各項目を入力するインターフェイスプログラムである。この案件情報は、案件に関する情報を記述するテーブルデータであり、この案件情報の例を図３（ａ）に示す。図３（ａ）に示すように、案件情報には、起案された案件に一意に付けられたＩＤである案件識別ＩＤ、案件名、起案アプリケーションサーバ名、起案した職員の職員ＩＤである起案者ＩＤ、起案者名、起案日時、決裁期限、決裁者の指定や決裁順序を定めた決裁ルート、保管可能者の種別である保管種別、決裁済みか否かを判断できる決裁完了フラグ、この他に、保管済みか否かを判断できる保管完了フラグ、保存年限などの情報が含まれている。ここで、決裁者の指定や決裁順序を定めた決裁ルートの符号の対応表を表１に、保管可能者の種別である保管種別の番号の対応表を表２にそれぞれ示す。表１に示した決裁ルートの対応表によると、決裁ルートの符号ごとに決裁者とその決裁順序とが示されている。また、表２に示した保管種別の対応表によると、案件に関する情報は起案した本人以外にも、起案者の所属課や、文書課などでも保管可能に設定することもできる。これにより、起案者が退職や異動などで保管できないといったケースを避けることができる。

また、この案件情報には、この案件の添付ファイルの書誌情報も含まれる。添付ファイルの書誌情報は、添付ファイルに一意に付けられたファイル識別ＩＤ、ファイル名、この添付ファイルの閲覧可能者の種別である閲覧権限、この添付ファイルの内容を表す分類コード、ファイル完成日、作成者名、作成者の職員ＩＤである作成者ＩＤなどを含んだテーブルデータである。１つの案件情報に複数の添付ファイルが関連付けられる場合には、それぞれの添付ファイルの書誌情報が案件情報に記入されることとなる。案件情報と添付ファイルとは、この書誌情報により関連付けられている。

さらに、案件情報には、業務アプリケーションサーバ３の扱う業務アプリケーションごとに、テーブルデータの項目を追加することが可能であり、例えば、業務アプリケーションが財務会計アプリケーションであれば、当該業務アプリケーション独自のＩＤ、会計年度、支払金額、支払期限、科目、債権者、債務者などの項目を追加することが考えられる。このような情報を含めることで、案件情報保管サーバ２では、業務アプリケーション独自の項目を用いて案件情報を検索することができる。

これらの案件情報は、起案ＡＰＩから、例えばＸＭＬ（eXtensible Mark-up Language）形式のデータとして出力される。

なお、決裁を必要とする案件の起案は決まっているが、添付ファイルが完成していない場合または添付ファイルの無い案件の場合には、起案ＡＰＩを起動して案件の案件情報のみを登録することも可能である。この際、添付ファイルが完成したり、追加の添付ファイルが生じた時点で、案件情報に添付ファイルの書誌情報を追加することができる。

そして、業務アプリケーションサーバ３は、案件情報および添付ファイルを、ネットワークを介して決裁基盤サーバ１に送信する（ステップＳ１０１）。この案件情報および添付ファイルを受信した（ステップＳ１０２）決裁基盤サーバ１は、案件情報を案件情報ＤＢ１１に、添付ファイルを添付ファイルＤＢ１２にそれぞれ登録する（ステップＳ１０３）。次に決裁基盤サーバ１は、受信した案件情報に含まれる決裁種別の項目の値に従って、決裁情報を作成し、決裁情報ＤＢ１３に登録する（ステップＳ１０４）。この決裁情報ＤＢ１３に登録される決裁情報の例を図３（ｂ）に示す。図３（ｂ）に示すように、決裁情報は、対象の案件の案件識別ＩＤである対象案件識別ＩＤ、決裁ルート、決裁者の職員ＩＤである決裁者ＩＤ、決裁者名、決裁日時、決裁済フラグなどの情報を含んだテーブルデータである。この決裁情報において、対象案件識別ＩＤは、図３（ａ）に示した案件情報の案件識別ＩＤに対応しており、これにより、案件情報と決裁情報とが対応付けられる。また、決裁者とその数は、表１に示した決裁ルートの項目の符号から決められ、図３（ｂ）を見ると、決裁者が一人の案件や決裁者が複数人の案件などがあることがわかる。また各決裁日時の隣の項目には決裁者ごとの決裁状況を示す決裁済フラグの欄があり、各決裁者が決裁することで「０」から「１」に書き換えられる。

次に決裁基盤サーバ１は、受信した案件情報を、例えば決裁者の端末装置に送信して決裁者の決裁を受ける（ステップＳ１０５）。ここで、決裁者は必要に応じて、案件情報の添付ファイルの書誌情報に含まれるファイル識別ＩＤをキー情報として、添付ファイルを閲覧して決裁を行うことになる。図３（ｂ）に示した決裁情報において、決裁者の決裁が完了すると決裁完了フラグが「０」から「１」に書き換えられ、その日時が、決裁日時の欄に入力される。決裁者が複数人いる場合にはこの決裁フラグがすべて「１」に書き換えられることで、決裁が完了したことになる。

そして、決裁が完了すると決裁基盤サーバ１は、案件情報ＤＢ１１に登録された、決裁対象となった案件情報に含まれる決裁完了フラグの欄を「０」から「１」に書き換える（ステップＳ１０６）。これにより、この案件情報が決裁済みであることを確認することができる。

以上の過程によって、決裁された案件情報が案件情報ＤＢ１１に、添付ファイルが添付ファイルＤＢ１２に、決裁情報が決裁情報ＤＢ１３にそれぞれ登録される。

（案件保管過程）
次に、前記した過程により、決裁基盤サーバ1の各データベースに登録された情報を、案件保管サーバ２に保管する過程について説明する。ここで、図４は決裁基盤サーバ１に登録された案件情報、添付ファイルおよび決裁情報が、案件保管サーバ２に保管されるまでのフローチャートの例を示している。図４に示したフローチャートを参照して、決裁案件の保管過程について説明する。

はじめに、決裁された案件を保管したい保管者が、例えば業務アプリケーションサーバ３に接続された端末装置から決裁基盤サーバ１にアクセスすると、決裁基盤サーバ１は、保管対象の案件を表示するために、案件情報ＤＢ１１に登録された案件情報のうち、決裁完了フラグが「１」である案件情報を集計して、保管対象となる案件のリスト画面である図示しない保管一覧画面を作成する（ステップＳ２００）。この保管一覧画面は、保管者が使用する端末装置に表示され、保管者が保管一覧画面から保管対象の案件情報を選択すると（ステップＳ２０１）、案件情報に含まれる保管種別の情報に基づいて、この保管対象の案件を選択した保管者が保管可能者であるかを認証して確認する（ステップＳ２０２）。ここで、もしも保管者が保管可能者でない場合には、そのまま終了する。また、保管者が保管可能者である場合には、決裁基盤サーバ１は、選択された案件の案件情報を、ネットワークを介して案件保管サーバ２に送信する（ステップＳ２０３）。

次に、ステップＳ２０１で選択された案件情報を受信した（ステップＳ２０４）案件保管サーバ２は、受信した案件情報を表示し、図１に示した案件保管サーバ２の案件情報ＤＢ２１における保管場所を指定する情報などを入力する表示画面である図示しない案件保管画面を作成する（ステップＳ２０５）。そして、案件保管サーバ２の管理者は、案件保管画面を用いて、案件情報に保管付加情報を追加すると（ステップＳ２０６）、案件保管サーバ２は、この保管付加情報が追加された案件情報を案件情報ＤＢ２１に格納する（ステップＳ２０７）。ここで、案件情報に追加される保管付加情報は、保管・管理する上で必要な、この案件が決裁された年度を表す暦年区分、案件情報ＤＢ２１の保存先のフォルダを指定するフォルダＩＤ、案件の種別を表す分類コードなどの項目を含んだテーブルデータである。

そして、案件保管サーバ２は、案件情報に含まれる案件識別ＩＤによりリンクされる決裁情報と、案件情報に含まれる添付ファイルの書誌情報のファイル識別ＩＤによりリンクされる添付ファイルとを要求する要求情報を決裁基盤サーバ１に送信する（ステップＳ２０８）。

この添付ファイルおよび決裁情報の要求情報を受信した（ステップＳ２０９）決裁基盤サーバ１は、案件情報ＤＢ１１に登録された案件情報に含まれる保管完了フラグの欄を「０」から「１」に書き換える（ステップＳ２１０）。これにより、この案件に関する情報は、案件保管サーバ２に保管されたことが判別でき、所定の期間経過後に、この案件情報と、案件情報にリンクした添付ファイルと、決裁情報は消去されることとなる。そして、決裁基盤サーバ１は、ステップＳ２０７で要求された添付ファイルおよび決裁情報を案件保管サーバ２に送信する（ステップＳ２１１）。

添付ファイルおよび決裁情報を受信した（ステップＳ２１２）案件保管サーバ２は、決裁情報を図１に示した決裁情報ＤＢ２２に登録し、添付ファイルを案件ＤＢ２１のステップＳ２０５でフォルダＩＤに設定したフォルダに案件情報とともに登録する（ステップＳ２１３）。

以上の過程を経て案件情報、添付ファイルおよび決裁情報は、決裁基盤サーバ１から案件保管サーバ２に受け渡され、保管される。

以上説明したような案件保管システムおよびその方法によると、決裁基盤サーバの保管一覧画面から、まとめて案件を保管することができるため、業務アプリケーションから直接、案件保管サーバに登録する場合に比べて保管作業の能率が向上する。また、決裁基盤サーバから案件保管サーバに案件ファイルを送信する際に、案件情報と、添付ファイルの送信のタイミングが違うため、案件保管サーバに表示される案件保管画面の応答が向上し、ネットワークへのトラフィックの負荷を分散することができる。

また、このように案件保管サーバ２に保管された案件に関する情報は、案件識別ＩＤをキー情報として業務アプリケーションサーバ３をはじめ、案件保管サーバ２と通信可能な端末から検索可能となる。

（決裁不要案件への対応）
なお、本実施の形態では決裁を必要とする案件についての案件情報とその添付ファイルを案件保管サーバに保管する例を説明したが、決裁を必要としない案件についても、本実施の形態の案件保管システムを用いて案件情報および添付ファイルを保管することができる。この場合、業務アプリケーションサーバ３において起案ＡＰＩを用いて案件情報を入力する際に、決裁ルートの欄に例えば決裁不要を示す「０」と入力し、決裁完了フラグの欄に決裁済を示す「１」と入力しておけばよい。これにより図２に示したフローチャートのステップＳ１０４ないしステップＳ１０６が省略されて、案件保管サーバ２の案件情報ＤＢ２１に保管されることとなる。

以上、本発明の好適な実施の形態について説明したが、本発明はこのような実施の形態に限定されるものではない。
例えば、本実施の形態では、案件情報に添付ファイルを識別するファイル情報を付加する構成としたが、案件情報、添付ファイルおよび決裁情報をリンクさせるリンクテーブルを別に設ける構成としてもよい。このような構成とすることで、添付ファイルを後から追加する場合の拡張性が図りやすくなる。
また、本実施の形態の案件情報には添付ファイルの書誌情報を付加する構成としたが、添付ファイルの書誌情報だけを別のデータベースに登録し、案件情報に添付ファイルのファイル識別ＩＤのみを付加する構成も可能である。このような構成によると、案件ごとの管理だけでなく、添付ファイルごとの管理も容易となり、柔軟な検索が可能となる。
また、案件保管サーバに情報公開用のＷｅｂサーバ機能を持たせることも考えられる。この場合、案件情報に含まれる添付ファイルの書誌情報に公開許諾に関する情報を持たせることで、添付データの公開または非公開を設定することができる。
以上のように、本発明は、様々に変形して実施可能である。従って、本発明は特許請求の範囲に記載された技術的思想によって定められる。
また、本発明に係る案件保管システムおよびその方法は、情報公開などの要望の高い、行政機関において特に有用に利用可能である。

案件保管システムの構成図である。 案件保管システムにおいて、案件ファイルが決裁されるまでのフローチャートである。 （ａ）書誌情報ＤＢに登録されるデータテーブルの例を示す図である。（ｂ）決裁情報ＤＢに登録されるデータテーブルの例である。 案件保管システムにおいて、案件ファイルが保管されるまでのフローチャートである。

符号の説明

１ 決裁基盤サーバ
２ 案件保管サーバ
３ 業務アプリケーションサーバ
１４ 登録処理部
１５ 決裁処理部
１６ 案件保管処理部
２３ 案件保管部
２４ 案件検索部

Claims (6)

1. 保管が必要な案件を起案するアプリケーションサーバ（３）と、前記案件を決裁する決裁基盤サーバ（１）と、前記案件を保管する案件保管サーバ（２）とが互いにネットワークを介して接続された案件保管システムにおける案件保管方法であって、
   前記アプリケーションサーバ（３）で起案された前記案件は、
   前記決裁基盤サーバ（１）に送信され、
   前記決裁基盤サーバ（１）において決裁された後で、前記決裁基盤サーバ（１）が作成した決裁された案件を選択するリスト画面から前記案件を選択することで、前記決裁基盤サーバ（１）から前記案件保管サーバ（２）に送信されて保管されること、
   を特徴とする案件保管方法。
2. 保管が必要な案件を起案するアプリケーションサーバ（３）と、前記案件を決裁する決裁基盤サーバ（１）と、前記案件を保管する案件保管サーバ（２）とが互いにネットワークを介して接続された案件保管システムであって、
   前記案件は、前記案件の添付ファイルと、前記添付ファイルのリンク情報を含んだ前記案件に関する情報である案件情報とから構成され、
   前記アプリケーションサーバ（３）には、前記案件情報を入力するインターフェイスプログラムが組み込まれ、
   前記アプリケーションサーバ（３）から、前記案件情報と前記添付ファイルとを受信した決裁基盤サーバ（１）は、前記案件情報と前記添付ファイルとを前記決裁基盤サーバ（１）の第１記憶手段に登録し、決裁された後で、決裁が終了した保管対象の案件のリスト画面を作成し、前記リスト画面から当該案件が選択されると、前記案件情報を前記案件保管サーバ（２）に送信し、
   前記案件保管サーバ（２）は、受信した前記案件情報に、保管場所に関する情報を含んだ情報を付加する表示画面を作成し、前記案件情報に保管場所に関する情報を含んだ情報を付加すると、前記案件情報に含まれる前記リンク情報を用いて、前記決裁基盤サーバ（１）に前記添付ファイルの送信を要求し、前記案件情報と前記決裁基盤サーバ（１）から受信した前記添付ファイルとを前記案件保管サーバ（２）の第２記憶手段に保管すること、
   を特徴とする案件保管システム。
3. 前記案件情報には、前記添付ファイルの書誌情報が含まれること、
   を特徴とする請求項２に記載の案件管理システム。
4. 前記インターフェイスプログラムは、前記アプリケーションサーバ（３）ごとに、独自に追加された入力項目を前記案件情報に含めること、
   を特徴とする請求項２または請求項３に記載の案件保管システム。
5. 前記案件保管サーバ（２）は、
   前記独自に追加された入力項目をキー情報として、前記第２記憶手段に保持された前記案件情報を検索すること、
   を特徴とする請求項４に記載の案件保管システム。
6. 前記案件情報には、当該案件の保管可能者に関する情報が設定され、
   前記決裁基盤サーバ（１）は、
   前記決裁基盤サーバ（１）から前記案件情報を案件保管サーバ（２）に送信する際に、案件の選択者が保管可能者であるか否かを判定すること、
   を特徴とする請求項２ないし請求項５のいずれか１項に記載の案件保管システム。

Images