企業外の電話を企業内のユーザに関連付けるネットワーク・フレームワーク
【課題】 外部ＩＤと企業内ＩＤの関連づけを容易にする方法を提供する。
【解決手段】本発明の方法は、（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、を有する。前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む。
【解決手段】本発明の方法は、（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、を有する。前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信に関し、特に、ネットワークの境界にまたがってユーザをマッピングする技術に関する。
【背景技術】
【０００２】
ＳＩＰは、オープンなシグナリング・プロトコルであり、あらゆる種類のリアルタイムの通信セッションを確立する。ＳＩＰを用いて確立される通信セッションの一例は、音声、画像、インスタント・メッセージングを含む。これ等の通信セッションは、あらゆる種類の通信機器上で実行される。通信機器の一例としては、パソコン、ラップトップコンピュータ、パーソナルデジタルアシスタントである。ＳＩＰのキーの１つとなる特徴は、エンドユーザのＡＯＲ（Address of Record ）を全ての通信の１個の統合したパブリック・アドレスとして用いることができる点である。かくして、ＳＩＰを利用した通信の世界に於いては、ユーザのＡＯＲは、ユーザの唯一無二の（即ち単一の）アドレスとなり、ユーザを、ユーザに関連する通信機器の全てに関連付けている。このＡＯＲを用いると、発呼者は、ユーザ（被呼者）の通信機器の内の何れか１つ（ユーザ・エージェントと称する）に達することができ、これは唯一無二のデバイスのアドレス或いは電話番号のそれぞれを知らなくても、行うことができる。
【０００３】
しかし、問題がある。あるネットワーク内のユーザのＩＤは、別のネットワーク内では使用できない。例えば、ユーザは、企業内ネットワークで使用される企業内ＩＤを有し、（１）前記ユーザを特定する、（２）前記ユーザの通信プリファレンスを特定する、（３）通信サービスを、その通信プリファレンスに従って、前記ユーザに拡張する。ところが、ユーザが、自分の企業内ＩＤで、企業内デバイスを介してネットワークにアクセスしない場合には、ネットワークは、そのユーザを適正に特定することができず、所望の通信フューチャをユーザに与えることができない。この為、ユーザにはフラストレーションが溜まる。特に、ユーザが職場から離れて働いており、企業内通信サービスにアクセスしたくても直ぐにはできない場合がある。
【０００４】
"Mobile twinning"あるいは"Extension to Cellular（ＥＣ）" は、企業内のコール・コントローラにより提供される生産性向上のフューチャ（以下「特徴」とも称する）の１つである。この特徴により、外部電話（携帯と家庭用）は、職場の電話番号と対にされる（即ち、関連づけられる）。現在、企業内の特徴は、対になった外部電話にまで延長されるが、これは、外部電話番号（ＰＢＸ外の電話番号）と、企業内の電話番号とを緩く結合することにより行われている。この特徴の実行は、１つのコール・コントローラが、その特徴の唯一のコントローラであり、他のアプリケーションは、それに関係させる必要がないという前提に基づいている。アプリケーション・コントロールが、複数のアプリケーション・サーバ全体に分配されているようなアーキテクチャにおいて、通信インフラは、順番に複数のアプリケーションを起動して、１つのセッション・リクエスト上で動かす。しかし、これらのアプリケーションが、関連が分かるように修正されていない場合には、これらのアプリケーションは、正しい特徴のロジックを起動できない、即ち所望のサービスを提供できない。それ故に、既存のソリューション（１つのアプリケーションが、企業内のユーザの内部電話番号と外部電話番号との間の関連性をサポートし、他のアプリケーションはその関連性が分かっていない）では、分散したアプリケーション・アーキテクチャでは十分には機能しない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Avayaや他のＰＢＸベンダーは、この種の問題を解決するために、カスタム・エクステンション（custom extensions）を、コール・コントローラのコア機能に構築し、所有者用のインターフェースを開発することにより、アプリケーションをインターフェースしている。産業界でこれを実行するためには、以下大きく２つのカテゴリに分けることができる。（１）Fixed Mobile Convergence (FMC：固定と移動の融合)と（２）IP Multimedia Services (IMS)エイリアスである。
【０００６】
ＦＭＣにおて、ユーザは、不断の通信サービスを、モバイルとVoIPのサービス・プロバイダーから、１つのデバイスを介して得る。呼びは、アプリケーション・サーバを介してアンカーされる。このアプリケーション・サーバは、様々なＩＤをマッピングし、携帯電話ネットワークとＶｏＩＰネットワーク間の呼びを、デバイスの信号強度に基づいて、切り替えている。それが企業内ネットワークで使用された場合には、他の通信アプリケーションは、マッピングについては知らず、携帯電話ＩＤと企業内ＩＤとを関連づけることができない。ＦＭＣのユーザの呼び処理に影響を及ぼし参加するためには、コアのアプリケーションは、カスタム・インターフェースを構築し、アンカー・アプリケーション・サーバとの一体化をすることが要求される。しかし、これにはコストと時間がかかる。
【０００７】
ＩＭＳは、ユーザ・プロファイルの概念を導入して、様々なＩＤ（即ち、パブリックＩＤ（public identifiers））を関連づけている。このユーザ・プロファイルは、パブリックＩＤあるいはコモンＩＤ（即ち、収束識別子（converged identifier））のいずれかを用いて、アクセスできる。通信リクエストが、関連するＩＤの１つから発せられたり、そこを宛先にされたりすると、コア・ネットワークのインフラとアプリケーションは、ユーザ情報に、ユーザ・プロファイルを用いてアクセスできる。ユーザ・プロファイルは、いずれかの識別子を用いてアクセスされる。しかし、このアプローチは、コア・インフラとアプリケーションに渡って幅広い変更を必要とし、又は、ＩＭＳエイリアス（IMS alias）をサポートするプロビジョンニング(provisioning：ネットワーク設備やシステム管理、ストレージ管理設備などを顧客のニーズに応じて提供するプロセス)・システムを必要とする。ＩＭＳユーザ・プロファイルのコンセプトを入れていない従来のあるいは既存の製品は、このアプローチからの利点を受けることはない。
【０００８】
現在、実施されている多くのソルーションにおいては、１つのアプリケーションが、企業内ユーザＩＤと外部ＩＤとを関連づけている。この種のアプローチは、新たに独立したアプリケーションが構築され、そのロジックがＩＤの関連性に依存している場合には、常に問題を引き起こす。外部ＩＤと企業内ユーザとを関連づけるネットワークに広がるフレームワークが無くなると、カスタム・コードと新たなインターフェースの開発が必要となる。このアプローチは、非効率的かつ時間もかかり高価である。
【０００９】
上記したように、他のアプローチ、例えばＩＭＳエイリアスは、ＩＤサブ・システムのオーバーホールを必要とする。例えば、インフラ・システム、アプリケーション・システム、プロビジョニング・システムを必要とする。これは、従来のインフラに多額の投資を行ったネットワークの必要性に適したものではない。
【課題を解決するための手段】
【００１０】
それ故に、本発明の一態様は、外部ＩＤと企業内ＩＤの関連づけを容易にする。特に、分散型のアプリケーション・アーキテクチャを実現するソリューションを提供する。
【００１１】
本発明の一実施例によれば、メソッド、デバイス、システムに、外部ＩＤとやり取りする呼びを、企業内ＩＤに対する呼びと同様に処理できる設備が具備される。本発明の一実施例により、従来のそして既存のアプリケーションが、大幅なコストをかけることなく、動作可能となる。
【００１２】
本発明の一態様は、企業外（non-enterprise）ＩＤテーブルを提供する。このテーブルにより、企業内（enterprise）ユーザの外部ＩＤと企業内ＩＤとを関連づける。
【００１３】
本発明の他の態様は、通信リクエスト処理の間、企業外ＩＤテーブルをレベレッジし、その結果、コーラーの外部ＩＤをコーラーの企業内ＩＤで置換する。例えば、これは、企業外ＩＤテーブルのルックアップ機能を用いて行う。
【００１４】
本発明の他の態様は、コーラーのオリジナルＩＤをリクエスト内の何処か（即ち、リクエスト・パケット・ヘッダ）に挿入する。
【００１５】
本発明の他の態様によれば、リクエストをコーラーの認証プロキシ（authoritative proxy）にルーティングして、発信処理（origination processing）を行う。言い替えると、発信側の特徴起動が行われる。これにより、コーラーの企業内プロファイルにより定義された通信特徴にアクセスする。企業内プロファイルとは、通信プリファレンスとコーラ−用のルールを含む通信プロファイルである。前記のコーラ−用のルールは、企業内に含まれ、独自環境のない外部ネットワークなしには共有し得ないルールである。発信処理の後、リクエストは、コーラーの認証プロキシにルーティングされ、着信処理（terminal processing）が行われる。言い替えると、着信側の特徴起動が行われる。
【００１６】
本発明の他の態様によれば、発信側の処理を起動した後、コーリーの外部ＩＤをコーリーの企業内ＩＤで置換する。これは、企業外ＩＤのテーブル・ルックアップ機能を用いて行う。
【００１７】
本発明の他の態様によりば、リクエストをコーリーの認証プロキシにルーティングし、着信側の特徴機能を行う。
【００１８】
本発明の他の態様によれば、コーリーのオリジナルの外部ＩＤをリストアする。例えば、これは、企業外ＩＤのテーブル・ルックアップ機能を用いて行う。その後、リクエストを外部ゲートウェイ／トランクにルーティングし、呼びを外部ＩＤで着信する。
【００１９】
本発明の方法は、
（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、を有する。
前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む。
【００２０】
一実施例によれば、第１ＩＤは企業外ＩＤであり、第２ＩＤは企業内ＩＤである。これは、企業内ネットワークにインバウンド（inbound）する通信リクエストに適用される。他の実施例において、第１ＩＤは企業内ＩＤであり、第２ＩＤは企業外ＩＤである。これは、企業内ネットワークからアウトバウンド（outbound）する通信リクエストに適用される。
【００２１】
ユーザＩＤのマッピングは、企業内ユーザに、企業ベースの通信プリファレンスへのアクセスを提供するのに有効である。特に、企業内ユーザが、企業外通信デバイスを用いている場合に有益である。言い替えると、ネットワーク・バウンダリ・デバイス（network boundary device）が、ユーザの企業外ＩＤを企業内ＩＤに、特定の通信リクエスト用のＩＤマッピング・モジュールを用いて、マッピングすると、その通信リクエストは、あたかも、企業内デバイスから発信されたか、又は企業内デバイスに発信されたように、処理される。通信リクエストが、ネットワークを通過してアプリケーションに達すると、各アプリケーションは、ユーザＩＤを企業内ＩＤにマッピングし戻す必要はない。言い替えると、企業内ネットワーク内の全ての処理は、ネットワーク・バウンダリあるいは他のネットワーク・デバイスで行われるＩＤマッピングからの恩恵を受ける。
【００２２】
企業内ネットワークから発信された呼びに対しては、発信側の処理の後、被呼者（コーリー）のＩＤは、ネットワークのコア内で置換される。企業内ネットワークの外部から発信された呼びに対しては、被呼者のＩＤあるいは発呼者のＩＤは、ネットワーク・バウンダリで置換される。いずれの状況においても、そのリクエストは、着信側の認証サーバ（authritative server）に転送される。着信側の処理の終了後、コンタクト・リゾリューション（contact resolution：コンタクト先の発見処理）の間、オリジナルの被呼者はリストアされる。
【００２３】
本発明の一実施例において、ＩＤマッピングは、あるネットワークＩＤを他のネットワークＩＤにマッピングすることを含む。この場合、両方のＩＤは、企業内ＩＤでなくてもい。一実施例において、呼びは、第１の企業外ＩＤを有するものとして受領される。この第１の企業外ＩＤは、同一ユーザの企業内ＩＤにマッピングされる。その後、呼びが企業内ネットワーク外に転送して戻されると、そのユーザの企業内ＩＤは、別の企業外ＩＤにマッピングされて、被呼者との効率的な通信を実施する。かくして、あるタイプのネットワークＩＤを、呼びあるいは通信リクエストのコーラーの識別子フィールドに含めることが可能となる。
【００２４】
本明細者において、用語「通信リクエスト」は、あらゆる種類の通信セッション開始メッセージを含む。代表的な通信リクエストは、SIP INVITE、コール・セットアップ・メッセージ、ビデオ・コール・セットアップ・メッセージ、第１インスタント・メッセージ、リソース保存メッセージ、通信セッションを開始したり設定したりするメッセージ（例、音声、画像、テキスト、電子メール、ＩＭ）を含む。
【図面の簡単な説明】
【００２５】
【図１】本発明の一実施例による通信システムのブロック図。
【図２】本発明の一実施例による第１ユーザのＩＤを第２ユーザのＩＤにマッピングするのに用いられるデータ構造を表すブロック図。
【図３】本発明の一実施例によるアウトバンド・リクエスト処理の流れを表すブロック図。
【図４】本発明の一実施例によるインバウンド・リクエスト処理の流れを表すブロック図。
【発明を実施するための形態】
【００２６】
図１において、本発明の通信システム１００は、第１ネットワーク、例えば企業内ネットワーク１０４を含む。この企業内ネットワーク１０４は、複数の企業内通信機器１０８を、内部ネットワーク・デバイス１１２ａ、１１２ｂに接続する。この企業内通信機器１０８の一例は、企業内ネットワーク１０４を管理運営する企業により所有され、操作され、利用されるデバイスである。内部ネットワーク・デバイス１１２ａ、１１２ｂは、アプリケーション・サーバあるいはフューチャ・サーバに対応する。具体的には内部ネットワーク・デバイス１１２ａ、１１２ｂは、ＳＩＰアプリケーション・サーバ又はフューチャ・サーバに対応する。このサーバが、ＳＩＰ機能を企業内通信機器１０８に提供する。一般的には、内部ネットワーク・デバイス１１２ａ、１１２ｂは、所定のフューチャ（以下、「特徴」とも称する）とアプリケーションを、企業内ユーザに提供する。この企業内ユーザは、企業内通信機器１０８を利用してもしなくてもよい。内部ネットワーク・デバイス１１２ａ、１１２ｂは、フューチャ又はアプリケーションを提供することに加え、コンタクト・ソリューション機能を提供するか、内部ネットワーク・デバイス１１２ａ、１１２ｂで受領した様々な通信リクエストのアプリケーション・シーケンスを決定する。或いはその両方を行う。適切な内部ネットワーク・デバイス１１２ａ、１１２ｂの一例は、通信マネージャ、通信マネージャ・ブランチ、ＳＩＰイネーブル・サービス、システム・マネージャ、あるいはアバイア・インク（出願人.）により市販されている類似の装置である。
【００２７】
企業内ネットワーク１０４は、あらゆるタイプの公知の通信媒体、あるいは通信媒体の集合体であり、あらゆるタイプのプロトコルを用いて、エンドポイント間でメッセージを転送する。企業内ネットワーク１０４は、無線あるいは有線の通信技術を使用する。企業内ネットワーク１０４の一例は、ＬＡＮ、ＷＡＮ、ＳＩＰネットワーク、パケット交換ネットワーク、回路交換ネットワーク等である。さらに企業内ネットワーク１０４は、１つのネットワークに限定されず、様々なネットワークから構成されることもある。
【００２８】
企業内ネットワーク１０４は、外部ネットワーク１５２（例、企業外通信ネットワーク）にネットワーク・バウンダリ・デバイス１３６を介して、接続される。ネットワーク・バウンダリ・デバイス１３６の一例は、アバイア・インクに生産販売されているAura Session Managerである。外部ネットワーク１５２は、あらゆるタイプの企業外ネットワーク（例えば、安全が確保されていないか、あるいは企業の従業員により管理されていないネットワーク）を含む。インターネットは、信頼出来ない外部ネットワーク１５２の一例である。これは、世界中に広がるコンピュータや通信機器からなるＩＰネットワークを構築する。このネットワークは、電話システムあるいは他の手段を介して接続される。外部ネットワーク１５２の他の例は、ＰＯＴＳ、ＩＳＤＮ、ＰＳＴＮ、携帯電話通信ネットワーク等である。
【００２９】
本発明の一実施例によれば、企業内通信機器１０８と企業外通信機器１５６（即ち、企業に登録されていない通信デバイス、又は登録された企業のユーザが使用しない通信デバイス）との間の通信は、ユーザ・プリファレンス・テーブル１２０を介して実行される。外部通信機器１５６は、企業内通信機器１０８に類似し、いずれの装置もあらゆるタイプの公知の通信機器あるいはプロセッサを含む。例えば、これは、パソコン、ラップトップ、ＰＤＡ、携帯電話、スマートフォン、電話、アナログフォンあるいはＤＣＰフォンあるいはそれらの組み合わせである。１つの企業内通信機器１０８又は企業外通信機器１５６は、１人のユーザにより制御されるかあるいは１人のユーザに関連する、又は多くのユーザ（例えば、企業内のユーザが通信デバイスを、ユーザ・ネーム又はパスワードを入力することにより使えるようになる企業内通信デバイスで）で使用される。
【００３０】
通信機器１０８と１５６の複数のある機器は、同一のユーザに関連していてもよい。言い替えると、通信機器１０８と１５６は、１人のユーザに帰属し、様々な種類の通信デバイスに対応することができる。一例として、企業内ユーザが、企業内通信機器１０８又は企業外通信機器１５６を４台有し、それらが１人のユーザの個人用電話、会社用電話、個人用パソコン、電子メール装置にそれぞれ対応してもよい。かくして、企業内通信機器１０８のある機器は、企業内ネットワーク１０４に直接接続され、他の企業外通信機器１５６、例えば、電子メール装置は、外部ネットワーク１５２に、企業内のサービス・プロバイダを介して接続される。一実施例によれば、企業内のユーザに関連するが、企業内ネットワーク１０４には接続されていない通信デバイスは、企業内通信機器１０８として取り扱われ、企業内処理を受け入れ、通信される。別の構成として、各企業内通信機器１０８と企業外通信機器１５６は、異なるユーザが所有し操作してもよい。
【００３１】
通信機器１０８と１５６は、他の通信機器１０８と１５６との間で、ビデオ通信、オーディオ通信、テキスト通信、データ通信をサポートする。他の通信機器１０８と１５６と通信する通信機器１０８と１５６により使用される通信媒体の種類は、通信機器１０８と１５６で利用できる通信アプリケーションに依存する。
【００３２】
企業内ネットワーク１０４のある特徴は、それらが企業内通信機器１０８（これは信頼できない企業外通信機器１５６に接続されている）で、呼びを開始したり、呼びを受領したりする場合に、企業内ユーザにより利用可能となる。このような特徴は、内部ネットワーク・デバイス１１２ａ、１１２ｂで提供されるが、これはネットワーク・バウンダリ・デバイス１３６が、企業内ユーザのＩＤを既知の企業内ＩＤにマッピングするか否かに基づいて行われる。
【００３３】
内部ネットワーク・デバイス１１２ａ、１１２ｂには、アプリケーション１１６、ユーザ・プリファレンス・テーブル１２０、アプリケーション・シーケンシング・モジュール１２４、コンタクト・レゾルーション・モジュール１２８をそれぞれ具備し、通信特徴を企業内ユーザに与える。アプリケーション１１６は、通信特徴を企業内ユーザに提供できる。代表的なアプリケーション１１６は、ＥＣ−５００（携帯電話へのエクステンション）のアプリケーション、コール・セットアップ・アプリケーション、ボイスメール・アプリケーション、電子メール・アプリケーション、ビデオ・アプリケーション、テキスト・アプリケーション、カンファレンス・アプリケーション、あるいは他の公知の通信アプリケーションを含む。
【００３４】
ユーザ・プリファレンス・テーブル１２０は、企業内ネットワーク１０４の様々な企業内ユーザの通信プリファレンスを含む。一実施例によれば、特定の内部ネットワーク・デバイス１１２ａ、１１２ｂは、全ての企業内ユーザの所定のサブセットに対してのみユーザ・プリファレンスを含んでもよい。この構成において、特定のユーザに対する通信プリファレンスを有する内部ネットワーク・デバイス１１２ａ、１１２ｂは、そのユーザに対する認証プロキシ（authritative proxy）あるいは認証サーバ（authritative server）として見なされる。認証サーバ又は認証プロキシとして機能すると、内部ネットワーク・デバイス１１２ａ、１１２ｂは、通信リクエストを受領し、この通信リクエストに関連するユーザを、ユーザの企業内ＩＤにより、特定し、さらにユーザ・プリファレンス・テーブル１２０を参照することにより、ユーザの通信プリファレンスを決定する。
【００３５】
ユーザの通信プリファレンスが、内部ネットワーク・デバイス１１２ａ、１１２ｂにより決定されると、アプリケーション・シーケンシング・モジュール１２４が、起動され、アプリケーション・シーケンスを決定し、ユーザの特定した通信プリファレンスを得る。一実施例において、ユーザ・プリファレンス・テーブル１２０のコンテンツは、企業内ユーザにより、ウェブ・インターフェース又はオーディブル・インターフェースにより、提供される。
【００３６】
内部ネットワーク・デバイス１１２ａ、１１２ｂは、その後、通信リクエストをアプリケーション１１６にルーティングするが、デバイスは同一の装置内あるいは別の装置内であってもよく、さらにアプリケーションにより処理される。
【００３７】
コンタクト・レゾルーション・モジュール１２８が、通信リクエストに対するコンタクト・レゾルーション（コンタクト先の住所検索）を実行する。しかしこれは、通信リクエストがアプリケーション１１６により処理された後である、一実施例によれば、コンタクト・レゾルーション・モジュール１２８は、同一の認証サーバもしくはプロキシ内にあってもよい。他の実施例によれば、コンタクト・レゾルーション・モジュール１２８は、ユーザの通信プリファレンスを有する装置とは別の内部ネットワーク・デバイス１１２ａ、１１２ｂにあってもよい。いずれの場合も、コンタクト・レゾルーション・モジュール１２８は、特定のタイプのアプリケーションであり、これにより、通信のアラート（警報）に関連するユーザの通信プリファレンスを決定し、ユーザに関連する適切な通信デバイスに対し、警報を発したりしなかったりする。例えば、企業内ユーザが、企業内通信機器１０８を２台所有する場合は、コンタクト・レゾルーション・モジュール１２８は、通信リクエストを特定のユーザが受領した時に、企業内通信機器１０８の一方又は両方に警告を発するか否かを決定する。コンタクト・レゾルーションのフェーズが完了すると、通信リクエストは、適切な企業内通信機器１０８に転送されて、通信セッションを確立しようとする。
【００３８】
ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０と、企業外ＩＤテーブル１４４と、ルーティング・テーブル１４８とを有する。これにより、ネットワーク・バウンダリ・デバイス１３６は、企業内ネットワーク１０４に入る又はそこから出る呼び又は通信リクエストを解析し、呼び又は通信リクエスト内のどのエンティティが別のＩＤにマッピングされるＩＤを有すかを決定し、呼び又は通信リクエストを変更し、この別のＩＤを参照する。
【００３９】
内部ネットワーク・デバイス１１２ａ、１１２ｂは、呼びを解析し、コーラー又はコーリーのＩＤを、適宜の別のＩＤにマッピングする。その為、内部ネットワーク・デバイス１１２ａ、１１２ｂの一方又は両方は、ＩＤマッピング・モジュール１４０と、企業外ＩＤテーブル１４４と、ルーティング・テーブル１４８を有することもできる（図示してはいないが）。
【００４０】
ネットワーク・バウンダリ・デバイス１３６は、企業内ユーザの記録の一部を保持する企業内ネットワーク１０４に帰属するあらゆるタイプのデバイスを含む。ネットワーク・バウンダリ・デバイス１３６と見なされる代表的なデバイスは、ＳＩＰルーティング・エレメント、ユーザ・リレーション・エレメント、セッション・ボーダ・コントローラ（SBC's））、ゲートウェイ、プロキシ等である。ＳＩＰルーティング・エレメントは、ＳＩＰサイト間でのルーティングとダイヤルプランを確立し、企業内ネットワーク１０４又は信頼できない外部ネットワーク１５２への着信とそこからの発信を提供する。ユーザ・リレーション・エレメントは、ユーザを装置にバインドし、あるいはユーザをそのアプリケーションをバインドする。プロキシは、通信デバイスからの呼びの制御を実行し、アドレス変換を行うのセントラル・リポジトリ（ＩＰアドレス）として機能する。これらの要素は、共通サーバ上にあるか、あるいは複数のサーバに分散して配置される。
【００４１】
本発明の一実施例によれば、通信リクエスト内でユーザＩＤをマッピングすることは、必ずしもネットワーク・バウンダリ・デバイス１３６で行われるとは限らない。例えば、マッピングは、企業内ネットワーク１０４内のネットワーク・バウンダリ・デバイス１３６の「背後」で行われることもある。
【００４２】
ユーザＩＤのマッピングは、企業内ユーザに、企業ベースの通信プリファレンス（ユーザ・プリフェランス・テーブル１２０）へのアクセスを提供するのに有効である。特に、企業内ユーザが、企業外通信デバイス１０８を用いている場合に有益である。言い替えると、ネットワーク・バウンダリ・デバイス１３６が、ユーザの企業外ＩＤを企業内ＩＤに、特定の通信リクエスト用のＩＤマッピング・モジュール１４０を用いて、マッピングすると、その通信リクエストは、あたかも、企業内デバイスから発信されたか、又は企業内デバイスに発信されたように、処理される。通信リクエストが、ネットワークを通過してアプリケーション１１６，１２４，１２８に達すると、各アプリケーションは、ユーザＩＤを企業内ＩＤにマッピングし戻す必要はない。このステップは、ネットワーク・バウンダリ・デバイス１３６で実行され、その為、ＩＤマッピングは、アプリケーションにはとらわれず（application agnostic）、特定のアプリケーションではなく、通信セッションにバウンドされる。言い替えると、企業内ネットワーク１０４内の全ての処理は、ネットワーク・バウンダリ装置１３６で行われるＩＤマッピングからの恩恵を受ける。
【００４３】
ネットワーク・バウンダリ・デバイス１３６は、企業外ＩＤテーブル１４４とルーティング・テーブル１４８を含むものとして示されている。しかし、そのテーブルを埋めるのに必要な情報の全てあるいは一部が、企業内データベース１３２内にあり、この企業内データベース１３２が、ネットワーク・バウンダリ・デバイス１３６によりアクセスされる構成でもよい。テーブル内の情報は、企業内ユーザによりあるいは企業内ネットワーク管理者により変更あるいは再提供されると、データは、１つのポイント即ち企業内データベース１３２で変更可能であり、ネットワーク・バウンダリ・デバイス１３６は、必要に応じて、このような変更を取り出すことができる。別の構成として、企業外ＩＤテーブル１４４とルーティング・テーブル１４８は、個別に維持しても、ネットワーク・バウンダリ・デバイス１３６内で完全に維持してもよい。
【００４４】
一実施例によれば、企業外ＩＤテーブル１４４は、ユーザ又は管理者（アドミニストレータ）に提供されるテーブル（表）である。このテーブルは、ある企業内のユーザの企業ＩＤをそのユーザの企業外ＩＤにマッピングする情報を含む。ＩＤマッピング・モジュール１４０は、必要なＩＤマッピングを実行するルーティンであり、これにより、企業内ユーザは、企業内通信機器１０８を用いずに、企業内通信プリファレンスにアクセスできる。
【００４５】
ルーティング・テーブル１４８は、企業ＩＤを、その企業ＩＤに関連するユーザ用の認証サーバ又はプロキシにマッピングする情報を含む。この情報は、直接ネットワーク・バウンダリ・デバイス１３６に与えられるか、或いはウェブ・インターフェースあるいはオーディオ・インターフェースを介して与えられるか、あるいはユーザが企業データベース１３２内で情報を更新すると、自動的に与えられる。例えば、企業データベース１３２は、データの更新をネットワーク・バウンダリ・デバイス１３６に入れるか、あるいはネットワーク・バウンダリ・デバイス１３６が、周期的に企業データベース１３２にデータを入れて、最新の変更データを得ることができる。
【００４６】
言い替えると、ルーティング・テーブル１４８は、ある情報を含む。この情報は、ユーザを企業内ＡＯＲを介して特定し、企業内ＡＯＲを内部ネットワーク・デバイス１１２ａ、１１２ｂにマッピングする。ＳＩＰによりドメイン内のＡＯＲは、３つ以上のエイリアスを用いて表現できる。「ドメイン内（In-domain）」とは、あらゆるドメインのメンバー、あるいはその企業が認証されているサブドメインを意味する。各エイリアスは、同一のユーザを意味するが、異なる表現あるいはフォーマットである。１人のユーザ当たり３個のＡＯＲが割り当てられると、古いプライベート企業ネットワーク（classic private enterprise networks）、グローバルＰＳＴＮ（global PSTN）、インターネット等の最大のインターオペラビリティ（相互運用性）が得られる。一例として、ユーザ「ジョン・ドゥー（John Doe）」に対する３個のＡＯＲは、次の通りである。
【００４７】
3031234567@e.com：このフォーマットは、企業プライベート・ナンバリング・フォーマットと称する。ユーザ部分数列でなければならない。「＋」の文字を含まないが、@SIPdomain部分を含む。顧客は、E.164フォーマット（先頭の「＋」がない）を、自分のプライベート・ナンバリング・プランとして選択するか、プライベート・ナンバリング・プラン・エイリアスを全く有さないか、を選択できる。
【００４８】
+13031234567@e.com：このフォーマットは、E.164インターナショナル・フォーマットと称する。これは「＋」文字を最初の場所に含み、@SIPdomain部分を含む。
【００４９】
JohnDoe@e.com：このフォーマットは、Alphanumeric Handle Formatと称する。これは、@SIPdomain部分を含み、ユーザ側はE.164インターナショナル・フォーマットあるいはプライベート・ナンバリング・フォーマットであってはならない。
【００５０】
上記の３つのフォーマットは、企業内で正式に認められたものと見なされる。その理由は、これらはコア−・ルーティングが可能で、企業内ネットワーク１０４に渡って、あらゆるロケーション或いはサイトで、一人のユーザを唯一表すからである。これらのＡＯＲフォーマットとそれらのルーティングが具備される。この具備された情報の一部あるいは全てが、ルーティング・テーブル１４８又は企業外ＩＤテーブル１４４内で、保持される。
【００５１】
次の動作について説明する。ネットワーク・バウンダリ・デバイス１３６は、通信リクエストを、外部ネットワーク１５２又は企業内ネットワーク１０４のいずれかから受領する。その後、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストを解析し、この通信リクエスト内で特定されたエンティティを決定する。例えば、発信ユーザ（即ち、コーラー）と目標ユーザ（即ち、コーリー）と目標エンティティ（即ち、１つの通信リクエストが、特定のユーザではなく企業に向けられるようなコンタクト・センタ構成内のエンティティ）を決定する。ＩＤマッピング・モジュール１４０は、この情報を受け取り、通信リクエスト内で特定されたエンティティが、別のＩＤ（例えば、通信リクエスト内の企業外ＩＤを介して特定されたユーザ用の企業内ＩＤ、又は通信リクエスト内の企業内ＩＤを介して特定されたユーザ用の企業外ＩＤ）を有するか否かを決定するために、評価を行う。この評価は、企業外ＩＤテーブル１４４に記憶された情報との比較、ルーティング・テーブル１４８との比較、あるいは他のポリシー又はルールとの比較を含む。この決定に基づいて、ＩＤマッピング・モジュール１４０は、通信リクエスト内のヘッダーを別の識別子で置換する。この別の識別子は、企業内ネットワーク１０４又は信頼されていない外部ネットワーク１５２を通して、通信リクエストに続くものである。
【００５２】
図２において、企業外ＩＤテーブル１４４とルーティング・テーブル１４８の詳細を、一実施例に基づいてさらに説明する。
【００５３】
企業外ＩＤテーブル１４４は、企業外ＩＤを企業内ＩＤにマッピングする、あるいはその逆にマッピングするフィールドを有する。一実施例において、企業外ＩＤテーブル１４４は、企業外ＩＤフィールドと企業内ＩＤフィールドとを有する。このフィールドは、その企業ユーザとの様々なエンティティの関連あるいはノン・エンティティの関連情報で埋められる。一実施例において、ネットワーク・バウンダリ・デバイス１３６にある企業外ＩＤテーブル１４４は、全ての企業内ユーザのエントリと、企業内ＩＤと企業外ＩＤ間のマッピング・テーブルを有する。他の実施例においては、ネットワーク・バウンダリ・デバイス１３６にある企業外ＩＤテーブル１４４は、全ての企業内ユーザのサブセットのエントリのみを含む。
【００５４】
ルーティング・テーブル１４８は、企業内ユーザを認証サーバにマッピングするフィールドを含む。一実施例において、ルーティング・テーブル１４８は、企業内ＩＤフィールドと認証サーバ・フィールドとを含む。ルーティング・テーブル１４８の各列は、企業内ユーザ用の特定の企業内ＩＤを、そのユーザの認証サーバにマッピングする。企業内ＩＤ（例、ドメイン内のＡＯＲ）は、複数のエイリアスを有する。ユーザに対する各エイリアスは、同一の認証サーバにマッピングされる。
【００５５】
図２において、特定のユーザであるアリス（Alice）は、複数の企業外ＩＤ２０４ａ、ＩＤ２０４ｂを有する。それらのいずれも別の通信機器（個人の家庭用電話あるいは携帯電話）に関連づけられている。企業外ＩＤ２０４ａ、２０４ｂの全ては、同一の企業内ＩＤ２０８にマッピングされる。この企業内ＩＤ２０８は、ルーティング・テーブル１４８で参照され、そのユーザの認証サーバを特定する。
【００５６】
ＩＤマッピング・モジュール１４０は、通信リクエストを受領し、この通信リクエスト内のヘッダー内にあるユーザの第１ＩＤをそのユーザの第２ＩＤで置換する。企業外ＩＤテーブル１４４内のユーザの企業内ＩＤと企業外ＩＤは、別のＩＤを含み、それらはＩＤマッピング・モジュール１４０により交換される。この交換は、通信リクエストが企業内ネットワーク１０４へのインバウンドか、あるいは企業内ネットワーク１０４からのアウトバウンドかに基づいて、行われる。
【００５７】
図３において、企業内ネットワーク１０４から信頼できない外部ネットワーク１５２へのアウトバウンドの通信リクエストのステップを示す。このプロセスは、通信リクエストが企業内通信機器１０８により開始された時に始まる（ステップ３０４）。その後、企業により必要とされる場合には、ユーザの認証が実行される（ステップ３０８）。
【００５８】
その後、通信リクエストは、発信側の処理を受け、発呼者の認証サーバが、発呼者の通信プリファレンスに基づいて、適切なアプリケーション・シーケンスを決定する（ステップ３１２）。このアプリケーション・シーケンスは、ユーザ・プリファレンス・テーブル１２０内の発呼者の企業内ＩＤを参照し、発呼者のプリファレンスにマッチした、アプリケーション・シーケンスを決定することにより、決定される。
【００５９】
このフローは、通信リクエストをネットワーク・バウンダリ・デバイス１３６が受領した時に継続する。そこでＩＤマッピング・モジュール１４０が起動され、被呼者が企業外ＩＤテーブル１４４内にいるか否かが決定される（ステップ３１６）。被呼者の企業外ＩＤテーブル１４４内で一致が見出されない（いない）場合、通信リクエストは、外部ネットワーク１５２に行く。企業外ＩＤテーブル１４４で一致が見出された（いる）場合には、リクエストＵＲＩ（即ち、宛先側のヘッダー内の被呼者の企業外ＩＤ）のコンテンツを、企業外ＩＤテーブル１４４内で見出された被呼者の企業内ＩＤで置換する。さらに補足パラメータが、ヘッダーに追加され、宛先デバイスが外部デバイス（即ち、企業外通信機器）であると認定する。この特定データを通信リクエストに追加する詳細は、米国特許出願No.12/493,031号に記載されている。
【００６０】
被呼者のオリジナル（元）のＩＤ（即ち、企業外ＩＤ）は、通信リクエスト内に保持されるが、これは、その値をヘッダー内に挿入することにより、そして後の時点で呼び処理で取り出すことにより、行われる。
【００６１】
その後、呼びのフェーズは、着信側の処理に変わり、この通信リクエストは、被呼者の認証サーバにルーティングされる。これは、ルーティング・テーブル１４８を参照することにより決定される（ステップ３２０）。通信リクエストを被呼者の認証サーバで受領すると、実際の着信側の処理が開始され、認証サーバのアプリケーション・シーケンシング・モジュール１２４が、通信リクエストの着信側の処理の適切なアプリケーション・シーケンスを、被呼者の通信プリファレンスに基づいて、決定する（ステップ３２４）。
【００６２】
着信側の処理後、通信リクエストのフェーズは、コンタクト・レゾルーション・フェーズに切り替わり、このコンタクト・レゾルーションが、全てのコンタクト・アドレスに対し実行される（ステップ３２８）。このステップにおいて、リクエストＵＲＩの値は、コンタクト・アドレスで置換され、通信リクエストのフェーズは、エンドポイントに変わる。その後、通信リクエストは適切な装置に転送される。宛先装置の１つが、企業内ネットワーク１０４に対し内部にある企業内通信機器１０８の場合には、ルーティング・ロジックは、通信リクエストをコンタクト・アドレスに転送する（ステップ３３２）。宛先装置の１つが企業外通信機器１５６の場合には、通信リクエストは、適切なゲートウェイ／ＳＩＰトランクにルーティングされ（ステップ３３６）、その結果、通信リクエストは、所望の外部番号にルーティングされる（ステップ３４０）。一実施例において、タグ・フェーズが、通信リクエストのエンドポイントに変更されると、ルーティング・ロジックは、企業外エクステンションと他のテーブル・ルックアップ（これは、呼びのルーティングの間通常必要とされ）をバイパスする。さらに通信リクエストが企業内ネットワーク１０４を出ると、リクエストＵＲＩ内の値を、被呼者の元のＩＤで置換することは、利点があり、必要である。
【００６３】
図４において、このフローは、外部ネットワーク１５２から企業内ネットワーク１０４が受領したインバウンドの通信リクエストを処理するステップを表す。このフローは、通信リクエストの発信元が、外部ネットワーク１５２の一部であると開始する（即ち、企業外通信機器１５６により行われたものとして開始する（ステップ４０４）。来入した通信リクエストを、ゲートウェイ、ＳＩＰトランク、あるいは類似のネットワーク・バウンダリ・デバイス１３６で、受領する（ステップ４０８）。最初に、通信リクエストは、それに関連したフェーズを有さない。通信リクエストを受領すると、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストの発信者（コーラーあるいは発呼者）を見る。これは、企業外ＩＤテーブル１４４内のリクエストのPAI header、From header、或いは他の合意したupon headerで特定されたものである。
【００６４】
発信者の識別子のマッチが、企業外ＩＤテーブル１４４で見出されない場合には、フローは、通信リクエストのターゲット（コーリーあるいは被呼者）を調べ、被呼者の認証サーバを決定することにより、継続する。これは、ルーティング・テーブル１４８内のR-URI header, To header, 合意したupon headerで特定される。ＰＡＩヘッダーとＲｅｑｕｅｓｔ−ＵＲＩの詳細は、米国特許出願第１２／４９３，０３１号に開示されている。
【００６５】
その後、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６により、被呼者用の認証サーバに転送される。そこで、アプリケーション・シーケンスが被呼者用に決定される（ステップ４２８）。これにより、通信リクエストの着信処理が起動される。この着信処理は、通信リクエストをアプリケーション・シーケンスで指定されたアプリケーション１１６に流す。その結果、アプリケーション・シーケンス１１６は、この通信リクエストを処理することができる。その後、コンタクト・レゾルーションが、認証サーバにより実行され、通信リクエストが、被呼者に関連する適切な通信デバイスに転送される（ステップ４３２）。
【００６６】
ステップ４０８に戻って、マッチが企業外ＩＤテーブル１４４内の発呼者に対して見出されると、フローは、発呼者の元のＩＤを発呼者の企業内ＩＤにマッピングすることにより継続する（ステップ４１６）。このステップの間、発信者の企業ＡＯＲは、通信リクエストのＰＡＩヘッダー内の発信者の元の企業外ＩＤを置換する。さらに、通信リクエストにあるインディケータがマークされ、例えば、デバイス−タイプ＝エクスターナル（device-type=external）が付され、その通信リクエストは、企業外通信機器１５６から発信されたものと特定する。さらに、被呼者の元のＩＤが、通信リクエスト内にパラメータとして、通信リクエストのヘッダー内に挿入される。その後、発呼者の認証サーバは、ルーティング・テーブル１４８を参照することにより、決定される。
【００６７】
この呼びのフェーズが変更され、発信プロセスが開始され、この通信リクエストは認証サーバに転送される（ステップ４２０）。認証サーバは、アプリケーション・シーケンスを、発呼者の通信プリファレンスに基づいて決定し、この通信リクエストをシーケンス内の第１アプリケーションにルーティングして、アプリケーション・シーケンスを起動する。上記のアプリケーション・シーケンスは、アプリケーションを起動するステップを含む。第１アプリケーションが通信リクエストの処理を完了すると、この第１アプリケーションは、通信リクエストを第２アプリケーション（アプリケーション・シーケンスで特定される）に転送して、通信リクエストの処理を継続し、アプリケーション・シーケンスを完了する。
【００６８】
発信者のアプリケーション・シーケンスのアプリケーションが起動された後、本発明の方法は、通信リクエストを被呼者の認証サーバにルーティングする（ステップ４２４）ことにより、継続する。発呼者と被呼者の両方の認証サーバは、ネットワーク・バウンダリ・デバイス１３６による同一のステップ、あるいは別個のステップで決定できる。被呼者の認証サーバは、発呼者の認証サーバと同一でも異なってもよい。一般的に、発呼者と被呼者の両者にとって、１つの装置（即ち、ネットワーク・バウンダリ・デバイス１３６）で、認証サーバを決定することは、このステップを２段階で行うことより効率的である。その理由は、同一のルーティング・テーブル１４８は、発呼者と被呼者を参照することができるからである。その後、通信リクエストを着信処理するプロセスが開始する（ステップ４２８）。
【００６９】
図３、４で通信状況について議論する。この通信状況においては、通信リクエストは、以下のいずれかの理由で、企業内ネットワーク１０４の境界を横切る。第１の理由は、通信リクエストが企業内通信機器１０８により発信され、企業外通信機器１５６の方向に向けられるからである。第２の理由は、通信リクエストが企業外通信機器１５６により発信され、そして企業内通信機器１０８に向けられるからである。この状況において、通信リクエストは、通信の固有の性質により、ネットワーク・バウンダリ・デバイス１３６に遭遇する。
【００７０】
通信リクエストは、ある企業内通信機器１０８により発信され、別の企業内通信機器１０８に向けられる。この種の通信は、２人の特定された企業内ユーザ間で起こるために内部通信と称する。２人の企業内ユーザの内部の呼び（両方のユーザは、彼らの企業内のＡＯＲを外部の番号に結びつける）の操作については、説明を割愛する。
【００７１】
共有ライン・アピアランス（外部番号の付いた）を有するユーザが、通信リクエストを他の企業内ユーザに発信した場合には、この通信リクエストは、発呼者の認証サーバを通る。発信側の認証サーバ（即ち、発呼者の認証サーバ）は、発呼者に関連する発信アプリケーション・シーケンス１１６を起動する。ここでアプリケーション１１６の一つは、共有ライン・アピアランスを実行する。この段階において、呼びは、外部番号には延長されないが、企業内デバイスは、それを延長するオプションを有する。
【００７２】
着信側において、被呼者の認証サーバは、被呼者に関連するアプリケーション・シーケンスを開始する。被呼者は、共有ライン・アピアランス特徴を有するために、着信側のアプリケーション・シーケンス１１６の１つは、このロジックを実行する。
【００７３】
呼びを、外部番号を含む被呼者の別のコンタクト先に提供するために、アプリケーション１１６は、コンタクト・レゾルーションを最大活用して、呼びをフォークする（分ける）。これは、リクエストをコンタクト・レゾルーション・モジュール１２８に送ることにより行う。ただし、Ｒ−ＵＲＩを修正することはない。別の構成として、アプリケーションは、呼びそのものをフォークするが、これはＲ−ＵＲＩを別のコンタクト・アドレスで置換することで、行う。
【００７４】
２つの企業のユーザが関与する呼びのシナリオを以下議論する。両方のユーザは、企業内番号（即ち、企業内ＩＤ）と関連する外部番号（即ち、企業外ＩＤ）を有する。以下は２つの呼びの例である。
１．企業内のユーザが別のユーザを呼び出すが、これは、企業内の電話から被呼者であるユーザのＰＳＴＮの内線番号をダイヤルすることにより行う。
２．企業内のユーザが別のユーザを呼び出すが、これは企業内の電話のＰＳＴＮ内線から企業の企業電話番号をダイヤルすることにより行う。
【００７５】
この実施例において、２つの企業内ユーザは、アリス（Alice）とボブ（Bob）であるとする。彼らは、企業内ＩＤである28521223@avaya.com（Alice-eと称する）と25381324@avaya.com（Bob-eと称する）をそれぞれ有する。それに加えて両方とも、彼らの企業内特徴を外部の番号に延長する。アリスは携帯電話番号である＋17324215858（Alice-mと称する）と、ボブは携帯電話番号である＋13035657856（Bob-mと称する）をそれぞれＰＳＴＮの延長として有する。
【００７６】
第１のシナリオにおいて、アリスはボブの携帯電話に、自分の企業内電話から電話をかける。第２のシナリオは、アリスはボブの会社の電話番号に自分の携帯電話から電話をかける。第１のシナリオにおいて、Alice-eは、Bob-mへの呼びを開始すると、通信リクエストは、アリスの認証サーバを通る。呼びの発信であるために、認証サーバは、アリスの通信プリファレンスに関連する発信アプリケーションを起動する。発信側のアプリケーションの全てが起動された後、認証サーバは、呼びのフェーズを着信に切り替える。次の認証サーバを決定するために、アリスの認証サーバは、通信リクエストをネットワーク・バウンダリ・デバイス１３６に送り、このネットワーク・バウンダリ・デバイス１３６が、ＩＤマッピング・モジュール１４０を起動して、企業外ＩＤテーブル１４４内の被呼者（Bob-m）をルックアップする。別の構成として、アリスの認証サーバは、ＩＤマッピング・モジュール１４０を含み、このＩＤマッピング・モジュール１４０が、企業外ＩＤテーブル１４４のルックアップを実行してもよい。
【００７７】
Bob-mは、Bob-eに関連するので、エントリーは、企業外ＩＤテーブル１４４内に見出される。Bob-eを用いて、別のルックアップをルーティング・テーブル１４８内で実行して、ボブの認証サーバを決定する。リクエストをボブの認証サーバに送る前に、通信リクエストを更新して、呼びの特別な特徴を反映させる。
【００７８】
ボブの認証サーバにおいて、ボブの通信プロファイル（ユーザ・プリファレンス・テーブル１２０で決定された）に関連する着信アプリケーション１１６が起動される。アプリケーション１１６の１つが、共有ライン・アピアランス特徴を有するために、それはリクエストを、ボブが登録された複数のデバイスにフォークする（分ける）。例えば、Bob-eとBob-mに分ける。このアプリケーション１１６は、ボブの複数のコンタクト・アドレスを知ることになるが、これは、登録イベント・パッケージあるいは類似の登録アウェア・アプリケーションに登録することにより、行われる。別の構成として、アプリケーション１１６は、ボブの認証サーバのコンタクト・レゾルーション・モジュール１２８に依存して、リクエストをフォークする。アプリケーション１１６は、認証サーバがリクエストをフォークすることを、望む場合でも、それはＲ−ＵＲＩを変更することはない。着信側のアプリケーションの全てを起動した後、ボブの認証サーバは、コンタクト・レゾルーションを実行する。ＳＩＰデバイス（Bob-e）において、それはリクエストを登録されたアドレスに転送する。外部デバイス（Bob-m）において、それは呼びをアプリケーション１１６にハンドオーバーして、適切な外部ゲートウェイ／ＳＩＰトランクに分配する。
【００７９】
第２のシナリオにおいて、アリスは、自分の携帯電話（Alice-m）から、ボブの企業内ＡＯＲ（Bob-e）に電話をかける。この呼びのリクエストは、携帯電話網を通り、ネットワーク・バウンダリ・デバイス１３６に行く。このネットワーク・バウンダリ・デバイス１３６は、企業内ネットワーク１０４と外部ネットワーク１５２を接続する。ネットワーク・バウンダリ・デバイス１３６は、リクエストを受領し、ＩＤマッピング・モジュール１４０を起動する。リクエストが、フェーズ・タグを有さずに到着するので、コーラーＩＤ（Alice-m）は、企業外ＩＤテーブル１４４に対しチェックされる。（Alice-eに）関連が見出されると、別のルックアップがルーティング・テーブル１４８内で実行され、アリスの認証サーバを見出す。リクエストをアリスの認証サーバに転送する前に、フェーズ・タグがリクエストに挿入されて、呼びの発信処理を要求する。さらに通信リクエストを更新して、呼びの特別なネイチャーを反映させる。
【００８０】
アリスの認証サーバにおいて、アリスに関係する発信側のアプリケーションは、ユーザ・プリファレンス・テーブル１２０により決定され、起動される。アプリケーション１１６の１つが、共有ライン・アピアランスであるので、そのアプリケーション１１６は、通知を他の登録されたコンタクト先に送る。これによりアリスは、他の装置（例えば、Alice-e）からの呼びに参加できる。全ての発信側のアプリケーションが起動されると、アリスの認証サーバは、呼びのフェーズを着信に切り替える。次の認証サーバを決定するために、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６に渡され、そこでＩＤマッピング・モジュール１４０が起動されて、企業外ＩＤテーブル１４４内の被呼者（Bob-e）をルックアップする。別の構成として、アリスの認証サーバは、企業外ＩＤテーブル１４４内でルックアップを実行してもよい。
【００８１】
Bob-eは、このテーブル内で見出されないので、第２のルックアップが、ルーティング・テーブル１４８内で実行され、Bob-eの認証サーバを決定する。Bob-eは、企業内ユーザであるために、このルックアップは、ボブの認証サーバのアドレスを戻る。リクエストをボブの認証サーバに転送する前に、フェーズ・タグがリクエストに挿入されて、通信リクエストの着信処理を要求する。
【００８２】
ボブの認証サーバにおいて、ボブのプロファイルに関連する着信アプリケーションが、ユーザ・プリファレンス・テーブル１２０から決定され、起動される。ボブは複数のコンタクト、内部コンタクトと外部コンタクトを有するために、リクエストはフォークされ、企業のＳＩＰデバイス（Bob-e）と外部携帯電話（Bob-m）に着信する。ロジックとアプリケーション・ポリシーに基づいて、デバイスの１つ（通常、応答する第１デバイス）が呼び内に留まり、他のリクエストはドロップされる。
【００８３】
上記の通信シナリオは、企業内ネットワーク１０４の境界を自然と横切るか（例、呼びが企業内ネットワーク１０４に入るか出る）、あるいは共有ライン・アピアランスにより企業内ネットワーク１０４の境界を横切る。本発明の実施例は、第１の企業ユーザが、第２のユーザ（必ずしも企業内ユーザであるとは限らない）に、企業外通信機器１５６から電話をする例である。これによれば、企業内ユーザは、それ自身の企業外通信機器１５６を構築して、通常モードではなく企業内モードで動作する。これにより、通信リクエストは、直接ダイヤルされた番号に送られる。企業内モードにおいて、企業外通信機器１５６は、ダイヤルされた番号の付いた通信リクエストを生成し、この通信リクエストを企業内ネットワーク１０４に送り、そこで発信側の処理が行われる。これにより、ネットワーク・バウンダリ・デバイス１３６は、通信リクエストを受領し、それを上記のように処理する。発信側の処理が完了すると、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６に送られ、その結果、それはダイヤルされた番号にルーティングされる。被呼者が企業内ＩＤを有さない場合には、通信リクエストは、直接被呼者に外部ネットワーク１５２を介して転送される。被呼者が企業内ＩＤを有する場合には、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストの着信側処理が、企業内ネットワーク１０４で行われる。
【００８４】
本発明によれば、あるネットワークタイプを別のネットワークタイプに、マッピングできる。特に、ある種のネットワークタイプの識別子をコーラーの識別フィールドに、含めることができる。外部ＩＤを企業内ＩＤにマッピングし同一の外部ＩＤに戻す代わりに、本発明は、第１の外部ＩＤを企業内ＩＤにマッピングし、その後、この企業内ＩＤを第２の外部ＩＤにマッピングする。これにより、発呼者と被呼者は、企業内のネットワークから複数の外部ＩＤにアクセスし利用することができる。
【００８５】
上記の説明は電話の呼びに関するものであるが、本発明はそれに限定されない。例えば、本発明の一実施例は、プレゼンス・リクエスト、インスタント・メッセージ、あるいは他の通信サービスを含むＳＩＰリクエストに基づいて、利用可能である。
【００８６】
本発明の実施例は、テーブル・ルックアップを含むアセスメント・アルゴリズム（assessment algorithm）を用いる例で、説明したが、本発明はこれに限定されない。具体的には、本発明は、呼びのリクエストのＩＤが変更されたが、この変更を形成し適応するために、装置がいかに機能するかについてには関連しない。エンティティのＩＤを変更するか否かの決定は、決定アルゴリズム（decision algorithm）を用いて行うことができる。
【００８７】
用語「コンピュータで読み取り可能な媒体」とは、コンピュータが実行するプロセスを記憶する媒体或いは伝送媒体を意味する。媒体とは、非揮発性媒体、揮発性媒体、伝送媒体を意味する。非揮発性の媒体とは、ＮＶＲＡＭ、磁気ディスク又は光学ディスクである。揮発性媒体とは、ＤＲＡＭ、メインメモリを意味する。このコンピュータで読み取り可能な媒体の一般的なものとしては、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気ディスク、他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、パンチカード、ペーパーテープ等、更にＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカード、メモリチップ、或いはカートリッジ等がある。ｅ−ｍａｉｌ或いは他の自己保存型の情報アーカイブに付属したデジタルファイルは、記憶媒体に等価な分配型の記憶媒体であり、本発明でいう記憶媒体と見なすことができる。コンピュータで読み取り可能な媒体がデータベースとして構築された場合には、このデータベースは、あらゆる種類のデータベース、例えば関連型、階層型、オブジェクト志向型のいずれをも含む。
本明細書の「モジュール」「エージェント」「ツール」とは、ハードウエア、ソフトウエア、ファームウエア、或いはそれらの組み合わせである。構成要素に関連した機能を実行する。
ここで議論したフローチャートは、特定のイベントのシーケンスを例に説明するが、本発明の操作に影響を及ぼすことなく、これ等のシーケンスの変更、追加、一部省略も可能である。本発明のシステムと方法は、特殊コンピュータ、プログラムされたマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、他の集積回路ＤＳＰ、ハードワイヤド電子素子、論理素子、例えばディスクリートな要素回路、プログラム可能な論理回路、ゲートアレイ、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、特殊目的コンピュータ或いは他の手段で実現できる。
ここに開示された方法は、オブジェクト指向のソフトウエア開発環境を用いたソフトウエアと組み合わせて実現できる。このソフトウエア環境は、様々なコンピュータ又はワークステーションで使用されるポータブルなソースコードを提供する。別の構成として、開示されたシステムは、標準の論理回路又はＶＬＳＩデザインを用いて一部又は全部のハードウエアで実現できる。本発明のシステムを実行するのにハードウエア又はソフトウエアを用いるかは、システムに要求される速度と効率に依存する。特に使用される特定のソフトウエア、ハードウエアのシステム、マイクロプロセッサ又はマイクロコンピュータシステムに依存する。
ここに開示された方法は、コンピュータで読み取り可能な記憶媒体に記憶されたソフトウエアで実行され、コントローラとメモリとを有するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ等で実施される。これ等の実施例に於いては、本発明のシステムと方法は、パソコンに組み込まれたプログラムで実行できる。例えばアプレット、ＪＡＶＡ、ＣＧＩスクプリト、サーバ或いはコンピュータ、ワークステーションに記録された資源或いは専用の測定システムに組み込まれたルーチン等で実施できる。
【００８８】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００８９】
１００ 通信システム
１０４ 企業内ネットワーク
１０８ 企業内通信機器
１１２ 内部ネットワーク・デバイス
１１６ アプリケーション
１２０ ユーザ・プリファレンス・テーブル
１２４ アプリケーション・シーケンシング・モジュール
１２８ コンタクト・レゾルーション・モジュール
１３２ 企業内データベース
１３６ バウンダリ・デバイス
１４０ ＩＤマッピング・モジュール
１４４ 企業外ＩＤテーブル
１４８ ルーティング・テーブル
１５２ 外部ネットワーク
１５６ 企業外通信機器
図２
左側
企業外ＩＤテーブル
外部エクステンション 企業内ＡＯＲ
右側
ルーティング・テーブル
企業内ＡＯＲ 認証サーバ
アリスの企業内取り扱い分
図３
宛先はＳＩＰデバイス
宛先は外部デバイス
図４
一致は有る
一致は無い
【技術分野】
【０００１】
本発明は、通信に関し、特に、ネットワークの境界にまたがってユーザをマッピングする技術に関する。
【背景技術】
【０００２】
ＳＩＰは、オープンなシグナリング・プロトコルであり、あらゆる種類のリアルタイムの通信セッションを確立する。ＳＩＰを用いて確立される通信セッションの一例は、音声、画像、インスタント・メッセージングを含む。これ等の通信セッションは、あらゆる種類の通信機器上で実行される。通信機器の一例としては、パソコン、ラップトップコンピュータ、パーソナルデジタルアシスタントである。ＳＩＰのキーの１つとなる特徴は、エンドユーザのＡＯＲ（Address of Record ）を全ての通信の１個の統合したパブリック・アドレスとして用いることができる点である。かくして、ＳＩＰを利用した通信の世界に於いては、ユーザのＡＯＲは、ユーザの唯一無二の（即ち単一の）アドレスとなり、ユーザを、ユーザに関連する通信機器の全てに関連付けている。このＡＯＲを用いると、発呼者は、ユーザ（被呼者）の通信機器の内の何れか１つ（ユーザ・エージェントと称する）に達することができ、これは唯一無二のデバイスのアドレス或いは電話番号のそれぞれを知らなくても、行うことができる。
【０００３】
しかし、問題がある。あるネットワーク内のユーザのＩＤは、別のネットワーク内では使用できない。例えば、ユーザは、企業内ネットワークで使用される企業内ＩＤを有し、（１）前記ユーザを特定する、（２）前記ユーザの通信プリファレンスを特定する、（３）通信サービスを、その通信プリファレンスに従って、前記ユーザに拡張する。ところが、ユーザが、自分の企業内ＩＤで、企業内デバイスを介してネットワークにアクセスしない場合には、ネットワークは、そのユーザを適正に特定することができず、所望の通信フューチャをユーザに与えることができない。この為、ユーザにはフラストレーションが溜まる。特に、ユーザが職場から離れて働いており、企業内通信サービスにアクセスしたくても直ぐにはできない場合がある。
【０００４】
"Mobile twinning"あるいは"Extension to Cellular（ＥＣ）" は、企業内のコール・コントローラにより提供される生産性向上のフューチャ（以下「特徴」とも称する）の１つである。この特徴により、外部電話（携帯と家庭用）は、職場の電話番号と対にされる（即ち、関連づけられる）。現在、企業内の特徴は、対になった外部電話にまで延長されるが、これは、外部電話番号（ＰＢＸ外の電話番号）と、企業内の電話番号とを緩く結合することにより行われている。この特徴の実行は、１つのコール・コントローラが、その特徴の唯一のコントローラであり、他のアプリケーションは、それに関係させる必要がないという前提に基づいている。アプリケーション・コントロールが、複数のアプリケーション・サーバ全体に分配されているようなアーキテクチャにおいて、通信インフラは、順番に複数のアプリケーションを起動して、１つのセッション・リクエスト上で動かす。しかし、これらのアプリケーションが、関連が分かるように修正されていない場合には、これらのアプリケーションは、正しい特徴のロジックを起動できない、即ち所望のサービスを提供できない。それ故に、既存のソリューション（１つのアプリケーションが、企業内のユーザの内部電話番号と外部電話番号との間の関連性をサポートし、他のアプリケーションはその関連性が分かっていない）では、分散したアプリケーション・アーキテクチャでは十分には機能しない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Avayaや他のＰＢＸベンダーは、この種の問題を解決するために、カスタム・エクステンション（custom extensions）を、コール・コントローラのコア機能に構築し、所有者用のインターフェースを開発することにより、アプリケーションをインターフェースしている。産業界でこれを実行するためには、以下大きく２つのカテゴリに分けることができる。（１）Fixed Mobile Convergence (FMC：固定と移動の融合)と（２）IP Multimedia Services (IMS)エイリアスである。
【０００６】
ＦＭＣにおて、ユーザは、不断の通信サービスを、モバイルとVoIPのサービス・プロバイダーから、１つのデバイスを介して得る。呼びは、アプリケーション・サーバを介してアンカーされる。このアプリケーション・サーバは、様々なＩＤをマッピングし、携帯電話ネットワークとＶｏＩＰネットワーク間の呼びを、デバイスの信号強度に基づいて、切り替えている。それが企業内ネットワークで使用された場合には、他の通信アプリケーションは、マッピングについては知らず、携帯電話ＩＤと企業内ＩＤとを関連づけることができない。ＦＭＣのユーザの呼び処理に影響を及ぼし参加するためには、コアのアプリケーションは、カスタム・インターフェースを構築し、アンカー・アプリケーション・サーバとの一体化をすることが要求される。しかし、これにはコストと時間がかかる。
【０００７】
ＩＭＳは、ユーザ・プロファイルの概念を導入して、様々なＩＤ（即ち、パブリックＩＤ（public identifiers））を関連づけている。このユーザ・プロファイルは、パブリックＩＤあるいはコモンＩＤ（即ち、収束識別子（converged identifier））のいずれかを用いて、アクセスできる。通信リクエストが、関連するＩＤの１つから発せられたり、そこを宛先にされたりすると、コア・ネットワークのインフラとアプリケーションは、ユーザ情報に、ユーザ・プロファイルを用いてアクセスできる。ユーザ・プロファイルは、いずれかの識別子を用いてアクセスされる。しかし、このアプローチは、コア・インフラとアプリケーションに渡って幅広い変更を必要とし、又は、ＩＭＳエイリアス（IMS alias）をサポートするプロビジョンニング(provisioning：ネットワーク設備やシステム管理、ストレージ管理設備などを顧客のニーズに応じて提供するプロセス)・システムを必要とする。ＩＭＳユーザ・プロファイルのコンセプトを入れていない従来のあるいは既存の製品は、このアプローチからの利点を受けることはない。
【０００８】
現在、実施されている多くのソルーションにおいては、１つのアプリケーションが、企業内ユーザＩＤと外部ＩＤとを関連づけている。この種のアプローチは、新たに独立したアプリケーションが構築され、そのロジックがＩＤの関連性に依存している場合には、常に問題を引き起こす。外部ＩＤと企業内ユーザとを関連づけるネットワークに広がるフレームワークが無くなると、カスタム・コードと新たなインターフェースの開発が必要となる。このアプローチは、非効率的かつ時間もかかり高価である。
【０００９】
上記したように、他のアプローチ、例えばＩＭＳエイリアスは、ＩＤサブ・システムのオーバーホールを必要とする。例えば、インフラ・システム、アプリケーション・システム、プロビジョニング・システムを必要とする。これは、従来のインフラに多額の投資を行ったネットワークの必要性に適したものではない。
【課題を解決するための手段】
【００１０】
それ故に、本発明の一態様は、外部ＩＤと企業内ＩＤの関連づけを容易にする。特に、分散型のアプリケーション・アーキテクチャを実現するソリューションを提供する。
【００１１】
本発明の一実施例によれば、メソッド、デバイス、システムに、外部ＩＤとやり取りする呼びを、企業内ＩＤに対する呼びと同様に処理できる設備が具備される。本発明の一実施例により、従来のそして既存のアプリケーションが、大幅なコストをかけることなく、動作可能となる。
【００１２】
本発明の一態様は、企業外（non-enterprise）ＩＤテーブルを提供する。このテーブルにより、企業内（enterprise）ユーザの外部ＩＤと企業内ＩＤとを関連づける。
【００１３】
本発明の他の態様は、通信リクエスト処理の間、企業外ＩＤテーブルをレベレッジし、その結果、コーラーの外部ＩＤをコーラーの企業内ＩＤで置換する。例えば、これは、企業外ＩＤテーブルのルックアップ機能を用いて行う。
【００１４】
本発明の他の態様は、コーラーのオリジナルＩＤをリクエスト内の何処か（即ち、リクエスト・パケット・ヘッダ）に挿入する。
【００１５】
本発明の他の態様によれば、リクエストをコーラーの認証プロキシ（authoritative proxy）にルーティングして、発信処理（origination processing）を行う。言い替えると、発信側の特徴起動が行われる。これにより、コーラーの企業内プロファイルにより定義された通信特徴にアクセスする。企業内プロファイルとは、通信プリファレンスとコーラ−用のルールを含む通信プロファイルである。前記のコーラ−用のルールは、企業内に含まれ、独自環境のない外部ネットワークなしには共有し得ないルールである。発信処理の後、リクエストは、コーラーの認証プロキシにルーティングされ、着信処理（terminal processing）が行われる。言い替えると、着信側の特徴起動が行われる。
【００１６】
本発明の他の態様によれば、発信側の処理を起動した後、コーリーの外部ＩＤをコーリーの企業内ＩＤで置換する。これは、企業外ＩＤのテーブル・ルックアップ機能を用いて行う。
【００１７】
本発明の他の態様によりば、リクエストをコーリーの認証プロキシにルーティングし、着信側の特徴機能を行う。
【００１８】
本発明の他の態様によれば、コーリーのオリジナルの外部ＩＤをリストアする。例えば、これは、企業外ＩＤのテーブル・ルックアップ機能を用いて行う。その後、リクエストを外部ゲートウェイ／トランクにルーティングし、呼びを外部ＩＤで着信する。
【００１９】
本発明の方法は、
（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、を有する。
前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む。
【００２０】
一実施例によれば、第１ＩＤは企業外ＩＤであり、第２ＩＤは企業内ＩＤである。これは、企業内ネットワークにインバウンド（inbound）する通信リクエストに適用される。他の実施例において、第１ＩＤは企業内ＩＤであり、第２ＩＤは企業外ＩＤである。これは、企業内ネットワークからアウトバウンド（outbound）する通信リクエストに適用される。
【００２１】
ユーザＩＤのマッピングは、企業内ユーザに、企業ベースの通信プリファレンスへのアクセスを提供するのに有効である。特に、企業内ユーザが、企業外通信デバイスを用いている場合に有益である。言い替えると、ネットワーク・バウンダリ・デバイス（network boundary device）が、ユーザの企業外ＩＤを企業内ＩＤに、特定の通信リクエスト用のＩＤマッピング・モジュールを用いて、マッピングすると、その通信リクエストは、あたかも、企業内デバイスから発信されたか、又は企業内デバイスに発信されたように、処理される。通信リクエストが、ネットワークを通過してアプリケーションに達すると、各アプリケーションは、ユーザＩＤを企業内ＩＤにマッピングし戻す必要はない。言い替えると、企業内ネットワーク内の全ての処理は、ネットワーク・バウンダリあるいは他のネットワーク・デバイスで行われるＩＤマッピングからの恩恵を受ける。
【００２２】
企業内ネットワークから発信された呼びに対しては、発信側の処理の後、被呼者（コーリー）のＩＤは、ネットワークのコア内で置換される。企業内ネットワークの外部から発信された呼びに対しては、被呼者のＩＤあるいは発呼者のＩＤは、ネットワーク・バウンダリで置換される。いずれの状況においても、そのリクエストは、着信側の認証サーバ（authritative server）に転送される。着信側の処理の終了後、コンタクト・リゾリューション（contact resolution：コンタクト先の発見処理）の間、オリジナルの被呼者はリストアされる。
【００２３】
本発明の一実施例において、ＩＤマッピングは、あるネットワークＩＤを他のネットワークＩＤにマッピングすることを含む。この場合、両方のＩＤは、企業内ＩＤでなくてもい。一実施例において、呼びは、第１の企業外ＩＤを有するものとして受領される。この第１の企業外ＩＤは、同一ユーザの企業内ＩＤにマッピングされる。その後、呼びが企業内ネットワーク外に転送して戻されると、そのユーザの企業内ＩＤは、別の企業外ＩＤにマッピングされて、被呼者との効率的な通信を実施する。かくして、あるタイプのネットワークＩＤを、呼びあるいは通信リクエストのコーラーの識別子フィールドに含めることが可能となる。
【００２４】
本明細者において、用語「通信リクエスト」は、あらゆる種類の通信セッション開始メッセージを含む。代表的な通信リクエストは、SIP INVITE、コール・セットアップ・メッセージ、ビデオ・コール・セットアップ・メッセージ、第１インスタント・メッセージ、リソース保存メッセージ、通信セッションを開始したり設定したりするメッセージ（例、音声、画像、テキスト、電子メール、ＩＭ）を含む。
【図面の簡単な説明】
【００２５】
【図１】本発明の一実施例による通信システムのブロック図。
【図２】本発明の一実施例による第１ユーザのＩＤを第２ユーザのＩＤにマッピングするのに用いられるデータ構造を表すブロック図。
【図３】本発明の一実施例によるアウトバンド・リクエスト処理の流れを表すブロック図。
【図４】本発明の一実施例によるインバウンド・リクエスト処理の流れを表すブロック図。
【発明を実施するための形態】
【００２６】
図１において、本発明の通信システム１００は、第１ネットワーク、例えば企業内ネットワーク１０４を含む。この企業内ネットワーク１０４は、複数の企業内通信機器１０８を、内部ネットワーク・デバイス１１２ａ、１１２ｂに接続する。この企業内通信機器１０８の一例は、企業内ネットワーク１０４を管理運営する企業により所有され、操作され、利用されるデバイスである。内部ネットワーク・デバイス１１２ａ、１１２ｂは、アプリケーション・サーバあるいはフューチャ・サーバに対応する。具体的には内部ネットワーク・デバイス１１２ａ、１１２ｂは、ＳＩＰアプリケーション・サーバ又はフューチャ・サーバに対応する。このサーバが、ＳＩＰ機能を企業内通信機器１０８に提供する。一般的には、内部ネットワーク・デバイス１１２ａ、１１２ｂは、所定のフューチャ（以下、「特徴」とも称する）とアプリケーションを、企業内ユーザに提供する。この企業内ユーザは、企業内通信機器１０８を利用してもしなくてもよい。内部ネットワーク・デバイス１１２ａ、１１２ｂは、フューチャ又はアプリケーションを提供することに加え、コンタクト・ソリューション機能を提供するか、内部ネットワーク・デバイス１１２ａ、１１２ｂで受領した様々な通信リクエストのアプリケーション・シーケンスを決定する。或いはその両方を行う。適切な内部ネットワーク・デバイス１１２ａ、１１２ｂの一例は、通信マネージャ、通信マネージャ・ブランチ、ＳＩＰイネーブル・サービス、システム・マネージャ、あるいはアバイア・インク（出願人.）により市販されている類似の装置である。
【００２７】
企業内ネットワーク１０４は、あらゆるタイプの公知の通信媒体、あるいは通信媒体の集合体であり、あらゆるタイプのプロトコルを用いて、エンドポイント間でメッセージを転送する。企業内ネットワーク１０４は、無線あるいは有線の通信技術を使用する。企業内ネットワーク１０４の一例は、ＬＡＮ、ＷＡＮ、ＳＩＰネットワーク、パケット交換ネットワーク、回路交換ネットワーク等である。さらに企業内ネットワーク１０４は、１つのネットワークに限定されず、様々なネットワークから構成されることもある。
【００２８】
企業内ネットワーク１０４は、外部ネットワーク１５２（例、企業外通信ネットワーク）にネットワーク・バウンダリ・デバイス１３６を介して、接続される。ネットワーク・バウンダリ・デバイス１３６の一例は、アバイア・インクに生産販売されているAura Session Managerである。外部ネットワーク１５２は、あらゆるタイプの企業外ネットワーク（例えば、安全が確保されていないか、あるいは企業の従業員により管理されていないネットワーク）を含む。インターネットは、信頼出来ない外部ネットワーク１５２の一例である。これは、世界中に広がるコンピュータや通信機器からなるＩＰネットワークを構築する。このネットワークは、電話システムあるいは他の手段を介して接続される。外部ネットワーク１５２の他の例は、ＰＯＴＳ、ＩＳＤＮ、ＰＳＴＮ、携帯電話通信ネットワーク等である。
【００２９】
本発明の一実施例によれば、企業内通信機器１０８と企業外通信機器１５６（即ち、企業に登録されていない通信デバイス、又は登録された企業のユーザが使用しない通信デバイス）との間の通信は、ユーザ・プリファレンス・テーブル１２０を介して実行される。外部通信機器１５６は、企業内通信機器１０８に類似し、いずれの装置もあらゆるタイプの公知の通信機器あるいはプロセッサを含む。例えば、これは、パソコン、ラップトップ、ＰＤＡ、携帯電話、スマートフォン、電話、アナログフォンあるいはＤＣＰフォンあるいはそれらの組み合わせである。１つの企業内通信機器１０８又は企業外通信機器１５６は、１人のユーザにより制御されるかあるいは１人のユーザに関連する、又は多くのユーザ（例えば、企業内のユーザが通信デバイスを、ユーザ・ネーム又はパスワードを入力することにより使えるようになる企業内通信デバイスで）で使用される。
【００３０】
通信機器１０８と１５６の複数のある機器は、同一のユーザに関連していてもよい。言い替えると、通信機器１０８と１５６は、１人のユーザに帰属し、様々な種類の通信デバイスに対応することができる。一例として、企業内ユーザが、企業内通信機器１０８又は企業外通信機器１５６を４台有し、それらが１人のユーザの個人用電話、会社用電話、個人用パソコン、電子メール装置にそれぞれ対応してもよい。かくして、企業内通信機器１０８のある機器は、企業内ネットワーク１０４に直接接続され、他の企業外通信機器１５６、例えば、電子メール装置は、外部ネットワーク１５２に、企業内のサービス・プロバイダを介して接続される。一実施例によれば、企業内のユーザに関連するが、企業内ネットワーク１０４には接続されていない通信デバイスは、企業内通信機器１０８として取り扱われ、企業内処理を受け入れ、通信される。別の構成として、各企業内通信機器１０８と企業外通信機器１５６は、異なるユーザが所有し操作してもよい。
【００３１】
通信機器１０８と１５６は、他の通信機器１０８と１５６との間で、ビデオ通信、オーディオ通信、テキスト通信、データ通信をサポートする。他の通信機器１０８と１５６と通信する通信機器１０８と１５６により使用される通信媒体の種類は、通信機器１０８と１５６で利用できる通信アプリケーションに依存する。
【００３２】
企業内ネットワーク１０４のある特徴は、それらが企業内通信機器１０８（これは信頼できない企業外通信機器１５６に接続されている）で、呼びを開始したり、呼びを受領したりする場合に、企業内ユーザにより利用可能となる。このような特徴は、内部ネットワーク・デバイス１１２ａ、１１２ｂで提供されるが、これはネットワーク・バウンダリ・デバイス１３６が、企業内ユーザのＩＤを既知の企業内ＩＤにマッピングするか否かに基づいて行われる。
【００３３】
内部ネットワーク・デバイス１１２ａ、１１２ｂには、アプリケーション１１６、ユーザ・プリファレンス・テーブル１２０、アプリケーション・シーケンシング・モジュール１２４、コンタクト・レゾルーション・モジュール１２８をそれぞれ具備し、通信特徴を企業内ユーザに与える。アプリケーション１１６は、通信特徴を企業内ユーザに提供できる。代表的なアプリケーション１１６は、ＥＣ−５００（携帯電話へのエクステンション）のアプリケーション、コール・セットアップ・アプリケーション、ボイスメール・アプリケーション、電子メール・アプリケーション、ビデオ・アプリケーション、テキスト・アプリケーション、カンファレンス・アプリケーション、あるいは他の公知の通信アプリケーションを含む。
【００３４】
ユーザ・プリファレンス・テーブル１２０は、企業内ネットワーク１０４の様々な企業内ユーザの通信プリファレンスを含む。一実施例によれば、特定の内部ネットワーク・デバイス１１２ａ、１１２ｂは、全ての企業内ユーザの所定のサブセットに対してのみユーザ・プリファレンスを含んでもよい。この構成において、特定のユーザに対する通信プリファレンスを有する内部ネットワーク・デバイス１１２ａ、１１２ｂは、そのユーザに対する認証プロキシ（authritative proxy）あるいは認証サーバ（authritative server）として見なされる。認証サーバ又は認証プロキシとして機能すると、内部ネットワーク・デバイス１１２ａ、１１２ｂは、通信リクエストを受領し、この通信リクエストに関連するユーザを、ユーザの企業内ＩＤにより、特定し、さらにユーザ・プリファレンス・テーブル１２０を参照することにより、ユーザの通信プリファレンスを決定する。
【００３５】
ユーザの通信プリファレンスが、内部ネットワーク・デバイス１１２ａ、１１２ｂにより決定されると、アプリケーション・シーケンシング・モジュール１２４が、起動され、アプリケーション・シーケンスを決定し、ユーザの特定した通信プリファレンスを得る。一実施例において、ユーザ・プリファレンス・テーブル１２０のコンテンツは、企業内ユーザにより、ウェブ・インターフェース又はオーディブル・インターフェースにより、提供される。
【００３６】
内部ネットワーク・デバイス１１２ａ、１１２ｂは、その後、通信リクエストをアプリケーション１１６にルーティングするが、デバイスは同一の装置内あるいは別の装置内であってもよく、さらにアプリケーションにより処理される。
【００３７】
コンタクト・レゾルーション・モジュール１２８が、通信リクエストに対するコンタクト・レゾルーション（コンタクト先の住所検索）を実行する。しかしこれは、通信リクエストがアプリケーション１１６により処理された後である、一実施例によれば、コンタクト・レゾルーション・モジュール１２８は、同一の認証サーバもしくはプロキシ内にあってもよい。他の実施例によれば、コンタクト・レゾルーション・モジュール１２８は、ユーザの通信プリファレンスを有する装置とは別の内部ネットワーク・デバイス１１２ａ、１１２ｂにあってもよい。いずれの場合も、コンタクト・レゾルーション・モジュール１２８は、特定のタイプのアプリケーションであり、これにより、通信のアラート（警報）に関連するユーザの通信プリファレンスを決定し、ユーザに関連する適切な通信デバイスに対し、警報を発したりしなかったりする。例えば、企業内ユーザが、企業内通信機器１０８を２台所有する場合は、コンタクト・レゾルーション・モジュール１２８は、通信リクエストを特定のユーザが受領した時に、企業内通信機器１０８の一方又は両方に警告を発するか否かを決定する。コンタクト・レゾルーションのフェーズが完了すると、通信リクエストは、適切な企業内通信機器１０８に転送されて、通信セッションを確立しようとする。
【００３８】
ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０と、企業外ＩＤテーブル１４４と、ルーティング・テーブル１４８とを有する。これにより、ネットワーク・バウンダリ・デバイス１３６は、企業内ネットワーク１０４に入る又はそこから出る呼び又は通信リクエストを解析し、呼び又は通信リクエスト内のどのエンティティが別のＩＤにマッピングされるＩＤを有すかを決定し、呼び又は通信リクエストを変更し、この別のＩＤを参照する。
【００３９】
内部ネットワーク・デバイス１１２ａ、１１２ｂは、呼びを解析し、コーラー又はコーリーのＩＤを、適宜の別のＩＤにマッピングする。その為、内部ネットワーク・デバイス１１２ａ、１１２ｂの一方又は両方は、ＩＤマッピング・モジュール１４０と、企業外ＩＤテーブル１４４と、ルーティング・テーブル１４８を有することもできる（図示してはいないが）。
【００４０】
ネットワーク・バウンダリ・デバイス１３６は、企業内ユーザの記録の一部を保持する企業内ネットワーク１０４に帰属するあらゆるタイプのデバイスを含む。ネットワーク・バウンダリ・デバイス１３６と見なされる代表的なデバイスは、ＳＩＰルーティング・エレメント、ユーザ・リレーション・エレメント、セッション・ボーダ・コントローラ（SBC's））、ゲートウェイ、プロキシ等である。ＳＩＰルーティング・エレメントは、ＳＩＰサイト間でのルーティングとダイヤルプランを確立し、企業内ネットワーク１０４又は信頼できない外部ネットワーク１５２への着信とそこからの発信を提供する。ユーザ・リレーション・エレメントは、ユーザを装置にバインドし、あるいはユーザをそのアプリケーションをバインドする。プロキシは、通信デバイスからの呼びの制御を実行し、アドレス変換を行うのセントラル・リポジトリ（ＩＰアドレス）として機能する。これらの要素は、共通サーバ上にあるか、あるいは複数のサーバに分散して配置される。
【００４１】
本発明の一実施例によれば、通信リクエスト内でユーザＩＤをマッピングすることは、必ずしもネットワーク・バウンダリ・デバイス１３６で行われるとは限らない。例えば、マッピングは、企業内ネットワーク１０４内のネットワーク・バウンダリ・デバイス１３６の「背後」で行われることもある。
【００４２】
ユーザＩＤのマッピングは、企業内ユーザに、企業ベースの通信プリファレンス（ユーザ・プリフェランス・テーブル１２０）へのアクセスを提供するのに有効である。特に、企業内ユーザが、企業外通信デバイス１０８を用いている場合に有益である。言い替えると、ネットワーク・バウンダリ・デバイス１３６が、ユーザの企業外ＩＤを企業内ＩＤに、特定の通信リクエスト用のＩＤマッピング・モジュール１４０を用いて、マッピングすると、その通信リクエストは、あたかも、企業内デバイスから発信されたか、又は企業内デバイスに発信されたように、処理される。通信リクエストが、ネットワークを通過してアプリケーション１１６，１２４，１２８に達すると、各アプリケーションは、ユーザＩＤを企業内ＩＤにマッピングし戻す必要はない。このステップは、ネットワーク・バウンダリ・デバイス１３６で実行され、その為、ＩＤマッピングは、アプリケーションにはとらわれず（application agnostic）、特定のアプリケーションではなく、通信セッションにバウンドされる。言い替えると、企業内ネットワーク１０４内の全ての処理は、ネットワーク・バウンダリ装置１３６で行われるＩＤマッピングからの恩恵を受ける。
【００４３】
ネットワーク・バウンダリ・デバイス１３６は、企業外ＩＤテーブル１４４とルーティング・テーブル１４８を含むものとして示されている。しかし、そのテーブルを埋めるのに必要な情報の全てあるいは一部が、企業内データベース１３２内にあり、この企業内データベース１３２が、ネットワーク・バウンダリ・デバイス１３６によりアクセスされる構成でもよい。テーブル内の情報は、企業内ユーザによりあるいは企業内ネットワーク管理者により変更あるいは再提供されると、データは、１つのポイント即ち企業内データベース１３２で変更可能であり、ネットワーク・バウンダリ・デバイス１３６は、必要に応じて、このような変更を取り出すことができる。別の構成として、企業外ＩＤテーブル１４４とルーティング・テーブル１４８は、個別に維持しても、ネットワーク・バウンダリ・デバイス１３６内で完全に維持してもよい。
【００４４】
一実施例によれば、企業外ＩＤテーブル１４４は、ユーザ又は管理者（アドミニストレータ）に提供されるテーブル（表）である。このテーブルは、ある企業内のユーザの企業ＩＤをそのユーザの企業外ＩＤにマッピングする情報を含む。ＩＤマッピング・モジュール１４０は、必要なＩＤマッピングを実行するルーティンであり、これにより、企業内ユーザは、企業内通信機器１０８を用いずに、企業内通信プリファレンスにアクセスできる。
【００４５】
ルーティング・テーブル１４８は、企業ＩＤを、その企業ＩＤに関連するユーザ用の認証サーバ又はプロキシにマッピングする情報を含む。この情報は、直接ネットワーク・バウンダリ・デバイス１３６に与えられるか、或いはウェブ・インターフェースあるいはオーディオ・インターフェースを介して与えられるか、あるいはユーザが企業データベース１３２内で情報を更新すると、自動的に与えられる。例えば、企業データベース１３２は、データの更新をネットワーク・バウンダリ・デバイス１３６に入れるか、あるいはネットワーク・バウンダリ・デバイス１３６が、周期的に企業データベース１３２にデータを入れて、最新の変更データを得ることができる。
【００４６】
言い替えると、ルーティング・テーブル１４８は、ある情報を含む。この情報は、ユーザを企業内ＡＯＲを介して特定し、企業内ＡＯＲを内部ネットワーク・デバイス１１２ａ、１１２ｂにマッピングする。ＳＩＰによりドメイン内のＡＯＲは、３つ以上のエイリアスを用いて表現できる。「ドメイン内（In-domain）」とは、あらゆるドメインのメンバー、あるいはその企業が認証されているサブドメインを意味する。各エイリアスは、同一のユーザを意味するが、異なる表現あるいはフォーマットである。１人のユーザ当たり３個のＡＯＲが割り当てられると、古いプライベート企業ネットワーク（classic private enterprise networks）、グローバルＰＳＴＮ（global PSTN）、インターネット等の最大のインターオペラビリティ（相互運用性）が得られる。一例として、ユーザ「ジョン・ドゥー（John Doe）」に対する３個のＡＯＲは、次の通りである。
【００４７】
3031234567@e.com：このフォーマットは、企業プライベート・ナンバリング・フォーマットと称する。ユーザ部分数列でなければならない。「＋」の文字を含まないが、@SIPdomain部分を含む。顧客は、E.164フォーマット（先頭の「＋」がない）を、自分のプライベート・ナンバリング・プランとして選択するか、プライベート・ナンバリング・プラン・エイリアスを全く有さないか、を選択できる。
【００４８】
+13031234567@e.com：このフォーマットは、E.164インターナショナル・フォーマットと称する。これは「＋」文字を最初の場所に含み、@SIPdomain部分を含む。
【００４９】
JohnDoe@e.com：このフォーマットは、Alphanumeric Handle Formatと称する。これは、@SIPdomain部分を含み、ユーザ側はE.164インターナショナル・フォーマットあるいはプライベート・ナンバリング・フォーマットであってはならない。
【００５０】
上記の３つのフォーマットは、企業内で正式に認められたものと見なされる。その理由は、これらはコア−・ルーティングが可能で、企業内ネットワーク１０４に渡って、あらゆるロケーション或いはサイトで、一人のユーザを唯一表すからである。これらのＡＯＲフォーマットとそれらのルーティングが具備される。この具備された情報の一部あるいは全てが、ルーティング・テーブル１４８又は企業外ＩＤテーブル１４４内で、保持される。
【００５１】
次の動作について説明する。ネットワーク・バウンダリ・デバイス１３６は、通信リクエストを、外部ネットワーク１５２又は企業内ネットワーク１０４のいずれかから受領する。その後、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストを解析し、この通信リクエスト内で特定されたエンティティを決定する。例えば、発信ユーザ（即ち、コーラー）と目標ユーザ（即ち、コーリー）と目標エンティティ（即ち、１つの通信リクエストが、特定のユーザではなく企業に向けられるようなコンタクト・センタ構成内のエンティティ）を決定する。ＩＤマッピング・モジュール１４０は、この情報を受け取り、通信リクエスト内で特定されたエンティティが、別のＩＤ（例えば、通信リクエスト内の企業外ＩＤを介して特定されたユーザ用の企業内ＩＤ、又は通信リクエスト内の企業内ＩＤを介して特定されたユーザ用の企業外ＩＤ）を有するか否かを決定するために、評価を行う。この評価は、企業外ＩＤテーブル１４４に記憶された情報との比較、ルーティング・テーブル１４８との比較、あるいは他のポリシー又はルールとの比較を含む。この決定に基づいて、ＩＤマッピング・モジュール１４０は、通信リクエスト内のヘッダーを別の識別子で置換する。この別の識別子は、企業内ネットワーク１０４又は信頼されていない外部ネットワーク１５２を通して、通信リクエストに続くものである。
【００５２】
図２において、企業外ＩＤテーブル１４４とルーティング・テーブル１４８の詳細を、一実施例に基づいてさらに説明する。
【００５３】
企業外ＩＤテーブル１４４は、企業外ＩＤを企業内ＩＤにマッピングする、あるいはその逆にマッピングするフィールドを有する。一実施例において、企業外ＩＤテーブル１４４は、企業外ＩＤフィールドと企業内ＩＤフィールドとを有する。このフィールドは、その企業ユーザとの様々なエンティティの関連あるいはノン・エンティティの関連情報で埋められる。一実施例において、ネットワーク・バウンダリ・デバイス１３６にある企業外ＩＤテーブル１４４は、全ての企業内ユーザのエントリと、企業内ＩＤと企業外ＩＤ間のマッピング・テーブルを有する。他の実施例においては、ネットワーク・バウンダリ・デバイス１３６にある企業外ＩＤテーブル１４４は、全ての企業内ユーザのサブセットのエントリのみを含む。
【００５４】
ルーティング・テーブル１４８は、企業内ユーザを認証サーバにマッピングするフィールドを含む。一実施例において、ルーティング・テーブル１４８は、企業内ＩＤフィールドと認証サーバ・フィールドとを含む。ルーティング・テーブル１４８の各列は、企業内ユーザ用の特定の企業内ＩＤを、そのユーザの認証サーバにマッピングする。企業内ＩＤ（例、ドメイン内のＡＯＲ）は、複数のエイリアスを有する。ユーザに対する各エイリアスは、同一の認証サーバにマッピングされる。
【００５５】
図２において、特定のユーザであるアリス（Alice）は、複数の企業外ＩＤ２０４ａ、ＩＤ２０４ｂを有する。それらのいずれも別の通信機器（個人の家庭用電話あるいは携帯電話）に関連づけられている。企業外ＩＤ２０４ａ、２０４ｂの全ては、同一の企業内ＩＤ２０８にマッピングされる。この企業内ＩＤ２０８は、ルーティング・テーブル１４８で参照され、そのユーザの認証サーバを特定する。
【００５６】
ＩＤマッピング・モジュール１４０は、通信リクエストを受領し、この通信リクエスト内のヘッダー内にあるユーザの第１ＩＤをそのユーザの第２ＩＤで置換する。企業外ＩＤテーブル１４４内のユーザの企業内ＩＤと企業外ＩＤは、別のＩＤを含み、それらはＩＤマッピング・モジュール１４０により交換される。この交換は、通信リクエストが企業内ネットワーク１０４へのインバウンドか、あるいは企業内ネットワーク１０４からのアウトバウンドかに基づいて、行われる。
【００５７】
図３において、企業内ネットワーク１０４から信頼できない外部ネットワーク１５２へのアウトバウンドの通信リクエストのステップを示す。このプロセスは、通信リクエストが企業内通信機器１０８により開始された時に始まる（ステップ３０４）。その後、企業により必要とされる場合には、ユーザの認証が実行される（ステップ３０８）。
【００５８】
その後、通信リクエストは、発信側の処理を受け、発呼者の認証サーバが、発呼者の通信プリファレンスに基づいて、適切なアプリケーション・シーケンスを決定する（ステップ３１２）。このアプリケーション・シーケンスは、ユーザ・プリファレンス・テーブル１２０内の発呼者の企業内ＩＤを参照し、発呼者のプリファレンスにマッチした、アプリケーション・シーケンスを決定することにより、決定される。
【００５９】
このフローは、通信リクエストをネットワーク・バウンダリ・デバイス１３６が受領した時に継続する。そこでＩＤマッピング・モジュール１４０が起動され、被呼者が企業外ＩＤテーブル１４４内にいるか否かが決定される（ステップ３１６）。被呼者の企業外ＩＤテーブル１４４内で一致が見出されない（いない）場合、通信リクエストは、外部ネットワーク１５２に行く。企業外ＩＤテーブル１４４で一致が見出された（いる）場合には、リクエストＵＲＩ（即ち、宛先側のヘッダー内の被呼者の企業外ＩＤ）のコンテンツを、企業外ＩＤテーブル１４４内で見出された被呼者の企業内ＩＤで置換する。さらに補足パラメータが、ヘッダーに追加され、宛先デバイスが外部デバイス（即ち、企業外通信機器）であると認定する。この特定データを通信リクエストに追加する詳細は、米国特許出願No.12/493,031号に記載されている。
【００６０】
被呼者のオリジナル（元）のＩＤ（即ち、企業外ＩＤ）は、通信リクエスト内に保持されるが、これは、その値をヘッダー内に挿入することにより、そして後の時点で呼び処理で取り出すことにより、行われる。
【００６１】
その後、呼びのフェーズは、着信側の処理に変わり、この通信リクエストは、被呼者の認証サーバにルーティングされる。これは、ルーティング・テーブル１４８を参照することにより決定される（ステップ３２０）。通信リクエストを被呼者の認証サーバで受領すると、実際の着信側の処理が開始され、認証サーバのアプリケーション・シーケンシング・モジュール１２４が、通信リクエストの着信側の処理の適切なアプリケーション・シーケンスを、被呼者の通信プリファレンスに基づいて、決定する（ステップ３２４）。
【００６２】
着信側の処理後、通信リクエストのフェーズは、コンタクト・レゾルーション・フェーズに切り替わり、このコンタクト・レゾルーションが、全てのコンタクト・アドレスに対し実行される（ステップ３２８）。このステップにおいて、リクエストＵＲＩの値は、コンタクト・アドレスで置換され、通信リクエストのフェーズは、エンドポイントに変わる。その後、通信リクエストは適切な装置に転送される。宛先装置の１つが、企業内ネットワーク１０４に対し内部にある企業内通信機器１０８の場合には、ルーティング・ロジックは、通信リクエストをコンタクト・アドレスに転送する（ステップ３３２）。宛先装置の１つが企業外通信機器１５６の場合には、通信リクエストは、適切なゲートウェイ／ＳＩＰトランクにルーティングされ（ステップ３３６）、その結果、通信リクエストは、所望の外部番号にルーティングされる（ステップ３４０）。一実施例において、タグ・フェーズが、通信リクエストのエンドポイントに変更されると、ルーティング・ロジックは、企業外エクステンションと他のテーブル・ルックアップ（これは、呼びのルーティングの間通常必要とされ）をバイパスする。さらに通信リクエストが企業内ネットワーク１０４を出ると、リクエストＵＲＩ内の値を、被呼者の元のＩＤで置換することは、利点があり、必要である。
【００６３】
図４において、このフローは、外部ネットワーク１５２から企業内ネットワーク１０４が受領したインバウンドの通信リクエストを処理するステップを表す。このフローは、通信リクエストの発信元が、外部ネットワーク１５２の一部であると開始する（即ち、企業外通信機器１５６により行われたものとして開始する（ステップ４０４）。来入した通信リクエストを、ゲートウェイ、ＳＩＰトランク、あるいは類似のネットワーク・バウンダリ・デバイス１３６で、受領する（ステップ４０８）。最初に、通信リクエストは、それに関連したフェーズを有さない。通信リクエストを受領すると、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストの発信者（コーラーあるいは発呼者）を見る。これは、企業外ＩＤテーブル１４４内のリクエストのPAI header、From header、或いは他の合意したupon headerで特定されたものである。
【００６４】
発信者の識別子のマッチが、企業外ＩＤテーブル１４４で見出されない場合には、フローは、通信リクエストのターゲット（コーリーあるいは被呼者）を調べ、被呼者の認証サーバを決定することにより、継続する。これは、ルーティング・テーブル１４８内のR-URI header, To header, 合意したupon headerで特定される。ＰＡＩヘッダーとＲｅｑｕｅｓｔ−ＵＲＩの詳細は、米国特許出願第１２／４９３，０３１号に開示されている。
【００６５】
その後、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６により、被呼者用の認証サーバに転送される。そこで、アプリケーション・シーケンスが被呼者用に決定される（ステップ４２８）。これにより、通信リクエストの着信処理が起動される。この着信処理は、通信リクエストをアプリケーション・シーケンスで指定されたアプリケーション１１６に流す。その結果、アプリケーション・シーケンス１１６は、この通信リクエストを処理することができる。その後、コンタクト・レゾルーションが、認証サーバにより実行され、通信リクエストが、被呼者に関連する適切な通信デバイスに転送される（ステップ４３２）。
【００６６】
ステップ４０８に戻って、マッチが企業外ＩＤテーブル１４４内の発呼者に対して見出されると、フローは、発呼者の元のＩＤを発呼者の企業内ＩＤにマッピングすることにより継続する（ステップ４１６）。このステップの間、発信者の企業ＡＯＲは、通信リクエストのＰＡＩヘッダー内の発信者の元の企業外ＩＤを置換する。さらに、通信リクエストにあるインディケータがマークされ、例えば、デバイス−タイプ＝エクスターナル（device-type=external）が付され、その通信リクエストは、企業外通信機器１５６から発信されたものと特定する。さらに、被呼者の元のＩＤが、通信リクエスト内にパラメータとして、通信リクエストのヘッダー内に挿入される。その後、発呼者の認証サーバは、ルーティング・テーブル１４８を参照することにより、決定される。
【００６７】
この呼びのフェーズが変更され、発信プロセスが開始され、この通信リクエストは認証サーバに転送される（ステップ４２０）。認証サーバは、アプリケーション・シーケンスを、発呼者の通信プリファレンスに基づいて決定し、この通信リクエストをシーケンス内の第１アプリケーションにルーティングして、アプリケーション・シーケンスを起動する。上記のアプリケーション・シーケンスは、アプリケーションを起動するステップを含む。第１アプリケーションが通信リクエストの処理を完了すると、この第１アプリケーションは、通信リクエストを第２アプリケーション（アプリケーション・シーケンスで特定される）に転送して、通信リクエストの処理を継続し、アプリケーション・シーケンスを完了する。
【００６８】
発信者のアプリケーション・シーケンスのアプリケーションが起動された後、本発明の方法は、通信リクエストを被呼者の認証サーバにルーティングする（ステップ４２４）ことにより、継続する。発呼者と被呼者の両方の認証サーバは、ネットワーク・バウンダリ・デバイス１３６による同一のステップ、あるいは別個のステップで決定できる。被呼者の認証サーバは、発呼者の認証サーバと同一でも異なってもよい。一般的に、発呼者と被呼者の両者にとって、１つの装置（即ち、ネットワーク・バウンダリ・デバイス１３６）で、認証サーバを決定することは、このステップを２段階で行うことより効率的である。その理由は、同一のルーティング・テーブル１４８は、発呼者と被呼者を参照することができるからである。その後、通信リクエストを着信処理するプロセスが開始する（ステップ４２８）。
【００６９】
図３、４で通信状況について議論する。この通信状況においては、通信リクエストは、以下のいずれかの理由で、企業内ネットワーク１０４の境界を横切る。第１の理由は、通信リクエストが企業内通信機器１０８により発信され、企業外通信機器１５６の方向に向けられるからである。第２の理由は、通信リクエストが企業外通信機器１５６により発信され、そして企業内通信機器１０８に向けられるからである。この状況において、通信リクエストは、通信の固有の性質により、ネットワーク・バウンダリ・デバイス１３６に遭遇する。
【００７０】
通信リクエストは、ある企業内通信機器１０８により発信され、別の企業内通信機器１０８に向けられる。この種の通信は、２人の特定された企業内ユーザ間で起こるために内部通信と称する。２人の企業内ユーザの内部の呼び（両方のユーザは、彼らの企業内のＡＯＲを外部の番号に結びつける）の操作については、説明を割愛する。
【００７１】
共有ライン・アピアランス（外部番号の付いた）を有するユーザが、通信リクエストを他の企業内ユーザに発信した場合には、この通信リクエストは、発呼者の認証サーバを通る。発信側の認証サーバ（即ち、発呼者の認証サーバ）は、発呼者に関連する発信アプリケーション・シーケンス１１６を起動する。ここでアプリケーション１１６の一つは、共有ライン・アピアランスを実行する。この段階において、呼びは、外部番号には延長されないが、企業内デバイスは、それを延長するオプションを有する。
【００７２】
着信側において、被呼者の認証サーバは、被呼者に関連するアプリケーション・シーケンスを開始する。被呼者は、共有ライン・アピアランス特徴を有するために、着信側のアプリケーション・シーケンス１１６の１つは、このロジックを実行する。
【００７３】
呼びを、外部番号を含む被呼者の別のコンタクト先に提供するために、アプリケーション１１６は、コンタクト・レゾルーションを最大活用して、呼びをフォークする（分ける）。これは、リクエストをコンタクト・レゾルーション・モジュール１２８に送ることにより行う。ただし、Ｒ−ＵＲＩを修正することはない。別の構成として、アプリケーションは、呼びそのものをフォークするが、これはＲ−ＵＲＩを別のコンタクト・アドレスで置換することで、行う。
【００７４】
２つの企業のユーザが関与する呼びのシナリオを以下議論する。両方のユーザは、企業内番号（即ち、企業内ＩＤ）と関連する外部番号（即ち、企業外ＩＤ）を有する。以下は２つの呼びの例である。
１．企業内のユーザが別のユーザを呼び出すが、これは、企業内の電話から被呼者であるユーザのＰＳＴＮの内線番号をダイヤルすることにより行う。
２．企業内のユーザが別のユーザを呼び出すが、これは企業内の電話のＰＳＴＮ内線から企業の企業電話番号をダイヤルすることにより行う。
【００７５】
この実施例において、２つの企業内ユーザは、アリス（Alice）とボブ（Bob）であるとする。彼らは、企業内ＩＤである28521223@avaya.com（Alice-eと称する）と25381324@avaya.com（Bob-eと称する）をそれぞれ有する。それに加えて両方とも、彼らの企業内特徴を外部の番号に延長する。アリスは携帯電話番号である＋17324215858（Alice-mと称する）と、ボブは携帯電話番号である＋13035657856（Bob-mと称する）をそれぞれＰＳＴＮの延長として有する。
【００７６】
第１のシナリオにおいて、アリスはボブの携帯電話に、自分の企業内電話から電話をかける。第２のシナリオは、アリスはボブの会社の電話番号に自分の携帯電話から電話をかける。第１のシナリオにおいて、Alice-eは、Bob-mへの呼びを開始すると、通信リクエストは、アリスの認証サーバを通る。呼びの発信であるために、認証サーバは、アリスの通信プリファレンスに関連する発信アプリケーションを起動する。発信側のアプリケーションの全てが起動された後、認証サーバは、呼びのフェーズを着信に切り替える。次の認証サーバを決定するために、アリスの認証サーバは、通信リクエストをネットワーク・バウンダリ・デバイス１３６に送り、このネットワーク・バウンダリ・デバイス１３６が、ＩＤマッピング・モジュール１４０を起動して、企業外ＩＤテーブル１４４内の被呼者（Bob-m）をルックアップする。別の構成として、アリスの認証サーバは、ＩＤマッピング・モジュール１４０を含み、このＩＤマッピング・モジュール１４０が、企業外ＩＤテーブル１４４のルックアップを実行してもよい。
【００７７】
Bob-mは、Bob-eに関連するので、エントリーは、企業外ＩＤテーブル１４４内に見出される。Bob-eを用いて、別のルックアップをルーティング・テーブル１４８内で実行して、ボブの認証サーバを決定する。リクエストをボブの認証サーバに送る前に、通信リクエストを更新して、呼びの特別な特徴を反映させる。
【００７８】
ボブの認証サーバにおいて、ボブの通信プロファイル（ユーザ・プリファレンス・テーブル１２０で決定された）に関連する着信アプリケーション１１６が起動される。アプリケーション１１６の１つが、共有ライン・アピアランス特徴を有するために、それはリクエストを、ボブが登録された複数のデバイスにフォークする（分ける）。例えば、Bob-eとBob-mに分ける。このアプリケーション１１６は、ボブの複数のコンタクト・アドレスを知ることになるが、これは、登録イベント・パッケージあるいは類似の登録アウェア・アプリケーションに登録することにより、行われる。別の構成として、アプリケーション１１６は、ボブの認証サーバのコンタクト・レゾルーション・モジュール１２８に依存して、リクエストをフォークする。アプリケーション１１６は、認証サーバがリクエストをフォークすることを、望む場合でも、それはＲ−ＵＲＩを変更することはない。着信側のアプリケーションの全てを起動した後、ボブの認証サーバは、コンタクト・レゾルーションを実行する。ＳＩＰデバイス（Bob-e）において、それはリクエストを登録されたアドレスに転送する。外部デバイス（Bob-m）において、それは呼びをアプリケーション１１６にハンドオーバーして、適切な外部ゲートウェイ／ＳＩＰトランクに分配する。
【００７９】
第２のシナリオにおいて、アリスは、自分の携帯電話（Alice-m）から、ボブの企業内ＡＯＲ（Bob-e）に電話をかける。この呼びのリクエストは、携帯電話網を通り、ネットワーク・バウンダリ・デバイス１３６に行く。このネットワーク・バウンダリ・デバイス１３６は、企業内ネットワーク１０４と外部ネットワーク１５２を接続する。ネットワーク・バウンダリ・デバイス１３６は、リクエストを受領し、ＩＤマッピング・モジュール１４０を起動する。リクエストが、フェーズ・タグを有さずに到着するので、コーラーＩＤ（Alice-m）は、企業外ＩＤテーブル１４４に対しチェックされる。（Alice-eに）関連が見出されると、別のルックアップがルーティング・テーブル１４８内で実行され、アリスの認証サーバを見出す。リクエストをアリスの認証サーバに転送する前に、フェーズ・タグがリクエストに挿入されて、呼びの発信処理を要求する。さらに通信リクエストを更新して、呼びの特別なネイチャーを反映させる。
【００８０】
アリスの認証サーバにおいて、アリスに関係する発信側のアプリケーションは、ユーザ・プリファレンス・テーブル１２０により決定され、起動される。アプリケーション１１６の１つが、共有ライン・アピアランスであるので、そのアプリケーション１１６は、通知を他の登録されたコンタクト先に送る。これによりアリスは、他の装置（例えば、Alice-e）からの呼びに参加できる。全ての発信側のアプリケーションが起動されると、アリスの認証サーバは、呼びのフェーズを着信に切り替える。次の認証サーバを決定するために、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６に渡され、そこでＩＤマッピング・モジュール１４０が起動されて、企業外ＩＤテーブル１４４内の被呼者（Bob-e）をルックアップする。別の構成として、アリスの認証サーバは、企業外ＩＤテーブル１４４内でルックアップを実行してもよい。
【００８１】
Bob-eは、このテーブル内で見出されないので、第２のルックアップが、ルーティング・テーブル１４８内で実行され、Bob-eの認証サーバを決定する。Bob-eは、企業内ユーザであるために、このルックアップは、ボブの認証サーバのアドレスを戻る。リクエストをボブの認証サーバに転送する前に、フェーズ・タグがリクエストに挿入されて、通信リクエストの着信処理を要求する。
【００８２】
ボブの認証サーバにおいて、ボブのプロファイルに関連する着信アプリケーションが、ユーザ・プリファレンス・テーブル１２０から決定され、起動される。ボブは複数のコンタクト、内部コンタクトと外部コンタクトを有するために、リクエストはフォークされ、企業のＳＩＰデバイス（Bob-e）と外部携帯電話（Bob-m）に着信する。ロジックとアプリケーション・ポリシーに基づいて、デバイスの１つ（通常、応答する第１デバイス）が呼び内に留まり、他のリクエストはドロップされる。
【００８３】
上記の通信シナリオは、企業内ネットワーク１０４の境界を自然と横切るか（例、呼びが企業内ネットワーク１０４に入るか出る）、あるいは共有ライン・アピアランスにより企業内ネットワーク１０４の境界を横切る。本発明の実施例は、第１の企業ユーザが、第２のユーザ（必ずしも企業内ユーザであるとは限らない）に、企業外通信機器１５６から電話をする例である。これによれば、企業内ユーザは、それ自身の企業外通信機器１５６を構築して、通常モードではなく企業内モードで動作する。これにより、通信リクエストは、直接ダイヤルされた番号に送られる。企業内モードにおいて、企業外通信機器１５６は、ダイヤルされた番号の付いた通信リクエストを生成し、この通信リクエストを企業内ネットワーク１０４に送り、そこで発信側の処理が行われる。これにより、ネットワーク・バウンダリ・デバイス１３６は、通信リクエストを受領し、それを上記のように処理する。発信側の処理が完了すると、通信リクエストは、ネットワーク・バウンダリ・デバイス１３６に送られ、その結果、それはダイヤルされた番号にルーティングされる。被呼者が企業内ＩＤを有さない場合には、通信リクエストは、直接被呼者に外部ネットワーク１５２を介して転送される。被呼者が企業内ＩＤを有する場合には、ネットワーク・バウンダリ・デバイス１３６は、ＩＤマッピング・モジュール１４０を起動して、通信リクエストの着信側処理が、企業内ネットワーク１０４で行われる。
【００８４】
本発明によれば、あるネットワークタイプを別のネットワークタイプに、マッピングできる。特に、ある種のネットワークタイプの識別子をコーラーの識別フィールドに、含めることができる。外部ＩＤを企業内ＩＤにマッピングし同一の外部ＩＤに戻す代わりに、本発明は、第１の外部ＩＤを企業内ＩＤにマッピングし、その後、この企業内ＩＤを第２の外部ＩＤにマッピングする。これにより、発呼者と被呼者は、企業内のネットワークから複数の外部ＩＤにアクセスし利用することができる。
【００８５】
上記の説明は電話の呼びに関するものであるが、本発明はそれに限定されない。例えば、本発明の一実施例は、プレゼンス・リクエスト、インスタント・メッセージ、あるいは他の通信サービスを含むＳＩＰリクエストに基づいて、利用可能である。
【００８６】
本発明の実施例は、テーブル・ルックアップを含むアセスメント・アルゴリズム（assessment algorithm）を用いる例で、説明したが、本発明はこれに限定されない。具体的には、本発明は、呼びのリクエストのＩＤが変更されたが、この変更を形成し適応するために、装置がいかに機能するかについてには関連しない。エンティティのＩＤを変更するか否かの決定は、決定アルゴリズム（decision algorithm）を用いて行うことができる。
【００８７】
用語「コンピュータで読み取り可能な媒体」とは、コンピュータが実行するプロセスを記憶する媒体或いは伝送媒体を意味する。媒体とは、非揮発性媒体、揮発性媒体、伝送媒体を意味する。非揮発性の媒体とは、ＮＶＲＡＭ、磁気ディスク又は光学ディスクである。揮発性媒体とは、ＤＲＡＭ、メインメモリを意味する。このコンピュータで読み取り可能な媒体の一般的なものとしては、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気ディスク、他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、パンチカード、ペーパーテープ等、更にＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカード、メモリチップ、或いはカートリッジ等がある。ｅ−ｍａｉｌ或いは他の自己保存型の情報アーカイブに付属したデジタルファイルは、記憶媒体に等価な分配型の記憶媒体であり、本発明でいう記憶媒体と見なすことができる。コンピュータで読み取り可能な媒体がデータベースとして構築された場合には、このデータベースは、あらゆる種類のデータベース、例えば関連型、階層型、オブジェクト志向型のいずれをも含む。
本明細書の「モジュール」「エージェント」「ツール」とは、ハードウエア、ソフトウエア、ファームウエア、或いはそれらの組み合わせである。構成要素に関連した機能を実行する。
ここで議論したフローチャートは、特定のイベントのシーケンスを例に説明するが、本発明の操作に影響を及ぼすことなく、これ等のシーケンスの変更、追加、一部省略も可能である。本発明のシステムと方法は、特殊コンピュータ、プログラムされたマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、他の集積回路ＤＳＰ、ハードワイヤド電子素子、論理素子、例えばディスクリートな要素回路、プログラム可能な論理回路、ゲートアレイ、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、特殊目的コンピュータ或いは他の手段で実現できる。
ここに開示された方法は、オブジェクト指向のソフトウエア開発環境を用いたソフトウエアと組み合わせて実現できる。このソフトウエア環境は、様々なコンピュータ又はワークステーションで使用されるポータブルなソースコードを提供する。別の構成として、開示されたシステムは、標準の論理回路又はＶＬＳＩデザインを用いて一部又は全部のハードウエアで実現できる。本発明のシステムを実行するのにハードウエア又はソフトウエアを用いるかは、システムに要求される速度と効率に依存する。特に使用される特定のソフトウエア、ハードウエアのシステム、マイクロプロセッサ又はマイクロコンピュータシステムに依存する。
ここに開示された方法は、コンピュータで読み取り可能な記憶媒体に記憶されたソフトウエアで実行され、コントローラとメモリとを有するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ等で実施される。これ等の実施例に於いては、本発明のシステムと方法は、パソコンに組み込まれたプログラムで実行できる。例えばアプレット、ＪＡＶＡ、ＣＧＩスクプリト、サーバ或いはコンピュータ、ワークステーションに記録された資源或いは専用の測定システムに組み込まれたルーチン等で実施できる。
【００８８】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。
【符号の説明】
【００８９】
１００ 通信システム
１０４ 企業内ネットワーク
１０８ 企業内通信機器
１１２ 内部ネットワーク・デバイス
１１６ アプリケーション
１２０ ユーザ・プリファレンス・テーブル
１２４ アプリケーション・シーケンシング・モジュール
１２８ コンタクト・レゾルーション・モジュール
１３２ 企業内データベース
１３６ バウンダリ・デバイス
１４０ ＩＤマッピング・モジュール
１４４ 企業外ＩＤテーブル
１４８ ルーティング・テーブル
１５２ 外部ネットワーク
１５６ 企業外通信機器
図２
左側
企業外ＩＤテーブル
外部エクステンション 企業内ＡＯＲ
右側
ルーティング・テーブル
企業内ＡＯＲ 認証サーバ
アリスの企業内取り扱い分
図３
宛先はＳＩＰデバイス
宛先は外部デバイス
図４
一致は有る
一致は無い
【特許請求の範囲】
【請求項１】
（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、
を有し、
前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む
ことを特徴とする方法。
【請求項２】
前記第１ＩＤは、企業外ＩＤを含み、
前記第２ＩＤは、企業内ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
（Ｄ)変更された通信リクエストを、前記第１ネットワークの第１の内部ネットワー・デバイスに転送するステップ
をさらに有する
ことを特徴とする請求項１記載の方法。
【請求項３】
前記（Ｂ)ステップと（Ｃ)ステップの少なくとも一方は、前記ネットワーク・デバイスで行なわれ、
企業外ＩＤテーブルが、前記第１ＩＤを前記第２ＩＤにマッピングする際に、使用され、前記ネットワーク・バウンダリ・デバイスで利用可能であり、
前記企業外ＩＤテーブルは、プロビジョニングにより、データが入れられ、
前記企業外ＩＤテーブルは、企業内ＩＤを、第１ネットワーク内で信頼されたユーザの企業外ＩＤにマッピングし、
ルーティング・テーブルが、前記（Ｄ)ステップで使用され、
前記ルーティング・テーブルは、ユーザの企業内ＩＤを、前記ユーザの認証サーバにマッピングし、
前記認証サーバは、第１の内部ネットワーク・デバイスを含む
ことを特徴とする請求項２記載の方法。
【請求項４】
変更の一部として、前記通信リクエストのヘッダー内の値は、第１ＩＤの代わりに第２ＩＤを参照して、変更され、
前記ヘッダーは、宛先側のヘッダーとコーラー側のヘッダーとコンタクト・ヘッダーの内の少なくとも１つを含み、
前記第１ユーザは、前記通信リクエストの発信者又は着信者の少なくとも一方であり、
前記第２ＩＤは、発信者と着信者の少なくとも一方の企業内ＩＤである
ことを特徴とする請求項１記載の方法。
【請求項５】
前記第１の内部ネットワーク・デバイスは、アプリケーション・シーケンス・モジュールを含み、
前記アプリケーション・シーケンス・モジュールは、前記通信リクエスト用のアプリケーション・シーケンスを前記第２ＩＤに基づいて決定し、前記通信リクエストを前記決定されたアプリケーション・シーケンス内の第１アプリケーションに転送し、これを前記第１アプリケーションが処理し、
前記第１アプリケーションは、前記通信リクエストの処理に関し、前記第２ＩＤを参照し、前記通信リクエストを、前記決定されたアプリケーション・シーケンス内の第２アプリケーションに転送し、
前記第２アプリケーションは、前記通信リクエストを処理するために、前記第１ＩＤを参照する
ことを特徴とする請求項２記載の方法。
【請求項６】
前記変更された通信リクエストは、前記ヘッダー内に前記第２ＩＤを有し、非ヘッダー部分に前記第１ＩＤを保持し、
（Ｅ)前記通信リクエストが前記第１ネットワークにより処理された後、前記変更された通信リクエストを、前記第１ネットワークのネットワーク・バウンダリ・デバイスで受領するステップと、
（Ｆ)前記ネットワーク・バウンダリ・デバイスで、前記第２ＩＤを、前記ヘッダー内で、第１ＩＤで置換するステップと、
（Ｇ)前記ヘッダー内に第１ＩＤを有する２回変更された通信リクエストを、前記第１ネットワーク外のデバイスに転送するステップ
を有する
ことを特徴とする請求項２記載の方法。
【請求項７】
前記第１ＩＤは、企業内ＩＤを含み、
前記第２ＩＤは、企業外ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
（Ｈ)前記変更された通信リクエストを、第１ネットワーク外のデバイスに転送するステップ
をさらに有する
ことを特徴とする請求項１記載の方法。
【請求項８】
第１ネットワーク・バウンダリ・デバイスを有する第１ネットワークを有する通信システムにおいて、
前記第１ネットワーク・バウンダリ・デバイスは、前記第１ネットワークと第２ネットワークとの間に配置され、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ａ)通信リクエストを受領し、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定し、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングし、
前記マッピングは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更する
ことを特徴とする通信システム。
【請求項９】
前記第１ＩＤは、企業外ＩＤを含み、
前記第２ＩＤは、企業内ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｄ）変更された通信リクエストを、前記第１ネットワークの第１の内部ネットワー・デバイスに転送する
ことを特徴とする請求項８記載の通信システム。
【請求項１０】
変更の一部として、前記通信リクエストのヘッダー内の値は、第１ＩＤの代わりに第２ＩＤを参照して、変更され、
前記ヘッダーは、宛先側のヘッダーとコーラー側のヘッダーとコンタクト・ヘッダーの内の少なくとも１つを含み、
前記第１ユーザは、前記通信リクエストの発信者又は着信者の少なくとも一方であり、
前記第２ＩＤは、発信者と着信者の少なくとも一方の企業内ＩＤであり、
前記第１の内部ネットワーク・デバイスは、アプリケーション・シーケンス・モジュールを含み、
前記アプリケーション・シーケンス・モジュールは、前記通信リクエスト用のアプリケーション・シーケンスを前記第２ＩＤに基づいて決定し、前記通信リクエストを前記決定されたアプリケーション・シーケンス内の第１アプリケーションに転送し、これを前記第１アプリケーションが処理し、
前記第１アプリケーションは、前記通信リクエストの処理に関し、前記第２ＩＤを参照し、前記通信リクエストを、前記決定されたアプリケーション・シーケンス内の第２アプリケーションに転送し、
前記第２アプリケーションは、前記通信リクエストを処理するために、前記第１ＩＤを参照し、
前記変更された通信リクエストは、前記ヘッダー内に前記第２ＩＤを有し、非ヘッダー部分に前記第１ＩＤを保持し、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｅ)前記通信リクエストが前記第１ネットワークにより処理された後、前記変更された通信リクエストを、前記第１ネットワークのネットワーク・バウンダリ・デバイスで受領し、
（Ｆ)前記ネットワーク・バウンダリ・デバイスで、前記第２ＩＤを、前記ヘッダー内で、第１ＩＤで置換し、
（Ｇ)前記ヘッダー内に第１ＩＤを有する２回変更された通信リクエストを、前記第１ネットワーク外のデバイスに転送し、
前記第１ＩＤは、企業内ＩＤを含み、
前記第２ＩＤは、企業外ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｈ)前記変更された通信リクエストを、第１ネットワーク外のデバイスに転送する
ことを特徴とする請求項９記載の通信システム。
【請求項１】
（Ａ)通信リクエストを第１ネットワークのネットワーク・デバイスで受領するステップと、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定するステップと、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングするステップと、
を有し、
前記（Ｃ)ステップは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更するステップを含む
ことを特徴とする方法。
【請求項２】
前記第１ＩＤは、企業外ＩＤを含み、
前記第２ＩＤは、企業内ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
（Ｄ)変更された通信リクエストを、前記第１ネットワークの第１の内部ネットワー・デバイスに転送するステップ
をさらに有する
ことを特徴とする請求項１記載の方法。
【請求項３】
前記（Ｂ)ステップと（Ｃ)ステップの少なくとも一方は、前記ネットワーク・デバイスで行なわれ、
企業外ＩＤテーブルが、前記第１ＩＤを前記第２ＩＤにマッピングする際に、使用され、前記ネットワーク・バウンダリ・デバイスで利用可能であり、
前記企業外ＩＤテーブルは、プロビジョニングにより、データが入れられ、
前記企業外ＩＤテーブルは、企業内ＩＤを、第１ネットワーク内で信頼されたユーザの企業外ＩＤにマッピングし、
ルーティング・テーブルが、前記（Ｄ)ステップで使用され、
前記ルーティング・テーブルは、ユーザの企業内ＩＤを、前記ユーザの認証サーバにマッピングし、
前記認証サーバは、第１の内部ネットワーク・デバイスを含む
ことを特徴とする請求項２記載の方法。
【請求項４】
変更の一部として、前記通信リクエストのヘッダー内の値は、第１ＩＤの代わりに第２ＩＤを参照して、変更され、
前記ヘッダーは、宛先側のヘッダーとコーラー側のヘッダーとコンタクト・ヘッダーの内の少なくとも１つを含み、
前記第１ユーザは、前記通信リクエストの発信者又は着信者の少なくとも一方であり、
前記第２ＩＤは、発信者と着信者の少なくとも一方の企業内ＩＤである
ことを特徴とする請求項１記載の方法。
【請求項５】
前記第１の内部ネットワーク・デバイスは、アプリケーション・シーケンス・モジュールを含み、
前記アプリケーション・シーケンス・モジュールは、前記通信リクエスト用のアプリケーション・シーケンスを前記第２ＩＤに基づいて決定し、前記通信リクエストを前記決定されたアプリケーション・シーケンス内の第１アプリケーションに転送し、これを前記第１アプリケーションが処理し、
前記第１アプリケーションは、前記通信リクエストの処理に関し、前記第２ＩＤを参照し、前記通信リクエストを、前記決定されたアプリケーション・シーケンス内の第２アプリケーションに転送し、
前記第２アプリケーションは、前記通信リクエストを処理するために、前記第１ＩＤを参照する
ことを特徴とする請求項２記載の方法。
【請求項６】
前記変更された通信リクエストは、前記ヘッダー内に前記第２ＩＤを有し、非ヘッダー部分に前記第１ＩＤを保持し、
（Ｅ)前記通信リクエストが前記第１ネットワークにより処理された後、前記変更された通信リクエストを、前記第１ネットワークのネットワーク・バウンダリ・デバイスで受領するステップと、
（Ｆ)前記ネットワーク・バウンダリ・デバイスで、前記第２ＩＤを、前記ヘッダー内で、第１ＩＤで置換するステップと、
（Ｇ)前記ヘッダー内に第１ＩＤを有する２回変更された通信リクエストを、前記第１ネットワーク外のデバイスに転送するステップ
を有する
ことを特徴とする請求項２記載の方法。
【請求項７】
前記第１ＩＤは、企業内ＩＤを含み、
前記第２ＩＤは、企業外ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
（Ｈ)前記変更された通信リクエストを、第１ネットワーク外のデバイスに転送するステップ
をさらに有する
ことを特徴とする請求項１記載の方法。
【請求項８】
第１ネットワーク・バウンダリ・デバイスを有する第１ネットワークを有する通信システムにおいて、
前記第１ネットワーク・バウンダリ・デバイスは、前記第１ネットワークと第２ネットワークとの間に配置され、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ａ)通信リクエストを受領し、
（Ｂ)前記通信リクエスト内で特定された第１ユーザの第１ＩＤを決定し、
（Ｃ)前記第１ユーザの第１ＩＤを前記第１ユーザの第２ＩＤにマッピングし、
前記マッピングは、第１ユーザを特定するために、第２ＩＤで前記通信リクエストを変更する
ことを特徴とする通信システム。
【請求項９】
前記第１ＩＤは、企業外ＩＤを含み、
前記第２ＩＤは、企業内ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｄ）変更された通信リクエストを、前記第１ネットワークの第１の内部ネットワー・デバイスに転送する
ことを特徴とする請求項８記載の通信システム。
【請求項１０】
変更の一部として、前記通信リクエストのヘッダー内の値は、第１ＩＤの代わりに第２ＩＤを参照して、変更され、
前記ヘッダーは、宛先側のヘッダーとコーラー側のヘッダーとコンタクト・ヘッダーの内の少なくとも１つを含み、
前記第１ユーザは、前記通信リクエストの発信者又は着信者の少なくとも一方であり、
前記第２ＩＤは、発信者と着信者の少なくとも一方の企業内ＩＤであり、
前記第１の内部ネットワーク・デバイスは、アプリケーション・シーケンス・モジュールを含み、
前記アプリケーション・シーケンス・モジュールは、前記通信リクエスト用のアプリケーション・シーケンスを前記第２ＩＤに基づいて決定し、前記通信リクエストを前記決定されたアプリケーション・シーケンス内の第１アプリケーションに転送し、これを前記第１アプリケーションが処理し、
前記第１アプリケーションは、前記通信リクエストの処理に関し、前記第２ＩＤを参照し、前記通信リクエストを、前記決定されたアプリケーション・シーケンス内の第２アプリケーションに転送し、
前記第２アプリケーションは、前記通信リクエストを処理するために、前記第１ＩＤを参照し、
前記変更された通信リクエストは、前記ヘッダー内に前記第２ＩＤを有し、非ヘッダー部分に前記第１ＩＤを保持し、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｅ)前記通信リクエストが前記第１ネットワークにより処理された後、前記変更された通信リクエストを、前記第１ネットワークのネットワーク・バウンダリ・デバイスで受領し、
（Ｆ)前記ネットワーク・バウンダリ・デバイスで、前記第２ＩＤを、前記ヘッダー内で、第１ＩＤで置換し、
（Ｇ)前記ヘッダー内に第１ＩＤを有する２回変更された通信リクエストを、前記第１ネットワーク外のデバイスに転送し、
前記第１ＩＤは、企業内ＩＤを含み、
前記第２ＩＤは、企業外ＩＤを含み、
前記第１ネットワークは、企業内ネットワークを含み、
前記第１ネットワーク・バウンダリ・デバイスは、
（Ｈ)前記変更された通信リクエストを、第１ネットワーク外のデバイスに転送する
ことを特徴とする請求項９記載の通信システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１１−６６８８８（Ｐ２０１１−６６８８８Ａ）
【公開日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２０５４０５（Ｐ２０１０−２０５４０５）
【出願日】平成２２年９月１４日（２０１０．９．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＪＡＶＡ
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
【公開日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願番号】特願２０１０−２０５４０５（Ｐ２０１０−２０５４０５）
【出願日】平成２２年９月１４日（２０１０．９．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
２．ＪＡＶＡ
【出願人】（５０８２１４０１９）アバイア インク． (75)
【Ｆターム（参考）】
[ Back to top ]