JPH06274392A - ファイル名による状態管理処理方法 - Google Patents

Abstract

(57)【要約】 【目的】電子メールシステムなどにおけるファイル名に
よる状態管理処理方法に関し，メール等の状態の管理を
効率よく行うことを目的とする。 【構成】ファイルを扱うシステムにおける管理対象の各
状態に対応して，ファイル名の一部または全部が各状態
を示す特定の文字列を含むようにファイル名を定め，管
理対象の状態変化があったときに，ファイルの内容を変
更することなくファイル名を新しい状態に対応するファ
イル名に変更し，ファイル名によってシステムの管理対
象の状態を管理する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は，電子メールシステムな
どにおいて管理対象の状態を管理する処理方法であっ
て，特に，ファイル名により状態を管理することによ
り，効率のよい処理を可能としたファイル名による状態
管理処理方法に関するものである。

【０００２】

【従来の技術】電子メールシステムとは，計算機ネット
ワークにおいて電子的にメールを発信・処理・受信する
一連のシステムである。従来の電子メールシステムにお
いては，メールの状態を以下のように管理していた。

【０００３】(1) 発信日時の管理 メールを発信する際に，メールの中に発信日時フィール
ドを持ち，そこに発信日時を保持する。

【０００４】(2) メールの種別の管理 種別によってメールの中身が異なるので，その中身を解
析することによって種別を判別する。

【０００５】(3) 受信簿内での状態の管理 受信簿内のメールの検索状態・受け取り状態は，状態管
理ファイルなどの何らかの管理手段を設け，それによっ
て管理する。

【０００６】(4) 同封物の通番の管理 メールの中身で通番を管理し，通番を知る必要がある場
合にはメールの中身を解析することによって判別する。

【０００７】

【発明が解決しようとする課題】従来の電子メールシス
テムにおけるメールの状態の管理は，メールそのものの
中に状態を示す情報を保持したり，状態を管理する機構
を別に設けたりしているので，以下のような欠点があっ
た。

【０００８】(1) 情報がメールの中に存在するため，情
報を獲得・設定するためには，ファイルをオープン（Ｏ
ＰＥＮ）しなければならない。 (2) メールの中身を解析しなければ，そのメールの種別
がわからない。

【０００９】(3) 状態を管理する機構を別に設けること
により，管理機構が複雑になり，また，状態を把握した
り状態を変化させたりする場合には，メールや管理ファ
イルの内容を参照・更新する必要があるため，処理に時
間がかかる。

【００１０】電子メールシステムに限らず，一般のファ
イルを使用するデータ処理システムにおいても，何らか
の状態の管理情報を，通常の場合，ファイルの中に持つ
ようにしているので同様の問題が存在する。なお，状態
の管理情報をファイルではなくメモリに持つシステムも
あるが，管理対象が多い場合には管理対象とその管理情
報との対応づけが難しくなり，またシステムダウンの障
害時や電源ＯＦＦ時に管理情報の内容を保証するのが困
難であるという問題がある。

【００１１】本発明は上記問題点の解決を図り，メール
等の状態の管理を効率よく行うことを目的とする。

【００１２】

【課題を解決するための手段】図１は本発明の原理説明
図である。図中，１０はＣＰＵやメモリなどからなる処
理装置である。

【００１３】本発明では，ファイルを扱うシステムにお
ける管理対象の各状態に対応して，ファイル名の一部ま
たは全部が各状態を示す特定の文字列を含むようにファ
イル名を定め（処理(a) ），作成したファイルに割り当
てる。

【００１４】そして，ファイル名により管理対象の状態
を管理する（処理(b) ）。また，管理対象の状態変化が
あるかどうかを監視し（処理(c) ），状態変化があれ
ば，ファイル名を新しい状態に対応するファイル名に変
更する（処理(d) ）。

【００１５】同様に，電子メールシステムにおいて，メ
ッセージ文書やメール基本情報ファイル等のファイル名
を，メールの各状態に対応して定める。状態変化があれ
ば，そのメールに関するファイルのファイル名を新しい
状態に対応するファイル名に変更し，ファイル名によっ
てメールの状態を管理する。

【００１６】

【作用】ファイル名によって状態がわかるので，ファイ
ルをオープンすることなく，現在の状態を把握すること
ができる。状態の変化に対しても，ファイル名を変更す
るだけでよく，ファイルの実体を更新する必要はない。
また，状態の管理機構を別に設ける必要はなく，既存の
ファイル名を検索する機能を用いるだけで状態管理を実
現できる。

【００１７】また，電子メールシステムにおいて，メー
ルの状態管理に応用した場合には，特にメール未検索
（未読）状態，検索済み状態，取り出し済み状態等を，
ファイル名（拡張子を含む）によって識別することによ
り，管理の簡易化・効率化が可能になる。

【００１８】

【実施例】図２は本発明の実施例による電子メールシス
テムの構成例を示す。本システムは，サーバ・クライア
ント型システムであり，メールの要求を出すクライアン
ト２０と，メールの送配信を行うメールサーバ２１のプ
ロセッサ群を備える。クライアント２０におけるメール
要求処理部２２は，ユーザインタフェースを持ち，メー
ルの送信要求，検索要求などを処理する部分である。

【００１９】ＬＡＮマネージャ２３，２４は，クライア
ント・サーバ間の通信制御機能を持つ。メールサーバ２
１におけるメール管理システム２５は，クライアント２
０からのメールに関する要求を処理する。メール制御部
２６は，クライアント２０からの要求を受信し，クライ
アント接続制御などを行う部分である。プロセス制御部
２７は，要求に応じたプロセスの起動制御を行う。配信
制御部２８は，本システム（以下，自ノードという）内
でのメールの配信か，他系システム（以下，他ノードと
いう）へのメールの配信かを切り分け，そのメールの配
信制御を行う。

【００２０】リモート発信部２９は，メールを他ノード
へ送る制御を行う。通信制御部３１は，他ノードとの通
信を制御する部分である。また，リモート配信部３０
は，他ノードからのメール配信要求を受け付けて処理す
る部分である。通信網３４は，公衆回線などの回線網で
あり，他系システム（他ノード）３５が接続される。

【００２１】依頼キュー３２は，発信依頼があったメー
ルに関する情報が接続されるキューである。メールボッ
クス（ＭＳ）３３は，受信者ごとに用意されるメール情
報の格納庫である。

【００２２】メール発信は次のように行われる。以下，
図２に示すＳ１〜Ｓ８に従って説明する。 （Ｓ１）クライアント２０は，サーバ２１が持つ依頼キ
ュー３２に，メールの基本情報，文書管理情報，メッセ
ージ文書の各ファイルを作成する。

【００２３】（Ｓ２）次に，クライアント２０は，ＬＡ
Ｎマネージャ２３，２４を介して，メール管理システム
２５にメールの発信依頼を行う。 （Ｓ３）メール制御部２６は，その依頼に対し発信簿を
作成し，プロセス制御部２７に配信処理を依頼する。

【００２４】（Ｓ４）プロセス制御部２７は，メール発
信のために配信制御部２８を起動する。 （Ｓ５）配信制御部２８は，メールの宛先に他ノードの
ものがあれば，リモート発信部２９を起動する。

【００２５】（Ｓ６）リモート発信部２９は，通信制御
部３１を介して，宛先の他系システム３５へメールを発
信する。 （Ｓ７）配信制御部２８は，メールの宛先が自ノードで
あれば，その自ノードの宛先にメールを配信する。

【００２６】（Ｓ８）配信制御部２８は，配信完了後，
メールの基本情報，文書管理情報，メッセージ文書を削
除し処理を終了する。また，他系システム３５からのメ
ールの配信（これをリモート配信という）は，図２に示
すＲ１〜Ｒ６のように行われる。

【００２７】（Ｒ１）他系システム３５からのメールの
到着を契機に，リモート配信部３０が動作する。 （Ｒ２）他系システム３５からのメール情報を，通信制
御部３１を介して受け取り依頼キュー３２に接続する。

【００２８】（Ｒ３）リモート配信部３０は，プロセス
制御部２７に発信の依頼を行う。 （Ｒ４）プロセス制御部２７は，メール発信のために配
信制御部２８を起動する。

【００２９】（Ｒ５）配信制御部２８は，自ノードの宛
先にメールを配信する。 （Ｒ６）配信制御部２８は，配信完了後，メールの基本
情報，文書管理情報，メッセージ文書を削除する。ま
た，メール配信のレポートを依頼キュー３２に繋げて発
信依頼を行い，処理を終了する。

【００３０】本実施例におけるメールボックス（ＭＳ）
および依頼キューのディレクトリは，図３に示すような
構成になっている。メールボックス３３−１，３３−
２，…は，各ユーザu0000001，u0000002ごとに設けられ
る。依頼キュー３２は，全員に共通である。図３に示す
点線の矢印はリンク関係を示している。

【００３１】メールボックス３３，依頼キュー３２にお
いて，各ディレクトリは，次のように使用される。ｏｕ
ｔｌｏｇは，メールの付記・発信日時・受信者情報など
のメールの各種情報を保持するファイルが保存されるデ
ィレクトリである。

【００３２】ｉｎｌｏｇは，受信者の受信簿（受信履歴
の管理情報）を保持するディレクトリである。ｂｏｄｙ
ａｔｔｒは，メールで発信した文書または受信者が受信
した文書の管理情報を保持するディレクトリである。

【００３３】ｂｏｄｙｐａｒｔは，メールで発信した文
書本体または受信者が受信した文書本体を保持するディ
レクトリである。図３に示す例では，メール１は，一つ
のメッセージ文書本体を持つメールであり，メール２
は，二つのメッセージ文書本体を持つメールになってい
る。これらのメール１，２に関するファイルの内容は，
図４に示すようになっている。なお，図３に示す〜
は，図４に示す〜のファイルに対応している。

【００３４】ファイル名の拡張子がｉｐｍのファイル
（，）は，メールに関する基本情報を保持するファ
イルである。具体的には，発信日時などの履歴情報，発
信者名や優先度などのエンベロープ（封筒）に関する情
報，有効期限，返信期限などのコンテント情報，ボディ
（文書本体）の種別やボディパート数などの情報，受信
者に関する情報などを持つ。

【００３５】ファイル名の拡張子がａＮＮ（ＮＮは０１
から始まる通番）のファイル（，，）は，メッセ
ージの管理情報を保持するファイルである。例えば，表
題，作成者，作成日時，最終更新日時，更新回数，デー
タ本体サイズ，注釈，版数，ページ数，先頭ページ番
号，所有者，最新登録日時，最終登録日時，有効期限，
キーワード，参照日時などの情報を管理している。

【００３６】ファイル名の拡張子がｃＮＮ（ＮＮは０１
から始まる通番）のファイル（，，）は，文書本
体であるメッセージ（これをボディともいう）を保持す
るファイルである。

【００３７】メッセージの管理情報とメッセージ本体の
ファイルは，ペアでボディ数分存在する。ファイル名の
拡張子がｉｎＸ（Ｘは０，１，２または３）のファイル
は，ｉｐｍのファイルと同様である。

【００３８】他に，ファイル名の拡張子がｉｐｎのファ
イルがあり，このファイル名は，メールの種別が送受信
の結果を報告するレポートであることを示す。エンベロ
ープに関する情報の他に，受信不可通知の場合の受信不
可理由，廃棄理由，コメントなどの情報，受信通知の場
合の受信日時，受信タイプ（手動／自動）などの情報を
持つ。

【００３９】メール１をユーザu0000002からユーザu000
0001に対して発信した場合を例に説明する。発信者（u0
000002）がメール１を発信する場合，依頼キュー３２の
ディレクトリｏｕｔｌｏｇに，「メール１．ｉｐｍ」の
ファイル名を持つメール基本情報のファイルを作成す
る。この「メール１．ｉｐｍ」は，発信の際に発信者
（u0000002）のメールボックス３３−２のディレクトリ
ｏｕｔｌｏｇからもポイントされる。また，依頼キュー
３２のｂｏｄｙａｔｔｒにメッセージ管理情報のファイ
ル「メール１．ａ０１」が，ｂｏｄｙｐａｒｔに発信文
書本体のファイル「メール１．ｃ０１」が接続される。

【００４０】依頼キュー３２に溜められたメールは，メ
ール管理システム２５によって受信者（u0000001）のメ
ールボックス３３−１に配信される。メールが配信され
ると，メールボックス３３−１のディレクトリｉｎｌｏ
ｇに「メール１．ｉｎ０」のファイル名を持つ受信簿
（実体は「メール１．ｉｐｍ」と同じ）が作成され，そ
のｂｏｄｙａｔｔｒの配下に「メール１．ａ０１」のメ
ッセージ管理情報，ｂｏｄｙｐａｒｔの配下に「メール
１．ｃ０１」の受信文書本体のファイルが接続される。

【００４１】これらのメール１に関するファイルの内容
は，各ユーザのメールボックス３３と依頼キュー３２に
別に格納されているわけでなく，実際には図３に示すよ
うに実体ファイル４０に共通に格納され，例えばＵＮＩ
Ｘ（米国ＡＴ＆Ｔ社開発のＯＳ）のファイルシステムに
より管理される。

【００４２】すなわち，メールの基本情報を参照する場
合，発信者（u0000002）側は，u0000002／outlog／メー
ル1.ipm のファイルを, 受信者（u0000001）側は，u000
0001／inlog ／メール1.in0 のファイルを参照すること
になるが，実際には同一ファイルを参照することにな
る。これを受信簿・発信簿の共通化という。

【００４３】次に，図５を参照し，本発明の実施例をさ
らに詳しく説明する。前述のように本実施例では，各デ
ィレクトリに保存するファイルは，ファイル名によっ
て，例えば以下の情報が分かるようになっている。

【００４４】(1) 発信者がメールを発信した日時。 (2) 発信者が発信したメールなのか，受信者の状態を伝
えるメールなのか，まだ作成中のメールなのかの種別。

【００４５】(3) 受信者が受信簿内のメールにどのよう
な処理をしたかの状態。 (4) メールの文書内に同封文書があった場合，同封物の
通番。 そのため，各ディレクトリのファイル名を以下のように
決める。 １．ｏｕｔｌｏｇ XXXXXXXX.ipm：メールの種別が発信メールであるこ
とを示す。

【００４６】 XXXXXXXX.ipn：メールの種別がレポー
トであることを示す。 XXXXXXXX.tmp：メールがまだ作成中であることを示
す。 ２．ｉｎｌｏｇ XXXXXXXX.inN：拡張子中のＮ（０〜３）で受信簿の状態
を識別する。

【００４７】０：未検索（未読）状態 １：検索済み状態 ２：取り出し済み状態 ３：削除済み状態 ３．ｂｏｄｙａｔｔｒ XXXXXXXX.aNN：拡張子中のＮＮでボディパートの順位を
示す。

【００４８】すなわち，ボディ数に応じてａ０１，ａ０
２，…の拡張子を付加する。 ４．ｂｏｄｙｐａｒｔ XXXXXXXX.cNN：拡張子中のＮＮで，管理情報のａＮＮに
対応する文書であることを示す。

【００４９】すなわち，ボディ数に応じてｃ０１，ｃ０
２，…の拡張子を付加する。また，上記ファイル名中の
XXXXXXXXは，発信者が発信した日時をキーに生成する。

【００５０】図５において，利用者Ａがメールサーバ２
１にログインした際に，サーバ側は利用者Ａのメールボ
ックス３３のディレクトリｉｎｌｏｇを検索（図５）
し，結果を利用者Ａに伝える。この検索の際に，メール
のファイル名によって状態を判別することができる。

【００５１】利用者Ｂが発信したメールは，一旦，依頼
キュー３２内に保存される（図５）。メールとして発
信したものとレポートとの区別は，メールのファイル名
によって識別することができる。

【００５２】利用者Ａは，未受信のメールがあった場合
には，メールを受信することができる。このときに，メ
ールボックス３３におけるディレクトリｂｏｄｙｐａｒ
ｔとｂｏｄｙａｔｔｒとの対応がファイル名によって判
別できる（図５）。

【００５３】発信したメールは，配信制御部２８によっ
て読み込まれ（図５），自ノード内であれば配信を行
う（図５）。他ノード宛であれば，リモート発信部２
９に依頼し（図５），外部へ発信する（図５）。

【００５４】図６は，本発明の実施例によるメール発信
処理フローチャートを示す。メール発信では，以下の処
理を行う。 (a) メール発信要求に対し，依頼キュー３２内で一意な
ファイル名を生成する。

【００５５】(b) そのファイル名の拡張子をｔｍｐとし
てファイルを作成する。 (c) ファイルにメールの情報を書き込む。 (d) 作成したファイルが基本情報（ＩＰＭ）のファイル
の場合，処理(e) を実行し，レポート情報のファイルの
場合，処理(f) を実行する。

【００５６】(e) ファイル名の拡張子をｉｐｍとする。 (f) ファイル名の拡張子をｉｐｎとする。 (g) メールサーバ２１に発信処理を依頼する。

【００５７】図７は，本発明の実施例によるメール受信
の際のメールボックス検索処理フローチャートを示す。
未読メールに対する検索要求に対しては，図７に示す
（イ）の処理を行う。

【００５８】(a) メールボックス３３におけるｉｎｌｏ
ｇ内のファイルを検索する。 (b) ファイル名の拡張子がｉｎ０のファイルを探す。な
ければ，処理を終了する。

【００５９】(c) 拡張子がｉｎ０のファイルがあれば，
そのファイル名を要求元に返却する。 (d) 拡張子をｉｎ１に変更し，検索済みであることを示
す。

【００６０】また，受信メールの取り出し要求に対して
は，図７に示す（ロ）の処理を行う。 (e) メールボックス３３におけるｉｎｌｏｇ内のファイ
ルを検索する。

【００６１】(f) 指定ファイル内容を要求元に返却す
る。 (g) 拡張子をｉｎ２に変更し，取り出し済みであること
を示して処理を終了する。

【００６２】また，文書削除要求に対しては，図７に示
す（ハ）の処理を行う。 (h) ｂｏｄｙｐａｒｔ，ｂｏｄｙａｔｔｒディレクトリ
内のファイルを検索する。

【００６３】(i) 指定されたファイル名のｂｏｄｙｐａ
ｒｔ，ｂｏｄｙａｔｔｒ配下のファイルを削除する。 (j) ｉｎｌｏｇディレクトリ内を検索する。

【００６４】(k) 指定ファイル名の拡張子をｉｎ３に変
更し，削除済みであることを示して処理を終了する。 電子メールシステムにおけるファイル名を以上のように
扱うことにより，電子メールシステムの負荷を次のよう
に軽減することができる。

【００６５】(1) メールボックスのｉｎｌｏｇ内の検索
（未受信・受信済み等）をする場合に，ファイル名でメ
ールの状態を把握することができるので，ファイルをオ
ープンせずに済み，処理の高速化が図れる。

【００６６】(2) メール管理システム２５内の配信プロ
セス（配信制御部２８）は，依頼キュー３２のｏｕｔｌ
ｏｇのファイル名を見ることによって，メールの種別を
判定できるので，メールの中身を解析せずに処理の切り
分けを行うことができる。

【００６７】(3) メール作成中にシステムがダウンした
場合，依頼キュー３２のファイル名を見ることによっ
て，作成中のメールであるか否かを判定できるので，リ
カバリ処理が単純になる。

【００６８】以上，電子メールシステムを例に説明した
が，本発明は電子メールシステムに限らず，ファイルを
扱うシステムにおいて，同様にファイル名により状態を
管理することにより，状態管理に関する処理の効率化を
図ることができる。

【００６９】

【発明の効果】以上説明したように，本発明によれば，
ファイルをオープンすることなく，ファイル名によって
状態がわかるので，状態管理を効率的に行うことができ
るようになる。また，電子メールシステムにおいて，メ
ールの状態管理に用いることにより，メール情報の管理
の簡易化・効率化が可能になるという効果がある。

【図面の簡単な説明】

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

【図２】本発明の実施例による電子メールシステムの構
成例を示す図である。

【図３】メールボックスおよび依頼キューのディレクト
リ構成例を示す図である。

【図４】メールのファイル構成例を示す図である。

【図５】本発明の実施例説明図である。

【図６】本発明の実施例によるメール発信処理フローチ
ャートである。

【図７】本発明の実施例によるメール受信の際のメール
ボックス検索処理フローチャートである。

【符号の説明】

１０ 処理装置

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ファイルを使用するデータ処理システム
   における状態管理処理方法において，ファイルを扱うシ
   ステムにおける管理対象の各状態に対応して，ファイル
   名の一部または全部が各状態を示す特定の文字列を含む
   ようにファイル名を定め，前記管理対象の状態変化があ
   ったときに，ファイルの内容を変更することなくファイ
   ル名を新しい状態に対応するファイル名に変更し，ファ
   イル名によってシステムの管理対象の状態を管理するこ
   とを特徴とするファイル名による状態管理処理方法。
2. 【請求項２】 電子的にメールを送受信する電子メール
   システムにおける状態管理処理方法において，メールの
   各状態に対応して，ファイル名の一部または全部が各状
   態を示す特定の文字列を含むようにファイル名を定め，
   発信するメールの状態変化または受信したメールの状態
   変化があったときに，そのメールに関するファイルのフ
   ァイル名を新しい状態に対応するファイル名に変更し，
   ファイル名によってメールの状態を管理することを特徴
   とするファイル名による状態管理処理方法。