転送エラー復帰技術
転送エラー復帰に関する技術が記載されている。システムは、第１の発呼端末と呼システム・リソースの間の第１の呼セッションに関するコンテキスト情報を記録し、そのコンテキスト情報をコンテキスト識別子とともにコンテキスト・テーブルに格納するように動作するコンテキスト生成モジュールを備えることができる。システムは、そのコンテキスト生成モジュールに接続され、コンテキスト識別子を有する転送エラー・コンテキスト情報を生成するように動作する、転送エラー・コンテキスト・モジュールを備えることができる。システムは、転送エラー・コンテキスト・モジュールに接続され、転送失敗イベントの場合に使用するために転送エラー・コンテキスト情報を第１の発呼端末に送信するように動作する、呼転送モジュールを備えることができる。他の実施形態も説明され、特許請求の範囲に記載されている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、転送エラー復帰技術に関する。
【背景技術】
【０００２】
テレフォニーにおいて、自動着信呼分配装置（ＡＣＤ）とは、着呼を、コールセンター・エージェント向けの特定の端末群に配分する装置またはシステムである。ＡＣＤは、多くの場合、ＣＴＩ（ｃｏｍｐｕｔｅｒ ｔｅｌｅｐｈｏｎｙ ｉｎｔｅｇｒａｔｉｏｎ）システムの一部である。
【０００３】
着呼のルーティングは、ＡＣＤシステムのタスクである。ＡＣＤシステムは、多くの場合、特定の者と話す必要はないが複数の者のうち何れかの者（例えば、カスタマ・サービスの担当者）からの支援を出来るだけ早く必要とする発呼者からの大量の着呼を扱うオフィスに見られる。
【０００４】
ＡＣＤシステムは、一般に、端末向けおよびスイッチ向けのハードウェア、電話回線、およびルーティング戦略向けのソフトウェアを含む。ルーティング戦略とは、システム内部で呼がどのように処理されるかをＡＣＤに伝える１組のルール・ベースの命令である。一般に、これは、所与の着信に対応するのに最も適した従業員を決定するアルゴリズムである。この照合を支援するため、顧客が発呼している理由を発見するための追加のデータが求められ、検討されている。ＡＣＤシステムでは、発呼者の発信者番号通知サービス（ｃａｌｌｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ＣＩＤ）または自動番号識別機能（ａｕｔｏｍａｔｉｃ ｎｕｍｂｅｒｉｎｇ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ＡＮＩ）を使用する場合もある。ＡＣＤシステムでは、呼の理由を確かめるため双方向音声応答（ｉｎｔｅｒａｃｔｉｖｅ ｖｏｉｃｅ ｒｅｓｐｏｎｓｅ：ＩＶＲ）システムを使用することが多い。
【０００５】
人間の介入の必要性が減少するため、ＡＣＤシステムの自動化された利便性により会社または企業のコストを劇的に削減することができる。しかし、顧客を扱うことに対するアルゴリズム的なアプローチでは、ルーティング戦略の限界により顧客が求める望ましい結果が得られなかった場合に、顧客サービスを危険にさらすこととなるおそれがある。従って、ＡＣＤシステムとその基盤技術の改良が、顧客サービスの改善と顧客満足をもたらす結果となろう。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ＩＥＴＦ ＲＦＣ ３５１５ ｔｉｔｌｅｄ “Ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） Ｒｅｆｅｒ Ｍｅｔｈｏｄ”、Ａｐｒｉｌ ２００３（ｔｈｅ “ＳＩＰ Ｒｅｆｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”）ならびにその後継、改訂版および変形
【発明の概要】
【０００７】
種々の実施形態は、一般に、通信システムに関する。いくつかの実施形態は、具体的には、着呼を１群の選択された発呼端末に自動的に送るためのＡＣＤシステムを有するコールセンターなどの通信システムに関する。ＡＣＤシステムは、転送エラー・コンテキスト（ＴＥＣ）コンポーネントの一部として実装される様々な転送エラー復帰技術を利用して、外部発呼端末が、ＡＣＤシステムによってサービスされる様々な内部発呼端末に転送される場合の転送エラーを削減することができる。
【０００８】
例えば、１つの実施形態では、ＡＣＤシステムは、コンテキスト生成モジュール、ＴＥＣモジュール、および呼転送モジュールを含むことができる。コンテキスト生成モジュールは、第１の発呼端末と呼システムのリソースの間の第１の呼セッションに関するコンテキスト情報を記録し、そのコンテキスト情報をコンテキスト識別子と共にコンテキスト・テーブルに格納するように動作する。ＴＥＣモジュールは、コンテキスト識別子を有するＴＥＣ情報を生成するように動作する。呼転送モジュールは、転送失敗の場合に使用するためのＴＥＣ情報を第１の発呼端末に送信するように動作する。他の実施形態も説明され、特許請求の範囲に記載されている。
【０００９】
本概要は、以下の発明を実施するための形態でさらに説明されている選択した概念を簡略化した形式で紹介するために提供するものである。本概要は、特許請求の範囲に記載されている主題事項の重要な特徴または本質的な特徴を特定することを目的とするものでも、特許請求の範囲に記載されている主題事項の範囲の決定に際して、補助として使用することを目的とするものでもない。
【図面の簡単な説明】
【００１０】
【図１】ＡＣＤシステムの一実施形態を示す図である。
【図２】ＴＥＣヘッダの一実施形態を示す図である。
【図３】通信システムの一実施形態を示す図である。
【図４】論理フローの一実施形態を示す図である。
【図５Ａ】第１のメッセージ・フローの一実施形態を示す図である。
【図５Ｂ】第２のメッセージ・フローの一実施形態を示す図である。
【図６】コンピューティング・システム・アーキテクチャの一実施形態を示す図である。
【図７】製品の一実施形態を示す図である。
【発明を実施するための形態】
【００１１】
種々の実施形態は、ある独立型または依存型の動作、機能またはサービスを実施するように配置構成された複数の相互接続された構造を含むことができる。この構造は、物理的な構造、論理的な構造、またはその両方の組合せを備えることができる。この物理的な構造あるいは論理的な構造は、ハードウェア要素、ソフトウェア要素、またはその両方の組合せを用いて実装される。しかし、具体的なハードウェア要素またはソフトウェア要素と関連させた実施形態の記載は、例を意味するものであって、限定ではない。実施形態を実際に実施するためのハードウェア要素またはソフトウェア要素は、所望の計算速度、電力レベル、耐熱性、処理サイクル予算（ｐｒｏｃｅｓｓｉｎｇ ｃｙｃｌｅ ｂｕｄｇｅｔ）、入力データ速度、出力データ速度、メモリ・リソース、データ・バス速度、および他の設計上または性能上の制約など、幾つかの外的要因に応じてその使用が決定される。さらに、物理的な構造または論理的な構造は、その構造間で情報を電子信号またはメッセージの形で通信するための対応する物理的な接続または論理的な接続を有してもよい。この接続は、情報または具体的な構造として適切な有線接続および／または無線接続を備えてもよい。「一実施形態」または「ある実施形態」への言及は、その実施形態に関して説明した具体的な特徴、構造、または特性が少なくとも１つの実施形態に含まれることを意味することに留意されたい。本明細書の種々の場所で「一実施形態では」という語句が現れるが、これは必ずしも全て同じ実施形態を言及しない。
【００１２】
種々の実施形態は、自動発呼システム向けの転送エラー復帰技術に関する。ＡＣＤシステムなどの自動発呼システムは、一般に、例えば顧客サービス業務向けとして、外部発呼端末からの着呼をＡＣＤシステムがサービスする種々の内部発呼端末に転送する必要がある。転送エラー復帰技術により、ＡＣＤシステムは転送失敗イベントから復帰することができる。転送失敗イベントは、対象の発呼端末への呼転送が完了しないというイベントを含む。転送失敗イベントの例には、対象の発呼端末からのビジー信号、対象の発呼端末の呼接続完了失敗、対象の発呼端末との呼接続の完了およびボイスメールまたは統一メッセージング・システムへの到達、意図しない発呼端末との呼接続の完了、等を含みうるが、これらに限らない。
【００１３】
転送エラー復帰技術では、ＡＣＤシステムおよび転送された発呼端末は、ＡＣＤシステムの複雑度を軽減するように、転送失敗イベントから復帰することができる。また、転送エラー復帰技術により、転送された発呼端末の操作者が発呼プロセス全体をＡＣＤシステムで再起動する必要性が軽減または排除される。その結果、転送エラー復帰技術により、操作者、装置またはネットワークの値ごろ感、スケーラビリティ、モジュール性、または拡張性を改善することができる。
【００１４】
図１は、ＡＣＤシステム１００のブロック図を示す。ＡＣＤシステム１００は、コールセンター・エージェント向けの特定の端末群に着呼を割り振ることができる。ＡＣＤシステム１００は、多くの場合、ＣＴＩシステムの一部として実装される。例えば、ＡＣＤシステム１００は、会社または企業にサービスを提供するコールセンター向けのＣＴＩシステムの一部を含んでもよい。
【００１５】
種々の実施形態において、ＡＣＤシステム１００は、パケット交換網および／または回路交換ネットワークなどの種々のタイプのネットワーク間で呼を開始または終了できる、様々なコンポーネント、装置またはシステムを含むことができる。パケット交換網の場合は、ＡＣＤシステムはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）標準組織が定義し推奨する、ＩＥＴＦのＲＦＣシリーズ３２６１、３２６５、３８５３、４３２０ならびにその後継、改訂版および変形により定義されるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）など、１つまたは複数のＶｏＩＰシグナリング・プロトコルを用いてＶｏＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を確立することができる。一般に、ＳＩＰシグナリング・プロトコルは、１つまたは複数の参加者とのセッションを作成し、修正し、終了するためのアプリケーション層のコントロールおよび／またはシグナリング・プロトコルである。これらのセッションには、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通話、マルチメディア配信、およびマルチメディア会議が含まれる。さらに、ＩＥＴＦ ＲＦＣ３５５０ならびにその後継、改訂版および変形によって定義されたＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）およびＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などのデータ・フォーマット・プロトコルまたはメディア・フォーマット・プロトコルを用いて、ＶｏＩＰ呼を確立することができる。ＲＴＰ／ＲＴＣＰ標準は、マルチメディア情報（例えば、オーディオおよびビデオ）をパケット交換網上で送達するための統一または標準化されたパケット・フォーマットを定義する。いくつかの実施形態では、限定ではなく例としてＳＩＰおよびＲＴＰ／ＲＴＣＰプロトコルを利用してもよいが、所与の実装形態で望ましいように他のＶｏＩＰプロトコルを使用してもよいことは理解されよう。
【００１６】
上述した一般的なＶｏＩＰプロトコルに加え、ＡＣＤシステム１００は、非特許文献１などの様々な呼転送プロトコルを具体的に実装することができる。ＳＩＰ参照仕様（ＳＩＰ Ｒｅｆｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）とは、受信者がリクエスト内に提供されたリソースを参照することを要求するＳＩＰ拡張である。ＳＩＰ参照仕様は、ＲＥＦＥＲを送信する者に参照されたリクエストの結果を通知できるようにする機構を提供する。この機構を使用して、呼転送を含む多くの応用例を可能とすることができる。いくつかの実施形態では限定ではなく例としてＳＩＰ参照仕様に言及するが、転送エラー復帰技術を、他の転送機構または転送技術に同様に適用することができる。
【００１７】
図１に図示した実施形態において、ＡＣＤシステム１００はＡＣＤシステムの各部分を含む。この部分には、外部発呼端末とＩＶＲモジュール１２０に通信可能に接続された呼制御モジュール１１０を含む。ＩＶＲモジュール１２０をＴＥＣコンポーネント１３０に通信可能に接続することができる。ＩＶＲモジュール１２０とＴＥＣコンポーネント１３０をコンテキスト・データベース１３４に通信可能に接続することができる。ＴＥＣコンポーネント１３０はＴＥＣモジュール１４２に通信可能に接続されたコンテキスト生成モジュール１３２を含む。ＴＥＣコンポーネント１３０を呼転送モジュール１５０に通信可能に接続することができる。呼転送モジュール１５０を呼制御モジュール１１０に通信可能に接続することができ、外部発呼端末を呼制御モジュール１１０に接続することができる。
【００１８】
図１に示すＡＣＤシステム１００の実施形態は一定のトポロジで配置した一定の要素を含むが、ＡＣＤシステム１００は別のトポロジで配置した、それより多いかまたは少ない要素を含んでもよく、これが依然として当該実施形態の範囲内にあることは理解されよう。さらに、ＡＣＤシステム１００の種々の要素を、互いの間の動作を調整するための情報を交換するために使用できる種々の信号線によって接続することができる。この情報を、種々の信号線に割り当てられた信号として実装することができる。係る割り当てでは、各メッセージが信号である。しかし、さらなる実施形態では、データ・メッセージを代替的に使用することもできる。係るデータ・メッセージを、種々の接続を通じて送信することができる。例示的な接続には、パラレル・インターフェース、シリアル・インタフェース、およびバス・インタフェースが含まれる。
【００１９】
ＡＣＤシステム１００は呼制御モジュール１１０を含むことができる。一般に、呼制御モジュール１１０を、ＡＣＤシステム１００の呼フロー動作を管理するように配置構成することができる。テレフォニーでは、呼制御とは、その中心的な機能を提供する電話交換機内のソフトウェアを指す。呼制御モジュール１１０は、宛先指定情報を解読し、通話を一方のエンド・ポイントから別のエンド・ポイントへと送る。呼制御モジュール１１０はまた、標準的な交換動作をユーザのニーズに適合させるために使用できる機能を生成する。係る機能の一般的な例として、呼転送、通話中着信、自動転送、着信拒否、等がある。
【００２０】
ＡＣＤシステム１００は、ＩＶＲモジュール１２０を含むことができる。ＩＶＲモジュール１２０は、一般に、発呼者とマシン・インタフェースの間の対話を管理するように配置構成された呼システム・リソースを含むことができる。テレフォニーでは、ＩＶＲは、コンピュータが通常の通話を用いて音声やタッチ・トーンを検出できるようにする電話技術を指す。ＩＶＲモジュール１２０は、発呼者にその後の対処方法をさらに指示するために、事前に記録された音声または動的に生成された音声で応答することができる。ＩＶＲモジュール１２０を使用して、インタフェースを一連の簡単なメニュー選択へ分類できるほぼすべての機能を制御することができる。発呼者は、ＩＶＲモジュール１２０が応答する電話番号をダイヤルする。ＩＶＲモジュール１２０は、ＤＮＩＳ（Ｄｉａｌｅｄ Ｎｕｍｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）に結合されたアプリケーションを実行する。アプリケーションの一部として、事前に録音された音声ファイルまたは動的に生成されたＴＴＳ（Ｔｅｘｔ ｔｏ Ｓｐｅｅｃｈ）音声により、発呼者が利用可能なオプションが説明される。発呼者には、ＤＴＭＦ（Ｄｕａｌ−Ｔｏｎｅ Ｍｕｌｔｉ−Ｆｒｅｑｕｅｎｃｙ）トーンまたは発せられた単語を用いてオプションを選択するための選択肢が与えられる。音声認識は通常、より複雑なトランザクションを実行するために使用され、アプリケーションのメニュー構造を簡素化する。
【００２１】
ＡＣＤシステム１００は、呼転送モジュール１５０を含むことができる。呼転送モジュール１５０を、一般に、ＡＣＤシステム１００向けの呼転送動作を管理するように配置構成することができる。別々のモジュールとして示したが、呼転送モジュール１５０によって提供される動作、機能またはサービスを、呼制御モジュール１１０の統合された部分として実装できることは理解されよう。実施形態はこの文脈において限定されない。
【００２２】
呼転送は、必要な場所にダイヤルすることにより、ユーザが既存の呼を別の電話または中継台に移動させることを可能にする通信機構である。転送された呼は、通知されるか、または通知されないかのいずれかである。転送された呼が通知される場合、所望の通話相手または内線に、来つつある呼が通知される。これは、一般に、発呼者を保留し所望の通話相手または内線にダイヤルすることで行われる。その後、その通話相手または内線が通知を受け、その通話相手または内線がその呼を受け入れる場合は、その呼がその通話相手または内線に転送される。通知転送に対して一般に使用される他の用語には、拡張転送およびウォーム転送が含まれる。他方では、非通知転送は、来つつある呼を所望の通話相手または内線に通知せずに転送される。この転送は自動的にその電話線に転送される。非通知転送に対して一般に使用される他の用語には、コールド転送、ブラインド転送が含まれる。
【００２３】
双方とも可能であるが、呼制御モジュール１１０とＩＶＲモジュール１２０は、一般に、ＡＣＤシステム１００の自動化された性質を促進するために非通知転送を実行する。従って、ＩＶＲモジュール１２０が発呼者から情報を受け取り、その情報に基づいて呼を所望の通知相手の特定の発呼端末に転送するように呼制御モジュール１１０に要求する場合が生じうる。このため、所望の通話相手が応対できず、転送失敗イベントに至る場合がある。従来の呼システムでは、これにより発呼者が会社の代表番号にリダイヤルし、ＩＶＲモジュール１２０に再接続し、ＩＶＲモジュール１２０との別の対話を行い、同じまたは異なる通話相手に接続してサービスを取得しなければならないこととなりうる。
【００２４】
呼転送の問題は、呼転送動作が首尾よく完了するまでＡＣＤシステム１００の呼制御要素をシグナリング経路内に保つことによって解決されることがある。例えば、ＡＣＤシステム１００は、ＳＩＰ呼の両端に対してユーザ・エージェントとして振舞うためにＢ２ＢＵＡ（ｂａｃｋ−ｔｏ−ｂａｃｋ ｕｓｅｒ ａｇｅｎｔ）を実装することができる。Ｂ２ＢＵＡは転送されている呼の状態を追跡し、呼の転送者（例として転送を開始する通話相手）に任意の変化を通知することができる。しかしながら、Ｂ２ＢＵＡを使用すると、呼制御動作の複雑さが増し、呼転送動作が完了するまでその呼転送動作を監視し追跡するためのリソースを消費し、それにより、他の着呼に利用可能なリソースが減少する。これは、ＡＣＤシステム１００が比較的大量の着呼をサービスする適用例に対しては、特に非効率的でありうる。
【００２５】
これらおよび他の問題を解決するために、ＡＣＤシステム１００は、Ｂ２ＢＵＡソリューションの場合のようにＡＣＤシステム１００が専ら呼転送動作の監視にリソースを使用する必要性を軽減または排除する種々の転送エラー復帰技術を実装することができる。転送者は、呼転送動作が受け入れられた後に、コールレグを終了させることができる。さらに、転送された者は、常に呼に対する完全な制御を維持する。これらおよび他の利点は、例えば、ＴＥＣコンポーネント１３０を用いて実現することができる。
【００２６】
一般に、ＴＥＣコンポーネント１３０を、転送失敗の場合に発呼者とＡＣＤシステム１００が復帰できるようにする種々の転送エラー復帰技術を実装するように配置構成することができる。ＴＥＣコンポーネント１３０は、発呼者とＩＶＲモジュール１２０などの呼システム・リソースの間の対話に関するコンテキスト情報を記録し、記憶することができる。ＴＥＣコンポーネント１３０はまた、コンテキスト識別子と称するコンテキスト情報への参照を含む、ＴＥＣ情報を有するＴＥＣヘッダを生成することができる。次に、ＴＥＣコンポーネント１３０は、転送失敗イベントに自動的に応答する際に使用するために、ＴＥＣ情報を発呼者の発呼端末に呼転送モジュール１５０を介して提供することができる。
【００２７】
ＴＥＣコンポーネント１３０を、発呼者とＩＶＲモジュール１２０などの呼システム・リソースの間の対話に関するコンテキスト情報を記録し、記憶するように構成することができる。本明細書で使用する「コンテキスト情報」という用語は、所与のタスクを実行している間の装置またはシステムの状態または状況に関する任意の情報を指すことができる。一般に、装置またはシステムがタスクを実行するときは常に、装置またはシステムは、リソースを割り当て、そのタスクに対して一般に一意であるデータを生成する。タスクが終了する前に割り込まれた場合は、タスクを、再度最初から開始する必要があるかもしれない。その結果、割り込みの前に行われた作業が全く失われることとなりうる。コンテキスト情報を記録し格納することにより、ある時点でタスクに割り込み、そのタスク全体をリスタートする必要なしに将来の時点で再開することができる。コンテキスト情報を保存することで、装置またはシステムは、タスクが割り込まれてそのタスクに対する作業を再開するときの状態または状況を再生成することができる。この場合、ＴＥＣコンポーネント１３０は、呼転送動作の前に呼セッションに関するコンテキスト情報を記録し記憶することができ、それにより、ＡＣＤシステム１００は、転送失敗の場合に後続の呼セッションに関するコンテキストを再生成することができる。コンテキスト情報の例には、限定ではなく、呼セッションの詳細、クライアント、装置、装置の機能、通話者の間の通信、呼接続、呼セッション、呼履歴、呼転送に関する以前の対象の発呼端末、エラー情報、発呼者の嗜好、発呼者のルール、発呼者の位置、発呼者の識別、生態情報、発呼者の個人情報（例えば、名前、住所、電話番号、等）、媒体の種別、媒体のパラメータ、電話番号の優先順位、キーワード、アプリケーション、アプリケーション・データ、等に関する任意の情報を含めることができる。本実施形態はこの文脈において限定されない。
【００２８】
ＴＥＣコンポーネント１３０を、コンテキスト情報に関するコンテキスト識別子を含むＴＥＣ情報１４４を生成するように配置構成することができる。本明細書で使用する「ＴＥＣ情報」という用語は、転送失敗の場合の転送エラー復帰動作を可能とするのに適した任意の情報を指すことができる。より具体的には、ＴＥＣ情報１４４により、発呼者の発呼端末が、転送失敗イベントに応答して、ＩＶＲモジュール１２０などの呼システム・リソースに自動的に再接続できるようにすることができる。さらに、ＴＥＣ情報１４４はコンテキスト識別子を含むことができ、このコンテキスト識別子により、ＡＣＤシステム１００は、発呼者との以前の呼セッションからコンテキスト情報を取り出し、後続の呼セッションにおける発呼者に関するコンテキストを生成して、以前に実施したデータ収集動作を削減または排除することができる。
【００２９】
一般的な動作では、呼制御モジュール１１０は着呼１０２−１を第１の発呼端末から受信することができる。呼制御モジュール１１０は呼フローを管理し、着呼１０２−１をＩＶＲモジュール１２０などの呼システム・リソースに接続する。これにより、第１の発呼端末とＩＶＲモジュール１２０の間の第１の呼セッションに対する第１の呼接続が確立される。
【００３０】
ＩＶＲモジュール１２０は、音声プロンプトを第１の発呼端末に送信し、第１の発呼端末から操作者の指令を受け取ることによって、第１の呼セッションに対する対話を管理するように動作する。ＩＶＲモジュール１２０は、ＤＮＩＳにダイヤルされる番号に結び付けられたアプリケーションを実行する。アプリケーションの一部として、事前に記録した音声ファイルまたは動的に生成されたＴＴＳ音声により、発呼者が利用可能な様々なオプションが説明される。発呼者には、ＤＴＭＦトーンまたは発せられた単語を用いてオプションを選択するための選択肢が与えられる。音声認識は通常、より複雑なトランザクションを実行するために使用され、アプリケーションのメニュー構造を簡素化する。ＩＶＲモジュール１２０が転送対象の発呼端末を決定するために発呼者から十分な情報を収集すると、ＩＶＲモジュール１２０は転送要求を呼制御モジュール１１０に送信することができる。
【００３１】
第１の発呼端末とＩＶＲモジュール１２０の間の第１の呼セッション中に、ＴＥＣコンポーネント１３０は、ＴＥＣ情報１４４を生成するためのＴＥＣ動作を開始することができる。図１に示した実施形態では、ＴＥＣコンポーネント１３０はコンテキスト生成モジュール１３２とＴＥＣモジュール１４２を備えることができる。
【００３２】
コンテキスト生成モジュール１３２を、第１の発呼端末とＩＶＲモジュール１２０などの呼システム・リソースの間の第１の呼セッションに関するコンテキスト情報１４０−１〜ｎを記録するように配置構成することができる。コンテキスト情報１４０−１〜ｎには、とりわけ、例えば、発呼者に提供された音声プロンプト、およびその音声プロンプトに応答して発呼者によって与えられた応答を含めることができる。コンテキスト情報１４０−１〜ｎには、さらに、アカウント番号、優先度情報、発呼者の嗜好などの発呼者の情報を有する発呼者のレコードまたはプロフィールなど、発呼者に関する情報を含めることができる。これらおよび他種のコンテキスト情報を使用して、呼セッションに関する一般的なコンテキストのスナップショット、特に、ＩＶＲモジュールが転送動作を開始する前に発呼者とＩＶＲモジュール１２０が到達した対話内のポイントのスナップショットを確立することができる。コンテキスト生成モジュール１３２は、対応するコンテキスト識別子１３８−１〜ｍをそれぞれが有するコンテキスト情報１４０−１〜ｎを記憶することができ、コンテキスト識別子１３８−１〜ｍは、一体となってコンテキスト・データベース１３４のコンテキスト・テーブル１３３においてコンテキスト・レコード１３６−１〜ｐを形成する。
【００３３】
ＴＥＣモジュール１４２を、とりわけコンテキスト識別子１３８−１〜ｍを有するＴＥＣ情報１４４を生成するように配置構成することができる。ＴＥＣ情報１４４には、とりわけ、転送エラー・イベント後に参照すべきリソース識別子、転送エラー・イベントを定義するエラー・コード、以前の呼セッションからのコンテキスト情報に関するコンテキスト識別子、等を含めることができる。ＴＥＣモジュール１４２は、ＴＥＣ情報１４４を呼転送モジュール１５０に転送することができる。
【００３４】
呼転送モジュール１５０はＴＥＣ情報を受け取り、転送失敗の場合に使用するためにＴＥＣ情報１４４を第１の発呼端末に送信する。前述のように、ＩＶＲモジュール１２０が転送対象の発呼端末を決定するために十分な情報を発呼者から収集すると、ＩＶＲモジュール１２０は転送要求を呼制御モジュール１１０に送信することができる。呼制御モジュール１１０は、転送要求をＩＶＲモジュール１２０から受け取る。呼制御モジュール１１０は、着呼１０２−１の転送に備えて、転送対象の発呼端末の番号検索などの、様々な呼制御動作を実施することができる。呼制御モジュール１１０は、制御指令を呼転送モジュール１５０に送信する。制御指令には、例えば、第１の発呼端末を第２の発呼端末へ転送する転送命令を含めることができる。呼転送モジュール１５０は、転送命令を呼制御モジュール１１０から受け取り、ＴＥＣ情報１４４をＴＥＣモジュール１４２から受け取り、転送要求ごとに第１の発呼端末を第２の発呼端末に転送する。
【００３５】
呼制御モジュール１５０は転送命令を呼制御モジュール１１０から受け取り、ＴＥＣ情報１４４をＴＥＣモジュール１４２から受け取り、転送メッセージを第１の発呼端末に送信する。幾つかの実施形態では、転送メッセージには、ＳＩＰ参照仕様によって定義されるＲＥＦＥＲメッセージ１０４−１を含めることができる。ＲＥＦＥＲメッセージ１０４−１には、とりわけ、ＴＥＣ情報１４４を含めることができる。具体的には、ＴＥＣ情報１４４には、図２を参照してより詳細に説明するＴＥＣヘッダを含めることができる。
【００３６】
図２は、データ構造２００の一実施形態を示す。データ構造２００は、例えば、ＲＥＦＥＲメッセージ１０４を含むことができる。ＲＥＦＥＲメッセージ１０４は、ＡＣＤシステム１００などの自動呼システムに対する呼を転送するための転送機構を含むことができる。ＲＥＦＥＲメッセージ１０４は、ＩＥＴＦ ＲＦＣ ３２６１によって定義されるＳＩＰメソッドである。ＲＥＦＥＲメッセージ１０４は、Ｒｅｑｕｅｓｔ−ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によって特定される受信者が、リクエスト内で提供されたコンタクト情報を用いて第三者に接続することを示す。Ｒｅｆｅｒ−Ｔｏ ＵＲＩによって特定されるリソースは、そのＵＲＩタイプに対する通常の機構を用いて接続される。例えば、ＵＲＩが、（例えば、ｍｅｔｈｏｄ＝ＩＮＶＩＴＥ ＵＲＩパラメータを用いて）ＩＮＶＩＴＥを示すＳＩＰのＵＲＩである場合は、ＳＩＰのＵＡは、ＳＩＰ標準で定義されたＩＮＶＩＴＥを送信するための通常のルールの全てを用いて新しいＩＮＶＩＴＥを発行するであろう。
【００３７】
図２に示す実施形態では、ＲＥＦＥＲメッセージ１０４は、ヘッダへの参照（Ｒｅｆｅｒ Ｔｏ Ｈｅａｄｅｒ：ＲＴＨ）２２０を含むことができる。ＲＴＨ２２０は、ＳＩＰ標準によって定義されるリクエスト・ヘッダ（ｒｅｑｕｅｓｔ−ｈｅａｄｅｒ）である。ＲＴＨ２２０は、一般に、ＲＥＦＥＲリクエストにおいてのみ現れる。ＲＴＨ２２０は、次のフォーマットに従って参照ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を提供する。
【００３８】
【数１】
【００３９】
ＵＲＬは、リソースを特定することに加えてその主要なアクセス機構またはネットワーク位置を記述することによって、リソースの表現に作用またはその表現を取得するための技法を提供するＵＲＩである。
【００４０】
ＲＴＨ２２０に加えて、ＲＥＦＥＲメッセージ１０４はＴＥＣヘッダ（ＴＣＨ）２３０を含むことができる。ＴＣＨ２３０は、ＴＥＣ情報１４４に対するデータ構造を含むことができる。図２に示した実施形態では、ＴＣＨ２３０は、１つまたは複数のリソース識別子２３２、１つまたは複数のエラー応答コード２３４、および１つまたは複数のコンテキスト識別子１３８−１〜ｍを含むことができる。ＴＣＨ２３０は、転送エラー復帰動作において使用するのに適した他種の情報を含むことができ、本実施形態はこの文脈において限定されない。
【００４１】
リソース識別子２３２は、転送失敗イベントに応答して呼を転送すべきリソースまたは宛先に関するコンタクト情報を表すことができる。コンタクト情報には、電話番号、ネットワーク・アドレス、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、電子メール（ｅｍａｉｌ）アドレス、ＳＩＰアドレス、ＵＲＩ、ＵＲＬ、およびリソースに関する他の任意の一意な識別子など、リソースに関する任意の種類のコンタクト情報を含めることができる。リソースには、転送エラー・イベントの前に呼転送を開始した転送者を含めて、転送エラー復帰動作を扱うのに適した任意のリソースを含めることができる。例えば、リソース識別子２３２は、次のように、ＩＶＲモジュール１２０などの、着呼に関して転送者のＳＩＰアドレスを含むことができる。
＜ｓｉｐ：ａｃｄ＠ｃｏｍｐａｎｙＡ．ｃｏｍ＞
別の例では、リソース識別子２３２は、特に転送エラー復帰動作を扱うために設計された専用呼システム・リソースを含むことができる。
【００４２】
エラー応答コード２３４は、転送エラー復帰動作を自動的に開始する転送エラー・イベントを定義する、構成可能なエラー・ケースまたはエラー・コードのリストを含むことができる。例えば、エラー応答コード２３４は、次のような様々なＳＩＰエラー・コードを含むことができる。
Ｒｅｓｐ−Ｃｏｄｅｓ＝“４ｘｘ，５ｘｘ，６ｘｘ”
本例では、ＴＣＨ２３０は発呼端末に、全ての４００、５００および６００クラスのＳＩＰエラー応答に対して呼をａｃｄ＠ｃｏｍｐａｎｙＡ．ｃｏｍに転送するよう指示するであろう。エラー応答コード２３４は、ＡＣＤシステム１００のユーザによって構成可能である。
【００４３】
コンテキスト識別子１３８−１〜ｍには、ＴＥＣコンポーネント１３０のコンテキスト・データベース１３４に格納したコンテキスト情報に対する１つまたは複数のコンテキスト識別子を含めることができる。コンテキスト識別子１３８−１〜ｍは任意の一意な識別子を含むことができ、その例は次の通りである。
Ｃｏｎｔｅｘｔ＝３ｘＡＢ２５１ｄ９ｅ
コンテキスト識別子１３８−１〜ｍを発呼要求とともに送信して、ＡＣＤシステム１１０との後続の呼セッションを開始することができる。ＡＣＤシステム１１０はコンテキスト識別子１３８−１〜ｍを使用して、外部発呼端末との以前の呼セッションに関するコンテキスト情報を取り出し、その外部発呼端末との後続の呼セッションのために、ＡＣＤシステム１１０の以前の呼セッションのコンテキストを復元することができる。
【００４４】
再度図１を参照すると、発呼側では、第１の発呼端末がＴＥＣ情報１４４を、ＲＥＦＥＲメッセージ１０４−１の一部を含むＴＣＨ２３０の形で、呼転送モジュール１５０から受け取ることができる。第１の発呼端末は、転送失敗イベントを検出するロジックを備えることができ、ＴＣＨ２３０内に含まれるＴＥＣ情報１４４を用いて、第１の発呼端末とＡＣＤシステム１００に関する呼システム・リソースの間の第２の呼セッションを開始することができる。
【００４５】
ＡＣＤシステム１００は、第１の発呼端末とＩＶＲモジュール１２０などの呼システム・リソースの間の第２の呼セッションを確立するための着呼１０２−２を受け取ることができる。コンテキスト生成モジュール１３２はコンテキスト識別子を第１の発呼端末から受け取ることができ、コンテキスト識別子１３８−１〜ｍに対応するコンテキスト情報１４０−１〜ｎをコンテキスト・データベース１３４のコンテキスト・テーブル１３３から取り出すことができる。コンテキスト生成モジュール１３２は、コンテキスト情報１４０−１〜ｎをＩＶＲモジュール１２０に送信することができる。あるいは、ＩＶＲモジュール１２０など、コンテキスト生成モジュール１３２とは異なるＡＣＤシステム１００の他の任意の要素がコンテキスト情報１４０−１〜ｎを取り出してもよい。この場合、第２の呼セッションからのコンテキスト情報を記録し適切なコンテキスト情報１４０−１〜ｎを更新するように、コンテキスト生成モジュール１３２に通知する必要があるかもしれない。
【００４６】
ＩＶＲモジュール１２０は、コンテキスト情報１４０−１〜ｎを受け取り、そのコンテキスト情報１４０−１〜ｎに基づいて、第１の発呼端末に対する後続の処理イベントを決定することができる。例えば、ＩＶＲモジュール１２０は、コンテキスト情報１４０−１〜ｎから、第１の発呼端末からの第１の着呼１０２−１を第２の発呼端末へ転送することが失敗したことを判定することができ、従って、ＩＶＲモジュール１２０は、第２の着呼１０２−２を第１の発呼端末から、第３の発呼端末などの別の内部発呼端末へ転送することを決定することができる。
【００４７】
第１の呼セッションに関して、コンテキスト生成モジュール１３２は、第１の発呼端末とＩＶＲモジュール１２０の間の第２の呼セッションからのコンテキスト情報を記録することができる。コンテキスト生成モジュール１３２は、次いで、第１の呼セッションからのコンテキスト情報１４０−１〜ｎを、第２の呼セッションからのコンテキスト情報で更新することができる。コンテキスト生成モジュール１３２は、更新されたコンテキスト情報１４０−１〜ｎを、第１の呼セッションと同じコンテキスト識別子１３８−１〜ｍを有する適切なコンテキスト・レコード１３６−１〜ｐに格納することができる。
【００４８】
図３は、通信システム３００の一実施形態を示す。種々の実施形態では、通信システム３００を、無線通信システム、有線通信システム、またはその両方の組合せとして実装することができる。無線通信システムとして実装した場合は、通信システム３００は、１つまたは複数のアンテナ、送信機、受信機、送受信機、増幅器、フィルタ、制御ロジックなど、無線通信媒体上で通信するのに適したコンポーネントおよびインタフェースを備えることができる。通信媒体の例には、ＲＦ（ｒａｄｉｏ−ｆｒｅｑｕｅｎｃｙ）スペクトルなど、無線スペクトルの一部を用いて実装した無線共有型媒体を含めることができる。有線通信システムとして実装した場合は、通信システム３００は、Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）アダプタ、Ｉ／Ｏアダプタを対応する優先通信媒体、ＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）ディスク・コントローラ、ビデオ・コントローラ、オーディオ・コントローラ、等と接続するための物理コネクタなどの、有線通信媒体上で通信するのに適したコンポーネントおよびインタフェースを備えることができる。有線通信媒体の例には、有線、ケーブル、金属リード、ＰＣＢ（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄ）、バックプレーン、スイッチ・ファブリック、半導体材料、ツイスト・ペア配線、同軸ケーブル、光ファイバ、等を含めることができる。
【００４９】
図３に示すように、通信システム３００は、複数の発呼端末３１０−１〜ｒを含むことができる。発呼端末３１０−１〜ｒは、パケット交換網３２０を介してＡＣＤシステム１００とＶｏＩＰ呼接続を確立できる任意の物理通信装置または論理通信装置を備えることができる。発呼端末３１０−１〜ｒの例には、限定ではなく、デジタル電話、パケット電話、ＶｏＩＰ電話、データ通信機能付きの携帯電話、コンピュータ、パーソナル・コンピュータ、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、モバイル・コンピュータ、サーバ、ワークステーション、電化製品、ネットワーク機器、等を含めることができる。一実施形態では、例えば、発呼端末３１０−１〜ｒを、ＳＩＰユーザ・エージェントとして実装されたＶｏＩＰ発呼端末として実装してもよい。しかし、本実施形態はこの文脈において限定されない。
【００５０】
第１の発呼端末３１０−１は外部の発呼端末を表すことができ、発呼端末３１０−２〜ｒは、ＡＣＤシステム１００によってサービスされる内部の発呼端末を表すことができる。第１の発呼端末３１０−１は、パケット交換網３２０を介して、ＡＣＤシステム１００との第１の呼接続３３０−１を開始することができる。パケット交換網３２０の例には、インターネットを含めることができる。第１の発呼端末３１０−１の発呼者との対話を通じて、ＡＣＤシステム１００は、呼接続３３０−１を第２の発呼端末３１０−２に転送することを決定でき、それに従ってＴＣＨ２３０を有するＲＥＦＥＲメッセージ１０４を介して第１の発呼端末３１０−１に通知し、呼接続３３０−１を解放する。
【００５１】
呼転送が失敗したと仮定すると、第１の発呼端末３１０−１のＴＥＣモジュール３０２は、転送エラー・イベントを検出し、ＴＣＨ２３０からＴＥＣ情報１４４を参照する。ＴＥＣモジュール３０２は、ＴＥＣ情報１４４を利用してクライアント側の転送呼復帰動作を実施することができる。例えば、ＲＥＦＥＲメッセージ１０４−１のＴＣＨ２３０のリソース識別子２３２を用いて、ＴＥＣモジュール３０２はＡＣＤシステム１００との呼接続を自動的に確立することができる。別の例では、ＴＥＣモジュール３０２は、ＡＣＤシステム１００への接続、会社内の異なる番号に接続、転送エラー復帰動作を終了する、等のユーザ・オプションのリストを提示することができる。これにより、転送された者に対して、転送失敗イベントを扱うための所望の選択肢をプログラム的に選択する機会を提供することができる。
【００５２】
第１の呼接続３３０−１が以前に解放されているので、第１の発呼端末３１０−１はＡＣＤシステム１００との第２の呼接続３３０−２を開始し、コンテキスト識別子１３８−１〜ｍをＡＣＤシステム１００に送信する。ＡＣＤシステム１００のＴＥＣコンポーネント１３０は、コンテキスト識別子１３８−１〜ｍを受け取り、対応するコンテキスト情報１４０−１〜ｎを取り出し、第２の呼接続３３０−２上で通信される第２の呼セッションのために、第１の呼接続３３０−１の上で通信される第１の呼セッションのコンテキストを構築する。再構築したコンテキストに基づいて、ＡＣＤシステム１００は、第１の発呼端末３１０−１を第３の発呼端末３１０−３に転送すると決定することができ、それに従ってＴＣＨ２３０を有するＲＥＦＥＲメッセージ１０４を介して第１の発呼端末３１０−１に通知し、第２の呼接続３３０−２を解放する。これらの転送エラー復帰動作は、第１の発呼端末３１０−１が、転送失敗イベントが発生することなく内部の発呼端末３１０−１〜ｒへの接続に成功するまで、任意数のサイクルを継続することができる。
【００５３】
上述した実施形態に対する動作を、１つまたは複数の論理フローを参照してさらに説明することができる。特に記載がない限り、その代表的な論理フローを、提示した順序で実行する必要はなく、またはどのような特定の順序で実行する必要もないことは理解されよう。さらに、論理フローに関して説明した種々の動作を、逐次的あるいは並列的に実行することができる。論理フローを、所与の１組の設計上および性能上の制約に対して望ましいように、説明した実施形態または代替的な要素の１つまたは複数のハードウェア要素および／またはソフトウェア要素を用いて実装することができる。例えば、論理フローを、論理装置（例えば、汎用目的または特殊目的のコンピュータ）によって実行されるロジック（例えば、コンピュータ・プログラム命令）として実装してもよい。
【００５４】
図４は、論理フロー４００のブロック・フロー図を示す。論理フロー４００は、本明細書で説明した１つまたは複数の実施形態によって実行される動作の一部または全部を代表することができる。
【００５５】
ブロック４０２で、論理フロー４００は、第１の発呼端末との第１の呼セッションに関するコンテキスト情報を記録することができる。例えば、ＴＥＣコンポーネント１３０のコンテキスト生成モジュール１３２は、第１の発呼端末３１０−１からの着呼１０２−１を検出し、または通知を受け、第１の発呼端末３１０−１とＩＶＲモジュール１２０の間の第１の呼セッションに関するコンテキスト情報１４０−ｎを記録するための記録動作を開始することができる。
【００５６】
ブロック４０４で、論理フロー４００は、コンテキスト識別子を有するコンテキスト情報を記憶することができる。例えば、ＴＥＣコンポーネント１３０のコンテキスト生成モジュール１３２は、一意なコンテキスト識別子１３８−１〜ｍを用いて、第１の発呼端末３１０−１との第１の呼セッションから記録されたコンテキスト情報１４０−１〜ｎを記憶することができる。コンテキスト識別子１３８−１〜ｍを使用して、第１の発呼端末３１０−１との将来または以降の呼セッションのためのコンテキスト情報１４０−１〜ｎを取り出すことができる。
【００５７】
ブロック４０６で、論理フロー４００は、コンテキスト識別子を有する転送エラー・コンテキスト情報を生成することができる。例えば、ＴＥＣモジュール１４２は、ＴＣＨ２３０を生成することができる。ＴＥＣモジュール１４２は、コンテキスト識別子１３８−１〜ｍをコンテキスト生成モジュール１３２から直接、または間接的にコンテキスト・データベース１３４を介して受け取り、ＴＣＨ２３０にコンテキスト識別子１３８−１〜ｍを含めることができる。ＴＥＣモジュール１４２は、ＴＣＨ２３０を呼転送モジュール１５０に送信することができる。
【００５８】
ブロック４０８で、論理フロー４００は、転送失敗イベントの場合に使用するために、転送エラー・コンテキスト情報を第１の発呼端末に送信することができる。例えば、呼転送モジュール１５０は、呼制御モジュール１１０からの転送指示を受け取り、ＴＥＣモジュール１４２からＴＣＨを受け取り、ＲＥＦＥＲメッセージ１０４−１を生成することができる。呼転送モジュール１５０は、ＲＥＦＥＲメッセージ１０４−１を第１の発呼端末３１０−１に送信し、着呼１０２−１に対する呼接続を解放することができる。
【００５９】
図５Ａは、第１のメッセージ・フロー５００の一実施形態を示す。メッセージ・フロー５００は通信システム３００の種々の要素の間のメッセージ・フローを表すことができる。図５Ａに示すように、発呼者アリスがＡ社の主番号に発呼し、Ａ社のＡＣＤシステム１００がその呼を受け入れるとする。矢印５０２によって示すＩＮＶＩＴＥメッセージ（例えば、ｍａｉｎ−ｎｕｍｂｅｒ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、アリスは発呼端末３１０−１を使用してパケット交換網３２０を介したＡＣＤシステム１００との第１の呼接続３３０−１を開始することができる。ＡＣＤシステム１００は、ＩＮＶＩＴＥメッセージを受け取り、矢印５０４で示したように２００ ＯＫメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は、矢印５０６で示したようにＡＣＫメッセージを送信し、第１の呼接続３３０−１が確立される。呼接続３３０−１に対するエンド・ポイントは、ＡＣＤシステム１００のＩＶＲモジュール１２０を含むことができる。
【００６０】
第１の発呼端末３１０−１の発呼者との対話を通して、ブロック５０８で、ＩＶＲモジュール１２０は、呼接続３３０−１を第２の発呼端末３１０−２にいるボブに転送することを決定する。それに従って、矢印５１０で示したようにＲＥＦＥＲメッセージ１０４−１を第１の発呼端末３１０−１に送信することによって、ＡＣＤシステム１００は第１の発呼端末３１０−１に通知する。ＲＥＦＥＲメッセージは、発呼端末３１０−２とＴＣＨ２３０に関するリソース識別子を有するＲＴＨ２２０を含むことができる。矢印５１２で示したように、発呼端末３１０−１は、２０２ ＡＣＣＥＰＴＥＤメッセージをＡＣＤシステム１００に送信する。矢印５１４で示したようにＢＹＥメッセージを発呼端末３１０−１に送信することによって、ＡＣＤシステム１００は呼接続３３０−１を解放する。発呼端末３１０−１は、矢印５１６で示したように２００ ＯＫメッセージをＡＣＤシステム１００に送信することによって、呼の解放を承諾する。
【００６１】
発呼端末３１０−１は、矢印５１８で示したようにＩＮＶＩＴＥメッセージ（例えば、ｂｏｂ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、発呼端末３１０−２との新しい呼を開始する。現在ボブが発呼端末３１０−２を用いて通話中であるとする。この場合、発呼端末３１０−２は、矢印５２０で示したように４８６ ＢＵＳＹメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は４８６ ＢＵＳＹメッセージを受け取り、発呼端末３１０−１のＴＥＣモジュール３０２は、４８６ ＢＵＳＹコードとＴＣＨ２３０からのエラー・コードと比較する。それらが一致する場合、発呼端末３１０−１は、発呼端末３１０−２でのボブとの転送失敗イベントを検出する。発呼端末３１０−１は、矢印５２２で示したようにＡＣＫメッセージを発呼端末３１０−２に送信する。
【００６２】
図５Ｂはメッセージ・フロー５００の続きを示す。図５Ｂに示すように、エラー・コード４８６はエラー応答コード２３４の一部であるため、発呼端末３１０−１は、矢印５２２で示すようにコンテキスト識別子１３８−１〜ｍを有する別のＩＮＶＩＴＥメッセージ（例えば、ｍａｉｎ−ｎｕｍｂｅｒ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）をＡＣＤシステム１００へ送信することによって、ＡＣＤシステム１００との第２の呼接続３３０−２を自動的に開始する。矢印５２４で示したように、ＡＣＤシステム１００は、２００ ＯＫメッセージを発呼端末３１０−１に送信する。矢印５２６で示したように、発呼端末３１０−１は、ＡＣＫメッセージをＡＣＤシステム１００に送信する。ブロック５２７で、ＡＣＤシステム１００は、コンテキスト情報を取り出す。取り出したコンテキスト情報により、ＩＶＲモジュール１２０によって提供されたＤＴＭＦベースのメニュー内の位置などの、呼接続３３０−１上の第１の呼セッションに対する元の呼コンテキストを復元することができる。その結果、アリスはＩＶＲモジュール１２０との対話を自動化スクリプトの最初から開始しなければならないことを回避することができる。次に、ブロック５２８で、ＡＣＤシステム１００のＩＶＲモジュール１２０は、ブロック５２８で取り出したコンテキスト情報に基づいて、呼接続３３０−２を第３の発呼端末３１０−３のメアリへ転送する新たな決定を行う。
【００６３】
図５Ａに示されているメッセージ・フロー５００に関して、ＡＣＤシステム１００は、対象の発呼端末３１０−３のメアリへの転送をアリスに通知し、呼接続３３０−２を解放する。これを、矢印５１０、５１２、５１４および５１６のそれぞれに関連して説明されるメッセージと同様である、矢印５３０、５３２、５３４および５３６に関連して説明されるメッセージを用いて実施することができる。注目すべき違いは、発呼端末３１０−２ではなく発呼端末３１０−３に対するリソース識別子を有するＲＴＨ２２０を含むＲＥＦＥＲメッセージ１０４−２が送信され、ＴＣＨ２３０がアップデートされたコンテキスト識別子１３８−１〜ｍを含むことである。
【００６４】
発呼端末３１０−１は、矢印５３８で示したようにＩＮＶＩＴＥメッセージ（例えば、ｍａｒｙ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、発呼端末３１０−３との新しい呼を開始する。メアリが対応可能であり、その呼に応答するとする。発呼端末３１０−３は、ＩＮＶＩＴＥメッセージを受け取り、矢印５４０で示したように２００ ＯＫメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は、矢印５４２で示したようにＡＣＫメッセージを送信し、呼接続３３０−３が、アリスの発呼端末３１０−１とメアリの発呼端末３１０−３の間に確立される。
【００６５】
呼転送の完了に成功すると、ＡＣＤシステム１００と発呼端末３１０−１は、他の発呼者または他の呼セッションからのコンテキスト情報に対する場所を空けるためにコンテキスト情報１４４を削除することによって、通常の記録メンテナンスを実行することができる。
【００６６】
代替的な実施形態では、ＡＣＤシステム１００は、第１の発呼端末３１０−１が転送失敗イベントに応答してＡＣＤシステム１００との呼接続を再確立する必要を回避するように、ＴＥＣ情報１４４を生成することができる。例えば、ＴＥＣモジュール１４２は、ＡＣＤシステム１００ではなく別の対象発呼端末のリソース識別子２３２を有するＴＣＨ２３０を生成することができる。第１の呼セッションの間、ＩＶＲモジュール１２０は、処理のために発呼端末３１０−１を転送するための複数の対象発呼端末３１０−２、３１０−３を決定することができる。次に、ＴＥＣモジュール１４２は、ＡＣＤシステム１００ではなく発呼端末３１０−３のためのリソース識別子２３２を有するＴＣＨ２３０を生成することができる。ＴＥＣモジュール３０２は、転送失敗イベントに応答して発呼端末３１０−３に直接接続することができ、それによって、ＡＣＤシステム１００に発呼する必要を回避することができる。
【００６７】
図５Ａと５Ｂは、無人の転送ケースに対するメッセージ・フロー５００を示す。しかし、いくつかの実施形態では、アリスとボブの間の有人の転送を実行するようにＡＣＤシステム１００を配置構成することができる。この場合、ＡＣＤシステム１００は、アリスが使用する発呼端末３１０−１をボブが使用する発呼端末３１０−２に接続する前に、矢印５１０、５１２、５１４、および５１６で示したメッセージ交換の前に発呼端末３１０−２のボブとの接続を確立する。
【００６８】
図６はコンピューティング・システム・アーキテクチャ６１０のブロック図を示す。コンピューティング・システム・アーキテクチャ６１０は、実施形態の一部または全部を実装するのに適したコンピューティング・アーキテクチャを代表することができる。基本的な構成では、コンピューティング・システム・アーキテクチャ６１０は一般に少なくとも１つの処理装置６３２とメモリ６３４を備える。メモリ６３４を、データを記憶できる任意の機械読取可能またはコンピュータ読取可能な媒体で実装することができ、それらには揮発性メモリおよび不揮発性メモリの両方が含まれる。例えば、メモリ６３４には、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ−ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＤＲＡＭ（ｄｙｎａｍｉｃ ＲＡＭ）、ＤＤＲＡＭ（Ｄｏｕｂｌｅ−Ｄａｔａ−Ｒａｔｅ ＤＲＡＭ）、ＳＤＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ＳＲＡＭ（ｓｔａｔｉｃ ＲＡＭ）、ＰＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、フラッシュメモリ、強誘電性ポリマ・メモリなどのポリマ・メモリ、オボニック・メモリ、相変化メモリもしくは強誘電メモリ、ＳＯＮＯＳ（ｓｉｌｉｃｏｎ−ｏｘｉｄｅ−ｎｉｔｒｉｄｅ−ｏｘｉｄｅ−ｓｉｌｉｃｏｎ）メモリ、磁気カードもしくは光学カード、または情報を記憶するのに適した他の任意の種類の媒体を含めることができる。図６に示すように、メモリ６３４は、１つまたは複数のアプリケーション・プログラム６３６−１〜ｓなどの種々のソフトウェア・プログラム、およびそれに付随するデータを記憶することができる。
【００６９】
コンピューティング・システム・アーキテクチャ６１０はまた、その基本構成を超えた付加的な特徴および／または機能を有してもよい。例えば、コンピューティング・システム・アーキテクチャ６１０は取外し可能記憶装置６３８と取外し不能記憶装置６４０を備えてもよく、それらはまた、前述のように種々の機械読取可能媒体またはコンピュータ読取可能媒体を備えることができる。コンピューティング・システム・アーキテクチャ６１０はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、測定装置、センサ、等のような１つまたは複数の入力装置６４４を有してもよい。コンピューティング・システム・アーキテクチャ６１０はまた、ディスプレイ、スピーカ、プリンタ、等のような１つまたは複数の出力装置６４２を備えてもよい。コンピューティング・システム・アーキテクチャ６１０はさらに、コンピューティング・システム・アーキテクチャ６１０が他の装置と通信できるようにする１つまたは複数の通信接続部６４６を備えてもよい。通信接続部６４６には、１つまたは複数の通信インタフェース、ネットワーク・インターフェース、ＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄｓ）、ラジオ、無線の送信機／受信機（送受信機）、有線および／または無線の通信媒体、物理コネクタ、等のような、種々の標準通信要素を含めることができる。通信媒体は、一般に、コンピュータ読取可能命令、データ構造、プログラム・モジュール、または他のデータを、搬送波または他の伝送機構などの変調データ信号で具現化し、任意の情報伝達媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を有するかまたはその信号内の情報をエンコードするように変化した信号を意味する。限定ではなく例として、通信媒体には有線の通信媒体と無線の通信媒体が含まれる。有線の通信媒体の例として、ワイヤ、ケーブル、金属リード、ＰＣＢ（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄｓ）、バックプレーン、スイッチ・ファブリック、半導体材料、ツイスト・ペア線、同軸ケーブル、光ファイバ、伝播信号、等を含めることができる。無線通信媒体の例として、音響、ＲＦ（ｒａｄｉｏ−ｆｒｅｑｕｅｎｃｙ）スペクトル、赤外線および他の無線の媒体を含むことができる。本明細書で使用される機械読取可能媒体およびコンピュータ読取可能媒体という用語は、記憶媒体と通信媒体の両方を含むことを意味している。
【００７０】
図７は、論理フロー４００を含む、種々の実施形態に対するロジックを記憶するのに適した製品７００の図を示す。示したように、製品７００は、ロジック７０４を記憶する記憶媒体７０２を備えることができる。記憶媒体７０２の例として、揮発性メモリまたは不揮発性メモリ、取外し可能メモリまたは取外し不能メモリ、消去可能メモリまたは消去不納メモリ、書込可能メモリまたは書込不能メモリ、等を含む、電子データを記憶可能な１つまたは複数の種類のコンピュータ読込可能な記憶媒体を含めることができる。ロジック７０４の例として、ソフトウェア・コンポーネント、プログラム、アプリケーション、コンピュータ・プログラム、アプリケーション・プログラム、システム・プログラム、マシン・プログラム、オペレーティング・システム・ソフトウェア、ミドルウェア、ファームウェア、ソフトウェア・モジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェア・インタフェース、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）、命令セット、計算コード、コンピュータ・コード、コード・セグメント、コンピュータ・コード・セグメント、ワード、値、シンボル、またはそれらの任意の組合せのような、種々のソフトウェア要素を含めることができる。
【００７１】
一実施形態では、例えば、製品７００および／またはコンピュータ読取可能な記憶媒体７０２は、コンピュータによる実行時に上述の実施形態に従う方法および／または動作をコンピュータに実施させる実行可能なコンピュータ・プログラム命令を備えたロジック７０４を記憶することができる。実行可能なコンピュータ・プログラム命令は、ソース・コード、コンパイル済みコード、解釈されたコード、実行可能コード、静的コード、動的コード、等のような、任意の適切な種類のコードを含むことができる。実行可能なコンピュータ・プログラム命令を、コンピュータに一定の機能を実施するよう指令するために、事前に定義されたコンピュータ言語、方法または構文に従って実装することができる。命令を、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＢＡＳＩＣ、Ｐｅｒｌ、Ｍａｔｌａｂ、Ｐａｓｃａｌ、Ｖｉｕａｌ ＢＡＳＩＣ、アセンブリ言語、等のような、任意の適切な、高レベルなプログラミング言語、低レベルなプログラミング言語、オブジェクト指向プログラミング言語、ビジュアル・プログラミング言語、コンパイル型プログラミング言語および／またはインタプリタプログラミング言語を用いて実装することができる。
【００７２】
種々の実施形態を、ハードウェア要素、ソフトウェア要素、またはその両方の組合せを用いて実装してもよい。ハードウェア要素の例として、論理装置に対して上で提供した例のいずれかを含めることができ、さらに、マイクロプロセッサ、回路、回路素子（例えば、トランジスタ、レジスタ、コンデンサ、インダクタ、等）、集積回路、論理ゲート、レジスタ、半導体装置、チップ、マイクロチップ、チップ・セット、等をさらに含めることができる。ソフトウェア要素の例として、ソフトウェア・コンポーネント、プログラム、アプリケーション、コンピュータ・プログラム、アプリケーション・プログラム、システム・プログラム、マシン・プログラム、オペレーティング・システム・ソフトウェア、ミドルウェア、ファームウェア、ソフトウェア・モジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェア・インタフェース、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）、命令セット、計算コード、コンピュータ・コード、コード・セグメント、コンピュータ・コード・セグメント、ワード、値、シンボル、またはそれらの任意の組合せを含めることができる。実施形態がハードウェア要素および／またはソフトウェア要素を用いて実装されるかどうかは、所与の実装形態に望ましいように、所望の計算速度、電力レベル、耐熱性、処理サイクル予算、入力データ速度、出力データ速度、メモリ・リソース、データ・バス速度、および他の設計上または性能上の制約など、任意数の要因に従って様々に決定することができる。
【００７３】
幾つかの実施形態を、「結合」および「接続」という表現をそれらの派生語とともに用いて説明することができる。これらの用語は、必ずしも互いに対する同義語として意図されているわけではない。例えば、幾つかの実施形態を、複数の要素が互いに直接物理的または電気的に接触していることを示すために「接続」および／または「結合」という用語を用いて説明することができる。しかし「結合」という用語は、複数の要素が互いに直接接触していないが依然として協調または相互作用していることを意味することもできる。
【００７４】
技術的な開示事項の本質を読者が迅速に確認できるようにする要約を要求する米国特許法施行規則§１．７２（ｂ）に従って要約が提供されていることを強調しておく。要約は、それが各請求項の範囲または意味を解釈または限定するために使用されないという理解のもとに提示されている。さらに、上述の発明を実施するための形態では、開示を分かり易くするために様々な特徴が単一の実施形態に纏められていることが分かる。この開示方法は、クレームされた実施形態には各請求項で明示的に示したよりも多くの特徴が必要であるという意図を反映するものと解釈されるべきではない。そうではなく、添付の特許請求の範囲が示すように、本発明の主題は、単一の開示された実施形態の全特徴よりも少ない特徴に存する。したがって、添付の特許請求の範囲は本明細書において発明を実施するための形態に組み入れられ、各請求項は別々の実施形態に基づく。添付の特許請求の範囲では、「ｉｎｃｌｕｄｉｎｇ」および「ｉｎ ｗｈｉｃｈ」という用語は、それぞれ「ｃｏｍｐｒｉｓｉｎｇ」および「ｗｈｅｒｅｉｎ」という用語の平易な英語の同義語として使用されている。さらに、「第１の」、「第２の」、「第３の」、等の用語は、ラベルとして用いられているにすぎず、それらの対象に数的な要件を課すことを意図するものではない。
【００７５】
主題を構造上の特徴および／または方法論的動作に固有な言葉で説明したが、添付の特許請求の範囲で定義した主題は上述の固有な特徴または動作に必ずしも限定されないことは理解されよう。そうではなく、上述の固有な特徴および動作は特許請求の範囲を実装する形態の例として開示されている。
【技術分野】
【０００１】
本発明は、転送エラー復帰技術に関する。
【背景技術】
【０００２】
テレフォニーにおいて、自動着信呼分配装置（ＡＣＤ）とは、着呼を、コールセンター・エージェント向けの特定の端末群に配分する装置またはシステムである。ＡＣＤは、多くの場合、ＣＴＩ（ｃｏｍｐｕｔｅｒ ｔｅｌｅｐｈｏｎｙ ｉｎｔｅｇｒａｔｉｏｎ）システムの一部である。
【０００３】
着呼のルーティングは、ＡＣＤシステムのタスクである。ＡＣＤシステムは、多くの場合、特定の者と話す必要はないが複数の者のうち何れかの者（例えば、カスタマ・サービスの担当者）からの支援を出来るだけ早く必要とする発呼者からの大量の着呼を扱うオフィスに見られる。
【０００４】
ＡＣＤシステムは、一般に、端末向けおよびスイッチ向けのハードウェア、電話回線、およびルーティング戦略向けのソフトウェアを含む。ルーティング戦略とは、システム内部で呼がどのように処理されるかをＡＣＤに伝える１組のルール・ベースの命令である。一般に、これは、所与の着信に対応するのに最も適した従業員を決定するアルゴリズムである。この照合を支援するため、顧客が発呼している理由を発見するための追加のデータが求められ、検討されている。ＡＣＤシステムでは、発呼者の発信者番号通知サービス（ｃａｌｌｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ＣＩＤ）または自動番号識別機能（ａｕｔｏｍａｔｉｃ ｎｕｍｂｅｒｉｎｇ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ＡＮＩ）を使用する場合もある。ＡＣＤシステムでは、呼の理由を確かめるため双方向音声応答（ｉｎｔｅｒａｃｔｉｖｅ ｖｏｉｃｅ ｒｅｓｐｏｎｓｅ：ＩＶＲ）システムを使用することが多い。
【０００５】
人間の介入の必要性が減少するため、ＡＣＤシステムの自動化された利便性により会社または企業のコストを劇的に削減することができる。しかし、顧客を扱うことに対するアルゴリズム的なアプローチでは、ルーティング戦略の限界により顧客が求める望ましい結果が得られなかった場合に、顧客サービスを危険にさらすこととなるおそれがある。従って、ＡＣＤシステムとその基盤技術の改良が、顧客サービスの改善と顧客満足をもたらす結果となろう。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ＩＥＴＦ ＲＦＣ ３５１５ ｔｉｔｌｅｄ “Ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） Ｒｅｆｅｒ Ｍｅｔｈｏｄ”、Ａｐｒｉｌ ２００３（ｔｈｅ “ＳＩＰ Ｒｅｆｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”）ならびにその後継、改訂版および変形
【発明の概要】
【０００７】
種々の実施形態は、一般に、通信システムに関する。いくつかの実施形態は、具体的には、着呼を１群の選択された発呼端末に自動的に送るためのＡＣＤシステムを有するコールセンターなどの通信システムに関する。ＡＣＤシステムは、転送エラー・コンテキスト（ＴＥＣ）コンポーネントの一部として実装される様々な転送エラー復帰技術を利用して、外部発呼端末が、ＡＣＤシステムによってサービスされる様々な内部発呼端末に転送される場合の転送エラーを削減することができる。
【０００８】
例えば、１つの実施形態では、ＡＣＤシステムは、コンテキスト生成モジュール、ＴＥＣモジュール、および呼転送モジュールを含むことができる。コンテキスト生成モジュールは、第１の発呼端末と呼システムのリソースの間の第１の呼セッションに関するコンテキスト情報を記録し、そのコンテキスト情報をコンテキスト識別子と共にコンテキスト・テーブルに格納するように動作する。ＴＥＣモジュールは、コンテキスト識別子を有するＴＥＣ情報を生成するように動作する。呼転送モジュールは、転送失敗の場合に使用するためのＴＥＣ情報を第１の発呼端末に送信するように動作する。他の実施形態も説明され、特許請求の範囲に記載されている。
【０００９】
本概要は、以下の発明を実施するための形態でさらに説明されている選択した概念を簡略化した形式で紹介するために提供するものである。本概要は、特許請求の範囲に記載されている主題事項の重要な特徴または本質的な特徴を特定することを目的とするものでも、特許請求の範囲に記載されている主題事項の範囲の決定に際して、補助として使用することを目的とするものでもない。
【図面の簡単な説明】
【００１０】
【図１】ＡＣＤシステムの一実施形態を示す図である。
【図２】ＴＥＣヘッダの一実施形態を示す図である。
【図３】通信システムの一実施形態を示す図である。
【図４】論理フローの一実施形態を示す図である。
【図５Ａ】第１のメッセージ・フローの一実施形態を示す図である。
【図５Ｂ】第２のメッセージ・フローの一実施形態を示す図である。
【図６】コンピューティング・システム・アーキテクチャの一実施形態を示す図である。
【図７】製品の一実施形態を示す図である。
【発明を実施するための形態】
【００１１】
種々の実施形態は、ある独立型または依存型の動作、機能またはサービスを実施するように配置構成された複数の相互接続された構造を含むことができる。この構造は、物理的な構造、論理的な構造、またはその両方の組合せを備えることができる。この物理的な構造あるいは論理的な構造は、ハードウェア要素、ソフトウェア要素、またはその両方の組合せを用いて実装される。しかし、具体的なハードウェア要素またはソフトウェア要素と関連させた実施形態の記載は、例を意味するものであって、限定ではない。実施形態を実際に実施するためのハードウェア要素またはソフトウェア要素は、所望の計算速度、電力レベル、耐熱性、処理サイクル予算（ｐｒｏｃｅｓｓｉｎｇ ｃｙｃｌｅ ｂｕｄｇｅｔ）、入力データ速度、出力データ速度、メモリ・リソース、データ・バス速度、および他の設計上または性能上の制約など、幾つかの外的要因に応じてその使用が決定される。さらに、物理的な構造または論理的な構造は、その構造間で情報を電子信号またはメッセージの形で通信するための対応する物理的な接続または論理的な接続を有してもよい。この接続は、情報または具体的な構造として適切な有線接続および／または無線接続を備えてもよい。「一実施形態」または「ある実施形態」への言及は、その実施形態に関して説明した具体的な特徴、構造、または特性が少なくとも１つの実施形態に含まれることを意味することに留意されたい。本明細書の種々の場所で「一実施形態では」という語句が現れるが、これは必ずしも全て同じ実施形態を言及しない。
【００１２】
種々の実施形態は、自動発呼システム向けの転送エラー復帰技術に関する。ＡＣＤシステムなどの自動発呼システムは、一般に、例えば顧客サービス業務向けとして、外部発呼端末からの着呼をＡＣＤシステムがサービスする種々の内部発呼端末に転送する必要がある。転送エラー復帰技術により、ＡＣＤシステムは転送失敗イベントから復帰することができる。転送失敗イベントは、対象の発呼端末への呼転送が完了しないというイベントを含む。転送失敗イベントの例には、対象の発呼端末からのビジー信号、対象の発呼端末の呼接続完了失敗、対象の発呼端末との呼接続の完了およびボイスメールまたは統一メッセージング・システムへの到達、意図しない発呼端末との呼接続の完了、等を含みうるが、これらに限らない。
【００１３】
転送エラー復帰技術では、ＡＣＤシステムおよび転送された発呼端末は、ＡＣＤシステムの複雑度を軽減するように、転送失敗イベントから復帰することができる。また、転送エラー復帰技術により、転送された発呼端末の操作者が発呼プロセス全体をＡＣＤシステムで再起動する必要性が軽減または排除される。その結果、転送エラー復帰技術により、操作者、装置またはネットワークの値ごろ感、スケーラビリティ、モジュール性、または拡張性を改善することができる。
【００１４】
図１は、ＡＣＤシステム１００のブロック図を示す。ＡＣＤシステム１００は、コールセンター・エージェント向けの特定の端末群に着呼を割り振ることができる。ＡＣＤシステム１００は、多くの場合、ＣＴＩシステムの一部として実装される。例えば、ＡＣＤシステム１００は、会社または企業にサービスを提供するコールセンター向けのＣＴＩシステムの一部を含んでもよい。
【００１５】
種々の実施形態において、ＡＣＤシステム１００は、パケット交換網および／または回路交換ネットワークなどの種々のタイプのネットワーク間で呼を開始または終了できる、様々なコンポーネント、装置またはシステムを含むことができる。パケット交換網の場合は、ＡＣＤシステムはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）標準組織が定義し推奨する、ＩＥＴＦのＲＦＣシリーズ３２６１、３２６５、３８５３、４３２０ならびにその後継、改訂版および変形により定義されるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）など、１つまたは複数のＶｏＩＰシグナリング・プロトコルを用いてＶｏＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を確立することができる。一般に、ＳＩＰシグナリング・プロトコルは、１つまたは複数の参加者とのセッションを作成し、修正し、終了するためのアプリケーション層のコントロールおよび／またはシグナリング・プロトコルである。これらのセッションには、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通話、マルチメディア配信、およびマルチメディア会議が含まれる。さらに、ＩＥＴＦ ＲＦＣ３５５０ならびにその後継、改訂版および変形によって定義されたＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）およびＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などのデータ・フォーマット・プロトコルまたはメディア・フォーマット・プロトコルを用いて、ＶｏＩＰ呼を確立することができる。ＲＴＰ／ＲＴＣＰ標準は、マルチメディア情報（例えば、オーディオおよびビデオ）をパケット交換網上で送達するための統一または標準化されたパケット・フォーマットを定義する。いくつかの実施形態では、限定ではなく例としてＳＩＰおよびＲＴＰ／ＲＴＣＰプロトコルを利用してもよいが、所与の実装形態で望ましいように他のＶｏＩＰプロトコルを使用してもよいことは理解されよう。
【００１６】
上述した一般的なＶｏＩＰプロトコルに加え、ＡＣＤシステム１００は、非特許文献１などの様々な呼転送プロトコルを具体的に実装することができる。ＳＩＰ参照仕様（ＳＩＰ Ｒｅｆｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）とは、受信者がリクエスト内に提供されたリソースを参照することを要求するＳＩＰ拡張である。ＳＩＰ参照仕様は、ＲＥＦＥＲを送信する者に参照されたリクエストの結果を通知できるようにする機構を提供する。この機構を使用して、呼転送を含む多くの応用例を可能とすることができる。いくつかの実施形態では限定ではなく例としてＳＩＰ参照仕様に言及するが、転送エラー復帰技術を、他の転送機構または転送技術に同様に適用することができる。
【００１７】
図１に図示した実施形態において、ＡＣＤシステム１００はＡＣＤシステムの各部分を含む。この部分には、外部発呼端末とＩＶＲモジュール１２０に通信可能に接続された呼制御モジュール１１０を含む。ＩＶＲモジュール１２０をＴＥＣコンポーネント１３０に通信可能に接続することができる。ＩＶＲモジュール１２０とＴＥＣコンポーネント１３０をコンテキスト・データベース１３４に通信可能に接続することができる。ＴＥＣコンポーネント１３０はＴＥＣモジュール１４２に通信可能に接続されたコンテキスト生成モジュール１３２を含む。ＴＥＣコンポーネント１３０を呼転送モジュール１５０に通信可能に接続することができる。呼転送モジュール１５０を呼制御モジュール１１０に通信可能に接続することができ、外部発呼端末を呼制御モジュール１１０に接続することができる。
【００１８】
図１に示すＡＣＤシステム１００の実施形態は一定のトポロジで配置した一定の要素を含むが、ＡＣＤシステム１００は別のトポロジで配置した、それより多いかまたは少ない要素を含んでもよく、これが依然として当該実施形態の範囲内にあることは理解されよう。さらに、ＡＣＤシステム１００の種々の要素を、互いの間の動作を調整するための情報を交換するために使用できる種々の信号線によって接続することができる。この情報を、種々の信号線に割り当てられた信号として実装することができる。係る割り当てでは、各メッセージが信号である。しかし、さらなる実施形態では、データ・メッセージを代替的に使用することもできる。係るデータ・メッセージを、種々の接続を通じて送信することができる。例示的な接続には、パラレル・インターフェース、シリアル・インタフェース、およびバス・インタフェースが含まれる。
【００１９】
ＡＣＤシステム１００は呼制御モジュール１１０を含むことができる。一般に、呼制御モジュール１１０を、ＡＣＤシステム１００の呼フロー動作を管理するように配置構成することができる。テレフォニーでは、呼制御とは、その中心的な機能を提供する電話交換機内のソフトウェアを指す。呼制御モジュール１１０は、宛先指定情報を解読し、通話を一方のエンド・ポイントから別のエンド・ポイントへと送る。呼制御モジュール１１０はまた、標準的な交換動作をユーザのニーズに適合させるために使用できる機能を生成する。係る機能の一般的な例として、呼転送、通話中着信、自動転送、着信拒否、等がある。
【００２０】
ＡＣＤシステム１００は、ＩＶＲモジュール１２０を含むことができる。ＩＶＲモジュール１２０は、一般に、発呼者とマシン・インタフェースの間の対話を管理するように配置構成された呼システム・リソースを含むことができる。テレフォニーでは、ＩＶＲは、コンピュータが通常の通話を用いて音声やタッチ・トーンを検出できるようにする電話技術を指す。ＩＶＲモジュール１２０は、発呼者にその後の対処方法をさらに指示するために、事前に記録された音声または動的に生成された音声で応答することができる。ＩＶＲモジュール１２０を使用して、インタフェースを一連の簡単なメニュー選択へ分類できるほぼすべての機能を制御することができる。発呼者は、ＩＶＲモジュール１２０が応答する電話番号をダイヤルする。ＩＶＲモジュール１２０は、ＤＮＩＳ（Ｄｉａｌｅｄ Ｎｕｍｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）に結合されたアプリケーションを実行する。アプリケーションの一部として、事前に録音された音声ファイルまたは動的に生成されたＴＴＳ（Ｔｅｘｔ ｔｏ Ｓｐｅｅｃｈ）音声により、発呼者が利用可能なオプションが説明される。発呼者には、ＤＴＭＦ（Ｄｕａｌ−Ｔｏｎｅ Ｍｕｌｔｉ−Ｆｒｅｑｕｅｎｃｙ）トーンまたは発せられた単語を用いてオプションを選択するための選択肢が与えられる。音声認識は通常、より複雑なトランザクションを実行するために使用され、アプリケーションのメニュー構造を簡素化する。
【００２１】
ＡＣＤシステム１００は、呼転送モジュール１５０を含むことができる。呼転送モジュール１５０を、一般に、ＡＣＤシステム１００向けの呼転送動作を管理するように配置構成することができる。別々のモジュールとして示したが、呼転送モジュール１５０によって提供される動作、機能またはサービスを、呼制御モジュール１１０の統合された部分として実装できることは理解されよう。実施形態はこの文脈において限定されない。
【００２２】
呼転送は、必要な場所にダイヤルすることにより、ユーザが既存の呼を別の電話または中継台に移動させることを可能にする通信機構である。転送された呼は、通知されるか、または通知されないかのいずれかである。転送された呼が通知される場合、所望の通話相手または内線に、来つつある呼が通知される。これは、一般に、発呼者を保留し所望の通話相手または内線にダイヤルすることで行われる。その後、その通話相手または内線が通知を受け、その通話相手または内線がその呼を受け入れる場合は、その呼がその通話相手または内線に転送される。通知転送に対して一般に使用される他の用語には、拡張転送およびウォーム転送が含まれる。他方では、非通知転送は、来つつある呼を所望の通話相手または内線に通知せずに転送される。この転送は自動的にその電話線に転送される。非通知転送に対して一般に使用される他の用語には、コールド転送、ブラインド転送が含まれる。
【００２３】
双方とも可能であるが、呼制御モジュール１１０とＩＶＲモジュール１２０は、一般に、ＡＣＤシステム１００の自動化された性質を促進するために非通知転送を実行する。従って、ＩＶＲモジュール１２０が発呼者から情報を受け取り、その情報に基づいて呼を所望の通知相手の特定の発呼端末に転送するように呼制御モジュール１１０に要求する場合が生じうる。このため、所望の通話相手が応対できず、転送失敗イベントに至る場合がある。従来の呼システムでは、これにより発呼者が会社の代表番号にリダイヤルし、ＩＶＲモジュール１２０に再接続し、ＩＶＲモジュール１２０との別の対話を行い、同じまたは異なる通話相手に接続してサービスを取得しなければならないこととなりうる。
【００２４】
呼転送の問題は、呼転送動作が首尾よく完了するまでＡＣＤシステム１００の呼制御要素をシグナリング経路内に保つことによって解決されることがある。例えば、ＡＣＤシステム１００は、ＳＩＰ呼の両端に対してユーザ・エージェントとして振舞うためにＢ２ＢＵＡ（ｂａｃｋ−ｔｏ−ｂａｃｋ ｕｓｅｒ ａｇｅｎｔ）を実装することができる。Ｂ２ＢＵＡは転送されている呼の状態を追跡し、呼の転送者（例として転送を開始する通話相手）に任意の変化を通知することができる。しかしながら、Ｂ２ＢＵＡを使用すると、呼制御動作の複雑さが増し、呼転送動作が完了するまでその呼転送動作を監視し追跡するためのリソースを消費し、それにより、他の着呼に利用可能なリソースが減少する。これは、ＡＣＤシステム１００が比較的大量の着呼をサービスする適用例に対しては、特に非効率的でありうる。
【００２５】
これらおよび他の問題を解決するために、ＡＣＤシステム１００は、Ｂ２ＢＵＡソリューションの場合のようにＡＣＤシステム１００が専ら呼転送動作の監視にリソースを使用する必要性を軽減または排除する種々の転送エラー復帰技術を実装することができる。転送者は、呼転送動作が受け入れられた後に、コールレグを終了させることができる。さらに、転送された者は、常に呼に対する完全な制御を維持する。これらおよび他の利点は、例えば、ＴＥＣコンポーネント１３０を用いて実現することができる。
【００２６】
一般に、ＴＥＣコンポーネント１３０を、転送失敗の場合に発呼者とＡＣＤシステム１００が復帰できるようにする種々の転送エラー復帰技術を実装するように配置構成することができる。ＴＥＣコンポーネント１３０は、発呼者とＩＶＲモジュール１２０などの呼システム・リソースの間の対話に関するコンテキスト情報を記録し、記憶することができる。ＴＥＣコンポーネント１３０はまた、コンテキスト識別子と称するコンテキスト情報への参照を含む、ＴＥＣ情報を有するＴＥＣヘッダを生成することができる。次に、ＴＥＣコンポーネント１３０は、転送失敗イベントに自動的に応答する際に使用するために、ＴＥＣ情報を発呼者の発呼端末に呼転送モジュール１５０を介して提供することができる。
【００２７】
ＴＥＣコンポーネント１３０を、発呼者とＩＶＲモジュール１２０などの呼システム・リソースの間の対話に関するコンテキスト情報を記録し、記憶するように構成することができる。本明細書で使用する「コンテキスト情報」という用語は、所与のタスクを実行している間の装置またはシステムの状態または状況に関する任意の情報を指すことができる。一般に、装置またはシステムがタスクを実行するときは常に、装置またはシステムは、リソースを割り当て、そのタスクに対して一般に一意であるデータを生成する。タスクが終了する前に割り込まれた場合は、タスクを、再度最初から開始する必要があるかもしれない。その結果、割り込みの前に行われた作業が全く失われることとなりうる。コンテキスト情報を記録し格納することにより、ある時点でタスクに割り込み、そのタスク全体をリスタートする必要なしに将来の時点で再開することができる。コンテキスト情報を保存することで、装置またはシステムは、タスクが割り込まれてそのタスクに対する作業を再開するときの状態または状況を再生成することができる。この場合、ＴＥＣコンポーネント１３０は、呼転送動作の前に呼セッションに関するコンテキスト情報を記録し記憶することができ、それにより、ＡＣＤシステム１００は、転送失敗の場合に後続の呼セッションに関するコンテキストを再生成することができる。コンテキスト情報の例には、限定ではなく、呼セッションの詳細、クライアント、装置、装置の機能、通話者の間の通信、呼接続、呼セッション、呼履歴、呼転送に関する以前の対象の発呼端末、エラー情報、発呼者の嗜好、発呼者のルール、発呼者の位置、発呼者の識別、生態情報、発呼者の個人情報（例えば、名前、住所、電話番号、等）、媒体の種別、媒体のパラメータ、電話番号の優先順位、キーワード、アプリケーション、アプリケーション・データ、等に関する任意の情報を含めることができる。本実施形態はこの文脈において限定されない。
【００２８】
ＴＥＣコンポーネント１３０を、コンテキスト情報に関するコンテキスト識別子を含むＴＥＣ情報１４４を生成するように配置構成することができる。本明細書で使用する「ＴＥＣ情報」という用語は、転送失敗の場合の転送エラー復帰動作を可能とするのに適した任意の情報を指すことができる。より具体的には、ＴＥＣ情報１４４により、発呼者の発呼端末が、転送失敗イベントに応答して、ＩＶＲモジュール１２０などの呼システム・リソースに自動的に再接続できるようにすることができる。さらに、ＴＥＣ情報１４４はコンテキスト識別子を含むことができ、このコンテキスト識別子により、ＡＣＤシステム１００は、発呼者との以前の呼セッションからコンテキスト情報を取り出し、後続の呼セッションにおける発呼者に関するコンテキストを生成して、以前に実施したデータ収集動作を削減または排除することができる。
【００２９】
一般的な動作では、呼制御モジュール１１０は着呼１０２−１を第１の発呼端末から受信することができる。呼制御モジュール１１０は呼フローを管理し、着呼１０２−１をＩＶＲモジュール１２０などの呼システム・リソースに接続する。これにより、第１の発呼端末とＩＶＲモジュール１２０の間の第１の呼セッションに対する第１の呼接続が確立される。
【００３０】
ＩＶＲモジュール１２０は、音声プロンプトを第１の発呼端末に送信し、第１の発呼端末から操作者の指令を受け取ることによって、第１の呼セッションに対する対話を管理するように動作する。ＩＶＲモジュール１２０は、ＤＮＩＳにダイヤルされる番号に結び付けられたアプリケーションを実行する。アプリケーションの一部として、事前に記録した音声ファイルまたは動的に生成されたＴＴＳ音声により、発呼者が利用可能な様々なオプションが説明される。発呼者には、ＤＴＭＦトーンまたは発せられた単語を用いてオプションを選択するための選択肢が与えられる。音声認識は通常、より複雑なトランザクションを実行するために使用され、アプリケーションのメニュー構造を簡素化する。ＩＶＲモジュール１２０が転送対象の発呼端末を決定するために発呼者から十分な情報を収集すると、ＩＶＲモジュール１２０は転送要求を呼制御モジュール１１０に送信することができる。
【００３１】
第１の発呼端末とＩＶＲモジュール１２０の間の第１の呼セッション中に、ＴＥＣコンポーネント１３０は、ＴＥＣ情報１４４を生成するためのＴＥＣ動作を開始することができる。図１に示した実施形態では、ＴＥＣコンポーネント１３０はコンテキスト生成モジュール１３２とＴＥＣモジュール１４２を備えることができる。
【００３２】
コンテキスト生成モジュール１３２を、第１の発呼端末とＩＶＲモジュール１２０などの呼システム・リソースの間の第１の呼セッションに関するコンテキスト情報１４０−１〜ｎを記録するように配置構成することができる。コンテキスト情報１４０−１〜ｎには、とりわけ、例えば、発呼者に提供された音声プロンプト、およびその音声プロンプトに応答して発呼者によって与えられた応答を含めることができる。コンテキスト情報１４０−１〜ｎには、さらに、アカウント番号、優先度情報、発呼者の嗜好などの発呼者の情報を有する発呼者のレコードまたはプロフィールなど、発呼者に関する情報を含めることができる。これらおよび他種のコンテキスト情報を使用して、呼セッションに関する一般的なコンテキストのスナップショット、特に、ＩＶＲモジュールが転送動作を開始する前に発呼者とＩＶＲモジュール１２０が到達した対話内のポイントのスナップショットを確立することができる。コンテキスト生成モジュール１３２は、対応するコンテキスト識別子１３８−１〜ｍをそれぞれが有するコンテキスト情報１４０−１〜ｎを記憶することができ、コンテキスト識別子１３８−１〜ｍは、一体となってコンテキスト・データベース１３４のコンテキスト・テーブル１３３においてコンテキスト・レコード１３６−１〜ｐを形成する。
【００３３】
ＴＥＣモジュール１４２を、とりわけコンテキスト識別子１３８−１〜ｍを有するＴＥＣ情報１４４を生成するように配置構成することができる。ＴＥＣ情報１４４には、とりわけ、転送エラー・イベント後に参照すべきリソース識別子、転送エラー・イベントを定義するエラー・コード、以前の呼セッションからのコンテキスト情報に関するコンテキスト識別子、等を含めることができる。ＴＥＣモジュール１４２は、ＴＥＣ情報１４４を呼転送モジュール１５０に転送することができる。
【００３４】
呼転送モジュール１５０はＴＥＣ情報を受け取り、転送失敗の場合に使用するためにＴＥＣ情報１４４を第１の発呼端末に送信する。前述のように、ＩＶＲモジュール１２０が転送対象の発呼端末を決定するために十分な情報を発呼者から収集すると、ＩＶＲモジュール１２０は転送要求を呼制御モジュール１１０に送信することができる。呼制御モジュール１１０は、転送要求をＩＶＲモジュール１２０から受け取る。呼制御モジュール１１０は、着呼１０２−１の転送に備えて、転送対象の発呼端末の番号検索などの、様々な呼制御動作を実施することができる。呼制御モジュール１１０は、制御指令を呼転送モジュール１５０に送信する。制御指令には、例えば、第１の発呼端末を第２の発呼端末へ転送する転送命令を含めることができる。呼転送モジュール１５０は、転送命令を呼制御モジュール１１０から受け取り、ＴＥＣ情報１４４をＴＥＣモジュール１４２から受け取り、転送要求ごとに第１の発呼端末を第２の発呼端末に転送する。
【００３５】
呼制御モジュール１５０は転送命令を呼制御モジュール１１０から受け取り、ＴＥＣ情報１４４をＴＥＣモジュール１４２から受け取り、転送メッセージを第１の発呼端末に送信する。幾つかの実施形態では、転送メッセージには、ＳＩＰ参照仕様によって定義されるＲＥＦＥＲメッセージ１０４−１を含めることができる。ＲＥＦＥＲメッセージ１０４−１には、とりわけ、ＴＥＣ情報１４４を含めることができる。具体的には、ＴＥＣ情報１４４には、図２を参照してより詳細に説明するＴＥＣヘッダを含めることができる。
【００３６】
図２は、データ構造２００の一実施形態を示す。データ構造２００は、例えば、ＲＥＦＥＲメッセージ１０４を含むことができる。ＲＥＦＥＲメッセージ１０４は、ＡＣＤシステム１００などの自動呼システムに対する呼を転送するための転送機構を含むことができる。ＲＥＦＥＲメッセージ１０４は、ＩＥＴＦ ＲＦＣ ３２６１によって定義されるＳＩＰメソッドである。ＲＥＦＥＲメッセージ１０４は、Ｒｅｑｕｅｓｔ−ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によって特定される受信者が、リクエスト内で提供されたコンタクト情報を用いて第三者に接続することを示す。Ｒｅｆｅｒ−Ｔｏ ＵＲＩによって特定されるリソースは、そのＵＲＩタイプに対する通常の機構を用いて接続される。例えば、ＵＲＩが、（例えば、ｍｅｔｈｏｄ＝ＩＮＶＩＴＥ ＵＲＩパラメータを用いて）ＩＮＶＩＴＥを示すＳＩＰのＵＲＩである場合は、ＳＩＰのＵＡは、ＳＩＰ標準で定義されたＩＮＶＩＴＥを送信するための通常のルールの全てを用いて新しいＩＮＶＩＴＥを発行するであろう。
【００３７】
図２に示す実施形態では、ＲＥＦＥＲメッセージ１０４は、ヘッダへの参照（Ｒｅｆｅｒ Ｔｏ Ｈｅａｄｅｒ：ＲＴＨ）２２０を含むことができる。ＲＴＨ２２０は、ＳＩＰ標準によって定義されるリクエスト・ヘッダ（ｒｅｑｕｅｓｔ−ｈｅａｄｅｒ）である。ＲＴＨ２２０は、一般に、ＲＥＦＥＲリクエストにおいてのみ現れる。ＲＴＨ２２０は、次のフォーマットに従って参照ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を提供する。
【００３８】
【数１】
【００３９】
ＵＲＬは、リソースを特定することに加えてその主要なアクセス機構またはネットワーク位置を記述することによって、リソースの表現に作用またはその表現を取得するための技法を提供するＵＲＩである。
【００４０】
ＲＴＨ２２０に加えて、ＲＥＦＥＲメッセージ１０４はＴＥＣヘッダ（ＴＣＨ）２３０を含むことができる。ＴＣＨ２３０は、ＴＥＣ情報１４４に対するデータ構造を含むことができる。図２に示した実施形態では、ＴＣＨ２３０は、１つまたは複数のリソース識別子２３２、１つまたは複数のエラー応答コード２３４、および１つまたは複数のコンテキスト識別子１３８−１〜ｍを含むことができる。ＴＣＨ２３０は、転送エラー復帰動作において使用するのに適した他種の情報を含むことができ、本実施形態はこの文脈において限定されない。
【００４１】
リソース識別子２３２は、転送失敗イベントに応答して呼を転送すべきリソースまたは宛先に関するコンタクト情報を表すことができる。コンタクト情報には、電話番号、ネットワーク・アドレス、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、電子メール（ｅｍａｉｌ）アドレス、ＳＩＰアドレス、ＵＲＩ、ＵＲＬ、およびリソースに関する他の任意の一意な識別子など、リソースに関する任意の種類のコンタクト情報を含めることができる。リソースには、転送エラー・イベントの前に呼転送を開始した転送者を含めて、転送エラー復帰動作を扱うのに適した任意のリソースを含めることができる。例えば、リソース識別子２３２は、次のように、ＩＶＲモジュール１２０などの、着呼に関して転送者のＳＩＰアドレスを含むことができる。
＜ｓｉｐ：ａｃｄ＠ｃｏｍｐａｎｙＡ．ｃｏｍ＞
別の例では、リソース識別子２３２は、特に転送エラー復帰動作を扱うために設計された専用呼システム・リソースを含むことができる。
【００４２】
エラー応答コード２３４は、転送エラー復帰動作を自動的に開始する転送エラー・イベントを定義する、構成可能なエラー・ケースまたはエラー・コードのリストを含むことができる。例えば、エラー応答コード２３４は、次のような様々なＳＩＰエラー・コードを含むことができる。
Ｒｅｓｐ−Ｃｏｄｅｓ＝“４ｘｘ，５ｘｘ，６ｘｘ”
本例では、ＴＣＨ２３０は発呼端末に、全ての４００、５００および６００クラスのＳＩＰエラー応答に対して呼をａｃｄ＠ｃｏｍｐａｎｙＡ．ｃｏｍに転送するよう指示するであろう。エラー応答コード２３４は、ＡＣＤシステム１００のユーザによって構成可能である。
【００４３】
コンテキスト識別子１３８−１〜ｍには、ＴＥＣコンポーネント１３０のコンテキスト・データベース１３４に格納したコンテキスト情報に対する１つまたは複数のコンテキスト識別子を含めることができる。コンテキスト識別子１３８−１〜ｍは任意の一意な識別子を含むことができ、その例は次の通りである。
Ｃｏｎｔｅｘｔ＝３ｘＡＢ２５１ｄ９ｅ
コンテキスト識別子１３８−１〜ｍを発呼要求とともに送信して、ＡＣＤシステム１１０との後続の呼セッションを開始することができる。ＡＣＤシステム１１０はコンテキスト識別子１３８−１〜ｍを使用して、外部発呼端末との以前の呼セッションに関するコンテキスト情報を取り出し、その外部発呼端末との後続の呼セッションのために、ＡＣＤシステム１１０の以前の呼セッションのコンテキストを復元することができる。
【００４４】
再度図１を参照すると、発呼側では、第１の発呼端末がＴＥＣ情報１４４を、ＲＥＦＥＲメッセージ１０４−１の一部を含むＴＣＨ２３０の形で、呼転送モジュール１５０から受け取ることができる。第１の発呼端末は、転送失敗イベントを検出するロジックを備えることができ、ＴＣＨ２３０内に含まれるＴＥＣ情報１４４を用いて、第１の発呼端末とＡＣＤシステム１００に関する呼システム・リソースの間の第２の呼セッションを開始することができる。
【００４５】
ＡＣＤシステム１００は、第１の発呼端末とＩＶＲモジュール１２０などの呼システム・リソースの間の第２の呼セッションを確立するための着呼１０２−２を受け取ることができる。コンテキスト生成モジュール１３２はコンテキスト識別子を第１の発呼端末から受け取ることができ、コンテキスト識別子１３８−１〜ｍに対応するコンテキスト情報１４０−１〜ｎをコンテキスト・データベース１３４のコンテキスト・テーブル１３３から取り出すことができる。コンテキスト生成モジュール１３２は、コンテキスト情報１４０−１〜ｎをＩＶＲモジュール１２０に送信することができる。あるいは、ＩＶＲモジュール１２０など、コンテキスト生成モジュール１３２とは異なるＡＣＤシステム１００の他の任意の要素がコンテキスト情報１４０−１〜ｎを取り出してもよい。この場合、第２の呼セッションからのコンテキスト情報を記録し適切なコンテキスト情報１４０−１〜ｎを更新するように、コンテキスト生成モジュール１３２に通知する必要があるかもしれない。
【００４６】
ＩＶＲモジュール１２０は、コンテキスト情報１４０−１〜ｎを受け取り、そのコンテキスト情報１４０−１〜ｎに基づいて、第１の発呼端末に対する後続の処理イベントを決定することができる。例えば、ＩＶＲモジュール１２０は、コンテキスト情報１４０−１〜ｎから、第１の発呼端末からの第１の着呼１０２−１を第２の発呼端末へ転送することが失敗したことを判定することができ、従って、ＩＶＲモジュール１２０は、第２の着呼１０２−２を第１の発呼端末から、第３の発呼端末などの別の内部発呼端末へ転送することを決定することができる。
【００４７】
第１の呼セッションに関して、コンテキスト生成モジュール１３２は、第１の発呼端末とＩＶＲモジュール１２０の間の第２の呼セッションからのコンテキスト情報を記録することができる。コンテキスト生成モジュール１３２は、次いで、第１の呼セッションからのコンテキスト情報１４０−１〜ｎを、第２の呼セッションからのコンテキスト情報で更新することができる。コンテキスト生成モジュール１３２は、更新されたコンテキスト情報１４０−１〜ｎを、第１の呼セッションと同じコンテキスト識別子１３８−１〜ｍを有する適切なコンテキスト・レコード１３６−１〜ｐに格納することができる。
【００４８】
図３は、通信システム３００の一実施形態を示す。種々の実施形態では、通信システム３００を、無線通信システム、有線通信システム、またはその両方の組合せとして実装することができる。無線通信システムとして実装した場合は、通信システム３００は、１つまたは複数のアンテナ、送信機、受信機、送受信機、増幅器、フィルタ、制御ロジックなど、無線通信媒体上で通信するのに適したコンポーネントおよびインタフェースを備えることができる。通信媒体の例には、ＲＦ（ｒａｄｉｏ−ｆｒｅｑｕｅｎｃｙ）スペクトルなど、無線スペクトルの一部を用いて実装した無線共有型媒体を含めることができる。有線通信システムとして実装した場合は、通信システム３００は、Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）アダプタ、Ｉ／Ｏアダプタを対応する優先通信媒体、ＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）ディスク・コントローラ、ビデオ・コントローラ、オーディオ・コントローラ、等と接続するための物理コネクタなどの、有線通信媒体上で通信するのに適したコンポーネントおよびインタフェースを備えることができる。有線通信媒体の例には、有線、ケーブル、金属リード、ＰＣＢ（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄ）、バックプレーン、スイッチ・ファブリック、半導体材料、ツイスト・ペア配線、同軸ケーブル、光ファイバ、等を含めることができる。
【００４９】
図３に示すように、通信システム３００は、複数の発呼端末３１０−１〜ｒを含むことができる。発呼端末３１０−１〜ｒは、パケット交換網３２０を介してＡＣＤシステム１００とＶｏＩＰ呼接続を確立できる任意の物理通信装置または論理通信装置を備えることができる。発呼端末３１０−１〜ｒの例には、限定ではなく、デジタル電話、パケット電話、ＶｏＩＰ電話、データ通信機能付きの携帯電話、コンピュータ、パーソナル・コンピュータ、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、モバイル・コンピュータ、サーバ、ワークステーション、電化製品、ネットワーク機器、等を含めることができる。一実施形態では、例えば、発呼端末３１０−１〜ｒを、ＳＩＰユーザ・エージェントとして実装されたＶｏＩＰ発呼端末として実装してもよい。しかし、本実施形態はこの文脈において限定されない。
【００５０】
第１の発呼端末３１０−１は外部の発呼端末を表すことができ、発呼端末３１０−２〜ｒは、ＡＣＤシステム１００によってサービスされる内部の発呼端末を表すことができる。第１の発呼端末３１０−１は、パケット交換網３２０を介して、ＡＣＤシステム１００との第１の呼接続３３０−１を開始することができる。パケット交換網３２０の例には、インターネットを含めることができる。第１の発呼端末３１０−１の発呼者との対話を通じて、ＡＣＤシステム１００は、呼接続３３０−１を第２の発呼端末３１０−２に転送することを決定でき、それに従ってＴＣＨ２３０を有するＲＥＦＥＲメッセージ１０４を介して第１の発呼端末３１０−１に通知し、呼接続３３０−１を解放する。
【００５１】
呼転送が失敗したと仮定すると、第１の発呼端末３１０−１のＴＥＣモジュール３０２は、転送エラー・イベントを検出し、ＴＣＨ２３０からＴＥＣ情報１４４を参照する。ＴＥＣモジュール３０２は、ＴＥＣ情報１４４を利用してクライアント側の転送呼復帰動作を実施することができる。例えば、ＲＥＦＥＲメッセージ１０４−１のＴＣＨ２３０のリソース識別子２３２を用いて、ＴＥＣモジュール３０２はＡＣＤシステム１００との呼接続を自動的に確立することができる。別の例では、ＴＥＣモジュール３０２は、ＡＣＤシステム１００への接続、会社内の異なる番号に接続、転送エラー復帰動作を終了する、等のユーザ・オプションのリストを提示することができる。これにより、転送された者に対して、転送失敗イベントを扱うための所望の選択肢をプログラム的に選択する機会を提供することができる。
【００５２】
第１の呼接続３３０−１が以前に解放されているので、第１の発呼端末３１０−１はＡＣＤシステム１００との第２の呼接続３３０−２を開始し、コンテキスト識別子１３８−１〜ｍをＡＣＤシステム１００に送信する。ＡＣＤシステム１００のＴＥＣコンポーネント１３０は、コンテキスト識別子１３８−１〜ｍを受け取り、対応するコンテキスト情報１４０−１〜ｎを取り出し、第２の呼接続３３０−２上で通信される第２の呼セッションのために、第１の呼接続３３０−１の上で通信される第１の呼セッションのコンテキストを構築する。再構築したコンテキストに基づいて、ＡＣＤシステム１００は、第１の発呼端末３１０−１を第３の発呼端末３１０−３に転送すると決定することができ、それに従ってＴＣＨ２３０を有するＲＥＦＥＲメッセージ１０４を介して第１の発呼端末３１０−１に通知し、第２の呼接続３３０−２を解放する。これらの転送エラー復帰動作は、第１の発呼端末３１０−１が、転送失敗イベントが発生することなく内部の発呼端末３１０−１〜ｒへの接続に成功するまで、任意数のサイクルを継続することができる。
【００５３】
上述した実施形態に対する動作を、１つまたは複数の論理フローを参照してさらに説明することができる。特に記載がない限り、その代表的な論理フローを、提示した順序で実行する必要はなく、またはどのような特定の順序で実行する必要もないことは理解されよう。さらに、論理フローに関して説明した種々の動作を、逐次的あるいは並列的に実行することができる。論理フローを、所与の１組の設計上および性能上の制約に対して望ましいように、説明した実施形態または代替的な要素の１つまたは複数のハードウェア要素および／またはソフトウェア要素を用いて実装することができる。例えば、論理フローを、論理装置（例えば、汎用目的または特殊目的のコンピュータ）によって実行されるロジック（例えば、コンピュータ・プログラム命令）として実装してもよい。
【００５４】
図４は、論理フロー４００のブロック・フロー図を示す。論理フロー４００は、本明細書で説明した１つまたは複数の実施形態によって実行される動作の一部または全部を代表することができる。
【００５５】
ブロック４０２で、論理フロー４００は、第１の発呼端末との第１の呼セッションに関するコンテキスト情報を記録することができる。例えば、ＴＥＣコンポーネント１３０のコンテキスト生成モジュール１３２は、第１の発呼端末３１０−１からの着呼１０２−１を検出し、または通知を受け、第１の発呼端末３１０−１とＩＶＲモジュール１２０の間の第１の呼セッションに関するコンテキスト情報１４０−ｎを記録するための記録動作を開始することができる。
【００５６】
ブロック４０４で、論理フロー４００は、コンテキスト識別子を有するコンテキスト情報を記憶することができる。例えば、ＴＥＣコンポーネント１３０のコンテキスト生成モジュール１３２は、一意なコンテキスト識別子１３８−１〜ｍを用いて、第１の発呼端末３１０−１との第１の呼セッションから記録されたコンテキスト情報１４０−１〜ｎを記憶することができる。コンテキスト識別子１３８−１〜ｍを使用して、第１の発呼端末３１０−１との将来または以降の呼セッションのためのコンテキスト情報１４０−１〜ｎを取り出すことができる。
【００５７】
ブロック４０６で、論理フロー４００は、コンテキスト識別子を有する転送エラー・コンテキスト情報を生成することができる。例えば、ＴＥＣモジュール１４２は、ＴＣＨ２３０を生成することができる。ＴＥＣモジュール１４２は、コンテキスト識別子１３８−１〜ｍをコンテキスト生成モジュール１３２から直接、または間接的にコンテキスト・データベース１３４を介して受け取り、ＴＣＨ２３０にコンテキスト識別子１３８−１〜ｍを含めることができる。ＴＥＣモジュール１４２は、ＴＣＨ２３０を呼転送モジュール１５０に送信することができる。
【００５８】
ブロック４０８で、論理フロー４００は、転送失敗イベントの場合に使用するために、転送エラー・コンテキスト情報を第１の発呼端末に送信することができる。例えば、呼転送モジュール１５０は、呼制御モジュール１１０からの転送指示を受け取り、ＴＥＣモジュール１４２からＴＣＨを受け取り、ＲＥＦＥＲメッセージ１０４−１を生成することができる。呼転送モジュール１５０は、ＲＥＦＥＲメッセージ１０４−１を第１の発呼端末３１０−１に送信し、着呼１０２−１に対する呼接続を解放することができる。
【００５９】
図５Ａは、第１のメッセージ・フロー５００の一実施形態を示す。メッセージ・フロー５００は通信システム３００の種々の要素の間のメッセージ・フローを表すことができる。図５Ａに示すように、発呼者アリスがＡ社の主番号に発呼し、Ａ社のＡＣＤシステム１００がその呼を受け入れるとする。矢印５０２によって示すＩＮＶＩＴＥメッセージ（例えば、ｍａｉｎ−ｎｕｍｂｅｒ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、アリスは発呼端末３１０−１を使用してパケット交換網３２０を介したＡＣＤシステム１００との第１の呼接続３３０−１を開始することができる。ＡＣＤシステム１００は、ＩＮＶＩＴＥメッセージを受け取り、矢印５０４で示したように２００ ＯＫメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は、矢印５０６で示したようにＡＣＫメッセージを送信し、第１の呼接続３３０−１が確立される。呼接続３３０−１に対するエンド・ポイントは、ＡＣＤシステム１００のＩＶＲモジュール１２０を含むことができる。
【００６０】
第１の発呼端末３１０−１の発呼者との対話を通して、ブロック５０８で、ＩＶＲモジュール１２０は、呼接続３３０−１を第２の発呼端末３１０−２にいるボブに転送することを決定する。それに従って、矢印５１０で示したようにＲＥＦＥＲメッセージ１０４−１を第１の発呼端末３１０−１に送信することによって、ＡＣＤシステム１００は第１の発呼端末３１０−１に通知する。ＲＥＦＥＲメッセージは、発呼端末３１０−２とＴＣＨ２３０に関するリソース識別子を有するＲＴＨ２２０を含むことができる。矢印５１２で示したように、発呼端末３１０−１は、２０２ ＡＣＣＥＰＴＥＤメッセージをＡＣＤシステム１００に送信する。矢印５１４で示したようにＢＹＥメッセージを発呼端末３１０−１に送信することによって、ＡＣＤシステム１００は呼接続３３０−１を解放する。発呼端末３１０−１は、矢印５１６で示したように２００ ＯＫメッセージをＡＣＤシステム１００に送信することによって、呼の解放を承諾する。
【００６１】
発呼端末３１０−１は、矢印５１８で示したようにＩＮＶＩＴＥメッセージ（例えば、ｂｏｂ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、発呼端末３１０−２との新しい呼を開始する。現在ボブが発呼端末３１０−２を用いて通話中であるとする。この場合、発呼端末３１０−２は、矢印５２０で示したように４８６ ＢＵＳＹメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は４８６ ＢＵＳＹメッセージを受け取り、発呼端末３１０−１のＴＥＣモジュール３０２は、４８６ ＢＵＳＹコードとＴＣＨ２３０からのエラー・コードと比較する。それらが一致する場合、発呼端末３１０−１は、発呼端末３１０−２でのボブとの転送失敗イベントを検出する。発呼端末３１０−１は、矢印５２２で示したようにＡＣＫメッセージを発呼端末３１０−２に送信する。
【００６２】
図５Ｂはメッセージ・フロー５００の続きを示す。図５Ｂに示すように、エラー・コード４８６はエラー応答コード２３４の一部であるため、発呼端末３１０−１は、矢印５２２で示すようにコンテキスト識別子１３８−１〜ｍを有する別のＩＮＶＩＴＥメッセージ（例えば、ｍａｉｎ−ｎｕｍｂｅｒ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）をＡＣＤシステム１００へ送信することによって、ＡＣＤシステム１００との第２の呼接続３３０−２を自動的に開始する。矢印５２４で示したように、ＡＣＤシステム１００は、２００ ＯＫメッセージを発呼端末３１０−１に送信する。矢印５２６で示したように、発呼端末３１０−１は、ＡＣＫメッセージをＡＣＤシステム１００に送信する。ブロック５２７で、ＡＣＤシステム１００は、コンテキスト情報を取り出す。取り出したコンテキスト情報により、ＩＶＲモジュール１２０によって提供されたＤＴＭＦベースのメニュー内の位置などの、呼接続３３０−１上の第１の呼セッションに対する元の呼コンテキストを復元することができる。その結果、アリスはＩＶＲモジュール１２０との対話を自動化スクリプトの最初から開始しなければならないことを回避することができる。次に、ブロック５２８で、ＡＣＤシステム１００のＩＶＲモジュール１２０は、ブロック５２８で取り出したコンテキスト情報に基づいて、呼接続３３０−２を第３の発呼端末３１０−３のメアリへ転送する新たな決定を行う。
【００６３】
図５Ａに示されているメッセージ・フロー５００に関して、ＡＣＤシステム１００は、対象の発呼端末３１０−３のメアリへの転送をアリスに通知し、呼接続３３０−２を解放する。これを、矢印５１０、５１２、５１４および５１６のそれぞれに関連して説明されるメッセージと同様である、矢印５３０、５３２、５３４および５３６に関連して説明されるメッセージを用いて実施することができる。注目すべき違いは、発呼端末３１０−２ではなく発呼端末３１０−３に対するリソース識別子を有するＲＴＨ２２０を含むＲＥＦＥＲメッセージ１０４−２が送信され、ＴＣＨ２３０がアップデートされたコンテキスト識別子１３８−１〜ｍを含むことである。
【００６４】
発呼端末３１０−１は、矢印５３８で示したようにＩＮＶＩＴＥメッセージ（例えば、ｍａｒｙ＠ｃｏｍｐａｎｙＡ．ｃｏｍ）を送信することによって、発呼端末３１０−３との新しい呼を開始する。メアリが対応可能であり、その呼に応答するとする。発呼端末３１０−３は、ＩＮＶＩＴＥメッセージを受け取り、矢印５４０で示したように２００ ＯＫメッセージを発呼端末３１０−１に送信する。発呼端末３１０−１は、矢印５４２で示したようにＡＣＫメッセージを送信し、呼接続３３０−３が、アリスの発呼端末３１０−１とメアリの発呼端末３１０−３の間に確立される。
【００６５】
呼転送の完了に成功すると、ＡＣＤシステム１００と発呼端末３１０−１は、他の発呼者または他の呼セッションからのコンテキスト情報に対する場所を空けるためにコンテキスト情報１４４を削除することによって、通常の記録メンテナンスを実行することができる。
【００６６】
代替的な実施形態では、ＡＣＤシステム１００は、第１の発呼端末３１０−１が転送失敗イベントに応答してＡＣＤシステム１００との呼接続を再確立する必要を回避するように、ＴＥＣ情報１４４を生成することができる。例えば、ＴＥＣモジュール１４２は、ＡＣＤシステム１００ではなく別の対象発呼端末のリソース識別子２３２を有するＴＣＨ２３０を生成することができる。第１の呼セッションの間、ＩＶＲモジュール１２０は、処理のために発呼端末３１０−１を転送するための複数の対象発呼端末３１０−２、３１０−３を決定することができる。次に、ＴＥＣモジュール１４２は、ＡＣＤシステム１００ではなく発呼端末３１０−３のためのリソース識別子２３２を有するＴＣＨ２３０を生成することができる。ＴＥＣモジュール３０２は、転送失敗イベントに応答して発呼端末３１０−３に直接接続することができ、それによって、ＡＣＤシステム１００に発呼する必要を回避することができる。
【００６７】
図５Ａと５Ｂは、無人の転送ケースに対するメッセージ・フロー５００を示す。しかし、いくつかの実施形態では、アリスとボブの間の有人の転送を実行するようにＡＣＤシステム１００を配置構成することができる。この場合、ＡＣＤシステム１００は、アリスが使用する発呼端末３１０−１をボブが使用する発呼端末３１０−２に接続する前に、矢印５１０、５１２、５１４、および５１６で示したメッセージ交換の前に発呼端末３１０−２のボブとの接続を確立する。
【００６８】
図６はコンピューティング・システム・アーキテクチャ６１０のブロック図を示す。コンピューティング・システム・アーキテクチャ６１０は、実施形態の一部または全部を実装するのに適したコンピューティング・アーキテクチャを代表することができる。基本的な構成では、コンピューティング・システム・アーキテクチャ６１０は一般に少なくとも１つの処理装置６３２とメモリ６３４を備える。メモリ６３４を、データを記憶できる任意の機械読取可能またはコンピュータ読取可能な媒体で実装することができ、それらには揮発性メモリおよび不揮発性メモリの両方が含まれる。例えば、メモリ６３４には、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ−ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＤＲＡＭ（ｄｙｎａｍｉｃ ＲＡＭ）、ＤＤＲＡＭ（Ｄｏｕｂｌｅ−Ｄａｔａ−Ｒａｔｅ ＤＲＡＭ）、ＳＤＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ＳＲＡＭ（ｓｔａｔｉｃ ＲＡＭ）、ＰＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、フラッシュメモリ、強誘電性ポリマ・メモリなどのポリマ・メモリ、オボニック・メモリ、相変化メモリもしくは強誘電メモリ、ＳＯＮＯＳ（ｓｉｌｉｃｏｎ−ｏｘｉｄｅ−ｎｉｔｒｉｄｅ−ｏｘｉｄｅ−ｓｉｌｉｃｏｎ）メモリ、磁気カードもしくは光学カード、または情報を記憶するのに適した他の任意の種類の媒体を含めることができる。図６に示すように、メモリ６３４は、１つまたは複数のアプリケーション・プログラム６３６−１〜ｓなどの種々のソフトウェア・プログラム、およびそれに付随するデータを記憶することができる。
【００６９】
コンピューティング・システム・アーキテクチャ６１０はまた、その基本構成を超えた付加的な特徴および／または機能を有してもよい。例えば、コンピューティング・システム・アーキテクチャ６１０は取外し可能記憶装置６３８と取外し不能記憶装置６４０を備えてもよく、それらはまた、前述のように種々の機械読取可能媒体またはコンピュータ読取可能媒体を備えることができる。コンピューティング・システム・アーキテクチャ６１０はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、測定装置、センサ、等のような１つまたは複数の入力装置６４４を有してもよい。コンピューティング・システム・アーキテクチャ６１０はまた、ディスプレイ、スピーカ、プリンタ、等のような１つまたは複数の出力装置６４２を備えてもよい。コンピューティング・システム・アーキテクチャ６１０はさらに、コンピューティング・システム・アーキテクチャ６１０が他の装置と通信できるようにする１つまたは複数の通信接続部６４６を備えてもよい。通信接続部６４６には、１つまたは複数の通信インタフェース、ネットワーク・インターフェース、ＮＩＣ（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄｓ）、ラジオ、無線の送信機／受信機（送受信機）、有線および／または無線の通信媒体、物理コネクタ、等のような、種々の標準通信要素を含めることができる。通信媒体は、一般に、コンピュータ読取可能命令、データ構造、プログラム・モジュール、または他のデータを、搬送波または他の伝送機構などの変調データ信号で具現化し、任意の情報伝達媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を有するかまたはその信号内の情報をエンコードするように変化した信号を意味する。限定ではなく例として、通信媒体には有線の通信媒体と無線の通信媒体が含まれる。有線の通信媒体の例として、ワイヤ、ケーブル、金属リード、ＰＣＢ（ｐｒｉｎｔｅｄ ｃｉｒｃｕｉｔ ｂｏａｒｄｓ）、バックプレーン、スイッチ・ファブリック、半導体材料、ツイスト・ペア線、同軸ケーブル、光ファイバ、伝播信号、等を含めることができる。無線通信媒体の例として、音響、ＲＦ（ｒａｄｉｏ−ｆｒｅｑｕｅｎｃｙ）スペクトル、赤外線および他の無線の媒体を含むことができる。本明細書で使用される機械読取可能媒体およびコンピュータ読取可能媒体という用語は、記憶媒体と通信媒体の両方を含むことを意味している。
【００７０】
図７は、論理フロー４００を含む、種々の実施形態に対するロジックを記憶するのに適した製品７００の図を示す。示したように、製品７００は、ロジック７０４を記憶する記憶媒体７０２を備えることができる。記憶媒体７０２の例として、揮発性メモリまたは不揮発性メモリ、取外し可能メモリまたは取外し不能メモリ、消去可能メモリまたは消去不納メモリ、書込可能メモリまたは書込不能メモリ、等を含む、電子データを記憶可能な１つまたは複数の種類のコンピュータ読込可能な記憶媒体を含めることができる。ロジック７０４の例として、ソフトウェア・コンポーネント、プログラム、アプリケーション、コンピュータ・プログラム、アプリケーション・プログラム、システム・プログラム、マシン・プログラム、オペレーティング・システム・ソフトウェア、ミドルウェア、ファームウェア、ソフトウェア・モジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェア・インタフェース、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）、命令セット、計算コード、コンピュータ・コード、コード・セグメント、コンピュータ・コード・セグメント、ワード、値、シンボル、またはそれらの任意の組合せのような、種々のソフトウェア要素を含めることができる。
【００７１】
一実施形態では、例えば、製品７００および／またはコンピュータ読取可能な記憶媒体７０２は、コンピュータによる実行時に上述の実施形態に従う方法および／または動作をコンピュータに実施させる実行可能なコンピュータ・プログラム命令を備えたロジック７０４を記憶することができる。実行可能なコンピュータ・プログラム命令は、ソース・コード、コンパイル済みコード、解釈されたコード、実行可能コード、静的コード、動的コード、等のような、任意の適切な種類のコードを含むことができる。実行可能なコンピュータ・プログラム命令を、コンピュータに一定の機能を実施するよう指令するために、事前に定義されたコンピュータ言語、方法または構文に従って実装することができる。命令を、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＢＡＳＩＣ、Ｐｅｒｌ、Ｍａｔｌａｂ、Ｐａｓｃａｌ、Ｖｉｕａｌ ＢＡＳＩＣ、アセンブリ言語、等のような、任意の適切な、高レベルなプログラミング言語、低レベルなプログラミング言語、オブジェクト指向プログラミング言語、ビジュアル・プログラミング言語、コンパイル型プログラミング言語および／またはインタプリタプログラミング言語を用いて実装することができる。
【００７２】
種々の実施形態を、ハードウェア要素、ソフトウェア要素、またはその両方の組合せを用いて実装してもよい。ハードウェア要素の例として、論理装置に対して上で提供した例のいずれかを含めることができ、さらに、マイクロプロセッサ、回路、回路素子（例えば、トランジスタ、レジスタ、コンデンサ、インダクタ、等）、集積回路、論理ゲート、レジスタ、半導体装置、チップ、マイクロチップ、チップ・セット、等をさらに含めることができる。ソフトウェア要素の例として、ソフトウェア・コンポーネント、プログラム、アプリケーション、コンピュータ・プログラム、アプリケーション・プログラム、システム・プログラム、マシン・プログラム、オペレーティング・システム・ソフトウェア、ミドルウェア、ファームウェア、ソフトウェア・モジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェア・インタフェース、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）、命令セット、計算コード、コンピュータ・コード、コード・セグメント、コンピュータ・コード・セグメント、ワード、値、シンボル、またはそれらの任意の組合せを含めることができる。実施形態がハードウェア要素および／またはソフトウェア要素を用いて実装されるかどうかは、所与の実装形態に望ましいように、所望の計算速度、電力レベル、耐熱性、処理サイクル予算、入力データ速度、出力データ速度、メモリ・リソース、データ・バス速度、および他の設計上または性能上の制約など、任意数の要因に従って様々に決定することができる。
【００７３】
幾つかの実施形態を、「結合」および「接続」という表現をそれらの派生語とともに用いて説明することができる。これらの用語は、必ずしも互いに対する同義語として意図されているわけではない。例えば、幾つかの実施形態を、複数の要素が互いに直接物理的または電気的に接触していることを示すために「接続」および／または「結合」という用語を用いて説明することができる。しかし「結合」という用語は、複数の要素が互いに直接接触していないが依然として協調または相互作用していることを意味することもできる。
【００７４】
技術的な開示事項の本質を読者が迅速に確認できるようにする要約を要求する米国特許法施行規則§１．７２（ｂ）に従って要約が提供されていることを強調しておく。要約は、それが各請求項の範囲または意味を解釈または限定するために使用されないという理解のもとに提示されている。さらに、上述の発明を実施するための形態では、開示を分かり易くするために様々な特徴が単一の実施形態に纏められていることが分かる。この開示方法は、クレームされた実施形態には各請求項で明示的に示したよりも多くの特徴が必要であるという意図を反映するものと解釈されるべきではない。そうではなく、添付の特許請求の範囲が示すように、本発明の主題は、単一の開示された実施形態の全特徴よりも少ない特徴に存する。したがって、添付の特許請求の範囲は本明細書において発明を実施するための形態に組み入れられ、各請求項は別々の実施形態に基づく。添付の特許請求の範囲では、「ｉｎｃｌｕｄｉｎｇ」および「ｉｎ ｗｈｉｃｈ」という用語は、それぞれ「ｃｏｍｐｒｉｓｉｎｇ」および「ｗｈｅｒｅｉｎ」という用語の平易な英語の同義語として使用されている。さらに、「第１の」、「第２の」、「第３の」、等の用語は、ラベルとして用いられているにすぎず、それらの対象に数的な要件を課すことを意図するものではない。
【００７５】
主題を構造上の特徴および／または方法論的動作に固有な言葉で説明したが、添付の特許請求の範囲で定義した主題は上述の固有な特徴または動作に必ずしも限定されないことは理解されよう。そうではなく、上述の固有な特徴および動作は特許請求の範囲を実装する形態の例として開示されている。
【特許請求の範囲】
【請求項１】
第１の発呼端末との第１の呼セッションに関するコンテキスト情報を記録するステップ（４０２）と、
前記コンテキスト情報をコンテキスト識別子とともに格納するステップ（４０４）と、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報を生成するステップ（４０６）と、
転送失敗イベントの場合に使用するために、前記転送エラー・コンテキスト情報を前記第１の発呼端末へ送信するステップ（４０８）と
を含むことを特徴とする方法。
【請求項２】
前記転送エラー・コンテキスト情報が、リソース識別子、１組のエラー・コード、および前記コンテキスト識別子を有する第１の転送エラー・コンテキスト・ヘッダを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の発呼端末を第２の発呼端末に転送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記第１の発呼端末が、転送失敗イベントを検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の発呼端末との第２の呼セッションを確立するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の発呼端末から前記コンテキスト識別子を受け取るステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記コンテキスト識別子に対応する前記コンテキスト情報を取り出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記コンテキスト情報に基づいて、前記第１の発呼端末に対する後続の処理イベントを決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記コンテキスト情報に基づいて、前記第１の発呼端末を第３の発呼端末に転送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１の呼セッションに関する前記コンテキスト情報を、前記第２の呼セッションからのコンテキスト情報で更新するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
システムに
発呼端末との呼セッションに関するコンテキスト情報を記録し、
前記コンテキスト情報をコンテキスト識別子とともに格納し、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報を生成し、
転送失敗イベントにおいて使用するために、前記転送エラー・コンテキスト情報を前記発呼端末に送信し、
前記発呼端末を別の発呼端末に転送すること
を実行させるための命令を含む記憶媒体を備えたことを特徴とする製品。
【請求項１２】
前記システムに、
前記発呼端末との後続の呼セッションを確立し、
前記発呼端末から前記コンテキスト識別子を受け取り、
前記コンテキスト識別子に対応する前記コンテキスト情報を取り出し、
前記コンテキスト情報に基づいて、前記発呼端末に対する後続の処理イベントを決定すること
を実行させる命令をさらに含むことを特徴とする請求項１１に記載の製品。
【請求項１３】
前記システムに、前記コンテキスト情報を前記後続の呼セッションからのコンテキスト情報で更新することを事項させる命令をさらに含むことを特徴とする請求項１１に記載の製品。
【請求項１４】
第１の発呼端末（３１０−１）と呼システム・リソースの間の第１の呼セッション（２０２−１）に関するコンテキスト情報（１４０）を記録し、前記コンテキスト情報をコンテキスト識別子（１３８）とともにコンテキスト・テーブル（１３３）に格納するように動作するコンテキスト生成モジュール（１３２）と、
前記コンテキスト生成モジュールに接続するための転送エラー・コンテキスト・モジュール（１４２）と、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報（１４４）を生成するように動作する前記転送エラー・コンテキスト・モジュールと、
前記転送エラー・コンテキスト・モジュールに接続され、転送失敗イベントの場合に使用するために前記転送エラー・コンテキスト情報を前記第１の発呼端末に送信するように動作する呼転送モジュール（１５０）と
を備えたことを特徴とするシステム。
【請求項１５】
前記転送エラー・コンテキスト・モジュールが、リソース識別子（２３２）、１組のエラー・コード（２３４）および前記コンテキスト識別子を有する第１の転送エラー・コンテキスト・ヘッダ（２３０）を含む転送エラー・コンテキスト情報を生成するように動作することを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記第１の発呼端末に音声プロンプトを送信し、前記第１の発呼端末から操作者の指令を受け取ることによって、第１の呼セッションに対する対話を管理するように動作する、前記呼システム・リソースとしての双方向音声応答モジュール（１２０）と、
前記双方向音声応答モジュールと前記呼転送モジュールに接続され、前記双方向音声応答モジュールから転送要求を受け取り、前記第１の発呼端末を第２の発呼端末に転送するという制御指令を前記呼転送モジュールに送信するように動作する呼制御モジュール（１１０）と、
前記第１の発呼端末を第２の発呼端末（３１０−２）に転送するように動作する前記呼転送モジュールと
を備えたことを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記第１の発呼端末が、前記呼転送モジュールから前記転送エラー・コンテキスト情報を受け取り、転送失敗イベントを検出し、前記転送エラー・コンテキスト情報を用いて前記第１の発呼端末と前記呼システム・リソースの間で第２の呼セッション（１０２−２）を開始することを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記コンテキスト生成モジュールが、前記コンテキスト識別子を前記第１の発呼端末から受け取り、前記コンテキスト識別子に対応する前記コンテキスト情報を前記コンテキスト・テーブルから取り出し、前記コンテキスト情報を前記双方向音声応答モジュールに送信することを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記双方向音声応答モジュールが、前記コンテキスト情報を受け取り、前記コンテキスト情報に基づいて、前記第１の発呼端末に対する後続の処理イベントを決定することを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記コンテキスト生成モジュールが、前記第１の呼セッションに関する前記コンテキスト情報を前記第２の呼セッションからのコンテキスト情報で更新することを特徴とする請求項１９に記載のシステム。
【請求項１】
第１の発呼端末との第１の呼セッションに関するコンテキスト情報を記録するステップ（４０２）と、
前記コンテキスト情報をコンテキスト識別子とともに格納するステップ（４０４）と、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報を生成するステップ（４０６）と、
転送失敗イベントの場合に使用するために、前記転送エラー・コンテキスト情報を前記第１の発呼端末へ送信するステップ（４０８）と
を含むことを特徴とする方法。
【請求項２】
前記転送エラー・コンテキスト情報が、リソース識別子、１組のエラー・コード、および前記コンテキスト識別子を有する第１の転送エラー・コンテキスト・ヘッダを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の発呼端末を第２の発呼端末に転送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記第１の発呼端末が、転送失敗イベントを検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の発呼端末との第２の呼セッションを確立するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の発呼端末から前記コンテキスト識別子を受け取るステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記コンテキスト識別子に対応する前記コンテキスト情報を取り出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記コンテキスト情報に基づいて、前記第１の発呼端末に対する後続の処理イベントを決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記コンテキスト情報に基づいて、前記第１の発呼端末を第３の発呼端末に転送するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１の呼セッションに関する前記コンテキスト情報を、前記第２の呼セッションからのコンテキスト情報で更新するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
システムに
発呼端末との呼セッションに関するコンテキスト情報を記録し、
前記コンテキスト情報をコンテキスト識別子とともに格納し、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報を生成し、
転送失敗イベントにおいて使用するために、前記転送エラー・コンテキスト情報を前記発呼端末に送信し、
前記発呼端末を別の発呼端末に転送すること
を実行させるための命令を含む記憶媒体を備えたことを特徴とする製品。
【請求項１２】
前記システムに、
前記発呼端末との後続の呼セッションを確立し、
前記発呼端末から前記コンテキスト識別子を受け取り、
前記コンテキスト識別子に対応する前記コンテキスト情報を取り出し、
前記コンテキスト情報に基づいて、前記発呼端末に対する後続の処理イベントを決定すること
を実行させる命令をさらに含むことを特徴とする請求項１１に記載の製品。
【請求項１３】
前記システムに、前記コンテキスト情報を前記後続の呼セッションからのコンテキスト情報で更新することを事項させる命令をさらに含むことを特徴とする請求項１１に記載の製品。
【請求項１４】
第１の発呼端末（３１０−１）と呼システム・リソースの間の第１の呼セッション（２０２−１）に関するコンテキスト情報（１４０）を記録し、前記コンテキスト情報をコンテキスト識別子（１３８）とともにコンテキスト・テーブル（１３３）に格納するように動作するコンテキスト生成モジュール（１３２）と、
前記コンテキスト生成モジュールに接続するための転送エラー・コンテキスト・モジュール（１４２）と、
前記コンテキスト識別子を有する転送エラー・コンテキスト情報（１４４）を生成するように動作する前記転送エラー・コンテキスト・モジュールと、
前記転送エラー・コンテキスト・モジュールに接続され、転送失敗イベントの場合に使用するために前記転送エラー・コンテキスト情報を前記第１の発呼端末に送信するように動作する呼転送モジュール（１５０）と
を備えたことを特徴とするシステム。
【請求項１５】
前記転送エラー・コンテキスト・モジュールが、リソース識別子（２３２）、１組のエラー・コード（２３４）および前記コンテキスト識別子を有する第１の転送エラー・コンテキスト・ヘッダ（２３０）を含む転送エラー・コンテキスト情報を生成するように動作することを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記第１の発呼端末に音声プロンプトを送信し、前記第１の発呼端末から操作者の指令を受け取ることによって、第１の呼セッションに対する対話を管理するように動作する、前記呼システム・リソースとしての双方向音声応答モジュール（１２０）と、
前記双方向音声応答モジュールと前記呼転送モジュールに接続され、前記双方向音声応答モジュールから転送要求を受け取り、前記第１の発呼端末を第２の発呼端末に転送するという制御指令を前記呼転送モジュールに送信するように動作する呼制御モジュール（１１０）と、
前記第１の発呼端末を第２の発呼端末（３１０−２）に転送するように動作する前記呼転送モジュールと
を備えたことを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記第１の発呼端末が、前記呼転送モジュールから前記転送エラー・コンテキスト情報を受け取り、転送失敗イベントを検出し、前記転送エラー・コンテキスト情報を用いて前記第１の発呼端末と前記呼システム・リソースの間で第２の呼セッション（１０２−２）を開始することを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記コンテキスト生成モジュールが、前記コンテキスト識別子を前記第１の発呼端末から受け取り、前記コンテキスト識別子に対応する前記コンテキスト情報を前記コンテキスト・テーブルから取り出し、前記コンテキスト情報を前記双方向音声応答モジュールに送信することを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記双方向音声応答モジュールが、前記コンテキスト情報を受け取り、前記コンテキスト情報に基づいて、前記第１の発呼端末に対する後続の処理イベントを決定することを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記コンテキスト生成モジュールが、前記第１の呼セッションに関する前記コンテキスト情報を前記第２の呼セッションからのコンテキスト情報で更新することを特徴とする請求項１９に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【公表番号】特表２０１１−５１１５９９（Ｐ２０１１−５１１５９９Ａ）
【公表日】平成２３年４月７日（２０１１．４．７）
【国際特許分類】
【出願番号】特願２０１０−５４５９２４（Ｐ２０１０−５４５９２４）
【出願日】平成２１年１月１９日（２００９．１．１９）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３１３７０
【国際公開番号】ＷＯ２００９／０９９７４６
【国際公開日】平成２１年８月１３日（２００９．８．１３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２３年４月７日（２０１１．４．７）
【国際特許分類】
【出願日】平成２１年１月１９日（２００９．１．１９）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３１３７０
【国際公開番号】ＷＯ２００９／０９９７４６
【国際公開日】平成２１年８月１３日（２００９．８．１３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]