JP6397859B2 - メッセージの受信通知のための方法、システム、および記録媒体 - Google Patents

Description

本発明の実施形態は、受信メッセージに対する通知を提供する技術に関する。

ユーザ間でメッセージをやり取りすることのできるメッセージングアプリケーションは、端末機において必須の構成要素として位置づいている。例えば、端末機間で文字メッセージや映像メッセージを送受信するために、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）やＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）などが主に利用されている。

一般的に、端末機はメッセージを受信すると、ユーザが端末機に予め設定しておいた内容にしたがってベル音、振動、ランプ（無音）などを活用してメッセージの受信状態を知らせる。

また、メッセージの受信通知の方式としては、新たなメッセージの受信状態を示すアイコンを端末機のステータスバー（ｓｔａｔｕｓ ｂａｒ）やタスクバー（ｔａｓｋ ｂａｒ）に表示する方式、メッセージの受信を知らせる通知メッセージ、あるいは受信したメッセージの内容の少なくとも一部をポップアップ（ｐｏｐ−ｕｐ）ウィンドウで表示する方式などが適用されている。

韓国登録特許第１０−０６６４１３７号公報

受信メッセージの種類に応じて区分された通知ウィンドウを提供することができるメッセージの受信通知方法、システム、および記録媒体を提供する。

受信メッセージに対する通知ウィンドウを、受信メッセージの種類に応じて柔軟に構成して提供することができるメッセージの受信通知方法、システム、および記録媒体を提供する。

コンピュータによって実現されるメッセージの受信通知方法であって、メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレームを予め定義することにより、ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信したメッセージに対応する種類を判断すること、前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決めること、および前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージに対する通知ウィンドウを生成および提供することを含む、メッセージの受信通知方法を提供する。

メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレームを予め定義することにより、ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信されたメッセージに対応する種類を判断すること、前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決めること、および前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージに対する通知ウィンドウを生成および提供することをコンピュータに実行させるためのコンピュータプログラムを提供する。

メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレームを予め定義することにより、ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信されたメッセージに対応する種類を判断する判断部、および前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決めた後、前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージに対する通知ウィンドウを生成および提供する提供部を備える、メッセージの受信通知システムを提供する。

本発明の実施形態によると、受信メッセージの種類に応じて区分された通知ウィンドウを提供することにより、受信メッセージに適した通知環境を提供することができ、メッセージ受信をさらに効果的に知らせることができる。

本発明の実施形態によると、メッセージの内容によって予測可能なユーザアクションを考慮した上で通知ウィンドウに含まれるユーザインタフェースを提供することにより、メッセージに応じてユーザインタフェースを柔軟に構成することができ、メッセージ別に関連する機能へのアクセス性を向上させることができる。

本発明の一実施形態における、メッセージの受信通知環境の一例を説明するための図である。 本発明の一実施形態における、メッセージの受信通知システムの内部構成の一例を説明するためのブロック図である。 本発明の一実施形態における、メッセージの受信通知方法を説明するためのフローチャートである。 本発明の一実施形態における、メッセージの種類を判断する過程を説明するためのフローチャートである。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、メッセージの受信通知と関連するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、受信メッセージと関連する追加情報を提供するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、受信メッセージと関連する追加情報を提供するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、受信メッセージと関連する追加情報を提供するユーザ端末画面の一例を示した図である。 本発明の一実施形態における、コンピュータシステムの内部構成の一例を説明するためのブロック図である。

以下、本発明の実施形態について、添付の図面を参照しながら詳細に説明する。

本実施形態は、受信メッセージに対する通知を提供する技術に関し、より詳細には、受信メッセージの種類に応じて区分された通知ウィンドウを提供することができるメッセージの受信通知方法とシステム、および記録媒体に関する。

本明細書において、「メッセージ」とは、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）、ＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）、ＥＭＳ（Ｅｎｈａｎｃｅｄ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）、インスタントメッセンジャー（ｉｎｓｔａｎｔ ｍｅｓｓｅｎｇｅｒ）、ＳＮＳ（ｓｏｃｉａｌ ｎｅｔｗｏｒｋ ｓｅｒｖｉｃｅ）、電子メール（ｅ−ｍａｉｌ）などで送信される単位情報であって、通信網を介して端末と端末との間でやり取りされるすべてのデータを包括したものを意味する。

図１は、本発明の一実施形態における、メッセージの受信通知環境の一例を説明するための図である。図１では、ユーザ端末１０１およびメッセージの受信通知システム１００を示している。図１に示す矢印は、構成要素間で有線／無線ネットワーク１０を介してデータが送受信されることを意味している。

ユーザ端末１０１は、本明細書で説明される特徴のうち１つ以上を実行するように構成された１つ以上のプロセスを実行してもよい。ユーザ端末１０１とは、メッセージの受信通知システム１００と関連するサービス専用アプリケーション（以下、「メッセージアプリ」と称する）のインストールおよび実行が可能なすべての端末装置を意味してもよい。ここで、ユーザ端末１０１は、メッセージアプリの制御下で、サービス画面の構成、データ入力、データ送受信、データ格納などのようなサービス全般の動作を実行してもよい。

ユーザ端末１０１の一例としては、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型パソコン（ｌａｐｔｏｐ ｃｏｍｐｕｔｅｒ）、ラップトップコンピュータ（ｌａｐｔｏｐ ｃｏｍｐｕｔｅｒ）、スマートフォン（ｓｍａｒｔ ｐｈｏｎｅ）、タブレット（ｔａｂｌｅｔ）、ウェアラブルコンピュータ（ｗｅａｒａｂｌｅ ｃｏｍｐｕｔｅｒ）などを含んでもよいが、これに限定されることはない。

ユーザ端末１０１は、ネットワーク１０（例えば、インターネットあるいはローカルエリアネットワークなど）に直接的あるいは間接的に接続してもよい。例えば、パーソナルコンピュータとノート型コンピュータは、有線ネットワーク接続を介してネットワーク１０に直接的に接続してもよい。ラップトップコンピュータは、ラップトップコンピュータと無線アクセスポイント（Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｐｏｉｎｔ）（すなわち、ＷＡＰ）との間に確立された無線通信チャネルを介してネットワーク１０に無線で接続してもよい。スマートフォンは、スマートフォンとセルラネットワーク／ブリッジとの間に確立された無線通信チャネルを介してネットワーク１０に無線で接続してもよい。ここで、ネットワーク１０は、１つ以上の２次ネットワーク（図示せず）と通信してもよく、２次ネットワークの例としては、ローカルエリアネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ワイドエリアネットワーク（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、またはイントラネット（ｉｎｔｒａｎｅｔ）を含んでもよいが、これに限定されることはない。

ユーザ端末１０１は、上述したネットワーク１０を介してメッセージの受信通知システム１００と互いに通信してもよい。

メッセージの受信通知システム１００は、本明細書で説明される特徴のうち１つ以上を実行するように構成された１つ以上のプロセスを実行してもよい。メッセージの受信通知システム１００は、メッセージアプリがインストールされたクライアント（ｃｌｉｅｎｔ）であるユーザ端末１０１を対象に、ユーザ端末１０１が受信したメッセージに対してメッセージの受信通知を提供してもよい。特に、メッセージの受信通知システム１００は、受信メッセージに対する構文解析（ｐａｒｓｉｎｇ；パーシング）によってメッセージの内容を把握した後、把握したメッセージ内容に応じて区分された通知ウィンドウを提供してもよく、通知ウィンドウ内のユーザインタフェース（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ；ＵＩ）もメッセージ内容に応じて柔軟に構成して提供してもよい。

メッセージの受信通知システム１００と関連するメッセージアプリは、受信メッセージに対する通知ウィンドウを提供する機能、スケジュール機能と連動する機能、定型文などを利用した迅速な返信機能、受信メッセージに対する通知バナーを提供する機能、メッセージの通知情報を管理するための通知センターを提供する機能などが含まれてもよい。

上述したメッセージアプリは、ＰＣ環境はもちろん、モバイル環境でも使用可能なように実現されるものであって、独立的に動作するプログラム形態で構成されてメッセージと関連する特定のアプリケーション（例えば、ＳＭＳやＭＭＳのようなメッセージングアプリケーション、メッセンジャーアプリケーション、メールアプリケーション、ＳＮＳアプリケーションなど）との連動によって動作するように実現されてもよいし、上述した特定のアプリケーションのイン−アプリ（ｉｎ−ａｐｐ）形態で構成されて該当するアプリケーション上で動作が可能なように実現されてもよい。

上述したメッセージの受信通知システム１００は、少なくとも一部の構成要素がユーザ端末１０１上にインストールされるアプリケーション形態で実現されてもよいし、クライアント−サーバ環境でサービスを提供するプラットフォームに含まれる形態で実現されてもよい。

メッセージの受信通知システム１００は、サーバコンピュータに該当するものであって、サーバコンピュータの一例としては、サーバコンピュータデバイス、パソコン、サーバコンピュータ、一連のサーバコンピュータ、ミニコンピュータ、および／またはメインフレームコンピュータを含んでもよいが、これに限定されることはない。サーバコンピュータは分散型システムであってもよく、サーバコンピュータの動作は、１つ以上のプロセッサ上で同時にそして／または順に実行されてもよい。

図２は、本発明の一実施形態における、メッセージの受信通知システムの内部構成を説明するためのブロック図であり、図３は、本発明の一実施形態における、メッセージの受信通知方法を説明するためのフローチャートである。

本実施形態に係るメッセージの受信通知システム１００は、プロセッサ２１０、バス２２０、ネットワークインタフェース２３０、メモリ２４０、およびデータベース２５０を備えてもよい。メモリ２４０は、オペレーティングシステム２４１および通知提供ルーチン２４２を含んでもよい。プロセッサ２１０は、判断部２１１および提供部２１２を含んでもよい。他の実施形態において、メッセージの受信通知システム１００は、図２の構成要素よりもさらに多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、メッセージの受信通知システム１００は、ディスプレイやトランシーバ（ｔｒａｎｓｃｅｉｖｅｒ）のような他の構成要素を含んでもよい。

メモリ２４０は、コンピュータで読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永久大容量記憶装置（ｐｅｒｍａｎｅｎｔ ｍａｓｓ ｓｔｏｒａｇｅ ｄｅｖｉｃｅ）を含んでもよい。また、メモリ２４０には、オペレーティングシステム２４１と通知提供ルーチン２４２のためのプログラムコードが格納されてもよい。このようなソフトウェア構成要素は、ドライブメカニズム（ｄｒｉｖｅ ｍｅｃｈａｎｉｓｍ）（図示せず）を利用してメモリ２４０とは別のコンピュータで読み取り可能な記録媒体からロードされてもよい。このような別のコンピュータで読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭドライブ、メモリカードなどのコンピュータで読み取り可能な記録媒体を含んでもよい。他の実施形態において、ソフトウェア構成要素は、コンピュータで読み取り可能な記録媒体ではないネットワークインタフェース２３０を利用してメモリ２４０にロードされてもよい。

バス２２０は、メッセージの受信通知システム１００の構成要素間の通信およびデータ送信を可能にする。バス２２０は、高速シリアルバス、パラレルバス、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、および／または他の適切な通信技術を利用して構成されてもよい。

ネットワークインタフェース２３０は、メッセージの受信通知システム１００をコンピュータネットワークに接続するためのコンピュータハードウェア構成要素であってもよい。ネットワークインタフェース２３０は、メッセージの受信通知システム１００を無線または有線接続を介してコンピュータネットワークに接続させてもよい。

データベース２５０は、メッセージの受信通知機能を提供するために必要なすべての情報を格納および維持する役割をする。データベース２５０は、ユーザがやり取りしたメッセージを格納してもよい。ここで、データベース２５０に格納されるメッセージは、基本的には時間情報を含んでもよく、これによってメッセージをタイムライン形態で管理してもよいし、日付別メッセージや相手（送信者／受信者）別メッセージなどに分類して管理してもよい。特に、データベース２５０は、受信メッセージに対する通知情報を含んでもよいが、ここで、通知情報とは、メッセージの受信を知らせる通知メッセージであって、これも時間情報を含んでよい。言い換えれば、データベース２５０には、受信メッセージ、すなわちユーザが未読のメッセージに対して通知情報が累積されることにより、データベース２５０に格納された通知情報は、時間情報を基準として管理される。また、データベース２５０には、メッセージの種類別に予め定義された通知ウィンドウのフレーム（またはテンプレート）と、フレーム別ユーザインタフェースを構成するためのコード情報などが含まれてもよい。さらに、データベース２５０には、受信メッセージに対する迅速な返信機能として、予め定義された返信メッセージテンプレートなどがさらに含まれてもよい。

図２では、メッセージの受信通知システム１００の内部にデータベース２５０を構築して含むものを示しているが、これに限定されることはなく、システム実現方式や環境などに応じて省略されてもよいし、全体または一部のデータベースが別の他のシステム上に構築された外部データベースとして存在してもよい。または、データベース２５０がユーザ端末１０１上にインストールされるアプリケーションに含まれるローカルデータベースで実現されてもよい。

プロセッサ２１０は、基本的な算術、ロジック、およびメッセージの受信通知システム１００の入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてもよい。命令は、メモリ２４０またはネットワークインタフェース２３０によって、バス２２０を介してプロセッサ２１０に提供されてもよい。プロセッサ２１０は、判断部２１１および提供部２１２のためのプログラムコードを実行するように構成されてもよい。このようなプログラムコードは、メモリ２４０のような記録装置に格納されてもよい。

判断部２１１および提供部２１２は、図３のステップ３１０からステップ３２０を実行するために構成されてもよい。

ステップ３１０で、判断部２１１は、ユーザ端末にメッセージが受信されると、受信メッセージを読み取り、該当するメッセージを構文解析することによってメッセージの種類を判断してもよい。判断部２１１は、メッセージに含まれる内容を構文解析し、メッセージの種類別に事前に定義された規則にしたがって受信メッセージの種類を区分してもよい。一例として、判断部２１１は、メッセージにファイルダウンロードリンク（例えば、ａｐｋファイルをダウンロードするＵＲＬなど）が含まれているか、あるいはダウンロードするファイルが悪性コードＤＢに含まれているかどうかを判断することによってスミッシングメッセージを区分してもよい。他の例として、判断部２１１は、メッセージに認証番号あるいは承認番号が含まれているかを判断することによって認証要請メッセージを区分してもよい。さらに他の例として、判断部２１１は、メッセージを送った送信者情報（例えば、送信者の電話番号や送信者の名前など）が事前に定義された管理対象情報に含まれるかを判断することによってメッセージの種類を区分してもよい。ここで、送信者情報とは、メッセージに直接含まれる内容であってもよいし、受信メッセージに対してユーザ端末で識別された内容であってもよい。例えば、判断部２１１は、送信者番号が金融会社電話番号ＤＢ（管理対象に含まれた金融会社の電話番号が格納されたデータベース（ＤＢ））に含まれている番号であるかどうかによって金融関連メッセージを区分してもよい。ここで送信者番号とは、メッセージを送信した人の電話番号を意味する。また受信メッセージに対してユーザ端末で識別された内容とは、電話番号に限定されず、例えば、ユーザ端末に、保存された電話番号、名前、住所などであってもよい。

ここで、判断部２１１は、金融関連メッセージである場合には、メッセージの内容にカード決済内訳が含まれるかによって決済確認メッセージを区分してもよく、決済予定情報が含まれるかによって決済予定メッセージを区分してもよく、銀行入出金内訳が含まれるかによって入出金確認メッセージを区分してもよい。さらに他の一例として、判断部２１１は、メッセージに事前に定義された特定のフレーズやキーワードが含まれるかを判断することによってスパムメッセージを区分してもよい。例えば、判断部２１１は、メッセージの内容に広告フレーズが含まれるかによって広告メッセージを区分してもよく、事前に定められた宅配関連キーワード（例えば、宅配、送り状番号、配達、配送など）が含まれるかによって宅配関連メッセージを区分してもよく、事前に定められたスパム関連キーワード（例えば、キャッシング、運転代行、金利など）が含まれるかによってスパムメッセージを区分してもよい。

上述したメッセージ判断方式のうち少なくとも１つ以上を適用することによって受信メッセージの種類を判断してもよいが、この他にも、公知の技術範囲内でメッセージの種類を判断するための多様な基準を追加して活用してもよい。

ステップ３２０で、提供部２１２は、受信メッセージに対し、該当するメッセージの種類に対応する通知ウィンドウをポップアップ形態でユーザ端末に提供してもよい。通知ウィンドウを構成するためのフレーム（またはテンプレート）は、メッセージの種類に応じて異なるように定義されるが、これにより、提供部２１２は、メッセージの種類別に事前に定義されたフレームのうちから受信メッセージの種類に該当するフレームを決めた後、決められたフレームにしたがって受信メッセージに対する通知ウィンドウを構成して提供してもよい。言い換えれば、提供部２１２は、メッセージの種類に対応するフレームにしたがってメッセージを加工し、受信したメッセージに対する通知情報を生成し、メッセージの種類に応じて区分された通知ウィンドウを生成および提供することができる。ここで通知情報は受信メッセージの少なくとも一部、例えば、送信者の電話番号、送信者の名前、メッセージの内容の中で少なくとも一部などが含まれてもよい。通知ウィンドウは、メッセージの種類に応じて互いに異なる色のフレームで構成されてもよいが、色の他にも、フレームの大きさや模様などのような多様な表示属性を利用してメッセージ種類別にフレームを異にして定義してもよい。

本実施形態では、通知ウィンドウに含まれるユーザインタフェース（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ；ＵＩ）も、受信メッセージの種類に応じて異なるように構成することができる。メッセージの内容に応じてユーザニーズのあるアクションを考慮した上で通知ウィンドウに含まれるアクションボタンをメッセージの種類に応じて事前に定義しておき、メッセージの種類別に通知ウィンドウのアクションボタンを柔軟に構成してもよい。また、提供部２１２は、通知ウィンドウに、他のアプリケーションと連動して他の機能に直ぐにアクセスすることのできる環境を提供してもよい。例えば、提供部２１２は、通知ウィンドウに含まれるアクションボタンにスケジュールアプリケーションを呼び出すためのＵＩを構成することで、スケジュール機能へのアクセス経路を提供してもよい。スケジュール機能を例示的に説明しているが、これに限定されることはなく、メッセージと関連するアクションのニーズに応じていくらでも機能の追加や拡張ができる。

また、提供部２１２は、メッセージの受信通知の他の形態として、メッセージ保管トレイと関連するユーザ端末画面上に、受信メッセージに対する通知情報をバナー形態で提供してもよい。ここで、メッセージ保管トレイとは、メッセージの格納、整列、確認、削除などを行うメッセージ管理環境の単位であって、メッセージアプリ上に自主的に作成された保管トレイであってもよいし、メッセージアプリ上に含まれたメッセージを実際に送受信する主体の保管トレイであってもよい。また、提供部２１２は、メッセージ保管トレイとは別に、受信メッセージに対する通知情報を別に管理するための通知センターを提供してもよく、メッセージの受信通知のさらに他の形態として、通知センターを通じて受信メッセージに対する通知メッセージを提供してもよい。言い換えれば、提供部２１２は、受信メッセージに対する通知メッセージのために通知センターを構成することによってメッセージの通知情報を管理するための場所を提供してもよい。通知センターはメッセージ保管箱とは別に受信メッセージに対する通知情報を管理するための仮想空間であり、通知情報を別に保管するための通知メッセージの保管箱である。

また、提供部２１２は、受信メッセージに対する通知ウィンドウと共に、通知ウィンドウと隣接する少なくとも１つの位置に、受信メッセージと関連する追加情報を提供してもよい。例えば、提供部２１２は、決済確認メッセージの通知ウィンドウが表示されるとき、該当する通知ウィンドウの下端に集計期間中のカード使用金額の合計や、カード使用先での最近の購買内訳、カード使用先との取引履歴、カード使用先と関連のあるイベント案内などを共に表示してもよい。

図４は、本発明の一実施形態における、メッセージの種類を判断する過程を説明するためのフローチャートである。図４のステップは、図２を参照しながら説明した判断部２１１によって実行されてもよい。

ステップ４０１で、判断部２１１は、受信メッセージがファイルダウンロードリンク（例えば、ａｐｋファイルをダウンロードするＵＲＬなど）を含むかどうかを判断する。

ステップ４０２からステップ４０４で、判断部２１１は、受信メッセージがファイルダウンロードリンクを含む場合、受信メッセージの種類をスミッシングメッセージと判断する。一例として、悪性コードなどを含むファイルのリストを事前に悪性コードＤＢとして構築して管理してもよく、これにより、判断部２１１は、ファイルダウンロードリンクを介してダウンロードされるファイル（例えば、ａｐｋファイルなど）が悪性コードＤＢに登録されているファイルであるかどうかを判断し（ステップ４０２）、悪性コードＤＢに登録されているファイルである場合には、確実にスミッシングメッセージ（スミッシングメッセージ）と判断し（ステップ４０３）、悪性コードＤＢには登録されていないがファイルをダウンロードする場合には、スミッシングメッセージの可能性を考慮した上でスミッシングが疑われるメッセージ（スミッシングである可能性があるメッセージ）と判断してもよい（ステップ４０４）。他の一例として、判断部２１１は、受信メッセージがファイルを自動的にダウンロードするファイルダウンロードリンクを含む場合には、無条件にスミッシングメッセージと判断してもよい。

ステップ４０５で、判断部２１１は、受信メッセージがファイルダウンロードリンクを含まない場合は、受信メッセージのテキストが認証番号あるいは承認番号を含むかどうかを判断する。

ステップ４０６で、判断部２１１は、受信メッセージのテキストが認証番号あるいは承認番号を含む場合は、受信メッセージの種類を認証要請メッセージと判断する。

ステップ４０７で、判断部２１１は、受信メッセージのテキストが認証番号あるいは承認番号を含まない場合は、受信メッセージの送信者番号が金融会社電話番号ＤＢに存在するかどうかを判断する。

ステップ４０８で、判断部２１１は、受信メッセージの送信者番号が金融会社電話番号ＤＢに存在する場合は、受信メッセージのテキストがカード決済内訳（例えば、決済金額など）を含むかどうかを判断する。

ステップ４０９で、判断部２１１は、受信メッセージのテキストがカード決済内訳を含む場合は、受信メッセージの種類を決済確認メッセージと判断する。

ステップ４１０で、判断部２１１は、受信メッセージのテキストがカード決済内訳を含まない場合は、受信メッセージのテキストが決済予定情報（例えば、決済予定金額など）を含むかどうかを判断する。

ステップ４１１で、判断部２１１は、受信メッセージのテキストが決済予定情報を含む場合は、受信メッセージの種類を決済予定メッセージと判断する。

上述した決済確認メッセージと決済予定メッセージは、互いに異なる種類のメッセージとして分類されると説明しているが、これに限定されることはなく、２つのメッセージを同じ種類のメッセージとして分類してもよい。

ステップ４１２で、判断部２１１は、受信メッセージのテキストがカード決済内訳を含まない場合は、受信メッセージのテキストが銀行入出金内訳（例えば、入金金額や出金金額など）を含むかどうかを判断する。

ステップ４１３で、判断部２１１は、受信メッセージのテキストが銀行入出金内訳を含む場合は、受信メッセージの種類を入出金確認メッセージと判断する。

ステップ４１４で、判断部２１１は、受信メッセージの送信者番号が金融会社電話番号ＤＢに存在しない場合は、受信メッセージのテキストが特定のキーワードである「広告」というフレーズを含むかどうかを判断する。

ステップ４１５で、判断部２１１は、受信メッセージのテキストが広告フレーズを含む場合は、受信メッセージの種類を広告メッセージと判断する。

ステップ４１６で、判断部２１１は、受信メッセージのテキストが広告フレーズを含まない場合は、受信メッセージのテキストが宅配と関連するキーワード（例えば、宅配、送り状番号、配達、配送など）（以下、「宅配関連キーワード」と称する）を含むかどうかを判断する。

ステップ４１７で、判断部２１１は、受信メッセージのテキストが宅配関連キーワードを含む場合は、受信メッセージの種類を宅配関連メッセージと判断する。

ステップ４１８で、判断部２１１は、受信メッセージのテキストが宅配関連キーワードを含まない場合は、受信メッセージのテキストがスパムメッセージ分類のために特定されたキーワード（例えば、キャッシング、運転代行、金利など）（以下、「スパム関連キーワード」と称する）を含むかどうかを判断する。

ステップ４１９で、判断部２１１は、受信メッセージのテキストがスパム関連キーワードを含む場合は、受信メッセージの種類をスパムメッセージと判断する。言い換えれば、受信メッセージのうち、キャッシング、運転代行、金利などのキーワードを含むメッセージをスパムフィルタによってフィルタリングした後、スパム指数に基づいてスパムメッセージとして処理してもよい。

ステップ４２０で、判断部２１１は、受信メッセージがスミッシングメッセージ、スミッシングである可能性があるメッセージ、認証要請メッセージ、決済確認メッセージ、決済予定メッセージ、入出金確認メッセージ、広告メッセージ、宅配関連メッセージ、スパムメッセージのうちいずれにも該当しない場合には、該当するメッセージを一般メッセージとして分類する。

一般メッセージの場合、送信者番号のタイプに応じて２つ以上の種類に分類されてもよいが、一例として、送信者番号が携帯電話の番号であるメッセージと、一般電話の番号であるメッセージとに区分してもよい。言い換えれば、一般メッセージとして分類された受信メッセージの場合は、送信者番号のタイプ（携帯電話番号、一般電話番号など）に応じて異なるフォーマットの通知ウィンドウが提供されてもよい。

図４を参照しながら説明したメッセージの種類は例示的なものに過ぎず、メッセージの構文解析によって分類可能なメッセージの種類をいくらでも追加して適用してもよい。メッセージの種類を判断する過程も例示的なものに過ぎず、事前に定義されたメッセージの種類に応じて追加の動作がさらに含まれてもよく、動作の順序や位置はいくらでも変更することができる。

提供部２１２は、受信メッセージに対する通知としてポップアップ形態の通知ウィンドウを提供するが、ここで、メッセージの種類に応じて通知ウィンドウのフレーム（またはテンプレート）とユーザインタフェース（アクションボタン）を区分して構成してもよい。

提供部２１２は、受信メッセージを加工し、受信メッセージの内容の少なくとも一部（以下、「メッセージ内容」と称する）を通知ウィンドウに表示するが、ここで、通知ウィンドウは、メッセージの種類とは関係なく、共通してメッセージ内容が最小長さ（例えば、１列）から最大長さ（例えば、４列）以内で表示され、メッセージ内容が最大長さを超える場合には、スクロールによって確認できるように構成されてもよい。また、通知ウィンドウは、通知ウィンドウに表示された本文領域であるメッセージ内容が選択された場合（例えば、タッチやクリックなど）には、受信メッセージの詳細ページにランディング（ｌａｎｄｉｎｇ）するように構成されてもよい。

通知ウィンドウには、メッセージ内容と共に、送信者情報が表示されてもよいが、ここで、送信者情報には、プロフィール画像、名前、電話番号のうち少なくとも１つが含まれてもよい。メッセージ送信者番号がユーザ端末の住所録に登録されている連絡先である場合には、住所録に格納されたイメージ、名前、番号などが利用されてもよく、メッセージ送信者番号が住所録に登録された連絡先でない場合には、アクセス可能なインターネット上のＤＢに格納されたイメージ、名前、番号などが利用されてもよい。

通知ウィンドウには、受信メッセージに対するユーザインタフェースとして少なくとも１つのアクションボタンが含まれてもよく、安心登録ボタン、削除ボタン、閉じるボタン、拒否ボタン、コピーボタン、返信ボタン、スケジュール登録ボタン、タグ追加ボタン、レポート表示ボタン、最近の内訳表示ボタンなどのアクションボタンが含まれるが、メッセージの種類に応じて通知ウィンドウのアクションボタンも柔軟に構成されてよい。

上述したアクションボタンは例えば、次のとおりとなる。

削除ボタンは、受信メッセージを直ぐに削除することのできる機能で構成される。

閉じるボタンは、受信メッセージを既読処理したり、該当するメッセージのバッジを１カウント差し引いたりする機能で構成される。

受信拒否ボタンは、受信メッセージを拒否して受信拒否メッセージ保管トレイに移動させると同時に、該当するメッセージの送信者番号を受信拒否ＤＢに追加する機能で構成される。

安心登録ボタンは、該当するメッセージの送信者電話番号とメッセージに含まれるリンク情報のうち少なくとも１つをスミッシング除外対象ＤＢに追加する機能で構成される。

コピーボタンは、受信メッセージの内容の少なくとも一部（例えば、認証番号）をクリップボードに自動格納する機能で構成される。

返信ボタンは、メッセージスレッドにランディングして定型文カードリストを提供し、定型文カードリストから選択されたメッセージを受信メッセージに対する返信として直ぐに送信する機能で構成される。

スケジュール登録ボタンは、受信メッセージと関連するスケジュールを登録するためにスケジュールアプリケーションを呼び出し、カレンダー選択画面およびスケジュール編集画面にランディングする機能で構成される。

タグ追加ボタンは、受信メッセージに位置情報や友達情報などの多様なタグを追加する機能で構成される。

レポート表示ボタンと最近の内訳表示ボタンは、受信メッセージが属するバンドル（ｂｕｎｄｌｅ）内のメッセージに基づいて累積された情報を提供する機能で構成される。ここで、バンドルとは、同じ主題や種類のメッセージ、あるいは同じ送信者のメッセージを分類する束の単位を意味する。

広告拒否ボタンは、受信メッセージを拒否して広告メッセージ保管トレイに移動させると同時に、該当するメッセージの送信者番号を受信拒否ＤＢに追加する機能で構成される。

メッセージ分類ボタンは、メッセージの種類を変更する機能で構成される。

配達状況照会ボタンは、受信メッセージに含まれたリンクを介して配達状況照会ページにランディングする機能で構成される。

リプレイボタンは、受信メッセージに対する通知を設定時間に再表示させる機能で構成される。例えば、メッセージの受信通知ウィンドウに構成されたリプレイボタンを選択した場合、３０分、１時間、２時間などのような時間リストが表示されるが、ここで、時間リストからユーザが特定の時間を選択すると、ユーザが選択した時間後に該当するメッセージに対する通知ウィンドウを再表示させるものである。リプレイボタンは、ユーザが選択した時間を周期として該当するメッセージに対する通知ウィンドウを繰り返し表示する機能を含んでもよい。

受信メッセージの通知ウィンドウは、メッセージの種類に応じて定められたボタンで構成されると説明しているが、これに限定されるものではなく、ユーザの設定によってユーザが望むボタンを選んで構成することもできる。

図５は、スミッシングメッセージの受信通知のためのスミッシングメッセージ通知ウィンドウ５００を示した図である。

図５を参照すれば、スミッシングメッセージ通知ウィンドウ５００には、メッセージ内容５０１と送信者情報とが含まれてもよい。ここで、送信者情報には、プロフィール画像５０２、名前５０３、電話番号５０４が含まれてもよく、スミッシングメッセージの場合には、プロフィール画像５０２にスミッシングの危険を知らせるイメージを適用してもよい。さらに、スミッシングメッセージ通知ウィンドウ５００には、スミッシングの注意を知らせる注意フレーズ５０５がさらに含まれてもよい。ここで、スミッシングメッセージをスミッシングメッセージとスミッシングである可能性があるメッセージとに区分し、互いに異なるフレーズを含む注意フレーズ５０５を表示してもよい。例えば、スミッシングメッセージの場合には「悪性コードなのでダウンロードしないでください！」のようなフレーズを、スミッシングである可能性があるメッセージの場合には「危険なファイルの可能性があるのでご注意ください」のようなフレーズを表示してもよい。

スミッシングメッセージ通知ウィンドウ５００には、スミッシングメッセージに対するユーザインタフェースとして、安心登録ボタン５１０、拒否ボタン５２０、閉じるボタン５３０などが含まれてもよい。ここで、安心登録ボタン５１０は、スミッシングメッセージとしての分類対象から除外することのできる機能で構成される。スミッシングメッセージ通知ウィンドウ５００で安心登録ボタン５１０が入力された場合、該当するメッセージの送信者電話番号とメッセージに含まれるリンク情報のうち少なくとも１つをスミッシング除外対象ＤＢに追加することにより、今後は同じ電話番号やリンク情報が含まれたメッセージがスミッシングメッセージとして分類されないようにしてもよい。

図６は、認証要請メッセージの受信通知のための認証メッセージ通知ウィンドウ６００を示した図である。

図６を参照すると、認証メッセージ通知ウィンドウ６００には、メッセージ内容６０１と共に、送信者情報が含まれてもよい。ここで、送信者情報には、プロフィール画像、名前、電話番号が含まれてもよく、認証要請メッセージの場合には、プロフィール画像に認証要請情報であることを知らせるイメージを適用してもよい。また、電話番号と名前とが含まれる別のＤＢが事前に定義されてもよく、該当するＤＢからメッセージ送信者番号に対応する名前を検索して送信者情報として表示してもよい。

メッセージ内容６０１には、認証要請メッセージの構文解析によって抽出された認証番号を強調して表示してもよい。認証番号が一定数（例えば、５桁）以上の数字である場合には、２つの束数に区分し、束数それぞれを互いに異なる色で表現してもよいが、ここで、認証番号が奇数である場合には、下桁の束数を１桁多く表現してもよい。

認証メッセージ通知ウィンドウ６００には、認証要請メッセージに対するユーザインタフェースとして、削除ボタン６１０、コピーボタン６２０、閉じるボタン６３０などが含まれてもよい。ここで、コピーボタン６２０は、メッセージ内容６０１に含まれた認証番号をコピーする機能で構成される。認証メッセージ通知ウィンドウ６００でコピーボタン６２０が入力された場合、認証要請メッセージで認証番号として構文解析された番号をクリップボードに自動コピーしてもよい。

図７は、決済確認メッセージの受信通知のための決済メッセージ通知ウィンドウ７００を示した図である。

図７を参照すると、決済メッセージ通知ウィンドウ７００には、メッセージ内容７０１と共に、送信者情報が含まれてもよい。ここで、送信者情報には、プロフィール画像、名前、電話番号が含まれてもよく、決済確認メッセージの場合には、プロフィール画像にカード会社のロゴを適用してもよい。また、電話番号とカード会社名／ロゴとが含まれる別のＤＢが事前に定義されてもよく、該当するＤＢからメッセージ送信者番号に対応するカード会社名とロゴを検索して送信者情報として表示してもよい。

メッセージ内容７０１は、決済確認メッセージを構文解析することで主要情報を含むようになった他のフォーマットで表示されてもよい。例えば、決済確認メッセージから決済金額、分割払い情報、使用先、累積金額などを抽出してメッセージ内容７０１を構成してもよく、特に、決済確認メッセージの構文解析によって抽出された決済金額を強調して表示してもよい。

決済メッセージ通知ウィンドウ７００には、決済確認メッセージに対するユーザインタフェースとしてレポートボタン７１０や閉じるボタン７２０などが含まれてもよい。ここで、レポートボタン７１０は、決済確認メッセージが属するバンドルに対する各種統計情報を提供するためのバンドル詳細ページにランディングする機能で構成される。例えば、決済メッセージ通知ウィンドウ７００でレポートボタン７１０が入力された場合、月別カード使用金額、カード会社別累積金額などを提供するためのバンドル詳細ページに移動してもよい。

図８は、入出金確認メッセージの受信通知のための入出金メッセージ通知ウィンドウ８００を示した図である。

図８を参照すると、入出金メッセージ通知ウィンドウ８００には、メッセージ内容８０１と共に、送信者情報が含まれてもよい。ここで、送信者情報には、プロフィール画像、名前、電話番号が含まれてもよく、入出金確認メッセージの場合には、プロフィール画像に銀行のロゴを適用してもよい。また、電話番号と銀行名／ロゴとが含まれる別のＤＢが事前に定義されてもよく、該当するＤＢからメッセージ送信者番号に対応する銀行名とロゴを検索して送信者情報として表示してもよい。

メッセージ内容８０１は、入出金確認メッセージを構文解析することで主要情報を含むようになった他のフォーマットで表示されてもよい。例えば、入出金確認メッセージから入出金金額、送金者／受信者、残額などを抽出してメッセージ内容８０１を構成してもよく、特に、入出金確認メッセージの構文解析によって抽出された入出金金額を強調して表示してもよい。

入出金メッセージ通知ウィンドウ８００には、入出金確認メッセージに対するユーザインタフェースとしてレポートボタン８１０や閉じるボタン８２０などが含まれてもよい。ここで、レポートボタン８１０は、入出金確認メッセージが属するバンドルに対する各種統計情報を提供するためのバンドル詳細ページにランディングする機能で構成される。例えば、入出金メッセージ通知ウィンドウ８００でレポートボタン８１０が入力された場合、月別取引金額（入出金合計金額）、銀行別取引金額（入出金合計金額）と残高などを提供するためのバンドル詳細ページに移動してもよい。

このように、金融会社の場合には、取引の種類に応じてカード会社と銀行とに分類され、カード社の場合には、クレジットカード、法人カード、デビットカードなどに分類されてもよいが、これに応じて金融会社から受信したメッセージを取引の種類に対応するフォーマットに加工して通知ウィンドウを構成してもよい。クレジット／法人カードの場合には、使用先、決済金額、決済種類（一括払い／分割払い）、累積金額（または利用限度残額）、詳細カード名などが表示され、デビットカードの場合には、使用先、決済金額、決済種類、残額（利用限度残額）、詳細カード名などが表示され、銀行の場合には、取引の種類（入金／出金／出金取消）、使用先、取引金額、残高などが表示されてもよい。

メッセージ送信者番号が金融会社電話番号ＤＢには存在するが、メッセージのテキストがカード決済内訳または銀行入出金内訳を含まない場合には、一般メッセージとして分類されてもよい。金融会社から受信したメッセージのうち告示事項や決済予定金額などを内容とする一般メッセージの場合は、図９に示すように、メッセージの受信通知ウィンドウ９００には、受信メッセージに対するユーザインタフェースとしてメッセージ分類ボタン９１０、スケジュール登録ボタン９２０、閉じるボタン９３０などが含まれてもよい。ここで、メッセージ分類ボタン９１０は、メッセージの種類を変更する機能で構成されるものであって、これによって受信メッセージが一般メッセージではなく、決済確認メッセージまたは入出金確認メッセージとして分類されるようにしてもよい。スケジュール登録ボタン９２０は、受信メッセージと関連するスケジュールを登録するためにスケジュールアプリケーションを呼び出し、カレンダー選択画面およびスケジュール編集画面にランディングする機能で構成される。

ここでは、決済予定金額が含まれたメッセージを一般メッセージとして分類すると説明しているが、図４を参照しながら説明したように、決済予定金額が含まれたメッセージを一般メッセージではなく、決済予定メッセージとして分類してもよい。このような場合、メッセージ通知ウィンドウには、決済確認メッセージや入出金確認メッセージと同じように、レポートボタンや閉じるボタンなどが含まれたユーザインタフェースが構成されてもよい。

図１０は、一般メッセージの受信通知のための一般メッセージ通知ウィンドウ１０００を示した図である。

図１０を参照すると、一般メッセージ通知ウィンドウ１０００には、メッセージ内容１００１と共に、送信者情報が含まれてもよい。ここで、送信者情報には、プロフィール画像、名前、電話番号が含まれてもよい。メッセージ送信者番号が住所録に登録されている連絡先である場合には、住所録に格納されているイメージ、名前、番号などを利用して送信者情報を表示してもよく、メッセージ送信者番号が住所録に登録された連絡先でない場合には、アクセス可能なインターネット上のＤＢに格納されているイメージ、名前、番号などを利用して送信者情報を表示してもよい。

メッセージ内容１００１には、受信メッセージを加工してメッセージに含まれた本文の内容の少なくとも一部が表示されてもよい。

一般メッセージ通知ウィンドウ１０００には、一般メッセージに対するユーザインタフェースとして、返信ボタン１０１０、スケジュール登録ボタン１０２０、閉じるボタン１０３０、ブックマークボタン１０４０などが含まれてもよい。

スケジュール登録ボタン１０２０は、受信メッセージと関連するスケジュールを登録するためにスケジュールアプリケーションを呼び出し、カレンダー選択画面およびスケジュール編集画面にランディングする機能で構成される。一般メッセージ通知ウィンドウ１０００でスケジュール登録ボタン１０２０が入力された場合、受信メッセージを構文解析した内容がスケジュールの入力要素（例えば、スケジュール名、日付、場所など）として自動入力されてもよい。例えば、メッセージの題目がスケジュール名として指定されるようにスケジュールアプリケーションに入力されてもよく、メッセージのテキストに特定の日付が含まれている場合、該当する日付が、日付区間が含まれている場合には「〜」や、「から」、「まで」などで表現された内容のうち最終となる日付が、日付情報としてスケジュールアプリケーションに入力されてもよい。日付が含まれていない場合にはメッセージ受信日がスケジュール登録日として指定されるように、スケジュールアプリケーションに入力されてもよい。

ブックマークボタン１０４０は、受信メッセージにブックマークを設定することで重要メッセージとして分類される機能で構成される。一般メッセージ通知ウィンドウ１０００でブックマークボタン１０４０が入力された場合、タイムラインに登録され、メッセージ保管トレイなどのメッセージリストでは該当するメッセージに重要アイコン（例えば、星）が表示されてもよい。重要メッセージはユーザがブックマークを設定したメッセージであり、ブックマーク設定されたメッセージを重要メッセージとして分類することができる。

返信ボタン１０１０は、定型文カードリストを提供し、定型文カードリストから選択されたメッセージを受信メッセージに対する返信としてすぐに送信する機能で構成される。ここで、定型文カードリストは、サービス上で任意登録しておいたフレーズで構成されてもよいし、他の一例としては、ユーザが送信したメッセージを読み取り、ユーザがよく使うフレーズを自動的に選定および登録して定型文カードリストとして提供してもよい。一般メッセージ通知ウィンドウ１０００で返信ボタン１０１０が入力された場合、図１１に示すように、定型文カードリスト１１００がポップアップによって表示されてもよく、定型文カードリスト１１００から１つのカードが選択されると、該当するカードの定型文が受信メッセージの返信として送信されてもよい。定型文カードが１つである場合には、定型文カードリスト１１００のポップアップ過程はなく、１つのカードに定められたフレーズが受信メッセージの返信としてすぐに送信されてもよい。ここで、定型文カードリスト１１００は、デフォルト設定されてもよいし、ユーザによって入力された定型文で構成されてもよい。

一般メッセージの場合、送信者番号のタイプ（携帯電話番号や一般電話番号など）によって異なるフォーマットの通知ウィンドウを提供してもよい。受信メッセージの送信者番号が携帯電話番号である場合には、上述したように、一般メッセージ通知ウィンドウ１０００に返信ボタン１０１０が含まれるように構成してもよく、受信メッセージの送信者番号が一般電話番号（例えば、有線電話番号など）である場合には、メッセージを返信することができないため、一般メッセージ通知ウィンドウ１０００には、返信ボタン１０１０の代わりにリプレイボタンが含まれるように構成されてもよい。リプレイボタンは、受信メッセージに対する通知を設定時間に再表示させたり、設定時間を周期として繰り返し表示させたりする機能によって構成される。例えば、一般メッセージ通知ウィンドウ１０００でリプレイボタンが選択された場合、３０分、１時間、２時間などの時間リストが表示されるが、ここで、時間リストからユーザが特定の時間を選択すると、ユーザが選択した時間後に該当するメッセージに対する通知ウィンドウ１０００を再表示してもよい。

例示的な図面は省略したが、広告メッセージに対応する通知ウィンドウには広告拒否ボタンが含まれ、スパムメッセージに対応する通知ウィンドウには拒否ボタンが含まれてもよい。ここで、広告メッセージに対応する通知ウィンドウの広告拒否ボタンは、受信メッセージを拒否して広告メッセージ保管トレイに移動させると同時に、該当するメッセージの送信者番号を受信拒否ＤＢに追加する機能で構成される。スパムメッセージに対応する通知ウィンドウの拒否ボタンは、受信メッセージを拒否して受信拒否メッセージ保管トレイに移動させると同時に、該当するメッセージの送信者番号を受信拒否ＤＢに追加する機能で構成される。さらに、宅配関連メッセージに対応する通知ウィンドウには配達状況照会ボタンが含まれてもよい。ここで、配達状況照会ボタンは、受信メッセージに含まれたリンクを介して配達状況照会ページにランディングする機能で構成される。また、宅配関連メッセージの送信者番号が携帯電話番号である場合には、通知ウィンドウに返信ボタンが含まれてもよい。返信ボタンは、定型文カードリストを提供し、定型文カードリストから選択されたメッセージを宅配関連メッセージに対する返信としてすぐに送信する機能で構成される。宅配用の返信ための定型文カードリストは、宅配員との対話によってやり取りすることのできるフレーズ（例えば、「管理室に預けてください」、「ベルは押さずにノックしてください」など）で構成されてもよく、このようなフレーズは、サービス上で事前登録されたフレーズであってもよいし、ユーザの設定によって任意登録されたフレーズであってもよい。

上述したように、受信メッセージに対する通知ウィンドウは、メッセージの種類に応じてフレームとアクションボタンを異なるように構成することができる。受信メッセージの種類によって通知ウィンドウのフレームとアクションボタンを異なるように構成することによって、ユーザがメッセージの種類を容易に区別することができ、メッセージに関連度が高い機能やアクションに容易にアクセスすることができる。

図１２を参照すると、提供部２１２は、ユーザ端末に新たにメッセージが受信されると、受信したメッセージの種類に対応するフレームとアクションボタンで構成された通知ウィンドウ１２００をユーザ端末の画面１２上にポップアップ形態で表示してもよい。

ユーザがまだメッセージを確認できずにメッセージの受信通知が累積した場合には、図１３に示すように、ユーザ端末の画面１３上にはメッセージの受信通知ウィンドウ１３００が重畳されて表示されてもよい。ここで、最近受信したメッセージの通知ウィンドウが一番手前に表示され、一番手前に表示された通知ウィンドウに対してアクション入力が可能となるように構成されてもよい。

メッセージの受信通知ウィンドウ１３００が重畳されてポップアップに表示された状態でユーザ端末のホームボタンやバックボタンが選択されたとき、メッセージの受信通知ウィンドウ１３００はすべて閉じるが、このような場合に、受信メッセージは未読の状態が維持され、メッセージのバッジカウントも変化のないまま処理されてもよい。

図１４は、メッセージ保管トレイと関連するユーザ端末画面１４を示した図である。

図１４に示すように、ユーザ端末画面１４では、メッセージ保管トレイに格納されたメッセージを一定の基準（例えば、時間順）にしたがって整列して表示してもよい。ここで、ユーザ端末画面１４の一端（例えば、画面上端）には、受信メッセージに対する通知情報としてバナー形態の通知メッセージ（以下、「通知バナー」と称する）１４００が表示されてもよい。

一例として、通知バナー１４００は、受信メッセージに対して送信者情報（プロフィール画像、名前、電話番号など）とメッセージ内容のうち少なくとも１つを含んで１行で構成された後にユーザ端末画面１４上に表示されてもよいし、通知バナー１４００はメッセージの長さに応じてスクロール方式でユーザ端末画面１４に表示されてもよい。

通知バナー１４００も、メッセージの種類に応じて区分されたフレームを適用してもよく（例えば、メッセージの種類に応じてバナーの色を異にする）、メッセージに含まれた題目、本文、添付ファイルなどに応じて異なるフォーマットで構成されてもよい。

図１５は、通知センターと関連するユーザ端末画面１５を示した図である。

図１５に示すように、ユーザ端末画面１５は、メッセージ保管トレイとは別の受信メッセージの通知情報を管理するための場所として、ポップアップやバナーなどの形態でメッセージの受信通知を提供したメッセージのうち既読処理されていない受信メッセージの通知情報１５００を別に集め、一定の基準（例えば、時間順）にしたがって整列して表示してもよい。

一例として、通知情報１５００は、受信メッセージそれぞれに対してカード形態で構成され、送信者情報（プロフィール画像、名前、電話番号）とメッセージ内容のうち少なくとも１つを含んで定められたフォーマットによって構成された後、ユーザ端末画面１５上にカードリストによって表示されてもよい。

通知情報１５００も、メッセージの種類に応じて区分されたカードを適用してもよく（例えば、メッセージの種類に応じてカードの色を異にする）、メッセージに含まれた題目、本文、添付ファイルなどに応じて異なるフォーマットで構成してもよい。

ユーザ端末画面１５から特定のメッセージの通知情報１５００を選択した場合、該当するメッセージカードが拡張されながら、拡張されたカード上にメッセージの全文を最大まで表示し、メッセージの種類に対応するアクションボタンを表示してもよい。

例えば、図１６に示すように、認証要請メッセージとして分類されたメッセージ１６０１の場合には、カードが拡張されるときに受信メッセージで構文解析された主要内容が表示されてもよく、特に、アクションボタンとしては、受信メッセージを既読処理するための閉じるボタンや、メッセージに含まれた認証番号をクリップボードにコピーするためのコピーボタンなどが含まれてもよい。さらに、一般メッセージとして分類されたメッセージ１６０２の場合には、カードが拡張されるときにメッセージの全文を最大限表示し、アクションボタンとしては、受信メッセージを既読処理するための閉じるボタンや、定型文を利用した返信を送信するための返信ボタンなどが含まれてもよい。

上述したように、通知バナーや通知センターを利用したメッセージの受信通知時にも、メッセージの種類に応じて区分された通知情報を生成および提供することができる。通知バナーや通知センターを用いたメッセージ受信通知時にも、メッセージの種類に応じて区分された通知情報を提供することによって、様々な通知環境をユーザに提供することができ、ユーザがメッセージの種類を容易に区別することができる。

図１７から図１９は、本発明の一実施形態における、受信メッセージと関連する追加情報を提供するユーザ端末画面の一例を示した図である。

提供部２１２は、ユーザ端末に新たなメッセージが受信されると、受信したメッセージの種類に対応するフレームとアクションボタンとで構成された通知ウィンドウをポップアップ形態で表示してもよいが、このとき、通知ウィンドウと隣接する少なくとも１つの位置に、受信メッセージと関連する追加情報を表示してもよい。例えば、受信メッセージが決済確認メッセージである場合に、図１７に示すように、提供部２１２は、受信メッセージ通知ウィンドウ１７００をユーザ端末の画面１７上に表示するときに、受信メッセージ通知ウィンドウ１７００の下端に、集計期間中のカード使用金額の合計を含む情報ウィンドウ１７１０を表示してもよい。他の一例として、提供部２１２は、図１８に示すように、受信メッセージ通知ウィンドウ１８００の下端に、カード使用先と関連するイベント案内を含む情報ウィンドウ１８２０を表示してもよい。さらに他の一例として、提供部２１２は、図１９に示すように、受信メッセージ通知ウィンドウ１８００の下端に、カード使用先との取引履歴（決済履歴）を含む情報ウィンドウ１９３０を表示してもよい。

言い換えれば、提供部２１２は、受信メッセージに対する通知ウィンドウと共に、受信メッセージと関連する追加情報を提供してもよい。追加情報を含む情報ウィンドウにも、メッセージの種類に応じて区分された内容が提供されてもよいが、ここで、情報ウィンドウに提供される追加情報は、サービス上で事前に定められてもよいし、ユーザ設定によってメッセージ種類別にユーザが望む情報を提供してもよい。

したがって、本発明に係るメッセージの受信通知方法は、受信メッセージの種類に応じて区分された通知ウィンドウを提供することにより、メッセージに見合った通知環境を提供することができ、メッセージ受信をより効果的に知らせることができる。

上述したメッセージの受信通知方法は、図１から図１９を参照しながら説明したメッセージの受信通知システムの詳細内容に基づき、より短縮された動作または追加された動作を含んでもよい。また、２つ以上の動作が組み合わされてもよく、動作の順序や位置は変更されてもよい。

図５から図１９は、発明の理解を助ける、説明の便宜のための例示的な画面に過ぎず、画面の構成や順序などはいくらでも変更が可能である。

図２０は、本発明の一実施形態における、コンピュータシステムの内部構成の一例を説明するためのブロック図である。

コンピュータシステム２０００は、少なくとも１つのプロセッサ２０１０、メモリ２０２０、周辺装置インタフェース（ｐｅｒｉｐｈｅｒａｌ ｉｎｔｅｒｆａｃｅ）２０３０、入力／出力サブシステム（Ｉ／Ｏ ｓｕｂｓｙｓｔｅｍ）２０４０、電力回路２０５０、および通信回路２０６０を備えてよい。ここで、コンピュータシステム２０００は、ユーザ端末に該当してもよい。

メモリ２０２０は、一例として、高速ＲＡＭ、磁気ディスク、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ、フラッシュメモリ、または不揮発性メモリを含んでもよい。メモリ２０２０は、コンピュータシステム２０００の動作に必要なソフトウェアモジュール、命令語集合、またはその他にも多様なデータを含んでもよい。ここで、プロセッサ２０１０や周辺装置インタフェース２０３０などの他のコンポーネントからメモリ２０２０へのアクセスは、プロセッサ２０１０によって制御されてもよい。

周辺装置インタフェース２０３０は、コンピュータシステム２０００の入力周辺装置および／または出力周辺装置をプロセッサ２０１０およびメモリ２０２０に接続させてもよい。プロセッサ２０１０は、メモリ２０２０に格納されたソフトウェアモジュールまたは命令語集合を実行し、コンピュータシステム２０００のための多様な機能を実行してデータを処理してもよい。

入力／出力サブシステム２０４０は、多様な入力／出力周辺装置を周辺装置インタフェース２０３０に接続させてもよい。例えば、入力／出力サブシステム２０４０は、モニタやキーボード、マウス、プリンタ、または必要に応じてタッチスクリーンやセンサなどの周辺装置を周辺装置インタフェース２０３０に接続させるためのコントローラを含んでもよい。他の側面によると、入力／出力周辺装置は、入力／出力サブシステム２０４０を介さずに周辺装置インタフェース２０３０に接続されてもよい。

電力回路２０５０は、ユーザ端末のコンポーネントの全部または一部に電力を供給してもよい。例えば、電力回路２０５０は、電力管理システム、バッテリや交流（ＡＣ）などのような１つ以上の電源、充電システム、停電検出回路（ｐｏｗｅｒ ｆａｉｌｕｒｅ ｄｅｔｅｃｔｉｏｎ ｃｉｒｃｕｉｔ）、電力変換器やインバータ、電力状態表示子、または電力生成、管理、分配のための任意の他のコンポーネントを含んでもよい。

通信回路２０６０は、少なくとも１つの外部ポートを利用して他のコンピュータシステムとの通信を可能にしてもよい。または、上述したように、必要に応じて、通信回路２０６０はＲＦ回路を含み、電磁信号（ｅｌｅｃｔｒｏｍａｇｎｅｔｉｃ ｓｉｇｎａｌ）とも知られているＲＦ信号を送受信することにより、他のコンピュータシステムとの通信を可能にしてもよい。

このような図２０の実施形態は、コンピュータシステム２０００の一例に過ぎず、コンピュータシステム２０００は、図２０に示されたコンポーネントの一部が除去されてもよいし、図２０には示されていない追加のコンポーネントをさらに備えてもよいし、２つ以上のコンポーネントを接続させる構成または配置を有してもよい。例えば、モバイル環境の通信端末のためのコンピュータシステムは、図２０に示されたコンポーネントの他にも、タッチスクリーンやセンサなどをさらに備えてもよく、通信回路２０６０には、多様な通信方式（ＷｉＦｉ（登録商標）、３Ｇ、ＬＴＥ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ、Ｚｉｇｂｅｅ（登録商標）など）のＲＦ通信のための回路が備えられてもよい。コンピュータシステム２０００に含めることができるコンポーネントは、１つ以上の信号処理またはアプリケーションに特化した集積回路を含むハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせによって実現されてもよい。

このように、本発明の実施形態によると、受信メッセージの種類に応じて区分された通知ウィンドウを提供することにより、メッセージに見合った通知環境を提供することができ、メッセージ受信をより効果的に知らせることができる。また、本発明の実施形態によると、メッセージの内容によって予測可能なユーザアクションを考慮した上で通知ウィンドウに含まれるユーザインタフェースを提供することにより、メッセージに応じてユーザインタフェースを柔軟に構成することができ、メッセージ別に関連する機能へのアクセス性を向上させることができる。

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてもよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてもよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してもよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、所望するとおりに動作するように処理装置を構成したり、独立的または集合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置に命令したりしてもよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、ある種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｎｔ）、コンピュータ格納媒体または装置、または送信される信号波（ｓｉｇｎａｌ ｗａｖｅ）に永久的または一時的に具現化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された態様で格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでもよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の一例としては、ハードディスク、フロッピー（登録商標）ディスク、磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の一例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして動作するように構成されてもよく、その逆も同じである。

以上のように、実施形態を、限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能である。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で接続されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

１００：メッセージの受信通知システム
２１１：判断部
２１２：提供部

Claims (24)

1. コンピュータによって実現されるメッセージの受信通知方法であって、
   メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレーム、および前記複数のメッセージの種類とユーザインタフェースボタンを予め定義することにより、
   ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信したメッセージに対応する種類を判断すること、
   前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決めること、
   前記受信したメッセージの種類に対応するユーザインタフェースボタンを決めること、および
   前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージの種類に応じてユーザインタフェースボタンの構成が異なる通知ウィンドウを生成および提供すること
   を含む、メッセージの受信通知方法。
2. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   前記ユーザインタフェースボタンから他のアプリケーションと連動して他の機能にアクセスすることのできる通知ウィンドウを生成すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
3. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   前記ユーザインタフェースボタンから他のアプリケーションとイン−アプリ形態で連動して他の機能にアクセスすることのできる通知ウィンドウを生成すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
4. 前記メッセージを区分するための複数のメッセージの種類は、
   メッセージにファイルダウンロードのためのリンク情報が含まれるか、メッセージを通じてダウンロードされるファイルが悪性コードＤＢに含まれるか、メッセージに認証番号あるいは承認番号が含まれるか、メッセージの送信者情報が金融会社電話番号ＤＢに含まれるか、メッセージのテキストにカード決済内訳が含まれるか、メッセージのテキストに決済予定情報が含まれるか、メッセージのテキストに銀行入出金内訳が含まれるか、またはメッセージのテキストに事前に定義されたフレーズやキーワードが含まれるかのうち少なくとも１つの基準を利用して定義されること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
5. 前記メッセージを区分するための種類別通知ウィンドウのフレームは、
   メッセージの種類別にフレームの表示属性が定義されること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
6. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   前記受信したメッセージに対応する種類に応じてフレームの表示属性が異なる通知ウィンドウを生成すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
7. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   メッセージと関連するスケジュールを登録するためのスケジュール機能または通知ウィンドウから直接返信するための返信機能のうち少なくとも１つの機能と連動する通知ウィンドウを生成すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
8. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   前記ユーザインタフェースボタンをメッセージに対応する種類に応じて、メッセージを削除する機能のボタン、メッセージを既読処理する機能のボタン、メッセージを受信拒否データベースに追加する機能のボタン、メッセージをスミッシング除外対象データベースに追加する機能のボタン、メッセージの内容の少なくとも一部をコピーする機能のボタン、定型文を利用して返信する機能のボタン、メッセージと関連するスケジュールを登録する機能のボタン、メッセージにタグを追加する機能のボタン、メッセージと関連する累積情報若しくは統計情報を提供する機能のボタン、メッセージの種類を変更する機能のボタン、メッセージに含まれたリンクを介して配達状況照会ページにランディングする機能のボタン、またはメッセージに対する通知ウィンドウを再表示する時間若しくは繰り返し表示する周期を設定する機能のボタンのうち少なくとも１つで構成すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
9. 前記受信したメッセージに対する通知ウィンドウを生成および提供することは、
   前記ユーザ端末に新たなメッセージが受信されると、前記新たなメッセージに対する通知ウィンドウをポップアップ形態で前記ユーザ端末の画面上に提供すること
   を特徴とする、請求項１に記載のメッセージの受信通知方法。
10. 前記メッセージ受信通知方法は、
    前記受信したメッセージに対する通知情報をバナー形態で提供すること
    をさらに含む、請求項１に記載のメッセージの受信通知方法。
11. 前記受信したメッセージに対する通知情報をバナー形態で提供することは、
    前記ユーザ端末と関連するメッセージ保管トレイのメッセージリストが表示されたユーザ端末画面の一端に通知バナーを表示すること
    を特徴とする、請求項１０に記載のメッセージの受信通知方法。
12. 前記メッセージ受信通知方法は、
    前記受信したメッセージに対する通知情報をカードリストで構成した通知センターを提供すること
    をさらに含む、請求項１に記載のメッセージの受信通知方法。
13. 前記通知センターを提供することは、
    前記ユーザ端末と関連するメッセージ保管トレイに格納されたメッセージのうち既読処理されていない受信メッセージに対し、メッセージの種類に応じて表示属性が異なるカードでカードリストを構成すること
    を特徴とする、請求項１２に記載のメッセージの受信通知方法。
14. 前記メッセージの受信通知方法は、
    前記通知ウィンドウと隣接する少なくとも１つの位置に、前記受信したメッセージと関連する追加情報を提供すること
    をさらに含む、請求項１に記載のメッセージの受信通知方法。
15. メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレーム、および前記複数のメッセージの種類とユーザインタフェースボタンを予め定義することにより、
    ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信したメッセージに対応する種類を判断すること、
    前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決めること、
    前記受信したメッセージの種類に対応するユーザインタフェースボタンを決めること、および
    前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージの種類に応じてユーザインタフェースボタンの構成が異なる通知ウィンドウを生成および提供すること
    をコンピュータによって実行させるためのコンピュータプログラム。
16. メッセージを区分するための複数のメッセージの種類と種類別通知ウィンドウのフレーム、および前記複数のメッセージの種類とユーザインタフェースボタンを予め定義することにより、
    ユーザ端末が受信したメッセージを構文解析して前記複数のメッセージの種類のうち前記受信したメッセージに対応する種類を判断する判断部、および
    前記種類別通知ウィンドウのフレームのうち前記受信したメッセージの種類に対応するフレームを決め、前記受信したメッセージの種類に対応するユーザインタフェースボタンを決めた後、前記受信したメッセージの種類に対応するフレームにしたがって前記受信したメッセージを加工し、前記受信したメッセージの種類に応じてユーザインタフェースボタンの構成が異なる通知ウィンドウを生成および提供する提供部
    を備える、メッセージの受信通知システム。
17. 前記メッセージを区分するための複数のメッセージの種類は、
    メッセージにファイルダウンロードのためのリンク情報が含まれるか、メッセージを通じてダウンロードされるファイルが悪性コードＤＢに含まれるか、メッセージに認証番号あるいは承認番号が含まれるか、メッセージの送信者情報が金融会社電話番号ＤＢに含まれるか、メッセージのテキストにカード決済内訳が含まれるか、メッセージのテキストに決済予定情報が含まれるか、メッセージのテキストに銀行入出金内訳が含まれるか、またはメッセージのテキストに事前に定義されたフレーズやキーワードが含まれるかのうち少なくとも１つの基準を利用して定義されること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
18. 前記提供部は、
    前記受信したメッセージに対応する種類に応じてフレームの表示属性が異なる通知ウィンドウを生成すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
19. 前記提供部は、
    前記ユーザインタフェースボタンから他のアプリケーションと連動して他の機能にアクセスすることのできる通知ウィンドウを生成すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
20. 前記提供部は、
    メッセージと関連するスケジュールを登録するためのスケジュール機能または通知ウィンドウから直接返信するための返信機能のうち少なくとも１つの機能と連動する通知ウィンドウを生成すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
21. 前記提供部は、
    前記ユーザ端末に新たなメッセージが受信されると、前記新たなメッセージに対する通知ウィンドウをポップアップ形態で前記ユーザ端末の画面上に提供すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
22. 前記提供部は、
    前記受信したメッセージに対する通知情報をバナー形態で提供し、前記ユーザ端末と関連するメッセージ保管トレイのメッセージリストが表示されたユーザ端末画面の一端に通知バナーを表示すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
23. 前記提供部は、
    前記受信したメッセージに対する通知情報をカードリストで構成した通知センターを提供し、前記ユーザ端末と関連するメッセージ保管トレイに格納されたメッセージのうち既読処理されていない受信メッセージに対し、メッセージの種類に応じて表示属性が異なるカードでカードリストを構成すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。
24. 前記提供部は、
    前記通知ウィンドウと隣接する少なくとも１つの位置に、前記受信したメッセージと関連する追加情報を提供すること
    を特徴とする、請求項１６に記載のメッセージの受信通知システム。