JP2012501138A

JP2012501138A - 異種フォーマットの通知を自動的に管理する方法およびシステム

Info

Publication number: JP2012501138A
Application number: JP2011524436A
Authority: JP
Inventors: デュポン，マリー−パスカル; ベートゲ−ブレゼッツ，ステファン; カムガ，ガイ−ベルトランド; ピエカレック，ソフィー; ヴァーノル，アルノー
Original assignee: アルカテル−ルーセント
Priority date: 2008-08-29
Filing date: 2009-08-26
Publication date: 2012-01-12
Also published as: EP2159746A1; FR2935506A1; FR2935506B1; US20100056112A1; WO2010023409A1; CN102132298A; KR20110050471A

Abstract

ユーザ通知を受信する、または生成する、ならびに表示することができる移動端末（１０）内で、異種フォーマットのこれらの通知を自動的に管理する方法が、以下のステップを含む。移動端末によって受信される、または生成される各通知を、単一のフォーマットのメタデータに変換するステップ、前記変換をデータベース（２）内に保存するステップ、ユーザによってあらかじめ設定された優先度基準の組合せに基づいて、前記通知の優先度を評価するステップ、既に保存されている他の変換された通知と比較したその優先度に基づいて、前記通知を収容するデータベース（２）を再編成するステップ、その優先度に基づいて、通知を端末（１０）に表示するステップ。

Description

本発明は、電気通信の技術分野に関する。その目的は、移動端末によって受信される通知を自動的に管理するための方法およびシステムである。

詳細には、本発明は、さまざまなサービスおよびさまざまなアプリケーションにより送信される、移動電話のユーザに宛てられたユーザ通知に関する。限定しない例として、それらはとりわけ、ショートＳＭＳ（ショート・メッセージサービス）メッセージ、もしくはＭＭＳ（マルチメディア・メッセージサービス）メッセージ形式の通知、あるいは、移動端末内のアプリケーションによって送信され、電子メールを送信および／または受信するように構成されて、ユーザに、新たなテキストメッセージもしくは音声メッセージの着信、または不在着信を通知する通知、カレンダーメモ、ローカルネットワークからの情報メモもしくはアラート、特定のタスク（アカウントの再読み込み、サービスへの申し込み）の確認／要求、その他を含むことができる。

これらの通知は、対話型の、すなわち特定の情報の送信を要求してよい、または情報提供する（たとえば、特定のタスクを実行するためのアラートまたはリマインダの形式の）通知であってよい。さらに、それらは一般的には、性質上揮発性であり、移動端末のユーザにとって、重要度または緊急度の異なるレベルの通知であってよい。

しかしながら、現在使用されている技術は、異なるタイプの通知の自動的な管理をサポートしないという欠点を有する。したがって、複数の通知を同時に受信したとき、移動端末のユーザは、あらかじめ通知の優先度の程度がわからなくても、すべての通知を次々とチェックすることを求められる。というのは、優先度の程度は、通知のコンテンツを見た後でしか決定できないからである。これはかなりの時間を必要とし、意思決定を遅らせることがある。加えて、ユーザは、確実に通知にアクセスできなければならない。そうでなければ、ユーザは、同時に受信した通知の１つまたは複数を、誤って削除、または紛失しかねない。

ユーザ通知を管理するためのいくつかの方法およびシステムが知られている。さらに、これらのシステムは、非常に特定的である。それらは主に、統一されたやり方において異なるタイプの通知の取扱いを可能にすることなく、いくつかの特殊なアラートを扱う。

文献、米国特許第６３９６５１３号は、たとえば、受信箱のユーザによってあらかじめ設定された基準に基づいて、着信メールをソートするためのシステムを記述している。

近年、ＶｅｒｉｚｏｎＷｉｒｅｌｅｓｓ（社名）によって導入され、Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ（社名）およびＣｏｍｖｅｒｓｅ（社名）によって制作されたソリューション、ＶｉｓｕａｌＶｏｉｃｅＭａｉｌ（商標）は、音声メッセージの管理を専用とする。それは、優先度規則の事前構成なしに、対話型のグラフィカル・インターフェースにおいて、移動端末によって受信される音声メッセージのリストを表示することを可能にする。

文献、米国特許第７３５９９３６号は、受信箱に入るメールをカテゴライズすることを可能にする、メール・エージェントシステムを記述している。このカテゴリ化は、メールの基本的な識別子（送信元、日付、件名、サイズ、その他）、およびメール・コンテンツの文字カウントから取得される一組のキーワードを含む、着信メールのプレビューに基づく。この後者の機能は、ＩＢＭコーポレーション（社名）によって制作された、ＩｎｔｅｌｌｉｇｅｎｔＭｉｎｅｒｆｏｒＴｅｘｔ（商標）などの市販製品を使用して実装することができる。カテゴリ化の結果として、グラフィカル・インターフェース・システムが、受信箱のユーザによりあらかじめ設定されたオプションに基づいた項目を提示することを可能にする。

移動端末向けの通知は、ますます頻繁になっていることが認められている。さらに、通知は、異種の範囲にわたるチャネルおよびサービス、すなわち、電話メッセージング・サービス（ＳＭＳ／ＭＭＳ：広告通知、サービス通知、電話プロバイダ通知、その他）、地理位置情報サービス、電子メールサービス、移動端末に組み込まれるサービス（カレンダ、リマインダ、その他）、特定の環境のＷＬＡＮ（ワイヤレス・ローカルエリア・ネットワーク）によってサポートされる通知サービス（病院のＷＬＡＮ：医療スタッフアラート、交通機関サービスのＷＬＡＮ：旅客のための通知、ショッピングセンターのＷＬＡＮ：顧客のための通知、その他）を介して、端末に着信する。

知られているシステムおよび方法は、とりわけ、カスタマイズ可能にできる重要度および緊急度の基準に基づいて、ユーザがこれらの通知を均一化し、ひいてはインテリジェントに編成するのを可能にすることになる、移動端末によって受信される通知のすべてを包括的に管理するやり方が欠如しているために、不完全である。

米国特許第６３９６５１３号明細書米国特許第７３５９９３６号明細書

本発明の１つの目的は、前述した欠点を改善することである。詳細には、本発明は、通知のソースまたは発信源にかかわらず、移動端末によって受信されるユーザ通知を管理する（とりわけ、受信する、保存する、チェックする）ための、普遍的な方法およびシステムを開示することを狙いとする。

その目的のために、本発明は、第１の態様に従って、ユーザ通知を受信する、または生成する、ならびに表示することが可能な移動端末内で、異種フォーマットのこれらの通知を自動的に管理するための方法を開示し、方法は以下のステップを含む。
− 移動端末によって受信される、または生成される各通知を、単一のメタデータ・フォーマットに変換するステップ、
− 前記変換をデータベース内に保存するステップ、
− ユーザによってあらかじめ設定された優先度基準に基づいて、前記通知の優先度を評価するステップ、
− 既に保存されている他の変換された通知と比較したその優先度に基づいて、前記通知を収容するデータベースを再編成するステップ、
− その優先度に基づいて、通知を端末に表示するステップ。

第２の態様に従って、本発明は、ユーザ通知を受信する、または生成する、ならびに表示することが可能な移動端末内で、異種フォーマットのこれらの通知を自動的に管理するためのシステムを開示し、前記システムは以下を含む。
− 前記移動端末によって受信される、または生成される各通知を、単一のフォーマットのメタデータに変換することが可能な、通知受信モジュール、
− 変換を保存するためのデータベース、
− ユーザによってあらかじめ設定された優先度基準に基づいて、各通知の優先度を評価するためのモジュール、
− データベースに保存された通知のそれぞれの優先度に基づいて、データベースを編成するためのモジュール、
− それらの優先度に基づいて、通知を表示するための対話型グラフィカル・モジュール。

本発明は、通知のソースおよびフォーマットに依存しない、移動端末によって受信される通知の、インテリジェントな自動管理を可能にする。詳細には、本発明は、移動端末のユーザによって設定された基準を使用することで、他の通知と比較した各通知の優先度をよりよく定義することを可能にする。非限定の例として、優先度基準は、通知の重要度、通知のソース、通知の緊急度、通知の存続期間、通知がどのくらいの頻度で現れるか、通知のコンテンツ、その他の中から選択することができる。

さらに、本発明は、通知の優先度を計算するために、移動端末のユーザの規則およびプロファイルのインテリジェントな組合せを可能にする。

本発明は、とりわけ、移動端末がそのユーザの注意を頻繁に要求する環境に適用されてよい。

本発明の他の特性および利点は、本方法の好ましいさまざまな実装、およびシステムの実施形態の以下の説明を、添付の図面を参照して読む際に、より明瞭かつ十分に明らかとなるであろう。

本発明の応用コンテキストを概略的に示す図である。システムのさまざまなモジュール間の関係を示しながら、本発明の方法のさまざまなステップを示す図である。

ユーザ通知を自動的に管理するための方法およびシステムのこの説明において、移動端末１０が、さまざまなソース２０、３０および４０によって送信される複数の通知２１、３１および４１を同時に受信していると仮定する。非限定の例として、これらの通知は、電話通知、電子メール通知、カレンダ通知、その他であってよい。これらの通知は、異種フォーマットであってよい（一般的にそうである）。

通知の自動管理は、図２に示される非限定の例において、移動端末１０に埋め込まれる機能モジュールによって保証される。これらのモジュールの少なくともいくつかのうちの一実装は、送信元２０、３０よび４０の中で具体化することができる。

これらのモジュールは以下を含む。
− さまざまなソース、２０、３０、４０によって送信されるユーザ通知を受信するためのモジュール１。例としては、プロキシサーバの使用が、さまざまなタイプの送信アプリケーションおよび送信プラットフォームとのインターフェースを作成することを可能にする。モジュール１の別の機能は、ユーザ通知を後で一緒に処理する目的で、さまざまなユーザ通知のフォーマットを均一化することであり、ユーザ通知は、以下で説明する、他のモジュールによって理解されることが可能な単一の内部メタデータ・フォーマットに変換される。ユーザ通知の変換は以下の動作を含む。
− 前記通知のソースサービスについての情報を識別するステップ、
− 前記通知内のフィールドを識別するステップ、
− 通知の記述的特性を識別するステップ、
− ソースサービスについての情報を用いて、識別されたフィールドを用いて、および記述的特性を用いて、前記通知に対応するメタデータを完成させるステップ。
− 受信モジュール１によって通知が搬送され、通知を集中化するための媒体として使用されるデータベース２。このデータベース２は、新たに受信されるユーザ通知２１、３１および４１、ならびにそれらの優先度レベル、送信元、存続期間、受信日、その他などの、通知に関係する詳細を伴った通知のログを集める。
− 優先度基準を、データベース２内で集中化されたユーザ通知についてのメタデータに適用するように構成された優先度管理モジュール３。慣例により、これらの基準は、時間依存性（緊急度基準）であると仮定する。したがって、モジュール３は、通知の優先度レベルの定期的な再評価を実行し、それにより継続的に更新される通知を管理する。
− 優先度管理モジュール３によって取得される結果に基づいて、ユーザ通知に関するメタデータの順序付けを保証するように構成されたモジュール４。モジュール４は、対応するモジュール３による優先度の管理と同じ頻度で継続的にユーザ通知に関するメタデータを配置し、時間遅延した通知に対応するリマインダを最終的にトリガすることを可能にする。
− モジュール４によってトリガされたユーザ通知の表示を制御するように構成された表示管理モジュール５。モジュール５は、対話型ユーザインターフェースを制御し、それは、このインターフェースがデータを修正または入力するのを可能にする。インターフェースはまた、通知のログを、モジュール４によって定義された順序で、または移動端末のユーザによって選択された任意の他の順序で表示するのに役立つ。例として、ユーザは、通知の受信日、通知の送信元、その他に基づいて分類された通知を表示することができる。
− 優先度マネジャ３の高度な構成モジュール６。このモジュール６は、移動端末のユーザが、優先度管理モジュール３によってその後使用される優先度基準を、入力する、または編集することを可能にするグラフィカル・ユーザインターフェースを備えている。

優先度マネジャ３はまた、有利には編集可能または削除可能でさえあってよい、ユーザ・プロファイルなどの、プロファイル・データベース７内で実装される個人的な基準を考慮に入れるように構成されてよい。さらに、複数のユーザ・プロファイルが、データベース７内で実装されてよい。

優先的に、モジュール６は以下を行うようにさらに構成される。
− 複数の優先度レベルを定義する。このやり方において、緊急度基準は、直ちに、所与の時間前に、所与の日付前になどの、時間の３つのレベルを含むことができる。同様に、緊急度基準は、極めて重大、重要、情報提供などの、重要度の３つのレベルを含むことができる。
− ユーザ通知のコンテンツ内で検索されることになるキーワード（これは同義語の辞書を使用して拡大されてよい）を考慮に入れる、
− ユーザ通知の識別子および特性を扱う優先度規則を選択する。したがって、これらの規則は、たとえば、通知のサイズ、通知が受信された日付、その添付物、送信プラットフォーム、送信元のアイデンティティ、件名、その他を扱うことができる。

優先的に、ユーザはまた、優先度マネジャ５のインターフェースを使用することによって、通知の優先度を直接編集することができなければならない。

詳細には、移動端末のユーザは、通知が既にそれら独自の優先度レベルを有していたとしても、これらの通知の優先度基準をカスタマイズすることができなければならない。

優先度マネジャ３は、構成モジュール６において定義されたように優先度基準を、およびデータベース７において選択されたユーザ・プロファイルを識別する。次に、優先度マネジャ３は、データベース２に記憶される新たな通知の優先度レベルを計算する。通知は次いで、優先度マネジャ３によって計算実行された結果を使用するモジュール４を使用して、優先度の順序によってランク付けされる。データベース２のコンテンツの再編成はまた、表示の管理モジュール５を使用しても可能である。

上記で触れたように、ユーザ通知は、移動端末１０と通信するように構成された外部サーバから来ても、移動端末１０によって内部的に生成されてもよい。

さらに、通知は、時間遅延があるなしにかかわらず、あらかじめ設定された優先度レベルを有していても、いなくてもよい。これらの優先度レベルは、高度な構成モジュール６を使用して構成されてよいユーザ・プロファイルおよび優先度基準に関連して、カスタマイズすることができる。

優先的に、メタデータの内部フォーマットは、ユーザ通知に関して利用可能である、任意の他の新たな情報に拡張されてよい。

ユーザ通知を受信する、または生成する、ならびに表示することが可能な移動端末１０内での、前記通知、たとえば２１、３１および４１の自動管理は、少なくとも以下のステップを含む。
− 移動端末によって受信される、または生成される各通知を、単一のメタデータ・フォーマットに変換するステップ、
− 前記変換をデータベース２内に保存するステップ、
− ユーザによってあらかじめ設定された優先度基準に基づいて、前記通知の優先度を評価するステップ、
− 既に保存されている他の変換された通知と比較したその優先度に基づいて、前記通知を収容するデータベース２を再編成するステップ、
− その優先度に基づいて、通知を端末に表示するステップ。

データベースの再編成は、通知の優先度を、以下から来る他の通知の優先度と比較するステップを含む。
− その通知と同じサービス、
− または異なるサービス。

下の実施例１は、アラート通知を示す。実施例２は、この通知のメタデータ・フォーマットへの考え得る変換を示し、メタデータ・フォーマットは変換を保存するのに使用することができる。

<Alert>
<Sender> Patient Monitoring System </Sender>
<Type> Abnormal situation </Type>
<ActivityDomain> Health </ActivityDomain>
<Msg> Fall Detection in Room 21, Emergency Department </Msg>
<Time> 12:32 AM </Time>
<ThirdParty> Bob Smith </ThirdParty>
<Priority> High </Priority>
<AckRequired> Yes </AckRequired>
<AckTimeout> 20 </AckTimeout>
<TimeToLive> 60 </TimeToLive>
</Alert>

<NotifEvent>
<Sender> Patient Monitoring System </Sender>
<Type> Abnormal situation </Type>
<ActivityDomain> Health </ActivityDomain>
<Content>
<Title> </Title>
<Msg> Fall Detection in Room 21 </Msg>
<MoreInfo></MoreInfo>
<Keywords> Emergency, Fall</Keywords
<Attachments> </Attachments>
</Content>
<ThirdParty> Bob Smith </ThirdParty>
<Priority> 8 </Priority>
<ReceptionTime> 12:32:50 </ReceptionTime>
<AckRequired> Yes </AckRequired>
<AckTimeout> 20 </AckTimeout>
<NbRepetition> 2 </NbRepetition>
<TimeToLive> 60 </TimeToLive>
<Status> Not Treated </Status>
<AdditionalInfo> </AdditionalInfo>
</NotifEvent>

優先度レベルは、１（低い優先度）から１０（最も高い優先度）にわたるものと仮定されたい。優先度レベル８の、機能上、限定しない計算は、２つの前述の実施例を参照して、少なくとも以下を考慮に入れる。
− 着信アラートの優先度、ここでは高い、
− 送信元、ここではＰａｔｉｅｎｔＭｏｎｉｔｏｒｉｎｇＳｙｓｔｅｍ、
− 異常な医学的状況、
− 確認応答の要求、
− キーワード、ここでは、ＥｍｅｒｇｅｎｃｙおよびＦａｌｌ、
− チェックされることなしにアラートが受信された回数。

Claims

ユーザ通知を受信または生成ならびに表示することができる移動端末（１０）において、異種フォーマットのこれらの通知を自動的に管理する方法であって、
前記移動端末によって受信または生成される各通知を、単一のフォーマットのメタデータに変換するステップと、
前記変換をデータベース（２）内に保存するステップと、
ユーザによって予め設定された優先度基準と前記通知のコンテンツとの組合せに基づいて、前記通知の優先度を評価するステップと、
既に保存されている他の変換された通知と比較したその優先度に基づいて、前記通知を収容する前記データベース（２）を再編成するステップと、
その優先度に基づいて、前記通知を前記端末（１０）に表示するステップとを含む、方法。
前記優先度基準が前記移動端末のユーザの少なくとも１つのプロファイルに基づく、請求項１に記載の方法。
前記通知を変換する前記ステップが、
前記通知のソースサービスについての情報を識別し、
前記通知内のフィールドを識別し、
前記通知の記述的特性を識別し、
前記ソースサービスについての前記情報と、識別された前記フィールドと、前記記述的特性とを用いて、前記通知に対応する前記メタデータを完成させる、動作を含む、請求項１または２に記載の方法。
通知に関連した前記優先度基準が、前記ソースサービスについての前記情報と、前記フィールドと、前記通知の記述的特性との相関関係である、請求項３に記載の方法。
前記通知の優先度の評価が、前記通知のコンテンツ、および場合によってその添付物において、予め定義されたリストからキーワードを検索する動作を含む、請求項１乃至４のいずれか１項に記載の方法。
前記検索が、同義語の辞書において識別される前記キーワードの同義語、短縮形、および数字を用いて拡大される、請求項５に記載の方法。
前記データベースを再編成する前記ステップが、前記通知の優先度をその通知と同じサービスから来る他の通知の優先度と比較するステップを含む、請求項１乃至６のいずれか１項に記載の方法。
前記データベースを再編成する前記ステップが、前記通知の優先度をその通知とは異なるサービスから来る他の通知の優先度と比較するステップを含む、請求項５に記載の方法。
ユーザ通知を受信または生成および表示することが可能な移動端末において、異種フォーマットのこれらの通知を管理するシステムであって、
前記移動端末によって受信または生成される各通知を、単一のフォーマットのメタデータに変換することが可能な通知受信モジュール（１）と、
前記変換を保存するデータベース（２）と、
ユーザによって予め設定された優先度基準と前記通知のコンテンツとに基づいて、各通知の優先度を評価するモジュール（３）と、
前記データベース（２）に保存された前記通知のそれぞれの優先度に基づいて、データベース（２）を編成するモジュール（４）と、
それらの優先度に基づいて通知を表示する対話型グラフィカル・モジュール（５）と、
を含むシステム。
前記ユーザ通知の前記優先度基準を構成するモジュールをさらに含む、請求項９に記載のシステム。