(57)【要約】【課題】ユーザの手間を軽減しつつ、メールサーバの容量を圧迫しないように複数台のクライアント装置でメールを受信すること。【解決手段】メールサーバ１０２は、クライアント装置１０１からメールの取得要求を受信すると、メールヘッダーに記載された受信回数（Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ）をインクリメントし、クライアント装置１０１に送信する。クライアント装置１０１はメールを受信すると当該メールの削除要求をメールサーバ１０２に送信する。メールサーバ１０２は、削除要求のあったメールのメールヘッダーに記載された受信回数が、予め設定された受信台数７０１以上であるメールについてはメールサーバ１０２に対して削除を実行するが、そうでない場合には削除を実行しない。【選択図】図１３
2014096791.tif 000002
【特許請求の範囲】
【請求項１】
メールサーバと電子メールの送受信を行う情報処理装置と、前記情報処理装置から送信された電子メールを蓄積するメールサーバとを含むメールシステムであって、
前記情報処理装置は、
前記メールサーバに対して電子メールの取得要求を送信する取得要求送信手段と、
前記取得要求送信手段で送信した電子メールの取得要求に応じて、前記メールサーバから送信された電子メールを受信する受信手段と、
前記受信手段で受信した電子メールの削除要求を前記メールサーバに送信する削除要求送信手段とを備え、
前記メールサーバは、
電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段と、
前記取得要求送信手段で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信手段と、
前記削除要求送信手段で送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定手段と、
前記削除判定手段で削除すると判定された場合には、前記削除要求送信手段で送信された削除要求に応じて電子メールを前記記憶手段から削除する削除手段と
を備えることを特徴とするメールシステム。
【請求項２】
前記メールサーバは、
前記取得要求送信手段で送信された電子メールの取得要求を受信すると、前記記憶手段に記憶された受信済み台数情報を更新する更新手段を更に備えることを特徴とする請求項１に記載のメールシステム。
【請求項３】
前記更新手段は、前記取得要求送信手段で送信された電子メールの取得要求を受信すると、当該電子メールに関する受信済み台数情報が存在しない場合には、当該電子メールに関する受信済み台数情報を生成し、当該電子メールに関する受信済み台数情報が存在する場合には、前記記憶手段に記憶された、当該電子メールに関する受信済み台数情報を更新することを特徴とする請求項２に記載のメールシステム。
【請求項４】
前記更新手段は、当該電子メールに関する受信済み情報が存在しない場合には、当該電子メールに関する受信済み台数情報を生成して値に１を設定し、当該電子メールに関する受信済み台数情報が存在する場合には、前記記憶手段に記憶された、当該電子メールに関する受信済み台数情報をインクリメントすることを特徴とする請求項２または３に記載のメールシステム。
【請求項５】
前記削除判定手段は、前記削除要求送信手段で送信された電子メールの削除要求に応じて、前記記憶手段に記憶された受信済み台数情報が前記設定台数情報以上である場合に削除すると判定することを特徴とする請求項４に記載のメールシステム。
【請求項６】
前記更新手段は、当該電子メールに関する受信済み情報が存在しない場合には、当該電子メールに関する受信済み台数情報を生成して、値に設定台数情報の値を設定し、当該電子メールに関する受信済み台数情報が存在する場合には、前記記憶手段に記憶された、当該電子メールに関する受信済み台数情報をデクリメントすることを特徴とする請求項２または３に記載のメールシステム。
【請求項７】
前記削除判定手段は、前記削除要求送信手段で送信された電子メールの削除要求に応じて、前記記憶手段に記憶された受信済み台数情報が０以下である場合に削除すると判定することを特徴とする請求項６に記載のメールシステム。
【請求項８】
前記受信手段は、既に受信済みの電子メールは受信しないことを特徴とする請求項１乃至７のいずれか１項に記載のメールシステム。
【請求項９】
前記受信済み情報は、当該受信済み情報に関する電子メールに含まれる情報であることを特徴とする請求項１乃至８のいずれか１項に記載のメールシステム。
【請求項１０】
電子メールの送受信を行う情報処理装置と通信可能に接続されたメールサーバであって、
電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段と、
前記情報処理装置で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信手段と、
前記情報処理装置から送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定手段と、
前記削除判定手段で削除すると判定された場合には、前記情報処理装置から送信された削除要求に応じて電子メールを前記記憶手段から削除する削除手段と
を備えることを特徴とするメールサーバ。
【請求項１１】
メールサーバと電子メールの送受信を行う情報処理装置と、電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段を備え、前記情報処理装置から送信された電子メールを蓄積するメールサーバとを含むメールシステムの制御方法であって、
前記情報処理装置の取得要求送信手段が、前記メールサーバに対して電子メールの取得要求を送信する取得要求送信ステップと、
前記メールサーバの送信手段が、前記取得要求送信ステップで送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信ステップと、
前記情報処理装置の受信手段が、前記取得要求送信ステップで送信した電子メールの取得要求に応じて、前記メールサーバから送信された電子メールを受信する受信ステップと、
前記情報処理装置の削除要求送信手段が、前記受信ステップで受信した電子メールの削除要求を前記メールサーバに送信する削除要求送信ステップと、
前記メールサーバの削除判定手段が、前記削除要求送信ステップで送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定ステップと、
前記メールサーバの削除手段が、前記削除判定ステップで削除すると判定された場合には、前記削除要求送信ステップで送信された削除要求に応じて電子メールを前記記憶手段から削除する削除ステップと
を備えることを特徴とするメールシステムの制御方法。
【請求項１２】
電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段を備え、電子メールの送受信を行う情報処理装置と通信可能に接続されたメールサーバであって、
前記メールサーバの送信手段が、前記情報処理装置で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信ステップと、
前記メールサーバの削除判定手段が、前記情報処理装置から送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定ステップと、
前記メールサーバの削除手段が、前記削除判定ステップで削除すると判定された場合には、前記情報処理装置から送信された削除要求に応じて電子メールを前記記憶手段から削除する削除ステップと
を備えることを特徴とするメールサーバの制御方法。
【請求項１３】
メールサーバと電子メールの送受信を行う情報処理装置と、電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段を備え、前記情報処理装置から送信された電子メールを蓄積するメールサーバとを含むメールシステムの制御方法をコンピュータに実行させるためのコンピュータに読み取り実行可能なプログラムであって、
前記情報処理装置を、
前記メールサーバに対して電子メールの取得要求を送信する取得要求送信手段と、
前記取得要求送信手段で送信した電子メールの取得要求に応じて、前記メールサーバから送信された電子メールを受信する受信手段と、
前記受信手段で受信した電子メールの削除要求を前記メールサーバに送信する削除要求送信手段として機能させ、
前記メールサーバを、
前記取得要求送信手段で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信手段と、
前記削除要求送信手段で送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定手段と、
前記削除判定手段で削除すると判定された場合には、前記削除要求送信手段で送信された削除要求に応じて電子メールを前記記憶手段から削除する削除手段
として機能させることを特徴とするコンピュータに読み取り実行可能なプログラム。
【請求項１４】
電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段を備え、電子メールの送受信を行う情報処理装置と通信可能に接続されたメールサーバであって、
前記メールサーバを、
前記情報処理装置で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信手段と、
前記情報処理装置から送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定手段と、
前記削除判定手段で削除すると判定された場合には、前記情報処理装置から送信された削除要求に応じて電子メールを前記記憶手段から削除する削除手段
として機能させることを特徴とするコンピュータに読み取り実行可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールの管理に関し、特に複数台のクライアント装置で電子メールを受信する場合であっても、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫することなく管理することの可能なメールシステム、その制御方法、及びプログラム、並びにメールサーバ、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、ユーザがクライアント装置（情報処理装置）にインストールされたメーラーを利用して電子メール（以下、メール）を送受信することで、ユーザ間の情報の伝達を行っている。このようなメールシステムの仕組みとしては、以下のようなものが一般的である。まず、クライアント装置から送信されたメールはメールサーバに蓄積される。クライアント装置は、メールサーバにメールの取得要求を行うと、メールサーバは蓄積されたメールをクライアント装置に送信する。そして、クライアント装置はメールの受信が完了すると、受信したメールの削除要求をメールサーバに送信し、メールサーバはこれを受けてメールの削除を行う。このような仕組みにすることで、メールサーバに大量のメールが蓄積されないようにしている。
【０００３】
しかし、メールサーバに蓄積されたメールを複数台のクライアント装置で受信したい場合には上記の仕組みでは問題が発生する。例えば、１台目のクライアント装置でメールを受信した場合、当該クライアント装置がメールサーバに対して削除要求を行ってしまうので、２台目以降のクライアント装置はメールを受信できなくなってしまう。つまり、最初にメールを受信したクライアント装置にのみ当該メールが保存されるので、複数台のクライアント装置で同じメールを閲覧することができない。
【０００４】
このような問題を解決するために、クライアント装置からメールサーバに対して削除要求を送らないようにする仕組みが考えられる。しかしながら、クライアント装置からメールサーバに対して削除要求がなされないと、メールサーバにメールが蓄積され続けるので、メールサーバの容量を圧迫してしまう。よって、このような仕組みを採用する場合には、ユーザが使用するすべてのクライアント装置で受信が完了したら、ユーザが手作業でメールサーバ上のメールを削除していた。
【０００５】
この問題を解決するために、下記の特許文献１には、どの電子メール端末がどの電子メールを受信したのかを含むログ情報を元にした電子メールを自分宛てに送信し、当該電子メールを受信したら、当該電子メールに含まれるログ情報に基づいてすべての電子メール端末で当該電子メールを受信しているか否か判定し、受信していれば当該電子メールの削除要求をメールサーバに送信する仕組みが開示されている。
【０００６】
また、下記の特許文献２には、メール管理装置でメール配信先の端末ごとにメールの未読・既読状態を示す情報を記憶管理しており、メール管理装置が端末からメールの配信要求を受信すると、配信要求のあった端末のメールの未読状態を既読状態に変更し、すべての端末の未読・既読状態を示す情報が既読状態となった場合に、当該メールをメール管理装置から削除する仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−２６２６８号公報
【特許文献２】特開２００４−４８３９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記の特許文献１では、ログ情報に基づいてすべての電子メール端末で電子メールを受信したかどうかを判定できるような専用のメーラーが必要になる。企業などでは、多くの社員がメーラーを利用するため、あらかじめ用意されたメーラーを採用することが多い。このような専用のメーラーを用意するためには開発費用がかかる上、管理が煩雑になってしまう問題がある。
【０００９】
また、上記の特許文献１や特許文献２では、メールを受信するクライアント装置を識別可能な情報（ＩＰアドレスやＭＡＣアドレス等）をあらかじめ登録しておく必要が生じる。上記の特許文献１では、使用するクライアント装置ごとにこのような識別情報を登録しておく必要があるし、上記の特許文献２では、メールサーバにクライアント装置の識別情報を登録しておかなければならない。このような情報を調べて登録するためには、ユーザが自分で調べて登録する必要があり非常に手間であるし、ユーザがクライアント装置の識別情報を調べるスキルが必要となってしまう。
【００１０】
また、クライアント装置が増えたり減ったりした場合には、都度登録し直さなくてはならないため、ユーザにとっては非常に管理しにくいものであった。
【００１１】
そこで本発明は、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫しないように複数台の情報処理装置でメールを受信することの可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明のメールシステムは、メールサーバと電子メールの送受信を行う情報処理装置と、前記情報処理装置から送信された電子メールを蓄積するメールサーバとを含むメールシステムであって、前記情報処理装置は、前記メールサーバに対して電子メールの取得要求を送信する取得要求送信手段と、前記取得要求送信手段で送信した電子メールの取得要求に応じて、前記メールサーバから送信された電子メールを受信する受信手段と、前記受信手段で受信した電子メールの削除要求を前記メールサーバに送信する削除要求送信手段とを備え、前記メールサーバは、電子メールと、電子メールを受信すべき情報処理装置の台数を示す設定台数情報と、電子メールが情報処理装置で受信された回数を示す受信済み台数情報とを記憶する記憶手段と、前記取得要求送信手段で送信された電子メールの取得要求に応じて、取得要求のあった電子メールを前記記憶手段から取得し、前記情報処理装置に送信する送信手段と、前記削除要求送信手段で送信された電子メールの削除要求に応じて、前記記憶手段に記憶された設定台数情報と受信済み台数情報とに基づいて、当該電子メールを前記記憶手段から削除するか否かを判定する削除判定手段と、前記削除判定手段で削除すると判定された場合には、前記削除要求送信手段で送信された削除要求に応じて電子メールを前記記憶手段から削除する削除手段とを備えることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ユーザがメールを受信したい情報処理装置の台数をメールサーバに設定しておくだけで、メールサーバが当該受信台数に達したメールのみ削除してくれるので、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫しないように複数台の情報処理装置でメールを受信することのできる効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態におけるメールシステム１００の一例を示す構成図である。
【図２】図１に示すクライアント装置１０１及びメールサーバ１０２のハードウェア構成の一例を示す構成図である。
【図３】図１に示すクライアント装置１０１及びメールサーバ１０２のモジュール構成の一例を示す構成図である。
【図４】本発明の実施形態における一連の処理の流れを示すフローチャートである。
【図５】図４の設定変更処理の詳細を示すフローチャートである。
【図６】Ｗｅｂメールログイン画面６００、設定変更画面６１０の一例を示す構成図である。
【図７】メールサーバ１０２に記憶されたユーザ認証テーブル７１０の構成の一例を示す構成図である。
【図８】本発明の実施形態における一連の処理の流れを示すフローチャートである。
【図９】図８に示すメール受信処理の詳細を示すフローチャートである。
【図１０】図９のメール受信処理の続きのフローチャートである。
【図１１】Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのないメールにＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔを付与した場合のメールヘッダーの一例を示す模式図である。
【図１２】Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのあるメールでＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔの値をインクリメントした場合のメールヘッダーの一例を示す模式図である。
【図１３】本発明の一連の処理の流れを示す模式図である。
【図１４】図８に示すメール受信処理の第２の実施例の詳細を示すフローチャートである。
【図１５】第２の実施例における、Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのないメールにＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔを付与した場合のメールヘッダーの一例を示す模式図である。
【図１６】第２の実施例における、Ｒｅｃｅｉｖｉｎｇ−ＣｏｕｎｔのあるメールでＲｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔの値をデクリメントした場合のメールヘッダーの一例を示す模式図である。
【図１７】本発明の第２の実施例における一連の処理の流れを示す模式図である。
【図１８】本発明の第３の実施例におけるメールシステム１００の一例を示す構成図である。
【図１９】第３の実施例における、受信台数を登録する処理を示すフローチャートである。
【図２０】第３の実施例における、設定変更画面２０００の一例を示す構成図である。
【図２１】図８に示すメール受信処理の第３の実施例の詳細を示すフローチャートである。
【図２２】図２１のメール受信処理の続きのフローチャートである。
【図２３】図８に示すメール受信処理の第４の実施例の詳細を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、図面を参照して、本発明の実施の形態の一例について説明する。
【００１６】
図１は、本発明のメールシステム１００のシステム構成の一例を示す図である。本発明のメールシステム１００は、クライアント装置１０１（クライアント装置１０１ａ、クライアント装置１０１ｂ、クライアント装置１０１ｃ）、メールサーバ１０２が設置されており、それら装置はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０３を介して相互にデータ通信可能に接続されている。図１のネットワーク１０３上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００１７】
クライアント装置１０１（情報処理装置）は、メールサーバ１０２と通信し、メーラーを通じて電子メール（以下、メール）の送受信を行う装置である。メーラーは後述する図２のＲＯＭ２０２または外部メモリ２１１に記憶されており、ユーザからの指示に応じて、ＣＰＵ２０１がＲＡＭ２０３に読み出して各種動作を行う。
【００１８】
メーラーは、ユーザからの操作に応じて、メールの作成、送受信、表示等を行う。本実施形態では、クライアント装置１０１ａ、クライアント装置１０１ｂ、クライアント装置１０１ｃはそれぞれ１人のユーザが使用するクライアント装置１０１であるので、メーラーに設定されたユーザのアカウント（ユーザＩＤ、パスワード等）は同じアカウントが設定されているものとして説明を行う。尚、メールはメールサーバ１０２の外部メモリ２１１に記憶されていても、クライアント装置１０１の外部メモリ２１１に記憶されていてもよい。本実施形態では、クライアント装置１０１の外部メモリ２１１に記憶されているものとして、以下説明を行う。
【００１９】
また、クライアント装置１０１は、Ｗｅｂブラウザを備えており、Ｗｅｂブラウザを通じてメールサーバ１０２にアクセスし、受信ボックスに格納されたメールを閲覧することができる。つまり、従来のＷｅｂメールの仕組みである。ユーザのアカウントを用いてメールサーバ１０２にログインすると、当該アカウントに紐づくメールがＷｅｂブラウザで表示できる。
【００２０】
メールサーバ１０２は、クライアント装置１０１から送信されたメールを宛先ごとに記憶管理し、クライアント装置１０１からの要求に応じてメールを送信する装置である。クライアント装置１０１との通信では、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ）といったプロトコルを用いて送受信を行う。通信プロトコルについては、これに限らない。クライアント装置１０１とメールサーバ１０２の間でメールの送受信ができればよい。
【００２１】
また、メールサーバ１０２は、クライアント装置１０１のＷｅｂブラウザからアクセスされることで、Ｗｅｂメールとしてメールを表示することができる。クライアント装置１０１からＳＭＴＰによって送信されたメールをアカウントごとに記憶しておき、クライアント装置１０１のＷｅｂブラウザでメールサーバ１０２にアクセスされると、記憶されたメールをアカウントごとに表示する仕組みである。つまり、ＳＭＴＰ環境とＷｅｂメール環境が併存することになる。Ｗｅｂメールの仕組みやＳＭＴＰ環境とＷｅｂメール環境が併存するための仕組みについては、従来技術であるので説明を省略する。
【００２２】
尚、クライアント装置１０１が、メールサーバ１０２の構成を含んでもよいし、メールサーバ１０２がクライアント装置１０１の構成を含んでもよい。
【００２３】
図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。
【００２４】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２５】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ)やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２６】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２７】
また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。
【００２８】
ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。
【００２９】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピーディスク（登録商標  ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３０】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００３１】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３２】
本発明のクライアント装置１０１、メールサーバ１０２が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。
【００３３】
次に、クライアント装置１０１及びメールサーバ１０２のモジュール構成を示す機能構成図について、図３を用いて説明する。尚、図３の各種端末あるいはサーバのモジュール構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００３４】
クライアント装置１０１は、記憶モジュール３０１、画面表示モジュール３０２、テーブル管理モジュール３０３、メール送受信モジュール３０４、メール削除要求モジュール３０５、Ｗｅｂブラウザモジュール３０６を備える。
【００３５】
記憶モジュール３０１は、メーラーによって作成及び送受信されたメールを記憶するモジュールである。記憶モジュール３０１によって記憶されたメールは、クライアント装置１０１の外部メモリ２１１等に記憶され、必要に応じて、記憶モジュール３０１によって読みだされる。
【００３６】
画面表示モジュール３０２は、メールや画面といった各種情報をクライアント装置１０１のＣＲＴ２１０に表示させるためのモジュールである。特に本実施形態では、図６に示すＷｅｂメールログイン画面６００や、設定変更画面６１０等を表示し、ユーザからの入力及び操作を受け付ける。
【００３７】
テーブル管理モジュール３０３は、後述する図７のユーザ認証テーブル７１０の記憶や更新等を行うためのモジュールである。各種テーブルは、外部メモリ２１１に記憶され、必要に応じてＲＡＭ２０３に読み出す。
【００３８】
メール送受信モジュール３０４は、クライアント装置１０１で生成されたメールをメールサーバ１０２に送信したり、メールサーバ１０２に蓄積されたメールを受信したりするためのモジュールである。メール以外の情報が送信できてもよい。
【００３９】
メール削除要求モジュール３０５は、メールサーバ１０２から受信したメールの削除要求をメールサーバ１０２に対して送信するためのモジュールである。
【００４０】
Ｗｅｂブラウザモジュール３０６は、メールサーバ１０２に備えるＷｅｂメールモジュール３１８と通信し、メールサーバ１０２に記憶されたメールをＷｅｂブラウザ経由でＷｅｂメールとして閲覧するためのモジュールである。
【００４１】
メールサーバ１０２は、記憶モジュール３１１、メールボックス管理モジュール３１２、ユーザ認証モジュール３１３、メール送受信モジュール３１４、メール削除モジュール３１５、メールヘッダー更新モジュール３１６、メール削除判定モジュール３１７、Ｗｅｂメールモジュール３１８を備える。
【００４２】
記憶モジュール３１１（記憶手段）は、前述したクライアント装置１０１の記憶モジュール３０１と同様である。後述するメール送受信モジュール３１４によって受信したメールや、メールヘッダー更新モジュール３１６で更新されたメール等を記憶する。また、メールを受信したいクライアント装置１０１の台数を示す情報が記憶されている。
【００４３】
メールボックス管理モジュール３１２は、記憶モジュール３１１で記憶されたメールをアカウントごとに記憶管理するためのモジュールである。後述するメール送受信モジュール３１４によってメールの受信要求を受け付けた場合には、メールの取得を行うアカウントを特定し、そのアカウントのメールボックスからメールを取得して、メール送受信モジュール３１４に渡す。
【００４４】
ユーザ認証モジュール３１３は、クライアント装置１０１から送信されたユーザＩＤとパスワードに基づいて、メールシステム１００の利用者であるか否かを認証するためのモジュールである。
【００４５】
メール送受信モジュール３１４は、クライアント装置１０１とメールの送受信を行うためのモジュールである。
【００４６】
メール削除モジュール３１５は、クライアント装置１０１のメール削除要求モジュール３０５からメールの削除要求があった場合に、後述するメール削除判定モジュール３１７で削除すると判定されたメールを、削除するモジュールである。
【００４７】
メールヘッダー更新モジュール３１６は、クライアント装置１０１からメールの取得要求に応じて、メールを送信する場合に、送信するメールのメールヘッダーを更新するためのモジュールである。メールヘッダーには、クライアント装置１０１に送信した回数、つまり受信したクライアント装置１０１の台数を示す情報が含まれており、それらをメール送信の際に追加、またはインクリメントする。また、別の実施形態として、メールヘッダーには、クライアント装置１０１に送信すべき残り回数を示す情報が含まれており、それらをメール送信の際に追加、またはデクリメントする。
【００４８】
メール削除判定モジュール３１７は、クライアント装置１０１のメール削除要求モジュール３０５から送信されたメールの削除要求を受け付けると、記憶モジュール３１１に記憶された受信台数と、クライアント装置１０１に送信した回数とに基づいて、削除するか否かを判定するモジュールである。メールヘッダーにクライアント装置１０１に送信すべき残り回数が設定されているのであれば、残り回数がなくなったか否かに応じて削除するか否かを判定すればよい。
【００４９】
Ｗｅｂメールモジュール３１８では、クライアント装置１０１のＷｅｂブラウザモジュール３０６からの要求に応じて、メールボックス管理モジュール３１２からメールを取得して、Ｗｅｂブラウザに表示可能な画面を生成してＷｅｂブラウザモジュール３０６に送信するモジュールである。つまり、Ｗｅｂメールを実現するためのモジュールである。
【００５０】
次に、本発明の実施形態におけるクライアント装置１０１によって行われる一連の処理について、図４に示すフローチャートを用いて説明する。尚、ステップＳ４０１、ステップＳ４０２、ステップＳ４０６、ステップＳ４１０乃至ステップＳ４１５、ステップＳ４１９、ステップＳ４２０の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ４０３乃至ステップＳ４０９、ステップＳ４１６乃至ステップＳ４１８の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００５１】
また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００５２】
図４に示す処理は、メールサーバ１０２にログインし、Ｗｅｂメールを表示して、ユーザがメールを受信したいクライアント装置１０１の台数を変更するための処理である。本実施形態では、Ｗｅｂメールを表示する画面上で受信台数を変更するような仕組みとして説明するが、これに限らない。管理者が受信台数を変更してもよいし、クライアント装置１０１のメーラーを通じてメールサーバ１０２にアクセスし、変更できるような仕組みでもよい。
【００５３】
ステップＳ４０１では、クライアント装置１０１は、クライアント装置１０１に備えられたＷｅｂブラウザを起動し、所定のＵＲＬにアクセスし、図６に示すようなＷｅｂメールログイン画面６００をＣＲＴ２１０に表示させる。クライアント装置１０１の外部メモリ２１１にＷｅｂメールログイン画面６００を保存しておき、ユーザからの指示に応じて表示させるような仕組みでもよい。そして、ユーザからの入力を受け付ける。具体的には、Ｗｅｂメールログイン画面６００に備えられたユーザＩＤ入力欄６０１、パスワード入力欄６０２に対する入力を受け付け、入力された後にＯＫボタン６０３が押下されたらステップＳ４０６に処理を進める。
【００５４】
ステップＳ４０２では、クライアント装置１０１は、ステップＳ４０１で入力を受け付けたユーザＩＤとパスワードを取得し、メールサーバ１０２に送信する。
【００５５】
ステップＳ４０３では、メールサーバ１０２は、ステップＳ４０２で送信されたユーザＩＤとパスワードを受信する。そして、ステップＳ４０４では、受信したユーザＩＤとパスワードを用いてユーザ認証を行う。具体的には、メールサーバ１０２に記憶されたユーザ認証テーブル７１０を参照して、受信したユーザＩＤとパスワードの組に一致するユーザＩＤ７１１とパスワード７１２が存在するか否かによって判定すればよい。
【００５６】
ユーザ認証テーブル７１０（図７参照）は、ユーザＩＤ７１１、パスワード７１２、受信台数７１３（設定台数情報）から構成される。ユーザＩＤ７１１は、ユーザごとに識別可能な情報である。本実施形態においては、ユーザのメールアドレスをユーザＩＤとして格納する。パスワード７１２は、ユーザ認証に必要なパスワードである。ユーザＩＤ７１１とパスワード７１２はあらかじめ管理者やユーザから登録されているものとする。受信台数７１３は、ユーザＩＤ７１１が示すユーザがメールを受信したいクライアント装置１０１の台数を示す値である。
【００５７】
ステップＳ４０５では、メールサーバ１０２は、ステップＳ４０４で認証された結果、ユーザ認証が成功したか否かを判定する。ユーザ認証が成功したと判定された場合には、ステップＳ４０７に処理を進め、ユーザ認証が失敗したと判定された場合には、クライアント装置１０１にその旨を送信し、ステップＳ４０６に処理を進める。
【００５８】
ステップＳ４０６では、クライアント装置１０１は、ユーザ認証が失敗したため、ユーザに接続エラーの通知を行い、ステップＳ４０１に処理を戻す。
【００５９】
ステップＳ４０７では、メールサーバ１０２は、ステップＳ４０３で受信したユーザＩＤから当該ユーザのメールボックスを特定し、そのメールボックスからメールを取得する。メールサーバ１０２には多数のメールが記憶管理されているが、宛先ごとにメールボックスを作成しておき、要求に応じてそのメールボックスに保存されたメールを出力することができる。ステップＳ４０７ではメール自体を取得しているが、後述するステップＳ４０８で使用する情報だけでよい。例えば、メールの件名や受信日時、送信者といったメールヘッダーである。メールボックスに保存されたメールのメールヘッダーのみを取得して、後述するステップＳ４０８で使用するようにしてもよい。
【００６０】
ステップＳ４０８では、メールサーバ１０２は、ステップＳ４０７で取得したメールに基づいて、Ｗｅｂメール画面（不図示）を生成する。Ｗｅｂメール画面には、メールボックスに保存されたメールの件名が一覧表示されており、件名が選択されると当該メールの本文が閲覧できるようになっている。また、設定変更ボタンが備えられており、この設定変更ボタンが押下されることにより、ユーザの受信台数変更を受け付けることができるようになる。
【００６１】
ステップＳ４０９では、メールサーバ１０２は、ステップＳ４０８で生成されたＷｅｂメール画面をクライアント装置１０１に送信する。
【００６２】
ステップＳ４１０では、クライアント装置１０１は、メールサーバ１０２から送信されたＷｅｂメール画面を表示し、ステップＳ４１１では、表示されたＷｅｂメール画面に対するユーザからの操作を受け付ける。
【００６３】
ステップＳ４１２では、クライアント装置１０１は、Ｗｅｂメール画面に備えられた設定変更ボタン（不図示）が押下されたか否かを判定する。つまり、後述するステップＳ４１３の設定変更処理の実行指示があったか否かを判定することになる。設定変更ボタンが押下されたと判定された場合には、ステップＳ４１３に処理を進め、そうでない場合には、ステップＳ４１４に処理を進める。
【００６４】
ステップＳ４１３では、クライアント装置１０１は、ユーザがメールを受信したいクライアント装置１０１の台数を変更するための処理を実行する。設定変更処理の詳細は、後述する図５に示す。
【００６５】
ステップＳ４１４では、クライアント装置１０１は、ユーザからＷｅｂメール画面に対してＷｅｂメール機能の終了指示があったか否かを判定する。具体的には、Ｗｅｂブラウザの閉じるボタン（不図示）が押下されたか否かを判定してもよいし、ログアウトボタン（不図示）が押下されたか否かを判定してもよい。終了指示があったと判定された場合には、ステップＳ４１５に処理を進め、そうでない場合には、ステップＳ４１１に処理を戻す。
【００６６】
ステップＳ４１５では、クライアント装置１０１は、ユーザから終了指示を受け付けたので、Ｗｅｂメールのログアウト要求をメールサーバ１０２に対して送信する。ログアウト要求と共にユーザのアカウントを送信するようにすればよい。
【００６７】
ステップＳ４１６では、メールサーバ１０２は、クライアント装置１０１からのログアウト要求を受信し、ステップＳ４１７では、ログアウト要求のあったアカウントのログアウトを実行する。ステップＳ４１８では、メールサーバ１０２は、ログアウトの実行結果をクライアント装置１０１に送信する。
【００６８】
ステップＳ４１９では、クライアント装置１０１は、メールサーバ１０２から送信されたログアウトの実行結果を受信し、ステップＳ４２０では、受信したログアウトの実行結果に基づいて、ユーザにログアウト結果を通知する。
【００６９】
次に、本発明の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われる設定変更処理について図５を用いて説明する。尚、ステップＳ５０１、ステップＳ５０５乃至ステップＳ５０９、ステップＳ５１３、ステップＳ５１４の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ５０２乃至ステップＳ５０４、ステップＳ５１０乃至ステップＳ５１２の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００７０】
また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００７１】
設定変更処理は、ユーザが受信したいクライアント装置１０１の台数を設定するための処理である。後述するメール受信処理ですべてのクライアント装置１０１で受信がなされたか否かを判定する際に、設定変更処理で設定された受信台数を使用する。
【００７２】
まず、ステップＳ５０１では、クライアント装置１０１は、メールサーバ１０２に対して設定変更を行うための画面の取得要求を送信する。
【００７３】
ステップＳ５０２では、メールサーバ１０２は、クライアント装置１０１から送信された設定変更画面の取得要求を受信し、ステップＳ５０３では、図６の設定変更画面６１０に示すような画面を生成する。設定変更画面６１０はメールサーバ１０２の外部メモリ２１１にあらかじめ記憶されていてもよい。ステップＳ５０４では、メールサーバ１０２は、生成された設定変更画面６１０をクライアント装置１０１に送信する。
【００７４】
ステップＳ５０５では、クライアント装置１０１は、メールサーバ１０２から送信された設定変更画面６１０を受信し、ステップＳ５０６では、受信した設定変更画面６１０をＣＲＴ２１０に表示する。そして、ステップＳ５０７では、クライアント装置１０１は、表示した設定変更画面６１０に対してユーザから操作を受け付ける。具体的には、設定変更画面６１０に備えられた受信台数入力欄６１１やＯＫボタン６１２に対する入力を受け付けることになる。
【００７５】
ステップＳ５０８では、クライアント装置１０１は、受信台数入力欄６１１に対する入力がなされ、ＯＫボタン６１２が押下されたか否かを判定する。ＯＫボタンが押下されたと判定された場合には、ステップＳ５０９に処理を進め、そうでない場合には、ＯＫボタン６１２が押下されるまで待機する。
【００７６】
ステップＳ５０９では、クライアント装置１０１は、受信台数入力欄６１１に入力された新たな受信台数の値をメールサーバ１０２に送信する。合わせて、ユーザのユーザＩＤ７１１も送信する。
【００７７】
ステップＳ５１０では、メールサーバ１０２は、クライアント装置１０１から送信された受信台数の値を受信し、ステップＳ５１１では、受信した受信台数の値をユーザ認証テーブル７１０に登録する。具体的には、受信したユーザＩＤから対応するユーザＩＤ７１１を検索し、ヒットしたユーザＩＤ７１１に対応する受信台数７１３に受信した値を格納すればよい。例えば、ユーザＩＤが「ａａａａａ＠ｘｘｘｘｘ．ｃｏ．ｊｐ」で受信台数が「３」だった場合には、ユーザ認証テーブル７１０の１レコード目の受信台数７１３に「３」を格納することになる。このようにして、ユーザごとに受信台数の設定を行うことができる。ここで設定された受信台数に応じて、後述するメール受信処理で必要な台数分受信できたか否かを判定することになる。
【００７８】
ステップＳ５１２では、メールサーバ１０２は、受信台数の登録の実行結果をクライアント装置１０１に送信する。
【００７９】
ステップＳ５１３では、クライアント装置１０１は、受信台数登録の実行結果を受信し、ステップＳ５１４では、その実行結果をユーザに通知する。
【００８０】
次に、本発明の実施形態におけるクライアント装置１０１によって行われる一連の処理について、図８に示すフローチャートを用いて説明する。尚、ステップＳ８０１乃至８０６の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【００８１】
また、この処理をクライアント装置１０１に実行させるためのプログラムは、クライアント装置１０１にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００８２】
まず、ステップＳ８０１では、クライアント装置１０１は、クライアント装置１０１の外部メモリ２１１に記憶されたメーラーのプログラムを起動する。そして、ステップＳ８０２では、クライアント装置１０１は、メーラーに対してユーザからの操作を受け付ける。
【００８３】
ステップＳ８０３では、クライアント装置１０１は、ステップＳ１０２で受け付けた操作がメールの受信指示であるか否かを判定する。例えば、メーラーのメニューからメール受信ボタン（不図示）が押下されたか否かを判定すればよい。メール受信指示であった場合には、ステップＳ８０４に処理を進め、そうでない場合には、ステップＳ８０５に処理を進める。
【００８４】
ステップＳ８０４では、クライアント装置１０１は、メールサーバ１０２に蓄積されたメールを受信する処理を実行する。メール受信処理の詳細は、後述する図９乃至図１０に示す。処理が終了したら、ステップＳ８０２に処理を戻す。
【００８５】
ステップＳ８０５では、クライアント装置１０１は、ステップＳ１０２で受け付けた操作がメーラーの終了指示であるか否かを判定する。例えば、メーラーのメニューから終了ボタン（不図示）が押下されたか否かを判定すればよい。終了指示であった場合には、ステップＳ８０６に処理を進め、そうでない場合には、ステップＳ８０２に処理を戻す。
【００８６】
ステップＳ８０６では、クライアント装置１０１は、メーラーの終了指示を受け付けたのでメーラーを終了し、本一連の処理を終了する。
【００８７】
次に、本発明の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われるメール受信処理について図９及び図１０を用いて説明する。尚、ステップＳ９０１、ステップＳ９０５乃至ステップＳ９０８、ステップＳ９１２乃至ステップＳ９１７、ステップＳ９２４、ステップＳ９２５、ステップＳ９３１、ステップＳ９３２の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ９０２乃至ステップＳ９０４、ステップＳ９０９乃至ステップＳ９１１、ステップＳ９１８乃至ステップＳ９２３、ステップＳ９２６乃至ステップＳ９３０の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００８８】
また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００８９】
メール受信処理は、メールサーバ１０２に蓄積されたメールをクライアント装置１０１に送信し、前述した設定変更処理で設定された受信台数分送信されていれば、受信の完了に応じて発行された削除要求を受け付けて、そうでない場合には削除要求を受け付けない仕組みである。
【００９０】
まず、図１３を参照してメール受信処理の処理概要について説明を行う。まず、前述した設定変更処理でクライアント装置１０１のＷｅｂブラウザを通じてＷｅｂメール上で受信台数７１３が設定される。そして、ユーザからの指示に応じて、クライアント装置１０１がメールサーバ１０２に対してメールの受信要求を送信する。メールサーバは、メールの受信要求を受信すると、メールボックスに蓄積されたメールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」（受信済み台数情報）の値をインクリメントする。ここで、メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」がない場合には、新しく追加する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」は、メールサーバ１０２がメールを送信した回数、つまりクライアント装置１０１でメールを受信した回数を示すメールヘッダーの項目である。尚、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。
【００９１】
「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の更新が完了したら、メールの受信要求が来たクライアント装置１０１に対して当該メールを送信する。クライアント装置１０１は、メールの受信が完了すると、メールサーバ１０２に対して受信したメールの削除要求を送信する。これは従来のメーラーの動きと同様である。そして、メールサーバ１０２は削除要求のあったメールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」値を参照し、当該「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が受信台数７１３以上となっている場合には、その削除要求を受け付けて、当該メールの削除を実行する。一方、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が受信台数７１３未満である場合には、削除要求を無視する。こうすることで、設定された受信台数分の送信が完了していれば、メールサーバ１０２がクライアント装置１０１からの削除要求を受け付けて当該メールの削除を実行し、そうでなければ削除要求を無視することができるので、ユーザは受信台数７１３をメールサーバ１０２に設定するだけで、メールサーバの容量を圧迫せずに、必要な台数分メールを受信することができる。以下、この詳細な説明を行う。
【００９２】
まず、ステップＳ９０１では、クライアント装置１０１は、ユーザ認証を行うべく、メーラーにあらかじめ設定されたユーザＩＤとパスワードをメールサーバ１０２に送信する。ユーザＩＤとパスワードは受信を行う度にユーザからの入力を受け付けて、入力されたユーザＩＤとパスワードをメールサーバ１０２に送信するようにしてもよい。
【００９３】
ステップＳ９０２では、メールサーバ１０２は、クライアント装置１０１から送信されたユーザＩＤとパスワードを受信し、ステップＳ９０３では、受信したユーザＩＤとパスワードと、メールサーバ１０２の外部メモリ２１１に記憶されたユーザ認証テーブル７１０に基づいてユーザ認証を行う。受信したユーザＩＤとパスワードの組み合わせがユーザ認証テーブル７１０のユーザＩＤ７１１とパスワード７１２の組み合わせに存在すれば、認証ＯＫとなるが、そうでなければ認証ＮＧとなる。
【００９４】
ステップＳ９０４では、メールサーバ１０２は、ステップＳ９０３で認証された結果をクライアント装置１０１に返信する。
【００９５】
ステップＳ９０５では、クライアント装置１０１は、メールサーバ１０２から送信されたユーザ認証の結果を受信する。そして、ステップＳ９０６では、クライアント装置１０１は、その受信結果が認証ＯＫであったか否かを判定する。認証ＯＫであった場合には、ステップＳ９０８に処理を進め、認証ＮＧであった場合には、ステップＳ９０７に処理を進める。
【００９６】
ステップＳ９０７では、クライアント装置１０１は、認証ＮＧであったため接続エラーをユーザに通知して、メール受信処理を終了し、呼び出し元に処理を戻す。
【００９７】
ステップＳ９０８では、クライアント装置１０１は、メールサーバ１０２のメールボックスに蓄積されたすべてのメールのメールヘッダーの取得をメールサーバ１０２に対して要求する。後述するステップＳ９１３及びステップＳ９１４で、既に受信済みのメールと新たに受信すべきメールを特定するためにこのような処理を行っている。
【００９８】
ステップＳ９０９では、メールサーバ１０２は、クライアント装置１０１から送信されたすべてのメールのメールヘッダー取得要求を受信する。そして、ステップＳ９１０では、メールサーバ１０２は、ステップＳ９０３で認証されたユーザのメールボックスに蓄積されたすべてのメールからメールヘッダーを取得する。ここでは少なくともメールを一意に特定する識別情報である「Ｍｅｓｓａｇｅ−ｉｄ」を含めて取得するようにする。他にもメールを一意に特定できるような情報があれば、それで代用しても構わない。
【００９９】
ステップＳ９１１では、メールサーバ１０２は、ステップＳ９１０で取得したすべてのメールのメールヘッダーをクライアント装置１０１に送信する。
【０１００】
ステップＳ９１２では、クライアント装置１０１は、メールサーバ１０２から送信されたメールヘッダーを受信し、ステップＳ９１３では、クライアント装置１０１は、受信したメールヘッダーとクライアント装置１０１に受信済みのメールのメールヘッダーとを比較し、新たに受信すべきメールの有無を確認する。具体的には、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールをクライアント装置１０１のメーラーから検索するようにすればよい。受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にあれば、既にそのメールは受信済みであると判定できる。しかし、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にないのであれば、当該「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールは、新たにメールサーバ１０２から受信すべきメールであると判定できる。
【０１０１】
ステップＳ９１４では、クライアント装置１０１は、ステップＳ９１３で確認した結果、新たに受信すべきメールが存在するか否かを判定する。新たに受信すべきメールが存在すると判定された場合には、図１０のステップＳ９１６に処理を進め、新たに受信すべきメールが存在しないと判定された場合には、ステップＳ９１５に処理を進める。
【０１０２】
ステップＳ９１５では、クライアント装置１０１は、新たに受信すべきメールが存在しないので、その旨をユーザに通知する。そして、メール受信処理を終了し、呼び出し元に処理を戻す。
【０１０３】
図９に続き、図１０を用いて説明を行う。ステップＳ９１６では、クライアント装置１０１は、後述するステップＳ９１７乃至ステップＳ９３１の処理を受信するメール数分繰り返す。受信するメール数分のループが完了したら、ループを抜けて、ステップＳ９３２に処理を進める。
【０１０４】
ステップＳ９１７では、クライアント装置１０１は、新たに受信すべきメールの受信要求をメールサーバ１０２に対して送信する（取得要求送信手段）。ここでは、新たに受信すべきメールのうち、１通のメールについての受信要求を送信する。メールの受信順序は問わない。
【０１０５】
ステップＳ９１８では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの受信要求を受信する。そして、ステップＳ９１９では、メールサーバ１０２は、クライアント装置１０１から要求されたメールを当該ユーザのメールボックスから取得する。
【０１０６】
ステップＳ９２０では、メールサーバ１０２は、ステップＳ９１９で取得したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在するか否かを判定する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在する場合には、ステップＳ９２２に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しない場合には、ステップＳ９２１に処理を進める。
【０１０７】
ステップＳ９２１では、メールサーバ１０２は、ステップＳ９１９で取得したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないので、新たにメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、値を「１」に設定する（更新手段）。図１１の送信メールヘッダー１１００に示すように、元々メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないメールについては、メールヘッダー情報１１０１に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を新たに追加し、値に「１」を設定する。ここで「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値を「１」に設定するのは、これからクライアント装置１０１にメールを送信することで、１台の装置で受信がなされるからである。
【０１０８】
一方、ステップＳ９２２では、メールサーバ１０２は、ステップＳ９１９で取得したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントする（更新手段）。図１２の送信メールヘッダー１２００のメールヘッダー情報１２０１に示すように、ステップＳ９１９で取得したメールのメールヘッダーには既に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」として値に「１」が設定されている。つまり、既に１台のクライアント装置１０１に当該メールを送信していることを示している。今回新たにメールを送信するため、この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に更に「１」を加算して、メールヘッダー情報１２０２に示すように値を「２」に変更する。このようにすることで、何台のクライアント装置１０１に送信したのかを記録しておくことができる。尚、前述した通り、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。
【０１０９】
ステップＳ９２３では、メールサーバ１０２は、ステップＳ９１９で取得し、ステップＳ９２１またはステップＳ９２２で「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加または更新を行ったメールをクライアント装置１０１に送信する（送信手段）。
【０１１０】
ステップＳ９２４では、クライアント装置１０１は、メールサーバ１０２から送信されたメールを受信する（受信手段）。
【０１１１】
ステップＳ９２５では、クライアント装置１０１は、ステップＳ９２４においてメールの受信が完了したので、当該メールの削除要求をメールサーバ１０２に送信する（削除要求送信手段）。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。
【０１１２】
ステップＳ９２６では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの削除要求を受信する。
【０１１３】
ステップＳ９２７では、メールサーバ１０２は、受信した削除要求に含まれるユーザＩＤから当該ユーザが設定した受信台数７１３を取得する。具体的には、ユーザ認証テーブル７１０と受信したユーザＩＤからユーザＩＤ７１１を特定し、当該ユーザＩＤ７１１に対応する受信台数７１３を取得するようにすればよい。
【０１１４】
ステップＳ９２８では、メールサーバ１０２は、削除要求がなされたメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が、ステップＳ９２７で取得した受信台数７１３以上であるか否かを判定する（削除判定手段）。つまり、設定された受信台数分のクライアント装置１０１で受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、削除要求を受け付けて当該メールの削除を実行するが、そうでなければ削除要求を無視して、次のメールの処理に移る。このような仕組みでメールサーバ１０２のメールボックスに蓄積されたメールを削除するようにすれば、ユーザは受信台数をメールサーバ１０２に設定するだけで、メールサーバの容量を圧迫することなく、複数台のクライアント装置１０１で同一のメールを受信することができるようになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７１３以上であると判定された場合には、ステップＳ９２９に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７１３以上でないと判定された場合には、ステップＳ９３０に処理を進める。
【０１１５】
ステップＳ９２９では、メールサーバ１０２は、削除要求のなされたメールをメールボックスから削除する（削除手段）。具体的には、ステップＳ９２６で受信した削除要求に含まれる「Ｍｅｓｓａｇｅ−ｉｄ」から当該ユーザのメールボックスにあるメールを特定し、当該メールをメールボックスから削除する。
【０１１６】
ステップＳ９３０では、メールサーバ１０２は、ステップＳ９２６で受信した削除要求に応じた実行結果をクライアント装置１０１に送信する。
【０１１７】
ステップＳ９３１では、クライアント装置１０１は、メールサーバ１０２から送信された実行結果を受信し、必要に応じてＲＡＭ２０３に記憶しておく。受信が完了したら、ステップＳ９１４で受信対象メールと判定されたメールがすべて受信できたか否かを判定し、すべてのメールの受信が完了できたなら、ステップＳ９３２に処理を進め、そうでない場合には、未受信のメールを受信するべく、ステップＳ９１７乃至ステップＳ９３１を繰り返す。
【０１１８】
ステップＳ９３２では、クライアント装置１０１は、ステップＳ９２４で受信したメール一覧をユーザに対して閲覧可能にＣＲＴ２１０に表示させる。表示が完了したら、メール受信処理を終了し、呼び出し元に処理を戻す。ここで、ステップＳ９３１で受信した削除要求に応じた実行結果をユーザに通知する。例えば、「まだ受信していない装置があるので、削除できませんでした。」といったメッセージをユーザに通知することで、ユーザに処理内容を把握させることができる。特に、削除できなかったメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を通知することで、削除できなかったメールを把握させることも可能である。この場合には、ステップＳ９３０で送信される実行結果にメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を含めて、その情報を通知させればよい。
【０１１９】
以上説明したように、本実施形態によれば、ユーザがメールを受信したいクライアント装置の台数をメールサーバに設定しておくだけで、メールサーバが当該受信台数に達したメールのみ削除してくれるので、ユーザの手間を軽減しつつ、メールサーバの容量を圧迫しないように複数台のクライアント装置でメールを受信することのできる効果を奏する。
【０１２０】
次に、本発明の第２の実施形態について説明する。前述した実施形態では、ステップＳ９２２において「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントしていたが、第２の実施形態では、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」に受信台数７１３の値を設定し、送信の度に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントし、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」になったら削除要求を受け付けて削除を実行する。そうでなければ削除要求を無視する。このような仕組みであっても、前述した実施形態と同じ効果を得ることができる。以下、この仕組みについての説明を行う。
【０１２１】
尚、第２の実施形態は、前述した実施形態のメール受信処理におけるステップＳ９１６以降が異なるだけであり、それ以外の部分については同様であるので説明を省略する。
【０１２２】
まず、図１７を参照してメール受信処理の処理概要について説明を行う。まず、前述した設定変更処理でクライアント装置１０１のＷｅｂブラウザを通じてＷｅｂメール上で受信台数７１３が設定される。そして、ユーザからの指示に応じて、クライアント装置１０１がメールサーバ１０２に対してメールの受信要求を送信する。メールサーバは、メールの受信要求を受信すると、メールボックスに蓄積されたメールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントする。ここで、メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」がない場合には、受信台数７１３の値を新しく追加し、デクリメントする。これから送信する分を「−１」することになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」は、メールサーバ１０２がメールを送信する残り回数、つまりクライアント装置１０１でメールを受信する残り回数を示すメールヘッダーの項目である。尚、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。
【０１２３】
「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の更新が完了したら、メールの受信要求が来たクライアント装置１０１に対して当該メールを送信する。クライアント装置１０１は、メールの受信が完了すると、メールサーバ１０２に対して受信したメールの削除要求を送信する。これは従来のメーラーの動きと同様である。そして、メールサーバ１０２は削除要求のあったメールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」値を参照し、当該「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が「０」となっている場合には、その削除要求を受け付けて、当該メールの削除を実行する。一方、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が「０」でない場合には、削除要求を無視する。こうすることで、設定された受信台数分の送信が完了していれば、メールサーバ１０２がクライアント装置１０１からの削除要求を受け付けて当該メールの削除を実行し、そうでなければ削除要求を無視することができるので、ユーザは受信台数７１３をメールサーバ１０２に設定するだけで、メールサーバの容量を圧迫せずに、必要な台数分メールを受信することができる。以下、この詳細な説明を行う。
【０１２４】
本発明の第２の実施形態におけるクライアント装置１０１とメールサーバ１０２によって行われるメール受信処理について図１４を用いて説明する。尚、ステップＳ１４０１、ステップＳ１４０２、ステップＳ１４１０、ステップＳ１４１１、ステップＳ１４１６、ステップＳ１４１７の各ステップはクライアント装置１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１４０３乃至ステップＳ１４０９、ステップＳ１４１２乃至ステップＳ１４１５の各ステップはメールサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１２５】
また、この処理をクライアント装置１０１及びメールサーバ１０２に実行させるためのプログラムは、クライアント装置１０１及びメールサーバ１０２にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１２６】
ステップＳ１４０１以前の処理は、前述した図９のメール受信処理と同様であるので説明を省略する。つまり、前述したステップＳ９１４で受信対象メールがあると判定されたところから説明を開始する。
【０１２７】
ステップＳ１４０１では、クライアント装置１０１は、後述するステップＳ１４０２乃至ステップＳ１４１６の処理を受信するメール数分繰り返す。受信するメール数分のループが完了したら、ループを抜けて、ステップＳ１４１７に処理を進める。
【０１２８】
ステップＳ１４０２では、クライアント装置１０１は、新たに受信すべきメールの受信要求をメールサーバ１０２に対して送信する（取得要求送信手段）。ここでは、新たに受信すべきメールのうち、１通のメールについての受信要求を送信する。メールの受信順序は問わない。また、合わせて当該ユーザのユーザＩＤを送信しておく。
【０１２９】
ステップＳ１４０３では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの受信要求を受信する。そして、ステップＳ１４０４では、メールサーバ１０２は、クライアント装置１０１から要求されたメールを当該ユーザのメールボックスから取得する。
【０１３０】
ステップＳ１４０５では、メールサーバ１０２は、ステップＳ１４０４で取得したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在するか否かを判定する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在する場合には、ステップＳ１４０８に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しない場合には、ステップＳ１４０６に処理を進める。
【０１３１】
ステップＳ１４０６では、メールサーバ１０２は、当該ユーザの受信台数７１３を取得する。具体的には、ユーザ認証テーブル７１０に基づいて、ステップＳ１４０３で受信したユーザＩＤからユーザＩＤ７１１を特定し、当該ユーザＩＤ７１１に対応する受信台数７１３を取得すればよい。
【０１３２】
ステップＳ１４０７では、メールサーバ１０２は、ステップＳ１４０４で取得したメールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないので、新たにメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、ステップＳ１４０６で取得した受信台数７１３の値を設定する。図１５の送信メールヘッダー１５００に示すように、元々メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないメールについては、メールヘッダー情報１５０１に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を新たに追加し、受信台数７１３の値を設定する。例えば、ここではユーザＩＤ７１１が「ａａａａａ＠ｘｘｘｘｘ．ｃｏ．ｊｐ」の受信台数７１３である「３」を設定している。
【０１３３】
そして、ステップＳ１４０８では、メールサーバ１０２は、ステップＳ１４０４で取得したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントする（更新手段）。図１６の送信メールヘッダー１６００のメールヘッダー情報１６０１に示すように、ステップＳ１４０４で取得したメールのメールヘッダーには既に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」として値に「２」が設定されている。つまり、残り２台のクライアント装置１０１に当該メールを送信しなければいけない旨を示している。今回新たにメールを送信するため、この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値から更に「１」を減算して、メールヘッダー情報１６０２に示すように値を「１」に変更する。このようにすることで、残り何台のクライアント装置１０１に送信すべきなのかを記録しておくことができる。尚、前述した通り、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。
【０１３４】
ステップＳ１４０９では、メールサーバ１０２は、ステップＳ１４０４で取得し、ステップＳ１４０７またはステップＳ１４０８で「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加または更新を行ったメールをクライアント装置１０１に送信する（送信手段）。
【０１３５】
ステップＳ１４１０では、クライアント装置１０１は、メールサーバ１０２から送信されたメールを受信する（受信手段）。
【０１３６】
ステップＳ１４１１では、クライアント装置１０１は、ステップＳ１４１０においてメールの受信が完了したので、当該メールの削除要求をメールサーバ１０２に送信する（削除要求送信手段）。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。
【０１３７】
ステップＳ１４１２では、メールサーバ１０２は、クライアント装置１０１から送信されたメールの削除要求を受信する。
【０１３８】
ステップＳ１４１３では、メールサーバ１０２は、削除要求がなされたメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下であるか否かを判定する（削除判定手段）。つまり、設定された受信台数分のクライアント装置１０１ですべて受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、削除要求を受け付けて当該メールの削除を実行するが、そうでなければ削除要求を無視して、次のメールの処理に移る。このような仕組みでメールサーバ１０２のメールボックスに蓄積されたメールを削除するようにすれば、ユーザは受信台数をメールサーバ１０２に設定するだけで、メールサーバの容量を圧迫することなく、複数台のクライアント装置１０１で同一のメールを受信することができるようになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下であると判定された場合には、ステップＳ１４１４に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下でないと判定された場合には、ステップＳ１４１５に処理を進める。
【０１３９】
ステップＳ１４１４では、メールサーバ１０２は、削除要求のなされたメールをメールボックスから削除する（削除手段）。具体的には、ステップＳ１４１２で受信した削除要求に含まれる「Ｍｅｓｓａｇｅ−ｉｄ」から当該ユーザのメールボックスにあるメールを特定し、当該メールをメールボックスから削除する。
【０１４０】
ステップＳ１４１５では、メールサーバ１０２は、ステップＳ１４１２で受信した削除要求に応じた実行結果をクライアント装置１０１に送信する。
【０１４１】
ステップＳ１４１６では、クライアント装置１０１は、メールサーバ１０２から送信された実行結果を受信し、必要に応じてＲＡＭ２０３に記憶しておく。受信が完了したら、ステップＳ９１４で受信対象メールと判定されたメールがすべて受信できたか否かを判定し、すべてのメールの受信が完了できたなら、ステップＳ１４１７に処理を進め、そうでない場合には、未受信のメールを受信するべく、ステップＳ１４０１乃至ステップＳ１４１６を繰り返す。
【０１４２】
ステップＳ１４１７では、クライアント装置１０１は、ステップＳ１４１０で受信したメール一覧をユーザに対して閲覧可能にＣＲＴ２１０に表示させる。表示が完了したら、メール受信処理を終了し、呼び出し元に処理を戻す。ここで、ステップＳ１４１６で受信した削除要求に応じた実行結果をユーザに通知する。例えば、「まだ受信していない装置があるので、削除できませんでした。」といったメッセージをユーザに通知することで、ユーザに処理内容を把握させることができる。特に、削除できなかったメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を通知することで、削除できなかったメールを把握させることも可能である。この場合には、ステップＳ９３０で送信される実行結果にメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を含めて、その情報を通知させればよい。
【０１４３】
次に、本発明の第３の実施形態について説明する。前述した実施形態では、クライアント装置１０１とメールサーバ１０２とが動作することによって、複数台のクライアント装置１０１で同じメールを受信することの可能な仕組みを説明したが、この仕組みでは、メールサーバ１０２を改修する必要がある。すなわち、従来のメールサーバ１０２では、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に応じて、対象のメールを削除するか否かを判定する仕組みは存在しないため、この処理を実行可能に改修する必要が生じてしまう。そのため、第３の実施形態では、クライアント装置１０１とメールサーバ１０２との間の通信を中継するプロキシサーバ１０４を設置し、プロキシサーバ１０４で前述した改修の必要がある処理を実行する。このような仕組みであっても、前述した実施形態と同じ効果を得ることができる。以下、この仕組みについての説明を行う。
【０１４４】
図１８は、第３の実施形態におけるメールシステム１００のシステム構成の一例を示す図である。本発明のメールシステム１００は、クライアント装置１０１（クライアント装置１０１ａ、クライアント装置１０１ｂ、クライアント装置１０１ｃ）、メールサーバ１０２、更にはプロキシサーバ１０４が設置されており、それら装置はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０３を介して相互にデータ通信可能に接続されている。図１のネットワーク１０３上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【０１４５】
クライアント装置１０１と、メールサーバ１０２は、前述した実施形態と同様であるので、説明を省略する。
【０１４６】
プロキシサーバ１０４は、クライアント装置１０１とメールサーバ１０２との間の通信を中継するサーバである。クライアント装置１０１からメールサーバ１０２に対するメールの取得要求や削除要求を受け取り、メールサーバ１０２に送信する。プロキシサーバ１０４は、クライアント装置１０１やメールサーバ１０２と通信するために、ＳＭＴＰやＰＯＰといったプロトコルを用いて情報の送受信を行う。
【０１４７】
クライアント装置１０１、メールサーバ１０２、更にはプロキシサーバ１０４のハードウェア構成は、前述した実施形態と同様（図２に示す）であるので、説明を省略する。
【０１４８】
次に、クライアント装置１０１、メールサーバ１０２、プロキシサーバ１０４のモジュール構成について説明する。モジュール構成は、前述した実施形態とほぼ同様であるが、メールサーバ１０２に備える一部の機能をプロキシサーバ１０４が備える形態となる。
【０１４９】
プロキシサーバ１０４は、メール送受信モジュール３１４、メール削除判定モジュール３１７を備える。メール送受信モジュール３１４、メール削除判定モジュール３１７は、前述した実施形態におけるメールサーバ１０２が備えるものと同様であるので、説明を省略する。
【０１５０】
次に、プロキシサーバ１０４にユーザが受信したいクライアント装置１０１の台数を設定するための処理について図１９を用いて説明する。
【０１５１】
また、この処理をクライアント装置１０１及びプロキシサーバ１０４に実行させるためのプログラムは、クライアント装置１０１及びプロキシサーバ１０４にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１５２】
まず、ステップＳ１９０１では、クライアント装置１０１のＣＰＵ２０１は、プロキシサーバ１０４に対して設定変更を行うための画面の取得要求を送信する。
【０１５３】
ステップＳ１９０２では、プロキシサーバ１０４のＣＰＵ２０１は、クライアント装置１０１から送信された設定変更画面の取得要求を受信し、ステップＳ１９０３では、図２０の設定変更画面２０００に示すような画面を生成する。設定変更画面２０００はプロキシサーバ１０４の外部メモリ２１１にあらかじめ記憶されていてもよい。ステップＳ１９０４では、プロキシサーバ１０４のＣＰＵ２０１は、生成された設定変更画面２０００をクライアント装置１０１に送信する。
【０１５４】
ステップＳ１９０５では、クライアント装置１０１のＣＰＵ２０１は、プロキシサーバ１０４から送信された設定変更画面２０００を受信し、ステップＳ１９０６では、受信した設定変更画面２０００をＣＲＴ２１０に表示する。そして、ステップＳ１９０７では、クライアント装置１０１のＣＰＵ２０１は、表示した設定変更画面２０００に対してユーザから操作を受け付ける。具体的には、設定変更画面２０００に備えられたユーザＩＤ入力欄２００１、パスワード入力欄２００２、受信台数入力欄２００３、ＯＫボタン２００４等に対する入力を受け付ける。
【０１５５】
ステップＳ１９０８では、クライアント装置１０１のＣＰＵ２０１は、ユーザＩＤ入力欄２００１と、パスワード入力欄２００２と、受信台数入力欄２００３とに対する入力がなされ、ＯＫボタン２００４が押下されたか否かを判定する。ＯＫボタン２００４が押下されたと判定された場合には、ステップＳ１９０９に処理を進め、そうでない場合には、ＯＫボタン２００４が押下されるまで待機する。
【０１５６】
ステップＳ１９０９では、クライアント装置１０１のＣＰＵ２０１は、ユーザＩＤ入力欄２００１と、パスワード入力欄２００２と、受信台数入力欄２００３とに入力された各種情報をプロキシサーバ１０４に送信する。
【０１５７】
ステップＳ１９１０では、プロキシサーバ１０４のＣＰＵ２０１は、クライアント装置１０１から送信された各種情報を受信し、ステップＳ１９１１では、受信した各種情報をユーザ認証テーブル７１０に登録する。ユーザ認証テーブル７１０は、前述した図７と同様であるが、第３の実施形態においては、プロキシサーバ１０４にも記憶されており、メールサーバ１０２に記憶されたユーザ認証テーブル７１０と適宜同期して内容を一致させている。ステップＳ１９１０の処理をより具体的に説明すると、受信した情報に含まれるユーザＩＤとパスワードの組に一致するレコードをユーザ認証テーブル７１０から特定し、当該レコードの受信台数７１３に受信台数入力欄２００３に入力された値を格納すればよい。例えば、ユーザＩＤが「ａａａａａ＠ｘｘｘｘｘ．ｃｏ．ｊｐ」で受信台数が「３」だった場合には、ユーザ認証テーブル７１０の１レコード目の受信台数７１３に「３」を格納することになる。このようにして、ユーザごとに受信台数の設定を行うことができる。
【０１５８】
ステップＳ１９１２では、プロキシサーバ１０４のＣＰＵ２０１は、受信台数の登録の実行結果をクライアント装置１０１に送信する。
【０１５９】
ステップＳ１９１３では、クライアント装置１０１のＣＰＵ２０１は、受信台数登録の実行結果を受信し、ステップＳ１９１４では、その実行結果をユーザに通知する。以上のようにして、プロキシサーバ１０４に受信台数を登録する。
【０１６０】
次に、本発明の実施形態におけるクライアント装置１０１と、メールサーバ１０２と、プロキシサーバ１０４とによって行われるメール受信処理について、図２１及び図２２を用いて説明する。第３の実施形態においても、メール受信処理は図８と同様の処理が実行される。その図８の一連の流れのうち、ステップＳ８０４の実行を行う際に、図２１及び図２２に示す処理が実行されることになる。図８については、同様の処理であるので説明を省略する。
【０１６１】
また、この処理をクライアント装置１０１、メールサーバ１０２、プロキシサーバ１０４に実行させるためのプログラムは、クライアント装置１０１、メールサーバ１０２、プロキシサーバ１０４にインストールされているメーラーまたはアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、メーラーまたはアプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１６２】
まず、ステップＳ２００１では、クライアント装置１０１のＣＰＵ２０１は、ユーザ認証を行うべく、ユーザからの入力によってメーラーにあらかじめ設定されたユーザＩＤとパスワードとをプロキシサーバ１０４に送信する。当該ユーザＩＤとパスワードとの送信先も、ユーザからの入力によってあらかじめメーラーに設定されており、当該送信先としてプロキシサーバ１０４が設定されている。ユーザＩＤとパスワードは受信を行う度にユーザからの入力を受け付けて、入力されたユーザＩＤとパスワードとをプロキシサーバ１０４に送信するようにしてもよい。
【０１６３】
ステップＳ２１０２では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１０１でクライアント装置１０１から送信されたユーザＩＤとパスワードを中継するべく、これらをメールサーバ１０２に送信する。ステップＳ２１０３では、メールサーバ１０２のＣＰＵ２０１は、プロキシサーバ１０４から送信されたユーザＩＤとパスワードを受信し、ステップＳ２１０４では、受信したユーザＩＤとパスワードと、メールサーバ１０２の外部メモリ２１１に記憶されたユーザ認証テーブル７１０に基づいてユーザ認証を行う。受信したユーザＩＤとパスワードの組み合わせがユーザ認証テーブル７１０のユーザＩＤ７１１とパスワード７１２の組み合わせに存在すれば、認証ＯＫとなるが、そうでなければ認証ＮＧとなる。
【０１６４】
ステップＳ２１０５では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１０４で認証された結果をクライアント装置１０１に返信する。ステップＳ２１０６では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１０５でメールサーバ１０２から送信された認証結果を中継すべく、これをクライアント装置１０１に送信する。
【０１６５】
ステップＳ２１０７では、クライアント装置１０１のＣＰＵ２０１は、プロキシサーバ１０４から送信されたユーザ認証の結果を受信する。そして、ステップＳ２１０８では、クライアント装置１０１のＣＰＵ２０１は、その認証結果が認証ＯＫであったか否かを判定する。認証ＯＫであった場合には、ステップＳ２１１０に処理を進め、認証ＮＧであった場合には、ステップＳ２１０９に処理を進める。
【０１６６】
ステップＳ２１０９では、クライアント装置１０１のＣＰＵ２０１は、認証ＮＧであったため、接続エラーをユーザに通知して、メール受信処理を終了する。
【０１６７】
ステップＳ２１１０では、クライアント装置１０１のＣＰＵ２０１は、メールサーバ１０２のメールボックスに蓄積されたすべてのメールのメールヘッダーの取得をプロキシサーバ１０４に対して要求する。後述するステップＳ２１１８及びステップＳ２１１９で、既に受信済みのメールと新たに受信すべきメールを特定するためにこのような処理を行っている。
【０１６８】
ステップＳ２１１１では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１１０でクライアント装置１０１から送信されたメールヘッダーの取得要求を中継すべく、これをメールサーバ１０２に送信する。ステップＳ２１１２では、メールサーバ１０２のＣＰＵ２０１は、プロキシサーバ１０４から送信されたすべてのメールのメールヘッダーの取得要求を受信する。そして、ステップＳ２１１３では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１０４で認証されたユーザのメールボックスに蓄積されたすべてのメールからメールヘッダーを取得する。ここでは少なくともメールを一意に特定する識別情報である「Ｍｅｓｓａｇｅ−ｉｄ」と、前述した「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」とを含めたメールヘッダーを取得するようにする。
【０１６９】
ステップＳ２１１４では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１１３で取得したすべてのメールのメールヘッダーをプロキシサーバ１０４に送信する。
【０１７０】
ステップＳ２１１５では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１１４でメールサーバ１０２から送信されたメールヘッダーを受信し、ＲＡＭ２０３等に一時保存する。プロキシサーバ１０４が保存したメールヘッダーは、後述する図２２のステップＳ２１２４で用いる。そして、ステップＳ２１１６では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１１４でメールサーバ１０２から送信されたメールヘッダーを中継するべく、これらをクライアント装置１０１に送信する。
【０１７１】
ステップＳ２１１７では、クライアント装置１０１のＣＰＵ２０１は、プロキシサーバ１０４から送信されたメールヘッダーを受信し、ステップＳ２１１８では、クライアント装置１０１のＣＰＵ２０１は、受信したメールヘッダーと、クライアント装置１０１に受信済みのメールのメールヘッダーとを比較し、新たに受信すべきメールの有無を確認する。具体的には、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールをクライアント装置１０１のメーラーから検索するようにすればよい。受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にあれば、既にそのメールは受信済みであると判定できる。しかし、受信したメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールがクライアント装置１０１にないのであれば、当該「Ｍｅｓｓａｇｅ−ｉｄ」を持つメールは、新たにメールサーバ１０２から受信すべきメールであると判定できる。
【０１７２】
ステップＳ２１１９では、クライアント装置１０１のＣＰＵ２０１は、ステップＳ２１１８で確認した結果、新たに受信すべきメールが存在するか否かを判定する。新たに受信すべきメールが存在すると判定された場合には、図２２のステップＳ２１２１に処理を進め、新たに受信すべきメールが存在しないと判定された場合には、ステップＳ２１２０に処理を進める。
【０１７３】
ステップＳ２１２０では、クライアント装置１０１のＣＰＵ２０１は、新たに受信すべきメールが存在しないので、その旨をユーザに通知する。そして、メール受信処理を終了する。
【０１７４】
図２１に続き、図２２を用いて説明を行う。ステップＳ２１２１では、クライアント装置１０１のＣＰＵ２０１は、後述するステップＳ２１２２乃至ステップＳ２１４７の処理を受信するメール数分繰り返す。受信するメール数分のループが完了したら、ループを抜けて、ステップＳ２１４８に処理を進める。
【０１７５】
ステップＳ２１２２では、クライアント装置１０１のＣＰＵ２０１は、新たに受信すべきメールの受信要求をプロキシサーバ１０４に対して送信する。ここでは、新たに受信すべきメールのうち、１通のメールについての受信要求を送信する。メールの受信順序は問わない。
【０１７６】
ステップＳ２１２３では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１２２でクライアント装置１０１から送信されたメールの受信要求を受信する。そして、ステップＳ２１２４では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１１５でＲＡＭ２０３等に一時保存したメールヘッダーのうち、クライアント装置１０１から要求されたメール（以下、対象メール）のメールヘッダーを取得する。
【０１７７】
ステップＳ２１２５では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１２４で取得した対象メールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在するか否かを判定する。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在する場合には、ステップＳ２１２７に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しない場合には、ステップＳ２１２６に処理を進める。
【０１７８】
ステップＳ２１２６では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１２４で取得した対象メールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないので、新たにメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、値を「１」に設定するよう、メールサーバ１０２に要求する。
【０１７９】
一方、ステップＳ２１２７では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１２４で取得したメールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントするよう、メールサーバ１０２に要求する。
【０１８０】
ステップＳ２１２８では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１２６またはステップＳ２１２７でプロキシサーバ１０４から送信された、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加要求または更新要求を受信する。そして、ステップＳ２１２９では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１２８で受信した「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加要求または更新要求に応じて、対象メールのメールヘッダーにある「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加または更新を実行する。例えば、メールサーバ１０２に、このようなメールヘッダーの操作指示を受け付けるためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を備えており、プロキシサーバ１０４からの要求に応じて、当該ＡＰＩを動作させ、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加または更新を実行する。
【０１８１】
図１１の送信メールヘッダー１１００に示すように、元々メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないメールの場合、メールヘッダー情報１１０１に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を新たに追加し、値に「１」を設定する。ここで「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値を「１」に設定するのは、これからクライアント装置１０１にメールを送信することで、１台の装置で受信がなされるからである。一方、図１２の送信メールヘッダー１２００のメールヘッダー情報１２０１に示すように、ステップＳ９１９で取得したメールのメールヘッダーには既に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」として値に「１」が設定されている場合、今回新たにメールを送信するため、この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値に更に「１」を加算して、メールヘッダー情報１２０２に示すように値を「２」に変更する。このようにすることで、何台のクライアント装置１０１に送信したのかを記録しておくことができる。尚、前述した通り、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。
【０１８２】
ステップＳ２１３０では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１２９で実行された実行結果をプロキシサーバ１０４に送信する。そして、ステップＳ２１３１では、プロキシサーバ１０４のＣＰＵ２０１は、メールサーバ１０２から送信された実行結果を受信すると、ステップＳ２１３２に処理を進める。
【０１８３】
ステップＳ２１３２では、プロキシサーバ１０４のＣＰＵ２０１は、クライアント装置１０１から要求された対象メールの取得要求をメールサーバ１０２に送信する。そして、ステップＳ２１３３では、メールサーバ１０２のＣＰＵ２０１は、プロキシサーバ１０４から送信された対象メールの取得要求を受信する。ステップＳ２１３４では、メールサーバ１０２のＣＰＵ２０１は、プロキシサーバ１０４から要求された対象メールを当該ユーザのメールボックスから取得する。
【０１８４】
ステップＳ２１３５では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１３４で取得した対象メールをプロキシサーバ１０４に送信する。ステップＳ２１３６では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１３５でメールサーバ１０２から送信された対象メールをクライアント装置１０１に中継するべく、当該対象メールをクライアント装置１０１に送信する。
【０１８５】
ステップＳ２１３７では、クライアント装置１０１のＣＰＵ２０１は、ステップＳ２１３６でプロキシサーバ１０４から送信された対象メールを受信する。
【０１８６】
ステップＳ２１３８では、クライアント装置１０１のＣＰＵ２０１は、ステップＳ２１３７においてメールの受信が完了したので、当該対象メールの削除要求をプロキシサーバ１０４に送信する。削除要求を送信する際には、当該メールを特定できる情報と共に送信する。例えば、当該対象メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードである。
【０１８７】
ステップＳ２１３９では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１３８でクライアント装置１０１から送信された対象メールの削除要求を受信する。
【０１８８】
ステップＳ２１４０では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１３９で受信した削除要求に含まれるユーザＩＤから当該ユーザが設定した受信台数７１３を取得する。具体的には、ユーザ認証テーブル７１０と受信したユーザＩＤからユーザＩＤ７１１を特定し、当該ユーザＩＤ７１１に対応する受信台数７１３を取得するようにすればよい。
【０１８９】
ステップＳ２１４１では、プロキシサーバ１０４のＣＰＵ２０１は、削除要求がなされた対象メールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が、ステップＳ２１４０で取得した受信台数７１３以上であるか否かを判定する。つまり、設定された受信台数分のクライアント装置１０１で受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、メールサーバ１０２に対して対象メールの削除要求を実行するが、そうでなければ削除要求を無視して、次のメールの処理に移る。このような仕組みでメールサーバ１０２のメールボックスに蓄積されたメールを削除するようにすれば、ユーザは受信台数をプロキシサーバ１０４に設定するだけで、メールサーバの容量を圧迫することなく、複数台のクライアント装置１０１で同一のメールを受信することができるようになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７１３以上であると判定された場合には、ステップＳ２１４２に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７１３以上でないと判定された場合には、ステップＳ２１４６に処理を進める。
【０１９０】
ステップＳ２１４２では、プロキシサーバ１０４のＣＰＵ２０１は、すべてのクライアント装置１０１で受信が完了したので、対象メールの削除要求をメールサーバ１０２に送信する。ここでは、ステップＳ２１３９でクライアント装置１０１から受信した削除要求に含まれる、対象メールのメールヘッダーに含まれる「Ｍｅｓｓａｇｅ−ｉｄ」と、ユーザを特定するユーザＩＤ及びパスワードを合わせて送信する。
【０１９１】
ステップＳ２１４３では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１４２でプロキシサーバ１０４から送信された対象メールの削除要求を受信する。そして、ステップＳ２１４４では、メールサーバ１０２のＣＰＵ２０１は、削除要求のなされた対象メールを当該ユーザのメールボックスから削除する。具体的には、ステップＳ２１４３で受信した削除要求に含まれるユーザＩＤやパスワードに基づいて当該ユーザのメールボックスを特定し、「Ｍｅｓｓａｇｅ−ｉｄ」から対象メールを特定し、当該対象メールをメールボックスから削除する。
【０１９２】
ステップＳ２１４５では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２１４４で対象メールを削除した実行結果をプロキシサーバ１０４に送信する。
【０１９３】
ステップＳ２１４６では、プロキシサーバ１０４のＣＰＵ２０１は、ステップＳ２１４１で「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が受信台数７１３以上でないと判定された場合には、その結果をクライアント装置１０１に送信し、ステップＳ２１４５でメールサーバ１０２から送信された、対象メール削除の実行結果を受信した場合には、クライアント装置１０１に中継するべく、当該実行結果をクライアント装置１０１に送信する。
【０１９４】
ステップＳ２１４７では、クライアント装置１０１のＣＰＵ２０１は、ステップＳ２１４６でプロキシサーバ１０４から送信された実行結果を受信し、必要に応じてＲＡＭ２０３に記憶しておく。受信が完了したら、ステップＳ２１１９で受信対象メールと判定されたメールがすべて受信できたか否かを判定し、すべてのメールの受信が完了できたなら、ステップＳ２１４８に処理を進め、そうでない場合には、未受信のメールを受信するべく、ステップＳ２１２２乃至ステップＳ２１４７を繰り返す。
【０１９５】
ステップＳ２１４８では、クライアント装置１０１のＣＰＵ２０１は、ステップＳ２１４７で受信したメール一覧をユーザに対して閲覧可能にＣＲＴ２１０に表示させる。表示が完了したら、メール受信処理を終了し、呼び出し元に処理を戻す。ここで、ステップＳ２１４７で受信した削除要求に応じた実行結果をユーザに通知する。例えば、「まだ受信していない装置があるので、削除できませんでした。」といったメッセージをユーザに通知することで、ユーザに処理内容を把握させることができる。特に、削除できなかったメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を通知することで、削除できなかったメールを把握させることも可能である。この場合には、ステップＳ２１４５で送信される実行結果にメールの件名や「Ｍｅｓｓａｇｅ−ｉｄ」を含めて、その情報を通知させればよい。
【０１９６】
以上説明したように、第３の実施形態によれば、クライアント装置１０１とメールサーバ１０２との間の通信を中継するプロキシサーバ１０４を設置し、当該プロキシサーバ１０４が受信台数に基づいてメールを削除するか否かを制御するので、メールサーバ１０２に大きな改修を加えることなく、受信させたいすべてのクライアント装置１０１でメールを受信させ、かつメールサーバ１０２の容量を圧迫しない効果を奏する。
【０１９７】
次に、本発明の第４の実施形態について説明する。第３の実施形態では、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をインクリメントしていたが、第４の実施形態では、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」に受信台数７１３の値を設定し、送信の度に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントし、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」になったら削除要求を受け付けて削除を実行する。そうでなければ削除要求を無視する。このような仕組みであっても、前述した実施形態と同じ効果を得ることができる。以下、この仕組みについての説明を行う。
【０１９８】
尚、第４の実施形態は、前述した第３の実施形態のメール受信処理におけるステップＳ２１２６以降の一部の処理が異なるだけであり、それ以外の部分については同様であるので説明を省略する。
【０１９９】
本発明の第４の実施形態におけるクライアント装置１０１と、メールサーバ１０２と、プロキシサーバ１０４とによって行われるメール受信処理について、図２３を用いて説明する。
【０２００】
図２３に示すステップＳ２１２１以前の処理は、前述した図２１のメール受信処理と同様であるので説明を省略する。つまり、前述したステップＳ２１２０で受信対象メールがあると判定されたところから説明を開始する。
【０２０１】
図２３に示すステップＳ２１２１乃至ステップＳ２１２５は、前述した図２２のステップＳ２１２１乃至ステップＳ２１２５と同様であるので、説明を省略する。
【０２０２】
ステップＳ２１２５で、対象メールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」がないと判定されると、ステップＳ２３０１では、プロキシサーバ１０４のＣＰＵ２０１は、対象メールを受信するユーザの受信台数７１３をユーザ認証テーブル７１０から取得し、当該取得した受信台数７１３の値を設定した「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を対象メールのメールヘッダーに追加するよう、メールサーバ１０２に要求する。
【０２０３】
ステップＳ２３０２では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２３０１でプロキシサーバ１０４から送信された、対象メールの「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の追加要求を受信すると、対象メールのメールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を追加し、当該「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値として、ステップＳ２３０１で取得した受信台数７１３を設定する。図１５の送信メールヘッダー１５００に示すように、元々メールヘッダーに「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」が存在しないメールについては、メールヘッダー情報１５０１に示すように「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」を新たに追加し、受信台数７１３の値を設定する。例えば、ここではユーザＩＤ７１１が「ａａａａａ＠ｘｘｘｘｘ．ｃｏ．ｊｐ」の受信台数７１３である「３」を設定している。
【０２０４】
そして、ステップＳ２３０３では、プロキシサーバ１０４のＣＰＵ２０１は、対象メールのメールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントするよう、メールサーバ１０２に要求する。
【０２０５】
ステップＳ２３０４では、メールサーバ１０２のＣＰＵ２０１は、ステップＳ２３０３でプロキシサーバ１０４から送信された、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の更新要求を受信し、ステップＳ２３０５では、当該更新要求に応じて、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値をデクリメントする。図１６の送信メールヘッダー１６００のメールヘッダー情報１６０１に示すように、ステップＳ１４０４で取得したメールのメールヘッダーには既に「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」として値に「２」が設定されている。つまり、残り２台のクライアント装置１０１に当該メールを送信しなければいけない旨を示している。今回新たにメールを送信するため、この「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値から更に「１」を減算して、メールヘッダー情報１６０２に示すように値を「１」に変更する。このようにすることで、残り何台のクライアント装置１０１に送信すべきなのかを記録しておくことができる。尚、前述した通り、本実施形態ではメールヘッダーにこのような情報を含める仕組みとして説明を行うが、メールとは別の情報でもよいし、メールの添付ファイルとして生成されてもよい。ステップＳ２３０５の処理が完了すると、図２３のステップＳ２１３０に処理を進める。
【０２０６】
図２３のステップＳ２１３０乃至ステップＳ２１３９は、前述した図２２のステップＳ２１３０乃至ステップＳ２１３９と同様であるので説明を省略する。
【０２０７】
ステップＳ２１３９が実行されると、ステップＳ２３０６では、プロキシサーバ１０４のＣＰＵ２０１は、削除要求がなされた対象メールのメールヘッダーをＲＡＭ２０３から取得し、当該メールヘッダーに含まれる「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下であるか否かを判定する。つまり、設定された受信台数分のクライアント装置１０１ですべて受信されたかどうかを判定することになる。ここで設定された受信台数分受信されていれば、削除要求を受け付けて当該メールの削除を実行するが、そうでなければ削除要求を無視して、次のメールの処理に移る。このような仕組みでメールサーバ１０２のメールボックスに蓄積されたメールを削除するようにすれば、ユーザは受信台数をプロキシサーバ１０４に設定するだけで、メールサーバの容量を圧迫することなく、複数台のクライアント装置１０１で同一のメールを受信することができるようになる。「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下であると判定された場合には、ステップＳ２１４２に処理を進め、「Ｒｅｃｅｉｖｉｎｇ−Ｃｏｕｎｔ」の値が「０」以下でないと判定された場合には、ステップＳ２１４６に処理を進める。
【０２０８】
図２３のステップＳ２１４２乃至ステップＳ２１４８は、前述した図２２のステップＳ２１４２乃至ステップＳ２１４８と同様であるので、説明を省略する。
【０２０９】
以上説明したように、第４の実施形態によれば、クライアント装置１０１とメールサーバ１０２との間の通信を中継するプロキシサーバ１０４を設置し、当該プロキシサーバ１０４が受信台数に基づいてメールを削除するか否かを制御するので、メールサーバ１０２に大きな改修を加えることなく、受信させたいすべてのクライアント装置１０１でメールを受信させ、かつメールサーバ１０２の容量を圧迫しない効果を奏する。
【０２１０】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０２１１】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０２１２】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０２１３】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０２１４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０２１５】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０２１６】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０２１７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０２１８】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０２１９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０２２０】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０２２１】
１００  メールシステム
１０１ａ  クライアント装置
１０１ｂ  クライアント装置
１０１ｃ  クライアント装置
１０２  メールサーバ
１０３  ネットワーク
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆ（インターフェース）コントローラ
２０９  入力装置
２１０  ディスプレイ装置
２１１  外部メモリ
【図１】
2014096791.tif 000003
【図２】
2014096791.tif 000004
【図３】
2014096791.tif 000005
【図４】
2014096791.tif 000006
【図５】
2014096791.tif 000007
【図６】
2014096791.tif 000008
【図７】
2014096791.tif 000009
【図８】
2014096791.tif 000010
【図９】
2014096791.tif 000011
【図１０】
2014096791.tif 000012
【図１１】
2014096791.tif 000013
【図１２】
2014096791.tif 000014
【図１３】
2014096791.tif 000015
【図１４】
2014096791.tif 000016
【図１５】
2014096791.tif 000017
【図１６】
2014096791.tif 000018
【図１７】
2014096791.tif 000019
【図１８】
2014096791.tif 000020
【図１９】
2014096791.tif 000021
【図２０】
2014096791.tif 000022
【図２１】
2014096791.tif 000023
【図２２】
2014096791.tif 000024
【図２３】
2014096791.tif 000025