JPH10293748A - メッセージ追跡の方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 複雑な情報処理ネットワークで使用可能なメ
ッセージ追跡方法を提供する。 【解決手段】 メッセージの追跡から得たデータを含む
メッセージ・トラック・データ構造２２を構築する。次
に、これを用いて、メッセージ・トラックのグラフィッ
ク表現２８を生成し、ユーザに表示する。メッセージ・
トラック・データ構造２２を構築する際、メッセージ・
トラック内のノードに対するエントリを作成する。この
エントリは、ノードにおけるメッセージ・ステータスを
規定するデータを含む。ノードおよびこれらノードを接
続する接続要素のグラフィック表現、ならびにノードに
おけるメッセージ・ステータスのアイコン表現には、グ
ラフィック・データベース２４においてアクセスするこ
とができ、あるいは、処理進行中に生成し、メッセージ
・トラックのグラフィック表現を作成することができ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理ネットワ
ークにおけるメッセージの追跡に関する。本発明は、特
にインターネットをベースとするメッセージの追跡に適
用するものである。

【０００２】

【従来の技術】現在、インターネット・ベースのメッセ
ージには、限られたメッセージ追跡機能が設けられてい
るに過ぎない。実際、完全なメッセージ追跡は行われて
いない。実際面では、メッセージ追跡は、エラー・メッ
セージに限定されており、典型的に、対象受信者のアド
レスのエラーおよび／または対象受信者のホストにおけ
る障害によって、当該受信者のアドレスを突き止めるこ
とができないためメッセージが配信不能となった場合
に、このエラー・メッセージを受信する。メッセージを
配信することができなかった場合、当該メッセージの元
の送出者は、例えば、「ユーザ不明」を示す応答を受信
する。

【０００３】具体的には、インターネット上では、２つ
のタイプのe-mailメッセージ、即ち、メッセージと通知
(notification)がある。メッセージとは、ユーザがイン
ターネット上の一人以上のユーザに送出するものであ
る。通知とは、メッセージに障害が発生した場合に何が
発生したかについて詳細に記し、あるいはいつそれがそ
の宛先に到達したか、またはどこに配信されるのを待っ
ているのかについて詳細に記したメッセージのことであ
る。インターネットでは、メッセージの発信者にメッセ
ージのステータスを返送するための、配信ステータス通
知（ＤＳＮ：Delivery Status Notifications)の使用法
を詳細に記した、１組のいわゆるＲＦＣ(Request for C
omments)がある。ＲＦＣは、本質的に、インターネット
を構築する標準となっている。そのフォーマットとそし
てＤＳＮをいつ送るかについては、これらＲＦＣに詳細
に記されている。即ち、ＲＦＣは、メッセージの追跡に
おいて問題に至った場合、およびメッセージがその最終
的な宛先に到達した場合に、どのようにそしていつＤＳ
Ｎを返送すべきかについて指定している。

【０００４】

【発明が解決しようとする課題】インターネットを経由
して送出するメッセージに対するメッセージ追跡機能の
改良および一層の完全化を図り、ＲＦＣに制定された状
況以外の状況に対処することができれば望ましいであろ
う。しかしながら、例えば、多数の受信者があるメッセ
ージに関連する問題、例えば、ルーティングの複雑化の
可能性を含む複雑な問題のために、扱い難い量のデータ
をユーザに提示しなければならない場合もある。したが
って、インターネット等の複雑な情報処理ネットワーク
で使えるメッセージ追跡機能に対するニーズがある。

【０００５】

【課題を解決するための手段】本発明の第１の面によれ
ば、情報ネットワーク上に送出したメッセージを追跡す
る方法を提供し、この方法は、 ａ）メッセージのトラック内の複数のノードからのステ
ータス・データを含むメッセージ・トラック・データ構
造を構築するステップと、 ｂ）前記メッセージ・トラック・ステータス・データか
ら、前記メッセージ・トラックのグラフィック表現を生
成するステップであって、前記グラフィック表現が、前
記ノードにおける前記ステータス・データを表す複数の
グラフィック要素を含み、前記グラフィック要素は相互
に配列して前記メッセージ・トラックを表す、前記のス
テップと、から成る。

【０００６】メッセージ・トラック・データ構造の生
成、および好ましくはツリー状表現のデータ構造のグラ
フィック表現の使用によって、ユーザに容易に理解およ
び操作が可能な方法で、メッセージ・トラック情報を自
動的に管理し表示する方法をユーザに提供する。

【０００７】このグラフィック表現は、コンピュータ・
システムの表示画面上に表示したり、印刷したり、後で
表示するために記憶したり、遠隔地に送信し必要に応じ
て表示することが可能である。

【０００８】先のステップｂは、ステータス・データに
応答して、前記ノードにおけるメッセージ・ステータス
のアイコン表現のパレットにアクセスすることにより、
グラフィック要素を生成するステップを含むことができ
る。あるいは、ステップｂは、前記ステータス・データ
に応答して、前記ノードにおける前記メッセージ・ステ
ータスを表すグラフィック要素を、処理の進行中に生成
するステップ、を含むことができる。

【０００９】好ましくは、ステップｂは、グラフィック
要素の階層を生成して、各グラフィック要素が前記ノー
ドの１つにおけるメッセージ・ステータスをグラフィッ
ク的に表すステップ、を含むことができる。前記階層の
前記グラフィック要素は、定着したツリーとして、また
はグラフとしてリンクすることができる。オプションと
して、ステップｂは、前記グラフィック要素にテキスト
を追加するステップを含むことができる。前記テキスト
は、前記メッセージ・トラック内の１つのノードの識
別、メッセージの識別、前記１つのノードにおけるメッ
セージの処置、の内の１つ以上を識別することができ
る。

【００１０】前記方法は、更に、 ｃ）前記グラフィック表現の一部分のユーザ選択に応答
して、前記メッセージ・トラック内の１つ以上のより低
いレベルのノードの詳細を記す、更に別のグラフィック
要素を生成することによって、前記選択した部分を展開
するステップ、を含むことができる。

【００１１】また、前記方法は、更に、 ｃ）前記グラフィック表現の一部分のユーザ選択に応答
して、前記グラフィック表現の一部分に、メッセージ・
ステータスを記述するテキストを追加するステップ、を
含むことができる。

【００１２】また、前記方法は、更に、 ｃ）前記グラフィック表現の少なくとも一部分のユーザ
選択に応答して、前記部分を、前記選択部分におけるメ
ッセージ・ステータスを記述するテキストと置換するス
テップ、を含むことができる。

【００１３】また、前記方法は、更に、 ｃ）複数のノードを含むグラフィック表現の一部分のユ
ーザ選択に応答して、複数のノードを含むより高いレベ
ルのノードを表すグラフィック要素を生成することによ
り、前記選択部分を圧縮するステップ、を含むことがで
きる。

【００１４】好ましくは、前記方法は、更に、グラフィ
ック表現を表示装置上に表示するステップを含む。

【００１５】好適実施例では、前記情報ネットワークは
インターネットである。

【００１６】本発明の他の面によれば、メッセージのト
ラック内の複数のノードからのステータス・データを含
むメッセージ・トラック・データ構造にアクセスして、
前記メッセージ・トラック・ステータス・データからの
前記メッセージ・トラックのグラフィック表現を生成す
るよう動作可能に構成したメッセージ追跡ツールを備
え、前記グラフィック表現が、前記ノードにおけるステ
ータス・データを表す複数のグラフィック要素を含み、
前記グラフィック要素は相互に配列してメッセージ・ト
ラックを表すこと、を特徴とするメッセージ追跡システ
ムを提供する。

【００１７】好ましくは、メッセージ追跡ツールと一体
化してまたは別個に、前記メッセージ・トラック・デー
タ構造を構築するよう動作可能に構成したメッセージ追
跡機構も備えている。

【００１８】前記メッセージ追跡機構は、メッセージの
送信に続いて、前記メッセージ・トラック内の前記ノー
ドから送出された応答に応答して、前記ノードにおける
メッセージ・ステータスを示し、前記メッセージ・トラ
ック・データ構造内の対応するエントリを作成するよう
動作可能に構成する。前記メッセージ追跡機構は、好ま
しくは、前記送信したメッセージのメッセージ識別子に
対応するまたはそれから派生したメッセージ識別子を識
別して、応答を識別するよう動作可能に構成する。

【００１９】代替的にはあるいはそれに加えて、前記メ
ッセージ追跡機構は、前記メッセージの送信に続くユー
ザが選択して時点で、メッセージ追跡要求を送信し、続
いて、前記メッセージ・トラック内のノードから送出さ
れかつ前記ノードにおけるメッセージ・ステータスを示
すメッセージ追跡要求に対する応答に応答して、前記メ
ッセージ・トラック・データ構造内に対応するエントリ
を作成するよう動作可能に構成する。好ましくは、前記
メッセージ追跡機構は、前記送信した要求のメッセージ
識別子に対応するまたはそれから派生したメッセージ識
別子を識別して、前記応答を識別するよう動作可能に構
成する。

【００２０】メッセージ・ステータスのアイコン表現の
パレットを備えることができ、前記メッセージ追跡ツー
ルは、前記ステータス・データに応答して、前記グラフ
ィック要素を生成するため、前記ノードにおけるメッセ
ージ・ステータスのアイコン表現のパレットにアクセス
するように構成する。

【００２１】代替的にはあるいはそれに加えて、前記メ
ッセージ追跡ツールは、前記ステータス・データに応答
して、処理の進行中にグラフィック要素を生成すること
により、前記ノードにおける前記メッセージ・ステータ
スを表すよう構成することができる。

【００２２】好ましくは、前記メッセージ追跡ツール
は、前記ステータス・データに応答して、グラフィック
要素の階層を生成するように構成し、各グラフィック要
素が１つのノードのにおけるメッセージ・ステータスを
グラフィック的に表す。

【００２３】前記メッセージ追跡ツールは、好ましく
は、表示装置上にグラフィック表現を表示するよう動作
可能に構成する。

【００２４】好適実施例では、前記メッセージ追跡ツー
ルおよび／またはメッセージ追跡機構は、コンピュータ
・ソフトウエアから成る。

【００２５】また、本発明は、データ記憶媒体上のメッ
セージ追跡プログラムも提供し、このプログラムは、メ
ッセージのトラック内の複数のノードからのステータス
・データを含むメッセージ・トラック・データ構造にア
クセスして、前記メッセージ・トラック・ステータス・
データからの前記メッセージ・トラックのグラフィック
表現を生成するよう動作可能に構成したメッセージ追跡
ツールを備え、前記グラフィック表現が、前記ノードに
おける前記ステータス・データを表す複数のグラフィッ
ク要素を含み、前記グラフィック要素は相互に配列して
前記メッセージ・トラックを表す。

【００２６】本発明は、更に、メッセージのトラック内
の複数のノードからのステータス・データを含む前記メ
ッセージ・トラック・データ構造にアクセスして、前記
メッセージ・トラック・ステータス・データからの前記
メッセージ・トラックのグラフィック表現を生成するよ
う動作可能なメッセージ追跡ツールを備えるコンピュー
タであって、前記グラフィック表現が、前記ノードにお
ける前記ステータス・データを表す複数のグラフィック
要素を含み、前記グラフィック要素は相互に配列して前
記メッセージ・トラックを表すコンピュータを提供す
る。好ましくは、このコンピュータは、前記グラフィッ
ク表現を表示する表示装置を備えている。また、このコ
ンピュータは、前記メッセージ・トラック・データ構造
を構築するよう動作可能に構成したメッセージ追跡機構
プログラムを備える。

【００２７】

【発明の実施の形態】図１は、本発明の一実施例による
メッセージ追跡システムの概略ブロック図である。メッ
セージ追跡システム１０は、単体のソフトウエア・ツー
ルとして実現することができ、あるいは、ネットワーク
・マネージャの一部としてまたはe-mailシステムの一部
として組み込むことも可能である。このメッセージ追跡
システムは、一元化パッケージ(unitary package)とし
て、または別個の構成要素の形態で実現することができ
る。これについては、以下で説明する。また、このメッ
セージ追跡システムは、イントラネット環境およびイン
ターネット環境の一方または双方において使用すること
ができる。言い換えれば、メッセージ追跡システムは、
プライベート・ネットワーク環境および公衆ネットワー
ク環境の一方または双方において使用することができ
る。特定の実施例についての以下の説明では、メッセー
ジ追跡システムは、インターネット環境における使用を
想定するが、メッセージ構造全体の一部を形成するロー
カルのイントラネット要素のメッセージ追跡も提供す
る。メッセージ追跡システムは、インターネット規格
“Simple Network Management Protocol”（ＳＮＭＰ：
簡易ネットワーク管理プロトコル）メッセージ送信およ
び管理情報ベース（ＭＩＢ：Management Information B
ase）技術を用いるインターネットを介する、ネットワ
ーク管理機能のネットワーク・マネージャの一体化部分
となることを意図するものである。ＳＮＭＰは、ＴＣＰ
／ＩＰ(Transmission Control Protocol/Internet Prot
ocol)ネットワークに対する簡略管理サービスを提供す
るように設計された標準的プロトコル（ＲＦＣ１１５
７）である。また、インターネット規格群は、いわゆる
管理情報ベース（ＭＩＢ）も規定しており、これは、ネ
ットワーク管理のグローバル情報モデルを形成し、ツリ
ー構造に組織化した情報オブジェクトを与える。これ
は、ネットワーク管理についてのグローバル情報モデル
を形成する。この情報モデルは、ＦＲＣ１１５５“Stru
cture and Identification for TCP/IP-Based Internet
s”に記載されている。このモデルは、将来の拡張を可
能にするためツリー構造に組織化した情報オブジェクト
を含む。標準的なＭＩＢの一例が、ＲＦＣ１２１２“Ma
nagement Information Base for network Management o
f TCP/IP-Based Internets: MIB II"に規定されてい
る。これ以上のＳＮＭＰおよびＭＩＢに関する詳細は、
William Stallingsによる“Data and Computer Communi
cations”（第４版）, Maxwell MacMillan Internation
al, 1994 ISBN 02-415441-5, 第７０１〜７２４頁に
おいても得ることができる。

【００２８】図１に示すように、メッセージ追跡システ
ム１０は、メッセージ追跡機構２０およびメッセージ追
跡ツール２６の形態の２つの機能的構成要素を備えてい
る。メッセージ追跡機構２０およびメッセージ追跡ツー
ル２６は、統合ソフトウエア・パッケージとして供給す
ることができる。あるいは、その代わりに、メッセージ
追跡機構２０は、メッセージ追跡ツール２６とは別個に
供給することも可能である。実際、メッセージ追跡機構
はメッセージ追跡ツール２６とは別個のデバイスに実装
することも可能であるが、本例では、これらを単一のデ
バイスに実装する。好適実施例では、メッセージ追跡ツ
ール２６およびメッセージ追跡機構２０を含むメッセー
ジ追跡システムは、従来のコンピュータ・ホスト、例え
ば、ワークステーションに、コンピュータ・ソフトウエ
ア・プログラムによって実装する。このプログラムは、
１枚以上の光ディスクまたはその他のディスク、あるい
はその他の記憶媒体にて供給したり、あるいはコンピュ
ータ・ネットワークを通じて中央記憶場所(central sto
rage location) から供給してもよい。これらのコンピ
ュータ・プログラムは、一旦ホスト・コンピュータのメ
モリ内に保持されると、ホストのプロセッサまたはプロ
セッサ群を制御して、本発明の機能を提供する。メッセ
ージ追跡機構２０は、メモリ内にメッセージ・トラック
・データ構造２２を作成し維持するように構成してあ
る。このメモリとは、通常、メッセージ・トラック・デ
ータ構造が常駐するホスト・コンピュータのメモリであ
る。メッセージ追跡ツール２６は、メッセージ・トラッ
ク・データ構造メモリ２２、およびオプションとしてグ
ラフィック・データベース・メモリ２４とインターフェ
ースする。グラフィック・データベース・メモリ２４
は、メッセージ追跡ツール２６が常駐するホスト・コン
ピュータ上かあるいはどこか他の所に保持することがで
き、そして表示用グラフィック・メッセージ・トラック
・データを収容する１つ以上の表示ファイル２８を作成
し保持するように構成する。また、表示ファイル（群）
は、ホスト・コンピュータの記憶装置内に保持し、ホス
ト・コンピュータの表示装置上に表示したり、遠隔地に
あるコンピュータまたはデバイスに送信しそこで表示す
ることも可能である。

【００２９】メッセージ追跡機構２０およびメッセージ
追跡ツール２６の一方または双方は、従来のコンピュー
タ・ワークステーション、コンピュータ・ネットワーク
・サーバ、メインフレーム・ホスト・コンピュータ、ま
たはホストとして機能する他のあらゆる情報処理ハード
ウエアで実装することができる。記憶要素２２，２４，
２８は、メッセージ追跡機構２０およびメッセージ追跡
ツール２６の一方または双方を実装してある、コンピュ
ータ・システムの主メモリの一部分として実現すること
ができ、主メモリ、バックアップ・メモリ、またはそれ
ら双方の組み合わせでもよい。あるいはまた、１つ以上
の特殊目的のメモリ・ユニットを設けることも可能であ
る。

【００３０】上述のように、好適実施例では、メッセー
ジ追跡機構２０およびメッセージ追跡ツール２６を備え
るメッセージ追跡システム１０は、ソフトウエアによっ
て実現し、ホスト・コンピュータのメモリに記憶して、
このホスト・コンピュータのプロセッサが処理を行う。
しかしながら、代替法として、以下に述べる機能の１つ
以上を、特殊目的のハードウエアによって実行すること
も可能である。

【００３１】図１のメッセージ追跡機構２０の処理の一
例について、図１および図２を参照しながら説明する。

【００３２】図２は、メッセージ追跡機構２０の機能構
成要素を示す機能ブロック図である。

【００３３】メッセージ追跡機構２０は、メッセージ追
跡要求に対する応答から、メッセージ・トラック・デー
タ構造を構築する。これを行うための２つの手法例につ
いてこれより説明する。第１の手法は、メッセージがネ
ットワークを横断する際にステータス通知をすることを
用い、第２の手法では、メッセージのステータスに関し
て後の時点において問い合わせを行うことを用いる。図
２は、双方の手法のための機構の概要である。

【００３４】図１および図２を比較すると、機能Ｆ１．
１は、メッセージ追跡要求の送信を提供し、機能Ｆ１．
２はメッセージ追跡応答（通知）の受信を提供し、機能
Ｆ１．３はメッセージ・トラック・データ構造における
ステータス情報の記憶を提供する。

【００３５】機能Ｆ１．１は、メッセージ追跡応答を要
求する。この機能は、第１例によればメッセージを発す
る時点で実行することができ、あるいは第２例によれば
後の時点で別個のメッセージ追跡要求として実行するこ
とも可能である。２つの例の各々に対する機能Ｆ１．２
については、以下で図４および図５を参照しながら更に
詳細に説明する。機能Ｆ１．２は、メッセージ追跡応答
を待ち、機能Ｆ１．３による処理(handling)のために応
答を受け渡す。機能Ｆ１．３は、この応答に基づいて、
メッセージ・トラック・データ構造２２を作成し保持す
る。

【００３６】データをメッセージ・トラック・データ構
造に記憶するフォーマットは、データ構造の所望の実現
例によって異なる。これは、リンク式リスト(linked li
st)として記憶し、リスト内の種々のエントリをポイン
タ（例えば、図８参照）によって互いにリンクすること
ができる。好ましくは、このメッセージ・トラック・デ
ータ構造は、先に引用したグローバルＭＩＢの拡張とし
て実現する。その方法は、当業者には明白であろう。

【００３７】図４は、第１例によるメッセージ追跡機構
２０の処理を示す。この構成では、初期メッセージＭを
端末Ｔ１から、Ｔ１，Ｔ３の受信者を対象として送信す
る。ここでは、端末とは、単にメッセージの伝送のため
の、メッセージ通信システムのエンド点を意味するに過
ぎない。端末は、従来の意味でのコンピュータ入力端末
とすることができ、あるいは、ワークステーション、そ
の他のタイプの計算機ハードウエアまたはマルチ・ユー
ザ・システム上のユーザ・セッションとすることができ
る。メッセージＭは、ローカル・ホストＮ１において受
信し、ここから更に別のノードＮ２に送信する。ノード
Ｎ２は、メッセージを個々の受信者に分配する役割を担
う。ノードＮ２において、メッセージを２つに分割し、
一方のメッセージＭ’をノードＮ３に送出し、他方のメ
ッセージＭ”をノードＮ４に送出する。ノードＮ３にお
いて、メッセージＭ”を端末Ｔ２に転送する。しかしな
がら、ノードＮ４においては、ノードＮ４および端末Ｔ
３間の送信リンク断線のため、メッセージは転送されな
い。

【００３８】この第１例では、各ノードは、端末Ｔ１に
応答メッセージを送出（通知）し、当該ノードにおける
メッセージＭまたはその派生物Ｍ’，Ｍ”の成り行きを
示すようにプログラムしてある。メッセージに関する出
立ステータス情報(ongoing status information)を返送
するための通知は、ＲＦＣの１８９１ないし１８９４に
詳細に記されているＤＳＮの単純な拡張をベースとする
ことができる。しかしながら、少なくとも以下の情報を
含むのであれば、適切にフォーマットされた任意の応答
メッセージを用いることも可能である。

【００３９】−応答ノードまでの原メッセージの経路、
および −応答ノードにおけるメッセージの現在の処置(disposi
tion)。

【００４０】図４に示すように、ノードＮ１は、応答経
路Ｒを通じて端末Ｔ１に通知を送出して、メッセージＭ
をノードＮ２に転送したことを示す。ノードＮ２は、応
答経路Ｒを通じて通知を端末Ｔ１に送って、メッセージ
Ｍを２つのメッセージＭ’，Ｍ”に分割したことを示す
と共に、メッセージＭ’，Ｍ”に関する通知も送り、こ
れらのメッセージをノードＮ３，Ｎ４にそれぞれ転送し
たことを示す。ノードＮ３は、経路Ｒ’，Ｒを通じて通
知を端末Ｔ１に送り、メッセージＭ’を端末Ｔ２に配信
したことを示す。ノードＮ４は、応答経路Ｒ”，Ｒを通
じて通知を送り、端末Ｔ３に至る通信リンクの障害のた
めに、メッセージＭ”を配信できなかったことを示す。

【００４１】尚、上述の説明では、通知Ｒ，Ｒ’，Ｒ”
を、メッセージＭを送信するのと同じ基本経路に沿って
返送するものとしたが、必ずしもその必要はなく、通知
のルーティングは、アウトバウンド・メッセージ(outbo
und message)に用いる特定ノード以外を経由することも
可能である。これら通知は、メッセージ追跡機構の機能
Ｆ１．２が受信し、通知からの情報は、機能Ｆ１．３に
よってデータ構造２２内に記憶する。

【００４２】各メッセージは、メッセージに対し特定の
（恐らく固有の）識別子によって識別するようにする。
したがって、原メッセージは、その識別子、例えば、４
部分識別子を収容するフィールドを含む。４部分識別子
は、例えば、ホスト＋日付＋時刻＋連番の連結から成
る。Ｍ’，Ｍ”のような派生メッセージは、通常、原メ
ッセージ識別子の派生物を含むような構成とする。ノー
ドは、メッセージ追跡ツールに送出する応答の中に、原
メッセージ識別子またはその派生物のいずれかを含める
ように構成する。

【００４３】派生識別子の生成は、任意の適切なアルゴ
リズムを用いて行うことができる。好ましくは、アウト
バウンド経路にある各ノードでは、原メッセージが当該
ポイントまでの全追跡を含み、そしてそのメッセージに
は、関係するノードにおいてそのステータスを追加して
いく。したがって、各通知は、応答を送出するポイント
までの特定経路に沿った、アウトバウンド・メッセージ
の履歴全てを含むことができる。これは、それ自体で、
正しい応答メッセージを識別するために用いることがで
きる。実際、メッセージ追跡機構の機能Ｆ１．３は、通
知内の履歴データに尋問を行い、データ構造２２を正し
く順序付けるように構成することが好ましい。こうすれ
ば、連続的に通知を受信する場合、これらが順序通りに
到達しなくとも、メッセージ追跡機構は、個々のメッセ
ージ応答を正しく順序付け、これによってそれらのメッ
セージから正しくデータ構造を形成することができる。

【００４４】このように、機能Ｆ１．２はユーザのメッ
セージ・インボックス(message inbox)を監視し、そし
て識別子を用いて、原メッセージに関係した通知を識別
する。通知を受信したなら、その通知を機能Ｆ１．３に
受け渡し、機能Ｆ１．３はこの通知を検査し、そしてそ
の通知からの情報を、送出した原メッセージについての
メッセージ・トラック・データ構造に追加する。

【００４５】受信した各通知に対して、機能Ｆ１．３
は、 −既存のメッセージ・トラック・データ構造を明らかに
するか、あるいは当該通知が関係するメッセージに関連
した、新たなツリー状メッセージ・トラック・データ構
造のためのルート・ノードを作成し、 −メッセージ・トラック・データ構造を辿っていくこと
により、ノード毎に、通知内の原メッセージの経路を検
査し、 −メッセージ・トラック・データ構造内にノードが存在
しない場合、空ノードを作成し、現エンド・ノード（Ｄ
ＳＮを送出したノード）において、メッセージのステー
タスを追加または更新する。

【００４６】この通知は、情報をメッセージ・トラック
・データ構造に追加した後には、破棄することができ
る。

【００４７】図５は、メッセージ・トラック・データ構
造を構築するための代わりの手法である。図５において
は、同一の基本メッセージを端末Ｔ１から送出して、端
末Ｔ２，Ｔ３に配信しようとするものとする。図４の例
におけるのと同様、派生メッセージＭ’は端末Ｔ２への
配信に成功するが、派生メッセージＭ”は端末Ｔ３に配
信されない。

【００４８】この手法では、各ノードを経由するメッセ
ージ送信全ての記録を、メッセージを送信する際に、リ
アル・タイムで各ノードに記憶する。このようにして、
ノードＮ１では、レコードＲ１を作り、当該ノードのメ
モリに記憶する。ノードＮ２では、レコードＲ２を作成
し、メモリに記憶する。同様に、ノードＮ３，Ｎ４で
は、各レコードＲ３，Ｒ４を作り、それらのノードに記
憶する。

【００４９】従来のメモリ管理技法を用いて、個々のノ
ードに記憶したレコードの管理を行うことができ、必要
であれば、所定時間の後レコードを削除する。例えば、
ユーザの要求に応じて、異なるユーザには異なる記憶時
間を与えることも可能であろう。

【００５０】この手法により、システムの端末Ｔ１のユ
ーザ、または、許可されるのであれば他のユーザは、メ
ッセージＭを追跡することを要求することができる。こ
れを行うために、メッセージ追跡マネージャ２０は、追
跡要求ＴＲ（原メッセージＭに対する識別子を含む）、
およびこれが追跡要求であることを示す別の識別子を発
する。この追跡要求は、原メッセージＭと同じ経路を辿
り、ノードＮ２における派生追跡要求ＴＲ’，ＴＲ”へ
の分割が含まれる。追跡要求は、システム内の各ノード
では、原メッセージに関して記憶されている情報を識別
する要求として解釈され、そしてこの時点で、ＴＲＲ，
ＴＲＲ’，ＴＲＲ”で表す追跡応答経路を通じて、応答
メッセージ（通知）を端末Ｔ１に送出する。図４の例に
ついてと同様、通知（応答）は、メッセージＭと同じ経
路を辿る必要はないが、実際面では、そうなる可能性が
高い。

【００５１】したがって、この第２手法では、関心のあ
る者は、e-mailメッセージのステータスについて、メッ
セージ送出後の後の時点で問い合わせをすることができ
る。メッセージの最終的な処置を明らかにするために
は、当該メッセージのメッセージ・トラックに沿った各
メッセージ・ルータに問い合わせをしなければならな
い。次いで、第１手法と同様に、メッセージ・トラック
・データ構造を構築する。

【００５２】メッセージ追跡ツール２６を用いて、問題
のメッセージを探し始める場所を特定するために用いる
情報について、ユーザに問い合わせをすることができ
る。これは、例えば、メッセージのメッセージＩＤ、そ
れが誰に送出されたか、主題(subject)、送出した日時
等とすることができる。

【００５３】メッセージ追跡機構ツール２６は、メッセ
ージ識別情報を含むメッセージ追跡要求を準備し、これ
をメッセージ追跡機構２０に送出する。次に、これは、
メッセージの最初の送出先であるメッセージ・ルータ
に、メッセージ追跡要求を送出する。このメッセージ・
ルータは通常は分かっている。なぜなら、原メッセージ
をその行程上の最初の（そして恐らく最後の）ホップで
どこに送出するかについて知っているからである。

【００５４】メッセージ・ルータは、１つ以上の応答
で、この要求に答える。応答が２以上のメッセージの詳
細を記している場合、ユーザは、（恐らく、返送された
リストからの固有のメッセージＩＤの内の１つを用いる
ことによってでも）一層特定した問い合わせを作成する
ことによって、その検索を狭めることができる。

【００５５】これら最上位の応答は、１つ以上のメッセ
ージに対するメッセージ・トラック・データ構造におけ
る、トップ・ノード即ちルート・ノード(root node)と
なる。

【００５６】返送された応答が、メッセージの最終結果
の詳細を記していない場合（例えば、メッセージが、更
に配信されるために他のノードまたはノード群に渡され
たため）、メッセージ追跡機構は、更に別の要求を用い
てこのノードまたはノード群に問い合わせをすることが
できる。これらの要求に対する応答は、階層型メッセー
ジ・トラック・データ構造において、このノードの子ノ
ード(child node)となる。メッセージ・トラック・デー
タ構造については、後に更に詳細に説明する。

【００５７】各ノードにおいて、メッセージの処置（即
ち、ステータス）を見出す（例えば、転送済み、配信さ
れず、等）。各ノードからのこの情報は、メッセージ・
トラック・データ構造に追加する。要求および応答のト
ラックを保持して、どの応答がどの要求から来たのかを
判定できるようにする。応答は、メッセージ・トラック
・データ構造において、その要求の子(children)とな
る。

【００５８】上述のように、メッセージ追跡要求は、追
跡すべき原メッセージの識別子を含むことが好ましい。
メッセージ追跡要求は、それ自体の識別子を有するフィ
ールドを含み、この識別子は、原メッセージ識別子の派
生物とすることも可能である。したがって、メッセージ
追跡要求に対する応答は、メッセージ追跡要求の識別子
またはその派生物を含むことが好ましい。

【００５９】情報処理ネットワーク全体を通じて一貫性
を得るために、種々の要求および応答を実施する際、標
準的なＳＮＭＰ手続きにしたがうことが好ましい。個々
のノードには、ネットワーク管理ソフトウエアを備え、
これがＳＮＭＰ要求に応答して必要な処理を実行し、そ
して要求されたデータを含む応答を返送する。ＳＮＭＰ
管理技法は、当業者には良く知られている。メッセージ
追跡要求は、例えば、ＳＮＭＰ GET処理として送り、そ
れに対する応答はＳＮＭＰ GET-RESPONSE処理として送
ることができる。

【００６０】双方の手続きは、前述のメッセージ・トラ
ック・データ構造を用いることができるが、第２の手法
では、問い合わせ要求を問い合わせ応答と合致させる。
第１の手法では、応答は、応答ノードからの経路を含
み、その応答データがどこに行くのかを識別する。メッ
セージ・トラック・データ構造は、実際には、原メッセ
ージを送信したノードに対応するノードを含む。

【００６１】例えば、メッセージをmary@nodecに送り、
次いでnodeaからnodebに送り、最終的にnodecによって
ユーザに配信した場合、対応するメッセージ・トラック
・データ構造は、図６に示す機能的構造を有することが
できる。

【００６２】メッセージ・トラック・データ構造におけ
る各ノードでは、メッセージに関する情報を記憶するこ
とができる。例えば、いつメッセージがそのノードに到
達したか、いつそれを回送したか、そしてどこでエラー
が発生したか、エラーが発生したか否か、あるいは当該
メッセージの処理にかかった処理時間はどれくらいだっ
たかに関しても、記憶することができる。

【００６３】原メッセージを２人以上の受信者に送出し
た場合、メッセージ・トラック・データ構造は、メッセ
ージ分割後の各ノード毎に別個のブランチを含む。全て
の受信者が同じノード上にある場合、メッセージ・トラ
ック・データ構造は、図６に示すようになる。メッセー
ジのメッセージ・トラックにおけるあるポイントにおい
て、受信者の内の１人以上が異なるノード上にある場
合、メッセージ・トラック・データ構造では分岐が生ず
る。例えば、メッセージをjoe@nodec2に送るが、ノード
nodec1，nodec2双方に至る経路にnodebを用いる場合、
メッセージ・トラック・データ構造は、図７に示す一般
的形態を有することができる。

【００６４】上述のようにメッセージ・トラック・デー
タ構造を分割することができる別のイベントに、メーリ
ング・リストへのメッセージの送出がある。例えば、ユ
ーザがメールをlist@nodebに送り、nodebがそのリスト
を２人の受信者joe@nodec1，mary@nodec2に展開した場
合も、メッセージ・トラック・データ構造は、構造内の
情報が異なることを除いて、図７にあるような形態とな
る。この情報は、nodeaにおいて、メッセージがnodeaお
よびnodebにおいて１人の受信者に送られ、nodebは"lis
t"と称する受信者を展開して、２つのメッセージの内一
方をnodec1に他方をnodec2に配信した、ということを示
す。

【００６５】データ構造のリーフ(leaf：葉)は、当該メ
ッセージについて最後に知ったステータスである。この
ステータスは、以下のような多数の理由により、不完全
な場合があり得る。 −ＤＳＮ（Delivery Status Notification:配信ステー
タス通知）またはその他の非問い合わせ型ステータス・
メッセージを用いる場合、メッセージを現在有するノー
ドがまだ応答をしていない場合、または全く応答がなく
メッセージのステータスが得られない場合がある。 −メッセージを送出した後の問い合わせの場合、問い合
わせされるノードが問い合わせ機構に対応していない場
合、あるいは問い合わせされた特定のメッセージに関す
る情報をもはや有していない場合がある。

【００６６】このような場合、メッセージ・トラック・
データ構造は、情報のないノードを含む可能性がある
（恐らく、ノード名を除いて）。これら空ノード下にあ
る情報は、後に受信または問い合わせされた他の情報か
ら充填することができる。

【００６７】各ノードには、１つ以上のステータス即ち
処置メッセージがあり得る。これらのステータス・メッ
セージは、当該メッセージがそのノードにあったときに
何が発生したのかについて記述する。これらのメッセー
ジは以下の内容を含むことが考えられる。 −メッセージが配信された。 −メッセージが配信できなかったこと、およびその理
由。 −受信者がリストであり、そのリストを何に対して展開
したかについて。 −メッセージを他のノードまたはノード群に移送したこ
と。 −受信者のメールを他の受信者に転送したこと。 −メッセージが現在あるノード上での処理を待っている
こと、およびその理由。 −ステータスが不明であること。

【００６８】原メッセージを配信することができず、発
信者に返送された場合、これをリーフ・ノードとする
か、あるいは、構造を継続することによって元のユーザ
に戻る経路を含ませることができる。

【００６９】メッセージ・トラック・データ構造におけ
る各ノードに含ませることができる他の情報には、以下
のものが考えられる。

【００７０】−メッセージを送出した先の次のノードま
たはノード群（これは、ツリーにおいてリーフに向かう
ポインタである）。 −ツリー内の以前のノード（これは、ルート(root：根)
に向かうポインタである）。 −メッセージが到達した時刻。 −メッセージ（群）がノードを出発した時刻（群）。 −メッセージのサイズ。 −メッセージの優先度。 −個々のメッセージを識別する識別子。 −インバウンドおよびアウトバウンドの発信者。 −インバウンドおよびアウトバウンドの受信者（群）。 −主題。 −メッセージのタイプ。 −メッセージに関するその他の任意の情報。

【００７１】好適な実現例では、メッセージ・トラック
・データ構造の各ノードは以下の情報を含む。 −ホスト名：情報が出てきたメール・ルータの名称。 −エラー：情報のためにホストと接触してエラーが発生
した場合、エラー・メッセージを含む文字列（これは、
ローカル・エラー・メッセージである）。 −要求：ツリー内のこのポイントより下にあるノード集
合を作成するために要求された情報。 −応答：このノードから返送された情報。 −親：親のメッセージ・トラック・データ構造ノードへ
のポインタ。 −第１の子：このノードに対する子集合へのポインタ。 −次の子：このノードの兄弟集合へのポインタ。

【００７２】この構造をツリー状とすることができるの
は、親、第１の子、および次の子ポインタである。親
は、常に、ツリーの上流側の、現ノードを指しているノ
ードを指す。第１の子は、メッセージのトラックの下流
側のノードのリンク式リストへのポインタである。これ
は、ノードからノードにホッピングするメッセージであ
る。次の子は、このノードに対する兄弟である子のリン
ク式リストを示す。これは、分岐またはその他の分割の
場合に用いる。各々別個のメッセージ・トラックを有す
る３人の受信者にメッセージを送る場合、作成されるリ
ンクは、図８に示す構造によって例示することができ
る。

【００７３】図８は、３人の受信者を有するメッセージ
に関するトラックを示す。３人の受信者は、３つの別個
のノード、即ち、nodec 上に１カ所、nodea上に１カ
所、およびnodeｂ上に第３のノードがある。この場合、
ルート・ノードは３つの兄弟で構成される。何故なら、
メッセージは発信時に分割するからである。実際、ルー
ト・ノードは、この場合では、初期の問い合わせであ
り、３つの子を有し、これらは３つのルート兄弟(root
sibling)である。図８の構造は、図９におけるように表
現することも可能である。

【００７４】好適な実現例におけるメッセージ・トラッ
ク・データ構造の要求構造部分は、以下のフィールドを
備えている。 −インデックス：要求を応答と合致させるための番号。 −ステータス：表内の行を制御するために用いる。 −応答ステータス：問い合わせのステータスを示す。 −最大応答数：返送すべき応答の最大数。 −アプリケーション・インデックス：RFC-1565 applTab
le MIB内へのインデックスのためのオプションの値。 −固有のｍｓｇＩＤ：メッセージ・ルータが内部的に用
いる固有のメッセージＩＤ。 −インバウンドｍｓｇＩＤ：メッセージ・ルータが受信
する際の固有のメッセージＩＤ。 −アウトバウンドｍｇｓＩＤ：メッセージ・ルータが送
出する際の固有のメッセージＩＤ。 −インバウンド発信者：受信形態のメッセージの発信
者。 −アウトバウンド発信者：送信形態のメッセージの発信
者。 −発信者名称形式：直ぐ上の２つのフィールド（インバ
ウンド発信者、アウトバウンド発信者）における発信者
の形式。 −インバウンド受信者（群）：受信形態のメッセージの
受信者（群）。 −アウトバウンド受信者（群）：送信形態のメッセージ
の受信者（群）。 −受信者（群）名称形式：直ぐ上の２つのフィールド
（インバウンド受信者（群）、アウトバウンド受信者
（群））における受信者（群）の形式。 −主題：メッセージの主題。 −最小サイズ：要求するメッセージの最小サイズ。 −最大サイズ：要求するメッセージの最大サイズ。 −最早到達時刻：要求するメッセージの最も早い到達時
刻。 −最遅到達時刻：要求するメッセージの最も遅い到達時
刻。 −処置：追跡するメッセージに関して何がされたか。 −障害理由：何故問い合わせに障害が発生したか（これ
は、遠隔エラー・メッセージである）。 −タイプ：追跡するメッセージのタイプ。 −コラプス受信者(collapse recipienets)：所与のメッ
セージに対する単一の受信者のみに返送させる要求。

【００７５】どのメッセージを追跡すべきかを選択する
際に用いるのは、要求構造である。これらフィールドの
１つあるいはそれ以上を埋めることができる。空白のま
ま残したフィールドは、ワイルド・カードとなる。

【００７６】検索の結果は、応答構造で返送する。好適
な実現例の応答構造は、以下のフィールドを備えてい
る。 −インデックス：上述の要求構造におけるインデックス
と一致する。 −処置：メッセージの処置（ステータス）。 −処置時刻：メッセージを処置したとき。 −次のホップ：メッセージを送った先のメッセージ・ル
ータの名称。 −前のホップ：メッセージが来た元のメッセージ・ルー
タの名称。 −非配信理由：メッセージが配信されなかった理由。 −到達時刻：メッセージがこのメッセージ・ルータに到
達した時刻。 −サイズ：メッセージのサイズ。 −優先度：メッセージの優先度。 −固有のｍｓｇＩＤ：メッセージ・ルータが内部で使用
する固有のメッセージＩＤ。 −インバウンドｍｓｇＩＤ：メッセージ・ルータが受信
する際の固有のメッセージＩＤ。 −アウトバウンドｍｇｓＩＤ：メッセージ・ルータが送
出する際の固有のメッセージＩＤ。 −インバウンド発信者：受信形態のメッセージの発信
者。 −アウトバウンド発信者：送信形態のメッセージの発信
者。 −インバウンド受信者（群）：受信形態のメッセージの
受信者（群）。 −アウトバウンド受信者（群）：送信形態のメッセージ
の受信者（群）。 −補足情報：ノードが提供する補足情報。 −主題：メッセージの主題。 −タイプ：メッセージのタイプ。

【００７７】これらの要求構造および応答構造は、Lotu
s社によってドキュメント作成され、メッセージを追跡
するためＳＮＭＰ ＭＩＢに関するＥＭＡ（electric M
ailAssociation：電子メール協会）の会合において紹介
された、ＳＮＭＰ ＭＩＢをベースとする。ＭＩＢは、
１９９５年５月に、"Message Management Implementor'
s Guide: Monitoring and Message Tracking"と題す
る、ＥＭＡによるペーパーバックの本において、最初に
公表されたものである。

【００７８】要求および応答は各ノードに保持する。要
求は、要求の間にエラーが発生した場合、そのエラー・
メッセージを記憶するので有用である。これによって、
メッセージ・トラック・データ構造を表示する際に、以
下で述べるように、エラーを示すことができる。

【００７９】１つの要求を行い、１つ以上の応答を受信
する。１つのノードからの各応答は兄弟であり、その要
求の子である。好適な実現例では、ルート要求を含むル
ート・ノードがあり、応答はその子となる。

【００８０】一旦メッセージ・トラック・データ構造の
ある部分または全体を作成したなら、それを表示するこ
とができる。好適実施例では、定着ツリー図(rooted tr
ee diagram)を形成する。この図では、ツリーのルート
は、メッセージを発信したノードであり、リーフ・ノー
ドは、受信した情報の内最後にわかった情報の送出者の
ノードである。各ノードは、グラフィック状のアイコン
で表すことができるので、メッセージがネットワークを
横断した際にメッセージに何が発生したか、または要求
に何が発生したかが容易にわかるようになる。ツリー
は、折り畳む（または剪定する）ことができるので、複
雑なメッセージ・トラック・データ構造を断片毎に見る
ことができる。また、ツリーは、メッセージ配信に失敗
した場合、または保留となっている場合にのみを表示す
るように剪定することも可能である。メッセージ・トラ
ックは、グラフィック・ウィンドウ内に表示することが
好ましいが、リストとして見ることも可能である。

【００８１】即ち、ここで図３を参照すると、メッセー
ジ追跡手続きの結果を表示することが望ましい場合、一
実施例では、機能ユニットＦ２が、グラフィック・デー
タベース２４からのデータおよび追跡すべき特定のメッ
セージに対するメッセージ・トラック・データ構造から
のデータにアクセスする。メッセージ・トラック・デー
タ構造２２は、複数の個々のメッセージに対する複数の
個々のデータ構造を収容可能であることは分かるであろ
う。グラフィック・データベース２４は、情報処理シス
テム内の種々のノードにおいて発生し得る処理を表すた
め、およびこれらノード間の接続または１つのノード内
の個々の処理間の接続を表すため、アイコンおよび個々
のアイコンを接続する接続構造を含む。アイコンおよび
その他のグラフィック要素のために記憶したグラフィッ
ク・データベースを用いる代わりとして、グラフィック
表示のためのグラフィック要素は、処理進行中に生成す
ることも可能である。

【００８２】メッセージ・トラック・データ構造は、個
々のノードにおいて実行する処理を表すデータを含むの
で、機能ユニットＦ３は、選択したメッセージについて
のメッセージ履歴のグラフィック表現を構築すること、
および関心のあるメッセージ履歴のグラフィック表現を
含む表示ファイル２８を生成することができる。好まし
くは、グラフィック表現は、全体としてフロー図の形態
とし、個々のブロック（例えば、ブロックＢ１，Ｂ２，
Ｂ３，Ｂ４，Ｂ５）が、メッセージ通信履歴内の各段階
において実行する処理を表すアイコン、それら処理を実
行するノードおよび／または特定のメッセージまたは関
連する派生メッセージの意図した受信者を識別するデー
タＤ、および／またはその他のデータを含む。個々のブ
ロックＢは、好ましくは、矢印またはその他のリンク・
デバイスＡ１，Ａ２，Ａ３，Ａ４によって接続して、こ
れらブロック間の流れを示す。

【００８３】グラフィック表現の一例を図１０に示す。
図１０に示すように、この表現は、実質的に二次元ツリ
ー状表現であるが、代わりの一次元表現あるいは三次元
またはそれ以上の次元の表現も使用可能である。図１０
におけるような二次元表現は、二次元表示画面上に、特
に理解が容易な表現を与える。

【００８４】好ましくは、個々のアイコンＩは、容易に
理解可能な方法で、メッセージ構造内の個々のポイント
において実行する処理を表現するようにする。例えば、
アイコンＩ１はメッセージを転送したことを示す。アイ
コンＩ２は、メッセージを複数のメッセージに分割した
ことを示す。Ｉ３は、メッセージの配信に成功したこと
を示す。アイコンＩ４は、それ以上メッセージの送信が
不可能であることを示す。

【００８５】メッセージ・トラック・データ構造は、ブ
ロックＢ１〜Ｂ５の各々について、その処理の性質を更
に詳細に指定するコードまたはテキスト情報を含む、追
加情報を含むことが好ましい。図示のアイコンは、単に
可能なアイコンの例示に過ぎない。他の異なる状態を表
現することが望ましい場合もあり、その際には、適切な
アイコンを選択すればよい。図１０に表したアイコンに
関して、関連する機能の特定のアイコン表現は、設計上
の選択事項である。

【００８６】また、標準的なグラフィカル・ユーザ・イ
ンターフェース技法を用いて、グラフィック表現の拡大
および／または縮小を行い、ワークステーションのモニ
タ上における一表示画面内のグラフィック表現の表示を
容易にすることも可能である。したがって、例えば、表
示画面上のポインタＰとマウスまたはその他のユーザ入
力デバイスとを用いて、ユーザが特定のブロックを識別
し、そしてデータ構造のより多くの部分を含ませること
によって（例えば、１つのブロックを複数のブロックお
よびリンクに分割して、あるノードにおける個々のプロ
セスを更に詳細に示すことによって）ブロックを展開す
ることを要求したり、あるいは当該ブロックに関して実
行する処理の更に詳細なテキスト表現を与えることが可
能となる。

【００８７】図１１は、ブロックＢ３を更に別のブロッ
クＢ３．１，Ｂ３．２，Ｂ３．３に展開した場合を表
す。ブロックＢ３．１は、関係するメッセージの分岐を
表し、ブロックＢ３．２，Ｂ３．３は、図４および図５
に示したような派生メッセージＭ’，Ｍ”の個々の送信
を表す。

【００８８】グラフィカル・ツリーを用いて、メッセー
ジのトラックおよびメッセージの処置を同時に示すこと
が可能であることが認められよう。ツリーのルートは、
メッセージの提出(submission)とすることができる。ま
た、メッセージのトラックがメッセージ・トラックに沿
った途中から開始する場合、ツリーのルートをメッセー
ジの追跡を開始する場所とすることも可能である。ツリ
ー内の各ノードは、メッセージ配信の各段階におけるメ
ッセージの処理を表す。

【００８９】好適な実現例では、Ｘウィンドウズを用い
る。Ｘウィンドウズ内では、“TheAthena Widgets”と
称するツールキットがある。Athenea Widgets内には、
ツリー・ウイジェット(tree widget)がある。ツリー・
ウイジェットについては、Oreilly & Associates, Inc.
からの“X Toolkit Intrinsics Reference Manual”第
５巻に記載されている。ツリー・ウイジェットは、他の
ウイジェットをそれに追加させることができる（この場
合は、ボックスを追加する）。ツリー・ウイジェットを
レイアウトする際、従属ウイジェットを接続ツリー(con
nected tree)内に組み入れ、これらの間に線を引き、ウ
ィンドウの一縁に定着させる。

【００９０】いかにしてツリーをレイアウトするかにつ
いて、以下に述べる。 −ツリー・ウイジェットを作成する。 −ツリーのトップ・ノードを作成する。メッセージ・ト
ラック・データ構造のトップノードから見て、前のホッ
プがない場合、メッセージが提出されたことを示すアイ
コンを作成する。前のホップがある場合、メッセージが
前のノードから移送されたことを示す。これが、グラフ
ィック表現におけるルート・ノードになる。 −各兄弟（次の子のリンク・リスト）に対して、親引数
として作成したルート・ウイジェットを用いて作成した
ばかりの親に接続した、サブツリー（以下で詳細に説明
する）を作成する。 −XawTreeForceLayout関数をコールし、これは、グラフ
ィック・バッファ内でノードをレイアウトする。

【００９１】サブツリーの作成は以下のように行う（親
ウイジェットを引数として渡す）。 −このノードが応答を有する場合、ノードを作成する
（以下で説明する）。その他の場合、「不明」というラ
ベルのアイコンを有するノードを作成して、ギャップを
埋める。 −これが応答を有さない（恐らく、エラーが発生した）
テール・ノード（子がないノード）である場合、これに
適したアイコンを示し、そして戻る。 −このノードの各々の子について、繰り返しこの関数を
コールして、ツリーの残り部分を構築する。

【００９２】各ノードは、以下のように作成する（親ウ
イジェットを引数として渡す）。 −ボックスを作成する。ボックスのparentWidgetを親ウ
イジェットにセットする。 −ボックス内において、アイコンおよび２つのテキスト
・ラベルを作成する。アイコンはメッセージの処置によ
って異なる。第１のテキスト・ラベルはノードの名称で
あり、第２のテキスト・ラベルは受信者（群）の名称
（群）である。 −各ボックスをツリーに追加する際、コールバックを取
り付けて、メニューをそれに付加することによって、ツ
リーのブランチの拡大または縮小を行うか、あるいはよ
り詳細な情報を得るようにする（ボックス上でダブル・
クリックすることによって）。

【００９３】上述のように、アイコンの形の問題は、設
計上の選択の問題である。一例では、アイコンは図１２
に概略的に示すようなものとすることも可能である。図
１２では、 −アイコン１２Ａは、メール・ボックス内に落下する手
紙の図によって「提出された」処置を表す。 −アイコン１２Ｂは、手紙を別の場所に移転するトラッ
クの図によって「移転された」処置を示す。 −アイコン１２Ｃは、メールボックス内の手紙の図柄に
よって「配信された」処置を示す。 −アイコン１２Ｄは、手紙を再送出または転送する手の
図によって、「再送出された」処置を表す。 −アイコン１２Ｅは、１つの手紙を分割する図によっ
て、「配信リスト展開」処置を表す。 −アイコン１２Ｆは、キュー内で待っている手紙の図に
よって、「待ち行列に入れられた」処置を表す。 −アイコン１２Ｇは、メッセージのトラック終了のため
の、「ＳＮＭＰ離脱」（すなわち、ＳＮＭＰ管理テリト
リからの離脱）を表す。 −アイコン１２Ｈは、情報が得られない場合に対する、
「不明」処置を表す。

【００９４】各ボックス（そのアイコンおよびテキスト
・ラベルを有する）をツリーに追加する毎に、その親を
セットする。XawTreeForceLayoutをコールすると、実際
にツリーを描き、ウィンドウ内にレイアウトする。ツリ
ーはウィンドウよりも大きい可能性がある。ツリーを含
むウィンドウはスクロール可能である。

【００９５】詳細情報は、応答構造内の情報である。こ
の情報は大量過ぎてグラフにもリストにも入り切らない
ので、この情報を得る手段を備えることが必要となる。
これは、各々しかるべきラベルを付けたフィールドを有
する形式で表示する。これは、ツリー内のボックス上で
ダブル・クリックすることによって画面上に表示させ
る。

【００９６】ツリーをこのように実現した場合、このツ
リーをウィンドウのいずれかの辺に取り付けることがで
きる。好適な実現例では、上の辺を選択した。

【００９７】代替のリスト表現では、以下の情報を、メ
ッセージ・トラックのリスト表現の各行に与える。 −受信者（群）：最初の数人のメッセージ受信者。 −処置：メッセージの処置。 −到達時刻：メッセージ・ルータに到達した時刻メッセ
ージ。 −エラー：発生したあらゆるエラー。

【００９８】これ以上の情報が利用可能な場合（エント
リの下に更にノードがある）、リストを強調表示し、ユ
ーザが「ドリル・ダウン(drilldown)」へのエントリ上
で選択／ダブル・クリックし、ツリー内の次のレベルか
ら情報が得られることを示すようにする。

【００９９】このようなリストの望ましくない制約の１
つとして、ユーザは、各メッセージの処置を明らかにす
るためには、ドリル・ダウンする、即ち、手動の深度第
一検索(manual depth first search)を行う必要がある
ことがあげられる。

【０１００】情報をリストで表示する別の可能な方法
は、情報をリーフ・ノード上のみで表示することであ
る。これは、各メッセージについて掘り下げる必要がな
く、当該メッセージに実際に何が発生したかについての
詳細が一目で分かる点で最も効果的であるが、実際にど
のように物事が起きたかについては明らかでない場合が
ある。この場合、「アンドリル(undrill)」即ちツリー
をルートに向かって見上げることによってメッセージの
履歴全体を見ることができると効果的である。これを達
成するには、ウィンドウ・システムにおいて種々の技法
を用いることができる。即ち、ルートに到達するまで何
回でもダブル・クリックし、ユーザがマウス・ボタンを
押したときに、ユーザにリストを提示したり、あるいは
別のウィンドウを用いて履歴を示すことも可能である。

【０１０１】また、メッセージ履歴は、「折り畳み式ツ
リー(folding tree)」として示すことも可能である。こ
れは、グラフィック・ツリーおよびリストの間の混成の
ようなものである。折り畳み式ツリー内の各項目は、折
り畳むことによってその下の複雑な構造を隠すことがで
きるが、各項目は、Windows 3.1におけるファイル・マ
ネージャの場合のような、１行のテキストまたは非常に
小さい単純なアイコン、あるいはその双方である。

【０１０２】図１３は、メッセージ追跡機構およびメッ
セージ追跡ツールをネットワーク通信アプリケーション
の一部として実現可能なワークステーションの概略図で
ある。ネットワーク通信アプリケーションは、ワークス
テーション４０のメモリ４３に記憶し、ワークステーシ
ョン４０のプロセッサ４１によって実行することができ
る。図１３に示すように、ワークステーションは、シス
テム・ユニット４２、ユーザ入力デバイス４４，４５、
表示装置４６、並びに通信アダプタ、バックアップ記憶
装置などを含む図示しない他のデバイスを備えている。
図１３では、図１０のグラフィック表現３８を、表示装
置の一ウィンドウ内に示す。別のウィンドウ３６には、
追跡したメッセージのリストを示す。リスト３６内の各
エントリには、メッセージ・トラック・データ構造を関
連付け、このデータ構造は、メッセージ・トラック・デ
ータ・メモリ２２に記憶してある。

【０１０３】ブロック３４は、例えば、マウス４５の制
御の下でポインタＰを使ってグラフィック表現３８上で
識別したブロックのテキスト記述を与えるために用い
る。

【０１０４】以上、情報ネットワーク（例えば、インタ
ーネット）上のメッセージのトラックを、容易に理解で
きしかも容易に操作できるような方法で、ユーザに提示
可能とする方法および装置の一実施例について説明し
た。この実施例では、メッセージのトラックから得たデ
ータを含むメッセージ・トラック・データ構造を構築す
る。次いで、これをグラフィック要素のためのグラフィ
ック・データベースと共に用いて、ユーザに表示するた
めに、メッセージ・トラックのグラフィック表現を生成
することができる。代替法として、グラフィック要素
は、処理しながら作成することも可能である。メッセー
ジ・トラック・データ構造を構築する際、メッセージ・
トラック内のノードに対するエントリを作成し、このエ
ントリには、当該ノードにおけるメッセージ・ステータ
スを定めるデータを含ませる。ノードおよびノードを接
続する接続要素のグラフィック表現、およびノードにお
けるメッセージ・ステータスのアイコン表現には、グラ
フィック・データベースにおいてアクセスして、メッセ
ージ・トラックのグラフィック表現を生成することがで
きる。あるいは、このグラフィック表現は、処理進行中
に作成することも可能である。ノードのグラフィック表
現に、テキスト情報を追加することも可能である。メッ
セージの追跡は、メッセージ送信と同時に行うことがで
き、あるいは、メッセージ追跡要求に応答して後の時点
に行うことも可能である。

【０１０５】これまで本発明の特定の実施例について説
明してきたが、理解されるように、本発明はこれに限定
される訳ではなく、特許請求の範囲に定めた本発明の精
神および範囲内において、多くの変更および／または追
加も可能である。例えば、具体的に列挙したもの以外の
従属項の特徴の異なる組み合わせを、本発明の特定実施
例における独立項の特徴と組み合わせることも可能であ
る。

【図面の簡単な説明】

【図１】本発明の一実施例によるメッセージ追跡ツール
の概略ブロック図。

【図２】メッセージ追跡ツールの一処理モードの概要を
与える機能図。

【図３】図２の詳細図。

【図４】メッセージ・トラック・データ構造を構築する
一方法を説明するための概略ブロック図。

【図５】図４の代替法を示す図。

【図６】簡略メッセージ・トラックの一例の概略図。

【図７】１つのブランチを有するメッセージ・トラック
の一例の概略図。

【図８】メッセージ・トラック・データ構造の一例の概
略図。

【図９】図８のメッセージ・トラック・データ構造が表
すメッセージ・トラックを示す図。

【図１０】メッセージを追跡した結果として可能なグラ
フィック表示の概略図。

【図１１】図１０のグラフィック表示を展開した変形例
の概略図。

【図１２】本発明の一実施例で用いることができるアイ
コンの例を示す図。

【図１３】本発明の一実施例によるメッセージ追跡ツー
ルが生成する種々の画面を表示する、ユーザのワークス
テーションの概略図。

【符号の説明】

１０ メッセージ追跡システム ２０ メッセージ追跡機構 ２２ メッセージ・トラック・データ構造メモリ ２４ グラフィック・データベース・メモリ ２６ メッセージ追跡ツール ２８ 表示ファイル ３６ 追跡メッセージのリストのウィンドウ ３８ グラフィック表現 ４１ プロセッサ ４３ メモリ ４４ ユーザ入力デバイス ４６ 表示装置 Ａ１〜Ａ４ リンク・デバイス Ｂ１〜Ｂ５ ブロック Ｆ１〜Ｆ４ 機能 Ｉ１〜Ｉ４ アイコン Ｍ’，Ｍ” 派生メッセージ Ｎ１〜Ｎ４ ノード Ｒ１〜Ｒ４ レコード Ｔ１〜Ｔ３ 端末 ＴＲ 追跡要求 ＴＲ’，ＴＲ” 派生追跡要求 ＴＲＲ，ＴＲＲ’，ＴＲＲ” 追跡応答経路

───────────────────────────────────────────────────── フロントページの続き (71)出願人 597004720 2550 Ｇａｒｃｉａ Ａｖｅｎｕｅ，ＭＳ ＰＡＬ１−521，Ｍｏｕｎｔａｉｎ Ｖ ｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

Claims (38)

【特許請求の範囲】
1. 【請求項１】情報ネットワーク上に送出したメッセージ
   を追跡する方法であって、 ａ） メッセージのトラック内のノードからのステータ
   ス・データを含むメッセージ・トラック・データ構造を
   構築するステップと、 ｂ） 前記メッセージ・トラック・ステータス・データ
   から、前記メッセージ・トラックのグラフィック表現を
   生成するステップであって、前記グラフィック表現が、
   前記ノードにおける前記ステータス・データを表すグラ
   フィック要素を含み、前記グラフィック要素は相互に配
   列して前記メッセージ・トラックを表す、前記のステッ
   プと、から成るメッセージ追跡方法。
2. 【請求項２】請求項１記載の方法において、ステップｂ
   が、 前記ステータス・データに応答して、前記グラフィック
   要素を生成するため、前記ノードにおけるメッセージ・
   ステータスのアイコン表現のパレットにアクセスするス
   テップ、を含むこと、を特徴とするメッセージ追跡方
   法。
3. 【請求項３】請求項１記載の方法において、ステップｂ
   が、 前記ステータス・データに応答して、前記ノードにおけ
   る前記メッセージ・ステータスを表すため、グラフィッ
   ク要素を処理の進行中に生成するステップ、を含むこ
   と、を特徴とするメッセージ追跡方法。
4. 【請求項４】請求項１記載の方法において、前記ステッ
   プｂが、 グラフィック要素の階層を生成して、各グラフィック要
   素が前記ノードの１つにおけるメッセージ・ステータス
   をグラフィック的に表すステップ、を含むこと、を特徴
   とするメッセージ追跡方法。
5. 【請求項５】請求項４記載の方法において、前記階層の
   前記グラフィック要素を定着したツリーとしてリンクす
   ること、を特徴とするメッセージ追跡方法。
6. 【請求項６】請求項４記載の方法において、前記階層の
   前記グラフィック要素をグラフとしてリンクすること、
   を特徴とするメッセージ追跡方法。
7. 【請求項７】請求項３記載の方法において、ステップｂ
   が、前記グラフィック要素にテキストを追加するステッ
   プを含むこと、を特徴とするメッセージ追跡方法。
8. 【請求項８】請求項７記載の方法において、前記テキス
   トは、 − 前記メッセージ・トラック内の１つのノードの識
   別、 − メッセージの識別、 − 前記１つのノードにおけるメッセージの処置、の内
   １つ以上を識別すること、を特徴とするメッセージ追跡
   方法。
9. 【請求項９】請求項１記載の方法であって、更に、 ｃ） 前記グラフィック表現の一部分のユーザ選択に応
   答して、前記メッセージ・トラック内の１つ以上の低い
   レベルのノードの詳細を記す、更に別のグラフィック要
   素を生成することによって、前記選択した部分を展開す
   るステップ、を含むこと、を特徴とするメッセージ追跡
   方法。
10. 【請求項１０】請求項１記載の方法であって、更に、 ｃ） 前記グラフィック表現の一部分のユーザ選択に応
    答して、前記グラフィック表現の一部分に、メッセージ
    ・ステータスを記述するテキストを追加するステップ、
    を含むこと、を特徴とするメッセージ追跡方法。
11. 【請求項１１】請求項１記載の方法であって、更に、 ｃ） 前記グラフィック表現の少なくとも一部分のユー
    ザ選択に応答して、前記部分を、前記選択部分における
    メッセージ・ステータスを記述するテキストと置換する
    ステップ、を含むこと、を特徴とするメッセージ追跡方
    法。
12. 【請求項１２】請求項１記載の方法であって、更に、 ｃ） 複数のノードを含む前記グラフィック表現の一部
    分のユーザ選択に応答して、前記複数のノードを含むよ
    り高いレベルのノードを表すグラフィック要素を生成す
    ることにより、前記選択部分を圧縮するステップ、を含
    むこと、を特徴とするメッセージ追跡方法。
13. 【請求項１３】請求項１記載の方法であって、更に、前
    記グラフィック表現を表示装置上に表示するステップを
    含むこと、を特徴とするメッセージ追跡方法。
14. 【請求項１４】請求項１記載の方法において、前記情報
    ネットワークはインターネットであること、を特徴とす
    るメッセージ追跡方法。
15. 【請求項１５】メッセージのトラック内のノードからの
    ステータス・データを含むメッセージ・トラック・デー
    タ構造にアクセスして、前記メッセージ・トラック・ス
    テータス・データからの前記メッセージ・トラックのグ
    ラフィック表現を生成するよう動作可能に構成したメッ
    セージ追跡ツールを備え、前記グラフィック表現が、前
    記ノードにおける前記ステータス・データを表すグラフ
    ィック要素を含み、前記グラフィック要素は相互に配列
    して前記メッセージ・トラックを表すこと、を特徴とす
    るメッセージ追跡システム。
16. 【請求項１６】請求項１５記載のシステムであって、前
    記メッセージ・トラック・データ構造を構築するよう動
    作可能に構成したメッセージ追跡機構を含むこと、を特
    徴とするメッセージ追跡システム。
17. 【請求項１７】請求項１６記載のシステムにおいて、前
    記メッセージ追跡機構は、メッセージの送信に続いて、
    前記メッセージ・トラック内の前記ノードから送出され
    かつ前記ノードにおける前記メッセージ・ステータスを
    示す応答に応答して、前記メッセージ・トラック・デー
    タ構造内に対応するエントリを作成するよう動作可能に
    構成したこと、を特徴とするメッセージ追跡システム。
18. 【請求項１８】請求項１７記載のシステムにおいて、前
    記メッセージ追跡機構は、前記送信したメッセージのメ
    ッセージ識別子に対応するまたはそれから派生したメッ
    セージ識別子を識別して、前記応答を識別するよう動作
    可能に構成したこと、を特徴とするメッセージ追跡シス
    テム。
19. 【請求項１９】請求項１６記載のシステムにおいて、前
    記メッセージ追跡機構は、メッセージの送信に続くユー
    ザが選択して時点で、メッセージ追跡要求を送信し、続
    いて、前記メッセージ・トラック内のノードから送出さ
    れかつ前記ノードにおける前記メッセージ・ステータス
    を示す前記メッセージ追跡要求に対する応答に応答し
    て、前記メッセージ・トラック・データ構造内に対応す
    るエントリを作成するよう動作可能に構成したこと、を
    特徴とするメッセージ追跡システム。
20. 【請求項２０】請求項１９記載のシステムにおいて、前
    記メッセージ追跡機構は、前記送信した要求のメッセー
    ジ識別子に対応するまたはそれから派生したメッセージ
    識別子を識別して、前記応答を識別するよう動作可能に
    構成したこと、を特徴とするメッセージ追跡システム。
21. 【請求項２１】請求項１５記載のシステムであって、更
    に、メッセージ・ステータスのアイコン表現のパレット
    を備えており、前記メッセージ追跡ツールは、前記ステ
    ータス・データに応答して、前記グラフィック要素を生
    成するため、前記ノードにおけるメッセージ・ステータ
    スのアイコン表現の前記パレットにアクセスするよう構
    成したこと、を特徴とするメッセージ追跡システム。
22. 【請求項２２】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記ステータス・データに
    応答して、処理の進行中にグラフィック要素を生成する
    ことにより、前記ノードにおける前記メッセージ・ステ
    ータスを表すように構成したこと、を特徴とするメッセ
    ージ追跡システム。
23. 【請求項２３】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記ステータス・データに
    応答して、グラフィック要素の階層を生成するように構
    成してあり、各グラフィック要素が１つの前記ノードに
    おけるメッセージ・ステータスをグラフィック的に表す
    こと、を特徴とするメッセージ追跡システム。
24. 【請求項２４】請求項２３記載のシステムにおいて、前
    記階層の前記グラフィック要素は、定着したツリーとし
    てリンクしたこと、を特徴とするメッセージ追跡システ
    ム。
25. 【請求項２５】請求項２３記載のシステムにおいて、前
    記階層の前記グラフィック要素は、グラフとしてリンク
    したこと、を特徴とするメッセージ追跡システム。
26. 【請求項２６】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記グラフィック要素にテ
    キストを追加するよう動作可能に構成したこと、を特徴
    とするメッセージ追跡システム。
27. 【請求項２７】請求項２６記載のシステムにおいて、前
    記テキストは、 −前記メッセージ・トラック内の１つのノードの識別、 −メッセージの識別、 −前記１つのノードにおけるメッセージの処置、の内の
    １つ以上を識別すること、を特徴とするメッセージ追跡
    システム。
28. 【請求項２８】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記グラフィック表現の一
    部分のユーザ選択に応答して、前記メッセージ・トラッ
    ク内の１つ以上のより低いレベルのノードの詳細を記
    す、更に別のグラフィック要素を生成することによっ
    て、前記選択した部分を展開するよう動作可能に構成し
    たこと、を特徴とするメッセージ追跡システム。
29. 【請求項２９】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記グラフィック表現の一
    部分のユーザ選択に応答して、前記グラフィック表現の
    一部分に、メッセージ・ステータスを記述するテキスト
    を追加するよう動作可能に構成したこと、を特徴とする
    メッセージ追跡システム。
30. 【請求項３０】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記グラフィック表現の少
    なくとも一部分のユーザ選択に応答して、前記部分を、
    前記選択部分におけるメッセージ・ステータスを記述す
    るテキストと置換するよう動作可能に構成したこと、を
    特徴とするメッセージ追跡システム。
31. 【請求項３１】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、複数のノードを含む前記グ
    ラフィック表現の一部分のユーザ選択に応答して、前記
    複数のノードを含むより高いレベルのノードを表すグラ
    フィック要素を生成することにより、前記選択部分を圧
    縮するよう動作可能に構成したこと、を特徴とするメッ
    セージ追跡システム。
32. 【請求項３２】請求項１５記載のシステムにおいて、前
    記メッセージ追跡ツールは、前記グラフィック表現を表
    示装置上に表示するよう動作可能に構成したこと、を特
    徴とするメッセージ追跡システム。
33. 【請求項３３】請求項１５記載のシステムにおいて、コ
    ンピュータ・ソフトウエア・システムの形態であるこ
    と、を特徴とするメッセージ追跡システム。
34. 【請求項３４】請求項１５記載のシステムにおいて、前
    記情報ネットワークはインターネットであること、を特
    徴とするメッセージ追跡システム。
35. 【請求項３５】データ記憶媒体上のメッセージ追跡プロ
    グラムであって、メッセージのトラック内の複数のノー
    ドからのステータス・データを含むメッセージ・トラッ
    ク・データ構造にアクセスして、前記メッセージ・トラ
    ック・ステータス・データからの前記メッセージ・トラ
    ックのグラフィック表現を生成するよう動作可能に構成
    したメッセージ追跡ツールを備え、前記グラフィック表
    現が、前記ノードにおける前記ステータス・データを表
    す複数のグラフィック要素を含み、前記グラフィック要
    素は相互に配列して前記メッセージ・トラックを表すこ
    と、を特徴とするデータ記憶媒体上のメッセージ追跡プ
    ログラム。
36. 【請求項３６】メッセージのトラック内の複数のノード
    からのステータス・データを含むメッセージ・トラック
    ・データ構造にアクセスして、前記メッセージ・トラッ
    ク・ステータス・データからの前記メッセージ・トラッ
    クのグラフィック表現を生成するよう動作可能なメッセ
    ージ追跡ツール・プログラムを備えたコンピュータであ
    って、前記グラフィック表現が、前記ノードにおける前
    記ステータス・データを表す複数のグラフィック要素を
    含み、前記グラフィック要素は相互に配列して前記メッ
    セージ・トラックを表すこと、を特徴とするコンピュー
    タ。
37. 【請求項３７】請求項３６記載のコンピュータであっ
    て、前記グラフィック表現を表示する表示装置を備えて
    いること、を特徴とするコンピュータ。
38. 【請求項３８】請求項３７記載のコンピュータであっ
    て、前記メッセージ・トラック・データ構造を構築する
    よう動作可能に構成したメッセージ追跡プログラムを備
    えていること、を特徴とするコンピュータ。