JPH10506766A

JPH10506766A - 音声とデータを統合化した配送を行うネットワーク・ベース電話システム

Info

Publication number: JPH10506766A
Application number: JP8515383A
Authority: JP
Inventors: ホーレンバック，スティーヴン，アンドリュー; マーチン，マイケル，アレン; ノヴァック，トーマス，スティーブン; ウォーズナック，ロバート，スティーブン
Original assignee: ベルコミュニケーションズリサーチ，インコーポレイテッド
Priority date: 1994-11-04
Filing date: 1995-11-01
Publication date: 1998-06-30
Anticipated expiration: 2015-10-18
Also published as: US5533115A; CA2204132A1; JP3058450B2; WO1996014704A1; CA2204132C; EP0789963A1; EP0789963A4

Abstract

(57)【要約】呼処理レコード（ＣＰＲ）をアクセスするサービス制御ポイント（ＳＣＰ）［１０２］を含んでいるネットワークを基礎とする電話システム［１００」において、インテリジェント周辺装置（ＩＰ）［１０４］は発呼者とＳＣＰ［１０２］との間のインテリジェント・インタフェース、呼をエージェント・ワークステーション［１１６］に転送する経路を選択する自動呼分配装置（ＡＣＤ［１０８］、およびエージェント・ワークステーション・ネットワーク［１１５］を備えている。ＩＰ［１０４］は周辺インタフェース（ＰＩ）［１２８］を通してＳＣＰ［１０２］とやりとりする。外部システム［１０６］は顧客データを得るために汎用データ・インタフェース（ＧＤＩ）［１２４］を通してＳＣＰ［１０２］によってアクセスされる。ＧＤＩ［１２４］は種々の外部システム［１０６］にストアされたデータの記録をとっている。データ要求を受信すると、ＧＤＩ［１２４］はサブ要求を作り、そのサブ要求を該当の外部システム［１０６］に転送する経路を選択し、要求データを収めているメッセージを返送する。次に、ＡＣＤ［１０８］は呼をエージェント［１１６］に転送する経路を選択し、これと同時に、ＧＤＩ［１２４］は要求データをエージェント［１１６］の表示端末［１１９］へ配送させる。

Description

【発明の詳細な説明】音声とデータを統合化した配送を行うネットワーク・ベース電話システム関連出願の相互参照本出願は、１９９３年１２月１６日に出願された米国特許出願第08/168,612号の一部継続出願であり、その内容は本出願の基礎となり、引用により本明細書の一部を構成するものである。また、本出願は、「テレコミュニケーション・システムにおけるサービスの作成、転送およびモニタリングのシステムおよび方法（System and Method for Cr eating，Transferring，and Monitoring Services in a Telecommunication Sys tem）」という名称で１９９２年８月２５日に出願された米国特許出願第07/934, 240号（出願人：Zager A．Nazif他。以下、「'240出願」と呼ぶ）、「テレコミュニケーション・システムにおけるサービスの作成、転送およびモニタリングのシステムおよび方法(System and Method for Creating，Transferring，and Mon itoring Services in a Telecommunication System)」という名称で１９９２年１１月６日に出願された米国特許出願第07/972,529号（出願人：Zager A．Nazif 他。以下、「'529出願」と呼ぶ）および「テレコミュニケーション・サービス仕様の作成方法(A Method of Creating a Telecommunication Service Specificat ion)」という名称で１９９２年１１月６日に出願された米国特許出願第07/972,8 17号（出願人：Susan K．K．Man 他。以下、「'817出願」と呼ぶ）の関連出願でもある。上記３出願の内容も本出願の基礎となり、引用により本明細書の一部を構成するものである。発明の背景本発明は一般的にはネットワークを基礎とする電話システム（以下、「ネットワーク・ベース電話システム」と呼ぶ）の分野に関し、より具体的には、発呼者とネットワーク・ベース電話システムとの間でやりとり(interaction)し、データを外部システムからアクセスし、データをサービス・エージェントに提供する問題に係わるものである。 '240出願と '817 出願には、呼処理ネットワークにおいてカストマイズされたテレコミュニケーション・サービスを作成し、そのサービスをインスタンス生成 (instantiate)し、維持するシステムと方法が記載されている。このシステムはサービス準備と作成環境（Service Provisioning and Creation Environment - ＳＰＡＣＥ：Bellcore社の登録商標）アプリケーションを含んでいるが、これは呼処理レコード(call processing record - ＣＰＲ)を作成するものである。ＣＰＲは、受信した電話呼が特定の顧客に対してどのように処理されるかを定義している。ＣＰＲはサービス制御ポイント（service control point - ＳＣＰ）へ転送され、そこでサービスが実行される。ネットワーク内の交換機が呼を処理するための情報を必要とするときは、照会 (query)をＳＣＰへ送信している。ＳＣＰ内のマルチサービス・アプリケーション・プラットフォーム（Multi-Services Application Platform - ＭＳＡＰ）は、呼と関連づけられた「キー」に基づいてＣＰＲをアクセスする。ＭＳＡＰはＣＰＲのノードを処理し、対応する呼処理指示を出して交換機へ送り返している。交換機はその指示に基づいて呼を転送する経路を選択している。ＣＰＲを実行している途中で、ＳＣＰはある特定ノードを使用して情報を発呼者に要求することができる。しかし、ＳＣＰが要求できる情報のタイプには若干の制限がある。例えば、ＳＣＰは、発呼者にＰＩＮ番号を挿入するように要求することができる。このように発呼者とＳＣＰとの間のやりとりが制限されていることは呼を完了するのには不十分であるため、サービス・エージェントに介入させて、呼を手操作で処理させる必要がある。当然のことであるが、手操作による呼処理は自動化呼処理よりも低速で、高コストであるのが通常である。発呼者からの上記入力を除き、ＭＳＡＰは外部システムから情報をアクセスすることができない。むしろ、ＭＳＡＰがアクセスできるのは、ＭＳＡＰが実行されているＳＣＰから得られる情報だけである。この場合も、この情報だけでは、呼処理を正しく実行するには不十分である。以上に鑑みて、望ましいことは、システムが電話呼(telephone call)を処理するときのインテリジェンスを向上することである。また、望ましいことは、システムが電話呼を処理するときの柔軟性を向上することである。さらに、望ましいことは、電話呼を処理するときの発呼者とシステムとのやりとりを強化することである。さらに、望ましいことは、電話呼を処理するときシステムが外部システムから情報をアクセスする容易性を向上することである。さらに、望ましいことは、呼をサービス・エージェントへ送る既存のプロセスを補強することである。さらに、望ましいことは、発呼者に関する情報に基づいて発呼者を該当するエージェントへ転送する経路を選択することである。さらに、望ましいことは、該当するエージェントへの呼の転送を行うと共に、その呼に関連するデータを同じエージェントの表示端末へ転送を行うことである。さらに、望ましいことは、発呼者を該当するエージェントへ転送する経路を選択するときのネットワーク信頼性を提供することである。上記以外に本発明が望ましいとしていることは以下の説明の中で明らかにするが、その中には、以下の説明を読むことにより理解することができるものと、本発明を実施することにより知得し得るものとがある。発明の開示内容上述した望ましいことおよび目的を達成するために、および以下に実施例として示され、広義に説明されている本発明の目的によれば、本発明の電話呼を処理する方法は、電話呼を交換機で受信するステップと、呼処理指示をＳＣＰに要求するステップと、呼処理指示に対応する電話呼の処理方法を指定しているサービス・ロジックをＳＣＰでアクセスするステップと、サービス・ロジックに従ってデータを１つまたは２つ以上の外部システムにＳＣＰから要求するステップと、サービス・ロジックに従ってデータを１つまたは２つ以上の外部システムからＳＣＰで受信するステップと、１つまたは２つ以上の外部システムから受信したデータに基づいて電話呼を該当するエージェントへ転送する経路を選択するステップと、データを同じエージェントへ転送する経路を選択するステップとを含んでいる。以上から理解されるように、上述の概要説明と以下の詳細説明は単なる例示であって、理解を容易にするためのものであり、請求の範囲に記載されている本発明をより具体的に説明したものである。図面の簡単な説明添付図面は本明細書の一部を構成するものとして添付されたものであり、本発明の好ましい実施例を示しているが、これらの図面は上述した概要説明と下述する好適実施例の詳細説明と共に、本発明の原理の理解を容易にするためのものである。図面において、図１は本発明によるネットワーク・ベースの電話システムを示すブロック図である。図２は本発明によるサービス制御ポイント(service control point：ＳＣＰ) を示すブロック図である。図３は本発明による周辺インタフェース（peripheral interface：ＰＩ）の内部インタフェースを示す図である。図４は本発明によるＰＩに対応するソフトウェア・モジュールを示す概略図である。図５は本発明の好適実施例において複数のＰＩとのインタフェースとなる複数のインテリジェント周辺装置（intelligent peripheral：ＩＰ）からなる構成を示す図である。図６は本発明による汎用データ・インタフェース（generic data interface：ＧＤＩ）とのインタフェースとなる内部テーブルを示す図である。図７は本発明の好適実施例によるＧＤＩのオペレーションを示すフローチャートである。図８は本発明による未処理要求テーブル内のサブ要求を示す図である。図９は本発明による呼処理レコードの例を示す図である。図１０はＡＣＤ１０８のオペレーションを示すフローチャートである。図１１はＡＣＤプロトコル・ハンドラ１２５のオペレーションを示すフローチャートである。図１２はエージェント・プロトコル・ハンドラ１２７のオペレーションを示すフローチャートである。発明の最適実施形態図１に示すように、本発明のネットーワークを基礎とする電話システム１００（以下では、「ネットワーク・ベース電話システム」と呼ぶ）は、公衆交換ネットワーク１１０の従来のエレメント、複数の電話機１１２（図には１つだけが示されている）、自動呼分配装置(automatic call distributor - ＡＣＤ)１０８、インテリジェント周辺装置(intelligent peripheral - ＩＰ)１０４、サービス制御ポイント（service control point - ＳＣＰ）１０２、外部システム１０６、エージェント・ワークステーション・ネットワーク１１５、各々が電話機１１７と表示端末１１９をもつ複数のエージェント・ワークステーション１１６（図には１つだけが示されている）を含んでいる。公衆交換ネットワーク１１０はＡＣＤ１０８とＩＰ１０４に接続されている。ＡＣＤ１０８はエージェント・ワークステーション１１６の電話機１１７とＳＣＰ１０２に接続されている。ＩＰ１０４は公衆交換ネットワーク１１０に接続され、ＳＣＰ１０２にも接続され、ＳＣＰ１０２は外部システム１０６とエージェント・ワークステーション・ネットワーク１１５に接続されている。エージェント・ワークステーション・ネットワーク１１５はエージェント・ワークステーション１１６の表示端末１１９に接続されている。電話機１１２から発呼者によって出された呼は公衆交換ネットワーク１１０によって受信され、ＩＰ１０４へ転送される。ＩＰ１０４がもつ機能の１つはインテリジェント音声周辺装置として、電話機１１２にいる発呼者とのインタフェースとなることである。例えば、ＩＰ１０４は、好ましくは、発呼者へディジタル化されたアナウンスを再生し、呼処理情報を入力するように発呼者にプロンプトで督促し、呼処理情報を収集することができる。呼が公衆交換ネットワーク１１０からＩＰ１０４へされてくると、ＩＰ１０４はその呼をどのように処理すべきかの指示をＳＣＰ１０２に要求する。以下で詳しく説明するように、ＳＣＰ１０２は呼処理レコード(call processing record) に基づいて指示をＩＰ１０４へ渡すインタフェースの働きをする。従って、発呼者とＩＰ１０４との間の接続はインテリジェント・インタラクティブ通信となり、ＳＣＰ１０２は発呼者から送られてきた情報に応答して指示をＩＰ１０４へ送っている。ＳＣＰ１０２をＩＰ１０４と併用することにより、呼処理が自動化されているので、エージェントが日常的な仕事（ルーチン・タスク）を処理する時間が大幅に節減されている。必要ならば、ＳＣＰは発呼者１１２をＡＣＤ１０８へ転送する経路を選択するようにＩＰ１０４に指示することもできる。ＳＣＰ１０２は、発呼者１１２（つまり、特定のエージェントまたはエージェント・グループ）の望ましい最終的宛先に関してＩＰ１０４に指示することになる。また、ＡＣＤ１０８は、発呼者１１２とエージェントの電話機１１７との接続を種々の基準に基づいて管理する。発呼者がＡＣＤ１０８を通して進行して行くとき、ＡＣＤ１０８はその進行状態をＳＣＰ１０２に通知する。好適実施例では、ＡＣＤ１０８はAT&T 5ESS Pinnac le（商標）ＡＣＤになっているが、ＡＣＤは公知のどのタイプのものでも使用することができる。好ましくは、ＩＰ１０４は自動アウトバウンド・ダイヤル呼出しなどの追加機能も備えており、その場合には、ＩＰ１０４はＳＣＰ１０２から受信した指示に従って外部電話機１１２へ起呼する。好適実施例では、ＩＰ１０４はPeriphonics VPS 9000またはBellcore Intelli gent Services Peripheral(ＩＳＰ)バージョン２．０になっている。外部システム１０６は、好ましくは、データベースまたは他のネットワーク・ベース・システムを含んでおり、そこには、呼を処理するときに役立つデータが収容されている。そのようなデータとして、例えば、アカウント状態データ、修理情報、顧客プロフィール・データ、注文情報などがある。アカウント状態データは、顧客が良好な持続状態にあるかどうか、顧客のサービスが料金未納のため一時中断されているかどうかを示すことができる。修理情報は、特定の電話回線に行われた修理、回線がサービス中であるかどうか、および特定の回線に起こっている問題のタイプを示すことができる。顧客プロフィール・データには、顧客の呼を送るときに役立つ顧客情報を収容することができる。そのような情報としては、インストールされているサービスのタイプ、電話回線の地理的ロケーションなどがある。注文情報としては、例えば、サービスのコスト、特定の顧客へサービスを提供できるかどうか、などがある。外部システム１０６は種々のハードウェア構造を備えることができるが、そのようなものとしては、例えば、IBM TN -3270 データベースがある。上述したように、ＡＣＤ１０８はＳＣＰ１０２によって受信された指示に従って呼をエージェント・ワークステーション１１６へ配送することもできる。エージェント・ワークステーション１１６に置かれたエージェントとしては、種々の顧客要求を処理する機能をもつ正規サービス・エージェントにすることも、特定の顧客要求を処理する機能をもつ専門サービス・エージェントにすることも可能である。ＩＰ１０４と外部システム１０６から受信した情報に基づいて、ＳＣＰ１０２は呼を該当するエージェント・ワークステーション１１６へ配送するようにＡＣＤ１０８に指示することができる。例えば、ある発呼者のアカウントが料金未納のため一時中断されていれば、その発呼者を収集部門へ転送する経路を選択することができる。また、発呼者の回線が自宅事務所で使用されていれば、発呼者を「在宅勤務」アカウント専門のエージェントへ転送する経路を選択することもできる。呼を処理するときに、エージェントが外部システムにストアされたデータをアクセスできるようにすることもできる。図２は、本発明の好適実施例によるＳＣＰ１０２アーキテクチャを示すブロック図である。図示のように、ＳＰＡＣＥアプリケーションはＭＳＡＰアプリケーション１２０とのインタフェースとなっている。ＳＰＡＣＥはＳＣＰ１０２の外側に示されているが、別の実施例では、ＳＰＡＣＥをＳＣＰ１０２に内蔵させることも可能である。ＭＳＡＰ１２０はメッセージ配達(Message Delivery - ＭＤ )インタフェース１２２とやりとりし、このインタフェースを通して、メッセージはＭＳＡＰ１２０から周辺インタフェース（ＰＩ）１２８か汎用データ・インタフェース（generic deta interface：ＧＤＩ）１２４のどちらかに配達される。ＭＳＡＰ１２０はＳＣＰ１０２に置かれているアプリケーションであり、アクセスされた呼処理レコードのサービス・ロジックを実行し、システム１００の他のエレメントに対する指示を出す。ＰＩ１２８はＩＰ１０４とＳＣＰ１０２とを結ぶインタフェースであり、これらの２デバイスはこのインタフェースを通して通信できる。ＧＤＩ１２４はデータ要求をプロトコル・ハンドラ１２６を経由して該当の外部システム１０６へ送信し、外部システム１０６から受け取ったデータを１つのメッセージにパッケージ化し、ＭＳＡＰ１２０へ送られて、そこで使用される。ＧＤＩ１２４はＳＣＰ１０２に置かれているデータまたはＳＣＰ１０２が取り出したデータを外部システムへ送ることもできる。さらに、ＧＤＩ１２４はＡＤＣ１０８およびエージェント・ワークステーション・ネットワーク１１５との間で、それぞれＡＣＤプロトコル・ハンドラ１２５とエージェント・プロトコル・ハンドラ１２７を経由してデータを返信し、取得する。ＰＩ１２８とＧＤＩ１２４は以下で詳しく説明する。ＰＩ１２８はＩＰ１０４とＳＣＰ１０２間のデータ・ネットワーク通信リンクを確立し、維持する。ＰＩ１２８は、ＩＰ１０４とＳＣＰ１０２間でメッセージを非同期送信することも取り扱う。さらに、ＰＩ１２８はメッセージをＩＰ１０４またはＳＣＰ１０２が認識できるフォーマットに変換する。好適実施例では、ＰＩ１２８がサポートするメッセージ・フォーマットは公表されているBellcore ドキュメントTR-TSY-000402(１９８９年７月)（以下、ＴＲ４０２フォーマットと呼ぶ）またはTA-NWT-001129(１９９２年１０月)（以下、ＴＡ１１２９＋フォーマットと呼ぶ）に記載されているが、これらのフォーマットはそれぞれＩＰ１０４とＳＣＰ１０２によって認識されている。なお、他のメッセージ・フォーマットをＩＰ１０４とＳＣＰ１０２で使用することも可能である。正常オペレーション期間には、ＰＩ１２８はＩＰ１０４とＭＳＡＰ１２０からのメッセージを同時に待っている。ＰＩ１２８によって受信されたメッセージはキュー（待ち行列）１２９に追加され、他方、ＰＩ１２８から送信されたメッセージはキュー１２９から除去される。図３はＰＩ１２８の内部インタフェースを示したもので、インタフェースとしては、例えば、ノード・マネージャ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）１３０、ノード管理ＡＰＩ１３２、メインテナンス・オペレーション・コンソール(Maintenance Operations Console - ＭＯＣ)ＡＰＩ１３４、ＴＣＰ／ＩＰＡＰＩ１３６、構成ファイル１３８、メッセージ配達（ＭＤ）１２２などがある。ノード・マネージャＡＰＩ１３０は、ＳＣＰ１０２内のノードの状態をモニタリングすることによってＳＣＰ１０２の信頼性を維持することを担当する。ノード管理ＡＰＩ１３２は、ＳＣＰ１０２に接続された各ＩＰ１０４のアドレスといった、ＳＣＰ１０２の構成に関する情報を収容している。ＭＯＣＡＰＩ１３４はコンピュータ端末（図示せず）とＳＣＰ１０２とを結ぶインタフェースとなって、例えば、技術者がＳＣＰ１０２で保守を実施できるようにする。ＴＰＣ／ＩＰＡＰＩ１３６はＴＣＰプロトコルを使用して、ＳＣＰ１０２とＩＰ１０４との間のインタフェースを提供する。構成ファイル１３８はＰＩ１２８のオペレーションに関する情報を収めている。このような情報としては、ＩＰ１０４のアドレスを識別し、キュー１２９に置かれたメッセージの優先順位を指定するといった、ＰＩ１２８の構成に関するパラメータなどがある。構成ファイル１３８に対する変更は、ＰＩ１２８の初期化時に行うことが好ましい。好適実施例では、ＰＩ１２８はソフトウェアで実現されている。図４は、ＰＩ１２８の好ましいソフトウェア・モジュールを示すブロック図である。ＰＩ１２８では、メッセージはＩＰ１０４からモジュール１４０によって受信される。受信されたメッセージは次にモジュール１４２によって妥当性検査（バリデーション）され、モジュール１４４によってＭＳＡＰ１２０が認識できるフォーマットにコード化される。モジュール１４６はＭＳＡＰ１２０との間でＭＤ１２２を経由してメッセージを送受信する。モジュール１４８はＭＳＡＰ１２０から受け取ったメッセージを妥当性検査し、モジュール１５０はＩＰ１０４が認識できるフォーマットにメッセージをコード化する。モジュール１５２はメッセージをＩＰ１０４へ供給する。受信したメッセージを処理するとき、ＰＩ１２８は変換が必要であるかどうかを判断する。変換が必要であれば、ＰＩ１２８は受信メッセージをデコードし、メッセージが有効かどうかを判断する。次に、ＰＩ１２８は変換テーブル（図示せず）を使用して、メッセージを受信側デバイスが認識できるフォーマットに変換する。例えば、ＳＣＰ１０２からＩＰ１０４によって受信されるメッセージはＴＲ４０２フォーマットからＴＡ１１２９＋フォーマットに、またはその逆に変換される。ＩＰ１２８がＩＰ１０４から無効なメッセージを受信したときは、そのメッセージは除去され、以後のメッセージ処理は中止される。この場合、ＩＰ１０４に置かれたタイマはメッセージを再送するか、呼を転送する。ＰＩ１２８がフォーマットが正しくないメッセージをＭＳＡＰ１２０から受信したときは、ＰＩ１２８はエラー・メッセージをＭＳＡＰ１２０に返送する。図５は複数のＩＰ１０４とＳＣＰ１０２間の接続に冗長性をもたせて、システム信頼性を向上するようにした本発明の好適実施例を示す図である。ＳＣＰ１０２はトランザクションを「ラウンドロビン」方式で複数のＰＩ１２８の各々に配分する。ＰＩ１２８は１つまたは２つ以上のＩＰ１０４との接続に冗長性をもたせる構成になっている。従って、ある接続に障害が起こった場合でも、メッセージをＩＰ１０４とＳＣＰ１０２間で送信することができる。各ＰＩ１２８は構成に含まれるすべての接続（冗長性のある接続を含む）を常時アクティブに保つようにする。ＰＩ１２８はその回線接続の各々の一般的状態をログに記録し、接続が良好であるか、低下したか、不良であるかを示している。接続が良好のときは、構成に含まれるすべての接続がアクティブであることを示している。接続が低下したときは、すべてではないが、少なくとも１つの接続に障害が起こったことを示している。接続が不良のときは、すべての接続に障害が起こったことを示している。いずれかの接続に障害が起こると、ＰＩ１２８に置かれた周期的タイマの働きでＰＩ１２８は、あらかじめ決めた時間の経過後に接続を確立する試みを再度行う。構成に含まれるすべての回線がアクティブであるときは、ＰＩ１２８はその周期的タイマの働きを非アクチベートする。アクティブな回線から期待外のエラーが戻されたときは、その回線は障害が起こったものと扱われ、ＰＩ１２８の周期的タイマは再アクチベートし、回線を再確立する試みが行われる。回線上を送られてきたメッセージのフォーマットが正しくないときは、回線に障害が起こったものと扱われるので、ＰＩ１２８の周期的タイマがアクチベートされる。ＧＤＩ１２４を通して、ＭＳＡＰ１２０は外部システム１０６にストアされた情報をリアルタイムで透過アクセスすることができるので、ＭＳＡＰ１２０は情報のソースを知らなくてもその情報を要求することができる。図６はＧＤＩ１２４にストアされた内部テーブルを示している。このテーブルはＭＳＡＰ１２０への情報要求を処理するものである。これらのテーブルとしては、データ・エレメント・テーブル(Data Element Table)１５４、ＧＤＩキュー・テーブル(GDI Queues Table)１５６、外部システム・テーブル(External Syst em Table)１５８、および未処理要求テーブル(Outstanding Request Table)１６０がある。データ・エレメント・テーブル１５４はデータ要求を該当の外部システム１０６へ転送するためにＧＤＩ１２４によって使用される。ＧＤＩキュー・テーブル１５６は、メッセージをやりとりするときどのキュー名を使用するかを判断するために、ＧＤＩ１２４とプロトコル・ハンドラ１２６によって使用される。外部システム・テーブル１５８は、外部システムとやりとりするためにアドレシング情報を得るためにプロトコル・ハンドラ１２６によって使用される。未処理要求テーブル１６０はＧＤＩ１２４による未処理要求リストを作るために使用される。プロトコル・ハンドラ１２６は外部システム１０６との物理的接続と論理的接続を管理し、外部システム１０６とやりとりして情報を取り出す。好適実施例では、各外部システム１０６は、対応するプロトコル・ハンドラ１２６を有している。ＡＣＤプロトコル・ハンドラ１２５はＡＣＤ１０８との物理的接続と論理的接続を管理し、ＡＣＤ１０８とやりとりしてＡＣＤ１０８内のキューに置かれた呼に関する状態情報を受け取る。ＡＣＤプロトコル・ハンドラ１２５は以下で詳しく説明する。エージェント・プロトコル・ハンドラ１２７はエージェント・ワークステーション・ネットワーク１１５との物理的接続と論理的接続を管理し、エージェント・ワークステーション・ネットワーク１１５とやりとりして呼にサービスするために必要な情報を、呼がそのエージェント・ワークステーション１１６へルート（経路選択）された時点で、呼がＡＣＤ１０８によってルート（経路選択）された先のエージェント・ワークステーション１１６の表示端末１１９に送信する。エージェント・プロトコル・ハンドラ１２７は以下で詳しく説明する。以下では、図７に示すフローチャート１６２を参照して、ＧＤＩ１２４がＭＳＡＰ１２０からのデータ要求をどのように処理するかについて説明する。初めに、ＧＤＩ１２４は、以下で詳しく説明するGetData 要求をＭＳＡＰ１２０から受信する（ステップ１６３）。ＧＤＩ１２４はGetData 要求をデコードしてどのデータ・エレメントがＭＳＡＰ１２０によって要求されているかを決定する（ステップ１６４）。データ・エレメント・テーブル１５４を使用して、ＧＤＩ１２４は要求されたデータ・エレメントを得るためにどの外部システム１０６をアクセスすべきかを決定する（ステップ１６５）。データ・エレメント・テーブル１５４はルックアップ・テーブルであり、特定のデータ・エレメントがどの外部システム１０６に置かれているかを示している。以上のように、ＧＩＤ１２４がGetD ata 要求をデコードし、ＭＳＡＰ１２０によって要求された特定データ・エレメントを判定すると、ＧＩＤ１２４は、データ・エレメント・テーブル１５４で特定データ・エレメントに対応する外部システムを調べる。次に、ＧＤＩ１２４はデータ・エレメントを要求する「サブ要求」を該当の外部システムに関連するプロトコル・ハンドラに転送する（ステップ１６６）。未処理要求テーブル１６０は、未処理「サブ要求」の記録をとるように更新される（ステップ１６７）。次に、ＧＤＩ１２４は応答が受信されたかどうかを判断する（ステップ１６８）。応答がＧＩＤ１２４によって外部システム１０６から受信されていれば、未処理要求テーブルは部分的完了の記録をとるように更新される（ステップ１６９）。次に、ＧＤＩ１２４はサブ要求に対する応答がすべて戻されなかったかどうかを判断する（ステップ１７０）。戻されていなければ、ＧＩＤ１２４は他の応答があるかで待つ。応答がすべて受信されていれば、ＧＤＩ１２４は完了メッセージをＭＳＡＰ１２０に返送する（ステップ１７２）。ステップ１６８で、ＧＤＩ１２４が応答が未受信であると判断したとき、あらかじめ決めた時間が経過したときも（１７１）、メッセージがＭＳＡＰ１２０に返送される（ステップ１７２）。以上のように、メッセージは未処理サブ要求がすべて応答されたときにもタイムアウトが起こったときにもＭＳＡＰ１２０に返送される。図８はＧＤＩ未処理要求テーブル１６０を示している。ブロックＡ，ＢおよびＣはＭＳＡＰ１２０からＧＤＩ１２４によって受信された未処理要求を表している。ブロックＡ１，Ａ２およびＡ３、ブロックＢ１，Ｂ２およびＢ３、ブロックＣ１，Ｃ２およびＣ３はそれぞれ未処理要求Ａ，ＢおよびＣから作成されたサブ要求を表している。ブロックＡ１Ｒ，Ａ２ＲおよびＡ３Ｒはそれぞれサブ要求Ａ１，Ａ２およびＢ３に応答してＧＤＩ１２４によって受信された応答を表している。未処理要求テーブル１６０は、ＭＳＡＰ１２０からの情報要求がＧＤＩ１２４によって受信されると、構築され、更新される。ＭＳＡＰ１２０から要求を受信すると、ＧＤＩ１２４はサブ要求を作成し、サブ要求は該当のプロトコル・ハンドラに転送される。ＧＤＩ１２４は各未処理サブ要求の応答を待つ。３タイプの応答を未処理要求テーブル１６０にストアすることが可能である。第１に、ＧＤＩ１２４は外部システム１０６からの応答Ａ１Ｒをストアすることができる。この応答はサブ要求に応答して結果が受信されたことを示している。第２に、ＧＤＩ１２４は外部システム１０６からの応答Ａ２Ｒをストアすることができる。この応答は外部システム１０６からエラーが受信されたことを示している。この種のエラーは外部システム１０６がサブ要求を処理できないことを示している場合がある。最後に、ＧＤＩ１２４は応答Ｂ３Ｒをストアすることができる。この応答はあらかじめ決めた時間内に外部システム１０６から応答が受信されなかったことを示している。本発明の一部を構成する'240出願、'529出願、および'817出願に説明されているように、ノードは呼処理期間に実行される論理的オペレーションを定義している基本単位である。ＭＳＡＰ１２０はノードを処理し、対応する要求または指示をシステム１００の他のエレメントに対して出す。本発明の一部を構成する上記特許出願には、ＭＳＡＰ１２０によってサポートされる種々のノードが記載されており、この中には、GetData、SendData、およびWaitForEventノードが含まれている。本発明の好適実施例では、GetData、SendData、およびWaitForEventノードは以下で説明するように変更することが可能である。また、本発明によれば、TransferCallノードも含まれているが、これについては下述する。 GetData ノードにより、ＭＳＡＰ１２０は特定のアカウントに関するデータを外部システム１０６に要求することができる。ＭＳＡＰ１２０から出されるGetD ata 要求には、ハンドル・コール変数(handle call variable)、アカウントＩＤ、およびコール変数リストが含まれている。ハンドル・コール変数はGetData 要求であることを示し、要求情報を取り出し、要求の状態をチェックするために使用される。アカウントＩＤは発呼者のアカウントを示している。コール変数リストはＭＳＡＰ１２０から外部システム１０６に要求されたデータを指定している。ＭＳＡＰ１２０からGetData 要求を受信すると、ＧＤＩ１２４は要求情報がどの外部システム１０６に置かれているかを、上述したように判断する。ＧＤＩ１２４はＭＳＡＰ１２０から受信したGetData 要求に基づいて要求をフォーマットし、該当する外部システムに送信する。ＧＤＩ１２４はサブ要求の各々に対する応答を待ってから、要求情報のすべてをＭＳＡＰ１２０に返送する。ＧＤＩ１２４があらかじめ決めた時間が経過したあとサブ要求のすべてに対する応答を受信しなかったときは、エラー通知が受信されたデータと一緒にＭＳＡＰ１２０に返送される。情報がＧＤＩ１２０からＭＳＡＰ１２０に戻されても、ＭＳＡＰ１２０がWaitForEventノードを実行したあとまで、その情報はＭＳＡＰ１２０では使用できない。 SendDataノードにより、ＭＳＡＰ１２０はデータを外部システム１０６およびエージェント・ワークステーション・ネットワーク１１５に送信することができる。ＭＳＡＰ１２０から外部システム１０６に出されるSendData要求には、ハンドル・コール変数、アカウントＩＤ、およびコール変数リストが対応するデータと一緒に含まれている。ハンドル・コール変数はSendData要求であることを示し、要求の状態を得るために使用される。コール変数リストに対応する情報はアカウントＩＤに従って外部システム１０６にストアされる。ＭＳＡＰ１２０からSendData要求を受信すると、ＧＤＩ１２０はデータをどこに送るべきかを決定する。ＧＤＩ１２０は受信したSendData要求からのデータをフォーマットし、フォーマットしたデータを該当のプロトコル・ハンドラに送信する。ＧＤＩ１２０は、データが受け取られたとのプロトコル・ハンドラからの肯定応答を待ってから、状態応答をＭＳＡＰ１２０に送信する。しかしながら、ＭＳＡＰ１２０がWaitForEventノードを実行したあとまで、SendData要求の状態をＭＳＡＰ１２０は使用できない。 WaitForEventノードを使用すると、ＭＳＡＰ１２０はGetData またはSendData 要求のデータまたは状態にアクセスすることができる。WaitForEvent指示はハンドル・コール変数を指定しており、これは、GetData またはSendData要求で指定されているハンドル・コール変数に対応している。ＭＳＡＰ１２０がwaitForEve ntノードを実行したあとまで、GetData またはSendData要求からＭＳＡＰ１２０に戻されるすべての要求をＭＳＡＰ１２０は使用できない。WaitForEvent指示が出されたとき、要求情報が返送されるまで別の指示はＭＳＡＰ１２０によって実行されない。応答が返送されたとき、情報が要求で指定されたコール変数に割り当てられ、要求の状態が返送される。ＧＤＩ１２４が要求情報を取り出している間に、ＭＳＡＰ１２０はＩＰ１０４に別の指示を出して、例えば、発呼者から追加情報を得たり、ディジタル化メッセージを再生したりしてからWaitForEvent要求を出すことができる。このようにすると、発呼者はＭＳＡＰ１２０が要求に対する応答を受信するのを待たないで済むことになる。 TransferCallノードを使用すると、ＭＳＡＰ１２０は呼を発呼者１１２に関する情報と一緒にエージェント・ワークステーション１１６へ転送する経路を選択するように公衆交換ネットワーク１１０に指示することができる。TransferCall 指示は、好ましくは転送番号とアカウント番号を含んでいるので、例えば、ＡＣＤ１０８へ送信して、そこで呼をキューに置いておき、そのあとで転送番号で指定された専門エージェント・ワークステーション１１６へ転送することができる。システム１００のオペレーションを理解しやすくするために、図９は符号１２０で示す呼処理レコードの例を示している。この例では、呼処理レコード２１０は発呼者のプロフィールに基づいて発呼者を「専門」エージェントへ転送するように経路選択している。受信された呼がＩＰ１０４へ転送されると、ＩＰ１０４は呼処理指示をＳＣＰ１０２に要求する。アカウント番号や電話番号といった、呼の中のあらかじめ決めた情報に基づいて、ＳＣＰ１０２はＭＳＡＰ１０２の制御の下で、対応する呼処理レコード２１０を実行する。図９の例に示すように、PlayAnnouncementノード１８０は、ディジタル化アナウンスで発呼者を歓迎するようにＩＰ１０４に指示している。GetDigits ノード１８２は、発呼者のアカウント番号または電話番号を入れることを発呼者に要求するようにＩＰ１０４に指示している。ＭＳＡＰは、ディジット・コレクション要求の結果をチェックして発呼者がプロンプトに応答したかどうかを判断しているが、これは、例えば、発呼者がタッチトーンをもっていないことがあるからである。結果が“１”で、入力された電話番号にエラーがあることを示していれば、ＭＳＡＰ１２０は、RouteToWithData ノード１８４を実行して、呼を「正規の (regular)」（つまり、非専門の）代表者へ転送させる。結果が“２”で、電話番号がＭＳＡＰ１２０によって確認されたことを示していれば、ＭＳＡＰ１２０は、GetData ノード１８６を実行して、顧客プロフィール情報をＧＤＩ１２４に要求する。 GetData 要求に対する結果が“１”で、発呼者が特定マーケットの顧客であることを示していれば、SendDataノード１８７とRouteToWithData ノード１８８が実行され、収集したデータを送信し、発呼者を特定マーケットの顧客を取り扱うことを専門とするエージェントへ転送する経路を選択する。 GetData 要求に対する結果が“２”であり、発呼者が「自宅勤務」であることを示していれば、SendDataノード１８９と RouteToWithDataノード１９０が実行され、収集したデータを送信し、発呼者を「自宅勤務」の顧客を取り扱うことを専門とするエージェントへ転送する経路を選択する。 GetData 要求に対する結果が“３”で、アカウントが在宅アカウントであることを示していれば、GetDigits ノード１９２が実行され、ＩＰ１０４は在宅エージェントまたは自動アプリケーションのどちらかを選択するように発呼者にプロンプトで指示する。発呼者が“０”を入力して、在宅エージェントを選択すると、発呼者は在宅アカウント専門のエージェントへ転送されるようにRouteToWithD ata ノード１９４によって経路選択され、関連データもSendDataノード１９３によってこのエージェントへ送信される。発呼者が他のいずれかのキーを押して、自動アプリケーションを選択すると、Handoverノード１９６が実行され、呼は別の呼処理レコードによって処理される。 GetData 要求に対する結果が“４”で、アカウントが料金未納のため一時中断されたことを示していれば、SendDataノード１９９とRouteToWithData ノード２００が実行され、収集したデータを送信し、呼を収集部門へ転送する経路を選択する。最後に、GetData 要求に対する結果が“５”で、顧客プロフィールが他の選択のどれも満たしていないことを示していれば、発呼者はRouteToWithData ノード２０２によって「正規の」代表者へ転送され、収集したデータはSendDataノード２０１によってこのエージェントへ送信される。次に、取得したデータと呼がどのようにしてエージェント・ワークステーション１１６へ経路選択されるかについて図１０〜図１２を参照して説明する。図１０はＡＣＤ１０８のオペレーションを示すフローチャートである。図１１はＡＣＤプロトコル・ハンドラ１２５のオペレーションを示すフローチャートである。図１２はエージェント・プロトコル・ハンドラ１２７のオペレーションを示すフローチャートである。ＡＣＤ１０８は、一般的に、呼が転送される経路が選択されるのを待っている（ステップ３００）。ＩＰ１０４は呼を特定のエージェントまたはエージェント・グループへ転送する指示をＳＣＰ１０２から受信すると、ＩＰ１０４は公衆交換電話ネットワークを利用して、呼をＡＣＤ１０８へ転送する。ＡＣＤ１０８は呼を受信すると、要求されたサービスを提供する該当のエージェントまたはエージェント・グループ用に設定されたキューに呼を置く（ステップ３０２）。ＡＣＤキューには、発呼者が与えた電話番号、内部発呼者ＩＤ、キューされた呼の状態、および呼がキューに入れられた時刻が含まれている。呼がキューに入れられると、ＡＣＤ１０８はＰＲＯＭＰＴメッセージを、発呼者が入力したアカウント番号および内部発呼者ＩＤと一緒にＡＣＤプロトコル・ハンドラ１２５へ送信する（ステップ３０４）。そのあと、ＡＣＤ１０８は次のイベントのいずれかが起こるまで呼をキューに保持する。すなわち、（１）エージェントが呼を受け付けるように使用可能になった（ステップ３０６）または（２）発呼者が呼を放棄した（ステップ３１４）。エージェントが使用可能になると、ＡＣＤ１０８は呼をそのエージェント・ワークステーション１１６へ転送する。これと同時に、ＡＣＤ１０８はキュー中の呼の状態を「待ち(waiting)」から「接続(connected)」に更新しステップ３０７）、ＡＣＤ１０８が呼を転送した先のエージェント・ワークステーション１１６の内部呼ＩＤおよび位置ＩＤと一緒にＣＯＮＮＥＣＴメッセージをＡＣＤプロトコル・ハンドラ１２５に送信する（ステップ３０８）。ＡＣＤ１０８は呼が完了すると、内部発呼者ＩＤを含むＤＩＳＣメッセージをＡＣＤプロトコル・ハンドラ１２５に出すことによって、ＡＣＤプロトコル・ハンドラ１２５に通知する（ステップ３１２）。発呼者が呼を放棄した場合には、ＡＣＤ１０８は内部発呼者ＩＤと一緒にＡＢＡＮＤメッセージをＡＣＤプロトコル・ハンドラ１２５に送信する。図１１を参照して説明すると、ＰＲＯＭＰＴメッセージを受信すると（ステップ４００）、ＡＣＤプロトコル・ハンドラ１２５は受信したアカウント番号と内部発呼者ＩＤをテーブルにマップする（ステップ４０２）。ＡＣＤプロトコル・ハンドラ１２５がＰＲＯＭＰＴメッセージを受信しなかったとき（ステップ４００）、および、ステップ４０２のあと、ＡＣＤプロトコル・ハンドラ１２５はＣＯＮＮＥＣＴメッセージを探す（ステップ４０４）。ＣＯＮＮＥＣＴメッセージを受信すると、ＡＣＤプロトコル・ハンドラ１２５はエージェント位置ＩＤおよび対応するアカウント番号をエージェント・プロトコル・ハンドラ１２７に転送する（ステップ４０６）。そのあと、ＡＣＤプロトコル・ハンドラ１２５はＤＩＳＣメッセージが受信されたかどうかを判断する（ステップ４１２）。受信されていれば、内部発呼者ＩＤを対応するアカウント番号に変換し（ステップ４０９）、そのアカウント番号に関連するバッファされたデータを破棄するようにエージェント・プロトコル・ハンドラ１２７に指示する（ステップ４１０）。ＡＣＤプロトコル・ハンドラ１２５は、処理を続けてＡＢＡＮＤメッセージが受信されたかどうかを判断する（ステップ４０８）処理を含んでいる。受信されていれば、内部発呼者ＩＤを対応するアカウント番号に変換し（ステップ４０７）、対応するアカウント番号に関連するバッファされたデータを破棄するようにエージェント・プロトコル・ハンドラ１２７に指示する（ステップ４１０）。次に、図１２を参照して説明すると、エージェント・プロトコル・ハンドラ１２７がデータをエージェントへ送信する指示をＧＤＩ１２４から受信すると（ステップ５００）、エージェント・プロトコル・ハンドラ１２７は発呼者から与えられたアカウント番号と対応づけて受信データをバッファする（ステップ５０２）。ＡＣＤプロトコル・ハンドラ１２５からのデータを転送する指示に応答して（ステップ５０４）、エージェント・プロトコル・ハンドラ１２７は、ドメイン・ネーム・サービス（Domain Name Service - ＤＮＳ）を使用して、エージェント位置ＩＤに対応するワークステーション・インターネット・プロトコル・アドレスを取得する（ステップ５０６）。そのあと、エージェント・プロトコル・ハンドラ１２７は、ＡＣＤプロトコル・ハンドラ１２５から受信したアカウント番号に対応する収集したデータをエージェント・ワークステーション・ネットワーク１１５に送信する。エージェント・ワークステーション・ネットワーク１１５は、データ・メッセージに付けられたアドレスを読み取り、その情報をＡＣＤ１０８が呼を転送した先のエージェント・ワークステーション１１６の表示端末１１９に転送する。このようにすると、エージェント・ワークステーション１１６のワークステーションへのデータ配送を、同一サービス・エージェントへの呼の経路選択と協調させることができる。従って、サービス・エージェントはより効果的かつ効率的に顧客にサービスすることができる。エージェントへ送られるデータは、ＭＳＡＰ１２０からＧＤＩ１２４に送られる単一のＴＣＡＰメッセージに含ませるには長すぎることがあるので、ＭＳＡＰ１２０は一連のメッセージにデータを入れてＧＤＩ１２４に送信する必要性が生じることがある。そのような場合には、最初のメッセージが送信されたあと別のメッセージが必要になったときは、後続メッセージがその前に送信されたメッセージの継続であることを示すタグを、そのメッセージに含めておくことが好ましい。エージェント・プロトコル・ハンドラ１２７は、これらの複数メッセージに入っているデータを集積していき、後続メッセージに付いているタグ番号を取り除き、データを単一メッセージに入れてエージェント・ワークステーション・ネットワーク１１５に送信する。エージェント・プロトコル・ハンドラ１２７は、データを破棄するようにエージェント・プロトコル・ハンドラ１２７に指示するメッセージがＡＣＤプロトコル・ハンドラ１２７から受信されるまで（ステップ５０８）、あるいはデータをバッファに置いておくあらかじめ決めた時間期間が経過するまで（ステップ５１２）、データをバッファに置いておく。どちらの場合も、エージェント・プロトコル・ハンドラ１２７はバッファに置かれたデータを破棄する（ステップ５１０）。このタイムリミットの目的は、上述してきた他のタイムリミットの目的と同じように、呼が放棄または切り離されたとき、キューに置かれた呼またはバッファに置かれたデータがなんらかの理由で正しく破棄されなかったため、キューとバッファがオーバロードするのを防止することである。上述したシステムの種々キューに入力される時間は共通タイマ・サーバによって与えることができる。好ましくは、ネットワーク・タイム・プロトコル（Network Time Protocol - ＮＰＴ）は共通タイマ・サーバを同期オフするために利用されている。以上、現在本発明の好適実施形態と方法であると考えられているものを例示して説明してきたが、この分野の精通者ならば理解されるように、本発明は種々の変更と改良が可能であり、本発明の範囲を逸脱しない限り本発明のエレメントは同等機能をもつ別のエレメントに置き換えることが可能である。例えば、上述してきた本発明では、エージェント電話機１１７とエージェント表示端末１１９は別々になっており、別々の通信リンクでシステムをエージェント電話機１１７とエージェント表示端末１１９に接続しているが、この分野の精通者ならば理解されるように、エージェント電話機１１７とエージェント表示端末１１９を単一の通信端末に統合化することが可能であり、また、発呼者からの音声信号とＳＣＰ１０２からのデータを単一の統合サービス・ディジタル・ネットワーク(Integrated Services Degital Network：ＩＳＤＮ)回線上を配達することが可能である。さらに、本発明の範囲を逸脱しない限り、特定のエレメント、手法または実現方法を本発明の教示事項に適応するように様々な変更を行なうことも可能である。従って、本発明は上述した特定実施例および方法に限定されるものではなく、本発明には、請求の範囲に記載されている本発明の範囲に属する一切の実施例が含まれるものである。

【手続補正書】特許法第１８４条の８【提出日】１９９６年９月１７日【補正内容】呼を該当するエージェント・ワークステーション１１６へ配送するようにＡＣＤ１０８に指示することができる。例えば、ある発呼者のアカウントが料金未納のため一時中断されていれば、その発呼者を収集部門へ転送する経路を選択することができる。また、発呼者の回線が自宅事務所で使用されていれば、発呼者を「在宅勤務」アカウント専門のエージェントへ転送する経路を選択することもできる。呼を処理するときに、エージェントが外部システムにストアされたデータをアクセスできるようにすることもできる。図２は、本発明の好適実施例によるＳＣＰ１０２アーキテクチャを示すブロック図である。図示のように、ＳＰＡＣＥ１１８アプリケーションはＭＳＡＰアプリケーション１２０とのインタフェースとなっている。ＳＰＡＣＥはＳＣＰ１０２の外側に示されているが、別の実施例では、ＳＰＡＣＥをＳＣＰ１０２に内蔵させることも可能である。ＭＳＡＰ１２０はメッセージ配達（Message Delivery interface-ＭＤＩ）１２２とやりとりし、このインタフェースを通して、メッセージはＭＳＡＰ１２０から周辺インタフェース（ＰＩ）１２８か汎用データ・インタフェース（generic deta interface：ＧＤＩ）１２４のどちらかに配達される。ＭＳＡＰ１２０はＳＣＰ１０２に置かれているアプリケーションであり、アクセスされた呼処理レコードのサービス・ロジックを実行し、システム１００の他のエレメントに対する指示を出す。ＰＩ１２８はＩＰ１０４とＳＣＰ１０２とを結ぶインタフェースであり、これらの２デバイスはこのインタフェースを通して通信できる。ＧＤＩ１２４はデータ要求をプロトコル・ハンドラ１２６を経由して該当の外部システム１０６へ送信し、外部システム１０６から受け取ったデータを１つのメッセージにパッケージ化し、ＭＳＡＰ１２０へ送られて、そこで使用される。ＧＤＩ１２４はＳＣＰ１０２に置かれているデータまたはＳＣＰ１０２が取り出したデータを外部システムへ送ることもできる。さらに、ＧＤＩ１２４はＡＤＣ１０８およびエージェント・ワークステーション・ネットワーク１１５との間で、それぞれＡＣＤプロトコル・ハンドラ１２５とエージェント・プロトコル・ハンドラ１２７を経由してデータを返信し、取得する。ＰＩ１２８とＧＤＩ１２４は以下で詳しく説明する。ＰＩ１２８はＩＰ１０４とＳＣＰ１０２間のデータ・ネットワーク通信リンクを確立し、維持する。ＰＩ１２８は、ＩＰ１０４とＳＣＰ１０２間でメッセージを非同期送信することを取り扱う。さらに、ＰＩ１２８はメッセージをＩＰ１０４またはＳＣＰ１０２が認識できるフォーマットに変換する。好適実施例では、ＰＩ１２８がサポートするメッセージ・フォーマットは公表されているBellcore ドキュメントTR-TSY-000402(１９８９年７月)（以下、ＴＲ４０２フォーマットと呼ぶ）またはTA-NWT-001129(１９９２年１０月)（以下、ＴＡ１１２９＋フォーマットと呼ぶ）に記載されているが、これらのフォーマットはそれぞれＩＰ１０４とＳＣＰ１０２によって認識されている。なお、他のメッセージ・フォーマットをＩＰ１０４とＳＣＰ１０２で使用することも可能である。正常オペレーション期間には、ＰＩ１２８はＩＰ１０４とＭＳＡＰ１２０からのメッセージを同時に待っている。ＰＩ１２８によって受信されたメッセージはキュー（待ち行列）１２９に追加され、他方、ＰＩ１２８から送信されたメッセージはキュー１２９から除去される。図３はＰＩ１２８の内部インタフェースを示したもので、インタフェースとしては、例えば、ノード・マネージャ・アプリケーション・プログラミング・インタフェース（ＡＰＩ）１３０、ノード管理ＡＰＩ１３２、メインテナンス・オペレーション・コンソール(Maintenance Operations Console - ＭＯＣ)ＡＰＩ１３４、伝送制御プロトコル／インタネット・プロトコル（ＴＣＰ／ＩＰ）ＡＰＩ１３６、構成ファイル１３８、メッセージ配達（ＭＤ）１２２などがある。ノード・マネージャＡＰＩ１３０は、ＳＣＰ１０２内のノードの状態をモニタリングすることによってＳＣＰ１０２の信頼性を維持することを担当する。ノード管理ＡＰＩ１３２は、ＳＣＰ１０２に接続された各ＩＰ１０４のアドレスといった、ＳＣＰ１０２の構成に関する情報を収容している。ＭＯＣＡＰＩ１３４はコンピュータ端末（図示せず）とＳＣＰ１０２とを結ぶインタフェースとなって、例えば、技術者がＳＣＰ１０２で保守を実施できるようにする。ＴＰＣ／ＩＰＡＰＩ１３６はＴＣＰプロトコルを使用して、ＳＣＰ１０２とＩＰ１０４との間のインタフェースを提供する。構成ファイル１３８はＰＩ１２８のオペレーションに関する情報を収めている。このような情報としては、ＩＰ１０４のアドレスを識別し、キュー１２９に置かれたメッセージの優先順位を指定するといった、ＰＩ１２８の構成に関するパラメータなどがある。構成ファイル１３８に対する変更は、ＰＩ１２８の初期化時に行うことが好ましい。好適実施例では、ＰＩ１２８はソフトウェアで実現されている。図４は、ＰＩ１２８の好ましいソフトウェア・モジュールを示すブロック図である。ＰＩ１２８では、メッセージはＩＰ１０４からモジュール１４０によって受信される。受信されたメッセージは次にモジュール１４２によって妥当性検査（バリデーション）され、モジュール１４４によってＭＳＡＰ１２０が認識できるフォーマットにコード化される。モジュール１４６はＭＳＡＰ１２０との間でＭＤ１２２を経由してメッセージを送受信する。モジュール１４８はＭＳＡＰ１２０から受け取ったメッセージを妥当性検査し、モジュール１５０はＡＣＤ１０８によってルート（経路選択）された先のエージェント・ワークステーション１１６の表示端末１１９に送信する。エージェント・プロトコル・ハンドラ１２７は以下で詳しく説明する。以下では、図７に示すフローチャート１６２を参照して、ＧＤＩ１２４がＭＳＡＰ１２０からのデータ要求をどのように処理するかについて説明する。初めに、ＧＤＩ１２４は、以下で詳しく説明するGetData 要求をＭＳＡＰ１２０から受信する（ステップ１６３）。ＧＤＩ１２４はGetData 要求をデコードしてどのデータ・エレメントがＭＳＡＰ１２０によって要求されているかを決定する（ステップ１６４）。データ・エレメント・テーブル１５４を使用して、ＧＤＩ１２４は要求されたデータ・エレメントを得るためにどの外部システム１０６をアクセスすべきかを決定する（ステップ１６５）。データ・エレメント・テーブル１５４はルックアップ・テーブルであり、特定のデータ・エレメントがどの外部システム１０６に置かれているかを示している。以上のように、ＧＩＤ１２４がGetD ata 要求をデコードし、ＭＳＡＰ１２０によって要求された特定データ・エレメントを判定すると、ＧＩＤ１２４は、データ・エレメント・テーブル１５４で特定データ・エレメントに対応する外部システムを調べる。次に、ＧＤＩ１２４はデータ・エレメントを要求する「サブ要求」を該当の外部システムに関連するプロトコル・ハンドラに転送する（ステップ１６６）。未処理要求テーブル１６０は、未処理「サブ要求」の記録をとるように更新される（ステップ１６７）。次に、ＧＤＩ１２４は応答が受信されたかどうかを判断する（ステップ１６８）。応答がＧＩＤ１２４によって外部システム１０６から受信されていれば、未処理要求テーブルは部分的完了の記録をとるように更新される（ステップ１６９）。次に、ＧＤＩ１２４はサブ要求に対する応答がすべて戻されなかったかどうかを判断する（ステップ１７０）。戻されていなければ、ＧＩＤ１２４は他の応答があるかで待つ。応答がすべて受信されていれば、ＧＤＩ１２４は完了メッセージをＭＳＡＰ１２０に返送する（ステップ１７２）。ステップ１６８で、ＧＤＩ１２４が応答が未受信であると判断したとき、あらかじめ決めた時間が経過したときも（ステップ１７１）、メッセージがＭＳＡＰ１２０に返送される（ステップ１７２）。以上のように、メッセージは未処理サブ要求がすべて応答されたときにもタイムアウトが起こったときにもＭＳＡＰ１２０に返送される。請求の範囲１．電話ネットワークにおいて発呼者からの電話呼を処理する方法であり、該電話ネットワークは複数の交換機と、該複数の交換機とサービス制御ポイント（ＳＣＰ）とのインタフェースとなるインテリジェント・インタフェース（ＩＰ）とを含んでいるものにおいて、複数の交換機の１つで電話呼を受信するステップと、電話呼をＳＣＰへ転送するステップと、ＳＣＰが呼処理要求を実行することをＩＰにより要求するステップと、ＳＣＰ内のサービス・ロジックをアクセスするステップであって、該サービス・ロジックは、呼処理要求に従って電話呼を処理する方法を指定しているものと、サービス・ロジック要求に応答して、１つまたは２つ以上の外部システムからのデータをＳＣＰで受信するステップと、サービス・ロジックに従って１つまたは２つ以上の外部システムからデータをＳＣＰで受信するステップと、１つまたは２つ以上の外部システムから受信したデータに基づいて、電話呼を選択した電話機に転送する経路を選択するステップと、受信したデータを選択した電話機に転送する経路を選択するステップとを備えることを特徴とする方法。２．請求項１に記載の方法において、１つまたは２つ以上の外部データ・システムから受信した前記データは、アカウント状態データ、修理情報、顧客プロフィール・データ、および注文情報のいずれかを備えることを特徴とする方法。３．請求項１に記載の方法において、サービス・ロジックをアクセスする前記ステップはマルチサービス・アプリケーション・プラットフォーム（ＭＳＡＰ）によって実行され、データを外部システムに要求する前記ステップは、ＭＳＡＰによって開始されると共に、ＭＳＡＰが汎用データ・インタフェース（ＧＤＩ）に対してデータ要求を出すサブステップを含み、ＭＳＡＰとＧＤＩはメッセージ配達インタフェース（ＭＤＩ）を介して接続されており、ＧＤＩは、受信したデータ要求からのサブ要求を作成するステップと、サブ要求を１つまたは２つ以上の外部システムに転送するステップと、サブ要求に対する応答を１つまたは２つ以上の外部システムから受信するステップと、要求データを収めているメッセージをＭＳＡＰに返送するステップとを実行することを特徴とする方法。４．請求項１に記載の方法において、ＳＣＰはマルチサービス・アプリケーション・プラットフォーム（ＭＳＡＰ）と、ＭＳＡＰと汎用データ・インタフェース（ＧＤＩ）とのインタフェースとなるメッセージ配達インタフェース（ＭＤＩ）とを含み、サービス・ロジックをアクセスする前記ステップはマルチサービス・アプリケーション・プラットフォーム（ＭＳＡＰ）によって実行され、さらに、ＭＳＡＰによって開始されるデータ送信ステップを含んでおり、該ステップは、ＭＳＡＰが汎用データ・インタフェース（ＧＤＩ）に対して送信データ要求を出すサブステップと、ＧＤＩが受信した送信データ要求に応答してサブ要求を作るサブステップと、ＧＤＩがサブ要求を外部システムの１つに転送するサブステップと、ＧＤＩが各サブ要求に関する状態情報を受信するサブステップと、ＧＤＩが送信データ要求の状態を収めているメッセージをＭＳＡＰに返送するサブステップとを備えることを特徴とする方法。５．請求項１に記載の方法において、さらに、受信した電話呼をキューに入れるステップと、受信したデータをストアするステップとを含み、呼を選択した電話機に転送する経路が選択されるのとほぼ同時に選択した電話機に受信したデータを転送する経路が選択されるようにしたことを特徴とする方法。６．請求項５に記載の方法において、さらに、受信した電話呼が切り離されたか、あるいは放棄されたとき、ストアされたデータを破棄するステップを備えることを特徴とする方法。７．請求項１に記載の方法において、さらに、録音された音声メッセージを、呼が受信されたとき発呼者に再生するステップと、発呼者情報を発呼者から受信するステップとを備えることを特徴とする方法。８．請求項１に記載の方法において、データを選択した電話機に転送する経路を選択する前記ステップは、さらに、受信した電話呼が選択した電話機に接続されたことを知らせるメッセージを待つサブステップであって、該メッセージは受信したデータに対応するアカウント番号と電話呼が転送された先の選択した電話機ＩＤを含んでいるサブステップと、電話呼が転送された先の選択した電話機のネットワーク・アドレスを、メッセージに含まれるＩＤに基づいて取得するサブステップと、受信したデータを、取得したネットワーク・アドレスの選択した電話機に転送するサブステップとを備えることを特徴とする方法。９．請求項１に記載の方法において、さらに、ＩＰに対するインタフェース指示をＳＣＰから出力するステップと、インタフェース指示をＩＰで実行するステップとを備えることを特徴とする方法。１０．請求項９に記載の方法において、インタフェース指示は発呼者に対する指示要求を備えることを特徴とする方法。１１．請求項１に記載の方法において、電話ネットワークは自動呼出装置（ＡＣＤ）を含み、該方法はＳＣＰが電話呼をＡＣＤへ転送するようにＩＰに指示するステップをさらに備えることを特徴とする方法。【図１】【図２】【図３】【図４】【図５】【図６】【図７】【図８】【図９】【図１０】【図１１】【図１２】

───────────────────────────────────────────────────── フロントページの続き (72)発明者マーチン，マイケル，アレンアメリカ合衆国 08876 ニュージャージー州ヒルズボロウエストブルックアヴェニュ１ (72)発明者ノヴァック，トーマス，スティーブンアメリカ合衆国 94583 カリフォルニア州サンレイモンマドリッドプレイス 57 (72)発明者ウォーズナック，ロバート，スティーブンアメリカ合衆国 08534 ニュージャージー州ペニントンイングルサイドアヴェニュ 218 【要約の続き】は呼をエージェント［１１６］に転送する経路を選択し、これと同時に、ＧＤＩ［１２４］は要求データをエージェント［１１６］の表示端末［１１９］へ配送させる。

Claims

【特許請求の範囲】１．複数の交換機およびサービス制御ポイント（ＳＣＰ）を含んでいる電話ネットワークにおいて発呼者からの電話呼を処理する方法であって、電話呼を交換機で受信するステップと、呼処理指示をＳＣＰに要求するステップと、呼処理指示に対応する電話呼の処理方法を指定しているサービス・ロジックをＳＣＰでアクセスするステップと、サービス・ロジックに従ってデータを１つまたは２つ以上の外部システムにＳＣＰで要求するステップと、サービス・ロジックに従って１つまたは２つ以上の外部システムからデータをＳＣＰで受信するステップと、１つまたは２つ以上の外部システムから受信したデータに基づいて、電話呼を該当するエージェントに転送する経路を選択するステップと、データを同じエージェントに転送する経路を選択するステップとを備えていることを特徴とする方法。２．請求項１に記載の方法において、１つまたは２つ以上の外部データ・システムから取り出された前記データは、アカウント状態データ、修理情報、顧客プロフィール・データ、および注文情報のいずれかを備えていることを特徴とする方法。３．請求項１に記載の方法において、サービス・ロジックをアクセスする前記ステップはマルチサービス・アプリケーション・プラットフォーム（ＭＳＡＰ）によって実行され、データを取得する前記ステップは、ＭＳＡＰによって開始されると共に、ＭＳＡＰが汎用データ・インタフェース（ＧＤＩ）に対してデータ要求を出すサブステップと、ＧＤＩが受信したデータ要求からのサブ要求を作るサブステップと、ＧＤＩがサブ要求を１つまたは２つ以上の外部システムに転送するサブステップと、ＧＤＩがサブ要求に対する応答を受信するサブステップと、ＧＤＩが要求データを収めているメッセージをＭＳＡＰに返送するサブステップとを備えることを特徴とする方法。４．請求項１に記載の方法において、さらに、サービス・ロジックに従ってＳＣＰからデータを１つまたは２つ以上の外部システムに送信するステップを備えることを特徴とする方法。５．請求項４に記載の方法において、サービス・ロジックをアクセスする前記ステップはマルチサービス・アプリケーション・プラットフォーム（ＭＳＡＰ）によって実行され、データを送信する前記ステップは、ＭＳＡＰによって開始されると共に、ＭＳＡＰが汎用データ・インタフェース（ＧＤＩ）に対して送信要求を出すサブステップと、ＧＤＩが受信した送信要求に応答してサブ要求を作るサブステップと、ＧＤＩがサブ要求を該当の外部システムに転送するサブステップと、ＧＤＩが各サブ要求に関する状態情報を受信するサブステップと、ＧＤＩが送信要求の状態を収めているメッセージをＭＳＡＰに返送するサブステップとを備えることを特徴とする方法。６．請求項１に記載の方法において、さらに、受信した電話呼をキューに入れるステップと、取得したデータをストアするステップと、取得したデータを、呼がエージェントに転送されるのとほぼ同時にエージェントに送信するステップとを備えることを特徴とする方法。７．請求項６に記載の方法において、さらに、受信した電話呼が切り離されたか、あるいは放棄されたとき、ストアされたデータを破棄するステップを備えることを特徴とする方法。８．請求項１に記載の方法において、さらに、録音された音声メッセージを呼が受信されたとき発呼者に再生するステップと、発呼者情報を発呼者から受信するステップとを備えることを特徴とする方法。９．請求項１に記載の方法において、データをエージェントへ経路選択する前記ステップは、さらに、受信した電話呼がエージェントに接続されたことを知らせるメッセージを待つサブステップであって、該メッセージはデータに対応するアカウント番号および呼が転送される経路が選択されたエージェントのエージェント位置ＩＤを含んでいるサブステップと、呼が転送される経路が選択されたエージェントのネットワーク・アドレスを、メッセージに含まれるエージェント位置ＩＤに基づいて取得するサブステップと、取得したネットワーク・アドレスのエージェントにデータを転送するサブステップとを備えることを特徴とする方法。