JPH10503902A - インテリジェント通信ネットワーク - Google Patents

Abstract

(57)【要約】 顧客に対してサービスを提供するためにインテリジェント通信ネットワークにおける使用に対してサービスノードを説明している。サービスノードは、複数のサービスを規定するように構成されているサービス規定手段と、顧客が提供したデータを認識し、このような認識データを記憶する手段と、使用において、それぞれのスピーチセグメントが対応する識別子を有する複数のスピーチセグメントを含んでいるスピーチセグメント記憶装置と、コマンド信号に対応するスピーチアナウンスのために、受信コマンド信号を対応する連続したスピーチセグメント識別子に変換し、前記スピーチセグメント識別子にしたがって前記スピーチセグメント記憶装置にアクセスし、スピーチアナウンスのために対応したスピーチセグメントを発生させ、アナウンスの最後のスピーチセグメントを発生させた時にアナウンス終了信号を供給するように構成されたリソース手段を制御する手段とを備えたリソース手段と、前記ネットワークにより前記サービスノードにルーティングされた入通話に前記リソース手段を接続するように構成されたスイッチと、このような入通話に応答して、必要なように通話を処理して待ち行列に入れるために前記サービス規定手段に通話の詳細を送り、前記サービス規定手段からの信号を前記リソース手段と前記スイッチに送り、前記リソース手段からのアナウンス終了信号を前記サービス規定手段に送るように構成されているノード制御手段とを具備している。

Description

【発明の詳細な説明】 インテリジェント通信ネットワーク この発明は、インテリジェント通信ネットワークでサービスを提供する方法お よびサービスノードに関する。 記憶プログラム制御（ＳＰＣ）交換機の出現前は、公衆電話交換ネットワーク （ＰＳＴＮ）は、ストローガー交換機およびクロスバー交換機のような電気機械 的な交換機と、ＴＸＥ２交換機およびＴＸＥ４交換機のような電子交換機を含ん でいた。しかしながら、これらのタイプの最先端のものでさえ、通話を単にスイ ッチングするのに加えて、すなわち入チャネルまたは回線と出チャネルとの間の 接続をするのに加えて、限られた数の機能を実行できるだけであった。さらに、 このような付加的な機能は、通信ネットワークの性能を改良するための動作、例 えば、最初に選択したルートが使用中である時に、代わりの出ルートを介して目 的地番号に到達しようと反復することに制限されていた。 ＳＰＣ交換機により、＊および＃ボタンを使用して電話キーパッドに入力され た信号を介して、顧客がさまざまな追加サービスを制御できるようになった。し かしながら、新しいサービスの導入または現在のサービスの修正は、それぞれの ＳＰＣ交換機において制御プログラムを更新しなければならないことを意味する 。 インテリジェント通信ネットワークの現在の概念は、ローカル交換機がデジタ ルメイン切替装置（ＤＭＳＵ）に接続され（ＤＭＳＵが故障した際の通信ネット ワークの回復のために、通常、それぞれのローカル交換機が２台のＤＭＳＵに接 続され）、通信ネットワーク中のさまざまな位置において離散しているサービス ノードによりサービスが提供され制御される、相互接続されたＤＭＳＵの一団に 基づいている。 各サービスノードはネットワークのＤＭＳＵに接続され、このＤＭＳＵは、顧 客によりダイヤルされたサービスアクセス数字を認識し、要求されたサービスを 顧客に対して提供するサービスノードに通話をルーティングする。 本発明の第１の観点にしたがうと、 顧客に対してサービスを提供するインテリジェント通信ネットワークで使用す るためのサービスノードにおいて、 複数のサービスを規定するように構成されているサービス規定手段と、 顧客が提供したデータを認識し、このような認識データを記憶する手段と、使 用において、それぞれのスピーチセグメントが対応する識別子を有する複数のス ピーチセグメントを含んでいるスピーチセグメント記憶装置と、コマンド信号に 対応するスピーチアナウンスのために、受信コマンド信号を対応する連続したス ピーチセグメント識別子に変換し、前記スピーチセグメント識別子にしたがって 前記スピーチセグメント記憶装置にアクセスし、スピーチアナウンスのために対 応したスピーチセグメントを発生させ、アナウンスの最後のスピーチセグメント を発生させた時にアナウンス終了信号を供給するように構成されたリソース手段 を制御する手段とを備えたリソース手段と、 前記ネットワークにより前記サービスノードにルーティングされた入通話に前 記リソース手段を接続するように構成されたスイッチと、 このような入通話に応答して、必要なように通話を処理して待ち行列に入れる ために前記サービス規定手段に通話の詳細を送り、前記サービス規定手段からの 信号を前記リソース手段と前記スイッチに送り、前記リソース手段からのアナウ ンス終了信号を前記サービス規定手段に送るように構成されているノード制御手 段とを具備していることを特徴とするサービスノードが提供される。 サービス規定手段がサービスの全制御を持っているとすると、サービス規定手 段は、第１のセグメントを発生させるようにリソースに命令することによりアナ ウンスを構成し、リソースからのセグメント発生信号の受信を待ち、そして次の セグメントに対するコマンドを送るなどを行う。本発明の利点は、ノード制御手 段が通信リンクを介して通信しなければならないことから信号が受ける伝送およ び処理遅延によりセグメント間のギャップを決定するのではなく、最適なスピー チ再生に対して決定し、リソースによって直接的に制御することができることで ある。別の利点は、リソース手段に顧客が提供したデータを認識し記憶する手段 を設けることにより、サービス規定手段がその機能と関係がなくなり、顧客によ り提供されたデータを返還させるために、単にリソース手段にコマンドを発行す るだけである。サービス規定手段とリソース手段間へのこのようなサービス構成 要素の分配により、サービス規定手段によりサービスがトータルに制御される場 合よりも、より早いサービス動作およびより簡単なソフトウェアコードが可能に なる。 前記リソース手段が、前記スピーチセグメント記憶装置を含んでいる第１のリ ソースと、顧客が提供したデータを認識し、このような認識データを記憶する前 記手段を含んでいる別の第２のリソースとを備え、前記第１のリソースが、前記 第２のリソースと入通話との間の接続を命令し、前記第２のリソースにその認識 および記憶手段を起動してこのように記憶されているデータを前記第１のリソー スに提供するように命令することが好ましい。 前記第１のリソースがそれ自身を介して前記接続をするように構成されていて もよい。 前記リソース手段が、顧客関連データのデータベースと、顧客用の前記データ ベースに記憶されている対応するデータと比較することにより、顧客が提供した 認識されたデータを確認するように構成された手段とをさらに備えていることが 好ましい。 前記リソース手段が、顧客関連データの前記データベースと顧客用の前記デー タベースに記憶されている対応するデータと比較することにより、顧客が提供し た認識されたデータを確認するように構成された前記手段とを含んでいる別の第 ３のリソースを備え、前記第１のリソースが、認識されたデータを前記第３のリ ソースに提供し、提供されたデータを確認して前記第１のリソースに確認の結果 を示している信号を提供するように前記第３のリソースに命令するように構成さ れているとさらに好ましい。 第１のリソースは、データをサービス規定手段に送ってもよく、場合によって は、データをサービス規定手段に送るように第２のリソースに命令してもよい。 このようなサービスノードでは、第１のリソース手段が、複数の番号付けされ たサービス関連オプションを顧客に提供するアナウンスを発生させ、顧客から認 識された番号を受信した時に異なる複数の番号付けされたサービス関連オプショ ンを提供する別の各アナウンスを発生させるように構成されていてもよい。 サービスノードのリソース手段は、そのサービスへの多くの同時通話を取扱う ことができるように、第２のリソース（場合によっては第３のリソース）ともに または第２のリソースなしに、非常に多くのこのような第１のリソースを備えて いる。リソース手段は、サービスの大部分を実行し、サービス規定手段との通信 を減らす利点を獲得するのに十分な知性を持っているが、サービスノードの費用 の過度に多い部分となる程インテリジェントではない。 本発明の第２の観点にしたがうと、 顧客に対してサービスを提供するインテリジェント通信ネットワークにおける サービスノードを動作させる方法において、 前記ネットワークにより前記サービスノードにルーティングされた入通話を受 信し、必要なように通話を処理して待ち行列に入れるためにサービス規定手段に 前記入通話の詳細を送り、 前記サービス規定手段からの要求に応答して、リソース手段を前記入通話に接 続し、 前記サービス規定手段からのコマンド信号を前記リソース手段に送り、 前記リソース手段により受信されたコマンド信号を対応する連続したスピーチ セグメント識別子に変換し、 前記スピーチセグメント識別子にしたがって、スピーチセグメント記憶装置に アクセスし、 前記対応するスピーチセグメントを発生させ、 アナウンスの最後のスピーチセグメントを発生させた時にアナウンス終了信号 を供給し、 前記リソース手段において、顧客が提供したデータを受信し、 前記受信された顧客が提供したデータを認識し、 このように認識されたデータを記憶するステップを含むことを特徴とする方法 が提供される。 前記変換、アクセス、発生、供給ステップは、前記リソース手段の第１のリソ ースにより実行され、前記認識および記憶ステップは、前記リソース手段の別の 第２のリソースにより実行され、前記第１のリソースからのコマンドに応答して 、 前記別の第２のリソースを前記入通話に接続するステップを含むことが好ましい 。 顧客が提供した認識されたデータを確認するステップをさらに設けてもよい。 前記確認ステップが前記リソース手段の別の第３のリソースにより実行されて もよい。 複数の番号付けされたサービス関連オプションを顧客に提供するアナウンスを 発生させ、顧客から認識された番号を受信した時に異なる複数の番号付けされた サービス関連オプションを提供する別の各アナウンスを発生させるステップをさ らに設けてもよい。 図面を参照して、例としてのみ、本発明にしたがったサービスノードの特定の 実施例をこれから説明する。 図１は、サービスノードのサービス論理実行環境の図である。 図２は、サービスノードにより提供されるサービスで使用される通話インスタ ンスの記憶位置を示している図である。 図３は、通話イベントの処理を示している図である。 図４は、通話インスタンスの初期化を示している図である。 図５は、通話インスタンスに対するリソースへの割当てを示している図である 。 図６は、リソースと呼出し人との間のスピーチパスの接続を示している図であ る。 図７は、アプリケーションによるリソースのコマンドを示している図である。 図８は、リソースの応答を示している図である。 図９は、アプリケーションが終了した時の手続きを示している図である。 図１０は、通話が切れた時の手続きを示している図である。 図１１は、リソースが切れた時の手続きを示している図である。 図１に見られるように、本発明のサービスノードの主要部分は、サービス論理 実行環境（ＳＬＥＥ）１０と呼ばれ、本発明の制御手段を構成する中央制御機能 である。 ＳＬＥＥ１０は、複数のアプリケーションタイプ１３ａ〜１３ｎのそれぞれに おける、（本発明のサービス規定手段を構成している）複数のアプリケーション インスタンス１２ａ〜１２ｎのそれぞれに対する、それぞれのアプリケーション ・プログラム・インターフェイス（ＡＰＩ）プロセス１１ａ〜１１ｎと、通話モ デルプロセス１４と、スケジューラプロセス１５と、複数のサービスノードのサ ブシステムのそれぞれに対するハンドラプロセス、すなわち、ＳＬＥＥ管理シス テム１６と、スイッチ１７と、請求書発行システム１８と、共通のハンドラ１９ Ｈを有する複数のインテリジェント周辺装置（ＩＰ）リソース１９と、共通のハ ンドラ２０Ｈを有する複数の会話リソース２０とを備えている。リソース１９お よび２０は、一緒になって、本発明のリソース手段を構成する。 この明細書では、インテリジェント周辺装置およびサービスノードの用語は、 同じ事実上の意味を持つように解釈されるべきであるが、実際には、サービスノ ードは、スイッチ１７をともなうインテリジェント周辺装置により構成される。 この実施例では、（本発明の第１のリソースを構成する）各ＩＰリソース１９ は、その自己の数字収集手段を含んでいるスピーチ・アプリケーション・プラッ トフォーム（ＳＡＰ）である。別の実施例では、（それぞれ本発明の第２のリソ ースを構成する）複数の数字収集手段があり、これらは、数字収集をともなうサ ービスに対して必要とされる時に、予約して、ＳＡＰと結合することができる。 各会話リソース２０は、非スピーチリソース、すなわちスイッチ１７のポート に接続されておらず、顧客からの信号（ＭＦ信号またはスピーチ）を送受信する ように構成されていないリソースである。会話リソース２０のタイプの例は、個 人識別番号（ＰＩＮ）確認装置、サービスノードが遠隔のリソースまたはシステ ムと通信する必要がある時のためのプロトコル変換装置、データベース２８への 入力の管理をするための管理論理装置である。 便宜のため、上記のプロセスを一般的にプロセス名により呼び、各ハンドラを １６Ｈ，１７Ｈなどとして識別する。ハンドラ１９Ｈは、アプリケーションとＳ ＬＥＥの共有メモリ２１との間の信号をインターフェイスする内部部分１９Ｈin tと、ＩＰリソース１９へのまたこれからの信号をインターフェイスする外部部 分１９Ｈextを有する。 ＳＬＥＥ１０の各構成部分は、プラットフォーム上のＵＮＩＸ（ＡＴ＆Ｔの商 標）プロセスとして実現される。プラットフォームは、詳細に説明する必要がな いが、マルチプロセッサの形態のマルチタスクで故障許容度のあるＵＮＩＸ環境 である。適切な場合、これらのプロセスは、メッセージの両方向通信のためのサ ブプロセスを含んでいる。このようなサブプロセスは当業者に良く知られており 、スイッチハンドラ１７Ｈのメッセージ受信サブプロセスを構成するスイッチメ ッセージハンドラ２６を除いて、特に言及しない。 ＳＬＥＥ１０の部分プロセスは、それらすべてがアクセスすることができる共 有メモリ２１のブロックを介して相互に通信する。この並列に動作する個別のプ ロセスの構成は、重大なボトルネックの可能性をかなり減らす。 アプリケーションインスタンスはＳＬＥＥ１０の初期化においてＳＬＥＥ管理 システム１６により開始され、プラットフォームに入るそれぞれの新しい通話が 共有メモリ２１中の新しい通話インスタンス２２を生成する（図２）。 各通話インスタンス２２は各通話に特定のデータを保持し、図２に示されてい るさまざまなデータカテゴリーは、割り振られたＩＰリソース、割り振られた会 話、スイッチ対話、切断フラグ、コンテキストメモリ、課金記録およびＡＰＩイ ベントである。これらのカテゴリーの中には、例えばＩＰリソースやＡＰＩイベ ントのように、通話インスタンス中に１以上の記憶位置を持つものもある。 各アプリケーションタイプ１３は１以上の規定されたサービスを提供すること ができ、（おそらく異なるサービスを使用する）異なる通話はすべて、アプリケ ーションが要求するようにカットインおよびカットアウトすることによって、任 意のアプリケーションインスタンス１３を共有することができる。通話インスタ ンス２２のコンテキストメモリは、通話の状態の履歴をたどるためにアプリケー ションにより使用される。 同じサービスを使用する多数の通話が並列に進行できるようにするために、同 じアプリケーションタイプ１３の複数のアプリケーションインスタンス１２が提 供される。通話イベントを処理できるように、ＳＬＥＥ１０のスケジューラ１５ が、アプリケーションインスタンス１２に対する通話の割当てを管理する。 外部イベントが起こった場合、ハンドラはそれらを各通話インスタンス２２の 待ち行列に入れる。図３は、これらの通話イベントを検索し、処理のためにアプ リケーションに送るさまざまなステップを示している。 スケジューラ１５は、各サービスインスタンス２３の相対優先度に基づいて、 次にどのサービスを進行させるかを決定する。すべてのサービスがそのうち進行 する一方、（ＳＬＥＥ管理システム１６により設定される）より高いサービス優 先度を有するものがより頻繁に進行することが確実になされるように、スケジュ ーラ１５が起動される度に、これらの優先度が再計算される。最高の相対優先度 とその待ち行列に入れられた実行可能な通話を持つサービスインスタンスが進行 のために選択される（ステップ１）。スケジューラ１５は、サービス支配アプリ ケーションタイプを検索し（ステップ２）、サービスインスタンス２３をサービ スキュー２４の一番下に加える（ステップ３）。スケジューラ１５により、アプ リケーションタイプ１３中のブロックキングセマファが増加され（ステップ４） 、このアプリケーションタイプ１３に属するアプリケーションインスタンス１２ の一つにより他の通話を処理する準備ができたことを信号送信する。これが生じ た時、次のサービスインスタンス２３がキュー２４から去り（ステップ５）、次 の通話インスタンス２２がその実行可能な通話キュー２５から去る（ステップ６ ）。この通話インスタンス２２に属している最初のＡＰＩイベントが、通話のコ ンテキストメモリとともに、処理されるべきアプリケーションに送られる（ステ ップ７）。 アプリケーションは、このイベントで動作させる必要のあるタスクを実行し、 これらのアプリケーションタスクの完了時にＡＰＩ中止コマンドを発行し、そし てＡＰＩ提供命令コマンドを発行し、コンテキストメモリを修正して（ステップ ８）、通話の状態の変化に影響を与える。アプリケーションのために待ち行列に 入れられた何らかの管理イベントが、そのセマファ上のプロセスブロックが次の 通話イベントのために準備する前に（ステップ１０）、それに対して発行される （ステップ９）。 アプリケーションは、ＡＰＩ中止コマンドをＳＬＥＥ１０に送ってアプリケー ションから通話インスタンス２２を解放（分離）し、ＡＰＩ供給命令コマンドを 送ってアプリケーションが次の通話の準備のためにブロックされるようにする。 サービスノードにより提供されるメッセージ記録サービスに対する典型的な通 話シナリオに対して生じるプロセスの説明をこれから行う。多くの異なるタスク が起こり得るが、プラットフォームを使用するすべての通話は、以下の説明と同 様な方法で進行する。 顧客がネットワークベースのメッセージ記録サービス（以下“ボイスメール・ サービス”という）に加入したと仮定すると、そのための（図示されていない） プラットフォームは、預けられた口頭メッセージ記憶用のデータベースを含み、 ＰＳＴＮのＤＭＳＵに結合される。顧客がボイスメール・サービスを起動する時 、顧客への通話がネットワークによりプラットフォームに自動的に接続され、何 らかの所望の口頭メッセージ（以下“ボイスメール・メッセージ”という）が顧 客による後の検索のために記録され、データベース２８に記憶するために、ボイ スメール・プラットフォームが、ボイスメール・メッセージについての情報（顧 客請求書番号、顧客名）をサービスノード中のアプリケーションに送り、これは 、その請求書番号に関連した記憶通話レジスタをインクリメントし、ボイスメー ル・メッセージの現在の位置を表しているインデックスに関連して、顧客名をボ イスメール・プラットフォーム・データベースに記憶させる。 自分を待っている何らかのボイスメール・メッセージがあるか否かを見出だし たいと顧客が思っている時、顧客はボイスメール・サービスへのアクセスを得る ためにサービスアクセス数字をダイヤルし、（ネットワーク上のどこで生じたの かにかかわらず）ＰＳＴＮがその通話をサービスノードにルーティングする。 図４を参照すると、ステップが１１から始まる番号付けがなされており、この 通話がサービスノードに到着した時、信号リンクを介してスイッチ１７から通話 モデル１４へ数字が送られる。通話モデル１４は、ボイスメール・サービスのた めにダイヤルされたサービスアクセス数字を認識し、これに応答して、ＳＬＥＥ 共有メモリ２１内に新しい通話インスタンス２２を生成して初期化し（ステップ １１）、入通話をその第１のＩＰリソース、すなわちＩＰリソース０に割り振る （ステップ１２）。実際のＩＰリソースは入チャネルであり、この入チャネル上 に入通話が現れ、これは通話インスタンス２２のＩＰリソース０位置に割り振ら れるこのチャネルの識別子である。通話モデル１４は、タイムスタンプ付きの入 通話すなわちイベントを通話インスタンス２２の課金記録位置に記録することに より、通話課金記録を初期化する（ステップ１３）。そしてＳＬＥＥ１０はＡＰ Ｉ入通話イベントを通話ＡＰＩイベントキューに入れ（ステップ１４）、通話イ ンスタンス２２を実行可能な通話として適切なサービスインスタンス２３上の待 ち行例に入れる（ステップ１５）。 図５を参照して説明されているように、スケジューラ１５がトリガされ、通話 イベント処理フェーズに入る。 図５を参照すると、通話を実行する時間であるとスケジューラ１５が決定した 時、ＳＬＥＥ１０は、通話インスタンスのＡＰＩイベントキューからアプリケー ション１３にＡＰＩ入通話イベントを送る（ステップ１６）。アプリケーション はこのイベントを受信し、（図示されていない）イベントの状態表を参照し、次 に続く位置から実行する。新しい通話であるこの場合では、サービスの始めから である。 アプリケーションは、ＩＰリソース０以外の少なくとも一つのＩＰリソースの 使用を必要とする。第１にアプリケーションは、ＡＰＩ予約リソースメッセージ をＳＬＥＥ１０に送ることにより、通話のアプリケーションの割り振られたＩＰ リソースの内の自由な一つのリソース（例えばリソース３）を予約しなければな らない（ステップ１７）。アプリケーションは、通話インスタンス２２中の自由 なＩＰリソースを自分自身で選択し、また自由なリソースを予約し、選択された ＩＰリソースに対してその識別子を割り振ることをＳＬＥＥ１０に頼む。ＳＬＥ Ｅの内部ＡＰＩリソースハンドラ１９Ｈintは、そのメッセージを受信し、自由 なリソースを記憶する装置中の正しいタイプの自由な（使用されていない）リソ ース（リソースＸ）を見つけ、自由なリソースから通話インスタンスのＩＰリソ ース３にリソース識別子を移動させることにより、自由なリソースをその通話に 割り振る（ステップ１８）。このステップでは、リソースは、自由なリソースか ら実際に取り出されるか、または、そのリソースが使用中または自由でないこと をマークするためにフラグを設定することにより効果的に取り出される。成功メ ッセージが、リターンコードとしてアプリケーションに返される（ステップ１９ ）。 図６に示されているように、リソースを使用するために、アプリケーションは そのスピーチチャネルを通話のスピーチチャネルと接続しなければならない。ア プリケーションは、接続したい２つのリソース（すなわち、ＩＰリソース０、入 通話、ＩＰリソース３、要求されたリソース）を参照してＡＰＩ接続メッセージ を送ることによりこれを行う（ステップ２０）。 ＳＬＥＥのＡＰＩスイッチハンドラ１７Ｈはそのメッセージを受信し、自由な スイッチ対話ＩＤを通話インスタンス２２に割当て（予約し）（ステップ２１） 、それを使用して接続のための要求をスイッチ１７に送る（ステップ２２）。ス イッチ１７はその要求を受信し、その通話をリソースＸに接続する（ステップ２ ３）。スイッチ１７はＳＬＥＥ１０のスイッチメッセージハンドラ２６に成功し たことを信号で送り返す（ステップ２４）。 リソースを予約すると、アプリケーションは今度それと通信し、例えばこのシ ナリオでは、アプリケーションはリソースが記録されているアナウンスを顧客対 して再生するように要求する。図７に示されているように、アナウンスタイプを 含むＡＰＩ ＩＰリソースコマンドをＳＬＥＥ１０に送ることにより、アプリケ ーションはこれを行う（ステップ２５）。ＳＬＥＥの外部ＡＰＩリソースハンド ラ１９Ｈextはこのメッセージを受信し、自由な対話ＩＤ記憶装置からのＩＤを 通話のアプリケーションＩＰリソースに割当てることによりリソースとの対話を 設定する（ステップ２６）。ＳＬＥＥの外部ＡＰＩリソースハンドラ１９Ｈext は、この対話ＩＤをコマンドに結合し、それを割り振られたリソースに送る（ス テップ２７）。 このようなコマンドを送ると、アプリケーションはリソースにアナウンスを発 生させ、スケジューラ１５の制御の下、他の通話の取扱いを始める。これを行う ために、アプリケーションは、最初にＡＰＩ中止コマンドをＳＬＥＥ１０に送り 、その後ＡＰＩ提供命令コマンドを送ることにより、その通話を中止しなければ ならない。 このシナリオでは、この最初のＡＰＩリソースコマンドは、“ようこそ”のア ナウンスを発生させて、顧客請求書番号と個人識別番号（ＰＩＮ）を表す１２個 の数字を集めるためのものである。 図８では、リソースＸはアプリケーションのコマンドを受信し、歓迎アナウン ス“ボイスメールへようこそ。貴方の請求書番号とＰＩＮを入力して下さい。” の発生を開始する（ステップ２８）。リソースＸは、歓迎アナウンスの開始後い つでも受信された数字を識別し、これらの数字の最初のものが受信され認識され た時にアナウンスの発生を停止するように構成されている。 最初の数字を受信した時、リソースＸはＳＬＥＥ１０に、最初に受信した数字 の値を含むＡＰＩイベントメッセージを送る。このメッセージは、通話インスタ ンス２２のＡＰＩイベント部の待ち行列に入れられる。本発明の目的のためには 、このアプリケーションは、請求書番号処理の最初の部分を実行するのに最初の 数字が必要であるが、請求書番号を必要とするすべてのアプリケーションが最初 の処理のために最初の数字を必要とするものではないことを説明すれば十分であ る。このアプリケーションとリソースＸとの間の対話がまだ終了していないので 、すなわち、対話がオープンのままであるので、対話ＩＤは通話インスタンスの ＩＰリソースと関係したままであることが許される。 別の実施例では、リソースＸは、顧客関連データのデータベースにアクセスし 、検索された顧客関連ＰＩＮをダイヤルされた顧客のＰＩＮと比較することによ り、顧客請求書番号およびＰＩＮの確認を実行する手段を含んでいる。用語“ダ イヤルされた”は、電話機またはその等価なものを介して手入力された数字と、 顧客により言われてリソースＸにより認識された数字の両方を含む。リソースＸ がこのような確認手段を含んでいない実施例では、これらの手段は、本発明の第 ３のリソースを構成する会話リソース２０の一つに提供されてもよい。 通常顧客は、アナウンスの始まりから開始される時間切れ内に、自分の８桁の 請求書番号と自分の４桁のＰＩＮとを入力し、１２桁が集められると、リソース Ｘは数字を含んでいる数字収集メッセージをＳＬＥＥ１０に送る（ステップ２９ ）。このメッセージは、ＳＬＥＥ１０によりコマンドとともにリソースＸに送ら れたものと同じ対話ＩＤと関係している。 顧客が時間切れ前に１２桁の入力を失敗した場合、または、何らかの他の理由 のためにリソースＸが時間切れ内に１２の認識された数字を集められなかった場 合、リソースＸは収集失敗メッセージをＳＬＥＥ１０に送る。 このアプリケーションは、数字収集メッセージまたは収集失敗メッセージのい ずれかを受信した時に対話が終了したと考え、対話ＩＤを取り出し、それを自由 な対話ＩＤのリストに戻すように処理する。 ＳＬＥＥの外部ＩＰリソースメッセージハンドラ１９Ｈextは、このメッセー ジを受信し、対話ＩＤと関連した手段により通話インスタンス２２を検索する（ ステップ３０）。その後、このメッセージはＡＰＩ ＩＰリソースメッセージ（ Ｍｓｇ）イベントとして通話インスタンスのＡＰＩイベントキューに加えられ（ ステップ３１）、通話インスタンス２２自体は、支配サービスインスタンスの実 行可能通話リストに加えられる（ステップ３２）。それから、スケジューラ１５ が再度トリガされる。 これが通話の再度の変わり目であるとスケジューラ１５が決定すると、ＡＰＩ ＩＰリソースＭｓｇイベントとこのメッセージ自体は、図９に示されているよ うに、アプリケーションに送られる（ステップ３３）。 そしてアプリケーションはサービスのための状態表中の次に続く状態に進み、 集められた請求書番号を使用してそのアプリケーションタイプと関係したデータ ベース２８にアクセスして、請求書番号で記憶されているＰＩＮを検索し、検索 されたＰＩＮを集められたＰＩＮと比較する。 ＰＩＮが一致すると、アプリケーションはデータベースに再度アクセスして、 顧客のアドレススタイルと最後の検索アクセスがなされた（日付を含む）時間を 検索し、その時間を現在の検索アクセスの時間で上書きする。そしてアプリケー ションは、それぞれ可変パラメータを含んでいる２つのフィールドを包含する第 ２のＡＰＩリソースコマンドを送る。その第１のものは顧客アドレススタイルで あり、第２のものは（日付を含む）最終検索時間である。そしてアプリケーショ ンは、ＡＰＩ中止コマンドとＡＰＩ提供命令コマンドを送り、スケジューラ１５ が次に選択された通話インスタンス２２からアプリケーションに詳細を送ってく るのを待つ。 そしてＳＬＥＥ１０は、外部ＩＰリソースハンドラ１９Ｈextにより新しい対 話ＩＤを割当て、この第２のＡＰＩリソースコマンドを第１のＡＰＩリソースコ マンドに対するのと同じ方法でリソースＸに送る。受信した時、リソースＸは、 多数の固定部分と多数の可変部分とを有するアナウンス、すなわち、“こんにち は”（固定）、“アンディ”（可変、顧客のアドレススタイル）、“貴方は〜の 時にボイスメールを最後に使用しました”（固定）、“午後３時３０分”（可変 ） 、“〜上の”（固定）、“１０日”（可変）、“〜の”（固定）、“６月”（可 変）を発生させる。これは安全性の尺度を提供する。その理由は、その時に顧客 がボイスメールにアクセスしなかった場合、誰か他の人が自分のＰＩＮを持って おり、自分のＰＩＮを変更するステップをとることができることを顧客が知るか らである。これは、顧客がオペレータに接触することにより実行することができ る。このオペレータは、適切な安全性調査をした後に、サービスノードに通話を 入れ、会話リソース２０の管理論理タイプを介してデータベース２８を修正し、 またこのリソースは、そのハンドラ２０Ｈを介して“通話”要求をし、その識別 子が会話リソース０に入力される通話インスタンスを生成する。 リソースＸがこの第２のアナウンスの発生を終了した時、リソースＸはＡＰＩ ＩＰリソースメッセージをＳＬＥＥ１０に送り、ＳＥＬＬ１０はそれを通話イ ンスタンスのＡＰＩイベントキューに入力する。 次にアプリケーションがこの通話インスタンスを処理する時に、アプリケーシ ョンは、顧客のボイスメール記憶装置にどれ位多くのボイスメール・メッセージ が預けられているのかを顧客に知らせる次の状態に行く。アプリケーションは、 データベースにアクセスして預けられたボイスメール・メッセージの数を検索し 、この数を含んでいるフィールドと時間を含んでいる他のフィールドとを包含し ている第３のＡＰＩリソースコマンドを送る。再度説明すると、その後にアプリ ケーションは、ＡＰＩ中止コマンドとＡＰＩ提供命令コマンドを送る。 ＳＬＥＥ１０はこの第３のコマンドをリソースＸに送る。このリソースＸは、 前と同じ方法で自由な対話ＩＤを割当てられることにより、この通話のために予 約されたままである。 リソースＸは、その内の２つが可変部である複数の部分を含んでいるアナウン スを発生させることにより、この第３のコマンドに応答する。第１の部分は、“ グッド”であり、これは固定されている。第２の部分は可変であり、受信コマン ドの時間フィールド中の値に応じて、“モーニング”、“アフタヌーン”または “イブニング”から選択される。すなわちリソースＸは、夜中の１２時から正午 、正午から午後６時、午後６時から夜中の１２時の３つの時間窓を持っており、 時間値を窓境界と比較することにより選択を行って、適切な窓をそして対応する 部分を決定する。第３の部分は“ボイスメールへようこそ。貴方には〜がある。 ”であり、これは固定である。第４の部分は可変であり、ボイスメール・メッセ ージ・データベース中のボイスメール・メッセージの可能性ある数に対応してい る語（スピーチセグメント）の範囲から、言い換えると、例えば“ない”から“ １２”までの範囲から選択される。第５の部分は“新しい”であり、これは固定 されている。第６の部分は可変であり、単一のボイスメール・メッセージがある か、複数のボイスメール・メッセージがあるか、ボイスメール・メッセージがな いかに応じて“メッセージ”または“メッセージズ”から選択される。 実際問題としては、アプリケーションは別のステージ、例えば、ボイスメール ・メッセージを預けている人々の名前を知りたいのかを顧客に尋ねることや（ボ イスメール・メッセージを預ける時に、自分の名前を言うように尋ねられている ）、（おそらく、ボイスメール・メッセージ番号と関連して）顧客にこれらの名 前を知らせることや、顧客の選択を受信して（サービスノードと遠隔のプラット フォームとの間の通信リンクを介して、プロトコル変換タイプの会話リソース２ ０で、ボイスメール・プラットフォーム・データベースから検索することにより ）ボイスメール・メッセージを発生させることや、ボイスメール・メッセージを 削除したいのか、または残したいのか、または保存したいのかを顧客に尋ねるこ とや、預けられたボイスメール・メッセージの発生中に顧客がハングアップ（自 分の通話を終了）した時にボイスメール・メッセージ・データベースを管理する ことがある。しかしながら当業者は、ボイスメール・サービスのこのような別の ステージの詳細な説明がなくても、サービスノードとそのＳＬＥＥの動作を十分 に理解できるであろう。 別の実施例では、顧客に複数の番号付けされたサービス関連オプション、例え ば“サービスオプションＡに対して１を押し、サービスオプションＢに対して２ を押すなど”を提供するアナウンスを発生させ、認識された番号を顧客から受信 した時に異なる複数の番号付けされたサービス関連オプションを提供する別の各 アナウンスを発生させる制御プログラムのおかげて、リソースＸは十分な知性を 有している。言い換えると、リソースはツリー構造メニューを再生して顧客が何 を要求しているかを確かめ、その能力があるのであれば要求されたサービスを提 供し、または、適切なアプリケーションタイプによる動作ために、適切な顧客関 連データとともにコマンドをＳＬＥＥに送る。 アプリケーションが最後の状態に達した時、例えば、サービスへのアクセスを 終了しようとする積極的な表示を顧客から受信した時や、時間切れが起こったこ とをリソースＸから受信した時に、アプリケーションはＡＰＩ終了信号をＳＬＥ Ｅ１０に送る。これは、通話の切断を始めるＳＬＥＥ１０のＡＰＩ終了ハンドラ ２７により受信される。 最初に、ＳＬＥＥ１０はスピーチパスを切らなければならない。ＳＬＥＥ１０ は、自由なスイッチ対話を通話インスタンス２２に割当て（ステップ３５）、リ ソースＸと呼出し人の切断を要求するメッセージをスイッチ１７に送る（ステッ プ３５）。スイッチ１７は切断を実行し（ステップ３７）、切断完了メッセージ をＳＬＥＥ１０に戻す（ステップ３８）。 リソースＸがＳＬＥＥ１０とオープン対話状態である場合には、リソースＸは 切断されなければならない。図１０に示されているように、最初に、割り振られ たリソースを通話インスタンスの切断リソース位置に移動させることによって割 り振られたＩＰリソース３を切断に入れ（ステップ３９）、そして切断メッセー ジをリソースＸに送ることにより（ステップ４０）、ＳＬＥＥ１０はこれを行う 。入通話は、通話モデル１４を介して同様な方法で切断され、その通話は現在切 断されているものとしてマークされる（ステップ４１）。 図１１に示されているように、リソースＸはそのメッセージを受信し、その切 断手順を開始する。リソースＸが切断を終了した時、切断完了メッセージをＳＬ ＥＥ１０に送る（ステップ４２）。このメッセージは、ＳＬＥＥの外部ＩＰリソ ースメッセージハンドラ１９Ｈextにより受信され、ハンドラ１９Ｈextは、対話 ＩＤに関連した手段により通話インスタンスを検索する。この対話ＩＤはリソー スから取り出され、自由な対話ＩＤ記憶装置に戻される（ステップ４３）。リソ ース自身は通話インスタンス２２から取り出され、自由なリソース記憶装置に戻 される（ステップ４４）。 これがその通話に属し切断される最後のリソースである（すなわち、入通話も 切断を終了した）場合、その後に通話は完了する。課金記録にはタイムスタンプ が付けられ、そして請求書発行システム１８に送られる（ステップ４５）。

【手続補正書】特許法第１８４条の８ 【提出日】１９９６年９月１２日 【補正内容】 明細書 インテリジェント通信ネットワーク この発明は、インテリジェント通信ネットワークでサービスを提供する方法お よびサービスノードに関する。 記憶プログラム制御（ＳＰＣ）交換機の出現前は、公衆電話交換ネットワーク （ＰＳＴＮ）は、ストローガー交換機およびクロスバー交換機のような電気機械 的な交換機と、ＴＸＥ２交換機およびＴＸＥ４交換機のような電子交換機を含ん でいた。しかしながら、これらのタイプの最先端のものでさえ、通話を単にスイ ッチングするのに加えて、すなわち入チャネルまたは回線と出チャネルとの間の 接続をするのに加えて、限られた数の機能を実行できるだけであった。さらに、 このような付加的な機能は、通信ネットワークの性能を改良するための動作、例 えば、最初に選択したルートが使用中である時に、代わりの出ルートを介して目 的地番号に到達しようと反復することに制限されていた。 ＳＰＣ交換機により、＊および＃ボタンを使用して電話キーパッドに入力され た信号を介して、顧客がさまざまな追加サービスを制御できるようになった。し かしながら、新しいサービスの導入または現在のサービスの修正は、それぞれの ＳＰＣ交換機において制御プログラムを更新しなければならないことを意味する 。 インテリジェント通信ネットワークの現在の概念は、ローカル交換機がデジタ ルメイン切替装置（ＤＭＳＵ）に接続され（ＤＭＳＵが故障した際の通信ネット ワークの回復のために、通常、それぞれのローカル交換機が２台のＤＭＳＵに接 続され）、通信ネットワーク中のさまざまな位置において離散したサービスノー ドによりサービスが提供され制御される、相互接続されたＤＭＳＵの一団に基づ いている。 各サービスノードはネットワークのＤＭＳＵに接続され、このＤＭＳＵは、顧 客によりダイヤルされたサービスアクセス数字を認識し、要求されたサービスを 顧客に対して提供するサービスノードに通話をルーティングする。 先に言及した概念の例として、インテリジェントネットワーク試験アーキテク チャーが、ペータ・オレリー、ヒング・ファイ（ルイス）チョング、ラッセル・ シベィおよびローレンス・ラタンジ氏による論文“インテリジェントネットワー クを試作する実験”、ＩＥＥＥグローバル通信会議、１９９３年１１月２９日か ら１２月２日、４の１巻、ページ１９２３から１９３０に開示されている。この アーキテクチャーでは、サービス制御ポイント（ＳＣＰ）が、Ｃ７またはＳＳ７ リンクとして通信技術者に知られている信号リンクによりスイッチに接続されて いる。ＳＣＰはまた、通話制御コマンドとメッセージ用のデータリンクにより、 アナウンスおよび数字収集のようなリソースを含んでいるインテリジェント周辺 装置（ＩＰ）にも接続されている。ＩＰは、ボイスパスを提供する通信リンクに よりスイッチに接続されている。 １９９０年エリクソン・レビューＮＯ．１、ページ１２から２２で公開された ポール・バン・ハル、ジャン・バン・デル・メア、およびニール・サルーハ氏に よる論文“サービススクリプトインタプリタ、最新のインテリジェントネットワ ークプラットフォーム”は、エリクソンのインテリジェントネットワークアーキ テクチャーのさまざまなネットワーク要素を説明している。にれらの要素の一つ は、汎用性があり費用効率が良い収集装置であり、インテリジェントネットワー クとその加入者との間の通信を可能にするインテリジェント周辺装置（ＩＰ）で ある。ＩＰは、多数の異なるアナウンスを加入者に送り、デュアルトーン多重周 波数（ＤＴＭＦ）電話機からの数字を受信することができ、アナウンスは、固定 フォーマットのものか、または可変部分をもったもののいずれかである。ＩＰは 、いくつかのサービススイッチングポイント（ＳＳＰ）によりアクセス可能な独 立のノードとして提供することができ、各サービス制御ポイントからのコマンド により、ＳＳＰを介してＩＰは制御される。ＩＰにより受信された数字は、解析 のために関連したＳＳＰを介して制御ＳＣＰに送られる。 これらの２つの先行公開論文に開示されているような既知のインテリジェント ネットワークアーキテクチャーでは、サービスのさまざまな部分の制御は、サー ビス論理プログラムに集中化されている。これは、アナウンス装置が選択された アナウンスを再生するように、質問またはプロンプトとして呼ばれＳＣＰのサー ビス論理回路から送られるメッセージにより命令され、また数字収集装置が数字 を収集するように、ＳＣＰから送られる収集数字メッセージにより命令されるエ リクソン論文にさらに明確に見出すことができる。数字収集装置は、加入者（顧 客）によりダイヤルされた数字を受信し、解析のためにそれらをユーザ数字メッ セージでＳＣＰに送信する。解析の結果が、例えば数字が認識可能な数字を形成 していない（これは、時間切れにおいて受信された数字が少なすぎる場合や、記 憶されている請求書データとの不一致かもしれない）のであれば、数字をリダイ ヤルするように顧客を促すために、ＳＣＰは適切なコマンドを発生させ、それを アナウンス装置に送信する。数字を収集し応答メッセージ（すなわち、ユーザ数 字メッセージ）を送信することにより、元の収集数字メッセージに応じて数字収 集装置がその動作を終了するので、同時にＳＣＰは、別の収集数字メッセージを 送らなければならない。 国際出願番号ＰＣＴ／ＵＳ９１／０３０８６（公開番号ＷＯ９１／１７６１６ ）では、ディスクシステムがボイスメッセージセグメント（ＶＭＳ）を記憶し、 各ＶＭＳが識別アドレス番号を持っている。加入者にボイスメッセージを再生す ることが望まれる場合、送信メッセージコマンドがディスクシステム用の入出力 制御装置に送られ、このコマンドには、チャネル番号、通話ＩＤ、送信されるべ きメッセージのメッセージ番号を指定するフィールドが含まれている。制御装置 は参照表を参照し、それによりメッセージ番号をＶＭＳの各シーケンスに変換し 、ＶＭＳのシーケンスを検索し、ＶＭＳをすぐに加入者に送信する。 本発明の第１の観点にしたがうと、 複数のサービスを規定するように構成されたサービス規定手段と、 複数のスピーチアプリケーションプラットフォーム（ＳＡＰ）と、複数の数字 収集手段とを備えたリソース手段と、 スピーチパス手段により前記リソース手段に接続されたスイッチと、 信号リンクにより前記スイッチに接続され、処理のために通話の詳細を前記サ ービス規定手段に送り、すでに進行中の通話処理により要求された場合に通話を 待ち行列に入れ、コマンド信号と応答信号を送るために前記サービス規定手段を 前記リソース手段と前記スイッチに論理的に接続し、前記リソース手段を入通話 に接続するように前記スイッチに命令することにより、ネットワークによりサー ビスノードへルーティングされた顧客からの入通話に応答するように構成された ノード制御手段とを具備する、顧客にサービスを提供するためにインテリジェン ト通信ネットワークで使用するサービスノードにおいて、 各ＳＡＰは、 各セグメントが対応する識別子を有しているスピーチセグメントを記憶する記 憶装置と、 予め定められたスピーチアナウンスの識別子を対応する連続したスピーチセグ メント識別子に変換し、 前記スピーチセグメント識別子にしたがってスピーチセグメント記憶装置にア クセスし、 ＳＡＰを制御して、スピーチアナウンスのために前記対応するスピーチセグメ ントを発生させ、 数字収集手段の前記入通話への接続を命令し、顧客から予め定められた数の数 字を集めるように前記数字収集手段を起動し、 予め定められた数の収集された数字を含んでいる対応した応答信号が前記ノー ド制御手段に送られるように命令することにより、 予め定められたスピーチアナウンスの識別子を含んでいる予め定められたコマ ンド信号の受信に応答するように構成された制御手段とを備えていることを特徴 とするサービスノードが提供される。 本発明の利点は、サービス規定手段が、リソースの個々の機能の制御に関係す る必要がなく、アナウンスを再生し顧客により提供される数字を返すようにリソ ースに対してコマンドを単に発行するだけであるということである。リソース中 に数字収集手段の制御すなわち起動コマンドの発生を配置することにより、顧客 にサービスを提供するに際してサービス規定手段がしなければならない処理量を 減少させ、既知のインテリジェントネットワークにおける場合よりもより早いサ ービス動作とより簡単なソフトウェアコードが可能になる。 前記複数の数字収集手段が前記複数のＳＡＰと離れており、前記スピーチパス 手段が、前記スイッチから前記ＳＡＰへのそれぞれの第１のスピーチパスと前記 スイッチから前記複数の数字収集手段へのそれぞれの第２のスピーチパスとを備 え、各ＳＡＰ制御手段が、前記複数の数字収集手段の１つを予約し、前記予約さ れた数字収集手段の前記それぞれの第２のスピーチパスを前記入通話に接続する ように前記スイッチに対して命令することにより、前記予め定められたコマンド 信号の受信にさらに応答するように構成されていることが好ましい。 代わりに、各ＳＡＰが前記数字収集手段のそれぞれ１つと関連しており、前記 スピーチパス手段が、前記スイッチから前記ＳＡＰへのそれぞれの第１のスピー チパスと各ＳＡＰからその関連した数字収集手段へのそれぞれの第２のスピーチ パスとを備え、各ＳＡＰ制御手段が、そのそれぞれの第１のスピーチパスをその それぞれの第２のスピーチパスへ接続するようにそのＳＡＰを制御することによ り、前記予め定められたコマンド信号の受信にさらに応答するように構成されて いてもよい。 各ＳＡＰ制御手段が、前記応答信号を前記ノード制御手段に送信するように、 前記入通話に接続され起動された数字収集手段に対して命令するように構成され ていることが好ましい。 代わりに、各ＳＡＰ制御手段が、前記応答信号に含めるために前記収集された 数字を提供するように、前記入通話に接続され起動された数字収集手段に対して 命令するように構成されていてもよい。 前記リソース手段が、顧客関連数字のデータベースと、前記顧客に対する前記 データベースに記憶されている対応した数字と比較することにより前記予め定め られた数の収集された数字を確認する手段とをさらに備え、各ＳＡＰ制御手段が 、前記収集した数字を前記確認手段に提供し、前記収集された数字を確認して確 認の結果を示す信号を返すように前記確認手段に対して命令することにより、前 記予め定められたコマンド信号の受信にさらに応答するように構成されているこ とが好ましい。 各ＳＡＰ制御手段が、 別のスピーチアナウンスの識別子を対応する連続したスピーチセグメント識別 子に変換し、 前記スピーチセグメント識別子にしたがってそのスピーチセグメント記憶装置 にアクセスし、 そのＳＡＰを制御して、別のスピーチアナウンスのために前記対応するスピー チセグメントを発生させ、 前記番号付けされたサービス関連オプションからの顧客の選択を表している数 字を集めるように、前記入通話に接続された数字収集手段を起動し、 前記数字の収集に応答して、前記収集された数字に対応するさらに別のスピー チアナウンスを発生させ、異なる複数の番号付けされたサービス関連オプション を提供することにより、 複数の番号付けされたサービス関連オプションを前記顧客に提供する別のスピ ーチアナウンスの識別子を含んでいる別のコマンド信号の受信に応答するように 構成されていることが好ましい。 リソース手段は、サービスの大部分を実行し、サービス規定手段との通信を減 らす利点を獲得するのに十分な知性を持っているが、サービスノードの費用の過 度に多い部分となる程インテリジェントではない。 本発明の第２の観点にしたがうと、 ネットワークによりサービスノードへルーティングされた顧客からの入通話を 受信し、処理のために入通話の詳細をサービス規定手段に送り、すでに進行中の 通話処理により要求された場合に通話を待ち行列に入れ、 前記サービス規定手段からの要求に応答して、数字収集手段とスピーチアプリ ケーションプラットフォーム（ＳＡＰ）を入通話に接続し、 予め定められたスピーチアナウンスの識別子を含んでいるコマンド信号を前記 サービス規定手段から前記ＳＡＰに送るステップを具備する、顧客にサービスを 提供するためにインテリジェント通信ネットワーク中のサービスノードを動作さ せる方法において、 予め定められたスピーチアナウンスの識別子を対応する連続したスピーチセグ メント識別子に変換し、 前記スピーチセグメント識別子にしたがって、スピーチセグメント記憶装置に アクセスして、前記スピーチセグメント識別子に対応するスピーチセグメントを 検索し、 前記検索されたスピーチセグメントを発生させ、 顧客によりダイヤルされた予め定められた数の数字を前記数字収集手段により 収集し、 前記サービス規定手段に前記予め定められた数の数字を含む応答信号を送信す ることにより、前記コマンド信号のＳＡＰによる受信に応答するステップを具備 することを特徴とする方法が提供される。 前記接続ステップが、入通話が受信された時に、前記スイッチを前記ＳＡＰお よび前記数字収集手段にそれぞれ結合している第１および第２のスピーチパスに 前記入通話を接続するようにスイッチを制御すること含んでいることが好ましい 。 代わりに、前記接続ステップが、入通話が受信された時に、前記ＳＡＰからス イッチに延在する第１のスピーチパスを、前記ＳＡＰから前記数字収集手段に延 在する第２のスピーチパスに接続するようにスイッチを制御すること含んでいて もよい。 前記ＳＡＰが、前記収集された数字を確認する手段に供給し、前記収集された 数字を確認して確認の結果を示す信号を返すように前記確認手段に対して命令す ることにより、前記コマンド信号の受信にさらに応答するとさらに好ましい。 顧客に複数の番号付けされたサービス関連オプションを提供する別のスピーチ アナウンスの識別子を含んでいる別のコマンド信号を前記ＳＡＰに送り、前記Ｓ ＡＰにおける前記別のコマンド信号の受信時に、別のスピーチアナウンスを発生 させ、番号付けされたサービス関連オプションからの顧客の選択を表している数 字を収集し、前記数字の収集に応答して、前記収集された数字に対応するさらに 別のスピーチアナウンスを発生させ、異なる複数の番号付けされたサービス関連 オプションを提供する別のステップを含んでいることが好ましい。 図面を参照して、例としてのみ、本発明にしたがったサービスノードの特定の 実施例をこれから説明する。 図１は、サービスノードのサービス論理実行環境の図である。 図２は、サービスノードにより提供されるサービスで使用される通話インスタ ンスの記憶位置を示している図である。 図３は、通話イベントの処理を示している図である。 図４は、通話インスタンスの初期化を示している図である。 図５は、通話インスタンスに対するリソースの割当てを示している図である。 図６は、リソースと呼出し人との間のスピーチパスの接続を示している図であ る。 図７は、アプリケーションによるリソースへのコマンドを示している図である 。 図８は、リソースの応答を示している図である。 図９は、アプリケーションが終了した時の手続きを示している図である。 図１０は、通話が切れた時の手続きを示している図である。 図１１は、リソースが切れた時の手続きを示している図である。 図１に見られるように、本発明のサービスノードの主要部分は、サービス論理 実行環境（ＳＬＥＥ）１０と呼ばれ、本発明の制御手段を構成する中央制御機能 である。 ＳＬＥＥ１０は、複数のアプリケーションタイプ１３ａ〜１３ｎのそれぞれに おける、（本発明のサービス規定手段を構成している）複数のアプリケーション インスタンス１２ａ〜１２ｎのそれぞれに対する、それぞれのアプリケーション ・プログラム・インターフェイス（ＡＰＩ）プロセス１１ａ〜１１ｎと、通話モ デルプロセス１４と、スケジューラプロセス１５と、複数のサービスノードのサ ブシステムのそれぞれに対するハンドラプロセス、すなわち、ＳＬＥＥ管理シス テム１６と、スイッチ１７と、請求書発行システム１８と、共通のハンドラ１９ Ｈを有する複数のインテリジェント周辺装置（ＩＰ）リソース１９と、共通のハ ンドラ２０Ｈを有する複数の会話リソース２０とを備えている。リソース１９お よび２０は、一緒になって、本発明のリソース手段を構成する。 この明細書では、インテリジェント周辺装置およびサービスノードの用語は、 同じ事実上の意味を持つように解釈されるべきであるが、実際には、サービスノ ードは、スイッチ１７をともなうインテリジェント周辺装置により構成される。 この実施例では、各ＩＰリソース１９は、その自己の数字収集手段を含んでい るスピーチ・アプリケーション・プラットフォーム（ＳＡＰ）である。別の実施 例では、複数の数字収集手段があり、これらは、数字収集をともなうサービスに 対して必要とされる時に、予約して、ＳＡＰと結合することができる。 各会話リソース２０は、非スピーチリソース、すなわちスイッチ１７のポート に接続されておらず、顧客からの信号（ＭＦ信号またはスピーチ）を送受信する ように構成されていないリソースである。会話リソース２０のタイプの例は、個 人識別番号（ＰＩＮ）確認装置、サービスノードが遠隔のリソースまたはシステ ムと通信する必要がある時のためのプロトコル変換装置、データベース２８への 入力の管理をするための管理論理装置である。 便宜のため、上記のプロセスを一般的にプロセス名により呼び、各ハンドラを １６Ｈ，１７Ｈなどとして識別する。ハンドラ１９Ｈは、アプリケーションとＳ ＬＥＥの共有メモリ２１との間の信号をインターフェイスする内部部分１９Ｈin tと、ＩＰリソース１９へのまたこれからの信号をインターフェイスする外部部 分１９Ｈextを有する。 ＳＬＥＥ１０の各構成部分は、プラットフォーム上のＵＮＩＸ（ＡＴ＆Ｔの商 標）プロセスとして実現される。プラットフォームは、詳細に説明する必要がな いが、マルチプロセッサの形態のマルチタスクで故障許容度のあるＵＮＩＸ環境 である。適切な場合、これらのプロセスは、メッセージの両方向通信のためのサ ブプロセスを含んでいる。このようなサブプロセスは当業者に良く知られており 、スイッチハンドラ１７Ｈのメッセージ受信サブプロセスを構成するスイッチメ ッセージハンドラ２６を除いて、特に言及しない。 ＳＬＥＥ１０の部分プロセスは、それらすべてがアクセスすることができる共 有メモリ２１のブロックを介して相互に通信する。この並列に動作する個別のプ ロセスの構成は、重大なボトルネックの可能性をかなり減らす。 アプリケーションインスタンスはＳＬＥＥ１０の初期化においてＳＬＥＥ管理 システム１６により開始され、プラットフォームに入るそれぞれの新しい通話が 共有メモリ２１中に新しい通話インスタンス２２を生成する（図２）。 各通話インスタンス２２は各通話に特定のデータを保持し、図２に示されてい るさまざまなデータカテゴリーは、割り振られたＩＰリソース、割り振られた会 話、スイッチ対話、切断フラグ、コンテキストメモリ、課金記録およびＡＰＩイ ベントである。これらのカテゴリーの中には、例えばＩＰリソースやＡＰＩイベ ントのように、通話インスタンス中に１以上の記憶位置を持つものもある。 各アプリケーションタイプ１３は１以上の規定されたサービスを提供すること ができ、（おそらく異なるサービスを使用する）異なる通話はすべて、アプリケ ーションが要求するようにカットインおよびカットアウトすることによって、任 意のアプリケーションインスタンス１３を共有することができる。通話インスタ ンス２２のコンテキストメモリは、通話の状態の履歴をたどるためにアプリケー ションにより使用される。 同じサービスを使用する多数の通話が並列に進行できるようにするために、同 じアプリケーションタイプ１３の複数のアプリケーションインスタンス１２が提 供される。通話イベントを処理できるように、ＳＬＥＥ１０のスケジューラ１５ が、アプリケーションインスタンス１２に対する通話の割当てを管理する。 外部イベントが起こった場合、ハンドラはそれらを各通話インスタンス２２の 待ち行列に入れる。図３は、これらの通話イベントを検索し、処理のためにアプ リケーションに送るさまざまなステップを示している。 スケジューラ１５は、各サービスインスタンス２３の相対優先度に基づいて、 次にどのサービスを進行させるかを決定する。すべてのサービスがそのうち進行 する一方、（ＳＬＥＥ管理システム１６により設定される）より高いサービス優 先度を有するものがより頻繁に進行することが確実になされるように、スケジュ ーラ１５が起動される度に、これらの優先度が再計算される。最高の相対優先度 とその待ち行列に入れられた実行可能な通話を持つサービスインスタンスが進行 のために選択される（他の参照番号とのオーバラップを避けるため、この最初の ステップは３０で参照されている）。スケジューラ１５は、サービス支配アプリ ケーションタイプを検索し（ステップ３１）、サービスインスタンス２３をサー ビスキュー２４の一番下に加える（ステップ３２）。スケジューラ１５により、 アプリケーションタイプ１３中のブロックキングセマファが増加され（ステップ ３３）、このアプリケーションタイプ１３に属するアプリケーションインスタン ス１２の一つにより他の通話を処理する準備ができたことを信号送信する。これ が生じた時、次のサービスインスタンス２３がキュー２４から去り（ステップ３ ４）、次の通話インスタンス２２がその実行可能な通話キュー２５から去る（ス テップ３５）。この通話インスタンス２２に属している最初のＡＰＩイベントが 、通話のコンテキストメモリとともに、処理されるべきアプリケーションに送ら れ る（ステップ３６）。 アプリケーションは、このイベントで動作させる必要のあるタスクを実行し、 これらのアプリケーションタスクの完了時にＡＰＩ中止コマンドを発行し、そし てＡＰＩ提供命令コマンドを発行し、コンテキストメモリを修正して（ステップ ３７）、通話の状態の変化に影響を与える。アプリケーションのために待ち行列 に入れられた何らかの管理イベントが、そのセマファ上のプロセスブロックが次 の通話イベントのために準備する前に（ステップ３９）、それに対して発行され る（ステップ３８）。 アプリケーションは、ＡＰＩ中止コマンドをＳＬＥＥ１０に送ってアプリケー ションから通話インスタンス２２を解放（分離）し、ＡＰＩ供給命令コマンドを 送ってアプリケーションが次の通話の準備のためにブロックされるようにする。 サービスノードにより提供されるメッセージ記録サービスに対する典型的な通 話シナリオに対して生じるプロセスの説明をこれから行う。多くの異なるタスク が起こり得るが、プラットフォームを使用するすべての通話は、以下の説明と同 様な方法で進行する。 顧客がネットワークベースのメッセージ記録サービス（以下“ボイスメール・ サービス”という）に加入したと仮定すると、そのための（図示されていない） プラットフォームは、預けられた口頭メッセージ記憶用のデータベースを含み、 ＰＳＴＮのＤＭＳＵに結合される。顧客がボイスメール・サービスを起動する時 、顧客への通話がネットワークによりプラットフォームに自動的に接続され、何 らかの所望の口頭メッセージ（以下“ボイスメール・メッセージ”という）が顧 客による後の検索のために記録され、データベース２８に記憶するために、ボイ スメール・プラットフォームが、ボイスメール・メッセージについての情報（顧 客請求書番号、顧客名）をサービスノード中のアプリケーションに送り、これは 、その請求書番号に関連した記憶通話レジスタをインクリメントし、ボイスメー ル・メッセージの現在の位置を表しているインデックスに関連して、顧客名をボ イスメール・プラットフォーム・データベースに記憶させる。 自分を待っている何らかのボイスメール・メッセージがあるか否かを見出だし たいと顧客が思っている時、顧客はボイスメール・サービスへのアクセスを得る ためにサービスアクセス数字をダイヤルし、（ネットワーク上のどこで生じたの かにかかわらず）ＰＳＴＮがその通話をサービスノードにルーティングする。 図４を参照すると、この通話がサービスノードに到着した時、信号リンクを介 してスイッチ１７から通話モデル１４へ数字が送られる。通話モデル１４は、ボ イスメール・サービスのためにダイヤルされたサービスアクセス数字を認識し、 これに応答して、ＳＬＥＥ共有メモリ２１内に新しい通話インスタンス２２を生 成して初期化し（ステップ４０）、入通話をその第１のＩＰリソース、すなわち ＩＰリソース０に割り振る（ステップ４１）。実際のＩＰリソースは入チャネル であり、この入チャネル上に入通話が現れ、これは通話インスタンス２２のＩＰ リソース０位置に割り振られるこのチャネルの識別子である。通話モデル１４は 、タイムスタンプ付きの入通話すなわちイベントを通話インスタンス２２の課金 記録位置に記録することにより、通話課金記録を初期化する（ステップ４２）。 そしてＳＬＥＥ１０はＡＰＩ入通話イベントを通話ＡＰＩイベントキューに入れ （ステップ４３）、通話インスタンス２２を実行可能な通話として適切なサービ スインスタンス２３上の待ち行例に入れる（ステップ４４）。 図５を参照して説明されているように、スケジューラ１５がトリガされ、通話 イベント処理フェーズに入る。 図５を参照すると、通話を実行する時間であるとスケジューラ１５が決定した 時、ＳＬＥＥ１０は、通話インスタンスのＡＰＩイベントキューからアプリケー ション１３にＡＰＩ入通話イベントを送る（ステップ４５）。アプリケーション はこのイベントを受信し、（図示されていない）イベントの状態表を参照し、次 に続く位置から実行する。新しい通話であるこの場合では、サービスの始めから である。 アプリケーションは、ＩＰリソース０以外の少なくとも一つのＩＰリソースの 使用を必要とする。第１にアプリケーションは、ＡＰＩ予約リソースメッセージ をＳＬＥＥ１０に送ることにより、通話のアプリケーションの割り振られたＩＰ リソースの内の自由な一つのリソース（例えばリソース３）を予約しなければな らない（ステップ４６）。アプリケーションは、通話インスタンス２２中の自由 なＩＰリソースを自分自身で選択し、また自由なリソースを予約し、選択された ＩＰリソースに対してその識別子を割り振ることをＳＬＥＥ１０に頼む。ＳＬＥ Ｅの内部ＡＰＩリソースハンドラ１９Ｈintは、そのメッセージを受信し、自由 なリソースを記憶する装置中の正しいタイプの自由な（使用されていない）リソ ース（リソースＸ）を見つけ、自由なリソースから通話インスタンスのＩＰリソ ース３にリソース識別子を移動させることにより、自由なリソースをその通話に 割り振る（ステップ４７）。このステップでは、リソースは、自由なリソースか ら実際に取り出されるか、または、そのリソースが使用中または自由でないこと をマークするためにフラグを設定することにより効果的に取り出される。成功メ ッセージが、リターンコードとしてアプリケーションに返される（ステップ４８ ）。 図６に示されているように、リソースを使用するために、アプリケーションは そのスピーチチャネルを通話のスピーチチャネルと接続しなければならない。ア プリケーションは、接続したい２つのリソース（すなわち、ＩＰリソース０、入 通話、ＩＰリソース３、要求されたリソース）を参照してＡＰＩ接続メッセージ を送ることによりこれを行う（ステップ４９）。 ＳＬＥＥのＡＰＩスイッチハンドラ１７Ｈはそのメッセージを受信し、自由な スイッチ対話ＩＤを通話インスタンス２２に割当て（予約し）（ステップ５０） 、それを使用して接続のための要求をスイッチ１７に送る（ステップ５１）。ス イッチ１７はその要求を受信し、その通話をリソースＸに接続する（ステップ５ ２）。スイッチ１７はＳＬＥＥ１０のスイッチメッセージハンドラ２６に成功し たことを信号で送り返す（ステップ５３）。 リソースを予約すると、アプリケーションは今度それと通信し、例えばこのシ ナリオでは、アプリケーションはリソースが記録されているアナウンスを顧客に 対して再生するように要求する。図７に示されているように、アナウンスタイプ を含むＡＰＩ ＩＰリソースコマンドをＳＬＥＥ１０に送ることにより、アプリ ケーションはこれを行う（ステップ５４）。ＳＬＥＥの外部ＡＰＩリソースハン ドラ１９Ｈextはこのメッセージを受信し、自由な対話ＩＤ記憶装置からのＩＤ を通話のアプリケーションＩＰリソースに割当てることによりリソースとの対話 を設定する（ステップ５５）。ＳＬＥＥの外部ＡＰＩリソースハンドラ１９Ｈex tは、この対話ＩＤをコマンドに結合し、それを割り振られたリソースに送る（ ステップ５６）。 このようなコマンドを送ると、アプリケーションはリソースにアナウンスを発 生させ、スケジューラ１５の制御の下、他の通話の取扱いを始める。これを行う ために、アプリケーションは、最初にＡＰＩ中止コマンドをＳＬＥＥ１０に送り 、その後ＡＰＩ提供命令コマンドを送ることにより、その通話を中止しなければ ならない。 このシナリオでは、この最初のＡＰＩリソースコマンドは、“ようこそ”のア ナウンスを発生させて、顧客請求書番号と個人識別番号（ＰＩＮ）を表す１２個 の数字を集めるためのものである。 図８では、リソースＸはアプリケーションのコマンドを受信し、歓迎アナウン ス“ボイスメールへようこそ。貴方の請求書番号とＰＩＮを入力して下さい。” の発生を開始する（ステップ５７）。リソースＸは、歓迎アナウンスの開始後い つでも受信された数字を識別し、これらの数字の最初のものが受信され認識され た時にアナウンスの発生を停止するように構成されている。 最初の数字を受信した時、リソースＸはＳＬＥＥ１０に、最初に受信した数字 の値を含むＡＰＩイベントメッセージを送る。このメッセージは、通話インスタ ンス２２のＡＰＩイベント部の待ち行列に入れられる。本発明の目的のためには 、このアプリケーションは、請求書番号処理の最初の部分を実行するのに最初の 数字が必要であるが、請求書番号を必要とするすべてのアプリケーションが最初 の処理のために最初の数字を必要とするものではないことを説明すれば十分であ る。このアプリケーションとリソースＸとの間の対話がまだ終了していないので 、すなわち、対話がオープンのままであるので、対話ＩＤは通話インスタンスの ＩＰリソースと関係したままであることが許される。 別の実施例では、リソースＸは、顧客関連データのデータベースにアクセスし 、検索された顧客関連ＰＩＮをダイヤルされた顧客のＰＩＮと比較することによ り、顧客請求書番号およびＰＩＮの確認を実行する手段を含んでいる。用語“ダ イヤルされた”は、電話機またはその等価なものを介して手入力された数字と、 顧客により言われてリソースＸにより認識された数字の両方を含む。リソースＸ がこ のような確認手段を含んでいない実施例では、これらの手段は、会話リソース２ ０の一つに提供されてもよい。 通常、顧客は、アナウンスの始まりから開始される時間切れ内に、自分の８桁 の請求書番号と自分の４桁のＰＩＮとを入力し、１２桁が集められると、リソー スＸは数字を含んでいる数字収集メッセージをＳＬＥＥ１０に送る（ステップ５ ８）。このメッセージは、ＳＬＥＥ１０によりコマンドとともにリソースＸに送 られたものと同じ対話ＩＤと関係している。 顧客が時間切れ前に１２桁の入力を失敗した場合、または、何らかの他の理由 のためにリソースＸが時間切れ内に１２の認識された数字を集められなかった場 合、リソースＸは収集失敗メッセージをＳＬＥＥ１０に送る。 このアプリケーションは、数字収集メッセージまたは収集失敗メッセージのい ずれかを受信した時に対話が終了したと考え、対話ＩＤを取り出し、それを自由 な対話ＩＤのリストに戻すように処理する。 ＳＬＥＥの外部ＩＰリソースメッセージハンドラ１９Ｈextは、このメッセー ジを受信し、対話ＩＤと関連した手段により通話インスタンス２２を検索する（ ステップ５９）。その後、このメッセージはＡＰＩ ＩＰリソースメッセージ（ Ｍｓｇ）イベントとして通話インスタンスのＡＰＩイベントキューに加えられ（ ステップ６０）、通話インスタンス２２自体は、支配サービスインスタンスの実 行可能通話リストに加えられる（ステップ６１）。それから、スケジューラ１５ が再度トリガされる。 これが通話の再度の変わり目であるとスケジューラ１５が決定すると、ＡＰＩ ＩＰリソースＭｓｇイベントとこのメッセージ自体は、図９に示されているよ うに、アプリケーションに送られる（ステップ６２）。 そしてアプリケーションはサービスのための状態表中の次に続く状態に進み、 集められた請求書番号を使用してそのアプリケーションタイプと関係したデータ ベース２８にアクセスして、請求書番号で記憶されているＰＩＮを検索し、検索 されたＰＩＮを集められたＰＩＮと比較する。 ＰＩＮが一致すると、アプリケーションはデータベースに再度アクセスして、 顧客のアドレススタイルと最後の検索アクセスがなされた（日付を含む）時間を 検索し、その時間を現在の検索アクセスの時間で上書きする。そしてアプリケー ションは、それぞれ可変パラメータを含んでいる２つのフィールドを包含する第 ２のＡＰＩリソースコマンドを送る。その第１のものは顧客アドレススタイルで あり、第２のものは（日付を含む）最終検索時間である。そしてアプリケーショ ンは、ＡＰＩ中止コマンドとＡＰＩ提供命令コマンドを送り、スケジューラ１５ が次に選択された通話インスタンス２２からアプリケーションに詳細を送ってく るのを待つ。 そしてＳＬＥＥ１０は、外部ＩＰリソースハンドラ１９Ｈextにより新しい対 話ＩＤを割当て、この第２のＡＰＩリソースコマンドを第１のＡＰＩリソースコ マンドに対するのと同じ方法でリソースＸに送る。受信した時、リソースＸは、 多数の固定部分と多数の可変部分とを有するアナウンス、すなわち、“こんにち は”（固定）、“アンディ”（可変、顧客のアドレススタイル）、“貴方は〜の 時にボイスメールを最後に使用しました”（固定）、“午後３時３０分”（可変 ）、“〜上の”（固定）、“１０日”（可変）、“〜の”（固定）、“６月”（ 可変）を発生させる。これは安全性の尺度を提供する。その理由は、その時に顧 客がボイスメールにアクセスしなかった場合、誰か他の人が自分のＰＩＮを持っ ており、自分のＰＩＮを変更するステップをとることができることを顧客が知る からである。これは、顧客がオペレータに接触することにより実行することがで きる。このオペレータは、適切な安全性調査をした後に、サービスノードに通話 を入れ、会話リソース２０の管理論理タイプを介してデータベース２８を修正し 、またこのリソースは、そのハンドラ２０Ｈを介して“通話”要求をし、その識 別子が会話リソース０に入力される通話インスタンスを生成する。 リソースＸがこの第２のアナウンスの発生を終了した時、リソースＸはＡＰＩ ＩＰリソースメッセージをＳＬＥＥ１０に送り、ＳＥＬＬ１０はそれを通話イ ンスタンスのＡＰＩイベントキューに入力する。 次にアプリケーションがこの通話インスタンスを処理する時に、アプリケーシ ョンは、顧客のボイスメール記憶装置にどれ位多くのボイスメール・メッセージ が預けられているのかを顧客に知らせる次の状態に行く。アプリケーションは、 データベースにアクセスして預けられたボイスメール・メッセージの数を検索し 、 この数を含んでいるフィールドと時間を含んでいる他のフィールドとを包含して いる第３のＡＰＩリソースコマンドを送る。再度説明すると、その後にアプリケ ーションは、ＡＰＩ中止コマンドとＡＰＩ提供命令コマンドを送る。 ＳＬＥＥ１０はこの第３のコマンドをリソースＸに送り、このリソースＸは、 前と同じ方法で自由な対話ＩＤを割当てられることにより、この通話のために予 約されたままである。 リソースＸは、その内の２つが可変部である複数の部分を含んでいるアナウン スを発生させることにより、この第３のコマンドに応答する。第１の部分は、“ グッド”であり、これは固定されている。第２の部分は可変であり、受信コマン ドの時間フィールド中の値に応じて、“モーニング”、“アフタヌーン”または “イブニング”から選択される。すなわちリソースＸは、夜中の１２時から正午 、正午から午後６時、午後６時から夜中の１２時の３つの時間窓を持っており、 時間値を窓境界と比較することにより選択を行って、適切な窓をそして対応する 部分を決定する。第３の部分は“ボイスメールへようこそ。貴方には〜がある。 ”であり、これは固定である。第４の部分は可変であり、ボイスメール・メッセ ージ・データベース中のボイスメール・メッセージの可能性ある数に対応してい る語（スピーチセグメント）の範囲から、言い換えると、例えば“ない”から“ １２”までの範囲から選択される。第５の部分は“新しい”であり、これは固定 されている。第６の部分は可変であり、単一のボイスメール・メッセージがある か、複数のボイスメール・メッセージがあるか、ボイスメール・メッセージがな いかに応じて“メッセージ”または“メッセージズ”から選択される。 実際問題としては、アプリケーションは別のステージ、例えば、ボイスメール ・メッセージを預けている人々の名前を知りたいのかを顧客に尋ねることや（ボ イスメール・メッセージを預ける時に、自分の名前を言うように尋ねられている ）、（おそらく、ボイスメール・メッセージ番号と関連して）顧客にこれらの名 前を知らせることや、顧客の選択を受信して（サービスノードと遠隔のプラット フォームとの間の通信リンクを介して、プロトコル変換タイプの会話リソース２ ０で、ボイスメール・プラットフォーム・データベースから検索することにより ）ボイスメール・メッセージを発生させることや、ボイスメール・メッセージを 削 除したいのか、または残したいのか、または保存したいのかを顧客に尋ねること や、預けられたボイスメール・メッセージの発生中に顧客がハングアップ（自分 の通話を終了）した時にボイスメール・メッセージ・データベースを管理するこ とがある。しかしながら当業者は、ボイスメール・サービスのこのような別のス テージの詳細な説明がなくても、サービスノードとそのＳＬＥＥの動作を十分に 理解できるであろう。 別の実施例では、顧客に複数の番号付けされたサービス関連オプション、例え ば“サービスオプションＡに対して１を押し、サービスオプションＢに対して２ を押すなど”を提供するアナウンスを発生させ、認識された番号を顧客から受信 した時に異なる複数の番号付けされたサービス関連オプションを提供する別の各 アナウンスを発生させる制御プログラムのおかげて、リソースＸは十分な知性を 有している。言い換えると、リソースはツリー構造メニューを再生して顧客が何 を要求しているかを確かめ、その能力があるのであれば要求されたサービスを提 供し、または、適切なアプリケーションタイプによる動作のために、適切な顧客 関連データとともにコマンドをＳＬＥＥに送る。 アプリケーションが最後の状態に達した時、例えば、サービスへのアクセスを 終了しようとする積極的な表示を顧客から受信した時や、時間切れが起こったこ とをリソースＸから受信した時に、アプリケーションはＡＰＩ終了信号をＳＬＥ Ｅ１０に送る（ステップ６３）。これは、通話の切断を始めるＳＬＥＥ１０のＡ ＰＩ終了ハンドラ２７により受信される。 最初に、ＳＬＥＥ１０はスピーチパスを切らなければならない。ＳＬＥＥ１０ は、自由なスイッチ対話を通話インスタンス２２に割当て（ステップ６４）、リ ソースＸと呼出し人の切断を要求するメッセージをスイッチ１７に送る（ステッ プ６５）。スイッチ１７は切断を実行し（ステップ６６）、切断完了メッセージ をＳＬＥＥ１０に戻す（ステップ６７）。 リソースＸがＳＬＥＥ１０とオープン対話状態である場合には、リソースＸは 切断されなければならない。図１０に示されているように、最初に、割り振られ たリソースを通話インスタンスの切断リソース位置に移動させることによって割 り振られたＩＰリソース３を切断に入れ（ステップ６８）、そして切断メッセー ジをリソースＸに送ることにより（ステップ６９）、ＳＬＥＥ１０はこれを行う 。入通話は、通話モデル１４を介して同様な方法で切断され、その通話は現在切 断されているものとしてマークされる（ステップ７０）。 図１１に示されているように、リソースＸはそのメッセージを受信し、その切 断手順を開始する。リソースＸが切断を終了した時、切断完了メッセージをＳＬ ＥＥ１０に送る（ステップ７１）。このメッセージは、ＳＬＥＥの外部ＩＰリソ ースメッセージハンドラ１９Ｈextにより受信され、ハンドラ１９Ｈextは、対話 ＩＤに関連した手段により通話インスタンスを検索する。この対話ＩＤはリソー スから取り出され、自由な対話ＩＤ記憶装置に戻される（ステップ７２）。リソ ース自身は通話インスタンス２２から取り出され、自由なリソース記憶装置に戻 される（ステップ７３）。 これがその通話に属し切断される最後のリソースである（すなわち、入通話も 切断を終了した）場合、その後に通話は完了する。課金記録にはタイムスタンプ が付けられ、そして請求書発行システム１８に送られる（ステップ７４）。 請求の範囲 １．複数のサービスを規定するように構成されたサービス規定手段（１１）と、 複数のスピーチアプリケーションプラットフォーム（ＳＡＰ）（１９）と、複 数の数字収集手段とを備えたリソース手段（１９，２０）と、 スピーチパス手段により前記リソース手段に接続されたスイッチ（１７）と、 信号リンクにより前記スイッチに接続され、処理のために通話の詳細を前記サ ービス規定手段に送り、すでに進行中の通話処理により要求された場合に通話を 待ち行列に入れ、コマンド信号と応答信号を送るために前記サービス規定手段を 前記リソース手段と前記スイッチに論理的に接続し、前記リソース手段を入通話 に接続するように前記スイッチに命令することにより、ネットワークによりサー ビスノードへルーティングされた顧客からの入通話に応答するように構成された ノード制御手段（１０）とを具備する、顧客にサービスを提供するためにインテ リジェント通信ネットワークで使用するサービスノードにおいて、 各ＳＡＰは、 各セグメントが対応する識別子を有しているスピーチセグメントを記憶する記 憶装置と、 予め定められたスピーチアナウンスの識別子を対応する連続したスピーチセグ メント識別子に変換し、 前記スピーチセグメント識別子にしたがってスピーチセグメント記憶装置にア クセスし、 ＳＡＰを制御して、スピーチアナウンスのために前記対応するスピーチセグメ ントを発生させ、 数字収集手段の前記入通話への接続を命令し、顧客から予め定められた数の数 字を集めるように前記数字収集手段を起動し、 予め定められた数の収集された数字を含んでいる対応した応答信号が前記ノー ド制御手段に送られるように命令することにより、 予め定められたスピーチアナウンスの識別子を含んでいる予め定められたコマ ンド信号の受信に応答するように構成された制御手段とを備えていることを特徴 とするサービスノード。 ２．前記複数の数字収集手段が前記複数のＳＡＰと離れており、前記スピーチパ ス手段が、前記スイッチから前記ＳＡＰへのそれぞれの第１のスピーチパスと前 記スイッチから前記複数の数字収集手段へのそれぞれの第２のスピーチパスとを 備え、各ＳＡＰ制御手段が、前記複数の数字収集手段の１つを予約し、前記予約 された数字収集手段の前記それぞれの第２のスピーチパスを前記入通話に接続す るように前記スイッチに対して命令することにより、前記予め定められたコマン ド信号の受信にさらに応答するように構成されていることを特徴とする請求項１ 記載のサービスノード。 ３．各ＳＡＰが前記数字収集手段のそれぞれ１つと関連しており、前記スピーチ パス手段が、前記スイッチから前記ＳＡＰへのそれぞれの第１のスピーチパスと 各ＳＡＰからその関連した数字収集手段へのそれぞれの第２のスピーチパスとを 備え、各ＳＡＰ制御手段が、そのそれぞれの第１のスピーチパスをそのそれぞれ の第２のスピーチパスヘ接続するようにそのＳＡＰを制御することにより、前記 予め定められたコマンド信号の受信にさらに応答するように構成されていること を特徴とする請求項１記載のサービスノード。 ４．各ＳＡＰ制御手段が、前記応答信号を前記ノード制御手段に送信するように 、前記入通話に接続され起動された数字収集手段に対して命令するように構成さ れていることを特徴とする請求項１ないし請求項３のいずれか１項記載のサービ スノード。 ５．各ＳＡＰ制御手段が、前記応答信号に含めるために前記収集された数字を提 供するように、前記入通話に接続され起動された数字収集手段に対して命令する ように構成されていることを特徴とする請求項１ないし請求項３のいずれか１項 記載のサービスノード。 ６．前記リソース手段が、顧客関連数字のデータベースと、前記顧客に対する前 記データベースに記憶されている対応した数字と比較することにより前記予め定 められた数の収集された数字を確認する手段とをさらに備え、各ＳＡＰ制御手段 が、前記収集した数字を前記確認手段に提供し、前記収集された数字を確認して 確認の結果を示す信号を返すように前記確認手段に対して命令することにより、 前記予め定められたコマンド信号の受信にさらに応答するように構成されている ことを特徴とする請求項１ないし請求項５のいずれか１項記載のサービスノード 。 ７．各ＳＡＰ制御手段が、 別のスピーチアナウンスの識別子を対応する連続したスピーチセグメント識別 子に変換し、 前記スピーチセグメント識別子にしたがってそのスピーチセグメント記憶装置 にアクセスし、 そのＳＡＰを制御して、別のスピーチアナウンスのために前記対応するスピー チセグメントを発生させ、 前記番号付けされたサービス関連オプションからの顧客の選択を表している数 字を集めるように、前記入通話に接続された数字収集手段を起動し、 前記数字の収集に応答して、前記収集された数字に対応するさらに別のスピー チアナウンスを発生させ、異なる複数の番号付けされたサービス関連オプション を提供することにより、 複数の番号付けされたサービス関連オプションを前記顧客に提供する別のスピ ーチアナウンスの識別子を含んでいる別のコマンド信号の受信に応答するように 構成されていることを特徴とする請求項１ないし請求項６のいずれか１項記載の サービスノード。 ８．ネットワークによりサービスノードへルーティングされた顧客からの入通話 を受信し、処理のために入通話の詳細をサービス規定手段に送り、すでに進行中 の通話処理により要求された場合に通話を待ち行列に入れ、 前記サービス規定手段からの要求に応答して、数字収集手段とスピーチアプリ ケーションプラットフォーム（ＳＡＰ）を入通話に接続し、 予め定められたスピーチアナウンスの識別子を含んでいるコマンド信号を前記 サービス規定手段から前記ＳＡＰに送るステップを具備する、顧客にサービスを 提供するためにインテリジェント通信ネットワーク中のサービスノードを動作さ せる方法において、 予め定められたスピーチアナウンスの識別子を対応する連続したスピーチセグ メント識別子に変換し、 前記スピーチセグメント識別子にしたがって、スピーチセグメント記憶装置に アクセスして、前記スピーチセグメント識別子に対応するスピーチセグメントを 検索し、 前記検索されたスピーチセグメントを発生させ、 顧客によりダイヤルされた予め定められた数の数字を前記数字収集手段により 収集し、 前記サービス規定手段に前記予め定められた数の数字を含む応答信号を送信す ることにより、前記コマンド信号のＳＡＰによる受信に応答するステップを具備 することを特徴とする方法。 ９．前記接続ステップが、入通話が受信された時に、前記スイッチを前記ＳＡＰ および前記数字収集手段にそれぞれ結合している第１および第２のスピーチパス に前記入通話を接続するようにスイッチを制御すること含んでいることを特徴と する請求項８記載の方法。 １０．前記接続ステップが、入通話が受信された時に、前記ＳＡＰからスイッチ に延在する第１のスピーチパスを、前記ＳＡＰから前記数字収集手段に延在する 第２のスピーチパスに接続するようにスイッチを制御すること含んでいることを 特徴とする請求項８記載の方法。 １１．前記ＳＡＰが、前記収集された数字を確認する手段に供給し、前記収集さ れた数字を確認して確認の結果を示す信号を返すように前記確認手段に対して命 令することにより、前記コマンド信号の受信にさらに応答することを特徴とする 請求項８ないし請求項１０のいずれか１項記載の方法。 １２．顧客に複数の番号付けされたサービス関連オプションを提供する別のスピ ーチアナウンスの識別子を含んでいる別のコマンド信号を前記ＳＡＰに送り、前 記ＳＡＰにおける前記別のコマンド信号の受信時に、別のスピーチアナウンスを 発生させ、番号付けされたサービス関連オプションからの顧客の選択を表してい る数字を収集し、前記数字の収集に応答して、前記収集された数字に対応するさ らに別のスピーチアナウンスを発生させ、異なる複数の番号付けされたサービス 関連オプションを提供する別のステップを含んでいることを特徴とする請求項８ ないし請求項１１のいずれか１項記載の方法。 【図２】 【図１０】 【図３】 【図４】 【図５】 【図６】 【図７】 【図８】 【図９】 【図１１】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ 【要約の続き】 通話に応答して、必要なように通話を処理して待ち行列 に入れるために前記サービス規定手段に通話の詳細を送 り、前記サービス規定手段からの信号を前記リソース手 段と前記スイッチに送り、前記リソース手段からのアナ ウンス終了信号を前記サービス規定手段に送るように構 成されているノード制御手段とを具備している。

Claims (1)

1. 【特許請求の範囲】 １．顧客に対してサービスを提供するインテリジェント通信ネットワークで使用 するためのサービスノードにおいて、 複数のサービスを規定するように構成されているサービス規定手段と、 顧客が提供したデータを認識し、このような認識データを記憶する手段と、使 用において、それぞれのスピーチセグメントが対応する識別子を有する複数のス ピーチセグメントを含んでいるスピーチセグメント記憶装置と、コマンド信号に 対応するスピーチアナウンスのために、受信コマンド信号を対応する連続したス ピーチセグメント識別子に変換し、前記スピーチセグメント識別子にしたがって 前記スピーチセグメント記憶装置にアクセスし、スピーチアナウンスのために対 応したスピーチセグメントを発生させ、アナウンスの最後のスピーチセグメント を発生させた時にアナウンス終了信号を供給するように構成されたリソース手段 を制御する手段とを備えたリソース手段と、 前記ネットワークにより前記サービスノードにルーティングされた入通話に前 記リソース手段を接続するように構成されたスイッチと、 このような入通話に応答して、必要なように通話を処理して待ち行列に入れる ために前記サービス規定手段に通話の詳細を送り、前記サービス規定手段からの 信号を前記リソース手段と前記スイッチに送り、前記リソース手段からのアナウ ンス終了信号を前記サービス規定手段に送るように構成されているノード制御手 段とを具備していることを特徴とするサービスノード。 ２．前記リソース手段が、前記スピーチセグメント記憶装置を含んでいる第１の リソースと、顧客が提供したデータを認識し、このような認識データを記憶する 前記手段を含んでいる別の第２のリソースとを備え、前記第１のリソースが、前 記第２のリソースと入通話との間の接続を命令し、前記第２のリソースにその認 識および記憶手段を起動してこのように記憶されているデータを前記第１のリソ ースに提供するように命令すること特徴とする請求項１記載のサービスノード。 ３．前記第１のリソースがそれ自身を介して前記接続をするように構成されてい ることを特徴とする請求項２記載のサービスノード。 ４．前記リソース手段が、顧客関連データのデータベースと、顧客用の前記デー タベースに記憶されている対応するデータと比較することにより、顧客が提供し た認識されたデータを確認するように構成された手段とをさらに備えていること を特徴とする請求項１ないし請求項３のいずれか１項記載のサービスノード。 ５．請求項２または請求項３に従属している時に、前記リソース手段が、顧客関 連データの前記データベースと顧客用の前記データベースに記憶されている対応 するデータと比較することにより、顧客が提供した認識されたデータを確認する ように構成された前記手段とを含んでいる別の第３のリソースを備え、前記第１ のリソースが、認識されたデータを前記第３のリソースに提供し、提供されたデ ータを確認して前記第１のリソースに確認の結果を示している信号を提供するよ うに前記第３のリソースに対して命令するように構成されていることを特徴とす る請求項４記載のサービスノード。 ６．前記リソース手段が、複数の番号付けられたサービス関連オプションを顧客 に提供するアナウンスを発生させ、顧客から認識された番号を受信した時に異な る複数の番号付けられたサービス関連オプションを提供する別の各アナウンスを 発生させるように構成されていることを特徴とする請求項１ないし請求項５のい ずれか１項記載のサービスノード。 ７．顧客に対してサービスを提供するインテリジェント通信ネットワークにおけ るサービスノードを動作させる方法において、 前記ネットワークにより前記サービスノードにルーティングされた入通話を受 信し、必要なように通話を処理して待ち行列に入れるためにサービス規定手段に 前記入通話の詳細を送り、 前記サービス規定手段からの要求に応答して、リソース手段を前記入通話に接 続し、 前記サービス規定手段からのコマンド信号を前記リソース手段に送り、 前記リソース手段により受信されたコマンド信号を対応する連続したスピーチ セグメント識別子に変換し、 前記スピーチセグメント識別子にしたがって、スピーチセグメント記憶装置に アクセスし、 前記対応するスピーチセグメントを発生させ、 アナウンスの最後のスピーチセグメントを発生させた時にアナウンス終了信号 を供給し、 前記リソース手段において、顧客が提供したデータを受信し、 前記受信された顧客が提供したデータを認識し、 このように認識されたデータを記憶するステップを含むことを特徴とする方法 。 ８．前記変換、アクセス、発生、供給ステップは、前記リソース手段の第１のリ ソースにより実行され、前記認識および記憶ステップは、前記リソース手段の別 の第２のリソースにより実行され、前記第１のリソースからのコマンドに応答し て、前記別の第２のリソースを前記入通話に接続するステップを含むことを特徴 とする請求項７記載の方法。 ９．顧客が提供した認識されたデータを確認するステップをさらに含むことを特 徴とする請求項７または請求項８記載の方法。 １０．請求項８に従属する時に、前記確認ステップが前記リソース手段の別の第 ３のリソースにより実行されることを特徴とする請求項９記載の方法。 １１．複数の番号付けされたサービス関連オプションを顧客に提供するアナウン スを発生させ、顧客から認識された番号を受信した時に異なる複数の番号付けさ れたサービス関連オプションを提供する別の各アナウンスを発生させるステップ をさらに含むことを特徴とする請求項７ないし請求項１０のいずれか１項記載の 方法。