JP2002055926A

JP2002055926A - 通信端末、サーバ装置、メール着信通知システム

Info

Publication number: JP2002055926A
Application number: JP2000240479A
Authority: JP
Inventors: Sachiko Takeshita; さち子竹下; Hidenori Ishii; 秀教石井; Hiroshi Uranaka; 洋浦中; Masahide Morozumi; 昌英両角
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2000-08-08
Filing date: 2000-08-08
Publication date: 2002-02-20
Also published as: US7308478B2; US20040059787A1

Abstract

(57)【要約】【課題】送信メールの返信に対する着信通知、送信メ
ールに関係するメールの着信通知、接続業者からユーザ
への着信通知を行えるようにすること。【解決手段】メールを通信端末から送信する場合に、
そのメールに関係する着信通知条件を付加してサーバ装
置へ送信すると、サーバ装置はその情報を着信通知条件
として検出し、登録してインターネットへメールを送信
する。さらに、前記着信通知条件に合致したメールを受
信した場合には通信端末へ着信通知を行い、その条件を
変更する。これにより、メールの送受信時に着信通知条
件を動的に設定変更可能となり、すなわち、送信メール
と関係する着信通知条件をサーバ装置へメール送信時に
登録でき、その着信通知条件にあうメールを受信した場
合には、ユーザへ着信通知として知らせ、着信通知条件
を変更することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子メールの着信
通知を行う通信端末、サーバ装置、メール着信通知シス
テムに関するものである。

【０００２】

【従来技術】従来、一般のユーザ、例えば、ＬＡＮ接続
されていないユーザは、プロバイダなどのインターネッ
ト接続業者と契約し、所有のパーソナルコンピュータな
どの通信端末を公衆網を介しその接続業者へ接続してイ
ンターネット経由で電子メール（以下、メールと記す）
の送受信をおこなっていた。つまり、メールの着信を知
るためにも、公衆網を介して接続業者へ接続し、接続業
者内のメールサーバの自分用メールボックスにメールが
到着しているかどうかチェックしなくてはならなかっ
た。この方法では、ユーザが接続業者へ接続できない場
合には大切なメールが到着しても、ユーザはその到着を
知ることができないため、対応が遅れる可能性が高かっ
た。

【０００３】そこで、近年では、メール着信通知システ
ムとして、特開平１１−２５２１６０号公報に記載され
たものが知られている。特開平１１―２５２１６０号公
報に記載された発明は、ユーザがブラウザソフトウェア
などを用いて、接続業者へ予め条件を設定しておき、接
続業者が受信したメールがその条件に合致した場合には
ユーザの通信端末へ着信通知するというものである。図
１３にその構成図を示す。図１３は、ユーザが所持しメ
ールの送受信アプリケーションを搭載した携帯情報端
末、パーソナルコンピュータなどの通信端末と、インタ
ーネットから受信したメールを公衆網に接続されている
通信端末へ配信したり、公衆網に接続された通信端末か
ら送信された電子メールをインターネットへ送信したり
するサーバ装置を有する接続業者、例えばプロバイダな
どで構成されている。通信端末１３０１は、キーボー
ド、マウスなどの入力を受け付ける入力手段１３０１０
１、メール着信通知条件をプロバイダへ設定するための
条件設定手段１３０１０２、メールを送信するメール送
信手段１３０３０３、メールを受信するメール受信手段
１３０１０４、公衆網と介して接続業者へ接続する接続
手段１３０１０５を有する。公衆網とインターネット接
続との仲介を行い、インターネット経由で受信したメー
ルの管理、保管などを行う接続業者１３０５は、ウェブ
サーバ１３０４、条件管理サーバ１３０３、メールサー
バ１３０２により構成されおり、その間はＬＡＮ（Loca
lAreaNetwork）などでネットワーク接続されていること
とする。

【０００４】ウェブサーバ１３０４は、通信端末１３０
１からブラウザなどのソフトウェアを介して設定された
着信通知条件を受信し、それを条件管理データベースへ
格納する条件格納手段１３０４０１を有する。条件管理
サーバ１３０３は、ユーザ電話番号などの公衆網上のユ
ーザ情報、メール送信者（From）などの前記着信通知条
件を管理する条件管理データベース１３０３０１を有す
る。メールサーバ１３０２は、インターネット経由で受
信したメールをメールボックス１３０２０５へ格納する
受信手段１３０２０２、条件管理データベース１３０３
０１から受信メールのヘッダから宛先ユーザの着信通知
条件を獲得し条件にマッチングするか判断する判断手段
１３０２０３、その判断結果を受けて宛先ユーザへ着信
通知を実際に行う着信通知手段１３０２０４、ユーザへ
メールの配信を行う配信手段１３０２０６、メールを送
信する送信手段１３０２０１を有する。

【０００５】その動作について説明する。まず、通信端
末１３０１から接続業者１３０５に対しメール着信通知
条件を登録する場合の動作について説明する。ユーザ
は、キーボードなどの入力手段１３０１０１からブラウ
ザなどのソフトウェアを立ち上げ、接続手段１３０１０
５を用いて公衆網を介してウェブサーバ１３０４へ接続
する。さらに、入力手段１３０１０１からメール着信条
件、例えば、メールの送信者（From）などを入力し、条
件設定手段１３０１０２を用いてウェブサーバ１３０４
へ条件を送る。ウェブサーバ１３０４では、その条件を
条件格納手段１３０４０１を利用して、条件管理サーバ
１３０３内の条件管理データベース１３０３０１に格納
する。この動作により、接続業者１３０５の条件管理デ
ータベース１３０３０１には、着信通知条件が設定され
る。

【０００６】次に、インターネット経由で接続業者１３
０５がメールを受信し、通信端末１３０１へ着信通知を
送出する場合について説明する。メールサーバ１３０２
は、受信手段１３０２０２を用いてインターネット経由
のメールを受信しメールボックス１３０２０５へ格納す
ると、判断手段１３０２０３により受信メールのヘッダ
から宛先アドレスを抽出し、宛先アドレス用の着信通知
条件と公衆網上の電話番号などのユーザ情報を条件管理
データベースから獲得する。さらに、判断手段１３０２
０３で獲得した着信通知条件が受信メールのヘッダ内に
あるかどうかマッチングを行い、条件に合致しない場合
には着信通知は行わず、条件に合致する場合には着信通
知手段１３０２０４でそのユーザ情報を利用して、宛先
アドレスの通信端末１３０１へ公衆網を介して着信通知
を行う。

【０００７】このように、ユーザから設定された着信通
知条件に合致するメールをプロバイダが受信すると、そ
の条件が変更されないかぎり、メールの着信通知が通信
端末１３０１へ送られるようになる。

【０００８】

【発明が解決しようとする課題】特開平１１−２５２１
６０号公報は、メール送受信時の接続業者への接続とは
別に、接続しブラウザなどで条件を設定する、例えば、
接続業者へ接続し、ブラウザを使ってある送信者（Fro
m）を予め条件として設定すると、その条件を変更しな
いかぎり、条件に合致する送信者のメールを受信するた
びに着信通知を行うという静的な条件設定であった。し
かしながら、送信メールと関係のあるメール、例えば、
返信を着信通知条件として設定するためには、それを確
定するための唯一の条件としてメッセージＩＤが必要と
なるが、メッセージＩＤはメール送信時にメールサーバ
または通信端末で付与されるものであるため、特開平１
１―２５２１６０では、メール送信後にそのメッセージ
ＩＤを獲得する手段、それを着信通知条件として登録す
る手段を設けなくては着信通知条件として登録すること
はできなかった。

【０００９】よって、特開平１１―２５２１６０では、
静的な条件設定は実現できるが、送信メールに密に関係
するメールの着信、例えば、一通のメールの送信時にそ
れに対する返信を着信通知条件として設定し、該当の返
信を受信した場合には着信通知を行って、条件を解除す
るというようなメールの送受信に連動した動的な条件設
定はできないという課題があった。また、特開平１１―
２５２１６０では、インターネットから契約ユーザ宛メ
ールの受信を契機にしてしか着信通知はできず、接続業
者がユーザ宛に通知したい内容、例えば、システム内の
異常検出、保守情報などを着信通知として自発的に知ら
せることはできないという課題もあった。

【００１０】本発明は、上記課題を解消して、送信メー
ルの返信に対して着信通知をするなどの送信メールに密
に関係するメールの着信通知、接続業者がユーザへ通知
したい内容を着信通知として知らせることができる通信
端末、サーバ装置、メール着信通知システムを提供する
ことを目的とする。

【００１１】

【課題を解決するための手段】上記課題を解決するため
に、第一の発明は、メールを通信端末から送信する場合
に、そのメールに関係する着信通知条件を付加してサー
バ装置へ送信すると、サーバ装置はその情報を着信通知
条件として検出し、登録してインターネットへメールを
送信する。さらに、前記着信通知条件に合致したメール
を受信した場合には着信通知を行い、その着信通知条件
を変更（削除を含む）する。これにより、メールの送受
信時に着信通知条件を動的に設定変更可能となり、すな
わち、送信メールと関係する着信通知条件をサーバ装置
へメール送信時に登録でき、その着信通知条件にあうメ
ールを受信した場合には、ユーザへ着信通知として知ら
せ、着信通知条件を変更することができる。

【００１２】第二の発明は、第一の発明において、着信
通知条件が登録されてから、一定時間以上経過しても、
それに該当するメールが受信できない場合にはその条件
を無効にするというものである。これにより、着信通知
条件を格納するメモリに上限があるメール着信通知シス
テムにおいて、着信通知条件に該当するメールが受信で
きない場合に、着信通知条件のメモリが割り当てられた
ままとなって、システム内のメモリが不足することを防
ぐことができる。

【００１３】第三の発明は、第一の発明において、着信
通知条件を登録するときに、着信通知条件数を管理し、
そのまま登録すると最大登録件数以上になる場合にはそ
れを回避する処理を行うものである。これにより、メー
ル着信通知システムの着信通知条件を格納するメモリ容
量を決定することができる。

【００１４】第四の発明は、第一の発明において設定し
た着信通知条件を参照、変更できるというものである。
これにより、メールの送信時に付加しておいた着信通知
条件を、通信端末から参照したり、削除するなどの変更
をフレキシブルに操作できる。

【００１５】第五の発明は、第一の発明の着信通知条件
が、送信メールの返信であるというものである。これに
より、ユーザは送信メールの返信に対して確実に着信通
知を受信することができる。

【００１６】第六の発明は、接続業者が契約ユーザへ通
知したい内容、例えば、システム内の異常や保守などの
緊急性が高い内容を着信通知として知らせることができ
るというものである。これにより、ユーザはインターネ
ットから受信したメール以外にも、接続業者が通知した
い内容があることを着信通知を受信することにより知る
ことができる。

【００１７】

【発明の実施の形態】（実施の形態１）以下、本発明の
実施の形態１について、図１から図５を用いて説明す
る。図１は、メール着信通知システムを示した構成図の
一例である。以下では、着信通知条件として送信メール
の返信を、また、接続業者とユーザはインターネット経
由のメールの送受信を可能とする契約を結んでいること
を前提として説明する。図１において、０１０１はユー
ザが所持しメールの送受信アプリケーションを搭載した
携帯情報端末、パーソナルコンピュータなどの通信端
末、０１０２はインターネットから受信したメールを公
衆網を介して契約ユーザの通信端末へ配信したり、公衆
網を介して契約ユーザの通信端末から送信された電子メ
ールをインターネットへ送信したりするメールサーバ、
０１０３は着信通知条件を管理する条件管理サーバ、０
１０４は公衆網とインターネット接続との仲介をし、Ｌ
ＡＮなどのネットワークで接続されたメールサーバ０１
０２、条件管理サーバ０１０３で構成された接続業者、
例えば、プロバイダを示す。

【００１８】通信端末０１０１において、０１０１０１
はマウス、キーボードなどを介してデータが入力される
入力手段、０１０１０２１はメール送信時に着信通知条
件を付加する条件付加手段、０１０１０２は条件付加手
段により着信通知条件が付加されたメールを送信するメ
ール送信手段、０１０１０４はメールの着信通知を受信
したり、メールデータを受信するメール受信手段、０１
０１０３は公衆網を介した接続業者との通信路を確立
し、データ通信を行い、通信路を解放する接続手段を示
す。メールサーバ０１０２において、０１０２０１１は
条件付加手段０１０１０２１が付与した着信通知条件を
検出する条件検出手段、０１０２０１は通信端末０１０
１が送信したメールにメッセージＩＤを付与して、実際
にインターネットへ送信する送信手段、０１０２０２は
インターネットから送られてきたメールを各宛先のユー
ザ用メールボックスへ格納する受信手段、０１０２０３
は条件管理データベース０１０３０１から着信通知条件
を獲得し、受信手段０１０２０２が受信したメールがそ
れに合致するかどうかを判断する判断手段、０１０２０
４は判断手段０１０２０３の結果が合致する場合に着信
通知を宛先ユーザの通信端末０１０１へ向けて送信する
着信通知手段、０１０２０５は受信手段０１０２０２が
受信したメールを宛先ユーザごとに格納し、管理するメ
ールボックス、０２０２０６は通信端末から受信メール
の配信依頼があったときにその受信メールの配信を行う
配信手段を示す。

【００１９】条件管理サーバ０１０３において、０１０
３０１は着信通知条件、接続業者と契約を結んだユーザ
に関する情報、例えば、電話番号などを保持し、管理す
る条件管理データベースである。図２は、送受信時のメ
ールのヘッダ例であり、ＩＥＴＦ（Internet Engineeri
ng Task Force)のＲＦＣ８２２（Requests for Comme
nts ）に従ったものである。ＲＦＣ８２２では、ヘッダ
部分と本体部分へのメール、メッセージ分割およびヘッ
ダ行の順序や文法を定めている。０２０１は、通信端末
０１０１がメールを送信するときのメールヘッダ、０２
０２はそれがメールサーバ０１０２からインターネット
へ送信されるときのメールヘッダ、０２０３はインター
ネットからメールサーバ０１０２が受信したメールのヘ
ッダを示す。

【００２０】図３は、条件管理データベース０１０３０
１が保持するユーザ情報管理テーブルである。図３に
おいて、０３０１は接続業者と契約を結んでいるユーザ
のメールアドレス、０３０２がメールアドレス０３０１
と同ユーザの公衆網の電話番号、０３０３〜０３０６ま
では着信通知条件を示し、０３０３はメールの送信年月
日・時間、０３０４はメールの題名、０３０５は宛先メ
ールアドレス、０３０６はメールのメッセージＩＤを示
す。

【００２１】図４はメール着信通知システムにおいて通
信端末０１０１から送信メールの返信を着信通知条件と
して登録する場合の処理手順の一例を説明するフローチ
ャートである。

【００２２】次に、図１〜図４を用いて、着信通知条件
を登録する場合の処理手順を説明する。まず、通信端末
０１０１からメールを作成し、返信メールに着信通知を
するかどうか設定し、メールを送信するまでの処理手順
を説明する。ユーザは通信端末０１０１の入力手段０１
０１０１を用いて、送信メールを作成、および、接続業
者がその返信を受信した場合に着信通知をしてもらうか
どうか選択し、メールの送信要求を入力する（ステップ
０４０１）。通信端末０１０１は、入力手段０１０１０
１０からメール送信要求が入力されると、メール送信手
段０１０１０２は、返信メールに対して着信通知を選択
しているかどうかを判断し（ステップ０４０２）、選択
されている場合には条件付加手段０１０１０２１により
返信メールを着信通知条件とする情報を付加し（ステッ
プ０４０３）、選択されていない場合には条件を付加せ
ずに、接続手段０１０１０３から接続業者へ公衆網を介
してダイアルアップ接続して、メールを送信し、送信が
終了したら接続解放する（ステップ０４０４）。条件付
加手段０１０１０２１が着信通知条件として送信メール
の返信を設定した場合の送信メールのヘッダは０２０１
において「Ｘ−Ｒｅｐｌｙ−Ｐｕｓｈ：ＯＮ」とし、設
定していない場合の送信メールのヘッダは０２０１にお
いて「Ｘ−Ｒｅｐｌｙ−Ｐｕｓｈ：OFF」としてＲＦＣ
８２２に従って付与する。

【００２３】次に、通信端末０１０１から送信したメー
ルを接続業者０１０４が受信し、インターネットへメー
ル送信するまでの処理手順を説明する。接続業者０１０
４は、通信端末０１０１が送信したメールをメールサー
バ０１０２の送信手段０１０２０１により受信し（ステ
ップ０４０５）、メッセージＩＤをメールヘッダへ付与
し、条件検出手段０１０２０１１を用いてそのメールの
返信を受信したときに着信通知を送信する希望があるか
どうかをメールヘッダ０２０１により判断する（ステッ
プ０４０６）。そして、メールヘッダが「Ｘ−Ｒｅｐｌ
ｙ−Ｐｕｓｈ：ＯＮ」ならば、条件管理データベース０
１０３０１の該当ユーザテーブル「ｆｏｏ＠ｔｅｓｔ．
ｏｒ．ｊｐ」にメールヘッダの情報を着信通知条件とし
て登録するように条件管理サーバ０１０３へ指示する
（ステップ０４０８）。この指示により、条件管理サー
バ０１０３は、送信年月日および時間０３０３に「２０
００／３／２４０５：３３：４５」、題名０３０４に
「ｍａｉｌｓｕｂｊｅｃｔ」、宛先アドレス０３０５
に「ｂａｒ＠ｘｘｘ．ｃｏ．ｊｐ」、メッセージＩＤ０
３０６に送信手段０１０２０１で付与したメッセージＩ
Ｄ「２００００３２３２０３３．ＦＡＡ１４３０５＠ｔ
ｅｓｔ．ｏｒ．ｊｐ」を登録する（ステップ０４０
７）。メールサーバ０１０２は、条件検出手段０１０２
０１１により条件管理サーバ０１０３に登録されたこと
を確認すると（ステップ０４０８）、送信手段０１０２
０１でインターネットへメール送信する（ステップ０４
０９）。また、「Ｘ−Ｒｅｐｌｙ−Ｐｕｓｈ：ＯＦ
Ｆ」ならば登録せずに、送信手段０１０２０１でインタ
ーネットへメール送信する（ステップ０４０９）。イン
ターネットへ送信するとき、メールヘッダ０２０１は０
２０２のように、「Ｘ−Ｒｅｐｌｙ−Ｐｕｓｈ：ＯＮ／
ＯＦＦ」は削除され、メッセージＩＤ「２００００３２
３２０３３．ＦＡＡ１４３０５＠ｔｅｓｔ．ｏｒ．ｊ
ｐ」が付与されて送信される。ステップ０４０１〜ステ
ップ０４０８により、ユーザは通信端末０１０１を用い
て送信メールの返信を着信通知条件として接続業者０１
０４へ登録することができた。

【００２４】図５は、接続業者０１０４が送信メールの
返信を受信して、通信端末０１０１へ着信通知をする場
合の処理手順の一例である。図１〜図３、図５を用い
て、接続業者０１０４が送信メールの返信を受信して、
通信端末０１０１へ着信通知をするまでの処理手順を説
明する。接続業者０１０４は、インターネットより受信
手段０１０２０２を用いてメールを受信し、メールボッ
クス０１０２０５へ格納し（ステップ０５０１）、受
信したメールヘッダ０２０３から宛先ユーザ「ｆｏｏ＠
ｔｅｓｔ．ｏｒ．ｊｐ」を抽出する。そして、判断手段
０１０２０３を用いて、宛先ユーザのユーザ情報を条件
管理データベース０１０３０１から獲得し（ステップ０
５０２）、ユーザがメール送信時に着信通知条件を設定
していたかどうか、条件が登録されているかどうかによ
りチェックする（ステップ０５０３）。登録していない
場合には処理を終了し（ステップ０５０７）、登録して
いた場合には、その条件に合致する返信メールである
か、すなわち、メールヘッダ０２０３のＲｅｆｅｒｅｎ
ｃｅｓ、または、Ｉｎ−Ｒｅｐｌｙ−Ｔｏのメッセージ
ＩＤと条件管理データベース０１０３０１から獲得した
メッセージＩＤが等しいかどうかチェックする（ステッ
プ０５０４）。判断手段０１０２０３で等しいと判断し
た場合には、該当の着信通知条件を条件管理データベー
ス０１０３０１から削除し（ステップ０５０５）、条件
管理データベース０１０３０１から獲得した電話番号で
電話をかけることで通信端末０１０１へ着信通知を行う
（ステップ０５０６）。

【００２５】また、等しくないと判断された場合には、
着信通知は行わない（ステップ０５０７）。通信端末０
１０１は、接続手段０１０１０３により接続業者０１０
４からの着信通知を受信する（ステップ０５０８）。ス
テップ０５０１〜０５０８により、ユーザは送信したメ
ールの返信が接続業者へ届いたことを着信通知で知るこ
とができる。この接続業者０１０４から通信端末０１０
１の着信通知、および、着信通知の契機となったメール
の獲得は、既存のどんな方法を用いてもよい。例えば、
発番号通知サービスなどにより、契約時に接続業者の番
号をユーザへ通知しておき、通信端末０１０１が鳴動、
または、無鳴動により電話がかかってきたことを認識
し、それが接続業者の番号であることを目で確認して手
動で切断してもよいし、通信端末０１０１にユーザが手
動で行う動作を組み込むことで自動的に切断してもよ
い。そして、切断後に接続手段０１０１０３を用いてダ
イアルアップ接続し、該当メールをメール受信手段０１
０１０４、配信手段０１０２０６を用いて手動で獲得し
てもよい。また、通信端末０１０１は着信通知を知らせ
る接続を接続手段０１０１０３でそのまま維持し、該当
メールをメール受信手段０１０１０４、配信手段０１０
２０６を用いて自動的に獲得してもよい。

【００２６】本発明は、上記の実施の形態に限定され
ず、特許請求の範囲内でいろいろな変更を行うことがで
きる。例えば、以上の説明では、メールサーバ０１０
２、条件管理サーバ０１０３が別々の装置であるように
説明しているが、一部または全体が統合されても、さら
に分散された配置になってもよし、メッセージＩＤをメ
ールサーバ０１０２が付与しているが、通信端末側で一
意に付与してもよい。また、本実施の形態では、送信メ
ールの返信を着信通知条件としているが、これに限定さ
れず、送信メールと密に関係する別の条件を着信通知条
件としてもよい。

【００２７】（実施の形態２）本実施の形態２は、実施
の形態１に対して着信通知条件の削除機構を付加したも
のであり、それに関する処理以外は、実施の形態１と全
く同じように処理動作を行うものとする。以下では、実
施の形態１と同様の前提で説明する。図６は、メール着
信通知システムの構成図の一例である。図６において、
条件管理サーバ０６０３以外は実施の形態１と全く同じ
ものを示す。条件管理サーバ０６０３において、条件管
理データベースは実施の形態１と同様であり、０６０３
０２は条件管理データベース０６０３０１に管理されて
いる着信通知条件がメール送信時間から一定時間、例え
ば、１週間など、の時間が立ったかどうかを監視するタ
イマ管理手段、０６０３０３はタイマ管理手段０６０３
０２が一定時間経たと判断した着信通知条件を変更する
条件削除手段である。

【００２８】メールヘッダ、テーブルについては、それ
ぞれ図２、図３に示す実施の形態１のものと同様であ
る。

【００２９】ユーザが通信端末０１０１から着信通知条
件として送信メールの返信を接続業者０１０４へ登録す
るまでの処理手順は、実施の形態１の図４と同様であ
る。接続業者０１０４がユーザが登録した着信通知条件
に合致するメールを受信したことを、通信端末０１０１
へ着信通知として知らせるまでの処理手順は実施の形態
１の図５と同様である。

【００３０】以下で、実施の形態２において、ユーザが
通信端末０１０１から着信通知条件として登録した送信
メールの返信が、接続業者０１０４で一定時間経過して
も受信されなかった場合の処理について図６を用いて説
明する。まず、タイマ管理手段０６０３０２は、定期的
に、例えば、１回／日、条件管理データベース０１０３
０１の保持する図３に示されたテーブルの送信年月日、
時間０３０３と現在の年月日、時間とを比較し、一定時
間、例えば１週間、経過している着信通知条件があるか
どうかを監視する。すなわち、一定時間経過している着
信通知条件とは、送信メールの返信をメールサーバ０１
０２が受信していないことを示している。

【００３１】一定時間経過している着信通知条件があっ
た場合には、タイマ管理手段０６０３０２は、条件削除
手段０６０３０３を用いて、検出された着信通知条件を
削除する。これらにより、実施の形態１では着信通知条
件に合致するメールを受信するまで条件が保持されたま
まであったが、本実施の形態では一定時間経過しても受
信できなかったメールの着信通知条件は自動的に削除さ
れるようになる。

【００３２】本発明は、上記の実施の形態に限定され
ず、特許請求の範囲内でいろいろな変更を行うことがで
きる。例えば、以上の説明では、メールサーバ０１０
２、条件管理サーバ０６０３が別々の装置であるように
説明しているが、一部または全体が統合されても、さら
に分散された配置になってもよい。また、メッセージＩ
Ｄをメールサーバ０１０２が付与しているが、通信端末
側で一意に付与することも可能である。

【００３３】（実施の形態３）本実施の形態３は、実施
の形態１において、一人のユーザが条件管理データベー
スへ登録できる着信通知条件数を管理し、最大登録件数
以上になることを回避する処理機構を付加したものであ
り、それに関する処理以外は、実施の形態１と全く同様
に処理動作を行うものとする。以下では、実施の形態１
と同様に送信メールの返信を例にして説明する。

【００３４】図７は、メール着信通知システムの構成図
の一例である。図７では、条件管理サーバ０７０３以外
は実施の形態１と全く同じものを示す。条件管理サーバ
０７０３において、条件管理データベースは実施の形態
１と同様であり、０７０３０２は条件管理データベース
０１０３０１へ一人のユーザが登録できる着信通知条件
数を管理し、最大登録件数以上になることを回避する処
理、例えば、最大登録件数以上になる着信通知条件を、
送信年月日、時間の一番古いものに上書きするなどを行
う条件管理手段である。

【００３５】メールヘッダ、テーブルについては、それ
ぞれ図２、図３に示す実施の形態１のものと同様であ
る。

【００３６】以下で、実施の形態１において、ユーザが
通信端末０１０１を用いて着信通知条件を接続業者０１
０４へ登録するときの処理手順について、図７、図８を
用いて説明する。

【００３７】ステップ０８０１〜ステップ０８０４は実
施の形態１の図４のステップ０４０１〜ステップ０４０
４と同様の処理手順である。接続業者０１０４は、通信
端末０１０１から送信されたメールを送信手段０１０２
０１により受信し（ステップ０８０５）、メッセージＩ
Ｄをメールヘッダに付与し、条件検出手段０１０２０１
１を用いてそのメールに対する返信を受信したときに通
信端末０１０１へ着信通知を送信する希望があるかどう
かをメールヘッダ０２０１により判断する（ステップ０
８０６）。そして、メールヘッダが「Ｘ−Ｒｅｐｌｙ−
Ｐｕｓｈ：ＯＮ」ならば、条件管理データベース０１０
３０１の該当ユーザテーブル「ｆｏｏ＠ｔｅｓｔ．ｏ
ｒ．ｊｐ」にメールヘッダの情報を着信通知条件として
登録するように条件管理サーバ０１０３へ指示する（ス
テップ０８１０）。条件管理サーバ０１０３は、その指
示を受けると条件管理手段０７０３０２により、条件管
理データベース０１０３０１に登録したときに、該当ユ
ーザの登録件数が最大登録件数以上になるかどうかをチ
ェックする（ステップ０８０７）。そして、最大登録件
数以上の場合には、一番古い送信年月日、時間である着
信通知条件を検出し（ステップ０８０８）、指示された
情報をステップ０８０８で検出された条件テーブルに上
書きすることで登録する（ステップ０８０９）。また、
最大登録件数以下の場合には指示された情報をそのまま
登録する（ステップ０８０９）。

【００３８】ステップ０８０９の登録により、条件管理
サーバ０１０３に送信年月日、時間０３０３に「２００
０／３／２４０５：３３：４５」、題名０３０４に
「ｍａｉｌｓｕｂｊｅｃｔ」、宛先アドレス０３０５
に「ｂａｒ＠ｘｘｘ．ｃｏ．ｊｐ」、メッセージＩＤ０
３０６に送信手段０１０２０１で付与したメッセージＩ
Ｄ「２００００３２３２０３３．ＦＡＡ１４３０５＠ｔ
ｅｓｔ．ｏｒ．ｊｐ」が条件管理データベースに０１０
３０１に登録された。メールサーバ０１０２は、条件管
理サーバ０１０３の登録を確認すると（ステップ０８１
０）、インターネットへメール送信する（ステップ０８
１１）。また、「Ｘ−Ｒｅｐｌｙ−Ｐｕｓｈ：ＯＦＦ」
ならば登録せずにインターネットへメール送信する（ス
テップ０８１１）。インターネットへ送信するとき、メ
ールヘッダ０２０１は０２０２のように、「Ｘ−Ｒｅ
ｐｌｙ−Ｐｕｓｈ：ＯＮ／ＯＦＦ」は削除され、メッセ
ージＩＤ「２００００３２３２０３３．ＦＡＡ１４３０
５＠ｔｅｓｔ．ｏｒ．ｊｐ」が付与されて送信される。
ステップ０８０１〜ステップ０８１１により、通信端末
０１０１から送信メールの返信を着信通知条件として登
録した。接続業者０１０４が、着信通知条件に合致する
メールを受信したことを、ユーザの所持する通信端末０
１０１へ着信通知として通知するまでの処理手順は実施
の形態１の図５と同様である。

【００３９】本発明は、上記の実施の形態に限定され
ず、特許請求の範囲内でいろいろな変更を行うことがで
きる。例えば、以上の説明では、メールサーバ０１０
２、条件管理サーバ０７０３が別々の装置であるように
説明しているが、一部または全体が統合されても、さら
に分散された配置になってもよいし、メッセージＩＤを
メールサーバ０１０２が付与しているが、通信端末側で
一意に付与してもよい。また、本実施の形態では、条件
管理サーバ０７０３の条件管理手段０７０３０２で、最
大登録件数以上となる着信通知条件を登録してから一番
時間が経過した条件を削除して登録するようにしている
が、最大登録件数以上となる着信通知条件を登録しない
ようにするなどに変更してもよい。

【００４０】（実施の形態４）本実施の形態は、実施の
形態１に対して、メールの送信時に登録した着信通知条
件をメールの送受信とは別の契機に通信端末０１０１か
ら参照し変更する機構を付加したものであり、それに関
する処理以外は、実施の形態１と全く同じように処理動
作を行うものとする。以下では、実施の形態１と同様の
前提で説明する

【００４１】図９は、メール着信通知システムの構成図
の一例である。図９において、通信端末０９０１、ウェ
ブサーバ０９０５以外は実施の形態１と全く同じものを
示す。通信端末０１０１において、０９０１０５、０９
０１０６以外は実施の形態１と同様である。０９０１０
５は、接続手段０１０１０３で接続業者０１０４に接続
されているとき、メール送信時に条件管理データベース
０１０３０１へ登録した着信通知条件を参照する条件参
照手段、０９０１０６はメール送信時に条件管理データ
ベース０１０３０１へ登録した着信通知条件の変更など
を行う条件変更手段である。

【００４２】例えば、条件参照手段０９０１０５は、ブ
ラウザソフトウェアでありＨＴＭＬ（ＨｙｐｅｒＴｅ
ｘｔＭａｋｅｕｐＬａｎｇｕａｇｅ）などの形式を
読み込むことで着信通知条件の設定変更画面などを表示
する。ユーザはその画面から入力手段０１０１０１を用
いて設定変更を入力し、条件変更手段０９０１０６で着
信通知条件の設定変更することができる。接続業者０１
０４において、０９０５はネットワークを管理するウェ
ブサーバ、０９０５０１は図９の通りウェブサーバ上に
あり、ＨＴＭＬ形式で記述されたデータを所持し、条件
管理サーバ０１０３を外部からの入力に従い操作する条
件操作手段である。

【００４３】メールヘッダ、テーブルについては、それ
ぞれ図２、図３に示す実施の形態１のものと同様であ
る。

【００４４】ユーザが通信端末０９０１を介して着信通
知条件として送信メールの返信を接続業者０１０４へ登
録するまでの処理手順は、実施の形態１の図４と同様で
ある。また、接続業者０１０４が着信通知条件に合致す
るメールを受信したときに、着信通知として通信端末０
９０１へ通知する処理手順までは実施の形態１の図５と
同様である。

【００４５】図１０は、着信通知条件を変更する場合の
処理手順の一例である。以下で、実施の形態４におい
て、接続業者０１０４に登録した着信通知条件を通信端
末０９０１を用いて参照、変更する処理手順について図
９、図１０を用いて説明する。まず、ユーザは入力手段
０１０１０１でブラウザソフトウェアの起動と、接続業
者０１０４へ登録してある着信通知条件の一覧表示・変
更画面の呼び出し要求を入力する。通信端末０９０１は
ブラウザソフトウェアを起動し（ステップ１００１）、
接続手段０１０１０３を使って接続業者０１０４へ接続
し、ウェブサーバ０９０５からＨＴＭＬ形式で記述され
た着信通知条件の一覧表示・変更画面を条件参照手段０
９０１０５で読み込む（ステップ１００２、１００
３）。一覧表示・変更画面には、図３に示された情報が
表示されるものとする。

【００４６】次に、ユーザが、ブラウザソフトウェア上
に表示された着信通知条件の一覧表示・変更画面に、入
力手段０１０１０１を用いて設定変更を入力すると（ス
テップ１００４）、条件変更手段０９０１０６からウェ
ブサーバ０９０５にその情報が送られ、条件操作手段０
９０５０１により条件管理データベース０１０３０１上
の該当着信通知情報が更新される（ステップ１００
５）。これらにより、本実施の形態４では着信通知条件
に合致するメールを受信するまで条件が保持されたまま
であったが、本実施の形態ではメールの送受信とは別の
契機で通信端末０９０１から着信通知条件を参照変更す
ることができるようになる。なお、着信通知条件の変更
には着信通知条件の削除も含まれる。

【００４７】本発明は、上記の実施の形態に限定され
ず、特許請求の範囲内でいろいろな変更を行うことがで
きる。例えば、以上の説明では、メールサーバ０１０
２、条件管理サーバ０１０３、ウェブサーバ０９０５が
別々の装置であるように説明しているが、一部または全
体が統合されても、さらに分散された配置になってもよ
い。また、メッセージＩＤをメールサーバ０１０２が付
与しているが、通信端末側で一意に付与してもよい。

【００４８】（実施の形態５）本実施の形態は、実施の
形態１に対して、接続業者がユーザ宛に通知したい内
容、例えば、システム内の異常や保守などの緊急性が高
い情報をメールとして作成し、あたかもインターネット
経由でメールを受信したかのようにユーザへ着信通知を
自発的に送出する機構を付加したものであり、それに関
する処理以外は、実施の形態１と全く同じように処理動
作を行うものとする。以下では、実施の形態１と同様の
前提で、さらに、ユーザ用メールボックスの容量がある
しきい値以上になり、容量あふれをおこしそうだという
ことを接続業者が該当ユーザ宛に通知する場合を例にし
て説明する。

【００４９】図１１は、メール着信通知システムの構成
図の一例である。図１１において、１１０２は、メール
ボックスからメールを獲得しただけではメールが削除で
きないメールサーバ、例えば、ＲＦＣ２０６０で定義さ
れているＩＭＡＰ４（ＩｎｔｅｒｎｅｔＭｅｓｓａｇ
ｅＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）のサーバであ
り、削除するためには、ユーザが意識的に接続業者０１
０４のメールボックスからメールを削除しなくてはなら
ない。メールサーバ１１０２では、１１０２０７以外は
実施の形態１と全く同様である。１１０２０７は、一定
間隔おき、例えば、一回／日に各契約ユーザのメールボ
ックス０１０２０５の容量をチェックし、しきい値以
上、例えば、契約時のメールボックス容量の８０％であ
った場合には、その旨を通知するメールを作成し、メー
ルボックスに格納し、そのユーザ宛に着信通知を行う異
常検出手段である。

【００５０】メールヘッダ、テーブルについては、それ
ぞれ図２、図３に示す実施の形態１のものと同様であ
る。

【００５１】ユーザが通信端末０１０１を介して着信通
知条件として送信メールの返信を接続業者０１０４へ登
録する処理手順までは、実施の形態１の図４と同様であ
る。接続業者０１０４が着信通知条件に合致するメール
を受信したことを、ユーザの所持する通信端末０１０１
へ着信通知として知らせるまでの処理手順は実施の形態
１の図５と同様である。以下で、実施の形態５におい
て、接続業者０１０４が、ユーザのメールボックスの容
量がしきい値以上となり、もう少しで容量あふれが発生
しそうなことを検出し、着信通知として通信端末０１０
１へ知らせる処理手順について図１１、１２を用いて説
明する。

【００５２】まず、異常検出手段１１０２０７は、一回
／日、全契約ユーザのメールボックスの使用率が前容量
の８０％を占めているかどうかのチェックをする（ステ
ップ１２０１）。チェックした結果、８０％値以下であ
る場合には何も処理は行わなず（ステップ１２０５）、
８０％以上である場合には、メールボックスの容量あふ
れが発生しそうなことを通知するメールを作成およびメ
ールボックスへ格納し（ステップ１２０２）、条件管理
データベース０１０３から該当ユーザの公衆網の電話番
号０３０２を獲得し（ステップ１２０３）、その電話番
号へ着信通知を送出する（ステップ１２０４）。通信端
末０１０１は接続手段０１０３、メール受信手段０１０
１０４を用いて、着信通知を受信する（ステップ１２０
６）。

【００５３】ユーザは、通信端末０１０１へ着信通知を
受信すると、接続業者０１０４へダイアルアップなどの
方法で接続し、自分宛のメールを獲得する。そして、そ
の中にメールボックスの容量がもう少しであふれること
を示す接続業者０１０４からのメールを確認し、メール
ボックス内のメールを適宜削除する。これにより、ユー
ザは、メールボックスの容量があふれることを事前に回
避することができる。

【００５４】この接続業者０１０４から通信端末０１０
１の着信通知、および、着信通知の契機となったメール
の獲得は、既存のどんな方法を用いてもよい。例えば、
発番号通知サービスなどにより、契約時に接続業者の番
号をユーザへ通知しておき、通信端末０１０１が鳴動、
または、無鳴動により電話がかかってきたことを認識
し、それが接続業者の番号であることを目で確認して手
動で切断してもよいし、通信端末０１０１にユーザ手動
で行う動作を組み込むことで自動的に切断してもよい。
そして、切断後に接続手段０１０１０３を用いてダイア
ルアップ接続し、該当メールをメール受信手段０１０１
０４、配信手段０１０２０６を用いて手動で獲得しても
よい。また、通信端末０１０１は着信通知を知らせる接
続を接続手段０１０１０３でそのまま維持し、該当メー
ルをメール受信手段０１０１０４、配信手段０１０２０
６を用いて自動的に獲得してもよい。これらにより、接
続業者０１０４がユーザ宛に通知したい内容、例えば、
システム内の異常検出、保守情報などは、その旨を通知
するメールを作成し、着信通知を送出することにより該
当ユーザ宛に通知することができるようになる。

【００５５】本発明は、上記の実施の形態に限定され
ず、特許請求の範囲内でいろいろな変更を行うことがで
きる。例えば、以上の説明では、メールサーバ１１０
２、条件管理サーバ０１０３が別々の装置であるように
説明しているが、一部または全体が統合されても、さら
に分散された配置になってもよいし、メッセージＩＤを
メールサーバ１１０２が付与しているが、通信端末側で
一意に付与してもよい。また、本実施の形態では、接続
業者がユーザ宛に通知したい異常検出、保守情報を、着
信通知とメールにより通知しているが、公衆網としてＩ
ＳＤＮを用いてユーザ・ユーザ情報に通知したい内容を
付加して着信通知を行うことで実現するなど、メールを
使わずに着信通知だけで知らせる既存の方法を用いても
よい。

【００５６】

【発明の効果】以上のように、本発明によれば、第一
は、メールを通信端末から送信する場合に、メールに関
係する着信通知条件を付加してサーバ装置へ送信する
と、サーバ装置はその情報を着信通知条件として検出
し、登録してインターネットへメールを送信するという
ことを備えた。さらに、前記着信通知条件に合致したメ
ールを受信した場合には着信通知を行い、その条件を削
除するということを備えた。これにより、メールの送受
信時に着信通知条件を動的に設定変更可能となり、すな
わち、送信メールと関係する着信通知条件をサーバ装置
へメール送信時に登録でき、その着信通知条件にあうメ
ールを受信した場合には、ユーザへ着信通知として知ら
せ、着信通知条件を削除することができるとう効果が得
られる。

【００５７】第二は、第一の発明において、着信通知条
件が登録されてから、一定時間以上経過しても、それに
該当するメールが受信できない場合にはその条件を無効
にするということを備えた。これにより、着信通知条件
を格納するメモリに上限があるメール着信通知システム
において、着信通知条件に該当するメールが受信できな
い場合に、着信通知条件のメモリが割り当てられたまま
となって、システム内のメモリが不足することを防ぐこ
とができるという効果が得られる。

【００５８】第三は、第一の発明において、着信通知条
件を登録するときに、着信通知条件数を管理し、そのま
ま登録すると最大登録件数以上になる場合にはそれを回
避する処理を行うことを備えた。これにより、メール着
信通知システムの着信通知条件を格納するメモリ容量を
決定することができるという効果が得られる。

【００５９】第四は、第一の発明において設定した着信
通知条件を参照、変更できるということを備えた。これ
により、メールの送信時に付加しておいた着信通信条件
を、通信端末から参照したり、削除するなどの変更をフ
レキシブルに操作できるという効果が得られる。

【００６０】第五は、第一の発明の着信通知条件が、送
信メールの返信であるということを備えたことにより、
送信メールの返信に対して確実に着信通知を受信するこ
とができるという効果が得られる。

【００６１】第六は、接続業者が契約ユーザへ通知した
い内容、例えば、システム内の異常や保守などの緊急性
が高い内容を着信通知として知らせることができるとい
うことを備えた。これにより、ユーザは、インターネッ
トから受信したメール以外にも、接続業者が通知したい
内容があることを着信通知を受信することにより知るこ
とができる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係るメール着信通
知システムの構成を示すブロック図

【図２】本発明のメール着信通知システムにおけるメー
ルヘッダの一例を示す構成図

【図３】本発明のメール着信通知システムにおける条件
管理データベースに保持するテーブルの一例を示す図

【図４】本発明の第１、２、４の実施の形態におけるメ
ール送信時の処理手順を説明するフローチャート

【図５】本発明の第１、２、３、４の実施の形態におい
て、メール受信〜着信通知を送出するまでの処理手順を
説明するフローチャート

【図６】本発明の第２の実施の形態に係るメール着信通
知システムの構成を示すブロック図

【図７】本発明の第３の実施の形態に係るメール着信通
知システムの構成を示すブロック図

【図８】本発明の第３の実施の形態におけるメール送信
時の処理手順を説明するフローチャート

【図９】本発明の第４の実施の形態に係るメール着信通
知システムの構成を示すブロック図

【図１０】本発明の第４の実施の形態において、着信通
知条件の設定変更時の処理手順を説明するフローチャー
ト

【図１１】本発明の第５の実施の形態に係るメール着信
通知システムの構成を示すブロック図

【図１２】本発明の第５の実施の形態の処理手順を説明
するフローチャート

【図１３】従来例に係るメール着信通知システムの構成
を示すブロック図

【符号の説明】

０１０１通信端末０１０１０１入力手段０１０１０２メール送信手段０１０１０２１条件付加手段０１０１０３接続手段０１０１０４メール受信手段０１０２メールサーバ０１０２０１送信手段０１０２０１１条件検出手段０１０２０２受信手段０１０２０３判断手段０１０２０４着信通知手段０１０２０５メールボックス０１０２０６配信手段０１０３条件管理サーバ０１０３０１条件管理データベース０１０４接続業者０２０１通信端末からの送信メールのヘッダ０２０２サーバ装置からの送信メールのヘッダ０２０３返信メールのヘッダ０３０１ユーザアドレス０３０２電話番号０３０３送信年月日、時間０３０４題名０３０５宛先アドレス０３０６メッセージＩＤ０４０１メール作成処理０４０２返信メールの着信通知希望を選択する処理０４０３情報付加処理０４０４メール送信処理０４０５メール受信処理０４０６返信メールの着信通知を判断する処理０４０７着信通知条件を登録する処理０４０８着信通知条件の登録指示と、登録されたこと
を確認する処理０４０９メール送信処理０５０１メール受信手段０５０２ユーザ情報獲得処理０５０３返信メールが着信通知条件として登録有りな
しの判断処理０５０４返信メールの着信通知をするかどうか判断す
る処理０５０５着信通知条件を削除する処理０５０６着信通知を実施する処理０５０７着信通知をしない処理０６０３条件管理サーバ０６０３０２タイマ管理手段０６０３０３条件削除手段０７０３条件管理サーバ０７０３０２条件管理手段０８０１メール作成処理０８０２返信メールの着信通知希望を選択する処理０８０３情報付加処理０８０４メール送信処理０８０５メール受信処理０８０６返信メールの着信通知を判断する処理０８０７着信通知条件数が最大登録数以上になるかど
うかチェックする処理０８０８一番古くに登録した着信通知条件を検索する
処理０８０９着信通知条件を登録する処理０８１０着信通知条件の登録指示と、登録されたこと
を確認する処理０８１１メール送信処理０９０１通信端末０９０１０５条件参照手段０９０１０６条件変更手段０９０５ウェブサーバ０９０５０１条件操作手段１００１ブラウザ起動処理１００２画面読み込み処理１００３要求画面ダウンロード処理１００４変更を入力する処理１００５データベースへ変更を設定する処理１１０２メールサーバ１１０２０７異常検出手段１２０１メールボックス内がひきい値以上かどうかチ
ェックする処理１２０２メールを作成し、メールボックスへ格納する
処理１２０３ユーザ情報を獲得する処理１２０４着信通知を実施する処理１２０５着信通知をしない処理１２０６着信通知受信処理１３０１通信端末１３０１０１入力手段１３０１０２条件設定手段１３０１０３メール送信手段１３０１０４メール受信手段１３０１０５接続手段１３０２メールサーバ１３０２０１送信手段１３０２０２受信手段１３０２０３判断手段１３０２０４着信通知手段１３０２０５メールボックス１３０２０６配信手段１３０３条件管理サーバ１３０３０１条件管理データベース１３０４ウェブサーバ１３０４０１条件格納手段１３０５接続業者

───────────────────────────────────────────────────── フロントページの続き (72)発明者浦中洋大阪府門真市大字門真1006番地松下電器産業株式会社内 (72)発明者両角昌英大阪府門真市大字門真1006番地松下電器産業株式会社内Ｆターム(参考） 5K030 GA18 HA06 HC01 HC13 JT03 KA07 LD14 5K101 KK02 LL01 MM07 NN01 NN11 PP10

Claims

【特許請求の範囲】

【請求項１】キーボード、マウスなどを介してデータ
が入力される入力手段と、メールを受信するメール受信
手段と、メール送信時にそのメールに関係する着信通知
条件を設定する条件付加手段と、そのメールを送信する
送信手段とを具備することを特徴とする通信端末。
【請求項２】メールを送受信し、保管および管理する
サーバ装置において、前記サーバ装置がメールを受信し
たとき着信通知をするかどうかの判断に利用する着信通
知条件を保管および管理する条件管理データベースと、
メールを送信したときに、そのメール内から着信通知条
件を検出し、前記条件管理データベースへ格納する条件
検出手段と、メールを受信したときに、前記条件管理デ
ータベースから着信通知条件を獲得し、着信通知をすべ
きかチェックする判断手段と、その結果、着信通知を行
う場合には受信メールの宛先アドレスが示す通信端末に
対し着信通知を行う着信通知手段と、通信端末から受信
メールの配信依頼があったときに配信を行う配信手段を
具備することを特徴とするサーバ装置。
【請求項３】キーボード、マウスなどを介してデータ
が入力される入力手段と、メールを受信するメール受信
手段と、メール送信時にそのメールに関係する着信通知
条件を設定する条件付加手段と、そのメールを送信する
送信手段とを具備する通信端末、およびメール送受信機
能を有し、メールを受信したとき着信通知をするかどう
かの判断に利用する着信通知条件を保管および管理する
条件管理データベースと、メールを送信したときに、そ
のメール内から着信通知条件を検出し、前記条件管理デ
ータベースへ格納する条件検出手段と、メールを受信し
たときに、前記条件管理データベースから着信通知条件
を獲得し、着信通知をすべきかチェックする判断手段
と、その結果、着信通知を行う場合には受信メールの宛
先アドレスが示す通信端末に対し着信通知を行う着信通
知手段と、通信端末から受信メールの配信依頼があった
ときに配信を行う配信手段を具備するサーバ装置から成
るメール着信通知システム。
【請求項４】条件管理データベースに着信ー通知条件
が登録されてから、その条件の登録からの時間を監視す
るタイマ管理手段と、着信通知条件が一定時間経過して
いるときにはその条件を削除する削除手段を具備するこ
とを特徴とする請求項２記載のサーバ装置。
【請求項５】請求項１記載の通信端末と、請求項４記
載のサーバ装置を具備することを特徴とするメール着信
通知システム。
【請求項６】条件管理データベースに着信通知条件を
新規に登録するときに、最大登録件数以上にならないよ
うに管理し、それ以上となるときはそうならないように
回避する処理を行う条件管理手段を具備することを特徴
とする請求項２記載のサーバ装置。
【請求項７】請求項１記載の通信端末と、請求項６記
載のサーバ装置を具備することを特徴とするメール着信
通知システム。
【請求項８】条件管理データベースへ格納してある着
信通知条件を参照する条件参照手段と、着信通知条件を
変更する条件変更手段とを具備することを特徴とする請
求項１記載の通信端末。
【請求項９】条件管理データベースへ格納した着信通
知条件を通信端末からの要求により操作する条件操作手
段を具備することを特徴とする請求項２記載のサーバ装
置。
【請求項１０】キーボード、マウスなどを介してデー
タが入力される入力手段と、メールを受信するメール受
信手段と、メール送信時にそのメールに関係する着信通
知条件を設定する条件付加手段と、そのメールを送信す
る送信手段とを具備する通信端末、およびメール送受信
機能を有し、メールを受信したとき着信通知をするかど
うかの判断に利用する着信通知条件を保管および管理す
る条件管理データベースと、メールを送信したときに、
そのメール内から着信通知条件を検出し、前記条件管理
データベースへ格納する条件検出手段と、メールを受信
したときに、前記条件管理データベースから着信通知条
件を獲得し、着信通知をすべきかチェックする判断手段
と、その結果、着信通知を行う場合には受信メールの宛
先アドレスが示す通信端末に対し着信通知を行う着信通
知手段と、通信端末から受信メールの配信依頼があった
ときに配信を行う配信手段を具備するサーバ装置から成
り、前記通信端末は、条件管理データベースへ格納して
ある着信通知条件を参照する条件参照手段と、着信通知
条件を変更する条件変更手段とを備え、また、前記サー
バ装置は、前記条件管理データベースへ格納した着信通
知条件を通信端末からの要求により操作する条件操作手
段を具備することを特徴とするメール着信通知システ
ム。
【請求項１１】通信端末からメール送信時に条件管理
データベースに登録する着信通知条件が、前記送信メー
ルに対応する返信とする請求項３、５、７、１０のいず
れかに記載のメール着信通知システム。
【請求項１２】メール受信とは関係なしに、サーバ装
置がユーザへ知らせたい内容を自発的に着信通知として
知らせる手段を具備することを特徴とする請求項２、
４、６、９のいずれかに記載のサーバ装置。
【請求項１３】サーバ装置がユーザへ知らせたい内容
がユーザ用メールボックスがしきい値以上となったこと
である請求項１２記載のサーバ装置。
【請求項１４】メール受信とは関係なしに、サーバ装
置がユーザへ知らせたい内容を自発的に着信通知として
知らせる手段を具備することを特徴とする請求項３、
５、７、１０、１１のいずれかに記載のメール着信通知
システム。
【請求項１５】サーバ装置がユーザへ知らせたい内容
がユーザ用メールボックスがしきい値以上となったこと
であることを特徴とする請求項３、５、７、１０、１１
のいずれかに記載のメール着信通知システム。