少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とするイベント報知装置。前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする請求項1に記載のイベント報知装置。前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする請求項1または2いずれかに記載のイベント報知装置。前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする請求項1または2いずれかに記載のイベント報知装置。前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする請求項1または2いずれかに記載のイベント報知装置。少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、前記イベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とするイベント報知システム。少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とするイベント報知方法。コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とするプログラム。しかしながら、関連技術1、2には、イベントの一種でもあるメールの着信をどのようにユーザに報知するかの点について一切の言及開示がない。このため、一般的なイベントの報知方法を採用しているものと推測せざるを得ない。たとえば、冒頭で説明したアイコンによる報知を採用していると推測すると、この方法では、ユーザは単にイベントの種類、つまり、メールの着信を知ることができるだけである。一方、先にも言及したとおり、メールの受信数がますます増加する傾向にあることから、1度のメールチェックで、ときによっては、様々な相手から数十通あるいはそれ以上のメールが届くことがある。このようなことを想定して、一般的に、アイコンと一緒にメール受信数を表示することもよく行われている。つまり、アイコンのデザインでイベントの種類メールの受信を表すと共に、その種類におけるイベント数メールの受信数をアイコンと一緒に同時表示するという対策である。しかし、このような対策を講じても、同一種類のイベントが大量に発生した際の混乱を避けられない。たとえば、メールであれば、大量のメールの中に読むべきメールが埋没してしまうからである。本発明の目的は、イベントの報知をグループごとにまとめて行うことにより、同じ種類の大量のイベントが報知された場合の混乱回避を図ることにある。本発明のイベント報知装置は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。本発明のイベント報知システムは、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、前記イベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。本発明のイベント報知方法は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とする。本発明のプログラムは、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とする。本発明によれば、イベントの報知をグループごとにまとめて行うようにしたので、グループごとにイベント状況を把握でき、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができる。以下、本発明の実施形態を、携帯電話機への適用を例にして、図面を参照しながら説明する。まず、実施形態の構成を説明する。図1は、携帯電話機1の外観図である。図において、携帯電話機1は、特にそれに限定されないが、手持ちに適した厚みと大きさを有する縦長箱型形状の本体部2と、その本体部2の一短辺端側にヒンジ機構3を介して連結された、本体部2と略同型状かつ薄厚の蓋部4とを備えた、いわゆる折り畳み式の筐体5を有している。なお、この折り畳み式は一例に過ぎない。折り畳み式以外のもの非折り畳み式やスライド式またはフリップ式などであっても当然かまわない。また、この携帯電話機1は、本体部2に多数のハードウェアキーからなる操作部後述の操作部14を備えているが、この操作部を具備せず、その代わりに表示部後述の表示部9の画面上にソフトウェアキーを表示するタイプのものであってもよい。この場合、折り畳み式である必然性はない。いわゆるタブレット型平板型の筐体形状であってもよい。このようなタブレット型の携帯電話機は一般的にスマートフォンと呼ばれている。本体部2の一方面蓋部4との対向面には、多数のハードウェアキー以下、操作ボタンからなる操作ボタン群6や、後述のマイク13aが収められた送話孔7が設けられ、また、蓋部4の一方面本体部2との対向面には、前面にタッチパネル8が貼り付けられた表示部9や、後述のスピーカ13bが収められた受話孔10、及び、この表示部9を見ている人物の顔を撮影することができる撮像部11が設けられている。図2は、携帯電話機1の構成図である。携帯電話機1は、無線通信部12、音声処理部13、撮像部11、操作部14、タッチパネル8付の表示部9、メモリI/Fインターフェース15、メモリ16、外部I/F17、電源部18、及び、中央制御部19を備える。無線通信部12は、中央制御部19からの制御により、アンテナ12aを介して最寄りの携帯電話基地局図示略との間で所定周波数帯域及び所定変調方式の無線によるデジタルデータの送受信を行う。このデジタルデータには、電話の着呼や発呼の情報および音声通話の情報が含まれるほか、電子メールの送受信情報や、各種インターネットコンテンツの閲覧情報ならびに任意のネットワークサービスのサービス情報などが含まれる。音声処理部13は、中央制御部19からの制御により、マイク13aで拾った音声信号をデジタルデータに変換して中央制御部19に出力したり、中央制御部19から出力されたデジタルの音声信号をアナログ信号に変換してスピーカ13bから拡声したりする。撮像部11は、二次元撮像デバイス、たとえば、CCD型やCMOS型などの二次元半導体撮像デバイスで構成され、中央制御部19からの制御を受けて所定画角撮影範囲の画像を所定の周期で周期的に撮像し、その画像信号を中央制御部19に出力する。操作部14は、ユーザインターフェース用の入力手段であり、たとえば、電話番号入力と文字入力の兼用ボタンや、各種の機能ボタン及びカーソル操作キーなどのボタン群図1の操作ボタン群6を備え、ユーザ操作に応答して、それらのボタンやキーに対応した入力信号を発生して中央制御部19に出力する。表示部9は、液晶パネルなどの平面二次元表示デバイス好ましくは多色表示が可能で高精細な表示画面を持つものからなり、中央制御部19から適宜に出力される任意の情報を可視化して画面上に表示する。好ましくは、表示部9はタッチパネル8付きのものである。このタッチパネル8は、たとえば、人体の一部指先等や静電ペンなどの接触を検知して、その検知信号を中央制御部19に出力する静電容量方式のものであってもよく、または、ペン先等の堅い物質の接触を検知して、同様にその検知信号を中央制御部19に出力する抵抗膜方式のものであってもよく、あるいは、その他の方式のものであってもよい。タッチパネル9も、ユーザインターフェース用の入力手段として機能し、操作部14の一部を構成する。メモリI/F15は、たとえば、メモリ16の規格SDカード等に対応した汎用インターフェースであり、中央制御部19とメモリ16との間に位置して相互のデータのやりとりを仲介する。メモリ16は、不揮発性且つ書き換え可能な情報記憶要素であり、たとえば、SDカード等のフラッシュメモリやシリコンディスクあるいはハードディスクなどを用いることができる。このメモリ16は、様々なユーザデータ、たとえば、撮像部11で撮像された画像ファイルや、後述する電話帳図3の電話帳21参照およびメールボックス図3のメールボックス20参照などのデータを記憶保存する。外部I/F17は、パーソナルコンピュータなどの外部機器とのデータインターフェースである。外部機器は、この外部I/F17と中央制御部19とを介してメモリ16にアクセスすることが可能であり、メモリ16に記憶されているユーザデータを外部機器に取り出したり、あるいは、外部機器からメモリ16に書き戻したりすることができる。電源部18は、一次電池または充電可能な二次電池からなるバッテリを含み、このバッテリの電力から携帯電話機1の動作に必要な各種電源電圧を発生して各部に供給する。中央制御部19は、コンピュータまたはマイクロコンピュータ以下、CPU19a、読み出し専用半導体メモリ以下、ROM19bおよび高速半導体メモリ以下、RAM19cならびに不図示の周辺回路を含むプログラム制御方式の制御要素であり、あらかじめROM19bに格納されている制御プログラムをRAM19cにロードしてCPU19aで実行することにより、各種の処理を逐次に実行して、この携帯電話機1の全体動作を統括制御する。なお、ROM19bは、書き込み型の不揮発性半導体メモリPROMやEPROMなどであってもよい。図3は、携帯電話機1の主要部構成図である。この主要部構成図には、携帯電話機1を構成する前記各部のうちの表示部9と、操作部14と、メモリ16と、中央制御部19とが抜粋して示されており、さらに、メモリ16の内部に新たにメールボックス20と電話帳21が、また、中央制御部19の内部に新たにキー操作制御部22とメール振り分け制御部23が示されている。これら主要部のうち表示部9、操作部14、メモリ16および中央制御部19は、図2に示されている同符号部と同じものであるが、メールボックス20と電話帳21は、メモリ16の内部に確保された2つの個別記憶領域を模式化して表したものである。すなわち、メモリ16の記憶空間は、少なくともメールボックス20として用いられる一の記憶領域と、電話帳21として用いられる二の記憶領域とに分けられており、さらに、必要に応じて他の用途の記憶領域たとえば、画像ファイル保存用の領域等にも分けられている。また、キー操作制御部22とメール振り分け制御部23はソフトウェア的に実現される機能である。すなわち、キー操作制御部22とメール振り分け制御部23は、携帯電話機1のハードウェアリソースCPU19aなどの物理的要素とソフトウェアリソースCPU19aで実行される制御プログラムとの有機的結合によってソフトウェア的に実現される機能であり、実体が存在しない非物理的機能である。図4は、メールボックス20と電話帳21の構造模式図である。この図において、電話帳21は複数のグループに分けられている。各グループを符号TG0、TG1、TG2、、TGnで表すことにする。Tは電話、Gはグループ、末尾の0~nはグループ番号を表している。たとえば、TG1は電話用の1番目のグループであることを示す。グループ番号は0からnまでであり、したがって、グループ数はn1個である。0を除く1からnまでのグループTG1~TGnはユーザに開放されたユーザが自由に使用できる自由グループである。これらの自由グループは、たとえば、友人、仕事、その他の用途などに自由に用いられる。以下、自由グループのうちの1つのグループを示す場合にTGiと表記することもある。iは1~nのいずれかである。0番のグループTG0はシステム用である。ユーザが登録した電話帳データは、システムによって、まず、このTG0に保存される。しかる後、ユーザによって任意のグループへの振り分けが行われると、たとえば、TGiへの振り分けが行われると、TG0に保存されていた電話帳データが振り分け先のTGiに移動する。なお、移動でなくコピーでもよい。ここまでをまとめると、電話帳21のTG0はシステム用のグループ、TGi=TG1~TGnはユーザに開放された自由グループである。ユーザは、TG0に保存された電話帳データを任意のグループTGiに振り分け保存することができる。たとえば、TG1を友人用、TG2を仕事用とすると、TG0に保存された友人の電話帳データをTG1に保存したり、同じくTG0に保存された仕事関係者の電話帳データをTG2に保存したりすることができる。一方、メールボックス20も電話帳21と同様に複数のグループに分けられている。各グループを符号MG0、MG1、MG2、、MGnで表すことにする。Mはメール、Gはグループ、末尾の0~nはグループ番号を表している。たとえば、MG1はメール用の1番目のグループであることを示す。ここで、グループ番号は0からnまでであり、したがって、グループ数は電話帳21と同じn1個である。0を除く1からnまでのグループMG1~MGnはユーザに開放されたユーザが自由に使用できる自由グループである。以下、自由グループのうちの1つのグループを示す場合にMGiと表記することもある。iは1~nのいずれかである。MGi=MG1~MGnの用途は、電話帳21の自由グループTGi=TG1~TGnと同じである。たとえば、電話帳21のTG1を友人用、TG2を仕事用、TG3をその他用とすると、このメールボックス20のMG1も友人用、MG2も仕事用、MG3もその他用になる。つまり、TG1-MG1、TG2-MG2、TG3-MG3、、TGn-MGnというように互いに関連付けされている。ユーザによる用途の割り当ては電話帳21が先である。たとえば、電話帳21のTG1を友人用に割り当てると、この割り当てに同期してメールボックス20のMG1も友人用になる。MGiへのメールデータの振り分けは、メールヘツダ情報に含まれる差出人メールアドレス以下、単にアドレスというと電話帳21に保存されている電話帳データとの照合に基づいて行われる。これは、一般的に電話帳21に登録される電話帳データには名前や電話番号のほかに、アドレスなどの付加情報も含まれているからであり、このアドレスに基づいてメールデータのグループ振り分けを行うことができるからである。たとえば、電話帳21に友人Aのアドレスを含む電話帳データが登録されているものとし、且つ、その友人Aの電話帳データがTG1友人用に保存されているものとすると、この場合、友人Aからのメールデータは、アドレス照合によってメールボックス20のMG1友人用に振り分け保存される。電話帳21と同様に、メールボックス21の0番のグループMG0もシステム用である。このシステム用グループMG0には、アドレス照合の結果、グループ分けされていないことが判明した差出人、または、電話帳21に登録されていない差出人からのメールデータが保存される。図5は、アイコン保持テーブル24を示す図である。このアイコン保持テーブル24は、メールボックス20の全てのグループMG0~MGnを個別に視覚的識別可能なn1個のアイコン25_0~25_nの実体を保持する。または、別の場所に保存されたn1個のアイコン25_0~25_nへのリンク情報を保持する。アイコン保持テーブル24は、さらに、それぞれのアイコン25_0~25_nがどのグループに割り当てられているかを示す割り当て情報図ではグループ名と同じMG0~MGnを保持する。なお、このアイコン保持テーブル24は、メール以外の他のイベント報知用のアイコン、たとえば、不在着信用のアイコン図6の第1のイベント報知アイコン28参照などを保持していてもよい。各々のアイコン25_0~25_nは、任意の大きさ、任意の形状、且つ、任意のデザインの背景上に、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列図では封筒の絵としているなどを表示するための第1のエリア26_0~26_nと、割当先のメールボックスに存在する未読メール数を表示するための第2のエリア27_0~27_nとを設けている。図6は、アイコンの表示例を示す図である。この図において、表示部9には、数は一例であるが、4個のイベント報知アイコンが表示されている。第1のイベント報知アイコン28は不在着信報知用であり、この第1のイベント報知アイコン28には、不在着信であることを明示するための可視情報、たとえば、絵または図形もしくは文字列図では携帯電話機の絵としているなどを表示するための第1のエリア28aと、不在着信数mを表示するための第2のエリア28bとが設けられている。第2~第4のイベント報知アイコン29~31はメール受信報知用であり、これらの第2~第4のイベント報知アイコン29~31には、先のアイコン保持テーブル24図5参照に保持されているn1個のアイコン25_0~25_nが選択的に用いられる。たとえば、第2のイベント報知アイコン29にMG1用のアイコン25_1が用いられ、また、第3のイベント報知アイコン30にMG2用のアイコン25_2が用いられ、さらに、第4のイベント報知アイコン31にMG0用のアイコン25_0が用いられという具合である。いずれのアイコンが用いられるかは、もっぱら着信メールの保存先グループによって決まる。たとえば、上記の例示は、友人用のグループMG1と仕事用のグループM2とシステム用のグループMG0の各々に受信メールが保存された場合である。つまり、この場合、第2のイベント報知アイコン29は友人用のメール受信を報知し、第3のイベント報知アイコン30は仕事用のメール受信を報知し、第4のイベント報知アイコン31は、グループ分けされていない差出人からのメール受信、または、電話帳21に登録されていない差出人からのメール受信を報知することになる。ここで、実施形態にとって重要なポイントは、第1に、メールの受信という1つの種類のイベント報知を複数のアイコン図示の例では第2~第3のイベント報知アイコン29~31を用いて行う点にある。これら複数のアイコンは、上記のとおり、電話帳21と同じようにグループ分けされたものであるから、結局のところ、メール受信の報知をグループごとに行うことができる。したがって、大量のメール受信があった場合、つまり、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができ、さらに、受信したメールの差出人が友人や仕事などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、などといった状況判断を速やかに下すことができるという効果が得られる。この効果は、第1のイベント報知アイコン28不在着信報知用との対比からも明らかである。すなわち、第1のイベント報知アイコン28は、不在着信であることを明示するための可視情報を表示する第1のエリア28aと、不在着信数mを表示するための第2のエリア28bとが設けられおり、その不在着信数mは、携帯電話機1に着信した全ての不在着信の数を示している。したがって、この不在着信数mを見ただけでは、その不在着信の中にすぐに応答しなければならないものがどれだけあるのかを即座に知ることができない。一般的には不在着信リストを開き、そのリストの発信者名や電話番号を見て応答可否を判断することになるが、操作の手間を否めない。実施形態のメール受信報知は、グループごとのアイコン図示の例では第2~第4のイベント報知アイコン29~31を用いているので、何らの操作も必要とせずに、少なくとも、どのグループのメール受信であるのかを一目で知ることができ、その場でのメール開封、または、後での開封、もしくは、開封せずに無視する、といった状況判断を速やかに行うことができる。加えて、第2に、実施形態のグループごとのアイコン図示の例では第2~第4のイベント報知アイコン29~31は、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列図では封筒の絵としているなどを表示するためのエリア29a、30a、31a図5の第1のエリア26_0~26_nに相当を有すると共に、割当先のメールボックスに存在する未読メール数を表示するためのエリア29b、30b、31b図5の第2のエリア27_0、27_1、27_2に相当を有しているので、各グループの未読メール数便宜的にn1、n2、n3を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという効果も得られる。なお、以上の説明では、イベントの報知としているが、この言葉報知に限定されない。通知でもよい。要するに、ユーザにイベントを知らせることができればよい。図7は、電話帳21の構造模式図である。この図において、電話帳21を構成する各グループ全てのグルーブは同じ構造であり、ここではTG1を例にするは、一連番号001、002、003、が付された複数のレコードのそれぞれに、各人の電話帳データとして少なくとも名前や電話番号などを保持すると共に、さらに、アドレスなどの付加情報も保持する。図8は、メールボックス20の構造模式図である。この図において、メールボックス20を構成する各グループ全てのグルーブは同じ構造であり、ここではMG1を例にするは、一連番号001、002、003、が付された複数のレコードのそれぞれに、各メールのデータとして少なくとも未読や既読の状態、受信日時、差出人のアドレス、メールのタイトルおよびメールの本文などを保持する。ここで、メールボックス20の各レコードに保持されているアドレスと、先の電話帳21の各レコードに保持されているアドレスとが一致している点に留意されたい。これは、たとえば、電話帳21のグループTG1を友人用としたとき、そのグループTG1に登録されている友人太郎、山田、花子、田中、木村、坂本からのメールが、アドレス照合によって、メールボックス20の同用途友人用のグループMG1に保存されたことを示している。次に、実施形態の作用を説明する。始めに、先の図3を参照しながら、携帯電話機1の内部における信号の流れを説明する。<電話帳21へのデータ登録>ユーザーが操作部14を用いて任意の人物以下、人物Aとするの電話帳データ名前、電話番号、アドレス、の登録作業を行うと、この作業に応答して操作部14から中央制御部19のキー操作制御部22にキー信号が出力される。キー操作制御部22は、キー信号を解読し、所定の形式の登録信号名前、電話番号、アドレス、の情報を含む信号に変換し、その登録信号をメモリ16の電話帳21に書き込む。これにより、電話帳21に人物Aの電話帳データ名前、電話番号、アドレス、が登録される。<グループ分け>次いで、必要であれば、ユーザは、操作部14を用いて人物Aのグループ割り当てたとえば、友人グループTG1への割り当てを行う。このとき、すでに当該グループTG1が電話帳21に存在していれば、キー操作制御部22は、そのグループTG1への人物Aの電話帳データの移動又はコピー行う。一方、当該グループTG1が電話帳21に存在していなかった場合、キー操作制御部22は、メモリ16の電話帳21に友人用の新たなグループTG1を作成すると同時に、メモリ16のメールボックス20に対してグループ作成信号を出力し、メールボックス20に同じ友人用のグループMG1を作成する。このとき、メールボックス20に作成されたグループMG1に対して、専用のアイコン図5のアイコン25_1参照が割り当てられる。このようにして、電話帳21への電話帳データ登録とグループ分けが行われると共に、メールボックス20のグループ分けも行われ、さらに、メールボックス20のグループにそれぞれ固有のアイコンが割り当てられ、且つ、電話帳21のグループとメールボックス20のグループとの関連付けも行われる。<メール受信と報知>次に、メール受信時には、まず、無線通信部12図2参照で受信したメールが中央制御部19のメール振り分け制御部23に取り込まれる。メール振り分け制御部23は、受信メールのアドレスと、電話帳21に登録されているアドレスとを照合し、判定1どのグループに登録されているアドレスTG1~TGnのいずれかに登録されているアドレスであるか、または、判定2グループ分けされていないアドレスTG0のみに登録されているアドレスであるか、もしくは、判定3未登録のアドレスTG0~TGnのいずれにも登録されていないアドレスであるかを判定し、それらの判定結果に従って、以下の動作を実行する。判定1の場合:メール振り分け制御部23は、メールボックス20にグループMG1~MGnのいずれかを指定する振り分け信号を出力し、メールボックス20の該当するグループMG1~MGnのいずれかに受信メールを振り分け保存する。判定2及び判定3の場合:メール振り分け制御部23は、メールボックス20にシステム用のグループMG0を指定する振り分け信号を出力し、メールボックス20のシステム用のグループMG0に受信メールを保存する。このようにして、メール振り分け制御部23からの振り分け信号に応答し、メールボックス20の該当するグループMG0~MGnに受信メールが保存される。このとき同時に、中央制御部19のメール振り分け制御部23は、表示部9に対してメール受信報知用のアイコンを表示するための表示信号を出力し、これにより、表示部9の画面上に当該アイコン図6の第2~第4のイベント報知アイコン29~31を参照が表示され、メールを受信した旨の報知メール受信イベントの報知がユーザに対して行われる。ユーザは、そのメール受信報知用のアイコン図6の第2~第4のイベント報知アイコン29~31を参照を確認し、どのグループに何通の未読メールがあるのかを速やかに知ることができる。<メールの確認>そして、任意グループのメール一覧を知りたい場合には、所定の操作を行って当該グループのメール一覧画面を開き、差出人やタイトルなどを確認した上で、読みたいメールがあれば、その一覧から対象のメールを選択して開封するようにしてもよい。メール振り分け制御部23は、所要の開封信号をメールボックス20に対して出力し、メールボックス20から該当するメールを読み出すとともに、そのメールを表示するための表示信号を表示部9に出力し、表示部9の画面上に対象メールを可視化して表示する。メール一覧画面の開き方については特に限定しないが、近年の直感的なプログラム設計手法に従えば、各グループごとのメール受信報知用のアイコン図6の第2~第4のイベント報知アイコン29~31を参照を選択したときに、対象グループのメール一覧画面を開くようにしておくことが好ましい。アイコンをタッチするだけで速やかに一覧画面を開くことができる。また、一覧画面から任意のメールを開封する際にも同様な直感的な設計手法を採用することが好ましい。たとえば、リストボックスと呼ばれるプログラム部品を用いてメール一覧を表示するようにすれば、そのリストボックスの任意行の選択操作に応答してワンタッチで対象メールを開封することができる。次に、以上の動作をソフトウェア的に説明する。図9は、携帯電話機1の動作フローを示す図である。まず、ユーザーによって電話帳12への人物Aの電話帳データ名前、電話番号、アドレス、の登録が行われるものとする。電話帳への登録が行われない場合、以下のステップS1とステップS2は実行されず、ステップS1とステップS2をパスしてそのままステップS3に進む。電話帳12への登録を行うとき、ユーザは、操作部14を操作し、所定の順番に従って人物Aの電話帳データ名前、電話番号、アドレス、を入力するステップS1。このとき、人物Aのグループとして新たなグループを作成する必要がある場合は、そのグループ作成に必要な情報についても操作部14を用いて入力する。あるいは、人物Aを既存のグループに割り当てる場合は、そのグループ割り当てに必要な情報についても操作部14を用いて入力する。このようにして、電話帳12への人物Aの電話帳データの登録とグループ割り当て必要であれば新規グループの作成を行うと、次に、メールボックス20のグループ管理を行うステップS2。メールボックス20のグループ管理とは、先のステップS1で、電話帳12に新規のグループが作成された場合に、そのグループに関連づけられた新たなグループをメールボックス20にも作成することをいい、且つ、メールボックス20に新たに作成されたグループに固有のアイコンを割り当てることをいう。次いで、メールの受信処理を実行するステップS3。この図では省略しているが、メールの受信処理では、無線通信部12を経由して外部のメールサーバにアクセスし、当該メールサーバ内の自アカウント領域ユーザ専用のサーバ内メールボックスから受信メールを読み出すという一連の処理を実行する。この処理は定期的又は不定期に行われる。メールサーバ内の自アカウント領域に受信メールが届いていなければそのまま待機し、または他のバックグラウンド処理を実行する。受信メールが届いていれば、その受信メールを無線通信部12を介し、中央制御部19メール振り分け制御部23に取り込む。受信メールを取り込むと、次に、その受信メールの差出人アドレスと電話帳21に登録されているアドレスとを照合し、登録済みのアドレスであって、且つ、電話帳21でグルーブ分けされたアドレスであるか否かを判定するステップS4。なお、図では、ステップS4の処理内容をアドレス照合とし、その照合結果を照合結果X及び照合結果Yとしているが、これは説明上の都合である。これらの照合結果X及び照合結果Yは、後述の説明図13の説明で引用される。また、照合結果Xは前述の判定2または判定3に相当し、照合結果Yは前述の判定1に相当する。ステップS4の照合結果が照合結果Xの場合、つまり、未登録のアドレスである場合、または、登録済みであるがグルーブ分けされたアドレスでない場合は、その受信メールをメールボックス20のシステム用のグループMG0に保存しステップS5、その受信メールが未読であるか否かを判定するステップS6。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部9の画面上に、メール受信報知用のアイコン図6のシステム用のアイコン25_0参照を表示するステップS7。そして、ユーザによる所定の未読メール確認操作たとえば、アイコン25_0へのタッチ操作に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行しステップS8、ステップS9、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理表示部9の画面上へのメールデータ表示を実行ステップS10した後、フローを終了する。他方、ステップS4の照合結果が照合結果Yの場合、つまり、登録済みのアドレスであって、且つ、電話帳21でグルーブ分けされたアドレスである場合は、その受信メールをメールボックス20の該当するグループMGi電話帳21のグループに関連づけられたグループに保存しステップS11、その受信メールが未読であるか否かを判定するステップS12。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部9の画面上に、メール受信報知用のアイコン図6のアイコン25_1~25_nのいずれかを表示するステップS13。そして、ユーザによる所定の未読メール確認操作たとえば、任意のアイコンへのタッチ操作に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行しステップS14、ステップS15、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理表示部9の画面上へのメールデータ表示を実行ステップS16した後、フローを終了する。以上のとおりであるから、実施形態によれば、以下の効果を得ることができる。まず、第1に、メールの受信という1つの種類のイベント報知を複数のアイコン図6の例では第2~第3のイベント報知アイコン29~31を用いて行うようにしたので、メール受信の報知を1つのイベント種類メール受信だけでなく、さらに、グループごとにも掘り下げて行うことができる。したがって、受信したメールの差出人が友人や仕事などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、といった状況判断を速やかに下すことができるという優れた効果が得られる。加えて、第2に、グループごとのアイコン図6の例では第2~第4のイベント報知アイコン29~31は、割当先のメールボックスに存在する未読メール数を表示するためのエリア29b、30b、31b図5の第2のエリア27_0、27_1、27_2に相当を有しているので、各グループの未読メール数n1、n2、n3を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。さらに、波及的な効果としては、目的の受信メールを確認するまでのキー操作回数を減らすことができる。これは、アイコンをタッチするだけでメール一覧を表示できるからである。さらに必要であれば、その一覧をワンタッチしてメール本文を読むことができるからであり、少なくとも2回の操作で目的の受信メールにたどりつけるからである。また、受信メールがグループごとに自動振り分けされるため、手作業によるメールの振り分け作業が必要なくなり、手間の軽減を図ることもできる。さらに、グループごとにメールを読むことができるので、優先度を付けた開封を行うことができる。なお、以上の説明では、メールの受信という特定のイベントの報知について説明したが、これに限定されないことはもちろんである。たとえば、不在着信のイベント報知に応用してもよい。図10は、不在着信への応用例を示す図である。この図において、表示部9には、複数図では3個の不在着信報知用のアイコン以下、第5~第7のイベント報知アイコン32~34が表示されている。これらのアイコンも、前記のメール受信報知用のアイコン図6の第2~第4のイベント報知アイコン29~31参照と同様に、電話帳21のグループと同じグループに関連づけられたものである。たとえば、第5のイベント報知アイコン32は、電話帳21の友人グループTG1と同じグループに関連づけられたもの、第6のイベント報知アイコン33は、電話帳21の仕事関連グループTG2と同じグループに関連づけられたもの、第7のイベント報知アイコン34は、電話帳21のシステム用グループTG0と同じグループに関連づけられたものである。このようにしても、第1に、不在着信という1つの種類のイベント報知を複数のアイコン図10の例では第5~第7のイベント報知アイコン32~34を用いて行うことができ、不在着信の報知をグループごとに掘り下げて行うことができる。したがって、不在着信の相手が友人や仕事などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに応答すべきか、または、後で応答してもかまわないか、あるいは、放置すべきといった判断を速やかに下すことができるという優れた効果が得られる。加えて、第2に、グループごとのアイコン図10の例では第5~第7のイベント報知アイコン32~34は、グループごとの不在着信数を表示するためのエリア32a、33a、34aを有しているので、各グループの不在着信数m1~m3を一目で知ることができ、現時点でどのグループにどれだけの不在着信があったか、あるいは、先回の確認からどのグループの未不在着信がどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。以上の説明は、携帯電話機1への適用を例にしたが、ユーザに届く通知イベントは上記の例メール受信や不在着信に限らず、他にも様々なものがある。たとえば、スケジュール通知予めユーザが設定した日時に何らかの手段でイベントが発生するものもその1つである。とりわけ、インターネットなどのネットワークを利用したスケジュール通知サービスは、昨今、高機能且つきめ細やかなサービスが行われており、たとえば、仕事とプライベートの区別はもちろんのこと、さらに、仕事の場合もA社用、B社用、Cプロジェクト用、Dプロジェクト用などと細分化することができ、または、プライベートの場合も家庭用、E趣味用、F趣味用などと細分化することができる。さらに、ソーシャルネットワークサービスSNSなどの人対人の交流サービスにあっても同様のきめ細かなサービスが提供されている。こうしたサービスを利用する場合、ユーザの端末には多くのイベントが通知されることになる。とりわけ、複数のサービスを並行利用している場合は、より多くのイベントが通知される。図11aは、イベント通知型のネットワークサービス利用概念図である。この図において、インターネット等のネットワーク35には、複数図では4台のサービスサーバ以下、単にサーバという36~39が接続されていると共に、ユーザの端末40も接続されている。端末40のユーザは、これら4台のサーバ36~39が各々提供するサービスを利用しているものとする。サービスの内容は、たとえば、前述のスケジュール通知サービスやSNSなどであるが、他のサービスであってもかまわない。イベント通知型のサービスであればよい。今、サーバ36~39のアドレス、つまり、ネットワーク35上の固有の識別情報典型的にはURLを便宜的にそれぞれa、b、c、dとする。つまり、サーバ36のアドレスをa、サーバ37のアドレスをb、サーバ38のアドレスをc、サーバ39のアドレスをdとする。ユーザの端末40は、定期的または不定期に各々のサーバ36~39にアクセスし、各サーバ36~39から自分宛に通知されるイベントを取り込み、そのイベント報知を端末40の画面上に表示する。今、アドレスaのサーバ36から4つのイベントi1~i4が端末40に取り込まれ、また、アドレスbのサーバ37からも3つのイベントi5~i7が端末40に取り込まれたものとする。同様に、アドレスcのサーバ38からも4つのイベントi8~i11が端末40に取り込まれ、さらに、アドレスdのサーバ37からも1つのイベントi12が端末40に取り込まれたものとする。つまり、4台のサーバ36~39から端末40に合計12個のイベントi1~i12が取り込まれたものとする。図11bは、12個のイベントi1~i12をグループ分けするためのアドレステーブルの構造模式図である。このアドレステーブル41は、いくつかのグループ図では第1~第4の4つのグループごとにサーバ36~39のアドレスを振り分けている。たとえば、第1グループにアドレスのa]と[bを振り分け、第2グループにアドレスのa]と[cを振り分け、第3グループにアドレスのb]と[cを振り分け、第4グループにアドレスのd]を振り分けている。このような振り分け例に従えば、4台のサーバ36~39からの12個のイベントi1~i12をアドレスに従ってグルーブごとにまとめてユーザに報知することができる。図12は、グループごとの報知例を示す図である。aは比較のために示す非グループ報知例であり、bは前記実施形態の技術思想を適用したグループ報知例である。非グループ報知の場合、aに示すように、端末40の画面上には12個のイベント報知42~53のすべてが表示される。端末40の画面サイズが充分に大きければ特段の不都合を生じないものの、小さな画面サイズの場合、特にブック型や携帯型のタブレット端末などにおいては表示面積の圧迫を免れない。これに対して、bに示す例、つまり、前記実施形態の技術思想を適用したグループ報知例の場合は、各グループごとの4個のイベント報知54~57が表示されているに過ぎず、aとの比較で見ても、はるかに少ない表示数であるから、画面素表示面積の圧迫を招くことはない。したがって、特にブック型や携帯型のタブレット端末などのように小さな画面サイズの場合に有効である。さらに、bにおいて、4個のイベント報知54~57のそれぞれにグループ内のイベント数を表示するためのエリア54a~57aを設けておけば、各グループのイベント数、つまり、第1のグループのイベント数i1~i4とi5~i7の7個、第2のグループのイベント数i1~i4とi8~i11の8個、第3のグループのイベント数i5~i7とi8~i11の7個、第4のグループのイベント数i12の1個をそれぞれのエリア54a~57aに表示できるので、各グループのイベントの詳細な情報も一目で知ることができ、たとえば、どのグループのイベントを先に確認すべきか、などといった状況判断を速やかに下すことができる。このように、前記実施形態の技術思想は、スケジュール通知やSNSなどのネットワークサービスイベント通知型のサービスにも応用することができる。この場合、前記実施形態の技術思想の実体はサーバ側、端末側のいずれに実装してもかまわない。図13は、端末側に実施形態の技術思想の実体を実装した場合の概念図である。この図に示すように、端末40は、サーバ36~39からのイベントi1~i12を取り込み、イベントを発生したサーバ36~39のアドレスと、図11のアドレステーブル41とを照合し、どのグループに属するイベントであるかを判定するステップS21。次いで、端末40はそのグループ照合結果が照合結果X図9の照合結果Xに相当であれば、各々のイベントi1~i12をグループ分けして端末40の画面に表示するステップS22。このときの表示例は、図12aである。なお、どのグルーブにも属しないと判定されたイベント照合結果Y図9の照合結果Yに相当については、図12aに示すようなイベント単体の表示イベント報知42~53参照を行えばよいステップS23。前記実施形態の技術思想の実体をサーバ側に実装する場合は、図11のアドレステーブル41に相当するものをサーバで保持すると共に、図13のステップS21、ステップS22およびステップS23に相当する処理部をサーバに実装すればよい。この場合、自サーバで発生するイベントのみをグループ化することができる。グループ化した結果を端末40に送信すればよい。グループ化した結果を端末40に送信する仕組みには、いわゆる動的ホームページの技術を利用することができる。すなわち、ホームページには、サーバから端末に送られたHTMLファイルをそのまま表示する静的ホームページと、ユーザ端末からのリクエストに応じて例えば入力フォームの内容に応じて、サーバ上のプログラムがHTML文書を作成し、ユーザ端末に送り返す動的ホームページの二種類あるが、この動的ホームページの技術を利用すれば、サーバ上でイベントをグループ化した結果を動的HTML文書の形にして端末40に送信することができ、さらに、動的HTML文書に含まれているユーザリクエスト用コントロールボタンやリンク情報などの操作結果をサーバに送り返し、再び、所要の動的HTML文書たとえば、選択されたグループの詳細なイベント情報を含む文書を生成して端末40に送信することができる。このように、動的ホームページの技術を利用することにより、前記実施形態の技術思想の実体をサーバ側にも実装することができる。サーバ側と端末側のいずれに実装するかは、システムの運用目的等を勘案して適切に判断すればよい。本実施の形態ではメールボックスや電話帳を格納するのにメモリ16を用いて説明したが、これに限らない。RAM19cなどの記憶装置を使用してもよい。あるいは、ROM19bが書き換え可能のものプログラマブル型のROMである場合は、そのROM19bを使用してもよい。また、未読メール数、電話の不在着信数、イベントの未読数を例に説明したがこれに限らない。累積数だけでなく、直近のメール着信数や、直近の未読メール数、直近の電話の不在着信数や、不在着信後に電話をしてかけ直していない未応答数や直近の未応答数、直近の未読イベント数であってもよい。また、メールアドレスや電話番号やイベントのグループを判定した際の判定基準について、照合結果Xの基準として未登録のものである場合、または登録済みであるがグループ分けされたものではないとして、グループ0番としてまとめて通知する説明をしたがこれに限らない。未登録のものは別のグループ扱いとしてグループ0番や他のグループとは別のグループに見えるように分けて通知してもよい。また、未登録のものは通知しない仕組みとしてもよい。迷惑メールやワン切りなどの知らない人からの通知をしないようにしてもよい。また、0番のグループはシステム用で、グループ番号は1からの自然数として説明したが、これに限らない。グループA、B、C、グループ家族、グループ仕事等、表示上は数字には限らない。内部処理として検索処理可能なユニークな記号が内部的に割り振られたグループであればよい。また、不在着信数や未読メール数などの報知で画面に表示する際に種別アイコンに加えその数字を表示したが、画面の表示エリア、表示アイコン数、種類などの制約に応じて、全ての数字を表示しなくてもよい。例えば2桁以上の数字はなどの記号に置き換えて1桁分の表示エリアで表示をしてもよい。以下、本発明の特徴を付記する。上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。付記1図14は、付記1の構成図である。付記1は、少なくともイベントのグルーブ化が可能なグループ情報100:実施形態のメールアドレスや発信者番号、URLなどに相当を含むイベント情報101:実施形態のメール受信、不在着信、スケジュール通知などのイベント情報に相当を受信する受信手段102:実施形態のメール振り分け制御部23に相当と、前記グループ情報100に基づいて前記イベント情報101をグループ化するグループ化手段103:実施形態のメール振り分け制御部23に相当と、前記グループ化された単位でユーザにイベントを報知する報知手段104:実施形態のメール振り分け制御部23に相当とを備えたことを特徴とするイベント報知装置105:実施形態の携帯電話機1に相当である。付記2付記2は、前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする付記1に記載のイベント報知装置である。付記3付記3は、前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする付記1または付記2いずれかに記載のイベント報知装置である。付記4付記4は、前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする付記1または付記2いずれかに記載のイベント報知装置である。付記5付記5は、前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする付記1または付記2いずれかに記載のイベント報知装置である。付記6図15は、付記6の構成図である。付記6は、少なくともイベントのグルーブ化が可能なグループ情報100を含むイベント情報101を発生する発生手段106:実施形態のメールサーバ36~39に相当と、前記イベント情報101を受信する受信手段102と、前記グループ情報100に基づいて前記イベント情報101をグループ化するグループ化手段103と、前記グループ化された単位でユーザにイベントを報知する報知手段104とを備えたことを特徴とするイベント報知システム107である。付記7付記7は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とするイベント報知方法である。付記8付記8は、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とするプログラムである。