JP3672231B2

JP3672231B2 - 業務用アプリケーション・システム及び操作方法

Info

Publication number: JP3672231B2
Application number: JP2000139621A
Authority: JP
Inventors: ロナルド・ジョン・ボウォーター; ニコラス・デビット・バトラー; デビット・アンドリュー・クラーク; デビット・シーガー・レンシャウ; グラハム・ヒュー・トゥットル
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1997-09-19
Filing date: 2000-05-12
Publication date: 2005-07-20
Anticipated expiration: 2018-08-25
Also published as: JP2001024791A; JPH11168566A; GB2329549A; EP0903922A3; GB9719942D0; KR100457288B1; US6335964B1; JP3301537B2; KR19990029317A; EP0903922A2

Description

【０００１】
【発明の属する技術分野】
本発明は、呼び出し処理アプリケーションのために、複数の電話回線に接続する音声処理システムに関する。
【０００２】
【従来の技術】
音声処理システムは技術的に公知であり、広範な機能を実行するために使用される。例えば、音声処理システムの一般形態は、音声応答ユニット（ＶＲＵ）であり、これはコール・センタに導入されて、しばしば初期スクリーニング・プロセスとして、或いは仲介者が使用可能でないときに着呼を処理するために使用される。従って、通常のアプリケーションは、呼び出しをＶＲＵにつなぐためのものであり、ＶＲＵが呼出人に、オプションのセットを提供する予め記録されたプロンプトを再生する。呼出人は次に、彼らの電話機上の特定のデュアル・トーン多重周波数（ＤＴＭＦ）キーを押下することにより、所望のオプションを選択でき、ＶＲＵが次に要求機能を実行する。あるオプションは例えば、単に呼出人がより多くの情報（例えばチケット入手可能性）を聞くためのものであったり、別のオプションは、（例えばチケット予約のために）呼出人をライブ・エージェントに転送したりする。呼出人とＶＲＵとの対話は極めて複雑であり、例えば、呼出人は、チケット入手可能性に関する情報を必要とする日にちの範囲を入力するように要求される。
【０００３】
音声処理システムの例は、ＩＢＭから販売されるＡＩＸ音声処理システム用のダイレクトトーク（DirectTalk）であり、これについてはマニュアル"DirectTalk for AIX、General Infomation and Planning"、参照番号ＧＣ３３−１８４０−００、或いはその中で参照される他のマニュアルで述べられている。多くの最新の音声処理システム同様、ダイレクトトーク・システムは、電話及び音声処理機能のための追加のハードウェア及びソフトウェアを有する汎用コンピュータ（この場合ＲＳ／６０００ワークステーション）にもとづく。（ダイレクトトーク、ＡＩＸ、及びＲＳ／６０００はＩＢＭの商標である。）
【０００４】
ダイレクトトーク音声処理システム上で、サポートされる広範な機構を使用することにより、非常に高機能なアプリケーションを開発することが可能である。こうした機構には、音声認識（通常ＤＴＭＦ入力の代替）、ＦＡＸ、ボイス・メール、呼び出し／被呼番号をそれぞれ識別する自動番号識別／ダイヤル番号識別サービス（ＡＮＩ／ＤＮＩＳ）情報の使用、テキスト−音声変換、及びリモート・データベース・アクセスが含まれる。
【０００５】
従来の音声処理アプリケーションの構造が図１に示され、これはアプリケーション２００、ダイレクトトーク・ソフトウェア２１０、及びオペレーティング・システム２２０を含み、これらは全て１つのワークステーション上に存在する。ダイレクトトーク・ソフトウェア２１０は、顧客アプリケーション２００の状態テーブル及び他の要素を受諾し、音声処理システムのためにオペレーティング・システム２２０と一緒に、適宜所望の機能を実行する役割をする。特定の場合では、アプリケーションがリモート・システム２３０からデータをアクセスすることが望ましく、これはオペレーティング・システムの通信機能を利用することにより達成される（この場合、ダイレクトトーク・ソフトウェアを媒介として使用するのではなく、アプリケーションが直接オペレーティング・システムと対話する）。
【０００６】
ダイレクトトーク音声処理システムのアプリケーションは、状態テーブルを基礎とし、これは本質的に呼出人に再生されるプロンプト、及び呼出人応答に応じて実行される異なるアクション、更に、音声処理資源のより直接的なプログラム制御を可能にする任意のカスタム・サーバをリストする。従って、アプリケーションの開発は、関連プロンプト、及びカスタム・サーバ（例えば音声認識資源へのアクセスを提供する）などの、任意の他のより特殊化された項目と一緒に、１つ以上の状態テーブルの構成を要求する。ダイレクトトーク音声処理システムは、アプリケーション開発を容易にする図形プログラミング・ツールを提供する。こうしたプログラミング・ツールを開発する必要性は、音声処理システムの提供者にとって厄介な作業である。なぜなら、こうした技術は通常、提供者の中心的な電話／ＩＶＲ（対話式音声応答）専門知識外であり、こうしたツールに投資する機会は限られているからである。
【０００７】
前述のように、音声処理アプリケーションは極めて複雑化し得、またそれぞれの個々の導入に対して特有であるという点で、通常、予約注文である。従って、顧客にとって、彼らの厳格な音声処理要求を満足する既製の解決策を購入する事は、困難である。それどころか、彼らは最初に基本音声処理システムを購入し、次に要求アプリケーションを開発しなければならない。
【０００８】
多くの場合、顧客は、所望のアプリケーションを含む総合的な音声処理解決策を提供する特定の第３者と連絡を取る。第３者はしばしば音声処理システムのメーカである。なぜなら、こうしたメーカは一般に、彼らのシステムのためにアプリケーションを開発するためのほとんどの専門知識を有するからである。このアプローチは、音声処理アプリケーションが本質的に独立型操作の場合には、満足のいくものであり得る。しかしながら、こうした音声処理アプリケーションを、事業の中核情報システム内にしっかり統合することが、益々一般的となりつつある。例えば、全ての着呼に対する呼び出し番号を顧客データベースと突き合わせ、この呼び出しを処理するために役立つ情報をリアルタイムに検索することが望まれる。顧客は様々な理由から、ＶＲＵメーカがこうした統合を達成することに気乗りしないであろう。なぜなら、メーカが特定のソフトウェア技術分野において、不十分な専門知識しか有さなかったり、或いは単にセキュリティの理由から、第３者に事業戦略的なコンピュータ・システムに対して、あまりに多くのアクセスを与えることが望ましくないなどの理由が考えられる。
【０００９】
更に、一旦顧客が音声処理アプリケーションの開発のために第３者を使用すると、彼らはサービス及び保守のためにも、その第３者を頼るようになり得る。こうしたことは、状況によっては、望ましくないコスト的な問題を招き得る。
【００１０】
従って別の可能性は、顧客が自身の音声処理アプリケーション開発をインハウスで行うことである。なぜなら、こうすることが顧客にとって、音声処理アプリケーションの最大の管理を達し得るからである。しかしながら、こうした状況は、顧客ソフトウェア技術者が音声処理システムのアプリケーション開発に精通することを要求する。こうした技能は、任意の特定のタイプの音声処理システムの導入の絶対数がかなり小さいことを考慮すると、しばしば市場において稀であり、更にこの理由から、ソフトウェア技術者の雇用への期待を大きく向上させ得ないことを鑑みると、彼らがこうした技能に注目するためには魅力に欠ける。その上、こうした音声処理アプリケーションを開発するためには、特殊な電話術の知識を有することがしばしば必要である。従って、顧客が彼ら自身の音声処理アプリケーションを開発し、保守するために必要な適切な人材を獲得し、保有することは困難である。
【００１１】
【発明が解決しようとする課題】
従って、本発明は複数の電話回線に接続する手段を有する音声処理システムを提供する。本発明の音声処理システムは、回線オブジェクトのセットを含み、各回線オブジェクトが前記電話回線の１つに関連付けられ、他のオブジェクトにより呼び出され、その回線オブジェクトに関連付けられる電話回線に対して操作を実行するメソッドのセットを含む。
【００１２】
【課題を解決するための手段】
従って、回線オブジェクトが音声応答サーバ機能を効果的に提供し、これらの機能が、ユーザ・アプリケーションにより所望されるときに呼び出される。それ故、ユーザ・アプリケーションがその特定のプラットフォームの音声処理環境において実行されなければならない従来システムと異なり、アプリケーションがこのクライアント・サーバ関係により、音声処理システムの詳細から効果的に分離される。この分離は、アプリケーション開発者がもはや関連する音声処理環境に縛られず、総称的なプログラミング・ツール及び技能を利用できると言う意味において、多大な利点をもたらす。このことはアプリケーション開発を迅速化し、費用効率を向上させる。なぜなら、高品質の総称的なプログラミング・ツール及び技能は、ＩＶＲ特有のツール及び技能に比べて、市場で容易に入手可能であるからである。
【００１３】
好適な実施例では、回線オブジェクト・メソッドが呼び出し応答（Answer Call）、呼び出し終了（End Call）、ＤＴＭＦキー獲得（Get DTMF Key）、及び音声再生（Play Audio）を含むが、多岐に渡る他のメソッドも使用可能である。これらのメソッドは、音声処理システムの中枢機能（特に対話式音声応答のための機能）を表し、基礎を成す音声処理システム内に既に提供されたアクションに容易に写像される。
【００１４】
音声処理システムは好適には、更に回線オブジェクトのメソッドを呼び出すＩＶＲアクション・オブジェクトのセットを含み、最も好都合には、１つのＩＶＲアクション・オブジェクトが、ある回線オブジェクトの各メソッドに対応する。このことはＩＶＲアクション・オブジェクトがユーザ・アプリケーションに容易に組み込まれることを可能にし、それによりＩＶＲアクション・オブジェクトはアプリケーションから、回線オブジェクト・メソッドを呼び出すことができる。このことは業務用アプリケーションと回線オブジェクトとの、ある程度の分離を提供する。こうした状況は、好適な実施例では、回線オブジェクトが本質的に業務用アプリケーションの要求時に作成され、物理的な電話回線に接続されることを鑑みると望ましい。従って、ＩＶＲアクション・オブジェクトを媒介として使用することは、業務用アプリケーションを物理的な電話回線の詳細から分離する支援となる。しかしながら、特定の場合では、性能上の理由から、業務用アプリケーションがＩＶＲアクション・オブジェクトを介すること無しに、直接回線オブジェクト内のメソッドを呼び出すことが望ましい。
【００１５】
好適な実施例はまた、ＩＶＲアクション・オブジェクトとして、音声メニューまたは音声形式などのためのより高いレベルの要素を提供し、これらは上述の低レベルのＩＶＲアクションから形成される複合オブジェクトと見なされ得る。こうした高レベルの要素は、しばしばユーザ・アプリケーション内で見い出され、従ってそれらを既製品形態で提供することは、迅速なアプリケーション開発を容易にする。
【００１６】
本発明の重要な面は、ＩＶＲアクション・オブジェクトがリモート・システム上で実行され、リモート・メソッド呼び出しを介し、回線オブジェクトと対話することである。従って、ＩＶＲシステムは単にリモート・サーバと見なされ、要求時にＩＶＲ機能を提供するために呼び出される。このアプローチでは、システム全体が業務用アプリケーションの要求により決定され、これらの要求がアプリケーションのＩＶＲ要素内に入力されることが明らかである。このことは従来システムと対照的な点であり、従来システムでは、音声処理アプリケーションが音声処理環境と関連して、本質的に独立型アプリケーションとして実行され、従って音声処理システムの制限により非常に拘束された。また、こうした独立型の音声処理アプリケーションをより広い企業コンピュータ環境に統合することは、困難であった。
【００１７】
本発明は更に、複数の電話回線のセットのための音声処理機能を含む業務用アプリケーション・システムを提供する。このシステムは、業務用アプリケーション・プログラミング・オブジェクトと、前記業務用アプリケーションが音声処理機能を要求するとき呼び出される、前記業務用アプリケーション・プログラミング・オブジェクトと一緒に統合される音声処理要素オブジェクトと、前記音声処理要素オブジェクトに応答して、要求される音声処理機能を提供するプログラミング・オブジェクト手段を含む音声処理サーバとを含む。
【００１８】
好適な実施例では、前記プログラミング・オブジェクト手段が回線オブジェクトを含み、各回線オブジェクトが前記電話回線の１つに関連付けられる。
【００１９】
本発明は更に、複数の電話回線のセットのための音声処理機能を含む業務用アプリケーションを操作する方法を提供する。この方法は、音声処理要素オブジェクトを含む業務用アプリケーション・プログラミング・オブジェクトを提供するステップと、前記業務用アプリケーション・プログラミング・オブジェクトが音声処理機能を要求するとき、前記音声処理要素オブジェクトを呼び出すステップと、音声処理ハードウェアと対話し、前記音声処理機能を実行する音声処理ソフトウェアを含むソフトウェア・サーバ手段を提供するステップであって、前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが、前記音声処理ソフトウェアに独立であり、前記ソフトウェア・サーバ手段を介してだけ前記音声処理ソフトウェアと対話するステップと、前記業務用アプリケーション・プログラミング・オブジェクトからの前記音声処理機能の呼び出しに応答して、前記音声処理要素オブジェクトにより、前記ソフトウェア・サーバ手段内のメソッドを呼び出すステップであって、前記メソッドが前記音声処理ソフトウェア及び前記音声処理ハードウェアと対話し、要求される前記音声処理機能を実行するステップとを含む。
【００２０】
好適な実施例では、前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが、第１のシステム上に配置され、前記ソフトウェア・サーバ手段が、前記音声処理ソフトウェア及び前記音声処理ハードウェアを含む第２のシステム上に配置される。それにより、前記音声処理要素オブジェクト及び前記ソフトウェア・サーバ手段が、リモート・メソッド呼び出しを介して通信する。従って、ＩＶＲシステムからのアプリケーションの論理的な分離が、これらを異なるマシン上で分離可能にする追加の利点を提供し、特に、アプリケーションがもはや音声処理システム自身上で実行される必要がない。このことはアーキテクチャ全体の柔軟性及び潜在的効率を著しく高め、ある業務用アプリケーションが複数の音声処理サーバ・システムを利用する可能性を開く。
【００２１】
【発明の実施の形態】
図２は、音声処理アプリケーションの顧客解決策を示す。特に、顧客の構内には、１つ以上の中継線１５（通常、各々が２４の従来式電話接続を含むＴ１回線）により公衆電話網１０に接続される交換機２０、及び交換機２０に同様に１つ以上の中継線２５により接続されるＶＲＵ３０が含まれる。ＶＲＵハードウェアは従来式のコンピュータ・ワークステーションを基礎とし、これは入来するそれぞれの中継線２５を終端する回線インタフェース・カード、及び時分割多重化（ＴＤＭ）バス、または回線カードからＶＲＵ内の適切な音声処理資源に電話チャネルを分配する他の適切なコネクタを含む。このハードウェア・レベルでは、ＶＲＵは既知の音声処理システムに従う。
【００２２】
図２のシステムは、企業コンピュータ構造基盤のいわゆる"３層"モデルに設定される。このモデルでは、第３層は概念的に、企業により格納されるデータ・セットを表し、これらが企業のコンピュータ・アプリケーションをサポートするために利用され、処理される。従って、これらのデータ・セットは企業の顧客リストや製品情報などを表し、事業活動にとって基本的であり、一般に専用のデータ・サーバ上の大規模なデータベース・システムに格納される。
【００２３】
３層モデル内の次の層は第２層であり、これは第３層のデータを利用し処理する業務用アプリケーションまたは業務論理を表す。従って、例えば注文処理アプリケーションが顧客データ・セット及び製品情報データ・セットの両方から情報を受け取り、注文の発行及び続く追跡を可能にする。３層モデルの最後の層は第１層であり、これはプレゼンテーション層を表す。これはアプリケーションまたは業務論理のフロント・エンドを表すソフトウェアである（任意の所与のアプリケーションに対して、複数のフロント・エンドが存在し得る）。このフロント・エンドは実際の顧客に直接公表され、インターネットを介する製品の発注を可能にしたり、特定の内部仲介業者、例えばデパート内で製品注文を受諾している販売代理店に公表される。
【００２４】
従来、図１の従来式の音声処理アプリケーション構造を３層モデル上に写像することが困難であった。それ故、こうしたアプリケーションは一般に、第３層を表すリモート・データ・サーバをアクセスしたが、ほとんどの音声処理システムにおいては第１層と第２層との明確な区別が存在しなかった。換言すると、従来式の音声処理システムは、論理層とプレゼンテーション層を、１つのアプリケーション構造に結合する。このことが本明細書の導入部分で述べたように、音声処理システムを、より広い企業コンピュータ構造基盤に統合することが困難な１つの理由である。
【００２５】
しかしながら、この問題は、図２に示される音声処理システムの根本的な構造改革により克服され得る。特に、明確な論理境界が、アプリケーション（図２では業務オブジェクト・サーバ４０として示される）と、音声応答ユニット３０自身との間に導入される。本発明の状況においては、音声応答ユニットが第１層内に別のプレゼンテーション機構としてしっかりと配置され、第２層のアプリケーションまたは業務論理が音声処理システムから効果的に切り離される。
【００２６】
図２のモデルをサポートするプログラミング構造が図３に示され、これは図１のそれよりも幾分複雑である。重要な点は、この構造はオブジェクト指向アプローチにもとづいており、従って、対話オブジェクトのセットを巡りできるだけたくさん展開されることである。従って、ダイレクトトーク音声処理ソフトウェア３３０の基本層は、音声処理システムの様々なハードウェア要素を直接制御するように、また基本的な電話及びデータ移送機能を実行するように維持される。この基本層の上には、回線オブジェクト３３５のセットが存在する。これらの回線オブジェクトは、あらゆる操作またはアクションが１つ以上の回線オブジェクトに対して実行されると言う点で、音声処理システムにより提供される基本的資源を表す。回線オブジェクト上には、呼び出し応答やプロンプト再生などの、対話式音声応答（ＩＶＲ）アクション３２０が存在する。ユーザ・アプリケーション３１０がこれらの上に存在し、選択されたＩＶＲアクションを効果的に統合する。それにより、業務用アプリケーションが必要に応じてＩＶＲアクション・オブジェクトを対応する回線オブジェクトと一緒に呼び出し、その回線オブジェクトの所望のアクションを生成することができる。
【００２７】
図３には更に、ＩＶＲ要素３２５のセットが示される。これらは事実上、ＩＶＲアプリケーションの一般に使用される要素を表すが、概念的には、基本ＩＶＲアクションよりも幾分高いレベルである。本実施例では、音声メニュー及び音声形式の２つのＩＶＲ要素が提供される。これらは単純なＩＶＲアクション３２０から構成され得るので、複合オブジェクトと見なされ得る。従って、音声メニューは本質的に音声プロンプトのセットを再生し、続いて適切なエラー処理などと一緒に、ユーザ入力（通常はＤＴＭＦキー）を受信する。他方、音声形式は本質的に、音声プロンプトのセットの間にＤＴＭＦキーの形式かまたは記録済みの音声として、呼出人からの入力を受信する。（しかしながら、性能上の理由から、これらの複合オブジェクトは必ずしも単にＩＶＲアクションから構成されるのではなく、回線オブジェクトと直接対話するように、完全にコード化される点に注意されたい。）
【００２８】
２つの重要なインタフェースが図３に記され、それらがインタフェース３６０及びインタフェース３５０として示される。これらは従来的な意味におけるプログラミング・インタフェースではなく、オブジェクトの異なる論理グループ間の概念的な境界を表す。すなわち、異なるグループ内のオブジェクトがこれらの境界を横断して、互いに通信する。
【００２９】
第１のインタフェース３６０は事実上、音声処理システムのメーカにより供給される総称的なＩＶＲソフトウェアと、ユーザによりまたはユーザのために開発される特定のアプリケーションとの間の境界に対応する。従って、インタフェース３６０は図１におけるアプリケーション２００とダイレクトトーク・ソフトウェア２１０との間の境界にほぼ対応する。しかしながら、従来技術において一般に使用可能でなかったＩＶＲ要素３２５のセットの提供が、このインタフェースの能力及び有用性を向上させ、ユーザ・レベルでの迅速なアプリケーション開発を容易にする。更に重要な点は、この解決策によるオブジェクト指向構造の結果、業務用アプリケーションがユーザにより開発される業務オブジェクトと、所望のＩＶＲアクション・オブジェクトの両方を含み、最終的なユーザ解決策において、これら２つのオブジェクトのセットが図３に示されるように別々ではなく、互いに効果的に統合される。
【００３０】
図３に示される第２のインタフェース、すなわちインタフェース３５０は重要である。なぜなら、これはＩＶＲ特有のソフトウェア（回線オブジェクト）と、ＩＶＲアクション・オブジェクトを組み込む本質的に独立の業務用アプリケーションとの境界を表すからである。従って、従来システムとは大きく異なり、ＩＶＲアクションのセットが、基本音声処理ソフトウェア（すなわちダイレクトトーク・ソフトウェア３３０）内に直接的に結合されない。代わりに、ＩＶＲアクションは、回線オブジェクトのセット内に予め定義されたインタフェースを介し、音声処理システムと対話する本質的に独立のオブジェクトを表す。換言すると、回線オブジェクトは、適切なメソッド呼び出しを介しＩＶＲクライアント・アプリケーションにより呼び出されるＩＶＲサーバ機能を表す。このことから、インタフェース３５０が事実上、図２に示される第１層と第２層との間の境界に対応することが分かる。
【００３１】
次に回線オブジェクトの構造及び振舞いについて、詳しく考えてみよう。回線オブジェクトは、アプリケーションが回線資源オブジェクト（図３では図示せず）から回線を要求することに応答して作成される。回線資源オブジェクトは、１つのＩＶＲに特有であるか、好適な実施例では、複数のＩＶＲの資源を制御することができ、ＩＶＲの回線（チャネル）容量を表す構成情報を提供される。この時回線オブジェクトは、これまでに割当てられた（または返却され、再割当てのために使用可能となった）容量を決定することができる。特定の予備の容量が実際に使用可能であると仮定すると、回線資源は回線オブジェクトを作成し、これがＩＶＲ上の物理チャネルに接続される。次に業務用アプリケーションに接続識別子が渡され、これを用いて、アプリケーションは割当てられた回線オブジェクトと対話することが可能になる。
【００３２】
回線オブジェクトは基本的に、他のオブジェクトにより呼び出されるメソッドのセットにより定義される。これらが表１にリストされる。
【００３３】
【表１】

【００３４】
このリストは単に、可能な回線オブジェクト・メソッドの代表例であり、前記の全てのメソッドがサポートされる必要はなく、また他のメソッドが含まれてもよい。例えば、１実施例では、音声記録がサポートされず、またリンギング通知（事実上、回線オブジェクト作成時に自動的に発生するように想定される）もサポートされない。しかしながら、この実施例は、アクションがタイムアウトにより終了されるか、或いは所定数のＤＴＭＦトーンまたは所定数のＤＴＭＦ文字の受信により終了されるかに依存して、複数のＤＴＭＦトーン獲得メソッドを有する。従って、当業者であれば、前記の回線オブジェクト・メソッドのリストに対する多くの変化及び追加に気付かれよう。
【００３５】
本実施例はジャバ（Java）・プログラミング言語で作成され（Javaはサン・マイクロシステムズ社の商標）、回線オブジェクトの前記メソッドは、主としてＩＶＲ上の固有のメソッドとして実現される（ダイレクトトークの状況では、これは好適な状態テーブル及びカスタム・サーバを介し達成される）。換言すると、呼び出し応答などの特定の回線オブジェクト・アクションが呼び出されるとき、対応するメソッドが対応する呼び出しを、ダイレクトトーク音声処理システム内に生成する。前記の回線オブジェクト・メソッドのセットに対応する機能が、従来の音声処理システム上で容易に使用可能になることが評価されよう。
【００３６】
回線オブジェクトの重要な面は、それが作成され、特定のシステムの物理回線に接続されるとき、その特定のシステムの属性がインポートされることである。従って、回線オブジェクト・メソッドはプラットフォーム特有であるが、提供されるメソッドのセットはそうではない。この結果、図２のシステムは任意の特定のＩＶＲプラットフォームには拘束されない。なぜなら、回線資源がそのＩＶＲプラットフォームの適切な回線オブジェクトを作成できるならば、同じアプリケーションがそのプラットフォーム上で実行され得るからである。これは明らかに移植性及びスケーラビリティの点で、大きな利点である。
【００３７】
ＩＶＲアクション・オブジェクト３５０について考えると、これらは実際、回線オブジェクト上で使用可能なメソッドのセットに、非常に密接に対応する。なぜなら、回線オブジェクト内の各メソッドに対して１つのＩＶＲアクション・オブジェクトが存在するからである。従って、これらのＩＶＲアクション・オブジェクトは、それらの主なアクションが、指定された回線オブジェクト内の対応するメソッドを呼び出すことであるという点で平凡である。ＩＶＲアクションのこの層の目的は、業務用アプリケーションを回線オブジェクトから分離することである。なぜなら、回線オブジェクトは特定の物理回線に関連して作成されるのに対して、業務用アプリケーションは、回線資源オブジェクトにより与えられる接続識別子に関係するからである。このことは業務用アプリケーションを、任意の特定の物理ＩＶＲシステムまたは電話回線に余りに密接に関連付けることを回避する。しかしながら、特定の状況では、性能上の理由から、業務用アプリケーションがＩＶＲアクション・オブジェクトをバイパスし、代わりに回線オブジェクト内の所望のメソッドを呼び出すことにより、回線オブジェクトと直接対話することが好ましい。
【００３８】
ＩＶＲアクション・オブジェクトは再度、ジャバ・オブジェクトのセットとして実現され、特にそれらは"ジャバ・ビーンズ（Java Beans）"（サン・マイクロシステムズ社の商標）のセットとして実現される。（ジャバ・ビーンズは本質的に、それが他のアプリケーション内の要素として容易に統合されることを可能にする特定の機構を有するジャバ・オブジェクトである。ジャバ・ビーンズに関する詳細については、http://www.javasoft.com/beans/を介しアクセスできる。）
【００３９】
前述のように、図３はＩＶＲ要素３２５として指定されるより高いレベルのオブジェクトも示す。好適な実施例では、２つのこうしたＩＶＲ要素オブジェクトが存在し、第１は音声メニューであり、第２は音声形式である。これらについてもジャバ・ビーンズとして提供される。これらのハイレベル・オブジェクトはユーザ・アプリケーションに統合することが可能であり、ＩＶＲアプリケーションの共通の要素を表す。最後に、業務用アプリケーション３１０に関しては、これは再度一般にジャバにより作成され、ジャバ・ビーンズのセットとして提供されるＩＶＲアクション・オブジェクトとの統合を容易にする。
【００４０】
図２のアーキテクチャは、ＩＶＲアプリケーションにおける従来のアプローチに勝る多くの利点を提供する。最初に、対話オブジェクトの使用はクライアント・サーバ・アプローチを可能にし、このことがＩＶＲプラットフォームからの業務用アプリケーションの分離を可能にする。従って前述のように、そして図１に示されるように、従来のＩＶＲアプリケーションは特殊化されたＩＶＲ環境内で実行され、プログラム開発及び保守をより困難にし、また他の企業内コンピュータ・システムとの密接な統合を妨げる。それに対して、本発明では、回線オブジェクトだけが特殊化されたＩＶＲ環境内で実行され、これらの回線オブジェクトがＩＶＲサーバ機能を効果的に提供する。このことはＩＶＲアプリケーションの論理を、（ＩＶＲアクション・オブジェクトのセットとして、）業務用アプリケーションに統合することを可能にし、回線オブジェクトとのクライアント・サーバ関係が、任意の所望のＩＶＲ機能をアクセスするために使用される。従って、ＩＶＲアプリケーションが、業務用アプリケーションの単なる要素として、効果的に包含される。このことは従って、業務用アプリケーションとＩＶＲアプリケーションとの非常に密接な統合を可能にし、更に従来技術とは逆に、前者の要求が後者を決定することを可能にする。概念的には、これは"ＩＶＲ中心"のパラダイムから、"アプリケーション中心"のパラダイムへの移行と見なされ得る。
【００４１】
本発明の別の重要な利点は、ＩＶＲアプリケーションがもはや音声処理環境内でプログラムされずに、汎用業務用アプリケーション内に統合され、従って、音声処理システムがアプリケーション開発ツールを提供する必要がないことである。（図形プログラミング及びスクリプティングのための）業界標準のソフトウェア開発ツールが、業務用アプリケーション全体を開発するために使用され、それには、適切なジャバ・ビーンズのアセンブリにより形成され得る統合ＩＶＲアプリケーションが含まれる。（こうしたアプリケーション開発ツールの例に、ＩＢＭから販売されるジャバ用のビジュアルエージ（VisualAge）（ＩＢＭの商標）が含まれる。）その結果、ＩＶＲアプリケーションの開発のために、もはやＩＶＲシステムの特殊な知識が要求されない。なぜなら、これは事実上、全て回線オブジェクト内に隠されるが、幅広い分野のプログラマにより達成され得るからである。業界標準ツール及び技術の使用は、顧客が特定の特殊なＩＶＲ環境にはまる危険無しに、音声処理アプリケーションのより迅速な開発を可能にする。
【００４２】
別の利点は、リモート・メソッド呼び出し（ＲＭＩ）と共にジャバ・オブジェクトの使用が、アプリケーションの設計において、多大な柔軟性を提供することである。（ＲＭＩはマシン上のオブジェクトが遠隔的に、リモート・マシン上のオブジェクトのメソッドを呼び出すことを可能にする。ＲＭＩに関する詳細については、http://www.javasoft.com/marketing/collateral/rmi_ds.htmlを介し入手できる。）ＩＶＲ４１０とリモート・ジャバ・システム４００との間で、ＲＭＩが発生する様々な可能な状況が、図４乃至図６に示される。ここでＩＶＲ４１０はダイレクトトーク音声処理ソフトウェア４１５を含み、ジャバ・システム４００は一般にいかなる電話またはＩＶＲ機能も有さず、任意の従来式ワークステーションである。
【００４３】
図４では、アプリケーション４２０がＩＶＲ自身上で実行され、ＩＶＲ上の回線オブジェクト４２２と直接的に対話する。しかしながら、アプリケーションはＲＭＩを用い、リモート・ジャバ・システム上のサーバ・オブジェクト４２４を呼び出す。このアプローチは、図１に示される従来のセットアップと幾つかの類似点を有する。非常に異なる構成が図５に示され、ここではアプリケーション４３０自身が、リモート・ジャバ・ワークステーション４００上に存在する。この状況では、アプリケーションがＲＭＩを用い、ＩＶＲシステム上の回線オブジェクト４３２へのアクセスを獲得し、これらがリモートＩＶＲサーバ資源として作用する。このアプローチは多くの利点を有し、例えばアプリケーションが音声処理ソフトウェアとＩＶＲシステムを共用する必要がなく、その特定の性能要求に見合う専用のマシン上で実行され得る（ＩＶＲシステムは、特殊な電話ハードウェアを組み込む必要性を鑑みると、しばしば、限られた範囲の基本コンピュータ・システム上でのみ使用可能である）。更に、１つのアプリケーションを複数のＩＶＲシステムを指令するジャバ・ワークステーション上に有することは、直接的である。
【００４４】
最後に図６は、幾分異なる構成を示し、そこでは製作ＩＶＲシステム４１０が、図４で示されるユーザ・アプリケーション４４０及び回線オブジェクト４４２を含む。この場合、ＲＭＩはアプリケーションをジャバ・ワークステーション上に複製するために使用される。開発者は（ＩＶＲシステムにおいて使用可能なプログラミング・ツールに頼る必要無しに）ジャバ・ワークステーションにおいて使用可能なプログラミング・ツールを用い、この形式のリモート・アクセスを実行し、自分自身のローカル・システム上に複製されたアプリケーション４４１に働きかけることができる。図６の別の例として、ジャバ・ワークステーション上に回線オブジェクト・シミュレータを導入することが可能であり、これにより再度、このステーション上でのアプリケーション開発が容易になる。
【００４５】
以上、本発明の好適な実施例が、ジャバ・プログラミング言語に関して述べられてきたが、上述した不可欠な機能が使用可能であれば、任意の他の好適な言語（または言語の組み合わせ）が使用され得る。更に、異なるマシン上のオブジェクト間の対話がＲＭＩに関連して述べられてきたが、ＣＯＲＢＡなどの他の機構も代わりに使用され得る。
【００４６】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００４７】
（１）複数電話回線のセットのための音声処理機能を含む業務用アプリケーション・システムであって、
業務用アプリケーション・プログラミング・オブジェクトと、
前記業務用アプリケーションが音声処理機能を要求するとき呼び出される、前記業務用アプリケーション・プログラミング・オブジェクトと一緒に統合される音声処理要素オブジェクトと、
前記音声処理要素オブジェクトに応答して、要求される音声処理機能を提供するプログラミング・オブジェクト手段を含む音声処理サーバと
を含む、業務用アプリケーション・システム。
（２）前記プログラミング・オブジェクトが、前記電話回線の１つに各々関連付けられる回線オブジェクトを含む、前記（１）記載のシステム。
（３）複数の電話回線のセットのための音声処理機能を含む業務用アプリケーションを操作する方法であって、
音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトを提供するステップと、
前記業務用アプリケーション・プログラミング・オブジェクトが前記音声処理機能を要求するとき、前記音声処理要素オブジェクトを呼び出すステップと、
音声処理ハードウェアと対話し、前記音声処理機能を実行する音声処理ソフトウェアを含むソフトウェア・サーバ手段を提供するステップであって、前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが、前記音声処理ソフトウェアに独立であり、前記ソフトウェア・サーバ手段を介してだけ前記音声処理ソフトウェアと対話するステップと、
前記業務用アプリケーション・プログラミング・オブジェクトからの前記音声処理機能の呼び出しに応答して、前記音声処理要素オブジェクトにより、前記ソフトウェア・サーバ手段内のメソッドを呼び出すステップであって、前記メソッドが前記音声処理ソフトウェア及び前記音声処理ハードウェアと対話し、要求される前記音声処理機能を実行するステップと
を含む、方法。
（４）前記ソフトウェア・サーバ手段が、前記電話回線の１つに各々関連付けられる複数の回線オブジェクトを含み、前記音声処理要素オブジェクトが前記回線オブジェクト内のメソッドを呼び出す、前記（３）記載の方法。
（５）前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが第１のシステム上に配置され、前記ソフトウェア・サーバ手段が、前記音声処理ソフトウェア及び前記音声処理ハードウェアを含む第２のシステム上に配置される、前記（３）または（４）記載の方法。
（６）前記音声処理要素オブジェクト及び前記ソフトウェア・サーバ手段がリモート・メソッド呼び出しを介し通信する、前記（５）記載の方法。
【図面の簡単な説明】
【図１】音声処理アプリケーションの従来構造を示す図である。
【図２】本発明に従う音声処理機能を含む業務用アプリケーションの構造を示す図である。
【図３】図２の音声処理機能を有する業務用アプリケーション内のソフトウェア構造を示す図である。
【図４】リモート・メソッド呼び出しを用いて、業務用アプリケーションがＩＶＲ及び標準のコンピュータ・ワークステーションを通じて配布される方法を示す図である。
【図５】リモート・メソッド呼び出しを用いて、業務用アプリケーションがＩＶＲ及び標準のコンピュータ・ワークステーションを通じて配布される別の方法を示す図である。
【図６】リモート・メソッド呼び出しを用いて、業務用アプリケーションがＩＶＲ及び標準のコンピュータ・ワークステーションを通じて配布される更に別の方法を示す図である。
【符号の説明】
１０公衆電話網
１５、２５中継線
２０交換機
３０音声応答ユニット（ＶＲＵ）
４０業務オブジェクト・サーバ
２００アプリケーション（顧客アプリケーション）
２１０、３３０ダイレクトトーク・ソフトウェア
２２０オペレーティング・システム
２３０リモート・システム
３１０業務用アプリケーション
３２０、３５０対話式音声応答（ＩＶＲ）アクション
３２５ＩＶＲ要素
３３０、４１５ダイレクトトーク音声処理ソフトウェア
３３５音声処理システム・ソフトウェア
３５０ＩＶＲアクション・オブジェクト
３６０インタフェース
４００リモート・ジャバ・システム
４１０製作ＩＶＲシステム
４２０アプリケーション
４２４サーバ・オブジェクト
４３０、４４１アプリケーション
４３２、４４２回線オブジェクト
４４０ユーザ・アプリケーション

Claims

複数電話回線のセットのための音声処理機能を含む業務用アプリケーション・システムであって、
業務用アプリケーション・プログラミング・オブジェクトと、
前記業務用アプリケーション・プログラミング・オブジェクトが音声処理機能を要求するとき呼び出される、前記業務用アプリケーション・プログラミング・オブジェクトと一緒に統合される音声処理要素オブジェクトと、
前記音声処理要素オブジェクトに応答して、要求される音声処理機能を提供するプログラミング・オブジェクト手段を含む音声処理サーバと
を含み、
前記プログラミング・オブジェクト手段が、前記業務用アプリケーション・プログラミング・オブジェクトからの要求により、接続識別子を含み、該接続識別子を前記業務用アプリケーション・プログラミング・オブジェクトに渡す回線資源オブジェクトを使用して生成され、かつ前記電話回線の１つに各々関連付けられる回線オブジェクトを含み、前記接続識別子を使用して前記音声処理要素オブジェクトにより呼び出される前記回線オブジェクト内のメソッドが、音声処理ハードウェア及び前記音声処理ハードウェアと対話して前記音声処理機能を実行する音声処理ソフトウェアと対話して、前記音声処理機能を実行する、
業務用アプリケーション・システム。
複数の電話回線のセットのための音声処理機能を含む業務用アプリケーションを操作する方法であって、
音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトを提供するステップと、
前記業務用アプリケーション・プログラミング・オブジェクトが前記音声処理機能を要求するとき、前記音声処理要素オブジェクトを呼び出すステップと、
音声処理ハードウェアと対話し、前記音声処理機能を実行する音声処理ソフトウェアを含むソフトウェア・サーバ手段を提供するステップであって、前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが、前記音声処理ソフトウェアに独立であり、前記ソフトウェア・サーバ手段を介してだけ前記音声処理ソフトウェアと対話するステップと、
前記業務用アプリケーション・プログラミング・オブジェクトからの前記音声処理機能の呼び出しに応答して、前記業務用アプリケーション・プログラミング・オブジェクトからの要求により、接続識別子を含み、該接続識別子を前記業務用アプリケーション・プログラミング・オブジェクトに渡す回線資源オブジェクトを使用して生成され、かつ前記電話回線の１つに各々関連付けられる、前記ソフトウェア・サーバ手段が含む回線オブジェクト内のメソッドを、前記接続識別子を使用して前記音声処理要素オブジェクトにより、呼び出すステップであって、前記メソッドが前記音声処理ソフトウェア及び前記音声処理ハードウェアと対話し、要求される前記音声処理機能を実行するステップと
を含む、方法。
前記音声処理要素オブジェクトを含む前記業務用アプリケーション・プログラミング・オブジェクトが第１のシステム上に配置され、前記ソフトウェア・サーバ手段が、前記音声処理ソフトウェア及び前記音声処理ハードウェアを含む第２のシステム上に配置される、請求項２記載の方法。
前記音声処理要素オブジェクト及び前記ソフトウェア・サーバ手段がリモート・メソッド呼び出しを介し通信する、請求項３記載の方法。