JP3893371B2 - 返信メール作成装置、方法、プログラム及び記録媒体 - Google Patents

Description

本発明は、ユーザのメールアドレスを宛先としたメールに対する返信メールを作成する際に、当該返信メールにおける送信元アドレスの設定に関するものである。

従来のメールアプリケーションでは、受信したメールに対して返信を指示することにより、返信メールを作成することができるようになっていた。このとき、返信メールの宛先アドレスは、受信したメールの送信元アドレスに、返信メールの送信元アドレスは、受信したメールの宛先アドレスに設定されるものとなっていた。これに対して、返信メールの送信元アドレスを単純に受信したメールの宛先アドレスとするのではなく、ユーザに有利な課金形態が使用されるようなメールアドレスに設定するものがあった（例えば、特許文献１参照）。

特開２００３−３６２２６号公報

しかしながら、返信メールに設定する送信元アドレスは、返信メールの作成時点において、既に使用できなくなっている虞もあった。この点は、特許文献１のように返信メールの送信元アドレスを設定する場合も変わりがなかった。既に使用できなくなったメールアドレスが送信元アドレスとして設定されてしまっていると、当該返信メールを受け取った他のユーザがさらに作成した返信メールは、当該ユーザの元に返送されないことになってしまっていた。

本発明は、受信したメールに対して返信メールを作成する際に、その返信メールの送信元アドレスとして適切なメールアドレスを設定することができる返信メール作成装置等を提供することを目的とする。

上記目的を達成するため、本発明の第１の観点にかかる返信メール作成装置は、ネットワークを介して接続されたメールサーバから、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを受信するメール受信手段と、ユーザが現在使用可能なメールアドレスを記憶するアドレス記憶手段と、ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、当該使用されなくなったメールアドレスを前記アドレス記憶手段から削除するアドレス削除手段と、前記メール受信手段がメールを受信した時点よりも後の時点で、該受信したメールに対する返信メールを生成する返信メール生成手段とを備え、前記返信メール生成手段は、前記返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスが前記アドレス削除手段により削除されることなく前記アドレス記憶手段に記憶されているかどうかを判定する宛先判定手段と、該宛先アドレスが前記アドレス記憶手段に記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定する送信元アドレス設定手段とを備えることを特徴とする。

上記返信メール作成装置では、受信したメールに設定されていた宛先アドレスが既に使用不能となっていても、そのメールに対する返信メールの送信元アドレスには、ユーザが現在使用可能なメールアドレスを設定することができる。このため、当該返信メールに対して他のユーザが作成した返信メールの宛先アドレスに、適切なアドレスが設定されるようになる。一方、受信したメールに設定されていた宛先アドレスが現在使用可能であれば、ユーザが他のメールアドレスも使用可能であっても、当該宛先アドレスが返信メールの送信元アドレスとして設定されるので、この返信メールを受け取った他のユーザは、どのメールに対する返信メールであるかを容易に判断することができる。

上記返信メール作成装置において、前記返信メールの作成対象となるメールの宛先アドレスは、重要度が異なる少なくとも２つの宛先区分による指定がなされていてもよい。この場合において、前記送信元アドレス設定手段は、前記宛先アドレスが前記アドレス記憶手段に記憶されていると判定されたときには、該記憶されている宛先アドレスのうちの重要度が高い区分の宛先アドレスを優先して、返信メールの送信元アドレスに設定するものとすることができる。

通常のユーザが他のユーザにメールを送信するとき、その送信先アドレスには、送信相手としての重要性に応じた宛先区分の指定（例えば、“to”、“cc”、“bcc”）を行うことがある。従って、“重要度が高い区分の宛先アドレスを優先して、返信メールの送信元アドレスに設定することで、返信メールの作成対象となったメールを送信したユーザが重要度が高いと考えていたメールアドレスを返信メールの送信元アドレスに設定することができるようになる。

上記返信メール作成装置において、前記アドレス記憶手段は、前記アドレス記憶手段は、各ユーザに対して必ず設定されている標準メールアドレスと、ユーザからの要求に従って任意に設定される拡張メールアドレスとを記憶するものであってもよい。この場合において、前記アドレス削除手段は、前記拡張メールアドレスが使用されなくなったときに、該使用されなくなった拡張メールアドレスを前記アドレス記憶手段から削除することができ、前記送信元アドレス設定手段は、前記宛先アドレスに対応した拡張メールアドレスが前記アドレス記憶手段に記憶されていないと判定されたときには、前記標準メールアドレスを返信メールの送信元アドレスに設定することができる。

この場合には、受信したメールの宛先となっていた拡張メールアドレスが使用不能となったり変更されていた場合であっても、ユーザに対して必ず設定されている標準メールアドレスを返信メールの送信元アドレスに設定することができる。このため、この返信メールに対して他のユーザが作成した返信メールが、当該ユーザの元に確実に届けられるようになる。

上記返信メール作成装置において、前記メールサーバは、ユーザの現在使用可能なメールアドレスを管理するものであってもよい。この場合において、上記返信メール作成装置は、所定の時点において、前記メールサーバにおいて管理されているユーザの現在使用可能なメールアドレスを前記ネットワークを介して取得するアドレス取得手段と、前記アドレス取得手段が取得したメールアドレスに従って、前記アドレス記憶手段に記憶させるメールアドレスを更新するアドレス更新手段とをさらに備えるものとすることができる。

ユーザが使用可能なメールアドレスに関する最新の情報は、通常はユーザの端末装置（ここでは、上記の返信メール作成装置）よりもメールサーバにおいて管理されるものとなる。上記返信メール作成装置では、所定期間毎にメールサーバにおいて管理されているユーザの現在使用可能なメールアドレスを取得して、アドレス記憶手段を更新するものとしているので、実際には使用不能となったメールアドレスが使用可能なものと判断されて返信メールの送信元アドレスに設定されてしまうのを防ぐことができる。

上記目的を達成するため、本発明の第２の観点にかかる返信メール作成方法は、ユーザが現在使用可能なメールアドレスをアドレス記憶手段に記憶する端末装置において、ネットワークを介して接続されたメールサーバから、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを受信し、ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、当該使用されなくなったメールアドレスを前記アドレス記憶手段から削除し、メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定することを特徴とする返信メール作成方法。

上記目的を達成するため、本発明の第３の観点にかかるプログラムは、ネットワークを介してメールサーバに接続されたコンピュータ装置において実行されるプログラムであって、ユーザが現在使用可能なメールアドレスをアドレス記憶手段に予め記憶させ、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを前記メールサーバから前記ネットワークを介して受信し、ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、前記端末装置において記憶されていたメールアドレスのうちで当該使用されなくなったメールアドレスを削除し、メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定することを特徴とする。

上記目的を達成するため、本発明の第４の観点にかかるコンピュータ読み取り可能な記録媒体は、ネットワークを介してメールサーバに接続されたコンピュータ装置において実行されるプログラムを記録した記録媒体であって、前記プログラムは、ユーザが現在使用可能なメールアドレスをアドレス記憶手段に予め記憶させ、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを前記メールサーバから前記ネットワークを介して受信し、ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、前記端末装置において記憶されていたメールアドレスのうちで当該使用されなくなったメールアドレスを削除し、メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定することを特徴とする。

本発明によれば、返信メールの送信元アドレスにユーザが現在使用可能な適切なメールアドレスを設定して、さらにその返信メールに対して他のユーザが作成する返信メールの宛先アドレスに適切なメールアドレスが設定されるようにすることができる。

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

図１は、この実施の形態に適用されるネットワークシステムの全体構成を示すブロック図である。図示するように、このネットワークシステムは、複数の端末装置１がインターネット３を介してサーバ群２に接続されて構成される。サーバ群２は、ＬＡＮ（Local Area Network）２５を介して互いに接続された管理サーバ２１、メールサーバ２２、ゲームサーバ２３、及びデータベースサーバ２４を含み、サーバ２１〜２３がインターネット３を介して端末装置１に接続される。

サーバ群２が提供するサービスは、会員制のサービスであり、予め会員登録したユーザ（以下、単にユーザという）のみが利用することができる。端末装置１は、サーバ群２が提供するサービス（ネットワークゲームサービス及びメール交換サービス）を利用するために、各ユーザが使用するクライアント端末である。端末装置１としては、汎用のパーソナルコンピュータの他、インターネット３に接続する機能を有するビデオゲーム機を用いることもできる。端末装置１の構成については、詳細を後述する。

管理サーバ２１は、ユーザの会員登録のための処理や、会員登録されたユーザの認証のための処理などを行うためのサーバである。会員登録する際には、ユーザ名の登録が必要となるが、既に存在するユーザ名と全く同一のユーザ名は登録できないものとなっている。管理サーバ２１は、サーバ群２において提供するサービスのうちで、各ユーザが利用しているサービスの管理や、各ユーザのプロファイルの管理なども行う。

メールサーバ２２は、ユーザにメール交換サービスを提供する。このメール交換サービスにおいて利用できるメールアドレスには、会員登録したユーザ全てに与えられる標準メールアドレスと、拡張サービスを利用するユーザのみに与えられる拡張メールアドレス（詳細を後述）とがある。メールサーバ２２において、受信したメールを格納するためのメールボックスは、ユーザ毎に設けられており、同じユーザに宛てたメールであれば、宛先（"to"、"cc"または"bcc"）のメールアドレスに関わらず同一のメールボックスに格納される。

ゲームサーバ２３は、ユーザにネットワークゲームサービスを提供する。ゲームサーバ２３は、ユーザに提供しているネットワークゲーム毎に設けられている。複数のゲームサーバ２３が同一種類のネットワークゲームを提供することもあり、その違いはワールドという概念によって区別される。ユーザは、自分がプレイしているネットワークゲーム毎（或いはワールド毎）にキャラクタ名を設定することができ、また、任意に変更・削除することができる。

データベースサーバ２４は、サーバ群２の各サーバ２１〜２３により共通して使用されるデータを管理するためのサーバである。データベースサーバ２４で管理されているデータと同一内容のデータが、各サーバ２１〜２３においても管理されることもあるが、データベースサーバ２４で管理されているデータの方がオリジナルのデータとして扱われる。これらのサーバ２１〜２４の構成についても、詳細を後述する。

図２は、端末装置１の構成を示すブロック図である。ここでは、端末装置１としてビデオゲーム装置を適用した場合の構成を示している。汎用のパーソナルコンピュータを適用する場合でも、これと同様の機能を実現するものであればよい。図２に示すように、このビデオゲーム装置を適用した端末装置１は、その内部バス１１９に接続された制御部１０３、ＲＡＭ（Random Access Memory）１０５、ハードディスク・ドライブ（ＨＤＤ）１０７、サウンド処理部１０９、グラフィック処理部１１１、ＤＶＤ／ＣＤ−ＲＯＭドライブ１１３、通信インターフェイス１１５、及びインターフェイス部１１７を含む。

サウンド処理部１０９は、スピーカーであるサウンド出力装置１２５に、グラフィック処理部１１１は、表示画面１２２を有する表示装置１２１に接続されている。ＤＶＤ／ＣＤ−ＲＯＭドライブ１１３には、記録媒体（ＤＶＤ−ＲＯＭまたはＣＤ−ＲＯＭ）１３１を装着し得る。通信インターフェイス１１５は、ネットワーク（ここでは、インターネット３）に接続される。インターフェイス部１１７には、入力部（コントローラ）１６１とメモリカード１６２とが接続されている。

制御部１０３は、ＣＰＵ（Central Processing Unit）やＲＯＭ（Read Only Memory）などを含み、ＨＤＤ１０７や記録媒体１３１上に格納されたプログラムを実行し、端末装置１の制御を行う。制御部１０３は、内部タイマを備えている。ＲＡＭ１０５は、制御部１０３のワークエリアである。ＨＤＤ１０７は、プログラムやデータを保存するための記憶領域であり、後述するアカウント情報テーブルもここに保存される。サウンド処理部１０９は、制御部１０３により実行されているプログラムがサウンド出力を行うよう指示している場合に、その指示を解釈して、サウンド出力装置１２５にサウンド信号を出力する。

グラフィック処理部１１１は、制御部１０３から出力される描画命令に従って、フレームメモリ１１２に画像を展開し、表示装置１２１の表示画面１２２上に画像を表示するビデオ信号を出力する。出力されるビデオ信号に含まれる画像の１フレーム時間は、例えば３０分の１秒とする。ＤＶＤ／ＣＤ−ＲＯＭドライブ１１３は、記録媒体１３１に対しプログラム及びデータの読み書きを行う。通信インターフェイス１１５は、ネットワーク（インターネット３）に接続され、他のコンピュータとの通信を行う。

インターフェイス部１１７は、入力部１６１からの入力データをＲＡＭ１０５に出力し、制御部１０３がそれを解釈して演算処理を実施する。入力部１６１は、方向キー及び複数の操作ボタンを備え、方向キーの操作によりゲームにおいてプレイヤキャラクタを移動させ、操作ボタンの操作により所定の処理を行わせるものである。方向キーは、カーソルの移動やメッセージなどのためにも用いられ、操作ボタンは、所定の指示を入力するために用いられる。インターフェイス部１１７は、また、制御部１０３からの指示に基づいて、ＲＡＭ１０５に記憶されているゲームの進行状況を示すデータをメモリーカード１６２に保存させ、メモリーカード１６２に保存されている中断時のゲームのデータを読み出して、ＲＡＭ１０５に転送する。

端末装置１においてゲームを行い、またメール交換をするためのプログラム及びデータは、最初例えば記録媒体１３１に記憶されている。このプログラム及びデータは、実行時にＤＶＤ／ＣＤ−ＲＯＭドライブ１１３により読み出されて、ＲＡＭ１０５にロードされる。制御部１０３は、ＲＡＭ１０５にロードされたプログラム及びデータを処理し、描画命令をグラフィック処理部１１１に出力し、サウンド出力の指示をサウンド処理部１０９に出力する。制御部１０３が処理を行っている間の中間的なデータは、ＲＡＭ１０５に記憶される。

図３は、各サーバ２１〜２４の構成を示すブロック図である。図示するように、各々のサーバ２１〜２４は、内部バス２００に接続されたＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、通信インターフェイス２０５、キーボード・マウスインターフェイス２０６、ＨＤＤ２０７、ＤＶＤ／ＣＤ−ＲＯＭドライブ２０８、及びビデオインターフェイス２０９を含む。

キーボード・マウスインターフェイス２０６には、キーボード２１１とマウス２１２とが接続される。ビデオインターフェイス２０９には、ディスプレイ２１３が接続される。通信インターフェイス２０５は、外部のネットワークに接続される。通信インターフェイス２０５が接続されるネットワークとは、サーバ２１〜２３の場合にはＬＡＮ２５とインターネット３の両方を含み、データベースサーバ２４の場合にはＬＡＮ２５を含むものとする。ＤＶＤ／ＣＤ−ＲＯＭドライブ２０８には、記録媒体２２０を装着し得る。

ＣＰＵ２０１は、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０７などに格納されたプログラムを実行し、サーバ２１〜２４がそれぞれ提供するサービスの機能を実現する。ＲＯＭ２０２は、ＣＰＵ２０１のブートプログラムなどを格納する。ＲＡＭ２０３は、ＣＰＵ２０１が実行するプログラムの格納領域、データ領域、作業領域などとして用いられる。ＨＤＤ２０７は、ＤＶＤ／ＣＤ−ＲＯＭドライブ２０８が記録媒体２２０から転送したプログラムやデータなどを格納する。また、メールサーバ２２のＨＤＤ２０７であれば、例えば、会員登録されたユーザのメールボックスを格納する。

通信インターフェイス２０５は、ネットワーク（ＬＡＮ２５、インターネット３）に接続され、他のサーバ２１〜２４や端末装置１との間の通信を行う。キーボード・マウスインターフェイス２０６は、キーボード２１１からの入力データをＲＡＭ２０３に出力し、ＣＰＵ２０１がそれを解釈して演算処理を実行する。ビデオインターフェイス２０９は、ＣＰＵ２０１の処理結果である画像データにかかるビデオ信号をディスプレイ２１３に出力する。

次に、このネットワークシステムにおいてメールサーバ２２が提供するメール交換サービスを利用するために必要なデータについて説明する。メール交換サービスを利用するためには、アカウント情報が必要となり、また、ここでは拡張サービスとしてネットワークゲームにおいてユーザが使用しているキャラクタ名を拡張メールアドレスのメールアカウントとして利用できるため、このキャラクタ名の情報も必要となる。

図４（ａ）は、メールサーバ２２が提供するメール交換サービスを利用するために用いられるアカウント情報テーブルを示す図である。このアカウント情報テーブル３００は、メールサーバ２２と、データベースサーバ２４と、端末装置１とにそれぞれ格納されるが、データベースサーバ２４に格納されたものがオリジナルであり、メールサーバ２２及び端末装置１に格納されたものはコピーということとなる。

このアカウント情報テーブル３００には、ユーザＩＤ３０１、パスワード３０２、メールアドレス３０３、メールパスワード３０４、拡張メールアドレス３０５、拡張サービス可・不可フラグ３０６、ＰＯＰ（Post Office Protocol）サーバ名３０７、ＰＯＰサーバポート番号３０８、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ名３０９、ＳＭＴＰサーバポート番号３１０、及び最終更新日時３１１が登録される。

ユーザＩＤ３０１は、会員登録されたユーザ毎にユニークなＩＤであり、ユーザのログイン認証のために用いられる他、各種処理においてユーザを識別するためのキーとして用いられる。メールサーバ２２のメールボックスは、ユーザＩＤ３０１に対応づけて設けられている。パスワード３０２は、ユーザのログイン認証のために用いられるパスワードである。ユーザＩＤとパスワードに関しては、管理サーバ２１においても管理されている。

メールアドレス３０３は、会員登録されたユーザ全てに与えられる標準のメールアドレスであり、メールの受信要求を認証するための認証情報としても用いられるので、メールサーバ２２が提供するメール交換のサービスを受けるためには必要となる。メールアドレス３０３は、次に説明する拡張メールアドレス３０５と対比するため標準メールアドレスと呼ぶ場合がある。メールパスワード３０４は、メールサーバ２２のユーザのメールボックスに投函されたメールを読み出すためのパスワードであり、メールアドレス３０３とともにメールの受信要求を認証するための認証情報として用いられる。

拡張メールアドレス３０５は、ユーザがネットワークゲームで使用するキャラクタ名をメールアカウントとして標準メールアドレス３０３以外に利用することのできるメールアドレスである。この実施の形態では、拡張サービスの利用を登録したユーザだけが最大５個まで利用できる。拡張サービス可・不可フラグ３０６は、ユーザが拡張サービスの利用を登録し、これを利用できるようにしたか否かを示すフラグである。この実施の形態では、拡張サービスの利用ができる場合に、フラグがセットされる。

拡張メールアドレス３０５は、キャラクタ情報テーブル３５０に登録された情報から生成されるものであり、その形式は、
キャラクタ名＠（ワールド名．）コンテンツ名．ｐｏｌ．ｃｏｍ
となり、ドメイン名の中にはネットワークゲーム名（及びワールド名）が含まれるものとなる。

一方、標準メールアドレス３０３の形式は、
ユーザ名＠ｐｏｌ．ｃｏｍ
となる。メールサーバ２２には、ドメインの最後に“ｐｏｌ．ｃｏｍ”を含むメールがインターネット３からメールサーバ２２に送られてくる。

ＰＯＰサーバ名３０７及びＰＯＰサーバポート番号３０８は、それぞれＰＯＰサーバの名称（アドレス）及びポート番号を示す。ＳＭＴＰサーバ名３０９及びＳＭＴＰサーバポート番号３１０は、それぞれＳＭＴＰサーバの名称（アドレス）及びポート番号を示す。最終更新日時３１１は、メールサーバ２２、データベースサーバ２４、端末装置１においてそれぞれアカウント情報テーブル３００が最後に更新された日時を示す。最終更新日時３１１は、メールサーバ２２及び端末装置１のアカウント情報テーブル３００をオリジナルのデータベースサーバ２４のアカウント情報テーブル３００と整合させるために用いられる。

図４（ｂ）は、拡張メールアドレスのメールアカウントとしてキャラクタ名を利用するために用いられるキャラクタ情報テーブルを示す図である。このキャラクタ情報テーブル３５０は、データベースサーバ２４とメールサーバ２２とにそれぞれ格納されるが、データベースサーバ２４に格納されたものがオリジナルであり、メールサーバ２２に格納されたものはコピーということとなる。

このキャラクタ情報テーブル３５０には、ユーザＩＤ３５１、コンテンツ名３５２、キャラクタ名３５３、及びワールド名３５４が登録される。ユーザＩＤ３５１は、ユーザＩＤ３０１と同じユーザを識別するためのキーとして用いられる。コンテンツ名３５２は、ネットワークゲームの名称を示す。ワールド名３５４は、同一種類のネットワークゲームを提供するゲームサーバ２３が複数ある場合において、どのゲームサーバ２３が提供するゲームであるかを示す。同一種類のネットワークゲームを提供するゲームサーバ２３が１つであれば、ワールド名３５４は登録されない。キャラクタ名３５３は、ネットワークゲーム（のワールド）において、ユーザが使用するキャラクタの名称である。

次に、拡張メールアドレスの設定について説明する。ユーザが拡張メールアドレスを利用しようとするときは、まずサーバ群２が提供するサービスに対して拡張サービスの利用登録をしなければならない。拡張サービスの利用を開始する場合は、端末装置１から管理サーバ２１にアクセスし、拡張サービスの開始を要求する。すると、管理サーバ２１は、データベースサーバ２４に拡張サービスの開始を通知し、データベースサーバ２４のアカウント情報テーブル３００の拡張サービス可・不可フラグ３０６がセットされる。拡張サービスの利用を終了する場合の手順も同様で、拡張サービス可・不可フラグ３０６がリセットされる。

拡張サービスの利用登録をした（拡張サービス可・不可フラグ３０６がセットされている）ユーザは、拡張メールアドレスを使用することができることとなる。なお、この実施の形態では、拡張サービスを利用登録していても拡張メールアドレスを設定するようにしていないので、拡張メールアドレスの設定を行う必要がある。

拡張メールアドレスの設定を行う場合、ユーザが端末装置１において拡張サービスのメニュー画面からサービス内容として拡張メールアドレス選択すると、図５に示す拡張メールアドレス設定開始画面４１０が表示画面１２２として表示される。この拡張メールアドレス設定開始画面４１０において、ユーザが入力部１６１の方向キーの操作により「確認・設定」ボタン４１１にカーソル４１２を合わせ、所定のボタンの操作により「確認・設定」についての確定入力を行うと、拡張アドレスの設定要求が管理サーバ２１を介してメールサーバ２２に送られる。

これに対して、アカウント情報テーブル３００に設定されている拡張メールアドレス３０５とキャラクタ情報テーブル３５０の登録内容とに基づいて生成された拡張メールアドレスの設定ページが返送されるものとなる。そして、図６に示す拡張メールアドレス設定画面４２０が表示画面１２２として表示される。拡張メールアドレス設定画面４２０では、拡張メールアドレスとして利用可能な候補アドレス４２１ａ〜４２１ｆが表示され、それぞれにチェックボックス４２２が付加される。チェックマークの付されているものが、現在設定されている拡張メールアドレスである。

ユーザは、カーソル４２３を所望の候補アドレス４２１ａ〜４２１ｆに合わせ、チェックボックス４２２にチェックマークを付加／削除することで、拡張メールアドレスとして利用するアドレスを選択する。選択を確定させる場合は、「確認」ボタン４２４にカーソル４２３を合わせ、確定入力を行うと、拡張メールアドレスの設定内容がメールサーバ２２に通知される。

この拡張メールアドレスの設定内容の通知に基づいて、データベースサーバ２４及びメールサーバ２２にそれぞれ格納されたアカウント情報テーブル３００が更新されると、拡張メールアドレスの設定完了ページが返送されるものとなる。そして、図７（ａ）に示す拡張メールアドレス設定完了画面４３０が表示画面１２２として表示される。この設定完了ページは、図７（ｂ）に示すようにマークアップ言語で記述されているもので、特別な制御タグ４３３が含まれている。

この制御タグ４３３を認識することにより、端末装置１ではデータベースサーバ２４及びメールサーバ２２においてアカウント情報テーブル３００が更新されたことを認識することができる。そこで、内部に格納しているアカウント情報テーブル３００と登録内容を確実に整合させるため、端末装置１では、制御タグ４３３を認識したときには自動的にアカウント情報の送信をデータベースサーバ２４に要求し（この実施の形態では、メールサーバ２２を介して）、これに対して送られてくるアカウント情報に基づいて、内部に格納しているアカウント情報テーブル３００を更新する。また、データベースサーバ２４、メールサーバ２２、及び端末装置１のそれぞれに格納しているアカウント情報テーブル３００の整合性を図るための処理は、端末装置１がサーバ群２が提供するサービスにログインするとき、また、定期的にも行われている。

この実施の形態では、メールサーバ２２においては、メールボックスをメールアドレス毎に用意せずに、ユーザ毎に用意するようにしている。従って、拡張メールアドレスが設定されても、当該拡張メールアドレス用にメールボックスを用意する必要がない。メールサーバ２２では、メールが送られてきたときには、当該メールの宛先アドレス（標準メールアドレスまたは拡張メールアドレス）に対応してアカウント情報テーブル３００に登録されているユーザＩＤ３０１を抽出し、抽出したユーザＩＤに対応するメールボックスに当該メールを投函する。

また、拡張メールアドレスの設定は、ユーザが任意の時点において任意に行うことができるため、他のユーザから受信したメールに対して返信する際には、当該受信したメールで宛先とされている拡張メールアドレスが利用できなくなっている場合も存在する。そこで、端末装置１において、他のユーザから受信したメールに対して返信するときには、送信元アドレスを現在利用可能としているメールアドレスに設定して、メールを生成するものとする。

以下、この実施の形態に適用されるネットワークシステムにおける処理について説明する。サーバ群２のゲームサーバ２３は、ネットワークゲームのサービスを提供しているが、ここでは、メールサーバ２２が提供するメール交換サービスに関連するゲームサーバ２３の処理を中心として説明する。もっとも、ネットワークゲームにおいてユーザが使用するキャラクタ名は、メールアドレスのメールアカウントとして使用できるものとなる。

ユーザが新たにネットワークゲームに参加するとき、当該ゲームでのキャラクタ名を設定することとなるが、この新規参加時のキャラクタ名の設定処理は、次に示すように任意のタイミングでキャラクタ名を変更するときの処理とほぼ同じである。もっとも、ゲームサーバ２３は、提供しているネットワークゲーム（或いはワールド）について新たなユーザの参加があったときには、適当なキャラクタ名を当該ユーザに割り振って、デフォルトで使用させるものとしてもよい。

図８は、この実施の形態にかかるキャラクタ名の変更・削除処理を示す流れ図である。このキャラクタ名変更・削除処理は、端末装置１と、ゲームサーバ２３と、データベースサーバ２４との間で行われるものとなる。

ユーザは、まず、端末装置１から変更または削除しようとしているキャラクタ名のネットワークゲーム（或いはワールド）を提供するゲームサーバ２３に接続する。ユーザは、このゲームサーバ２３が提供するネットワークゲームの機能により入力部１６１から所定の入力を行い、キャラクタ名を指定して、その変更または削除を指示する。キャラクタ名を変更する場合は、変更後のキャラクタ名も指定する。この指示は、制御部１０３によりインターネット３を介してゲームサーバ２３に送られる（ステップＳ１０１）。ここで、端末装置１は、ゲームサーバ２３からの通知の受信待ちとなる。

ゲームサーバ２３では、キャラクタ名の変更または削除の指示を端末装置１から受け取ると、ゲームサーバ２３のＣＰＵ２０１は、その指示がキャラクタ名の変更であるか削除であるかを判定する（ステップＳ１０２）。キャラクタ名の削除であった場合には、ＣＰＵ２０１は、当該ゲームサーバ２３に関して指定されたキャラクタ名を有するキャラクタ情報テーブル３５０を削除するように、ＬＡＮ２５を介してデータベースサーバ２４に依頼する。データベースサーバ２４のＣＰＵ２０１は、この依頼に基づいて、対応するキャラクタ情報テーブル３５０を削除する（ステップＳ１０３）。これで、キャラクタ名の削除が終了する。

また、端末装置１からの指示がキャラクタ名の変更であった場合には、ゲームサーバ２３のＣＰＵ２０１は、ＬＡＮ２５を介してデータベースサーバ２４にアクセスし、当該ゲームサーバ２３の提供するネットワークゲームについて登録されている全てのキャラクタ名をデータベースサーバ２４に要求する。データベースサーバ２４のＣＰＵ２０１は、この要求に基づいて、当該ゲームサーバ２３についてキャラクタ情報テーブル３５０に登録されている全てのキャラクタ名を取得し、ＬＡＮ２５を介して要求元のゲームサーバ２３に返送する（ステップＳ１０４）。

次に、ゲームサーバ２３のＣＰＵ２０１は、指定された変更後のキャラクタ名をデータベースサーバ２４から送られてきたキャラクタ名と比較し、指定された変更後のキャラクタ名が当該ゲームサーバ２３が提供するネットワークゲームにおいて唯一のものとなっているかどうかを判定する（ステップＳ１０５）。唯一のものであった場合には、ＣＰＵ２０１は、キャラクタ情報テーブル３５０の変更前のキャラクタ名を変更後のキャラクタ名に更新するように、ＬＡＮ２５を介してデータベースサーバ２４に依頼する。データベースサーバ２４のＣＰＵ２０１は、この依頼に基づいて、対応するキャラクタ情報テーブル３５０を更新する（ステップＳ１０６）。

データベースサーバ２４においてキャラクタ情報テーブル３５０の更新が行われると、ゲームサーバ２３のＣＰＵ２０１は、完了通知をインターネット３を介して端末装置１に返送する（ステップＳ１０７）。また、指定された変更後のキャラクタ名が当該ゲームサーバ２３が提供するネットワークゲームにおいて既に存在していた場合には、ゲームサーバ２３のＣＰＵ２０１は、再指定通知をインターネット３を介して端末装置１に返送する（ステップＳ１０８）。

ゲームサーバ２３からの通知の受信待ちとなっていた端末装置１では、制御部１０３は、ゲームサーバ２３からの通知を受信したときに、その通知が再指定通知であったか完了通知であったかを判定する（ステップＳ１０９）。再指定通知であった場合には、制御部１０３は、再びステップＳ１０１から処理をやり直させる。完了通知であった場合には、これでキャラクタ名の変更が完了となる。このようにキャラクタ名を変更することにより、ユーザは、変更したキャラクタ名を使ってネットワークゲームを行うことができるようになる。

こうしてネットワークゲームにおいてユーザが使用しているキャラクタ名は、メールサーバ２２が提供するメール交換サービスにおいてメールアドレスのメールアカウントとして使用できるようになるが、この実施の形態では、このメール交換サービスにおける拡張サービスを利用することをユーザが設定する必要がある。また、ユーザがこの拡張サービスの利用を停止することも任意に設定できることが好ましい。

図９は、この実施の形態にかかる拡張サービス開始・停止処理を示す流れ図である。この拡張サービス開始・停止処理は、端末装置１と、管理サーバ２１と、データベースサーバ２４との間で行われるものとなる。

ユーザは、入力部１６１から所定の入力を行い、拡張サービスの利用開始または利用停止を指示する。制御部１０３は、拡張サービス利用開始または利用停止の指示通知を通信インターフェイス１１５からインターネット３を介して管理サーバ２１に送信させる（ステップＳ２０１）。

管理サーバ２１のＣＰＵ２０１は、端末装置１からの拡張サービスの利用開始または利用停止の指示通知に基づいて、ＬＡＮ２５を介してデータベースサーバ２４に指示を送り、当該ユーザに関してデータベースサーバ２４に格納されているアカウント情報テーブル３００の拡張サービス可・不可フラグ３０６をセット（利用開始の場合）またはリセット（利用停止の場合）させる（ステップＳ２０２）。管理サーバ２１のＣＰＵ２０１は、拡張サービス可・不可フラグ３０６のセットまたはリセットが行われると、通信インターフェイス２０５からインターネット３を介して端末装置１に手続完了通知を送信する（ステップＳ２０３）。これで、拡張サービス開始・停止処理を終了する。

この処理によって拡張サービスの利用が設定されているときに、ユーザはキャラクタ名をメールアカウントとした拡張メールアドレスを使用することができるようになる。この実施の形態では、拡張サービスを利用しているだけで拡張メールアドレスを使用できるものではなく、ユーザが使用する拡張メールアドレスの設定を別に行う必要がある。また、キャラクタ名の変更や新たなネットワークゲームへの参加などに伴って、一度設定した拡張メールアドレスも、任意に変更できるようにしておくことが好ましい。

図１０は、この実施の形態にかかる拡張メールアドレス設定処理を示す流れ図である。この処理は、この拡張メールアドレス設定処理は、端末装置１と、管理サーバ２１と、メールサーバ２２と、データベースサーバ２４との間で行われるものとなる。

まず、ユーザは、拡張サービスのメニュー画面が表示された状態で、入力部１６１を操作することによりサービス内容として拡張メールアドレスを選択すると、管理サーバ２１から拡張メールアドレスの設定開始ページが送られてくる。制御部１０３は、この設定開始ページに基づいて、図５に示した拡張メールアドレス設定開始画面４１０を表示画面１２２として表示させる（ステップＳ３０１）。

ユーザは、表示された拡張メールアドレス設定開始画面４１０において、入力部１６１の方向キーの操作により「確認・設定」ボタン４１１にカーソル４１２を合わせ、入力部１６１の所定のボタンの操作により確定入力を行うと、制御部１０３は、拡張メールアドレスの設定要求を、通信インターフェイス１１５からインターネット３を介して管理サーバ２１に送信させる（ステップＳ３０２）。管理サーバ２１は、この拡張メールアドレスの設定要求を、ＬＡＮ２５を介してメールサーバ２２に転送する（ステップＳ３０３）。

メールサーバ２２では、拡張メールアドレスの設定要求を受信すると、ＣＰＵ２０１は、当該要求をしたユーザについて、メールサーバ２２のアカウント情報テーブル３００に現在設定されている拡張メールアドレスを取得するとともに、メールサーバ２２のキャラクタ情報テーブル３５０に登録されているキャラクタ名により当該ユーザが設定可能な拡張メールアドレスを取得する。メールサーバ２２のＣＰＵ２０１は、これら現在設定されている、または設定可能な拡張メールアドレスを、通信インターフェイス２０５からＬＡＮ２５を介して管理サーバ２１に返却する（ステップＳ３０４）。

管理サーバ２１では、ＣＰＵ２０１は、メールサーバ２２から返却された現在設定されている、または設定可能な拡張メールアドレスに基づいて、拡張メールアドレスの設定ページを生成し（ステップＳ３０５）、これを通信インターフェイス２０５からインターネット３を介して要求元の端末装置１に送信する（ステップＳ３０６）。端末装置１では、制御部１０３は、管理サーバ２１から送られた設定ページに基づいて、図６に示した拡張メールアドレス設定画面４２０を表示画面１２２として表示させる（ステップＳ３０７）。

ユーザは、拡張メールアドレス設定画面４２０において、入力部１６１の操作により拡張メールアドレスとして設定するアドレスを候補アドレス４２１ａ〜４２１ｆの中から選択する。より具体的に説明すると、現在拡張メールアドレスとして設定されている候補アドレスには、チェックボックス４２２にチェックマークが付加されている。これを拡張メールアドレスの設定から外す場合には、当該候補アドレスにカーソル４２３を合わせ、チェックマークを削除すればよい。また、新たな拡張メールアドレスを設定する場合には、対応する候補アドレスにカーソル４２３を合わせ、チェックマークを付加すればよい（ステップＳ３０８）。

拡張メールアドレス設定画面４２０において、ユーザが「確認」ボタン４２４にカーソル４２３を合わせ、入力部１６１から確定入力を行うと、制御部１０３は、新たな拡張メールアドレスの設定内容を、通信インターフェイス１１５からインターネット３を介してメールサーバ２２に通知させる（ステップＳ３０９）。メールサーバ２２は、この設定内容通知を、ＬＡＮ２５を介してデータベースサーバ２４に転送する（ステップＳ３１０）。

データベースサーバ２４では、メールサーバ２２から拡張メールアドレスの設定内容が通知されると、ＣＰＵ２０１は、これに基づいて内部に格納しているアカウント情報テーブル３００の拡張メールアドレス３０５の登録を更新する（ステップＳ３１１）。アカウント情報テーブル３００が更新されると、このアカウント情報の更新内容がデータベースサーバ２４からＬＡＮ２５を介してメールサーバ２２に送信される（ステップＳ３１２）。

メールサーバ２２では、ＣＰＵ２０１は、データベースサーバ２４から送られてきたアカウント情報の更新内容に従って、メールサーバ２２のアカウント情報テーブル３００を更新する（ステップＳ３１３）。アカウント情報テーブル３００の更新が終了すると、ＣＰＵ２０１は、アカウント情報の設定完了通知を通信インターフェイス２０５からＬＡＮ２５を介して管理サーバ２１に送信する（ステップＳ３１４）。

管理サーバ２１では、ＣＰＵ２０１は、メールサーバ２２から送信された設定完了通知に基づいて、拡張メールアドレスの設定完了ページを生成し（ステップＳ３１５）、これを通信インターフェイス２０５からインターネット３を介して要求元の端末装置１に送信する（ステップＳ３１６）。端末装置１では、制御部１０３は、管理サーバ２１から送られた設定完了ページに基づいて、図７（ａ）に示した拡張メールアドレス設定完了画面４３０を表示画面１２２として表示させる（ステップＳ３１７）。

ところで、この設定完了ページには、図７（ｂ）に示したように制御タグ４３３が含まれている。制御部１０３は、この制御タグ４３３を認識すると、アカウント情報の送信要求を通信インターフェイス１１５からインターネット３を介してメールサーバ２２に送信する（ステップＳ３１９）。メールサーバ２２は、このアカウント情報の送信要求をＬＡＮ２５を介してデータベースサーバ２４に転送する（ステップＳ３２０）。

データベースサーバ２４のＣＰＵ２０１は、このアカウント情報の送信要求に対して、当該ユーザについてのアカウント情報テーブル３００に登録されたアカウント情報を読み出し、これをメールサーバ２２に返送する（ステップＳ３２１）。メールサーバ２２は、データベースサーバ２４から送られてきたアカウント情報を端末装置１に送信する（ステップＳ３２２）。端末装置１の制御部１０３は、データベースサーバ２４からメールサーバ２２を介して送られてきたアカウント情報を受信すると、受信したアカウント情報に従って、内部に格納しているアカウント情報テーブルを更新する（ステップＳ３２３）。これで、拡張メールアドレス設定処理が終了となる。

この拡張メールアドレス設定処理において、データベースサーバ２４、メールサーバ２２、及び端末装置１のそれぞれにおけるアカウント情報テーブル３００の整合が図られているが、ユーザが利用する端末装置１を変えた場合には、新たに使用する端末装置１には正しい内容のアカウント情報テーブル３００が格納されていないこととなる。

また、ユーザが拡張サービスの利用を停止した後にも、キャラクタ名をメールアカウントとした拡張メールアドレスが、アカウント情報テーブル３００に格納されたままとなっていることもある。さらに、ユーザがキャラクタ名を変更・削除したときなどには、使用されなくなったキャラクタ名をメールアカウントとした拡張メールアドレスが、アカウント情報テーブル３００に格納されたままとなっていることもある。そこで、この実施の形態においては、次の図１１及び図１２に示すような処理も行われるものとなる。

図１１は、この実施の形態にかかる端末ログイン処理を示す流れ図である。この端末ログイン処理は、端末装置１と、管理サーバ２１と、メールサーバ２２との間で行われるものとなる。サーバ群２が提供するサービスをユーザが利用しようとする場合、管理サーバ２１にアクセスしてユーザ認証を受ける必要があるため、管理サーバ２１の処理も必要となる。

端末装置１において、ユーザが入力部１６１を操作してサーバ群２が提供するサービスへのログインを指示すると、制御部１０３は、端末装置１内のアカウント情報テーブル３００からユーザＩＤ３０１とパスワード３０２とを読み出す。あるいは、ユーザが入力部１６１を操作して、ユーザＩＤとパスワードを直接入力する。制御部１０３、これらのユーザＩＤとパスワードとともにログイン要求を、通信インターフェイス１１５からインターネット３を介して管理サーバ２１に送信させる（ステップＳ４０１）。

管理サーバ２１のＣＰＵ２０１は、ログイン要求とともに送られてきたユーザＩＤ及びパスワードを、内部で管理しているユーザＩＤ及びパスワードと照合して、ユーザ認証を行う。その結果、送られてきたユーザＩＤ及びパスワードと同じものが照合されたかどうかにより、ユーザ認証がされたかどうかを判定する（ステップＳ４０２）。ユーザ認証がされなければ、ログインを拒否して、処理終了となる。

ユーザ認証がされた場合には、端末装置１の制御部１０３は、ログイン要求に使用したユーザＩＤと同じユーザＩＤを含むアカウント情報テーブル３００が当該端末装置１内に記憶されているかどうかを判定する（ステップＳ４０３）。ここで、ユーザが新たな端末装置１からログイン要求した場合や、他のユーザの端末装置１を借りてログイン要求した場合には、当該ログイン要求をした端末装置１には、同じユーザＩＤを含むアカウント情報テーブルが記憶されていないこととなる。

同じユーザＩＤを含むアカウント情報テーブル３００が端末装置１内に記憶されていれば、メールサーバ２２のアカウント情報テーブル３００に登録されている最終更新日時３１１の送信を管理サーバ２１に要求し（ステップＳ４０４）、さらに管理サーバ２１からメールサーバ２２に要求する（ステップＳ４０５）。この要求は、データベースサーバ２４に対して行うものとしてもよい。

メールサーバ２２のＣＰＵ２０１は、管理サーバ２１からの要求に基づいて、当該ユーザＩＤに対応するアカウント情報テーブル３００に登録された最終更新日時３１１を読み出し、ＬＡＮ２５を介して管理サーバ２１に返送する（ステップＳ４０６）。管理サーバ２１のＣＰＵ２０１は、メールサーバ２２から返送された最終更新日時３１１を含めばよい）を、通信インターフェイス２０５からインターネット３を介して要求元の端末装置１に送信する（ステップＳ４０７）。

端末装置１では、制御部１０３は、メールサーバ２２からアカウント情報テーブル３００の最終更新日時３１１を受信すると、端末装置１内のアカウント情報テーブル３００に登録されているユーザＩＤと比較する。その比較の結果、制御部１０３は、最終更新日時が一致したかどうかを判定する（ステップＳ４０８）。ここで、ユーザがキャラクタ名を変更・削除するなどして、図１２の処理においてメールサーバ２２及びデータベースサーバ２４のアカウント情報テーブル３００が更新された場合には、最終更新日時が一致しないこととなる。

同じユーザＩＤを含むアカウント情報テーブル３００が記憶されていなかった場合や、最終更新日時が一致しなかった場合には、端末装置１の制御部１０３は、通信インターフェイス１１５からインターネット３を介してメールサーバ２２にアカウント情報の送信を要求する（ステップＳ４０９）。この要求も、データベースサーバ２４に対して行うものとしてもよい。メールサーバ２２のＣＰＵ２０１は、端末装置１からの要求に基づいて、内部のアカウント情報テーブル３００に登録されているアカウント情報を全て読み出し、通信インターフェイス２０５からインターネット３を介して要求元の端末装置１に返送する（ステップＳ４１０）。

端末装置１では、メールサーバ２２からアカウント情報を受信すると、制御部１０３は、受信したアカウント情報を、内部のアカウント情報テーブル３００として記憶させる。元々アカウント情報テーブル３００が記憶されていたときには、メールサーバ２２から受信したアカウント情報に更新して記憶させる（ステップＳ４１１）。これで、ログイン処理が終了となり、ユーザは、サーバ群２が提供するサービスを利用できることとなる。。なお、アカウント情報テーブル３００の最終更新日時３１１が一致していた場合には、そのままログイン処理が終了となり、ユーザは、サーバ群２が提供するサービスを利用できる。

図１２は、この実施の形態にかかるアカウント情報更新処理を示す流れ図である。このアカウント情報更新処理は、メールサーバ２２のＣＰＵ２０１の内部タイマにより所定時間毎に生じるタイマ割り込みによって、行われるものとなる。また、このアカウント情報更新処理は、拡張サービスの利用を停止したユーザの拡張メールアドレスや、ユーザによって使用されていないキャラクタ名をメールアカウントとした拡張メールアドレスを排除し、メールサーバ２２とデータベースサーバ２４のアカウント情報テーブル３００の登録内容を整合させるために、これら２つのサーバ２２、２４の間で行われるものである。

メールサーバ２２のＣＰＵ２０１は、ＬＡＮ２５を介してデータベースサーバ２４に所定の指示を送り、データベースサーバ２４に記憶されている全てのキャラクタ情報テーブル３５０を取得し、例えばＨＤＤ２０７の作業領域に一時保存する（ステップＳ５０１）。ここで、メールサーバ２２には元々記憶されていたキャラクタ情報テーブル３５０もあるため、両者を区別するため、元々記憶されていたものを保存キャラクタ情報、データベースサーバ２５から取得したものを取得キャラクタ情報と呼ぶものとする。

次に、ユーザＩＤを順次処理対象としていきながら、まだ処理対象としていないユーザＩＤがあれば（ステップＳ５０２）、メールサーバ２２のＣＰＵ２０１は、ＬＡＮ２５を介してデータベースサーバ２４に当該ユーザＩＤとともに所定の指示を送り、データベースサーバ２４から当該ユーザＩＤに対応するアカウント情報テーブル３００に記憶されたアカウント情報を取得し、ＲＡＭ２０３に一時保存する（ステップＳ５０３）。

メールサーバ２２のＣＰＵ２０１は、このデータベースサーバ２４から取得したアカウント情報の拡張サービス可・不可フラグ３０６がセットされているかどうか、すなわち処理対象のユーザＩＤに対応するユーザが拡張サービスを利用しているものとなっているかどうかを判定する（ステップＳ５０４）。ユーザが拡張サービスを利用していれば、当該ユーザＩＤに対応する保存キャラクタ情報と取得キャラクタ情報とを比較し、両者が一致するかどうかを判定する（ステップＳ５０５）。両者が一致すれば、ステップＳ５０２の処理に戻る。

処理対象のユーザＩＤに対応した保存キャラクタ情報と取得キャラクタ情報とが一致しない場合、一致していないキャラクタに対応した拡張メールアドレスをＲＡＭ２０３に一時保存したアカウント情報から削除する。また、ステップＳ５０４において拡張サービス可・不可フラグがリセットされていた場合には、全ての拡張メールアドレスをＲＡＭ２０３に一時保存したアカウント情報から削除する（ステップＳ５０６）。

その後、メールサーバ２２のＣＰＵ２０１は、ＲＡＭ２０３に一時保存しているアカウント情報に、内部に記憶しているアカウント情報テーブル３００の内容を更新する（ステップＳ５０７）。また、ＬＡＮ２５を介してＲＡＭ２０３に一時保存しているアカウント情報をデータベースサーバ２４に返送し、データベースサーバ２４に記憶されているアカウント情報テーブル３００の内容を更新させる（ステップＳ５０８）。

こうして全てのユーザＩＤを処理対象としてアカウント情報テーブル３００の更新が終了すると（ステップＳ５０２）、メールサーバ２２のＣＰＵ２０１は、内部に記憶していたキャラクタ情報テーブル３５０をステップＳ５０１でデータベースサーバ２４から取得したキャラクタ情報テーブル３５０の内容に全て更新する（ステップＳ５０９）。これで、アカウント情報更新処理が終了となる。

メールサーバ２２が提供するメール交換サービスにおいて、ユーザは、上記のようにして設定された拡張メールアドレスを使用して、或いは拡張サービスの利用の有無に関わらずユーザ毎に与えられた標準メールアドレスを使用して、メールを送受信することができる。ここで、いずれかの端末装置１からメールサーバ２２に送られてきたメールを適切なメールボックスに格納する処理と、ユーザが自分のメールボックスに格納されたメールを読み出す処理とが行われるものとなる。

図１３は、この実施の形態にかかるメール格納処理を示す流れ図である。このメール格納処理は、メールサーバ２２がインターネット３を介していずれかの端末装置１から送られてきたメールを受信したときに当該メールの送信先アドレスに対応した適切なメールボックスに格納するために行われる処理であり、メールサーバ２２において単独で行われる処理である。

まず、インターネット３を介して送られてきたメールを通信インターフェイス２０５が受信すると、ＣＰＵ２０１は、これをＲＡＭ２０３の所定の領域に一時保存させる（ステップＳ６０１）。ＣＰＵ２０１は、受信したメールの宛先の＠以下を調べ、当該宛先のアドレスが標準メールアドレスとなっているかどうかを判定する（ステップＳ６０２）。

宛先が標準メールアドレスであった場合には、ＣＰＵ２０１は、メールサーバ２２に格納されているアカウント情報テーブル３００を調べ、当該標準メールアドレスに対応するユーザＩＤを検索する（ステップＳ６０３）。ＣＰＵ２０１は、この検索の結果としてユーザＩＤが抽出されたかどうかを判定する（ステップＳ６０４）。ユーザＩＤが抽出された場合には、ＣＰＵ２０１は、当該ユーザＩＤに対応したメールボックスに受信したメールを格納する（ステップＳ６０５）。そして、メール格納処理を終了する。一方、ユーザＩＤが抽出されなかった場合には、ＣＰＵ２０１は、所定のエラー処理（従来と同じ）を行う（ステップＳ６０６）。そして、メール格納処理を終了する。

宛先が拡張メールアドレスであった場合には、ＣＰＵ２０１は、メールサーバ２２に格納されているアカウント情報テーブル３００を調べ、当該拡張メールアドレスに対応するユーザＩＤを検索する（ステップＳ６０７）。ＣＰＵ２０１は、この検索の結果としてユーザＩＤが抽出されたかどうかを判定する（ステップＳ６０８）。ユーザＩＤが抽出された場合には、ＣＰＵ２０１は、当該ユーザＩＤに対応したメールボックスに受信したメールを格納する（ステップＳ６０９）。そして、メール格納処理を終了する。一方、ユーザＩＤが抽出されなかった場合には、ＣＰＵ２０１は、所定のエラー処理（従来と同じ）を行う（ステップＳ６１０）。そして、メール格納処理を終了する。

なお、受信したメールの宛先に複数のアドレスが設定されている場合には、ＣＰＵ２０１は、それぞれの宛先について、ステップＳ６０２〜Ｓ６１１の処理を行うものとすればよい。また、受信したメールの宛先として同じユーザのメールアドレスが複数設定されていると、異なるメールアドレスから同一のユーザＩＤを検索できることとなる。この場合には、それぞれのメールアドレスに対してメールボックスへメールを格納してもよく、当該ユーザＩＤに対して１つだけメールボックスへメールを格納するものとしてもよい。

図１４は、この実施の形態にかかるメール取得処理を示す流れ図である。このメール取得処理は、端末装置１とメールサーバ２２との間で行われるものとなる。

端末装置１において、ユーザが入力部１６１の操作によりメールの受信を指示すると、制御部１０３は、端末装置１のアカウント情報テーブル３００に登録されている標準メールアドレス３０３とメールパスワード３０４とを取得し、これらとともにメールの受信要求を通信インターフェイス１１５からインターネット３を介してメールサーバ２２に送信する（ステップＳ７０１）。

メールサーバ２２では、通信インターフェイス２０５が端末装置１からのメールの受信要求を受信すると、ＣＰＵ２０１は、この受信要求とともに送られてきたメールアドレス及びメールパスワードを、メールサーバ２２に格納されているアカウント情報テーブル３００に登録されている標準メールアドレス３０３及びメールパスワード３０４と照合する。その結果、ＣＰＵ２０１は、同一のものが登録されていたかどうかにより、当該メールの受信要求が認証されたかどうかを判定する（ステップＳ７０２）。

当該メールの受信要求が認証された場合には、ＣＰＵ２０１は、その標準メールアドレスに対応してアカウント情報テーブル３００に登録されているユーザＩＤ３０１を検索して、抽出する（ステップＳ７０３）。ＣＰＵ２０１は、抽出したユーザＩＤに対応するメールボックスに格納されているメールを全て取得し（ステップＳ７０４）、通信インターフェイス２０５からインターネット３を介して要求元の端末装置１に送信する（ステップＳ７０５）。

端末装置１では、通信インターフェイス１１５がメールサーバ２２から送られてきたメールを受信すると、制御部１０３は、これを例えばＨＤＤ１０７の所定の領域に格納する（ステップＳ７０６）。また、制御部１０３は、グラフィック処理部１１１との協働動作により、受信したメールを表示装置１２１の表示画面１２２に表示させる（ステップＳ７０７）。そして、メール取得処理を終了する。また、ステップＳ７０２でメールの受信要求が認証されなかった場合には、所定のエラー処理を行った後（ステップＳ７０８）、端末装置１にメールを送信することなくメール取得処理を終了する。

ユーザは、上記のようにして自己の標準メールアドレスまたは拡張メールアドレスに宛てられたメールを取得するものとなる。もっとも、拡張サービスの利用停止や利用する拡張メールアドレスの変更によって、拡張メールアドレスが送信元となっているメールに返信する際には、既に返信先の拡張メールアドレスがなくなっているという不都合も起こりえる。そこで、この実施の形態では、このような不都合を回避して、メールの返信を行うことができるようにしている。

図１５は、この実施の形態にかかるメール返信処理を示す流れ図である。このメール返信処理は、端末装置１において受信したメールに対して、ユーザが返信メールの作成を指示したときに行われる処理であり、端末装置１において単独で行われる処理である。なお、以下の説明において、返信メールを作成する対象となる先に受信したメールのことを、元メールと呼ぶものとする。

元メールに対して返信メールの作成が指示されると、制御部１０３は、元メールの送信元"from"のメールアドレスを返信メールの宛先"to"のメールアドレスに設定する（ステップＳ８０１）。次に、制御部１０３は、元メールの宛先"to"に設定されていたメールアドレスが、端末装置１のアカウント情報テーブル３００に拡張メールアドレス３０５として登録されているかどうかを判定する（ステップＳ８０２）。"to"のメールアドレスが拡張メールアドレス３０５として登録されていれば、制御部１０３は、元メールの宛先"to"のメールアドレスを返信メールの送信元"from"のメールアドレスに設定して（ステップＳ８０３）、ステップＳ８０９の処理に進む。

"to"のメールアドレスが拡張メールアドレス３０５として登録されていなければ、制御部１０３は、元メールの宛先"cc"に設定されていたメールアドレスが、端末装置１のアカウント情報テーブル３００に拡張メールアドレス３０５として登録されているかどうかを判定する（ステップＳ８０４）。"cc"のメールアドレスが拡張メールアドレス３０５として登録されていれば、制御部１０３は、元メールの宛先"cc"のメールアドレスを返信メールの送信元"from"のメールアドレスに設定して（ステップＳ８０５）、ステップＳ８０９の処理に進む。なお、元メールの宛先として"cc"がなければ"cc"のメールアドレスが拡張メールアドレス３０５として登録されていないものと判定される。

"cc"のメールアドレスが拡張メールアドレス３０５として登録されていなければ、制御部１０３は、元メールの宛先"bcc"に設定されていたメールアドレスが、端末装置１のアカウント情報テーブル３００に拡張メールアドレス３０５として登録されているかどうかを判定する（ステップＳ８０６）。"bcc"のメールアドレスが拡張メールアドレス３０５として登録されていれば、制御部１０３は、元メールの宛先"bcc"のメールアドレスを返信メールの送信元"from"のメールアドレスに設定して（ステップＳ８０７）、ステップＳ８０９の処理に進む。なお、元メールの宛先として"bcc"がなければ"bcc"のメールアドレスが拡張メールアドレス３０５として登録されていないものと判定される。

"bcc"のメールアドレスも拡張メールアドレス３０５として登録されていなければ、制御部１０３は、アカウント情報テーブル３００に登録されている標準メールアドレス３０３を返信メールの送信元"from"のメールアドレスに設定して（ステップＳ８０８）、ステップＳ８０９の処理に進む。

ステップＳ８０９では、制御部１０３が返信メールの件名を“RE:（元メールの件名）”に設定するとともに、ユーザが入力部１６１を操作して返信メールの本文を入力する。ユーザが入力部１６１からの入力により件名を変更してもよい。制御部１０３は、入力部１６１からの入力により返信メールの送信が要求されたかどうかを判定する（ステップＳ８１０）。返信メールの送信が要求されるまでは、制御部１０３は、ステップＳ８０９、Ｓ８１０の処理を繰り返して行う。返信メールの送信が要求されると、制御部１０３は、当該返信メールを通信インターフェイス１１５からインターネット３に送出させる（ステップＳ８１１）。そして、メール送信処理を終了する。

以上説明したように、この実施の形態にかかるネットワークシステムのサーバ群２は、ゲームサーバ２３によりネットワークゲームのサービスを、メールサーバ２２によりメール交換サービスを提供している。ゲームサーバ２３が提供するネットワークゲームにおいては、ユーザは、ゲーム内で使用するキャラクタ名を設定することができ、このキャラクタ名を用いて他のユーザとゲームを進行させることとなる。

ユーザがネットワークゲームで使用するキャラクタ名は、キャラクタ情報テーブル３５０に記憶され、ユーザは、拡張サービスを利用することによって、ここに登録されたキャラクタ名を含む拡張メールアドレスを使用できるようになる。ネットワークゲームにおいては、各ユーザは、他のユーザをキャラクタ名で認識していることが多いので、このような拡張メールアドレスを使用できるものとすることによって、ゲームサーバ２３がそれぞれ提供するネットワークゲームに参加するユーザ間でのコミュニケーションを円滑に図ることができる。

ここで、この実施の形態の拡張メールアドレスは、メールアカウント（＠の前側）にキャラクタ名を設定し、ドメイン名（＠の後側）にネットワークゲームのゲーム名（及びワールド名）を含むものとしている。このため、ユーザがネットワークゲームで使用しているキャラクタ名が分かり易く、さらにどの種類のゲームで使用されているかも分かり易い。しかも、ドメイン名にゲーム名（及びワールド名）を含むことで、異なるゲーム及び同一のゲームの異なるワールドで同一のキャラクタ名が使用されていても、仮に異なるユーザによって使用されている場合であっても、メールアドレスを区別して使用することができる。また、ゲームにおけるキャラクタ名から相手の拡張メールアドレスとなる可能性のあるアドレスを把握でき、ゲーム内の他のユーザのキャラクタに対してコミュニケーションを図ることができる。

この実施の形態では、各ユーザ宛のメールを格納するためのメールボックスは、ユーザＩＤに対応して設けられている。つまり、メールサーバ２２において、標準メールアドレスを宛先としたメールだけではなく、拡張メールアドレスを宛先としたメールも、それぞれのメールアドレスに対応するユーザＩＤに対応して設けられたメールボックスに格納される。

つまり、ユーザは、拡張メールアドレスを宛先としたメールを標準メールアドレスを宛先としたメールと同様に受け取ることができ、自分がネットワークゲームで使用しているキャラクタ名を含むメールアドレスで容易にメール交換ができるようになる。また、メールサーバ２２においても、同じユーザ宛のメールを当該ユーザからの要求に基づいて一度に送ることができるので、その処理が容易になる。

ユーザがネットワークゲームで使用するキャラクタ名を変更・削除した場合には、その変更が即座にデータベースサーバ２４のキャラクタ情報テーブル３５０に反映されることとなる。メールサーバ２２は、所定時間毎にデータベースサーバ２４からキャラクタ情報テーブル３５０を取得して、内部のキャラクタ情報テーブル３５０の内容も更新するとともに、アカウント情報テーブル３００から使用されなくなったキャラクタ名を含む拡張メールアドレスを削除する。

これにより、ネットワークゲームで使用されなくなったキャラクタ名が、拡張メールアドレスとして何時までも使用されることがなくなる。また、このようにメールサーバ２２のアカウント情報テーブル３００及びキャラクタ情報テーブル３５０は、できるだけ最新のネットワークゲームにおける状況を反映したものとなるため、ユーザは、自己がネットワークゲームで使用するキャラクタ名を設定したときには、比較的早いうちにそのキャラクタ名を含む拡張メールアドレスを使用できるようになる。

しかも、キャラクタ情報テーブル３５０をメールサーバ２２にも記憶しているため、ユーザが拡張メールアドレスを設定するときに、メールサーバ２２がユーザのネットワークゲームでのキャラクタ名を容易に取得することができ、拡張メールアドレスを容易に生成することができるようになる。

ここで、所定時間毎の処理でメールサーバ２２のキャラクタ情報テーブル３５０の内容を更新し、使用されなくなったキャラクタ名を含む拡張メールアドレスの削除は、データベースサーバ２４のアカウント情報テーブル３００について行われ、メールサーバ２２のアカウント情報テーブル３００は、これと同じ内容に更新されることとなる。これにより、データベースサーバ２４とメールサーバ２２とで、アカウント情報テーブル３００の登録内容が整合されることとなる。

拡張メールアドレスを設定したときは、その設定内容をデータベースサーバ２４に送り、データベースサーバ２４のアカウント情報テーブル３００を更新してから、これをメールサーバ２２に送って、メールサーバ２２のアカウント情報テーブル３００も更新するようにしている。これにより、データベースサーバ２４とメールサーバ２２とで、アカウント情報テーブル３００の登録内容が整合されることとなる。

さらに、設定完了ページ４３０に含まれる制御タグ４３３を認識することによって、端末装置１からもメールサーバ２２を介してデータベースサーバ２４にアカウント情報を要求して、その内部のアカウント情報テーブル３００を更新するようにしている。これにより、データベースサーバ２４と端末装置１とでも、アカウント情報テーブル３００の登録内容が整合されることとなる。

また、端末装置１からサーバ群２が提供するサービスにユーザがログインしようとするときには、ログイン要求のユーザＩＤと同じユーザＩＤを登録したアカウント情報テーブル３００が端末装置１内に記憶されているかどうか判定される。また、データベースサーバ２４のアカウント情報テーブル３００から取得した最終更新日時３１１が端末装置１に記憶されていたアカウント情報テーブル３００の最終更新日時３１１と比較される。

ここで、同じユーザＩＤのアカウント情報テーブル３００において最終更新日時３１１が一致していたならば、端末装置１に記憶されていたアカウント情報テーブル３００をそのまま用いて、メールサーバ２２が提供するメール交換のサービスを利用することができる。つまり、最終更新日時３１１以上に多くの情報をインターネット３を介してメールサーバ２２からインターネット３を介して端末装置１に送信する必要がないので、これらの資源にかかる負荷を小さくすることができる。

一方、端末装置１に同じユーザＩＤのアカウント情報テーブル３００が記憶されていなかったり、記憶されていても最終更新日時が一致していなかったときには、データベースサーバ２４のアカウント情報テーブル３００の登録内容が端末装置１に送られて、端末装置１のアカウント情報テーブル３００として記憶されることとなる。これによっても、データベースサーバ２４と端末装置１とで、アカウント情報テーブル３００の登録内容が整合されることとなる。

このため、ユーザは、他のユーザの端末装置１など、これまでとは異なる新たな端末装置１からサーバ群２が提供するサービスにログインした場合でも、新たな端末装置１においてアカウント情報の設定を行う必要がない。端末装置１のアカウント情報テーブルが壊れてしまった場合も同様に設定を行う必要がない。また、ネットワークゲームにおけるキャラクタ名の変更・削除は、データベースサーバ２４及びメールサーバ２２におけるアカウント情報テーブル３００の内容を更新させるが、ユーザは、このようなことを行っても、端末装置１においてアカウント情報の設定をやり直す必要がない。

しかも、アカウント情報テーブル３００が端末装置１に記憶されていなかったときや、記憶されていてもメールサーバ２２から取得した最終更新日時３１１と一致しなかったときは、端末装置１のアカウント情報テーブル３００として、最新の内容となっているデータベースサーバ２４のアカウント情報テーブル３００の内容が記憶される。従って、実際には使用不能となった拡張メールアドレスが、メールの送信元アドレスに設定されてしまうのを防ぐことができる。

このように端末装置１に記憶されるアカウント情報テーブル３００は、その内容を全てサーバ群２からインターネット３を介して取得し、自動的に内部に記憶されることとなる。このため、ユーザが自ら設定操作を行わなくても、アカウント情報を容易に端末装置１に設定することができる。また、アカウント情報が自動設定されることから、ユーザは、アカウント情報を憶えていなくても、任意の端末装置１を利用して、メールサーバ２２が提供するメール交換のサービスを利用することができる。

さらに、アカウント情報テーブル３００の登録対象となるアカウント情報には、ＰＯＰサーバ名３０７、ＰＯＰサーバポート番号３０８、ＳＭＴＰサーバ名３０９、及びＳＭＴＰサーバポート番号３１０も含まれている。これらも自動的に更新されるものであるため、サーバ群２においてＰＯＰ（Post Office Protocol）サーバ名３０７、ＰＯＰサーバポート番号３０８、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ名３０９、および／またはＳＭＴＰサーバポート番号３１０が変更されたとしても、ユーザは、その変更を意識することなく、メールサーバ２２が提供するメール交換のサービスを利用することができる。

ところで、メールサーバ２２が提供するメール交換サービスにおいて、標準メールアドレスは、当該メール交換サービスを受けるためには必要なものであるが、拡張メールアドレスは、ユーザの設定によって使用されるものであり、必ずしも必要がない。また、ユーザが拡張サービスの利用を停止したり、ネットワークゲームにおいてキャラクタ名を変更・削除することによっても、拡張メールアドレスが使用できなくなる。従って、ユーザが拡張メールアドレスを宛先とするメールを端末装置１において受信した後、このメール（元メール）に対する返信メールを作成しようとするときには、当該拡張メールアドレスが使用できなくなっていることもあり得る。

この実施の形態にかかる端末装置１では、元メールの宛先アドレスが既に使用不能となっていても、端末装置１のアカウント情報テーブル３００に登録された他のメールアドレスから使用可能なメールアドレスを選択するものとなっている。このため、返信メールの送信元アドレスは、現在使用可能な適切なメールアドレスに設定されることとなる。一方、元メールの宛先アドレスが現在使用可能であれば、それが返信メールの送信元アドレスとして設定されるので、この返信メールを受け取った他のユーザは、どのメールに対する返信メールであるかを容易に判断することができる。

また、返信メールにおける送信元アドレスの選択は、元メールにおける宛先アドレスとして“to”、“cc”、“bcc”が指定されている順に優先される。通常のユーザが他のユーザにメールを送信するとき、送信相手としての重要性が高い順に“to”、“cc”、“bcc”を指定することが多い。従って、このような優先順位で返信メールの送信元アドレスに設定することで、返信メールの作成対象となったメールを送信したユーザが重要性が高いと考えていたメールアドレスを返信メールの送信元アドレスに設定することができるようになる。

さらに、“to”、“cc”、“bcc”のいずれに指定された宛先アドレスも使用不能となっていれば、標準メールアドレスが返信メールの送信元アドレスとして設定される。標準メールアドレスは、必須のメールアドレスであり、返信メールの送信元アドレスに設定すべきメールアドレスとして、適切なメールアドレスが選択できないということがない。このようにしてユーザが現在使用しているメールアドレスだけが返信メールの送信元アドレスとして設定されるものとすることで、この返信メールに対して他のユーザが作成した返信メールが、当該ユーザの元に確実に届けられるようになる。

本発明は、上記の実施の形態に限られず、種々の変形、応用が可能である。以下、本発明に適用可能な上記の実施の形態の変形態様について説明する。

上記の実施の形態では、キャラクタ名の変更・削除により使用できなくなった拡張メールアドレスをアカウント情報テーブル３００から削除するため、メールサーバ２２のタイマ割り込みによるアカウント情報更新処理を行うものとしていた。これに対して、図８のキャラクタ名変更・削除が行われた後、削除されたキャラクタ名（変更により削除されたものを含む）をゲームサーバ２３からデータベースサーバ２４に送るものとし、この時点で使用されていないキャラクタ名を含む拡張メールアドレスをアカウント情報テーブル３００から削除するものとしてもよい。また、ここでアカウント情報テーブル３００が更新された場合も、メールサーバ２２などから端末装置１にアカウント情報を送信するものとし、端末装置１のアカウント情報テーブル３００も更新することができる。

上記の実施の形態では、ユーザがネットワークゲームで使用するキャラクタ名をメールアカウントとした拡張メールアドレスは、サーバ群２が提供するサービスのうちの拡張サービスを利用するユーザだけが最大５個まで登録できるものとなっていた。しかしながら、拡張サービスを利用するかどうかに関わらず、サーバ群２が提供するサービスを利用するユーザ全てが、拡張メールアドレスを利用できるようにしてもよい。また、１人のユーザが拡張メールアドレスを利用できる数は、１以上の任意の数とし、最大で当該ユーザが利用するキャラクタの数までとすることもできる。

さらに、ユーザがネットワークゲームにおいてキャラクタ名を設定することにより、当該キャラクタ名及びゲーム名を含むメールアドレスを自動的に使用することができるようにしてもよい。この場合には、キャラクタ名の設定（変更により新たに設定されたものを含む）が行われたときに、設定されたキャラクタ名をゲームサーバ２３からデータベースサーバ２４に送るものとし、この時点で新たに設定されたキャラクタ名を含む拡張メールアドレスをアカウント情報テーブル３００に登録するものとしてもよい。また、ここでアカウント情報テーブル３００が更新された場合も、メールサーバ２２などから端末装置１にアカウント情報を送信するものとし、端末装置１のアカウント情報テーブル３００も更新することができる。

上記の実施の形態では、ユーザは、ネットワークゲームで使用するキャラクタ名を含む拡張メールアドレスの他に、標準メールアドレスも使用できるものとなっていた。メールボックスからメールを読み出す際の認証には、この標準メールアドレスが使用されていた。もっとも、メールアドレス以外の情報（例えば、ユーザＩＤなど）で認証を行うのであれば、標準メールアドレスはなくてもよい。この場合でも、拡張メールアドレスに対応するユーザＩＤをアカウント情報テーブル３００から検索し、該ユーザＩＤに対応したメールボックスにメールを格納すればよいからである。

上記の実施の形態では、メールサーバ２２においてメールボックスは、ユーザＩＤに対応して設けられており、該ユーザＩＤに対応するメールアドレスを宛先としたメールは、当該宛先のメールアドレスが標準メールアドレスか拡張メールアドレスかに関わらず、同一のメールボックスに格納されるものとなっていた。しかしながら、拡張メールアドレス毎にメールボックスを用意するものとしてもよい。ユーザＩＤとネットワークゲーム（或いはワールド）に対応してメールボックスを用意するものとし、キャラクタ名が変更されても同じゲームに対応するメールは、同じメールボックスに格納するものとすることもできる。拡張メールアドレス毎にメールボックスを用意した場合（ユーザＩＤとネットワークゲーム（或いはワールド）に対応してメールボックスを用意した場合を含む）、ユーザがメールを受信する際に、端末装置１は、ユーザの複数の拡張メールアドレスに対応する各メールボックスからメールを受信するようにしてもよい。

上記の実施の形態では、メールサーバ２２の管理しているユーザのメールボックスに拡張メールアドレスを宛先としたメールを格納するようにしていたが、本発明はこれに限られない。例えば、メールサーバ２２とは異なる他のサーバにおいて管理されているユーザのメールボックスに拡張メールアドレスを宛先としたメールを格納してもよい。この場合、例えば、メールサーバ２２において異なるサーバのメールボックスに対応する所定のメールアドレスを管理しておき、メールサーバ２２が拡張メールアドレスを宛先としたメールを当該所定のアドレスに転送すればよい。また、他のサーバのメールボックスに拡張メールアドレスを宛先としたメールを格納するようにした場合には、端末装置１は、他のサーバのメールボックスに格納されたメールを、当該他のサーバから受信するようにすることができる。

上記の実施の形態では、端末装置１からサーバ群２が提供するサービスにログインするときに、メールサーバ２２のアカウント情報テーブル３００の最終更新日時３１１を端末装置１に取得し、これが端末装置１のアカウント情報テーブル３００の最終更新日時３１１と一致しないときに、メールサーバ２２からアカウント情報を取得して、端末装置１のアカウント情報テーブル３００を更新するものとしていた。これに対して、端末装置１からサーバ群２が提供するサービスにログインするときには、常にメールサーバ２２（或いはデータベースサーバ２４）からアカウント情報を端末装置１に取得するものとしてもよい。

これにより、端末装置１においては、サーバ群２が提供するサービスを利用しないときにおいては、内部にアカウント情報テーブル３００を格納しておく必要がない。また、ユーザがサーバ群２が提供するサービスを利用するための端末装置１を頻繁に変えたとしても、ユーザが使用する端末装置１のアカウント情報テーブル３００の登録内容は、サーバ側のアカウント情報テーブル３００の内容と一致させることができる。

上記の実施の形態では、ユーザは、拡張サービスを利用することによって標準メールアドレスと拡張メールアドレスとを使用できるものとなり、それぞれアカウント情報テーブル３００に登録されるものとしていた。また、ログイン時において最終更新日時３１１を比較することにより、端末装置１のアカウント情報テーブル３００の登録内容をサーバ側の登録内容に合わせて更新するものとしていた。もっとも、ログイン時における端末装置１のアカウント情報テーブル３００の更新は、サーバ群２が拡張メールアドレスをサービスとして提供しているかどうかに関わらず、行うものとすることができる。

上記の実施の形態では、図１２のアカウント情報更新処理において、各ユーザＩＤに対応について、データベースサーバ２４のアカウント情報テーブル３００に登録されたアカウント情報全体を必端末装置１に必ず取得するものとしていた。しかし、最初に拡張サービス可・不可フラグ３０６だけをデータベースサーバ２４から端末装置１に取得し、これがセットされていたときだけ、他のアカウント情報もデータベースサーバ２４から取得するものとしてもよい。ＰＯＰ及びＳＭＴＰサーバ名及びポート番号３０７〜３１０は、データベースサーバ２４においても滅多に更新されないので、特に問題は生じない。

拡張サービス可・不可フラグ３０６がリセットされていたときは、さらにアカウント情報をデータベースサーバ２４から取得することなく、端末装置１のアカウント情報テーブル３００の拡張サービス可・不可フラグ３０６もリセットするとともに、拡張メールアドレス３０５を全て削除するものとすればよい。これにより、データベースサーバ２４からインターネット３を介して端末装置１に送信するデータ量を小さくすることができ、これらにかかる負荷を小さくすることができる。

上記の実施の形態では、ユーザが元メールに対して返信を行う際に、元メールの宛先アドレスが既に使用されなくなった拡張メールアドレスであったときに、他のメールアドレスを返信メールの送信元アドレスとして設定するものとしていた。しかしながら、元メールに対して返信を行う際に元メールの宛先アドレスが既に使用されなくなっていることは、拡張メールアドレスでなくても起こりえる。例えば、複数のメールアドレス（ドメインが異なるものでもよい）を使用していたユーザが一方の使用を止めた場合である。ユーザが現在使用しているメールアドレスは、通常端末装置１に格納されているので、現在使用されているメールアドレスに変更して、返信メールの送信元アドレスを設定することができる。

上記の実施の形態では、管理サーバ２１、メールサーバ２２、複数のゲームサーバ２３、及びデータベースサーバ２４を互いにＬＡＮ２５で接続して、サーバ群２を構成するものとしていた。しかしながら、サーバ側のシステム構成は任意である。例えば、上記したサーバ群２の機能を１つのサーバ装置上で全て実現するものとしてもよい。或いは、さらに多くのサーバ装置にサーバ群２の機能を分散するものとしてもよい。

また、データベースサーバ２４がなくても、他のサーバ２１〜２３の間で互いにデータをやりとりすることによって、端末装置１から見た機能としては同じ機能を実現することができる。さらに、データベースサーバ２４に置かれているデータは、他のサーバ２１〜２３には置かないようにして、必要に応じてサーバ２１〜２３からデータベースサーバ２４にアクセスして、必要なデータを取得するものとしてもよい。

上記の実施の形態では、端末装置１としては、ビデオゲーム機または汎用のパーソナルコンピュータを適用するものとして説明していた。これに対して、ビデオゲーム本体１０１と同様の構成要素を備え、インターネット接続機能を備えるのであれば、表示装置１２１を同一の筐体内に納めた構成を有する携帯ゲーム機を適用してもよい。記録媒体１３１として、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭの代わりに半導体メモリカードを適用することができる。さらに、ネットワークゲームのアプリケーションを実行する機能とインターネット接続機能の両方を備えるのであれば、携帯電話機を適用することもできる。

上記の実施の形態では、端末装置１のプログラム及びデータは、記録媒体１３１に格納されて配布されるものとしていた。サーバ２１〜２４のプログラム及びデータは、記録媒体２２０に格納されて配布されるものとしていた。これに対して、これらのプログラム及びデータは、ＨＤＤ１０７、２０７に予め格納して適用してもよい。また、これらのプログラム及びデータをインターネット３上に存在するサーバ装置が有する固定ディスク装置に格納しておき、端末装置１、サーバ２１〜２４にインターネット３を介して配信するものとしてもよい。例えば、端末装置１において、通信インターフェイス１１５がサーバ装置から受信したプログラム及びデータは、ＨＤＤ１０７に保存し、実行時にＲＡＭ１０５にロードすることができる。

本発明の実施の形態にかかるネットワークシステムの全体構成を示すブロック図である。 本発明の実施の形態にかかる端末装置の構成を示すブロック図である。 本発明の実施の形態にかかる各サーバの構成を示すブロック図である。 メールサーバが提供するメール交換サービスを利用するためのアカウント情報テーブルと、キャラクタ情報テーブルとを示す図である。 拡張メールアドレス設定開始画面を示す図である。 拡張メールアドレス設定画面を示す図である。 拡張メールアドレス設定完了画面と、そのソースコードを示す図である。 本発明の実施の形態にかかるキャラクタ名の変更・削除処理を示す流れ図である。 本発明の実施の形態にかかる拡張サービス開始・停止処理を示す流れ図である。 本発明の実施の形態にかかる拡張メールアドレス設定処理を示す流れ図である。 本発明の実施の形態にかかる端末ログイン処理を示す流れ図である。 本発明の実施の形態にかかるアカウント情報更新処理を示す流れ図である。 本発明の実施の形態にかかるメール格納処理を示す流れ図である。 本発明の実施の形態にかかるメール取得処理を示す流れ図である。 本発明の実施の形態にかかるメール返信処理を示す流れ図である。

符号の説明

１ 端末装置
２ サーバ群
２１ 管理サーバ
２２ メールサーバ
２３ ゲームサーバ
２４ データベースサーバ

Claims (7)

1. ネットワークを介して接続されたメールサーバから、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを受信するメール受信手段と、
   ユーザが現在使用可能なメールアドレスを記憶するアドレス記憶手段と、
   ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、当該使用されなくなったメールアドレスを前記アドレス記憶手段から削除するアドレス削除手段と、
   前記メール受信手段がメールを受信した時点よりも後の時点で、該受信したメールに対する返信メールを生成する返信メール生成手段とを備え、
   前記返信メール生成手段は、
   前記返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスが前記アドレス削除手段により削除されることなく前記アドレス記憶手段に記憶されているかどうかを判定する宛先判定手段と、
   該宛先アドレスが前記アドレス記憶手段に記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定する送信元アドレス設定手段とを備える
   ことを特徴とする返信メール作成装置。
2. 前記返信メールの作成対象となるメールの宛先アドレスは、重要度が異なる少なくとも２つの宛先区分による指定がなされており、
   前記送信元アドレス設定手段は、前記宛先アドレスが前記アドレス記憶手段に記憶されていると判定されたときには、該記憶されている宛先アドレスのうちの重要度が高い区分の宛先アドレスを優先して、返信メールの送信元アドレスに設定する
   ことを特徴とする請求項１に記載の返信メール作成装置。
3. 前記アドレス記憶手段は、各ユーザに対して必ず設定されている標準メールアドレスと、ユーザからの要求に従って任意に設定される拡張メールアドレスとを記憶し、
   前記アドレス削除手段は、前記拡張メールアドレスが使用されなくなったときに、該使用されなくなった拡張メールアドレスを前記アドレス記憶手段から削除し、
   前記送信元アドレス設定手段は、前記宛先アドレスに対応した拡張メールアドレスが前記アドレス記憶手段に記憶されていないと判定されたときには、前記標準メールアドレスを返信メールの送信元アドレスに設定する
   ことを特徴とする請求項１または２に記載の返信メール作成装置。
4. 前記メールサーバは、ユーザの現在使用可能なメールアドレスを管理しており、
   所定の時点において、前記メールサーバにおいて管理されているユーザの現在使用可能なメールアドレスを前記ネットワークを介して取得するアドレス取得手段と、
   前記アドレス取得手段が取得したメールアドレスに従って、前記アドレス記憶手段に記憶させるメールアドレスを更新するアドレス更新手段とをさらに備える
   ことを特徴とする請求項１乃至３のいずれか１項に記載の返信メール作成装置。
5. ユーザが現在使用可能なメールアドレスをアドレス記憶手段に記憶する端末装置において、
   ネットワークを介して接続されたメールサーバから、受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを受信し、
   ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、当該使用されなくなったメールアドレスを前記アドレス記憶手段から削除し、
   メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、
   該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、
   該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定する
   ことを特徴とする返信メール作成方法。
6. ネットワークを介してメールサーバに接続されたコンピュータ装置において実行されるプログラムであって、
   ユーザが現在使用可能なメールアドレスをアドレス記憶手段に予め記憶させ、
   受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを前記メールサーバから前記ネットワークを介して受信し、
   ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、前記端末装置において記憶されていたメールアドレスのうちで当該使用されなくなったメールアドレスを削除し、
   メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、
   該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、
   該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定する
   ことを特徴とするプログラム。
7. ネットワークを介してメールサーバに接続されたコンピュータ装置において実行されるプログラムを記録した記録媒体であって、
   前記プログラムは、
   ユーザが現在使用可能なメールアドレスをアドレス記憶手段に予め記憶させ、
   受信の時点までにユーザの使用するメールアドレスを宛先アドレスとして前記メールサーバの当該ユーザのメールボックスに格納されていたメールを前記メールサーバから前記ネットワークを介して受信し、
   ユーザがこれまで使用していたメールアドレスが使用されなくなったときに、前記端末装置において記憶されていたメールアドレスのうちで当該使用されなくなったメールアドレスを削除し、
   メールを受信した時点よりも後の時点で該受信したメールに対する返信メールを作成する際に、該返信メールの作成対象となるメールの宛先アドレスがユーザが削除されることなく現在使用可能なメールアドレスとしてアドレス記憶手段に記憶されているかどうかを判定し、
   該宛先アドレスが記憶されていると判定されたときには、該宛先アドレスを返信メールの送信元アドレスに設定し、
   該宛先アドレスが記憶されていないと判定されたときには、前記アドレス記憶手段に記憶されているいずれかのメールアドレスを返信メールの送信元アドレスに設定する
   ことを特徴とするコンピュータ読み取り可能な記録媒体。

Images