"ヘッダ情報およびメール本文を含む電子メールを取得するメール取得部と、前記メール取得部により取得された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定するグルーピング部と、前記グルーピング部により特定された電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する表示部と、を備えることを特徴とする電子メール受信装置。前記グルーピング部は、当該電子メール受信装置から送信した電子メールも含めてグルーピングを行い、前記表示部は、当該電子メール受信装置から送信した電子メールを、前記メール取得部により取得された電子メールとともに、ディスプレイのメッセージ表示領域に表示することを特徴とする請求項1に記載の電子メール受信装置。前記表示部は、メッセージ表示領域とともに、送信メッセージを書き込むための領域を形成することを特徴とする請求項1または2に記載の電子メール受信装置。前記表示部は、当該電子メール受信装置から送信した電子メールのメッセージ表示領域と、前記メール取得部により取得された電子メールのメッセージ表示領域とを、左右方向にずらした位置に形成することを特徴とする請求項2または3に記載の電子メール受信装置。前記表示部は、当該電子メール受信装置から送信した電子メールのメッセージ表示領域の左側または右側に、その送信者を特定する情報を配置し、前記メール取得部により取得された電子メールのメッセージ表示領域の右側または左側に、取得された電子メールの送信者を特定する情報を配置することを特徴とする請求項4に記載の電子メール受信装置。ヘッダ情報およびメール本文を含む電子メールを取得し、取得した電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定し、特定した電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する、ことを特徴とする電子メール表示方法。コンピュータに、ヘッダ情報およびメール本文を含む電子メールを取得する機能と、取得した電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定する機能と、特定した複数の電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する機能と、を実現させるためのプログラム。請求項7に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。一般に、携帯型の電子機器に搭載されるメールアプリケーションは、電子メールをダウンロードすると、電子メールのプレビューを生成して、ディスプレイにプレビューリストを表示する。ユーザが、プレビューリストからプレビューを選択すると、メールアプリケーションは、そのプレビューに対応する電子メールの本文をディスプレイに表示する。携帯型の電子機器は据置型の電子機器と比べると、メモリ容量が小さい。そのため、携帯型の電子機器では、受信するデータサイズが大きくならないように、メールサーバからダウンロードする電子メールの数に上限が設定されることが多い。一般に、その上限数は数十程度であるため、1日に何百ものメールを受信するユーザにとっては、使い勝手がよいとは言えない。またメールアプリケーションの機能で、特定の送信者からの電子メールを特定のフォルダに振り分けるように設定できるものがある。このような設定を行っていれば、電子メールを送信者ごとに分類できるため、ユーザがメールを探す場合に便利である。しかしながら、携帯型の電子機器は、据置型の電子機器と比べると、入力インタフェースが充実しているとはいえないため、振分設定するにも手間がかかる。また携帯型の電子機器は、手軽さを売りとしているため、関連する複数の電子メールを簡易に閲覧できるような仕組みを提供できることが好ましい。そこで本発明は、改良されたメールアプリケーションを提供することを目的とする。上記課題を解決するために、本発明のある態様の電子メール受信装置は、ヘッダ情報およびメール本文を含む電子メールを取得するメール取得部と、メール取得部により取得された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定するグルーピング部と、グルーピング部により特定された電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する表示部とを備える。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。本発明の情報処理技術によると、改良されたメールアプリケーションを提供することが可能となる。図1は、本発明の実施例にかかる情報処理システム1を示す。情報処理システム1は、ユーザ端末である電子メール受信装置10と、メールサーバ8とを備える。本実施例において、電子メール受信装置10は、無線通信機能を有する携帯型の電子機器である。電子メール受信装置10は、アクセスポイント以下、APと呼ぶ2を介してネットワーク4に接続し、メールサーバ8から電子メールを受信する。AP2は、無線LANLocalAreaNetworkで電子メール受信装置10をネットワーク4に接続する中継装置として機能する。電子メール受信装置10は、無線LAN方式による通信機能を有してもよいが、第3世代移動通信システムなどの携帯電話通信方式により携帯電話網に接続して、メールサーバ8から電子メールを受信してもよい。なお電子メール受信装置10は、他の方式の無線通信機能を有してもよく、また有線通信によりメールサーバ8から電子メールを受信してもよい。電子メール受信装置10は、メールアプリケーションを起動することで、電子メールの送受信機能および表示機能を実現する。なおメールアプリケーションはバックグランドで起動されて、電子メールの送受信機能を実現してもよい。電子メール受信装置10は、たとえば携帯電話やPDAPersonalDigitalAssistant、携帯型ゲーム機であってよく、いずれの電子機器であってもメールアプリケーションを搭載したものであればよい。なお、本実施例のメールアプリケーションは、記憶容量が小さい電子機器において特に有用であるが、記憶容量が大きい電子機器、たとえば据置型のゲーム機においても有効に利用されることができる。以下では、電子メール受信装置10が、本実施例のメールアプリケーションを搭載した携帯型ゲーム機である場合を例にとる。図2は、実施例にかかる電子メール受信装置10の外観の一例を示す。電子メール受信装置10の表側、すなわち、ユーザが電子メール受信装置10を把持して操作するときにユーザに面する側には、指示入力ボタン21、方向キー22、Rボタン23、Lボタン24などの入力装置20と、表示装置68が備えられている。表示装置68には、ユーザの指やスタイラスペンなどによる接触を検知するためのタッチパネル69が併設されている。電子メール受信装置10の内部には、電子メール受信装置10の傾きを検知するモーションセンサ25が備えられている。なお電子メール受信装置10の裏側に、背面タッチパネルが備えられてもよい。電子メール受信装置10の側面には、メモリカードなどの記録メディアを装着するためのスロット図示せずなどの収容部が設けられる。また、電子メール受信装置10の側面には、ゲームファイルを記録した記録メディアを装着するためのスロット図示せずなどの収容部も設けられる。ユーザは、電子メール受信装置10を両手で把持した状態で、例えば、右手親指で指示入力ボタン21を操作し、左手親指で方向キー22を操作し、右手人差し指又は中指でRボタン23を操作し、左手人差し指又は中指でLボタン24を操作することができる。またタッチパネル69を操作する場合には、電子メール受信装置10を両手で把持した状態で、それぞれの親指でタッチパネル69を操作してもよく、また電子メール受信装置10を左手で把持した状態で、右手でタッチパネル69を操作してもよい。図3は、電子メール受信装置10の機能ブロック図である。表示装置68は、電子メール受信装置10の各機能により生成される画像を表示する。表示装置68は、液晶表示装置であってもよいし、有機EL表示装置であってもよい。タッチパネル69は、表示装置68の上に重ね合わせて設けられ、ユーザの指やペンなどによる接触を検知する。タッチパネル69は、抵抗膜方式、表面型静電容量方式、投影型静電容量方式など、いずれの方式のものであってもよい。電子メール受信装置10では、表示装置68およびタッチパネル69によりディスプレイが構成される。無線通信モジュール30はIEEE802.11b/g等の通信規格に準拠した無線LANモジュールによって構成され、AP2を介して、ネットワーク4に接続する。携帯電話モジュール32は、ITUInternationalTelecommunicationUnion;国際電気通信連合によって定められたIMT-2000InternationalMobileTelecommunication2000規格に準拠した第3世代3rdGenerationデジタル携帯電話方式に対応し、携帯電話網6に接続する。携帯電話モジュール32には、携帯電話の電話番号を特定するための固有のID番号が記録されたSIMカードが挿入される。インタフェース50において、LEDLightEmittingDiode51は、無線通信モジュール30や携帯電話モジュール32などがデータの送受信をしている際に点滅する。モーションセンサ25は、電子メール受信装置10の動きを検知する。マイク52は、電子メール受信装置10の周辺の音声を入力する。スピーカ53は、電子メール受信装置10の各機能により生成される音声を出力する。ステレオ入出力端子54は、外部のマイクからステレオ音声を入力し、外部のヘッドフォンなどへステレオ音声を出力する。入力装置20は、前述した操作キーなどを含み、ユーザの操作入力を受け付ける。CPUCentralProcessingUnit40は、メインメモリ44にロードされたプログラムなどを実行し、本実施例ではメールアプリケーションを実行する。GPUGraphicsProcessingUnit42は、画像処理に必要な計算を実行する。メインメモリ44は、RAMRandomAccessMemoryなどにより構成され、電子メール受信装置10で動作するプログラムやデータなどを記憶する。ストレージ46は、NAND型フラッシュメモリNANDtypeflashmemoryなどにより構成され、内蔵型の補助記憶装置として利用される。GPSGlobalPositioningSystem制御部60は、GPS衛星からの信号を受信し、現在位置を算出する。USB制御部61は、USBUniversalSerialBusで接続された周辺装置との間の通信を制御する。ビデオ出力制御部64は、HDMIなどの規格に基づいて、外部表示装置へビデオ信号を出力する。メモリカード制御部62は、スロットなどの収容部図示せずに装着されたフラッシュメモリなどの記録メディア80との間のデータの読み書きを制御する。リムーバブルな記録メディア80が収容部に装着されると、記録メディア80は、外付け型の補助記憶装置として利用される。メディアドライブ63は、ゲームファイルを記録したゲーム記録メディア70が装着される収容部であり、ゲーム記録メディア70との間のデータの読み書きを制御する。以上の各機能ブロックはバス90によって互いに接続されている。以下、本実施例のメールアプリケーションについて説明する前に、POPPostOfficeProtocol3の基本動作について説明する。POP3は、認証Authentication、処理Transaction、および更新Updateの3つの手順で構成される。認証手順では、まず、クライアントがユーザIDをメールサーバに送信する。メールサーバは、ユーザIDをもとにメールボックスを特定する。次にクライアントは、パスワードをメールサーバに送信する。メールサーバは、パスワードをもとにユーザを確認して認証する。認証が成功すると、処理手順が開始される。図4は、認証手順の後に実行される処理手順および更新手順のシーケンス図を示す。図4において、S10~S23のステップが、処理手順を示し、S30~S33のステップが、更新手順を示す。なお、以下のシーケンスは、POP3の基本動作の一例である。<処理手順>S10クライアントが、STATコマンドをメールサーバに送信する。S11メールサーバは、メールボックスにある電子メールの数と、電子メールの総バイト数をクライアントに返す。201MBは、電子メールの総数が20個、総バイト数が1MBメガバイトであることを示している。S12クライアントが、LISTコマンドをメールサーバに送信する。S13メールサーバのメールボックスでは、電子メールの到着順に1番からメッセージ番号が割り振られている。メールサーバは、LISTコマンドを受けると、各電子メールのメッセージ番号とバイト数を含めたメッセージリストlistを、クライアントに返す。ここでは、20個の電子メールに、それぞれ1~20のメッセージ番号が割り振られているものとする。S14クライアントは、RETRコマンドをメールサーバに送信する。ここで、RETR1は、メッセージ番号1の電子メールの取得要求を意味する。S15メールサーバは、メッセージ番号1の電子メールをクライアントに送信する。これにより、クライアントは、メッセージ番号1の電子メールを取得できる。S16クライアントは、DELEコマンドをメールサーバに送信する。ここで、DELE1は、メッセージ番号1の電子メールに削除マークを付けるコマンドである。S17メールサーバは、メッセージ番号1の電子メールに削除マークを付ける。なお、削除マークを付けるだけで、電子メールの削除はまだ行われていない。クライアントは、RETRコマンドとDELEコマンドを、メッセージリストに含まれる全てのメッセージ番号を指定して送信することで、メールボックスに蓄積されている全ての電子メールを取得し、またメールボックスに蓄積されている全ての電子メールに削除マークを付ける。S20クライアントは、RETRコマンドをメールサーバに送信する。ここで、RETR20は、メッセージ番号20の電子メールの取得要求を意味する。S21メールサーバは、メッセージ番号20の電子メールをクライアントに送信する。これにより、クライアントは、メッセージ番号20の電子メールを取得できる。S22クライアントは、DELEコマンドをメールサーバに送信する。ここで、DELE20は、メッセージ番号20の電子メールに削除マークを付けるコマンドである。S23メールサーバは、メッセージ番号20の電子メールに削除マークを付ける。以上で、処理手順が完了する。<更新手順>S30クライアントは、RESTコマンドをメールサーバに送信する。RESTコマンドは、メールボックスの電子メールに付けた削除マークを外すためのコマンドである。クライアントは、取得した電子メールをメールボックスから削除したくない場合、RESTコマンドを送信することで、取得した電子メールをメールボックスに残すことができる。S31メールサーバは、電子メールの削除マークを外す。S32クライアントは、QUITコマンドをメールサーバに送信する。QUITコマンドは、削除マークが付いている電子メールをメールボックスから削除し、TCPコネクションを切断するためのコマンドである。S33メールサーバは、削除マークが付いている電子メールをメールボックスから削除する。S30でRESTコマンドが送信されている場合には、電子メールから削除マークが外されているため、メールボックスの電子メールは、削除されずに残されることになる。本実施例の電子メール受信装置10は、携帯型の端末装置であり、ユースケースとして、ユーザが屋外で電子メールを確認する場合に利用されることが想定される。そのため、電子メール受信装置10は、RESTコマンドを送信して、メールボックスに電子メールを残す設定にしておくことが好ましい。以上で、更新手順が完了する。この後、クライアントとメールサーバ間のTCPコネクションが切断される。なお、本実施例ではメールボックスに電子メールを残す設定にするため、削除マークに関するステップであるS16,S17,S22,S23,S30,S31は、シーケンスから除外してもよい。なお、図4に示す基本シーケンスによると、クライアントは、メールボックスに蓄積された全ての電子メールを受信することになる。そうすると、同じ電子メールを何度も受信する状況が発生するため、クライアントは、取得済みの電子メールと、新しくメールボックスに到着した電子メールとを区別し、新しい電子メールだけを受信することが好ましい。そのために、POP3では、UIDLコマンドが用意されている。図4に示すシーケンスにおいて、クライアントがRETRコマンドを送信する前つまり、S14の前に、UIDLコマンドをメールサーバに送信する。メールサーバは、メールボックスに蓄積している電子メールに、それぞれを一意に特定するIDを付加しておき、メールサーバは、UIDLコマンドを受けると、メッセージ番号と電子メールIDとを対応付けた対応リストを、クライアントに送信する。その後、クライアントは、RETRコマンドを送信して、電子メールを取得すると、取得した電子メールのIDを記録していく。クライアントは、次回のアクセスの際にもUIDLコマンドで電子メールIDを取得することで、前回取得していないIDをもつ電子メールだけを、RETRコマンドで取得するようにする。これにより、同じ電子メールを重複して取得しないようにできる。本実施例の電子メール受信装置10は、POP3の仕組みを用いて、メールサーバ8から電子メールを受信する。電子メール受信装置10において、メールアプリケーションは、受信した電子メールを記録メディア80に蓄積する。記録メディア80は数GBギガバイトの記憶容量を有しており、仮に電子メール受信装置10がメールアプリケーションしか実行しないのであれば、記録メディア80の容量は十分といえる。しかしながら本実施例の電子メール受信装置10はゲーム機であるため、記録メディア80には、ゲームサーバからダウンロードしたゲームプログラムや、ゲームのセーブデータなども記録される。そのため、メールアプリケーションが、無制限に記録メディア80を利用することは好ましくない。そこで電子メール受信装置10では、メールアプリケーションに割り当てられる記憶容量に制限が設けられる。利用可能な容量は、たとえば10MBであり、メールアプリケーションは、10MBの容量を効率的に利用して、ユーザに効果的に電子メールを提示する機能をもつ。第1実施例第1実施例では、ユーザに受信メールを提示するメールアプリケーションを提供する。このメールアプリケーションは、起動されると、ディスプレイに電子メールのプレビューリストを表示する。各メールプレビューは、たとえば件名、送信者、送信日時、メール本文メッセージの一部を含んで表示される。ユーザは、プレビューリストを見て、読みたい電子メールのプレビューを選択すると、メールアプリケーションは、選択された電子メールの本文をディスプレイに表示する。メールアプリケーションはPOP3で電子メールの受信を行うが、図4に示すシーケンスをそのまま採用すると、メールボックスに蓄積されている全ての電子メールUIDLコマンドを用いる場合には、未読の全ての電子メールを取得するため、受信するデータサイズは大きくなる。この理由から、従来のメールアプリケーションは、ダウンロードする電子メールの数を制限して、携帯型電子端末に保存されるデータサイズを小さくするようにしていた。従来のメールアプリケーションは、ダウンロードする電子メールの数を数十程度に制限しており、その結果、ダウンロードした電子メールから生成されるプレビューは、ダウンロードした電子メールの数しかユーザに提示できないという問題があった。そこで、第1実施例のメールアプリケーションは、電子メールを受信すると、ヘッダ情報の少なくとも一部およびメール本文の少なくとも一部からプレビュー構成データを生成してキャッシュし、プレビュー構成データの生成後は、受信した電子メールを破棄するようにする。つまり、一度電子メールを受信しても、その電子メールはプレビュー構成データの生成のためだけに使用され、電子メール自体は記録メディア80に記録されない。またプレビュー構成データのサイズは小さいため、数百~数千のプレビュー構成データをキャッシュしたとしても、全文受信をした場合と比べると、そのデータサイズは著しく小さい。これにより、記録メディア80に記録するデータ量を低減できるとともに、プレビューリストに含めるプレビューの数を多くでき、メールアプリケーションの利便性を高めることができる。なお、プレビュー構成データを生成するために電子メールを受信する際、TOPコマンドを利用して電子メールのヘッダ情報と、所定行数のメッセージをダウンロードした時点で電子メールの受信を打ち切ることで、ダウンロードするデータ量を抑えてもよい。図5は、第1実施例の電子メール受信装置10における電子メール受信機能を実行するための機能ブロックを示す。図5では、メインメモリ44やGPU42などの図示は省略している。電子メール受信装置10は、入力装置20、タッチパネル69、入力部92、CPU40、記録メディア80および表示装置68を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。入力部92は、入力装置20およびタッチパネル69から入力されるユーザによる操作指示を受け付ける。記録メディア80は、メールアプリケーションが使用するデータを記録する。なお、記録メディア80の代わりに、他の記録装置、たとえばストレージ46が利用されてもよい。CPU40は、インタフェース94、リスト取得部100、メール取得部102、プレビュー生成部104、コマンド送信部106、表示部108および記録管理部120を備える。インタフェース94、リスト取得部100、メール取得部102、プレビュー生成部104、コマンド送信部106および表示部108の各機能は、メールアプリケーションにより実現される。記録管理部120は、メールアプリケーションが利用する容量が上限たとえば10MBを超えないように、メールアプリケーションによる記録メディア80の利用状況を管理する。なお後述するように、電子メール受信装置10は、第1実施例のメールアプリケーションだけでなく、第2実施例のメールアプリケーションも搭載しており、記録管理部120は、これら複数のメールアプリケーションによる記録メディア80の利用状況を管理して、トータルで利用する容量が上限を超えないように監視している。入力部92が、メールアプリケーションの起動指示を受け付けると、第1実施例のメールアプリケーションが起動され、コマンド送信部106が、図4に示す認証手順を実行する。認証手順が終了すると、コマンド送信部106は、S10に示すSTATコマンド、S12に示すLISTコマンドを、インタフェース94を介して無線通信モジュール30からメールサーバ8に送信する。また、コマンド送信部106は、UIDLコマンドも送信する。リスト取得部100は、メールサーバ8より、各電子メールのメッセージ番号とバイト数を含めたメッセージリストlistを取得する。また、リスト取得部100は、UIDLコマンドに応じてメールサーバ8から送信される電子メールIDとメッセージ番号との対応リストも取得する。リスト取得部100は、メッセージリストおよび対応リストを、リスト保持部140に記録する。コマンド送信部106は、リスト保持部140に記録されたリストを参照して、図4のS14に示すRETRコマンドを、インタフェース94を介して無線通信モジュール30からメールサーバ8に送信する。RETRコマンドには、電子メールのメッセージ番号が含まれており、メールサーバ8は、RETRコマンドに含まれるメッセージ番号の電子メールをメールボックスから抽出し、電子メール受信装置10に送信する。メール取得部102は、ヘッダ情報およびメール本文を含む電子メールを取得する。メール取得部102は、取得した電子メールをプレビュー生成部104に渡す。プレビュー生成部104は、電子メールからプレビュー構成データを生成する。具体的にプレビュー生成部104は、電子メールからヘッダ情報の少なくとも一部と、メール本文の少なくとも一部を抽出して、所定のデータサイズの範囲内でプレビュー構成データを生成する。プレビュー構成データは、表示装置68に表示されてメールのプレビューを構成するためのデータである。本実施例においてプレビュー生成部104は、ヘッダ情報から件名Subject、送信者From、送信日時Dateを抽出し、またメール本文から所定文字数の範囲内でテキストを抽出し、プレビュー構成データを生成する。プレビュー構成データは、キャッシュ部142にキャッシュされる。なお、プレビュー生成部104は、ヘッダ情報から宛先ToCcを抽出して、プレビュー構成データに含めてもよい。プレビュー生成部104は、プレビュー構成データを生成すると、メール取得部102により取得された電子メールを破棄する。つまり、プレビュー構成データの生成時、メール取得部102で取得された電子メールは、プレビュー構成データの生成のために利用され、利用された後は、記録メディア80のメール蓄積部144に蓄積されない。これにより、ユーザがメール本文を読むか明らかでない電子メールを記録しないで済むようになる。コマンド送信部106は、リスト保持部140に記録されたリストを参照して、未取得の電子メールについてのRETRコマンドおよびDELEコマンドをメールサーバ8に送信する。プレビュー生成部104は、メール取得部102により取得された電子メールをもとにプレビュー構成データを生成し、キャッシュ部142は、生成されたプレビュー構成データをキャッシュする。プレビュー生成部104は、プレビュー構成データのサイズを、たとえば2KBキロバイト以下に制限する。メールアプリケーションに割り当てられる記録メディア80の容量は、たとえば10MBであるが、記録メディア80には、キャッシュ部142だけでなく、リストを保持するリスト保持部140や、電子メールを蓄積するメール蓄積部144なども形成されている。そのため、リスト保持部140、キャッシュ部142およびメール蓄積部144のそれぞれが使用する容量を低減することで、全体として使用する容量を10MBまでに抑える必要がある。そのため、プレビュー構成データのサイズを所定値以下に設定して、キャッシュ部142の使用容量を小さくすることが好ましい。そのような理由から、プレビュー構成データは、さらに小さいデータサイズたとえば、512バイトまたは256バイト以下に制限されてもよい。また、キャッシュ部142がキャッシュするプレビュー構成データの数にも上限が設定されることが好ましい。プレビューリストが表示装置68に表示されると、ユーザはタッチパネル69を操作して、プレビューリストをスクロールする。ユーザにもよるが、大体200件程度のプレビューをスクロールできれば、受信メッセージリストとしては十分であろうと考えられる。そこでキャッシュ部142は、200件までのプレビュー構成データをキャッシュできるようにする。なお、ユーザが、キャッシュ部142にキャッシュされていないプレビューを見る場合、つまりは200件を超えるプレビューを見る場合には、コマンド送信部106が、任意のタイミングで、リスト保持部140に記録されたリストを参照して、RETRコマンドをメールサーバ8に送信し、プレビュー生成部104がプレビュー構成データを生成する。このときプレビュー生成部104は、LRULeastRecentlyUsed方式などに代表されるキャッシュアルゴリズムにより、キャッシュ部142におけるキャッシュ数が上限200件を超えないように、キャッシュ部142からプレビュー構成データを削除することが好ましい。これにより、キャッシュ部142で使用する容量を、400KB=2KB×200件以下に抑えることができる。なお、記録メディア80の利用可能な残量に余裕があれば、キャッシュ部142は、200件を超えてプレビュー構成データをキャッシュしてもよい。上記したように、プレビュー構成データのサイズは、2KB以下に制限される。そのため、仮に1つの電子メールのデータサイズが1MBあるような場合、1MB全てをダウンロードしてからプレビュー構成データを生成することは時間的に効率的ではない。また、1MB全てをダウンロードすることは、結局は破棄するデータであるにもかかわらず、ダウンロード時に記憶容量を無駄に使用することになる。また電子メール受信装置10はバッテリ駆動の端末装置であるため、電力消費の観点からも好ましくない。そこでメール取得部102は、電子メールを、先頭から所定のデータサイズの範囲内で取得し、範囲を超えた分については取得しないようにしてもよい。プレビュー構成データは、ヘッダ情報の一部と、メール本文の一部から生成されるが、ヘッダ情報は、電子メールの先頭部分に配置され、また抽出するメール本文も、ボディ部分の最初に記載されているテキストであればよい。そこで、たとえば電子メールのデータを先頭から2.5KB~3KB程度のサイズ分だけ取得できれば、2KB以下のプレビュー構成データを作成するに十分である。そこで、メール取得部102は、取得する電子メールのサイズをたとえば2.5KB程度までとし、2.5KBを超える部分については取得しないようにする。取得する電子メールのサイズを2.5KB程度に制限する方法の例を示す。1つの例として、メール取得部102がTOPコマンドを使用し、メッセージ本文をダウンロードする行数を予め指定する。これによりメール取得部102は、電子メールのヘッダと、所定行数のメッセージをダウンロードした時点で、電子メールの受信を打ち切ることができる。なお、TOPコマンドの使用は、プレビュー構成データ生成用の電子メールの取得時のみに行われる。図示していないが、メールアプリケーションは、メール取得部102がプレビュー構成データ生成用の電子メールを取得しているか、またはメッセージ本文表示のための電子メールを取得しているかのステータスを管理する機能を有し、その機能により、プレビュー構成データ生成用の電子メールの取得時に、ダウンロードするメール本文の行数が設定される。別の例として、受信データ量が、設定されたデータサイズ2.5KBを超えた場合に、インタフェース94がTCPセッションを強制的に終了させてもよい。TCPセッションの強制終了は、インタフェース94によって行われてもよく、またメール取得部102により制御されてもよい。このように、プレビュー構成データの生成時、メール取得部102が、プレビュー構成データの生成に必要なデータサイズの電子メールを取得するようにすることで、プレビュー構成データの生成効率を高めることができる。表示部108は、キャッシュ部142によりキャッシュされたプレビュー構成データを用いて、プレビューリストを表示装置68に表示する。図6は、プレビューリストの表示例を示す。プレビューリストには、複数のプレビュー150a、150b、150c、150dが含まれる。図6において、全てのプレビュー150に、メール本文を取得していないことを示す未読マーク151が付加されているが、たとえば、いずれかのプレビュー150が選択されて、メール取得部102が、電子メールの全体を取得して、表示部108が表示装置68に表示すると、未読マーク151は外される。ユーザがタッチパネル69を上下方向にフリックしてプレビューリストをスクロールすると、表示されるプレビューが変更される。ユーザは、閲覧したい電子メールのプレビュー150をタップして選択する。コマンド送信部106は、プレビューが選択されると、選択されたプレビューにより特定される電子メールの送信を要求するRETRコマンドをメールサーバ8に送信する。具体的には、コマンド送信部106が、リスト保持部140から、選択されたプレビューに対応するメッセージ番号を取得し、RETRコマンドに含めて、メールサーバ8に送信する。メール取得部102は、メールサーバ8から電子メールを取得すると、メール蓄積部144に記録し、表示部108は、メール本文を表示装置68に表示する。このように、第1実施例のメールアプリケーションでは、メール蓄積部144に蓄積する電子メールは、プレビューリストの生成後に、ユーザからの閲覧要求にしたがってダウンロードしたものに限定されるため、メール蓄積部144の使用容量を低減することができる。記録管理部120は、記録メディア80の利用状況を監視し、記憶内容の参照された時間などを記録している。記録管理部120は、利用容量が所定の上限容量10MBに近づくと、たとえばLRULeastRecentlyUsed方式などに代表されるキャッシュアルゴリズムにより、記録メディア80のデータを削除して、使用可能な容量を増やすようにする。図7は、第1実施例のメールアプリケーションによるメール表示処理のフローチャートである。リスト取得部100が、メールサーバ8から、メールボックスに蓄積されている電子メールのメッセージリストを取得し、リスト保持部140に保持させるS50。メール取得部102は、RETRコマンドを送信して、メールサーバ8から電子メールを取得するS52。このときメール取得部102は、電子メールを、データの先頭から所定のデータサイズの範囲内で取得する。プレビュー生成部104は、電子メールから、ヘッダ情報の少なくとも一部と、メール本文の少なくとも一部を抽出して、プレビュー構成データを生成し、キャッシュ部142にキャッシュさせるS54。S52,S54のステップは、繰り返し実行されるS56のN。メール取得部102が、メッセージリストに含まれる全ての電子メールを取得し、プレビュー生成部104がプレビュー構成データを生成するとS56のY、表示部108が、キャッシュ部142にキャッシュされたプレビュー構成データを用いて、プレビューリストを表示装置68に表示するS58。なお、キャッシュ部142において、キャッシュするプレビュー構成データの数は所定数たとえば200個に制限されているため、メール取得部102が、メッセージリストに含まれる電子メールのうち、最新のものから200個の電子メールを取得し、プレビュー生成部104がプレビュー構成データを生成した場合には、メール取得部102は、それ以上の電子メールの取得を行わない。ユーザは、プレビューリストをスクロール表示してS60のN、閲覧したい電子メールのプレビューを選択するS60のY。このときコマンド送信部106は、選択されたプレビューにより特定される電子メールのRETRコマンドをメールサーバ8に送信する。メール取得部102は、メールサーバ8から電子メールを取得しS62、メール蓄積部144に蓄積すると、表示部108は、表示装置68にメール本文を表示するS64。第2実施例第2実施例では、電子メールをグルーピングしてユーザに提示するメールアプリケーションを提供する。このメールアプリケーションは、電子メールのヘッダ情報に含まれる送信者Fromのメールアドレスと宛先ToCcのメールアドレスの集合が一致する電子メールをグルーピングして表示する。以下、理解を容易にするために、送信者のメールアドレス、宛先のメールアドレスを、それぞれ送信者、宛先の名前に置き換えて説明する。たとえば、送信者がAさんで、宛先がBさん、Cさんである電子メールと、送信者がBさんで、宛先がAさん、Cさんである電子メールは、送信者および宛先の集合がともにAさん、Bさん、Cさんであるため、同じグループに属する。一方、送信者がAさんで、宛先がBさん、Cさんである電子メールと、送信者がAさんで、宛先がBさん、Cさん、Dさんである電子メールは、送信者および宛先の集合が異なるため、別のグループに属する。このように、第2実施例のメールアプリケーションは、送信者および宛先の集合が完全一致する電子メールをまとめて1つのグループとする処理を行う。図8は、第2実施例の電子メール受信装置10における電子メール表示機能を実行するための機能ブロックを示す。図8では、メインメモリ44やGPU42などの図示は省略している。電子メール受信装置10は、入力装置20、タッチパネル69、入力部92、CPU40、記録メディア80および表示装置68を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。入力部92は、入力装置20およびタッチパネル69から入力されるユーザによる操作指示を受け付ける。記録メディア80は、メールアプリケーションが使用するデータを記録する。なお、記録メディア80の代わりに、他の記録装置、たとえばストレージ46が利用されてもよい。CPU40は、インタフェース194、リスト取得部200、メール取得部202、コマンド送信部204、メール送信部206、表示部208、グルーピング部210および記録管理部120を備える。インタフェース194、リスト取得部200、メール取得部202、コマンド送信部204、メール送信部206、表示部208およびグルーピング部210の各機能は、メールアプリケーションにより実現される。記録管理部120は、メールアプリケーションが利用する容量が上限たとえば10MBを超えないように、メールアプリケーションによる記録メディア80の利用状況を管理する。なお、記録管理部120は、第1実施例の電子メール受信装置10においても設けられている。記録管理部120は、電子メール受信装置10に複数のメールアプリケーションが実装されている場合であっても、複数のメールアプリケーションがトータルで利用する容量が上限を超えないように、記録メディア80の利用状況を管理している。入力部92が、メールアプリケーションの起動指示を受け付けると、第2実施例のメールアプリケーションが起動される。第2実施例のメールアプリケーションは、第1実施例で説明したプレビューを生成しないため、図4に示す認証手順、処理手順、更新手順を実行する。なおメールアプリケーションに割り当てられる記憶容量には上限10MBが設定されているため、第2実施例のメールアプリケーションで送受信される電子メールは、メッセージの文字数が制限されるなどして、電子メールのデータサイズが小さくされていることが好ましい。コマンド送信部204は、STATコマンド、LISTコマンドを、インタフェース194を介して無線通信モジュール30からメールサーバ8に送信する。また、コマンド送信部204は、UIDLコマンドも送信する。リスト取得部200は、メールサーバ8より、各電子メールのメッセージ番号とバイト数を含めたメッセージリストlistを取得する。また、リスト取得部200は、UIDLコマンドに応じてメールサーバ8から送信される電子メールIDとメッセージ番号との対応リストも取得する。リスト取得部200は、メッセージリストおよび対応リストを、リスト保持部240に記録する。コマンド送信部204は、リスト保持部240に記録されたリストを参照して、RETRコマンドを、インタフェース194を介して無線通信モジュール30からメールサーバ8に送信する。メールサーバ8は、RETRコマンドに含まれるメッセージ番号の電子メールをメールボックスから抽出し、電子メール受信装置10に送信する。メール取得部202は、ヘッダ情報およびメール本文を含む電子メールを取得し、メール蓄積部242に蓄積する。なお第2実施例のメールアプリケーションは、IMAPInternetMessageAccessProtocolを利用して、電子メールの送受信を行ってもよい。グルーピング部210は、メール蓄積部242に蓄積された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定して、グルーピングを行う。具体的にグルーピング部210は、ヘッダ情報に含まれる送信者From、宛先ToCcのメールアドレスを参照し、電子メールごとに送信者と宛先の集合を生成する。たとえば、ある電子メールの送信者がAさん、宛先がBさん、Cさんである場合、その電子メールの送信者および宛先の集合は、{A、B、C}である。また、別の電子メールの送信者がBさん、宛先がAさん、Cさんである場合、その電子メールの送信者および宛先の集合は、{A、B、C}である。したがって、この2つの電子メールの送信者および宛先の集合は完全一致し、グルーピング部210は、この2つの電子メールを、同一のグループに振り分ける。たとえば、グルーピング部は、グループを特定するグループIDを設定し、各電子メールと、グループIDとを対応付けたデータベースを作成してもよい。なお、電子メール受信装置10において、ユーザは、入力装置20またはタッチパネル69からメッセージを入力して送信メールを生成できる。メール送信部206は、宛先を特定して電子メールを送信するとともに、送信した電子メールをメール蓄積部242に蓄積する。グルーピング部210は、受信した電子メールだけでなく、送信した電子メールも含めてグルーピングを行う。表示部208は、グルーピング部210により分類されたグループを、表示装置68に表示する。このGUIGraphicalUserInterfaceにより、電子メールをフォルダに振り分けたような状態がユーザに提供される。図9は、グループリストの表示例を示す。グループリストには、分類されたグループを特定するグループ構成情報250a、250b、250c、250dが含まれる。各グループ構成情報は、グループを構成する自分以外のメンバの名前と、そのメンバのアイコン画像を含む。たとえば、グループ構成情報250aは、そのグループを構成するメンバが自分、Ken、Taro、Jiroであることを示し、グループ構成情報250bは、そのグループを構成するメンバが自分、Ken、Taroであることを示している。表示部208は、グループに対して送信された最新の電子メールの送信日時が新しい順に、グループ構成情報250を上から並べて表示する。ユーザが、タッチパネル69を上下方向にフリックしてグループリストをスクロールすると、表示されるグループ構成情報が変更される。ユーザは、電子メールを閲覧したいグループ構成情報250をタップして選択する。ここでは、グループ構成情報250bが選択されたものとする。図10は、メッセージの表示画面例を示す。メッセージ画面には、グループメンバのアイコン画像を表示するメンバアイコン表示領域260が形成される。図10の例では、メンバアイコン表示領域260において、左から順に、自分、Ken、Taroのアイコン画像が表示されている。表示部208は、グループ内で送信された電子メールのメール本文を、メッセージ表示領域264、266に表示する。ここで、メッセージ表示領域264には、自分が他のメンバKenとTaroに対して送信したメッセージが表示されており、メッセージ表示領域266には、Kenが自分とTaroに対して送信したメッセージが表示されている。このように、表示部208は、メール送信部206より送信した電子メールを、メール取得部202により取得された電子メールとともに表示する。このように、グループ内で送信された電子メールであれば、送信メールも受信メールもまとめて表示することで、ユーザは、グループ内でどのような情報伝達があったのかを瞬時に把握することができる。なお、自分が送信した電子メールであるか、または受信した電子メールであるかを容易に認識できるようにするために、表示部208は、自分の送信メッセージが表示されるメッセージ表示領域264と、メール取得部202により取得された電子メールのメッセージ表示領域266とを、左右方向にずらした位置に形成する。図10の例では、メッセージ表示領域264に対して、メッセージ表示領域266が所定長さだけ右側にシフトした位置に形成されている。また自分の送信メッセージが表示されるメッセージ表示領域264に対して、右側に自分のアイコン画像を表示し、受信メッセージが表示されるメッセージ表示領域266に対しては、左側にメンバのアイコン画像を表示するようにしている。この左右は逆であってもよいが、アイコン画像とメッセージ表示領域とを横並びで表示する際に、自分と他のメンバのアイコン画像の配置を逆にすることで、送信メッセージであるか受信メッセージであるかの判断を容易に行えるようになる。また表示部208は、メッセージ表示領域264、266以外の位置に、送信メッセージを書き込むためのメッセージ書込領域262を形成する。メッセージ書込領域262はウィンドウ形式で形成されてよい。表示部208が、メッセージ表示領域264、266と同一画面にメッセージ書込領域262を表示することで、ユーザは、送信済みメールまたは受信済みメールに含まれるメッセージを見ながら、メッセージをメッセージ書込領域262に書き込むことができ、グループ内でのコミュニケーションを円滑にすることが可能となる。図11は、第2実施例のメールアプリケーションによるメール表示処理のフローチャートである。メール取得部202がメールサーバ8から電子メールを取得し、メール蓄積部242に蓄積するS80。グルーピング部210は、メール蓄積部242に蓄積された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定し、グルーピングするS82。表示部208は、表示装置68にグループリストを表示するS84。ユーザは、グループリストをスクロール表示してS86のN、閲覧したいグループを選択するS86のY。表示部208は、選択されたグループのIDを付与された電子メールをメール蓄積部242から抽出し、新しい順に上から並べて、電子メールのメール本文を表示するS88。以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。"