(57)【要約】      （修正有）【課題】容量超過によりメールサーバ内のメールボックスにメールを格納できなかった場合に、メールの宛先にメールの詳細な内容について通知できるようにする。【解決手段】メール受信サーバで、メールの受信処理を行うメール受信手段と、受信メールをメールアドレス毎に格納する第１のメールボックスと、メールを受信した時、メールの宛先アドレスに対応する第１のメールボックスに格納可能な空き容量があるかをアドレス毎に判定する判定手段と、格納可能な空き容量がないと判定された時、メールを受信エラーメールとして格納する一時格納領域と、格納されたエラーメールからヘッダー情報と本文情報とを抽出する抽出手段と、エラーメールに関する情報を宛先メールアドレスに通知する情報通知メールを、抽出されたヘッダー情報及び本文情報を用いて生成する情報通知メール管理手段と、情報通知メールをアドレス毎に格納する第２のメールボックスと、を備える。【選択図】図１
2010213193.tif 000002
【特許請求の範囲】
【請求項１】
メールの受信処理を行うメール受信手段と、
受信したメールを格納する第１のメールボックスと、
前記メール受信手段でメールを受信したときに、前記受信したメールを格納可能な空き容量が前記受信したメールの宛先に記載されたメールアドレスに対応した前記第１のメールボックスにあるか否かを判定する判定手段と、
前記判定手段で格納可能な空き容量がないと判定されたときに前記メールが受信エラーメールとして格納される格納領域と、
前記格納領域に格納された前記受信エラーメールからヘッダー情報と本文情報とを抽出する抽出手段と、
前記受信エラーメールに関する情報を前記受信エラーメールの宛先に記載されたメールアドレスに通知するための情報通知メールを、前記抽出手段で抽出された前記ヘッダー情報および前記本文情報を用いて生成する情報通知メール管理手段と、
前記情報通知メール管理手段で生成された前記情報通知メールを格納する第２のメールボックスと、
を備えることを特徴とするメール受信サーバ。
【請求項２】
前記情報通知メールは、前記ヘッダー情報に基づいて生成される第１の情報通知メールおよび、前記ヘッダー情報と前記本文情報とに基づいて生成される第２の情報通知メールからなることを特徴とする請求項１に記載のメール受信サーバ。
【請求項３】
前記情報通知メール管理手段は、すべての前記受信エラーメールの総データサイズを前記抽出手段で抽出した前記ヘッダー情報および前記本文情報から算出し、前記算出したすべての受信エラーメールの総データサイズと前記判定手段で格納可能な空き容量がないと判定された前記第１のメールボックスの現時点での残容量との差分を計算し、前記すべての受信エラーメールを受信するのに必要となる前記第１のメールボックスの容量値を算出することを特徴とする請求項１に記載のメール受信サーバ。
【請求項４】
受信側クライアント装置からのＰＯＰ受信処理リクエストを受けて前記第１のメールボックスおよび／または前記第２のメールボックスに格納されたメールを転送するＰＯＰ処理手段をさらに備え、
前記情報通知メール管理手段は、前記ＰＯＰ処理手段によって前記情報通知メールが転送された時点で、当該転送された情報通知メールを削除することを特徴とする請求項１に記載のメール受信サーバ。
【請求項５】
前記抽出手段は、前記格納領域に格納された前記受信エラーメールから添付ファイル情報をさらに抽出し、
前記情報通知メール管理手段は、前記抽出された添付ファイル情報に基づいて、添付ファイルの有無、添付ファイルの名称、添付ファイルのサイズのいずれかの情報を少なくとも含むように前記第２の情報通知メールを生成することを特徴とする請求項１に記載のメール受信サーバ。
【請求項６】
前記情報通知メール管理手段は、前記抽出手段で抽出した前記ヘッダー情報に重要なメールであることを示すフラグが含まれているかどうかを判定し、重要なメールであることを示すフラグが含まれていない場合には所定時間の経過を待って前記情報通知メールを生成し、重要なメールであることを示すフラグが含まれている場合には前記所定時間の経過を待たずに前記情報通知メールを生成することを特徴とする請求項１に記載のメール受信サーバ。
【請求項７】
前記情報通知メール管理手段は、前記受信エラーメールの宛先に記載されたメールアドレスのうち、前記判定手段で格納可能な空き容量があると判定された第１のメールボックスに対応するメールアドレスについては、前記情報通知メールを生成しないことを特徴とする請求項１に記載のメール受信サーバ。
【請求項８】
メールを送信する送信側クライアント装置、ブラウザを搭載した前記メールを受信する受信側クライアント装置、メール受信サーバおよびＷＷＷサーバがインターネットを介して接続された電子メールシステムであって、
前記メール受信サーバは、
メールの受信処理を行うメール受信手段と、
受信した前記メールを格納する第１のメールボックスと、
前記メール受信手段でメールを受信したときに、前記受信したメールを格納可能な空き容量が前記メールの宛先に記載されたメールアドレスに対応する前記第１のメールボックスにあるか否かをメールアドレス毎に判定する判定手段と、
前記判定手段で格納可能な空き容量がないと判定されたときに前記メールが受信エラーメールとして格納される格納領域と、
前記格納領域に格納された前記受信エラーメールからヘッダー情報と本文情報とを抽出する抽出手段とを備え、
前記ＷＷＷサーバは、前記受信側クライアント装置の前記ブラウザからのアクセスを受けて、前記受信エラーメールに関する情報を表す情報通知Ｗｅｂ画面としてのＨＴＭＬデータを前記ヘッダー情報および前記本文情報を基に生成し、生成された前記ＨＴＭＬデータを前記受信側クライアント装置に転送する手段を備え、
前記受信側クライアント装置は、前記転送されたＨＴＭＬデータで表された情報通知Ｗｅｂ画面を前記ブラウザによって表示する、
ことを特徴とする電子メールシステム。
【請求項９】
メールの受信処理を行うメール受信手段と、各メールアドレスに対応し、メールを格納する第１および第２のメールボックスと、前記第１のメールボックスに格納できなかったメールを格納する格納領域とを備えたメール受信サーバにおけるメールの管理方法であって、
前記メール受信手段で前記メールを受信したときに、前記受信したメールを格納可能な空き容量が前記受信したメールの宛先に記載されたメールアドレスに対応した前記第１のメールボックスにあるか否かを判定するステップと、
前記判定するステップで格納可能な空き容量がないと判定されたときに前記メールを受信エラーメールとして前記格納領域に格納するステップと、
前記格納するステップで前記格納領域に格納された前記受信エラーメールからヘッダー情報と本文情報とを抽出するステップと、
前記受信エラーメールに関する情報を前記受信エラーメールの宛先に記載されたメールアドレスに通知するための情報通知メールを、前記抽出するステップで抽出された前記ヘッダー情報および前記本文情報を用いて生成する情報通知メール管理ステップと、
前記情報通知メール管理ステップで生成された前記情報通知メールを前記第２のメールボックスに格納するステップと、
を含むことを特徴とする方法。
【請求項１０】
前記情報通知メールは、前記ヘッダー情報に基づいて生成される第１の情報通知メールおよび、前記ヘッダー情報と前記本文情報とに基づいて生成される第２の情報通知メールからなることを特徴とする請求項９に記載の方法。
【請求項１１】
前記情報通知メール管理ステップは、すべての前記受信エラーメールの総データサイズを前記抽出するステップで抽出した前記ヘッダー情報および前記本文情報から算出し、前記算出したすべての受信エラーメールの総データサイズと前記判定するステップで格納可能な空き容量がないと判定された前記第１のメールボックスの現時点での残容量との差分を計算し、前記すべての受信エラーメールを受信するのに必要となる前記第１のメールボックスの容量値を算出することを特徴とする請求項９に記載の方法。
【請求項１２】
受信側クライアント装置からのＰＯＰ受信処理リクエストを受けて前記第１のメールボックスおよび／または前記第２のメールボックスに格納されたメールを転送するＰＯＰ処理ステップと、
前記ＰＯＰ処理ステップによって前記情報通知メールが転送された時点で、当該転送された情報通知メールを削除するステップと、
をさらに含むことを特徴とする請求項９に記載の方法。
【請求項１３】
前記抽出するステップは、前記格納領域に格納された前記受信エラーメールから添付ファイル情報をさらに抽出し、
前記情報通知メール管理ステップは、前記抽出された添付ファイル情報に基づいて、添付ファイルの有無、前記添付ファイルの名称、前記添付ファイルのサイズのいずれかの情報を少なくとも含むように前記第２の情報通知メールを生成する、
ことを特徴とする請求項９に記載の方法。
【請求項１４】
前記情報通知メール管理ステップは、前記抽出するステップで抽出した前記ヘッダー情報に重要なメールであることを示すフラグが含まれているかどうかを判定するステップを含み、前記判定するステップで重要なメールであることを示すフラグが含まれていないと判定された場合には所定時間の経過を待って前記情報通知メールを生成し、重要なメールであることを示すフラグが含まれていると判定された場合には前記所定時間の経過を待たずに前記情報通知メールを生成するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１５】
前記情報通知メール管理ステップは、前記受信エラーメールの宛先に記載されたメールアドレスのうち、前記判定するステップで格納可能な空き容量があると判定された第１のメールボックスに対応するメールアドレスについては、前記情報通知メールを生成しないことを特徴とする請求項９に記載の方法。
【請求項１６】
メールを送信する送信側クライアント装置、ブラウザを搭載した前記メールを受信する受信側クライアント装置、メール受信サーバおよびＷＷＷサーバがインターネットを介して接続された電子メールシステムにおけるメールの管理方法であって、
メールの受信処理を行うメール受信手段と、前記メールを格納する第１および第２のメールボックスと、前記第１のメールボックスに格納できなかったメールを格納する格納領域とを備えた前記メール受信サーバにおいて、
前記メール受信手段でメールを受信したときに、前記受信したメールを格納可能な空き容量が前記受信したメールの宛先に記載されたメールアドレスに対応した前記第１のメールボックスにあるか否かを判定するステップと、
前記判定するステップで格納可能な空き容量がないと判定されたときに前記メールを受信エラーメールとして前記格納領域に格納するステップと、
前記格納するステップで前記格納領域に格納された前記受信エラーメールからヘッダー情報と本文情報とを抽出するステップと、
前記ＷＷＷサーバにおいて、前記受信側クライアント装置の前記ブラウザからのアクセスを受けて前記受信エラーメールに関する情報を表す情報通知Ｗｅｂ画面としてのＨＴＭＬデータを前記ヘッダー情報および前記本文情報を基に生成し、生成された前記ＨＴＭＬデータを前記受信側クライアント装置に転送するステップと、
前記受信側クライアント装置において、前記転送されたＨＴＭＬデータで表された情報通知Ｗｅｂ画面を前記ブラウザによって表示するステップと、
を含むことを特徴とする方法。
【請求項１７】
コンピュータに請求項９乃至１６のいずれか１項に記載の方法を実行させるためのコンピュータプログラム。
【請求項１８】
コンピュータにより読み出し可能なプログラムを格納した記憶媒体であって、請求項１７記載のコンピュータプログラムを格納したことを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メール受信時における容量制限によるメールの受信エラーを当該メールの名宛人に通知するための情報の抽出と通知に関する。
【背景技術】
【０００２】
本発明の先行技術について、文献を挙げて説明する。
【０００３】
企業におけるメールの重要性が高まる中、特に即時性を要求されるような職務遂行において、メールを即時に受信するニーズが高まっている。しかし、メールサービスを提供するＩＳＰ(Internet Service Provider)では、サーバの保護や契約(容量)の関係でメールボックスの容量に制限が設定されていることが一般的である。そのため、メールボックスの容量が制限値を超えていることでメールを受信できないなど、即時受信のニーズに対応できない場合があった。
【０００４】
このような状況への対応技術としては、メールの受信自体を妨げないように別の受信先(メールボックス)を提供する方法や受信メールを加工してメール自体の容量（データ量）を削減して受信を継続する方法などがある（例えば、特許文献１参照）。また、ＰＯＰ受信時にメール一通あたりの容量が超過しているかどうかを判定し、超過の場合はヘッダーだけを受信してその旨をメールの名宛人に通知し、受信失敗を回避する方法も存在する（例えば、特許文献２参照）。この方法では、その後ヘッダー以外の残メールデータが容量許容範囲内となった段階で追加受信し、既に受信したヘッダー部と結合するなどにより、完全なメールが受信可能となる。
【０００５】
さらに、メールサービスにおいて容量超過が発生すると、サーバエラーログ（図１３参照）から、送信元情報、メッセージＩＤ、メール容量、送信日時を抽出し、その都度、宛先メールアドレスに対してエラー通知メール（警告のメール）を通知する方法もある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平０２−２１３２５２号公報
【特許文献２】特開２００１−１５４９４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、これらの方法には次のような課題がある。
まず、特許文献１に開示された方法では、単純に契約外の容量を用いて顧客のメールをそのままの状態で受け取っており、サーバリソースの無駄な消費が生じるという問題がある。さらに、この方法では、顧客データの保全性を２倍（すなわち、契約容量と契約外容量の２つの領域について）考慮する必要があるという問題もある。
【０００８】
また、特許文献２に開示の方法は、メーラーソフトによるＰＯＰ受信時における受信側クライアントの容量不足に対する解決方法である。このためメールサーバ間の受信処理において発生する、メールサーバ内にある受信用メールボックスの容量不足時の名宛人への情報通知と、ＩＳＰとしての容量維持の課題を解決するには至っていない。
【０００９】
さらに、サーバログから抽出した情報をエラー通知メールとして宛先メールアドレスに通知する先行技術については、メールサーバの処理したログからの抽出であるため、得られる情報がメールのヘッダー情報に限られていた。したがって、受信エラーとなったメールの題名や送信者のアドレスなどの情報を知ることはできるが、受信エラーとなったメールの本文内容を知ることは全く出来なかった。また、受信エラーとなったメールの中に添付ファイルがあったのか、どのような添付ファイルなのかといったことも知ることが出来なかった。また、受信者のメールボックスの容量に空きがない状態においては、新たなメールが送信されてくる度に毎回エラー通知メールを送信することになるため、受信者側にとって非常に不便であった。
【課題を解決するための手段】
【００１０】
本発明のメール受信サーバは、メールの受信処理を行うメール受信手段と、受信したメールを格納する第１のメールボックスと、前記メール受信手段でメールを受信したときに、前記受信したメールを格納可能な空き容量が前記受信したメールの宛先に記載されたメールアドレスに対応した前記第１のメールボックスにあるか否かを判定する判定手段と、
前記判定手段で格納可能な空き容量がないと判定されたときに前記メールが受信エラーメールとして格納される格納領域と、前記格納領域に格納された前記受信エラーメールからヘッダー情報と本文情報とを抽出する抽出手段と、前記受信エラーメールに関する情報を前記受信エラーメールの宛先に記載されたメールアドレスに通知するための情報通知メールを、前記抽出手段で抽出された前記ヘッダー情報および前記本文情報を用いて生成する情報通知メール管理手段と、前記情報通知メール管理手段で生成された前記情報通知メールを格納する第２のメールボックスと、を備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、メールサーバにおける規定の容量超過時にメールサーバの受信拒否機能を生かして容量を越えた分のメール受信を制限しつつ、制限による受信エラーメールの存在とその詳細情報を速やかに宛先メールアドレス（名宛人）に通知することができる。
【００１２】
特に、本発明では、容量超過で格納できなかったメールを一時格納領域に格納することにより、当該メールの本文や添付ファイルなどに関する情報を抽出し、詳細情報として通知できるようにしている。また、本発明では、上記の通知に関し、メールサーバの処理として、顧客との契約により容量が定まる（受信拒否の対象となる）メールボックスとは別に受信エラー通知用メールボックスを設け、両者を使い分ける技術を用いている。このように別個のメールボックスを用い、そこに受信エラー通知用のメールを配置することで、標準的なメール受取手法である所謂ＰＯＰ受信により速やかに名宛人に対して通知を行うことができる。
【００１３】
さらに、メールボックス内の情報通知メールを速やかに削除することで、サーバ上のリソースの無駄を排除することを可能とする。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態を示す電子メールシステムの構成図である。
【図２】第１の実施形態に係る本発明の処理の概要を示すフローチャートである。
【図３】第２の実施形態に係る本発明の処理の概要を示すフローチャートである。
【図４】情報抽出処理の詳細を示すフローチャートである。
【図５】情報通知メールの生成処理の詳細を示すフローチャートである。
【図６】第１の実施形態における各処理がどのように行われるかを視覚的に示す概要図である。
【図７】第２の実施形態における各処理がどのように行われるかを視覚的に示す概要図である。
【図８】情報通知メール（一覧）の一例を示したものである。
【図９】情報通知メール（個別）の一例を示したものである。
【図１０】一般的なメールヘッダーの一例を示したものである。
【図１１】情報通知Ｗｅｂ画面（一覧）の一例を示したものである。
【図１２】情報通知Ｗｅｂ画面（個別）の一例を示したものである。
【図１３】従来技術におけるメール受信サーバのエラーログの一例を示したものである。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１６】
図１は本発明の実施形態を示す電子メールシステムの構成図である。
同図において、１０１は送信側クライアント装置で、インターネット１０３で接続されたコンピュータである。送信側クライアント装置１０１には、メールを受信者に対して送信するためのメールソフトを備えている。
【００１７】
１０２は受信側クライアント装置で、インターネット１０３で接続されたコンピュータである。受信側クライアント装置１０２には、メール受信時にメールサーバ装置に対してメール受取の処理（代表的な例としてＰＯＰ（Post Office Protocol）受信）を行うためのメールソフトを備えている。  
１１０も受信側クライアント装置の一例であり、iモード（登録商標）など携帯機器用Ｗｅｂブラウザを備えている携帯電話などの機器である。
【００１８】
１０３はクライアントＰＣやサーバなどを相互に繋ぐネットワークとしてのインターネットである。
【００１９】
１０４は外部ＩＳＰで、送信側クライアント装置からのメールを外部へ送信する外部メールサーバ１０５を備える。
【００２０】
外部メールサーバ１０５は、送信者がメールの名宛人に対してメールを送信するにあたり、受信者側ＩＳＰ１０６のメール受信サーバ１０７と通信しメール送信処理を行うサーバである。外部メールサーバ１０５は、メールの送受信を行うＭＴＡ(Mail Transfer Agent)処理手段１０５ａを備えている。ここで、「名宛人」とは、メールの“TO”、“CC”、“BCC”の欄に記載されたメールの受取人となるべき自然人や法人などを指す。なお、“TO”、“CC”、“BCC”の欄に自然人等の名称ではなくメールアドレス自体が直接記載されている場合には、当該メールアドレスを保有（使用）する潜在的な自然人等を指すものとする。
【００２１】
１０６は受信者側ＩＳＰであり、受信側クライアント装置１０２／１１０に届くメールを受信しこれを管理するメール受信サーバ１０７のほか、ＤＢサーバ１０８およびＷＷＷサーバ１０９を備えている。
【００２２】
メール受信サーバ１０７は、外部メールサーバ１０５からのメールを受ける不図示のＭＸ（Mail eXchange）サーバからメールを受け取り、宛先メールボックスに格納する処理を行う。メール受信サーバ１０７は、ＭＸサーバからのメールを受信するＭＴＡ処理手段１０７ａを備える。また、メール受信サーバ１０７には、受信メールの格納先ディレクトリである各宛先メールアドレスに対応した受信用メールボックス１０７ｅ（第１のメールボックス）および情報通知メール用メールボックス１０７ｆ（第２のメールボックス）を備える。ここで、「情報通知メール」とは、受信用メールボックス１０７ｅに格納できなかったメール（本明細書において「受信エラーメール」と呼ぶ）に関する情報を、当該メールの宛先に記載されたメールアドレス（名宛人）に通知するためのメールを指す。さらに、メール受信サーバ１０７は、受信エラーメール処理手段１０７ｂ、情報抽出管理手段１０７ｃ、ＰＯＰ処理手段１０７ｄ、受信エラーメール一時格納領域１０７ｇを備える。
【００２３】
ＭＴＡ処理手段１０７ａは、ＭＸサーバからのメールを受信し、容量チェックを実施のうえ受信用メールボックス１０７ｅに格納する処理を行う。また、容量超過によって受信用メールボックス１０７ｅにメールを格納できなかった時は、当該メールを受信エラーメール一時格納領域１０７ｇに格納する処理を行う。
【００２４】
受信エラーメール処理手段１０７ｂは、メールボックス１０７ｅの容量超過によるメールの受信エラーが発生した場合に、そのメールからの情報抽出やメール名宛人への通知といった受信エラーメール処理のすべてを管理する。すなわち、情報抽出管理手段１０７ｃを呼出し、一時格納領域に格納された受信エラーメールから情報の抽出を行い、抽出された情報に基づき情報通知メールの生成および情報通知メール用メールボックスへの格納処理といった、情報通知メール管理全般を行う。
【００２５】
情報抽出管理手段１０７ｃは、受信エラーメール一時格納領域１０７ｇに保存された受信エラーメールからの情報の抽出、抽出した情報をＤＢ（Database）サーバ１０８に格納およびＤＢサーバ１０８に格納された情報の削除等の各処理を行う。
【００２６】
ＰＯＰ処理手段１０７ｄは、受信側クライアント装置１０２／１１０のメールソフトからのＰＯＰ受信処理リクエストに対して、メールボックス１０７ｅ／１０７ｆからのデータを転送する処理を行う。
【００２７】
受信用メールボックス１０７ｅは、受信したメールを格納する領域であり、容量超過の状態に陥っていない限り、ＭＸサーバを介して受信されたメールはメールアドレス毎にすべてここに格納される。受信用メールボックス１０７ｅは容量の上限値を備えており、ＭＴＡ処理手段１０７ａと連携して上限値を超えたメールの受信処理を制限することができる。この制限を越えると容量超過の状態となる。
【００２８】
情報通知メール用メールボックス１０７ｆは、容量超過によるメールの受信制限によって受信用メールボックス１０７ｅにメールを格納できなかった場合に生成される情報通知メールをメールアドレス毎に格納するディレクトリ領域を備えている。メールソフトからのアクセス時には、受信用メールボックス１０７ｅおよびこの情報通知用メールボックス１０７ｆの両方に格納されたメールデータが受信側クライアント装置１０２／１１０のメールソフトに対して送信される。すなわち、受信側クライアント装置１０２／１１０のメールソフトが一度の受信操作で、当該メールアドレス（ユーザＩＤ）に関するメールデータを、受信用メールボックス１０７ｅと情報通知用メールボックス１０７ｆの両方から取得する。なお、情報通知メール用メールボックス１０７ｆは、ＭＴＡ処理手段１０７ａによる容量チェックと容量チェック結果に基づくメールの受信制限の対象とはならないディレクトリ領域になっている。
【００２９】
受信エラーメール一時格納領域１０７ｇは、容量制限の超過により受信できなかったメール（ヘッダー、本文および添付ファイルのすべて）を、情報抽出のために一時的に保持するディレクトリ領域を備えている。
【００３０】
ＤＢサーバ１０８は、データベースソフトを備えており、メール情報レコードおよび抽出されたメール情報を格納する。また、抽出情報データベース１０８ａを備えている。
【００３１】
抽出情報データベース１０８ａは、情報抽出管理手段１０７ｃが抽出したメール情報を格納する具体的なデータベースである。
【００３２】
ＷＷＷ（World Wide Web）サーバ１０９は、情報をＷｅｂ画面に表示するＷｅｂサーバプログラムを有し、情報表示手段１０９ａおよび認証処理手段１０９ｂを備えている。受信側クライアント装置１０２／１１０からのアクセスにより、ＷＷＷサーバ１０９はリクエストされた情報からＷｅｂ画面を生成し、ＷＷＷブラウザ経由で受信側クライアント装置１０２／１１０が備える表示手段上にＷｅｂ画面を表示する。
【００３３】
情報表示手段１０９ａは、受信側クライアント装置からのリクエストに対して、抽出情報データベース１０８ａから受信エラーメール抽出情報を検索し、受信エラーメール抽出情報が存在した場合は、受信状況を表示する情報通知Ｗｅｂ画面を生成する。ここで、「情報通知Ｗｅｂ画面」とは、受信用メールボックス１０７ｅに格納できなかったメールに関する情報を、当該メールの名宛人ユーザに通知するための画面を指す。
【００３４】
認証処理手段１０９ｂは、ＷＷＷサーバ１０９にアクセスする受信側クライアント装置１０２／１１０の認証処理を行う。受信側クライアント装置１０２／１１０からのアクセスがあると、認証処理手段１０９ｂはＩＤとパスワードの入力画面を転送する。受信側クライアント装置１０２／１１０から入力されたＩＤ、パスワードが正しい場合、ＷＷＷサーバ１０９はアクセスされたＵＲＬのページ情報を表示する。誤っていた場合は認証エラー画面を表示する。
【００３５】
（第１の実施形態）
以下、本発明の第１の実施形態について詳細を説明する。
【００３６】
図２は第１の実施形態に係る本発明の処理の概要を示すフローチャートである。なお、Ｓ２０１〜Ｓ２０７は各ステップを示す。
【００３７】
まず、Ｓ２０１において、送信側クライアント装置１０１から送信されたメールを、外部ＩＳＰ１０４等の外部メールサーバ１０５からインターネット１０３を介して、メール受信サーバ１０７のＭＴＡ処理手段１０７ａが受信する。
【００３８】
次に、Ｓ２０２においてＭＴＡ処理手段１０７ａは、受信したメールの名宛人を確認し、当該名宛人ユーザの受信用メールボックス１０７ｅの契約容量と、現時点での当該名宛人ユーザの受信用メールボックス１０７ｅの格納済データ容量との比較チェックを行う。なお、メールの名宛人が複数の場合には、それぞれの名宛人について上記比較チェックを行い以下の処理もメールアドレス単位で実行する。この比較チェックにより当該名宛人ユーザの受信用メールボックス１０７ｅの空容量を算出し、算出された空き容量と受信したメールのデータ容量との比較から、今回受信したメールを格納可能な容量があるかどうか判定する。判定の結果、今回受信したメールを格納可能な容量が存在する場合には、Ｓ２０４の処理を実行する。  
Ｓ２０４では、ＭＴＡ処理手段１０７ａが、受信したメールを名宛人ユーザの受信用メールボックス１０７ｅに格納して処理を終了する。
【００３９】
一方、Ｓ２０２で、受信したメールを格納可能な容量が存在しないと判定された場合には、Ｓ２０３において、ＭＴＡ処理手段１０７ａは今回受信したメールを受信エラーメール一時格納領域１０７ｇに格納する。この格納処理が終了した後、ＭＴＡ処理手段１０７ａは格納処理が終了した旨を受信エラーメール処理手段１０７ｂに通知する。
【００４０】
Ｓ２０５では、受信エラーメール処理手段１０７ｂは、Ｓ２０３で格納処理の終了を通知されたことをきっかけに、受信エラーメール一時格納領域１０７ｇに格納されたメールから当該メールの名宛人に通知する情報通知メール用の情報を抽出する。
【００４１】
ここで、情報抽出処理に関する詳細を、図４を用いて説明する。
【００４２】
（情報抽出処理）
図４は、情報抽出処理の詳細を示すフローチャートであり、Ｓ４０１〜Ｓ４０８は各ステップを示す。
【００４３】
まず、Ｓ４０１において、受信エラーメール処理手段１０７ｂは、情報抽出管理手段１０７ｃを呼び出し、起動させる。
【００４４】
そして、Ｓ４０２において、情報抽出管理手段１０７ｃは、受信エラーメール一時格納領域１０７ｇに格納されたメールのデータサイズを取得し、取得したデータサイズの値をＤＢサーバ１０８に格納する。格納後は、Ｓ４０３へと進み、当該メールのヘッダー情報を取得する処理を行う。
【００４５】
Ｓ４０３において、情報抽出管理手段１０７ｃは最初に、当該メールがＭＩＭＥ（Multipurpose Internet Mail Extension）エンコード処理されているかどうかを、ヘッダーのエンコード情報から判定する。ＭＩＭＥエンコード処理がされていないと判定された場合には、そのままＳ４０４の処理を実行する。ＭＩＭＥエンコードがされていると判定された場合にはＭＩＭＥエンコードの内容を取得し、Ｓ４０８の処理を実行する。
【００４６】
Ｓ４０８では、情報抽出管理手段１０７ｃは、Ｓ４０３で取得したＭＩＭＥエンコードの内容からデコード仕様を把握し、把握したデコード仕様に基づきＭＩＭＥデコード処理を実施して、デコードにより得られた情報をメモリ上に保持する。この情報の保持が終わると、次のＳ４０４の処理に進む。
【００４７】
Ｓ４０４において、情報抽出管理手段１０７ｃは、当該メールのヘッダーに含まれるすべての情報を対象に情報抽出処理を実行する。図１０は、一般的なメールヘッダーの一例を示したものである。１００１はリターンパス（Return-Path）であり、正常にメール受信が行えなかった場合などの返送先を示すものである。１００２は当該メールの送信年月日および時刻を示す。１００３は当該メールの送信者のメールアドレスを示している。１００４は当該メールの宛先(TO)に記載された名宛人のメールアドレスを示している。１００５は当該メールの件名を示している。１００６は当該メールの転送処理を行うにあたり、メールソフトが割り当てた一意の識別番号を示している。１００７は当該メールのＭＩＭＥエンコード状態を表すエンコード情報を示している。
【００４８】
この段階で抽出対象となる情報には、メッセージＩＤ、送信者のメールアドレス、名宛人の名称あるいは宛先メールアドレス（TO、CC、BCC）、送信日時、受信日時、件名、メールの重要度を示すフラグ等が含まれる。ヘッダーの項目名は規約に基づいて共通の名称を用いているが、各項目の表示順は送信される経路上のメールサーバによって異なるため、抽出は以下の手順により行う。
【００４９】
まず、ヘッダーに含まれるすべての文字列についてパーシングを行い、パーシングされたテキストデータをメモリ上に保持する。そして、パーシングされたテキストデータを対象に、抽出対象の項目名をキーに検索処理を実行する。ヘッダーの各項目と内容データは、項目名と“：”(コロン)とでつながって記述されているため、検索処理でヒットした項目名と“：”でつながっている文字列を各項目のヘッダー内容として各々のヘッダー情報として取得する。取得されたヘッダー情報は、処理する都度、ＤＢサーバ１０８上にある該当項目名領域（不図示）に格納し、すべての対象項目の検索が完了するまで実行する。ただし、送信元のメールサーバによっては記述されないヘッダー項目も存在するため、検索に該当しなかった項目については、空白値をＤＢサーバ１０８上にある該当項目名領域に格納する。
【００５０】
すべてのヘッダー情報の抽出処理が終了すると、メール本文ならびに添付ファイルについてデータを抽出する処理を行うＳ４０５へと移行する。
【００５１】
Ｓ４０５において、情報抽出管理手段１０７ｃはメール本文の内容、メールの添付ファイルの有無、添付ファイルのデータサイズ、添付ファイル名を抽出する。抽出されたデータはＤＢサーバ１０８上の各々の項目領域に格納される。メール本文の内容については、予め規定された任意のサイズ（文字数)のみを文頭から抽出し、規定されたサイズを越えた以降のデータは抽出しないようにしている。また、それ以外の項目についてもそれぞれ抽出サイズ制限を設け、それ以上のデータについては抽出しないようにしてもよい。これによりリソースの消費を抑えることができる。情報抽出管理手段１０７ｃは、抽出したデータを都度ＤＢサーバ１０８上にある該当項目名領域に格納する。ＤＢサーバ１０８は、取得した情報のうちメッセージＩＤをキーとして用い、これらの情報を管理する。
【００５２】
Ｓ４０６において、情報抽出管理手段１０７ｃは、情報抽出のために一時的に格納した受信エラーメールを、受信エラーメール一時格納領域１０７ｇから削除する。
【００５３】
Ｓ４０７において、情報抽出管理手段１０７ｃは、すべての情報抽出処理が完了した旨を受信エラーメール処理手段１０７ｂに通知して、情報抽出処理を終了する。
【００５４】
以上が、図２のＳ２０５における情報抽出処理である。続いて、情報通知メールを生成するＳ２０６の処理について説明する。
【００５５】
Ｓ２０６では、受信エラーメール処理手段１０７ｂが、Ｓ２０５でＤＢサーバ１０８に格納された受信エラーメール抽出情報を基に、情報通知メールを生成する。この情報通知メールの生成に関する処理の詳細を図５を用いて説明する。
【００５６】
(情報通知メール生成処理)
図５は、情報通知メールの生成処理の詳細を示すフローチャートである。なお、Ｓ５０１〜Ｓ５１０は各ステップを示す。
【００５７】
まず、Ｓ５０１において、受信エラーメール処理手段１０７ｂは、情報抽出管理手段１０７ｃから情報抽出完了の通知を受信する。
【００５８】
そして、Ｓ５０２において、受信エラーメール処理手段１０７ｂは、情報通知メールの配信可能化が未だ済んでいない受信エラーメール抽出情報の有無をチェックする。具体的には、まず、ＤＢサーバ１０８に格納されているメール情報レコード内の情報通知メール配信可能化ステータスフィールドを確認する。そして、情報通知メールが宛先メールアドレスに配信可能な状態になっていることを示す配信可能化フラグがセットされているかどうかを調べる。配信可能化フラグがセットされていない場合、情報通知メールが未だ生成されていない受信エラーメール抽出情報が存在することを意味する。この場合には情報通知メールの生成のためＳ５０３の処理に進む。一方、配信可能化フラグがセットされている場合には、情報通知メール生成処理を終了する。なお、配信可能化フラグをセットする処理については後述する。
【００５９】
Ｓ５０３において、受信エラーメール処理手段１０７ｂは、情報通知メールの配信可能化が未だ済んでいない受信エラーメールについて、その抽出情報のすべて（ヘッダー内の基本情報およびメール本文などの詳細情報）をＤＢサーバ１０８から読み出す。読み出した抽出情報は、後の処理のため不図示のメモリに保持する。なお、情報通知メールをまだ生成していない受信エラーメールが複数あった場合には、その全部について上記抽出情報の読み出しを行う。
【００６０】
次に、Ｓ５０４において、受信エラーメール処理手段１０７ｂは、対象とされた受信エラーメールのヘッダー中に重要なメールであることを示すフラグがあるか否かを判定する。重要フラグがある場合は、緊急性が高いと考えられることから、直ちに情報通知メールを生成するためＳ５０６に進む。一方、重要フラグがない場合は、緊急性が薄く、受信できていないメールの存在を急いで名宛人に通知する必要性は低いと考えられることからＳ５０５に進み、所定時間の経過を待って情報通知メールの生成処理がなされる。
【００６１】
Ｓ５０５では、受信エラーメール処理手段１０７ｂは、前回の情報通知メールの生成から所定の時間が経過しているかどうかを判定する。ここで、所定の時間はユーザの要望などに応じて任意に設定可能であり、本実施形態においては１０分としている。１０分以上が経過していると判定されると、Ｓ５０６に進む。他方、１０分は経過していないと判定された場合は、再びＳ５０５の処理を実行し、１０分以上の経過が確認されるまでこの判定処理を繰り返す。
【００６２】
Ｓ５０６において、受信エラーメール処理手段１０７ｂは、メモリ上に保持している抽出情報の中から受信エラーメールに関するヘッダー情報を取得する。ここでヘッダー情報には、件名、送信者、受信日時およびメールサイズなどが含まれる。
【００６３】
Ｓ５０７において、まず、受信エラーメール処理手段１０７ｂは、メモリ上に保持している抽出情報（ヘッダー情報、本文情報および添付ファイル情報）からすべての受信エラーメールの総データサイズを算出する。次に、算出した受信エラーメールの総データサイズと上記Ｓ２０２で格納可能な容量がないと判定された受信用メールボックス１０７ｅの現時点での残容量との差分を計算する。そして、計算結果からすべての受信エラーメールを受信するのに必要となる受信用メールボックス１０７ｅの容量値を算出する。
【００６４】
Ｓ５０８において、受信エラーメール処理手段１０７ｂは、Ｓ５０６で取得した各受信エラーメールに関する基本情報およびＳ５０７で算出した総データサイズやメールボックス容量値に基づいて、第１の情報通知メールとしての情報通知メール(一覧)を生成する。情報通知メール(一覧)は、受信することができなかったメールの全件名や全メールの受信に必要なデータ容量など受信エラーメールの存在とその概要を把握するのを可能にする。情報通知メール（一覧）は、例えば“.eml”などメールソフトで閲覧可能なデータ形式であればよく、特に種類は問わない。図８は、情報通知メール（一覧）の一例を示したものである。情報通知メール（一覧）８０１は、宛先８０２、件名８０３のほか、８０４〜８０６からなる本文欄および後述する情報通知メール（個別）のアイコンから構成される。宛先８０２には、受信用メールボックス１０７ｅが容量超過となったメールアドレスまたは当該メールアドレスを保有する名宛人ユーザの名称が記載される。件名８０３には、情報通知メールのタイトルが表示される。本実施形態では、「容量超過による受信エラー通知-＿YYYYMMDD」と表示されている。なお、“YYYYMMDD”部分は年月日である。８０４は情報通知メール（一覧）の本文であり、受信メールボックス１０７ｅの容量制限超過により受信エラーが発生したことを通知する内容の文言が記載される。８０５には現時点での受信用メールボックスの空き容量、受信できていないメールの総容量および受信に必要なメールボックス容量が示される。８０６には受信エラーとなっているメールの概要が一覧として示される。本実施例では、件名、送信者、受信日時、メールサイズが記載されている。なお、ここの「件名」は受信エラーメールの件名であり、かつ、後述する情報通知メール（個別）の件名でもある。８０７は添付メール形式で付与されている情報通知メール（個別）のアイコンであり、本実施形態においては、４つの情報通知メール（個別）が存在するので４つのアイコンが表示されている。
【００６５】
続いて、Ｓ５０９において、Ｓ５０３で読み出したヘッダーや本文などの情報に基づいて第２の情報通知メールとしての情報通知メール（個別）を生成する。この段階で生成される情報通知メール（個別）は、受信することができなかったメール一件毎の詳細を把握するのを可能にする。情報通知メール（一覧）と同様、例えば“.eml”などメールソフトで閲覧可能なデータ形式であれば特にその種類は問わない。このように受信エラーメールの本文欄の情報は、メール１件につき１ファイルが生成される。情報通知メール（個別）の宛先や件名などの情報は、本実施形態のように基となる受信エラーメールに対応付けて生成されるのが望ましい。すなわち、情報通知メール（個別）における送信者、宛先（TO、CC）、送信日時、件名の各欄には、受信エラーメールの送信者のアドレス、送信日時、宛先メールアドレス（TO、CC、BCC）、件名がそれぞれ記載されるのが望ましい。これにより、受信できなかったメールの基本情報を分かりやすくかつ漏れなく名宛人に伝えることができる。
【００６６】
加えて、情報通知メール（個別）の本文の欄には、所定の容量内（文字数）までのメール本文の内容、添付ファイルの有無、添付ファイルの名称、添付ファイルのデータサイズ等が記載される。これにより、受信エラーメールの詳細情報を分かりやすくかつ正確に名宛人に伝えることができる。図９は、情報通知メール（個別）の一例を示したものである。情報通知メール（個別）９０１は、送信者９０２、送信日時９０３、宛先（TO）９０４、CC９０５、件名９０６および本文欄から構成される。送信者９０２には、受信エラーメールを送信した送信者のメールアドレスまたは当該送信者の名称が記載される。本実施例では送信者のメールアドレスが表示されている。送信日時９０３には、受信エラーメールの送信日時が記載される。宛先（TO）９０４には、受信エラーメールの宛先（TO）欄に記載されていた名宛人の名称あるいは当該名宛人のメールアドレスが記載される。CC９０５には、受信エラーメールのCC欄に記載されていた名宛人の名称あるいは当該名宛人のメールアドレスが記載される。なお、本実施例では、宛先（TO）９０４欄およびCC９０５欄に、名宛人の名称に代えて、当該名宛人のメールアドレスがそれぞれ表示されている。件名９０６には、受信エラーメールの件名が記載される。９０７には、受信エラーメールの本文の内容が記載される。ただし、予め定められたデータサイズ（文字数）の範囲内に限られる。９０８には受信エラーメールの添付ファイルに関する情報が記載される。すなわち、添付ファイルの有無、添付ファイルのファイル名およびサイズなどの情報が記載される。なお、添付ファイルそのものは削除されているため、情報通知メール（個別）によっても受信エラーメールに添付されたファイルの内容までは確認することができない。しかしながら、拡張子を含んだファイル名やデータサイズを把握できるので、ある程度その内容も推測することができる。
【００６７】
Ｓ５１０において、受信エラーメール処理手段１０７ｂは、Ｓ５０８およびＳ５０９においてそれぞれ生成された情報通知メール（一覧）と情報通知メール（個別）とを結合する。この結合処理は情報通知メール(一覧)１件に対して同時に生成した１件以上の情報通知メール（個別）を添付ファイルとする処理であり、情報通知メール（個別）を情報通知メール(一覧)に組込む形式で行なわれる。組込みは、たとえば、ＭＩＭＥ形式などの添付メールと同じ方法で構わない。
【００６８】
以上のようにして、図２のＳ２０６における情報通知メールの生成処理が行われる。Ｓ２０６において情報通知メールの生成がなされると、Ｓ２０７に移行する。
【００６９】
Ｓ２０７は、生成された情報通知メールを情報通知メール用メールボックス１０７ｆに格納するステップである。受信エラーメール処理手段１０７ｂは、生成された情報通知メールを名宛人ユーザの情報通知メール用メールボックス１０７ｆに格納する。すなわち、情報通知メールは、名宛人ユーザの受信用メールボックス１０７ｅの使用容量合計値に含まれない領域である情報通知メール専用のディレクトリ配下に格納される。これにより、当該名宛人ユーザの契約容量の使用として加算されることなく、情報通知メールのデータをメールボックスに格納することができる。また、上述のとおり、情報通知メール（個別）の本文に記載される内容については予め定められたデータサイズに制限されるため、リソースを大量に消費することもない。以上の格納処理の終了後、受信エラーメール処理手段１０７ｂは、メール情報レコード内の情報通知メール配信可能化ステータスフィールドに配信可能化フラグをセットし、そのメール情報レコードをＤＢサーバ１０８に格納して処理を終了する。
【００７０】
受信エラーメールの名宛人は、以上のようにして生成された情報通知メールを通常の受信メール閲覧と同じくメールソフトのＰＯＰ受信処理によって取得する。そして、情報通知メール（一覧）を見て、件名などから気になったメールについては、添付された情報通知メール（個別）をさらに閲覧することができる。
【００７１】
受信エラーメール処理手段１０７ｂは、情報通知メールが所定の名宛人に配信された時点で当該情報通知メールを削除する。すなわち、受信側クライアント装置１０２／１１０からのＰＯＰ受信処理リクエストを受け、情報通知メール用メールボックス１０７ｆから当該名宛人向けの情報通知メールが転送された時点で、速やかに当該情報通知メールを削除する。
【００７２】
図６は、第１の実施形態について、これまで説明した各処理がどのように行われるかを視覚的に示した概要図である。
【００７３】
最初に、送信側クライアント装置１０１がインターネット１０３を経由してメール６０１を送信する。すると、当該メールの名宛人となっているユーザのメール受信サーバ１０７のＭＴＡ処理手段１０７ａが、当該名宛人ユーザの受信用メールボックス１０７ｅに対してメールデータの格納を試みる。その際、当該受信用メールボックス１０７ｅが容量制限超過のためにメールデータを格納できなかった場合、当該メール６０１を受信エラーメール一時格納領域１０７ｇに格納する。情報抽出管理手段１０７ｃはこの一時的に格納されたメールデータから必要な情報６０３を抽出し、ＤＢサーバ１０８に格納する。受信エラーメール一時格納領域１０７ｇに格納されたメール６０１は一時的に保持されたに過ぎず、必要な情報の抽出が終了した後は、速やかにメール受信サーバ１０７上から消去される。抽出された情報６０３は、送信日時、送信者、件名、宛先等、メールの名宛人が欲する情報となる。受信エラーメール処理手段１０７ｂはこの抽出された情報６０３を基に名宛人向けの情報通知メール６０４を生成し、容量制限の対象外である情報通知メール用メールボックス１０７ｆに格納する。メールの名宛人ユーザは、受信側クライアント装置１０２内のメーラーソフトを使用して通知情報メール６０４をＰＯＰ受信することによって、送信者からのメールが受信できなかった事実および当該受信エラーメールの詳細な情報を知ることができる。メールの名宛人ユーザは、当該受信エラーメールの詳細な情報（本文の一部など）を閲覧できるので当該受信できなかったメールの重要度を容易に判別できる。したがって、メールの名宛人ユーザは、少なくとも受信したいメールの容量分の空きを作ったのち、当該メールの送信元ユーザに対して再送依頼をしやすくなる。
【００７４】
なお、受信用メールボックス１０７ｅが容量制限超過のためにメールデータを格納できなかった場合、当該メール６０１を受信エラーメール一時格納領域１０７ｇに格納した後に、当該メール６０１の送信元宛てに、送信エラーメール６０２を返信するものとする。送信エラーメール６０２には、当該メールの名宛人になっているユーザの受信用メールボックスが容量制限超過のために格納できなかった旨と、当該メールの内容が記載されているものとする。送信元のユーザは、送信エラーメール６０２を受け取ることで、当該メールを送信できなったことが分かる。
【００７５】
なお、ＤＢサーバ１０８に格納された情報は情報抽出管理手段１０７ｃによって管理し、受信エラーの発生からシステム管理者が予め指定した期間（例えば１４日間）保持する。そして、受信エラー発生日時から指定期間を経過した時点で自動的に削除するようにすればよい。この場合、情報抽出管理手段１０７ｃは、１日のうちの決められた処理時間に自動的にこのチェック処理を起動し、ＤＢサーバ１０８に保持されている抽出情報の受信エラー発生日時情報と現在日時情報とを比較する。比較された日時情報が指定された期間（例えば１４日間：３３６時間）を超過していた場合、受信エラーメール処理手段１０７ｂは該当する抽出情報を削除する。指定期間を超過していない場合は削除処理を行わずにチェック処理を終了する。
【００７６】
以上、本実施形態について詳述したが、上記においては、受信用メールボックス１０７ｅが容量制限超過となったメールアドレスを保有する名宛人のみに情報通知メールを配信する態様について説明した。しかし、本発明はこのような場合に限定されない。すなわち、メールの名宛人が複数存在し、そのうち一部の名宛人のみが容量制限超過によってメールを受信できない場合において、無事にメールを受信できた他の名宛人にも情報通知メールを配信する態様も含まれる。すなわち、図９に示された情報通知メール（個別）の宛先９０４に記載されたメールアドレスのうち、“watanabe@xxxxx.jp”については問題なく対応する受信用メールボックス１０７ｅに格納されていた場合も本発明の実施態様に含まれる。この場合、受信エラーメール処理手段１０７ｂは、Ｓ２０６において“takahashi@xxxxx.jp”のために情報通知メールを生成すると同時に“watanabe@xxxxx.jp”のためにも情報通知メールを生成する。ここで、“watanabe@xxxxx.jp”のために生成される情報通知メールは、“watanabe@xxxxx.jp”が名宛人に含まれるメールに限ることが望ましい。自己に関係のないメールを他人が受信できていないことについてまで通知を受ける必要性は低いからである。このように無事にメールを受信できた名宛人についても情報通知メールを配信することにより、メールの名宛人となっているグループ内で誰に届いてないかが把握できるため、重要な情報の伝達漏れをより確実に防ぐことができる。
【００７７】
（第２の実施形態）
第１の実施形態においてはメールの受信エラーが発生した事実とその内容を情報通知メールによって当該メールの名宛人に通知した。ここでは、情報通知メールに代えてＷｅｂ画面に表示することにより名宛人に通知する第２の実施形態について説明する。
【００７８】
図３は第２の実施形態に係る本発明の処理の概要を示すフローチャートである。なお、Ｓ３０１〜Ｓ３０８は各ステップを示す。Ｓ３０１乃至Ｓ３０５は図２のＳ２０１乃至Ｓ２０５と同じであるためその説明を省略する。
【００７９】
Ｓ３０６において、メールの受信状況を確認したいユーザは、受信側クライアント装置１０２／１１０を介してＷＷＷサーバ１０９の通知画面用ＵＲＬ（不図示）にアクセスする。ここで、一例として、１０２はパーソナルコンピュータ、１１０はブラウザを搭載している携帯電話である。しかし、図示された受信側クライアント装置１０２／１１０に代えてインターネット１０３にアクセス可能なその他の電子情報機器、たとえばＰＤＡなどでも構わない。ＷＷＷサーバ１０９には認証処理手段１０９ｂがあり、アクセスしてきた受信側クライアント装置１０２／１１０に対してユーザ認証処理を行う。ユーザ認証処理が成功した場合はＳ３０７の処理に進む。ユーザ認証処理が失敗した場合、認証処理手段１０９ｂはＨＴＭＬ（Hyper Text Markup Language）で記述されたエラー画面を生成し、生成したＨＴＭＬデータを受信側クライアント装置１０２／１１０に転送して処理を終了する。
【００８０】
ユーザ認証処理が成功した後、Ｓ３０７では、情報表示手段１０９ａはユーザ認証に成功したユーザ情報（対応するメールアドレスなど）に基づき、ＤＢサーバ１０８に対して当該ユーザについての受信エラーメール抽出情報の有無を検索する。
【００８１】
当該ユーザに対応する受信エラーメール抽出情報が存在した場合、情報表示手段１０９ａは、ＨＴＭＬで記述した受信エラーメールの情報通知Ｗｅｂ画面（一覧）７０５を生成し、受信側クライアント装置１０２／１１０にインターネット１０２を介して転送する。当該ユーザに対応する受信エラーメール抽出情報が存在しなかった場合は、受信できていないメールが無い旨の情報通知Ｗｅｂ画面（一覧）７０５を生成し、受信側クライアント装置１０２／１１０に転送する。受信側クライアント装置１０２／１１０のブラウザが転送されたＨＴＭＬデータを受信し、ブラウザ画面上で情報通知Ｗｅｂ画面（一覧）７０５を表示する。
【００８２】
図１１は、情報通知Ｗｅｂ画面（一覧）の一例を示したものである。情報通知Ｗｅｂ画面（一覧）１１０１の上部には、ログインユーザ名１１０２、画面の名称１１０３が表示されている。１１０４は情報通知Ｗｅｂ画面（一覧）の本文であり、メールボックスの容量制限超過によりメールの受信エラーが発生したことを通知する内容の文言が表示される。１１０５は当該ユーザの受信用メールボックス１０７ｅの現時点での空き容量、受信エラーメールの総容量および前記容量の差異から必要となる必要メールボックス容量が表示される。１１０６には受信エラーとなっているメールの概要が一覧として示される。本実施例では、件名、送信者、受信日時、メールサイズが表示されている。なお、ここの「件名」は、受信エラーメールの件名であり、かつ、後述する情報通知Ｗｅｂ画面（個別）の件名でもある。下線表示は別画面が表示可能なことを意味し、いずれかの「件名」をクリックすると当該件名に対応した後述の情報通知Ｗｅｂ画面（個別）が表示される。１１０７は情報通知Ｗｅｂ画面のログイン状態からログアウト状態にするためのログアウトボタンである。
【００８３】
Ｓ３０８においては、各受信エラーメールの詳細情報を表す情報通知Ｗｅｂ画面（個別）を表示するための処理がなされる。Ｓ３０７で下線表示されている「件名」のいずれかがクリックされることでこの処理が開始される。まず、情報表示手段１０９ａが情報通知Ｗｅｂ画面（一覧）において指定された特定の受信エラーメールの抽出情報をＤＢサーバ１０８から取得し、取得した抽出情報に基づいて情報通知Ｗｅｂ画面（個別）を生成する。なお、この情報通知Ｗｅｂ画面（個別）も、情報通知Ｗｅｂ画面（一覧）と同様、ＨＴＭＬで記述されたデータとして生成される。そして、生成したＨＴＭＬデータをインターネット１０３を介して受信側クライアント装置１０２／１１０に対して転送する。受信側クライアント装置１０２／１１０のブラウザが転送されたＨＴＭＬデータを受信し、ブラウザ画面上で情報通知Ｗｅｂ画面（個別）を表示する。
【００８４】
図１２は、情報通知Ｗｅｂ画面（個別）の一例を示したものである。情報通知Ｗｅｂ画面（個別）１２０１は、送信者１２０２、送信日時１２０３、宛先(TO)１２０４、CC１２０５、件名１２０６および本文欄１２０７・１２０８から構成される。送信者１２０２には、受信エラーメールを送信した送信者の名称が表示される。本実施例では送信者の名称に代えて、当該送信者のメールアドレスが表示されている。送信日時１２０３には、受信エラーメールの送信日時が表示される。宛先（TO）１２０４には、受信エラーメールの宛先（TO）欄に記載されていた名宛人の名称あるいは当該名宛人のメールアドレスが表示される。CC１２０５には、受信エラーメールのCC欄に記載されていた名宛人の名称あるいは当該名宛人のメールアドレスが表示される。なお、本実施例では、宛先（TO）１２０４およびCC１２０５に、名宛人の名称に代えて、当該名宛人のメールアドレスがそれぞれ表示されている。件名１２０６には、受信エラーメールの件名が表示される。１２０７には、受信エラーメールの本文の内容が表示される。ただし、予め定められたデータサイズ（文字数）の範囲内に限られる。１２０８には受信エラーメールの添付ファイルに関する情報が表示される。すなわち、添付ファイルの有無、添付ファイルのファイル名およびサイズなどの情報が表示される。なお、添付ファイルそのものは削除されているため、情報通知Ｗｅｂ画面（個別）によっても受信エラーメールに添付されたファイルの内容までは確認することができない。しかしながら、拡張子を含んだファイル名やデータサイズを把握できるので、ある程度その内容も推測することができる。
【００８５】
図７は、実施形態２における各処理がどのように行われるかを視覚的に示す概要図である。
【００８６】
最初に、送信側クライアント装置１０１がインターネット１０３を経由してメール６０１を送信する。すると、当該メールの名宛人となっているユーザのメール受信サーバ１０７のＭＴＡ処理手段１０７ａが、当該名宛人ユーザの受信用メールボックス１０７ｅに対してメールデータの格納を試みる。その際、当該受信用メールボックス１０７ｅが容量制限超過のためにメールデータを格納できなかった場合、当該メール６０１を受信エラーメール一時格納領域１０７ｇに格納する。情報抽出管理手段１０７ｃはこの一時的に格納されたメールデータから必要な情報６０３を抽出し、ＤＢサーバ１０８に格納する。受信エラーメール一時格納領域１０７ｇに格納されたメール６０１は一時的に保持されたに過ぎず、必要な情報の抽出が終了した後は、速やかにメール受信サーバ１０７上から消去される。抽出された情報６０３は、送信日時、送信者、件名、宛先等、メールの名宛人が欲する情報となる。ここまでは図６と同様である。情報表示手段１０９ａは、まず、受信側クライアント装置１０２／受信側クライアント装置１１０上のブラウザからアクセスがあった場合、格納された情報６０３を基に情報通知Ｗｅｂ画面としてＨＴＭＬデータ７０５を生成する。そして、インターネット１０３を介して、生成したＨＴＭＬデータ７０５を受信側クライアント装置１０２／１１０に対し転送する。情報表示手段１０９ａについては公知の技術が適用可能であり、本発明に特有の技術事項ではないため詳しい説明は省略する。これにより名宛人ユーザは、送信者からのメールが受信できていない事実および当該受信エラーメールの詳細な情報を知ることができる。
【００８７】
（その他の実施形態）
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスクがある。また、更に、記録媒体としては、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、その接続先のホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。また、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【図１】
2010213193.tif 000003
【図２】
2010213193.tif 000004
【図３】
2010213193.tif 000005
【図４】
2010213193.tif 000006
【図５】
2010213193.tif 000007
【図６】
2010213193.tif 000008
【図７】
2010213193.tif 000009
【図８】
2010213193.tif 000010
【図９】
2010213193.tif 000011
【図１０】
2010213193.tif 000012
【図１１】
2010213193.tif 000013
【図１２】
2010213193.tif 000014
【図１３】
2010213193.tif 000015