(57)【要約】データネットワーク上でテレフォニおよび他のサービスを提供するためのアプローチが開示されている。通信システム（１００）は呼ばれた当事者（１１８）に関連するすべてのアドレスのセットから第一のサブセットを生成する位置サーバ（１１５）を含む。プロキシサーバ（１１３）は位置サーバ（１１５）からアドレスの第一サブセットを得、アドレスのサブセットに基づいて呼ばれた当事者（１１８）とセッションを確立する試みを行う。アドレスの第一サブセットによって、セッションが確立するか否かに応答して、プロキシサーバ（１１３）は位置サーバ（１１５）から第二サブセットを要求してもよい。第一サブセット付きの位置サーバ（１１５）によって提供された状況情報は第二サブセットに対する要求の一部として位置サーバ（１１５）に戻されてもよい。
2005505948.tif 000002
【特許請求の範囲】
【請求項１】
通信システムに接続された少なくとも１人の当事者と通信セッションを確立するための方法であって、
位置サーバから、当事者との通信に関連する少なくとも一つの第一情報のセットを得るステップと、
第一情報セットを使用して通信システムを介してセッションを確立する試みを行うステップと、
第一情報セットを使用してセッションが確立されたかどうかに応じて、位置サーバから当事者との通信に関連する少なくとも一つの第二情報セットを得、第二情報セットを使用してセッションを確立する試みを行うステップとを含む、方法。
【請求項２】
第一情報セットは当事者に関連する少なくとも一つの通信システムアドレスを含む、請求項１に記載の方法。
【請求項３】
位置サーバに対して、位置サーバにおいて生じる処理に関連する状況情報を提供することをさらに含む、請求項１に記載の方法。
【請求項４】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項３に記載の方法。
【請求項５】
位置サーバから、位置サーバにおいて生じる処理に関連した状況情報を得るステップをさらに含む、請求項１に記載の方法。
【請求項６】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項５に記載の方法。
【請求項７】
第一情報セットを得ると共に、状況情報は、位置サーバから得られ、状況情報は、第二情報セットを得ると共に位置サーバに提供される、請求項１に記載の方法。
【請求項８】
位置サーバは第二情報セットを提供する間に状況情報を使用する、請求項７に記載の方法。
【請求項９】
状況情報は、アドレスの性質指示器、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項７に記載の方法。
【請求項１０】
位置サーバを含む通信システムにおいて、通信システムに接続された少なくとも１人の当事者と通信セッションを確立するための方法であって、
位置サーバに対して当事者に関連するコンタクト情報に対する第一要求を提出するステップと、
第一要求に応答して位置サーバから第一応答を得るステップを含み、第一応答は当事者に関連した一以上のコンタクトの少なくとも一つの第一セットを含み、
コンタクトの第一セットを使用して当事者とセッションの確立を試みるステップと、
第一セットのコンタクトがセッションを確立したかどうかに応答して、条件に応じて、
位置サーバに対して少なくとも一つの第二要求を提出するステップと、
第二要求に応答して位置サーバから第二要求を得るステップとを含み、第二応答は当事者に対して一以上のコンタクトの少なくとも一つの第二のセットを含み、
コンタクトの第二のセットを使用して当事者と条件付で実行するステップとを含む、方法。
【請求項１１】
第二要求は第一応答において提供された少なくとも一つのコンタクトに関連する、請求項７に記載の方法。
【請求項１２】
第二要求は第一応答におけるコンタクトの第一セットにおける少なくとも一つのコンタクトに応答して開始される、請求項７に記載の方法。
【請求項１３】
第二要求は第一応答の内容に応じて条件付きで提出される、請求項７に記載の方法。
【請求項１４】
第一応答は第二要求が提出されるべきかどうかに関連した情報を含む、請求項１３に記載の方法。
【請求項１５】
第一応答の少なくとも一つのコンタクトは第二要求が提出されるべきかどうかに関連する情報を含む、請求項１４に記載の方法。
【請求項１６】
位置サーバにおいて生じる処理に関連する状況情報を位置サーバに提供するステップをさらに含む、請求項１０に記載の方法。
【請求項１７】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項１６に記載の方法。
【請求項１８】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項１６に記載の方法。
【請求項１９】
位置サーバから、位置サーバにおいて生じる処理に関連した状況情報を得るステップをさらに含む、請求項１０に記載の方法。
【請求項２０】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項１９に記載の方法。
【請求項２１】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項１９に記載の方法。
【請求項２２】
状況情報は、第一応答セットと共に位置サーバから得、状況情報は第二要求と共に位置サーバに提供される、請求項１０に記載の方法。
【請求項２３】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項２２に記載の方法
【請求項２４】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項１８に記載の方法。
【請求項２５】
通信システムにおいて少なくとも１人の当事者についてのコンタクト情報を提供するサーバであって、
当事者に対するコンタクト情報の第一要求を受信するための手段と、
当事者に対する０以上のコンタクトを含む第一コンタクトセットを判定する手段と、
第一要求に応じて第一コンタクトセットを含む第一応答を出力する手段と、
第一要求に続いて当事者に対するコンタクト情報のための第二要求を受信する手段と、
当事者に対する０以上のコンタクトを含む第二コンタクトセットを判定する手段と、
第二コンタクトセットを含む第二要求に対して第二応答を出力する手段とを含み、
第二コンタクトセットは第一コンタクトセットと異なる、サーバ。
【請求項２６】
第一コンタクトセットと第二コンタクトセットの少なくとも一つは位置サーバによって維持される当事者のための全コンタクトのサブセットである、請求項２５に記載のサーバ。
【請求項２７】
第二要求は第一応答において提供された少なくとも一つのコンタクトに関連する、請求項２５に記載のサーバ。
【請求項２８】
第二要求は第一応答におけるコンタクトセットの少なくとも一つのコンタクトに応答して開始される、請求項２５に記載のサーバ。
【請求項２９】
第二要求は第一応答の内容に応じて条件付きで提出される、請求項２５に記載のサーバ。
【請求項３０】
第一応答は第二要求が提出されるべきかどうかに関連した情報を含む、請求項２９に記載のサーバ。
【請求項３１】
第一応答と共に、第二要求を提出すべきかどうかの少なくとも一つの指示器を提供する手段をさらに含む、請求項２５に記載のサーバ。
【請求項３２】
第一応答における少なくとも一つのコンタクトは、第二応答を提出すべきかどうかに関連する情報を含む、請求項２５に記載のサーバ。
【請求項３３】
第一要求に関連した状況情報を判定するための手段をさらに含む、請求項２５に記載のサーバ。
【請求項３４】
第二要求は状況情報を含む、請求項３３に記載のサーバ。
【請求項３５】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項３４に記載のサーバ。
【請求項３７】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項３３に記載のサーバ。
【請求項３８】
第一応答は状況情報を含む、請求項３７に記載のサーバ。
【請求項３９】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項３７に記載のサーバ。
【請求項３９】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項３７に記載のサーバ。
【請求項４０】
第二要求は状況情報を含む、請求項３７に記載のサーバ。
【請求項４１】
位置サーバは第二応答を準備している間に第二要求と共に提供される状況情報を使用する、請求項４０に記載のサーバ。
【請求項４２】
状況情報は、アドレス指示器の性質、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項４０に記載のサーバ。
【請求項４３】
通信システムにおいて当事者とセッションを確立するための少なくとも一つの要求を処理するためのプロキシサーバであって、
当事者に対するコンタクト情報のための第一要求を位置サーバに提出する手段と、
第一要求に応答して位置サーバから第一応答を受信する手段を含み、第一応答は第一コンタクトセットを含み、
第一応答から、さらなるコンタクト情報を得るために第二要求を実行するかどうかを判定する手段と、
第一応答に基づいて第二要求を開始する手段とを含む、プロキシサーバ。
【請求項４４】
位置サーバに対して第二要求を提出するための手段をさらに含む、請求項４３に記載のプロキシサーバ。
【請求項４５】
第一応答における少なくとも一つのコンタクトは第二要求を実行することの必要性を指示する情報を含む、請求項４３に記載のプロキシサーバ。
【請求項４６】
位置サーバからの第一コンタクトセットおよび第二コンタクトセットの少なくとも一つを使用してセッションを確立するための試みを行う手段をさらに含む、請求項４３に記載のプロキシサーバ。
【請求項４７】
第一応答の内容に応じて、プロキシサーバはそれ自身に対して第二要求を発送する、請求項４３に記載のプロキシサーバ。
【請求項４８】
位置サーバは少なくとも一つのコンタクトに最終指示器を関連させ、第二要求は最終性指示器の状態に応答して条件付で提出される、請求項４３に記載のプロキシサーバ。
【請求項４９】
第一応答と共に位置サーバから少なくとも一つの状況情報を受信する手段と、
第二要求と共に状況情報を提供する手段とをさらに含む、請求項４３に記載のプロキシサーバ。
【請求項５０】
状況情報は、アドレスの性質指示器、ダイアルプラン識別子および位置識別子の少なくとも一つを含む、請求項４９に記載のプロキシサーバ。
【請求項５１】
当事者に対してコンタクト情報を提供するための方法を実行するためのコンピュータ実行可能命令を有するコンピュータ読み出し可能媒体であって、方法は、
当事者に対するコンタクト情報に対する第一要求を受信するステップと、
当事者に対して０以上のコンタクトを含む第一コンタクトセットを判定するステップと、
第一コンタクトセットを含む第一要求に対して第一応答を出力するステップと、
当事者に対するコンタクト情報に対して第一要求に続いて、少なくとも一つの第二要求を受信するステップと、
当事者に対して０以上のコンタクトを含む第二コンタクトを判定するステップと、
第二コンタクトセットを含む第二要求に対して第二応答を出力するステップとを含み、第二コンタクトセットは第一コンタクトセットと異なる、コンピュータ読み出し可能媒体。
【請求項５２】
方法はさらに、
第一要求に関連した状況情報を判定するステップと、
第一応答の出力と共に状況情報を出力するステップと、
第二要求の受信と共に状況情報を受信するステップと、
第二コンタクトセットを判定するのに状況情報を適用するステップとを含む、請求項５１に記載のコンピュータ読み出し可能媒体。
【請求項５３】
当事者に対するコンタクト情報を得るための方法を実行するコンピュータ実行可能命令を有するコンピュータ読み出し可能媒体であって、方法は、
位置サーバに対して、当事者に対するコンタクト情報のための第一要求を提出するステップと、
位置サーバから第一要求に対する第一応答を受信するステップとを含み、第一応答は第一コンタクトセットを含み、
第一応答から、少なくとも一つの第二要求がさらなるコンタクト情報を得るために実行されるべきかどうかを判定するステップと、
第一応答に基づいて第二要求を開始するステップとを含む、コンピュータ読み出し可能媒体。
【請求項５４】
方法はさらに、
第一応答と共に位置サーバから状況情報を受信するステップと、
第二要求と共に位置サーバからに対して状況情報を提供するステップとを含む、請求項５３に記載のコンピュータ読み出し可能媒体。
【発明の詳細な説明】
【発明の分野】
【０００１】
[０００２]  この発明は通信システムに関し、特に、通信セッションを確立するためのアドレスの決定に関する。
【背景】
【０００２】
[０００３]  データ転送ネットワークの増殖、最も目立つのはインターネットであるが、リアルタイム通信のテレフォニおよび他の形式における革命を引き起こしている。テレフォニトラフィックとデータトラフィックを異なるシステムおよびネットワーク上で別々にサポートさせるということに慣れてきたビジネスは、電話音声トラフィックおよび他のリアルタイム媒体の他の形式がデジタル形式に変換されデータの他の形式と共にパケットデータネットワークによって搬送される、いわゆる「集中型のネットワーク」に向いて動きつつある。今や技術はそれをサポートすることが可能であるため、データ転送(transport)を介した音声は削減された資本および操作コスト、資源効率および柔軟性の点で多くの利点を提供する。
【０００３】
[０００４]  例えば、商業的設備においては、ＰＢＸのような自動呼び出し分配機能のような強化された機能のほとんどは、サービスプロバイダのネットワークに存在してもよいため、顧客構内装置の投資は実質的に減らされた。各種形式のゲートウエイのおかげでＩＰ電話、従来のアナログ電話およびＰＢＸならびにネットワークに接続されたデスクトップコンピュータのような多様化したシステムの間においてさえセッションが確立されてきた。
【０００４】
[０００５]  データ転送上で音声の要求にこたえるために、サービスプロバイダおよびネットワーク装置ベンダは、新しいプロトコルおよび標準の確立、新しいビジネスモデルの認識、新しいサービスの実行および２０年以前には想像することさえ難しかったような方法で新しい装置を設計すること等の課題に直面している。
【０００５】
[０００６]  例えば、エンドユーザ端末装置の新しい世代は、従来の電話および、より最近のＰＢＸ電話セットさえ置き換えつつある。シスコ(Cisco)およびピンテル(Pingtel)によって提供されるこのような新しい装置は、例えばイーサネット接続を介して一般のパケットデータネットワークにおよびユーザインターフェイスの豊富さを高めるために、外観の大きな視覚ディスプレイに直接接続されてもよい。
【０００６】
[０００７]  そのような装置が開発される前においてさえ、オーディオアダプタ付きでインターネットに接続されたコンピュータは、質は予測が不可能でかつしばしば非常にひどいものではあったが、インターネットテレフォニのある基本的な形態を実行することができた。今や、信頼できる料金の質の接続、容易な呼び出し設定およびメディアトランスポートの別の形態と共にフル機能のテレフォニを供給するための強化された特性を提供するために、インターネットプロトコル（ＩＰ）ネットワークおよび他のパケット転送ネットワークを採用することが強調されている。そのような技術によって可能になった媒体セッションのある別の形式は、ビデオ、質の高いオーディオ、多数当事者会議、メッセージングおよび協力的なアプリケーションを含んでもよい。
【０００７】
[０００８]  もちろん、ビジネスおよび住居の通信加入者(subscriber)は、従来のテレフォニと置き換えるためのそのような音声オーバパケット通信の使用を開始するため、接続の質およびサービスの多様性は、以前の電話ネットワークにおけるのと少なくとも同様であることの期待が当然存在する。例えば、サービスの点では、ビジネスの中には呼び出し転送および条件付き呼び出し処理のようなＰＢＸ特性またはネットワークに存在する「セントレックス」(Centrex)特性に頼るものもある。近い将来において、そのような特別のサービスの使用の増大が予測される。というのは、先に述べた新しい端末装置がユーザに対してずっと直感的なインターフェイスを提供できるからである。既存のシステムにおいては、ユーザはキーストロークのどの組み合わせが強化された特性を実行するのに要求されるのかということをしばしば忘れる。
【０００８】
[０００９]  ネットワークにおいて通信セッションを確立するために、新しいプロトコルおよび制御アーキテクチャが現れてきた。これらはデータ上での音声移行によって刺激されてきたが、そのような環境に必ずしも限られるものではないということに注意すべきである。ある点において、次に述べられるプロトコルと制御アーキテクチャは転送の任意の形態を介して呼び出しを確立するために使用されてもよい。
【０００９】
[００１０]  ＩＴＵ  Ｈ.３２３標準およびＩＥＴＦのセッション開始プロトコル（ＳＩＰ）は共にネットワークに接続された端末間での通信セッションを確立するために使用されてもよいプロトコルの例である。ＳＩＰプロトコルはＩＥＴＦドキュメントＲＦＣ２５４３およびその後継者に述べられている。各種アーキテクチャが、ユーザのために、任意の宛先にどのように到着するのかとか、特性をどのように制御するのかといった現在の情報を維持するためにネットワークのどこかで「位置サーバ」と呼ばれる、アドレス解決機能を有する共通のテーマを有する、これらプロトコルと関連して提案されている。
【００１０】
[００１１]  他のリアルタイムの通信同様、データトランスポート上での音声の大規模な展開のために、ネットワーク制御アーキテクチャは、毎日、数１００万のセッションを信頼性を持って処理できる極端な信頼性と、高度な拡張性を有することが必須である。信頼性は冗長性とフェイルオーバ機構の設計を必要としてもよい。好ましくは、これらの対策は、セッションの途中で故障が生じたとしても、既存のセッションおよび特性のトランスペアレントな連続性を提供する。このレベルの信頼性を確実にし、拡張性を最大にするために、位置サーバのような、制御機能に基づく要求を最小にすることが、ネットワーク
における各呼び出しのための任意の持続性状態を維持するために一般に好ましい。
【００１１】
[００１２]  他のニーズと同様にセッション処理システムにおける信頼性および拡張性のニーズが統合された通信システムがデータネットワーク上でテレフォニおよびデータサービスを提供するこの発明によって対処される。模範的な実施例においては、システムは通信セッションの確立ためにセッション開始プロトコル（ＳＩＰ）を利用する。
【００１２】
[００１３]  簡単に言うと、セッションは次のように開始される。プロキシサーバが、第一のユーザが第二ユーザにコンタクトを望む呼び出しセッションから典型的に、まずＳＩＰ「ＩＮＶＩＴＥ」（インバイト）メッセージのような要求を要求を受信する。第二ユーザは例えば、電話番号、ＩＰアドレスまたはユニフォームリソースロケータ（ＵＲＬ）によって識別されてもよい。プロキシサーバは、第一ユーザが第二ユーザに到着する特権を確認したり、第二ユーザに対する一以上の位置を見つけたり、第一または第二ユーザに対して規定された(provisioned)任意の呼び出し処理特性を実行するといった目的のために、経路制御(routing)要求を位置サーバに中継してもよい。一般に、位置サーバは第二ユーザがコンタクトしてもよい端末の一以上のアドレスをプロキシサーバに戻すことによってプロキシの要求に応答する。
【００１３】
[００１４]  位置サーバからのアドレス情報を受信すると、プロキシサーバは各アドレスに対して「ＩＮＶＩＴＥ」メッセージまたは同様のものの送信を開始する。このように、プロキシサーバは連続的にまたはパラレルにアドレスを試みることによって第二ユーザに到着しようと試みる。
【００１４】
[００１５]  多数のアドレスは、例えば、もし所与のユーザプロファイルが「ファインドミー」リスト、すなわち、呼ばれている第二ユーザに到着しようと試みられるべきコンタクトのセット、を示していれば、位置サーバによって戻されてもよい。位置サーバによって維持されたそれらのプロファイルのプロビジョニングによって、ユーザは、例えば、入来呼び出しがまずＩＰ電話に行き、それから別の電話、それから移動電話、そしてそれらの場所で返事がないときは、音声メールシステムに行くように特定する。
【００１５】
[００１６]  ファインドミーリストにおけるエントリはネットワーク内のさらに別のアカウントを表すアドレスであってもよい。このアカウントはファインドミーリストを含むそれ自身の関連したプロファイルを代わりに有してもよい。それゆえ、ユーザによって要求された単一の呼ばれた当事者が、位置サーバにおいてコンタクトアドレスの階層に対応することは可能である。
【００１６】
[００１７]  この現象は、位置サーバに対してかなりの負担を負わせる。というのは、たとえ呼ばれた当事者がプロキシサーバによって試みられた最も速いコンタクトアドレスの一つで到着されうるとしても、潜在的に大量のコンタクトアドレスが、各ＩＮＶＩＴＥ要求に対して決定されかつ戻される必要があるからである。
【００１７】
[００１８]  ある局面においては、この発明は、大量のアドレスが一度に位置サーバによって決定される必要がない、代案のアプローチを提供する。代わりに、位置サーバはプロキシサーバからの最初の経路制御要求に応じて第一セットのアドレスを戻してもよく、そしてそれからプロキシサーバからの引き続く経路制御要求に基づいて更なるアドレスを戻してよい。
【００１８】
[００１９]  好ましい実施例に従えば、位置サーバは、アドレスのリストを戻すが、そのリストのいくつかはそれ自身が多数のコンタクトを生じる他のアカウントに対応してもよい、プロキシに戻される。この最初のリストは、これらの後者のコンタクトの完全な「拡張された」リストを含まない。代わりに、好ましい実施例に従って、各そのような「拡張可能な」アドレスは、それが多数のアドレスに拡張されてもよいということを示すためにアドレスに関連したタグ、またはフラッグと共に最初のリストにおいて単に報告されてもよい。最初のアドレスのリストを介した作業において、プロキシサーバはこのタグを用いて拡張されたアドレスセットが必要な場合、およびその時のみに拡張されたアドレスセットの連続した検索を引き起こす。
【００１９】
[００２０]  位置サーバがセッションのための持続した状態情報を保持することなくプロキシからのこれらの次の要求を効率的に処理することを可能にするために、追加の状況情報がプロキシサーバに対して位置サーバによって戻された各アドレスに提供される。プロキシサーバは、位置サーバからのさらなるコンタクトを次に要求するため、プロキシサーバは次の要求において状況情報を含む。以下により詳細に説明されるように、この状況情報を位置サーバに渡すことによって、位置サーバは最初の経路制御要求のために、単に実行される必要のある多くのステップを有利に飛ばすことができる。
【００２０】
[００２１]  このようにして位置サーバを維持状態から解放することによって、任意の利用可能な位置サーバが次の要求を処理することが可能になるということが特に重要である。言い換えると、拡張されたアドレスセットに対して次の要求をサービスする位置サーバが最初のリストを提供したのと同じ位置サーバである必要はない。すべての位置サーバは均等に作動すると共に、アドレスの一貫したイメージおよびユーザプロファイル情報を維持するべきである。異なる位置サーバへの相談の必要性は、フェイルオーバまたは負荷のバランス機構によって生じてもよい。
【００２１】
[００２２]  この発明のある局面においては、当事者が多数のコンタクトを利用した状態で通信セッションを確立するための方法が開示されている。位置サーバは当事者のためにコンタクトのセットを維持する。方法は、位置サーバからコンタクトの最初のセットにおけるステップと、コンタクトの最初のセットを使用して当事者とセッションを確立するために試みるステップと、セッションが最初のコンタクトのセットを使用して確立されなかったとき、試みるために次のコンタクトのセットを得るステップとを一般に含む。
【００２２】
[００２３]  この発明の別の局面においては、位置サーバにおいて生じる処理に関連した状況情報が当事者のためのコンタクト要求と関連して位置サーバから得られる。同じ状況情報が、位置サーバによる次の要求の処理を容易にするために、次の要求と共に位置サーバに提供される。
【００２３】
[００２４]  この発明の別の局面においては、位置サーバから得られる一以上のコンタクトは位置サーバに対するさらなる要求を引き起こしてもよい。
【００２４】
[００２５]  この発明の別の局面においては、位置サーバから得られた一以上のコンタクトは位置サーバに対する次の要求が所与のコンタクトに対して適切であるかどうかということを示す指示を有してもよい。
【００２５】
[００２６]  この発明の別の局面においては、位置サーバ手段は、最初のおよび続く要求に応答して、当事者のためにコンタクト情報を提供できる位置サーバ手段が開示されている。
【００２６】
[００２７]  好ましい実施例に従えば、位置サーバ手段は、位置サーバにおける処理に関連した状況情報を提供および受信するための手段を含む。さらに、好ましい実施例によれば、位置サーバ手段は、要求に応じて各コンタクトが提供された状態で、最終指示器を提供するための手段を含む。
【００２７】
[００２８]  この発明の別の局面においては、提供されたコンタクトを使用して、位置サーバからのコンタクトを得、当事者とセッションの確立を試みることによって、セッション要求を処理するプロキシサーバ手段が開示されている。好ましい実施例に従えば、プロキシサーバ手段はコンタクトを使用してセッションが確立されたかどうかを判定し、応答として位置サーバからのさらなるコンタクトを得るかどうかを決定する。
【００２８】
[００２９]  好ましい実施例に従えば、プロキシサーバ手段は、コンタクトのあるセットを得ると共に、位置サーバからの状況情報の処理を受け入れ、それから状況情報をコンタクトのための次の要求と共に位置サーバに提供する。
【００２９】
[００３０]  好ましい実施例に従えば、プロキシサーバ手段は、さらなるコンタクトのための次の要求が提出されるべきであるかどうかを判定するために位置サーバからの応答を解釈する。好ましい実施例に従えば、プロキシサーバ手段は先の応答において提供されたコンタクトに応答して位置サーバからコンタクトのための次の要求を開始する。好ましい実施例に従えば、プロキシサーバ手段は次の要求がコンタクトに応答して位置サーバに対して提出されるべきかどうかを決定するためにコンタクトに関連した指示器を解釈する。
【００３０】
[００３１]  この発明の別の局面においては、位置サーバ手段を実行するための方法を実行するためのコンピュータ実行可能命令を有するコンピュータ読み出し可能媒体が開示されている。
【００３１】
[００３２]  この発明の別の局面においては、プロキシサーバ手段を実行するための方法を実行するためのコンピュータ実行可能命令を有するコンピュータ読み出し可能媒体が開示されている。
【００３２】
[００３３]  この発明のさらに別の局面、特徴および利点はこの発明を実行するために考慮されたベストモードを含む、多数の特定の実施例および具体例を単に例示することによって以下の詳細な説明から容易に明らかである。この発明はまた別の実施例も可能であり、その多くの詳細はこの発明の精神および範囲から離れることなく各種の点において修正されうる。従って、次の図面および説明は制限的なものではなくて性質的に例示的なものであると見なされるべきである。
【詳細な説明】
【００３３】
[００３５]  以下の説明において、公知の構造および装置はブロック図の形態で示されるかまたは、この発明を不必要にあいまいにするのを避けるためにそうでない場合には要約される。説明のために、この発明の完全な理解を提供するために多くの特定の詳細が述べられている。しかしながら、この発明はこれらの特定の詳細を超えて各種の方法で実行されてもよい。
【００３４】
[００３６]  例えば、この発明はセッション開始プロトコル（ＳＩＰ）およびインターネットプロトコル（ＩＰ）に基づくネットワークの状況において議論されてはいるが、当業者は、この発明は他の均等なまたは類似の通信プロトコルまたは通信ネットワークに一般的に適用してもよいということを認識する。
【００３５】
[００３７]  この開示を通して、ＳＩＰ型のメッセージが便利のために示されているが、任意の形式のプロトコルまたはそのようなプロトコルの混合が全システムの各種部分に適用されてもよいということが理解されるべきである。特に、プロキシサーバおよび位置サーバ間の経路制御要求および応答は厳格にまたは緩やかにＳＩＰまたは何らかの他の標準化されたプロトコルに一致してもよいしまたは性質として独自性があってもよい。
【００３６】
[００３８]  図１はこの発明の模範的な実施例に従う音声サービスをサポートすることができるデータ通信システムの図を示す。通信システム１００はパケットデータ転送ネットワーク１０１を含み、これは模範的な実施例においてはインターネットプロトコル（ＩＰ）に基づくネットワークである。システム１００は、電話１２５、ＰＢＸ電話１１８およびＳＩＰ電話１０９のようなそこに接続された各種端末装置間で通信を確立するための能力を提供する。実際、一以上のシステム１００によってサービスが提供されるそのような端末装置が数千または数百万存在しうる。
【００３７】
[００３９]  ここで使用されているように、「ＳＩＰ電話」という文言はＳＩＰ電話機能性を提供するよう設定された任意のクライアント（例えば、パーソナルコンピュータ、ウエブ装置など）をいう。ＳＩＰ電話１０９はスタンドアロン装置の形態を取ってもよい。例えば、ＳＩＰ電話は簡単な古い電話サービス（ＰＯＴＳ）電話ステーションのように見え、そのように機能するよう設定および設計されてもよい。しかしながら、ＳＩＰクライアント１１１はソフトウエアクライアントであり、例えば、従来のパーソナルコンピュータ（ＰＣ）またはラップトップコンピュータ上で実行可能であってもよい。信号送信の観点から、これらの装置１０９、１１１は、主な相違がユーザインターフェイスに関するが、全く同様に動作してもよい。他に規定がない限り、ＳＩＰ電話１０９およびＳＩＰクライアント１１１の両方の機能性は匹敵し、ネットワークは、いずれの形式の装置共同様に動作するということが認識される。
【００３８】
[００４０]  システム１００は、企業ゲートウエイ１０３、専用アクセスライン（ＤＡＬ）ゲートウエイ１０５、ネットワークゲートウエイ１０７およびＳＩＰ会議プラットフォーム１２７を含む、音声サービスをサポートするために多くの要素を提供する。特に、システム１００はプロキシサーバ１１３（また、ネットワークサーバ（ＮＳ）として知られている）の重要な要素および位置サーバ（ＬＳ）１１５を含む。位置サーバ１１５はエンドユーザ情報がアドレスの検証、特性状態およびリアルタイムの加入者特性設定を可能にする容器として作動する。加えて、ＬＳ１１５は設定情報を格納してもよい。
【００３９】
[００４１]  説明のために、システム１００の能力は大企業ユーザに関連して述べられる。システム１００の特性／機能性は各種のユーザタイプおよび通信のニーズに適用可能であってもよい。システム１００は、多数の位置で音声およびデータ要求を維持する顧客をサポートすることができる。
【００４０】
[００４２]  示されているように、企業ゲートウエイ１０３は、しばしば、単一のビジネス顧客かまたは位置（例えばＰＢＸ電話１１８）に対するトランクまたは線を含む、ＰＢＸから接続性を提供する。ＩＰネットワークへのＰＢＸ１１７からの呼び出しのための信号送信は、顧客、トランクグループまたはキャリアを独自に識別する情報を含む。これによって私的な番号がそれらの正しい状況に解釈されうる。ＰＢＸ１１７にインターフェイスするために、企業ゲートウエイ１０３は総合デジタル通信網（ＩＳＤＮ）、回路関連信号送信（ＣＡＳ）、またはＰＢＸインターフェイス（例えば、ヨーロッパ電気通信規格研究所（ＥＴＳＩ）ＰＲＩ、Ｒ２）を使用してもよい。
【００４１】
[００４３]  システム１００における専用アクセス線（ＤＡＬ）ゲートウエイ１０５は仮想私設網（ＶＰＮ）顧客がＶＰＮによってサービスを提供されない従来の電話からさえそのサービスにアクセスが可能になるようにする。
【００４２】
[００４４]  システム１００を通して、ＰＳＴＮ１２３およびパケットデータネットワーク１０１に取り付けられたパーソナルコンピュータ（例えばＰＣ１１１）を介してサービスを提供される音声ステーション１２５間で通信が確立されてもよい。
【００４３】
[００４５]  ＰＣソフトクライアントとスタンドアロンＩＰ電話の同様の特性を留意して、ボイスオーバＩＰ呼び出しの配置に関して４つの可能なシナリオが存在するといえる。（１）電話と電話、（２）電話とＰＣ、（３）ＰＣと電話および（４）ＰＣとＰＣ。電話と電話の呼び出しを確立する最初のシナリオにおいては、電話１２５からの電話呼び出しは、ネットワークゲートウエイ１０７への切り換えによるＰＸＴＮ１２３を介して切り換えられ、これがＩＰバックボーンネットワーク１０１を介して呼び出しを転送する。パケット化された音声呼び出しは、別のＰＳＴＮ電話（図示なし）に存在する、他の別の類似のネットワークゲートウエイ１０７へ、ネットワーク１０１を介して経路制御される。第二シナリオの下では、電話１２５はＰＳＴＮ１２３にスイッチを介してＰＣに呼び出しを行う。この音声呼び出しはＰＳＴＮ１２３によってＳＩＰネットワークゲートウエイ１０７に切り換えられ、ＳＩＰネットワークゲートウエイ１０７は音声呼び出しをネットワーク１０１を介してＰＣ１１１に転送する。第三のシナリオは音声ステーション（例えば電話１２５）への呼び出しを行うＰＣ１１１を含む。音声エンコーダを使用して、ＰＣ１１１は、ＳＩＰネットワークゲートウエイ１０７に予定されたネットワーク１０１へ音声パケットの流れを導入する。ＳＩＰネットワークゲートウエイ１０７はパケット化された音声情報をＰＯＴＳ電気信号に変換し、ＰＯＴＳ電気信号は音声ステーション（例えば電話１２５）に回線交換される。最後に、第四のシナリオにおいては、ＰＣ１１１が別のＰＣ（図示なし）と音声呼び出しを確立する。この場合において、パケット化された音声データはネットワーク１０１を介してＰＣ１１１からパケット音声データが復号化される別のＰＣ（図示なし）にネットワーク１０１を介して送信される。
【００４４】
[００４６]  上記したように、システム１００はセッションセットアップメッセージを交換するためにＳＩＰを採用してもよい。現実的には国際電気通信連合（ＩＴＵ）によってマルチメディア通信を完成させるために普及された関連したプロトコルのセットではあるが、別の一般的なセッション確立プロトコルはＨ.３２３プロトコルと呼ばれる。これは、ＳＩＰはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって開発されてきた代わりの標準である。ＳＩＰは、サービスを提供することができるサーバに対して要求をメッセージすることによって、要求されたサービスをクライアントが実行するということを一般に意味するクライアントサーバモデルに基づいた信号送信プロトコルである。他のＩＥＴＦプロトコル（例えば、シンプルメィルトランスファプロトコル（ＳＭＴＰ）と同様におよびハイパトランスファプロトコル（ＨＴＴＰ））と同様に、ＳＩＰはテキスト系の人間が読み出し可能なプロトコルである。
【００４５】
[００４７]  Ｈ.３２３およびＳＩＰプロトコルのいずれもＩＰテレフォニアプリケーションに限定されておらず、一般にマルチメディアサービスに適用可能性を有するということに注意されてもよい。この発明のある実施例においては、ＳＩＰはシステム１００を介して電話呼び出しおよび他のセッション形式を確立するために使用される。しかしながら、当業者にとって明らかなように、Ｈ.３２３プロトコル（何らかの修正または拡張を含む）または他の類似のプロトコルはＳＩＰの代わりに使用されうる。ＳＩＰとは別にしかししばしばＳＩＰと共に使用されるのがセッション記述プロトコル（ＳＤＰ）であり、これはセッション記述の受信者がセッションに参加することを許可するマルチメディアにおけるメディアストリームについての情報を提供する。
【００４６】
[００４８]  インターネットエンジニアリングタスクフォースのＳＩＰプロトコルはメソッドとしてまた呼ばれる、要求の各種形式を規定する。重要なメソッドはＩＮＶＩＴＥ（インバイト）メソッドであり、これはユーザを会議に招待する。別のメソッドはＢＹＥ要求であり、これは呼び出しが解放されてもよいことを示す。言い換えると、ＢＹＥは２ユーザ間または会議中の当事者間の接続を終了させる。別のメソッドはＯＰＴＩＯＮＳメソッドである。このメソッドは呼び出しを必ずしも確立することなく、能力についての情報を求める。ＲＥＧＩＳＴＥＲメソッドはユーザの現在の位置について、ＳＩＰサーバに情報を提供するために使用されてもよいメソッドである。
【００４７】
[００４９]  ＳＩＰに関する詳細およびその呼び出し制御サービスはＩＥＴＦ  ＲＦＣ２５４３およびＩＥＴＦインターネットドラフト"SIP Call Control Services", June 17, 1999に述べられており、これらドキュメントの両方の全体をここに参照により引用する。
【００４８】
[００５０]  ＳＩＰメッセージの送信は、よく知られたユーザデータグラムプロトコル（ＵＤＰ）またはより信頼性のあるトランズアクション制御プロトコル（ＴＣＰ）を介してＩＰネットワークにおいて生じる。ＳＩＰ、Ｈ.３２３または他のプロトコルがデータネットワークを介したセッションを確立するために使用されてもよいが、ユーザ間において通信される現実の媒体または「トラフィック」は、よく知られた、ＩＥＴＦドキュメントＲＦＣ１８８９に記載されたリアルタイムトランスポート（ＲＴＰ）に従って生じてもよい。
【００４９】
[００５１]  本質的ではないが、呼び出し制御信号送信（ＳＩＰ、Ｈ.３２３）のすべて、媒体トラフィック（ＲＴＰ／ＲＴＣＰ）およびネットワーク管理およびプロビジョニングは、共通のトランスポートネットワーク１０１を介して通信される。このように、図１においては、要素のすべてがトランスポートネットワーク１０１の周りでハブの配置に現れる。
【００５０】
[００５２]  従来の電話ネットワークにおいては、呼び出しは、呼ばれた電話番号によって独自に識別される特定の位置または端末装置に向けられる。対照的に、システム１００は、呼び出し者が任意の特定の位置または端末に無関係に到達される呼ばれた当事者を呼び出し者が特定することを可能にする。
【００５１】
[００５３]  ユーザはある端末から別の端末へ移動してもよく、各端末で、入来呼び出しが最も最近登録された位置に向けられるように存在しているとして登録してもよい。さらに、ユーザは、呼び出し遮断のような特性の活性化に影響を及ぼす個人およびグループ的な両プロファイル設定を有してもよく、時間帯の関数としてもよい。
【００５２】
[００５４]  ユーザの位置や呼び出し処理特性の動的な性質にかんがみて、セッションを確立するための各要求はまず、ユーザの許可が認証され、宛先アドレスが見つけられ、ユーザまたはビジネスに関連した特別の特性が呼び出しに適用されるように、プロキシサーバにまず経路制御される。要求は内部でサービスされるかまたはそれらを変換の後、他のサーバに手渡すことによって処理される。プロキシは解釈を行い、必要であれば、それを転送する前に要求メッセージを書き換える。
【００５３】
[００５５]  一般的に、位置サーバ１１５はプロキシサーバからのような経路制御要求を受け入れ、経路制御要求中に表現された宛先当事者に対応するアドレスまたは「コンタクト」を決定する。要求に応答して、位置サーバはその当事者に対するコンタクトを情報を含むリダイレクト応答を戻してもよい。ＮＳ１１３およびＬＳ１１５間のメッセージはＳＩＰの修正されたバージョンを使用してもよい、ということに注意のこと。例えば、ＳＩＰの通知メッセージはＮＳ１１３およびＬＳ１１５との間では不必要であってもよい。そうでなければ、ＮＳ１１３とＬＳ１１５のようなネットワーク機能間のメッセージは標準のＳＩＰまたは非ＳＩＰ代案さえ使用してもよい。
【００５４】
[００５６]  システム１００はプロビジョニング、請求、ネットワーク管理能力を提供するために運用支援システム（ＯＳＳ）１２１をさらに含む。ＯＳＳ１２１は、ダイアルプラン、ユーザ許可および各ユーザのためにどのように特性が作動するのかという、多くの局面を提供するために、ウエブに基づくインターフェイスのような環境またはインターフェイスを提供してもよい。これらの局面の多くは位置サーバまたは、システム１００内の情報を変えることによってＯＳＳ１２１を介して設定される。ＯＳＳ１２１によって設定されてもよいある特定の特性は、無条件の呼び出し転送、条件付呼び出し転送、呼び出し遮断および呼び出しスクリーニングのようなレガシー(legacy)セントレックス特性を含むＯＳＳ１２１によって設定されてもよい。
【００５５】
[００５７]  設定されてもよいある特性は、いわゆる「ファインドミー」サービスを含む。ファインドミー計画は、各宛先が順に試みられる可能な宛先のリストを用いた呼び出しを経路制御するための機構を提供する。ファインドミーリストは時間帯または曜日別が適用されるよう特定されてもよく、また呼び出し番号の異なるカテゴリーに関連してもよい。さらに、デフォルトのファインドミーリストは、特定のファインドミーリストが効力がなくなる時の一般的な処理を決定するために提供(provisioned)されてもよい。
【００５６】
[００５８]  ファインドミーリストにおける可能な宛先はアカウントプロファイルに関連した特定のアドレスでありうる。例えば、特定の携帯電話番号または無線電話番号は可能な宛先アドレスでありうる。さらに、ユーザが、ＳＩＰ電話のような端末で自分たちの存在を登録すると、端末のアドレスはファインドミーリストに一時的に加えられてもよい。
【００５７】
[００５９]  ＳＩＰ電話プロファイルに対して、ファインドミーリストはユーザプロファイルおよび／または現在の登録されたアドレスに対する参照において、提供された特定の宛先アドレスを含むことができる。企業ゲートウエイプロファイルの後ろの従来の電話に対してはファインドミーリストはユーザプロファイルおよび／またはユーザのＰＢＸ電話に対する参照において与えられる特定の宛先アドレスを含むことができる。ファインドミーリストの特性はアカウント生成の間にユーザに対して可能にされ、それからユーザによって更新される。ファインドミーリストになされたエントリは加入者のダイアルプランのための特性ブロッキングリストに対して確認されてもよい。ユーザプロファイルはファインドミーリストを更新するためにリンクを有する。特に、システム１００はユーザが、ファインドミーリストを一般化するために使用されうる、可能性のある装置の在庫を生成、読み出し、更新および削除することを許可する。
【００５８】
[００６０]  ＳＩＰ電話１０９はユーザが電話から登録または登録取り消し、またはログインまたはログアウトするのを許容する。模範的な実施例においては、移動性を提供するために、ＳＩＰ電話１０９はビジターがユーザ名とパスワードを入力するのを許容する。ログインによってＳＩＰ電話はビジターのプロファイルを仮定することができる。ログインすることによって、ビジターのプロファイルに対する入来呼び出しは電話に向けられる。ビジターがログインすると、ＳＩＰ電話１０９はネットワークサーバ１１３および位置サーバ１１５にビジターを登録する。電話によって登録された任意のプロファイルに対する任意の入来呼び出しは電話に向けられうる。ネットワークサーバ１１３と位置サーバ１１５はユーザがビジターとしてログインする状態またはユーザが、もし存在すれば、それらの普通の家の装置にログインする場合の両方において同様に応答してもよい。ネットワークサーバ１１３および位置サーバ１１５の論理はプロキシ認可課題の結果として配送されたユーザ名に頼ってもよい。
【００５９】
[００６１]  Ｅ.１６４およびＤＮＳアドレスに関して、ＳＩＰ電話１０９は、ＩＰドメインまたはＥＮＵＭ可能化ネットワークで発生した呼び出しを経路制御するために使用されるＥＮＵＭ（電子番号）サービスをサポートしてもよい。ＥＮＵＭサービスは、「ＥＮＵＭ」というタイトルで、ＩＥＴＦ  ＲＦＣ２９１６において詳細が記載され、その全体を参照によってここに引用する。ＳＩＰ電話１０９はクライアントに基づくディレクトリ検査のためにまたＬＩＮＣＰをサポートしてもよい。
【００６０】
[００６２]  「邪魔しない」特性は、入来呼び出しが減少し、例えば電話またはページャの場合には、近くのユーザを邪魔しないようベルを鳴らさないように端末で利用可能である。「邪魔しない」がＳＩＰ電話１０９で実行されたとき、ＳＩＰ電話１０９はＮＳ１１３によってコンタクトされたとき、ビジーメッセージを戻す。例えば、電話は入来呼び出しが到着したときベルの代わりにビジー信号を戻す。ＳＩＰ電話１０９が「４８６ビジー」メッセージを戻すと、ネットワークサーバ１１３および位置サーバ１１５は、ビジー特性に基づく呼び出し転送が供給されたかどうかのような、ユーザプロファイルに基づいてインテリジェントな経路制御決定を行うことができる。
【００６１】
[００６３]  図２はＳＩＰプロトコルを使用してセッションのセットアップを実行するための従来技術に従う基本的な要素の典型的な相互作用を示す図である。これら要素間の通信は図１のＩＰネットワーク１０１のような一般のパケットデータネットワークを介して典型的には生じる。
【００６２】
[００６４]  図２において、ユーザＡ２１０はユーザＢ２２０と通信を確立したいと望む。ユーザＢ２２０は多くのアドレスの内の任意の一つで到着される。これらのアドレスまたはコンタクトは従来の電話、ＩＰ電話、無線電話、ページャなどに対応してもよい。アドレスのリストは、ユーザＢが動きまわり、各種端末装置２２２で存在するとして登録するにつれて変化してもよい。ユーザＢのコンタクト情報についての現在の情報は位置サーバ２４０において典型的には維持されるか、または、ここには示されていない何らかの形式の存在登記において維持される。
【００６３】
[００６５]  コンタクトを開始するために、ユーザＡ２１０は端末、呼び出しステーション２１２にアクセスし、到着されるべき宛先としてユーザＢを特定する。この特別の所望の宛先の表現は数字のダイアルの形態またはリストからユーザ名またはＵＲＬ形式のアドレスを選択するという形態をとる。ある場合には、ユーザＡはどのような形態のセッションを望むのか（ビデオ、質の高い、メッセージなど）ということを表現できてもよく、またはセッションのための所望の質のレベルを特定してもよい。要求がひとたびステーション２１２で特定されると、要求を述べたＳＩＰ「ＩＮＶＩＴＥ」メッセージは構成されプロキシサーバ２３０に送信される。
【００６４】
[００６６]  プロキシサーバ２３０はユーザＢが到達されてもよい一以上のコンタクトを検索するために位置サーバ２４０に要求を典型的には送信する。前に述べたように、プロキシサーバ２３０はプロファイル制御された特性動作の実行およびユーザＢに関連する最新の知られた位置情報を得るような、各種の目的で位置サーバ２３０を調べる。
【００６５】
[００６７]  位置サーバ２４０は要求を分析し、プロキシサーバ２３０に多くの可能な方法の内の一つで応答する。位置サーバ２４０は、もしユーザＡがユーザＢにコンタクトを許可されなかったときは、もしユーザＢのアドレスが認識されないときまたはもしユーザＢが、ユーザＡによって到着できないようにさせるような活性された特性を有しているのであれば、セッションを否認してもよい。位置サーバ２４０はセッションが確立される前に、ユーザＡはシステムに対して自分自身を認証しなければならないというようにプロキシサーバ２３０に応答してもよい。
【００６６】
[００６８]  位置サーバ２４０は、ユーザＡがユーザＢへのコンタクトを許可すると決定してもよく、またユーザＢが到着されうる多数のアドレスを見出してもよい。この場合においては、位置サーバ２４０はＳＩＰに、試されるべき内容のリストを含む「３００多数選択」メッセージを戻す。
【００６７】
[００６９]  そのような応答を受信したとき、プロキシサーバ２３０は対応する端末２２２の任意のものでユーザＢがうまく到着されうるかどうかということを知るためにコンタクトの試みを開始する。この「ファインドミー」機能性は、最も最近の登録された位置で開始するシーケンスで通常は実行され、または、ユーザＢ（電話それからページャ）のために提供された特定の順に従う。ある設定においては、プロキシサーバ２３０はすべてのコンタクトを平行に試みてもよいと認識される。端末２２２とコンタクトを確立するための試みは端末に対してＳＩＰ「ＩＮＶＩＴＥ」を送信し、成功または失敗を示す返答を待つことを含む。このプロセスは図３にその詳細が記載されている。
【００６８】
[００７０]  図３は、他のプロトコルの使用は可能ではあるが、ＳＩＰプロトコルを使用してセッションを確立するために、各種要素間で生じるメッセージの典型的なシーケンスを示すフローチャートである。この例において、ユーザＡに関連するステーションは「ユーザＡ」として示されている。しかしながら、ユーザＢはファインドミー特性の下では任意の数の装置（またはクライアント）と関連してもよいため、これらの装置は「端末１」、「端末２」、「端末３」と呼ばれる。一般に、任意の数の端末（すなわち宛先クライアント）がユーザＢのファインドミーリストに特定されてもよい、ということに注意のこと。このシナリオにおいては、ユーザＢは結局端末３を介して到着すると仮定される。各端末装置、ユーザＡおよび端末１、２および３はＳＩＰ電話または他の形式の電話であってもよく、企業ゲートウエイまたはネットワークゲートウエイ１０７などを介して接続されてもよい。ユーザＢはそのプロファイルの一部としてファインドミー特性を有し、試みるべき多数のコンタクトを結果として有する。これに基づいて、ＮＳ１は、ユーザＢに到達したいというユーザＡの要求に、まずＩＮＶＩＴＥメッセージを端末１に、それから端末２、それから端末３に対して送信することによって応答し、ここで呼び出しは最終的に完了する。この例において、端末１、２および３はＳＩＰ電話であると仮定される。ある要素から別の要素へ送信されるメッセージの各事例はプロセスまたはシーケンスにおけるステップとして呼ばれる。
【００６９】
[００７１]  ステップ３０１において、ユーザＡがユーザＢに到着したいという意図を示すＳＩＰ「ＩＮＶＩＴＥ」メッセージは、ユーザＡの端末からプロキシＮＳ１へ送信される。ステップ３０３において、プロキシは、任意の要求を受ける前に、ユーザＡの認証を調べるためにＳＩＰ「４０７認証要求」メッセージで応答する。この最初の交換での締め切り(closure)を提供するために、ユーザＡはステップ３０５においてプロキシに対してＳＩＰ通知メッセージを戻す。
【００７０】
[００７２]  ユーザＡはステップ３０７において次にＩＮＶＩＴＥ要求を繰り返すが、今度はステップ３０３の調査に応答して認証ヘッダを含む。ユーザＡの認証が満足であれば、ステップ３０９においてＩＮＶＩＴＥが位置サーバに転送される。位置サーバは要求の検査を始め、ユーザＢがプロファイルを有しているかどうかおよびどのような特性が現在活性化されているのかということを決定する。ところで、「１００試み」仮応答は、ユーザＡ端末に対して種類の呼び出し進行指示器として戻される。このすぐあとで、位置サーバはステップ３１３において、それがユーザＢに対するファインドミーリストを見つけたということを示すＳＩＰ「３００多数選択」メッセージで応答する。この応答はユーザＢとの通信が試みられたコンタクトのリスト、この場合は端末１、２および３であるが、を含む。
【００７１】
[００７３]  プロキシＮＳ１はそれから連続的にコンタクトを試み始める。ステップ３１５において、ＮＳ１は端末１に対してＩＮＶＩＴＥメッセージを送信し、そこで、端末１は、ステップ６１７で「４０４見つからない」メッセージで応答する。これは、ユーザＢが端末１で到着できないことを示す。ＮＳ１は、ステップ３１９において「ＡＣＫ」メッセージを戻すことによって「４０４」メッセージを通知する。この通知がなければ、端末１はその応答が受信されたということを確実にするために、間隔をあけて「４０４」応答を繰り返す。
【００７２】
[００７４]  ステップ３２１において、プロキシＮＳ１はＩＮＶＩＴＥメッセージを送信することによって端末２を介してコンタクトを試みる。ステップ３２３において、端末２は端末がベルを鳴らす（電話）かまたはそうでなければ入来呼び出しの近くにいるユーザに警告するということを呼び出し当事者に知らせる進行指示器として「１８０リンギング」仮応答を送信する。ステップ３２５においてこのリンギングメッセージはプロキシからユーザＡ端末へ渡される。結局、端末２が応答されることなくしばらくベルが鳴らされると、タイムアウトが宣言されてＮＳ１は、端末２がベルを鳴らすのをやめるようにステップ３２７において「キャンセル」メッセージを発行する。
【００７３】
[００７５]  プロキシＮＳ１はそれから端末３を介してユーザＢに到着しようと試み、ＩＮＶＩＴＥメッセージをステップ３２７において端末３に送信する。この新しいコンタクトが開始される間、端末２がステップ３３１において「２００ＯＫ」メッセージを戻すことによって前の「キャンセル」に応答するということが起こる。端末２はそれからステップ３３３において、最近のキャンセルの理解を示すため、「４８７要求はキャンセルされた」メッセージを送信する。プロキシＮＳ１は、端末２に対する呼び出しの試みがキャンセルされたということを確認し、ステップ３３５において、「ＡＣＫ」を送信することによって端末２との処理を終了する。
【００７４】
[００７６]  ステップ３３７において、端末３はステップ３３９においてユーザＡに対して繰り返して戻される「１８０リンギング」応答を送信する。ステップ６４１において、端末３はこの端末において呼び出しが受け入れられたということを示す「２００ＯＫ」メッセージを送信する。「２００ＯＫ」はステップ３４３においてユーザＡ端末にも送信される。実行可能な接続の通知はステップ３４５および３４７において戻される。この点においてユーザＡの端末および端末３は互いにお互いのアドレスを知り、二方向のＲＴＰ媒体接続がユーザＡとユーザＢとの間でネットワークを介して確立されてもよい。
【００７５】
[００７７]  この発明の理解およびその利点の理解を提供するために、図４はこの発明の好ましい実施例に従って、可能にされ、かつ適切に処理された状態を示す。
【００７６】
[００７８]  図４において、ユーザＢを特定するＩＮＶＩＴＥメッセージ４０２は位置サーバによって受信される。多分、要求の他の局面の有効性を確認した後で、位置サーバは要求の時点でのユーザＢに関連する第一のコンタクトリスト４１０を決定する。第一のコンタクトリスト４１０の中には、一以上のコンタクトが位置サーバによってアクセス可能なプロファイルを有する他のアカウントを実際現してもよい。例えば、図４に示されているように、第一のコンタクトリスト４１０のコンタクトＡ２は第二コンタクトリスト４２０を代わりに特定するプロファイルを有してもよい。第一のコンタクトリストはコンタクトのある数を含んでもよく、その各々はコンタクトのさらなるコンタクトリストを特定するプロファイルを有してもよい。この影響は任意の深さまで続いてもよい。非常に多くのコンタクトが単一の問い合わせから続いてもよいということは容易に例示される。これらすべてのコンタクトの計算は位置サーバにとってわずらわしい場合もあり、呼ばれた当事者が試みられた最初のいくつかのコンタクト内で到着されるのであれば、ほとんどは不必要である。この発明は位置サーバにおいてこの負担を減らすことによって拡張性と効率の改良を追求する。
【００７７】
[００７９]  図５は図４に述べられた場合において位置サーバによって戻されてもよい典型的なリダイレクト応答メッセージ５００を示す。便利のために、メッセージ５００は、他のフォーマットも使用されてもよいが、ＳＩＰ「３００多数選択」メッセージにならってパターン化される場合が示される。メッセージ５００は最初のヘッダライン５０２による「多数選択」応答として特定される。メッセージ５００が開始端末からプロキシサーバへ行くときに通る経路はアドレスライン５０４を「経由して」セットにおいて反映される。このＳＩＰの「経由スタック」局面は、プロキシサーバ、位置サーバ、端末および他のセッションを開始するのに含まれる他のＳＩＰと通じている要素間の経路制御メッセージとして役に立つ。呼び出しに関連した他の典型的なヘッダ情報は、ヘッダセクション５０６に提供され、開始端末によって送信される開始ＩＮＶＩＴＥメッセージから通常はコピーされる。コンタクトセクション５０８は、位置サーバがユーザＢのために決定したコンタクトのリストを含む。メッセージ５００に応答して、プロキシサーバはコンタクトセクション５０８を調べ、リスト内の各コンタクトにＩＮＶＩＴＥメッセージの送信を開始する。メッセージ５００は、すべての可能なユーザＢに対するコンタクトは計算され、単一のメッセージで戻されるという状況で表される。
【００７８】
[００８０]  図６はこの発明の好ましい模範的な実施例に従うセッションを確立するための要素間の相互作用を模式的に示す。前のシナリオと同様に、ユーザＡ６１０は、多くの異なるコンタクトの一つに存在しうるユーザＢ６２０とセッションを確立したいと望む。この例において、コンタクト６２２は図４に示された状況と一致している。
【００７９】
[００８１]  ユーザＡは、ユーザＢに到達しようという意思を示すＳＩＰ  ＩＮＶＩＴＥメッセージを組み立てる端末６１２を使用してセッション要求を開始する。メッセージ経路６５０に沿って、端末６１２はＩＮＶＩＴＥメッセージをＳＩＰプロキシサーバ、ネットワークサーバ（ＮＳ）６３０ａに送信する。ユーザＢがどこでコンタクトできるかということに関する情報を得るために、ＮＳ６３０ａは、メッセージ経路６５１によって示されているように位置サーバ（ＬＳ）６４０によって表される位置サーバに対して経路制御要求を送信する。この経路制御要求はＳＩＰ  ＩＮＶＩＴＥメッセージの形態を選択的に有してもよい。経路制御要求の処理の後で、ＬＳ６４０はメッセージ経路６５２に沿ってＮＳ６３０ａに応答する。例示のために、この応答は図７に示されたＳＩＰ「３００多数選択」メッセージと似ているものと仮定する。
【００８０】
[００８２]  簡単に図７に戻って、ＳＩＰメッセージ７００はこの発明の模範的な実施例に従う位置サーバからの応答を表す。ＳＩＰメッセージ７００はヘッダ７０２によって「多数選択」として特定される。前に述べたように、「経由」ヘッダ７０４のセットは、ＮＳ６３０ａおよびＬＳ６４０のようなＳＩＰ要素間でＳＩＰメッセージの経路制御をするために使用される。メッセージ７００のセクション７０６はセッションにおいて含まれるべき呼び出しおよび当事者を特定する情報を含む。
【００８１】
[００８３]  セクション７０２、７０４および７０６は図５に示した従来技術のＳＩＰメッセージに匹敵する。しかしながら、コンタクトセクション７０８は図５のセクション５０８とはっきりと異なる。セクション７０８において、コンタクトリストは呼び出し環境が等価であるとしても、セクション５０８よりずっと短い。さらに、セクション７０８にリストされた各コンタクトはセクション５０８のコンタクト間では見られない追加のパラメータをさらに含む。特に、あるコンタクトは「最終(final)＝イエス」パラメータ７１４を有している。この発明の好ましい実施例に従って、これらはさらなる位置サーバ検査が必要ではないコンタクトアドレスに対応する。言い換えると、これらはさらなるアドレスとなるようなプロファイルを有していない。コンタクトセクション７０８のあるエントリは、状況情報パラメータ７１２への状態と共に「最終＝ノー」パラメータ７１０を有している。好ましい実施例に従えば、このパラメータは、これらのさらなるアドレスはまだ検討されていないが、コンタクトはさらなるコンタクトアドレスを引き出すような対応するプロファイルを有しているかもしれないということを示す。コンタクトリストセクション７０８は、ＬＳ６４０からの最初の応答がなぜコンタクトＡ２が「最終ではない」と示されるのかということを明らかに示すために、図４の状態と比較されてもよい。
【００８２】
[００８４]  どのようにしてＮＳ６３０ａがコンタクトリスト内のこれらのパラメータまたは「フラグ」に対応するのかということを明らかに理解するために、図６の説明をここで要約することが役立つ。ＬＳ６４０からの「多数選択」の受信に応じて、ＮＳ６３０ａはＬＳ６４０によって提供されたコンタクトリストの各コンタクトにメッセージを送るシーケンスを開始する。メッセージ７００において見られるように、最初のコンタクトＡ１はさらなるアドレスの調査は要求されないということを示す「最終＝イエス」パラメータを有している。従って、ＮＳ６３０ａは、コンタクトＡ１に対応する端末６２２に直接、メッセージ経路６５３に沿ってＩＮＶＩＴＥメッセージを単に送信する。この活動はプロキシが宛先に到着しようと試みるときのいつもの方法と似ている。
【００８３】
[００８５]  端末６２２は、ユーザＢがそのコンタクトでははっきりと到達できないということを示す最終応答として「４０４見つからない」メッセージを戻してもよい。代わりに、端末６２２は、端末は呼び出しに答える誰かを要求することを試みているということを示す「１８０リンギング」メッセージのような仮の応答をメッセージ経路６５４に沿って戻してもよい。
【００８４】
[００８６]  もしユーザＢがコンタクトＡ１でうまく到着できれば、端末６２２ａは「２００ＯＫ」メッセージを戻し、そこで、ユーザＡとユーザＢは互いに媒体接続を確立し、セッションは成功裏に開始される。端末Ａ１からの応答メッセージはメッセージ経路６５９に沿って開始端末６１２戻されてもよい。
【００８５】
[００８７]  ユーザＢがコンタクトＡ１で到着されなかったときは、ＮＳ６３０ａはセクション７０８においてリスト化されたコンタクトＡ２に進む。コンタクトＡ２は、コンタクトリスト４２０のような第二のアドレスリストの可能な存在を表す、「最終＝ノー」パラメータ７１０を保持している。この発明の好ましい実施例に従えば、ＮＳ６３０ａは端末コンタクトよりもそれ自身に対してＩＮＶＩＴＥメッセージを送信する。この行為はＮＳ６３０ｂの存在によって図６において示されている。ＮＳ６３０ｂは、サーバの処理環境においてプロキシ処理の異なった事例も存在するようではあるが、実際は、ＮＳ６３０ａと同じプロキシサーバである。ＮＳ６３０ａとＮＳ６３０ｂとを分けて示すことはメッセージ行為を例示するには役に立つ。最終ではないＡ２コンタクトに到着すると、プロキシサーバはメッセージ経路６５５に沿ってそれ自身にＩＮＶＩＴＥメッセージを送信する。このＩＮＶＩＴＥメッセージの例が図８にメッセージ８００として示されている。好ましい実施例に従えば、メッセージ８００の要求−ＵＲＩ部分８０２は、メッセージ７００において見られるＡ２コンタクトリストエントリから直接コピーされた追加の情報を保持する。この追加の情報の重要性は後の説明でより明らかになる。
【００８６】
[００８８]  ＮＳ６３０ａからＩＮＶＩＴＥメッセージを受信すると、ＮＳ６３０ｂはあたかも、新しいＩＮＶＩＴＥメッセージが開始者から受信されたように事例を挙げる(instantiated)。経路６５５に沿った自分にアドレスされたＩＮＶＩＴＥメッセージは他の任意の入来ＩＮＶＩＴＥメッセージのように処理される。従って、ＮＳ６３０ｂは受取人、この場合はコンタクトＡ２であるが、に対するコンタクト情報を求めてＬＳ６４０にメッセージ経路６５６に沿って経路制御要求を送信する。ＬＳ６４０がＢ４を介してコンタクトＢ１を含むコンタクトの長いリストに単一のＡ２コンタクトを「拡張する」のはこのときである。ＬＳ６４０はメッセージ経路６５７に沿ってＮＳ６３０ｂに対する応答の中でこのリストを戻す。ＮＳ６３０ｂはこれらの位置Ｂ１−Ｂ４でユーザＢにコンタクトすることを試みる。例えば、ＮＳ６３０ｂはメッセージ経路６５８に沿って端末Ｂ１に対してＩＮＶＩＴＥメッセージをまず送信する。各コンタクト試みからの応答はメッセージ経路６６０、６６１および６５９を介してプロキシおよび開始者に戻される。この返送メッセージ行為はＳＩＰ機構の一部である。
【００８７】
[００８９]  コンタクトＢ１−Ｂ４のいずれもが成功しなかったときは、ＮＳ６３０ａはアドレスＡ３およびＡ４と継続する。この例においては、ＮＳ６３０ｂはコンタクトＡ２に関連した追加のアドレスを調査するためだけに関わっている。コンタクトＡ１、Ａ３およびＡ４は、ＮＳ６３０ｂの生成または利用なしに、通常の方法でＮＳ６３０ａによって直接単に実行される。
【００８８】
[００９０]  このシナリオにおいては、もしユーザＢがコンタクトＡ１で成功裏に到達するとすれば、続くすべての活動は未然に防がれ、それによってＬＳ６４０への負担が減らされる。
【００８９】
１）コンタクトＡ２のプロファイルに基づくコンタクトＢ１−Ｂ４のアドレス検査
２）Ａ２プロファイルに関連した他の特性の行使
３）第二ＮＳ６３０ｂの使用
４）経路６５５、６５６、６５７、６６１に沿ったメッセージ
[００９１]  示された例のシナリオにおいては、経路６５１および６５２に沿ったアドレスの開始セットの検索は、模範的な実施例に従って正確に一度実行され、メッセージ７００のコンタクトリストがＮＳ６３０ａに返送される結果となる（ＮＳおよびＬＳ間の他の準備的メッセージは例えば、ユーザＡの認証中に生じてもよい）。
【００９０】
[００９２]  示された例のシナリオにおいては、経路６５５、６５６および６５７に沿ったメッセージ送信は、コンタクトＡ１が不成功であったということがわかった後でのみ、ただ一度だけ行われ、ＮＳ６３０ｂへＢ１−Ｂ４コンタクトのリストが返送される結果となる。ＮＳ６３０ｂは４つのコンタクトＢ１−Ｂ４の各々に対してＩＮＶＩＴＥを送信する。
【００９１】
[００９３]  特定のシナリオを超えた部分を一般化するために、ＮＳ６３０ｂによって表された「自分自身に対するメッセージ」およびメッセージ経路６５５、６５４、６５７および６６９はメッセージ経路６５２に沿って戻されたリダイレクト応答における各最終ではないコンタクトに対して一度繰り返される。
【００９２】
[００９４]  さらに、コンタクトＢ１−Ｂ４のような、一以上の第二層コンタクトはさらなるアドレスを生じるプロファイルをまた有してもよい。もしこれが生じたときは、ネスティングの追加のレベルが発生し、プロキシサーバはそれ自身に再びＩＮＶＩＴＥメッセージを送信する。図６からわかるように、これは第二ＮＳ６３０ｂから第三ＮＳ受信ＩＮＶＩＴＥメッセージのインスタンス作成(instatiation)を意味する。
【００９３】
[００９５]  上記プロセスの理解を強化すると共に、これまで述べてきた状況情報パラメータがどのように技術の効率性および信頼性を強化するのかということを述べるためのさらなる説明を行う。説明は位置サーバおよびネットワークサーバによって実行されるプロセスに焦点が当てられる。
【００９４】
[００９６]  図９Ａ−Ｂは位置サーバが入来経路制御要求を処理するプロセス９００を述べたフローチャートである。メッセージの別の形式の処理のような他の処理は位置サーバにおいて行われるが、この発明の理解のためには重要ではない。ＳＩＰメッセージの別のタイプの処理は当業者にとって十分理解されるため、明確さおよび簡潔さのためにここでは除外する。
【００９５】
[００９７]  プロセス９００が入来経路制御要求の受信に応じてステップ９０２で開始される。それからステップ９０４において、ＩＮＶＩＴＥメッセージの要求−ＵＲＩ部のような、コンタクト部分が図８のパラメータ８０４と同様の「最終＝ノー」パラメータを保持しているかどうかを判定する。もし保持していなければ、経路制御要求は元の要求として処理され、プロセスはステップ９０８へ進んでその要求および開始者をさらに分析する。ステップ９０８は開始者および意図された宛先に関するデータベースからの情報の検索を含んでもよい。そのような状況情報は、例えば、開始および宛先アドレスが適切な状況にあると解釈されるように、ダイアルプラン識別子を含んでもよい。
【００９６】
[００９８]  ダイアルプランＩＤはそれ自身のダイアルプランのＶＰＮを有する特定の企業顧客の機能である。ダイアルプランＩＤは多数のＶＰＮが共存し、システム１００において十分差別化されるということを確実にする。例えば、開始者が会社Ａに属する私的ネットワークにおいて内線「２６６５２０５」をダイアルすると、たとえ同じシステム１００を共有する会社Ｂがその私的番号プランの中に「２６６５２０５」位置をまた有していたとしても、会社Ａ内の意図した宛先に到着すべきである。
【００９７】
[００９９]  状況情報の別の例は、例えば、公衆電話番号、私的ダイアルプラン番号およびＩＰアドレス間で区別するために使用される「アドレスの性質」であってもよい。状況情報のさらに別の例は、地理的または論理的区分であってもよい、位置識別子であり、例えば、ダイアルプランプリフィックスに対応してもよい。
【００９８】
[０１００]  一般的に、状況情報は開始者、宛先または要求の適切な処理を確実にするために位置サーバによって検査されるかまたはそうでなければ判定されなければならないセッション要求についての任意の情報であってもよい。この状況情報は要素の各種および複数を含んでもよいが、ここでは「状況情報＝」という標記で要約される。
【００９９】
[０１０１]  「最終＝イエス」パラメータは位置サーバによっては決して受信されるべきではない。「最終＝イエス」パラメータを検出すると、ＮＳは位置サーバに再問い合わせをやめるべきである。それにもかかわらず、もしそのような経路制御要求が受信されたなら、ＬＳは経路制御要求において提供された同じ要求されたコンタクトを含む単一のコンタクトを付けてＳＩＰ「３０２一時的移動」メッセージに匹敵する応答を単に返送してもよい。
【０１００】
[０１０２]  ステップ９０８において追加の状況情報が得られた後で、プロセスはステップ９１０で開始者の要求が有効であるかどうかの判定を継続する。この判定は、開始者が宛先にコンタクトすることを許可されているかどうか、開始者が認証されているかどうか、および宛先が位置サーバによって認識されているかどうかといった要因に基づいてもよい。
【０１０１】
[０１０３]  ステップ９１０で要求が有効にできなかったときは、ステップ９０９である形式の拒否メッセージがステップ９０９においてネットワークサービスに戻され、ＬＳ処理がステップ９１６で終了する。
【０１０２】
そうでなければ、もしステップ９１０で、セッション要求が有効であるとわかったときは、プロセスは宛先当事者が到着されてもよいコンタクトの検索を始めるためにステップ９１２で継続を行う。
【０１０３】
[０１０４]  ステップ９１２の処理およびそれから先を述べる前に、経路制御情報要求付きの状況情報を渡すことによって得られたかなりの効率に関連しているため、ステップ９０６の役割を述べるのが重要である。
【０１０４】
[０１０５]  判定ステップ９０４に戻って、経路制御要求の要求−ＵＲＩが「最終＝ノー」パラメータを有していると判定されたときは、これは経路制御要求が前の開始要求から派生した次の要求であるということを意味する。「最終＝ノー」パラメータの存在はＮＳ６３０ｂが図６において経路６５６に沿って送信した形式の入来メッセージを示す。
【０１０５】
[０１０６]  ルーティング要求のこの側面を認識すると、位置サーバはステップ９０８および９１０を飛ばして、代わりにメッセージ自身から必要な状況情報を検索するためにステップ９０６を実行する。状況情報を得、開始者の要求を有効にするステップが開始および経路制御要求の処理において実行されているという点を考慮すると、次の要求のためにこれらのステップを位置サーバが繰り返す必要はない。それゆえ、ひとたび得られると、状況情報はＮＳおよびＬＳとの間でメッセージに付加される。
【０１０６】
[０１０７]  前に導入されていたメッセージ７００は経路情報要求に応答してＬＳによって提供される状況情報パラメータ７１２を示す。メッセージ８００はこの情報がどのようにして状況情報パラメータ８０４として位置サーバに戻されるのかということを示す。次の要求に対して、これは位置サーバが、最初のものが状況情報を提供したステップの繰り返しをしないようにする。これはまた位置サーバが、ＮＳ６３０ａからの開始経路制御要求のときとＮＳ６３０ｂからの次の経路制御要求との間の任意の状態情報を維持することを省く。各コンタクトにおけるリンギング時間のために、たとえ対応する開始要求よりも数秒または一分間後であっても、続く経路制御要求は提示されてもよい。
【０１０７】
[０１０８]  先に述べたように、次の要求は自己完結的であり、位置サーバにおいて持続性を必要としないという事実のために、負荷のバランスおよびファイルオーバ(failover)という点で多くの利点がある。どの位置サーバもネットワークサーバから任意の開始または続く要求を処理することができる。このように、図９Ａにおいて、ステップ９０６はステップ９０８および９１０を飛ばすことに関係し、その代わりにメッセージヘッダから直接先に派生した状況情報の値を直接読むことに関係する。
【０１０８】
[０１０９]  ステップ９１２は、状況情報がステップ９０８および９１０によって得られるかまたはステップ９０６で検索されたときに次に実行される。ステップ９１２においてＩＮＶＩＴＥメッセージの要求−ＵＲＩのような、経路要求において特定された宛先がプロファイルを有するかどうかが判定される。このプロファイルは先に述べたようにＯＳＳを介して供給される。このプロファイルは入来呼び出しの処理に影響を与える各種情報を含んでもよい。例えば、プロファイルはファインドミーリスト、呼び出し遮断または呼び出し転送情報および時間帯および曜日によって可変のコンタクト情報を含んでもよい。プロファイルは、宛先ユーザが最近存在すると指示された一時的に登録されたコンタクトを含んでもよい。
【０１０９】
[０１１０]  もしそのようなプロファイルがステップ９１４で見つからなかったときは、ＳＩＰ「３０２」メッセージのような応答は、宛先として決定された単一のコンタクトを示す、経路制御要求を送信するプロキシサーバに戻される。
【０１１０】
[０１１１]  ある場合においては、もし宛先に対するコンタクトが従来の電話番号であれば、ＮＳが向け直されるべき図１のネットワークゲートウエイ１０７のような、ゲートウエイを特定するための追加のステップが行われてもよい。プロキシに戻されたメッセージは、ゲートウエイのアドレスを含む。ステップ９１４においてＮＳに応答した後で、ＬＳはステップ９０２で受信した経路制御要求を処理し、プロセスはステップ９１６で終了する。
【０１１１】
[０１１２]  ステップ９１２において、もしプロファイルが宛先のために見つけられたときは、ステップ９１８が、妥当な場合、ファインドミーリストの行使を含む、プロファイルによって示された任意の特性処理を適用するために実行される。ステップ９１８の結果はコンタクトリストの形にしばしばなる。特に、もし宛先プロファイルに従う特性処理が開始者の呼び出し試みを遮断することを特定していれば、ステップ９１８はコンタクトを生じない可能性がある。
【０１１２】
[０１１３]  プロセス９００はそれから、ステップ９２０で図９Ｂに続く。ステップ９１８の実行によって提供されるコンタクトがなければ、それからステップ９２４が実行され、プロキシにＳＩＰ「４０３」メッセージまたは同様のものを返送する。処理はそれから９４０において終了する。
【０１１３】
[０１１４]  そうでなければ、ステップ９２０においてもし特性およびプロファイル処理によってコンタクトが生成されるのであれば、ＳＩＰ「３ＸＸ」メッセージのような、リダイレクト応答がステップ９２６で生成される。そのようなＳＩＰ３００シリーズ応答を構成する一般的な方法がＳＩＰにおいてよく知られており、ＩＥＴＦドキュメントＲＦＣ２５４３に記載されている。この点における応答は、図７のセクション７０２、７０４および７０６に似ていてもよい。
【０１１４】
[０１１５]  次に、リダイレクト応答に対して一以上のコンタクトを付加するためにステップ９２８から９３６が実行される。ステップ９２８がコンタクトの一つを選択することを含む。ステップ９３０は、コンタクトがプロファイルを有する形式のものであるかどうかを判定するために実行される。もしそうであれば、それからステップ９３２が実行され、以前述べたような状況情報と共にコンタクトに対して付加された「最終＝ノー」パラメータが実行される。そうでなければ、もし、ステップ９３０でコンタクトがプロファイルをもてない形式であれば、ステップ９３３において、コンタクト情報のテキストに対して「最終＝イエス」パラメータのみが、追加される。「最終＝イエス」パラメータに対して適切であるようなコンタクト形式の例は登録されたアドレスであり、そこでは、宛先当事者は特定の端末装置で存在するとして一時的に登録される。この場合、当事者は単なる「訪問者」ユーザであるため、例えあるとしても、端末の通常ユーザのプロファイルを実行するのは不適切であろう。
【０１１５】
[０１１６]  ステップ９３２またはステップ９３３が実行されるかどうかによって、ステップ９３４はリダイレクト応答のコンタクトリストに対して選択されたコンタクトを追加するために次に実行される。ステップ９３６は処理されるべきより多くのコンタクトがあるかどうかを判定するために実行される。もしそうであれば、実行はステップ９１８において決定されたすべてのコンタクトに対してステップ９３０から９３４を繰り返すためにステップ９２８に戻る。すべてのコンタクトがそのように処理された後で、実行は、リダイレクト応答がステップ９０２において経路制御要求を送信するプロキシに戻るようステップ９３８に進み、処理はステップ９４０で終了する。
【０１１６】
[０１１７]  プロセス９００を補完するために、図１０はプロキシサーバがＩＮＶＩＴＥメッセージを処理し、位置サーバと相互作用するプロセス１０００を述べる。プロセス１０００は、例えば、開始端末からＩＮＶＩＴＥメッセージの受信に応じてステップ１００２で始まる。それからステップ１００４においてプロキシは位置サーバに対して対応するルーティング要求を送信し、応答を待つ。応答を受信すると、ステップ１００６が応答がＳＩＰ３００シリーズの応答のような、位置サーバからのコンタクトアドレスの返送を示すリダイレクト応答であるかどうかを判定するために実行される。そうでなければ、それからステップ１００８でリダイレクト形式ではないメッセージを処理するための他のプロセスが実行され、それからプロセスはステップ１０２６で終了する。ステップ１００８は無数の他の可能なメッセージ形式のプロセスを要約するが、その詳細は比較的よく知られており、この発明の説明に対しては重要ではない。
【０１１７】
[０１１８]  ステップ１００６において、もしＬＳからの応答がコンタクトアドレスを有するリダイレクト応答であると判定されると、プロセスはメッセージにおいて戻されたコンタクトの一つを選択するためにステップ１０１０に移動する。それからステップ１０１２において、選択されたコンタクトが「最終＝ノー」パラメータがコンタクトアドレスに表れるかどうかを判定するために検査される。もしそうであれば、次にステップ１０１６が実行され、そこでＩＮＶＩＴＥメッセージがプロキシサービス自身に送信される。このメッセージは、最終フラグおよび任意の状況情報を含む要求されたコンタクト（ＩＮＶＩＴＥメッセージの要求−ＵＲＩのような）、としてリダイレクト応答においてコンタクトラインを使用する。そうでなければ、ステップ１０１２において「最終＝ノー」フラグが見つからなかったときは、プロキシは、通常のようにＩＮＶＩＴＥメッセージを単に送信し、ステップ１０２０において応答を待つ。
【０１１８】
[０１１９]  コンタクトからの待ちおよび応答処理のステップ１０２０は、一時的な応答および最終応答の両方を処理することを含んでもよい。例えば、コンタクトはネットワークサーバおよび開始端末に対して戻るよう手渡されるＳＩＰ「１８０リンギング」一時的メッセージを送信してもよい。コンタクトは意図された当事者に到着するためにコンタクトの成功または失敗のいずれかを示す最終応答を代わりまたは次に送信してもよい。ステップ１０２０は受信されてもよいすべての各種の応答を含むことが意図されている。ステップ１０２０はセッション開始技術において当業者によく知られているかまたは容易に想像される方法で各種の可能な応答を適切に処理することを含む。
【０１１９】
[０１２０]  ステップ１０２２において、ステップ１０１０において選択されたコンタクトを使用してセッションがうまく確立されるかどうかを判定する。もしそうであれば、さらなるコンタクトは試みられる必要はなく、プロセスはステップ１０２６で終了する。そうでなければ、もしコンタクトの試みがセッションの確立にならなかったときは、ステップ１０２４が実行され、より多くのコンタクトを試みるかどうかを判定する。そうであれば、プロセスはステップ１０１０へ進み、次の利用可能なコンタクトを選択する。そうでなければ、それ以上のコンタクトが利用で可能でなければ、ステップ１００２で受信したＩＮＶＩＴＥメッセージのプロセスはステップ１０２６で終了する。
【０１２０】
[０１２１]  ネットワークサーバおよび位置サーバのネット相互作用を要約するために、図１１はこの発明の実施例に従うセッションを確立するための繰り返し問い合わせを実行するための全体の処理１１００のフローチャートである。図１１のプロセスは、位置サーバが一度にすべてのコンタクトを提供するというよりは、必要に応じてコンタクトのサブセットを提供してもよいという現在の教示を一般化している。コンタクトのサブセットはここに例として示されているかまたはコンタクトの上位集合の何らかの他の任意の分割を通した繰り返しによって示されているように、ネスト化されたコンタクトの繰り返しから派生してもよい。当業者はサブセットの多くの可能な配置が選択されうるということがわかるであろう。当業者はプロキシと位置サーバとの間で手渡される状況情報は、検索のために位置サーバが、コンタクトの次のバッチを選択するのをまた助けてもよい。例えば、状況情報は、プロキシのためのコンタクトの次のグループを取りに行くために位置サーバに対してインデックスとして使えるように、シーケンス番号または「試みられた最後のコンタクト」を含んでもよい。
【０１２１】
[０１２２]  プロセス１１００は、ユーザが端末にアクセスして別の当事者に到着するためにセッション要求を開始したとき、ステップ１１０２において始まる。ステップ１１０４に移動して、開始端末はＳＩＰ  ＩＮＶＩＴＥメッセージのようなセッション要求をネットワークサーバまたはプロキシに送信する。ステップ１１０６において、プロキシは位置サーバに対して対応する経路制御要求を送信する。ステップ１１０８において、位置サーバは要求を検査し、ユーザプロファイル、特性および他の要因に基づいて、宛先当事者が到着するコンタクトアドレスのリストを編集する。この発明の好ましい実施例に従えば、位置サーバは、さらなるコンタクトを検索するために、続く位置サーバの再問い合わせを、それらが必要であるときにすることができるように、十分な状況情報と共にコンタクトのサブセットを提供してもよい。
【０１２２】
[０１２３]  ステップ１１１０において、位置サーバはコンタクトのセットをプロキシに上記した状況情報と共に戻す。ステップ１１１２において、プロキシはステップ１１１０において提供されたコンタクトのリストを使用して宛先当事者に到着するよう試みる。ステップ１１１４において、ＳＩＰ「２００ＯＫ」メッセージの返送によって証明されるように、何らかのコンタクトが宛先当事者にうまく到着したかどうかが判定される。もしそうであれば、プロセスはステップ１１２０に続き、そこで開始端末と成功したコンタクトとの間で媒体セッションが確立し、プロセス１０００がステップ１１２０で終了する。
【０１２３】
[０１２４]  ステップ１１１４に戻って、そうでなければ、これまで提供されてきたコンタクトのいずれもが意図された当事者にうまく到着しなかったと判定されると、プロキシは再びさらなるコンタクトアドレスのセットを得るために位置サーバを調べる。ステップ１１１７において、多分位置サーバによって、すべてのコンタクトが使い果たされたと判定されたときは、ステップ１１２２において現時点においてセッションは確立できなかったと宣言する。この状態は、例えば、宛先が到着できなかったという開始当事者への指示によって処理されてもよい。ステップ１１２２において如何なるアクションも適切であるとした後で、プロセス１１００はステップ１１２０において終了する。
【０１２４】
[０１２５]  ステップ１１１７に戻って、プロキシサーバに対して与えられなかった位置サーバに知られたより多くのコンタクトが存在するのであれば、ステップ１１１８において、位置サーバは試みるべきさらなるコンタクトアドレスのセットを決定する。そうするときに、位置サーバは、冗長な努力を多分避けるためまたはどのアドレスのセットとを次に戻すべきであるのかということを判定するのを助けるための要求を提供された状況情報を使用してもよい。
【０１２５】
[０１２６]  プロセスはそれから１１１０に戻って、そこで、位置サーバはさらなるコンタクトのリストでもって応答する。ステップ１１１０から１１１８のプロセスは宛先当事者が到着されるかまたは成功することなくすべてのコンタクトが試みられるかのいずれかまで続けられる。
【０１２６】
[０１２７]  図１２はこの発明に従う実施例が実行されるコンピュータシステム１２００を例示する。コンピュータシステム１２００はバス１２０１または他の通信情報のための通信機構と情報を処理するためのバス１２０１に接続されたプロセッサ１２３０とを含む。コンピュータシステム１２００は、プロセッサ１２０３によって実行される情報および命令を格納するためのバス１２０１に接続された、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミックなストレージ装置をまた含む。メインメモリ１２０５はプロセッサ１２０３によって実行される命令の実行の間に一時的な変数または他の中間情報を格納するために使用されうる。コンピュータシステム１２００はさらに、プロセッサ１２０３のための静的な情報および命令を格納するためのバス１２０１に接続されたリードオンリメモリ（ＲＯＭ）１２０７または他の静的ストレージ装置をさらに含む。磁気ディスクまたは光ディスクのようなストレージ装置１２０９は情報および命令を格納するためにバス１２０１に付加的に接続されている。
【０１２７】
[０１２８]  コンピュータシステム１２００はコンピュータユーザに対して情報を表示するための、カソードレイチューブ（ＣＲＴ）、液晶表示、アクティブマトリックスディスプレイ、またはプラズマディスプレイのような、ディスプレイ１２１１にバス１２０１を介して接続されてもよい。英数字および他のキーを含むキーボードのような入力装置１２１３がプロセッサ１２０３に通信情報および命令選択のためにバス１２０１に接続される。ユーザ入力装置の他の形式は、プロセッサ１２０３に対して方向情報およびコマンド選択を通信するためおよびディスプレイ１２１１上でカーソルの移動を制御するための、マウス、トラックボードまたはカーソル方向キーのようなカーソル制御１２１５である。
【０１２８】
[０１２９]  発明のある実施例に従えば、ＳＩＰサーバ機能（特に図９に示されたような繰り返し問い合わせ能力）が、プロセッサ１２０３がメインメモリ１２０５に含まれた命令の配置を実行するのに応答してコンピュータシステム１２００によって提供される。このような命令はストレージ装置１２０９のような別のコンピュータ読み出し可能媒体からメインメモリ１２０５に読み込まれうる。メインメモリ１２０５に含まれた命令の配置を実行すると、プロセッサ１２０３がここに述べられた処理ステップを実行する。マルチ処理配置における一以上のプロセッサがメインメモリ１２０５に含まれた命令を実行するために採用されてもよい。代わりの実施例においては、配線で接続された回路がこの発明の実施例を実行するためにソフトウエア命令の代わりにまたソフトウエア命令と組み合わせて使用されてもよい。このように、この発明の実施例はハードウエア回路とソフトウエアの任意の特定の組み合わせに限定されない。
【０１２９】
[０１３０]  コンピュータシステム１２００はバス１２０１に接続された通信インターフェイス１２１７をまた含む。通信インターフェイス１２１７はローカルネットワーク１２１１に接続されたネットワークリンク１２１９に接続された二方向のデータ通信を提供する。例えば、通信インターフェイス１２１７はデジタルサブスクライバライン（ＤＳＬ）カードまたはモデム、相互デジタル通信網（ＩＳＤＮ）カード、ケーブルモデムまたは電話モデムのような電話線の対応する形式にデータ通信接続を提供するものであればよい。別の例として、通信インターフェイス１２１７はローカルエリアネットワーク（ＬＡＮ）カード（例えばイーサネットＴＭまたは同期転送モード（ＡＴＭ）ネットワーク）のような互換性のあるＬＡＮにデータ通信接続を提供するものであってもよい。無線リンクもまた実施される。そのような任意の実施において、通信インターフェイス１２１７は各種形式の情報を表すデジタルデータストリームを搬送する電気、電磁気または光信号を送信および受信する。さらに、通信インターフェイス１２１７は、ユニバーサルシリアルバス（ＵＳＢ）インターフェイス、ＰＣＭＣＩＡ（パーソナルコンピュータメモリカード国際協会）インターフェイスなどのような周辺インターフェイス装置を含みうる。単一の通信インターフェイス１２１７のみが示されているが、異なるネットワークおよび装置と通信するために多数の通信インターフェイスが採用されてもよい。
【０１３０】
[０１３１]  ネットワークリンク１２１９は一以上のネットワークを介して、他のデータ装置にデータ通信を典型的に提供する。例えば、ネットワークリンク１２１９はローカルネットワーク１２２１を介してホストコンピュータ１２２３へ接続を提供し、ホストコンピュータ１２２３はネットワーク１２２５（例えば、ワイドエリアネットワーク（ＷＡＮ）または現在一般的に「インターネット」として呼ばれている国際的なパケットデータ通信ネットワーク）またはサービスプロバイダによって作動されるデータ装置に接続される。ローカルネットワーク１２２１およびネットワーク１２２５は共に情報および命令を伝達するために電気、電磁気または光信号を使用する。各種ネットワークを介した信号および、コンピュータシステム１２００とデジタルデータを通信する、ネットワークリンク１２１９上、および通信インターフェイス１２１７を介した信号は、情報および命令を保持する搬送波の模範的な形態である。
【０１３１】
[０１３２]  コンピュータシステム１２００はネットワーク、ネットワークリンク１２１９および通信インターフェイス１２１７を介してプログラムコードを含むメッセージを送信およびデータを受信することができる。インターネットの例においては、（図示のない）サーバはネットワーク１２２５、ローカルネットワーク１２２１および通信インターフェイス１２１７を介してこの発明の実施例を実行するためのアプリケーションプログラムに属する要求されたコードを送信してもよい。プロセッサ１２０３は、受信中および／またはストレージ装置１２０９にコードを格納し、または後の実行のために不揮発性のストレージに格納しながら送信されたコードを実行してもよい。このように、コンピュータシステム１２００は搬送波の形態でアプリケーションコードを得てもよい。
【０１３２】
[０１３３]  ここで使用されている「コンピュータ読み出し可能媒体」という文言はプロセッサ１２０３が実行するための命令を提供することができる任意の媒体を言う。そのような媒体は、不揮発性媒体、揮発性媒体、送信媒体を含む任意の形態を取りうるが、これに限られるものではない。不揮発性媒体は、例えば、ストレージ装置１２０９のような光または磁気ディスクを含む。揮発媒体はメインメモリ１２０５のようなダイナミックメモリを含む。送信媒体は、バス１２０１を含むワイヤを含む、同軸ケーブル、導線およびファイバを含む。送信媒体は音、光、または無線周波数（ＲＦ）および赤外線（ＩＲ）データ通信の間に発生されるような、音の、光のまたは電磁波の形態を取りうる。コンピュータ読み出し可能媒体の一般の形態は、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープおよび任意の他の磁気媒体、ＣＤ−ＲＯＭ、ＣＤＲＷ、ＤＶＤ、任意の他の光媒体、パンチカード、紙テープ、光学読み取りマークシート、穴のパターンまたは他の光学的に認識可能な標識を有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、搬送波、またはコンピュータが読むことができる任意の他の媒体を含む。
【０１３３】
[０１３４]  コンピュータ呼び出し可能媒体の各種形態がプロセッサが実行するための命令を提供するために含まれてもよい。例えば、この発明の少なくとも１部を実行するための命令は遠隔のコンピュータの磁気ディスク上に最初は担持されてもよい。そのようなシナリオにおいては、ローカルのコンピュータはメインメモリに命令をロードし、命令をモデムを使って電話線を介して送信する。遠隔コンピュータシステムのモデムは電話線上でデータを受信し、データを赤外線信号に変換するために赤外線送信機を使用し、赤外線信号をパーソナルデジタルアシスタンス（ＰＤＡ）およびラップトップのような携帯コンピュータ装置へ送信する。携帯コンピュータ装置の赤外線検出器は赤外線信号によって担持された情報および命令を受信し、データをバスの上に置く。バスはデータをメインメモリに搬送し、そこからプロセッサが検索して命令を実行する。メインメモリによって受信された命令はプロセッサによって実行される前かまたは実行された後のいずれかにおいてストレージ装置に選択的に格納されてもよい。
【０１３４】
[０１３５]  この発明が多くの実施例および具体例と共に述べられてきたが、この発明は添付のクレームの範囲内にある、各種自明な修正および均等な配置に限られるものではないが、それらを含む。
【参考文献】
【０１３５】
[１]  ハンドレイ他、「ＳＩＰ：セッション開始プロトコル」、ＩＥＴＦ  ＲＦＣ２５４３、１９９９.
[２]  ハンドレイ他、「ＲＦＣ２５４３の２」、ＩＥＴＦインターネットドラフト、進化における作業
[３]  スパークス，Ｒ、「ＳＩＰ呼び出し制御：参照」ＩＥＴＦインターネットドラフト、進化における作業
[４]  ジョンストン他、「ＳＩＰテレフォニ呼び出しフロー例」、ＩＥＴＦインターネットドラフト、進化における作業
[５]  ジョンストン他、「ＳＩＰサービス例」、ＩＥＴＦ１２７−ドラフト、進化における作業
【図面の簡単な説明】
【０１３６】
[００３４]  この発明は添付の図面の図において限定としてではなくて例として例示され、図において、同様の参照番号が同様の要素を表す。
【図１】この発明の模範的な実施例に従う音声サービスをサポートすることができるデータ通信システムの図である。
【図２】この発明の模範的な実施例に従う当事者間でセッションを確立するときに含まれる機能要素の図である。
【図３】宛先当事者が多数のコンタクトを有するかもしれないときに、セッションを確立するためにどのようにメッセージが典型的に発生するのかということを述べるフローチャートである。
【図４】宛先当事者に対するコンタクトのネスティングの例を示す図である。
【図５】先行技術に従う典型的なＳＩＰ多重選択メッセージの図である。
【図６】この発明の好ましい模範的な実施例に従うセッション開始時に含まれる機能要素のブロック図である。
【図７】この発明の好ましい実施例に従うＳＩＰ多重選択メッセージの図である。
【図８】この発明の好ましい模範的な実施例に従うＳＩＰ  ＩＮＶＩＴＥメッセージの図である。
【図９Ａ】この発明の好ましい模範的な実施例に従う位置サーバによって実行されるセッション要求を処理するためのプロセスのフローチャートである。
【図９Ｂ】この発明の好ましい模範的な実施例に従う位置サーバによって実行されるセッション要求を処理するためのプロセスのフローチャートである。
【図１０】この発明の好ましい模範的な実施例に従うプロキシサーバによって実行されるセッション要求を処理するためのプロセスを示すフローチャートである。
【図１１】この発明の好ましい模範的な実施例に従うサブセットにおける多数のコンタクトを得かつ試みるための通信システムにおけるプロセスを示すフローチャートである。
【図１２】この発明の実施例を実行するために使用されうるコンピュータシステムの図である。
【図１】
2005505948.tif 000003
【図２】
2005505948.tif 000004
【図３】
2005505948.tif 000005
【図４】
2005505948.tif 000006
【図６】
2005505948.tif 000007
【図９Ａ】
2005505948.tif 000008
【図９Ｂ】
2005505948.tif 000009
【図１０】
2005505948.tif 000010
【図１１】
2005505948.tif 000011
【図１２】
2005505948.tif 000012
【国際公開パンフレット】
2005505948.tif 000013
2005505948.tif 000014
2005505948.tif 000015
2005505948.tif 000016
2005505948.tif 000017
2005505948.tif 000018
2005505948.tif 000019
2005505948.tif 000020
2005505948.tif 000021
2005505948.tif 000022
2005505948.tif 000023
2005505948.tif 000024
2005505948.tif 000025
2005505948.tif 000026
2005505948.tif 000027
2005505948.tif 000028
2005505948.tif 000029
2005505948.tif 000030
2005505948.tif 000031
2005505948.tif 000032
2005505948.tif 000033
2005505948.tif 000034
2005505948.tif 000035
2005505948.tif 000036
2005505948.tif 000037
2005505948.tif 000038
2005505948.tif 000039
2005505948.tif 000040
2005505948.tif 000041
2005505948.tif 000042
2005505948.tif 000043
2005505948.tif 000044
2005505948.tif 000045
2005505948.tif 000046
2005505948.tif 000047
2005505948.tif 000048
2005505948.tif 000049
2005505948.tif 000050
2005505948.tif 000051
2005505948.tif 000052
2005505948.tif 000053
2005505948.tif 000054
2005505948.tif 000055
2005505948.tif 000056
2005505948.tif 000057
2005505948.tif 000058
2005505948.tif 000059
2005505948.tif 000060
2005505948.tif 000061
2005505948.tif 000062
2005505948.tif 000063
2005505948.tif 000064
2005505948.tif 000065
2005505948.tif 000066
2005505948.tif 000067
2005505948.tif 000068
2005505948.tif 000069
2005505948.tif 000070
2005505948.tif 000071
【国際調査報告】
2005505948.tif 000072