JP5678945B2 - メールシステム、その制御方法、及びプログラム、並びに情報処理装置、その制御方法、及びプログラム - Google Patents

Description

本発明は、電子メールの管理に関し、特に複数台のクライアント装置で電子メールを受信する場合であっても、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫することなく管理することの可能なメールシステム、その制御方法、及びプログラム、並びに情報処理装置、その制御方法、及びプログラムに関する。

従来、ユーザがクライアント装置にインストールされたメーラーを利用して電子メール（以下、メール）を送受信することで、ユーザ間の情報の伝達を行っている。このようなメールシステムの仕組みとしては、以下のようなものが一般的である。まず、クライアント装置から送信されたメールはメールサーバに蓄積される。クライアント装置は、メールサーバにメールの取得要求を行うと、メールサーバは蓄積されたメールをクライアント装置に送信する。そして、クライアント装置はメールの受信が完了すると、受信したメールの削除要求をメールサーバに送信し、メールサーバはこれを受けてメールの削除を行う。このような仕組みにすることで、メールサーバに大量のメールが蓄積されないようにしている。

しかし、メールサーバに蓄積されたメールを複数台のクライアント装置で受信したい場合には上記の仕組みでは問題が発生する。例えば、１台目のクライアント装置でメールを受信した場合、当該クライアント装置がメールサーバに対して削除要求を行ってしまうので、２台目以降のクライアント装置はメールを受信できなくなってしまう。つまり、最初にメールを受信したクライアント装置にのみ当該メールが保存されるので、複数台のクライアント装置で同じメールを閲覧することができない。

このような問題を解決するために、クライアント装置からメールサーバに対して削除要求を送らないようにする仕組みが考えられる。しかしながら、クライアント装置からメールサーバに対して削除要求がなされないと、メールサーバにメールが蓄積され続けるので、メールサーバの容量を圧迫してしまう。よって、このような仕組みを採用する場合には、ユーザが使用するすべてのクライアント装置で受信が完了したら、ユーザが手作業でメールサーバ上のメールを削除していた。

この問題を解決するために、下記の特許文献１には、どの電子メール端末がどの電子メールを受信したのかを含むログ情報を元にした電子メールを自分宛てに送信し、当該電子メールを受信したら、当該電子メールに含まれるログ情報に基づいてすべての電子メール端末で当該電子メールを受信しているか否か判定し、受信していれば当該電子メールの削除要求をメールサーバに送信する仕組みが開示されている。

また、下記の特許文献２には、メール管理装置でメール配信先の端末ごとにメールの未読・既読状態を示す情報を記憶管理しており、メール管理装置が端末からメールの配信要求を受信すると、配信要求のあった端末のメールの未読状態を既読状態に変更し、すべての端末の未読・既読状態を示す情報が既読状態となった場合に、当該メールをメール管理装置から削除する仕組みが開示されている。

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

しかしながら、従来の仕組みでは、受信するクライアント装置を識別可能な情報（ＩＰアドレスやＭＡＣアドレス等）をあらかじめ登録しておく必要が生じる。上記の特許文献１では、使用するクライアント装置ごとにこのような識別情報を登録しておく必要があるし、上記の特許文献２では、メールサーバにクライアント装置の識別情報を登録しておかなければならない。このような情報を調べて登録するためには、ユーザが自分で調べて登録する必要があり非常に手間であるし、ユーザがクライアント装置の識別情報を調べるスキルが必要となってしまう。

また、クライアント装置が増えたり減ったりした場合には、都度登録し直さなくてはならないため、ユーザにとっては非常に管理しにくいものであった。

本発明は上記の課題を解決するためになされたもので、ユーザの手間をかけることなく、複数の情報処理装置において受信したメールをメールサーバから削除することの可能な仕組みを提供することを目的とする。

上記の目的を達成するために、本発明のメールシステムは、メールサーバと複数の情報処理装置とを含むメールシステムであって、前記複数の情報処理装置は、前記メールサーバから送信される、メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信手段と、前記複数の情報処理装置により前記メールを受信可能な回数を示す受信数を記憶する第１の記憶手段と、前記第１の記憶手段に記憶されている受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示手段とを備え、前記メールサーバは、前記情報処理装置に送信する前記メールを記憶する第２の記憶手段と、前記情報処理装置に前記メールを送信する場合に、前記第２の記憶手段に記憶された当該メールの前記受信済み回数情報を更新する受信済み回数情報更新手段と、前記受信済み回数情報更新手段で受信済み回数情報が更新された前記メールを前記情報処理装置に送信する送信手段と、前記情報処理装置の前記削除指示手段によるメールの削除指示に応じて、前記第２の記憶手段に記憶された当該メールの削除を行うメール削除手段とを備えることを特徴とする。

本発明によれば、ユーザの手間をかけることなく、複数の情報処理装置において受信したメールをメールサーバから削除することのできる効果を奏する。

本発明の実施形態におけるメールシステム１００の一例を示す構成図である。 図１に示すクライアント装置１０１及びメールサーバ１０２のハードウェア構成の一例を示す構成図である。 図１に示すクライアント装置１０１及びメールサーバ１０２のモジュール構成の一例を示す構成図である。 本発明の実施形態における一連の処理の流れを示すフローチャートである。 図４のステップＳ１０４における受信台数変更処理の詳細を示すフローチャートである。 受信台数変更画面６００、他端末変更メッセージ６１０、送信完了メッセージ６２０の一例を示す構成図である。 クライアント装置１０１に記憶された受信台数テーブル７００、メールサーバ７１０に記憶されたユーザ認証テーブル７１０の構成の一例を示す構成図である。 受信台数の変更がなされた場合に生成されるメールのメールヘッダーの一例を示す模式図である。 図４のステップＳ１０６におけるメール受信処理の詳細を示すフローチャートである。 図９に続き、図４のステップＳ１０６におけるメール受信処理の詳細を示すフローチャートである。 図１０に続き、図４のステップＳ１０６におけるメール受信処理の詳細を示すフローチャートである。 Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのないメールにＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔを付与した場合のメールヘッダーの一例を示す模式図である。 Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのあるメールでＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔの値をインクリメントした場合のメールヘッダーの一例を示す模式図である。 受信台数変更確認メッセージ１４００の一例を示す構成図である。 本発明の一連の処理の流れを示す模式図である。 受信台数を変更する場合の一連の処理の流れを示す模式図である。 本発明の第２の実施形態における、図４のステップＳ１０６におけるメール受信処理の一部の詳細を示すフローチャートである。 本発明の第２の実施形態における処理の概要を示す模式図である。

以下、図面を参照して、本発明の実施の形態の一例について説明する。

図１は、本発明のメールシステム１００のシステム構成の一例を示す図である。本発明のメールシステム１００は、クライアント装置１０１（クライアント装置１０１ａ、クライアント装置１０１ｂ、クライアント装置１０１ｃ）、メールサーバ１０２が設置されており、それら装置はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワーク１０３を介して相互にデータ通信可能に接続されている。図１のネットワーク１０３上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。

クライアント装置１０１（情報処理装置）は、メールサーバ１０２と通信し、メーラーを通じて電子メール（以下、メール）の送受信を行う装置である。メーラーは後述する図２のＲＯＭ２０２または外部メモリ２１１に記憶されており、ユーザからの指示に応じて、ＣＰＵ２０１がＲＡＭ２０３に読み出して各種動作を行う。

メーラーは、ユーザからの操作に応じて、メールの作成、送受信、表示等を行う。本実施形態では、クライアント装置１０１ａ、クライアント装置１０１ｂ、クライアント装置１０１ｃはそれぞれ１人のユーザが使用するクライアント装置１０１であるので、メーラーに設定されたユーザのアカウント（ユーザＩＤ、パスワード等）は同じアカウントが設定されているものとして説明を行う。尚、メールはメールサーバ１０２の外部メモリ２１１に記憶されていても、クライアント装置１０１の外部メモリ２１１に記憶されていてもよい。本実施形態では、クライアント装置１０１の外部メモリ２１１に記憶されているものとして、以下説明を行う。

メールサーバ１０２は、クライアント装置１０１から送信されたメールを宛先ごとに記憶管理し、クライアント装置１０１からの要求に応じてメールを送信する装置である。クライアント装置１０１との通信では、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）といったプロトコルを用いて送受信を行う。通信プロトコルについては、これに限らない。クライアント装置１０１とメールサーバ１０２の間でメールの送受信ができればよい。

尚、クライアント装置１０１が、メールサーバ１０２の構成を含んでもよいし、メールサーバ１０２がクライアント装置１０１の構成を含んでもよい。

図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ)やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明のクライアント装置１０１、メールサーバ１０２が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。

次に、クライアント装置１０１及びメールサーバ１０２のモジュール構成を示す機能構成図について、図３を用いて説明する。尚、図３の各種端末あるいはサーバのモジュール構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。

クライアント装置１０１は、記憶モジュール３０１、画面表示モジュール３０２、テーブル管理モジュール３０３、メール送受信モジュール３０４、メール削除要求モジュール３０５、第１の設定台数変更モジュール３０６、第２の設定台数変更モジュール３０７、変更メール生成モジュール３０８を備える。

記憶モジュール３０１（記憶手段）は、メーラーによって作成及び送受信されたメールを記憶するモジュールである。記憶モジュール３０１によって記憶されたメールは、クライアント装置１０１の外部メモリ２１１等に記憶され、必要に応じて、記憶モジュール３０１によって読みだされる。

画面表示モジュール３０２は、メールや画面といった各種情報をクライアント装置１０１のＣＲＴ２１０に表示させるためのモジュールである。特に本実施形態では、図６に示す受信台数変更画面６００や、他装置変更メッセージ６１０、送信完了メッセージ６２０、図１４に示す受信台数変更確認メッセージ１４００等を表示し、ユーザからの入力及び操作を受け付ける。

テーブル管理モジュール３０３は、後述する図７の受信台数テーブル７００やユーザ認証テーブル７１０の記憶や更新等を行うためのモジュールである。各種テーブルは、外部メモリ２１１に記憶され、必要に応じてＲＡＭ２０３に読み出す。

メール送受信モジュール３０４は、クライアント装置１０１で生成されたメールをメールサーバ１０２に送信したり、メールサーバ１０２に蓄積されたメールを受信したりするためのモジュールである。メール以外の情報が送信できてもよい。

メール削除要求モジュール３０５は、メールサーバ１０２から受信したメールのメールヘッダーに記載された情報と、後述する第１の設定台数変更モジュールで設定された受信台数とを比較して、削除すべきメールの削除要求をメールサーバ１０２に対して送信するためのモジュールである。

第１の設定台数変更モジュール３０６は、クライアント装置１０１のメーラーごとに受信したいクライアント装置１０１の台数を設定するためのモジュールである。第１の設定台数変更モジュール３０６は、ユーザからの指示に応じて台数の変更が可能である。

第２の設定台数変更モジュール３０７は、メール送受信モジュール３０４で受信したメールに後述する変更メール生成モジュール３０８で生成された受信台数を変更するためのメールがあった場合に、当該受信台数を変更するためのモジュールである。

変更メール生成モジュール３０８は、第１の設定台数変更モジュール３０６で受信台数が変更されると、他のクライアント装置１０１のメーラーに設定された受信台数を変更するためのメールを生成し、メール送受信モジュール３０４に送信させるためのモジュールである。

メールサーバ１０２は、記憶モジュール３１１、メールボックス管理モジュール３１２、ユーザ認証モジュール３１３、メール送受信モジュール３１４、メール削除モジュール３１５、メールヘッダー更新モジュール３１６を備える。

記憶モジュール３１１は、前述したクライアント装置１０１の記憶モジュール３０１と同様である。後述するメール送受信モジュール３１４によって受信したメールや、メールヘッダー更新モジュール３１６で更新されたメール等を記憶する（電子メール記憶手段）。

メールボックス管理モジュール３１２は、記憶モジュール３１１で記憶されたメールをアカウントごとに記憶管理するためのモジュールである。後述するメール送受信モジュール３１４によってメールの受信要求を受け付けた場合には、メールの取得を行うアカウントを特定し、そのアカウントのメールボックスからメールを取得して、メール送受信モジュール３１４に渡す。

ユーザ認証モジュール３１３は、クライアント装置１０１から送信されたユーザＩＤとパスワードに基づいて、メールシステム１００の利用者であるか否かを認証するためのモジュールである。

メール送受信モジュール３１４は、クライアント装置１０１とメールの送受信を行うためのモジュールである。

メール削除モジュール３１５は、クライアント装置１０１のメール削除要求モジュール３０５からメールの削除要求があった場合に、メールボックス管理モジュール３１２によって管理されるメールを削除する。

メールヘッダー更新モジュール３１６は、クライアント装置１０１からメールの取得要求に応じて、メールを送信する場合に、送信するメールのメールヘッダーを更新するためのモジュールである。メールヘッダーには、クライアント装置１０１に送信した回数、つまり受信したクライアント装置１０１の台数を示す情報が含まれており、それらをメール送信の際に追加、またはインクリメントする。

次に、本発明の実施形態におけるクライアント装置１０１によって行われる一連の処理について、図４に示すフローチャートを用いて説明する。尚、ステップＳ１０１乃至ステップＳ１０８の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。

また、この処理をクライアント装置１０１に実行させるためのプログラムは、クライアント装置１０１にインストールされているメーラーの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーとは別にインストールされたプログラムとして用意されていてもよい。

まず、ステップＳ１０１では、クライアント装置１０１は、クライアント装置１０１の外部メモリ２１１に記憶されたメーラーのプログラムを起動する。そして、ステップＳ１０２では、クライアント装置１０１は、メーラーに対してユーザからの操作を受け付ける。

ステップＳ１０３では、クライアント装置１０１は、ステップＳ１０２で受け付けた操作が受信台数変更指示であるか否かを判定する。例えば、メーラーのメニューから受信台数変更ボタン（不図示）が押下されたか否かを判定すればよい。受信台数変更指示であった場合には、ステップＳ１０４に処理を進め、そうでない場合には、ステップＳ１０５に処理を進める。

ステップＳ１０４では、クライアント装置１０１は、ユーザが同一のメールを受信したいクライアント装置の台数を変更する処理を実行する。受信台数変更処理の詳細は、後述する図５に示す。処理が終了したら、ステップＳ１０２に処理を戻す。

ステップＳ１０５では、クライアント装置１０１は、ステップＳ１０２で受け付けた操作がメールの受信指示であるか否かを判定する。例えば、メーラーのメニューからメール受信ボタン（不図示）が押下されたか否かを判定すればよい。メール受信指示であった場合には、ステップＳ１０６に処理を進め、そうでない場合には、ステップＳ１０７に処理を進める。

ステップＳ１０６では、クライアント装置１０１は、メールサーバ１０２に蓄積されたメールを受信する処理を実行する。メール受信処理の詳細は、後述する図９乃至図１１に示す。処理が終了したら、ステップＳ１０２に処理を戻す。

ステップＳ１０７では、クライアント装置１０１は、ステップＳ１０２で受け付けた操作がメーラーの終了指示であるか否かを判定する。例えば、メーラーのメニューから終了ボタン（不図示）が押下されたか否かを判定すればよい。終了指示であった場合には、ステップＳ１０８に処理を進め、そうでない場合には、ステップＳ１０２に処理を戻す。

ステップＳ１０８では、クライアント装置１０１は、メーラーの終了指示を受け付けたのでメーラーを終了し、本一連の処理を終了する。

次に、本発明の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われる受信台数変更処理について図５を用いて説明する。尚、ステップＳ２０１乃至ステップＳ２０８、ステップＳ２１２乃至ステップＳ２１５、ステップＳ２１９、ステップＳ２２０の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２０９乃至ステップＳ２１１、ステップＳ２１６乃至ステップＳ２１８の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。

また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。

受信台数変更処理は、ユーザが受信したいクライアント装置１０１の台数を設定するための処理である。後述するメール受信処理ですべてのクライアント装置１０１で受信がなされたか否かを判定する際に、受信台数変更処理で設定された受信台数を使用する。

まず、ステップＳ２０１では、クライアント装置１０１は、図６に示すような受信台数変更画面６００をクライアント装置１０１のＣＲＴ２１０に表示させる。受信台数変更画面６００は、ユーザＩＤ入力欄６０１、パスワード入力欄６０２、受信台数入力欄６０３、ＯＫボタン６０４から構成される。ユーザＩＤ入力欄６０１とパスワード入力欄６０２には、ユーザごとに設定されたユーザＩＤとパスワードの入力を受け付ける入力フォームである。受信台数入力欄６０３は、ユーザが同一のメールを受信したいクライアント装置１０１の台数の入力を受け付ける入力フォームである。

ステップＳ２０２では、クライアント装置１０１は、ユーザＩＤ入力欄６０１、パスワード入力欄６０２、受信台数入力欄６０３にそれぞれ入力され、ＯＫボタン６０４が押下されたか否かを判定する。ＯＫボタン６０４が押下されたと判定された場合には、ステップＳ２０３に処理を進め、そうでない場合にはそのまま待機する。

ステップＳ２０３では、クライアント装置１０１は、クライアント装置１０１の外部メモリ２１１に記憶された図７に示す受信台数テーブル７００の受信台数７０１を、受信台数入力欄６０３に入力された値に変更する（第１の設定台数変更手段）。

受信台数テーブル７００（図７参照）は、受信台数７０１から構成される。受信台数７０１（設定台数情報）は、同一のメールを受信したいクライアント装置１０１の台数を示す情報である。

図７に示す受信台数７０１には「２」が格納されているが、図６に示すように受信台数入力欄６０３に「３」と入力されている場合には、受信台数７０１を「３」に変更する。こうすることで、ユーザが同一のメールを受信したいクライアント装置１０１の台数を変更することができる。これをすべてのクライアント装置１０１で行ってもよいし、後述するステップＳ２０４乃至ステップＳ２２０、図１０のステップＳ３２５乃至ステップＳ３２９の処理によって変更させてもよい。

ステップＳ２０４では、クライアント装置１０１は、図６に示すような他装置変更メッセージ６１０をクライアント装置１０１のＣＲＴ２１０に表示させる。つまり、受信台数７０１を変更したということは、他のクライアント装置１０１においても変更する必要がある。例えば、ユーザがクライアント装置１０１ａとクライアント装置１０１ｂの２台を使用していたところに、クライアント装置１０１ｃを追加した場合には、各クライアント装置１０１で受信台数の設定変更が必要となる。この設定変更は、台数が多ければ多いほどユーザにとって手間となってしまうので、受信台数７０１を自動的に変更できるメールを自分宛てに送信することで、設定を簡単にする。受信台数変更処理では、このメールを送信する処理について説明を行い、後述するメール受信処理でこのメールを受信した場合の処理について説明を行う。

ステップＳ２０５では、クライアント装置１０１は、他のクライアント装置１０１も変更する指示がなされたか否かを判定する。つまり、他装置変更メッセージ６１０のはいボタン６１１が押下されたか否かを判定する。はいボタン６１１が押下されたと判定された場合には、ステップＳ２０６に処理を進め、そうでない場合には、受信台数変更処理を終了し、呼び出し元に処理を戻す。

ステップＳ２０６では、クライアント装置１０１は、クライアント装置１０１のメーラーによってメールヘッダーに変更された受信台数を通知するための項目を追加したメールを生成する。具体的には、図８の受信台数変更メールヘッダー８００のメールヘッダー情報８０１に示すように、メールヘッダーに「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」という項目を追加したメールを生成する。尚、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。また、メールヘッダーには「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」という項目も追加する。この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」（受信済み台数情報）は、メールサーバ１０２がメールを送信した回数、つまりクライアント装置１０１でメールを受信した回数を示す項目である。この項目の値と、前述したステップＳ２０３で設定された受信台数７０１に基づいて、メールサーバ１０２に対してクライアント装置１０１が削除要求を送信するか否か決定する。尚、「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」と同様に、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報やファイルでもよいし、メールの添付ファイルとして生成されてもよい。また、すでにステップＳ２０３で設定変更されたクライアント装置１０１は再度生成したメールを受信する必要はないので、図８のメールヘッダー情報８０２に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を「１」と設定しておく。そして、自分宛てに送信するため、メールヘッダー情報８０３に示すように、宛先を示す「Ｔｏ」には自分のアドレスを設定する。自分のアドレスは、メーラーにあらかじめ設定されているアカウントから取得してもよいし、ユーザＩＤ入力欄６０１に入力されたメールアドレスを使用してもよい。

ステップＳ２０７では、クライアント装置１０１は、ステップＳ２０６で生成された「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」にステップＳ２０３で変更された受信台数７０１を設定する。受信台数７０１が「２」から「３」に変更されたのであれば、図８のメールヘッダー情報８０１に示すように「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」に「３」を設定する。

ステップＳ２０８では、クライアント装置１０１は、ステップＳ２０６及びステップＳ２０７で生成、設定されたメールを送信するために、ユーザＩＤ入力欄６０１及びパスワード入力欄６０２に入力されたユーザＩＤとパスワードをメールサーバ１０２に送信する。つまり、メール送信のためのユーザ認証を行う。

ステップＳ２０９では、メールサーバ１０２は、クライアント装置１０１から送信されたユーザＩＤとパスワードを受信する。そして、ステップＳ２１０では、メールサーバ１０２は、受信したユーザＩＤとパスワードと、メールサーバ１０２の外部メモリ２１１に記憶されたユーザ認証テーブル７１０に基づいてユーザ認証を行う。受信したユーザＩＤとパスワードの組み合わせがユーザ認証テーブル７１０のユーザＩＤ７１１とパスワード７１２の組み合わせに存在すれば、認証ＯＫとなるが、そうでなければ認証ＮＧとなる。

ユーザ認証テーブル７１０（図７参照）は、ユーザＩＤ７１１とパスワード７１２から構成される。ユーザＩＤ７１１は、ユーザごとに識別可能な情報である。本実施形態においては、ユーザのメールアドレスをユーザＩＤとして格納する。パスワード７１２は、ユーザ認証に必要なパスワードである。ユーザＩＤ７１１とパスワード７１２はあらかじめ管理者やユーザから登録されているものとする。

ステップＳ２１１では、メールサーバ１０２は、ステップＳ２１０で認証された結果をクライアント装置１０１に返信する。

ステップＳ２１２では、クライアント装置１０１は、メールサーバ１０２から送信されたユーザ認証の結果を受信する。そして、ステップＳ２１３では、クライアント装置１０１は、その受信結果が認証ＯＫであったか否かを判定する。認証ＯＫであった場合には、ステップＳ２１５に処理を進め、認証ＮＧであった場合には、ステップＳ２１４に処理を進める。

ステップＳ２１４では、クライアント装置１０１は、認証ＮＧであったため接続エラーをユーザに通知して、受信台数変更処理を終了し、呼び出し元に処理を戻す。

ステップＳ２１５では、クライアント装置１０１は、ステップＳ２０６及びステップＳ２０７で生成、設定されたメールをメールサーバ１０２に送信する（変更メール送信手段）。

ステップＳ２１６では、メールサーバ１０２は、クライアント装置１０１から送信されたメールを受信し、ステップＳ２１７では、受信したメールの宛先に対応するメールボックスにメールを格納する。つまり、当該ユーザのメールボックスに格納されることになる。ステップＳ２１８では、メールサーバ１０２は、メールの格納が完了した結果をクライアント装置１０１に送信する。

ステップＳ２１９では、クライアント装置１０１は、メールの格納結果を受信し、ステップＳ２２０では、図６に示すような送信完了メッセージ６２０をクライアント装置１０１のＣＲＴ２１０に表示させ、受信台数変更処理を終了し、呼び出し元に処理を戻す。

以上のようにすることで、クライアント装置１０１の受信台数を変更し、更に変更に応じて他のクライアント装置１０１の受信台数を変更可能なメールを自分宛てに送信することができる。

次に、本発明の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われるメール受信処理について図９乃至図１１を用いて説明する。尚、ステップＳ３０１、ステップＳ３０５乃至ステップＳ３０８、ステップＳ３１２乃至ステップＳ３１７、ステップＳ３２４乃至ステップＳ３３１、ステップＳ３３５、ステップＳ３３６の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ３０２乃至ステップＳ３０４、ステップＳ３０９乃至ステップＳ３１１、ステップＳ３１８乃至ステップＳ３２３、ステップＳ３３２乃至ステップＳ３３４の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。

また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。

メール受信処理は、クライアント装置１０１がメールサーバ１０２に蓄積されたメールを受信し、前述した受信台数変更処理で設定された受信台数分受信されている場合に、メールサーバ１０２に対して削除要求を送信するための処理である。

まず、図１５を参照してメール受信処理の処理概要について説明を行う。まず、前述した受信台数変更処理でクライアント装置１０１のメーラーによって受信台数７０１が設定される。そして、ユーザからの指示に応じて、クライアント装置１０１がメールサーバ１０２に対してメールの受信要求を送信する。メールサーバは、メールの受信要求を受信すると、メールボックスに蓄積されたメールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントする。ここで、メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」がない場合には、新しく追加する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」は前述の通り、当該メールがクライアント装置１０１に受信された回数を示す情報である。

「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の更新が完了したら、メールの受信要求が来たクライアント装置１０１に対して当該メールを送信する。クライアント装置１０１は、メールの受信が完了すると、受信したメールのメールヘッダーに付された「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値と、クライアント装置１０１のメーラーに設定された受信台数７０１とを比較し、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上であったら、当該メールの削除要求をメールサーバ１０２に対して送信する。そうでないメールについては、削除要求を送信しない。メールサーバ１０２では、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上となったメールの削除要求を受信し、当該メールをメールボックスから削除する。こうすることで、設定された受信台数分の受信が完了したら、クライアント装置１０１からメールサーバ１０２に対して当該メールの削除要求を送信することができるので、ユーザは受信台数をクライアント装置１０１に設定するだけで、メールサーバの容量を圧迫せずに、必要な台数分メールを受信することができる。以下、この詳細な説明を行う。

まず、ステップＳ３０１では、クライアント装置１０１は、ユーザ認証を行うべく、メーラーにあらかじめ設定されたユーザＩＤとパスワードをメールサーバ１０２に送信する。

ステップＳ３０２では、メールサーバ１０２は、クライアント装置１０１から送信されたユーザＩＤとパスワードを受信し、ステップＳ３０３では、受信したユーザＩＤとパスワードと、メールサーバ１０２の外部メモリ２１１に記憶されたユーザ認証テーブル７１０に基づいてユーザ認証を行う。受信したユーザＩＤとパスワードの組み合わせがユーザ認証テーブル７１０のユーザＩＤ７１１とパスワード７１２の組み合わせに存在すれば、認証ＯＫとなるが、そうでなければ認証ＮＧとなる。

ステップＳ３０４では、メールサーバ１０２は、ステップＳ３０３で認証された結果をクライアント装置１０１に返信する。

ステップＳ３０５では、クライアント装置１０１は、メールサーバ１０２から送信されたユーザ認証の結果を受信する。そして、ステップＳ３０６では、クライアント装置１０１は、その受信結果が認証ＯＫであったか否かを判定する。認証ＯＫであった場合には、ステップＳ３０８に処理を進め、認証ＮＧであった場合には、ステップＳ３０７に処理を進める。

ステップＳ３０７では、クライアント装置１０１は、認証ＮＧであったため接続エラーをユーザに通知して、メール受信処理を終了し、呼び出し元に処理を戻す。

ステップＳ３０８では、クライアント装置１０１は、メールサーバ１０２のメールボックスに蓄積されたすべてのメールのメールヘッダーの取得をメールサーバ１０２に対して要求する。後述するステップＳ３１３及びステップＳ３１４で、既に受信済みのメールと新たに受信すべきメールを特定するためにこのような処理を行っている。

ステップＳ３０９では、メールサーバ１０２は、クライアント装置１０１から送信されたすべてのメールのメールヘッダー取得要求を受信する。そして、ステップＳ３１０では、メールサーバ１０２は、ステップＳ３０３で認証されたユーザのメールボックスに蓄積されたすべてのメールからメールヘッダーを取得する。ここでは少なくともメールを一意に特定する識別情報である「Ｍｅｓｓａｇｅ−ｉｄ」を含めて取得するようにする。他にもメールを一意に特定できるような情報があれば、それで代用しても構わない。

ステップＳ３１１では、メールサーバ１０２は、ステップＳ３１０で取得したすべてのメールのメールヘッダーをクライアント装置１０１に送信する。

ステップＳ３１２では、クライアント装置１０１は、メールサーバ１０２から送信されたメールヘッダーを受信し、ステップＳ３１３では、クライアント装置１０１は、受信したメールヘッダーとクライアント装置１０１に受信済みのメールのメールヘッダーとを比較し、新たに受信すべきメールの有無を確認する。具体的には、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールをクライアント装置１０１のメーラーから検索するようにすればよい。受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にあれば、既にそのメールは受信済みであると判定できる。しかし、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にないのであれば、当該「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールは、新たにメールサーバ１０２から受信すべきメールであると判定できる。

ステップＳ３１４では、クライアント装置１０１は、ステップＳ３１３で確認した結果、新たに受信すべきメールが存在するか否かを判定する。新たに受信すべきメールが存在すると判定された場合には、図１０のステップＳ３１６に処理を進め、新たに受信すべきメールが存在しないと判定された場合には、ステップＳ３１５に処理を進める。

ステップＳ３１５では、クライアント装置１０１は、新たに受信すべきメールが存在しないので、その旨をユーザに通知する。そして、メール受信処理を終了し、呼び出し元に処理を戻す。

図９に続き、図１０を用いて説明を行う。ステップＳ３１６では、クライアント装置１０１は、後述するステップＳ３１７乃至ステップＳ３２９、図１１のステップＳ３３０乃至ステップＳ３３５の処理を受信するメール数分繰り返す。受信するメール数分のループが完了したら、ループを抜けて、図１１のステップＳ３３６に処理を進める。

ステップＳ３１７では、クライアント装置１０１は、新たに受信すべきメールの受信要求をメールサーバ１０２に対して送信する（取得要求送信手段）。ここでは、新たに受信すべきメールのうち、１通のメールについての受信要求を送信する。メールの受信順序は問わない。

ステップＳ３１８では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの受信要求を受信する。そして、ステップＳ３１９では、メールサーバ１０２は、クライアント装置１０１から要求されたメールを当該ユーザのメールボックスから取得する。

ステップＳ３２０では、メールサーバ１０２は、ステップＳ３１９で取得したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在するか否かを判定する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在する場合には、ステップＳ３２２に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しない場合には、ステップＳ３２１に処理を進める。

ステップＳ３２１では、メールサーバ１０２は、ステップＳ３１９で受信したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないので、新たにメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、値を「１」に設定する（更新手段、カウントアップ）。図１２の受信メールヘッダー１２００に示すように、元々はメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないメールについては、メールヘッダー情報１２０１に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を新たに追加し、値に「１」を設定する。ここで「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値を「１」に設定するのは、これからクライアント装置１０１にメールを送信することで、１台の装置で受信がなされるからである。

ステップＳ３２２では、メールサーバ１０２は、ステップＳ３１９で取得したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントする（更新手段）。図１３の受信メールヘッダー１３００のメールヘッダー情報１３０１に示すように、ステップＳ３１９で取得したメールのメールヘッダーには既に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」として値に「１」が設定されている。つまり、既に１台のクライアント装置１０１に当該メールを送信していることを示している。今回新たにメールを送信するため、この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に更に「１」を加算して、メールヘッダー情報１３０２に示すように値を「２」に変更する。このようにすることで、何台のクライアント装置１０１に送信したのかを記録しておくことができる。尚、前述した通り、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。

ステップＳ３２３では、メールサーバ１０２は、ステップＳ３１９で取得し、ステップＳ３２１またはステップＳ３２２で「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加または更新を行ったメールをクライアント装置１０１に送信する（送信手段）。

ステップＳ３２４では、クライアント装置１０１は、メールサーバ１０２から送信されたメールを受信する（受信手段）。

ステップＳ３２５乃至ステップＳ３２９は、前述した受信台数変更処理で送信した受信台数変更のためのメールに応じた処理を実行するステップである。図１６を参照してこの処理概要について説明を行う。前述した受信台数変更処理でクライアント装置１０１の受信台数７０１を変更すると、自分宛てにメールを生成し、当該メールのメールヘッダーに「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、変更した受信台数を「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値として設定し、メールサーバ１０２に送信する。そして、他のクライアント装置１０１で、自分宛てに送信した「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」付きメールを受信すると、当該クライアント装置１０１のメーラーに設定された受信台数７０１と、受信したメールの「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値を比較して、一致しなければ、受信台数７０１を「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に更新する。図１６に示すように、クライアント装置１０１ａで受信台数７０１を「３」に変更した場合には、「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に「３」を設定したメールを自分宛てに送信する。そして、受信台数７０１が「２」のクライアント装置１０１ｂで送信したメールを受信すると、クライアント装置１０１ｂの受信台数７０１を「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値である「３」に変更する。こうすることで、１台のクライアント装置１０１を変更するだけで、他のクライアント装置１０１の受信台数７０１も自動的に変更することが可能となる。以下、この処理についてステップＳ３２５乃至ステップＳ３２９で詳細な説明を行う。

ステップＳ３２５では、クライアント装置１０１は、ステップＳ３２４で受信したメールのメールヘッダーに「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在するか否かを判定する。つまり、前述した受信台数変更処理で自分宛てに送信した受信台数変更のためのメールであるかどうかを判定することになる。「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在する場合には、ステップＳ３２６に処理を進め、「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しない場合には、図１１のステップＳ３３０に処理を進める。

ステップＳ３２６では、クライアント装置１０１は、クライアント装置１０１のメーラーに設定された受信台数７０１と、ステップＳ３２４で受信したメールの「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が一致するか否かを判定する。一致すると判定された場合には、図１１のステップＳ３３０に処理を進め、一致しないと判定された場合には、ステップＳ３２７に処理を進める。

ステップＳ３２７では、クライアント装置１０１は、図１４に示すような受信台数変更確認メッセージ１４００をクライアント装置１０１のＣＲＴ２１０に表示させる。自動的にクライアント装置１０１の受信台数７０１を変更してしまってもよいが、ここではユーザに対して変更するか否かの選択を受け付けるようにする。

ステップＳ３２８では、クライアント装置１０１は、受信台数の変更指示をユーザから受け付けたかどうかを判定する。具体的には、受信台数変更確認メッセージ１４００に備えられたはいボタン１４０１が押下されたか否かを判定する。はいボタン１４０１が押下されたと判定された場合には、ステップＳ３２９に処理を進め、そうでない場合には、図１１のステップＳ３３０に処理を進める。

ステップＳ３２９では、クライアント装置１０１は、クライアント装置１０１の受信台数７０１を、ステップＳ３２４で受信したメールの「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に変更する（第２の設定台数変更手段）。クライアント装置１０１の受信台数７０１が「２」で、「Ｃｈａｎｇｅ−Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「３」であれば、受信台数７０１を「３」に変更する。こうすることで、自分宛てに送信された受信台数変更のメールに基づき、クライアント装置１０１の受信台数７０１を変更することができる。

図１０に続き、図１１を用いて説明を行う。ステップＳ３３０では、クライアント装置１０１は、前述したステップＳ３２４で受信したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が、クライアント装置１０１のメーラーに設定された受信台数７０１以上であるか否かを判定する。つまり、設定された受信台数分受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、当該メールの削除要求を後述するステップＳ３３１で送信するが、そうでなければ削除要求を発行せずに次のメールの処理に移る。このような仕組みでメールサーバ１０２のメールボックスに蓄積されたメールを削除するようにすれば、ユーザは受信台数を各クライアント装置１０１に設定するだけで、サーバの容量を圧迫することなく、複数台のクライアント装置１０１で同一のメールを受信することができるようになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上であると判定された場合には、ステップＳ３３１に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上でないと判定された場合には、ステップＳ３１６に処理を戻す。尚、ステップＳ３３１に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上でないと判定された場合で、すべての受信メールに対して処理が完了している場合には、ステップＳ３３６に処理を進める。

ステップＳ３３１では、クライアント装置１０１は、設定された受信台数分受信が完了したので、当該メールの削除要求をメールサーバ１０２に送信する（削除要求送信手段）。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。

ステップＳ３３２では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの削除要求を受信する。そして、ステップＳ３３３では、メールサーバ１０２は、受信したメールの削除要求に基づいて、該当するメールをメールボックスから削除する（削除手段）。削除するメールは、クライアント装置１０１から送信された「Ｍｅｓｓａｇｅ−ｉｄ」やユーザＩＤ等から特定する。削除が完了したら、ステップＳ３３４では、メールサーバ１０２は、削除結果をクライアント装置１０１に送信する。

ステップＳ３３５では、クライアント装置１０１は、メールサーバ１０２から送信された削除結果を受信し、処理をステップＳ３１６に戻す。尚、すべての受信メールに対して処理が完了している場合には、ステップＳ３３６に処理を進める。

ステップＳ３３６では、クライアント装置１０１は、前述したステップＳ３２４で受信したメール一覧をユーザに対して閲覧可能にＣＲＴ２１０に表示させる。表示が完了したら、メール受信処理を終了し、呼び出し元に処理を戻す。

次に、本発明の第２の実施形態について説明を行う。

前述した実施形態では、同一のメールを複数受信したとしても、１通ずつ処理を行うことになる。例えば、個人アドレスと同様のアドレスを含むメーリングリストに対して送信すると、「Ｍｅｓｓａｇｅ−ｉｄ」が重複した同じ内容の２通のメールがメーラーに受信される。１台のクライアント装置１０１のみで受信する場合は、重複したメールは受信後にメールサーバから削除される。しかし、複数端末から受信する場合は、全端末から受信が完了するまで、重複メールが削除されないため不要な重複メールが長期間メールサーバに残ってしまう。

第２の実施形態では、この問題点を解決するために、前述したステップＳ３３０における「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の判定で未受信のクライアント装置１０１があると判定されたメールについて、重複メールか否かを判定し、重複メールであると判定された場合には、メールサーバ１０２に対して削除要求を送信する。つまり、メールが未受信のクライアント装置１０１があったとしても、重複メールなら削除要求を送信する仕組みである。

第２の実施形態の処理概要について、図１８を用いて説明する。図１８は、第２の実施形態の処理概要を示す概要図である。まず、前述した実施形態と同様に、クライアント装置１０１がメールサーバ１０２からメールを受信する。その結果、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が所定値未満だった場合には、まだ未受信のクライアント装置１０１が存在するので、メールサーバ１０２には削除要求を送信しない。そして、第２の実施形態では、ここであとから送信されてくるメールが重複メールかどうかを判定するために、受信したメールをＲＡＭ２０３等の一時領域に保存しておく。これらの処理が終了したら、クライアント装置１０１は残りのメールの取得をメールサーバ１０２に要求する。そして、メールサーバ１０２から送信されたメールを受信する。クライアント装置１０１は、メールを受信し、未受信のクライアント装置１０１が存在するメールであると判定された場合には、そのメールが一時領域に記憶されたメールと重複するメールか否かを判定する。重複するメールとは、「Ｍｅｓｓａｇｅ−ｉｄ」、「Ｆｒｏｍ」、「Ｓｕｂｊｅｃｔ」といったメールヘッダーが同じメールである。メールの宛先には、「Ｔｏ」、「Ｃｃ」、「Ｂｃｃ」の３つが存在し、このうち２種類以上に同じ宛先が指定されると、２通メールを受信することになってしまう。これを重複メールと示す。重複メールであると判定された場合には、未受信のクライアント装置１０１に受信させたり、メールサーバ１０２に残しておいたりしたくないので、当該メールの削除要求をメールサーバ１０２に送信する。このようにすることで、未受信のクライアント装置１０１で重複メールを受信することがなくなる上、メールサーバ１０２の容量を作成することができるようになる。

次に、第２の実施形態における一連の処理の流れについて説明を行う。尚、第２の実施形態のシステム構成、ハードウェア構成、モジュール構成は、前述した実施形態と同様であるので、説明を省略する。また、第２の実施形態は、前述した実施形態で説明を行ったメール受信処理に関する別の実施形態である。そのため、図１０、図１１の各ステップにおける処理は、第２の実施形態においても同様であるので、図１２のステップＳ３３０に相当するステップから説明を行う。その他、画面やデータ、用語の定義についても、前述した実施形態と同様である。

本発明の第２の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われるメール受信処理について、図１７に示すフローチャートを用いて説明する。尚、ステップＳ４０１、ステップＳ４０２、ステップＳ４０６乃至ステップＳ４０８、ステップＳ４１４、ステップＳ４１５の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ４０３乃至ステップＳ４０５、ステップＳ４０９乃至ステップＳ４１１の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。

また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。

また、図１７のステップＳ４０１は、前述した図１０のステップＳ３２５、またはステップＳ３２６、またはステップＳ３２８、またはステップＳ３２９から所定の判定または処理が終了した後に、実行が開始されるステップである。

ステップＳ４０１では、クライアント装置１０１は、前述したステップＳ３２４で受信したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が、クライアント装置１０１のメーラーに設定された受信台数７０１以上であるか否かを判定する。つまり、設定された受信台数分受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、当該メールの削除要求を後述するステップＳ４０２で送信するが、そうでなければ削除要求を発行せずに次のメールの処理に移る。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上であると判定された場合には、ステップＳ４０２に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７０１以上でないと判定された場合には、ステップＳ４０７に処理を進める。

ステップＳ４０２では、クライアント装置１０１は、設定された受信台数分受信が完了したので、当該メールの削除要求をメールサーバ１０２に送信する（削除要求送信手段）。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。

ステップＳ４０３では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの削除要求を受信する。そして、ステップＳ４０４では、メールサーバ１０２は、受信したメールの削除要求に基づいて、該当するメールをメールボックスから削除する（削除手段）。削除するメールは、クライアント装置１０１から送信された「Ｍｅｓｓａｇｅ−ｉｄ」やユーザＩＤ等から特定する。削除が完了したら、ステップＳ４０５では、メールサーバ１０２は、削除結果をクライアント装置１０１に送信する。

ステップＳ４０６では、クライアント装置１０１は、メールサーバ１０２から送信された削除結果を受信し、処理をステップＳ３１６に戻す。尚、すべての受信メールに対して処理が完了している場合には、ステップＳ４１４に処理を進める。

ステップＳ４０７では、クライアント装置１０１は、未受信のクライアント装置１０１があると判定されたメールが、クライアント装置１０１のＲＡＭ２０３等に一時記憶されたメールと重複するメールであるか否かを判定する（重複メール判定手段）。クライアント装置１０１のＲＡＭ２０３等には、後述するステップＳ４１３で記憶された重複メール判定用のメールが保存されている。このメールは、未受信のクライアント装置１０１が存在するメールであり、かつ重複メールでないと判定されたメールである。本実施形態では１通ずつ受信し、ステップＳ４１３までの処理を行っていくため、重複メールがある場合には、後から送信されてくることになる。よって、受信したメールを一時的に記憶しておき、後から受信されたメールを比較することで、重複メールかどうかを判定している。重複するか否かは、メールのメールヘッダーを比較するようにすればよい。基本的には「Ｍｅｓｓａｇｅ−ｉｄ」同士を比較すればよい。しかし、「Ｍｅｓｓａｇｅ−ｉｄ」はランダムに生成された識別情報なので、異なる内容のメールだが同じ「Ｍｅｓｓａｇｅ−ｉｄ」となってしまう可能性がある。よって、「Ｍｅｓｓａｇｅ−ｉｄ」以外の「Ｆｒｏm」や「Ｓｕｂｊｅｃｔ」といったメールヘッダーを併用してもよい。重複メールかどうかの判定方法はこれに限らない。重複メールであると判定された場合には、ステップＳ４０８に処理を進め、そうでない場合には、ステップＳ４１３に処理を進める。

ステップＳ４０８では、クライアント装置１０１は、重複メールであると判定されたので、当該メールの削除要求をメールサーバ１０２に送信する。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。

ステップＳ４０９では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの削除要求を受信する。そして、ステップＳ４１０では、メールサーバ１０２は、受信したメールの削除要求に基づいて、該当するメールをメールボックスから削除する。削除するメールは、クライアント装置１０１から送信された「Ｍｅｓｓａｇｅ−ｉｄ」やユーザＩＤ等から特定する。削除が完了したら、ステップＳ４１１では、メールサーバ１０２は、削除結果をクライアント装置１０１に送信する。

ステップＳ４１２では、クライアント装置１０１は、メールサーバ１０２から送信された削除結果を受信し、処理をステップＳ３１６に戻す。尚、すべての受信メールに対して処理が完了している場合には、ステップＳ４１４に処理を進める。

ステップＳ４１３では、クライアント装置１０１は、ステップＳ４０７で重複メールではないと判定されたので、当該メールをクライアント装置１０１に備えられたＲＡＭ２０３等の一時記憶領域に保存する。保存されたメールは、前述したステップＳ４０７で重複メールであるか否かの判定を行うために利用される。尚、本実施形態では、メール自体を保存するようにしているが、当該メールからステップＳ４０７における判定で必要なメールヘッダーのみを抽出して保存する形態でもよい。

ステップＳ４１４では、クライアント装置１０１は、メールサーバ１０２に保存されたメールをすべて受信したので、重複メールを判定するために保存していたメールをすべて削除する。つまり、ステップＳ４１３でクライアント装置１０１のＲＡＭ２０３等に記憶したメールをすべて削除するということである。

ステップＳ４１５では、クライアント装置１０１は、前述したステップＳ３２４で受信したメール一覧をユーザに対して閲覧可能にＣＲＴ２１０に表示させる。表示が完了したら、メール受信処理を終了し、呼び出し元に処理を戻す。

以上説明したように、本実施形態によれば、メールを受信するクライアント装置ごとに受信台数を設定しておくだけで、当該受信台数に達したメールの削除要求をメールサーバに送信することが可能となるので、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫しないように複数台のクライアント装置でメールを受信することのできる効果を奏する。

本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００ メールシステム
１０１ａ クライアント装置
１０１ｂ クライアント装置
１０１ｃ クライアント装置
１０２ メールサーバ
１０３ ネットワーク
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆ（インターフェース）コントローラ
２０９ 入力装置
２１０ ディスプレイ装置
２１１ 外部メモリ

Claims (12)

1. メールサーバと複数の情報処理装置とを含むメールシステムであって、
   前記複数の情報処理装置は、
   前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信手段と、
   前記複数の情報処理装置により前記メールを受信可能な回数を示す受信数を記憶する第１の記憶手段と、
   前記第１の記憶手段に記憶されている受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示手段と
   を備え、
   前記メールサーバは、
   前記複数の情報処理装置に送信する前記メールを記憶する第２の記憶手段と、
   前記複数の情報処理装置のうちの一の情報処理装置に前記メールを送信する場合毎に、前記第２の記憶手段に記憶された当該メールの前記受信済み回数情報を更新する受信済み回数情報更新手段と、
   前記受信済み回数情報更新手段で受信済み回数情報が更新された前記メールを前記情報処理装置に送信する送信手段と、
   前記情報処理装置の前記削除指示手段によるメールの削除指示に応じて、前記第２の記憶手段に記憶された当該メールの削除を行うメール削除手段と
   を備えることを特徴とするメールシステム。
2. 前記メールサーバは、
   前記情報処理装置に送信するメールに前記受信済み回数情報が付与されていない場合、新しく受信済み回数情報を書き込む書き込み手段を更に備えることを特徴とする請求項１に記載のメールシステム。
3. 前記情報処理装置は、
   ユーザからの指示に基づいて、前記第１の記憶手段に記憶された受信数を更新する第１の受信数更新手段と、
   前記受信数更新手段で前記受信数が更新された場合に、当該情報処理装置とは異なる情報処理装置の記憶手段に記憶された受信数を更新するためのメールを前記メールサーバに送信する更新メール送信手段と、
   前記更新メール送信手段で送信されたメールを受信した場合には、前記記憶手段に記憶された受信数を、当該メールに基づいて更新する第２の受信数更新手段と
   を更に備えることを特徴とする請求項１または２に記載のメールシステム。
4. 前記第２の受信数更新手段は、前記記憶手段に記憶された受信数と、前記第１の受信数更新手段で更新された受信数とが一致しない場合に、当該メールに基づいて変更することを特徴とする請求項３に記載のメールシステム。
5. 前記受信済み回数情報は、前記送信手段で送信されるメールのヘッダに記載される情報であることを特徴とする請求項１乃至４のいずれか１項に記載のメールシステム。
6. 前記受信済み回数情報更新手段は、前記第２の記憶手段に記憶されたメールに書き込まれた受信済み回数情報をカウントアップすることを特徴とする請求項１乃至５のいずれか１項に記載のメールシステム。
7. 前記受信手段は、既に受信済みのメールは受信しないことを特徴とする請求項１乃至６のいずれか１項に記載のメールシステム。
8. 複数の情報処理装置によりメールを受信可能な回数を示す受信数を記憶する第１の記憶手段を備える複数の情報処理装置と、複数の情報処理装置に送信する前記メールを記憶する第２の記憶手段を備えるメールサーバとを含むメールシステムの制御方法であって、
   前記情報処理装置の受信手段が、前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信ステップと、
   前記情報処理装置の削除指示手段が、前記第１の記憶手段に記憶されている受信数に、前記受信ステップで受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示ステップと、
   前記メールサーバの受信済み回数情報更新手段が、前記複数の情報処理装置のうちの一の情報処理装置に前記メールを送信する場合毎に、前記第２の記憶手段に記憶された当該メールの前記受信済み回数情報を更新する受信済み回数情報更新ステップと、
   前記メールサーバの送信手段が、前記情報処理装置に前記受信済み回数情報更新ステップで更新された受信済み回数情報が書き込まれた前記メールを送信する送信ステップと、
   前記メールサーバのメール削除手段が、前記削除指示ステップによるメールの削除指示に応じて前記第２の記憶手段に記憶された当該メールの削除を行うメール削除ステップと
   を備えることを特徴とするメールシステムの制御方法。
9. 複数の情報処理装置によりメールを受信可能な回数を示す受信数を記憶する第１の記憶手段を備える複数の情報処理装置と、複数の情報処理装置に送信する前記メールを記憶する第２の記憶手段を備えるメールサーバとを含むメールシステムの制御方法を実行可能なプログラムであって、
   前記情報処理装置を、
   前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信手段と、
   前記第１の記憶手段に記憶されている受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示手段と
   して機能させ、
   前記メールサーバを、
   前記複数の情報処理装置のうちの一の情報処理装置に前記メールを送信する場合毎に、前記第２の記憶手段に記憶された当該メールの前記受信済み回数情報を更新する受信済み回数情報更新手段と、
   前記受信済み回数情報更新手段で受信済み回数情報が更新された前記メールを前記情報処理装置に送信する送信手段と、
   前記情報処理装置の前記削除指示手段によるメールの削除指示に応じて、前記第２の記憶手段に記憶された当該メールの削除を行うメール削除手段
   として機能させることを特徴とするプログラム。
10. 複数の情報処理装置に送信するメールを記憶する第２の記憶手段を備えるメールサーバと通信可能に接続された情報処理装置であって、
    前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信手段と、
    前記複数の情報処理装置により前記メールを受信可能な回数を示す受信数を記憶する第１の記憶手段と、
    前記第１の記憶手段に記憶されている前記受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示手段と
    を備えることを特徴とする情報処理装置。
11. 複数の情報処理装置に送信するメールを記憶する第２の記憶手段を備えるメールサーバと通信可能に接続された、前記複数の情報処理装置により前記メールを受信可能な回数を示す受信数を記憶する第１の記憶手段を備える情報処理装置の制御方法であって、
    前記情報処理装置の受信手段が、前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信ステップと、
    前記情報処理装置の削除指示手段が、前記第１の記憶手段に記憶されている受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示ステップと
    を備えることを特徴とする情報処理装置の制御方法。
12. 複数の情報処理装置に送信するメールを記憶する第２の記憶手段を備えるメールサーバと通信可能に接続された、前記複数の情報処理装置により前記メールを受信可能な回数を示す受信数を記憶する第１の記憶手段を備える情報処理装置の制御方法を実行可能なプログラムであって、
    前記情報処理装置を、
    前記メールサーバから送信されるメールであって、当該メールの受信された回数を示す受信済み回数情報の書き込まれたメールを受信する受信手段と、
    前記第１の記憶手段に記憶されている前記受信数に、前記受信手段で受信した前記メールに書き込まれた前記受信済み回数情報の回数が達している場合に、前記メールサーバに対して当該メールの削除指示を行う削除指示手段
    として機能させることを特徴とするプログラム。
    

Images