プラガブルコンタクトレゾリューション
【課題】 プラガブルな拡張を実現する。
【課題を解決するための手段】 プリファードで、ユーザー指向型なアラートする関係を取り扱うためのユーザー集団のユニークなセットに、適用するための、方法、デバイス及びシステムを提供する。プラガブルな拡張は、ユーザーが、彼らから発せられた、または彼らの方に向けられたコールについてサーバで適用されるパーソナライズしたコンタクトレゾリューションアルゴリズムを持つことを、許容する。コンタクトレゾリューションアルゴリズムは、いずれのサーバにもプラガブルで、サーバ自身には内蔵する必要がない。更には、複数のユーザーが同一のプラガブルなコンタクトレゾリューションアルゴリズムを参照し、使用することができる。
【課題を解決するための手段】 プリファードで、ユーザー指向型なアラートする関係を取り扱うためのユーザー集団のユニークなセットに、適用するための、方法、デバイス及びシステムを提供する。プラガブルな拡張は、ユーザーが、彼らから発せられた、または彼らの方に向けられたコールについてサーバで適用されるパーソナライズしたコンタクトレゾリューションアルゴリズムを持つことを、許容する。コンタクトレゾリューションアルゴリズムは、いずれのサーバにもプラガブルで、サーバ自身には内蔵する必要がない。更には、複数のユーザーが同一のプラガブルなコンタクトレゾリューションアルゴリズムを参照し、使用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には通信に関連し、より明確には、ポータブルでユーザー指向型（ｕｓｅｒ−ｃｅｎｔｒｉｃ）のコンタクトレゾリューション（ｃｏｎｔａｃｔ ｒｅｓｏｌｕｔｉｏｎ）メカニズムに関連する。
【背景技術】
【０００２】
セッションイニシエーションプロトコル（ＳＩＰ）は、多数の種類のリアルタイムの通信セッションを確立するためのオープンシグナリングプロトコルである。ＳＩＰを使用して確立される通信セッションのタイプの例は、音声、画像、及び／または、インスタントメッセージングを含む。これらの通信セッションは、パーソナルコンピュータ、ラップトップコンピュータ、個人情報端末のような、いかなるタイプの通信デバイス上でも実行される。ＳＩＰの1つの重要な特徴は、全ての通信のために、単一の統合した公衆アドレスとして、エンドユーザーのアドレスオブレコード（ＡＯＲ）を使用する能力である。このように、ＳＩＰ機能強化通信の世界では、ユーザーのＡＯＲはそのユーザーに関連する全ての通信デバイスにユーザーをリンクする単一のアドレスとなる。このＡＯＲを使用して、発呼者は、各々の固有のデバイスアドレスや電話番号を知る必要はなく、ユーザーエージェント（ＵＡ）としても参照されて、ユーザーのいずれか１つの通信デバイスに到達することができる。
【０００３】
ＳＩＰセッションの確立の間に遂行されるステップの１つは、与えられたユーザーに登録された、どのデバイスが、与えられたコールの際にアラート（ａｌｅｒｔ）するかを決定する、コンタクトレゾリューションである。伝統的なシステムでは、ユーザーのためのコンタクトレゾリューションポリシー（どのデバイスをリングするか、どのようにリングするかなどに関してなされる決定）は、ＰＢＸの中に組み込まれており、設定済み（ｐｒｏｖｉｓｉｏｎｅｄ）の電話セットのためだけに機能した。このように、コンタクトレゾリューションポリシーに関するユーザーの選択は、ＰＢＸのリリースと電話デバイスに固有であった。ＳＩＰでは、このことは極めて望ましくない。なぜなら、隠されたＩＰネットワークが、ユーザーによって登録されたいくつものＳＩＰ通信デバイスのための、一般目的のアタッチメントメカニズムとなるからである。自分のデバイスのどれが登録されるか、接続されるか、稼働可能とされるか、また、これらのデバイスのそれぞれがどんな目的で使用されるか、を決定するのは、ＳＩＰユーザー自身である。ＳＩＰでは、コンタクトレゾリューションは、従来はロケーションサーバでなされていた。しかしながら、ＰＢＸのように、ロケーションサーバを、新たなコンタクトレゾリューションの動作を提供することができるように、再びデプロイ（ｄｅｐｌｏｙ）することは、しばしば、望ましくないことである。それゆえ、ユーザーが、一般的に特別なＰＢＸまたは通信フィーチャーサーバまたはネットワークのロケーションサーバの改変を必要とすることなしに、システム／ネットワークアドミニストレータによって彼らに代わって容易に提供される、コンタクトレゾリューションポリシーとアクセスを持つことが望ましい。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願１２／２４１３６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の実施の形態は、コンタクトレゾリューションポリシーまたはアルゴリズムを、ユーザー、特にＳＩＰユーザーのために可能にするメカニズムを提供する。多くの企業が、ＳＩＰユーザーに、単純なｑ値（ｑ−ｖａｌｕｅ）として、ロケーションサーバで、各々のデバイスまたはネットワークのための彼らのプリファレンス（ｐｒｅｆｅｒａｎｃｅ）を登録することを許している。ＳＩＰでは、ロケーションサーバの役割は、ユーザーのポリシーに従って、ＳＩＰリクエストを、各々の登録したコンタクトへ送信することを仲介することである。これは、従来、ユーザーポリシーを履行する静的なアルゴリズムの中のｑ値を評価することによってなされた。いくつかの共通に用いられるポリシーには、シーケンシャルフォーキング（各々のデバイスに順番コンタクトする）、パラレルフォーキング（全てのデバイスに同時にコンタクトし、最初に応答したデバイスをコンタクトの勝者と認める）、及びロードバランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）が含まれる。本発明の実施の形態は、ネットワークアドミニストレータが、ネットワークのユーザーに対して新たなアルゴリズムの選択を「ホットデプロイ（ｈｏｔ ｄｅｐｌｏｙ）」することを許し、また、ユーザーが、企業のネットワークの中で使用しうる、どんなデプロイされたコンタクトレゾリューションポリシーまたはアルゴリズムをも選択し、任意にパーソナライズすることを許す。より明確には、本発明の実施の形態は、ユーザーが、プラガブル（ｐｌｕｇｇａｂｌｅ）コンタクトレゾリューションアルゴリズム（シリアルフォーキング、パラレルフォーキング、スマートロードバランシング、発呼者識別に基づきリングを代えるなど）を見つけ出し、使用することを許すメカニズムを提供する。しばしばプラガブルコンタクトレゾリューションアルゴリズムは、アドミニストレータまたはアドミニストレータの許可を得た他のユーザーによってデプロイされる。しかし、本発明の実施の形態は、それに限定されず、アドミニストレータではないユーザーが、プラガブルコンタクトレゾリューションアルゴリズムを、個人の使用及び／または、他のユーザーの使用のために、開発し、デプロイすることも許容される。プラガブルコンタクトレゾリューションアルゴリズムをデプロイするように選ばれたどんなユーザーも、そのようなコンタクトレゾリューションアルゴリズムをリファインし、カスタマイズすることが、適用する際には許される。
【０００６】
インバウンド（ｉｎｂｏｕｎｄ）コンタクトを、ユーザーのために受信したときに、どのＣＲＡ（コンタクトレゾリューションアルゴリズム）を使用すべきか（すなわち、どの拡張モジュールが参照されるべきか）を示すテーブルエントリーと関連して、コンタクトレゾリューションアルゴリズムを含む拡張モジュールが使用される。
【０００７】
拡張モジュールは、個々にデプロイし、またはデプロイしないようにできる、自給自足式（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）のジャーファイル（ｊａｒ ｆｉｌｅ）である点で、ＳＩＰサーブレット（ｓｅｒｖｌｅｔ）に似ている。ＳＩＰサーブレットは、ＳＩＰ機能をサポートするためにその中に搭載されたインターフェースを強化する点で、他のタイプのサーブレットに似ている。別のタイプのサーブレットの例は、ｈｔｔｐサーブレットであり、これは、ウェブサーバまたはアプリケーションサーバの中で動作し、典型的にはデータベースにアクセスする、またはｅ−コマース処理を実行するような、サーバ側の処理を提供する、Ｊａｖａ（登録商標）アプリケーションである。それは、ＣＧＩスクリプト（ＣＧＩ ｓｃｒｉｐｔｓ）、アクティブサーバページ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ、ＡＳＰｓ）及びＣ及びＣ＋＋で書かれたプロプライアトリプラグイン（ｐｒｏｐｒｉｅｔｒｙｐｌｕｇ−ｉｎｓ）の、Ｊａｖａベースの置き換えである。サーブレットはＣＧＩコンセプトに類似するが、分離したプロセスを使う代わりに、メッセージはサーバ内部のバーチャルマシンの中で動作するクラスに伝達される。
【０００８】
多数のサーブレットは、サーバとオペレーティングシステムの間で可搬性を許容するように、特定のプログラム言語（例えばＪａｖａ）で書かれる。Ｊａｖａは、サーブレットまたは拡張モジュールを創作するために使用されるプログラム言語の一例であるが、本発明の実施の形態はそれに限定されないことを、この技術分野の当業者は理解するであろう。より明確には、本発明の実施の形態は、拡張モジュールがサーバとオペレーティングシステムの間で可搬性を持つことを許容するような、いずれかのタイプのプログラム言語での、拡張モジュールの創作を意図している。本発明の実施の形態は、また、サーバ（例えば、企業サーバで、特にＳＩＰサーバ）上のバーチャルマシンの内部で動作することができる拡張モジュールを意図している
【０００９】
しかしながら、ＳＩＰサーブレットと違って、拡張モジュールは、ホットデプロイ可能である。拡張モジュールは、サービスの損失なく、稼働中のアップグレードが可能である。本発明の少なくともいくつかの実施の形態に応じて、拡張モジュールは、インカミング（ｉｎｃｏｍｉｎｇ）コンタクトが受信されたときに、特定のユーザーが得るコンタクトレゾリューションの形式を改変するための、ＳＩＰダイアログアダプテーション（ｄｉａｌｏｇ ａｄａｐｔａｔｉｏｎ）の中で使用される。より明確には、個々のダイアログアダプテーション論理は、各々のアダプターのために、サーブレットとしてよりも、拡張モジュールとして、履行されることができる。拡張モジュールのホットスワップ（ｈｏｔ ｓｗａｐ）能力に加えて、拡張モジュールの使用は、より容易なマネジメント及び共通のダイアログアダプテーション論理がシェアされることを許容する。拡張モジュールと伝統的なＳＩＰサーブレットの別の相違は、ＳＩＰサーブレットインタフェースのみを想定しているＳＩＰサーブレットとは違って、拡張モジュールはサービスに供される多数のインタフェースを定義しうることである。
【００１０】
更に、また、本発明の少なくともいくつかの実施の形態に応じて、拡張モジュールは、サーブレット、アプリケーションルータ、及び／または、他のＳＩＰアプリケーションによってアクセスされ得るサービスに供されるために使用される。いくつかの実施の形態では、拡張モジュールは、デプロイの間に定義される（通常は、システムアドミニストレータによって定義される）ユニークな短いＩＤに結びつけられる。拡張モジュールは、そのサービスを供するインタフェースもまた、定義する。必要な場合には、拡張ＡＰＩは、短いＩＤを用いて、拡張モジュールの検索を支援する。拡張モジュールは、デプロイ可能な自給自足式のジャーであるから、拡張モジュールのためのコンフィグレーション情報は、拡張モジュールを履行するクラスファイル（ｃｌａｓｓ ｆｉｌｅ）と一緒に、ジャーファイルの中に含まれている。コンフィグレーション情報は、サーブレットと同じ方式で、デプロイ形ＸＭＬファイルの中に定義されている。
【００１１】
オペレーションでは、各々の遠隔のパーティは、サービスホスト拡張モジュールとして履行されるインバウンド及びアウトバウンドのダイアログアダプテーションロジックと関連づけられる。（コンタクトレゾリューションのような）ダイアログアダプテーションを必要とするいずれかのサービスが、拡張モジュールの識別子（ｉｄｅｎｔｉｆｉｅｒ）（すなわち、拡張モジュールにアサインされたユニークな短いＩＤ）を介して、アダプテーションモジュールを呼び出す（ｉｎｖｏｋｅ）。
【００１２】
コンタクトレゾリューションリクエストが受信されたときに、どのＣＲＡが使用されるべきかを示すテーブルエントリーに加えて、この拡張モジュールが使用される。本発明の少なくともいくつかの実施の形態に応じて、テーブルは、ユーザーに関連する、設定済みの、または、ダイナミックなデータを含んでいる。テーブルの中に、ユーザーは、コンタクトが受信されたときはいつでも適用を望む、デプロイされたＣＲＡとのパーソナルな関係を定義することができる。より明確には、特定のユーザーに関するテーブルは、特定のＣＲＡに適用する、拡張モジュールの識別子を含むであろう。ユーザーオプションをセットするために、別のウェブインタフェースを通して、ユーザーによって、希望したように、コンフィギュア（ｃｏｎｆｉｇｕｒｅ）される、または、再びコンフィギュアされる、この拡張と関連づけられたユーザー指向のデータがある。より明確には、一旦、テーブル内に、ユーザーデータコンフィグレーション（ｃｏｎｆｉｇｕｒａｔｉｏｎ）または再コンフィグレーションが発生すると、アクティブなＣＲＡの正当性チェックが、理解力のあるエンドポイントによる登録または再登録の間に、発生する。
【００１３】
コンタクトレゾリューションの要求が受信されたときに、拡張モジュールが呼び出される。このように、コンタクトレゾリューションは、プラガブルで、ＳＩＰロケーションサーバ自身に組み込まれる必要がない。更に、複数のユーザーが同一の拡張モジュールを参照し、自身のパーソナライズしたユーザーセッティングで、同じまたは類似のＣＲＡを適用することができる。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明の少なくともいくつかの実施の形態に応じて、一般的に、
−第１サーバで、第１ユーザーに宛てられたコンタクトレゾリューションリクエストを受信し、
−第１ユーザーのための、コンタクトレゾリューションプリファレンスを識別し、
−第１ユーザーのための、コンタクトレゾリューションプリファレンスが、コンタクトレゾリューションの一部として、拡張モジュールを使用することを決定し、
−第１サーバによって、そのリクエストに対する拡張モジュールに、ユーザープリファレンスオプションを適用する、拡張モジュールを呼び出す、
ことからなる、通信方法を提供する。
【図面の簡単な説明】
【００１５】
【図１】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションシステムを表すブロック図。
【図２】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションシステムの要素を表すブロック図。
【図３】本発明の少なくともいくつかの実施の形態による、ユーザーが、コンタクトレゾリューションアルゴリズムを定義することを許可する方法を表すフロー図。
【図４】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションの方法を表すフロー図。
【発明を実施するための形態】
【００１６】
本発明は、典型的な通信システムと関連して、以下に例示される。例えばサーバまたは／及びデータベースを用いたシステムとともに用いられるのによく適合するが、本発明は、通信システムまたはシステム要素のコンフィギュレーションの、いかなる特定のタイプにも限定されない。この技術分野の当業者は理解するであろうが、開示された技術は、特にＳＩＰ環境において、ユーザーに、コンタクトレゾリューションアルゴリズムをパーソナライズさせることを必要とするいかなる通信アプリケーションにおいても使用することができる。
【００１７】
本発明の典型的なシステムと手法は、分析ソフトウェア、モジュール、及び関連する分析ハードウェアに関連して記述される。しかしながら、本発明の不必要な不明瞭化を避けるため、この後の記述は、よく知られた構造、要素を省略し、また、ブロックダイアグラムフォームで示される装置は、よく知られたものであり、または、他の方法で要約されている。
【００１８】
説明の目的で、本発明の完全な理解を提供するために、数多くの詳細が発表される。しかし、本発明は、ここに開示された特定の詳細を越えて、種々の方法で実施されうることを理解されるべきである。
【００１９】
最初に図１を参照して、典型的な通信システム１００を、本発明の少なくともいくつかの実施の形態に応じて、説明する。より明確には、通信システム１００は、ユーザー登録サーバ１１２と１以上の通信デバイス１０８を相互接続するために設けられた通信ネットワーク１０４を含んでいる。
【００２０】
通信ネットワーク１０４は、いかなるタイプの既知の通信手段またはそれらの集合であってもよく、エンドポイント間のメッセージの伝達のためのいかなるタイプのプロトコルも含んでもよい。通信ネットワーク１０４は、有線及び／または無線の通信技術を含む。インターネットは通信ネットワーク１０４の一例であり、それを構成する、世界中に置かれた多数のコンピュータやその他の通信デバイスからなるＩＰネットワークは多数の電話システムやその他の手段を介して接続されている。通信ネットワーク１０４の他の例は、標準の従来型単純電話システム（ＰＯＴＳ）、サービス総合デジタル網（ＩＳＤＮ）、公衆交換電話網（ＰＳＴＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、セッションイニシエーションプロトコル（ＳＩＰ）ネットワーク、いかなるタイプの企業ネットワーク、この技術分野で知られているいかなるその他のタイプのパケット交換またはサーキット交換ネットワークを含み、これに限定されない。更に、通信ネットワーク１０４は1つのネットワークタイプに限定されず、いくつかの異なるネットワーク及び／またはネットワークタイプから構成されてもよい。
【００２１】
通信デバイス１０８は、パーソナルコンピュータ、ラップトップ、個人情報端末（ＰＤＡ）、携帯電話、スマートフォン、電話、アナログフォン、ＤＣＰフォン、またはそれらの組み合わせのような、周知のどんなタイプの通信または処理デバイスであってもよい。1つの通信デバイス１０８は、単独のユーザーに制御され、または関連づけられていてもよいし、多数のユーザーの使用に供されてもよい。（すなわち、企業の通信デバイスが、企業のユーザーに、有効なユーザー名とパスワードの提示による使用を許可するような場合である。）
【００２２】
通信デバイス１０８の各々は同一ユーザーと関連づけられてもよい。言い換えれば、通信デバイス１０８は単独のユーザーに属してもよく、また、異なるタイプの通信デバイスに対応してもよい。一例として、ユーザーが、それぞれが単一ユーザーの個人電話、業務電話、パソコン、Ｅメール検索デバイスに対応するような、４つの通信デバイス１０８を持ってもよい。代替として、通信デバイス１０８の各々が、異なるユーザーに所有され、操作され（すなわち関連づけられ）ていてもよい。
【００２３】
一般的に、通信デバイス１０８は、他の通信デバイス１０８との、ビデオ、オーディオ、テキスト、及び／またはデータの通信をサポートするように適合されている。通信デバイス１０８によって他の通信デバイス１０８と通信するために使用される媒体のタイプは、通信デバイス１０８において利用できる通信アプリケーションに依存する。
【００２４】
ユーザー登録サーバ１１２は、多数のユーザーが、１つ以上の通信デバイス１０８を操作するためのユーザープリファレンスを受け取り、記憶するようになっている。より明確には、ユーザーはユーザー登録サーバ１１２にログインし、そのユーザーが関与しているどんな通信セッションにも適用することができる、特定のプリファレンス（すなわちユーザープリファレンス）を定義することが許可される。これらのユーザープリファレンスはユーザーに対して全世界的に定義され得る。（すなわち、単一のセットのユーザープリファレンスが、どんなネットワークでも、そのユーザーに関連づけられたどんな通信デバイスにも一貫して適用されうる。）代替として、ユーザーは、異なるネットワークまたはユーザーケースのために、異なるユーザープリファレンスを定義することも許される。（すなわち、あるユーザーが異なる家庭用と業務用のプリファレンスを持ちうる）あるユーザーは、また、各々の通信デバイス１０８のために、異なるユーザープリファレンスを定義することも許される。一例として、ユーザーは第１セットのコンタクトレゾリューションプリファレンス（すなわち、第１ＣＲＡ）をモバイル通信デバイス１０８に定義し、第２の異なるセットのコンタクトレゾリューションプリファレンス（すなわち第２ＣＲＡ）を業務用通信デバイスに定義し、第３の異なるセットのコンタクトレゾリューションプリファレンス（すなわち第３ＣＲＡ）を家庭用の通信デバイスに定義することができる。これらの異なるユーザープリファレンスは、ユーザー登録サーバ１１２上で、単一のセットのユーザープリファレンス１１６に結合されて記憶されうる。例えば、いくつかのデバイスのサブセットではパラレルフォーキング（ｆｏｒｋｉｎｇ）を使用して処理され、別のサブセットではシーケンシャルフォーキングを使用して処理されるというように、類似のＣＲＡの階層構造に連鎖する、または階層構造を形成することは有効である。このような実施の形態では、ＣＲＡの間の連鎖を処理する高レベルのコーディネイターが存在し得る。また、デバイス毎のベースでは、デバイスに固有のコンタクトレゾリューションの振る舞いが変化するために、アルゴリズムは、一日の中の時間、週の中の曜日、デバイスの状態などの事象に敏感である。
【００２５】
代替として、単一のコンタクトレゾリューションプリファレンス（すなわち、単一ＣＲＡ）が、そのユーザーに関係づけられた全ての通信デバイス１０８の間で、コンタクトをレゾルブ（ｒｅｓｏｌｖｅ）するために用いられる。言い換えれば、単一のＣＲＡが、特定の通信デバイス１０８がアラートされるべきかどうか、いつアラートされるべきか、どのようにアラートされるべきかを決めるために用いられる。本発明の、少なくともいくつかの実施の形態に関連して用いられ得る、このようなＣＲＡの例は、更に詳しく、米国特許出願番号１２／２４１，３６８号（ブルンソン他）に記述されており、その全文は、参考としてここに組み込まれる。
【００２６】
本発明の少なくともいくつかの実施の形態に応じて、ユーザーは通信デバイス１０８を経由してユーザー登録サーバ１１２で自らのユーザープリファレンス１１６を更新及び／または変更することが許される。言い換えれば、ユーザーは、通常はある種のウエブユーザーオプションインターフェースを介して、ユーザープリファレンス１１６を設定するために、ユーザー登録サーバ１１２に接続するであろう。本発明の少なくともいくつかの実施の形態に応じて、プラガブルＣＲＡは、ユーザーがユーザープリファレンス１１６をセットするために、ウエブユーザーオプションインターフェースをサポートするようにする。これらのユーザーオプションは、企業データベースのようなローカルなデータ記憶装置に記憶され、及び／または、ユーザープリファレンス１１６としてユーザー登録サーバ１１２の中に記憶される。これらのプリファレンス１１６は、それから、コール処理のコンタクトレゾリューションフェーズの間に、ユーザープリファレンス１１６を呼び出す、１以上のネットワークデバイスに分配される。
【００２７】
本発明の少なくともいくつかの実施の形態に応じて、ユーザープリファレンス１１６は、（１または複数の通信デバイス１０８のための）プリファードＣＲＡを定義するパラメータを含む。ユーザーがユーザープリファレンス１１６を更新したときには、ユーザープリファレンスの変更が、そのようなプリファレンスが適用されるどんなデバイスにもネットワークを通じて分配される。典型的には、ネットワークには、ユーザーのＣＲＡ選択を知る必要のある、ごく少数の（例えば２または３の）デバイスが存在する。しかし、本発明の実施の形態は、そのようには制限されず、ユーザープリファレンス１１６の変更は、どんな数のネットワークデバイスにも分配されうる。これらのプリファレンスは、これから詳細が議論されるように、ユーザープロビジョンドテーブルに記憶される。
【００２８】
本発明の実施の形態は、ネットワークが、その操作が有害に影響されることなく、稼働している間に、新たなＣＲＡがネットワークにデプロイされるような状況を意図している。（すなわちアドミニストレータがホットプラガブルＣＲＡを拡張モジュールの形でネットワークに追加することができる。）言い換えれば、ネットワークのアドミニストレータが新たなＣＲＡを、１つのネットワークに、または、そのデバイスによって後に受信されたコンタクトに適用される１つのネットワークデバイスに、追加することを許容する。本発明の少なくともいくつかの実施の形態に応じて、そのようなＣＲＡがネットワークに追加されたときに、ネットワークの１以上のユーザーがその更新を通告され得る。この通告に対応して、ユーザーは、新たに追加されたＣＲＡを適用すべく、ユーザープリファレンス１１６を改変することを許される。（通告に対応して直接的に、または分離してユーザー登録サーバ１１２にアクセスして間接的に）再び、ユーザーは、いずれのタイプの、既知の、またはこれから開発されるウエブオプションインターフェースを介して、ユーザープリファレンス１１６にアクセスし、更新することが許される。このようなプロセスの詳細は、更に細かく、以下で検討される。
【００２９】
ユーザーがユーザープリファレンス１１６を更新することを許可されることの、代替として、または追加として、ネットワークアドミニストレータもまた、ユーザープリファレンス１１６を更新することを許されことがある。従って、新たに加えられたＣＲＡを呼び出すための、ユーザープリファレンス１１６の改変は、ユーザー及び／または、ネットワークアドミニストレータによって実行されうる。
【００３０】
更に、ユーザープリファレンス１１６はパスワードまたは類似のタイプの真正証明（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｒｅｄｅｎｔｉａｌ）によって書き込み保証されうる。このように、一例として、ユーザー名として適切なパスワードの準備なしでは、ユーザーまたはアドミニストレータはユーザープリファレンスを改変しえない。ユーザープリファレンス１１６を更新する、ユーザー及び／または、アドミニストレータの能力を制限する他の代替案は予想され、ネットワークセキュリティの要求に応じて変化しうる。
【００３１】
ここで、図２を参照し、本発明の少なくともいくつかの実施の形態に応じて、例としてＳＩＰ通信システム２００を記述する。このシステム２００は、コールルーティング（ｒｏｕｔｉｎｇ）メカニズム２１２を持つ、１以上のコーリングデバイス２０８（これはユーザー通信デバイス１０８と一致するかも、しないかもしれない）を接続する通信ネットワーク２０４を含んでいる。
【００３２】
通信ネットワーク２０４は、通信ネットワーク１０４と同じであり得るし、または異なっていることもあり得る。例えば、両方のネットワーク１０４、２０４が企業ネットワークと通信しうる場合もあり、代替として、通信ネットワーク１０４がインターネットと通信するが、通信ネットワーク２０４は企業ネットワークまたはＳＩＰ可能なネットワークと通信するという場合もある。
【００３３】
通信ネットワーク２０４のコンフィグレーションに関係なく、発呼者（ｃａｌｌｅｒ）は着呼者（ｃａｌｌｅｅ）へコーリングデバイスを介してコンタクトを開始することを許される。本発明の少なくともいくつかの実施の形態に応じて、受信者は複数のＳＩＰデバイス２３２ａ−Ｎを有するＳＩＰユーザーと通信しうる。この技術分野の当業者は理解するであろうが、１以上のＳＩＰデバイス２３２ａ−Ｎは、図１に示すユーザー通信デバイス１０８の１つとも対応しうる。
【００３４】
発呼者が着呼者に向けてコンタクトを開始したときに、コンタクトレゾリューション要求は、着呼者のコンタクトレゾリューションプリファレンスに基づいてコンタクトレゾリューションを実行するために用意されている、ロケーションサーバのようなコールルーティングメカニズム２１２に送られる。着呼者のプリファレンスは、ユーザープロビジョンドテーブル２１６で定義される。これは着呼者のユーザープリファレンス１１６と同じ場合もあり、または同じでない場合もある。従って、コールルーティングメカニズム２１２はユーザー登録サーバ１１２と同じ場合もあり、または同じでない場合もある。代替として、ユーザー登録サーバ１１２でのユーザープリファレンス１１６への更新は、コールルーティングメカニズム２１２へと送られて、そこでユーザープロビジョンドテーブル２１６に組み入れられる場合もある。本発明の少なくともいくつかの実施の形態に応じて、ユーザープロビジョンドテーブル２１６は、各々のユーザーのコンタクトレゾリューションプリファレンスにマップ（ｍａｐ）されたユーザーのＡＯＲのリストを含んでいる。これらのプリファレンスは、そのユーザーに宛てられたインカミングのコンタクトに適用される特別のＣＲＡを識別するポインターを含んでいる。
【００３５】
従って、コールルーティングメカニズム２１２は、ユーザープロビジョンドテーブル２１６に加えて、ダイナミックテーブル２２０、１以上の旧ＣＲＡ２２４、１以上の拡張モジュール２２８（または新ＣＲＡ）から構成される。旧ＣＲＡ２２４は、コールルーティングメカニズム２１２の更新の前に（すなわち、コールルーティングメカニズム２１２上の拡張モジュール２２８のデプロイの前に）、コールルーティングメカニズム２１２に存在した、いかなるタイプも含むＣＲＡから構成される。
【００３６】
拡張モジュール２２８は、あるユーザーが、その拡張モジュールを指定し、呼び出すための、ユーザープロビジョンドテーブル２１６を更新するならば、どんなユーザーによっても適用できる、新ＣＲＡから構成される。より明確には、拡張モジュール２２８がデプロイされたときに、ユニークなＩＤが（拡張モジュールに）アサインされる。もし、あるユーザーが拡張モジュール２２８と関連したＣＲＡを利用したいならば、拡張モジュールのユニークなＩＤを含むように、ユーザープロビジョンドテーブル２１６の中の自分の情報を更新する。それゆえ、コールルーティングメカニズム２１２において、ユーザーに宛てられたコンタクトのためのコンタクトレゾリューションリクエストが受信された場合は、コールルーティングメカニズム２１２は、ユーザープロビジョンドテーブル２１６を参照すること、及び、ユーザーが旧ＣＲＡよりも拡張モジュール２２８のＣＲＡを呼び出すことを望むと決定することが可能であり、それから、受信したコンタクトレゾリューションリクエストを処理するため、拡張モジュール２２８を使用する。
【００３７】
処理中に、拡張モジュール２２８のＣＲＡは、どのＳＩＰデバイス２３２が、それへとルートづけられたコンタクトを持つことが適切かを決定する必要がある。この決定はユーザーが特定のＳＩＰデバイス２３２が、コールルーティングメカニズム２１２とともに登録してあるかどうかに基づく。言い換えれば、いくつかのコンタクトルーティングの決定は、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２上にあり、コールルーティングメカニズム２１２とともに登録されているかどうかに基づく。ＳＩＰデバイス２３２の動作に関する、このダイナミックな登録情報は、ダイナミックテーブル２２０に記憶される。このように、処理の間に、拡張モジュール２２８のＣＲＡは、コンタクトがどこにルートされるべきかを決定するためにダイナミックテーブル２２０を参照するようになっている。
【００３８】
ダイナミックテーブル２２０内の情報は、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２とともに登録されているかどうかに、（部分的にはそのような考慮に基づいてはいるが、）常に基づくわけではない。むしろ、ダイナミックテーブル２２０内の情報は、検出された特定のユーザーのプレゼンスアクティビティ（ｐｒｅｓｅｎｃｅ ａｃｔｉｖｉｔｙ）、一日の中の時間、週の中の曜日、処理の負荷、及びいずれかのＣＲＡ（すなわち旧ＣＲＡ２２４か新ＣＲＡか）によって考慮されるべきダイナミックなパラメータに基づいて改変しうる。本発明の少なくともいくつかの実施の形態に応じて、ダイナミックテーブル２２０内の情報は、ＳＩＰデバイス２３２の状態の変化に敏感である。（例えば、ＳＩＰデバイス２３２が現在ＳＩＰセッションに入っているかどうか、どんなタイプの通信媒体が現在ＳＩＰデバイスで使用されているかなど）これらの変化は、ＳＩＰデバイス２３２によって、周知のシグナリングまたはＳＩＰメッセージを介して、コールルーティングメカニズム２１２へとレポートされる。一例として、ＳＩＰデバイス２３２は、ＮＯＴＩＦＹまたはＰＵＢＬＩＳＨメッセージをコールルーティングメカニズム２１２へ送ることによって、コールルーティングメカニズム２１２におけるその状態情報を更新する。
【００３９】
追加として、ダイナミックテーブル２２０は、別のユーザーまたは別のユーザーののデバイスのプレゼンスステート（ｐｒｅｓｅｎｃｅ ｓｔａｔｅ） のような他のパラメータにも敏感である。このように、特定のユーザーに対するＣＲＡアルゴリズムは、他のユーザーのデバイスが、その特定のユーザーに対するＩＮＶＩＴＥリクエストのターゲットとして、ＣＲＡアルゴリズムに参加するデバイスのセットに含まれることを許す論理を含んでいる。言い換えれば、ＣＲＡアルゴリズムは、第１異なるユーザーに到達しようと試みるときに第２のユーザーのデバイスにアラートすることを決定する。一例として、第１ユーザーは、特定の日の特定の時間に、第２のユーザーのデバイスにアラートするようにＣＲＡアルゴリズムを定義しうる。（例えば、私に到達するためには、金曜日の２時から３時の間、第２のユーザーの業務用フォンにアラートするよう試みよ。）第１ユーザーが第２のユーザーと特定の時間にミーティングすることを知っているならば、このことは、なされうる。更に、このような情報はカレンダアプリケーションや類似のものに記憶されているユーザーの電子スケジュールから自動的に検索されうる。
【００４０】
図３を参照して、ユーザーのコンタクトレゾリューションプリファレンスを更新する例示の方法について、本発明の少なくともいくつかの実施の形態に合わせて説明する。その方法は、新たな拡張モジュール２２８が、コールルーティングメカニズム２１２のようなネットワークデバイスの上にデプロイされたときに開始する。（ステップ３０４）本発明の少なくともいくつかの実施の形態に応じて、拡張モジュール２２８はホットデプロイ可能である。すなわち、ネットワークデバイスが動作中で、かつ、ネットワークデバイスが他のネットワークデバイスと接続された状態で、拡張モジュール２２８のコードをネットワークデバイスに追加することができる。従って、ネットワークデバイス上に拡張モジュール２２８をデプロイするのに、デバイスの停止時間は必要ではない。このことは、巨大なネットワークの場合に、特に有効である。なぜなら、もし新ＣＲＡのデプロイがネットワーク停止時間を必要とするならば、全体のネットワークの動作が１つのネットワークデバイスの停止時間によって悪影響を与えられるか、または、全てのネットワークデバイスの更新に非常に長い時間を要することになり、それにより、ネットワーク停止時間が増大し、生産性のロスを増加することになる。本発明の実施の形態は、そのような否定的な影響を回避する。この技術分野の当業者は理解するであろうが、新ＣＲＡのデプロイは、通常は、ネットワークアドミニストレータによって実行されるが、アドミニストレータでないユーザにも実行しうる。
【００４１】
その方法は、新たにデプロイされた拡張モジュール２２８を、１以上のユーザーに通告することにより、進められる。（ステップ３０８）この通告は、新たな拡張モジュール２２８がデプロイされたという事実によって自動的に発生する。代替として、新たな拡張モジュール２２８がデプロイされた後で、ネットワークアドミニストレータによって、この通告が開始されることもあり得る。更に、ユーザー通告の程度（すなわち、更新を通告されるユーザー数）は、ユーザーがこのような通告を受信することに同意していたかどうかなどの、ネットワークセキュリティの関心度により変化しうる。更に、その通告は電子的なフォーマット（例えば、Ｅメール、ＳＭＳメッセージ、インスタントメッセージ（ＩＭ）など）で来ることもあり、紙のフォーマットで来ることもある。
【００４２】
新たな拡張モジュール２２８がデプロイされたとの通告を受けると、ユーザーは、新たにデプロイされた拡張モジュール２２８、特に、新たな拡張モジュール２２８のＣＲＡの使用を含むように、プリファレンス１１６を更新する。（ステップ３１２）この更新は、通告に、直接に対応して開始されるか、または、分離してユーザーがウエブオプションインターフェースを介して、ユーザー登録サーバ１１２と通信して更新する。
【００４３】
ユーザープリファレンス１１６の更新は、コールルーティングメカニズム２１２の中のユーザープロビジョンドテーブル２１６の更新もまた引き起こす。（ステップ３１６）より明確には、ユーザーがコンタクトレゾリューションプリファレンスを更新したときに、その特定のユーザーのためのユーザープロビジョンドテーブル２１６の記載事項（ｅｎｔｒｙ）もまた、新しいプリファレンスを反映して更新される。より更に明確には、ユーザープロビジョンドテーブルの記載事項は、新たに加えられた拡張モジュール２２８の識別子を含んでいる。この識別子はもしユーザープロビジョンドテーブルが通告に直接に応答した場合は、自動的にテーブル２１６に入力され、または、ユーザープリファレンス１１６をマニュアルで更新した場合は、ユーザーが、識別子を入力する必要がある。一旦、ユーザープロビジョンドテーブル２１６が更新されたら、後に受信する、そのユーザーに宛てられたコンタクトは、新たに追加された拡張モジュール２２８を呼び出す。
【００４４】
この技術分野の当業者は理解するであろうが、ステップ３１２とステップ３１６は、単一のステップに結合しうる。もし、ユーザーがユーザープロビジョンドテーブル２１６を、中間のユーザー登録サーバ１１２を経由するよりも、直接に更新する場合には、特に、結合しうる。しかし、多数のコールルーティングメカニズム２１２を有する、より大きなネットワークでは、ユーザーの更新の単一の場所として、単一の登録サーバ１１２を持つことが望ましい。そのようなコンフィグレーションでは、単一の登録サーバ１１２は、（ユーザーの）プリファレンスに関して、ユーザーとのインターフェースとして機能し、その登録サーバ１１２は、ネットワーク中の他のコールルーティングメカニズム２１２に対して、ユーザープリファレンスへのどんな変更をも通告する。
【００４５】
図４を参照し、本発明の少なくともいくつかの実施の形態に応じて、インカミングコンタクトレゾリューションリクエストを処理する方法の一例を説明する。その方法は、コンタクトレゾリューションリクエストが、コールルーティングメカニズム２１２で受信されることで開始する。（ステップ４０４） コンタクトレゾリューションリクエストは、着呼者の識別子を含んでいる。この情報は、コンタクトレゾリューションリクエストの、１以上のヘッダーの中に含まれている。特にコンタクトレゾリューションリクエストが、ＳＩＰ ＩＮＶＩＴＥメッセージと関連づけられている場合は、そのメッセージ及びそのコンタクトレゾリューションリクエストは、ＳＩＰヘッダーの中の、ＡＯＲを介した着呼者の識別から構成される。しかしながら、理解できるように、インカミングコンタクトレゾリューションリクエストは、必ずしも、ＳＩＰメッセージの形式であることは必要ではない。むしろ、インカミングコンタクトレゾリューションリクエストは、ユーザーのＡＯＲによる特定のユーザーよりも、特定の通信デバイスを個別認識するような、アナログフォンまたは類似のものによって通話する、通常のインバウンドコールに相当する。コールルーティングメカニズム２１２は、代替的に、インバウンドコンタクトレゾリューションリクエストが、ユーザーの通信デバイスの１つがそのコンタクトによって識別され、その識別情報がコンタクトレゾリューションリクエストの中に含まれたという事実によって、特定のユーザーのためであることを決定することもある。
【００４６】
着呼者を識別すると、その方法は、そのユーザーのためのコンタクトレゾリューションプリファレンスを識別するために、コールルーティングメカニズム２１２がユーザープロビジョンドテーブル２１６を参照することで、続行する。（ステップ４０８） より明確には、コールルーティングメカニズム２１２は、テーブル２１６の中のユーザーのＡＯＲを識別し、どのＣＲＡがそのユーザーのために呼び出されるべきかを決定するようになっている。（ステップ４１２）そのＣＲＡは、そのＣＲＡと関連しているユニークなＩＤによって、識別される。本発明の少なくともいくつかの実施の形態に応じて、識別されたＣＲＡは、拡張モジュール２２８を介してコールルーティングメカニズム２１２に新たに追加されたＣＲＡに一致する。
【００４７】
ＣＲＡの識別子（より明確には、拡張モジュール２２８のユニークなＩＤ）を獲得すると、コールルーティングメカニズム２１２は、識別されたＣＲＡを呼び出し、コンタクトをそのＣＲＡにパスする。（ステップ４１６） 一旦、ＣＲＡがコンタクトを受信したら、ＣＲＡは、どちらのＳＩＰデバイス２３２が、それへとルートづけられたコンタクトを有するのが適切か、また、コンタクトのこのようなデバイスに、どのようにアラートするか、を決定するために、（必要なら）ダイナミックテーブル２２０を参照する。ＳＩＰデバイスの適格性は、呼び出されたＣＲＡに定義されているルールに基づき、また、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２とともに記録されているかどうかに基づく。ＣＲＡのルールは、１つのＳＩＰデバイス２３２を最初にアラートし、もしユーザーがそのＳＩＰデバイスでコンタクトに応答しないならば、別のＳＩＰデバイス２３２にアラートする（シリアルフォーキング）よう、定義する。代替として、ＣＲＡのルールは、複数のＳＩＰデバイスに同時にアラートし、アラートに最初に応答したデバイスがコンタクトに勝利する（パラレルフォーキング）よう、定義することもできる。他のタイプのＣＲＡもまた、拡張モジュール２２８の中に含まれるが、本発明の実施の形態は、ここで議論したＣＲＡの例に必ずしも限定されない。
【００４８】
用語「コンピュータで読み取り可能な媒体」とは、コンピュータが実行するプロセスを記憶する媒体或いは伝送媒体を意味する。媒体とは、非揮発性媒体、揮発性媒体、伝送媒体を意味する。非揮発性の媒体とは、ＮＶＲＡＭ、磁気ディスク又は光学ディスクである。揮発性媒体とは、ＤＲＡＭ、メインメモリを意味する。このコンピュータで読み取り可能な媒体の一般的なものとしては、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気ディスク、他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、パンチカード、ペーパーテープ等、更にＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカード、メモリチップ、或いはカートリッジ等がある。ｅ−ｍａｉｌ或いは他の自己保存型の情報アーカイブに付属したデジタルファイルは、記憶媒体に等価な分配型の記憶媒体であり、本発明でいう記憶媒体と見なすことができる。コンピュータで読み取り可能な媒体がデータベースとして構築された場合には、このデータベースは、あらゆる種類のデータベース、例えば関連型、階層型、オブジェクト志向型のいずれをも含む。
用語「モジュール」「エージェント」「ツール」とは、ハードウエア、ソフトウエア、ファームウエア、人工知能、ファジーロジック、それらの組み合わせを言う。
上記したイベント、事象の発生順は、本発明の動作／効果に影響を与えずに変更可能である。特に断りのない限り、実施例の順にはこだわらない。
ここで議論したフローチャートは、特定のイベントのシーケンスを例に説明するが、本発明の操作に影響を及ぼすことなく、これ等のシーケンスの変更、追加、一部省略も可能である。本発明のシステムと方法は、特殊コンピュータ、プログラムされたマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、他の集積回路ＤＳＰ、ハードワイヤド電子素子、論理素子、例えばディスクリートな要素回路、プログラム可能な論理回路、ゲートアレイ、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、特殊目的コンピュータ或いは他の手段で実現できる。
他の実施例に於いては、ここに開示された方法は、オブジェクト指向のソフトウエア開発環境を用いたソフトウエアと組み合わせて実現できる。このソフトウエア環境は、様々なコンピュータ又はワークステーションで使用されるポータブルなソースコードを提供する。別の構成として、開示されたシステムは、標準の論理回路又はＶＬＳＩデザインを用いて一部又は全部のハードウエアで実現できる。本発明のシステムを実行するのにハードウエア又はソフトウエアを用いるかは、システムに要求される速度と効率に依存する。特に使用される特定のソフトウエア、ハードウエアのシステム、マイクロプロセッサ又はマイクロコンピュータシステムに依存する。
他の実施例に於いては、開示された方法は、コンピュータで読み取り可能な記憶媒体に記憶されたソフトウエアで実行され、コントローラとメモリとを有するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ等で実施される。これ等の実施例に於いては、本発明のシステムと方法は、パソコンに組み込まれたプログラムで実行できる。例えばアプレット、ＪＡＶＡ、ＣＧＩスクプリト、サーバ或いはコンピュータ、ワークステーションに記録された資源或いは専用の測定システムに組み込まれたルーチン等で実施できる。
本発明のシステムは、本発明のシステムと方法をソフトウエア又はハードウエアのシステムに物理的に組み込むことにより実施することもできる。 本発明は、特定の標準及びプロトコルを例に説明したが、本発明はこのような標準とプロトコルに制限されるものではない。他の類似の標準とプロトコルも本発明で用いることができる。これ等の標準とプロトコルは、今後開発されるより効率的な標準とプロトコルで置換されるかも知れないが、このような置換も本発明の一態様（一実施例）と考えられる。
【００４９】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００５０】
１０４ 通信ネットワーク
１０８ 通信デバイス
１１２ ユーザー登録サーバ
１１６ ユーザープリファレンス
２０４ 通信ネットワーク
２１２ コールルーティングメカニズム
２１６ ユーザープロビジョンドテーブル
２２０ ダイナミックテーブル
２２４ 旧ＣＲＡ
２２８ 拡張モジュール
２３２ ＳＩＰデバイス
３０４ ネットワークが動作中に新しい拡張モジュールがネットワークに追加された
３０８ ユーザーに新しい拡張モジュールを通告する
３１２ ユーザーが新しい拡張モジュールの使用を含むようにプリファレンスを更新する３１６ プリファレンスのユーザープロビジョンドテーブルを新しい拡張モジュールに向ける
４０４ インカミングコンタクトを受信する
４０８ ユーザープロビジョンドテーブルをＣＲＡプリファレンスと比較する
４１２ ユーザーの選択したＣＲＡのために使用されるべき拡張モジュールを識別する
４１６ 拡張モジュールを呼び出す
【技術分野】
【０００１】
本発明は、一般的には通信に関連し、より明確には、ポータブルでユーザー指向型（ｕｓｅｒ−ｃｅｎｔｒｉｃ）のコンタクトレゾリューション（ｃｏｎｔａｃｔ ｒｅｓｏｌｕｔｉｏｎ）メカニズムに関連する。
【背景技術】
【０００２】
セッションイニシエーションプロトコル（ＳＩＰ）は、多数の種類のリアルタイムの通信セッションを確立するためのオープンシグナリングプロトコルである。ＳＩＰを使用して確立される通信セッションのタイプの例は、音声、画像、及び／または、インスタントメッセージングを含む。これらの通信セッションは、パーソナルコンピュータ、ラップトップコンピュータ、個人情報端末のような、いかなるタイプの通信デバイス上でも実行される。ＳＩＰの1つの重要な特徴は、全ての通信のために、単一の統合した公衆アドレスとして、エンドユーザーのアドレスオブレコード（ＡＯＲ）を使用する能力である。このように、ＳＩＰ機能強化通信の世界では、ユーザーのＡＯＲはそのユーザーに関連する全ての通信デバイスにユーザーをリンクする単一のアドレスとなる。このＡＯＲを使用して、発呼者は、各々の固有のデバイスアドレスや電話番号を知る必要はなく、ユーザーエージェント（ＵＡ）としても参照されて、ユーザーのいずれか１つの通信デバイスに到達することができる。
【０００３】
ＳＩＰセッションの確立の間に遂行されるステップの１つは、与えられたユーザーに登録された、どのデバイスが、与えられたコールの際にアラート（ａｌｅｒｔ）するかを決定する、コンタクトレゾリューションである。伝統的なシステムでは、ユーザーのためのコンタクトレゾリューションポリシー（どのデバイスをリングするか、どのようにリングするかなどに関してなされる決定）は、ＰＢＸの中に組み込まれており、設定済み（ｐｒｏｖｉｓｉｏｎｅｄ）の電話セットのためだけに機能した。このように、コンタクトレゾリューションポリシーに関するユーザーの選択は、ＰＢＸのリリースと電話デバイスに固有であった。ＳＩＰでは、このことは極めて望ましくない。なぜなら、隠されたＩＰネットワークが、ユーザーによって登録されたいくつものＳＩＰ通信デバイスのための、一般目的のアタッチメントメカニズムとなるからである。自分のデバイスのどれが登録されるか、接続されるか、稼働可能とされるか、また、これらのデバイスのそれぞれがどんな目的で使用されるか、を決定するのは、ＳＩＰユーザー自身である。ＳＩＰでは、コンタクトレゾリューションは、従来はロケーションサーバでなされていた。しかしながら、ＰＢＸのように、ロケーションサーバを、新たなコンタクトレゾリューションの動作を提供することができるように、再びデプロイ（ｄｅｐｌｏｙ）することは、しばしば、望ましくないことである。それゆえ、ユーザーが、一般的に特別なＰＢＸまたは通信フィーチャーサーバまたはネットワークのロケーションサーバの改変を必要とすることなしに、システム／ネットワークアドミニストレータによって彼らに代わって容易に提供される、コンタクトレゾリューションポリシーとアクセスを持つことが望ましい。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願１２／２４１３６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の実施の形態は、コンタクトレゾリューションポリシーまたはアルゴリズムを、ユーザー、特にＳＩＰユーザーのために可能にするメカニズムを提供する。多くの企業が、ＳＩＰユーザーに、単純なｑ値（ｑ−ｖａｌｕｅ）として、ロケーションサーバで、各々のデバイスまたはネットワークのための彼らのプリファレンス（ｐｒｅｆｅｒａｎｃｅ）を登録することを許している。ＳＩＰでは、ロケーションサーバの役割は、ユーザーのポリシーに従って、ＳＩＰリクエストを、各々の登録したコンタクトへ送信することを仲介することである。これは、従来、ユーザーポリシーを履行する静的なアルゴリズムの中のｑ値を評価することによってなされた。いくつかの共通に用いられるポリシーには、シーケンシャルフォーキング（各々のデバイスに順番コンタクトする）、パラレルフォーキング（全てのデバイスに同時にコンタクトし、最初に応答したデバイスをコンタクトの勝者と認める）、及びロードバランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）が含まれる。本発明の実施の形態は、ネットワークアドミニストレータが、ネットワークのユーザーに対して新たなアルゴリズムの選択を「ホットデプロイ（ｈｏｔ ｄｅｐｌｏｙ）」することを許し、また、ユーザーが、企業のネットワークの中で使用しうる、どんなデプロイされたコンタクトレゾリューションポリシーまたはアルゴリズムをも選択し、任意にパーソナライズすることを許す。より明確には、本発明の実施の形態は、ユーザーが、プラガブル（ｐｌｕｇｇａｂｌｅ）コンタクトレゾリューションアルゴリズム（シリアルフォーキング、パラレルフォーキング、スマートロードバランシング、発呼者識別に基づきリングを代えるなど）を見つけ出し、使用することを許すメカニズムを提供する。しばしばプラガブルコンタクトレゾリューションアルゴリズムは、アドミニストレータまたはアドミニストレータの許可を得た他のユーザーによってデプロイされる。しかし、本発明の実施の形態は、それに限定されず、アドミニストレータではないユーザーが、プラガブルコンタクトレゾリューションアルゴリズムを、個人の使用及び／または、他のユーザーの使用のために、開発し、デプロイすることも許容される。プラガブルコンタクトレゾリューションアルゴリズムをデプロイするように選ばれたどんなユーザーも、そのようなコンタクトレゾリューションアルゴリズムをリファインし、カスタマイズすることが、適用する際には許される。
【０００６】
インバウンド（ｉｎｂｏｕｎｄ）コンタクトを、ユーザーのために受信したときに、どのＣＲＡ（コンタクトレゾリューションアルゴリズム）を使用すべきか（すなわち、どの拡張モジュールが参照されるべきか）を示すテーブルエントリーと関連して、コンタクトレゾリューションアルゴリズムを含む拡張モジュールが使用される。
【０００７】
拡張モジュールは、個々にデプロイし、またはデプロイしないようにできる、自給自足式（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）のジャーファイル（ｊａｒ ｆｉｌｅ）である点で、ＳＩＰサーブレット（ｓｅｒｖｌｅｔ）に似ている。ＳＩＰサーブレットは、ＳＩＰ機能をサポートするためにその中に搭載されたインターフェースを強化する点で、他のタイプのサーブレットに似ている。別のタイプのサーブレットの例は、ｈｔｔｐサーブレットであり、これは、ウェブサーバまたはアプリケーションサーバの中で動作し、典型的にはデータベースにアクセスする、またはｅ−コマース処理を実行するような、サーバ側の処理を提供する、Ｊａｖａ（登録商標）アプリケーションである。それは、ＣＧＩスクリプト（ＣＧＩ ｓｃｒｉｐｔｓ）、アクティブサーバページ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ、ＡＳＰｓ）及びＣ及びＣ＋＋で書かれたプロプライアトリプラグイン（ｐｒｏｐｒｉｅｔｒｙｐｌｕｇ−ｉｎｓ）の、Ｊａｖａベースの置き換えである。サーブレットはＣＧＩコンセプトに類似するが、分離したプロセスを使う代わりに、メッセージはサーバ内部のバーチャルマシンの中で動作するクラスに伝達される。
【０００８】
多数のサーブレットは、サーバとオペレーティングシステムの間で可搬性を許容するように、特定のプログラム言語（例えばＪａｖａ）で書かれる。Ｊａｖａは、サーブレットまたは拡張モジュールを創作するために使用されるプログラム言語の一例であるが、本発明の実施の形態はそれに限定されないことを、この技術分野の当業者は理解するであろう。より明確には、本発明の実施の形態は、拡張モジュールがサーバとオペレーティングシステムの間で可搬性を持つことを許容するような、いずれかのタイプのプログラム言語での、拡張モジュールの創作を意図している。本発明の実施の形態は、また、サーバ（例えば、企業サーバで、特にＳＩＰサーバ）上のバーチャルマシンの内部で動作することができる拡張モジュールを意図している
【０００９】
しかしながら、ＳＩＰサーブレットと違って、拡張モジュールは、ホットデプロイ可能である。拡張モジュールは、サービスの損失なく、稼働中のアップグレードが可能である。本発明の少なくともいくつかの実施の形態に応じて、拡張モジュールは、インカミング（ｉｎｃｏｍｉｎｇ）コンタクトが受信されたときに、特定のユーザーが得るコンタクトレゾリューションの形式を改変するための、ＳＩＰダイアログアダプテーション（ｄｉａｌｏｇ ａｄａｐｔａｔｉｏｎ）の中で使用される。より明確には、個々のダイアログアダプテーション論理は、各々のアダプターのために、サーブレットとしてよりも、拡張モジュールとして、履行されることができる。拡張モジュールのホットスワップ（ｈｏｔ ｓｗａｐ）能力に加えて、拡張モジュールの使用は、より容易なマネジメント及び共通のダイアログアダプテーション論理がシェアされることを許容する。拡張モジュールと伝統的なＳＩＰサーブレットの別の相違は、ＳＩＰサーブレットインタフェースのみを想定しているＳＩＰサーブレットとは違って、拡張モジュールはサービスに供される多数のインタフェースを定義しうることである。
【００１０】
更に、また、本発明の少なくともいくつかの実施の形態に応じて、拡張モジュールは、サーブレット、アプリケーションルータ、及び／または、他のＳＩＰアプリケーションによってアクセスされ得るサービスに供されるために使用される。いくつかの実施の形態では、拡張モジュールは、デプロイの間に定義される（通常は、システムアドミニストレータによって定義される）ユニークな短いＩＤに結びつけられる。拡張モジュールは、そのサービスを供するインタフェースもまた、定義する。必要な場合には、拡張ＡＰＩは、短いＩＤを用いて、拡張モジュールの検索を支援する。拡張モジュールは、デプロイ可能な自給自足式のジャーであるから、拡張モジュールのためのコンフィグレーション情報は、拡張モジュールを履行するクラスファイル（ｃｌａｓｓ ｆｉｌｅ）と一緒に、ジャーファイルの中に含まれている。コンフィグレーション情報は、サーブレットと同じ方式で、デプロイ形ＸＭＬファイルの中に定義されている。
【００１１】
オペレーションでは、各々の遠隔のパーティは、サービスホスト拡張モジュールとして履行されるインバウンド及びアウトバウンドのダイアログアダプテーションロジックと関連づけられる。（コンタクトレゾリューションのような）ダイアログアダプテーションを必要とするいずれかのサービスが、拡張モジュールの識別子（ｉｄｅｎｔｉｆｉｅｒ）（すなわち、拡張モジュールにアサインされたユニークな短いＩＤ）を介して、アダプテーションモジュールを呼び出す（ｉｎｖｏｋｅ）。
【００１２】
コンタクトレゾリューションリクエストが受信されたときに、どのＣＲＡが使用されるべきかを示すテーブルエントリーに加えて、この拡張モジュールが使用される。本発明の少なくともいくつかの実施の形態に応じて、テーブルは、ユーザーに関連する、設定済みの、または、ダイナミックなデータを含んでいる。テーブルの中に、ユーザーは、コンタクトが受信されたときはいつでも適用を望む、デプロイされたＣＲＡとのパーソナルな関係を定義することができる。より明確には、特定のユーザーに関するテーブルは、特定のＣＲＡに適用する、拡張モジュールの識別子を含むであろう。ユーザーオプションをセットするために、別のウェブインタフェースを通して、ユーザーによって、希望したように、コンフィギュア（ｃｏｎｆｉｇｕｒｅ）される、または、再びコンフィギュアされる、この拡張と関連づけられたユーザー指向のデータがある。より明確には、一旦、テーブル内に、ユーザーデータコンフィグレーション（ｃｏｎｆｉｇｕｒａｔｉｏｎ）または再コンフィグレーションが発生すると、アクティブなＣＲＡの正当性チェックが、理解力のあるエンドポイントによる登録または再登録の間に、発生する。
【００１３】
コンタクトレゾリューションの要求が受信されたときに、拡張モジュールが呼び出される。このように、コンタクトレゾリューションは、プラガブルで、ＳＩＰロケーションサーバ自身に組み込まれる必要がない。更に、複数のユーザーが同一の拡張モジュールを参照し、自身のパーソナライズしたユーザーセッティングで、同じまたは類似のＣＲＡを適用することができる。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明の少なくともいくつかの実施の形態に応じて、一般的に、
−第１サーバで、第１ユーザーに宛てられたコンタクトレゾリューションリクエストを受信し、
−第１ユーザーのための、コンタクトレゾリューションプリファレンスを識別し、
−第１ユーザーのための、コンタクトレゾリューションプリファレンスが、コンタクトレゾリューションの一部として、拡張モジュールを使用することを決定し、
−第１サーバによって、そのリクエストに対する拡張モジュールに、ユーザープリファレンスオプションを適用する、拡張モジュールを呼び出す、
ことからなる、通信方法を提供する。
【図面の簡単な説明】
【００１５】
【図１】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションシステムを表すブロック図。
【図２】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションシステムの要素を表すブロック図。
【図３】本発明の少なくともいくつかの実施の形態による、ユーザーが、コンタクトレゾリューションアルゴリズムを定義することを許可する方法を表すフロー図。
【図４】本発明の少なくともいくつかの実施の形態による、コンタクトレゾリューションの方法を表すフロー図。
【発明を実施するための形態】
【００１６】
本発明は、典型的な通信システムと関連して、以下に例示される。例えばサーバまたは／及びデータベースを用いたシステムとともに用いられるのによく適合するが、本発明は、通信システムまたはシステム要素のコンフィギュレーションの、いかなる特定のタイプにも限定されない。この技術分野の当業者は理解するであろうが、開示された技術は、特にＳＩＰ環境において、ユーザーに、コンタクトレゾリューションアルゴリズムをパーソナライズさせることを必要とするいかなる通信アプリケーションにおいても使用することができる。
【００１７】
本発明の典型的なシステムと手法は、分析ソフトウェア、モジュール、及び関連する分析ハードウェアに関連して記述される。しかしながら、本発明の不必要な不明瞭化を避けるため、この後の記述は、よく知られた構造、要素を省略し、また、ブロックダイアグラムフォームで示される装置は、よく知られたものであり、または、他の方法で要約されている。
【００１８】
説明の目的で、本発明の完全な理解を提供するために、数多くの詳細が発表される。しかし、本発明は、ここに開示された特定の詳細を越えて、種々の方法で実施されうることを理解されるべきである。
【００１９】
最初に図１を参照して、典型的な通信システム１００を、本発明の少なくともいくつかの実施の形態に応じて、説明する。より明確には、通信システム１００は、ユーザー登録サーバ１１２と１以上の通信デバイス１０８を相互接続するために設けられた通信ネットワーク１０４を含んでいる。
【００２０】
通信ネットワーク１０４は、いかなるタイプの既知の通信手段またはそれらの集合であってもよく、エンドポイント間のメッセージの伝達のためのいかなるタイプのプロトコルも含んでもよい。通信ネットワーク１０４は、有線及び／または無線の通信技術を含む。インターネットは通信ネットワーク１０４の一例であり、それを構成する、世界中に置かれた多数のコンピュータやその他の通信デバイスからなるＩＰネットワークは多数の電話システムやその他の手段を介して接続されている。通信ネットワーク１０４の他の例は、標準の従来型単純電話システム（ＰＯＴＳ）、サービス総合デジタル網（ＩＳＤＮ）、公衆交換電話網（ＰＳＴＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、セッションイニシエーションプロトコル（ＳＩＰ）ネットワーク、いかなるタイプの企業ネットワーク、この技術分野で知られているいかなるその他のタイプのパケット交換またはサーキット交換ネットワークを含み、これに限定されない。更に、通信ネットワーク１０４は1つのネットワークタイプに限定されず、いくつかの異なるネットワーク及び／またはネットワークタイプから構成されてもよい。
【００２１】
通信デバイス１０８は、パーソナルコンピュータ、ラップトップ、個人情報端末（ＰＤＡ）、携帯電話、スマートフォン、電話、アナログフォン、ＤＣＰフォン、またはそれらの組み合わせのような、周知のどんなタイプの通信または処理デバイスであってもよい。1つの通信デバイス１０８は、単独のユーザーに制御され、または関連づけられていてもよいし、多数のユーザーの使用に供されてもよい。（すなわち、企業の通信デバイスが、企業のユーザーに、有効なユーザー名とパスワードの提示による使用を許可するような場合である。）
【００２２】
通信デバイス１０８の各々は同一ユーザーと関連づけられてもよい。言い換えれば、通信デバイス１０８は単独のユーザーに属してもよく、また、異なるタイプの通信デバイスに対応してもよい。一例として、ユーザーが、それぞれが単一ユーザーの個人電話、業務電話、パソコン、Ｅメール検索デバイスに対応するような、４つの通信デバイス１０８を持ってもよい。代替として、通信デバイス１０８の各々が、異なるユーザーに所有され、操作され（すなわち関連づけられ）ていてもよい。
【００２３】
一般的に、通信デバイス１０８は、他の通信デバイス１０８との、ビデオ、オーディオ、テキスト、及び／またはデータの通信をサポートするように適合されている。通信デバイス１０８によって他の通信デバイス１０８と通信するために使用される媒体のタイプは、通信デバイス１０８において利用できる通信アプリケーションに依存する。
【００２４】
ユーザー登録サーバ１１２は、多数のユーザーが、１つ以上の通信デバイス１０８を操作するためのユーザープリファレンスを受け取り、記憶するようになっている。より明確には、ユーザーはユーザー登録サーバ１１２にログインし、そのユーザーが関与しているどんな通信セッションにも適用することができる、特定のプリファレンス（すなわちユーザープリファレンス）を定義することが許可される。これらのユーザープリファレンスはユーザーに対して全世界的に定義され得る。（すなわち、単一のセットのユーザープリファレンスが、どんなネットワークでも、そのユーザーに関連づけられたどんな通信デバイスにも一貫して適用されうる。）代替として、ユーザーは、異なるネットワークまたはユーザーケースのために、異なるユーザープリファレンスを定義することも許される。（すなわち、あるユーザーが異なる家庭用と業務用のプリファレンスを持ちうる）あるユーザーは、また、各々の通信デバイス１０８のために、異なるユーザープリファレンスを定義することも許される。一例として、ユーザーは第１セットのコンタクトレゾリューションプリファレンス（すなわち、第１ＣＲＡ）をモバイル通信デバイス１０８に定義し、第２の異なるセットのコンタクトレゾリューションプリファレンス（すなわち第２ＣＲＡ）を業務用通信デバイスに定義し、第３の異なるセットのコンタクトレゾリューションプリファレンス（すなわち第３ＣＲＡ）を家庭用の通信デバイスに定義することができる。これらの異なるユーザープリファレンスは、ユーザー登録サーバ１１２上で、単一のセットのユーザープリファレンス１１６に結合されて記憶されうる。例えば、いくつかのデバイスのサブセットではパラレルフォーキング（ｆｏｒｋｉｎｇ）を使用して処理され、別のサブセットではシーケンシャルフォーキングを使用して処理されるというように、類似のＣＲＡの階層構造に連鎖する、または階層構造を形成することは有効である。このような実施の形態では、ＣＲＡの間の連鎖を処理する高レベルのコーディネイターが存在し得る。また、デバイス毎のベースでは、デバイスに固有のコンタクトレゾリューションの振る舞いが変化するために、アルゴリズムは、一日の中の時間、週の中の曜日、デバイスの状態などの事象に敏感である。
【００２５】
代替として、単一のコンタクトレゾリューションプリファレンス（すなわち、単一ＣＲＡ）が、そのユーザーに関係づけられた全ての通信デバイス１０８の間で、コンタクトをレゾルブ（ｒｅｓｏｌｖｅ）するために用いられる。言い換えれば、単一のＣＲＡが、特定の通信デバイス１０８がアラートされるべきかどうか、いつアラートされるべきか、どのようにアラートされるべきかを決めるために用いられる。本発明の、少なくともいくつかの実施の形態に関連して用いられ得る、このようなＣＲＡの例は、更に詳しく、米国特許出願番号１２／２４１，３６８号（ブルンソン他）に記述されており、その全文は、参考としてここに組み込まれる。
【００２６】
本発明の少なくともいくつかの実施の形態に応じて、ユーザーは通信デバイス１０８を経由してユーザー登録サーバ１１２で自らのユーザープリファレンス１１６を更新及び／または変更することが許される。言い換えれば、ユーザーは、通常はある種のウエブユーザーオプションインターフェースを介して、ユーザープリファレンス１１６を設定するために、ユーザー登録サーバ１１２に接続するであろう。本発明の少なくともいくつかの実施の形態に応じて、プラガブルＣＲＡは、ユーザーがユーザープリファレンス１１６をセットするために、ウエブユーザーオプションインターフェースをサポートするようにする。これらのユーザーオプションは、企業データベースのようなローカルなデータ記憶装置に記憶され、及び／または、ユーザープリファレンス１１６としてユーザー登録サーバ１１２の中に記憶される。これらのプリファレンス１１６は、それから、コール処理のコンタクトレゾリューションフェーズの間に、ユーザープリファレンス１１６を呼び出す、１以上のネットワークデバイスに分配される。
【００２７】
本発明の少なくともいくつかの実施の形態に応じて、ユーザープリファレンス１１６は、（１または複数の通信デバイス１０８のための）プリファードＣＲＡを定義するパラメータを含む。ユーザーがユーザープリファレンス１１６を更新したときには、ユーザープリファレンスの変更が、そのようなプリファレンスが適用されるどんなデバイスにもネットワークを通じて分配される。典型的には、ネットワークには、ユーザーのＣＲＡ選択を知る必要のある、ごく少数の（例えば２または３の）デバイスが存在する。しかし、本発明の実施の形態は、そのようには制限されず、ユーザープリファレンス１１６の変更は、どんな数のネットワークデバイスにも分配されうる。これらのプリファレンスは、これから詳細が議論されるように、ユーザープロビジョンドテーブルに記憶される。
【００２８】
本発明の実施の形態は、ネットワークが、その操作が有害に影響されることなく、稼働している間に、新たなＣＲＡがネットワークにデプロイされるような状況を意図している。（すなわちアドミニストレータがホットプラガブルＣＲＡを拡張モジュールの形でネットワークに追加することができる。）言い換えれば、ネットワークのアドミニストレータが新たなＣＲＡを、１つのネットワークに、または、そのデバイスによって後に受信されたコンタクトに適用される１つのネットワークデバイスに、追加することを許容する。本発明の少なくともいくつかの実施の形態に応じて、そのようなＣＲＡがネットワークに追加されたときに、ネットワークの１以上のユーザーがその更新を通告され得る。この通告に対応して、ユーザーは、新たに追加されたＣＲＡを適用すべく、ユーザープリファレンス１１６を改変することを許される。（通告に対応して直接的に、または分離してユーザー登録サーバ１１２にアクセスして間接的に）再び、ユーザーは、いずれのタイプの、既知の、またはこれから開発されるウエブオプションインターフェースを介して、ユーザープリファレンス１１６にアクセスし、更新することが許される。このようなプロセスの詳細は、更に細かく、以下で検討される。
【００２９】
ユーザーがユーザープリファレンス１１６を更新することを許可されることの、代替として、または追加として、ネットワークアドミニストレータもまた、ユーザープリファレンス１１６を更新することを許されことがある。従って、新たに加えられたＣＲＡを呼び出すための、ユーザープリファレンス１１６の改変は、ユーザー及び／または、ネットワークアドミニストレータによって実行されうる。
【００３０】
更に、ユーザープリファレンス１１６はパスワードまたは類似のタイプの真正証明（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｒｅｄｅｎｔｉａｌ）によって書き込み保証されうる。このように、一例として、ユーザー名として適切なパスワードの準備なしでは、ユーザーまたはアドミニストレータはユーザープリファレンスを改変しえない。ユーザープリファレンス１１６を更新する、ユーザー及び／または、アドミニストレータの能力を制限する他の代替案は予想され、ネットワークセキュリティの要求に応じて変化しうる。
【００３１】
ここで、図２を参照し、本発明の少なくともいくつかの実施の形態に応じて、例としてＳＩＰ通信システム２００を記述する。このシステム２００は、コールルーティング（ｒｏｕｔｉｎｇ）メカニズム２１２を持つ、１以上のコーリングデバイス２０８（これはユーザー通信デバイス１０８と一致するかも、しないかもしれない）を接続する通信ネットワーク２０４を含んでいる。
【００３２】
通信ネットワーク２０４は、通信ネットワーク１０４と同じであり得るし、または異なっていることもあり得る。例えば、両方のネットワーク１０４、２０４が企業ネットワークと通信しうる場合もあり、代替として、通信ネットワーク１０４がインターネットと通信するが、通信ネットワーク２０４は企業ネットワークまたはＳＩＰ可能なネットワークと通信するという場合もある。
【００３３】
通信ネットワーク２０４のコンフィグレーションに関係なく、発呼者（ｃａｌｌｅｒ）は着呼者（ｃａｌｌｅｅ）へコーリングデバイスを介してコンタクトを開始することを許される。本発明の少なくともいくつかの実施の形態に応じて、受信者は複数のＳＩＰデバイス２３２ａ−Ｎを有するＳＩＰユーザーと通信しうる。この技術分野の当業者は理解するであろうが、１以上のＳＩＰデバイス２３２ａ−Ｎは、図１に示すユーザー通信デバイス１０８の１つとも対応しうる。
【００３４】
発呼者が着呼者に向けてコンタクトを開始したときに、コンタクトレゾリューション要求は、着呼者のコンタクトレゾリューションプリファレンスに基づいてコンタクトレゾリューションを実行するために用意されている、ロケーションサーバのようなコールルーティングメカニズム２１２に送られる。着呼者のプリファレンスは、ユーザープロビジョンドテーブル２１６で定義される。これは着呼者のユーザープリファレンス１１６と同じ場合もあり、または同じでない場合もある。従って、コールルーティングメカニズム２１２はユーザー登録サーバ１１２と同じ場合もあり、または同じでない場合もある。代替として、ユーザー登録サーバ１１２でのユーザープリファレンス１１６への更新は、コールルーティングメカニズム２１２へと送られて、そこでユーザープロビジョンドテーブル２１６に組み入れられる場合もある。本発明の少なくともいくつかの実施の形態に応じて、ユーザープロビジョンドテーブル２１６は、各々のユーザーのコンタクトレゾリューションプリファレンスにマップ（ｍａｐ）されたユーザーのＡＯＲのリストを含んでいる。これらのプリファレンスは、そのユーザーに宛てられたインカミングのコンタクトに適用される特別のＣＲＡを識別するポインターを含んでいる。
【００３５】
従って、コールルーティングメカニズム２１２は、ユーザープロビジョンドテーブル２１６に加えて、ダイナミックテーブル２２０、１以上の旧ＣＲＡ２２４、１以上の拡張モジュール２２８（または新ＣＲＡ）から構成される。旧ＣＲＡ２２４は、コールルーティングメカニズム２１２の更新の前に（すなわち、コールルーティングメカニズム２１２上の拡張モジュール２２８のデプロイの前に）、コールルーティングメカニズム２１２に存在した、いかなるタイプも含むＣＲＡから構成される。
【００３６】
拡張モジュール２２８は、あるユーザーが、その拡張モジュールを指定し、呼び出すための、ユーザープロビジョンドテーブル２１６を更新するならば、どんなユーザーによっても適用できる、新ＣＲＡから構成される。より明確には、拡張モジュール２２８がデプロイされたときに、ユニークなＩＤが（拡張モジュールに）アサインされる。もし、あるユーザーが拡張モジュール２２８と関連したＣＲＡを利用したいならば、拡張モジュールのユニークなＩＤを含むように、ユーザープロビジョンドテーブル２１６の中の自分の情報を更新する。それゆえ、コールルーティングメカニズム２１２において、ユーザーに宛てられたコンタクトのためのコンタクトレゾリューションリクエストが受信された場合は、コールルーティングメカニズム２１２は、ユーザープロビジョンドテーブル２１６を参照すること、及び、ユーザーが旧ＣＲＡよりも拡張モジュール２２８のＣＲＡを呼び出すことを望むと決定することが可能であり、それから、受信したコンタクトレゾリューションリクエストを処理するため、拡張モジュール２２８を使用する。
【００３７】
処理中に、拡張モジュール２２８のＣＲＡは、どのＳＩＰデバイス２３２が、それへとルートづけられたコンタクトを持つことが適切かを決定する必要がある。この決定はユーザーが特定のＳＩＰデバイス２３２が、コールルーティングメカニズム２１２とともに登録してあるかどうかに基づく。言い換えれば、いくつかのコンタクトルーティングの決定は、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２上にあり、コールルーティングメカニズム２１２とともに登録されているかどうかに基づく。ＳＩＰデバイス２３２の動作に関する、このダイナミックな登録情報は、ダイナミックテーブル２２０に記憶される。このように、処理の間に、拡張モジュール２２８のＣＲＡは、コンタクトがどこにルートされるべきかを決定するためにダイナミックテーブル２２０を参照するようになっている。
【００３８】
ダイナミックテーブル２２０内の情報は、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２とともに登録されているかどうかに、（部分的にはそのような考慮に基づいてはいるが、）常に基づくわけではない。むしろ、ダイナミックテーブル２２０内の情報は、検出された特定のユーザーのプレゼンスアクティビティ（ｐｒｅｓｅｎｃｅ ａｃｔｉｖｉｔｙ）、一日の中の時間、週の中の曜日、処理の負荷、及びいずれかのＣＲＡ（すなわち旧ＣＲＡ２２４か新ＣＲＡか）によって考慮されるべきダイナミックなパラメータに基づいて改変しうる。本発明の少なくともいくつかの実施の形態に応じて、ダイナミックテーブル２２０内の情報は、ＳＩＰデバイス２３２の状態の変化に敏感である。（例えば、ＳＩＰデバイス２３２が現在ＳＩＰセッションに入っているかどうか、どんなタイプの通信媒体が現在ＳＩＰデバイスで使用されているかなど）これらの変化は、ＳＩＰデバイス２３２によって、周知のシグナリングまたはＳＩＰメッセージを介して、コールルーティングメカニズム２１２へとレポートされる。一例として、ＳＩＰデバイス２３２は、ＮＯＴＩＦＹまたはＰＵＢＬＩＳＨメッセージをコールルーティングメカニズム２１２へ送ることによって、コールルーティングメカニズム２１２におけるその状態情報を更新する。
【００３９】
追加として、ダイナミックテーブル２２０は、別のユーザーまたは別のユーザーののデバイスのプレゼンスステート（ｐｒｅｓｅｎｃｅ ｓｔａｔｅ） のような他のパラメータにも敏感である。このように、特定のユーザーに対するＣＲＡアルゴリズムは、他のユーザーのデバイスが、その特定のユーザーに対するＩＮＶＩＴＥリクエストのターゲットとして、ＣＲＡアルゴリズムに参加するデバイスのセットに含まれることを許す論理を含んでいる。言い換えれば、ＣＲＡアルゴリズムは、第１異なるユーザーに到達しようと試みるときに第２のユーザーのデバイスにアラートすることを決定する。一例として、第１ユーザーは、特定の日の特定の時間に、第２のユーザーのデバイスにアラートするようにＣＲＡアルゴリズムを定義しうる。（例えば、私に到達するためには、金曜日の２時から３時の間、第２のユーザーの業務用フォンにアラートするよう試みよ。）第１ユーザーが第２のユーザーと特定の時間にミーティングすることを知っているならば、このことは、なされうる。更に、このような情報はカレンダアプリケーションや類似のものに記憶されているユーザーの電子スケジュールから自動的に検索されうる。
【００４０】
図３を参照して、ユーザーのコンタクトレゾリューションプリファレンスを更新する例示の方法について、本発明の少なくともいくつかの実施の形態に合わせて説明する。その方法は、新たな拡張モジュール２２８が、コールルーティングメカニズム２１２のようなネットワークデバイスの上にデプロイされたときに開始する。（ステップ３０４）本発明の少なくともいくつかの実施の形態に応じて、拡張モジュール２２８はホットデプロイ可能である。すなわち、ネットワークデバイスが動作中で、かつ、ネットワークデバイスが他のネットワークデバイスと接続された状態で、拡張モジュール２２８のコードをネットワークデバイスに追加することができる。従って、ネットワークデバイス上に拡張モジュール２２８をデプロイするのに、デバイスの停止時間は必要ではない。このことは、巨大なネットワークの場合に、特に有効である。なぜなら、もし新ＣＲＡのデプロイがネットワーク停止時間を必要とするならば、全体のネットワークの動作が１つのネットワークデバイスの停止時間によって悪影響を与えられるか、または、全てのネットワークデバイスの更新に非常に長い時間を要することになり、それにより、ネットワーク停止時間が増大し、生産性のロスを増加することになる。本発明の実施の形態は、そのような否定的な影響を回避する。この技術分野の当業者は理解するであろうが、新ＣＲＡのデプロイは、通常は、ネットワークアドミニストレータによって実行されるが、アドミニストレータでないユーザにも実行しうる。
【００４１】
その方法は、新たにデプロイされた拡張モジュール２２８を、１以上のユーザーに通告することにより、進められる。（ステップ３０８）この通告は、新たな拡張モジュール２２８がデプロイされたという事実によって自動的に発生する。代替として、新たな拡張モジュール２２８がデプロイされた後で、ネットワークアドミニストレータによって、この通告が開始されることもあり得る。更に、ユーザー通告の程度（すなわち、更新を通告されるユーザー数）は、ユーザーがこのような通告を受信することに同意していたかどうかなどの、ネットワークセキュリティの関心度により変化しうる。更に、その通告は電子的なフォーマット（例えば、Ｅメール、ＳＭＳメッセージ、インスタントメッセージ（ＩＭ）など）で来ることもあり、紙のフォーマットで来ることもある。
【００４２】
新たな拡張モジュール２２８がデプロイされたとの通告を受けると、ユーザーは、新たにデプロイされた拡張モジュール２２８、特に、新たな拡張モジュール２２８のＣＲＡの使用を含むように、プリファレンス１１６を更新する。（ステップ３１２）この更新は、通告に、直接に対応して開始されるか、または、分離してユーザーがウエブオプションインターフェースを介して、ユーザー登録サーバ１１２と通信して更新する。
【００４３】
ユーザープリファレンス１１６の更新は、コールルーティングメカニズム２１２の中のユーザープロビジョンドテーブル２１６の更新もまた引き起こす。（ステップ３１６）より明確には、ユーザーがコンタクトレゾリューションプリファレンスを更新したときに、その特定のユーザーのためのユーザープロビジョンドテーブル２１６の記載事項（ｅｎｔｒｙ）もまた、新しいプリファレンスを反映して更新される。より更に明確には、ユーザープロビジョンドテーブルの記載事項は、新たに加えられた拡張モジュール２２８の識別子を含んでいる。この識別子はもしユーザープロビジョンドテーブルが通告に直接に応答した場合は、自動的にテーブル２１６に入力され、または、ユーザープリファレンス１１６をマニュアルで更新した場合は、ユーザーが、識別子を入力する必要がある。一旦、ユーザープロビジョンドテーブル２１６が更新されたら、後に受信する、そのユーザーに宛てられたコンタクトは、新たに追加された拡張モジュール２２８を呼び出す。
【００４４】
この技術分野の当業者は理解するであろうが、ステップ３１２とステップ３１６は、単一のステップに結合しうる。もし、ユーザーがユーザープロビジョンドテーブル２１６を、中間のユーザー登録サーバ１１２を経由するよりも、直接に更新する場合には、特に、結合しうる。しかし、多数のコールルーティングメカニズム２１２を有する、より大きなネットワークでは、ユーザーの更新の単一の場所として、単一の登録サーバ１１２を持つことが望ましい。そのようなコンフィグレーションでは、単一の登録サーバ１１２は、（ユーザーの）プリファレンスに関して、ユーザーとのインターフェースとして機能し、その登録サーバ１１２は、ネットワーク中の他のコールルーティングメカニズム２１２に対して、ユーザープリファレンスへのどんな変更をも通告する。
【００４５】
図４を参照し、本発明の少なくともいくつかの実施の形態に応じて、インカミングコンタクトレゾリューションリクエストを処理する方法の一例を説明する。その方法は、コンタクトレゾリューションリクエストが、コールルーティングメカニズム２１２で受信されることで開始する。（ステップ４０４） コンタクトレゾリューションリクエストは、着呼者の識別子を含んでいる。この情報は、コンタクトレゾリューションリクエストの、１以上のヘッダーの中に含まれている。特にコンタクトレゾリューションリクエストが、ＳＩＰ ＩＮＶＩＴＥメッセージと関連づけられている場合は、そのメッセージ及びそのコンタクトレゾリューションリクエストは、ＳＩＰヘッダーの中の、ＡＯＲを介した着呼者の識別から構成される。しかしながら、理解できるように、インカミングコンタクトレゾリューションリクエストは、必ずしも、ＳＩＰメッセージの形式であることは必要ではない。むしろ、インカミングコンタクトレゾリューションリクエストは、ユーザーのＡＯＲによる特定のユーザーよりも、特定の通信デバイスを個別認識するような、アナログフォンまたは類似のものによって通話する、通常のインバウンドコールに相当する。コールルーティングメカニズム２１２は、代替的に、インバウンドコンタクトレゾリューションリクエストが、ユーザーの通信デバイスの１つがそのコンタクトによって識別され、その識別情報がコンタクトレゾリューションリクエストの中に含まれたという事実によって、特定のユーザーのためであることを決定することもある。
【００４６】
着呼者を識別すると、その方法は、そのユーザーのためのコンタクトレゾリューションプリファレンスを識別するために、コールルーティングメカニズム２１２がユーザープロビジョンドテーブル２１６を参照することで、続行する。（ステップ４０８） より明確には、コールルーティングメカニズム２１２は、テーブル２１６の中のユーザーのＡＯＲを識別し、どのＣＲＡがそのユーザーのために呼び出されるべきかを決定するようになっている。（ステップ４１２）そのＣＲＡは、そのＣＲＡと関連しているユニークなＩＤによって、識別される。本発明の少なくともいくつかの実施の形態に応じて、識別されたＣＲＡは、拡張モジュール２２８を介してコールルーティングメカニズム２１２に新たに追加されたＣＲＡに一致する。
【００４７】
ＣＲＡの識別子（より明確には、拡張モジュール２２８のユニークなＩＤ）を獲得すると、コールルーティングメカニズム２１２は、識別されたＣＲＡを呼び出し、コンタクトをそのＣＲＡにパスする。（ステップ４１６） 一旦、ＣＲＡがコンタクトを受信したら、ＣＲＡは、どちらのＳＩＰデバイス２３２が、それへとルートづけられたコンタクトを有するのが適切か、また、コンタクトのこのようなデバイスに、どのようにアラートするか、を決定するために、（必要なら）ダイナミックテーブル２２０を参照する。ＳＩＰデバイスの適格性は、呼び出されたＣＲＡに定義されているルールに基づき、また、ＳＩＰデバイス２３２がコールルーティングメカニズム２１２とともに記録されているかどうかに基づく。ＣＲＡのルールは、１つのＳＩＰデバイス２３２を最初にアラートし、もしユーザーがそのＳＩＰデバイスでコンタクトに応答しないならば、別のＳＩＰデバイス２３２にアラートする（シリアルフォーキング）よう、定義する。代替として、ＣＲＡのルールは、複数のＳＩＰデバイスに同時にアラートし、アラートに最初に応答したデバイスがコンタクトに勝利する（パラレルフォーキング）よう、定義することもできる。他のタイプのＣＲＡもまた、拡張モジュール２２８の中に含まれるが、本発明の実施の形態は、ここで議論したＣＲＡの例に必ずしも限定されない。
【００４８】
用語「コンピュータで読み取り可能な媒体」とは、コンピュータが実行するプロセスを記憶する媒体或いは伝送媒体を意味する。媒体とは、非揮発性媒体、揮発性媒体、伝送媒体を意味する。非揮発性の媒体とは、ＮＶＲＡＭ、磁気ディスク又は光学ディスクである。揮発性媒体とは、ＤＲＡＭ、メインメモリを意味する。このコンピュータで読み取り可能な媒体の一般的なものとしては、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気ディスク、他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、パンチカード、ペーパーテープ等、更にＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカード、メモリチップ、或いはカートリッジ等がある。ｅ−ｍａｉｌ或いは他の自己保存型の情報アーカイブに付属したデジタルファイルは、記憶媒体に等価な分配型の記憶媒体であり、本発明でいう記憶媒体と見なすことができる。コンピュータで読み取り可能な媒体がデータベースとして構築された場合には、このデータベースは、あらゆる種類のデータベース、例えば関連型、階層型、オブジェクト志向型のいずれをも含む。
用語「モジュール」「エージェント」「ツール」とは、ハードウエア、ソフトウエア、ファームウエア、人工知能、ファジーロジック、それらの組み合わせを言う。
上記したイベント、事象の発生順は、本発明の動作／効果に影響を与えずに変更可能である。特に断りのない限り、実施例の順にはこだわらない。
ここで議論したフローチャートは、特定のイベントのシーケンスを例に説明するが、本発明の操作に影響を及ぼすことなく、これ等のシーケンスの変更、追加、一部省略も可能である。本発明のシステムと方法は、特殊コンピュータ、プログラムされたマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、他の集積回路ＤＳＰ、ハードワイヤド電子素子、論理素子、例えばディスクリートな要素回路、プログラム可能な論理回路、ゲートアレイ、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、特殊目的コンピュータ或いは他の手段で実現できる。
他の実施例に於いては、ここに開示された方法は、オブジェクト指向のソフトウエア開発環境を用いたソフトウエアと組み合わせて実現できる。このソフトウエア環境は、様々なコンピュータ又はワークステーションで使用されるポータブルなソースコードを提供する。別の構成として、開示されたシステムは、標準の論理回路又はＶＬＳＩデザインを用いて一部又は全部のハードウエアで実現できる。本発明のシステムを実行するのにハードウエア又はソフトウエアを用いるかは、システムに要求される速度と効率に依存する。特に使用される特定のソフトウエア、ハードウエアのシステム、マイクロプロセッサ又はマイクロコンピュータシステムに依存する。
他の実施例に於いては、開示された方法は、コンピュータで読み取り可能な記憶媒体に記憶されたソフトウエアで実行され、コントローラとメモリとを有するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ等で実施される。これ等の実施例に於いては、本発明のシステムと方法は、パソコンに組み込まれたプログラムで実行できる。例えばアプレット、ＪＡＶＡ、ＣＧＩスクプリト、サーバ或いはコンピュータ、ワークステーションに記録された資源或いは専用の測定システムに組み込まれたルーチン等で実施できる。
本発明のシステムは、本発明のシステムと方法をソフトウエア又はハードウエアのシステムに物理的に組み込むことにより実施することもできる。 本発明は、特定の標準及びプロトコルを例に説明したが、本発明はこのような標準とプロトコルに制限されるものではない。他の類似の標準とプロトコルも本発明で用いることができる。これ等の標準とプロトコルは、今後開発されるより効率的な標準とプロトコルで置換されるかも知れないが、このような置換も本発明の一態様（一実施例）と考えられる。
【００４９】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００５０】
１０４ 通信ネットワーク
１０８ 通信デバイス
１１２ ユーザー登録サーバ
１１６ ユーザープリファレンス
２０４ 通信ネットワーク
２１２ コールルーティングメカニズム
２１６ ユーザープロビジョンドテーブル
２２０ ダイナミックテーブル
２２４ 旧ＣＲＡ
２２８ 拡張モジュール
２３２ ＳＩＰデバイス
３０４ ネットワークが動作中に新しい拡張モジュールがネットワークに追加された
３０８ ユーザーに新しい拡張モジュールを通告する
３１２ ユーザーが新しい拡張モジュールの使用を含むようにプリファレンスを更新する３１６ プリファレンスのユーザープロビジョンドテーブルを新しい拡張モジュールに向ける
４０４ インカミングコンタクトを受信する
４０８ ユーザープロビジョンドテーブルをＣＲＡプリファレンスと比較する
４１２ ユーザーの選択したＣＲＡのために使用されるべき拡張モジュールを識別する
４１６ 拡張モジュールを呼び出す
【特許請求の範囲】
【請求項１】
（Ａ）第１サーバで、第１ユーザーのためのコンタクトレゾリューションリクエストを受信するステップと、
（Ｂ）前記第１ユーザーのためのコンタクトレゾリューションプレファランスを識別するステップと、
（Ｃ）前記第１ユーザーのための前記コンタクトレゾリューションプレファランスが、コンタクトレゾリューションの一部として、拡張モジュールを使用することを決定するステップと、
（Ｄ）前記第１サーバによって、前記リクエストに対する前記拡張モジュールに、前記ユーザープレファランスのオプションを適用する、前記拡張モジュールを呼び出すステップと
を有する
ことを特徴とする方法。
【請求項２】
（Ａ）ユーザーコンタクトレゾリューションプレファランスを含むテーブルと、
（Ｂ）拡張モジュールと、
を有するサーバにおいて、
前記サーバが、第１ユーザーに宛てられたコンタクトと関連づけてコンタクトレゾリューションリクエストを受信し、前記第１ユーザーのコンタクトレゾリューションプレファランスについてのテーブルを参照し、その後、前記第１ユーザーのコンタクトレゾリューションプレファランスに基づいて、コンタクトレゾリューションリクエストに対して第１ユーザーのコンタクトレゾリューションプレファランスを適用するためにその拡張モジュールを呼び出す
からなる、サーバ。
【請求項３】
前記第１ユーザーのための前記コンタクトレゾリューションプレファランスが前記第１サーバに記憶されているユーザープロビジョンドテーブルの中で識別される
ことを特徴とする請求項１記載の方法。
【請求項４】
前記コンタクトレゾリューションテーブルが、ユーザーオプションインタフェースによって、コンフィグレーション及び再コンフィグレーションされる、ユーザー指向型であるデータから構成される
ことを特徴とする請求項３記載の方法。
【請求項５】
（Ｅ）第１ＳＩＰデバイスを前記第１サーバで登録するステップと、
前記第１ＳＩＰデバイスは、前記第１ユーザに関連づけられている
（Ｆ）第１ＳＩＰデバイスを前記第１サーバで登録したことを示すように、ダイナミックテーブルを更新するステップと、
（Ｇ）第２ＳＩＰデバイスを前記第１サーバで登録するステップと、
前記第２ＳＩＰデバイスは、前記第１ユーザに関連づけられている
（Ｆ）第２ＳＩＰデバイスを前記第１サーバで登録したことを示すように、ダイナミックテーブルを更新するステップと、
コンタクトレゾリューションの間、前記第１及び前記第２のＳＩＰデバイスにアラートするかどうかを決定するためのコンタクトレゾリューションリクエストの処理の間に、前記拡張モジュールが、前記ダイナミックテーブルを参照する、
を更に有する
ことを特徴とする請求項３記載の方法。
【請求項６】
前記ユーザープロビジョンドテーブルが、前記第１ユーザーのためのアドレスオブレコードと前記第１ユーザーのコンタクトレゾリューションプレファランスとの間のマッピングを有する
ことを特徴とする請求項３記載の方法。
【請求項７】
前記拡張モジュールを呼び出すことが、前記拡張モジュールと関連づけて識別子を決定すること、及び前記拡張モジュールを前記決定された識別子と参照することからなる、
ことを特徴とする請求項１記載の方法。
【請求項８】
前記拡張モジュールは、前記第１サーバが動作中で通信ネットワークに接続されている状態で、前記第１サーバ上にデプロイされるような、ホットデプロイ可能なものであり、前記第１サーバは、デプロイの前には前記拡張モジュールを持たず、前記第１ユーザーは、前記拡張モジュールのデプロイを通告される
ことを特徴とする請求項１記載の方法。
【請求項９】
前記拡張モジュールは、以下の項目の１以上を決定する
（ｉ） 前記第１ユーザーのＳＩＰデバイスを鳴らすかどうか。
（ｉｉ） 前記第１ユーザーのＳＩＰデバイスをいつ鳴らすか。
（ｉｉｉ）前記第１ユーザーのＳＩＰデバイスをどのように鳴らすか。
（ｉｖ） 第２のユーザーのＳＩＰデバイスを鳴らすかどうか。
（ｖ） 前記第２のユーザーのＳＩＰデバイスをいつ鳴らすか。
（ｖｉ） 前記第２のユーザーのＳＩＰデバイスをどのように鳴らすか。
ことを特徴とする請求項１記載の方法。
【請求項１０】
請求項１の方法を実施するように動作可能な、プロセッサーが実行可能なインストラクションをエンコードされた、コンピュータで読み取り可能な媒体。
【請求項１】
（Ａ）第１サーバで、第１ユーザーのためのコンタクトレゾリューションリクエストを受信するステップと、
（Ｂ）前記第１ユーザーのためのコンタクトレゾリューションプレファランスを識別するステップと、
（Ｃ）前記第１ユーザーのための前記コンタクトレゾリューションプレファランスが、コンタクトレゾリューションの一部として、拡張モジュールを使用することを決定するステップと、
（Ｄ）前記第１サーバによって、前記リクエストに対する前記拡張モジュールに、前記ユーザープレファランスのオプションを適用する、前記拡張モジュールを呼び出すステップと
を有する
ことを特徴とする方法。
【請求項２】
（Ａ）ユーザーコンタクトレゾリューションプレファランスを含むテーブルと、
（Ｂ）拡張モジュールと、
を有するサーバにおいて、
前記サーバが、第１ユーザーに宛てられたコンタクトと関連づけてコンタクトレゾリューションリクエストを受信し、前記第１ユーザーのコンタクトレゾリューションプレファランスについてのテーブルを参照し、その後、前記第１ユーザーのコンタクトレゾリューションプレファランスに基づいて、コンタクトレゾリューションリクエストに対して第１ユーザーのコンタクトレゾリューションプレファランスを適用するためにその拡張モジュールを呼び出す
からなる、サーバ。
【請求項３】
前記第１ユーザーのための前記コンタクトレゾリューションプレファランスが前記第１サーバに記憶されているユーザープロビジョンドテーブルの中で識別される
ことを特徴とする請求項１記載の方法。
【請求項４】
前記コンタクトレゾリューションテーブルが、ユーザーオプションインタフェースによって、コンフィグレーション及び再コンフィグレーションされる、ユーザー指向型であるデータから構成される
ことを特徴とする請求項３記載の方法。
【請求項５】
（Ｅ）第１ＳＩＰデバイスを前記第１サーバで登録するステップと、
前記第１ＳＩＰデバイスは、前記第１ユーザに関連づけられている
（Ｆ）第１ＳＩＰデバイスを前記第１サーバで登録したことを示すように、ダイナミックテーブルを更新するステップと、
（Ｇ）第２ＳＩＰデバイスを前記第１サーバで登録するステップと、
前記第２ＳＩＰデバイスは、前記第１ユーザに関連づけられている
（Ｆ）第２ＳＩＰデバイスを前記第１サーバで登録したことを示すように、ダイナミックテーブルを更新するステップと、
コンタクトレゾリューションの間、前記第１及び前記第２のＳＩＰデバイスにアラートするかどうかを決定するためのコンタクトレゾリューションリクエストの処理の間に、前記拡張モジュールが、前記ダイナミックテーブルを参照する、
を更に有する
ことを特徴とする請求項３記載の方法。
【請求項６】
前記ユーザープロビジョンドテーブルが、前記第１ユーザーのためのアドレスオブレコードと前記第１ユーザーのコンタクトレゾリューションプレファランスとの間のマッピングを有する
ことを特徴とする請求項３記載の方法。
【請求項７】
前記拡張モジュールを呼び出すことが、前記拡張モジュールと関連づけて識別子を決定すること、及び前記拡張モジュールを前記決定された識別子と参照することからなる、
ことを特徴とする請求項１記載の方法。
【請求項８】
前記拡張モジュールは、前記第１サーバが動作中で通信ネットワークに接続されている状態で、前記第１サーバ上にデプロイされるような、ホットデプロイ可能なものであり、前記第１サーバは、デプロイの前には前記拡張モジュールを持たず、前記第１ユーザーは、前記拡張モジュールのデプロイを通告される
ことを特徴とする請求項１記載の方法。
【請求項９】
前記拡張モジュールは、以下の項目の１以上を決定する
（ｉ） 前記第１ユーザーのＳＩＰデバイスを鳴らすかどうか。
（ｉｉ） 前記第１ユーザーのＳＩＰデバイスをいつ鳴らすか。
（ｉｉｉ）前記第１ユーザーのＳＩＰデバイスをどのように鳴らすか。
（ｉｖ） 第２のユーザーのＳＩＰデバイスを鳴らすかどうか。
（ｖ） 前記第２のユーザーのＳＩＰデバイスをいつ鳴らすか。
（ｖｉ） 前記第２のユーザーのＳＩＰデバイスをどのように鳴らすか。
ことを特徴とする請求項１記載の方法。
【請求項１０】
請求項１の方法を実施するように動作可能な、プロセッサーが実行可能なインストラクションをエンコードされた、コンピュータで読み取り可能な媒体。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１１−４３８６（Ｐ２０１１−４３８６Ａ）
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−７４１２０（Ｐ２０１０−７４１２０）
【出願日】平成２２年３月２９日（２０１０．３．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願番号】特願２０１０−７４１２０（Ｐ２０１０−７４１２０）
【出願日】平成２２年３月２９日（２０１０．３．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
[ Back to top ]