JP2001084193A - 電子メール情報管理方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】文書とその履歴及び文書に関係するメールを後
から遡って探し出易いデータの構造で管理し、文書の内
容が不明でもメールで文書が動いた特長を手掛かりに目
的の文書を探し出す。 【解決手段】本発明による電子メール情報管理方法は、
利用者宛てに電子メールが着信した際に、着信元アドレ
スに対応して決まる特定のアドレスにメールを転送する
メール転送ステップと、前記メール転送ステップによっ
て転送されたメールが着信した際に該メールに含まれる
識別情報を元にして管理対象メールを判別する管理対象
メール判別ステップと、前記管理対象メール判別ステッ
プによって判別された管理対象メールを文書データベー
スの所定の格納場所に登録する管理対象メール登録ステ
ップを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、本発明は、コンピ
ュータ装置を用いて、利用者間で電子的にメッセージお
よび文書情報を交換または蓄積する電子メール情報管理
方法および装置に関する。

【０００２】

【従来の技術】グループウェアは、企業、官公庁等の組
織内におけるホワイトカラーの生産性向上手段として、
基幹業務システムではシステム化できない業務領域で用
いられてきている。中でも、文書管理システムは文書作
成を主目的とする業務で活用されており、最近では、文
書内容の版管理ができるシステムも製品化されている。
また、電子メールシステムは、容易な操作により柔軟な
情報交換を行うことが可能であるため、オフィス業務で
発生するアドホックな文書のやり取りに活用されてい
る。ただし、電子メールの場合、受信メールは利用者ご
とに管理されるので、一連のテーマに関して受送信され
たメールやその経過の全てを参照できるわけではなく、
利用者は受信したメールの本文、ヘッダに記載されてい
る履歴を見ることができるだけである。また、メールに
ファイルを添付することによって文書の送付を行うこと
ができるが、文書の長期的保存や改訂履歴の管理につい
ては考慮されていないので、文書の保存のためには、個
別にその都度、文書管理システム等に移管しなければな
らない。また、メールは進捗管理の機能をもたないの
で、これを補う技術としてワークフローシステムが存在
するが、ワークフローシステムでは作業プロセスをあら
かじめすべて定義する必要があるので、フローの途中で
アドホックに流れを変えるなど、真に柔軟な情報交換は
難しい。近年、官公庁・自治体において普及が進みつつ
ある公文書管理システムにも同様の問題がある。

【０００３】

【発明が解決しようとする課題】企業、組織において
は、個人作成文書に端を発した意思決定（稟議、決裁
等）が行われることが多い。これらの意思決定は通常紙
文書を用いて行われるが、特に官公庁・自治体において
はその頻度が比較的高く、業務を圧迫するとともに意思
決定の遅れを招いている。

【０００４】オフィス内部で意思決定を伴う文書を作成
し、内容を審査して承認する文書の稟議、決裁業務は、
一見定型的な業務に見えるが、実際には決裁処理に入る
前の事前調整の段階で、複雑なやりとりを必要とする場
合が多い。事前調整の段階まで含めて意志決定の全過程
を確認把握できるようにするためには、一連のテーマに
関係する文書とそのやりとりの経過、文書内容の変更履
歴を検索できることが必要である。事前調整の段階での
アドホックな情報のやりとり手段としては電子メールが
適しているが、メールシステムには意思決定の経過・結
果をまとめて管理する仕組みがないため、例えば、あと
から議論に参加した関与者が最初からの議論の流れを把
握できないといった問題が生じる。あとから意志決定の
経緯をたどれるようにしようとすると、電子メールと文
書管理システムを併用し、さらに、利用者が受送信操作
のたびごとに、一定のルールに従って、文書管理システ
ムにメールや添付文書を案件単位に登録して管理しなけ
ればならない。これでは、非常に手間がかかる上、誤操
作によって経過が分からなくなる危険がある。

【０００５】議論の経過を共有できるようにするする仕
組みとしては、ＷｅｂのＢＢＳ等に代表されるの電子掲
示板があるが、情報の更新、変更を把握するためには利
用者が能動的に掲示板を参照しに行かなければならない
上、添付文書の管理機能や、ユーザの権限に応じたアク
セス管理機能、特定の条件に当てはまる案件を検索する
機能等は提供されない。

【０００６】文書管理システムとして、文書内容の更新
履歴や版の管理を実現したシステムは既に存在している
（公知例：特開平９−３４７６３及び特開平９−１２８
３８０）。しかし、これらはいずれも出版／編集業務に
おける文書の執筆／校正管理、研究開発業務における設
計ドキュメントの管理などを目的とした専用システムで
あり、一般の社員・職員が使うには操作が難しく、柔軟
さを欠いている。意思決定はすべての社員・職員にかか
わる問題であり、かつ職場・利用者により使用頻度にば
らつきがあるため、操作に熟練を要するシステムでは受
け入れは極めて難しい。また、これらのシステムで管理
できるのは文書そのものに限られており、文書内容を決
定するに至った経緯が管理できるわけではない。

【０００７】進捗管理を行う手段としては、ワークフロ
ーシステムが存在する。しかし、ワークフローシステム
では、業務プロセスをあらかじめ定義しておく必要があ
り、定義されていない業務プロセスは実行できない。こ
のため、その適用範囲は極めて限定されたものとなる。

【０００８】これらの状況により、汎用的あるいは業務
横断的な意思決定及び文書管理のシステム化がなかなか
進まないという問題が生じている。

【０００９】本発明の目的は、履歴情報を利用した電子
メール情報の管理が実現できる電子メール情報管理方法
および装置を提供することにある。

【００１０】

【課題を解決するための手段】前記目的を達成するた
め、本発明による電子メール情報管理方法は、利用者宛
てに電子メールが着信した際に、着信元アドレスに対応
して決まる特定のアドレスにメールを転送するメール転
送ステップと、前記メール転送ステップによって転送さ
れたメールが着信した際に該メールに含まれる識別情報
に基づいて管理対象メールを判別する管理対象メール判
別ステップと、前記管理対象メール判別ステップによっ
て判別された管理対象メールを文書データベースの所定
の格納場所に登録する管理対象メール登録ステップを備
える。

【００１１】ここで、前記管理対象メール判別ステップ
は、管理対象メールの宛先に特定のアドレスが含まれて
いた場合、または、前記管理対象メールの内部に特定の
識別情報が含まれていた場合に、該メールを管理対象メ
ールと判別するようにする。

【００１２】また、前記管理対象メール登録ステップ
は、前記管理対象メールの内容中に含まれる識別情報か
ら該メールを登録すべき管理単位を判別し、該管理単位
が存在しない場合には前記文書データベース中に該管理
単位を生成した後、前記管理対象メールを該メールの挙
動に関する情報を付加して、対応する該管理単位に登録
し、更に登録を通知するメールを前記識別情報に基づい
て決まる宛先に送信するようにする。

【００１３】また、前記管理対象メール登録ステップに
おいて、前記管理対象メールに付加する挙動に関する情
報は、該メールに関わる前記管理単位内におけるメール
の送信回数、該メールに先行するメールの送信から該メ
ールの送信までに至る時間間隔、および該メールの宛先
数の少なくとも１個以上を含むように構成する。

【００１４】また、本発明が適用された文書管理システ
ムにおける文書検索方法は、前記文書データベース登録
ステップにおいて登録されたメールに関する情報、メー
ルの管理単位である案件について付与された情報、なら
びに案件中に含まれるメールの挙動情報のうち、少なく
とも１つ以上の情報を検索条件として入力する検索条件
入力ステップと、検索条件入力ステップにおいて入力さ
れた条件について、文書データベース中の該当項目を参
照し、条件に適合するメールを検索する文書検索ステッ
プと、文書検索ステップにおいて抽出したメールの一部
ないしは全部について、文書データベースから一部ない
しは全部の情報を抽出し、案件単位にグルーピングして
表示する文書表示ステップを有する。

【００１５】上記手段によって、電子メールで文書をや
り取りすることで、利用者は文書管理データベースへの
登録操作を意識することなく、テーマの関係者とやり取
りした意思決定過程に関連するメール、関連文書等の情
報を文書データベースに格納することができる。また、
組織におけるある意思決定に関して関与者が作成、受送
信した全ての電子メールと電子文書ファイルを対応づけ
て管理できる。さらに、文書のやり取りの過程、経緯、
背景、文書名などの関連情報を手掛かりに関係するメー
ルや文書をすべて遡って探すことができる。

【００１６】また、行政機関における起案・決裁事務に
おいて、起案に至る前の事前調整段階における素案文書
（電子メールデータ、電子文書ファイル）を管理する状
態と、組織として意思決定するために起案した起案文書
を管理することも可能となる。

【００１７】また、利用者が電子メールシステムで受送
信している電子メールデータの内容や作業の状態に対応
した種類や階層で区別した“案件”という管理単位を文
書データベース中に設けて、その管理単位毎に電子メー
ルデータと添付された電子文書を格納しておくことで、
議題のテーマ毎に関連する全ての関与者が作成または送
信した電子メールデータおよび電子文書ファイルをひと
つのまとまりとし管理することが出来る。

【００１８】また、利用者が電子メールシステムを利用
している業務の状態や、電子メールシステムで取扱う文
書の重要度などが変化していった場合に適切な管理単位
に変更して管理することができるようになる。

【００１９】また、利用者は、電子メールシステムを用
いて、特定のメールアドレス指定してメールを送信する
あるいは、特定の識別情報を付加してメールを送信する
ことにより、文書管理システム上で意識的に登録画面を
操作行うことなく電子メールで扱う情報を文書管理シス
テムに格納することが可能となる。

【００２０】また、意思決定で文書をやり取りした活動
の結果である文書および、文書を利用して活動した記録
である電子メールデータなどの情報を手掛かりとしてを
送受信した履歴を検索条件として参照できる。

【００２１】

【発明の実施の形態】以下、本発明の実施の形態につい
て、図面を用いて説明する。

【００２２】図１は本発明の一実施例である第１の実施
例を示す電子メール情報管理システム及びネットワーク
システムの構成図である。

【００２３】本実施例のネットワークシステムは文書サ
ーバ１０と電子メールサーバ３０及び利用者端末Ａ４０
と利用者端末Ｂ４０がＬＡＮ、インターネット、公衆回
線等のネットワークで接続されている。文書サーバ１０
は文書データベース１１と、それを制御する文書処理ア
プリケーション２０と、メール受発信手段２１と、文書
検索アプリケーション２２により構成される。

【００２４】電子メールサーバ３０は電子メールデータ
ベース３１と、それを制御するメールサーバ制御手段３
５と、メール転送アプリケーション３６により構成され
る。ここで、メール受発信手段２１および、メール転送
アプリケーション３６は、電子メールデータベース３１
と文書データベース１１とのデータ交換が必要な際にデ
ータの中継を行う。メール転送アプリケーション３６
は、メールサーバ制御手段３５を介して電子メールデー
タベース３１のメールデータを文書サーバ１０のメール
受発信手段２１に転送する。メール受発信手段２１は、
文書処理アプリケーション２０を介して文書データベー
ス１１から受け取るメールデータを電子メールサーバ３
０のメール転送アプリケーション３６に転送する。利用
者端末Ａ４０は電子メールクライアント４１、文書作成
アプリケーション４２、Ｗｅｂブラウザ４３、入力装置
４４からなる。ここで電子メールクライアント４１はネ
ットワークを介して電子メールサーバ３０とやり取り
し、Ｗｅｂブラウザ４３は文書検索アプリケーション２
２とやり取りするものとする。利用者端末Ｂ５０は利用
者端末Ａ４０と同様の機能を持つ。文書データベース１
１は公用文書属性テーブル１２、公用文書履歴管理テー
ブル１３、公用経路テーブル１４、決裁文書属性テーブ
ル１５、決裁文書履歴管理テーブル１６、決裁経路テー
ブル１７、承認情報テーブル１８、関係管理テーブル１
９から構成される。電子メールデータベース３１はＰＯ
Ｐテーブル３２、メールＩＤテーブル３３、ＳＭＴＰテ
ーブル３４から構成される。ＰＯＰテーブル３２は受信
メールデータを格納しておくテーブルである。メールＩ
Ｄテーブル３３はメールの利用者ＩＤとパスワードを管
理するテーブルである。ＳＭＴＰテーブル３４は送信メ
ールを溜めておくテーブルである。

【００２５】次に、図１２から図１９を用いて文書サー
バ１０の文書データベース１１が保持するテーブルの項
目の一例を説明する。まず、図１２から図１９のテーブ
ルの相互関係を説明する。関係管理テーブル１９は、公
用文書属性テーブル１２と決裁文書属性テーブル１５の
対応関係を管理するテーブルである。そして、公用文書
属性テーブル１２は、公用文書履歴管理テーブル１３
と、公用経路テーブル１４を一つのまとまりとして属性
情報を管理するテーブルである。また、決裁文書属性テ
ーブル１５は、決裁文書履歴管理テーブル１６と、決裁
経路テーブル１７と、承認情報テーブル１８を一つのま
とまりとして属性情報を管理するテーブルである。

【００２６】図１２を用いて公用文書属性テーブル１２
を説明する。

【００２７】公用文書属性テーブル１２は、文書サーバ
１０で管理対象とするメールを案件ごとひと纏まりにす
るための属性情報を管理するテーブルである。このテー
ブルは、文書Ｎｏ．１２０１と、作成者１２０２と、作
成日時１２０３と、件名１２０４と、送信件数１２０５
の各項目からなる。

【００２８】ここで、文書Ｎｏ．１２０１は文書サーバ
１０で管理対象となるメールの件名タグなどに一意に番
号を付与してある識別情報に対応したレコードを格納す
る。メールＮｏ．１２０２は文書Ｎｏ．１２０１で識別
されたメールの発生順に番号を付与するとする。送信日
時１２０３は送信日時タグを格納する。

【００２９】図１３を用いて公用文書履歴管理テーブル
１３を説明する。

【００３０】公用文書履歴管理テーブル１３は、利用者
から受信した電子メールデータと、そこから抽出または
２次加工したデータを併せて発生順に履歴として蓄積管
理するテーブルである。

【００３１】このテーブルは、文書Ｎｏ．１３０１と、
メールＮｏ．１３０２と、送信日時１３０３と、メール
データ１３０４と、添付文書１３０５と、属性と、履歴
１３０７の各項目からなる。ここで、文書Ｎｏ．１３０
１は文書サーバ１０で管理対象となるメールの件名タグ
などに一意に番号を付与してある識別情報に対応したレ
コードを格納する。メールＮｏ．１３０２は文書Ｎｏ．
１３０１で識別されたメールの発生順に番号を付与する
とする。送信日時１３０３は送信日時タグを格納する。
添付文書１３０５はメールの添付ファイルである電子文
書ファイルを電子メールデータからそれぞれ抽出する。
メールデータ１３０４は、利用者から受信したメールデ
ータそのも全部または一部を格納するものとする。そし
て、属性１３０６は、前記添付ファイルからファイル
名、作成日などの属性情報を抽出して格納する。

【００３２】文書Ｎｏ．１３０１、メールＮｏ．１３０
２、送信日時１３０３は、図１２の、文書Ｎｏ．１２０
１、メールＮｏ．１２０２、送信日時１２０３の各項目
とそれぞれ対応する。

【００３３】また、履歴１３０７は、前記添付ファイル
が保存される度に、先に登録済みの履歴レコードの内容
と比較し、版の変更回数を格納するものとする。添付文
書１３０５と、属性１３０６と、履歴１３０７は複数格
納する必要に応じて前記のカラムを追加するもとする。
図１３の例では、簡略化して１箇所分管理する例を示し
ている。

【００３４】図１４を用いて公用経路テーブル１４を説
明する。

【００３５】公用経路テーブル１４は、文書サーバ１０
で管理対象とする電子メールデータのタグなどの識別情
報を解読し、送信履歴の管理に必要な項目を抽出して格
納するテーブルである。このテーブルは、文書Ｎｏ．１
４０１と、メールＮｏ．１４０２と、送信日時１４０３
と、送信者１４０４と、受信者１４０５と、送信回数１
４０６と、添付文書数１４０７の各項目からなる。ここ
で、文書Ｎｏ．１４０１、メールＮｏ．１４０２、送信
日時１４０３は、図１２の文書Ｎｏ．１２０１、メール
Ｎｏ．１２０２、送信日時１２０３の各項目とそれぞれ
対応する。例えば送信日時１４０３は送信日時タグ、送
信者１４０４はＦＲＯＭ：タグ、受信者１４０５はＴ
Ｏ：タグ、送信回数１４０６は転送ヘッダの回数を電子
メールデータからそれぞれ抽出する。また、文書Ｎｏ．
１４０１は件名タグなどの管理対象メールを識別情報か
ら一意に番号を付与し、メールＮｏ．１４０２は文書Ｎ
ｏ．１４０１で識別されたメールの発生順に番号を付与
するとする。

【００３６】図１５を用いて決裁文書属性テーブル１５
を説明する。

【００３７】決裁文書属性テーブル１５は公用文書属性
テーブル１２と同様に、文書サーバ１０で管理対象とす
るメールを案件ごとひと纏まりにするための属性情報を
管理するテーブルである。

【００３８】このテーブルは、文書Ｎｏ．１５０１と、
作成者１５０２と、作成日時１５０３と、件名１５０４
と、分類コード１５０５と、決裁日時１５０６と、文書
保存年限１５０７と、コメント欄１５０８と、送信件数
１５０９の各項目からなる。文書Ｎｏ．１３０１は文書
サーバ１０で管理対象となる起案メールの件名タグなど
に一意に番号を付与してある識別情報に対応したレコー
ドを格納する。メールＮｏ．１５０２は文書Ｎｏ．１５
０１で識別されたメールの発生順に番号を付与するとす
る。送信日時１３０３は前記メールの送信日時タグを格
納する。件名１５０４と、分類コード１５０５と、決裁
日時１５０６と、文書保存年限１５０７と、コメント欄
１５０８は、このテーブルで管理対象とする電子メール
データである起案メールにある起案文書情報として記述
してあるする各情報を文書処理アプリケーション２０に
より抽出しそれぞれ格納する。

【００３９】図１６を用いて決裁文書履歴管理テーブル
１６を説明する。

【００４０】決裁文書履歴管理テーブル１６は、公用文
書履歴管理テーブル１３と同様に利用者から受信した電
子メールデータと、そこから抽出または２次加工したデ
ータを併せて発生順に履歴として蓄積管理するテーブル
である。

【００４１】このテーブルは、文書Ｎｏ．１６０１と、
メールＮｏ．１６０２と、送信日時１６０３と、メール
データ１６０４と、添付文書１６０５と、属性１６０６
と、履歴１６０７の各項目からなる。

【００４２】ここで、文書Ｎｏ．１６０１は文書サーバ
１０で管理対象となるメールの件名タグなどに一意に番
号を付与してある識別情報、メールＮｏ．１６０２は文
書Ｎｏ．１６０１で識別されたメールの発生順に番号を
付与するとする。送信日時１６０３は送信日時タグ、添
付文書１６０５はメールの添付ファイルである電子文書
ファイルを電子メールデータからそれぞれ抽出する。メ
ールデータ１３０４は、利用者から受信した電子メール
データそのも全部または一部を格納するものとする。

【００４３】文書Ｎｏ．１６０１で生成するレコート
は、文書Ｎｏ．１５０１と対応する識別番号が付与され
るとする。メールＮｏ．１６０２、送信日時１６０３
は、レコードを生成する時点で図１３の、メールＮｏ．
１５０２、送信日時１３０３で、生成するレコードと対
応する値が付与される。文書Ｎｏ．１６０１は、図１５
の文書Ｎｏ．１５０１の項目と対応する。

【００４４】そして、属性１６０６は、前記添付ファイ
ルからファイル名、作成日などの属性情報を抽出して格
納する。また、履歴１６０７は、前記添付ファイルが保
存される度に、先に登録済みの履歴レコードの内容と比
較し、版の変更回数を格納するものとする。添付文書１
６０５と、属性１６０６と、履歴１６０７は、複数格納
する必要に応じて前記のカラムを追加するもとする。図
１６の例では、簡略化して１箇所分管理する例を示して
いる。

【００４５】図１７を用いて決裁経路テーブル１７を説
明する。

【００４６】決裁経路テーブル１７は、文書サーバ１０
で管理対象とする電子メールデータのタグなどの識別情
報を解読し、送信履歴の管理に必要な項目を抽出して格
納するテーブルである。このテーブルは、文書Ｎｏ．１
７０１と、メールＮｏ．１７０２と、送信日時１７０３
と、送信者１７０４と、受信者１７０５と、送信回数１
７０６と、添付文書数１７０７の各項目からなる。ここ
で、例えば送信日時１７０３は送信日時タグ、送信者１
７０４はＦＲＯＭ：タグ、受信者１７０５はＴＯ：タ
グ、送信回数１７０６は転送ヘッダの回数を電子メール
データからそれぞれ抽出する。また、文書Ｎｏ．１７０
１は件名タグなどの管理対象メールを識別情報から一意
に番号を付与し、メールＮｏ．１７０２は文書Ｎｏ．１
７０１で識別されたメールの発生順に番号を付与すると
する。

【００４７】文書Ｎｏ．１７０１、メールＮｏ．１７０
２、送信日時１４０３は、図１６の文書Ｎｏ．１６０
１、メールＮｏ．１６０２、送信日時１６０３の各項目
とそれぞれ対応する。

【００４８】図１８を用いて承認情報テーブル１８を説
明する。

【００４９】承認情報テーブル１８は、決裁文書を回覧
したとき、文書を受け取った利用者が文書の内容を承認
した証拠情報を管理するテーブルである。このテーブル
は、文書Ｎｏ．１８０１と、送信者１８０２と、受信者
１８０３と、送信日時１８０４と、送付状態１８０５の
各項目からなる。

【００５０】文書Ｎｏ．１８０１、送信日時１８０４
は、図１５の文書Ｎｏ．１５０１、送信日時１５０３と
それぞれ対応する。

【００５１】図１９を用いて関係管理テーブル１９を説
明する。

【００５２】関係管理テーブル１９は、公用文書属性テ
ーブル１２と決裁文書属性テーブル１５の２つのテーブ
ルにおいて、相互に引き継いて発生するデータの対応関
係を管理するテーブルである。このテーブルは、ＩＤＮ
ｏ．１９０１と、文書Ｎｏ．１９０２と、登録日時１９
０３と、決裁Ｎｏ．１９０４と、登録日時１９０５の各
項目からなる。文書Ｎｏ．１９０２、登録日時１９０３
は、図１２の文書Ｎｏ．１９０２、送信日時１６０３と
それぞれ対応する。決裁Ｎｏ．１９０４、登録日時１９
０５は、図１５の決裁Ｎｏ．１６０１、送信日時１６０
３の各項目とそれぞれ対応する。

【００５３】次に、図２０から図２２の電子メールサー
バ３０の電子メールデータベース３１における電子メー
ルでのテーブルの項目の一例を説明する。

【００５４】図２０を用いてＰＯＰテーブル３２を説明
する。ＰＯＰテーブル３２は、利用者端末Ａ４０や利用
者端末Ｂ５０から送信されたメールの利用者宛の電子メ
ールデータを蓄積しておき、電子メールクライアント４
１から要求があった場合に送るためのデーブルである。
このテーブルは、ユーザＩＤ２００１と、送信日時２０
０２と、メールデータ２００３の各項目からなる。

【００５５】図２１を用いてメールＩＤテーブル３３を
説明する。メールＩＤテーブル３３は、利用者のＩＤを
一元管理するテーブルである。このテーブルは、個人の
メールアドレスであるユーザＩＤ２１０１と、認証のた
めのパスワードであるＰＷＤ２１０２と、利用者氏名２
１０３と、所属部署２１０４からなる。通常、電子メー
ルサーバ３０はユーザＩＤ２１０１と、パスワードＰＷ
Ｄ２１０２を管理するのが基本であり、ここでは付加的
に利用者氏名２１０３と、所属部署２１０４を管理する
機能を持つ一例を示している。

【００５６】図２２を用いてＳＭＴＰテーブル３４を説
明する。ＳＭＴＰテーブル３４は、利用者端末Ａ４０の
電子メールクライアント４１から送信された電子メール
データを、メールサーバ制御手段３５がヘッダに記載さ
れた宛先に従ってＰＯＰテーブル３２の該当する格納場
所へ登録するために一時的に格納しているテーブルであ
る。このテーブルは、送信元ＩＤ２２０１、送信日時２
２０２、メールデータ２２０３の各項目からなる。送信
元ＩＤ２２０１、送信日時２２０２、メールデータ２２
０３は、図２０のユーザＩＤ２００１と、送信日時２０
０２と、メールデータ２００３の各項目とそれぞれ対応
する。

【００５７】図９を用いて本発明で利用する電子メール
の送受信の方法を説明する。

【００５８】本発明のシステムでは従来技術の電子メー
ルシステムにおける電子メールデータの送受信を区別す
るため、以下に示す２つの概念を設ける。

【００５９】一つは電子メール情報管理システムで管理
しない通常の電子メールシステムと何ら変わらない利用
をする通常の電子メールの送受信である。次に電子メー
ル情報管理システムで管理対象とする送受信である“業
務メール”である。ここで、便宜的に“業務メール”と
呼称することとする。これは、通常の電子メールシステ
ムで使用する電子メールデータにひとつまたは複数の階
層と種類をもつ識別情報を付加または特定のメールアド
レスを指定して利用する電子メールの送受信である。前
記の識別情報を付加するための方法は、利用者が電子メ
ールを利用するときに使用する宛先、件名、本文、添付
ファイルなどの入力可能な項目の一部分に識別情報を付
加することをで実現する。一例として予め決めておいた
識別情報を示す特殊記号などの文字列“《！！公用！
！》”を件名や本文に入力することが挙げられる。ま
た、前記の特定のメールアドレスを指定する方法は、通
常の送信相手のメールアドレスを指定するのとは別に
“業務メール”を専用として扱う宛先（システム用のメ
ールアドレス）を設定しこれを指定する方法である。前
記の方法を一方または組み合わせて用いると、電子メー
ルクライアント４１の実現方式に左右されずに前記“業
務メール”として識別情報を付加できるといったメリッ
トがある。さらに別の識別情報を付加する方法として、
システムが識別可能な情報を格納した電子ファイルを添
付ファイルとして添付して送信する方法がある。この場
合は前記ファイルを扱うことが直感的で利用者端末の初
心者が利用する場合に有効な方法である。

【００６０】本発明のシステムにおいて、電子メールシ
ステムで受送信する電子メールデータを区別、管理する
実施例の１例を以下に示す。

【００６１】まず、ひとつまたは複数以上の種類と階層
をもつ識別情報を用いる。前記識別情報の有無によっ
て、通常の利用する電子メール送受信で扱う電子メール
データの中から文書サーバに登録管理の対象かどうかを
区別を実現する。ここで“業務メール”といった電子メ
ールデータのあつまりの概念を設ける。識別情報を電子
メールデータの一部に持つのは“業務メール”として識
別し、本発明のシステムで文書管理の対象とする。識別
情報をもたない電子メールデータは電子メールシステム
で通常の送受信する電子メールデータと識別し、本発明
のシステムで文書管理の対象としないとする。

【００６２】次に、識別情報の種類と階層によって本発
明の文書管理システムで複数の管理状態の区別を実現す
る。前記の区別の種類の１例として前記の“業務メー
ル”の受送信状態の種類を２つ設ける。前記の種類を
“公用メール”“起案メール”とする。また、“起案メ
ール”の下位の階層の種類として“決裁中”“完結（決
裁済み）”といった管理状態を設ける。以上のような識
別情報の種類と階層を設けることで、電子メールシステ
ムで送受信される個々の電子メールデータが本発明の文
書管理システムからみた位置づけを区別して識別できる
ようになる。

【００６３】図１を用いて本発明の電子メール情報管理
システムでデータを管理する単位についての概念を説明
する。

【００６４】本発明のシステムは、前記の“業務メー
ル”について利用者が異なった議題（議題、仕事）でや
り取りする個々の電子メールの送受信を“案件”といっ
た概念で管理を行う。前記の“案件”はメールのやり取
りの目的とする議題をまとまりの単位として定義する。
ある利用者が新規の議題をメールで発信し議論を開始す
ることで１案件ができるとし、利用者が他の利用者とや
り取りしたメールは前記の“案件”でひとまとまりの単
位にする。このような概念を設けることで、メールの送
受信関与者となった利用者全員が、ある議論に関して
は、自分以外に受送信された電子メールも含めて一つの
まとまりとして管理できる。

【００６５】本実施例では、１例として、以下の３つの
案件の単位（“業務案件”、“公用案件”、“起案案
件”）で管理する。“公用案件”は公用モードの“業務
メール”においてある議題で関連する電子メールデータ
の集合をまとめる単位と定義する。前記の“公用案件”
は公用文書属性テーブル１２の文書Ｎｏ．１２０１の個
々の識別番号がこれに該当する。“起案案件”は“起案
メール”においてある議題で関連する電子メールデータ
の集合をまとめる単位と定義する。前記の“起案案件”
は決裁文書属性テーブル１５の文書Ｎｏ．１５０１の個
々の識別番号がこれに該当する。“業務案件”は“公用
案件”と“起案案件”それぞれである議題で関連する
“案件”のあつまりを単位と定義する。前記の“業務案
件”は関係管理テーブル１９のＩＤＮｏ．１９０１の個
々の識別番号がこれに該当する。前記の管理単位で電子
メールデータを格納しておくことで、議題のテーマ毎に
関連する電子メールを分類することが出来る。

【００６６】次に、電子メールデータの識別情報の種類
と階層に対応して、本発明の文書管理システムの文書デ
ータベースにおいて、管理対象とする電子メールデータ
（“業務メール”）の管理する概念（“案件”）種類と
の対応関係について実施例の１例を以下に示す。

【００６７】文書サーバ１０の文書データベース１１で
は以下に示す管理の単位で文書管理対象とする電子メー
ルデータを管理する。“業務メール”はすべて“業務案
件”の管理単位で文書データベース１１に格納し管理す
る。また、“業務メール”は“公用メール”“起案メー
ル”といった種類によって前記“業務案件”の下位階層
の管理単位である“公用案件”、“起案案件”を管理単
位として格納し管理する。“公用メール”は“公用案
件”の管理単位で文書データベース１１に格納し管理す
る。“起案メール”は“公用案件”の管理単位でさらに
“決裁中”の管理状態で格納し管理する。“起案案件”
における前記“決裁中”の管理状態は、利用者が前記の
文書管理対象とする電子メール“業務メール”の内容の
一部に指定して送信することで文書処理アプリケーショ
ン２０が行う処理で“完結”の状態の管理に切り替える
こととする。このように、利用者が電子メールシステム
で受送信している電子メールデータの内容や作業の状態
に対応した“案件”という文書データベースの管理単位
を設け、種類や階層で区別することで、利用者が電子メ
ールシステムを利用している業務の状態や、電子メール
システムで取扱う文書の重要度などが変化していったと
きに対応して利用者が指示した適切な管理の種類で管理
することができるようになる。具体例として、明らかに
管理対象として重要度か低い内容（例：電話応対の取り
次ぎの伝言など）文書管理の対象から区別したり、行政
機関における起案・決裁事務において、起案に至る前の
事前調整の個人の素案文書（電子メールデータ、電子文
書ファイル）を管理する状態と、組織として意思決定し
た起案文書を管理状態する状態を区別するといった電子
メールで文書を複数人の間でやり取りする間で変化して
いく文書の重要度に対応した管理ができるようになる。
また、文書を１議題（案件）について議題の関与者同士
と送受信した電子メールデータをひとまとまりの単位と
して管理できるので、決定内容を管理しやすい形で記録
した起案文書（電子メールデータ、電子文書ファイル）
とそれ以前の各個人が個別に管理している素案の文書
（電子メールデータ、電子文書ファイル）を関係づけて
管理できる。図１及び図９から図１１を用いて、本発明
の基本的な考え方及び処理の全体概要を説明する。

【００６８】本発明では、前記の２種類の業務メールの
送受信を実現するため、２種類のシステムを組み合わせ
て用いる。

【００６９】通常の電子メールシステムに（電子メール
サーバ３０のメールサーバ制御手段３５と電子メールサ
ーバデータベース３１及び、利用者端末Ａ４０の電子メ
ールクライアント４１を中心とする）、前記２種類の
“業務メール”機能を実現する文書管理システム（文書
サーバ１０の文書処理アプリケーション２０と文書検索
アプリケーション２２と文書データベース１１及び、利
用者端末Ａ４０のＷｅｂブラウザ４３）の文書管理機能
を組み合わせて従来のメールシステムでは管理されない
文書のやり取りの経緯である作業者間の文書がメールで
交換する動きを通常の電子メールシステムから必要情報
を得ることによって、メールや文書の履歴と併せて蓄積
し、意意思決定のプロセスが顕在化しない状態から追跡
管理しておくことで、後から遡って案件の原因追及が必
要になった場合、思決定過程の記録として電子メールデ
ータ及び添付された電子文書ファイルの履歴、あるいは
進捗情報の検索を実現することを想定している。

【００７０】本システムでは以下の手順で電子メールを
運用していく中で、前記機能を実現するものとする。ま
ず、意思決定の準備として、事前調整のための回覧・相
談等を受ける電子文書ファイルを作成する。例えば、利
用者端末４０において文書作成アプリケーション４２
（ワードプロセッサ、表計算等）により電子文書ファイ
ルを作成し、保管しておく。以下に、本システムが利用
者に運用される業務プロセスの一例を示す。文書を作成
した担当者は、電子メールの本文に主旨説明を記入し、
電子文書ファイルを添付すると共に、前述の識別情報を
付与する操作を行い、利用者は、本システムが管理対象
として登録して返信されたメールを受信し、このメール
を転送して相談または事前調整する相手にメールを送信
する。図１０に、文書管理を開始するときの電子メール
の受送信の概要を例として示す。図１０の１例では、利
用者がシステム宛の特定のメールアドレスを指定して送
信することで、電子メールサーバ３０は文書サーバ１０
に前記該当メール転送する。前記該当メールを受信した
文書サーバ１０はデータベース１１に登録可能な識別番
号を登録し、さらに、受信メールに前記番号を付与して
利用者への返信メールとして返信する。これにより、
“業務メール”を用いてやり取りする内容を文書サーバ
１０で管理できるようになる。つまり、利用者は特定の
メールアドレスを指定するだけで、前記アドレスに送信
したメールは文書管理の対象とするメールにすることが
できる。ここで、本実施例では上記で説明したように文
書管理対象とするメールに種別を設けるために、利用者
がメール送信時点で識別情報を付与している。前記のメ
ール送信時に付与する識別情報が“公用メール”を意味
するものならを“公用メール”、”起案メール”を意味
するものなら“起案メール”の電子メールデータとして
本システムが管理対象とする。ここでは、利用者が、公
用モードを意味する識別情報を付与して送信すると、シ
ステムは“公用メール”として登録した結果を返信メー
ルとして送信することとする。

【００７１】次に、前記“公用メール”を利用者端末に
受信した相手は、担当者が叩き台として作成した電子文
書ファイルを閲覧し、メール本文に意見や修正指示、所
感等を記入または電子文書ファイルを修正・添付して転
送又は返信する。転送又は返信を受けたものは、関与者
から返信された検討事項を見直し、修正後の電子文書フ
ァイルを再度電子メールに添付し送信する。以下、意思
決定の関与者に案件を共通認識させ、文書の内容が整理
され、概ね合意されるまで様々な相手と非定型にメール
のやり取りを繰り返す。図９に利用者間でメールを送受
信途中で、文書管理が行われている概要を例として示
す。ここで、文書管理対象の電子メールが電子メールサ
ーバ３０に送受信されてくるとメール転送アプリケーシ
ョン３６は管理対象のメール（“業務メール”）を振り
分けて文書サーバ１０に転送する。そして、文書サーバ
１０は電子メールサーバ３０から横取りして転送してき
た前記電子メールを逐次履歴として蓄積する。

【００７２】次に、前記“公用メール”で回覧した添付
文書の内容を組織として正式文書にする段階になったと
きに、利用者は、“業務メール”の登録を切り替える操
作を行う。図１０の例に、文書管理状態を変更するとき
の電子メールの受送信の概要を１例として示す。図１０
の１例では、利用者が“公用メール”を特定のメールア
ドレスを指定して送信することで、電子メールサーバ３
０は文書サーバ１０に前記該当メール転送する。前記該
当する“公用メール”を受信した文書サーバ１０は”公
用メール”を“起案メール”として登録方法を切り替え
て、受信メールに”公用メール”であった前記番号を
“起案メール”の番号に書き替えて利用者への返信メー
ルとして返信する。これにより、”公用メール”のとき
の内容を引き継いで、“起案メール”として文書サーバ
１０で管理できるようになる。

【００７３】このあと、通常の意思決定の結果ならこの
まま保管してもよいが、意思決定を正式な文書にしたい
場合は、利用者は、文書サーバから切り替え操作を確認
したメールを受信し、回覧及びその後に管理するための
起案用情報を添付し承認者に送信することで“起案メー
ル”を開始する。その後、下位役職から上位役職の順序
で文書を電子メールを転送し回覧する。このとき、先に
説明した図９の概要でメールがやり取りし、文書サーバ
１０で管理する。

【００７４】図９の１例では、文書サーバ１０は承認情
報と“業務メール”をデータベース１１“業務メール”
とそこから抽出した承認情報に格納する。これで、業務
メールの内容と進捗情報を管理できる。

【００７５】次に、最終承認者（決裁者）が“起案メー
ル”を文書サーバ宛に送信する。図１１に、決裁文書と
して管理している文書を決裁済みの状態に変更するとき
の電子メールの受送信の概要を例として示す。

【００７６】図１１の１例では、利用者が“起案メー
ル”を特定のメールアドレスを指定して送信すること
で、電子メールサーバ３０は文書サーバ１０に前記該当
メール転送する。前記該当する“起案メール”を受信し
た文書サーバ１０は承認情報と“業務メール”をデータ
ベース１１に格納し、データベース１１から文書作成者
（起案者）のアドレスを取り出し、受信メールにのアド
レスを書き替えて利用者への返信メールとして返信す
る。これにより、業務メール内容が決裁され、その結果
を文書作成者に通知できるようになる。

【００７７】先に説明した利用者間で電子文書ファイル
を電子メールシステムでやり取りする流れの中で、本シ
ステムは以下の機能を実現する。電子メールシステムで
受送信されるメールをひとつまたは複数の階層と種類の
管理状態に種別して蓄積していき、あるテーマに関する
まとまりを単位として関係する電子メールデータ及び添
付 文書のデータその他属性情報を併せて履歴の管理が
行える。

【００７８】また、これら本システムで管理している文
書データベース１１に格納されたメールと添付文書のデ
ータに対して、管理目的で付加した文書の属性情報や、
受送信した電子メールデータ、添付ファイルの属性情報
を検索条件にして目的の電子メールデータ、添付ファイ
ルを前記のまとまりの単位で取り出すことができる。

【００７９】本システムは前記に示す全体機能を大きく
２つのサーバを用いたシステム構成で実現する。文書サ
ーバ１０と、電子メールサーバ３０にある機能である。
この２つのサーバで、文書管理対象とするメールを抽出
し、電子文書ファイルの登録を管理する機能と、文書の
内容閲覧、再利用するための機能を実現する。

【００８０】前記の文書管理対象とするメールを抽出
し、電子文書の登録更新を管理する機能は、文書サーバ
１０の機能（文書処理アプリケーション２０）と電子メ
ールサーバ３０の機能（メール転送アプリケーション３
６）を組み合わせて実現する。メール転送アプリケーシ
ョン３６は管理対象とする電子メールデータを選び出し
振り分ける役割であり、文書処理アプリケーション２０
は、前記電子メールデータの登録処理を制御する。ま
た、文書の内容閲覧、再利用するための機能は、文書サ
ーバ１０の機能文書検索アプリケーション２２である。
文書検索アプリケーション２２は、利用者から要求され
た検索条件に従って取り出した文書データベース１１に
蓄積された電子文書ファイル及び電子メールデータを、
利用者端末Ａ４０のＷｅｂブラウザ４３に表示を行う。

【００８１】前記のシステム構成によって本発明の特徴
である文書サーバ１０が電子メールサーバ３０から電子
メールを横取りする機能を図１を用いて以下に実現す
る。まず、利用者が電子メールの送信操作を行うことで
一連の処理の流れが開始する。利用者端末Ａ４０の電子
メールクライアント４１が電子メールサーバ３０のメー
ルデータ制御手段３５に電子メールデータを送信する。
電子メールサーバ３０のメールデータ制御手段３５は電
子メールデータベース３１のＰＯＰテーブル３２の該当
する宛先に前記電子メールデータを格納する。つぎに、
メール転送アプリケーション３６は、メールデータ制御
手段３５が電子メールデータを受信したことを契機とし
て起動し、前記電子メールデータが、文書サーバ１０で
管理対象であることを示すひとつまたは複数の階層と種
類からなる識別情報を有するかどうかを判別して、電子
メールサーバ３０から文書管理の対象と判別した電子メ
ールデータを文書サーバ１０のメール受発信手段２１に
転送する。つぎに、文書サーバ１０では、メール受発信
手段２１を介して文書処理アプリケーション２０は前記
電子メールを取得し、文書処理アプリケーション２０は
前記電子メールデータの内容を解析を行う。つづいて、
解析した識別情報のひとつまたは複数の階層と種類に対
応するひとつまたは複数の文書データベース１１に対す
る登録処理に振り分け、それぞれ実行する。さらにつづ
いて、文書処理アプリケーション２０は、前記電子メー
ルデータに対して前記のひとつまたは複数の階層と種類
の登録処理に対応した宛先の指定及びメールデータの加
工を行い、メール受発信手段２１を介して電子メールサ
ーバ３０に転送する。つぎに、電子メールサーバ３０の
メールデータ制御手段３５は、指定された宛先に従って
前記電子メールデータの送受信処理を行う。最後に、利
用者端末Ｂ５０では電子メールサーバ３０から電子メー
ルデータを送信する。

【００８２】前記のシステム構成と処理手順を取ること
によって利用者によって受送信された電子メールが電子
メールサーバ３０から横取りした形で電子メールデータ
と添付文書ファイルを文書サーバ１０に格納できるた
め、次のような効果が得られる。利用者は文書管理シス
テムの登録画面を操作しなくても電子メールシステムを
利用しているだけで電子メールで扱う情報を文書管理シ
ステムに格納することが可能となる。また、前記のシス
テム構成をとることで、さらに別の効果が生じる。

【００８３】従来技術の電子メールシステムの機能を実
現する電子メールサーバが既設されているネットワーク
システムにおいて、前記のシステム構成を構築して実現
する場合、既設された前記電子メールサーバにメール転
送機能を実現する手段を付加し、本発明の文書管理シス
テムの機能を実現する文書サーバを増設することで実現
できる。これにより、利用者が使い慣れた電子メールシ
ステム置き換えなくても本発明のシステムを実現するこ
とができる。また、電子メールシステムの二重投資を避
けることができる。

【００８４】ここで文書処理アプリケーション２０は、
文書データベース１１に対する処理の１例としてして以
下に示す登録処理を行う。

【００８５】ひとつは、文書サーバ１０が電子メールサ
ーバから受け取ったが電子メールデータを解析して、ひ
とつまたは複数の階層と種類をもつ識別情報または特定
のメールアドレスの指定を判別して、電子メールデータ
の登録単位である“案件”を生成し、前記電子メールデ
ータに対して前記の生成した“案件”を対応づけた管理
番号を付与した電子メールデータを利用者に通知する処
理である。

【００８６】またもうひとつは、前記の“案件”と前記
の識別情報で関係づけられた電子メールデータを解析し
てひとつまたは複数の階層と種類をもつ識別情報または
特定のメールアドレスの指定を判別して、前記電子メー
ルデータとそこから抽出した添付文書ファイルを前記の
該当“案件”に格納する処理である。またもうひとつ
は、前記電子メールデータに付加した識別情報の種類ま
たは特定のメールアドレスの指定が変わったことを判別
して種類の異なる“案件”を生成またはステータスを変
更し、前記の結果を電子メールデータを利用者に通知す
る処理である。さらにまたもうひとつは、前記電子メー
ルデータ解析して、ひとつまたは複数の階層と種類をも
つ識別情報または特定のメールアドレスの指定を判別し
て、電子メールシステムの転送を制御して起案・決裁事
務といった事務手続き情報を登録する処理である。これ
ら文書処理アプリケーション２０が行う登録処理の詳細
な手順は以降で述べる。

【００８７】以下、前記の電子文書の登録を管理する機
能を構成する２つのサーバで行う機能（“メール転
送”、“文書処理”）につき詳細に説明する。

【００８８】最初に、“メール転送”につき詳細に説明
する。

【００８９】図２は、電子メールサーバ３０における送
信メールの中から、メール転送アプリケーション３６が
文書サーバ１０で管理対象とする“業務メール”を振り
分け、該当するメール文書サーバ１０に転送することが
できる実施例である。本処理が、前記で述べた２つのサ
ーバ構成で本発明を実施するために電子メールシステム
が機能するサーバ（電子メールサーバ３０）に付加する
メール転送機能を実現する手段の１例である。

【００９０】メールサーバ制御手段３５が、ＳＭＴＰテ
ーブル３４に送信メール受け取りＰＯＰテーブル３２格
納することを契機に本処理を行う。初期段階では、処理
要求がきているかどうかを判定するループを実行してい
る（ステップ２００）。メールサーバ制御手段３５がメ
ールの送信処理が行われる通知を受け取ると、該当電子
メールデータをＰＯＰテーブル３２からメールデータ２
２０３を読み込む（ステップ２０１）。前記電子メール
データの宛先を判定する。宛先が特定のシステム用のメ
ールアドレスであった場合はステップ２０３に進み、そ
うでない場合はステップ２０４に進む（ステップ２０
２）。宛先が特定のシステム用のメールアドレス（実施
例ではTouroku@h.go.jp、kessai@h.go.jp、jidou@h.go.
jp）であった場合は本処理は文書サーバ１０のメール転
送手段２１の該当アドレスに相当する文書サーバ１０の
アドレス（１例としてTouroku@h2.go.jp、kessai@h2.g
o.jp、jidou@h2.go.jp）へ電子メールデータを転送する
ため、送信するこれにより、文書サーバ１０側では宛先
ごとに“開始”、“決裁”“経路中継”の各処理に引継
いて処理を続ける（ステップ２０３）。宛先が通常の利
用者のメールアドレスである場合は、次に、前記電子メ
ールデータの内容を解析し文書サーバ１０で管理対象で
あることを示す（特定の文字列や、添付ファイル等の）
識別情報が存在するかを判定する。識別情報がない場合
はステップ２０５に進み、そうでない場合はステップ２
０６に進む（ステップ２０４）。識別情報がなかった場
合は、通常の電子メールとして送信された通常の電子メ
ールデータであるので、通常の送信処理を行うためにメ
ールサーバ制御手段３５に処理を引き渡す（ステップ２
０５）。ステップ２０４で前記識別情報があったと判定
した場合、該当メールは文書サーバ１０で管理対象のメ
ールであるので電子メールデータを複写して一方を通常
の送信処理を行うためにメールサーバ制御手段３５に処
理を引き渡す（ステップ２０６）。次に複写しておいた
電子メールデータの宛先を文書サーバ１０のメール転送
手段２１のアドレス（実施例ではshounin@h2.go.jp）に
書き替えて電子メールデータの転送処理行う。これによ
り文書サーバ１０側で“承認”処理に引継いて処理を続
ける（ステップ２０７）。

【００９１】次に、“文書処理”につき詳細に説明す
る。

【００９２】図３は、文書サーバ１０における文書の処
理業務を選択する初期処理の実施例である。利用者が
“業務メール”を送る操作を利用者端末Ａ４０の入力装
置４４から受け取り、電子メールクライアント４１が電
子メールサーバ３０のメールサーバ制御手段３５に電子
メールデータを送信する。そして、利用者が送信した
“業務メール”が受信者に届けられるまでに文書サーバ
１０と電子メールサーバ３０との間で以下の処理を行
う。メールサーバ制御手段３５を介してメール転送アプ
リケーション３６が送信対象のメールデータから“業務
メール”を文書サーバ１０に転送する。そして、文書処
理アプリケーション２０は、文書サーバ１０においてメ
ール受発信手段２１が受け取った“業務メール”を以降
に説明する個別の文書処理サブ機能（“開始”“承認”
“決裁”“経路中継”）に処理を振り分けることを行
う。“業務メール”であるメールデータをメール受発信
手段２１が受信することで、文書処理アプリケーション
２０が起動し、本処理を開始する。初期段階では、処理
要求がきているかどうかを判定するループを実行してい
る（ステップ３００）。メール受発信手段２１が受信し
た電子メールデータを読み出す（ステップ３０１）。前
記電子メールデータのヘッダ情報を解析し電子メールデ
ータの宛先を判定する。宛先が“承認”処理の対象であ
ることを示す通常の利用者のメールアドレス（実施例で
はshounin@h.go.jp）が指定してあった場合は、図９に
示す受送信がされる電子メールデータであると判断でき
るので、ステップ３０３に進み、そうでない場合はステ
ップ３０４に進む（ステップ３０２）。前記のアドレス
指定であった場合は、“承認”処理に処理を引き渡す
（ステップ３０３）。そうでなかった場合は、電子メー
ルデータの宛先が“開始”処理に割り当てられたメール
アドレスであるかを判定する。“開始”処理を示すアド
レス指定であった場合は、図１０に示す受送信がされる
電子メールデータであると判断できるので、ステップ３
０５に進む。そうでない場合は、図１１に示す受送信が
される電子メールデータであると判断できるので、ステ
ップ３０６に進む（ステップ３０４）。“開始”処理宛
てのメールアドレス（実施例ではTouroku@h2.go.jp）で
あった場合は、“開始”処理に処理を引き渡す（ステッ
プ３０５）。さらに、前記のアドレス指定でなかった場
合は、電子メールデータの宛先が“決裁”処理に割り当
てられたメールアドレスであるかを判定し、そうである
場合はステップ３０７に進み、そうでない場合はステッ
プ３０８に進む（ステップ３０６）。“決裁”処理宛て
のメールアドレス（実施例ではkessai@h2.go.jp）であ
った場合は、“決裁”に処理を引き渡す（ステップ３０
７）。そうでない場合、“経路中継”処理宛てのメール
アドレス（実施例ではjidou@h2.go.jp）であるときは、
“経路中継”に処理を引き渡す（ステップ３０８）。以
下、前記機能を構成する個別のサブ機能（“開始”“承
認”、“決裁”、“経路中継”）につき詳細に説明す
る。

【００９３】まず、“文書処理”の１番目のサブ機能と
して、“開始”処理の１実施例を説明する。

【００９４】図４は、利用者から送信された通常のメー
ルと“公用メール”から新規に文書管理の対象とする事
前準備を行うことができる実施例である。本処理に入る
前に、利用者は“業務メール”を開始するため、文書サ
ーバ宛のアドレス（touroku@h.go.jp）にメールを送信
しているものとする。図２３にメール送信の操作例を示
す。２３０１に示すアドレスを指定し、必要に応じて２
３０２に示す仮のタイトル入力し、２３０３を押下する
操作を行う。この状態において、電子メールサーバ３０
を介して文書サーバ１０に届けられたメールを文書処理
アプリケーション２０が処理中である場合に、図３の
“文書処理”処理（ステップ３０５）において“開始”
処理が選択された場合に本処理に移る。

【００９５】メール受発信手段２１が受信した“業務メ
ール”である電子メールデータの内容を解析し、識別情
報（識別ＩＤ、一連番号）を抽出する（ステップ４０
０）。次に、“業務メール”が”公用メール”が“起案
メール”であるかを識別する識別ＩＤを判定する。識別
ＩＤが”公用メール”のＩＤ（１例としてメール本文中
にある“［公用］”または図２７の２７０１に示す添付
ファイル）であれば、ステップ４０２に進み、“起案メ
ール”であればステップ４０６に進む（ステップ４０
１）。

【００９６】識別ＩＤが“公用メール”であれば、続い
て“公用メール”を管理する“公用案件”の一連番号
（１例として“Ａ０００１０００”）があるかを判定す
る。前記番号があれば、ステップ４０３に進み、そうで
なければステップ４０９に進む（ステップ４０２）。

【００９７】“公用案件”の識別ＩＤであるが一連番号
がない場合は、利用者が送付したメールは、新規に公用
文書の管理を開始する要求であると判断し、以下の処理
を行う。文書データベース１１の公用文書属性テーブル
１２の文書Ｎｏ．１２０１を参照し、最新の一連番号を
取得し、前記雛形メールに書き込む（ステップ４０
３）。ここで、新規に公用文書として管理を受け付けた
結果を利用者に返信するために、雛形メールのデータを
文書データベース１１から取り出し受信した“業務メー
ル”に書き込んでもよい。次に、公用文書属性テーブル
１２にレコードを生成し、前記一連番号、利用者から受
信した“業務メール”にある送信アドレス、送信日時、
メールタイトル等を抽出し、公用文書属性テーブル１２
の文書Ｎｏ．１２０１、作成者１２０２、作成日時１２
０３、件名１２０４にそれぞれ格納する。続いて、関係
管理テーブル１９にレコードを生成し、前記公用文書属
性テーブル１２に格納した、文書Ｎｏ．１２０１を公用
Ｎｏ．１９０２に、作成日時１２０３を登録日時１９０
３にそれぞれ格納する。また、送信件数１２０５に
“０”を格納する。このあとステップ４１４以降処理に
進む（ステップ４０４）。

【００９８】一方、識別ＩＤが“起案メール”を管理す
る“起案案件”である場合、“起案案件”の一連番号
（１例として“Ｂ０００１３５５”）があるかを判定す
る。前記番号がなければ、ステップ４０７に進み処理を
継続する。利用者から受信したメールに誤りがあると判
断し、ステップ４１７のエラー返信用処理に進む（ステ
ップ４０５）。

【００９９】“起案案件”の識別ＩＤで一連番号がなけ
れば、利用者が送付したメールは、新規に決裁文書の管
理を開始する要求であると判断し、“起案案件”で“業
務メール”を管理するための処理を以下に実施する。新
規に決裁文書として管理を受け付けた結果を利用者に返
信するために、雛形メールの電子メールデータを文書デ
ータベース１１から取り出し、受信した“業務メール”
の本文に書き込む（ステップ４０６）。

【０１００】次に、文書データベース１１の決裁文書属
性テーブル１５の文書Ｎｏ．１５０１を参照し、最新の
一連番号を取得し、前記雛形メールに書き込む（ステッ
プ４０７）。

【０１０１】次に、決裁文書属性テーブル１５にレコー
ドを生成し、前記一連番号、利用者から受信した“起案
メール”にある送信アドレス、送信日時、メールタイト
ル等を抽出し、決裁文書属性テーブル１５の文書Ｎｏ．
１５０１、作成者１５０２、作成日時１５０３、件名１
５０４にそれぞれ格納する。続いて、関係管理テーブル
１９にレコードを生成し、前記決裁文書属性テーブル１
５に格納した、文書Ｎｏ．１５０１を決裁Ｎｏ．１９０
２に、作成日時１５０３を登録日時１９０３にそれぞれ
格納する。また、送信件数１５０９、に“０”を格納す
る。このあとステップ４１４以降処理に進む（ステップ
４０８）。

【０１０２】“公用案件”の識別ＩＤで一連番号がある
場合は、既に登録済みの“公用メール”であると判断
し、管理対象とする“案件”の種類 “公用案件”から
“起案案件”にを変更して管理するための処理を以下に
実施する。まず、利用者から受信したメールの“公用案
件”の一連番号を文書データベース１１の公用文書属性
テーブル１２の文書Ｎｏ．１２０１を参照する（ステッ
プ４０９）。

【０１０３】次に、文書Ｎｏ．１２０１に番号が存在す
るなら処理を継続する。また、存在しない場合は、利用
者から受信したメールに誤りがあると判断し、ステップ
４１７のエラー返信用メール作成処理に進む（ステップ
４１０）。

【０１０４】文書Ｎｏ．１２０１に番号が存在する場
合、文書データベース１１の決裁文書属性テーブル１５
の文書Ｎｏ．１５０１を参照し、該当“起案案件”内の
“起案メール”の最新の一連番号を取得し、続いて、前
記“公用メール”の一連番号と関係管理テーブル１９の
文書Ｎｏ．１９０２が一致するレコードの決裁Ｎｏ．１
９０４、登録日時１９０５に、前記文書Ｎｏ．１５０１
に格納した“起案メール”の一連番号と、受信メールか
ら抽出した送信日時をそれぞれ格納する。これにより、
以前の“公用メール”を引き継いで、新たに“起案メー
ル”を文書データベース１１で管理することが可能にな
る。（ステップ４１１）。

【０１０５】ここで、図３１と図３２で、利用者が前記
切り替えの処理を要求するメールの操作を説明する。図
３１は“公用メール”を“起案メール”に切り替える前
の状態を示している。図３２は切り替えの指定を行う１
例を示している。３２０１に示すように受信メールの転
送操作を行った後、３２０１に示すアドレス指定を行
い、３２０３を押下することで切り替えのためのメール
を送信する。

【０１０６】次に、“公用メール”から管理の種類を変
更した登録結果を電子メールデータを送信した該当する
利用者に通知するため、前記受信メールの”公用メー
ル”の一連番号を前記“起案メール”の一連番号と書き
替える（ステップ４１２）。

【０１０７】次に、決裁文書属性テーブル１５にレコー
ドを生成する。前記“起案メール”の一連番号、受信メ
ールから抽出した送信宛先、送信日時、を文書Ｎｏ．１
５０１、作成者１５０２、作成日時１５０３にそれぞれ
格納する。また、送信件数１５０９に“０”を格納する
（ステップ４１３）。

【０１０８】以降、利用者へ前記の登録結果をメールで
通知するための処理を行う。前記の処理対象の“業務メ
ール”が次承認者へのメール送信をシステムが代行する
“経路中継”処理用であるかを判定する。メールの宛先
がシステム用の宛先（１例としてjidou@h2.go.jp）であ
れば、ステップ４１５に進み、そうでなければステップ
４１５を飛ばしてステップ４１６に進む（ステップ４１
４）。

【０１０９】メールの本文又は添付ファイルにアドレス
宛先がシステムの“経路中継”処理用の宛先（１例とし
てＴｏ：jidou@h2.go.jp）であり、かつ、メール本文中
または添付ファイルに格納されている回覧経路を示すア
ドレスが存在するなら、送信元をメールの宛先がシステ
ム用の宛先（１例としてＦｒｏｍ：jidou@h.go.jp＜Fro
mＡ＞）に書き換え、前記の宛先リストから次の送信先
アドレスを取り出して書き込む。（ステップ４１５）。

【０１１０】“経路中継”処理用の“業務メール”でな
い場合は、利用者に前記の登録結果を返信するため、受
信メールのヘッダ情報の送信者と受信者のメールアドレ
スを入れ替える（ステップ４１６）。

【０１１１】ステップ４０５、ステップ４１０から処理
を引き継いだ場合、利用者からの受信メールがエラーで
あったことを通知する返信メールを作成する（ステップ
４１７）。

【０１１２】前記処理で新規作成または加工した返信用
メールを利用者に送信するため、メール受発信手段２１
処理に前記メールデータを引き渡す。これにより利用者
は、利用者端末Ａ４０の電子メールクライアントで登録
結果を通知する前記メールを受信する事ができる。図２
４に利用者が登録結果を受信した例を示す（ステップ４
１８）。以後、利用者が図２５の２５０１例に示すメー
ル本文と送付したい宛先を入力装置４４から入力し、２
５０２を押下することで“公用メール”が開始する。図
２６の例では２６０１に前記“公用メール”を受信した
例を示している。

【０１１３】これにより、利用者は、電子メールシステ
ムで特定のメールアドレス指定してメール送信の操作を
行うことで、文書管理システムの登録画面を操作するこ
とを意識せずに文書管理対象とする“業務メール”を新
規に開始（“公用案件”の新規作成）または“業務メー
ル”の管理の種類を（“公用案件”を“公用案件”に）
変更する指定を行うことができる。

【０１１４】また、図２３で示した特定のメールアドレ
ス指定による登録方法とは別の方法として、識別情報を
含む電子ファイルを電子メールデータに添付し、システ
ム処理用の特定の宛先を指定せずに直接通常のアドレス
を指定し送付する方法が挙げあられる。図２７では、、
利用者端末Ａ４０において前記の識別情報を付加して電
子メールデータを送付する方法を用いた文書管理の対象
とする電子メールを指定する操作を示す画面の１例であ
る。

【０１１５】図２７の電子ファイル２７０１の１例とし
て“公用案件”の番号である文書Ｎｏ．１２０１を格納
したＨＴＭＬ文書などである。さらに、前記電子ファイ
ル２７０１に“決裁案件”の番号である文書Ｎｏ．１５
０１を格納した場合は、“公用メール”を“起案メー
ル”に管理の種類を変更する指定をすることができる。

【０１１６】電子文書ファイル識別情報として付加した
電子メールデータで本処理を実施する場合の手順につい
て、前記の処理との違いを図４を用いて以下に説明す
る。まず、ステップ４００において、前記の電子文書フ
ァイル２７０１を電子メールデータに付加されている前
記の電子ファイルの内容を識別情報で判別する。前記の
電子ファイルの内容が“公用案件”の識別番号である文
書Ｎｏ．１２０１であれば、ステップ４０２に進み、
“起案案件”の識別番号である文書Ｎｏ．１５０１であ
ればステップ４０６に進む。

【０１１７】以下同様に処理を続ける。そして本処理の
結果を通知する処理（ステップ４１５、４１６）におい
て、通知メールの送信者のアドレスを指定した電子メー
ルデータと、受信者のアドレスを指定した電子メールデ
ータを２つ作成する。

【０１１８】以上の処理に変更することで図２８の２８
０１に示すような結果をメールの送信者と受信者双方に
通知する。これにより、文書管理対象の電子メールを新
規に開始や、文書管理対象の電子メールの管理の種類を
変更を指定する場合に、メール送信者がシステムへの登
録結果を待つことなく、１回のメール送信操作で処理が
行える。また、操作性の観点から見ると、該当するメー
ルを文書管理の対象にする操作条件が予め指定した特定
のファイルを添付するだけであるため、利用者は、通常
のメール操作方法と違和感を感じることなく自然に扱え
る。

【０１１９】“文書処理”の２番目のサブ機能として、
“承認”処理の１実施例を説明する。

【０１２０】図５は、利用者から送信された“業務メー
ル（公用モード、起案メール）”を受送信のやり取りが
関係する過去のメール及び添付文書とを関連づけて格納
しておくことができる実施例である。

【０１２１】本処理に至る前に、利用者は、他の利用者
から受信した“業務メール”を次の相手（一例として
“公用メール”の場合は相談、事前調整する他部署の人
間であり、“起案メール”では次承認者）に送信するも
のとする。図２９、図３０の例を用いて操作の流れを示
す。図２９の２９０１に示すように、利用者は利用者端
末Ａ４０の入力装置４４から前記の宛先（一例としてＣ
@h.go.jp）を指定し、２９０２を押下して電子メールク
ライアント４１が電子メールサーバ３０へ“業務メー
ル”を送信する。利用者端末Ｂ５０の受信相手は電子メ
ールサーバ３０を介して“業務メール”を受信する。図
３０にメールの受信状態の１例を示す。このとき、業務
メールは電子メールサーバ３０を介して文書サーバに格
納される。前記の“業務メール”の受送信の概要を図９
に示す。

【０１２２】以下の場合に、本処理を行う。電子メール
サーバ３０を介して文書サーバ１０に届けられたメール
を文書処理アプリケーション２０が処理中であり、図３
の“文書処理”処理（ステップ３０３）において“承
認”処理が選択された場合に本処理に移る。

【０１２３】まず、メール受発信手段２１が受信した
“業務メール”である電子メールデータの内容を解析
し、識別情報（識別ＩＤ、一連番号）を抽出する（ステ
ップ５００）。

【０１２４】“業務メール”が“公用メール”か“起案
メール”であるかを識別する識別ＩＤを判定する。識別
ＩＤが“公用メール”のＩＤ（１例としてメール本文中
にある“［公用］”または添付ファイル）であれば、ス
テップ５０２に進み、“起案メール”であればステップ
５０７に進む（ステップ５０１）。

【０１２５】識別ＩＤが“公用メール”であれば、続い
て“公用メール”の一連番号（１例として“Ａ０００１
０００”）があるかを判定する。前記番号があれば、ス
テップ５０３に進む。前記番号がなければ、利用者から
受信したメールに誤りがある（新規登録のための業務メ
ールを通常に送信した場合など）と判断し、ステップ５
１７のエラー返信用メール作成処理に進む（ステップ５
０２）。

【０１２６】“公用メール”の識別ＩＤで一連番号があ
れは、利用者が送付したメールは、公用文書として管理
対象とする“業務メール”を追加登録する要求であると
判断し、“公用メール”で文書を追加登録するための処
理を以下に実施する。まず、文書データベース１１の公
用文書属性テーブル１２の文書Ｎｏ．１２０１を参照
し、受信メールから識別した前記一連番号に対当するレ
コードを取得する（ステップ５０３）。

【０１２７】前記の該当レコードがあれば、処理を継続
し、そうでなければステップ５１７のエラー返信用メー
ル作成処理に進む（ステップ５０４）。

【０１２８】利用者から受信した“業務メール”を登録
するため、ヘッダ情報、本文、添付ファイルそれぞれか
ら、送信者アドレス、受信者信者アドレス、送信日、を
抽出する。さらに、添付ファイルの属性情報を解析し抽
出する。（ステップ５０５）。

【０１２９】前記の該当レコードがある場合、次に、公
用文書属性テーブル１２の送信件数１２０５を確認し、
利用者から受信した“業務メール”が１回目かどうかを
判定する。公用文書属性テーブル１２の送信件数１２０
５が“０”であれば、前記業務メールが１回目でと判断
し、ステップ５０７に進む。そうでない場合は、次のス
テップ５０７を省略しステップ５０８に進む（ステップ
５０６）。

【０１３０】前記業務メールが１回目であれば、本ステ
ップを行う。

【０１３１】公用文書属性テーブル１２に受信メールか
ら抽出した情報を格納する。公用文書属性テーブル１２
の件名１２０４に前記抽出した件名を格納する。また、
以前書かれている送信件数１２０５に１加算する。ま
た、前記抽出した送信メールアドレスと受信アドレス
を、公用経路テーブル１４の文書Ｎｏ．１４０１と前記
一連番号が一致する該当レコードの送信者１４０４と受
信者１４０５と比較して一致しなければそれぞれの分を
１加算する。

【０１３２】つづいて、公用文書履歴管理テーブル１
３、公用経路テーブル１４の２つのテーブルに受信メー
ルから抽出した情報を格納する。公用文書履歴管理テー
ブル１３の文書Ｎｏ．１３０１に前記一連番号、メール
Ｎｏ．１３０２に“０００１”、送信日時１３０３に前
記受信メールの送信日、メールデータ１３０４に前記受
信メール、添付文書１３０５に前記抽出した添付ファイ
ル、属性１３０６に前記添付ファイルの属性情報、履歴
１３０７に“１”をそれぞれ格納する。公用経路テーブ
ル１４の文書Ｎｏ．１４０１に前記一連番号、メールＮ
ｏ．１４０２に“０００１”、送信日時１４０３に前記
受信メールの送信日、送信者１４０４に前記受信メール
の送信者、受信者１４０５に前記受信メールの受信者、
送信回数１４０６に“１”添付文書数１４０７に前記抽
出した添付ファイルの数をそれぞれ格納する。（ステッ
プ５０７）。

【０１３３】前記業務メールが２回目以降であれば、本
ステップを行う。

【０１３４】公用文書履歴管理テーブル１３、公用経路
テーブル１４の２つのテーブルに受信メールから抽出し
た情報を格納する。公用文書履歴管理テーブル１３の文
書Ｎｏ．１３０１に前記一連番号、送信日時１３０３に
前記受信メールの送信日、メールデータ１３０４に前記
受信メール、添付文書１３０５に前記抽出した添付ファ
イル、属性１３０６に前記添付ファイルの属性情報をそ
れぞれ格納する。また、メールＮｏ．１３０２には、前
記一連番号と一致しかつメールＮｏ．１３０２の最新番
号のレコードに格納されている数をそれぞれ１加算し格
納する。履歴１３０７には前記一連番号と一致しかつメ
ールＮｏ．１３０２の最新番号のレコードに格納されて
いる数値を、前記該当レコードに格納されている文書フ
ァイルと比較し、変更があれば１加算し格納する。公用
経路テーブル１４の文書Ｎｏ．１４０１に前記一連番
号、送信日時１４０３に前記受信メールの送信日、送信
者１４０４に前記受信メールの送信者、受信者１４０５
に前記受信メールの受信者、添付文書数１４０７に前記
抽出した添付ファイルの数をそれぞれ格納する。また、
メールＮｏ．１４０２、送信回数１４０６には、前記一
連番号と一致しかつメールＮｏ．１４０２の最新番号の
レコードに格納されている数をそれぞれ１加算し格納す
る。（ステップ５０８）。

【０１３５】識別ＩＤが“起案メール”であれば、続い
て“起案メール”の一連番号（１例として“Ｂ０００１
０００”）があるかを判定する。前記番号があれば、ス
テップ５１０に進み、そうでなければステップ５１７の
に進む（ステップ５０９）。

【０１３６】“起案メール”の識別ＩＤで一連番号があ
れば、決裁文書として管理対象とする“業務メール”を
追加登録する要求であると判断し、“起案メール”で文
書を追加登録するための処理を以下に実施する。まず、
文書データベース１１の決裁文書属性テーブル１５の文
書Ｎｏ．１５０１を参照し、受信メールから識別した前
記一連番号に対当するレコードを取得する（ステップ５
１０）。

【０１３７】前記の該当レコードがあれば、処理を継続
し、そうでなければステップ５１７のエラー返信用メー
ル作成処理に進む（ステップ５１１）。

【０１３８】前記の該当レコードがある場合、“業務メ
ール”のヘッダ情報、本文、添付ファイルそれぞれか
ら、送信者アドレス、受信者アドレス、送信日、を抽出
する。さらに、“起案メール”のメール本文中に記述さ
れている起案文書の表紙の情報を、タグ等で識別し、件
名、分類コード、文書保存年限、コメント欄、承認を表
す文字列（１例として“！！承認！！”“！！ＯＫ！
！”“！！代理！！”）といった情報を抽出する。ま
た、添付ファイルの属性情報を解析し抽出する。（ステ
ップ５１２）。

【０１３９】次に、決裁文書属性テーブル１５の送信件
数１５０９、を確認し、利用者から受信した“業務メー
ル”が１回目のものかどうかを判定する。決裁文書属性
テーブル１５の送信件数１５０９が“０”であれば、前
記業務メールが１回目でと判断し、ステップ５０６に進
む。そうでない場合は、次のステップ５０６を省略しス
テップ５０７に進む（ステップ５１３）。

【０１４０】前記業務メールが１回目であれば、本ステ
ップを行う。

【０１４１】つづいて、決裁文書属性テーブル１５に受
信メールから抽出した情報を格納する。決裁文書属性テ
ーブル１５の件名１５０４に前記抽出した件名、分類コ
ード１５０５に前記抽出した分類コード、文書保存年限
１５０７に前記抽出した文書保存年限、コメント欄１５
０８に前記抽出したコメント欄を格納する。また、以前
書かれている送信件数１５０９を１加算する。

【０１４２】これにより、最初を送信した業務メール内
容及び、決裁のための文書として起案した文書管理のた
めの情報が管理できるようになるさらにつづいて、決裁
文書履歴管理テーブル１６、決裁経路テーブル１７、承
認情報テーブル１８の３つのテーブルに受信メールから
抽出した情報を格納する。決裁文書履歴管理テーブル１
６の文書Ｎｏ．１６０１に前記一連番号、メールＮｏ．
１６０２に“０００１”、送信日時１６０３に前記受信
メールの送信日、メールデータ１６０４に前記受信メー
ル、添付文書１６０５に前記抽出した添付ファイル、属
性１６０６に前記添付ファイルの属性情報、履歴１６０
７に“１”をそれぞれ格納する。決裁経路テーブル１７
の文書Ｎｏ．１７０１に前記一連番号、メールＮｏ．１
７０２に“０００１”、送信日時１７０３に前記受信メ
ールの送信日、送信者１７０４に前記受信メールの送信
者、受信者１７０５に前記受信メールの受信者、送信回
数１７０６に“１”添付文書数１７０７に前記抽出した
添付ファイルの数をそれぞれ格納する。承認情報テーブ
ル１８の文書Ｎｏ．１８０１に前記一連番号、送信者１
８０２に前記抽出した送信者アドレス、受信者１８０３
に前記抽出した受信者アドレス、送信日時１８０４に前
記受信メールの送信日、送付状態１８０５に前記抽出し
た承認を表す文字列をそれぞれ格納する（ステップ５１
４）。

【０１４３】前記業務メールが２回目以降であれば、本
ステップを行う。

【０１４４】決裁文書履歴管理テーブル１６、決裁経路
テーブル１７、承認情報テーブル１８の３つのテーブル
に受信メールから抽出した情報を格納する。決裁文書履
歴管理テーブル１６の文書Ｎｏ．１６０１に前記一連番
号、送信日時１６０３に前記受信メールの送信日、メー
ルデータ１６０４に前記受信メール、添付文書１６０５
に前記抽出した添付ファイル、属性１６０６に前記添付
ファイルの属性情報をそれぞれ格納する。また、メール
Ｎｏ．１６０２には、前記一連番号と一致しかつメール
Ｎｏ．１７０２の最新番号のレコードに格納されている
数をそれぞれ１加算し格納する。履歴１６０７には前記
一連番号と一致しかつメールＮｏ．１７０２の最新番号
のレコードに格納されている数値を、前記該当レコード
に格納されている文書ファイルと比較し、変更があれば
１加算し格納する。決裁経路テーブル１７の文書Ｎｏ．
１７０１に前記一連番号、送信日時１７０３に前記受信
メールの送信日、送信者１７０４に前記受信メールの送
信者、受信者１７０５に前記受信メールの受信者、添付
文書数１７０７に前記抽出した添付ファイルの数をそれ
ぞれ格納する。また、メールＮｏ．１７０２、送信回数
１７０６には、前記一連番号と一致しかつメールＮｏ．
１７０２の最新番号のレコードに格納されている数をそ
れぞれ１加算し格納する。承認情報テーブル１８の文書
Ｎｏ．１８０１に前記一連番号、送信者１８０２に前記
抽出した送信者アドレス、受信者１８０３に前記抽出し
た受信者アドレス、送信日時１８０４に前記受信メール
の送信日、送付状態１８０５に前記抽出した承認を表す
文字列をそれぞれ格納する（ステップ５１５）。

【０１４５】ステップ５０２、ステップ５０４、ステッ
プ５０９、ステップ５１１の処理で、利用者から受信し
たメールに誤りがあると判断した場合、前記受信メール
がエラーであったことを通知する返信メールを作成す
る。受信メールのヘッダ情報の送信者と受信者のメール
アドレスを入れ替える（ステップ５１６）。

【０１４６】前記処理で新規作成または加工した返信用
メールを利用者に送信するため、メール受発信手段２１
処理に前記電子メールデータを引き渡す。これにより利
用者は、利用者端末Ａ４０の電子メールクライアントで
登録結果を通知する前記メールを受信する事ができる
（ステップ５１７）。またここで、“業務メール（決済
モード）”において図３７、図３８に示す別の実施例が
挙げることができる。図３７の３７０１の例に示したフ
ァイルまたはアプリケーションを添付して転送していく
方法である。前記ファイルで起動する業務画面を用いる
ことで、文書サーバ１０の文書データベース１１に格納
された電子文書ファイルを動かすことなく、参照更新す
る手段をメールで受け渡すことが可能になる。

【０１４７】“文書処理”の３番目のサブ機能として、
“決裁”処理の１実施例を説明する。

【０１４８】図６は、“起案メール”を用いて文書の承
認・回覧（“承認”処理）を行う場合において、利用者
が最後の承認者として文書の承認（決裁）するとき、文
書作成者（起案者）への電子メールの転送のためのメー
ルアドレスの指定や最終の承認操作などを省略できる実
施例である。

【０１４９】図１０は、利用者が“起案メール”を電子
メールクライアントを用いて送信したら、前記メールに
関係する決裁文書の管理状態を切り替え、変更結果を業
務を最初の文書作成者（起案者）及び関与者など適切な
相手に通知するメールの受送信の流れを示している。

【０１５０】前記のメール受送信における電子メールサ
ーバを介して、利用者からのメール転送を受信した文書
サーバが行う処理を以下に示す。

【０１５１】本処理に至る前に、利用者（最終承認者）
は、他の利用者から受信した“業務メール”の内容を最
終的に承認した記録を残すことと、作成者（起案者）に
その結果を伝える（書類の返送）を行う必要がある状態
とする。図３３の３３０１に決裁依頼のメールを受信し
た１例を示す。ここで、先に説明した“承認”処理であ
れば、以下の操作を行えば実現可能となる。次操作の流
れとしては、利用者（最終承認者）は利用者端末Ａ４０
の入力装置４４から作成者（起案者）の宛先（一例とし
てＡ@h.go.jp）を指定し、かつメール本文中に承認の意
思を表す文字列（！！承認！！など）を指定し、電子メ
ールクライアント４１から電子メールサーバ３０へ“業
務メール”を送信することになる。しかし、利用者（最
終承認者）は受信する“起案メール”が多くなるので、
前述した操作負担を減らす必要がある。前述の負担を軽
減する操作として、図３４にメールで決裁操作を行う１
例を示す。利用者（最終承認者）は受信した決裁依頼の
“業務メール”を、３４０１に示すように、文書サーバ
宛のアドレス（例としてkessai@h.go.jp）を指定し、３
４０２を押下して送信することで、決裁の承認情報を文
書サーバに登録したあと、文書作成者（起案者）は該当
メールを受信する操作の流れを実現するものとする。

【０１５２】この操作方法により、宛先をシステムが利
用するアドレスを指定することで、文書の内容を承認し
たことを明示する文字列をメール中に示す操作（例とし
て本文に“！！決裁！！”“！！認可！！”“！！ＯＫ
です！！”と記入）や、文書作成者（起案者）やメール
を回覧している案件の関与者（途中の承認者）へ文書を
決裁したことを通知する操作を省略できる。

【０１５３】以下の場合に、本処理を行う。電子メール
サーバ３０を介して文書サーバ１０に届けられたメール
を文書処理アプリケーション２０が処理中であり、図３
の“文書処理”処理（ステップ３０７）において“決
裁”処理が選択された場合に本処理に移る。

【０１５４】まず、メール受発信手段２１が受信した
“業務メール”である電子メールデータの内容を解析
し、識別情報（識別ＩＤ、一連番号）を抽出する（ステ
ップ６００）。

【０１５５】“業務メール”が“公用メール”が“起案
メール”であるかを識別する識別ＩＤを判定する。識別
ＩＤが“起案メール”のＩＤ（１例としてメール本文中
にある“［決裁］”または添付ファイル）であれば、ス
テップ６０２に進み、“起案メール”でなければステッ
プ６０９のエラー返信用メール作成処理に進む（ステッ
プ６０１）。

【０１５６】識別ＩＤが“起案メール”であれば、続い
て“起案メール”の一連番号（１例として“Ｂ０００１
３５５”）があるかを判定する。前記番号があれば、ス
テップ６０３に進む。前記番号がなければ、利用者から
受信したメールに誤りがあると判断し、ステップ６０９
のエラー返信用メール作成処理に進む（ステップ６０
２）。

【０１５７】“起案メール”の識別ＩＤで一連番号があ
れは、利用者が送付したメールは、起案文書であり、決
裁する要求であると判断し、以下の処理を実施する。ま
ず、文書データベース１１の公用文書属性テーブル１５
の文書Ｎｏ．１５０１を参照し、受信メールから識別し
た前記一連番号に該当するレコードを取得する（ステッ
プ６０３）。

【０１５８】前記の該当レコードがあれば、処理を継続
し、そうでなければステップ６０９のエラー返信用メー
ル作成処理に進む（ステップ６０４）。

【０１５９】“業務メール”のヘッダ情報、本文、添付
ファイルそれぞれから、送信者アドレス、受信者アドレ
ス、送信日を抽出する。さらに、“起案メール”のメー
ル本文中に記述されている起案文書の表紙の情報を、タ
グ等で識別し、件名、分類コード、文書保存年限、コメ
ント欄、といった情報を抽出する。また、添付ファイル
の属性情報を解析し抽出する。（ステップ６０５）。

【０１６０】次に、公用文書属性テーブル１５の前記一
連番号に該当するレコードの作成者１５０２からアドレ
スを取り出し、利用者から受信したメールの宛先を書き
替える（ステップ６０６）。

【０１６１】次に、決裁・承認情報を格納する。決裁文
書属性テーブル１５の決裁日時１５０６に前記抽出した
送信日を格納する。承認情報テーブル１８の文書Ｎｏ．
１８０１に前記一連番号、送信者１８０２に前記抽出し
た送信者アドレス、受信者１８０３に前記抽出した受信
者アドレス、送信日時１８０４に前記受信メールの送信
日、送付状態１８０５に“承認”をそれぞれ格納する
（ステップ６０７）。

【０１６２】あと、決裁文書履歴管理テーブル１６、決
裁経路テーブル１７に受信メールから抽出した情報を格
納する。

【０１６３】決裁文書履歴管理テーブル１６の文書Ｎ
ｏ．１６０１に前記一連番号、送信日時１６０３に前記
受信メールの送信日、メールデータ１６０４に前記受信
メール、添付文書１６０５に前記抽出した添付ファイ
ル、属性１６０６に前記添付ファイルの属性情報をそれ
ぞれ格納する。また、メールＮｏ．１６０２には、前記
一連番号と一致しかつメールＮｏ．１７０２の最新番号
のレコードに格納されている数をそれぞれ１加算し格納
する。履歴１６０７には前記一連番号と一致しかつメー
ルＮｏ．１７０２の最新番号のレコードに格納されてい
る数値を、前記該当レコードに格納されている文書ファ
イルと比較し、変更があれば１加算し格納する。決裁経
路テーブル１７の文書Ｎｏ．１７０１に前記一連番号、
送信日時１７０３に前記受信メールの送信日、送信者１
７０４に前記受信メールの送信者、受信者１７０５に前
記受信メールの受信者、添付文書数１７０７に前記抽出
した添付ファイルの数をそれぞれ格納する。また、メー
ルＮｏ．１７０２、送信回数１７０６には、前記一連番
号と一致しかつメールＮｏ．１７０２の最新番号のレコ
ードに格納されている数をそれぞれ１加算し格納する
（ステップ６０８）。

【０１６４】利用者に前記の登録結果を返信するため、
受信メールのヘッダ情報の送信者と受信者のメールアド
レスを入れ替える（ステップ４１４）。

【０１６５】ステップ６０１、ステップ６０２、ステッ
プ６０４から処理を引き継ぎ、利用者からの受信メール
がエラーであったことを通知する返信メールを作成する
（ステップ４１５）。

【０１６６】前記処理で加工した文書作成者（起案者）
に決裁処理結果を通知するため、メール送信処理を行
う。本処理は、メール受発信手段２１処理に前記電子メ
ールデータを引き渡す。これにより利用者（最終承認
者）は、別の利用者（起案者や案件の関与者）にメール
を送信するのための宛先指定操作や、決裁を承認したこ
とを示す情報をメールに付加する操作の負担を軽減で
き、文書作成者（起案者）は利用者端末Ａ４０の電子メ
ールクライアントで決裁完了の通知を受信することがで
きる（ステップ６０９）。

【０１６７】“文書処理”の４番目のサブ機能として、
“経路中継”処理の１実施例を説明する。

【０１６８】図７は、利用者が“起案メール”を用いて
文書の承認・回覧（“承認”処理）を行う場合、途中の
承認者が次承認者へ電子メールの転送の際、次承認者の
メールアドレスの指定や承認する操作などを省略できる
実施例である。

【０１６９】本処理に至る前に、他の利用者から受信し
た前記の“起案メール”を次の相手（次承認者）に送信
する場合において、以下の操作を行う。図３５の３７０
１に決済用メールの受信状態の例を示す。利用者（承認
者）は利用者端末Ａ４０の入力装置４４を介して電子メ
ールクライアント４１にメールを返信する操作を行う。
図３６に返信メールを操作する例を示す。ここで、文書
作成者（起案者）は、本処理を行うために図３６の３６
０１に示すように“起案メール”に予め決裁の回覧先の
順序を示すメールアドレスのリストを前記メールの本文
に記して送信しているものとする。そして、前記の“起
案メール”は先に説明した“開始”処理で“決裁”処理
を指定する文書サーバ用の宛先（一例としてjidou@h.g
o.jp）が送信先として、利用者に送信される。このた
め、電子メールサーバ１０を介して文書サーバ１０が受
信した前記“業務メール”を、本処理が“業務メール”
の本文にある宛先リスト判断するので、前記のメール返
信の操作で、事前に設定した宛先の利用者（次承認者）
に転送することが実現する。

【０１７０】以下の場合に、本処理を行う。電子メール
サーバ３０を介して文書サーバ１０に届けられたメール
を文書処理アプリケーション２０が処理中であり、図３
の“文書処理”処理（ステップ３０８）において“経路
中継”処理が選択された場合に本処理に移る。

【０１７１】まず、メール受発信手段２１が受信した
“業務メール”である電子メールデータの内容を解析
し、識別情報（識別ＩＤ、一連番号）を抽出する（ステ
ップ７００）。

【０１７２】“業務メール”が“公用メール”が“起案
メール”であるかを識別する識別ＩＤを判定する。識別
ＩＤが“起案メール”のＩＤ（１例としてメール本文中
にある“［決裁］”または添付ファイル）であれば、ス
テップ６０２に進み、“起案メール”でなければ、利用
者から受信したメールに誤りがあると判断し、ステップ
７１２のエラー返信用メール作成処理に進む（ステップ
７０１）。

【０１７３】識別ＩＤが“起案メール”であれば、続い
て“起案メール”の一連番号（１例として“Ｂ０００１
３５５”）があるかを判定する。前記番号があれば、ス
テップ７０３に進む。前記番号がなければ、ステップ７
１２のエラー返信用メール作成処理に進む（ステップ７
０２）。

【０１７４】“起案メール”の識別ＩＤで一連番号があ
れは、次に、文書データベース１１の公用文書属性テー
ブル１５の文書Ｎｏ．１５０１を参照し、受信メールか
ら識別した前記一連番号に該当するレコードを取得する
（ステップ７０３）。

【０１７５】前記の該当レコードがあれば、処理を継続
し、そうでなければステップ７１２のエラー返信用メー
ル作成処理に進む（ステップ７０４）。

【０１７６】次に、“業務メール”の中に決裁の回覧順
路を示すメールＩＤのアドレスのリスト（“経路リス
ト”）が存在するかを判定する。“経路リスト”が存在
（１例として図３６の３６０１に示すメール本文中への
記入や、リストを添付ファイルとして付加）していれ
ば、ステップ７０６に進み、存在しなければ、ステップ
７１３のエラー返信用メール作成処理に進む（ステップ
７０５）。

【０１７７】“起案メール”の識別ＩＤで一連番号と
“経路リスト”があれば、利用者が送付したメールは、
承認を中継して転送する要求であると判断し、以下の処
理を実施する。まず、“業務メール”のヘッダ情報か
ら、送信者アドレスを抽出する。つぎに、本文、添付フ
ァイルそれぞれから、前記“経路リスト”を抽出する
（ステップ７０６）。

【０１７８】そして、前記“経路リスト”の最後のアド
レスと前記抽出した送信者アドレスを比較し、“業務メ
ール”の送信者が決裁の回覧順路のどの場所にいるかを
判定する。“業務メール”の送信者が最終承認者であっ
た場合はステップ７０８に進み、そうでない場合は処理
を継続する（ステップ７０７）。

【０１７９】“業務メール”の送信者が最終承認者であ
った場合は、“決裁”処理に処理を引き渡す。（ステッ
プ７０８）。

【０１８０】“業務メール”のヘッダ情報、本文、添付
ファイルそれぞれから、送信者アドレス、受信者アドレ
ス、送信日を抽出する。さらに、“起案メール”のメー
ル本文中に記述されている起案文書の表紙の情報を、タ
グ等で識別し、件名、分類コード、文書保存年限、コメ
ント欄、といった情報を抽出する。また、添付ファイル
の属性情報を解析し抽出する。さらに、“業務メール”
の送信者が途中の承認者であった場合は以下の処理を続
ける。“経路リスト”における送信者のアドレスの次に
ある送付する相手のアドレス（次承認者）を読み出す。
（ステップ７０９）。

【０１８１】次に、決裁文書履歴管理テーブル１６、決
裁経路テーブル１７に受信メールから抽出した情報を格
納する。決裁文書履歴管理テーブル１６の文書Ｎｏ．１
６０１に前記一連番号、送信日時１６０３に前記受信メ
ールの送信日、メールデータ１６０４に前記受信メー
ル、添付文書１６０５に前記抽出した添付ファイル、属
性１６０６に前記添付ファイルの属性情報をそれぞれ格
納する。また、メールＮｏ．１６０２には、前記一連番
号と一致しかつメールＮｏ．１７０２の最新番号のレコ
ードに格納されている数をそれぞれ１加算し格納する。
履歴１６０７には前記一連番号と一致しかつメールＮ
ｏ．１７０２の最新番号のレコードに格納されている数
値を、前記該当レコードに格納されている文書ファイル
と比較し、変更があれば１加算し格納する。決裁経路テ
ーブル１７の文書Ｎｏ．１７０１に前記一連番号、送信
日時１７０３に前記受信メールの送信日、送信者１７０
４に前記受信メールの送信者、受信者１７０５に前記受
信メールの受信者、添付文書数１７０７に前記抽出した
添付ファイルの数をそれぞれ格納する。また、メールＮ
ｏ．１７０２、送信回数１７０６には、前記一連番号と
一致しかつメールＮｏ．１７０２の最新番号のレコード
に格納されている数をそれぞれ１加算し格納する。承認
情報テーブル１８の文書Ｎｏ．１８０１に前記一連番
号、送信者１８０２に前記抽出した送信者アドレス、受
信者１８０３に前記抽出した受信者アドレス、送信日時
１８０４に前記受信メールの送信日、送付状態１８０５
に“承認”をそれぞれ格納する（ステップ７１０）。

【０１８２】そして、次承認者に送信するが作成する。
利用者から受信したメールの宛先（Ｔｏ：）を“経路リ
スト”から取り出したアドレスに、送信元（Ｆｒｏ
ｍ：）を文書サーバの経路中継処理用アドレス（一例と
してjidou@h.go.jp）に書き替える。（ステップ７１
１）。

【０１８３】また、ステップ７０１、ステップ７０２、
ステップ７０４、ステップ７０５から処理を引き継ぎ、
利用者からの受信メールがエラーであったことを通知す
る返信メールを作成する（ステップ７１２）。

【０１８４】前記処理で加工した文書作成者（起案者）
に決裁処理結果を通知するため、メール送信処理を行
う。本処理は、メール受発信手段２１処理に前記電子メ
ールデータを引き渡す。これにより利用者（承認者）
は、別の利用者（次承認者）にメールを転送するのため
の宛先指定操作や、承認情報をメールに付加する操作の
負担を軽減できる（ステップ７１３）。

【０１８５】最後に、“検索”処理につき詳細に説明す
る。

【０１８６】本実施例では、主に所定の案件（起案）に
ついて承認の状況を確認すること、または過去に受送信
されたメールまたはメール群を参照することにより過去
に作成した文書の再利用や結論に至るまでの経緯を調査
することを目的としている場合を想定している。

【０１８７】図８に、文書検索アプリケーション２２
（図１に記載）に関するフローチャートを示す。

【０１８８】文書検索アプリケーション２２では、まず
始めにステップ８００においてユーザが指定した検索対
象項目について検索条件の取得を行う。

【０１８９】ここで、図３９に入力条件の一例を示す。

【０１９０】本実施例では検索条件の入力画面として、
２種類の検索条件指定領域を検索目的に応じて使い分け
ることを想定している。

【０１９１】すなわち、所定の案件（起案）について承
認状況を確認したい場合には、３９０１に示す領域中に
該当起案の文書番号、分類、件名または作成者の、少な
くとも一項目以上を指定して検索実行ボタン３９０３を
押下する。また、過去に受送信されたメールまたはメー
ル郡を参照することにより過去に作成した文書の再利用
や結論に至るまでの経緯を調査する場合には、３９０２
に示す領域中に送信者、受信者または送信日時の、少な
くとも１項目以上を指定して検索実行ボタン３９０３を
押下する。

【０１９２】つぎに、利用者から入力された検索条件
が、図３９の例で３９０１の条件であればステップ８０
２の起案文書一覧の画面表示に進み、また３９０２のそ
れ以外の条件であればステップ８１４のメール履歴群一
覧の画面表示に進む（ステップ８０１）。

【０１９３】まず始めに、図３９における検索画面にお
いて３９０１の条件が指定された場合、すなわち起案文
書における承認状況確認における検索処理および検索結
果の表示処理の流れについて説明する。

【０１９４】すなわち、図３９における３９０１の領域
中に指定された条件について、図１５に示す決裁文書属
性テーブル１５中の該当項目を参照し、指定された条件
に合致する決裁文書の識別情報（文書Ｎｏ．）を抽出す
る。そして、条件に合致した案件（1案件あるいは複数
案件）を画面に表示する（ステップ８０２）。

【０１９５】この時点の表示例を図４０に示す。つづい
て利用者端末４０より文書の指定を受け付ける（ステッ
プ８０３）。

【０１９６】図４０の例で４００１のレコードが選択さ
れ、４００２が押下されたら、決裁文書属性テーブル１
５、承認情報テーブル１８の該当レコードを参照し、文
書属性情報及び、文書の決裁の承認状態を表示する（ス
テップ８０４）。

【０１９７】図４１に文書管理業務画面の１例を示す。

【０１９８】つぎに、簡易な検索ならばここまでで終了
する可能性もあるため、終了するかを利用者に問い合わ
せ、終了であれば“検索”処理を終了する。終了でなけ
れば、最新の電子文書ファイルの内容表示または履歴検
索に移る（ステップ８０５）。

【０１９９】図４１の例で表示対象文書が選択され、４
００１が押下された場合は、ステップ８０７の最新文書
の画面表示に進み、４００２が押下された場合は、ステ
ップ８０８の履歴文書の検索に進む（ステップ８０
６）。

【０２００】最新文書の画面表示の要求を受け付けた
ら、以下の処理を行う。利用者から指定された該当レコ
ードである決裁文書属性テーブル１５の文書Ｎｏ．１５
０１と対応する決裁文書履歴管理テーブル１６の文書Ｎ
ｏ．１６０１とが一致し、かつレコードでメールＮｏ．
１６０２が最新の添付文書１６０５に格納された電子文
書データを利用者端末Ａ４０の文書作成アプリケーショ
ン４２を介して表示する。図４２に文書の表示例を示
す。図４２の文書表示例では、４２０１が押下された
ら、図４３に戻り、ステップ８１３に進む（ステップ８
０７）。

【０２０１】履歴文書の検索の要求を受け付けたら、以
下の処理を行う。（ステップ８０８）。

【０２０２】利用者から指定された該当レコードである
決裁文書属性テーブル１５の文書Ｎｏ．１５０１と対応
する決裁文書履歴管理テーブル１６の該当レコードを１
件または複数表示する（ステップ８０９）。図４２に文
書版履歴一覧表示画面の１例を示す。これにより、最新
文書の変更されていた推移を把握することができる。

【０２０３】図４３で履歴文書が４３０１のように選択
され、４３０２が押下されたら、履歴文書の表示を行
う。利用者から指定された該当レコードを決裁文書履歴
管理テーブル１６の添付文書１６０５に格納された電子
文書データを利用者端末Ａ４０の文書作成アプリケーシ
ョン４２を介して表示する。図４２の文書表示例では４
２０１が押下されたら、図４３に戻り、ステップ８１３
に進む（ステップ８１０）。

【０２０４】つぎに、図４３の４３０３が押下された
ら、ステップ８１２に進み、そうでなければステップ８
１３に進む。（ステップ８１１）。

【０２０５】履歴文書に対応する履歴メールの表示処理
を行う。前記指定されている該当レコードの決裁文書履
歴管理テーブル１６のメールデータ１６０４を読み出
し、Ｗｅｂブラウザ４３または電子メールクライアント
４１を介して表示する。これにより、過去の履歴文書の
作成時点における経緯、背景を知ることができる。（ス
テップ８１２）。

【０２０６】そして、さらに別の検索を続けずに、ここ
で終了する可能性もあるため、終了するかを利用者に問
い合わせ、終了であれば“検索”処理を終了する。終了
でなければ、ステップ８００の検索条件の入力に進む
（ステップ８１３）。

【０２０７】以上が、図３９における検索画面において
３９０１の条件が指定された場合、すなわち起案文書に
おける承認状況確認における検索処理および検索結果の
表示処理の流れである。

【０２０８】次に、図３９における検索画面において３
９０２の条件が指定された場合、すなわち過去に受送信
されたメールまたはメール郡を参照することにより過去
に作成した文書の再利用や結論に至るまでの経緯調査に
おける検索処理および検索結果の表示処理の流れについ
て説明する。

【０２０９】本ケースでは、図３９における３９０２の
領域中に指定されたメールの属性情報、すなわちメール
の送信日時、送信者、受信者について、図１４における
公用経路テーブル１４の該当項目を参照し、文書Ｎｏ．
が同一のメールについてはこれらを１件の文書とみなし
て指定された条件に合致する文書の識別情報（文書Ｎ
ｏ．）を抽出する。そして、ヒットした文書の文書Ｎ
ｏ．について図１２に示す公用文書属性情報テーブル１
２を参照して該当文書の属性情報を抽出し、ステップ８
１４においてメール送信履歴一覧画面として表示する。

【０２１０】図４４にメール送信履歴一覧画面の１例を
示す。利用者から、図４４の４４０１が指定され、４４
０２が押下されたら、詳細な受送信履歴を表示する該当
案件を取得する。（ステップ８１５）。

【０２１１】つづいて、指定されたレコードの検索キー
である公用文書属性テーブル１２の文書Ｎｏ．１２０
１、決裁文書属性テーブル１５の文書Ｎｏ．１５０１に
対応する決裁経路テーブル１７、公用経路テーブル１
４、（ステップ８１６）。

【０２１２】つぎに、簡易な検索ならばここまでで終了
する可能性もあるため、終了するかを利用者に問い合わ
せ、終了であれば“検索”処理を終了する。終了でなけ
れば、最新の電子文書ファイルの内容表示または履歴検
索に移る（ステップ８１７）。

【０２１３】つぎに、図４４の４４０２が押下された
ら、表示対象とする履歴メールの指定を取得する（ステ
ップ８１８）。

【０２１４】つづいて、履歴メールの表示処理を行う。
前記指定されている該当レコードの公用文書履歴管理テ
ーブル１３のメールデータ１３０４または、決裁文書履
歴管理テーブル１６のメールデータ１６０４から格納し
てある電子メールデータを読み出し、Ｗｅｂブラウザ４
３または電子メールクライアント４１を介して表示する
（ステップ８１９）。図４５にメール送信経路履歴の詳
細画面の１例を示す。図４５の４５０１に示す履歴メー
ルを選択すると、前記履歴メールに添付された電子文書
ファイルが表示される。その一つである４５０２を選択
肢４５０３が押下されたら、ステップ８１０の履歴文書
の表示処理に進み該当する履歴文書を表示する。そうで
なければステップ８１３の終了の問い合わせ処理に進む
（ステップ８２０）。このように、非定型に文書をやり
取りした文書を探し出す場合に、電子メールデータが検
索の手掛かりとして有効な手段となる。

【０２１５】以上説明したように、本実施例による電子
メール情報管理システムによれば、電子メールにより送
受信される文書をそのまま文書データベースとして蓄
積、管理することにより、意思決定の過程を電子的な形
で保存することが可能になる。また、電子メールデータ
や添付の電子文書ファイルといった個々のデータは履歴
の前後関係で整合性を保って管理することができるた
め、意思決定活動の証拠として検索、再利用することが
可能になる。さらに、意思決定の結果として生成した文
書を、そのまま起案、承認、決裁業務に適用することが
可能であり、予算作成時における共同作業や官庁・自治
体の起案、決裁事務における浄書など、過去の経過を重
視する文書の作成と利用の用途、情報公開における開示
対象文書に関する事実と関連文書の遡及などに利用する
ことが可能になる。また、既存の紙文書についても、ス
キャナー等によりイメージデータに変換することによ
り、承認、決裁業務に適用することが可能になる。さら
に、本実施例による電子メール情報管理システムは、起
案、承認、決裁業務のみならず、公的な証明書類や契約
書類などの経過を記録として電子的な形で蓄積、管理す
る用途などにおいても適用可能である。

【０２１６】なお、本実施例において、過去に受送信さ
れたメールまたはメール群を参照することにより過去に
作成した文書の再利用や結論に至るまでの経緯調査にお
ける検索として、公用経路テーブル１４に記載している
項目を対象とする場合について説明した。しかし、図３
９に示す検索用条件入力画面に検索条件の入力領域を追
加することにより、公用文書履歴管理テーブルに格納し
ている項目を検索の条件として追加することも可能であ
る。すなわち、本画面によると、メールの受送信や送信
日時だけではなく、メールの本文として記載されている
図１３におけるメールデータ１３０４、添付文書中のテ
キストデータ１３０５、添付文書に関するファイル名や
ファイルサイズなどの属性値１３０６ならびに添付ファ
イルの修正回数（履歴）１３０７などを指定した高機能
な検索を実現することが可能になる。

【０２１７】また、本実施例においてはメールに添付さ
れた形で受送信される電子データ（添付ファイル）を公
用文書履歴管理テーブル１３中の１項目の情報として登
録する方法について説明した。しかし、添付ファイルの
管理を公用文書履歴管理テーブル１３とは別のテーブル
で管理し、公用文書履歴管理テーブル１３においては添
付ファイルデータへのポインタ情報を管理する形態を採
ることも可能である。本形態による電子メール情報管理
システムでは、複数メール間で同一の添付ファイルを受
送信する場合等に、これらを別々のデータとして登録す
るのではなく共通化することが可能になるため、文書デ
ータベース容量の削減ならびに登録処理性能の高速化な
ど効果を得ることが可能になる。

【０２１８】さらに、本実施例における電子メール情報
管理システムでは、複数の送信者に宛てて送信されたメ
ールを、送信先アドレス毎に別々のメールデータとして
公用文書管理テーブル１３ならびに公用経路テーブル１
４等に登録、蓄積する方式について説明した。しかし、
複数送信者に宛てられたこれらのメールを１件の文書と
して蓄積、管理することも可能である。すなわち、図５
に示す公用および起案文書の登録ステップにおける前処
理として、該当メールに関する情報が既に文書データベ
ースに登録済み、または登録中の状態であるか否かを判
定する。そして、登録済みまたは登録中の状態でないと
判定された場合には、該当メールにおける全ての宛先を
公用経路テーブル１４における送信先１４０４に登録す
る。また、登録済みまたは登録中の状態であると判定さ
れた場合には、該当メールを文書データベースへの登録
対象から除外するすることにより、同一文書の重複登録
を回避することが可能になり、ひいては文書データベー
ス容量の削減ならびに登録処理性能の高速化など効果を
得ることが可能になる。

【０２１９】図４６は本発明の一実施例である第２の実
施例を示す電子メール情報管理システム及びネットワー
クシステムの構成図である。

【０２２０】図１の第１の実施例では、文書サーバ１０
と電子メールサーバ３０の２つのサーバで本発明を実現
していたが、本実施例である第２の実施例では第１の実
施例で説明した機能を１つのサーバで本発明を実現する
１例である。

【０２２１】本実施例のネットワークシステムは文書サ
ーバ１０及び利用者端末Ａ４０と利用者端末Ｂ４０がＬ
ＡＮ、インターネット、公衆回線等のネットワークで接
続されている。

【０２２２】文書サーバ１０は文書データベース１１
と、それを制御する文書処理アプリケーション２０、文
書検索アプリケーション２２及び、電子メールサーバデ
ータベース３１と、それを制御するメールサーバ制御手
段３５により構成される。

【０２２３】本実施例において文書処理アプリケーショ
ン２０は、メールサーバ制御手段３５が制御した電子メ
ールデータを電子メールサーバデータベース３１から取
り出し、文書データベース１１に前記電子メールデータ
を登録及び更新する制御を行う。

【０２２４】図４７は、文書サーバ１０における文書処
理アプリケーション２０が行うメイン処理の実施例であ
る。

【０２２５】メールサーバ制御手段３５が制御を行った
送信メールの中から、管理対象とする“業務メール”を
振り分け、文書処理業務を選択する初期処理である。利
用者が“業務メール”を送る操作を利用者端末Ａ４０の
入力装置４４から受け取り、電子メールクライアント４
１が電子メールサーバ３０のメールサーバ制御手段３５
に電子メールデータを送信する。そして、利用者が送信
した“業務メール”が受信者に届けられるまでに文書サ
ーバ１０で、文書処理アプリケーション２０は、メール
受発信手段２１が受け取った“業務メール”を第１の実
施例で説明した個別の文書処理サブ機能（“開始”“承
認”“決裁”“経路中継”）に処理を振り分けることを
行う。メールサーバ制御手段３５が、ＳＭＴＰテーブル
３４に送信メール受け取りＰＯＰテーブル３２格納する
ことを契機に本処理を行う。

【０２２６】初期段階では、処理要求がきているかどう
かを判定するループを実行している（ステップ４７０
０）。メールサーバ制御手段３５がメールの送信処理が
行われる通知を受け取ると、該当電子メールデータをＳ
ＭＴＰテーブル３４からメールデータ２２０３を読み込
む（ステップ４７０１）。つづいて、電子メールデータ
のヘッダ情報を解析し前記電子メールデータの宛先を判
定する。宛先が特定のシステム用のメールアドレスであ
った場合はステップ４７０３に進み、そうでない場合は
ステップ４７０８に進む（ステップ４７０２）。宛先が
特定のシステム用のメールアドレス（実施例ではTourok
u@h.go.jp、kessai@h.go.jp、jidou@h.go.jp）であった
場合は電子メールデータの宛先が“開始”処理に割り当
てられたメールアドレス（実施例ではTouroku@h.go.j
p）であるかを判定する。前記のアドレス指定であった
場合はステップ４７０４に進み、そうでなかった場合は
ステップ４７０５に進む（ステップ４７０３）。“開
始”処理を示すアドレス指定であった場合は、図１０に
示す受送信がされる電子メールデータであると判断でき
るので、“開始”処理に処理を引き渡す（ステップ４７
０４）。

【０２２７】そうでない場合は、電子メールデータの宛
先が“決裁”処理に割り当てられたメールアドレス（実
施例ではkessai@h.go.jp）であるかを判定する。前記の
アドレス指定であった場合はステップ４７０６に進み、
そうでなかった場合はステップ４７０７に進む（ステッ
プ４７０５）。

【０２２８】“決裁”処理を示すアドレス指定であった
場合は、図１１に示す受送信がされる電子メールデータ
であると判断できるので、“決裁”処理に処理を引き渡
す（ステップ４７０６）。前記のアドレス指定でなかっ
た場合は、“経路中継”処理宛てのメールアドレス（実
施例ではjidou@h.go.jp）であるので、“経路中継”処
理に処理を引き渡す（ステップ４７０７）。

【０２２９】つぎに、電子メールデータの宛先が通常の
利用者のメールアドレスが指定してあった場合は、前記
電子メールデータの内容を解析し文書データベース１１
で管理対象であることを示す（特定の文字列や、添付フ
ァイル等の）識別情報が存在するかを判定する。識別情
報がない場合はステップ４７０１０に進み、そうでない
場合はステップ２０９に進む（ステップ４７０８）。

【０２３０】識別情報がなかった場合は、通常の電子メ
ールとして送信された通常の電子メールデータであるの
で、通常の送信処理を行うためにメールサーバ制御手段
３５に処理を引き渡す（ステップ４７０９）。

【０２３１】識別情報がある場合は、図９に示す受送信
がされる管理対象の電子メールデータであると判断でき
るので、“承認”処理に処理を引き渡す（ステップ４７
１０）。

【０２３２】以上の処理を行うことで、第１の実施例に
比較して、本発明で実現する機能を１台のサーバ装置内
で実現することが可能である。

【０２３３】これまでに示した実施例では、受送信され
る文書を時系列的に格納する方法について述べてきた。
しかし、この方法では、起案文書のように一方向的に処
理されていく場合にはメールの受送信順序からメール間
の接続関係を参照することができるが、複数の相手に対
しメールを送信し、それぞれの相手から別々にメールで
指示を受信するような場合には、メールの接続関係を正
しく参照することができないという問題がある。

【０２３４】そこで、本発明第３の実施例として、図１
における文書処理アプリケーション２０の処理として文
書管理システムが受信したメールに接続するメールの識
別情報を抽出し、これを含めてメールの属性情報として
蓄積、管理することにより、複数の相手に対しメールを
送信するような場合にも、メール間の接続関係の正確な
参照を可能とする文書管理システムについて説明する。

【０２３５】本実施例における公用経路テーブル１４の
構成を図４８に示す。すなわち図１４に示した公用経路
テーブルにおいて接続先メールＮｏ．４８０１を追加し
た構成をとるものである。さらに、本実施例における決
裁経路テーブル１７の構成を図４９に示す。決裁経路テ
ーブルについても、図１７に示した決裁経路テーブルに
おいて接続先メールＮｏ．４９０１を追加した構成をと
るものである。

【０２３６】次に、本実施例における登録処理の概要に
ついて説明する。

【０２３７】本実施例における登録処理では、図５に示
すフローチャートにおけるステップ５０８およびステッ
プ５１５において、メール接続情報の登録処理を実行す
るものである。

【０２３８】以下、メール接続情報の登録処理につい
て、図４８に示す公用経路テーブル１４を対象とする場
合を例に図５０を用いて説明する。

【０２３９】始めに、ステップ５００１において受信し
たメールが該当案件における最初のメールであるか否か
を判定する。

【０２４０】その結果、該当案件に関する最初のメール
であると判定された場合には、該当メールを接続先とす
るメールは存在しないと判断されるため、接続先メール
Ｎｏ．の登録を行うことなく処理を終了する。

【０２４１】また、ステップ５００１における判定の結
果、該当案件に関する最初のメールでないと判定された
場合には、ステップ５００２において該当メールに関す
る接続元メールのメールＮｏ．を抽出する。

【０２４２】そして、ステップ５００３において、ステ
ップ５００２で抽出したメールＮｏ．における接続先Ｎ
ｏ．４８０１として、受け取ったメールに関するメール
Ｎｏ．を設定する。

【０２４３】なお、本実施例ではステップ５００２にお
ける各メールに関する接続元メールのメールＮｏ．を抽
出する方法として、インターネットメールにおいて標準
ヘッダとして定義されているMessage IDを利用すること
を想定している。すなわち、図４８に示す公用経路テー
ブル１４において、インターネットメールにおけるMess
age ID（図４８においては図示していない）との対応を
管理しておく。そして、文書管理システムがメールを受
け取った際に、該当メールに関するヘッダ情報を参照
し、インターネットメールにおいて標準ヘッダとして定
義されているReferencesやIn-Reply-Toなどにおける接
続元メールのMessage IDを抽出する。そして、該当IDに
ついて公用経路テーブル１４におけるMessage ID（図１
４においては図示していない）を参照することにより、
接続元メールのメールＮｏ．を抽出する方法を想定して
いる。

【０２４４】以上が、“公用メール”を対象としたメー
ル接続情報の登録処理の内容である。

【０２４５】なお、決裁メールを対象とした場合につい
ても、図５０に示した処理において、公用経路テーブル
１４ではなく決裁経路テーブル１７を参照することによ
り、同様の処理でメール接続情報の登録を実現すること
が可能である。

【０２４６】以上述べたように、本実施例によると、各
案件について最初のメール（メールＮｏ．が０００１で
あるメール）から公用経路テーブル１４における接続先
Ｎｏ．を順次参照していくことにより、該当案件に関す
る全てのメールの接続情報を参照することが可能にな
る。つまり、ある案件に関する全ての情報の伝達経路を
即座に参照することが可能になる。また、あるメールに
ついて該当メールに対する返信メールを即座に抽出する
ことが可能になる。

【０２４７】なお、本実施例においては、ステップ５０
０２における接続先の抽出方法としてインターネットメ
ールにおけるMessage IDを利用する方法について述べ
た。しかし、本処理は各メールのメールＮｏ．をメール
タイトルないしはメール本文中に書き込む方法によって
も実現可能である。すなわち本実現方法によると、文書
管理システムは受け取ったメールタイトルないしは本文
中に記載されているメールＮｏ．から、接続元となるメ
ールのメールＮｏ．を抽出することが可能になる。こう
して抽出したメールＮｏ．についてステップ５００３を
実行することにより、上述した処理と同様の処理を実現
できることは明らかである。また、添付ファイルなどの
情報中に接続元となるメールのメールＮｏ．を格納する
方法によっても上記処理は実現可能である。

【０２４８】また、本実施例では、公用経路テーブル１
４および決裁経路テーブル１７において接続先Ｎｏ．４
８０１および４９０１を格納することにより、あるメー
ルに関する返信メールを高速に抽出する方法について述
べている。これと同様に、公用経路テーブル１４および
決裁経路テーブル１７において各メールの接続元のメー
ルＮｏ．を格納することにより、各メールの元となるメ
ールを時系列的に遡りながら参照することも可能であ
る。この時の公用経路テーブル１４および決裁経路テー
ブル１７の構成をそれぞれ図５１および図５２に示す。

【０２４９】引き続き、本発明第４の実施例における文
書管理システムについて説明する。

【０２５０】これまでに示した実施例では、検索条件と
してメールそのものに関する属性情報や起案文書に関す
る属性情報を指定する方法について述べてきた。しか
し、この方法ではメールの内容について明確な記憶がな
い場合には、所望の文書を検索できないという問題があ
る。

【０２５１】そこで、本発明第４の実施例として、図１
における文書処理アプリケーション２０の処理として、
文書登録時にメールの受送信に関する挙動を示す情報を
抽出し、格納するステップを設けることにより、あいま
いな記憶を元に所望の文書を検索することを可能にする
文書管理システムについて説明する。

【０２５２】本実施例における公用経路テーブル１４の
構成を図５３に示す。すなわち図５１に示した公用経路
テーブルにおいて往復回数５３０１、往復所用時間５３
０２および送信者数５３０３を追加した構成をとるもの
である。さらに、本実施例における決裁経路テーブル１
７の構成を図５４に示す。決裁経路テーブルについて
も、図５２に示した決裁経路テーブルにおいて往復回数
５４０１、往復所用時間５４０２および送信者数５４０
３を追加した構成をとるものである。

【０２５３】次に、本実施例における登録処理の概要に
ついて説明する。

【０２５４】本実施例では、メール挙動情報の登録処理
について、図５３に示す公用経路テーブル１４を対象と
する場合を例に図５５を用いて説明する。

【０２５５】なお、本実施例における登録処理では、図
５に示すフローチャートにおけるステップ５０８および
ステップ５１５において、メール接続情報の登録処理が
完了した後、すなわち図５０に示した処理ステップが完
了し、図５３における接続先メールＮｏ．４８０１と接
続元メールＮｏ．５１０１の設定が完了していることを
前提としている。この時、メール受送信における挙動を
示す情報として、メールのやり取りの回数を表す往復回
数５３０１、メールを送信してからリプライを受信する
までに要した往復所用時間５３０２および送信者数５３
０３を登録するものである。

【０２５６】まず、ステップ５５０１では、初期化処理
として往復回数５３０１に初期値‘０’を、往復所用時
間に未登録状態であることを表す特殊値 ‘──’を設
定する。

【０２５７】次にステップ５５０２で、文書管理システ
ムが受け取ったメールの宛先人数を計数し、これを送信
者数５３０３として登録する。

【０２５８】そしてステップ５５０３で、受信したメー
ルの送信者１４０４、受信者１４０５および送信日時１
４０３を参照し、これを一時データとして管理してお
く。

【０２５９】さらにステップ５５０４で、受信メールに
おける接続元メールＮｏ．５１０１を参照し、ここで得
た値をメールＮｏ．１４０２として持つメールを、送信
元のメールとして抽出する。

【０２６０】そしてステップ５５０５において、一時保
存している受信メールの送信者が送信元メールにおける
受信者１４０５と一致し、かつ一時保存している受信メ
ールの受信者が送信元メールにおける送信者１４０４と
一致していることを判定することにより、受信メールが
送信元メールの返信メールであるか否かを判定する。

【０２６１】そこで、返信メールと判定されなかった場
合には、受信メールにおける往復回数５３０１および往
復所用時間５３０２に新規に値を登録することなく、初
期値のまま登録処理を完了する。

【０２６２】また、受信メールが送信元メールの返信メ
ールであると判定された場合には、ステップ５５０６で
受信元メールの往復回数が‘０’であるか否かを判定す
ることにより、既に往復メールが存在したか、否かを判
定する。そして、判定結果が‘Ｙｅｓ’の場合、すなわ
ち往復メールが存在しなかったと判定された場合には、
初めての往復が生じたものとしてステップ５５０７にお
いて往復回数に‘１’を設定する。また、判定の結果が
‘Ｎｏ’の場合、すなわち往復メールが存在したと判定
された場合には、ステップ５５０８において送信元メー
ルの往復回数に0.5を加算し、受信メールの往復回数５
３０１を算出、設定する。

【０２６３】最後に、ステップ５５０９において受信メ
ールの送信日時と送信元メールの受信日時の差を取るこ
とにより往復所用時間５３０２を算出、設定する。

【０２６４】以上が、本実施例におけるメール挙動情報
の登録処理の流れである。

【０２６５】次に、本実施例におけるメール挙動情報の
登録処理の具体例について、図５３に従って説明する。

【０２６６】まず始めに、メールＮｏ．１４０１の値が
‘A001000’であり、かつメールＮｏ．が‘0001’のメ
ールを受信する。

【０２６７】この時、ステップ５５０１において、該当
メールの往復回数５３０１と往復所用時間５３０２に、
それぞれ初期値‘０’と未登録状態を表す特殊値‘─
─’を設定する。

【０２６８】次に、ステップ５５０２を実行する。該当
メールは送信者Ａが受信者Ｂに宛てたものであり、宛先
人数は‘１’であるため、該当メールの送信者数５３０
３としては‘１’が設定される。

【０２６９】さらに、ステップ５５０３において受信メ
ールの送信者として‘Ａ’を、受信者として‘Ｂ’を、
送信日時として‘19990802’を抽出する。

【０２７０】この後、ステップ５５０４において接続元
のメールが存在するか否かを判定するが、本メールにお
いては接続元メールＮｏ．５１０１の値が存在しない
（未登録状態を表す‘──’である）ため、本判定の結
果は‘Ｎｏ’となり、本メールに関するメール挙動情報
の登録処理が終了する。

【０２７１】次に、メールＮｏ．１４０１の値が‘A001
000’であり、かつメールＮｏ．が‘0002’のメールを
受信する。

【０２７２】この時、ステップ５５０１、ステップ５５
０２および５５０３において上述した処理と同様の処理
が行われ、往復回数５３０１として‘０’が、往復所用
時間５３０２に‘──’が設定される。また、本メール
は送信者‘Ｂ’が‘Ｈ’と‘Ｊ’の２名に宛てたものな
ので、送信者数５３０３として‘２’が設定される。ま
た、メールの送信者として‘Ｂ’が、受信者として
‘Ｈ’が、送信日時として‘19990803’が抽出される。

【０２７３】この後、ステップ５５０４において接続元
のメールが存在するか否かを判定するが、本メールにお
いては接続元メールＮｏ．５１０１は‘0001’として存
在するため、本判定の結果は‘Ｙｅｓ’となる。

【０２７４】次に、ステップ５５０５において(接続元
メールの受信者＝受信メールの送信者)であり、かつ(接
続元メールの送信者＝受信メールの受信者)であるとい
う条件で、往復メールの判定処理を行う。その結果、接
続元メールの受信者と受信メールの送信者はいずれも
‘Ｂ’で一致するが、接続元メールの送信者‘Ａ’と受
信メールの受信者‘Ｈ’は異なるため、判定の結果は
‘Ｎｏ’となる。この結果、受信メールは送信元メール
に対する返信と判定されないこととなり、往復回数や往
復所用時間を更新することなく、本メールに関するメー
ル挙動情報の登録処理が終了する。

【０２７５】次に、メールＮｏ．１４０１の値が‘A001
000’であり、かつメールＮｏ．が‘0003’のメールを
受信するが、本メールにおいても上記メールと同様にス
テップ５５０５の判定結果が‘Ｎｏ’となるため、ステ
ップ５５０６以降の処理を実行することなくメール挙動
情報の登録処理が終了する。

【０２７６】さらに、メールＮｏ．１４０１の値が‘A0
01000’であり、かつメールＮｏ．が‘0004’のメール
を受信した際の処理について説明する。

【０２７７】ステップ５５０１、ステップ５５０２およ
び５５０３において、上述した処理と同様の処理が行わ
れ、往復回数５３０１として‘０’が、往復所用時間に
５３０２に‘──’が、送信者数５３０３として‘１’
が設定される。また、メールの送信者として‘Ｈ’が、
受信者として‘Ｂ’が、送信日時として‘19990804’が
抽出される。

【０２７８】また、ステップ５５０４における判定処理
において、接続元メールとして‘0002’が存在するた
め、引き続きステップ５５０５が実行される。本判定の
結果、、接続元メールの受信者と受信メールの送信者は
いずれも‘Ｈ’で一致し、かつ接続元メールの送信者と
受信メールの受信者はいずれも‘Ｂ’で一致するため、
判定の結果は‘Ｙｅｓ’となる。この結果、受信メール
は送信元メールの返信メールとして、引き続きステップ
５５０６が実行されることになる。

【０２７９】ステップ５５０６では送信元メールの往復
回数が‘０’であるか否かの判定を行う。送信元メール
に該当する、メールＮｏ．が‘0002’のメールに関する
往復回数の値は‘０’であるため、判定の結果は‘Ｙｅ
ｓ’となる。すなわち、ステップ５５０７が実行される
ことになり、受信メールであるメールＮｏ．が‘0004’
のメールについて往復回数５３０１に‘１’が設定され
ることになる。

【０２８０】そして、ステップ５５０９において受信メ
ールの送信日時‘19990804’と接続元メールの送信日時
‘19990803’の差を取ることにより、往復所用時間とし
て１日、すなわち‘１’が設定されることになる。

【０２８１】以下、同様の処理を全ての受信メールにつ
いて繰り返すことにより、図５３に示す公用経路テーブ
ル１４が生成されることになる。

【０２８２】以上が、本実施例におけるメール挙動情報
登録処理の具体例である。

【０２８３】なお、上述した処理では、図５３に示す公
用経路テーブル１４を更新する場合について、処理の流
れを説明したが、図５４における決裁経路テーブル１７
においても同様の処理により、メール受送信における挙
動情報を条件とした検索用のデータを生成することが可
能である。

【０２８４】さらに、メール受送信における挙動情報を
条件とした検索を実現するための検索条件入力画面例を
図５６に示す。本図における画面は、図３９に示す第１
の実施例における検索条件入力画面において検索条件入
力領域５６０１を付加した構成となる。

【０２８５】検索時には、検索条件入力領域５６０１に
メール往復回数や関与人数、メールの往復時間などのう
ち所定箇所を指定して、検索ボタン３９０３を押下す
る。文書検索アプリケーション２２は公用経路テーブル
１４ないしは決裁経路テーブル１７における該当項目を
参照して、メール受送信における挙動情報について指定
された条件に合致するメールを抽出する。これにより、
例えばＡという検索者が正確にメールの属性情報などを
思い出さなかった場合においても、Ｂという担当者と頻
繁に意見交換を行ったという記憶があったり、なかなか
リプライが帰ってこなかったという条件であったり、多
くのメンバに展開されたメールなどといった、あいまい
な記憶を元に目的とする文書を検索することが可能にな
る。

【０２８６】なお、本実施例において、図５３と図５４
では往復所用時間５３０２、５４０２として年月の情報
を用いる場合について説明したが、送信日時１４０３お
よび１７０３に時間、分や秒などの情報を追加すること
により、さらに細かい単位で時間指定することが可能に
なる。

【０２８７】また、往復回数５３０１、５４０１とし
て、図５５に示した例では連続的にメール交換される場
合の往復回数の算出処理について述べた。これに対し、
メールの接続情報をメールＮｏ．が‘０００１’である
最初のメールまで遡り、往復回数を計数していくことに
より、途中で別担当者へのメール送信を含む延べの往復
回数を条件とした検索を実現することが可能になる。

【０２８８】さらに、本実施例では図５５におけるステ
ップ５５０５では、(接続元メールの受信者＝受信メー
ルの送信者)であり、かつ(接続元メールの送信者＝受信
メールの受信者)であるという条件で、往復メールの判
定処理を行っている。これに対し、本実施例中に示した
メールの送受信情報に加えて、メール受送信者の所属部
署情報を管理するデータを利用することにより、メール
受送信における挙動を部署単位で指定した検索（例え
ば、Ａ課内のメンバがＢ課のメンバと頻繁に意見交換し
た案件の検索など）を実現することが可能になる。

【０２８９】さらに、上述した実施例では主にメールの
往復回数や往復に要した時間、ならびに各メールに関す
る関与人数として送信者数を条件とした検索例について
説明した。しかし、図５５における登録処理をさらに拡
張することにより、関与者数としてある案件に関する延
べの受送信数や展開の経路を指定した検索（例えば担当
者Ａより先に、担当者Ｂに通知が行われた案件の検索）
など、メール受送信における様々な挙動を条件とした検
索に適用することも可能である。

【０２９０】最後に、本実施例では図１に示す通りメー
ルサーバ制御手段３５からメール転送アプリケーション
３６を介して文書処理アプリケーション２０にメールデ
ータが受け渡される場合について、メール受送信におけ
る挙動情報を条件とした検索の実現方式について述べ
た。しかし、図５５に示すメール受送信における挙動情
報の登録処理は、一般のメールサーバやグループウェア
ならびに各クライアントＰＣにおけるメール管理プログ
ラム等に適用可能であり、その場合においても本実施例
と同じくあいまいな記憶を元に所望の文書を検索する上
で有効な手段となり得るものである。

【０２９１】以上説明したように、本発明の電子メール
情報管理方法によれば、意思決定過程の見せたい文書を
電子メールで送るといった操作に連動して利用者は文書
管理に関わるシステムの操作を意識することなく添付文
書とメール履歴の管理が実現できる。また、文書管理対
象とするメールと通常の送受信状態のメールを識別して
利用者のプライバシー性を確保しつつ、管理対象とする
メールをレベル分けして管理することができる。また、
作業者間で文書を受送信した経過や、受送信経過の任意
の途中時点における文書及びその版をみることができ
る。また、電子メールデータと添付の電子文書ファイル
結びつけてメールの送受信の履歴として管理すること
で、意思決定過程の動きを示す情報として蓄積すること
ができる。このため、メールのやり取りの動きを検索条
件の手掛かりとして用いることで案件で作成した文書の
改変の経緯や、意思決定に至るまでの変化及びその背景
となるを示す参考情報（メール、関連文書）を遡って探
し出すことができる。さらに、前記履歴の電子メールデ
ータや添付の電子文書ファイルといった個々のデータは
履歴の前後関係で整合性を保って管理するので意思決定
活動の証拠とすることができる。これらは、予算作成時
における共同作業や、官庁・自治体の起案、決裁事務に
おける浄書など過去の経過を重視する文書の作成と利用
の用途、情報公開における開示対象文書に関する事実と
関連文書を遡及するときの用途、その他、公的な証明書
類や契約書類やそれらをやり取りした経過を記録として
管理する用途などにおいても有効である。

【０２９２】

【発明の効果】本発明によれば、履歴情報を利用した電
子メール情報の管理が実現できる

【図面の簡単な説明】

【図１】本発明の一実施例である第１の実施例における
電子メール情報管理システム及びネットワークシステム
構成を示す図である。

【図２】電子メールサーバ３０におけるメール転送アプ
リケーション３６のメール転送処理を示すフローチャー
トである。

【図３】文書サーバ１０における文書処理アプリケーシ
ョン２０のメイン処理を示すフローチャートである。

【図４】文書処理アプリケーション２０のサブ処理であ
る開始処理を行う処理を示すフローチャートである。

【図５】文書処理アプリケーション２０のサブ処理であ
る決裁処理を行う処理を示すフローチャートである。

【図６】文書処理アプリケーション２０のサブ処理であ
る経路中継処理を行う処理を示すフローチャートであ
る。

【図７】文書処理アプリケーション２０のサブ処理であ
る承認処理を行う処理を示すフローチャートである。

【図８】文書検索アプリケーション２２における検索処
理を示すフローチャートである。

【図９】“承認”処理における“業務メール”の受送信
の概要である。

【図１０】“開始”処理における“業務メール”の受送
信の概要である。

【図１１】“決裁”処理における“業務メール”の受送
信の概要である。

【図１２】文書サーバ１０の文書データベース１１にお
ける公用文書属性テーブル１２のテーブルレイアウトの
一例を示す図である。

【図１３】文書サーバ１０の文書データベース１１にお
ける公用文書履歴管理テーブル１３のテーブルレイアウ
トの一例を示す図である。

【図１４】文書サーバ１０の文書データベース１１にお
ける公用経路テーブル１４のテーブルレイアウトの一例
を示す図である。

【図１５】文書サーバ１０の文書データベース１１にお
ける決裁文書属性テーブル１５のテーブルレイアウトの
一例を示す図である。

【図１６】文書サーバ１０の文書データベース１１にお
ける決裁文書履歴管理テーブル１６のテーブルレイアウ
トの一例を示す図である。

【図１７】文書サーバ１０の文書データベース１１にお
ける決裁経路テーブル１７のテーブルレイアウトの一例
を示す図である。

【図１８】文書サーバ１０の文書データベース１１にお
ける承認情報テーブル１８のテーブルレイアウトの一例
を示す図である。

【図１９】文書サーバ１０の文書データベース１１にお
ける関係管理テーブル１９のテーブルレイアウトの一例
を示す図である。

【図２０】電子メールサーバ３０の電子メールデータベ
ース３１におけるＰＯＰテーブル３２のテーブルレイア
ウトの一例を示す図である。

【図２１】電子メールサーバ３０の電子メールデータベ
ース３１におけるメールＩＤテーブル３３のテーブルレ
イアウトの一例を示す図である。

【図２２】電子メールサーバ３０の電子メールデータベ
ース３１におけるＳＭＴＰテーブル３４のテーブルレイ
アウトの一例を示す図である。

【図２３】利用者端末Ａ４０における電子メールクライ
アント４１によるメール送信画面の一例を示す図であ
る。

【図２４】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図２５】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図２６】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図２７】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図２８】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図２９】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３０】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図３１】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３２】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３３】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図３４】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３５】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図３６】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３７】利用者端末Ａ４０における電子メールクライ
アント４１による送信メール作成画面の一例を示す図で
ある。

【図３８】利用者端末Ａ４０におけるＷｅｂブラウザ４
３による文書管理情報入力画面の一例を示す図である。

【図３９】利用者端末Ａ４０における電子メールクライ
アント４１による受信メール一覧画面の一例を示す図で
ある。

【図４０】利用者端末Ａ４０におけるＷｅｂブラウザ４
３による検索条件入力画面の一例を示す図である。

【図４１】利用者端末Ａ４０における文書作成アプリケ
ーション４２による文書検索結果一覧画面の一例を示す
図である。

【図４２】利用者端末Ａ４０におけるＷｅｂブラウザ４
３による文書管理業務画面の一例を示す図である。

【図４３】利用者端末Ａ４０におけるＷｅｂブラウザ４
３による文書版履歴一覧の一例を示す図である。

【図４４】利用者端末Ａ４０におけるＷｅｂブラウザ４
３によるメール送信履歴一覧画面の一例を示す図であ
る。

【図４５】利用者端末Ａ４０におけるＷｅｂブラウザ４
３によるメール送信経路履歴の詳細画面の一例を示す図
である。

【図４６】本発明の１実施例である第２の実施例におけ
る電子メール情報管理システム及びネットワークシステ
ム構成を示す図である。

【図４７】本発明の第２の実施例における文書サーバ１
０の文書処理アプリケーション２０のメイン処理を示す
フローチャートである。

【図４８】本発明の１実施例である第３の実施例におけ
る文書サーバ１０の文書データベース１１の公用経路テ
ーブル１４のテーブルレイアウトの一例を示す図であ
る。

【図４９】本発明の１実施例である第３の実施例におけ
る文書サーバ１０の文書データベース１１の決裁テーブ
ル１７のテーブルレイアウトの一例を示す図である。

【図５０】本発明の１実施例である第３の実施例ににお
ける図５の文書処理アプリケーション２０のサブ処理で
ある開始処理で行うメール接続情報の登録処理処理を示
すフローチャートである。

【図５１】本発明の１実施例である第３の実施例ににお
ける文書サーバ１０の文書データベース１１の公用経路
テーブル１４のテーブルレイアウトの一例を示す図であ
る。

【図５２】本発明の１実施例である第３の実施例ににお
ける文書サーバ１０の文書データベース１１の決裁経路
テーブル１７のテーブルレイアウトの一例を示す図であ
る。

【図５３】本発明の１実施例である第４の実施例ににお
ける文書サーバ１０の文書データベース１１の公用経路
テーブル１４のテーブルレイアウトの一例を示す図であ
る。

【図５４】本発明の１実施例である第４の実施例ににお
ける文書サーバ１０の文書データベース１１の決裁経路
テーブル１７のテーブルレイアウトの一例を示す図であ
る。

【図５５】本発明の１実施例である第４の実施例におけ
る文書サーバ１０文書検索アプリケーション２２の処理
を示すフローチャートである。

【図５６】本発明の第４の実施例の利用者端末Ａ４０に
おけるＷｅｂブラウザ４３による検索条件入力画面の一
例を示す図である。

【符号の説明】

１０文書サーバ， １１公用文書属性データベース， １２公用文書テーブル， １３公用文書履歴管理テーブル， １４公用経路テーブル， １５決裁文書属性テーブル， １６決裁文書履歴管理テーブル， １７決裁経路テーブル， １８承認情報テーブル， １９関係管理テーブル， ２０文書管理アプリケーション， ２１メール受発信手段， ２２文書検索アプリケーション， ３０電子メールサーバ， ３１電子メールデータベース， ３２ＰＯＰテーブル， ３３メールＩＤテーブル， ３４ＳＭＴＰテーブル， ３５メールサーバ制御手段， ３６メール転送アプリケーション， ４０利用者端末Ａ， ４１電子メールクライアント， ４２文書作成アプリケーション， ４３Ｗｅｂブラウザ，４４入力装置， ５０利用者端末Ｂ， ６０ＬＡＮ、インターネット、公衆回線

───────────────────────────────────────────────────── フロントページの続き (72)発明者 木下 照己 東京都江東区新砂一丁目６番27号 株式会 社日立製作所公共情報事業部内 (72)発明者 多田 勝己 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所システム開発本部内 (72)発明者 鍵政 秀子 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所システム開発本部内 Ｆターム(参考） 5B075 PR03 5B089 GA21 GB02 GB04 HA10 JA31 KA03 KA13 KB06 LA08 LB14 5K030 HA06 LD17 LE12

Claims (8)

【特許請求の範囲】
1. 【請求項１】利用者宛てに電子メールが着信した際に、
   着信元アドレスに対応して決まる特定のアドレスにメー
   ルを転送するメール転送ステップと、前記メール転送ス
   テップによって転送されたメールが着信した際に、該メ
   ールに含まれる識別情報を基いて管理対象メールを判別
   する管理対象メール判別ステップと、前記管理対象メー
   ル判別ステップによって判別された管理対象メールを文
   書データベースの所定の格納場所に登録する管理対象メ
   ール登録ステップとを備えたことを特徴とする電子メー
   ル情報管理方法。
2. 【請求項２】前記管理対象メール判別ステップは、管理
   対象メールの宛先に特定のアドレスが含まれていた場
   合、または、前記管理対象メールの内部に特定の識別情
   報が含まれていた場合に、該メールを管理対象メールと
   判別することを特徴とする請求項１記載の電子メール情
   報管理方法。
3. 【請求項３】前記管理対象メール登録ステップは、前記
   管理対象メールの内容中に含まれる識別情報から該メー
   ルを登録すべき管理単位を判別し、該管理単位が存在し
   ない場合には該管理単位を生成した後、前記管理対象メ
   ールを該メールの挙動に関する情報を付加して、対応す
   る該管理単位に登録することを特徴とする請求項１記載
   の電子メール情報管理方法。
4. 【請求項４】前記管理対象メール登録ステップにおい
   て、前記管理対象メールに付加する挙動情報に関する情
   報には、該メールに関わる前記管理単位内におけるメー
   ルの送信回数、該メールに先行するメールの送信から該
   メールの送信までに至る時間間隔、および該メールの宛
   先数のうち、少なくとも１個以上を含むことを特徴とす
   る請求項３記載の電子メール情報管理方法。
5. 【請求項５】予め文書データベース中に登録したメール
   が保持する情報、１件以上の前記メールに対して予め作
   成した管理単位が保持する情報ならびに前記管理単位内
   に格納されたメールの挙動に関する情報のうち、少なく
   とも１つ以上の情報を含む検索条件について、前記文書
   データベースを参照し、該検索条件に適合するメールを
   検索するメール検索ステップと、 前記メール検索ステップにおいて検出したメールの一部
   ないしは全部について、前記文書データベースから該メ
   ールに関する一部ないしは全部の情報を抽出し、表示す
   るメール情報表示ステップとを有することを特徴とする
   電子メール情報管理方法。
6. 【請求項６】検索条件に適合するメールを文書データベ
   ース中から検索する際に、検索条件に含まれるメールの
   挙動を示す情報として、検索対象メールに関連して前記
   管理単位内に登録されているメール数の、該検索対象メ
   ールに先行するメールの送信から該検索対象メールの送
   信までに至る時間間隔、および該メールの宛先数のう
   ち、少なくとも１個以上の情報を含むことを特徴とする
   請求項５記載の電子メール情報管理方法。
7. 【請求項７】請求項５記載の電子メール情報管理方法に
   おけるメール情報表示ステップにおいて、 表示対象となるメールを、前記管理単位毎にグルーピン
   グして表示することを特徴とする電子メール情報管理方
   法。
8. 【請求項８】利用者宛てに電子メールが着信した際に、
   着信元アドレスに対応して決まる特定のアドレスにメー
   ルを転送するメール転送手段と、 前記メール転送ステップによって転送されたメールが着
   信した際に、該メールに含まれる識別情報を基いて管理
   対象メールを判別する管理対象メール判別手段と、 前記管理対象メール判別ステップによって判別された管
   理対象メールを文書データベースの所定の格納場所に登
   録する管理対象メール登録手段とを備えたことを特徴と
   する電子メール情報管理装置。