(57)【要約】ローカルのポイントオブプレゼンスでコールに応答し、サービスを提供し、待ち行列に入れ、経路指定することができる分散されたコール・センタ・システムを有して、インバウンドのコール・センタおよびアウトバウンドのコール・センタに関する通信コストを削減し、オペレーション上の効率を向上させる仮想インテリジェント・ネットワーク（ＶＩＮ）。ＶＩＮは、コール・センタが常駐するビジネス・ロケーションにおける構内コール・センタ・ゲートウェイにユーザ制御された仮想私設ネットワークによって接続された、コール発信元の点に近いポイントオブプレゼンスに分散された１組のポイントオブプレゼンスコール・センタ・ゲートウェイを含む。
2004500754.tif 000002
【特許請求の範囲】
【請求項１】
Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）タグとしてネットワークのノード間で渡されるコマンドの使用を介して遠隔／データ通信ネットワーク内のコール・フローを管理することを含む方法。
【請求項２】
管理することが、応答すること、終了させること、受け入れること、経路指定すること、開始すること、ブリッジすること、ブリッジ解除すること、会議を行うこと、および／または接続解除することを含む請求項１に記載の方法。
【請求項３】
ネットワークのノードの少なくとも１つが、前記ネットワークの他のノードにＸＭＬタグを送信し、かつ他のノードからＸＭＬタグを受信するように構成されたコール・フロー・マネージャ・アプリケーションをホストするＷＥＢサーバを含むを含む請求項２に記載の方法。
【請求項４】
管理することが、ネットワーク内のコール・フロー・マネージャにおいてコールの通知を受け取ること、およびＸＭＬタグの１つまたは複数の使用を介してコールが受け入れられるべきか否かを指示することを含む請求項１に記載の方法。
【請求項５】
管理することが、ＸＭＬタグのいくつかを使用して発行された１つまたは複数のコマンドに応答してコールを第２のコールにブリッジすることをさらに含む請求項４に記載の方法。
【請求項６】
第２のコールが、ＸＭＬタグの少なくとも１つを使用して発行された１つまたは複数のコマンドに応答してコール・センタにおいて開始されるプロキシ・コールである請求項５に記載の方法。
【請求項７】
第２のコールが、第２のコールのエンドポイントに近いポイントオブプレゼンスにおいて開始される請求項５に記載の方法。
【請求項８】
第２のコールが、ＸＭＬタグの少なくとも１つを使用して発行されたコマンドに応答して開始される請求項７に記載の方法。
【請求項９】
コールが受け入れられた場合、前記コールが、ネットワーク内のコンピュータ・リソース上でホストされる対話式音声応答（ＩＶＲ）アプリケーションの制御下でさらに管理される請求項４に記載の方法。
【請求項１０】
ＩＶＲアプリケーションが、ＸＭＬタグの様々なタグを使用して、コールが受信されたネットワークのノードにおいて実行される発呼者対話オペレーションに関連するコマンドを発行することにより、前記コールを管理する請求項９に記載の方法。
【請求項１１】
ＩＶＲアプリケーションによって発行されるコマンドの少なくとも１つが、コールが受信されたネットワークのノードが、前記コールを終了するための命令をそこで探し出すことができるアドレスに関する情報を含む請求項１０に記載の方法。
【請求項１２】
ＩＶＲアプリケーションによって発行されるコマンドの少なくとも１つが、コールが受信されたネットワークのノードが、メッセージを再生するための命令をそこで探し出すことができるアドレスに関する情報を含む請求項１０に記載の方法。
【請求項１３】
遠隔／データ通信ネットワークによって使用されるための、Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）で書かれたコール・フロー管理コマンドを含む１組のコンピュータ可読命令。
【請求項１４】
ネットワークの少なくとも２つのノードを相互接続する媒体上でトランスポートされる電気信号またはその他の信号として実装される請求項１３に記載のコンピュータ可読命令。
【請求項１５】
コンピュータ可読媒体上に実装される請求項１３に記載のコンピュータ可読命令。
【請求項１６】
Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）で表現された１組のコンピュータ可読命令の使用を介して互いに通信することによってコール管理オペレーションを提供するように構成された２つ以上のノードを含むネットワーク。
【請求項１７】
命令が、個々のＸＭＬページ上のコール管理で実行される一連のオペレーションのとして表現される請求項１６に記載のネットワーク。
【請求項１８】
１つまたは複数のユーザ指定のＷＥＢアプリケーションを介して第２のコール・センタに指示してインバウンドのコールにサービスを提供するようにさせることと、
前記アプリケーションを介して第１のコール・センタに指示して前記センタ内で接続を確立するようにさせることと、
前記第１のコール・センタ内で接続が確立されたとき、前記アプリケーションの制御下で前記第２のコール・センタからの前記インバウンドのコールをブリッジすることとを含む方法。
【請求項１９】
ＷＥＢアプリケーション・サーバ、ローカル・コール・センタ、および遠隔コール・センタが、データ・ネットワークを介して通信する請求項１８に記載の方法。
【請求項２０】
前記遠隔コール・センタが、広域に分散された複数のコール・センタから選択される請求項１８に記載の方法。
【請求項２１】
前記ユーザ指定のアプリケーションが、ＷＥＢアプリケーション・サーバ上で実行される請求項１８に記載の方法。
【請求項２２】
前記ユーザ指定のアプリケーションが、前記ローカル・コール・センタおよび前記遠隔コール・センタのコール・フローの挙動および音声応答の挙動を制御する請求項１８に記載の方法。
【請求項２３】
前記ユーザ指定のアプリケーションが、複数の遠隔コール・センタ間におけるコール・フローの均等な分散を実現するようにコール・センタを選択することにより、ローカル・コール・センタおよび前記遠隔コール・センタのコール・フローの挙動を制御する請求項２２に記載の方法。
【請求項２４】
前記ユーザ指定のアプリケーションが、対話式音声応答ベースの自動化されたサービスを選択し、前記サービスを実行するようにローカル・センタに要求することによって音声応答の挙動を制御する請求項２２に記載の方法。
【請求項２５】
前記ユーザ指定のアプリケーションが、ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）を介して前記コール・フローの挙動および音声応答の挙動を制御する請求項２２に記載の方法。
【請求項２６】
前記ユーザ指定のアプリケーションが、コール・フロー管理（ＣＦＭ）ＷＥＢアプリケーションおよび対話式音声応答（ＩＶＲ）ＷＥＢアプリケーションである請求項２２に記載の方法。
【請求項２７】
前記ユーザ指定のアプリケーションが、外部のインターネット・データ・センタにおいてホストされるＷＥＢアプリケーション・サーバ上に配備される請求項２３に記載の方法。
【請求項２８】
ユーザ指定のアプリケーションが、発呼者のアカウント情報を収集すること、遠隔コール・センタを選択すること、およびインバウンドのコールを前記選択された遠隔コール・センタに経路指定することをさらに含む請求項１８に記載の方法。
【請求項２９】
ローカル・コール・センタが、コール発信の点の近くでコールを代行受信して応答することにより、前記インバウンドのコールに対するサービスを提供し、対話式音声応答ベースの自動化されたサービスを提供し、かつ遠隔コール・センタが、前記コールにサービスを提供するように応対可能になるまで前記コールを保留にして待ち行列に入れる請求項１８に記載の方法。
【請求項３０】
１つまたは複数のユーザ指定のアプリケーションを介して、ローカル・コール・センタによるコールの待ち行列化を要求するステップと、
１つまたは複数のユーザ指定のアプリケーションを介して、コール保留時間中の音声応答アプリケーションの実行を要求するステップと、
１つまたは複数のユーザ指定のアプリケーションを介して、前記待ち行列に入れられたコールに割込みを行い、ローカル・コール・センタに命令して前記コールを選択された応答リソースに転送させるステップとをさらに含む請求項２９に記載の方法。
【請求項３１】
コールを一方のロケーションから他方のロケーションに転送する必要がある場合、前記ユーザ指定のアプリケーションが、ローカル・コール・センタに要求して前記一方のロケーションにおける応答リソースに対する接続を解放させ、前記他方のロケーションにおいて接続を行わせる請求項３０に記載の方法。
【請求項３２】
ユーザ指定のアプリケーションが、遠隔コール・センタに要求して遠隔コール・センタの待ち行列内にプロキシ・コールを発信させることをさらに含む請求項１８に記載の方法。
【請求項３３】
遠隔コール・センタが、ユーザ指定のアプリケーションの要求に応答してプロキシ・コールを発信し、オペレータの応対可能性に関して前記プロキシ・コールの進行を監視し、前記進行を前記ユーザ指定のアプリケーションに通知することをさらに含む請求項３２に記載の方法。
【請求項３４】
オペレータが応対可能であることが遠隔コール・センタから通知されたとき、ユーザ指定のアプリケーションが、ローカル・コール・センタに指示して保留されているコールを前記遠隔コール・センタに転送するようにさせることをさらに含む請求項３３に記載の方法。
【請求項３５】
１つまたは複数のユーザ指定のアプリケーションを介してローカル・コール・センタに指示してアウトバウンドのコールを発信するようにさせることと、
前記アプリケーションを介して遠隔コール・センタに指示して前記センタ内で接続を確立するようにさせることと、
前記アプリケーションの制御下で前記アウトバウンドのコールを既存のコールとブリッジすることとを含む方法。
【請求項３６】
１つまたは複数のユーザ指定のアプリケーションを介して１組の代替の長距離番号を指定することと、
前記１組の代替の長距離番号から第１の長距離番号を選択することと、
１つまたは複数のユーザ指定のアプリケーションを介して第１の選択された番号にローカルなコール・センタに指示して第１のコールを行うようにさせることと、
前記第１の選択された番号に対する前記第１のコールの確立が不成功であった場合、他の選択される番号のどれかに対するコールを完遂することができるまで前記１組の代替の長距離番号から他の長距離番号を選択することとをさらに含む請求項３５に記載の方法。
【請求項３７】
音声メッセージを選択することと、コール・センタに指示して前記音声メッセージをエンド・ユーザに送達するようにさせることとをさらに含む請求項３５に記載の方法。
【請求項３８】
前記音声メッセージが、サービス提供エージェントに接続されるオプションをエンド・ユーザに提供する請求項３７に記載の方法。
【請求項３９】
エンド・ユーザが、前記オプションを選択することと、ユーザ指定のアプリケーションが、遠隔コール・センタに指示してサービス提供エージェントとの接続を確立するようにさせ、前記接続が確立されたときにコールを前記エンド・ユーザにブリッジするようにさせることとをさらに含む請求項３８に記載の方法。
【請求項４０】
コールにサービスを提供するために広域に分散された複数の遠隔コール・センタと、
コールに応答するローカル・コール・センタと、
ローカル・コール・センタに指示して、遠隔コール・センタ内で接続が確立されるまでコールにサービスを提供するようにさせるユーザ指定のアプリケーションをホストするように構成されたＷＥＢベースのアプリケーション・サーバとを含む仮想インテリジェント・ネットワーク・システム。
【請求項４１】
ローカル・コール・センタ、複数の遠隔コール・センタ、およびＷＥＢアプリケーション・サーバを接続するデータ・ネットワークをさらに含む請求項４０に記載のシステム。
【請求項４２】
データ・ネットワークが、接続−トランスポート・プロトコルを提供する仮想私設ネットワークである請求項４１に記載のシステム。
【請求項４３】
ＷＥＢネットワーク管理ツールを使用して仮想私設ネットワークの発見、構成、監視、および管理を行う前記データ・ネットワークに接続されたネットワーク・オペレーション・センタをさらに含む請求項４２に記載のシステム。
【請求項４４】
インターネット・プロトコル（ＩＰ）電話、メディア・ゲートウェイ制御プロトコル（ＭＧＣＰ）、ゲートキーパ・プロトコル、および遠距離音声通信のための仮想私設ネットワークをさらに含む請求項４３に記載のシステム。
【請求項４５】
ローカル・アクセス・ネットワークのエッジに物理的に位置するゲートウェイに対して企業ネットワークによって提供されるコール制御機構の使用を介して、前記ローカル・アクセス・ネットワークの前記エッジまで企業アプリケーションを拡張することを含む方法。
【請求項４６】
コール制御機構が、コール制御機能に関連するＸＭＬタグを含む請求項４５に記載の方法。
【請求項４７】
ゲートウェイが、複数の企業ネットワーク間で共用される請求項４５に記載の方法。
【請求項４８】
ローカル・アクセス・ネットワークを介して受信されたコールが、ゲートウェイにおいて終了される請求項４５に記載の方法。
【請求項４９】
コールが、中継ネットワークを介してローカル・アクセス・ネットワークから企業ネットワークまでブリッジされる請求項４８に記載の方法。
【請求項５０】
中継ネットワークが、回線交換長距離電話ネットワーク、ボイス・オーバーＩＰネットワーク、ボイス・オーバーＡＴＭネットワーク、またはボイス・オーバー・フレーム・リレー・ネットワークのどれかである請求項４９に記載の方法。
【請求項５１】
ローカル・アクセス・ネットワークが、セルラー電話ネットワーク、無線ネットワーク、または有線ネットワークのどれかを含む請求項４８に記載の方法。
【発明の詳細な説明】
【０００１】
（関連出願）
本出願は、Ｐｒｅｍ　ＵｐｐａｌｕｒｕおよびＭｕｋｅｓｈ　Ｓｕｎｄａｒａｍによって１９９９年２月１２日に出願され、本発明の譲受人に譲渡された「Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ　Ｃａｌｌ　Ｃｅｎｔｅｒ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ」という名称の同時係属出願、第０９／２４９３９５号に関連する一部継続出願である。
【０００２】
（発明の分野）
本発明は、テレコミニュケーションの分野に関し、より詳細には、コール・センタとの間の電話コールの管理に関する。
【０００３】
（背景）
図１は、発信元のローカル公衆交換テレコミニュケーション・ネットワーク（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ）１０６、長距離ネットワーク１１４、および終端のローカルＰＳＴＮ１０６を介してエンド・ユーザ１１６をビジネス・コール・センタ１０８に接続するビジネス・コール・センタを示す機能図である。ビジネス・コール・センタは、通常、コール・センタ内でインバウンドの顧客コールに応答し、サービスを提供し、待ち行列に入れ、経路指定するために、完全なビジネス・ソリューションに複数のシステム構成要素を統合することによって構成される。これらのシステム構成要素には、顧客サービス・アプリケーションまたはコール・センタ・エージェント１０４のためのヘルプ・デスク・アプリケーションに加えて、構内交換機（ＰＢＸ）１０２、自動コール分配器（ＡＣＤ）１１２、および対話式音声応答（ＩＶＲ）システム１１０などが含まれる。また、多くのコール・センタは、インテリジェントなコール経路指定を提供するためにコンピュータ電話統合（ＣＴＩ）サーバ１１８も配備している。
【０００４】
従来、複数のベンダが、システム構成要素を供給し、システム統合を行う人が、その構成要素をソリューションにまとめ、コールにサービスを提供する際のビジネス依存論理を実施するように構成要素をプログラミングした。ただし、コールにサービスを提供するためには、この従来の解決策では、Ａｍｅｒｉｃａｎ  Ｔｅｌｅｐｈｏｎｅ  ＆  Ｔｅｌｅｇｒａｐｈ（ＡＴ＆Ｔ）、Ｍｉｃｒｏｗａｖｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｉｎｃｏｒｐｏｒａｔｅｄ（ＭＣＩ）、ＷｏｒｌｄＣｏｍ、およびＳｐｒｉｎｔなどの企業によって提供される長距離ネットワーク１１４を介してコール・センタにコールすることが要求された。この方法は、コールがコール・センタに到着するとすぐに、長距離の課金の累積が開始するため、コール・センタ１０８のオペレーションのコストを増大させた。さらに、複数の物理的ロケーションを有するビジネスは、ロケーション間を接続する長距離ネットワークの柔軟性が不十分であるため、すべての物理ロケーションでプログラム可能インテリジェンスを維持し、コールにサービスを提供する論理を実装する複数のアプリケーションを開発する必要があった。
【０００５】
図２は、発信元のローカルＰＳＴＮ１０６、長距離ネットワーク１１４、および終端のローカルＰＳＴＮ１０６を介してエンド・ユーザ１１６をビジネス・コール・センタ１０８に接続するネットワーク・ベースのコール・センタを示す機能図である。ネットワーク・コール・センタは、長距離ネットワーク１１４内にスイッチ１２２と、ＡＣＤ１１２と、ＩＶＲ１１０とを含み、コールに応答するサービス、コールにサービスを提供するサービス、コールを待ち行列に入れるサービスを提供することができる。ネットワーク・コール・センタは、通常、通信事業者によって提供される音声テレコミニュケーションを構内ベースのスイッチング技術、コール分配技術、対話式音声応答技術、およびコンピュータ電話統合技術と統合してそのようなサービスを行う。従来、ネットワーク・ベースのコール・センタは、応答するサービス、サービスを提供するサービス、および待ち行列に入れるサービスを行うコール管理アプリケーションを開発し、配備するのに、ベンダ独自に所有するシステムやソフトウェアを利用していた。近年、テレコミニュケーション事業者は、管理されたネットワーク・サービスとして付加価値コール管理アプリケーションの提供を開始している。ただし、そのような管理されたネットワーク・サービスは、通常、提供を行う通信事業者所有のサービスであり、しばしば、その柔軟性が不十分で、通常、機能性が不完全である。
【０００６】
（発明の概要）
本発明の一実施態様によれば、第１のコール・センタに対する電話コールが、ユーザ指定のアプリケーションのコマンド時に第２のコール・センタにダイレクトされる。ユーザ指定のアプリケーションの指示の下で、コールは、第２のコール・センタでサービスを受け、一方、ユーザ指定のアプリケーションは、センタ内で接続を確立するように第１のコール・センタに指示する。第１のコール・センタ内で接続が確立されたとき、ユーザ指定のアプリケーションは、テレコミニュケーション・ネットワークを介して第１のコール・センタ内の電話接続を使用してコールを転送またはブリッジするように第２のコール・センタに指示する。
【０００７】
本発明を添付の図面で例として、制限するものとしてではなく示す。図面では、同じ参照番号は、同じ要素を示す。
【０００８】
（詳細な説明）
本発明を以下に特定の構造および方法を含む様々な実施形態に関して説明するが、代替の構造または方法を含む実施形態も、本明細書に説明する本発明の原理を逸脱することなく使用することができる。一般に、以下に説明する実施形態は、コール・センタ・サービス・プロバイダ、以降、ユーザによって制御された分散コール・センタ・システムを提供し、ポイントオブプレゼンスでコールに応答し、サービスを提供し、待ち行列に入れかつ／または経路指定することができ、コール・センタのために通信コストを削減してオペレーション上の効率を高める仮想インテリジェント・ネットワーク（ＶＩＮ）を扱う。コール・センタは、問合せであれ、発注であれ、販売後のサポートであれ、またはその他のコール・センタ活動であれ、電話コールが、コール・センタ・エージェントのチームによって扱われ、処理される単一のコンタクト点である。これらのコール・センタ・エージェントまたはオペレータは、コール・センタの構成およびコール・センタが属する組織に依存して単一のサイトをベースとすること、または複数のサイトをベースとすることができる。コール・センタの使用が最も普及した業界および組織は、顧客サービスおよび大量の分散した顧客コンタクトに焦点が当てられる業界や組織である。これらには、銀行金融機関、保険会社、航空会社、ホテル業界、自動車レンタル組織、旅行サービス業界が含まれる。
【０００９】
本発明の実施形態を詳細に説明する前に、ＶＩＮの構成要素のいくつか、および本発明の基礎となるその他の一般的概念を議論することが役に立つ。本発明は、ポイントオブプレゼンス（ＰＯＰ：ｐｏｉｎｔ−ｏｆ−ｐｒｅｓｅｎｃｅ）コール・センタ・ゲートウェイを利用する。ＰＯＰコール・センタ・ゲートウェイは、前述した関連出願（参照により、本明細書に組み込まれる）で詳細に説明されており、コール・センタ・サービス・プロバイダのために電話料金を最小限に抑える努力におけるゲートウェイの適用可能性が、その関連出願では強調されている。ＰＯＰコール・センタ・ゲートウェイは、コール発信の点に近いローカルのポイントオブプレゼンスでコールに応答し、サービスを提供し、待ち行列に入れ、かつ／または経路指定するように構成される。したがって、ＰＯＰコール・センタ・ゲートウェイは、着信コールの初期処理を提供すること、コールを受けたビジネス・コール・センタでライブのオペレータが応対可能になるまでコールを保留にして待ち行列に入れることができる。ライブのオペレータが応対可能になった後、ＰＯＰコール・センタ・ゲートウェイは、ローカルで待ち行列に入れられたコールをビジネス・コール・センタにおけるオペレータに経路指定する。したがって、そのようなＰＯＰコール・センタ・ゲートウェイを使用することの１つの利点は、ビジネス・コール・センタ・サービス・プロバイダには、発呼者が実際にビジネス・コール・センタのオペレータに接続されている時間中だけしか長距離料金がかからないことである。保留で、待ち行列中で、または自動化されたメニューの質問に応答することなどで費やされた時間は、長距離料金には加えられない。というのは、コールのその部分が、ＰＯＰコール・センタ・ゲートウェイに終端するローカル・コールとして扱われるからである。
【００１０】
本発明のもう１つの不可欠な構成要素は、コンピュータ・サーバである。サーバは、様々なコンピュータ・ハードウェア・プラットフォームのうち任意の１つまたは複数のプラットフォーム上で実行されて、クライアントと呼ばれる他のプログラム（やはり様々なコンピュータ・プラットフォーム上で動作することができる）に何らかのサービスを提供するように構成することができるコンピュータ・プログラムである。クライアントとサーバは、しばしば、ネットワークを介するメッセージの受渡しで通信を行い、どのようにデータを通信（すなわち、送信および受信）するかを記述する１組の正式の規則である何らかのプロトコルを使用してクライアントの要求および／または応答およびサーバの応答および／または要求を符号化する。サーバは、常時、実行され、クライアントの要求および／または応答が着信するのを待っているか、またはいくつかの特定のサーバを制御する、常時実行されるサーバなどの、何らかのより高いレベルのソフトウェア・アプリケーションによって起動される。クライアント−サーバ間の通信は、顧客（クライアント）が、注文（要求）を注文書で供給業者（サーバ）に送り、供給業者が、要求された商品および請求書（応答）を発送するのと同様である。注文書および請求書（例えば、そこに明細が記される売買条件）は、要求および応答を通信するのに使用されるプロトコルの一環である。
【００１１】
以下にさらに説明するとおり、本ＶＩＮは、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ときには、「ＷＥＢ」として知られる）上におけるＳｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＳＧＭＬ）の使用を可能にするように設計されたコンピュータ・ベースの言語である、いわゆるｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）を使用する。ＳＧＭＬは、様々なタイプの電子文書の構造および内容の記述を定義するための国際標準である。さらに、ＶＩＮは、インターネット上におけるハイパーテキスト文書の配布のために設計された周知のＨｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を利用して、仮想私設ネットワーク（ＶＰＮ）上のＸＭＬメッセージを介するネットワーク構成要素（例えば、クライアントおよびサーバ）間における通信を円滑にする。仮想私設ネットワーク（ＶＰＮ）は、それ以外では公衆のネットワーク内で、セキュアで専用のデータ通信のためにトンネルを提供する
【００１２】
本発明の少なくとも１つの実施形態では、ＶＩＮは、コール・センタが存在するロケーションに分散された構内コール・センタ・ゲートウェイに対してユーザによって制御される仮想私設ネットワークによって相互接続された、コール発信の点に近いポイントオブプレゼンスに分散された１組のＰＯＰコール・センタ・ゲートウェイを含む。ＰＯＰゲートウェイおよび構内ゲートウェイは、本発明の実施形態によれば、コール・フロー管理（ＣＦＭ）アプリケーションおよび対話式音声応答（ＩＶＲ）ＷＥＢアプリケーションによって動的に制御されたプログラム可能電話アプリケーション・ゲートウェイである。ＣＦＭアプリケーションは、時刻、日付、休日、オーバーフロー、複数のサイトにわたるパーセンテージ割当て、および応答リソースを選択するためにコールがそこに経路指定されるエージェント・グループ・セットなどの情報を使用する。ＩＶＲアプリケーションは、音声（または合成された音声）メッセージの事前記録されたデータベースを使用してユーザが入力した数字を提示および／または収集し、オフィス・データベースと対話し、結果をユーザに提供するソフトウェア・アプリケーションと見なすことができる。また、ＩＶＲアプリケーションは、オプションとして、音声認識を使用してユーザからの入力オプションを確保することも可能である。これらのアプリケーション、ＣＦＭおよびＩＶＲは、外部インターネット・データ・センタおよび／またはコール・センタ構内でホストされ、ＰＯＰゲートウェイおよび構内ゲートウェイと同じＶＰＮに接続されることが可能なＮｅｔｓｃａｐｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ  ２．１やＮｅｔＤｙｍａｎｉｃｓ  ４．０などのＷＥＢアプリケーション・サーバ上に常駐することが可能である。ＣＦＭアプリケーションおよびＩＶＲアプリケーションは、分散コール・リソース（ハードウェアおよび／またはソフトウェア）管理のためにＨＴＴＰおよび仮想私設ネットワークを使用するＸＭＬメッセージを介して、これらのゲートウェイのコール・フローの挙動および音声応答の挙動を制御する。
【００１３】
ＶＩＮを動作させるプロセスは、図３に示す単純化した流れ図を参照して一般的に説明することができる。インバウンドのコールが行われるのに応答して、ステップ２００で、ユーザ指定のＣＦＭアプリケーションおよびＩＶＲアプリケーションが、インバウンドのコールを代行受信するようにコール発信の点における、またはその近くのＰＯＰゲートウェイに指示する。したがって、ＰＯＰゲートウェイが、ローカルでインバウンドのコールに応答して終端させ、一般に最低のアクセス料金を提供するローカル相互接続の経済性を活用する。さらに、ＣＦＭが、ステップ２０４で、ＰＯＰコール・センタ・ゲートウェイにコマンド（例えば、以下に説明するＸＭＬ  Ｐａｇｅを使用して）を発行して、オペレータが応対可能になってコールにサービスを提供するまで、コールを保留にするまたは待ち行列に入れる、かつ／またはコールが保留されている間、発呼者に対して音楽またはカストマイズされた告知を流すなどのサービスを提供する。
【００１４】
これと並行して、ＣＦＭは、ステップ２０８で、構内コール・センタ・ゲートウェイにコマンド（やはりＸＭＬ  Ｐａｇｅを介して）を発行して、コール・センタのオペレータに対しその自動コール分配器（ＡＣＤ）にプロキシ・コールを発信させることができる。これに応答して、構内コール・センタ・ゲートウェイは、ＡＣＤに対するプロキシ・コールを生成して出す。また、ＣＦＭコマンドは、ステップ２１０で、オペレータの応対可能性に関してＡＣＤ内のプロキシ・コールの進行を監視して、その応対可能性をＣＦＭに通知するように構内コール・センタ・ゲートウェイに指示することも可能である。プロキシ・コールが、構内コール・センタ待ち行列の先頭に到達し、ライブのコール・センタ・エージェントによって応答されるのが間近であるとき、構内コール・センタ・ゲートウェイがＣＦＭに警報する。選択されたオペレータの応対可能性に関するこのリアルタイムの情報に基づき、ＣＦＭアプリケーションは、ステップ２１２で、ＰＯＰコール・センタ・ゲートウェイにコマンドを発行して、保留中のコールを構内コール・センタ・ゲートウェイに転送させ、またＰＯＰゲートウェイからの着信コールを構内ＡＣＤ内のプロキシ・コール（現時点で、オペレータによって応答されるのが間近である）にブリッジする。そのようなローカル待ち行列化およびジャスト・イン・タイムのコール・デリバリにより、待ち行列に入れるためにコールがより早くから構内コール・センタに接続された場合、かかることになる長距離通信料金が節約される。
【００１５】
構内コール・センタを選択するプロセスを図４に示す流れ図を参照して一般的に説明する。ステップ２１６で、着信コールが、好ましくはＷＥＢアプリケーションとして開発され、ＷＥＢサーバ上に配備されたＩＶＲアプリケーションにダイレクトされる。そのようなアプリケーションを使用して発呼者特有の情報（例えば、ＣＦＭアプリケーションが使用して最適にマッチする応答リソースにコールをインテリジェントに経路指定することができるアカウント番号）を収集することができる。ステップ２１８で、ＣＦＭが、着信コールに対してローカルなＰＯＰコール・センタに指示して、前述したとおり、コールを代行受信して対話式音声応答ベースの自動化されたサービスを提供するようにさせる。ＣＦＭが、ステップ２２０で、最適応答リソースとして選択された構内コール・センタ・ゲートウェイに指示してＡＣＤにプロキシ・コールを挿入させる。コールにサービスを提供できる応対可能な最適応答リソースがなく、コールを次善のロケーションに転送する必要がある場合、ＣＦＭが、ステップ２２４で、最適応答リソースに対してコマンドを発行してそのＡＣＤからプロキシ・コールをドロップさせ、ステップ２２８で、次善の応答ロケーションにあるコール・センタに指示して、そのＡＣＤにプロキシ・コールを行うようにさせる。（このプロセスは、コールを扱うことができる応答リソースが探し出されるまで、必要に応じて（またリソースが許す限り）反復することができる。）第２のロケーションは、ＣＦＭコマンドに応答して、ステップ２３０でプロキシ・コールの進行を監視し、ＣＦＭにオペレータの応対可能性を通知する。コールにサービスを提供する応対可能なライブのオペレータがいると、第２のロケーションからメッセージを受け取って、ＣＦＭは、ステップ２３２で、ＰＯＰコール・センタ・ゲートウェイに指示してコールを第２のロケーションに転送させる。ＰＯＰコール・センタ・ゲートウェイにおけるそのようなローカルの待ち行列化により、コールがより早くから最適応答リソースに接続され、次に第２のロケーションに転送された場合、かかることになる長距離通信料金が節約される。
【００１６】
コールが、構内コール・センタにいるエージェントに最終的に接続された場合、ＶＩＮは、ＩＰ電話、Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＭＧＣＰ），Ｇａｔｅｋｅｅｐｅｒプロトコルなどの従来のインターネット技術を活用することができ、高品質のユーザ経験を確実にするために長距離音声通信に関して保証されたサービス品質を有する仮想私設ネットワークが提供される。次に、構内コール・センタにおける選択されたコール・センタ・エージェントが、転送されたコールに応答して、発呼者に対するまたは発呼者のための顧客サービスを提供する。最後に、発呼者またはコール・センタ・エージェントが、コールをハングアップしたとき、ＣＦＭが、ＰＯＰゲートウェイおよび構内ゲートウェイに指示してコールを終了するようにさせる。
【００１７】
好ましくは、ＰＯＰゲートウェイおよび構内ゲートウェイ、ならびに制御を行うＣＦＭおよびＩＶＲのアプリケーション・サーバは、本発明の実施形態によれば、ゲートウェイおよびサーバと同じＶＰＮに接続された中央ネットワーク・オペレーション・センタ（ＮＯＣ）１５６（図９参照）から管理される。Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）およびネットワーク管理ＷＥＢツールを使用して、ＮＯＣは、ＶＩＮ内のすべての構成要素を発見、構成、監視、および管理することができる。さらに、ＮＯＣは、サービス提供システム、ユーザ請求書発行システム、ユーザ・サポート・システム、およびＶＩＮが、一連の終端間の管理されたユーザ対話サービスを提供するのを可能にする他のサービス管理システムを含む他のオペレーション・サポート・システムをホストする。
【００１８】
本ＶＩＮは、ユーザ（すなわち、コール・センタ・プロバイダ）に、コール・センタのインバウンドのオペレーションに対する制御を与えるだけでなく、アウトバウンドのコール・センタ・オペレーションに対しても制御を与える。ＣＦＭアプリケーションに導かれ、ＶＩＮを使用して指定された長距離番号をローカル番号としてダイヤル呼出しを行い、応答のないコールまたはマシン応答されたコールをフィルタリングして取り出し、コールに応答が行われたときに指定された告知またはメッセージを流し、着呼側が、ライブのオペレータおよび／または記憶された対話式ソフトウェア・アプリケーションを使用して対話式トランザクションを行うのを可能にすることができる。ＣＦＭのＷＥＢアプリケーションは、１組の代替の長距離番号を指定し、ＸＭＬメッセージを介してＶＩＮの要素に命令し、着呼側にコンタクトして、所定の音声メッセージを送ることができる。ＶＩＮは、ダイヤル呼出しを受ける番号がローカル・コールになる適切なＰＯＰゲートウェイに対してそのようなコンタクトを試みる要求を送出する。コールに対する応答がない場合、またはマシンによって応答された場合、ライブの人員にコールを到達させることができるまで、他の指定された番号が順に試みられる。コールに応答が行われたとき、ＩＶＲアプリケーションが、着呼側を認証し、ＣＦＭ指定の音声メッセージまたは告知を送り、着呼側から肯定応答を受け取ることが可能である。また、ＩＶＲは、サービス提供エージェントに接続されるオプションを着呼側に提供することもできる。着呼側が、このオプションを選択すると、ＣＦＭは、遠隔コール・センタに指示して、遠隔コール・センタのＡＣＤ内におけるプロキシ・コールを要求し、プロキシ・コールの進行を監視することにより、サービス提供エージェントとの接続を確立するようにさせる。サービス提供エージェントとの接続が確立されたとき、ＣＦＭは、遠隔コール・センタに指示してプロキシ・コールをローカル・コール・センタにブリッジするようにさせ、これにより、コールを転送し、待ち行列に入れて累積されることになる不必要な長距離料金がないようにする。
【００１９】
したがって、より一般的な見方では、プログラム可能のＶＩＮは、コールを発信または終了させること、コールの対をブリッジすること、および発呼者をＩＶＲアプリケーションに接続することができるインテリジェントな電話ポートの集まりであると見なすことができる。電話ポートのプログラム可能性は、ＸＭＰページの使用を介して実現され、ページの「タグ」のそれぞれが、電話ポートに指示して指定されたコール管理機能を行うようにさせる。そのようなＸＭＬタグは、ＰＯＰコール・センタ・ゲートウェイの挙動を遠隔で制御するための汎用の音声応答制御言語（ＶＣＲＬ）の一環でよい。したがって、コール発信の点に近いポイントオブプレゼンスに分散されたポイントオブプレゼンス・コール・センタ・ゲートウェイの１組が、プログラム可能のＶＩＮによってコール・センタが常駐するビジネス・ロケーションにある構内音声応答サーバに相互接続される。コール・フロー・マネージャ（ＣＦＭ）が、コール・センタＩＶＲアプリケーションの制御下で、ＶＩＮ内の電話コールの作成および管理を調整する。
【００２０】
前述したとおり、ＶＲＣＬは、ＣＦＭにおいて生成され、ＰＯＰゲートウェイによって使用されてコール・センタのために処理を実行するＸＭＬ  Ｐａｇｅオブジェクトのための構文を提供する。ＸＭＬ  Ｐａｇｅオブジェクトは、ＷＥＢサーバのディレクトリ内に記憶された、またはＣＦＭをホストするサーバにおけるスクリプトによって生成されたＡＳＣＩＩテキストの簡単なページでよい。ＸＭＬ  Ｐａｇｅは、ＰＯＰゲートウェイ上で実行されるクライアント・アプリケーションによって行われるＨＴＴＰ要求に応答してＣＦＭによって伝送される。
【００２１】
ＶＲＣＬが、コール・センタにおいて実行されるＩＶＲアプリケーションによってどのように使用されて、コール・センタのためにＰＯＰゲートウェイの処理を制御するのが可能であるかをより十分に理解するため、図５に示す流れ図に関連して以下の例を考慮されたい。インバウンドのコールがＰＯＰゲートウェイに着信したとき、ＰＯＰゲートウェイとＣＦＭの間でデータ通信パスが確立される。コールが受け入れられた直後に、音声プロンプトおよびメニュー選択肢の選択を発呼者に提供するため、ＣＦＭは、制御をＩＶＲアプリケーションに渡す。ＰＯＰゲートウェイは、ＩＶＲアプリケーションからＸＭＬ  Ｐａｇｅを取り出し、ＸＭＬ  Ｐａｇｅ内のコマンドを構文解析して実行し、次に、第１のＸＭＬ  Ｐａｇｅ内に指定されたＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）によって定義されるロケーションから次のＸＭＬ  Ｐａｇｅを要求する。次に、このプロセスが反復され、ＰＯＰゲートウェイが、ＩＶＲアプリケーションから新しい組のコマンド（ＸＭＬ  Ｐａｇｅ内のタグによって表される）の獲得を続ける。ＶＲＣＬに関して留意すべき重要な点は、ＨＴＭＬとは異なり、ＶＲＣＬは、線形順序の命令を表すことである。ＨＴＭＬページは、一般的に一斉にユーザに提示されるが、ＶＲＣＬページは、可聴式にレンダリングされて上から下の順に処理される。
【００２２】
ＩＶＲアプリケーションは、アプリケーションの複雑さに応じて、ＰＯＰゲートウェイを導いて一連のＸＭＬ  Ｐａｇｅを通らせる。例えば、一連の相互リンクされたメニューが発呼者によってナビゲートされるまでは、発呼者の意図および／または選択を完全に定義することができない。最終的に、ＩＶＲアプリケーションは、コールを終了させること、またはコールをライブのオペレータに転送することができる。どちらの場合も、ＩＶＲアプリケーションは、ＣＦＭに制御を渡して戻し、次に、ＣＦＭが、ＰＯＰゲートウェイに指示してＰＳＴＮを介してコールをセットアップするように、またはコールを終了するようにさせる。図５に示すコール・フローで指定される１組のＸＭＬタグは、ＶＩＮ内で使用することが可能なタイプのタグの例に関する以下の議論に関連して理解することができる。
【００２３】
ＶＲＣＬは、ライブのオペレータに転送する前にコールを待ち行列に入れる能力、およびＣｌｉｃｋ−ｔｏ−Ｔａｌｋアプリケーションなどの他のＷＥＢ機能強化された電話アプリケーションを統合する能力をさらに提供する。これは、専用ＸＭＬタグの使用によって可能となり、このタグは、ＰＯＰゲートウェイによって解釈されてそこに指定される所望のコマンドを実施するのが可能である。したがって、ＶＲＣＬは、いくつかのタグまたは要素（コマンドと同様の）を定義してＰＯＰサーバの挙動を制御する。図６は、ＩＶＲアプリケーションによって生成されたＸＭＬ  Ｐａｇｅに含まれることが可能なタイプのタグの例を図示している。
【００２４】
以下の説明では、「会話コントローラ」という用語は、ＩＶＲアプリケーションまたはＣＦＭとの対話を管理するＰＯＰサーバ内のエンドポイントを指す。示すとおり、ＸＭＬ  Ｐａｇｅ要素は、ＰＯＰゲートウェイとの通信のためにＣＦＭおよび／またはＩＶＲによって使用されるＸＭＬ  Ｐａｇｅごとのルート要素である。Ｐａｇｅ要素は、（とりわけ）以下の属性を有することが可能である。    ＴＹＰＥ    ページのソースを識別するのにＩＶＲアプリケーションは、値「ＩＶＲ」を使用しなければならず、一方、その他のアプリケーションは、異なる値を使用することができる（例えば、コール・フロー・マネージャは、値「ＣＣ」を使用することができる）。
ＣＵＳＴＩＤ    コール・センタのための固有識別子。
ＰＡＧＥＩＤ    （オプション）各ページを識別する文字列（数字であることが可能である）。
ＳＥＳＳＩＯＮＩＤ    発呼者との特定のセッションのための識別子。これは、各ページごとにＨＴＴＰ要求内でＰＯＰゲートウェイによって送信される照会ストリングの一部であることが可能である。
ＨＲＥＦ    ページの終りに達した場合、取り出すべき次のＸＭＬ  ＰａｇｅのＵＲＬ（子要素は、ページ中のどこかから別のＵＲＬに制御を渡すことができる）。
【００２５】
各ＸＭＬ  Ｐａｇｅは、ＰＯＰゲートウェイによって行われるべき作業の単位（すなわち、作業命令）を表す。作業の単位は、単一の処理から構成されること、またはいくつかの処理の線形リストから構成されることができる。最高レベルで、基本要素（例えば、ＰＬＡＹ、ＴＯＮＥＭＡＰ、ＶＯＩＣＥＭＡＰ、およびＥＸＣＥＰＴＩＯＮＭＡＰ）、複合要素（例えば、ＭＥＮＵ、ＦＯＲＭ）、および／またはラベル付けのためのアンカー要素（例えば、Ａ）が、Ｐａｇｅ中に含まれてもよい。さらに、音声記録を扱うためのＲＥＣＦＩＬＥ要素および／またはユーザ定義の変数を設定するためのＳＥＴ要素も提供されてもよい（図示していない）。ＸＭＬ  Ｐａｇｅルートの下位要素が、コール・フロー、発呼者との対話、またはコール制御に向けられる。
【００２６】
コール・フローおよび対話の管理に向けられたＸＭＬ  Ｐａｇｅルート要素のいくつかの可能な子（下位要素）は、ＰＬＡＹ、ＴＯＮＥＭＡＰ、ＶＯＩＣＥＭＡＰ、ＥＸＣＥＰＴＩＯＮＭＡＰ、ＭＥＮＵ、ＦＯＲＭ、Ａ、ＲＥＣＦＩＬＥ、およびＳＥＴである。コール制御に向けられた下位要素は、ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬ、ＨＡＮＧＵＰ＿ＡＮＤ＿ＤＥＳＴＲＯＹ＿ＬＥＧ、ＱＵＥＵＥ＿ＣＡＬＬ、ＱＵＥＵＥ＿ＤＲＯＰ、ＢＲＩＤＧＥ＿ＣＡＬＬ、ＵＮＢＲＩＤＧＥ＿ＣＡＬＬ、ＬＥＧ＿ＷＡＩＴ、ＡＬＥＲＴ＿ＬＥＧ、およびＥＮＤ＿ＳＥＳＳＩＯＮである。これらの下位要素は、任意の順序で複数回、現れれてもよい。ＣＦＭは、ＩＶＲアプリケーションによって発行されるのが可能ではないより大きい１組のよりプリミティブなコール制御タグを利用することができる。これは、ＣＦＭが、ＶＩＮ監視プロセスだからである。
【００２７】
ＰＬＡＹ要素により、ＩＶＲアプリケーションは、ＰＯＰゲートウェイに指示して音声ファイルを再生すること、指定された時間量だけ一時停止すること、数または１組の数字をプレイアウトすることなどをさせる。この要素は、以下の属性を有することが可能である。
ＩＮＴＥＲＲＵＰＴＩＢＬＥ    （オプション）ＹＥＳまたはＮＯ。デフォルトで、再生されるメッセージは、トーン入力によって割込み可能である。ただし、メッセージは、ＮＯの値を使用することによって割込み不可能にすることができる（ＭＥＮＵの場合を除き−以下を参照）。
ＰＬＡＹは、任意の順序で、任意の回数、使用することができるいくつかの可能な子要素、ＶＯＩＣＥ、ＰＡＵＳＥ、ＳＴＲＩＮＧ、ＤＡＴＥ、ＴＩＭＥ、ＮＵＭＢＥＲ、ＣＵＲＲＥＮＣＹ、ＯＲＤＩＮＡＬ、ＩＮＤＥＸＦＩＬＥ、およびＤＴＭＦを有する。
【００２８】
ＶＯＩＣＥ要素は、再生される音声ファイルを指定する。音声ファイルは、．ｖｏｘファイルまたは．ｗａｖファイルなどの任意のコンピュータ可読オーディオ・ファイルであるのが可能である。一実施形態では、ＶＯＩＣＥ要素は、２つの属性を有し、その一方（ＳＲＣ）は必須であり、その他方（ＴＥＸＴ）はオプションである。
ＳＲＣ    再生されるファイルの完全に指定されたＵＲＬ。
ＴＥＸＴ    （オプション）ＳＲＣファイル内にあるもののテキストとしてのレンダリング
ＶＯＩＣＥは、子を有さず、空の要素（すなわち、終了タグは、属性の終りにおける単なる「／＞」であるのが可能である）である。
【００２９】
ＰＡＵＳＥ要素は、沈黙の期間を指定する。この要素は、例えば、ＰＬＡＹ要素内のＶＯＩＣＥタグに続くのが可能である。その親ＰＬＡＹタグが、ＭＥＮＵまたはＦＩＥＬＤの一部ではない場合、ＰＡＵＳＥは、指定されたＴＩＭＥの間、単に沈黙を導入する。他方、その親ＰＬＡＹタグが、ＭＥＮＵまたはＦＩＥＬＤの一部である場合、ＰＡＵＳＥは、発呼者が、その間に、少なくとも１つの数字を入力するものとされるタイムアウト期間として作用する（以下のＩＮＰＵＴタグの説明におけるＭＡＸ＿ＩＤＤ（ｍａｘ  ｉｎｔｅｒｄｉｇｉｔ−ｄｅｌａｙ）の説明も参照）。
【００３０】
ＰＡＵＳＥは、２つの属性、ＴＩＭＥおよびＵＮＩＴを有する。
ＴＩＭＥ    その間、沈黙が所望され、また発呼者の入力が所望される（ＭＥＮＵまたはＦＩＥＬＤの一部である場合）時間帯の値。
ＵＮＩＴ    （オプション）ＴＩＭＥが指定される単位（ＳＥＣまたはＴＥＮＴＨＳ）。ＴＥＮＴＨＳは、ユニット＝０．１ＳＥＣを意味する。
ＰＡＵＳＥは、子を有さない。
【００３１】
子を有さないＳＴＲＩＮＧ要素を使用して、ＰＯＰサーバが文字、数字、および／または特殊文字のストリングを１つずつプレイアウトするのをＩＶＲアプリケーションが所望していることが示される。この要素は、２つの属性を有し、その両方とも必須である。
ＳＲＣ    文字を発音するための音声サブシステムによって使用される索引ファイル（以下を参照）のＵＲＬである。
ＶＡＬＵＥ    プレイアウトされる文字／数字／文字のストリング。ストリングは、以下の記号の任意の組み合わせを含むことが可能である。Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌ、Ｍ、Ｎ、Ｏ、Ｐ、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖ、Ｗ、Ｘ、Ｙ、Ｚ、０、１、２、３、４、５、６、７、８、９、＋、＜、＝、％、−、＞、＆、．、＃、＊、＠等（すなわち、あらゆるＡＳＣＩＩ文字）。従来のＸＭＬ構文解析コードが「＜」、「＞」、および「＆」という記号に付与する特別の意味のため、これらの記号は、それぞれ、実際には「＆ｌｔ；」、「＆ｇｔ；」、および「＆ａｍｐ；」と記される必要がある可能性がある。
【００３２】
どのようにＳＴＲＩＮＧタグを使用することができるかの例として、ＶＡＬＵＥ＝「ＩＢＭ」を考慮されたい。プレイアウトされるとき、このストリングは、「Ａｉｙｅｅ　Ｂｅｅ　Ｅｍｍ」としてレンダリングされる。ＶＡＬＵＥ＝「３＋４」の場合、プレイアウトされる句は、「Ｔｈｒｅｅ　Ｐｌｕｓ　Ｆｏｕｒ」であるといった具合である。ＳＴＲＩＮＧ、ＤＡＴＥ、ＴＩＭＥ、ＮＵＭＢＥＲ、ＣＵＲＲＥＮＣＹ、およびＯＲＤＩＮＡＬのデータをプレイアウトするときに使用される特別索引ファイルは、これらのタイプのデータをプレイアウトする際に使用されるすべての共通プロンプトのための音を記憶することができる。また、このファイルは、その中のプロンプトの開始点を明確な順序でポイントするオフセットのアレイであるファイルの開始におけるヘッダ・セクションも含むことが可能である。索引ファイルの形式は、本発明にとってクリティカルではない。
【００３３】
ＤＡＴＥ要素を使用して、ＰＯＰサーバが発呼者に日付をプレイアウトするのをＩＶＲアプリケーションが所望していることが示される。この要素は、３つの属性を有し、そのすべてが必須である。
ＳＲＣ　　日付を発音するために音声サブシステムによって使用される索引ファイルのＵＲＬ（ＳＴＲＩＮＧタグの前述の説明を参照）。
ＶＡＬＵＥ　　発音される日付の値。値は、ｙｙｙｙｍｍｄｄ（８桁）、ｍｍｄｄ（４桁）、ｗ：ｙｙｍｍｄｄ（１０文字）、ｗ：ｍｍｄｄ（６文字）、または別のユーザ定義された形式として指定することができる。ｗは、曜日を指し、０が日曜日に該当し、１が月曜に該当するといった具合である。ｙｙ、ｍｍ、およびｄｄは、それぞれ、年、月、日付を指す。
ＦＯＲＭＡＴ　　この属性は、どのように日付がプレイアウトされるべきかを示す。この属性の可能な値は、ＤＤＭＭ、ＭＭＤＤ、ＤＤＭＭＹＹＹＹ、ＭＭＤＤＹＹＹＹ、Ｗ：ＤＤＭＭ、Ｗ：ＭＭＤＤ、Ｗ：ＤＤＭＭＹＹＹＹ、およびＷ：ＭＭＤＤＹＹＹＹである。例えば、ＤＤＭＭＹＹＹＹは、日付が、「日−月−年」として発音されるべきことを意味する。Ｗ：ＭＭＤＤは、日付が、（例えば、）曜日−月−日として発音されるべきことを意味する。
ＤＡＴＥは、子を有さない。
【００３４】
ＴＩＭＥ要素を使用して、ＰＯＰサーバが発呼者に時刻をプレイアウトするのをＩＶＲアプリケーションが所望していることが示される。この要素は、３つの属性を有し、そのすべてが必須である。
ＳＲＣ　　時刻をプレイアウトするために音声サブシステムによって使用される索引ファイルのＵＲＬ（ＳＴＲＩＮＧタグの前述の説明を参照）。
ＶＡＬＵＥ　　プレイアウトされる時刻の値。この値は、ｈｈｍｍ（４桁）またはｈｈｍｍｓｓ（６桁）、あるいは別のユーザ指定の形式（例えば、２４時間時刻式の）として指定することができる。
ＦＯＲＭＡＴ　　どのように時刻がプレイアウトされるべきかを記述する。可能な値は、１２＿ＨＯＵＲまたは２４＿ＨＯＵＲである。
ＴＩＭＥは、子を有さない。
【００３５】
ＮＵＭＢＥＲ要素は、ＰＯＰサーバが発呼者に数をプレイアウトするのをＩＶＲアプリケーションが所望していること示すことができる。この要素は、２つの属性を有し、その両方とも必須である。
ＳＲＣ　　数を発音するために音声サブシステムによって使用される索引ファイルのＵＲＬ（ＳＴＲＩＮＧタグの前述の説明を参照）。
ＶＡＬＵＥ　　プレイアウトされる数の値。
ＮＵＭＢＥＲは、子を有さない。
【００３６】
ＣＵＲＲＥＮＣＹ要素を使用して、ＰＯＰサーバが発呼者に貨幣価値をプレイアウトするのをＩＶＲアプリケーションが所望していることが示される。この要素は、３つの属性を有し、そのすべてが必須である。
ＳＲＣ　　通貨を発音するために音声サブシステムによって使用される索引ファイルのＵＲＬ（ＳＴＲＩＮＧタグの前述の説明を参照）。
ＶＡＬＵＥ　　発音される通貨の値。この値は、小数点を有することも有さないことも可能である。
ＣＯＵＮＴＲＹ　　３文字（例えば、ＩＳＯ−４２１７準拠）通貨コード
ＣＵＲＲＥＮＣＹは、子を有さない。
【００３７】
ＯＲＤＩＮＡＬ要素を使用して、ＰＯＰサーバが発呼者に序数（例えば、「第１」、「第３」等）をプレイアウトするのをＩＶＲアプリケーションが所望していることが示される。この要素は、２つの属性を有する。
ＳＲＣ　　序数を発音するために音声サブシステムによって使用される索引ファイルのＵＲＬ。
ＶＡＬＵＥ　　発音される序数の値。許される値は、０、１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５、１６、１７、１８、１９、２０、２１、２２、２３、２４、２５、２６、２７、２８、２９、３０、３１、４０、５０、６０、７０、８０、９０、１００、１０００、１００００００、１０００００００００等であることが可能である。
ＯＲＤＩＮＡＬは、子を有さない。
【００３８】
前述した索引ファイル形式が、所望のプロンプトを再生するのに不適切である場合（例えば、コール・センタが、何らかの追加のプロンプトを使用していること、またはコール・センタの索引ファイルが前述したファイル・タイプに適合しないことが可能である）、日付、通貨、数字等を再生するためにＩＮＤＥＸＦＩＬＥ要素が、ＩＶＲアプリケーションによって使用されるのが可能である。そのような場合、ＩＶＲアプリケーションは、前述したＤＡＴＥ、ＣＵＲＲＥＮＣＹ等のタグを使用すべきではなく、ＩＮＤＥＸＦＩＬＥタグを使用し、ファイル内のオフセットおよび長さを指定して所望のプロンプトがプレイアウトされるのを確実にしなければならない。ＩＮＤＥＸＦＩＬＥは、最高で４つの属性を有する。
ＳＲＣ　　プロンプトをプレイアウトするために音声サブシステムによって使用されるコール・センタの索引ファイルのＵＲＬ。
ＯＦＦＳＥＴＳ　　ファイル内の再生されるプロンプトの開始点に関するバイト・オフセットを示すコンマで区切られたオフセットのリスト。例えば、ＯＦＦＳＥＴＳは、Ｍ、Ｓ、Ｆ、およびＴのプロンプトの開始に関するオフセットが、それぞれ、００３１５４５、００３８０４０、００２２０６０、および００４１１２２であると想定すると、句「ＭＳＦＴ」に対して「００３１５４５，００３８０４０，００２２０６０，００４１１２２」という値を有するのが可能である。
ＬＥＮＧＴＨＳ　　ファイル内の再生されるプロンプトの長さを示すコンマで区切られた長さのリスト。ＯＦＦＳＥＴＳとＬＥＮＧＴＨＳの間には、１対１の対応が存在しなければならない。
ＴＥＸＴ　　プロンプト内にあるもののオプションのテキストとしてのレンダリング。
ＩＮＤＥＸＦＩＬＥは、子を有さない。
【００３９】
ＤＴＭＦタグは、ＰＬＡＹの下で子タグとしてだけ使用されなければならない。このタグの目的は、ＩＶＲアプリケーションが、既に確立されたコール上でＡＣＤ／ＰＢＸに対して帯域内ＤＴＭＦトーンを送信できるようにすることである。これにより、ＩＶＲアプリケーションは、アカウント番号等を送信することができ、また、発呼者が情報を再入力／反復しなくてもライブのオペレータと話すことができるステージにＡＤＣ／ＣＴＩアプリケーションをもっていくことができる。ＤＴＭＦタグは、１つだけの属性を有する。
ＶＡＬＵＥ　　送信されるトーン（例えば、「２６９０」、「＃，３３９６」）。値の中でコンマを使用して一時停止を示すことができる。
【００４０】
ＰＬＡＹ　ＤＴＭＦの組み合わせは、ＭＥＮＵ内でトーン間の干渉が生じないよにＭＥＮＵ内で使用すべきではない。ＤＴＭＦは、子を有さない。
【００４１】
ＴＯＮＥＭＡＰ要素により、ＩＶＲアプリケーションは、発呼者によって入力されたトーン・キーとユーザ入力に応答して訪ねるＸＭＬ　ＰａｇｅのＵＲＬの間のマッピングを指定することができる。ＴＯＮＥＭＡＰは、ＸＭＬ　Ｐａｇｅ中の最高レベルに存在すること、またはＭＥＮＵの下位要素として使用されることができる。第１のケースでは（ＭＥＮＵの外で指定されているとき）、ＴＯＮＥＭＡＰは、ページにわたって記憶されているという意味で、グローバルな効果を有する。第２のケースでは（ＭＥＮＵの一部として指定されているとき）、その範囲はローカルである。ＭＥＮＵ内で、ローカルＴＯＮＥＭＡＰは、２つのマップ間で矛盾するＴＯＮＥ（以下を参照）に関して、グローバルＴＯＮＥＭＡＰに優先する。ローカルＴＯＮＥＭＡＰと全く矛盾のないグローバルＴＯＮＥＭＡＰ内のＴＯＮＥに関しては、そのようなＴＯＮＥは、ＭＥＮＵ内であってさえも、グローバルなケースと同じ効果を有する。ＭＥＮＵをエグジットした後、当該のＴＯＮＥＭＡＰは、当該のグローバルＴＯＮＥＭＡＰに戻る。
【００４２】
ＴＯＮＥＭＡＰは、ＴＯＮＥ子要素を有するのが可能であり、この要素を使用して、１つのトーン・キーと次のページが取り出されるＵＲＬの間のマッピングを指定することができる。ＴＯＮＥは、次の属性を有する。第１の属性（ＴＯＮＥＩＤ）は、必須である。また、第２の属性または第３の属性のどちらかも、入力されなければならない。
ＴＯＮＥＩＤ　　０、１、２、３、４、５、６、７、８、９、＊、＃、ＯＴＨＥＲのどれか。ＯＴＨＥＲには、ＴＯＮＥＭＡＰ内で明記されていない残りのすべてのキーが含まれる。（必須）
ＨＲＥＦ　　次のページを取り出すＵＲＬ。この属性は、現在のＰａｇｅ中のラベルもポイントすることが可能である（以下のＡ要素の説明を参照）。（ＲＥＰＥＡＴの代りでオプション）
ＲＥＰＥＡＴ　　値は、ＭＥＮＵでなければならない。この属性により、関連トーン・キーが入力された場合、制御が、ＭＥＮＵの開始におけるＰＬＡＹに戻ることができる。（ＨＲＥＦの代りにオプション）
ＴＯＮＥは、子を有さない。
【００４３】
ＶＯＩＣＥＭＡＰ要素により、ＩＶＲアプリケーションは、発呼者から受け取られたある音声入力と、この入力に応答して訪れるＸＭＬ　ＰａｇｅのＵＲＬの間のマッピングを指定することができる。ＶＯＩＣＥＭＡＰは、ＸＭＬ　Ｐａｇｅ中の最高レベルに存在すること、またはＭＥＮＵの下位要素として現れることが可能である。第１のケースでは（ＭＥＮＵの外で指定されているとき）、ＶＯＩＣＥＭＡＰは、ページにわたって記憶されているという意味で、グローバルな効果を有する（例えば、発呼者が、「オペレータ」と言ったときはいつでも、あるＵＲＬのＸＭＬ　Ｐａｇｅにアクセスが行われて制御がオペレータに渡される）。第２のケースでは（ＭＥＮＵの一部として指定されているとき）、その範囲はローカルである。ＭＥＮＵ内で、ローカルＶＯＩＣＥＭＡＰは、２つのマップ間で矛盾するＰＨＲＡＳＥ（以下を参照）に関して、グローバルＶＯＩＣＥＭＡＰに優先する。ローカルＶＯＩＣＥＭＡＰと全く矛盾のないグローバルＶＯＩＣＥＭＡＰ内のＰＨＲＡＳＥに関しては、そのようなＴＯＮＥは、ＭＥＮＵ内であってさえも、グローバルなケースと同じ効果を有する。ＭＥＮＵをエグジットした後、当該のＶＯＩＣＥＭＡＰは、当該のグローバルＶＯＩＣＥＭＡＰに戻る。
【００４４】
ＶＯＩＣＥＭＡＰは、１つの音声コマンド（句）と、このコマンドに応答して次のＸＭＬ　Ｐａｇｅを取り出すＵＲＬの間のマッピングを指定するＰＨＲＡＳＥ子要素を有することが可能である。
ＳＲＣ　　音声認識ファイルまたは音声文法ファイル
ＨＲＥＦ　　次のページを取り出すＵＲＬ。この属性は、ページ中のラベルをポイントすることもできる（以下のＡ要素の説明を参照）。
ＰＨＲＡＳＥは、子を有さない。
【００４５】
ＥＸＣＥＰＴＯＮＭＡＰ要素を使用して、ある例外（例えば、タイムアウト）と、そのようなイベントがあった場合に取り出すＸＭＬ　ＰａｇｅのＵＲＬの間のマッピングを指定することができる。ＴＯＮＥＭＡＰと同様に、ＥＸＣＥＰＴＩＯＮＭＡＰの範囲も、グローバル（ＸＭＬ　Ｐａｇｅの下位要素として最高レベルで現れる場合）でもローカル（ＦＩＥＬＤまたはＭＥＮＵの下位要素として）でもよい。ＦＩＥＬＤ内またはＭＥＮＵ内で、ローカルＥＸＣＥＰＴＩＯＮＭＡＰは、２つのマップの間で矛盾するＥＸＣＥＰＴＩＯＮ（以下を参照）に関してグローバルＥＸＣＥＰＴＩＯＮＭＡＰに優先する。ローカルＥＸＣＥＰＴＩＯＮＭＡＰと全く矛盾のないグローバルＥＸＣＥＰＴＩＯＮＭＡＰ内のＥＸＣＥＰＴＩＯＮに関しては、ＦＩＥＬＤ内またはＭＥＮＵ内であってさえも、グローバルなケースとやはり同じ効果を有する。ＦＩＥＬＤまたはＭＥＮＵをエグジットした後、当該のＥＸＣＥＰＴＩＯＮＭＡＰは、当該のグローバルＥＸＣＥＰＴＩＯＮＭＡＰに戻る。
【００４６】
ＥＸＣＥＰＴＩＯＮＭＡＰは、ＥＸＣＥＰＴＩＯＮ子要素を有することが可能であり、この要素は、例外と、そのような例外に遭遇した場合、対応するページを取り出すＵＲＬの間のマッピングを指定する。ＥＸＣＥＰＴＩＯＮは、３つの可能な属性、必須であるＥＶＥＮＴ、グローバルＥＸＣＥＰＴＩＯＮＭＡＰに必須のＨＲＥＦ、およびＭＥＮＵ内またはＦＩＥＬＤ内でＥＸＣＥＰＴＩＯＮＭＡＰのためにＨＲＥＦの代りに使用することができるＲＥＰＥＡＴを有する。
ＥＶＥＮＴ　　可能な値：
ＴＯＯＦＥＷＤＩＧＩＴＳ−ＦＩＥＬＤ内で該当する。発呼者によって入力された数字の数が、期待されるよりも少ない。
ＴＩＭＥＯＵＴ−前のＰＡＵＳＥタグによって指定された期間内に発呼者が、入力を全く入力しなかった。
ＣＡＬＬＥＲＨＵＰ−発呼者が、不意にハングアップする
ＯＴＨＥＲ−予期しない例外に対するキャッチオール
ＨＲＥＦ　　遭遇したＥＶＥＮＴによって指定される例外が生成された場合に次のページを取り出すＵＲＬ。この属性は、現在のページ中のラベルもポイントすることができる（以下のＡ要素の説明を参照）。
ＲＥＰＥＡＴ　　値は、ＭＥＮＵ内またはＦＩＥＬＤ内で指定されたＥＸＣＥＰＴＩＯＮＭＡＰのための「ＭＥＮＵ」または「ＦＩＥＬＤ」であることが可能である。これにより、制御が、ＥＸＣＥＰＴＩＯＮが生じた場合、ＭＥＮＵ／ＦＩＥＬＤの開始におけるＰＬＡＹに戻ることができる。
【００４７】
ＥＸＣＥＰＴＩＯＮは、任意の時点で起こすことができ、完全に非同期のイベント（例えば、発呼者が、突然、ハングアップする）であるのが可能である。したがって、ＩＶＲアプリケーションによって送信される最初のＸＭＬ　Ｐａｇｅの１つでデフォルトのグローバルＥＸＣＥＰＴＩＯＮＭＡＰを指定することが有用である。ＥＸＣＥＰＴＩＯＮは、子を有さない。
【００４８】
ＭＥＮＵ要素は、ＰＯＰサーバにメッセージを再生させ、次に発呼者の選択（選択メニューからの）を収集させ、そのような選択に基づいて新しいＸＭＬ　Ｐａｇｅを取り出させる能力をＩＶＲアプリケーションに提供する。発呼者は、トーン・キーを入力すること、または語または句を言うことによって（音声認識がサポートされる場合）自らの選択を行うことができる。ＭＥＮＵは、１つの属性を有する。
ＭＡＸＲＥＰＥＡＴＳ　　（オプション）制御が、ＭＥＮＵの開始に戻ることのできる最大回数。無限ループを防止するため、制御は、連続でＭＡＸＲＥＰＥＡＴＳ回数を超えてＲＥＰＥＡＴ例外に遭遇した場合、ページの最上部で指定されるＸＭＬ　Ｐａｇｅタグ内で指定されるＨＲＥＦに行く。ＭＡＸＲＥＰＥＡＴＳは、Ａ（アンカー）ラベルを使用することにより、制御がＦＩＥＬＤタグに戻る場合にも適用されることに留意されたい。
【００４９】
ＭＥＮＵは、次の子を有することができる。ＰＬＡＹ、ＴＯＮＥＭＡＰ、ＶＯＩＣＥＭＡＰ、およびＥＸＣＥＰＴＩＯＮＭＡＰ。ＴＯＮＥＭＡＰとＶＯＩＣＥＭＡＰのどちらかまたは両方が、存在しなければならない。ＭＥＮＵ内で使用されるとき、ＰＬＡＹは、ＰＡＵＳＥ下位要素を含んで、発呼者が、その期限内にトーンを入力する、または音声入力を提供するものとされるタイムアウトを指定しなければならない。発呼者が、タイムアウト期間内にトーン／音声入力を全く入力しなかった場合、制御は、ＴＩＭＥＯＵＴ　ＥＸＣＥＰＴＩＯＮで指定されるＨＲＥＦに行くことが可能である。ローカルＥＸＣＥＰＴＩＯＮＭＡＰ内でＴＩＭＥＯＵＴ　ＥＸＣＥＰＴＩＯＮが指定されていない場合、グローバルＥＸＣＥＰＴＩＯＮＭＡＰが調べられる。グローバルなレベルにおいてさえもＴＩＭＥＯＵＴ　ＥＸＣＥＰＴＩＯＮが存在しない場合には、現在のＸＭＬ　ＰａｇｅのＨＲＥＦ属性内で指定される次のページが取り出される。例外を扱うこの同じ階層をすべての例外に関して使用することができる。また、Ａ下位要素（以下を参照）を使用してＸＭＬ　ＰａｇｅのＨＲＥＦ属性内の＃ラベルを指定することにより、制御を現在のＸＭＬ　Ｐａｇｅ上のアンカー／ラベルに渡すことも可能である。
【００５０】
ＦＯＲＭ要素を使用してＰＯＰサーバに指示し、ＦＩＥＬＤの数に関する情報（例えば、マルチキー入力または音声記録）を収集し、次に、ＮＡＭＥ、ＶＡＬＵＥの対としてこの情報をＦＯＲＭ内で指定されるＨＲＥＦに送り返すようにさせることができる。
【００５１】
ＦＯＲＭは、次の属性を有することが可能である（ＨＲＥＦだけが必須である）。
ＨＲＥＦ　　発呼者から収集した情報を送信する先のＵＲＬ。このＵＲＬは、通常、２進プログラムまたはＰｅｒｌ、Ｊａｖａ（登録商標）またはＡＳＰスクリプトである。
ＭＥＴＨＯＤ　　（オプション）ＧＥＴまたはＰＯＳＴ。データが、ＵＲＬに照会ストリングとして送信されるか、標準入力として送信されるかを指定する。
ＳＲＣ　　（オプション）ＦＯＲＭ内でサブミットされたデータが、ＩＶＲアプリケーションによって処理されている間に再生するファイル（例えば、．ｖｏｘファイル）のＵＲＬ。ファイルは、通常、「貴方の入力を処理する間、お待ちください」などのメッセージを含む。ＳＲＣ属性が含まれない場合、発呼者は、ＦＯＲＭデータを処理した後、ＩＶＲアプリケーションが次のＸＭＬ　Ｐａｇｅを送信するのをＰＯＰサーバが待っている間、沈黙を聴く。
ＳＵＢＭＩＴ＿ＰＡＲＴＩＡＬ　（　オプション）この属性は、発呼者が、フィールドのいくつかまたはすべてを埋めた後、ハングアップして、ＩＶＲアプリケーションと対話するようにオンラインに留まらない場合、ＦＯＲＭが、ＩＶＲアプリケーションにサブミットされるべきかどうかを指定する。可能な値は、次のとおりである。
ＰＡＲＴＩＡＬ＿ＯＫ：埋められているあらゆるフィールドに関する値を送信する
ＣＯＭＰＬＥＴＥ＿ＯＮＬＹ：すべてのフィールドが埋められている場合だけ、値を送信する
ＬＡＳＴ＿ＦＩＥＬＤ＿ＨＵＰ：すべてのフィールドが埋められ、発呼者が、ＩＶＲとまだ対話している、または発呼者が、最後のフィールドに対するデータを入力している（または音声を記録している）最中にハングアップした場合、値を送信する
ＰＯＳＴＨＲＥＦ　　（オプション−音声フィールドに関してだけ）。この属性は、音声記録ファイルを受け取るアプリケーションのＵＲＬである。発呼者によって記録されたメッセージを含む音声ファイルは、ネットワーク・マネージャによって決定される後の時点にＰＯＰサーバによってＰＯＳＴされる。（ソフトウェア・アプリケーションであることが可能な）マネージャは、音声記録ファイルをトランスポートする際、余りにも多くの可用ネットワーク帯域幅が消費されないことを確実にする。ＰＯＳＴＨＲＥＦ　ＵＲＬは、照会ストリング内に以下を含む：
？ＳＥＳＳＩＯＮＩＤ＝＄ｓｅｓｓｉｏｎｉｄ＄＆
ＦＩＥＬＤＮＡＭＥ＝＄ｆｉｅｌｄｎａｍｅ＄＆ＲＥＳＵＬＴ＝＄ｓｔａｔｕｓ＄
【００５２】
ＦＯＲＭは、ＰＯＰサーバが、ＩＮＰＵＴ下位要素内で指定されたある規則に従って単一の名前付きフィールドに関する情報（例えば、マルチキー入力または音声記録）を収集するのを可能にする１つまたは複数のＦＩＥＬＤ子を有するのが可能である。ＦＩＥＬＤは、以下の属性を有する。
ＨＲＥＦ　　（ＶＯＩＣＥに関してだけ）。音声ファイルの記録が完了した後、音声ファイルの内容がＰＯＳＴされるＵＲＬ。ＨＲＥＦが指定されない場合には、ネットワーク・マネージャが、ＦＲＯＭ内で指定されたＰＯＳＴＨＲＥＦにファイルをＰＯＳＴする。
ＭＡＸＲＥＰＥＡＴＳ　　（オプション）制御が、ＦＩＥＬＤの開始に戻ることのできる最大回数。無限ループを防止するため、制御は、連続でＭＡＸＲＥＰＥＡＴＳ回数を超えてＲＥＰＥＡＴ例外に遭遇した場合、ページの最上部で指定されるＸＭＬ　Ｐａｇｅタグ内で指定されるＨＲＥＦに行く。ＭＡＸＲＥＰＥＡＴＳは、Ａ（アンカー）ラベルを使用することにより、制御がＦＩＥＬＤタグに戻る場合にも適用されることに留意されたい。
ＦＩＥＬＤは、常に、以下の下位要素から成るトリプレットから構成されなければならない。ＰＬＡＹ、ＩＮＰＵＴ、およびＥＸＣＥＰＴＩＯＮＭＡＰ。
【００５３】
ＩＮＰＵＴ要素は、ＦＩＥＬＤに関する入力を収集するためにＰＯＰサーバにおける電話インターフェースに関する規則を指定する。この要素は、以下の属性を有することが可能である。
ＮＡＭＥ　　発呼者の入力をそこで収集する変数の名前。ＶＯＩＣＥ入力の場合、ＮＡＭＥの値（ＮＡＭＥ内では、ＶＡＬＵＥの対が、ＦＯＲＭによって送り返される）は、アプリケーションによってＲＥＣＦＩＬＥタグ内で戻されるＦＩＬＥＮＡＭＥであるか、またはＰＯＰサーバ上にローカルで記憶された記録ファイルのＵＲＬである（ＦＩＥＬＤタグに関するＨＲＥＦ属性の説明も参照）。ＰＯＳＴＨＲＥＦがＦＯＲＭ内で指定される場合、ＮＡＭＥの値（ＮＡＭＥ内では、ＶＡＬＵＥの対が、ＦＯＲＭによって送り返される）は、ＰＯＰサーバ上にローカルで記憶された記録ファイルの名前である。
ＴＹＰＥ　　（オプション）期待される入力のタイプを示すＴＯＮＥＳまたはＶＯＩＣＥまたはＥＩＴＨＥＲ。
ＭＩＮＤＩＧＩＴＳ　　（オプション）フィールドに必要な数字の最小数（音声に関しては有効でない）。
ＭＡＸＤＩＧＩＴＳ　　（オプション）このフィールドに対して入力することのできる数字の最大数（音声に関しては有効でない）。ＡＣＣＥＰＴキーが指定された場合、それに対して１を追加する。
ＡＣＣＥＰＴ　　（オプション）ユーザの入力の終わりを示すトーン・キー　　ＭＡＸ＿ＩＤＤ　　（オプション）ユーザの入力の出力がその後、暗黙に示される秒単位の最大数字間遅延
ＭＡＸＳＩＬＥＮＣＥ　　（オプション）音声入力の記録中、ユーザの入力が暗黙に示されるまでの最長の沈黙（秒単位の）
ＭＡＸＲＥＣＬＥＮ　　（オプション）音声入力の記録中、記録することができる秒単位のメッセージの最大長。
ＶＯＩＣＥＦＩＬＥ＿ＦＯＲＭＡＴ　　（オプション）記録ファイルに関する所望の形式およびサンプリング・レート。
ＩＮＰＵＴは、子を有さない。
【００５４】
ＰＯＳＴＨＲＥＦが、ＦＯＲＭタグ内で指定される場合には、ＩＶＲアプリケーションは、ＩＮＰＵＴ　ＮＡＭＥ属性内で指定された異なるフィールドに関するＮＡＭＥ、ＶＡＬＵＥの対を有するＨＴＴＰ　ＧＥＴ要求を最初に受け取る。値は、ＰＯＰサーバ上にローカルで記憶されている記録ファイルの名前である。必要な場合、ＩＶＲアプリケーションは、発呼者に対して記録ファイルの内容を再生することができる。後に、ＩＶＲアプリケーションは、内容として記録されたファイルの２進データを有する複数のＨＴＴＰ　ＰＯＳＴ要求を受け取る。
【００５５】
ＲＥＣＦＩＬＥタグは、ＶＯＩＣＥフィールド入力に対するデータを含むＰＯＳＴ要求に応答して、ＩＶＲアプリケーションによって使用されるのが可能である。このタグは、以下の属性を有する。
ＦＩＬＥＮＡＭＥ　　ＰＯＳＴされた音声データが、ＩＶＲアプリケーション・サーバによってそこに記憶されたファイルの名前。
ＲＥＣＦＩＬＥは、子を有さない。
【００５６】
「Ａ」（アンカー）要素をＸＭＬ　Ｐａｇｅ内のラベル付け機構として提供することができる。ＵＲＬは、＃名前（ＨＴＭＬにおけるように）を使用することによって現在のＸＭＬ　Ｐａｇｅ中または異なるＸＭＬ　Ｐａｇｅ中の目標を指定することができる。この要素は、ＰＯＰサーバに指示してページの開始においてではなく、ページ中のラベル付けされたポイントでＸＭＬ　Ｐａｇｅの構文解析および実行を開始するようにさせる能力を提供する。また、この要素は、現在のＸＭＬ　Ｐａｇｅ中のあるポイントにジャンプするための機構としても使用することができる。Ａは、１つの必須の属性を有し、子は有さない。
ＮＡＭＥ　　このアンカーが、それにより、ＵＲＬによって参照されるラベル名
【００５７】
ＳＥＴ要素により、ＩＶＲアプリケーションは、ＰＯＰサーバによる後の置換のためにユーザ定義可能な変数の値を設定することが可能となる。この要素は、ＩＶＲアプリケーションが、特定の値と特定の変数名の間の関連を指定して、ＩＶＲアプリケーションが同一のＸＭＬ　Ｐａｇｅ中または別のＸＭＬ　Ｐａｇｅ中で後に変数名を使用する際に、ＰＯＰサーバが変数名を値で置き換えなければならないようにするのを可能にする便利な機構である。ＳＥＴは２つの必須の属性を有し、子は有さない。
ＶＡＲＮＡＭＥ　　変数の名前
ＶＡＬＵＥ　　変数に割り当てられる値
【００５８】
したがって、ＳＥＴは、状態のないＩＶＲアプリケーションに、状態を維持してあらゆるＷＥＢサーバ環境に対するセッション変数を使用する強力な機構を提供する。ＩＶＲアプリケーションは、ＳＥＴタグを使用することにより、セッション変数（現在のセッション／コールの生存期間中、持続する変数）の値を定義し、設定することができる。セッション変数の値は、変数の値を使用する必要があるアプリケーションＵＲＬの照会ストリング内に変数を入れることで、アプリケーションによって後に検索されることが可能である。
【００５９】
以下に説明するのは、ＩＶＲアプリケーションがＰＯＰサーバに発行することができるコール制御指向のタグである。ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬ要素が、アウトバウンドのコールを行うため、ＩＶＲアプリケーションによって送信されるのが可能である。ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬの属性は、以下のとおりである。
ＴＥＬＮＵＭ　　電話サーバが呼び出す必要のある電話番号
ＩＶＲＵＲＬ　　アウトバウンドのコールが行われ、コールに応答があった後、新しいレッグの会話コントローラが、そこから、その第１のＸＭＬ　Ｐａｇｅを取り出さなければならないＵＲＬ。この属性は、オーディオ・メッセージを再生するため、または他のＶＲＣＬコマンドを実行するためにＩＶＲアプリケーションによって使用されるのが可能である。また、この属性は、ＬＥＧ＿ＷＡＩＴの値を実行することもでき、その場合、新しい会話コントローラは、単に、割込み可能な待機状態に入り、着呼番号で電話に応答する人は、割込みが会話コントローラにコールをブリッジさせるまで沈黙を聴く。ＩＶＲＵＲＬは、ＢＲＩＤＧＥ属性がＹＥＳに設定されているときは、使用されない。
ＡＮＩ　　（オプション）電話マネージャが発信コールで送信すべきＡＮＩ　　ＢＲＩＤＧＥ　　（オプション）ＹＥＳまたはＮＯ。ＹＥＳの場合、新しいコールのダイヤル呼出しが行われ、応答があるとすぐに、新しいコールが、現在のＬＥＧ上のコールとブリッジされる。
【００６０】
ＴＥＬＮＵＭ属性は、その値の中にコンマを含むことが可能である。コンマはＴＥＬＮＵＭ内で２つの意味を有する。第１のコンマ（左から）は、第１のコンマの左側の数字が、ダイヤルアウトしてコールを確立するために使用され、一方、第１のコンマの右側の数字が、確立されたコール上で帯域内ＤＴＭＦトーンとして送出されることを意味する。第１のコンマの右側の数字内のコンマは、ＤＴＭＦトーン・シーケンス内の各コンマごとに一時停止が挿入されるべきことを意味する。例えば、ＴＥＬＮＵＭ＝「１２１５９０９０，，，＊＊，９００６１２３４＃」は、コールを確立するために１２１５９０９０をダイヤルし、一時停止し、＊＊トーンを送信し、一時停止し、９００６１２３４＃トーンを送信するように電話サーバに命令する。どのトーンも、コールに応答があってからでないと送信しないことを確実にするため、より良好な制御が必要な場合、作成されたレッグをＩＶＲＵＲＬに送信し、これらのタグをＩＶＲＵＲＬによって送り返されたＸＭＬ　Ｐａｇｅ中で使用することにより、ＰＬＡＹ　ＤＴＭＦタグを使用しなければならない。その場合、ＢＲＩＤＧＥ＝ＮＯオプションが、使用されるべきである。ＴＥＬＮＵＭフィールド内でコンマを使用することにより、ダイヤルアウトを固定された一時停止と組み合わせて、何らかの帯域内ＤＴＭＦトーンを送信するための便利な機構が提供されるが、これは、ＤＴＭＦタグほど多くの制御は提供しない。
【００６１】
ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬは、全く子を有さない。通常、ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬタグには、他のレッグがこのレッグと同期化するのを待つため、ＬＥＧ＿ＷＡＩＴタグ（またはＰＬＡＹ、その後にＬＥＧ＿ＷＡＩＴ）が続く。
【００６２】
このタグを受信すると、電話サーバは、ＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬ＿ＲＥＱ　ＮｅｘｔＡｃｔｉｏｎ要求をＣＦＭに送信する。ＣＦＭは、適切な電話サーバ上にアウトバウンド・ポートを予約し（ＴＥＬＮＵＭに基づいて）、電話サーバ上に新しい会話コントローラを作成し、次に、ＤＩＡＬ＿ＣＡＬＬ　ＸＭＬタグおよび（オプションとして）ＢＲＩＤＧＥ＿ＣＡＬＬタグをその新しい会話コントローラに送信してアウトバウンドのコールを行い、そのコールを現在のコールにブリッジする。誤りがあった場合、誤りのタイプに応じて、グローバルＥＸＣＥＰＴＩＯＮＭＡＰが調べられ、ＣＲＥＡＴＥ＿ＬＥＧ＿ＥＲＲＯＲ、ＤＩＡＬ＿ＥＲＲＯＲ、またはＢＲＩＤＧＥ＿ＥＲＲＯＲに対応するＵＲＬにコンタクトが行われる。
【００６３】
ＨＡＮＧ＿ＵＰ＿ＡＮＤ＿ＤＥＳＴＲＯＹ＿ＬＥＧ要素が、ＩＶＲアプリケーションによって使用されて、指定されたレッグ上のコールが終了されるべきこと、およびこのタグを受け取った会話コントローラ（ＬＥＧ）が破棄されるべきことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＥＲＲＯＲまたはＣＡＬＬＥＲＨＵＰ。
この要素は、下位要素を全く有さない。
【００６４】
ＱＵＥＵＥ＿ＣＡＬＬタグは、ＩＶＲアプリケーションによって送信され、コールを保留することができる。このタグは、以下の属性を有する。
ＡＧＥＮＴＧＲＰ　　コールが待ち行列に入れられるべきエージェント・グループを識別する（例えば、ＳＡＬＥＳ）。
ＳＴＡＴＵＳ＿ＩＮＴ＿ＴＩＭＥ　（　オプション）この属性は、ＩＶＲアプリケーションが、待ち行列に入れられたコールのステータスについて通知を受けるべき間隔である。
ＳＴＡＴＵＳ＿ＩＮＴ＿ＵＲＬ　　（オプション）この属性は、ＩＣＲ／ＡＣＤステータスを与えるＣＦＣ割込みを受け取った後、保留中のコールのステータスに関してＩＶＲがそこで通知を受けるべきＵＲＬである。（グローバルＥＸＣＥＰＴＩＯＮＭＡＰ内のＱＵＥＵＥ＿ＥＲＲＯＲ例外が調べられる）。
ＡＣＤ＿ＴＥＬＮＵＭ　　（オプション）この属性は、ＡＣＤでコールを待ち行列に入れるために電話サーバによってダイヤル呼出しされる必要のあるアウトバウンドの電話番号である。
ＡＮＩ　　（オプション）この属性は、ＡＣＤまたはＩＣＲに対して行われるアウトバウンドのコールにＰＯＰサーバが挿入することをＩＶＲアプリケーションが望むＡＮＩである。これは、電話番号またはストリング＄ＡＮＩ＄であることが可能である。
ＵＳＲ＿ＰＡＲＡＭＳ　　（オプション）発呼者が、オペレータへの転送を要求する前にＩＶＲシステムに入力した情報。このフィールドは、下位パラメータおよびコロン（「：」）で区切られた値を含み、異なるパラメータ−値の対が、コンマによって区切られている。例えば、ＰＡＲＭ１：２５、ＰＡＲＡＭ２：話中音、ＰＡＲＡＭ３：４１１。下位パラメータの名前および値は、ＡＣＤによる解釈のため、ＡＣＤアダプタによって翻訳される。
ＡＧＥＮＴ＿ＵＲＬ　　（オプション）この属性は、ＡＣＤに対するアウトバウンドのコールを有する電話サーバのＬＥＧが、ＡＧＥＮＴが接続された後、そのＸＭＬ　Ｐａｇｅをそこから得るべきＵＲＬである。これは、コールが発呼者のコールにブリッジされる前に、何らかの発呼者関連情報をエージェントの電話機に流すために使用することができる。
ＱＵＥＵＥ＿ＣＡＬＬは、オプションとして、ＥＸＣＥＰＴＩＯＮＭＡＰを子として有することが可能である。
【００６５】
コールの保留を続ける価値がなく、コールがＡＣＤ待ち行列からドロップされるべきであると発呼者および／またはアプリケーションが判定したとき、ＱＵＥＵＥ＿ＤＲＯＰタグが、ＩＶＲアプリケーションによって送信される。このタグは、属性を全く有さないが、ＱＵＥＵＥ＿ＤＲＯＰは、オプションとして、ＥＸＣＥＰＴＩＯＮＭＡＰを子として有することが可能である。
【００６６】
会話に関して１つだけの待ち行列が存在するのが可能であるため、ドロップされるＱＵＥＵＥの識別は、暗黙に示される。電話サーバは、このタグを受け取った後、ＱＵＥＵＥ＿ＤＲＯＰ＿ＲＥＱをＣＦＭに送信する。
【００６７】
ＢＲＩＤＧＥ＿ＣＡＬＬタグが、ＩＶＲアプリケーションによって送信されて、現在のコール（現在のレッグ上のコール）を同じＰＯＰサーバ上の別のコールと、または異なるＰＯＰゲートウェイ上の異なるゲートウェイ上のコールとブリッジする。ＢＲＩＤＧＥ＿ＣＡＬＬは、１つの必須の属性を有する。
ＬＥＧ＿ＩＤ　　現在のレッグ上のコールとブリッジされる他のレッグの識別。ＡＬＬという値が、現在のレッグ上のコールをこのセッションの様々なレッグに関連する他のすべてのコールとブリッジする。
ＢＲＩＤＧＥ＿ＣＡＬＬは、オプションとして、ＥＸＣＥＰＴＩＯＮＭＡＰを子として有するのが可能である。
【００６８】
２つのコールがブリッジされた後、すべてのブリッジされたコールは、ＬＥＧ＿ＷＡＩＴ状態に入る。コールをブリッジする際に誤りが存在した場合、ＢＲＩＤＧＥ＿ＥＲＲＯＲ例外が生成され、例外の中で指定されるＨＲＥＦから次のＸＭＬ　Ｐａｇｅが取り出される。
【００６９】
コールの様々なレッグ間のブリッジを解除するため、ＵＮＢＲＩＤＧＥ＿ＣＡＬＬタグを有するＸＭＬ　Ｐａｇｅが、ＩＶＲアプリケーションによって送信される。ＵＮＢＲＩＤＧＥ＿ＣＡＬＬの属性は、以下のとおりである。
ＬＥＧ＿ＩＤ　　（必須）ブリッジ解除される他方のレッグを識別するのに使用される。ＡＬＬという値が、現在のレッグのコールと現在のコールにブリッジされた他のすべてのコールの間のブリッジを解除する。
ＯＴＨＥＲ＿ＬＥＧ＿ＵＲＬ　（　オプション）他方のレッグが、ブリッジ解除された後、次のＸＭＬ　Ｐａｇｅをそこから取り出すべきＵＲＬ。この属性が省略される場合、他方のレッグは、ＬＥＧ＿ＷＡＩＴ状態に保たれ、それらのレッグをウェイクアップするのにＡＬＥＲＴ＿ＬＥＧタグが必要とされる。
レッグの１つは、暗黙的に、このＵＮＢＲＩＤＧＥ＿ＣＡＬＬタグを受け取るレッグである。
【００７０】
ＵＮＢＲＩＤＧＥ＿ＣＡＬＬは、オプションとして、ＥＸＣＥＰＴＩＯＮＭＡＰを子として有するのが可能である。コールのブリッジ解除が行われた後、ＰＯＰサーバが、ＵＮＢＲＩＤＧＥ＿ＣＡＬＬタグに続く次のタグを実行するか、または（次のタグが存在しない場合）ページの最上部のＸＭＬ　Ｐａｇｅルート要素タグ内で指定されたＨＲＥＦから次のＸＭＬ　Ｐａｇｅを取り出す。コールのブリッジ解除を行う際に誤りが存在した場合、ＵＮＢＲＩＤＧＥ＿ＥＲＲＯＲ例外が生成され、次のＸＭＬ　Ｐａｇｅが、例外の中で指定されたＨＲＥＦから取り出される。
【００７１】
ＬＥＧ＿ＷＡＩＴタグを有するＸＭＬページが、ＩＶＲアプリケーションによって送信されて、このタグを受け取る会話コントローラを待機状態にする。会話コントローラは、電話マネージャからのイベント（例えば、発呼者のハングアップ）、またはＣＦＭからの割込み、またはＩＶＲアプリケーションからのＡＬＥＲＴ＿ＬＥＧタグを待つ以外は、何も行わないものとされる。ＬＥＧ＿ＷＡＩＴは、属性を有さず、また子を有さない。
【００７２】
ＡＬＥＲＴ＿ＬＥＧタグがＩＶＲによって使用されて、ＬＥＧ＿ＷＡＩＴ状態にある会話コントローラ・スレッドに割込みを行い、属性として指定されたＵＲＬにＨＴＴＰ　ＧＥＴ要求を送信するようにこのスレッドに命令する。ＡＬＥＲＴ＿ＬＥＧの属性は、以下のとおりである。
ＬＥＧ＿ＩＤ　　警報を受ける他方のレッグの識別子。警報を受けるレッグは、通常、ＬＥＧ＿ＷＡＩＴ状態にある。ＡＬＬという値が使用される場合、このセッションの他のすべてのレッグが警報を受ける。
ＩＶＲＵＲＬ　　警報を受けた後、他方のレッグのために次のＸＭＬ　Ｐａｇｅをそこから取り出すＵＲＬ。
ＡＬＥＲＴ＿ＬＥＧは、子を有さない。このタグは、例えば、コールのブリッジ解除を行った後、他方のレッグに警報を行い、そのレッグを指定されたＵＲＬにダイレクトするのに使用することができる。
【００７３】
ＥＮＤ＿ＳＥＳＳＩＯＮがＩＶＲアプリケーションによって使用されて、現在のセッションのすべてのＬＥＧを破棄し、すべての関連コールをハングアップすることが可能である。これは、電話サーバによってＣＦＭに送信されるＥＮＤ＿ＳＥＳＳＩＯＮ＿ＲＥＱ ＮｅｘｔＡｃｔｉｏｎ要求に翻訳される。そのような要求を受信すると、ＣＦＭは、ＨＡＮＧＵＰ＿ＣＡＬＬタグおよびＤＥＳＴＲＯＹ＿ＬＥＧタグをセッションに関連するすべての会話コントローラ・スレッドに送信する。
【００７４】
前述したタグの使用のいくつかの例が、この時点で有用であろう。第１の例、例１では、ウェルカム・メッセージをプレイアウトし、グローバルＴＯＮＥＭＡＰおよびグローバルＥＸＣＥＰＴＩＯＮＭＡＰを設定するためのＸＭＬ　Ｐａｇｅが提示される。最初に、ページ・タイプおよび顧客識別子が指定される。「ｃｕｓｔｏｍｅｒ．ｃｏｍ」のコール・センタ・サーバＵＲＬは、様々なページが記憶されるアドレスとして使用されることに留意されたい。
〔例１〕
〔Ａ〕
2004500754.tif 000003
【００７５】
次に、グローバルＴＯＮＥＭＡＰを定義する。ＴＯＮＥＭＡＰにより、発呼者は、任意の時点で０を押してオペレータに到達すること、または＊キーを押してログイン・メニューに直接に行くことができる。また、発呼者が、無効なキーを押した場合、そのようなケースを扱う指定されたＨＲＥＦに配置された別のＸＭＬ　Ｐａｇｅに制御が渡される。これは、新しいＴＯＮＥＭＡＰによってオーバーライドされない限り、後続のすべてのページに適用される。
2004500754.tif 000004
【００７６】
次に、グローバルＥＸＣＥＰＴＩＯＮＭＡＰを定義することができる。ＥＸＣＥＰＴＩＯＮＭＡＰは、発呼者が、ＦＩＥＬＤ値を入力するように、またはＭＥＮＵから選択を行うように求められたとき、指定されたタイムアウト期間内にキーを押せなかったときはいつでも、例外が生成されるようにさせる。このとき、制御は、指定されたタイムアウト例外ハンドラ（ｔｉｍｅｏｕｔ．ａｓｐ？ＳＥＳＳＩＯＮＩＤ＝３）に渡される。また、例外は、発呼者が突然にハングアップした場合にも生成される。各ＥＸＣＥＰＴＩＯＮ内のＨＲＥＦ属性は、そのような例外が生じた場合、どのＸＭＬ　Ｐａｇｅを次に取り出すかを指定する。グローバルＥＸＣＥＰＴＩＯＮＭＡＰは、オーバーライドされない限り、後続のすべてのページに適用される。
2004500754.tif 000005
【００７７】
次に、挨拶メッセージを再生するコマンドを発行することができる。メッセージには、発呼者によって割込みが行われるべきではなく、したがって、メッセージが再生されている間に発呼者が押す可能性があるどのキーも無視する命令が存在する。
2004500754.tif 000006
ページの終りに達すると、最初のＰａｇｅの開始で指定された次のＸＭＬ　Ｐａｇｅが取り出される（ｉｎｉｔｉａｌ．ａｓｐ）。
【００７８】
第２の例、例２は、１組の選択を告知し、発呼者から単一のトーン入力を受け入れるためのＸＭＬ　Ｐａｇｅが提供される。
2004500754.tif 000007
【００７９】
前のＰａｇｅ上に指定されたグローバルＴＯＮＥＭＡＰで（例１からの）、このＰａｇｅのローカルＴＯＮＥＭＡＰは、「０」、「＊」、「２」のすべてが有効な応答であるようにする。ＭＥＮＵをエグジットした後、ＭＥＮＵ内で指定されたＴＯＮＥＭＡＰは、もはや適用可能ではなく、「０」および「＊」だけが有効なトーンとして受け入れられることになる。ＸＭＬ　Ｐａｇｅ中のＦＯＲＭ内またはＭＥＮＵ内で処理される必要のあるどのグローバル・マップも（ＥＸＣＥＰＴＩＯＮＭＡＰならびにＴＯＮＥＭＡＰ）、ＦＲＯＭまたはＭＥＮＵよりも上に配置されなければならない。ＸＭＬ　Ｐａｇｅ中のタグの実行は、順次に行われる性質のものである。Ｐａｇｅの終りで定義されるマップが、そのＰａｇｅ中で実行されるタグに影響を与えるのを期待することはできない。上記のＭＥＮＵ内のＰＬＡＹのＰＡＵＳＥ下位要素内で指定されたタイムアウト期間内に、発呼者によってトーンが入力されない場合、ＴＩＭＥＯＵＴ例外が生成され、制御は、対応するＨＲＥＦに（この例では、ＮＡＭＥ＝「ラベル１」を有するＡラベルに）移る。無効なキーが入力された場合、ＴＯＮＥＩＤ＝ＯＴＥＨＲが適用され、制御は、やはりラベル１に移る。ＲＥＰＥＡＴ＝「ＭＥＮＵ」をＨＲＥＦ＝＃ラベル１の代りに使用して、ＴＭＥＯＵＴ　ＥＸＣＥＰＴＩＯＮで同じ効果を得ることも可能である。
【００８０】
次の例３では、１組の入力フィールド（社会保障番号およびパスワード）を受け入れるためのＸＭＬ　Ｐａｇｅが提示される。ＦＯＲＭ要素により、発呼者は、データがコール・センタに送られる前に複数のＦＩＥＬＤを入力することができる。例えば、以下では、ｓｓｎｕｍＦＩＥＬＤとｐａｓｓｗＦＩＥＬＤの両方のためのＦＯＲＭデータが収集された後に送信される（終了タグ＜／ＦＯＲＭ＞が現れたとき）。
2004500754.tif 000008
【００８１】
ＦＯＲＭ内の様々なフィールドに対して発呼者によって入力されたあらゆる入力が、ＦＯＲＭ内のＨＲＥＦ属性によって指定されたＵＲＬに照会ストリング（ＵＲＬの後に？およびＮＡＭＥ、ＶＡＬＵＥの対が続く）として送信される。この照会ストリングは、終了タグ＜／ＦＯＲＭ＞が現れたときに送信される。ＩＮＰＵＴ内のＭＡＸ＿ＩＤＤ＝「２」属性は、最後のキーが入力されてから２秒間、何もキーが入力されない場合、あたかもＡＣＣＥＰＴキーが入力されたかのように、発呼者が入力値を入力するのを終えたものと見なされることを指定する。（ＩＤＤは、Ｉｎｔｅｒ−ｄｉｇｉｔ−ｄｅｌａｙの省略である）。ＴＩＭＥＯＵＴイベントとＭＡＸ＿ＩＤＤの区別は、かなり微妙である。音声ファイルの再生が停止した後、ＰＡＵＳＥのＴＩＭＥ属性によって指定された期間内に第１の数字さえ入力されない場合、ＥＶＥＮＴ＝ＴＩＭＥＯＵＴを有するＥＸＣＥＰＴＩＯＮが生じる。ただし、ＴＩＭＥ秒内に１つまたは複数の数字が入力され、次に、ＭＡＸ＿ＩＤＤ秒間にわたって全く数字が入力されない場合、フィールド入力は、完了したものと見なされる。パスワード・フィールドに対するＭＡＸＤＩＧＩＴＳは、最大パスワード長が７であるものの、８と指定される。これは、ＡＣＣＥＴＰ文字である＃キーに対応するためである。
【００８２】
次の例４では、発呼者のアカウント記録（例えば、アカウント収支）を再生するためのＸＭＬ　Ｐａｇｅが提供される。
2004500754.tif 000009
2004500754.tif 000010
【００８３】
次の例５では、さよならメッセージを再生して、このコールを終了するために制御をＣＦＭに戻すためのＸＭＬ　Ｐａｇｅが提供される。
2004500754.tif 000011
【００８４】
以下の例６は、ＣＦＭに指示してコールをオペレータに転送させるためのＸＭＬ　Ｐａｇｅを提供する。
2004500754.tif 000012
【００８５】
ＩＶＲアプリケーションとＰＯＰゲートウェイの間の対話に加え、ＣＦＭとＩＶＲアプリケーションの間の対話も存在する。前述したとおり、ＣＦＭは、ＶＩＮ内のサーバ上で実行されるソフトウェア構成要素であり、コール・センタＩＶＲアプリケーションとＰＯＰゲートウェイ・サーバの間の通信を円滑にする。ＣＦＭとＩＶＲアプリケーションの間で直接の対話は、全く必要ない（また、これらが同じコンピュータ・プラットフォーム上に常駐するか、異なるプラットフォーム上に常駐するかも重要ではない）。代りに、これらのアプリケーションは、ＰＯＰサーバと直接に通信することができる。制御が、ＣＦＭからＩＶＲアプリケーションに渡される必要があるとき、ＣＦＭは、次のＨＲＥＦがＩＶＲアプリケーションのＵＲＬをポイントするＸＭＬ　ＰａｇｅをＰＯＰサーバに送信する。同様に、ＩＶＲアプリケーションは、制御をＣＦＭに送り返す必要があるとき、ＰＯＰサーバに指示して、ＣＦＭに関連するＵＲＬから次のＸＭＬ　Ｐａｇｅを要求するようにさせる。渡される必要のあるあらゆるパラメータが、ＨＴＴＰ要求の中でＵＲＬ名の後、照会ストリングの中の名前／値の対として送信される。これを以下の特定の例の助けを借りてより詳細に説明する。
【００８６】
着信コールがＰＯＰサーバにおいて受信されたばかりである状況を考慮されたい。中央ルックアップ・データベースの助けを借りて、ＰＯＰサーバは、着呼番号に対応する顧客の（すなわち、コール・センタ・プロバイダの）ＣＦＭ　ＵＲＬを知る。次に、ＰＯＰサーバは、以下のＵＲＬにＨＴＴＰ要求を送信する。
2004500754.tif 000013
この例では、＜ｃａｌｌ−ｍｇｒ−ｕｒｌ＞は、ルックアップ・サーバから獲得されたコール・フロー・マネージャのＵＲＬであり（また、照会ストリングを含まない）、＜ｄｉｄ＞は、着信コールに関する着呼番号であり、＜ａｎｉ＞は、着信コールに関する発呼者の番号であり、またＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＰＲＯＣＥＳＳ＿ＩＮＣＡＬＬは、ＣＦＭに必要な次の処理が、新しい着信コールを処理することであるのを示す。
【００８７】
以上に応答して、ＣＦＭは、コールが受け入れられるべきか、拒否されるべきか（あるリソースの可用性に応じて）を示すＸＭＬ　ＰａｇｅをＰＯＰサーバに戻すことができる。コールが受け入れられる場合、顧客のＩＶＲアプリケーションのＵＲＬが、ＳＥＳＳＩＯＮ　ＩＤとともに（ＡＣＣＥＰＴ＿ＣＡＬＬ）ＸＭＬ　Ｐａｇｅ中に含められ、ＳＥＳＳＩＯＮ　ＩＤは、ＰＯＰサーバと顧客のＩＶＲアプリケーションの間における将来のすべての通信に含められる。顧客のＩＶＲアプリケーションに対するＰＯＰサーバの第１のＨＴＴＰ要求は、次の形式を有することになる。
2004500754.tif 000014
この例では、＜ｉｖｒ−ｕｒｌ＞は、ＡＣＣＥＰＴ＿ＣＡＬＬページ中でＣＦＭによってＰＯＰサーバに送信されるＩＶＲアプリケーションのＵＲＬであり、＜ｓｅｓｓｉｏｎｉｄ＞は、ＡＣＣＥＰＴ＿ＣＡＬＬページ中でＣＦＭによってＰＯＰサーバに送信されるＳＥＳＳＩＯＮＩＤであり、＜ｄｉｄ＞は、着信コールに関する着呼番号であり、また＜ａｎｉ＞は、着信コール内の発呼者の番号である。
【００８８】
この時点からは、ＩＶＲアプリケーションが制御を行い、ＰＯＰサーバが、適切なタグを有するＸＭＬ　Ｐａｇｅ（前述した例１ないし６に提供されるＸＭＬ　Ｐａｇｅのような）の助けを借りて、どのプロンプトおよび選択を発呼者に提示しなければならないかを指示する。ＳＥＳＳＩＯＮＩＤが、ＰＯＰサーバからの各ＨＴＴＰ要求ごとの照会ストリングの一部として、またＩＶＲアプリケーションによって送信される各ＸＭＬ　Ｐａｇｅ中のＸＭＬ　Ｐａｇｅタグ内の属性として含められる。ＤＩＤおよびＡＮＩは、最初のＨＴＴＰ要求を除き、ＰＯＰサーバからのどのＨＴＴＰ要求の照会ストリング中に含まれる必要はない。
【００８９】
ＩＶＲアプリケーションは、コールを終了するため、またはアウトバウンドのコールを行うために制御をＣＦＭに戻す準備ができているとき、次の値を有するＨＲＥＦをＰＯＰサーバに送信することができる。
2004500754.tif 000015
【００９０】
ＣＦＭに伝送される必要があるＮｅｘｔＡｃｔｉｏｎ要求は、ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱおよびＥＮＤ＿ＣＡＬＬだけである。ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱは、新しいセッションを開始するようにＣＦＭに促すＷＥＢアプリケーション（例えば、Ｃｌｉｃｋ−ｔｏ−ｔａｌｋ）によって送信される割込みである。この要求のためのパラメータは、以下のとおりである。
ＩＶＲＵＲＬ：ＰＯＰサーバに対する次のＣＲＥＡＴＥ＿ＬＥＧ＿ＲＥＱ割込みの一部であるべきＵＲＬ。このパラメータは、新しい会話が開始された後、どこから次のＸＭＬ　Ｐａｇｅを取り出すべきかをＰＯＰサーバに指示する。
ＴＥＬＮＵＭが、新しい会話がそこで開始されるべきＰＯＰサーバ（およびゲートウェイ）をＣＦＭが識別するのを助ける。
ＮＵＭ＿ＬＩＮＥＳが、このセッションのために予約される必要があるアウトバウンドの電話回線の数を指定する。Ｃｌｉｃｋ−ｔｏ−ｔａｌｋアプリケーションの場合、この数は、常に２である。Ｃｌｉｃｋ−ｔｏ−ｔａｌｋアプリケーションで必要とされる第２の電話番号が、顧客アプリケーションのＩＶＲＵＲＬ内に担持されなければならない。
ＡＰＰ＿ＮＡＭＥが、この処理が所望されるアプリケーションを識別する。このパラメータは、この要求が、そこに出されなければならないＣＦＭプロセスをＣＦＭフロントエンドが識別するのを助ける。
ＦＡＩＬＵＲＥ＿ＵＲＬが、ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱを実行する際に障害が生じたことをＶＩＮの構成要素に知らせるのに使用すべきＵＲＬを指定する。
【００９１】
ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱ割込みに対する応答は、ＲＥＳＵＬＴ属性が成功または失敗を示す単一のＲＥＳＰＯＮＳＥタグを含むＸＭＬ　Ｐａｇｅでなければならない。ＸＭＬ　Ｐａｇｅヘッダ内のＨＲＥＦ属性は、空（“”）でなければならない。
【００９２】
ＩＶＲアプリケーション／発呼者による通常のハングアップまたは別の仕方では扱うことのできず、コールを終了する以外のオプションが存在しない誤りの状況（例えば、ＩＶＲサーバが停止したときなどの）に応答して、ＥＮＤ＿ＣＡＬＬ照会ストリングが、ＰＯＰサーバによってＣＦＭに送信されるのが可能である。ＩＶＲアプリケーションが、コールを終了することを望む場合、最後のＸＭＬ　Ｐａｇｅは、ＣＦＭをポイントするＨＲＥＦを有し、以下の照会ストリングを有することになる：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬ＆ａｍｐ；ＳＥＳＳＩＯＮＩＤ＝＄ｓｅｓｓｉｏｎｉｄ＄＆ａｍｐ；ＲＥＡＳＯＮ＝ＮＯＲＭＡＬ。発呼者が、ＩＶＲセッションの途中でハングアップした場合、ＰＯＰサーバは、まず、以下の照会ストリングを有するＨＴＴＰ要求をＣＦＭに送信する：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬプラス他の名前／値の対。また、ＰＯＰサーバは、ＣＡＬＬＥＲＨＵＰグローバルＥＸＣＥＰＴＩＯＮの一部として指定されたＵＲＬにおけるＩＶＲアプリケーションにもＨＴＴＰ要求を送信する。ＩＶＲサーバが、何らかの理由で停止した場合、ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰのＩＶＲ＿ＥＲＲＯＲ例外内に設定された値に応じて（ＰＯＰサーバは、その時点までには、＄ｌａｓｔ−ｅｒｒｏｒ＄、＄ｅｒｒｏｒ−ｕｒｌ＄、および＄ｌａｓｔ−ｅｒｒｏｒ−ｓｔｒｉｎｇ＄という値を既に設定していなければならない）、ＰＯＰサーバは、以下の照会ストリングをＣＦＣに送信することができる：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬ＆ａｍｐ；ＲＥＡＳＯＮ＝ＩＶＲ＿ＥＲＲＯＲ＆ａｍｐ；ＳＥＳＳＩＯＮＩＤ＝＄ｓｅｓｓｉｏｎｉｄ＄＆ａｍｐ；ＥＲＲＯＲ＝＄ｌａｓｔ−ｅｒｒｏｒ＄＆ａｍｐ；ＵＲＬ＝＄ｌａｓｔ−ｅｒｒｏｒ−ｕｒｌ＄＆ａｍｐ；ＤＥＳＣＲＩＰＴＩＯＮ＝＄ｌａｓｔ−ｅｒｒｏｒ−ｓｔｒｉｎｇ＄。
【００９３】
ＰＯＰサーバとＩＶＲアプリケーションの間における通信でそうであったように、ＰＯＰサーバとＣＦＭの間における通信の基本的方法は、ＸＭＬ　Ｐａｇｅの使用を介する。この通信は、着信コールがＰＯＰサーバに現れるとすぐに開始され、ネットワーク・オペレーション・センタ（ＮＯＣ）（図９を参照）を使用するＤＩＤ／ＣａｌｌＭｇｒＵＲＬ翻訳を介して、ＰＯＰサーバが、ＣＦＭのＵＲＬを知る。ＰＯＰサーバは、ＸＭＬ　Ｐａｇｅ要求の照会ストリング中のＮＡＭＥ、ＶＡＬＵＥの対の形態で要求に関する情報を送信する。ＣＦＭは、適切な要素を有するＸＭＬ　Ｐａｇｅの形態で応答を戻す。以下の要素／タグが、そのようなコール制御応答のためにＣＦＭにとって利用可能である。さらに、前述したＬＥＧ＿ＷＡＩＴタグをＰＯＰサーバとＣＦＭの間における通信のために使用することも可能である。同様に、ＢＲＩＤＧＥ＿ＣＡＬＬタグおよびＵＮＢＲＩＤＧＥ＿ＣＡＬＬタグも使用される。ＣＦＭにとっての違いは、ＡＬＬのＬＥＧ＿ＩＤを使用できないだけである。ＣＦＭは、ただ１つだけのＬＥＧ＿ＩＤを明示的に指定してコールをブリッジし、かつ／またはブリッジ解除しなければならない。
【００９４】
「ＸＭＬ　Ｐａｇｅ」要素は、ＰＯＰサーバとの通信のためにＣＦＭによって使用されるすべてのＸＭＬ　Ｐａｇｅのためのルート要素である。この要素は、以下の属性を有することが可能である。
ＴＹＰＥ　　ＣＣまたはＩＶＲという値をとることができる。ＣＦＭは、値ＣＣ（コール制御）を使用する。
ＣＵＳＴＩＤ　　顧客を識別する
ＰＡＧＥＩＤ　　（オプション）ページ自体を識別する
ＶＥＲＳＩＯＮ　　顧客のアプリケーションのバージョン番号を識別するために顧客によって使用される
ＳＥＳＳＩＯＮＩＤ　　発呼者との特定のセッションを識別するための識別子
各ＸＭＬ　ＰａｇｅはＰＯＰサーバによるコール制御要求に対する応答を表す。ＸＭＬ　Ｐａｇｅの可能な子（下位要素）は、ＡＣＣＥＰＴ＿ＣＡＬＬ、ＬＥＧ＿ＷＡＩＴ、ＲＥＳＰＯＮＳＥ、ＤＩＡＬ＿ＣＡＬＬ、ＢＲＩＤＧＥ＿ＣＡＬＬ、ＵＮＢＲＩＤＧＥ＿ＣＡＬＬ、ＨＡＮＧＵＰ＿ＣＡＬＬ、ＤＥＳＴＲＯＹ＿ＬＥＧ、ＲＥＪＥＣＴ＿ＣＡＬＬ、ＥＮＤ＿ＣＡＬＬ、ＭＡＫＥ＿ＯＵＴＣＡＬＬ、ＳＥＴ、ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰ、ＥＸＣＥＰＴＩＯＮ、およびＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲである。
【００９５】
ＡＣＣＥＰＴ＿ＣＡＬＬ要素は、ＣＦＭによって使用されて、着信電話コールのためのリソースが利用可能であること、およびＰＯＰサーバがコールを受け入れるべきことをＰＯＰサーバに警報する。
ＲＩＮＧＳ　　（オプション）コールに応答するまでのリングバックにおけるリングの回数を制御する属性。ＩＶＲアプリケーションからの最初のＸＭＬ　Ｐａｇｅが受信されるまで、必要なリングが鳴らされる。
ＵＮＩＴ　　（オプション）値は、ＲＩＮＧＳの単位を示すＳＥＣまたはＮＵＭＢＥＲであることが可能である。
ＨＲＥＦ　　ＰＯＰサーバがコールに応答した後、ＰＯＰサーバによって次のＸＭＬ　Ｐａｇｅがそこから取り出されるべきＩＶＲアプリケーションのＵＲＬ。
【００９６】
このＸＭＬ　Ｐａｇｅタグは、着信コールが来たとき、ＰＯＰサーバからの要求に応答して送信される。このページのＵＲＬに対する要求は、ＤＩＤおよび、入手可能な場合、着信コールのＡＮＩを照会ストリングの一部として含まなければならない。ＡＣＣＥＰＴ＿ＣＡＬＬ応答ページが、ＣＦＭによって作成されたセッションのための固有識別子であるＳＥＳＳＩＯＮＩＤを戻す。ＣＦＭ（ならびにＩＶＲアプリケーション）に対するＰＯＰサーバからの将来のすべての要求は、ＤＩＤおよびＡＮＩではなく、ＳＥＳＳＩＯＮＩＤを担持しなければならない。ＡＣＣＥＰＴ＿ＣＡＬＬは、子としての下位要素を全く有さない。
【００９７】
ＡＣＣＥＰＴ要素を含むＸＭＬ　Ｐａｇｅ（ＣＦＭからの最初のページ）は、回復不能のＩＶＲの誤りを扱うため、ＩＶＲ＿ＥＲＲＯＲ＿ＥＸＣＥＰＴＩＯＮを含んだＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰも含まなければならない。ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、グローバル・マップであり、どのＡＣＣＥＰＴタグよりも前に配置されなければならない。
【００９８】
割込み要求（上記を参照）に応答してＲＥＳＰＯＮＳＥタグが、ＣＦＭまたはＰＯＰサーバによって送信される。このタグは、割込みによって要求された処理が成功であったか、失敗であったかを示し、失敗であった場合、失敗の理由を示す。ＲＥＳＰＯＮＳＥは、２つの必須の属性を有し、子を有さない。
ＲＥＳＵＬＴ　　ＳＵＣＣＥＳＳまたはＦＡＩＬＵＲＥ。
ＲＥＡＳＯＮ　　（オプション）ＦＡＩＬＵＲＥの場合、可能な値は、ＵＮＫＮＯＷＮ＿ＲＥＱ、ＩＮＶＡＬＩＤ＿ＰＡＲＡＭＥＴＥＲＳ、ＮＯ＿ＲＥＳＯＵＲＣＥＳである。
【００９９】
ＩＶＲアプリケーションおよび他のアプリケーションによる要求に応答して、ＤＩＡＬ＿ＣＡＬＬタグを有するＸＭＬ　ＰａｇｅがＣＦＭによって伝送されて、アウトバウンドのコールを行う。ＤＩＡＬ＿ＣＡＬＬの属性は、以下のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号。
ＡＮＩ　　（オプション）電話マネージャが、発信コール内で送信すべきＡＮＩ。この値は、アプリケーションによってＱＵＥＵＥ＿ＣＡＬＬタグ内に指定される。
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＤＩＡＬ＿ＥＲＲＯＲ例外内に指定されたＨＲＥＦに要求を送信することによってＣＦＭに即時に通知する。アウトバウンドのコールが成功した場合、ＰＯＰサーバは、次のタグ（存在する場合）に、またはＰａｇｅの最上部のＸＭＬ　Ｐａｇｅタグ内のＨＲＥＦ（ＤＩＡＬ＿ＣＡＬＬがページ上の最後のタグの場合）にとりかかる。ＤＩＡＬ＿ＣＡＬＬは、１つの子要素−ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを有する。また、グローバルＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰも、ＣＡＬＬＥＲＨＵＰイベントで指定されなければならない。また、＄ｅｎｄ−ｃａｌｌ−ｕｒｌ＄も、この時点までに、会話コントローラのために設定されなければならない。
【０１００】
ＨＡＮＧＵＰ＿ＣＡＬＬ要素がＣＦＭによって使用されて、このタグを受け取るレッグ上のコールが終了されなければならないことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＥＲＲＯＲまたはＣＡＬＬＥＲＨＵＰ。
ＨＡＮＧＵＰ＿ＣＡＬＬタグは、ドロップされたコールに関連する会話コントローラを破棄しないということでＥＮＤ＿ＣＡＬＬタグとは異なる。関連する会話コントローラ上でさらなるコールが行われない場合、ＨＡＮＧＵＰ＿ＣＡＬＬタグの後には、ＤＥＳＴＲＯＹ＿ＬＥＧタグが続くことが可能であり、あるいは別のアウトバウンドのコールを行うために別のＤＩＡＬ＿ＣＡＬＬが続くことが可能である。ＨＡＮＧＵＰ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０１】
ＤＥＳＴＲＯＹ＿ＬＥＧ要素がＣＦＭによって使用されて、会話コントローラが終了されるべきことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＥＲＲＯＲまたはＣＡＬＬＥＲＨＵＰ。
ＤＥＳＴＲＯＹ＿ＬＥＧは下位要素を全く有さない。ＤＥＳＴＲＯＹ＿ＬＥＧには、ＨＡＮＧＵＰ＿ＣＡＬＬタグが先行するものとされてはいるが、レッグ上にアクティブなコールが存在する場合、会話コントローラは、先行するＨＡＮＧＵＰ＿ＣＡＬＬなしにＤＥＳＴＲＯＹ＿ＬＥＧを実際に受け取ったならば、このレッグを破棄するのに必要とされる必要なクリーンアップを行わなければならない。
【０１０２】
ＲＥＪＥＣＴ＿ＣＡＬＬ要素がＣＦＭによって使用されて、コールのためのリソースが割り振られていないこと、および話中信号を出すことによってＰＯＰサーバが着信コールを拒否すべきことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）。ＮＯＰＯＲＴＳまたはＯＴＥＨＲ。
ＲＥＪＥＣＴ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０３】
ＥＮＤ＿ＣＡＬＬ要素がＣＦＭによって使用されて、コールが終了されるべきことをＰＯＰサーバに通知するのが可能である。このタグを有するＸＭＬ　Ｐａｇｅが、コールを終了するＰＯＰサーバからのＣＦＭに対する要求に応答して送信される。ＰＯＰサーバは、そのような要求の照会ストリング中のＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬを使用して、そのようにＣＦＭにアドバイスする。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＩＶＲ＿ＥＲＲＯＲまたはＣＡＬＬＥＲ＿ＲＥＱ。
このタグは、インバウンドのコールまたはアウトバウンドのコールが既に終了されたとき（以下のＭＡＫＥ＿ＯＵＴＣＡＬＬを参照）、ＣＦＭによってＰＯＰサーバにも送り返される。ＣＦＭは、このタグをＰＯＰサーバに送信した後、自らのリソース使用カウントをクリーンアップして減分する。ＥＮＤ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０４】
ＩＶＲアプリケーションによる要求に応答して、ＭＡＫＥ＿ＯＵＴＣＡＬＬタグを有するＸＭＬ　ＰａｇｅがＣＦＭによって送信されてアウトバウンドのコールを行い、発呼者の着信コールをこのアウトバウンドのコールにブリッジする。この要求は、ＩＶＲアプリケーションによって送信されたＸＭＬ　Ｐａｇｅ上のＨＲＥＦに従うことにより、ＩＶＲアプリケーションのためにＰＯＰサーバによって行われる。例えば、発呼者がキー「０」を押したとき、発呼者をオペレータに接続することをＩＶＲアプリケーションが望む場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ　Ｐａｇｅは、次の値を有するＴＯＮＥＩＤ＝０に対応するＨＲＥＦを有していなければならない。
2004500754.tif 000016
ここで、＜ｔｅｌｎｕｍ＞は、ＰＯＰサーバが呼び出すことをＩＶＲアプリケーションが望む電話番号によって置き換えられ、また＄ｓｅｓｓｉｏｎｉｄ＄は、インバウンドのコールが最初に来たときに作成されたセッションＩＤによって置き換えられる。
【０１０５】
ＭＡＫＥ＿ＯＵＴＣＡＬＬの属性は、以下のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号
ＨＲＥＦ　　コールが成功したかどうかを通知する（アウトバウンドが最終的に終了したとき）ためのコール・フロー・コンダクタＵＲＬ
【０１０６】
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ例外（例９を参照）内で指定されたＨＲＥＦに要求を送信することにより、そのことをＣＦＭに通知する。アウトバウンドが成功した場合、ＰＯＰサーバは、即時には、ＣＦＭに全く通知を送信しない。むしろ、ＰＯＰサーバは、アウトバウンドのコールが終了される（発呼者または着呼側により）のを待ってから、ＭＡＫＥ＿ＯＵＴＣＡＬＬのＨＲＥＦ属性に要求を送信する。成功通知と失敗通知の両方に応答して、ＣＦＭは、ＥＮＤ＿ＣＡＬＬタグを有するＸＭＬ　Ｐａｇｅを送り返す。
【０１０７】
ＭＡＫＥ＿ＯＵＴＣＡＬＬは、１つの子要素を有する。あるコール制御例外と、そのような例外が生じた場合、取り出すべきＸＭＬ　ＰａｇｅのＵＲＬとのマッピングを指定するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰである。ＩＶＲ＿ＥＲＲＯＲ　ＥＸＣＥＰＴＩＯＮを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、ＣＦＭからの最初のＸＭＬ　Ｐａｇｅ中のどのＡＣＣＥＰＴタグよりも前に含まれなければならない。ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ　ＥＸＣＥＰＴＩＯＮを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰが、ＭＡＫＥ＿ＯＵＴＣＡＬＬタグ内およびＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲタグ内に含まれなければならない。
【０１０８】
ＥＸＣＥＰＴＩＯＮＭＡＰは、子要素ＥＸＣＥＰＴＩＯＮを使用して、例外と、そのような例外が生じた場合に次のページをそこから取り出すＵＲＬとのマッピングを指定することができる。ＥＸＣＥＰＴＩＯＮは、２つの必須の属性を有する。
ＥＶＥＮＴ　　可能な値は、ＢＲＩＤＧＥ＿ＥＲＲＯＲ、ＵＮＢＲＩＤＧＥ＿ＥＲＲＯＲ、ＩＶＲ＿ＥＲＲＯＲ、およびＯＵＴＣＡＬＬ＿ＥＲＲＯＲである。
ＨＲＥＦ　　ＥＶＥＮＴによって指定された例外が生じた場合、次のページをそこから取り出すＵＲＬ。
ＥＸＣＥＰＴＩＯＮは、子を有さない。
【０１０９】
ＩＶＲ＿ＥＲＲＯＲが、回復不能のＩＶＲアプリケーションの誤りを示す。ＣＦＭからの最初のＸＭＬ　Ｐａｇｅ（ＡＣＣＥＰＴタグを含む）は、ＩＶＲ＿ＥＲＲＯＲイベントを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを含まなければならず、またこのＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、ＡＣＣＥＰＴタグよりも前に配置されなければならない。ＯＵＴＣＡＬＬ＿ＥＲＲＯＲは、コールをダイヤルしようとする試みが失敗したことを示す。ＭＡＫＥ＿ＯＵＴＣＡＬＬタグまたはＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲタグを有するＸＭＬ　Ｐａｇｅが、ＯＵＴＣＡＬＬ＿ＥＲＲＯＲイベントを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを含まなければならない。
【０１１０】
ＳＥＴタグにより、ＣＦＭは、ＰＯＰによる後の置換のために変数の値を設定することができる。このタグは、ＰＯＰサーバが、特定の値を特定の変数名関連付けるべきこと、およびＣＦＭが、後に同じＸＭＬ　Ｐａｇｅ中または別のＸＭＬ　Ｐａｇｅ中で変数名を使用するとき、ＰＯＰサーバが、変数名を値で置き換えるべきことをＣＦＭが、ＰＯＰサーバに示すのを可能にする便利な機構である。ＳＥＴは、２つの必須の属性を有し、子を有さない。
ＶＡＲＮＡＭＥ　　変数の名前。
ＶＡＬＵＥ　　変数に割り当てられる値。
【０１１１】
ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲ要素がＣＦＭによって使用されて、アウトバウンドのコールを行い、そのコールを着信コールにブリッジすることによって着信コールをオペレータに再ダイレクトする。この要素は、ＩＶＲアプリケーションが何らかの理由でダウンしている場合、便利である。ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲの属性は、次のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号
ＨＲＥＦ　　コールが成功した場合、（アウトバウンドのコールが最終的に終了したとき）通知を行うためのＣＦＭ　ＵＲＬ
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ例外内で指定されたＨＲＥＦに要求を送信することにより、そのことをＣＦＭに即時に通知する。アウトバウンドのコールが成功した場合、ＰＯＰサーバは、コール・フロー・コンダクタに全く通知を送信しない。ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲは、１つの子要素−ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを有する。
【０１１２】
前と同様に、いくつかの例が、上記のタグの使用を説明するのに役立つ。例７で、ＰＯＰサーバに指示して着信コールを受け入れるようにさせるためのＸＭＬ　Ｐａｇｅが提示されている。このページは、ＰＯＰサーバからの新規コール指示に応答して送信される。この指示は、通常、新しく着信したコールに関してＰＯＰサーバによってＣＦＭに送信される最初の要求である。ＡＣＤに対するプロキシ・コールのためのリソースを割り振った後、ＣＦＭは、このＰａｇｅをＰＯＰサーバに戻す。Ｐａｇｅは、ＳＥＳＳＩＯＮＩＤ属性内に、ＣＦＭによって予約されたコール構造のアドレスを含むことに留意されたい。ＣＦＭは、ＡＣＤ上またはＩＶＲ上の利用可能なポートをもうすぐ使い果たすことが分かった場合、コールがＰＯＰサーバによって応答されるまでのＲＩＮＧＢＡＣＫ内で与えられるＲＩＮＧＳの数を増加させることができる。
2004500754.tif 000017
図５に示すとおり、ＰＯＰゲートウェイからの着信コール警報に応答して、そのようなＰａｇｅをＣＦＭによって戻される＜ＡＣＣＥＰＴ＿ＣＡＬＬ＞ページとして使用することができる。
【０１１３】
次の例８では、コール終了例が提供される。この場合、発呼者が済み、コールが終了されるべきであるとＩＶＲアプリケーションが判定している。そのような場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ　Ｐａｇｅは、以下のようなＨＲＥＦを有することになる。
2004500754.tif 000018
【０１１４】
ＰＯＰサーバは、要求をＣＦＭに送信するとき、以下のＸＭＬ　Ｐａｇｅを送り返す。
2004500754.tif 000019
【０１１５】
次の例９では、ＩＶＲアプリケーションは、発呼者がアウトバウンドのコールを行う必要があると判定した。そのような場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ Ｐａｇｅは、以下のようなＨＲＥＦを有することになる。
2004500754.tif 000020
ＰＯＰサーバは、要求をＣＦＭに送信するとき、以下のＸＭＬ　Ｐａｇｅを送り返す。
2004500754.tif 000021
【０１１６】
次の例１０では、適切な技能セットを有するエージェントが応対可能になるのを待ってコールがＡＣＤの待ち行列の中に入れられたことをＰＯＰサーバに通知するためのＸＭＬ　Ｐａｇｅが提示されている。適切な技能セットを有するエージェント・グループに関する情報を含んだ照会ストリングを有するＲＥＤＩＲＥＣＴ　ＨＴＴＰ要求（元はＩＶＲサーバからの）に応答して、そのようなＰａｇｅがＣＦＭによって送信されるのが可能である。このＸＭＬ　Ｐａｇｅを介して、ＣＦＭは、ＰＯＰサーバに命令して、コールが保留されている間、発呼者に対して音楽／情報コマーシャル・ファイルを再生するようにさせる。ＣＡＬＬ＿ＱＵＥＵＥＤ要素は、オプションとして、待ち行列がどれだけ長いか、また予想される保留時間はどれぐらいかに関する指示を含むことが可能である。
2004500754.tif 000022
【０１１７】
前述したタグを使用して、図５および７に示したもののようなコール・フロー管理オペレーションを容易に実施することができる。例えば、図５に示したとおり、インバウンドのコールが、コールの発信元の点に近いローカルＰＯＰゲートウェイにおいて代行受信され、そうでなければかかる可能性がある長距離料金を削減することができる。これに応答して、ローカルＰＯＰゲートウェイは、コールのことをＣＦＭに通知して、コールを管理するための命令を求める。コールのこの部分は、図でＬＥＧ＿ＩＤ＝１として示されている。
【０１１８】
ＰＯＰゲートウェイからの通知に応答して、ＣＦＭは、＜ＡＣＣＥＰＴ＿ＣＡＬＬ＞ページを戻し、ＰＯＰゲートウェイを適切なＵＲＬにダイレクトしてＩＶＲから命令を取り出すようにさせる。この指示に従って、ＰＯＰゲートウェイは、インバウンドのコールを扱うための命令を提供するＩＶＲアプリケーションとの交換を開始する。例えば、ＩＶＲは、前述したとおり、指定されたメニューを使用してプロンプト指示することが可能であるユーザからのデータ収集に関する命令を提供することができる。
【０１１９】
ＩＶＲとローカルＰＯＰゲートウェイの間のダイアログが進行する中で、ＩＶＲは、ＰＯＰゲートウェイに命令して、最終的に発呼者をコール・センタにおけるオペレータに接続することを目的として、プロキシ・コールをコール・センタのＡＣＤに入れる要求を行うようにさせることができる。図に示したとおり、これは、前述したＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬコマンドを使用して行うことができる。指定されたＴＥＬＮＵＭは、コール・センタに到達するためにダイヤル呼出しされる番号である。他の場合、この命令は、コール・センタにおける構内ゲートウェイ・サーバに行くことが可能である。
【０１２０】
どちらの場合も、ゲートウェイ・サーバは、プロキシ・コールを開始する要求をＣＦＭに渡し、これに応答して、ＣＦＭは、そうするために要求を行っているゲートウェイとのダイアログを始める。プロキシ・コールがセットアップされ（図でＬＥＧ＿ＩＤ＝２として識別される）、プロキシ・コールに応答があるのが間近になると、示したとおり、２つのコール（ＬＥＧ＿ＩＤ＝１とＬＥＧ＿ＩＤ＝２）がブリッジされる（ＣＦＭからのＢＲＩＤＧＥ＿ＣＡＬＬコマンドに応答して）。
【０１２１】
インバウンドのコールの管理を可能にすることに加えて、ＸＭＬコマンドは、図７に示すとおり、コール・センタからのアウトバウンドのコールを管理するのにも使用することができる。今度は、ＩＶＲが、識別された電話番号（ｎｐａ）ｎｘｘ−ｘｘｘｘに対するコールのための新しいコール・セッションを確立するようにＣＦＭに求めることにより、プロセスを開始する。これに応答して、ＣＦＭは、適切なローカルＰＯＰゲートウェイを決定して、コール・セットアップ・ダイアログを開始し、ＰＯＰゲートウェイは、ＤＩＡＬ＿ＣＡＬＬコマンドを使用して指定された電話番号にアウトバウンドのコールを行うように命令される。このコールが確立されると、ＣＦＭは、制御をＩＶＲに引き渡し（Ｐａｇｅをそこから取り出すべき適切なＵＲＬをＰＯＰゲートウェイに渡すことにより）、次に、ＩＶＲが、適切な着呼側対話命令をＰＯＰゲートウェイに提供することができる。
【０１２２】
（システムの説明）
以上、本発明のプロセス・フローの態様を検討してきたので、システムの概要が役に立つであろう。図８は、エンド・ユーザ１１６が、発信元のローカルＰＳＴＮ１０６、長距離ネットワーク１１４、および終端するローカルＰＳＴＮ１０６を介してビジネス・コール・センタ１５０に接続されている本発明の少なくとも１つの実施形態による仮想インテリジェント・ネットワーク・システムの機能図である。
【０１２３】
ＶＩＮは、コール発信元の点に近い１つまたは複数のポイントオブプレゼンス１５２に分散された１つまたは複数のＰＯＰコール・センタ・ゲートウェイ・サーバ１４６を含む。これらのＰＯＰコール・センタ・ゲートウェイ・サーバ１４６は、１つまたは複数のコール・センタ・ネットワーク１４８によって１つまたは複数のビジネス・コール・センタ１５０における構内コール・センタ・ゲートウェイ・サーバ１４２に接続されている。コール・センタ・ネットワーク１４８は、複数のビジネス・コール・センタ１５０のためにＣＦＭアプリケーションおよびＩＶＲアプリケーションなどのユーザ指定のアプリケーションをホストする１つまたは複数のアプリケーションＷＥＢアプリケーション・サーバ１５４に接続されている。ＰＯＰコール・センタ・ゲートウェイ・サーバ１４６は、接続された構内コール・センタ・ゲートウェイ・サーバ１４２との長距離音声通信を可能にする交換公衆テレコミニュケーション・ネットワークまたは専用アクセス公衆テレコミニュケーション・ネットワーク１１４にさらに接続されている。
【０１２４】
ビジネス・コール・センタ１５０は、広い地域にわたって分散した複数のビジネス・コール・センタに属することが可能であり、また１つまたは複数の構内コール・センタ・ゲートウェイ・サーバ１４２を含むことが可能であり、ＰＯＰコール・センタ・ゲートウェイにおいて着信コールを扱う時点で、ＣＦＭアプリケーションによってそれらのサーバの１つが動的に選択されることになる。
【０１２５】
次に、図９を参照すると、ＰＯＰゲートウェイ１６６が、ＣＦＭの指示の下で、コールの発信元の点において、またはその近くでインバウンドのコールを代行受信して、それに応答する。さらに、ＰＯＰゲートウェイ１６６は、ＣＦＭ指定の対話式音声応答アプリケーションを使用して自動化されたサービスを提供し、コールにサービスを提供する適切なオペレータが応対可能になったとき、コールをコール・センタ１５０における構内コール・センタ・ゲートウェイ１６４に転送するまで、コールを保留にして待ち行列に入れ、かつ／またはコールの保留中、音楽またはカストマイズされた告知を発呼者に流す。コールが待ち行列に入れられた場合、ＣＦＭアプリケーションは、構内コール・センタ・ゲートウェイ１６４に対してコマンドを発行して、コール・センタ１５０においてプロキシ・コールを発信し、待ち行列に入れられたコールの進行を監視することができる。構内コール・センタ・ゲートウェイ１６４が、ＡＮＩやＤＮＩＳなどのコール特有の情報またはＷＥＢサーバ１５４上に配備されたＩＶＲアプリケーションによって提供される発呼者アカウント情報を使用するＣＦＭによって選択されて、最もよくマッチする応答リソースがインテリジェントに選択される。次に、構内コール・センタ・ゲートウェイ１６４がＣＦＭにそうするように警報したとき、ＣＦＭは、ＰＯＰコール・センタ・ゲートウェイ１６６に指示して、オペレータがコールに応答する前にジャスト・イン・タイムで、ローカルで待ち行列に入れられたコールを構内コール・センタ・ゲートウェイ１６６に経路指定するようにさせる。
【０１２６】
構内コール・センタ・ゲートウェイ１６４は、ＣＦＭコマンドに応答して、構内コール・センタＡＣＤに対するプロキシ・コールを生成する。次に、構内コール・センタ・ゲートウェイ１６４は、オペレータの応対可能性に関してＡＣＤ内のプロキシ・コールの進行を監視し、選択されたオペレータに対するジャスト・イン・タイムのコール・デリバリのためにＣＦＭと通信し、ＰＯＰコール・センタ・ゲートウェイ１６６と構内ＡＣＤの間でコールをブリッジする。
【０１２７】
ネットワーク・オペレーション・センタ（ＮＯＣ）１５６は、着呼番号をルックアップするためにＣＦＭおよび／またはＶＩＮの他のリソースによってアクセスされることが可能なデータベースをホストすることができる。このようにして、インテリジェントな着呼側の経路指定を提供することができる。
【０１２８】
図１０を参照すると、一実施形態による仮想インテリジェント・ネットワークは、複数のＰＯＰコール・センタ・ゲートウェイ１６６と、すべて単一のビジネス・コール・センタ１５０に属することが可能な１つまたは複数の構内コール・センタ・ゲートウェイ１６４と、そのビジネス・コール・センタのためのＣＦＭやＩＶＲアプリケーションなどのユーザ指定のアプリケーションをホストする１つまたは複数のＷＥＢアプリケーション・サーバ１５４とをコール・センタネットワーク１４８を介して接続する仮想私設ネットワークである。仮想私設ネットワークは、オプションのサービス品質保証で接続されたエンティティ間のセキュアな専用のデータ通信のために、非同期転送モード（ＡＴＭ）、フレーム・リレー、またはインターネット・プロトコル（ＩＰ）などの接続−トランスポート・プロトコルを提供する。
【０１２９】
図１１を参照すると、各ＰＯＰコール・センタ・ゲートウェイ１６６は、サービスを受ける各ビジネス・コール・センタ１５０ごとに１つの、ビジネス・コール・センタ１５０のためにすべて１つまたは複数のＷＥＢアプリケーション・サーバ１５４に接続された複数のそのようなコール・センタ・ネットワーク１４８の一部であることが可能である。ＰＯＰコール・センタ・ゲートウェイ１６６は、コール・センタ・ネットワーク１４８を使用して対応する構内コール・センタ・ゲートウェイ１６４に接続し、それぞれのビジネス・コール・センタのためにＣＦＭの指示の下で適切な対話式音声応答アプリケーションにアクセスする。
【０１３０】
以上の明細では、本発明をその特定の例としての実施形態に関連して説明してきた。ただし、頭記の特許請求の範囲に記載する本発明のより広汎な趣旨および範囲を逸脱することなく、特定の例としての実施形態に様々な改変および変更を加えるのが可能なことが明白であろう。例えば、前述したＸＭＬコマンドは、どのコンピュータ可読媒体（例えば、ＣＤ−ＲＯＭ、フロッピー（登録商標）・ディスク等）上にも記憶することができ、かつ／またはＶＩＮの要素を相互接続する媒体上の電気信号またはその他の（例えば、光、マイクロ波等）信号としてトランスポートすることができる。
【０１３１】
さらに、本ＶＩＮの全体的目標を見失ってはならない。要するに、ＶＩＮは、企業ネットワークにトランスペアレントな形で、また基礎を成す媒体トランスポート機構とは独立にアクセス・ネットワークのエッジにまで企業ネットワーク（例えば、前述したビジネス・コール・センタ）を拡張する。例えば、図１２に描いたネットワーク・トポロジを考慮されたい。ネットワーク２００は、ゲートウェイ２０４がそのエッジに設けられたいくつかの（Ｎ）アクセス・ネットワーク２０２を含む。ゲートウェイ２０４は、前述したＰＯＰコール・センタ・ゲートウェイと同様であることが可能である。
【０１３２】
各アクセス・ネットワーク２０２は、幾人かのユーザ２０６にとってのローカル・アクセス・ネットワークとして働くことができる。例えば、１つまたは複数のアクセス・ネットワーク２０２は、ローカル・ループ・ネットワーク（無線または有線の）、セルラー電話ネットワーク（アナログまたはデジタルの）、デジタル・ネットワーク（例えば、ＩＰ、ＡＴＭ、フレーム・リレー等）、またはその他のアクセス・ネットワークであることが可能である。ゲートウェイ２０４を介して、アクセス・ネットワーク２０２は、中継ネットワーク（ＩＸＮ）２１０および／またはＩＰネットワーク２１２を介して１つまたは複数の企業ネットワーク（例えば、ビジネス・コール・センタ、オフィス・コンピュータ・ネットワーク、イントラネット等）２０８と通信するように結合することができる。ＩＸＮ２１０は、中継通信事業者によって運営される長距離ネットワークまたはその他のテレコミニュケーション・ネットワークであることが可能であり、従来の時間分割多重（ＴＤＭ）トランスポート機構、アナログまたはデジタルの交換通信トランスポート機構、ボイス・オーバーＩＰ、ボイス・オーバー・ＡＴＭ、ボイス・オーバー・フレーム・リレー、または他の任意の回線交換トランスポートまたはその他の基礎を成すトランスポートおよび／または通信機構を使用して音声コールおよび／またはデータ通信を搬送することができる。ＩＰネットワーク２１２は、前述したＣＦＭサーバを含むことが可能である。
【０１３３】
例えば、前述したとおり、ＩＶＲサーバおよび／またはＣＦＭサーバの制御下で、ゲートウェイ２０４において実行されるローカル・アプリケーションの制御を介して、ゲートウェイ２０８の機能性がアクセス・ネットワーク２０２のエッジにまで届けられる。したがって、ユーザ２０６には、トランスポートおよび／または接続アクセスＩＸＮ２１０に関連する費用を被る必要なしにサービスを提供することができる。さらに、複数のゲートウェイ２０８（同じビジネス・エンティティに関連していなくてもよい）が、ゲートウェイ２０４を共用することができ、各ゲートウェイは、前述したＸＭＬ制御プロセスを介してゲートウェイ２０４で実行されるアプリケーションに対する制御を有する。というのは、そのような制御プロセスは、ＩＰネットワーク２１２を使用して、これらの制御プロセスは、ＩＸＮ２１０の使用に関連する料金も回避するからである。企業ネットワークに対する真の接続が必要とされるときだけ（例えば、オペレータが応対可能になったとき）、ＩＸＮ２１０を介してコールをブリッジする必要がある（どの仕方でも、例えば、回線交換ＰＳＴＮ、ボイス・オーバーＩＰ、ボイス・オーバーＡＴＭ、ボイス・オーバー・フレーム・リレー等）。
【０１３４】
また、本ＶＩＮは、容易な終端間コール経路指定も可能にする。例えば、前述したＸＭＬ制御プロセスを使用して、企業ネットワークは、ゲートウェイ２０４に宛先アドレス情報を提供し、ＩＰネットワークまたはその他のデジタル・ネットワークを介する着信コールのトランスポートを可能にすることができる。着信コールは、ＰＯＴＳダイヤル呼出し番号に関連付けられるものと考えられたい。従来の回線交換ＰＳＴＮは、このダイヤル呼出し番号を利用してコールを経路指定することができるが、ＩＰ、ＡＴＭ、フレーム・リレー等に基づくネットワークは、コールを経路指定するためには、関連アドレス（場合に応じて、例えば、ＩＰアドレス、ＶＰ／ＶＣＩ、ＤＬＣＩ等）を有していなければならない。前述したＸＭＬ制御手続きを使用して、ゲートウェイ２０４に、そのようなアドレスを提供し、そのようなネットワークを介して、場合によっては、ＩＰエンドポイントにまで直接に（例えば、ＩＰ電話機）コール経路指定を提供することができる。したがって、本ＶＩＮは、コール管理を媒体管理から分離して、ＶＯＩＰ（ＶＯＡＴＭ、ＶＯＦＲ等）を音声（またはその他のデータ）のトランスポート機構として効率的に使用する。したがって、本ＶＩＮおよびそれによって提供される複数のアプリケーションの一般的性質のため、明細および図面は、制限するものではなく、例示するものと見なされるべきである。
【図面の簡単な説明】
【図１】
ＰＢＸシステム、ＡＣＤシステム、およびＩＶＲシステムがコール・センタに配置された従来のコール・センタ構成を示す概略図である。
【図２】
長距離ネットワーク内にスイッチ・システム、ＡＣＤシステム、およびＩＶＲシステムが配置された従来のネットワーク・ベースのコール・センタ構成を示す概略図である。
【図３】
本発明の実施形態による仮想インテリジェント・ネットワークのオペレーション上の方法の一例を示す流れ図である。
【図４】
本発明の実施形態による構内コール・センタの選択のための１プロセスを示す流れ図である。
【図５】
本発明の実施形態による仮想インテリジェント・ネットワーク（ＶＩＮ）内におけるＸＭＬコマンドの使用の様々な態様を示すコール流れ図である。
【図６】
本発明の実施形態によるＶＩＮ内の伝送のためにＸＭＬ　Ｐａｇｅに含まれることが可能なＸＭＬタグの例を示す図である。
【図７】
本発明の実施形態によるコール・センタからアウトバウンドのコールを行うためのＶＩＮ内におけるＸＭＬコマンドのケースの様々な態様を示すコール図である。
【図８】
ポイントオブプレゼンス（ＰＯＰ）コール・センタ・ゲートウェイ、構内コール・センタ・ゲートウェイ、コール・センタ・ネットワーク、ネットワーク・オペレーション・センタ、およびＷＥＢアプリケーション・サーバを含む本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図９】
ＷＥＢアプリケーション・サーバ上に配備されたユーザ指定のアプリケーションによって制御されたコール・センタ・ネットワークを介して構内コール・センタ・ゲートウェイに接続されたＰＯＰコール・センタ・ゲートウェイを含む本発明の実施形態による仮想インテリジェント・ネットワーク構成を示す概略図である。
【図１０】
複数のＰＯＰコール・センタ・ゲートウェイに接続された複数のコール・センタ・サイトを有する単一のビジネスをサポートする本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図１１】
複数のＰＯＰコール・センタ・ゲートウェイに接続された複数のビジネス・コール・センタをサポートする本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図１２】
本発明の実施形態による例としてのネットワーク・トポロジを示す図である。
【図１】
2004500754.tif 000023
【図２】
2004500754.tif 000024
【図３】
2004500754.tif 000025
【図４】
2004500754.tif 000026
【図５】
2004500754.tif 000027
【図６】
2004500754.tif 000028
【図７】
2004500754.tif 000029
【図８】
2004500754.tif 000030
【図９】
2004500754.tif 000031
【図１０】
2004500754.tif 000032
【図１１】
2004500754.tif 000033
【図１２】
2004500754.tif 000034
【国際公開パンフレット】
2004500754.tif 000035
2004500754.tif 000036
2004500754.tif 000037
2004500754.tif 000038
2004500754.tif 000039
2004500754.tif 000040
2004500754.tif 000041
2004500754.tif 000042
2004500754.tif 000043
2004500754.tif 000044
2004500754.tif 000045
2004500754.tif 000046
2004500754.tif 000047
2004500754.tif 000048
2004500754.tif 000049
2004500754.tif 000050
2004500754.tif 000051
2004500754.tif 000052
2004500754.tif 000053
2004500754.tif 000054
2004500754.tif 000055
2004500754.tif 000056
2004500754.tif 000057
2004500754.tif 000058
2004500754.tif 000059
2004500754.tif 000060
2004500754.tif 000061
2004500754.tif 000062
2004500754.tif 000063
2004500754.tif 000064
2004500754.tif 000065
2004500754.tif 000066
2004500754.tif 000067
2004500754.tif 000068
2004500754.tif 000069
2004500754.tif 000070
2004500754.tif 000071
2004500754.tif 000072
2004500754.tif 000073
2004500754.tif 000074
2004500754.tif 000075
2004500754.tif 000076
2004500754.tif 000077
2004500754.tif 000078
2004500754.tif 000079
2004500754.tif 000080
2004500754.tif 000081
2004500754.tif 000082
2004500754.tif 000083
2004500754.tif 000084
2004500754.tif 000085
2004500754.tif 000086
2004500754.tif 000087
2004500754.tif 000088
2004500754.tif 000089
2004500754.tif 000090
2004500754.tif 000091
2004500754.tif 000092
2004500754.tif 000093
2004500754.tif 000094
2004500754.tif 000095
2004500754.tif 000096
2004500754.tif 000097
【国際公開パンフレット（コレクトバージョン）】
2004500754.tif 000098
2004500754.tif 000099
【国際公開パンフレット（コレクトバージョン）】
2004500754.tif 000100
2004500754.tif 000101
【手続補正書】
【提出日】平成13年12月11日(2001.12.11)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）タグとしてネットワークのノード間で渡されるコマンドの使用を介して遠隔／データ通信ネットワーク内のコール・フローを管理することを含む方法。
【請求項２】
管理することが、応答すること、終了させること、受け入れること、経路指定すること、開始すること、ブリッジすること、ブリッジ解除すること、会議を行うこと、および／または接続解除することを含む請求項１に記載の方法。
【請求項３】
ネットワークのノードの少なくとも１つが、前記ネットワークの他のノードにＸＭＬタグを送信し、かつ他のノードからＸＭＬタグを受信するように構成されたコール・フロー・マネージャ・アプリケーションをホストするＷＥＢサーバを含むを含む請求項２に記載の方法。
【請求項４】
管理することが、ネットワーク内のコール・フロー・マネージャにおいてコールの通知を受け取ること、およびＸＭＬタグの１つまたは複数の使用を介してコールが受け入れられるべきか否かを指示することを含む請求項１に記載の方法。
【請求項５】
管理することが、ＸＭＬタグのいくつかを使用して発行された１つまたは複数のコマンドに応答してコールを第２のコールにブリッジすることをさらに含む請求項４に記載の方法。
【請求項６】
第２のコールが、ＸＭＬタグの少なくとも１つを使用して発行された１つまたは複数のコマンドに応答してコール・センタにおいて開始されるプロキシ・コールである請求項５に記載の方法。
【請求項７】
第２のコールが、第２のコールのエンドポイントに近いポイントオブプレゼンスにおいて開始される請求項５に記載の方法。
【請求項８】
第２のコールが、ＸＭＬタグの少なくとも１つを使用して発行されたコマンドに応答して開始される請求項７に記載の方法。
【請求項９】
コールが受け入れられた場合、前記コールが、ネットワーク内のコンピュータ・リソース上でホストされる対話式音声応答（ＩＶＲ）アプリケーションの制御下でさらに管理される請求項４に記載の方法。
【請求項１０】
ＩＶＲアプリケーションが、ＸＭＬタグの様々なタグを使用して、コールが受信されたネットワークのノードにおいて実行される発呼者対話オペレーションに関連するコマンドを発行することにより、前記コールを管理する請求項９に記載の方法。
【請求項１１】
ＩＶＲアプリケーションによって発行されるコマンドの少なくとも１つが、コールが受信されたネットワークのノードが、前記コールを終了するための命令をそこで探し出すことができるアドレスに関する情報を含む請求項１０に記載の方法。
【請求項１２】
ＩＶＲアプリケーションによって発行されるコマンドの少なくとも１つが、コールが受信されたネットワークのノードが、メッセージを再生するための命令をそこで探し出すことができるアドレスに関する情報を含む請求項１０に記載の方法。
【請求項１３】
遠隔／データ通信ネットワークによって使用されるための、Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）で書かれたコール・フロー管理コマンドを含む１組のコンピュータ可読命令。
【請求項１４】
ネットワークの少なくとも２つのノードを相互接続する媒体上でトランスポートされる電気信号またはその他の信号として実装される請求項１３に記載のコンピュータ可読命令。
【請求項１５】
コンピュータ可読媒体上に実装される請求項１３に記載のコンピュータ可読命令。
【請求項１６】
Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）で表現された１組のコンピュータ可読命令の使用を介して互いに通信することによってコール管理オペレーションを提供するように構成された２つ以上のノードを含むネットワーク。
【請求項１７】
命令が、個々のＸＭＬページ上のコール管理で実行される一連のオペレーションのとして表現される請求項１６に記載のネットワーク。
【請求項１８】
１つまたは複数のユーザ指定のＷＥＢアプリケーションを介して第２のコール・センタに指示してインバウンドのコールにサービスを提供するようにさせることと、
前記アプリケーションを介して第１のコール・センタに指示して前記センタ内で接続を確立するようにさせることと、
前記第１のコール・センタ内で接続が確立されたとき、前記アプリケーションの制御下で前記第２のコール・センタからの前記インバウンドのコールをブリッジすることとを含む方法。
【請求項１９】
ＷＥＢアプリケーション・サーバ、ローカル・コール・センタ、および遠隔コール・センタが、データ・ネットワークを介して通信する請求項１８に記載の方法。
【請求項２０】
前記遠隔コール・センタが、広域に分散された複数のコール・センタから選択される請求項１８に記載の方法。
【請求項２１】
前記ユーザ指定のアプリケーションが、ＷＥＢアプリケーション・サーバ上で実行される請求項１８に記載の方法。
【請求項２２】
前記ユーザ指定のアプリケーションが、前記ローカル・コール・センタおよび前記遠隔コール・センタのコール・フローの挙動および音声応答の挙動を制御する請求項１８に記載の方法。
【請求項２３】
前記ユーザ指定のアプリケーションが、複数の遠隔コール・センタ間におけるコール・フローの均等な分散を実現するようにコール・センタを選択することにより、ローカル・コール・センタおよび前記遠隔コール・センタのコール・フローの挙動を制御する請求項２２に記載の方法。
【請求項２４】
前記ユーザ指定のアプリケーションが、対話式音声応答ベースの自動化されたサービスを選択し、前記サービスを実行するようにローカル・センタに要求することによって音声応答の挙動を制御する請求項２２に記載の方法。
【請求項２５】
前記ユーザ指定のアプリケーションが、ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（ＸＭＬ）を介して前記コール・フローの挙動および音声応答の挙動を制御する請求項２２に記載の方法。
【請求項２６】
前記ユーザ指定のアプリケーションが、コール・フロー管理（ＣＦＭ）ＷＥＢアプリケーションおよび対話式音声応答（ＩＶＲ）ＷＥＢアプリケーションである請求項２２に記載の方法。
【請求項２７】
前記ユーザ指定のアプリケーションが、外部のインターネット・データ・センタにおいてホストされるＷＥＢアプリケーション・サーバ上に配備される請求項２３に記載の方法。
【請求項２８】
ユーザ指定のアプリケーションが、発呼者のアカウント情報を収集すること、遠隔コール・センタを選択すること、およびインバウンドのコールを前記選択された遠隔コール・センタに経路指定することをさらに含む請求項１８に記載の方法。
【請求項２９】
ローカル・コール・センタが、コール発信の点の近くでコールを代行受信して応答することにより、前記インバウンドのコールに対するサービスを提供し、対話式音声応答ベースの自動化されたサービスを提供し、かつ遠隔コール・センタが、前記コールにサービスを提供するように応対可能になるまで前記コールを保留にして待ち行列に入れる請求項１８に記載の方法。
【請求項３０】
１つまたは複数のユーザ指定のアプリケーションを介して、ローカル・コール・センタによるコールの待ち行列化を要求するステップと、
１つまたは複数のユーザ指定のアプリケーションを介して、コール保留時間中の音声応答アプリケーションの実行を要求するステップと、
１つまたは複数のユーザ指定のアプリケーションを介して、前記待ち行列に入れられたコールに割込みを行い、ローカル・コール・センタに命令して前記コールを選択された応答リソースに転送させるステップとをさらに含む請求項２９に記載の方法。
【請求項３１】
コールを一方のロケーションから他方のロケーションに転送する必要がある場合、前記ユーザ指定のアプリケーションが、ローカル・コール・センタに要求して前記一方のロケーションにおける応答リソースに対する接続を解放させ、前記他方のロケーションにおいて接続を行わせる請求項３０に記載の方法。
【請求項３２】
ユーザ指定のアプリケーションが、遠隔コール・センタに要求して遠隔コール・センタの待ち行列内にプロキシ・コールを発信させることをさらに含む請求項１８に記載の方法。
【請求項３３】
遠隔コール・センタが、ユーザ指定のアプリケーションの要求に応答してプロキシ・コールを発信し、オペレータの応対可能性に関して前記プロキシ・コールの進行を監視し、前記進行を前記ユーザ指定のアプリケーションに通知することをさらに含む請求項３２に記載の方法。
【請求項３４】
オペレータが応対可能であることが遠隔コール・センタから通知されたとき、ユーザ指定のアプリケーションが、ローカル・コール・センタに指示して保留されているコールを前記遠隔コール・センタに転送するようにさせることをさらに含む請求項３３に記載の方法。
【請求項３５】
１つまたは複数のユーザ指定のアプリケーションを介してローカル・コール・センタに指示してアウトバウンドのコールを発信するようにさせることと、
前記アプリケーションを介して遠隔コール・センタに指示して前記センタ内で接続を確立するようにさせることと、
前記アプリケーションの制御下で前記アウトバウンドのコールを既存のコールとブリッジすることとを含む方法。
【請求項３６】
１つまたは複数のユーザ指定のアプリケーションを介して１組の代替の長距離番号を指定することと、
前記１組の代替の長距離番号から第１の長距離番号を選択することと、
１つまたは複数のユーザ指定のアプリケーションを介して第１の選択された番号にローカルなコール・センタに指示して第１のコールを行うようにさせることと、
前記第１の選択された番号に対する前記第１のコールの確立が不成功であった場合、他の選択される番号のどれかに対するコールを完遂することができるまで前記１組の代替の長距離番号から他の長距離番号を選択することとをさらに含む請求項３５に記載の方法。
【請求項３７】
音声メッセージを選択することと、コール・センタに指示して前記音声メッセージをエンド・ユーザに送達するようにさせることとをさらに含む請求項３５に記載の方法。
【請求項３８】
前記音声メッセージが、サービス提供エージェントに接続されるオプションをエンド・ユーザに提供する請求項３７に記載の方法。
【請求項３９】
エンド・ユーザが、前記オプションを選択することと、ユーザ指定のアプリケーションが、遠隔コール・センタに指示してサービス提供エージェントとの接続を確立するようにさせ、前記接続が確立されたときにコールを前記エンド・ユーザにブリッジするようにさせることとをさらに含む請求項３８に記載の方法。
【請求項４０】
コールにサービスを提供するために広域に分散された複数の遠隔コール・センタと、
コールに応答するローカル・コール・センタと、
ローカル・コール・センタに指示して、遠隔コール・センタ内で接続が確立されるまでコールにサービスを提供するようにさせるユーザ指定のアプリケーションをホストするように構成されたＷＥＢベースのアプリケーション・サーバとを含む仮想インテリジェント・ネットワーク・システム。
【請求項４１】
ローカル・コール・センタ、複数の遠隔コール・センタ、およびＷＥＢアプリケーション・サーバを接続するデータ・ネットワークをさらに含む請求項４０に記載のシステム。
【請求項４２】
データ・ネットワークが、接続−トランスポート・プロトコルを提供する仮想私設ネットワークである請求項４１に記載のシステム。
【請求項４３】
ＷＥＢネットワーク管理ツールを使用して仮想私設ネットワークの発見、構成、監視、および管理を行う前記データ・ネットワークに接続されたネットワーク・オペレーション・センタをさらに含む請求項４２に記載のシステム。
【請求項４４】
インターネット・プロトコル（ＩＰ）電話、メディア・ゲートウェイ制御プロトコル（ＭＧＣＰ）、ゲートキーパ・プロトコル、および遠距離音声通信のための仮想私設ネットワークをさらに含む請求項４３に記載のシステム。
【請求項４５】
ローカル・アクセス・ネットワークのエッジに物理的に位置するゲートウェイに対して企業ネットワークによって提供されるコール制御機能に関連するＸＭＬタグの使用を介して、前記ローカル・アクセス・ネットワークの前記エッジまで企業アプリケーションを拡張することを含む方法。
【請求項４６】
ゲートウェイが、複数の企業ネットワーク間で共用される請求項４５に記載の方法。
【請求項４７】
ローカル・アクセス・ネットワークを介して受信されたコールが、ゲートウェイにおいて終了される請求項４５に記載の方法。
【請求項４８】
コールが、中継ネットワークを介してローカル・アクセス・ネットワークから企業ネットワークまでブリッジされる請求項４８に記載の方法。
【請求項４９】
中継ネットワークが、回線交換長距離電話ネットワーク、ボイス・オーバーＩＰネットワーク、ボイス・オーバーＡＴＭネットワーク、またはボイス・オーバー・フレーム・リレー・ネットワークのどれかである請求項４９に記載の方法。
【請求項５０】
ローカル・アクセス・ネットワークが、セルラー電話ネットワーク、無線ネットワーク、または有線ネットワークのどれかを含む請求項４８に記載の方法。
【国際調査報告】
2004500754.tif 000102
2004500754.tif 000103
2004500754.tif 000104