イベント報知システム、イベント報知装置、イベント報知方法及びプログラム
【課題】 近年、メールの受信数が増加する傾向にあり、簡単な受信イベントの報知では受信状況を把握しにくくなっている。
【解決手段】 メールの受信をグルーブごとに管理してグループ単位で報知するために、イベント報知装置（１０５）は、少なくともイベントのグルーブ化が可能なグループ情報（１００）を含むイベント情報（１０１）を受信する受信手段（１０２）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４）とを備える。
【解決手段】 メールの受信をグルーブごとに管理してグループ単位で報知するために、イベント報知装置（１０５）は、少なくともイベントのグルーブ化が可能なグループ情報（１００）を含むイベント情報（１０１）を受信する受信手段（１０２）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４）とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえば、メール着信や不在着信などのユーザに対する各種イベントを報知するためのイベント報知システム、イベント報知装置、イベント報知方法及びプログラムに関する。
【背景技術】
【０００２】
近年、携帯電話機などのコンピュータ応用機器の普及に伴い、当該機器のユーザ（利用者）に対して、多種多様なイベントの報知、たとえば、メール着信、不在着信、スケジュール通知などの報知が行われるようになってきた。
かかるイベントをユーザに報知するための方法（以下、旧来方法）として、古くから、ハードウェア的な報知、つまり、機器本体のスピーカから着信音を流したり、機器本体を振動させたり、機器本体のランプを点灯させたりすることが行われてきたが、この旧来方法では、イベントの種類、たとえば、メール着信や不在着信などの種類を“直感的”に判断することができず、しばしば、「この着信音はメールの受信？それとも不在着信？」などといった混乱を生じていた。
【０００３】
かかる背景から、今日におけるイベントの報知は、機器本体の画面を利用して視覚的に行われる方法が主流になっている。すなわち、画面上に、メール着信や不在着信などの各種イベントを示す個別のオブジェクトを表示することが行われている。イベント報知に用いられるオブジェクトの典型はアイコンである。アイコンのデザインを変えてイベントの種類を表現する。たとえば、封筒の絵をデザインしたアイコンはメール着信を直感的に表現し、あるいは、電話機の絵をデザインしたアイコンは不在着信を直感的に表現する。したがって、ユーザは、それらの絵を見るだけで、イベントの種類、つまり、メール着信であるのか、不在着信であるのか、などを直感的に把握することができ、前記の混乱を生じない。
【０００４】
このように、イベントの“種類”については、一応のところ、すでに直感的に把握できる技術が確立している。
【０００５】
しかしながら、同じ種類のイベント報知であっても、その内容はますます複雑化する傾向にあり、単にイベントの種類ごとのオブジェクト（アイコン等）を表示しただけでは、複雑化の傾向に対応しきれなくなってきている。たとえば、メールを例にして説明すると、メールの受信数は受信者の属性（年齢性別や職種／学生など）にかかわらず、ますます増加しつつあり、大量のメールを読んだり、削除したりする際に多くの労力を要するようになってきている。このことは、不在着信についても同様である。知人（家族、友人、仕事仲間など）からの着信だけでなく、見知らぬ第三者や一時的な相手（たとえば、予約したレストラン）からの着信などもしばしばあり、それらの相手ごとの応答可否を決めるのが面倒になってきている。また、スケジュール通知も、私的なものから公的なものまで幅広く、ますます管理が面倒になってきている。
【０００６】
この点に関し、下記の特許文献１の段落〔００２９〕中頃に「受信グループ１・４１３には電話帳のグループ１・４０３の登録者からのメールが保存される。」と記載されていることから、同文献には、電話帳のグループに対応した個別のメールボックスを作り、それらのメールボックスに受信メールを分類して保存する技術（以下、第１の関連技術という）が開示されていると認められる。
また、下記の特許文献２の段落〔０１１５〕に「アドレス帳において、各人物のグループが設定されている。」と記載されており、さらに、同文献の段落〔０１１７〕に「イメージ画面が表示されたときに、表示された人物画像を接触操作すると、・・・・当該接触操作された人物画像と同じグループに設定された人物の人物画像が表示されるようになっている。」と記載されていることから、同文献には、グループごとに分類されたアイコン（人物画像）を表示する技術（以下、第２の関連技術という）が開示されていると認められる。
【０００７】
要するに、関連技術１は電話帳の情報を利用し、グループごとにメールを仕分けして整理分類する技術であり、また、関連技術２はグループ内の情報をアイコンで整理分類する技術であるといえるから、これらの技術を利用することにより、大量のメールを読んだり、削除したりする際の手間を軽減することが可能になる。これは、グループ単位にメールを読んだり、削除したりできるからである。この考え方（グループ単位の仕分け）は、不在着信やスケジュール通知にも応用することができる。いずれも、グループ単位に応答可否を判断したり、スケジュール管理をしたりできるからである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−０２０６８４号公報
【特許文献２】特開２００８−１４１５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、関連技術１、２には、イベントの一種でもあるメールの着信をどのようにユーザに“報知”するかの点について一切の言及（開示）がない。このため、一般的なイベントの報知方法を採用しているものと推測せざるを得ない。たとえば、冒頭で説明したアイコンによる報知を採用していると推測すると、この方法では、ユーザは単にイベントの種類、つまり、メールの着信を知ることができるだけである。
一方、先にも言及したとおり、メールの受信数がますます増加する傾向にあることから、１度のメールチェックで、ときによっては、様々な相手から数十通あるいはそれ以上のメールが届くことがある。このようなことを想定して、一般的に、アイコンと一緒にメール受信数を表示することもよく行われている。つまり、アイコンのデザインでイベントの種類（メールの受信）を表すと共に、その種類におけるイベント数（メールの受信数）をアイコンと一緒に同時表示するという対策である。
しかし、このような対策を講じても、同一種類のイベントが大量に発生した際の混乱を避けられない。たとえば、メールであれば、大量のメールの中に読むべきメールが埋没してしまうからである。
【００１０】
本発明の目的は、イベントの報知をグループごとにまとめて行うことにより、同じ種類の大量のイベントが報知された場合の混乱回避を図ることにある。
【課題を解決するための手段】
【００１１】
本発明のイベント報知装置は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。
本発明のイベント報知システムは、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、前記イベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。
本発明のイベント報知方法は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とする。
本発明のプログラムは、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、イベントの報知をグループごとにまとめて行うようにしたので、グループごとにイベント状況を把握でき、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】携帯電話機１の外観図である。
【図２】携帯電話機１の構成図である。
【図３】携帯電話機１の主要部構成図である。
【図４】メールボックス２０と電話帳２１の構造模式図である。
【図５】アイコン保持テーブル２４を示す図である。
【図６】アイコンの表示例を示す図である。
【図７】電話帳２１の構造模式図である。
【図８】メールボックス２０の構造模式図である。
【図９】携帯電話機１の動作フローを示す図である。
【図１０】不在着信への応用例を示す図である。
【図１１】イベント通知型のネットワークサービス利用概念図（ａ）及びアドレステーブルの構造模式図（ｂ）である。
【図１２】グループごとの報知例を示す図である。
【図１３】端末側に実施形態の技術思想の実体を実装した場合の概念図である。
【図１４】付記１の構成図である。
【図１５】付記６の構成図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態を、携帯電話機への適用を例にして、図面を参照しながら説明する。
まず、実施形態の構成を説明する。
図１は、携帯電話機１の外観図である。図において、携帯電話機１は、特にそれに限定されないが、手持ちに適した厚みと大きさを有する縦長箱型形状の本体部２と、その本体部２の一短辺端側にヒンジ機構３を介して連結された、本体部２と略同型状かつ薄厚の蓋部４とを備えた、いわゆる「折り畳み式」の筐体５を有している。なお、この「折り畳み式」は一例に過ぎない。折り畳み式以外のもの（非折り畳み式やスライド式またはフリップ式など）であっても当然かまわない。また、この携帯電話機１は、本体部２に多数のハードウェアキーからなる操作部（後述の操作部１４）を備えているが、この操作部を具備せず、その代わりに表示部（後述の表示部９）の画面上にソフトウェアキーを表示するタイプのものであってもよい。この場合、「折り畳み式」である必然性はない。いわゆるタブレット型（平板型）の筐体形状であってもよい。このようなタブレット型の携帯電話機は一般的にスマートフォンと呼ばれている。
【００１５】
本体部２の一方面（蓋部４との対向面）には、多数のハードウェアキー（以下、操作ボタン）からなる操作ボタン群６や、後述のマイク１３ａが収められた送話孔７が設けられ、また、蓋部４の一方面（本体部２との対向面）には、前面にタッチパネル８が貼り付けられた表示部９や、後述のスピーカ１３ｂが収められた受話孔１０、及び、この表示部９を見ている人物の顔を撮影することができる撮像部１１が設けられている。
【００１６】
図２は、携帯電話機１の構成図である。携帯電話機１は、無線通信部１２、音声処理部１３、撮像部１１、操作部１４、タッチパネル８付の表示部９、メモリＩ／Ｆ（インターフェース）１５、メモリ１６、外部Ｉ／Ｆ１７、電源部１８、及び、中央制御部１９を備える。
【００１７】
無線通信部１２は、中央制御部１９からの制御により、アンテナ１２ａを介して最寄りの携帯電話基地局（図示略）との間で所定周波数帯域及び所定変調方式の無線によるデジタルデータの送受信を行う。このデジタルデータには、電話の着呼や発呼の情報および音声通話の情報が含まれるほか、電子メールの送受信情報や、各種インターネットコンテンツの閲覧情報ならびに任意のネットワークサービスのサービス情報などが含まれる。
【００１８】
音声処理部１３は、中央制御部１９からの制御により、マイク１３ａで拾った音声信号をデジタルデータに変換して中央制御部１９に出力したり、中央制御部１９から出力されたデジタルの音声信号をアナログ信号に変換してスピーカ１３ｂから拡声したりする。
【００１９】
撮像部１１は、二次元撮像デバイス、たとえば、ＣＣＤ型やＣＭＯＳ型などの二次元半導体撮像デバイスで構成され、中央制御部１９からの制御を受けて所定画角（撮影範囲）の画像を所定の周期で周期的に撮像し、その画像信号を中央制御部１９に出力する。
【００２０】
操作部１４は、ユーザインターフェース用の入力手段であり、たとえば、電話番号入力と文字入力の兼用ボタンや、各種の機能ボタン及びカーソル操作キーなどのボタン群（図１の操作ボタン群６）を備え、ユーザ操作に応答して、それらのボタンやキーに対応した入力信号を発生して中央制御部１９に出力する。
【００２１】
表示部９は、液晶パネルなどの平面二次元表示デバイス（好ましくは多色表示が可能で高精細な表示画面を持つもの）からなり、中央制御部１９から適宜に出力される任意の情報を可視化して画面上に表示する。好ましくは、表示部９はタッチパネル８付きのものである。このタッチパネル８は、たとえば、人体の一部（指先等）や静電ペンなどの接触を検知して、その検知信号を中央制御部１９に出力する静電容量方式のものであってもよく、または、ペン先等の堅い物質の接触を検知して、同様にその検知信号を中央制御部１９に出力する抵抗膜方式のものであってもよく、あるいは、その他の方式のものであってもよい。タッチパネル９も、ユーザインターフェース用の入力手段として機能し、操作部１４の一部を構成する。
【００２２】
メモリＩ／Ｆ１５は、たとえば、メモリ１６の規格（ＳＤカード等）に対応した汎用インターフェースであり、中央制御部１９とメモリ１６との間に位置して相互のデータのやりとりを仲介する。
【００２３】
メモリ１６は、不揮発性且つ書き換え可能な情報記憶要素であり、たとえば、ＳＤカード等のフラッシュメモリやシリコンディスクあるいはハードディスクなどを用いることができる。このメモリ１６は、様々なユーザデータ、たとえば、撮像部１１で撮像された画像ファイルや、後述する電話帳（図３の電話帳２１参照）およびメールボックス（図３のメールボックス２０参照）などのデータを記憶保存する。
【００２４】
外部Ｉ／Ｆ１７は、パーソナルコンピュータなどの外部機器とのデータインターフェースである。外部機器は、この外部Ｉ／Ｆ１７と中央制御部１９とを介してメモリ１６にアクセスすることが可能であり、メモリ１６に記憶されているユーザデータを外部機器に取り出したり、あるいは、外部機器からメモリ１６に書き戻したりすることができる。
【００２５】
電源部１８は、一次電池または充電可能な二次電池からなるバッテリを含み、このバッテリの電力から携帯電話機１の動作に必要な各種電源電圧を発生して各部に供給する。
【００２６】
中央制御部１９は、コンピュータまたはマイクロコンピュータ（以下、ＣＰＵ）１９ａ、読み出し専用半導体メモリ（以下、ＲＯＭ）１９ｂおよび高速半導体メモリ（以下、ＲＡＭ）１９ｃならびに不図示の周辺回路を含むプログラム制御方式の制御要素であり、あらかじめＲＯＭ１９ｂに格納されている制御プログラムをＲＡＭ１９ｃにロードしてＣＰＵ１９ａで実行することにより、各種の処理を逐次に実行して、この携帯電話機１の全体動作を統括制御する。なお、ＲＯＭ１９ｂは、書き込み型の不揮発性半導体メモリ（ＰＲＯＭやＥＰＲＯＭなど）であってもよい。
【００２７】
図３は、携帯電話機１の主要部構成図である。この主要部構成図には、携帯電話機１を構成する前記各部のうちの表示部９と、操作部１４と、メモリ１６と、中央制御部１９とが抜粋して示されており、さらに、メモリ１６の内部に新たにメールボックス２０と電話帳２１が、また、中央制御部１９の内部に新たにキー操作制御部２２とメール振り分け制御部２３が示されている。
【００２８】
これら主要部のうち表示部９、操作部１４、メモリ１６および中央制御部１９は、図２に示されている同符号部と同じものであるが、メールボックス２０と電話帳２１は、メモリ１６の内部に確保された２つの個別記憶領域を模式化して表したものである。すなわち、メモリ１６の記憶空間は、少なくともメールボックス２０として用いられる一の記憶領域と、電話帳２１として用いられる二の記憶領域とに分けられており、さらに、必要に応じて他の用途の記憶領域（たとえば、画像ファイル保存用の領域等）にも分けられている。
【００２９】
また、キー操作制御部２２とメール振り分け制御部２３はソフトウェア的に実現される機能である。すなわち、キー操作制御部２２とメール振り分け制御部２３は、携帯電話機１のハードウェアリソース（ＣＰＵ１９ａなどの物理的要素）とソフトウェアリソース（ＣＰＵ１９ａで実行される制御プログラム）との有機的結合によってソフトウェア的に実現される機能であり、実体が存在しない非物理的機能である。
【００３０】
図４は、メールボックス２０と電話帳２１の構造模式図である。この図において、電話帳２１は複数のグループに分けられている。各グループを符号ＴＧ０、ＴＧ１、ＴＧ２、・・・・、ＴＧｎで表すことにする。“Ｔ”は電話、“Ｇ”はグループ、末尾の“０”〜“ｎ”はグループ番号を表している。たとえば、ＴＧ１は電話用の１番目のグループであることを示す。グループ番号は“０”から“ｎ”までであり、したがって、グループ数はｎ＋１個である。
“０”を除く“１”から“ｎ”までのグループ（ＴＧ１〜ＴＧｎ）はユーザに開放された（ユーザが自由に使用できる）自由グループである。これらの自由グループは、たとえば、友人、仕事、その他の用途などに自由に用いられる。以下、自由グループのうちの１つのグループを示す場合にＴＧｉと表記することもある。“ｉ”は“１”〜“ｎ”のいずれかである。
【００３１】
０番のグループ（ＴＧ０）はシステム用である。ユーザが登録した電話帳データは、システムによって、まず、このＴＧ０に保存される。しかる後、ユーザによって任意のグループへの振り分けが行われると、たとえば、ＴＧｉへの振り分けが行われると、ＴＧ０に保存されていた電話帳データが振り分け先のＴＧｉに移動する。なお、移動でなくコピーでもよい。
【００３２】
ここまでをまとめると、電話帳２１のＴＧ０はシステム用のグループ、ＴＧｉ（＝ＴＧ１〜ＴＧｎ）はユーザに開放された自由グループである。ユーザは、ＴＧ０に保存された電話帳データを任意のグループＴＧｉに振り分け保存することができる。たとえば、ＴＧ１を友人用、ＴＧ２を仕事用とすると、ＴＧ０に保存された友人の電話帳データをＴＧ１に保存したり、同じくＴＧ０に保存された仕事関係者の電話帳データをＴＧ２に保存したりすることができる。
【００３３】
一方、メールボックス２０も電話帳２１と同様に複数のグループに分けられている。各グループを符号ＭＧ０、ＭＧ１、ＭＧ２、・・・・、ＭＧｎで表すことにする。“Ｍ”はメール、“Ｇ”はグループ、末尾の“０”〜“ｎ”はグループ番号を表している。たとえば、ＭＧ１はメール用の１番目のグループであることを示す。ここで、グループ番号は“０”から“ｎ”までであり、したがって、グループ数は電話帳２１と同じｎ＋１個である。
“０”を除く“１”から“ｎ”までのグループ（ＭＧ１〜ＭＧｎ）はユーザに開放された（ユーザが自由に使用できる）自由グループである。以下、自由グループのうちの１つのグループを示す場合にＭＧｉと表記することもある。“ｉ”は“１”〜“ｎ”のいずれかである。
ＭＧｉ（＝ＭＧ１〜ＭＧｎ）の用途は、電話帳２１の自由グループＴＧｉ（＝ＴＧ１〜ＴＧｎ）と同じである。たとえば、電話帳２１のＴＧ１を友人用、ＴＧ２を仕事用、ＴＧ３をその他用とすると、このメールボックス２０のＭＧ１も友人用、ＭＧ２も仕事用、ＭＧ３もその他用になる。
つまり、ＴＧ１−ＭＧ１、ＴＧ２−ＭＧ２、ＴＧ３−ＭＧ３、・・・・、ＴＧｎ−ＭＧｎというように互いに関連付けされている。ユーザによる用途の割り当ては電話帳２１が先である。たとえば、電話帳２１のＴＧ１を友人用に割り当てると、この割り当てに同期してメールボックス２０のＭＧ１も友人用になる。
【００３４】
ＭＧｉへのメールデータの振り分けは、メールヘツダ情報に含まれる差出人メールアドレス（以下、単にアドレスという）と電話帳２１に保存されている電話帳データとの照合に基づいて行われる。これは、一般的に電話帳２１に登録される電話帳データには名前や電話番号のほかに、アドレスなどの付加情報も含まれているからであり、このアドレスに基づいてメールデータのグループ振り分けを行うことができるからである。
たとえば、電話帳２１に友人Ａのアドレスを含む電話帳データが登録されているものとし、且つ、その友人Ａの電話帳データがＴＧ１（友人用）に保存されているものとすると、この場合、友人Ａからのメールデータは、アドレス照合によってメールボックス２０のＭＧ１（友人用）に振り分け保存される。
【００３５】
電話帳２１と同様に、メールボックス２１の０番のグループ（ＭＧ０）もシステム用である。このシステム用グループＭＧ０には、アドレス照合の結果、グループ分けされていないことが判明した差出人、または、電話帳２１に登録されていない差出人からのメールデータが保存される。
【００３６】
図５は、アイコン保持テーブル２４を示す図である。このアイコン保持テーブル２４は、メールボックス２０の全てのグループＭＧ０〜ＭＧｎを個別に視覚的識別可能なｎ＋１個のアイコン２５＿０〜２５＿ｎの実体を保持する。または、別の場所に保存されたｎ＋１個のアイコン２５＿０〜２５＿ｎへのリンク情報を保持する。アイコン保持テーブル２４は、さらに、それぞれのアイコン２５＿０〜２５＿ｎがどのグループに割り当てられているかを示す割り当て情報（図ではグループ名と同じＭＧ０〜ＭＧｎ）を保持する。
なお、このアイコン保持テーブル２４は、メール以外の他のイベント報知用のアイコン、たとえば、不在着信用のアイコン（図６の第１のイベント報知アイコン２８参照）などを保持していてもよい。
【００３７】
各々のアイコン２５＿０〜２５＿ｎは、任意の大きさ、任意の形状、且つ、任意のデザインの背景上に、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では封筒の絵としている）などを表示するための第１のエリア２６＿０〜２６＿ｎと、割当先のメールボックスに存在する未読メール数を表示するための第２のエリア２７＿０〜２７＿ｎとを設けている。
【００３８】
図６は、アイコンの表示例を示す図である。この図において、表示部９には、数は一例であるが、４個のイベント報知アイコンが表示されている。第１のイベント報知アイコン２８は不在着信報知用であり、この第１のイベント報知アイコン２８には、不在着信であることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では携帯電話機の絵としている）などを表示するための第１のエリア２８ａと、不在着信数ｍを表示するための第２のエリア２８ｂとが設けられている。
【００３９】
第２〜第４のイベント報知アイコン２９〜３１はメール受信報知用であり、これらの第２〜第４のイベント報知アイコン２９〜３１には、先のアイコン保持テーブル２４（図５参照）に保持されているｎ＋１個のアイコン２５＿０〜２５＿ｎが選択的に用いられる。たとえば、第２のイベント報知アイコン２９にＭＧ１用のアイコン２５＿１が用いられ、また、第３のイベント報知アイコン３０にＭＧ２用のアイコン２５＿２が用いられ、さらに、第４のイベント報知アイコン３１にＭＧ０用のアイコン２５＿０が用いられという具合である。
【００４０】
いずれのアイコンが用いられるかは、もっぱら着信メールの保存先グループによって決まる。たとえば、上記の例示は、友人用のグループＭＧ１と仕事用のグループＭ２とシステム用のグループＭＧ０の各々に受信メールが保存された場合である。
【００４１】
つまり、この場合、第２のイベント報知アイコン２９は「友人用」のメール受信を報知し、第３のイベント報知アイコン３０は「仕事用」のメール受信を報知し、第４のイベント報知アイコン３１は、グループ分けされていない差出人からのメール受信、または、電話帳２１に登録されていない差出人からのメール受信を報知することになる。
【００４２】
ここで、実施形態にとって重要なポイントは、第１に、メールの受信という１つの種類のイベント報知を複数のアイコン（図示の例では第２〜第３のイベント報知アイコン２９〜３１）を用いて行う点にある。これら複数のアイコンは、上記のとおり、電話帳２１と同じようにグループ分けされたものであるから、結局のところ、メール受信の報知をグループごとに行うことができる。したがって、大量のメール受信があった場合、つまり、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができ、さらに、受信したメールの差出人が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、などといった状況判断を速やかに下すことができるという効果が得られる。
【００４３】
この効果は、第１のイベント報知アイコン２８（不在着信報知用）との対比からも明らかである。すなわち、第１のイベント報知アイコン２８は、不在着信であることを明示するための可視情報を表示する第１のエリア２８ａと、不在着信数ｍを表示するための第２のエリア２８ｂとが設けられおり、その不在着信数ｍは、携帯電話機１に着信した“全て”の不在着信の数を示している。したがって、この不在着信数ｍを見ただけでは、その不在着信の中にすぐに応答しなければならないものがどれだけあるのかを即座に知ることができない。一般的には不在着信リストを開き、そのリストの発信者名や電話番号を見て応答可否を判断することになるが、操作の手間を否めない。
【００４４】
実施形態のメール受信報知は、グループごとのアイコン（図示の例では第２〜第４のイベント報知アイコン２９〜３１）を用いているので、何らの操作も必要とせずに、少なくとも、どのグループのメール受信であるのかを一目で知ることができ、その場でのメール開封、または、後での開封、もしくは、開封せずに無視する、といった状況判断を速やかに行うことができる。
【００４５】
加えて、第２に、実施形態のグループごとのアイコン（図示の例では第２〜第４のイベント報知アイコン２９〜３１）は、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では封筒の絵としている）などを表示するためのエリア２９ａ、３０ａ、３１ａ（図５の第１のエリア２６＿０〜２６＿ｎに相当）を有すると共に、割当先のメールボックスに存在する未読メール数を表示するためのエリア２９ｂ、３０ｂ、３１ｂ（図５の第２のエリア２７＿０、２７＿１、２７＿２に相当）を有しているので、各グループの未読メール数（便宜的にｎ１、ｎ２、ｎ３）を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという効果も得られる。
【００４６】
なお、以上の説明では、イベントの“報知”としているが、この言葉（報知）に限定されない。“通知”でもよい。要するに、ユーザにイベントを「知らせる」ことができればよい。
【００４７】
図７は、電話帳２１の構造模式図である。この図において、電話帳２１を構成する各グループ（全てのグルーブは同じ構造であり、ここではＴＧ１を例にする）は、一連番号（００１、００２、００３、・・・・）が付された複数のレコードのそれぞれに、各人の電話帳データとして少なくとも名前や電話番号などを保持すると共に、さらに、アドレスなどの付加情報も保持する。
【００４８】
図８は、メールボックス２０の構造模式図である。この図において、メールボックス２０を構成する各グループ（全てのグルーブは同じ構造であり、ここではＭＧ１を例にする）は、一連番号（００１、００２、００３、・・・・）が付された複数のレコードのそれぞれに、各メールのデータとして少なくとも未読や既読の状態、受信日時、差出人のアドレス、メールのタイトルおよびメールの本文などを保持する。
【００４９】
ここで、メールボックス２０の各レコードに保持されているアドレスと、先の電話帳２１の各レコードに保持されているアドレスとが一致している点に留意されたい。これは、たとえば、電話帳２１のグループＴＧ１を「友人用」としたとき、そのグループＴＧ１に登録されている友人（“太郎”、“山田”、“花子”、“田中”、“木村”、“坂本”）からのメールが、アドレス照合によって、メールボックス２０の同用途（友人用）のグループＭＧ１に保存されたことを示している。
【００５０】
次に、実施形態の作用を説明する。
始めに、先の図３を参照しながら、携帯電話機１の内部における信号の流れを説明する。
＜電話帳２１へのデータ登録＞
ユーザーが操作部１４を用いて任意の人物（以下、人物Ａとする）の電話帳データ（名前、電話番号、アドレス、・・・・）の登録作業を行うと、この作業に応答して操作部１４から中央制御部１９のキー操作制御部２２にキー信号が出力される。キー操作制御部２２は、キー信号を解読し、所定の形式の登録信号（名前、電話番号、アドレス、・・・・の情報を含む信号）に変換し、その登録信号をメモリ１６の電話帳２１に書き込む。これにより、電話帳２１に人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）が登録される。
【００５１】
＜グループ分け＞
次いで、必要であれば、ユーザは、操作部１４を用いて人物Ａのグループ割り当て（たとえば、友人グループＴＧ１への割り当て）を行う。このとき、すでに当該グループＴＧ１が電話帳２１に存在していれば、キー操作制御部２２は、そのグループＴＧ１への人物Ａの電話帳データの移動又はコピー行う。一方、当該グループＴＧ１が電話帳２１に存在していなかった場合、キー操作制御部２２は、メモリ１６の電話帳２１に友人用の新たなグループＴＧ１を作成すると同時に、メモリ１６のメールボックス２０に対してグループ作成信号を出力し、メールボックス２０に同じ友人用のグループＭＧ１を作成する。このとき、メールボックス２０に作成されたグループＭＧ１に対して、専用のアイコン（図５のアイコン２５＿１参照）が割り当てられる。
【００５２】
このようにして、電話帳２１への電話帳データ登録とグループ分けが行われると共に、メールボックス２０のグループ分けも行われ、さらに、メールボックス２０のグループにそれぞれ固有のアイコンが割り当てられ、且つ、電話帳２１のグループとメールボックス２０のグループとの関連付けも行われる。
【００５３】
＜メール受信と報知＞
次に、メール受信時には、まず、無線通信部１２（図２参照）で受信したメールが中央制御部１９のメール振り分け制御部２３に取り込まれる。メール振り分け制御部２３は、受信メールのアドレスと、電話帳２１に登録されているアドレスとを照合し、（判定１）どのグループに登録されているアドレス（ＴＧ１〜ＴＧｎのいずれかに登録されているアドレス）であるか、または、（判定２）グループ分けされていないアドレス（ＴＧ０のみに登録されているアドレス）であるか、もしくは、（判定３）未登録のアドレス（ＴＧ０〜ＴＧｎのいずれにも登録されていないアドレス）であるかを判定し、それらの判定結果に従って、以下の動作を実行する。
【００５４】
（判定１）の場合：
メール振り分け制御部２３は、メールボックス２０にグループＭＧ１〜ＭＧｎのいずれかを指定する振り分け信号を出力し、メールボックス２０の該当するグループ（ＭＧ１〜ＭＧｎのいずれか）に受信メールを振り分け保存する。
（判定２）及び（判定３）の場合：
メール振り分け制御部２３は、メールボックス２０にシステム用のグループＭＧ０を指定する振り分け信号を出力し、メールボックス２０のシステム用のグループＭＧ０に受信メールを保存する。
【００５５】
このようにして、メール振り分け制御部２３からの振り分け信号に応答し、メールボックス２０の該当するグループ（ＭＧ０〜ＭＧｎ）に受信メールが保存される。
【００５６】
このとき同時に、中央制御部１９のメール振り分け制御部２３は、表示部９に対してメール受信報知用のアイコンを表示するための表示信号を出力し、これにより、表示部９の画面上に当該アイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）が表示され、メールを受信した旨の報知（メール受信イベントの報知）がユーザに対して行われる。
【００５７】
ユーザは、そのメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）を確認し、どのグループに何通の未読メールがあるのかを速やかに知ることができる。
【００５８】
＜メールの確認＞
そして、任意グループのメール一覧を知りたい場合には、所定の操作を行って当該グループのメール一覧画面を開き、差出人やタイトルなどを確認した上で、読みたいメールがあれば、その一覧から対象のメールを選択して開封するようにしてもよい。メール振り分け制御部２３は、所要の開封信号をメールボックス２０に対して出力し、メールボックス２０から該当するメールを読み出すとともに、そのメールを表示するための表示信号を表示部９に出力し、表示部９の画面上に対象メールを可視化して表示する。
【００５９】
メール一覧画面の開き方については特に限定しないが、近年の直感的なプログラム設計手法に従えば、各グループごとのメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）を選択したときに、対象グループのメール一覧画面を開くようにしておくことが好ましい。アイコンをタッチするだけで速やかに一覧画面を開くことができる。また、一覧画面から任意のメールを開封する際にも同様な直感的な設計手法を採用することが好ましい。たとえば、リストボックスと呼ばれるプログラム部品を用いてメール一覧を表示するようにすれば、そのリストボックスの任意行の選択操作に応答してワンタッチで対象メールを開封することができる。
【００６０】
次に、以上の動作をソフトウェア的に説明する。
図９は、携帯電話機１の動作フローを示す図である。
まず、ユーザーによって電話帳１２への人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）の登録が行われるものとする。電話帳への登録が行われない場合、以下のステップＳ１とステップＳ２は実行されず、ステップＳ１とステップＳ２をパスしてそのままステップＳ３に進む。
【００６１】
電話帳１２への登録を行うとき、ユーザは、操作部１４を操作し、所定の順番に従って人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）を入力する（ステップＳ１）。このとき、人物Ａのグループとして新たなグループを作成する必要がある場合は、そのグループ作成に必要な情報についても操作部１４を用いて入力する。あるいは、人物Ａを既存のグループに割り当てる場合は、そのグループ割り当てに必要な情報についても操作部１４を用いて入力する。
【００６２】
このようにして、電話帳１２への人物Ａの電話帳データの登録とグループ割り当て（必要であれば新規グループの作成）を行うと、次に、メールボックス２０のグループ管理を行う（ステップＳ２）。メールボックス２０のグループ管理とは、先のステップＳ１で、電話帳１２に新規のグループが作成された場合に、そのグループに関連づけられた新たなグループをメールボックス２０にも作成することをいい、且つ、メールボックス２０に新たに作成されたグループに固有のアイコンを割り当てることをいう。
【００６３】
次いで、メールの受信処理を実行する（ステップＳ３）。この図では省略しているが、メールの受信処理では、無線通信部１２を経由して外部のメールサーバにアクセスし、当該メールサーバ内の自アカウント領域（ユーザ専用のサーバ内メールボックス）から受信メールを読み出すという一連の処理を実行する。この処理は定期的又は不定期に行われる。メールサーバ内の自アカウント領域に受信メールが届いていなければそのまま待機し、または他のバックグラウンド処理を実行する。受信メールが届いていれば、その受信メールを無線通信部１２を介し、中央制御部１９メール振り分け制御部２３に取り込む。
【００６４】
受信メールを取り込むと、次に、その受信メールの差出人アドレスと電話帳２１に登録されているアドレスとを照合し、登録済みのアドレスであって、且つ、電話帳２１でグルーブ分けされたアドレスであるか否かを判定する（ステップＳ４）。なお、図では、ステップＳ４の処理内容を「アドレス照合」とし、その照合結果を「照合結果Ｘ」及び「照合結果Ｙ」としているが、これは説明上の都合である。これらの「照合結果Ｘ」及び「照合結果Ｙ」は、後述の説明（図１３の説明）で引用される。また、「照合結果Ｘ」は前述の（判定２）または（判定３）に相当し、「照合結果Ｙ」は前述の（判定１）に相当する。
【００６５】
ステップＳ４の照合結果が「照合結果Ｘ」の場合、つまり、未登録のアドレスである場合、または、登録済みであるがグルーブ分けされたアドレスでない場合は、その受信メールをメールボックス２０のシステム用のグループＭＧ０に保存し（ステップＳ５）、その受信メールが未読であるか否かを判定する（ステップＳ６）。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部９の画面上に、メール受信報知用のアイコン（図６のシステム用のアイコン２５＿０参照）を表示する（ステップＳ７）。そして、ユーザによる所定の未読メール確認操作（たとえば、アイコン２５＿０へのタッチ操作）に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行し（ステップＳ８、ステップＳ９）、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理（表示部９の画面上へのメールデータ表示）を実行（ステップＳ１０）した後、フローを終了する。
【００６６】
他方、ステップＳ４の照合結果が「照合結果Ｙ」の場合、つまり、登録済みのアドレスであって、且つ、電話帳２１でグルーブ分けされたアドレスである場合は、その受信メールをメールボックス２０の該当するグループＭＧｉ（電話帳２１のグループに関連づけられたグループ）に保存し（ステップＳ１１）、その受信メールが未読であるか否かを判定する（ステップＳ１２）。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部９の画面上に、メール受信報知用のアイコン（図６のアイコン２５＿１〜２５＿ｎのいずれか）を表示する（ステップＳ１３）。そして、ユーザによる所定の未読メール確認操作（たとえば、任意のアイコンへのタッチ操作）に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行し（ステップＳ１４、ステップＳ１５）、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理（表示部９の画面上へのメールデータ表示）を実行（ステップＳ１６）した後、フローを終了する。
【００６７】
以上のとおりであるから、実施形態によれば、以下の効果を得ることができる。
まず、第１に、メールの受信という１つの種類のイベント報知を複数のアイコン（図６の例では第２〜第３のイベント報知アイコン２９〜３１）を用いて行うようにしたので、メール受信の報知を１つのイベント種類（メール受信）だけでなく、さらに、“グループ”ごとにも掘り下げて行うことができる。したがって、受信したメールの差出人が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、といった状況判断を速やかに下すことができるという優れた効果が得られる。
【００６８】
加えて、第２に、グループごとのアイコン（図６の例では第２〜第４のイベント報知アイコン２９〜３１）は、割当先のメールボックスに存在する未読メール数を表示するためのエリア２９ｂ、３０ｂ、３１ｂ（図５の第２のエリア２７＿０、２７＿１、２７＿２に相当）を有しているので、各グループの未読メール数（ｎ１、ｎ２、ｎ３）を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。
【００６９】
さらに、波及的な効果としては、目的の受信メールを確認するまでのキー操作回数を減らすことができる。これは、アイコンをタッチするだけでメール一覧を表示できるからである。さらに必要であれば、その一覧をワンタッチしてメール本文を読むことができるからであり、少なくとも２回の操作で目的の受信メールにたどりつけるからである。また、受信メールがグループごとに自動振り分けされるため、手作業によるメールの振り分け作業が必要なくなり、手間の軽減を図ることもできる。さらに、グループごとにメールを読むことができるので、優先度を付けた開封を行うことができる。
【００７０】
なお、以上の説明では、メールの受信という特定のイベントの報知について説明したが、これに限定されないことはもちろんである。たとえば、不在着信のイベント報知に応用してもよい。
【００７１】
図１０は、不在着信への応用例を示す図である。この図において、表示部９には、複数（図では３個）の不在着信報知用のアイコン（以下、第５〜第７のイベント報知アイコン３２〜３４）が表示されている。これらのアイコンも、前記のメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１参照）と同様に、電話帳２１のグループと同じグループに関連づけられたものである。たとえば、第５のイベント報知アイコン３２は、電話帳２１の友人グループＴＧ１と同じグループに関連づけられたもの、第６のイベント報知アイコン３３は、電話帳２１の仕事関連グループＴＧ２と同じグループに関連づけられたもの、第７のイベント報知アイコン３４は、電話帳２１のシステム用グループＴＧ０と同じグループに関連づけられたものである。
【００７２】
このようにしても、第１に、不在着信という１つの種類のイベント報知を複数のアイコン（図１０の例では第５〜第７のイベント報知アイコン３２〜３４）を用いて行うことができ、不在着信の報知を“グループ”ごとに掘り下げて行うことができる。したがって、不在着信の相手が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに応答すべきか、または、後で応答してもかまわないか、あるいは、放置すべきといった判断を速やかに下すことができるという優れた効果が得られる。
【００７３】
加えて、第２に、グループごとのアイコン（図１０の例では第５〜第７のイベント報知アイコン３２〜３４）は、グループごとの不在着信数を表示するためのエリア３２ａ、３３ａ、３４ａを有しているので、各グループの不在着信数ｍ１〜ｍ３を一目で知ることができ、現時点でどのグループにどれだけの不在着信があったか、あるいは、先回の確認からどのグループの未不在着信がどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。
【００７４】
以上の説明は、携帯電話機１への適用を例にしたが、ユーザに届く通知（イベント）は上記の例（メール受信や不在着信）に限らず、他にも様々なものがある。たとえば、スケジュール通知（予めユーザが設定した日時に何らかの手段でイベントが発生するもの）もその１つである。とりわけ、インターネットなどのネットワークを利用したスケジュール通知サービスは、昨今、高機能且つきめ細やかなサービスが行われており、たとえば、仕事とプライベートの区別はもちろんのこと、さらに、仕事の場合も「Ａ社用」、「Ｂ社用」、「Ｃプロジェクト用」、「Ｄプロジェクト用」などと細分化することができ、または、プライベートの場合も「家庭用」、「Ｅ趣味用」、「Ｆ趣味用」などと細分化することができる。さらに、ソーシャルネットワークサービス（ＳＮＳ）などの人対人の交流サービスにあっても同様のきめ細かなサービスが提供されている。
【００７５】
こうしたサービスを利用する場合、ユーザの端末には多くのイベントが通知されることになる。とりわけ、複数のサービスを並行利用している場合は、より多くのイベントが通知される。
【００７６】
図１１（ａ）は、イベント通知型のネットワークサービス利用概念図である。この図において、インターネット等のネットワーク３５には、複数（図では４台）のサービスサーバ（以下、単にサーバという）３６〜３９が接続されていると共に、ユーザの端末４０も接続されている。
【００７７】
端末４０のユーザは、これら４台のサーバ３６〜３９が各々提供するサービスを利用しているものとする。サービスの内容は、たとえば、前述のスケジュール通知サービスやＳＮＳなどであるが、他のサービスであってもかまわない。イベント通知型のサービスであればよい。
【００７８】
今、サーバ３６〜３９のアドレス、つまり、ネットワーク３５上の固有の識別情報（典型的にはＵＲＬ）を便宜的にそれぞれ「ａ」、「ｂ」、「ｃ」、「ｄ」とする。つまり、サーバ３６のアドレスを「ａ」、サーバ３７のアドレスを「ｂ」、サーバ３８のアドレスを「ｃ」、サーバ３９のアドレスを「ｄ」とする。
【００７９】
ユーザの端末４０は、定期的または不定期に各々のサーバ３６〜３９にアクセスし、各サーバ３６〜３９から自分宛に通知されるイベントを取り込み、そのイベント報知を端末４０の画面上に表示する。今、アドレス「ａ」のサーバ３６から４つのイベント（ｉ１〜ｉ４）が端末４０に取り込まれ、また、アドレス「ｂ」のサーバ３７からも３つのイベント（ｉ５〜ｉ７）が端末４０に取り込まれたものとする。同様に、アドレス「ｃ」のサーバ３８からも４つのイベント（ｉ８〜ｉ１１）が端末４０に取り込まれ、さらに、アドレス「ｄ」のサーバ３７からも１つのイベント（ｉ１２）が端末４０に取り込まれたものとする。
つまり、４台のサーバ３６〜３９から端末４０に合計１２個のイベント（ｉ１〜ｉ１２）が取り込まれたものとする。
【００８０】
図１１（ｂ）は、１２個のイベント（ｉ１〜ｉ１２）をグループ分けするためのアドレステーブルの構造模式図である。このアドレステーブル４１は、いくつかのグループ（図では第１〜第４の４つのグループ）ごとにサーバ３６〜３９のアドレスを振り分けている。たとえば、第１グループにアドレスの「ａ］と［ｂ」を振り分け、第２グループにアドレスの「ａ］と［ｃ」を振り分け、第３グループにアドレスの「ｂ］と［ｃ」を振り分け、第４グループにアドレスの「ｄ］を振り分けている。
【００８１】
このような振り分け例に従えば、４台のサーバ３６〜３９からの１２個のイベント（ｉ１〜ｉ１２）をアドレスに従ってグルーブごとにまとめてユーザに報知することができる。
【００８２】
図１２は、グループごとの報知例を示す図である。（ａ）は比較のために示す非グループ報知例であり、（ｂ）は前記実施形態の技術思想を適用したグループ報知例である。非グループ報知の場合、（ａ）に示すように、端末４０の画面上には１２個のイベント報知４２〜５３のすべてが表示される。端末４０の画面サイズが充分に大きければ特段の不都合を生じないものの、小さな画面サイズの場合、特にブック型や携帯型のタブレット端末などにおいては表示面積の圧迫を免れない。
【００８３】
これに対して、（ｂ）に示す例、つまり、前記実施形態の技術思想を適用したグループ報知例の場合は、各グループごとの４個のイベント報知５４〜５７が表示されているに過ぎず、（ａ）との比較で見ても、はるかに少ない表示数であるから、画面素表示面積の圧迫を招くことはない。したがって、特にブック型や携帯型のタブレット端末などのように小さな画面サイズの場合に有効である。
【００８４】
さらに、（ｂ）において、４個のイベント報知５４〜５７のそれぞれにグループ内のイベント数を表示するためのエリア５４ａ〜５７ａを設けておけば、各グループのイベント数、つまり、第１のグループのイベント数（ｉ１〜ｉ４とｉ５〜ｉ７の７個）、第２のグループのイベント数（ｉ１〜ｉ４とｉ８〜ｉ１１の８個）、第３のグループのイベント数（ｉ５〜ｉ７とｉ８〜ｉ１１の７個）、第４のグループのイベント数（ｉ１２の１個）をそれぞれのエリア５４ａ〜５７ａに表示できるので、各グループのイベントの詳細な情報も一目で知ることができ、たとえば、どのグループのイベントを先に確認すべきか、などといった状況判断を速やかに下すことができる。
【００８５】
このように、前記実施形態の技術思想は、スケジュール通知やＳＮＳなどのネットワークサービス（イベント通知型のサービス）にも応用することができる。この場合、前記実施形態の技術思想の実体はサーバ側、端末側のいずれに実装してもかまわない。
【００８６】
図１３は、端末側に実施形態の技術思想の実体を実装した場合の概念図である。この図に示すように、端末４０は、サーバ３６〜３９からのイベント（ｉ１〜ｉ１２）を取り込み、イベントを発生したサーバ３６〜３９のアドレスと、図１１のアドレステーブル４１とを照合し、どのグループに属するイベントであるかを判定する（ステップＳ２１）。次いで、端末４０はそのグループ照合結果が「照合結果Ｘ」（図９の照合結果Ｘに相当）であれば、各々のイベント（ｉ１〜ｉ１２）をグループ分けして端末４０の画面に表示する（ステップＳ２２）。このときの表示例は、図１２（ａ）である。なお、どのグルーブにも属しないと判定されたイベント（「照合結果Ｙ」図９の照合結果Ｙに相当）については、図１２（ａ）に示すようなイベント単体の表示（イベント報知４２〜５３参照）を行えばよい（ステップＳ２３）。
【００８７】
前記実施形態の技術思想の実体をサーバ側に実装する場合は、図１１のアドレステーブル４１に相当するものをサーバで保持すると共に、図１３のステップＳ２１、ステップＳ２２およびステップＳ２３に相当する処理部をサーバに実装すればよい。この場合、自サーバで発生するイベントのみをグループ化することができる。グループ化した結果を端末４０に送信すればよい。グループ化した結果を端末４０に送信する仕組みには、いわゆる「動的ホームページ」の技術を利用することができる。
【００８８】
すなわち、ホームページには、サーバから端末に送られたＨＴＭＬファイルをそのまま表示する「静的ホームページ」と、ユーザ（端末）からのリクエストに応じて（例えば入力フォームの内容に応じて）、サーバ上のプログラムがＨＴＭＬ文書を作成し、ユーザ（端末）に送り返す「動的ホームページ」の二種類あるが、この「動的ホームページ」の技術を利用すれば、サーバ上でイベントをグループ化した結果を動的ＨＴＭＬ文書の形にして端末４０に送信することができ、さらに、動的ＨＴＭＬ文書に含まれているユーザリクエスト用コントロール（ボタンやリンク情報など）の操作結果をサーバに送り返し、再び、所要の動的ＨＴＭＬ文書（たとえば、選択されたグループの詳細なイベント情報を含む文書）を生成して端末４０に送信することができる。
このように、「動的ホームページ」の技術を利用することにより、前記実施形態の技術思想の実体をサーバ側にも実装することができる。
サーバ側と端末側のいずれに実装するかは、システムの運用目的等を勘案して適切に判断すればよい。
【００８９】
本実施の形態ではメールボックスや電話帳を格納するのにメモリ１６を用いて説明したが、これに限らない。ＲＡＭ１９ｃなどの記憶装置を使用してもよい。あるいは、ＲＯＭ１９ｂが書き換え可能のもの（プログラマブル型のＲＯＭ）である場合は、そのＲＯＭ１９ｂを使用してもよい。
また、未読メール数、電話の不在着信数、イベントの未読数を例に説明したがこれに限らない。累積数だけでなく、直近のメール着信数や、直近の未読メール数、直近の電話の不在着信数や、不在着信後に電話をしてかけ直していない未応答数や直近の未応答数、直近の未読イベント数であってもよい。
また、メールアドレスや電話番号やイベントのグループを判定した際の判定基準について、照合結果Ｘの基準として未登録のものである場合、または登録済みであるがグループ分けされたものではないとして、グループ０番としてまとめて通知する説明をしたがこれに限らない。未登録のものは別のグループ扱いとしてグループ０番や他のグループとは別のグループに見えるように分けて通知してもよい。
また、未登録のものは通知しない仕組みとしてもよい。迷惑メールやワン切りなどの知らない人からの通知をしないようにしてもよい。
また、０番のグループはシステム用で、グループ番号は１からの自然数として説明したが、これに限らない。グループＡ、Ｂ、Ｃ・・・・、グループ家族、グループ仕事等、表示上は数字には限らない。内部処理として検索処理可能なユニークな記号が内部的に割り振られたグループであればよい。
また、不在着信数や未読メール数などの報知で画面に表示する際に種別アイコンに加えその数字を表示したが、画面の表示エリア、表示アイコン数、種類などの制約に応じて、全ての数字を表示しなくてもよい。例えば２桁以上の数字は＋などの記号に置き換えて１桁分の表示エリアで表示をしてもよい。
【００９０】
以下、本発明の特徴を付記する。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
図１４は、付記１の構成図である。
付記１は、少なくともイベントのグルーブ化が可能なグループ情報（１００：実施形態のメールアドレスや発信者番号、ＵＲＬなどに相当）を含むイベント情報（１０１：実施形態のメール受信、不在着信、スケジュール通知などのイベント情報に相当）を受信する受信手段（１０２：実施形態のメール振り分け制御部２３に相当）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３：実施形態のメール振り分け制御部２３に相当）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４：実施形態のメール振り分け制御部２３に相当）とを備えたことを特徴とするイベント報知装置（１０５：実施形態の携帯電話機１に相当）である。
（付記２）
付記２は、前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする付記１に記載のイベント報知装置である。
（付記３）
付記３は、前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記４）
付記４は、前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記５）
付記５は、前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記６）
図１５は、付記６の構成図である。
付記６は、少なくともイベントのグルーブ化が可能なグループ情報（１００）を含むイベント情報（１０１）を発生する発生手段（１０６：実施形態のメールサーバ３６〜３９に相当）と、前記イベント情報（１０１）を受信する受信手段（１０２）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４）とを備えたことを特徴とするイベント報知システム（１０７）である。
（付記７）
付記７は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とするイベント報知方法である。
（付記８）
付記８は、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とするプログラムである。
【符号の説明】
【００９１】
１００ グループ情報
１０１ イベント情報
１０２ 受信手段
１０３ グループ化手段
１０４ 報知手段
１０５ イベント報知装置
１０６ 発生手段
１０７ イベント報知システム
【技術分野】
【０００１】
本発明は、たとえば、メール着信や不在着信などのユーザに対する各種イベントを報知するためのイベント報知システム、イベント報知装置、イベント報知方法及びプログラムに関する。
【背景技術】
【０００２】
近年、携帯電話機などのコンピュータ応用機器の普及に伴い、当該機器のユーザ（利用者）に対して、多種多様なイベントの報知、たとえば、メール着信、不在着信、スケジュール通知などの報知が行われるようになってきた。
かかるイベントをユーザに報知するための方法（以下、旧来方法）として、古くから、ハードウェア的な報知、つまり、機器本体のスピーカから着信音を流したり、機器本体を振動させたり、機器本体のランプを点灯させたりすることが行われてきたが、この旧来方法では、イベントの種類、たとえば、メール着信や不在着信などの種類を“直感的”に判断することができず、しばしば、「この着信音はメールの受信？それとも不在着信？」などといった混乱を生じていた。
【０００３】
かかる背景から、今日におけるイベントの報知は、機器本体の画面を利用して視覚的に行われる方法が主流になっている。すなわち、画面上に、メール着信や不在着信などの各種イベントを示す個別のオブジェクトを表示することが行われている。イベント報知に用いられるオブジェクトの典型はアイコンである。アイコンのデザインを変えてイベントの種類を表現する。たとえば、封筒の絵をデザインしたアイコンはメール着信を直感的に表現し、あるいは、電話機の絵をデザインしたアイコンは不在着信を直感的に表現する。したがって、ユーザは、それらの絵を見るだけで、イベントの種類、つまり、メール着信であるのか、不在着信であるのか、などを直感的に把握することができ、前記の混乱を生じない。
【０００４】
このように、イベントの“種類”については、一応のところ、すでに直感的に把握できる技術が確立している。
【０００５】
しかしながら、同じ種類のイベント報知であっても、その内容はますます複雑化する傾向にあり、単にイベントの種類ごとのオブジェクト（アイコン等）を表示しただけでは、複雑化の傾向に対応しきれなくなってきている。たとえば、メールを例にして説明すると、メールの受信数は受信者の属性（年齢性別や職種／学生など）にかかわらず、ますます増加しつつあり、大量のメールを読んだり、削除したりする際に多くの労力を要するようになってきている。このことは、不在着信についても同様である。知人（家族、友人、仕事仲間など）からの着信だけでなく、見知らぬ第三者や一時的な相手（たとえば、予約したレストラン）からの着信などもしばしばあり、それらの相手ごとの応答可否を決めるのが面倒になってきている。また、スケジュール通知も、私的なものから公的なものまで幅広く、ますます管理が面倒になってきている。
【０００６】
この点に関し、下記の特許文献１の段落〔００２９〕中頃に「受信グループ１・４１３には電話帳のグループ１・４０３の登録者からのメールが保存される。」と記載されていることから、同文献には、電話帳のグループに対応した個別のメールボックスを作り、それらのメールボックスに受信メールを分類して保存する技術（以下、第１の関連技術という）が開示されていると認められる。
また、下記の特許文献２の段落〔０１１５〕に「アドレス帳において、各人物のグループが設定されている。」と記載されており、さらに、同文献の段落〔０１１７〕に「イメージ画面が表示されたときに、表示された人物画像を接触操作すると、・・・・当該接触操作された人物画像と同じグループに設定された人物の人物画像が表示されるようになっている。」と記載されていることから、同文献には、グループごとに分類されたアイコン（人物画像）を表示する技術（以下、第２の関連技術という）が開示されていると認められる。
【０００７】
要するに、関連技術１は電話帳の情報を利用し、グループごとにメールを仕分けして整理分類する技術であり、また、関連技術２はグループ内の情報をアイコンで整理分類する技術であるといえるから、これらの技術を利用することにより、大量のメールを読んだり、削除したりする際の手間を軽減することが可能になる。これは、グループ単位にメールを読んだり、削除したりできるからである。この考え方（グループ単位の仕分け）は、不在着信やスケジュール通知にも応用することができる。いずれも、グループ単位に応答可否を判断したり、スケジュール管理をしたりできるからである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−０２０６８４号公報
【特許文献２】特開２００８−１４１５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、関連技術１、２には、イベントの一種でもあるメールの着信をどのようにユーザに“報知”するかの点について一切の言及（開示）がない。このため、一般的なイベントの報知方法を採用しているものと推測せざるを得ない。たとえば、冒頭で説明したアイコンによる報知を採用していると推測すると、この方法では、ユーザは単にイベントの種類、つまり、メールの着信を知ることができるだけである。
一方、先にも言及したとおり、メールの受信数がますます増加する傾向にあることから、１度のメールチェックで、ときによっては、様々な相手から数十通あるいはそれ以上のメールが届くことがある。このようなことを想定して、一般的に、アイコンと一緒にメール受信数を表示することもよく行われている。つまり、アイコンのデザインでイベントの種類（メールの受信）を表すと共に、その種類におけるイベント数（メールの受信数）をアイコンと一緒に同時表示するという対策である。
しかし、このような対策を講じても、同一種類のイベントが大量に発生した際の混乱を避けられない。たとえば、メールであれば、大量のメールの中に読むべきメールが埋没してしまうからである。
【００１０】
本発明の目的は、イベントの報知をグループごとにまとめて行うことにより、同じ種類の大量のイベントが報知された場合の混乱回避を図ることにある。
【課題を解決するための手段】
【００１１】
本発明のイベント報知装置は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。
本発明のイベント報知システムは、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、前記イベント情報を受信する受信手段と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、前記グループ化された単位でユーザにイベントを報知する報知手段とを備えたことを特徴とする。
本発明のイベント報知方法は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とする。
本発明のプログラムは、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、イベントの報知をグループごとにまとめて行うようにしたので、グループごとにイベント状況を把握でき、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】携帯電話機１の外観図である。
【図２】携帯電話機１の構成図である。
【図３】携帯電話機１の主要部構成図である。
【図４】メールボックス２０と電話帳２１の構造模式図である。
【図５】アイコン保持テーブル２４を示す図である。
【図６】アイコンの表示例を示す図である。
【図７】電話帳２１の構造模式図である。
【図８】メールボックス２０の構造模式図である。
【図９】携帯電話機１の動作フローを示す図である。
【図１０】不在着信への応用例を示す図である。
【図１１】イベント通知型のネットワークサービス利用概念図（ａ）及びアドレステーブルの構造模式図（ｂ）である。
【図１２】グループごとの報知例を示す図である。
【図１３】端末側に実施形態の技術思想の実体を実装した場合の概念図である。
【図１４】付記１の構成図である。
【図１５】付記６の構成図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態を、携帯電話機への適用を例にして、図面を参照しながら説明する。
まず、実施形態の構成を説明する。
図１は、携帯電話機１の外観図である。図において、携帯電話機１は、特にそれに限定されないが、手持ちに適した厚みと大きさを有する縦長箱型形状の本体部２と、その本体部２の一短辺端側にヒンジ機構３を介して連結された、本体部２と略同型状かつ薄厚の蓋部４とを備えた、いわゆる「折り畳み式」の筐体５を有している。なお、この「折り畳み式」は一例に過ぎない。折り畳み式以外のもの（非折り畳み式やスライド式またはフリップ式など）であっても当然かまわない。また、この携帯電話機１は、本体部２に多数のハードウェアキーからなる操作部（後述の操作部１４）を備えているが、この操作部を具備せず、その代わりに表示部（後述の表示部９）の画面上にソフトウェアキーを表示するタイプのものであってもよい。この場合、「折り畳み式」である必然性はない。いわゆるタブレット型（平板型）の筐体形状であってもよい。このようなタブレット型の携帯電話機は一般的にスマートフォンと呼ばれている。
【００１５】
本体部２の一方面（蓋部４との対向面）には、多数のハードウェアキー（以下、操作ボタン）からなる操作ボタン群６や、後述のマイク１３ａが収められた送話孔７が設けられ、また、蓋部４の一方面（本体部２との対向面）には、前面にタッチパネル８が貼り付けられた表示部９や、後述のスピーカ１３ｂが収められた受話孔１０、及び、この表示部９を見ている人物の顔を撮影することができる撮像部１１が設けられている。
【００１６】
図２は、携帯電話機１の構成図である。携帯電話機１は、無線通信部１２、音声処理部１３、撮像部１１、操作部１４、タッチパネル８付の表示部９、メモリＩ／Ｆ（インターフェース）１５、メモリ１６、外部Ｉ／Ｆ１７、電源部１８、及び、中央制御部１９を備える。
【００１７】
無線通信部１２は、中央制御部１９からの制御により、アンテナ１２ａを介して最寄りの携帯電話基地局（図示略）との間で所定周波数帯域及び所定変調方式の無線によるデジタルデータの送受信を行う。このデジタルデータには、電話の着呼や発呼の情報および音声通話の情報が含まれるほか、電子メールの送受信情報や、各種インターネットコンテンツの閲覧情報ならびに任意のネットワークサービスのサービス情報などが含まれる。
【００１８】
音声処理部１３は、中央制御部１９からの制御により、マイク１３ａで拾った音声信号をデジタルデータに変換して中央制御部１９に出力したり、中央制御部１９から出力されたデジタルの音声信号をアナログ信号に変換してスピーカ１３ｂから拡声したりする。
【００１９】
撮像部１１は、二次元撮像デバイス、たとえば、ＣＣＤ型やＣＭＯＳ型などの二次元半導体撮像デバイスで構成され、中央制御部１９からの制御を受けて所定画角（撮影範囲）の画像を所定の周期で周期的に撮像し、その画像信号を中央制御部１９に出力する。
【００２０】
操作部１４は、ユーザインターフェース用の入力手段であり、たとえば、電話番号入力と文字入力の兼用ボタンや、各種の機能ボタン及びカーソル操作キーなどのボタン群（図１の操作ボタン群６）を備え、ユーザ操作に応答して、それらのボタンやキーに対応した入力信号を発生して中央制御部１９に出力する。
【００２１】
表示部９は、液晶パネルなどの平面二次元表示デバイス（好ましくは多色表示が可能で高精細な表示画面を持つもの）からなり、中央制御部１９から適宜に出力される任意の情報を可視化して画面上に表示する。好ましくは、表示部９はタッチパネル８付きのものである。このタッチパネル８は、たとえば、人体の一部（指先等）や静電ペンなどの接触を検知して、その検知信号を中央制御部１９に出力する静電容量方式のものであってもよく、または、ペン先等の堅い物質の接触を検知して、同様にその検知信号を中央制御部１９に出力する抵抗膜方式のものであってもよく、あるいは、その他の方式のものであってもよい。タッチパネル９も、ユーザインターフェース用の入力手段として機能し、操作部１４の一部を構成する。
【００２２】
メモリＩ／Ｆ１５は、たとえば、メモリ１６の規格（ＳＤカード等）に対応した汎用インターフェースであり、中央制御部１９とメモリ１６との間に位置して相互のデータのやりとりを仲介する。
【００２３】
メモリ１６は、不揮発性且つ書き換え可能な情報記憶要素であり、たとえば、ＳＤカード等のフラッシュメモリやシリコンディスクあるいはハードディスクなどを用いることができる。このメモリ１６は、様々なユーザデータ、たとえば、撮像部１１で撮像された画像ファイルや、後述する電話帳（図３の電話帳２１参照）およびメールボックス（図３のメールボックス２０参照）などのデータを記憶保存する。
【００２４】
外部Ｉ／Ｆ１７は、パーソナルコンピュータなどの外部機器とのデータインターフェースである。外部機器は、この外部Ｉ／Ｆ１７と中央制御部１９とを介してメモリ１６にアクセスすることが可能であり、メモリ１６に記憶されているユーザデータを外部機器に取り出したり、あるいは、外部機器からメモリ１６に書き戻したりすることができる。
【００２５】
電源部１８は、一次電池または充電可能な二次電池からなるバッテリを含み、このバッテリの電力から携帯電話機１の動作に必要な各種電源電圧を発生して各部に供給する。
【００２６】
中央制御部１９は、コンピュータまたはマイクロコンピュータ（以下、ＣＰＵ）１９ａ、読み出し専用半導体メモリ（以下、ＲＯＭ）１９ｂおよび高速半導体メモリ（以下、ＲＡＭ）１９ｃならびに不図示の周辺回路を含むプログラム制御方式の制御要素であり、あらかじめＲＯＭ１９ｂに格納されている制御プログラムをＲＡＭ１９ｃにロードしてＣＰＵ１９ａで実行することにより、各種の処理を逐次に実行して、この携帯電話機１の全体動作を統括制御する。なお、ＲＯＭ１９ｂは、書き込み型の不揮発性半導体メモリ（ＰＲＯＭやＥＰＲＯＭなど）であってもよい。
【００２７】
図３は、携帯電話機１の主要部構成図である。この主要部構成図には、携帯電話機１を構成する前記各部のうちの表示部９と、操作部１４と、メモリ１６と、中央制御部１９とが抜粋して示されており、さらに、メモリ１６の内部に新たにメールボックス２０と電話帳２１が、また、中央制御部１９の内部に新たにキー操作制御部２２とメール振り分け制御部２３が示されている。
【００２８】
これら主要部のうち表示部９、操作部１４、メモリ１６および中央制御部１９は、図２に示されている同符号部と同じものであるが、メールボックス２０と電話帳２１は、メモリ１６の内部に確保された２つの個別記憶領域を模式化して表したものである。すなわち、メモリ１６の記憶空間は、少なくともメールボックス２０として用いられる一の記憶領域と、電話帳２１として用いられる二の記憶領域とに分けられており、さらに、必要に応じて他の用途の記憶領域（たとえば、画像ファイル保存用の領域等）にも分けられている。
【００２９】
また、キー操作制御部２２とメール振り分け制御部２３はソフトウェア的に実現される機能である。すなわち、キー操作制御部２２とメール振り分け制御部２３は、携帯電話機１のハードウェアリソース（ＣＰＵ１９ａなどの物理的要素）とソフトウェアリソース（ＣＰＵ１９ａで実行される制御プログラム）との有機的結合によってソフトウェア的に実現される機能であり、実体が存在しない非物理的機能である。
【００３０】
図４は、メールボックス２０と電話帳２１の構造模式図である。この図において、電話帳２１は複数のグループに分けられている。各グループを符号ＴＧ０、ＴＧ１、ＴＧ２、・・・・、ＴＧｎで表すことにする。“Ｔ”は電話、“Ｇ”はグループ、末尾の“０”〜“ｎ”はグループ番号を表している。たとえば、ＴＧ１は電話用の１番目のグループであることを示す。グループ番号は“０”から“ｎ”までであり、したがって、グループ数はｎ＋１個である。
“０”を除く“１”から“ｎ”までのグループ（ＴＧ１〜ＴＧｎ）はユーザに開放された（ユーザが自由に使用できる）自由グループである。これらの自由グループは、たとえば、友人、仕事、その他の用途などに自由に用いられる。以下、自由グループのうちの１つのグループを示す場合にＴＧｉと表記することもある。“ｉ”は“１”〜“ｎ”のいずれかである。
【００３１】
０番のグループ（ＴＧ０）はシステム用である。ユーザが登録した電話帳データは、システムによって、まず、このＴＧ０に保存される。しかる後、ユーザによって任意のグループへの振り分けが行われると、たとえば、ＴＧｉへの振り分けが行われると、ＴＧ０に保存されていた電話帳データが振り分け先のＴＧｉに移動する。なお、移動でなくコピーでもよい。
【００３２】
ここまでをまとめると、電話帳２１のＴＧ０はシステム用のグループ、ＴＧｉ（＝ＴＧ１〜ＴＧｎ）はユーザに開放された自由グループである。ユーザは、ＴＧ０に保存された電話帳データを任意のグループＴＧｉに振り分け保存することができる。たとえば、ＴＧ１を友人用、ＴＧ２を仕事用とすると、ＴＧ０に保存された友人の電話帳データをＴＧ１に保存したり、同じくＴＧ０に保存された仕事関係者の電話帳データをＴＧ２に保存したりすることができる。
【００３３】
一方、メールボックス２０も電話帳２１と同様に複数のグループに分けられている。各グループを符号ＭＧ０、ＭＧ１、ＭＧ２、・・・・、ＭＧｎで表すことにする。“Ｍ”はメール、“Ｇ”はグループ、末尾の“０”〜“ｎ”はグループ番号を表している。たとえば、ＭＧ１はメール用の１番目のグループであることを示す。ここで、グループ番号は“０”から“ｎ”までであり、したがって、グループ数は電話帳２１と同じｎ＋１個である。
“０”を除く“１”から“ｎ”までのグループ（ＭＧ１〜ＭＧｎ）はユーザに開放された（ユーザが自由に使用できる）自由グループである。以下、自由グループのうちの１つのグループを示す場合にＭＧｉと表記することもある。“ｉ”は“１”〜“ｎ”のいずれかである。
ＭＧｉ（＝ＭＧ１〜ＭＧｎ）の用途は、電話帳２１の自由グループＴＧｉ（＝ＴＧ１〜ＴＧｎ）と同じである。たとえば、電話帳２１のＴＧ１を友人用、ＴＧ２を仕事用、ＴＧ３をその他用とすると、このメールボックス２０のＭＧ１も友人用、ＭＧ２も仕事用、ＭＧ３もその他用になる。
つまり、ＴＧ１−ＭＧ１、ＴＧ２−ＭＧ２、ＴＧ３−ＭＧ３、・・・・、ＴＧｎ−ＭＧｎというように互いに関連付けされている。ユーザによる用途の割り当ては電話帳２１が先である。たとえば、電話帳２１のＴＧ１を友人用に割り当てると、この割り当てに同期してメールボックス２０のＭＧ１も友人用になる。
【００３４】
ＭＧｉへのメールデータの振り分けは、メールヘツダ情報に含まれる差出人メールアドレス（以下、単にアドレスという）と電話帳２１に保存されている電話帳データとの照合に基づいて行われる。これは、一般的に電話帳２１に登録される電話帳データには名前や電話番号のほかに、アドレスなどの付加情報も含まれているからであり、このアドレスに基づいてメールデータのグループ振り分けを行うことができるからである。
たとえば、電話帳２１に友人Ａのアドレスを含む電話帳データが登録されているものとし、且つ、その友人Ａの電話帳データがＴＧ１（友人用）に保存されているものとすると、この場合、友人Ａからのメールデータは、アドレス照合によってメールボックス２０のＭＧ１（友人用）に振り分け保存される。
【００３５】
電話帳２１と同様に、メールボックス２１の０番のグループ（ＭＧ０）もシステム用である。このシステム用グループＭＧ０には、アドレス照合の結果、グループ分けされていないことが判明した差出人、または、電話帳２１に登録されていない差出人からのメールデータが保存される。
【００３６】
図５は、アイコン保持テーブル２４を示す図である。このアイコン保持テーブル２４は、メールボックス２０の全てのグループＭＧ０〜ＭＧｎを個別に視覚的識別可能なｎ＋１個のアイコン２５＿０〜２５＿ｎの実体を保持する。または、別の場所に保存されたｎ＋１個のアイコン２５＿０〜２５＿ｎへのリンク情報を保持する。アイコン保持テーブル２４は、さらに、それぞれのアイコン２５＿０〜２５＿ｎがどのグループに割り当てられているかを示す割り当て情報（図ではグループ名と同じＭＧ０〜ＭＧｎ）を保持する。
なお、このアイコン保持テーブル２４は、メール以外の他のイベント報知用のアイコン、たとえば、不在着信用のアイコン（図６の第１のイベント報知アイコン２８参照）などを保持していてもよい。
【００３７】
各々のアイコン２５＿０〜２５＿ｎは、任意の大きさ、任意の形状、且つ、任意のデザインの背景上に、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では封筒の絵としている）などを表示するための第１のエリア２６＿０〜２６＿ｎと、割当先のメールボックスに存在する未読メール数を表示するための第２のエリア２７＿０〜２７＿ｎとを設けている。
【００３８】
図６は、アイコンの表示例を示す図である。この図において、表示部９には、数は一例であるが、４個のイベント報知アイコンが表示されている。第１のイベント報知アイコン２８は不在着信報知用であり、この第１のイベント報知アイコン２８には、不在着信であることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では携帯電話機の絵としている）などを表示するための第１のエリア２８ａと、不在着信数ｍを表示するための第２のエリア２８ｂとが設けられている。
【００３９】
第２〜第４のイベント報知アイコン２９〜３１はメール受信報知用であり、これらの第２〜第４のイベント報知アイコン２９〜３１には、先のアイコン保持テーブル２４（図５参照）に保持されているｎ＋１個のアイコン２５＿０〜２５＿ｎが選択的に用いられる。たとえば、第２のイベント報知アイコン２９にＭＧ１用のアイコン２５＿１が用いられ、また、第３のイベント報知アイコン３０にＭＧ２用のアイコン２５＿２が用いられ、さらに、第４のイベント報知アイコン３１にＭＧ０用のアイコン２５＿０が用いられという具合である。
【００４０】
いずれのアイコンが用いられるかは、もっぱら着信メールの保存先グループによって決まる。たとえば、上記の例示は、友人用のグループＭＧ１と仕事用のグループＭ２とシステム用のグループＭＧ０の各々に受信メールが保存された場合である。
【００４１】
つまり、この場合、第２のイベント報知アイコン２９は「友人用」のメール受信を報知し、第３のイベント報知アイコン３０は「仕事用」のメール受信を報知し、第４のイベント報知アイコン３１は、グループ分けされていない差出人からのメール受信、または、電話帳２１に登録されていない差出人からのメール受信を報知することになる。
【００４２】
ここで、実施形態にとって重要なポイントは、第１に、メールの受信という１つの種類のイベント報知を複数のアイコン（図示の例では第２〜第３のイベント報知アイコン２９〜３１）を用いて行う点にある。これら複数のアイコンは、上記のとおり、電話帳２１と同じようにグループ分けされたものであるから、結局のところ、メール受信の報知をグループごとに行うことができる。したがって、大量のメール受信があった場合、つまり、同じ種類の大量のイベントが報知された場合の混乱回避を図ることができ、さらに、受信したメールの差出人が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、などといった状況判断を速やかに下すことができるという効果が得られる。
【００４３】
この効果は、第１のイベント報知アイコン２８（不在着信報知用）との対比からも明らかである。すなわち、第１のイベント報知アイコン２８は、不在着信であることを明示するための可視情報を表示する第１のエリア２８ａと、不在着信数ｍを表示するための第２のエリア２８ｂとが設けられおり、その不在着信数ｍは、携帯電話機１に着信した“全て”の不在着信の数を示している。したがって、この不在着信数ｍを見ただけでは、その不在着信の中にすぐに応答しなければならないものがどれだけあるのかを即座に知ることができない。一般的には不在着信リストを開き、そのリストの発信者名や電話番号を見て応答可否を判断することになるが、操作の手間を否めない。
【００４４】
実施形態のメール受信報知は、グループごとのアイコン（図示の例では第２〜第４のイベント報知アイコン２９〜３１）を用いているので、何らの操作も必要とせずに、少なくとも、どのグループのメール受信であるのかを一目で知ることができ、その場でのメール開封、または、後での開封、もしくは、開封せずに無視する、といった状況判断を速やかに行うことができる。
【００４５】
加えて、第２に、実施形態のグループごとのアイコン（図示の例では第２〜第４のイベント報知アイコン２９〜３１）は、メールであることを明示するための可視情報、たとえば、絵または図形もしくは文字列（図では封筒の絵としている）などを表示するためのエリア２９ａ、３０ａ、３１ａ（図５の第１のエリア２６＿０〜２６＿ｎに相当）を有すると共に、割当先のメールボックスに存在する未読メール数を表示するためのエリア２９ｂ、３０ｂ、３１ｂ（図５の第２のエリア２７＿０、２７＿１、２７＿２に相当）を有しているので、各グループの未読メール数（便宜的にｎ１、ｎ２、ｎ３）を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという効果も得られる。
【００４６】
なお、以上の説明では、イベントの“報知”としているが、この言葉（報知）に限定されない。“通知”でもよい。要するに、ユーザにイベントを「知らせる」ことができればよい。
【００４７】
図７は、電話帳２１の構造模式図である。この図において、電話帳２１を構成する各グループ（全てのグルーブは同じ構造であり、ここではＴＧ１を例にする）は、一連番号（００１、００２、００３、・・・・）が付された複数のレコードのそれぞれに、各人の電話帳データとして少なくとも名前や電話番号などを保持すると共に、さらに、アドレスなどの付加情報も保持する。
【００４８】
図８は、メールボックス２０の構造模式図である。この図において、メールボックス２０を構成する各グループ（全てのグルーブは同じ構造であり、ここではＭＧ１を例にする）は、一連番号（００１、００２、００３、・・・・）が付された複数のレコードのそれぞれに、各メールのデータとして少なくとも未読や既読の状態、受信日時、差出人のアドレス、メールのタイトルおよびメールの本文などを保持する。
【００４９】
ここで、メールボックス２０の各レコードに保持されているアドレスと、先の電話帳２１の各レコードに保持されているアドレスとが一致している点に留意されたい。これは、たとえば、電話帳２１のグループＴＧ１を「友人用」としたとき、そのグループＴＧ１に登録されている友人（“太郎”、“山田”、“花子”、“田中”、“木村”、“坂本”）からのメールが、アドレス照合によって、メールボックス２０の同用途（友人用）のグループＭＧ１に保存されたことを示している。
【００５０】
次に、実施形態の作用を説明する。
始めに、先の図３を参照しながら、携帯電話機１の内部における信号の流れを説明する。
＜電話帳２１へのデータ登録＞
ユーザーが操作部１４を用いて任意の人物（以下、人物Ａとする）の電話帳データ（名前、電話番号、アドレス、・・・・）の登録作業を行うと、この作業に応答して操作部１４から中央制御部１９のキー操作制御部２２にキー信号が出力される。キー操作制御部２２は、キー信号を解読し、所定の形式の登録信号（名前、電話番号、アドレス、・・・・の情報を含む信号）に変換し、その登録信号をメモリ１６の電話帳２１に書き込む。これにより、電話帳２１に人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）が登録される。
【００５１】
＜グループ分け＞
次いで、必要であれば、ユーザは、操作部１４を用いて人物Ａのグループ割り当て（たとえば、友人グループＴＧ１への割り当て）を行う。このとき、すでに当該グループＴＧ１が電話帳２１に存在していれば、キー操作制御部２２は、そのグループＴＧ１への人物Ａの電話帳データの移動又はコピー行う。一方、当該グループＴＧ１が電話帳２１に存在していなかった場合、キー操作制御部２２は、メモリ１６の電話帳２１に友人用の新たなグループＴＧ１を作成すると同時に、メモリ１６のメールボックス２０に対してグループ作成信号を出力し、メールボックス２０に同じ友人用のグループＭＧ１を作成する。このとき、メールボックス２０に作成されたグループＭＧ１に対して、専用のアイコン（図５のアイコン２５＿１参照）が割り当てられる。
【００５２】
このようにして、電話帳２１への電話帳データ登録とグループ分けが行われると共に、メールボックス２０のグループ分けも行われ、さらに、メールボックス２０のグループにそれぞれ固有のアイコンが割り当てられ、且つ、電話帳２１のグループとメールボックス２０のグループとの関連付けも行われる。
【００５３】
＜メール受信と報知＞
次に、メール受信時には、まず、無線通信部１２（図２参照）で受信したメールが中央制御部１９のメール振り分け制御部２３に取り込まれる。メール振り分け制御部２３は、受信メールのアドレスと、電話帳２１に登録されているアドレスとを照合し、（判定１）どのグループに登録されているアドレス（ＴＧ１〜ＴＧｎのいずれかに登録されているアドレス）であるか、または、（判定２）グループ分けされていないアドレス（ＴＧ０のみに登録されているアドレス）であるか、もしくは、（判定３）未登録のアドレス（ＴＧ０〜ＴＧｎのいずれにも登録されていないアドレス）であるかを判定し、それらの判定結果に従って、以下の動作を実行する。
【００５４】
（判定１）の場合：
メール振り分け制御部２３は、メールボックス２０にグループＭＧ１〜ＭＧｎのいずれかを指定する振り分け信号を出力し、メールボックス２０の該当するグループ（ＭＧ１〜ＭＧｎのいずれか）に受信メールを振り分け保存する。
（判定２）及び（判定３）の場合：
メール振り分け制御部２３は、メールボックス２０にシステム用のグループＭＧ０を指定する振り分け信号を出力し、メールボックス２０のシステム用のグループＭＧ０に受信メールを保存する。
【００５５】
このようにして、メール振り分け制御部２３からの振り分け信号に応答し、メールボックス２０の該当するグループ（ＭＧ０〜ＭＧｎ）に受信メールが保存される。
【００５６】
このとき同時に、中央制御部１９のメール振り分け制御部２３は、表示部９に対してメール受信報知用のアイコンを表示するための表示信号を出力し、これにより、表示部９の画面上に当該アイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）が表示され、メールを受信した旨の報知（メール受信イベントの報知）がユーザに対して行われる。
【００５７】
ユーザは、そのメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）を確認し、どのグループに何通の未読メールがあるのかを速やかに知ることができる。
【００５８】
＜メールの確認＞
そして、任意グループのメール一覧を知りたい場合には、所定の操作を行って当該グループのメール一覧画面を開き、差出人やタイトルなどを確認した上で、読みたいメールがあれば、その一覧から対象のメールを選択して開封するようにしてもよい。メール振り分け制御部２３は、所要の開封信号をメールボックス２０に対して出力し、メールボックス２０から該当するメールを読み出すとともに、そのメールを表示するための表示信号を表示部９に出力し、表示部９の画面上に対象メールを可視化して表示する。
【００５９】
メール一覧画面の開き方については特に限定しないが、近年の直感的なプログラム設計手法に従えば、各グループごとのメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１を参照）を選択したときに、対象グループのメール一覧画面を開くようにしておくことが好ましい。アイコンをタッチするだけで速やかに一覧画面を開くことができる。また、一覧画面から任意のメールを開封する際にも同様な直感的な設計手法を採用することが好ましい。たとえば、リストボックスと呼ばれるプログラム部品を用いてメール一覧を表示するようにすれば、そのリストボックスの任意行の選択操作に応答してワンタッチで対象メールを開封することができる。
【００６０】
次に、以上の動作をソフトウェア的に説明する。
図９は、携帯電話機１の動作フローを示す図である。
まず、ユーザーによって電話帳１２への人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）の登録が行われるものとする。電話帳への登録が行われない場合、以下のステップＳ１とステップＳ２は実行されず、ステップＳ１とステップＳ２をパスしてそのままステップＳ３に進む。
【００６１】
電話帳１２への登録を行うとき、ユーザは、操作部１４を操作し、所定の順番に従って人物Ａの電話帳データ（名前、電話番号、アドレス、・・・・）を入力する（ステップＳ１）。このとき、人物Ａのグループとして新たなグループを作成する必要がある場合は、そのグループ作成に必要な情報についても操作部１４を用いて入力する。あるいは、人物Ａを既存のグループに割り当てる場合は、そのグループ割り当てに必要な情報についても操作部１４を用いて入力する。
【００６２】
このようにして、電話帳１２への人物Ａの電話帳データの登録とグループ割り当て（必要であれば新規グループの作成）を行うと、次に、メールボックス２０のグループ管理を行う（ステップＳ２）。メールボックス２０のグループ管理とは、先のステップＳ１で、電話帳１２に新規のグループが作成された場合に、そのグループに関連づけられた新たなグループをメールボックス２０にも作成することをいい、且つ、メールボックス２０に新たに作成されたグループに固有のアイコンを割り当てることをいう。
【００６３】
次いで、メールの受信処理を実行する（ステップＳ３）。この図では省略しているが、メールの受信処理では、無線通信部１２を経由して外部のメールサーバにアクセスし、当該メールサーバ内の自アカウント領域（ユーザ専用のサーバ内メールボックス）から受信メールを読み出すという一連の処理を実行する。この処理は定期的又は不定期に行われる。メールサーバ内の自アカウント領域に受信メールが届いていなければそのまま待機し、または他のバックグラウンド処理を実行する。受信メールが届いていれば、その受信メールを無線通信部１２を介し、中央制御部１９メール振り分け制御部２３に取り込む。
【００６４】
受信メールを取り込むと、次に、その受信メールの差出人アドレスと電話帳２１に登録されているアドレスとを照合し、登録済みのアドレスであって、且つ、電話帳２１でグルーブ分けされたアドレスであるか否かを判定する（ステップＳ４）。なお、図では、ステップＳ４の処理内容を「アドレス照合」とし、その照合結果を「照合結果Ｘ」及び「照合結果Ｙ」としているが、これは説明上の都合である。これらの「照合結果Ｘ」及び「照合結果Ｙ」は、後述の説明（図１３の説明）で引用される。また、「照合結果Ｘ」は前述の（判定２）または（判定３）に相当し、「照合結果Ｙ」は前述の（判定１）に相当する。
【００６５】
ステップＳ４の照合結果が「照合結果Ｘ」の場合、つまり、未登録のアドレスである場合、または、登録済みであるがグルーブ分けされたアドレスでない場合は、その受信メールをメールボックス２０のシステム用のグループＭＧ０に保存し（ステップＳ５）、その受信メールが未読であるか否かを判定する（ステップＳ６）。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部９の画面上に、メール受信報知用のアイコン（図６のシステム用のアイコン２５＿０参照）を表示する（ステップＳ７）。そして、ユーザによる所定の未読メール確認操作（たとえば、アイコン２５＿０へのタッチ操作）に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行し（ステップＳ８、ステップＳ９）、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理（表示部９の画面上へのメールデータ表示）を実行（ステップＳ１０）した後、フローを終了する。
【００６６】
他方、ステップＳ４の照合結果が「照合結果Ｙ」の場合、つまり、登録済みのアドレスであって、且つ、電話帳２１でグルーブ分けされたアドレスである場合は、その受信メールをメールボックス２０の該当するグループＭＧｉ（電話帳２１のグループに関連づけられたグループ）に保存し（ステップＳ１１）、その受信メールが未読であるか否かを判定する（ステップＳ１２）。未読メールでない場合、すなわち、その受信メールが既読メールであれば、そのままフローを終了し、一方、未読メールであれば、次に、表示部９の画面上に、メール受信報知用のアイコン（図６のアイコン２５＿１〜２５＿ｎのいずれか）を表示する（ステップＳ１３）。そして、ユーザによる所定の未読メール確認操作（たとえば、任意のアイコンへのタッチ操作）に応答して未読メールの一覧画面を開くなどの未読メール確認処理を実行し（ステップＳ１４、ステップＳ１５）、その未読メール一覧画面に対するユーザ操作に応答して対象となる未読メールの開封処理（表示部９の画面上へのメールデータ表示）を実行（ステップＳ１６）した後、フローを終了する。
【００６７】
以上のとおりであるから、実施形態によれば、以下の効果を得ることができる。
まず、第１に、メールの受信という１つの種類のイベント報知を複数のアイコン（図６の例では第２〜第３のイベント報知アイコン２９〜３１）を用いて行うようにしたので、メール受信の報知を１つのイベント種類（メール受信）だけでなく、さらに、“グループ”ごとにも掘り下げて行うことができる。したがって、受信したメールの差出人が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに読むべきか、または、後で読んでもかまわないか、といった状況判断を速やかに下すことができるという優れた効果が得られる。
【００６８】
加えて、第２に、グループごとのアイコン（図６の例では第２〜第４のイベント報知アイコン２９〜３１）は、割当先のメールボックスに存在する未読メール数を表示するためのエリア２９ｂ、３０ｂ、３１ｂ（図５の第２のエリア２７＿０、２７＿１、２７＿２に相当）を有しているので、各グループの未読メール数（ｎ１、ｎ２、ｎ３）を一目で知ることができ、現時点でどのグループに何通の未読メールが届いているのか、あるいは、先回の確認からどのグループの未読メールがどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。
【００６９】
さらに、波及的な効果としては、目的の受信メールを確認するまでのキー操作回数を減らすことができる。これは、アイコンをタッチするだけでメール一覧を表示できるからである。さらに必要であれば、その一覧をワンタッチしてメール本文を読むことができるからであり、少なくとも２回の操作で目的の受信メールにたどりつけるからである。また、受信メールがグループごとに自動振り分けされるため、手作業によるメールの振り分け作業が必要なくなり、手間の軽減を図ることもできる。さらに、グループごとにメールを読むことができるので、優先度を付けた開封を行うことができる。
【００７０】
なお、以上の説明では、メールの受信という特定のイベントの報知について説明したが、これに限定されないことはもちろんである。たとえば、不在着信のイベント報知に応用してもよい。
【００７１】
図１０は、不在着信への応用例を示す図である。この図において、表示部９には、複数（図では３個）の不在着信報知用のアイコン（以下、第５〜第７のイベント報知アイコン３２〜３４）が表示されている。これらのアイコンも、前記のメール受信報知用のアイコン（図６の第２〜第４のイベント報知アイコン２９〜３１参照）と同様に、電話帳２１のグループと同じグループに関連づけられたものである。たとえば、第５のイベント報知アイコン３２は、電話帳２１の友人グループＴＧ１と同じグループに関連づけられたもの、第６のイベント報知アイコン３３は、電話帳２１の仕事関連グループＴＧ２と同じグループに関連づけられたもの、第７のイベント報知アイコン３４は、電話帳２１のシステム用グループＴＧ０と同じグループに関連づけられたものである。
【００７２】
このようにしても、第１に、不在着信という１つの種類のイベント報知を複数のアイコン（図１０の例では第５〜第７のイベント報知アイコン３２〜３４）を用いて行うことができ、不在着信の報知を“グループ”ごとに掘り下げて行うことができる。したがって、不在着信の相手が「友人」や「仕事」などのいずれのグループに属しているかを一目で知ることができ、グループ単位にすぐに応答すべきか、または、後で応答してもかまわないか、あるいは、放置すべきといった判断を速やかに下すことができるという優れた効果が得られる。
【００７３】
加えて、第２に、グループごとのアイコン（図１０の例では第５〜第７のイベント報知アイコン３２〜３４）は、グループごとの不在着信数を表示するためのエリア３２ａ、３３ａ、３４ａを有しているので、各グループの不在着信数ｍ１〜ｍ３を一目で知ることができ、現時点でどのグループにどれだけの不在着信があったか、あるいは、先回の確認からどのグループの未不在着信がどれだけ増えたのか、などといったイベントの詳細な情報を何らの操作を行うことなく、一目で知ることができるという優れた効果も得られる。
【００７４】
以上の説明は、携帯電話機１への適用を例にしたが、ユーザに届く通知（イベント）は上記の例（メール受信や不在着信）に限らず、他にも様々なものがある。たとえば、スケジュール通知（予めユーザが設定した日時に何らかの手段でイベントが発生するもの）もその１つである。とりわけ、インターネットなどのネットワークを利用したスケジュール通知サービスは、昨今、高機能且つきめ細やかなサービスが行われており、たとえば、仕事とプライベートの区別はもちろんのこと、さらに、仕事の場合も「Ａ社用」、「Ｂ社用」、「Ｃプロジェクト用」、「Ｄプロジェクト用」などと細分化することができ、または、プライベートの場合も「家庭用」、「Ｅ趣味用」、「Ｆ趣味用」などと細分化することができる。さらに、ソーシャルネットワークサービス（ＳＮＳ）などの人対人の交流サービスにあっても同様のきめ細かなサービスが提供されている。
【００７５】
こうしたサービスを利用する場合、ユーザの端末には多くのイベントが通知されることになる。とりわけ、複数のサービスを並行利用している場合は、より多くのイベントが通知される。
【００７６】
図１１（ａ）は、イベント通知型のネットワークサービス利用概念図である。この図において、インターネット等のネットワーク３５には、複数（図では４台）のサービスサーバ（以下、単にサーバという）３６〜３９が接続されていると共に、ユーザの端末４０も接続されている。
【００７７】
端末４０のユーザは、これら４台のサーバ３６〜３９が各々提供するサービスを利用しているものとする。サービスの内容は、たとえば、前述のスケジュール通知サービスやＳＮＳなどであるが、他のサービスであってもかまわない。イベント通知型のサービスであればよい。
【００７８】
今、サーバ３６〜３９のアドレス、つまり、ネットワーク３５上の固有の識別情報（典型的にはＵＲＬ）を便宜的にそれぞれ「ａ」、「ｂ」、「ｃ」、「ｄ」とする。つまり、サーバ３６のアドレスを「ａ」、サーバ３７のアドレスを「ｂ」、サーバ３８のアドレスを「ｃ」、サーバ３９のアドレスを「ｄ」とする。
【００７９】
ユーザの端末４０は、定期的または不定期に各々のサーバ３６〜３９にアクセスし、各サーバ３６〜３９から自分宛に通知されるイベントを取り込み、そのイベント報知を端末４０の画面上に表示する。今、アドレス「ａ」のサーバ３６から４つのイベント（ｉ１〜ｉ４）が端末４０に取り込まれ、また、アドレス「ｂ」のサーバ３７からも３つのイベント（ｉ５〜ｉ７）が端末４０に取り込まれたものとする。同様に、アドレス「ｃ」のサーバ３８からも４つのイベント（ｉ８〜ｉ１１）が端末４０に取り込まれ、さらに、アドレス「ｄ」のサーバ３７からも１つのイベント（ｉ１２）が端末４０に取り込まれたものとする。
つまり、４台のサーバ３６〜３９から端末４０に合計１２個のイベント（ｉ１〜ｉ１２）が取り込まれたものとする。
【００８０】
図１１（ｂ）は、１２個のイベント（ｉ１〜ｉ１２）をグループ分けするためのアドレステーブルの構造模式図である。このアドレステーブル４１は、いくつかのグループ（図では第１〜第４の４つのグループ）ごとにサーバ３６〜３９のアドレスを振り分けている。たとえば、第１グループにアドレスの「ａ］と［ｂ」を振り分け、第２グループにアドレスの「ａ］と［ｃ」を振り分け、第３グループにアドレスの「ｂ］と［ｃ」を振り分け、第４グループにアドレスの「ｄ］を振り分けている。
【００８１】
このような振り分け例に従えば、４台のサーバ３６〜３９からの１２個のイベント（ｉ１〜ｉ１２）をアドレスに従ってグルーブごとにまとめてユーザに報知することができる。
【００８２】
図１２は、グループごとの報知例を示す図である。（ａ）は比較のために示す非グループ報知例であり、（ｂ）は前記実施形態の技術思想を適用したグループ報知例である。非グループ報知の場合、（ａ）に示すように、端末４０の画面上には１２個のイベント報知４２〜５３のすべてが表示される。端末４０の画面サイズが充分に大きければ特段の不都合を生じないものの、小さな画面サイズの場合、特にブック型や携帯型のタブレット端末などにおいては表示面積の圧迫を免れない。
【００８３】
これに対して、（ｂ）に示す例、つまり、前記実施形態の技術思想を適用したグループ報知例の場合は、各グループごとの４個のイベント報知５４〜５７が表示されているに過ぎず、（ａ）との比較で見ても、はるかに少ない表示数であるから、画面素表示面積の圧迫を招くことはない。したがって、特にブック型や携帯型のタブレット端末などのように小さな画面サイズの場合に有効である。
【００８４】
さらに、（ｂ）において、４個のイベント報知５４〜５７のそれぞれにグループ内のイベント数を表示するためのエリア５４ａ〜５７ａを設けておけば、各グループのイベント数、つまり、第１のグループのイベント数（ｉ１〜ｉ４とｉ５〜ｉ７の７個）、第２のグループのイベント数（ｉ１〜ｉ４とｉ８〜ｉ１１の８個）、第３のグループのイベント数（ｉ５〜ｉ７とｉ８〜ｉ１１の７個）、第４のグループのイベント数（ｉ１２の１個）をそれぞれのエリア５４ａ〜５７ａに表示できるので、各グループのイベントの詳細な情報も一目で知ることができ、たとえば、どのグループのイベントを先に確認すべきか、などといった状況判断を速やかに下すことができる。
【００８５】
このように、前記実施形態の技術思想は、スケジュール通知やＳＮＳなどのネットワークサービス（イベント通知型のサービス）にも応用することができる。この場合、前記実施形態の技術思想の実体はサーバ側、端末側のいずれに実装してもかまわない。
【００８６】
図１３は、端末側に実施形態の技術思想の実体を実装した場合の概念図である。この図に示すように、端末４０は、サーバ３６〜３９からのイベント（ｉ１〜ｉ１２）を取り込み、イベントを発生したサーバ３６〜３９のアドレスと、図１１のアドレステーブル４１とを照合し、どのグループに属するイベントであるかを判定する（ステップＳ２１）。次いで、端末４０はそのグループ照合結果が「照合結果Ｘ」（図９の照合結果Ｘに相当）であれば、各々のイベント（ｉ１〜ｉ１２）をグループ分けして端末４０の画面に表示する（ステップＳ２２）。このときの表示例は、図１２（ａ）である。なお、どのグルーブにも属しないと判定されたイベント（「照合結果Ｙ」図９の照合結果Ｙに相当）については、図１２（ａ）に示すようなイベント単体の表示（イベント報知４２〜５３参照）を行えばよい（ステップＳ２３）。
【００８７】
前記実施形態の技術思想の実体をサーバ側に実装する場合は、図１１のアドレステーブル４１に相当するものをサーバで保持すると共に、図１３のステップＳ２１、ステップＳ２２およびステップＳ２３に相当する処理部をサーバに実装すればよい。この場合、自サーバで発生するイベントのみをグループ化することができる。グループ化した結果を端末４０に送信すればよい。グループ化した結果を端末４０に送信する仕組みには、いわゆる「動的ホームページ」の技術を利用することができる。
【００８８】
すなわち、ホームページには、サーバから端末に送られたＨＴＭＬファイルをそのまま表示する「静的ホームページ」と、ユーザ（端末）からのリクエストに応じて（例えば入力フォームの内容に応じて）、サーバ上のプログラムがＨＴＭＬ文書を作成し、ユーザ（端末）に送り返す「動的ホームページ」の二種類あるが、この「動的ホームページ」の技術を利用すれば、サーバ上でイベントをグループ化した結果を動的ＨＴＭＬ文書の形にして端末４０に送信することができ、さらに、動的ＨＴＭＬ文書に含まれているユーザリクエスト用コントロール（ボタンやリンク情報など）の操作結果をサーバに送り返し、再び、所要の動的ＨＴＭＬ文書（たとえば、選択されたグループの詳細なイベント情報を含む文書）を生成して端末４０に送信することができる。
このように、「動的ホームページ」の技術を利用することにより、前記実施形態の技術思想の実体をサーバ側にも実装することができる。
サーバ側と端末側のいずれに実装するかは、システムの運用目的等を勘案して適切に判断すればよい。
【００８９】
本実施の形態ではメールボックスや電話帳を格納するのにメモリ１６を用いて説明したが、これに限らない。ＲＡＭ１９ｃなどの記憶装置を使用してもよい。あるいは、ＲＯＭ１９ｂが書き換え可能のもの（プログラマブル型のＲＯＭ）である場合は、そのＲＯＭ１９ｂを使用してもよい。
また、未読メール数、電話の不在着信数、イベントの未読数を例に説明したがこれに限らない。累積数だけでなく、直近のメール着信数や、直近の未読メール数、直近の電話の不在着信数や、不在着信後に電話をしてかけ直していない未応答数や直近の未応答数、直近の未読イベント数であってもよい。
また、メールアドレスや電話番号やイベントのグループを判定した際の判定基準について、照合結果Ｘの基準として未登録のものである場合、または登録済みであるがグループ分けされたものではないとして、グループ０番としてまとめて通知する説明をしたがこれに限らない。未登録のものは別のグループ扱いとしてグループ０番や他のグループとは別のグループに見えるように分けて通知してもよい。
また、未登録のものは通知しない仕組みとしてもよい。迷惑メールやワン切りなどの知らない人からの通知をしないようにしてもよい。
また、０番のグループはシステム用で、グループ番号は１からの自然数として説明したが、これに限らない。グループＡ、Ｂ、Ｃ・・・・、グループ家族、グループ仕事等、表示上は数字には限らない。内部処理として検索処理可能なユニークな記号が内部的に割り振られたグループであればよい。
また、不在着信数や未読メール数などの報知で画面に表示する際に種別アイコンに加えその数字を表示したが、画面の表示エリア、表示アイコン数、種類などの制約に応じて、全ての数字を表示しなくてもよい。例えば２桁以上の数字は＋などの記号に置き換えて１桁分の表示エリアで表示をしてもよい。
【００９０】
以下、本発明の特徴を付記する。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
図１４は、付記１の構成図である。
付記１は、少なくともイベントのグルーブ化が可能なグループ情報（１００：実施形態のメールアドレスや発信者番号、ＵＲＬなどに相当）を含むイベント情報（１０１：実施形態のメール受信、不在着信、スケジュール通知などのイベント情報に相当）を受信する受信手段（１０２：実施形態のメール振り分け制御部２３に相当）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３：実施形態のメール振り分け制御部２３に相当）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４：実施形態のメール振り分け制御部２３に相当）とを備えたことを特徴とするイベント報知装置（１０５：実施形態の携帯電話機１に相当）である。
（付記２）
付記２は、前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする付記１に記載のイベント報知装置である。
（付記３）
付記３は、前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記４）
付記４は、前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記５）
付記５は、前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする付記１または付記２いずれかに記載のイベント報知装置である。
（付記６）
図１５は、付記６の構成図である。
付記６は、少なくともイベントのグルーブ化が可能なグループ情報（１００）を含むイベント情報（１０１）を発生する発生手段（１０６：実施形態のメールサーバ３６〜３９に相当）と、前記イベント情報（１０１）を受信する受信手段（１０２）と、前記グループ情報（１００）に基づいて前記イベント情報（１０１）をグループ化するグループ化手段（１０３）と、前記グループ化された単位でユーザにイベントを報知する報知手段（１０４）とを備えたことを特徴とするイベント報知システム（１０７）である。
（付記７）
付記７は、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、前記グループ化された単位でユーザにイベントを報知する報知工程とを含むことを特徴とするイベント報知方法である。
（付記８）
付記８は、コンピュータに、少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、前記グループ化された単位でユーザにイベントを報知する報知手段としての機能を与えることを特徴とするプログラムである。
【符号の説明】
【００９１】
１００ グループ情報
１０１ イベント情報
１０２ 受信手段
１０３ グループ化手段
１０４ 報知手段
１０５ イベント報知装置
１０６ 発生手段
１０７ イベント報知システム
【特許請求の範囲】
【請求項１】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、
前記グループ化された単位でユーザにイベントを報知する報知手段と
を備えたことを特徴とするイベント報知装置。
【請求項２】
前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする請求項１に記載のイベント報知装置。
【請求項３】
前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項４】
前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項５】
前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項６】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、
前記イベント情報を受信する受信手段と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、
前記グループ化された単位でユーザにイベントを報知する報知手段と
を備えたことを特徴とするイベント報知システム。
【請求項７】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、
前記グループ化された単位でユーザにイベントを報知する報知工程と
を含むことを特徴とするイベント報知方法。
【請求項８】
コンピュータに、
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、
前記グループ化された単位でユーザにイベントを報知する報知手段
としての機能を与えることを特徴とするプログラム。
【請求項１】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、
前記グループ化された単位でユーザにイベントを報知する報知手段と
を備えたことを特徴とするイベント報知装置。
【請求項２】
前記報知手段は、グループ化されたイベント情報の数を一緒に報知することを特徴とする請求項１に記載のイベント報知装置。
【請求項３】
前記イベント情報がメール受信のイベントであって、且つ、前記グループ情報が当該メールの差出人アドレスであることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項４】
前記イベント情報が不在着信のイベントであって、且つ、前記グループ情報が当該不在着信の発信者番号であることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項５】
前記イベント情報がスケジュール通知、または、ソーシャルネットワークサービスの通知であって、且つ、前記グループ情報が当該通知を行ったサーバのアドレスであることを特徴とする請求項１または２いずれかに記載のイベント報知装置。
【請求項６】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を発生する発生手段と、
前記イベント情報を受信する受信手段と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段と、
前記グループ化された単位でユーザにイベントを報知する報知手段と
を備えたことを特徴とするイベント報知システム。
【請求項７】
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信工程と、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化工程と、
前記グループ化された単位でユーザにイベントを報知する報知工程と
を含むことを特徴とするイベント報知方法。
【請求項８】
コンピュータに、
少なくともイベントのグルーブ化が可能なグループ情報を含むイベント情報を受信する受信手段、
前記グループ情報に基づいて前記イベント情報をグループ化するグループ化手段、
前記グループ化された単位でユーザにイベントを報知する報知手段
としての機能を与えることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１３−７０３４６（Ｐ２０１３−７０３４６Ａ）
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１１−２０９２６３（Ｐ２０１１−２０９２６３）
【出願日】平成２３年９月２６日（２０１１．９．２６）
【出願人】（３９００１０１７９）埼玉日本電気株式会社 (1,228)
【Ｆターム（参考）】
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２３年９月２６日（２０１１．９．２６）
【出願人】（３９００１０１７９）埼玉日本電気株式会社 (1,228)
【Ｆターム（参考）】
[ Back to top ]