JP2004500754A - Virtual intelligent network for user interaction service - Google Patents

Abstract

Having a distributed call center system that can answer, service, queue, and route calls at the local point of presence, providing inbound call centers and outbound call centers A virtual intelligent network (VIN) that reduces communication costs for the center and increases operational efficiency. VIN is a set of points distributed over a point-of-presence close to the point of origin of the call, connected by a user-controlled virtual private network to a local call center gateway at the business location where the call center resides. Includes presence call center gateway.

Description

【００７５】
次に、グローバルＴＯＮＥＭＡＰを定義する。ＴＯＮＥＭＡＰにより、発呼者は、任意の時点で０を押してオペレータに到達すること、または^＊キーを押してログイン・メニューに直接に行くことができる。また、発呼者が、無効なキーを押した場合、そのようなケースを扱う指定されたＨＲＥＦに配置された別のＸＭＬ　Ｐａｇｅに制御が渡される。これは、新しいＴＯＮＥＭＡＰによってオーバーライドされない限り、後続のすべてのページに適用される。

【００７６】
次に、グローバルＥＸＣＥＰＴＩＯＮＭＡＰを定義することができる。ＥＸＣＥＰＴＩＯＮＭＡＰは、発呼者が、ＦＩＥＬＤ値を入力するように、またはＭＥＮＵから選択を行うように求められたとき、指定されたタイムアウト期間内にキーを押せなかったときはいつでも、例外が生成されるようにさせる。このとき、制御は、指定されたタイムアウト例外ハンドラ（ｔｉｍｅｏｕｔ．ａｓｐ？ＳＥＳＳＩＯＮＩＤ＝３）に渡される。また、例外は、発呼者が突然にハングアップした場合にも生成される。各ＥＸＣＥＰＴＩＯＮ内のＨＲＥＦ属性は、そのような例外が生じた場合、どのＸＭＬ　Ｐａｇｅを次に取り出すかを指定する。グローバルＥＸＣＥＰＴＩＯＮＭＡＰは、オーバーライドされない限り、後続のすべてのページに適用される。

【００７７】
次に、挨拶メッセージを再生するコマンドを発行することができる。メッセージには、発呼者によって割込みが行われるべきではなく、したがって、メッセージが再生されている間に発呼者が押す可能性があるどのキーも無視する命令が存在する。

ページの終りに達すると、最初のＰａｇｅの開始で指定された次のＸＭＬ　Ｐａｇｅが取り出される（ｉｎｉｔｉａｌ．ａｓｐ）。
【００７８】
第２の例、例２は、１組の選択を告知し、発呼者から単一のトーン入力を受け入れるためのＸＭＬ　Ｐａｇｅが提供される。

【００７９】
前のＰａｇｅ上に指定されたグローバルＴＯＮＥＭＡＰで（例１からの）、このＰａｇｅのローカルＴＯＮＥＭＡＰは、「０」、「^＊」、「２」のすべてが有効な応答であるようにする。ＭＥＮＵをエグジットした後、ＭＥＮＵ内で指定されたＴＯＮＥＭＡＰは、もはや適用可能ではなく、「０」および「^＊」だけが有効なトーンとして受け入れられることになる。ＸＭＬ　Ｐａｇｅ中のＦＯＲＭ内またはＭＥＮＵ内で処理される必要のあるどのグローバル・マップも（ＥＸＣＥＰＴＩＯＮＭＡＰならびにＴＯＮＥＭＡＰ）、ＦＲＯＭまたはＭＥＮＵよりも上に配置されなければならない。ＸＭＬ　Ｐａｇｅ中のタグの実行は、順次に行われる性質のものである。Ｐａｇｅの終りで定義されるマップが、そのＰａｇｅ中で実行されるタグに影響を与えるのを期待することはできない。上記のＭＥＮＵ内のＰＬＡＹのＰＡＵＳＥ下位要素内で指定されたタイムアウト期間内に、発呼者によってトーンが入力されない場合、ＴＩＭＥＯＵＴ例外が生成され、制御は、対応するＨＲＥＦに（この例では、ＮＡＭＥ＝「ラベル１」を有するＡラベルに）移る。無効なキーが入力された場合、ＴＯＮＥＩＤ＝ＯＴＥＨＲが適用され、制御は、やはりラベル１に移る。ＲＥＰＥＡＴ＝「ＭＥＮＵ」をＨＲＥＦ＝＃ラベル１の代りに使用して、ＴＭＥＯＵＴ　ＥＸＣＥＰＴＩＯＮで同じ効果を得ることも可能である。
【００８０】
次の例３では、１組の入力フィールド（社会保障番号およびパスワード）を受け入れるためのＸＭＬ　Ｐａｇｅが提示される。ＦＯＲＭ要素により、発呼者は、データがコール・センタに送られる前に複数のＦＩＥＬＤを入力することができる。例えば、以下では、ｓｓｎｕｍＦＩＥＬＤとｐａｓｓｗＦＩＥＬＤの両方のためのＦＯＲＭデータが収集された後に送信される（終了タグ＜／ＦＯＲＭ＞が現れたとき）。

【００８１】
ＦＯＲＭ内の様々なフィールドに対して発呼者によって入力されたあらゆる入力が、ＦＯＲＭ内のＨＲＥＦ属性によって指定されたＵＲＬに照会ストリング（ＵＲＬの後に？およびＮＡＭＥ、ＶＡＬＵＥの対が続く）として送信される。この照会ストリングは、終了タグ＜／ＦＯＲＭ＞が現れたときに送信される。ＩＮＰＵＴ内のＭＡＸ＿ＩＤＤ＝「２」属性は、最後のキーが入力されてから２秒間、何もキーが入力されない場合、あたかもＡＣＣＥＰＴキーが入力されたかのように、発呼者が入力値を入力するのを終えたものと見なされることを指定する。（ＩＤＤは、Ｉｎｔｅｒ−ｄｉｇｉｔ−ｄｅｌａｙの省略である）。ＴＩＭＥＯＵＴイベントとＭＡＸ＿ＩＤＤの区別は、かなり微妙である。音声ファイルの再生が停止した後、ＰＡＵＳＥのＴＩＭＥ属性によって指定された期間内に第１の数字さえ入力されない場合、ＥＶＥＮＴ＝ＴＩＭＥＯＵＴを有するＥＸＣＥＰＴＩＯＮが生じる。ただし、ＴＩＭＥ秒内に１つまたは複数の数字が入力され、次に、ＭＡＸ＿ＩＤＤ秒間にわたって全く数字が入力されない場合、フィールド入力は、完了したものと見なされる。パスワード・フィールドに対するＭＡＸＤＩＧＩＴＳは、最大パスワード長が７であるものの、８と指定される。これは、ＡＣＣＥＴＰ文字である＃キーに対応するためである。
【００８２】
次の例４では、発呼者のアカウント記録（例えば、アカウント収支）を再生するためのＸＭＬ　Ｐａｇｅが提供される。

【００８３】
次の例５では、さよならメッセージを再生して、このコールを終了するために制御をＣＦＭに戻すためのＸＭＬ　Ｐａｇｅが提供される。

【００８４】
以下の例６は、ＣＦＭに指示してコールをオペレータに転送させるためのＸＭＬ　Ｐａｇｅを提供する。

【００８５】
ＩＶＲアプリケーションとＰＯＰゲートウェイの間の対話に加え、ＣＦＭとＩＶＲアプリケーションの間の対話も存在する。前述したとおり、ＣＦＭは、ＶＩＮ内のサーバ上で実行されるソフトウェア構成要素であり、コール・センタＩＶＲアプリケーションとＰＯＰゲートウェイ・サーバの間の通信を円滑にする。ＣＦＭとＩＶＲアプリケーションの間で直接の対話は、全く必要ない（また、これらが同じコンピュータ・プラットフォーム上に常駐するか、異なるプラットフォーム上に常駐するかも重要ではない）。代りに、これらのアプリケーションは、ＰＯＰサーバと直接に通信することができる。制御が、ＣＦＭからＩＶＲアプリケーションに渡される必要があるとき、ＣＦＭは、次のＨＲＥＦがＩＶＲアプリケーションのＵＲＬをポイントするＸＭＬ　ＰａｇｅをＰＯＰサーバに送信する。同様に、ＩＶＲアプリケーションは、制御をＣＦＭに送り返す必要があるとき、ＰＯＰサーバに指示して、ＣＦＭに関連するＵＲＬから次のＸＭＬ　Ｐａｇｅを要求するようにさせる。渡される必要のあるあらゆるパラメータが、ＨＴＴＰ要求の中でＵＲＬ名の後、照会ストリングの中の名前／値の対として送信される。これを以下の特定の例の助けを借りてより詳細に説明する。
【００８６】
着信コールがＰＯＰサーバにおいて受信されたばかりである状況を考慮されたい。中央ルックアップ・データベースの助けを借りて、ＰＯＰサーバは、着呼番号に対応する顧客の（すなわち、コール・センタ・プロバイダの）ＣＦＭ　ＵＲＬを知る。次に、ＰＯＰサーバは、以下のＵＲＬにＨＴＴＰ要求を送信する。

この例では、＜ｃａｌｌ−ｍｇｒ−ｕｒｌ＞は、ルックアップ・サーバから獲得されたコール・フロー・マネージャのＵＲＬであり（また、照会ストリングを含まない）、＜ｄｉｄ＞は、着信コールに関する着呼番号であり、＜ａｎｉ＞は、着信コールに関する発呼者の番号であり、またＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＰＲＯＣＥＳＳ＿ＩＮＣＡＬＬは、ＣＦＭに必要な次の処理が、新しい着信コールを処理することであるのを示す。
【００８７】
以上に応答して、ＣＦＭは、コールが受け入れられるべきか、拒否されるべきか（あるリソースの可用性に応じて）を示すＸＭＬ　ＰａｇｅをＰＯＰサーバに戻すことができる。コールが受け入れられる場合、顧客のＩＶＲアプリケーションのＵＲＬが、ＳＥＳＳＩＯＮ　ＩＤとともに（ＡＣＣＥＰＴ＿ＣＡＬＬ）ＸＭＬ　Ｐａｇｅ中に含められ、ＳＥＳＳＩＯＮ　ＩＤは、ＰＯＰサーバと顧客のＩＶＲアプリケーションの間における将来のすべての通信に含められる。顧客のＩＶＲアプリケーションに対するＰＯＰサーバの第１のＨＴＴＰ要求は、次の形式を有することになる。

この例では、＜ｉｖｒ−ｕｒｌ＞は、ＡＣＣＥＰＴ＿ＣＡＬＬページ中でＣＦＭによってＰＯＰサーバに送信されるＩＶＲアプリケーションのＵＲＬであり、＜ｓｅｓｓｉｏｎｉｄ＞は、ＡＣＣＥＰＴ＿ＣＡＬＬページ中でＣＦＭによってＰＯＰサーバに送信されるＳＥＳＳＩＯＮＩＤであり、＜ｄｉｄ＞は、着信コールに関する着呼番号であり、また＜ａｎｉ＞は、着信コール内の発呼者の番号である。
【００８８】
この時点からは、ＩＶＲアプリケーションが制御を行い、ＰＯＰサーバが、適切なタグを有するＸＭＬ　Ｐａｇｅ（前述した例１ないし６に提供されるＸＭＬ　Ｐａｇｅのような）の助けを借りて、どのプロンプトおよび選択を発呼者に提示しなければならないかを指示する。ＳＥＳＳＩＯＮＩＤが、ＰＯＰサーバからの各ＨＴＴＰ要求ごとの照会ストリングの一部として、またＩＶＲアプリケーションによって送信される各ＸＭＬ　Ｐａｇｅ中のＸＭＬ　Ｐａｇｅタグ内の属性として含められる。ＤＩＤおよびＡＮＩは、最初のＨＴＴＰ要求を除き、ＰＯＰサーバからのどのＨＴＴＰ要求の照会ストリング中に含まれる必要はない。
【００８９】
ＩＶＲアプリケーションは、コールを終了するため、またはアウトバウンドのコールを行うために制御をＣＦＭに戻す準備ができているとき、次の値を有するＨＲＥＦをＰＯＰサーバに送信することができる。

【００９０】
ＣＦＭに伝送される必要があるＮｅｘｔＡｃｔｉｏｎ要求は、ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱおよびＥＮＤ＿ＣＡＬＬだけである。ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱは、新しいセッションを開始するようにＣＦＭに促すＷＥＢアプリケーション（例えば、Ｃｌｉｃｋ−ｔｏ−ｔａｌｋ）によって送信される割込みである。この要求のためのパラメータは、以下のとおりである。
ＩＶＲＵＲＬ：ＰＯＰサーバに対する次のＣＲＥＡＴＥ＿ＬＥＧ＿ＲＥＱ割込みの一部であるべきＵＲＬ。このパラメータは、新しい会話が開始された後、どこから次のＸＭＬ　Ｐａｇｅを取り出すべきかをＰＯＰサーバに指示する。
ＴＥＬＮＵＭが、新しい会話がそこで開始されるべきＰＯＰサーバ（およびゲートウェイ）をＣＦＭが識別するのを助ける。
ＮＵＭ＿ＬＩＮＥＳが、このセッションのために予約される必要があるアウトバウンドの電話回線の数を指定する。Ｃｌｉｃｋ−ｔｏ−ｔａｌｋアプリケーションの場合、この数は、常に２である。Ｃｌｉｃｋ−ｔｏ−ｔａｌｋアプリケーションで必要とされる第２の電話番号が、顧客アプリケーションのＩＶＲＵＲＬ内に担持されなければならない。
ＡＰＰ＿ＮＡＭＥが、この処理が所望されるアプリケーションを識別する。このパラメータは、この要求が、そこに出されなければならないＣＦＭプロセスをＣＦＭフロントエンドが識別するのを助ける。
ＦＡＩＬＵＲＥ＿ＵＲＬが、ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱを実行する際に障害が生じたことをＶＩＮの構成要素に知らせるのに使用すべきＵＲＬを指定する。
【００９１】
ＮＥＷ＿ＳＥＳＳＩＯＮ＿ＲＥＱ割込みに対する応答は、ＲＥＳＵＬＴ属性が成功または失敗を示す単一のＲＥＳＰＯＮＳＥタグを含むＸＭＬ　Ｐａｇｅでなければならない。ＸＭＬ　Ｐａｇｅヘッダ内のＨＲＥＦ属性は、空（“”）でなければならない。
【００９２】
ＩＶＲアプリケーション／発呼者による通常のハングアップまたは別の仕方では扱うことのできず、コールを終了する以外のオプションが存在しない誤りの状況（例えば、ＩＶＲサーバが停止したときなどの）に応答して、ＥＮＤ＿ＣＡＬＬ照会ストリングが、ＰＯＰサーバによってＣＦＭに送信されるのが可能である。ＩＶＲアプリケーションが、コールを終了することを望む場合、最後のＸＭＬ　Ｐａｇｅは、ＣＦＭをポイントするＨＲＥＦを有し、以下の照会ストリングを有することになる：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬ＆ａｍｐ；ＳＥＳＳＩＯＮＩＤ＝＄ｓｅｓｓｉｏｎｉｄ＄＆ａｍｐ；ＲＥＡＳＯＮ＝ＮＯＲＭＡＬ。発呼者が、ＩＶＲセッションの途中でハングアップした場合、ＰＯＰサーバは、まず、以下の照会ストリングを有するＨＴＴＰ要求をＣＦＭに送信する：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬプラス他の名前／値の対。また、ＰＯＰサーバは、ＣＡＬＬＥＲＨＵＰグローバルＥＸＣＥＰＴＩＯＮの一部として指定されたＵＲＬにおけるＩＶＲアプリケーションにもＨＴＴＰ要求を送信する。ＩＶＲサーバが、何らかの理由で停止した場合、ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰのＩＶＲ＿ＥＲＲＯＲ例外内に設定された値に応じて（ＰＯＰサーバは、その時点までには、＄ｌａｓｔ−ｅｒｒｏｒ＄、＄ｅｒｒｏｒ−ｕｒｌ＄、および＄ｌａｓｔ−ｅｒｒｏｒ−ｓｔｒｉｎｇ＄という値を既に設定していなければならない）、ＰＯＰサーバは、以下の照会ストリングをＣＦＣに送信することができる：ＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬ＆ａｍｐ；ＲＥＡＳＯＮ＝ＩＶＲ＿ＥＲＲＯＲ＆ａｍｐ；ＳＥＳＳＩＯＮＩＤ＝＄ｓｅｓｓｉｏｎｉｄ＄＆ａｍｐ；ＥＲＲＯＲ＝＄ｌａｓｔ−ｅｒｒｏｒ＄＆ａｍｐ；ＵＲＬ＝＄ｌａｓｔ−ｅｒｒｏｒ−ｕｒｌ＄＆ａｍｐ；ＤＥＳＣＲＩＰＴＩＯＮ＝＄ｌａｓｔ−ｅｒｒｏｒ−ｓｔｒｉｎｇ＄。
【００９３】
ＰＯＰサーバとＩＶＲアプリケーションの間における通信でそうであったように、ＰＯＰサーバとＣＦＭの間における通信の基本的方法は、ＸＭＬ　Ｐａｇｅの使用を介する。この通信は、着信コールがＰＯＰサーバに現れるとすぐに開始され、ネットワーク・オペレーション・センタ（ＮＯＣ）（図９を参照）を使用するＤＩＤ／ＣａｌｌＭｇｒＵＲＬ翻訳を介して、ＰＯＰサーバが、ＣＦＭのＵＲＬを知る。ＰＯＰサーバは、ＸＭＬ　Ｐａｇｅ要求の照会ストリング中のＮＡＭＥ、ＶＡＬＵＥの対の形態で要求に関する情報を送信する。ＣＦＭは、適切な要素を有するＸＭＬ　Ｐａｇｅの形態で応答を戻す。以下の要素／タグが、そのようなコール制御応答のためにＣＦＭにとって利用可能である。さらに、前述したＬＥＧ＿ＷＡＩＴタグをＰＯＰサーバとＣＦＭの間における通信のために使用することも可能である。同様に、ＢＲＩＤＧＥ＿ＣＡＬＬタグおよびＵＮＢＲＩＤＧＥ＿ＣＡＬＬタグも使用される。ＣＦＭにとっての違いは、ＡＬＬのＬＥＧ＿ＩＤを使用できないだけである。ＣＦＭは、ただ１つだけのＬＥＧ＿ＩＤを明示的に指定してコールをブリッジし、かつ／またはブリッジ解除しなければならない。
【００９４】
「ＸＭＬ　Ｐａｇｅ」要素は、ＰＯＰサーバとの通信のためにＣＦＭによって使用されるすべてのＸＭＬ　Ｐａｇｅのためのルート要素である。この要素は、以下の属性を有することが可能である。
ＴＹＰＥ　　ＣＣまたはＩＶＲという値をとることができる。ＣＦＭは、値ＣＣ（コール制御）を使用する。
ＣＵＳＴＩＤ　　顧客を識別する
ＰＡＧＥＩＤ　　（オプション）ページ自体を識別する
ＶＥＲＳＩＯＮ　　顧客のアプリケーションのバージョン番号を識別するために顧客によって使用される
ＳＥＳＳＩＯＮＩＤ　　発呼者との特定のセッションを識別するための識別子
各ＸＭＬ　ＰａｇｅはＰＯＰサーバによるコール制御要求に対する応答を表す。ＸＭＬ　Ｐａｇｅの可能な子（下位要素）は、ＡＣＣＥＰＴ＿ＣＡＬＬ、ＬＥＧ＿ＷＡＩＴ、ＲＥＳＰＯＮＳＥ、ＤＩＡＬ＿ＣＡＬＬ、ＢＲＩＤＧＥ＿ＣＡＬＬ、ＵＮＢＲＩＤＧＥ＿ＣＡＬＬ、ＨＡＮＧＵＰ＿ＣＡＬＬ、ＤＥＳＴＲＯＹ＿ＬＥＧ、ＲＥＪＥＣＴ＿ＣＡＬＬ、ＥＮＤ＿ＣＡＬＬ、ＭＡＫＥ＿ＯＵＴＣＡＬＬ、ＳＥＴ、ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰ、ＥＸＣＥＰＴＩＯＮ、およびＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲである。
【００９５】
ＡＣＣＥＰＴ＿ＣＡＬＬ要素は、ＣＦＭによって使用されて、着信電話コールのためのリソースが利用可能であること、およびＰＯＰサーバがコールを受け入れるべきことをＰＯＰサーバに警報する。
ＲＩＮＧＳ　　（オプション）コールに応答するまでのリングバックにおけるリングの回数を制御する属性。ＩＶＲアプリケーションからの最初のＸＭＬ　Ｐａｇｅが受信されるまで、必要なリングが鳴らされる。
ＵＮＩＴ　　（オプション）値は、ＲＩＮＧＳの単位を示すＳＥＣまたはＮＵＭＢＥＲであることが可能である。
ＨＲＥＦ　　ＰＯＰサーバがコールに応答した後、ＰＯＰサーバによって次のＸＭＬ　Ｐａｇｅがそこから取り出されるべきＩＶＲアプリケーションのＵＲＬ。
【００９６】
このＸＭＬ　Ｐａｇｅタグは、着信コールが来たとき、ＰＯＰサーバからの要求に応答して送信される。このページのＵＲＬに対する要求は、ＤＩＤおよび、入手可能な場合、着信コールのＡＮＩを照会ストリングの一部として含まなければならない。ＡＣＣＥＰＴ＿ＣＡＬＬ応答ページが、ＣＦＭによって作成されたセッションのための固有識別子であるＳＥＳＳＩＯＮＩＤを戻す。ＣＦＭ（ならびにＩＶＲアプリケーション）に対するＰＯＰサーバからの将来のすべての要求は、ＤＩＤおよびＡＮＩではなく、ＳＥＳＳＩＯＮＩＤを担持しなければならない。ＡＣＣＥＰＴ＿ＣＡＬＬは、子としての下位要素を全く有さない。
【００９７】
ＡＣＣＥＰＴ要素を含むＸＭＬ　Ｐａｇｅ（ＣＦＭからの最初のページ）は、回復不能のＩＶＲの誤りを扱うため、ＩＶＲ＿ＥＲＲＯＲ＿ＥＸＣＥＰＴＩＯＮを含んだＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰも含まなければならない。ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、グローバル・マップであり、どのＡＣＣＥＰＴタグよりも前に配置されなければならない。
【００９８】
割込み要求（上記を参照）に応答してＲＥＳＰＯＮＳＥタグが、ＣＦＭまたはＰＯＰサーバによって送信される。このタグは、割込みによって要求された処理が成功であったか、失敗であったかを示し、失敗であった場合、失敗の理由を示す。ＲＥＳＰＯＮＳＥは、２つの必須の属性を有し、子を有さない。
ＲＥＳＵＬＴ　　ＳＵＣＣＥＳＳまたはＦＡＩＬＵＲＥ。
ＲＥＡＳＯＮ　　（オプション）ＦＡＩＬＵＲＥの場合、可能な値は、ＵＮＫＮＯＷＮ＿ＲＥＱ、ＩＮＶＡＬＩＤ＿ＰＡＲＡＭＥＴＥＲＳ、ＮＯ＿ＲＥＳＯＵＲＣＥＳである。
【００９９】
ＩＶＲアプリケーションおよび他のアプリケーションによる要求に応答して、ＤＩＡＬ＿ＣＡＬＬタグを有するＸＭＬ　ＰａｇｅがＣＦＭによって伝送されて、アウトバウンドのコールを行う。ＤＩＡＬ＿ＣＡＬＬの属性は、以下のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号。
ＡＮＩ　　（オプション）電話マネージャが、発信コール内で送信すべきＡＮＩ。この値は、アプリケーションによってＱＵＥＵＥ＿ＣＡＬＬタグ内に指定される。
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＤＩＡＬ＿ＥＲＲＯＲ例外内に指定されたＨＲＥＦに要求を送信することによってＣＦＭに即時に通知する。アウトバウンドのコールが成功した場合、ＰＯＰサーバは、次のタグ（存在する場合）に、またはＰａｇｅの最上部のＸＭＬ　Ｐａｇｅタグ内のＨＲＥＦ（ＤＩＡＬ＿ＣＡＬＬがページ上の最後のタグの場合）にとりかかる。ＤＩＡＬ＿ＣＡＬＬは、１つの子要素−ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを有する。また、グローバルＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰも、ＣＡＬＬＥＲＨＵＰイベントで指定されなければならない。また、＄ｅｎｄ−ｃａｌｌ−ｕｒｌ＄も、この時点までに、会話コントローラのために設定されなければならない。
【０１００】
ＨＡＮＧＵＰ＿ＣＡＬＬ要素がＣＦＭによって使用されて、このタグを受け取るレッグ上のコールが終了されなければならないことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＥＲＲＯＲまたはＣＡＬＬＥＲＨＵＰ。
ＨＡＮＧＵＰ＿ＣＡＬＬタグは、ドロップされたコールに関連する会話コントローラを破棄しないということでＥＮＤ＿ＣＡＬＬタグとは異なる。関連する会話コントローラ上でさらなるコールが行われない場合、ＨＡＮＧＵＰ＿ＣＡＬＬタグの後には、ＤＥＳＴＲＯＹ＿ＬＥＧタグが続くことが可能であり、あるいは別のアウトバウンドのコールを行うために別のＤＩＡＬ＿ＣＡＬＬが続くことが可能である。ＨＡＮＧＵＰ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０１】
ＤＥＳＴＲＯＹ＿ＬＥＧ要素がＣＦＭによって使用されて、会話コントローラが終了されるべきことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＥＲＲＯＲまたはＣＡＬＬＥＲＨＵＰ。
ＤＥＳＴＲＯＹ＿ＬＥＧは下位要素を全く有さない。ＤＥＳＴＲＯＹ＿ＬＥＧには、ＨＡＮＧＵＰ＿ＣＡＬＬタグが先行するものとされてはいるが、レッグ上にアクティブなコールが存在する場合、会話コントローラは、先行するＨＡＮＧＵＰ＿ＣＡＬＬなしにＤＥＳＴＲＯＹ＿ＬＥＧを実際に受け取ったならば、このレッグを破棄するのに必要とされる必要なクリーンアップを行わなければならない。
【０１０２】
ＲＥＪＥＣＴ＿ＣＡＬＬ要素がＣＦＭによって使用されて、コールのためのリソースが割り振られていないこと、および話中信号を出すことによってＰＯＰサーバが着信コールを拒否すべきことをＰＯＰサーバに通知する。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）。ＮＯＰＯＲＴＳまたはＯＴＥＨＲ。
ＲＥＪＥＣＴ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０３】
ＥＮＤ＿ＣＡＬＬ要素がＣＦＭによって使用されて、コールが終了されるべきことをＰＯＰサーバに通知するのが可能である。このタグを有するＸＭＬ　Ｐａｇｅが、コールを終了するＰＯＰサーバからのＣＦＭに対する要求に応答して送信される。ＰＯＰサーバは、そのような要求の照会ストリング中のＣＣ．ＮＥＸＴＡＣＴＩＯＮ＝ＥＮＤ＿ＣＡＬＬを使用して、そのようにＣＦＭにアドバイスする。この要素の属性は、以下のとおりである。
ＲＥＡＳＯＮ　　（オプション）ＮＯＲＭＡＬまたはＩＶＲ＿ＥＲＲＯＲまたはＣＡＬＬＥＲ＿ＲＥＱ。
このタグは、インバウンドのコールまたはアウトバウンドのコールが既に終了されたとき（以下のＭＡＫＥ＿ＯＵＴＣＡＬＬを参照）、ＣＦＭによってＰＯＰサーバにも送り返される。ＣＦＭは、このタグをＰＯＰサーバに送信した後、自らのリソース使用カウントをクリーンアップして減分する。ＥＮＤ＿ＣＡＬＬは、下位要素を全く有さない。
【０１０４】
ＩＶＲアプリケーションによる要求に応答して、ＭＡＫＥ＿ＯＵＴＣＡＬＬタグを有するＸＭＬ　ＰａｇｅがＣＦＭによって送信されてアウトバウンドのコールを行い、発呼者の着信コールをこのアウトバウンドのコールにブリッジする。この要求は、ＩＶＲアプリケーションによって送信されたＸＭＬ　Ｐａｇｅ上のＨＲＥＦに従うことにより、ＩＶＲアプリケーションのためにＰＯＰサーバによって行われる。例えば、発呼者がキー「０」を押したとき、発呼者をオペレータに接続することをＩＶＲアプリケーションが望む場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ　Ｐａｇｅは、次の値を有するＴＯＮＥＩＤ＝０に対応するＨＲＥＦを有していなければならない。

ここで、＜ｔｅｌｎｕｍ＞は、ＰＯＰサーバが呼び出すことをＩＶＲアプリケーションが望む電話番号によって置き換えられ、また＄ｓｅｓｓｉｏｎｉｄ＄は、インバウンドのコールが最初に来たときに作成されたセッションＩＤによって置き換えられる。
【０１０５】
ＭＡＫＥ＿ＯＵＴＣＡＬＬの属性は、以下のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号
ＨＲＥＦ　　コールが成功したかどうかを通知する（アウトバウンドが最終的に終了したとき）ためのコール・フロー・コンダクタＵＲＬ
【０１０６】
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ例外（例９を参照）内で指定されたＨＲＥＦに要求を送信することにより、そのことをＣＦＭに通知する。アウトバウンドが成功した場合、ＰＯＰサーバは、即時には、ＣＦＭに全く通知を送信しない。むしろ、ＰＯＰサーバは、アウトバウンドのコールが終了される（発呼者または着呼側により）のを待ってから、ＭＡＫＥ＿ＯＵＴＣＡＬＬのＨＲＥＦ属性に要求を送信する。成功通知と失敗通知の両方に応答して、ＣＦＭは、ＥＮＤ＿ＣＡＬＬタグを有するＸＭＬ　Ｐａｇｅを送り返す。
【０１０７】
ＭＡＫＥ＿ＯＵＴＣＡＬＬは、１つの子要素を有する。あるコール制御例外と、そのような例外が生じた場合、取り出すべきＸＭＬ　ＰａｇｅのＵＲＬとのマッピングを指定するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰである。ＩＶＲ＿ＥＲＲＯＲ　ＥＸＣＥＰＴＩＯＮを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、ＣＦＭからの最初のＸＭＬ　Ｐａｇｅ中のどのＡＣＣＥＰＴタグよりも前に含まれなければならない。ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ　ＥＸＣＥＰＴＩＯＮを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰが、ＭＡＫＥ＿ＯＵＴＣＡＬＬタグ内およびＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲタグ内に含まれなければならない。
【０１０８】
ＥＸＣＥＰＴＩＯＮＭＡＰは、子要素ＥＸＣＥＰＴＩＯＮを使用して、例外と、そのような例外が生じた場合に次のページをそこから取り出すＵＲＬとのマッピングを指定することができる。ＥＸＣＥＰＴＩＯＮは、２つの必須の属性を有する。
ＥＶＥＮＴ　　可能な値は、ＢＲＩＤＧＥ＿ＥＲＲＯＲ、ＵＮＢＲＩＤＧＥ＿ＥＲＲＯＲ、ＩＶＲ＿ＥＲＲＯＲ、およびＯＵＴＣＡＬＬ＿ＥＲＲＯＲである。
ＨＲＥＦ　　ＥＶＥＮＴによって指定された例外が生じた場合、次のページをそこから取り出すＵＲＬ。
ＥＸＣＥＰＴＩＯＮは、子を有さない。
【０１０９】
ＩＶＲ＿ＥＲＲＯＲが、回復不能のＩＶＲアプリケーションの誤りを示す。ＣＦＭからの最初のＸＭＬ　Ｐａｇｅ（ＡＣＣＥＰＴタグを含む）は、ＩＶＲ＿ＥＲＲＯＲイベントを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを含まなければならず、またこのＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰは、ＡＣＣＥＰＴタグよりも前に配置されなければならない。ＯＵＴＣＡＬＬ＿ＥＲＲＯＲは、コールをダイヤルしようとする試みが失敗したことを示す。ＭＡＫＥ＿ＯＵＴＣＡＬＬタグまたはＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲタグを有するＸＭＬ　Ｐａｇｅが、ＯＵＴＣＡＬＬ＿ＥＲＲＯＲイベントを有するＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを含まなければならない。
【０１１０】
ＳＥＴタグにより、ＣＦＭは、ＰＯＰによる後の置換のために変数の値を設定することができる。このタグは、ＰＯＰサーバが、特定の値を特定の変数名関連付けるべきこと、およびＣＦＭが、後に同じＸＭＬ　Ｐａｇｅ中または別のＸＭＬ　Ｐａｇｅ中で変数名を使用するとき、ＰＯＰサーバが、変数名を値で置き換えるべきことをＣＦＭが、ＰＯＰサーバに示すのを可能にする便利な機構である。ＳＥＴは、２つの必須の属性を有し、子を有さない。
ＶＡＲＮＡＭＥ　　変数の名前。
ＶＡＬＵＥ　　変数に割り当てられる値。
【０１１１】
ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲ要素がＣＦＭによって使用されて、アウトバウンドのコールを行い、そのコールを着信コールにブリッジすることによって着信コールをオペレータに再ダイレクトする。この要素は、ＩＶＲアプリケーションが何らかの理由でダウンしている場合、便利である。ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲの属性は、次のとおりである。
ＴＥＬＮＵＭ　　ＰＯＰサーバが呼び出す必要のある電話番号
ＨＲＥＦ　　コールが成功した場合、（アウトバウンドのコールが最終的に終了したとき）通知を行うためのＣＦＭ　ＵＲＬ
アウトバウンドのコールが失敗した場合、ＰＯＰサーバは、ＥＶＥＮＴ＝ＯＵＴＣＡＬＬ＿ＥＲＲＯＲ例外内で指定されたＨＲＥＦに要求を送信することにより、そのことをＣＦＭに即時に通知する。アウトバウンドのコールが成功した場合、ＰＯＰサーバは、コール・フロー・コンダクタに全く通知を送信しない。ＩＭＭＥＤＩＡＴＥ＿ＴＲＡＮＳＦＥＲは、１つの子要素−ＣＣ＿ＥＸＣＥＰＴＩＯＮＭＡＰを有する。
【０１１２】
前と同様に、いくつかの例が、上記のタグの使用を説明するのに役立つ。例７で、ＰＯＰサーバに指示して着信コールを受け入れるようにさせるためのＸＭＬ　Ｐａｇｅが提示されている。このページは、ＰＯＰサーバからの新規コール指示に応答して送信される。この指示は、通常、新しく着信したコールに関してＰＯＰサーバによってＣＦＭに送信される最初の要求である。ＡＣＤに対するプロキシ・コールのためのリソースを割り振った後、ＣＦＭは、このＰａｇｅをＰＯＰサーバに戻す。Ｐａｇｅは、ＳＥＳＳＩＯＮＩＤ属性内に、ＣＦＭによって予約されたコール構造のアドレスを含むことに留意されたい。ＣＦＭは、ＡＣＤ上またはＩＶＲ上の利用可能なポートをもうすぐ使い果たすことが分かった場合、コールがＰＯＰサーバによって応答されるまでのＲＩＮＧＢＡＣＫ内で与えられるＲＩＮＧＳの数を増加させることができる。

図５に示すとおり、ＰＯＰゲートウェイからの着信コール警報に応答して、そのようなＰａｇｅをＣＦＭによって戻される＜ＡＣＣＥＰＴ＿ＣＡＬＬ＞ページとして使用することができる。
【０１１３】
次の例８では、コール終了例が提供される。この場合、発呼者が済み、コールが終了されるべきであるとＩＶＲアプリケーションが判定している。そのような場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ　Ｐａｇｅは、以下のようなＨＲＥＦを有することになる。

【０１１４】
ＰＯＰサーバは、要求をＣＦＭに送信するとき、以下のＸＭＬ　Ｐａｇｅを送り返す。

【０１１５】
次の例９では、ＩＶＲアプリケーションは、発呼者がアウトバウンドのコールを行う必要があると判定した。そのような場合、ＩＶＲアプリケーションによって送信される最後のＸＭＬ Ｐａｇｅは、以下のようなＨＲＥＦを有することになる。

ＰＯＰサーバは、要求をＣＦＭに送信するとき、以下のＸＭＬ　Ｐａｇｅを送り返す。

【０１１６】
次の例１０では、適切な技能セットを有するエージェントが応対可能になるのを待ってコールがＡＣＤの待ち行列の中に入れられたことをＰＯＰサーバに通知するためのＸＭＬ　Ｐａｇｅが提示されている。適切な技能セットを有するエージェント・グループに関する情報を含んだ照会ストリングを有するＲＥＤＩＲＥＣＴ　ＨＴＴＰ要求（元はＩＶＲサーバからの）に応答して、そのようなＰａｇｅがＣＦＭによって送信されるのが可能である。このＸＭＬ　Ｐａｇｅを介して、ＣＦＭは、ＰＯＰサーバに命令して、コールが保留されている間、発呼者に対して音楽／情報コマーシャル・ファイルを再生するようにさせる。ＣＡＬＬ＿ＱＵＥＵＥＤ要素は、オプションとして、待ち行列がどれだけ長いか、また予想される保留時間はどれぐらいかに関する指示を含むことが可能である。

【０１１７】
前述したタグを使用して、図５および７に示したもののようなコール・フロー管理オペレーションを容易に実施することができる。例えば、図５に示したとおり、インバウンドのコールが、コールの発信元の点に近いローカルＰＯＰゲートウェイにおいて代行受信され、そうでなければかかる可能性がある長距離料金を削減することができる。これに応答して、ローカルＰＯＰゲートウェイは、コールのことをＣＦＭに通知して、コールを管理するための命令を求める。コールのこの部分は、図でＬＥＧ＿ＩＤ＝１として示されている。
【０１１８】
ＰＯＰゲートウェイからの通知に応答して、ＣＦＭは、＜ＡＣＣＥＰＴ＿ＣＡＬＬ＞ページを戻し、ＰＯＰゲートウェイを適切なＵＲＬにダイレクトしてＩＶＲから命令を取り出すようにさせる。この指示に従って、ＰＯＰゲートウェイは、インバウンドのコールを扱うための命令を提供するＩＶＲアプリケーションとの交換を開始する。例えば、ＩＶＲは、前述したとおり、指定されたメニューを使用してプロンプト指示することが可能であるユーザからのデータ収集に関する命令を提供することができる。
【０１１９】
ＩＶＲとローカルＰＯＰゲートウェイの間のダイアログが進行する中で、ＩＶＲは、ＰＯＰゲートウェイに命令して、最終的に発呼者をコール・センタにおけるオペレータに接続することを目的として、プロキシ・コールをコール・センタのＡＣＤに入れる要求を行うようにさせることができる。図に示したとおり、これは、前述したＣＲＥＡＴＥ＿ＬＥＧ＿ＡＮＤ＿ＤＩＡＬコマンドを使用して行うことができる。指定されたＴＥＬＮＵＭは、コール・センタに到達するためにダイヤル呼出しされる番号である。他の場合、この命令は、コール・センタにおける構内ゲートウェイ・サーバに行くことが可能である。
【０１２０】
どちらの場合も、ゲートウェイ・サーバは、プロキシ・コールを開始する要求をＣＦＭに渡し、これに応答して、ＣＦＭは、そうするために要求を行っているゲートウェイとのダイアログを始める。プロキシ・コールがセットアップされ（図でＬＥＧ＿ＩＤ＝２として識別される）、プロキシ・コールに応答があるのが間近になると、示したとおり、２つのコール（ＬＥＧ＿ＩＤ＝１とＬＥＧ＿ＩＤ＝２）がブリッジされる（ＣＦＭからのＢＲＩＤＧＥ＿ＣＡＬＬコマンドに応答して）。
【０１２１】
インバウンドのコールの管理を可能にすることに加えて、ＸＭＬコマンドは、図７に示すとおり、コール・センタからのアウトバウンドのコールを管理するのにも使用することができる。今度は、ＩＶＲが、識別された電話番号（ｎｐａ）ｎｘｘ−ｘｘｘｘに対するコールのための新しいコール・セッションを確立するようにＣＦＭに求めることにより、プロセスを開始する。これに応答して、ＣＦＭは、適切なローカルＰＯＰゲートウェイを決定して、コール・セットアップ・ダイアログを開始し、ＰＯＰゲートウェイは、ＤＩＡＬ＿ＣＡＬＬコマンドを使用して指定された電話番号にアウトバウンドのコールを行うように命令される。このコールが確立されると、ＣＦＭは、制御をＩＶＲに引き渡し（Ｐａｇｅをそこから取り出すべき適切なＵＲＬをＰＯＰゲートウェイに渡すことにより）、次に、ＩＶＲが、適切な着呼側対話命令をＰＯＰゲートウェイに提供することができる。
【０１２２】
（システムの説明）
以上、本発明のプロセス・フローの態様を検討してきたので、システムの概要が役に立つであろう。図８は、エンド・ユーザ１１６が、発信元のローカルＰＳＴＮ１０６、長距離ネットワーク１１４、および終端するローカルＰＳＴＮ１０６を介してビジネス・コール・センタ１５０に接続されている本発明の少なくとも１つの実施形態による仮想インテリジェント・ネットワーク・システムの機能図である。
【０１２３】
ＶＩＮは、コール発信元の点に近い１つまたは複数のポイントオブプレゼンス１５２に分散された１つまたは複数のＰＯＰコール・センタ・ゲートウェイ・サーバ１４６を含む。これらのＰＯＰコール・センタ・ゲートウェイ・サーバ１４６は、１つまたは複数のコール・センタ・ネットワーク１４８によって１つまたは複数のビジネス・コール・センタ１５０における構内コール・センタ・ゲートウェイ・サーバ１４２に接続されている。コール・センタ・ネットワーク１４８は、複数のビジネス・コール・センタ１５０のためにＣＦＭアプリケーションおよびＩＶＲアプリケーションなどのユーザ指定のアプリケーションをホストする１つまたは複数のアプリケーションＷＥＢアプリケーション・サーバ１５４に接続されている。ＰＯＰコール・センタ・ゲートウェイ・サーバ１４６は、接続された構内コール・センタ・ゲートウェイ・サーバ１４２との長距離音声通信を可能にする交換公衆テレコミニュケーション・ネットワークまたは専用アクセス公衆テレコミニュケーション・ネットワーク１１４にさらに接続されている。
【０１２４】
ビジネス・コール・センタ１５０は、広い地域にわたって分散した複数のビジネス・コール・センタに属することが可能であり、また１つまたは複数の構内コール・センタ・ゲートウェイ・サーバ１４２を含むことが可能であり、ＰＯＰコール・センタ・ゲートウェイにおいて着信コールを扱う時点で、ＣＦＭアプリケーションによってそれらのサーバの１つが動的に選択されることになる。
【０１２５】
次に、図９を参照すると、ＰＯＰゲートウェイ１６６が、ＣＦＭの指示の下で、コールの発信元の点において、またはその近くでインバウンドのコールを代行受信して、それに応答する。さらに、ＰＯＰゲートウェイ１６６は、ＣＦＭ指定の対話式音声応答アプリケーションを使用して自動化されたサービスを提供し、コールにサービスを提供する適切なオペレータが応対可能になったとき、コールをコール・センタ１５０における構内コール・センタ・ゲートウェイ１６４に転送するまで、コールを保留にして待ち行列に入れ、かつ／またはコールの保留中、音楽またはカストマイズされた告知を発呼者に流す。コールが待ち行列に入れられた場合、ＣＦＭアプリケーションは、構内コール・センタ・ゲートウェイ１６４に対してコマンドを発行して、コール・センタ１５０においてプロキシ・コールを発信し、待ち行列に入れられたコールの進行を監視することができる。構内コール・センタ・ゲートウェイ１６４が、ＡＮＩやＤＮＩＳなどのコール特有の情報またはＷＥＢサーバ１５４上に配備されたＩＶＲアプリケーションによって提供される発呼者アカウント情報を使用するＣＦＭによって選択されて、最もよくマッチする応答リソースがインテリジェントに選択される。次に、構内コール・センタ・ゲートウェイ１６４がＣＦＭにそうするように警報したとき、ＣＦＭは、ＰＯＰコール・センタ・ゲートウェイ１６６に指示して、オペレータがコールに応答する前にジャスト・イン・タイムで、ローカルで待ち行列に入れられたコールを構内コール・センタ・ゲートウェイ１６６に経路指定するようにさせる。
【０１２６】
構内コール・センタ・ゲートウェイ１６４は、ＣＦＭコマンドに応答して、構内コール・センタＡＣＤに対するプロキシ・コールを生成する。次に、構内コール・センタ・ゲートウェイ１６４は、オペレータの応対可能性に関してＡＣＤ内のプロキシ・コールの進行を監視し、選択されたオペレータに対するジャスト・イン・タイムのコール・デリバリのためにＣＦＭと通信し、ＰＯＰコール・センタ・ゲートウェイ１６６と構内ＡＣＤの間でコールをブリッジする。
【０１２７】
ネットワーク・オペレーション・センタ（ＮＯＣ）１５６は、着呼番号をルックアップするためにＣＦＭおよび／またはＶＩＮの他のリソースによってアクセスされることが可能なデータベースをホストすることができる。このようにして、インテリジェントな着呼側の経路指定を提供することができる。
【０１２８】
図１０を参照すると、一実施形態による仮想インテリジェント・ネットワークは、複数のＰＯＰコール・センタ・ゲートウェイ１６６と、すべて単一のビジネス・コール・センタ１５０に属することが可能な１つまたは複数の構内コール・センタ・ゲートウェイ１６４と、そのビジネス・コール・センタのためのＣＦＭやＩＶＲアプリケーションなどのユーザ指定のアプリケーションをホストする１つまたは複数のＷＥＢアプリケーション・サーバ１５４とをコール・センタネットワーク１４８を介して接続する仮想私設ネットワークである。仮想私設ネットワークは、オプションのサービス品質保証で接続されたエンティティ間のセキュアな専用のデータ通信のために、非同期転送モード（ＡＴＭ）、フレーム・リレー、またはインターネット・プロトコル（ＩＰ）などの接続−トランスポート・プロトコルを提供する。
【０１２９】
図１１を参照すると、各ＰＯＰコール・センタ・ゲートウェイ１６６は、サービスを受ける各ビジネス・コール・センタ１５０ごとに１つの、ビジネス・コール・センタ１５０のためにすべて１つまたは複数のＷＥＢアプリケーション・サーバ１５４に接続された複数のそのようなコール・センタ・ネットワーク１４８の一部であることが可能である。ＰＯＰコール・センタ・ゲートウェイ１６６は、コール・センタ・ネットワーク１４８を使用して対応する構内コール・センタ・ゲートウェイ１６４に接続し、それぞれのビジネス・コール・センタのためにＣＦＭの指示の下で適切な対話式音声応答アプリケーションにアクセスする。
【０１３０】
以上の明細では、本発明をその特定の例としての実施形態に関連して説明してきた。ただし、頭記の特許請求の範囲に記載する本発明のより広汎な趣旨および範囲を逸脱することなく、特定の例としての実施形態に様々な改変および変更を加えるのが可能なことが明白であろう。例えば、前述したＸＭＬコマンドは、どのコンピュータ可読媒体（例えば、ＣＤ−ＲＯＭ、フロッピー（登録商標）・ディスク等）上にも記憶することができ、かつ／またはＶＩＮの要素を相互接続する媒体上の電気信号またはその他の（例えば、光、マイクロ波等）信号としてトランスポートすることができる。
【０１３１】
さらに、本ＶＩＮの全体的目標を見失ってはならない。要するに、ＶＩＮは、企業ネットワークにトランスペアレントな形で、また基礎を成す媒体トランスポート機構とは独立にアクセス・ネットワークのエッジにまで企業ネットワーク（例えば、前述したビジネス・コール・センタ）を拡張する。例えば、図１２に描いたネットワーク・トポロジを考慮されたい。ネットワーク２００は、ゲートウェイ２０４がそのエッジに設けられたいくつかの（Ｎ）アクセス・ネットワーク２０２を含む。ゲートウェイ２０４は、前述したＰＯＰコール・センタ・ゲートウェイと同様であることが可能である。
【０１３２】
各アクセス・ネットワーク２０２は、幾人かのユーザ２０６にとってのローカル・アクセス・ネットワークとして働くことができる。例えば、１つまたは複数のアクセス・ネットワーク２０２は、ローカル・ループ・ネットワーク（無線または有線の）、セルラー電話ネットワーク（アナログまたはデジタルの）、デジタル・ネットワーク（例えば、ＩＰ、ＡＴＭ、フレーム・リレー等）、またはその他のアクセス・ネットワークであることが可能である。ゲートウェイ２０４を介して、アクセス・ネットワーク２０２は、中継ネットワーク（ＩＸＮ）２１０および／またはＩＰネットワーク２１２を介して１つまたは複数の企業ネットワーク（例えば、ビジネス・コール・センタ、オフィス・コンピュータ・ネットワーク、イントラネット等）２０８と通信するように結合することができる。ＩＸＮ２１０は、中継通信事業者によって運営される長距離ネットワークまたはその他のテレコミニュケーション・ネットワークであることが可能であり、従来の時間分割多重（ＴＤＭ）トランスポート機構、アナログまたはデジタルの交換通信トランスポート機構、ボイス・オーバーＩＰ、ボイス・オーバー・ＡＴＭ、ボイス・オーバー・フレーム・リレー、または他の任意の回線交換トランスポートまたはその他の基礎を成すトランスポートおよび／または通信機構を使用して音声コールおよび／またはデータ通信を搬送することができる。ＩＰネットワーク２１２は、前述したＣＦＭサーバを含むことが可能である。
【０１３３】
例えば、前述したとおり、ＩＶＲサーバおよび／またはＣＦＭサーバの制御下で、ゲートウェイ２０４において実行されるローカル・アプリケーションの制御を介して、ゲートウェイ２０８の機能性がアクセス・ネットワーク２０２のエッジにまで届けられる。したがって、ユーザ２０６には、トランスポートおよび／または接続アクセスＩＸＮ２１０に関連する費用を被る必要なしにサービスを提供することができる。さらに、複数のゲートウェイ２０８（同じビジネス・エンティティに関連していなくてもよい）が、ゲートウェイ２０４を共用することができ、各ゲートウェイは、前述したＸＭＬ制御プロセスを介してゲートウェイ２０４で実行されるアプリケーションに対する制御を有する。というのは、そのような制御プロセスは、ＩＰネットワーク２１２を使用して、これらの制御プロセスは、ＩＸＮ２１０の使用に関連する料金も回避するからである。企業ネットワークに対する真の接続が必要とされるときだけ（例えば、オペレータが応対可能になったとき）、ＩＸＮ２１０を介してコールをブリッジする必要がある（どの仕方でも、例えば、回線交換ＰＳＴＮ、ボイス・オーバーＩＰ、ボイス・オーバーＡＴＭ、ボイス・オーバー・フレーム・リレー等）。
【０１３４】
また、本ＶＩＮは、容易な終端間コール経路指定も可能にする。例えば、前述したＸＭＬ制御プロセスを使用して、企業ネットワークは、ゲートウェイ２０４に宛先アドレス情報を提供し、ＩＰネットワークまたはその他のデジタル・ネットワークを介する着信コールのトランスポートを可能にすることができる。着信コールは、ＰＯＴＳダイヤル呼出し番号に関連付けられるものと考えられたい。従来の回線交換ＰＳＴＮは、このダイヤル呼出し番号を利用してコールを経路指定することができるが、ＩＰ、ＡＴＭ、フレーム・リレー等に基づくネットワークは、コールを経路指定するためには、関連アドレス（場合に応じて、例えば、ＩＰアドレス、ＶＰ／ＶＣＩ、ＤＬＣＩ等）を有していなければならない。前述したＸＭＬ制御手続きを使用して、ゲートウェイ２０４に、そのようなアドレスを提供し、そのようなネットワークを介して、場合によっては、ＩＰエンドポイントにまで直接に（例えば、ＩＰ電話機）コール経路指定を提供することができる。したがって、本ＶＩＮは、コール管理を媒体管理から分離して、ＶＯＩＰ（ＶＯＡＴＭ、ＶＯＦＲ等）を音声（またはその他のデータ）のトランスポート機構として効率的に使用する。したがって、本ＶＩＮおよびそれによって提供される複数のアプリケーションの一般的性質のため、明細および図面は、制限するものではなく、例示するものと見なされるべきである。
【図面の簡単な説明】
【図１】
ＰＢＸシステム、ＡＣＤシステム、およびＩＶＲシステムがコール・センタに配置された従来のコール・センタ構成を示す概略図である。
【図２】
長距離ネットワーク内にスイッチ・システム、ＡＣＤシステム、およびＩＶＲシステムが配置された従来のネットワーク・ベースのコール・センタ構成を示す概略図である。
【図３】
本発明の実施形態による仮想インテリジェント・ネットワークのオペレーション上の方法の一例を示す流れ図である。
【図４】
本発明の実施形態による構内コール・センタの選択のための１プロセスを示す流れ図である。
【図５】
本発明の実施形態による仮想インテリジェント・ネットワーク（ＶＩＮ）内におけるＸＭＬコマンドの使用の様々な態様を示すコール流れ図である。
【図６】
本発明の実施形態によるＶＩＮ内の伝送のためにＸＭＬ　Ｐａｇｅに含まれることが可能なＸＭＬタグの例を示す図である。
【図７】
本発明の実施形態によるコール・センタからアウトバウンドのコールを行うためのＶＩＮ内におけるＸＭＬコマンドのケースの様々な態様を示すコール図である。
【図８】
ポイントオブプレゼンス（ＰＯＰ）コール・センタ・ゲートウェイ、構内コール・センタ・ゲートウェイ、コール・センタ・ネットワーク、ネットワーク・オペレーション・センタ、およびＷＥＢアプリケーション・サーバを含む本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図９】
ＷＥＢアプリケーション・サーバ上に配備されたユーザ指定のアプリケーションによって制御されたコール・センタ・ネットワークを介して構内コール・センタ・ゲートウェイに接続されたＰＯＰコール・センタ・ゲートウェイを含む本発明の実施形態による仮想インテリジェント・ネットワーク構成を示す概略図である。
【図１０】
複数のＰＯＰコール・センタ・ゲートウェイに接続された複数のコール・センタ・サイトを有する単一のビジネスをサポートする本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図１１】
複数のＰＯＰコール・センタ・ゲートウェイに接続された複数のビジネス・コール・センタをサポートする本発明の実施形態による仮想インテリジェント・ネットワークの構成要素を示す概略図である。
【図１２】
本発明の実施形態による例としてのネットワーク・トポロジを示す図である。[0001]
(Related application)
This application is a co-pending application entitled "Point-of-Presence Call Center Management System", filed February 12, 1999 by Prem Uppaluru and Mukesh Sundaram and assigned to the assignee of the present invention, Ser. No. 249395 is a continuation-in-part application.
[0002]
(Field of the Invention)
The present invention relates to the field of telecommunications, and more particularly, to managing telephone calls to and from a call center.
[0003]
(background)
FIG. 1 illustrates connecting an end user 116 to a business call center 108 via an originating local Public Switched Telecommunication Network (PSTN) 106, a long distance network 114, and a terminating local PSTN 106. FIG. 2 is a functional diagram showing a business call center to be used. Business call centers typically combine multiple system components into a complete business solution to answer, provide, queue, and route inbound customer calls within the call center. It is configured by integration. These system components include a private branch exchange (PBX) 102, an automatic call distributor (ACD) 112, and an interactive service, in addition to a customer service application or a help desk application for a call center agent 104. An audio response (IVR) system 110 and the like are included. Many call centers also deploy a computer telephone integration (CTI) server 118 to provide intelligent call routing.
[0004]
Traditionally, multiple vendors have delivered system components and the system consolidator programmed the components to implement the business-dependent logic in bringing the components together into a solution and servicing calls. . However, in order to service the call, this conventional solution uses a long distance network 114 provided by companies such as the American Telephone & Telegraph (AT & T), Microwave Communications Incorporated (MCI), WorldCom, and Sprint. Called to a call center via This approach increased the cost of operation of the call center 108 because long-term billing accumulation began as soon as the call arrived at the call center. In addition, businesses with multiple physical locations need to maintain the programmable intelligence at all physical locations and provide the logic to service calls due to the inflexibility of long distance networks connecting locations. We needed to develop multiple applications to implement.
[0005]
FIG. 2 is a functional diagram illustrating a network-based call center that connects an end user 116 to a business call center 108 via an originating local PSTN 106, a long distance network 114, and a terminating local PSTN 106. . The network call center includes a switch 122, an ACD 112, and an IVR 110 within the long distance network 114 to provide services for answering calls, servicing calls, and queuing calls. Can be. Network call centers typically integrate voice telecommunications provided by carriers with premises-based switching, call distribution, interactive voice response, and computer-telephone integration technologies to provide such services. Do. Traditionally, network-based call centers have developed proprietary systems and software to develop and deploy call management applications that provide answering, serving, and queuing services. I was using it. In recent years, telecommunications operators have begun providing value-added call management applications as managed network services. However, such managed network services are typically provider-provided services that provide and are often inflexible and usually have incomplete functionality.
[0006]
(Summary of the Invention)
According to one embodiment of the invention, a telephone call to a first call center is directed to a second call center upon command of a user-specified application. Under the direction of the user-specified application, the call is serviced at a second call center, while the user-specified application directs the first call center to establish a connection within the center. . When a connection is established in the first call center, the user-specified application may transfer or bridge the call using the telephone connection in the first call center via the telecommunications network. Instruct the second call center.
[0007]
The present invention is illustrated by way of example, and not by way of limitation, in the accompanying figures. In the drawings, like reference numbers indicate like elements.
[0008]
(Detailed description)
Although the invention is described below with reference to various embodiments that include specific structures and methods, embodiments that include alternative structures or methods may be used without departing from the principles of the invention described herein. Can be. In general, the embodiments described below provide a call center service provider, hereafter a distributed call center system controlled by a user, answering calls at a point of presence, providing services, and waiting. Handles a virtual intelligent network (VIN) that can be queued and / or routed and reduces communication costs and operational efficiency for call centers. The call center is a single point where telephone calls are handled and handled by a team of call center agents, whether for inquiries, orders, after-sales support, or other call center activities. Contact point. These call center agents or operators may be based on a single site or multiple sites depending on the configuration of the call center and the organization to which the call center belongs. The industries and organizations where call center use has been most widespread are those that focus on customer service and high volume of decentralized customer contact. These include banking institutions, insurance companies, airlines, hotel industry, car rental organizations, and travel services industry.
[0009]
Before describing embodiments of the present invention in detail, it is helpful to discuss some of the components of VIN and other general concepts underlying the present invention. The present invention utilizes a point-of-presence (POP) call center gateway. POP call center gateways are described in detail in the aforementioned related application, which is incorporated herein by reference, and in an effort to minimize telephone charges for call center service providers. The applicability of the gateway is highlighted in that related application. The POP call center gateway is configured to answer, service, queue, and / or route calls at a local point of presence near the point of origination of the call. Accordingly, the POP call center gateway can provide initial handling of incoming calls, hold and queue calls until a live operator is available at the business call center that receives the call. it can. After the live operator is available, the POP call center gateway routes the locally queued call to the operator at the business call center. Thus, one advantage of using such a POP call center gateway is that a business call center service provider may require that the caller be actually connected to a business call center operator. This means that long-distance tolls are charged only during the time you are. Time spent on hold, in the queue, or answering automated menu questions, etc., is not added to the long haul fare. Since that part of the call is treated as a local call terminating at the POP call center gateway.
[0010]
Another essential component of the present invention is a computer server. The server runs on any one or more of the various computer hardware platforms and provides some other program, called a client, that can also run on the various computer platforms. A computer program that can be configured to provide a service. Clients and servers often communicate by passing messages over a network and using some protocol, a set of formal rules that describe how to communicate (ie, send and receive) data. Encode the client's request and / or response and the server's response and / or request. The server is always running, waiting for the client's request and / or response to arrive, or controlling some particular server, some higher level software, such as a constantly running server. Invoked by the application. Client-server communication is similar to a customer (client) sending an order (request) with a purchase order to a supplier (server) and the supplier dispatching the requested goods and invoice (response). It is. Purchase orders and invoices (eg, terms and conditions of sale specified therein) are part of the protocol used to communicate requests and responses.
[0011]
As described further below, the VIN is a computer-based language designed to enable the use of Standard Generalized Markup Language (SGML) on the World Wide Web (sometimes known as "WEB"). Some so-called eXtensible Markup Language (XML) is used. SGML is an international standard for defining descriptions of the structure and content of various types of electronic documents. In addition, VIN utilizes well-known Hypertext Transfer Protocol (HTTP) designed for the distribution of hypertext documents over the Internet, using network components (eg, XML messages) over XML messages over a virtual private network (VPN). Communication between the client and the server). Virtual Private Networks (VPNs) provide tunnels for secure, dedicated data communication within otherwise public networks
[0012]
In at least one embodiment of the present invention, the VIN is the originating call, interconnected by a user controlled virtual private network to a local call center gateway distributed to the location where the call center resides. Includes a set of POP call center gateways distributed in a point of presence close to the point. The POP gateway and the private gateway, according to embodiments of the present invention, are programmable telephone application gateways dynamically controlled by a call flow management (CFM) application and an interactive voice response (IVR) WEB application. The CFM application uses information such as time, date, holidays, overflow, percentage allocation across sites, and the set of agent groups to which calls are routed to select answering resources. The IVR application uses a pre-recorded database of voice (or synthesized voice) messages to present and / or collect digits entered by the user, interact with the office database, and provide results to the user. -It can be regarded as an application. The IVR application can also optionally use voice recognition to secure input options from the user. These applications, CFM and IVR, are hosted on external Internet data centers and / or call center premises and can be connected to the same VPN as the POP and campus gateways, such as Netscape Application Server 2.1 and NetDynamics. It can reside on a web application server such as 4.0. The CFM application and the IVR application communicate the call flow behavior and voice response of these gateways via XML messages using HTTP and virtual private networks for distributed call resource (hardware and / or software) management. Control behavior.
[0013]
The process of operating VIN can be described generally with reference to the simplified flowchart shown in FIG. In response to the inbound call being made, at step 200, the user-specified CFM and IVR applications instruct the POP gateway at or near the point of originating the call to intercept the inbound call. . Thus, the POP gateway terminates and responds to inbound calls locally, taking advantage of the economics of local interconnects that generally provide the lowest access fees. Further, the CFM issues a command (eg, using an XML page described below) to the POP call center gateway at step 204 until the operator becomes available and services the call. Provide services such as placing a call on hold or queuing, and / or playing a music or customized announcement to a caller while the call is on hold.
[0014]
In parallel, the CFM issues a command (also via an XML Page) to the local call center gateway at step 208 to the call center operator and to its automatic call distributor (ACD). You can make a proxy call. In response, the local call center gateway generates and places a proxy call to the ACD. The CFM command also in step 210 instructs the local call center gateway to monitor the progress of the proxy call in the ACD for operator availability and notify the CFM of the availability. Is also possible. When the proxy call reaches the head of the local call center queue and is about to be answered by a live call center agent, the local call center gateway alerts the CFM. Based on this real-time information about the availability of the selected operator, the CFM application issues a command to the POP call center gateway at step 212 to transfer the held call to the local call center gateway. And bridge the incoming call from the POP gateway to a proxy call in the local ACD (currently being answered by the operator). Such local queuing and just-in-time call delivery saves on long-distance communications charges that would have been incurred if a call were connected to a local call center earlier to queue. You.
[0015]
The process of selecting a local call center is generally described with reference to the flowchart shown in FIG. At step 216, the incoming call is directed to an IVR application, preferably developed as a WEB application and deployed on a WEB server. Such applications can be used to collect caller-specific information (eg, an account number that a CFM application can use to intelligently route calls to the best matching answering resource). At step 218, the CFM directs the local POP call center for the incoming call to intercept the call and provide an interactive voice response based automated service, as described above. The CFM directs the local call center gateway selected as the best answering resource at step 220 to cause the ACD to insert a proxy call. If there is no available best answer resource available to service the call and the call needs to be forwarded to the next best location, the CFM issues a command to the best answer resource at step 224 from its ACD The proxy call is dropped and, at step 228, the call center at the next best answer location is instructed to make the ACD make the proxy call. (This process can be repeated as necessary (and as resources permit) until a response resource is found that can handle the call.) The second location responds to the CFM command by: At step 230, the progress of the proxy call is monitored and the CFM is notified of the availability of the operator. If there is an available live operator servicing the call, receiving a message from the second location, the CFM in step 232 directs the POP call center gateway to route the call to the second location. Transfer. Such local queuing at the POP call center gateway saves on long distance charges that would have been incurred if the call was connected earlier to an optimal answering resource and then transferred to a second location. Is done.
[0016]
When the call is finally connected to an agent at the local call center, the VIN can take advantage of traditional Internet technologies such as IP telephony, Media Gateway Control Protocol (MGCP), Gateway protocol, and high quality. A virtual private network is provided with guaranteed quality of service for long-distance voice communications to ensure a user experience of the same. Next, the selected call center agent at the local call center provides customer service to or for the caller in response to the transferred call. Finally, when the caller or call center agent hangs up the call, the CFM directs the POP and local gateways to end the call.
[0017]
Preferably, the POP gateway and the campus gateway, and the controlling CFM and IVR application servers are, according to an embodiment of the invention, a central network operations center (NOC) connected to the same VPN as the gateway and server. 156 (see FIG. 9). Using Simple Network Management Protocol (SNMP) and network management WEB tools, NOCs can discover, configure, monitor, and manage all components within a VIN. In addition, the NOC provides a service delivery system, a user billing system, a user support system, and other service management systems that enable VIN to provide a series of end-to-end managed user interaction services. Host other operations support systems, including:
[0018]
The VIN gives the user (ie, the call center provider) not only control over the inbound operation of the call center, but also over the outbound call center operation. Guided by the CFM application and dialed using the specified long distance number as the local number using the VIN to filter out unanswered or machine answered calls and answer the call , And allow the called party to conduct interactive transactions using live operators and / or stored interactive software applications. The CFM web application can specify a set of alternate long distance numbers, command the elements of the VIN via an XML message, contact the called party, and send a predetermined voice message. The VIN sends a request to attempt such a contact to the appropriate POP gateway where the number to be dialed will be a local call. If the call is not answered, or answered by the machine, the other designated numbers are tried in order until the live personnel can get the call to reach. When the call is answered, the IVR application can authenticate the called party, send a CFM-specified voice message or announcement, and receive an acknowledgment from the called party. The IVR can also provide the called party with an option to be connected to the serving agent. If the callee selects this option, the CFM will direct the remote call center to service the proxy by requesting a proxy call in the remote call center's ACD and monitoring the progress of the proxy call. Causes a connection to be established with the agent. When a connection with the serving agent is established, the CFM directs the remote call center to bridge the proxy call to the local call center, thereby forwarding the call and placing it in a queue. Make sure there are no unnecessary long-distance charges that will be accumulated.
[0019]
Thus, in a more general view, a programmable VIN is a collection of intelligent telephone ports that can place or end calls, bridge pairs of calls, and connect callers to IVR applications. Can be considered as Telephone port programmability is implemented through the use of XMP pages, causing each of the "tags" on the page to direct the telephone port to perform a designated call management function. Such XML tags may be part of a general purpose voice response control language (VCRL) for remotely controlling the behavior of a POP call center gateway. Thus, a set of point-of-presence call center gateways, distributed at the point-of-presence close to the point of originating the call, is provided by a programmable VIN to the local voice response server at the business location where the call center resides Interconnected. A call flow manager (CFM) coordinates the creation and management of telephone calls within a VIN under the control of a call center IVR application.
[0020]
As mentioned above, VRCL provides syntax for XML Page objects that are generated at the CFM and used by the POP gateway to perform processing for the call center. The XML Page object may be a simple page of ASCII text stored in a directory on the web server or generated by a script at the server hosting the CFM. The XML Page is transmitted by the CFM in response to an HTTP request made by a client application running on a POP gateway.
[0021]
To better understand how VRCL can be used by an IVR application running in a call center to control the processing of a POP gateway for the call center, FIG. Consider the following example in connection with the flow diagram shown. When an inbound call arrives at the POP gateway, a data communication path is established between the POP gateway and the CFM. Immediately after the call is accepted, the CFM passes control to the IVR application to provide the caller with voice prompts and menu selection choices. The POP Gateway retrieves the XML Page from the IVR application, parses and executes the commands in the XML Page, and then from the location defined by the Universal Resource Locator (URL) specified in the first XML Page. Request the next XML Page. Next, the process is repeated and the POP gateway continues to acquire a new set of commands (represented by tags in the XML Page) from the IVR application. An important point to note about VRCL is that, unlike HTML, VRCL represents instructions in linear order. HTML pages are generally presented to the user all at once, whereas VRCL pages are rendered audibly and processed from top to bottom.
[0022]
The IVR application guides the POP gateway through a series of XML pages, depending on the complexity of the application. For example, a caller's intent and / or choices cannot be completely defined until a series of interlinked menus have been navigated by the caller. Ultimately, the IVR application can terminate the call or transfer the call to a live operator. In either case, the IVR application passes control back to the CFM, and then causes the CFM to instruct the POP gateway to set up the call via the PSTN or to terminate the call. The set of XML tags specified in the call flow shown in FIG. 5 can be understood in connection with the following discussion of examples of the types of tags that can be used in a VIN.
[0023]
VRCL further provides the ability to queue calls before transferring them to a live operator and the ability to integrate other WEB-enhanced telephone applications such as Click-to-Talk applications. This is made possible by the use of dedicated XML tags, which can be interpreted by the POP gateway and implement the desired commands specified therein. Thus, VRCL defines several tags or elements (similar to commands) to control the behavior of the POP server. FIG. 6 illustrates examples of the types of tags that can be included in an XML Page generated by an IVR application.
[0024]
In the following description, the term "conversation controller" refers to an endpoint in a POP server that manages interaction with an IVR application or CFM. As shown, the XML Page element is a root element per XML Page used by the CFM and / or IVR for communication with the POP gateway. The Page element can have (among other things) the following attributes: The IVR application must use the value "IVR" to identify the source of the TYPE page, while other applications may use different values (eg, the call flow manager The value "CC" can be used).
CUSTID Unique identifier for the call center.
PAGEID (optional) A character string identifying each page (can be a number).
SESSIONID Identifier for a particular session with the caller. This can be part of the query string sent by the POP gateway in the HTTP request for each page.
HREF When the end of the page is reached, the URL of the next XML Page to retrieve (child elements can pass control to another URL from anywhere in the page).
[0025]
Each XML Page represents a unit of work to be performed by the POP gateway (ie, a work order). A unit of work can consist of a single operation or a linear list of several operations. At the highest level, basic elements (eg, PLAY, TONEMAP, VOICEMAP, and EXCEPTIONMAP), composite elements (eg, MENU, FORM), and / or anchoring elements for labeling (eg, A) are included in the Page. It may be. Additionally, a RECFILE element for handling audio recordings and / or a SET element for setting user-defined variables may be provided (not shown). Sub-elements of the XML Page route are directed to call flow, caller interaction, or call control.
[0026]
Some possible children (sub-elements) of the XML Page root element directed to call flow and interaction management are PLAY, TONEMAP, VOICEMAP, EXCEPTIONMAP, MENU, FORM, A, RECFILE, and SET. The sub-elements directed to call control are: CREATE_LEG_AND_DIAL, HANGUP_AND_DESTROY_LEG, QUEUE_CALL, QUEUE_DROP, BRIDGE_CALL, UNBRIDGE_CALL, LEG_WAIT, ALERT_LEG, and END_LEGS. These sub-elements may appear multiple times in any order. CFM can utilize a larger set of more primitive call control tags that are not possible to be issued by an IVR application. This is because CFM is a VIN monitoring process.
[0027]
The PLAY element causes the IVR application to instruct the POP gateway to play an audio file, pause for a specified amount of time, play out a number or set of numbers, and the like. This element can have the following attributes:
INTERRUPTIVE (optional) YES or NO. By default, the message played is interruptible by tone input. However, the message can be made non-interruptible by using a value of NO (except in the case of MENU-see below).
PLAY has several possible child elements that can be used in any order and any number of times: VOICE, PAUSE, STRING, DATE, TIME, NUMBER, CURRENCY, ORDINAL, INDEXFILE, and DTMF.
[0028]
The VOICE element specifies an audio file to be reproduced. The audio file is. vox file or. It can be any computer readable audio file, such as a wav file. In one embodiment, the VOICE element has two attributes, one of which is mandatory (SRC) and the other (TEXT) is optional.
SRC The fully specified URL of the file to be played.
TEXT (Optional) Render what is in the SRC file as text
A VOICE is an element that has no children and is empty (i.e., the end tag can be just "/>" at the end of the attribute).
[0029]
The PAUSE element specifies a period of silence. This element can, for example, follow the VOICE tag in the PLAY element. If the parent PLAY tag is not part of a MENU or FIELD, PAUSE simply introduces silence during the specified TIME. On the other hand, if the parent PLAY tag is part of a MENU or FIELD, PAUSE acts as a timeout period during which the caller must enter at least one digit (the INPUT tag below). (See also the description of MAX_IDD (max interdigit-delay) in the description of).
[0030]
PAUSE has two attributes, TIME and UNIT.
TIME The value of the time zone during which silence is desired and caller input is desired (if part of MENU or FIELD).
UNIT (Optional) Unit in which TIME is specified (SEC or TENTHS). TENTHS means unit = 0.1SEC.
PAUSE has no children.
[0031]
The use of a STRING element with no children indicates that the IVR application wants the POP server to play out a string of letters, numbers, and / or special characters one by one. This element has two attributes, both of which are mandatory.
URL of the index file (see below) used by the audio subsystem to pronounce SRC characters.
VALUE The string of characters / digits / characters to be played out. The string can include any combination of the following symbols: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, +, <, =,%,-,>, &,. , #, ^* , ＠, etc. (ie, any ASCII character). Because of the special meaning that conventional XML parsing code gives to the symbols "<", ">", and "&", these symbols are actually "&lt;","&gt;", And "&amp;".
[0032]
As an example of how the STRING tag can be used, consider VALUE = "IBM". When played out, this string is rendered as "Ayeee Bee Emm". If VALUE = "3 + 4", the phrase to be played out is "Three Plus Four", and so on. The special index file used when playing out STRING, DATE, TIME, NUMBER, CURRENCY, and ORDINAL data is a sound for all common prompts used in playing out these types of data. Can be stored. The file may also include a header section at the beginning of the file, which is an array of offsets pointing in a clear order to the starting point of the prompts therein. The format of the index file is not critical to the invention.
[0033]
The DATE element is used to indicate that the IVR application wants the POP server to play out the date to the caller. This element has three attributes, all of which are mandatory.
SRC URL of the index file used by the audio subsystem to pronounce the date (see previous description of the STRING tag).
VALUE The value of the date to be pronounced. The value can be specified as yyyymmdd (8 digits), mmdd (4 digits), w: yymmdd (10 characters), w: mmdd (6 characters), or another user-defined format. w indicates a day of the week, 0 corresponds to Sunday, 1 corresponds to Monday, and so on. yy, mm, and dd refer to year, month, and date, respectively.
FORMAT This attribute indicates how the date should be played out. Possible values for this attribute are DDMM, MMDD, DDMMYYYY, MMDDYYYY, W: DDMM, W: MMDD, W: DDDMMYYYY, and W: MMDDYYYY. For example, DDMMYYYY means that the date should be pronounced as "day-month-year". W: MMDD means that the date should be pronounced as (for example) day-month-day.
DATE has no children.
[0034]
The TIME element is used to indicate that the IVR application wants the POP server to play out the time to the caller. This element has three attributes, all of which are mandatory.
SRC URL of the index file used by the audio subsystem to play out the time (see previous description of the STRING tag).
VALUE The time value to be played out. This value can be specified as hhmm (four digits) or hhmmss (six digits), or another user-specified format (eg, a 24-hour clock).
FORMAT Describes how the time should be played out. Possible values are 12_HOUR or 24_HOUR.
TIME has no children.
[0035]
The NUMBER element may indicate that the IVR application wants the POP server to play out a number to the caller. This element has two attributes, both of which are mandatory.
URL of the index file used by the audio subsystem to pronounce the SRC number (see previous description of the STRING tag).
VALUE The value of the number to be played out.
NUMBER has no children.
[0036]
The CURRENCY element is used to indicate that the IVR application wants the POP server to play out the monetary value to the caller. This element has three attributes, all of which are mandatory.
URL of the index file used by the audio subsystem to pronounce the SRC currency (see previous description of the STRING tag).
VALUE The value of the currency to be pronounced. This value may or may not have a decimal point.
COUNTRY 3 characters (for example, ISO-4217 compliant)
CURRENCY has no children.
[0037]
The ORDINAL element is used to indicate that the IVR application wants the POP server to play out an ordinal number (eg, “first”, “third”, etc.) to the caller. This element has two attributes.
SRC URL of the index file used by the audio subsystem to pronounce ordinal numbers.
VALUE The ordinal value to be pronounced. Allowed values are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22 , 23, 24, 25, 26, 27, 28, 29, 30, 31, 40, 50, 60, 70, 80, 90, 100, 1000, 1,000,000, 100,000,000, etc.
ORDINAL has no children.
[0038]
If the index file format described above is inappropriate for playing the desired prompt (e.g., the call center is using some additional prompts, or the call center index file is a INDEXFILE elements can be used by the IVR application to reproduce dates, currencies, numbers, etc.) In such a case, the IVR application should not use tags such as DATE, CURRENCY, etc., as described above, but use the INDEXFILE tag to specify the offset and length in the file and play out the desired prompt. You have to make sure. INDEXFILE has up to four attributes.
URL of the call center index file used by the voice subsystem to play out SRC prompts.
OFFSETS A comma-separated list of offsets indicating the byte offsets relative to the start of the prompt to be played in the file. For example, OFFSETS assumes that the offsets for the start of the M, S, F, and T prompts are 0031545, 0038040, 0022060, and 0041122, respectively, for the phrase "MSFT", "0031545, 0038040, 0022060". , 0041122 ".
LENGTH A comma-separated list of lengths of the prompts to be played in the file. There must be a one-to-one correspondence between OFFSETS and LENGTHS.
Rendering of what is in the TEXT prompt as optional text.
INDEXFILE has no children.
[0039]
DTMF tags must only be used as child tags under PLAY. The purpose of this tag is to allow the IVR application to send in-band DTMF tones to the ACD / PBX on an already established call. This allows the IVR application to send account numbers etc. and bring the ADC / CTI application to a stage where the caller can talk to the live operator without having to re-enter / repeat the information Can be. A DTMF tag has only one attribute.
VALUE The tone to be transmitted (eg, "2690", "#, 3396"). You can use a comma in the value to indicate a pause.
[0040]
The PLAY DTMF combination should not be used in the MENU so that there is no inter-tone interference in the MENU. DTMF has no children.
[0041]
The TONEMAP element allows the IVR application to specify a mapping between the tone keys entered by the caller and the URL of the XML page to visit in response to user input. TONEMAP can be present at the highest level in an XML Page, or can be used as a subelement of a MENU. In the first case (when specified outside the MENU), the TONEMAP has a global effect in the sense that it is stored across pages. In the second case (when specified as part of the MENU), the range is local. Within the MENU, the local TONEMAP takes precedence over the global TONEMAP for conflicting TONE between the two maps (see below). Regarding the TONE in the global TONEMAP that is completely consistent with the local TONEMAP, such a TONE has the same effect as in the global case, even in the MENU. After exiting the MENU, the TONEMAP returns to the global TONEMAP.
[0042]
The TONEMAP can have a TONE child element, which can be used to specify the mapping between one tone key and the URL from which the next page will be retrieved. TONE has the following attributes. The first attribute (TONEID) is mandatory. Also, either the second attribute or the third attribute must be input.
TONEID 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ^* , #, OTHER. OTHER includes all remaining keys not specified in the TONEMAP. (Required)
HREF URL to retrieve the next page. This attribute can also point to the label in the current Page (see description of A element below). (Optional instead of REPEAT)
The REPEAT value must be MENU. This attribute allows control to return to the PLAY at the start of the MENU if the associated tone key is entered. (Optional instead of HREF)
TONE has no children.
[0043]
The VOICEMAP element allows the IVR application to specify a mapping between certain voice input received from the caller and the URL of the XML page to visit in response to this input. The VOICEMAP can be at the highest level in the XML Page or appear as a subelement of the MENU. In the first case (when specified outside the MENU), the VOICEMAP has a global effect in that it is stored across pages (eg, when the caller says "operator"). At any time, an XML page at a URL is accessed and control is passed to the operator.) In the second case (when specified as part of the MENU), the range is local. Within the MENU, the local VOICEMAP takes precedence over the global VOICEMAP for a PHRASE (see below) that conflicts between the two maps. With respect to PHRASE in the global VOICEMAP that is completely consistent with the local VOICEMAP, such a TONE has the same effect as in the global case, even in the MENU. After exiting the MENU, the VOICEMAP returns to the global VOICEMAP.
[0044]
A VOICEMAP may have a PHRASE child element that specifies a mapping between one voice command (phrase) and a URL that fetches the next XML Page in response to this command.
SRC speech recognition file or speech grammar file
HREF URL to retrieve the next page. This attribute can also point to a label in the page (see description of A element below).
PHRASE has no children.
[0045]
The EXCEPT MAP element can be used to specify a mapping between certain exceptions (eg, timeouts) and the URL of the XML Page to retrieve if there is such an event. Like TONEMAP, the range of EXCEPTIONMAP may be global (if it appears at the highest level as a subelement of XML Page) or local (as a subelement of FIELD or MENU). Within a FIELD or MENU, the local EXCEPTION MAP takes precedence over the global EXCEPTION MAP for conflicting EXCEPTION MAP between the two maps (see below). Regarding the EXCEPTION in the global EXPRESSION MAP which is completely compatible with the local EXPRESSION MAP, even in the FIELD or MENU, it has the same effect as in the global case. After exiting the FIELD or MENU, the EXCEPTION MAP returns to the global EXCEPTION MAP.
[0046]
The EXCEPTIONMAP can have an EXCEPTION child element, which specifies the mapping between the exception and the URL from which to retrieve the corresponding page if such an exception is encountered. EXCEPTION has three possible attributes, EVENT, which is mandatory, HREF, which is mandatory for global EXPRESSIONMAP, and REPEAT, which can be used in place of HREF for EXCEPTIONMAP in MENU or FIELD.
EVENT Possible values:
Applicable in TOOFEWDIGITS-FIELD. The number of digits entered by the caller is less than expected.
TIMEOUT—The caller did not enter any input within the period specified by the previous PAUSE tag.
CALLERUP-Caller hangs unexpectedly
OTHER-Catchall for unexpected exceptions
HREF URL to fetch the next page if the exception specified by the encountered EVENT was generated. This attribute can also point to a label in the current page (see description of the A element below).
The REPEAT value can be “MENU” or “FIELD” for the EXCEPTION MAP specified in MENU or FIELD. This allows control to return to PLAY at the start of MENU / FIELD when EXCEPTION occurs.
[0047]
EXCEPTION can occur at any time and can be a completely asynchronous event (eg, the caller suddenly hangs up). Therefore, it is useful to specify a default global EXCEPTIONMAP in one of the first XML Pages sent by the IVR application. EXCEPTION has no children.
[0048]
The MENU element provides the IVR application with the ability to have the POP server play the message and then collect the caller's choices (from the selection menu) and retrieve a new XML Page based on such choices. The caller can make his own selection by entering a tone key or by saying a word or phrase (if speech recognition is supported). The MENU has one attribute.
MAXREPEATS (Optional) The maximum number of times control can return to the start of the MENU. To prevent an infinite loop, control goes to the HREF specified in the XML Page tag specified at the top of the page if a REPEAT exception is encountered more than MAXREPEATS times in a row. Note that MAXREPEATS also applies when control returns to the FIELD tag by using the A (anchor) label.
[0049]
The MENU can have the following children: PLAY, TONEMAP, VOICEMAP, and EXCEPTIONMAP. Either or both TONEMAP and VOICEMAP must be present. When used within a MENU, the PLAY must include a PAUSE sub-element to specify a timeout within which the caller must enter a tone or provide voice input. If the caller has not entered any tone / voice input within the timeout period, control can go to the HREF specified in TIMEOUT EXCEPTION. If TIMEOUT EXCEPTION is not specified in the local EXCEPTIONMAP, the global EXCEPTIONMAP is examined. If TIMEOUT EXCEPTION is not present, even at the global level, the next page specified in the HREF attribute of the current XML Page is retrieved. This same hierarchy of handling exceptions can be used for all exceptions. Control can also be passed to the anchor / label on the current XML Page by specifying the #label in the HREF attribute of the XML Page using the A sub-element (see below).
[0050]
The FORM element is used to instruct the POP server to collect information about the number of FIELDs (e.g., multi-key input or voice recording), and then use this information as a NAME, VALUE pair in the HREF specified in the FORM. Can be sent back.
[0051]
The FORM can have the following attributes (only HREF is mandatory):
HREF The URL to which the information collected from the caller is sent. This URL is typically a binary program or Perl, Java or ASP script.
METHOD (optional) GET or POST. Specifies whether the data is sent to the URL as a query string or as standard input.
SRC (Optional) The URL of a file (eg, .vox file) to play while the data submitted in the FORM is being processed by the IVR application. The file usually contains a message such as "Please wait while processing your input". If the SRC attribute is not included, the caller listens to silence after processing the FORM data while the POP server is waiting for the IVR application to send the next XML Page.
SUBMIT_PARTIAL (optional) This attribute indicates that if the caller hangs up after filling some or all of the fields and does not stay online to interact with the IVR application, the FORM will be submitted to the IVR application. Specifies whether or not it should be. Possible values are:
PARTIAL_OK: send values for any filled fields
COMPLETE_ONLY: send a value only if all fields are filled
LAST_FIELD_HUP: All fields are filled and the caller is still interacting with the IVR, or the caller is entering data (or recording voice) for the last field Send value if hung
POSTHREF (optional-only for audio fields). This attribute is the URL of the application that receives the audio recording file. The audio file containing the message recorded by the caller is POSTed by the POP server at a later point in time as determined by the network manager. The manager (which can be a software application) ensures that not too much available network bandwidth is consumed when transporting audio recording files. The POSTHREF URL contains the following in the query string:
? SESSIONID = {sessionid} &
FILEDNAME = {fieldname} & RESULT = {status}
[0052]
The FORM allows one or more FIELDS to enable a POP server to collect information (eg, multi-key input or audio recording) for a single named field according to certain rules specified in the INPUT sub-element. It is possible to have children. FIELD has the following attributes.
HREF (only for VOICE). A URL where the content of the audio file is posted after recording of the audio file is completed. If HREF is not specified, the network manager POSTs the file to the specified POSTHREF in FROM.
MAXREPEATS (Optional) The maximum number of times control can return to the start of the FIELD. To prevent an infinite loop, control goes to the HREF specified in the XML Page tag specified at the top of the page if a REPEAT exception is encountered more than MAXREPEATS times in a row. Note that MAXREPEATS also applies when control returns to the FIELD tag by using the A (anchor) label.
A FIELD must always consist of a triplet consisting of the following sub-elements: PLAY, INPUT, and EXCEPTIONMAP.
[0053]
The INPUT element specifies rules for the telephone interface at the POP server to collect input for FIELD. This element can have the following attributes:
NAME The name of the variable where the caller input is collected. For a VOICE input, the value of NAME (in NAME, the VALUE pair is sent back by FORM) is the FILENAME returned by the application in the RECFILE tag, or the recording file stored locally on the POP server (See also the description of the HREF attribute for the FIELD tag). If POSTHREF is specified in the FORM, the value of NAME (in NAME, the VALUE pair is sent back by FORM) is the name of the recording file stored locally on the POP server.
TYPE (Optional) Tones or VOICE or EITHER indicating the type of input expected.
MINDIGITS (optional) The minimum number of digits required in the field (not valid for speech).
MAXDIGITS (optional) The maximum number of digits that can be entered for this field (not valid for audio). If the ACCEPT key is specified, add 1 to it.
ACCEPT (Optional) Tone key to indicate end of user input MAX_IDD (Optional) Maximum interdigit delay in seconds after which output of user input is implied
MAXSILENCE (optional) Longest silence (in seconds) before recording user input while recording audio input
MAXRECLEN (Optional) The maximum length of a message, in seconds, that can be recorded while recording audio input.
VOICEFILE_FORMAT (Optional) Desired format and sampling rate for the recording file.
INPUT has no children.
[0054]
If POSTHREF is specified in a FORM tag, the IVR application first receives an HTTP GET request with a NAME, VALUE pair for the different fields specified in the INPUT NAME attribute. The value is the name of a recording file stored locally on the POP server. If necessary, the IVR application can play the contents of the recording file to the caller. Later, the IVR application receives a plurality of HTTP POST requests with the binary data of the file recorded as content.
[0055]
The RECFILE tag can be used by an IVR application in response to a POST request containing data for a VOICE field entry. This tag has the following attributes.
The name of the file where the FILENAME POSTed audio data was stored by the IVR application server.
RECFILE has no children.
[0056]
The "A" (anchor) element can be provided as a labeling mechanism in the XML Page. The URL can specify a target in the current XML page or in a different XML page by using #name (as in HTML). This element provides the ability to instruct the POP server to start parsing and executing the XML Page at a labeled point in the page, rather than at the start of the page. This element can also be used as a mechanism to jump to a point in the current XML Page. A has one required attribute and no children.
NAME The label name by which this anchor is referenced by the URL
[0057]
The SET element allows the IVR application to set the value of a user-definable variable for later replacement by the POP server. This element allows the IVR application to specify the association between a particular value and a particular variable name so that when the IVR application later uses the variable name in the same XML page or another XML Page, A convenient mechanism that allows the server to replace variable names with values. SET has two mandatory attributes, no children.
VARNAME variable name
The value assigned to the VALUE variable
[0058]
Thus, SET provides a stateless IVR application with a powerful mechanism to maintain state and use session variables for any WEB server environment. The IVR application can use the SET tag to define and set the value of a session variable (a variable that persists for the duration of the current session / call). The value of the session variable can be retrieved later by the application by including the variable in the query string of the application URL that needs to use the value of the variable.
[0059]
Described below are call control oriented tags that an IVR application can issue to a POP server. A CREATE_LEG_AND_DIAL element can be sent by the IVR application to make an outbound call. The attributes of CREATE_LEG_AND_DIAL are as follows.
Telephone number that TELNUM telephone server needs to call
IVURL The URL from which the outbound call is made and the conversation controller of the new leg must retrieve its first XML Page after the call has been answered. This attribute can be used by the IVR application to play audio messages or to execute other VRCL commands. This attribute can also implement the value of LEG_WAIT, in which case the new conversation controller simply enters an interruptible wait state and the person answering the phone with the called number will see the interruption Listen to silence until you bridge the call. The IVURL is not used when the BRIDGE attribute is set to YES.
ANI (optional) ANI BRIDGE that the phone manager should send on outgoing calls (optional) YES or NO. If yes, a new call is dialed and as soon as the new call is answered, the new call is bridged with the call on the current LEG.
[0060]
The TELNUM attribute can include a comma in its value. Commas have two meanings within TELNUM. The first comma (from the left) indicates that the digits to the left of the first comma are used to dial out to establish a call, while the digits to the right of the first comma are used to establish a call. Means to be transmitted as an in-band DTMF tone. A comma in the number to the right of the first comma means that a pause should be inserted for each comma in the DTMF tone sequence. For example, TELNUM = “12159090 ,,, ^** , 90061234 # "dials 12159090 to establish a call, pauses, ^** Send the tone, pause, and instruct the telephone server to send the 90061234 # tone. If better control is needed to ensure that no tones are transmitted after the call has been answered, the created legs are sent to the IVRURL and these tags are sent back by the IVRURL The PLAY DTMF tag must be used by using it in the XML Page. In that case, the BRIDGE = NO option should be used. The use of commas in the TELNUM field provides a convenient mechanism for transmitting some in-band DTMF tones, combining dial-out with a fixed pause, which is not as common as a DTMF tag. No control is provided.
[0061]
CREATE_LEG_AND_DIAL has no children. Typically, the CREATE_LEG_AND_DIAL tag is followed by a LEG_WAIT tag (or PLAY followed by LEG_WAIT) to wait for another leg to synchronize with this leg.
[0062]
Upon receiving this tag, the telephone server sends a CREATE_LEG_AND_DIAL_REQ NextAction request to the CFM. The CFM reserves an outbound port on the appropriate phone server (based on TELNUM), creates a new conversation controller on the phone server, and then places the DIAL_CALL XML tag and (optionally) the BRIDGE_CALL tag on the new conversation server. Send to controller to make outbound call and bridge that call to current call. If there is an error, the global EXCEPTION MAP is examined and a URL corresponding to CREATE_LEG_ERROR, DIAL_ERROR, or BRIDGE_ERROR is contacted, depending on the type of error.
[0063]
The HANG_UP_AND_DESTROY_LEG element is used by the IVR application to notify the POP server that the call on the specified leg should be terminated and that the conversation controller (LEG) that received this tag should be discarded. The attributes of this element are as follows:
REASON (optional) NORMAL or ERROR or CALLERUP.
This element has no sub-elements.
[0064]
The QUEUE_CALL tag is sent by the IVR application and can put the call on hold. This tag has the following attributes.
AGENTGRP Identifies the agent group for which the call should be queued (eg, SALES).
STATUS_INT_TIME (optional) This attribute is the interval at which the IVR application should be notified about the status of the queued call.
STATUS_INT_URL (optional) This attribute is the URL where the IVR should be notified about the status of the call on hold after receiving a CFC interrupt giving ICR / ACD status. (The QUEUE_ERROR exception in the global EXCEPTIONMAP is checked).
ACD_TELNUM (optional) This attribute is the outbound telephone number that needs to be dialed by the telephone server to queue the call on the ACD.
ANI (optional) This attribute is the ANI that the IVR application wants the POP server to insert into outbound calls made to the ACD or ICR. This can be a telephone number or the string {ANI}.
USR_PARAMS (Optional) Information entered by the caller into the IVR system before requesting a transfer to the operator. This field contains sub-parameters and values separated by colons (":"), with different parameter-value pairs separated by commas. For example, PARM 1:25, PARAM2: busy tone, PARAM3: 411. The names and values of the sub-parameters are translated by the ACD adapter for interpretation by the ACD.
AGENT_URL (optional) This attribute is the URL from which the LEG of the telephone server having outbound calls to the ACD should get its XML Page after the AGENT is connected. This can be used to flush any caller related information to the agent's phone before the call is bridged to the caller's call.
QUEUE_CALL can optionally have EXCEPTIONMAP as a child.
[0065]
A QUEUE_DROP tag is sent by the IVR application when the caller and / or the application determines that the call is not worth holding and that the call should be dropped from the ACD queue. This tag has no attributes, but QUEUE_DROP can optionally have EXCEPTIONMAP as a child.
[0066]
Since there can be only one queue for a conversation, the identity of the QUEUE to be dropped is implicitly indicated. After receiving the tag, the telephone server sends a QUEUE_DROP_REQ to the CFM.
[0067]
A BRIDGE_CALL tag is sent by the IVR application to bridge the current call (the call on the current leg) with another call on the same POP server or a call on a different gateway on a different POP gateway. BRIDGE_CALL has one mandatory attribute.
LEG_ID Identification of the other leg that is bridged with the call on the current leg. The value ALL bridges the call on the current leg with all other calls associated with the various legs of this session.
BRIDGE_CALL can optionally have EXCEPTIONMAP as a child.
[0068]
After the two calls are bridged, all bridged calls enter the LEG_WAIT state. If there is an error in bridging the call, a BRIDGE_ERROR exception is generated and the next XML Page is retrieved from the HREF specified in the exception.
[0069]
An XML Page with an UNBRIDGE_CALL tag is sent by the IVR application to unbridge between the various legs of the call. The attributes of UNBRIDGE_CALL are as follows.
LEG_ID (Required) Used to identify the other leg to be unbridged. A value of ALL de-bridges the call on the current leg and all other calls bridged to the current call.
OTHER_LEG_URL (optional) The URL from which the next XML page should be fetched after the other leg is unbridged. If this attribute is omitted, the other legs are kept in the LEG_WAIT state and an ALERT_LEG tag is needed to wake up those legs.
One of the legs is the leg that implicitly receives this UNBRIDGE_CALL tag.
[0070]
UNBRIDGE_CALL can optionally have EXCEPTIONMAP as a child. After the call is de-bridged, the POP server executes the next tag following the UNBRIDGE_CALL tag, or (if there is no next tag) specified in the XML Page root element tag at the top of the page. Take out the next XML Page from the HREF. If there is an error in de-bridging the call, a UNBRIDGE_ERROR exception is generated and the next XML Page is fetched from the HREF specified in the exception.
[0071]
An XML page with a LEG_WAIT tag is sent by the IVR application to put the conversation controller that receives this tag on standby. The conversation controller shall do nothing except wait for an event from the phone manager (eg, caller hang-up), or an interrupt from the CFM, or an ALERT_LEG tag from the IVR application. LEG_WAIT has no attributes and no children.
[0072]
The ALERT_LEG tag is used by the IVR to interrupt the conversation controller thread in the LEG_WAIT state and instruct this thread to send an HTTP GET request to the URL specified as an attribute. The attributes of ALERT_LEG are as follows.
LEG_ID The identifier of the other leg to be alerted. The leg receiving the alert is typically in the LEG_WAIT state. If the value ALL is used, all other legs of this session will be alerted.
IVURL The URL from which the next XML Page will be retrieved for the other leg after receiving the alert.
ALERT_LEG has no children. This tag can be used, for example, to alert the other leg after unlinking the call and direct that leg to the specified URL.
[0073]
END_SESSION can be used by the IVR application to discard all LEGs in the current session and hang up all relevant calls. This is translated into an END_SESSION_REQ NextAction request sent to the CFM by the telephone server. Upon receiving such a request, the CFM sends a HANGUP_CALL tag and a DESTROY_LEG tag to all conversation controller threads associated with the session.
[0074]
Some examples of the use of tags described above may be useful at this point. In the first example, Example 1, an XML Page is presented for playing out the welcome message and setting the global TONEMAP and global EXCEPTIONMAP. First, the page type and customer identifier are specified. Note that the call center server URL of "customer.com" is used as the address where the various pages are stored.
[Example 1]
[A]

[0075]
Next, a global TONEMAP is defined. With TONEMAP, the caller can press 0 at any time to reach the operator, or ^* You can press a key to go directly to the login menu. Also, if the caller presses an invalid key, control is passed to another XML Page located at the designated HREF that handles such cases. This applies to all subsequent pages unless overridden by the new TONEMAP.

[0076]
Next, a global EXCEPTIONMAP can be defined. EXCEPTIONMAP raises an exception whenever a caller fails to press a key within a specified timeout period when prompted to enter a FIELD value or to make a selection from the MENU. So that At this time, control is passed to the specified timeout exception handler (timeout.asp? SESSIONID = 3). An exception is also generated if the caller suddenly hangs up. The HREF attribute in each EXCEPTION specifies which XML Page to retrieve next if such an exception occurs. The global execution map applies to all subsequent pages unless overridden.

[0077]
Next, a command to play the greeting message can be issued. There should be instructions in the message that should not be interrupted by the caller, and thus ignore any keys that the caller might press while the message is playing.

When the end of the page is reached, the next XML Page specified at the start of the first Page is retrieved (initial.asp).
[0078]
The second example, Example 2, announces a set of choices and provides an XML Page to accept a single tone input from the caller.

[0079]
With the global TONEMAP specified on the previous Page (from Example 1), the local TONEMAP for this Page is "0", " ^* , "2" are all valid responses. After exiting the MENU, the TONEMAP specified in the MENU is no longer applicable and "0" and " ^* Only "will be accepted as a valid tone. Any global maps that need to be processed in the FORM or MENU in the XML Page (EXCEPTIONMAP and TONEMAP) must be located above the FROM or MENU. Execution of tags in an XML page is of a nature that is performed sequentially. You cannot expect a map defined at the end of a Page to affect the tags executed in that Page. If no tone is entered by the caller within the timeout period specified in the PLAY PAUSE sub-element in the above MENU, a TIMEOUT exception is generated and control is passed to the corresponding HREF (NAME = (A label with “label 1”). If an invalid key is entered, TONEID = OTEHR applies and control also transfers to label 1. The same effect can be achieved with TMEOUT EXCEPTION, using REPEAT = "MENU" instead of HREF = # label1.
[0080]
In the following example 3, an XML Page for accepting a set of input fields (social security number and password) is presented. The FORM element allows the caller to enter multiple FIELDs before the data is sent to the call center. For example, below, sent after FORM data for both ssnumFIELD and passwFIELD has been collected (when the end tag </ FORM> appears).

[0081]
Any input entered by the caller for the various fields in the FORM is sent as a query string (URL followed by? And a NAME, VALUE pair) to the URL specified by the HREF attribute in the FORM. You. This query string is sent when the end tag </ FORM> appears. The MAX_IDD = "2" attribute in INPUT indicates that if no key is pressed for 2 seconds after the last key is pressed, the caller inputs the input value as if the ACCEPT key was pressed. Is considered to be finished. (IDD is an abbreviation for Inter-digit-delay). The distinction between TIMEOUT events and MAX_IDD is rather subtle. After the audio file has stopped playing, if even the first digit is not entered within the period specified by the TIME attribute of PAUSE, an EXCEPTION with EVENT = TIMEOUT occurs. However, if one or more digits are entered within TIME seconds, and then no digits are entered for MAX_IDD seconds, the field entry is considered complete. MAXDIGITS for the password field is specified as 8, although the maximum password length is 7. This is to support the # key which is an ACCETP character.
[0082]
In Example 4 below, an XML Page is provided for playing a caller's account record (eg, account balance).

[0083]
In the next example 5, an XML Page is provided for playing the goodbye message and returning control to the CFM to end this call.

[0084]
Example 6 below provides an XML Page to instruct the CFM to transfer the call to the operator.

[0085]
In addition to the interaction between the IVR application and the POP gateway, there is also interaction between the CFM and the IVR application. As mentioned above, the CFM is a software component that runs on a server in the VIN and facilitates communication between the call center IVR application and the POP gateway server. No direct interaction between the CFM and the IVR application is required (and it does not matter whether they reside on the same computer platform or on different platforms). Alternatively, these applications can communicate directly with the POP server. When control needs to be passed from the CFM to the IVR application, the CFM sends an XML Page to the POP server where the next HREF points to the URL of the IVR application. Similarly, when the IVR application needs to send control back to the CFM, it directs the POP server to request the next XML Page from the URL associated with the CFM. Any parameters that need to be passed are sent as name / value pairs in the query string after the URL name in the HTTP request. This is explained in more detail with the help of the following specific example.
[0086]
Consider the situation where an incoming call has just been received at a POP server. With the help of a central lookup database, the POP server knows the customer's (ie, call center provider) CFM URL corresponding to the called number. Next, the POP server sends an HTTP request to the following URL.

In this example, <call-mgr-url> is the URL of the call flow manager obtained from the lookup server (and also does not contain the query string), and <did> is the incoming call for the incoming call <Ani> is the number of the caller for the incoming call, and CC. NEXTATION = PROCESS_INCALL indicates that the next processing required for CFM is to handle a new incoming call.
[0087]
In response, the CFM can return an XML Page to the POP server indicating whether the call should be accepted or rejected (depending on the availability of certain resources). If the call is accepted, the URL of the customer's IVR application is included in the XML Page with the SESSION ID (ACCEPT_CALL), and the SESSION ID is included in all future communications between the POP server and the customer's IVR application. The POP server's first HTTP request for the customer's IVR application will have the following format:

In this example, <ivr-url> is the URL of the IVR application sent by the CFM to the POP server in the ACCEPT_CALL page, and <sessionid> is the SESSIONID sent to the POP server by the CFM in the ACCEPT_CALL page. , <Did> is the called number for the incoming call, and <ani> is the number of the calling party in the incoming call.
[0088]
From this point on, the IVR application takes control and the POP server determines which prompts and selections with the help of XML Pages with the appropriate tags (such as the XML Pages provided in Examples 1-6 above). Must be presented to the caller. The SESSIONID is included as part of the query string for each HTTP request from the POP server and as an attribute in the XML Page tag in each XML Page sent by the IVR application. The DID and ANI need not be included in the query string of any HTTP request from the POP server except for the initial HTTP request.
[0089]
When the IVR application is ready to end control or return control to the CFM to make an outbound call, it can send an HREF with the following values to the POP server.

[0090]
The only NextAction requests that need to be transmitted to the CFM are NEW_SESSION_REQ and END_CALL. NEW_SESSION_REQ is an interrupt sent by a web application (eg, Click-to-talk) that prompts the CFM to start a new session. The parameters for this request are as follows:
IVURL: URL to be part of the next CREATE_LEG_REQ interrupt to the POP server. This parameter tells the POP server where to get the next XML Page after a new conversation is started.
TELNUM helps CFM identify the POP server (and gateway) where the new conversation should be initiated.
NUM_LINES specifies the number of outbound telephone lines that need to be reserved for this session. For Click-to-talk applications, this number is always two. The second telephone number required by the Click-to-talk application must be carried in the customer application's IVURL.
APP_NAME identifies the application for which this processing is desired. This parameter helps the CFM front end identify the CFM process to which this request must be issued.
FAILURE_URL specifies the URL that should be used to signal a component of the VIN that a failure has occurred in performing a NEW_SESSION_REQ.
[0091]
The response to the NEW_SESSION_REQ interrupt must be an XML Page containing a single RESPONSE tag whose RESULT attribute indicates success or failure. The HREF attribute in the XML Page header must be empty ("").
[0092]
Respond to error situations (e.g., when the IVR server goes down) that cannot be handled by a normal hangup or otherwise by the IVR application / caller and have no options other than terminating the call Thus, the END_CALL query string can be sent by the POP server to the CFM. If the IVR application wants to end the call, the last XML Page will have an HREF pointing to the CFM and will have the following query string: CC. NEXTATION = END_CALL &amp; SESSIONID = {sessionid} &amp; REASON = NORMAL. If the caller hangs up in the middle of an IVR session, the POP server will first send an HTTP request with the following query string to CFM: CC. NEXTATION = END_CALL plus other name / value pairs. The POP server also sends an HTTP request to the IVR application at the URL specified as part of the CALLERUP Global EXCEPTION. If the IVR server goes down for any reason, depending on the value set in the IVR_ERROR exception of the CC_EXCEPTIONMAP (the POP server will, by that time, have {last-error}, {error-url}, and {last -Error-string @ must already be set), the POP server can send the following query string to the CFC: CC. NEXTATION = END_CALL &amp; REASON = IVR_ERROR &amp; SESSIONID = {sessionid} &amp; ERROR = {last-error} &amp; URL = {last-error-url} &amp; DESCRIPration = @-rust-
[0093]
As with communication between the POP server and the IVR application, the basic method of communication between the POP server and the CFM is through the use of XML Pages. This communication is initiated as soon as the incoming call appears on the POP server, and via the DID / CallMgrURL translation using the Network Operations Center (NOC) (see FIG. 9), the POP server retrieves the CFM URL. know. The POP server sends information about the request in the form of a NAME, VALUE pair in the query string of the XML Page request. The CFM returns a response in the form of an XML Page with the appropriate elements. The following elements / tags are available to CFM for such call control responses. Further, the above-mentioned LEG_WAIT tag can be used for communication between the POP server and the CFM. Similarly, BRIDGE_CALL and UNBRIDGE_CALL tags are used. The only difference for the CFM is that it cannot use the ALL's LEG_ID. The CFM must explicitly specify only one LEG_ID to bridge and / or unbridge the call.
[0094]
The “XML Page” element is the root element for all XML Pages used by CFM for communicating with the POP server. This element can have the following attributes:
It can take the value TYPE CC or IVR. CFM uses the value CC (call control).
CUSTID Identify the customer
PAGEID (optional) identifies the page itself
VERSION Used by the customer to identify the version number of the customer's application
SESSIONID Identifier to identify a specific session with the caller
Each XML Page represents a response to a call control request by the POP server. The possible children (sub-elements) of the XML Page are ACCEPT_CALL, LEG_WAIT, RESPONSE, DIAL_CALL, BRIDGE_CALL, UNBRIDGE_CALL, HANGUP_CALL, DESTROI_LEG, REJECT_CALL, ENJLEXPAL, CALL, XEL, MALE, CALL, ENJL, CALL, ENJL, CALL, ENCALL
[0095]
The ACCEPT_CALL element is used by the CFM to alert the POP server that resources are available for incoming telephone calls and that the POP server should accept the call.
RINGS (Optional) An attribute that controls the number of rings in ringback before answering the call. The required ring is ringed until the first XML Page from the IVR application is received.
The UNIT (optional) value can be SEC or NUMBER indicating the unit of RINGS.
After the HREF POP server answers the call, the URL of the IVR application from which the next XML Page should be retrieved by the POP server.
[0096]
This XML Page tag is transmitted in response to a request from the POP server when an incoming call comes. The request for the URL of this page must include the DID and, if available, the ANI of the incoming call as part of the query string. The ACCEPT_CALL response page returns SESSIONID, a unique identifier for the session created by the CFM. All future requests from the POP server for CFM (and IVR applications) must carry SESSIONID, not DID and ANI. ACCEPT_CALL has no sub-elements as children.
[0097]
The XML Page containing the ACCEPT element (the first page from the CFM) must also include a CC_EXCEPTIONMAP with an IVR_ERROR_EXCEPTION to handle irrecoverable IVR errors. CC_EXCEPTIONMAP is a global map and must be placed before any ACCEPT tags.
[0098]
A RESPONSE tag is sent by the CFM or POP server in response to the interrupt request (see above). This tag indicates whether the process requested by the interrupt was successful or unsuccessful, and if unsuccessful, indicates the reason for the failure. RESPONSE has two mandatory attributes and has no children.
RESULT SUCCESS or FAILURE.
REASON (optional) For FAILURE, possible values are UNKNOWN_REQ, INVALID_PARAMETERS, NO_RESOURCES.
[0099]
In response to requests by the IVR application and other applications, an XML Page with a DIAL_CALL tag is transmitted by the CFM to make an outbound call. The attributes of DIAL_CALL are as follows.
The telephone number that the TELNUM POP server must call.
ANI (Optional) The ANI that the phone manager should send in outgoing calls. This value is specified by the application in the QUEUE_CALL tag.
If the outbound call fails, the POP server immediately notifies the CFM by sending a request to the HREF specified in the EVENT = DIAL_ERROR exception. If the outbound call is successful, the POP server will work on the next tag (if any) or on the HREF (if DIAL_CALL is the last tag on the page) in the XML Page tag at the top of the Page. DIAL_CALL has one child element -CC_EXCEPTIONMAP. Also, the global CC_EXCEPTIONMAP must be specified in the CALLERHUP event. Also, {end-call-url} must be configured for the conversation controller by this point.
[0100]
The HANGUP_CALL element is used by the CFM to inform the POP server that the call on the leg receiving this tag must be terminated. The attributes of this element are as follows:
REASON (optional) NORMAL or ERROR or CALLERUP.
The HANGUP_CALL tag differs from the END_CALL tag in that it does not discard the conversation controller associated with the dropped call. The HANGUP_CALL tag may be followed by a DESTROY_LEG tag, or another DIAL_CALL to make another outbound call if no further calls are made on the associated conversation controller. . HANGUP_CALL has no sub-elements.
[0101]
The DESTROY_LEG element is used by the CFM to notify the POP server that the conversation controller should be terminated. The attributes of this element are as follows:
REASON (optional) NORMAL or ERROR or CALLERUP.
DESTROY_LEG has no sub-elements. If the DESTROY_LEG is preceded by a HANGUP_CALL tag, but there are active calls on the leg, the conversation controller discards this leg if it actually receives the DESTROY_LEG without the preceding HANGUP_CALL. You must do any necessary cleanup needed to do so.
[0102]
The REJECT_CALL element is used by the CFM to notify the POP server that resources have not been allocated for the call and that the POP server should reject incoming calls by signaling a busy signal. The attributes of this element are as follows:
REASON (optional). NOPORTS or OTEHR.
REJECT_CALL has no sub-elements at all.
[0103]
The END_CALL element can be used by the CFM to notify the POP server that the call should be terminated. An XML Page with this tag is sent in response to a request for CFM from the POP server ending the call. The POP server sends the CC. Advise the CFM as such using NEXTATION = END_CALL. The attributes of this element are as follows:
REASON (optional) NORMAL or IVR_ERROR or CALLER_REQ.
This tag is also returned by the CFM to the POP server when the inbound or outbound call has already been terminated (see MAKE_OUTCALL below). After transmitting this tag to the POP server, the CFM cleans up its resource usage count and decrements it. END_CALL has no sub-elements.
[0104]
In response to a request by the IVR application, an XML Page with a MAKE_OUTCALL tag is sent by the CFM to make an outbound call, bridging the caller's incoming call to this outbound call. This request is made by the POP server for the IVR application by following the HREF on the XML Page sent by the IVR application. For example, if the IVR application wants to connect the caller to the operator when the caller presses the key "0", the last XML Page sent by the IVR application would have a TONEID = Must have an HREF corresponding to 0.

Here, <telnum> is replaced by the phone number that the IVR application wants the POP server to call, and {sessionid} is replaced by the session ID created when the inbound call first came.
[0105]
The attributes of MAKE_OUTCALL are as follows.
Telephone number that TELNUM POP server needs to call
Call Flow Conductor URL to signal whether the HREF call was successful (when the outbound has finally ended)
[0106]
If the outbound call fails, the POP server notifies the CFM of this by sending a request to the HREF specified in the EVENT = OUTCALL_ERROR exception (see Example 9). If the outbound is successful, the POP server does not immediately send any notification to the CFM. Rather, the POP server waits for the outbound call to be terminated (by the caller or callee) before sending the request to the HREF attribute of MAKE_OUTCALL. In response to both the success and failure notifications, the CFM sends back an XML Page with an END_CALL tag.
[0107]
MAKE_OUTCALL has one child element. CC_EXCEPTIONMAP that specifies the mapping between a call control exception and the URL of the XML Page to be retrieved if such an exception occurs. CC_EXCEPTIONMAP with IVR_ERROR EXCEPTION must be included before any ACCEPT tags in the first XML Page from CFM. CC_EXCEPTIONMAP with OUTCALL_ERROR EXCEPTION must be included within the MAKE_OUTCALL tag and IMMEDIATE_TRANSFER tag.
[0108]
EXCEPTIONMAP can use a child element, EXCEPTION, to specify a mapping between an exception and a URL from which to retrieve the next page if such an exception occurs. EXCEPTION has two mandatory attributes.
EVENT Possible values are BRIDGE_ERROR, UNBRIDGE_ERROR, IVR_ERROR, and OUTCALL_ERROR.
The URL from which the next page will be retrieved if the exception specified by HREF EVENT occurs.
EXCEPTION has no children.
[0109]
IVR_ERROR indicates an error for an unrecoverable IVR application. The first XML Page from the CFM (including the ACCEPT tag) must contain a CC_EXCEPTIONMAP with an IVR_ERROR event, and this CC_EXCEPTIONMAP must be placed before the ACCEPT tag. OUTCALL_ERROR indicates that an attempt to dial the call has failed. An XML Page with a MAKE_OUTCALL or IMMEDIATE_TRANSFER tag must include a CC_EXCEPTIONMAP with an OUTCALL_ERROR event.
[0110]
The SET tag allows the CFM to set the value of a variable for later replacement by a POP. This tag indicates that the POP server should associate a particular value with a particular variable name, and that when the CFM later uses the variable name in the same XML page or another XML page, A convenient mechanism that allows the CFM to indicate to the POP server what to replace with a value. SET has two required attributes and has no children.
VARNAME The name of the variable.
VALUE The value assigned to the variable.
[0111]
The IMMEDIATE_TRANSFER element is used by the CFM to make an outbound call and redirect the incoming call to the operator by bridging the call to the incoming call. This element is useful if the IVR application is down for any reason. The attributes of IMMEDIATE_TRANSFER are as follows.
Telephone number that TELNUM POP server needs to call
CFM URL to notify if HREF call is successful (when outbound call finally ends)
If the outbound call fails, the POP server immediately informs the CFM of this by sending a request to the HREF specified in the EVENT = OUTCALL_ERROR exception. If the outbound call is successful, the POP server does not send any notification to the call flow conductor. IMMEDIATE_TRANSFER has one child element-CC_EXCEPTIONMAP.
[0112]
As before, some examples serve to illustrate the use of the above tags. Example 7 presents an XML Page for instructing the POP server to accept an incoming call. This page is transmitted in response to a new call instruction from the POP server. This indication is typically the first request sent to the CFM by the POP server for a newly arrived call. After allocating resources for a proxy call to the ACD, the CFM returns this Page to the POP server. Note that the Page contains in the SESSIONID attribute the address of the call structure reserved by the CFM. If the CFM finds that it will soon run out of available ports on the ACD or IVR, it can increase the number of RINGS provided in the RINGBACK before the call is answered by the POP server.

As shown in FIG. 5, in response to an incoming call alert from a POP gateway, such a Page can be used as the <ACCEPT_CALL> page returned by the CFM.
[0113]
In the following example 8, a call termination example is provided. In this case, the IVR application has determined that the caller is done and the call should be terminated. In such a case, the last XML Page sent by the IVR application will have an HREF as follows:

[0114]
When sending a request to the CFM, the POP server sends back the following XML Page.

[0115]
In the next example 9, the IVR application has determined that the caller needs to make an outbound call. In such a case, the last XML Page sent by the IVR application will have an HREF as follows:

When sending a request to the CFM, the POP server sends back the following XML Page.

[0116]
In the following example 10, an XML Page is presented for waiting for an agent with the appropriate skill set to be available and notifying the POP server that the call has been queued in the ACD. . Such a Page can be sent by the CFM in response to a REDIRECT HTTP request (originally from an IVR server) having a query string containing information about an agent group having the appropriate skill set. Via this XML Page, the CFM instructs the POP server to cause the caller to play a music / information commercial file while the call is on hold. The CALL_QUEUED element may optionally include an indication as to how long the queue is and what the expected hold time is.

[0117]
Using the tags described above, call flow management operations such as those shown in FIGS. 5 and 7 can be easily implemented. For example, as shown in FIG. 5, an inbound call can be intercepted at a local POP gateway near the point of origin of the call, reducing long-distance charges that would otherwise be possible. In response, the local POP gateway informs the CFM about the call and asks for instructions to manage the call. This part of the call is shown in the figure as LEG_ID = 1.
[0118]
In response to the notification from the POP gateway, the CFM returns the <ACCEPT_CALL> page, directing the POP gateway to the appropriate URL to retrieve the instructions from the IVR. Following this indication, the POP gateway initiates an exchange with an IVR application that provides instructions for handling inbound calls. For example, the IVR may provide instructions regarding data collection from a user who may be prompted using a designated menu, as described above.
[0119]
As the dialogue between the IVR and the local POP gateway progresses, the IVR instructs the POP gateway to call a proxy call with the goal of finally connecting the caller to an operator at the call center. A request to enter the center's ACD can be made. As shown, this can be done using the CREATE_LEG_AND_DIAL command described above. The designated TELNUM is the number to be dialed to reach the call center. In other cases, the instruction may go to a local gateway server at the call center.
[0120]
In either case, the gateway server passes the request to initiate a proxy call to the CFM, and in response, the CFM initiates a dialog with the requesting gateway to do so. As the proxy call is set up (identified as LEG_ID = 2 in the figure) and the proxy call is about to be answered, the two calls (LEG_ID = 1 and LEG_ID = 2) are bridged as shown. (In response to a BRIDGE_CALL command from the CFM).
[0121]
In addition to enabling management of inbound calls, XML commands can also be used to manage outbound calls from call centers, as shown in FIG. This time, the IVR begins the process by asking the CFM to establish a new call session for the call to the identified telephone number (npa) nxxx-xxxx. In response, the CFM determines the appropriate local POP gateway and initiates a call setup dialog, which causes the POP gateway to make an outbound call to the specified telephone number using the DIAL_CALL command. Ordered. When this call is established, the CFM passes control to the IVR (by passing the appropriate URL from which to retrieve the Page to the POP gateway), which then sends the appropriate called party interaction command to the POP. Can be provided to the gateway.
[0122]
(Description of system)
Having reviewed aspects of the process flow of the present invention, an overview of the system will be helpful. FIG. 8 illustrates a virtual system according to at least one embodiment of the present invention in which an end user 116 is connected to a business call center 150 via an originating local PSTN 106, a long distance network 114, and a terminating local PSTN 106. FIG. 2 is a functional diagram of the intelligent network system.
[0123]
The VIN includes one or more POP call center gateway servers 146 distributed over one or more points of presence 152 near the point of origin of the call. These POP call center gateway servers 146 are connected by one or more call center networks 148 to local call center gateway servers 142 in one or more business call centers 150. I have. Call center network 148 is connected to one or more application web application servers 154 that host user-specified applications, such as CFM and IVR applications, for multiple business call centers 150. The POP call center gateway server 146 further connects to a switched public telecommunications network 114 or a dedicated access public telecommunications network 114 that enables long-distance voice communication with the connected local call center gateway server 142. It is connected.
[0124]
Business call center 150 may belong to multiple business call centers distributed over a large geographic region, and may include one or more local call center gateway servers 142. At the time of handling incoming calls at the POP call center gateway, one of those servers will be dynamically selected by the CFM application.
[0125]
Referring now to FIG. 9, the POP gateway 166 intercepts and responds to an inbound call at or near the point of origin of the call under the direction of the CFM. In addition, the POP gateway 166 provides automated services using a CFM-specified interactive voice response application, and allows the call to be routed to the call center 150 when an appropriate operator servicing the call becomes available. The call is put on hold and queued until it is transferred to the local call center gateway 164 at and / or the music or customized announcement is played to the caller while the call is on hold. If the call is queued, the CFM application issues a command to the local call center gateway 164 to place a proxy call at the call center 150, and You can monitor the progress. The local call center gateway 164 is selected by the CFM using call specific information such as ANI or DNIS or caller account information provided by an IVR application deployed on the web server 154 to best match Response resources to be selected are intelligently selected. Next, when the local call center gateway 164 alerts the CFM to do so, the CFM instructs the POP call center gateway 166 to provide a just-in-time before the operator answers the call. , Causing the locally queued calls to be routed to the local call center gateway 166.
[0126]
The local call center gateway 164 generates a proxy call to the local call center ACD in response to the CFM command. Next, the local call center gateway 164 monitors the progress of the proxy call in the ACD for operator availability and communicates with the CFM for just-in-time call delivery to the selected operator. Then, the call is bridged between the POP call center gateway 166 and the local ACD.
[0127]
The network operations center (NOC) 156 may host a database that can be accessed by CFM and / or other resources of VIN to look up the called number. In this way, intelligent callee routing can be provided.
[0128]
Referring to FIG. 10, a virtual intelligent network according to one embodiment includes multiple POP call center gateways 166 and one or more local calls that may all belong to a single business call center 150. A connection via the call center network 148 between the center gateway 164 and one or more web application servers 154 hosting user-specified applications such as CFM and IVR applications for the business call center. Is a virtual private network. A virtual private network is a connection-transformer such as Asynchronous Transfer Mode (ATM), Frame Relay, or Internet Protocol (IP) for secure, dedicated data communication between connected entities with optional quality of service. Provides a port protocol.
[0129]
Referring to FIG. 11, each POP call center gateway 166 has one or more WEB application servers for each business call center 150, one for each business call center 150 to be served. It may be part of a plurality of such call center networks 148 connected to 154. The POP call center gateway 166 connects to the corresponding local call center gateway 164 using the call center network 148 and, under the direction of the CFM for the respective business call center, Access an interactive voice response application.
[0130]
In the foregoing specification, the invention has been described with reference to specific example embodiments thereof. However, it will be apparent that various modifications and changes can be made to the specific example embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. There will be. For example, the XML commands described above can be stored on any computer-readable medium (eg, CD-ROM, floppy disk, etc.) and / or on a medium that interconnects the elements of VIN. It can be transported as an electrical signal or other (eg, light, microwave, etc.) signal.
[0131]
In addition, the overall goal of this VIN must not be lost. In essence, VIN extends an enterprise network (eg, the business call center described above) to the edge of the access network in a manner that is transparent to the enterprise network and independent of the underlying media transport mechanism. For example, consider the network topology depicted in FIG. Network 200 includes several (N) access networks 202 with gateways 204 at their edges. Gateway 204 can be similar to the POP call center gateway described above.
[0132]
Each access network 202 can serve as a local access network for some users 206. For example, one or more access networks 202 may be a local loop network (wireless or wired), a cellular telephone network (analog or digital), a digital network (eg, IP, ATM, frame relay, etc.). Or other access network. Via gateway 204, access network 202 may be connected to one or more enterprise networks (eg, business call centers, office computer networks, intranets) via transit networks (IXN) 210 and / or IP networks 212. Etc.) 208 can be communicatively coupled. The IXN 210 can be a long-haul network or other telecommunications network operated by a transit operator, and can be a conventional time division multiplex (TDM) transport mechanism, an analog or digital switched communication transport mechanism. Voice calls and / or voice over IP, voice over ATM, voice over frame relay, or any other circuit switched transport or other underlying transport and / or communication mechanism. Or it can carry data communication. The IP network 212 can include the CFM server described above.
[0133]
For example, as described above, under the control of an IVR server and / or a CFM server, the functionality of gateway 208 is delivered to the edge of access network 202 through the control of local applications running on gateway 204. Thus, the user 206 can be provided services without having to incur the costs associated with the transport and / or connection access IXN 210. Further, multiple gateways 208 (which may not be associated with the same business entity) can share gateways 204, with each gateway executing an application running on gateway 204 via the XML control process described above. Have control over Because such control processes use the IP network 212, these control processes also avoid the charges associated with using the IXN 210. Only when a true connection to the enterprise network is needed (e.g., when an operator becomes available) need to bridge the call via the IXN 210 (in any way, e.g., circuit switched PSTN, voice / voice). Over IP, voice over ATM, voice over frame relay, etc.).
[0134]
The VIN also allows for easy end-to-end call routing. For example, using the XML control process described above, an enterprise network can provide destination address information to the gateway 204 to enable the transport of incoming calls over an IP network or other digital network. Consider an incoming call to be associated with a POTS dialing number. Conventional circuit-switched PSTNs can use this dialed number to route calls, but networks based on IP, ATM, frame relay, etc., require the associated address ( Depending on the case, it must have an IP address, VP / VCI, DLCI, etc.). Using the XML control procedure described above, provide such an address to the gateway 204 and route calls (eg, an IP telephone) directly through such a network, and possibly to an IP endpoint. Can be provided. Thus, the VIN separates call management from media management and efficiently uses VOIP (VOATM, VOFR, etc.) as a voice (or other data) transport mechanism. Therefore, due to the general nature of the present VIN and the applications provided thereby, the specification and drawings should be regarded as illustrative rather than restrictive.
[Brief description of the drawings]
FIG.
1 is a schematic diagram showing a conventional call center configuration in which a PBX system, an ACD system, and an IVR system are located in a call center.
FIG. 2
1 is a schematic diagram illustrating a conventional network-based call center configuration with a switch system, an ACD system, and an IVR system located in a long distance network.
FIG. 3
5 is a flowchart illustrating an example of an operational method of a virtual intelligent network according to an embodiment of the present invention;
FIG. 4
5 is a flowchart illustrating one process for local call center selection according to an embodiment of the present invention.
FIG. 5
4 is a call flow diagram illustrating various aspects of using XML commands in a virtual intelligent network (VIN) according to embodiments of the invention.
FIG. 6
FIG. 4 illustrates an example of an XML tag that can be included in an XML Page for transmission within a VIN according to an embodiment of the present invention.
FIG. 7
FIG. 8 is a call diagram illustrating various aspects of the case of an XML command in a VIN for making an outbound call from a call center according to embodiments of the present invention.
FIG. 8
Configuration of a virtual intelligent network according to an embodiment of the present invention including a point-of-presence (POP) call center gateway, a local call center gateway, a call center network, a network operations center, and a web application server. FIG. 4 is a schematic diagram showing elements.
FIG. 9
A virtual according to an embodiment of the present invention including a POP call center gateway connected to a local call center gateway via a call center network controlled by a user-specified application deployed on a web application server. FIG. 2 is a schematic diagram illustrating an intelligent network configuration.
FIG. 10
FIG. 2 is a schematic diagram illustrating components of a virtual intelligent network according to an embodiment of the present invention that supports a single business having multiple call center sites connected to multiple POP call center gateways.
FIG. 11
FIG. 2 is a schematic diagram illustrating components of a virtual intelligent network according to an embodiment of the present invention that supports multiple business call centers connected to multiple POP call center gateways.
FIG.
FIG. 4 illustrates an example network topology according to an embodiment of the present invention.

Claims (51)

A method comprising managing call flow within a remote / data communication network through the use of commands passed between nodes of the network as Extensible Markup Language (XML) tags. Claims wherein managing comprises answering, terminating, accepting, routing, initiating, bridging, unbridging, conferencing, and / or disconnecting. 2. The method according to 1. At least one of the nodes of the network includes a web server hosting a call flow manager application configured to send XML tags to other nodes of the network and receive XML tags from other nodes. The method of claim 2, comprising: The managing comprises receiving a notification of the call at a call flow manager in the network and indicating whether the call should be accepted via one or more uses of XML tags. 2. The method according to 1. 5. The method of claim 4, wherein managing further comprises bridging the call to a second call in response to one or more commands issued using some of the XML tags. The method of claim 5, wherein the second call is a proxy call initiated at a call center in response to one or more commands issued using at least one of the XML tags. The method of claim 5, wherein the second call is initiated at a point of presence near the endpoint of the second call. The method of claim 7, wherein the second call is initiated in response to a command issued using at least one of the XML tags. The method of claim 4, wherein if the call is accepted, the call is further managed under the control of an interactive voice response (IVR) application hosted on a computer resource in the network. 10. The IVR application manages the call by using various XML tags to issue commands related to caller interaction operations performed at the node of the network where the call was received. The method described in. 11. The method of claim 10, wherein at least one of the commands issued by the IVR application includes information about an address at which a node of the network where the call was received can find instructions for terminating the call. 11. The method of claim 10, wherein at least one of the commands issued by the IVR application includes information regarding an address at which a node of the network from which the call was received can find an instruction to play the message. A set of computer readable instructions including call flow management commands written in Extensible Markup Language (XML) for use by a remote / data communication network. 14. The computer readable instructions of claim 13, implemented as electrical or other signals transported over a medium interconnecting at least two nodes of the network. 14. The computer readable instructions of claim 13, implemented on a computer readable medium. A network comprising two or more nodes configured to provide call management operations by communicating with each other via the use of a set of computer-readable instructions expressed in Extensible Markup Language. 17. The network of claim 16, wherein the instructions are represented as a series of operations performed in call management on individual XML pages. Directing a second call center via one or more user-specified web applications to service inbound calls;
Directing a first call center via the application to establish a connection within the center;
Bridging the inbound call from the second call center under the control of the application when a connection is established in the first call center. The method of claim 18, wherein the web application server, the local call center, and the remote call center communicate over a data network. 19. The method of claim 18, wherein the remote call center is selected from a plurality of call centers that are widely distributed. 19. The method of claim 18, wherein the user-specified application runs on a web application server. 19. The method of claim 18, wherein the user-specified application controls call flow behavior and voice response behavior of the local call center and the remote call center. The user-specified application selects a call center to achieve an even distribution of call flows among a plurality of remote call centers, thereby providing a call center for the local call center and the remote call centers. 23. The method according to claim 22, wherein the behavior of the flow is controlled. 23. The method of claim 22, wherein the user-specified application controls voice response behavior by selecting an interactive voice response based automated service and requesting a local center to perform the service. . 23. The method of claim 22, wherein the user-specified application controls the behavior of the call flow and voice response via extensible Markup Language (XML). The method of claim 22, wherein the user-specified applications are a call flow management (CFM) web application and an interactive voice response (IVR) web application. 24. The method of claim 23, wherein the user-specified application is deployed on a web application server hosted at an external internet data center. 20. The user-specified application further comprises collecting caller account information, selecting a remote call center, and routing inbound calls to the selected remote call center. The method described in. A local call center to service the inbound call by intercepting and answering the call near the point of originating the call, providing an interactive voice response based automated service; and 19. The method of claim 18, wherein a remote call center places the call on hold and queued until it is available to service the call. Requesting a call to be queued by a local call center via one or more user-specified applications;
Requesting execution of the voice response application during call hold time via one or more user-specified applications;
Interrupting the queued call via one or more user-specified applications and instructing a local call center to forward the call to a selected answering resource. 30. The method of claim 29 comprising: If a call needs to be transferred from one location to another, the user-specified application requests a local call center to release the connection to the answering resource at the one location, and the other location 31. The method of claim 30, wherein the connection is made. 19. The method of claim 18, further comprising the user-specified application requesting the remote call center to place a proxy call in a queue of the remote call center. A remote call center places a proxy call in response to a request of a user-specified application, monitors the progress of the proxy call for operator availability, and notifies the user-specified application of the progress. 33. The method of claim 32, further comprising: When the remote call center notifies that the operator is available, a user-specified application directs the local call center to forward the held call to the remote call center. 34. The method of claim 33, further comprising: Directing the local call center via one or more user-specified applications to place outbound calls;
Directing a remote call center via the application to establish a connection within the center;
Bridging the outbound call with an existing call under the control of the application. Specifying a set of alternative long distance numbers via one or more user specified applications;
Selecting a first long distance number from the set of alternative long distance numbers;
Directing a first selected number to a local call center via one or more user-specified applications to place a first call;
If the establishment of the first call to the first selected number is unsuccessful, the set of alternate long distances until a call to any of the other selected numbers can be completed. 36. The method of claim 35, further comprising selecting another long distance number from the number. The method of claim 35, further comprising selecting a voice message and instructing a call center to deliver the voice message to an end user. The method of claim 37, wherein the voice message provides an end user with an option to connect to a service providing agent. The end user selects the option and causes the user-specified application to instruct the remote call center to establish a connection with the service providing agent, and to place the call when the connection is established. 39. The method of claim 38, further comprising causing the end user to bridge. A plurality of remote call centers distributed over a wide area to service the call;
A local call center that answers the call;
A web-based application server configured to host a user-specified application that directs a local call center to service calls until a connection is established in a remote call center; Virtual intelligent network system including. 41. The system of claim 40, further comprising a data network connecting a local call center, a plurality of remote call centers, and a web application server. 42. The system of claim 41, wherein the data network is a virtual private network that provides a connection-to-transport protocol. 43. The system of claim 42, further comprising a network operations center connected to said data network for discovering, configuring, monitoring, and managing virtual private networks using a web network management tool. 44. The system of claim 43, further comprising a virtual private network for Internet Protocol (IP) telephony, Media Gateway Control Protocol (MGCP), gatekeeper protocol, and long distance voice communications. Including extending enterprise applications to the edge of the local access network through the use of a call control mechanism provided by the enterprise network to a gateway physically located at the edge of the local access network Method. The method of claim 45, wherein the call control mechanism includes an XML tag associated with the call control function. The method of claim 45, wherein the gateway is shared between multiple enterprise networks. The method of claim 45, wherein a call received via the local access network is terminated at a gateway. 49. The method of claim 48, wherein the call is bridged from a local access network to a corporate network via a transit network. 50. The method of claim 49, wherein the transit network is one of a circuit switched long distance telephone network, a voice over IP network, a voice over ATM network, or a voice over frame relay network. 49. The method of claim 48, wherein the local access network comprises any of a cellular telephone network, a wireless network, or a wired network.

Images