コンバージドマルチメディア環境におけるリソースのアービトレーション
１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数のＵＥ（ユーザ装置）デバイスにネットワークリソースを割り当てるためにネットワーク上に配置された、ＵＥから遠隔にあるアクセス制御エージェントを含む、データ通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンバージドマルチメディア環境におけるリソースのアービトレーションに関する。詳細には、本発明は、どのタイプのマルチメディアコンテンツがユーザに提示されるか、およびこれがどのようにネットワークによって処理されるかに関して、決定されることができるアービトレーションシステムに関する。
【背景技術】
【０００２】
マルチメディアサービスおよび通信サービスをユーザのライフスタイルに適合することができる、コンバージドデータシステムおよび情報システムの必要性が増している。たとえば、デバイスのユーザは、単一のデバイスまたはユーザ装置（ＵＥ）から、電子メール、ＳＭＳを受信しそれに返答すること、友達リスト（ｂｕｄｄｙ ｌｉｓｔ）からコールを開始すること、従来のテレビサービスまたはビデオオンデマンド（ＶｏＤ）を見ること、ゲームをすることなどができることを一般に要求する。
【０００３】
多くの異なるタイプの通信サービスおよび情報サービスが、ＩＰＴＶ ＵＥに配信されることができる。これらのサービスには、たとえば、ＳＭＳ、ＭＭＳ、ＩＭＳ−ＩＭ、ＶＯＩＰコール、ＩＭＳフィーチャ、ＲＳＳフィード、電子メール、カレンダ機能、ＩＳＭ、Ｇｏｏｇｌｅトークなどのさまざまなタイプのインスタントメッセージングサービス、インターネット通知、ゲーム、およびその他多数が含まれる。サービス事業者は、ユーザが、数多くのこれらの異なるサービスを受けることができるコンバージドソリューションを提供することに特に関心がある。コンバージドソリューションでは、ＵＥが、複数の同時発生によるマルチメディアセッション、たとえば、ＳＩＰコール、ＶＯＤセッション、および電子メールプレゼンテーションに直面したときに、ＵＥは、共有リソースへのアクセスをアービトレートし、共有する必要がある。これらのリソースは、たとえば、ＴＶまたは他のディスプレイスクリーン、メディアデコーダ、スピーカ、記憶手段などであってよい。
【０００４】
共有ＵＥリソースへのアクセスをアービトレートするための方法が必要とされている。
【０００５】
これに対する現在のソリューションは、すべてのＵＥデバイスの完全な制御を前提とすることができる、ＵＥ上のＩＰＴＶアプリケーションを最も一般的に使用する。既存の「コンバージド」ソリューションは、通知ソースまたは情報ソースからゲートウェイを使用する。ゲートウェイは、ＩＰＴＶ ＵＥに通知を配信する。ＵＥは、サービスのタイプごとの複数のイネーブラと、共通ＡＰＩ（アプリケーションプログラミングインターフェース）のアブストラクション層を介してデバイスへのアクセスを共有するアプリケーションとを含む。各アプリケーションは、提示可能な管理されたやり方でアクセスを共有するように、他のアプリケーションを認識しなければならない。たとえば、ＴＶ上で提供される電子メールの場合、電子メールは、ＰＯＰ３、ＩＭＡＰ、ＳＭＴＰ、またはその他を使用して、直接、またはゲートウェイを介してのいずれかでＵＥに配信されることができ、ＵＥ上の組込み電子メールクライアントは、共通ＡＰＩを介して、スクリーン上で映像の上にテキストをオーバーレイするための許可を要求する。別の例は、ＩＭＳ ＳＩＰ（セッション開始プロトコル）コールが、ＩＰＴＶ ＵＥにかけられる場合である。ＵＥ上の組込みコールクライアントを介してセッション設定がネゴシエートされ、オーディオが配信されるときに、組込みコールクライアントは、共通ＡＰＩを介して、ＵＥシステム上のスピーカを排他的に、または調和させて使用することを要求する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このタイプのシステムによる問題は、ＵＥ上で提供されることになる、およびＵＥの共通リソース（デバイス）にアクセスするためのルールについて認識する、サービスタイプごとの別個のサービスを必要とすることである。これにより、いくつかの制約が設けられる：
ポリシー、プレゼンス、プロファイル、およびアクティビティなどの外部の固定的でない要因は、リソースがどのように割り当てられるべきかという決定に考慮されることができない。たとえば、フットボール試合観戦について友達チャットから来るＶＯＩＰコールを処理するためのルールは、オフィスまたは他の職場環境からの着信ＶＯＩコールを処理するためのルールとは、非常に異なることがある。前者は、話し合いの進行中、バックグラウンドにフットボール試合の実況放送を含むよう望むことがあるが、後者はそうではないであろう。
【０００７】
たとえ基礎的な配信メカニズムが同じであっても、ＵＥにおいて、新たなサービスタイプごとに、新たなクライアントおよび処理ロジカルが必要とされる。
【０００８】
アプリケーションは、互いの知識を用いて書かれる必要がある。また、
アプリケーションがＵＥに配置された後に、ルールをカスタマイズし、変更する簡単なやり方はない。
【課題を解決するための手段】
【０００９】
本発明は、改良されたアービトレーションシステムを提供するための試みにおいて生じたものである。
【００１０】
本発明によれば、１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数のＵＥ（ユーザ装置）デバイスにネットワークリソースを割り当てるためにネットワーク上に配置された、ＵＥから遠隔にあるアクセス制御エージェントを含む、データ通信システムが提供される。
【００１１】
好ましくは、アクセス制御エージェントは、要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、プレゼンス、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てる。
【００１２】
ＵＥは、（たとえば閉じたＩＰネットワーク、もしくはインターネットに接続されていてよい）ＩＰＴＶ装置、あるいは、無線（たとえばＧＰＲＳ、ＵＭＴＳ、もしくは他の無線）ネットワーク、もしくは固定回線ネットワークに接続されて、他のデバイスと通信するように構成された任意の移動体端末または固定端末であってよい。
【００１３】
本発明は、アクセス制御エージェントが、ネットワーク内に、またはネットワークのバックエンドにおいて「ローカルで」提供され、それにより、ＵＥにおいて利用可能なＵＥ使用が、さまざまなタイプのマルチメディアまたは他のコンテンツにどのように使用されるべきかに関する初期の決定論理を作成する機能を、ＵＥが有するための要件を解除することを可能にする。
【００１４】
リソースがどのように使用されることができるかに関する決定は、アクセス制御エージェントに委ねられることができる。必要であれば、エージェントは、所与のマルチメディアセッションのためのリソースの割当てに先立って、プロファイル情報、プレゼンス情報、ＵＥのユーザに関連付けられた友達リストを含むパーソナリゼーション、一般的なまたは特定のポリシー、および標準のまたは特定のインターフェースを介した情報にアクセスして、それらを評価することができる。
【００１５】
ＵＥは、ディスプレイ装置、スピーカ、マイクロフォンまたはマイクロフォン入力、さまざまなデータ入力／出力デバイスの使用、その他などの利用可能ないくつかのリソースを有することができる。これらのリソースのうちのいずれの制御も、少なくとも部分的には、アクセス制御エージェントによって割り当てられることができる。
【００１６】
さらに、共有リソース（ＵＥ物理的デバイス）へのアクセスは、共通のＵＥ ＡＰＩのアブストラクション層を介して再利用されることができる。
【００１７】
初期データの要求／送信についての通知をＵＥに提供するための通知エージェントが、やはり好ましくはＵＥから遠隔でネットワークにおいて提供されてよく、通知エージェントは、同時係属出願の代理人参照番号１５３５１ＥＰに開示されているようなものでよく、その通知エージェントは、複数のソースから通知を受信することができ、複数のソースそれぞれは特定のプロトコルを使用し、共通のプロトコルを通じかつ共通のルックアンドフィールによって、これらの通知をＵＥに提供する。通知エージェントは、アクセス制御エージェントにリンクされる、またはアクセス制御エージェントの一部を形成することができ、それにより、中央ネットワークリソースまたはローカルネットワークリソースが最大限活用され、ＵＥにおいて必要とされる論理リソースおよびソフトウエアリソースが最小限にされる。
【００１８】
本発明は、ネットワーク上で提供されるＵＥのリソース使用をアービトレートし、割り当てる方法をさらに提供し、方法は、１つまたは複数のリソースを使用する要求が生じたときに、１つまたは複数のパラメータに従って、ＵＥから遠隔で提供されるアクセス制御エージェントに、ＵＥにおけるリソース使用を割り当てさせ、アービトレートさせるステップを含む。
【００１９】
本発明は、１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数の遠隔ＵＥデバイスに利用可能なリソースを割り当てる手段を含む、アクセス制御エージェントをさらに提供する。
【００２０】
本発明はまた、本明細書で開示される、新規な特徴、特徴の組合せ、ステップ、またはステップの組合せのうちのいずれか１つまたは複数を含む、システムまたは方法を提供する。
【００２１】
次に本発明の実施形態が、例のみとして、添付の概略的な図面を参照して説明される。
【図面の簡単な説明】
【００２２】
【図１】ネットワークの一部を概略的に示す図である。
【図２】第１の使用例の説明図を示す図である。
【図３】第２の使用例の説明図である。
【図４】第３の使用例の説明図である。
【発明を実施するための形態】
【００２３】
図１を参照すると、本発明の実施形態が概略的に示されている。この場合はＩＰＴＶ ＵＥ（たとえばセットトップボックスとディスプレイ）であるＵＥ１が、ネットワークに接続されて、ネットワークから多くの異なるタイプのデータを受信する。図に示されるように、ＵＥ１は、いくつかのコンポーネントを含む。
【００２４】
ＵＥ１は、ＵＥの性質によってはプロセッサであるハードウエア２と、データ記憶ハードウエア（たとえばソリッドステートおよび／またはハードディスク）と、ディスプレイと、キーボード、タッチスクリーン、入力、マウス、タッチポインタなどの１つまたは複数の入力／出力手段と、マルチメディア使用のための、１つまたは複数のラウドスピーカ２（図２）と、マイクロフォンおよび／またはマイクロフォン入力とを含む。さまざまなレベルのソフトウエアもまた含まれる。これらのソフトウエアは、オペレーティングシステムおよびデバイスドライバ３と、デバイス制御層５と、この場合はＩＭＳ（ＶＯＩＰ）アプリケーションエージェント６およびＩＰＴＶアプリケーション７である、いくつかのより特定的なアプリケーションとを含むことができる。ネットワーク上に遠隔で提供される通知エージェント９から通知を受信するように構成されたさらなるエージェント８もまた含まれてよく、最も好ましくは、同時係属出願の参考文献１５３５０ＥＰに開示されたやり方で、これらが一緒に動作する。
【００２５】
ＩＭＳ（ＶＯＩＰ）アプリケーション６は、たとえば、セッション開始プロトコル（ＳＩＰ）、リアルタイムプロトコル（ＲＴＰ）、およびセッション記述プロトコル（ＳＤＰ）のマルチメディアセッションを使用する、一般に音声タイプのアプリケーションに関する。データは、オーディオデータおよび／またはビデオデータであってよい。
【００２６】
ＩＰＴＶアプリケーションは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、インターネットグループ管理プロトコル（ＩＧＭＰ）、またはＨＴＴＰなどのプロトコルを使用することができる。このアプリケーションは、ビデオデータ、（ＩＰマルチキャストによる）ビデオ放送、ビデオオンデマンドプログラム、またはセットトップボックス１を使用する他の素材に使用されることができる。
【００２７】
他のタイプのアプリケーションレイアウトのプロトコルおよび／またはエージェントが使用されてよい。
【００２８】
ネットワークレベルでは、前記通知エージェント９を含むメディエータ１０が提供される。メディエータはまた、アクセス制御エージェント（ＡＣＡ）１１と、オーケストレーションエージェント（実際には制御装置またはワークフローエージェント）１１とを含む。メディエータはまた、ＩＭＳプラットフォームおよびＩＰＴＶプラットフォーム１３などのさまざまなデータ／通信プラットフォームにリンクする。メディエータはまた、ＵＥのユーザにはっきり限定して関連されることができるか、またはより一般的な情報であってよいかのどちらかの外部情報にアクセスすることができ、たとえばこれらは、プレゼンス１４、プロファイル１５、友達リスト１６、または他の情報１７である。
【００２９】
ＵＥのＶＯＩＰアプリケーション６は、着信ＶＯＩＰコール設定Ａ、またはユーザ動作のどちらかによってトリガされたとき、共通のデバイス制御ＡＰＩ５を介してデバイスアクセスを要求するのに先立って、メディエータ１０（アクセス制御エージェント１１）に対してアクセスを要求する。ＶＯＩＰアプリケーション６は、ネットワークを通じてアクセス制御エージェント１１にコンタクトする。このアプリケーションは、セッション／サービス初期化の間に一度だけ共有リソースへのアクセスを決定する必要があり、これは、実際のサービス配信の間にユーザ経験に対して性能低下をもたらすことにはならないことに留意されたい。
【００３０】
メディエータ（アクセス制御エージェント）は次いで、共有リソースへのアクセスレベルを決定する前に、外部情報１４から１７にアクセスすることができる。エージェントは、ＵＥにではなく、ネットワーク内部に位置するため、同じアクセス制御エージェント１１が、複数のクライアントまたはＵＥの間で共有され、アクセスインターフェースを再利用し、キャッシュを可能にすることができる。たとえば、フットボール試合を見ているＴＶ上でビデオコールまたはチャットセッションを設定しようとしている複数のＵＥから要求されたときに、ユーザプロファイル、プレゼンス、およびいくつかのサービスデータがキャッシュされ、再利用されることができる。
【００３１】
アクセス制御エージェント１１は、いくつかの条件ステップが要求される場合に、外部の構成可能なワークフロー、またはプラグ可能な決定論理を使用して、デバイスアクセスを決定することができる。ＵＥ上でのオーケストレーションの低価格実装が達成されることができる。たとえば、初期のＶＯＩＰコールＡまたは電子メールの要求に応答して、アクセス制御エージェント１１は、ＩＰＴＶプラットフォーム１３に、あらかじめＵＥに送信されているストリーミングビデオを一時停止する、またはタイムシフト機能を開始するよう要求することができる。
【００３２】
アクセス制御エージェントは、アクセス許可およびアクセスレベルをアプリケーション６または７に戻す。ＵＥアプリケーションは次いで、承諾されたアクセスレベルによってＵＥデバイスへのアクセスを要求する。次に、これを明らかにするための例が与えられることになるが、これらの例は、本発明の多くの異なる例および実施形態のうちの例示にすぎない。
【００３３】
第１の一組のシナリオが、図２および図３に示される。これは、ユーザがディスプレイ上でフットボール試合２０を見ていて、試合の実況放送が一組のラウドスピーカ３を通して中継されている場合の着信ＶＯＩＰコールに関する。アクセス制御エージェントは、異なるタイプのＶＯＩＰコールの異なる処理を可能にすることができる。
【００３４】
第１の例では、ＩＰＴＶアプリケーションが、（同時係属出願１５３５０ＥＰにより詳細に説明されるような）通知エージェント９から着信コールを受け入れるためのユーザ選択オプションを有する。ＳＩＰ ｉｎｖｉｔｅが到着し、たとえば、オーディオがＲＴＰを介してＵＥに配信される。初期の設定時間の間、アプリケーションは、ＡＣＡ１１に対して、ＵＥ上の特定のリソース、とりわけオーディオスピーカ３およびマイクロフォンへのアクセスを要求するよう要請する。ＡＣＡはプレゼンス１４を確認し、すなわち、ＶＯＩＰコールの発信者のプレゼンスを確認する。ＡＣＡが、着信コールはその特定のＵＥ１のユーザの「友達リスト」１６の誰かからであり、その発信者が同じフットボール試合を見ていることを特定すると、たとえば、共有アクセスを承諾することができる。これは、実際には、ＶＯＩＰコールからの着信オーディオがオーバーレイされる間、リアルタイムでフットボール試合がまだ見られており、実況放送が聞かれていてよいことを意味する。したがって、アプリケーションは、バックグラウンドの（減衰された）試合の実況放送の上に、オーディオをオーバーレイする。これは、図２の第２の部分に示されており、ここでは、スピーカ３が発するサウンドが、実況放送とＶＯＩＰオーディオを表す。実況放送は、ＶＯＩＰオーディオがよりはっきりと聞かれることができるように、通常減衰されることになる。
【００３５】
あるいは、着信ＶＯＩＰコールが、たとえば、ユーザの職場から、または学校にいるユーザの子供から来ていることが特定されると、ユーザがそのメッセージに十分な注意を注ぐことがより重要であることがある。この場合は、オーディオおよびマイクロフォンへの排他的なアクセスが承諾される。これは図３に示される。最初は、フットボール試合２０が見られ、実況放送２１がスピーカから出力される。
【００３６】
上記に特定されたこれらのより重要な状況では、ＶＯＩＰオーディオ２２は次いで、実況放送なしに、単独２２でスピーカから出力される。フットボール試合または他のＩＰＴＶプログラムは、オプションでキャンセルされる、またはプロファイルのプレゼンスに基づいて一時停止されることができる。図３は、その第２の部分において、フットボール試合がどのようにしてスクリーンからキャンセルされて、それによりユーザがＶＯＩＰコールに十分な注意を払うことができるかを示す。しかしながら、代替として、試合はスクリーン上で単に一時停止されてもよい。オプションで、ＡＣＡは、オーケストレーションをトリガして、追加の情報、たとえばウェブページ、またはコールする人のコンタクトの詳細を含むウェブページへの参照、コールする人に関連付けられた記録などを、コールの間に配信することができる。
【００３７】
図４に概略的に図示されたさらなるシナリオでは、ＩＰＴＶシステムのユーザが再びフットボール試合を見ており、この場合では、ユーザはビデオコールすることを決める。ＩＰＴＶビデオコールアプリケーションより、ユーザは自分の「友達リスト」から自分の友達にコールすることを選択する。ビデオコールアプリケーションは、その友達についてプロファイル１５を検索するＡＣＡ１１にアクセスする。この場合、ＡＣＡは、ビデオコールおよびＶＯＤセッション（ライブのフットボール試合）の両方が、同時には処理されることができないことを判定する。したがって、ＡＣＡは、コールの間、ＩＰＴＶアプリケーションからのビデオ／オーディオリソースへのアクセスを拒否する。ビデオアプリケーションはビデオを停止し、制御はビデオコールアプリケーションに排他的に渡される。このようにして、ユーザは次にビデオコール２３で自分が話している相手を見ることができ、ビデオコールからのオーディオがスピーカ２４を通して出力される。
【００３８】
当然ながら、多くの例が明らかであるだろう。これらの例では、共有ＵＥリソースへのアクセスは、特定のユーザ環境用に個人化されることに留意されたい。加えて、アクセス制御エージェントによってＵＥに与えられるアクセスレベルは、ＵＥそのものによってではなく、ＡＣＡエージェントによって決定されるので、それぞれのアプリケーションは、互いを認識する必要が全くない。
【００３９】
本発明のいくつかの実施形態では、ＡＣＡが外部条件に基づいてアクセス権を提供することができる。すなわち、ＡＣＡは、ビデオアプリケーションのビデオを拒否し、オーディオを拒否し、ディスクへの正当なアクセスを拒否することなどができる。これは、特定のデバイスが、子供からのＶＯＩＰコール、ＳＭＳのプレゼンテーション、または他の目的などの、他の優先順位の高いサービスに必要とされる場合に発生することがある。特定の一例は、高帯域幅のビデオコールが発信される、または設定されるように要求される場合である。
【００４０】
サービス品質（ＱｏＳ）は、リソースの割当てを決定するもう１つのパラメータであってよい。たとえば、コールまたはデータ要求の発信者が「プレミアム」の顧客である場合、ＡＣＡは、自動的により高いＱｏＳを要求することができてよく、低いプレミアムの顧客に対するよりも、ＵＥ上のハードウエアリソースおよびソフトウエアリソースへの高いアクセスを取得することができる。ユーザ設定、ビデオコールのビットレート／解像度、または単に１つのタイプのサービス要件が（さまざまな規準を介して）別のものよりも重要であるかどうかの基準など、他の要因が決定を行うのに使用されてよい。たとえば、ビデオコールのコンテンツが、いつでも見られる特定のＶＯＤ放送よりも重要である場合、コールの発信者はＶＯＤよりも重要である、などである。２つの競合するサービスがリソースを求めて対抗しているとき、アクセス制御エージェントは、これらのうちのどちらがリソースを使用するか、またはどちらが使用のより高いレベルを獲得するかを決定するのに使用されることができる。
【００４１】
実際には、サービスの一定レベルを決定し、リソースの割当てを決定するための責任が、ＵＥから解除され、ネットワーク上に遠隔で配置されたアクセス制御エージェントに移される。アクセス制御エージェントは、外部システムとの連絡を保って、これを決定する。
【００４２】
多くの異なるルールおよびシナリオが明らかであろう。
【００４３】
本発明の実施形態では、ＵＥは、しばしば異なるアクセスインターフェースを必要とする異なる外部ソースの情報（プレゼンス、プロファイル、友達リストなど）に、どのようにアクセスするかを知る必要がないことに留意されたい。代わりに、ＵＥは、単一のＡＣＡと通信する必要があり、それにより、ＵＥからネットワークへと複雑さを移動させる。ＡＣＡは次いで、これらの通信を処理する。
【技術分野】
【０００１】
本発明は、コンバージドマルチメディア環境におけるリソースのアービトレーションに関する。詳細には、本発明は、どのタイプのマルチメディアコンテンツがユーザに提示されるか、およびこれがどのようにネットワークによって処理されるかに関して、決定されることができるアービトレーションシステムに関する。
【背景技術】
【０００２】
マルチメディアサービスおよび通信サービスをユーザのライフスタイルに適合することができる、コンバージドデータシステムおよび情報システムの必要性が増している。たとえば、デバイスのユーザは、単一のデバイスまたはユーザ装置（ＵＥ）から、電子メール、ＳＭＳを受信しそれに返答すること、友達リスト（ｂｕｄｄｙ ｌｉｓｔ）からコールを開始すること、従来のテレビサービスまたはビデオオンデマンド（ＶｏＤ）を見ること、ゲームをすることなどができることを一般に要求する。
【０００３】
多くの異なるタイプの通信サービスおよび情報サービスが、ＩＰＴＶ ＵＥに配信されることができる。これらのサービスには、たとえば、ＳＭＳ、ＭＭＳ、ＩＭＳ−ＩＭ、ＶＯＩＰコール、ＩＭＳフィーチャ、ＲＳＳフィード、電子メール、カレンダ機能、ＩＳＭ、Ｇｏｏｇｌｅトークなどのさまざまなタイプのインスタントメッセージングサービス、インターネット通知、ゲーム、およびその他多数が含まれる。サービス事業者は、ユーザが、数多くのこれらの異なるサービスを受けることができるコンバージドソリューションを提供することに特に関心がある。コンバージドソリューションでは、ＵＥが、複数の同時発生によるマルチメディアセッション、たとえば、ＳＩＰコール、ＶＯＤセッション、および電子メールプレゼンテーションに直面したときに、ＵＥは、共有リソースへのアクセスをアービトレートし、共有する必要がある。これらのリソースは、たとえば、ＴＶまたは他のディスプレイスクリーン、メディアデコーダ、スピーカ、記憶手段などであってよい。
【０００４】
共有ＵＥリソースへのアクセスをアービトレートするための方法が必要とされている。
【０００５】
これに対する現在のソリューションは、すべてのＵＥデバイスの完全な制御を前提とすることができる、ＵＥ上のＩＰＴＶアプリケーションを最も一般的に使用する。既存の「コンバージド」ソリューションは、通知ソースまたは情報ソースからゲートウェイを使用する。ゲートウェイは、ＩＰＴＶ ＵＥに通知を配信する。ＵＥは、サービスのタイプごとの複数のイネーブラと、共通ＡＰＩ（アプリケーションプログラミングインターフェース）のアブストラクション層を介してデバイスへのアクセスを共有するアプリケーションとを含む。各アプリケーションは、提示可能な管理されたやり方でアクセスを共有するように、他のアプリケーションを認識しなければならない。たとえば、ＴＶ上で提供される電子メールの場合、電子メールは、ＰＯＰ３、ＩＭＡＰ、ＳＭＴＰ、またはその他を使用して、直接、またはゲートウェイを介してのいずれかでＵＥに配信されることができ、ＵＥ上の組込み電子メールクライアントは、共通ＡＰＩを介して、スクリーン上で映像の上にテキストをオーバーレイするための許可を要求する。別の例は、ＩＭＳ ＳＩＰ（セッション開始プロトコル）コールが、ＩＰＴＶ ＵＥにかけられる場合である。ＵＥ上の組込みコールクライアントを介してセッション設定がネゴシエートされ、オーディオが配信されるときに、組込みコールクライアントは、共通ＡＰＩを介して、ＵＥシステム上のスピーカを排他的に、または調和させて使用することを要求する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
このタイプのシステムによる問題は、ＵＥ上で提供されることになる、およびＵＥの共通リソース（デバイス）にアクセスするためのルールについて認識する、サービスタイプごとの別個のサービスを必要とすることである。これにより、いくつかの制約が設けられる：
ポリシー、プレゼンス、プロファイル、およびアクティビティなどの外部の固定的でない要因は、リソースがどのように割り当てられるべきかという決定に考慮されることができない。たとえば、フットボール試合観戦について友達チャットから来るＶＯＩＰコールを処理するためのルールは、オフィスまたは他の職場環境からの着信ＶＯＩコールを処理するためのルールとは、非常に異なることがある。前者は、話し合いの進行中、バックグラウンドにフットボール試合の実況放送を含むよう望むことがあるが、後者はそうではないであろう。
【０００７】
たとえ基礎的な配信メカニズムが同じであっても、ＵＥにおいて、新たなサービスタイプごとに、新たなクライアントおよび処理ロジカルが必要とされる。
【０００８】
アプリケーションは、互いの知識を用いて書かれる必要がある。また、
アプリケーションがＵＥに配置された後に、ルールをカスタマイズし、変更する簡単なやり方はない。
【課題を解決するための手段】
【０００９】
本発明は、改良されたアービトレーションシステムを提供するための試みにおいて生じたものである。
【００１０】
本発明によれば、１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数のＵＥ（ユーザ装置）デバイスにネットワークリソースを割り当てるためにネットワーク上に配置された、ＵＥから遠隔にあるアクセス制御エージェントを含む、データ通信システムが提供される。
【００１１】
好ましくは、アクセス制御エージェントは、要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、プレゼンス、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てる。
【００１２】
ＵＥは、（たとえば閉じたＩＰネットワーク、もしくはインターネットに接続されていてよい）ＩＰＴＶ装置、あるいは、無線（たとえばＧＰＲＳ、ＵＭＴＳ、もしくは他の無線）ネットワーク、もしくは固定回線ネットワークに接続されて、他のデバイスと通信するように構成された任意の移動体端末または固定端末であってよい。
【００１３】
本発明は、アクセス制御エージェントが、ネットワーク内に、またはネットワークのバックエンドにおいて「ローカルで」提供され、それにより、ＵＥにおいて利用可能なＵＥ使用が、さまざまなタイプのマルチメディアまたは他のコンテンツにどのように使用されるべきかに関する初期の決定論理を作成する機能を、ＵＥが有するための要件を解除することを可能にする。
【００１４】
リソースがどのように使用されることができるかに関する決定は、アクセス制御エージェントに委ねられることができる。必要であれば、エージェントは、所与のマルチメディアセッションのためのリソースの割当てに先立って、プロファイル情報、プレゼンス情報、ＵＥのユーザに関連付けられた友達リストを含むパーソナリゼーション、一般的なまたは特定のポリシー、および標準のまたは特定のインターフェースを介した情報にアクセスして、それらを評価することができる。
【００１５】
ＵＥは、ディスプレイ装置、スピーカ、マイクロフォンまたはマイクロフォン入力、さまざまなデータ入力／出力デバイスの使用、その他などの利用可能ないくつかのリソースを有することができる。これらのリソースのうちのいずれの制御も、少なくとも部分的には、アクセス制御エージェントによって割り当てられることができる。
【００１６】
さらに、共有リソース（ＵＥ物理的デバイス）へのアクセスは、共通のＵＥ ＡＰＩのアブストラクション層を介して再利用されることができる。
【００１７】
初期データの要求／送信についての通知をＵＥに提供するための通知エージェントが、やはり好ましくはＵＥから遠隔でネットワークにおいて提供されてよく、通知エージェントは、同時係属出願の代理人参照番号１５３５１ＥＰに開示されているようなものでよく、その通知エージェントは、複数のソースから通知を受信することができ、複数のソースそれぞれは特定のプロトコルを使用し、共通のプロトコルを通じかつ共通のルックアンドフィールによって、これらの通知をＵＥに提供する。通知エージェントは、アクセス制御エージェントにリンクされる、またはアクセス制御エージェントの一部を形成することができ、それにより、中央ネットワークリソースまたはローカルネットワークリソースが最大限活用され、ＵＥにおいて必要とされる論理リソースおよびソフトウエアリソースが最小限にされる。
【００１８】
本発明は、ネットワーク上で提供されるＵＥのリソース使用をアービトレートし、割り当てる方法をさらに提供し、方法は、１つまたは複数のリソースを使用する要求が生じたときに、１つまたは複数のパラメータに従って、ＵＥから遠隔で提供されるアクセス制御エージェントに、ＵＥにおけるリソース使用を割り当てさせ、アービトレートさせるステップを含む。
【００１９】
本発明は、１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数の遠隔ＵＥデバイスに利用可能なリソースを割り当てる手段を含む、アクセス制御エージェントをさらに提供する。
【００２０】
本発明はまた、本明細書で開示される、新規な特徴、特徴の組合せ、ステップ、またはステップの組合せのうちのいずれか１つまたは複数を含む、システムまたは方法を提供する。
【００２１】
次に本発明の実施形態が、例のみとして、添付の概略的な図面を参照して説明される。
【図面の簡単な説明】
【００２２】
【図１】ネットワークの一部を概略的に示す図である。
【図２】第１の使用例の説明図を示す図である。
【図３】第２の使用例の説明図である。
【図４】第３の使用例の説明図である。
【発明を実施するための形態】
【００２３】
図１を参照すると、本発明の実施形態が概略的に示されている。この場合はＩＰＴＶ ＵＥ（たとえばセットトップボックスとディスプレイ）であるＵＥ１が、ネットワークに接続されて、ネットワークから多くの異なるタイプのデータを受信する。図に示されるように、ＵＥ１は、いくつかのコンポーネントを含む。
【００２４】
ＵＥ１は、ＵＥの性質によってはプロセッサであるハードウエア２と、データ記憶ハードウエア（たとえばソリッドステートおよび／またはハードディスク）と、ディスプレイと、キーボード、タッチスクリーン、入力、マウス、タッチポインタなどの１つまたは複数の入力／出力手段と、マルチメディア使用のための、１つまたは複数のラウドスピーカ２（図２）と、マイクロフォンおよび／またはマイクロフォン入力とを含む。さまざまなレベルのソフトウエアもまた含まれる。これらのソフトウエアは、オペレーティングシステムおよびデバイスドライバ３と、デバイス制御層５と、この場合はＩＭＳ（ＶＯＩＰ）アプリケーションエージェント６およびＩＰＴＶアプリケーション７である、いくつかのより特定的なアプリケーションとを含むことができる。ネットワーク上に遠隔で提供される通知エージェント９から通知を受信するように構成されたさらなるエージェント８もまた含まれてよく、最も好ましくは、同時係属出願の参考文献１５３５０ＥＰに開示されたやり方で、これらが一緒に動作する。
【００２５】
ＩＭＳ（ＶＯＩＰ）アプリケーション６は、たとえば、セッション開始プロトコル（ＳＩＰ）、リアルタイムプロトコル（ＲＴＰ）、およびセッション記述プロトコル（ＳＤＰ）のマルチメディアセッションを使用する、一般に音声タイプのアプリケーションに関する。データは、オーディオデータおよび／またはビデオデータであってよい。
【００２６】
ＩＰＴＶアプリケーションは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、インターネットグループ管理プロトコル（ＩＧＭＰ）、またはＨＴＴＰなどのプロトコルを使用することができる。このアプリケーションは、ビデオデータ、（ＩＰマルチキャストによる）ビデオ放送、ビデオオンデマンドプログラム、またはセットトップボックス１を使用する他の素材に使用されることができる。
【００２７】
他のタイプのアプリケーションレイアウトのプロトコルおよび／またはエージェントが使用されてよい。
【００２８】
ネットワークレベルでは、前記通知エージェント９を含むメディエータ１０が提供される。メディエータはまた、アクセス制御エージェント（ＡＣＡ）１１と、オーケストレーションエージェント（実際には制御装置またはワークフローエージェント）１１とを含む。メディエータはまた、ＩＭＳプラットフォームおよびＩＰＴＶプラットフォーム１３などのさまざまなデータ／通信プラットフォームにリンクする。メディエータはまた、ＵＥのユーザにはっきり限定して関連されることができるか、またはより一般的な情報であってよいかのどちらかの外部情報にアクセスすることができ、たとえばこれらは、プレゼンス１４、プロファイル１５、友達リスト１６、または他の情報１７である。
【００２９】
ＵＥのＶＯＩＰアプリケーション６は、着信ＶＯＩＰコール設定Ａ、またはユーザ動作のどちらかによってトリガされたとき、共通のデバイス制御ＡＰＩ５を介してデバイスアクセスを要求するのに先立って、メディエータ１０（アクセス制御エージェント１１）に対してアクセスを要求する。ＶＯＩＰアプリケーション６は、ネットワークを通じてアクセス制御エージェント１１にコンタクトする。このアプリケーションは、セッション／サービス初期化の間に一度だけ共有リソースへのアクセスを決定する必要があり、これは、実際のサービス配信の間にユーザ経験に対して性能低下をもたらすことにはならないことに留意されたい。
【００３０】
メディエータ（アクセス制御エージェント）は次いで、共有リソースへのアクセスレベルを決定する前に、外部情報１４から１７にアクセスすることができる。エージェントは、ＵＥにではなく、ネットワーク内部に位置するため、同じアクセス制御エージェント１１が、複数のクライアントまたはＵＥの間で共有され、アクセスインターフェースを再利用し、キャッシュを可能にすることができる。たとえば、フットボール試合を見ているＴＶ上でビデオコールまたはチャットセッションを設定しようとしている複数のＵＥから要求されたときに、ユーザプロファイル、プレゼンス、およびいくつかのサービスデータがキャッシュされ、再利用されることができる。
【００３１】
アクセス制御エージェント１１は、いくつかの条件ステップが要求される場合に、外部の構成可能なワークフロー、またはプラグ可能な決定論理を使用して、デバイスアクセスを決定することができる。ＵＥ上でのオーケストレーションの低価格実装が達成されることができる。たとえば、初期のＶＯＩＰコールＡまたは電子メールの要求に応答して、アクセス制御エージェント１１は、ＩＰＴＶプラットフォーム１３に、あらかじめＵＥに送信されているストリーミングビデオを一時停止する、またはタイムシフト機能を開始するよう要求することができる。
【００３２】
アクセス制御エージェントは、アクセス許可およびアクセスレベルをアプリケーション６または７に戻す。ＵＥアプリケーションは次いで、承諾されたアクセスレベルによってＵＥデバイスへのアクセスを要求する。次に、これを明らかにするための例が与えられることになるが、これらの例は、本発明の多くの異なる例および実施形態のうちの例示にすぎない。
【００３３】
第１の一組のシナリオが、図２および図３に示される。これは、ユーザがディスプレイ上でフットボール試合２０を見ていて、試合の実況放送が一組のラウドスピーカ３を通して中継されている場合の着信ＶＯＩＰコールに関する。アクセス制御エージェントは、異なるタイプのＶＯＩＰコールの異なる処理を可能にすることができる。
【００３４】
第１の例では、ＩＰＴＶアプリケーションが、（同時係属出願１５３５０ＥＰにより詳細に説明されるような）通知エージェント９から着信コールを受け入れるためのユーザ選択オプションを有する。ＳＩＰ ｉｎｖｉｔｅが到着し、たとえば、オーディオがＲＴＰを介してＵＥに配信される。初期の設定時間の間、アプリケーションは、ＡＣＡ１１に対して、ＵＥ上の特定のリソース、とりわけオーディオスピーカ３およびマイクロフォンへのアクセスを要求するよう要請する。ＡＣＡはプレゼンス１４を確認し、すなわち、ＶＯＩＰコールの発信者のプレゼンスを確認する。ＡＣＡが、着信コールはその特定のＵＥ１のユーザの「友達リスト」１６の誰かからであり、その発信者が同じフットボール試合を見ていることを特定すると、たとえば、共有アクセスを承諾することができる。これは、実際には、ＶＯＩＰコールからの着信オーディオがオーバーレイされる間、リアルタイムでフットボール試合がまだ見られており、実況放送が聞かれていてよいことを意味する。したがって、アプリケーションは、バックグラウンドの（減衰された）試合の実況放送の上に、オーディオをオーバーレイする。これは、図２の第２の部分に示されており、ここでは、スピーカ３が発するサウンドが、実況放送とＶＯＩＰオーディオを表す。実況放送は、ＶＯＩＰオーディオがよりはっきりと聞かれることができるように、通常減衰されることになる。
【００３５】
あるいは、着信ＶＯＩＰコールが、たとえば、ユーザの職場から、または学校にいるユーザの子供から来ていることが特定されると、ユーザがそのメッセージに十分な注意を注ぐことがより重要であることがある。この場合は、オーディオおよびマイクロフォンへの排他的なアクセスが承諾される。これは図３に示される。最初は、フットボール試合２０が見られ、実況放送２１がスピーカから出力される。
【００３６】
上記に特定されたこれらのより重要な状況では、ＶＯＩＰオーディオ２２は次いで、実況放送なしに、単独２２でスピーカから出力される。フットボール試合または他のＩＰＴＶプログラムは、オプションでキャンセルされる、またはプロファイルのプレゼンスに基づいて一時停止されることができる。図３は、その第２の部分において、フットボール試合がどのようにしてスクリーンからキャンセルされて、それによりユーザがＶＯＩＰコールに十分な注意を払うことができるかを示す。しかしながら、代替として、試合はスクリーン上で単に一時停止されてもよい。オプションで、ＡＣＡは、オーケストレーションをトリガして、追加の情報、たとえばウェブページ、またはコールする人のコンタクトの詳細を含むウェブページへの参照、コールする人に関連付けられた記録などを、コールの間に配信することができる。
【００３７】
図４に概略的に図示されたさらなるシナリオでは、ＩＰＴＶシステムのユーザが再びフットボール試合を見ており、この場合では、ユーザはビデオコールすることを決める。ＩＰＴＶビデオコールアプリケーションより、ユーザは自分の「友達リスト」から自分の友達にコールすることを選択する。ビデオコールアプリケーションは、その友達についてプロファイル１５を検索するＡＣＡ１１にアクセスする。この場合、ＡＣＡは、ビデオコールおよびＶＯＤセッション（ライブのフットボール試合）の両方が、同時には処理されることができないことを判定する。したがって、ＡＣＡは、コールの間、ＩＰＴＶアプリケーションからのビデオ／オーディオリソースへのアクセスを拒否する。ビデオアプリケーションはビデオを停止し、制御はビデオコールアプリケーションに排他的に渡される。このようにして、ユーザは次にビデオコール２３で自分が話している相手を見ることができ、ビデオコールからのオーディオがスピーカ２４を通して出力される。
【００３８】
当然ながら、多くの例が明らかであるだろう。これらの例では、共有ＵＥリソースへのアクセスは、特定のユーザ環境用に個人化されることに留意されたい。加えて、アクセス制御エージェントによってＵＥに与えられるアクセスレベルは、ＵＥそのものによってではなく、ＡＣＡエージェントによって決定されるので、それぞれのアプリケーションは、互いを認識する必要が全くない。
【００３９】
本発明のいくつかの実施形態では、ＡＣＡが外部条件に基づいてアクセス権を提供することができる。すなわち、ＡＣＡは、ビデオアプリケーションのビデオを拒否し、オーディオを拒否し、ディスクへの正当なアクセスを拒否することなどができる。これは、特定のデバイスが、子供からのＶＯＩＰコール、ＳＭＳのプレゼンテーション、または他の目的などの、他の優先順位の高いサービスに必要とされる場合に発生することがある。特定の一例は、高帯域幅のビデオコールが発信される、または設定されるように要求される場合である。
【００４０】
サービス品質（ＱｏＳ）は、リソースの割当てを決定するもう１つのパラメータであってよい。たとえば、コールまたはデータ要求の発信者が「プレミアム」の顧客である場合、ＡＣＡは、自動的により高いＱｏＳを要求することができてよく、低いプレミアムの顧客に対するよりも、ＵＥ上のハードウエアリソースおよびソフトウエアリソースへの高いアクセスを取得することができる。ユーザ設定、ビデオコールのビットレート／解像度、または単に１つのタイプのサービス要件が（さまざまな規準を介して）別のものよりも重要であるかどうかの基準など、他の要因が決定を行うのに使用されてよい。たとえば、ビデオコールのコンテンツが、いつでも見られる特定のＶＯＤ放送よりも重要である場合、コールの発信者はＶＯＤよりも重要である、などである。２つの競合するサービスがリソースを求めて対抗しているとき、アクセス制御エージェントは、これらのうちのどちらがリソースを使用するか、またはどちらが使用のより高いレベルを獲得するかを決定するのに使用されることができる。
【００４１】
実際には、サービスの一定レベルを決定し、リソースの割当てを決定するための責任が、ＵＥから解除され、ネットワーク上に遠隔で配置されたアクセス制御エージェントに移される。アクセス制御エージェントは、外部システムとの連絡を保って、これを決定する。
【００４２】
多くの異なるルールおよびシナリオが明らかであろう。
【００４３】
本発明の実施形態では、ＵＥは、しばしば異なるアクセスインターフェースを必要とする異なる外部ソースの情報（プレゼンス、プロファイル、友達リストなど）に、どのようにアクセスするかを知る必要がないことに留意されたい。代わりに、ＵＥは、単一のＡＣＡと通信する必要があり、それにより、ＵＥからネットワークへと複雑さを移動させる。ＡＣＡは次いで、これらの通信を処理する。
【特許請求の範囲】
【請求項１】
１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数のＵＥ（ユーザ装置）デバイスにリソースを割り当てるためにネットワーク上に配置された、ＵＥから遠隔にあるアクセス制御エージェントを含む、データ通信システム。
【請求項２】
アクセス制御エージェントが、要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、プレゼンス、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てる、請求項１に記載のシステム。
【請求項３】
ＵＥがＩＰＴＶ装置である、請求項１に記載のシステム。
【請求項４】
アクセス制御エージェントが、所与のマルチメディアセッションのためのリソースの割当てに先立って、プロファイル情報、プレゼンス情報、ＵＥのユーザに関連付けられた友達リストを含むパーソナリゼーション、一般的なまたは特定のポリシー、および標準のまたは特定のインターフェースを介した情報のうちの１つまたは複数に基づいて決定を行う、請求項１に記載のシステム。
【請求項５】
リソースが、スピーカ、ディスプレイ、マイクロフォンまたはマイクロフォン入力、さまざまなデータ入力／出力デバイスの使用のうちのいずれか１つまたは複数を含む、請求項１に記載のシステム。
【請求項６】
それぞれが特定のプロトコルを使用し、共通のプロトコルを通じてＵＥに通知を提供する複数のソースから、通知を受信するように構成された通知エージェントを含む、請求項１に記載のシステム。
【請求項７】
アクセス制御エージェントが、複数のＵＥの間で共有され、データをキャッシュするためのキャッシュを含む、請求項１に記載のシステム。
【請求項８】
ＵＥから遠隔の外部データソースが、プロファイル、プレゼンス、パーソナリゼーション、またはポリシー情報を決定するためにアクセスされる、請求項２に記載のシステム。
【請求項９】
１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数の遠隔ＵＥデバイスに利用可能なリソースを割り当てる手段を含む、アクセス制御エージェント。
【請求項１０】
要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てるように構成された、請求項１に記載のアクセス制御エージェント。
【請求項１１】
１つまたは複数のリソースを使用する要求が生じたときに、１つまたは複数のパラメータに従って、ＵＥから遠隔で提供されるアクセス制御エージェントに、ＵＥにおけるリソース使用を割り当てさせ、アービトレートさせるステップを含む、ネットワーク上で提供されるＵＥのリソース使用をアービトレートし、割り当てる方法。
【請求項１２】
ＵＥがＩＰＴＶデバイスである、請求項１１に記載の方法。
【請求項１３】
パラメータが、プロファイル、プレゼンス、パーソナリゼーション、およびポリシーのうちの１つまたは複数を含み、ＵＥに対して遠隔のソースからＡＣＡに提供される、請求項１１に記載の方法。
【請求項１４】
ＵＥリソースへのアクセスが、共通ＵＥ ＡＰＩのアブストラクション層を介して見直される、請求項１３に記載の方法。
【請求項１５】
それぞれが特定のプロファイルを使用し、共通のプロトコルを通じてＵＥに通知を提供する、複数の通知ソースと通信する、ＵＥから遠隔の通知エージェントによって、ＵＥへの初期通知が処理される、請求項１１に記載の方法。
【請求項１６】
必要であれば、ＡＣＡが追加の情報をＵＥに配信するように構成された、請求項１１に記載の方法。
【請求項１７】
追加の情報が、ウェブページまたはウェブページへの参照として配信される、請求項１１に記載の方法。
【請求項１】
１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数のＵＥ（ユーザ装置）デバイスにリソースを割り当てるためにネットワーク上に配置された、ＵＥから遠隔にあるアクセス制御エージェントを含む、データ通信システム。
【請求項２】
アクセス制御エージェントが、要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、プレゼンス、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てる、請求項１に記載のシステム。
【請求項３】
ＵＥがＩＰＴＶ装置である、請求項１に記載のシステム。
【請求項４】
アクセス制御エージェントが、所与のマルチメディアセッションのためのリソースの割当てに先立って、プロファイル情報、プレゼンス情報、ＵＥのユーザに関連付けられた友達リストを含むパーソナリゼーション、一般的なまたは特定のポリシー、および標準のまたは特定のインターフェースを介した情報のうちの１つまたは複数に基づいて決定を行う、請求項１に記載のシステム。
【請求項５】
リソースが、スピーカ、ディスプレイ、マイクロフォンまたはマイクロフォン入力、さまざまなデータ入力／出力デバイスの使用のうちのいずれか１つまたは複数を含む、請求項１に記載のシステム。
【請求項６】
それぞれが特定のプロトコルを使用し、共通のプロトコルを通じてＵＥに通知を提供する複数のソースから、通知を受信するように構成された通知エージェントを含む、請求項１に記載のシステム。
【請求項７】
アクセス制御エージェントが、複数のＵＥの間で共有され、データをキャッシュするためのキャッシュを含む、請求項１に記載のシステム。
【請求項８】
ＵＥから遠隔の外部データソースが、プロファイル、プレゼンス、パーソナリゼーション、またはポリシー情報を決定するためにアクセスされる、請求項２に記載のシステム。
【請求項９】
１つまたは複数のパラメータに従って、ネットワーク上で１つまたは複数の遠隔ＵＥデバイスに利用可能なリソースを割り当てる手段を含む、アクセス制御エージェント。
【請求項１０】
要求されるリソースのタイプおよび性質に従って、ならびにプロファイル、パーソナリゼーション、ポリシー、または他の情報のうちの１つまたは複数に従って、リソースを割り当てるように構成された、請求項１に記載のアクセス制御エージェント。
【請求項１１】
１つまたは複数のリソースを使用する要求が生じたときに、１つまたは複数のパラメータに従って、ＵＥから遠隔で提供されるアクセス制御エージェントに、ＵＥにおけるリソース使用を割り当てさせ、アービトレートさせるステップを含む、ネットワーク上で提供されるＵＥのリソース使用をアービトレートし、割り当てる方法。
【請求項１２】
ＵＥがＩＰＴＶデバイスである、請求項１１に記載の方法。
【請求項１３】
パラメータが、プロファイル、プレゼンス、パーソナリゼーション、およびポリシーのうちの１つまたは複数を含み、ＵＥに対して遠隔のソースからＡＣＡに提供される、請求項１１に記載の方法。
【請求項１４】
ＵＥリソースへのアクセスが、共通ＵＥ ＡＰＩのアブストラクション層を介して見直される、請求項１３に記載の方法。
【請求項１５】
それぞれが特定のプロファイルを使用し、共通のプロトコルを通じてＵＥに通知を提供する、複数の通知ソースと通信する、ＵＥから遠隔の通知エージェントによって、ＵＥへの初期通知が処理される、請求項１１に記載の方法。
【請求項１６】
必要であれば、ＡＣＡが追加の情報をＵＥに配信するように構成された、請求項１１に記載の方法。
【請求項１７】
追加の情報が、ウェブページまたはウェブページへの参照として配信される、請求項１１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１１−５１５７２２（Ｐ２０１１−５１５７２２Ａ）
【公表日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願番号】特願２０１０−５４２５６３（Ｐ２０１０−５４２５６３）
【出願日】平成２１年１月７日（２００９．１．７）
【国際出願番号】ＰＣＴ／ＥＰ２００９／００００２９
【国際公開番号】ＷＯ２００９／０９２５１２
【国際公開日】平成２１年７月３０日（２００９．７．３０）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願日】平成２１年１月７日（２００９．１．７）
【国際出願番号】ＰＣＴ／ＥＰ２００９／００００２９
【国際公開番号】ＷＯ２００９／０９２５１２
【国際公開日】平成２１年７月３０日（２００９．７．３０）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]