JP3813873B2 - 複数のプラットホーム上に資源を有する呼出し処理システム - Google Patents

Description

【０００１】
（技術分野）
本発明は音声処理システムに関し、より特定的には、ある呼出しに関して複数のプラットホームからポーリングされた資源の最新の可用性情報に基づいて、１つまたは複数のサーバーがその呼出しの処理のために必要な資源を割当てることを可能にした改善された呼出し処理アーキテクチャに関する。
【０００２】
（従来の技術）
音声処理システムは、今日の社会において一般化されてきている。これらのシステムは、典型的に、コンピュータ化された統合音声応答（ＩＶＲ）システムへの電話発呼者のダイアル呼出しを含む。遠隔ユーザダイアルインとコンピュータ化システムとの間の対話は広範に変化し、アプリケーションに特化されている。これらのシステムの典型例は、ユーザが資金を勘定間で振替え、勘定収支を確認できる銀行業務システム、クレジットカード会社システムを含む。
【０００３】
近年、これらの音声処理システムと、ファクシミリ、ｅメール、その他の機能とを併合することも一般的になってきている。このような例の１つは、ファックス・オン・デマンドと呼ばれるものである。ファックス・オン・デマンドシステムでは、遠隔ユーザがコンピュータにダイアルインし、彼の電話機のキーパッドを通して特定のアイテムまたは製品番号に対応する数字を入力する。更に、タッチトーンキーパッドを通してファクシミリ番号を入力することができ、この番号はこのシステムによって翻訳される。次いでファックス・オン・デマンドシステムは、特定のアイテムまたは製品に関するドキュメンテーションを、指定された遠隔電話機番号に位置するファクシミリマシンへ伝送する。
【０００４】
多くの近代的な音声、または呼出し処理システムの開発、及び複雑な本質を見込んで、これらの音声処理システムを複数の異なるクライアントアプリケーションから構成することが標準になってきている。音声処理アプリケーションは、ファックス・オン・デマンド、音声メールなどを含むことができるが、これらは全てローカルエリアネットワーク、または他のこのような手段を介して相互接続される。
【０００５】
音声処理資源を呼出し間で柔軟に使用することも、明確に標準化されてきている。例えば、典型的な音声処理資源は、ＤＴＭＦキーパッドを介して入力された数字を検出するトーン検出器、電話回線からのエコーを濾波するエコーキャンセラー、遠隔ユーザが音声を介してコマンドを入力できるようにする音声認識ソフトウェア等のようなアイテムを含む。
【０００６】
これらのシステムに伴う１つの問題は、音声処理アプリケーション並びに資源の設計及び実施が広範に変化し得ることである。複数の各ベンダーが彼等のシステムを別々に実現しているために、これらのアイテムを一緒に動作させることは困難である。更に、通常は、要求される呼出し処理機能の全てを実現するために単一のプラットホーム上に１組の回路基板が存在しているので、これらのシステムは極めて柔軟性に欠ける。プラットホーム上の資源が使用中であると、呼出しを単純に処理することができなくなり、ブロックされる。
【０００７】
他の問題は、サーバー上の主機能成分と、別のサーバー上のそのスタンバイ機能成分との間をシャドウにすることによってサーバーレベルにおける障害許容力を達成するために、冗長サーバーを使用することからもたらされる。両サーバーは、ある時間間隔で実行される同期プロセスによって、複数のプラットホーム上の要求される資源の可用性情報の同じ記録を保持するので、スタンバイ機能成分は、主機能が動作を停止した時にそれまでに主機能が遂行していたタスクを引継ぐことができる。しかしながら、同期は常にある時間間隔で実施されるから、もし最後の同期の後に呼出しがその要求したサービスを変化させていれば、スタンバイ成分の記録は時代遅れになり得る。
【０００８】
以上に説明したように、多くの異なるベンダーの資源を、さまざまに異なる構成で最適に使用することができるような、より柔軟で、且つ構成可能な音声処理システムに対する要望が当分野に存在している。システムは、音声処理アプリケーションを実現するために使用される異なる型の資源（トーン検出器、信号発生器等）の位置には無関係に、アプリケーションが動作できるようにすべきである。更に、システムは、サーバー上の機能成分が動作の開始を要求された場合には何時でも、要求される資源の可用性に関する最新の情報に基づいて資源を選択できるようにもすべきである。
【０００９】
（発明の概要）
従来技術の上述した、及び他の問題は、より柔軟にユーザが構成可能な、且つより大きい容量の多重プラットホーム音声処理システムに関連する本発明によって解消され、技術的進歩が達成される。本発明によれば、複数の呼出し処理資源は種々の回路カード（即ち、音声処理カード）上に配列される。複数のこれらのカードは、特定の音声処理プラットホーム内に設置される。
【００１０】
多分異なるコンピュータ上で走る複数の音声処理アプリケーションは、１つまたはそれ以上のＣＴサーバーと通信する。これらのＣＴサーバーは、異なる音声処理資源の全てに問合わせ、特定の呼出しを処理するために必要な資源を構築する。資源は、異なるベンダーから、同一のまたは異なる音声処理基板から、同一のまたは異なる音声処理プラットホームからであることができ、また如何なる特定の呼出しの持続時間中にも変化させることができる。音声処理資源の構成全体は音声処理アプリケーションから絶縁され、該アプリケーションからは見えない。その結果、特定の呼出しの処理のために割当てられる音声処理資源が同じ位置から割当てられても、または異なる位置から割当てられても、アプリケーションは同一の手法で動作することができる。
【００１１】
各サーバーは、ポーリングソフトウェア及び割当てソフトウェアを含む。各呼出し毎に、ポーリングソフトウェアは、その呼出しを処理するために必要な資源の可用性に関する情報をプラットホームからポーリングし、割当てソフトウェアは、ポーリングソフトウェアによってポーリングされた情報に基づいて資源を割当てる。各ＣＴサーバーは、呼出しに特定のそれぞれの機能を遂行するための複数の機能成分を更に有している。
【００１２】
機能成分は、主機能成分と、それらのカウンターパートであるスタンバイ機能成分とからなり、各スタンバイ機能成分はそのカウンターパートである主機能成分が動作を停止するまでシャドウであり続ける。サーバーレベルにおけるこのような障害許容力は、主機能成分とスタンバイ機能成分との間をシャドウにすることによって達成される。主機能成分が動作を停止すると、そのカウンターパートであるスタンバイ成分を構成しているサーバー上のポーリングソフトウェアが走り、必要な資源の可用性情報についてプラットホームをポーリングする。このサーバー上を割当てソフトウェアが走り、新たにポーリングされた可用性情報に基づいてそのスタンバイ成分のために資源を割当てる。スタンバイ成分が動作し始め、停止した主成分がそれまでに遂行していたタスクを引継ぐ。
【００１３】
（実施の形態）
図１は、本発明による実施の形態の機能図の例である。図１の配列は、複数のクライアントパーソナルコンピュータをベースとするシステム２２０−２２４を含み、これらは全てネットワーク２２６を介して接続され、ＣＴサーバー２０１−２０３と通信する。ＰＣをベースとするシステムは、システム毎に大幅に変化する種々の音声処理及び呼出しセンターアプリケーションを走らせる。これらの各システムが使用する特定の技術は、本発明にとってクリティカルではない。
【００１４】
更に、音声処理プラットホーム２０８−２１２は、ネットワーク及び標準Ｓ．３００または他の型のプロトコルを介してＣＴサーバー２０１及び２０２と通信する。プラットホーム２０８−２１２は、音声処理品質を改善するために、ＡＴＭスイッチ２１４または他のスイッチ配列を介して互いに相互接続することもできる。
【００１５】
ポーリングソフトウェア及び割当てソフトウェアは、各ＣＴサーバー２０１−２０３上で走る。各ＣＴサーバーは、電話呼出しを処理するためにそれぞれの機能を遂行する機能成分を有する複数のプロセッサをも含んでいる。若干の機能成分を主機能成分と称し、他の機能成分をそれぞれの主機能成分に対応するスタンバイ機能成分と呼ぶ。各スタンバイ機能成分は、そのカウンターパートである主機能成分が動作またはワークを適切に停止するまでシャドウであり続ける。サーバーレベルにおけるこのような障害許容力は、主機能成分とそのスタンバイ機能成分との間をシャドウにすることによって達成される。
【００１６】
プロセッサまたはサーバー上の機能成分の配列は本発明にとってクリティカルではないことを理解されたい。例えば、ある配列では、各プロセッサは１つの機能成分（主またはスタンバイ機能成分の何れか）だけを含むことができる。別の配列では、若干のプロセッサが主成分及びスタンバイ成分の両方を含むことができる。サーバーは、主成分またはスタンバイ成分の何れかだけを含むことも、または若干の主成分及び若干のスタンバイ成分の両方を含むこともできる。何れの場合も、主成分及びそのスタンバイ成分が同一プロセッサまたは同一サーバー上に含まれていない方が有利であることは明白である。
【００１７】
図１には３つのＣＴサーバーだけを示してあるが、ＣＴサーバーの数は本発明にとってクリティカルではない。更に、各主機能成分が、カウンターパートであるスタンバイ機能成分を有している必要はないが、少なくとも重要な機能を遂行する主成分は、それらのスタンバイカウンターパートを有していることが好ましい。
【００１８】
動作を説明する。呼出しは公衆交換電話回線網（ＰＳＴＮ）２５０を介して遠隔ユーザから到着し、呼出し処理プラットホーム２０８−２１２の１つを通して受信される。ＣＴサーバー２０１−２０３は呼出しを受信し、適切なアプリケーション２２０−２２４をその呼出しに接続する。次いでＣＴサーバーは、アプリケーションから受信したメッセージに応答して呼出しを解析し、特定の呼出しを処理するのに必要な特定の資源のグループを確かめる。呼出し及び／またはアプリケーションに依存して、これらの資源は、トーン発生器、スピーチ認識アルゴリズム、エコーキャンセラー、または特定の呼出しの種々の面を処理するための他のさまざまな可能性のある資源のようなアイテムを含むことができる。資源グループのアセンブリング、変更、及びディスアセンブリングの詳細に関しては、米国特許第5,608,791号を参照されたい。
【００１９】
ＣＴサーバー２０１−２０３は、特定の到着呼出し及びアプリケーションに基づいて、その呼出しを処理するためにはどの特定の資源型が必要であるかを決定する。即ち、サーバー２０１−２０３上でポーリングソフトウェアが走り、プラットホームから必要な資源グループの可用性をポーリングする。サーバ２０１−２０３上の割当てソフトウェアが走り、ポーリングソフトウェアによってポーリングされた可用性情報を用いて資源を選択し、それらを論理グループに構成し、これらの呼出しをこれらの資源によって処理できるようにする。これらの各資源はＳ．３００標準プロトコルを介してＣＴサーバー２０１−２０３と通信するので、資源は異なるベンダーからのものであることができ、しかも単一の呼出しを処理することができる。更に、アプリケーションは、使用される特定の資源も、及びこれらの資源が同一の基板上に、プラットホーム上に、または互いに他方から隔れて配置されているのか否かも知っていない。
【００２０】
ポーリングソフトウェアは、それが、第１のプラットホームをポーリングして利用可能な必要資源のリストを入手し、次いで第２のプラットホームをポーリングして第１のプラットホーム上では調達できなかった残余の必要資源をチェックし、次いで次のプラットホームをチェックする等々の順序で、必要な資源の全てが見出されるまでプラットホームをポーリングして行く。
【００２１】
ポーリングソフトウェアは、他の如何なる所定の最適順序でポーリングすることもできる。例えば、ポーリングソフトウェアは、各プラットホーム上の必要資源の全ての可用性をポーリングし、あるプラットホームが全ての資源を含んでいることを見出した場合には停止することができる。
【００２２】
資源を割当てることを試みるために、優先順位スキームが使用される。例えば、もし全ての資源が同一基板上に存在しなければ、割当ては、可能な限り多くの資源を割当てることを試みることができる。ＣＴサーバー２０１−２０３上のポーリングソフトウェアは異なる資源の全てのリストと、それらが何処に位置しているかとを入手しているから、これは最初に試みることができる。もし資源が同一基板上で調達できなければ、割当てソフトウェアはそれらを同一プラットホーム上で、そして最終的には、必要な場合に限って、異なるプラットホーム上で探すことを試みる。
【００２３】
資源を割当てるための優先順位スキームを決定する上で、多くの要因が考慮される。これらの要因は、資源の位置、トラフィックパターン、若干の資源の払底等を含むことができる。
【００２４】
もし主機能成分（例えば、サーバー２０１上の）が動作を停止し、そのシャドウにされているスタンバイ機能成分（例えば、サーバー２０２上の）が動作し始めれば、サーバー２０２上のポーリングソフトウェアが走って、必要な資源の可用性情報をそれらのプラットホームからポーリングする。従って、可用性情報またはサーバー２０２上のこのスタンバイ成分に提供される資源は、サーバー２０１のそれらには無関係であり、従って、サーバー２０２上のスタンバイ成分が動作し始めた場合には常に更新されることになる。資源の可用性情報に関して、サーバー２０１と２０２との間に同期は遂行されないか、または必要としない。
【００２５】
特定の呼出し中に新しいサービスが要求されたために、その呼出しを処理するために必要な資源のグループが変化した場合には、この新サービスを遂行する関連主機能成分を含んでいるサーバー上のポーリングソフトウェアが再度走り、新たに必要とされる資源の可用性情報をプラットホームからポーリングする。ポーリングソフトウェアは、新たに追加される資源の可用性だけをチェックすることも、または新しい呼出しを受信した時と同一の手法で全ての必要資源を再度調べることもできる。
【００２６】
以上に、本発明の好ましい実施の形態を説明した。当業者ならば、他のさまざまな変更及び追加は明白であろう。これらの変更は、特許請求の範囲によってカバーされることを意図している。
【図面の簡単な説明】
【図１】 本発明の実施の形態の概念的ブロック図である。

Claims (22)

1. 公衆交換電話回線網へ接続するための音声処理システムであって、
   音声処理アプリケーションを含む複数のクライアントコンピュータと、
   １つまたはそれ以上の回路基板上の複数の音声処理資源を各々が含む複数のプラットホームと、
   特定の電話呼出しを処理するためにはどの資源セットが必要であるかを決定するための、上記クライアントコンピュータ及び上記プラットホームへインタフェースする複数のプロセッサを各々が有する１つまたはそれ以上のコンピュータ電話サーバーと、
   上記プロセッサ上に収容され、上記呼出しを処理するために必要なそれぞれの機能を遂行するための、主機能成分及びそのカウンターパートであるスタンバイ機能成分からなる複数の機能成分と、
   を備え、上記スタンバイ機能成分は、そのカウンターパートである上記主機能成分が動作を停止して上記カウンターパート主機能成分の代わりに動作するようになるまでシャドウであり続け、
   上記システムは更に、
   上記サーバー上で走り、上記特定の電話呼出しを処理するために必要な上記資源セットの可用性に関する情報を上記プラットホームからポーリングするポーリングソフトウェアと、
   上記サーバー上で走り、上記ポーリングソフトウェアからの上記可用性情報に基づいて、上記プラットホームと同じ、または異なるプラットホームの何れかから上記資源セットを割当てる割当てソフトウェアと、
   を備え、
   上記呼出し中に、あるサーバー上で上記呼出しを処理するために必要なその機能を新しい機能成分が遂行するように動作し始めると、上記サーバー上の上記ポーリングソフトウェアが走るようになっている、
   ことを特徴とする音声処理システム。
2. 上記ポーリングソフトウェアは、上記必要な資源の全ての可用性を上記複数の各プラットホームからポーリングするように構成されていることを特徴とする請求項１に記載のシステム。
3. 上記ポーリングソフトウェアは、上記呼出しを処理するために必要な上記資源の全てを含んでいる１つのプラットホームが見出されると、ポーリングを停止するように構成されていることを特徴とする請求項２に記載のシステム。
4. 上記ポーリングソフトウェアは、それが、上記必要な資源の全ての可用性に関して第１のプラットホームをポーリングし、次いで上記第１のプラットホーム上では調達できなかった残余の資源の可用性に関して第２のプラットホームをポーリングする等々の順序で、上記必要な資源の全てを見出すまでプラットホームをポーリングして行くように構成されていることを特徴とする請求項１に記載のシステム。
5. 少なくとも２つのサーバーが存在し、上記各主機能成分及びそのカウンターパートであるスタンバイ機能成分は異なるサーバーによって収容されていることを特徴とする請求項４に記載のシステム。
6. 少なくとも２つのサーバーが存在し、上記各主機能成分及びそのカウンターパートであるスタンバイ機能成分は異なるサーバーによって収容されていることを特徴とする請求項１に記載のシステム。
7. 上記各サーバーは、上記主機能成分だけ、または上記スタンバイ機能成分だけの何れかを収容していることを特徴とする請求項５に記載のシステム。
8. 上記各サーバーは、上記主機能成分だけ、または上記スタンバイ機能成分だけの何れかを収容していることを特徴とする請求項１に記載のシステム。
9. 上記サーバー及び上記プラットホームは、Ｓ．３００プロトコルを使用して通信することを特徴とする請求項１に記載のシステム。
10. 上記各プラットホームは、上記他のプラットホームと相互接続されていることを特徴とする請求項１に記載のシステム。
11. 上記プラットホームはＡＴＭスイッチング配列によって接続され、上記ＡＴＭスイッチング配列は、上記プラットホーム間のリアルタイム媒体ストリームの交換を容易にするように構成されていることを特徴とする請求項１に記載のシステム。
12. 上記新しい機能成分は、主機能成分またはスタンバイ機能成分の何れかであることを特徴とする請求項１に記載のシステム。
13. 呼出し処理システムにおいて電話呼出しを処理する方法であって、
    複数の呼出し処理資源を含む複数のプラットホームと、呼出し処理アプリケーションを走らせる複数のクライアントコンピュータとの間に１つまたはそれ以上のコンピュータ電話サーバーを接続するステップを含み、上記サーバーは、上記呼出しを処理するために必要なそれぞれの機能を遂行するための主機能成分及びそのカウンターパートであるスタンバイ機能成分からなる複数の機能成分を収容し、上記各スタンバイ機能成分は、そのカウンターパートである上記主機能成分が動作を停止するまでシャドウであり続け、
    上記方法は更に、
    特定の呼出しを受信すると、上記呼出し処理アプリケーションから上記サーバーへ、上記呼出しを処理するためにはどの資源グループが必要であるか、及び上記呼出しを処理するためにはどの機能成分セットを動作させる必要があるかに関する命令を送るステップと、
    上記命令を受信すると、上記必要な機能成分を収容している上記サーバー上でポーリングソフトウェアを走らせて、上記プラットホーム上の上記資源グループの可用性に関する情報について上記プラットホームからポーリングするステップと、
    上記ポーリングソフトウェアによってポーリングされた上記可用性情報に基づいて、上記プラットホームと同じ、または異なるプラットホームの何れかから上記資源セットを割当てるステップと、
    を含み、
    上記呼出し中に新しい機能成分が動作し始めると、上記新しい機能成分を収容している上記サーバー上で上記ポーリングソフトウェアが上記可用性に関する情報をポーリングするために走るようになっている、
    ことを特徴とする方法。
14. 上記ポーリングステップは、上記必要な資源の全ての可用性に関して、上記複数の各プラットホームからポーリングを遂行することを特徴とする請求項１３に記載の方法。
15. 上記呼出しを処理するために必要な上記資源の全てを含んでいる単一のプラットホームが見出されると、上記ポーリングステップは停止することを特徴とする請求項１４に記載のシステム。
16. 上記ポーリングステップは、上記必要な資源の全ての可用性に関して上記複数のプラットホームの第１のプラットホームをポーリングし、上記第１のプラットホーム上では調達できなかった残余の資源の可用性に関して上記複数のプラットホームの第２のプラットホームをポーリングする等々と、必要な資源の全てが見出されるまでポーリングして行くステップからなることを特徴とする請求項１３に記載の方法。
17. 上記割当てステップは、上記サーバー上で優先順位スキームで割当てソフトウェアを走らせることによって遂行されることを特徴とする請求項１３に記載の方法。
18. 上記サーバー上のスタンバイ機能成分がその主成分の代わりに動作を開始することを要求されると、上記サーバーの１つ上で上記ポーリングソフトウェアが走ることを特徴とする請求項１３に記載の方法。
19. 上記呼出し中に新しいサービスが要求されたことによって上記サーバー上の主成分が動作を開始することを要求されると、上記サーバーの１つの上で上記ポーリングソフトウェアが走ることを特徴とする請求項１３に記載の方法。
20. 上記新しい機能成分は、主機能成分またはスタンバイ機能成分の何れかであることを特徴とする請求項１３に記載の方法。
21. 上記新しい機能成分は、上記呼出し中にそのカウンターパートである機能成分が動作を停止すると動作し始めるスタンバイ機能成分であることを特徴とする請求項２０に記載の方法。
22. 上記新しい機能成分は、上記呼出中に新しいサービスが要求されると動作し始めることを特徴とする請求項２０に記載の方法。

Images