JPH10503903A

JPH10503903A - インテリジェント通信ネットワーク

Info

Publication number: JPH10503903A
Application number: JP8506340A
Authority: JP
Inventors: アンドリュー・パクストンテイラー、; スティーブンハリウッド、
Original assignee: ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・・カンパニー
Priority date: 1994-08-04
Filing date: 1995-08-04
Publication date: 1998-04-07
Also published as: WO1996004743A1; NO970471L; CN1155362A; EP0774191A1; DE69505262D1; NO970471D0; ES2124575T3; CN1092444C; FI970440A0; DE69505262T2; KR970705277A; FI970440A; AU3184595A; CA2195666A1; EP0774191B1; AU689298B2; KR100338575B1; US5530742A; CA2195666C; US6310949B1

Abstract

(57)【要約】顧客に対してサービスを提供するためにインテリジェント通信ネットワークにおける使用に対してサービスノードを説明している。サービスノードは、複数のサービスを規定するように構成されているサービス規定手段と、各コマンド信号の受信に応答してスピーチアナウンスを発生し、それぞれ発生したスピーチアナウンスが終了した時にアナウンス終了信号を供給するようにそれぞれ構成された複数のリソースと、ネットワークによりサービスノードにルーティングされた入通話に前記リソースを接続するように構成されたスイッチと、このような入通話に応答して通話の詳細を対応したサービスキューに入れ、前記サービス規定手段から、（ａ）その詳細がサービスキューの一番上から前記制御手段により前記サービス規定手段に既に送られている通話に関するリソースの予約のための予約リソース要求信号と、（ｂ）これにしたがって前記スイッチを制御する、前記通話に接続されるべき前記予約されたリソースに対する接続要求信号と、（ｃ）対応するスピーチアナウンスを発生させ、これに応答して前記コマンド信号を前記予約されたリソースに送信するための、前記予約されたリソースに対するコマンド信号と、（ｄ）前記サービス規定手段を前記通話から切断し、これに応答して通話の現在の詳細を記憶するための信号と、（ｅ）前記サービス規定手段が別の通話を取扱う準備ができていることを示し、これに応答して前記サービス規定手段のそのサービスキューの一番上に前記通話を送るための信号とを受信し、サービスリソースからアナウンス終了信号を受信し、これに応答して、対応する通話の詳細を更新し、記憶装置からの前記更新された詳細を対応するサービスキューの一番下に送るように構成された制御手段とを具備する。

Description

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

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者ハリウッド、スティーブンイギリス国、アイピー４・５ユージー、サフォーク、イプスウィッチ、ブラッデン・ドライブ 44 【要約の続き】スに送信するための、前記予約されたリソースに対するコマンド信号と、（ｄ）前記サービス規定手段を前記通話から切断し、これに応答して通話の現在の詳細を記憶するための信号と、（ｅ）前記サービス規定手段が別の通話を取扱う準備ができていることを示し、これに応答して前記サービス規定手段のそのサービスキューの一番上に前記通話を送るための信号とを受信し、サービスリソースからアナウンス終了信号を受信し、これに応答して、対応する通話の詳細を更新し、記憶装置からの前記更新された詳細を対応するサービスキューの一番下に送るように構成された制御手段とを具備する。

Claims

【特許請求の範囲】１．顧客に対してサービスを提供するインテリジェント通信ネットワークで使用するためのサービスノードにおいて、複数のサービスを規定するように構成されているサービス規定手段と、各コマンド信号の受信に応答してスピーチアナウンスを発生し、それぞれ発生したスピーチアナウンスが終了した時にアナウンス終了信号を供給するようにそれぞれ構成された複数のリソースと、ネットワークによりサービスノードにルーティングされた入通話に前記リソースを接続するように構成されたスイッチと、このような入通話に応答して通話の詳細を対応したサービスキューに入れ、前記サービス規定手段から、（ａ）その詳細がサービスキューの一番上から前記制御手段により前記サービス規定手段に既に送られている通話に関するリソースの予約のための予約リソース要求信号と、（ｂ）これにしたがって前記スイッチを制御する、前記通話に接続されるべき前記予約されたリソースに対する接続要求信号と、（ｃ）対応するスピーチアナウンスを発生させ、これに応答して前記コマンド信号を前記予約されたリソースに送信するための、前記予約されたリソースに対するコマンド信号と、（ｄ）前記サービス規定手段を前記通話から切断し、これに応答して通話の現在の詳細を記憶するための信号と、（ｅ）前記サービス規定手段が別の通話を取扱う準備ができていることを示し、これに応答して前記サービス規定手段のそのサービスキューの一番上に前記通話を送るための信号とを受信し、サービスリソースからアナウンス終了信号を受信し、これに応答して、対応する通話の詳細を更新し、記憶装置からの前記更新された詳細を対応するサービスキューの一番下に送るように構成された制御手段とを具備することを特徴とするサービスノード。２．前記制御手段が、前記予約リソース要求信号の受信に応答して、前記リソースの自由な１つを予約する第１の部分を有する共通リソースハンドラを備え、前記第１の部分は、通話の現在の詳細として記憶されるべき予約されたリソースの識別子を提供し、リソース予約信号を提供するようにも構成されていることを特徴とする請求項１記載のサービスノード。３．前記共通リソースハンドラが、前記アナウンス共通信号の受信に応答して複数の対話識別子の自由な１つを予約し、記憶された予約リソース識別子に関して前記通話の現在の詳細として記憶されるべき予約対話識別子を提供し、予約対話識別子に関して前記アナウンスコマンド信号を予約されたリソースに送信する第２の部分も有することを特徴とする請求項２記載のサービスノード。４．ネットワークによりサービスノードにルーティングされた入通話を前記サービスノードのスイッチで受信し、要求されたサービスを識別し、通話の詳細を対応するサービスキューに入れ、サービスキューの一番上にある通話詳細を、次に通話を処理する準備ができているサービスノードのサービス規定手段に送り、前記サービスノードの複数のリソースの自由な１つを予約し、予約したリソースを前記通話と結合し、前記サービス規定手段からのコマンドに応答して、予約されたリソースを前記スイッチにより前記入通話に接続し、前記サービス規定手段からのコマンドに対応するスピーチアナウンスを前記予約されたリソースにより発生させ、前記予約されたリソースに命令し、別の通話を処理させるために前記サービス規定手段を解放する時の現通話の詳細を記憶し、アナウンス終了信号を前記予約されたリソースにより発生させ、これに応答して、通話の記憶されている詳細を更新させ、前記更新された通話詳細を対応するサービスキューの一番下に入れ、通話が終了するか、前記選択されたリソースがもはや必要とされないことを前記サービス規定手段が決定するまで、その通話に関してリソースの予約を維持するステップを具備する、顧客にサービスを提供するためにインテリジェント通信ネットワーク中のサービスノードを動作させる方法。５．リソースの自由な１つを予約する前記ステップが、前記サービスノードの共通リソースハンドラの第１の部分により、自由なリソースのリストのエントリーを実際にまたは実質的に取り出して、前記第１の部分により予約されたリソースの識別子とリソース予約信号を提供し、前記識別子を通話の現在の詳細として記憶し、前記リソース予約信号を前記サービス規定手段に送るサブステップを含んでいることを特徴とする請求項４記載の方法。６．前記共通リソースハンドラの第２の部分により複数の対話識別子の自由な１つを予約し、前記第２の手段により前記対話識別子を提供し、前記第２の部分により前記対話識別子に関して前記アナウンスコマンドを前記予約されたリソースに送り、前記通話の現在の詳細として前記対話識別子を記憶するステップを含むことを特徴とする請求項５記載の方法。