JP2011071891A - メール受信通知送信装置、メール受信通知送信システム、メール受信通知送信方法およびプログラム - Google Patents

Abstract

【課題】携帯端末を持つユーザのスケジュールに応じて携帯端末へ受信通知メールを送信することができる。
【解決手段】ウェブメールシステムサーバ１０に新着メールが届いた場合には、現在日時を取得すると共にスケジュールサーバ１２に登録されたスケジュールが参照され、現在のスケジュールの受信通知メールお断りフラグが確認され、受信通知メールお断りフラグが「ＴＲＵＥ」であるか、すなわち受信通知メールの送信が断られているか否かが判断される。受信通知メールの送信が断られている場合には、受信通知メールは送信されず、受信通知メールの送信が断られていない場合には、受信通知メールが生成され、ウェブメールシステムサーバ１０から携帯端末２０へ送信される。これにより、ユーザのスケジュールに応じて携帯端末へ受信通知メールを送信するか否かを決定することができる。
【選択図】 図５

Description

本発明はメール受信通知送信装置、メール受信通知送信システム、メール受信通知送信方法およびプログラムに係り、特にメールの受信通知を携帯端末に送信可能なメール受信通知送信装置、メール受信通知送信システム、メール受信通知送信およびプログラムに関する。

プライベートな連絡を受けられない仕事中、仕事の連絡を受けたくないプライベート時間など、携帯電話所持者の状況に応じて携帯電話の着信を許可する相手を指定したいという要望がある。例えば、特許文献１には、携帯電話機に登録されたスケジュールと電話帳を元に、着信制限を行う機能が提案されている。

特許文献１に記載の発明では、スケジュール上許可されている登録電話番号からの着信に対しては着信処理を行い、許可されていない連絡先からの着信には着信拒否、音声メッセージまたは電子メールにて応答可能時間を知らせる処理等を行う。例えば、「仕事」という内容のスケジュールが登録されている時間帯は、関連付けられた電話帳データ（電話帳グループ「会社」など）からの着信は通常通り受け、それ以外からの着信に対しては、「現在電話に出ることができません。○○時以降にお掛け直し下さい。」等の通知を行う。

特許文献１に記載の発明は、主にプライベートと仕事の切り分けを目的にされている。企業では業務用の携帯電話が支給される場合が多いが、特許文献１に記載の発明により、プライベートと仕事とで携帯電話を使い分ける必要がなくなるという効果がある。

現在、業務上の連絡手段として電話だけではなく電子メールが活用されている。電子メールは、電話に比べて相手の状況を考えなくて良い連絡手段であるものの、業務において緊急対応が必要なメールが少なくないため、受信メールを確認する事はとても大切である。自席にいる時間が短い労働者は、常に所持する携帯電話へ企業メールの転送を行う者がいるが、携帯電話本体にメールが残るためセキュリティの観点から好ましくない。

そのため多くの企業では、携帯電話からネットワーク経由でグループウェアにアクセスし企業メールの閲覧を行うサービスを利用している。特許文献２には、アクセスするタイミングとして新着メールがあることを知らせる手段が提案されている。

特許文献２に記載の発明では、到着通知禁止時間帯（ユーザにより予め設定）以外の時間にメールボックスに電子メールが到着すると、電話機・ポケットベル・ファクシミリ機・別の電子メールアドレスのいずれか宛（ユーザにより予め設定）に到着通知をする。重要度の高い電子メールを受信した場合は到着通知禁止時間帯であっても到着通知をする。

また、特許文献３には、メールとスケジュールを同一サーバ上で管理するグループウェアなどにおいて、送信期限が指定されたメールが受信されると、メール受信者のスケジュール情報を参照し、受信側ユーザがメールを開封する予定時間を探索し、およその開封時間をメール送信者に通知する発明が記載されている。

特開２００５−８６５８４号公報 特開２０００−２０４１８号公報 特開２００２−７３７４０号公報

特許文献２に記載の発明においては、メールの重要度により通知を行うメールの取捨選択ができている。しかしながら、到着通知禁止時間帯は「○月○日○時○分〜○月○日○時○分」という細かい設定はできず、「毎日○時○分〜○時○分」という指定方法である。したがって、睡眠時間の設定には良いかもしれないが、日々のスケジュールには対応できないという問題がある。

特許文献１に記載の発明は、携帯端末側のスケジュール機能を利用するものであるが、グループウェアを利用している企業等では、グループメンバーの予定が閲覧できるため、携帯端末側のスケジュール機能を用いるより、グループウェアのスケジュール機能を用いるほうが便利である。また、携帯電話からネットワーク経由でグループウェアに登録されているスケジュールを確認する場合には、携帯電話側のスケジュール機能の利用は２度手間となり、大変面倒な作業が必要となるという問題がある。

特許文献３に記載の発明は、メールとスケジュールを同一サーバで管理しているが、ここでのキーパーソンはメール送信者であり、受信者は効果を享受できない。また、送信者に通知された開封時間の通りに受診者によりメールが開封されるとは限らず、目安にしかなりえないという問題がある。

また、特許文献１〜３に記載の発明では、業務上の重要度の高い連絡をとる手段として電子メールを用いる場合に、会議や打ち合わせの最中は受信通知を受け取りたくない場合に受け取りを拒否することができないという問題がある。さらに、携帯電話をマナーモードに切り替えた場合には、呼び出しに気付かず、緊急を要する受信通知に対応することができないという問題がある。

本発明は、携帯端末を持つユーザのスケジュールに応じて携帯端末へ受信通知メールを送信することができる受信通知送信装置、メール受信通知送信システム、メール受信通知送信方法およびプログラムを提供することを目的とする。

請求項１に記載の受信通知送信装置は、スケジュールが記憶されたスケジュール記憶手段と、メールを受信するメール受信手段と、前記メール受信手段によりメールが受信されたことを示す受信通知メールであって、前記メール受信手段により受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成する受信通知メール生成手段と、前記メール受信手段によりメールが受信されると、前記スケジュール記憶手段に記憶されたスケジュールに基づいて受信通知メールの送信が可能か否かを判断する送信可否判断手段と、前記送信可否判断手段により受信通知メールの送信が可能と判断された場合には、前記受信通知メール生成手段により生成された受信通知メールを携帯端末へ送信する送信手段と、を備えたことを特徴とする。

請求項１に記載の受信通知送信装置によれば、メールが受信されると、スケジュール記憶手段に記憶されたスケジュールに基づいて受信通知メールの送信が可能か否かが判断され、受信通知メールの送信が可能と判断された場合には受信通知メールが携帯端末へ送信される。受信通知メールとは、受信されたメールのヘッダ情報に含まれる情報のみからなるメールであり、メールが受信されたことを示すものである。これにより、ユーザのスケジュールに応じて携帯端末へ受信通知メールを送信するか否かを決定し、携帯端末への受信通知メールの送信に制限をかけることができる。また、受信通知メールにメール本文の内容が含まれないため、メールの内容が漏洩することが無く、安全性を高めることができる。

請求項２に記載の受信通知送信装置は、請求項１に記載のメール受信通知送信装置において、前記スケジュール記憶手段は、開始日時と終了日時とが各スケジュール毎に記憶されたスケジュールデータを記録し、前記送信可否判断手段は、現在日時を取得する現在日時取得手段と、前記現在日時取得手段により取得された現在日時が前記スケジュール記憶手段に記憶された所定のスケジュールの開始日時と終了日時との間にあるか否かを判断する第１判断手段と、前記第１判断手段により現在時刻が前記所定のスケジュールの開始日時と終了日時との間にあると判断された場合には、当該所定のスケジュールが所定の条件を満たすか否かを判断する第２判断手段と、前記第２判断手段により前記所定のスケジュールが前記所定の条件を満たすと判断された場合には、受信通知メールの送信が不可能であると判断する第３判断手段と、を有することを特徴とする。

請求項２に記載の受信通知送信装置によれば、現在日時が取得され、取得された現在日時が所定のスケジュールの開始日時と終了日時との間にあるか否かが判断される。現在時刻が所定のスケジュールの開始日時と終了日時との間にあると判断された場合には、所定のスケジュールが所定の条件を満たすか否かが判断され、所定のスケジュールが所定の条件を満たすと判断された場合には、受信通知メールの送信が不可能であると判断される。これにより、ユーザの置かれた状況に応じて携帯端末へ受信通知メールを送信するか否かを決定し、携帯端末への受信通知メールの送信に制限をかけることができる。

請求項３に記載の受信通知送信装置は、請求項２に記載のメール受信通知送信装置において、前記スケジュール記憶手段は、前記スケジュールデータとして開始日時と終了日時と受信通知メールの送信を断るか否かを示す情報と関連付けて記憶し、前記第２判断手段は、前記所定のスケジュールの開始日時と終了日時とに受信通知メールの送信を断ることを示す情報が関連付けられている場合には前記所定の条件を満たすと判断することを特徴とする。

請求項３に記載の受信通知送信装置によれば、所定のスケジュールの開始日時と終了日時とに受信通知メールの送信を断ることを示す情報が関連付けられている場合には、受信通知メールの送信が不可能であると判断される。これにより、受信通知メールの送信が不可能であるか否かを容易にかつ適切に判断することができる。

請求項４に記載の受信通知送信装置は、請求項２に記載のメール受信通知送信装置において、前記スケジュール記憶手段は、前記スケジュールデータとして開始日時と終了日時とスケジュールの内容を簡潔に示す情報であるスケジュールタイプと関連付けて記憶し、前記第２判断手段は、前記所定のスケジュールの開始日時と終了日時とに関連付けられたスケジュールタイプに基づいて前記所定の条件を満たすか否かを判断することを特徴とする。

請求項４に記載の受信通知送信装置によれば、所定のスケジュールの開始日時と終了日時とに関連付けられたスケジュールタイプに基づいて受信通知メールの送信が可能か否かが判断される。これにより、スケジュールデータに受信通知メールお断りフラグが無い場合においても受信通知メールを送信するか否かを決定することができる。

請求項５に記載の受信通知送信装置は、請求項２に記載のメール受信通知送信装置において、前記第２判断手段は、前記所定のスケジュールのスケジュールデータに所定の文字が含まれるか否かを解析し、前記所定のスケジュールのスケジュールデータに所定の文字が含まれる場合には前記所定の条件を満たすと判断することを特徴とする。

請求項５に記載の受信通知送信装置によれば、所定のスケジュールのスケジュールデータに所定の文字が含まれる場合には、受信通知メールの送信が不可能であると判断される。これにより、スケジュールデータに受信通知メールお断りフラグが無い場合においても受信通知メールを送信するか否かを決定することができる。

請求項６に記載の受信通知送信装置は、請求項２から５のいずれかに記載のメール受信通知送信装置において、前記送信手段は、前記第２判断手段により前記所定のスケジュールが前記所定の条件を満たすと判断された場合に前記所定のスケジュールの終了日時を過ぎたか否かを判断し、前記所定のスケジュールの終了日時を過ぎた場合には、前記受信通知メール生成手段により生成された受信通知メールを携帯端末へ送信することを特徴とする。

請求項６に記載の受信通知送信装置によれば、受信通知メールの送信が不可能であると判断された場合には、所定のスケジュールの終了日時を過ぎたか否かが判断され、所定のスケジュールの終了日時を過ぎた場合には受信通知メールが携帯端末へ送信される。これにより、所定のスケジュールのスケジュール終了後に自動的に受信通知メールが携帯端末へ送信される。したがって、受信通知メールを受信したくない場合には受信をしないという要求、及びメールを受信したことを知りたいという要求の相反する２つの要求を満たすことができる。

請求項７に記載の受信通知送信装置は、請求項１から５のいずれかに記載のメール受信通知送信装置において、前記メール受信手段により受信されたメールの重要度を判断する重要度判断手段を備え、前記送信可否判断手段は、前記重要度判断手段により重要度が高いと判断された場合には、受信通知メールの送信が可能であると判断することを特徴とする。

請求項７に記載の受信通知送信装置によれば、受信されたメールの重要度が判断され、重要度が高いと判断された場合には受信通知メールの送信が可能であると判断される。これにより、重要度の高いメールが受信された場合には、いかなるスケジュールが登録されている場合であっても受信通知メールを送信することができる。したがって、メールの重要度によって受信通知メールの取捨選択ができ、ユーザにとって便利なシステムを提供することができる。

請求項８に記載の受信通知送信装置は、請求項７に記載のメール受信通知送信装置において、前記メール受信手段は、重要度を示す情報が関連付けられたメールを受信し、前記重要度判断手段は、前記重要度を示す情報に基づいてメールの重要度を判断することを特徴とする。

請求項８に記載の受信通知送信装置によれば、重要度を示す情報が関連付けられたメールをが受信され、受信されたメールの重要度を示す情報に基づいてメールの重要度が判断される。これにより、メールが重要であるか否かを容易にかつ適切に判断することができる。

請求項９に記載の受信通知送信装置は、請求項７に記載のメール受信通知送信装置において、前記メール受信手段により受信されたメールを解析するメール解析手段を備え、前記重要度判断手段は、前記メール解析手段によりメールに重要であることを示す文字が含まれていることが解析された場合には重要度が高いと判断することを特徴とする。

請求項９に記載の受信通知送信装置によれば、受信されたメールが解析され、その結果メールに重要であることを示す文字が含まれていることが解析された場合には重要度が高いと判断される。これにより、重要度フラグが設定されていない場合にも重要度が高いか否かを判断することができる。

請求項１０に記載の受信通知送信システムは、請求項１から９に記載のメール受信通知送信装置と、前記携帯端末としての携帯電話とを備えたメール受信通知送信システムであって、前記携帯電話は、動作モードを設定する設定手段と、前記設定手段により設定された動作モードを示す情報を前記メール受信通知送信装置に送信する第１通信手段と、を備え、前記メール受信通知送信装置は、前記第１送信手段から送信された動作モードを示す情報を受信する第２通信手段と、前記送信可否判断手段により受信通知メールの送信が不可能と判断された場合には、前記第１受信手段により受信された動作モードを示す情報を参照し、前記動作モードがマナーモードであるか否かを判断する動作モード判断手段と、を備え、前記第２通信手段は、前記動作モード判断手段により動作モードがマナーモードでないと判断された場合には、マナーモードへの設定指示を前記携帯電話に送信し、前記第１通信手段は、前記第２通信手段から送信された前記マナーモードへの設定指示を受信し、前記設定手段は、前記第１通信手段により前記マナーモードへの設定指示が受信されると、前記動作モードをマナーモードに設定することを特徴とする。

請求項１０に記載の受信通知送信システムによれば、メール受信通知送信装置では、携帯端末から送信された動作モードを示す情報が受信される。メール受信通知送信装置において受信通知メールの送信が不可能と判断された場合には、メール受信通知送信装置では、受信された動作モードを示す情報を参照して動作モードがマナーモードであるか否かは判断される。動作モードがマナーモードでないと判断された場合には、マナーモードへの設定指示がメール受信通知送信装置から携帯電話に送信され、携帯端末では動作モードがマナーモードに設定される。これにより、ユーザに状況に応じて携帯端末の動作モードをサーバ側から自動的に切り替えることができる。したがって、携帯端末へ常時受信通知メールを送信することができる。

請求項１１に記載の受信通知送信システムは、請求項１０に記載のメール送信システムにおいて、前記第２通信手段は、前記メール受信手段によりメールが受信されると前記第１送信手段へ動作モードを示す情報を送信するように指示を送信し、前記第１通信手段は、前記第２通信手段から送信された指示を受信すると前記動作モードを示す情報を送信することを特徴とする。

請求項１１に記載の受信通知送信システムによれば、メールが受信されると携帯端末に動作モードを示す情報を送信するように指示が送信され、携帯端末から動作モードを示す情報が送信される。これにより、必要に応じて動作モードの変更を行い、受信通知メールを送信することができる。

請求項１２に記載のメール受信通知送信方法は、メールを受信するステップと、前記メール受信手段によりメールが受信されたことを示す受信通知メールであって、前記メール受信手段により受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成する受信通知メール生成手段と、前記メールが受信されると、スケジュール記憶手段に記憶されたスケジュールに基づいて受信通知メールの送信が可能か否かを判断するステップと、前記受信通知メールの送信が可能と判断された場合には、メールが受信されたことを示す受信通知メールであって、前記受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成するステップと、前記生成された受信通知メールを携帯端末へ送信するステップと、を実行することを特徴とする。

請求項１３に記載のプログラムは、請求項１２に記載のメール受信通知送信方法を受信通知送信装置に実行させることを特徴とする。

本発明によれば、携帯端末を持つユーザのスケジュールに応じて携帯端末へ受信通知メールを送信することができる。

メール受信通知送信システム１の概略構成図である。 メール受信通知送信システム１の概略ブロック図である。 スケジュールデータの一例である。 メール受信通知送信システム１の受信通知メールの送信処理のフローチャートである。 メール受信通知送信システム１の受信通知メールの送信処理を模式的に示す図である。 メール受信通知送信システム１の受信通知メールの送信処理の変形例１のフローチャートである。 メール受信通知送信システム１の受信通知メールの送信処理の変形例２のフローチャートである。 メール受信通知送信システム１の受信通知メールの送信処理の変形例３のフローチャートである。 メール受信通知送信システム２の概略ブロック図である。 メール受信通知送信システム２の受信通知メールの送信処理のフローチャートである。 メール受信通知送信システム２の受信通知メールの送信処理の変形例のフローチャートである。 メール受信通知送信システム３の概略ブロック図である。 メール受信通知送信システム３の受信通知メールの送信処理のフローチャートである。 メール受信通知送信システム３の受信通知メールの変形例１の送信処理のフローチャートである。 メール受信通知送信システム３の受信通知メールの変形例２の送信処理のフローチャートである。

＜第１の実施の形態＞
図１、図２は本発明の第１の実施の形態に係るメール受信通知送信システム１の概略構成を示す。このシステムは、主として、ウェブメールシステムサーバ１０、携帯端末２０で構成される。ウェブメールシステムサーバ１０と携帯端末２０とは、移動体通信網、インターネットおよびＬＡＮなどで構築されたネットワークを介して相互に接続可能である。

ウェブメールシステムサーバ１０は、携帯端末へ受信通知メールを送信することで新着メールがあることを知らせるものであり、図１、２に示すように、主として、メールサーバ１１、スケジュールサーバ１２、新着メール確認部１３、スケジュールデータ確認部１４、受信通知メール送信可否決定部１５、受信通知メール生成開始指示部１６、受信通知メール生成部１７、受信通知メール送信部１８等で構成される。

メールサーバ１１は、ネットワークを介して他の端末等と接続されており、他の端末等から送信されたメールを受信する。

スケジュールサーバ１２は、図３に示すように、携帯端末２０の所有者（以下、ユーザという）のスケジュールデータを記憶する。スケジュールデータは、スケジュールタイプ、件名、場所、開始日時、終了日時、詳細内容、受信通知メールお断りフラグ等が関連付けて記憶されたものであり、ユーザにより予め登録されている。スケジュールタイプとは、スケジュールの内容を簡潔に示すものであり、「会議」、「予定」、「イベント」、「記念日」、「確認」等の登録可能な言葉が定められている。また、受信通知メールお断りフラグとは、受信通知メールの送信を断るか否かを示すものであり、受信通知メールの送信を断る場合には「ＴＲＵＥ」、受信通知メールの送信を断らない場合には「ＦＡＬＳＥ」が設定される。なお、スケジュールデータは、最低限件名、開始日時、終了日時、受信通知メールお断りフラグが含まれていればよく、図３に示す形式に限定されない。また、スケジュールデータに受信通知メールの送信を断るか否かを示すもの含まれていればよく、受信通知メールお断りフラグに限定されない。

新着メール確認部１３は、受信通知メール生成開始指示部１６からの指示に基づき、メールサーバ１１が新たにメールを受信したか否か、すなわちメールサーバ１１に新しいメール（以下、新着メールという）が届いたか否かを判断し、新着メールが届いた場合には、新着メールのヘッダ情報、本文のテキストデータ等を確認する。

スケジュールデータ確認部１４は、現在日時を取得し、現在日時とスケジュールデータとに基づいて現在のスケジュールを確認する。現在日時の取得は、ウェブメールシステムサーバ１０内の図示しない内部時計から取得することができる。

受信通知メール送信可否決定部１５は、スケジュールデータ確認部１４から出力された確認結果に基づいて、受信通知メールを携帯端末２０に送信してよいか否かを決定する。

受信通知メール生成開始指示部１６は、任意時間（規定値、ユーザ設定値など）ごとに、又は受信通知メール送信可否決定部１５の指示により、新着メール確認部１３に対してメールサーバ１１に新着メールが届いたか否かを確認するように指示を出力する。

受信通知メール生成部１７は、新着メールのヘッダ情報（送信者、受信日時、件名など）が内容として含まれる受信通知メールを生成する。

受信通知メール送信部１８は、携帯端末２０との間で、移動体通信網を介して受信通知メールその他のデータを通信する。

また、ウェブメールシステムサーバ１０は、図示しない制御部を備える。制御部は、ウェブメールシステムサーバ１０全体の動作を統括制御する。制御部は、所定のプログラムに従って動作を制御する制御手段として機能する。制御部はメモリ領域を有し、メモリ領域には、制御部が実行するプログラム及び制御に必要な各種データ等が格納される。

携帯端末２０は、携帯電話であり、図２に示すように、主として、メール受信部２１、表示制御部２２、表示部２３等で構成される。また、携帯端末２０は、公知の携帯電話と同様に機能、例えば送話音声を入力するマイクロフォンと、受話音声を出力するスピーカと、マイクロフォンから入力された音声の符号化及び受信した音声の復号化を行う音声処理部等の音声の通話に関わる回路を備えるが、これらは必須ではない。

メール受信部２１は、ウェブメールシステムサーバ１０との間で、移動体通信網を介して受信通知メールその他のデータを通信する。

表示制御部２２は、メール受信部２１が受信した受信通知メールを所定の形式で表示部２３に表示する。

表示部２３は、白黒表示又はカラー表示が可能な液晶ディスプレイ、有機ＥＬ等のディスプレイである。表示部２３は、ウェブメールシステムサーバ１０から送信された受信通知メールが表示されると共に、各種設定操作を行なう際のユーザインターフェース（ＧＵＩ）表示パネルとして利用される。

また、携帯端末２０は、図示しない制御部を備える。制御部は、携帯端末２０全体の動作を統括制御する。制御部は、所定のプログラムに従って動作を制御する制御手段として機能する。制御部はメモリ領域を有し、メモリ領域には、制御部が実行するプログラム及び制御に必要な各種データ等が格納される。

このようにして構成されたメール受信通知送信システム１の作用について説明する。このメール受信通知送信システム１の処理をウェブメールシステムサーバ１０および携帯端末２０に実行させるためのプログラムはウェブメールシステムサーバ１０や携帯端末２０の処理部内のメモリ領域又は図示しない記憶媒体に記憶されている。

図４は、受信通知メールの送信処理の流れを示すフローチャートである。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時に該当するスケジュールがあるか否かは、スケジュールデータから各スケジュールの開始日時と終了日時とを取得し、あるスケジュールの開始日時と終了日時との間に現在日時があるか否かにより判断される。図３に示すスケジュールデータがスケジュールサーバ１２に記憶されており、現在日時が２００９年２月２３日１０時である場合は、現在は件名「会議」のスケジュールが該当するスケジュールであると判断される。

現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、該当するスケジュールの受信通知メールお断りフラグを確認し、受信通知メールお断りフラグが「ＴＲＵＥ」であるか、すなわち受信通知メールの送信が断られているか否かを判断する（ステップＳ１２）。スケジュールデータ解析部１４は、ステップＳ１１で得られた結果を受信通知メール送信可否決定部１５へ出力する。

受信通知メールお断りフラグが「ＴＲＵＥ」である場合、すなわち受信通知メールの送信が断られている場合（ステップＳ１２でＹＥＳ）には、受信通知メールの送信が不可能であるため、受信通知メール送信可否決定部１５が受信通知メールを送信しないことを決定する。例えば、現在日時が２００９年２月２３日１０時である場合は、図３より現在日時は件名「会議」のスケジュールが該当するスケジュールであり、件名「会議」のスケジュールの受信通知メールお断りフラグは「ＴＲＵＥ」である。したがって、受信通知メール送信可否決定部１５は、受信通知メールを送信しないことを決定する。この判断は、受信通知メールお断りフラグに基づいて行われるため、受信通知メールの送信が断られているか否かを容易にかつ適切に判断することができる。そして、処理が終了される。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、及び受信通知メールお断りフラグが「ＦＡＬＳＥ」である場合、すなわち受信通知メールの送信が断られていない場合（ステップＳ１２でＮＯ）には、受信通知メール送信可否決定部１５は受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

これにより、図５に示すように、現在日時に該当するスケジュールがあり（ステップＳ１１でＹＥＳ）、受信通知メールの送信が断られている（ステップＳ１２でＹＥＳ）には、携帯端末２０へ受信通知メールが送信されず、その他の場合（現在日時に該当するスケジュールが無い場合（ステップＳ１１でＮＯ）、及び現在日時に該当するスケジュールがあり（ステップＳ１１でＹＥＳ）、受信通知メールの送信が断られていない場合（ステップＳ１２でＮＯ））には、携帯端末２０へ受信通知メールが送信される。

携帯端末２０のメール受信部２１は受信通知メールを受信し、表示制御部２２が受信通知メールを所定の形式で表示部２３に表示する。これにより、図１に示すように、新着メールのヘッダの内容を含むが本文の内容は含まない受信通知メールが表示部２３に表示される。

本実施の形態によれば、グループウェアのようにメールサーバとスケジュールサーバを有するサーバの処理だけで、携帯端末への受信通知メールの送信に制限をかけることができる。携帯端末側の処理を必要としないため、使用端末の制限がほとんどないという効果もある。

また、本実施の形態では、現在ユーザがおかれている状況に応じて携帯端末へ受信通知メールを送信するか否かを決定し、携帯端末への受信通知メールの送信に制限をかけることができる。したがって、ユーザのスケジュールによって携帯端末が受信する受信通知メールの取捨選択が自動的に行われる便利なメール受信通知送信システムを提供することができる。

また、本実施の形態では、受信通知メールには本文の内容が含まれないため、メールの内容が漏洩することが無く、安全性が高いメール受信通知送信システムを提供することができる。

（第１の実施の形態の変形例１）
第１の実施の形態では、現在日時に該当するスケジュールがあり（ステップＳ１１でＹＥＳ）、受信通知メールお断りフラグが「ＴＲＵＥ」である場合（ステップＳ１１でＹＥＳ）には、受信通知メール送信可否決定部１５により受信通知メールを送信しないことが決定され、処理が終了されたが、該当するスケジュールのスケジュールタイプに基づいて受信通知メールの送信の有無を決定するようにしても良い。

図６は、該当するスケジュールに応じて受信通知メールの送信の有無を決定する処理の流れを示すフローチャートである。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、スケジュールサーバ１２に記憶されたスケジュールデータを参照し、該当するスケジュールが受信通知メールの受信を希望しないスケジュール（例えば、スケジュールタイプが「会議」）であるか否かを判断する（ステップＳ１５）。本変形例では、スケジュールサーバ１２に記憶されたスケジュールデータから、該当するスケジュールのスケジュールタイプを取得し、取得したスケジュールタイプが「会議」である場合には、該当するスケジュールが受信通知メールの受信を希望しないスケジュールであると判断する。受信通知メールの受信を希望しないスケジュールは予め設定されており、図示しないメモリ領域等に記憶されている。スケジュールデータ解析部１４は、ステップＳ１５で得られた結果を受信通知メール送信可否決定部１５へ出力する。

該当するスケジュールが受信通知メールの受信を希望しないスケジュールである場合（ステップＳ１５でＹＥＳ）には、受信通知メール送信可否決定部１５により受信通知メールを送信しないことが決定され、処理が終了される。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、及び該当するスケジュールが受信通知メールの受信を希望しないスケジュールでない場合（ステップＳ１５でＮＯ）には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

これにより、スケジュールデータに受信通知メールお断りフラグが無い場合においても受信通知メールを送信するか否かを決定することができる。

なお、本実施の形態の変形例では、スケジュールタイプに基づいて受信通知メールを送信するか否かを決定したが、決定に用いる指標としてはスケジュールタイプに限定されない。例えば、件名や場所を決定に用いる指標としても良い。また、受信通知メールの受信を希望しないスケジュールタイプは「会議」に限定されず、ユーザが任意に設定するようにしてもよい。

（第１の実施の形態の変形例２）
第１の実施の形態では、現在日時に該当するスケジュールがあり（ステップＳ１１でＹＥＳ）、受信通知メールお断りフラグが「ＴＲＵＥ」である場合（ステップＳ１１でＹＥＳ）には、受信通知メール送信可否決定部１５により受信通知メールを送信しないことが決定され、処理が終了されたが、該当するスケジュールのスケジュールデータの内容に基づいて受信通知メールの送信の有無を決定するようにしても良い。

図７は、該当するスケジュールのスケジュールデータの内容に基づいて受信通知メールの送信の有無を決定する処理の流れを示すフローチャートである。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、スケジュールサーバ１２に記憶されたスケジュールデータの中から該当するスケジュールのテキストデータを解析し、テキストデータにＮＧワードが含まれているか否かを判断する（ステップＳ１６）。ＮＧワードとは、会議、緊急、最優先など受信通知メールの受信を希望しないと想定される言葉である。本実施の形態では、スケジュールデータ解析部１４は、ＮＧワードデータベースを有し、ＮＧワードデータベースにはＮＧワードが予め設定されている。ＮＧワードは、ユーザが携帯端末２０等から任意の言葉を設定することも可能である。スケジュールデータ解析部１４は、ステップＳ１１で得られた結果を受信通知メール送信可否決定部１５へ出力する。

該当するスケジュールのテキストデータにＮＧワードが含まれている場合（ステップＳ１６でＹＥＳ）には、受信通知メール送信可否決定部１５により受信通知メールを送信しないことが決定され、処理が終了される。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、及び該当するスケジュールのテキストデータにＮＧワードが含まれていない場合（ステップＳ１６でＮＯ）には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

これにより、スケジュールデータにＮＧワードが含まれるスケジュールの開催時間中には、受信通知メールを送信しないようにすることができる。また、スケジュールデータに受信通知メールお断りフラグを記憶させることなく、受信通知メールを送信するか否かを決定することができる。

（第１の実施の形態の変形例３）
第１の実施の形態では、現在日時に該当するスケジュールがあり（ステップＳ１１でＹＥＳ）、受信通知メールお断りフラグが「ＴＲＵＥ」である場合（ステップＳ１１でＹＥＳ）には、受信通知メール送信可否決定部１５により受信通知メールを送信しないことが決定され、処理が終了されたが、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールが終了したら受信通知メールを送信するようにしても良い。

図８は、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールが終了したら受信通知メールを送信する処理の流れを示すフローチャートである。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。

現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、該当するスケジュールの受信通知メールお断りフラグを確認し、受信通知メールお断りフラグが「ＴＲＵＥ」であるか、すなわち受信通知メールの送信が断られているか否かを判断する（ステップＳ１２）。スケジュールデータ解析部１４は、ステップＳ１１で得られた結果を受信通知メール送信可否決定部１５へ出力する。

受信通知メールお断りフラグが「ＴＲＵＥ」である場合、すなわち受信通知メールの送信が断られている場合（ステップＳ１２でＹＥＳ）には、受信通知メールの送信が不可能であるため、受信通知メール送信可否決定部１５は、該当するスケジュールの終了日時を迎えたか否かを判断する（ステップＳ１７）。例えば、該当するスケジュールが図３の件名「会議」である場合には、受信通知メール送信可否決定部１５は、現在日時が終了日時である２００９年２月２３日１１時以降であるか否かを判断する。該当するスケジュールの終了日時を迎えていない場合（ステップＳ１７でＮＯ）には、再度ステップＳ１５の処理を行う。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、受信通知メールお断りフラグが「ＦＡＬＳＥ」である場合、すなわち受信通知メールの送信が断られていない場合（ステップＳ１２でＮＯ）、及び該当するスケジュールの終了日時を迎えた場合（ステップＳ１７でＹＥＳ）には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

これにより、受信通知メールの送信を断ることが設定されているスケジュールの間にメールサーバがメールを受信した場合においても、そのスケジュール終了後に自動的に受信通知メールが携帯端末へ送信される。したがって、受信通知メールを受信したくない場合には受信をしないという要求、及びメールを受信したことを知りたいという要求の相反する２つの要求を満たすことができる。

＜第２の実施の形態＞
本発明の第２の実施の形態は、新着メールの重要度に基づいて受信通知メールの送信の有無を決定する処理の流れを示すフローチャートである。以下、第２の実施の形態に係るメール受信通知送信システム２について説明する。なお、第１の実施の形態と同一の部分については、同一の符号を付し、説明を省略する。

図９はメール受信通知送信システム２の内部構成を示すブロック図である。このシステムは、主として、ウェブメールシステムサーバ１０−１、携帯端末２０で構成される。

ウェブメールシステムサーバ１０−１は、携帯端末へ受信通知メールを送信することで新着メールがあることを知らせるものであり、主として、メールサーバ１１、スケジュールサーバ１２、新着メール確認部１３、スケジュールデータ確認部１４、受信通知メール送信可否決定部１５、受信通知メール生成開始指示部１６、受信通知メール生成部１７、受信通知メール送信部１８、新着メール重要度確認部３１等で構成される。

新着メール重要度確認部３１は、新着メールの重要度フラグを確認する。メールサーバ１１が受信するメールには、メール送信者により低、中、高の３種類の重要度フラグが設定されており、新着メール重要度確認部３１は、重要度フラグを確認し、重要度フラグが低、中、高のいずれであるかを判断する。

このようにして構成されたメール受信通知送信システム２の作用について説明する。このメール受信通知送信システム２の処理をウェブメールシステムサーバ１０−１および携帯端末２０に実行させるためのプログラムはウェブメールシステムサーバ１０−１や携帯端末２０の処理部内のメモリ領域又は図示しない記憶媒体に記憶されている。

図１０は、受信通知メールの送信処理の流れを示すフローチャートである。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、メール重要度確認部３１は、新着メールの重要度フラグが低、中、高のいずれであるかを判断する（ステップＳ１８）。

新着メールの重要度フラグが「中」、「低」である場合（ステップＳ１８で中ｏｒ低）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時が２００９年２月２３日１０時である場合は、図３に示すスケジュールデータを参照して、現在は件名「会議」のスケジュールが該当するスケジュールであると判断される。

現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、該当するスケジュールの受信通知メールお断りフラグを確認し、受信通知メールお断りフラグが「ＴＲＵＥ」であるか、すなわち受信通知メールの送信が断られているか否かを判断する（ステップＳ１２）。スケジュールデータ解析部１４は、ステップＳ１１で得られた結果を受信通知メール送信可否決定部１５へ出力する。

受信通知メールお断りフラグが「ＴＲＵＥ」である場合、すなわち受信通知メールの送信が断られている場合（ステップＳ１２でＹＥＳ）には、受信通知メールの送信が不可能であるため、受信通知メール送信可否決定部１５が受信通知メールを送信しないことを決定する。そして、処理が終了される。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、受信通知メールお断りフラグが「ＦＡＬＳＥ」である場合、すなわち受信通知メールの送信が断られていない場合（ステップＳ１２でＮＯ）、及び新着メールの重要度フラグが「高」である場合（ステップＳ１８で高）には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。これにより、新着メールの重要度フラグが「高」の場合には、スケジュールによらず常に受信通知メールが生成される。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

携帯端末２０のメール受信部２１は受信通知メールを受信し、表示制御部２２が受信通知メールを所定の形式で表示部２３に表示する。これにより、受信通知メールが表示部２３に表示される。

本実施の形態によれば、重要度の高いメールが受信された場合には、いかなるスケジュールが登録されている場合であっても受信通知メールを送信することができる。したがって、メールの重要度によって受信通知メールの取捨選択ができ、ユーザにとって便利なシステムを提供することができる。また、メール送信者により設定された重要度フラグに基づいて重要度を判断するため、メールが重要であるか否かを容易にかつ適切に判断することができる。

なお、本実施の形態では、新着メールの重要度フラグが「高」の場合（ステップＳ１８で高）には、スケジュールによらず常に受信通知メールが生成、送信されたが、スケジュールによらず常に受信通知メールを生成、送信する重要度フラグの設定は任意である。ユーザが設定することより、重要度フラグが「高」、「中」の場合には、スケジュールによらず常に受信通知メールが生成、送信されるようにすることも可能である。

また、本実施の形態では、重要度フラグに基づいて重要度の高いメールか否かを判断したが、重要度の高いメールか否かを判断する指標はこれに限られない。例えば、新着メールのヘッダに含まれる送信元のアドレスが所定の条件を満たす場合には、重要度が高いと判断し、常時受信通知メールを送信するようにしても良い。例えば、アドレスデータベースに所望のアドレスを登録しておき、送信元のアドレスがアドレスデータベースに登録されているアドレスである場合には、所定の条件を満たすとすればよい。また、公知のメール振り分け機能を用いて、所定のフォルダにメールが振り分けられた場合には、常時受信通知メールを送信するようにしても良い。

また、新着メールのヘッダを確認し、ユーザのアドレスが「To」に含まれているか「cc」に含まれているかによって常時受信通知メールを送信するか否かを変えるようにしてもよい。例えば、ユーザのアドレスが「To」に含まれている場合には、重要度の高いメールであると判断するようにすれば良い。

（第２の実施の形態の変形例）
第２の実施の形態では、新着メールの重要度フラグに応じて常時受信通知メールを送信するか否かを決定したが、常時受信通知メールを送信するか否かを決定する指標は重要度フラグに限定されない。

第２の実施の形態の変形例は、件名に重要ワードが含まれるか否かに応じて受信通知メールを送信するか否かを決定する形態である。図１１は、件名に重要ワードが含まれるか否かに応じて受信通知メールを送信するか否かを決定する処理の流れを示すフローチャートである。

新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール重要度確認部３１は、新着メールの件名のテキストデータを確認し、重要ワードが含まれるか否かを判断する（ステップＳ１９）。重要ワードとは、重要、至急、緊急など、重要であることを示す言葉である。新着メール重要度確認部３１は、重要ワードデータベースを有し、重要ワードデータベースには重要ワードが予め設定されている。

新着メールの件名に重要ワードが含まれない場合（ステップＳ１９でＮＯ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時が２００９年２月２３日１０時である場合は、図３に示すスケジュールデータを参照して、現在は件名「会議」のスケジュールが該当するスケジュールであると判断される。

現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、該当するスケジュールの受信通知メールお断りフラグを確認し、受信通知メールお断りフラグが「ＴＲＵＥ」であるか、すなわち受信通知メールの送信が断られているか否かを判断する（ステップＳ１２）。スケジュールデータ解析部１４は、ステップＳ１１で得られた結果を受信通知メール送信可否決定部１５へ出力する。

受信通知メールお断りフラグが「ＴＲＵＥ」である場合、すなわち受信通知メールの送信が断られている場合（ステップＳ１２でＹＥＳ）には、受信通知メールの送信が不可能であるため、受信通知メール送信可否決定部１５が受信通知メールを送信しないことを決定する。そして、処理が終了される。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、受信通知メールお断りフラグが「ＦＡＬＳＥ」である場合、すなわち受信通知メールの送信が断られていない場合（ステップＳ１２でＮＯ）、及び新着メールの件名に重要ワードが含まれる場合（ステップＳ１９でＹＥＳ）には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。これにより、新着メールの件名に重要ワードが含まれる場合には、スケジュールによらず常に受信通知メールが生成される。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

携帯端末２０のメール受信部２１は受信通知メールを受信し、表示制御部２２が受信通知メールを所定の形式で表示部２３に表示する。これにより、受信通知メールが表示部２３に表示される。

これにより、重要ワードが件名に含まれている新着メールがある場合は、いかなるスケジュールが登録されている場合であっても受信通知メールを送信することができる。また、重要度フラグが設定されていない場合にも、新着メールの重要度が高いか否かを判断することができる。

なお、スケジュールによらず常に受信通知メールが生成、送信されるのは、重要ワードが件名に含まれている場合に限られない。例えば、重要ワードが本文に含まれている場合には、常時受信通知メールが生成、送信されるようにしてもよい。

なお、本実施の形態及び変形例は、第１の実施の形態、第１の実施の形態の変形例１及び第１の実施の形態の変形例２の少なくとも１つと組み合わせて適用することができる。

＜第３の実施の形態＞
本発明の第３の実施の形態は、利用者のスケジュールデータから判断される状況に応じて携帯電話をマナーモードに切り替える形態である。以下、第３の実施の形態に係るメール受信通知送信システム３について説明する。なお、第１の実施の形態及び第２の実施の形態と同一の部分については、同一の符号を付し、詳細な説明を省略する。

図１２はメール受信通知送信システム３の内部構成を示すブロック図である。このシステムは、主として、ウェブメールシステムサーバ１０−２、携帯端末２０−１で構成される。

ウェブメールシステムサーバ１０−２は、携帯端末へ受信通知メールを送信することで新着メールがあることを知らせるものであり、主として、メールサーバ１１、スケジュールサーバ１２、新着メール確認部１３、スケジュールデータ確認部１４、受信通知メール送信可否決定部１５、受信通知メール生成開始指示部１６、受信通知メール生成部１７、受信通知メール送信部１８、モード設定通信部３２等で構成される。

モード設定通信部３２は、モード設定通信部３３から送信された動作モードを受信する。また、モード設定通信部３２は、動作モードの設定変更が必要な場合には、動作モード切替指示をモード設定通信部３３に送信する。

携帯端末２０は、携帯電話であり、図１２に示すように、主として、メール受信部２１、表示制御部２２、表示部２３、モード設定通信部３３、モード設定部３４等で構成される。

モード設定通信部３３は、携帯端末２０−１の動作モードをウェブメールシステムサーバ１０−２に送信する。また、モード設定通信部３３は、モード設定通信部３２から送信された動作モード切替指示を受信し、モード設定部３４に出力する。

モード設定部３４は、モード設定通信部３３から出力された動作モード切替指示に応じて携帯端末２０−１の動作モードの設定を変更する。携帯端末２０−１の動作モードとしては、通常モードやユーザが設定したモード等着信音を含む通知方法により着信を通知するモード（以下、モードＡという）、着信音を鳴らさず、振動等の携帯端末２０−１を保有するユーザ以外の他人に着信があったことが知られないような方法により着信を通知するマナーモード等が挙げられる。

このようにして構成されたメール受信通知送信システム３の作用について説明する。このメール受信通知送信システム２の処理をウェブメールシステムサーバ１０−２および携帯端末２０−１に実行させるためのプログラムはウェブメールシステムサーバ１０−２や携帯端末２０−１の処理部内のメモリ領域又は図示しない記憶媒体に記憶されている。

図１３は、利用者のスケジュールデータから判断される状況に応じて携帯電話をマナーモードに切り替え、受信通知メールを送信する処理の流れを示すフローチャートである。

最初に、スケジュールデータ解析部１４は、スケジュールデータの受信通知メールお断りフラグを確認し、受信通知メールお断りフラグが「ＴＲＵＥ」である、すなわち受信通知メールの送信が断られている場合には、スケジュールデータからそのスケジュールの開始日時及び終了日時を取得する。そして、スケジュールデータ解析部１４は、現在日時を取得し、現在日時とそのスケジュールの開始日時を比較し、そのスケジュールの開始日時を迎えた場合には、スケジュールデータ解析部１４がそのスケジュールの開始日時を迎えたと判断した場合には、その結果を受信通知メール送信可否決定部１５へ出力し、図１３に示す処理が開始される。

受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、モード設定通信部３３から携帯端末２０−１の動作モードを受信する（ステップＳ２０）。

モード設定通信部３２が携帯端末２０−１の動作モードがモードＡであることを受信すると、モード設定通信部３２は、モード設定通信部３３へマナーモードに切り替えることを示す要求を送信する（ステップＳ２１）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをマナーモードに設定する。これにより、携帯端末２０−１の動作モードがマナーモードに切り替えられ、ユーザが受信通知メールの受信を望まないスケジュールの最中であっても受信通知メールが送信可能となる。

受信通知メールが送信可能となると、新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かの判断結果は、受信通知メール送信可否決定部１５へ出力される。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、受信通知メール送信可否決定部１５は受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。本実施の形態では、マナーモードに設定されているため、受信通知メール送信可否決定部１５は、新着メール確認部１３から新着メールが届いたという判断結果が出力された場合には、常に受信通知メール生成部１７へ指示を出す。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

携帯端末２０のメール受信部２１は受信通知メールを受信し、表示制御部２２が受信通知メールを所定の形式で表示部２３に表示する。これにより、受信通知メールが表示部２３に表示される。

スケジュールデータ解析部１４は、現在日時と受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールの終了日時とを比較し、そのスケジュールの終了日時を迎えた場合には、その結果を受信通知メール送信可否決定部１５へ出力する。受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、ステップＳ２１でマナーモードに切り替えることを示す要求を送信する前の動作モード（本実施の形態ではモードＡ）へ切り替えることを示す要求をモード設定通信部３３へ送信する（ステップＳ２２）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをモードＡに設定する。これにより、モードＡの着信通知方法による通知が開始される。

本実施の形態によれば、スケジュールデータからわかるユーザに状況に応じて携帯端末の動作モードをサーバ側から自動的に切り替えることができる。着信があったことを他人に知られたくない場合、着信を望まない場合等に、携帯端末の動作モードをマナーモードに設定することにより、常時受信通知メールを送信することが可能となる。したがって、ユーザの置かれている状況に関わらず、新着メールが届いたことをユーザに知らせることができる。

なお、本実施の形態では、マナーモードに設定後は、新着メールの重要度によらず受信通知メールを携帯端末へ送信したが、新着メールの重要度を判断し、新着メールの重要度が高い場合にのみ受信通知メールを携帯端末へ送信するようにしても良い。この場合には、ウェブメールシステムサーバ２０−２がメール重要度確認部３１を備えるようにし、メール重要度確認部３１が重要度フラグを確認した結果、新着メールの重要度フラグが「高」である場合にのみ受信通知メールを携帯端末へ送信するようにすればよい。

また、本実施の形態では、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールの開始日時を迎えるとマナーモードに設定し、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールの終了日時を迎えると動作モードを元に戻したが、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールの開始日時を迎えた時にマナーモードに設定する場合に限定されない。例えば、着信音を異ならせるようにしてもよい。また、受信通知メールお断りフラグが「ＴＲＵＥ」であるスケジュールの開始日時を迎えた場合にはスリープモード（制御部のみが動作し、他は動作しない動作モード）に設定し、受信通知メールを送信しないようにしてもよい。これにより、新着メールがあったことを通知することはできないが、ユーザの状況に応じて自動的に携帯端末の動作モードを切り替えることは可能となる。

（第３の実施の形態の変形例１）
第３の実施の形態は、現在日時とそのスケジュールの開始日時を比較し、そのスケジュールの開始日時を迎えた場合には携帯端末２０−１をマナーモードに設定し、そのスケジュールの終了日時を迎えた場合には携帯端末２０−１の動作モードを元に戻したが、携帯端末２０−１をマナーモードに設定するタイミングはこれに限られない。

第３の実施の形態の変形例１は、マナーモードに設定する処理及び動作モードを基に戻す処理を受信通知メールの送信前後に行う形態である。図１４は、マナーモードに設定する処理及び動作モードを基に戻す処理を受信通知メールの送信前後に行う処理の流れを示すフローチャートである。

新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、スケジュールサーバ１２に記憶されたスケジュールデータを参照し、該当するスケジュールが受信通知メールの受信を希望しないスケジュール（例えば、スケジュールタイプが「会議」）であるか否かを判断する（ステップＳ１５）。スケジュールデータ解析部１４は、ステップＳ１５で得られた結果を受信通知メール送信可否決定部１５へ出力する。

該当するスケジュールが受信通知メールの受信を希望しないスケジュールである場合（ステップＳ１５でＹＥＳ）には、受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、モード設定通信部３３から携帯端末２０−１の動作モードを受信する（ステップＳ２０）。

モード設定通信部３２が携帯端末２０−１の動作モードがモードＡであることを受信すると、モード設定通信部３２は、モード設定通信部３３へマナーモードに切り替えることを示す要求を送信する（ステップＳ２１）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをマナーモードに設定する。これにより、携帯端末２０−１の動作モードがマナーモードに切り替えられる。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、該当するスケジュールが受信通知メールの受信を希望しないスケジュールでない場合（ステップＳ１５でＮＯ）、及びマナーモードに切り替えることを示す要求を送信する処理（ステップＳ２１）が終了した場合には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

スケジュールデータ解析部１４は、ステップＳ１５で受信通知メールの受信を希望しないスケジュールと判断されたスケジュールの終了日時を取得すると共に現在日時を取得し、取得された終了日時と現在日時とを比較し、そのスケジュールの終了日時を迎えたか否かを判断する（ステップＳ２３）。スケジュールデータ解析部１４は、その結果を受信通知メール送信可否決定部１５へ出力する。

そのスケジュールの終了日時を迎えていない場合（ステップＳ２３でＮＯ）には、処理が終了される。そのスケジュールの終了日時を迎えた場合（ステップＳ２３でＹＥＳ）には、受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、ステップＳ２１でマナーモードに切り替えることを示す要求を送信する前の動作モード（本実施の形態ではモードＡ）へ切り替えることを示す要求をモード設定通信部３３へ送信する（ステップＳ２２）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをモードＡに設定する。

これにより、必要に応じて動作モードの変更を行い、受信通知メールを送信することができる。

（第３の実施の形態の変形例２）
図１５は、マナーモードに設定する処理及び動作モードを基に戻す処理を受信通知メールの送信時に行う処理の流れを示すフローチャートである。

新着メール確認部１３は、メールサーバ１１に新着メールが届いたか否かを判断する（ステップＳ１０）。新着メールが届いていない場合（ステップＳ１０でＮＯ）には、処理が終了される。

新着メールが届いた場合（ステップＳ１０でＹＥＳ）には、新着メール確認部１３はスケジュールデータ解析部１４に指示を出し、スケジュールデータ解析部１４は、現在日時を取得すると共にスケジュールサーバ１２に記憶されたスケジュールデータを参照し、現在日時に該当するスケジュールがあるか否かを判断する（ステップＳ１１）。現在日時に該当するスケジュールがある場合（ステップＳ１１でＹＥＳ）には、スケジュールデータ解析部１４は、スケジュールサーバ１２に記憶されたスケジュールデータを参照し、該当するスケジュールが受信通知メールの受信を希望しないスケジュール（例えば、スケジュールタイプが「会議」）であるか否かを判断する（ステップＳ１５）。スケジュールデータ解析部１４は、ステップＳ１５で得られた結果を受信通知メール送信可否決定部１５へ出力する。

該当するスケジュールが受信通知メールの受信を希望しないスケジュールである場合（ステップＳ１５でＹＥＳ）には、受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、モード設定通信部３３から携帯端末２０−１の動作モードを受信する（ステップＳ２０）。

モード設定通信部３２が携帯端末２０−１の動作モードがモードＡであることを受信すると、モード設定通信部３２は、モード設定通信部３３へマナーモードに切り替えることを示す要求を送信する（ステップＳ２１）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをマナーモードに設定する。これにより、携帯端末２０−１の動作モードがマナーモードに切り替えられる。

現在日時に該当するスケジュールがない場合（ステップＳ１１でＮＯ）、該当するスケジュールが受信通知メールの受信を希望しないスケジュールでない場合（ステップＳ１５でＮＯ）、及びマナーモードに切り替えることを示す要求を送信する処理（ステップＳ２１）が終了した場合には、受信通知メール送信可否決定部１５が受信通知メールを送信することを決定し、受信通知メール生成部１７へ指示を出す。受信通知メール生成部１７は、指示を受けて受信通知メールを生成する（ステップＳ１３）。

受信通知メール生成部１７が生成した受信通知メールは、受信通知メール送信部１８へ出力され、受信通知メール送信部１８は受信通知メールを携帯端末２０へ送信する（ステップＳ１４）。

受信通知メール送信可否決定部１５は、ステップＳ１５で判断されたスケジュールが受信通知メールの受信を希望しないスケジュールであるか否かを判断する（ステップＳ２５）。

ステップＳ１５で判断されたスケジュールが受信通知メールの受信を希望しないスケジュールである場合（ステップＳ２５でＹＥＳ）には、受信通知メール送信可否決定部１５は、モード設定通信部３２へ指示を出し、モード設定通信部３２は、ステップＳ２１でマナーモードに切り替えることを示す要求を送信する前の動作モード（本実施の形態ではモードＡ）へ切り替えることを示す要求をモード設定通信部３３へ送信する（ステップＳ２２）。モード設定部３４は、モード設定通信部３３を介して要求を受信すると、携帯端末２０−１の動作モードをモードＡに設定する。これにより、受信通知メールの送信時のみマナーモードにし、受信通知メールの送信終了後には元の動作モードに戻すことができる。携帯端末２０−１の動作モードがモードＡに設定されたら、処理が終了される。

ステップＳ１５で判断されたスケジュールが受信通知メールの受信を希望しないスケジュールでない場合（ステップＳ２５でＮＯ）には、マナーモードへの設定変更が行われていないため、そのまま処理が終了される。

これにより、受信通知メールの送受信時のみモードを切り替えることため、ユーザ自身が携帯端末に設定した動作モードを最大限有効にすることができる。したがって、突然の予定変更でモードＡでの着信が可になった場合などに不必要に長時間マナーモードに切り替えられてしまうことが無いため、使いやすいメール受信通知送信システムを提供することができる。

なお、本実施の形態、変形例１及び変形例２は、第１の実施の形態、第１の実施の形態の変形例１〜３、第２の実施の形態、及び第２の実施の形態の変形例の少なくとも１つと組み合わせて適用することができる。

本発明は、ウェブメールシステムサーバ、携帯端末を備えたメール受信通知送信システムに限らず、ウェブメールシステムサーバ単体として提供しても良いし、ウェブメールシステムサーバ、メール受信通知送信システムに適用するプログラムとして提供することもできる。また、携帯端末としては、携帯電話に限らず、ＰＤＡ等の各種の携帯端末を用いることができる。

１、２、３：メール受信通知送信システム、１０、１０−１、１０−２：管理装置、２０、２０−１：携帯端末

Claims (13)

1. スケジュールが記憶されたスケジュール記憶手段と、
   メールを受信するメール受信手段と、
   前記メール受信手段によりメールが受信されたことを示す受信通知メールであって、前記メール受信手段により受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成する受信通知メール生成手段と、
   前記メール受信手段によりメールが受信されると、前記スケジュール記憶手段に記憶されたスケジュールに基づいて受信通知メールの送信が可能か否かを判断する送信可否判断手段と、
   前記送信可否判断手段により受信通知メールの送信が可能と判断された場合には、前記受信通知メール生成手段により生成された受信通知メールを携帯端末へ送信する送信手段と、
   を備えたことを特徴とするメール受信通知送信装置。
2. 前記スケジュール記憶手段は、開始日時と終了日時とが各スケジュール毎に記憶されたスケジュールデータを記録し、
   前記送信可否判断手段は、
   現在日時を取得する現在日時取得手段と、
   前記現在日時取得手段により取得された現在日時が前記スケジュール記憶手段に記憶された所定のスケジュールの開始日時と終了日時との間にあるか否かを判断する第１判断手段と、
   前記第１判断手段により現在時刻が前記所定のスケジュールの開始日時と終了日時との間にあると判断された場合には、当該所定のスケジュールが所定の条件を満たすか否かを判断する第２判断手段と、
   前記第２判断手段により前記所定のスケジュールが前記所定の条件を満たすと判断された場合には、受信通知メールの送信が不可能であると判断する第３判断手段と、を有することを特徴とする請求項１に記載のメール受信通知送信装置。
3. 前記スケジュール記憶手段は、前記スケジュールデータとして開始日時と終了日時と受信通知メールの送信を断るか否かを示す情報と関連付けて記憶し、
   前記第２判断手段は、前記所定のスケジュールの開始日時と終了日時とに受信通知メールの送信を断ることを示す情報が関連付けられている場合には前記所定の条件を満たすと判断することを特徴とする請求項２に記載のメール受信通知送信装置。
4. 前記スケジュール記憶手段は、前記スケジュールデータとして開始日時と終了日時とスケジュールの内容を簡潔に示す情報であるスケジュールタイプと関連付けて記憶し、
   前記第２判断手段は、前記所定のスケジュールの開始日時と終了日時とに関連付けられたスケジュールタイプに基づいて前記所定の条件を満たすか否かを判断することを特徴とする請求項２に記載のメール受信通知送信装置。
5. 前記第２判断手段は、前記所定のスケジュールのスケジュールデータに所定の文字が含まれるか否かを解析し、前記所定のスケジュールのスケジュールデータに所定の文字が含まれる場合には前記所定の条件を満たすと判断することを特徴とする請求項２に記載のメール受信通知送信装置。
6. 前記送信手段は、前記第２判断手段により前記所定のスケジュールが前記所定の条件を満たすと判断された場合に前記所定のスケジュールの終了日時を過ぎたか否かを判断し、前記所定のスケジュールの終了日時を過ぎた場合には、前記受信通知メール生成手段により生成された受信通知メールを携帯端末へ送信することを特徴とする請求項２から５のいずれかに記載のメール受信通知送信装置。
7. 前記メール受信手段により受信されたメールの重要度を判断する重要度判断手段を備え、
   前記送信可否判断手段は、前記重要度判断手段により重要度が高いと判断された場合には、受信通知メールの送信が可能であると判断することを特徴とする請求項１から５のいずれかに記載のメール受信通知送信装置。
8. 前記メール受信手段は、重要度を示す情報が関連付けられたメールを受信し、
   前記重要度判断手段は、前記重要度を示す情報に基づいてメールの重要度を判断することを特徴とする請求項７に記載のメール受信通知送信装置。
9. 前記メール受信手段により受信されたメールを解析するメール解析手段を備え、
   前記重要度判断手段は、前記メール解析手段によりメールに重要であることを示す文字が含まれていることが解析された場合には重要度が高いと判断することを特徴とする請求項７に記載のメール受信通知送信装置。
10. 請求項１から９に記載のメール受信通知送信装置と、前記携帯端末としての携帯端末とを備えたメール受信通知送信システムであって、
    前記携帯端末は、
    動作モードを設定する設定手段と、
    前記設定手段により設定された動作モードを示す情報を前記メール受信通知送信装置に送信する第１通信手段と、を備え、
    前記メール受信通知送信装置は、
    前記第１送信手段から送信された動作モードを示す情報を受信する第２通信手段と、
    前記送信可否判断手段により受信通知メールの送信が不可能と判断された場合には、前記第１受信手段により受信された動作モードを示す情報を参照し、前記動作モードがマナーモードであるか否かを判断する動作モード判断手段と、を備え、
    前記第２通信手段は、前記動作モード判断手段により動作モードがマナーモードでないと判断された場合には、マナーモードへの設定指示を前記携帯端末に送信し、
    前記第１通信手段は、前記第２通信手段から送信された前記マナーモードへの設定指示を受信し、
    前記設定手段は、前記第１通信手段により前記マナーモードへの設定指示が受信されると、前記動作モードをマナーモードに設定することを特徴とするメール受信通知送信システム。
11. 前記第２通信手段は、前記メール受信手段によりメールが受信されると前記第１送信手段へ動作モードを示す情報を送信するように指示を送信し、
    前記第１通信手段は、前記第２通信手段から送信された指示を受信すると前記動作モードを示す情報を送信することを特徴とする請求項１０に記載のメール受信通知送信システム。
12. メールを受信するステップと、
    前記メール受信手段によりメールが受信されたことを示す受信通知メールであって、前記メール受信手段により受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成する受信通知メール生成手段と、
    前記メールが受信されると、スケジュール記憶手段に記憶されたスケジュールに基づいて受信通知メールの送信が可能か否かを判断するステップと、
    前記受信通知メールの送信が可能と判断された場合には、メールが受信されたことを示す受信通知メールであって、前記受信されたメールのヘッダ情報に含まれる情報のみからなる受信通知メールを生成するステップと、
    前記生成された受信通知メールを携帯端末へ送信するステップと、
    を実行することを特徴とするメール受信通知送信方法。
13. 請求項１２に記載のメール受信通知送信方法をメール受信通知送信装置に実行させることを特徴とするプログラム。

Images