JPH09501812A

JPH09501812A - 対話型機能を有するネットワークに基づく電話システム

Info

Publication number: JPH09501812A
Application number: JP7520239A
Authority: JP
Inventors: アクマン，アーロン，アーサー; ドネリー，パトリック，ジェイムズ; ホレンバック，スティーヴン，アンドリュウ; クレト，マイケル，アンソニー
Original assignee: ベルコミュニケーションズリサーチ，インコーポレイテッド
Priority date: 1994-01-31
Filing date: 1995-01-30
Publication date: 1997-02-18
Also published as: US5519772A; CA2179498C; CA2179498A1; EP0742980A1; WO1995020857A1; EP0742980A4

Abstract

(57)【要約】サービス制御ポイント（ＳＣＰ）［１０２］を含み、呼処理レコード（ＣＰＲ）をアクセスするネットワークに基づく電話システム［１００］において、知的周辺機器（ＩＰ）［１０４］が発呼者とＳＣＰ［１０２］との間の知的インタフェースを提供する。ＩＰ［１０４］は周辺機器インタフェース（ＰＩ）［１２８］を通してＳＣＰ［１０２」と通信する。外部システム［１０６］は顧客データを得るためにジェネリック・データ・インタフェース（ＧＤＩ）［１２４］を通してＳＣＰ［１０２］によりアクセスされる。ＧＤＩ［１２４］は種々の外部システム［１０６］にストアされたデータの追跡をし続ける。データの要求を受信すると、ＧＤＩ［１２４］はサブ要求を形成し、適当な外部システム［１０６］へサブ要求をルートし、要求されたデータを含むメッセージを戻す。

Description

【発明の詳細な説明】対話型機能を有するネットワークに基づく電話システム発明の背景本発明は一般的にはネットワークに基づく電話システムの分野に関し、より詳しくは発呼者(caller)とネットワークに基づく電話システムとの間の対話および外部システムからのデータへのアクセスの問題に関する。本明細書の一部分を構成する特許出願は、カスタマイズされた電気通信サービスを作りだしネットワークにおけるそのサービスを具体化し維持するためのシステムと方法を述べている。このシステムは、サービスの供給と作成環境(Service Provisioning and Creation Environment:ＳＰＡＣＥ（登録商標）)という応用を含み、それは呼処理レコード(呼設定受付レコード−call processing records :ＣＰＲｓ)を作成する。ＣＰＲｓは、受信した電話呼出しが特定の顧客に対していかに処理されるかを定義する。ＣＰＲｓは、サービス制御ポイント(service c ontrol points:ＳＣＰｓ)に転送されてサービスを実現する。本明細書の一部分を構成する特許出願において説明されているように、ネットワークにおける交換機は受信した呼(call)をＳＣＰへルート(route:経路選択)する。ＳＣＰにおける多重サービス応用プラットフォーム(Multi-services Applic ation Platform:ＭＳＡＰ)は、その呼に関連した「キー(key)」に基づくＣＰＲにアクセスする。ＭＳＡＰは、ＣＰＲのノードを処理し対応する呼処理命令を発行して交換機へ戻す。交換機はこの命令に基づいて呼をルートする。本明細書の一部分を構成する特許出願において説明されているように、ＣＰＲを実行する一方、ＳＣＰはあるノードに基づく発呼者からの情報を要求できる。しかし、ＳＣＰが要求できる情報のタイプは幾分制限されている。例えば、ＳＣＰは発呼者に要求してＰＩＮ番号を挿入できる。発呼者とＳＣＰとの間のこの限定された対話は呼を完了するには不十分であり、サービス・エージェントに介在させ手動的に呼を処理することを要求する。手動呼処理は自動化された呼処理より一般的により遅く、より費用がかかる。本明細書の一部分を構成する特許出願においてまた述べてあるように、ＭＳＡＰは外部システムからの情報をアクセスできない。事実、ＭＳＡＰはＭＳＡＰ側で利用可能である情報をアクセスできるのみである。しかし、この情報はＣＰＲを正しく実行するには不十分である。従って、電話呼出しを処理するためにはシステムの知能を増加させることが望ましい。電話呼出しを処理するためにはシステムにおける柔軟性を増加させることが望ましい。電話呼出しを処理するためには発呼者とシステムとの間のより大きい対話を提供することが望ましい。電話呼出しを処理するためにはシステムによる外部システムからの情報へのより大きいアクセス可能性を提供することが望ましい。サービス・エージェントへ呼を方向づける既存のプロセスを増加することが望ましい。発呼者に関する情報に基づいて適当なエージェントへ発呼者をルートすることが望ましい。呼とその関連したデータを適当なエージェントへルートすることを提供することが望ましい。発呼者を適当なエージェントへルートする際のネットワーク信頼性を提供することが望ましい。本発明のさらなる所望の点は以下の説明に示され、部分的には説明から明らかとなるかまたは、本発明の実施により学ぶことができる。本発明の利点は、添付の請求の範囲において特に指摘された手段および組合わせにより実現され、かつ得ることができる。発明の開示前述の所望の点と目的を達成するために、およびここで実施され広く記述された本発明の目的によれば、本発明は、知的周辺機器(intelligent peripheral:ＩＰ)、サービス制御ポイント(service control point:ＳＣＰ)、および外部データ・システムを含むアドバンスド・インテリジェント・ネットワーク(Advanced Intelligent Network:ＡＩＮ)のようなネットワークに基づく電話システムにおいて、発呼者から呼をＩＰが受信するステップと、ＳＣＰからの呼処理命令をＩＰが要求するステップと、呼処理レコードをＳＣＰがアクセスするステップと、サービス・ロジックに基づき発呼者からの情報を集めるためのＩＰをＳＣＰが命令するステップと、サービス・ロジックに基づき外部データ・システムからのアカウント・データをＳＣＰがアクセスするステップとを備えた、呼を処理する方法を提供する。さらに、本発明は、アクセスした呼処理レコードのサービス・ロジックに従う命令を発行するためのサービス制御ポイント（ＳＣＰ）と、該サービス制御ポイントからの命令に従ってシステムと発呼者とをインタフェースするための知的周辺機器（ＩＰ）と、該サービス制御ポイントからの命令に従ってデータへのアクセスを提供するための外部システムとを備えた、発呼者からの受信した呼と関連したサービス・ロジックを有する呼処理レコードを実行するためのネットワークに基づく電話システムを提供する。図面の簡単な説明添付の図面は、明細書に組み込まれその一部分を構成するものであり、本発明の現在の好適実施例を例示し、上述の一般的説明と以下の好適実施例の詳細な説明とともに、本発明の原理を説明するのに役立つものである。図面において、図１は、本発明によるネットワークに基づく電話システムのブロック図である。図２は、本発明によるサービス制御ポイント（ＳＣＰ）のブロック図である。図３は、本発明による周辺機器インタフェース（ＰＩ）の内部インタフェースを示す図である。図４は、本発明によるＰＩに対応するソフトウェア・モジュールの図式的表現の図である。図５は、本発明の好適実施例による複数のＰＩとインタフェースされた複数の知的周辺機器（ＩＰｓ）を有する構成を示す図である。図６は、本発明によるジェネリック・データ・インターフェース(generic dat a interface:ＧＤＩ)とインタフェースする内部テーブルを例示する図である。図７は、本発明の好適実施例によるＧＤＩの操作を例示するフローチャートを示す図である。図８は、本発明による未解決要求テーブル(Outstanding Request Table)におけるサブ要求(sub-requests)を例示する図である。図９は、本発明による呼処理レコードの例を例示する図である。発明を実施する最良の形態図１に示すように、ネットワークに基づく電話システム１００の好適実施例、またはアドバンスド・インテリジェント・ネットワーク(Advanced Intelligent Network:ＡＩＮ)１００は、公衆交換ネットワーク１１０、複数の電話１１２（１つのみ示す）、自動呼分配器(automatic call distributor:ＡＣＤ)１０８、知的周辺機器(intelligent peripheral:ＩＰ)１０４、サービス制御ポイント(se rvice control point:ＳＣＰ）１０２、外部システム１０６、および複数のエージェント１１６（１つのみ示す）を含む。公衆交換ネットワーク１１０はＩＰ１０４とＡＣＤ１０８に接続される。ＡＣＤ１０８はエージェント１１６に接続される。ＩＰ１０４はまたＳＣＰ１０２に接続され、ＳＣＰ１０２は外部システム１０６に接続される。エージェント１１６はまた外部システム１０６に接続される。電話１１２の発呼者によりかけられた呼は、公衆交換ネットワーク１１０により受信されてＩＰ１０４へ転送される。好適実施例において、ＡＣＤ１０８はＡＴ＆Ｔ５ＥＳＳＰｉｎｎａｃｌｅＡＣＤであるが、しかしＡＣＤのどのような既知のタイプのものでも使用できる。ＩＰ１０４の機能の１つは、電話１１２の発呼者との知的通話周辺機器(intel ligent speech peripheral)としてインタフェースをとることである。例えばＩＰ１０４は、発呼者へのディジタル化されたアナウンスの役割を好適に演じ、発呼者に呼処理情報の入力を促し、呼処理情報を集めることができる。ある呼がＩＰ１０４へ公衆交換ネットワーク１１０からルートされる場合、ＩＰ１０４はその呼の処理方法についてＳＣＰ１０２からの命令を要求する。以下でより詳細に説明されるように、ＳＣＰ１０２は呼処理レコードに基づいてＩＰ１０４へのインタフェース命令を提供する。従って、発呼者−ＩＰ１０４接続は知的対話型通信となり、これには発呼者により提供された情報に応答してＩＰ１０４へ命令を提供するＳＣＰ１０２も共に入る。ＩＰ１０４と関連するＳＣＰ１０２の使用は、呼処理を自動化して日常のタスクを処理するためのエージェント時間を実質的に減らす。ＩＰ１０４はまた自動市外ダイヤリング(automatic outbound dialing)のような付加的機能を提供するのが好適である。ＩＰ１０４は、ＳＣＰ１０２から受信した命令に従って外の電話１１２に電話をかける。好適実施例において、ＩＰ１０４はＰｅｒｉｐｈｏｎｉｃｓＶＰＳ９０００またはＢｅｌｌｃｏｒｅＩｎｔｅｌｌｉｇｅｎｔＳｅｒｖｉｃｅｓＰｅｒｉｐｈｅｒａｌ（ＩＳＰ）ｖｅｒｓ．１．０である。外部システム１０６はデータベースまたは他のネットワークに基づくシステムを好適に含み、それらは呼を処理する上で役に立つデータを含むものであり、例えば、アカウント状態データ(account status data)、修理情報、顧客プロフィール・データ、および注文情報などを含むものである。アカウント状態データは、顧客が料金をきちんと払っているかどうか、または顧客のサービスが不払いのために中断(suspend)されているかどうかを示す。修理情報は、特定の電話線にされた修理と、特定の線が使用されているかどうかと、特定の線が経験している問題のタイプとを示す。顧客プロフィール・データは、顧客の電話を方向づける上で有用である顧客に関する情報、例えば設置されたサービスのタイプおよび顧客の電話線の地理的な位置などを含む。注文情報は、例えば特定の顧客に対するサービスのコストおよびサービスの可能性(availabil ity)を含むことができる。上述したように、ＡＣＤ１０８はＳＣＰ１０２により受信された命令に従ってエージェント１１６へ呼をルートすることもできる。エージェント１１６は、種々の顧客のニーズを処理できる通例の(regular)サービス・エージェントか、または特定の顧客のニーズを処理できる専門的な(specialized)サービス・エージェントである。ＩＰ１０４および外部システム１０６から受信した情報に基づき、ＳＣＰ１０２はＡＣＤ１０８に方向づけをおこなって呼を適当なエージェント１１６にルートさせることもできる。例えば、発呼者のアカウントが不払いのために中断している場合は、発呼者は回収部門(collections department)にルートされる。または、発呼者の線がホーム・オフィスで使用されている場合は、発呼者は「在宅勤務(work-at-home)」アカウントに特化されているエージエントにルートされる。呼を処理する上で、エージェント１１６は外部システムにストアされたデータへアクセスできる。図２は、本発明の好適実施例によるＳＣＰ１０２のアーキテクチャのブロック図を示す。サービスの処理と作成環境(Service Processing and Creation Envir onment:ＳＰＡＣＥ（登録商標）)という応用は多重サービス応用プラットフォーム（ＭＳＡＰ）応用１２０とのインタフェースをとる。ＭＳＡＰ１２０は、メッセージ配送(Message Delivery:ＭＤ)インタフェース１２２と通信し、それはメッセージをＭＳＡＰ１２０から周辺機器インタフェース(peripheral interface: ＰＩ）１２８かまたはジェネリック・データ・インタフェース（ＧＤＩ）１２４のいずれかに配送する。ＰＩ１２８は、ＩＰ１０４のＳＣＰ１０２に対するインタフェースをとりこれらの２つの装置が通信できるようにする。ＧＤＩ１２４は、データに対する要求を適当な外部システム１０６に対してプロトコル・ハンドラ１２６経由で送信し、外部システム１０６から受信したデータをパッケージ化してＭＳＡＰ１２０へ送信され、かつＭＳＡＰ１２０により使用されるメッセージにする。ＰＩ１２８およびＧＤＩ１２４は以下で詳細に説明される。ＭＳＡＰ１２０は、ＳＣＰ１０２に常駐するアプリケーションであり、アクセスされた呼処理レコードのサービス・ロジックを実行してシステム１００の他の要素への命令を発行する。ＰＩ１２８は、ＩＰ１０４とＳＣＰ１０２との間のデータ・ネットワーク通信リンクを確立し維持する。ＰＩ１２８はまた、ＩＰ１０４とＳＣＰ１０２との間のメッセージの非同期送信(asynchronous transmission)を処理する。さらに、ＰＩ１２８はメッセージを変換して、ＩＰ１０４またはＳＣＰ１０２のいずれかにより理解されるフォーマットにする。好適実施例において、ＰＩ１２８によりサポートされるメッセージ・フォーマットは、一般に出版されたＢｅｌｌｃｏｒｅドキュメントＴＲ−ＴＳＹ−０００４０２、１９８９年７月（以下「ＴＲ４０２フォーマット」という）、およびＴＡ−ＮＷＴ−００１１２９、１９９２年１０月（以下「ＴＡ１１２９＋フォーマット」という）、それぞれＩＰ１０４およびＳＣＰ１０２により理解されるものにおいて説明される。しかし、他のメッセージ・フオーマットはＩＰ１０４およびＳＣＰ１０２により使用できる。正常な操作の間、ＰＩ１２８はＩＰ１０４およびＭＳＡＰ１２０からのメッセージを同時に待っている。ＰＩ１２８により受信されたメッセージは、待ち行列１２９に加えられ、一方ＰＩ１２８から送信されたメッセージは、該待ち行列１２９から削除される。図３は、ＰＩ１２８の内部インタフェースを示す図であり、ノード・マネージャ・アプリケーション・プログラミング・インタフェース(Node Manager Applic ation Programming Interface:ＡＰＩ)１３０)ノード・アドミニストレーション (Node Administration)ＡＰＩ１３２、メンテナンス・オペレーションズ・コンソール(Maintenance Operations Console:ＭＯＣ)ＡＰＩ１３４、ＴＣＰ／ＩＰＡＰＩ１３６、構成ファイル１３８、およびメッセージ配送(Message Delivery: ＭＤ）１２２を含む。ノード・マネージャＡＰＩ１３０は、ＳＣＰ１０２におけるノードの状態をモニターすることによりＳＣＰ１０２の信頼性を維持する責任がある。ノード・アドミニストレーションＡＰＩ１３２は、ＳＣＰ１０２に接続された各ＩＰ１０４のアドレスのようなＳＣＰ１０２の構成と考えられる情報を含む。ＭＯＣＡＰＩ１３４は、図示されていないコンピュータ端末とＳＣＰ１０２とのインタフェースをとって、例えば技術者がＳＣＰ１０２の維持を行うことを可能にする。ＴＣＰ／ＩＰＡＰＩ１３６は、ＴＣＰプロトコルを使用してＳＣＰ１０２とＩＰ１０４との間のインタフェースを提供する。構成ファイル１３８は、ＰＩ１２８の操作に関する情報を含む。この情報は、ＰＩ１２８を構成するためのパラメータを含み、これは例えば複数のＩＰ１０４のアドレスを識別し、待ち行列１２９内のメッセージの優先度を指定するものである。構成ファイル１３８の変化は、ＰＩ１２８の初期化に好適に影響をもたらす。好適実施例において、ＰＩ１２８はソフトウェアとして実現される。図４は、ＰＩ１２８の好適ソフトウェア・モジュールのブロック図を示す図である。ＰＩ１２８において、メッセージはモジュール１４０によりＩＰ１０４から受信される。この受信されたメッセージは、次にモジュール１４２によりバリデーション (validation：有効性検証)を行われ、モジュール１４４によりＭＳＡＰ１２０が理解できるフォーマットに符号化される。モジュール１４６は、ＭＤ１２２を通してＭＳＡＰ１２０とメッセージを送受信する。モジュール１４８はＭＳＡＰから受信したメッセージのバリデーションを行い、モジュール１５０はこのメッセージを符号化してＩＰ１０４が理解できるフォーマットにする。モジュール１５２はＩＰ１０４へのメッセージを提供する。受信したメッセージを処理する上で、ＰＩ１２８は変換が必要かどうかを決定する。必要な場合は、ＰＩ１２８は受信したメッセージを復号化しこのメッセージが有効であるかどうかを決定する。ＰＩ１２８は次に、このメッセージを変換して変換テーブル（図示されず）を使用して受信装置により理解されるフォーマットにする。例えば、ＩＰ１０４によりＳＣＰ１０２から受信されるメッセージは、ＴＲ４０２フォーマットｋａｒａＴＡ１１２９＋フォーマットへ変換され、逆もまた同様である。ＰＩ１２８がＩＰ１０４から無効なメッセージを受信する場合、このメッセージは落とされこのメッセージの先の処理は終わる。ＩＰ１０４のタイマは次にこのメッセージを再送し呼を転送する。ＰＩ１２８が不適当にフォーマットされたメッセージをＭＳＡＰ１２０から受信する場合は、ＰＩ１２８はＭＳＡＰ１２０へエラー・メッセージを返す。図５は、高度なシステム信頼性を提供するために複数のＩＰ１０４とＳＣＰ１０２との間に冗長な接続を有する本発明の好適実施例を示す図である。ＳＣＰ１０２は、複数のＰＩ１２８の各々へ「ラウンドーロビン(round-robin)」形式でトランザクションを分散させる。複数のＰＩ１２８は、１つ以上のＩＰ１０４と冗長な接続をするように構成される。従って、失敗した接続の場合は、メッセージはＩＰ１０４とＳＣＰ１０２との間でまだ送信可能である。各ＰＩ１２８は冗長な接続を含んですべての構成された接続が常にアクティブに保たれるように試みる。ＰＩ１２８はその回路接続の各々の一般的状態のログをとり、それは接続が良好(good)、低下(degraded)、不良(poor)かどうかを示す。良好な接続は、すべての構成された接続がアクティブであることを示す。低下した接続は、少なくとも１つ、しかしすべてではない接続が失敗したことを示す。不良な接続は、すべての接続が失敗したことを示す。いっさいの接続が失敗した場合、ＰＩ１２８における周期タイマ・メカニズム (periodic timer mechanism)は、ＰＩ１２８があらかじめ決められた時間の後、接続を確立する別の試みを行わせる。すべての構成された回路がアクティブである場合、ＰＩ１２８はその周期タイマ・メカニズムを停止(deactivates)する。アクティブな回路が予期しないエラーを返す場合はその回路は障害がおきたものと考えられ、ＰＩ１２８の周期タイマは再起動し、その回路を再確立するための試みがなされる。回路上に受信された不良に形成されたメッセージは、回路障害 (circuit failure)がおきているためと考えられ、ＰＩ１２８の周期タイマが付勢(activation)されることになる。ＧＤＩ１２４は、ＭＳＡＰ１２０にその情報のソースについて知ることなく情報を要求することを許容することにより、ＭＳＡＰ１２０に外部システム１０６にストアされた情報へのトランスペアレントなアクセス(transparent access)を与える。図６は、情報に対する要求を処理するためのＧＤＩ１２４にストアされた内部テーブルを例示する。このテーブルは、データ・エレメント・テーブル１５４、ＧＤＩ待ち行列テーブル１５６、外部システム・テーブル１５８、および未解決要求テーブル１６０を含む。データ・エレメント・テーブル１５４は、ＧＤＩ１２４により使用されてデータに対する要求を適当な外部システム１０６へ転送する。ＧＤＩ待ち行列テーブル１５６は、ＧＤＩ１２４およびプロトコル・ハンドラ(protocol handlers)１２６により使用されてメッセージを交換するために使用する待ち行列の名前を決定する。外部システム・テーブル１５８は、プロトコル・ハンドラ１２６により使用されて外部システムと通信するためのアドレッシング情報を得る。未解決要求テーブル１６０は、ＧＤＩ１２４により未解決要求のリスト(list of outstanding requests)を維持するために使用される。プロトコル・ハンドラ１２６は、外部システム１０６への物理的および論理的接続を管理し、情報を検索するために外部システム１０６と対話処理する。好適実施例では、各外部システム１０６は対応するプロトコル・ハンドラ１２６を有する。図７に示されるように、フローチャート１６２はＧＤＩ１２４がデータに対する要求をいかに処理するかを示す。最初にＧＤＩ１２４は、以下で詳細に説明されるＧｅｔＤａｔａ要求を、ＭＳＡＰ１２０から受信する（ステップ１６３）ＧＤＩ１２４は、ＧｅｔＤａｔａ要求を復号化してＭＳＡＰ１２０により要求される特定のデータ・エレメントを決定する（ステップ１６４）。データ・エレメント・テーブル１５４を使用して、ＧＤＩ１２４は、要求されたデータ・エレメントを得るためにアクセスされるべき外部システム１０６を決定する（ステップ１６５）。ＧＤＩ１２４は次に、データ・エレメントを要求する「サブ要求(sub-r equests)」を適当な外部システムと関連したプロトコル・ハンドラへ転送する（ステップ１６６）。未解決要求テーブル１６０は、未解決の「サブ要求」を追跡し続けるために更新される（ステップ１６７）。ＧＤＩ１２４は次に、返信が受信されたかどうかを決定する（ステップ１６８）。返信が外部システム１０６からＧＤＩ１２４により受信される場合、未解決要求テーブルは部分的完了の跡を保持するために更新される（ステップ１６９）。ＧＤＩ１２４は次に、サブ要求へのすべての返信が返らなかったかどうかを決定する（ステップ１７０）。返らなかった場合、ＧＤＩ１２４は追加の返信を待つ。すべての返信が受信された場合、ＧＤＩ１２４は完了メッセージをＭＳＡＰ１２０へ返す（ステップ１７２）。ステップ１６８でＧＤＩ１２４が返信は受信されなかったと決定する場合は、あらかじめ決められた時間が過ぎると（１７１）、メッセージがまたＭＳＡＰ１２０へ戻される（ステップ１７２）。したがって、すべての未解決サブ要求が応答されるかまたは時間切れとなる場合、メッセージはＭＳＡＰ１２０へ戻される。図８は、ＧＤＩ未解決要求テーブル１６０を示す。ブロックＡ、Ｂ、およびＣはＭＳＡＰ１２０からＧＤＩ１２４により受信された未解決要求を表す。ブロックＡ１、Ａ２、およびＡ３、Ｂ１、Ｂ２、およびＢ３、Ｃ１、Ｃ２、およびＣ３は、未解決要求Ａ、Ｂ、およびＣからそれぞれ作られたサブ要求を表す。ブロックＡＩＲ、Ａ２Ｒ、およびＢ３Ｒはサブ要求Ａ１、Ａ２、およびＢ３にそれぞれ応答してＧＤＩ１２４により受信された応答を表す。未解決要求テーブル１６０は、ＭＳＡＰ１２０からの情報に対する各要求がＧＤＩ１２４により受信されるときに構成され、そして更新される。ＭＳＡＰ１２０から要求を受信すると、ＧＤＩ１２４はサブ要求を作り、それは適当なプロトコル・ハンドラへ転送される。ＧＤＩ１２４は、各未解決サブ要求に対する応答を待つ。３つのタイプの応答を未解決要求テーブル１６０にストアすることができる。第１に、ＧＤＩ１２４は外部システム１０６からの応答Ａ１Ｒをストアでき、これは結果がサブ要求に応答して受信されたことを示す。第２に、ＧＤＩ１２４は外部システム１０６からの応答Ａ２Ｒをストアでき、これはエラーが外部システム１０６から受信されたことを示す。そのようなエラーは、外部システム１０６がサブ要求を処理できないことを示すようにしてもよい。最後に、ＧＤＩ１２４は応答Ｂ３Ｒをストアでき、これはあらかじめ決められた時間内に、外部システム１０６から何ら応答が受信されなかったことを示す。本明細書の一部分を構成する特許出願において説明されているように、ノードは、呼処理の間実行される論理操作を定義する基本ユニットである。ＭＳＡＰ１２０はこのノードを処理して、システム１００の他の要素への対応する要求または命令を発行する。本明細書の一部分を構成する特許出願は、ＧｅｔＤａｔａ、ＳｅｎｄＤａｔａ、およびＷａｉｔＦｏｒＥｖｅｎｔノードを含む、ＭＳＡＰ１２０によりサポートされる種々のノードを記述している。本発明の好適実施例において、ＧｅｔＤａｔａ、ＳｅｎｄＤａｔａ、およびＷａｉｔＦｏｒＥｖｅｎｔノードは以下に説明されるように変更できる。本発明もまた以下に説明されるようにＴｒａｎｓｆｅｒＣａｌｌノードを考慮している。ＧｅｔＤａｔａノードは、ＭＳＡＰ１２０が特定のアカウントのために外部システム１０６からのデータを要求できるようにする。ＭＳＡＰ１２０により発行されたＧｅｔＤａｔａ要求はハンドル・コール変数(handle call variable)、アカウント(accounts)ＩＤ、およびコール変数のリストを含む。ハンドル・コール変数は、ＧｅｔＤａｔａ要求を識別し、この要求された情報を検索するのに用いられ、この要求の状態をチェックする。アカウントＩＤは発呼者のアカウントを識別する。コール変数のリストは、外部システムからのＭＳＡＰ１２０により要求されたデータを指定する。ＭＳＡＰ１２０からＧｅｔＤａｔａ要求を受信すると、ＧＤＩ１２４は上述の要求されたデータを含む外部システム１０６を決定する。ＧＤＩ１２４は、ＭＳＡＰ１２０から受信したＧｅｔＤａｔａ要求に基づくサブ要求をフォーマットして適当な外部システムへ送信する。ＧＤＩ１２４は、ＭＳＡＰ１２０へ要求された情報のすべてが戻る前に、各サブ要求に対する応答を待つ。ＧＤＩ１２４が、あらかじめ決められた時間の後すべてのサブ要求への応答を受信しない場合は、受信したデータといっしよにＭＳＡＰ１２０へエラー表示が戻される。ＧＤＩ１２４からＭＳＡＰ１２０へ情報を戻すことができる一方、この情報は、ＭＳＡＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノードを実行する後まではＭＳＡＰ１２０により使用可能ではない。ＳｅｎｄＤａｔａノードは、ＭＳＡＰ１２０がデータを外部システム１０６へ送ることができるようにする。外部システム１０６へＭＳＡＰ１２０により発行されたＳｅｎｄＤａｔａ要求は、ハンドル・コール変数、アカウントＩＤ、および対応するデータといっしよにコール変数のリストを含む。ハンドル・コール変数はＳｅｎｄＤａｔａ要求を識別し、この要求の状態を得るために使用される。コール変数のリストに対応する情報は、アカウントＩＤに従い外部システム１０６にストアされる。ＭＳＡＰ１２０からＳｅｎｄＤａｔａ要求を受信すると、ＧＤＩ１２４はどの外部システム１０６へこのデータを送るべきかを決定する。ＧＤＩ１２４は受信したＳｅｎｄＤａｔａ要求からのデータをフォーマットして、このフォーマットされたデータを適当な外部システム・プロトコル・ハンドラへ送信する。ＧＤＩ１２４は、ＭＳＡＰ１２０への状態応答(status reply)を送る前にデータが受容されたことを示す、プロトコル・ハンドラからの肯定応答(positive acknowledg ement)を待つ。しかしＳｅｎｄＤａｔａ要求の状態は、ＭＳＡＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノード実行した後まではＭＳＡＰ１２０には使用可能ではない。ＷａｉｔＦｏｒＥｖｅｎｔノードはＭＳＡＰ１２０にＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求のデータまたは状態へのアクセスを与える。ＷａｉｔＦｏｒＥｖｅｎｔ命令は、ハンドル・コール変数を指定し、それはＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求において指定されたハンドル・コール変数に対応する。ＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求からＭＳＰ１２０へ戻されたすべての要求は、ＭＳＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノードを実行した後まではＭＳＰ１２０には使用可能ではない。ＷａｉｔＦｏｒＥｖｅｎｔ命令が発行された場合は、要求された情報が戻されるまでさらに先の命令がＭＳＡＰ１２０により実行されることはない。応答が戻った場合は、要求において指定されたコール変数へ情報が割り当てられて要求の状態が戻される。ＧＤＩ１２４が要求された情報を検索している間、ＭＳＡＰ１２０は追加の命令をＩＰ１０４へ発行できる。それは例えば、発呼者から追加の情報を得たりＷａｉｔＦｏｒＥｖｅｎｔ要求が発行される前にディジタル化されたメッセージをながし(play)たりするためである。この方法では、発呼者１１２は要求への応答を受信するためにＭＳＰ１２０を単に待つのではない。ＴｒａｎｓｆｅｒＣａｌｌノードは、ＭＳＡＰ１２０が公衆交換ネットワーク１１０に指示して、発呼者１１２に関するデータと一緒に呼をエージェント１１６へルートできるようにする。ＴｒａｎｓｆｅｒＣａｌｌ命令は、転送番号とアカウント番号を含むのが好適であり、例えばＡＣＤ１０８へ転送される。そこでは、呼は発呼者１２２に関するアカウント情報と一緒に転送番号により識別される専門化したエージェント１１６へルートされる。システム１００の操作を例示するために、図９は数２１０により指定される呼処理レコードの例を示す図である。この例において、呼処理レコード２１９は発呼者をその発呼者のプロフィールに基づいた「専門化」エージェントへルートする。受信した呼がＩＰ１０４へルートされた後、ＩＰ１０４はＳＣＰ１０２からの呼処理命令を要求する。アカウント番号または電話番号のような呼においてあらかじめ決められた情報に基づいて、ＳＣＰ１０２はＭＳＡＰ１２０の制御下で、対応する呼処理レコード２１０を実行する。図９の例に示されるように、ＳＣＰ１０２はＩＰ１０４に指示して、ディジタル化されたアナウンスで発呼者を迎える、ＰｌａｙＡｎｎｏｕｎｃｅｍｅｎｔ１８０を行わせる。ＧｅｔＤｉｇｉｔｓノード１８２によりＩＰ１０４は発呼者に依頼して発呼者のアカウント番号または電話番号を入力させる。結果が「１」の場合は入力した電話番号がエラーであることを示し、ＭＳＡＰ１２０はＲｏｕｔｅＴｏノード１８４を実行して呼が「通例の」（すなわち非専門化した）代理にルートされるようにする。結果が「２」の場合は電話番号がＭＳＡＰ１２０により確認されたことを示し、ＭＳＡＰ１２０はＧｅｔＤａｔａノード１８６を実行してＧＤＩ１２４から顧客プロフィール情報を要求する。要求への結果が「１」である場合は発呼者が特定の市場顧客であることを示し、ＲｏｕｔｅＴｏノード１８８が実行されて、特定の市場顧客を処理することに専門化したエージェントへ発呼者をルートする。要求への結果が「２」である場合は発呼者が「在宅勤務している」ことを示し、ＲｏｕｔｅＴｏノード１９０が実行されて、「在宅勤務している」顧客を処理することに専門化したエージェントへ発呼者をルートする。要求への結果が「４」である場合はアカウントが住宅用アカウントであることを示し、ＧｅｔＤｉｇｉｔｓノード１９２が実行されて、ＩＰ１０４が発呼者を促して住宅用エージェントまたは自動化された応用の間の選択をさせる。発呼者が住宅用エージェントを選択する「０」を入力する場合、発呼者はＲｏｕｔｅＴｏノード１９４により住宅用アカウントに専門化したエージェントへルートする。発呼者が他のキーを押す場合は自動化した応用を示すことになるが,Ｈａｎｄｏｖｅｒノード１９６が実行されて、呼が別の呼処理レコードにより処理される。要求への結果が「５」である場合はアカウントが不払いのために中断したことを示し、ＲｏｕｔｅＴｏノード２００が実行されて、呼は回収部門へルートされる。最後に、要求への結果が「６」である場合は顧客ｐロフィールが他の選択のどれも満たさないことを示し、呼はＲｏｕｔｅＴｏノード２０２により「通例の」代理へルートされる。本発明の好適実装および方法であると現在考えられるものを例示し説明してきたが、当業者により理解されるように、種々の変形および変更が可能であり、本発明の真の範囲から逸脱することなく均等物による要素の置換が可能である。付け加えるに、多くの変更が、本発明の中心的範囲から逸脱することなく、特定の要素、技術、または実施を本発明の教示に適合するためになされることが可能である。従って、本発明はここで開示された特定の実施例および方法に制限されるものではなく、本発明は添付の請求の範囲内に入るすべての実施例を含むことを意図する。

【手続補正書】特許法第１８４条の８【提出日】１９９５年１１月２２日【補正内容】（原文第１頁）明細書対話型機能を有するネットワークに基づく電話システム発明の背景本発明は一般的にはネットワークに基づく電話システムの分野に関し、より詳しくは発呼者(caller)とネットワークに基づく電話システムとの間の対話および外部システムからのデータへのアクセスの問題に関する。この特許出願は、″Method of Creating a Telecommunication Service Templ ate″「電気通信サービス・テンプレートを作成する方法」という名称で１９９５年１０月３日に発行された米国特許第５，４５５，８５３号、および″A Meth od of Creating s Telecommunications Service Specification″「電気通信サービス仕様を作成する方法」という名称で１９９５年９月９日に発行された米国特許第５，４５０，４８０号に関する。これらの特許はともにここでは「本明細書の一部分を構成する特許」と引用される。前述の各特許の内容はここでそれを参照することにより本明細書の一部を構成するものとする。本明細書の一部分を構成する特許は、カスタマイズされた電気通信サービスを作りだしネットワークにおけるそのサービスを具体化し維持するためのシステムと方法を述べている。このシステムは、サービスの供給と作成環境(Service Pro visioning and Creation Environment:ＳＰＡＣＥ（登録商標）)という応用を含み、それは呼処理レコード(呼設定受付レコード−call processing records:ＣＰＲｓ)を作成する。ＣＰＲｓは、受信した電話呼出しが特定の顧客に対していかに処理されるかを定義する。ＣＰＲｓは、サービス制御ポイント(service con trol points:ＳＣＰｓ)に転送されてサービスを実現する。本明細書の一部分を構成する特許において説明されているように、ネットワークにおける交換機は受信した呼(call)をＳＣＰへルート(route:経路選択)する。ＳＣＰにおける多重サービス応用プラットフォーム(Multi-services Applicatio n Platform:ＭＳＡＰ)は、その呼に関連した「キー(key)」に基づくＣＰＲにアクセスする。ＭＳＡＰは、ＣＰＲのノードを処理し対応する呼処理命令を発行して交換機へ戻す。交換機はこの命令に基づいて呼をルートする。本明細書の一部分を構成する特許出願において説明されているように、ＣＰＲを実行する一方、ＳＣＰはあるノードに基づく発呼者からの情報を要求できる。しかし、ＳＣＰが要求できる情報のタイプは幾分制限されている。例えば、ＳＣＰは発呼者に要求してＰＩＮ番号を挿入できる。発呼者とＳＣＰとの間のこの限定された対話は呼を完了するには不十分であり、サービス・エージェントに介在させ手動的に呼を処理することを要求する。手動呼処理は自動化された呼処理より一般的により遅く、より費用がかかる。（原文第６頁）アカウント状態データは、顧客が料金をきちんと払っているかどうか、または顧客のサービスが不払いのために中断(suspend)されているかどうかを示す。修理情報は、特定の電話線にされた修理と、特定の線が使用されているかどうかと、特定の線が経験している問題のタイプとを示す。顧客プロフィール・データは、顧客の電話を方向づける上で有用である顧客に関する情報、例えば設置されたサービスのタイプおよび顧客の電話線の地理的な位置などを含む。注文情報は、例えば特定の顧客に対するサービスのコストおよびサービスの可能性(availabil ity)を含むことができる。上述したように、ＡＣＤ１０８はＳＣＰ１０２により受信された命令に従ってエージェント１１６へ呼をルートすることもできる。エージェント１１６は、種々の顧客のニーズを処理できる通例の(regular)サービス・エージェントか、または特定の顧客のニーズを処理できる専門的な(specialized)サービス・エージェントである。ＩＰ１０４および外部システム１０６から受信した情報に基づき、ＳＣＰ１０２はＡＣＤ１０８に方向づけをおこなって呼を適当なエージェント１１６にルートさせることもできる。例えば、発呼者のアカウントが不払いのために中断している場合は、発呼者は回収部門(collections department)にルートされる。または、発呼者の線がホーム・オフィスで使用されている場合は、発呼者は「在宅勤務(work-at-home)」アカウントに特化されているエージェントにルートされる。呼を処理する上で、エージェント１１６は外部システムにストアされたデータへアクセスできる。図２は、本発明の好適実施例によるＳＣＰ１０２のアーキテクチャのブロック図を示す。サービスの処理と作成環境(Service Processing and Creation Envir onment:ＳＰＡＣＥ（登録商標）)という応用１１８は多重サービス応用プラットフォーム（ＭＳＡＰ）応用１２０とのインタフェースをとる。ＭＳＡＰ１２０は、メッセージ配送(Message Delivery:ＭＤ)インタフェース１２２と通信し、それはメッセージをＭＳＡＰ１２０から周辺機器インタフェース(peripheral inte rface:ＰＩ）１２８かまたはジェネリック・データ・インタフェース（ＧＤＩ）１２４のいずれかに配送する。（原文第７頁）ＰＩ１２８は、ＩＰ１０４のＳＣＰ１０２に対するインタフェースをとりこれらの２つの装置が通信できるようにする。ＧＤＩ１２４は、データに対する要求を適当な外部システム１０６に対してプロトコル・ハンドラ１２６経由で送信し、外部システム１０６から受信したデータをパッケージ化してＭＳＡＰ１２０へ送信され、かつＭＳＡＰ１２０により使用されるメッセージにする。ＰＩ１２８およびＧＤＩ１２４は以下で詳細に説明される。ＭＳＡＰ１２０は、ＳＣＰ１０２に常駐するアプリケーションであり、アクセスされた呼処理レコードのサービス・ロジックを実行してシステム１００の他の要素への命令を発行する。ＰＩ１２８は、ＩＰ１０４とＳＣＰ１０２との間のデータ・ネットワーク通信リンクを確立し維持する。ＰＩ１２８はまた、ＩＰ１０４とＳＣＰ１０２との間のメツセージの非同期送信(asynchronous transmission)を処理する。さらに、ＰＩ１２８はメッセージを変換して、ＩＰ１０４またはＳＣＰ１０２のいずれかにより理解されるフオーマットにする。好適実施例において、ＰＩ１２８によりサポートされるメッセージ・フォーマットは、一般に出版されたＢｅｌｌｃｏｒｅドキュメントＴＲ−ＴＳＹ−０００４０２、１９８９年７月（以下「ＴＲ４０２フオーマット」という）、およびＴＡ−ＮＷＴ−００１１２９、１９９２年１０月（以下「ＴＡ１１２９＋フォーマット」という）、それぞれＩＰ１０４およびＳＣＰ１０２により理解されるものにおいて説明される。しかし、他のメッセージ・フオーマットはＩＰ１０４およびＳＣＰ１０２により使用できる。正常な操作の間、ＰＩ１２８はＩＰ１０４およびＭＳＡＰ１２０からのメッセージを同時に待っている。ＰＩ１２８により受信されたメッセージは、待ち行列１２９に加えられ、一方ＰＩ１２８から送信されたメッセージは、図３に示されるように該待ち行列１２９から削除される。図３は、ＰＩ１２８の内部インタフェースを示す図であり、ノード・マネージャ・アプリケーション・プログラミング・インタフェース(Node Manager Applic ation Programming Interface:ＡＰＩ)１３０、ノード・アドミニストレーション(Node Administration)ＡＰＩ１３２、メンテナンス・オペレーションズ・コンソール(Maintenance Operations Console:ＭＯＣ)ＡＰＩ１３４、伝送制御ポイント／インタネット・プロトコル(Transmission Control Point/Internet Proto col:ＴＣＰ／ＩＰ)ＡＰＩ１３６、構成ファイル１３８、およびメッセージ配送( Message Delivery:ＭＤ)１２２を含む。ノード・マネージャＡＰＩ１３０は、ＳＣＰ１０２におけるノードの状態をモニターすることによりＳＣＰ１０２の信頼性を維持する責任がある。（原文第１１頁）返信が外部システム１０６からＧＤＩ１２４により受信される場合、未解決要求テーブルは部分的完了の跡を保持するために更新される（ステップ１６９）。ＧＤＩ１２４は次に、サブ要求へのすべての返信が返らなかったかどうかを決定する（ステップ１７０）。返らなかった場合、ＧＤＩ１２４は追加の返信を待つ。すべての返信が受信された場合、ＧＤＩ１２４は完了メッセージをＭＳＡＰ１２０へ返す（ステップ１７２）。ステップ１６８でＧＤＩ１２４が返信は受信されなかったと決定する場合は、あらかじめ決められた時間が過ぎると（ステップ１７１）、メッセージがまたＭＳＡＰ１２０へ戻される（ステップ１７２）。したがって、すべての未解決サブ要求が応答されるかまたは時間切れとなる場合、メッセージはＭＳＡＰ１２０へ戻される。図８は、ＧＤＩ未解決要求テーブル１６０を示す。ブロックＡ、Ｂ、およびＣはＭＳＡＰ１２０からＧＤＩ１２４により受信された未解決要求を表す。ブロックＡ１、Ａ２、およびＡ３、Ｂ１、Ｂ２、およびＢ３、Ｃ１、Ｃ２、およびＣ３は、未解決要求Ａ、Ｂ、およびＣからそれぞれ作られたサブ要求を表す。ブロックＡ１Ｒ、Ａ２Ｒ、およびＢ３Ｒはサブ要求Ａ１、Ａ２、およびＢ３にそれぞれ応答してＧＤＩ１２４により受信された応答を表す。未解決要求テーブル１６０は、ＭＳＡＰ１２０からの情報に対する各要求がＧＤＩ１２４により受信されるときに構成され、そして更新される。ＭＳＡＰ１２０から要求を受信すると、ＧＤＩ１２４はサブ要求を作り、それは適当なプロトコル・ハンドラへ転送される。ＧＤＩ１２４は、各未解決サブ要求に対する応答を待つ。３つのタイプの応答を未解決要求テーブル１６０にストアすることができる。第１に、ＧＤＩ１２４は外部システム１０６からの応答Ａ１Ｒをストアでき、これは結果がサブ要求に応答して受信されたことを示す。第２に、ＧＤＩ１２４は外部システム１０６からの応答Ａ２Ｒをストアでき、これはエラーが外部システム１０６から受信されたことを示す。そのようなエラーは、外部システム１０６がサブ要求を処理できないことを示すようにしてもよい。（原文第１３頁）ＧＤＩ１２４からＭＳＡＰ１２０へ情報を戻すことができる一方、この情報は、ＭＳＡＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノードを実行する後まではＭＳＡＰ１２０により使用可能ではない。ＳｅｎｄＤａｔａノードは、ＭＳＡＰ１２０が、たとえばアカウント・データなどのデータを外部システム１０６へ送ることができるようにする。外部システム１０６へＭＳＡＰ１２０により発行されたＳｅｎｄＤａｔａ要求は、ハンドル・コール変数、アカウントＩＤ、および対応するデータといつしよにコール変数のリストを含む。ハンドル・コール変数はＳｅｎｄＤａｔａ要求を識別し、この要求の状態を得るために使用される。コール変数のリストに対応する情報は、アカウントＩＤに従い外部システム１０６にストアされる。ＭＳＡＰ１２０からＳｅｎｄＤａｔａ要求を受信すると、ＧＤＩ１２４はどの外部システム１０６へこのデータを送るべきかを決定する。ＧＤＩ１２４は受信したＳｅｎｄＤａｔａ要求からのデータをフォーマットして、このフォーマットされたデータを適当な外部システム・プロトコル・ハンドラへ送信する。ＧＤＩ１２４は、ＭＳＡＰ１２０への状態応答(status reply)を送る前にデータが受容されたことを示す、プロトコル・ハンドラからの肯定応答(positive acknowledg ement)を待つ。しかしＳｅｎｄＤａｔａ要求の状態は、ＭＳＡＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノード実行した後まではＭＳＡＰ１２０には使用可能ではない。ＷａｉｔＦｏｒＥｖｅｎｔノードはＭＳＡＰ１２０にＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求のデータまたは状態へのアクセスを与える。ＷａｉｔＦｏｒＥｖｅｎｔ命令は、ハンドル・コール変数を指定し、それはＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求において指定されたハンドル・コール変数に対応する。ＧｅｔＤａｔａまたはＳｅｎｄＤａｔａ要求からＭＳＰ１２０へ戻されたすべての要求は、ＭＳＰ１２０がＷａｉｔＦｏｒＥｖｅｎｔノードを実行した後まではＭＳＰ１２０には使用可能ではない。ＷａｉｔＦｏｒＥｖｅｎｔ命令が発行された場合は、要求された情報が戻されるまでさらに先の命令がＭＳＡＰ１２０により実行されることはない。応答が戻った場合は、要求において指定されたコール変数へ情報が割り当てられて要求の状態が戻される。請求の範囲１．知的周辺機器（ＩＰ）、サービス制御ボイント（ＳＣＰ）、および外部データ・システムを含み、前記ＳＣＰは呼処理レコード（ＣＰＲ）を処理する多重サービス応用プラットフォーム（ＭＳＡＰ）、前記ＳＣＰを前記ＩＰとインタフェースをとる周辺機器インタフェース（ＰＩ）、および前記ＳＣＰを前記外部システムとインタフェースをとるジェネリック・データ・インタフェース（ＧＤＩ）を含むネットワークに基づく電話システムにおいて、（ａ）発呼者から呼をＩＰが受信するステップと、（ｂ）前記ＳＣＰから呼処理命令をＩＰが要求するステップと、（ｃ）サービス処理論理を有する対応するＣＰＲをＭＳＡＰがアクセスするステップと、（ｄ）前記サービス処理論理に基づき、前記発呼者から情報を集めるために前記ＩＰにＳＣＰが命令するステップと、（ｅ）前記サービス処理論理に基づき、前記ＧＤＩへアカウント・データをＭＳＡＰが送信するステップとを備えたことを特徴とする呼を処理する方法。２．請求項１に記載の方法において、アカウント・データをＭＳＡＰが送信するステップが、前記ＧＤＩへ送信要求をＳＣＰが発行するステップと、前記受信した送信要求に応答してサブ要求をＧＤＩが形成するステップと、適当な外部システムへ前記サブ要求をＧＤＩが転送するステップと、各サブ要求に関する状態情報をＧＤＩが受信するステップと、前記送信要求の状態を含む前記ＳＣＰへメッセージをＧＤＩが戻すステップとを備えたことを特徴とする方法。３．請求項２に記載の方法において、アカウント・データをＭＳＡＰが送信するステップが、戻されたメッセージにアクセスするための待ち要求をＳＣＰが発行するステップをさらに含むことを特徴とする方法。４．電話呼出しを処理するネットワークに基づく電話システムにおいて、アクセスされた呼処理レコード(ＣＰＲ)のサービス論理に従い命令を発行するサービス制御ポイント（ＳＣＰ）と、前記システムを発呼者とインタフェースをとりおよび前記ＳＣＰからの命令に基づき前記発呼者と通信する知的周辺機器（ＩＰ）と、前記ＳＣＰへデータを提供するため前記ＳＣＰからの要求に応答する外部システムとを備え、前記ＳＣＰは、前記ＳＣＰを前記ＩＰとインタフェースをとるための周辺機器インタフェース（ＰＩ）と、前記ＳＣＰと前記外部システムとの間で顧客データを送信するためのジェネリック・データ・インタフェース（ＧＤＩ）とを備えたことを特徴とするネットワークに基づく電話システム。５．請求項４に記載のシステムにおいて、前記外部システムにより提供された前記データはアカウント状態データ、修理情報、顧客プロフィール・データ、および注文情報を含むことを特徴とするシステム。６．請求項５に記載のシステムにおいて、前記ＩＰはメッセージをながし、および発呼者情報を受信することを特徴とするシステム。７．請求項４に記載のシステムにおいて、前記ＳＣＰは、ＣＰＲを実行しおよび対応する呼処理命令を発行するための多重−サービス応用プラットフォーム（ＭＳＡＰ）をさらに含むことを特徴とするシステム。８．請求項７に記載のシステムにおいて、前記ＧＤＩは情報を要求する前記ＭＳＡＰからのデータ要求を受信する手段と、前記適当な外部システムへ転送されるサブ要求を形成する手段と、およびその要求された情報を含むＭＳＡＰへの単一メッセージを戻す手段とを含むこと特徴とするシステム。９．請求項７に記載のシステムにおいて、前記ＧＤＩは前記ＭＳＡＰから送信要求を受信する手段と、前記適当な外部システムへ転送するサブ要求を形成する手段と、およびその送信要求の状態を含む前記ＭＳＡＰへの単一メッセージを戻す手段とを含むことを特徴とするシステム。１０．請求項７に記載のシステムにおいて、前記ＳＣＰは、前記ＭＳＡＰ、前記ＧＤＩ、および前記ＰＩの間でメッセージを配送するためのメッセージ配送（ＭＤ）をさらに含むことを特徴とするシステム。１１．知的周辺機器（ＩＰ）、サービス制御ポイント（ＳＣＰ）、および外部データ・システムを含むネットワークに基づく電話システムにおいて、（ａ）ＩＰにおいて発呼者から呼を受信するステップと、（ｂ）前記ＳＣＰから呼処理命令を要求するステップと、（ｃ）キーに基づくサービス論理を有する呼処理レコードをＳＣＰがアクセスするステップと、（ｄ）前記サービス論理に基づき、前記発呼者から情報を集めるために前記ＩＰにＳＣＰが命令するステップと、（ｅ）前記サービス論理に基づき、外部データ・システムからデータをＳＣＰが検索するステップとを備えたことを特徴とする呼を処理する方法。１２．請求項１１に記載の方法において、外部データ・システムから検索された前記データは前記発呼者に関連した顧客プロフィール情報を含むことを特徴とする方法。１３．請求項１２に記載の方法において、（ｆ）前記顧客プロフィール情報に基づきエージェントへ前記呼をルートするステップをさらに含むことを特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ドネリー，パトリック，ジェイムズアメリカ合衆国 08807 ニュージャージー州ブリッジウォーターローリングヒルスロード 435 (72)発明者ホレンバック，スティーヴン，アンドリュウアメリカ合衆国 08853 ニュージャージー州ネシャニックステーションブロカウコート 213 (72)発明者クレト，マイケル，アンソニーアメリカ合衆国 08854 ニュージャージー州ピスカタウェイマチューコート 39

Claims

【特許請求の範囲】１．知的周辺機器（ＩＰ）、サービス制御ポイント（ＳＣＰ）、および外部データ・システムを含み、前記ＳＣＰは呼処理レコード（ＣＰＲ）を処理する多重サービス応用プラットフォーム（ＭＳＡＰ）、前記ＳＣＰを前記ＩＰとインタフェースをとる周辺機器インタフェース（ＰＩ）、および前記ＳｃＰを前記外部システムとインタフェースをとるジェネリック・データ・インタフェース（ＧＤＩ）を含むネットワークに基づく電話システムにおいて、（ａ）発呼者から呼をＩＰが受信するステップと、（ｂ）前記ＳＣＰから呼処理命令をＩＰが要求するステップと、（ｃ）サービス処理論理を有する対応するＣＰＲをＭＳＡＰがアクセスするステップと、（ｄ）前記サービス処理論理に基づき、前記発呼者から情報を集めるために前記ＩＰにＳＣＰが命令するステップと、（ｅ）前記サービス処理論理に基づき、前記ＧＤＩへアカウント・データをＭＳＡＰが送信するステップとを備えたことを特徴とする呼を処理する方法。２．請求項１に記載の方法において、アカウント・データをＭＳＡＰが送信するステップが、ジェネリック・データ・インタフェース（ＧＤＩ）へ送信要求をＳＣＰが発行するステップと、前記受信した送信要求に応答してサブ要求をＧＤＩが形成するステップと、適当な外部システムへ前記サブ要求をＧＤＩが転送するステップと、各サブ要求に関する状態情報をＧＤＩが受信するステップと、前記送信要求の状態を含む前記ＳＣＰへメッセージをＧＤＩが戻すステップとを備えたことを特徴とする方法。３．請求項２に記載の方法において、アカウント・データをＭＳＡＰが送信するステップが、戻されたメッセージにアクセスするための待ち要求をＳＣＰが発行するステップをさらに含むことを特徴とする方法。４．電話呼出しを処理するネットワークに基づく電話システムにおいて、アクセスされたＣＰＲのサービス論理に従い命令を発行するサービス制御ポイント（ＳＣＰ）と、前記システムを発呼者とインタフェースをとりおよび前記サービス制御ポイントからの命令に基づき前記発呼者と通信する知的周辺機器（ＩＰ）と、前記ＳＣＰへデータを提供するため前記ＳＣＰからの要求に応答する外部システムとを備え、前記ＳＣＰは、前記ＳＣＰを前記知的周辺機器とインタフェースをとるための知的周辺機器インタフェース（ＰＩ）と、前記ＳＣＰと前記外部システムとの間で顧客データを送信するためのジェネリック・データ・インタフェース（ＧＤＩ）とを備えたことを特徴とするネットワークに基づく電話システム。５．請求項４に記載のシステムにおいて、前記外部システムからアクセスされた前記データはアカウント状態データ、修理情報、顧客プロフィール・データ、および注文情報を含むことを特徴とするシステム。６．請求項５に記載のシステムにおいて、前記ＩＰはメッセージをながし、および発呼者情報を受信することを特徴とするシステム。７．請求項４に記載のシステムにおいて、前記ＳＣＰは、ＣＰＲを実行しおよび対応する呼処理命令を発行するための多重−サービス応用プラットフォーム（ＭＳＡＰ）をさらに含むことを特徴とするシステム。８．請求項７に記載のシステムにおいて、ＧＤＩは情報を要求するＭＳＡＰからのデータ要求を受信し、適当な外部システムへ転送されるサブ要求を形成し、およびその要求された情報を含むＭＳＡＰへの単一メッセージを戻すことを特徴とするシステム。９．請求項７に記載のシステムにおいて、ＧＤＩはＭＳＡＰから送信要求を受信し、適当な外部システムへ転送するサブ要求を形成し、送信要求の状態を含むＭＳＡＰへの単一メッセージを戻すことを特徴とするシステム。１０．請求項７に記載のシステムにおいて、前記ＳＣＰは、ＭＳＡＰ、ＧＤＩ、およびＰＩの間でメッセージを配送するためのメッセージ配送（ＭＤ）をさらに含むことを特徴とするシステム。１１．知的周辺機器（ＩＰ）、サービス制御ポイント（ＳＣＰ）、および外部データ・システムを含むネットワークに基づく電話システムにおいて、（ａ）ＩＰにおいて発呼者から呼を受信するステップと、（ｂ）前記ＳＣＰから呼処理命令を要求するステップと、（ｃ）キーに基づくサービス論理を有する呼処理レコードをＳＣＰがアクセスするステップと、（ｄ）前記サービス論理に基づき、前記発呼者から情報を集めるために前記ＩＰにＳＣＰが命令するステップと、（ｅ）前記サービス論理に基づき、外部データ・システムからデータをＳＣＰが検索するステップとを備えたことを特徴とする呼を処理する方法。１２．請求項１１に記載の方法において、外部データ・システムから検索された前記データは前記発呼者に関連した顧客プロフィール情報を含むことを特徴とする方法。１３．請求項１２に記載の方法において、（ｆ）前記顧客プロフィール情報に基づきエージェントへ前記呼をルートするステップをさらに含むことを特徴とする方法。