JPH0233245A - 電子メール追従システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、情報処理システム、特に電子メール・システ
ムに関する。

Ｂ、従来技術 ディジタル・ネットワークを介する通信は、かなり速い
速度で広がっている。言い換えれば、このネットワーク
に接続されたユーザは電子メールを介して多数のファイ
ルを交換し、それらのファイルの大部分とは言わないま
でも一部分は処置を必要とするものである。

明らかなことながら、電子メールの出現により、個人レ
ベルや部門レベルでもまた組織レベルでも交換ファイル
の入来フローに対応することがますます難しくなってき
ている。従来のように各ファイルを印刷して処理せずに
、自分の作業／活動スケジュールを編成することが、ユ
ーザにとって現実に問題になってきた。旧来のようにフ
ァイルを印刷して処理するのは、電子メールにとって効
率の悪いやり方であり、現在の設備では、時代遅れな作
業のスケジュール編成方式に固執する訳にはいかない。

Ｃ０発明が解決しようとする問題点 本発明は、電子メール追従の問題を対象とするもので、
電子メールを追跡しスケジューリングし、広い意味で処
理するため、個人レベルならびに部門レベルでこうした
問題に対する効率のよい解決策を提供する。

さらに具体的に述べると、本発明は、受信または送信さ
れたメール、講じるべき処置、講じられた処置、処置の
目標日、及びメール処理にとって重要な他のいくつかの
項目に受信者または発信者の注意が自動的に向けられる
ようにする、メールに自動的に追従するためのシステム
を対象とする。

本発明はまた、同じ電子メール・システムに接続された
予め定義されたユーザのグループ（部門）内で、メール
処理の委託、別の個人による処理すべきメールの追跡、
統計処理の自動的実行、管理レベルへの報告などを可能
とする、より精巧なメール追従用の改良されたシステム
を対象とする。

言い換えれば、本発明は、調整手段及びグループ管理手
段を付加することにより、個人ユーザ単位で独立にだけ
でなく、複雑なグループ単位でも電子メールを処理する
手段を提供する。

Ｄ１問題点を解決するための手段 処理を開始し、ネットワークに接続された端末キーボー
ドを使って、互いにデータをメールするためのハードウ
ェア機能及びソフトウェア機能を共用するための手段と
記憶域を備えた仮想計算機がユーザに個別に割り当てら
れる、データ処理・伝送ディジタル・ネットワークにお
いて、選択されたメール項目を監視し処理するためのメ
ール追従システムが提供される。上記システムは、予め
定義したフィールドを含むメール・タグを生成する手段
、メールを追跡してそれからメール特性データを引き出
す手段、上記特性データをタグ・フィールドに記憶する
手段、記入済みのタグをファイルに記憶し、予め定義し
たメール・フィールドにアクセスし処理する手段を含み
、処理済みのタグは異なるタグ・ファイルに自動的に転
送される。上記システムはさらに、タグ付きメールを部
門別に集中管理する管理手段を含む。

Ｅ、実施例 第１図に、アプリケーション資源と通信資源の両方を含
むディジタル・ネットワーク・メートを示す。端末装置
Ｔ１、Ｔ２、たとえばＩ　８Ｍ３２７Ｘまたは３１７Ｘ
などの知能的表示装置が、直接に、あるいは集積装置ま
たは通信制御装置（１８Ｍ３７２５）または遠隔端末用
ＰＢＸを介して、上位計算機（ＩＢＭ３０３３）に接続
されている。

類似のいくつかのノードが接続されてディジタル・ネッ
トワークになり、したがって数千台の端末装置がネット
ワークに接続される。どの端末にいるユーザも、ネット
ワーク・ソフトウェア資源を用いて選択されたタスクを
実行し、簡単なキーボード操作で互いに意のままに昼夜
を問わず通信することができる。

上位計算機を含むシステムがＶＭ／ＳＰ環境で稼働して
いるものと仮定する。各エンド・ユーザにはネットワー
クの所与のノードにある計算機システム内で仮想計算機
が割り当てられる。仮想計算機とは、実際には、所淀の
サイズの記憶位置、及び共通の計算機ハードウェアや資
源を共用するための許可を意味し、基本的にＩＢＭ制御
プログラム（ＣＰ）及び対話型監視システム（ＣＭＳ）
を含み、それぞれ独自のタイプのサービスを備えている
。ＣＰはシステム資源を管理し、システムを使用する各
ユーザに個別の作業環境を提供する。

ＣＰによって管理される資源には、プロセッサの諸機能
、すなわちプロセッサ記憶域及び入出力装置が含まれる
。ＣＰはシステム作業環境を生成し、作業セラシロン中
にユーザが利用できるシステム資源を制御する。

ＣＭＳは、ＶＭ／ＳＰオペレーティング・システムの構
成要素ではあるが、それ自体がＣＰのもとで走行するオ
ペレーティング・システムである。

「対話型」という名前かられかるように、システム・ユ
ーザとＣＭＳの間で両方向通信が行なわれる。

ＩＢＭ　　ＣＰ及びＣＭＳに関する詳細については、下
記のＩＢＭ文書を参照されたい。

仮想計算機／システム・プロダクト二ＣＭＳコマンド及
びマクロ解説書（Ｖｉｒｔｕａ１Ｍａｃｈｉｎｅ／Ｓｙ
ｓｔｅｍ　Ｐｒｏｄｕｃｔ　：　ＣＭＳ　Ｃｏｍｍａｎ
ｄａｎｄ　Ｍａｃｒｏ　　Ｒｅｆｅｒｅｎｃｅ）、５Ｃ
１９−６２０９゜仮想計算機／システム・プロダクト二
ＣＭＳユーザの手引き（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎ
ｅ／Ｓｙｓｔｅｍ　Ｐｒｏｄｕｃｔ　：　ＣＭＳ　ＵＳ
ＥＲ’Ｓ　Ｇｕｉｄｅ）。

５Ｃ１９−６２１０゜ 仮想計算機／システム・プロダクトニ一般ユーザ向けＣ
Ｐコマンド解説書（Ｖｉｒｔｕａ１Ｍａｃｈｉｎｅ／Ｓ
ｙｓｔｅｍ　Ｐｒｏｄｕｃｔ　：　ＣＰ　Ｃｏｍｍａｎ
ｄＲｅｆｅｒｅｎｃｅ　ｆｏｒ　Ｇｅｎｅｒａｌ　１Ｊ
ｓｅｒｓ）、　５Ｃ１９−６２１１゜ 仮想計算機／システム・プロダクト：システム・プロダ
クト編集プログラム、ユーザの手引き（Ｖｉｒｔｕａｌ
　）４ａｃｈｉｎｅ／ＳｙｓｔｅｍＰｒｏｄｕｃｔ　：
　Ｓｙｓｔｅｍ　Ｐｒｏｄｕｃｔ　Ｅｄｉｔｏｒ　Ｕｓ
ｅｒ’５Ｇｕｉｄｅ）、　５Ｃ２４−５２２０゜仮想計
算機／システム・プロダクト：システム・プロダクト編
集プログラム、コマンド及びマクロ解説書（Ｖｉｒｔｕ
ａｌ　Ｍａｃｈｉｎｅ／Ｓｙｓｔｅｍ　Ｐｒｏｄｕｃｔ
　：　Ｓｙｓｔｅｍ　Ｐｒｏｄｕｃｔ　ＥｄｉｔｏｒＣ
ｏｍｍａｎｄ　ａｎｄ　Ｍａｃｒｏ　Ｒｅｆｅｒｅｎｃ
ｅ）、　５Ｃ２４−５２２１゜ 仮想計算機／システム・プロダクト：システム・プロダ
クト解釈プログラム、ユーザの手引き（Ｖｉｒｔｕａｌ
　Ｍａｃｈｉｎｅ／ＳｙｓｔｅｍＰｒｏｄｕｃｔ　：　
５ｙｓｔｅＩＩＩＰｒｏｄｕｃｔ　Ｉｎｔｅｒｐｒｅｔ
ｅｒＵｓｅｒ’ｓ　Ｇｕｉｄｅ）、　５Ｃ２４−５２３
８゜仮想計算機／システム・プロダクト：システム・プ
ロダクト解釈プログラム解説書（Ｖｉｒｔｕａｌ　Ｍａ
ｃｈｉｎｅ／Ｓｙｓｔｅｍ　Ｐｒｏｄｕｃｔ　：Ｓｙｓ
ｔｅｍ　Ｐｒｏｄｕｃｔ　Ｉｎｔｅｒｐｒｅｔｅｒ　Ｒ
ｅｆｅｒｅｎｃｅ）。

５Ｃ２４−５２３９゜ 文書作成機能−汎用マークアップ言語入門：スタータ・
セットの使用法（ＤｏｃｕｍｅｎｔＣｏｍｐｏｓｉｔｉ
ｏｎ　Ｆａｃｉｌｉｔｙ　−Ｉｎｔｒｏｄｕｃｔｉｏｎ
　ｔ。

ｔｈｅ　Ｇｅｎｅｒａｌｉｚｅｄ　Ｍａｒｋｕｐ　Ｌａ
ｎｇｕａｇｅ　：Ｕｓｉｎｇ　ｔｈｅ　５ｔａｒｔｅｒ
　５ｅｔ）、　５Ｈ２０−９１８６゜第２図に示すよう
に、ユーザはネットワークに接続された任意の端末装置
を使ってセッシジンを開始し、ログオン手順によって自
分のマシンにアクセスすることができる。ログオンとは
、０２機能にアクセスするため割込みコマンドをキーボ
ードから入力し、自分の識別コード（ｕｓｅｒｉｄ）と
、大抵の場合はパスワードとをタイプして自分をシステ
ムに対して識別することを意味する。その後、０ＭＳ資
源または他の任意のソフトウェア資源（たとえば、ＩＢ
Ｍ　　ＰＲＯＦＳアプリケーション・プログラム）に、
要求に応じてまたは直接にアクセスすることができる。

これは、特定のユーザが自分のマシンを最初に定義する
ときにそのユーザに割り当てられる利用可能資源（すな
わち利用可能モード）を識別するように調整された、ユ
ーザのＰＲＯＦＩＬＥ　　ＥＸＥＣルーチンで定義され
る。ＰＲＯＦＳに関する詳細については、下記のＩＢＭ
文書を参照されたい。

プロフェッショナル・オフィス・システムの起動（Ｇｅ
ｔｔｉｎｇ　５ｔａｒｔｅｄ　ｗｉｔｈ　ｔｈｅＰｒｏ
ｆｅｓｓｉｏｎａｌ　０ｆｆｉｃｅ　Ｓｙｓｔｅｍ）、
（資料番号プロフェッショナル・オフィス−システムの
使用法（Ｕｓｉｎｇ　ｔｈｅ　Ｐｒｏｆｅｓｓｉｏｎａ
ｌ０ｆｆｉｃｅ　Ｓｙｓｔｅｍ）、（資料番号　Ｓｌ＋
２Ｏ−５６０４）　。

ＰＲＯＦＳ早見表（Ｑｕｉｃｋ　Ｒｅｆｅｒｅｎｃｅ　
ｔ。

ＰＲＯＦＳ）、（資料番号　ＧＸ２０−２４０８）ＰＲ
ＯＦＳ　　ライン・モード・サポートの使用法（口ｓｉ
ｎｇ　Ｌｉｎｅ−Ｍｏｄｅ　５ｕｐｐｏｒｔ　ｗｉｔｈ
ＰＲＯＦＳ）、（資料番号　５Ｈ２０−５６０７）プロ
フェッショナル・オフィス・システム、プログラマ−の
手引き（Ｐｒｏｇｒａｍｍｅｒ’５Ｇｕｉｄｅ　ｔｏ　
ｔｈｅ　Ｐｒｏｆｅｓｓｉｏｎａｌ　０ｆｆｉｃｅ）１
（資料番号５Ｈ２０−５６０６） 本発明のメール追従システムは、送信メールにも受信メ
ールにも適用されるが、以下では特に受信メールに関し
て説明する。大部分のユーザがアクセスできる資源の一
つは、ファイル識別（ファイル名）をつけたテキスト・
ファイルを作成して、それぞれのユーザに割り当てられ
た記憶セクションまたは数人のユーザが共用する中央記
憶位置に記憶するためのテキスト処理ソフトウェアであ
る。

あるユーザ（Ｕ１）がファイル名（Ｘ）のファイルを別
のユーザ（Ｕ２）に送るとき、Ｕｌはメール資源にアク
セスしなければならない。次いで、システムのメール機
能がファイル（Ｘ）に経路指定データを付加して、上記
ファイルをＵ２に向けて送る。Ｕ２が受信したファイル
は、まずそのユーザのマシン中でＵ２に割り当てられた
バッファ（読取機構）に記憶される。Ｕ２が上記ファイ
ルにアクセスしてそれを処理する方式はいくつかある。

そのファイルを表示して消すか、記憶するかである。後
者の場合、ファイルはＵ２に割り当てられたディスク位
置に記憶される。ユーザに割り当てられた上記のディス
ク位置をそのユーザの（ミニ）ディスクＡと呼ぶ。後で
説明するように、着信メールは名前つきメール記録にフ
ァイルされる。このメール記録は、ディスクＡの内容を
ユーザが定義した主題別に分類するためのものである。

これは、指定された引出しに収納することに似ている。

ファイル処理中に、処理時間に基づくメール記録の分類
が可能となるように操作時間が記録される。ＩＢＭ　　
ＣＭＳまたはＰＲＯＦＳソフトウェア機能を使用する場
合、メール記録の内容を最終処理時間別に分類して表示
するために、ＦＩＬＥＬ　Ｉ　ＳＴというコマンドを呼
び出す。本発明では、メール追従操作の速度を上げ簡単
にするために、このコマンドを使用する。

以下に開示するように、各ユーザに追加のソフトウェア
機能を与えることにより、追従システムがもたらされる
。

自明のことであるが、追従すべきメールは、消されたメ
ールや、まだ読取機構内に緩衝記憶されているメールで
あってはならない。そのために、本発明では、読取機構
のバッファから記憶ディスクＡまたは中央記憶装置に転
送されたデータについて、メール追跡が行なわれる。ま
た追跡は、任意のタイプの受信（または送信）ファイル
についても、特定のタイプのファイル、すなわちＶＭフ
ァイル及びいわゆるＰＲＯＦＳの注釈及び文書について
も行なえるが、特定のタイプのファイルについて行なう
ことがより好ましい。

第３図は、着信メールを処理するために使用される追従
機構の概略図である。図に示されているように、選択さ
れたメール項目（すなわち、この実施例ではＶＭファイ
ルとＰＲＯＦＳの注釈及び文書）が、そのユーザのマシ
ンの読取機構（バッファ）からそのユーザに割り当てら
れたディスクＡと呼ばれる記憶域に転送される間に監視
される。

繰り返す必要もないが、以下の説明で開示される本発明
の範囲から逸脱せずに、本発明を他のタイプのファイル
に拡張することもできる。

本明細書で説明するシステムは、読取機構から転送され
る選択された各ファイルに自動的にタグを割り当てる。

こうした最初のタグは、最初の記憶手段すなわち「未割
当てメール」ファイル中にファイルされる。そこからメ
ール・タグをユーザが処理して、「未応答メール」ファ
イルに転送することができる。未応答メールは、そのユ
ーザが処理することもでき、また指定された管理者から
委任された他のユーザに割り当てることもできる。

後で詳しく示すが、管理者は何人かのユーザを管理し、
あるユーザのグループに共通のマシンを処理することが
できる。たとえば、管理者は自分のマシン内の特別な記
憶セクションを利用でき、読取り／書込みのためにその
セクションにアクセスでき、そのグループ中の残りのユ
ーザは読取りのためだけ管理者の記憶域にアクセスでき
る（リンクされている）。また管理者は、追従システム
用のユーザのプログラムを導入し、（テーブルにリスト
された）ユーザ・グループをサブグループに配列し、秘
書指定や動作「閾値」　（後で定義する）などの作業用
パラメータを設定する仕事を割り当てられることがある
。続いて、応答済みメール・タグまたはその一部分が「
応答済みメール」ファイルに転送され、そこからユーザ
のファイル（ノート記録、メール記録など）に、または
グループ・マネージャに報告すべく、監視及びグループ
活動記録の目的でグループ秘書のマシンに転送される。

言い換えれば、このシステムは独立して稼働する、すな
わち各ユーザのメールを個別に監視し追従するだけでな
く、グループ単位でも稼働し、したがって追加のグルー
プ処理機能を提供する。言うまでもないが、管理者、秘
書及びマネージャもメール追従システムの単なるユーザ
と見なすことができる。また、管理者、秘書及びマネー
ジャの制御は任意である。

第４図に簡略化したメール追従の流れを示す。

ＰＦの番号は、ユーザが表示（またはタスク）を切り換
えるために押す端末キーボードの機能キーを示す。

以下に、本システムによって受信メールに割り当てられ
るタグのサンプルを示す。

上記のタグには、メールを識別し適切ナメ−／Ｌ／処理
を実行するための特定の項目または特性データが含めで
ある。タグは、たとえば次のものを含む。

文書番号（ＤＯＣＮＢＲ）：年と日の数字（たとえば８
８１５７は８６年の１５７日目を表わす）、ユーザまた
はそのユーザにサービスするシステムを識別するユーザ
簡略記憶コード、最後に順序番号たとえば０１９２（後
で説明する）を含む。

注意：ＩＢＭ　　ＰＲＯＦＳシステムを使用する場合、
要求した形式の文書番号が既に用意されている。

受信口（ＲＣＶ　　ＤＡＴＥ）：メールを受イ言した臼 発信元ＣＦＲＯＭ）：発信者を識別する主題（ＳＵＢＪ
ＥＣＴ）：主題を示す。発信者がメールを作成中に久方
した情報に応じてシステムによって自動的に与えられる
。

目標日（ＴＧＴ　　ＤＡＴＥ）：応答目標日。

当初、このタグ・フィールド−はＹＹ　　ＭＭＤＤとな
っており、年月日にそれぞれ２桁が留保されている。ユ
ーザがこれらのフィールドに入力する。

上記の定義から明らかなように、これらのデータにはメ
ール自体から導き出されるものもあり、追従システムに
よって生成されるものもある。

上記のフィールドは、文書番号と受信口以外、すべて修
正可能である。

また、実用上、特定の強調表示やカラー着色を用いて、
修正可能フィールドと修正不能フィールドを区別するこ
とができる。

第５図には、システムの起動のしかたを示す流れ図が示
されている。図に示すように、メール追従は、ユーザが
そのＶＭシステム・アプリケーションにログオンした後
で自動的に分岐して追従ルーチンを開始させる命令（Ｅ
ＸＥＣＭＡＩＬＦＲ８Ｔ）をユーザのＰＲＯＦＩＬＥ　
　ＥＸＥＣに挿入して、自動的に開始させることもでき
、また０ＭＳモードでユーザが特定のコマンド（ＭＡ　
Ｉ　ＬＲＯＵＴ）をタイプして、要求に応じて開始させ
ることもできる。時間の浪費を避けるため、タグの自動
表示と追従処理に対する自動アクセスは、予め選定した
頻度、たとえば１日１回に制限される。そのために、各
ユーザのログオフ時または追従処理から出る際に、日時
が汎用カウンタに記憶される（＄ＧＥＮＣＴＲ＄　　＄
ＦＬＵＰｍａ＄ファイルが他のファイルと同じくユーザ
の割り当てられた記憶域に記憶される）。現在の日付が
汎用カウンタに記憶されている日付に等しい場合、ルー
チンはＰＲＯＦＩＬＥ　　ＥＸＥＣに戻り、このプログ
ラムの実行が続行される。言い換えれば、メール追従ア
プリケーションから出る。そうでない場合は、ＭＡＩＬ
ＲＯＵＴに進み、プログラムの主経路機能を実行する。

したがって、このシステムは、連続する２つの追従セラ
シロンの間で受信（または送信）メールを検出する手段
を設ける必要がある。探索時間を減らすために、最後の
セッシシン以降に更新されたファイルだけが走査される
。この目的のため、プログラムは、ＦＩＬＥＬＩＳＴコ
マンドヲ用いて、ユーザの記憶済みファイルを更新日ご
とに分類する。ファイル”＄ＧＥＮＣＴＲ＄　　＄ＦＬ
ＵＰｍａ＄は最後に更新されたファイルなので、ログオ
フ時にファイルリストの一番上にある。すなわち、メー
ルを受信または送信すると、メール・ログがファイルリ
スト中の＄ＧＥＮＣＴＲ＄＄ＦＬＵＰｍａ＄の一番上に
くる。そうすると、次の追従プログラムの走行時には、
システムは、＄ＧＥＮＣＴＲ＄　　＄ＦＬＵＰｍａ＄の
一番上にあるそうしたログを走査するだけでよい。この
ことを第６図に示す。第６ａ図は、最初の追従セッシσ
ンの終了時のファイルリストの表示を示す。

それ４ｍは、ＴＯＴＯＮＥＴＬＯＧｌＮＯＴＥＯＦＳＬ
ＯＧｆｌ、Ｎ０ＴＥＢＯＯＫ　　ＡＬＬ１＄ＧＥＮＣＴ
Ｒ＄　　＄ＦＬＵＰｍａ＄などの名前のついたいくつか
のログが含まれており、＄ＧＥＮＣＴＲ＄　　＄ＦＬＵ
Ｐｍａ＄がファイルリストの一番上にある。次に、ネッ
トワークが稼働し、メールが最初にログＮ０ＴＥＢＯＯ
Ｋ　　ＡＬＬに記憶されるものと仮定すると、ログＴＯ
ＴＯＮＥＴＬＯＧ中では、追従プログラムを実行せずと
も、第６ｂ図に示すように当該のログがファイルリスト
中に現われる。自動的に（翌日）またはユーザの要求で
（端末キーボードからコマンドＭＡＩＬＲＯＵＴをタイ
プして）追従プログラムが実行されると、第６ｃ図に示
すように、すなわち、ファイルリストの一番上に＄ＧＥ
ＮＣＴＲ＄　　＄ＦＬＵＰｍａ＄がある状態でファイル
リストが終了する。

第７図に、主経路プログラム（ＭＡＩＬＲＯＵＴ　　Ｅ
ＸＥＣ）の流れ図を示す。このプログラムは、次の３つ
の主ルーチンを順次呼び出す。

−ＭＡＩＬ　　ＲＥＣＰ１新しい着信メールにタグを付
ける。

−ＭＡＩＬ　　ＡＳＳＧｌ　ｒ未割当て」画面を管理す
る。

−ＭＡＩＬＡＮＳＷ１　ｒ未応答」画面を管理する。

メール・ファイルに付加される各タグには、収約な参照
番号（第４図のＤＯＣＮＢＲ参照）が割り当てられる。

後で開示するようにグループ・モードで動かすときは特
に、この−要件が重要である。文書番号のフォーマット
は次の通りである。：ＹＹＤＤＤＭＮＥＳＳＳＳ。

ただし、ＹＹ＝年、ＤＤＤ＝年初からの日数、ＭＮＥ＝
３桁の簡略記憶コード、５ｓｓｓ＝順序番号。

独立モードの省略時簡略記憶コードは次の通りである。

ｖＭファイルの場合、　　ＭＮＥ＝ＶＭＦＶＭ／−）ｆ
７）場合、　　　ＭＮＥ＝ＶＭＮＰＲＯＦＳノートの場
合、ＭＮＥ＝ＰＦＮＰＲＯＦＳ文書の場合、　ＭＮＥ＝
ＰＦＤ最後の順序番号は、ファイルまたはタグ・カウン
タ＄＄ＣＮＴＲ＄＄　　＄ＦＬＵＰｍａ＄中で維持され
る。文書番号の一義性を保持するには、この順序番号を
喪失してはならない。したがって、このファイルが偶然
に消失した場合、最後の順序番号でファイルを再構築す
るために回復手順に入る。最初に使用する際も、新しい
エンド・ユーザが追従システムに接続されて、同様の手
順ＣＡＬＬ　　ＭＡＩＬＩＮＩＴが開始される。

ＭＡＩ　ＬＲＯＵＴ上での上記動作を、第７図の流れ図
に示す。第７図で、システムはまず、タグ・カウンタ・
ファイル＄＄ＣＮＴＲ＄＄　　＄ＦＬＵＰｍａ＄の育無
の検査から始める。このカウンタが存在しない場合は、
ＣＡＬＬ　　ＭＡＩＬＩＮＩＴルーチンに入って、タグ
・カウンタが失われた場合はそれを回復し、そうでない
場合は初期使用をセットアツプする。その後にＭＡ　Ｉ
　ＬＲＯＵＴＥＸＥＣに戻る。ルーチンＭＡＩＬＩＮＩ
Ｔ（第８図参照）は、タグ・カウンタが存在しないとき
に呼び出され、それが偶然に失われた場合はそれを回復
し、そうでない場合は追従システムの初期使用時に既存
の全ファイルを更新する。

タグ・カウンタは最初ゼロに設定される。次いで、シス
テムはすべての記憶済みファイル（ＶＭ７　ｙ　４　／
Ｌ／、ＶＭ／−）、ＰＲＯＦＳ文書、ＰＲＯＦＳノート
の各ファイル）を走査して、既存のメールルーート・フ
ラグがあればそれを検出する（第１１図参照）。次いで
、タグ・カウンタが検出された最高のフラグ値に更新さ
れる。タグ・カウンタの内容が検査され、それがゼロの
場合は、後続のフラグ検査を簡単にするためにすべての
記憶済みファイルにフラグをつけるが、タグは作成せず
、タグ・カウンタを更新してからＭＡＩ　ＬＲＯＵＴＥ
ＸＥＣに分岐して戻る。逆に、タグ・カウンタがゼロで
ない場合は、ＭＡＩＬＩＮＩＴルーチンは直接ＭＡＩＬ
ＲＯＵＴ　　ＥＸＥＣに戻る。

ＭＡＩＬＲＯＵＴ　　ＥＸＥＣは、次にグループ追従管
理のための予め指定された管理者または秘書あるいはそ
の両方の処理を含む、システムのための動作ステップに
分岐する。そのために、共通ディスク動作モードが定義
されている。システムは、予め記憶された管理者テーブ
ルからの（定義すべき）閾値、当該ユーザに指定された
秘書の参照（ノードとｕｓｅｒｉｄ）、及び秘書の指定
し直しがあったかどうか検査するため、以前のＭＡＩ　
ＬＲＯＵＴ実行で同じユーザに指定された秘書の参照な
どのパラメータを獲得する。秘書−の参照が変更されて
いる場合は、秘書バックアップ手順（ＭＡＩ　ＬＳＣＢ
Ｋ）が開始される。

このバックアップ手順を第９図の流れ図に示す。

ＭＡＩＬＳＣＢＫ　　ＥＸＥＣは、まずタグに割り当て
られたフラグを検査して、メール宛先ユーザによってそ
のタグに個人″Ｐ″フラグが割り当てられた個人のファ
イルを、”Ｓ″フラグ秘書）を割り当てられたタグから
区別する。Ｓフラグは省略時に指定される。次に、未応
答の″Ｓ″フラグのついたメール（言い換えれば、公共
タグ付きのメール）を監視する。秘書が変わった場合、
以前の秘書にも新しく指定された秘書にも通知が行なわ
れる。

次にルーチンは分岐してＭＡＩＬＲＯＵＴ　　ＥＸＥＣ
に戻り、メール受信ルーチン、すなわち第１０図のＭＡ
ＩＬＲＥＣＰ呼出しルーチンを処理する。監視される受
信メールは、委託タグ、すなわち後で説明する委託基準
に基づいて追従管理者によって割り当てられるタグを含
むことがある。

これらのタグはファイル処理するだけでよい。当該のタ
イプに属する（すなわちＶＭま゛たはＰＲＯＦＳによる
）ＦＩＬＥＬＩＳＴ中で汎用カウンタより上にあるすべ
てのファイルを探して、残りのファイルが走査される。

この処置により、メール処理を新たに受信したメールだ
けに限定することが可能となる。新しく受信した（後で
説明するように、フラグがついていない）各メールは、
受信した最後のファイルまたは委託手順で処理すべき最
後のファイルで終わる反復ルーチンによってタグを用意
される。最後のファイルを探して走査を行なう。最後の
順序番号が処理されていないうちは、最後の順序番号が
タグ・カウンタ中で取り出され、１だけ増分されて５ｓ
ｓｓタグ番号参照を生成する。次いで、処理済みファイ
ルから情報、すなわち発信者名（ＦＲＯＭ）　、主題、
発信臼（ＲＣＶ日付）及び発信者参照（ノードＩＤとＵ
ｓｅｒｉｄ）を獲得することにより、新しいフラグが作
成される。メール発信者を検査して、Ｓ”フラグ（送信
メールの場合）または”Ｒ″フラグ受信メールの場合）
を生成し、当該ファイルの未使用部分に付加する。

第１１図は、７Ｍノートに適用される上記のフラグ付加
処理を示したものである。ＶＭノートは、ファイル・タ
イプがＮｏｔｅｂｏｏｋ″のファイル中で受信（記憶さ
れる）。端末で表示されるとき、各ノートはシステムが
挿入した分離符号（＝＝＝）で次のノートから分離され
る。分離符号行に上記の順序番号が挿入される。図のよ
うに、ノート１とノート２は既に処理済みであり、それ
ぞれ順序番号０７３２Ｒと０７３３Ｒが割り当てられて
いる。ノート３は最後のメール追従セツション以降に受
信されたもので、第１１ａ図ではまだ処理されていない
。＄＄ＣＮＴＲ＄＄　　＄ＦＬＵＰｍａ＄は最高の順序
番号０７３３を含んでいる。

ノート３が処理されると（第１１ｂ図）、それに順序番
号０７３４が割り当てられ、０７３４Ｒとフラグがつく
。対応するタグが「未割当て」ファイルに加えられる。

順序番号は増分されて０７３４となる。言い換えれば、
ＭＡＩＬＲＥＣＰ　　ＥＸＥＣは次の処理を実行する。

（１）送信／受信メールが記録されているファイル、す
なわち下記のいずれかのタイプに属するファイルを走査
する。

”ＸＸＸＸＸＸ　Ｎ０ＴＥＢＯＯＫ″−ＶＭ／−ト″Ｘ
ＸＸＸＸＸ　０ＦＳＬＯＧｆｌ　”　−Ｐ　ＲＯＦ　Ｓ
　／−）ＸＸＸＸＸＸ　ＨＥＴＬＯＧ″−ＶＭファイル
”　０ＦＳＩＮＤＥＸ　０ＦＳＤＡＴＡ　”　−Ｐ　Ｒ
ＯＦ　Ｓ文書（２）新しく受信／送信したメール（フラ
グなし）が検出された場合、上記ファイルから集めた関
連情報を用いてタグが作成される。

（３）フラグ（順序番号とＳ（送信メール）またはＲ（
受信メール）から構成される）が当該ファイルの未使用
フィールドに挿入される（第１０図参照）。

（４）＄＄ＣＮＴＲ＄＄　　＄ＦＬＵＰｍａ＄中の最後
の順序番号が更新される。

（５）「未割当て」ファイルにタグが入れられる。

ある追従セッシＵンと次のセッシ仔ンの間のフラグ設定
及び追従処理の処理時間を最小にするため、更新された
、すなわち新しいメールを受信したログ・ファイルのみ
を考慮する。そのために、追従システムは、ＦＩＬＥＬ
ＩＳＴコマンドがファイルを更新日別に分類することを
利用する。汎用カウンタ・ファイル＄ＧＥＮＣＴＲ＄　
　＄ＦＬＵＰｍａ＄は追従セツシヨンの最後に更新され
たファイルなので、ＦＩＬＥＬＩＳＴの一番上にくるは
ずである。次の追従セツション時には、未処理ファイル
が＄ＧＥＮＣＴＲ＄　　＄ＦＬＵＰｍａ＄の一番上にく
る。このため、システムは考慮すべきファイル、すなわ
ちまだ追従されていないファイルだけを識別することが
できる。

したがって、システムは未処理のログを識別し、かつ各
ログ内で未処理のファイルを識別する。

第１０図（第１０Ａ図、第１０Ｂ図、第１０Ｃ図からな
る）に示すように、最後に受信したメールにタグが割り
当てられると、（たとえば委託によって）特別に割り当
てられたメールにタグが付けられる。委託フラグを割り
当てられた各フＴイルが考慮され、まだフラグが付いて
いなければ、フラグが付けられる。最後に、システムは
ＭＡＩＬＲＯＵＴ　　ＥＸＥＣへ戻って、「未割当て」
画面を要求する（ＭＡＩＬＡＳＳＧ　　ＥＸＥＣ）。

タグを割り当てる追従ルーチンが実行されると、システ
ムは自動的に「メール未割当て」画面を表示する。この
画面はいくつか（下２に示す画面のコピーでは５個）の
タグを表示す冬。各タグは、ユーザが書き込める修正可
能フィールド（たとえば、目標日ＴＧＴ）と、修正不能
フィールド（たトエば、ＲＣＶ　　ＤＡＴＥ’ＰＤＯＣ
ＮＢＲ）を含む。異なる色を用いて修正可能フィールド
と修正不能フィールドを区別しである。また、機能キー
（ＰＦキー）は、オペレータがタグ及び対応するファイ
ルを処理できるようにカスタマイズしである。下記の説
明かられかるように、ＰＦキーのカスタマイズはプログ
ラマが任意に追従システムの各種ルニチンを設定して編
成することができる。

このシステムのいくつかの特徴が、上記の画面のコピー
に示されている。説明のため、それらに番号をつけであ
る。

＊０は、画面表示の上部、とりわけメール処理日及び年
初からの日数と退散を示す。たとえば、Ｄ１５７Ｗ２３
は、その年の１５７日目及び２３週目を表わす。

＊１は、処理待ちの文書のメール・タグを示す。

＊２は、目標日が指定され、対応するタグが「未応答」
ファイルに転写されたばかりのメール・タグを示す。

＊３は、ユーザが廃棄したばかりのメール・タグを示す
。ＰＦ指定から明らかなように、削除はカーソルをタグ
・フィールドの１つに合わせて、ＰＦ４を指す（または
ＴＧＴ　　ＤＡＴＥの最初のＹ″にＤ”を重ね書きする
）ことによって行なう。

メール・タグだけが削除され、関連するメールは削除さ
れないことに留意されたい。この機能により、タグ付き
のメールをクリアして、選択したメールだけを追従し続
けることができる。

＊４は、ＰＦキーの指定を示す。これは自明である。

＊５は、秘書指定フラグを示す。このフラグはＳ（省略
時）またはＰにセットされる。Ｓフラグ付きのタグは監
視のため秘書の所へ送られ、Ｐフラグ付きのタグは、秘
書の監視を受けない私用ファイルである。′Ｓ″フラグ
付きのタグは、秘書から見て「公共」タグとも呼ばれる
。

上記の処理は、第１２図（第１２Ａ図と第１２Ｂ図から
構成される）のＭＡＩＬＡＳＳＧ　　ＥＸＥＣを実行す
ることによって制御される。

タグは、ページ（Ｐ）ごとに画面に表示される。

ただし、Ｐ＝１から始まる。タグが表示されると、ユー
ザはカーソルを使って通常のやり方で、たとえば、キー
ボード、タグ制御キー、あるいはカーソル制御キーを使
って、タグまたはタグ内の選択可能フィールドを選択す
ることができる。この動作はシステムで監視され、「ユ
ーザ応答」と見なされる。

各応答の後に、タグが走査され、更新のため及び削除す
るタグを探すため目標白が検査される。

目標白が数値を含む場合（最初のデータ・デイジットと
して挿入されたＤは削除を意味する）、妥当性が検査さ
れる。無効な日付、たとえばＭＭ＞１２があるとエラー
・メツセージが表示され、ＰＦ３を押してタイツトした
とき、ユーザの訂正を受ける。日付の妥当性が検査され
ると、タグは「未応答」ファイルに転送され、「未割当
て」ファイルから削除される。

削除についてテストするため、カストマイズした機能キ
ーが走査される。明らかなことながら、機能キーは追従
システムのユーザの必要に応じてカストマイズできる。

現在得られる「未割当てメール」ルーチンの実施態様で
は、ＰＦ主キーは下記の機能が割り当てられている。

−ＰＦ４＝削除二「未割当て」ファイルからタグを削除
する。

−Ｐ　Ｆ　８　＝　Ｍａｉｌ　Ｅｄｉｔ呼出し：タグに
付加された文書を取り出して表示するルー チンに分岐する。

−ＰＦ３＝タイツト：ユーザが各タグに加えた変更をフ
ァイル処理し、追従シス テムを「未応答」ルーチンに切 り替える、すなわち「未割当て」 ルーチンから出る。

−ＰＦ７＝作成：任意にタグを作成するルーチンに分岐
する。このルーチンは、 追従システムによって監視・追 跡される電子メールを介して受 信されないメール用にタグ・リ マインダを付加するため、ブラ ンク・タグを表示する。

−ＰＦ　１０及びＰＦＩＩ：それぞれ「未割当て」ファ
イルの順方向及び逆方向の 画面移動を行なう。

ＭＡＩＬＡＳＳＧ　　ＥＸＥＣの実行中にＰＦ３を押す
と、システムは未応答メールを処理するためのＭＡＩＬ
ＡＮＳＷ　　ＥＸＥＣに分岐する（第１３Ａ図ないし第
１３Ｄ図を参照のこと、第１３Ｃ図はＣ１と０２からな
る）。

ＭＡＩＬＡＮＳＷ　　ＥＸＥＣを実行すると、システム
はまず新しいまたは変更された委託タグの通知について
検査する。答がイエスの場合、システムはＭＡＩＬＦＷ
ＴＲＥＸＥＣ（第１４図参照）に分岐して、委託タグを
提示する。委託タグとは、通常の方法で監視される受信
メールではなく、平均的システム・ユーザの１人または
管理者によって委託手順を用いて割り当てられるジロブ
に対して生成されるタグである。したがって、委託タグ
は転送されるジロブに付加される。ＭＡＩＬＦＷＴＲＥ
ＸＥＣ（第１４図）は、新しいまたは更新された委託タ
グを提示する。これらの情報は、システムによって作成
されＭＡＩＬＲＥＣＰ　　ＥＸＥＣによって更新される
「タグ通知」ファイルと呼ばれる追跡ファイル＄ＦＷＴ
ＲＫ＄＄ＦＬＵＰｍａ＄から引き出される。ＭＡＩＬＡ
ＮＳＷ　　ＥＸＥＣ（第１３Ａ図）に戻って、まずタグ
が目標白ごとに分類され、順次読み出され、目標白に関
する予め定義された遅延閾値に基づく特別の強調表示つ
きで表示される。たとえば、１）目標白く第１閾値の場
合、 フィールド１＝文書番号　　　青に設定フィールド２＝
受信日　　　　青 フィールド３＝目標日　　　　緑 フィールド４＝応答日　　　　緑 ２）第［閾値く目標白く第２閾値の場合、フィールド２
の内容が亀”ＴＡＲＧＥＴ−Ｘ１６″を含む以外は上記
と同じ。ただし、Ｘは目標白までの残りの日数。このフ
ィールドは白。

３）目標臼≧第２閾値の場合、 （２）と同じだが、色が異なる。

フィールド１＝白 フィールド２＝白 フィールド３＝赤 フィールド４＝赤 次に、第１閾値に対するタグ検査が始まる。第１閾値に
達し、当該タグが私用タグではない場合、秘書に通知が
行なわれる。こうした処理が最後のタグまで行なわれる
。第１閾値に達した各ファイルについて、監視をトリガ
するため、タグ閾値フラグ・フィールドに”Ｔ″フラグ
（閾値フラグ）がロードされる。タグのベージ１から順
に、タグが表示される（第１３Ｂ図ないし第１３Ｃ図参
照）。ユーザは表示されたどのタグでも更新できる（し
なくてもよい）。第１３Ｃ図（この図はＣ１と０２にわ
かれている）に示すように、当該のタグが更新されてい
る場合、応答日がＤ″（削除）で始まるかどうか検査す
る。そうである場合、タグが「応答済み」ファイルに書
き込まれて、そのメールの追従が停止される。そうでな
い（すなわち　ｌ’ｌＤ″タグがない）場合、日付の妥
当性が検査される。日付が無効な場合、ユーザに日付の
訂正を要求するメツセージが表示される。ＰＦ３が押さ
れたかどうかテストされ、押されていない場合は、次の
タグで日付の妥当性検査が行なわれ、そうでない場合は
応答日がＹＹ　　ＭＭ　　ＤＤ″に設定される。有効だ
ったタグは「応答済み」ファイルに書き込まれる。続い
て、２つのテストが行なわれる。第１のテストは、その
ユーザが応答の責任者であるかどうか検査するものであ
る。責任者である場合、委託変更通知ルーチン（ＭＡ　
Ｉ　ＬＦＷＴＧ　　ＥＸＥＣ）（第１５図参照）が呼び
出される。そうでない場合は公共タグかどうか検査され
、公共タグでない場合は「未応答」ファイルから単にそ
のタグが除去される。公共タグである場合は、秘書用の
通知タグが作成される。′Ｄ″フラグは削除済みタグを
表わし、′Ａ″フラグは応答済みタグを表わす。当該フ
ラグに付加された委託リストがあるかどうか検査される
。ある場合は、秘書委託通知を作成してから「未応答」
ファイルからタグが削除され、そうでない場合はそのま
ま削除が行なわれる。こうした処理が最後のタグまで行
なわれる。

応答日が更新されなかったとすると、目標日の変更の有
無が検査される。変更されていない場合、次のタグでタ
グ走査が行なわれる。目標日が変更された場合は、目標
日の妥当性検査が行なわれる。

無効な場合、ユーザに訂正した日付の入力を求めるエラ
ー・メツセージが表示される。次に、ＰＦ３を押すと目
標日がリセットされる。目標日が有効だった場合、目標
日が第１閾値より低いかどうか検査され、閾値フラグ＝
　ｎ　Ｔ　ｎであればフラグがＦにセットされる。公共
タグの場合、第１閾値に達したとき、閾値フラグ・フィ
ールドに″Ｔ″Ｔ″フラグ入される。この”Ｔ″フラグ
は、当該のフラグが調査ゾーンに入り、秘書が通知を受
けたことを知らせるものである。

次に目標日〈閾値及び閾値フラグ＝″Ｔ”かどうか検査
する。これは、次のような意味である。

このテストの答がイエスの場合、タグが調査ゾーンに入
り、秘書が通知を受けるが、目標日は延期されて調査ゾ
ーンから出る。したがって「遅延」フラグで秘書に通知
する必要がある。

したがって、応答日が更新されたかまたは目標日が更新
された瞬間に、タグが直接考慮され、次いでシステムは
当該タグに（すなねち、その関連ファイルに）割り当て
られた委託命令を探す。そのために、システムは委託変
更通知ルーチン（ＭＡＩＬＦＷＴＧ　　ＥＸＥＣ）（第
１５図参照）に分岐する。

この機能の理論的根拠を理解するには、若干の追加情報
が宵月である。追従システムのユーザの１人がメールを
受は取ったとき、予め定義したユーザ・リスト中の別の
ユーザに応答の責任を委託し、１人または数人の検討者
にまたコメントを委任しようと決心することがある。委
託機能は、後で説明するように、「未応答メール」画面
でＰＦ８（責任転送）を押すとアクセスできる。ある選
択を設定すると、その選択が委託活動記録ファイルに入
る。

ＭＡＩＬＡＮＳＷＲＥＸＥＣの実行に続いて、ＭＡＩＬ
ＦＷＴＧルーチンを呼び出すと、システムは次の動作を
実行する（第１５図参照）。

−委託活動記録ファイル中でリストを見つけて検討する
。

−「委託通知」ファイルを作成する。

−「委託通知」ファイルを被委託者（責任者または検討
者）に送る。

第１５図に示すように、委託処理の際、統計及び制御／
計画の目的でカウンタを使用してそれをロードまたは増
分することができる。

ＭＡＩＬＡＮＳＷＲＥＸＥＣはまた、カストマイズされ
２つのメニューに分配された機能キーをもたらす。ＰＦ
２を押すとメニュー１からメニュー２に切り替わり、Ｐ
ＦＩを押すとメニュー１に戻る（第１３Ｂ図参照）。ど
ちらのメニューでも、ＰＦ３を押すと、後で第１３Ｂ図
に関して説明するように「クイツト」ルーチンに分岐す
る。

残りのキーの機能は次のように構成されている。

（１）メニュー１で、 −ＰＦ５：ＭＡＩＬＡＳＳＧ　　ＥＸＥＣを呼び出し、
「未割当てメール」画面に戻 る。

−ＰＦ６　：タグに付加されたファイルを編集するため
の実用上特に有用なＭＡＩＬ ＥＤＩＴルーチンを呼び出す。この ルーチンはメール・テキストを獲得 して表示するだけである。

−ＰＦ７　：タグを作成するため、ＭＡＩＬＣＲＥＡ　
　ＥＸＥＣ（後で第１６図に関 して説明する）を呼び出す。これは、 電話または紙によるメツセージ・デー タを追従システムに入力するのに特 に有用である。すなわち、追従シス テムを電子メール以外に拡張する。

−ＰＦ８　：委託メニューを提示するため、ＭＡＩＬＦ
ＷＲＤ　　ＥＸＥＣ（第１７Ａ 図と第１７Ｂ図からなる第１７図を 参照）を呼び出す。

委託機能については、既にＭＡＩＬＦＷＴＧＥＸＥＣに
関連して触れた。具体的にいうと、本明細書では、ユー
ザは４つの責任レベルを利用できる。

（ａ）受信者（Ａ）二当該メールの真の受信者で、目標
日の入力、選択フラグの修正、責任者と検討者の指定が
できる。

（ｂ）責任者（Ｂ）：メールの応答を行なうことを要請
され、応答臼を入力する人で、新しい責任者の任命、検
討者リストの変更、目標日の修正ができる。

（Ｃ）検討者（Ｃ）：メールの検討／コメントを依頼さ
れた人。

委託フラグ（ＡｌＢｌＧまたはＤ）は、対応するタグに
自動的に付加される。委託プロセスについては、後で第
１７図に関して詳しく説明する。

−ＰＦｌｏ及び１１：それぞれ「未応答メール」画面を
前後に移動するのに使用す る。

−ＰＦ１２：指示されたタグにさらに情報を追加し、表
示するためのメニューを 提示するＭＡＩＬＭＯＲＩ　　ＥＸ ＥＣを呼び出す。

（２）メニュー２で、 −ＰＦＩ：メニュー１に戻る。

−ＰＦ２　：応答済みファイルで検索を行なうため、Ｍ
ＡＩＬＳＲＣＨＥＸＥＣルー チンを呼び出す。

最後に、メニュー１でもメニュー２でも、ＰＦ３はクイ
ツト・キーである。いくつかの処理を実行した後でこの
キーを押すと、追従システムから出ることができる（第
１３Ｄ図参照）。

追従システムから出ると、まず応答済みメールまたは未
応答メールに関する目標日を更新しなければならない。

すなわち、各フラグに付加されたメールを処理するため
、残っている遅延を表示するための計算と書込みを行な
う。これらの動作と並行して、監視のため指定された秘
書が自動的に通知を受ける。

まず、タグが秘書の監視下にあり、私用に変更された場
合、対応するメールが私用にされたことをその秘書に通
知する。対応するメールに閾値フラグがついていたとす
ると、それに応じてそのフラグが消去される。

遅延フラグについて次のテストを行ない、メール処理が
遅延し閾値フラグをリセットしたことを秘書に通知でき
るようにする。

上記の諸動作を、「未応答」ファイル中のすべてのタグ
について繰り返し、それに応じてタグを修正し、秘書通
知ファイルを送り、あるいは秘書通知ファイルを消去で
きるようにする。次いで、汎用カウンタを現在の日付と
現秘書で更新し、タグ通知ファイルを消去し、最後にア
プリケーシヨンから出て、ルーチンはＭＡＩＬＲＯＵＴ
　　ＥＸＥＣに戻る。「未応答メール」画面は、最後に
次のようになる。

指標’１ないし６６は、このルーチンで提供される特定
の機能を指示し説明するためにここで使用しただけであ
る。

傘１は、強調表示される過ぎてしまった目標を示す（＋
２は、画面の左上端に出ている現日付を第１のタグのＴ
ＲＧＴと比較すると確認できるように、目標を２日過ぎ
たことを示す）。

１２は、強調表示されて閾値（目標の５日前）に達した
ことを示し、そのタグに対してユーザの注意を喚起する
もので、毎日減分される。

傘３は未応答メールで、まだ閾値に達していない。

幸４は応答済みメールで、応答臼がシステムに入力され
たばかりである。

傘５は、個人選択フラグを割り当てられたメール（秘書
にはまだ報告されていない）。

１１６は委託フラグである。

第１３Ｂ図に示すように、メニュ７−１でＰＦ７を押す
と、ＭＡＩＬＣＲＥＡ　　ＥＸＥＣが呼び出される（第
１６図の流れ図を参照）。

このルーチンを使うと、キーボードからタグを入力する
ことにより、書簡、電話、個人行動、報告などの非電子
メールにも追跡システムが利用できるようになる。その
ために、ＭＡＩＬＣＲＥＡＥＸＥＣを呼び出すと、下記
の画面のコピーに示すように、既に記入済みのフィール
ドと未記入のフィールドをもつタグ・テンプレートが゛
表示される。

：　　ＡＣＴＩＶＩＴＹ／ＭＡＩＬ　　：：　　ＴＡＧ
　　ＣＲＥＡＴＩＯＨ＊ ＤＯＣＮＢＲ：　８６０６１ＴｔｌＢ１７５６　ＲＣＶ
Ｄ：８８０３０１　　ＦＲＯＭ：　ＴＵＢＩＡＮＡＳＵ
ＢＪＥＣＴ：　Ｅｘｔｅｒｎａｌ　ｄｏｃｕｍｅｎｔ　
ｃｒｅａｔｉｏｎ″ＴＧＴ　ＤＡＴＥ：をＭＷ　ＤＤ　
ＳＩｆ　ｔｈｅ　Ｔａｒｇｅｔ　ｄａｔｅ　ｉｓ　ｆｉ
ｌｌｅｄ　ｉｎ：ｔｈｅ　ｔａｇ　ｗｉｌｌ　ｓｈｏｗ
　ｏｎ　ｔｈｅ″ＴＯ−ＢＥ−ＡＮＳＷＥＲＥＤ　５ｃ
ｒｅｅｎＩｆ　ｎｏｔ： ｔｈｅ　ｔａｇ　ｗｉｌ　ｌ　ｓｈｏｗ　ｏｎ　ｔｈｅ
　Ｔｏ−ＢＥ−ＡＳＳＩＧＨＥＤ　５ｃｒｅｅｎ既に記
入済みのフィールドには、遂次カウンタによってセット
されそのユーザ向けに予め設計されたＤｏ−ＣＮＢＲが
ある。たとえば、８８０６１ＴＵ８１７５Ｂは、１９８
８年の６１日白灯現日付）、ユーザのＩＤ簡略記憶コー
ドを表わすＴＵＢｌ及び順序番号１７５６を表わす。記
入済みフィールドには、ＲＣＶ　　ＤＡＴＥの現日付も
含まれる。そのどちらも修正できない。発信者フィール
ド（ＦＲＯＭ）は、ユーザの名前が記入されるが、キー
ボードから任意に変更できる。主題フィールドには、ユ
ーザに主題を入力することを求めるＥｘｔｅｒｎａｌ　
ｄｏｃｕｍｅｎｔ　ｃｒｅａｔｉｏｎ（外部文書作成）
“などのメツセージを入れる。ＴＧＴ　　ＤＡＴＥは、
最初ＹＹ　　ＭＭ　　ＤＤを含む。目標臼が記入されて
いる場合、タグは「未応答」画面に表示され、そうでな
い場合は「未割当て」画面に表示される。

自明のことであるが、この場合には、対応するメールを
編集するためのＥＤＩＴ″などの機能は利用できない。

第１６図に示すように、このルーチンは、まずタグ・カ
ウンタ中の最後の順序番号を獲得し、それを１だけ増分
してタグ現順序番号（たとえば１７５６）を獲得する。

次いで、端末表示画面に−「メール作成画面」が提示さ
れる。システムはユーザのフィールド修正を読み取り、
次いでＴＧＴＤＡＴＥの内容を検査して、ＴＧＴ　　Ｄ
ＡＴＥフィールドが記入済みか否かに応じて、そのタグ
を「未割当て」ファイルにファイルするかそれとも「未
応答」ファイルにファイルするか判定する。

日付の妥当性検査も行なわれ、ＭＡ　Ｉ　ＬＣＲＥ’Ａ
ＥＸＥＣから出てＭＡＩＬＡＳＳＧ　　ＥＸＥＣに戻る
前に日付の誤りを訂正することができる。

前述のように、ＭＡＩＬＡＮＳＷ　　ＥＸＥＣの実行中
にＰＦ８を押すと、委託メニューを指示して処理するた
めのＭＡＩ　ＬＦＷＲＤ　（第１７Ａ図及び第１７Ｂ図
を参照）が呼び出される。ユーザはこの画面上で、共通
してサービスされ管理されるグループに属する個人の名
前、ｕｓｅｒｉｄｓ　ノードＩＤを含むテーブルを獲得
する。このグループは、サブグループ（参照番号０．１
．２等々）に分かれていることもある。この表示された
テーブルは、フラグ″Ｆ″フィールドも含み、そこにユ
ーザはＢ（責任者）、Ｃ（検討者）またはＤ（削除）を
書き込むことができる。テーブル中のある個人の前にフ
ラグとしてこれらの文字の１つを入力すると、委託また
は委託の削除が行なわれる。

また、質問にイエスまたはノー（省略時の値はノーに設
定されている）で答えることにより、委託タグに文書を
付加することができる。付加とは、ここでは被委託者に
当該の完全テキスト・メールを獲得するための手段を与
える、すなわちタグとタグ付きメール（またはそのメー
ルにアクセスするための手段）を転送するという意味で
ある。

言い換えれば、まず通知カウンタが読み取られて増分さ
れ、委託通知ファイルが作成される。テストを行なって
、ユーザが責任者（タグ状況がＣでもＡでもない）であ
り、したがって当該メールに応答するジョブを委託でき
るかどうか検査する。

ユーザが責任者でない場合、システムはメツセージを出
してＭＡＩＬＡＮＳＷ　　ＥＸＥＣに戻る。

そうでない場合は、管理者テーブルから項目を読み取り
、当該のｕｓｅｒ　ｉｄ　を探す。ｕｓｅｒ　ｉｄが存
在する場合、委託活動記録ファイルを走査して、委託タ
グが既に存在するかどうか判定する。管理テーブルが提
示されるとき、既存の項目（たとえば、ＤＯＣＮＢＲ，
受信者の名前とｕｓｅｒｉｄ）が強調表示される。

ユーザがタイプした選択が読み取られ検査される。複数
の責任ある被委託者が設定される場合、リストの最初の
人だけが維持され、その他の人には検討者の仕事が委任
される。次に、ユーザ自身が「責任ある」被委託者であ
り、グループの他のメンバーにも責任が委任されている
とすると、そのユーザの状況は受信者に変わる。

ＰＦ３を押すと委託メニューから出ることができ、ＰＦ
５を押すと、行なった委託の選択が確認され、再度「未
応答メール」画面が表示される。

その瞬間から、自分の文書メール・タグで、委託処理が
使用されたことを示す自分の状況（ＡまたはＢ）が受信
者に見える。タグが責任者及び検討者の「未応答メール
」ログに送られ、続いて適当な文字（ＢまたはＣ）のフ
ラグがつけられる。

受信者が応答の責任を保持し、検討者（Ｃ）のみを指定
する場合、そのフラグは自動的にＡからＢに変わる。

関連文書は、責任者または検討者として関与する人に別
に送らなければならない。委託情報を含む＄　Ｆ　Ｌ　
Ｐｘｘｘｘファイルが関係するユーザに送られる。ユー
ザの処置は不変であり、追従プログラムは呼び出される
と自動的にそれを読み取る。受信者と検討者のタグは、
責任者が応答臼を入力したとき自動的に処理される。

第１３Ｂ図に関して述べたように、ＰＦ１２キーを押す
と、”文書ＮＢＲＸに関する追加情報”という名前の画
面を提示するためのＭＯＲＩＮＦＯ（ＭＡＩＬＭＯＲＩ
　　ＥＸＥＣ）ルーチアに入る。ただし、Ｘは処理され
る文書の参照番号である。このルーチンは、下記のよう
なメール特性と考えられる情報を表示する。

一主題 一発信者 一文書受信日 一目標日 一文書のタイプ −あり場所（たとえば、ノートログやノートブックの名
前） 一委託状況 委託機能が使用されている場合、関与する受信者、責任
者、検討者がすべて日付と共に表示される。

委託処理中に多数の転送が行なわれる場合、受信者に通
し番号がつけられる。いずれにせよ、−人の人が応答を
行なう責任をもつ。

第１８図にＭＯＲＩＮＦＯ流れ図を示す。まず、メール
からメール特性が取り出される。次いで、委託リストを
用いて委託状況の検査が行なわれる。

それにより、当該タグに情報を付加する妨げとなる不整
合性がある場合、警告メツセージを出すことができる。

そうでない場合、メール特性が、当該タグに付加したい
情報を入力するための指示されたゾーンと共に表示され
、次いで「未応答メール」画面に戻る。

第１３Ｂ図に示すように、メニュー２で操作中に機能キ
ーＰＦ２を押すと、応答済みメールの探索を行なうため
、ＭＡＩ　ＬＳＲＣＨルーチンが呼び出される。自明の
ことながら、この機能は、どのようにすれば機能を付加
できるかを示して追従システムの利益を強調するための
追加機能である。

このルーチンを使うと、応答済みメールの間から探索を
行なうことができる。論理式ＡＮＤ１０Ｒで結合された
１組のフィールドが表示される。単にこれらのフィール
ドにキーワードをタイプするだけで、ユーザは探索のた
め活動化すべき照会動作を定義することができる。次に
、システムは対応する検出されたメール・タグを表示し
、そこでさらに情報を追加したり、選択したタグを再活
動化したりするなどの操作を行なうことができる。

第１９図（第１９Ａ図と第１９Ｂ図からなる）に、ＭＡ
ＩＬＳＲＣＨＥＸＥＣを示す。このプログラム・モジュ
ールは、実行されると、活動記録ファイル・タグを走査
して、要求者が使用可能かどうか検査する。次いで、シ
ステムは応答済みファイル・タグを獲得して応答日別に
分類し、日付と探索引数を入力するための探索画面を提
示する。ＰＦ３を押すとＭＡＩ　ＬＳＲＣＨから出てＭ
ＡＩＬＡＮＳＷ　　ＥＸＥＣに戻る。そうしないと、シ
ステムはタグ応答臼と設定された探索日限界が一致する
かどうか検査する。次いで、論理探索引数に基づいて探
索が行なわれ、結果タグが提示され、結果が表示される
。

機能キーのカストマイズは自明であり、たとえばＰＦ２
はＭＡＩＬＭＯＲＩ　　ＥＸＥＣを呼び出す。

前述のように、追従ユーザによって処理されるメールを
、指定された秘書が追跡することもできる。そのために
、上記に開示した通常のユーザが使用するファイル（バ
ッファ）の他に、秘書の７シンに「通知ファイル」、「
監視ファイル」、「委託通知ファイル」、「応答済み委
託ファイル」が割り当てる。秘書は、閾値限界に合格し
たメール・タグを追跡し、マネージャと一緒にそれを検
討して、文書に期限内に回答するための処置計画を策定
する。

秘書は、経営幹部に提出すべき統計データを記録するこ
とができる。追跡能力は、受は取った文書（メール）の
数、指定された文書の数、応答済み（目標内／目標）の
数、削除された文書の数によって定義できる。

これは、秘書のＰＲＯＦＩＬＥ　　ＥＸＥＣを、ログオ
ン時または０ＭＳモードでＭＡＩ　ＬＭＯＮ■コマンド
をタイプするときに実行されるＭＡＩＬＳＥＣＦ　　Ｅ
ＸＥＣを含むように修正することによって可能となる。

上記の処理を第２０図の流れ図に示す。秘書のＰＲＯＦ
ＩＬＥ　　ＥＸＥＣに挿入されたＭＡＩＬＳＥＣＦ実行
命令に達すると、システムは各セツションの日付をロー
ドした秘書カウンタの内容を取り出す。上記の日付が現
日付であれば、システムはＰＲＯＦＩＬＥ　　ＥＸＥＣ
に戻って先へ進む。

そうでなければ、第２１図のＭＡＩＬＭＯＮＩルーチン
に分岐する。

「秘書監視」ファイルは、−日のうちに進化する。たと
えば、「目標−１」の状況であったタグが、ユーザが応
答臼を指定したときは、「応答済み」の状況になる。−
日の最初のログオン時に、前日に処理されたすべてのタ
グ（応答済み、削除、私用、遅延）が、ＭＡＩＬＳＰＲ
Ｇルーチンによってファイルのモニタからパージされる
。

このルーチンに従って、システムは前回のセッシ１ンの
日付を含む秘書カウンタを読み取って、それを現日付と
比較する。それが一致した場合、システムはＭＡＩＬＳ
ＰＲＧルーチンに分岐して、項目を更新する（第２２図
参照）。監視されたメールを含む秘書監視ファイルの全
項目を読み取り、″Ｔ″フラグのついていない、すなわ
ち対応するメールに応答するために設定された第１の閾
値に達しなかった全項目を消去する。

次いで、ルーチンはＭＡＩＬＭＯＮＩ　　ＥＸＥＣに分
岐して、秘書マシン読取機構（入力バッファ）で秘書通
知ファイルを受は取ったかどうか検査し、それをファイ
ルする。次に、システムは秘書通知ファイルを獲得し、
そのファイルの内容を使って秘書監視ファイルを更新す
る。

次いでシステムは、メールの状況がＦ（遅延）またはＰ
（私用）以外のものかどうか検査する。

答えがイエスであれば、秘書応答済みファイルから始め
て秘書の全ファイルを更新し、次いで秘書通知ファイル
を消去し、委託通知ファイルを獲得し、応答済み委託フ
ァイルから以前の委託リストを消却し、応答済み委託フ
ァイルに別委託リストを追加し、委託通知ファイルを消
去する必要があり、その後に秘書通知ファイルに戻って
、最後の秘書通知ファイルまで走査を続ける。

最後のファイルを検査すると、ＭＡＩ　ＬＭＯＮＩ　　
ＥＸＥＣは、下記の秘書監視表示画面を制御するＭＡＩ
ＬＳＣＤＳ　　ＥＸＥＣ（第２３図参照）ルーチンに分
岐する。

ＭＡＩＬＳＣＤＳ　　ＥＸＥＣは、まず秘書監視ファイ
ル項目を獲得し、適当なファイル状況をセットアツプす
る。選択される状況のタイプには次のものがある。

″Ａ″＝応答済応答窓答臼がユーザによって入力された
。

″Ｄ″＝削除：削除２グ書タグされた。

Ｐ”＝私用：ユーザが選択フラグをＳからＰに修正した
。

″Ｆ″＝遅延：ユーザが目標臼を修正した。

ＴＡＲＧＥＴ−ＸＸ　：　ＸＸ４を閾値テータニ対する
遅延を表わす。

この状況は、現日付が（現場管理者の 判断で設定された）閾値の範囲内にあ ることを示して、対応するメールに対 して秘書の注意を喚起する。

メール監視表示画面に示すように、機能キーはカストマ
イズされている。クイツト、印刷、ＦＷＲＤ（順方向）
　、ＢＫＷＲＤ　（逆方向）など若干の機能は自明であ
る。Ｐ１’１３＝強制応答とＰＦ７＝強制削除が追加さ
れている。ＰＦ６は、対応するメールがユーザの応答済
みファイルに送られたとき秘書監視ファイルを更新する
ことによって、通常は自動的に一致するはずのユーザの
タグと秘書のタグの偶然による不一致を是正するための
ものである。ＰＦ７は、削除されたタグ同士の不一致を
是正するためのものである。

Ｆ０発明の効果 本発明の追従システムは、予め設計されたメール・タグ
を生成し、それらのタグを交換されたメールから取り出
したデータで充填し、メール・タグまたは対応するメー
ルあるいはその両方を表示し処理することができるだけ
でなく、各種の管理用操作を実行することもできる。こ
うした操作には、単なる秘書の監視から、より複雑な管
理者の制御下でのものも含めたグループ毎のメール処理
まで広い範囲の操作が含まれる。

【図面の簡単な説明】

第１図は、ディジタル・ネットワーク・ノードを示す。 第２図は、ハード機能及びソフト機能を含むユーザのマ
シンを示す。 第３図は、本発明の構成図である。 第４図は、本発明を実施する際の機能キー操作を示す構
成図である。 第５図は、本発明の流れ図である。 第６図は、メール追従動作を示す。 第７図ないし第１０図及び第１２図ないし第１９図は、
通常のユーザ用に追従システムを実施するための流れ図
である。 第１１図は、ファイル処理機能を示す。 第２０図ないし第２３図は、追従メールの秘書による監
視を実施するための流れ図である。 出願人　　インターナシ日ナル・ビジネス・マシーンズ
・コーポレーシ式ン 代理人　　弁理士　　山　　本　　仁　　朗（外１名） 他のノードへ 第 図 コンビエータ 第 図 第 図 と二Ｚアイル実行 ＭＡＩＬＲＯＵＴ　ＥＸＥＣ ファイルリスト ＋ａ＋ 第 図 ファイルリスト ファイルリスト ｂｌ ｅｌ 第　８　図 ＭＡＩＬＮＩＴ 口 ａＥＩＯＡＩＩｃ （第１０Ｂ図へ） 口 第１０Ｂ図 （第１０Ａ図から） 第１１図 第１３Ａ図 第１２Ｂ図 ＭＡＩＬＡＳＳＣＥＸＥＣ（続ぎ−ＩＦ］　）（第１３
Ｃ図の２へ） 第１３ｃ図の２ 第１４図 第 図 第 Ｆ■ 第 Ｂ 図 第　１９Ａ　　図 Ｅ　　２０ 第 手続補正書（右側 平成１年　７月ｌｖ７［３ 特許庁艮官　吉　ＩＩＩ　　文　毅　殿１、１ざ件の表
示 平成　１年　特許願　第７８７２２号 ２、発明の名称 電子メール追従システム ３、補正をする者 ・１１件との関係　　特許出願人 住所　アメリカ合衆国＋　０６０４、ニューヨーク州ア
ーモンク（番地なし） 名称 インターナショナル・ビジネス・マシーンズ・コーポレ
ーション ６、補正の対象 図面 ７、補正の内容 図面の第１３Ｃ図及び第１３Ｃ図の２をそれぞれ、別紙
の第１３Ｃ図（その１）及び第１３Ｃ図（その２）のよ
うに補正する（内容に変更なし）。 ４、代理人 第１３ｃ図（その１） 第１３０図（その２）へ 第１３Ｃ図（その２）

Claims (1)

1. 【特許請求の範囲】 個々のユーザーに仮想マシンが割り当てられ、該仮想マ
   シンは、ネットワーク・ノードにおいて、メモリ領域と
   、システムに対してログ・オンされたネットワークに接
   続されたキーボード及び表示端末を介してデータを入力
   し処理し他のユーザーにメールするためのソフトウェア
   及びハードウェア機能を共有するための手段を有するよ
   うな、データ処理及びディジタル伝送ネットワークのた
   めの電子メール追従システムにおいて、 （ａ）予定のフィールドを含むメール・タグを生成する
   ための手段と、 （ｂ）ユーザーのメールを追跡して予定の特性のメール
   ・データをそれからフェッチしあるいは取り出すための
   追跡手段と、 （ｃ）上記追跡手段に応答して上記メール・データを対
   応する予定のメール・タグ・フィールドに記録し、もっ
   てフィールドが埋められたタグを生成させるための記録
   手段と、 （ｄ）上記記録手段に応答して第１の予定のファイル中
   の上記フィールドが埋められたタグを、上記ユーザーの
   マシンに記憶するための記憶手段と、（ｅ）上記ファイ
   ルの内容を上記ユーザーの端末表示装置に表示するため
   の端末制御手段を具備し、上記端末制御手段は、 （ｅ１）特定のメール・タグ・フィールドに応答する応
   答手段と、 （ｅ２）上記応答手段に応答して、上記応答したフィー
   ルド内容を解析するための解析手段と、（ｅ３）上記解
   析に応答してメール・タグを転送するための転送手段を
   有する、 電子メール追従システム。