JPH04280534A - メールヘッダアクセス方式 - Google Patents

Abstract

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

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はマルチメディア情報通信
センタにおける配送・通知のためのメールヘッダアクセ
ス方式に関する。近年，交換機等のネットワークを介し
て電話機・ＦＡＸを利用した情報通信システムとして，
音声メール，ＦＡＸメール，音声情報提供サービス，Ｆ
ＡＸ情報提供サービスなどがある。このようなサービス
を提供するマルチメディア情報通信センタでは，依頼さ
れたメールを受付けたことの通知，配送先へのメールの
着信の通知，依頼者への配送結果の通知等を行う必要が
あるが，これらの配送・通知に使用するメールのヘッダ
ファイルへのアクセスに時間がかかるため，その改善が
望まれている。

【０００２】

【従来の技術】図６は従来例の情報通信システムの動作
説明図である。図において交換機５２はＦＡＸや電話機
等の種々のメディアの交換接続を行う。交換機５２には
ＦＡＸ端末５０，５４，５６等と共に電話機５１，５５
，５７等が収容されると共にマルチメディア情報センタ
（図ではセンタで表示）５３が設けられ，加入者からの
要求に応じたサービスを提供している。

【０００３】ＦＡＸメールの例により図６におけるサー
ビス動作の例を説明すると，センタ５３は音声により自
動応答し，ＦＡＸ端末５０の利用者が電話機５１からセ
ンタ５３に対して自己がセンタ５３に保管しているＦＡ
Ｘメール（またはＦＡＸ端末５０からセンタ５３へこれ
から送信するメール）の配送を依頼した場合，宛先とし
てＦＡＸ端末５４及び５６を電話機のダイヤル信号（２
周波のＰＢ信号）等を用いて指定（時間等も指定可）し
て依頼する。センタではそれを受付けると，受付けた旨
の通知をＦＡＸ端末５０に通知し，配送指定時間がくる
と指定されたＦＡＸ端末５４，５６に送信する。この後
それぞれのＦＡＸの使用者が備える電話機５５，５７を
呼び出してＦＡＸによる着信があったことを音声により
通知する。また送信依頼者のＦＡＸ５０に対し配送の結
果通知を送信する。

【０００４】図７はセンタのファイル構成を示す。従来
のセンタでは，利用者から依頼された音声メール・ＦＡ
Ｘメールをセンタ内でファイルの形式で扱う。そのファ
イルの構成は１メール当たり，メールの配送，通知状況
を記録するヘッダファイル６０と，メールデータの所在
を管理する本体ファイル６１，メールデータの内容が格
納された実体ファイル６２の３種類である。

【０００５】図８はセンタにおける従来のメールの配送
・通知処理の構成を示す。依頼者からメールがセンタに
入力されると，上記３種類のファイル６０〜６２が送信
メールプロセス６３で生成され，配送予約ファイル６４
に登録される。この時，初期値を埋め込まれて生成され
たヘッダファイル６０は配送管理プロセス（常駐プロセ
ス）６５，配送プロセス６６（複数個生成するのは同時
に複数の宛先へ配送する場合）により処理され，依頼者
の希望する配送先へ出力される。また，センタへの受付
が実行されたことを利用者へ通知する受付通知，配送先
へメールの着信を知らせる着信通知，利用者へ配送結果
を知らせる結果通知の各通知も配送処理の経過に従って
通知予約ファイル６９に登録された状況に応じて，通知
管理プロセス６８が各通知プロセス６７を起動して実行
される。

【０００６】上記したようにヘッダファイルにより配送
通知の状況・結果を管理しており，図９に従来のヘッダ
管理方式の構成を示す。すなわち，配送プロセス６６や
各通知プロセス６７ａ〜６７ｃは，処理状況をヘッダフ
ァイル６０内の受信者情報テーブル（図示せず）の各端
末情報に対応する配送・通知の状況フラグへ書き込む。 詳細には，処理結果を前記状況フラグとヘッダファイル
内のカウンタ情報の書き込みを行う。なお，状況フラグ
は，状況確認プロセス７０で使用され，カウンタ情報は
，配送・通知プロセス６６，６７ａ〜６７ｃが，１つの
メール依頼に対して最終処理となるヘッダのジャーナル
化（ジャーナルファイル７１への転送）とメールファイ
ル（図７の実体ファイル６２）の削除をするかしないか
の判断の基準となる。このヘッダファイル６０への書き
込みは，他プロセスでアクセスできないように排他制御
を行っている。

【０００７】

【発明が解決しようとする課題】従来のセンタでは，回
線数が十分あり，多数宛先の同報を行う場合に処理のネ
ックになるのは，このヘッダファイルへの書き込みであ
る。例えば，最大回線数が６４回線の時，６４個のプロ
セスが起動された場合，状況フラグは１宛先につき「未
配送（初期値）」，「配送中」，「完了（または不達）
」と，最低２回はアクセス（書き込み）されるので，１
メール依頼の１つのヘッダファイルについて１２８回の
アクセスとなり，これが排他制御で行われるので６４個
のプロセスの内，いくつかがアクセス待ちになる可能性
がある。なお，カウンタ情報は，状況フラグの完了（ま
たは不達）書き込み時に同時に書き込みを行うのでアク
セス回数は状況フラグだけを考えればよい。このため，
システム中に配送・通知の非常駐プロセスが存在する時
間が長くなり，ヘッダファイルへのアクセス集中による
システム全体のスループットが悪化するという問題があ
った。

【０００８】更に，現在のセンタでは１つのメールに関
する配送・通知プロセスの内，処理最終プロセスがヘッ
ダファイルのジャーナル化と本体ファイル，実体メール
ファイルの削除を行っている。このため，各配送・通知
プロセスは自分が最終プロセスであるか否かの判断と最
終プロセスである場合の処理を行なわなければならない
。これは，多数起動される配送・通知プロセスに最終プ
ロセス判断部と処理部をそれぞれもたなければならず，
プロセスサイズがその分大きくなり，メモリの有効使用
ができなくなるという問題がある。また，各配送・通知
プロセスで必ず判断を行うため処理時間がかかるという
問題があった。本発明はヘッダファイルへの配送・通知
プロセスのアクセス待ちや配送・通知プロセスによる最
終プロセスの判断等のチェック処理を不用にしてシステ
ムのスループットを向上することができるメールヘッダ
アクセス方式を提供することを目的とする。

【０００９】

【課題を解決するための手段】図１は本発明の原理構成
図である。図１において，１０−１〜１０−４は配送プ
ロセス，第１通知プロセス，第２通知プロセス，第３通
知プロセスで，１１−１〜１１−４は各プロセス１０−
１〜１０−４から発生したプロセス間通信用のデータが
格納されるキュー，１２はヘッダ管理プロセス，１３は
ヘッダファイルである。本発明はヘッダ管理プロセスを
新たに設け，各配送・通知プロセスはヘッダ管理プロセ
スに対しＯＳによるシステムコールでプロセス間通信キ
ューへ書き込み，ヘッダ管理プロセスによりヘッダファ
イルへの書き込みとチェック処理を行うものである。

【００１０】

【作用】配送プロセスや各通知プロセスが発生すると，
それぞれのプロセス１０−１〜１０−４は，それぞれの
処理中の状況や処理終了の結果をヘッダ管理プロセス１
２に通知を行う。この通知はＯＳ（オペレーティングシ
ステム）のシステムコールにより行われ，対応するキュ
ー１１−１〜１１−４の１つに登録される。ヘッダ管理
プロセス１２はこれらのキューを順次取り出し，配送・
通知プロセスから送られた状況をヘッダファイル１３へ
書き込む。さらに，チェック（最終条件）を行って，最
終の場合はヘッダファイル１３をジャーナル化すると共
にメールファイルの削除の処理を行う。このようにして
，ヘッダ管理プロセスを設けることによりヘッダプロセ
スへのアクセス集中や配送・通知プロセスにおけるチェ
ック処理を不用にすることができる。なお，プロセス間
通信用のキュー１１−１〜１１−４の数はそれぞれ１つ
だけで十分であり，ヘッダ管理プロセスの構造が簡単で
あるが，条件により複数設けることができる。

【００１１】

【実施例】図２は本発明が実施されるセンタのハードウ
ェア構成図，図３はセンタのソフトウェア構成図，図４
は実施例のヘッダアクセスの構成図，図５は実施例の各
プロセス間の動作シーケンスである。図２にはセンタの
主要な装置だけが示され，センタ全体の処理を行う中央
処理装置（ＣＰＵ）２０，データ及びプログラムを格納
するメモリ２１，交換機（図６の５２）と接続して電話
機やＦＡＸと接続する回線が収容される複数の回線制御
装置２２，メールや，各種のファイルが格納される大容
量のディスク２３とを備える。

【００１２】図３には上記のハードウェア構成に対して
，センタが備えるソフトウェア構成が示されている。 電話機やＦＡＸの回線を収容する回線制御装置２２に対
する制御を行うプログラムであるドライバ２５，ユーザ
プログラムである各プロセスを管理するオペレーション
・システム２４及びユーザプログラム（アプリケーショ
ンプログラム２６）である配送プロセス，受付通知プロ
セス，着信通知プロセス，結果通知プロセス及び本発明
によるヘッダ管理プロセスや，従来からある配送管理プ
ロセス，状況確認プロセス，通知管理プロセス，送信メ
ールプロセス等で構成する。

【００１３】図４に示す実施例の構成を説明する。図に
おいて，４０は配送プロセス，４１は受付通知プロセス
，４２は着信通知プロセス，４３は結果通知プロセス，
４４はヘッダ管理プロセス，４５はヘッダファイル，４
６は状況確認プロセス，４７はジャーナルファイルであ
る。配送プロセス４０や各通知プロセス４１〜４３は従
来のヘッダファイルへの排他的書き込みを行わずに，処
理の途中または結果のメッセージをプロセス間通信用キ
ューに送るシステムコール（例えばＵＮＩＸのｍｓｇｓ
ｎｄ）によりヘッダ管理プロセスへ送出する。処理結果
のメッセージをヘッダ管理プロセスへ送ったら，各プロ
セス４０〜４３は終了する。

【００１４】次にヘッダ管理プロセス４４は，常にプロ
セス間通信用キューから受信する処理（例えばＵＮＩＸ
のｍｓｇｒｃｖ）によりメッセージを待ち，メッセージ
が存在した場合は，メッセージ内容に従ってヘッダファ
イル４５を更新（状況フラグ更新とカウント情報をカウ
ントアップ）を行う。さらにカウンタ情報が条件に達し
たら，ヘッダファイル４５をジャーナルファイルへ転送
すると共にメールファイルの削除を行う。この後ヘッダ
管理プロセス４４を終了する。さらに，カウンタ情報が
条件を満足していない場合は，メッセージ待ちの状態で
待機する。

【００１５】上記の構成の動作シーケンスを図５に示す
。図５に示すように配送プロセス，受付通知プロセス，
着信通知プロセス，結果通知プロセスのそれぞれにおい
て，起動した後の，処理中通知と処理終了通知が発生す
ると，その都度メッセージがヘッダ管理プロセスに送出
される。ヘッダ管理プロセスは，起動後はメッセージ待
ちの状態で，メッセージを受け取るとその都度ヘッダプ
ロセスへの書き込みを行う。その後最終プロセス条件の
判断をして最終でなければメッセージ待ちに戻る。 最終プロセス条件の判断で最終であることが判ると，ヘ
ッダプロセスのジャーナル化を行うと共にメール本体と
実体ファイルの削除を行い，自からヘッダ管理プロセス
の消滅を行う。

【００１６】

【発明の効果】本発明によれば従来の方式に比べて以下
の点で有利である。■プロセス間通信はキューの構成を
持つので，キューの大きさを予想される最大プロセス数
にしておけば配送・通知プロセスはアクセス待ちになる
ことが無い。■配送・通知プロセスで１つの依頼メール
に対する最終プロセスであることを意識しなくても良い
（チェック処理不用）。■以上の機能をメール・プロセ
ス等のシステム資源を浪費せずに実現できる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】本発明が実施されるセンタのハードウェア構成
図である。

【図３】センタのソフトウェア構成図である。

【図４】実施例のヘッダアクセスの構成図である。

【図５】実施例の各プロセス間の動作シーケンスである
。

【図６】従来例の情報通信システムの動作説明図である
。

【図７】センタのファイル構成である。

【図８】センタにおける従来のメールの配送・通知処理
の構成である。

【図９】従来のヘッダ管理方式の構成図である。

【符号の説明】

１０−１　　　　　　配送プロセス

Claims (2)

【特許請求の範囲】
1. 【請求項１】　　マルチメディア情報通信センタにおけ
   る配送・通知のためのメールヘッダアクセス方式におい
   て，各配送・通知プロセスはヘッダファイルへ書き込む
   メッセージが発生するとプロセス間通信キューへ書き込
   み，ヘッダ管理プロセスを設け，該ヘッダ管理プロセス
   は前記プロセス間通信キューを受信すると順次ヘッダフ
   ァイルへの書き込みを行うことを特徴とするメールヘッ
   ダアクセス方式。
2. 【請求項２】　　請求項１において，前記ヘッダ管理プ
   ロセスは，さらに最終処理の判断を行い，最終処理の場
   合メールヘッダのジャーナル化とメール削除の処理を行
   うことを特徴とするメールヘッダアクセス方式。