JPH06224936A

JPH06224936A - 統合電子メール・システム

Info

Publication number: JPH06224936A
Application number: JP31766492A
Authority: JP
Inventors: Osamu Inoue; 修井上; Mitsugi Kanehara; 貢金原; Akira Okubo; 晃大久保; Shoichi Tsuchiya; 昌一土屋; Keiichi Yamamoto; 啓一山本
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1992-11-27
Filing date: 1992-11-27
Publication date: 1994-08-12
Anticipated expiration: 2013-11-11
Also published as: JP2823106B2

Abstract

(57)【要約】【目的】特定のメール・システムや通信プロトコルに
依存せず、接続できるメール・システムにも制限がな
い、拡張性及び汎用性に富んだ統合電子メール・システ
ムを提供すること。【構成】それぞれモニタ２４〜２９を介してメールを
送受信する複数のメール・システム１１〜１６を相互接
続して統合的に管理するために、各モニタに対する共通
インターフェース１７、ファイル手段１８、管理手段１
９及び処理手段２３を設ける。管理手段はモニタを含む
システム全体を管理する。処理手段は、入力側のモニタ
から共通インターフェースを介して受け取ったメール及
び宛先情報をファイル手段に保管し、宛先情報を出力側
のモニタ別に分類し、メール及び宛先情報を共通インタ
ーフェースを介して出力側のモニタへ送る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は統合電子メール・システ
ムに関し、特に複数の異なったメール・システムの間で
自由にメール交換を行うことができる統合電子メール・
システムに関する。

【０００２】

【従来の技術】今日、多くの企業では、オフィス内にお
ける業務のオートメーション化が企業全体の生産性向上
を図る上での最も重要な方策であると考え、オフィス・
オートメーションの中核として「電子メール・システ
ム」を位置づけている。既に市場では数多くの電子メー
ル製品が販売されており、オフィス・オートメーション
化に熱心な企業に導入されている。市販の電子メール製
品は、それぞれが独自のハードウェア、オペレーティン
グ・システム（ＯＳ）及びプロトコルを採用しているの
が通例で、そのため異なる電子メール製品間でメールを
交換するのは容易ではない。しかし、オフィス活動のよ
り一層の効率化を図るため、様々な電子メール製品の連
結及び統合化や、ファクシミリへのメール出力などが望
まれている。

【０００３】上述のような点から、これまでにも異なっ
た電子メール・システムあるいは通信メディアを接続す
るための提案が幾つかなされている。例えば、特開平２
−２７０４６６号は複数の異なった通信メディアの中か
ら宛先の通信メディアを自動選択して、原稿データを送
信する通信メディア自動選択装置を開示している。この
通信メディア自動選択装置は、宛先コードと通信メディ
ア名の対照表（通信メディアテーブル）を持っており、
宛先コード入力部から入力された宛先コードでこの対照
表を検索することにより宛先の通信メディア（ファクシ
ミリ、テレックス、電子メールなど）を自動的に選択す
る。通信メディアが選択されると、あとはそれに応じた
編集処理を行い、対応する制御装置を介して宛先へ送信
する。

【０００４】特開平４−６８７３１号は、複数の電子メ
ール・プロトコルの電子メールの着信を、それがどの電
子メール・プロトコルを利用しているのかを意識するこ
となく常時確認できるようにした電子メール装置を開示
している。この電子メール装置は、電子メールの送受信
処理部及び着信監視部をプロトコル対応に備えており、
電子メールの送受信処理及び着信監視を独立して行うこ
とにより、異なったプロトコルの電子メールの着信を確
実に検出できるようにしたものである。

【０００５】ヨーロッパ公開特許明細書第４６２７２５
号は、ＯＳＩ（開放型システム間相互接続）メール処理
システムのような特定のメール・システムのユーザが他
のメール・システムのユーザと通信できるようにした通
信システムを開示している。これは、任意のユーザから
発信された通信を処理するための共通インターフェース
を特定のメール・システムに設けることによって達成さ
れる。

【０００６】

【発明が解決しようとする課題】以上のように、従来は
各メール・システムが交信する相手のメール・システム
を１つ１つ直接意識し、それぞれに対応する外部とのイ
ンターフェースを用意するか、又は特定のメール・シス
テムのグループで共通インターフェースを決めてメール
交換を行うのが一般的であった。しかし、これでは拡張
性や汎用性に欠ける。例えば、従来のやり方では、接続
するメール・システムが増える度に各メール・システム
のプログラム変更が必要になってしまうのが普通であ
る。また、送受信する組み合せの数だけトランザクショ
ンが必要になり、ネットワーク全体の管理を統合された
環境で行うこともできない。更に、データ変換が必要な
場合は各インターフェースが独自に行わなければならな
い。

【０００７】従って本発明の目的は、特定のメール・シ
ステムや通信プロトコルに依存せず、接続できるメール
・システムにも制限がない、拡張性及び汎用性に富んだ
統合電子メール・システムを提供することにある。

【０００８】本発明の他の目的は、新しいメール・シス
テムを追加接続した場合、既接続のメール・システム及
びインターフェースの変更が不要である統合電子メール
・システムを提供することにある。

【０００９】本発明の他の目的は、送付するメール・デ
ータが制限されない統合電子メール・システムを提供す
ることにある。

【００１０】本発明の他の目的は、交信する各メール・
システムの状況及び通信データ量を統合された環境で管
理することができる統合電子メール・システムを提供す
ることにある。

【００１１】

【課題を解決するための手段】本発明は、それぞれモニ
タを介してメールを送受信する複数のメール・システム
を相互接続して統合的に管理する統合電子メール・シス
テムに関するものであって、各モニタに対する共通イン
ターフェースと、ファイル手段と、入力側のモニタから
の要求に応答して共通インターフェースを介して受け取
ったメール及び宛先情報をファイル手段に保管し、宛先
情報を出力側のモニタ別に分類し、該出力側のモニタか
らの要求に応答してメール及び宛先情報を共通インター
フェースを介して出力側のモニタへ送る処理手段と、モ
ニタを含むシステム全体を管理する管理手段とを備えた
ことを特徴としている。共通インターフェースは、各モ
ニタと処理手段との間のやりとりを共通化するものであ
り、これにより異なったメール・システム間でメールを
交換することができる。

【００１２】

【実施例】本発明に従う統合電子メール・システムの構
成を図１に示す。本システムは共通のプラットフォーム
１０により、それぞれモニタを介してメールを交換する
複数の異なったメール・システム１１〜１６を相互接続
する。各メール・システムのモニタは、メール・システ
ム１１、１２及び１５のように入力モニタ及び出力モニ
タに分かれていても、メール・システム１６のように共
通の入出力モニタ２９であってもよい。またメール・シ
ステム１３及び１４のように、送信専用又は受信専用の
場合はそれに対応するいずれか一方のモニタを備えてい
ればよい。例えば、出力モニタ２６だけを備えたメール
・システム１３としてファクシミリ・システムや印刷シ
ステムを接続することができ、入力モニタ２９だけを備
えたメール・システム１４としてテキスト検索結果を別
のシステムに出力する検索システムを接続することがで
きる。本発明においては、モニタ（以下、入力モニタ及
び出力モニタを特に区別する必要がないときは単にモニ
タと云う）が後述の共通インターフェース仕様に従って
いる限り、接続可能なメール・システムに制限はない。

【００１３】プラットフォーム１０は、各モニタとのや
りとりを共通化するための共通インターフェース１７
と、メール交換に関する様々な情報を記録保持するファ
イル機構１８と、本システムを運用・管理するための管
理機構１９と、メールのデータ形式を変換するためのデ
ータ変換部２０〜２２と、モニタ又は管理機構１９から
呼び出されてファイル機構１８及びデータ変換部２０〜
２２をアクセスするリンク・プロセッサ２３とを含む。
共通インターフェース１７は、各モニタとリンク・プロ
セッサ２３との間、及びリンク・プロセッサ２３と管理
機構１９との間をそれぞれ仲介するもので、一般にアプ
リケーション・プログラミング・インターフェース（Ａ
ＰＩ）と呼ばれている。ファイル機構１８は、入力モニ
タ毎のメール関連ファイルを保持するバスケット１８
Ａ、各出力モニタが送信すべきメールの宛先情報を保持
する宛先情報ファイル１８Ｂ、警告やエラーなどのログ
情報を保持するログ情報ファイル１８Ｃ、及びメール・
システムのユーザに課金するための会計情報を保持する
会計情報ファイル１８Ｄを含む。バスケット１８Ａが保
持するメール関連ファイルは、メールのプロファイル情
報を保管するメール・ヘッダ・ファイル、送られてきた
メールの本体（メールの内容そのもの）を保管するメー
ル・ファイル及びメール本体の属性情報を保管するメー
ル属性ファイルである。

【００１４】管理機構１９は、本システムを運用・管理
していく際に必然的に生じる次のような作業を支援す
る。・モニタの登録及びその抹消・モニタの始動及び停止・モニタの稼働状況の表示・ログ情報の表示、印刷及び保存・会計情報の表示、印刷及び保存・データ変換部の登録及びその抹消・ヘルプ画面の表示図１には示していないが、管理機構１９は表示装置、印
刷装置及びキーボードを備えており、それらを用いて上
記の作業を行う。

【００１５】宛先のメール・システムに合わせてメール
のデータ形式を変換するデータ変換部２０〜２２は、修
正、追加及び削除の容易さを考えると、ソフトウェアで
実現するのが望ましい。本実施例では、データ変換部２
０〜２２はそれぞれデータ変換プログラムとしてプラッ
トフォーム１０に含まれている。リンク・プロセッサ２
３は共通インターフェース１７を介してモニタ又は管理
機構１９から呼び出され、バスケット１８Ａをアクセス
したり、データ変換プログラム２０〜２２を呼び出した
り、ログ情報及び会計情報を管理機構１９に渡したりす
る。次に、図１のシステムにおいてメールがどのように
処理されるかを図２〜図５を参照しながら簡単に説明し
ておく。

【００１６】メールは、該メールを受け取るべきユーザ
の識別子（ユーザＩＤ）及びそのユーザが接続されてい
るノード（メール・システム）の識別子（ノードＩＤ）
を指定することによって送信される。以下では、メール
・システム１１〜１６のノードＩＤをそれぞれＭＳ１、
ＭＳ２、ＭＳ３、ＭＳ４、ＭＳ５及びＭＳ６とし（実際
には、１つのメール・システムが複数のノードＩＤを持
っていることがある）、メール・システム１１のユーザ
が次のように宛先を指定してメール・システム１２、１
３及び１５のユーザにメールを送る場合を考える。

【００１７】ＩＮＯＵＥａｔＭＳ２ＴＵＣＨＩＹＡａｔＭＳ２０３−３５８６−１１１１ａｔＭＳ３ＫＩＮＢＡＲＡａｔＭＳ５ＯＨＫＵＢＯａｔＭＳ５ＹＡＭＡＭＯＯａｔＭＳ５上記において、「ａｔ」の前がユーザＩＤを表し、後ろ
がノードＩＤを表す。

【００１８】まず入力モニタ２４は、メール・システム
１１のユーザからメールを受け取ると、リンク・プロセ
ッサ２３を呼び出すことによって、対応するバスケット
１８Ａにメール本体及び宛先情報を保管する（図２）。
バスケット１８Ａに保管された宛先情報は、リンクプロ
セッサ２３によって、出力モニタ毎に（云い替えればノ
ードＩＤ毎に）分類されて宛先情報ファイル１８Ｂに移
される（図３）。図示の例では、メール・システム１２
の出力モニタ２５、メール・システム１３の出力モニタ
２６及びメール・システム１５の出力モニタ２７にそれ
ぞれ対応する宛先情報ファイルに関連する宛先情報が移
される。メール本体はバスケット１８Ａに保管されたま
まである。次に、各出力モニタが対応する宛先情報ファ
イル１８Ｂにある宛先情報（ユーザＩＤ及びノードＩ
Ｄ）によって指定された宛先に向けてバスケット１８Ａ
内のメールを送信する（図４）。図４の例では、出力モ
ニタ２５がメール・システム１２の二人のユーザにメー
ルを送信している。送信が終了すると、出力モニタ２５
は対応する宛先情報ファイル１８Ｂの内容を消去する
（図５）。他の出力モニタ２６及び２７も同様な動作を
行う。メールが全ての宛先に送信され、３つの宛先情報
ファイルの内容が消去されると、バスケット１８Ａ内の
メール本体も消去される。

【００１９】次に、図１に示す統合電子メール・システ
ムの詳細について説明するが、メール・システム１１〜
１６は市販の電子メール製品でよく、その構成や機能は
本発明には直接関係しないので、メール・システム１１
〜１６の詳細については省略する。

【００２０】各メール・システムのモニタは、他の異な
ったメール・システムとのメール交換を可能にするた
め、共通インターフェース１７の仕様に合わせて設計す
る必要がある。本実施例では、各モニタはソフトウェア
で実現される。入力モニタの主たる処理内容は：送信者
側のメール・システムから送られてくるメールを受け取
ること；リンク・プロセッサ２３を呼び出して、受け取
ったメールをバスケット１８Ａに保管すること；及びリ
ンク・プロセッサ２３を呼び出し、出力モニタ毎にメー
ルの宛先を分類して宛先情報ファイルを作成することで
ある。これに対して出力モニタの主たる処理内容は：リ
ンク・プロセッサ２３を呼び出して、送信すべきメール
をバスケット１８Ａから入手すること；及び受信者側の
メール・システムに向けてメールを送信することであ
る。各モニタによるリンク・プロセッサ２３の呼出しは
共通インターフェース１７を介して行われる。共通イン
ターフェース１７は、リンク・プロセッサ２３で共通に
処理されるサービスを呼び出すための命令及びプラット
フォーム１０内で統一的に処理すべきメール情報の形式
を定めており、いかなるメール・システムであっても、
そのモニタが共通インターフェース１７に従っていれ
ば、任意のメール・システム間でメールを交換すること
ができる。本実施例では、以下のようなサービスを呼び
出す命令を各モニタのプログラム中に記述することによ
り、共通インターフェース１７を介してサービスを受け
られるようになっている。サービスを実際に実行するの
はリンク・プロセッサ２３である。

【００２１】１．入力モニタ用の機能に関するサービス・メール関連ファイルをバスケット１８Ａに格納するた
めに使用するファイル名を割り当てるファイル名割当て
サービス（DwiAssignFileName）。・メール・ヘッダ情報をバスケット１８Ａに格納するメ
ール・ヘッダ格納サービス（DwiPutMailHeader）。・メール本体のデータの属性情報をバスケット１８Ａに
格納する属性格納サービス（DwiPutContentAttr）。・メールを出力モニタに配信する配信サービス（DwiDis
tribute）。

【００２２】２．出力モニタ用の機能に関するサービス・処理すべきメールが配信されているかどうかを確認
し、配信されている場合はバスケット１８Ａ内のそのメ
ール関連ファイルのファイル名を返すメール情報入手サ
ービス（DwiGetMailInfo）。・処理完了後のメール関連ファイルを削除するメール・
クリア・サービス（DwiClearMail）。・メールの種類が受信確認情報の場合、メール関連ファ
イルを参照して受信確認情報テキスト・ファイルを作成
する受信確認テキスト作成サービス（DwiCreateAckTex
t）。・メール情報入手サービスで一度確認した配信メールを
リセットするメール・リセット・サービス（DwiResetMa
ilInfo）。

【００２３】３．その他のサービス・作業記憶域を割り振って初期化し、そのアドレスを返
す初期化サービス（DwiInit）。・モニタ情報を入手するモニタ情報入手サービス（DwiG
etMonitorInfo）。・管理機構１９から終了要求が出されているかどうかを
確認する終了確認サービス（DwiAskTerminate）。・モニタの稼働状況を更新する状況設定サービス（DwiS
etStatus）。・作業記憶域の割り振りを解除して終了する終了サービ
ス（DwiTerm）。・メールの受信確認情報を送信する受信確認送信サービ
ス（DwiSendAck）。・ログ情報を出力するログ出力サービス（DwiPutLo
g）。 #d 上記において、各サービス名の後ろの括弧内に示してあ
るのは対応するサービスを呼び出すための命令の例であ
る。これらの命令は、共通インターフェース１７が定義
した命令であることを示す文字「Ｄｗｉ」及びサービス
を識別する文字で表され、命令実行に必要なパラメータ
を含んでいる。勿論これらは一例に過ぎず、本発明はそ
れらに限定されない。

【００２４】共通インターフェース１７に従う標準的な
入力モニタ及び出力モニタのプログラムの構造をそれぞ
れ図６及び図７に示す。いずれのプログラムも３つの部
分、すなわち初期化処理部、メール処理部及び終了処理
部に分けられている。管理機構１９が入力モニタを始動
すると図６のプログラムが実行され、出力モニタを始動
すると図７のプログラムが実行される。

【００２５】まず図６において、初期化処理部３１は、
作業記憶域の割り振り、モニタ情報の入手及びモニタ稼
働状況の変更を行う。記憶域を割り振るときは前述の初
期化サービスを呼び出す。この割り振りは入力モニタ
（例えば入力モニタ２４）とファイル機構１８との間で
情報をやりとりするのに必要である。リンク・プロセッ
サ２３による割り振りが終ると、その記憶域のアドレス
が入力モニタに返され、モニタ情報の入手に進む。なん
らかの理由で割り振りができなかった場合は、初期化エ
ラーを示すログ情報がログ出力サービスにより管理機構
１９に渡される。管理機構１９はこのログ情報をログ情
報ファイル１８Ｃに保管したり、表示装置（図示せず）
で表示したりすることができる。

【００２６】モニタ情報の入手はモニタ情報入手サービ
スを呼び出すことによって行われる。モニタ情報入手サ
ービスは、当該入力モニタが使用するバスケット１８Ａ
のパス名、データ変換プログラムが使用するパス名、及
び宛先情報ファイル１８Ｂが作成されるパス名を含むモ
ニタ定義情報を入力モニタに与える。もしモニタ情報が
入手できなければ、初期化エラーのときと同様に、その
旨を示すログ情報が管理機構１９に渡される。モニタ情
報を入手すると、入力モニタは状況設定サービスを呼び
出すための命令中で稼働状況フラグをオンにして状況設
定サービスを呼び出すことにより、自身の稼働状況を
「稼働中」に変更する。状況設定サービスは、入力モニ
タが稼働中になったことを管理機構１９に知らせる。管
理機構１９はその表示装置で各モニタの稼働状況を表示
することができる。初期化処理が完了するとメール処理
に進む。

【００２７】メール処理部３２では、終了要求のチェッ
ク、メール受信、ファイル名の割当て、メール・ヘッダ
の作成、メール本体の保管、及び各出力モニタへの配信
が行われる。入力モニタはまず終了確認サービスを呼び
出すことにより、管理機構１９から入力モニタの終了要
求が出ているかどうかをチェックする。管理機構１９は
稼働中のモニタの作業記憶域に終了要求を書込むことに
よって任意のモニタを停止することができるようになっ
ており、終了確認サービスは入力モニタの作業記憶域に
おける終了要求の有無を入力モニタに知らせる。終了要
求が出ていると、入力モニタはメール処理を打ち切って
次の終了処理部３３に進む。

【００２８】終了確認サービスで終了要求が出ていない
ことが分かると、入力モニタは関連するメール・システ
ム（例えばメール・システム１１）からメールを受け取
ってそれをプラットフォーム１０の方へ渡すことができ
る。各モニタと関連するメール・システムとの間のやり
とりは本発明とは無関係であるからここでは省略する。
入力モニタは関連するメール・システムからメールを受
け取ると、ファイル名割当てサービスを呼び出すによ
り、メール関連ファイルをバスケット１８Ａに格納する
ために使用するファイル名を割り当ててもらう。ファイ
ル名割当てサービスは割り当てたファイル名を入力モニ
タに返す。それが終ると、メール・ヘッダ格納サービス
を呼び出すことにより、入力モニタからのメール・ヘッ
ダ情報をバスケット１８Ａに格納する。このとき入力モ
ニタは共通インターフェース１７が定めている形式でメ
ール・ヘッダ情報をリンク・プロセッサ２３に渡す。メ
ール・ヘッダ格納サービスでは、メール関連ファイルの
１つであるメール・ヘッダ・ファイルがバスケット１８
Ａに作成される。このファイルは、前述のノードＩＤ及
びユーザＩＤをそれぞれ含む発信者情報及び受信者情報
の他に、メールの種類（通常のメール又は受信確認）、
メール処理の優先順位、通常メールの場合の受信確認の
要不要、メール・ファイルの数（通常は１、同封メール
の場合は２以上）、及び受信確認の場合のエラー状況、
といった様々なプロファイル情報を含む。

【００２９】メール・ヘッダ情報の格納が終ると、入力
モニタはファイル名割当てサービスで割り当てられたフ
ァイル名を使用することにより、自身でメール本体をバ
スケット１８Ａに格納する。このとき、メール関連ファ
イルの１つであるメール・ファイルがバスケット１８Ａ
に作成される。更に、格納したメール本体のデータの属
性情報を属性格納サービスを呼び出すことによりバスケ
ット１８Ａに格納する。この属性情報はメール関連ファ
イルの１つであるメール属性ファイルに保管され、メー
ルの内容（テキスト・データ、イメージ・データ、音声
データなど）を識別するメール識別子、及びメール・フ
ァイルの通し番号（通常は１、同封メールの場合は１か
ら始まる通し番号を指定する）を含む。１つのメールが
複数のメール本体を含む同封メールの場合は、メール本
体の格納及びそれに伴う属性情報の格納はメール本体の
数だけ繰り返される。 #d 格納が終ると、配信サービスを呼び出すことにより、各
出力モニタにメールを配信する。これは図３の処理に対
応するもので、リンク・プロセッサ２３がノードＩＤ及
びユーザＩＤを含む受信者情報ないし宛先情報に基づい
て出力モニタ別に宛先情報ファイル１８Ｂを作成する。
このときメール本体はまだ出力モニタには送られない。
受信者のノードＩＤに対応する出力モニタがない場合
は、その旨を示すログ情報が管理機構１９に渡される。
そのとき前のメール・ヘッダ格納サービスで格納したメ
ール・ヘッダ情報で受信確認要が指定されていると、受
信確認送信サービスによりメールの発信者に受信確認情
報を自動的に返す。出力モニタへの配信が終ると、メー
ル処理部３２の先頭に戻って再び終了確認サービスを呼
び出す。管理機構１９から終了要求が出ていると終了処
理部３３に進み、さもなければメールの受信を始める。

【００３０】最後の終了処理部３３は、モニタ稼働状況
の変更及び割り振られた記憶域の解放を行う。管理機構
１９から終了要求が出ていると、入力モニタは前述の稼
働状況フラグをオフにして状況設定サービスを呼び出す
ことにより、自身の稼働状況を「停止中」に変更する。
リンク・プロセッサ２３はこの状況変更を管理機構１９
に知らせる。

【００３１】次に、出力モニタのプログラム構造を示す
図７において、最初の初期化処理部４１は最後にメール
・リセット・サービスが呼び出される点を除くと入力モ
ニタの初期化処理部３１と同じである。出力モニタは、
稼働状況を「稼働中」に変更した後メール・リセット・
サービスを呼び出すことにより、前回の処理時にメール
情報入手サービスで確認した処理中のメールをリセット
する。それが終るとメール処理部４２に進む。

【００３２】メール処理部４２では、終了要求のチェッ
ク、メール情報の入手、入手したメールの送信、及び処
理完了メールの削除を行う。最初の終了要求のチェック
は入力モニタのときと同じであり、管理機構１９から終
了要求が出ていると終了処理部４３に進む。終了要求が
出ていなければ、メール情報入手サービスを呼び出すこ
とにより当該出力モニタへの配信メールを確認する。メ
ール情報入手サービスは、当該出力モニタの宛先情報フ
ァイル１８Ｂから受信者情報を取り出し、更にバスケッ
ト１８Ａから発信者情報を含むメール関連情報を取り出
す。取り出しは、メールの優先順位の高いものから順に
行われる。このときデータ変換が指定されていると、対
応するデータ変換プログラムを呼び出して指定された変
換を行う。このデータ変換は、メールをバスケット１８
Ａに格納するときに行うように指定することもできる。
前述のように、データ変換の指定はモニタ情報入手サー
ビスで入手したモニタ情報に含まれている。データ変換
は、例えばテキスト・データをイメージ・データに変換
してファクシミリに出力するときなどに必要である。配
信メールがなければ、所定時間だけ待った後メール情報
入手サービスの呼出しを再試行する。 #d メール情報の取り出しが終ると、出力モニタはバスケッ
ト１８Ａから送信すべきメール本体を取り出して、受信
者毎に関連するメール・システムに向けて送信する。こ
れは図４の処理に対応している。送信すべきメールが受
信確認の場合は、受信確認テキスト作成サービスを呼び
出すことにより、受信確認情報をテキスト・ファイルと
して受信側のメール・システムに送ることができる。送
信が完了すると、メール・クリア・サービスを呼び出す
ことにより、送信済みのメールの宛先情報ファイルを削
除し（図５参照）、最初の終了要求のチェックに戻る。
リンク・プロセッサ２３は、各出力モニタからのメール
・クリア・サービス呼出しをチェックしており、全ての
出力モニタ（図５の例では、出力モニタ２５〜２７）か
らの呼出しがあった後にバスケット１８Ａ内のメール関
連ファイルを削除する。最後の終了処理部４３は入力モ
ニタの終了処理部３３と同じであるから、ここでは省略
する。

【００３４】共通インターフェース１７は、前述の各種
サービスを呼び出すための命令だけでなく、各モニタと
プラットフォーム１０との間でやりとりする発信者情
報、受信者情報及びメール・ヘッダ情報のデータの形式
も定義している。その一例を図８に示す。図８のデータ
形式は固定長のヘッダ部分及び可変長のデータ部分から
なり、それらを合わせてフィールドと呼ぶ。ヘッダ部分
は、フィールド全体の長さを表す２バイトの長さ値、デ
ータ部分に入っているデータの種類を表す２バイトのフ
ィールドＩＤ、及びデータ部分に入っているデータのタ
イプを表す１バイトのタイプ値を含む。発信者情報、受
信者情報及びメール・ヘッダ上をファイル機構１８に保
管する場合は、図８に点線で示すように、このフィール
ドを必要な数だけ並べて保管することになる。

【００３５】フィールドＩＤによって表されるデータの
種類は、発信者情報及び受信者情報の他に、例えばメー
ルのコメント、作成日時、作成者名、送付日時、件名な
どを自由に定義することができる。データのタイプは、
文字データ、２進データなどを表す。１つのメールを複
数の受信者に送る場合は、受信者毎に１つの受信者情報
フィールドが作成される。そうしておかないと、リンク
・プロセッサ２３が出力モニタ別に宛先情報ファイル１
８Ｂを作成するときの処理（図３の処理）が面倒にな
る。入力モニタは、関連するメール・システムから受け
取ったメール情報を図８の形式に変換してリンク・プロ
セッサ２３に与え、出力モニタは図８の形式の情報をリ
ンク・プロセッサから受け取って、関連するメール・シ
ステムでの処理に適した形に変換する。

【００３６】最後に、管理機構１９によるモニタ、ログ
情報、会計情報及びデータ変換プログラムの管理につい
て説明する。図１には示さなかったが、管理機構１９
は、具体的には、表示装置、印刷装置、キーボード及び
管理プログラムで構成されている。プラットフォーム１
０が起動されると、表示装置の画面には、モニタ名、種
別（入力モニタか出力モニタか）及び稼働状況を含むモ
ニタ状況表示ウィンドウが現れる。操作員はこの画面で
メニューを適当に選択することにより、対話形式でモニ
タの追加（新規登録）、変更、削除、始動、停止、全始
動及び全停止を実行することができる。登録メニューを
選ぶと、モニタ追加／変更画面が表示され、その中に追
加したいモニタの名前及び種別、並びに宛先情報ファイ
ルのパス名、バスケットのパス名、始動方法、データ変
換プログラム用のパス名などを入力することにより新し
いモニタを追加できる。これらの情報はモニタ情報とし
てファイル機構１８に保管される。モニタは、自身のモ
ニタ名を指定して前述のモニタ情報入手サービスを呼び
出すことによりこのモニタ情報を入手できる。モニタの
変更も同じ画面で行われる。モニタを削除する場合は、
モニタ状況表示ウィンドウにおいて削除したいモニタを
例えばカーソルで指定して削除メニューを選択すればよ
い。これにより、前に作成されていたモニタ情報が抹消
される。特定モニタの始動及び停止も同様にして行われ
る。モニタ状況表示ウィンドウにおいて全始動メニュー
を選ぶと、現在停止中の全モニタを同時に始動すること
ができ、全停止メニューを選ぶと、稼働中の全モニタを
同時に停止することができる。モニタの稼働状況は終了
確認サービスにより各モニタに知らされる。

【００３７】システムのエラー状況を示すログ情報につ
いては、表示装置のメニュー画面から表示装置での表
示、ログ情報ファイル１８Ｃへの保管、及び印刷装置で
の印刷を指定することができる。会計情報も同様であ
る。会計情報のレコードはメール毎に作成され、メール
の優先順位、メール本体（メール・ファイル）の数、受
信者の数及び発信者情報を含む。会計情報が出力される
のは、前述の配信サービスのときである。

【００３８】データ変換プログラムの追加、変更及び削
除もメニュー選択により実行できる。追加及び変更は所
定の画面でモニタ名、呼出しタイミング（入力時か出力
時か）、変換対象（メール本体かメール情報か）、当該
データ変換プログラムのプログラム名などを入力又は変
更すればよい。呼出しタイミングは、データ変換を、入
力モニタがメールをバスケットに格納するとき（入力
時）に行うか、出力モニタがメールをバスケットから取
り出すとき（出力時）に行うかを指定する。データ変換
プログラムの削除は同じ画面で削除メニューを選べばよ
い。

【００３９】以上、本発明の良好な実施例について説明
してきたが、本発明の統合電子メール・システムがそれ
らに限定されず、様々な変更が可能なことは云うまでも
ない。

【００４０】

【発明の効果】本発明によれば、特定のメール・システ
ムや通信プロトコルに依存せず、モニタが共通インター
フェースに従っている限り接続できるメール・システム
にも制限がない、拡張性及び汎用性に富んだ統合電子メ
ール・システムを提供することができる。

【図面の簡単な説明】

【図１】本発明に従う統合電子メール・システムの構成
を示すブロック図。

【図２】入力モニタからバスケットへのメール格納を示
す図。

【図３】リンク・プロセッサがバスケットに格納された
宛先情報を出力モニタ別に分類して、宛先情報ファイル
を作成する様子を示す図。

【図４】出力モニタが宛先情報ファイルに入っている宛
先に向けてメール本体を送信する様子を示す図。

【図５】送信を完了した出力モニタが宛先情報ファイル
の内容を削除する様子を示す図。

【図６】入力モニタのためのプログラム構造を示す流れ
図。

【図７】出力モニタのためのプログラム構造を示す流れ
図。

【図８】共通インターフェースで定義されているデータ
形式を示す図。

【符号の説明】

１０プラットフォーム１１〜１６メール・システム１７共通インターフェース１８ファイル機構１９管理機構２０〜２２データ変換部２３リンク・プロセッサ２４入力モニタ２５〜２７出力モニタ２８入出力モニタ２９入力モニタ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁵ 識別記号庁内整理番号ＦＩ技術表示箇所Ｈ０４Ｎ 1/00 １０７Ａ 7046−5Ｃ (72)発明者金原貢神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内 (72)発明者大久保晃神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内 (72)発明者土屋昌一神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内 (72)発明者山本啓一神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内

Claims

【特許請求の範囲】

【請求項１】それぞれモニタを介してメールを送受信す
る複数のメール・システムを相互接続して統合的に管理
する統合電子メール・システムであって、前記モニタに対する共通インターフェースと、ファイル手段と、入力側のモニタからの呼出しに応答して前記共通インタ
ーフェースを介して受け取ったメール及び宛先情報を前
記ファイル手段に保管し、前記宛先情報を出力側のモニ
タ別に分類し、該出力側のモニタからの呼出しに応答し
て前記メール及び前記宛先情報を前記共通インターフェ
ースを介して前記出力側のモニタへ送る処理手段と、前記モニタを含むシステム全体を管理する管理手段と、を備えた統合電子メール・システム。
【請求項２】前記共通インターフェースは、前記処理手
段で実行すべき複数のサービスを呼び出すための命令、
並びに前記ファイル手段に格納されるメール及び宛先情
報のデータ形式を定義する、請求項１に記載の統合電子
メール・システム。
【請求項３】前記ファイル手段は、前記メールを格納す
るバスケットと、前記宛先情報を出力側のモニタ別に格
納する宛先情報ファイルとを含む、請求項１又は２に記
載の統合電子メール・システム。
【請求項４】前記ファイル手段は、更にエラー状況を示
すログ情報を格納するログ情報ファイルと、ユーザに課
金するための会計情報を格納する会計情報ファイルとを
含む、請求項３に記載の統合電子メール・システム。
【請求項５】前記管理手段は表示装置を含み、前記モニ
タの状況、前記ログ情報及び前記会計情報を該表示装置
で表示できる、請求項５に記載の電子メール・システ
ム。
【請求項６】前記複数のサービスは、前記宛先情報を含
むメール・ヘッダ情報を前記ファイル手段に格納するメ
ール・ヘッダ格納サービス、前記宛先情報を出力側のモ
ニタ別に分類することによりメールを出力側のモニタに
配信する配信サービス、処理すべきメールが配信されて
いるかどうかを確認するメール情報入手サービス、処理
完了後のメールを前記ファイル手段から削除するメール
・クリア・サービスを含む、請求項２乃至５のうちの１
つに記載の統合電子メール・システム。
【請求項７】前記モニタは、前記複数のサービスを呼び
出すための命令を自身のプログラム中に記述する、請求
項６に記載の統合電子メール・システム。