JP2012252596A - 電子メール受信装置および電子メール表示方法 - Google Patents

Abstract

【課題】改良されたメールアプリケーションを提供する。
【解決手段】メール取得部２０２は、ヘッダ情報およびメール本文を含む電子メールを取得する。グルーピング部２１０は、取得された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定して、グルーピングする。表示部２０８は、グルーピング部２１０により特定された電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する。グルーピング部２１０は、当該電子メール受信装置１０から送信した電子メールも含めてグルーピングを行う。
【選択図】図８

Description

本発明は、電子メールを処理する技術に関する。

近年、スマートフォンや携帯型ゲーム機など、多様な機能を備えた小型電子機器が普及している。これらの電子機器には、電子メールの送受信機能を搭載したものも存在し、これによりユーザは、屋外でも簡単に電子メールを閲覧することができる。

ＵＳ特許出願公開２００２−０１１２０１８号明細書

一般に、携帯型の電子機器に搭載されるメールアプリケーションは、電子メールをダウンロードすると、電子メールのプレビューを生成して、ディスプレイにプレビューリストを表示する。ユーザが、プレビューリストからプレビューを選択すると、メールアプリケーションは、そのプレビューに対応する電子メールの本文をディスプレイに表示する。

携帯型の電子機器は据置型の電子機器と比べると、メモリ容量が小さい。そのため、携帯型の電子機器では、受信するデータサイズが大きくならないように、メールサーバからダウンロードする電子メールの数に上限が設定されることが多い。一般に、その上限数は数十程度であるため、１日に何百ものメールを受信するユーザにとっては、使い勝手がよいとは言えない。

またメールアプリケーションの機能で、特定の送信者からの電子メールを特定のフォルダに振り分けるように設定できるものがある。このような設定を行っていれば、電子メールを送信者ごとに分類できるため、ユーザがメールを探す場合に便利である。しかしながら、携帯型の電子機器は、据置型の電子機器と比べると、入力インタフェースが充実しているとはいえないため、振分設定するにも手間がかかる。また携帯型の電子機器は、手軽さを売りとしているため、関連する複数の電子メールを簡易に閲覧できるような仕組みを提供できることが好ましい。

そこで本発明は、改良されたメールアプリケーションを提供することを目的とする。

上記課題を解決するために、本発明のある態様の電子メール受信装置は、ヘッダ情報およびメール本文を含む電子メールを取得するメール取得部と、メール取得部により取得された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定するグルーピング部と、グルーピング部により特定された電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する表示部とを備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明の情報処理技術によると、改良されたメールアプリケーションを提供することが可能となる。

本発明の実施例にかかる情報処理システムを示す図である。 実施例にかかる電子メール受信装置の外観の一例を示す図である。 電子メール受信装置の機能ブロック図である。 認証手順の後に実行される処理手順および更新手順のシーケンス図である。 第１実施例の電子メール受信装置における電子メール受信機能を実行するための機能ブロックを示す図である。 プレビューリストの表示例を示す図である。 第１実施例のメールアプリケーションによるメール表示処理のフローチャートである。 第２実施例の電子メール受信装置における電子メール表示機能を実行するための機能ブロックを示す図である。 グループリストの表示例を示す図である。 メッセージの表示画面例を示す図である。 第２実施例のメールアプリケーションによるメール表示処理のフローチャートである。

図１は、本発明の実施例にかかる情報処理システム１を示す。情報処理システム１は、ユーザ端末である電子メール受信装置１０と、メールサーバ８とを備える。本実施例において、電子メール受信装置１０は、無線通信機能を有する携帯型の電子機器である。電子メール受信装置１０は、アクセスポイント（以下、「ＡＰ」と呼ぶ）２を介してネットワーク４に接続し、メールサーバ８から電子メールを受信する。ＡＰ２は、無線ＬＡＮ（Local Area Network）で電子メール受信装置１０をネットワーク４に接続する中継装置として機能する。電子メール受信装置１０は、無線ＬＡＮ方式による通信機能を有してもよいが、第３世代移動通信システムなどの携帯電話通信方式により携帯電話網に接続して、メールサーバ８から電子メールを受信してもよい。なお電子メール受信装置１０は、他の方式の無線通信機能を有してもよく、また有線通信によりメールサーバ８から電子メールを受信してもよい。

電子メール受信装置１０は、メールアプリケーションを起動することで、電子メールの送受信機能および表示機能を実現する。なおメールアプリケーションはバックグランドで起動されて、電子メールの送受信機能を実現してもよい。電子メール受信装置１０は、たとえば携帯電話やＰＤＡ（Personal Digital Assistant）、携帯型ゲーム機であってよく、いずれの電子機器であってもメールアプリケーションを搭載したものであればよい。なお、本実施例のメールアプリケーションは、記憶容量が小さい電子機器において特に有用であるが、記憶容量が大きい電子機器、たとえば据置型のゲーム機においても有効に利用されることができる。以下では、電子メール受信装置１０が、本実施例のメールアプリケーションを搭載した携帯型ゲーム機である場合を例にとる。

図２は、実施例にかかる電子メール受信装置１０の外観の一例を示す。電子メール受信装置１０の表側、すなわち、ユーザが電子メール受信装置１０を把持して操作するときにユーザに面する側には、指示入力ボタン２１、方向キー２２、Ｒボタン２３、Ｌボタン２４などの入力装置２０と、表示装置６８が備えられている。表示装置６８には、ユーザの指やスタイラスペンなどによる接触を検知するためのタッチパネル６９が併設されている。電子メール受信装置１０の内部には、電子メール受信装置１０の傾きを検知するモーションセンサ２５が備えられている。なお電子メール受信装置１０の裏側に、背面タッチパネルが備えられてもよい。

電子メール受信装置１０の側面には、メモリカードなどの記録メディアを装着するためのスロット（図示せず）などの収容部が設けられる。また、電子メール受信装置１０の側面には、ゲームファイルを記録した記録メディアを装着するためのスロット（図示せず）などの収容部も設けられる。

ユーザは、電子メール受信装置１０を両手で把持した状態で、例えば、右手親指で指示入力ボタン２１を操作し、左手親指で方向キー２２を操作し、右手人差し指又は中指でＲボタン２３を操作し、左手人差し指又は中指でＬボタン２４を操作することができる。またタッチパネル６９を操作する場合には、電子メール受信装置１０を両手で把持した状態で、それぞれの親指でタッチパネル６９を操作してもよく、また電子メール受信装置１０を左手で把持した状態で、右手でタッチパネル６９を操作してもよい。

図３は、電子メール受信装置１０の機能ブロック図である。表示装置６８は、電子メール受信装置１０の各機能により生成される画像を表示する。表示装置６８は、液晶表示装置であってもよいし、有機ＥＬ表示装置であってもよい。タッチパネル６９は、表示装置６８の上に重ね合わせて設けられ、ユーザの指やペンなどによる接触を検知する。タッチパネル６９は、抵抗膜方式、表面型静電容量方式、投影型静電容量方式など、いずれの方式のものであってもよい。電子メール受信装置１０では、表示装置６８およびタッチパネル６９によりディスプレイが構成される。

無線通信モジュール３０はＩＥＥＥ８０２．１１ｂ／ｇ等の通信規格に準拠した無線ＬＡＮモジュールによって構成され、ＡＰ２を介して、ネットワーク４に接続する。携帯電話モジュール３２は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応し、携帯電話網６に接続する。携帯電話モジュール３２には、携帯電話の電話番号を特定するための固有のＩＤ番号が記録されたＳＩＭカードが挿入される。

インタフェース５０において、ＬＥＤ（Light Emitting Diode）５１は、無線通信モジュール３０や携帯電話モジュール３２などがデータの送受信をしている際に点滅する。モーションセンサ２５は、電子メール受信装置１０の動きを検知する。マイク５２は、電子メール受信装置１０の周辺の音声を入力する。スピーカ５３は、電子メール受信装置１０の各機能により生成される音声を出力する。ステレオ入出力端子５４は、外部のマイクからステレオ音声を入力し、外部のヘッドフォンなどへステレオ音声を出力する。入力装置２０は、前述した操作キーなどを含み、ユーザの操作入力を受け付ける。

ＣＰＵ（Central Processing Unit）４０は、メインメモリ４４にロードされたプログラムなどを実行し、本実施例ではメールアプリケーションを実行する。ＧＰＵ（Graphics Processing Unit）４２は、画像処理に必要な計算を実行する。メインメモリ４４は、ＲＡＭ（Random Access Memory）などにより構成され、電子メール受信装置１０で動作するプログラムやデータなどを記憶する。ストレージ４６は、ＮＡＮＤ型フラッシュメモリ（NAND-type flash memory）などにより構成され、内蔵型の補助記憶装置として利用される。

ＧＰＳ（Global Positioning System）制御部６０は、ＧＰＳ衛星からの信号を受信し、現在位置を算出する。ＵＳＢ制御部６１は、ＵＳＢ（Universal Serial Bus）で接続された周辺装置との間の通信を制御する。ビデオ出力制御部６４は、ＨＤＭＩなどの規格に基づいて、外部表示装置へビデオ信号を出力する。メモリカード制御部６２は、スロットなどの収容部（図示せず）に装着されたフラッシュメモリなどの記録メディア８０との間のデータの読み書きを制御する。リムーバブルな記録メディア８０が収容部に装着されると、記録メディア８０は、外付け型の補助記憶装置として利用される。メディアドライブ６３は、ゲームファイルを記録したゲーム記録メディア７０が装着される収容部であり、ゲーム記録メディア７０との間のデータの読み書きを制御する。以上の各機能ブロックはバス９０によって互いに接続されている。

以下、本実施例のメールアプリケーションについて説明する前に、ＰＯＰ（Post Office Protocol）３の基本動作について説明する。ＰＯＰ３は、認証（Authentication）、処理（Transaction）、および更新（Update）の３つの手順で構成される。

認証手順では、まず、クライアントがユーザＩＤをメールサーバに送信する。メールサーバは、ユーザＩＤをもとにメールボックスを特定する。次にクライアントは、パスワードをメールサーバに送信する。メールサーバは、パスワードをもとにユーザを確認して認証する。認証が成功すると、処理手順が開始される。

図４は、認証手順の後に実行される処理手順および更新手順のシーケンス図を示す。図４において、Ｓ１０〜Ｓ２３のステップが、処理手順を示し、Ｓ３０〜Ｓ３３のステップが、更新手順を示す。なお、以下のシーケンスは、ＰＯＰ３の基本動作の一例である。

＜処理手順＞
（Ｓ１０）
クライアントが、ＳＴＡＴコマンドをメールサーバに送信する。
（Ｓ１１）
メールサーバは、メールボックスにある電子メールの数と、電子メールの総バイト数をクライアントに返す。「２０ １ＭＢ」は、電子メールの総数が２０個、総バイト数が１ＭＢ（メガバイト）であることを示している。
（Ｓ１２）
クライアントが、ＬＩＳＴコマンドをメールサーバに送信する。
（Ｓ１３）
メールサーバのメールボックスでは、電子メールの到着順に１番からメッセージ番号が割り振られている。メールサーバは、ＬＩＳＴコマンドを受けると、各電子メールのメッセージ番号とバイト数を含めたメッセージリスト（ｌｉｓｔ）を、クライアントに返す。ここでは、２０個の電子メールに、それぞれ１〜２０のメッセージ番号が割り振られているものとする。

（Ｓ１４）
クライアントは、ＲＥＴＲコマンドをメールサーバに送信する。ここで、「ＲＥＴＲ１」は、メッセージ番号１の電子メールの取得要求を意味する。
（Ｓ１５）
メールサーバは、メッセージ番号１の電子メールをクライアントに送信する。これにより、クライアントは、メッセージ番号１の電子メールを取得できる。
（Ｓ１６）
クライアントは、ＤＥＬＥコマンドをメールサーバに送信する。ここで、「ＤＥＬＥ１」は、メッセージ番号１の電子メールに削除マークを付けるコマンドである。
（Ｓ１７）
メールサーバは、メッセージ番号１の電子メールに削除マークを付ける。なお、削除マークを付けるだけで、電子メールの削除はまだ行われていない。

クライアントは、ＲＥＴＲコマンドとＤＥＬＥコマンドを、メッセージリストに含まれる全てのメッセージ番号を指定して送信することで、メールボックスに蓄積されている全ての電子メールを取得し、またメールボックスに蓄積されている全ての電子メールに削除マークを付ける。
（Ｓ２０）
クライアントは、ＲＥＴＲコマンドをメールサーバに送信する。ここで、「ＲＥＴＲ２０」は、メッセージ番号２０の電子メールの取得要求を意味する。
（Ｓ２１）
メールサーバは、メッセージ番号２０の電子メールをクライアントに送信する。これにより、クライアントは、メッセージ番号２０の電子メールを取得できる。
（Ｓ２２）
クライアントは、ＤＥＬＥコマンドをメールサーバに送信する。ここで、「ＤＥＬＥ２０」は、メッセージ番号２０の電子メールに削除マークを付けるコマンドである。
（Ｓ２３）
メールサーバは、メッセージ番号２０の電子メールに削除マークを付ける。
以上で、処理手順が完了する。

＜更新手順＞
（Ｓ３０）
クライアントは、ＲＥＳＴコマンドをメールサーバに送信する。ＲＥＳＴコマンドは、メールボックスの電子メールに付けた削除マークを外すためのコマンドである。クライアントは、取得した電子メールをメールボックスから削除したくない場合、ＲＥＳＴコマンドを送信することで、取得した電子メールをメールボックスに残すことができる。
（Ｓ３１）
メールサーバは、電子メールの削除マークを外す。
（Ｓ３２）
クライアントは、ＱＵＩＴコマンドをメールサーバに送信する。ＱＵＩＴコマンドは、削除マークが付いている電子メールをメールボックスから削除し、ＴＣＰコネクションを切断するためのコマンドである。
（Ｓ３３）
メールサーバは、削除マークが付いている電子メールをメールボックスから削除する。Ｓ３０でＲＥＳＴコマンドが送信されている場合には、電子メールから削除マークが外されているため、メールボックスの電子メールは、削除されずに残されることになる。本実施例の電子メール受信装置１０は、携帯型の端末装置であり、ユースケースとして、ユーザが屋外で電子メールを確認する場合に利用されることが想定される。そのため、電子メール受信装置１０は、ＲＥＳＴコマンドを送信して、メールボックスに電子メールを残す設定にしておくことが好ましい。
以上で、更新手順が完了する。この後、クライアントとメールサーバ間のＴＣＰコネクションが切断される。
なお、本実施例ではメールボックスに電子メールを残す設定にするため、削除マークに関するステップであるＳ１６，Ｓ１７，Ｓ２２，Ｓ２３，Ｓ３０，Ｓ３１は、シーケンスから除外してもよい。

なお、図４に示す基本シーケンスによると、クライアントは、メールボックスに蓄積された全ての電子メールを受信することになる。そうすると、同じ電子メールを何度も受信する状況が発生するため、クライアントは、取得済みの電子メールと、新しくメールボックスに到着した電子メールとを区別し、新しい電子メールだけを受信することが好ましい。そのために、ＰＯＰ３では、ＵＩＤＬコマンドが用意されている。

図４に示すシーケンスにおいて、クライアントがＲＥＴＲコマンドを送信する前（つまり、Ｓ１４の前）に、ＵＩＤＬコマンドをメールサーバに送信する。メールサーバは、メールボックスに蓄積している電子メールに、それぞれを一意に特定するＩＤを付加しておき、メールサーバは、ＵＩＤＬコマンドを受けると、メッセージ番号と電子メールＩＤとを対応付けた対応リストを、クライアントに送信する。その後、クライアントは、ＲＥＴＲコマンドを送信して、電子メールを取得すると、取得した電子メールのＩＤを記録していく。クライアントは、次回のアクセスの際にもＵＩＤＬコマンドで電子メールＩＤを取得することで、前回取得していないＩＤをもつ電子メールだけを、ＲＥＴＲコマンドで取得するようにする。これにより、同じ電子メールを重複して取得しないようにできる。

本実施例の電子メール受信装置１０は、ＰＯＰ３の仕組みを用いて、メールサーバ８から電子メールを受信する。電子メール受信装置１０において、メールアプリケーションは、受信した電子メールを記録メディア８０に蓄積する。記録メディア８０は数ＧＢ（ギガバイト）の記憶容量を有しており、仮に電子メール受信装置１０がメールアプリケーションしか実行しないのであれば、記録メディア８０の容量は十分といえる。しかしながら本実施例の電子メール受信装置１０はゲーム機であるため、記録メディア８０には、ゲームサーバからダウンロードしたゲームプログラムや、ゲームのセーブデータなども記録される。そのため、メールアプリケーションが、無制限に記録メディア８０を利用することは好ましくない。

そこで電子メール受信装置１０では、メールアプリケーションに割り当てられる記憶容量に制限が設けられる。利用可能な容量は、たとえば１０ＭＢであり、メールアプリケーションは、１０ＭＢの容量を効率的に利用して、ユーザに効果的に電子メールを提示する機能をもつ。

（第１実施例）
第１実施例では、ユーザに受信メールを提示するメールアプリケーションを提供する。このメールアプリケーションは、起動されると、ディスプレイに電子メールのプレビューリストを表示する。各メールプレビューは、たとえば件名、送信者、送信日時、メール本文（メッセージ）の一部を含んで表示される。ユーザは、プレビューリストを見て、読みたい電子メールのプレビューを選択すると、メールアプリケーションは、選択された電子メールの本文をディスプレイに表示する。

メールアプリケーションはＰＯＰ３で電子メールの受信を行うが、図４に示すシーケンスをそのまま採用すると、メールボックスに蓄積されている全ての電子メール（ＵＩＤＬコマンドを用いる場合には、未読の全ての電子メール）を取得するため、受信するデータサイズは大きくなる。この理由から、従来のメールアプリケーションは、ダウンロードする電子メールの数を制限して、携帯型電子端末に保存されるデータサイズを小さくするようにしていた。従来のメールアプリケーションは、ダウンロードする電子メールの数を数十程度に制限しており、その結果、ダウンロードした電子メールから生成されるプレビューは、ダウンロードした電子メールの数しかユーザに提示できないという問題があった。

そこで、第１実施例のメールアプリケーションは、電子メールを受信すると、ヘッダ情報の少なくとも一部およびメール本文の少なくとも一部からプレビュー構成データを生成してキャッシュし、プレビュー構成データの生成後は、受信した電子メールを破棄するようにする。つまり、一度電子メールを受信しても、その電子メールはプレビュー構成データの生成のためだけに使用され、電子メール自体は記録メディア８０に記録されない。またプレビュー構成データのサイズは小さいため、数百〜数千のプレビュー構成データをキャッシュしたとしても、全文受信をした場合と比べると、そのデータサイズは著しく小さい。これにより、記録メディア８０に記録するデータ量を低減できるとともに、プレビューリストに含めるプレビューの数を多くでき、メールアプリケーションの利便性を高めることができる。なお、プレビュー構成データを生成するために電子メールを受信する際、ＴＯＰコマンドを利用して電子メールのヘッダ情報と、所定行数のメッセージをダウンロードした時点で電子メールの受信を打ち切ることで、ダウンロードするデータ量を抑えてもよい。

図５は、第１実施例の電子メール受信装置１０における電子メール受信機能を実行するための機能ブロックを示す。図５では、メインメモリ４４やＧＰＵ４２などの図示は省略している。電子メール受信装置１０は、入力装置２０、タッチパネル６９、入力部９２、ＣＰＵ４０、記録メディア８０および表示装置６８を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

入力部９２は、入力装置２０およびタッチパネル６９から入力されるユーザによる操作指示を受け付ける。記録メディア８０は、メールアプリケーションが使用するデータを記録する。なお、記録メディア８０の代わりに、他の記録装置、たとえばストレージ４６が利用されてもよい。

ＣＰＵ４０は、インタフェース９４、リスト取得部１００、メール取得部１０２、プレビュー生成部１０４、コマンド送信部１０６、表示部１０８および記録管理部１２０を備える。インタフェース９４、リスト取得部１００、メール取得部１０２、プレビュー生成部１０４、コマンド送信部１０６および表示部１０８の各機能は、メールアプリケーションにより実現される。記録管理部１２０は、メールアプリケーションが利用する容量が上限（たとえば１０ＭＢ）を超えないように、メールアプリケーションによる記録メディア８０の利用状況を管理する。なお後述するように、電子メール受信装置１０は、第１実施例のメールアプリケーションだけでなく、第２実施例のメールアプリケーションも搭載しており、記録管理部１２０は、これら複数のメールアプリケーションによる記録メディア８０の利用状況を管理して、トータルで利用する容量が上限を超えないように監視している。

入力部９２が、メールアプリケーションの起動指示を受け付けると、第１実施例のメールアプリケーションが起動され、コマンド送信部１０６が、図４に示す認証手順を実行する。認証手順が終了すると、コマンド送信部１０６は、Ｓ１０に示すＳＴＡＴコマンド、Ｓ１２に示すＬＩＳＴコマンドを、インタフェース９４を介して無線通信モジュール３０からメールサーバ８に送信する。また、コマンド送信部１０６は、ＵＩＤＬコマンドも送信する。

リスト取得部１００は、メールサーバ８より、各電子メールのメッセージ番号とバイト数を含めたメッセージリスト（ｌｉｓｔ）を取得する。また、リスト取得部１００は、ＵＩＤＬコマンドに応じてメールサーバ８から送信される電子メールＩＤとメッセージ番号との対応リストも取得する。リスト取得部１００は、メッセージリストおよび対応リストを、リスト保持部１４０に記録する。

コマンド送信部１０６は、リスト保持部１４０に記録されたリストを参照して、図４のＳ１４に示すＲＥＴＲコマンドを、インタフェース９４を介して無線通信モジュール３０からメールサーバ８に送信する。ＲＥＴＲコマンドには、電子メールのメッセージ番号が含まれており、メールサーバ８は、ＲＥＴＲコマンドに含まれるメッセージ番号の電子メールをメールボックスから抽出し、電子メール受信装置１０に送信する。

メール取得部１０２は、ヘッダ情報およびメール本文を含む電子メールを取得する。メール取得部１０２は、取得した電子メールをプレビュー生成部１０４に渡す。プレビュー生成部１０４は、電子メールからプレビュー構成データを生成する。具体的にプレビュー生成部１０４は、電子メールからヘッダ情報の少なくとも一部と、メール本文の少なくとも一部を抽出して、所定のデータサイズの範囲内でプレビュー構成データを生成する。プレビュー構成データは、表示装置６８に表示されてメールのプレビューを構成するためのデータである。本実施例においてプレビュー生成部１０４は、ヘッダ情報から件名（Subject）、送信者（From）、送信日時（Date）を抽出し、またメール本文から所定文字数の範囲内でテキストを抽出し、プレビュー構成データを生成する。プレビュー構成データは、キャッシュ部１４２にキャッシュされる。なお、プレビュー生成部１０４は、ヘッダ情報から宛先（To, Cc）を抽出して、プレビュー構成データに含めてもよい。

プレビュー生成部１０４は、プレビュー構成データを生成すると、メール取得部１０２により取得された電子メールを破棄する。つまり、プレビュー構成データの生成時、メール取得部１０２で取得された電子メールは、プレビュー構成データの生成のために利用され、利用された後は、記録メディア８０のメール蓄積部１４４に蓄積されない。これにより、ユーザがメール本文を読むか明らかでない電子メールを記録しないで済むようになる。

コマンド送信部１０６は、リスト保持部１４０に記録されたリストを参照して、未取得の電子メールについてのＲＥＴＲコマンドおよびＤＥＬＥコマンドをメールサーバ８に送信する。プレビュー生成部１０４は、メール取得部１０２により取得された電子メールをもとにプレビュー構成データを生成し、キャッシュ部１４２は、生成されたプレビュー構成データをキャッシュする。

プレビュー生成部１０４は、プレビュー構成データのサイズを、たとえば２ＫＢ（キロバイト）以下に制限する。メールアプリケーションに割り当てられる記録メディア８０の容量は、たとえば１０ＭＢであるが、記録メディア８０には、キャッシュ部１４２だけでなく、リストを保持するリスト保持部１４０や、電子メールを蓄積するメール蓄積部１４４なども形成されている。そのため、リスト保持部１４０、キャッシュ部１４２およびメール蓄積部１４４のそれぞれが使用する容量を低減することで、全体として使用する容量を１０ＭＢまでに抑える必要がある。そのため、プレビュー構成データのサイズを所定値以下に設定して、キャッシュ部１４２の使用容量を小さくすることが好ましい。そのような理由から、プレビュー構成データは、さらに小さいデータサイズ（たとえば、５１２バイトまたは２５６バイト）以下に制限されてもよい。

また、キャッシュ部１４２がキャッシュするプレビュー構成データの数にも上限が設定されることが好ましい。プレビューリストが表示装置６８に表示されると、ユーザはタッチパネル６９を操作して、プレビューリストをスクロールする。ユーザにもよるが、大体２００件程度のプレビューをスクロールできれば、受信メッセージリストとしては十分であろうと考えられる。そこでキャッシュ部１４２は、２００件までのプレビュー構成データをキャッシュできるようにする。なお、ユーザが、キャッシュ部１４２にキャッシュされていないプレビューを見る場合、つまりは２００件を超えるプレビューを見る場合には、コマンド送信部１０６が、任意のタイミングで、リスト保持部１４０に記録されたリストを参照して、ＲＥＴＲコマンドをメールサーバ８に送信し、プレビュー生成部１０４がプレビュー構成データを生成する。このときプレビュー生成部１０４は、ＬＲＵ（Least Recently Used）方式などに代表されるキャッシュアルゴリズムにより、キャッシュ部１４２におけるキャッシュ数が上限（２００件）を超えないように、キャッシュ部１４２からプレビュー構成データを削除することが好ましい。これにより、キャッシュ部１４２で使用する容量を、４００ＫＢ（＝２ＫＢ×２００件）以下に抑えることができる。なお、記録メディア８０の利用可能な残量に余裕があれば、キャッシュ部１４２は、２００件を超えてプレビュー構成データをキャッシュしてもよい。

上記したように、プレビュー構成データのサイズは、２ＫＢ以下に制限される。そのため、仮に１つの電子メールのデータサイズが１ＭＢあるような場合、１ＭＢ全てをダウンロードしてからプレビュー構成データを生成することは時間的に効率的ではない。また、１ＭＢ全てをダウンロードすることは、結局は破棄するデータであるにもかかわらず、ダウンロード時に記憶容量を無駄に使用することになる。また電子メール受信装置１０はバッテリ駆動の端末装置であるため、電力消費の観点からも好ましくない。

そこでメール取得部１０２は、電子メールを、先頭から所定のデータサイズの範囲内で取得し、範囲を超えた分については取得しないようにしてもよい。プレビュー構成データは、ヘッダ情報の一部と、メール本文の一部から生成されるが、ヘッダ情報は、電子メールの先頭部分に配置され、また抽出するメール本文も、ボディ部分の最初に記載されているテキストであればよい。そこで、たとえば電子メールのデータを先頭から２．５ＫＢ〜３ＫＢ程度のサイズ分だけ取得できれば、２ＫＢ以下のプレビュー構成データを作成するに十分である。そこで、メール取得部１０２は、取得する電子メールのサイズをたとえば２．５ＫＢ程度までとし、２．５ＫＢを超える部分については取得しないようにする。

取得する電子メールのサイズを２．５ＫＢ程度に制限する方法の例を示す。１つの例として、メール取得部１０２がＴＯＰコマンドを使用し、メッセージ本文をダウンロードする行数を予め指定する。これによりメール取得部１０２は、電子メールのヘッダと、所定行数のメッセージをダウンロードした時点で、電子メールの受信を打ち切ることができる。なお、ＴＯＰコマンドの使用は、プレビュー構成データ生成用の電子メールの取得時のみに行われる。図示していないが、メールアプリケーションは、メール取得部１０２がプレビュー構成データ生成用の電子メールを取得しているか、またはメッセージ本文表示のための電子メールを取得しているかのステータスを管理する機能を有し、その機能により、プレビュー構成データ生成用の電子メールの取得時に、ダウンロードするメール本文の行数が設定される。

別の例として、受信データ量が、設定されたデータサイズ（２．５ＫＢ）を超えた場合に、インタフェース９４がＴＣＰセッションを強制的に終了させてもよい。ＴＣＰセッションの強制終了は、インタフェース９４によって行われてもよく、またメール取得部１０２により制御されてもよい。このように、プレビュー構成データの生成時、メール取得部１０２が、プレビュー構成データの生成に必要なデータサイズの電子メールを取得するようにすることで、プレビュー構成データの生成効率を高めることができる。

表示部１０８は、キャッシュ部１４２によりキャッシュされたプレビュー構成データを用いて、プレビューリストを表示装置６８に表示する。
図６は、プレビューリストの表示例を示す。プレビューリストには、複数のプレビュー１５０ａ、１５０ｂ、１５０ｃ、１５０ｄが含まれる。図６において、全てのプレビュー１５０に、メール本文を取得していないことを示す未読マーク１５１が付加されているが、たとえば、いずれかのプレビュー１５０が選択されて、メール取得部１０２が、電子メールの全体を取得して、表示部１０８が表示装置６８に表示すると、未読マーク１５１は外される。

ユーザがタッチパネル６９を上下方向にフリックしてプレビューリストをスクロールすると、表示されるプレビューが変更される。ユーザは、閲覧したい電子メールのプレビュー１５０をタップして選択する。コマンド送信部１０６は、プレビューが選択されると、選択されたプレビューにより特定される電子メールの送信を要求するＲＥＴＲコマンドをメールサーバ８に送信する。具体的には、コマンド送信部１０６が、リスト保持部１４０から、選択されたプレビューに対応するメッセージ番号を取得し、ＲＥＴＲコマンドに含めて、メールサーバ８に送信する。

メール取得部１０２は、メールサーバ８から電子メールを取得すると、メール蓄積部１４４に記録し、表示部１０８は、メール本文を表示装置６８に表示する。このように、第１実施例のメールアプリケーションでは、メール蓄積部１４４に蓄積する電子メールは、プレビューリストの生成後に、ユーザからの閲覧要求にしたがってダウンロードしたものに限定されるため、メール蓄積部１４４の使用容量を低減することができる。

記録管理部１２０は、記録メディア８０の利用状況を監視し、記憶内容の参照された時間などを記録している。記録管理部１２０は、利用容量が所定の上限容量（１０ＭＢ）に近づくと、たとえばＬＲＵ（Least Recently Used）方式などに代表されるキャッシュアルゴリズムにより、記録メディア８０のデータを削除して、使用可能な容量を増やすようにする。

図７は、第１実施例のメールアプリケーションによるメール表示処理のフローチャートである。リスト取得部１００が、メールサーバ８から、メールボックスに蓄積されている電子メールのメッセージリストを取得し、リスト保持部１４０に保持させる（Ｓ５０）。メール取得部１０２は、ＲＥＴＲコマンドを送信して、メールサーバ８から電子メールを取得する（Ｓ５２）。このときメール取得部１０２は、電子メールを、データの先頭から所定のデータサイズの範囲内で取得する。プレビュー生成部１０４は、電子メールから、ヘッダ情報の少なくとも一部と、メール本文の少なくとも一部を抽出して、プレビュー構成データを生成し、キャッシュ部１４２にキャッシュさせる（Ｓ５４）。Ｓ５２，Ｓ５４のステップは、繰り返し実行される（Ｓ５６のＮ）。

メール取得部１０２が、メッセージリストに含まれる全ての電子メールを取得し、プレビュー生成部１０４がプレビュー構成データを生成すると（Ｓ５６のＹ）、表示部１０８が、キャッシュ部１４２にキャッシュされたプレビュー構成データを用いて、プレビューリストを表示装置６８に表示する（Ｓ５８）。なお、キャッシュ部１４２において、キャッシュするプレビュー構成データの数は所定数（たとえば２００個）に制限されているため、メール取得部１０２が、メッセージリストに含まれる電子メールのうち、最新のものから２００個の電子メールを取得し、プレビュー生成部１０４がプレビュー構成データを生成した場合には、メール取得部１０２は、それ以上の電子メールの取得を行わない。

ユーザは、プレビューリストをスクロール表示して（Ｓ６０のＮ）、閲覧したい電子メールのプレビューを選択する（Ｓ６０のＹ）。このときコマンド送信部１０６は、選択されたプレビューにより特定される電子メールのＲＥＴＲコマンドをメールサーバ８に送信する。メール取得部１０２は、メールサーバ８から電子メールを取得し（Ｓ６２）、メール蓄積部１４４に蓄積すると、表示部１０８は、表示装置６８にメール本文を表示する（Ｓ６４）。

（第２実施例）
第２実施例では、電子メールをグルーピングしてユーザに提示するメールアプリケーションを提供する。このメールアプリケーションは、電子メールのヘッダ情報に含まれる送信者（From）のメールアドレスと宛先（To, Cc）のメールアドレスの集合が一致する電子メールをグルーピングして表示する。以下、理解を容易にするために、送信者のメールアドレス、宛先のメールアドレスを、それぞれ送信者、宛先の名前に置き換えて説明する。

たとえば、送信者がＡさんで、宛先がＢさん、Ｃさんである電子メールと、送信者がＢさんで、宛先がＡさん、Ｃさんである電子メールは、送信者および宛先の集合がともにＡさん、Ｂさん、Ｃさんであるため、同じグループに属する。一方、送信者がＡさんで、宛先がＢさん、Ｃさんである電子メールと、送信者がＡさんで、宛先がＢさん、Ｃさん、Ｄさんである電子メールは、送信者および宛先の集合が異なるため、別のグループに属する。このように、第２実施例のメールアプリケーションは、送信者および宛先の集合が完全一致する電子メールをまとめて１つのグループとする処理を行う。

図８は、第２実施例の電子メール受信装置１０における電子メール表示機能を実行するための機能ブロックを示す。図８では、メインメモリ４４やＧＰＵ４２などの図示は省略している。電子メール受信装置１０は、入力装置２０、タッチパネル６９、入力部９２、ＣＰＵ４０、記録メディア８０および表示装置６８を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

入力部９２は、入力装置２０およびタッチパネル６９から入力されるユーザによる操作指示を受け付ける。記録メディア８０は、メールアプリケーションが使用するデータを記録する。なお、記録メディア８０の代わりに、他の記録装置、たとえばストレージ４６が利用されてもよい。

ＣＰＵ４０は、インタフェース１９４、リスト取得部２００、メール取得部２０２、コマンド送信部２０４、メール送信部２０６、表示部２０８、グルーピング部２１０および記録管理部１２０を備える。インタフェース１９４、リスト取得部２００、メール取得部２０２、コマンド送信部２０４、メール送信部２０６、表示部２０８およびグルーピング部２１０の各機能は、メールアプリケーションにより実現される。記録管理部１２０は、メールアプリケーションが利用する容量が上限（たとえば１０ＭＢ）を超えないように、メールアプリケーションによる記録メディア８０の利用状況を管理する。

なお、記録管理部１２０は、第１実施例の電子メール受信装置１０においても設けられている。記録管理部１２０は、電子メール受信装置１０に複数のメールアプリケーションが実装されている場合であっても、複数のメールアプリケーションがトータルで利用する容量が上限を超えないように、記録メディア８０の利用状況を管理している。

入力部９２が、メールアプリケーションの起動指示を受け付けると、第２実施例のメールアプリケーションが起動される。第２実施例のメールアプリケーションは、第１実施例で説明したプレビューを生成しないため、図４に示す認証手順、処理手順、更新手順を実行する。なおメールアプリケーションに割り当てられる記憶容量には上限（１０ＭＢ）が設定されているため、第２実施例のメールアプリケーションで送受信される電子メールは、メッセージの文字数が制限されるなどして、電子メールのデータサイズが小さくされていることが好ましい。

コマンド送信部２０４は、ＳＴＡＴコマンド、ＬＩＳＴコマンドを、インタフェース１９４を介して無線通信モジュール３０からメールサーバ８に送信する。また、コマンド送信部２０４は、ＵＩＤＬコマンドも送信する。リスト取得部２００は、メールサーバ８より、各電子メールのメッセージ番号とバイト数を含めたメッセージリスト（ｌｉｓｔ）を取得する。また、リスト取得部２００は、ＵＩＤＬコマンドに応じてメールサーバ８から送信される電子メールＩＤとメッセージ番号との対応リストも取得する。リスト取得部２００は、メッセージリストおよび対応リストを、リスト保持部２４０に記録する。

コマンド送信部２０４は、リスト保持部２４０に記録されたリストを参照して、ＲＥＴＲコマンドを、インタフェース１９４を介して無線通信モジュール３０からメールサーバ８に送信する。メールサーバ８は、ＲＥＴＲコマンドに含まれるメッセージ番号の電子メールをメールボックスから抽出し、電子メール受信装置１０に送信する。メール取得部２０２は、ヘッダ情報およびメール本文を含む電子メールを取得し、メール蓄積部２４２に蓄積する。なお第２実施例のメールアプリケーションは、ＩＭＡＰ（Internet Message Access Protocol）を利用して、電子メールの送受信を行ってもよい。

グルーピング部２１０は、メール蓄積部２４２に蓄積された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定して、グルーピングを行う。具体的にグルーピング部２１０は、ヘッダ情報に含まれる送信者（From）、宛先（To, Cc）のメールアドレスを参照し、電子メールごとに送信者と宛先の集合を生成する。たとえば、ある電子メールの送信者がＡさん、宛先がＢさん、Ｃさんである場合、その電子メールの送信者および宛先の集合は、｛Ａ、Ｂ、Ｃ｝である。また、別の電子メールの送信者がＢさん、宛先がＡさん、Ｃさんである場合、その電子メールの送信者および宛先の集合は、｛Ａ、Ｂ、Ｃ｝である。したがって、この２つの電子メールの送信者および宛先の集合は完全一致し、グルーピング部２１０は、この２つの電子メールを、同一のグループに振り分ける。たとえば、グルーピング部は、グループを特定するグループＩＤを設定し、各電子メールと、グループＩＤとを対応付けたデータベースを作成してもよい。

なお、電子メール受信装置１０において、ユーザは、入力装置２０またはタッチパネル６９からメッセージを入力して送信メールを生成できる。メール送信部２０６は、宛先を特定して電子メールを送信するとともに、送信した電子メールをメール蓄積部２４２に蓄積する。グルーピング部２１０は、受信した電子メールだけでなく、送信した電子メールも含めてグルーピングを行う。

表示部２０８は、グルーピング部２１０により分類されたグループを、表示装置６８に表示する。このＧＵＩ（Graphical User Interface）により、電子メールをフォルダに振り分けたような状態がユーザに提供される。

図９は、グループリストの表示例を示す。グループリストには、分類されたグループを特定するグループ構成情報２５０ａ、２５０ｂ、２５０ｃ、２５０ｄが含まれる。各グループ構成情報は、グループを構成する自分以外のメンバの名前と、そのメンバのアイコン画像を含む。たとえば、グループ構成情報２５０ａは、そのグループを構成するメンバが自分、Ｋｅｎ、Ｔａｒｏ、Ｊｉｒｏであることを示し、グループ構成情報２５０ｂは、そのグループを構成するメンバが自分、Ｋｅｎ、Ｔａｒｏであることを示している。表示部２０８は、グループに対して送信された最新の電子メールの送信日時が新しい順に、グループ構成情報２５０を上から並べて表示する。

ユーザが、タッチパネル６９を上下方向にフリックしてグループリストをスクロールすると、表示されるグループ構成情報が変更される。ユーザは、電子メールを閲覧したいグループ構成情報２５０をタップして選択する。ここでは、グループ構成情報２５０ｂが選択されたものとする。

図１０は、メッセージの表示画面例を示す。メッセージ画面には、グループメンバのアイコン画像を表示するメンバアイコン表示領域２６０が形成される。図１０の例では、メンバアイコン表示領域２６０において、左から順に、自分、Ｋｅｎ、Ｔａｒｏのアイコン画像が表示されている。

表示部２０８は、グループ内で送信された電子メールのメール本文を、メッセージ表示領域２６４、２６６に表示する。ここで、メッセージ表示領域２６４には、自分が他のメンバ（ＫｅｎとＴａｒｏ）に対して送信したメッセージが表示されており、メッセージ表示領域２６６には、Ｋｅｎが自分とＴａｒｏに対して送信したメッセージが表示されている。このように、表示部２０８は、メール送信部２０６より送信した電子メールを、メール取得部２０２により取得された電子メールとともに表示する。

このように、グループ内で送信された電子メールであれば、送信メールも受信メールもまとめて表示することで、ユーザは、グループ内でどのような情報伝達があったのかを瞬時に把握することができる。

なお、自分が送信した電子メールであるか、または受信した電子メールであるかを容易に認識できるようにするために、表示部２０８は、自分の送信メッセージが表示されるメッセージ表示領域２６４と、メール取得部２０２により取得された電子メールのメッセージ表示領域２６６とを、左右方向にずらした位置に形成する。図１０の例では、メッセージ表示領域２６４に対して、メッセージ表示領域２６６が所定長さだけ右側にシフトした位置に形成されている。

また自分の送信メッセージが表示されるメッセージ表示領域２６４に対して、右側に自分のアイコン画像を表示し、受信メッセージが表示されるメッセージ表示領域２６６に対しては、左側にメンバのアイコン画像を表示するようにしている。この左右は逆であってもよいが、アイコン画像とメッセージ表示領域とを横並びで表示する際に、自分と他のメンバのアイコン画像の配置を逆にすることで、送信メッセージであるか受信メッセージであるかの判断を容易に行えるようになる。

また表示部２０８は、メッセージ表示領域２６４、２６６以外の位置に、送信メッセージを書き込むためのメッセージ書込領域２６２を形成する。メッセージ書込領域２６２はウィンドウ形式で形成されてよい。表示部２０８が、メッセージ表示領域２６４、２６６と同一画面にメッセージ書込領域２６２を表示することで、ユーザは、送信済みメールまたは受信済みメールに含まれるメッセージを見ながら、メッセージをメッセージ書込領域２６２に書き込むことができ、グループ内でのコミュニケーションを円滑にすることが可能となる。

図１１は、第２実施例のメールアプリケーションによるメール表示処理のフローチャートである。メール取得部２０２がメールサーバ８から電子メールを取得し、メール蓄積部２４２に蓄積する（Ｓ８０）。グルーピング部２１０は、メール蓄積部２４２に蓄積された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定し、グルーピングする（Ｓ８２）。表示部２０８は、表示装置６８にグループリストを表示する（Ｓ８４）。

ユーザは、グループリストをスクロール表示して（Ｓ８６のＮ）、閲覧したいグループを選択する（Ｓ８６のＹ）。表示部２０８は、選択されたグループのＩＤを付与された電子メールをメール蓄積部２４２から抽出し、新しい順に上から並べて、電子メールのメール本文を表示する（Ｓ８８）。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

１・・・情報処理システム、８・・・メールサーバ、１０・・・電子メール受信装置、４０・・・ＣＰＵ、６８・・・表示装置、８０・・・記録メディア、９４・・・インタフェース、１００・・・リスト取得部、１０２・・・メール取得部、１０４・・・プレビュー生成部、１０６・・・コマンド送信部、１０８・・・表示部、１２０・・・記録管理部、１４０・・・リスト保持部、１４２・・・キャッシュ部、１４４・・・メール蓄積部、１９４・・・インタフェース、２００・・・リスト取得部、２０２・・・メール取得部、２０４・・・コマンド送信部、２０６・・・メール送信部、２０８・・・表示部、２１０・・・グルーピング部、２４０・・・リスト保持部、２４２・・・メール蓄積部。

Claims (8)

1. ヘッダ情報およびメール本文を含む電子メールを取得するメール取得部と、
   前記メール取得部により取得された電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定するグルーピング部と、
   前記グルーピング部により特定された電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する表示部と、
   を備えることを特徴とする電子メール受信装置。
2. 前記グルーピング部は、当該電子メール受信装置から送信した電子メールも含めてグルーピングを行い、
   前記表示部は、当該電子メール受信装置から送信した電子メールを、前記メール取得部により取得された電子メールとともに、ディスプレイのメッセージ表示領域に表示することを特徴とする請求項１に記載の電子メール受信装置。
3. 前記表示部は、メッセージ表示領域とともに、送信メッセージを書き込むための領域を形成することを特徴とする請求項１または２に記載の電子メール受信装置。
4. 前記表示部は、当該電子メール受信装置から送信した電子メールのメッセージ表示領域と、前記メール取得部により取得された電子メールのメッセージ表示領域とを、左右方向にずらした位置に形成することを特徴とする請求項２または３に記載の電子メール受信装置。
5. 前記表示部は、当該電子メール受信装置から送信した電子メールのメッセージ表示領域の左側または右側に、その送信者を特定する情報を配置し、前記メール取得部により取得された電子メールのメッセージ表示領域の右側または左側に、取得された電子メールの送信者を特定する情報を配置することを特徴とする請求項４に記載の電子メール受信装置。
6. ヘッダ情報およびメール本文を含む電子メールを取得し、
   取得した電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定し、
   特定した電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する、
   ことを特徴とする電子メール表示方法。
7. コンピュータに、
   ヘッダ情報およびメール本文を含む電子メールを取得する機能と、
   取得した電子メールのヘッダ情報に含まれる送信者のメールアドレスと宛先のメールアドレスの集合が一致する電子メールを特定する機能と、
   特定した複数の電子メールのメール本文を、ディスプレイのメッセージ表示領域に表示する機能と、
   を実現させるためのプログラム。
8. 請求項７に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images