JP2011514697A - コンバージド情報システム - Google Patents

Abstract

少なくとも２つの異なるプロトコルを使用する複数のソースからネットワークを介してユーザ機器（ＵＥ）に通知を提供する通知システムであって、前記複数の通知ソースからのＵＥ向けの通知を受信するように構成され、個々のソースのプロトコルに応じて複数のプロトコルを使用する通知を受信する手段と、単一のプロトコルを使用してＵＥに通知を伝達する手段とを有し、それにより通知のコア処理をＵＥの外に移した通知エージェントを備えた通知システムが提供される。

Description

本発明は、コンバージド情報システムに関する。特に、ユーザ機器（ＵＥ）が、多数の異なるプロトコルを使用するいくつかのタイプのデータを伝達および受信するために使用されるシステムに関する。

ＩＰＴＶ（インターネットプロトコルＴＶ）のユーザは、多数の異なる通信および情報技術を使用したいことがある。例えば、ＳＭＳ、ＭＭＳ、ＩＭＳ（ＩＰマルチメディアサブシステム）、ＩＭＳ−ＩＭ、ＶＯＩＤ呼、ＲＳＳ、Ｅメール、カレンダ機能、ＭＳＮまたはＧｏｏｇｌｅトークなどのインスタントメッセージイングサービス、インターネット通知、および他のタイプのサービスなどがある。これらはすべて、一般的に異なるプロトコルに関わる。通信事業者は、ＩＰＴＶユーザに、前述の通知ソースの一部またはすべてからの通知に対処するための機能を提供することに関心をますます高めている。すなわち、ユーザが、特定のプロトコルを使用した要求または伝送を知らされる時、ユーザは通知を受け取り、ユーザがそれにどのように対処するかを選択できる機能がＵＥで提供される。これらのアプリケーションは一般的に「コンバージドサービス」と呼ばれ、これらは、従来のＩＰＴＶ（ブロードキャストＴＶ、コンテンツオンデマンド、ビデオオンデマンド（ＶＯＤ）など）の付加価値サービスである。

同様に、ユーザは、理想的には、マルチメディアサービスおよび通信体験が自分のライフスタイルに合わせて調整可能であることを願う。例えば、ユーザは、「バディリスト」上の人物からの優先順位の高いＥメール、ＳＭＳメッセージ、または呼についてはＴＶ画面で通知を受信し、適切な応答処置を取りたいと思うこともある。

ＵＥにそのようなコンバージドサービスを提供する既存の方法は、通知ソースからＵＥまでゲートウェイを使用することがあり、そのＵＥには、各タイプの通信（ＳＭＳ、Ｅメール、ＶＯＩＤ、カレンダ機能など）に固有の通知処理ロジックを含む個別の通知クライアントが準備される必要がある。例えば、ＩＭＳ ＶＯＩＰ（セッション開始プロトコル）呼をＩＰサブシステムに配信するには、ＩＭＳ ＶＯＩＰ通知をＩＰＴＶ ＵＥに配信するためゲートウェイが使用される。このゲートウェイは、呼の通知をＩＰＴＶ ＵＥにＳＩＰを使用して配信することができ、ＵＥ上の組み込みクライアントが応答処置を提供する。一般的には、可能性のあるオプションとしては、「ボイスメールへの転送」、「発呼者に関する追加情報の要求」、「拒否」、「返信」、「その他」があり得る。

もう１つの例として、Ｅメールの通知がある。着信Ｅメールの通知は、ＰＯＰ３、ＩＭＡＰ、ＳＭＴＰなどのＥメールプロトコルによってＵＥユーザに直接またはゲートウェイを介して配信され、ＵＥ上の別の組み込みクライアントが応答処置を提供する。一般的には、応答処置は、「返信」、「本文を読む」、「無視」、「その他」が考えられる。応答に応じて、クライアントは、ＰＯＰ３、ＩＭＡＰなどを使用してＥメールのテキストを取り出す。

この既存の方法に関する主要な問題は、通知ソースごとに固有のプロトコルおよび通知処理ロジックを含む専用ＵＥクライアントが必要なことである。このクライアントは、ＵＥそのものに備えられる必要がある。このことから、以下の限界が生ずる。

新しい通知ソース、例えば、Ｅメール、ＳＭＳなどをサポートするために新しいＵＥクライアントが必要であり、それは、中規模から、より規模の大きい展開に至るまでコスト効率が良くない、
新しい通知ソースをサポートするには、ＵＥ上に新しい通知処理ロジックが必要である、
ＵＥ上に処理ロジックを追加することは余分な処理電力が必要であり、ハードウェアが必要とするコストが増加する、
複数の通知クライアントと他のアプリケーション間のアービトレーションもコストを増加させる、および
グラフィカルユーザインターフェース（ＧＵＩ）がカスタマイズされる時には各クライアントのカスタマイズが必要であり、このこともコストを増加させる。

さらに、新しいサービスを既存のＵＥに追加することは困難である。

このような通知方法がＥＳ ２０２３９ １０−３「Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ」（ＯＳＡ）「ｐａｒｌａｙ Ｘ−ｗｅｂ ｓｅｒｖｉｃｅｓ Ｐａｒｔ ３：Ｃａｌｌ Ｎｏｔｉｆｉｃａｔｉｏｎ」で標準化されている。この標準では、固有の通知ソースに対してクライアントアプリケーションが登録される必要があり、クライアントアプリケーションは通知処理ロジックを実装している必要がある。

ＥＳ ２０２３９ １０−３「Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ」（ＯＳＡ）「ｐａｒｌａｙ Ｘ−ｗｅｂ ｓｅｒｖｉｃｅｓ Ｐａｒｔ ３：Ｃａｌｌ Ｎｏｔｉｆｉｃａｔｉｏｎ」

本発明は、複数の通知ソースからの通知および応答処置をＵＥデバイスで実施する方法を改善しようとしていた時、新しい通知ソースおよびタイプを追加する新しい、容易な方法が可能なシステムを提供しようとした試みから誕生した。

本発明によれば、少なくとも２つの異なるプロトコルを使用する複数のソースからネットワークを介してユーザ機器に通知を提供する通知システムであって、前記複数の通知ソースからのユーザ向けの通知を受信するように構成され、個々のソースのプロトコルに応じて複数のプロトコルを使用する通知を受信する手段と、共通プロトコルを使用してＵＥに通知を提供する手段とを有する通知エージェントを備えた通知システムが提供される。

通知エージェントは通知と共に１つまたは複数のパラメータを表すさらに別のデータをパッケージ化することが好ましい。それらのパラメータは、メタデータ、応答処置、および許容機能のうちの１つのみ、または複数個とすることができる。別の言い方では、これらは、「｛通知、処置、メタデータ、機能｝」（｛ＮＡＭＦ｝）パッケージと呼ばれる。

｛ＮＡＭＦ｝は、通知エージェントからクライアントのユーザ機器（ＵＥ）へ個別に、まとめて、または別の方法で渡すことができる。任意であるが、ＩＰＴＶ ＡＳを介して伝送することもできる。

システムは、初期処理用のプラガブル処理ロジックをさらに含むことができる。

さらに別の態様では、本発明は、複数のエージェントからの、異なる固有のプロトコルを有する通知をネットワーキングを介してユーザ機器に伝送する方法であって、複数のエージェントから、それぞれが固有のプロトコルを使用する通知を受信し、その通知を単一のプロトコルを使用してＵＥに転送するようになされた通知エージェントを提供するステップを含む方法をさらに提供する。

ＵＥにおける通知クライアントは、通知が受信されていることをユーザに知らせるような構成、さらに、該当する場合は、ユーザが処置を選択できるように、可能な処置の範囲をユーザに提示するような構成にすることができる。該当する場合、ユーザは、選択した処置を、それ以降の対処のために通知処置エージェントに送り返すことができる。

本発明は、複数のソースから、それぞれが特定のプロトコルを使用する通知を受信する手段、および共通のプロトコルを使用してＵＥに通知を提供する手段を有する通知エージェントをさらに提供する。

本発明は、本明細書で開示される、および／または特許請求の範囲で請求される開示される新規機能のうちの１つまたは複数、または機能の組合せを含む通知システムまたはエージェントをさらに提供する。

以下で、例としてのみであるが、次のような添付の概略図を参照して本発明の実施形態を説明する：

通知システムを示した図である。 データの流れを示した図である。 データパッケージを示した図である。 ユーザ機器（ＵＥ）上の画面表示を示した図である。 別の画面表示を示した図である。 第１の画面表示を示した図である。

図１を参照すると、ユーザ機器１が様々なソースから通知を受信できるようにする概括的なシステムが示されている。この場合のＵＥ １は、ディスプレイ３に接続されたセットトップボックス２を含むＩＰＴＶ装置である。ＳＴＢは、当然、ディスプレイと一体化されていてよい。あるいは、ＵＥは、移動体電話、ＰＤＡあるいはハンドヘルド端末、または任意の他のデバイスなど、任意の他の機器であってよい。通信を関連のデバイス宛に送ることができるように、特定のユーザが任意の時に移動体デバイスまたはセットトップボックスを使用しているかを示すことができる手段（本発明の一部ではない）を提供することができる。

これは、任意の適切な通信チャネル、例えば、クローズドＩＰネットワーク、オープンインターネット、例えば、ＧＰＲＳ、ＵＭＴＳを使用するなどのワイヤレスチャネル、あるいは他のワイヤレスもしくは固定回線のチャネルによって、またはこれらの組合せ、あるいは他の手段によって、ネットワーク上の任意の適切な場所に置かれ、通知エージェント４を含むリモート「ミドルウェア」に接続される。通知エージェント４は、Ｅメール５、ＭＭＳ／ＳＭＳサービス６、インターネット７、ＶＯＩＤサービス８、ＩＭＳ ＶＯＩＤサービス９、および多くの他のタイプのサービス１０など、様々な通信サービスとの一連のゲートウェイとの間でデータを受信および伝送する。これらは、多くの異なるプロトコルを使用して正常に通信することができる。例えば、Ｅメールは、ＳＭＴＰ、ＰＯＰ３、ＩＭＡＰまたはＳＭＰＰを使用して伝達できるし、インターネットとの通信はＨＴＴＰ／ＸＭＬを使用できるし、ＶＯＩＰはＳＩＰ（セッション開始プロトコル）を使用できる。同じように、ＩＭＳ ＶＯＩＰおよび他のデータソースも同様または他のプロトコルを使用できる。

通知エージェント４は、複数の通知ソース５から１０からの通知を収集／受信するような構成になっている。拡張性のために複数のエージェントが使用できることに留意されたい。例えば、着信ＳＩＰ用の受動型リスニングモードあるいはインターネット更新用の能動型プルモードなど、異なるモードまたは他の機能などが使用できる。着信通知は、様々な通知サービスから個々の標準インターフェースを介して受信され、これは、図１にステップＡとして示されている。通知エージェント４は、通知を処理し、その通知を単一の通知フォーマット／プロトコルに変換する機能が組み込まれている。さらに、通知エージェント４は、メタデータ、応答処置、表示プロパティ、および許容機能をパッケージ化し、これらは、「｛通知、処置、メタデータ、機能｝」、すなわち、｛ＮＡＭＦ｝パッケージと呼ばれる。典型的なパッケージが概略的に図３に示されており、この図において、パッケージ５は、通知Ｎ、可能な処置の範囲Ａ、メタデータＭおよび機能Ｆを含み、このパッケージがＵＥ １に伝送される。これについて、以下でさらに詳しく説明する。

図１は、多数の通知処理ロジックユニット６を示しているが、通知処理ロジックユニット６は外部プラガブルロジックデバイスである。通知エージェントは、着信通知を複数の情報ソース５から１０から通知プロジェクトロジックデバイス６に初期処理のために渡すことができ、これは、図１でステップＢとして示されている。

通知エージェントが｛ＮＡＭＦ｝をパッケージ化し終わると、それらはステップＣでＵＥに送信される。それらは、まとめて、すなわち、図３に示されているようなパッケージとして、または個別に渡すことができ、実際のトランスポート実施／プロトコルは任意の適切なものでよい。ＵＥは、ユーザにディスプレイ３を介して通知および各種オプション／処置を提示する。任意であるが、通知はＩＰＴＶ ＡＳを介して配信することもできる。使用可能な各種オプションがユーザに表示され、ユーザは、そのうちの１つを選択することができる。ユーザが所望の処置を選択した後、ＵＥは、ステップＤで、選択された処置を通知エージェントに渡す。次いで、通知エージェントは、選択された処置を処理するか、または選択された処置を関連のプラガブル通知処理ロジック６に渡す。任意であるが、新しい通知および処置の選択がＵＥに送り返される必要がある。次いで、通知エージェントは新しいＮＡＭＦを生成し、これをＳＴＢに渡す。さらに反復が必要な場合、ステップＢ、ＣおよびＤをこの通りに繰り返すことができる。

発信元通知ソース５から１０へ応答が必要な場合、通知エージェント４は、ステップＥで、その通知が発信元から受信された時の標準（固有）通知サービスインターフェースを介して応答を配信することができる。

図２は、データの流れを概略的に示している。様々なエージェント（この場合には、３つのエージェント、すなわち、Ｅメール５、インターネット７、ＶＯＩＤ ８が例としてのみ示されている）からの通知が通知エージェント４によって受信される。通知エージェント４は、通知を単一の通知フォーマット／単一のプロトコルに変換する。通知エージェント４は｛ＮＡＭＦ｝パッケージを生成し、これをＵＥ １に伝送する。次いで、ＵＥ １は通知および使用可能なすべてのオプションを表示し、ユーザはオプションを１つ選択する。これが、ステップＤで、通知エージェント４に送り返される。発信元エージェントでさらに別の通信データ転送が必要な場合、これが行われる。そうでない場合、通知エージェントは、おそらく通知処理ロジックユニット６（分かり易くするために図２には示されていない）を介して、ステップＣ２でさらに｛ＮＡＭＦ｝をＵＥに伝送する。通知エージェント４とＵＥ間のすべての通信は、単一のプロトコルを介して、単一の通信手段によって行われ、そのため、これ以降、ＵＥ自体に通知処理ロジックは必要ない。これは、すべて通知エージェント４で行われる。したがって、複数の通知ソースがサポートできる。実際には、出現してくる新しい通知ソース（例えば、Ｅメール、ＳＭＳ、他のソース）をＵＥのアップグレードまたは修正を必要とせずに含めるために、ミドルウェアベースの通知エージェント４に事実上無制限の拡張を追加することができる。

より一般的に言えば、ミドルウェア内の共通通知エージェントＮＡ４が複数の通知ソースから通知を収集および受信する。このエージェントは、通知を受信して処理し、その通知を、統一された方法でメタデータ、応答処置、表示プロパティ、許容機能あるいは他のパラメータまたは機能と一緒にパッケージ化し、次に、このパッケージが単一の通知チャネルを介してＵＥに伝送される。したがって、ＵＥは、ソース５から１０の固有性とは関係なく、パッケージの表示プロパティを使用し、統一されたＵＥルック＆フィールでユーザに対して通知を提示する。

伝送される実際の｛ＮＡＭＦ｝パッケージが例として図３に示されている。基本の通知に加えて、前述のような様々な他の情報がパッケージ化される。これには処置Ａも含まれる。例えば、通知がＥメールに関する場合、「通知」はＥメールの件名のみを含むことができる。「処置」は、ユーザが実行できる各種処置、例えば、「読む」、「保存」「本文を取得」、「無視」などを含むことができる。「機能」は、ＵＥ（例えば、セットトップボックス）に、選択可能な仮想ボタンなどの画面上の位置、表示の期間、サイズ／カラーなどを含めて、件名および各種処置をどのように表示するかを指示する情報を含むことができる。様々なタイプの「メタデータ」を含むこともでき、当然、他の機能またはデータを含むこともできる。機能Ｆは、例えば、各種オプションをディスプレイ上でボタンの形で表示するかなど、オプションの表示方法のみでなく、物理的にディスプレイ上のどこにこれらのボタンを配置するか、およびユーザがその時点でＩＰＴＶ番組または他のコンテンツを視聴している場合、すでに表示されているコンテンツの扱い方も含むことができる。例えば、通知および各種機能を既存の表示の上にオーバーレイするのか、既存の表示の代わりにオーバーレイするのか、または既存の表示が映像コンテンツの場合、通知を表示している間、既存の表示を続行させるのか、あるいは既存の表示をブランクまたはフリーズするかについての情報を含むことができる。多くの他のタイプの情報も伝送できる。この情報は、通知が画面に以降は表示されなくなった時、映像コンテンツが、停止（すなわち、一時停止）した位置から自動的に再開できるように映像コンテンツを自動的に保存する命令も含むことができる。

伝送される可能性がある他の要素として、例えば優先順位情報に関連するものがあり得る。これは、例えば、メッセージがユーザのバディリスト上の人物から、または他の理由で、より大きい優先順位が与えられるべき人物から発信された場合、そのメッセージは、より目立つように表示されるか、またはすでに表示されている別のメッセージより、おそらく優先して表示されるか、またはいずれか他の表示プロパティを変更することもあり得ることを意味する可能性がある。それは、メッセージがユーザの子供から送信されており、そのため、ユーザはそのメッセージが早急に表示される必要があるという可能性もある。多くの他のタイプのロジックが明らかであろう。

図４から図６は、表示の例を示している。図４において、ディスプレイ３に映像１０が表示されている。通知が発生すると、その通知と一緒に送信される処理ロジックおよび命令に従って、通知は映像イメージ１０にオーバーレイされる方法で表示される。この場合には、その情報はＥメールの形で送信され、Ｅメールの件名が第１のボックス１１に表示される。複数の処置ボタン１２ａ、１２ｂおよび１２ｃも、映像イメージにオーバーレイされて表示される。１２ａは「本文を取得」、１２ｂは「削除」、１２ｃは「保存」などと表示される。当然、ボタンは３個より多くても、少なくてもよい。ボタン１２ａは、おそらく、ユーザが、リモート制御で、キーボードまたは他の入力手段を用いて、またはリモート制御ポインタを用いるか、または任意の他の手段によってタッチ画面を使用して直接タッチすることにより、ボタン「１」（例えば）を選択することで選択可能である。

ユーザが選択項目１２ａ「件名を取得」を選択すると、このメッセージが通知エージェントに中継されて戻され、さらにＥメールソース５に戻される（図１）。次いで、件名が取得されて、ＵＥに送り返される。図６は、その後の表示を示しており、本文（または全メッセージ）がボックス１３に表示され、さらにいくつかのオプションが表示されている。オプションは、例えば、ボックス１４ａでは「削除」、ボックス１４ｂでは「返信」などと表示される。当然、多くの他のオプションが可能であり、可能な返信ボタンは２個より多くても、少なくてもよい。

図４から図６の実施形態は、当然、概略的なものであり、メッセージがＥメールの場合を表している。他のタイプのデータには他のタイプの通知および表示が適切であろう。

例えば、コンテンツ共用のシナリオもあり得る。この場合には、通知エージェント４は、その新しいユーザ生成のコンテンツがアップローディングエージェント１０によってアップロードされたことを検出する。通知エージェント４は、コンテンツ創作者の「バディ」に対して、「フレッドからの新コンテンツがあります」という旨の通知を生成する。これは、図５の件名ボックス１１に表示される通知になることもあり得る。可能な処置は、「詳細を読む」「後で表示」「早急に表示」、「無視」、「フレッドにＳＭＳを送信する」などと表示される。ＵＥは、通知「フレッドからの新コンテンツがあります」をディスプレイ上に標準のルック＆フィールで表示し、各種処置をオーバーレイする。処置の位置付けは、通知から送信されたパッケージによって、またはＵＥ上の所定のルールに従って決めることができる。

ユーザが「後で表示」を選択すると、ＵＥはその処置を通知エージェントに渡す。次いで、そのエージェントが、後で表示するためのコンテンツをキャッシュするためにコンテンツ移動を起動する。すると、新しい通知「コンテンツは１７：００時に表示準備されます。処置は不要です」が生成できる。

上の例では、ＵＥ上に特定のコンテンツアウェアクライアントも、どのような処理ロジックも必要ない。

さらに別のシナリオは、ＩＰＴＶシステムで受信されるＥメールに関する。通知エージェント４は、新しいＥメールが受信されたことを検出する。そのエージェントは、ＩＰＴＶ ＵＥに対する通知「メールがあります」を生成する。処置「読む」、「返信」、「無視」。ＵＥは、その通知を標準のルック＆フィールで表示し、各種処置をオーバーレイする。この例では、ユーザは「読む」を選択する。ＵＥは、この処置を通知エージェントに渡す。そのエージェントは、ＩＭＡＰ、ＰＯＰ３などの適切なＥメールプロトコルを使用してＥメール本文を取り出す。次いで、メール本文および新しい処置一式を含む新しい通知が生成される。さらに、サイクルが続行される。この例では、やはり、ＵＥ上に特定のＥメール処理（ＰＯＰ３、ＩＭＡＰ、ＳＭＴＰなど）クライアントも、どのような処理ロジックも必要ない。

さらに別のシナリオは、ＩＰＴＶ ＳＭＳ通知に関する。上述のシナリオと同様のデータの流れが発生するが、通知プロキシからＳＭＰＰ上のＳＭＳサーバに対して「読む」処置が起動される。この場合も、ＵＥ自体にＳＭＰＰクライアントも、どのような処理ロジックも必要ない。上述のシナリオすべて、および多くの他のシナリオが同じＵＥ上で共通のルック＆フィールを用いて実行できるが、ＵＥ上にどのような通知固有のクライアントも、処理ロジックも必要ない。

多くの変形が可能である。通知の表示は、例えば、低優先順位のメッセージが受信された場合、そのメッセージは、ユーザが鑑賞中のＴＶ番組（例えば、フットボールの試合）の終了後に配信されるように調整できる。または、より目立ちにくく表示するが、試合の上にオーバーレイして表示することもできる。

本発明は、ＵＥから通知処理ロジックを取り除いた。そのため、複数の通知ソースを共通のコスト効率の良い方法でサポートできる。本発明は、ＵＥアップグレードまたは修正を加えてミドルウェアに（すなわち、サーバまたはインフラストラクチャレベルで）追加される新しい通知ソースを含めて、事実上無制限の拡張も可能にした。これは非常にコスト効率が良く、さらに通信事業者の要件しだいで「ピック＆ミックス」コンバージドサービスが使用可能にされることも可能にした。

ＵＥは、複数の通知クライアントと他のアプリケーションの間にアービトレーションを有する必要がない。また、ＵＥはすべての通知に共通のルック＆フィールを使用できるので、各クライアント用にＧＵＩカスタマイズは必要ない。

このように、通知のコア処理はＵＥから移され、代わりに、ＵＥではなく、通知エージェントで（および／または外部プラガブルロジックによって）行われる。ユーザは、応答を選択する必要があるのみである。

Claims (17)

1. 少なくとも２つの異なるプロトコルを使用する複数のソースからネットワークを介してユーザ機器（ＵＥ）に通知を提供する通知システムであって、前記複数の通知ソースからのユーザ向けの通知を受信するように構成され、個々のソースのプロトコルに応じて複数のプロトコルを使用する通知を受信する手段と、共通プロトコルを使用してＵＥに通知を提供する手段とを有する通知エージェントを備えた、通知システム。
2. 通知エージェントがＵＥに各通知で基本通知データのほかに、さらに別の情報を提供する、請求項１に記載の通知システム。
3. ＵＥに提供される情報が１つまたは複数の通知、処置、メタデータ、機能（｛ＮＡＭＦ｝データ）を含む、請求項２に記載の通知システム。
4. データが、ユーザが通知に応答して選択を所望する可能性がある１つまたは複数の処置を表すデータを含む、請求項２に記載の通知システム。
5. データが、通知の位置付けおよび／または表示を表すデータを含む、請求項４に記載の通知システム。
6. ＵＥからの返信を共通のプロトコルを介して通知エージェントに伝送し、該当する場合、通知エージェントから発信元ソースに個々のプロトコルを使用して伝送できるようにする手段を含む、請求項１に記載の通知システム。
7. 通知エージェントからＵＥに提供されるデータが、発信元エージェントからの通知のプロトコルおよびルック＆フィールに関係なく、共通のルック＆フィールを用いて表示されるフォーマットである、請求項１に記載の通知システム。
8. プラガブルロジック要素を含む、請求項１に記載の通知システム。
9. 通知の表示および／またはタイミングが条件および／または状況に応じて調整される、請求項１に記載の通知システム。
10. 通知処理が通知エージェントの内部で、および／または通知エージェントに「プラガブル」な処理ロジックによって行われる、請求項１に記載の通知システム。
11. 各々が特定のプロトコルを使用する複数のソースから通知を受信する手段と、共通プロトコルを使用してＵＥに通知を提供する手段とを有する、通知エージェント。
12. 通知エージェントが｛ＮＡＭＦ｝データをＵＥに提供する、請求項１１に記載の通知エージェント。
13. 複数のエージェントからの、異なる固有のプロトコルを有する通知をネットワークを介してユーザ機器に伝送する方法であって、複数のエージェントから、固有のプロトコルを使用する通知を受信し、その通知を単一のプロトコルを使用してＵＥに転送するようになされた通知エージェントを提供するステップを含む、方法。
14. 通知エージェントがＵＥに通知と共にさらに別のデータを送信する、請求項１３に記載の方法。
15. さらに別のデータが｛ＮＡＭＦ｝データの１つまたは複数個を含む、請求項１４に記載の方法。
16. 通知エージェントからＵＥに提供されるデータが、発信元エージェントからの通知のプロトコルおよびルック＆フィールに関係なく、共通のルック＆フィールを用いて表示されるフォーマットである、請求項１５に記載の方法。
17. 通知がＵＥによって受信され、その通知が、ＵＥのユーザに対して、ユーザが選択できて、単一のプロトコルを用いて通知エージェントに返信できる一連の選択可能な処置と共に表示され、その通知エージェントが、ユーザの選択によって決定されたさらに別のデータを取得するため、または応答を提供するために、各自固有のプロトコルを用いる複数のエージェントと通信する、請求項１３に記載の方法。

Images