(57)【要約】携帯電話機１００−１は、電子メールの取得を要求する旨のＨＴＴＰリクエストに、ユーザが取得を所望する添付ファイルの拡張子を示す情報を内包させ、このＨＴＴＰリクエストをメールサーバ４００へ送信する。メールサーバ４００は、ＨＴＴＰリクエストを受信すると、電子メールに添付されているファイルと、ＨＴＴＰリクエストに内包された情報とを比較し、添付ファイルを送信するか否か判断する。メールサーバ４００は、添付ファイルを送信しないと判断した場合には、添付ファイルを削除した電子メールを携帯電話機１００−１へ送信する。
2003105426.tif 000002
【特許請求の範囲】
【請求項１】
ファイルが添付された電子メールをサーバ装置から通信端末へ送信する方法であって、
前記通信端末が、前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を取得する取得ステップと、
前記通信端末が、前記種別情報を前記サーバ装置へ送信する送信ステップと、
前記サーバ装置が、前記種別情報を受信する受信ステップと、
前記サーバ装置が、前記サーバ装置により受信された前記通信端末宛ての電子メールの添付ファイルの種類が、前記種別情報によって特定されるファイル種類に一致するか否かを判定するステップと、
前記サーバ装置が、該添付ファイルの種類が一致しない場合は、該電子メールから該添付ファイルを削除して得られた電子メールを前記通信端末へ送信し、
当該添付ファイルの種類が一致する場合は、該電子メールを前記通信端末へ送信するステップと
を有することを特徴とする電子メール送信方法。
【請求項２】
前記通信端末において、該通信端末宛の電子メールを取得する旨の要求を前記サーバ装置に送信するステップをさらに備え、
当該要求には前記取得された種別情報が内包されている
ことを特徴とする請求項１に記載の電子メール配信方法。
【請求項３】
前記取得ステップにおいて、前記通信端末が前記通信端末にて使用可能なファイルの種類を表示すること
を特徴とする請求項１に記載の電子メール配信方法。
【請求項４】
前記通信端末は、当該通信端末に着脱可能な記憶部を有し、
前記通信端末が、前記電子メール送信ステップにて送信された電子メールを受信し、受信した電子メールに添付されているファイルを前記記憶部に記憶させる記憶ステップ
をさらに有することを特徴とする請求項１に記載の電子メール配信方法。
【請求項５】
前記取得ステップにおいて、まずユーザが受信したくないファイルの種類を指定する情報を取得し、該取得した情報に基づいて前記種別情報を生成することを特徴とする請求項１に記載の電子メール配信方法。
【請求項６】
ユーザが受信を希望する添付ファイルの種類を指定する種別情報を取得する手段と、
前記種別情報をサーバ装置へ送信する送信手段と、
前記サーバ装置から電子メールを取得する取得手段と
を有することを特徴とする通信端末。
【請求項７】
前記通信端末宛の電子メールの取得を要求する旨の受信要求を前記サーバ装置に送信する手段をさらに備え、
前記要求には前記取得された種別情報が内包されている
ことを特徴とする請求項６に記載の通信端末。
【請求項８】
前記通信端末にて使用可能なファイルの種類をユーザに提示する手段をさらに備えることを特徴とする請求項６に記載の通信端末。
【請求項９】
取得した電子メールに添付されているファイルを着脱可能な記憶部に記憶する手段を更に有することを特徴とする請求項６に記載の通信端末。
【請求項１０】
前記取得手段は、まず、前記ユーザが受信を希望しないファイルの拡張子を指定する情報を受信し、該受信された情報に基づいて前記種別情報を生成する
ことを特徴とする請求項６に記載の通信端末。
【請求項１１】
通信端末から送信された、前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を受信する手段と、
前記サーバ装置により受信された前記通信端末宛ての電子メールに添付されるファイルの種類が、前記種別情報によって特定されるファイルの種類に一致するか否かを判定する手段と、
該添付ファイルの種類が一致しない場合は、該電子メールから該添付ファイルを削除することにより得られた電子メールを前記通信端末へ送信し、当該添付ファイルの種類が一致する場合は、該電子メールを前記通信端末へ送信する手段と
を有することを特徴とするサーバ装置。
【請求項１２】
サーバ装置において、電子メールを通信端末へ送信する方法であって、前記通信端末から送信された、前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を受信するステップと、
前記通信端末宛ての電子メールを受信すると、該電子メールに添付されているファイルの種類が前記種別情報によって特定されるファイルの種類に一致するか否かを判定するステップと、
該添付ファイルの種類が一致しない場合は、該電子メールから該添付ファイルを削除することにより得られた電子メールを前記通信端末へ送信し、当該添付ファイルの種類が一致する場合は、該電子メールを前記通信端末へ送信するステップと
を有することを特徴とするメール送信方法。
【発明の詳細な説明】
技術分野
本発明は、ファイルが添付された電子メールを通信端末へ配信する技術に関する。
背景技術
近年、携帯電話機やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄａｔａ  Ａｓｓｉｓｔａｎｔｓ）などの携帯通信端末やパーソナルコンピュータ等の電子機器を用いて、画像や音楽などのファイルを添付した電子メールの送受信が盛んに行われている。
しかしながら、上記機器によってハードウェア構成や機能が異なるため、ファイルが添付された電子メールを受信しても、そのファイルを使用できないという問題がある。例えば、携帯電話機によっては、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）方式の画像ファイルが添付された電子メールを受信しても、そのファイルを開くことができない。一般に添付ファイルのサイズはメール本文のそれと比べて大きく、開くことができない添付ファイルを受信するのは時間の無駄である。加えて、特にハードウェアリソースの乏しい携帯電話機においては、ファイル受信中は他の機能が制限される可能性もある。これは無視できない問題である。
メールサーバが携帯端末宛のメールを受信する度に、添付ファイルを受信するか否かをユーザに確認させることも考えられるが、これによってユーザの利便性は著しく低下してしまう。
この問題に対処するため、携帯電話機に受信される添付ファイルを全て処理可能なファイル形式に変換する技術が特開２００１−２１７８６０号公報に開示されている。より具体的には、携帯電話機で処理できないファイルの形式を、サーバ装置にて携帯電話機で使用可能なファイル形式に変換し、該変換されたファイルが添付された電子メール新たに作成し、これを携帯電話機へ送信する技術が開示されている。
しかしながら、通常一つのメールサーバには一度に多数の端末がアクセスし得るため、この技術では、添付ファイルの変換処理にともなって多大な負荷がサーバ装置にかかってしまうことがある。加えて、サーバ装置へアクセスする端末の種類も様々であるので、サーバ装置は端末の種類に応じた変換方法を用意する必要がある。これにより、サーバ装置にかかる負荷は一層増す。
そこで、このようなファイルの変換作業を通信端末側で行うことも考えられるが、特に携帯電話機のように十分な処理能力をもたない機器にあっては、仮にこの変換作業ができたとしても、電子メールの受信が終了するまでに時間がかかってしまい、現実的ではない。
これを回避するため、変換ができないことを示す旨の通知のみを携帯電話機へ送信し、変換不可能なファイルは携帯電話機に送信しないという技術がある。すなわち、一部の添付ファイルのみが携帯電話機に送信される。このため、ファイル変換を行うサーバ装置は、各携帯電話機がどのファイル形式に対応可能であるかを示す対応表を予め備えている。
しかしながら、この場合は、携帯電話機の機種によって受信可能な添付ファイルが固定されてしまう。例えば、携帯電話機で処理できる種類の添付ファイルであれば、たとえユーザが受信を望まなくても、すべて携帯電話機に送信されてしまうことになる。すなわち、受信したい添付ファイルをユーザが自由に指定することができない。
本発明は上述した事情に鑑みてなされたものであり、ユーザが所望する添付ファイルのみを受信することのできる電子メール配信方法、当該方法に用いられる通信端末、サーバ装置を提供することを目的とする。
発明の開示
上述した課題を解決するために、本発明は、ファイルが添付された電子メールをサーバ装置から通信端末へ送信する方法であって、前記通信端末において前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を取得する取得ステップと、前記通信端末において前記種別情報を前記サーバ装置へ送信する送信ステップと、前記サーバ装置において前記種別情報を受信するステップと、前記サーバ装置において前記サーバ装置により受信された前記通信端末宛ての電子メールの添付ファイルの種類が、前記種別情報によって特定されるファイル種類に一致するか否かを判定するステップと、前記サーバ装置において該添付ファイルの種類が一致しない場合は、該電子メールから該添付ファイルを削除して得られた電子メールを前記通信端末へ送信し、当該添付ファイルの種類が一致する場合は、該電子メールを前記通信端末へ送信するステップと
を有する電子メール送信方法を提供する。
また本発明は、ユーザが受信を希望する添付ファイルの種類を指定する種別情報を取得する手段と、前記種別情報をサーバ装置へ送信する送信手段と、
前記サーバ装置から電子メールを取得する取得手段とを有することを特徴とする通信端末を提供する
また本発明は、通信端末から送信された、前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を受信する手段と、前記サーバ装置により受信された前記通信端末宛ての電子メールに添付されるファイルの種類が、前記種別情報によって特定されるファイルの種類に合致するか否かを判定する手段と、該添付ファイルの種類が一致しない場合は、該電子メールから該添付ファイルを削除することにより得られた電子メールを前記通信端末へ送信し、当該添付ファイルの種類が一致する場合は、該電子メールを前記通信端末へ送信する手段とを有するサーバ装置を提供する。
また本発明は、コンピュータ装置を、当該コンピュータ装置のユーザが受信を希望する添付ファイルの種類を指定する種別情報を取得する手段と、前記種別情報をサーバ装置へ送信する送信手段と、前記サーバ装置から電子メールを取得する取得手段として機能させるためのプログラムおよび当該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
また本発明は、コンピュータ装置を、通信端末から送信された、前記通信端末のユーザが受信を希望する添付ファイルの種類を指定する種別情報を受信する手段と、前記コンピュータ装置により受信された前記通信端末宛ての電子メールに添付されるファイルの種類が、前記種別情報によって特定されるファイルの種類に合致するか否かを判定する手段と、該添付ファイルの種類が一致しない場合は該電子メールから該添付ファイルを削除することにより得られた電子メールを前記通信端末へ送信し、当該添付ファイルの種類が一致する場合は該電子メールを前記通信端末へ送信する手段として機能させるためのプログラムおよび当該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
発明を実施する為の最良の形態
以下、図面を参照して本発明に係る実施形態について説明する。ただし、本発明は、係る実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内で任意の態様を含む。
＜１．実施形態の構成＞
＜１−１．全体構成＞
図１は、本発明に係わる通信システム１０の全体構成を例示する図である。通信システム１０には多数の携帯電話機が存在するが、図面が繁雑になるのを防ぐために、所定の携帯電話機１００−１と携帯電話機１００−２のみが示されている。
携帯電話機１００−１および携帯電話機１００−２は（以下、特に個々の携帯電話機を区別する必要のない場合は、携帯電話機１００と略称する）、ユーザが所有する携帯電話機であり、移動パケット通信網２００が提供する移動体データ通信サービス受けることができる。携帯電話機１００は、移動パケット通信網２００を利用して電子メールの授受を行う機能を有している。
携帯電話機１００−１は、拡張子が「ｊｐｅｇ」であるＪＰＥＧ形式の画像ファイルと、拡張子が「ｍｉｄ」であるＭＩＤＩ（Ｍｕｓｉｃａｌ  Ｉｎｓｔｒｕｍｅｎｔ  Ｄｉｇｉｔａｌ  Ｉｎｔｅｒｆａｃｅ）形式の音楽ファイルを使用することが可能であり、携帯電話機１００−２は、拡張子が「ｊｐｅｇ」であるＪＰＥＧ形式の画像ファイルをのみを使用することが可能である。
図２に示すように、携帯電話機１００−１のユーザは、その名前が「電話太郎」であり、移動パケット通信網２００を運用する通信事業者から電子メールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」を付与されている。携帯電話機１００−２のユーザは、その名前が「電話花子」であり、電子メールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」が付与されている。
移動パケット通信網２００は、移動体データ通信サービスを提供する通信網であり、移動パケット通信網２００に収容されている携帯電話機と無線通信を行う無線基地局と、無線基地局に接続された交換機と、交換機に接続された関門交換機と（いずれも図示略）、関門交換機に接続されたゲートウェイサーバ３００と、メールサーバ４００と、加入者データベース５００とを有している。
この移動パケット通信網２００を介し、パケット通信方式により、移動パケット通信網２００に収容されている携帯電話機間で行われる電子メールの授受が行われる。
ゲートウェイサーバ３００は、図示を省略したインターネット等のネットワークと移動パケット通信網２００とを相互接続するために、各ネットワークに適合するように通信プロトコルの変換を行う。より具体的には、ゲートウェイサーバ３００は、移動パケット通信網２００内で使用される移動パケット通信網用の伝送プロトコルと、インターネット等のネットワークにおいて標準で使用されるＴＣＰ／ＩＰとの変換を行う。
メールサーバ４００は、携帯電話機１００へ電子メールを配信するサーバであり、ゲートウェイサーバ３００に接続されている。
加入者データベース５００は、移動パケット通信網２００を運用する通信事業者と移動パケット通信網２００の使用に関する契約を行った加入契約者に関する情報を記憶するデータベースであり、ゲートウェイサーバ３００に接続されている。加入者データベース５００には加入契約者に関するデータが格納されている。具体的には、図２に示すように、加入契約者の氏名に対応づけて、加入契約者が所有する携帯電話機を識別するための端末識別子、加入契約者が所有する携帯電話機の電話番号、加入契約者の住所、移動パケット通信網２００を運用する通信事業者が加入契約者に付与した電子メールアドレスなどのデータが格納されている。
＜１−２．携帯電話機＞
図３は、携帯電話機１００−１のハードウェア構成を例示するブロック図である。同図に示すように、アンテナ１０３を除く携帯電話機１００−１の各部は、バス１０１に接続されており、このバス１０１を介して各部間でデータの授受が行われる。
通信部１０２は、アンテナ１０３を備えており、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１０の制御の下、移動パケット通信網２００に設置されている無線基地局との間で無線通信を行う。操作部１０４は、図示を省略したテンキーや操作指示などを入力するための複数のキー等を有している。ユーザはこの操作部１０４を用いて、文字入力、条件選択、プログラムの起動指示等を行う。具体的には、ユーザが操作部１０４を操作すると、その操作内容に応じた信号がＣＰＵ１１０に供給され、ＣＰＵ１１０はその操作内容を解釈して、該操作内容に応じて各部の動作を制御する。表示部１０５は、例えば、図示せぬ液晶表示パネルおよび液晶表示パネルの表示制御を行う制御回路を有しており、ＣＰＵ１１０から制御の下、文字や画像を液晶ディスプレイに表示する。画像の一例としては電源投入時に表示されるメニュー画面である。記憶部１０６は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）などの不揮発性メモリ（図示略）を有しており、携帯電話機１００−１を制御するためのデータなどを記憶する。音楽再生部１０７は図示を省略したスピーカを有しており、ＣＰＵ１１０の制御の下、音楽ファイルを再生する。
ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０８には、ＣＰＵ１１０により実行される各種プログラムが記憶されており、携帯電話機１００−１の全体を制御するＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）プログラムや電子メールプログラムなどが記憶されている。また、ＲＯＭ１０８には、携帯電話機１００−１を一意に識別するための識別子である端末識別子「ＭＳ０００００１」が記憶されている。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０９は、ＣＰＵ１１０の作業エリアとして使用され、ＣＰＵ１１０が実行するプログラムが使用するデータが一時的に記憶される。
ＣＰＵ１１０は、携帯電話機１００−１の電源が入れられると、ＲＯＭ１０８からＯＳプログラムを読み出し実行する。ＣＰＵ１１０はＯＳプログラムを実行すると、通信部１０２が受信した信号やユーザの操作に応じて操作部１０４から出力される信号に応じた処理を行う。例えば、ユーザの操作が電子メールプログラムの起動を指示するものであれば、ＣＰＵ１１０はＲＯＭ１０８から電子メールプログラムを読み出し実行する。ＣＰＵ１１０は、電子メールプログラムを実行した後は、操作部１０４から供給される信号と表示部１０５に現在表示されている画面とに基づいてユーザの指示を特定し、この指示に応じた各種の処理を行う。
次に、携帯電話機１００−１が有する電子メールの送受信に関する機能を説明する。ＲＯＭ１０８に格納される電子メールプログラムは、電子メールの送受信をＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いて行う機能を有している。
（１）送信
ＣＰＵ１１０が電子メールプログラムを実行すると、まず、表示部１０５に図４に例示したメニュー画面Ｍ１０が表示される。次に、携帯電話機１００−１のユーザが電子メールの本文と送信先を示す電子メールアドレスの入力し、続いて添付するファイルを指定すると、入力された電子メール本文、電子メールアドレスおよび添付すべきファイルが、ＲＡＭ１０９に格納される。そしてＣＰＵ１１０は、ユーザにより入力された電子メールの本文と電子メールの送信先を示す電子メールアドレス、およびユーザにより指定された添付するファイルを表示部１０５に表示させる。
ユーザが操作部１０４を用いて電子メールを送信する操作を行うと、ＣＰＵ１１０は、ＲＡＭ１０９に格納されている電子メールの本文、メールアドレス、添付すべきファイルおよび携帯電話機１００−１の端末識別子をパラメータとして含む、ＰＯＳＴメソッドを用いたＨＴＴＰリクエストを生成する。生成されたＨＴＴＰリクエストの一例を図５に示す。
同図に示すように、メールサーバ４００が実行するＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）プログラムのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）がＰＯＳＴメソッドのパラメータとして設定される。また、端末識別子はＵｓｅｒ−Ａｇｅｎｔ部に設定される「ＭＳ０００００１」である。このようにして生成されたＨＴＴＰリクエストは、メールサーバ４００へ送信される。
（２）受信
ＣＰＵ１１０は、携帯電話機１００−１宛に電子メールが届いていることを知らせる旨の着信通知をメールサーバ４００から受信すると、該電子メールをメールサーバ４００から取得するために、ＧＥＴメソッドを用いたＨＴＴＰリクエストを生成する。このＨＴＴＰリクエストは、携帯電話機１００−１の端末識別子と、電子メールを識別するためのメール識別子と、電子メールにファイルが添付されている場合に、携帯電話機１００−１に取得するファイルの拡張子を指定するパラメータとを内包している。具体的には、メールサーバ４００が実行するＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）プログラムのＵＲＩをＧＥＴメソッドのパラメータとして設定する。生成されるＨＴＴＰリクエストの一例を図６に示す。同図に示すように、取得するファイルの拡張子を指定するパラメータとして「ｊｐｅｇ」が、端末識別子「ＭＳ０００００１」がＵｓｅｒ−Ａｇｅｎｔ部に、設定し、メール識別子「０００１」がＸ−ＩＤ部にそれぞれ設定される。このようにして生成されたＨＴＴＰリクエストはメールサーバ４００へ送信される。
ＣＰＵ１１０は、電子メールを受信するためのＨＴＴＰリクエストへの応答としてメールサーバ４００から送信されるＨＴＴＰレスポンスを受信すると、ＨＴＴＰレスポンスに内包されている電子メールを該ＨＴＴＰレスポンスから抽出し、抽出した電子メールを記憶部１０６に記憶させる。電子メールにファイルが添付されている場合には、ＣＰＵ１１０は添付されているファイルを電子メールから抽出し、これを記憶部１０６に記憶させる。
また、この電子メールプログラムは、あらゆる種類の添付ファイルを受信することができる。受信した添付ファイルがＪＰＥＧ形式またはＭＩＤＩ形式のファイルであった場合は、携帯電話機１００−１はそのファイルを開くことができるが、それ以外の添付ファイルを受信した場合は、そのファイルを開くことができない。
具体的には、携帯電話機１００−１は、拡張子が「ｊｐｅｇ」である画像ファイルを受信した場合、ユーザからの指示に従って、表示部１０５にその画像を表示させる。例えば、ユーザから指示により、ＣＰＵ１１０は記憶部１０６に記憶されている受信した添付ファイルを読み出し、その一覧を表示部１０５に表示させる。そして、ユーザがその中から拡張子が「ｊｐｅｇ」であるファイルを選択すると、ＣＰＵ１１０はその画像を表示部１０５に表示させる。
また、携帯電話機１００−１は、拡張子が「ｍｉｄ」である音楽ファイルが添付された電子メールを受信した場合、ユーザからの指示によりその音楽を再生する。具体的には、ユーザが、所定の操作を行うと、ＣＰＵ１１０は記憶部１０６に記憶されている添付ファイルを読み出し、そのファイルの一覧を表示させる。ユーザが、表示された一覧の中から拡張子が「ｍｉｄ」であるファイルを選択すると、ＣＰＵ１１０は音楽再生部１０７にその音楽を再生させる。
＜１−３．携帯電話機１００−２＞
携帯電話機１００−２は、携帯電話機１００−１とほぼ同じ構成であるため、同一の部分についてはその説明を省略する。携帯電話機１００−２が携帯電話機１００−１と異なる点は、端末識別子が「ＭＳ０００００２」である点、および携帯電話機１００−１が有している音楽再生部１０７を有しておらず、従って拡張子が「ｍｉｄ」である音楽ファイルを使用することができない点、である。
＜１−４．メールサーバ４００＞
図９は、メールサーバ４００のハードウェア構成を例示するブロック図である。同図に示すように、メールサーバ４００の各部は、バス４０１により接続されている。
通信部４０２は、他の装置と通信を行うための通信インターフェースであり、ゲートウェイサーバ３００とメールサーバ４００とを接続する。操作部４０３は、図示を省略したマウスやキーボードを有している。メールサーバ４００の管理者が操作部４０３のマウスやキーボードを操作すると、該操作に応じた信号がＣＰＵ４０８へ出力される。表示部４０４は、一例として、図示せぬ液晶ディスプレイおよびその制御回路から構成される。表示部４０４は、ＣＰＵ４０８から送信される制御信号を受信すると、該制御信号に応じた文字や画像を表示する。管理者はこの画面を見ながら、新規ユーザ登録や記憶部４０５のメールボックスのメンテナンス作等を行う。
記憶部４０５は、ハードディス等から構成され、移動パケット通信網２００の加入契約者宛の電子メールを記憶するためのメールボックスを、加入契約者（すなわち携帯電話機のユーザ）に付与された電子メールアドレス毎に保有している。また、記憶部４０５には、メールサーバ４００の全体を制御するための制御プログラムと、移動パケット通信網２００に収容されている携帯電話機から送信された電子メールをメールボックスに格納するためのＣＧＩプログラム「ｓｅｎｄ．ｃｇｉ」（以下、格納用ＣＧＩとする）と、メールボックスに格納されている電子メールを移動パケット通信網２００に収容されている携帯電話機へ配信するためのＣＧＩプログラム「ｒｅｃｅｉｖｅ．ｃｇｉ」（以下、配信用ＣＧＩとする）とが記憶されている。格納用ＣＧＩの記憶位置を示すＵＲＩは、「ｈｔｔｐ：／／ａｂｃ．ｃｏ．ｊｐ／ｓｅｎｄ．ｃｇｉ」であり、配信用ＣＧＩの記憶位置を示すＵＲＩは、「ｈｔｔｐ：／／ａｂｃ．ｃｏ．ｊｐ／ｒｅｃｅｉｖｅ．ｃｇｉ」である。
ＲＯＭ４０６には、ＩＰＬ（Ｉｎｉｔｉａｌ  Ｐｒｏｇｒａｍ  Ｌｏａｄｅｒ）が記憶されている。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）４０７はＣＰＵ４０８の作業エリアとして使用され、ＣＰＵ４０８により実行されるプログラムが使用するデータが転送される。ＣＰＵ４０８は、メールサーバ４００を構成する各部を制御する。ＣＰＵ４０８は、メールサーバ４００の電源が入れられると、まずＲＯＭ４０６からＩＰＬを読み出し実行する。続いて、記憶部４０５から制御プログラムを読み出し実行する。
次に、メールサーバ４００が有する電子メールの配信機能について説明する。
記憶部４０５に記憶されているＣＧＩプログラムは、携帯電話機１００から送信された電子メールを配信する機能を有している。具体的には、ＣＰＵ４０８は、携帯電話機１００から送信されるＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストのメソッドに応じてＣＧＩプログラムを記憶部４０５から読み出して実行する。以下、図１０に例示したフローチャートを用いて、ＣＰＵ４０８がＨＴＴＰリクエストを受信した時に行う処理について説明する。
まず、ＣＰＵ４０８は、携帯電話機１００から送信されたＨＴＴＰリクエストを受信したか否かを判断する（ステップＳＢ１）。ＣＰＵ４０８は、ＨＴＴＰリクエストを受信していないと判断した場合には、ＨＴＴＰリクエストを受信するまで待ち続ける（ＳＢ１：ＮＯ）。
ＣＰＵ４０８は、ステップＳＢ１で「ＹＥＳ」と判断した場合には、受信したＨＴＴＰリクエストのメソッドがＰＯＳＴメソッドであるか否かを判断する（ＳＢ２）。ＣＰＵ４０８は、ＨＴＴＰリクエストのメソッドがＰＯＳＴメソッドであると判断した場合には（ＳＢ２：ＹＥＳ）、格納用ＣＧＩを記憶部４０５から読み出して実行する（ＳＢ３）。
続いて、ＣＰＵ４０８は、受信したＨＴＴＰリクエストに内包されている電子メールを記憶部４０５のメールボックスに格納する（ＳＢ４）。この格納処理の詳細は後述する。
ＣＰＵ４０８は、ステップＳＢ２で「ＮＯ」と判断した場合には、受信したＨＴＴＰリクエストのメソッドがＧＥＴメソッドであるか否かを判断する（ＳＢ５）。ＣＰＵ４０８は、ＨＴＴＰリクエストのメソッドがＧＥＴメソッドであると判断した場合には（ＳＢ５：ＹＥＳ）、配信用ＣＧＩを記憶部４０５から読み出して実行する（ＳＢ６）。続いて、ＣＰＵ４０８は、記憶部４０５のメールボックスに格納されている電子メールを移動パケット通信網２００に収容されている携帯電話機へ配信する処理を行う（ＳＢ７）。この配信処理の詳細は後述する。なお、ステップＳＢ５にて「ＮＯ」と判断した場合には、処理はステップＳＢ１へ戻り、ＨＴＴＰリクエストが送信されるのを待つ。
（１）電子メール格納処理
次に、図１０のステップＳＢ４における格納用ＣＧＩを実行する処理について、図１１に示すフローチャートを用いて詳述する。
ＣＰＵ４０８は、格納用ＣＧＩを実行すると、携帯電話機１００から送信されたＰＯＳＴメソッドを用いたＨＴＴＰリクエストに内包されている、電子メールの宛先を示すメールアドレスをキーにして記憶部４０５のメールボックスを検索する。ＣＰＵ４０８は、該当するメールボックスを見つけると、当該受信した電子メールを識別するためのメール識別子を生成する。次に、ＣＰＵ４０８は、ＨＴＴＰリクエストに内包されているメール本文と、送信元の携帯電話機１００の端末識別子と、添付ファイルが添付されている場合には添付ファイルと、該メール識別子とを対応づけて、当該メールボックスに格納する（ステップＳＣ１）。
続いてＣＰＵ４０８は、ＨＴＴＰリクエストに内包されているメールアドレスで指定されるユーザに電子メールが送信されたことを示す着信通知を生成する（ＳＣ２）。この着信通知には、該メールボックスに格納されているメール識別子が内包される。
次に、ＣＰＵ４０８は、着信通知の通知先となる携帯電話機を特定するために、ＨＴＴＰリクエストに内包されている、宛先を示すメールアドレスをキーにして加入者データベース５００を検索する。ＣＰＵ４０８は、該当するメールアドレスを見つけると、このメールアドレスに対応づけて格納されている端末識別子を加入者データベース５００から読み出す。
次に、ＣＰＵ４０８は、この端末識別子で特定される携帯電話機へ生成した着信通知を送信する（ＳＣ３）。以上で格納用ＣＧＩの処理は完了する。
（２）電子メール配信処理
次に、図１０のＳＢ７における配信用ＣＧＩの実行処理について、図１２に示すフローチャートを用いて詳述する。
ＣＰＵ４０８は、配信用ＣＧＩを実行すると、携帯電話機１００から送信された、ＧＥＴメソッドを用いたＨＴＴＰリクエストに内包されている端末識別子をキーにして、加入者データベース５００を検索する。ＣＰＵ４０８は、該当する端末識別子を見つけると、該端末識別子に対応づけて記憶されている電子メールアドレスを抽出する。
次にＣＰＵ４０８は、読み出した電子メールアドレスをキーにして、記憶部４０５のメールボックスを検索する。ＣＰＵ４０８は、該当するメールボックスを見つけると、ＨＴＴＰリクエストに内包されているメール識別子によって特定される電子メールをメールボックスから読み出す（ステップＳＤ１）。
次にＣＰＵ４０８は、読み出した電子メールにファイルが添付されているか否かを判断する（ＳＤ２）。ファイルが添付されていないと判断した場合には（ＳＤ２：ＮＯ）、ＣＰＵ１１０はステップＳＤ５へ処理を進める。
ファイルが添付されていると判断した場合には（ＳＤ２：ＹＥＳ）、ＣＰＵ４０８は、該ＨＴＴＰリクエストにおいて配信用ＣＧＩのパラメータとして設定されている添付ファイルの拡張子と、メールボックスから読み出した電子メールに添付されているファイルの拡張子とを比較する。
ＣＰＵ４０８は、この二つの拡張子が同一であると判断した場合には（ＳＤ３：ＹＥＳ）、該添付ファイルをＨＴＴＰリクエストに内包されている端末識別子で指定される携帯電話機へ送信するものと判断し、ステップＳＤ５へ処理を進める。この二つの拡張子が同一でないと判断した場合には（ＳＤ３：ＮＯ）、ＣＰＵ４０８は、携帯電話機のユーザが読み出した電子メールに添付されているファイルの受信を希望していない判断し、当該電子メールに添付されているファイルを削除する（ＳＤ４）。
次にＣＰＵ４０８は、添付ファイルを削除した電子メール、または添付ファイルを有する電子メールを内包するＨＴＴＰレスポンスを生成し、生成したＨＴＴＰレスポンスを、該ＨＴＴＰリクエストに内包されている端末識別子で指定される携帯電話機へ送信する（ＳＤ５）。
＜２．実施形態の動作例＞
次に、携帯電話機１００とメールサーバ４００との間で行われる一連のメール送受信処理について説明する。
（１）添付ファイルの拡張子の設定
携帯電話機１００のユーザは、まず当該ユーザが取得を希望する添付ファイルの拡張子を設定する。以下、図７および図８用いて、ユーザが拡張子を設定する際にＣＰＵ１１０が行う処理の流れの一例を説明する。
携帯電話機１００−１のユーザが所定の操作を行うと、ＣＰＵ１１０は、図８に例示した設定メニュー画面Ｍ２０を表示部１０５に表示させる。この画面Ｍ２０が表示されている状態でユーザが操作を行うと、ＣＰＵ１１０は操作部１０４から供給された信号に基づき、ユーザの行った操作が設定メニュー画面Ｍ２０のテキストボックスＢＸ１０に拡張子を示す文字の入力であるか否かを判断する（図７、ステップＳＡ１）。
ＣＰＵ１１０は、ユーザの行った操作が文字列の入力であると判断した場合には（図７、ＳＡ１：ＹＥＳ）、ユーザが入力した文字列を設定メニュー画面Ｍ２０のテキストボックスＢＸ１０内に表示させる（図７、ＳＡ２）。ここでは、「ｊｐｅｇ」が入力されたとする。このとき、表示部１０５には、設定メニュー画面Ｍ２１（図８）が表示される。
当該操作が文字列の入力ではないと判断した場合には、ＣＰＵ１１０は、さらに、該供給された信号から、ユーザの行った操作が設定メニュー画面Ｍ２０の「設定」ボタンをクリックであるか否かを判断する（図７、ＳＡ３）。「設定」ボタンをクリックする旨の操作でないと判断した場合には（図７、ＳＡ３：ＮＯ）、ステップＳＡ１へ戻る。「設定」ボタンのクリックであると判断した場合には（図７、ＳＡ３：ＹＥＳ）、ＣＰＵ１１０は設定メニュー画面Ｍ２０のテキストボックスＢＸ１０に入力された文字列「ｊｐｅｇ」を抽出し、これを記憶部１０６に記憶させる（ＳＡ４）。ここでは、設定ボタンがクリックされたとする。
最後に、ＣＰＵ１１０は、拡張子を示す文字列を記憶部１０６に記憶させた後、取得する添付ファイルの拡張子の設定が終了したことをユーザに示すための設定メニュー画面Ｍ２２（図８）を表示部１０５に表示させる。
（２）電子メールの送受信
次に、携帯電話機１００−１および携帯電話機１００−２において、上記のファイル設定が完了したのちに、メールサーバ４００を介してメールの送受信を行われる時の動作について、図１３を用いて説明する。なお、以下に述べる動作において、携帯電話機１００−１および携帯電話機１００−２は、既に電源が入れられており、位置登録が行われて移動パケット通信網２００が提供するサービスを受けられる状態にあるものとする。また、携帯電話機１００−１のユーザと携帯電話機１００−２のユーザのいずれも、取得を希望する添付ファイルの拡張子を「ｊｐｅｇ」に設定したものとする。また、以下では、携帯電話機１００−１および携帯電話機１００−２のユーザのメールアドレスは、それぞれ「ｔａｒｏｕ＠ａｂｃ．ｃｏ．ｊｐ」および「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」であるとする。
（実施例１）
まず、携帯電話機１００−１から携帯電話機１００−２へ、拡張子が「ｍｉｄ」であるファイル「ｍｕｓｉｃｌ．ｍｉｄ」を添付した電子メールを送信する場合を考える。
まず、携帯電話機１００−１のユーザは、メールの本文の入力、携帯電話機１００−２のユーザのメールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」とメール本文とを入力し、添付ファイル「ｍｕｓｉｃｌ．ｍｉｄ」を添付する操作を行い、電子メールを作成する。
次に、携帯電話機１００−１のユーザが、作成した電子メールを送信する操作を行うと、ＣＰＵ１１０はＰＯＳＴメソッドを用いたＨＴＴＰリクエストを生成する。具体的には、このリクエストは、メールサーバ４００に記憶されている格納用ＣＧＩのＵＲＩ「ｈｔｔｐ：／／ａｂｃ．ｃｏ．ｊｐ／ｓｅｎｄ．ｃｇｉ」をＰＯＳＴメソッドのパラメータとし、ユーザが入力したメールアドレス、メール本文、添付ファイル、およびこれらに加えて携帯電話機１００−１の端末識別子「ＭＳ０００００１」を内包する。生成されたＨＴＴＰリクエストは、携帯電話機１００−１から送信され、メールサーバ４００の通信部４０２にて受信される（ステップＳ１０１）。
メールサーバ４００において、通信部４０２にて受信されたＨＴＴＰリクエストは、ＣＰＵ４０８へ供給される。ＣＰＵ４０８は、ＨＴＴＰリクエストを受信すると、当該ＰＯＳＴメソッドのパラメータであるＵＲＩで指定される格納用ＣＧＩを記憶部４０５から読み出して実行する。ＣＰＵ４０８は、格納用ＣＧＩを実行すると、当該ＨＴＴＰリクエストに内包されているメールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」をキーにして記憶部４０５を検索し、携帯電話機１００−２のユーザに割り当てられたメールボックスを探す。ＣＰＵ４０８は該当するメールボックスを見つけると、当該電子メールを識別するためのメール識別子を生成する。続いて、ＣＰＵ４０８は、ＨＴＴＰリクエストに内包されているメール本文と、送信元である携帯電話機１００−１の端末識別子と、添付ファイルと、生成されたメール識別子とを対応づけて当該メールボックスに格納する。
次に、ＣＰＵ４０８は、メールサーバ４００が携帯電話機１００−２のユーザ宛の電子メールを受信したことを示す着信通知を生成する。この着信通知には、当該メールボックスに格納されている電子メールのメール識別子が内包される。続いて、ＣＰＵ４０８は、着信通知の通知先となる携帯電話機１００−２を特定するために、当該電子メールの宛先を示すメールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」をキーにして、加入者データベース５００を検索する。ＣＰＵ４０８は、図２に示したデータの中から該当するメールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」を見つけると、このメールアドレスに対応づけて記憶されている端末識別子「ＭＳ０００００２」を抽出する。
ＣＰＵ４０８は、抽出された端末識別子で識別される携帯電話機１００−２を宛先として、生成した着信通知を送信する（ステップＳ１０２）。送信された着信通知は、携帯電話機１００−２の通信部１０２にて受信されたのちＣＰＵ１１０へ供給される。
着信通知を受信すると、メールサーバ４００のメールボックスに格納されている電子メールを取得するために、ＣＰＵ１１０はＧＥＴメソッドを用いたＨＴＴＰリクエストを生成する。このＨＴＴＰリクエストは、図１４に示すように、メールサーバ４００に記憶されている配信用ＣＧＩのＵＲＩ「ｈｔｔｐ：／／ａｂｃ．ｃｏ．ｊｐ／ｒｅｃｅｉｖｅ．ｃｇｉ」をＧＥＴメソッドのパラメータとする。配信用ＣＧＩのパラメータにおいて、取得するファイルの拡張子を示す「ｊｐｅｇ」が設定される。また、このＨＴＴＰリクエストは、携帯電話機１００−２の端末識別子「ＭＳ０００００２」と、取得しようとする電子メールのメール識別子「０００１」とを内包している。
生成されたＨＴＴＰリクエストは、携帯電話機１００−２から送信され（ステップＳ１０３）、メールサーバ４００の通信部４０２にて受信された後、ＣＰＵ４０８へ送られる。ＣＰＵ４０８は、当該ＨＴＴＰリクエストを受信すると、ＧＥＴメソッドのパラメータであるＵＲＩで指定される配信用ＣＧＩを記憶部４０５から読み出して実行する。
ＣＰＵ４０８はこの配信用ＣＧＩを実行すると、当該ＨＴＴＰリクエストに内包されている端末識別子「ＭＳ０００００２」をキーにして、加入者データベース５００を検索し、当該端末識別子に対応づけて記憶されている電子メールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」を加入者データベース５００から抽出する。
次にＣＰＵ４０８は、抽出された電子メールアドレス「ｈａｎａｋｏ＠ａｂｃ．ｃｏ．ｊｐ」をキーにして記憶部４０５のメールボックスを検索する。ＣＰＵ４０８は、携帯電話機１００−２のユーザに割り当てられたメールボックスを見つけると、当該メール識別子「０００１」で特定される電子メールを該メールボックスから抽出する。続いて、ＣＰＵ４０８は、読み出された電子メールに添付されているファイルを、端末識別子で指定される携帯電話機１００−２へ送信するか否かを決定する。
携帯電話機１００−２のユーザが取得を希望する添付ファイルの拡張子は、ＣＧＩのパラメータにおいて「ｊｐｅｇ」に設定されている一方、読み出した電子メールに添付されているファイルの拡張子は「ｍｉｄ」である。従って、ＣＰＵ４０８は、携帯電話機１００−２にこの添付ファイルを送信しないことを決定し、読み出された電子メールから添付されているファイル「ｍｕｓｉｃｌ．ｍｉｄ」を削除する。
次にＣＰＵ４０８は、添付ファイルを削除して得られた電子メールを内包するＨＴＴＰレスポンスを生成する。生成されたＨＴＴＰレスポンスは、メールサーバ４００から携帯電話機１００−２へ送信される（ステップＳ１０４）。
携帯電話機１００−２では、通信部１０２にてＨＴＴＰレスポンスが受信されると、受信されたＨＴＴＰレスポンスがＣＰＵ１１０へ送られる。ＣＰＵ１１０は、該ＨＴＴＰレスポンスから電子メールを抽出し、これを記憶部１０６に記憶させる。
（実施例２）
次に、同じく図３を参照しつつ、携帯電話機１００−２から携帯電話機１００−１へ、ＪＰＥＧ形式の画像ファイル「ｉｍａｇｅｌ．ｊｐｅｇ」を電子メールに添付して送信する場合について説明する。
まず、携帯電話機１００−２のユーザが、宛先のメールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」およびメール本文の入力を行い、「ｉｍａｇｅｌ．ｊｐｅｇ」を添付し、作成した電子メールを送信する操作を行うと、ＣＰＵ１１０は、ユーザが入力したメールアドレス、メール本文、添付ファイルおよび携帯電話機１００−２の端末識別子「ＭＳ０００００２」を内包するＰＯＳＴメソッドを用いたＨＴＴＰリクエストを生成する。
このＨＴＴＰリクエストは、メールサーバ４００に記憶されている格納用ＣＧＩのＵＲＩをＰＯＳＴメソッドのパラメータとし、ユーザが入力したメールアドレス、メール本文、添付ファイルおよび携帯電話機１００−２の端末識別子「ＭＳ０００００２」とを内包する。生成されたＨＴＴＰリクエストは、メールサーバ４００へ送信され（ステップＳ１０５）、通信部４０２にて受信されたのち、ＣＰＵ４０８へ送られる。
ＣＰＵ４０８は、ＨＴＴＰリクエストを受信すると、ＰＯＳＴメソッドのパラメータであるＵＲＩによって指定される格納用ＣＧＩを記憶部４０５から格納用ＣＧＩを読み出して実行する。具体的には、ＣＰＵ４０８は、ＨＴＴＰリクエストに内包されているメールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」をキーにして記憶部４０５のメールボックスを検索する。
ＣＰＵ４０８は、携帯電話機１００−１のユーザに割り当てられたメールボックスを見つけると、該電子メールを識別するためのメール識別子を生成する。ＣＰＵ４０８は、このＨＴＴＰリクエストに内包されているメール本文と、携帯電話機１００−２の端末識別子と、添付ファイルと、生成されたメール識別子とを対応づけてメールボックスに格納する。
次にＣＰＵ４０８は、携帯電話機１００−１のユーザ宛に電子メールが送信されたことを示す着信通知を生成する。この着信通知には、メールボックスに格納されている電子メールのメール識別子が内包される。
続いて、ＣＰＵ４０８は、着信通知の通知先となる携帯電話機１００−１を特定するために、加入者データベース５００を参照し、宛先を示すメールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」に対応付けて格納されている端末識別子「ＭＳ０００００１」を抽出する。
次に、ＣＰＵ４０８は、抽出された端末識別子で特定される携帯電話機１００−１を宛先として、生成した着信通知を送信する（ステップＳ１０６）。メールサーバ４００から送信された着信通知は、携帯電話機１００−１にて受信され携帯電話機１００−１のＣＰＵ１１０へ送られる。
着信通知を受信したＣＰＵ１１０では、メールサーバ４００のメールボックスに格納されている電子メールを取得するために、ＧＥＴメソッドを用いたＨＴＴＰリクエストを生成する。このＨＴＴＰリクエストは、図６に示したように、メールサーバ４００に記憶されている配信用ＣＧＩのＵＲＩをＧＥＴメソッドのパラメータとする。また、配信用ＣＧＩのパラメータは、取得するファイルの拡張子を示す「ｊｐｅｇ」に設定される。また、このＨＴＴＰリクエストは、図６に示したように、携帯電話機１００−１の端末識別子「ＭＳ０００００１」と、取得しようとする電子メールのメール識別子「０００１」とを内包している。
生成されたＨＴＴＰリクエストは、携帯電話機１００−１から送信され（ステップＳ１０７）、メールサーバ４００の通信部４０２にて受信された後、ＣＰＵ４０８へ送られる。
ＣＰＵ４０８は、該ＨＴＴＰリクエストを受信すると、ＧＥＴメソッドのパラメータであるＵＲＩによって指定される配信用ＣＧＩを記憶部４０５から読み出して実行する。具体的には、ＣＰＵ４０８は、ＨＴＴＰリクエストに内包されている端末識別子「ＭＳ０００００１」キーにして加入者データベース５００内を検索する。この結果、ＨＴＴＰリクエストに内包されている端末識別子「ＭＳ０００００１」に対応付けて格納されている電子メールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」が抽出される。
次にＣＰＵ４０８は、抽出された電子メールアドレス「ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ」をキーにして記憶部４０５内を検索する。この結果、携帯電話機１００−１のユーザに割り当てられたメールボックスから該メール識別子により指定される電子メールが抽出される。
次にＣＰＵ４０８は、抽出された電子メールに添付されているファイルを該端末識別子で指定される携帯電話機１００−１へ送信するか否かを判断する。ここで、携帯電話機１００−１が取得する添付ファイルの拡張子はＣＧＩのパラメータにて「ｊｐｅｇ」に設定されており、抽出された電子メールに添付されているファイルの拡張子もまた「ｊｐｅｇ」である。従って、ＣＰＵ４０８は、該添付ファイルを携帯電話機１００−１に送信すべきであると判定する。続いて、ＣＰＵ４０８は、該ファイルが添付されたままの電子メールを内包するＨＴＴＰレスポンスを生成する。生成されたＨＴＴＰレスポンスは、メールサーバ４００から携帯電話機１００−１へ送信される（ステップＳ１０８）。
携帯電話機１００−１では、通信部１０２にてＨＴＴＰレスポンスが受信されたのち、ＣＰＵ１１０へ供給される。ＣＰＵ１１０は、該ＨＴＴＰレスポンスを受信すると、該ＨＴＴＰレスポンスから電子メールを抽出しこれを記憶部１０６に記憶させる。
以上説明したように、本実施形態によれば、携帯電話機１００のユーザは、自分の所望する拡張子のファイルのみを、携帯電話機１００に受信させることが可能となる。また、ユーザは取得する添付ファイルの拡張子を携帯電話機１００にて一度設定すれば、それ以降、電子メールを受信するたびに添付ファイルを受信するか否かの操作を行う必要がない。以降のＨＴＴＰリクエストにその設定内容が反映されるからである。
＜３．変形例＞
上述した実施形態では、一例として、携帯電話機１００が画像ファイルおよび音楽ファイルを処理できることとした。しかしながら、携帯電話機１００が使用することができるファイルは、画像ファイルや音楽ファイルに限定されるものではない。本発明は任意の種類（拡張子）にも適用可能である。
上述した実施形態では、携帯電話機１００のユーザが、取得する添付ファイルの拡張子を設定する際に、一つの拡張子しか設定していないが、図１５に例示したように取得する添付ファイルを複数設定するようにしてもよい。この場合、例えば、携帯電話機１００が使用可能なファイルの拡張子を携帯電話機１００の記憶部１０６に予め記憶させておき、受信を希望する添付ファイルの拡張子を設定する際に、図１６に示すような設定メニュー画面を表示部１０５に表示させる。これにより、ユーザは表示された使用可能なファイルのうち、受信を希望するものを複数選ぶことができる。例えば、「ｊｐｅｇ」、「ｍｉｄ」および［ｇｉｆ」が設定された場合は、ＧＥＴメソッドのヘッダは図１７に示すようなものになる。メールサーバ４００において、このようなＨＴＴＰリクエストを受信した場合、ＣＰＵ４０８は、携帯電話機１００宛の電子メールの添付ファイルのいずれか一つに合致するか否かを判定する。
これとは逆に、図１８に示すように、ユーザが取得を希望しないファイルの拡張子を指定することとしてもよい。この場合、携帯電話機１００において、ＣＰＵ１１０は、携帯電話機１００で使用可能な全てのファイルの種類の中からユーザが指定したものを除外して得られたファイル種類をＨＴＴＰリクエストのヘッダに設定する。
このような態様によれば、携帯電話機１００のユーザは、取り扱い説明書などをみることなく、携帯電話機１００で使用可能なファイルの拡張子を容易に確認することが可能となるので、ユーザの利便性がさらに向上する。
なお、複数の拡張子の指定が可能な場合には、取得するファイルの拡張子を全て設定するのではなく、全てのファイルの取得を指定するＣＧＩパラメータを導入してもよい。例えば、ユーザは端末で処理できる形式の全てのファイルを受け入れたい場合は、図６に示すＨＴＴＰリクエストにおいて、例えば「？ＡＴＴ＝ｊｐｅｇ」に替えて、「？ＡＴＴ＝ａｌｌｆｉｇ」というパラメータが指定される。逆に、いかなる添付ファイルもファイルを受信したくない場合には、例えば、図６において、「？ＡＴＴ＝ｊｐｅｇ」に替えて、「？ＡＴＴ＝ｎｏｎｅ」というパラメータが指定される。メールサーバ４００において、ＣＰＵはこのようなＨＴＴＰリクエストを受信すると、「ａｌｌｆｉｇ」の場合は、いかなる添付ファイルであっても携帯電話機１００へ送信し、「ｎｏｎｅ」の場合は全ての添付ファイルを削除したのち携帯電話機１００へ送信する。
また、上述した実施形態では、ユーザが文字列をテキストボックスに入力することにより、添付ファイルの拡張子の指定を行っている。しかしながら、これに限定されず、プルダウンメニューやチェックボックスを用いて選択するようにしてもよい。あるいは、画面を通じてではなく、音声ガイダンスによってユーザにファイル種類の選択を促してもよい。
また、上述した実施形態では、電子メールの授受は移動パケット通信網２００内に収容されている携帯電話機１００−１と携帯電話機１００−２の間で行われている。しかしながら、電子メールの授受は移動パケット通信網２００内に限定されるものではない。例えば、ゲートウェイサーバ３００を介し、携帯電話機１００とインターネットに接続されているパーソナルコンピュータとの間でメールを授受するようにしてもよい。
また、上述した実施形態では、取得する添付ファイルの拡張子をＣＧＩのパラメータに設定して、携帯電話機１００が取得する添付ファイルの拡張子をメールサーバ４００へ知らせるようにした。しかしながら、取得する添付ファイルの拡張子をメールサーバ４００へ知らせる方法は、この方法に限定されない。例えば、ＨＴＴＰリクエストのリクエストヘッダに新たなヘッダを設けて、このヘッダに取得する添付ファイルの拡張子を設定するようにしてもよい。
上述した実施形態では、メールサーバ４００は、携帯電話機１００へ電子メールを送信した後、送信した電子メールをメールボックスに残すようにしているが、電子メールを携帯電話機１００へ送信後、送信した電子メールをメールボックスから削除するようにしてもよい。
この場合、メールサーバ４００は、携帯電話機１００から送信される電子メール受信確認を受信した後、当該電子メールを削除するようにしてもよい。
上述した実施形態では、携帯電話機１００が受信した電子メールの添付ファイルは、携帯電話機１００の記憶部１０６に記憶されるが、ＩＭＴ−２０００に準拠した携帯電話機においては、電子メールに添付されたファイルをＵＩＭに記憶させるようにしてもよい。ここで、ＵＩＭ（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅ）とは、契約者情報を記憶した不揮発性メモリを有するＩＣカードであり、ＩＭＴ−２０００（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ２０００）に準拠した携帯電話機では携帯電話機に着脱可能に実装されるものである。
この態様によれば、受信した携帯電話機では開けないファイルをメールサーバ４００から受信しても、添付ファイルを記憶したＵＩＭを、ファイルを使用可能な携帯電話機へ差し替えることにより、受信したファイルを使用することが可能となる。従って、添付ファイルの種類の設定においては、その携帯電話機が使用できるファイルに制限されない。これにより、添付ファイルを利用形態は多様化し、ユーザの利便性が高まる。
また、メールサーバが実行する制御プログラム、格納用ＣＧＩ、配信用ＣＧＩは、プログラムを作成した事業者が、インターネットなどのネットワークを介してメールサーバへ提供するようにしてもよい。また、これらのプログラムをＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やＤＶＤ−ＲＯＭなどの記録媒体に記録させて、当該サーバへ提供するようにしてもよい。
また、上述した実施形態では、携帯電話機１００にて実行されるプログラムはＲＯＭ１０８に記憶されているが、フラッシュメモリなどの書き換えが可能なメモリに記憶させるようにしてもよい。これにより、移動パケット通信網２００およびインターネットを介して、携帯電話機１００にて実行されるプログラムを提供することが可能となる。また、携帯電話機にて実行されるプログラムを上記記録媒体に記録させて提供する場合には、パーソナルコンピュータを用いてこれらの記録媒体からプログラムを読み出し、パーソナルコンピュータと携帯電話機１００とを有線もしくは無線により接続することにより携帯電話機のフラッシュメモリにプログラムを記憶させるようにしてもよい。
【図面の簡単な説明】
図１は、本発明の実施形態に係わる通信システム１０の全体構成を例示する図である。
図２は、加入者データベース５００に記憶されたデータのフォーマットを例示する図である。
図３は、携帯電話機１００のハードウェア構成を例示する図である。
図４は、携帯電話機１００の表示部１０５に表示される、電子メールを作成するためのメニュー画面を例示する図である。
図５は、携帯電話機１００が送信するＰＯＳＴメソッドを用いたＨＴＴＰリクエストのヘッダ部を例示する図である。
図６は、携帯電話機１００が送信するＧＥＴメソッドを用いたＨＴＴＰリクエストのヘッダ部を例示する図である。
図７は、携帯電話機１００にて行われる、ユーザが所望する添付ファイルの拡張子を設定する際の処理を例示するフローチャートである。
図８は、本発明の実施形態に係わる携帯電話機１００の表示部１０５に表示される、ユーザが所望する添付ファイルの拡張子を設定するための設定メニュー画面を例示する図である。
図９は、メールサーバ４００のハードウェア構成を例示する図である。
図１０は、メールサーバ４００が行う、電子メールの配信処理を例示するフローチャートである。
図１１は、メールサーバ４００にて実行される格納用ＣＧＩの処理を例示するフローチャートである。
図１２は、メールサーバ４００にて実行される配信用ＣＧＩの処理を例示するフローチャートである。
図１３は、電子メールの送受信における動作例を示すシーケンス図である。
図１４は、携帯電話機１００−２がメールサーバ４００へ送信するＨＴＴＰリクエストの書式を例示する図である。
図１５は、取得する添付ファイルの拡張子を複数設定する際における設定メニュー画面を例示する図である。
図１６は、ユーザが所望する添付ファイルの拡張子を設定する際における設定メニュー画面を例示する図である。
図１７は、携帯電話機１００が送信するＧＥＴメソッドを用いたＨＴＴＰリクエストのヘッダ部を例示する図である
図１８は、ユーザが所望する添付ファイルの拡張子を設定する際における設定メニュー画面を例示する図である。
【図１】
2003105426.tif 000003
【図２】
2003105426.tif 000004
【図３】
2003105426.tif 000005
【図４】
2003105426.tif 000006
【図５】
2003105426.tif 000007
【図６】
2003105426.tif 000008
【図７】
2003105426.tif 000009
【図８】
2003105426.tif 000010
【図９】
2003105426.tif 000011
【図１０】
2003105426.tif 000012
【図１１】
2003105426.tif 000013
【図１２】
2003105426.tif 000014
【図１３】
2003105426.tif 000015
【図１４】
2003105426.tif 000016
【図１５】
2003105426.tif 000017
【図１６】
2003105426.tif 000018
【図１７】
2003105426.tif 000019
【図１８】
2003105426.tif 000020
【国際調査報告】
2003105426.tif 000021
2003105426.tif 000022
2003105426.tif 000023
2003105426.tif 000024